Autor Zpráva
sqlman
Profil *
Ahoj.

Nemám problém vytvořit databázi, kterou potřebuji, ale problém je v tom (protože o tom nevím vše), že nevím, jak poznám, že je můj návrh databáze správný a že to bude URČITĚ fungovat. Chtěl bych se tedy zeptat, jak to tedy poznám a zda byste mi případně doporučili nějakou literaturu či odkazy na spolehlivé zdroje na internetu.

Díky :-)
Alphard
Profil
Abyste to mohl vědět určitě, musel byste mít zcela jasné zadání, které se už nebude měnit. To jsem v praxi ještě neviděl :-)
Obecně to chce nějaké zkušenosti s programováním, pak vám bude jasné, jestli je daná struktura vhodná pro požadovaný účel, jestli tam hrozí nějaké problémy, na co si dát pozor. Určité zdroje existují, webové i knížní, ale většinou je to vše ve stylu rozebírání řešení a nějaké vymyšlené zadání, které se kromě učebnicových příkladů nebude schodovat s vaší aplikací. V první řadě doporučuji vaší pozornosti normální formy.
juriad
Profil
Nastuduj si něco o normálových formách. Pokud je budeš dodržovat (což pravděpodobně teď stejně děláš intuitivně) nehrozí, že by ses chytil do pasti.
Teoreticky by mělo stačit splnit všechny NF. (Pozor, prvních několik uvádí všechny zdroje, vyšším se věnuje málokdo.)
Další otázkou je pak výkon takového schématu.
Zechy
Profil
Tak samotné ERD ani neni o tom, aby řešilo programové chyby, ono ani s tim nepočítá. Jedná se pouze o návrh jak tabulky budou propojeny a co v nich bude. Během programování databáze, kdy se narazí na chyby se, ale může návrh mírně změnit :).

Co se týče normálových forem, existuje jich asi 4 nebo 5, ale normálně se používají pouze 3 formy, ani Oracle ty poslední formy nějak extra neučí.
Joker
Profil
juriad [#3]:
Ten příspěvek je ohledně normálních forem až moc optimistický, spíš je to „něco za něco“.
Normalizace řeší tyto problémy:
• Existují informace, které v databázi jsou uložené a přitom je nelze získat výběrem sloupců určitých záznamů.
• Některé reálné hodnoty sledovaných záznamů nelze do databáze uložit.
• Některé informace jsou v databázi uložené vícenásobně.

Na druhé straně se za to platí výkonem. Normalizace vesměs spočívá v rozdělování na více tabulek, takže ve vysoce normalizované databázi je pomalu každý jednoduchý výběr JOIN přes několik tabulek.

Právě proto se obvykle říká, že má smysl normalizovat tak na 3. NF, možná „třiapůltou“ BCNF, ale výš obvykle ne.

Zechy:
existuje jich asi 4 nebo 5
Těsně vedle, je jich šest :-)
Resp. poslední je 5. NF, ale jsou „dvě třetí“ (3. NF a BCNF)
Zechy
Profil
Joker:
ale jsou ‚dvě třetí‘ (3. NF a BCNF
To bude asi ono :-) MY máme naučeno z databází že existují 1, 2, 3, 4, 5, o BCNF jsem nevěděl.
Joker
Profil
Zechy:
Nám to vykládali tak, že původně byla jen 1.-5. NF a dnešní BCNF byla 3. NF.
Časem se ale ukázalo, že požadavek na nezávislost všech atributů je až moc přísný, v mnoha aplikacích by se hodilo dovolit závislost v rámci složeného klíče.
Tak vznikla nová 3. NF s požadavkem na nezávislost jen neklíčových atributů a původní 3. NF byla změněna na BCNF alias „třiapůltou NF“.

I z toho (že pro mnoho aplikací je vhodná 3. NF) je vidět, že není vždycky dobré normalizovat na co nejvyšší NF.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: