Návrh informačního systému pro vedení evidence pracovníků

Mendelova zemědělská a lesnická univerzita v Brně Provozně ekonomická fakulta

Návrh informačního systému pro vedení evidence pracovníků Bakalářská práce

Vedoucí práce: Ing. Oldřich Trenz, Ph.D.

Kamil Tureček

Brno 2008

Prohlašuji, že jsem tuto bakalářskou práci vyřešil samostatně s použitím literatury, kterou uvádím v seznamu.

V Brně 24. 5. 2008

....................................................

Chtěl bych poděkovat svojí rodině za stálou podporu při studiu a vedoucímu mé práce Ing. Oldřichu Trenzovi, Ph.D. za pomoc s touto prací.

Abstract Kamil Tureček. Layout of information system of records of human resources. Bachelor thesis. Brno, 2008. This thesis is oriented toward the layout of a novel approach to organizing human resources relating to ski and snowboard schools and accompanying ski rentals. The begining of thesis deals with investigation of the current situation, followed by a suggestion of a new solution and its implementation. The whole approach is based on internet environment with client-server principle where all information is stored in relational database. The end of thesis describes a field test and real operation with a final evaluation of the whole project. Klíčová slova: evidence, informační systém, databáze.

Abstrakt Kamil Tureček. Návrh informačního systému pro vedení evidence pracovníků. Bakalářská práce. Brno, 2008. Tato práce se zabývá návrhem nového řešení organizace a evidování pracovníků konkrétní lyžařské školy a půjčovny zimního vybavení. Zkoumá současný stav, navrhuje nové řešení a zabývá se jeho implementací. Celý nový systém je umístěn do prostředí internetu a je založen na principu klient-server kde se na serveru veškeré informace ukládají do relační databáze. Závěr práce popisuje zkušební a ostrý provoz s hodnocením celého projektu. Key words: evidence, information system, database.

4

OBSAH

Obsah 1 Úvod

7

2 Cíl práce

8

3 Rozvoj elektronických aplikací 9 3.1 Prostředky databázových aplikací . . . . . . . . . . . . . . . . . . . . 9 3.2 Uplatnění databázových systémů v prostředí internetu . . . . . . . . 10 4 Metodická východiska 4.1 Databáze . . . . . . . . . . . 4.2 Entita . . . . . . . . . . . . . 4.3 Integritní omezení . . . . . . . 4.4 Vztah . . . . . . . . . . . . . 4.5 Sekvence . . . . . . . . . . . . 4.6 Jazyk SQL . . . . . . . . . . . 4.7 PL/SQL . . . . . . . . . . . . 4.7.1 Procedura . . . . . . . 4.7.2 Funkce . . . . . . . . . 4.7.3 Spoušť . . . . . . . . . 4.8 Databázový systém . . . . . . 4.9 Databázový systém ORACLE 4.10 Jazyk PHP . . . . . . . . . .

. . . . . . . . . . . . .

12 12 12 13 14 14 15 16 16 16 16 17 17 18

. . . . . . . .

20 20 21 21 23 25 26 28 31

6 Diskuse 6.1 Poznatky z praktického využití . . . . . . . . . . . . . . . . . . . . . 6.2 Nevhodné vyústění . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Možnosti dalšího rozšíření . . . . . . . . . . . . . . . . . . . . . . . .

32 32 32 33

7 Závěr

34

8 Slovníček vybraných pojmů

35

9 Literatura

36

5 Vývoj vlastní aplikace 5.1 Aktuální situace . . . 5.2 Požadavky na systém 5.3 Architektura aplikace 5.4 Integritní omezení . . 5.5 Webový přístup . . . 5.6 Uživatelské rozhraní 5.7 Propojení aplikačních 5.8 Shrnutí vývoje . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . komponent . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . . . .

5

OBSAH

Přílohy

37

A Seznam příkazů SQL pro vytvoření entit

38

B Práce se sekvencí

39

6

1

1

ÚVOD

Úvod

Svět se revolucí v Evropě roku 1989 posunul z doby průmyslové do doby informační. .. Robert T. Kiyosaki (Kiyosaki, 1999) Dnešní doba se posouvá mílovými kroky dál a společně s ní i vyspělost lidstva. Veškeré technologie se vyvíjí někdy tak rychle, že se nestačí dostat na trh a jsou překonány nějakou novější. Jak řekl Robert T. Kiyosaki, svět se revolucí v Evropě posunul do doby informační, čímž se změnil v České republice i postoj lidí k práci a to tím, že dostali možnost soukromě podnikat. Podnikáním se lidé snaží získat finanční nezávislost, pasivní příjem či dřívější odchod do důchodu, nicméně jejich firmy se musí neustále vyvíjet a snažit se co nejlépe přizpůsobit trhu a oponovat konkurenci. Dá se říci, že podobnými progresivními změnami jako technologie současné doby prochází i podnikání. Tyto dvě roviny spolu významným způsobem souvisí, všechny komodity podnikání dnes využívají některou z moderních technologií, byť by to byl osobní počítač pro kancelářské potřeby nebo účetnictví. Podobných nástrojů, které provádí postupnou inovaci drobných i větších společností a firem je celá řada, mohou se týkat mobility, výroby, vývoje a dalších. Když se zaměříme na problematiku komunikace nebo organizace je jakýkoliv moderní nástroj obrovskou výhodou, speciálně když je komunikace významnou složkou předmětu podnikání. V současné době je fenoménem veškerého shonu informací a komunikace internet. Je to nejrychlejší informační kanál, který například oproti mobilnímu telefonu nevyžaduje okamžitou účast další osoby k předání informací. Tato práce se bude zabývat inovací komunikace a systému udržování informací drobné společnosti zabývající se výukou zimních sportů a půjčováním zimní výbavy. Organizace provozu společnosti v místě podnikání funguje bez větších problémů. Ovšem razantně pokulhává plánování času pracovníků, především externistů. Každý má jiné dovednosti, jiné jazykové schopnosti a také jinou časovou dostupnost. V momentě, kdy pověřená osoba této společnosti potřebuje pracovníka s konkrétní kvalifikací v konkrétní čas, sáhne po papírovém seznamu jmen s telefonními čísly a mobilním telefonu. Začne obvolávat tyto pracovníky a dotazovat se na jejich dovednosti a volný čas. Tento postup je zdlouhavý a zbytečně časově a finančně náročný. Úkolem práce je tuto situaci změnit a vytvořit informační systém evidence lidských zdrojů. Pomocí nového systému bude komunikace mezi pověřenou osobou a pracovníky mnohem jednodušší a přinese úsporu finančních prostředků i času.

7

2

2

CÍL PRÁCE

Cíl práce

Práce má za cíl realizaci informačního systému evidence lidských zdrojů fungujícího v prostředí internetu. Úvod je věnován nástinu aktuálního stavu a odůvodění potřeby vzniku nového řešení. Nejdříve je nutné vysvětlit, čím se bude evidence lidských zdrojů zabývat a proč se takový informační systém vytváří. Z analýzy současného stavu budou nastíněna nová řešení potřeb všech potenciálních uživatelů, na základě kterých bude zpracována analytická podoba systému, výběr vhodného softwaru a provozního zařízení, kde bude informační systém umístěn. V dalším kroku se bude práce zabývat implementací informačního systému, zkušebním provozem, testováním všech dostupných aplikací a úpravami pro přesnou potřebu všech uživatelů nebo-li takzvané kustomizaci. Diskuse bude konstatovat již funkční systém a jeho provoz s tím, že bude popsáno i několik možných směrů, kam se systém může ubírat, a které praxí prověřené vlastnosti se ukázaly jako silné stránky systému, či které se staly téměř nevyhovujícími nebo dokonce nevyužitelnými. Jedná se o pilotní projekt, který bude v případě zájmu uživatelů dále vyvíjen, rozšiřován a komerčně využit.

8

3

3

ROZVOJ ELEKTRONICKÝCH APLIKACÍ

Rozvoj elektronických aplikací

Počítač a internet se zatím nezabydlely v českých domácnostech v takové míře, jak by bylo ve vyspělém státu ve třetím tisíciletí potřebné a žádoucí. Někteří lidé těmto moderním technologiím ke své škodě zatím na chuť nepřišli. Tento problém se týká seniorů, sociálně slabších nebo mimoměstských obyvatel. Avšak paradoxně ceny počítačových komponentů klesají a tím se i dostupnost výpočetní techniky navyšuje. Dostupnost vysokorychlostního internetu široké veřejnosti je stále větší, ale přesto zatím nelze říci, že zejména s ohledem na cenu mimo velká města je k dispozici všem. Každým rokem samozřejmě přibývá uživatelů domácích počítačů i internetu, na což reaguje celá společnost a vznikají stále nové internetové obchody, rozšiřuje se elektronické bankovnictví, informační systémy, vyhledávací portály, prostředky komunikace a vyjímku v dostupnosti na internetu netvoří ani státní správa. Česká republika je zemí, která se po vzoru EU snaží funkci státní správy převést na jednodušší, rychlejší, provázanější atd. Tento stav nastává díky přechodu na elektronické systémy. Příkladem může být příchod e-governmentu, jehož podstatou je, že úřady neobíhají občané, ale data v elektronické podobě. Podobnou novinkou je také příprava systému elektronických voleb, pomocí kterého budou moci občané volit ze svých domovů. Tento model již úspěšně funguje v Estonsku, Velké Británii nebo Švýcarsku. E-government je příklad dosti složité systémové změny. Kromě technologie je potřeba mít i oporu v zákoně, čímž se stává podobný projekt časově i finančně náročnějším. Podobně dnes reaguje většina firem a institucí, které svoje vnitropodnikové záznamy uchovávají v elektronické podobě a využívají internet jako jeden z významných komunikačních kanálů.

3.1

Prostředky databázových aplikací

První kontakty lidí s pojmem se samozřejmě lišily. Pro někoho tento kontakt znamenal setkání s některým z „desktopových souborovýchÿ databázových prorgramů, např. MS Access, Paradox či FoxPro. Ve většině případů byla celá databáze uložena v jednom souboru a mnohdy dokonce byla v souboru umístěna pouze jedna tabulka. Kromě omezené funkcionality a bezpečnosti je největší nevýhodou nutnost práce s celým objektem dat. Tuto nevýhodu neodstranilo ani vyčlenění funkčních enginů desktopových databází, které potom vůči jiným aplikacím vystupovaly v pozici serverů. Když klientská aplikace požádá o údaje, manipuluje se zpravidla s celým objemem údajů v souboru, což u desktopových souborů nevadí, protože se data přenášejí pouze mezi diskem desktopu a operační pamětí. Když se ovšem k údajům přistupuje z klientských stanic, dochází ke zbytečné zátěži komunikačních kanálů (Kyte, 2005). Oproti tomu zkušenosti s databázovými servery, jako jsou např. MS SQL Server, Oracle či MySQL jasně mluví pro výhody řešení klient-server. V momentě kdy potřebujeme získat nějaké drobné množství údajů, třeba i z terabajtové databáze, stačí 9

3.2

Uplatnění databázových systémů v prostředí internetu

pouze poslat dotaz v jazyce SQL, což je obvykle pár set bajtů a jako odpověď dostaneme jenom ty údaje, o které jsme požádali. Ovšem špatně zformulovaný dotaz může vrátit obrovské množství nepotřebných odpovědí či chybové hlášení (Lacko, 2003).

3.2


Vytváření databázového systému vyžaduje volbu typu architektury, který bude pro dané účely nejvhodnější. Je potřeba brát ohled na technologické a ekonomické možnosti. Existuje několik druhů architektur, které jsou k dispozici pro návrh konkrétního databázového systému. • Jednovrstvý systém Jedná se o starý model s využitím centrálního počítače. Samotní uživatelé měli k dispozici pouze terminál na svém stole, na který se dopravovaly informace o rozložení obrazovky obsahující zobrazovaná data. Tento model je dnes již využíván pouze okrajově, stále se s ním ovšem můžeme u některých velkých společností setkat. • Dvouvrstvá architektura (klient – server) Tato architektura má dva podtypy a to architektura soustřeďující svůj výkon na stranu klienta a architektura soutřeďjící svůj výkon na stranu serveru. U architektury s výkonem soustředěným na stranu klienta se všechny aplikační a uživatelské služby zpracovávají u klienta. Slabou stránkou této architektury je nutná přenosová kapacita, kdy mezi klientem a serverem musí probíhat velký počet datových přenosů. Obrázek 1: Architektura s výkonem soustředěným u klienta. Architektura s výkonem soustředěným na straně serveru - ke klientovi

Obrázek 1: Architektura s výkonem soustředěným u klienta (Paláček, 2002)

se přesouvají pouze uživatelské služby a dostává pouze požadované informace. Aplikační a datové služby probíhají na serveru viz Obrázek 2: Architektura s výkonem na serveru. • Třívrstvá architektura Tahle architektura má určitou podobnost s již uvedeným modelem architektury soustředěné na straně serveru. Uživatelské rozhraní je separováno, stejně tak jako datové a aplikační služby jsou od sebe odděleny do samostatných logických modelů. Ty mohou být umístěny buď na jednom stejném serveru, nebo na 10

3.2


Obrázek 2: Architektura s výkonem soustředěným na server (Paláček, 2002)

dvou odlišných serverech. Třívrstvý model nám umožňuje získat vyšší úroveň stability, jelikož provozní zátěž může být rozložena na dva servery viz Obrázek 3: Třívrstvá architektura.

Obrázek 3: Třívrstvá architektura (Paláček, 2002)

Aplikační server obsahuje služby pro řízení profilů návštěvníků, vytváření, modifikaci a odstaňování uživatelských účtů a komerčních informací, zprávu přihlášených zákazníků, provádění obsahové aktualizace, služby sledující všechny záležitosti týkající se výkonu, jako jsou například „úzká hrdlaÿ sítě při rozsáhlé úplné aktualizaci obsahu atd. (Welling, Thomson 2003). • N-vrstvé architektury Podstata tohoto modelu je stejná jako u třívrstvé architektury. Komponenty lze zde rozdělit do co nejmenších logických modulů a následně je pak rozmístit na několik serverů (Král, 1998).

11

4

4

METODICKÁ VÝCHODISKA

Metodická východiska

Každá databázová aplikace prochází při svém zrodu několik vývojovými fázemi. Cílem první fáze je sběr všech požadavků, které budou v aplikaci nutné při jejím využití. Následně probíhá návrh na logické úrovni. Závěrečnou fází je fyzická úroveň návrhu, která je implementačně závislá. Tuto úroveň je vhodné rozdělit na databázovou vrstvu a zbytek aplikace. Databázovou vrstvu je vhodné vyvíjet pomocí terminálu nebo podobného klientského nástroje. Zbytek aplikace se vyvíjí programováním ve zvolených programovacích jazycích a jejich rozhraní pro vzájemnou komunikaci (Lacko, 2003).

4.1

Databáze

Historie databází sahá hluboko do šedesátých let minulého století, kdy se mnoho firem zabývalo vývojem platformy, která by uspokojila potřebu skladování dat. Velká vetšina prvních produktů fungovala na síťovém modelu propojení dat. Roku 1968 firma IBM uvedla svůj produkt IMS. Rozdílem od předchozích platforem byla implementace dle hierarchického modelu. Předpokládaná spokojenost s tímto ani žádným z původních modelů ovšem nenastala. Roku 1970 zaměstnanec firmy IBM Ted Codd publikoval článek ”A Relation Model of Data for Large Shared Data Banks”, jehož podstatou byl návrh relačního databázového modelu. V jeho návrhu bylo využití relačního kalkulu a algebry pro manipulaci a ukládání dat i pro netechnicky založené uživatele. Jeho koncept uváděl hned od začátku neprocedurálnost dotazovacího jazyka a ukládání veškerých dat do tabulek. Dle relační teorie lze pomocí několika operací (selekce, sjednocení, kartézský součin, rozdíl, projekce a spojení) a jejich kombinace provádět veškeré operace s daty. Tento návrh byl základem pro vznik dvou projektů System-R (IBM) a Ingres (Berkleyho univerzita v Kalifornii). I po několika letech vývoje systému fungujícím na bázi relací se vedení IBM nenechalo přesvědčit o nahrazení původního IMS. Oproti tomu druhý projekt na Barkleyho univerzitě, jenž byl vyvíjen pro uložení dat tamní geografické skupiny, se stal inspirací nebo přímo zdrojem pro založení všech dnes známých databází (Žák, 2001).

4.2

Entita

Entita (anglicky Entity) je objekt reálného světa, který je schopný nezávislé existence a je jednoznačně identifikovatelný. Entita je umístěna v tabulce a zpravidla shromažďuje údaje o jednom druhu objektů. Například můžeme mít tabulku s osobními údaji pracovníků. Jednotlivé řádky odpovídají jednotlivým pracovníkům. Sloupce pak obsahují informace o pracovnících. Mohly by to být následující údaje: os. číslo, jméno, rodné číslo, adresa a výše platu. Sloupcům tabulky obvykle říkáme v databázové terminologii atributy. Každý atribut má svoje jméno, svůj datový typ a může být omezen podmínkou - integrit-

12

4.3

Integritní omezení

Obrázek 4: Entita v relačním modelu dat (Kosek, 1999)

ním omezením. Jednotlivé řádky v tabulce potom nahrazují jednotlivé záznamy. Vše zobrazuje Obrázek 5: Entita v relačním modelu (Kosek, 1999). Vzhledem k faktu, že tabulka je jediné úložiště dat v databázi, dá se nad tabulkou provádět celá řada operací. Od přejmenování atributu, přidání čí odebrání atributu, změna datového typu atributu, nastavení implicitní hodnoty, nastavení integritního omezení včetně jeho zapnutí a vypnutí (Kosek, 1999).

4.3


Integritní omezení jsou pravidla na úrovni entity. Zabraňují odstranění entity, pokud existují závislosti. V systému Oracle jsou platné následující typy omezení: NOT NULL, UNIQUE KEY, PRIMARY KEY, FOREIGN KEY, CHECK. Doporučení k integritnímu omezení: • Vhodnou pomůckou je název integritního omezení, jinak Oracle vytvoří vlastní ve formátu SYS CN. • Vytvoření integritního omezení současně s vytvořením entity nebo hned poté. • Definice omezení na úrovni atributu nebo entity (Welling, Thomson 2003). Cizí klíč (foreign key) je integritní omezení, které u entity vytvoří spojení jednoho nebo více jejích atributů s atributy jiné entity. Pokud se hodnoty dotčených atributů shodují, poté příslušný záznam cizí entity rozvíjí záznam zdrojové entity přes toto spojení. Tomu se říká reference nebo odkaz. Cizí klíč umožňuje definovat akce, které mají nastat při změně nebo smazání záznamů ve zdrojové tabulce, například, po smazání záznamu z primární tabulky budou v cizí tabulce řádky se stejnou 13

4.4

Vztah

hodnotou cizího klíče taktéž smazány, nastaveny na určitou hodnotu nebo se smazání zabrání úplně. Cizí klíče tak představují mechanismus pro udržení referenční integrity databáze. Omezení lze přidávat a odstraňovat, nikoli upravovat. Dá se též deaktivovat a znovu aktivovat (Dohnal, Pour, 1997).

4.4

Vztah

Vztah (anglicky Relationship) mezi entitami popisují vztahy objektů reálného světa, které tyto entity představují. Během návrhu modelu databáze, na který navazuje návrh aplikační logiky, může vzniknout několik vztahů: • 1:1 Jeden záznam první tabulky odpovídá právě jednomu záznamu v druhé tabulce. • 1:N První entitě odpovídá více druhých entit, druhé entitě odpovídá právě jeden záznam z první tabulky. • M:N První entitě odpovídá více druhých entit a naopak, druhé entitě odpovídá více prvních entit. Díky vědomosti o entitách a vztazích můžeme sestrojit entitně - relační diagram, který je součástí každého návrhu před započetím implementace databázového systému. Jeho forma je grafická nebo textová, zobrazuje entity, jejich atributy (s datovými typy), relace a její druh, primární klíče atd. (Welling, Thomson 2003).

4.5

Sekvence

Sekvence (anglicky Sequence) je objektem v databázi sloužícím jako nástroj produkující jedinečná čísla za použití sekvenčního generátoru, který poskytuje čísla v sekvenční sérii. Sekvence je vhodná do prostředí, kde se vyskytuje více uživatelů najednou. Uživatelé nemusí čekat jeden na druhého k zjištění posledního použitého čísla. Není nutné využívat transakčního zamykání. Generátor přidá každému uživateli prostředím sekvence jedinečné číslo. Jedná se nejčastěji o čísla do velikosti běžného datového typu (s celými čísly). K vytvoření sekvence se používá DDL příkazu CREATE. Nutnou vlastností je její název, informace zda je sekvence rostoucí či klesající, interval mezi čísly a další. Vytvořenou sekvenci lze modifikovat nebo odstranit. K odstranění sekvence se použije DDL příkazu DROP respektive k modifikaci sekvence příkazu ALTER. Modifikace se může týkat změny přírůstků od posledního čísla, zda má být cyklická, maximální a minimální hodnota, přednačítání čísel do paměti a podobně (Kyte, 2005). Příklad práce se sekvencí je v příloze 10: Práce se sekvencí.

14

4.6

4.6

Jazyk SQL

Jazyk SQL

V roce 1974 kdy Dr. Codd uveřejnil svoje první práce na téma relačních databází, bylo nutné vytvořit sadu příkazů pro ovládání těchto databází. Vznikl tak jazyk SEQUEL (Structured English Query Language) firmy IBM. Jednoznačný cíl byl ve vytvoření databázového jazyka, který by vycházel z angličtiny. Vývojem jazyka se zabývaly další firmy jako RSI (Oracle Corporation), v rozmezí let 1979 až 1981 byly vyvinuty systémy jako např. Progres, Informix a SyBase. Ve všech těchto systémech se používala varianta jazyka SEQUEL, který byl přejmenován na SQL (Wikipedia, 2008). Jazyk SQL lze rozdělit na tyto části: • DDL (Data Definition Language) Jazyk pro definici datových struktur, vytváří v databázi objekty (tabulky, pohledy, indexy, . . .) a umožňuje je odstraňovat nebo měnit jejich strukturu. CREATE, ALTER, DROP • DML (Data Manipulation Language) Jazyk pro manipulaci dat, umožňuje manipulaci s údaji jako vkládání, jejich aktualizaci, výmaz a velmi mocný příkaz SELECT. SELECT, INSERT, UPDATE, DELETE • DCL (Data Control Language) Jazyk řídících příkazů, umožňuje řídit a udržovat provoz databáze, odebírat uživatelská privilegia uživatelům a skupinám uživatelů. CREATE USER, ALTER USER, DROP USER, GRANT, REVOKE (Lacko, 2002) SQL je specializovaným programovacím jazykem, který lze využít buď interaktivně nebo uživatelsky k okamžitému řešení zadaných úloh. Jeho příkazy se také předkládají hostitelskému jazyku. Samotné SQL však není považováno za plnohodnotný programovací jazyk, hlavně proto, že v něm nejsou ve většině implementací řídicí programové konstrukce a jiné požadované prvky, které jsou obvyklou náležitostí každého obecného programovacího jazyku. SQL tedy je standardizovaným nástrojem vytvořeným pro práci s relačními databázemi (Wikipedia, 2008).Dále je SQL interaktivním neprocedurálním programovacím jazykem – je schopen získat odpověď v krátkém čase i na velmi komplikované dotazy. Výsledkem zadané úlohy která se týká vyhledávání je takzvaná tabulka výsledků, která nemusí být konečným výsledkem, ale může sloužit jako poddotaz k dalšímu hledání. Příkazy SQL mají velké množství povinných a volitelných parametrů, které se různí dle jednotlivých databázových objektů. Systém Oracle, nám dává k dispozici i procedurální nástavbu systém PL/SQL, který nám poskytuje možnost tvorby objektů v databázi: uložené procedury a funkce, jejich balíčky a spoušte (Lacko, 2002).

15

4.7

4.7 4.7.1

PL/SQL

PL/SQL Procedura

Procedura v prostředí Oracle je uložená struktura jako entity, pohledy apod. V databázi jsou tedy uložena nejen data, ale i aplikační logika pro spracování těchto dat. Přispívá se tím k jednodušší distribuci, ale také ke spolehlivosti, protože se dá aplikační logika zálohovat stejně snadno a rychle jako samotná data. Další výhodou tohoto uložení je předkompilovaná podoba procedur, databázový server díky tomu neztrácí čas a provádí již předkompilovaný kód (Lacko, 2003). Procedura je blok PL/SQL příkazů. Spuštěním procedury se spustí její příkazy jako jeden celek bez návratové hodnoty. Není zde využito žádných externích aplikací a jakéhokoli externího komunikačního kanálu. Výsledkem procedury mohou být úpravy údajů v entitě. Procedura může mít nějaký vstupní parametr a může být použita v těle jiné procedury (Theriault, Newman, 1998). Pokud uložená procedura při kompilaci vykáže nedostatek, její kompilace nebude považována za úspěšnou a bude označena jako neplatná. Takovou proceduru nelze použít! 4.7.2

Funkce

Funkce je v podstatě procedurou, která má v těle kódu dvě položky navíc. Tou první je v hlavičce definice návratového datového typu a tou druhou je samotný příkaz RETURN pro přiřazení návratové hodnoty v těle funkce. Funkce nemohou provádět DML operace. Jako v případě procedury nelze použít neplatnou funkci (Theriault, Loney, 2003). 4.7.3

Spoušť

Pod pojmem spoušť (anglicky TRIGGER) myslíme pojmenovanou množinu příkazů, která se provedou automaticky v případě předem definované operace s daty, nejčastěji: vložení, výmaz, úprava. Jejich použití většinou slouží ke kontrole dat, tvorbě záznamů o změně v entitě, zajištění referenční integrity a další. Spouště jsou speciálním případem procedur, jsou podobně jako procedury uloženy v databázi, ale neprovádí se přímo, jsou svázány s konkrétní událostí. Spoušť se vytváří příkazem CREATE TRIGGER kde určíme název spouště, tabulku a událost na kterou bude reagovat. Aktivace spouště může být definována před událostí, po události nebo místo události. K možnostem nastavení spouště patří i nastavení zda se bude zabývat každým řádkem entity nebo jen jedním, zda mazaná data budou před mazáním ještě k nečemu využita (prefix :OLD) nebo naopak jestli nově vkládaná data budou před vložením ještě ošetřena (prefix :NEW). Spoutě nabízí i možnost aktivace a deaktivace. To znamená, že mohou být libovoně dle potřeby v činnosti nebo nečinnosti. (Theriault, Newman, 1998).

16

4.8

4.8

Databázový systém

Databázový systém

Databázi chápeme jako úložiště údajů, které jsou uloženy a zpracovávány nezávisle na aplikačních programech. Databáze zapouzdřují jednak vlastní údaje, ale i relační vztahy mezi jednotlivými prvky a objekty v databázi, schémata popisují struktury údajů a integritní omezení. Kromě těchto údajů, které jsou uloženy a spravovány v databázi, ale také zapouzdřuje i software pro přístup k těmto údajům. Souhrn nástrojů, postupů a technik, které se využívají v souvislosti s databázemi, nazýváme databázová technologie. Databázový systém je tedy tvořen systémem řízení báze dat a databází (Lacko, 2003). Správu nad databází přebírá Systém Řízení Báze Dat (SŘBD). Bez SŘBD by žádná aplikace neměla přístup k databázi viz Obrázek 4: Spolupráce SŘBD s aplikací (Kosek, 1999). Právě SŘBD umožňuje vyřízení dotazů nad databází, které se předávají z nadřízených vrstev až od samotného uživatele.

Obrázek 5: Spolupráce aplikace se SŘBD (Kosek, 1999)

Nyní se dostáváme k deklarativnímu programovacímu jazyku SQL, který bude sloužit k samotné tvorbě entit a relací. Pro zadávání příkazů k tomu sloužících je ideální využít terminálu připojeného na databázový server, pomocí kterého se vepsané SQL příkazy přímo provedou, a není třeba je vkládat do některého z programovacích jazyků. Použití nadřazeného programovacího jazyku s deklarovaným SQL dotazem přistupujícího přes rozhraní OCI k SŘBD bude potřeba až se budou odpovědi SŘBD na dotazy dále zpracovávat a posílat na výstup k uživateli (Král, 1998).

4.9

Databázový systém ORACLE

Databázový systém Oracle je již dlouhou řadu let využívaným a stále vyvíjeným systémem. Jeho počátky sahají do roku 1977, kdy Lawrence J. Ellison, Robert N. Miner a Edward Oates založili společnost SDL (Software Development Laboratory), která pracovala na vývoji relačních databází podle teorie doktora E. F. Codda (Lacko, 2002). Oracle původně znamenal kódový název projektu vyvíjený společností SDL pro firmu CIA, která v té době potřebovala systém na shromáždění velkého množství dat a také v nich rychle vyhledávat. Rok po té se zrodila první verze databázové platformy Oracle verze 1.0 která byla vytvořena v assembleru a nijak se nerozšířila, nicméně motivovala vývojáře k další práci (Lacko, 2002). Následovaly další verze: 2.0 (1980 – problémy s portabilitou), 3.0 (1983 – přechod na jazyk C), 4.0 (1984 – spolupráce více serverů, 17

4.10

Jazyk PHP

kompatibilní s IBM), 5.0 (1985 – pro všechny tehdejší hardwarové platformy), 6.0 a 6.2 (1988 – dostupnost, transakční systémy), 7.0 (1993 – velmi rozsáhlé databáze a datové sklady vetší než 5TB), 8.0 a 8i (1997 – integrace jazyka Java, i – orientace na prostředí internetu), 9i (2000), . . . Současnou verzí, která je instalována na vývojovém studentském serveru Akela je verze Oracle 10g. Tato verze je volně šířitelná pouze pro nekomerční a studijní účely. Její platforma je spolehlivá, bezpečná, výkonná, rychlá a s jednoduchou administrací. Moderní webové aplikace využívají velké množství dat, včetně různých multimediálních formátů, databázová platforma Oracle umožňuje ukládat, spravovat a seskupovat všechny typy multimediálního obsahu webové aplikace do jediné databáze (Lacko, 2002). Tento systém podporuje nejen standardní relační dotazovací jazyk SQL podle normy SQL92, ale také imperativní programovací jazyk PL/SQL rozšiřující možnosti vlastního SQL, dále podporuje objektové databáze a databáze uložené v hierarchickém modelu dat (XML databáze, jazyk XSQL) (Wikipedia, 2008). Dodnes se (od přejmenování v roce 1980 z původní SDL) společnost Oracle Corporation věnuje problematice databázovým systémům a je vedoucí společností v této oblasti.

4.10

Jazyk PHP

PHP je servrovým skriptovacím jazykem, který je speciálně navržen pro potřebu webových aplikací. PHP byl vytvořen v roce 1994 a je to původně práce jednoho člověka – Rasmuse Lerdorfa. Vzápětí se dostal do rukou odborníků a prošel třemi velkými předělávkami, díky kterým teď před námi stojí všeobjímající produkt. Ve stránce HTML je umístěn PHP kód, který se vykoná pokaždé, když má být stránka zobrazena. PHP kód se interpretuje na webovém serveru a generuje HTML či jiný kód, který je pak zobrazen na výstupu. V říjnu 2002 byl používán na více než devíti miliónech domén a tento počet se neustále zvětšuje. PHP je open source produkt což znamená, že je jeho zdrojový kód plně otevřen a k dispozici. Dá se používat, upravovat, distribuovat a to všechno bez jakýchkoli poplatků. Původní zkratka PHP znamenala Personal Home Page, ale název byl později přeměněn na Hypertext Preprocesor. Jedním z hlavních soupeřů PHP jsou Perl, MS ASP, JSP a ACF. Přednosti PHP jsou vysoká výkonnost, rozhraní pro mnoho druhů databázových systémů, zabudované knihovny pro implementaci mnoha běžných webových úloh, nízké náklady, přenositelnost, open source. Výkonnost spočívá v jednoduchosti a nenáročnosti na server, díky tomu je PHP schopno obsloužit milióny požadavků denně (Castagnetto, Rawat, Schumann, Scollo, Veliath, 2002). Protože byl PHP od prvopočátku navrhován pro využití ve webových aplikacích, obsahuje mnoho funkcí, které jsou určeny k plnění úkolů souvisejících s webovým prostředím. Může se za pochodu připojovat k síťovým službám, odesílat e-maily, pracovat s cookies, generovat PDF dokumenty a další. Syntaxe PHP je založena na jiných programovacích jazycích, především 18

4.10

Jazyk PHP

C a Perl. PHP kód je přenositelný mezi mnoha operačními systémy, napsaný kód v prostředí linux bude bez větších modifikací fungovat i v prostředí Unix nebo na různých verzích MS Windows. Díky zpřístupněnému zdrojovému kódu je možnost veškerých úprav a dodělávek bez nutností čekání na novou verzi či opravné balíčky (Welling, Thomson 2003).

19

5

5 5.1

VÝVOJ VLASTNÍ APLIKACE

Vývoj vlastní aplikace Aktuální situace

Informační systém evidence lidských zdrojů byl vyvíjena pro evidování a organizování lidských zdrojů lyžařské školy a půjčovny Envy Ski na Ramzové. Původní systém evidence byla papírová kartotéka, kterou měl na starost jeden ze zaměstnanců lyžařské školy. Komunikace probíhala pouze pomocí mobilního telefonu. Při každé změně nebo potřebě dalších lidských zdrojů musel konkrétní zaměstnanec pověřený evidováním a organizací obvolávat všechny dostupné pracovníky a externisty. Tento způsob byl zastatralý a z velké části naprosto nevyhovující. Docházelo tak k mnoho chybám, kdy požadavky na zaměstnance nebyly v souladu s jeho schopnostmi nebo byly mimo jeho časovou dostupnost. Tyto informace ovšem pověřená osoba neměla, protože nebyl nikde vytvořen profil každého instruktora, na základě kterého by se nemusela obvolávat všechna uvedená telefonní čísla a teprve při hovoru zjišťovat jeho schopnosti a dostupnost. Kritéria vyhledávání byla s rozvojem lyžařské školy i půjčovny stále složitější a při nárůstu počtu zaměstnanců a externistů nebylo možné nadále fungovat pouze pomocí seznamu jmen a příjmení s telefonními čísly. Příklad takového vyhledávání může být: žena, instruktorka snowboardingu, schopnost mluvit anglicky, schopnost vypomáhat v půjčovně, dostupnost 15.-23.ledna. Takovou osobu nebylo možné najít pouze pomocí informace o jméně a telefonním čísle. Pokud osoba pověřená neznala zaměstnance a nevěděla s jakými požadavky se na koho obrátit, začala obvolávat náhodně všechny ženy ze seznamu. Vznikaly tak zbytečné časové a finanční ztráty. V těsné souvislosti s vyhledáváním osob byla velice oslabena i informovanost vedoucích složek školy a půjčovny. S příchodem každé nové sezony bylo obtížné zjistit kvalifikační růst všech pracovníků z minulé sezony. Opět bylo potřeba všechny obvolat a tázat se na změny v kvalifikaci a na samotný zájem o působení v dalším roce. Toto řešení je přijatelné pokud není potřeba větší množství pacovníků a externistů. Dalším nevyhovujícím prvkem byla neexistující evidence docházky jednotlivých zaměstnanců. Nebylo tedy možné vytvořit přehledy přítomnosti, výpočty bonusů nebo vystavit potvrzení o praxi. Pracovník pověřený evidencí musel po každé sezoně spojit údaje za všechny týdny sezony a provádět zdlouhavé výpočty. Rizikem tohoto postupu mohla být nechtěná chyba při výpočtu, ztráta části podkladů během sezony nebo zdlouhavá časová prodleva od konce sezony do doby získání výsledků. Samozřejmě i tento způsob evidence lidských zdrojů má své výhody. Výhodou beze sporu je její jednoduchá obsluha, téměř kdokoliv byl schopen každodenní informace vepsat na správné místo správného formuláře. To souvisí i s kvalifikací této osoby kdy není potřeba žádné odborné způsobilosti nebo vzdělání. Také nároky na technickou vybavenost jsou v tomto případě minimální, v podstatě stačí kalkulačka se základními funkcemi a telefon. Fugovala i vysoká mobilita evidenčních prostředků což je v případě lyžařské školy a půjčovny fungující v zimních podmínkách a oddělených provozovnách výhodou.

20

5.2

5.2

Požadavky na systém

Požadavky na systém

Nový systém měl všechny výše zmíněné problémy pomoci vyřešit. Vzhledem k tomu, že lyžařská škola a půjčovna jsou pouze sezonní záležitostí, nemuselo se na nový systém přecházet v průběhu obdodí, ale se začátkem nového. Tím byl odstraněn problém převodu záznamů z části období, čímž se potlačí riziko vzniku chyb a bude dostatečný čas na zaškolení pracovníků pro práci se systémem. Anaýlza požadavků stanovila stavební kameny jádra systému. Základním požadavkem na systém byla evidence uživatelů, kteří plní různé role – zaměstnanci, externisté a vedoucí pracovník. Každý uživatel bude mít své jedinečné osobní číslo, uvede kontaktní údaje, pracovní schopnosti, jazykové dovednosti a další. Druhým požadavkem je virtuální kalendář, který bude sloužit uživatelům k zadání jednotlivých dnů či celých bloků, kdy mohou být k dispozici na pracovišti. Tohle řešení vytvoří vysokou variabilitu změn v reálném čase bez nutnosti komunikace s osobou pověřenou organizováním. Tak stejně tato osoba uvidí vždy aktuální situaci při každém přístupu do systému. Tímto byl splěn požadavek rozšíření základních prvků, které měla i původní evidence, především o stálost aktuálních informací a profilu každého uživatele. Nový systém bude ovšem nabízet o mnoho více. Hlavní výhodou je přístup všech uživatelů v režimu 24/7. Systém umožňuje editaci uživatelského profilu, intuitivní ovládání nebo dostupnost informací z uživatelských profilů pověřenou osobou na základě několika kliknutí. Založení nového uživatele provádí správce, který předá uživatelské jméno a heslo novému uživateli mimo systém (např. sms zpávou). Ten již samostatně bez nutnosti komunikace s pověřenou osobou bude systémem naveden a vloží veškeré potřebné informace do systému. Na výzvu uživatele systém informace zpracuje a uloží. V tu chvíli jsou informace k dispozici dalším oprávněným uživatelům, kteří je mohou okamžitě využívat a reagovat na ně.

5.3

Architektura aplikace

Aplikace využívá univerzitní studentský vývojový server Akela z důvodu dostupnosti databázového systému Oracle a příslušného aplikačního prostředí (PHP). Systém nebyl v rámci pilotního projektu a ze studijních důvodů komerčně využíván, proto byl vybrán školní server, pro nasazení do ostrého provozu by však bylo potřeba najít vhodnější umístění s podporou třeba i slabšího systému MySQL, který není spoplatněn. Entitně relační diagram (ERD), který schématicky vytvoří zjednodušený datový model tvořeného systému, je zobrazen na Obrázku 6: Entitně relační diagram. Splňuje 3. normální formu. Nejvýznamější entitou v ERD je samotný uživatel. Ovlivňuje celý systém a všechny ostatní entity jsou na něm závislé, protože jsou v přímé souvislosti s uživatelem. Popis vedleších entit:

21

5.3

Architektura aplikace

Obrázek 6: Entitně relační diagram

• PRITOMNOST Entita, jejíž atributy udržují informace o přítomnosti konkrétního uživatele (pracovníka/externisty) v konkrétním dni v konkrétní sezóně. • HODNOCENI Entita, která slouží pověřené osobě k získání a zadávání hodnocení uživatelů v konkrétních sezónách. • DOVEDNOSTI Tato entita udržuje informace o jednotlivých uživatelích, jaké mají dovednosti a v jakém jazyce jsou schopni komunikovat se zákazníkem. • ATRIBUTY Entita, v jejímž obsahu jsou doplňují informace o uživateli. • C SEZONY Číselník sezón. • C DOVEDNOSTI Číselník druhů dovedností. 22

5.4


• C JAZYKY Číselník jazyků. • C SABLONA Číselník druhů dovedností s jejich popisem. • C POHLAVI Číselník pohlaví. • C ROLE Číselník role uživatele, má oddělit běžného uživatele od administrátora, pověřené osoby, majitele a dalších.

5.4


Se správně navrženým ERD se můžeme pustit do tvorby samotných entit včetně integritních omezení. Ty budou sloužit jako prostředky omezování hodnot položek, popisovat vztahy mezi jednotlivými entitami, požadovat jednoznačnost v polích s primárním klíčem a další. Vytvoření jednotlivých entit probíhá pomocí jazyka SQL. Entita UZIVATEL je vytvořena tímto SQL dotazem: CREATE TABLE uzivatel ( id NUMBER(5) PRIMARY KEY, jmeno VARCHAR2(25) NOT NULL, prijmeni VARCHAR2(25), kontakt VARCHAR2(60), email VARCHAR2(60), role NUMBER(1) REFERENCES c_role CHECK(role>0 AND role<4) NOT NULL, heslo VARCHAR2(40) NOT NULL, pohlavi NUMBER(1) REFERENCES c_pohlavi CHECH(pohlavi IN (0,1)) NOT NULL ) Atribut ID je definován jako primární klíč, díky tomu nesmí být automaticky NULL. Vkládání nových atributů do entity je řešeno pomocí sekvence, která vytváří sekvenčním generátorem nové jedinečné hodnoty při každém zavolání. Atribut JMENO je omezen nenulovou hodnotou a datovým typem, což omezuje vkládanou hodnotu. C POHLAVI a C ROLE jsou číselníky, které mají omezený počet variant správných údajů, které hlídá integritní omezení CHECK. Číselník C POHLAVI umožňuje výběr pouze ze dvou možností. C ROLE mají na výběr ze tří možných rolí uživatelů v systému. Oba číselníky jsou navázány na hlavní entity jako cizí klíče. Obdobně je realizována i další entita DOVEDNOSTI:

23

5.4


CREATE TABLE dovednosti ( uzivatel NUMBER(5) NOT NULL REFERENCES uzivatel, dovednost number(5) NOT NULL REFERENCES c_dovednosti, jazyky number(5) NOT NULL REFERENCES c_jazyky ) Tabulka udržuje informace o dovednostech všech uživatelů. Vzhledem ke snaze dosáhnout co nejnižší redundance má entita DOVEDNOST návaznost na další dva číselníky. Entita je kromě číselníků spojena i s uživatelem. V každém atributu je záznam podřízený jiné entitě přes relaci. Jedná se o tzv. cizí klíč. Integritní omezení se v tomto případě stará o to, aby nezůstávaly v entitách údaje, které již nemají návaznost na nadřízená data. Jaký smysl by měly informace o dovednostech již neexistujícího uživatele? Tak stejně informace o jeho přítomnosti či jeho hodnocení? Aby k takovým situacím nedocházelo SŘBD pomocí správně nastaveného integritního omezení nesvolí ke smazání uživatele, který má v některé z podřízených entit uložené hodnoty v atributech. Nezbývá, než před odstraněním samotného uživatele odstranit hodnoty atributů souvisejíchích s tímto uživatelem ze všech podřízených entit. Při pohledu na ERD jsou podřízené entity čtyři a to: DOVEDNOSTI, ATRIBUTY, PRITOMNOST a HODNOCENI. Řešením by bylo použití pěti SQL příkazů, pomocí kterých bychom se zbavili všech záznamů o uživateli a posledním z nich ho odstranili z entity uživatelů. Existuje zde ale podobné řešení, které je mnohem efektivnější a pohodlnější – využití spouště (trigger). Správně nastavená spoušť nám umožní zbavit se uživatele (například s identifikačním číslem 34) jednoduše pouze pomocí SQL příkazu: DELETE FROM uzivatel WHERE id = 34 Bez použití aktivované spouště by SŘBD zahlásil porušení integrity a SQL příkaz by se neprovedl. Právě tuhle situaci ošetřuje spoušt, která před provedením dotazu zareaguje a záznamy z podřízených entit před smazíním samotného uživatele vymaže. Spoušť má tuto podobu: CREATE OR REPLACE TRIGGER smaz_udaje BEFORE DELETE ON uzivatel FOR EACH ROW BEGIN DELETE FROM dovednosti WHERE uzivatel = :OLD.id ; DELETE FROM atributy WHERE uzivatel = :OLD.id ; DELETE FROM pritomnost WHERE uzivatel = :OLD.id ; DELETE FROM hodnoceni WHERE osoba = :OLD.id ; END; Součástí spouště je vytvoření implicitní proměnné, kterou vytváří Oracle pro využití mazaných hodnot před nebo po jejich smazání (v tomto případě před smazáním – OLD). Nyní SQL příkaz pro smazání uživatele s ID 34 neporušuje integritu a může

24

5.5

Webový přístup

být proveden. Vkládání uživatele je věnována kapitola 5.7 – Propojení aplikačních komponent. Následující entita PRITOMNOST uchovává informaci o přítomnosti uživatele a je relačně spojena s entitou UZIVATEL a číselníkem C SEZONY. CREATE TABLE pritomnost ( uzivatel NUMBER(5) NOT NULL REFERENCES uzivatel, sezona NUMBER(5) NOT NULL REFERENCES c_sezony, den VARCHAR2(10) ) Integritní omezení je zde naprosto srovnatelné s entitou dovedností. Významu a funkci entity PRITOMNOST je věnována kapitola 5.7 - Propojení aplikačních komponent. Podobně jsou vytvořeny i další entity potřebné k funkci celé evidence. SQL příkazy k jejich vytvoření jsou vypsány v příloze 1.

5.5

Webový přístup

Databáze a její entity připravily půdu pro data, která do nich mají být vložena přes nadřazené vrstvy uživatelem. To je smyslem celé aplikace. Aby se informace, které chce uživatel do systému uložit dostaly až k databázi jako atributy správných entit, je nezbytné vytvořit uživatelské prostředí kde toho bude schopen. To se nedá vyřešit pomocí vzdáleného přístupu přes terminál, aby každý uživatel vkládal data pomocí SQL příkazů. Pro koncového uživatele, ať je jím zaměstnanec, pověřená osoba nebo majitel, je potřeba jednoduché uživatelské prostředí, kde se zorientuje každý bez znalosti problematiky nižších vrstev informačního systému. V případě databázového serveru připojeného na internet není jednodušší volby než webového rozhraní. Jak již bylo v předešlém textu zmíněno, se základní znalostí obsluhy internetu se počítá u každého uživatele a pokud je samotné rozhraní uděláno přívětivým způsobem, nemůže nastat problém. S odkazem na předešlý obrázek (Obrázek 4: Spolupráce aplikace se SŘBD) je nutné konstatovat, že pokud chceme předávat a získávat informace z databáze, je nutné přistupovat k SŘBD. Z webových aplikací, které jsou umístěny na stejném databázovém serveru (Akela) je možný přístup přes rozhraní OCI. Rozhraní OCI je krátce popsáno ve slovníčku pojmů (kapitola 8). Webový přístup se realizuje pomocí okna internetového prohlížeče, který je součástí dnes již každého operačního systému. Prvky zobrazené uživateli jsou výsledky skriptovacího jazyka PHP pracujícího na straně serveru a předávajícího na stranu klienta výsledky, které jsou pomocí značkovacího jazyku HTML a kaskádových stylů CSS upraveny ve finální podobu která je k dispozici uživateli. PHP užívá právě zmiňované rozhraní OCI, pomocí kterého komunikuje s SŘBD.

25

5.6

5.6

Uživatelské rozhraní


Uživatelské rozhraní je rozděleno do více kategorií. Existuje jiné rozhraní s jinými aplikačními složkami pro zaměstnance, jiné pro osobu pověřenou nebo vedoucího pracovníka a poslední pro administrátora celé evidence. Administrátorské rozhraní slouží spíše jako rychlý přehled základních informací o celé aplikaci než jako funkční prostředí, samotný administrátor má k dispozici terminál, na kterém je schopen fungovat mnohem efektivněji a zasahovat do klíčových nastavení. Případné změny v PHP, HTML čí CSS musí řešit ve zdrojových souborech, k čemuž použije software podobný WinSCP, aby se k nim dostal a mohl je editovat. Rozhraní vedoucího pracovníka je základem pro vše co systém nabízí, protože v jeho kompetenci je zakládání i mazání uživatelů, přehled aktuální přítomnosti všech uživatelů, pohled na profil jednotlivých uživatelů, vyhledávání nejvhodnějších uživatelů pro konkrétní potřebu, hodnocení a další. Oproti tomu zaměstnanecké rozhraní funguje jako zdroj informací pro veškeré přehledy pověřené osoby. Zaměstnanci a externisté pod svým jedinečným klíčem udržují aktuální informace v systému především o svém profilu a přítomnosti. Pojďme se na některé z jmenovaných operací podívat blíže. Nový uživatel. Aby mohly vzniknout nějaké přehledy a možnost vyhledávání mezi zaměstnanci a externisty je nezbytně nutné nějaké uživatele evidovat. Prvním krokem je vytvoření nového uživatele. Je to základní operace, kterou má na starost pověřená osoba v jedné ze záložek svého rozhraní. Vstupní informace o novém uživateli, které jsou povinné, se vpisují do jednotlivých vstupních polí formuláře vytvořeného pomocí HTML. Mezi povinné údaje patří: id, jméno, role, heslo a pohlaví. Po odeslání těchto informací se provede vytvoření nového uživatele. Jak tento průběh vypadá z hlediska vrstvové architektury aplikace bude rozebráno v kapitole 5.7 - Propojení aplikačních komponent. Pověřené osobě se vypíše informace o úspěšném vytvoření nového uživatele, kterému předá základní přihlašovací údaje do systému (id, heslo), a samotný uživatel si po přihlášení nastaví svůj profil a případně vloží další údaje sám. Samozřejmostí zůstává, že položka id je pro každého uživatele neměnná! Problematika mazání uživatele již byla zmíněna v kapitole 5.4 – Integritní omezení. Přehled přítomností. Z pohledu pověřené osoby je tento přehled seznamem pracovníků na dané období či daný den. Po odpovědi systému na jeho dotaz přítomnosti je už na jeho zvážení, zda má zaměstnanců tolik, kolik ptřebuje, nebo musí dodatečné zaměstnance shánět či přebytečné odvolávat. Celý tento přehled funguje na prostém textovém výpisu, kde je ke konkrétnímu datu přiřazen seznam jmen zaměstnanců a externistů, kteří se k tomuto dni uvolili být přítomni. Z pohledu zaměstnance je přítomnost o mnoho jednodušší. Po přihlášení do systému stačí přejít do záložky přítomost, kde je k dispozici virtuální kalendář aktuální sezóny. Tento kalendář je vytvořen pomocí PHP, HTML a CSS. Jeho jedinou funkcí je přehledně nabídnout zaměstnanci přehled o pracovních dnech sezony (Obrázek 7: Ukázka virtuálního kalendáře) a možnost předat informace, které dny nebo časové úseky bude k dispozici.

26

5.6


Zadání informací do systému pomocí kalendáře je naprosto jenoduché – stačí pouze zaškrtnout políčka pod vybranými dny a odeslat tlačítkem pro zanesení aktualizace přítomnosti uživatele do databáze. Veškeré provedené změny se hned projeví v přehledu pověřené osobě.

Obrázek 7: Ukázka virtuálního kalendáře

Funkce zadávání a výpisu přítomností bude opět rozebrána z vrstvového hlediska v kapitole 5.7 - Propojení aplikačních komponent. Vyhledávání vhodného zaměstnance/externisty. Tato funkce systému je určena pro pověřenou osobu. Jejím cílem je najít vhodného zaměstnance pro daný úkol. Funguje na jednoduchém principu, kdy se v databázi uživatelů hledá právě ten, který nejvíce vyhovuje zadaným kritériím. Záložka „Vyhledání uživateleÿ nabízí širokou volbu možností hledání v profilu zaměstnanců a jejich přítomnosti. Zadávání kritérií probíhá přes HTML formulář složený z běžných rolovacích nabídek, radio přepínačů, zaškrtávacích políček a poslední součástí je i již zmíněný virtuální kalendář. Tentokrát slouží tento kalendář pověřené osobě oproti předchozímu použití na straně zaměstnance. Požadavky na vyhledávání mohou vypadat následovně: je potřeba muž, který je instruktorem snowboardingu, umí anglicky a je k dispozici na druhý a třetí víkend v měsíci lednu. Odesláním elektronického formuláře s těmito předvyplněnými kritérii příjde k SŘBD nadřízená vrstva s tímto dotazem: SELECT DISTINCT uzivatel.prijmeni AS Prijmeni, uzivatel.jmeno AS Jmeno FROM 27

5.7

Propojení aplikačních komponent

uzivatel, pritomnost, dovednosti WHERE pritomnost.uzivatel = uzivatel.id AND uzivatel.id = dovednosti.uzivatel AND pritomnost.den IN (113,114,120,121) AND dovednosti.dovednost = 4 AND dovednosti.jazyky = 1 AND uzivatel.pohlavi = 1 ORDER BY uzivatel.prijmeni, uzivatel.jmeno Výsledkem tohoto hledání je seznam zaměstnanců, kteří vyhověli všem kritériím. SŘBD vyhledá v databázi odpověď na tento dotaz a předá jej nadřazené vrstvě k dalšímu zpracování. Z pohledu terminálu vypadá výsledek tak, jak je ukázáno na Obrázku 8: Ukázka výsledku hledání v terminálu. Jaká bude finální podoba výpisu na výstupu již záleží na grafické interpretaci a vzhledu uživatelského prostředí. Výsledkem ovšem může být prázdná množina řešení (Empty set) a vyhledávání je tím pádem neúspěsné. Jediným řešením tohoto problému je postupné ubírání na nárocích vyhledávácích kritérií, dokud se nenajde nejvíce vyhovující zaměstnanec/externista. Funkce vyhledávání vhodného zaměstnance nebude hlouběji rozebírána, neboť její hlavní část byla dostatečně popsána a komunikace aplikačních vrstev je téměř shodná s funkcemi „nový uživatelÿ a „přehled přítomnostíÿ, které jsou po této stránce rozebrány v kapitole 5.7 - Propojení aplikačních komponent.

Obrázek 8: Ukázka výsledku hledání v terminálu

5.7


Aby byl jakýkoliv uživatel schopen vstoupit do databáze a získat potřebné informace nebo vložit či upravit jiné, je nutné projít skrze celou řadu aplikačních komponent. V textu jsou tyto komponenty označovány jako vrstvy. Tyto vrstvy spolu musí spolupracovat, jinak by nedošlo ke správné funkci celého systému. I odpadnutí jedné z komponent znamená nefunkci celého systému. Samozřejmě nefunkce neznamená ztrátu uložených dat, ale pouze přerušení správného chodu celého systému. Ztrátu dat může způsobit pouze destruktivní chyba v databázi. 28

5.7


Jednotlivé komponenty, které spolu komunikují jsou v pořadí: uživatel – webové rozhraní – skriptovací jazyk PHP – databázové rozhraní OCI – SŘBD – databázový systém Oracle. Pokud se tedy rozhodne uživatel vložit záznam do atributů některé z entit, je potřeba, aby jím podaná informace prošla celou hierarchií. Když se opět podíváme na potřebu pověřené osoby vytvořit nového uživatele, musíme přistoupit k nejvýše postavené komponentě, kterou je webové rozhraní. Po přihlášení pověřené osoby jako uživatele a zvolení záložky pro vytvoření uživatele se nacházíme ve webovém rozhraní, které je složeno ze značek jazyka HTML a kaskádových stylů CSS. Formulář, který se v tomto prostředí nachází vyzve uživatele (pověřenou osobu), aby zadal povinné údaje pro vytvoření nového uživatele – Obrázek 9: Formulář základních informací pro vytvoření nového uživatele. Jsou to: identifikační číslo, jméno, role, heslo a pohlaví. Jak již bylo zmíněno v předešlém textu, pouze atribut ID je neměnný a je přidělen sekvencí uživateli na celou dobu existence jeho účtu, ostatní položky včetně hesla si může uživatel ve svém profilu dle potřeby měnit.

Obrázek 9: Formulář základních informací pro vytvoření nového uživatele

Po odeslání formuláře tlačítkem „Vytvořit uživateleÿ dojde k předání hodnot podřízené komponentě PHP metodou POST. V PHP se všechny údaje příjaté z odeslaného formuláře seřadí do správného pořadí aby vytvořily pseudopříkaz jazyka SQL uloženího do proměnné $dotaz: INSERT INTO uzivatel (id, jmeno, prijmeni, kontakt, email, role, heslo, pohlavi) VALUES ( uzivatel_seq.NEXTVAL, ’$_POST[jmeno]’, ’$_POST[prijmeni]’, ’$_POST[kontakt]’, ’$_POST[email]’, 2, ’$_POST[heslo]’, 29

5.7


’$_POST[pohlavi]’ ) Formulář ovšem nepředává dvě hodnoty nutné pro kompletnost vkládacího příkazu do entity uživatelů. Jde o ROLI a ID. ROLE je přednastavena na hodnotu 2 což odkazuje do číselníku rolí na externistu. Evidence je v případě lyžařské školy převážně tvořena externisty, kteří se v průběhu sezony střídají jako instruktoři, a pro tuto masovost je jednodušší se při tvorbě uživatele rolí nezabývat a případně roli zaměstnance či pověřené osoby dodatečným příkazem upravit. Touto drobnou změnou se evidence dále nezabývá, vznesený požadavek řeší na požádání administrátor, pro kterého je pomocí terminálu tato změna maličkostí. V případě přání/potřeby by se tato drobná aplikace dala do uživatelského rozhraní pověřené osoby dodělat. Dále je vyjmuta z pole vstupního formuláře položka ID z důvodu ochrany primárního klíče a je vkládána pomocí generované následující hodnoty z vytvořené sekvence UZIVATEL SEQ. Příkaz, který se tedy uložil do proměnné $dotaz vypadá následovně: INSERT INTO uzivatel (id, jmeno, prijmeni, kontakt, email, role, heslo, pohlavi) VALUES ( 46, ’Jaroslava’, ’Novotná’, ’736 98 23 09’, ’[email protected]’, 2, ’Jar555’, 2 ) Následuje provedení PHP příkazu: $vysledek_dotazu = SQL_QUERY($dotaz); kterým se přes rozhraní OCI dostane dotaz k SŘBD a je proveden nad databází. Tím je vložení nového uživatele úspěšně dokončeno1 . Tabulka uživatelů po vložení několika záznamů vypadá následovně Obrázek 10: Tabulka uživatelů po vložení záznamů.

Obrázek 10: Tabulka uživatelů po vložení záznamů 1

Nejdříve je nutné se přes sérii PHP příkazů připojit k databázi.

30

5.8

Shrnutí vývoje

Přitomnost. Virtuální kalendář plný zaškrtávacích polí má komunikaci s databází velice podobnou. Malým rozdílem ovšem je, že již při vstupu uživatele na záložku, kde chce zadat či upravit svoji přítomnost, se informace dříve zadané načtou z entity PRITOMNOST. Poté je uživatel pomocí virtuálního kalendáře modifikuje a znovu ukládá. Komunikace aplikačních komponent probíhá totožně jak v předešlém popise s rozdílem, že při vykreslování virtuálního kalendáře je nutné vyznačit dříve uložené hodnoty. Po vznesení SQL dotazu nad entitou PRITOMNOST jsou cyklicky vypisovány jednotlivé měsíce sezony. Každý den je testován zda-li není zanesen ve výsledku dotazu, čímž by se žaskrtávací pole daného dne označilo jako „checkedÿ. Zdrojový kód, který generuje virtuální kalendář a kontroluje dříve zanesené dny, je k dispozici v příloze 2. Aktualizace přítomnosti pomocí virtuálního kalendáře. Odeslání aktualizace či prvního vložení hodnot proběhne kliknutím na tlačítko ”aktualizuj” spojené s formulářem virtuálního kalendáře. Před uložením aktuálního stavu přítomnosti do entity PRITOMNOST se nejdříve provede SQL příkaz pro výmaz všech předchozích zadaných hodnot spojených s ID aktualizovaného uživatele. Následně se opět cyklicky testují proměnné všech jednotlivých dnů a hodnoty TRUE neboli „checkedÿ v případě zaškrtávacích polí se přidají do vkládajícího SQL dotazu nad entitou PRITOMNOST, samozřejmě s přiloženým ID uživatele a ID sezony.

5.8

Shrnutí vývoje

Evidence lidských zdrojů v novém podání má být schopna v sobě udržet velké množství informací a zároveň být k dispozici po celou dobu lyžařsé sezony a pro potřeby oprávněných osob po celý rok. Aby tato podmínka byla splněna, bylo nutností umístit aplikaci do prostředí internetu. Aplikace se tímto stává dostupnou v režimu 24/7 a to každému uživateli, který má k dispozici internet. Díky přenosu pouze textových dat mezi uživatelem a aplikací, není potřeba vysokorychlostního připojení ani připojení na delší časový úsek. Vývoj samotné aplikace začal seznámením s nároky na aplikaci, která měla obsahovat veškeré předchozí prvky ve vylepšené podobě a být rozšířena o mnoho dalších. Z těchto údajů bylo navrženo funkční rozložení entit v databázi a následovně tyto entity implementovány. Podobně byla rozvržena a implementována jednotlivá uživatelská rozhraní, ke kterým uživatelé přistupují pomocí internetu respektive internetových prohlížečů. Při testovacím provozu bylo do evidence vloženo několik desítek uživatelů a jejich profily byly fiktivně vyplněny smyšlenými údaji. Z pohledu správce byly vyzkoušeny všechny dostupné aplikace a jejich výsledky byly porovnávány se zdrojovými daty, zda nedochází např. k zadržování informací špatným propojením vrstev či zda fungují integritní omezení a kontrola zadávaných údajů. Byly otestovány i hromadné výpisy přítomnosti, dovedností a uživatelů zda nedochází k nepřehlednosti či rozložení zobrazovaných údajů.

31

6

6 6.1

DISKUSE

Diskuse Poznatky z praktického využití

Evidence lidských zdrojů fungovala v praxi po dobu jedné sezony. Její nasazení ulehčilo správci udržet informace o profilu všech uživatelů a jejich přítomnosti. Oproti informacím z profilu a vyhledávání byly informace o přítomnosti naprosto nepoužitelné. Nebylo to chybou evidence, ale nespolehlivostí a nekázní externích pracovníků. Na začátku sezony každý uživatel dostal přiděleno svoje identifikační číslo a heslo pod kterým v systému vystupoval. Po prvním přihlášení a zanesení informací o svém profilu a přítomnosti do evidence řada uživatelů již samotnou evidenci nikdy nevyužila. Důsledkem byla neaktuálnost informací o uživatelově přítomnosti. Docházelo tak k příjezdu většího počtu externistů v jednom časovém období a naopak nedorazili externisté, kteří zadali do evidence svoji plánovanou účast. Na základě této nespolehlivosti uživatelů nastala potřeba kontrolovat každého účastníka telefonicky což vedlo k dodatečným nákladům, které již neměly vznikat. Stejná věc měla za důsledek neplatnost informací o přítomnosti po ukončené sezoně. Tyto informace nebyly v průběhu měněny a proto jejich vypovídací schopnost byla pouze orientační až zanedbatelná. Funkce pro vyhledávání vhodných uživatelů fungovala s jedním omezením. Toto omezení nebylo chybou systému, ale opět souviselo s nespolehlivostí uživatelů. Důsledkem byla kritéria hledání omezená o přítomnost – správce si vyhledal vhodné uživatele a teprve po té zjišťoval možnosti jejich přítomnosti. Vznikala tak úspora potřeby kontaktovat každého uživatele pro zjištění jeho dovedností, ale stačila pouze krátká textová zpráva s vyhledaným uživatelem na potvrzení/dotázání jeho přítomnosti. Aplikace vykazovala naprosto vyrovnaný provoz, do kterého nebylo nutné zasahovat. Silnou stránkou byla její nepřetržitá dostupnost a měla jí být i stálá aktuálnost, což se díky nespolehlivosti a lehkomyslnosti uživatelů nepotvrdilo.

6.2

Negativa vývoje

Poměrně nelogickým prvkem uživatelského rozhraní zaměstnanců a externistů bylo vkládání jejich dovedností a řeči kterou ovládali. Smyslem přiřazení jazyku k dovednosti byla jeho úroveň. Zaměstnanec, který ovládal polštinu na úrovni, kdy byl schopen použít pouze několik málo slovíček pro obsloužení zákazníka v půjčovně, nemohl být využit pro práci instruktora, kde by s touhle nedostatečnou slovní zásobou nevystačil. Přiřazení nebylo zcela nelogické, ale pokud chtěl uživatel skutečně vložit do profilu jaké funkce je schopen vykonávat v jakém jazyce, mohl vzniknout i nepotřebně zdlouhavý výpis. Navíc například u dovednosti řídit auto není podstatné zda umí uživatel polsky nebo anglicky, ale zda-li vlastní řidičské oprávnění. Tento problém by řešilo odloučení jazyka od dovedností číselníkem jazyků s návazností na číselník pokročilostí k danému jazyku.

32

6.3

6.3

Možnosti dalšího rozšíření

Možnosti dalšího rozšíření

Možností kam by se evidence mohla ubírat je celá řada – veškeré funkce mohou být hlouběji propracovány, přesněji upraveny pro potřeby uživatelů, upraven pohled na uživatelského rozhraní např. pomocí volitelných vzhledů a podobně: Z administrativních aplikací by mohla být dodělána funkce, která by byla schopna po skončení sezony vygenerovat potvrzení o absolvované praxi pro instruktory. Pomocí PHP by byl vygenerován PDF dokument, který by v sobě nesl osobní informace z profilu uživatele a součet dnů jeho praxe. Tento formulář by správce mohl jednoduše vytisknout a potvrdit razítkem a podpisem. V uživatelském prostředí správce v záložce „přítomnostiÿ může být přidána možnost zobrazení pouze vybraného časového období, čímž dojde k větší přehlednosti a menšímu objemu přenášených dat. Také vzhled může být podobný jako v uživatelské záložce zadávání přítomností, tedy v podobě virtuálního kalendáře. Jistému přepracování by se nevyhnula celá problematika dovedností, která by se musela znovu řešit od návrhové úrovně entit. Na ukládání jazykových dovedností by se vytvořil vlastní číselník jazyků s atributem pokročilostní úrovně. Nový číselník by byl spojen relací s entitou uživatele, ve vyhledávacím dotazu by se upravila volba kritérií jazyka zcela mimo dovedností, v závislosti na jazykové úrovni. Jednoduchou aplikací pro zlepšení komunikace by byl formulář pro odeslání emailu konkrétnímu uživateli. Tato funkce by na vybranou e-mailovou adresu (adresy) poslala informace, které by byly vepsány do vstupního pole formuláře. Došlo by tak k urychlení odesílání zpráv s tím, že by nebylo nutné mít k dispozici žádného emailového klienta či otevřenou poštovní schránku přes webové rozhraní. Významnou změnou by bylo dodělání aplikace pro změnu rolí uživatele. Tato aplikace by sloužila správci, který by mohl uživateli přidělit roli administrátora nebo sekundárního správce či nějakou novou roli, kterou by definoval. V současné době ovšem evidence s rolemi nepracuje a neklade na ně žádný jiný než informační důraz. V budoucnu by se mohl uživatel na základě role dostávat do správcovského rozhraní za předpokladu potřeby většího počtu správců. V současné době je tato úvaha bezpředmětná. Posledním námětem na rozšíření je zcela jistě bezpečnost. Současná aplikace neobsahuje žádné nadstandartní zabezpečovací prvky, veškerá autorizace je pouze srovnání hesla vloženého do vstupního pole s heslem v profilu uživatele uloženým v databázi. Aplikace nevyužívá SSL ani jiné prvky, které by významně zvedly bezpečnost nejen při autorizaci.

33

7

7

ZÁVĚR

Závěr

Práce popisuje analýzu, vývoj, provoz a zhodnocení aplikace evidence lidských zdrojů. V práci je analyzován původní stav, který nebyl dostačující. Byla zpracována nová řešení, která vycházela z rozšíření původních potřeb a námětů na další nové aplikační prvky. Tato řešení byla podkladem pro sestavení funkční logiky systému. Pro maximální dostupnost byla aplikace umístěna do prostředí internetu a byly zvoleny vhodné softwarové prostředky. Následovala implementace funkční logiky a dalších souvisejících komponent. Celá aplikace byla dokončena a podrobena zkušebnímu provozu. Následně byla nasazena do ostrého provozu. Výsledky jejího ročního nepřetržitého provozu byly analyzovány, zhodnoceny a popsány. Dotázáni byli i uživatelé aplikace, kteří s ní přicházeli do styku. Na jejich základě byly odhaleny chyby v aplikaci a v diskusi zpracovány možnosti dalšího rozšíření celé aplikace. Umístěním aplikace do prostředí internetu došlo k maximální dostupnosti pro všechny uživatele. V dnešní době je internet k dispozici z celé řady komunikačních zařízení (osobní počítač, mobilní telefon, notebook, . . .). Nehledě na použité zařízení je internet k dipozici pro široké spektrum operačních systémů a jejich internetových prohlížečů. V kapitole 5 byla vysvětlena metodika a teoretická východiska pro návrh a implementaci jednotlivých aplikačních komponent. V práci bylo zmíněno, že se jedná pouze o nekomerční pilotní projekt. Tento status nadále zůstává a v současné době probíhají další diskuse, na základě kterých bude aplikace přizpůsobena další sezóně a opětovně nasazena.

34

8

8

SLOVNÍČEK VYBRANÝCH POJMŮ

Slovníček vybraných pojmů

ASSEMBLER – Programovací jazyk nejnižší úrovně blížící se strojovému kódu DATOVÝ SKLAD – Zvláštní typ relační databáze, která umožňuje řešit úlohy zaměřené převážně na analytické dotazování nad rozsáhlými soubory dat. DEKLARATIVNÍ PROGRAMOVACÍ JAZYK – Založen na myšlence programování aplikace pomocí definic ”co se má udělat” a ne ”jak se to má udělat” ERD – Entitně-relační diagram, nástroj techniky datového modelování. Pomocí tohoto diagramu se popisují entity uvnitř informačního systému, jejich atributy a vzájemné vztahy IMPLEMENTACE – Proces při kterém se na základě výsledků analýzy a návrhu informačního systému vytváří konečný program INTEGRITNÍ OMEZENÍ – Určité mechanizmy zajišťující ochranu databáze před vložením nevyhovujících dat a ztrátou dat, která mají zůstat KUSTOMIZACE – Přizpůsobení informačního systému potřebám zákazníka na základě analýzy potřeb a formulací zákazníka OCI – Oracle Call Interface, funkce umožňují přístup k databázím Oracle, vysoká flexibilita a podpora např. globálních i lokálních proměnných PHP v Oracle prostředí PHP – Hypertext Preprocessor, skriptovací programovací jazyk určený pro programování dynamických internetových stránek, konzolových či desktopových aplikací POST – Určení způsobu jakou metodou dojde k předání hodnot HTML formuláře PRIMÁRNÍ KLÍČ – Je atribut nebo kombinace atributů, jednoznačně identifikující každý záznam v entitě databáze RELAČNÍ VAZBA – Vazba mezi daty dvou tabulek RELAČNÍ VZTAH – Nevlastními klíči reprezentovaná relace SEKVENCE – Pomocí objektu sekvence se dá snadno vytvářet předdefinovaná fronta číselných posloupností SQL – Structured Query Language, standardizovaný dotazovací jazyk používaný pro práci s daty v relačních databázích SŘBD – Systém řízení báze dat, obsahuje soubor programů, které manipulují a obhospodařují údaje v databázi SSL – Secure Socket Layers, bezpečnostní kódovací prvek mezi transportní a aplikační vrstvou, brání odposlechu, změně dat a podvrhování zpráv TRANSAKČNÍ SYSTÉM – Pravidla posloupnosti provádění jednotlivých transakcí nad databází, zabraňuje kolizím současných požadavků více uživatelů

35

9

9

LITERATURA

Literatura

Gruber, M. Mistrovství v SQL. Praha: SoftPress, 2004., ISBN 80-86497-62-3. Dohnal, J., Pour, J. Architektury informačních systémů: v průmyslových a obchodních podnicích. 1 vyd. Praha: Ekopress, s.r.o., 1997, 301 s. ISBN 80-8611902-5. Lacko, L. Informační systémy : Specifikace, realizace, provoz. 1 vyd. Brno: Computer Press, 202. 464 s., ISBN 80-7226-699-3. Lacko, L. Oracle : správa, programování a použití databázového systému. Brno : Computer Press, 2003. 298 s., ISBN 80-7226-975-5. Král, J. Informační systémy : Specifikace, realizace, provoz. 1 vyd. Brno: SCIENCE, 1998. 358 s., ISBN 80-86083-00-4. Kyte, T. Oracle : návrh a tvorba aplikací. 1 vyd. Brno: CP Books, 2005. 694 s., ISBN 80-251-0569-5. Castagnetto, J., Rawat, H., Schumann, S., Scollo, CH., Veliath, D. Programujeme PHP profesionálně. Praha : Computer Press, 2002. 656 s., ISBN 80-7226-310-2. Theriault, M., Newman, A. Bezpečnost v oracle. Brno : Computer Press, 2004. 514 s., ISBN 80-7226-979-8. Theriault, M., Loney, K. Mistrovství v Oracle : Oracle 9i, 8i a 8. Praha : Computer Press, 2003. 860 s., ISBN 80-7226-635-7. Welling, L., Thomson, L. PHP a MySQL : rozvoj webových aplikací. 2 vyd. Praha : Softpress, 2003. 910 s., ISBN 80-86497-60-7. Kiyosaki, R., Letcher, L. S. Cashflow kvadrant. Praha : Pragma, 1999. 290 s., ISBN 80-7205-853-3. Žák, K. Historie relačních databází [online]. Poslední aktualizace 2001-10-19, [cit. 2007-12-12], Česky. Dostupný na . Kosek, J. Aplikace na webu [online]. 1999, [cit. 2008-03-25], Česky. Dostupný na . Paláček, L. Elektronický učební text pro MS SQL Server 2000 [online]. [cit. 200803-20], Česky. Dostupný na . Wikipedia Oracle [online]. Poslední aktualizace 2007-09-13, [cit. 2008-03-28], Česky. Dostupný na . Wikipedia SQL [online]. Poslední aktualizace 2007-01-21, [cit. 2008-02-22], Česky. Dostupný na . 36

Přílohy

A SEZNAM PŘÍKAZŮ SQL PRO VYTVOŘENÍ ENTIT

A

Seznam příkazů SQL pro vytvoření entit

create table c_role (id number(20) primary key, role varchar2(25)) create table c_pohlavi (id number(1) primary key, pohlavi varchar2 (4)) create table c_sezony (id number(5) primary key, od_dne varchar2(4 ), do_dne varchar2(4)) create table c_dovednosti (id number(5) primary key, nazev varchar 2(30)) create table c_jazyky (id number(5) primary key, druh varchar2(25) ) create table c_sablona (id number(5) primary key, nazev varchar2(2 5), popis varchar2(150)) create table uzivatel (id number(5) primary key, jmeno varchar2(25 ) not null, prijmeni varchar2(25), kontakt varchar2(60), email var char2 (60), role number(1) references c_role check(role>0 and role <4) not null, heslo varchar2(40) not null, pohlavi number(1) refer ences c_pohlavi check(pohlavi IN (0,1)) not null) create table atributy (uzivatel number(5) primary key references uzivatel, atribut number(5) not null references c_sablona, hodnota varchar2(200)) create table hodnoceni (osoba number(5) not null references uzivate l, sezona number(5) not null references c_sezony, zadal number(5) not null references uzivatel, hodnoceni varchar2(200)) create table pritomnost (uzivatel number(5) not null references uzi vatel, sezona number(5) not null references c_sezony, den varchar2( 10)) create table dovednosti (uzivatel number(5) not null references uzi vatel, dovednost number(5) not null references c_dovednosti, jazyky number(5) not null references c_jazyky)

38

B PRÁCE SE SEKVENCÍ

B

Práce se sekvencí

create sequence uzivatel_seq start with 2 maxvalue 1000 cache 2 // vytvoření sekvence select uzivatel_seq.nextval from dual // vypsání (a zahození) další přidělené hodnoty $dotaz = "insert into uzivatel values (uzivatel_seq.nextval, ’$_POST[jmeno]’, ’$_POST[prijmeni]’, ’$_POST[kontakt]’, ’$_POST[email]’, 2, ’$_POST[heslo]’, $_POST[pohlavi])"; // využití sekvence při vkládání alter sequence uzivatel_seq nocache // vypnutí předchystávání hodnot drop sequence uzivatel_seq // smaže sekvenci

39

Návrh informačního systému pro vedení evidence pracovníků

Recommend Documents