datab - univerzita...
TRANSCRIPT
Databáze 2011/2012 Logický model DB
RNDr.David Hoksza, Ph.D.
http://siret.cz/hoksza
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
Relační logický model (neformálně)
• 1974 - E. F. Codd
• reprezentace objektů konceptuálního schématu
pomocí tabulek (relací) o entitní (vztahový) typ → tabulka
o atribut → sloupec
o entita (vztah) → řádek tabulky
• schéma tabulky o T(S1:T1, …, Sn:Tn) – T = tabulka, Si = sloupec i, Ti = datový typ sloupce i
• schéma DB o schémata všech tabulek v DB + případná integritní omezení
Relační model (neformálně)
• Neexistují 2 stejné řádky, tj. každá tabulka má jednoznačný identifikátor
• Relační model nezná pojem NULL hodnoty o lze zavést metadhonotu NULL
• Množina sloupců jednoznačně identifikující řádky tabulky se nazývá nadklíč
• Nadklíč s nejmenším počtem sloupců se nazývá klíč
o klíčů může být více
• Množinu sloupců, které jsou klíčem v jiné tabulce
nazýváme cizí klíč o realizace vatahů mezi entitami
Relační model (formálně) • relace v algebře
o R ⊆ D1 x D2 x … x Dn
• databázové rozšíření pojmu relace o R(A1:D1, …, An:Dn)
o zjednodušeně R(A1, …, An)
• formální vs. neformální o schéma relace – schéma tabulky
o relace – tabulka (data)
o doména – datový typ sloupce
o prvek relace – řádek tabulky
• dále budeme používat zjednodušený relační model k popisu principů převodu konceptuálního schématu do relačního
Cizí klíč - princip
spz majitel rok_vyroby znacka
1A3 3040 Petr Novák 1980 Ford
ANE 0689 Aleš Vomáčka 2005 Honda
1T8 1230 Josef Novotný 2000 Honda
2B1 3491 Karel Vodrážka 2005 Škoda
znacka zeme
Ford USA
Honda JP
Škoda CZ
automobil(spz:string, majitel:string, rok_vyroby:integer, znacka:string)
vyrobce(znacka:string, zeme:string)
klíč
cizí klíč
Převod – kardinalita 1:1
linkaridic(cislo, start, cil, …, id, jmeno, rok_narozeni, …)
• V 1:1 kardinalitě může libovlný z klíčů účastnících se entit být klíčem výsledného relačního schématu
linka(cislo, start, cil, …, id),
ridic(id, jmeno, rok_narozeni, …)
• Při nepovinné účasti je třeba zvláštní relaci pro řidiče, který ve vztahu být nemusí
Převod – 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
Převod – 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
Převod – 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
Převod – kardinalita M:N • 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
linka(cislo, start, cil, …)
linkaridic(cislo, id)
ridic(id, jmeno, rok_narozeni)
Funkční závislost – př.
značení čtení
• RC → JMENO • Rodné číslo
funkčně
určuje jméno
• 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
význam
RČ … JMENO …
870226/5385 … Karel Vomáčka …
890610/1182 … David Mikeš …
880906/5595 … Jan Novák …
870226/5385 … Patrik Nový …
• funkční závislost určuje sémantické vztahy mezi atributy
Funkční závislost – př. značení čtení
• {START, CIL} →
CISLO
• Start a cíl
funkčně
určuje číslo
• 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
význam
CISLO … START CIL …
106 … Kavkazská Nádraží Braník
…
203 … Kačerov Vavřenova …
308 … Kavkazská Nádraží Braník
…
205 … Zemanka Komořany …
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
Funkční závislost (FZ) X → Y nad schématem R(A) je parciální zobrazení fi: Xi → Yi, kde Xi,Yi⊆A (kde i = 1..počet závislostí pro R(A)). Říkáme že n-tice z Xi funkčně určuje m-tici z Yi a že m-tice z Yi
funkčně závisí na n-tici z Xi
• Definice:
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 o R(A, F), kde F = ∪i{fi}
• nadklíč relace NK o NK → A
• klíč relace K o K → A ∧ ∄ K1: K1 ⊇ K
• klíčový atribut o atribut z A, který je součástí nějakého klíče (klíčů může být více)
• neklíčový atribut o atribut z A, který není součástí žádného klíče
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_K
M_ZA_MESIC
ODPRACOVANO_LET
PLAT VEK
1 Petr Malý
412 20 18000 48
2 Jan Vostrý
654 10 19000 35
3 Aleš Nový
412 20 18000 44
4 Petr Berka
128 15 17000 50
• ID → ALL
• JMENO → ALL
• NJKZM → OL
• OL → NJKZM
• {NJKZM, OL} → PLAT
• VEK → VSE
ne vše, co vidíme v
datech obecně platí
Aktualizační anomálie • mějme relaci
o AUTOBUS(SPZ, NAJETO, …, SOUCASTKA, VYROBCE_SOUCASTKY, …)
o součástky uchováváme v relaci s autobusy, tj. má-li autobus 20
součástek, máme 20 prvků relace v tabulce autobus pro jeden autobus
• příklady aktualizačních anomálií o změna informace o konkrétním autobusu vyžaduje vícenásobné
provedení této změny
o chceme-li odstranit jeden autobus z DB, je třeba to učinit na více místech
o není-li součástka použita v žádném autobusu, informaci o ní ztrácíme
o nelze přidat součástku do DB, aniž by nebyla použita v nějakém autobuse
Normalizace schématu • Normalizaci lze zajisti dekompozicí tak, aby výsledné
schéma splňovalo požadavky dané normální formy
• 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 o BCNF
o 4NF
o 5NF
• Výhody o Snížení redundance dat → menší prostorové nároky
o Jednodušší aktualizace dat
o Zabránění aktualizačním anomáliím
• Nevýhody o Zpomalení komplexních dotazů
1NF
1. tabulka musí reprezentovat relaci v algebraickém smyslu o 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)
o 1NF odporuje i situace, kdy je pro telefon použit jeden sloupec typu string, kde jsou telefony odděleny delimitorem
2NF • v DB se nesmí vyskytovat závislost neklíčového
atributu NK na vlastní podmnožině některého klíče K
o ∄𝐾𝐾 ⊂ 𝐾: 𝐾𝐾 → 𝑁𝐾
• {C_ZIDLE,BUDOVA} → ALL, BUDOVA → ADRESA
• redundance adresy
JMENO C_ZIDLE BUDOVA ADRESA PLAT
Jan Vodnář 58 A Technická 5, Praha 24000
Petr Novotný 58 B Technická 3, Praha 20000
Karel Kolář 2 A Technická 5, Praha 18000
Patrik Nový 23 C Studentská 1, Praha 35000
Aleš Výmola 45 B Technická 3, Praha 28000
není v 2NF
2NF - dekompozice JMENO C_ZIDLE BUDOVA PLAT
Jan Vodnář 58 A 24000
Petr Novotný 58 B 20000
Karel Kolář 2 A 18000
Patrik Nový 23 C 35000
Aleš Výmola 45 B 28000
BUDOVA ADRESA
A Technická 5, Praha
B Technická 3, Praha
C Studentská 1, Praha
{C_ZIDLE,BUDOVA} → ALL … 2NF
BUDOVA → ADRESA … 2NF
3NF • v DB se nesmí vystkytnout tranzitivní závislost na klíči K
o ∄𝐴, 𝐵: 𝐾 → 𝐴 → 𝐵
• JMENO → VSE, PSC → MESTO ⇒ JMENO → PSC → MESTO
• reundance města o může být problematické, když k se rozhodneme uchovávat další informace
o městě, např. počet obyvatel
JMENO PSC MESTO PLAT
Jan Vodnář 14200 Praha 24000
Petr Novotný 10100 Praha 20000
Karel Kolář 60200 Brno 18000
Patrik Nový 66434 Kuřim 35000
Aleš Výmola 63900 Brno 28000
není v 3NF
3NF – dekompozice JMENO PSC PLAT
Jan Vodnář 14200 24000
Petr Novotný 10100 20000
Karel Kolář 60200 18000
Patrik Nový 66434 35000
Aleš Výmola 63900 28000
PSC MESTO
14200 Praha
10100 Praha
60200 Brno
66434 Kuřim
63900 Brno
JMENO → ALL … 3NF
PSC→ MESTO … 3NF