Základy DBS

rsonální náklady na obsluhu a údržbu
databázového serveru. V malé síti (zhruba pod 20 uživatelů) může správce sítě obvykle
udržovat databázový server i uživatelský přístup k němu a poskytovat podporu aplikacím
front-end. Jakmile však roste počet uživatelů nebo rozsah databáze samé, může být potřebný
databázový administrátor, který převezme péči o provoz SŘBD a podporu systémů front-end.
K počátečním nákladům někdy přibude též školení, protože SŘBD může pracovat pod
operačním systémem, se kterým obsluhující personál není dosud obeznámen.
Rovněž náklady na hardware jsou vyšší. Ačkoli mnoho databází C/S pracuje pod
běžným operačním systémem a většina dodavatelů tvrdí, že SŘBD může pracovat na témže
stroji společně se softwarem pro server souborů, pro zajištění výkonnosti a integrity dat by
databázový server měl pracovat na vlastním vyhrazeném počítači. To obvykle znamená nákup
velmi výkonného systému s velkou operační pamětí a diskovým prostorem a další podpůrná
zařízení jako např. napájecí zdroj (UPS) chránící server před výpadkem elektrické sítě.
Výhoda aplikační nezávislosti systémů C/S má i svou stinnou stránku. Více počítačů
front-end s přístupem k databázi zvyšuje požadavky na programátory, protože je třeba vyvíjet
a udržovat více různých programů. Změna ve struktuře databáze se rovněž šíří jako vlna k
systémům front-end. Provedení potřebných změn v příslušných aplikacích je delší a složitější
proces a je obtížné provést vše synchronizovaně bez vážného přerušení dostupnosti databáze
pro uživatele.
10

Největší nevýhodou dosud popsaných databázových systémů je to, že vyžadují, aby
data byla uložena na jediném počítači. To může způsobovat problémy velkým společnostem,
u nichž může vyvstat potřeba podporovat databázové uživatele rozptýlené po rozsáhlém
území nebo které potřebují, aby části jejich databází na úrovni oddělení byly sdíleny s jinými
odděleními nebo s centrálním hostitelským počítačem. Je nutný nějaký způsob rozdělení dat
mezi různými počítači nebo lokalitami, což vede k vývoji systémů distribuovaného
zpracování.
d) Systémy distribuovaného zpracování
Jednoduchá forma distribuovaného zpracování existuje již několik let. V této omezené
formě se sdílejí data mezi různými hostitelskými systémy tak, že se mezi nimi posílají změny
(updates) přímým spojením (v téže síti) nebo dálkově po telefonních nebo vyhrazených
datových linkách. Aplikace, která běží na jednom nebo několika hostitelských počítačích
vybírá části dat změněné v průběhu programátorem definovaného časového intervalu a posílá
tato data centrálnímu počítači nebo jiným hostitelským počítačům v počítačové síti. Ostatní
databáze se tedy aktualizují, aby všechny systémy byly synchronizovány. Tento typ
distribuovaného zpracování se používá obvykle mezi počítači jednotlivých oddělení nebo
mezi lokální sítí a hostitelským systémem - data se posílají do velkého centrálního
minipočítače nebo střediskového počítače po skončení pracovní doby.
Třebaže je tento systém ideální pro sdílení části dat mezi různými hostitelskými
počítači, neřeší případy, kdy uživatel požaduje přístup k datům, která na jeho lokálním
hostitelském počítači nejsou. Pro přístup k různým databázím se uživatel musí připojovat k
různým počítačům, a musí si pamatovat, kde je která databáze. Je zde rovněž problém
duplicitních dat - udržování jejich synchronizace systém dále komplikuje.
Řešení těchto problémů se vynořuje v technice transparentního přístupu k datům,
zvané distribuované zpracování. V systému distribuovaného zpracování požádá uživatel o
data lokální hostitelský počítač. Zjistí-li tento počítač, že data nemá, pošle požadavek po síti
počítači, kde data jsou. Ten potom pošle data zpět uživateli, aniž by se ten dověděl, že data
pocházejí z jiného systému (až na případné menší zpoždění). Obr. 4. znázorňuje jednu formu
systému distribuovaného zpracování. Nejdříve uživatel vytvoří požadavek a vyšle jej
lokálnímu databázovému serveru. Ten vyšle požadavek na data, která sám nemá, po síti na
střediskový počítač - v případě potřeby přes bránu (gateway) nebo most (bridge) spojující
vzájemně dvě sítě. Dostane zpět odpověď na dotaz, zkombinuje ji s daty nalezenými na
vlastních discích a vše pošle zpět uživateli.
Distribuovaný systém může pracovat i takovým způsobem, že uživatelé u terminálů
připojených přímo ke střediskovému počítači mohou přistupovat k datům uloženým na
vzdálených databázových serverech.

11
Obr.4: Systém distribuovaného zpracování
Výhody a nevýhody:
• Lokální transparence, což znamená, že uživatel, resp. Aplikační program , nepotřebuje znát
kde jsou data uložena. Celý systém je pro uživatele "průhledný", tj. vidí až svoje data a ne
cestu k nim, a vlastně si ani neuvědomí, že pracuje s distribuovanou databází. Systém sám
automaticky zajistí dodání dat do místa, kde je uživatel.
• Zvýšená spolehlivost, protože když se zhroutí centrální databáze, pak je nedostupná pro
všechny uživatele. V distribuovaném systému při zhroucení některé z databází dojde pouze k
redukci funkcí (nemohou být provozovány aplikace, které vyžadují data právě z této
zhroucené databáze), ostatní aplikace však mohou být provozovány beze změny.
Střediskový počítač
Síťové médium - kabel
PC
Databázový server
Vzdálený dotaz a odpověď
ze střediskového počítače
Brána (most)
Místní terminál
Dotaz
Odpověď
Server souborů
12
• Vyšší odpovědnost za data, která vyplývá z toho, že data jsou distribuována tak, že jsou
uložena vždy v místech, kde se nachází osoba (popř. útvar) za tato data odpovědná. Příslušný
uživatel má v tomto případě pocit, že má u sebe "svoje" data a dbá více o jejich správnost a
integritu. Rovněž hardware může být lépe místně přizpůsobován konkrétnímu charakteru i
rozsahu lokálních dat než bychom mohli zabezpečit globálním centrálním systémem (např.
grafická karta, apod.).
• Modulární růst systému je snazší, protože když se např. organizace rozšíří o novou lokalitu,
čí o novou aplikační oblast, a tudíž vznikne potřeba rozšířit databázi, máme možnost
implementovat si lokální databázi a připravit si všechna potřebná data včetně prototypového
prověření funkcí, aniž bychom tím zatěžovali celý systém. Pak se provede pouze připojení
lokálního systému do sítě.
• Menší náklady na komunikace než v centrálním systému, protože předpokládáme, že data
jsou distribuována tak, že většina transakcí se provádí s lokálními daty a jen menší část
aplikací vyžaduje data z jiných lokalit, Tím se snižuje zátěž komunikačního subsystému.
• Rychlejší odezva, což souvisí s předchozí vlastností. Samozřejmě je tato vlastnost
podmíněna optimální distribucí dat právě z hlediska rozmístění a frekvence požadavků na
data. Obecně předpokládáme, že většina aplikací je uspokojována z lokálních zdrojů, a tudíž
rychleji.
• Dražší a složitější software, protože vedle lokálních SŘBD je zapotřebí i poměrně drahý
globální SŘBD (viz dále).
• Vyšší provozní náklady, protože mezi jednotlivými místy je třeba vyměňovat řadu řídících
informací a provádět řadu doplňujících výpočtů zajišťujících vzájemnou koordinaci činností.
• Obtížnější kontrola datové integrity v důsledku vícestupňovosti SŘBD.
• Nebezpečí pomalé odezvy, pokud jsou data nevhodně distribuována.

SŘBD systémů distribuovaného zpracování
V distribuovaných databázích kromě lokálních SŘBD je třeba implementovat i
globální SŘBD, který musí zabezpečit zejména tyto funkce:
1. Určit místo, kde se nacházejí požadovaná data.
2. V případě potřeby, převést data ze syntaxe lokálního SŘBD jednoho místa do
syntaxe SŘBD druhého místa.
3. Zajišťovat referenční integritu a řídit souběžné přístupy k datům.
4. Zajišťovat ochranu dat před neautorizovaným přístupem.

V systému distribuovaného zpracování je v každém místě umístěna jednak kopie
globálního systému řízení označená jako DSŘBD (distribuovaný systém řízení báze dat),
jednak vlastní lokální systém řízení báze dat (označený jako LSŘBD). Kromě toho si musí
13
DSŘBD udržovat v každém místě svůj katalog obsahující údaje o všech datech v databázi a
jejich místech uložení (označuje se jako DCAT).
DSŘBD má navíc v každém místě ještě složku zvanou transakční manažer, který má
zejména tyto funkce:
Udržovat záznamy o transakcích a stavech DB před transakci či po ní pro potřeby
obnovy DB po poruchách.
Udržovat vlastní schéma řízení souběžnosti přístupů k datům (concurrency control)
pro zabezpečení integrity a konsistence DB.
Při globální transakci zabezpečuje transakční manažer na každé ze zúčastněných stran
synchronizaci všech operací, jinak je nebezpečí ztráty integrity a výskyt chyb. K tomu
používá především protokol ke sledování toho, zda globální transakce byla úspěšně ukončena
nebo naopak přerušena. Každé místo si zpracuje svůj díl transakce, ale neuloží okamžitě
výsledek do lokální databáze. Čeká se, až všechna místa provedou své transakce a potvrdí
jejich bezchybný průběh.