Konceptualne modelovanie DBS

answered 2014-10-15 06:53:19 +0100

Josef Kokeš
2956 ●20 ●35 ●73

updated 2014-10-15 12:35:33 +0100

Tím zakončením podrobněji určujete vztah mezi entitami. Teď se omlouvám, jestli to řeknu blbě, protože jsem zvyklý na jiné značení a transformuji to z https://edux.fit.cvut.cz/courses/BI-DBS/_media/lectures/b141-dbs_03_konceptualni_modelovani-tisk.pdf jen podle logiky obrázků, ale zhruba to bude odpovídat:

Úplné zakončení, tj. pokračování čáry vs. vidlička, určuje kardinalitu vztahu vzhledem k entitě, u které to zakončení je. Takže pokud na straně 23 je u pokoje vidlička a u bloku čárka, tak to říká, že ke každému bloku může být libovolně mnoho pokojů a že k jednomu pokoji je jenom jeden blok (že jeden pokoj nemůže současně ležet v několika blocích).

Případná kolmá čárka před zakončením určuje, že entita do svého identifikátoru přebírá identifikační údaje (primární klíč) z jiné tabulky a případně k nim doplňuje ještě nějaká svoje pole. Bez kolmé čárky má entita vlastní identifikátor.

• Převzatý identifikátor bez doplňujících údajů se typicky používá u vazeb 1:1, kde mám tabulku se základními údaji o nějakém objektu a k ní druhou tabulku, ve které jsou další údaje, které ale mají smysl jen u části objektů. Například ve školním systému by šlo představit si tabulku OSOBA, kde jsou všichni (studenti i vyučující) a k tomu tabulku VYUCUJICI, kde jsou údaje relevantní jen pro vyučující; šlo by je samozřejmě nacpat přímo do tabulky OSOBA, ale pak by se u každého studenta zbytečně objevovala spousta nerelevantních polí. Ještě hůř by to dopadlo, kdybychom měli deset kategorií osob a každá měla mít sto svých doplňujících polí (což u objektově-relační DB není až tak neobvyklé), tak je určitě lepší mít jednu hlavní tabulku a deset pomocných 1:1 než těch tisíc polí narvat do hlavní tabulky a u každého záznamu mít 900 polí NULL (navíc by se pěkně blbě řešila integrita).

• Převzatý identifikátor s doplňujícími údaji se typicky používá, pokud chci mít v tabulce přirozený identifikátor. Lze si představit třeba to, že budeme zachycovat místnosti na čvut, tak budeme mít tabulky BUDOVA (identifikátor bude obsahovat věci jako "T9" nebo "TH" nebo "NTK"), BLOK (identifikátor bude ("T9","") nebo ("TH","A")) a MISTNOST (identifikátor bude ("T9","","105") nebo ("TH","A","1442")). Každá detailnější tabulka rozšiřuje identifikátor méně detailní tabulky o další pole. Mohli bychom samozřejmě použít umělé identifikátory (nějaký autoincrement, třeba) a pak bychom nepotřebovali přebírat identifikátory, dokonce se to často dělá, protože to má své výhody*), ale pokud zrovna lze použít přirozený identifikátor, tak to některé věci dost zjednodušuje pro uživatele (např. v příkladu s místnostmi půjde velmi snadno dělat dotazy, "vypiš místnosti, které leží v budově T9" (s umělými klíči bychom museli dělat tento dotaz nad spojením několika entit).

*) Zákazník sice řekne, že "nikdy nemůže nastat, že by byli dva lidi se stejným rodným číslem", ale za pět let, když už váš systém běží, se najednou dozvíte, že "... až na pana Nováka z Horní Dolní, který má stejné RČ jako pan Černý z Dolní Horní").