Tvorba návrhu relačnej databázy
Tvorba návrhu relačnej databázy
Súčasti konceptuálneho návrhu databázy
Relácie typu jedna k viacerým (1:N)
Relácia typu jedna k viacerým je vzťah medzi entinami, kde ľubovoľná inštancia prvej entiny môže byť priradená k jednej alebo k viacerým inštanciám druhej entiny, alebo naopak, každá inštancia druhej entiny môže byť priradená najviac k jednej inštancii prvej entiny. Na obrázku 2.1 vidíme 2 takéto relácie. Prvá je definovaná medzi entinami Zákazníci a Objednávky a druhá medzi entinami Zamestnanci a Objednávky. Relácia medzi Zákazníkmi a Objednávkami je povinná len v jednom smere a môžeme ju prečítať takto: „V ľubovoľnom okamžiku môže mať každý jeden zákazník podaných nula až mnoho (viac) objednávok a ku každej objednávke musí byť definovaný jeden a práve jeden zákazník, ku ktorému táto objednávka patrí “.
Obrázok: Relácia typu 1:N
Relácie 1:N sú v databázach dosť bežné. Fakticky sa dá povedať, že sú základným stavebným kameňom relačného modelu databáz, preto že v relačnej databáze sú nakoniec všetky relácie implementované ako relácie 1:N. Na strane „1“ bývajú tieto relácie len málokedy voliteľné, a prípady, kedy je naopak povinná strana „N“, sú ešte vzácnejšie, ale samozrejme i to sa môže stať. Pozrime sa na príklad z nasledujúceho obrázku.
Obrázok: Relácia typu 1:N
Po uzavretí účtu zákazníka zaznamenáme dôvod jeho uzavretia a to pomocou kódu uzavretia (Kód dôvodu uzavretia účtu). Preto že niektoré účty sú stále otvorené, je tento kód nepovinný (voliteľný). Reláciu môžeme preto prečítať takto: “V ľubovoľnom okamžiku môže mať dôvod uzavretia účtu priradené nula, jeden alebo viacej zákazníkov a súčasne každý jeden zákazník môže mať priradené nula alebo jeden dôvod uzavretia účtu”. Ďalej predpokladajme, že v rámci firemnej politiky nebude zákazníkovi povolené otvoriť si účet bez získania prvotného úverového hodnotenia a že všetky tieto úverové hodnotenia budeme zaznamenávať do databázy, tak že každý jeden zákazník môže mať viac ako len jedno úverové hodnotenie. Takto bude relácia medzi entinami Zákazník a Úverové hodnotenia typu 1:N a bude povinná v obidvoch smeroch. Prečítame ju nasledovne: “V ľubovoľnom okamžiku môže mať každý jeden zákazník jedno alebo viacej úverových hodnotení, ale každé úverové hodnotenie prislúcha práve len jednému zákazníkovi”
Po uzavretíúčtu zákazníka zaznamenáme dôvod jeho uzavretia a to pomocou kóduuzavretia (Kód dôvodu uzavretia účtu). Preto že niektoré účty sú stáleotvorené, je tento kód nepovinný (voliteľný). Reláciu môžeme preto prečítaťtakto: “V ľubovoľnom okamžiku môže mať dôvod uzavretia účtu priradené nula,jeden alebo viacej zákazníkov a súčasne každý jeden zákazník môže mať priradenénula alebo jeden dôvod uzavretia účtu”. Ďalej predpokladajme, že v rámcifiremnej politiky nebude zákazníkovi povolené otvoriť si účet bez získaniaprvotného úverového hodnotenia a že všetky tieto úverové hodnotenia budemezaznamenávať do databázy, tak že každý jeden zákazník môže mať viac ako lenjedno úverové hodnotenie. Takto bude relácia medzi entinami Zákazník a Úverovéhodnotenia typu 1:N a bude povinná v obidvoch smeroch. Prečítame junasledovne: “V ľubovoľnom okamžiku môže mať každý jeden zákazník jedno aleboviacej úverových hodnotení, ale každé úverové hodnotenie prislúcha práve lenjednému zákazníkovi”