Normální formy – MySQL – Fórum – Programujte.com

Prosím někoho o vysvětlení 3. NF (Normální Formy).

Z jednoho zdroje mám, že se jedná o odstranění redundance. A z jiného zdroje, že se jedná o tranzitivní závislost a její odstranění.   

Kde / Co je tedy pravda?

mozna postaci viki
https://cs.wikipedia.org/…%C3%AD_forma

Dostanes od sefa tabulku z excelu s kontakty na pracovniky. Je tam nekolik sloupcu, ve kterych se hodnoty opakuji. Idealnim resenim je, udelat si pro cely takovy sloupec ciselnik, pomocnou tabulku (id, text)
lojza, Navratilova 17, praha
pavel, destova 13, ostrava

3 forma je takova, kdy si udelas ciselnik nad sloupcem mesto. Logicka volba. (a soucasne cokoliv v 1 a 2 forme). Kdyz mas vsechno, co jde, jako ciselnik. V tomto pripade jen to mesto. jmena jsou vicemene unikatni, totez adresy. Ale mesta, ty se nebudou menit, to bude pevny vyber, tabulka, kde, kdyz prejmenujes Zlin na Gottwaldov, tak chces aby se to zmenilo u vsech uzivatelu. Kdezto, kdyz lojza zmeni pohlavi a prejmenujes ho na bedriska, tak chces, aby se to zmenilo jen u nej a ne u vsech lojzu

2 forma, kdyz mas zamestnance treba mas oddelene zvlast v tabulce Ale treba mas i veci, ktere nejsou v tabulce, jako treba prave mesta

1 forma je, ze nemas pomocnou tabulku nad nici, cili holou excelovou tabulku. Kdyz ti tam nekdo udela preklep u par lidi a napise Ostrav misto Ostrava, tak par lidi bude mit udaje spatne. Coz je to, co asi nechces. Chces mit data co nejvice spravne, co to pujde. Ale tahle podoba se treba da pouzit u malych tabulek do 10-100 radku. Kdy nema moc smysl pro sloupce vytvaret dalsi a dalsi minitabulecky.
A take je to podoba, kterou chces dostat na vystupu, kdyz delas export do cvs/excelu.

Kazdopadne je to pekna teorie z dob, kdy bylo misto na disku drahy a nikdo nekoukal na rychlost. Ale jakmile zacnes delat mnohourovnovy joiny nad velkejma tabulkama (idealne pro desitky lidi zaroven), tak pri ladeni vykonu nakonec vypadne neco mezi 1. a 2. NF.

Mozna v objektovych databazich by to fungovalo dobre

#1 Jan
Nejprve si přečti Třetí normální formu na Wikipedii

Odstranění tranzitivních závislostí se řeší už v 2NF. Ve 3NF je stanoveno, že každý atribut musí být závislý na celém primárním klíči a pouze na něm, což je u jednosloupcového primárního klíče de facto samozřejmostí.

V praxi obvykle postačí, když databáze splňuje právě 3NF.

#4 Kit
Dovolím si nesouhlasit s tvým tvrzením. 3. NF "Every non-prime attribute of R is non-transitively dependent on every key of R. "      viz. https://en.wikipedia.org/wiki/Third_normal_form

A 2. NF (https://en.wikipedia.org/…_normal_form) " (2)  not have any non-prime attribute that is dependent on any proper subset of any candidate key of the relation. "

Takže, jestli jsem to pochopil, tak 2. NF je o té redundanci (opakování) stejného konkrétního slova v sloupečku tabulky u vícero záznamů (řádků)?

KIIV - "pri ladeni vykonu nakonec vypadne neco mezi 1. a 2. NF" - S tim bych nesouhlasil. Souhlasim, ze u mnoha tabulek je problem napsat sql dotaz. Ale urcite spravne napsany dotaz nemuze byt na urovni rychlosti obycejne tabulky. Takovy pripad si neumim realne predstavit. Jedine, pokud je dotaz spatne a nebo mas v tabulce binarni delku id podobnou name, cili, velmi kratka name. A nebo je to prilis aktivni tabulka a ciselnik id je prilis vysoky, cili opet delka id je podobna name. Netvrdim, ze se to nemuze stat, jen se mi to nezda jako bezne potkatelne.