Jak poznat, že je návrh databáze správně a že bude fungovat?

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.

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.

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čí.

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)

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.

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.