Teorie zpracování dat

Transkript

1 Vysoká Škola Báňská Technická Univerzita Ostrava Teorie zpracování dat Informační systém pro společnost zabývající se prodejem sprchových koutů (Semestrální projekt)

2 1. Zadání Je třeba vymyslet nový informační systém, který umožní spravování databáze o zaměstnancích, dodavatelích a zákaznících. Dále potřebujeme mít přehled v objednávkách a dílech na skladě. Také bude zapotřebí umožnit komunikaci mezi zaměstnanci firmy pomocí systému. 1.1 Funkční požadavky PROČ nový systém Stávající informační systém byl zřízen jen z důvodu okamžitého zjištění stavu dílů na skladě. Informace byla uložena v excelovských tabulkách, ke kterým byl přístup přes internet na serveru. Také je potřeba konečně přesunout evidenci všech osob do elektronické podoby, ať už se jedná o zaměstnance, dodavatele nebo zákazníky. K úspoře firemních výdajů za telefon je taky potřeba umožnit jednoduchou komunikaci mezi zaměstnanci. K ČEMU má IS sloužit Evidence zaměstnanců, dodavatelů a zákazníků. Přidávání, odebírání a editování vztahů mezi jednotlivými díly. Kontrola a editace počtu dílů na skladě. Přidávání nových objednávek a umožnění jejich rychlé kontroly podle stavu. Umožnění komunikace mezi zaměstnanci ve formě zpráv a úkolů. KDO bude s IS pracovat Jen zaměstnanci firmy, kteří mají důvod systém využít, jako jsou prodejci a nákupčí, kteří se starají o objednávky, jejich vytváření a určování, v jakém stavu se nacházejí. Skladníci, kteří mají na starosti evidenci dílů na skladě. Účetní pro výpočty platů zaměstnanců v závislosti na jimi odpracovaných hodinách a vedení informací o aktuálním finančním stavu firmy a vedoucí pro kontrolu chodu firmy, přidávání nových zaměstnanců a prohlížení výsledků práce svých zaměstnanců. VSTUPY do systému Uživatelé jsou všechny osoby, které mají přístup do systému, ale mohou to být i zaměstnanci kteří do něho přístup nemají (jen pro evidenci, například dělníci apod.). Přístup je umožněn pomocí zadání kombinace u, hesla a také musí daný uživatel zastupovat funkce která mu přístup umožňuje. U uživatelů evidujeme jméno, příjmení, rodné číslo, datum narození, adresu, která je složena z ulice, čísla popisného, města, PSČ a popřípadě státu. Dále evidujeme informace o aktuálním platu, který je vypočten z aktuální cenové sazby za hodinu a počtem odpracovaných hodin. Heslo se samozřejmě nebude ukládat do databáze ve skutečné podobě ale jen v zakódovaném tvaru. Dalším atributem bude admin, který určí, zdali zaměstnanec má přístup ke všem věcem nebo jen k těm daných svou funkcí ke které je taky vztažena hodinová mzda a má-li zaměstnanec přístup do systému. Funkce budou jednotlivé profese, které ve firmě mohou zaměstnanci zastávat. Každá funkce se musí nějak jmenovat, bude k ní krátký popis, jakou je za ní hodinová mzda a má-li s ní zaměstnanec přístup do systému. Každý zaměstnanec musí mít přiřazenou funkci. Některá funkce nemusí pro začátek být přiřazena žádnému zaměstnanci. Osoby obsahují informace o zákaznících a dodavatelích přičemž, lze o nich mluvit buď, jako o fyzických nebo o právnických osobách. Podle toho se taky určí, které atributy budou muset být vyplněny. Protože až na pár atributů by je měli stejné použijeme ISA hierarchii a nebudeme vytvářet dvě tabulky. Zatím co u fyzických osob půjde o jméno, příjmení, adresu (ulice, číslo popisné, město, PSČ, stát), tak u právnických osob (firem) to bude název firmy, IČ, DIČ, adresa (ulice, číslo popisné, město, PSČ, stát). U obou dále musíme evidovat kontakty a to mobilní telefon, pevný telefon, , popřípadě WWW stránky. Podstatnou věcí budou atributy zákazník, dodavatel, podle kterých se nám vytvořený kontakt bude zobrazovat pomocí filtrů a také

3 jak na něho zaměstnanci budou nahlížet. Samozřejmě může být i zákazníkem a dodavatelem současně. V tabulce se bude jednat o atributy: je_zakaznik, je_dodavatel. Každá osoba, která je v seznamu už provedla minimálně jednu objednávku. Objednávky budou udržovány v databázi, a bude u nich evidováno: kdo je do databáze vložil, pro koho je objednávka určená, kdy byla vložena do databáze, informaci o stavu dané objednávky, a datum poslední editace objednávky. Dále u každé objednávky musíme evidovat typ a počet kusů daných součástek, které si zákazník nebo firma objednala. U objednávky budeme evidovat také celkovou cenu, kterou zaplatíme/obdržíme. Každá objednávka musí obsahovat aspoň jeden díl, ale jsou i díly které si uživatel neobjedná. Ne každý uživatel musí vytvořit objednávku. Stav objednávky bude sloužit k určení, v jakém se v současnosti objednávka nachází stavu. Evidujeme u něho název a může být i krátký popisek co tento stav označuje přesně. Každá objednávka se musí nacházet v nějakém stavu jinak by ani nebyla v databázi. Struktura dílů, které prodáváme je následující. Jako elementární prvek bude sám díl. Z něho tvoříme komponenty a produkty. Evidujeme u něho kód(pod kterým ho má dodavatel v evidenci) který je také u této entity primárním klíčem (ne id), název, popis, dodavatele, technické parametry, cenu, počet dílů na skladě a jejich umístění. Cena je dvojí, pořizovací a prodejní. Dalším stupněm jsou komponenty. Ty se logicky skládají z dílů. Takže u nich evidujeme kód, název, technické parametry, popis, a pořizovací cenu dopočítanou z cen dílů a prodejní cenu, kterou si určíme sami. Poslední vrstvou jsou produkty. V našem případě už samotné sprchy a jejich příslušenství, které se skládají z komponent. Evidujeme u nich kód, název, popis, technické parametry a zase dvojici cen nákupní, prodejní. Každá komponenta může obsahovat více dílů, ale minimálně jeden (to v případě, že komponenta sama o sobě se dá považovat za díl, například pokud firma objednává už hotové ovládání) a každý díl v ní může být obsažen právě jednou ale třeba ve více kusech. U produktů je to stejné jako s komponentami. Uživatel si může objednat jak díl, tak komponentu, nebo rovnou celý produkt a to v různém množství kusů. U zpráv definujeme titulek (název) zprávy, text zprávy, typ zprávy (který si vybereme z definovaných typů zpráv), příjemce, kterým bude zpráva určena a také kdo zprávu vytvořil. Typ zprávy obsahuje v sobě jen atribut o názvu daného typu, podle kterého určíme jakého charakteru zpráva je. U úkolů, které zadáváme pro zaměstnance firmy, udržujeme informace o názvu, popisu, typu, prioritě, stavu a také o uživateli který úkol zadal. Přidáme-li nový úkol automaticky se zobrazí všem zaměstnancům. Nevybírá se adresát. Typ úkolu v sobě obsahuje jen název. Stav úkolu popisuje zda-li byl či nebyl daný úkol splněn. Priorita v sobě obsahuje atribut název a krátký popisek, například určující do jaké doby má být úkol s takovouto prioritou proveden. Zprávy můžeme zadat jak jednotlivcům, tak i celým předdefinovaným skupinám. Ve skupině udržujeme informace o názvu, popisu skupiny, a jejích členech. Posíláme-li zprávu Skupině, která nemá definovaného žádného člena tak se automaticky pošle všem uživatelům. Chceme-li poslat zprávu jen jedné osobě a ne skupině řešíme to vytvořením skupiny o jednom členu. Uživatel může mít více skupin a skupina je tvořena více uživateli. Každá entita v sobě automaticky obsahuje atribut id, který pokud není určeno jinak je primárním klíčem.

4 VÝSTUPY ze systému Seznam zaměstnanců všechny informace ohledně zaměstnanců od jména, příjmení, data narození, až po funkci a plat. K osobním údajům zaměstnanců bude mít přístup jen šéf firmy a osoby odpovídající za plat. Seznam zákazníků informace ohledně zákazníků od jmen, nebo názvů firmy, po adresy a kontakty. Seznam dodavatelů Informace o dodavatelích firmy, jména nebo názvy firem, které součástky dodávají, kontakty a popřípadě i seznam dodávek které už byly provedeny i se stavem s jakým byly provedeny (úspěšné, neúspěšné). Seznam objednávek protože zatím on-line obchod nefunguje, budou objednávky vyplňovat vždy jen zaměstnanci. Ať už se jedná o objednávky zákazníků nebo o objednávky pro dodavatele. U objednávek chceme vidět kdo a pro koho ji vytvořil a také o jaké díly se jedná. Budeme také schopni si zobrazit objednávky uzavřené daným zaměstnance, nebo objednávky, které byly pro daného zákazníka/dodavatele. Seznam součástek budeme schopni si kdykoliv nechat zobrazit počet dílů, komponent i produktů na skladě, uvidíme kdo je dodává, za jakou cenu, které díly tvoří určitou komponentu a také které komponenty tvoří určitý díl. Seznam zpráv budeme mít přehledný seznam zpráv, i s daty kdy byly přidány a taky kým byly přidány. Seznam úkolů jako u zpráv kdy, kdo a také prioritu úkolu a informaci o jeho splnění či nesplnění. first_name last_name birdth rc street city zip function salary Jan Svoboda 20/5/ Main Bern Svoboda@company.com chief David Novák 15/9/ First Ohio Novak@company.com buyer Výstupní sestava pro tabulku: User code name description tech_params buy_price sell_price screw steel screw Ф 50 mm tube iron tube 50 cm, Ф 10 mm Výstupní sestava pro tabulku: Part FUNKCE systému Událost Reakce Systému Aktér vytvoření uživatele přidá do tabulky User nový záznam Chief, Buyer, Seller vymazání uživatele odebrání záznamu z tabulky User Chief, Buyer, Seller vytvoření osoby přidá do tabulky Person nový záznam Chief, Buyer, Seller vymazání osoby odebrání záznamu z tabulky zákazník Chief, Buyer, Seller upravení uživatele upravení záznamu v tabulce User Chief, Buyer, Seller upravení osoby upravení záznamu v tabulce Person Chief, Buyer, Seller vložení nové zprávy vloží do tabulky Message nový záznam Chief,Buyer, Seller, Accountant vymazání zprávy vymaže z tabulky Message záznam Chief,Buyer, Seller, Accountant upravení zprávy upraví v tabulce Message konkrétní záznam Chief,Buyer, Seller, Accountant vložení nového úkolu vytvoří nový záznam v tabulce Task Chief upravení úkolu upraví v tabulce Task konkrétní záznam Chief vymazání úkolu vymaže z tabulky Task záznam Chief vložení nové objednávky vloží do tabulky Order nový záznam Chief, Buyer, Seller upravení objednávky vymaže z tabulky Order záznam Chief,Buyer, Seller

5 vymazání objednávky upraví v tabulce Order konkrétní záznam Chief,Buyer, Seller nalezení objednávek uživatele Vyhledá všechny objednávky konkrétního uživatele Chief, Seller, Accountant vypsání dílů dané komponenty Vypíše ze kterých dílů se skládá daná komponenta Storeman, Buyer, Seller Vytvoření objednávky jedná-li se o objednávku zákazníka pak prodejce vytvoří nový záznam kde specifikuje komu je objednávka určena a také jaké součástky si objednal. Pokud systém zjistí, že v současné době není na skladě dostatek kusů dané součástky je na to prodejce upozorněn a bude mu nabídnuto zadání součástky k objednání některému z nákupčích. Vytvoření nové zprávy z důvodu přehlednosti neuvidí všichni uživatelé všechny zprávy, ale jen ty které jsou pro ně určené. Toho docílíme tak že, při vytváření zprávy nadefinujeme komu je zpráva určena. Je možné zaslat jednu zprávu jen jedné osobě, ale pro tuto jednu osobu si musíme vytvořit svou vlastní skupinu. Tedy nejdříve musíme vytvořit novou skupinu, přidat do ní uživatele a pak tuto skupinu nastavit jako příjemce při vytváření zprávy. Okolí systému 1.2 Nefunkční požadavky Hardwarové vybavení firmy je na slušné úrovni. Počítače jsou nové, takže nebude problém s rychlým vyhledáváním. Databáze poběží na serveru. Bude to MySQL databáze. Celý projekt bude řešen pomocí jazyku Ruby on Rails, který umožňuje rychlou a jednoduchou komunikaci s databází. Časově by základní funkce vytvoření databáze neměla zabrat déle než dva týdny. S tím že pokročilejší funkce a různé úpravy by měly být zrealizovány do 2 měsíců. Cena systému je stanovena a dále se bude odvozovat podle počtu odpracovaných hodin jednotlivých pracovníků, kteří se na ní podílí + cena za následnou správu informačního systému.