Databáze. Logický model DB. David Hoksza

Transkript

1 Databáze Logický model DB David Hoksza

2 Osnova Relační model dat Převod konceptuálního schématu do logického Funkční závislosti Normalizace schématu Cvičení převod do relačního modelu

3 Relační logický model - neformálně (1) E. F. Codd reprezentace objektů konceptuálního schématu pomocí (matematických) relací (lze reprezentovat tabulkou) + dotazovací jazyk (relační kalkul, relační algebra) entitní (vztahový) typ relace (tabulka) atribut atribut relace definované domény (sloupec) entita (vztah) n-tice (řádek tabulky) schéma relace (tabulky) T(S 1 :T 1,, S n :T n ) T = tabulka, S i = sloupec i, T i = datový typ sloupce i schéma DB schémata všech tabulek v DB + případná integritní omezení

4 Relační logický model (neformálně) - příklad automobil(spz:string, majitel:string, rok_vyroby:integer, znacka:string) spz majitel rok_vyroby znacka 1A Petr Novák 1980 Ford ANE 0689 Aleš Vomáčka 2005 Honda 1T Josef Novotný 2000 Honda 2B Karel Vodrážka 2005 Škoda

5 Relační logický model - neformálně (2) Narozdíl od tabulky, relace neobsahují duplicitní entice, tj. přesné mapování by vyžadovalo, aby každá tabulka měla jednoznačný identifikátor Množina sloupců jednoznačně identifikující řádky tabulky se nazývá nadklíč Nadklíč s nejmenším počtem sloupců se nazývá klíč klíčů může být více Množinu sloupců, které jsou klíčem v jiné tabulce nazýváme cizí klíč realizace vztahů mezi entitami Relační model nezná pojem NULL (neznámé/nevyplněné) hodnoty lze zavést metahodnotu NULL

6 Cizí klíč - princip automobil(spz:string, majitel:string, rok_vyroby:integer, znacka:string) spz majitel rok_vyroby znacka 1A Petr Novák 1980 Ford ANE 0689 Aleš Vomáčka 2005 Honda 1T Josef Novotný 2000 Honda 2B Karel Vodrážka 2005 Škoda automobil(znacka) vyrobce(znacka) znacka Ford Honda Škoda zeme USA JP CZ vyrobce(znacka:string, zeme:string) klíč cizí klíč

7 Relační model (formálně) relace R D 1 D n D i doména (datový typ) i databázové rozšíření pojmu relace R(A 1 : D 1,., A n : D n ) Relace R nad množinou atributů A 1,, A n z domén D 1,, D n zjednodušeně R A 1,., A n dále budeme používat zjednodušený relační model k popisu principů převodu konceptuálního schématu do relačního formální vs. neformální schéma relace schéma (struktura/záhlaví) tabulky relace tabulka (data) doména datový typ sloupce prvek relace řádek tabulky

8 Realizace vazeb kardinalita 1:1 V 1:1 kardinalitě může libovloný z klíčů účastnících se entit být klíčem výsledného relačního schématu linkaridic(cislo, start, cil,, id, jmeno, rok_narozeni, ) linka(cislo, start, cil,, id), při nepovinné účasti je třeba zvláštní relaci pro řidiče, který ve vztahu být nemusí ridic(id, jmeno, rok_narozeni, )

9 Realizace vazeb kardinalita 1:1 linka(cislo, start, cil, ) linkaridic(cislo, id) ridic(id, jmeno, rok_narozeni, ) při nepovinné účasti obou entit je třeba vytvořit novou relaci, protože každý objekt v jedné entitě může existovat nezávisle na objektu v entitě druhé protože jsou kardinality na obou stranách 1, tvoří každý z cizích klíčů ve spojovací relaci klíč v této relaci

10 Realizace vazeb kardinalita 1:N linka(cislo, start, cil, ) ridic(id, jmeno, rok_narozeni, cislo) Kardinalitu N zajišťuje cizí klíč cislo v relaci ridic, kde nehraje roli klíče (atribut není podtržen), na rozdíl od (0,1):(1,1) situace Parcialitu na N straně nejsme schopni v základním relačním modelu zajistit, proto ke 2 ER schématům máme 1 relační schéma

11 Realizace vazeb kardinalita 1:N linka(cislo, start, cil, ) linkaridic(cislo, id) ridic(id, jmeno, rok_narozeni) Parcialitu na 1 straně zajistíme vložením spojovací relace, která bude mít id jako klíč. Výsledek je podobný jako (0:1):(0:1) až na nejednoznačnost atributu cislo ve spojovací relaci Parcialitu na N straně nejsme schopni v základním relačním modelu zajistit, proto ke 2 ER schématům máme 1 relační schéma

12 Realizace vazeb kardinalita M:N linka(cislo, start, cil, ) linkaridic(cislo, id) ridic(id, jmeno, rok_narozeni) Ve vztahu M:N nejsme schopni v relačním modelu zajistit parcialitu, neboť každý objekt jedné entity muže být ve vztahu s více objekty druhé entity nutnost spojovací relace Klíčem ve spojovací relaci nemůže být ani jeden z cizích klíčů, nýbrž klíč musí tvořit oba cizí klíče najednou

13 Funkční závislost př. (1) funkční závislost určuje sémantické vztahy mezi atributy značení RC JMENO čtení rodné číslo funkčně určuje jméno RČ JMENO /5385 Karel Vomáčka /1182 David Mikeš /5595 Jan Novák /5385 Patrik Nový význam ke každému RČ existuje nejvýše jedno jméno = neexistují 2 záznamy v tabulce řidič se stejným RČ, ale různým jménem

14 Funkční závislost př. (2) značení {START, CIL} CISLO čtení Start a cíl funkčně určuje číslo CISLO START CIL 106 Kavkazská Nádraží Braník 203 Kačerov Vavřenova 308 Kavkazská Nádraží Braník 205 Zemanka Komořany význam ke každému startu a cíli existuje nejvýše jedno číslo = neexistují 2 záznamy v tabulce linka se stejným startem a cílem, ale různým číslem

15 Funkční závislost formálně Funkční závislost (FZ) je funkce mezi doménami atributů FZ je typem integritního omezení, tj. vymezuje jaká data mohou být v DB uložena, případně vymezuje vztahy mezi nimi Definice: Funkční závislost (FZ) X Y nad schématem R(A) je parciální zobrazení f i : X i Y i, X i, Y i A (kde i = 1..počet závislostí pro R(A)). Říkáme že n-tice z X i funkčně určuje m-tici z Y i a že m-tice z Y i funkčně závisí na n-tici z X i.

16 Funkční závislost a relační model relační model lze rozšířit tak, aby bylo možné v něm uchovávat informace o závislostech, tj. u relace nebudeme uchovávat pouze seznam atributů, ale i funkční závislosti mezi nimi R(A, F), kde F = i {f i } nadklíč relace NK NK A klíč relace K K A K 1 (K 1 A) : K 1 K klíčový atribut atribut z A, který je součástí nějakého klíče (klíčů může být více) neklíčový atribut atribut z A, který není součástí žádného klíče

17 Návrh funkčních závislostí modelování funkčních závislostí spadá do procesu funkční analýzy, tj. je třeba jej učinit ještě před vkládáním dat. To plyne i z faktu, že se jedná o IO, tedy omezuje možné vstupy není možné FZ odvozovat ze stávajících dat, nýbrž z přirozených vztahů mezi atributy ID JMENO NAJETE_KM _ZA_MESIC ODPRACO VANO_LET PLAT 1 Petr Malý Jan Vostrý Aleš Nový Petr Berka VEK ID ALL JMENO ALL NJKZM OL OL NJKZM {NJKZM, OL} PLAT VEK VSE ne vše, co vidíme, v datech obecně platí

18 Aktualizační anomálie mějme relaci AUTOBUS(SPZ, NAJETO,, SOUCASTKA, VYROBCE_SOUCASTKY, ) součástky uchováváme v relaci s autobusy, tj. má-li autobus 20 součástek, máme 20 řádků pro 1 příklady aktualizačních anomálií změna informace o konkrétním autobusu vyžaduje vícenásobné provedení této změny chceme-li odstranit jeden autobus z DB, je třeba to učinit na více místech není-li součástka použita v žádném autobusu, informaci o ní ztrácíme nelze přidat součástku do DB, aniž by nebyla použita v nějakém autobuse

19 Normalizace schématu Normalizace relace minimalizuje redundanci v datech a tak předchází vzniku aktualizačních anomálií Normalizaci lze zajisti dekompozicí (rozdělení jedné relace do více tabulek) tak, aby výsledné schéma splňovalo požadavky dané normální formy (NF) 1NF zajišťuje nestrukturovanost dat 2NF a 3NF omezují redundanci dat, tj. nutí uživatele dekomponovat schéma Další NF, které nejsou v praxi často využívány BCNF 4NF 5NF Výhody Snížení redundance dat menší prostorové nároky Jednodušší aktualizace dat Zabránění aktualizačním anomáliím Nevýhody Zpomalení komplexních dotazů

20 1NF 1. tabulka musí reprezentovat relaci v algebraickém smyslu atributy vnitřně nestrukturované (žádné vnořené tabulky, nebo složené datové typy, tj. jako domény je třeba užít základní datové typy) 2. neexistence opakujících se skupin osoba(id:integer, jmeno:string, datum_narozeni:date, podrizeni:osoba[]) osoba(id:integer, jmeno:string, datum_narozeni:date) osobaosoba(id_pod:integer, id_nad:integer) osoba(id:integer, jmeno:string, datum_narozeni:date, tel1:string, tel2:string, tel3:string) osoba(id:integer, jmeno:string, datum_narozeni:date) osobatelefon(cislo:string, id_osoba:integer) 1NF odporuje i situace, kdy je pro telefon použit jeden sloupec typu string, kde jsou telefony odděleny delimitorem

21 2NF v DB se nesmí vyskytovat závislost neklíčového atributu NK na vlastní podmnožině některého klíče K KK K: KK NK není v 2NF JMENO C_ZIDLE BUDOVA ADRESA PLAT Jan Vodnář 58 A Technická 5, Praha Petr Novotný 58 B Technická 3, Praha Karel Kolář 2 A Technická 5, Praha Patrik Nový 23 C Studentská 1, Praha Aleš Výmola 45 B Technická 3, Praha {C_ZIDLE,BUDOVA} ALL, BUDOVA ADRESA redundance adresy (nebo obecně jakékoli informace závislé na budově)

22 2NF - dekompozice JMENO C_ZIDLE BUDOVA PLAT Jan Vodnář 58 A Petr Novotný 58 B Karel Kolář 2 A Patrik Nový 23 C Aleš Výmola 45 B {C_ZIDLE,BUDOVA} ALL 2NF BUDOVA A B C ADRESA Technická 5, Praha Technická 3, Praha Studentská 1, Praha BUDOVA ADRESA 2NF

23 3NF v DB se nesmí vystkytnout tranzitivní závislost na klíči K A, B: K A B JMENO PSC MESTO PLAT Jan Vodnář Praha Petr Novotný Praha Karel Kolář Brno Patrik Nový Kuřim Aleš Výmola Brno není v 3NF JMENO VSE, PSC MESTO JMENO PSC MESTO reundance města může být problematické, když se rozhodneme uchovávat další informace o městě, např. počet obyvatel

24 3NF dekompozice JMENO PSC PLAT Jan Vodnář Petr Novotný Karel Kolář Patrik Nový Aleš Výmola JMENO ALL 3NF PSC MESTO Praha Brno Kuřim Brno PSC MESTO 3NF