WWW APLIKACE PRO PODPORU ORGANIZACE VÝUKY INFORMATIKA I

VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY

FAKULTA STROJNÍHO INŽENÝRSTVÍ ÚSTAV AUTOMATIZACE A INFORMATIKY FACULTY OF MECHANICAL ENGINEERING INSTITUTE OF AUTOMATION AND COMPUTER SCIENCE

WWW APLIKACE PRO PODPORU ORGANIZACE VÝUKY INFORMATIKA I COMPUTER AIDED ORGANIZATION OF INF I COURSES

BAKALÁŘSKÁ PRÁCE BACHELOR'S THESIS

AUTOR PRÁCE

TOMÁŠ FRITZ

AUTHOR

VEDOUCÍ PRÁCE SUPERVISOR

BRNO 2007

Ing. JAN ROUPEC, Ph.D.

Strana 3

ZADÁNÍ ZÁVĚREČNÉ PRÁCE

Strana 5

LICENČNÍ SMLOUVA

Strana 7

ABSTRAKT Bakalářská práce se zabývá realizací WWW aplikace umožňující evidenci plnění povinností, které jsou kladeny na studenty během studia předmětu Informatika I, nutných k udělení klasifikovaného zápočtu. Práce obsahuje postupy analýzy, návrhu a implementace aplikace. Jsou zde také uvedeny technologie, které byly použity při jejím vzniku a funkční popis vytvořeného řešení, který může sloužit jako manuál.

ABSTRACT Bachelor´s thesis deals with realization of WWW application susceptible to file fulfilmet of tasks demanded from students during INF I courses, necessary to conferment classified inclusion. Work contains processes of analysis, design and implementation of application. There are also mentioned technologies that was used for creation of this aplication and functional description of created solution that is able to serve as manual.

KLÍČOVÁ SLOVA WWW aplikace, evidence povinností, výuka Informatiky, PHP, Herodis.

informační systém

KEYWORDS WWW application, file of tasks, INF courses, PHP, information system Herodis.

Strana 9

PODĚKOVÁNÍ Děkuji vedoucímu své bakalářské práce Ing. Janu Roupcovi, Ph.D. za všechny cenné rady, připomínky a odborné vedení, které mi poskytl během vzniku této práce.

Strana 11

Obsah: 1 2

Úvod...........................................................................................................................13 Použité technologie....................................................................................................15 2.1 Relační databázový model........................................................................................15 2.2 Systémy pro správu relační databáze........................................................................15 2.3 Jazyk SQL................................................................................................................16 2.4 Jazyk PHP.................................................................................................................17 2.5 Jazyk HTML.............................................................................................................18 2.6 JavaScript.................................................................................................................18 3 Analýza.......................................................................................................................19 3.1 Určení cílů úkolu......................................................................................................19 3.2 Analýza existující databáze......................................................................................19 3.3 Vytvoření datové struktury.......................................................................................20 3.4 Konečná struktura databáze......................................................................................22 3.4.1 Tabulka UDALOST....................................................................................................22 3.4.2 Tabulka HODNOCENI...............................................................................................23 3.4.3 Tabulka ZAPOCET.....................................................................................................23 3.4.4 Relační schéma databáze.............................................................................................24 4 Implementace............................................................................................................25 4.1 Bezpečnost................................................................................................................25 4.2 Připojení k databázi..................................................................................................25 4.3 Skripty aplikace........................................................................................................25 4.4 Instalace....................................................................................................................27 4.5 Používání aplikace....................................................................................................27 4.5.1 Seznam událostí..........................................................................................................27 4.5.2 Přidání nové události...................................................................................................27 4.5.3 Úprava události...........................................................................................................28 4.5.4 Smazání události.........................................................................................................28 4.5.5 Hodnocení studentů.....................................................................................................28 4.5.6 Přidání a smazání studenta..........................................................................................29 4.5.7 Udílení zápočtu...........................................................................................................30 5 Závěr..........................................................................................................................31 6 Seznam použité literatury........................................................................................33

Strana 13

1

ÚVOD

Díky masivnímu rozšíření internetu v posledním desetiletí se stále častěji stávají webové informační systémy nezbytnou součástí mnoha institucí a firem. Takovéto informační systémy bývají obvykle rozděleny do menších nezávislých a mezi sebou navzájem propojitelných celků – modulů, které obsluhují konkrétní procesy firmy či instituce. Právě postupy návrhu a tvorby modulu informačního systému Herodis fakulty strojního inženýrství VUT v Brně jsou obsahem této práce. Modul řeší problém, kdy se na výuce předmětu Informatika I u každé rozvrhové skupiny podílejí tři vyučující a klasifikovaný zápočet udílí pouze jeden z nich. K jeho udělení potřebuje znát hodnocení studentů od ostatních vyučujících. Proto si aplikace bere za cíl umožnit obsluhu evidence požadavků, které jsou kladeny na studenty v průběhu studia tohoto předmětu a plnění těchto povinností jednotlivými studenty. Prvním krokem v tvorbě takovéto aplikace je obvykle analýza zadaného úkolu. Ta vede ke zjištění požadavků a obecných úkonů koncového uživatele, které má vytvořené řešení splňovat. Z těchto požadavků se následně vychází při návrhu datové struktury databáze. Databáze jsou základní technologií infrastruktury informačních systémů a proto se jedná o nejdůležitější fázi tvorby aplikace. Kombinace kvalitní aplikace se špatně navrženými daty způsobuje nepřesnost získávaných informací, v horším případě jejich neplatnost. Proto je třeba pro její správnou a bezproblémovou funkčnost věnovat návrhu databáze dostatečné prostředky. Třetí fáze zahrnuje samotné vytvoření aplikace, která umožní uživateli pracovat s daty uloženými v databázi a její implementace do informačního systému. Během tohoto procesu je nutné brát v úvahu stávající hardwarové a softwarové vybavení a aplikaci těmto podmínkám přizpůsobit.

Strana 15

2

POUŽITÉ TECHNOLOGIE

Tato kapitola si bere za cíl seznámení s technologiemi, které byly použity při vývoji. Aplikace je vytvořena především pomocí skriptovacího jazyka PHP. Tento jazyk také úzce spolupracuje s jazykem HTML, a pro komunikaci s relační databází je využíván jazyk SQL. Jako systém řízení báze dat je v tomto konkrétním případě využit systém Oracle.

2.1

Relační databázový model

Relační databáze byla poprvé představena v roce 1969 a v současnosti se bezesporu stala nejrozšířenějším modelem používaným při správě databází. Tvůrcem tohoto databázového modelu je Dr. Edgar F. Codd. [3] Dr. Codd svůj relační model formálně představil v červnu 1970 v mezní práci nazvané „Relační model dat pro velké sdílené databanky“ (A Relational Model of Data for Large Shared Databanks). Svůj model založil na dvou matematických disciplínách – teorii množin a predikátové logice prvního řádu. Dokonce i jméno modelu je odvozeno z pojmu „relace“, který je součástí teorie množin. [3] Relační databáze ukládá data ve vztazích, které uživatel vidí jako tabulky. Každý vztah je složen z uspořádaných n-tic, neboli záznamů, a atributů, neboli polí. Skutečné uspořádání záznamů, neboli polí, je v databázi zcela nepodstatné a každý záznam v tabulce je identifikován polem, které obsahuje unikátní hodnotu – tzv. primární klíč. Toto jsou dva základní rysy relační databáze, které umožňují, že data mohou existovat nezávisle na svém fyzickém uložení v počítači. Uživatel nemusí znát fyzické umístění záznamu, pokud z něj chce získat data. To je právě rozdíl oproti hierarchickému a síťovému databázovému modelu, ve kterém je znalost umístění dat klíčová. [3] Relační databáze má oproti jiným modelům několik výhod [3], např.: 



 

Zabudovaná víceúrovňová integrita. Integrita dat je zabudována přímo do modelu na úrovni položek, aby se zajistila přesnost dat. Na úrovni tabulek zajišťuje, že záznamy nejsou duplicitní a detekuje chybějící hodnoty primárních klíčů. Na úrovni vztahů zajišťuje, že vztah mezi dvojicí tabulek je platný. Logická a fyzická nezávislost dat na databázové aplikaci. Ani změny uživatele v logickém návrhu, ani změny poskytovatele databázového softwaru ve fyzické implementaci databáze neovlivní aplikaci postavenou pro původní logický návrh a databázový software. Garantování konzistence a přesnosti dat. Data jsou konzistentní a přesná díky různým úrovním integrity, které se dají v databázi vynutit. Snadné získávání dat. Na základě uživatelova příkazu mohou být data získána buď z určité tabulky, nebo z libovolného počtu tabulek, které jsou ve vztahu. To uživateli umožňuje zobrazovat informace téměř neomezeným počtem způsobů.

Tyto a jiné výhody se ukázaly přínosné pro mnoho aplikací a všechny, kdo potřebují sbírat a spravovat data. V současnosti se relační databáze stala implicitní volbou.

2.2

Systémy pro správu relační databáze

Systém pro správu relační databáze (RDBMS – relational database management system) je program, který se používá k vytvoření, udržování, modifikování a správě relační databáze. Mnoho RDBMS také zajišťuje nástroje pro vytváření aplikací pro koncového uživatele, které pracují s daty uloženými v databázi. Kvalita tohoto systému je přímo úměrná tomu, jak podporuje relační model. Dokonce i mezi „pravými“ RDBMS se podpora relačního modelu liší podle výrobce a na plnou implementaci relačního databázového modelu se teprve čeká. Přesto se všechny RDBMS neustále vyvíjejí a podporují stále více funkcí. [3] Potřeba sdílet data se stala zřejmou během 80. a 90. let, kdy stále více a více uživatelů začalo používat databáze. Myšlenka centrálně uložené databáze, která může být zpřístupněna více

Strana 16

2 Použité technologie

uživatelům, se zdála být jako dobrý nápad. Zcela jistě by to usnadnilo implementaci správy dat a bezpečnosti. Producenti databázových systémů na tuto myšlenku odpověděli vývojem RDBMS klient/server. [3] Jak ukazuje obrázek 1, v tomto systému jsou data uložena na počítači sloužícím jako databázový server a uživatelé s daty pracují pomocí aplikací spuštěných na jejich vlastních počítačích, neboli databázových klientech. Vývojář databáze používá RDBMS klient/server k vytvoření a správě databáze a vytvoření provázané aplikace pro koncového uživatele. Implementuje integritu a bezpečnost dat na databázovém serveru a tím umožňuje založit množství různých uživatelských aplikací na jedné množině dat, aniž by byla ohrožena bezpečnost, nebo integrita dat. RDBMS klient/server se využívají pro správu velkých množství sdílených dat. Mezi novější produkty v této oblasti patří Microsoft SQL Server 2000 od Microsoft Corporation a Oracle10i Application Server od Oracle Corporation. [3]

Obr. 1 Typická architektura klient/server.

2.3

Jazyk SQL

S relačními databázemi je úzce spojen pojem SQL (Structured Query Language), neboli strukturovaný dotazovací jazyk. Jeho základní model je obecně použitelný pro většinu relačních databází. Historie jazyka spadá do 70. a 80. let. 20. století. V 70. letech probíhal ve firmě IBM výzkum relačních databází. Bylo nutné vytvořit sadu příkazů pro ovládání těchto databázi. Vznikl tak jazyk SEQUEL (Structured English Query Language). Cílem bylo vytvořit jazyk, ve kterém by se příkazy tvořily syntakticky co nejblíže přirozenému jazyku (angličtině). [6] K vývoji jazyka se přidaly další firmy. V r. 1979 uvedla na trh firma Relational Software Inc. (dnešní Oracle Corporation) svůj relační databázový systém Oracle. IBM uvedla v roce 1981 nový systém SQL/DS a v roce 1983 systém DB2. Dalšími systémy byly např. Progress, Informix a SyBase. Ve všech těchto systémech se používala varianta jazyka SEQUEL, který byl přejmenován na SQL. [6] Relační databáze byly stále významnější, a bylo nutné jejich jazyk standardizovat. Americký institut ANSI původně chtěl vydat jako standard zcela nový jazyk RDL. SQL se však prosadil a ANSI založil nový standard na tomto jazyku. Ten bývá označován jako SQL-86 podle roku, kdy byl přijat. [6] V dalších letech se ukázalo, že SQL-86 obsahuje některé nedostatky a naopak v něm nejsou obsaženy některé důležité prvky týkající se hlavně integrity databáze. V roce 1992 byl proto přijat nový standard SQL-92 (někdy se uvádí jen SQL2). Zatím nejnovějším je SQL3 (SQL-99), který reaguje na potřeby nejmodernějších databází s objektovými prvky. [6] Standardy podporuje prakticky každá relační databáze, ale obvykle nejsou implementovány

2 Použité technologie

Strana 17

vždy všechny požadavky normy. A naopak, každá z nich obsahuje prvky a konstrukce, které nejsou ve standardech obsaženy. Přenositelnost SQL dotazů mezi jednotlivými databázemi je proto omezená. [6] SQL patří mezi tzv. deklarativní programovací jazyky, což v praxi znamená, že kód jazyka SQL nepíšeme v žádném samostatném programu (jako by tomu bylo např. u jazyka C nebo Pascal), ale vkládáme jej do jiného programovacího jazyka, který je již procedurální. [7] SQL se skládá z několika částí. Některé části jsou určeny pro administrátory a návrháře databázových systémů, jiné pak pro koncové uživatele a programátory. První částí jazyka SQL je jazyk DDL - Data Definition Language. Jedná se o jazyk pro vytváření databázových schémat a katalogů. Způsob ukládání tabulek definuje jazyk SDL - Storage Definition Language. Třetí částí pro návrháře a správce je jazyk VDL - View Definition Language, určující vytváření pohledů (pohled si lze představit jako virtuální tabulku složenou z různých jiných tabulek). Poslední částí je jazyk DML - Data Manipulation Language, který obsahuje základní příkazy INSERT, UPDATE, DELETE a nejpoužívanější příkaz SELECT. S jazykem DML pracují nejvíce koncoví uživatelé a programátoři databázových aplikací. [7]

2.4

Jazyk PHP

PHP (rekurzivní zkratka PHP: Hypertext Preprocessor, „PHP: Hypertextový preprocesor“, původně Personal Home Page) je skriptovací programovací jazyk určený především pro programování dynamických internetových stránek..[6] PHP je nástupcem staršího produktu, nazvaného PHP/FI. PHP/FI vytvořil Rasmus Lerdorf v roce 1995, na počátku jako jednoduchou sadu skriptů v jazyce Perl pro zpracování záznamů o přístupech k jeho webu. Tuto sadu nazval 'Personal Home Page Tools'. Protože byla třeba větší funkčnost, napsal Rasmus mnohem rozsáhlejší implementaci v C, která byla schopna komunikovat s databázemi a umožňovala uživatelům vyvíjet jednoduché dynamické aplikace pro Web. Rasmus se rozhodl uvolnit zdrojový kód PHP/FI pro všechny, takže ho může používat kdokoli, stejně jako opravovat chyby a vylepšovat kód. [8] PHP/FI, což znamená Personal Home Page / Forms Interpreter, obsahovalo něco ze základní funkcionality PHP, jak ho známe dnes. Mělo proměnné perlovského typu, automatickou interpretaci formulářových proměnných a syntaxi vloženou do HTML. V roce 1997 se PHP/FI 2.0, druhá implementace psaná v C, stala kultovní záležitostí pro (odhadem) tisíce uživatelů po celém světě, a s přibližně 50.000 doménami oznamujícími nainstalované PHP/FI, což čítalo zhruba 1 % všech domén na Internetu. [8] PHP 3.0 byla první verze, která se velmi blížila verzím užívaným v dnešní době. Vytvořili ho Andi Gutmans a Zeev Suraski v roce 1997 jako kompletně přepsaný celek, poté co shledali PHP/FI 2.0 výrazně "poddimenzované" pro vývoj svých aplikací pro e-komerci. Ve snaze spolupracovat a zahájit budování nad existující uživatelskou základnou PHP/FI, rozhodli se Andi, Rasmus a Zeev pracovat společně a prohlásit PHP 3.0 za oficiálního nástupce PHP/FI 2.0, a vývoj PHP/FI 2.0 byl v podstatě zastaven. [8] Jednou z nejsilnějších zbraní PHP 3.0 byly jeho obrovské možnosti rozšíření. K poskytnutí pevné infrastruktury pro mnoho různých databází, protokolů a API koncovým uživatelům, přilákaly možnosti rozšíření PHP 3.0 také tucty vývojářů, kteří se připojili a vytvořili nové rozšiřující moduly. Toto byl nesporně klíč k obrovskému úspěchu PHP 3.0. Jiným klíčovým prvkem v PHP 3.0 byla podpora objektově orientované syntaxe a mnohem silnější a konzistentnější syntaxe jazyka. [8] Nový engine, nazvaný 'Zend Engine' (sestaven z jejich křestních jmen, Zeev a Andi), úspěšně splnil cíle návrhu a byl uveden v polovině roku 1999. PHP 4.0, založené na tomto enginu a doplněné širokou škálou nových prvků, bylo oficiálně uvolněno v květnu 2000. K podstatně zvýšenému výkonu této verze, přidává PHP 4.0 další klíčové prvky, jako je podpora pro mnoho WWW serverů, HTTP sessions, buffering výstupu, bezpečnější způsoby zpracování vstupů uživatele a mnoho nových jazykových konstruktů. [8] Nejnovějším přírůstkem je PHP 5.0, které je do značné míry zpětně kompatibilní s PHP 4. V nové verzi jazyka byly především posíleny bezpečnostní mechanismy (což může vést

Strana 18

2 Použité technologie

k nefunkčnosti některých špatně postavených aplikací pro PHP 4) a uveden nový, podstatně kvalitnější objektový model, umožňující používat PHP jako skutečný objektově orientovaný jazyk.[8]

2.5

Jazyk HTML

Jazyk html (Hyper Text Markup Language, hypertextový jazyk s příznaky) je popisný jazyk stránky. Jazyk sám je popsán pomocí jazyka SGML (Standard Generalized Markup Language). SGML je metajazyk (jazyk určený primárně k popisu dalších jazyků), a je normalizován v ISO (schváleno 1986), HTML je tedy aplikací v SGML. Jazyk html popisuje, jak budou jednotlivá data zobrazena prohlížečem. V době vzniku autor jazyka html nepředpokládal, že by se stránky vytvářely přímo v html, uvažoval o existenci generátoru stránek, jehož výstupem bude popis stránky v html. V dnešní době existuje řada programových produktů schopných úlohu takového generátoru více či méně úspěšně zastávat, vytváření stránek přímo v jazyce html však není výjimkou. [5] Jazyk html prošel a stále ještě prochází bouřlivým vývojem. V roce 1994 bylo založeno www konsorcium (WWWC, W3C), které má vývoj jazyka na starosti. Vzhledem k tomu, že řadu rozšíření zavedli do jazyka přímo výrobci prohlížečů, není úloha konsorcia jednoduchá a jsou časté případy, kdy stejně popsanou stránku (a napsanou v souladu s oficiální verzí jazyka) zobrazují různé prohlížeče různě. [5] Jazyk html je popisným jazykem stánky, má tedy podobnou úlohu jako např. postscript. Protože ale cílovou plochou pro zobrazení je obrazovka (resp. okno), neobsahuje html prostředky pro přesný popis zobrazení, ale pouze doporučení typu „zde začíná odstavec“, „tohle je nadpis“, „zde je centrovaný obrázek“ apod. V novějších verzích jazyka sice jsou prostředky pro poměrně přesné ovlivnění vzhledu výstupu, využití těchto prostředků může být ale problematické vzhledem k tomu, že každý počítač – prohlížeč – používá jiné rozlišení, jiný počet současně zobrazitelných barev, podporuje různé fonty, velikost okna prohlížeče si může každý uživatel nastavit zcela libovolně atd. [5] Příkazy jazyka html (položky, příznaky, tagy, značky) se zapisují ve tvaru <xxx>, jsou tedy uzavřené v úhlových závorkách. Značky existují párové a nepárové, párových značek je většina a označují začátek platnosti značky a konec platnosti (ukončovací značka se zapisuje jako . Dokument html je koncipován jako nezávislý na platformě a aplikaci. [5]

2.6

JavaScript

JavaScript je multiplatformní, objektově orientovaný skriptovací jazyk, jehož autorem je Brendan Eich z tehdejší společnosti Netscape. [6] Nyní se zpravidla používá jako interpretovaný programovací jazyk pro WWW stránky, vkládaný přímo do HTML kódu stránky. Jsou jím obvykle ovládány různé interaktivní prvky GUI (tlačítka, textová políčka) nebo tvořeny animace a efekty obrázků. [6] Jeho syntaxe patří do rodiny jazyků C/C++/Java. JavaScript byl v červenci 1997 standardizován asociací ECMA (Europen Computer Manufacturers Association) a v srpnu 1998 ISO. Standardizovaná verze JavaScriptu je pojmenována jako ECMAScript a z ní byly odvozeny i další implementace, jako je například ActionScript. [6] Program v JavaScriptu se obvykle spouští až po stažení WWW stránky z Internetu (tzv. na straně klienta), na rozdíl od ostatních jiných interpretovaných programovacích jazyků (např. PHP a ASP), které se spouštějí na straně serveru ještě před stažením z Internetu. Z toho plynou jistá bezpečností omezení, JavaScript např. nemůže pracovat se soubory, aby tím neohrozil soukromí uživatele. [6]

Strana 19

3

ANALÝZA

Účelem této kapitoly je zanalyzovat zadaný úkol, zformulovat požadavky na výslednou aplikaci a navrhnout databázi pro tuto aplikaci. Je nutné zjistit, jaká data bude potřeba do databáze dodat – neboli jaká data bude zapotřebí sledovat.

3.1

Určení cílů úkolu

Každá databáze je vytvořena k určitému specifickému účelu, ať už je to řešení určitého podnikatelského problému, správa denních transakcí, nebo má sloužit jako součást informačního systému, jak je tomu v tomto případě. Účel databáze určuje a definuje zadání úkolu. Avšak spolu s formulací úkolu je nutné navrhnout také cíle úkolu. Cíle úkolu jsou tvrzení, která reprezentují obecné úkony, které uživatel může s daty v aplikaci provádět. Tyto cíle se využívají k podpoře formulace úkolu a pomáhají určit různé aspekty struktury databáze. Hlavním účelem aplikace by mělo být umožnit proces evidence povinností studentů a plnění těchto povinností jednotlivými studenty. Cíle úkolu, které jsou nezbytné k návrhu aplikace, lze tedy zjistit z pohledu vyučujících, kteří mají na starosti hodnocení studentů. 

  







Povinnosti pro udělení zápočtu se mohou např. v různých ročnících lišit. Z toho vyplývá, že by aplikace měla splňovat jistou universalitu pro vytváření různých hodnotících požadavků na studenty. Samozřejmostí by měla být i možnost tyto požadavky odstranit nebo je pozměnit. Tuto možnost by však měl mít pouze uživatel, který tento záznam vytvořil nebo administrátor. Pro potřeby hodnocení je nutné mít možnost k jednotlivým povinnostem přidat jakýkoliv počet studentů a přiřazovat k nim údaj o splnění povinnosti. Tento údaj může být různý pro různé typy požadavků. Například pro hodnocení testu bude chtít uživatel zadávat číselnou hodnotu, ale pro jinou událost (např. vytvoření nějakého programu studentem) pouze, zda student tuto povinnost splnil či nesplnil. Protože uživatel, který uděluje zápočet, potřebuje znát hodnocení studentů i od jiných vyučujících, je nutné, aby si mohl prohlížet hodnocení studentů i u požadavků od jiných uživatelů. Z hlediska přehlednosti obsluhy udělování zápočtu by také bylo výhodné mít možnost prohlížet hodnocení studentů ne podle jednotlivých povinností, ale podle jednotlivých studentů. Jelikož se na výuce jedné rozvrhové skupiny podílí více vyučujících, měl by mít uživatel možnost hodnotit studenty i u událostí ostatních vyučujících. Například pokud je vytvořen požadavek na studenty na odevzdání programu uživatelem, který vyučuje pouze polovinu studijní skupiny, měl by mít možnost v tomto požadavku hodnotit studenty i uživatel, který vyučuje druhou polovinu této skupiny. Z hlediska přehlednosti a integrity dat by tedy měl být u každého hodnocení záznamenán i údaj o tom, kdo jej uložil.

Tímto jsou stanoveny základní požadavky, které musí aplikace splňovat. Následuje analýza existující databáze a vytvoření datové struktury databáze, která z těchto stanovených cílů vychází.

3.2

Analýza existující databáze

Druhá fáze procesu návrhu zahrnuje analýzu existující databáze a také analýzu toho, jakým způsobem jsou data shromažďována a prezentována. Analýza stávající databáze je v tomto případě vhodná především proto, že aplikace bude pro svou činnost používat některé její tabulky. Z cílů úkolu jasně vyplývá, že aplikace bude používat především tabulky, z nichž se získávají údaje o vyučujících, studentech a jejich obsazení studijních skupin, protože by bylo krajně nevhodné tyto tabulky pro potřeby aplikace vytvářet znovu. Příslušnost studenta ke studijní skupině je v datovém skladu VUT řešeno pomocí mnoha tabulek, které zobrazuje relační schéma na obrázku 2. Vhodným způsobem, jak získávat tyto údaje

Strana 20

3 Analýza

v samotné aplikaci, je vytvoření pohledu. Pohledy jsou užitečné zejména v případě, kdy jsou založeny na několika provázaných tabulkách jak je tomu i zde.

Obr. 2 Relační schéma uložení příslušnosti studenta ke studijní skupině v datovém skladu VUT. Tyto tabulky jsou pro potřeby zjišťování údajů o studentech a jejich obsazení studijních skupin postačující. Avšak pouze pomocí těchto tabulek by aplikace fungovat nemohla, a proto je také vhodné zanalyzovat, jakým způsobem jsou informace shromažďovány v současné době. To obvykle probíhá způsobem zápisu do tabulky, která obsahuje matici informací o studentech, hodnotících událostech a hodnocení studentů. Takovýto zápis znázorňuje následující tabulka. Student Os.číslo 53900 24780 12522 …

3.3

Test 1 Test 2 Jméno Příjmení 12.10. 20.11 Jan Novák 21 14 Kamil Plachý 12 7 Aleš Hloch 15 11 … … … Tab. 1 Zaznamenávání hodnocení studentů do tabulky.

… … … … … …

Vytvoření datové struktury

Vytváření datových struktur databáze je třetí fází v procesu návrhu databáze. Je nutné určit entity, které budou tabulkami reprezentovány, jejich atributy a jejich vzájemné vztahy. Tento návrh musí také zaručit dostatečnou integritu dat. Integrita dat označuje platnost, konzistentnost a přesnost dat v databázi. Je třeba zdůraznit fakt, že stupeň přesnosti informací získávaných z databáze je v přímé úměře ke stupni integrity dat uložených v databázi. Integrita dat je jedním z nejdůležitějších aspektů procesu logického návrhu databáze a nesmí se podceňovat, přehlížet nebo dokonce částečně opomíjet. Takovýto přístup způsobuje nebezpečí záplavy chyb, které jsou velmi těžko naleznutelné a odstranitelné. Důsledkem toho bude rozhodování na základě informací, které jsou v lepším případě nepřesné, v horším neplatné. [3] Je nutné také provést proces normalizace, který slouží k eliminaci redundantních a duplicitních dat a k eliminaci budoucích problémů s vkládáním, rušením a aktualizací dat.

3 Analýza

Strana 21

Normalizace by měla vést k vzniku tabulek, které lze snadno udržovat a efektivně se na ně dotazovat. Normalizace má několik stupňů a správně navržené tabulky by měly splňovat alespoň 3. normální formu. Při návrhu datové struktury jsem tedy vycházel ze způsobů hodnocení studentů, který zobrazuje Tab. 1. Pokud chceme obdobné informace udržovat a sledovat pomocí databáze, bude zapotřebí tabulka HODNOCENI, která bude obsahovat osobní číslo studenta, údaje o požadavku a hodnocení studenta. Taková tabulka by mohla mít následující tvar. Os. číslo 53900 24780 12522 53900 24780 12522

Název Datum Test 1 12.10. Test 1 12.10. Test 1 12.10. Test 2 20.11. Test 2 20.11. Test 2 20.11. Tab. 2 Tabulka hodnocení studentů.

Hodnocení 21 12 15 14 7 11

U této tabulky však vznikají potíže, protože informace v tabulce jsou poněkud redundantní. Pro daný požadavek mají všechny záznamy stejný název a také stejné datum. Budeme-li zaznamenávat hodnocení tímto způsobem, nejen že budeme v každém novém záznamu pořizovat stejný název, ale i stejné datum. Těchto duplicitních informací je potřeba se zbavit. Řešení nabízí vytvoření nové tabulky UDALOST, ve které budeme uchovávat záznam o tom jaká událost se daného dne koná. Poté budeme moci u libovolného hodnocení určit, o jakou událost se jedná tím, že údaj o hodnocení zkombinujeme s informacemi ze seznamu událostí. To provedeme tak, že spojíme dohromady datum ze záznamu tabulky HODNOCENI se stejným datem z tabulky UDALOST . Získáme tak název události konané ve zvoleném dni, jak ukazuje obr. 3.

Obr. 3 Propojení tabulky HODNOCENI a UDALOST pomocí data. Jedním z požadavků kladených na tabulku UDALOST, který vyplývá z předchozího návrhu, je jednoznačnost data, protože pomocí každého data se spojují odpovídající záznamy tabulek UDALOST a HODNOCENI. Jinak řečeno, nelze v jednom dni zadat více událostí. Pokud by se tak stalo, měli bychom v tabulce HODNOCENI dvě sady záznamů a dva záznamy v tabulce UDALOST, všechny budou mít stejné datum a nebude možno určit, o kterou událost se jedná. Vypořádat se s tímto problémem není obtížné. Do tabulky UDALOST stačí přidat sloupec UDALOST_ID, který se použije k přiřazení jedinečných identifikačních čísel záznamů tabulky. Výsledek je znázorněn na Obr. 4.

Strana 22

3 Analýza

Obr. 4 Propojení tabulky HODNOCENI a UDALOST pomocí identifikačního čísla. Nyní se dohromady spojují tabulky HODNOCENI a UDALOST pomocí identifikačních čísel událostí a ne pomocí data. Proto už není nutné, aby bylo každé datum v tabulce UDALOST jedinečné. Jednoznačná musejí být pouze identifikační čísla, což znamená, že v jednom dni může být jakýkoliv počet událostí. Přestože nová tabulka HODNOCENI obsahuje redundantní data, je tato redundance přijatelná, protože je nejmenší možná. Ve skutečnosti každá databáze obsahuje určitou část redundantních dat. Mým cílem je však databázi zabezpečit tak, aby množství takových dat bylo jen absolutně nezbytné. Ze zadání a cílů úkolu je patrné, že je nutno zavést ještě jednu tabulku, která bude uchovávat informace o zápočtech udělených studentům.

3.4

Konečná struktura databáze

Tabulky z předcházejícího návrhu je však nezbytné doplnit o atributy, které zajistí lepší funkčnost, přehlednost, uživatelskou efektivnost aplikace a také integritu dat. Datové typy, jako např. NUMBER pro číselné záznamy, jsou voleny s přihlédnutím k databázovému systému Oracle (viz. [2]), pro který je tato aplikace určena. 3.4.1

Tabulka UDALOST

Tabulka UDALOST tedy slouží k uchovávání dat o jednotlivých událostech a požadavcích kladených na studenty v průběhu výuky. Zde je uvedena její konečná struktura a její atributy jsou popsány níže. UDALOST Název sloupce UDALOST_ID (PK) NAZEV DATUM POZNAMKA TYP EDITOVAL TS  



Datový typ NUMBER VARCHAR2 (40) DATE VARCHAR2 (100) NUMBER NUMBER DATE

UDALOST_ID – obsahuje jedinečné identifikační číslo události, které je zároveň primárním klíčem. Je zadáváno automaticky, aby byla zaručena jeho unikátnost. NAZEV – je datového typu VARCHAR2, délky 40 znaků. Je to povinný údaj, což znamená, že je nutné jej zadat a bez něj nemůže být událost uložena. Jak už z jména položky vyplývá, označuje textovým údajem název události a slouží jako hlavní položka k identifikaci události uživatelem. DATUM – je datového typu DATE. Je to údaj, ne o datu vložení události do databáze, ale o datu konání události. Není to povinná položka a není nutno ji zadat, je to však vhodné.

3 Analýza   



3.4.2

Strana 23

POZNAMKA – je datového typu VARCHAR2, délky 100 znaků. Slouží k bližší identifikaci a popisu události. Není to povinná položka a tak ji není nutné zadávat. TYP – v aplikaci nabývá pouze dvou hodnot a to 0 pro událost typu Číslo/Text nebo 1 pro událost typu Ano/Ne. Tento typ udává, jakým způsobem bude uživatel studenty hodnotit. EDITOVAL – obsahuje identifikační číslo vyučujícího, který událost založil. Slouží k identifikaci události, které se mají zobrazovat konkrétním uživatelům pro editaci a smazání, a také pro informaci ostatním uživatelům, kdo tuto událost založil. Je to povinná položka a ukládá se sama bez zásahu uživatele. TS – ukládá časový údaj o vložení či editaci záznamu v databázi. Slouží především pro administrační účely. Tato položka se do databáze ukládá sama bez zásahu uživatele. Tabulka HODNOCENI

Tabulka HODNOCENI je podstatě spojovací tabulkou mezi studentem a událostmi. Slouží k uložení hodnocení konkrétních studentů u konkrétních událostí. HODNOCENI Název sloupce Datový typ STUDENT_ID (CPK/FK) NUMBER UDALOST_ID (CPK/FK) NUMBER HODNOCENI VARCHAR2 (50) HODNOTIL NUMBER TS DATE  



 

3.4.3

STUDENT_ID – obsahuje identifikační číslo studenta. Je to povinný údaj a cizí klíč, který ve spojení s položkou UDALOST_ID tvoří primární klíč . UDALOST_ID – obsahuje identifikační číslo události, ke které je studentovi zadána hodnota. Je to taktéž povinný údaj, cizí klíč a spolu s položkou STUDENT_ID tvoří jedinečný primární klíč. HODNOCENI – ukládá hodnocení jednotlivých studentům u jednotlivých událostí zadané uživatelem. Je datového typu VARCHAR2, délky 50 znaků. Tento datový typ a délka je zvolena proto, aby měl uživatel možnost zadat nejen body či zda student požadavek splnil/nesplnil, na které by stačil celočíselný typ, ale aby měl také možnost v případě potřeby zadat kratší textový údaj. HODNOTIL – obsahuje identifikační číslo vyučujícího, který záznam uložil či editoval. Je to povinná položka a ukládá se sama bez zásahu uživatele. TS – Ukládá časový údaj o vložení či editaci záznamu v databázi. Slouží především pro administrační účely. Tato položka se do databáze ukládá sama bez zásahu uživatele. Tabulka ZAPOCET

Tabulka zápočet ukládá údaje o udělených zápočtech jednotlivým studentům. Ačkoliv má zápočet v této aplikaci pouze informativní účel, je vhodnou a doplňující položkou. ZAPOCET Název sloupce STUDENT_ID (PK) ZAPOCET ZAPOCETL TS

Datový typ NUMBER NUMBER NUMBER TIMESTAMP

Strana 24  





3.4.4

3 Analýza

STUDENT_ID – Obsahuje identifikační číslo studenta, ke kterému je přidáván záznam o zápočtu. Je to povinný údaj a primární klíč. ZAPOCET – Položka nabývá hodnot 0 až 6. Hodnot 1 až 6 pro jednotlivé stupně klasifikovaného zápočtu a 0 označující neudělení zápočtu. Není to povinný údaj, při nezadání hodnoty se v aplikaci automaticky zobrazuje jako neudělení zápočtu. ZAPOCETL – Obsahuje identifikační číslo vyučujícího, který záznam uložil či editoval. Je to povinná položka a ukládá se sama bez zásahu uživatele. Slouží pro informaci ostatním uživatelům kdo tento záznam uložil či editoval. TS – Ukládá časový údaj o vložení či editaci záznamu v databázi. Slouží především pro administrační účely. Tato položka se do databáze ukládá sama bez zásahu uživatele. Relační schéma databáze

Návrh datové struktury je tedy hotov. Obr. 5 znázorňuje celkové relační schéma databáze aplikace, využívající tabulek stávajícího datového skladu VUT s tabulkami nově vytvořenými.

Obr. 5 Relační schéma databáze.

Strana 25

4

IMPLEMENTACE

Ve fázi implementace je nutné brát v úvahu stávající hardwarové a softwarové vybavení, pro které je toto řešení určeno. Aplikace má být zařazena jako modul do informačního systému Herodis, z čehož vyplývají některé specifické vlastnosti.

4.1

Bezpečnost

Možnost vzájemné komunikace počítačů v síti i Internetu přináší mnoho nových a užitečných způsobů rychlého vyměňování a sdílení informací. Zároveň toto prostředí přináší jistá bezpečnostní rizika. Každá aplikace by měla na tyto rizika brát ohledy a být proti nim dostatečně chráněna.[1] V tomto případě je však aplikace zařazována jako modul do stávajícího informačního systému, který toto zabezpečení dostatečně obsluhuje, a tak není nutné podnikat žádná další dodatečná opatření.

4.2

Připojení k databázi

Každý SQL – server má svůj vlastní protokol, pomocí kterého s ním může klient komunikovat. Obvykle se k připojení k databázi používá nativních funkcí, nebo přístupu přes rozhraní ODBC. Použití nativních funkcí sebou přináší značnou nevýhodu v podobě malé přenositelnosti kódu. Nativní funkce jsou totiž pro každý RDBMS jiné, a tak by při jeho změně bylo nutné přepisovat značnou část kódu. ODBC slouží jako prostředník mezi klientskou aplikací a databázovým serverem. Rozhraní ODBC se volá jednotně a ODBC – ovladač pak požadavek předá databázovému serveru pomocí správného protokolu. Velkou výhodou ODBC tedy je, že stejným způsobem můžeme přistupovat k libovolné databázi. Nevýhodou však může být to, že přidává další vrstvu mezi aplikaci a nativní protokol databáze. [1] Fakultní informační systém však používá pro komunikaci s databází objekt. Tento objekt zapouzdřuje nativní funkce pro obsluhu RDBMS, které se používají v celé aplikaci. Při změně databázového systému tak stačí přepsat pouze nativní funkce v tomto objektu a aplikace se stane opět zcela funkční. Tím je do značné míry vyřešena, i když ne zcela odstraněna, přenositelnost kódu, a mezi aplikaci a databázový server není přidávána žádná další vrstva.

Obr. 6 Typy komunikace s SQL-serverem.

4.3

Skripty aplikace

Samotná aplikace pro svou funkci využívá 16 vlastních skriptů a 3 knihovny nadřazeného informačního systému. Pro lepší přehlednost o tom, jak aplikace tyto skripty využívá, zde uvádím jejich seznam s jednoduchým popisem funkce a schéma jejich propojení. Zdrojový kód je také, např. pro potřeby editace nebo rozšiřování, dostatečně okomentován.

Strana 26

4 Implementace

Skripty vlastní aplikace:       

udalost.php – zobrazuje seznam událostí. udalost_pridat.php – formulář pro přidání nové události. udalost_insert.php – provádí uložení záznamu o nové události do databáze. udalost_smazat.php – zobrazí potvrzení smazání události. udalost_delete.php – provádí samotné odstranění záznamu o události z databáze. udalost_upravit.php – zobrazí formulář pro editaci události. udalost_update.php – provede změnu záznamu o události v databázi.

     

hodnoceni.php – zobrazuje seznam studentů a umožňuje zadávat hodnocení. hodnoceni_insert.php – provádí uložení hodnocení do databáze. student_pridat.php – zobrazuje formulář umožňující přidávání studentů k události. student_insert.php – provede přidání studentů k události. student_smazat.php – zobrazí potvrzení smazání studenta. student_delete.php – provede odstranění záznamu z databáze.

  

vyber.php – formulář výběru studentů pro prohlížení a udílení započtu. zapocet.php – umožňuje udělování zápočtu nebo dodatečnou změnu hodnocení. zapocet_pridat.php – uloží nebo změní záznam o zápočtu nebo hodnocení studentů. Knihovny informačního systému Herodis:

  

herodis.php – knihovna spravující vzhled a styly aplikace. dblib.php – objekt sloužící k obsluze RDBMS. stdlib.php – obecně prospěšné funkce používané v systému.

Obr. 7 Schéma propojení skriptů aplikace.

4 Implementace

4.4

Strana 27

Instalace

Aplikace je konstruována jako modul informačního systému Herodis. Proto ji nelze provozovat samostatně. Instalace do informačního systému zahrnuje nakopírování skriptů aplikace do příslušného adresáře a vytvoření datové struktury nově navržených tabulek databáze. Pokud se knihovny systému nalézají v jiném adresáři je nutné změnit cesty k těmto knihovnám v jednotlivých skriptech.

4.5

Používání aplikace

Následuje funkční popis aplikace a úkonů, které lze v aplikaci provádět. Tato část tedy slouží jako manuál aplikace. 4.5.1

Seznam událostí

Hlavní stránka aplikace prezentuje seznam všech hodnotících událostí v systému. Seznam se dělí na události vlastní a ostatní. Události vlastní jsou vytvořeny přihlášeným uživatelem – tedy jeho vlastní, ostatní události jsou vytvořené jinými uživateli. Vlastní události má uživatel možnost změnit nebo smazat. U ostatních z logických důvodů tuto možnost nemá, avšak i to lze uživateli umožnit nastavením práv. To je vhodné např. pro administrační úkony. U každé události je také odkaz Hodnocení studentů, který slouží k přesměrování na formulář pro editaci hodnocení. Tento odkaz je uživateli přístupný i u ostatních událostí. Celý seznam událostí lze řadit sestupně nebo vzestupně podle jeho jednotlivých položek. Stránka obsahuje také odkaz na formulář pro přidání nové události.

Obr. 8 Hlavní strana prezentující seznam událostí. 4.5.2

Přidání nové události

Je-li zvolen odkaz pro přidání nové události na stránce seznamu událostí, skript předloží formulář umožňující tuto událost vytvořit a vložit do databáze. Uživatel zadá informace o názvu události, datum události, které je automaticky přednastaveno na aktuální datum, poznámku o události a vybere, o jaký typ události se jedná. Poznámka a datum jsou nepovinné údaje, a tak není nezbytně nutné je vyplnit. Po stisknutí tlačítka Přidej se informace o nové události uloží do databáze a stránka je přesměrována na seznam událostí, kde se zároveň vypíše informační text o úspěšnosti či neúspěšnosti této operace.

Strana 28

4 Implementace

Obr. 9 Formulář pro přidání nové události. 4.5.3

Úprava události

Stránka úpravy události obsahuje formulář shodný s formulářem pro vytvoření nové události s tím rozdílem, že pole formuláře jsou již přednastavena stávajícími informacemi a uživatel má možnost je změnit. Po stisknutí tlačítka Uložit změny dojde k editaci záznamu v databázi a zobrazení hlavní stránky, kde se vypíše informativní text o úspěšnosti této úpravy údajů. 4.5.4

Smazání události

Smazat událost lze opět pomocí odkazu v seznamu událostí. Pokud neobsahuje žádné hodnocené studenty, tak se aplikace dotáže, jestli si uživatel vážně přeje tuto událost smazat a vypíše údaje o této události. Jestliže vše souhlasí, může uživatel tuto operaci dokončit pomocí tlačítka Smazat. Skript provede odstranění záznamu z databáze a přesměrování na hlavní stranu seznamu událostí, kde oznámí zda byla operace úspěšná. Jestli ale událost již hodnocené studenty obsahuje, vypíše se pouze hlášení o tom, že událost nemůže být smazána proto, aby byla zachována celistvost dat v databázi.

Obr. 10 Potvrzení smazání události. 4.5.5

Hodnocení studentů

Zvolí-li uživatel hodnocení studentů konkrétní události v seznamu událostí, předloží skript stránku, na které se zobrazuje seznam studentů přiřazený k této události, jejich hodnocení a

4 Implementace

Strana 29

informace o události. Seznam lze vzestupně nebo sestupně řadit podle jednotlivých atributů. Po stisknutí tlačítka Editovat lze hodnocení studentů vkládat buďto do textového pole v případě typu Číslo/text, nebo volbou položky ano či ne z tzv. list boxu v případě události typu Ano/ne. Také se u každého studenta zobrazí odkaz sloužící k jeho odstranění. Pro potvrzení vložených hodnocení slouží tlačítko Uložit, které vloží či změní záznamy v databázi a vypíše hlášení o úspěšnosti této operace. Protože hodnotit studenty mají možnost i uživatelé, kteří tuto událost nezaložili, tak je v seznamu u každého hodnocení také uveden údaj o tom, kdo toto hodnocení do databáze uložil. Přidat studenty k události lze přes odkaz Přidat studenty.

Obr. 11 Hodnocení studentů. 4.5.6

Přidání a smazání studenta

Přidání studentů k události umožňují dvě pole se seznamem rozvrhových skupin a studentů. Z prvního pole si uživatel nejdříve zvolí skupinu, ze které chce studenta či studenty vložit. Následně z pole Student může zvolit jednotlivé studenty z této skupiny nebo může vložit celou skupinu. Volbu potvrdí tlačítkem Přidat, které provede přidání studentů k události. Uživatel má také možnost studenta vyhledat pomocí osobního čísla a jednoduchého formuláře. Smazání studenta je obdobné jako smazání události, aplikace opět vypíše údaje o studentovi a pokud vše souhlasí, uživatel dokončí smazání pomocí tlačítka Smazat.

Obr. 12 Přídání studentů k události.

Strana 30 4.5.7

4 Implementace

Udílení zápočtu

Pokud chce uživatel přistoupit k udílení zápočtu, tak si opět zvolí studenta či celou skupinu totožným způsobem jako u přidávání studenta k události. Poté se mu vypíše abecední seznam těchto studentů. U každého studenta jsou uvedeny události, u nichž má student nějaké hodnocení a jeho hodnota. Dále je u každého studena položka zápočet, sloužící k udílení klasifikovaného zápočtu. Záznamy v seznamu lze opět řadit sestupně či vzestupně podle jednotlivých položek. Uživatel má možnost u studentů editovat zápočty pomocí tlačítka Editovat zápočet. Po jeho stisknutí se pole zápočet změní na výběrové pole, ze kterého již může zvolit známku klasifikovaného zápočtu nebo hodnotu nezapočteno. Po stisknutí tlačítka Uložit se hodnoty zápočtu uloží do databáze. Uživatel má obdobným způsobem možnost editovat i všechny ostatní hodnoty u jednotlivých událostí pomocí tlačítka Editovat vše.

Obr. 13 Udílení klasifikovaného zápočtu.

Strana 31

5

ZÁVĚR

Cílem této práce bylo vytvoření aplikace pro evidenci požadavků na studenty předmětu Informatika I a její implementace do stávajícího fakultního systému Herodis. Aplikace prošla fází analýzy požadavků na její funkčnost, vyplývajících ze zadání, a také ze stávajících způsobů pořizování hodnocení studentů. Velmi důležitou fází byl návrh databázové struktury především z hlediska integrity dat, která zajišťuje jejich přesnost a konzistentnost. Posledním krokem byla samotná implementace vytvořeného řešení do fakultního informačního systému a popsání jeho funkcí. Při vývoji webového rozhraní bylo dbáno zejména na uživatelskou přívětivost a na intuitivní ovládání a obsluhu systému. Tyto nároky jsou obvykle kladeny na většinu podobných aplikací, protože webové rozhraní je jedinou částí systému, se kterou se řadový uživatel setká a s níž bude pracovat. Téměř všechna současná softwarová řešení se také musí v průběhu životního cyklu potýkat s novými požadavky své uživatelské základny. A proto i zde bylo myšleno na případný další rozvoj či vylepšování tohoto modulu. V tomto směru by tak aplikace neměla být žádným způsobem omezena pro další rozšiřování a během své existence se může dále přizpůsobovat aktuálním požadavkům fakulty.

Strana 33

6

SEZNAM POUŽITÉ LITERATURY

[1]

KOSEK, Jiří. PHP – tvorba interaktivních internetových aplikací. 1. vyd. Praha : Grada Publishing , 1998. 492 s. ISBN 80-7169-373-1.

[2]

LONEY, K.; THERIAULT, M. Mistrovství v Oracle : kompletní průvodce tvorbou, správou a údržbou databází. 1. vyd Praha : Computer Press, 2002. 896 s. ISBN 80-7226-635-7.

[3]

HERNANDEZ, M. J. Návrh databází. 1. vyd. Praha : Grada Publishing , 2006. 408 s. ISBN 80-247-0900-7.

[4]

DUBOIS, P. MySQL profesionálně. 2. vyd. Praha : Mobil Media , 2003. 1072 s. ISBN 80-86593-41-X.

[5]

ROUPEC, Jan. Počítačové sítě. [pdf dokument]. VUT v Brně 2002 [cit. 15.4.2007 ] Dostupné z WWW: http://drogo.fme.vutbr.cz/~jroupec/nsite/p_site.pdf

[6]

PŘISPĚVATELÉ WIKIPEDIE. Wikipedie:Otevřená encyklopedie [online]. [cit. 29.4.2007]. Dostupné z: http://cs.wikipedia.org/

[7]

SKŘIVAN, J. Databáze a jazyk SQL. Interval.cz [online]. 4.8.2000 [cit. 29.4.2007]. Dostupné z: http://interval.cz/clanky/databaze-a-jazyk-sql/

[8]

PHP dokumentace. [cit. 29.4.2007]. Dostupné z: http://www.php.net/manual/cs/index.php

Strana 35

PŘÍLOHY Přiložené CD obsahuje tyto položky: • bakalářskou práci ve formátu PDF • zdrojové kódy aplikace