TÉMATICKÝ OKRUH Teorie zpracování dat, Databázové a informační systémy a Teorie informačních systémů
Číslo otázky : Otázka :
Obsah :
14. Návrh struktury relační databáze, funkční závislosti.
1. Návrh struktury relační databáze – relační datový model(RDM) Převod konceptuálního schématu zapsaného v nějakém konceptuálním modelu není jediným způsobem, jak navrhnout relační schéma databáze. Současně se vznikem teorie relačního modelu dat vznikla také metoda návrhu relačních schémat, založená na jiných principech, než intuitivním návrhem konceptuálního modelu, a to pomocí funkčních závislostí. Podívejme se na úlohu návrhu struktury databáze takto: z reálného světa máme dánu množinu atributů, které chceme rozmístit do jednotlivých schémat relací. Názvy těchto relací (názvy typů entit) ani jejich počet předem neznáme. Úkolem je navrhnout schéma databáze bez redundancí. Ukážeme si to na konkrétním případě. Mějme relaci R (Přednáška, Učitel, Místnost, Hodina, Student, Známka). Prvkem tohoto schématu je přednáška, učitel, který ji přednáší v uvedené místnosti a uvedenou hodinu, student, který přednášce naslouchá a známka, kterou dostane po vykonání zkoušky z daného předmětu. Klíčem tohoto schématu je (Hodina,Student).
Snadno si všimneme následujících nedostatků a potíží: ● redundance, pro každého studenta navštěvujícího přednášku se opakují hodnoty přednáška, učitel, místnost, hodina ● nebezpečí vzniku nekonzistence při modifikacích jako důsledek redundance, ● anomálie při vkládání záznamů: nemůžeme vložit učitele, který nepřednáší, neboť by nebyly obsazeny klíčové atributy ● anomálie při vypouštění záznamů: přestane-li učitel přednášet, vypustíme prvky tohoto učitele, tím ztratíme informaci i o jeho jménu. Je zřejmě nutné schéma databáze změnit, atributy rozdělit do více relačních schémat. V následujícím seznamu jsou uvedena různá relační schémata databáze, popisující původní situaci. Pro jednoduchost místo atributů píšeme jen jejich počáteční písmena: R1 = {PU, HMP, HUM, PSZ, HSM } R4 = {PU, HMP, PSZ, HSP } R2 = {PU, HSP, PSZ, HSM } R5 = {HMPU, PSZ, HSM } R3 = {PU, HSM, PSZ, HMP } R6 = {PU, HMP, HSM } R7 = {PSUHM, PSZ } Po rozboru uvidíme, že všechna schémata jsou smysluplná, avšak nedovedeme říci, čím se vlastně od sebe liší, je-li některé z nich lepší než ostatní. Jediným zdrojem informací pro upřesnění sémantiky mohou být IO. Čím více jich budeme mít k dispozici, tím lépe můžeme provést návrh schématu. Současně se vznikem teorie relačního modelu dat vznikla také metoda návrhu relačních schémat, založená na jiných principech, než intuitivním návrhem konceptuálního modelu, a to pomocí funkčních závislostí.
2. Funkční závislosti Funkční závislost je definovaná mezi dvěma podmnožinami atributů v rámci jednoho schématu relace. Jde tedy o vztahy mezi atributy nikoliv mezi entitami. Definice: Nechť R({A1,A2,...,An}, f) je relační schéma, nechť X, Y jsou podmnožiny množiny jmen atributů {A1,A2,...,An}. Řekneme, že Y je funkčně závislá na X, píšeme X → Y, když pro každou možnou aktuální relaci R(A1,A2,...,An) platí, že mají-li libovolné dva prvky (= dva řádky) relace R stejné hodnoty atributů X, pak mají i stejné hodnoty atributů Y. Je-li Y ⊂ X říkáme, že závislost X → Y je triviální. Jak plyne z definice funkční závislost je definována na základě všech možných aktuálních relací, není tedy možné soudit na funkční závislost z vlastností jediné (třeba aktuální) relace. Tak můžeme poznat pouze neplatnost funkční závislosti. Funkční závislosti jsou tvrzení o reálném světě, o významu atributů nebo vztahů mezi entitami (jako každé IO), je nutné je brát v úvahu při návrhu schématu databáze. Ukážeme si opět příklad: Je dána aktuální relace dle relačního schématu z minulého příkladu. Podívejme se podrobněji na obsah tabulky: Všimneme si vztahu mezi podmnožinami X = {místnost, hodina} a Y = {předmět}. Vždy, když 2 řádky tabulky mají stejné hodnoty atributů X, mají i stejné hodnoty atributů Y. V tabulce jsou vyznačeny stejnou barvou, X světlejším, Y tmavším odstínem. Slovně to můžeme formulovat takto: v dané místnosti a v danou hodinu v týdnu se učí jediný předmět. Tedy existuje funkční závislost M H → P. Tuto funkční závislost známe obecně z reality.
Funkční závislost nám také plyne z integritního omezení IO - v uvažované škole platí, že každý předmět přednáší jeden učitel - P → U. Celkem v příkladě můžeme určit tuto množinu funkčních závislostí F - F = { MH → P, P → U, HU → M, PS → Z, HS → M} Z aktuální relace by se mohlo usuzovat na platnost funkční závislosti M → H, ovšem obecně to zřejmě není pravda. Nelze tedy z jedné relace dokázat platnost funkčního vztahu. Naopak negativní fakta mohou být zjistitelná, protože tvoří protipříklad: není pravda PU → M, protože TZD se učí ve dvou posluchárnách v týdnu. Uvedeme ještě další pojmy, které jsou důležité pro další použití. Nechť F je množina funkčních závislostí pro relační schéma R, nechť X → Y je funkční závislost. Řekneme, že F logicky implikuje X → Y, jestliže v každé relaci R, v níž jsou splněny závislosti z F, je splněna i závislost X → Y. Množinu všech závislostí, které jsou logicky
implikovány množinou F, nazýváme uzávěrem množiny F, označujeme F+. Nechť X, Y jsou podmnožiny atributů schématu R s množinou závislostí F. Říkáme, že Y úplně závisí na X, jestliže X → Y a pro žádnou vlastní podmnožinu X'⊂X není X' → Y. Jinými slovy Y je funkčně závislá na X, ale není funkčně závislá na žádné vlastní podmnožině X. Nechť R ({A1,A2,...,An},f) je relační schéma s množinou funkčních závislostí F, nechť X {A1,A2,...,An}. Řekneme, že X je klíč schématu R, jestliže 1. X → A1...An ⊂ F+ 2. pro každou vlastní podmnožinu Y ⊂ X je Y → A1...An ⊄ F Přidali jsme tedy podmínku minimality. Zřejmě můžeme klíč schématu definovat také jako takovou X ⊂ A, že A je úplně závislá na X. V relačním schématu může být více klíčů, z nich obvykle vybíráme jeden a označujeme jako primární klíč. Atribut relačního schématu R se nazývá primární, je-li podmnožinou alespoň jednoho klíče schématu R. Ostatní atributy nazveme sekundárními.
2.1 Amstrongovy axiomy K určení klíče relačního schématu a k hledání logických implikací množiny závislostí potřebujeme nalézt uzávěr F+, nebo určit, zda daná závislost X → Y je prvkem F+. K tomu existují pravidla zvaná Armstrongovy axiomy. Tato pravidla jsou úplná (dovolují odvodit z dané množiny závislostí F všechny závislosti patřící do F+) a bezesporná (dovolují z F odvodit pouze závislosti patřící do F+). Nechť A je množina atributů daného relačního schématu, F množina funkčních závislostí mezi atributy A. V následujících pravidlech označujeme sjednocení X∪Y jako XY. Následující odvozovací pravidla se obvykle nazývají Armstrongovými axiomy jsou: A1: jestliže Y⊂ X ⊂ A, pak F logicky implikuje X → Y (reflexivita, triviální fční závislost) A2: jestliže X → Y a Z ⊂ A, pak XZ → YZ (rozšíření) A3: jestliže X → Y a Y → Z, pak X → Z (tranzitivita) A4: jestliže X → Y a X → Z, pak X → YZ (sjednocení) A5: jestliže X → Y a WY → Z, pak XW → Z (pseudotranzitivita) A6: jestliže X → Y a Z ⊂ Y, pak X → Z (zúžení) A7: jestliže X →YZ, pak X → Y a X → Z (dekompozice) Důsledkem sjednocení a dekompozice je: X→A1 ...An právě tehdy, když X→ Ai pro všechna i. Příklad: Určete klíč relačního schématu R(Jméno, Katedra, Předmět, Úvazek) se závislostmi F = {Jméno → Katedra, Jméno Předmět → Úvazek}. Pro stručnost zapíšeme zadání i další odvozování opět jen prvními písmeny atributů: Zadání: A = {J, K, P, U }, F = {J → K, JP → U } Odvození klíče: 1. J → K ( dáno v F ) 2. JP → KP ( aplikace rozšíření na 1. ) 3. JP → U ( dáno v F ) 4. JP → KPU ( aplikace sjednocení na 2. a 3. ) 5. JP → JKPU ( aplikace reflexivity na 4. ) Neplatí například J → P, P → K, podle důsledků pravidel je JP minimální a tedy klíč. Platí, že F lze nahradit závislostmi, které vzniknou dekompozicí pravých stran závislostí na
jednotlivé atributy. Závislost, která má na pravé straně pouze jeden atribut, nazýváme elementární. Je-li F' množina elementárních závislostí, které vzniknou z F uvedeným způsobem, platí F+ = F '+ Z F' lze odstraňovat závislosti, které jsou odvoditelné ze zbytku F'. Říkáme, že závislost f je redundandní v F', jestliže platí (F' - {f})+ = F'+ Odstraněním všech redundandních závislostí z F' vznikne tzv. neredundandní pokrytí F. Definice: Pokrytí množiny funkčních závislostí F je taková množina G funkčních závislostí, pro niž platí G+ = F+. Neredundandní pokrytí je takové pokrytí, které neobsahuje redundandní závislosti. Neredundandní pokrytí není dáno jednoznačně, závisí na pořadí, ve kterém odebíráme neredundandní závislosti. Obecně tedy nemusí být podmnožinou původní množiny F, pokud vycházíme z F+, ne z F. Příklad 5.78. Určete neredundandní pokrytí množiny funkčních závislostí F: F = {X→ Y, Y→ X, Y→ Z, X→Z} Řešení: 1. Uzávěr celé množiny F je : F+ = { X→XYZ, Y→YXZ, Z→Z } 2. (F - {X→Y})+ = {X→XZ, ... } ... menší než F+, vyloučení závislost není redundandní, 3. (F - {Y→X})+ = {X→XZY, Y→YZ ... } ... menší než F+, 4. (F - {Y→Z})+ = {X→XZY, Y→YXZ, Z→Z ... } ... stejný jako F+, Y→Z je redundandní, 5. (F - {X→Z})+ = {X→XZY, Y→YXZ, Z→Z ... } ... stejný jako F+, X→Z je redundandní, ale ne obě (Y→ Z i X→ Z) současně. Výsledek tedy není jednoznačný, záleží na pořadí odebírání redundandních závislostí: buď Fnered = { X → Y, Y → X, X → Z } nebo Fnered = { X → Y, Y → X, Y → Z } Příklad 5.8. Určete neredundandní pokrytí množiny funkčních závislostí F: F: AB→C, C→A, BC→D, ACD→B, D→EG, BE→C, CG→BD, CE→AG 1)Nejprve upravíme F, aby obsahovala jen elementární závislosti F': AB→C, C→A, BC→D, ACD→B, D→E, D→G, BE→C, CG→B, CG→D, CE→A, CE→G Zde CE→A, CG→B jsou redundandní, vyloučíme je v uvedeném pořadí a dostaneme výsledek: F1: AB→C, C→A, BC→D, ACD→B, D→E, D→G, BE→C, CG→D, CE→G 2)Jestliže zvolíme jiné pořadí při odstraňování redundandních závislostí v pořadí CE→A, CG→D, ACD→B, obdržíme: F2: AB→C, C→A, BC→D, D→E, D→G, BE→C, CG→B, CE→G Při provádění dekompozicí univerzálního schématu R(A) se zadanou množinou funkčních závislostí F často není nutné znát celý uzávěr F+, ale stačí uzávěr podmnožiny atributů X ⊂ A vzhledem k F. Tento uzávěr tvoří množina všech atributů funkčně závislých na X a označíme jej X+. Jestliže X→Y a pro nějaké C∈ X platí (X - C)+ = X+, říkáme, že atribut C je redundandní pro zadanou závislost. Pokrytí, v jehož závislostech neexistují žádné redundandní atributy, nazýváme minimálním pokrytím. Význam minimálního pokrytí je v tom, že pro manipulaci s IO (např. testování jejich splnění při aktualizaci relací) jich má být co nejméně.
Příklad 5.80. Je dáno schéma R(A,B,C,D,E). Určete minimální pokrytí Fmin množiny funkčních závislostí F = {ABC→D, E→C, AB→E, C→D} Řešení: A+ = {A}, B+ = {B}, C+ = {CD}, D+ = {D}, E+ = {EA} AB+ = {ABECD} ... v ABC → D je C redundandní Výsledek: Fmin = {AB→DEC, E→C, C→D} Příklad 5.9. Uvažme opět neredundandní pokrytí F1 z dŕívějšího příkladu: F1: AB→C, C→A, BC→D, ACD→B, D→E, D→G, BE→C, CG→D, CE→G. Z C→A lze odvodit CD→AD a CD→ACD. Protože ACD→B, platí dále CD→B. Tak získáme minimální pokrytí Fmin: AB→C, C→A, BC→D, CD→B, D→E, D→G, BE→C, CG→D, CE→G Při eliminaci redundandních atributů se nenaruší uzávěr množiny funkčních závislostí, z redukovaných závislostí je možno získat původní. Z redukovaných závislostí se také nedají získat jiné závislosti, než ty původní. Platí tedy F+ = F1+ = F2+ = Fmin+ Obě transformace (odstranění redundandních závislostí a redundandních atributů) nelze provádět v libovolném pořadí. Pro získání minimálního pokrytí je nutno odstranit nejprve redundandní atributy a potom závislosti.
3. Normální formy 3.1 První normální forma - 1NF Relace je v první normální formě, pokud každý její atribut obsahuje jen atomické hodnoty. Tedy hodnoty z pohledu databáze již dále nedělitelné. Například v relaci obsahující data o nějaké osobě budeme chtít mít více telefonních čísel: Osoba Jméno Přijmení Adresa Telefony Jan Novák Havlíčkova 2 Praha 3 125789654;601258987;789456123 Petr Kovář Svatoplukova 15 Brno 369852147;357951456;963852741 Pavel Pavel Papalášova 25 Kocourkov 546789123;123456789;987456123 S takovouto tabulkou by byla spousta problémů, například by se dost špatně prováděly změny čísel, případně vyhledávání podle telefonního čísla. Aby tabulka byla v 1NF musíme buďto rozdělit atribut telefon do více atributů (pouze za předpokladu, že jsme si jisti, že se množství telefonních čísel nezvýší), nebo oddělit telefoní čísla do samostatné tabulky, což já osobně preferuji, protože je to podstatně flexibilnější řešení: Osoba ID Jméno 1 Jan 2 Petr 3 Pavel
Příjmení Adresa Novák Havlíčkova 2 Praha 3 Kovář Svatoplukova 15 Brno Pavel Papalášova 25 Kocourkov
Telefon ID_osoby 1 1 1 2 2 2 3 3 3
Cislo 125789654 601258987 789456123 369852147 357951456 963852741 546789123 123456789 987456123
Zjednodušeno(jiný zdroj): Vyžaduje, aby všem atributovým jménům byly jako domény přiřazeny jednoduché datové typy. Tedy vlastně nic extra. 1NF asi nelze nesplnit.
3.2 Druhá normální forma - 2NF Relace se nachází v druhé normální formě, jestliže je v první normální formě a každý neklíčový atribut je plně závislý na primárním klíči, a to na celém klíči a nejen na nějaké jeho podmnožině. Z čehož vyplívá, že druhou normální formu musíme řešit pouze v případě, že máme vícehodnotový primární klíč. Zní to poněkud složitě, ale nic na tom není, opět pomůže příklad: V tabulce zboží v obchodě bude název zboží, výrobce, telefon na výrobce, cena zboží a množství na skladě. Sklad Název Výrobce Telefon Výrobce Cena Množství Mléčná čokoláda Milka +420123456789 30Kč 2500 Oříšková čokoláda Milka +420123456789 30Kč 2800 Tyčinka milkyway Milka +420123456789 10Kč 7000 Mléčná čokoláda Orion +420987654321 25Kč 5800 Oříšková horalka Horalka +420897654321 7Kč 4560 Klíčem této relace je kombinace atributů Název a Výrobce. Telefon výrobce ovšem není závislí na celém klíči, ale pouze na atributu výrobce. To by vedlo k aktualizační anomálii a to k té, že pokud by se vymazaly veškeré výrobky od výrobce Milka, ztratilo by se telefoní číslo na výrobce Milka, což není zrovna žádané. Řešením je opět rozpad na dvě tabulky: Výrobek Název Mléčná čokoláda Oříšková čokoláda Tyčinka milkyway Mléčná čokoláda Oříšková horalka
Výrobce_ID 1 1 1 2 3
Cena 30Kč 30Kč 10Kč 25Kč 7Kč
Množství 2500 2800 7000 5800 4560
ýrobce Vyrobce_ID 1 2 3
Vyrobce Telefon Milka +420123456789 Orion +420987654321 Horalka +420897654321
Zjednodušeno(jiný zdroj): Zakazuje míšení různých údajů v jedné tabulce. Formálně se to řekne: žádný neklíčový atribut (něco, co se v tab. vyhledává) není funkčně závislý jen na části libovolného klíče. Nesmím být tedy schopen najít nějaký údaj v tabulce podle informace, která je menší než klíč. (Jinak bych tabulku měl rozdělit na dvě.)
3.3 Třetí normální forma - 3NF V této formě se nachází tabulka, splňuje-li předchází dvě formy a žádný z jejich atributů není tranzitivně závislý na klíči. Jiné vyjádření téhož říká, že relace je v 3.NF, pokud je ve 2.NF a všechny neklíčové atributy jsou navzájem nezávislé. Opět definice, která zní nesrozumitelně, ale její použití je vlastně jednoduché. Tranzitivní závislost je taková závislost, mezi minimálně dvěma atributy a klíčem, kde jeden atribut je funkčně závislý na klíči a druhý atribut je funkčně závislý na prvním. Koukám, že jsem tomu opět moc nepomohl, takže nejlepší bude příklad: Řekněme, že firma chce uchovávat informace o zaměstnancích, takže vytvoříme relaci Zaměstnanec s atributy r.č. (primární klíč), Jméno, Příjmení, Město, PSČ, Funkce a Plat, zbytek adresy vynecháme, protože pro příklad není důležitý. Zaměstnanec r.č Jméno Příjmení Město PSČ Funkce Plat 1 Jack Smith Jihlava 58601 CEO 150000 2 Franta Vomáčka Praha10 10000 Senior Software Architect 80000 3 Pepa František Plzeň 10000 Senior Software Architect 80000 4 Pavel Novák Kocourkov 99999 Junior Developer 30000 5 Petr Koukal Praha10 12345 Database Designer 75000 6 Honza Novák Plzeň 12345 Junior Developer 30000 Z této tabulky je vidět kromě závislosti všech atributů na klíči ještě závislost PSČ a Města a závislost Platu na Funkci. Aby jsme si to ukázali pomocí obou vyjádření definic. Závislost r.č -> Město -> PSČ je tranzitivní závislost PSČ na klíči, stejně tak závislost r.č. -> Funkce ->Plat. Pochopitelnější je asi druhé vyjádření, podle něj jsou závislosti Město -> PSČ a Funkce ->Plat přesně ty, které porušují sousloví: "všechny neklíčové atributy jsou navzájem nezávislé". Řešením problému je opět rozpad na více relací, v tomto případě dokonce na 3, protože jsme 3.NF porušily rovnou dvakrát.
Zaměstnanec r.č 1 2 3 4 5 6
Jméno Jack Franta Pepa Pavel Petr Honza
Příjmení Smith Vomáčka František Novák Koukal Novák
Město_ID 1 2 4 3 2 4
Funkce_ID 1 2 2 4 3 4
Město Město_ID Město PSČ 1 Jihlava 58601 2 Praha10 10000 3 Kocourkov 99999 4 Plzeň 12345 Funkce Funkce_ID Funkce 1 CEO 2 Senior Software Architect 3 Database Designer 4 Junior Developer
Plat 150000 80000 75000 30000
Zjednodušeno(jiný zdroj): Zakazuje tranzitivní funkční závislosti. Formálně: neexistuje klíč Klíč schématu R, podmnožina P schématu R a neklíčový atribut X, který není v P obsažen, aby Klič->P->X, ale přitom neplatilo P>Klíč ani x->Klíč. V tabulce Zaměstnanec( RČ, Č_Vedoucího, Č_Oddělení) lze Č_Vedoucího odvodit z Č_Oddělení. Klíčem do tabulky je přitom RČ zaměstance. (Nešikovné je to , protože při změně vedoucího nějakého oddělení budu muset projít všechny zaměstnance toho oddělení a vedoucího u nich upravit.)
3.4 Boyce Coddova normální forma - BCNF Boyce/Coddova normální forma se pokládá za variaci třetí normální formy a dokonce je původní definicí 3.NF tak jak byla publikována v 70 letech. Je vymezena stejnými pravidli jako 3.NF forma, říká, že musí platit i mezi hodnotami uvnitř složeného primárního klíče. Relace se nachází v BCNF, jestliže pro každou netriviální závislost X -> Y platí, že X je nadmnožinou nějakého klíče schématu R. Zní to poněkud šíleně, ale ničeho se nebojte, k tomu, aby byla porušena BCNF musí být splněno několik podmínek a to poměrně specifických: • • •
Relace musí mít více kandidátních klíčů Minimálně 2 kandidátní klíče musí být složené z více atributů Některé složené kandidátní klíče musí mít společný atribut.
Nejsnáze Boyce/Coddovu normální formu pochopíme s pomocí funkčních závislostí. Boyce/Coddova normální forma v podstatě říká, že mezi kandidátními klíči nesmí být žádná funkční závislost. Jak známo, nejlépe se definice chápou na příkladech, takže mějme relaci adresář:
Původní příklad byl odstraněn, byl chybný, tento jsem si vypůjčil ze script Databázové systémy, Prof. RNDr. Jaroslav Pokorný CSc., Ing Ivan Halška Adresa Město Ulice PSČ Praha 10 Černokostelecká 100 00 Jihlava Žižkova 58601 Praha 10 Vrátkovská 100 00 Brno Dvořákova 589 74 Praha 6 Chaloupeckého 160 00 V této relaci platí dvě netriviální funkční závislosti: {Město,Ulice} -> PSČ a PSČ -> Město Protože neplatí Ulice -> PSČ ani Město -> PSČ, tvoří dvojice {Město, Ulice} klíč schématu. Klíčem je ale i {Ulice, PSČ} platí totiž PSČ -> Město, nikoliv však PSČ -> Ulice. Tudíž je {PSČ, Ulice} kandidátním klíčem schématu. Schéma má všechny atributy atomické a nemá žádný neklíčový atribut a tudíž je v 3.NF, ale není v BCNF. Tento fakt vede k tomu, že nelze evidovat města s PSČ bez znalosti Ulice a krom toho jsou v relaci redundantní data, pokud by se evidovalo velké množství ulic v jednom městě, začal by to být problém. Klasické řešení, rozpad na dvě tabulky. Vzhledem k tomu, že neplatí PSČ -> Ulice, musíme spojit PSČ a Ulice. Výsledkem tudíž budou relace Města(PSČ, Město) a Ulice(PSČ, Ulice) Město PSČ Město 100 00 Praha 10 160 00 Praha 6 586 01 Jihlava Brno 589 74 Adresa Ulice Černokostelecká Vrátkovská Dvořákova Chaloupeckého Dvořákova
PSČ 100 00 100 00 586 01 160 00 589 74
Zjednodušeno(jiný zdroj): Nedovoluje ani tranzitivní závislost klíčových atributů, tj. obsahuje pouze body 1. a 2. : 1. závislost je triviální, tj. atribut x je obsažn v Y, 2. Y je nadklíč schématu A
3.5 Čtvrtá normální forma - 4NF Tabulka je ve čtvrté normální formě, je-li v BCNF a popisuje pouze příčinnou souvislost (jeden fakt). Sice jednoduché vyjádření bez složitých definic, ale poněkud nicneříkající, takže zkusíme jinou definici: " Relace je ve čtvrté normální formě, pokud je v Boyce/Coddově normální formě, a navíc všechny vícehodnotové závislosti jsou zároveň funkčními závislostmi z kandidátních klíčů. " Mno koukám, že jsem tomu moc nepomohl, tak zkusíme definici a příklad ze skript Tvorba datového modelu v prostředí strategických informačních systému, Prof. Ing. Jindřich Kaluža, CSc. :
"ve čtvrté normální formě je relace tehdy, je-li v BCNF a všechny vícehodnotové závislosti obsažené v relaci jsou zároveň funkčními závislostmi. Vícehodnotovou závislost atributů lze definovat následovně: V relaci R, která je v BCNF, s atributy A, B, C nastává vícehodnotová závislost atributu B na atributu A právě tehdy, jestliže množina hodnot B přiřazená dvojici hodnot A, C závisí jen na hodnotě atributu A a je nezávislá na hodnotě atributu C." Tak teď už je to definice přesná a všeříkající, ale bez perfektní znalosti všech použitých pojmů je opět špatně pochopitelná, tudíž příklad si vypůjčím vysvětlení a příklad ze skript Databázové systémy, Vostrovský, Merunka: Čtvrtá normální forma se zabývá vztahy uvnitř složeného primárního klíč. Pokud je v tabulce složený primární klíč, může se stát, že některé hodnoty tohoto klíče jsou na sobě nezávislé, ale tím, že spolu tvoří klíč, vzniká falešná souvislost mezi těmito hodnotami a nemohou existovat nezávisle na sobě, což není v souladu s modelovanou realitou. 4.NF proto vyžaduje, aby klíč tvořily jen ty hodnoty, které mají skutečnou vzájemnou souvislost. Mějme relaci zachycující vztah zaměstnance, kvalifikace a úkolu: Pracovní zařazení(Zaměstnanec, Úkol, Kvalifikace) Pracovní zařazení Zaměstnanec Úkol Kvalifikace Ing Petr Pastyňák Tvorba webu Webdeveloper Ing PetrPastyňák Návrh databáze podnikového IS Database Specialist Eva Petrželová Asistentka Ing Pastyňáka Psaní na stroji Eva Petrželová Asistentka Pastyňáka ECDL Pavel Mrkvička Analytik podnikového IS Aanalyst Pavel Mrkvička Analytik podnikového IS UML Všechny atributy dohromady tvoří klíč schématu a neexistuje mezi nimi žádná funkční závislost, tudíž je v BCNF a všechno vypadá ideálně, ale není tomu tak. I když se dá předpokládat, že atributy Kvalifikace a Úkol jsou na sobě nezávislé, tak tabulka neumožňuje zachytit kvalifikaci zaměstnance, který nemá přiřazen žádný úkol (a úkolujte někoho o kom netušíte co umí) a nelze ani úkolovat zaměstnance bez kvalifikace. Krom ztráty informací se rozkladem vyvarujeme i redundance dat. Tudíž je opět nutno tabulku rozdělit a to na dvojici: Kvalifikace (Zaměstnanec, Kvalifikace), Úkol (Zaměstnanec, Úkol). Kvalifikace Zaměstnanec Ing Petr Pastyňák Ing Petr Pastyňák Eva Petrželová Eva Petrželová Pavel Mrkvička Pavel Mrkvička Ing Petr Cibula Ing Petr Cibula
Kvalifikace Webdeveloper Database Specialist Psaní na stroji ECDL Aanalyst UML Project manager RUP Specialist
Úkol Zaměstnanec Úkol Ing Petr Pastyňák Tvorba webu Ing Petr Pastyňák Návrh databáze podnikového IS Eva Petrželová Asistentka Ing Pastyňáka Pavel Mrkvička Analytik podnikového IS Jan Celer Kopání odvodňovacího kanálu Do rozložených relací jsem záměrně přidal data, která v původní relaci nebyla, ale měla by být. Krásně se tím ukazuje, jak snadné je teď najít project m,anagera na tvorbu podnikového IS, ale zkuste si to v nenormalizované tabulce, když pan Cibula zrovna nemá přidělen žádný úkol.
