Prezentace se nahrává, počkejte prosím

Prezentace se nahrává, počkejte prosím

Úvod do databázových systémů Jakub Lokoč. Literatura POKORNÝ, J., HALAŠKA, J.: Databázové systémy, skripta FEL ČVUT 2003 HALAŠKA, J., POKORNÝ, J.: Databázové.

Podobné prezentace


Prezentace na téma: "Úvod do databázových systémů Jakub Lokoč. Literatura POKORNÝ, J., HALAŠKA, J.: Databázové systémy, skripta FEL ČVUT 2003 HALAŠKA, J., POKORNÝ, J.: Databázové."— Transkript prezentace:

1 Úvod do databázových systémů Jakub Lokoč

2 Literatura POKORNÝ, J., HALAŠKA, J.: Databázové systémy, skripta FEL ČVUT 2003 HALAŠKA, J., POKORNÝ, J.: Databázové systémy-cvika, skripta ČVUT 2002 Ramakrishnan, Gehrke: Database Systems Management, McGraw-Hill, 2003 Další zdroje - web ◦ ◦ Upozornění – informace v této prezentaci nejsou vyčerpávající !!! 2Databázové systémy, Jakub Lokoč

3 Relační algebra (RA) Deklarativní dotazovací jazyk (neprocedurální) Výsledkem je vždy konečná relace Základní operace relační algebry (ZORA) ◦ “ ” – přejmenování atributu (konflikty jmen, spojení tabulek, …) ◦ “[a 1,.., a n ]” – projekce záhlaví jen na vybrané atributy a 1,.., a n ◦ “(logická podmínka)” - selekce řádků jejichž atributy splňují logickou podmínku ◦ “R 1 x R 2 x …” - kartézský součin více tabulek ◦ “R 1 – R 2 “ - rozdíl řádků tabulek se stejným záhlavím ◦ “R 1  R 2 ” - sjednocení řádků tabulek se stejným záhlavím ◦ “R 1  R 2 ” - průnik řádků tabulek se stejným záhlavím Operace jsou uvedeny v pořadí jejich priorit Jejich kombinací získáváme odvozené operace relační algebry (OORA) Databázové systémy, Jakub Lokoč3

4 Relační algebra (RA) Kartézský součin jako jediný rozšiřuje schéma nové tabulky Jejich kombinací lze formulovat velice pestrou škálu dotazů Při konfliktu jmen budeme pro jednodušší vyjádření pomocí ZORA přejmenovávat automaticky Databázové systémy, Jakub Lokoč4

5 ZORA – [], (), , , – Databázové systémy, Jakub Lokoč5 AdresaČísloBarva Estonská1Modrá Estonská2Červená Vltavská1Modrá Vltavská2Zelená Vltavská3Bílá Evropská1Modrá Evropská2Bílá Evropská3Modrá Evropská4Bílá Evropská5Zelená Francouzská1Bílá Francouzská2Zelená Francouzská3Modrá Barva Modrá Červená Zelená Bílá Dům[Barva] Barva Modrá Červená Dům(Adresa=‘Estonská’)[Barva] Dům(Adresa=‘Estonská’ v Adresa=‘Vltavská’)[Barva] Dům(Adresa=‘Estonská’)[Barva]  Dům(Adresa=‘Vltavská’)[Barva] Barva Modrá Červená Zelená Bílá Jaké jsou barvy všech domů? Jaké jsou barvy domů na Estonské? Jaké jsou barvy domů na Estonské a Vltavské? Jaké barvy domů mají společné Estonská a Vltavská? Dům(Adresa=‘Estonská’)[Barva]  Dům(Adresa=‘Vltavská’)[Barva] Jaké barvy domů na Estonské chybí? Dům[Barva] - Dům(Adresa=‘Estonská’)[Barva] Dům

6 ZORA – kartézský součin Základní matematická operace nad množinami Pozor na konflikty jmen (přejmenování, prefixy) Většinou kombinovaný se selekcí a projekcí Pomocí něj se odvozují všechny operace spojení Značíme R 1 x R 2 Databázové systémy, Jakub Lokoč6 AdresaČísloBarva Estonská1Modrá Vltavská1Zelená Francouzská1Bílá BarvaRGB Červená25500 Zelená02550 Modrá00255 AdresaČísloR1.Barva Estonská1Modrá Estonská1Modrá Estonská1Modrá Vltavská1Zelená Vltavská1Zelená Vltavská1Zelená Francouzská1Bílá Francouzská1Bílá Francouzská1Bílá R2.BarvaRGB Červená25500 Zelená02550 Modrá00255 Červená25500 Zelená02550 Modrá00255 Červená25500 Zelená02550 Modrá00255 R1R1 R2R2

7 OORA – přirozené spojení „Intuitivní“ propojení tabulek přes společné atributy Nechť A s = A 1  ( A 2 – A 1 ) a A p = A 1  A 2 R 1 x R 2 (R 1.a = R 2.a pro všechna a z A p )[A s ] Značíme R 1 * R 2 Pokud je A p prázdná, je výsledkem kartézský součin Databázové systémy, Jakub Lokoč7 AdresaČísloBarva Estonská1Modrá Vltavská1Zelená Francouzská1Bílá BarvaRGB Červená25500 Zelená02550 Modrá00255 AdresaČísloBarva Estonská1Modrá Vltavská1Zelená RGB R1R1 R2R2

8 OO RA – vnitřní spojení Přirozené spojení spojuje přes predikát rovnosti společných atributů Ten je ale jen speciálním případem libovolného predikátu, který určuje podmínku spojení R 1 x R 2 (t 1  t 2 ) [A 1  A 2 ] Značíme jako R 1 [t 1  t 2 ]R 2 Databázové systémy, Jakub Lokoč8 AdresaČísloBarva Estonská1Modrá Estonská2Červená Vltavská1Modrá Vltavská2Zelená Vltavská3Bílá Evropská1Modrá Evropská2Bílá Evropská3Modrá Evropská4Bílá Evropská5Zelená Francouzská1Bílá Francouzská2Zelená Francouzská3Modrá BarvaRGB Červená25500 Zelená02550 Modrá00255 AdresaČísloR1.Barva Vltavská1Modrá Vltavská2Zelená Vltavská3Bílá R2.BarvaRGB Červená25500 Červená25500 Červená25500 R 1 [Číslo < R & Adresa=“Vltavská”]R 2 R1R1 R2R2

9 OO RA – levé vnitřní spojení Ve spojení nás zajímají jen ty řádky z první tabulky, které se „spárovaly“ s nějakými řádky z druhé tabulky Neboli (R 1 [t 1  t 2 ]R 2 )[A 1 ] Značíme R 1

10 OORA – vnější spojení Rozšíření výsledku o řádky, které se „nespárovaly“ Levé vnější spojení R 1 * L R 2 = R 1 * R 2  R 1 x (NULL, …) Pravé vnější spojení R 1 * P R 2 = R 1 * R 2  R 2 x (NULL, …) R 1 a R 2 jsou nespárované řádky, R 1 = R 1 – (R 1 * R 2 )[A 1 ] Plné vnější spojení R 1 * F R 2 = R 1 * L R 2  R 1 * P R 2 Existuje i zobecněná varianta spojení přes libovolný predikát Databázové systémy, Jakub Lokoč10 AdresaČísloBarva Estonská1Modrá Vltavská1Zelená Francouzská1Bílá BarvaRGB Červená25500 Zelená02550 Modrá00255 AdresaČísloBarva NULL Estonská1Modrá Vltavská1Zelená Francouzská1Bílá RGB NULL LVS PVS R1R1 R2R2

11 OO RA - dělení Pro dotazy typu – „Které entity z R 1 obsahují všechny entity z R 2 ?“ Máme tabulky R 1 (A 1 ) a R 2 (A 2 ) R 1 [A 1 – A 2 ] – (R 1 [A 1 – A 2 ] x R 2 – R 1 )[A 1 – A 2 ] Značíme jako R 3 = R 1  R 2 Databázové systémy, Jakub Lokoč11 AdresaBarva EstonskáModrá EstonskáČervená VltavskáModrá VltavskáZelená VltavskáBílá EvropskáModrá EvropskáBílá EvropskáZelená FrancouzskáBílá FrancouzskáZelená FrancouzskáModrá Barva Zelená Modrá Adresa Vltavská Evropská Francouzská Adresy ulic, kde jsou všechny barvy z tabulky barev? R1R1 R2R2

12 Vyhodnocování dotazu RA Operace jsou vyhodnocovány dle jejich priorit (popř. dle závorek) Postup vyhodnocení lze zachytit tzv. stromem dotazu Příklad Dům(Adresa=‘Estonská’)[Barva]  Dům(Adresa=‘Vltavská’)[Barva] Databázové systémy, Jakub Lokoč12 Dům Selekce (Adresa=‘Estonská’) Projekce [Barva] Sjednocení Projekce [Barva] Selekce (Adresa=‘Vltavská’)

13 Optimalizace dotazu v RA Dotaz je možné často přepsat aniž by se změnil jeho výsledek – ekvivalentní výraz Přeskládání dotazu je v SŘBD úkolem optimalizátorů Ty se snaží mimo jiné zajistit, aby se projekce a selekce prováděly co nejdříve Dotaz lze také optimalizovat předpočítáním často používaných tabulek Databázové systémy, Jakub Lokoč13

14 Relační úplnost Né všechny operace jsou nezbytně nutné ◦ Která se dá odebrat? Dotazovací jazyk, kterým lze vyjádřit všechny konstrukce relační algebry se nazývá relačně úplný Databázové systémy, Jakub Lokoč14

15 Relační kalkul Využití predikátové logiky 1. řádu pro formulaci dotazů Různé úrovně práce s daty ◦ Doménový kalkul – atributy ◦ N-ticový kalkul – celé řádky Výsledkem dotazu je opět relace Popisujeme CO chceme získat z DB Databázové systémy, Jakub Lokoč15

16 Relační kalkul - příklady Dům(Adresa, Číslo, Barva) Čísla a barvy domů na Estonské ◦ { x, y : Dům(‘Estonská’, x, y) } ◦ { n[Číslo, Barva] : Dům(n) & n.Adresa = ‘Estonská’} Co ale vrátí následující dotaz? ◦ { x :  Dům(‘Estonská’, 25, x) } ◦ Může být výsledkem ‘abc’? ‘zlatá’? Databázové systémy, Jakub Lokoč16

17 Relační kalkul – bezpečné výrazy Předchozí příklad představuje výraz, který není bezpečný Výraz je bezpečný, pokud všechny hodnoty výsledku jsou vytvořeny z n-tic v databázi Relační kalkul omezený na bezpečné výrazy je ekvivalentní relační algebře Databázové systémy, Jakub Lokoč17

18 Rekapitulace Představili jsme si dva formální dotazovací jazyky ◦ Relační algebru ◦ Relační kalkul (doménový, n-ticový) Pomocí nich lze konstruovat dotazy nad definovaným datovým schématem relační databáze Prvky obou jazyků tvoří kostru jazyka SQL, který je rozšířen o další konstrukce (funkce, agregace, atp…) Databázové systémy, Jakub Lokoč18

19 SQL – Group by Podpora seskupovacích dotazů v SQL, výsledkem opět tabulka! Nezajímají nás detaily, ale spíš souhrny s agregacemi Lze zapsat i bez použití Group by (nevýhody?) Příklad dat - detaily vs. souhrny Databázové systémy, Jakub Lokoč19 UliceČísloCena Estonská Estonská Estonská Vltavská Vltavská Francouzská Francouzská UliceMin(Cena) Estonská Vltavská Francouzská

20 SQL – seskupení bez Group by Select ‘Estonská’ As Ulice, Min(Cena) From Dům Where Ulice=‘Estonská’  Select ‘Vltavská’ As Ulice, Min(Cena) From Dům Where Ulice=‘Vltavská’  Select ‘Francouzská’ As Ulice, Min(Cena) From Dům Where Ulice=‘Francouzská’ Musí se 3 x projít tabulka dům!!! Navíc ani dotaz není nejjednodušší… Databázové systémy, Jakub Lokoč20 UliceČísloCena Estonská Estonská Estonská Vltavská Vltavská Francouzská Francouzská UliceMin(Cena) Estonská Vltavská Francouzská

21 SQL – Group by Select Ulice, Min(Cena) From Dům Group by Ulice Pro každou hodnotu atributu Ulice jeden superřádek V dotazu s Group by se mohou používat ze seskupované tabulky pouze ◦ Atributy přes které se dělá Group by ◦ Agregační funkce nad zbývajícímí atributy Databázové systémy, Jakub Lokoč21 UliceČísloCena Estonská Estonská Estonská Vltavská Vltavská Francouzská Francouzská UliceMin(Cena) Estonská Vltavská Francouzská Špatně zapsaný dotaz: Select Cena From Dům Group by Ulice Bez funkce agragace by nebylo zřejmé, kterou cenu vybrat (pro každou ulici je ve výsledku jen jeden řádek)!

22 SQL – Group by / Having Having slouží pro filtrování výsledné tabulky superřádků Podmínka nemůže obsahovat samostatné atributy ze seskupované tabulky, které nejsou uvedeny za Group by (ale jejich agregace ano!) Select Ulice, Min(Cena) From Dům Group by Ulice Having Min(Cena) <= Databázové systémy, Jakub Lokoč22 UliceČísloCena Estonská Estonská Estonská Vltavská Vltavská Francouzská Francouzská UliceMin(Cena) Estonská Vltavská Francouzská

23 Vnořené dotazy Volání Selectu v Selectu ◦ Může vrátit jednu nebo i více hodnot Dvě možnosti vnoření dotazu ◦ V klauzuli Where + operace In, Exists, All, Any ◦ V klauzuli From (popř. i join s jinou tabulkou) Chování a efektivita vnořených dotazů ◦ Opakující se mezivýsledky ◦ Výskyty NULL v odpovědi  atribut IN (NULL, …, NULL) – nelze rozhodnout  EXISTS (NULL, …, NULL) – vrací TRUE Databázové systémy, Jakub Lokoč23

24 Vnořené dotazy – IN a EXISTS Select * From Dům D1 Where Cena IN (Select Cena From Dům D2 Where D2.Ulice = ‘Estonská’) Select * From Dům D1 Where EXISTS (Select Cena From Dům D2 Where D2.Ulice = ‘Vltavská’ & D2.Cena > D1.Cena) Databázové systémy, Jakub Lokoč24 UliceČísloCena Estonská Estonská Estonská Vltavská Vltavská Francouzská Francouzská UliceČísloCena Estonská Estonská Estonská Francouzská UliceČísloCena Estonská Vltavská

25 Vnořené dotazy – ALL a ANY Select * From Dům Where Cena < ALL (Select Cena From Dům Where Ulice = ‘Estonská’) Select * From Dům Where Cena < ANY (Select Cena From Dům Where Ulice = ‘Vltavská’) Databázové systémy, Jakub Lokoč25 UliceČísloCena Estonská Estonská Estonská Vltavská Vltavská Francouzská Francouzská UliceČísloCena Vltavská UliceČísloCena Estonská Vltavská

26 Transakce Podobně jako u jiných oborů se jedná o sadu operací, u které předpokládáme nějaké garantované chování Ty databázové charakterizují 4 vlastnosti ◦ Atomicity – buď proběhne vše nebo nic ◦ Consistency – zachování konzistentního stavu DB ◦ Isolation – transakce běží nezávisle na sobě ◦ Durability – po potvrzení se určitě zapíše do DB Podporovány všemi známějšími SŘBD Pořadí jejich spouštění a vykonávání zajišťuje v SŘBD tzv. rozvrhovač transakcí Databázové systémy, Jakub Lokoč26

27 Transakce Proč transakce? ◦ Netriviální operace na které nestačí základní SQL operace ◦ V průběhu vykonávání může být DB chvíli v nekonzistentním stavu ◦ Běh v konkurenčním prostředí (více transakcí současně) Příkladem může být třeba transakce pro převod peněz mezi účty Úhrada(částka, zÚčtu, naÚčet) SELECT zůstatek INTO z FROM Účet WHERE čÚčtu = zÚčtu If (z < částka) ZrušTransakci(„Nedostatek peněz na účtu!“) UPDATE Účet SET zůstatek = zůstatek – částka WHERE čÚčtu = zÚčtu UPDATE Účet SET zůstatek = zůstatek + částka WHERE čÚčtu = naÚčet Potvrdit transakci Databázové systémy, Jakub Lokoč27 READ(zU) WRITE(zU) WRITE(naU)

28 Transakce Základní operace v transakci ◦ READ(X) – načtení objektu X z DB ◦ WRITE(X) – zapsání objektu X do DB (pozor na cache!) ◦ COMMIT – potvrzení změn a ukončení transakce ◦ ABORT (ROLLBACK) – stornování změn a ukončení transakce Transakci lze chápat jako DB program ◦ Operace s DB (Read / Write) + další operace (aritmetické, pomocné, atp…) ◦ Problémy způsobují R/W operace nad stejnými daty, na ty se budeme zaměřovat ◦ Transakce - posloupnost R/W operací zakončená COMMIT nebo ABORT ◦ Např. Úhrada(částka, zU, naU) = { READ(zU), WRITE(zU), WRITE(naU), COMMIT} ◦ Dále budeme operace transakce zapisovat do sloupce Databázové systémy, Jakub Lokoč28

29 Transakce - vykonávání Uvažujme prostředí ve kterém může být současně spuštěno více transakcí (zatím - každá končí příkazem COMMIT, statické DB) Sériové vykonávání ◦ Dokud není obsloužena aktuálně zpracovávaná transakce, ostatní čekají ◦ Nemusí se řešit konflikty u společných DB objektů - konzistence ◦ Během R/W operací je procesor nevytížen Paralelní vykonávání ◦ všechny transakce jsou průběžně obsluhovány (tj. jedna čte data z DB, druhá může provádět výpočty nad již dotaženými daty) ◦ Jedna velká „neodstřelí“ server - odezva ◦ Musí se řešit konflikty nad společnými DB objekty (Isolation) Požadované chování SŘBD – paralelní vykonávání transakcí, kdy výsledný stav DB je stejný jako při sériovém vykonávání Databázové systémy, Jakub Lokoč29

30 Transakce - rozvrh Rozvrh je posloupnost operací které vykonávají průběžně běžící transakce, operace jsou libovolně prokládány ◦ S = {T 1.R(X), T 1.W(Y), T 2.R(Y), T 3.R(X), T 1.R(Z), …} Nedá se naplánovat dopředu (rozvrhovač neví, které transakce dorazí ke zpracování, dokonce ani nezná dopředu jednotlivé kroky vykonávaných transakcí) Tzn. rozvrh není vytvořen rozvrhovačem předem, rozvrh je jen historie provedených operací Rozvrhovač může jen garantovat vlastnosti rozvrhu pomocí omezení, které klade na spouštěné transakce (např. pustí transakci jakmile má potřebné zámky) Databázové systémy, Jakub Lokoč30

31 Transakce – rozvrh – příklad T1T1T2T3 READ(A) A = A + 10A = A + 5READ(B) WRITE(A) READ(C) WRITE(B) WRITE(C) WRITE(B) Databázové systémy, Jakub Lokoč31 Pokud by rozvrhovač pouštěl transakce ke slovu úplně náhodně, tak by mohl vzniknout pro T1, T2, T3 např. následující rozvrh. Nicméně, paralelní provedení zde nevede k očekávanému stavu DB. U libovolného sériového rozvrhu pro T1, T2, T3 bude k A přičteno celkem 15.Po vykonání tohoto rozvrhu bude hodnota A větší pouze o 5. Problém je v R/W konfliktech nad společnými daty. Možné konfliktní dvojice: RW Rokx Wxx

32 Uspořádatelnost Rozvrh nazveme uspořádatelný, jestliže jeho vykonání vede ke stejnému stavu, jaký obdržíme vykonáním nějakého sériového rozvrhu na stejných transakcích Velice silná vlastnost! Zaručuje izolaci a konzistenci (pokud jsou konzistentní T) Nicméně prokládání transakcí může vést ke konfliktům, které mohou porušit uspořádatelnost, tyto konflikty potenciálně způsobují tzv. konfliktní dvojice ◦ Read / Write ◦ Write / Read ◦ Write / Write Databázové systémy, Jakub Lokoč32

33 (Ne)konfliktní dvojice R/R Jako jediná nemá vliv na konzistenci DB Pouze čtení společných dat Příklad Databázové systémy, Jakub Lokoč33 T1T1T2 READ(A) B = A + 10READ(A) C = A + 5 WRITE(C) WRITE(B) COMMIT Předpoklad  A = 0 Sériové vykonání S(T1, T2)  A = 0, B = 10, C = 5 S(T2,T1)  A = 0, B = 10, C = 5 Paralelní vykonání P  A = 0, B = 10, C = 5

34 Konfliktní dvojice R/W Neopakovatelné čtení (nonrepeatable read) ◦ Transakce T2 zapíše objekt A, který předtím přečetla zatím nepotvrzená T1 ◦ Příklad, který vede ke konfliktu Databázové systémy, Jakub Lokoč34 T1T1T2 READ(A)A = 10 WRITE(A) C = A + 5 A = A + 5WRITE(C) WRITE(A) B = A + 10 WRITE(B) COMMIT Předpoklad  A = 0 Sériové vykonání S(T1, T2)  A = 10, B = 15, C = 15 S(T2,T1)  A = 15, B = 25, C = 15 Paralelní vykonání P  A = 5, B = 15, C = 15

35 Konfliktní dvojice W/R Čtení nepotvrzených dat (dirty read) ◦ T2 čte hodnotu A, kterou T1 zatím nepotvrdila, tj. mohou se číst nekonzistentní data ◦ Příklad, který vede ke konfliktu Databázové systémy, Jakub Lokoč35 T1T1T2 READ(A) A = A WRITE(A) READ(A) READ(B) A = A * 1.01, B = B * 1.01 WRITE(A) WRITE(B) COMMIT READ(B) B = B WRITE(B) COMMIT Předpoklad  A = 1000, B = 1000 Sériové vykonání S(T1, T2)  A = 0, B = 2020 S(T2,T1)  A = 10, B = 2010 Paralelní vykonání P  A = 0, B = 2010

36 Konfliktní dvojice W/W Přepsání nepotvrzených dat ◦ T2 přepíše hodnotu B, kterou předtím zapsala stále běžící T1 ◦ Příklad, který vede ke konfliktu Databázové systémy, Jakub Lokoč36 T1T1T2 A = B = 10A = B = 20 WRITE(A) WRITE(B) WRITE(A) COMMIT Předpoklad  A = 0, B = 0 Sériové vykonání S(T1, T2)  A = 20, B = 20 S(T2,T1)  A = 10, B = 10 Paralelní vykonání P  A = 10, B = 20

37 Konfliktová uspořádatelnost Dva rozvrhy nad stejnými transakcemi jsou konfliktově ekvivalentní, když mají stejné konfliktní dvojice (ve stejném pořadí nad stejnými objekty) Rozvrh je konfliktově uspořádatelný, pokud je konfliktově ekvivalentní k nějakému sériovému rozvrhu (v něm nejsou konflikty) Konfliktová uspořádatelnost se dá detekovat pomocí precedenčního grafu (nesmí obsahovat cykly – ty představují konflikty) Databázové systémy, Jakub Lokoč37 T1T1T2 READ(X) WRITE(X) COMMIT T1 T2 RW WW

38 Konfliktová uspořádatelnost Přísnější než uspořádatelnost (zachování konzistence) Eliminuje rozvrhy s konflikty RW, WR, WW Nicméně, zatím jsme uvažovali jen zjednodušenou DB Co když ale akce neskončí pomocí COMMIT? ◦ Rozvrh nemusí být zotavitelný Co když nemáme statickou DB? ◦ Může se vyskytnout fantom Databázové systémy, Jakub Lokoč38

39 Zotavitelný rozvrh Pokud transakce T zapisuje data a jiná transakce R je čte a dále s nimi pracuje, tak musí R provést COMMIT až po T Jinak by v případě ABORT u T byla R již potvrzena (R četla nekonzistentní data!!!) Rozvrh může být také zabezpečen proti kaskádovému rušení tj. čtou se změny pouze potvrzených transakcí Jak jde vidět – čím výhodnější rozvrh, tím méně možností prokládání Existuje ještě pohledová ekvivalence a uspořádatelnost, její testování je ale NP-úplný problém, nahrazuje se tedy v praxi konfliktově uspořádatelnými a zotavitelnými rozvrhy Databázové systémy, Jakub Lokoč39

40 Zotavitelný rozvrh Databázové systémy, Jakub Lokoč40 T1T1T2 READ(Z) WRITE(Z) READ(X) WRITE(X) READ(X) READ(Y) WRITE(X) WRITE(Y) COMMIT ABORT Který z následujících rozvrhů je zotavitelný? Jak by musel rozvrh vypadat, aby byl zabezpečen proti kaskádovému rušení? T1T1T2 READ(Z) WRITE(Z) READ(X) WRITE(X) READ(X) READ(Y) WRITE(X) WRITE(Y) ABORT COMMIT

41 Rekapitulace V konkurenčním prostředí můžou vznikat pro více běžících transakcí libovolné rozvrhy, ty mohou vést k nekonzistentní DB Rozvrhy mohou mít specifické vlastnosti, zajišťující míru izolace ◦ Sériový ◦ Uspořádatelný ◦ Konfliktově uspořádatelný ◦ Zotavitelný Jak ale zajistit, abychom získali rozvrh s požadovanými vlastnostmi? Rozvrhovač transakcí musí dodržovat určitá pravidla během „pouštění“ transakcí – tzv. protokol Databázové systémy, Jakub Lokoč41

42 Protokoly Sada pravidel zajišťující požadované vlastnosti ◦ Paralelizace (odezva, výkon) ◦ Uspořádatelnost (izolace, konzistence) ◦ Zotavitelnost (konzistence) Uzamykací protokoly ◦ Uzamykání DB entit (řádky, tabulky, …) ◦ Detekce uváznutí ◦ Fantom Alternativní protokoly ◦ Optimistické řízení – málo konfliktů ◦ Časová razítka Databázové systémy, Jakub Lokoč42

43 Uzamykání entit Nástroj pro zajištění konfliktové uspořádatelnosti (zámky určují pevné pořadí vykonávání) Exkluzivní X(A) a sdílené zámky S(A) Pokud není zámek k dispozici, transakce čeká (spí) Uzamykání je uživateli skryto, používá je rozvrhovač (zámky v rozvrhu – historie přidělení zámků rozvrhovačem) O přidělování zámků transakcím se stará správce zámků Zamykání a odemykání musí být atomické operace Databázové systémy, Jakub Lokoč43

44 Dvoufázový uzamykací protokol (2PL) 2PL uplatňuje při sestavování rozvrhu ◦ Nejdříve se musí uzamknout objekt, než se s ním pracuje (čtení, modifikace) ◦ Transakce nepožaduje zámek, pokud již nějaký uvolnila (tj. dvě fáze zamykání a odemykání) Důsledek pravidel ◦ Precedenční graf je acyklický Negarantuje však zotavitelnost Zotavitelnost garantuje až striktní 2PL ◦ Upravuje druhou podmínku – zámky jsou uvolněny až při ukončení transakce ◦ Garantuje také zabezpečení proti kaskádovému rušení transakcí Databázové systémy, Jakub Lokoč44

45 Uváznutí (deadlock) Transakce T žádá prostředky, které drží jiná transakce R. Ta požaduje zase prostředky, které drží transakce T. Obě jsou tudíž zablokovány. Může nastat i při S2PL Jak se vypořádat s uváznutím ◦ Detekce a vyřešení  Waits-for graf, transakce dlouho nic nedělá, …  Restartovat transakci dle nějakého kritéria ◦ Prevence  Prioritní upřednostňování (časové razítko určuje prioritu)  Konzervativní 2PL protokol (všechny zámky už na začátku) Databázové systémy, Jakub Lokoč45

46 Fantom Výskyt v dynamických DB (vkládání, mazání, …) Jedna transakce pracuje s množinou entit a druhá ji mění  nekonzistence DB Prevence – zamknout vše co se dá nebo pomocí indexu hlídat zamčenou oblast V příkladu rozvrh s fantomem (mají být zamčeni všichni muži) Databázové systémy, Jakub Lokoč46 T1T2 S(VsichniMuzi) A = PrumernyVek(VsichniMuzi) INSERT(‘Jan’, 20) X(‘Jana’) DELETE(‘Jana’) COMMIT S(VsechnyZeny) B = PrumernyVek(VsechnyZeny) COMMIT Sériové vykonání S(T1, T2)  A = 24, B = 20 S(T2,T1)  A = 22, B = 22 Paralelní vykonání P  A = 24, B = 22 JménoVěk Karel24 Jana18 Petra22

47 Úrovně izolace v SQL 92 Databázové systémy, Jakub Lokoč47 ÚroveňProtokolWRRWFantom READ UNCOMMITTED (read only transakce) žádnýmožná READ COMMITTED S2PL na X() 2PL na S() Nemožná REPEATABLE READS2PLNe možná SERIALIZABLE S2PL prevence fantoma Ne RW = Neopakovatelné čtení (nonrepeatable read) WR = Čtení nepotvrzených dat (dirty read)

48 Alternativní protokoly Optimistické řízení ◦ Konflikty jen zřídka, zamykání zbytečně zatěžuje systém ◦ Read/Validation/Write protokol  Data jsou čtena z DB  Transakce pracuje v lokálním datovém prostoru  Před potvrzením SŘBD rozhodne jestli nedošlo ke konfliktu  Pokud ano, tak se transakce restartuje, jinak zápis do DB Časová razítka ◦ Každá transakce dostane na začátku časové razítko TS(Ti) ◦ Pokud dojde ke konfliktu akcí T1.A1 a T2.A2, pak musí platit že TS(T1) < TS(T2) ◦ Kvůli zotavitelnosti se musí ukládat informace o všech zápisech (dokud transakce nepotvrdí) Databázové systémy, Jakub Lokoč48

49 Zotavení po havárii systému Správce zotavení musí zajistit ◦ Atomicitu – v případě zrušení transakce ◦ Trvanlivost – potvrzené transakce v DB i po havárii (pokud se data nestihla zapsat na disk) ARIES – algoritmus pro zotavení ◦ Analýza modifikovaných, ale nezapsaných stránek, aktivní transakce v okamžiku havárie ◦ Zopakování transakcí od určitého příslušného místa v logu ◦ Odvolání akcí těch transakcí, které nestačily potvrdit Principy ARIES ◦ Write-Ahead logging - každá změna DB do logu ◦ Repeating history during redo - znovu provede akce z logu ◦ Logging changes during undo – rušení transakce se také loguje Databázové systémy, Jakub Lokoč49

50 Cvičení 1 IS dopravního podniku ◦ Evidence řidičů, jízd a typy DP na které mají licenci ◦ Kdy a kde prováděl kontrolu revizor ◦ Koho chytil (ČP) a jakou mu udělil pokutu ◦ Seznam zastávek a linky které jimi projíždí ◦ Jízdní řád s časy odjezdů linek ze zastávek ◦ Které DP zajišťují které linky ◦ Pasažéři, kteří mají koupenou legitku Typy dotazů ◦ Kdo byl chycen revizorem a přitom má legitku (nechal doma)? ◦ Jak se dostanu ze stanice A do B s maximálně dvěma přestupy? ◦ Jak dlouho jede linka ze stanice A do B? Databázové systémy, Jakub Lokoč50

51 Databázové systémy, Jakub Lokoč51 ŘidičLicence Kontrola Revizor Pokuta Jízdní řád DP Zastávka Linka PasažérLegitka Má Licenci Provádí Uděluje Dostal Projíždí Zakoupil Jezdí Řídil Kontroluje Číslo licence RČ Typ DP Číslo RČ Datum vydání n 0..n n n n 1..n RČ ID Rok ID Kód Částka Datum Název

52 Konverze na relační model Databázové systémy, Jakub Lokoč52 Licence(Číslo_licence, RČ_Řidiče) RČ_Řidiče je cizí klíč do tab. Řidič Řidič(RČ) DP(TypDP, Číslo) Řídil(RČ, TypDP, Číslo) RČ a TypDP, Číslo jsou CK …

53 Cvičení 2 - definice Redundantní atribut ◦ Atribut v levé části funkční závislosti X  Y jehož odstraněním získáme odvoditelnou FZ z F ◦ atr z X takový, že (X – atr)  Y je z F+ Redundantní FZ ◦ FZ, která je odvoditelná ze zbývajících FZ ◦ fz patří do množiny (F – fz)+ Databázové systémy, Jakub Lokoč53

54 Cvičení 2 A = (Učitel, Předmět, Student, Čas, Budova, Areál, Stát) F = (PředmětČas  Učitel, StudentČas  Učitel, Budova  AreálStát, Areál  Stát, UčitelČas  Předmět, PředmětStudentČas  BudovaUčitel) Úkoly ◦ Nalezněte všechny klíče schématu ◦ Nalezněte všechny redundantní atributy ◦ Nalezněte všechny redundantní závislosti ◦ Jakou normální formu schéma splňuje? ◦ Proveďte dekompozici do 3NF, charakterizujte výsledek ◦ Splňují výsledné tabulky BCNF? ◦ Pojmenujte vzniklé tabulky Databázové systémy, Jakub Lokoč54

55 Cvičení 2 R1 ◦ A1 = (Areál, Stát) ◦ F1 = (Areál  Stát) R2 ◦ A2 = ◦ F2 = R3 ◦ A3 = ◦ F3 = R4 ◦ A4 = ◦ F4 = Databázové systémy, Jakub Lokoč55

56 Cvičení 3 – dotazy v RA Uvažujte tato schémata ◦ Dům(Ulice, ČP, PSČ, Barva) ◦ Okno(Ulice, ČP, PořadíOkna, JeStřešní) ◦ Kočka(Id, Jméno, BarvaSrsti) ◦ Předení(KočkaId, Ulice, ČP, PořadíOkna, Datum) Které domy na Estonské mají střešní okna? Které domy na Estonské nemají střešní okna? Jaká jsou PSČ domů, které mají více jak 10 oken? Jména koček, které předly na ulici Estonská? Jména koček, které předly na Estonské i Vltavské? Data, kdy předly bílé kočky v domech se střešními okny? Databázové systémy, Jakub Lokoč56

57 Cvičení 3 – dotazy v RA Uvažujte tato schémata ◦ Dům(Ulice, ČP, PSČ, Barva) ◦ Okno(Ulice, ČP, PořadíOkna, JeStřešní) ◦ Kočka(Id, Jméno, BarvaSrsti) ◦ Předení(KočkaId, Ulice, ČP, PořadíOkna, Datum) Ve kterých domech předly všechny zrzavé kočky? Které kočky předly na všech střešních oknech v Estonské? Adresy domů, kde dnes nepředly zrzavé ale všechny bílé kočky? Domy s max 5ti okny, kde dnes každá kočka splynula s pozadím? Na kterém domě se vystřídaly za dnešek kočky všech barev? Se kterými domy by splynuly kočky, které nikdy nikde nepředly? Databázové systémy, Jakub Lokoč57

58 Cvičení 3 – dotazy v RA Uvažujte tato schémata ◦ Dům(Ulice, ČP, PSČ, Barva) ◦ Okno(Ulice, ČP, PořadíOkna, JeStřešní) ◦ Kočka(Id, Jméno, BarvaSrsti) ◦ Předení(KočkaId, Ulice, ČP, PořadíOkna, Datum) Které domy na Estonské mají střešní okna? ◦ R1 = Okno(Ulice=“Estonska” and JeStresni=1)[Ulice,CP] Které domy na Estonské nemají střešní okna? ◦ R2 = Dům(Ulice=“Estonska”)[Ulice,CP] - R1 Jaká jsou PSČ domů, které mají více jak 10 oken? ◦ (Okno(PoradiOkna > 10)[Ulice,CP] * Dům)[PSC] Jména koček, které předly na ulici Estonská? ◦ R3 = (Kočka Predeni) [Ulice, CP, Datum] ◦ R5 = (R4 * Okno(JeStresni=1)[Ulice, CP])[Datum] Databázové systémy, Jakub Lokoč58

59 Cvičení 3 – dotazy v RA Uvažujte tato schémata ◦ Dům(Ulice, ČP, PSČ, Barva) ◦ Okno(Ulice, ČP, PořadíOkna, JeStřešní) ◦ Kočka(Id, Jméno, BarvaSrsti) ◦ Předení(KočkaId, Ulice, ČP, PořadíOkna, Datum) Ve kterých domech předly všechny zrzavé kočky? ◦ R6 = Kočka(BarvaSrsti=„Zrzavá“)[Id] ◦ R7 = Předení[KočkaId, Ulice, CP] ◦ R7  R6 nebo R7[Ulice,CP] – (R7[Ulice,CP] x R6 – R7)[Ulice,CP] Které kočky předly na všech střešních oknech v Estonské? ◦ StresniOknaVEstonske = Okno(Ulice=„Estonská“ & JeStřešní=1)[Ulice,CP,PořadíOkna] ◦ KočkyKterePredlyNaOknechVEstonské = Predeni(Ulice=“Estonská”)[KockaId,Ulice,CP,PoradiOkna] ◦ KočkyKterePredlyNaOknechVEstonské  StresniOknaVEstonske Adresy domů, kde dnes nepředly zrzavé ale všechny bílé kočky? Domy s max 5ti okny, kde dnes každá kočka splynula s pozadím? Na kterém domě se vystřídaly za dnešek kočky všech barev? Se kterými domy by splynuly kočky, které nikdy nikde nepředly? Databázové systémy, Jakub Lokoč59

60 Cvičení 5 Vytvořte ER-Model zachycující ◦ Návštěvy pacientů (jmeno, RC) u lékařů (jmeno, RC, adresa, mesto) ◦ Převeďte ER-Model do relačního modelu ◦ FZ = { adresa  město, RC  vše }  Určete klíče tabulky lékař  Proveďte dekompozici tabulky lékař do BCNF ◦ Napište SQL skript, který založí tabulky v DB a vloží do každé řádek Zapište dotazy jen pomocí ZORA a NJ ◦ Kteří pacienti chodí jen k doktorce Novotné? ◦ Kteří pacienti navštívili všechny doktory? Zapište pomocí SQL ◦ Ke kterým doktorům chodí více jak 10 pacientů? ◦ Kteří pacienti navštívili nejvíce doktorů? Databázové systémy, Jakub Lokoč60

61 Cvičení 5 T1T2 B = 5R(B) R(A)A = 10 W(B)B = A + B A = A – BW(A) W(B) COMMIT Databázové systémy, Jakub Lokoč61 A = 20, B = 0 Určete výsledek T1, T2 a T2, T1 Určete vlastnosti rozvrhu Serializovatelnost Konfliktovou uspořádatelnost Zotavitelnost Jaký by byl výsledek při použití S2PL? Co je to fantom?


Stáhnout ppt "Úvod do databázových systémů Jakub Lokoč. Literatura POKORNÝ, J., HALAŠKA, J.: Databázové systémy, skripta FEL ČVUT 2003 HALAŠKA, J., POKORNÝ, J.: Databázové."

Podobné prezentace


Reklamy Google