answered
2014-12-27 15:20:55 +0100
Ad a): Potřebujeme takovou minimální množinu atributů, že po aplikaci funkčních závislostí na ni získáme množinu všech atributů. Řeší se to tak, že si stanovíte, že v klíči chcete mít atribut x, zjistíte, které další atributy z něj dokážete dostat pomocí funkčních závislostí, a vyjde vám množina atributů, ke které se nedá dostat. Tak si jeden z nich vyberete a přidáte ho do klíče. A tohle pořád opakujete, dokud nepokryjete celý klíč. Takže např. ve vašem příkladu si zvolíte a a zjistíte, že funkčními závislostmi se nikam dál nedostanete; ale zároveň si všimnete, že kdybyste měl i b, tak už vám aspoň jedna funkční závislost bude fungovat, takže začnete s klíčem a, b. Podle druhého pravidla se pak dostanete i k d, a když už máte d, tak třetí pravidlo vám udělá i c a máte pokryté všechny atributy. Takže a, b by byl jedním z klíčů. Teď totéž vyzkoušíte i pro všechny ostatní atributy a dostanete množinu potenciálních klíčů.
Případně se dá postupovat i obráceně - začnete s tím, že klíčem je množina všech atributů, a potom jdete "proti směru" funkčních závislostí a vyřazujete ty sloupečky, které "nepotřebujete". Takže z a, b, c, d můžete podle druhého pravidla vyřadit d a podle prvního a a zbyde vám klíč b, c.
Ty druhé dva dotazy neberte se stoprocentní zárukou, v praxi to moc nepoužívám (z výkonnostních a jiných důvodů je často vhodné vyšší normální formy nevytvářet) a když už, tak metodou "kouknu a vidím". Teď jenom vzpomínám, jak přesně to v teorii funguje.
ad b): Aby byla relace ve třetí normální formě, musí být v 1NF (atomické atributy), 2NF (1NF + ne-klíčové atributy jsou závislé na celém klíči) a 3NF (2NF + ne-klíčové atributy jsou závislé pouze na klíči).
Atomické atributy - z vašeho zadání se to moc nepozná, ale v praxi to obvykle pokládáme za splněné. Nebylo by to splněné, kdyby některý atribut mohl obsahovat třeba nějaký seznam položek. Teoreticky vzato je otázka, jestli atribut typu DATE nebo DATETIME je nebo není atomický, protože sice ho obvykle chápeme jako jeden celek, ale můžeme přistupovat i k jeho komponentám.
Ne-klíčové atributy závislé na celém klíči - Podíváte se na kandidátní klíče (všechny) a na funkční závislosti a hledáte, jestli se dá některý atribut vyjádřit pomocí jenom části klíče. Kdybyste třeba došel k tomu, že klíčem nutně musí být a, b, c, tak snadno uvidíte, že atribut d je závislý jen na a, b a ne na c, takže relace s takovým klíčem by určitě nebyla v 2NF.
Ne-klíčové atributy závislé pouze na klíči - Nesmí vám nastat situace, kdy by se k některému atributu dalo dostat třeba kombinací (části) klíče a ne-klíčového atributu. Ve vašem případě, máte klíč např. b, c a je zřejmé, že k atributu d se jenom pomocí nich dostat nedokážete, potřebujete ještě a, abyste mohl použít druhou funkční závislost. Takže relace zjevně není v 3NF. (Ovšem pouze za předpokladu, že d je ne-klíčový atribut, tzn. není součástí žádného kandidátního klíče, to jsem nezjišťoval.)
ad c): Aby relace byla v BCNF, musí být v 3NF a navíc netriviální závislosti musí být závislostmi na nadklíči. Nebo jinak, pro všechny funkční závislosti X -> Y musí platit, že buď jde o triviální závislost (např. X -> X nebo (x, y) -> (y)), nebo X je kandidátní klíč. Takhle spatra bych řekl, že třetí funkční závislost tohle poruší, protože není triviální a nejspíš nedokážu udělat kandidátní klíč jenom ze samotného d. Asi to tedy bude chtít vyexpedovat c do samostatné relace. Ale tady už fakt dost vařím z vody.