ARCHITEKTURY SRBD. Centralizované platformy. Po absolvování přednášky Architektury SŘBD budeme umět

Arch itekturySRi3D

v

ARCHITEKTURY SRBD Po absolvování přednášky Architektury SŘBD budeme umět • • • •

vyjmcnovatjednodivé typy architektury SŘBD vysvětlit, v čem spočívá základní rozdíl mezi archi tekturam i stručně charakterizova t j ednotlivé typy z hlediska zpracování dat vysvětlit základní výhody a nevýhody jednotlivých typll architektur.

Centralizované platformy Zásadní rozdíl mezi jednotl ivými architekmrami SŘBD je určen místem, kde probíhá vlastní zpracování dat. Typ architektury zpravidla přímo ncpopisujc, na jakých počítačích (PC, ..., mainframe) bude databáze provozována. V centralizovaných systémech budeme rozlišovat dva základní prvky: • hostitelský počítač • tenninály. Na hostitelském počítači se zpracovávají všechny programy - SŘ BD, apli kace, uživa telské roz hraní a komunikační software přenášející informace na uživa telské term inály a z nich . Uživatelé přismpují k databázi z terminá lů. Terminály zpravidla nemají žádné, nebo jen omezené mož nosti l okálního zpr acování. V nejjednodušších plípadech se skládají pouze z monitoru, klávesnice a hardware pro komunikaci s hostitelským počítačem. Inteligentní terminály mohou přejímat část zodpovědnosti za manipulaci s obsahem obrazovky a zpracování vstupních dat uživatele.

Stfedlskovy poěltaě

ArchitekturySRBD

2

V centralizovaném systému probíhá veškeré zpracování na hostitelském počítači . Na hostitelském počítači musí být spuštěn SŘBD. Uživatel po zapnutí tcm1inálu musí zadat své pfiblašovací jméno a heslo a tím získá přístup k aplikacím na hostitelském počítači. Po spuštění databázové aplikace jsou obsahy jednotlivých obrazovek vysílány z hostitelského počítače na terminál. Aplikace i SŘBD j sou spuštěny na hostitelském počítači a komunikují spolu navzájem v

operační paměti hostitelského počítače:

k tennmólum

.

k dlskovym

pamtt6m

:

OBA

ktonmnalum

Pamtf počltOOo

SŘBD odpoví dá za přenos dat na disk a z disku s využitím služeb operačního systému. SŘBD může být založen na libovolném databázovém modelu - nejčastěj i ale na síťovém nebo relačním. Výhody centralizovaných systémů: • centrá lní zabezpečení • uložení velkého množství dat • možnost současné práce mnoha uživa tclí1 (i více než I 000) Nevý hod y central izovaných systém ů: • vysoké náklady na pořízení a údržbu systémů o nutnost specializovanýc h technických zařízení (klim atizace, ...) o tým kvalifikovaných systémových administrátOiů

I. Kde probíhá zpracování databázové aplikace v centralizovaném systému?

Systémy na osobních počítačích

Běží-li SŘBD na PC, pracuj e PC současně j ako hostitelský počítač i terminál -veškeré zpracová n í probíh á na

PC. V nejjednodušších případech bývají SŘBD a databázová aplikace spojeny do je dnoho programu . Databázová aplikace často zpracovává vstup od uživatele , výstup na obrazovku i

ArchitekturySRBD

pfístup k datům na disk. Toto řešení má několik výhod : • flexibilita aplikace • rychlost aplikace ale i n evýh od: • nízká bezpečnost a integrita dat • malé objemy zpracovávaných informací. Většina SŘBD na PC je založena na relačním modelu , ale často v ních není implementována část relačních principů. Velmi často tyto systémy ncmají integrovány mechanismy integrity dat. Jednodušší systémy často umožňují i přímý přísn1pk datiun (bez použití příslušného SŘBD). Tak mohou být v datech prováděny různé změny narušující integritu dat, kterou jinak kontroluje SŘBD. PC bývají velmi často propojen y do lokálních sítí (LAN). V lokální síti jsou data uložena na serveru souborů. Server zajišťuje uživatelům LAN sdílený přístup k datům na svých pevných discích. LAN umožňuje uživatelům databáze na PC sdílet společné datové soubory , ale nemění princip zpracová ní- veškeré zpracování dat probíhá na PC, na němž je spuštěna databázová aplikace. Souborový server pouze vyhledává požadované soubory na discích a po síťovém médiu je posílá na PC. Data zpracovává SŘBD na PC. Každá změna v databázi vyžaduje, aby PC poslalo celý soubor s daty na server, který jej uloží na disk:

Nevý hody víceuživa tel ského pfístupu v systémech na PC: • výkonnost systému není závislá na výkonnosti serveru, ale na výkonu koncového PC • zpomalení práce sítě- pokud pracuje s databází více uživatelů, musí server poslat tytéž soubory na každé PC, které je používá • nutnost řešit současný pfístup více uživatelů k databázi. Pokud chce více uživatelů

současně provádět změny dat,je nutné měněný soubor uzamknout, aby k němu měl pfístup pouze j eden z nich (více podrobností o této problematice se dozvíme v

3

ArchitekturySRBD

4

kapitole věnované paralelnímu zpracování dat).

1 2. Jaké jsou

výhody SŘBD 11a PC?

Databázové systémy klient/server Databáze klient/server rozděluje zpracován í mezi dva systém y: • klient (např. PC) na nčmž bčží databázová apl ikace. • databázový server na nčmž běží SŘBD, Databázový server může běžet na témže

stroji jako server souborů nebo na vlastním stroji. K l ientský stroj (PC) je označován j ako systém front-end a zajišťuje zpracován í obrazovek a uživa telských vstupů a výstupí'1. Systém ba ck-end na databázovém servem zajišťuje zpracování dat a přístup na disk. P1incip fungování systému : • uživatel na počítači front-end vytvoří požadavek (dotaz) na data z databázového serveru, aplikace front-end vyšle požadavek po síti na server • databázový server provede vlastní vyhledán í dat a pošle zpět pouze data, která odpovídají uži vatelovu dotazu

PC

Po síti tedy neputují celé datové soubory , ale pouze dotazy (nejčastěji SQL příkazy- o velikosti řádově desítek bytů) a odpovědi na tyto dotazy (nejčastěji jeden nebo několik datových záznamů z databáze). Kl ientské systémy obvykle běží na PC,j ako databázový server může být použito PC i počítače vyšší kategor ie. V současní době mají obrovský pfínos webové služby (web se1vice), které se dají využít

-

ArchitekturySRBD

téměř při jakékoli úrovni distribuce aplikace mezi klienta a sc1vcr. Webová služba zpravidla obaluje datový zdroj a komunikuje s uživatelem. Tento koncept je výhodný z hlediska zabezpečení. Mezi největší výhody architektury klient/server patří: • rozdělení práce mezi klienta (aplikaci) a databázový server • redukce množství dat posílaných po síti • udržení integrity dat. Nevýhodou systémů klient/server je skutečnost, že ve své základní variantě • nepodporuje rozdělení dat mezi několik lokalit, tzn . data musí být uložena na jediném databázovém sc1vcru.

3. Jaf.ý. je rozdíl mezi objemem údaj1i posílaných po síti mezi architekturou databázi na PC (v síti) LAN a architekturou klient/server?

Systémy distribuovaného zpracování Systémy distribuovaného zpracování umožňují transparentní přístup k datům. V takovémto systému požádá uživatel o data svůj lokální databázový server. Pokud server nemá požadovaná data k dispozici, pošle po síti požadavek počítači , na němž jsou tato data uložena. Tento počítač (server) pošle data zpět uživateli , aniž by se uživatel dozvěděl , že data pocházejí z jin ého než jeho lokálního Serveru. Mezi hlavní výhody patří dostupnost (např. pobočky pojišťovny) , výpadky většinou neohrozi korektní přístupnost na další uzly (transparentnost). Využívají se převážně v bankovn ictví či ve zdravotn i ctví. V případě bankovnictví jsou tak účty klientů spravovány lokálně, ale jsou přístupné z jin ých poboček. Distribuovaná databáze je tedy jediná logická databáze, která je fyzicky rozmístěna na více počítačích spojených komunikační sítí. Distribuované databázové systémy tedy kombinují dvě technologie- databáze a komunikace. Distribuované databázové systémy je možné posuzovat ze tří základních pohledů: • autonomie . Autonomie je týká distribuce řízeni. o Může se jednat o těsné spojení, kdy je distribuovaná databáze vytvořena nad lokálními databázemi a každé místo má úplnou znalost o všech datech v celé distribuované databázi. o Při volnější autonomii jsou sdílena pouze určitá data z lokálních databází. o V případě úplné izolace jsou jednotlivé lokální databáze autonomní a navzájem o sobě neví. Distribuovaná databáze pak tvoří speciální vrstvu nad lokálními systémy. • transparence distribuce- určuje, do jaké míry je distribuce dat v jednotlivých místech viditelná uživatelů . • heterogennost. Může se jednat o 1ůznorodý hardware v různých místech , o různé typy lokálních SŘBD nebo dokonce i různé databázové modely.

5

-

ArchitekturySRBD

6

Různé systém y mohou využíva t různé drul1y distribuce: • replikace - na všech místech jsou uložena stejná data- kopie jedné a téže databáze

• objektové (horizontální) členění- na jednotlivých místech jsou uloženy informace o různých objektech, ale se stejnou strukturou

1--

·

f--J

-

t

t

---·

.t-+-

-

·-·

• funkční(vertikál ní) členění)- na jednotliv ých místech jsou uloženy informace s různou strukturou

Arch itekturySRi3D

7

t

!······

+•·· ··< . ....

.....

•····

'-t- --

t

. --+ ------- i- -

4. Pokuste se definovat pojem distribuovaná databáze.

Databázové aplikační programovací jazyky Aby mčl SŘBD praktický význam,musí uživatelů umožni t přístup k datům. Možnosti, které SŘBD poskytuje pomocí vlastních prostředků, zpravidla nejsou příliš komfortní a proto uživatel využívá databázovou aplikaci. Databázová apl ikace je program umožňující komunikaci uživatele s daty (zadáváni,změny, rušení a vyhl edávání uložen ých údajů). Aplikace sestavují programá toři v univerzálních nebo specializovaných programovacích jazycích. Pro tvorbu databázových aplikací je možné využívat • objektově orientované jazyky • SQL • ostatní jazyky. Běžné hybridní jazyky (jako Del phi , C++) mohou být využity pro tvorbu databázových apl ikací prostředn ictvím API {Application Programm ing Intcrfacc- aplikační programové rozhraní). API se skládá z množiny funkcí rozšiřujících jazyk o prostředky přístupu k datům s využitím SŘBD. Vyšším programovacím jazyki'lm , které mohou být použity pro tvorbu programu (a tedy i databázové aplikace) se říká 3GL (jazyky 3.generace). Něktcré programovací jazyky jsou specifické pro určitý SŘBD. Takovýmto jazykům se obvykle říká 4GL (jazyky 4.generace). Pomocí objektově-orientovaných jazykl'• (C#, Java , ...)se program nepíše jako řada procedur , ale definují se objekty a akce nad těm ito objekty . SQL (Structured Query Language - strukturovaný dotazovací jazyk) je neprocedurální jazyk , který nepopisuje, j ak je třeba operace provést, ale co je od databáze požadováno. Pomocí jazyka SQL je možné definovat data a manipulovat s nimi. SQL neobsahujc žádné

-

Architektury SRi3D

prostředky pro manipulaci s obrazovkami a pro uživatelský vstup a výstup. SQL má trojí využití - SQL jako dotazovací (manipulační) jazyk pro relační databáze -SQL jako složka hostitelského jazyka pro programován í databázových aplikací - SQL jako jazyk komunikace mezi různými zdroji dat. Mezi ostatn í jazyky patří například jazyky maker. Makrojazyky umožňují nahradit posloupnost kláves, kterou by uži vate l musel stisknout, kratší pos loupností- makrem. Tímto způsobem je možné zautomatizovat některé jednoduché operace. Makra se používají spíše u jednodušších SŘBD. Dalším představ itelem této skupiny je QBE (Query-By-Example). QBEje uživatelské rozhraní , které umožňuje uživateli snadno vytvářet dotazy , aniž by znal syntaxi příkazů SQL. Zpravidla je jej možné využít i k tvorbě jednoduchých výstupních sestav. Pii tvorbě aplikací je velmi vhodné využívat jmennou konvenci DB schémat: • Názvy tabulek v jednotném čísle, malými písmeny , bez diakritiky • Názvy atributů malým i písmeny , oddělovat podtržítkem • Sloupec reprezentující jed noznačný identifikátor (umělý PK) by se měl patřičně jmenovat- název tabulky + _id (employce_id) • Cizí klíč by se měl jmenovat stejně jako primární , včetně postfixu id-pokud to dává smysl. Pokud je třeba vyjádřit skutečnost, že se jedná o zodpovědného zaměstnance projektu , určitě by nemělo zmizet minimálně _id (responsible_employee_id) • Názvy uložených procedur, pohledů ... s odpovídajícím prefixem (sp_inscrt_ employec, vw_empl oycc_programmers)

5. K jakému účelu se pou ž ívají databázové aplikační ja zyky ?

Doporučená literatura: Salemi J. -Databáze klient/server , str. 17- 29 Pokorný J. - Databázová abeceda - str. 61 - 64; 149 - 152; 169 - 174; Connoly T. - Databasc Systems, str.383 - 526 Date C.J.- An Introduction to Database systems, str.42-43 ; 593-622

Řešení úkoll• : I.V centralizovaném systému je databázová aplikace (stejně j ako SŘBD a uživatelské rozhran í) spuštěna na hostitelském počítači.

2. Uži vatelské rozhraní , databázová apl ikace i SŘBD běží na PC. Mezi výhody tohoto řešení

patií flexibili ta a rychlost aplikace. Tyto výhody ale platí pouze pro malé aplikace.

8

-

ArchitekturySRi3D

3. V případč architektmy databází na PC se po síti posílají celé databázové soubory. V architektuře klient/server se po síti posílají dotazy a odpovědi na ně (tzn. vybrané údaje z databáze). Objem zasílaných informací je u architektmy klient/server mnohonásobně menší.

4. Distribuovaná databáze je jediná logická databáze, která je fyzicky rozmístěna na více počítačích. Uži vatel, který plistupuje k disnibuované databázi nemusí vědět, na kterém z propojených počítačů j sou data uložena. vyhledáni dat zajistí distribuovaný databázový systém.

S. Databázové aplikační se používají pro tvorbu uživatelského rozhraní.

9

-

Benchmarking

BENCHMARKING Po prostudování přednášky Benchmark ing budeme umět:

• • • •

popsat princ ip měření výkonu databázových systémů vysvětlit funkci společnosti TPC vyjmenovat základní TPC testy a vybrané z nich stručně charakterizovat najít na Internetu aktuální výsledky testování výkonu databázových systémů.

Měření výkonu DBS Měření výkonu databázových systémů se provádí prostřednictvím soustavy standard i:lOvaných testů. Tyto testy slouží k vytvoření měřítek pro objektivní porovnávání různých systému provozovaných na n1zných platformách. Výsledkem testování jsou konk rétní informace , které představují reá lné možnosti systému. Standardizovaným testováním databázových systémů se zabývá TPC ( Tnmsaction pro cessing

Performance Council). Pod zkratkou TPC se skrývá společnost pro měření výkonu transakčního zpracování. Toto společenství bylo založeno v roce 1988 osmi velkými sofiwarovými a hardwarovým i firmami a dnesje tvořen více než 30 členy ze severn í Ameriky, Asie. Austrálie a Evropy . Členy TPCjsou:

loataReturn ldebis Systemhaus IDell Compute rs

IEiectronic Data Systems

lltnformix

lloracle

IEMC Corporation

lltntel

IIProgress Software sec

IFujitsu IHarris Teeter IHewlett-Packard

UITOM lnternational UMicrosoft IIMorgan Stanley

IIFujitsu/Sieme ns USGI IFI-:s=u=n 7M""'ic= =os=y=s""te=m=s==

UHitachi UtBM

UNCR UNEC

llsybase IT Io !!s :'h :":iba =====

UIDEAS lnternational

IINetwork Appliance

UUnisys

Úko lem výboru je vydávat přesné specifikace standard tl pro jednot livé testy ,jím navržené testy tvoří všeobecně uznávaný standard v oblasti měření výkonu databázových systému.

Testy TPC TPC za dobu své existence vyv inula řadu testů na měření výkonu databázových systému. TCP- A, TCP- B Prvními testy byly TCP A a TCP B. Tyto testy by ly používány v letech 1989 až 1995. Jejich úkolem by lo simu lovat práci banky. Datové prostřed í tvořily čtyři tabulky. Transakce, které v tomto prostředí probíhaly příliš neodpovída ly reálnému prostředí. Výkon systému mčři v transakcích za sekundu (TPS - Transact ion Per Second). TCP - C Test TPC C je real ističtějš í než TPC-A a TPC-B.Datové prostředí je tvořeno devíti navzájem propojenými tabulkami a test simuluje práci u term inálu (včetně prod lev). Test je založen na OLTP (5 základních transakcí).

Benchmarking

2

Výstupem testu je hodnota vyjádřená poměrem cena/výkon. TPC definovala a používá řadu dalších testů: • • • •

TPC D TPC H TPC R TPCW

Benchmarks S výsledky testování je možné seznámit se na adrese http://www .tpc .org. K I0. 1 1 .2003 byly ak tuální výsledky : Pořadí podle výkonu

1 2 3 4

s 6 7 8 9 10

Date Submitte

Database

pmC

Oracle Oatabase 10g Enterprise Edition

1,008,144

8.33 US$ HP UX 11.iv2 64-Bit Base OS

11/04/03

824,16 4 786,646

8.28 US$ HP UX 11.iv2 64-Bit Base OS

07/30/03

768,839

8.SS US$ IBM AIX SL VS .2

09/12/03

8.2S US$ IBM AIX SL VS.2 Microsoft Windows 2000 709,220 14.96 US$ V..dvanced Server Microsoft Windows Server 707,102 7.16 US$ 2003 Oatacenter Edition 680,613 11.13 US$ IBM AIX SL VS .2

06/30/03

S9S,702 12.43 US$ Sun Solaris 8

10/31/03

Oracle Oatabase 10G Enterprise Edition Microsoft SQL Server 2000 Enterprise Ed.64-bit Oracle Oatabase 10g Enterprise Edition IBM OB2 UOB 8.1 Microsoft SQL Server 2000 Enterprise Edition Microsoft SQL Server 2000 Enterprise Ed. 64-bit IBM OB2 UOB 8.1 Oracle Oatabase 10g Enterprise Edition Microsoft SQL Server 2000 Enterprise Ed.64-bit

Price/tpmC Operating System

6.49 US$

Microsoft Windows Server 08/27/03 2003 Oatacenter Edition 64-bit

763,898

S77,S30 10.81 US$

09/19/01 OS/20/03 OS/09/03

Microsoft Windows Server 10/09/03 2003 Oatacenter Edition 64-bit

Pořadí podle poměru cena/výkon loatabase

lltpmC IIPrice/tpmC Operating System

IOate .Subm1tted

1

Microsoft SQL Server 2000 Standard Ed.SP3

20,477 12.06 US$

Microsoft Windows Server 109/08/03 2003 Standard Edition

2

Microsoft SQL Server 2000 Standard Ed.

20,108 12.19 US$

Microsoft Windows Server 07/14/03 2003 Server

EJ

Microsoft SQL Server 2000

119,S26112.2S US$

Microsoft Windows Server IOS/12/03 2003

I

119,718112.31 US$

Microsoft Windows Server 107/1S/03 2003 Standard Edition

I

18,818112.32 US$

IIOS/29/03

EJ s

Microsoft SQL Server 2000 Standard Ed.SP3 Microsoft SQL Server

Microsoft Windows Server

Benchmarking

3

2003 Standard Edition

Microsoft Windows Server 2003 Standard Edition Microsoft Windows Server 2003 Enterprise Server

SQL Server O Standard Ed.SP3

Pro dobrou orientaci na trhu je nutné zvážit prioritu výsledků testů. V případč požadav l.:u na absolutní výkon a spolehlivost bez ohledu na cenu systému jsou preferovány maximální propustnost a výkon. Dttležitým faktorem pro včtšinu zákazníků je ale pomčr cena/výkon. Z výsledků testů je zřejmé , že vyšší cena nemusí automaticky znamena t vyšší výkon .

Doporu čen á literatura : http://www .tpc.org/

-

Bezpečnost dat

v

BEZPECNOST DAT Po absolvovátú přednášky Bezpečnost dat budeme umět • • • •

charakterizovat jednotli vé složky bezpečnosti dat definovat pojem integritní omezení vysvětlit mechanismus fungování integritních omezení aplikovat získané teoretické poznatky v rámci konkrétního SŘBD

Složky bezpečnosti dat Oblast bezpečnosti dat zahrnuje velmi širokou problematiku. Pro potřeby této přednášky můžeme bezpečnost dat v databázi sledovat ze čtyř různých pohledů: • • • •

integrita dat ochrana dat zotavení z chyb paralelní zpracování.

Integrita da t (Integrity) zabezpečuje přesnost a korektnost dat v databázi . Jejím úkolem je zajistit, aby uložená data odpovídala skutečnosti . Úkolem ochrany dat (Security) je zabezpeči t databázi před neautorizovaným přístupem. Zotavení z ch yb (Recovery) zajišťuje obnovu stavu databáze v případě zhroucení systému . Paralelní zpracová ní (Concurrency) umožňuje současnou práci s daty různým uživatelům.

1. Jakéjsou základní složky bezpečností dat?

Integrita dat Integrita dat zabezpečuje přesnost a korektnost dat v databázi . Na rozdíl od ochrany dat není integrita uživatelsky závis l á. Pravidla, která ji tvoli platí pro kategorie uživatelů naprosto stejně. Integrita je definována množ inou pravidel , která se nazývají integritní omezení.

Integritní omezení (IO) jsou tvrzení , která mají platit o datech v databázi. IO by mčla být v úzkém vztahu k tvrzením na konceptuá l ní úrovní , která platí o objektech reálného svčta. 10 zabezpečují , že data uložená v databázi j sou odrazem reality. Někdy se mohou nazývat také "bussines rul es".

-

Bezpečnost dat

Aby tedy mohla být zajištěna integrita da t, musí být známa pravid la (10), která uživatel nesmí narušit. Tato pravidla musí být specifikována. Definici 10 provádí zpravidla návrhář databáze (data administrator) při návrhu schématu databáze . Protože IO se ověřují neustále , musí být v databázi zaznamenána. Jsou v zapsána v nějakém jazyku (podle konkrétního SŘBD) a uložena v systémovém katalogu. SŘBD musí sledovat veškeré uživatelovy operace a kontrolovat, zda při nich nedochází k narušení 10. K tomuto účelu musí m ít SŘBD integritní subsystém, který sleduje uživatelov y UPDATE operace (INSERT, UPDATE a DELETE ) a zji šťuje, zda nebyla některá 10 narušena . Příklad

CREATE INTEGR ITY RULE prav idl o1 FOR osoba (osoba.vaha >O) ON ATIEMPTED VIOLATION reject ; Příkladje zapsán v hypotetickém jazyce: definice 10 I. 1'ádek - zadánijména pravidla. Pod tímtojménemje JO uloženo v systémovém katalogu a v případě porušeiiÍ se totojmé no objevuje v chybových hlášeních. 2. řádek- definice logické podmínl.,y. Vpřípadě nesplnění této podmín/..y je JO narušeno. Podmínka se kontroluje při každé UPDATE operaci. 3. řádek- říká systému, co dělat pH porušení podmínky. Po spuš tění příkazu CREATE .. systém musí nejprve zkontrolovat aktuální stav databáze. Pokud je podmínka ale 'jJOIÍ vjednou případě p orušena, musí se pravidlo zamítnou t,jinak je akceptováno a uloženo do systémového katalogu. Dále musí SIUJD monitorovat všechny operace vkládající nebo měnící hodnotu atributu váha v tabulce osoba a v případě pokusu o vložení hodnoty O nebo zápomého čísla musí tuto aktualizaci odmítnout.

2. V čem spočívá hlavní úkol integrity dat?

Kategorie integritních omezení Integritní omezení můžeme rozdělit do čtyř kategorií:

• doménová pravidla • atributová pravidla • relační pravidla • databázová pravid la

Doménová pravid la Doménová pravidla definují množinu hodnot přípustn ých pro danou dom énu. Pravidlu se nepřiděluje žádné zvláštní jm éno,jeho jméno je stejné jako jméno vytvářené domény . Příklad y

CREATE DOMAIN množství NUMERIC(9) FORALL (množství> O AND množství < 5000 AND MOD(množství ,50)=0)

2

-

Bezpečnost dat

VytvoN doménu množství. Prvky této domény jsou nezáporná čísla menší než 5 000 dělítelná 50.

CREATE DOMAIN barva CHAR(5) VALUES ("černá", "žlutá", "bílá","modrá")

Vy tvoří doménu barva. Jedná se v podstatě o výčtový typ. M1iže nabývat hodnot čemá, žlutá, bílá a modrá.

Atributová pravidla Atributová pravidla specifikují doménu pro daný atribut. Nepoužívá se pro nč žádný explicitní příkaz CREATE ATTRIBUTE INTEGRITY RULE,ale j sou specifikovány přímo píi specifikaciatributů. Jméno pravidla je stejné jako jméno pliřazované domény . Piikaždé UPDA TE operaci se provádí bezprostřední kontrola hodnoty attibum,pokudje atributové pravidlo porušeno (pokoušíme se do sloupec v tabulce vložit jinou než povolenou hodnom), je operace zamítnuta. Zrušení pravidla se provádí automaticky při zrušení příslušného atributu.

Relační pravidla Relační pravidla jsou pravidla,která se týkají atributů jedné relace (tzn. mohou dávat do vzájemného vztahu údaje v několika sloupcích jedné tabulky). Kontrola pravidla se provádí bezprostředně pliUPDATE operaci. PříkJady CREATE INTEGRITY RULE prav 1 FORALL s (IF s.město = "Pardubice" THEN s.psč = "532 03") ON ATIEMPTED VIOLATION REJECT;

Definuje J O prav/. Totopravidlo se vztahuje k tabulce S. Pokud je ve sloupci město vložen text Pardubice , musí být ve sloupci PSČ hodnota 532 03. Pokud by došlo k pokusu o vložení jiné hodnoty než 532 03, bude prováděná operace odmítnuta. CREATE INTEGRITY RULE prav2 s.status > O AND s.status < 100;

Definuje JO prav2. Totopravidlo se vztahuje k tabulce S. Do atributu statusje možné vložit pouze nezápomé číslo menší než 100. CREATE INTEGRITY RULE prav3 IF sx.s# = sy.s# THEN sx .město = sy.město;

Definuje JO prav3. Totopravidlo se vztahuje opět k tabulce S. Pokud se do atributu s# vložena stejná hodnota, musí být stejná hodnota i v atriblllu město. CREATE INTEGRITY RULE prav4 COUNT (p WHERE p.barva = "žlutá") > 1;

3

-

Bezpečnost dat

Definuj e JO prav4 . Toto pravidlo se vztahuje k tabulce P. V tabulce mus í bý t v každém okamžiku alespoň dva záz namy obsahující v atributu barva hodnotu žlutá .

Databázová pravidla Databázová pravidla umožňují definovat omezení , která spojují dvč nebo více různých relací (tabulek) v databázi. V rámci definice omezujících podm ínek musí být definována i podmínka spojení tabu lek . Tato 10 se nekontroluji bezprostřednč ,jejich konn·ola se odkládá na skončeni transakce (COMMIT) a defaultní akcí při porušení prav idla není REJECT (odmítnutí operace) ale ROLLBACK (zrušení celé transakce) . Poznámka - bliž$/ informace o transakcích budou tématem následujících pfedná$ek .

Příklad CREATE INTEGRITY RULE prav5 IF prod.status < 20 AND prod.s# = zam .s# THEN zam .plat > 10 000 Definuje JO pr av5. Toto pr avidlo se vztahuje k tabulkám Prod a lam. Pravidl o určuje, že žádný zaměstnanec se statusem menším než 20 nemzlže mít plat menší než JO 000.

3. Sja ký m typ em JO j ste se setkali v SŘDB MS Access?

Doporu čená literatura: Pokorný J .. - Databázová abeceda, str. 89-92 Date

Řešení úkolů: 1. Integrita dat, ochrana dat, zotavení z chyb, paralelni zpracování

2. Integrita dat zabezpečuje korektnost dat. Je definována množinou integritních omezeni . Pokud není žádné integritní omezení porušeno,je databáze konzistentní.

4

Datové modely

DATOVÉ MODELY Po absolvování přednášky Datové modely budeme umčt

• popsat funkci databázového systém u • charakter i zovat jednotl i vé složky databázového systému • vyjmen ovat a stručně objasn it funkce SŘBD • vysvčtli t Ílčcl datového modelování • charakterizovat jednotlivé databázové modely

Databázové systémy (DBS) Databázový systém (DBS) umožňuje shromažďovat různé informace . Tyto info•mace ukládá a udržuje v plamém stavu na centrál ním místě. Databázový systém se skládá z několika částí : DBS = SŘBD + OBA + DB SŘBD- systém řízení báze dat- program ,jebož Ílkol em je pracovat s uloženými informacem i (organizuje je a udržuje je v platném stavu), OBA- databá zová aplikace- program umožňujíc í manipulaci s daty (výbčry, prohlí žení a aktuali zace infom1aci) prostl-ed nictvím SŘBD, DB- databáze (báze dat)- množina infonnací , o nichž chceme mit přehled. Jednotlivé části DBS se mohou provozovat na jednom počítači nebo mohou být různých počítačích , h i storicky byly často SŘBD a OBA spojeny dojednoho programu . V dnešní dobč pa tli mezi nejpoužívanější způsoby zpracován i dat databázové systémy klient/server , v nichž jsou SŘBD a OBA od sebe oddčleny.

I. Uveďlepříklad a/espOJíjeduoho databázového systému (DBS) a alesp(ní dvou ystémti řízeuí báze dat (SŘBD).

Báze dat Data uložená v databázi jsou tvořena informacemi,o nichž potřebujeme mít přehled. V databázi jsou zpravidl a uloženy info1mace o nějaké skupině objektů (elllil), které je možné určitým zpt1sobem definovat. Násl edtuící příklad ukazuje databázi pacientů praktického lékaře. Každ.ý zázuam (věta) v databázi obsahuje i nformace ojednom pacientovi ajednotlivépofožky (pole) zaznamenávaj í detaily o příslušném pacientovi. V příkladu jsou zachyceny tři záznamy (pacienti) a každý záznam obsahuje čtyři položky (příjmení, křestní jméno, rodné čí slo a váhu) pro každého pacienta.

v

Systémy řízení báze dat (SRBD) Aby bylo možné pracovat se shromážděnými daty,musí SŘBD poskytovat ji sté základní služby:

Datové modely

Pokud chceme na disku nějaké infonnace uchovávat, musí nám SŘBD poskytnou služby pro definici dat, pomocí nich můžeme určit záznamy a položky v databázi . Kromě vl astní defin ice dat musí systém zajisti t i údržbu dat- musí spravovat i nfotmace na disku a například být schopen vyhledat určitý konkrétní ptvek databáze. Krom ě vl astní h o uchováván í dat musíme mít možnost s daty pracovat. Manipulace s daty představuje možnost vkládat nová data do databáze,vybírat nebo tří dit potřebné in fonnace a aktual izovat nebo rušit uložené záznamy. Pokud budou data pouze uložena na disku a uživate l nebude mít možnost zobrazi t j e na monitoru nebo ve fom1ě tištěné sestavy, bude tuto možnost pravděpodobně postrádat. Systém proto zpravidla poskytuje i ji sté metody pr ezentace dat uživateli - zobrazování dat. Pro o:načení Si?I1D be:stn=eb :abra:a••ání dat se éa.sto fXJLóvá termín databá:aVJ;stroj. Protože v bázi dat jsou zpravidla uchovává n y infonnace, mající pro uživatele vel ký význam, je nezby111é, aby SŘBD obsahoval mechanismy zamčující správnost a úplnost dat v databázi.Mechan ismy integrity dat chrání data před vněj ším i okolnostmi (např.výpadek proudu) í chybnými změnami provedenými uživa tel i. Tyto mechanismy maj í oh romný význam zvláště u velkých víceuživatelských databází. SŘBD tedy poskytuj e následující služby: Definice dat (Data Defini tion) Údržba dat (Data Maintenancc) Manipulace s daty (Data Manipulation) Zobrazování dat (Data Display) llllegrita dat (Data in tegrity)

2,/(terou ze pěti <ák/adních s/uieb nuiže v nékte1ýchpřípadech SŘBD postrádat? jak se takový SŘBD nazývá?

Databázový model Databázový mod el je ve své podstatě popisem fungováni databáze. Jeho hlavním úkolem je popsat, jakým způsobem jsou data zplístupňována uživatelům a programá toritm tvořící m databázové apli kace. Uživate li se jev í data jiným zet'tsobem než jak jsou ve skutečnosti uložena . Napřiklad uživatel vi dí požadovaná data jako dvojrozměrno u tabulku Re. ené projekty, zatí mco uvnitř systému jsou tato data uložena ve dvou tabulkách Pracovník a Projekt, kde tabulka Pracovník obsahuje údaje ojedno tlivých zaměstnancích řešících projekty a tabul ka Projekt údaje o projektech. V systému je uložen návod popi sující,jaký m způsobem je možné z tčc hto dvou tabulek vytvolit výslednou tabulku Ře.'iené projekty, obsahující údaje o projektech i jej i ch řeš i telích . A úpl ně jiný m způsobem jsou data uložená na disku,kdy j ednotl ivé řád!ky tabulek jsou uloženy jako záznamy v sektorech a ex i stují k ni m j eště další pomocná data, která urych luj í přístup k požadova ným údajům . V datovém modelu jsou rovněž popsány vztahy mezi jed notlivými obj ekty. Pii datovém m odel ován í se využívá abstrakce - od jednot l ivých kon krétních entit (např. student Nový) se odvozují typy entit (např.STUDENT),k teré se od konkrétní en tity l iší tí m,že jsou charak tetizovány pouze vybraný mi vlaslllOStnl i. Například typ en tity STUDENT má vlastnosti (atri buty) j méno,datum narození, ... . Výsledkem m odel ování je logické schéma databáze. Datový model je tedy jistý nástroj pro tvorbu schématu databáze.Podobným nástrojem jsou i konceptuáln í modely (např. E-R model), výsledkem jehož použití je koncepntálni schéma. Databázové modely zpravidl a ncpopisuj í vlastní uložení dat na disku.Tčmi to probl émy se zabývaj í tvůrc i konkrétních SŘBD. Rttzné SŘBD jsou založeny na různých databázových modelech: systémy pro správu soubori1 hierarchické DBS síťové DBS relační DBS objektové-relační DBS

2

Datové modely

objektové DBS

3. K jakému účelu slouží da1abázový model?

Systémy pro správu souborů Systém pro správu souborů (File Management System - FMS)je nejjednodušší databázový model a jako jediný z databázových modcli1 přímo popisuje zpi1sob uložení dat na disku. V FMS j sou všechny pol ožky ukládány sekven čně do j ednoho souboru, ve tvaru podobném následuj í cí ukázce: Pokud je třeba nají t určí tou infom1ací, je nutné prohledat celý soubor od začátku. FMS byla historicky první použitá metoda pro uložení dat v databázi . Výhodou FMS je jeho jednoduchost. Tyto systémy mají řadu nevýhod: • mezi uloženými údaji ncní žádný vzájemný vzta h ·programátor tvořící databázovou aplikaci musí přesně vědět, jak j sou data v souboru uložena. • vznikají značné problémy s integritou - SŘBD ncprovádí žádné kontmly a za správnost ukládaných dat odpovídá aplikace. Pokud do jedné databáze přistupttic několik různých aplikaci s rozdílnými požadavky na pří pustn é hodnoty položek, mohou vznikat značné potíže. • pomalé vyhledávání infonnaci -pokud potl-cbujcmc najít nějaký údaj, musíme databázi prohledávat od začátku až k hledané položce. • obtížné změny struktury databáze- pokud chceme do databáze doplnit údaj o výšce pacienta, musí SŘBD přečíst každý záznam, zapsat jej do pomocného souboru a na jeho konec doplnit údaj o výšce. Po přečteni všech záznamt'1 původního soubom bude nutné tento soubor zmšit a pomocný soubor přejmenovat jeho jménem.

4. Víle (například z jiného předmělu) ,jak se nazývá typ sekvenčního soubortt, k1e1ý využívá FMS? Znáte nijaké nějaké přístupové me1ody urychlující prohledávání tohoto souboru ?

Hierarchický databázový model Hierarchické databázové modely (HDS) tvoří další stupeň ve vývoji databázových modeiÍL. HDS organizuje data do strom ové stmktury. Ve stromě je vždy j eden kořenový uzel ,jehož "vlastn í kem" je SŘBD.Z kořene vedou ukazatele k ukazate le k uzlúm !.úrovně v nichž začíná vl astní databáze.Každý uzel první úrovně m ilže mít několik synovských uzlů 2.úrovně apod. Jednot l ivé datové položky jsou umístě n y na různých úrovních (uzlech) podél větví vycházejících z kořene. Na fyzické struktuře dat na disku nezáleží , tento úkol řeší konkrétní SRBD. Obvykle se používá zřetězený seznam s ukazate li .V tomto případč je možné přidávat nové pol ožky na jednotl i vých úrovních- stačí pouze zmčnit hodnotu ukazate le na sourozen ecký uzel. Z diagramu HDS je ale obtížné určit, z jak ých položek se skládá záznam . Velmi obtížná je zmčna strukrury databáze- v tomto připadč je nutné vytvořit novou stmkturu a překopírovat do ni údaj e ze stávaj ící -i zmčna defin ic úrovní. Tento databázový model umožňuje definovat vztahy I :N a efcktivnčjšim způsobem je v nčm možné realizovat vyhledáváni infonnaci. Pii prohledáváni neni nutné prohledávat celý soubor, ale při vhodném rozloženi požadavku na jednotl ivé složky stačí prohledá vat příslušnou část stromu. HDS neumožňuje definovat vztahy M:N. Tento zjednodušený síťový model (i když v li teratuře bývá uváděn samostatně) byl využíván v době magnetických pásek, přístup k datům byl pouze sekvenční,od tohoto modelu se upustilo s příchodem magnetických médii a z důvodu nári1Stt1 redundantních dat.

3

Datové modely

Síťový datový model Síťový databázový model (Network Database System- NDS) vycházející z programovací hojazyka Cobol popisuje databáze, v n i chž existují vztahy M:N. NDS j e založen na ukaza telích , které vyjadřuj í vztahy mezi jednotliv ými položkami. Vzájem né vztahy mezi množi nami (např. např. množina studentů, m nožina předmětů, ...) mohou být velm i komplikované . NDS má obdobné nevýhody týkají cí se zmčny struktury databáze je HDS. Pro označení NDS se často používá tem1ín CODASYLovské databáze, protože první písemná specifikace byla publikována konferenci CODASYL (Confcrence on Data system Languages) v roce 1971.

S. V čem spočívají nejvélsí nevýhody HSD a NDS? Jaký je rozdíl mezi HDS a NDS?

Relační datový model Relační databázový model (Rclational Da tabase System - RDS) pochází z roku 1969, kdy E.F.Codd popsal model databází založený na matematickém pojmu relace. V RDS se nevyužívají rodičovské vztahy mezi jednotlivými položkami .V tomto modelu jsou data organizována do uspořádaných n-tic. Jednotl ivé n-tice před stavuji řádky tabu lky. Každý záznam je tedy řádkem tabulky a každá položka je sloupcem tabulky . Relačni databáze je tedy soustava v čase se měnících tabulek s uspořádanými sloupci. Pii definování schématu databáze j e využívám proces normalizace , při němž dochází k dekompozici dat do podm noži n pro jed notlivé tabulky. Výhody ROS: • reali zuje vztahy M :N • snadná změna schématu databáze - změna struktury spočívá v přidáni nebo zrušen i sl oupce v tabulce a neovlivní ostatn í tabulk y v databázi • zachování integrity dat - pokud je SŘBD skutečně rel ační musí znemožnit přistup k datům ji nými kanály než prostředni ctvím sebe sama (data musí být uložena ve tvaru vylučuj ícím plístup pomocí ji ného programu než SŘBD) • programy pracují s daty an i ž by znaly jejich umístčn í v databázi- k veškeré manipulaci s daty využívají služeb SŘBD.

6.Jak je definována relace v RDS?

Objektově-relační databáze Protože mnoho současných aplikací je založeno na relační technologii, řada výrobců se pokusila integrovat objekty a relace dojednoho systému a vytvoři t objektové relační technologii (OROS). V 90. letech se obje vily tři možné přístupy : • objek10vé relační dolové mauaže1y mapující objekty do relačních tabul ek • relační obálky tvořené lmibovnam i ,k teré se přilinkují k relační databázi. Relační obálka detekuje zmčny objektit a promítá je pomoci SQL do relační databáze a zmčny v relační databázi promítá do objcktit

4

Datové modely

5

• objektové relační databáze uk ládající data pomocí relací i jako objekty . V rozšíření směrem k objektt'un se výrobci orientují před evším na data reprezentovaná jako vel ké objekty (tex ty, obrázky , ...). V klasi ckých ROS je sice také možné tyto objekty do databáze uloži t,ale protože tyto systém y nemohou pracova t sj ejich struk turou, není možné v n ich vyhledávat pod le obsahu (celý objekt vystupujejako atomická hodn ota). OROS bývají oproti ROS oboh aceny o uživatelsky definované datové typy a uživatelsky deflnovanéfimkce. Mezi objektově rel ačn í databáze řadíme n apř. Oracl e, který je rozšířen o vlastní abstraktní datové typy,kolekce, uk l ádáni velkých datových objektů, odkazy , objektové poh l edy , metody .

Objektově orientované databáze Objektově ori entovaný databázový systém (OODS)je databázový systém vybudovaný pomocí objektově orientovaných metod jehož každá komponenta zapouzdřujc data a funkce, přičemž komponenty dědi atributy a chování z jinýc h komponent a navzáj em komunikuji pomoci zpráv. P1vní pokusy o vytvoření objektově orientova ných databázi vycházel y z ex istence objektově orientovaných programovacích jazyků.

Doporučená literatu ra: Sal emi J. - Databáze kl ien úserve r,str. I - 17 Pokorný J.- Databázo vá abeceda - str.43 - 44; 1 09 - 114; 115 - 118;

Connol y T. - Database system s, srr.982 - I 032

Řešení úkolů: I. Příkladem d tabázovéh o systému může být n apříklad systém I SH sloužící k evidenci studijní agendy na FIS, představiteli SRBD jsou napřík lad MS Access, MS SQL Server, lnformix, 082 apod.

2. SŘBD nemusí nutn ě obsahovat prostředky pro zobrazován í dat. Tuto fun kci může převz ít databázová aplikace. SŘBD bez m ož nosti zo bra zování dat se nazývá databázový stroj. 3. Databázový model j e nástroj pro tvorbu schématu databáze. Jeho hlavním úkolem je popsat způsob zpřístupňová ní dat uživatelům a programátorům . ;]!.!1. 4. Halda (heap); proh ledává ni souboru j e možné urychlit například indexací nebo využ itím hašovacích funkcí. S. V případ ě pou žití HDS a N DS se velmi obtížně provádí zm ěny schématu databáze. NDS na rozdíl od HDS umožňuje realizovat vztahy M:N. 6. Relace nad množinami Dl' ..., 0 j e libovolná podmnožina kartézského součinu D x ... x 0 11

1

• 11

wff!.

Ochrana dat

OCHRANADAT Po absolvování přednášky Ochrana dat budeme umčt • • • •

vyjmenovat aspekty bezpečnosti dat charakterizovat dva základní přístupy k bezpečnosti dat vysvětlit princip datového kódování použít jednoduch ý kódovací algoritmus

Aspekty bezpečnosti dat Ochrana dat (DataSecurity) spočívá v zabezpečení dat před neautorizovaným přístupem. Existuje celá řada aspektů bezpečnosti. Mezi nejdůležitější z nich patří napřík lad aspekty: • • • • • • •

právní , sociální a etické fyzická kontrola politické otázky operační problémy HW kontro ly bezpečnost operačního systému (OS) specificky databázové otázky

Právní, sociá lní a etick éotázky se zabývají například problémy , zda má konkrétní osoba požadující nčjaké informace právo tyto informace (např.plat ostatních zaměstnanců) vi dčt. Tuto problematiku řeší napřík lad i zákon na ochranu osobních informací. Každá organizace musí mít vytvořen systém pravidel, která určují kdo a jaké operace může s daty provádět (politické otáz ky). Fyzická kontrola může být realizována například umístěním počítače do uzavřené místnosti.V systému se zpravidla používají přístupová hesla, je třeba definovatjak jsou utajena a jak často se mění (operační probl émy). HW kon trolymohou být založeny na bezpečnostních charakteristikách procesorovéjednotky. Do problematiky b ezpečností OS patří například otázky, zda OS ruší obsah úložišť a datových souborů, když už je nepotřebujeme.

Přístupy k bezpečnosti dat Existují dva zák ladní plístupy k bezpečnosti dat- diseretíonary a mandatory . Moderní SŘBD

zpravidla zaji šťují jeden z nich, ve výjimečných případech oba přístupy . V obou přístupech se mluví o datových objektech. Datovým objektem může být cokoliv, co je obsaženo v databázi. Najedné straně můžeme tímto pojmem označit úplnou databázi a na straně druhé může být takovým objektem jedno jediné pole v tabulce. Ať systém používá libovolný typ kontroly , zásadní otázka- kdo může s čím provádčt operace nespočívá v technickém provedení. Tato otázka je politická. Musí ex istovat ustanovení vnč systému,

Ochrana dat

které určuje příslušná pravidla. SŘBD následně tato pravidla bude technicky provádět. Výsledky politických ustanovení musí být • sděleny systému pomocí nějakého jazyka definujícího přístupová práva • opakovatelné systémem (uloženy v katalogu ve formě sccurity rules) Dále musí být pro kontrolu daného přístupu (kombinace user+ objckt+opcracc) označeno aplikovatelné bezpečnostní prav id lo a vlastní kontro lu bude provádět bezpečnostní subsystém SŘBD. Aby by l systém schopen určit , které bezpečnostní pravidlo je aplikovate lné pro daný přístup , musí být schopen určit zdroj požadavku - uživatele. Uživatelé se do systému proto hlásí pomocí své ídentilikace (většinou musí zadávat i heslo pro ověření své totožnosti).

I.Jakýje obecný po stup při zajišl'ování ochrany dar v databázi?

Discretionary control Většina SŘBD má implementovánu discretionary control. Discretionary control je založena na myšlence, že každý uživatel má definována různá přístupová práva (privi legia, autorizace) k různým objektům. Různí uživatele mohou mít různá práva na tytéž objekty. Tato metoda je velm i flexibiln í. Pro delinici bezpečnostních pravidel je potřeba jazyková podpora. Obecný příkaz by mčl míl tyto části:

CREATE SECURlTY RULE rule GRANT privilege-commalis t ON expresion TO user-commalist ON ATIEMPTED VIOLAT ION action Část CREA TE SECURITY RULE delinuje jméno pravidla (rule). Pravi dlo je pod tímto jméne m uloženo v systémovém katalogu. Jméno se bude objevovat ve zprávách reagujících na porušení příslušného pravidla. V části GRANT určujeme, jaký typ operací může uživate l provádčt (privilegia- RETRIEVE- výbčr dat-, lNSERT, U PDATE, DELETE , A LL). Část ON definuje s jakými datovými objekty. Pomocí výrazu (expresion) lze speci fikovat tabulk y, sloupce i množiny záznamů. Jedná se o výraz relační algebry , který určuje rozsah platnosti pravidla (např. položky tabulky kde ve sloupci město není hodnota Praha). V části TO je uveden seznam uživatelů , kteří mají dané privilegium přiděleno. A ac/ion v části ON ATTEMPTED VIOLA TION je specifikováno,jak bude systém reagovat na porušení prav idla (např. zamítnutí přístupu, přerušení programu , záznam do speciálního logu, ...)

Mandatory control

2

-

Ochrana dat

Mandatory contol je postavena na filosofii tříd datových objektů a uživatel ů. Je použitelná v databázích , kde data mají spíše statickou a přesně klasifikovanou stmktum (např. armáda , v láda). Každý datový objekt je označen jistou klasifikační úrovní (classificatin Ieve!) a každý uži vatel má jistou clearance úroveň. Jednot livé úrovně jso u striktně uspořádány - například : • • • •

veřejné důvčmé tajné přísně tajné.

K danému datovému objektu může přistupovat pouze uživatel , který má přidělenu odpovídající elearence úroveň. Přístup k datům se řidi těmito dvěma pravidly (mějme uživatele Ia datový objekt J): • uživateli může vidčt objekt J je n tehdy ,je-li clearance Ieve!Ivětší nebo rovna elassifíeation Ieve! J • uživateli může modifikovat objekt J ,je- li elearance Ieve! I = classification Jeve! J

Bezpečnostní třídy Otázky týkající se bezpečnosti jsou dokumentovány v dokumentech U.S. Department of Defcnse: • Tmsted Computer System Evaluation Criteria (Orange Book) • Trustcd Database Management System lnterpretation (Lavender Book ) Dokumen ty definují čtyři bezpečnostn í třídy: • D - minima! proteetion • C - diseretionary proteetion o dvě podtřídy CI
Podpora SQL SQL má jazykovou pouze pro discretionary control. Je možné použit příkazy GRANT privileg i a ON object TO users

3

-

-

4

Ochrana dat

WITH GRANT OPTIONS REVOKE nebo mechan i smus pohledu (view).

2. Kletý z bezpečnostních pNstup1i umožňuje definovat pNs111pová práva k jednotlivým objekt1i pro každého uživatele ?

Datové kódování Výše uvedené bezpečnostní mechanismy se používají proti neoprávnčnému postupu uživate lů, kteří pro přístup do databáze používají normální přístupové cesty. Cílem tčchto mechanism u je zabezpečit, že uživatel bude manipulovat pouze s daty, na která má oprávnčni. Můžou al e existovat i "uživatelé", kteří nepřistupuji k databázi tak, že se přihlásí pomoci svého uživatelského jména , ale používají "bypass" systému.Například fyzické přesunutí části databáze nebo využ ívají odposlech na komunikační l ince. Před touto kategorii útočníků ochrání data datové kódováni. Při datovém kódováni se citlivá data uchovávají nebo přenášejí po komunikačních linkách v kódovaném tvana. Při datovém kódováni je plaiutext (původní nekódovaná data) kódován pomocí kódovacíh o a lgoritmu a výsledkem jsou zakódovaná data (ciphertex t). Do kódovacího algoritmu tedy vstupuje plaintext a kódovac í klíč a vystupuje ciphertext. Kódovací algoritmy jsou veřejné, klíče musí zůstat t jné. Existují dva základní přístupy ke kódování: • substitu ce (nahrazení znaku plaintextu jinými znaky) • per mu tace (znaky plain textu jsou přeházeny do jiné sekvence)

Příkl ad: Následující příklad ilustruje metodu substituční. Mčjme nezakódovaný text (plaintext): NA TY LOUCE ZELEN Y Při kódování budeme používat kódovací klíč: PES Pro zakódování použijeme tento postup: I. Rozdělíme plaintext do bloku stejné délky jako je klíč (rj. 3 znaky). Pro lepší čitelnost nahradíme mezeru znakem + NA+ TY+ LOUCE+ ZEL ENY 2. Nahradime každý znak plaintextu číslem podle kódovací tabu lky: 00. mezera

OI·A 02 • B

09 - I 10. J ll-K

18 • R

19. s

20-T

-

5

Ochrana dat

12- L

21 - u

05- E 06- F 07- G

13-M 14- N 15-0 16- p

22 - v 23- w 24-X 25- y

08- ll

17-Q

26-

3 -c 4 -D

z

tzn. N nahradíme 14, A nahradíme Ol a+ zaměníme za 00. Místo původního textu dostáváme řetězec čísel: 140100 202500 12 152 1 030500 260512 051525. Stejné nahrazení provedeme v kódovacím k l íči a dostáváme: 160519 3. Každý zakódovaný blok plaintextu sečteme s klíčem. Sčítáni budeme provádět vždy v dvouciferných blocích. Aby bylo možné provést zpětnou substituci; jako výsledek zapíšeme zbytek po dělení číslem 27 (modul u 27). tzn .první blok je 140I 00 a klíč 1605 19 14 + 16je 30- v kódovací tabulce máme pouze čísla 0-26, proto musíme vypočítal 30 mod 27 = 3,jako výsledek tedy zapíšeme 03 O I + 05 je 6 -jako výsledek zapíšeme 06 00 + 19je 19 - jako výsledek zapíšeme 19 prvním blok tedy nahradíme skupinou cifer 030619 dostáváme : 140I 00 202500 12 152 1 030500 260512 051525 160519 1 605 1 9 1605 19 160519 160519 160519 030619 0903 1 9 0 120 13 191019 151004 212017 4. Podle kódovací tabulky nahradíme nazpět čísla znaky. Dostáváme zakódovaný text (ciphenexl) CFS ICS ATM SJS OJD UTQ

Ochrana dat

6

N A

T y

ZE L E N Y

LOUCE

P E S

kódcwact tnbuAIII

00 Ol 02 03 04 -

os -

06 07

08 -

A

09 10 -

8

ll

c

12 13 14 -

+

(mexera)

-

I

J K

18 19 20 -

R

s T

o

G

15 16 -

p

21 - u 22 - v 23 - w 24 - X 25 - y

H

17

-

Q

26 -

o E F

L M N

z

Kódovací standa rd y Mezi nejznámčjši kódovací standardy patři DES, který kombinuje oba přístupy. Tento standard zajišťuje vysokou bezpečnost. Plainuw je ro=délen do 64 bitov_vch b/oktl. ka:!dý blokje kódován =apomocí 64-bitové/w klíče (56 dat.bittl + 8 parimích 256 mo:!ll);Cit klíčtl}. Blok je =akódováll s potótím počáteč11i permtttttce ,pak nás/edtife 16 substifttčních krokl! a na =ávěr se ap/iktife permutace inver=ní k ptivodni.

Na odlišné lilosofii je založen public key. v jeho případě je kódovací algoritmus i kliče veřejně dostupné .každý muže kódovat plaintext do ciphcr textu. Ale odpovídající dekódovací klič je tajný (a nemi'1žc být odvozen z kódovacího klíče). A, Bjsou dva uživatelé, kteH chtějí navzájem komunikovat pomocí PK. A i B budou publikovat svzij kódovací algoritmus včetně kódovacího klíče, ale utají dekódovací algoritmus a klíč. ECA, ECB jsou pNslušné kódovací algoritmy (veřejně známé) DCA, DCB jsou dekódovací algoritmy (DCA zná pouze A a DCB zná jen B) platí, že pokud text zakódujeme kódovacím algoritmem a následně na zákódovan;í text použijeme pNshršnJ í dekódovací klíč, získáme p1ivodní text: DCA(ECA(x)) = x Uživatel A chce poslat plaintext P uživateli B. Nejprve aplil.."l!ie DCA (znájen pouze A) na Pa výsledek zakód uje pomocí ECB (kódovací algoritmus Bje veřejně známý) a pošle B. c = ECB(DCA(p)) Uživatel B přijme ciphertext c, nejprve na něj aplikuje DBB (znájej pouze sám) a později ECA {kódovací algoritmus A je veřejně známý): ECA(DCB(c)) = ECA(DCB(ECB(DCA(p)))

= ECA(DCAúJ))

p

Ochrana dat

3.Před !.ým chrání datové kódování?

Doporučená literatura: Pokorný J. . -Databázová abeceda, str. 89-92 Date C.J. - An introduction to database systems, str. 416-437

Řešení úkolů: /.Definice přístupových práv ajejich uložení v systémovém katalogu - při tvorbě databáze nebo později. Pfí požadavku uživatele- ověřeníjeho totožnosti, zjištění jakou operaci a sja!.ým objektem bude provádět, vyhledání příslušného security rules ajeho aplikace.

2. Discretionary controf.

3. Datové kódovaní chrání proti odposlechu dat při komunikaci nebo pokud jsou používány k přístupu k databázi nestandardní cesty.

7

Paralelní zpracování

PARALELNÍZPRACOVÁNÍ Po absolvování přednášky Paralelní zpracování budeme umět • • • •

vysvětlit princip paralelního zpracování vyjmenovat a popsat základní problémy parale lního zpracování vysvětlit základní myšlenky uzamykacích protokolů popsat dvoufázový uzamykací protokol

Problémy paralelního zpracování O paralelním zpracování hovoříme tehdy ,_pokud SŘBD přistupuje v jednom čase k jedněm dattun pomocí více transakcí. V tomto případě SRBD potřebuje nějaký mechanismus , který zabezpečí bezpečnost para l elního zpracování (concurency control). Pokud je současně prováděno více transakcí nad jednou databází, nemusí běžet sekvenčně za sebou, ale mohou se navzájem prolinat. Plánování současného bčhu transakcí provádí rozvrhovač.

Problémem paralelního zpracování je, že prolínání operací jednotlivých transakcí vede obecně k nekon zistentnímu stavu databáze. Při souběhu několika transakcí , z nichž každá je správná, mť1že nastat několik situací , v nichž budou transakce dávat nesprávný výsledek: • ztráta aktualizace • dočasná aktua lizace • nekorektní použití agregačních funkcí

Ztráta aktualizace Problém ztráty aktualizace je možné ilustrovat následujícím příkladem . Mějme dvě transakce A a B. Obě transakce pracují nad databází cestovní kanceláře a aktualizují informace o počtu rezervací. Transakce B čtyři rezervace přidává : Transakce A ruší pět rezervací: READ(x)

READ(x)

x := x-5 WRITE(x)

x := x+4 WRITE(x

Na začátk u máme v databázi registrováno 80 rezervací. Pokud nejprve proběhne celá transakce A a po jejím ukončení transakce B, bude v databází 79


2

rezervací:

Transakce A: přečte x=80 vypočítá x=80-5 zapíše x=75

READ(x) x := x-5 WRITE(x) Transakce 8:

přečte x=75 vypočítá x=75+4 zapíše x=79

READ(x) x := x+4

WRITE(x)

Transakce A

Transakce B

Pokud nejprve proběhn e celá transakce Ba po jejím ukončení transakce A, bude v databázi 79 rezervací:

Transakce 8: přečte x=80 vypočítá x=80+4 zapíše x=84

READ(x) x :=x+4

WRITE(x) Transakce A:

přečte x=84 vypočítá x=84-5 zapíše x=79

READ(x) x := x-5 WRITE(x)

Transakce A

Transakce B

Když se budou transakce A a B pro línat, může nastat situace:

Transakce A:

Transakce B:

READ(x) x := x-5

READ(x) x := x+4

WRJTE(x) WRITE(x)

přečte x=80 vypočítá x=80-5 přečte x=80 vypočítá x=80+4 zapíše x=75 zapíše x=84


3

Transakce A

Transakce B

V tom to případě , ačkoli v v databázi mělo být u loženo 79,je počet rezervaci změněn na 84. Problém lze obecně popsat takto: Transakce B mění hodnotu viděnou v čase t2- tj. tu samoujako v čase t1 (t1<12), tím se úplně <Jrácf z měna provedená transakcí A.

Dočasná aktualizace Problém dočasné aktualizace je možné ilustrovat následujícím příkladem . Mějme opět dvě transakce A a B. Transakce A ruší pět rezervací: Transakce B čtyři rezervace přidává : READ(x) READ(x) x := x-5 x := x+4 WRITE(x WRITE(x) Na začátku máme v databázi registrováno 80 rezervací. Při zpracován i transakce A dojde k (lokální) chybě a transakce mus í být vrácena zpět. Pokud nej prve probíhala transakce A, byla přerušena a vrácena zpět, a po jejím ukončení proběhla transakce B,je v databázi 84 rezervací. Pokud nejprve proběhla transakce B, změnila počet rezervací na 84. Po jejím ukončeni by la spuštěna transakce A, nebyla ale dokončena a všechny změny , které provedla byly vráceny zpět. Také v tomto případě je v databázi 84 rezervací. Když se budou transakce A a B pro línat, m uže nastat si tuace:

Transakce A:

Transakce 8:

READ(x)

přečte x=80 vypočítá x=80-5 zapíše x=75 přečte x=75

x := x+4 WRJTE(x)

vypočítá x=75+4 zapíše x=79

READ(x) x := x-5 WRJTE(x) chyba (ROttBACK)


Transakce A

4

Transakce B

V tom to případč , ačkoliv v databázi mčlo být uloženo 84,jc počet rezervací zmčnčn na 79. Problém lze obecně popsat takto: Transakce ll 1•illí {m . ěnyjiné, zatím nepotvrzené transakce A a na jejich základě pr{)l >ádí 11/astní ;.měny. Pokudje tmnsakce A 11rácemt zpět, pra cuje B se iptttnými daty. Po ROLLBACK A bude aktualiz ace pro1•edená ll z tracená a 11ýsledek chybný.

Nekorek tní pou žití agregačních fun kcí Nekorektní použiú agregačn ích funkcí můžeme ilustrova t na da lším příkladě: Mějme opět dvě transakce A a B. Obě transakce pracují nad bankovní databází s j ednotlivými konty. Transakce A sčítá částky na kontech I , 2 a 3: Transakce B převádí 10 000 Kč z konta 3 na konto sum=O READ(konto3) READ(kon tol) konto3=konto3 - 10 000 sum=sum +konto I WRJTE(konto3) READ(konto2) READ(konto I) sum=sum+konto2 konto I =konto I + I O 000 READ(kon to3) WRITE(konto I) sum=sum+konto3 N a začátk u máme v databázi na kontě I 40 000 Kč, na kontě2 50 000 Kč a na kontě3 30 000 Kč . Pokud nejprve proběhne celá transakce A a po jejím ukončení transakce B, bude na všech třech kontech dohromady - Í· výsledek transakce A - 1.20 000 Kč:

Transakce A:

Transakce ll:

sum=O READ(kontol) sum=sum+konto I READ(kon to2) sum=sum+konto2 READ(konto3) sum=sum+konto3 READ(konto3) konto3=konto3 - I O 000 WRITE(konto3) REA D(konto I ) konto I =konto I + I O 000 WRJTE(kon to I )

sum =O přečte konto I =40 000 vypočítá sum=0+40 000 přečte konto2=50 000 vypočítá sum=40 000+50 000 přečte konto3=30 000 vypočítá sum=90 000+30 000 =

000

přečte konto3=30 000 vypočítá konto3=30 000- 10 OOt zapíše konto3= 20 000 přečte konto I =40 000 vypočí tá konto 1=40 000+ I O 000 zapíše konto I = 50 000


5

konto1 = 40000 Transakce A

Transakce B

konto3

=

30000

Pokud nejprve. pr bčhn e celá transakce Ba po jejím ukončení transakce A, bude na všech třech kontech dohromad y - 1· vysledek transakce A - 120 000 Kč: 7í·ansakce 8: READ(konto3) konto3=konto3 - I O 000 WRITE(konto3) READ(kontol ) konto I =konto I + I O 000 WRITE(konto 1)

Transakce A:

sum=O READ(kontol) sum=sum+konto I READ(konto2) sum=sum+konto2 READ(konto3) sum=sum+konto3

přečte konto3=30 000 vypočítá konto3=30 000- 10 00! zapíše konto3= 20 000 přečte konto I =50 000 vypočítá konto1=50 000+10 000 zapíše konto I = 60 000 sum=O přečte kontol =50 000 vypočítá sum=0+50 000 přečte konto2=50 000 vypočítá sum=50 000+20 000 přečte konto3=20 000 vypočítá sum= IOO 000+20 000 = 120 000


6

konto1 = 40000 Transakce A

Transakce B

konto3

=

30000

Pokud připustíme, aby se obč transakce prolína ly, mťažcmc dostat chybný výsledek

Transakce A : sum=O READ(konto l ) sum=sum+konto I READ(konto2) sum=sum+konto2

Transakce B:

READ(konto3) konto3=konto3 - I O 000 WRJTE(konto3) READ(konto I) konto I =konto I + I O 000 WRITE(konto I) READ(konto3) sum=sum +konto3

sum=O přečte konto1=40 000 vypočítá sum=0+40 000 přečte konto2=50 000 vypočítá sum=40 000+50 OOO=S 000 přečte konto3=30 000 vypočítá konto3=30 000 - I O 00 zapíše konto3= 20 000 přečte konto I =40 000 vypočítá konto I=40 000+ I O 00( zapíše konto I = 50 000 přečte konto3=20 000 vypočítá sum=90 000+20 000 =

000


7

konto1 Transakce A

Transakce B

= 40000

konto3 = 30000

V tom to případč , ačkoliv mčl být součet částek na kon tč 120 000 Kč,j e pouze IlO 000 Kč.

Uzamykací protokoly Předchozí problémy se můžeme pokusit vyřešit pomocí myšlenky: Pok u d transakce potřebuje přistupovat k n ějakému objek tu (typicky db položce) uzam kne jej a ostatn í transakce jej nem ohou měnit. Tato transakce má potom možnost provádčt své operace a má zaručeno, že objekt j e přístupn ý jen j í. V praxi se používají dva typy zámků: • X-lock (výhradní zámek, zámek pro zápis) • S-lock (sdílený zámek, zámek pro čtení) Jestliže transakce A umístí na položkup X lock ,je :l.ádost transakce B, která chce umísti t zámek na tutéž položkup odmítnuta. Jestliže transakce A umístí na položkup S lock, pak je žádost transakce 8: • o X lock na tuto položku odmítnuta • o S loek na tuto položku povolena Tuto strategii popisuje matice kom patibility :

I X lock I X lock ll N I Slock ll N I - ll y

l S lock ll N l y l y

ll y- I ll I ll y I ll y I

Máme položku p, transakce A jí má uzamčenou zámkem (hlavičky sloupců) a transakce B chce na tuto položku umístit zámek ( !.sloupec). znamená, že došlo ke konniktu a požadavek transakce B je

odmítnut, Y znamená , že transakce B byla úspčšná.

-


8

Uzamykací protokol : I. Transakce , která chce přistupovat (číst) k položce , si j i musí uzamknout S lockem 2. Transakce, která chce mčnit položku, ji musí uzamknout X lockcm (jestliže má ji ž tuto položku uzamčen u S lockem, musí ho změnit na X lock) 3. Jestliže je požadavek transakce B na uzamčení položky zamítnut (A má zámek), transakce přechází do čekajícího stavu, dohd transakce A položku neodemkne. Systém musí garantova l, že 8 nebude čekat věčně- požadavky na zámek mohou býl vefrontě (I . p1'ijde, I. obsloužen) 4. Zámky (X i S lock) jsou uvoln ěny na konci transakce (COMMIT nebo ROLLBACK)

Revize problémů V této kapitole zjistime,j akým způsobem uzamykací protokol vyřeší problém y paralelního zpracováni.

Ztráta aktualizace Transakce A: READ(x) S-lock x x := x-5

Transakce B: uzamkne a přečte x=80 vypočítá x=80-5 uzamkne a přečte x=80 vypočítá x=80+4 chce uzamknout x X-lockem čeká na uvolnění S-Iock x chce uzamknout x X-lockem čeká na u voln ěn í X-lock x

READ(x) S-lock x x := x+4 WRJTE(x) X-Iock x wait

WRITE(x) X-Iock x wait

( Transakce

1

( Transakce B

1

Žádná z transakci nemu že pokračovat ,protože čeká na uvolněni zámku . Zámky tedy přinesly nový problém DEADLOCK.

Dočasná aktualizace Transakce 8: Transakce A: READ(x) S-lock x x := x-5 WRJTE(x) X-Iock x chyba (ROLLBACK )

READ(x) S-Iock x waí t wait

uzamkne a přečte x=80 vypoč ítá x=80-5 uzamkne a zapíše x=75 chce uzamknout x S-lockem čeká na uvolnění X-lock x uvolněn X-Iock x (i S-Iock)

-


9

x := x+4 WRJTE(x) X-lock x

uzamkne a přečte x=80 vypočítá x=80+4 uzamkne a zapíše x=84

Transakce B

Transakce B musí čekat, až A uvolní zámek objektu , tzn. B vidí až potvrzenou zmčnu objektua tedy B není závislá na nepotvrLených hodnotách.

Nekorektní pou žití agregačních funkcí N a začátku máme v databázi na kontč I 40 000 Kč, na kontě2 50 000 Kč a nakontč3 30 000 Kč. Transakce A: 7i·ansakce B: sum=O sum =O READ(konto I) S-lock uzamkne a přečte konto I=40 000 sum=sum+konto I vypočítá sum=0+40 000 READ(konto2) S-lock uzamkne a přečte konto2=50 000 sum=sum+konto2 vypočítá sum=40 000+50 000=90 000 READ(konto3) S-lock uzamkne a přečte konto3=30 000 konto3=konto3- 10 000 vypočítá konto3=30 000- 10 000 WRITE(konto3) X -l ock uzamkne a zapíše konto3= 20 000 READ(konto I ) S-lock uzamkne a přečte konto I =40 000 kontol =kontol + JO 000 vypočítá konto I =40 000+ I O 000 WRITE(kontol) X -l ock chce uzamknout konto! X-lockcm wait čeká na uvol nění S-lock kon to I READ(konto3) S-lock wait chce uzamknout konto3 S-lockcm čeká na uvolnění X-lock konto3 wait wait


10

konto1

= 40000

konto2 = 50000 konto3

Transakce

=

30000

Transakce B

Také tato situace vede k dcadlocku. Deadlockjc situace, kdy se dvč nebo více transakcí nachází v čekajícím stavu a každá z nich čeká na uvolnění zámku jiné čekající transakce . Ukončení dcadlocku je možné provést pou ze výběrem jedné z čekajících transakcí ("občť deadlocku") a jejím ROLLBACKcm. Obět'deadlocku" může být vrácena, i když sama nemá žádnou chybu. Některé systémy takovou transakci automaticky znovu spoušti, jiné prostě pošlou hlášení o "oběti deadlocku" zpět aplikaci. Detekce dead l oc"-'U je možná například hledáním cyklů ve Wait For Group (kdo na koho čeká). V praxi se nemusi deadlock přímo detekovat, může se používat např . time-out mechanismus (transakce, která nepracuje předepsaný časje považována za deadlock).

Uspořadatelnost (Serializable) Uspořadatelnost definuje kriteria korektnosti paralelního zpracován. Tvrzení: M nožin a tran sakcí je považována za korektní,j estliže je u spořadatelná (serializable), tzn. dává tentýž výsledek jako nějaké sériové provedení těch to tran sakcí (spou štěných jedna po druhé).

Dzikaz tvrzeni: I. Individuá lní transakce je korektní (transformuje konzistentní stav db dojiného konzi stentního stavu) 2. Spouštění jedné transakce po druhé v sériovém pořadí je korektní (plati pro libovolné sériové pořadí), protože individuální transakce je nezávislá na ostatních . 3. Libovolné paralelní spuštěn i je korek mí, je- li ekvivalentní s nějakým sériovým spuštěním. Rozvrh určuje posloupnost spouštění dané množiny transakcí (proložcné nebo jiné). Spuštění transakcí vždy jedné v čase- bez proložení -sériový rozvrh. Rozvrh , který ncní sériový je proložcný (paraleln í).

-


Závěry:

• dva rozvrhy jsou ekvivalemní,jestli že dávají tentýž výsledek nezávisl e na původním stavu db • rozvrh je správný- uspořadatelný (scrial izable)- jest liže je ekvivalentní s nějakým sériovým rozvrhem Pfíklad:

transakce A - přidej I k x transakce B- zdvojnásob x (x j e ooložka z db. na počátku x = 10) - sériový rozvrh AB - x = 22, - sériový rozvrh BA - x = 2 1 Oba výsledky jsou správné, Každý rozvrh ekvi valentní s AB nebo BA je korektní. E j e rozvrh množiny transakcí Tl, T2, ...,Tn. • jes tl iže Eje uspořadatelný, pak existuje nějaký sériový rozvrh S transakcí Tl , T2 až Tn , který je ekvivalentní s E. o S neníjed inečný, múže existovat více serializací E • nechť Ti a Tj jsou dvč transakce z množiny T l až Tn o pokud Ti předchází J:j v rozvrhu S, pak v rozvrhu E musí také Ti předcházet Tj • charakteristická vlastnost uspořa datelnosti: o jest liže jsou A, B dvě transakce v uspořadatelném rozvrhu ,pak buď A předchází B nebo B předchází A -tzn. buď B vidí výstupy A nebo A vidí výstupy B o jest liže A updatuje položky p,q,r a B pracuje s některými z nich, pak je B vidí všechny zmčnčné A nebo je vidí před zmčnou A

Dvoufázový uzamykací protokol Jest liže všechny transakce splňují dvoufázový u zam ykací protoko l, pak jejich všechny možné "proložené" rozvrhy jsou uspořadatelné (seriazablc). Dvoufázový uzamykací protokol nemá nic společného s dvoufázovým commitem.

Transakce řídící se dvoufázovým uzamykac ím protokolem má dvč fáze- uzamykac í a odemykací , v praxi se často druhá fáze shrnuje do je dné operace COMM IT nebo ROLLBACK na konci transakce. Dvoufázový u zamykací protokol: • před operací s libovolným objektem musí být tento objekt uzamčen • po uvolnční prvního zámku nesmí transakce umíst i t žádný dal ší zámek • dvě fáze - uzamykací a odemykací

Nedvoufázové protokoly V případě nedvoufázového uzamykacího prototokolu potřebujeme znát doplňující informace o objektech databáze (např. fyzické uložen í, ...). Mezi ncdvoufázové protoko ly patří :

ll


• Stromové protokoly • Časová razí tka • Optimistické algoritmy

STROMOVÉ PROTOKOLY

Jsou vhodné pro hierarch i cké databáze nebo S-stromy (8-stromy se často využívají pro indexováni). Předpokládané operace: • READ(Q) - nalezení a přečtení listového uzlu s objektem Q • UPDATE(Q)- aktualizace stromu prostředn i ctvím objektu Q (dcletc, in sert) Bezpečn ý uzel S-stromu má • ménč než m-1 klíčů (pro INSE RT) • více než m/2-1 klíčů (pro DELETE) Nen í-J í uzel bezpečný, bude UPDA TE operace ovlivňova t předch ůdce tohoto uzlu (štěpení nebo slévání uzlů) . Protokol pro READ I . Umísti R lock do kořene S-stromu 2. Přečti kořen S-stromu do vyrovnávací pamčti (běžný uzel) 3. Whíle běžný uzel není list do begin umístí R-lock na následníka běžného uzl u uvoln i zámek uzlu běžného uzlu přečti následníka běžného uzlu end Protokol pro READ udržuje vždy jen jeden uzamknutý uzel v transakci. Protokol pro UPDATE I. Um ísti W lock do kořene S-stromu 2. Přečti kořen S-stromu do vyrovnávac í paměti (běžný uzel) 3. Whilc bčžný uzelncní list do begin umísti W-lock na následníka běžného uzlu přečti následníka běžného uzlu i f bčžný uzel j e bezpečný thcn uvoln i zámek všech uzamčených předch ůdců cnd Protokol pro U PDATE může mít více uzamčen ých uzlů. ČASOVÁ RAZÍTKA Základní m yšlenka:

P01
12


o označuje pro objekt X největší časové razítko transakce, která úspěšně provedla operaci WRITE(X) o ak tualizováno, kdyko liv dojde k přístupu k X o přiděluje jej operace TSW • Časové razítko pro čtení objektu X o označuje pro objekt X největší časové razítko transakce , která úspěšně provedla operaci REA D(X) o aktuali zováno , kdyko liv dojde k přístupu k X o přiděluje jej operace TSR

Transakce T VY''Oi á operaci WR ITE(X) a. ifTSR(X) > TS(T) then zruš T nějaká transakce s razítkem větším než TS(!)již četla X p1'ed tím, než T mělo možnost provést zápis X- narušuje pol'adí transakcí b. if TSW(X) > TS(T) then zruš operaci WRJTE(x) a pokračuj nějaká transakce s razítkem větším než TS(I)již zapisovala X aje nutné ignorovat WRJTE(X) z transakce T vlastně pl'edcházející aktuálnějšímu stavu X c. if nenastává a), b) then begín WRITE(X) TSW(x):=TS(T) end Kdykoliv nějaká transakce T zkouší vyvo lat operaci READ(x) nebo WRJTE(X), porovná se časové razítko transakce T s časovým razítkem pro čteni X i zápis X, aby bylo zajištěno , že pořadí transakcí dané jejich razítky není narušeno. Pokud je pořadí narušeno , musí být transakce T zrušena. Pak jeT znovu nabídnuta systému s novým časovým razítkem.

Transakce T vyvol á operaci READ(X) a. ifTSW(X) > TS(T) then zruš T nějaká transakce s razítkem větším než TS(T)již zapisovala X pl'ed tím, než T mělo možnost provést čtení X- narušuje pol'adí transakcí b. ifTSW(X) < TS(T) then begin READ(X) TSR(x):=max(TS(D,TSR(X)) end Stejný rozvrh je zpravid la možné získat i dvoufázovým uzamykacím protokolem . Nčkteré pro tokoly za lože né na časových razí tkách drží staré hodnoty aktualizovanýc h objektů (řízení paralelismu s vice vertemi).

OPTIMISTICK É ALGOR ITMY Neprovádí se žádná kontrola v průběhu transakce. Všech ny aktualizace se provádějí do lokálních kopii objektll a před koncem transakce se provádí fáze zjišťující, zda nebyla narušena uspořadatelnost.

Fáze algoritmu :< • Fáze čten í o čtou se potřebné objekty, o provádí se výpočty, o provádí se aktuali zace do dočasné pamět i

• Fáze ko ntroly platn osti o určuje se, zda operace dané transakce nejsou v konfliktu s operacemi jiných transakcí. o PoJ..'Ud ano, dočasné aplikace WRJTE j sou zrušeny a transakce je restartována. o Kontroluje , zda existuje transakce , která začíná fázi zápisu po začátku čtení transakce T, ale před začátkem fáze kontroly platnosti T. Zároveň některé objekty, které tato transakce zapisuje musí být objekty, které T čte. Pokud ex istuje- došlo ke konfliktu.

• Fáze zápisu

13


o Projde-li kontrola ,jsou provedeny všechny WRITE do databáze

Doporučená literatura :

Pokorný J. .- Databá zová abeceda, Date C.J. - An introduction to database systems

14

-

PROSTŘEDKY FRONT-END

v

PROSTREDKY FRONT-END Po absolvovátú přednášky Prostředky front-end budeme umčt • vysvětl it mechanismus prostře.dkí'• front-end • vyjmenovat typy prostředků front-end • charakterizovat jednotl ivé typy prostředků fron t-cn d

Mechanismus práce prostředků front-end Databázový systém , ve kterém budou data pouze uložena , ale který k nim neumožní přístup, n emá praktický význam . Proto producent databáze spolu s ní zpravidla dodává interaktivní nástroj pro správce databáze a prostředek front-cnd pro koncového uživatele. Síla systémů CI S je ale skryta ve velkém množství použite lných klientských aplikací a software pro jejich vývoj od nezávislých producentů. Aplikace front-end m ůže být nějaký standardně komerčně dostupn ý software, nebo může být pro určitého uživatele specicl ně vytvořena . V každém případ č klientská aplikace vypadá a pracuje jak o každá jiná apl ikace, kterou má uživatel nainstal ovánu na svém počítači. Skutečnost, že přistupuje k datům na databázovém serveru, pozná uživatel pouze z toho, že musí uvést své uživatelské jméno a heslo. Posloupnost zpracování dotazu j e zachycena na následujícím schématu {tennínem dotaz budeme pro jednoduchost označovat libovolnou operaci s databází - např.aktualizaci dat, vkládáni nových dat, rušení, vyhledáni údajů apod.):


I. Nejprve uživatel vytvoří dotaz. Dotaz může být ad-hoc (operativně vytvořený uživatelem podle aktuální potřeby) , nebo mítže uživatel použít předprogramovaný dotaz, který je součásti aplikace front-end. 2. Aplikace front-end zformátuje dotaz do jazyka SQL používaného serverem a vyšle jej po síti na server. 3. Server nejprve ověří , zda má uživatel právo přisntpovat k požadovaným datům. 4. Pokud má uživa tel právo pracovat s požadovanými daty , setver zpracuje dotaz a pošle odpovídají cí data zpět aplikaci front-end. 5. Klientská aplikace obdrží odpovčď a zformátuje ji do tvam vhodného k zobrazení pro uživatele. 6. Uživatel vidí odpověď na obrazovce a může s daty manipulovat Obecně neplatí, že jedna aplikace front-end může zpracovávat data z databázového serveru libovolného producenta. Ačkoliv mechanismus práce prostředků front-end je velmi jednoduchý ,univerzální aplikace by musela vy řešit velmi zásadní problém - rozdíly v SQL jednotli vých producentů . Přestože existuje řada standardů SQL, které se stále zdokonalujíjednotliví producenti SŘBD plidávají k SQL vlastní doplňky. Výsledkem je , že verze SQL nemusí být kompatibilní s verzemi jiných producentů. (Podrobnějise s touto probl ematikou sez námíme v kapitole věnované replikacím a ODBC.) Aplikace front-end je možné rozdělit do čtyř obecných kategorií : • přídavné modu ly k existujícím produktům , • nástroje pro vývoj aplikací

• programy pro zadáválli dotazů a tvorbu sestav • nástroje pro gl obální analýzu dat.

2

PROSTREDKY FRONT-END

Zařazení produktu do kategorie nemusí být jednoznačné , řada produktů může patřit do více kategorií.

l.Jaká je posloupnost zpracováni uživatelova požadavku na data klientskou aplikaci?

Přídavné moduly k existujícím produktům Většina přídavných modu l ů k existujícím produktům se vztahuj e k databázím na PC- většina klientských systémů jsou PC. Producentům databází pro PC záleží na tom , aby jejich produkty byly užitečné i po přechodu zákazníka na architekturu C/S, a proto své systémy doplňuj í přídavnými modu ly pro přístup k databázím C/S. Přídavné moduly k databázím pro PC u snadňuj í vývoj ářům systém l't C/S integraci stávající databáze (na PC) do vytváře ného systému. Náklady na vývoj aplikací front-end mohou být nižší , protože uživatelé i programátoii existující databázi znají. S malým zaškolením mohou uzpůsobit své pracovní postupy tak, aby mohli pracovat s daty na serveru. Databáze na PC jsou jednou z nejvšest rann ěj ších aplikací front-end a mohou jistým způsobem plnit roli všech čtyř kategorií. Většina databází na PC má uživatelsky příjemné ovládání. Jejich integrované prostředí umožňuje pomocí různých návrháiů tvorbu dotazů i ti skových sestav. Velmi často obsahují i prostředky pro programování aplikací. Pfídavné moduly k existujícím systémům obvykle vyžaduj í více zdroj ů - například RAM než produkt navržený přímo jako aplikace front-end. Větší náročnost na zdroje je způsobena nutností přek ladu dotazů a odpovědí do potřebného formátu. Přídavn ý modu l musí nejp1ve přeložit požadavek z jazyka používaného uživatelem nebo z příslušného menu do SQL. Až se data vrátí , přeloží přídavný modul odpověď do fonnátů odpovídajícího příslušné aplikaci. Operace navíc také prod lužují dobu odezvy mezi aplikací front-end a databázovým serverem. Přídavné moduly k existujícím produktům mohou být nejlépe využity jako dočasn é řešeni, než jsou vyvinuty nové aplikace front-end a předvedena data z databází na PC do databázového serveru.

2. Jaké jsou nevýhody přídavných moduhi k existujicím produkttim?

Nástroje pro vývoj aplikací Většina producen tů SŘBD C/S dodává nějaký nástroj pro tvorbu uživatelských aplikací . Tyto nástroje jsou však obvykle omezeny na tvorbu aplikací pro SŘBD příslušného producenta.

3


4

V posledním desetiletí vyvinuli nezávislí producenti nástroje , které je možné pou žít k tvorbě likací pro l< da databázových serven1. Rada programovacích ja zykl'• má integrovány prostředky podporující tvorbu databázových apl ikací. Exisntjí knihovny, které mohou programátoři použít pro zajištění přisn1pu svých aplikací k datům na serveru.

Programy pro zadávání dotazů a tvorbu sestav Programy pro zadávání dotazů atvorbu sestav jsou n ástroje pro koncové uživatele. Jejich cílem j e umožnit pří ležitostným uživatelům a neprogramáton•m přístup k datům v databázi C/S. Tyto front-end aplikace nemají obvykle svůj vlastní programovací j azyk, mohou však obsahovat jazyk pro tvorbu příkazovýc h souborů nebo makrojazyk. Makrojazyk zaznamenává posloupnost kláves a umožňuje tak automatizovat běžné dotazy pro pozdější použití. Dotaz je možné také uložit do soubom a v prípadě potřeby jej spustit znovu.

3. Jak se liší cílové skupiny používající nástroje pro vývoj aplikací aprogramy pro zadávání dotazti a tvorbu sestav?

Nástroje pro globální analýzu dat Gl obální analýza dat probíhá ve dvou fázích. V první fázi si uživatel vyžádá data z různých zdrojLl a ve druhé fázi data kombinuje a analyzuje jejic h význam. Globálně analytické nástroje jsou určeny ke sběm dat z různých míst v organizaci a prezentaci informací vedoucím pracovníkům. Získané infonnace pomáhají managerům provádět komplexní rozhodnutí. Tyto aplikace mohou být použity i pro statistické a vědecké studie, analýzu trendů apod.

Doporučen á H teratura : Salemi J. -Databáze kl ient/server , str. 1 75-205

Řešení úkolů: I.

Uživate l zformuluje dotaz- prostředek front-end pošle dotaz SŘBD na serveru - server

PROSTREDKY FRONT-END

ověří uživatelova přístupová práva , zpracuje dotaz a pošle odpověď zpět prostředku front end- prostředek fron-end zpracuje odpověď a zobrazí ji uživateli.

2. Přídavn é modu ly k existujícím systémům vyžadují více RAM než na klíč vytvářená apl ikace front-cnd . Zpravidla je i delší doba odezvy mezi aplikací a databázovým serverem . Pokud má aplikace front-cnd realizovat nějaké speciální funkce, může být její tvorba s využitím přídavných modulů značně obtížná.

3. Nástroje pro vývoj aplikací používají programátor; tvolící nové front-end aplikace a program y pro zadávání dotazi'1 a tvorbu sestav využívají koncový uživa telé.

5

-

Replikace dat

REPLIKACE DAT Po absolvovátú přednášky Replikace dat budeme umět • • • • • •

vysvětlit rozdí l mezi centralizovaným a distribuovaných řešením definovat pojem replikace vysvětlit princi p replikace zdůvodnit, proč je replikované řešení výhodnější než cenn·alizované popsat jednotlivé formy replikací a zhodnotit je z hlediska náročnosti na systém vysvětlit funkci ODBC

Distribuované DBS Tradiční informační systémy byly vytváře ny centralizovaně. Činnosti spojené s ukládáním a zpřístupňováním dat, zajišťováním jejich bezpečnosti a integrity provádělo jedno výpočetní středisko. Uživatelé přistupova li k systému prostřednictvím lokální (LAN) nebo rozsáhlé sítě (WAN). Centralizované systémy mají řadu výhod, ale i nevýhod. Jsou : • pomalé • nespolehl ivé • drahé Změny v organizačních strukturách podniků vedou organizace k přechodu na distribuovaná řešení. Mnoho organizací decentralizovalo svoji činnost do oddělených poboček nebo se spojilo sjin ými organizacemi do větších celků.

1. Vporovnání s jaf...ými systémy a za jakých podmínek jsou centralizované systémy pomalé, nespolehlivé a drahé ?

Replikace Pojem replikace označuje kopírování dat z databáze do ví ce míst. Kopie v jednotlivých místech se nazývají repliky. V případě replikace musí být zajištěno, že pokud dojde ke změně jednoho řádku rel ace v jedné replice, musí se odpovídajícím způsobem zmčnit tento řádek i ve všech ostatních replikách. Replikace poskytuje uživatelům lokální aktualizované kopie dat. Replikace má řadu výhod.

Replikace dat

Je efektivnější mít potřebná data replikovaná v místč zpracováni dotazu než provádět spojení tabulek rozmístěných v několika místech sítě. Jiným vhodným způsobem využití je zálohovánív reálném čase, kdy je na jiném místč udržována kopie databáze (ncbojcjí části). Replikovat je možné j ednotlivé tabulky nebo část databáze, která vznikne jako výsledek dotazu. Výsledek dotazu je zpravidla kopie read-only, resp momemka (snapshot).

Momentky jsou výsledky dotazu, do kterých se periodicky promítají aktualizace řízené :z jednoho místa. Jednotlivá místa mohou momentku číst, ncmají jí ale právo aktualizovat. Nejčastěji se používají momentky pouze nad jednou tabulkou. Replikace umožňuje napřík l ad: • zvýšení dostupností dat- kopie dat jsou přímo uloženy v různých místech sítč, případný výpadek jednotlivých míst nebo komunikační sítč nebrání v činnosti zbytku systému • zvýšení rychlosti a propustnosti aplikace- použití lokálních dat snižuje síťový provoz • omezenější provoz sítě • zajištění kompletní nezávislost- každé z míst může spravovat svá vlastní data • levnější přístup k distribuovanému zpracování dat. Velký rozvoj rcplíka ční technologie začíná v období ,kdy se architektura C/S rozšířila do prostředí podn iků rozmístěných v několika geografických místech. Koncem roku 1995 se u známých výrobců SŘBD objevily rcplikační seivCI)'. Replikační server podpomje vytvářen í a automatickou synchronizaci kopií dat. Tyto sc•ve•y jsou navrženy pro práci v prostředí globálnich sítí (WAN) a umožňují replikovat data mezi datovým i zdroji 1ůzných SŘBD (heterogenní prostředí). Úkoly replikačního servem: • • • • • • •

popis replikovaných dat a procedur doprava replikovaných data na místo, kde jsou potřebná a když jsou potřeba inicializace dat v replikovaných tabulkách přenos změn primárních tabulek do replikovaných kopií ochrana integrity dat synchronizace všech kopií po chybě záznam nedokončených transakcí

Jednim z důvodů pro vznik replikovaných systémů j e nutnost oddělení on-line aplikací (OLTP- On Line Transaction Proccssing) od aplikací poskytujících syntetické informace pro podpom managementu (DC - Deci sion Support). V OLTP aplikacích se využívá velký počet transakcí , které mění několik z.áznaml! současně. V OLTP aplikacích je minima lizován čas, po který zůstává transakce otevřená, aby nedocházelo k uzamykaní ostatních spuštěných transakcí a tím k sni žováni propustnosti systému. V DS apl ikacích se využívají velmi často read-only dotazy čtoucí ohromná množství dat. Tyto dotazy velmi často provádí spojení více tabulek a spouští složité výpočty zatěžující datový server. Oddělení OLTP a DS na 1ůzné datové servery má pozitivní vliv na celkovou propustnost a dobu odezvy aplikací. OLPT aplikace mohou pracovat s p1imámími daty, zatímco OS

2

Replikace dat

3

aplikace budou pracovat nad jejich replikovanou kopií.

2. Proč se využívá replikování databáze?

Formy replikace Replikace je možné provádět několika způsoby. M ůžcme je klasifikovat například vzhledem k možnostem aktualizace: • jeden aktualiz uje (jednosměrné systémy) o právo aktualizovat má jeden uživatel (nebo skupina uživatelú) nad jedním zdrojem) o replikace je podporována distribucí read-only kopií o nenastávají problémy s konflikty p!i nezávislých akn.alizacícb kopií dat (není možné je provádět) o mohou nastat problémy s vý konem (pokud jsou pro aktualizace kopi í nutné transf01macc dat, nebo pokud jsou místa obsahující kopie heterogenní)

místo 1 primární kopie

místo 4 replika

místo 2 replika

místo 3 replika

• několik aktualizuje (obousměrné, symetrické systémy) o podobná situace jako při běžném zpracování transakcí o u asynchronního replikačního systému není k dispozici žádný uzamykací mechanismus , proto mohou vznikat kolize

Replikace dat

4

místo 1 replika

mlsto 4 replika

místo 2 replika

místo 3 replika

Klasifikace podle objemu přenášených dat: • rychlá o do repliky se promítají pouze skutečné změny dat • úplná o celá replika se nahradí novější verzí Místo, odkud je iniciována zmčna , se nazývá vydavatel(publisher). Místo, které přijímá změnu replikované databáze se nazývá předplatitel (subscriber). Je možné rozlišovat přístup peer-to-peer, kdy aktualizace může být provedena v libovolném místě sítě a změna je propagována do všech ostatních míst. V přístupu master-slaveje nutné nejdříve aktualizovat ptimární kopii dat. V přístupu peer-to-peer mohou u každého typu aktua l izační operace nastat na vzdá lených místech kol ize: • operace INSERT - při vkládání řádku do tabulky muže dojít ke konfliktu s primárním klíčem , pokud řádek s daným klíčem v tabulce už existuje • operace DELETE - řádek již mohl být dříve odstraněn, nebo byl zmčnčn potom, co byl odstraněn z místa vydavatele • operace UPDATE- řádek již byl odstraněn , nebo změněn, nebo nové hodnoty narušují omezení primárního klíče. Replikační server : • musí oznámit kolizi v okamžiku jejího výskytu • udržovat pro každou potvrzenou transakci žumál pro všechny procesy , které se dostanou při propagaci této transakce do dalších míst. Replikační server muže pro řešení kolizí použí vat různé strategie: • • • •

prioritu má počáteční aktualizace, na pozdější transakce je uplatněn ROLLBACK prioritu má poslední aktualizace, dojde k přepisu dřívějších aktualizací kolize se řeší spuštěním uživatelem napsaného triggeru replikační proces se pozdrží a zašle se zpráva správci disnibuované databáze.

Replikace dat

3. Ja/..ým zptisobemjsou data nejčastěji replikována?

Lokální a vzdálené replikace Replikace se může nacházet na tomtéž serveru, kde je primární kopie, nebo může být umí stěna na jiném serveru v lokální síti. Rovněž se ale může nacházet na vzdáleném servem. Lokální replika ce j sou replikace v rámci jedné LAN a zpravidla umožňují pouze jedno směrný tok dat z primárního datového servem na replikovaný. Jsou tvořeny komponentami:

• datový server pro primární OLTP data • datový server pro replikovaná DS data • LTM (Log Transfer Manager) pro indikaci změn primární databáze a přenos na rcplikační server • RS (Replicati on Sen,er) pro přesměrování a uplatn ění replikovaných transakcí mezi primámí a replikovanou databází Změny dat lze provádět jen na primární straně, tzn . na datovém servem určeném pro OLTP aplikace. LTM čte transakční log primární databáze a informace o změnách tabulek předává replikačnímu servem (RS),aby je aplikova l na příslušné tabulky replikované databáze. Vzdálené replikace se používají v rozsáh lých podnikových sítích ,kdy uživatelé nemohou pracovat v rámci jedn é LAN. Místo centralizovaného databázového systému je možné pomocí rcplika čního serveru udržovat na různých místech WAN repliky dat. Vzdá lené replikace mají oproti centrá l nímu zpracování několik výhod: • redukce zatížení centra • výpadek W AN neovlivní jednotlivé apli kace • vyšší rychlost aplikací

4. Jaké komponenty se up/atJízl}í pli replikacích?

ODBC Zpracovávaná data mohou být uložena a zpracovávána různými SŘBD (MS SQL Server, I nformíx , Oracle, Progress,...). K těmto datům potřebujeme přistupovat z tůzných front-end aplikaci a v některých případech je nutné, aby jedna front-end aplikace přistupovala k různým datovým zd rojům . Větš ina SŘDB má implementováno SQL, jednotlivé databáze se ale liší dia logem SQL, které použ ívají. V SQL databáze také zpracovávají tůzně některé základní prvky (například používají různé označení pro datové typy - character, cbar, ...). Naprostá většina SŘBD má své vlastní programové prostředky , které umožňují vytvářet

5

Replikace dat

aplikace front-end. ODBC (Open DataBa se Connectiv ity) je jednotné API prostředí umožňující různým front end (Access, Vi sual FoxPro, Deplhi , ...), apli kacím piístup k datům na 1ůznýcb back-cnd serverech (MS SQL Server, Inforrnix , Oracle, Progress,...).

Architektura ODBC se skládá :z těchto komponent: • • • •

apl ikace správa driverů drivery zdroje dat

Aplikace používá ODBC k poslání plíkazů SQL na back-cnd server a k přcvzeti výsledků . Aplikace zajišťuje vytvoření spojení na zdroj dat, definici příkazů SQL, převzetí výsledků nebo chybových zpráv , ukončení transakce (COMMIT nebo ROLLBACK) a odpojení od zdroje dat. Správce driverů organizuje přístup k ODBC driverům. Zavádí potřebný driver a předává funkce ODBC volané z aplikace . Správce driverů naleznete v systému Windows (Start Nastavení -Ovládací panely). Driver provede funkci ODBC poslanou aplikací . Vytvoří spojení ke zdroji dat, převede piíkaz SQL do dialektu zdroje dat, provede příkazy SQL a předá výsledky nebo chybové zprávy aplikaci. Pro každý zdroj dat musí být k dispozici jeho driver. Zdroj dat je back-end s daty , který zpracuje požadavek od driveru a vrátí výsledek.

6

Replikace dat

Aplikace vždy komunikuje se správcem driverů, nikdy se neobraci přímo na driver nebo zdroj dat. Správce driverů komunikuje pouze s aplikací nebo driverem a neoslovuje zdroj dat. ODBC definuje standardní SQL gramatiku (standard SQL pro tůzné databázové formáty) . Tento přístup dovol uje oddělit logiku programu od zdroje dat. Změní-li se datové zdroje, stačí správce driveri't přesmčrovat na j iný zdroj. Úrovně syntaxe ODBC SQL: • minimální- měli by ji podporovat všechny drivery , obsahuje příkazy o CREATE TABLE, o DROP TABLE, o SELECT, o INSERT, o U PDATE, o DEL ETE • core - podporuje ji většina driverů, obsahuje příkazy z minimální úrovně + o CREATE INDEX o DROP INDEX o CREATE VIEW o DROP VTEW o GRANT o R EVOKE o SELECT +agregač ní funkce, rozšířené typy dat • cxtcndcd- příkazy corc úrovně+ o outer join (vněj ší spojení) o SELECT FOR U PDATE o UN ION Při použíti minimální úrovně je možné v apli kaci střídat různé zdroje dat.

7

Replikace dat

5. K čemu se mzižete použít ODBC ?

Doporu čená literatura: Pokorný J. .- Databázová abeceda, str. 149- 152 Date C.J.- An introduction to database systerns, str. 593-622 Plecháč V.- Klient/server ODBC

Řešení úkolů: 2.V plípadě replikovaného řešení jsou data snáze dostupná na všech místech zpracovaní a přitom n ejsou kladeny pří lišné požadavky na provoz sítě.

3.Nejčastěji jsou data repl ikována j ednosměrně , protože v tomto případě není nutné řešit kol i zní stavy.

4. Datový server pro primární OLTP data,datový server pro replikovaná data, Log Transfer Manager, replikačn í server

5. Při tvorbě aplikace front-end.

8

4. února 2012 12:40

Transakční zpracování

2

Transakce musí skončit v konečném čase. Transakcese buď provede celá,anebo vůbec. Ideální případ,kdy se provedou všechny operace transakce ,nelze zaj stit (např.systém spadne mezi dvěma operacemi). Transakční zpracování ale zaručuje,že pokud nebyla celá transakce úspěšně dokončena (zhroutila se z důvodu nějaké chyby) budou všechny změny, které provedla,vráceny zpět. Proto lze na transakci pohlížet j ako na atomickou operaci. Příklad: PotFebujeme změnit číslo čtenáFe v tabulce CTENAŘ. Každý čtenáf mtiže mít vyptijčené nebo rezervované nějaké knihy. Pokud bychom provedli pouze změnu čísla čtenáPe v 1abulce CTENAŘ, ale nezměnili tolo číslo čtenáPe v odpovídajících záznamech labulek VÝPŮJCKY a REZERVACE , z tistaly by nám v 1abulkách záznamy bez pl amé identifikace členáPe. V lom/o prípadě by nešlo určil, kdo má knihy vyptijčené. Pro/oje poli'eba provést všechny změny současně a pokud se některou provéslnepodaN, nesmí se provésl žádná z nich. Begin_transaction Změna_čísla_čtenáře begin input(staré_číslo, nové_číslo) read(temp, ČTENÁŘ.Č_ČT = staré_číslo) if temp = empty then begin output("čtenář neexistuje") ROLLBACK end else begin modify(ČTENÁŘ,staré_č íslo, nové_číslo) modify(VÝPUJČKY ,staré_č íslo, nové_číslo) modify(REZERVACE ,staré_číslo,nové_číslo) end end_transaction

(1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13)

Operace begin_transaclion (BOT, START) a end_transaclion (EOT) označují začá1ek a konec /ransakce , lzn.mnoiina pNkaz1 mezi řád/..J ' (1) a (13) se chápejako atomická operace. Operace ROLLBACK (ABOR7; EXIT) zaslavuje běh transakce. Da tabáze se po ní musí uvést do p1ivodního stavu. Operace(/)- (13)převádějí dalabázi z jednoho konzislenlního stavu doj iného konzistentního stavu, v pn běhu zpracován konzistence zajištěna není (9)-(1/). Pozn. Operace read (4) a modify (9-1I} mohou být implementovány pomocí hostitelské verze SQL. Jak jsme si ukázali na příkladu,transakce začíná příkazem BEG!N TRANSACTION a končí příkazem COMMIT nebo ROLLBACK. Příkaz COMMlT (potvrzení) signalizuje úspěšnost provedení transakce. Příkaz COMMIT může být vygenerován pokud:


• Všechny změny provedené programem (transakcí) byly potvrzeny - tzn. jsou perzistentní (uložené ) a vidi telné ostatním transakcím, • Zámky na všechny databázové prvky by ly uvoln ěny. Příkaz COMMIT potvrzuje, že databáze je konzistentní. Jestliže je transakce potvrzená, systém garantuje, že změny jsou permanentně uloženy v databází ncovlívní je žádná další chyba. Naproti tomu příkaz ROLLBACK signalizuje, že databáze je nekonzistentní a musí být navrácena zpčt do stavu před BEGLN TRANSACTION. Aby bylo možné vrátil databázi do předchozího stavu, používá se log file(deník transakcí, žurnál). Log liJ e obsahuje historii všech změn databáze (všechny UPDATE operace nad daty). Log je uložen na pásce nebo disku. Při nutnost i provést navrácení do původního stavu (UNDO) systém použije odpovídající log k obnovč zmčnčných objektů na původní hodnoty. V praxi se log skládá ze dvou částí aktivní (on-line- d isk) a archivní (off-line- páska). Pokud dojde k chybě systému po COMMITu , ale před fyzickým zápisem dodatabáze (změny jso u v pamčťovém bufferu, ale j eště nejsou přeneseny na disk), musí systém restarovat proceduru zaznamenávající provedené změny do databáze - pomocí logu (ten musí být fyzicky uložen před COMM!Tcm).

1. Co znamená tvrzení, že databázeje konzistentní?

1 2. Coje transakce? ACID vlastnosti V souvislosti s transakcemi se velmi často hovoří o vlastnostech ACID. ACID je zkratka prvních písmen čtyř anglických slov: • • • •

Atomicity Consistency lsolation Durability

Atomicity (atomicita) znamená, že transakce jsou atom ické. Transakce musí proběhnou buď celá, nebo vůbec ne. S atomicitou transakce souvisí zotavení z chyb, např. příkaz ROLLBACK. Con sístency(konzistence) znamená , že transakce transformuje databázi z jednoho konzistentního do jiného konzistentního stavu. V průběhu prováděni transakce nemusí být databáze konzistentní. lsolatíon (izolace, nezávislost) znamená,že transakce jsou navzájem nezávislé. Dílčí efekty transakce nejsou vid ite ln é jiným transakcím, každá transakce v idí databázi jen v konzisten tn ím stavu. Durabítity (trvalost) znamená, že jednou potvrzená transakce je trvalá.

3


Efekty potvrzené transakce jsou uloženy dodatabázc.

3.Jak é vlastnosti transakce charak/ erizuje zkra tka ACJD ?

"' , , , TransakCOl zpraCOVaDI Transak ční zpracování je základem systémového

řešení zotavení z chyb.

Architekturu transakčního zpracování v charakterizuje obrázek:

V transakčním zpracování tedy figurují: • aplikačn í pr ogram • m a n ažer tran sa kcí - vyvolává transakce a prostřednictvím rozvrhovače posílá požadavky na data manažeru dat. • rozvrhovač - řídí paralelní zpracování transakcí , zajišťuje transparencí para lelního zpracování. • m a n ažer dat- zajišťuje komunikací s databázi (čtení a zápis dat), zodpovídá za zotaveni z chyb systému. • d atabáze Transakční manager zajišťuje atomicitu operace: • COMM IT- signalizuje úspěšné ukončení transakce , že databáze je v konzistentním stavu a zmčny mohou být pennancntní a viditelné ostatním transakcím , ncní nutné explicitně vyvolávat, stačí normální ukončení transakce • ROLLBACK - signalizuje neúspěšné ukončení transakce, databáze je v nekonz istentním stavu a všechny změny provedené logickou jedno tkou práce musí být vráceny zpět

4. Co se musí provést po vyvolání příkazu ROLLBACK ?

Zotavení systému Systém musí být schopen zotavení nejen z lokálních (např.přetečení jedné transakce) ale i z globálních chyb (např. výpadek napájení). Druhy chyb: • Loká l ní chyba je chyba, která má vliv pouze na tran sakcí , v níž se projevila . • Globá ln í chyba má vliv na všechny právč spuštčné transakce. o chyba systému (např. napájení)- ovlivní všechny spuštěné transakce, ale neznamená fyzícké nebezpečí pro databází = soft crash o chyb a m éd ia (např. disku) - znamená nebezpečí pro samotnou databázi nebo její část =

4


5

hard crash Kritickým bodem systémové chyby je ztráta obsahu hlavní paměti (ztráta bufferů). Vše co bylo v okamžiku chyby v operační paměti, je ztraceno. Všechny transakce probíhající v době chyby musí být vráceny po restartu systému zpět (UNDO), protože nevíme v jakém byly stavu ajaké provedly zmčny. A dále je třeba provést REDO (dokončení) všech transakcí, které byly v okamžiku chyby úspěšně dokončeny, ale jejich změny nebyly přeneseny z databázových bufferů do databáze.

Jak systém pozná, které transakce m á REDO a které UNDO ? Pro obsluhu zotavení z chyb používá systém log filc. Do logu je zapisují všechny U PDATE operace provedené nad databázi. V předepsaných intervalech (např. po určitém počtu zápisů do logu) generuje systém checkpoint record (kontrolní záznam), který zahrnuje: • fyzický zápis obsahu databázových bufferu do fyzické databáze • fyzický zápis checkpoint recordu do fyzického logu (seznam všech právě spuštěných transakcí) Náslcdující obrázek ilustruje tuto situaci: V čase tc byl generován checkpoint record a v čase trdošlo k chybě systému. Transakce může být v jednom z následujících stavů:

!!!!!!!!!!

iifiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiOi tfciiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii .il

chKkpoint

• Tl -ukončena před časem tc • T2- začala před tc a v čase trje již ukončena

• D- začala před tc ale v čase trnení ukončena • T4 - začala po tc a v čase trje již ukončena

• D - začala po tc ale v čase trncní ukončena

Transakce: + dokončená a zapsaná dokončená. nezapsaná + nedokončená

-


Po restartu systému budou transakce T3 a T5 vráceny zpět (UN DO) a T2 a T4 provedeny znova (REDO). Systém použije následující posloupnost operací: • Vytvoří se dva seznamy transakcí UNDO a REDO . • Do seznamu U DO se uloží všechny transakce z checkpoint rccordu (v příkladě T2,T3), REDO bude prázdný . • Začne prohledávání logu od tc dopředu. • Pokud se narazí na začátek další transakce, přidá se do seznamu UNDO (T4, TS) • Je-li v logu nalezen COMMIT transakce , převede se transakce ze seznamu UNDO do seznamu REDO (T2, T4). • Na konci žurnálu obdržíme dva seznamy o UNDO - T3, T5 o REDO- T2, T4 • Ny ní je možné provést vlastní zotavení z chyb o zpětně se prochá zí log a provádí se rušení operací transakcí z UNDO seznamu, po dosažení tc se postupuje opět dopředu a znovu provádí se operace transakcí z REDO seznamu

Pozn ámka :

Existují dva druhy logfl!ti: • s odloženými realizace změn- všechny wrile operacejsou odloženy do okamžilat porvrzení transakce, zaznamenávají se do logu, do databáze se zapíší až v okamžiku potvrzení • s bezprostfednf realizací změn - všechny wrile operace se provádí pffmo do databáze

I s.

K čemu se využívá deník transakcí?

Z0tave01,IDe'd"ll'Po chybě médií (např. chyba řadiče disku, chyba disk.hlavy, .) může být nějaká část databáze fyzicky poškozena. Zotavení v tomto případě znamená přehrání (obnova) celé databáze ze záložní kopie (nebo dumpu) a využití logu k opětovnému provedení všech transakcí, které byly uskutečněny po vytvoření záložní kopie. UN DO transakcí není třeba provádět, protože definice všech zmčn tčchto transakcí byla také ztracena. N u tnost vytváření zálož ních kopií - kopie m ůže být uložena např. na pásce, není nutný přímý přístup .

Dvoufázový COMMIT Dvoufázový potvrzovací protokol se používá pro transakce, kte ré mají interakci s několika zdroji dat, z nichž každý má vlastní log (distribuované prostředí). V distribuovaném prostředí je transakce úspěšná pouze tehdy ,jestliže jsou všechny její UPDATE operace na všech databázích potvrzené . Při chybě v libovolné databázi musí být všechny UPDATE operace vráceny zpět.

6

-


Koordinátor - systémová komponenta , řidi COMM I T či ROLLBACK na zák ladě garance managerů jednotlivých zdrojů Dvě fáze: I. Každý participujíci proces (manager každého zdroje dat) musí fyzicky zapsat všechny zmčny týkajíci se lokálního zdroje dat do vlastního fyzického logu 2. Když má koordinátor odpovědi od všech částí , provede zápis do svého vlastního logu všechny OK - COMMIT, nějaká Not OK - ROLLBACK o závěru informuje koordinátor všechny části a každá musí provést pod le jeho pokynu buď COMMIT nebo ROLLBACK Přechod mezi fázemi je tvořen zápisem do logu koordinátoru. Při chybě systému restmtovací procedura h ledá závěr v logu koordinátora, když jej nalezne pokračuje tam, kde byla transakce přerušena , jinak předpokládá ROLLBACK.

Doporučená literatura: Pokorný J.. - Databázová abeceda, str. 57-60, 65-69, 187-190, 2 17-220 Date C.J. - An introduct ion to database systems, str. 374-390

Řešení úk ol ů: 1. Databáze je konzistentní , pokud splňuje všechna integritní omezení definovaná ve schématu databáze.

2. Transakce je logická jednotka práce, posloupnost operaci, která transformuje databázi z j ednoho konzistentn ího stavu do jiného konzistentního stavu.

3. A - atomocita, C - konzistence, I - nezávislost , O - trvalost

4. Po ROLLBACKU se s pomoci log filc musí zrušit všechny změny dat, které transakce provedla.

7

-

VYHODY A NEVÝHODY SYSTEMU C/S

,

,

VYHODY A,NEVYHODY o SYSTEMU C/S Po absolvováni přednášky Výhody a nevýhody systémů C/S budeme umčt • • • •

vyjmenovat základní varianty architektury C/S objasnit,v čem spočívá rozdíl mezi tčmito architekturami vysvětlit výhod y a nevýhody architektury C/S charakterizovat platformy , na nichž jsou systémy C/S provozovány

Základní varianty architektury C/S Hledisek pro klasifikování jednotlivých variant architektury C/S existuje celá řada. Systémy je možné posuzovat podle platforem , na nichž je spuštěn front-end a back-end . Dalším možným h l ediskem je posuzování vari ant podle rozdělení práce mezi klienta a server. Každá databázová aplikace je tvořena ze tří základních komponent: • uživatelské rozhraní (GUI) • aplikační funkce • správa dat. Uživatelské roz hraní zajišťuje komunikaci s uživatelem. Zprav idla sestává z obrazovek obsahujících ovládací prvky (nabídky , ...) a oken sloužících pro zadáváni , prohlížení a manipulaci s daty . Aplikační funk ce tvoli vlastní jádro aplikace a správa dat zabezpečuje vlastni uchování dat v systému. Zpracování jednotliv ých komponent může probíhat buď na serveru nebo na klientovi. Z hlediska rozdčlcni zpracováni pak můžeme rozlišovat pčt variant: • • • • •

Tnte1face Distribution lntcrfacc Separation Application Distribution Data Separation Data Distribution .


2

KLIENT

• lnterface D•stribut1on • lnterface Separation • Aplication D1strlbutfon

• Data Separatlon • Data D•stribution

SERVER

Interface Distribution - distribuce uživatelských funkcí. V této variantě architektury C/S probíhá naprostá většina zpracování na serveru. Na serveru běží správa dat, aplikační funkce i část uži vatelského rozhraní. Na klientovi běží jen část funkcí uživatelského rozhraní . Tnterface Separation - oddělení uživatelských funkcí -je varianta architektury C/S, v níž je na klientovi spuštěno uži vatelské rozhraní. Aplikační funkce i správa dat běží na serveru. Application Distribution -distribuce uživatelských funkcí -je nejuniverzálnější a nejrozšířenější varianta. V tomto případě je na klientovi spuštěno uživatelské rozhraní a na serveru správa dat. Aplikační funkce jsou rozděleny a část jich bčží na klientov i a část na serveru. Data Separation - oddělení dat. V této variantě server zabezpečuje pouze správu dat. Na klientovi běží uživatelské rozhraní i všechny aplikační funkce. Data Distri bution - distribuce dat- je varianta , v níž server zajišťuje pouze část správy dat. Veškerá ostatní či nnost probíhá na klientovi. Správu dat je naplíklad možné distribuovat tak, že uložené procedury se nespou ští na serveru, ale přímo na kl ientovi. Prozatim jsme uvažoval i dvojvrstvou architektum , v ní ž máme k dispozici setver a klienta . Z dLIVOdLI zvýšení výkonu se v praxi stále více prosazuje vícevrstvá architektura. V plípadě tiívrstvé architektury pracujeme kromě databázového serveru a klienta ještě s aplikačním serverem.

I. Najaké komponenty mližeme roz ložil databázovou aplikaci?

2. Co znamenají pojmy distribution a separation v klasifikaci 5ystémli C/S? Jaké rozlišujeme


zák ladní varianty architektury CIS?

Jiná klasifikace systémů C/S Pii jiné klasifikaci můžeme systémy C/S rozdělit na: • • • • •

plně disttibuované zpracová n i úp l né systémy C/S systémy s databázovou bránou omezené systémy C/S firemní systémy.

V případě systémů plně distribuovaného zpracování jsou data uložena na více serverech. Plístup uživatelů k datům je pi nč tt·ansparcntní -připojí se k vybranému serveru a ten mu zpřístupní data na všech ostatních systémech. Server provádí veškeré funkce SŘBD. Uživatel musí pro plístup k datům vždy použít SŘBD. Front-end služby může zajišt'ova t větší počet systémů. Ú plné systémy C/S patří mezi nejběžnější systémy C/S. Data jsou zpravid la uložena na jednom serveru, ale mohou se nacházet i na více serverech. Uživatelská apl ikace se vždy plipojujc přímo na příslušný scivcr (musí včdčt, na kterém scivcm se data nacházejí). Sc1ver provádí veškeré funkce SŘBD. Uživatel musí pro přístup k datům vždy použít SŘBD. Front end služby mť1že zaj išťovat větší počet systémů. Systémy C/S s da tabázovou bránou slouží jako spojení mezi systémy na PC a SŘBD na střediskovém počítači. Databázové brány (gateway) a aplikace vytvářejí most mezí uživatelskou aplikací a SŘBD na jiných systémech než C/S. Databázové brány překládají požadavky na práci s daty do procedur , které umí SŘBD zpracovat. V om ezených systémech C/S sc1ver provádí pouze některé funkce SŘBD (vlastní ukládání , indexování , ...). Uživatel nemusí pro pl·ístup k datům použít služby SŘBD, s daty je možné manipulovat i jinými způsoby (například editováním přís l ušného souboru). Většina zpracování probíhá na klientov i . Front-end služby může zajišťovat několik systémů. Firemní systémy dnes existují v omezené míře, v dřívějších letech byl y pomčmě běžné . Tyto systémy vyžadují firemní hardware a operační systém a přístup k datům umožňují pouze vybraná typy software front-end, většinou dodávané přímo producentem SŘBD.

Výhody systémů C/S Hl avní výhodou systémů C/Sje rozdělení práce mezi klientský systém a databázový server. Protože většinu databázového zpracování provádí databázov ý server, n ení rychlost zpracování dat om ezena výkonem pracovní stanice. Na pracovní stanici běží pouze systém front-end. Z tohoto důvodu může být jako pracovní stanice využit i počítač s nižším výkonem (např. starší PC), který by nepostačoval pro provoz složitého SŘBD. Rozdělení práce snižuje zatížení sítě.

3

-


4

Místo přenášení celých databázových soubo1ů je provoz na síti omezen na dotazy směrované k serveru a na jeho odpovědi. Dalším piínoscm oddělení serveru a klienta je nezávislost na pracovní stanici . Uživatelé nejsou omezeni najeden typ systému. V případě architektury C/S může být pracovní stanicí PC, Macintosh i unixovská pracovní stanice a zároveň zde existuje aplikační n ezávislost Není nutné, aby pracovní stanice používaly stejný aplikační SW. Mezi velké výhody systémů C/S patří udržení integrity dat. Vyřípadě C/S systémů nemají uživatelé přístup k datům j inak než prostřednictvím SŘBD. SRBD tedy ověřuje přístupová práva jednotlivých uživatelů. Přístup k jednotlivým datovým položkám je tedy umožněn pouze těm uživatelům , kte1ým databázový administrátor přídělit piíslušná oprávnění. Každý SŘBD má zabudované mechan ismy pro zachování integrity dat (doménové, referenční , ...). SŘBD může poskytovat i další služby ochJany dat- například šifrování nebo duplex ing či mirroting disků. Systémy C/S zajišťují transak ční zpracovaní. Při transakčním zpracování SŘBD průběžně zaznamenává všechny modifikace prováděné v databázi. V plipadě havárie systému se záznam zmčn použije k obnovení databáze do stavu před chybou. SŘBD s architekturou C/S umožňují i paralelní práci více uživatelů.

3. Vyjmenujte a vysvětlete alespoií !Pi vý hody architektwy CIS ?

Nevýhody systémů C/S Mezi hlavní n evýhody systémů s arch i tekturou C/S v porovnání s databázemi na PC patří zvýšené personální náklad y na údržbu databázového serveru. U větších systémů j e nutné aby kromě správce sítě organizace zaměstnávala i databázového administrátora, jeh ož úkolem je zabezpeči t bezproblémový provoz SŘBD a front-end aplikací. Oproti DBS na PC jsou vyšší náklady na hard ware. V LAN, kde provozujeme DBS na PC, potřebuje file-server (souborový server). Pokud chceme v této síti provozovat DBS C/S musíme zajistit (nejlépe) vyhrazený databázový server. Jako databázový server je nutné používat stroj s velkou operační pamětí a rozsáhlým diskovým prostore m . Oproti DBS na PC jsou vyšší náklad y i na software. U databází s architekturou C/S je kromě nákladů na SŘBD nutné počítat i s pořizovací cenou front-end aplikací. Problémem může být i větší složitost těchto systémů. Delší dobu trvá vývoj systému a v případě havárie se obtížněji odhaluje její příči na .

4. Z čeho pramení většina nevý hod systémll s architekturou CIS ? I

I

-


5

Platformy C/S Platformou budeme rozumět kombinaci hardwar e a software, na nčmž je SŘBD provozován. Můžeme rozlišovat čtyři základní pl atformy: • • • •

PC, uni xovské pracovní stanice, minipočítače, střediskové počítače .

Z hlediska programového vybavení je velmi di'tlcžitý operační systém . Operační systém je základní software, který tvoří rozhraní mezi hardwarem , aplikacemi a uživateli. Základní vlastností operačního systému použi telného pro SŘBD s architekturou C/S je mullitasking (víccúlohovost- souběžné zpracován í několika úloh). Multitasking dovoluje SŘBD zpracovávat požadavky různých úloh nebo uživatelů , aniž by se navzájem ovlivňoval y. Pokud má systém umožnit současnou práci více uživatelů m usí být mulliuser (víceuživatelský). Žádná platforma nevyhovuje všem požadavkům a není vhodná pro všechny situace. Při výběru odpovídající platformy je nutné zvážit všechna hlediska. Pro otientaci v této problematice se seznámíme se zák l adními charakteristikami jednotlivých platforem .

S. Co chápeme pod pojmem platforma ?

v

Otázky pro dodavatele SRBD Pfi výběm nového SŘBD je třeba zj istit odpovědi na řadu otázek: • Z oblasti hard ware je třeba posou di t: o použitelnost dosavadního serveru o kompatibi l ita Hhardware s operačním systémem pod nímž běží SŘBD o nutnost dalšího hardware - UPS, zálohovací jednotky apod. o jaké má dodavatel zkušenosti s konfigurováním celých systémů (RAM, disková kapaci ta, systémy zálohování , apod.) • Z hlediska kompatibility s ex istujícími systém y o lépe je vybrat SŘHD pracující pod operačním systémem, který jsou zaměstnanc i běžně zvyklí používat o posoudit slučitelnost nového vybavení se stávajícím • Jaká j e podpora ze strany producenta? Ta totiž může velmi ovli vnit kvalitu nasazení systému. Do této kategorie patři například: o opravy chyb a drobná zlepšení SŘBD mohou být základní ceně o jakým způsobem je zajištěna technická pomoc • servis u zákazníka • jen hot-line (má zákazník speciálně jmenovaného konzu l tanta, nebo

-

-


pomoc spočívá v citaci manuálu? • pouze od dealen1 Osou odborně vyškoleni?) • žádná o jaká je rychlost technické pomoci • 24 hodin 7 dní v týdnu • pouze v pracovní dobč

• do týdne, .... o odborná instalace dodavatele o Podporu producenta můžeme nejlépe posoudit kontaktováním dalších zákazníky téhož producenta a zjištěním jejich zkušeností • Je součástí dodávky i proškolení ? o v jakém rozsahu o bude probíhat ve školícím středisku u dodavatele nebo v domácích prostorách odběratele • SŘBD by měl obsahovat prostředky m onitorová ní zatížen í, které jsou schopné zjistit, zda je delší doba odezvy zaviněna momentálním zvýšením požadavků na data nebo klesáním výkonnosti systému • Jaké systémy front-end SŘBD podporuje?

Doporu čen á literatura: Salemi J.- Databáze klient/server, str. 30- 60

Řešení úkolů : 1. Databázová aplikace je tvořena ze tří komponent: uživatelského rozhraní (GUI), apl ikačních funkcí a správy dat.

2. Distribution- rozdělení, separation- oddělení. lnterface Distribution (distribuce uživatelského rozhraní mezi klienta a server), lnterface Separation (odděleni uživatelského rozhraní od ostatních částí aplikace na serveru), Application Distribution (rozdělení aplikačních funkcí mezi klienta a server), Data Separation (oddělení správy dat- server- od ostatních částí aplikace klient) , Data Distribution (rozdělení správy dat mezi k lienta a server)

3. integrita dat- přístup k databázi pouze prostřednictvím SŘBD, zabudované integritní mechanismy v SŘBD transakční zpracování- obnova databáze do původního stavu po havárii paralelní zpracováni- současná práce více uživateltl nezávislost na pracovní stanici, aplikační nezávislost- uživatelé mohou jako klienta používat rozličné typy počítačů i aplikací

6

-


niž.ší zatížení sítě (než v případě DBS na PC) -rozdělení zpracování mezi klienta a

server, komunikace pomocí dotazů a odpovědí na ně

4, Většina nevýhod systémů C/S - vyšší náklady na HW, SW iobsluhu systémů je způsobena větší složitostí těchto systémtl oproti DBS na PC.

5. Pl atformou = kombinace hardware a software, na němž je SŘBD provozován.

7

ARCHITEKTURY SRBD. Centralizované platformy. Po absolvování přednášky Architektury SŘBD budeme umět

Recommend Documents