Tvorba návrhu relačnej databázy

Tvorba návrhu relačnej databázy

V súčasnosti žijeme v dobe, keď sa samotný údaj stáva predmetom obchodu, preto spôsob ukladania, organizovania ako aj využívania údajov, ktoré vlastní každá organizácia je dôležitým prvkom v jej riadení. Práve preto pri voľbe informačného systému a tvorby návrhu databázy je venovaná veľká pozornosť zostrany managementu organizácie. V nasledujúcom texte si opíšeme základné kroky tvorby návrhu relačnej databázy, vysvetlíme si elementárne pojmy, s ktorými sa pri jej tvorbe stretávame.

Tvorba samotnej databázy prebieha troma základnými fázami:

• fáza tvorby informačných požiadaviek – tvorba konceptuálneho modelu databázy,
• tvorba logického modelu databázy,
• tvorba fyzického modelu databázy.

Konceptuálny návrh databázy

Myšlienkový alebo konceptuálny návrh databázy znamená štúdium a modelovanie dát technologicky nezávislým spôsobom. Výsledný konceptuálny návrh je preto teoreticky možné implementovať v ľubovoľnej databáze a dokonca i v systéme otvorených súborov. Človek, ktorý vytvára konceptuálny návrh databázy, sa často nazýva dátový modelár.

Základ konceptuálneho modelu databázy spočíva v dôslednom vyhodnotení informačného toku, ktorý prebieha v organizácii a vzniká na základe sledovania vzájomných súvislostí medzi jednotlivými oddeleniami, spôsobe využívania uložených údajov a vyhodnotenia požiadaviek na vstupné a výstupné údaje. Ak má analytik všetky informácie, vyhotoví prvý (konceptuálny) model databázy a postupne ho konzultuje so všetkými pracovníkmi v organizácii, ktorí budú pracovať s jej údajmi.

Pretože užívatelia databázy nemusia byť odborníci v oblasti tvorby databáz,konceptuálny model nepoužíva odborné výrazy. Jeho význam spočíva v tom, že jednoduchým spôsobom mapuje tok informácií v organizácii a znázorňuje ho spôsobom, ktorý je pochopiteľný pre všetkých užívateľov vytváranej databázy s cieľom, čo najviac prispôsobiť databázu jej reálnemu využitiu.

Konečným krokom pri tvorbe konceptuálneho modelu databázy je dôsledný návrh skupín navzájom súvisiacich údajov (napr. údaje o pracovníkovi, údaje o oddelení a pod.) a náčrt vzájomných prepojení medzi týmito skupinami. Konceptuálny model obsahuje aj návrh východzích údajov, ktoré má organizácia k dispozícii a ktoré sú nevyhnutné pre tvorbu výstupných zostáv v jednotlivých oddeleniach.

Logický návrh databázy

Logický návrh databázy potom znamená proces prevodu (mapovanie) konceptuálneho návrhu do podoby logického návrhu, ktorý už zapadá do zvoleného databázového modelu (relačného, objektovo orientovaného,objektovo-relačného atď.). Špecialista, ktorý realizuje logický návrh databázy sa nazýva databázový návrhár, ale častoho zostavuje už samotný databázový administrátor .

Tvorbu logického modelu databázy môžemecharakterizovať pomocou týchto piatich základných krokov:

1. špecifikácia potrebných údajových položiek, ktoré budúvčlenené do databázy,
2. špecifikácia úrovne detailov jednotlivých údajovýchpoložiek, v závislosti na manipulácii s nimi v rámci databázy,
3. určenie logických celkov údajových položiek,
4. určenie vzájomných prepojení týchto celkov,
5. normalizáciou navrhovaných relačných vzťahov medzi logickýmiskupinami údajov.

Logický model databázy už obsahuje:

• návrh tabuliek , v ktorých budú údaje usporiadané,
• určenie typovúdajov ukladaných v databáze a
• grafické znázornenie ich relačných prepojení .

Fyzický návrh databázy

Posledným krokom (fázou) je fyzický návrh databázy, pri ktorom premietame (mapujeme) logický návrh databázy do jedného alebo viacerých fyzických návrhov, z ktorých každý je šitý na mieru konkrétnemu databázovému systému, ktorý bude zaisťovať správu databázy a konkrétnemu počítačovému systému, na ktorom databáza pobeží. Za fyzickýnávrh databázy je už takmer vždy zodpovedný databázovýadministrátor .

Fyzický model databázy tvorí návrh programu, vytvorený na základe predchádzajúcich dvoch návrhov. Tento model databázy tvoria odborníci z oblasti programovania databázových systémov a je priamo závislý na programovom jazyku, v ktorom sa databázový systém vytvára.

Pri tvorbe návrhu databázy sa snažíme vytvoriť obraz skutočnej reality v zjednodušenom tvare tak, aby sme čo najpresnejšie kopírovali vzájomné vzťahy medzi jednotlivými objektmi. Takýto opis reality vytvárame zo základných stavebnýchprvkov. V nasledujúcej časti textu budeme rozoberať jednotlivé komponenty konceptuálnej, logickej a fyzickej fázy návrhu relačného databázového modelu.

Súčasti konceptuálneho návrhu databázy

Nasledujúci obrázok (Obrázok 2.1) zachytáva konceptuálny návrh databázy, pričom sa čiastočne podobá obrázku 2.0, ale pre ilustráciu najdôležitejších princípov jev ňom na viac niekoľko drobností. Označené položky:

• Entina,
• Atribút,
• Relácia,
• Aplikačné pravidlo,
• Prienikové dáta,

predstavujú základné komponenty konceptuálneho návrhu databázy.

Obrázok 2.0: Ukážka štruktúry relačného modelu databázy

Obrázok 2.1: Konceptuálny návrh databázy

Entiny

Entina je osoba, miesto, vec alebo myšlienka, o ktorej zhromažďujeme určité dáta. Inými slovami, entiny sú „predmety“ z reálneho sveta, ktoré sú pre nás dostatočne zaujímavé, tak že o nich sledujeme určite údaje a zaznamenávame ich do databázy. Entinu reprezentuje v predchádzajúcej schéme obdĺžnik. Za entinu je možné považovať prakticky čokoľvek, čo môžeme pomenovať podstatným menom. Pretože, ale samozrejme, nemá zmysel modelovať v databáze celú planétu entín, obmedzíme množinu entín na také entiny, s ktorými bude pracovať užívateľ databázy. Každá entina znázornená v konceptuálnom návrhu (resp. v konceptuálnom modely) reprezentuje celú triedu entiny. Takto napríklad entina Zákazník vyjadruje celú kolekciu všetkých zákazníkov určitej spoločnosti, firmy, atď. Jednotlivých zákazníkov označujeme ako inštancie tejto entiny .

Externá entina je taká entina, s ktorou si naša databáza vymieňa určité údaje – teda, z ktorej do databázy zapisujeme údaje,do ktorej údaje z databázy zasielame alebo oboje, ale pritom priamo tieto údaje nezhromažďujeme.

Napríklad: Väčšina firiem, ktoré svojim zákazníkom poskytuje nejaký úverový limit, potrebuje napríklad vymieňať informácie o zákazníkoch s rôznymi úverovými spoločnosťami. Taktiež v našom príklade (Obrázok 2.1) budeme odosielať do úverovej spoločnosti informácie s identifikáciou zákazníkaa prijímať správu o jeho úverovom rámci – to sú všetko údaje o zákazníkovi a nie o úverovej spoločnosti. Táto úverová spoločnosť sa v konceptuálnom návrhu databázy ako entina neobjaví, samozrejme, pokiaľ nemáme nejaký dôležitý dôvod ukladať do nej údaje, napríklad jej poštovú adresu. Externé entiny sa v skutočnosti v návrhu databázy používajú len zriedka, napriek tomu sa s nimi často stretávame v diagramoch tokov dát, kde tvorí zdroj alebo cieľ dátových tokov.

Atribúty

Atribút je jednotka faktov o entine, ktorá entinu nejakým spôsobom charakterizuje alebo popisuje. Typickým príkladom je napríklad veľkosť, tvar, farba, množstvo, miesto.V diagrame s konceptuálnym návrhom podľa obrázku 2.1 znázorňujeme atribúty ako názvy vo vnútri obdĺžniku príslušnej entiny. Atribút alebo atribúty uvedené v obdĺžniku hore (nad vodorovnou čiarou), tvorí jednoznačný identifikátor entiny, ktorý pre každú inštanciu (výskyt) entiny obsahuje jedinečnú hodnotu. Atribút Kód zákazníka je napríklad jednoznačným identifikátorom entiny Zákazník a preto musí mať každý zákazník inú hodnotu tohto atribútu. Nezabudnime pri tom, že jedinečný identifikátor môže byť zložený aj z niekoľkých atribútov - v takom prípade sa ale považuje za jeden jedinečný identifikátor.

Povedali sme, že atribút je jednotka faktov o entine – každý atribút by mal byť atomický, teda taký, aby jeho hodnotu nebolo možné zmysluplne ďalej rozdeliť do niekoľkých menších jednotiek. Inými slovami, atribút je najmenšia pomenovaná jednotka dát definovaná v databázovom systéme .V tomto slova zmysle môžeme atribút Adresa považovať za„podozrivý“, pretože ho môžeme ľahko rozdeliť do dvoch adresných riadkov. Táto zmena je na viac zmysluplná, pretože nám uľahčí napríklad tlač adresných vizitiek. Atribút Kontaktná osoba s menom kontaktnej osoby by sme tak mohli rozdeliť na titul, meno, priezvisko, no musíme zvážiť, či nám takáto zmena niečo prinesie. Návrh databáz, ale na druhej strane nie je žiadnou exaktnou vedou a musíme sa pri ňom riadiť taktiež vlastným zdravým rozumom.

Údaje, ktoré zapisujeme ako atribúty majú zvyčajne presne stanovenú množinu, z ktorej ich vyberáme, napríklad meno Peter patrí do množiny krstných mien, dátum narodenia XX.YY.ZZZZ do množiny dátumov. Množinu, z ktorej vyberáme údaj určujúci atribút entity nazývame doménou atribútu. Napríklad domény atribútu stav je slobodný, ženatý, rozvedený, vdovec a pod.

Relácie

Vzťah chápeme ako vzájomnú súvislosť alebo zobrazenie medzi dvoma množinami. Pri zobrazovaní situácií z reálneho sveta môžeme rozlišovať množstvo vzájomných vzťahov, napríklad osoba A je manželom osoby B, osoba M je dieťaťom osoby A.

Relácie popisujú vzájomné vzťahy (asociácie) medzi entinami. Pretože do databázy ukladáme dáta, ktoré spolu nejakým spôsobom súvisia, či že sú “relačne zviazané”, potrebujeme v nej nejaké lepidlo, vďaka ktorému bude databáza držať pohromade a tím sú práve relácie. V diagrame konceptuálneho návrhu z obrázku 2.1 sú relácie naznačené ako čiary prepájajúce jednu alebo viacej entín.

Na každom konci relačnej čiary je ďalej znázornená maximálna kardinalita vzťahu, teda najväčší počet inštancií jednej entiny, ktoré môžu byť združené s inštanciou entiny na opačnom konci. Táto maximálna kardinalita môže byť rovná:

• jednej – v tomto prípade čiara nemá na konci žiadny zvláštny symbol,
• viacerým –v tomto prípade je na konci relačnej čiary rozvetvenie.

Tesne pred týmto symbolom je ešte ďalší symbol, ktorý naznačuje minimálnu kardinalitu vzťahu, teda najmenší počet inštancií jednej entiny, združených s entinou na opačnom konci. Minimálna kardinalita môže byť rovná:

• nule – v tomto prípade je na konci čiary zakreslený krúžok,
• jednej – v tomto prípade je čiara je pretnutá krátkou kolmou vedenou čiarou.

Pomocou dvoch kolmých čiarok naznačujú dátový modelári často reláciu s kardinalitou “jedna a práve jedna”.

Pri správnom definovaní a zakresľovaní relácie je podstatné premýšľať o vzťahu obidvoch entín v jednom smere a potom sa na reláciu pozrieť z druhej strany.

Uvažujme napríklad reláciu medzi entinami Zákazník a Objednávka. Tu si musíme položiť 2 otázky: Prvá otázka: ”koľko objednávok môže podať jeden zákazník?” a druhá otázka: “koľko zákazníkov je priradených k jednej objednávke?”

Relácie môžeme preto klasifikovať do troch základných typov , ktoré súcharakterizované podľa toho, koľko prvkov je týmto vzťahom navzájom zviazaných:

• Relácie typu jedna k jednej (1:1) - vzťah 1:1 charakterizuje napríklad manželstvo (ak samozrejme jeden z manželov nie je sobášny podvodník).
• Relácie typu jedna k viacerým (1:N) - vzťah 1:N je zas charakterizovaný napríklad vzťahom rodič – dieťa, jeden rodič môže mať viac detí.
• Relácie typu viaceré k viacerým (M:N) - príkladom vzťahu M:N môže byť vzťah autobusovej linky a autobusovej zastávky. Jedna autobusová linka má viacero zastávok a na jednej autobusovej zastávke zastavuje viacero autobusových liniek.

Obrázok: Schematickéznázornenie základnej klasifikácie relácií

Niektorý môžu namietať, že relácia môže byť taktiež typu viaceré k jednej, ale to je fakticky normálna relácia jednak viacerým, iba že v obrátenom pohľade.

Relácie typu jedna k jednej (1:1)

Relácia typu jedna k jednej je taký vzťah medzi dátami, kedy inštanciu jednej entiny môžeme priradiť k najviac jednej inštancii druhej entiny a naopak. Na obrázku 2.1 je príkladom takejto relácie vzťah medzi entinami Zákazník a Pohľadávky odberateľov. To znamená, že s každým zákazníkom môže byť spojený najviac jeden záznam pohľadávok a každý účet pohľadávky má priradeného najviac jedného zákazníka. Relácia je na viac v obidvoch smeroch povinná, tak že zákazník musí mať súčasne aspoň jeden záznam pohľadávky a naopak každý pohľadávkový účet musí mať aspoň jedného zákazníka. Dohromady potom túto reláciu medzi entinami Zákazník a Pohľadávky odberateľov môžeme čítať: „S každým zákazníkom je spojený jeden a práve jeden záznam pohľadávky a ku každému záznamu pohľadávky je priradený jeden a práve jeden zákazník“.

Obrázok: Relácia medzi Zákazníkmi a Pohľadávkami

Relácie typu jedna k jednej sú medzi entinami veľmi ojedinelé (a tým aj vzácne). V praxi totiž takáto relácia, ktorá je typu 1:1 a na viac je v obidvoch smeroch povinná znamená jasnú chybu – obidve entiny môžeme ľahko zlúčiť do jednej. Nakoniec predsa, nie je účet pohľadávky obyčajným špeciálnym prípadom informácie o zákazníkovi? My predsa nebudeme zhromažďovať dáta o všetkých možných pohľadávkach, ale v rámci informácií entiny Pohľadávky odberateľov zisťujeme iba dáta o zákazníkovi. Na druhej strane, pokiaľ by sme si zakúpili administratívny softvér od nejakého nezávislého výrobcu, bola by v ňom určite preddefinovaná nejaká podporovaná databáza, tak že by sme už nemali na výber a entinu Pohľadávok by sme museli nechať tak, ako je. Návrh databázy od výrobcu asi len tak ľahko nezmeníme a na druhej strane jeho softvér “neprinútime” k rozpoznaniu ďalších informácií uložených v našej vlastnej databáze.    

Na obrázku 2.2 vidíme inú verziu relácie typu 1:1 a síce takú reláciu, ktorá je v obidvoch smeroch voliteľná, čiže nepovinná (dá sa taktiež povedať aj podmienená).

Obrázok 2.2: Relácia medzi zamestnancami a automobilmi

Dajme tomu, že navrhujeme databázu pre spoločnosť zameranú na predaj automobilov. Táto obchodná firma dáva (niektorým) zamestnancom k dispozícii služobné auto, ale vždy na istú obmedzenú dobu. Je jasné, že takto nebudú zamestnancom rozdeľovať všetky autá (inak by im nezostalo žiadne v predajni na predaj). Reláciu medzi entinami Zamestnancov a Automobilov tak môžeme prečítať: “ V ľubovoľnom okamžiku môže mať každý jeden zamestnanec pridelené žiadne alebo jedno auto a každý jeden automobil môže byť pridelený žiadnemu alebo jednému zamestnancovi.” Všimnime si tu podmienku “v ľubovoľnom okamžiku”: aj keď automobil jednému zamestnancovi odoberieme a pridelíme ho inému, bude relácia 1:1 zachovaná. To preto, že pri analýze relácií berieme do úvahy vždy momentálny pohľad na dáta získaný v jednom konkrétnom okamžiku.

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”

Relácie typu viaceré k viacerým (M:N)

Relácia typu viaceré k viacerým je zvláštnym typom vzťahu medzi dvomi entinami, pri ktorom môže byť nie len ľubovoľná inštancia prvej entiny spojená s nula, jednou alebo viacerými inštanciami druhej entiny, ale aj opačne. Na obrázku 2.1 môže byť príkladom relácie medzi entinami Objednávok a Výrobkov. Túto reláciu môžeme prečítať: „V ľubovoľnom okamžiku môže každá jedna objednávka obsahovať nula alebo viacej výrobkov a súčasne každý jeden výrobok sa môže vyskytovať na nula až viacerých objednávkach.“

Dáta spojené s touto konkrétnou reláciou sú v diagrame zaznačené pomocou kosoštvorca. Tieto dáta nazývame prienikové dáta (označované tiež aj ako väzobná entina, alebo v konkrétnej databáze spojovacia tabuľka) a samé o sebe nemajú zmysel – musíme ich vždy združiť s obidvomi entinami súčasne. Atribút objednaného množstva nemá napríklad zmysel, pokiaľ nevieme kto (teda ktorý zákazník) si objednal čo (teda aký výrobok). Ak sa opäť pozrieme na obrázok 1.7, poznáme tieto dáta v relačnom modeli uvedenej databázy ako tabuľku Rozpis objednávok. Prečo teda tento rozpis objednávok nepovažujeme za entinu? Odpoveď je jednoduchá: neodpovedá definícii entiny. V systéme totiž nezhromažďujeme dáta o jednotlivých riadkoch objednávky, pretože tieto riadky sú obyčajnými dátami o objednávke. 

Obrázok: Relácia typu M:N

V praxi sú ale relácie M:N veľmi bežné a s väčšinou z nich sú spojené nejaké prienikové dáta. Je trochu smola, že relačný model tieto relácie priamo nepodporuje. V konceptuálnom návrhu nie je s reláciou M:N žiadny problém, preto že tento typ návrhu je ešte nezávislý na konkrétnej technológii. Ako náhle chceme databázu postaviť ako relačnú, musíme v nej zrealizovať určité úpravy a konceptuálny model musíme premietnuť do zodpovedajúceho logického modelu. Riešením sú prienikové dáta v zvláštnej tabuľke (spojovacia, alebo prieniková tabuľka) a reláciu typu M:N definovať ako dve relácie typu 1:N, pričom prienikové tabuľka leží v obidvoch týchto reláciách na strane N. Popísaná úprava bola zachytená už na spomínanom obrázku 1.7

Rekurzívne relácie

Zatiaľ sme sa zaoberali reláciami medzi entinami dvoch rôznych typov. Relácie (vzťahy) môžu ale existovať i medzi dvomi inštanciami rovnakého typu – t.j. tej istej entiny. Hovoríme o tzv. rekurzívnych reláciách. Ako rekurzívna môže byť definovaná relácia ľubovoľného z 3 základných typov popísaných v predchádzajúcej časti (teda relácia typu 1:1, 1:N alebo M:N). Príklady všetkých týchto rekurzívnych relácií sú znázornené na nasledujúcich obrázkoch a podrobne ich môžeme charakterizovať takto:

• Jedna k jednej: Každý zamestnanec môže, ale nemusí byť manželom (manželkou) jedného iného zamestnanca.

Obrázok

Pokiaľ budeme v databáze sledovať, ktorý zamestnanec je manželom alebo manželkou iného zamestnanca, bude naisto spojený s nula alebo s jedným iným zamestnancom.

• Jedna k viacerým: Každý zamestnanec môže byť nadriadený jednému alebo viacerým iným zamestnancom.

Obrázok 

V databázach sa veľmi často sleduje „organizačný pavúk“ so vzťahmi, kto je komu vo firme podriadený. Vo väčšine organizácií máva každý zamestnanec len jedného priameho nadriadeného. To znamená, že za normálnych okolností bude zamestnanec podriadený nula alebo jednému zamestnancovi  (svojmu “šéfovi”) a naopak, zamestnanec vo vedúcej funkcii bude priamo nadriadený jednému alebo viacerým iným, podriadeným zamestnancom.

• Viaceré k viacerým: Každá súčiastka môže obsahovať viac iných súčiastok a naopak, každá súčiastka môže byť zapojená do viacerých iných súčiastok.

Obrázok

Pri sledovaní výroby určitého tovaru nás často bude zaujímať, z akých súčiastok sa skladá finálny výrobok. Napríklad mechanika DV v osobnom počítači: táto jednotka – DVD prehrávač sa skladá z viacerých jednotlivých súčiastok, ale na druhej strane je i táto DVD mechanika jednou z mnohých súčiastok či komponentov celého počítača. To znamená, že jedná súčiastka môže byť zhotovená z mnohých iných súčiastok a zároveň každá súčiastka môže byť zapojená do viacerých rôznych „väčších“ súčiastok.

Aplikačné pravidlá

Aplikačné pravidlo je politika, postup, procedúra alebo štandard, ktorý daná organizácia prijala za svoj. Aplikačné pravidlá sú v návrhu databázy veľmi dôležité, pretože predpisujú isté pravidlá pre kontrolu dát. Na obrázku 2 je uvedené jedno také aplikačné pravidlo – podľa neho sme mohli prijať objednávky len od zákazníkov, ktorí nemajú žiadne nezaplatené pohľadávky.

Obrázok 2.4

Väčšinu aplikačných pravidiel je možné zaistiť pomocou manuálnych postupov, ktorých dodržiavanie majú zamestnanci administratívne nariadené, alebo pomocou logiky začlenenej do aplikačného programu. Obidva typy pravidiel sa ale dajú obísť – zamestnanci môžu na dodržiavanie predpísaného postupu (pravidla) zabudnúť, alebo sú k nemu skrátka ľahostajný a oprávnený užívatelia môžu v databáze realizovať i priame aktualizácie, pri ktorých sa kontroly aplikačného programu vynechávajú. Databáza tak môže slúžiť ako tzv. „posledná obranné línia“. Do databázy implementujeme aplikačné pravidlá vo forme tzv. obmedzení, čo sú formálne definované pravidlá, ktoré nejakým spôsobom obmedzujú podobu dát v databáze.

Aplikačné pravidlá do diagramu s konceptuálnym modelom databázy normálne nezapisujeme – na obrázku 2 sú uvedené len pre ilustráciu, zatiaľ čo v praxi ich o mnoho častejšie zapisujeme do samostatného dokumentu, ktorý je doplnkom uvedeného diagramu.     

Súčasti logického a fyzického návrhu databázy

V Modeli ANSI/SPARC, ktorý sme preberali v predchádzajúcej kapitole a bol zakreslený na obrázku 1.1, implementujeme logický návrh databázy v rámci logickej vrstvy. Fyzický návrh databázy potom v tomto modely spadá do fyzickej vrstvy. Fyzickú vrstvu ale nakoniec implementujeme vo vybranom databázovom systéme, tak že sa obidve vrstvy oddeľujú pomerne obtiažne.

Ak napríklad v databáze vytvoríme novú tabuľku, zapíšeme do príslušného príkazu CREATE TABLE klauzulu, ktorá databázovému systému nariadi jej umiestenie. Databázový systém potom automaticky alokuje, inak povedané vyhradí potrebný priestor pre tabuľku v požadovanom súbore (resp. súboroch) operačného systému. Súčasťou definície logických štruktúr v databázovom systéme je teda veľká časť vlastnej fyzickej implementácie. V priebehu fázy logického návrhu databázy môžeme jednotlivým dátovým objektom prevádzaných z konceptuálneho návrhu databázy, ihneď priradiť isté vlastnosti fyzického uloženia (ako napríklad názov súboru, jeho umiestenie a informácie o veľkosti), alebo ich môžeme najprv vynechať a doplniť ich až neskôr, v kroku fyzického návrhu, ktorý nasleduje po logickom návrhu.

Pre úsporu času realizuje väčšina databázových administrátorov obidva kroky (teda logický aj fyzický návrh) súbežne. 

Tabuľky

Primárnou jednotkou ukladania dát v relačnom modeli je tabuľka, čo je dvojrozmerná štruktúra zložená s riadkov a stĺpcov. Každý riadok reprezentuje jeden výskyt entiny, ktorú tabuľka modeluje a každý stĺpec reprezentuje jeden atribút tejto entiny.

Proces prevodu entín z konceptuálneho návrhu do tabuliek v logickom návrhu sa nazýva normalizácia. Entina v konceptuálnom návrhu sa často premieta do práve jednej tabuľky v logickom návrhu, ale vždy tomu tak byť nemusí. Z dôvodu, ktorý poznáme práve z výkladu normalizácie, sa entiny často rozdeľujú do niekoľkých tabuliek a výnimočne sa taktiež niekoľko entín môže spojiť do jednej tabuľky. Na obrázku 2.5 je znázornený výpis tabuľky Objednávky.

Obrázok 2.5: Čiastočný výpis tabuľky Objednávky

Na tomto mieste je dôležité si zapamätať, že relačná tabuľka je len logickou záznamovou štruktúrou a že obvykle vo fyzickej vrstve neexistuje v skutočnej tabuľkovej forme. Databázový administrátor priraďuje jednotlivé tabuľky do súborov operačného systému z fyzickej vrstvy - tým sa vo väčšine relačných databázových systémoch hovorí tabuľkový priestor, a je celkom bežné, že do jedného tabuľkového priestoru umiestnime niekoľko tabuliek. Rozsiahle tabuľky môžu byť ale umiestnené do samostatného tabuľkového priestoru, alebo môžu byť dokonca rozdelené medzi niekoľko takých priestorov – hovoríme tu potom o delení. Databázový administrátor musí každej tabuľke v okamžiku jej vytvorenia priradiť jednoznačný (jedinečný) názov. Maximálna dĺžka názvu medzi rôznymi relačnými databázami sa líši a pohybuje sa od 18 znakov až po 255 znakov. Názov tabuľky by mal byť výstižný a mal by označovať entinu reálneho sveta, ktorú tabuľka reprezentuje.

Microsoft Access povoľuje v názvoch tabuliek a stĺpcov aj medzery, čo je však v rozpore so štandardami. Na viac, Microsoft Access, Sybase, Microsoft SQL Server povoľujú názvy zložené z malých a veľkých písmen, napríklad Rozpis Objednávok, zatiaľ čo Oracle, DB2 a iné databázové systémy vyžadujú zápis názvov len veľkými písmenami.  

Obmedzenia

Obmedzenie je pravidlo, ktoré definujeme nad určitým databázovým objektom (najčastejšie tabuľkou alebo stĺpcom) a ktoré určitým spôsobom obmedzuje prípustné dátové hodnoty tohto databázového objektu. Tieto obmedzenia patria v relačných databázach k najdôležitejším prvkom, pretože pomocou nich v logickom návrhu implementujeme relácie aj aplikačné pravidlá. Každé obmedzenie má priradený jedinečný názov, pod ktorým sa na obmedzenie môžeme odvolávať v chybových správach a ďalších databázových príkazoch. Je dobrým zvykom, že názvy obmedzení definuje sám databázový administrátor, preto že v opačnom prípade relačný databázový systém priradí východzí, automaticky vygenerovaný názov, ktorý nie je príliš výstižný.

Stĺpce a dátové typy

Každý stĺpec v relačnej tabuľke reprezentuje určitý atribút z konceptuálneho návrhu (modelu). Stĺpec je v relačnej databáze najmenšou pomenovanou jednotkou dát, na ktorú sa môžeme odkazovať. Každému stĺpcu musíme priradiť jedinečný názov v rámci tabuľky a dátový typ. Dátový typ je pri tom určitá kategória konkrétneho stĺpca. Definícia dátového typu má niekoľko zaujímavých výhod:

• Obmedzuje množinu povolených dát v stĺpci len na také znaky, ktoré majú pre dátový typ zmysel (napríklad len číslo alebo platný dátum)
• Cieľovému užívateľovi databázy predkladá určitú množinu správania: pokiaľ napríklad odčítame číslo od iného čísla, dostaneme vo výsledku opäť číslo, no ale ak odčítame dátum od iného dátumu, dostaneme taktiež číslo, ktoré ale tento krát vyjadruje počet dní uplynutých medzi obidvomi dňami.
• Pomáha relačnému databázovému systém k efektívnemu ukladaniu dát stĺpca. Čísla sa napríklad často dajú ukladať v internom, kapacitne úspornom číselnom formáte a nie len v neefektívnom formáte reťazcov znakov

 Na nasledujúcom obrázku 2.6 je ukážka definície tabuľky Objednávky v MS Access. Dátový typ každého zo stĺpcov je uvedený v druhom stĺpci zľava. Dátové typy vo väčšine prípadov hovoria sami o sebe, ale pokiaľ i napriek tomu nebude jasné čo-to o príslušnom dátovom type, bližšie informácie poskytuje Pomocník v MS Access.

Obrázok 2.6: Definícia tabuľky Objednávky v MS Access

Je opäť veľkým nešťastím, že vývoj štandardných dátových typov za rozvojom relačných databázových systémov značne zaostáva. Väčšina výrobcov si teda všetko dlhé roky robila “po svojom”, kým sa dokázala dohovoriť s ostatnými výrobcami na vytvorení štandardov. Dnes sú už relačné dátové typy definované v príslušných normách ANSI a väčšinou zo štandardných typov (ale nie všetky) pričom ich podporuje každý z významných výrobcov. Na druhej strane má ale každý z výrobcov taktiež určité neštandardné rozšírenie, ktoré sa z veľkej časti týkajú dátových typov vzniknutých ešte pred ustanovením štandardov. Dalo by sa žartom povedať, že na databázových štandardoch je najlepšie to, že každý výrobca má svoj vlastný. Ak hovoríme o štandardoch pre relačné databázy, potom medzi najrozšírenejšími produktmi najmenej zodpovedá štandardom asi Microsoft Access.

Vzhľadom k mnohým rôznym úrovniam súladu so štandardmi a vzhľadom k spomínaným „rozšíreniam“ u jednotlivých výrobcov musí taktiež každý databázový administrátor veľmi podrobne poznať, aké dátové typy sú v konkrétnom databázovom systéme k dispozícii a aké môže tým pádom pri návrhu databázy používať. Veľký pozor si samozrejme musí dávať pri akomkoľvek prevode logického návrhu z databázového prostredia jedného výrobcu k inému.

V tabuľke 2.1 je ukážka niektorých takmer ekvivalentných (no nie však presne identických) dátových typov ako sú definované v relačných databázových systémoch od rôznych výrobcov. Dátový typ VARCHAR v databáze Oracle môže mať napríklad dĺžku až 4000 znakov, zatiaľ čo ekvivalentný typ MEMO v MS Accesse môže obsahovať až 64000 znakov dát.

 Poznámka: V Microsoft Access sú názvy dátových typov “počeštené” - zobrazujú sa ale len do príslušných dialógov, a nie do príkazov jazyka SQL.

Tabuľka 2.1: Ekvivalentné dátové typy v najvýznamnejších relačných databázach

Obmedzenie primárneho kľúča

Primárny kľúč je stĺpec lebo množina stĺpcov, ktoré dohromady jednoznačne identifikujú každý riadok tabuľky. Jedinečný identifikátor z konceptuálneho návrhu implementujeme do logického návrhu práve ako primárny kľúč tabuľky. Vizuálna informácia, ktorá oznamuje, že príslušné pole je definované ako primárny kľúč tabuľky je znázornená v podobe malej ikony kľúča pri názvu tohto pola v návrhovom zobrazení tabuľky.

Ak v tabuľke definujeme primárny kľúč, implementuje ho relačný databázový systém ako obmedzenie primárneho kľúča a tým potom zaručí, že žiadne 2 riadky v tabuľke nebudú mať v stĺpci (stĺpcoch) primárneho kľúča rovnaké (duplicitné) hodnoty. Pokiaľ sa primárny kľúč skladá z hodnôt niekoľkých stĺpcov, môže jednotlivý stĺpec primárneho kľúča sám v sebe obsahovať duplicitné hodnoty, ale kombinácie všetkých stĺpcov primárneho kľúča už ale musia byť medzi všetkými riadkami tabuľky jedinečné. 

Obmedzenie primárneho kľúča sa v relačných databázových systémoch implementuje takmer vždy pomocou indexu, čo je špeciálny typ databázového objektu, ktorý slúži na rýchle prehľadávanie hodnôt v stĺpci. Pri vložení nového riadku do tabuľky tak relačný databázový systém automaticky prehľadá index (indexový súbor) a skontroluje, či sa hodnota primárneho kľúča nového riadku už v tabuľke nachádza a pokiaľ ju tu nájde, operáciu vloženia odmietne.

Indexy (indexové súbory) sa dajú prehľadávať podstatne rýchlejšie ako tabuľky, a preto je vytvorenie indexu nad primárnym kľúčom veľmi dôležité, bez ohľadu na veľkosť tabuľky. Len vďaka indexu neznamená hľadanie duplicitných kľúčov žiadne významné spomaľovanie operácií vkladania dát.

Referenčné obmedzenie

Aby sme pochopili, ako relačný databázový systém zaisťuje platnosť relácií pomocou referenčných obmedzení, musíme si najprv vysvetliť, čo sú to tzv. cudzie kľúče.

V prípade, že pomocou tabuliek v relačnej databáze implementujeme reláciu typu jedna ak viacerým, potom do tabuľky na strane „viacerým“ musíme zapísať stĺpec alebo množinu stĺpcov, ktorý asociuje (priraďuje) príslušný riadok s riadkom rodičovskej tabuľky, teda tabuľky na strane jedna a ten práve nazývame cudzí kľúč. (foreign key, FK). Názov stĺpcov cudzieho kľúča sa preberajú z názvov stĺpcov v príslušnej “cudzej” tabuľky. V tabuľke Objednávky z obrázku 2.6 je tak napríklad stĺpec Číslo zamestnanca cudzím kľúčom z tabuľky Zamestnanci a stĺpec Kód zákazníka je cudzím kľúčom z tabuľky Zákazníci.

Vo väčšine relačných databáz musí byť cudzím kľúčom buď primárny kľúč rodičovskej tabuľky, alebo množina stĺpcov, pre ktoré je definovaný jedinečný index. Dôvodom je opäť efektivita činnosti databázy. Väčšina ľudí má najradšej, keď sa názov stĺpca cudzieho kľúča zhoduje s názvom zodpovedajúceho stĺpca primárneho kľúča rodičovskej tabuľky, ale opäť existujú aj opačné názory a to najmä preto, že so stĺpcami rovnakého názvu (podobného) sa v dotazovacom jazyku ťažšie pracuje.

Každá relácia medzi entinami z konceptuálneho návrhu sa v logickom návrhu premieta do referenčného obmedzenia. Pod pojmom referenčné obmedzenie alebo obmedzenie referenčnej integrity rozumieme také obmedzenie, ktoré zaisťuje reláciu medzi tabuľkami v relačnej databáze. Zaisťovať v tomto prípade znamená, že relačný databázový systém automaticky kontroluje, či ku každej hodnote cudzieho kľúča v závislej tabuľke existuje zodpovedajúca hodnota primárneho kľúča v rodičovskej (riadiacej) tabuľke.

Microsoft Access ponúka pre stĺpec s cudzím kľúčom jednu veľmi príjemnú funkciu, na ktorú je ale nutné si najprv zvyknúť. Pri definícii referenčného obmedzenia môžeme vyžiadať automatické prehľadávanie riadkov rodičovskej tabuľky. Na obrázku 2.6 má druhý stĺpec tabuľky označenie Kód zákazníka. Na obrázku 2.5 vidíme ale, že na pozícii druhého stĺpca je miesto kódu zákazníka jeho meno a názov stĺpca Zákazník. V prípade, že do stĺpca Zákazník v niektorom z riadkov klikneme myšou, objaví sa šípka rozbaľovacieho zoznamu, ktorý ponúka na výber rodiča vybraného riadku objednávok z platných zákazníkov (teda z tabuľky Zákazníci). Podobne i v stĺpci Číslo zamestnanca je v skutočnosti zobrazené meno zákazníka. Pre databázového užívateľa je táto funkcia veľmi príjemná a pohodlná a popri tom nedovoľuje priradiť k objednávke neexistujúceho (neplatného) zákazníka alebo zamestnanca. Súčasne sa s tým v tabuľke skrývajú skutočné hodnoty cudzieho kľúča.

Na nasledujúcom obrázku 2.7 je vyhľadávanie hodnôt stĺpcov v tabuľke Objednávky vypustené, tak že v stĺpcoch Číslo zamestnanca a Kód zákazníka vidíme skutočné kódové hodnoty cudzieho kľúča.

Obrázok 2.7: Tabuľka Objednávky so zobrazením cudzích kľúčov

Pri aktualizácii tabuľky Objednávky z obrázku 2.7 musí relačný databázový systém zaistiť platnosť referenčných obmedzení, ktoré sú nad touto tabuľkou definované. Pôvab databázových obmedzení spočíva v tom, že sú automatické a nedajú sa teda obísť – pokiaľ ich databázový administrátor nezablokuje alebo nevymaže. V rámci zaistenia referenčných obmedzení musí relačný databázový systém obsluhovať tieto konkrétne udalosti:

• V prípade, že sa pokúsime do závislej tabuľky (t.j. tabuľky cudzieho kľúča) vložiť záznam, ku ktorému neexistuje zodpovedajúci riadok rodičovskej tabuľky, musí v tomto prípade systém túto požiadavku na vloženie dát odmietnuť. Pokiaľ sa napríklad do tabuľky Objednávky pokúsime vložiť riadok s hodnotou Číslo zamestnanca 12345, pozrie sa databázový systém do tabuľky Zamestnanci a zistí, či je v nej definovaný zamestnanec s číslom 12345. Ak nie je, požiadavku na vloženie dát odmietne.
• Podobne sa správa databázový systém pri aktualizácii dát: ak sa pokúsime uskutočniť v závislej tabuľke aktualizáciu hodnoty cudzieho kľúča, pričom nová hodnota kľúča nie je v rodičovskej tabuľke doposiaľ definovaná, bude požiadavka na aktualizáciu odmietnutá. Ak sa napríklad pokúsime zmeniť Číslo zamestnanca v objednávke 10248 z 5 na 12345, pozrie sa databázový systém opäť do tabuľky Zamestnanci a zistí, či je v nej definovaný zamestnanec s číslom 12345, pokiaľ v nej nie je definovaný, požiadavka na zápis bude odmietnutá.
• Ak chceme odstrániť riadok rodičovskej tabuľky, ku ktorému existujú zviazané (závislé) riadky v jednej alebo vo viacerých závislých tabuľkách, musíme buď spolu s rodičovským riadkom odstrániť taktiež príslušné riadky v závislej tabuľke, alebo databázový systém musí zamietnuť celú požiadavku na odstránenie. Väčšina relačných databázových systémov ponúka aj prvú popísanú možnosť, teda automatické odstránenie závislých záznamov, ktoré sa nazýva kaskádové odstránenie.

Pozrime sa na tabuľky Objednávky a Rozpis objednávok: pokiaľ odstraňujeme z databázovej tabuľky Obednávka nejakú objednávku, má zmysel odstrániť s objednávkou v tom istom kroku i všetky ostatné (jednotlivé) riadky tejto objednávky (tabuľka Rozpis objednávok). V prípade tabuľky Zamestnanci toto správanie požadovať nebudeme: naopak, ak zadáme napríklad odstránenie zamestnanca číslo 5 z tabuľky Zamestnanci (napríklad preto, že už v spoločnosti nepracuje), musí relačný databázový systém skontrolovať, či sa v tabuľke Objednávky nenachádzajú nejaké riadky zadané týmto zamestnancom, a pokiaľ tu tieto riadky sú, odstránenie zamestnanca odmietne. Zo všeobecného hľadiska by automatické odstránenie všetkých objednávok vybavených bývalým zamestnancom rozhodne nemalo zmysel.       

Obrázok 2.8: Vzťah medzi tabuľkami Objednávky a Rozpis objednávok

Vo väčšine relačných databázových systémoch definujeme referenčné obmedzenie pomocou zvláštneho príkazu jazyka SQL (je to jazyk, pomocou ktorého komunikujeme s relačnou databázou). Viacerý z výrobcov databázových systémov ponúkajú pre definíciu databázových objektov, napr. referenčných obmedzení, vhodné ovládacie prvky grafického užívateľského rozhrania (GUI). V Oracle a v SQL Server sa tieto ovládacie prvky či panely nachádzajú v nástroji Enterprise Manager (resp. Management Studio v SQL Serveri 2005), zatiaľ čo v Microsoft Access sú priam súčasťou aplikácie. Na nasledujúcom obrázku 2.8 vidíme okno Relácie v ktorom definujeme práve referenčné obmedzenie

Obrázok 2.8 Panel Relácie v Microsoft Access

Pre zjednodušenie je pritom na obrázku 2.8 znázornená len tabuľka Objednávky a k nej dve rodičovské tabuľky, Zamestnanci a Zákazníci. Referenčné obmedzenia sú v tomto prípade vyjadrené čiarami, zakončenými silnejšou líniou a číslicou jedna pri rodičovskej tabuľke, respektíve symbolom nekonečna pri závislej tabuľke. Definovať tieto obmedzenia je veľmi jednoduché: stačí potiahnuť myšou za názov primárneho kľúča z rodičovskej tabuľky na názov cudzieho kľúča v závislej tabuľke. Potom sa následne zobrazí dialóg Upraviť relácie, v ktorom môžeme zmeniť možnosti definovaného referenčného obmedzenia (Obrázok 2.9).

Obrázok 2.9 Dialóg Upraviť relácie v MS Access

Pri hornom okraji dialógu Upraviť relácie sú uvedené názvy obidvoch tabuliek – na ľavej strane je rodičovská tabuľka a na pravej strane “súvisiaca”, teda závislá tabuľka (toto vám napovie aj popis v spodnej časti dialógového okna). Pod názvom každej z tabuliek môžete vybrať názvy stĺpcov, z ktorých sa skladá primárny a cudzí kľúč – na obrázku 2.9 je to stĺpec Kód Zákazníka, ktorý je primárnym kľúčom v tabuľke Zákazníci a cudzím kľúčom v tabuľke Objednávky. Zaškrtávacie políčka majú tento význam:

• Zaistiť referenčnú integritu. Pokiaľ je toto políčko zaškrtnuté, bude MS Access zaisťovať toto obmedzenie. Ako náhle zaškrtnutie zrušíme, nebude systém platnosť relácie zaisťovať.
• Aktualizácia súvisiacich polí v kaskáde. Zaškrtnutie tohto políčka znamená, že sa pri akejkoľvek aktualizácii hodnoty primárneho kľúča v rodičovskej tabuľke, automatiky zrealizuje zodpovedajúca aktualizácia hodnôt cudzích kľúčov vo všetkých zviazaných záznamoch. Aktualizácia primárneho kľúča je ovšem dosť málo realizovaná operácia.
• Odstránenie súvisiacich polí v kaskáde. Toto políčko znamená, že sa pri odstránení riadku v rodičovskej tabuľke automaticky odstráni taktiež kaskáda všetkých záznamov v závislej tabuľke. V tomto prípade je potrebné byť opatrný: niekedy je táto funkcia veľmi užitočná, napríklad pri už pred tým popísaného relačného obmedzenia medzi tabuľkami Objednávky a Rozpis objednávok, zatiaľ čo niekedy môže viesť k nežiaducej a dokonca katastrofálnej strate dát – napríklad pri odstraňovaní zamestnanca by sa z databázy automaticky odstránili i všetky objednávky, ktoré tento zamestnanec prace vybavil.

Prienikové tabuľky

Relačný databázový systém nedokáže typ relácie viaceré k viacerým implementovať priamo, ale ju musíme definovať pomocou ďalšej, prostrednej tabuľky, ktorú nazývame prieniková tabuľka (väzbová entina). Na nasledujúcom obrázku 2.10 je znázornená prieniková tabuľka Rozpis objednávok implementovaná v MS Access.

Obrázok: Prieniková tabuľka Rozpis objednávok MS Access

Z relácie typu M:N medzi objednávkami a výrobkami v konceptuálnom návrhu sme tak v logickom návrhu vytvorili prienikovú tabuľku Rozpis objednávok. Vlastnú reláciu tak implementujeme prostredníctvom dvoch relácií typu 1:N, pričom na strane „N“ sa v obidvoch prípadoch vyskytuje práve prieniková tabuľka. Primárny kľúč tabuľky Rozpis objednávok tvorí kombináciu stĺpcov Číslo objednávky a Číslo výrobku, pričom Číslo objednávky je cudzím kľúčom prevzatým z tabuľky Objednávky a Číslo Výrobku ako cudzí kľúč pochádza z tabuľky Výrobky. Teraz sa na obsah prienikovej tabuľky a na obidve referenčné obmedzenia pozrieme trochu z blízka. Môžeme povedať, že:  

• Každý riadok v prienikovej tabuľke Rozpis objednávok je priradený kombinácii jedného výrobku a jednej objednávky. Do tejto tabuľky rozhodne nemá zmysel zapisovať Názov výrobku, pretože tento názov by sa pri každej jednotlivej objednávke musel opakovať. Rovnako tak nemá zmysel ukladať do tabuľky Kód Zákazníka, pretože všetky riadky z rozpisu jednej objednávky patria vždy rovnakému zákazníkovi.
• Ku každému riadku tabuľky Výrobky môže byť priradené ľubovoľné množstvo riadkov v tabuľke Rozpis objednávok, ale jeden riadok tabuľky Rozpis objednávok prináleží vždy iba k jednému riadku tabuľky Výrobky.
• S každým riadkom tabuľky Objednávky môže byť zviazané ľubovoľné množstvo riadkov tabuľky Rozpis objednávok, ale jeden riadok tabuľky Rozpis objednávok prináleží vždy iba k jednému riadku tabuľky Objednávky.

Obmedzenie integrity

Do obmedzenia v logickom návrhu sa premietajú aplikačné pravidlá z konceptuálneho návrhu databázy. Obmedzenie integrity je pri tom také obmedzenie, ktoré zvyšuje presnosť dát v databáze. Podstatnou výhodou je, že tieto obmedzenia sú zaisťované automaticky relačným databázovým systémom, a že je ich nemôžeme obísť (okrem databázového administrátora). Najdôležitejšími typmi obmedzenia integrity sú obmedzenie typu NOT NULL, obmedzenie CHECK a obmedzenie zaistené pomocou spúšti.

Obmedzenie typu NOT NULL

Pri definícii stĺpcov v databázovej tabuľke máme možnosť stanoviť, či majú byť v stĺpci povolené alebo zakázané hodnoty NULL. Hodnota NULL vyjadruje v relačnej databáze špeciálny kód, ktorý znamená, že pre daný riadok je údaj tohto stĺpca neznámy. To znamená, že hodnota NULL nie je úplne to isté čo prázdna číselná hodnota, prázdny reťazec alebo nula – je to skutočne špeciálny kód, ktorý v databáze nemá žiadny iný význam.

Hodnota NULL nie je rovná ničomu inému a to ani inej hodnote NULL, tak že pri vyhľadávaní v databáze vzniká zvláštna trojhodnotová logika. So zapojením hodnôt NULL môže operácia hľadania vrátiť pravdivostnú hodnotu TRUE (pravda) – hodnota stĺpca sa zhoduje, FALSE (nepravda) – hodnota stĺpca sa nezhoduje, alebo UNKNOWN (neznáma) – stĺpec obsahuje hodnotu NULL. Programátori, ktorí nad databázami píšu aplikačné programy, potom musia hodnoty NULL ošetriť ako špeciálny prípad.  

V MS Access definujeme obmedzenie typu NOT NULL pomocou voľby Je nutné zadať, ktorá sa nachádza na panely návrhového zobrazenia tabuľky. Ak sa pozrieme na obrázok 2.11 kde je znázornená definícia stĺpca Dátum narodenia v tabuľke Zamestnanci: pri tomto stĺpci je v parametre Je nutné zadať nastavené Nie, a preto hodnota nie je povinná a stĺpec povoľuje i hodnotu NULL. V jazyku SQL zapíšeme do definície príslušného stĺpca jednoducho kľúčové slovo NULL alebo NOT NULL.

Obrázok 2.11: Panel s definíciou tabuľky Zamestnanci, zvýraznený stĺpec Dátum narodenia

Obmedzenie typu CHECK

Obmedzenie typu CHECK overuje platnosť hodnoty stĺpca pomocou jednoduchého logického výrazu. Výsledok tohto výrazu musí byť logická hodnota pravda alebo nepravda (TRUE alebo FALSE), pričom TRUE povoľuje zápis hodnoty do stĺpca tabuľky, zatiaľ čo FALSE znamená jej odmietnutie s príslušnou chybovou správou.

Ak sa pozrieme na obrázok 2.11, kde je v položke Overovacie pravidlo v stĺpci Dátum narodenia zapísaný výraz:

“<Date()”.

Toto pravidlo znamená, že do tabuľky zamestnancov nesmieme zapísať taký dátum narodenia, ktorý nastane až niekedy v budúcnosti. V iných databázach platí síce pre zápis podmienky iná syntax, ale základný princíp je rovnaký. V jazyku SQL pod databázou Oracle zapíšeme napríklad rovnakú podmienku takto:

 CHECK (BIRTH_DATE < CURRENT_DATE)

Vynútenie obmedzení pomocou „spúští“

Niektoré obmedzenia sú príliš komplikované a v jednoduchej deklarácii sa vynútiť alebo zaistiť nedajú. Do tejto kategórie patrí napríklad aplikačné pravidlo z obrázku 2.1 (“Zákazníci s nezaplatenými pohľadávkami nemôžu podávať nové objednávky”), pretože pri jeho overení musíme pracovať s údajmi z niekoľkých tabuliek.

V prípade, že riadok tabuľky Zákazníci obsahuje v stĺpci s pohľadávkou (Číslo pohľadávky) nezaplatenú čiastku väčšiu ako nula, nedovolíme v databáze pridanie nových objednávok , teda nových riadkov do tabuľky Objednávky od tohto zákazníka. Spúšť (trigger) je modul programovej logiky, ktorý sa “odpáli”, čiže spustí pri vzniku určitej udalosti v databáze. V našom príklade budeme chcieť, aby sa spúšť odpálila pri každom vložení nového riadku do tabuľky Objednávky: spúšť načíta hodnotu nezaplatených objednávok z tabuľky zákazníkov a pokiaľ je väčšia ako nula, vyvolá v databáze chybu, ktorá zastaví operáciu vloženia dát a zobrazí zodpovedajúcu chybovú správu.

V Microsoft Access môžeme spúšť zapísať pomocou makier jazyka MS VBA (Visual Basic for Applications). Niektoré relačné databázové systémy majú pre zápis programových modulov spúští svoj vlastný, špeciálny jazyk: Oracle má tak jazyk PL/SQL a databáza Microsoft SQL Server a Sybase pracujú s jazykom Transact SQL. V iných relačných databázach, napríklad DB2, môžeme využiť všeobecný programovací jazyk, ako napríklad C.   

Pohľady

Pohľad je uložený databázový dotaz, ktorý užívateľovi databázy predkladá istú upravenú podmnožinu dát z jednej alebo viacerých tabuliek. Inými slovami, pohľad je určitá virtuálna tabuľka, pretože vypadá ako skutočná tabuľka a do značnej miery sa aj chová, ale žiadne dáta v nej fyzicky uložené nie sú (do pohľadu sa ukladá iba definícia dotazu). Užívateľské pohľady tvoria v modeli ANSI/SPARC externú vrstvu.

Pohľady tvoríme v priebehu fázy logického návrhu, a to postupom platným v konkrétnej databáze.

Vo viacerých relačných databázových systémoch definujeme pohľady pomocou jazyka SQL.

V MS Access sa pohľady označujú ako dotazy. Na nasledujúcom obrázku 2.12 je príklad definície jednoduchého dotazu.

Pohľady majú celý rad užitočných vlastností:

• Skrývajú stĺpce, ktoré užívateľ nepotrebuje vidieť (alebo ktoré mu nie sú dovolené)
• Skrývajú v tabuľke riadky, ktoré užívateľ nepotrebuje vidieť (alebo ktoré mu nie sú dovolené)
• Skrývajú užívateľovi zložité databázové operácie, ako je spojenie tabuliek

Obrázok 2.12 Pohľad v databáze MS Access