Relační datový model

No pro akademické účely docela OK, ale reálně by to bylo velmi problematické ...

1/ Stát - název C30 není noc moc podle ISO normy ( cs.wikipedia.org/... se tam některé názvy nevejdou např. "Heardův ostrov a McDonaldovy ostrovy"má 36 znaků, nikdi nevíte jak dlouze se bude jmenovat i nově vzniající stát, toto jsou prblémy

2/ Textová data je potřeba rozlišovat C jako char a V jako varchar (nikde není), zatím co char má pevnou délku, varchar má variabilní a tím se šetří místo v db. takže např pro ty státy je mnohem lepší místo C30 dát V255 a je klid... to platí všobecně všude - těch bych je tam více např. pojištovna C15 je fakt málo ... Je potřeba myslet velkoryse .. kolik hodin jsem propálil jako DBA prodlužováním položek - nepočítataně ... v reálu máte vývojovou, testavací a produkční databázi (i v jiných lokalitách) s aktualizací dokumentace, takže se pracnost velmi zvyšuje ...

3/ Za ten termín v samostané tabulece bych vás jako DBA fakt nepochválil, normalizace databáze jsou hezdké akademické poučky, ale dokážete si přidstavit, že jako DBA budete neustále muset joinovat další tabulku (při výpisu a při ručních hromadných updatech apod ... U nás v práci jsou taktové prkotiny běžené, ale je to k ničmu, akademicky možná v pořádku, ale v praxi akorát přidělává práci ... normálně bych dal Termín od - do jako položku objednávky termin_od D a termin_do D a hotovo ...

4/ Za ty PK klíče doprava a ubytování by bylo lepší místo N1 1,2,3,4,5 ... dát písmena např. C1 A-auto, B-bus, V-vlak, L-letadlo, pokud to bude používat nějaká aplikace tak je jí to jedno, ale pokud to občas potřebuje opravit DBA nebo programátor tak se v tom rychleji zorientuje a bude zde riziko menší chyby ... např. když zaměnujete A za B než 1 za 2. Čísla nič neříkají...

5/ Model nemá rozlišení co jsou povinné a nepovinné položky, doplnění podmínek NOT NULL by se hodilo ... všeobecně by blo dobré vědět něco integritě databáze (integritních omezení) a doplnit to ...