Systém pro online prodej jízdenek IDS JMK

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

Systém pro online prodej jízdenek IDS JMK Bakalářská práce

Vedoucí práce: Mgr. Tomáš Foltýnek, Ph.D.

Bohumír Hájek

Brno 2009

Na tomto místě bych rád poděkoval Mgr. Tomáši Foltýnkovi, Ph.D. za odborné vedení s odpovědným a ochotným přístupem, podporu a cenné rady a připomínky při tvorbě této práce.

Prohlašuji, že jsem tuto práci vypracoval samostatně s použitím literatury, jejíž seznam uvádím v závěru a kterou řádně cituji v textu.

V Brně dne 22.5.2009

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

4

Abstract Hájek, B. The system for online selling of tickets for South Moravian Integrated Public Transport System. Bachelor thesis. Brno, 2009. This thesis deals with creation of system, which could ease selling of prepay non-delegable tickets for South Moravian Integrated Public Transport System. It is a web aplication, which enable purchasing of this types of tickets for passengers by means of internet. At first in this text there are described theoretical resources whose understanding is necesarry before realization and next there are described resources which will be used for realization. Next parts of the thesis deals with realization of application, at first with design and creation of data structure and next with describe of creation and functionality of individual parts of system.

Abstrakt Hájek, B. Systém pro online prodej jízdenek IDS JMK. Bakaklářská práce. Brno, 2009. Práce se zabývá tvorbou sytému, který by mohl usnadnit prodej předplatních nepřenosných jízdních dokladů v rámci Integrovaného dopravního systému Jihomoravského kraje. Jedná se o webovou aplikaci, která umožní cestujícím nákup tohoto druhu jízdenek prostřednictvím internetu. V práci jsou nejdříve popsána teoretická východiska, jejichž znalost je nutná před realizací, a dále prostředky, které budou k realizaci použity. Další části práce se již zabývají realizací aplikce, nejprve návrhem a tvorbou datové struktury a potom popisem tvorby a funkčnosti jednotlivých částí systému.

5

OBSAH

Obsah 1 Úvod a cíl práce 1.1 Úvod do problematiky . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7 7 8

2 Současný stav problematiky 2.1 KORDIS JMK, spol. s r. o. . . . . . . . . . 2.2 IDS JMK . . . . . . . . . . . . . . . . . . 2.2.1 Stručná charakteristika . . . . . . . 2.2.2 Systém jízdních dokladů . . . . . . 2.2.3 Možnosti nákupu jízdních dokladů 2.3 Webové aplikace . . . . . . . . . . . . . . . 2.4 Požadavky na systém . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

9 9 9 10 10 11 11 12

3 Použité prostředky 3.1 XHTML a kaskádové styly . . . . . 3.1.1 HTML versus XHTML . . . 3.1.2 CSS . . . . . . . . . . . . . 3.2 PHP . . . . . . . . . . . . . . . . . 3.3 Relační databáze . . . . . . . . . . 3.3.1 Relační databázový model . 3.3.2 SQL . . . . . . . . . . . . . 3.3.3 Relační databázové systémy 3.4 PostgreSQL . . . . . . . . . . . . . 3.5 CASE nástroje . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

15 15 15 16 16 17 17 17 18 18 19

. . . . . . .

20 20 24 24 25 26 27 27

. . . . . . .

28 28 29 29 30 32 34 37

4 Návrh a tvorba databáze 4.1 ERD . . . . . . . . . . . . . . . . 4.2 Příslušnost k normálním formám 4.3 Omezení dat . . . . . . . . . . . . 4.4 Vytvoření databáze . . . . . . . . 4.5 Triggery a funkce . . . . . . . . . 4.6 Pohledy . . . . . . . . . . . . . . 4.7 Naplnění daty . . . . . . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

5 Tvorba vlastní aplikace 5.1 Vzhled uživatelského rozhraní . . . . . . . . . 5.2 Programování jednotlivých částí . . . . . . . . 5.2.1 Společné funkce . . . . . . . . . . . . . 5.2.2 Přihlašování uživatelů . . . . . . . . . 5.2.3 Administrační sekce . . . . . . . . . . . 5.2.4 Výdej průkazek a dokladů . . . . . . . 5.2.5 Objednávky a informace o zákaznících

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

6

OBSAH

5.2.6

Zákaznická sekce – e-shop . . . . . . . . . . . . . . . . . . . . 38

6 Diskuze

41

7 Závěr

42

8 Literatura

43

1

ÚVOD A CÍL PRÁCE

1 1.1

7

Úvod a cíl práce Úvod do problematiky

Každý má občas potřebu někam cestovat při využití veřejné dopravy. Někteří lidé cestují každý den nebo i několikrát denně například do škol nebo do zaměstnání, na nákupy či za zájmovými aktivitami. Jiní naopak využívají veřejnou dopravu méně často, například pro cesty na výlety. Existuje však také skupina lidí, kteří dávají výhradně přednost individuální automobilové dopravě. Právě postupný nárůst individuální dopravy a s ním spojené negativní jevy si začaly vynucovat výraznější podporu veřejné dopravy. Jednou z možností podpory je i zřízení integrovaného dopravního systému (Společnost pro veřejnou dopravu). Pod pojmem integrovaný dopravní systém se rozumí takový způsob zajištění veřejné dopravy v území, v němž jednotlivé druhy dopravy vzájemně spolupracují a vytvářejí tak přehledný a jednoduchý systém vzájemně provázaných linek s jednotným tarifem, přepravními podmínkami a pravidelnými intervaly mezi spoji (IDS JMK). Od 1. ledna 2004 působí takový dopravní systém i na území Jihomoravského kraje, pojmenovaný jako Integrovaný dopravní systém Jihomoravského kraje, zkráceně IDS JMK. Zahrnuje postupně čím dál větší území a je cílem jeho rozšíření na území celého kraje. Do tohoto systému jsou zahrnuty kromě autobusových a vlakových linek také systémy veřejné hromadné dopravy ve větších městech včetně Brna (IDS JMK). Pro cestovaní v rámci IDS JMK existuje mnoho druhů a variant cestovních dokladů. Pro pravidelné jízdy je pro cestujícího nejvýhodnější využití předplatní jízdenky. Vzhledem k tomu, že tyto doklady lze vydat pouze na předem vystavené průkazky, jsou k dostání pouze na omezeném množství prodejních míst. A zde právě mohou vznikat problémy. Uvažujme například člověka, který bydlí v obci Brumov a denně jezdí za prací do města Kuřimi. Ten by ke koupi potřebného předplatního dokladu musel nejprve navštívit 16 km vzdálený Tišnov. Další problém vzniká pravidelně na začátku školního roku v měsíci září. Na nádražích se objevují velice dlouhé fronty žáků a studentů, kteří si chtějí po prázdninách opět pořídit nové jízdenky pro pravidelné cesty do školy a tím dochází i ke zbytečnému zdržování odbavení ostatních cestujících. Nabízí se zde otázka, zda by se nákup tohoto druhu dokladů nedal použitím nějakých vhodných prostředků ulehčit. V dnešní době rozmachu internetu se spousta zboží prodává pomocí internetu, včetně jízdních dokladů. To platí i o dokladech právě toho typu, o jakém je zde řeč. Důkazem toho může být například Dopravní podnik hlavního města Prahy, který provozuje prodej právě těchto dokladů přes internet. Neměl by být tedy problém uvažovat o zavedení podobné možnosti i pro IDS JMK.

1.2

1.2

Cíl práce

8

Cíl práce

Cílem této práce bude vytvořit prostředek, který by mohl určitým způsobem eliminovat výše popsané problémy a ulehčit cestujícím nákup předplatních nepřenosných jízdenek pro cestování v rámci IDS JMK. Tím prostředkem bude systém, díky kterému cestující dostanou možnost si objednat svoji předplatní jízdenku z pohodlí domova a nechat si ji doručit třeba i právě domů. Systém bude koncipován jako webová aplikace tvořená podle aktuálních standardů, dostupná tedy z jakéhokoliv počítače vybaveného připojením k internetu. Aplikace by měla být přehledná a jednoduchá co se týká ovládání a používání, aby cestujícím jejich nákupy opravdu maximálně ulehčila. K implementaci budou užity technologie podle současných trendů v dané oblasti, včetně využití databázového systému. Vytvořená aplikace bude sloužit jako funkční návrh pro koordinátora IDS JMK, společnost KORDIS JMK, spol. s r. o., toho, jak by takový systém mohl vypadat a fungovat. Rozhodnutí o tom, zda by se aplikace použila v praxi a případně v jaké podobě a s jakými úpravami, bude řešeno mimo rámec této práce. Během vývoje aplikace budou probíhat odborné konzultace vztažené k řešení problému se zaměstnancem společnosti KORDIS JMK, spol. s r. o. v oddělení provozu IDS JMK na pozici specialista v dopravě, panem Vladimírem Dopitou.

2

SOUČASNÝ STAV PROBLEMATIKY

2

9

Současný stav problematiky

Nyní si postupně proberme několik východisek, které je třeba znát před započetím řešení problému. Tato část se tedy bude zabývat problematikou společnosti fungující jako koordinátor IDS JMK, dále otázkami ohledně fungování IDS JMK a problematikou kolem webových aplikací a jejich tvorby. Také je třeba stanovit přesné požadavky, které by měl vyvíjený systém splňovat.

2.1

KORDIS JMK, spol. s r. o.

Společnost KORDIS JMK, spol. s r. o. byla založena v březnu 2002 Jihomoravským krajem společně se Statutárním městem Brnem jako koordinátor integrovaného dopravního systému Jihomoravského kraje. Vlastní ji z 51 % Jihomoravský kraj a ze 49 % Statutární město Brno a v současné době má 22 zaměstnanců. Společnost byla založena za účelem vykonávání dvou hlavních činností: koordinace základní dopravní obslužnosti na území Jihomoravského kraje a přípravy, realizace a provozování integrovaného dopravního systému postupně na celém území Jihomoravského kraje (IDS JMK). Společnost se zabývá těmito činnostmi: • je odpovědná za organizační zajištění dopravní obslužnosti území zapojeného do IDS (smlouvy, podklady pro licence), • plánuje a zajišťuje realizaci rozvoje IDS, řízení a realizaci finančních toků IDS, • trvale sleduje a vyhodnocuje vývoj přepravních potřeb, navrhuje jízdní řády, optimalizuje vedení linek, • zavádí jednotný tarifní systém, jízdní doklady, odbavovací systémy, přepravní kontrolu, vytváří a zajišťuje jednotné přepravní podmínky, • vede trvalou informační a propagační kampaň, • zajišťuje smluvní dopravce, provádí jejich kontrolu, • spolupracuje na modernizaci a vývoji vozového parku, vybavení zastávek a přestupních terminálů, zajišťuje ochranu dat poskytnutých dopravci, • účastní se projednávání územně plánovacích dokumentací v oblasti zajištění dopravní obslužnosti (IDS JMK).

2.2

IDS JMK

O zavedení integrovaného dopravního systému na území Jihomoravského kraje bylo rozhodnuto z několika důvodů. Mezi ty hlavní patřila stále větší nepřehlednost a neekonomičnost tehdejšího systému, což mělo za následek stále se zvyšující počet osob dávajících přednost osobnímu automobilu před veřejnou dopravou. Nový integrovaný systém má za úkol tento trend naopak obrátit opačným směrem. Jeho cílem je především dopravu zjednodušit a snažit se ji maximálně přizpůsobit potřebám cestujících při zachování ekonomické efektivnosti.

2.2

IDS JMK

2.2.1

10

Stručná charakteristika

Integrovaný dopravní systém Jihomoravského kraje (dále jen IDS JMK) začal fungovat 1. 1. 2004, respektive jeho první etapa. V následujících letech se začal v dalších etapách rozšiřovat a postupně byly připojovány nové obce. Běhěm posleního rozšíření v prosinci roku 2009 byla zaintegrována rozsáhlá oblast na Hodonínsku a Břeclavsku. V současné době IDS JMK zahrnuje tři čtvrtiny rozlohy Jihomoravského kraje, spadá do něj 554 obcí a více než milion obyvatel. Co se týka spojů a linek, zaintegrováno bylo na daném území prakticky vše, co bylo možné. To znamená veškeré regionální autobusové a vlakové linky, městská hromadná doprava ve větších městech a také velice rozsáhlá síť MHD v Brně. Celkový počet linek v IDS JMK nyní šplhá téměř ke třem stům (IDS JMK). Nový systém s sebou přinesl velké množství výhod pro cestující. Za nejvýraznější změnu se dají považovat jednotné jízdenky a sjednocené jízdné. Nezáleží tedy, jaký druh dopravy cestující z místa A do místa B použije a nezáleží ani na dopravci, cena bude vždy stejná. To platí i pro jízdní doklady, pro všechny druhy dopravy lze použít stejné jízdenky. Pro tento účel je území IDS JMK rozděleno do určitých zón a daný cestovní doklad je platný pro cestování vždy v rámci určitého počtu těchto zón, přičemž bývá ještě zpravidla označen dobou platnosti (pokud se bavíme o jednorázových jízdenkách). Mezi další výhody IDS JMK lze řadit například pravidelnost odjezdů spojů, kdy ve většíně případů zůstávají stejné minutové časy odjezdu a mění se jen hodiny v závislosti na určitém pravidelném intrvalu na dané lince. Jízdní řády linek jsou sestavovány tak, aby na sebe spoje co nejvíce navazovaly, což zkvalitňuje možnosti cestování. 2.2.2

Systém jízdních dokladů

Cestující v IDS JMK má na výběr z široké řady různých druhů cestovních dokladů. Jednak již zmíněné jednorázové jízdenky, které slouží pro jednotlivé cesty veřejnou dopravu. Cestující je může využít vždy pro cestu v daném počtu zón (až 10), přičemž je navíc omezená doba platnosti jízdenky (max. 180 minut). Specifickým druhem jídenky je takzvaná univerzální jízdenka, kde si cestující označí určitý počet polí podle toho, jak daleko cestuje. Pro opakované a pravidlené cestování jsou nabízeny předplatní jízdenky. K dostání je několik druhů přenosných předplatních jízdenek pro cestování především v brněnských zónách s platností jeden, tři, sedm nebo čtrnáct dní či jeden měsíc. Poslení a nejrozsáhlejší skupinou jízdních dokladů jsou jízdenky předplatní nepřenosné. Mají platnost měsíc nebo 3 měsíce (některé druhy i celý rok) a opravňují svého držitele k neomezenému cestování během dané doby v úseku, pro který byla jízdenka vydána. Daným úsekem se rozumí obvykle určitý počet zón. Cestující si pro využití tohoto druhu jízdenek musí nejprve opatřit průkazku s fotografií a dalšími údaji, jako je jméno, příjmení a datum narození a na tuto průkazku si poté pořizuje kupóny.

2.3

Webové aplikace

11

Jízdenky tohoto druhu se dělí na 2 základní skupiny, a to s platností zároveň i pro 2 brněnské zóny 100 a 101 a jízdenky vydané pro mimobrněnské zóny, případně jen s jednou brněnskou zónou. Tyto dvě skupiny se mírně liší v cenách. V rámci každé z těchto skupin lze rozlišovat doklady podle druhu cestujícího, to znamená základní, děti, studenti a důchodci, přičemž se zároveň rozlišuje zmíněná doba platnosti. U každé jízdenky jsou potom ještě přesně definovány zóny, ve kterých jízdenka platí. 2.2.3

Možnosti nákupu jízdních dokladů

Jednorázové jízdenky je možné koupit na široké řadě prodejních míst, například ve městě Brně i téměř ve všech novinových stáncích a většinu základních typů i v prodejních automatech. Jízdenky tohoto typu jsou tedy dostupné velice dobře. Zabývejme se však předplatními nepřenosnými jízdními doklady. Tam už je jejich dostupnost omezená. To je dáno samozřejmě tím, že je před vydáním každého takového dokladu třeba ověřit platnost průkazky k jeho vydání. To je možné v prodejnách Českých drah na nádražích, na několika stálých prodejních místech v Brně a dále v prodejních střediscích některých autobusových dopravců a na poštách v zaintegrovaných obcích. Ovšem na dvou posledně jmenovaných skupinách prodejních míst se vydávají pouze doklady s platností do maximálně čtyř zón a zároveň bez kombinace obou brněnských zón 100 a 101 současně (IDS JMK).

2.3

Webové aplikace

Webová aplikace je aplikace poskytovaná uživatelům z webového serveru přes počítačovou síť Internet, nebo její vnitropodnikovou obdobu (intranet). Webové aplikace jsou populární především pro všudypřítomnost webového prohlížeče jako klienta. Ten se pak nazývá tenkým klientem, neboť sám o sobě logiku aplikace nezná (Wikipedie, 2009). V běžných aplikacích typu klient–server má každá aplikace svůj vlastní klientský program, který slouží jako její uživatelské rozhraní a musí být instalován na osobním počítači každého uživatele. Aktualizace serverové části typicky vyžaduje i aktualizaci klientských programů na každé pracovní stanici. Oproti tomu webové aplikace generují dynamicky sérii webových stránek ve standardním formátu HTML/XHTML, který je podporován běžnými prohlížeči. Obecně je každá jednotlivá webová stránka dodána prohlížeči jako statický dokument, ale sled takových stránek může vyvolat pocit interaktivity, např. díky reakci na vstup uživatele do formulářových prvků vložených do kódu stránky. Pro přidání dynamických prvků do uživatelského rozhraní se používá skriptovací jazyk JavaScript. Webový prohlížeč v průběhu běhu aplikace interpretuje a zobrazuje stránky a funguje jako univerzální klient pro libovolnou webovou aplikaci (Wikipedie, 2009). Jednou z hlavních výhod webových aplikací je tedy ta, že uživatel nemusí instalovat žádný speciální softwarový balík na každém z počítačů, jako u klasických

2.4

Požadavky na systém

12

instalací. K ovládání mu postačuje pouze internetový prohlížeč, který se vzdálenou aplikací umístěnou na serveru komunikuje. Dále se podstatně zjednodušila distribuce nových verzí aplikací, kdy uživatel má díky internetu vždy přístup k aktuální zveřejněné verzi. Webové aplikace přinášejí i zkvalitnění servisu, protože pracovníci dodavatele nemusí ke klientovi jezdit, ale aplikaci opraví na jediném centrálním místě (na serveru) na dálku (MediaCentrik). Další velkou výhodou webových aplikací je jejich nezávislost na operačním systému, pod kterým budou spuštěné. Stačí tedy vyvinout pouze jedinou verzi aplikce, která bude naprosto stejně fungovat jak pod operačním systémem Windows, tak i pod Linuxem nebo pod Mac OS. S tím souvisí i nezávislost na typu webového prohlížeče. Pokud bychom se zabývali současnými verzemi prohlížečů, aplikace by v každém měla vypadat a fungovat totožně. Existuje sice několik málo výjimek, kdy některý prohlížeč zobrazuje odlišným způsobem některé HTML prvky a CSS vlastnosti, avšak takové prohlížeče nepodporují správným způsobem všeobecně dané standardy. Z výše uvedených faktů tedy vyplývá, že webové aplikce jsou dostupné z kteréhokoliv počítače na světě vybaveného webovým prohlížečem (potřebné kvality) a připojením k internetu. Uvedené výhody jsou však vyváženy také určitými nevýhodami, i když výhody převažují. Jedná se například o vysokou závislost na poskytovateli aplikace a dostatečně dimenzované kapacitě připojení k serveru poskytovatele. Pokud se poskytovatel rozhodne ukončit poskytování této služby nebo ji přeruší z jiného důvodu, nelze službu nadále používat, na rozdíl od lokálně provozovaného software. Stejně tak pokud dojde k přerušení spojení se serverem poskytovatele, může být služba dočasně nedostupná (Wikipedie, 2009). Co se týka struktury webových aplikací, ta bývá běžně třívrstvá. Prezentační vrstva se zabývá zobrazováním veškerých výstupních informací a rozvržením uživatelského rozhraní. Ta bývá u webových aplikací standardně tvořena pomocí technologie HTML/XHTML a kaskádových stylů. Druhá vrstva, aplikační, se zabývá logikou aplikace a logikou práce s daty. Tato vrstva bývá nejčastěji tvořena algoritmy napsanými v některém z programovacích jazyků, například v PHP nebo Perlu. Datová vrstva se potom zabývá uložením veškerých dat používaných aplikací a ovládáním přístupu k těmto datům. Zde bývá použit některý z datbázových systémů.

2.4


Vyvíjená aplikce bude ve formě internetového obchodu, vytvořeného přesně na míru pro potřeby prodeje nepřenosných předplatních dokladů pro cestování v rámci IDS JMK. Vhodné tedy bude řešit systém jako webovou aplikaci. Kromě samotného on-line prodeje dokladů musí být umožněna i jednoduchá správa obsahu systému. Protože systém bude mít vpodstatě formu internetového obchodu, nabízí se zde otázka, zda by nebylo vhodné použít některý již hotový software k vytváření e-shopů a ulehčit si práci. Co se týká nabídky v českém prostředí, lze použít jednak některou z desktopových aplikací, například E-shop Panda

2.4


13

(http://zsery.aspweb.cz/Panda.aspx), nebo některou ze služeb umožňujících tvorbu e-shopu přímo on-line, například eshop.zdarma.cz. Tyto generátory e-shopů si však vždy samy automaticky vytvoří určitou strukturu databáze a veškerých zdrojových kódů a zpravidla neumožňují zásadnější zásahy do této struktury a tím ani přizpůsobení pro určité konkrétní potřeby, které by bylo často pro vytvoření e-shopu se sepecifickými požadavky nutné. V našem případě právě použití takového softvaru není evidentně vhodné, systém bude nutné vytvořit s ohledem na veškerá pravidla, která definuje vlastní Integrovaný dopravní systém Jihomoravsého kraje. IDS JMK je v určitých ohledech specifický a všechna tato specifika je potřeba ve vyvíjené aplikaci správně implementovat. Týká se to především systému tarifních zón a systému předplatních jízdních dokladů. Celý systém on-line prodeje by v reálu mohl fungovat následovně: zákazník, který by měl zájem systém používat, by se musel nejdříve registrovat na některém prodejním místě. To je nutné z toho důvodu, že získání předplatního nepřenosného dokladu je možné pouze na platnou průkazku, jejíž ověření je nutné před vydáním dokladu. Na daném místě by si tedy cestující mohl nechat případně i průkazku vystavit, pokud by ji dosud nevlastnil. Na základě držení této průkazky obsluha zákazníka zaregistruje do systému a případně mu přímo na místě vydá nový cestovní doklad. Další doklad si ale může zákazník již objednat přes internet z domova. Při registraci mu byly na sdělenou e-mailovou adresu zaslány přihlašovací údaje – login a dočasné heslo. Po prvním přihlášení si zákazník heslo změní a může přidat do systému další údaje, jako například svoji adresu. Poté si již může další předplatní jízdenku objednat buď přímo na svoji zadanou adresu nebo na některé z výdejních míst, kde si hotový vystavený doklad již jen vyzvedne. Předpokládá se, že systém bude rozdělen na jednotlivé samostatně fungující části, z nichž každá bude sloužit odlišnému účelu a každou budou používat jiné skupiny osob. První částí bude vlastní internetový obchod, který budou využívat zákazníci popsaným způsobem. Druhou část by používala obsluha na prodejních místech, kde by se zákazníci registrovali a kde by se zároveň i vydávaly doklady. Třetí část by používaly osoby, které budou mít na starosti vyřizování objednávek, tedy by se jednalo o aplikaci pro správu objednávek. Poslední část by sloužila pro správu vlastního obsahu systému, tedy především co se týká vlastností a sortimentu nabízených dokladů a dalších možností ohledně jejich objednávání. Jak je zřejmé, do systému bude možný pouze autentizovaný vstup, kdy budou zvlášť odlišeny zákaznické uživatelské účty a účty pro obsluhu či správu systému. U účtů druhého typu bude navíc třeba vždy definovat, do jakých sekcí bude mít vlastník účtu přistup. Předpokládá se totiž, že zaměstnanci provozovatele systému by měli různé úkoly a povinnosti k akcím spojených s obsluhou systému, proto by každý měl mít právo pro používání pouze těch částí, jejichž obsluhu bude mít na starosti.

2.4

14


Obr. 1: Use Case diagram

3

POUŽITÉ PROSTŘEDKY

3

15

Použité prostředky

Pro tvorbu webových aplikací bývá obvykle použito větší množství programovacích prostředků a technologií. To je dáno také třívrstvou architekturou, kdy je k řešení každé vrstvy použita jedna nebo i více různých technologií. Dále je vhodné v některých případech použít nástroje, které nám vývoj aplikace ulehčí. Následující část práce bude pojednávat o jednotlivých technologiích a nástrojích použitých při tvorbě řešené aplikace.

3.1 3.1.1

XHTML a kaskádové styly HTML versus XHTML

HyperText Markup Language, označovaný zkratkou HTML, je značkovací jazyk pro hypertext. Je jedním z jazyků pro vytváření stránek v systému World Wide Web, který umožňuje publikaci dokumentů na Internetu. Jazyk je aplikací dříve vyvinutého rozsáhlého univerzálního značkovacího jazyka SGML (Standard Generalized Markup Language). Vývoj HTML byl ovlivněn vývojem webových prohlížečů, které zpětně ovlivňovaly definici jazyka. Je charakterizován množinou značek a jejich atributů definovaných pro danou verzi. Mezi značky se uzavírají části textu dokumentu a tím se určuje význam (sémantika) obsaženého textu. Názvy jednotlivých značek se uzavírají mezi úhlové závorky. Část dokumentu tvořená otevírací značkou, nějakým obsahem a odpovídající ukončovací značkou tvoří tzv. element (prvek) dokumentu. Značky (zvané tagy) jsou obvykle párové, přičemž koncové značka je shodná se značkou počáteční, jen má před názvem znak lomítko. Některé značky jsou však i nepárové – nemají žádný obsah a nepoužívají koncovou značku. Tagy mohou také obsahovat atributy, které popisují jejich vlastnosti nebo nesou jinou informaci (Wikipedie, 2009). V roce 1990 v počátcích jazyka HTML byla jeho jediným cílem prezentace obsahu v čisté, strukturované formě, pouze s několika značkami. Později si začalo mnoho autorů stěžovat, že nemohou nijak ovlivnit vzhled svých HTML stránek. Proto byl v roce 1994 vypracován první návrh „Cascading Style Sheetsÿ, tedy kaskádových stylů pro ovlivnění vzhledu HTML dokumentu. Výrobci webových prohlížečů však tento počin nepodpořili a naopak se začaly zabudovávat vlastnosti pro řízení vzhledu přímo do značek HTML, kdy se začal původně čistý a strukturovaný kód postupně zanášet formátovacími značkami a atributy. S narůstající složitostí HTML dokumentů však narůstaly i problémy. Datový objem formátovacích značek a atributů byl často větší, než objem vlastního obsahu. Navíc se vyskytovalo mnoho problémů při formátování dokumentů pro jiná zařízení, nežli běžné prohlížeče. Vpodstatě byli vyřazeni zrakově handicapovaní, jejichž čtecí zařízení si s takovou stránkou obvykle nedokáže poradit (Cyroň, 2006). Řešení přichází v použití XHTML a formátování pomocí kaskádových stylů (CSS). XHTML dokument je vpodstatě HTML stránka, která je zároveň i dokumentem vyhovujícím standardu XML. Jazyk XML má oproti HTML jednu zvláštnost.

3.2

PHP

16

Vůbec se nestará o to, jak se dokument zobrazí, ale pouze o strukturu dokumentu (Ponkrác, 2000). Použití XHTML umožňuje oddělení obsahu dokumentu od definice jeho vzhledu, což může být v mnoha případech přínosem. Tvorba webových stránek v XHTML je s ohledem do budoucnosti jednoznačně výhodná, tento standard je v současné době velice dobře podporován a očekává se jeho čím dál větší rozšiřování na úkor zastarávajícího HTML. To vyplývá například i faktu, že W3C (webová standardizační organizace) chce XHTML prosazovat jako jediný jazyk pro definici webových stránek, bez ohledu na typ zařízení, které je zpracovává (Snížek, 2002). 3.1.2

CSS

CSS je zkratka pro anglický název Cascading Style Sheets, česky tabulky kaskádových stylů. Je to jazyk pro popis způsobu zobrazení stránek napsaných v jazycích HTML, XHTML nebo XML. Jazyk byl navržen standardizační organizací W3C. Byly vydány zatím dvě úrovně specifikace CSS1 a CSS2, dokončuje se revize CSS 2.1 a pracuje se na verzi CSS3. Hlavním smyslem je umožnit návrhářům oddělit vzhled dokumentu od jeho struktury a obsahu (Wikipedie, 2009). Kaskádové styly nabízejí mnohem širší možnosti formátování oproti HTML, týká se to například formátování seznamů. Některé potřebné vlastnosti způsob formátování pomocí HTML ani neumožňuje realizovat, nebo jen ve značně omezené míře – například vlastnosti okrajů, výplní, pozadí nebo pozicování (přesné nastavení polohy) (Cyroň, 2006). Další obrovská výhoda používání CSS vyplývá právě z faktu, že je oddělen obsah dokumentu od definice jeho vzhledu. Pokud bychom chtěli změnit vzhled celého webu (několika stránek) vytvořeného pomocí formátování v HTML, bylo by to velice obtížné. Museli bychom postupně projít všechny HTML dokumenty a vyhledat v nich a změnit všechny potřebné značky a jejich atributy k dosažení nového vzhledu. Oproti tomu změna vzhledu webu používajícího CSS je jednoduchá a rychlá, stačí vždy pouze změnit v tabulce stylů definici vlastostí určitého prvku a změna se ihned promítne do všech těchto prvků v celém webu. Současný trend při tvorbě XHTML dokumentů směřuje k tomu, že se veškeré rozmístění prvků na stránce svěří CSS (nikoliv dříve oblíbeným tabulkám a rámcům). Změna vzhledu takovéto webové prezentace je potom jednoduchá. Nejen barvy, zarovnání, písmo či rozměry prvků, ale i jejich umístění lze provést několikerým kliknutím myši a několika málo stisky kláves na klávesnici. Takováto věc byla v případě použití tabulek a rámců značně obtížná (Cyroň, 2006).

3.2

PHP

PHP je hypertextový peprocesor, který na serveru interpretuje stránky HTML s vlasními příkazy před jejich odesláním ke klientovi (obvykle webovému prohlížeči). To znamená, že PHP umožňuje vkládat vlastní skripty (krátké úseky kódu, ale i celé programy) přímo do hypertextových stránek. Interpretovaný znamená, že progra-

3.3

Relační databáze

17

mový kód je až do svého použití a spuštění uchován ve zdrojovém tvaru. Interpret jazyka tento kód převezme a překládá jej do stojového kódu pro počítač, na kterém PHP běží. Na rozdíl například od JavaScriptu (který je interpretovaný klientem) je PHP interpretováno na serveru. To s sebou přináší některé výhody, jako je třeba snadná interakce s dalšími aplikacemi na serveru, nenáročnost na hardware či software klienta, menší objem přenesených dat a vyšší ochrana zdrojových textů programů (Bráza, 2005). Syntaxe jazyka je inspirována několika programovacími jazyky (Perl, C, Pascal a Java). PHP je nezávislý na platformě, skripty fungují bez větších úprav na mnoha různých operačních systémech. Podporuje mnoho knihoven pro různé účely – např. zpracování textu, grafiky, práci se soubory, přístup k většině databázových systémů (mj. MySQL, ODBC, Oracle, PostgreSQL, MSSQL), podporu celé řady internetových protokolů (HTTP, SMTP, SNMP, FTP, IMAP, POP3, LDAP . . . ). V kombinaci s operačním systémem Linux, databázovým systémem (obvykle MySQL nebo PostgreSQL) a webovým serverem Apache je často využíván k tvorbě webových aplikací (Wikipedie, 2009).

3.3 3.3.1

Relační databáze Relační databázový model

Relační databáze byla proprvé 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í. Model je založen na dvou matematických disciplínách – teorii množin a predikátové logice prvního řádu. Data se ukládají ve vztazích, které uživatel vidí jako tabulky. Každá tabulka je složena z uspořádaných n-tic, neboli záznamů, a atributů. Relační model rozděluje vztahy na 1 : 1, 1 : N a M : N. Vztah mezi dvojicí tabulek je zřízen prostřednictvím odpovídajících si hodnot ve sdílených atributech. Zná-li uživatel vztahy mezi tabulkami v databázi, může k datům přistupovat téměř neomezeným počtem způsobů (Hernandez, 2006). Při návrhu struktury relačního databázového modelu se obvykle používá entitně-relační diagram (zkráceně ERD), který slouží k přehlednému zobrazení veškerých entit vystupujících v modelu a vztahů mezi nimi. 3.3.2

SQL

Relační databáze je obsluhována pomocí SQL jazyka (structured query language – strukturovaný dotazovací jazyk). Ten nabízí sadu příkazů složících jak k získávání dat z databáze, tak i k jejich ukládání a modifikaci a navíc ještě mnoho dalších možností. SQL příkazy se dělí do tří základních skupin. První z nich jsou DDL (Data Definition Language) příkazy, které slouží k manipulaci s datovým slovníkem databáze. DML (Data Modification Language) příkazy slouží k modifikaci obsahu databáze, tedy uložených dat. Do poslední skupiny, DQL (Data Query Language) se

3.4

PostgreSQL

18

řadí pouze jediný příkaz SELECT, který má však obrovské možnosti využití a slouží k získávání dat z databáze. 3.3.3

Relační databázové systémy

Relační databázový systém, jindy nazývaný také Systém pro správu relační databáze (angl. zkratka RDBMS), je program, který se používá k vytvoření, udržování, modifikování a správě relační databáze. Kvalita tohoto systému je přímo úměrná tomu, jak podporuje relační databázový model. Mezi různý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álůe vyvíjejí a podporují stále více funkcí (Hernandez, 2006). Relační databázových systémů v současnosti používaných existuje větší množství. Mezi nejznámější a nejvíce používané se řadí Oracle, Firebird, Microsoft SQL Server, MySQL či PostgreSql.

3.4

PostgreSQL

PostgreSQL je relační databázový systém s některými objektovými rysy, který má možnosti tradičních komerčních databázových systémů s několika rozšířeními, které lze najít v DBMS systémech příští generace. Používání PostgreSQL není omezené a veškeré zdrojové kódy jsou volně dostupné. PostgreSQL je vyspělý databázový systém spadající do skupiny Open Source softwaru, který má za sebou dlouholetý aktivní vývoj a vynikající pověst pro svou spolehlivost a bezpečnost. Lze jej provozovat na všech, dnes běžně rozšířených operačních systémech (Linux, UNIX, Windows). PostgreSQL je šířen pod BSD licencí, která je nejliberálnější ze všech open source licencí. Tato licence umožňuje neomezené používání, modifikaci a distribuci PostgreSQL. PostgreSQL lze šířit se zdrojovými kódy nebo bez nich a to zdarma nebo komerčně (Habrman, 2007). Předností systému PostgreSQL je jeho rozšiřitelnost. Systém může být bezproblémově rozšiřován o nové datové typy, funkce, operátory, agregační funkce, procedurální jazyky. PostgreSQL plně podporuje cizí klíče, operace JOIN, pohledy, spouště a uložené procedury. Obsahuje většinu SQL92 a SQL99 datových typů, např. INTEGER, NUMERIC, BOOLEAN, CHAR, VARCHAR, DATE, INTERVAL a TIMESTAMP. Také je umožněn běh uložených procedur napsaných v několika programovacích jazycích, v Perlu, v Pyhon, v jazyku C nebo v speciálním PL/pgSQL, jazyku vycházejícím z PL/SQL fy. Oracle. Aktuální osmá verze produktu obsahuje všechny pokročilé vlastnosti, díky kterým se dá považovat za solidní a bezpečnou platformou pro vývoj podnikových aplikací (Habrman, 2007).

3.5

3.5

CASE nástroje

19

CASE nástroje

CASE (z anglického Computer-aided Software Engineering, počítačem podporované softwarové inženýrství) znamená použití softwaru pří vývoji počítačových programů. Pojem CASE nepředstavuje jeden jediný konkrétní nástroj, ale skupinu nástrojů zaměřených především na podporu vývoje informačních systémů, obvykle pohledu analýzy a návrhu. Jednotlivé nástroje CASE vycházejí z konkrétní metodologie a formou diagramů umožňující materializovat představu o zpracovávaném problému. Nejčastěji jsou nástroje CASE používány pro datové a funkční modelování (Skřivánek, 2008). Samozřejmostí je, že jednotlivé nástroje dokáží vygenerovat kód spustitelný ve vybraném prostředí, který vytvoří potřebné datové struktury či metody. Jinými slovy, formou diagramu je možné si vytvořit datové struktury a pomocí vygenerovaného kódu (obvykle skriptu) je založit v databázi. Kvalitnější nástroje CASE dokáží s vybranými produkty – nemusí se jednat pouze o databázové platformy, ale například také o vývojové nástroje – komunikovat přímo a vývojáři se o žádný přenos skriptu starat nemusí (Skřivánek, 2008).

4

NÁVRH A TVORBA DATABÁZE

4

20

Návrh a tvorba databáze

Při návrhu databáze byl kladen veklý důraz na vytvoření modelu správným způsobem i s ohledem do budoucnosti, aby bylo případných pozdějších úprav už jen minimum nebo aby nebyly žádného zásadního charakteru. Aplikace postavená na nesprávně navržené databázi by nemusela pracovat korektně a zjištění chyby v databázovém schématu by mohlo mít téměř fatální následky, kdy by se aplikace musela nově změněnému databázovému schématu složitě přizpůsobovat. V modelu bylo nutné zahrnout všechny druhy jízdních dokladů, pro jejichž prodej bude aplikace sloužit. Těchto druhů je velké množství, takže úkol nebyl nejjednodušší, nicméně bylo snahou model navrhnout co nejobecněji. Proto vzniklo několik různých takzvaných číselníků. Dále bylo třeba převést do modelu i systém tarifních zón a poté správným způsobem zachytit všecny vztahy mezi vzniklými tabulkami. Pro návrh databázového modelu byl použit CASE nástroj s názvem Toad Data Modeler ve verzi 2.24 z roku 2006 s freeware licencí. Tato verze je oproti nejnovější komerční verzi ochuzena o některé funkce, nicméně i tak byl tento program shledán jako velice vhodný k použití. Umožňuje jednoduchým a intuitivním způsobem vytvořit datový model a z něj následně i vygenerovat SQL DDL příkazy k vytvoření databáze, přičemž podporuje velké množství databázových platforem v různých verzích.

4.1

ERD

Nyní přistupme k tvorbě nového modelu databáze. Jako databázový systém, pro který bude model tvořen, zvolíme PostgreSQL 8.1. Že bude databáze tvořena právě pro tento systém poznáme například při tvorbě atributů entit, kdy nám jsou nabízeny právě ty datové typy, které tato verze PostgreSQL podporuje. Nejdříve je třeba definovat entity vystupující v modelu. Pro jednoduchost a přehlednost bude mít každá entita klíčový atribut s názvem id_nazev_entity. Protože systém bude sloužit pro prodej jízdních dokladů, první tabulka bude mít název doklady. Ta bude obsahovat záznamy o jednotlivých skutečných fyzických jízdních dokladech, kdy bude mít každý přiřazen datum počátku a konce platnosti a cenu dokladu v době jeho objednání. Každý doklad je určitého typu, další tedy bude tabulka typy_dokladu, na kterou se bude tabulka doklady odkazovat cizím klíčem. Každý typ dokladu má určitý název, cenu, dále atribut typu boolean informijící o tom, zda se jedná doklad i pro obě brněnské zóny a další atribut typu boolean s názvem aktiv, o kterém bude ještě řeč později. Dále, protože každý typ dokladu je ještě blíže určen dobou platnosti (měsíc, 3 měsíce, rok) a druhem zákazníka (základní, dítě, student, důchodce), byly pro tyto informace vytvořeny číselníky, na něž se tabulka typy_dokladu odkazuje. Ta se odkazuje ještě navíc na třetí číselník useky, který obsahuje další informace o úseku (definovaném většinou jako počet zón), pro který bude doklad platit. Informace z této tabulky se využívají v aplikaci při výběru druhu dokladu při nákupu.

4.1

ERD

21

Další významná entita v modelu má název prukazky. Ta bude obsahovat informace o vlastních fyzických průkazkách, které vlastní zákaznící a na základě kterých lze vydávat jízdní doklady. Musí zde být tedy všechny atributy, jako na skutečné průkazce, to znamená, kód průkazky, data počátku a konce platnosti a také druh zákazníka odkazem na číselník typy_zakaznika. Ostatní data jsou k průkazce vázána odkazem na tabulku se zákazníky. Je třeba správně definovat vztah mezi průkazkami a doklady, to znamená, že na jednu průkazku může být vydáno 0 až n dokladů, přitom každý doklad je vždy vydán právě na jednu průkazku, tedy relace 1 : 0. .n. Nyní se dostáváme k již zmíněné tabulce zakaznici, kde budou jednotlivými položkami uživatelé tohoto sytému. Atributy zde budou jméno, příjmení, datum narození, e-mailová adresa, telefon a také přihlašovací údaje do systému, tedy login a heslo. Každý zákazník může mít adresu, kam si nechá zaslat objednaný doklad, další entita bude mít tedy název adresy. Bude obsahovat atributy definující dohromady ardresu jakéhokoliv místa na území ČR, jako je ulice, číslo popisné, město a poštovní směrovací číslo. Myslelo se zároveň i na případ, že by si zákazník nechal objednávku zaslat do sídla firmy, kde například pracuje, proto je přidán navíc atribut firma a dále ještě osoba, definující konkrétní osobu ve firmě, na kterou by byla zásilka adresována. Tabulka adresy bude kromě záznamů o adresách zákazníků obsahovat navíc i adresy prodejních míst, kde se budou vydávat průkazky a doklady. Každý zákazník bude v obvykle používat v systému jen jednu adresu, avšak je třeba předcházet možným problémům v budoucnu, kdy by mohlo být stanoveno, že zákazník bude mít možnost používat zároveň adres víc. Musíme tedy správně definovat vztah mezi zákazníky a adresami, který je takový, že zákazník bude mít možnost vlastnit 0 až n adres a zároveň každá adresa bude moci být přiřazena 0 až n zákazníkům. Jedná se o klasický vztah M : N, pro jehož interpretaci vytvoříme asociační entitu zakaznici_adresy, která obsahuje pouze odkazy na primární klíče obou takto propojených tabulek. Jak bylo zmíněno, tabulka adresy bude obsahovat i adresy prodejních míst. Pro uložení údajů o těchto místech bude sloužit tabulka prodmista, která bude obsahovat název prodejního místa a právě odkaz na jeho adresu do tabulky adresy. Každý doklad bude vydán na určitém prodejním místě, přičemž bude třeba o každém dokladu evidovat čas a datum jeho vydání a osobu, která doklad vydala. Pro tento účel vznikne další entita s názvem vydani, která bude obsahovat kromě zmíněného data a času vydání také odkazy do dalších tabulek k propojení s informacemi o prodejním místě a osobě vydávající doklad. Na tuto entitu s informacemi o vydání každého dokladu se bude zároveň odkazovat tabulka doklady. Osoby vydávájící doklady bude evidovat tabulka spravci. Ta bude dohromady obsahovat informace o veškerých osobách, které budou systém používat v jiných rolích, než jako zákazníci. O každém bude uchováno jméno, příjmení a login s heslem pro přihlášení. Předpokládá se, že budou existovat skupiny osob s různými právy pro vstup do jednotlivých částí systému. Pro tento účel vznikla další entita prava, která bude obsahovat tato jednotlivá práva. Mezi těmito jednotlivými právy a osobami bude vztah M : N, protože každá osoba může mít M práv a zároveň každé právo může

4.1

ERD

22

mít přiřazeno N osob. Vznikne tedy další asociační entita s názvem spravci_prava, která bude obsahovat odkazy na primární klíče obou spojených tabulek. Pokud si zákazník objedná nějaký doklad, bude třeba tuto akci samozřejmě nějakým způsobem zaevidovat v databázi. Pro ukládání informacích o všech objednávkách zákazníku bude sloužit tabulka objednavky. Ta bude obsahovat atributy pro datum a čas objednávky, dále textovou poznámku zákazníka k objednávce a atribut vyrizeno typu boolean pro označení objednávky jako vyřízené či nikoliv. Ukládat se bude také ještě IP adresa přihlášeného uživatele. Každá objednávka bude mít dále definovaný způsob doručení a způsob platby. Aby bylo možné všechny způsoby platby a doručení měnit nebo přidávat i později při již hotové aplikaci, vzniknou pro tyto informace 2 číselníky, na které se bude tabulka objednavky odkazovat cizími klíči. Toto řešení zajistí, že například v budoucnu při potřebě přidat pro zákazníky další možnost placení objednávek, se pouze přidá záznam do tabulky zpusoby_platby. Dále je každá objednávka směrována vždy na určitou adresu, ať už jde o adresu bydliště zákazníka, nebo o adresu prodejního místa, kde si zákazník doklad vyzvedne. Znamená to tedy další cizí klíč v tabulce objednavky, odkazující na tabulku adresy. Každá objednávka se navíc váže k určitému zákazníkovi a k určitému objednanému dokladu, takže vzniknou ještě další 2 cizí klíče. Nyní máme v ERD vyřešeny všechny situace týkající se zákazníků, objednávek, adres, prodejních míst a osob obsluhujících tento systém. Nyní bude v diagramu následovat zachycení systému tarifních zón, který má vliv na vlastnosti všechy vydávaných dokladů a některých druhů průkazek. Každý doklad lze totiž vydat pro platnost v několika konkrétních zónách. Totéž platí i o průkazkách pro děti a studenty, kdy lze potom vydat doklad jen na konkrétní zóny definované na průkazce. Pro tento účel je tedy nutné v databázovém schématu tento systém zón nějakým způsobem zobrazit. Základní tabulka s názvem zony bude obsahovat záznamy o všech jednotlivých zónách. Protože každý doklad může být vydán pouze pro zóny, které s sebou sousedí, musí být každé zóně definovány i všechny její sousední zóny. Pro tento účel vznikne tabulka okolnizony, ve které budou údaje o zónách totožné s údaji v tabulce zony. Kvůli vztahu M : N mezi těmito dvěma entitami vznikne další asociační tabulka s názvem zony_okolnizony obsahující pouze odkazy na obě spojené tabulky. Tímto způsobem bude možné každé zóně přiřadit N okolních zón. Aby nedocházelo k nekonzistenci v databázi, bude třeba zaručit, aby byly po celou dobu obsahy obou tabulek se zónami totožné. To bude zajištěno pomocí triggerů, o kterých bude řeč později. Pro definování vztahu mezi zónami a doklady bude sloužit asociační tabulka doklady_zony. Ta nám definuje, že každý doklad může mít přiřazeno M zón a zároveň každá zóna se může vyskytovat na N dokladech. Stejný vztah platí i mezi zónami a průkazkami, i zde tedy vznikne asociační tabulka představující tento vztah. V tomto případě však některé průkazky nemusí mít přiřazeny žádné zóny (druh základní a důchodce), nicméně vztah daný asociační tabulkou připouští i tuto možnost. Tento případ lze nalézt i ve vztahu mezi zónami a doklady, pokud bychom mluvili o typu dokladu platném pro všechny zóny. V tomto případě pro doklady tohoto typu v asociační tabulce jednoduše žádný záznam nebude.

4.1

23

ERD

Ještě je třeba zmínit atribut s názvem aktiv, který se vyskytuje u několika tabulek. Tento atribut je typu boolean a bude nám definovat, zda se daná položka aktivní a v současné době používaná či nikoliv. Toto nám zajistí uchování veškeré historie o všech položkách figurujících v databázi během fungování aplikace. Pro názornost posloží jednoduchý příklad. Mějme určitý typ dokladu, který se nějakou dobu prodává, avšak tento typ dokladu se v určitém momentu zruší a dále se již prodávat nebude. Při smazání tohoto druhu z databáze bychom již nikdy nezjistili, například kolik dokladů tohoto druhu bylo před zrušením prodáno. Proto mimo jiné i u druhů dokladů bude položka aktiv, která se při zrušení daného typu dokladu pouze změní na false a tím pádem bude i možné tento druh kdykoliv obnovit.

Obr. 2: ERD databáze

4.2

4.2

Příslušnost k normálním formám

24

Příslušnost k normálním formám

Vznikl nám tedy ERD obsahující celkem 22 entit propojených dohromady 27 vztahy. Bylo snahou tento diagram maximálně přizpůsobit normálním formám, což jsou doporučení, při jejichž dodržení bude mít datový model určité kladné vlastnosti. Atomičnost všech atributů, tedy první normální formu, návrh zcela jistě splňuje. Dalo by se sice diskutovat například u ukládání e-mailových adres (atribut email u tabulky zakaznici), které se fakticky skládají z více částí, nicméně v kontextu tohoto systému lze celou e-mailovou adresu chápat jako dále nedělitelnou. Druhá normální forma je také evidentně splněna, každá tabulka obsahuje totiž pouze jediný umělý primární klíč. Zkoumat příslušnost ke druhé normální formě by mělo smysl pouze tehdy, pokud by v některé tabulce tvořilo primární klíč dohromady více atributů. Z definice třetí normální formy vyplývá, že by žádné dva neklíčové atributy neměly být na sobě závislé. U většiny tabulek je tento požadavek splněn, avšak na problém narážíme u tabulky adresy. Vyskytují se vedle sebe atributy mesto a psc, které mají mezi sebou závislost. PSČ totiž závisí na konkrétním městě a opačně. Tento problém by vyřešil vznik nové tabulky, kde by jednotlivými položkami byla všechna poštovní směrovací čísla vždy s přiřazeným konkrétním městem nebo jeho částí a v tabulce s adresami by byl vložen cizí klíč odkazující na záznam v této nové tabulce. K realizaci bychom ale museli vlastnit seznam všech míst s přiřazeným PSČ a příslušnou tabulku v databázi těmito daty naplnit. Navíc při každé změně v těchto údajích by se musely okamžitě aktualizovat i údaje v naší databázi. V současné době by byla realizace této myšlenky poněkud problematická, nicméně může to být námět ke změně do budoucna.

4.3

Omezení dat

Pro udržení databáze v konzistentním stavu je třeba definovat některá omezení. Některá omezení takového typu, která mají za úkol řešit správnost vstupních dat, budou aplikována až v php skriptech i s případným ošetřením nekorektních vstupů v podobě chybových hlášení a zabránění v akci a podobně. Přímo v databázi však není problémem definovat alespoň základní omezení NOT NULL, které zamezí vložení prázdné hodnoty do sloupce, kde by z povahy daných dat neměla nulová hodntota figurovat. V naší databázi bude takových situací celá řada, jako příklad můžeme uvést alespoň tabulku zakaznici: z hlediska funkčnosti aplikace musí mít každý zákazník svůj login a heslo, dále musí mít uloženo i jméno a příjmení, datum narození a také e-mailovou adresu k zasílání potrvzení o provedených objednávkách. Tyto všechny položky jsou povinné, budou tedy označeny jako NOT NULL. Telefonní číslo nebude muset každý zákazník zadávat, proto tento atribut povinný nebude. Další omezení UNIQUE nám zabrání vložení duplicitních hodnot do sloupce tabulky, neboli zajistí jedinečnost hodnot sloupce. Opět je potřeba omezení UNIQUE definovat jednotlivě každému atributu, kterých najdeme opět větší množství. Příklad můžeme uvést stejně tak jako v minulém případě z tabulky zakaznici: zde jako

4.4

Vytvoření databáze

25

unikátní označíme atribut login (z hlediska jeho funkce musí být jednoznačně unikátní). Diskutovat by se dalo i o atributu email, avšak budeme předpokládat, že se může vyskytnout situace, kdy více osob může používat jednu e-mailovou schránku, nebo že by zákazník mohl z nějakého důvodu přestat používat jeden účet a vytvořit si nový opět se stejnou e-mailovou adresou, proto tento sloupec jako unikátní neoznačíme. Primární klíče jsou kombinací obou již zmíněných omezení, NOT NULL a zároveň i UNIQUE. Všechny primární klíče v modelu máme datového typu serial, což implicitně zajistí unikátnost všech jejich hodnot i neprázdnost. Tento datový typ nám přináší navíc další výhodu spočívající v tom, že nemusíme pro každý klíč vytvářet sekvenci, ale vytvoří se nám v databázi automaticky. Cizí klíče musejí vždy odpovídat hodnotě v některém řádku jiné tabulky. V používaném programu Toad Data Modeler se atributy cizích klíčů automaticky vytvoří vždy po definování vztahu mezi dvěma tabulkami a příkazy pro jejich vytvoření lze navíc automaticky vygenerovat. Každému cizímu klíči se potom ještě definují akce ON DELETE a ON UPDATE, které určují, co se stane, chceme-li aktualizovat nebo smazat primární klíč na který je odkazováno v cizím klíči. V navržené databázi budou různé případy těchto akcí, podívejme se ovšem opět například na tabulku zakaznici a její cizí klíč id_spravci. Pokud by se smazala určitá osoba z tabulky spravci, mohli by být v některém případě vymazání i všichni zákazníci, kteří se na mazaný záznam odkazují. Tomu lze jednoduše zabránit definováním akce ON DELETE RESTRICT, která takovouto změnu zakáže. Jako ON UPDATE akci pro tento případ definujeme CASCADE, což zajistí v případě změny v hodnotě primárního klíče aktualizaci všech sloupců v cizích klíčích, které se na hodnotu tohoto primárního klíče odkazují.

4.4

Vytvoření databáze

Všechny výše uvedené kroky bylo možno provádět přímo v prostředí softwaru Toad Data Modeler. V tuto chvíli je již vhodné databázi podle vzniklého modelu vytvořit na vzdáleném serveru a případné další úpravy provádět až na ní. Jako úložiště byl vybrán server Internet Centrum (http://www.ic.cz/), kde je poskytována freehostingová služba s prostorem v databázi PostgreSQL verze 8.1. S databází na tomto serveru je možné pracovat pomocí webového rozhraní phpPgAdmin, což nám ulehčí práci. Tvorbu vlastní databáze nám výrazně ulehčí použitý CASE nástroj, který dokáže podle vytvořeného ERD vygenerovat SQL skript pro vytvoření databáze i se všemi zmíněnými omezeními. Vygenerovaný skript stačí v rozhraní phpPgAdmin zkopírovat do okna pro vkládání sql scriptů a databázi máme na vzdáleném serveru vytvořenou. Pro všechny primární klíče datového typu serial byly zároveň automaticky vytvořeny sekvence (jak bylo zmíněno výše) ve tvaru nazev_tabulky_nazev_sloupce_seq. Ty zajistí při každém vkládání nového zá-

4.5

Triggery a funkce

26

znamu do tabulky vždy přiřazení primárního klíče s hodnotou o 1 větší, než je u posledního vloženého řádku.

4.5

Triggery a funkce

Jednou z věcí, které je možné vytvořit až na hotové databázi, jsou triggery. Které nám umožňují provádět akce na základě operací INSERT, UPDATE a DELETE. V systému PostgreSQL lze volat v triggeru uložené funkce, které provedou danou akci po spuštění triggeru. Ve vytvořené databázi najdeme několik případů, kdy bude definování určitých akcí v určitou chvíli nutné pro zachování integrity dat v databázi. Poměrně jasná situace vhodná na použití triggerů bude v případě tabulek, které definují síť tarifních zón. Je třeba zajistit, aby záznamy v tabulce zony byly vždy totožné se záznamy v tabulce okolnizony. Pro tutou situaci požijeme celkem 3 triggery, z nichž každý bude volat vždy jednu uloženou proceduru. Alespoň jednu z nich by bylo vhodné ukázat, zabývejme se tedy například případem, kdy se do sýstému ukládá nová zóna s určitým číslem. Při uložení nového záznamu do tabulky zony se musí totéž uložit i do tabulky okolnizony. Akce by se dala rozepsat na dva jednotlivé SQL dotazy, to by však nebylo tak efektivní, jako využití triggeru, který se v této situaci přímo nabízí. Nejprve se musí vytvořit procedura, kterou bude trigger volat. Pro její definici použijeme jazyk plpgsql a bude vypadat následovně: CREATE FUNCTION trig_zony() RETURNS OPAQUE AS ’ BEGIN IF TG_OP = ’’INSERT’’ THEN INSERT INTO okolnizony (id_okolnizony, cislo_okolnizony) VALUES (default, new.cislo_zony); RETURN new; END IF; END; ’ LANGUAGE ’plpgsql’; Tento zápis říká, že pokud funkci zavolá příkaz INSERT, tak se provede další příkaz INSERT, který uloží do tabulky okolnizony nový záznam s takovým číslem zóny, které se rovná číslu zóny v příkazu INSERT, který akci vyvolal. Poté se vytvoří vlastní trigger, který bude definován tímto zápisem: CREATE TRIGGER zony_trg AFTER INSERT ON zony FOR EACH ROW EXECUTE PROCEDURE trig_zony(); Definice triggeru říká, že po příkazu INSERT v tabulce zony se vyvolá procedura trig_zony(). Podobným způsobem se budou tvořit další procedury a triggery v dalších případech, kde to bude vhodné

4.6

4.6

Pohledy

27

Pohledy

Pro některé situace bude vhodné definovat pohledy (v PostgreSQL zvané náhledy), které nám později ulehčí práci. První z nich bude použit pro práci s výpisem všech zón a jejich okolních zón. Jeho definice bude vypadat následovně: CREATE VIEW zony_view AS SELECT zony.id_zony, zony.cislo_zony, okolnizony.cislo_okolnizony, okolnizony.id_okolnizony FROM zony, zony_okolnizony, okolnizony WHERE zony.id_zony = zony_okolnizony.id_zony AND okolnizony.id_okolnizony = zony_okolnizony.id_okolnizony AND zony.aktiv = true ORDER BY zony.cislo_zony, okolnizony.cislo_okolnizony; Tímto vznikne tabulka, která bude v jednotlivých řádcích spojovat vždy číslo určité zóny s číslem jedné ze sousedních zón dané zóny a navíc i primární klíče obou záznamů. Řádky budou navíc seřazené podle čísel zón a dále podle čísel jejich okolních zón, přičemž budou do tohoto pohledu zařazeny jen aktivní záznamy. Pohled bude později s výhodou využit například k výpisu všech aktivních zón s jejich všemi sousedními zónami. Další pohled potom použijeme například také pro práci s osobami obsluhujícími systém a jejich právy pro vstup do určitých částí systému. V této situaci bude pohled použit ke vzniku dočasné tabulky spojující jednotlivé osoby a jejich práva podobným způsobem jako v předchozím případě.

4.7

Naplnění daty

Nyní je databáze hotová a připravená k naplnění daty. Pro každou tabulku připravíme SQL skript pro naplnění korektními daty, na kterých bude možné testovat funkčnost aplikace. Většinu tabulek naplníme pochopitelně fiktivními daty, které by byly při provozu aplikce nahrazeny daty skutečnými. Nicméně i tato fiktivní data musí být v takové podobě, v jaké budou později data skutečná, aby na nich bylo možné otestovat všechny možnosti aplikace. V některých tabulkách ale přesto bude vhodnější vytvořit data už přímo reálná. Týká se to především tabulek definujících systém tarifních zón, tedy zony, zony_okolnizony a okolnizony a také všechny tabulky týkající se druhů dokladů včetně příslušných číselníku. Nakonec nesmíme zapomenout ani na tabulku definující práva osob obsluhujících systém. V ostatních tabulkách postačí pro testování data fiktivní.

5

TVORBA VLASTNÍ APLIKACE

5

28

Tvorba vlastní aplikace

Nyní je připravená databáze naplněná veškerými potřebnými daty, můžeme proto přejít k tvorbě vlastní aplikace pracující s touto databází. Uživatelské rozhraní bude tvořeno pomocí XHTML a k definování jeho vzhledu bude použita technologie kaskádových stylů (CSS). Ke generování XHTML kódu, práci s databází a provádění veškerých akcí v aplikaci bude sloužit skriptivací jazyk PHP.

5.1

Vzhled uživatelského rozhraní

Pro prozatímní jednoduchost a přímočarost byl použit pro všechny části systému prakticky totožný vzhled. Byl při tom kladen důraz na jednoduchost a přehlednost uživatelského rozhraní. Co se týká částí, do kterých budou přistupovat osoby obsluhující systém, tedy například administrátoři a lidé vyřizující objednávky, bude tento vzhled jedině pozitivní vlastností. V těchto případech bude třeba se v uživatelském rozhraní především rychle orientovat a provádět potřebné akce, nikoliv obdivovat podařený grafický vzhled. Zde bude tedy v jednoduchosti skutečně síla. U části aplikace, kterou budou používat zákazníci, mohou být požadavky již jiné, kdy by měl být vzhled propracovanější a pro zákazníka příjemný. V případě skutečného provozu aplikace by však vzhled této části záležel především na přání provozovatele a na domluvě s ním, přičemž by zároveň byla aplikace pravděpodobně nějakým způsobem včleněna do současných fungujících webových stránek Integrovaného dopravního systému Jihomoravského kraje. Z těchto důvodů necháme konečný vzhled dané části otevřený a vyřešíme jej zatím jednoduchým způsobem, nicméně přehledným a v každém případě fungujícím. Ostatně i zmíněné webové stránky mají vzhled poměrně nenáročný, kdy byl kladen důraz než na oslnivou grafiku spíše na přehlednost a jednoduchost. Vzhled aplikace bude však vytvořen tak, aby alespoň určitým způsobem korespondoval se stránkami IDS JMK. To bylo dohodnuto i při konzultaci s příslušným zaměstnancem společnosti Kordis a svoleno k použití grafických prvků právě z fungujících stránek. Pozadí stránek bude ponecháno bílé a na další prvky budou použity barvy ze stránek IDS JMK, kterých není velké množství. Jednak je to dominantní světle zelená barva použitá především u menu a nadpisů tabulek. Dalšími převzatými barvami budou světle žlutá jako pozadí některých prvků a také červenohnědá používaná u odkazů. Dalším přejatým prvkem bude ikona stránky, známá jako favicon.ico. Jedná se o jednoduchý malý obrázek o rozměrech 16 × 16 pixelů, který se zobrazuje například v prohlížeči Mozilla Firefox u názvu panelu s otevřenou stránkou nebo také v nabídce Záložky po přidání dané stránky do záložek. Použití takovéto ikonky působí příjemněji, než implicitní anonymní obrázek bílého listu papíru. Základní layout rozhraní bude rozdělen na horní pruh s nadpisem sekce, dále bude následovat pruh s informací o přihlášeném uživateli a pruh s hlavním menu dané sekce. Zbytek stránky bude tvořit hlavní pracovní okno pro zobrazování všech informací a dialogů. Tohoto rozvržení dosáhneme použitím XHTML prvků
,

5.2

Programování jednotlivých částí

29

kdy jeden bude tvořit celou stránku a další, představující jednotlivé části, budou do onoho základního vnořené. U všech prvků bude nastavena pouze výška, šířka bude ponechána automatická, bude se tedy přizpůsobovat velikosti okna prohlížeče. Pro zpřehlednění bude celé hlavní pracovní pole a také nějaké další prvky odděleny od zbytku prostoru tenkou tečkovanou čarou o šířce jednoho pixelu (která se však v některých především starších verzích prohlížeče Internet Explorer jeví vlivem jeho nedokonalosti jako čárkovaná). Vzhled hlavního menu byl inspirován do určité míry opět stránkami IDS JMK, čož však neplatí o jeho rozvržení. V této aplikaci nebude menu v žádné sekci obsahovat tolik položek, aby muselo být řešeno vertikálně, proto jej můžeme zformátovat do horizontální podoby jako jediný pruh. Jednotlivé položky menu jsou tvořeny odkazy s bílým písmem a zeleným podkladem, které po najetí kurzoru mění barvy písma a podkladu přesně do inverzní podoby. Každá stránka bude vygenerována vždy příslušným PHP skriptem a ke všem bude připojen společný soubor, kde budou definovány všechny potřebné styly zajišťující popsaný vzhled uživatelského rozhraní.

5.2


Aplikace bude rozdělena do čtyř funkčních částí, které mohou být vyvíjeny nezávisle na sobě. Ty bude spojovat jen práce se společnými daty z vytvořené databáze, ale každá bude mít jinou funkci. Do tří částí budou mít přístup osoby obsluhující aplikaci, tedy pravděpodobně zaměstnanci pozdějšího provozovatele systému. Poslední částí bude ta, kterou budou používat zákazníci a bude mít podobu jednoduchého e-shopu. Pro každou část bude sestaveno několik PHP skriptů různého rozsahu a složitosti, avšak některé části lze definovat jako společné pro všechny skripty. Nyní se tedy zabývejme problémy programování jednotlivých částí systému. 5.2.1

Společné funkce

Nejprve se zaměříme na části programového kódu, které budou pro všechny skripty společné. V některých případech je totiž kvůli přehlednosti a zjednodušení mít určité části společného charakteru vytvořené a odladěné v jednom souboru, který se potom ke všem ostatním jen jednoduše připojí. Jedná se především o funkce používané zároveň na více místech. Jako naprosto jasný příklad se jeví například funkce pro připojení k databázi. Pokud aplikace pracuje nad jednou databází, bude tato funkce na začátku každého skriptu vždy totožná. Místo toho, abychom fukci kopírovali na začátek každého skriptu zvlášť, tak ji s výhodou vložíme do společného souboru, na který uvedeme odkaz na začátku každého skriptu, který tuto funkci bude používat. Při případné změně parametrů funkce ji nebudeme muset ve všech skriptech přepisovat, ale změníme ji pouze na tom jediném místě. Soubor pro společné funkce si pojmenujeme common.php. Jako první věc v něm bude použita funkce pg_connect pro připojení k PosgreSQL databázi, která má

5.2


30

parametry: adresa serveru, uživatel, heslo a název databáze. Výsledek funkce uložíme do proměnné $connection, kterou později použijeme na dalších místech. Ihned v zápětí za zmíněnou funkcí ještě musíme volat SQL dotaz, který zajistí práci s příslušným schématam v databázi. Poté hned následuje jednoduchá podmínka, která zjišťuje obsah proměnné connection. V případě hodnoty false se připojení k databázi nezdařilo, proto je třeba celý skript ukončit. Dále zde bude figurovat funkce pro výpis XHTML hlavičky stránky. Ta bude ve všech případech totožná, měnit se bude jen titulek, proto bude funkce obsahovat jeden parametr právě pro text titulku stránky. Další jednoduchá funkce bude sloužit pro zašifrování hesla určité osoby před uložením do databáze. Bude požadovat 2 parametry, a to nejprve login osoby a potom právě její heslo. K zašifrování použijeme hashovací funkci sha1, která řetězec na vstupu převede na řetězec pevné délky (zde konkrétně 40 znaků), takzvaný hash, ze kterého se původní řetězec nedá v rozumném čase zpátky zjistit. Spolu s heslem budeme posílat na vstup této funkce i login z prostého důvodu, a tím je kolize hesel – když dva uživatelé zadají stejné heslo, tak má i stejný hash a když to jeden z uživatelů jakkoliv zjistí, může se přihlásit i na druhého uživatele. Login však musí mít každá osoba unikátní, takže spojení hesla s loginem před zašifrováním se jeví z tohoto pohledu jako bezpečné. Tento způsob ukládání hesel sice znemožní zaslání zapomenutého hesla, avšak je nutný z bezpečnostních důvodů. V případě zapomenutí hesla bude mít administrátor možnost vygenerovat dané osobě náhodné dočasné heslo a ta si jej po prvním přihlášení změní. Následuje funkce pro vygenerování náhodného řetězce, převzatá z weblogu Jakuba Vrány o elegantním programování v PHP pro mírně pokročilé. Ta obsahuje 2 parametry, první definuje délku vráceného řetězce a druhý rozsah použitých znaků (Vrána, 2006). Figurovat zde bude také ještě funkce sloužící pro navigaci při nákupu v e-shopu, její význam však bude popsán později. 5.2.2

Přihlašování uživatelů

Dvě mírně složitější funkce také umístěné ve společném souboru budou použity pro přihlašování uživatelů do systému, z nichž jedna bude sloužit pro přihlašování zákazníků do e-shopu a druhá pro přihlašování osob obsluhujících systém. Základ obou funkcí bude stejný, lišit se budou jen SQL dotazem, který bude porovnávat zadané přihlašovací údaje s údaji v databázi. Přihlašování uživatelů bude řešeno pomocí SESSION, musí se tedy SESSION nejdříve spustit příkazem session_start(), který bude umístěn také v připojovaném souboru common.php. Jako příklad můžeme uvést funkci auth_zakaznici pro přihlašování zákazníků do systému. Takto vypadadá v podobě lehce zkrácené o výpis html kódu pro přihlašovací formulář: function auth_zakaznici($conn) { if (isset($_POST[’auth_login’])) { $query = ’SELECT id_zakaznici, jmeno, prijmeni FROM zakaznici WHERE login = \’’.pg_escape_string($_POST[’auth_login’])

5.2


31

.’\’ AND heslo = \’’.sha1(pg_escape_string($_POST[’auth_login’]) .pg_escape_string($_POST[’auth_heslo’])).’\’’; $query_res = pg_query($conn, $query); if ($result = pg_fetch_array($query_res)) { session_regenerate_id(); $_SESSION[’id_zakaznici’] = $result[’id_zakaznici’]; $_SESSION[’jmeno_zakaznici’] = $result[’jmeno’]; $_SESSION[’prijmeni_zakaznici’] = $result[’prijmeni’]; } } if (!isset($_SESSION[’id_zakaznici’])) { print_head(’Příhlášení’); echo ’
’; if (isset($_POST[’auth_login’])) { echo ’
Neplatné přihlašovací údaje.
’; } \,\dots // vypis html kodu pro prihlasovaci formular \,\dots exit; } } V pořadí druhá hlavní podmínka v tomto zápisu ohraničuje úsek, který proběhne v případě, že osoba dosud není přihlášena. Zavolá se nejprve funkce pro výpsi HTML hlavičky a poté se na střed stránky zobrazí krátký formulář s políčky pro zadání loginu a hesla spolu s tlačítkem pro potvrzení. Ošetřena je zde také situace, kdy by už jednou byly zadané přihlašovací údaje, avšak nekorektní, potom se vypíše upozornění na tuto situaci. První podmínka potom proběhne, pokud uživatel vyplní údaje k přihlášení a klepne na potvrzovací tlačítko. Spustí se SQL dotaz, který porovná zadané hodnoty s hodnotami v databázi. Zde stojí za zmínku použití funkce pg_escape_string pro zpracování textových řetězců vepsaných zákazníkem. Ta zajišťuje ochranu uživatelských vstupů proti SQL injection. V případě, že se podaří dotaz spustit a ten vráti nějaký vysledek, je ze všeho nejdříve zavolána funkce session_regenerate_id. Ta zde figuruje opět z důvodu bezpečnosti, kdy zaručuje ochranu proti Session Fixation. Jedná se o útok, kdy útočník klientovi nastaví nějakou hodnotu Session ID (podstrčením odkazu na webu, v e-mailu nebo např. přímou editací uživatelových cookies) a jakmile se uživatel přihlásí, tak tuto Session ID použije pro sebe. Na obranu proti tomuto typu útoku stačí před prováděním citlivých operací jako je přihlašování zavolat zmíněnou funkci, která způsobí změnu Session ID, takže původní ID útočník nebude moci využít (Vrána, 2005). Po prove-

5.2


32

dení této funkce bude následovat uložení hodnoty atributu id_zakaznici do session proměnné, která bude vždy jednoznačně identifikovat právě přihlášeného zákazníka. Dále se pro určité další potřeby uloží do session proměnných i jméno a příjmení dané osoby. Funkce pro přihlašování osob obsluhujících systém byde v podstatě totožná, bude však navíc obsahovat parametr, který bude definovat, jaké právo musí vlastnit osoba pro přístup do dané sekce. Použitý SQL dotaz ve funkci bude navíc rozšířen o podmínku, která zjistí, zda přihlašovaná osoba potřebné právo vlastní. Pokud ne, přístup jí nebude umožněn. Ve společném souboru musí být také samozřejmě umístěna i funkce pro odhlášení dosud přihlášeného uživatele. Bude univerzální pro odhlašování obou skupin uživatelů, její použití pro každou skupinu bude definováno paramatrem funkce. Spustí po stisknutí příslušného tlačítka v pravém horním rohu uživatelského rozhraní a způsobí jen jednoduchým způsobem uvolnění session proměnných s informacemi o přihlášeném uživateli. Volání funkcí pro přihlášení a odhlášení bude v každém skriptu umístěno tak, aby se po odhlášení objevil opět pouze přihlašovací formulář. 5.2.3

Administrační sekce

Co se týká tvorby jednotlivých vlastních částí systému, zabývejme se nejdříve pohledem na administrační sekci. Do ní se budou přihlašovat uživatelé s příslušným právem ke vstupu, s největší pravděpodobností zaměstnanci provozovatele aplikace. Požadavky jsou takové, aby zde bylo možno přidávat, mazat a měnit ty položky v databázi, které v průběhu užívání systému bude třeba aktualizovat. To se týká především druhů dokladů, které budou v e-shopu nabízeny, jejich nabídka se může do budoucna měnit, také samozřejmě jejich ceny. Dále může přijít potřeba změny v definici sítě tarifních zón, integrovaný systém se v buoucnosti může rozšířit (což se skutečně předpokládá), případně se může změnit rozvržení některých zón. Další data, která bude potřeba občas aktualizovat, se budou týkat prodejních míst a jejich adres, kde budou mít zákazníci možnost si vyzvednout svoje objednávky. A také je ještě třeba myslet na administraci osob, které budou mít do systému přístup, včetně udělovaní jim příslušných práv ke vstupu. Pro administraci každého ze zmíněných druhů udajů budou sloužit vždy 2 PHP skripty. Jeden pro výpis všech údajů a případné jejich mazání, druhý pro přidávání nových ůdajů a editaci těch stávajících. Soubor doklady_vypis.php se bude starat o výpis všech existujících druhů dokladů zařazených do systému. V tabulce výpisu se bude jeden řádek rovnat vždy jednomu druhu dokladu a bude obsahovat vždy název dokladu, cenu a další příslušné parametry a také odkaz na druhý skript pro editaci daného druhu dokladů. Výpis bude rozdělený do dvou tabulek, kdy v první z nich budou aktivní položky a ve druhé neaktivní. Tuto aktivitu a neaktivitu určí právě dříve zmíněný atribut aktiv u některých entit v databázi. Protože jednotlivých druhů dokladů je při kombinaci všech jejich parametrů široká řada, výpis bude vždy regulován na jednu skupinu dokladů určenou druhem zákazníka a dále tím, zda bude doklad platit i současně pro

5.2


33

obě brněnské zóny, či nikoliv. Nad tabulkou s výpisem údajů bude umístěn ovládací prvek pro výběr příslušné skupiny dokladů k výpisu. V horní části stránky bude také figurovat odkaz na skript doklady_edit.php pro vytvoření nového druhu dokladů. Jak bylo řečeno, tento druhý skript bude sloužit také pro editaci již existujícího záznamu. Editace se spustí pouze v případě, když bude skriptu předán metodou GET parametr id obsahující hodnotu primárního klíče určitého záznamu. Bude zajištěno, že při podstrčení nekorektní hodnoty do proměnné $_GET[’id’] bude skript ukončen s chybovou hláškou. Při ukládání změn záznamu nebo celého nového záznamu je vždy ošetřena otázka, zda jsou vyplněna všechna povinná pole ve formuláři. Pokud by tomu tak nebylo, bude následovat chybové hlášení. Navíc jsou všechny uživatelské vstupy opět ošetřeny dříve zmíněnou funkcí pg_escape_string, jak tomu je ostatně u všech vstupů v celé aplikaci. Pro spuštění příslušné části skriptu, kde se do databáze zasílá SQL dotaz INSERT nebo UPDATE, se testuje v poli $_POST přítomnost prvku s názvem, který se rovná názvu tlačítka sloužícího k odeslání příslušného fromuláře.

Obr. 3: Administrační rozhraní – výpis typů dokladů Pro práci se záznamy o prodejních místech je situace obdobná. Opět dva skripty, jeden provádí výpisy záznamů a druhý záznamy ukládá a edituje. Na první pohled podobná situace bude i u části pro práci s tarifními zónami, avšak dva skripty na tomto místě použité budou mít vnitřní strukturu poněkud složitější. U výpisu zón se všemi sousedními zónami se s výhodou využívá pohledu zony_view, odkud se čerpají veškerá data. V každém řádku však kromě odkazu k editaci záznamu bude i možnost jeho smazání. Po jeho spuštění se nejprve zobrazí dialog pro potvrzení

5.2


34

smazání, bez tohoto ošetření by náhodné klepnutí na tento odkaz mohlo mít velice nepříjemné následky. Po klepnutí na ano daný záznam skutečně zmizí, avšak pouze zdánlivě. Dojde totiž nejprve ke skutečnému smazání dané zóny z tabulky okolnizony. Následně se touto akcí spustí trigger, který zajistí pouze přepnutí atributu aktiv u příslušné zóny v tabulce zony na false. Zóna se totiž nemůže skutečně smazat, protože pokud nějaký čas existovala, bude pravděpodobně figurovat na objednaných dokladech a vydaných průkazkách, pro uchování korektních dat a historie nákupů tedy nebude skutečné odstranění možné. Co se týká ukládání novách zón, po vyplnění příslušného formuláře s definovanými okolními zónami nové zóny se nejprve spustí SQL dotaz INSERT k uložení záznamu do tabulky zony. To způsobí spuštění dalšího triggeru, který uloží záznam se stejným číslem zón také do tabulky okolnizony. Následně se ještě spustí další dotaz, který uloží příslušné záznamy o vztazích mezi zónami také do tabulky zony_okolnizony. Poslední 2 skripty použité v administrační sekci budou sloužit k administraci správcovských účtů včetně práv ke vstupu do různých sekcí. Předpokládá se, že přístup k těmto funkcím by neměl mít asi každý, kdo bude mít přístup k ostatním nastavením, proto bude existovat také zvláštní právo právě pro přístup k těmto možnostem. První skript bude sloužit k výpisu všech osob, podobným způsobem jako například výpis typů dokladů, kde bude u každé položky uveden i odkaz k její editaci a nad tabulkou také odkaz na vytvoření nového účtu. Tyto dvě posledně jmenované akce bude provádět druhý skript spravci_edit.php. Při ukládání nové osoby, se po odeslání formuláře s vyplněnými údaji a definovanými právy spustí nejprve SQL doataz pro uložení záznamu do tabulky spravci. Protože je potřeba uložit také údaje o přiřazených právech nové osobě, spustí se v zápětí další dotaz INSERT pro tabulku spravci_prava. Protože je zde potřeba uložit pro každý záznam hodotu primárního klíče právě uloženého záznamu o osobě, je třeba získat tuto hodnotu ze sekvence pro tabulku spravci. V tomto konkrétním případě získáme požadovanou hodnotu tímto zápisem: currval(\’spravci_id_spravci_seq\’). Při změnách v tabulce spravci_prava při ukládání změn již existující osoby se nejprve všechny záznamy o právech pro danou osobu smažou a následně se vloží nové aktuální záznamy již popsaným způsobem. Problém by se dal určitě řešit i jiným způsobem, kdy by se dala zkoumat změna pro každý záznam zvlášť a při tom mazat a přidávat jen nezbytně nutné položky, což by však bylo výrazně náročnější na implementaci. Použitý způsob je však v každém případě vpořádku a funkční. 5.2.4

Výdej průkazek a dokladů

U této části aplikace se předpokládá použití na prodejních místech, kde by se vydávaly průkazky a doklady a kde by si zákaznící případně mohli vyzvednout i svoje objednané doklady. Na těchto místech se také budou zákazníci registrovat pro používání tohoto systému. V této sekci tedy bude jednak potřeba vytvářet nové zákaznické účty. Novému zákazníkovi se musí následně přiřadit nová průkazka, což zde bude také řešeno. A nakonec, když zákazník vlastní průkazku, může si na ni nechat vy-

5.2


35

dat doklad, což bude posledním hlavním problémem zde řešeným. Aplikace se však musí vytvořit takovým způsobem, aby bylo možné kromě všech úkonů při vzniku nového zákazníka také přidávat nové průkazky již existujícím zákazníkům a také jim vydávat nové doklady na průkazky existující již delší dobu, tedy nejen na ty právě vydané. Pro tuto sekci jsou vytvořeny 3 skripty, kdy každý z nich řeší odlišnou situaci. První z nich, zakaznici.php, bude sloužit především k vytvoření nového zákaznického účtu. Povinnými atributy pro vznik každého účtu bude jméno a příjmení, datum narození a e-mailová adresa, ostatní údaje si bude moci zákazník později vložit sám. Vkládání data narození je vyřešeno třemi roletkovými menu, pro výběr čísla dne, měsíce a roku. Tento způsob je lepší oproti přímému vepsání hodnot do políčka v tom, že je zabráněno vepsání data v nekoretním formátu. U políčka pro zadání e-mailu je zatím ošetřeno alespoň, zda je nějaká hodnota vyplněná. Existoval by i způsob, jak zjistit, zda zadaná e-mailová adresa skutečně existuje, avšak implementace by byla poněkud složitější. Nicméně i toto může být námět pro vylepšení do budoucna. Při vytvoření nového účtu je zákazníkovi vygenerováno identifikační číslo pro přihlašování (login) a také náhodné dočasné heslo. Tyto informace jsou odeslány na zadanou e-mailovou adresu a je doporučeno, aby si zákazník po prvním přihlášení do systému svoje dočasné heslo změnil. Pro odesílání e-mailů je v PHP přítomná funkce mail() se 4 parametry, a to adresa příjemce, předmět zprávy, vlastní tělo zprávy a hlavičky. V hlavičkách je potřeba definovat především správné kódování znaků (v našem případě UTF-8) a další údaje, aby se zpráva odeslala korektně. Problém se vyskytnul v předmětu zprávy, který bylo třeba zvlášť ošetřit pro správné zobrazení českých znaků. Pro něj bylo zvoleno zakódování pomocí funkce imap_8bit() a další úprava. Sestavení celého e-mailu a jeho následné odeslání příslušnou funkcí vypadá následovně (při vypuštění obsahu těla zprávy pro zkrácení): $predmet = ’Potvrzení registrace -- jízdenky IDS JMK’; $predmet = imap_8bit($predmet); $predmet = "=?utf-8?Q?".$predmet."?="; $from = ’[email protected]’; $zprava = "\,\dotsobsah zprávy\,\dots"; $charset=’UTF-8’; $headers="From: ".$from."\n" . "Content-Type: text/plain; charset=$charset; format=flowed\n" . "MIME-Version: 1.0\n" . "Content-Transfer-Encoding: 8bit\n" . "X-Mailer: PHP\n"; if (mail($_POST[’email’], $predmet, $zprava, $headers)) { echo ’
Registrační e-mail byl odeslán.
’; } V popisovaném skriptu zakaznici.php bude také navíc vyřešena možnost vyhledání zákazníka podle jeho identifikačního čísla a nebo podle příjmení. Po provedení

5.2


36

hledání se zobrazí tabulka s výpisem odpovídajících záznamů, kde bude u každého uveden přímý odkaz do dalšího skriptu pro přiřazení průkazky danému zákazníkovi. Nyní se tedy dostáváme k dalšímu skriptu v této sekci, který bude oproti ostatním poměrně rozsáhlejší a složitější. Jeho název je doklady.php a bude sloužit k přidávání zákaznímům nových dokladů do systému. Nový doklad může být vydán pouze na konkrétní platnou průkazku, proto musí být známý nejdříve její kód. K tomuto účelu skript spuštěný bez jakýchkoliv parametrů zobrazí jednoduchý dialog pro zadání čísla průkazky a její vyhledání. Vstup je samozřejmě ošetřen jako všechny ostatní a při zadání nekorektní hodnoty nebo kódu neexistující průkazky se vypíše chybová hláška. Po úspěšném vyhledání průkazky se zobrazí tabulka s výpisem všech jejích atributů a s odkazem pro vstup do dialogu k vytvoření nového dokladu. Pod touto tabulkou se zobrazí další, která zobrazuje informace o všech dosud vydaných dokladech na tuto průkazku v rámci tohoto systému, pokud takové existují. U každého je navíc barevně označeno, zda je v současné chvíli platný, či již nikoliv. Po klepnutí na odkaz pro přidání nového dokladu následuje skok do poměrně oddělené a rozsáhlé a zároveň nejsložitější části skriptu. Výběr parametrů dokladu je rozdělen do několika kroků, kdy jsou zvolené údaje průběžně ukládány do session proměnných, kde je zajišteno jejich uchování i při opakovaném spouštění skriptu. Po odeslání údajů v jakémkoliv kroku se na začátku skriptu nejdříve zjišťuje, který prvek způsobil odeslání údajů. Podle toho se odeslané údaje uloží do příslušných session proměnných a vloží se určitá hodnota do proměnné $page. Ta má ve sktiptu takovou úlohu, že se podle jejího obsahu rozhoduje, jaká část kódu se bude provádět, respektive co se zobrazí uživateli na monitoru. Toho je dosaženo použitím příkazu switch, který spustí vždy příslušnou část kódu pro danou hodnotu v proměnné page. Nyní se dostáváme k popisu toho, co se děje v jednotlivých krocích. Nejdříve se do session uloží kód průkazky, na kterou se nový doklad vydává a také, jakého druhu je tato průkazka (co se týká druhu zákazníka). Nový doklad bude totiž automaticky právě toho typu, jako je tato průkazka, jiná možnost není přípustná. Následně se zobrazí první část dialogu pro výběr dokladu, kde je třeba vybrat dobu platnosti dokladu. Ta je standardně měsíční nebo čvrtletní, avšak pro typ zákazníka „základníÿ může být vydána i jízdenka roční. Podle druhu zákazníka se tedy nabídnou vždy povolené možnosti k výběru. Po potvrzení se vybrané údaje uloží do příslušné proměnné v session a zobrazí se další dialog k výběru zón, pro které bude doklad platit. Pokud se bude jednat o doklad platný pro všechny zóny, vybere tato možnost klepnutím na příslušné tlačítko. V opačném případě se v tomto kroku zadá číslo první z požadovaných zón. K tomu bude sloužit roletkové menu, kde budou v tomto kroku na výběr zcela všechny zóny uložené v databázi v tabulce zony. Po potvrzení následuje dialog pro výběr další zóny. Protože doklad může být vydán pouze na zóny, které s sebou sousedí a tvoří tak jeden propojený celek, jsou dále k výběru nabízeny jen právě ty zóny, které je možné přidat k již vybraným, aby byla podmínka splněna. Zde se využívá údajú v databázi o sousedních zónách každé existující zóny. Po přidání druhé zóny je možné samozřejmě opět přidat další a k tomu zobrazit opět stejný dialog, nebo právě vybíranou zónu přidat, ale výběr potom již

5.2


37

ukončit. K těmto volbám zde slouží příslušná tlačítka. Údaje o vybraných zónách se ukládají do session do speciální proměnné typu pole, kde indexy jednotlivých položek tvoří pořadí výběru dané zóny a hodnoty položek jsou čísla vybraných zón. Když se výběr zón ukončí, zobrazí se poslední dialog, kde jsou již vypsány údaje o konkrétním vybraném druhu dokladu. Toho se docílí tím, že se odešle do databáze SQL dotaz k výběru konkrétního záznamu z tabulky typy_dokladu, kterému se předají vybrané parametry obsažené v příslušných session proměnných a podle nich se vybere konkrétní druh dokladu. Vypíše se také jeho cena a zbývá už jen určit datum počátku platnosti nového dokladu. K tomu slouží opět stejný způsob jako v předchozích případech, navíc je zde implicitně nabídnuto právě aktuální datum. Když se tento poslední krok potvrdí, uloží se do databáze do příslušné tabulky záznam o novém dokladu a také záznam do tabulky vydani, kde se uloží datum a čas vydání dokladu a také informace o tom, která osoba doklad vydala a také na jakém výdejním místě. Datum konce platnosti dokladu, které musí být také definováno před uložením záznamu, se vypočítá na základě hodnot zadaných jako počátek platnosti a doby platnosti dokladu, k čemuž se využijí funkce mktime() a date(). Následně se ještě uloží potřebné záznamy do tabulky doklady_zony, které budou definovat, pro které zóny bude daný doklad platit. Pokud se jedná o typ dokladu platný pro všechny zóny, žádný záznam se neukládá. Pokud vše proběhne úspěšně, zobrazí se rekapitulace parametrů nově uloženého dokladu a na pozadí se uvolní všechny session proměnné použité v této části. 5.2.5

Objednávky a informace o zákaznících

Nyní se zaměříme na třetí a poslední sekci aplikace, kterou by využívaly osoby ze strany provozovatele systému. Bude sloužit jednak k prohlížení veškerých informací o přijatých objednávkách ze strany zákazníků a také k náhledu na všechny informace o jednotlivých zákaznících. Z toho vyplývá, že bude sloužit především osobám, které by měly na starosti vyřizování objednávek. Budou zde figurovat dva hlavní skripty, kdy bude každý řešit jednu ze zmíněných situací. První skript s názvem objednavky.php bude sloužit k evidenci objednávek a k získávání informací potřebných pro jejich vyřízení. Skript spuštěný bez jakéhokoliv parametru odešle do databáze SQL dotaz pro získání informací o všech objednávkách. Tato data se zobrazí v přehledné tabulce, kde každý záznam bude obsahovat zjednodušené informace vždy o jedné objednávce. Bude to především datum a čas objednání, požadovaný jízdní doklad, způsob doručení a způsob platby objednávky. Dále u každého záznamu také figuruje barevně zvýrazněná poznámka, zda je příslušná objednávka již vyřízena či nikoliv a odkaz k zobrazení podrobných informací o objednávce. Po klepnutí na něj se zobrazí 3 tabulky s informacemi. První z nich obsahuje informace týkající se přímo objednávky, jako je datum a čas jejího vzniku, způsob doručení a plaby a podobně. Druhá tabulka poskytuje komletní informace o objednávající osobě včetně její adresy a všech kontaktů. Poslední tabulka informuje o objednaném dokladu a všech jeho parametrech. Nachází se zde také

5.2


38

tlačítko, kterým lze označit objednávku za vyřízenou. Toho se dosáhne odesláním SQL doatzu, který v databázi v tabulce objednavky způsobí u příslušného záznamu změnu hodnoty v atributu vyrizeno na true. Později může z jakéhokoliv důvodu nastat situace, kdy bude třeba nějakou objednávku označit zpět jako nevyřízenou, tato možnost je zde také ošetřena. Ve druhé části této sekce, jejíž funkčnost zajišťuje skript zakaznici_info.php, bude možné nahlédnout na všechny informace o zákaznících, které se týkají jejich kontaktů. Bude zde možné vyhledat zákazníka podle jeho identifikačního čísla nebo podle příjmení. Po provedení hledání se zobrazí tabulka s relevantními výsledky, případně chybová hláška informující o neúspěšnosti hledání. 5.2.6

Zákaznická sekce – e-shop

Poslední ze čtyř sekcí, na které je celý systém rozdělen, budou využívat zákazníci a bude tedy asi nejčastěji využívanou. Tato část bude tvořena čytřmi hlavními skripty. První z nich bude přístupný bez autentiztace a měl by obsahovat informace o používání systému a jeho možnostech. Obsah těchto informací by však byl závislý až na domluvě s pozdějším provozovatelem systému. Následně bude na této stránce umístěn odkaz pro přihlašování registrovaných uživatelů vedoucí již na další skript. Skript zakaznik.php se spustí po přihlášení uživatele a na obrazovku vypíše informace o všech průkazkách a jízdních dokaldech, které kdy daný zákaznák vlastnil v rámci tohoto systému. Přitom aktualně platná průkazka a platný doklad jsou barvně odlišeny, pokud takové existují. Zákazník tedy má po přihlášení ihned přehled o tom, zda by bylo vhodné si již objednat nový doklad například při blížícím se konci platnosti toho aktuálního nebo jestli mu dosud platí jeho průkazka. Zde by bylo ještě vhodné vše provázat dalšími textovými informacemi, avšak to by opět později záleželo na domluvě s provozovatelem aplikace. Další položkou v menu jsou osobní údaje. Zde má zákazník přehled všech údajů o své osobě a také jeho kontaktů, přičemž některé údaje si může sám změnit. Možnost změn je rozdělena na tři části, kde první se týká údajů o osobě, druhá umožňuje editaci adresy, na kterou budou zákazníkovi zasílána objednávky a třetí slouží ke změně hesla, pomocí kterého se zákazník přihlašuje do systému. Při změně hesla je z bezpečnostních důvodů požadováno nejprve zadání stávajícího hesla a dvakrát hesla nového. Nové heslo se musí zadat dvakrát, aby se zamezilo překlepům při vpisování hesla, místo skutečných znaků totiž osoba v příslušném políčku vidí jen černé tečky. Po odeslání údajú o změně hesla je nejprve provedena kontrola, zda souhlasí staré heslo a následně zda jsou totožné oba řetězce představující nové heslo Poslední odkaz v menu již vede k zahájení vlastního nákupu. Zde zajišťuje celou funkčnost jediný skript nakup.php, který je nejrozsáhlejší a pravděpodobně nejsložitější ze všech skriptů použitých v aplikaci. Nákup probíhá v několika krocích, kde si zákazník postupně volí jednotlivé parametry objednávky a požadovaného jízdního dokladu. Pro lepší orientaci se vždy zobrazuje seznam všech kroků nákupu, kdy ten právě aktuální krok je zvýrazněn. K tomuto výpisu je použita dříve zmíněná

5.2


39

funkce ve společném připojovaném souboru common.php. Její název je navigace a předává se jí vždy jeden parametr, který označuje pořadí právě prováděného kroku. Na základě tohoto parametru se vypíšou vždy údaje ve správném tvaru pro daný krok. Definice této funkce vypadá následovně: function navigace($krok) { $pole = array(1 => ’Způsob doručení a platby’, 2 => ’Jízdenka - doba platnosti’, 3 => ’Jízdenka - výběr zón’, 4 => ’Rekapitulace a potvrzení objednávky’); foreach ($pole as $key => $val) { if ($key == $krok) { echo ’’.$key.’. ’.$val.’
’; } else { echo $key.’. ’.$val.’
’; } } } Při prvním kroku nákupu si zákazník zvolí způsob platby a způsob doručení objednávky. Způsoby zde nyní uvedené se mohou lišit od těch, které by byly nabízeny v případě skutečného fungování aplikce v praxi. Dále je zde také uvedeno doporučení, aby si zákazník zkontroloval svoji uloženou adresu, pokud by měl zájem o zaslání objednávky právě na ni a odkaz vedoucí k těmto údajům. Po potvrzení následuje druhý krok, kdy se přejde k výběru parametrů požadovaného jízdního dokladu. Typ dokladu z hlediska typu zákazníka je automaticky určen typem aktuálně platné průkazky daného zákazníka. Na výběr zůstává doba platnosti a datum počátku platnosti dokladu, kde výběr probíhá způsobem již popsaným v článku o výdeji průkazek a dokladů, konkrétně o skiptu doklady.php. Také je třeba říci, že výběr všech dalších parametrů dokladu probíhá způsobem popsaným na zmíněném místě a totéž se týká řízení a předávání a ukládání hodnot ve skriptu nakup.php, které bude vyřešeno stejným způsobem jako ve skiptu doklady.php. Ve třetím kroku si zákazník vybere zóny, pro které bude doklad platit a poté se přejde k poslednímu kroku celého procesu nákupu. Zde budou přehledně zrekapitulované veškeré zvolené údaje týkající se objednávky a vybraného dokladu. Také je zde umístěno textové pole, kde může zákazník vepsat jakoukoliv poznámku týkající se objednávky. Posledním prvkem je zde tlačítko pro potvrzení veškerých zvolených údajů a odeslání objednávky. Po jeho stlačení je třeba všechny údaje uložit do databáze. Jednak se do tabulky objednavky uloží všechny informace týkající se objednávky a atribut vyrizeno se u daného záznamu nastaví na false. Dále se uloží informace o požadovaném dokladu do tabulky doklady, kde se nastaví novému záznamu hodnota false u atributu vydany, aby bylo zřejmé, že tento záznam dosud neoznačuje vydaný fyzický doklad, ale pouze požadavek k jeho vydání. Jako

5.2


40

již vydaný se doklad označí po označení jeho objednávky za vydanou v sekci pro správu objednávek. Dále se musí ještě do tabulky doklady_zony uložit záznamy, které budou definovat, pro které zóny bude nový doklad platit (pokud se nebude jednat o doklad platný pro všechny zóny). Při potvrzení objednávky se také odešle zákazníkovi e-mail potvrzující přijetí objednávky včetně rekapitulace všech údajů v objednávce uvedených. Toto je řešeno opět stejným způsobem, jak bylo popsáno v článku o výdeji průkazek a dokladů, konkrétně o skiptu zakaznici.php.

6

6

DISKUZE

41

Diskuze

Vznikl webový systém, jehož jednotlivé části jsou dostupné na adresách: • http://idsjmk-jizdenky.ic.cz/admin – administrační část • http://idsjmk-jizdenky.ic.cz/prodej – výdej průkazek a dokladů • http://idsjmk-jizdenky.ic.cz/objednavky – objednávky a informace o zákaznících • http://idsjmk-jizdenky.ic.cz/eshop – sekce pro zákazníky (e-shop) Pro přístup do zákaznické sekce se lze přihlásit pod zkušebním účtem s loginem „2150276544ÿ a heslem „zakaznikÿ. Pro vstup do ostatních částí je vytvořen zkušební účet se všemy právy přistupu s loginem „adminÿ a heslem „adminÿ. Vytvořené řešení je nyní již vhodné zhodnotit. Systém byl vytvořen jako webová aplikace, z čehož plynou určité výhody. Ty byly již zmíněny na jiném místě této práce, zabývejme se tedy vlastnostmi konkrétního řešení. Za přednost sytému lze jistě považovat jeho jednoduchost. V dané chvíli je na dané stránce vždy jasné, jaké možnosti jsou nabídnuty a není složité se v nich orientovat. S tím je spojená i jednoduchost používání systému. U administračních účtů je výhodné použití konkrétních práv k přístupu, kdy majitel účtu má přístup opravdu jen tam, kde je to nutné k vykonáváni jeho úkolů. Co se týká technologického řešení, za kladné lze považovat použití databázového systému PostgreSQL, který nabízí velice slušné možnosti oproti například rozšířenému MySQL. Za pozitivní lze považovat také použití určitých alespoň základních bezpečnostních prvků, které se týkají bezpečného ukládání hesel, ošetření některých uživatelských vstupů a s tím spojená ochrana proti SQL injection či implementace ochrany proti Session Fixation. Jak bylo řečeno v úvodu, tato aplikace je však dosud pouze jakýmsi návrhem a pro nasazení do skutečného provozu by zcela jitě potřebovala určité úpravy. Jednou z věcí vhodných k mírné změně by mohl být vzhled zákaznického rozhraní. Práce s aplikací by pro zákazníky měla být nejen jednoduchá, ale i příjemná, což by mohlo přinést určité vylepšení vzhledu a zanesení určitých vhodných grafických prvků. Dále by aplikace měla být zcela jistě provázána spoustou doprovodných textových či grafických informací, které by ještě více usnadňovaly její používání. Uvedení do provozu by také přineslo požadavky na stoprocentní funkčnost a bezpečnost aplikce, což by s sebou také jistě přineslo jisté úpravy. Jednou z nich by zcela jistě bylo zavedení transakcí do databáze a tím zajištění správnosti fungování aplikace i například při souběhu práce administrátora a zákazníka. Pokud by měla být zákazníkům umožněna platba přes internet pomocí platební karty (což se předpokládá), bylo by nutné systém napojit na platební bránu a tomuto kroku jej případně i přizpůsobit. Které z těchto kroků dalšího vývoje aplikace budou realizovány a zda vůbec některé, není zatím jasné. O všech dalších postupech se bude jednat mimo rámec této práce, kdy bude zcela jistě nutné kromě posouzení efektivnosti pro zákazníky zkoumat také ekonomickou efektivnost případného používání tohoto systému.

7

7

ZÁVĚR

42

Závěr

Cílem práce bylo vytvořit funkční návrh aplikce, která by mohla ulehčit prodej předplatních nepřenosných jízdních dokladů v rámci IDS JMK. Byl vytvořen webový systém, který umožňuje zákazníkům objednat si požadovaný doklad přes internet a nechat si jej doručit domů či si jej již připravený vyzvednout na vybraném výdejním místě. Kromě zákaznické aplikace pro objednávání dokladů byly vytvořeny všechny další části potřebné k fungování systému. Jedná se především o aplikaci ke správě obsahu systému a dále části systému, které by používaly osoby vyřizující objednávky či vydávající nové doklady. Lze tedy konstatovat, že definovaný cíl byl splněn. Nejprve byla v práci popsána východiska, bez jejichž znalostí by nebyl další postup možný. Jednalo se především o fakta týkající se integovaného dopravního systému fungujícího na území Jihomoravského kraje, a to především co se týká systému tarifních zón a nabídky různých druhů jízdních dokladů s možnostmi jejich nákupu. Dále byly definovány přesné požadavky na aplikaci a také popsána fakta ohledně webových aplikací a technologií vhodných k jejich realizaci. Následoval pečlivý návrh datové struktury a její vytvoření. Dalším krokem již byla realizace a naprogramování jednotlivých částí systému, jejichž funkčnost byla vždy popsána a také byly zmíněny některé zajímavé či důležité momenty při implementaci. Vytvořené řešení bylo následně zhodnoceno a byly i definovány možné kroky k vylepšení aplikace do budoucna. Tato práce umožnila jejímu autorovi vyzkoušet si v praxi vědomosti získané studiem. To se týká především znalostí z oblasti databázových systémů a návrhu databází a také schopností algoritmického řešení konkrétních problémů či základů tvorby webových aplikací. K tvorbě této práce však bylo nutné mnoho informací a postupů individuálně nastudovat z literatury, což bylo také velkým přínosem pro autora. Také je třeba zmínit cenné zkušenosti získané vývojem aplikace pro konkrétní společnost a pro řešení konkrétního problému, což bylo spojeno s odbornými konzultacemi ohledně řešení aplikace přímo se zástupcem dané společnosti.

8

8

LITERATURA

43

Literatura

Bráza, J. PHP 5: začínáme programovat. 1. vydání. Praha: Grada Publishing, 2005. 244 s. ISBN 80-247-1146-X. Cascading Style Sheets [online]. Wikipedie, otevřená encyklopedie. Poslední revize 2. 4. 2009 [cit. 21. května 2009]. Dostupné na internetu: Cyroň, M. CSS: kaskádové styly: praktický manuál. 1. vydání. Praha: Grada Publishing, 2006. 340 s. ISBN 80-247-1420-5. Habrman, R. PostgreSQL, Úvod [online]. Owebu.cz. Poslední revize 7. 11. 2007 [cit. 21. května 2009]. Dostupné na internetu: Hernandez, Michael J. Návrh databází. 1. vydání. Praha: Grada, 2005. 408 s. ISBN 80-247-0900-7. HyperText Markup Language [online]. Wikipedie, otevřená encyklopedie. Poslední revize 27. 4. 2009 [cit. 21. května 2009]. Dostupné na internetu: Integrované dopravní systémy (IDS) [online]. Společnost pro veřejnou dopravu [cit. 21. května 2009]. Dostupné na internetu: KORDIS JMK, spol. s r. o. [online]. Integrovaný dopravní systém Jihomoravského kraje [cit. 21. května 2009]. Dostupné na internetu: PHP [online]. Wikipedie, otevřená encyklopedie. Poslední revize 14. 5. 2009 [cit. 21. května 2009]. Dostupné na internetu: Ponkrác, M. XHTML - živá voda na HTML [online]. Interval.cz. Poslední revize 15. 2. 2000 [cit. 21. května 2009]. Dostupné na internetu: Přehled prodejních míst [online]. Integrovaný dopravní systém Jihomoravského kraje [cit. 21. května 2009]. Dostupné na internetu: Skřivánek, F. Databázová abeceda -8211; Case nástroje [online]. Databázový svět. Poslední revize 23. 4. 2008 [cit. 21. května 2009]. Dostupné na internetu: Snížek, M. XHTML – vývoj (X)HTML a jeho možnosti [online]. Interval.cz. Poslední revize 22. 7. 2002 [cit. 21. května 2009]. Dostupné na internetu: Stručně o IDS JMK [online]. Integrovaný dopravní systém Jihomoravského kraje [cit. 21. května 2009]. Dostupné na internetu: Vrána, J. Kontrola e-mailové adresy [online]. Poslední revize 5. 5. 2006 [cit. 21. května 2009]. Dostupné na internetu:

8

LITERATURA

44

Vrána, J. Zabezpečení session proměnných [online]. PHP triky. Poslední revize 1. 7. 2005 [cit. 21. května 2009]. Dostupné na internetu: Webová aplikace [online]. Wikipedie, otevřená encyklopedie. Poslední revize 20. 4. 2009 [cit. 21. května 2009]. Dostupné na internetu: Webové aplikace [online]. MediaCentrik – profesionální internetové prezentace [cit. 21. května 2009]. Dostupné na internetu:

Systém pro online prodej jízdenek IDS JMK

Recommend Documents