NÁVRH A IMPLEMENTACE INFORMAČNÍHO SYSTÉMU PRO FIRMU SDUR,S.R.O.

Transcription

1 VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA PODNIKATELSKÁ ÚSTAV INFORMATIKY FACULTY OF BUSINESS AND MANAGEMENT INSTITUTE OF INFORMATICS NÁVRH A IMPLEMENTACE INFORMAČNÍHO SYSTÉMU PRO FIRMU SDUR,S.R.O. PROPOSAL AND IMPLEMENTATION OF INFORMATION SYSTEM FOR COMPANY SDUR,S.R.O. BAKALÁŘSKÁ PRÁCE BACHELOR'S THESIS AUTOR PRÁCE AUTHOR VEDOUCÍ PRÁCE SUPERVISOR ANETA ŽIAKOVÁ Ing. JIŘÍ KŘÍŽ, Ph.D. BRNO 2012

2 Vysoké učení technické v Brně Akademický rok: 2011/2012 Fakulta podnikatelská Ústav informatiky ZADÁNÍ BAKALÁŘSKÉ PRÁCE Žiaková Aneta Manažerská informatika (6209R021) Ředitel ústavu Vám v souladu se zákonem č.111/1998 o vysokých školách, Studijním a zkušebním řádem VUT v Brně a Směrnicí děkana pro realizaci bakalářských a magisterských studijních programů zadává bakalářskou práci s názvem: Návrh a implementace informačního systému pro firmu Sdur,s.r.o. v anglickém jazyce: Proposal and Implementation of Information System for Company Sdur,s.r.o. Úvod Vymezení problému a cíle práce Teoretická východiska práce Analýza problému a současné situace Vlastní návrhy řešení, přínos návrhů řešení Závěr Seznam použité literatury Přílohy Pokyny pro vypracování: Podle 60 zákona č. 121/2000 Sb. (autorský zákon) v platném znění, je tato práce "Školním dílem". Využití této práce se řídí právním režimem autorského zákona. Citace povoluje Fakulta podnikatelská Vysokého učení technického v Brně.

3 Seznam odborné literatury: CONOLLY, Thomas; BEGG, Carolyn; HOLOWCZAK, Richard. Mistrovství - databáze: Profesionální průvodce tvorbou efektivních databází. Vyd. 1. Brno: Computer Press, s. ISBN HOLZNER, Steve. Beginning Ruby on Rails s. ISBN Programming Ruby: The Pragmatic Programmer's Guide [online]. c2001 [cit ]. Programming Ruby. Dostupné z: Ruby on Rails Guides [online]. [cit ]. Rails Guides. Dostupné z: SCHWARTZ, Baron. MySQL profesionálně: optimalizace pro vysoký výkon. Vyd. 1. Brno: Zoner Press, s. ISBN Vedoucí bakalářské práce: Ing. Jiří Kříž, Ph.D. Termín odevzdání bakalářské práce je stanoven časovým plánem akademického roku 2011/2012. L.S. Ing. Jiří Kříž, Ph.D. Ředitel ústavu doc. RNDr. Anna Putnová, Ph.D., MBA Děkan fakulty V Brně, dne

4 Abstrakt Táto bakalárska práca popisuje postup návrhu a implementácie informačného systému pre firmu Sdur, s.r.o. Na základe analýzy firmy a jej potrieb vytvorím informačný systém v Ruby on Rails s využitím jazyka MySQL pre tvorbu databáze. Informačný systém by mal pomôcť pri vývoji firmy a k zlepšeniu komunikácie nielen vo firme, ale aj so zákazníkmi. Abstract This bachelor thesis describes the design development and implementation of information system for company Sdur, s.r.o. Based on the analysis of the company and its needs, I will create an information system in Ruby on Rails using MySQL for database creation. Information system should assist in developing business and improving the communication, not only in the company, but also with customers. Kľúčové slová Informačný systém, Ruby on Rails, SQL, MySQL, databáza, HTML, CSS, JavaScipt Key words Information system, Ruby on Rails, SQL, MySQL, database, HTML, CSS, JavaScript

5 Bibliografická citácia mojej práce: ŽIAKOVÁ, A. Návrh a implementácia informačného systému pre firmu Sdur, s.r.o.. Brno: Vysoké učení technické v Brně, Fakulta podnikatelská, s. Vedúci bakalárskej práce Ing. Jiří Kříž, Ph.D..

6 Čestné prehlásenie Čestne prehlasujem, že predložená bakalárska práca je pôvodná a spracovala som ju samostatne. Prehlasujem, že citácia použitých prameňov je úplná, že som vo svojej práci neporušila autorské práva (v zmysle Zákona č. 121/2000 Sb., o právu autorském a o právech souvisejících s právem autorským). V Brne, dňa 31. mája 2012

7 Poďakovanie Rada by som poďakovala vedúcemu bakalárksej práce, pánu Ing. Jiřímu Křížovi, Ph.D., za odborné vedenie a cenné rady a pripomienky. Tiež by som rada poďakovala konateľke spoločnosti, pani Jitke Cabalovej, za poskytnuté informácie o spoločnosti a príjemnú spoluprácu.

8 Úvod Vymedzenie problému a ciele práce Teoretické východiská Relačné databázy Relačná integrita SQL (Structured Query Language) Životný cyklus databázy Metodológia návrhu databázy Hľadanie faktov prípady použitia Konceptuálny návrh databázy Logický návrh databázy Fyzický návrh databázy Funkčné modelovanie vývojové diagramy Informačný systém Životný cyklus informačného systému Použité technológie pri tvorbe informačného systému MySQL Ruby on Rails HTML CSS JavaScript Metódy použité pri analýze firmy SWOT analýza Analýza problému a súčasnej situácie Popis spoločnosti Základné údaje o firme Vznik firmy Vnútorná analýza spoločnosti Vonkajšia analýza spoločnosti SWOT analýza... 34

9 2.2 Zhodnotenie informačných technológií firmy Hardware a software Webové stránky firmy Popis súčasnej situácie informačných technológií Údaje o umelcoch Údaje o podujatiach Údaje o obchodných partneroch Zhodnotenie analýzy Návrh riešenia Požiadavky spoločnosti na informačný systém Požiadavky firmy Požiadavky návštevníkov webu Use Case diagram Konceptuálny návrh databázy Logický návrh databázy Fyzický návrh databázy Modelovanie systému Webová prezentácia Prihlásenie do internej časti IS Správa klientov Správa zamestnancov Správa firiem Správa podujatí Správa činností Účet zamestnanca Správa sponzorských darov Výsledná aplikácia Záver Použitá literatúra Zoznam skratiek... 63

10 Zoznam obrázkov Zoznam tabuliek Zoznam príloh... 65

11 Úvod Informačné systémy v dnešnej dobe sú nepostradateľnou súčasťou každej spoločnosti. Napriek tomu, že spoločnosť s informačným systémom sa stáva konkurenčne silnejšia na trhu, niektorí podnikatelia majú strach z používania informačných systémov pre ich zložitosť a tiež cenu. Táto bakalárska práca sa zaoberá návrhom a implementáciou informačného systému na mieru v podobe webovej aplikácie. Informačný systém je navrhnutý pre agentúru Sdur, s. r. o., ktorá sa zaoberá zastupovaním umelcov a organizovaním koncertov klasicekj hudby. 11

12 Vymedzenie problému a ciele práce Spoločnosť Sdur, s. r. o. má v súčasnej dobe statické webové stránky. Vytvorenie informačného systému jej pomôže vyriešiť hlavný problém a to je získavanie a spravovanie údajov. Ďalším problémom spoločnosti je aktualizácia webových stránok, ktorá je buď náročná pre zamestnancov, ktorí nepoznajú nejaký programovací jazyk alebo časovo náročná, ak webové stánky upravuje externý odborník. Preto informačný systém by bolo vhodné navrhnúť ako webovú aplikáciu, ktorá umožňuje generovať údaje z databázy pre návštevníkov webu. Cieľom mojej bakalárskej práce je navrhnúť a implementovať informačný systém pre firmu Sdur, s.r.o. Tento cieľ som rozdelila na čiastkové ciele: V prvej časti bakalárskej práce budú popísané teoretické východská pre návrh informačného systému, návrh databázy, s ktorou bude informačný systém pracovať a použité technológie pre vývoj. Ďalším čiastkovým cieľom je analýza spoločnosti, zistiť jej silné stránky, ktoré by sa mali rozvíjať a naopak slabé stránky, ktoré by sa mali vyriešiť. Návrh riešenia obsahuje návrh informačného systému a databázy, s ktorou bude pracovať a popis vývoja aplikácie. 12

13 1 Teoretické východiská Táto kapitola má za úlohu oboznámiť čitateľa so základnými pojmami databázových a informačných systémov a postupom ich návrhu, rozoberá základy jazyka SQL, ktorý musí programátor poznať pri práci s databázami. Ďalej sú tu popísané základné vlastnosti nástrojov použitých pre vývoj aplikácie a to: MySQL pre prácu s databázou, jazyky Ruby on Rails, pomocou ktorého je naprogramovaná celá aplikácia a jazyk HTML, CSS a JavaScript, ktoré upravujú dizajn aplikácie. 1.1 Relačné databázy V roku 1970 predstavil ako prvý E. F. Codd relačný model vo svojej práci A relation model of data for large shared data banks (Relačný model dát pre veľké zdielané banky dát), ktorý riešil nedostatky hierarchického a sieťového modelu matematickými technikami a štruktúrami. Cieľom relačného modelu bolo umožniť vysoký stupeň nezávislosti dát, poskytnúť základ pre zvládnutie problému sémantiky dát, konzistencie dát a redundancie (duplicity) dát a umožniť expanziu množinovo orientovaných jazykov pre manipuláciu dát. Datový model je pomerne jednoduchý a všetky dáta reprezentuje vo forme dvojrozmerných tabuliek (4, 9). V dnešnej dobe sú relačné databázové systémy veľmi rozšírené. Komerčné databázové systémy ako Microsoft SQL Server, Oracle, IBM DB2 predstavujú dominantnú databázovú technológiu a označujú sa ako databázové systémy druhej generácie (4). Pred prácou s relačnou databázou je potrebné poznať niekoľko základných pojmov (4): relácia tabuľka so stĺpcami a riadkami schéma relácie záhlavie tabuľky atribút pomenovaný stĺpec relácie datová n-tica riadok relácie hodnota atribútu jedna hodnota v tabuľke doména množina prípustných hodnôt pre jeden alebo viac atribútov relačná databáza kolekcia normalizovaných tabuliek 13

14 Obrázok 1: Základné pojmy relačnej databázy (Upravené podľa 15, s. 25) Pravidlá pre tabuľkovú prezentáciu relácie (15): každý riadok odpovedá jednej n-tici relácie poradie riadkov je nevýznamné žiadne dva riadky nie sú rovnaké (tabuľka neobsahuje duplicitné riadky) poradie atribútov je nevýznamné význam každého atribútu je určený menom atribútu žiadne dva názvy atribútov nie sú rovnaké hodnoty atribútov sú atomické Relačná integrita Pri modelovaní dát z reálneho sveta je nutné dodržiavať určité obmedzenia, ktoré zaisťujú presnosť dát. Tieto pravidlá sa nazývajú integritné obmedzenia a predstavujú prostriedky pre obmedzenie datových hodnôt, ktoré sú vkladané do tabuľky alebo sú vytvorené pri jej aktualizácii. K porušeniu integrity dát môže dôjsť vo viacerých prípadoch: pri pridávaní neplatných dát do databáze (zadaná objednávka, ktorá určuje neplatný produkt), existujúce dáta, ktoré sú zmenené na zlú hodnotu (priradenie zamestnanca do neexistujúcej pobočky), zmeny dát môžu byť stratené (výpadok napätia) alebo aplikované čiastočne (4, 9, 15). Integritné obmedzenie pre entity (15): doménová integrita entitná integrita referenčná integrita 14

15 Doménová integrita Ako som už uvádzala vyššie, doména je množina prípustných hodnôt pre daný atribút. Doménová intergita slúži ku kontrole týchto hodnôt atribútov, či patria do domény (9). Pre daný atribút je nutné určiť tieto povolené hodnoty (15): typ poľa (datový typ) zadanie hodnoty atribútu je povinné, neprázdna hodnota jedinečnosť hodnôt v rámci atribútu rozsah hodnôt minimálna, maximálna hodnota implicitná (štandardná) hodnota maska pre vkladanie zoznam prípustných hodnôt (číselník) Entitná integrita V prípade, že je relačná databáza správne navrhnutá podľa integritných obmedzení, každá relácia má jeden atribút alebo kombináciu atribútov, ktorých hodnoty jednoznačne identifikujú každý riadok relácie. Tento atribút (atribúty) označujeme ako primárny kľúč (9). Primárnym kľúčom (primary key) môže byť atribút (alebo kombinácia atribútov), ktorý je jednoznačný v relácií neexistuje iný riadok, ktorý by mal rovnakú hodnotu atribútu primárneho kľúča. Ďalšou podmienkou pre primárny kľúč je atomickosť (musí byť minimálny) žiadny z atribútov nie je možné vypustiť bez toho, aby bolo porušené pravidlo jednoznačnosti. Keďže pomocou primárneho kľúča identifikujeme každý záznam v tabuľke, táto hodnota atribútu nesmie byť prázdna, čiže nesmie obsahovať hodnotu NULL (15) Referenčná integrita Referenčná integrita zaisťuje, aby relačný databázový systém automaticky kontroloval, či ku každej hodnote cudzieho kľúča v podriadenej tabuľke existuje odpovedajúca hodnota primárneho kľúča v nadriadenej tabuľke (9). Cudzím kľúčom (foreign key) je atribút (alebo kombinácia atribútov), ktorého hodnota v jednej tabuľke zodpovedá hodnote v inej tabuľke. Počet atribútov a datové 15

16 typy atribútov, ktoré tvoria cudzí kľúč a primárny kľúč musia byť vždy identické. Cudzie kľúče v relačných databázach sú veľmi dôležitou súčasťou, pretože vynucujú správnosť relácie. Vzťah primárneho kľúča a cudzieho kľúča tvorí reláciu tabuliek a určuje nadriadenú alebo podriadenú tabuľku. Na obrázku 2 je ukážka použitia primárneho kľúča ID_zákazník v tabuľke ZÁKAZNÍK ako cudzí kľúč v tabuľke OBJEDNÁVKA (9). Obrázok 2: Ukážka použitia primárneho a cudzieho kľúča (Vlastné spracovanie) SQL (Structured Query Language) Jazyk SQL, z anglického názvu preložené ako štrukturovaný dotazovací jazyk, je neprocedurálny programovací jazyk, ktorý slúži pre organizovanie, správu a získavanie dát, čiže komunikáciu s relačnými databázami. Stal sa formálnym štandardom ISO (International Standards Organization), ANSI (American National Standards Institute) a v podstate štandardným jazykom relačných databázových systémov (4, 9). Pôvodne bol jazyk SQL navrhnutý len pre získavanie dát z databázy a aj keď to patrí medzi jeho najdôležitejšie funkcie, je ho možné použiť k riadeniu všetkých funkcií, ktoré databázový systém poskytuje, vrátane (9): definície dát definovanie štruktúry a organizácie uložených dát a jej vzťahov získavanie dát z databázy 16

17 manipulácia s dátami aktualizácia pridávaním nových dát, odstraňovaním starých alebo zmenou už uložených dát riadenie prístupu obmedzenie prístupových práv zdielanie dát zľadenie zdielania dát medzi viac užívateľmi integrita dát Príkazy jazyka SQL Hlavnú časť jazyka SQL tvorí asi 40 príkazov. Medzi najdôležitejšie a často používané príkazy patria príkazy pre vytvorenie tabuliek, vyhľadanie dát alebo vloženie nových dát do databázy (9). Príkazy jazyka SQL sú formulované pomocou klauzúl s príslušnými kľúčovými slovami a parametrami. Kľúčové slová tvoria vybrané alebo rezervované slová, takže ich nemôžeme použiť ako názvy bežných databázových objektov. Každý príkaz musí končiť bodkočiarkou (;). Príkazy jazyka SQL môžme rozdeliť do nasledujúcich kategórií (20): Jazyk pre dotazovanie dát (Data Query Language, DQL) - príkazy, ktoré sa dotazujú databázy, ale v dátach ani v databázových objektoch neprevádzajú žiadne zmeny: SELECT (niektorí výrobcovia zaraďujú do jazyka DML) Jazyk pre manapuláciu s dátami (Data Manipulation Language, DML) príkazy, ktoré modifikujú dáta uložené v tabuľkách: INSERT, UPDATE a DELETE Jazyk pre definíciu dát (Data Definiton Language, DDL) príkazy, ktoré slúžia k vytváraniu a modifikácii databázových objektov: CREATE, ALTER a DROP Jazyk pre riadenie dát (Data Control Language, DCL) príkazy pre správu oprávnení: súčasťou sú príkazy GRANT a REVOKE Životný cyklus databázy Životný cyklus databázy úzko súvisí s životným cyklom informačného systému, ktorý je popísaný nižšie. Pred samotným návrhom databázy je nutné naplánovať priebeh projektu, čiže priebeh návrhu databázy a stanoviť čiastočné ciele. Ako pri každom 17

18 projekte, musia sa stanoviť finančné prostriedky, ľudské zdroje a časová náročnosť pre vytvorenie databázy. Pre správne vytvorenie databázy je dôležitý zber a analýza požiadaviek budúcich užívateľov systému. Požiadavky užívateľov sa často menia behom návrhu, preto komunikácia so zákazníkom je veľmi potrebná v priebehu celého vývoja databázy (4). Klasická metóda vývoja počítačového systému sa opiera o proces označovaný ako životný cyklus vývoja systému (system development life cycle, SDLC) a jeho etapy zobrazuje nasledujúci obrázok (20): Obrázok 3: Klasický životný cyklus vývoja systému (Upravené podľa 20, s. 138) 18

19 1.2 Metodológia návrhu databázy Metodológia návrhu databázy predstavuje: Strukturovaný přístup používající procedury, techniky, nástroje a dokumentaci s cílem podpořit a usnadnit proces návrhu. (4, s. 206). Samotný návrh databázy je rozdelený na tri hlavné štádia: konceptuálny, logický a fyzický návrh databázy, ktoré napomáhajú návrhárom pri plánovaní, správe, kontrole a zhodnotení vývojových produktov (4). Pri návrhu sa pre lepšie pochopenie systému využíva datové a funkčné modelovanie, ktrého výsledkom sú diagramy, napr. Use Case diagram, ER diagram, vývojové diagramy a iné (4, 20) Hľadanie faktov prípady použitia Diagramy prípadov použitia (Use Case) tvoria súčasť UML (Unified Modelling Language unifikovaný modelovací jazyk), ktorý predstavuje univerzálny jazyk pre vizuálne modelovanie systému. Prípady použitia, ktoré popisujú typické interakcie medzi užívateľmi systému a samotným systémom, používame pre zachytenie funkčných požiadavkiek na systém (1). Pri modelovaní prípadov použitia postupujeme nasledovne (1): nájdenie hraníc systému (system boundary) vyznačenie hraníc modelovaného systému definovanie účastníkov (actors) užívatelia systému osoby alebo predmety (systém), ktoré predstavujú osoby alebo predmety (systém) používajúce daný systém nájdenie prípadov použitia (use cases) činnosti, ktoré môžu účastníci systému vykonávať špecifikácia prípadov použitia tvorba scenárov 19

20 1.2.2 Konceptuálny návrh databázy Konceptuálny návrh databázy sa zameriava hlavne na vytvorenie ER modelu (entitnerelačný model), ktorý predstavuje úplnú a presnú reprezentáciu datových požiadaviek organizácie, ktorú má databáza podporovať (4). Metodika návrhu ER modelu (4, 15): 1. identifikácia entít definovanie hlavných objektov, 2. idetifikácia relácií vzťahy medzi hlavnými objektami, 3. identifikácia atribútov entít a relácií nájdenie faktov, ktoré budeme o entitách a reláciach v databáze prezentovať 4. určenie domén atribútov 5. určenie primárnych kľúčov jednotlivých entít 6. kontrola redundancie v modeli preskúmanie relácií typu 1:1, prípadne ich odstránenie 7. kontrola, či model podporuje užívateľské transakcie 8. posúdenie konceptuálneho modelu s užívateľmi Logický návrh databázy Hlavným účelom logického návrhu databázy je vytvorenie popisu tabuliek pomocou ER modelu vytvoreného vo fáze koceptuálneho návrhu databázy. Štruktúra tabuliek je potrebné normalizovať, aby nenastalo zbytočné opakovanie záznamov. Okrem toho je potrebné skontrolovať, či tabuľky podporujú požadované užívateľské transakcie. Pri logickom návrhu databázy sa postupuje následovne (4): 1. vytvorenie tabuliek reprezentujú entity, relácie, atribúty a integritné obmedzenia 2. kontrola tabuliek pomocou normalizácie všetky tabuľky musia byť minimálne v 3. normálnej forme 3. kontrola, či tabuľky podporujú užívateľské transakcie 4. kontrola integritných obmedzení 5. posúdenie logického návrhu databázy s užívateľmi 20

21 Normalizácia V roku 1979 E. F. Codd vytvoril proces normalizácie, ktorý predstavuje techniky používané pri návrhu datových štruktúr databázy. Pomocou normálnych foriem sú tabuľky upravované tak, aby bolo umožnené efektívne ukladanie dát a aby sa minimalizovala redundancia dát. Znormalizované tabuľky v databáze tak umožňujú efektívne vkladanie dát a prácu s nimi (4, 15). Prvá normálna forma (1. NF) Relace je v první normální formě, pokud jsou všechny její atributy definovány nad skalárními obory hodnot (doménami). (15, s. 55) Aby tabuľky databázy boli v prvej normálnej forme, každá položka tabuľky musí byť jednoduchá, čiže nesmie byť zložená alebo viachodnotová (15). Obrázok 4: Normalizácia relácie do 1.NF (Upravené podľa 15, s. 57) Druhá normálna forma (2. NF) Relace je ve druhé normální formě, pokud je v první normální formě a navíc všechny její atributy jsou závislé na celém kandidátním (primárním) klíči. (15, s. 56) Druhá normálna forma sa týka hlavne tabuliek, ktoré majú zložený primárny kľúč, tzn. primárny kľúč, ktorý tvoria dva alebo viaceré stĺpce (4). Obrázok 5: Normalizácia relácie do 2.NF (Upravené podľa 15, s. 59) 21

22 Tretia normálna forma (3. NF) Relace je ve třetí normální formě, pokud je ve druhé normální formě a navíc všechny její neklíčové atributy jsou vzájemně nezávislé. (15, s. 58) Tretia normálna forma vyžaduje, aby v tabuľkách nebola tranzitívna závislosť, ktorá spôsobuje redundanciu dát. Všetky nekľúčové atribúty entity by mali byť teda funkčne závisle len na jednom primárnom kľúči (4, 15). Obrázok 6: Normalizácia relácie do 3.NF (Upravené podľa 15, s. 60) Boyce-Coddova normálna forma Relace je v Boyce-Coddově normální formě, pokud mezi kandidátními klíči není žádna funkční závislost a to za těchto podmínek: relace musí mít dva nebo více kandidátních klíčů nejméně dva z kandidátních klíčů musí být složené kandidátní klíče se v některých atributech musí prekrývat (15, s. 61) Relácia je v Boyce-Coddovej normálnej forme, ak je relácia v tretej normálnej forme (naopak to neplatí). Táto a nasledujúce (štvrtá a piata) norálne formy sú určené pre špecifické prípady a nie vždy je možné reláciu normalizovať do týchto foriem (15). Štvrtá normálna forma (4. NF) Relace je ve čtvrté normální formě, pokud je v Boyce-Coddově normální formě, a navíc všechny vícehodnotové závislosti jsou zároveň funkčními závislostmi z kandidátních klíčů (v jedné relaci se nesmí spojovat nezávislé opakované skupiny). (15, s. 63) 22

23 Piata normálna forma (5. NF) Týká se případu spojené závislosti, která vyjadřuje cyklické omezení: pokud je relace 1 spojená s relací 2, relace 2 je spojená s relací 3 a relace 3 je zase spojena s relací 1, pak všechny tři entity musí být součástí stejného vektoru hodnot. (15, s. 64) Fyzický návrh databázy Cieľom fyzického návrhu databázy je previesť logický návrh do konkrétnej podoby tak, aby sme boli schopní databázu implementovať. Fyzický návrh na strane databázy znamená implementovať normalizované tabuľky do prostredia relačného databázového systému. Podstatným výstupom tejto fázy sú príkazy jazyka DDL pre vytvorenie tabuliek, prípadne indexov, s ktorými budú pracovať vývojari. Následne je vhodné v tejto fáze vývoja navrhnúť bezpečnostné mechanizmy (19, 20) Funkčné modelovanie vývojové diagramy Funkčné modelovanie sa zaoberá skúmaním a algoritmizáciou činností, procesov, ktoré prebiehajú v informačnom systéme. Medzi ďalšie diagramy funkčného modelovania patria: procesný diagram, stavový diagram, diagram toku dát (Data Flow Diagram, DFD) a iné. Funkčné modelovanie slúži hlavne k modifikácie datového modelu na základe funčných požiadaviek (15). Vývojový diagram patrí medzi najpoužívanejšie diagramy funčného modelovania. Hlavnou výhodou vývojového diagramu je možnosť zachytenia vetvenia spracovania podľa splnenia či nesplnenia požiadaviek (15). Obrázok 7: Vývojový diagram používané značky (Upravené podľa 15, s. 93) 23

24 1.3 Informačný systém Informační systém slouží nejen k sběru, správě a kontrole dat používaných a vytvářených organizací, ale umožňuje také transformaci dat na informace. Informační systém poskytuje také infrastrukturu pro usnadnění šíření informací k těm, kdo přijímají rozhodnutí kritická pro úspěch organizace. Podstatnou složkou jádra informačního systému je databáze, která ho podporuje. (4, s. 108) Životný cyklus informačného systému Efektívny vývoj ľubovoľnej aplikácie musí mať určitú postupnosť. Ak sa správne dodržujú jednotlivé kroky vývoja, vývojoví projektanti sa vyhnú problémom s prekročením finančných prostriedkov a dodacej lehoty alebo nespokojnosti zákazníkov. Životný cyklus informačného systému sa rozdeľuje do viacerých nepostrádateľných fáz: plánovanie, zber a analýza požiadaviek, návrh (vrátane návrhu databázy), vytvorenie prototypu, implementácia, testovanie, konverzia a prevádzková údržba. Tieto fázy sú logicky a efektívne usporiadané a postup by mal byť striktne dodržiavaný. Avšak častokrát je potrebné alebo nutné vrátiť sa na predchádzajúcu fázu pomocou spätných väzieb a zopakovať daný proces (4). 24

25 1.4 Použité technológie pri tvorbe informačného systému MySQL MySQL je databázový systém pre správu relačnej databázy typu klient/server a zahŕňa SQL server, klientské programy pre prístup k servru, nástroje pre správu a programovacie rozhranie pre písanie vlastných programov. Vznik MySQL siaha až do roku 1979 v Škandinávii (6). Medzi výhody MySQL oproti iným databázovým systémom patrí rýchlosť mnohí vývojari tvdria, že je najrýchlejším databázovým systémom, jednoduchosť používania, podpora dotazovacieho jazyka, spôsobilosť súčasne je možné pripojiť viacerých klientov, klienti môžu využívať zároveň niekoľko databáz. MySQL je plne sieťový, a preto k databázam je možné pristupovať z internetu, má riadený prístup, takže dáta nemusia vidieť všetci návštevníci. MySQL je projekt Open Source, takže je dostupný zadarmo v rámci GPL GNU. Toto pravidlo je vyjadrené na domácej stránke MySQL a znie: MySQL je zcela zdarma pro ty, kdo nikdy nekopírují, nemění a nedistribuují. (16, s. 42) (6, 16). Obrázok 8: Logická architektúra MySQL (Upravené podľa 25, s. 20) 25

26 1.4.2 Ruby on Rails Ruby on Rails (ďalej Rails) je framework, ktorý zjednodušuje vývoj, nasadenie a údržbu webových aplikácií, napísaný v jazyku Ruby (21). Obsahuje abstraktnú vrstvu pre prácu s databázou, implementáciu pomocou model-view-controller architektúry, zabudovanú podporu pre testovanie všetkých vrstiev aplikácie, generátory kódu alebo konzolu pre interaktívnu prácu s aplikáciou (22, 24). Rails filozofia obsahuje niekoľko základných zásad (22): DRY Don t Repeat Yourself znamená, že nie je produktívne a správne písať ten istý kód stále dookola Konvencia má prednosť pred konfiguráciou je dôležitejšie určiť si predpoklady o tom, čo chcem robiť a čo budem robiť, než každú maličkosť upravovať cez nekonečné konfiguračné súbory. REST (Representational State Transfer) je najlepším vzorom webových aplikácií: organizovanie aplikácií pomocou zdrojov a štandardného HTTP je najrýchlejší spôsob Model-Pohľad-Radič architektúra (Model-View-Controller) S touto architektúrou, označovanou tiež skratkou MVC, prišiel v roku 1979 Trygve Reenskaug. MVC sa využíva pre vývoj interaktívnych aplikácií a je rozdelená na tri typy komponent: modely, pohľady a radiče. Medzi výhody MVC architektúry patrí oddelená aplikačná logika od užívateľského rozhrania, znovupoužiteľnosť kódu a štruktúra kódu aplikácie, ktorá je prehľadná a zjednodušuje údržbu (22, 24). Obrázok 9: Architektúra MVC (24, s. 59) 26

27 Model Model slúži k udržiavaniu stavu aplikácie, ktorý je niekedy prechodný a trvá len niekoľo interakcii s užívateľom a inokedy je trvalý a ukladá sa mimo aplikáciu, do databázy. Model si vynucuje všetky pravidlá, ktoré sa vzťahujú na dáta. Je to logický spôsob zaistenia, že nič v aplikácií nemôže spôsobiť neplatnosť dát. Vo väčšine prípadov odpovedá jedna tabuľka v databáze jednému modelu v aplikácii (22, 24). Pohľad - view V architektúre MVC pohľady generujú užívateľské rozhranie, ktoré je väčšinou založené na dátach z modelu. Tieto dáta sú dostupné cez model, ale práve pohľad k nim pristupuje a formátuje ich pre koncového užívateľa. V Rails sú pohľady väčšinou HTML súbory s vloženými časťami Ruby kódu, ktorý má na starosti len úkony týkajúce sa prezentácie dát (22, 24). Radič controller Radiče riadia celú aplikáciu. Slúžia k spracovaniu požiadaviek, ktoré prichádzajú z webového prehliadača, získavajú dáta z modelov a odosielajú tieto dáta do pohľadov, ktoré dáta zobrazia (22, 24) Súčasť Rails Framework Rails nie je monolitický, ale je poskladaný z niekoľkých častí (22): Action Pack VC časť MVC architektúry o Action Controller má na starosti radiče v Rails aplikácii, spracováva požiadavky, extrahuje z nich parametre a smeruje na príslušné radiče o Action Dispatch spracováva smerovanie prichádzajúcich požiadaviek do aplikácie o Action View spracováva pohľady aplikácie, vo východzom nastavení vie poskytovať výstup v HTML a XML, obsahuje zabudovanú podporu pre Ajax Action Mailer poskytuje podporu pre prácu s -ami 27

28 Active Model umožňuje používať iné ORM technológie (Object Relational Mapping, objektovo relačné mapovanie) pre prácu s relačnými databázami Active Record je základom pre modely v Rails aplikácii, poskytuje taktiež nezávislosť na SQL dialektu konkrétnej databázy, základné operácie pre získavanie, vytváranie, editáciu a mazanie záznamov (tzv. CRUD Create, Read, Update, Delete), pokročilé získavanie dát z databázy (JOIN, GROUP a iné) a v neposlednej rade definovať vzťahy medzi jednotlivými modelmi Active Resource umožňuje prepojiť modely v aplikácii s webovou službou typu REST (Representational State Transfer), mapuje modely na vzdialenej webovej službe, umožňuje s nimi pracovať podobne, ako by boli mapované na databáze Active Support je rozsiahly súbor podporných funkcií a rozšírení základných tried Ruby Railties umožňuje vygenerovať novú Rails aplikáciu a podporuje jednotlivé frameworky a súčasti dohormady Obrázok 10: Adresárová štruktúra Rails na najvyššej úrovni (Upravené podľa 24, s. 295) 28

29 1.4.3 HTML HTML (Hypertext Markup Language) je štandardný jazyk pre tvorbu hypertextových dokumentov, spracovávaný konzorciom W3C (3). HTML umožňuje (28): publikovať online dokumenty s hlavičkami, textami, tabuľkami, fotkami, atď. získavať online informácie cez hypertoxtové odkazy jedným klikom navrhovať formuláre pre riadenie transakcií vzdialených služieb, hľadať informácie, robiť rezervácie, objednávať produkty zahrnúť videá, obrázky, zvukové nahrávky a iné aplikácie do dokumentov Obrázok 11: Ukážka HTML kódu (Zdroj 27) CSS Prvá verzia CSS (Kaskádové štýly, Cascading Style Sheets) pochádza z roku 1996, kedy bola uvedená spoločne s HTML 4.0. CSS je jazyk pre popis prezentácie webových stránok vrátane farieb, základného rozloženia stránky a písma. CSS je nezávislý na HTML a je možné ho použiť s ľubovoľným značkovacím jazykom založeným na XML (10, 28). 29

30 Hlavnou výhodou používania CSS je oddelený vzhľad stránky od jej obsahu je jednoducho modifikovateľný, môže byť definovaný centrálne pre celú množinu stránok, má jednotný spôsob definície štýlu pre všetky elementy (2). Obrázok 12: Ukážka CSS kódu (Zdroj 27) JavaScript JavaScript je programovací jazyk, ktorý sa využíva pri návrhu webových stránok a zapisuje sa do HTML kódu. Kód v JavaScipte je klientský skript, čiže je vykonaný až na strane klienta (webový prehliadač) (14). Charakteristiky JavaScript-u (14): interpretovaný jazyk nie je nutné kompilovať objektový jazyk využíva objekty prehliadačov a zabudované objekty závislý na prehliadači funguje len v prehliadačoch citlivý na veľkosť písmen (case sensitiv) Obrázok 13: Trojvrstvý model moderného webového vývoja (Upravené podľa 5, s. 36) 30

31 1.5 Metódy použité pri analýze firmy SWOT analýza Cieľom SWOT analýzy je určiť, do akej miery je súčasná stratégia firmy a jej špecifické silné a slabé miesta schopné prekonať zmeny, ktoré nastávajú v prostredí. Skratka SWOT vznikla z prvých písmen štyroch anglických slov: strengths silné stránky, weaknesses slabé stránky, opportunities vonkajšie príležitosti a threats hrozby (13, 18). SWOT analýza slouží k základní identifikaci současného stavu podniku sumarizuje základní faktory působící na efektivnost marketingových aktivit a ovlivňující dosažení vytyčených cílů. (12, s. 46) Ak podnik analyzuje svoje vnútorné stránky, jedná sa o SW analýzu, ak podnik rozoberá len faktory vonkajšieho prostredia, čiže rozbor príležitostí a ohrození, jedná sa o OT analýzu. Nevýhodou SWOT analýzy je, že je statická a veľmi subjektívna (12). Pre bližšiu identifikáciu vnútornej analýzy spoločnosti sa využívajú ďalšie známe nástroje ako model 7 S (strategy stratégia, structure štruktúra, systmes systémy riadenia, styl štýl managerskej práce, staff spolupracovníci, skills schopnosti, shared values zdieľané hodnoty). Pre vonkajšiu analýzu analýzu okolia podniku, je možné použit SLEPT analýzu, Porterovú analýzu, Marketingový mix 4 P (product produkt, price - cena, place miesto predaja, promotion marketingová komunikácia) a iné. Zo získaných poznatkov je možné zkonštruovať SWOT analýzu (13, 17). 31

32 2 Analýza problému a súčasnej situácie Analýza súčasného stavu spoločnosti je veľmi dôležitá pre nasledujúci návrh a tvorbu informačného systému. Je potrebné zhodnotiť vývoj spoločnosti, úroveň informačných technológií vo firme a dbať na požiadavky spoločnosti. 2.1 Popis spoločnosti Základné údaje o firme (26) Názov firmy: Sdur, s.r.o. Sídlo firmy: Piaristická 269/36, Trenčín Právna forma firmy: Spoločnosť s ručením obmedzeným Predmet činnosti: kúpa tovaru na účely jeho predaja konečnému spotrebiteľovi /maloobchod/ alebo iným prevádzkovateľom živnosti /veľkoobchod/ sprostredkovateľská činnosť v oblasti obchodu sprostredkovateľská činnosť v oblasti služieb administratívne služby reklamné a marketingové služby organizovanie kultúrnych a iných spoločenských podujatí organizovanie kurzov a seminárov Obrázok 14: Logo Sdur, s.r.o. (Vlastné spracovanie) 32

33 2.1.2 Vznik firmy Firma Sdur, s.r.o. vznikla dňom zápisu do Obchodného registra SR, t. j Konateľka spoločnosti založila firmu za účelom vybudovania umeleckej agentúry (ďalej len agentúra), ktorá bude zastupovať nielen hudobníkov slovenského a zahraničného trhu, ale aj sprostredkovávať koncerty klasickej hudby Vnútorná analýza spoločnosti Dlhodobým cieľom spoločnosti je usporadúvať medzinárodné koncerty pre širokú verejnosť a podporovať mladých nádejných umelcov. K priblíženiu sa k tomuto cieľu, poriada koncerty, na ktoré pozýva známych umelcov, aby prilákala stále viac poslucháčov a tým prispela k rozširovaniu kultúrneho povedomia. Agentúra sa v nedávnej dobe rozhodla pre vytvorenie stránok, na ktorých sú aktuálne infromácie o podujatiach, prehľad spolupracujúcich umelcov a reklamná plocha pre obchodných partnerov. Organizačná štruktúra spoločnosti je jednoduchá, keďže spoločnosť patrí medzi mikro podniky, tvorí ju konateľka spoločnosti a traja externí spolupracovníci: účtovníčka, dvaja asistenti. Konateľka spoločnosti konzultuje so svojimi asistentami dôležité rozhodnutia podľa zamerania ich schopností. Tieto rozhodnutia vyhodnocujú spoločne a sú prijímané demokratickou formou. Keďže pracovný tým pozostáva z troch ľudí, ktorí si vyhovujú nielen po stránke pracovnej, ale aj osobnostnej, pracovné prostredie je v priateľskej atmosfére. Tým sa odbúravajú komunikačné problémy a agentúra sa zameriava na úspešné naplňovanie svojich cieľov. Medzi silné stránky spoločnosti patria výnimočné schopnosti konateľky, má vynikajúce organizačné schopnosti a vie spolupracovníkov pozitívne motivovať k spoločnej práci. Informačný systém v elektronickej podobe firma nemá. Komunikácia so spolupracovníkmi prebieha telefonicky, prostredníctvom ov a osobnými stretnutiami. Dôležité údaje, kontakty a poznámky sú ukladané v papierovej podobe. 33

34 2.1.4 Vonkajšia analýza spoločnosti Aj keď je v oblasti pôsobenia agentúry (klasická hudba) jmenšia konkurencia, vstup na trh je veľmi náročný kvôli zvláštnym konkurenčným praktikám - veľký boj o knowhow, ktorý je v tejto oblasti kopírovateľnejší ako možno v iných oblastiach. Túto pozíciu nezľahčuje tiež prístup neochota úradníkov kultúrnych inštitúcii pri spolupráci na jednotlivých podujatiach. So svojími obchodnými partnermi spolupracuje buď formou poskytnutia reklamy alebo bartrovým obchodom. Medzi dodávateľov patrí marketingová spoločnosť, ktorá zabezpečuje reklamu a predaj vstupeniek cez svoj internetový portál. V prípade nevýhodnejších obchodných podmienok, agentúra má možnosť nahradiť dodávateľov inými, s výhodnejšími podmienkami. Agentúra má dva typy odberateľov: umelci, ktorých zastupuje a účinkujú na podujatiach a záujemci o podujatia. Mohlo by sa zdať, že vzhľadom na menšiu konkurenciu v oblasti klasickej hudby bude záujem o koncerty zo strany poslucháčov vysoký. S uvážením k nízkemu kultúrnemu povedomiu dnešnej doby, o zabezpečenie účasti poslucháčov na koncertoch sa aktívne zasluhuje aj tým agentúry. Umelci, ktorí spolupracujú s agentúrou sa rozdeľujú na umelcov s exkluzívnym zastúpením na Slovensku a umelcov, ktorí sú pozývaní na konkrétne koncerty SWOT analýza Agentúra má veľa silných stránok, ktoré sú v obore jej činnosti kľúčové a radia ju do popredia medzi konkurenciou. Pri analýze spoločnosti neboli zistené iné slabé stránky, vzhľadom na mladú a rozvíjajúcu sa firmu, táto skutočnosť ale nemá vplyv na porovnávanie s inými dlhšie pôsobiacimi firmami v tejto oblasti poskytovania služieb. Postupom času by bolo vhodné pre agentúru, aby prenikla aj do zahraničia a naopak, aby prilákala zaujímavých zahraničných umelcov. Dôležitou skutočnosťou pre spoločnosť je hrozba zrušenia koncertu, čo môže nastať ochorením účinkujúceho umelca alebo inou nešťastnou alebo nepredvídateľnou udalosťou. Zrušený koncert je obtiažne nahradiť, v takomto prípade je agentúra povinná vrátiť peniaze záujemcom o koncert. Na obrázku 15 sú podrobnejšie rozpísané silné a slabé stránky spoločnosti, jej príležitosti a hrozby. 34

35 Obrázok 15: SWOT analýza spoločnosti Sdur, s.r.o. (Vlastné spracovanie) 2.2 Zhodnotenie informačných technológií firmy Pre agentúru, ktorá sprostredkováva koncerty a iné akcie, nie sú až tak nevyhnutné pokročilé a moderné technológie. Dôležitý je kontakt so sponzormi, umelcami, prípadne vlastníkmi priestorov, kde sa podujatie koná, a je možné komunikovať buď telefonickým spojením, alebo výmenou ov. Toto kritérium spĺňa domáci počítač s prístupom na internet Hardware a software Firma je pomerne mladá a nemôže vynakladať vysoké výdavky na informačné technológie, a preto je veľkou výhodou, že pre prácu sú postrádateľné výkonné technológie. Konateľka spoločnosti pre prístup na internet a prípadnú komunikáciu používa notebook značky Lenovo X61s. Pre vytvorenie základných potrebných dokladov je využívaný Microsoft Office 2007 na operačnom systéme Windows Vista. V súčasnej dobe firma využíva papierovú formu databázového systému. 35

36 2.2.2 Webové stránky firmy V rámci praxe boli firme vytvorené webové stránky, ktoré majú informačný a propagačný charakter. Na webových stránkach môžu návštevníci nájsť základné informácie o spoločnosti, kontakty na zodpovedné osoby, mená zastupovaných umelcov, ich životopisy, fotogalériu, hudobné nahrávky a zoznam skladieb, ktoré jednotliví umelci ponúkajú na podujatiach. Stránky sú pravidelne aktualizované - pridávajú sa informácie o pripravovaných koncertoch a o nových zastupovaných umelcoch. Hlavnou nevýhodou webových stránok pre konateľku spoločnosti je, že bez znalostí programovacieho jazyka nedokáže sama upravovať webové stránky, teda aj pridávať nové informácie a musí kontaktovať tvorcu stránok, čím sa oneskorujú aktuálne informácie. 2.3 Popis súčasnej situácie informačných technológií Ako som už spomínala, vo firme je vedená papierová forma databázového systému. Pre každý atribút entity spoločnosti (umelci, podujatia, obchodný partneri, účtovníctvo) je vedená jednotlivá zložka. Za rok pôsobenia spoločnosti nie je množstvo jednotlivých zložiek veľké, avšak pri rozšírení agentúry o ďalších umelcov, koncerty a obchodných partnerov môže byť množstvo zložiek neprehľadné a nebude jednoduché sa v nich orientovať Údaje o umelcoch Pre každého umelca, ktorý je zastupovaný agentúrou, je vytvorená zložka, do ktorej sa zakladajú zmluvy o zastúpení, základné údaje o umelcovi a životopis. Životopisy umelcov sú využívané pri poskytovaní informácií o ich činnosti na webových stránkach alebo do jednotlivých prezentácií Údaje o podujatiach Zložky s jednotlivými podujatiami musia obsahovať zmluvy na prenájom priestorov, prípadne ozvučenia, zmluvy s účinkujúcimi, objednávky a faktúry týkajúce sa podujatia. 36

37 2.3.3 Údaje o obchodných partneroch Medzi dôležité údaje o obchodných partneroch, ktoré musia byť založené v zložke sú zmluvy o spôsobe spolupráce, prípadne poskytnutí sponzorského daru. Ďalej je potrebné založiť údaje o firme, ktorá spolupracovala s agentúrou a o kontaktnej osobe v danej firme. 2.4 Zhodnotenie analýzy Dlhodobým cieľom spoločnosti je usporadúvať medzinárodné koncerty pre širokú verejnosť a podporovať mladých nádejných umelcov. Podľa súčasnej situácie sa firme darí ciele úspešne plniť. V SWOT analýze bolo zistených veľa silných stránok, ktoré by mohli do budúcnosti napomôcť firme dostať sa do popredia agentúr aj v zahraničí. Hrozby spoločnosti sú neovplyvniteľné a, bohužiaľ, v budúcnosti môžu nastať. Pre firmu je potrebné vytvoriť informačný systém intuitívne ovládateľný a zároveň musí spĺnať požiadavky spoločnosti. Tento informačný systém agentúre zjednoduší spravovanie dôležitých dát a webových stránok. 37

38 3 Návrh riešenia V tejto kapitole popisujem postup návrhu informačného systému podľa požiadaviek spoločnosti a jeho následnú implementáciu. Informačný systém je navrhnutý vo forme webovej aplikácie, ktorá je rozdelená na časť verejnú (ďalej tiež webová prezentácia) pre návštevníkov webu a časť internú pre správu dát spoločnosti, kam majú prístup len zamestnanci. Pre modelovanie požiadaviek na systém je použitá metóda jazyka UML, presnejšie prípady užitia (Use Case) a vývojové diagramy funkčného modelovania. Tieto metódy modelovania systému sú vybrané kvôli prehľadnosti ako pre návrhára systému, tak pre užívateľov systému, ktorí kladú požiadavky. Databáza, ktorú používa informačný systém, je navrhnutá podľa procesu SDLC. 3.1 Požiadavky spoločnosti na informačný systém Informačný systém spoločnosti bude mať okrem spolupracovníkov ďalší typ užívateľa (tiež užívateľ systému), a to návštevníkov webu. Pri návrhu informačného systému je nutné prihliadať na požiadavky týchto užívateľov Požiadavky firmy Hlavnou požiadavkou konateľky spoločnosti je vytvoriť systém, ktorý nebude náročný na obsluhu. Je potrebné vkladať informácie o klientoch zastupovaných umelcoch a aktuality ohľadne plánovaných podujatí bez nutnej znalosti programovacieho jazyka pre tvorbu webových aplikácií. Ďalšími požiadavkami sú základné funkcie informačného systému vkladanie, mazanie a údržba dát o spolupracovníkoch (ďalej pomenované ako zamestnanci), klientoch, partneroch spoločnosti v databáze; zložitejšie funkcie informačného systému: možnosť pridelovania činností jednotlivým zamestnancom, následná kontrola termínov. 38

39 3.1.2 Požiadavky návštevníkov webu Hlavnou požiadavkou návštevníkov webu, ktorých chce spoločnosť prilákať, je pohodlné prijímanie informácií o konaných akciách a ponúkaných službách agentúry. Preto informačný systém musí poskytovať aktuálne informácie o konaných podujatiach a účinkujúcich. Informačný sytém musí umožňovať prípadné slovné ohodnotenie podujatí, ktorých sa zúčastnia návštevníci. 3.2 Use Case diagram Na Obrázku 16 sú zobrazené role a prípady použitia informačného systému, ktoré boli identifikované podľa požiadaviek spoločnosti. Rola s najnižšími právami Návštevník webu má prístup iba do verejnej časti informačného systému a môže tak zobrazovať informácie o podujatiach, životopisy klientov agentúry, fotky, videá a zvukové nahrávky klientov a podujatí. Tieto údaje je možné vkladať, upravovať alebo mazať z interného informačného systému, ktoré však spravujú zamestnanci firmy. Zamestnanci firmy majú práva ako návštevníci webu a z verejnej časti systému sa môžu prihlásiť do internej časti systému. Po zadaní login-u a užívateľského hesla je im sprístupnený ich účet internej časti informačného systému. Rolu s vyššími právami tvorí Administrátor. Ten má rovnaké práva a možnosti ako Zamestnanec. Administrátor má ďalej možnosť spravovať zamestnanecké účty internej časti informačného systému, priradzovať práva zamestnancom, spravovať vložené záznamy a iné dôležité úkony, ktoré nie sú sprístupnené zamestnancom. Konateľka spoločnosti má, samozrejme, rovnaké práva ako administrátor. 39

40 Obrázok 16: Use Case diagram informačného systému (Vlastné spracovanie) 40

41 3.2 Konceptuálny návrh databázy Vo fáze konceptuálneho návrhu databázy sú identifikované základné entity a relácie medzi nimi. Pre agentúru je dôležité ukladať a spravovať dáta o klientoch, ktorých zastupuje, o firmách a zamestnancoch, s ktorými spolupracuje a o podujatiach, ktoré organizuje. Ďalšie entity sa odvíjajú od týchto hlavných entít a od činnosti spoločnosti. Na Obrázku 17 je zobrazený základný ER diagram obsahujúci zistené entity a relácie. Základné entity: ZAMESTNANCI, KLIENTI, FIRMY, PODUJATIA, KONTAKTNÉ OSOBY, ČINNOSTI, SPONZORSKÉ DARY, RECENZIE a ZMLUVY bude nutné v nasledujúcej fázy normalizovať, hlavne entity v M:N vzťahu. V Tabuľke 1 sú rozpísané zistené entity, ich popis a výskyt v súčasnosti, v Tabuľke 2 sa nachádza datový slovník entít: rozpísané entity, relácie a ich multiplicity. Obrázok 17: ER diagram konceptuálny návrh (Vlastné spracovanie) 41

42 Tabuľka 1: Datový slovník entít (Vlastné spracovanie) Tabuľka 2: Obmedzenie multiplicity pre relácie IS Sdur, s.r.o. (Vlastné spracovanie) 3.3 Logický návrh databázy Pri logickom návrhu databázy sa vychádza zo základného ER diagramu spracovaného vo fáze konceptuálneho návrhu databázy. V tejto fáze sú identifikované atribúty entít a pomocou normalizácie sú vytvorené ďalšie entity ER diagramu: VIDEA, ZVUKOVE_SUBORY, GALERIA_FOTKY, entity vzniknuté normalizáciou M:N väzieb: PODUJATIE_KLIENTI, CINNOSTI_ZAM, CINNOSTI_FIRMY a číselníky: C_STAV_VSTUPENIEK, C_STAV_PODUJATIA, C_STAV_SPONZOR_DAR, C_TYP_CINNOSTI, C_STAV_CINNOSTI. Konečný ER diagram je zobrazený na obrázku 18, datový slovník atribútov entít je umiestnený v Prílohe 1. 42

43 C_STAV_VSTUPENIEK PODUJATIA RECENZIE C_STAV_SPONZOR_DAR PK ID_Stav_Vstup Nazov C_STAV_PODUJATIA PK ID_Stav_Pod Nazov PK ID_Podujatie Nazov Popis Miesto Datum_Od Datum_Do Cas_Harmonogram Cennik Zhodnotenie FK1 ID_Stav_Vstup FK2 ID_Stav_Pod PODUJATIE_KLIENTI PK,FK1 ID_Podujatie PK ID_Recenzia Datum Popis Alias PK ID_Stav_Dary SPONZORSKE_DARY PK ID_Dar Nazov Popis Nazov Popis Suma FK2 ID_Stav_Dary FK1 ID_Podujatie FK3 ID_Firma PK,FK1 ID_Podujatie PK,FK2 ID_Klient CINNOSTI PK ID_Cinnost VIDEA PK ID_Video Popis Datum_Vlozenia Nazov_Suboru FK1 ID_Klient ZVUKOVE_SUBORY PK ID_Z_Subor KLIENTI PK ID_Klient Meno Priezvisko Titul Nazov_Zdruzenia Zivotopis Ulica Mesto PSC Stat Telefon Cislo_Bank_Uctu C_STAV_CINNOSTI PK ID_Stav_Cinnosti Nazov Popis Datum_Od Datum_Do Zhodnotenie FK2 ID_Typ_Cinnosti FK1 ID_Podujatie FK3 ID_Stav_Cinnosti CINNOSTI_ZAM PK,FK1 ID_Cinnost PK,FK2 ID_Zam Popis Datum_Vlozenia Nazov_Suboru FK1 ID_Klient GALERIA_FOTKY ZAMESTNANCI PK ID_Zam PK ID_Fotka Popis Datum_Vlozenia Nazov_Suboru FK3 ID_Firma FK2 ID_Podujatie FK1 ID_Klient Meno Priezvisko Titul Fotka Rodne_Cislo Ulica Mesto PSC Stat Telefony Cislo_Bank_Uctu Login_IS_Ucet Heslo_IS_Ucet Obrázok 18: ER diagram logikcý návrh databáze (Vlastné spracovanie) 43 FIRMY PK ID_Firma Nazov Sidlo Stat ICO Telefon Prezentacia Poznamka CINNOSTI_FIRMY PK,FK1 ID_Cinnost PK,FK2 ID_Firma C_TYP_CINNOSTI PK ID_Typ_Cinnosti Nazov Popis EVIDENCIA_ZMLUV PK ID_Zmluva Datum_Od Datum_Do Nazov_Suboru Umiestnenie_sklad FK2 ID_Firma FK3 ID_Zam FK1 ID_Klient KONTAKTNE_OSOBY PK ID_Kontakt Meno Priezvisko Titul Telefon Poznamka FK1 ID_Firma

44 3.4 Fyzický návrh databázy V tejto časti sú navrhnuté tabuľky databázy, s ktorou bude pracovať informačný systém agentúry a model frameworku Rails, ktorý umožňuje, aby aplikácia pracovala s danou tabuľkou. Pomocou príkazu, ktorého príklad je zobrazený na Obrázku 19 sú ďalej vytvorené pohľady tvoriace užívateľské rozhranie a radič, ktorý riadi aplikáciu. Obrázok 19: Ukážka vytvorenia tabuliek: vytvorenie tabuľky Recenzie (Vlastné spracovanie) Postupne sú vytvorené všetky tabuľky databázy, v súboroch sú zvolené primárne a cudzie kľúče a obmedzenia. Na Obrázku 20 je ukážka súboru s informáciami o migráciach tabuľky Recenzie a zvolenom primárnom kľúči a Obrázok 21 je ukážkou súboru modelu tabuľky Recenzie. V súbore modelu tabuľky Recenzie bola pridaná informácia o primárnom kľúči, ktorý tvorí atribút ID_Recenzie, o zvolenom cudzom kľúči ukazujúcom do tabuľky Podujatia a o obmedzeniach datových typov a ďalších obmedzeniach. Ďalšie tabuľky sú umiestnené na priloženom CD v Prílohe 2. 44

45 Obrázok 20: Ukážka súboru is_sdur/db/migrate/ _create_recenzies.rb (Vlastné spracovanie) Obrázok 21: Ukážka súboru is_sdur/app/models/recenzie.rb (Vlastné spracovanie) 45

46 3.5 Modelovanie systému V priebehu návrhu vývojových diagramov som rozdelila priebeh systému do základných procesov a podprocesov ako ukazuje Obrázok 22. Ako prvé, každý návštevník webu, či užívateľ systému uvidí webovú prezentáciu firmy, cez ktorú sa dá prihlásiť do svojho účtu. Každý užívateľ s prístupovými údajmi sa po prihlásení môže rozhodnúť pre správu klientov, zamestnancov, firmy, podujatí, činností alebo správu svojho účtu. Ďalšie vývojové diagramy podrobnejšie modelujú jednotlivé podprocesy sytému.!"#$%&'(")* +,+-.& / * 819:;<* =01>1?@AB4CD I?: EFG$HI* /%FJF"-IK!' "41 /05B:;57*L* 6A@5M4* L=:3:N?:L@4D I?: /%!OPI+F"!F*Q$*!"-F%"FR*('+-!*!+ /05B:;57*L*6A@5M4* SP!F"-$HD I?: +/%IH'* SP!F"-$H "41 /05B:;57*L*6A@5M4* J'&F+-"'"K$HD I?: +/%IH'* J'&F+-"'"K$H "41 /05B:;57*L*6A@5M4* #!%!F&D I?: +/%IH'*#!%!F& "41 /05B:;57*L*6A@5M4* /$QTR'-UD I?: +/%IH'* /$QTR'-U "41 T=05;:;57* (!""$+-UD I?: +/%IH'* (!""$+-U "41 +=05;:;57*L;:W* <N1@D I?: V(F- J'&F+-"'"K' "41 $623AL1?41*>:* LXL@YMC S$"!FK Obrázok 22: Vývojový diagram informačného systému (Vlastné spracovanie) 46

47 3.5.1 Webová prezentácia Proces webová prezentácia umožňuje užívateľovi systému buď sa prihlásiť do internej časti informačného systému, v prípade, že má prístupové práva, alebo prehliadať webovú prezentáciu verejnú časť informačného systému. Užívateľ si môže pri prehliadaní webových stránok zobraziť podujatia, prípadne k uskutočneným podujatiam vložiť recenziu alebo prehliadať vložené recenzie od iných užívateľov, ďalej môže nahliadnúť na cenník a časový harmonogram podujatia a zobraziť sponzorov (tiež obchodných partnerov). Na webových stránkach je možné prehliadať fotogalériu, spúšťať zvukové záznamy a videá a zobraziť informácie o klientoch umelcoch zastupovaných agentúrou.!"#$%&' ()"*"+,&-./ (25?@AB56'B3'80' 9CDE3;<>BF<:'G3B;5'.H= &O0 ().IJ&H"+."' K$'.+,")+"L' M/H,.'.H X +5< * ' 7089:3;5<= &O0 %0>13' 7089:3;53 * ' 7089:3;5< * ' 2<N<O45<= &O0 )<N<O45<' 7089:3;53 * ' 2<N<O45< +5< * ' S0;0T3@U259= &O0 Z0;F[' 7089:3;D\' F@5<O;0E +5< %@0C56'2<N<O459= +5< &O0 *3836'3@53B' OAEP;<EODF3' Q<19'3';<R;' 2<N<O45< * 'N<OODF' 7089:3;53= &O0 %Y1<2' N<OODF9' * 'N<OODF' 7089:3;53 * 'S0;F[ +5< +5< * 'G3BV'?32W0O0T23W' 7089:3;53= &O0 %Y1<2'G3BV'?32W0O0T23W9 * 'G3BV'?32W0O0T23W +5< * ' B70O4020E= &O0 H70O4025' 7089:3;53 * ' B70O4020E +5< * 'F@5<O;3= &O0 %0>13'F@5<O;3 H79B;56'E58<0= &O0 * 'E58<0' F@5<O;3 +5< +5< H79B;56'4E9F0EY' B]102= &O0 H79B;56'4E9F0EY' B]102'F@5<O;3 X$+."- +5< Obrázok 23: Vývojový diagram webová prezentácia (Vlastné spracovanie) 47

48 3.5.2 Prihlásenie do internej časti IS Do internej časti informačného systému agentúry sa môžu prihlásiť iba užívatelia s prístupovými právami a to: konteľka spoločnosti, spolupracovníci a administrátor IS. Pre prístup do tejto časti IS musí mať každý užívateľ login a heslo. V prípade zabudnutia hesla je možnosť požiadať administrátora o zmenu hesla.!"#$%&'()#(*+,* #)-(")(.*/0'-#*#' * 78954:;*2* <6=72* ;>?@2A6B2 &48,@6C6456* =DCE@48=A5* DC5<72=8@2F?F<* G32H8@ 'G*I2324J*3EA2* =DCE@46K )56 'NG=5L*6RA6*C2IK &48 )56!C5<7E=6456*38* ;>?@2A6B=NJ<8*GO;!8>5232L* 23M545=ACEA8C2*8* IM64;*DC5<72=8@2F?F<* G32H8@K 12=72456*D8>5232@N;* 8*IM64;* DC5<72=8@2F?F<* G32H8@ P,)#(Q )56 Obrázok 24: Vývojový diagram prihlásenie (Vlastné spracovanie) Správa klientov Pre správu klienta je nutné na začiatok zadať údaje klienta, podľa ktorých má systém dotyčného umelca vyhľadať v databáze. Ak systém nenašiel klienta, užívateľ má možnosť vytvoriť nový záznam klienta. Tento klient pri zápise jeho údajov do informačného systému musí mať podpísanú zmluvu o zastupovaní agentúrou. Táto zmluva je naskenovaná a vložená do databázy. Ak systém záznam hľadaného klienta našiel, užívateľ má možnosť zmeniť a vymazať záznam klienta, vložiť nový alebo vymazať starý súbor (videá, fotky, zvukové súbory), prípadne tieto súbory zviditeľniť na verejnej časti IS. Ďalej užívateľ systému môže priradiť klienta k podujatiu ako účinkujúceho na danom koncerte alebo v prípade ukončenia spolupráce agentúry s klientom, zmazať záznam klienta. 48

49 SPRÁVA KLIENTOV 82D<+# $%&'()+!"#$%&'()# *"*(+,- 7&' 86)02=&:# *"*(+,# $%&'()+.,%/0+#$%&'()+ 1234&5#*,%/06 C(2.,'(&:#*"*(+,- C(2 F4=+0&:#*"*(+,# $%&'()+ 720E#*"*(+,# *,%/06 7&' 8%29&:#5;<2=6- C(2 720E#*"*(+,# 5;<2=/.0&3&)'D(&:#(+# G'<20'H# 4='*'()"I&&- C(2.0&3&)'D(&:#5;<2=6# 4='#("0J)'0(K$20# G'</ 7&' 7&' 86,+*+:# 5;<2=6- C(2.=/J'(&'# *"*(+,/#5;<2=/ 7&' 123/H+)&+# 4=&=+3'(L# $%&'()20&!"#4=&=+3'(L# 423/H+)&'- C(2.2<=+*&:# 423/H+)&+# $%&'()+- C(2.2<=+*&:# 423/H+)&+#$%&'()+ 7&' 7&'.=/J&:#423/H+)&'# $%&'()+- C(2 82D<+# 423/H+)&+.=/J'(&'# 4=&=+3'(&+# 423/H+)&+#+# $%&'()+ 7&' 1=&=+3&:# 423/H+)&'- C(2 82D<+# 423/H+)&+ 720E#*"*(+,# 4=&=+3'(&+# 423/H+)&+#+# $%&'()+ 7&'.=/J&:#*"*(+,# $%&'()+-!")'# C(2 C(2 24="0('(&'-.=/J'(&'# *"*(+,/ 7&' 7&' Obrázok 25: Vývojový diagram správa klientov (Vlastné spracovanie) 49

50 3.5.4 Správa zamestnancov Pre väčšinu činností v tomto podprocese má práva administrátor a konateľka spoločnosti. Administrátor môže vytvoriť záznam zamestnanca, tiež ho môže vymazať. Pri vytvorení nového záznamu je nutné vložiť naskenovanú zmluvu do databázy pre lepšiu orientáciu vo všetkých zmluvách. Administrátor pre nového zamestnanca vytvorí účet v systéme a priradí mu login a heslo, ktoré by mal zamestnanec neskôr zmeniť. Zamestnanec môže upravovať svoje údaje v systéme, k ostatným záznamom spolupracovníkov nemá prístup. Jednotlivým zamestnancom sa priradzujú činnosti, ktoré rozčleňujú podujatie na menšie procesy a zamestnanci majú možnosť ich skontrolovať (termín dokončenia, stav, atď). SPRÁVA ZAMESTNANCOV I.JK&# $&'/-0%&%1&!"#$"$%&'( 75/ 7.,L#$"$%&'# $&'/-0%&%1& )'*+,&#-.# $&'/-0%&%1.' #$'*+,6 7.,L#$"$%&'# $'*+,6 H%.!"#,60,.?/%L# NA/0( 75/ I60,.?/%5/#NA0+# $&'/-0%&%1&O#,60,.?/%5/##*.P5%Q+#&# R/-*& )"45-#*.P5%Q+#&# R/-*& )&-*&%5/# 5%S.?'&A%TR.# /'&5*+# $&'/-0%&%1.,5#-# 4.U5&3&,>.'#.# $'/%+#R/-*& H%. M4?&,5@#$"%$&'( H%. M4?&,5@#$"%$&'# $&'/-0%&%1& 75/ =>.%0?.*.,&@# A5%%.-05( H%. 897BC9DE# 8.%0?.*&#A5%%.-0W F:779=BG 75/ 2?5?&35@#A5%%.-@( H%. =2CHIE# F:779=BG 75/ )?+V5@#$"$%&'( H%.!"0/#.4?",%/%5/( H%. )?+V/%5/# $"$%&'+ )?+V/%5/#NA0+#&# $&-*&%5/# 5%S.?'&A%TR.# /'&5*+ 75/ 897:;< Obrázok 26: Vývojový diagram správa zamestnancov (Vlastné spracovanie) 50

51 3.5.5 Správa firiem Na začiatku podprocesu správy firiem je užívateľ požiadaný o zadanie údajov o firme, podľa ktorých je firma vyhľadaná v databáze. V prípade, že záznam nie je nájdený, má užívateľ možnosť zadať nový záznam firmy. Po vytvorení záznamu firmy musí užívateľ vyplniť kontaktnú osobu danej spoločnosti, s ktorou bude agentúra prevažne komunikovať. Tieto záznamy je možné zmeniť, prípadne doplniť ďalšiu kontaktnú osobu. Informačný systém umožňuje vkladať súbory firiem (väčšinou logo firmy), priradiť firmy k jednotlivým činnostiam, na ktorých spolupracujú s agentúrou. Zmazať súbor firmy pri ukončení spolupráce má možnosť užívateľ s vyššími právami a to administrátor alebo konateľka spoločnosti. Vývojový diagram tohto podprocesu je zobrazený na Obrázku Správa podujatí Obrázok 27 Užívateľ systému musí pri správe podujatí vyhľadať dané podujatie, ktoré bude chcieť upravovať. V prípade, že podujatie neexistuje, je potrebné zadať údaje nového záznamu. K vytvoreným podujatiam je možné pridávať činnosti, a tým rozložiť proces organizácie podujatia na čiatkové činnosti. Každé podujatie má účinkujúcich v databáze pomenovaných ako umelci, ktorých ak užívateľ systému chce priradiť k podujatiu, musí prejsť na správu klientov. Na správu klientov musí prejsť tiež, ak chce upraviť účinkujúcich podujatia. Pri ukončení alebo prerušení organizácie podujatia je možné zmeniť stav podujatia. Tento podproces je zobrazený na Obrázku

52 SPRÁVA PODUJATÍ!"#$%& '"()*%+,% -.,/+)*0&1213%4& '"()*%+,%5 6,0 6"78&1213%4& 9':%7,;&1213%4& 9':%7,;&1213%4& '"()*%+,% 6,0 BC66D>EF 6,0 <:,:%(,;& G=,3H)*GI,IJ& 9':%7,;&1213%4& '"()*%+,% OPC-6ED! 6,0 N403,;& OPC-6ED! 6,0 N403,;&/+%7& 9':%7,;&1213%4& '"()*%+,% 6,0 OD6C-Q Obrázok 27: Vývojový diagram správa podujatí (Vlastné spracovanie) Správa činností Správa činností je zobrazená na Obrázku 29. Pri vytvorení novej činnosti, musí užívateľ zadať zodpovednú osobu za danú činnosť, túto osobu zamestnanca je možné neskôr zmeniť. Jednotlivé činnosti môžu byť spojené s firmami, ktoré spolupracujú s agentúrou. V takom prípade užívateľ musí k činnosti priradiť aj firmu. V zázname činnosti je nutné zadať stav činnosti (prebieha/ukončená/...) a typ činnosti (marketing/sponzoring/...). 52

53 SPRÁVA FIRIEM H0IG(# $%&'5!"#$%&'(# )")*('+,%-,0<J#)")*('# $%&'5,0<J#)")*('# 20*F(2F*-K# 010G5 >*0 ;/&(<%=#)")*('# $%&'5+ >*0 ;/&(<%=# )")*('#$%&'5,%- ;/&(<%=#)")*('# 20*F(2FT#010G5+ >*0 ;/&(<%=# )")*('# 20*F(2FT#010G5,%- HC0V%=#1LG0&+,0<J#)")*('# 1LG0&A,%-!"#/&%&(4-*L# B%**01=+.20*F&0C0<(=# >*0 >*0 B%**01F%+ 60*F&0C(#B%**01FW,%-,%-,%- M&AN%=#B%**01=+ >*0.DO>HP# Q8,,7.RS E-#/0F&-G*"# )'CA<(+ D&%&(4%=#B%**01=+ >*0 >*0,%-,0<J#)")*('# )'CA<5 D04/%1#)'CA<5 M'CA<(#1#$%&'0A,%-./0*)0&123# 4(&5+ >*0.DO>HP#.D7,M7OT# UPO7H,%- A20*B%=# >*0 M"/%1#40# /0/%1A#$%&'5,%- M&AN%=#)")*('# $%&'5+ >*0!"F-# 0/&"<*-*%-+ >*0 M&AN-*%-# )")*('A 67,89:,%-,%- Obrázok 28: Vývojový diagram správa firiem (Vlastné spracovanie) 53

54 54!"#$%&' ()**+!,- %./01' ' ' :8:41;< *3= :1;=56414=C< $4. :1;=56414C1 *3= D8?35' :1;=56414C1'E' D;=439' :1;=56414C1< $4. :.A?.F=A4GH.' :1;=56414C1'E' $4. I *3= D;=41' :.A?.F=A4GH.' :1;=56414C1 $4. >='?@3@1A=48' J3@;1< *3= %K6F.@=43='?@3@1A=431'J3@;K'E' D@LM39'?@3@1A=43='' E'J3@;=< "@3@1A39'J3@;L< $4. +A56@8439'?@3@1A=43=' J3@;K'E' *3= $4. D8?35'J3@;K'E' ='.?@8F4=43=< $4. %B0=@'J3@;K $4. %B0=@'J3@;K 786='.?@8F4=43=< D8?35'A.'5K56G;L $4. *3= D;=439'561F' < D;=439'6K?' < *3= *3= N+*)OP %./01'561FL' %./01'6K?L' D8?35'561FL' D8?35'6K?L' $4. $4. *3= I *3= D1A143='A86'.' Obrázok 29: Vývojový diagram správa činností (Vlastné spracovanie)

55 3.5.8 Účet zamestnanca Každý zamestnanec spoločnosti, ktorý má vytvorený účet v internej časti informačného systému, môže zvoliť úpravu svojho účtu zmeniť svoj záznam a prístupové údaje, zobraziť činnosti, ku ktorým je priradený alebo zviditeľniť dáta uložené v databáze na verejnej časti informačného systému.!"#$% &'(#)$*'*+' H3DB7% 57,-1<.7.I7% 93@D7% 9:/JK71327I;IJ%?@7432 &,-./0%1234% 565.7,89:;1<=932>%?@74-A M.3 L9:72/0%565.7,% 57,-1<.7.I7 */- &3B:75/0%1234-% C/..31</A M.3 N3.<:3K7%C/..31<; */- &2/@/<-D./0%@6<7%9:-%.62E<-2.;F32%G-B=A M.3 H3DB7%@6<% FK/-.<78 93@=47</7 &2/@/<-D./0%@6<7%9:-%.62E<-2.;F32%G-B= NO*P#+ Obrázok 30: Vývojový diagram účet zamestnanca (Vlastné spracovanie) 55

56 3.5.9 Správa sponzorských darov V prípade, že firma bude chcieť sponzorovať podujatie, užívateľ systému vytvorí nový záznam najskôr v správe činností, kde nastaví typ činnosti na sponzoring a potom v správe sponzorských darov vytvorí nový záznam pre daný sponzorský dar. Cez správu činností je tiež možné zmeniť zodpovednú osobu. V prípade, že záznam pre sponzorský dar už existuje, užívateľ systému môže tento záznam upravovať. V prípade, že firma stratí záujem takýmto spôsobom podporivať podujatie a ponuku zruší, užívateľ systému nezruší záznam, ale zmení položku stav sponzorského daru na zrušený. SPRÁVA SPONZORSKÝCH DAROV 57.8-*+$&9:90,;& 8<&),%*= 3.$ EFG/!H& I4332EJK!"#$%& '()*+,-., /0(!"#$%&8<& ),%* 3(@"&9:90,;&8<& ),%*!"#$%& >.%;? A;$0.B&9:90,;& 8<&),%*= /0( C'%,@.B&9:90,;& 8<&),%* 3.$ A;$0.B&& 9()'(@$)0D& (8(#*= /0( EFG/!H& I4332EJK 3.$ Obrázok 31: Vývojový diagram správa sponzorských darov (Vlastné spracovanie) 56

57 3.6 Výsledná aplikácia Konečná aplikácia je rozdelená na dve časti: interná a verejná. Do internej časti je možné prihlásiť sa s prístupovými údajmi, ktoré majú zatiaľ len zamestnanci. Pri návrhu internej časti informačného systému som použila dizajn Twitter Bootstrap (23), ktorý tvorí Open Source knižnica CSS a JavaScript-u. Kód je pod licenciou Apache License, Version 2.0. Na Obrázku 32 je ukážka internej časi IS, užívateľ v tejto časti vidí zoznam klientov a môže jednotlivé záznamy upravovať, vymazať alebo vytvoriť nové. Dizaj je jednoduchý a štruktúra je navrhnutá podľa požiadaviek spoločnosti. Pre návrh verejnej časti informačného systému som využila stránky spoločnosti Sdur, s.r.o. navrhnuté počas praxe a neskôr využívané (Obrázok 33). Obrázok 32: Ukážka internej časti IS správa klientov (Vlastné spracovanie) 57

58 Obrázok 33: Stránky Sdur, s.r.o. (Vlastné spracovanie) 58