Pojem „vzťahový“ znamená „založený na vzťahoch“. Relačnú databázu tvoria entity (tabuľky), ktoré majú medzi sebou nejaký vzťah. Názov pochádza z anglické slovo vzťah
Návrh databázy pozostáva z dvoch hlavných fáz: logického a fyzického modelovania.
Počas logického modelovania zbierate požiadavky a vyvíjate databázový model, ktorý je nezávislý od konkrétneho DBMS (systém riadenia relačnej databázy). Je to ako vytvárať plány pre váš dom. Všetko by ste si mohli premyslieť a nakresliť: kde bude kuchyňa, spálne, obývačka. Ale to všetko je na papieri a v maketách.
Počas fyzického modelovania vytvoríte model, ktorý je optimalizovaný pre konkrétnu aplikáciu a DBMS. Práve tento model sa zavádza do praxe. Ak sa vrátime k domu z predchádzajúceho odseku, v tejto fáze budete musieť dom niekde postaviť - nosiť polená, tehly...

Proces návrhu databázy pozostáva z nasledujúcich krokov:

• zber informácií;
• definícia entity;
• definovanie atribútov pre každú entitu;
• definovanie vzťahov medzi entitami;
• normalizácia;
• konverzia na fyzikálny model;
• vytvorenie databázy.

Prvých 5 fáz tvorí fázu logického návrhu a zvyšné dve tvoria fázu fyzického modelovania.

Logická fáza

Logická fáza pozostáva z niekoľkých etáp. Všetky sú uvedené nižšie.

Požiadavky na zber

V tejto fáze musíte presne určiť, ako sa bude databáza používať a aké informácie v nej budú uložené. Zhromaždite čo najviac informácií o tom, čo by systém mal a nemal robiť.

Definovanie entít

V tejto fáze je potrebné definovať entity, ktoré budú tvoriť databázu.

Entita je objekt v databáze, ktorý ukladá dáta. Entita môže byť niečo hmotné (dom, osoba, objekt, miesto) alebo niečo abstraktné (banková transakcia, oddelenie spoločnosti, autobusová trasa). Vo fyzikálnom modeli sa entita nazýva tabuľka.

Entity pozostávajú z atribútov (stĺpce tabuľky) a záznamov (riadky v tabuľke).

Databázy zvyčajne pozostávajú z niekoľkých hlavných entít, s ktorými súvisia veľké množstvo podriadených subjektov. Základné entity sa nazývajú nezávislé: nezávisia od žiadnej inej entity. Podriadené entity sa nazývajú závislé entity: na to, aby jedna z nich existovala, musí existovať pridružená primárna tabuľka.
V diagramoch sú entity zvyčajne znázornené ako obdĺžniky. Názov entity je uvedený vo vnútri obdĺžnika:

Každá tabuľka má nasledujúce vlastnosti:

• nie sú v ňom identické čiary;
• všetky stĺpce (atribúty) v tabuľke musia mať rôzne názvy;
• prvky v tom istom stĺpci majú rovnaký typ (reťazec, číslo, dátum);
• Poradie riadkov v tabuľke môže byť ľubovoľné.

V tejto fáze je potrebné identifikovať všetky kategórie informácií (entít), ktoré budú uložené v databáze.

Definovanie atribútov

Atribút predstavuje vlastnosť, ktorá popisuje entitu. Atribúty sú často číslo, dátum alebo text. Všetky údaje uložené v atribúte musia byť rovnakého typu a musia mať rovnaké vlastnosti.
Vo fyzickom modeli sa atribúty nazývajú stĺpce.
Po zadefinovaní entít musíte definovať všetky atribúty týchto entít.
V diagramoch sú atribúty zvyčajne uvedené vo vnútri obdĺžnika entity. Na obrázku nájdete príklad databázy „Domy“, len teraz sú pre entity z tejto databázy definované niektoré atribúty.


Pre každý atribút typ údajov, jeho veľkosť, platné hodnoty a akékoľvek iné pravidlá. Patria sem pravidlá povinného vypĺňania, meniteľnosti a jedinečnosti.
Povinné pravidlo určuje, či je atribút povinnou súčasťou entity. Ak je atribút voliteľnou súčasťou entity, môže mať hodnotu NULL, inak nie.
Musíte tiež určiť, či je atribút premenlivý. Niektoré hodnoty atribútov nie je možné po vytvorení záznamu zmeniť.
Nakoniec musíte určiť, či je atribút jedinečný. Ak je to tak, hodnoty atribútov sa nemôžu opakovať.

Keys

Kľúč je súbor atribútov, ktoré jednoznačne identifikujú záznam. Kľúče sú rozdelené do dvoch tried: jednoduché a zložené.
Jednoduchý kľúč pozostáva iba z jedného atribútu. Napríklad v databáze „Pasy občanov krajiny“ bude číslo pasu s jednoduchým kľúčom: Koniec koncov, neexistujú dva pasy s rovnakým číslom.
Zložený kľúč pozostáva z niekoľkých atribútov. V tej istej databáze „Pasy občanov krajiny“ môže byť zložený kľúč s nasledujúcimi atribútmi:
priezvisko, meno, priezvisko, dátum narodenia. Toto je len príklad, keďže tento zložený kľúč teoreticky neposkytuje zaručenú jedinečnosť záznamu.
Existuje tiež niekoľko typov kľúčov, ktoré sú popísané nižšie.

Možná stopa

Kandidátsky kľúč je akýkoľvek súbor atribútov, ktorý jednoznačne identifikuje záznam v tabuľke. Možný kľúč môže byť jednoduchý alebo zložený.
Každá entita musí mať aspoň jeden možný kľúč, hoci ich môže byť viac. Žiadny z atribútov primárneho kľúča nemôže mať nulovú hodnotu.
Kandidátsky kľúč sa tiež nazýva náhradný kľúč.

Primárne kľúče

Primárny kľúč je súbor atribútov, ktoré jednoznačne identifikujú záznam v tabuľke (entitu). Jeden z kandidátskych kľúčov sa stane primárnym kľúčom. V diagramoch sú primárne kľúče často zobrazené nad hlavným zoznamom atribútov alebo zvýraznené špeciálnymi znakmi. Entita na obrázku má kľúčové aj bežné atribúty.

Alternatívne kľúče

Akýkoľvek možný kľúč, ktorý nie je primárnym kľúčom, sa nazýva alternatívny kľúč. Entita môže mať viacero alternatívnych kľúčov.

Cudzie kľúče

Cudzí kľúč je súbor atribútov, ktoré odkazujú na primárny alebo alternatívny kľúč inej entity. Ak cudzí kľúč nie je spojený s primárnou entitou, môže obsahovať iba hodnoty null. Ak je kľúč zložený, všetky atribúty cudzieho kľúča musia byť nedefinované.
V diagramoch sú atribúty, ktoré sú kombinované do cudzích kľúčov, označené špeciálnymi znakmi. Na obrázku sú znázornené dve spriaznené entity (Domy a ich vlastníci) a nimi tvorené cudzie kľúče (veď jedna osoba môže vlastniť viacero domov).

Kľúče sú logické konštrukcie, nie fyzické objekty. Relačné databázy majú mechanizmy na zabezpečenie uloženia kľúčov.

Definovanie vzťahov medzi entitami

Relačné databázy umožňujú kombinovať informácie patriace rôznym entitám.
Vzťah je situácia, v ktorej jedna entita odkazuje na primárny kľúč druhej entity. Ako napríklad entity House a Master na predchádzajúcom obrázku.
Vzťahy sú definované počas procesu návrhu databázy. Ak to chcete urobiť, mali by ste analyzovať entity a identifikovať logické spojenia, ktoré medzi nimi existujú.
Typ vzťahu určuje počet záznamov entity, ktoré súvisia s iným záznamom entity. Vzťahy sú rozdelené do troch hlavných typov, ktoré sú popísané nižšie.

Jeden na jedného

Každý záznam prvej entity zodpovedá iba jednému záznamu z druhej entity. A každý záznam druhej entity zodpovedá iba jednému záznamu z prvej entity. Napríklad existujú dve entity: Ľudia a Rodné listy. A jedna osoba môže mať len jeden rodný list.

Jeden k mnohým

Každý záznam prvej entity môže zodpovedať niekoľkým záznamom druhej entity. Každý záznam druhej entity však zodpovedá iba jednému záznamu z prvej entity. Napríklad existujú dve entity: objednávka a položka objednávky. A jedna objednávka môže obsahovať veľa produktov.

Mnoho-k-mnohým

Každý záznam prvej entity môže zodpovedať niekoľkým záznamom druhej entity. Každý záznam druhej entity však môže zodpovedať niekoľkým záznamom z prvej entity. Napríklad existujú dve entity: Autor a Kniha. Jeden autor môže napísať veľa kníh. Ale kniha môže mať viacero autorov.
Podľa kritéria obligatórnosti sa vzťahy delia na obligatórne a fakultatívne.

• Povinný vzťah znamená, že pre každý záznam v prvej entite musia existovať súvisiace záznamy v druhej entite.
• Nepovinný vzťah znamená, že záznam z prvej entity nemusí mať záznam v druhej entite.

Normalizácia

Normalizácia je proces odstránenia nadbytočných údajov z databázy. Každý dátový prvok musí byť v databáze uložený len v jednej kópii. Existuje päť bežných foriem normalizácie. Typicky je databáza zredukovaná na tretiu normálnu formu.
Počas procesu normalizácie určité akcie na odstránenie nadbytočných údajov. Normalizácia zlepšuje výkon, urýchľuje triedenie a vytváranie indexov, znižuje počet indexov na entitu a urýchľuje operácie vkladania a aktualizácie.
Normalizovaná databáza je zvyčajne flexibilnejšia. Pri úprave dotazov alebo uložených údajov normalizovaná databáza zvyčajne vyžaduje menej zmien a zmeny majú menej dôsledkov.

Prvá normálna forma

Ak chcete previesť entitu do prvej normálnej formy, musíte odstrániť duplicitné skupiny hodnôt a zabezpečiť, aby každý atribút obsahoval iba jednu hodnotu.
Inými slovami, každý atribút musí byť v podstate uložený iba v jednej inštancii.
Napríklad na obrázku nie je entita Domov normalizovaná. Obsahuje niekoľko atribútov na ukladanie údajov o vlastníkoch domu (entita Dom nezodpovedá prvému normálnemu tvaru).

Na uvedenie entity House do prvej normálnej formy je potrebné odstrániť opakujúce sa skupiny hodnôt, to znamená odstrániť atribúty Owner 1-3 a umiestniť ich do samostatnej entity. Výsledok (Essence House zredukovaný na prvú normálnu formu):

Druhá normálna forma

Tabuľka v druhej normálnej forme obsahuje iba údaje, ktoré sa jej týkajú. Hodnoty nekľúčových atribútov entity závisia od primárneho kľúča. Presnejšie povedané, atribúty závisia od primárneho kľúča, od celého primárneho kľúča a iba od primárneho kľúča.
Aby boli entity v súlade s druhou normálnou formou, musia byť v prvej normálnej forme.
Napríklad entita Dom na obrázku má atribút Cena za liter benzínu, ktorý nemá nič spoločné s domami. Tento atribút je odstránený (alebo ho môžete presunúť do inej entity). Na samostatnú entitu prenášame aj atribút Starosta – tento atribút závisí od mesta, kde sa dom nachádza, a nie od domu.
Na obrázku je znázornená esencia domu v druhej normálnej forme (podstata domu zredukovaná na druhú normálnu formu).

Tretia normálna forma

Tretia normálna forma vylučuje atribúty, ktoré nezávisia od celého kľúča. Každá entita, ktorá je v tretej normálnej forme, je aj v druhej normálnej forme. Toto je najbežnejšia forma databázy.
V tretej normálnej forme každý atribút závisí od kľúča, od celého kľúča a od ničoho iného ako od kľúča.
Napríklad entita majiteľ domu na obrázku má atribút znamenia zverokruhu, ktorý závisí od dátumu narodenia majiteľa domu a nie od jeho mena (ktoré je kľúčom).
Ak chcete priniesť entitu vlastníka domu, musíte vytvoriť entitu Znamenia zverokruhu a preniesť tam atribút znamenia zverokruhu (entita vlastníka domu zredukovaná na tretiu normálnu formu):

Obmedzenia

Obmedzenia- to sú pravidlá, ktoré monitoruje systém správy databáz. Obmedzenia definujú množinu hodnôt, ktoré možno zadať do stĺpca alebo stĺpcov.
Napríklad nechcete, aby suma objednávky vo vašom skvelom obchode bola nižšia ako 500 rubľov. Jednoducho nastavíte limit v stĺpci Čiastka objednávky.

Uložené procedúry

Uložené procedúry sú predkompilované procedúry uložené v databáze. Uložené procedúry sa dajú použiť na definovanie obchodných pravidiel a môžu vykonávať zložitejšie výpočty ako pri použití samotných obmedzení.
Uložené procedúry môžu obsahovať logiku toku programu, ako aj databázové dotazy. Môžu akceptovať parametre a vrátiť výsledky ako tabuľky alebo jednotlivé hodnoty.
Uložené procedúry sú podobné bežným procedúram alebo funkciám v akomkoľvek programe.

POZNÁMKA
Uložené procedúry sú uložené v databáze a spúšťajú sa na databázovom serveri. Vo všeobecnosti sú rýchlejšie ako príkazy SQL, pretože sú uložené v kompilovanej forme.

Integrita údajov

Po usporiadaní údajov do tabuliek a určení vzťahov medzi nimi môžeme uvažovať, že bol vytvorený model, správnym spôsobom odráža podnikateľské prostredie. Teraz musíme zabezpečiť, aby údaje vložené do databázy poskytovali správny obraz o stave vecí. Inými slovami, musíte zabezpečiť dodržiavanie obchodných pravidiel a zachovanie integrity databázy.
Vaša spoločnosť napríklad dodáva knihy. Je nepravdepodobné, že prijmete objednávku od neznámeho klienta, pretože potom nebudete môcť objednávku ani doručiť. Z toho vyplýva obchodné pravidlo: objednávky sú prijímané len od klientov, ktorých údaje sú v databáze.
Správnosť údajov v relačných databázach je zabezpečená súborom pravidiel. Pravidlá integrity údajov spadajú do štyroch kategórií.

• Integrita entity- každý záznam entity musí mať jedinečný identifikátor a musí obsahovať údaje. Všetky tieto záznamy v databáze musíte predsa nejako rozlíšiť.
• Integrita atribútu- každý atribút akceptuje iba platné hodnoty. Napríklad suma nákupu rozhodne nemôže byť nižšia ako nula.
• Referenčná integrita- súbor pravidiel, ktoré zabezpečujú logickú konzistenciu primárneho a cudzieho kľúča pri vkladaní, aktualizácii a odstraňovaní záznamov. Referenčná integrita zabezpečuje, že pre každý cudzí kľúč existuje zodpovedajúci primárny kľúč. Zoberme si predchádzajúci príklad s entitami Vlastník domu a Dom. Povedzme, že ste Vasja Ivanov a vlastníte dom. Zmenili ste si priezvisko na Sidorov a urobili ste zodpovedajúce zmeny v entite Vlastník domu. Určite by ste chceli, aby bol váš dom naďalej registrovaný pod vaším novým menom a nepatril istému Vasyovi Ivanovovi, ktorý už neexistuje.
• Vlastné pravidlá integrity- akékoľvek pravidlá integrity, ktoré nepatria do žiadnej z uvedených kategórií.

Spúšťače

Spúšťač je analógom uloženej procedúry, ktorá sa volá automaticky pri zmene údajov v tabuľke.
Spúšťače sú mocným mechanizmom na udržiavanie integrity databázy. Spúšťače sa volajú pred alebo po zmene údajov v tabuľke.
Pomocou spúšťačov môžete tieto zmeny nielen vrátiť späť, ale aj zmeniť údaje v akejkoľvek inej tabuľke.
Napríklad vytvárate online fórum a musíte sa uistiť, že najnovší príspevok fóra je zobrazený v zozname fór. Samozrejme, môžete prevziať správu od entity Správy vo fóre, ale tým sa zvýši zložitosť vašej požiadavky a čas jej vykonania. Jednoduchšie je pridať spúšťač do entity Správy fóra, ktorý by zaznamenal poslednú pridanú správu do entity Fórum, v atribúte Posledná správa. To výrazne zjednoduší požiadavku.

Obchodné pravidlá

Obchodné pravidlá definujú obmedzenia kladené na údaje podľa požiadaviek podniku (tých, pre ktorých databázu vytvárate). Obchodné pravidlá môžu pozostávať zo súboru krokov potrebných na dokončenie špecifickej úlohy, alebo to môžu byť jednoducho kontroly, ktoré zabezpečia správnosť zadaných údajov. Obchodné pravidlá môžu zahŕňať pravidlá integrity údajov. Na rozdiel od iných pravidiel je ich hlavným účelom zabezpečenie riadneho priebehu obchodných transakcií.
Napríklad vo firme Very Cool Guys môže byť zvykom, že pre úradné potreby sa kupujú len biele, modré a čierne autá.
Potom by obchodným pravidlom pre atribút Farba vozidla entity Firemné vozidlá bolo, že vozidlo môže byť iba biele, modré alebo čierne.
Väčšina DBMS poskytuje zariadenia:

• určiť predvolené hodnoty;
• skontrolovať údaje pred ich vložením do databázy;
• udržiavať vzťahy medzi tabuľkami;
• zabezpečiť jedinečnosť hodnôt;
• na ukladanie uložených procedúr priamo v databáze.

Všetky tieto možnosti možno použiť na implementáciu obchodných pravidiel v databáze.

Fyzikálny model

Ďalším krokom po vytvorení logického modelu je vytvorenie fyzického modelu. Fyzický model je praktická implementácia databázy. Fyzický model definuje všetky objekty, ktoré musíte implementovať.
Pri prechode z logického modelu na fyzickú entitu sa atribúty skonvertujú na tabuľky a atribúty na stĺpce.
Vzťahy medzi entitami je možné previesť na tabuľky alebo ponechať ako cudzie kľúče.
Primárne kľúče sa skonvertujú na obmedzenia primárneho kľúča. Možné kľúče sú v obmedzeniach jedinečnosti.

Denormalizácia

Denormalizácia je zámerná zmena v štruktúre základne, ktorá porušuje pravidlá normálnych foriem. Zvyčajne sa to robí na zlepšenie výkonu databázy.
Teoreticky by ste sa mali vždy snažiť o úplne normalizovanú základňu, ale v praxi úplná normalizácia základne takmer vždy znamená pokles výkonu. Prílišná normalizácia databázy môže viesť k tomu, že pri každom načítaní údajov bude potrebné pristupovať k viacerým tabuľkám. Typicky musí dotaz zahŕňať štyri tabuľky alebo menej.
Štandardné denormalizačné techniky sú: zlučovanie niekoľkých tabuliek do jednej, ukladanie rovnakých atribútov do niekoľkých tabuliek a ukladanie súhrnných alebo vypočítaných údajov do tabuľky.

Pojem „vzťahový“ znamená „založený na vzťahoch“. Relačnú databázu tvoria entity (tabuľky), ktoré majú medzi sebou nejaký vzťah. Názov pochádza z anglického slova relácia.
Návrh databázy pozostáva z dvoch hlavných fáz: logického a fyzického modelovania.
Počas logického modelovania zbierate požiadavky a vyvíjate databázový model, ktorý je nezávislý od konkrétneho DBMS (systém riadenia relačnej databázy). Je to ako vytvárať plány pre váš dom. Všetko by ste si mohli premyslieť a nakresliť: kde bude kuchyňa, spálne, obývačka. Ale to všetko je na papieri a v maketách.
Počas fyzického modelovania vytvoríte model, ktorý je optimalizovaný pre konkrétnu aplikáciu a DBMS. Práve tento model sa zavádza do praxe. Ak sa vrátime k domu z predchádzajúceho odseku, v tejto fáze budete musieť dom niekde postaviť - nosiť polená, tehly...

Proces návrhu databázy pozostáva z nasledujúcich krokov:

• zber informácií;
• definícia entity;
• definovanie atribútov pre každú entitu;
• definovanie vzťahov medzi entitami;
• normalizácia;
• konverzia na fyzikálny model;
• vytvorenie databázy.

Prvých 5 fáz tvorí fázu logického návrhu a zvyšné dve tvoria fázu fyzického modelovania.

Logická fáza

Logická fáza pozostáva z niekoľkých etáp. Všetky sú uvedené nižšie.

Požiadavky na zber

V tejto fáze musíte presne určiť, ako sa bude databáza používať a aké informácie v nej budú uložené. Zhromaždite čo najviac informácií o tom, čo by systém mal a nemal robiť.

Definovanie entít

V tejto fáze je potrebné definovať entity, ktoré budú tvoriť databázu.

Entita je objekt v databáze, ktorý ukladá dáta. Entita môže byť niečo hmotné (dom, osoba, objekt, miesto) alebo niečo abstraktné (banková transakcia, oddelenie spoločnosti, autobusová trasa). Vo fyzikálnom modeli sa entita nazýva tabuľka.

Entity pozostávajú z atribútov (stĺpce tabuľky) a záznamov (riadky v tabuľke).

Databázy zvyčajne pozostávajú z niekoľkých hlavných entít spojených s veľkým počtom podriadených entít. Základné entity sa nazývajú nezávislé: nezávisia od žiadnej inej entity. Podriadené entity sa nazývajú závislé entity: na to, aby jedna z nich existovala, musí existovať pridružená primárna tabuľka.
V diagramoch sú entity zvyčajne znázornené ako obdĺžniky. Názov entity je uvedený vo vnútri obdĺžnika:

Každá tabuľka má nasledujúce vlastnosti:

• nie sú v ňom identické čiary;
• všetky stĺpce (atribúty) v tabuľke musia mať rôzne názvy;
• prvky v tom istom stĺpci majú rovnaký typ (reťazec, číslo, dátum);
• Poradie riadkov v tabuľke môže byť ľubovoľné.

V tejto fáze je potrebné identifikovať všetky kategórie informácií (entít), ktoré budú uložené v databáze.

Definovanie atribútov

Atribút predstavuje vlastnosť, ktorá popisuje entitu. Atribúty sú často číslo, dátum alebo text. Všetky údaje uložené v atribúte musia byť rovnakého typu a musia mať rovnaké vlastnosti.
Vo fyzickom modeli sa atribúty nazývajú stĺpce.
Po zadefinovaní entít musíte definovať všetky atribúty týchto entít.
V diagramoch sú atribúty zvyčajne uvedené vo vnútri obdĺžnika entity. Na obrázku nájdete príklad databázy „Domy“, len teraz sú pre entity z tejto databázy definované niektoré atribúty.


Pre každý atribút je definovaný typ údajov, jeho veľkosť, prijateľné hodnoty a akékoľvek ďalšie pravidlá. Patria sem pravidlá povinného vypĺňania, meniteľnosti a jedinečnosti.
Povinné pravidlo určuje, či je atribút povinnou súčasťou entity. Ak je atribút voliteľnou súčasťou entity, môže mať hodnotu NULL, inak nie.
Musíte tiež určiť, či je atribút premenlivý. Niektoré hodnoty atribútov nie je možné po vytvorení záznamu zmeniť.
Nakoniec musíte určiť, či je atribút jedinečný. Ak je to tak, hodnoty atribútov sa nemôžu opakovať.

Keys

Kľúč je súbor atribútov, ktoré jednoznačne identifikujú záznam. Kľúče sú rozdelené do dvoch tried: jednoduché a zložené.
Jednoduchý kľúč pozostáva iba z jedného atribútu. Napríklad v databáze „Pasy občanov krajiny“ bude číslo pasu jednoduchým kľúčom: napokon neexistujú dva pasy s rovnakým číslom.
Zložený kľúč pozostáva z niekoľkých atribútov. V tej istej databáze „Pasy občanov krajiny“ môže byť zložený kľúč s nasledujúcimi atribútmi:
priezvisko, meno, priezvisko, dátum narodenia. Toto je len príklad, keďže tento zložený kľúč teoreticky neposkytuje zaručenú jedinečnosť záznamu.
Existuje tiež niekoľko typov kľúčov, ktoré sú popísané nižšie.

Možná stopa

Kandidátsky kľúč je akýkoľvek súbor atribútov, ktorý jednoznačne identifikuje záznam v tabuľke. Možný kľúč môže byť jednoduchý alebo zložený.
Každá entita musí mať aspoň jeden možný kľúč, hoci ich môže byť viac. Žiadny z atribútov primárneho kľúča nemôže mať nulovú hodnotu.
Kandidátsky kľúč sa tiež nazýva náhradný kľúč.

Primárne kľúče

Primárny kľúč je súbor atribútov, ktoré jednoznačne identifikujú záznam v tabuľke (entitu). Jeden z kandidátskych kľúčov sa stane primárnym kľúčom. V diagramoch sú primárne kľúče často zobrazené nad hlavným zoznamom atribútov alebo zvýraznené špeciálnymi znakmi. Entita na obrázku má kľúčové aj bežné atribúty.

Alternatívne kľúče

Akýkoľvek možný kľúč, ktorý nie je primárnym kľúčom, sa nazýva alternatívny kľúč. Entita môže mať viacero alternatívnych kľúčov.

Cudzie kľúče

Cudzí kľúč je súbor atribútov, ktoré odkazujú na primárny alebo alternatívny kľúč inej entity. Ak cudzí kľúč nie je spojený s primárnou entitou, môže obsahovať iba hodnoty null. Ak je kľúč zložený, všetky atribúty cudzieho kľúča musia byť nedefinované.
V diagramoch sú atribúty, ktoré sú kombinované do cudzích kľúčov, označené špeciálnymi znakmi. Na obrázku sú znázornené dve spriaznené entity (Domy a ich vlastníci) a nimi tvorené cudzie kľúče (veď jedna osoba môže vlastniť viacero domov).

Kľúče sú logické konštrukcie, nie fyzické objekty. Relačné databázy majú mechanizmy na zabezpečenie uloženia kľúčov.

Definovanie vzťahov medzi entitami

Relačné databázy umožňujú kombinovať informácie patriace rôznym entitám.
Vzťah je situácia, v ktorej jedna entita odkazuje na primárny kľúč druhej entity. Ako napríklad entity House a Master na predchádzajúcom obrázku.
Vzťahy sú definované počas procesu návrhu databázy. Ak to chcete urobiť, mali by ste analyzovať entity a identifikovať logické spojenia, ktoré medzi nimi existujú.
Typ vzťahu určuje počet záznamov entity, ktoré súvisia s iným záznamom entity. Vzťahy sú rozdelené do troch hlavných typov, ktoré sú popísané nižšie.

Jeden na jedného

Každý záznam prvej entity zodpovedá iba jednému záznamu z druhej entity. A každý záznam druhej entity zodpovedá iba jednému záznamu z prvej entity. Napríklad existujú dve entity: Ľudia a Rodné listy. A jedna osoba môže mať len jeden rodný list.

Jeden k mnohým

Každý záznam prvej entity môže zodpovedať niekoľkým záznamom druhej entity. Každý záznam druhej entity však zodpovedá iba jednému záznamu z prvej entity. Napríklad existujú dve entity: objednávka a položka objednávky. A jedna objednávka môže obsahovať veľa produktov.

Mnoho-k-mnohým

Každý záznam prvej entity môže zodpovedať niekoľkým záznamom druhej entity. Každý záznam druhej entity však môže zodpovedať niekoľkým záznamom z prvej entity. Napríklad existujú dve entity: Autor a Kniha. Jeden autor môže napísať veľa kníh. Ale kniha môže mať viacero autorov.
Podľa kritéria obligatórnosti sa vzťahy delia na obligatórne a fakultatívne.

• Povinný vzťah znamená, že pre každý záznam v prvej entite musia existovať súvisiace záznamy v druhej entite.
• Nepovinný vzťah znamená, že záznam z prvej entity nemusí mať záznam v druhej entite.

Normalizácia

Normalizácia je proces odstránenia nadbytočných údajov z databázy. Každý dátový prvok musí byť v databáze uložený len v jednej kópii. Existuje päť bežných foriem normalizácie. Typicky je databáza zredukovaná na tretiu normálnu formu.
Počas procesu normalizácie sa vykonajú určité kroky na odstránenie nadbytočných údajov. Normalizácia zlepšuje výkon, urýchľuje triedenie a vytváranie indexov, znižuje počet indexov na entitu a urýchľuje operácie vkladania a aktualizácie.
Normalizovaná databáza je zvyčajne flexibilnejšia. Pri úprave dotazov alebo uložených údajov normalizovaná databáza zvyčajne vyžaduje menej zmien a zmeny majú menej dôsledkov.

Prvá normálna forma

Ak chcete previesť entitu do prvej normálnej formy, musíte odstrániť duplicitné skupiny hodnôt a zabezpečiť, aby každý atribút obsahoval iba jednu hodnotu.
Inými slovami, každý atribút musí byť v podstate uložený iba v jednej inštancii.
Napríklad na obrázku nie je entita Domov normalizovaná. Obsahuje niekoľko atribútov na ukladanie údajov o vlastníkoch domu (entita Dom nezodpovedá prvému normálnemu tvaru).

Na uvedenie entity House do prvej normálnej formy je potrebné odstrániť opakujúce sa skupiny hodnôt, to znamená odstrániť atribúty Owner 1-3 a umiestniť ich do samostatnej entity. Výsledok (Essence House zredukovaný na prvú normálnu formu):

Druhá normálna forma

Tabuľka v druhej normálnej forme obsahuje iba údaje, ktoré sa jej týkajú. Hodnoty nekľúčových atribútov entity závisia od primárneho kľúča. Presnejšie povedané, atribúty závisia od primárneho kľúča, od celého primárneho kľúča a iba od primárneho kľúča.
Aby boli entity v súlade s druhou normálnou formou, musia byť v prvej normálnej forme.
Napríklad entita Dom na obrázku má atribút Cena za liter benzínu, ktorý nemá nič spoločné s domami. Tento atribút je odstránený (alebo ho môžete presunúť do inej entity). Na samostatnú entitu prenášame aj atribút Starosta – tento atribút závisí od mesta, kde sa dom nachádza, a nie od domu.
Na obrázku je znázornená esencia domu v druhej normálnej forme (podstata domu zredukovaná na druhú normálnu formu).

Tretia normálna forma

Tretia normálna forma vylučuje atribúty, ktoré nezávisia od celého kľúča. Každá entita, ktorá je v tretej normálnej forme, je aj v druhej normálnej forme. Toto je najbežnejšia forma databázy.
V tretej normálnej forme každý atribút závisí od kľúča, od celého kľúča a od ničoho iného ako od kľúča.
Napríklad entita majiteľ domu na obrázku má atribút znamenia zverokruhu, ktorý závisí od dátumu narodenia majiteľa domu a nie od jeho mena (ktoré je kľúčom).
Ak chcete priniesť entitu vlastníka domu, musíte vytvoriť entitu Znamenia zverokruhu a preniesť tam atribút znamenia zverokruhu (entita vlastníka domu zredukovaná na tretiu normálnu formu):

Obmedzenia

Obmedzenia- to sú pravidlá, ktoré monitoruje systém správy databáz. Obmedzenia definujú množinu hodnôt, ktoré možno zadať do stĺpca alebo stĺpcov.
Napríklad nechcete, aby suma objednávky vo vašom skvelom obchode bola nižšia ako 500 rubľov. Jednoducho nastavíte limit v stĺpci Čiastka objednávky.

Uložené procedúry

Uložené procedúry sú predkompilované procedúry uložené v databáze. Uložené procedúry sa dajú použiť na definovanie obchodných pravidiel a môžu vykonávať zložitejšie výpočty ako pri použití samotných obmedzení.
Uložené procedúry môžu obsahovať logiku toku programu, ako aj databázové dotazy. Môžu akceptovať parametre a vrátiť výsledky ako tabuľky alebo jednotlivé hodnoty.
Uložené procedúry sú podobné bežným procedúram alebo funkciám v akomkoľvek programe.

POZNÁMKA
Uložené procedúry sú uložené v databáze a spúšťajú sa na databázovom serveri. Vo všeobecnosti sú rýchlejšie ako príkazy SQL, pretože sú uložené v kompilovanej forme.

Integrita údajov

Usporiadaním údajov do tabuliek a definovaním vzťahov medzi nimi môžeme predpokladať, že bol vytvorený model, ktorý správne odráža podnikateľské prostredie. Teraz musíme zabezpečiť, aby údaje vložené do databázy poskytovali správny obraz o stave vecí. Inými slovami, musíte zabezpečiť dodržiavanie obchodných pravidiel a zachovanie integrity databázy.
Vaša spoločnosť napríklad dodáva knihy. Je nepravdepodobné, že prijmete objednávku od neznámeho klienta, pretože potom nebudete môcť objednávku ani doručiť. Z toho vyplýva obchodné pravidlo: objednávky sú prijímané len od klientov, ktorých údaje sú v databáze.
Správnosť údajov v relačných databázach je zabezpečená súborom pravidiel. Pravidlá integrity údajov spadajú do štyroch kategórií.

• Integrita entity- každý záznam entity musí mať jedinečný identifikátor a musí obsahovať údaje. Všetky tieto záznamy v databáze musíte predsa nejako rozlíšiť.
• Integrita atribútu- každý atribút akceptuje iba platné hodnoty. Napríklad suma nákupu rozhodne nemôže byť nižšia ako nula.
• Referenčná integrita- súbor pravidiel, ktoré zabezpečujú logickú konzistenciu primárneho a cudzieho kľúča pri vkladaní, aktualizácii a odstraňovaní záznamov. Referenčná integrita zabezpečuje, že pre každý cudzí kľúč existuje zodpovedajúci primárny kľúč. Zoberme si predchádzajúci príklad s entitami Vlastník domu a Dom. Povedzme, že ste Vasja Ivanov a vlastníte dom. Zmenili ste si priezvisko na Sidorov a urobili ste zodpovedajúce zmeny v entite Vlastník domu. Určite by ste chceli, aby bol váš dom naďalej registrovaný pod vaším novým menom a nepatril istému Vasyovi Ivanovovi, ktorý už neexistuje.
• Vlastné pravidlá integrity- akékoľvek pravidlá integrity, ktoré nepatria do žiadnej z uvedených kategórií.

Spúšťače

Spúšťač je analógom uloženej procedúry, ktorá sa volá automaticky pri zmene údajov v tabuľke.
Spúšťače sú mocným mechanizmom na udržiavanie integrity databázy. Spúšťače sa volajú pred alebo po zmene údajov v tabuľke.
Pomocou spúšťačov môžete tieto zmeny nielen vrátiť späť, ale aj zmeniť údaje v akejkoľvek inej tabuľke.
Napríklad vytvárate online fórum a musíte sa uistiť, že najnovší príspevok fóra je zobrazený v zozname fór. Samozrejme, môžete prevziať správu od entity Správy vo fóre, ale tým sa zvýši zložitosť vašej požiadavky a čas jej vykonania. Jednoduchšie je pridať spúšťač do entity Príspevky vo fóre, ktorý by zaznamenal poslednú pridanú správu do entity Fórum v atribúte Posledný príspevok. To výrazne zjednoduší požiadavku.

Obchodné pravidlá

Obchodné pravidlá definujú obmedzenia kladené na údaje podľa požiadaviek podniku (tých, pre ktorých databázu vytvárate). Obchodné pravidlá môžu pozostávať zo súboru krokov potrebných na dokončenie špecifickej úlohy, alebo to môžu byť jednoducho kontroly, ktoré zabezpečia správnosť zadaných údajov. Obchodné pravidlá môžu zahŕňať pravidlá integrity údajov. Na rozdiel od iných pravidiel je ich hlavným účelom zabezpečenie riadneho priebehu obchodných transakcií.
Napríklad vo firme Very Cool Guys môže byť zvykom, že pre úradné potreby sa kupujú len biele, modré a čierne autá.
Potom by obchodným pravidlom pre atribút Farba vozidla entity Firemné vozidlá bolo, že vozidlo môže byť iba biele, modré alebo čierne.
Väčšina DBMS poskytuje zariadenia:

• určiť predvolené hodnoty;
• skontrolovať údaje pred ich vložením do databázy;
• udržiavať vzťahy medzi tabuľkami;
• zabezpečiť jedinečnosť hodnôt;
• na ukladanie uložených procedúr priamo v databáze.

Všetky tieto možnosti možno použiť na implementáciu obchodných pravidiel v databáze.

Fyzikálny model

Ďalším krokom po vytvorení logického modelu je vytvorenie fyzického modelu. Fyzický model je praktická implementácia databázy. Fyzický model definuje všetky objekty, ktoré musíte implementovať.
Pri prechode z logického modelu na fyzickú entitu sa atribúty skonvertujú na tabuľky a atribúty na stĺpce.
Vzťahy medzi entitami je možné previesť na tabuľky alebo ponechať ako cudzie kľúče.
Primárne kľúče sa skonvertujú na obmedzenia primárneho kľúča. Možné kľúče sú v obmedzeniach jedinečnosti.

Denormalizácia

Denormalizácia je zámerná zmena v štruktúre základne, ktorá porušuje pravidlá normálnych foriem. Zvyčajne sa to robí na zlepšenie výkonu databázy.
Teoreticky by ste sa mali vždy snažiť o úplne normalizovanú základňu, ale v praxi úplná normalizácia základne takmer vždy znamená pokles výkonu. Prílišná normalizácia databázy môže viesť k tomu, že pri každom načítaní údajov bude potrebné pristupovať k viacerým tabuľkám. Typicky musí dotaz zahŕňať štyri tabuľky alebo menej.
Štandardné denormalizačné techniky sú: zlučovanie niekoľkých tabuliek do jednej, ukladanie rovnakých atribútov do niekoľkých tabuliek a ukladanie súhrnných alebo vypočítaných údajov do tabuľky.

Entita je skutočný alebo abstraktný objekt, ktorý má významný význam pre predmetnú oblasť. Subjekt musí mať názov, vyjadrené podstatným menom jednotného čísla

Neformálnym spôsobom identifikácie entít je hľadanie abstrakcií, ktoré popisujú objekty, procesy, roly a iné koncepty. Formálnym spôsobom identifikácie entít je analýza textových popisov predmetnej oblasti, zvýraznenie podstatných mien a ich výber ako abstrakcie.

Inštancia entity je špecifickým zástupcom danej entity. Napríklad inštanciou entity Zamestnanec môže byť zamestnanec Ivanov.

Každá entita musí mať nasledujúce vlastnosti:

mať jedinečný názov;

majú jeden alebo viac atribútov, ktoré buď patria entite, alebo sa zdedia prostredníctvom vzťahu;

majú jeden alebo viac atribútov, ktoré jedinečne identifikujú každú inštanciu entity.

Atribút je charakteristika entity, ktorá je významná pre predmetnú oblasť a je určená na identifikáciu, klasifikáciu, kvantifikáciu alebo vyjadrenie stavu entity.

Existujú nasledujúce typy atribútov:

jednoduchý - pozostáva z jedného dátového prvku;

kompozitný – pozostáva z viacerých dátových prvkov;

jednoznačný – obsahuje jednu hodnotu pre jednu entitu;

viachodnotové - obsahuje niekoľko hodnôt pre jednu entitu;

voliteľné - môže mať prázdnu (nedefinovanú) hodnotu;

derivovaný - hodnota odvodená od hodnoty iného atribútu.

Jedinečný identifikátor je množina atribútov, ktorých hodnoty sú spolu jedinečné pre každú inštanciu entity. Odstránenie akéhokoľvek atribútu z identifikátora porušuje jeho jedinečnosť. Jedinečné identifikátory sú na diagrame znázornené podčiarknutím

Každá entita môže mať ľubovoľný počet spojení s inými entitami.

Vzťahy medzi subjektmi

Vzťah je pomenované spojenie medzi entitami, ktoré je významné pre predmetnú oblasť.

Stupeň spojenia je počet subjektov zapojených do spojenia.

Komunikačná sila – počet inštancií entity zúčastňujúcich sa komunikácie.

V závislosti od hodnoty výkonu môže byť komunikácia jedným z troch typov:

jeden k jednému (označené 1:1).

jedna ku mnohým (označená 1:N).

many-to-many (označené M:N).

Jeden na jedného. Znamená to, že v takomto vzťahu entity s jednou rolou vždy zodpovedajú nie viac ako jednej entite s inou rolou. Keďže stupeň spojenia pre každú entitu je 1, sú spojené jednou čiarou.

Jeden k mnohým. Entita s jednou rolou môže byť spojená s ľubovoľným počtom entít s inou rolou.

Mnoho-k-mnohým. V tomto prípade môže byť každá z pridružených entít reprezentovaná ľubovoľným počtom inštancií.

Pred pár rokmi medzi moje ďalšie aktivity patrili online lekcie o základoch konštrukcie logickej štruktúry databázy a jazyku SQL. Lekcie na tento moment Neštudujem, ale samotné nahrávky zostali, tak som sa rozhodol ich zverejniť, prečo to márne plytvať? 🙂

Dnes si povieme niečo o entitno-vzťahovom modeli.

teória

Entity-Relationship model alebo ER model je vysokoúrovňový koncepčný dátový model, ktorý bol vyvinutý na zjednodušenie úlohy navrhovania databázových štruktúr.

Tento model je súborom pojmov, ktoré popisujú štruktúru databázy ako súbor entít, atribútov a vzťahov. Hlavným účelom vývoja takéhoto dátového modelu je vytvoriť užívateľské vnímanie dát a zosúladiť veľké množstvo technických aspektov spojených s návrhom databázy. Je potrebné poznamenať, že koncepčný dátový model nezávisí od konkrétnej DBMS alebo hardvérovej platformy, ktorá sa používa na implementáciu databázy.

Účelom entitno-relačných diagramov je vytvoriť presnú a úplnú reprezentáciu reálnej predmetnej oblasti (SbA), ktorá sa následne používa ako zdroj informácií pre budovanie databázy. automatizované systémy spracovanie informácií (DB ASOI).

Tento diagram alebo koncepčný model SbA musí spĺňať nasledujúce požiadavky:

• Zabezpečte primerané zobrazenie SbA;
• Prezentované v jazyku zrozumiteľnom pre budúcich používateľov ASOI aj pre vývojárov databáz;
• Obsahovať dostatočné informácie o SbA pre ďalší návrh databázy (vývoj logických a fyzických modelov);
• Zaručiť jednoznačnú interpretáciu alebo interpretáciu modelu SbA.

Hlavnými konceptmi tohto modelu sú koncepty entity, atribútu a vzťahu.

PODSTATA je súbor objektov v reálnom svete s rovnakými vlastnosťami. Entita sa vyznačuje nezávislou existenciou a môže to byť objekt s fyzickou (alebo reálnou) existenciou alebo objekt s konceptuálnou (alebo abstraktnou) existenciou.

Entita predstavuje hlavný obsah javu alebo procesu (transakcie alebo požiadavky), o ktorom je potrebné zbierať informácie, a je uzlovým bodom pre zhromažďovanie informácií. Entita sa vzťahuje na súbor homogénnych predmetov alebo vecí. Každá entita je identifikovaná názvom a zoznamom vlastností (atribútov). Subjektom môže byť osoba, miesto, vec a pod., informácie o ktorých musia byť uložené v databáze.

Prax

PRÍKLAD. Oblasť témy " Objednávanie lístkov v kine" V kine sa premietajú filmy, na ktoré je možné zakúpiť si vstupenky v deň premietania alebo vopred rezervovať. Databáza obsahuje informácie o všetkých Filmových predstaveniach v danom kine, vrátane starých. Každá filmová projekcia má svoj náklad, t.j. lístky na ten istý film, ale v iný čas, môže sa líšiť v cene. Filmovú výstavu tvorí Film, o ktorom sú informácie uložené aj v databáze.

Pre softvér “ Objednávanie lístkov v kine” entity budú nasledujúce pojmy:

Premietanie filmu

Filmy

Divák

Lístok

Rezervácia

cena

Graficky sú entity v diagramoch vzťahov medzi entitami reprezentované ako obdĺžniky:

ATRIBÚT— je to prostriedok, ktorým sa definujú vlastnosti entity alebo vzťahu. Atribút je pomenovaná charakteristika entity. Názov atribútu musí byť jedinečný pre konkrétnu entitu, ale môže byť rovnaký pre rôzne entity.

Špecifický súbor atribútov pre entitu je určený úlohami, v ktorých sa používajú. Napríklad entitu SbA „Objednávanie lístkov v kine“ možno opísať pomocou nasledujúceho súboru atribútov:

Premietanie filmu(Číslo filmu, Číslo filmu, Dátum predstavenia, Číslo nákladov);

Film(Číslo filmu, Názov, Trvanie, Stručný popis);

Divák(číslo diváka, celé meno, dátum narodenia);

Lístok(Číslo diváka, Číslo premietania filmu, Cena vstupenky);

Rezervácia(číslo diváka, číslo premietania filmu, dátum rezervácie);

cena(Číslo nákladov, číslo premietania filmu, náklady).

Graficky je obrázok atribútov entity prezentovaný vo forme popisov, ktoré uvádzajú zoznam názvov atribútov. Napríklad:

Tučná kurzíva a podčiarknutie označujú primárne kľúče – atribút entity, ktorý ju jednoznačne charakterizuje. Podčiarkovníky označujú cudzie kľúče – atribúty, ktoré jedinečne charakterizujú entity, na ktoré odkazujú.

SPOJENIE je vzťah medzi inštanciami dvoch (alebo viacerých) rôznych entít. Mechanizmus prepojenia sa používa na určenie vzťahov medzi entitami v SbA. Okrem toho existujú vzťahy medzi atribútmi samostatnej entity (budú zohľadnené pri konštrukcii logických modelov).

Každý odkaz má názov, ktorý by mal popisovať jeho funkciu. Spojenia majú také charakteristiky, ako je názov spojenia, indikátor mohutnosti, stupeň účasti, stupeň spojenia, životnosť spojenia a iné.

Názov vzťahu by mal mať určitý význam, aby bolo ľahšie pochopiť, ako spolu entity súvisia. Napríklad vzťah medzi entitami Divák a Vstupenka možno definovať ako „Nákupy“.

Na grafické znázornenie vzťahov v diagramoch entít a vzťahov sa používa kosoštvorec. Vo vnútri kosoštvorca je určený názov spojenia a entity zúčastňujúce sa tohto spojenia sú spojené pomocou čiar.

Indikátor kardinality odkazu (charakteristika jedinečnosti) udáva stupeň prepojenia medzi entitami a popisuje počet možných spojení pre každý zo zúčastnených subjektov:

• jedna ku jednej (1:1);
• jedna ku mnohým (1:N);
• many-to-many (N:M).

Vytvorenie databázy začína návrhom.

Etapy návrhu databázy:

· Výskum predmetnej oblasti;

· Analýza údajov (subjekty a ich atribúty);

· Definujte vzťahy medzi entitami a definujte primárne a sekundárne (cudzie) kľúče.

V procese návrhu sa určuje štruktúra relačnej databázy (zloženie tabuliek, ich štruktúra a logické súvislosti). Štruktúra tabuľky je určená zložením stĺpcov, typom údajov a veľkosťou stĺpcov a kľúčmi tabuľky.

TO základné pojmy databázové modely „vzťah entít“. zahŕňajú: entity, prepojenia medzi nimi a ich atribúty (vlastnosti).

Esencia – akýkoľvek konkrétny alebo abstraktný objekt v predmetnej oblasti. Entity sú základné typy informácie, ktoré sú uložené v databáze (v relačnej databáze má každá entita priradenú tabuľku). Medzi entity môžu patriť: študenti, klienti, oddelenia atď. Inštancia entity a typ entity sú rôzne pojmy. Pojem typ entity sa vzťahuje na súbor homogénnych jednotlivcov, predmetov alebo udalostí pôsobiacich ako celok (napríklad študent, klient atď.). Inštancia entity odkazuje napríklad na konkrétnu osobu v množine. Typ entity môže byť študent a inštancia môže byť Petrov, Sidorov atď.

Atribút je majetkom účtovnej jednotky v predmetnej oblasti. Jeho názov musí byť jedinečný pre konkrétny typ entity. Napríklad pre študentskú entitu možno použiť tieto atribúty: priezvisko, meno, priezvisko, dátum a miesto narodenia, údaje o pase atď. V relačnej databáze sú atribúty uložené v poliach tabuľky.

Pripojenie – vzťah medzi subjektmi v predmetnej oblasti. Vzťahy sú spojenia medzi časťami databázy (v relačnej databáze sú to spojenia medzi záznamami tabuľky).

Entity sú údaje, ktoré sú klasifikované podľa typu a vzťahy ukazujú, ako tieto typy údajov navzájom súvisia. Ak opíšeme určitú predmetnú oblasť z hľadiska entity – spojenia, dostaneme modelová entita – vzťah pre túto databázu.

Zoberme si predmetnú oblasť: Dekanát (Študentské úspechy)
Databáza „Dekanát“ by mala uchovávať údaje o študentoch, skupinách študentov, známkach študentov v rôznych odboroch, učiteľoch, štipendiách atď. Obmedzíme sa na údaje o žiakoch, skupinách žiakov a známkach žiakov v rôznych odboroch. Definujme entity, atribúty entít a základné požiadavky na databázové funkcie s obmedzenými údajmi.

Hlavnými vecne významnými subjektmi databázy „dekanátu“ sú: Žiaci, Skupiny žiakov, Disciplíny, Progres.

Základné vecne významné atribúty entít:
-študenti – priezvisko, meno, priezvisko, pohlavie, dátum a miesto narodenia, skupina študentov;
-skupiny študentov – názov, kurz, semester;
-disciplíny – názov, počet hodín
- študijný výkon – hodnotenie, typ kontroly.

Základné požiadavky na funkcie databázy:
-vybrať výkon študenta v disciplínach s uvedením celkový počet hodiny a typ kontroly;
-vyberať výkony žiakov podľa skupín a disciplín;
-vybrať odbory, ktoré študuje skupina študentov v konkrétnom kurze resp
určitý semester.

Z analýzy doménových dát vyplýva, že každej entite musí byť priradená jednoduchá dvojrozmerná tabuľka (vzťahy). Ďalej musíte vytvoriť logické spojenia medzi tabuľkami. Medzi tabuľkami Študenti a Progres je potrebné zaviesť také prepojenie, aby každý záznam z tabuľky Študenti zodpovedal niekoľkým záznamom v tabuľke Progres, t.j. one-to-many, pretože každý študent môže mať viacero známok.

Logický vzťah medzi entitami Skupina – Študenti je definovaný ako jeden – veľa na základe skutočnosti, že v skupine je veľa študentov a každý študent je súčasťou jednej skupiny. Logický vzťah medzi entitami Disciplína – Úspech je definovaný ako jeden – veľa, pretože pre každú disciplínu možno prideliť rôznym študentom niekoľko stupňov.

Na základe vyššie uvedeného vytvárame entitno-vzťahový model pre databázu „Dekanát“.

Šípka je symbol spojenia: jeden - k - mnohým.

Na vytvorenie databázy musíte použiť niektorý zo známych DBMS, napríklad Access DBMS.