Vlákno názorů k článku Modelování databází od Libor Vanek - Ackoliv mam z toho nekolik zkousek, tak furt...

Ackoliv mam z toho nekolik zkousek, tak furt nechapu, co je mysleno temi NF (tu 1. NF chapu, ale 2. a 3. uz ne) - muzete mi nekdo uvest nejaky priklad neceho, co neni a proc neni 2. NF a 3. NF? Moc d', Libor

skus pozriet http://fria.fri.utc.sk/~kmat/dbs/dbs.html
su to skripta o databazovych systemoch, kapitola 7 je venovana normalizacii datoveho modelu, urcite tam nieco vhodne najdes.

Příklad:
Místo rod. čísla bude dohromady klíčem datum narození, pohlaví a část za lomítkem (z toho se dá odvodit RČ). Pak když bude nějaký atribut záviset např. pouze na pohlaví, nesplňuje to 2. NF (závisí na podklíči, nikoli na celém klíči).

Jiný příklad:
Mějme např. databázi platebních příkazů, každý bude obsahovat mj. název banky a její číselný kód. Za předpokladu, že každá banka má přiřazen právě 1 kód, nebude splněna 3. NF (závislost na jiném atributu než klíči, jinak řečeno tranzitivní závislost na klíči).

V případě pochybností vysvětlí odborník na databáze ing. Halaška (halaska@fel.cvut.cz) nebo přímo náš databázový guru prof. Pokorný (pokorny@fel.cvut.cz, pokorny@mff.cuni.cz).

Mel jsem v rukou skripta od p.Pokorneho z CVUT a musim rict, ze to byla jedna z nejlepsich veci co jsem na dane tema videl. Dopurucuji k precteni kazdemu kdo chce prekrocit horizont "instatnich" clanku/manualu o SQL a zaroven nezkoncit u pouhe matematiky :-)

Omlouvam se za to, ze jsem v clanku neuvedl ukazky NF, snad nekdy priste.

Z mého (laického) pohledu jde vesměs o to, aby v datech nebyly žádné duplicity údajů.
Co myslel autor 2.NF si taky nejsem až tak jistý.
3.NF by podle toho jak to popisuje mělo být toto:
Když mám tabulku FIRMY a ZAMESTNANCI a do ZAMESTNANCI zapíšu na každý řádek nejen cizí klíč, který mi to propojuje do FIRMY, ale navíc ještě adresu firmy, pak to ve 3.NF NEBUDE. Když tam tu adresu (duplicitní údaj) neuvedu, ve 3.NF to BUDE. Nemusí to ale být jen takovéto surové opsání údaje duplicitně, ale i nějaká kalkulace - např. když v ZAMESTNANCI mám DatumNarozeni a do FIRMY bych si přidal pole (atribut) PrumernyVek, uz to NEBUDE ve 3.NF, protoze je to duplicitní informace k tomu ZAMESTNANCI.DatumNarozeni.
Autor zde vlastně popírá sám sebe (toto se traduje u naprosté většiny analytiků) tím, že píše: "vyhledáme klíčové atributy". Použití atributu (který něco reálně popisuje) jako klíče totiž porušuje 3.NF, tj. zavádí zbytečnou duplicitu. Kromě asi 5-ti dalších dobrých důvodů stačí už toto, abychom nikdy jako klíč nepoužívali reálný údaj, ale raději nějaké automaticky generované ID.

Parciální a tranzitivní závislosti jsou IMHO tak triviální věci, že nerozumět jim je snad skoro zločin. Vámi zmiňovaný příklad ZAMESTNANCI.DatumNarozeni vs. FIRMY.PrumernyVek je nesmysl, protože o tomhle 3.NF rozhodně není. Přečtěte si tu definici ještě jednou a pomalu! Já jsem si nevšiml, že by tam byla zmínka o větším počtu tabulek než jedna. Každá hraje, pokud jde o NF, sama za sebe. Apropos, průměrný věk je očividným kandidátem na COMPUTED sloupec nebo na zařazení do pracovního pohledu místo do tabulky. Takže to ani nemusí být perzistentní pole a klidně si může žít vlastním životem bez ohledu na nějaké normálové formy :) Chyb ve vašem příspěvku je mnoho, je jedna ráno a já nemám sílu je hledat...dost na tom, že tu dřepím, nadávám na hlásky Informixu, které si snad psali vývojáři sami a lokalizovat to po nich je práce pro vraha :/