11. blok Normalizace Studijní cíl Využití normalizace při návrhu databáze. Vliv nenormalizovaných tabulek na vznik anomálií a nekonzistence v databázi. Pravidla spojená s nejužívanějšími normálními formami (1NF,2NF,3NF). Odstraňovaní chyb a redundancí z tabulek, které nesplňují normální formy. Doba nutná k nastudování 2-3 hodiny Průvodce studiem Při studiu tohoto bloku se předpokládá, že čtenář je obeznámen se základními pojmy z databázového modelování, jako jsou entity, atributy, relace atd. 1 Úvod do normalizace Tento studijní blok se snaží poukázat na důležitost normalizace při návrhu databáze. Zároveň se snaží pohlížet na normalizaci jako užitečnou techniku při kontrole struktury tabulek odvozených z ER modelu. Prakticky se dá normalizace využít pomocí dvou přístupů. Jednak se dá využít přístupem zdola nahoru (bottom-up), jednak se dá využít přístupu shora dolů (top-down). Při normalizaci za využití přístupu zdola nahoru se studují souvislosti mezi jednotlivými atributy a na základě analýzy těchto souvislostí jsou jednotlivé atributy seskupeny do tabulek, které reprezentují výsledné entity a relace. V případě velkého množství atributů je velmi obtížné tento přístup použít, protože je pak obtížné zavést všechny vztahy mezi atributy. Při normalizaci za požití přístupu shora dolů se využívá ER modelování, v rámci kterého se namodelují základní entity, atributy a relace. ER model je následně převeden na tabulky a tabulky následně projdou normalizací. Předně je dobré zdůraznit, že technika normalizace byla vyvinuta v roce 1972 E. F. Coddem pro podporu návrhu databází založených na relačním modelu. Technická definice normalizace říká: Normalizace je technika používaná pro vytvoření sady tabulek s minimální redundancí, která podporuje datové požadavky organizace. 1
Jiné definice hovoří o normalizaci jako o sadě testů prováděných na jednotlivých tabulkách, aby se zjistilo, zda jsou dodržena pravidla pro tzv. normální formy. Normálních forem existuje celá řada, ale mezi ty nejužívanější normální formy paří první normální forma (1NF), druhá normální forma (2NF) a třetí normální forma (3NF). Společným rysem všech tři normálních forem je jejich založení na vztazích mezi sloupci v tabulce. V následující části dokumentu budou jednotlivé normální formy vysvětleny. Dále budou popsány příklady chybně navržených tabulek spolu s ukázkami, jak tento chybný návrh může způsobit následnou redundanci dat spolu s anomáliemi vznikajícími při aktualizaci. 2 Redundance dat a anomálie aktualizace Jedním z cílů, ke kterému by měl každý návrh databáze směřovat, je omezení (nebo úplná eliminace) redundance dat. Je tedy nutné jednotlivé atributy seskupit/rozdělit do tabulek, tak aby prostor pro uložení navržených tabulek byl co nejmenší. Pro ilustraci jsou zvoleny tabulky Studenti a Fakulty. cislostudenta jmeno email cislofakulty st12456 Jan Novák novak@up.cz f1 st14527 Tomáš Nový novy@up.cz f2 st18621 Petr Jakš jaks@up.cz f2 st11821 Jan Houser houser@up.cz f1 st12333 Josef Levý levy@up.cz f3 1 Tabulka Studenti cislofakulty nazev adresa f1 Elektrotechnika Jungmanova 475, Praha 1, 110 00 f2 Ekonomická Fugnerova 487, Praha 2, 120 00 f3 Humanitní Národní Třída 15, Praha 1, 110 00 2 Tabulka Fakulty cislostudenta jmeno email cisfak nazev adresa st12456 Jan Novák novak@up.cz f1 Elektrotechnik a Jungmanova 475, Praha 1, 110 00 st14527 Tomáš Nový novy@up.cz f2 Ekonomická Fügnerova 487, Praha 2, 120 00 st18621 Petr Jakš jaks@up.cz f2 Ekonomická Fügnerova 487, Praha 2, 120 00 Jungmanova 475, Praha 1, 110 00 st11821 Jan Houser houser@up.cz f1 Elektrotechnik a st12333 Josef Levý levy@up.cz f3 Humanitní Národní Třída 15, Praha 1, 110 00 3 Tabulka StudentiFakulty 2
Tabulka StudentiFakulty je alternativní reprezentací tabulek Studenti a Fakulty. Tabulka StudentiFakulty již na první pohled obsahuje redundantní data. Údaje o fakultě (název, adresa) se opakují pro každého studenta znovu a znovu. V tabulce student se opakovalo jen číslo dané fakulty jako údaj o tom, kde daný student studuje. Ovšem to, že se data v tabulce opakují, není jediný problém spojený s redundancí dat. Spolu s redundantními daty jsou potenciálně spojeny následující anomálie. Anomálie vkládání, anomálie vymazání a anomálie modifikace. Anomálie vkládání Pokud bude vložen do tabulky StudentiFakulty nový záznam o studentovi studujícím na určité fakultě, musí údaje o fakultě u nového studenta přesně souhlasit s údaji o fakultě u ostatních studentů, kteří studují stejnou fakultu. Zde hrozí, že pokud uvedeme u stejné fakulty různé adresy, pak v tabulce budou existovat pro stejnou fakultu různé adresy a nebude možné identifikovat, která adresa je ta správná. Tabulka Studenti tímto neduhem netrpí, jelikož všichni studenti stejné fakulty odkazují na jeden záznam a tím tudíž i na jednu adresu. Navíc se v tomto případě uchovávat daný záznam o fakultě jen jednou, což v případě mnoha záznamů v tabulce Student, může znamenat značnou úsporu diskového prostoru. Druhý problém spojený se vkládáním do tabulky podobné StudentiFakulty nastává ve chvíli, kdy je nutné vytvořit novou fakultu, která ale ještě nemá žádné studenty. V tomto případě by se to rovnalo vyplnění sloupců týkajících se jen fakulty a informace o studentovi vyplnit hodnotou NULL. Ale co když je jeden ze sloupců týkajících se studenta definován jako povinný (NOT NULL)? V tomto případě by se tedy jednalo o porušení integrity a daná operace by byla zamítnuta. První dvojice tabulek tímto netrpí. Nová fakulta bude vytvořena vložením příslušného záznamu do tabulky fakulta. Samotné studenty fakulty je možné zadat až později. Anomálie vymazání V situaci, kdy by byl vymazán záznam z tabulky StudentiFakulty obsahující posledního studenta fakulty, nenávratně by byla smazána z databáze i příslušná fakulta. V dané tabulce by záznam o fakultě přestal existovat. Například smazaní studenta Josef Levý by způsobilo zároveň i smazaní humanitní fakulty, neboť už se u jiného studenta v tabulce nevyskytuje. První dvojce tabulek opět tento problém nemá. Pokud z tabulky Student smažeme studenta Josef Levý, tak fakulta pouze přijde o posledního studenta, ale jinak informace o fakultě stále zůstanou v tabulce Fakulty. 3
Anomálie modifikace V případě, že mají byt změněny hodnoty jednoho ze sloupců s údaji o fakultě, například může být měněna adresa fakulty, musí být modifikace provedena na všech záznamech tabulky, jež se týkají dané fakulty. Vynechání aktualizace byť jednoho záznamu způsobí, že data v databázi budou nekonzistentní. U tabulky Fakulty toto nehrozí, jelikož je vždy aktualizován jen jeden záznam. Jak je z uvedených příkladů patrné, rozložení entity na dvě (i více) tabulky je velmi výhodné. Nejen že se tím odstraní problém s redundancí dat, ale zároveň nehrozí žádná ze zmíněných anomálií. Nyní budou probrány jednotlivé normální formy spolu s jejich využitím pro vytvoření tabulek s požadovanými vlastnostmi, které netrpí problémy způsobenými výše uvedenými anomáliemi. 3 První normální forma (1NF) Definice první normální formy říká: Tabulka je v první normální formě, jestliže lze do každého pole dosadit pouze jednoduchý datový typ (jsou dále nedělitelné). Alternativní definice o první normální formě říká, že průsečík sloupce a záznamu (řádku) obsahuje vždy jen jednu hodnotu. Dodržení první normální formy je kritické pro definování vhodných tabulek relační databáze. Dodržení této formy je prakticky povinné. Ostatní normy se dají považovat za volitelné, i když, aby se předešlo výše uvedeným anomáliím, doporučuje se používat minimálně třetí normální formu. cisfak nazev adresa telefon f1 Elektrotechnika Jungmanova 475, Praha 1, 110 00 2871471245,728747474,736788 545 f2 Ekonomická Fügnerova 487, Praha 721784458,245781236 2, 120 00 f3 Humanitní Národní Třída 15, Praha 1, 110 00 721556566 4 Tabulka Fakulty (nesplňující 1NF) Tabulka Fakulty není v první normální formě, protože její sloupec telefon nevyhovuje definici 1NF. Je to způsobeno tím, že Elektrotechnická a Ekonomická fakulta obsahují ve sloupci telefon dvě telefonní čísla, což je v přímém rozporu s 1NF. Svým způsobem může být pozornost zaměřena i na sloupec adresa. Může být o něm prohlášeno, že obsahuje více hodnot. Nejedná se však o stejnou vadu jako u sloupce telefon, kde se opakovalo více telefonních čísel. Zde se vždy jedná jen o jednu adresu, avšak která se skládá s více hodnot. Jedná se tedy o složený atribut, který by bylo vhodné rozdělit na jednoduché atributy. 4
Pokud bychom ovšem pod atributem adresa chtěli vidět (kdykoli v budoucnu pracovat s těmito dílčími atributy) ulici, číslo popisné, PSČ a město, pak bychom to takto prohlásit nemohli, jednalo by se o složený atribut a bylo by vhodné jej rozdělit do několika samostatných sloupců. Rozdělení do několika samostatných sloupců by navíc mohlo přinést i výhodu spočívající v přesnější definici domén jednotlivých atomických sloupců, která může zajistit i vyšší integritu dat. Alternativním řešením by bylo použití jasně definované a bezpečné struktury atributu adresa, která by takové přesné rozdělení umožnila nebo použití strukturovaného datového typu (např. typu OBJECT), což však překračuje hranice tohoto kurzu. Aby tabulka splňovala 1NF, musí dojít k přesunutí sloupce telefon, spolu s kopií primárního klíče tabulky Fakulta, do nové tabulky nazvané například FakultyTelefoy. Po normalizaci tedy zůstanou dvě tabulky: cisfak nazev adresa f1 Elektrotechnika Jungmanova 475, Praha 1, 110 00 f2 Ekonomická Fügnerova 487, Praha 2, 120 00 f3 Humanitní Národní Třída 15, Praha 1, 110 00 5 Tabulka Fakulty (splňující 1NF) řešení s ponecháním sloupce adresa 4 Druhá normální forma (2NF) cisfak telefon f1 2871471245 f1 728747474 f1 736788545 f2 721784458 f2 245781236 f3 721556566 6 Tabulka FakultyTelefony Definice druhé normální formy říká: Tabulka je ve druhé normální formě, pokud je v první normální formě a zároveň, jsou hodnoty každého sloupce, který není součástí primárního klíče, determinovány všemi hodnotami sloupců, které tvoří primární klíč. Druhá normální forma se tak tedy týká jen tabulek, které obsahují složený primární klíč (primární klíč tvoří dva a více sloupců). Z toho vyplývá, že tabulka, která je v 1NF a zároveň její primární klíč je tvořen pouze jediným sloupcem, je automaticky také v 2NF. Pokud se tabulka nenachází v 2NF, hrozí jí anomálie spojená s aktualizací. S pojmem determinovat uvedeným v definici druhé normální formy úzce souvisí pojem funkční závislost. Funkční závislost popisuje vztah mezi sloupci v tabulce 5
a indikuje to, že tyto sloupce spolu souvisí. Pokud by existovala tabulka se sloupci a a b, kde by sloupec a determinoval sloupec b, tak by tento vztah byl označen jako a -> b. Z tohoto vztahu vyplývá, že pokud známe hodnotu a, najdeme k ní vždy jen jednu hodnotu b. Opačně tento vztah nefunguje, jelikož pro jednu hodnotu b může existovat několik hodnot a. Uvažujme následující tabulku, která druhou normální formu nesplňuje: cislostudent kodpredmet jmeno email Známka datum st12124 IDAS2 Jan Nový novy@up.cz 1 25.1.2012 st12124 IMAT Jan Nový novy@up.cz 2 2.1.2012 st14754 IDAS2 Petr Levý levy@up.cz 3 5.1.2012 st14754 INPIN Petr Levý levy@up.cz 1 10.1.2012 7 Tabulka StudentiZkousky Nechť tabulka StudentZkouska slouží pro zapisování výsledů zkoušek jednotlivým studentům. Tabulka obsahuje složený primární klíč, tvořený sloupci cislostudent a kodpredmet, který jednoznačně identifikuje studenta, kterému byl výsledek zapsán a zároveň identifikuje předmět, ve kterém tohoto výsledku daný student dosáhl. Při bližším pohledu na tabulku je zřejmé, že tabulka je v 1NF. Žádný její sloupec neobsahuje více hodnot. Ve druhé normální formě však tato tabulka už není. Příčinu toho, proč tato tabulka není ve 2NF, pomůže odhalit termín funkční závislosti. Každý sloupec v tabulce, který není součástí primárního klíče, je zkoumán pomocí funkční závislosti na celém primárním klíči. Tabulka pak není ve 2NF, pokud se při testování zjistí, že alespoň jeden sloupec tabulky je pouze částečně závislý na primárním klíči. Tento jev se nazývá částečná závislost. Pokud je test funkční závislosti aplikován na tabulku StudentZkouska, tak je zřejmé, že sloupce známka a datum jsou funkčně závislé (jsou determinovány) na obou sloupcích primárního klíče (cislostudent,kodpredmet), jelikož konkrétní výsledek zkoušky (známka a datum zápisu známky) se vždy zapisují pro konkrétního studenta a konkrétní předmět. Pokud se ale test funkční závislosti provede na sloupce jmeno a email, je zjištěno, že tyto sloupce jsou závislé pouze na sloupci cislostudent, tudíž se jedná jen o částečnou závislost a proto tabulka nemůže být v 2NF. Kromě toho, že tato částečná závislost způsobuje, že v tabulce StudentiZkousky vznikají redundance a s nimi spjaté anomálie při aktualizacích a podobně. Aby tabulka StudentiZkousky odpovídala pravidlům pro 2NF, je nezbytně nutné odstranit sloupce, které jsou jen částečně závislé na primárním klíči. Tzn. odstranit sloupce jmeno a email. Tyto sloupce se pak umístí do nové tabulky, např. pojmenované Student, kam budou umístěny společně s částí primárního klíče 6
tabulky StudentiZkousky, na které jsou závislý, v tomto případě spolu se sloupcem cislostudenta. Tabulka Student, díky tomu že bude obsahovat jen jeden primární klíč (cislostudenta), bude mít všechny neklíčové atributy plně závislé na primárním klíči, a tudíž bude ve 2NF. Po odstranění sloupců jmeno a email z tabulky StudentiZkousky bude tabulka StudentiZkousky také ve 2NF, protože všechny její neklíčové prvky budou již plně závislé na celém primárním klíči. cislostudent Jmeno email st12124 Jan Nový novy@up.cz st12124 Jan Nový novy@up.cz st14754 Petr Levý levy@up.cz st14754 Petr Levý levy@up.cz cislostudent kodpredmet znamka datum st12124 IDAS2 1 25.1.2012 st12124 IMAT 2 2.1.2012 st14754 IDAS2 3 5.1.2012 st14754 INPIN 1 10.1.2012 8- Tabulka StudentiZkousky po normalizaci 5 Třetí normální forma Ačkoliv v tabulkách s 2NF je mnohem méně redundance než v tabulkách v 1NF, přesto ještě mohou trpět anomáliemi aktualizace. Technická definice třetí normální formy říká: Tabulka, která již je v 1NF a 2NF a ve které jsou všechny hodnoty ve sloupcích, které nepatří k primárnímu klíči, jsou determinovány pouze sloupci primárního klíče a nejsou determinovány žádnými jinými sloupci. Se třetí normální formou dále souvisí pojem tranzitivní závislost. Tranzitivní závislost popisuje vztah mezi sloupci a, b a c. Pokud a determinuje b (a -> b) a b determinuje c (b -> c), pak sloupec c je tranzitivně závislý na a prostřednictvím b (pokud b nebo c nedeterminuje a). Příklad tranzitivní závislosti je vidět na následující tabulce Student. cisstud jmeno email mesto cisfak nazevfak st12475 Tomáš Bok bok@up.cz Praha f1 Elektrotechnická st18745 Jan Nový novy@up.cz Kolín f1 Elektrotechnická st12654 Petr Petr petr@up.cz Brno f2 Ekonomická st17875 Jan Zach zach@up.cz Přelouč f2 Ekonomická 9 Tabulka Studenti před převodem na 3NF 7
V tabulce Studenti je primárním klíčem sloupec cisstud. Primární klíč je tak tvořen jen jedním sloupcem, tudíž všechny ostatní sloupce jsou na primárním klíči závislé. Tabulka tedy vyhovuje druhé normální formě. Nyní přichází na řadu kontrola tranzitivních závislostí. Sloupce jmeno, email a mesto jsou závislé (determinovány) přímo primárním klíčem cisstud. Sloupce cisfak a nazevfak jsou také závislé na primárním klíči (fakulta, kterou student studuje, je určena právě studentem). Zároveň se ale oba atributy determinují navzájem. Název fakulty je determinován jejím číslem a naopak. Takže například sloupec nazevfak je tranzitivně závislý na primárním klíči cisstud prostřednictvím sloupce cisfak. Tato tranzitivní závislost způsobí, že tabulka nemůže být uznána jako tabulka ve třetí normální formě. Číslo fakulty a její název lze sice jednoznačně identifikovat z primárního klíče cisstud, ale název fakulty můžeme jednoznačně identifikovat i z jejího čísla (cisfak). A právě toto není ve 3NF dovoleno, protože hodnoty sloupců, které nepatří do primárního klíče, musí být určeny výhradně hodnotami sloupce nebo sloupců primárního klíče. Aby byla tabulka převedena do třetí normální formy, musí dojít k odstranění sloupců, které nepatří do primárního klíče a lze je určit pomocí jiných sloupců, které nepatří k primárnímu klíči. V tomto případě bude nutné odstranit sloupce cisfak nebo nazevfak. Výhodnější bude ponechat v tabulce sloupec cisfak a odstranit tak z tabulky Student sloupec nazevfak. Název dané fakulty samozřejmě z databáze nezmizí, je nutné totiž vytvořit novou tabulku, např. Fakulta, která by v tomto případě obsahovala sloupce cisfak (kopie primárního klíče z tabulky Student) a nazevfak. Tím zůstane vazba studenta na fakultu stále zachována. cisfak f1 f2 nazevfak Elektrotechnická Ekonomická 10 Tabulka Fakulty vzniklá normalizací tabulka Student cisstud jmeno email mesto cisfak st12475 Tomáš Bok bok@up.cz Praha f1 st18745 Jan Nový novy@up.cz Kolín f1 st12654 Petr Petr petr@up.cz Brno f2 st17875 Jan Zach zach@up.cz Přelouč f2 11 Tabulka Studenti ve 3NF Tabulka Studenti se tak dostane do třetí normální formy, jelikož nyní jsou všechny sloupce, které nejsou součástí primárního klíče, plně závislé na primárním klíči. Totéž platí i o nově vzniklé tabulce Fakulty. Ta je rovněž ve 3NF, i když zde se dá namítnout, že hodnotu primárního klíče můžeme (cisfak) odvodit z názvu fakulty (nazevfak). Název fakulty lze totiž v tomto případě považovat za kandidátní klíč. 8
Na základě toho lze zobecnit definici třetí normální formy, tak aby zahrnovala i všechny kandidátní klíče. Proto lze definici pro tabulku s více než jedním kandidátním klíčem zobecnit tak, že tabulka je ve třetí normální formě právě když je v 1NF a 2NF a hodnoty všech sloupců, které nepatří primárnímu klíči, je možné určit pomocí sloupců kandidátního klíče (kandidátních klíčů) a není to možné pomocí žádných jiných sloupců. Navíc se dá podobné zobecnění provést i pro 2NF. Definice 2NF pak zní, že se jedná o tabulku v 1NF a hodnoty všech sloupců, které nepatří primárnímu klíči, je možné určit pomocí sloupců kandidátního klíče (kandidátních klíčů) a žádných jiných sloupců. 6 Boyce-Coddova normální forma Boyce-Coddova normální forma (BCNF) je jistou variací třetí normální formy (v podstatě se jedná o původní 3. NF). BCNF normální formu vymezují stejná pravidla jako třetí normální formu. BCNF normální forma navíc říká, že tranzitivní závislost nesmí existovat ani mezi kandidátními klíči. Technická definice BCNF: 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 tabulky. Aby byla BCNF porušena, musí dojít ke splnění několika specifických podmínek: Tabulka musí obsahovat více kandidátních klíčů. Nejméně dva z kandidátních klíčů musí být složené z více atributů. Složené klíče musí mít společné atributy. BCNF bude vysvětlena na následujícím příkladě. Město Ulice PSČ Pardubice Palackého třída 530 02 Praha 1 Zlatá 110 00 Pardubice Průmyslová 530 02 Kolín Jaselská 280 02 Plaňany Pražská 281 04 Praha 1 Široká 110 00 Tabulka 12 Adresy V tabulce Adresy se nachází dvě netriviální funkční závislosti. První z nich je závislost složeného atributu (město, ulice) na atributu psč. Druhou funkční závislostí je psč -> město. Na druhou stranu neplatí že ulice -> psč a neplatí ani město -> psč. Proto platí, že dvojice atributů město a ulice tvoří klíč tabulky. Klíčem tabulky ovšem také může být dvojice psč a ulice. Dá se totiž dokázat, že psč -> město, nikoliv však psč -> ulice (jedna ulice se může vyskytnout ve více městech identifikovaných daným PSČ). Tabulka samotná je ve 3. NF (všechny atributy jsou atomické a tabulka neobsahuje neklíčové atributy), ale BCNF už nesplňuje. 9
To způsobuje, že není možné evidovat samotná města s PSČ bez znalosti jejich ulice. Důsledkem toho se v tabulce objevují redundantní data. Atribut město se bude opakovat tolikrát, kolik ulic z daného města bude tabulka obsahovat. Řešením je tabulku Adresy rozložit na dvě tabulky. Město PSČ Pardubice 530 02 Praha 1 110 00 Kolín 280 02 Plaňany 281 04 Tabulka 13 - Tabulka Mesta Ulice PSČ Palackého třída 530 02 Zlatá 530 02 Průmyslová 110 00 Jaselská 280 02 Pražská 281 04 Široká 110 00 Tabulka 14 - Tabulka Ulice Existují i jiné a vyšší formy než je 3NF a BCNF. Příkladem můžou být čtvrtá a pátá normální forma. Tyto pokročilé formy se však používají jen ve výjimečných případech a řeší jen řídce vyskytující se problémy. Pokročilejší normální formy jsou popsány v: http://www.manualy.net/article.php?articleid=13 Pojmy k zapamatování Pojmy: Normalizace, redundance dat, anomálie aktualizace, anomálie vkládání, anomálie mazání, anomálie modifikace, normální formy (1NF, 2NF, 3NF), Boyce- Coddova normální forma, funkční závislost, úplná funkční závislost, částečná funkční závislost, tranzitivní funkční závislost. Problém: Normalizace navržených tabulek, předcházení anomálií aktualizace, převody tabulek do vyšších normálních forem. 10
Shrnutí Normalizace slouží pro vytvoření databázového modelu obsahujícího tabulky s minimální redundancí dat. Zároveň musí výsledný databázový model podporovat všechny datové požadavky organizace. Pokud tabulka obsahuje redundantní data, trpí tzv. anomáliemi aktualizace. Tyto anomálie jsou dále členěny na anomálie vkládání, anomálie vymazání a anomálie modifikace. Tabulka vyhovuje první normální formě (1NF), jestliže všechny její sloupce obsahují pouze jednu hodnotu. Tabulka splňuje druhou normální formu, pokud je v 1NF a pokud jsou všechny hodnoty sloupců, které nejsou součástí primárního klíče, jsou determinovány všemi hodnotami sloupců, jenž tvoří primární klíč. Tabulka je ve třetí normální formě, pokud už tabulka je ve 1NF a 2NF a zároveň všechny hodnoty sloupců, které nejsou součástí primárního klíče, jsou determinovány pouze sloupci primárního klíče a nejsou determinovány žádnými jinými sloupci. Funkční závislost vyjadřuje vztah mezi sloupci v tabulce a udává, že sloupce mezi sebou souvisí. Pokud například sloupec a determinuje sloupec b, tak to znamená, že pro hodnotu a vždy v tabulce nalezneme právě jednu hodnotu b. Obráceně tento vztah neplatí. Pro jednu hodnotu b totiž může existovat více hodnot a. Plná funkční závislost znamená, že pokud jsou v tabulce sloupce a a b, pak je b plně determinováno a, pokud b není determinováno jen určitou podmnožinou a. Pokud b je determinováno jen určitou podmnožinou a, hovoří se o tzv. částečné závislosti. Tranzitivní závislost je vztah, který vzniká v tabulce se sloupci a, b a c, když a determinuje b a zároveň b determinuje c, pak c je tranzitivně závislý na sloupci a. Otázky na procvičení 1. K čemu se normalizace při návrhu databáze využívá? 2. Jaké druhy anomálií se mohou vyskytnout, pokud se v tabulce objevují redundantní data? 3. Jaký je základní rys tabulek, nesplňující první normální formu (1NF)? 4. Jaké vlastnosti má tabulka ve druhé normální formě? 5. Co znamená funkční závislost? 6. Jaké je rozdíl mezi plnou funkční závislostí a částečnou funkční závislostí? 7. Jak zní definice třetí normální formy? 8. Objasněte pojem tranzitivní závislost. Jakým způsobem souvisí tranzitivní závislost s normální formou. 11
Odkazy a další studijní prameny http://www.manualy.net/article.php?articleid=13 Odkazy a další studijní prameny 1. CONOLLY, Thomas, Carolyn BEGG a Richard HOLOWCZAK. Mistrovství - databáze: profesionální průvodce tvorbou efektivních databází. Brno: Computer Press, 2009. ISBN 978-802-5123-287. 12