opory

o výlučně na
straně klienta, správa databáze je umístěna na straně serveru. Server může fun-
govat zároveň jako klient jiného serveru v hierarchické klient–server architek-
tuře. Pak hovoříme o tzv. zřetězené dvouvrstvé architektuře (chained two tier
architecture).
Třívrstvá architektura (Three tier architecture) byla vyvinuta v devadesátých
letech jako nástupce architektury dvouvrstvé. Mezi vrstvu klienta a serveru
byla přidána třetí (prostřední – middle tier) vrstva. Tato vrstva může být im-
plementována různými způsoby a technologiemi například formou monitoru
transakčního zpracování (transaction processing monitor), serveru zpráv
(message server) nebo aplikačního serveru (application server). Může provádět
akce jako řazení požadavků do front, přidávat možnosti plánování a prioritního
zpracování. Zavedení střední vrstvy ulehčuje administraci a správu změn, pro-
tože případné změny se zapisují pouze jednou na server střední vrstvy, a tak se
stávají automaticky dostupné ve všech systémech. U jiných modelů by změna
funkce musela být zapsána do každé aplikace. Podařilo se překonat a odstranit
výkonnostní omezení týkající se dvouvrstvé architektury. Je zajištěn výkon i
pro velké skupiny současně pracujících klientů (řádově stovek až tisíců počíta-
čů).
Třívrstvá architektura je základem v současné době tak populárních interneto-
vých aplikací. Vrstvu klienta, která má na starosti grafické uživatelské rozhra-
ní, logicky přebírá internetový prohlížeč (web browser). Pro vytváření uživa-
telského prostředí máme k dispozici nástroje v podobě jazyka HTML, CSS,
pomocí skriptovacích jazyků na straně klienta a objektových modelů prohlíže-
če můžeme klientu svěřit i část logiky informačního systému.
Střední vrstvu představuje nejčastěji tzv. aplikační server, poskytující více slu-
žeb, které lze rovněž formálně od sebe oddělit (proto se často hovoří o n-vrstvé
architektuře). Základem střední vrstvy bývá webový server protokolu http, kte-
rý navíc disponuje rozšířením pro:
• udržování kontextu pro jednotlivé připojené uživatele
• poskytování zabezpečeného přístupu a ověřování oprávnění
• implementaci vlastní aplikační logiky informačního systému pomocí
vestavěného prostředí pro vytváření a používání programových objektů
• realizaci transakčního zpracování
• prostřednictvím vestavěných objektů obsahuje aplikační rozhraní pro
spolupráci se systémy SŘBD a jinými poskytovateli dat
• plus mnoho dalších možností
Zjednodušeným pohledem můžeme internetovou aplikaci vidět v podobě pro-
cesu, kdy
1. klient (prohlížeč internetu) požádá server o dokument s HTML formu-
lářem

12
Informační technologie a systémová analýza
2. po vyplnění formuláře uživatelem jsou data odeslána zpět na webový
server
3. ten předá data získaná od uživatele programu na aplikačnímu serveru,
který na jejich základě zformuluje potřebný dotaz SQL
4. dotaz je předán databázovému serveru, který dotaz (příkaz) provede a
vrátí nejčastěji databázovou relaci (tabulku)
5. aplikační server data získaná z databáze opatří značkami jazyka HTML
a odpověď prostřednictvím webového serveru předá klientskému pro-
hlížeči
6. klient – prohlížeč pak uživateli interpretuje data v patřičné grafické po-
době
Uvedený proces se v různých obměnách opakuje, dokud uživatel práci
s informačním systémem neukončí. Aplikační server musí přitom správně vy-
hodnotit fázi rozpracovanosti, v níž se uživatel systému nachází – jinými slovy,
odezvy informačního systému závisí na historii jeho komunikace s uživatelem.
Vzhledem k tomu, že používaný komunikační protokol HTTP je bezstavový a
nepodporuje udržování takového historického kontextu, plní tuto úlohu apli-
kační server.
DB Server
Data
SŘBD
síť
Klient PC
Uživatelské
rozhraní
(browser)
Aplikační
server
Aplikační
logika IS
DB rozhraní
Síťové
rozhraní
(HTTP)

Obr. 2.7 Schéma informačního systému ve vícevrstvé architektuře

13


Také se zde řeší problémy oprávnění – aplikační server musí v každé etapě
komunikačního procesu znát identitu uživatele a rozhodnout, zda je jeho poža-
davek legitimní. Rozhodování o oprávnění lze sice přesunout i na databázový
server (ve dvouvrstvé architektuře jinou možnost nemáme), aplikační vrstva
však obsahuje daleko bohatší nástroje, které jsou komfortnější i z hlediska uži-
vatele (dostává srozumitelné odpovědi, co nemůže udělat, a proč).
Programy implementující informační systém z hlediska jeho pravidel a logiky
jsou uloženy na aplikačním serveru a volají se podle potřeb uživatelů. Progra-
my se často vytvářejí v interpretačním prostředí (jazyky VBscript, JavaScript,
Perl apod.) kvůli rychlejšímu vývoji a snazšímu ladění. V tomto prostředí jsou
pak k dispozici vestavěné objekty, resp. knihovny, které zpřístupňují požadav-
ky klientů, rozhraní databázového systému, souborový systéme serveru aj.
V současnosti jsou velmi používané platformy PHP (provozované zejména
v operačních systémech typu unix), ASP nebo pokročilejší .NET (pro systémy
orientované na MS Windows).
Výše nastíněná komplexnost aplikační vrstvy vedla k jejímu dalšímu rozdělení
na vrstvy. Toto rozčlenění pomohlo definovat odpovědnosti jednotlivých vrs-
tev v rámci aplikační vrstvy. Vrstvy jsou nejčastěji formálně definovány jako
prezentační (presentation), aplikační (business) a datová (persistence). K ustá-
lení terminologie v této oblasti však prozatím nedošlo.
Pozorný čtenář si mohl všimnout, že třívrstvá technologie představuje určitou
formu návratu k vyšší centralizaci ve srovnání s architekturou klient–server.
Jedná se však spíše o novou kvalitu, neboť na rozdíl od ryze centralistického
pojetí nebývá aplikační server umístěn na stejném stroji jako databázový ser-
ver. Skutečností však zůstává, že v případě architektury klient–server obsahuje
klient také aplikační logiku informačního systému (tzv. tlustý klient), zatímco
ve třívrstvé architektuře je úlohou klienta takřka výhradně poskytovat pouze
komfortní uživatelské rozhraní (tenký klient). Z tohoto hlediska je také interne-
tový prohlížeč považován za tenkého klienta, což je celkem paradoxní vzhle-
dem k tomu, že je reprezentován velmi rozsáhlým programem.
2.2.4. Webové služby
Webové služby představují další zobecnění vícevrstvé architektury. Zatímco
v případě třívrstvé architektury je výstupní odpověď aplikačního serveru urče-
na zejména k zobrazení uživateli, v případě webové služby (web service) je
výstup upraven do univerzální obecné podoby tak, aby ho mohla využít jiná
aplikace k dalšímu zpracování.
Ilustrujme si uvedený mechanizmus na příkladu proslulé vyhledávací služby
Google. Ta poskytovala své služby původně pouze prostřednictvím webové
stránky – uživatel si načetl stránku s vyhledávacím formulářem, do něj zadal
svůj dotaz a stránku odeslal. Zpět dostal odpověď od Googlu, opět v podobě
webové stránky v jazyce HTML s lineárním seznamem odkazů na jiné stránky.
Pokud měl uživatel jinou představu o výsledku (např. znázornit jej graficky,
nebo jinak dále zpracovat, případně zkombinovat s jinými výsledky), musel si
to zařídit sám.

14
Informační technologie a systémová analýza
V případě webové služby může uživatel vytvořit jinou aplikaci, která si sama
vyžádá příslušná data od služby Google, zpracuje je podle svých potřeb, a s
výsledkem naloží podle představ uživatele – zobrazí ho například v grafické
podobě místo v podobě seznamu apod. Příklad se službou Google není zcela
náhodný – právě Google totiž zavedení webových služeb silně podporuje.
Z dalších významných subjektů, poskytujících své služby na Internetu, se
k podobnému kroku odhodlal také známý Amazon (původně orientován na
elektronické knihkupectví). I zde je umožněno, aby si jiné aplikace samy pro-
hledávaly jeho katalogy, vyhledávaly zde to, co potřebují a výsledky dále zpra-
covávaly podle svých představ a potřeb.
Základním znakem webové služby je zejména klient, který je nyní (na rozdíl
od internetového prohlížeče) původní samostatnou aplikací s vlastní inteligencí
a vlastní logikou zpracování dat. Server služby může být značně specializován,
proti aplikačnímu serveru je obvykle daleko jednodušší. Proto se také v souvis-
losti s webovými službami někdy hovoří o modelu klient–služba, místo o mo-
delu klient–server.
U webových služeb se dále významným způsobem mění charakter vztahu mezi
klientem (aplikací) a službou (serverem poskytujícím službu). Zatímco dříve
byly tyto dvě složky poměrně pevně svázány a jejich vazba měla statický cha-
rakter, v případě webových služeb je jejich vazba značně volnější a má spíše
příležitostný charakter – klient si teprve na základě určité momentální potřeby
vyhledá potřebnou službu pro spolupráci. K tomu jsou ovšem nutné nové stan-
dardy a protokoly.
Každá služba musí být standardizovaně popsána, co nabízí a jak se s ní dá ko-
munikovat, a tyto informace musí být známým způsobem veřejně dostupné.
Prostřednictvím takových veřejných katalogů pak budou moci konkrétní apli-
kace (klienti) vyhledávat konkrétní služby a také je využívat. Některé konkrét-
ní standardy jsou již k dispozici, další se připravují či dokončují nebo vylepšu-
jí. Jde např. o jazyk XML (pro strukturovanou formulaci požadavků a odpově-
dí na ně), SOAP (pro vzájemnou komunikaci), WSDL (pro popis webových
služeb), UDDI (pro realizaci katalogů webových služeb) a další.
Velké rozšíření webových služeb se teprve očekává, komplexní informační
systémy dosud používají zejména dnes již klasickou třívrstvou technologii.
3. Databázové systémy
V předchozí kapitole jsme se pokusili ozřejmit vývoj způsobu zpracování hro-
madných dat. Na základě obrázků 2.1 a 2.4 můžeme vyvodit platnost následu-
jícího zápisu:

Systém řízení báze dat (SŘBD) + Databáze (DB) = Databázový systém (DBS)

Uvedené termíny představují základní pojmy, proto si je vysvětleme:


15

• Systém řízení báze dat (SŘBD),
v anglické terminologii často užívaná zkratka DBMS (Data Base Manage-
ment System), je program nebo soubor programů, který data organizuje:
umožňuje je definovat, ukládat, měnit, mazat. SŘBD dodávají výrobci pro-
gramového vybavení podobně jako operační systémy, textové editory nebo
programy pro kreslení. Nejznámějšími produkty jsou např. dBase, MS Ac-
cess, Oracle, Informix, Progress, MS SQL Server, Sybase a další.
• Databáze (databázová aplikace)
Databáze je strukturovaná množina dat ve formě databázového souboru, te-
dy konkrétní data. Důležité je zde zejména slovo strukturovaná, protože da-
tabáze může být prázdná, tedy nenaplněná daty, a přesto můžeme říci, že
existuje, pokud byl definován popis tvaru a struktury jejích dat. K těmto da-
tům potom přistupují jednotliví uživatelé různé úrovně prostřednictvím
aplikací, které jim umožňují zadávat data a dotazy pomocí uživatelsky pří-
jemného rozhraní jako jsou formuláře nebo dialogová okna pro zadávání dat
nebo tiskové sestavy pro zobrazení a tisk výsledků dotazů.
• Databázový systém (DBS)
DBS je pojem, který spojuje vlastní údaje ukládané v databázi s nástroji
(programy) umožňujícími jejich správu.
3.1. Charakteristika databázového systému
Z analýzy vývoje DB technologie lze formulovat základní charakteristiky
a kritéria, která musí databázový systém splňovat. Jsou to zejména následující
požadavky:
• Struktury aplikačních programů a vlastních datových souborů musí být od-
dělené.
Tím je dosaženo vzájemné nezávislosti programů na datech a naopak. Pak je
vytvořen předpoklad, aby bylo možné (s většími či menšími úpravami)
spravovat data různými SŘBD.
• K datům je možno přistupovat pouze prostřednictvím DB systému, nikoli
přímo.
DB systém sám řídí přístup uživatelů k datům, tím je zajištěna ochrana dat.
Na základě oprávnění přidělovaných uživatelům musí zabránit zneužití dat,
ať už úmyslnému či neúmyslnému. Rovněž musí zajistit, že vkládaná data
budou pravdivá, tedy odpovídající skutečnosti (v tom smyslu, že jsou prav-
děpodobná).
• Dotazy lze tvořit i v průběhu práce se systémem, nemusí být formulovány
předem.
Při vývoji systému budou jistě pro běžné použití sestaveny často kladené
dotazy. Dotazy podle specifických požadavků je však možno formulovat
i kdykoli později při rutinním provozu systému.
• Je umožněn současný přístup k datům více uživatelům.
Moderní DB systém musí být víceuživatelský.

16
Informační technologie a systémová analýza
3.2. Úrovně pohledu na data
Předností databázového systému je to, že poskytuje uživateli abstraktní pohled
na data bez znalosti implementačních podrobností, to znamená bez znalosti
toho, jak se skutečně realizuje fyzické ukládání, vyhledávání a aktualizace dat
uložených v souborech. Při pohledu na data můžeme mluvit o třech vrstvách,
které jsou do určité míry nezávislé, což umožňuje provádět změny v těchto
vrstvách, aniž by tím byly ovlivněny vrstvy ostatní.
Fyzická úroveň
nejnižší vrstva, na které je popsáno, jak jsou konkrétně data uložena. Na této
úrovni pracuje s daty programátor – tvůrce SŘBD.
Konceptuální úroveň
popisuje logickou strukturu dat, která jsou v databázi obsažena. Na této úrovni
abstrakce pracuje správce databáze, který popisuje strukturu dat a jejich vzá-
jemné vazby, případně aplikační programátor, který vytváří aplikační programy
s použitím prostředků jazyka DML. Popisu databáze na této úrovni říkáme
schéma databáze.
Uživatelská úroveň
popisuje pro daného uživatele jen část databáze, s kterou je oprávněn pracovat.
Popisu struktury databáze pro jednotlivé uživatele říkáme subschéma nebo též
pohled a může jich být tolik, kolik je různých uživatelů. Uživatel na této úrovni
může pracovat se systémem pouze prostřednictvím aplikačního programu (na-
ivní uživatel) nebo může být schopen formulovat dotazy v databázovém jazyce
(znalý uživatel).
3.3. Úkoly SŘBD
SŘBD musí mít prostředky pro popis dat, k jejich definici a vytvoření vlastní
databáze. Rovněž je třeba nějakého mechanismu, který spravuje data na disku
a ví, kde je uložen konkrétní prvek. Tyto prostředky pro definici dat bývají
označovány jako jazyk typu DDL (Data Definition Language) a slouží jako
nástroj pro vytvoření a definici databáze.
Dále musí být k dispozici prostředky, které dovolí přistupovat k již existujícím
databázím, vybírat z nich data, třídit je, filtrovat a měnit. Tyto prostředky pro
manipulaci s daty bývají označovány jako jazyk typu DML (Data Manipulati-
on Language). Specifická část manipulace s daty – výběr dat, je realizována
pomocí dotazovacího jazyka (viz. kapitoly 6.5 a 7).
SŘBD by měl poskytovat také možnost zobrazovat data na obrazovce nebo na
tiskárně ve formě tiskové sestavy. Moderní SŘBD, tyto služby poskytují.
O systému řízení báze dat, který poskytuje pouze základní služby jako je defi-
nice, údržba a manipulace s daty, mluvíme jako o databázovém stroji. Zobra-
zování a tisk dat pak je třeba zajistit aplikačním programem.
Když chceme s databázovým systémem pracovat, předpokládáme, že je možné
se spoléhat na to, že data jsou správná, to znamená, že data odpovídají vlast-
nostem příslušného popisovaného objektu reálného světa. Této vlastnosti se
říká integrita. Např. fakt, že únor má 28 dní, je třeba popsat takovými integrit-
ními podmínkami, které postihnou to, že datum 30. února je vždy porušením

17

integrity, zatímco datum 29. února jen někdy (není-li přestupný rok). Systém
musí zajistit, že integrita nebude porušena ani v případě havárie (např. výpadek
proudu) ani zásahem jiného uživatele nebo aplikace, ať již úmyslným nebo
neúmyslným. Zajišťuje se jak na úrovni SŘBD, tak i zadáním určitých kritérií
na úrovni definice dat, popřípadě na úrovni aplikační.
U rozsáhlých databázových aplikací se často stává, že některé informace jsou
v systému obsaženy vícenásobně. Tato vlastnost se nazývá redundance.
Správným návrhem databáze je třeba redundanci minimalizovat, neboť spotře-
bovává prostor na pevných pamětech a je zdrojem nekonzistencí. Nicméně
pokud se vícenásobná data vyskytnou, SŘBD musí zajistit jejich konzistenci,
to znamená, že data za všech okolností musí mít ve všech svých výskytech
stejnou hodnotu. Problémy s konzistencí nastávají např. v době aktualizace,
kdy oprava již započala, ale dosud nebyla dokončena. V této době jsou data
jako celek nekonzistentní. Proto se takovéto operace provádějí po malých lo-
gicky uzavřených částech, tzv. transakcích, které je možno zopakovat, pokud
nebyly provedeny správně. Transakce je tedy množina příkazů, které převádějí
databázi z jednoho konzistentního stavu do jiného konzistentního stavu. Pro-
středky pro popis ochrany přístupu k datům se někdy označují jako jazyk
typu DCL (Data Control Language). Řízení transakcí, jež poskytuje většina
dnešních SŘBD, je zabezpečováno řídícími příkazy označovanými jako TCC
(Transaction Control Commands).
Jestliže jsme výše označili prostředky pro zabezpečení úkolů SŘBD jako jazy-
ky DDL, DML a DCL, neznamená to, že se jedná o nějak oddělené‚ samostat-
né jazyky, ale měli bychom je chápat u procedurálních jazyků jako množinu
procedur zabezpečujících určité služby (definici dat, manipulaci s nimi, řízení a
ochranu dat). V současnosti jsou tyto prostředky většinou integrovány do jed-
noho celku, takže moderní SŘBD poskytuje dostatečně silný databázový jazyk,
který splňuje potřeby jak laických nebo příležitostných uživatelů, tak i správců
dat, případně aplikačních programátorů.

Shrneme-li tedy úkoly SŘBD, musí poskytovat následující služby:
• Definice dat
• Údržba dat
• Manipulace s daty
• Zobrazení dat
• Zajištění integrity dat

3.4. Databázové aplikace
Databázová aplikace zajišťuje komunikaci uživatele s databázovým systémem.
Umožňuje mu s daty pracovat, to znamená zadávat je, měnit, rušit, různě se-
skupovat a vytvářet z nich výpisy. Tyto aplikace mohou být vytvořeny
v univerzálním nebo specializovaném programovacím jazyce. Dnešní SŘBD,
zvláště systémy na PC, poskytují uživatelsky orientované nástroje pro přístup
k databázi a snižují nutnost tradičního programování.

18
Informační technologie a systémová analýza
Jazyky používané pro tvorbu aplikací můžeme rozdělit do následujících sku-
pin:
• Obecné procedurální jazyky jako je Pascal, Cobol, Basic, C. Procedurální
znamená, že aplikace je zapsána ve formě procedur, to znamená algoritmů,
které určují, jakým způsobem požadovaná data získat, změnit, atd. Tyto ja-
zyky běžně používané pro tvorbu nedatatabázových aplikací, musí být rozší-
řeny o prostředky pro přístup k datům. Těmito prostředky jsou množiny
funkcí, které bývají shromážděny do tzv. knihoven, které se dodávají spolu
se SŘBD. Těmto univerzálním jazykům se říká jazyky 3. generace (3GL)
• Pro některé SŘBD byly vyvinuty specifické procedurální jazyky, které na
rozdíl od univerzálních jazyků mohou být použity pouze v tomto systému,
případně v podobných produktech, pokud se stanou dostatečným standar-
dem, jako např. jazyk dBASE. Aby se odlišily od univerzálních jazyků, bý-
vají označovány jako jazyky 4. generace (4GL).
• Dotazovací jazyky jsou prostředky umožňující formulovat požadavky uži-
vatelů na výběr potřebných informací z databáze. Většinou se jedná
o neprocedurální jazyky, to znamená, že příkazem se popisuje, co se má
provést, jaká data potřebujeme, ale neurčuje se, jak se to má provést. Již
v 70. letech byl firmou IBM vyvinut dotazovací jazyk SQL (Structured
Query Language), určený pro komunikaci se SŘBD relačního typu. Vzhle-
dem k tomu, že neposkytuje prostředky pro manipulaci s obrazovkou a pro
uživatelský vstup a výstup, je spíš jakýmsi podjazykem. Jeho prostřednic-
tvím lze interaktivně formulovat dota