RELAČNÝ DATOVÝ MODEL

Relačný dátový model ako bol pôvodne definovaný vychádzal z nasledovných požiadaviek:

• Zabezpečiť vysoký stupeň dátovej nezávislosti.
• Zabezpečiť minimálnu redundanciu dát spolu s konzistenciou dát s podporou sémantiky jazyka.
• Sprístupniť databázu pomocou množinovo orientovaného neprocedurálneho jazyka.
• Umožniť jednoduchým spôsobom reštrukturalizáciu a rast dátového modelu.


Pohľad na dáta je reprezentovaný:
- množinou dvojrozmerných objektov tzv. tabuliek,
- ktoré bývajú podrobené normalizačnému procesu,
- aby bola minimalizovaná redundancia dát
- ktoré umožňujú pomocou príkazov relačnej algebry vytvárať užívateľské pohľady na dáta.
Relačný dátový model je teda v podstate:
• založený na teórii relácií, množinovom pojme relácií a relačnej algebre,
• všetky vzťahy reprezentuje vo forme tabuliek, pretože dvojrozmerné tabuľky stačia na modelovanie reálnych vzťahov,
• kľúčovým pojmom používaným pri relačnom modelovaní je relácia.
Pri pohľade na obr1 môžeme uviesť základné pojmy potrebné k práci s relačným modelom dát, ktoré v ďalšom texte postupne zadefinujeme a podrobne popíšeme.
Sú to:
• entita - zodpovedá tabuľke
• kortéž - zodpovedá riadku tabuľky
• doména - zodpovedá stĺpcu tabuľky
• primárny kľúč - jednoznačný identifikátor v tabuľke, ktorý reprezentovaný stĺpcom alebo skupinu stĺpcov

Relačný pojem Reprezentácia Súborová analógia
entita tabuľka súbor
koréž riadok záznam
doména stĺpec položka
Obr. 4.2 Analógia pojmov




















































6 RELAČNÁ DATABÁZA
ÚVOD
Relačné databázové systémy spolu s relačným systémom riadenia bázy dát sa stali najpoužívanejšími databázovými systémami.







#RC Meno Priezvisko Ulica Obec PSC Nar Okres
801106/3456 Peter Novák Kamenná 27 Banská Bystrica 97401 SR Bans
800312/7845 Stanislav Steinmüller Zelená 9 Nové Mesto nad Váhom 91501 SR Tren
790907/1259 János Tóth Slnečné námestie Komárno 94501 MR Komá
810130/3695 Marek Rátroch Stred 49/7 Považská Bystrica 01701 SR Pova
781201/1248 Bohuslav Biely Juh 2100/456 Trenčín 91101 SR Tren
810514/5341 Branislav Baláž Ťahanovce 38/12 Košice 04000 SR Koši
781015/4431 Peter Kapustný Javorová 2 Žilina 01001 SR Žili
800407/3522 Marek Ďurica Prečín 124 Prečín 01701 SR Pova
791229/5431 Martin Kľúčiar A. Bernoláka 14/20 Žilina 01001 SR Žili
771124/3578 Lukáš Satrapa Dolná 12 Čadca 02201 ČR Čadc
771203/5472 Ján Krnáč Prievoznícka Ružomberok 03401 SR Ružo
790310/2145 Juraj Papún Košická cesta Michalovce 07101 SR Mich



6.1.1 Domény

Doména reprezentuje stĺpec relácie určený v rámci relácie svojim unikátnym názvom množinou prípustných hodnôt.

Je potrebné pochopiť čo je najmenšia jednotka používaná v relačnom modeli. Je ňou konkrétna dátová hodnota, ktorá napríklad reprezentuje meno nejakej osoby, číslo výrobku, hmotnosť výrobky, počet kusov, a pod. Od dátovej hodnoty je požadované, aby bola atomická tzn. ďalej nedeliteľná. C.J. Date [Date95] ju nazval skalárom, čo je termín pomerne zriedkavo sa vyskytujúci v databázovej literatúre, ale veľmi vhodný pre budúce pochopenia relačných databáz.

Skalár je hodnota, ktorá reprezentuje najmenšiu sémantickú jednotku dát. Samotný skalár nemá vnútornú štruktúru, je nedekomponovateľný. Napríklad hodnota priradená názvu predmetu nie je ďalej dekomoponovateľná bez straty významu. Je síce zložená z množiny znakov (písmen), ale samotné nemajú žiadnu informačnú hodnotu. Občas pri definovaní hodnôt patriacich do nejakej množiny priradenej doméne je možné uvažovať o istom význame jednotlivých znakov, ktoré samotné majú alebo môžu mať informačný význam. V tomto prípade je však vhodnejšie dekomponovať príslušný atribút na niekoľko významovo samostatných atribútov.
Pri intervale - v prípade definovania domén pomocou intervalu je možné uvažovať s priradením významu čiastkovým intervalom. (napr. žilinskí študenti majú definované osobné čísla v intervale 1000 - 4999, prievidzskí v intervale 5000 - 9000 a ružomberskí nad 9000).

Množina takýchto hodnôt (rovnakého dátového typu) sa nazýva doména (domain).
Reprezentácia domén:
• Interval
• Množina
Doména môže byť definovaná napr. ako interval (číselných) hodnôt alebo ako množina vymenovaných hodnôt, atď.
Príklad
Pre osobné číslo sú to hodnoty typu integer od 1 povedzme do 10 000, alebo pre atribút farba je to množina prípustných farieb {biela, žltá, zelená, čierna, červená, modrá}.

Typy domén:
• Jednoduchá
• Kompozitná
Jednoduchá doména sa týka jednoduchého atribútu a reprezentuje len hodnoty tvoriace prípustnú množinu hodnôt tohoto atribútu. Doména je množina hodnôt toho istého typu pre daný atribút. Reprezentuje vlastne definičný obor príslušného atribútu.
Kompozitná doména (napr. doména DÁTUM) je definovaná ako kartézsky súčin hodnôt jednoduchých domén atribútov tvoriacich kompozitnú doménu.
Príklad
Typickým príkladom zloženej domény je pre zložený atribút typu dátum, kde doména typu DEN je množina (1...31),
typu MESIAC je množina (1...12) a
typu ROK je množina (OO...99).
Počet prvkov takto definovanej domény je daný súčinom počtu prvkov každej jednoduchej domény, teda 31x12x99, čo dáva množinu o mohutnosti 36828 prvkov reprezentujúcu vyčerpávajúco všetky možnosti kombinácií hodnôt trojice atribútov (DEN, MESIAC, ROK). Avšak čitateľovi je zrejmé, že takto definovaná doména obsahuje aj hodnoty, ktoré sú z istého hľadiska neprípustné. Ako vyriešime tento problém bude popísané v časti venujúcej sa relačnej integrite.

Význam domén
Dôležité je si uvedomiť, že domény majú veľký význam pri relačných operáciách. Napríklad pri operáciach spojenia, porovnania, atď. nemá zmysel pracovať s atribútmi ak nie sú z rovnakej domény. Preto je nutné definovať rovnaké domény pre atribúty v rôznych reláciach, ktoré vyžadujú rovnaké množiny prípustných hodnôt a obzvlášť v prípadoch ak sa nad hodnotami atribútov z rôznych relácií budú vykonávať operácie predpokladajúce príslušnosť do rovnakých domén.
Príklad:
SELECT Student.*,ZPredmet.*
FROM Student,ZPredmet
WHERE Student.OC=ZPredmet.OC

má zmysel, lebo student.OC a predmet.OC patria do rovnakej domény.
Ale
SELECT Student.*,ZPredmet.*
FROM Student, ZPredmet
WHERE Student.OC=ZPredmet.Cis_predmet

asi nemá zmysel hoci Student.OC a ZPredmet.Cis_predmet sú čísla typu integer, ale vyjadrujú rôzne významy hodnôt príslušných atribútov.
Definícia domén
V niektorých DDL (Data definition language - jazyk popisu dát) pre relačné databázové systémy je možné definovať domény ako súčasť popisu schémy dátového modelu, čo umožní definovať istý druh integritných obmedzení vyplývajúcich z definície typu dát. (Analógia s jazykom Pascal pri definícii typov).

Doménu môžeme popísať nasledovným príkazom:

CREATE DOMAIN meno_domény AS dátový_typ;
Kde
meno_domény popisuje meno domény
dátový_typ určuje prípustný dátový typ (Napr. CHAR(n), NUMERIC, DATE, SMALLINT,apod.
Príklad - Defícia relácie bez použitia domén
create table os_udaje
(
rod_cislo char(11) not null,
meno char(15),
priezvisko char(15),
ulica char(20),
obec char(20),
psc char(5),
st_prisl char(2),
okres char(4)
);
Príklad - Defícia doménypre atribút OKRES
create domain DOMENA_OKRES
AS char(4);
Príklad - Defícia relácie s použitím domény
create table os_udaje
(
rod_cislo char(11) not null,
meno char(15),
priezvisko char(15),
ulica char(20),
obec char(20),
psc char(5),
st_prisl char(2),
okres DOMENA_OKRES(4)
);
Príklad - Defícia domény pre atribút OS_CISLOdefinovanej ako interval
create domain DOMENA_OC
AS SMALLINT
CHECK VALUES >1 AND <10000
Príklad - Defícia domény pre atribút OS_CISLO s definíciou množiny
create domain DOMENA_VYSLEDOK
AS SMALLINT
CHECK VALUES IN (1,2,3,NULL)
Príklad - Defícia relácieZAP_PREDMETY s použitím domény pre atribút OS_CISLO definovanej ako interval a pre atribút VYSLEDOK definovanej ako množina
create table zap_predmety
(
os_cislo DOMENA_OC not null,
cis_predmet char(4) not null,
vysledok DOMENA_VYSLEDOK,
datum_sk date,
termin smallint,
zapocet date,
skrok smallint,
body smallint,
prednasajuci char(5)
);
Príklad - Defícia domény pre atribút ROD_CISLO s definíciou tvaru hodnoty
create domain DOMENA_RC
AS CHARACTER(11)
CHECK VALUE (______/____)
Príklad - Defícia domény pre atribút DATUM_SK s definíciou prednastavenej hodnoty
create domain DOMENA_DATUM_SK
AS DATE DEFAULT CURRENT_DATE

Pravidlá použitia domén
Pre správny návrh dátového modelu je potrebné vykonať definíciu domén v dátovom modeli tak, aby boli dodržané tieto pravidlá:

1. Určite množinu D t.j. množinu všetkých domén danej databázy. Táto množina je uzavretou množinou, pričom do nej patria i domény pre hodnoty, ktoré sú výsledkom predpokladaných aritmetických operácií.
2. Určite pre každú doménu Di &#61646;D, unárne operátory, ktoré je možné aplikovať na každý prvok di &#61646; Di,
3. Pre každú dvojicu domén Di &#61646;D , Dj &#61646;D určite, ktoré binárne operátory je možné použiť medzi dvojicami prvkov di&#61646; Di,a dj &#61646; Dj,uvedených domén
4. Určite pre každý výraz používajúci prvky domén doménu všetkých možných výsledkov daného výrazu

Atribút - je menotab_menodomeny, ale v mnohých prípadoch a meno tabulky vynecháva. Je potrebné si uvedomiť, že samotná relácia je určená svojou množinou atribútov, definovaných v rámci relácie unikátnymi menami, ktoré zabezpečia adresovací mechanizmus k prístupu k hodnotám reprezentovaných v samotnej relácii.

Atribút relácie reprezentuje stĺpec relácie určený v rámci relácie svojim unikátnym názvom a množinou prípustných hodnôt.

Samotný atribút bližšie popisuje hodnoty ukladané v tabuľke
&#61662; Príklad
V relácii OS_UDAJE na obr. je definovaná množina nasledovných popisov atribútov:
RC - reprezentuje rodné číslo osoby
Meno - reprezentuje meno
Priezvisko - reprezentuje priezvisko
Ulica - reprezentuje časť adresy
Obec - reprezentuje časť adresy
PSC - reprezentuje časť adresy
Nar - reprezentuje národnosť osoby
Okres - reprezentuje časť adresy
Z pohľadu na vymenované atribúty je zrejmé, že v rôznych reláciach je možné používať rovnaké mená atribútov v rôznych reláciach, ale v rámci jednej relácie musia byť mená atribútov rôzne.
6.1.2 Relácia
Relačný model dát má len jediný konštrukt a tým je databázová relácia. Od matematickej relácie sa líši tým, že je :
• Obsahuje schému relácie,
• Prvky domén, z ktorých sa berú hodnoty atribútov sú atomické hodnoty.

6.1.2.1 Pojmy

Relačná schéma
Relačná schéma relácie R je &#61527;={ A1 :D1, A2:D2, ..., An:Dn}, a to konečná množina dvojíc atribút – doména
Relácia
Nech existuje množina domén D={ D1,D2, ...,Dn} nad množinou &#61527; , potom reláciou je podmnožina karteziánskeho súčinu domén D1xD2x ...xDn.
Relácia R nad množinou domén D1, D2, ..., Dn (nie nevyhnutne odlišnými) sa skladá z hlavičky a tela :
Hlavička – stála (nemenná) množina atribútov A1, A2, ..., An, takých, že každému atribútu Ai zodpovedá práve jedna z domén Di kde i=1, 2, ..., n ( Ai:Di )
Telo – v čase sa meniaca množina n-tíc, kde každú n-ticu tvorí množina dvojíc
(Ai: vij), kde i=1, 2, ..., n a j=1, 2, ..., m
tzn. existuje jedna dvojica atribút – hodnota (Ai: vij) pre každý atribút Ai z hlavičky.
Pre ktorúkoľvek danú dvojicu atribút – hodnota (Ai: vij) platí, že vij je jednou z hodnôt danej domény Di prislúchajúcej atribútu Ai.

Označovanie schém relácií:
Schéma relácie sa často označuje aj R={ A1, A2, ..., An}, R(&#61527;) alebo aj &#61527; ak nám nezáleží na mene relácie.
Označovanie domén:
Doména týkajúca sa atribútu A sa často označuje ako dom(A).
Ak existuje schema relácie &#61527;={A,B }, tak dom(&#61527;)=dom(A)xdom(B).

Kardinalita relácie
Kardinalita relácia vyjadruje počet kortéžov relácie.
Stupeň relácie
Ak existuje relačná schéma relácie R={ A1 , A2, ..., An:}, tak počet atribútov n udáva stupeň relácie.

6.1.2.2 Definície

1. UNION
Definícia
Operácia UNION (Zjednotenie) vytvorí z relácie R1(A1, A2, …, An) a z relácie R2(A1, A2, …, An), tretiu reláciu R3(A1, A2, …, An) takú, že pre každú n-ticu t platí:
t * R3 ak t * R1 alebo t * R2.
2. DIFFERENCE
Definícia
Operácia DIFFERENCE (Rozdiel) vytvorí z relácie R1(A1,A2, …, An) a z relácie R2(A1, A2, …, An), tretiu reláciu R3(A1, A2, …, An) takú, že pre každú n-ticu t platí:
t * R3 ak t * R1 a t * R2.
3. INTERSECTION
Definícia
Operácia INTERSECTION (Prienik) vytvorí z relácie R1(A1, A2, …, An) a z relácie R2(A1, A2, …, An), tretiu reláciu R3(A1, A2, …, An) takú, že pre každú n-ticu t platí:
t * R3 ak t * R1 a súčasne t * R2.
4. PRODUCT
Definícia
Operácia PRODUCT (Karteziánsky súčin) vytvorí z relácie R1(A1,A2, …, An) a z relácie R2(B1,B2, …, Bm), tretiu reláciu R3( A1, A2, …, Aa , B1, B2, …, Bm) takú, že obsahuje všetky kombinácie n-tíc, kde pre každú n-ticu t platí:
t * R3 a t je usporiadanou dvojicou t= t1 , t2 ak t1 * R1 a t2 * R2.

5. PROJECTION
Definícia
Operácia PROJECTION (Projekcia) vytvorí z relácie R1(A1,A2, …, An) reláciu R2(B1,B2, …, Bm), takú, že množina atribútov (B1,B2, …, Bm) * (A1,A2, …, An) a pre stupeň relácie R2 platí m < n a card(R2) = card(R1 ).
6. SELECTION
Definícia
Elementárnou podmienkou EC nazývame výraz v tvare:
<Atribút> <Operátor> <Hodnota>
kde
operátor je z množiny relačných operátorov {=, <, >, <-, >=, *}.

Definícia
Podmienkou C nazývame výraz v tvare:
[NOT] EC1 [{OR | AND |NOT} [[NOT] EC2 ]…]

Definícia
Operácia SELECTION (Výber) vytvorí z relácie R1(A1,A2, …, An) reláciu R2(A1,A2, …, An), takú, že pre každú n-ticu t * R2 platí t * R1 , a je splnená podmienka C .

7. JOIN
Definícia
Operácia JOIN (Spojenie) vytvorí z relácie R1(X, A1,A2, …, An) a z relácie R2(X,B1,B2, …,Bm), ktoré majú spoločnú množinu atribútov X, tretiu reláciu R3(X,A1,A2,…,Aa,B1,B2,…,Bm) takú, že ak t1 * R1 a ak t2 * R2
a pre hodnoty atribútov X platí t1.X=t2.X
potom n-tica t * R3 má atribúty t= t1..X , t1..A1 , t1..A2 , …, t1..Aa , t2..X , t2..B1, t2..B2, …, t2..Bm.

8. DIVISION
Definícia
Operácia DIVISION (Delenie) vytvorí z relácie D(A1,A2, …, Ap ,Ap+1,Ap+2,…,An) delením reláciou d(Ap+1,Ap+2,…,An), tretiu reláciu Q(A1,A2, …, Ap) takú, že konkatenáciou tQ * Q a td * d dostaneme n-ticu tD * D. (tQ , td = tD)

Veta
D*d = R1 – R2
R1 = * A1,A2, …, Ap(D)
R2 = * A1,A2, …, Ap((R1 * d) - D)

9. NATURAL JOIN
Definícia
Operácia NATURAL JOIN (Prirodzené spojenie) vytvorí z relácie R1(X,A1,A2,…,An) a z relácie R2(X,B1,B2, …,Bm), ktoré majú spoločnú množinu atribútov X, tretiu reláciu R3(X,A1,A2,…,Aa,B1,B2,…,Bm) takú, že ak t1 * R1 a ak t2 * R2
a pre hodnoty atribútov X platí t1.X=t2.X
potom n-tica t * R3 má atribúty t= t1..X , t1..A1 , t1..A2 , …, t1..Aa , t2..B1, t2..B2, …, t2..Bm. pričom atribúty s rovnakými menami sa neopakujú.

9. THETA JOIN
Definícia
Operácia THETA JOIN (* - spojenie) vytvorí z relácie R1(X,A1,A2,…,An) a z relácie R2(X,B1,B2, …,Bm), ktoré majú spoločnú množinu atribútov X, tretiu reláciu R3(X,A1,A2,…,Aa,B1,B2,…,Bm) takú, že ak t1 * R1 a ak t2 * R2
a pre hodnoty atribútov X platí t1.X * t2.X
potom n-tica t * R3 má atribúty t= t1..X , t1..A1 , t1..A2 , …, t1..Aa , t2..B1, t2..B2, …, t2..Bm pričom operátor * nadobúda hodnotu z množiny relačných operátorov {=,<,>,<=,>=,*}.
10. EQUI JOIN
Definícia
Operácia EQUI JOIN je takou operáciou *-spojenia, kde operátor * nadobúda hodnotu relačného operátora =.
11. INE QUI JOIN
Definícia
Operácia INEQUI JOIN je takou operáciou *-spojenia, kde operátor * nadobúda hodnotu z množiny relačných operátorov {<,>,<=,>=,*}.
12. EXTERNAL JOIN
Definícia
Operácia EXTERNAL JOIN (Vonkajšie spojenie) vytvorí z relácie R1(X,A1,A2,…,An) a z relácie R2(X,B1,B2, …,Bm), ktoré majú spoločnú množinu
atribútov X, tretiu reláciu R3(X,A1,A2,…,Aa,B1,B2,…,Bm) takú, že ak t1 * R1 a ak t2 * R2
a ak pre hodnoty atribútov X platí t1.X=t2.X
potom n-tica t * R3 má atribúty t= t1..X , t1..A1 , t1..A2 , …, t1..Aa , t2..B1, t2..B2, …, t2..Bm.
a ak pre hodnoty atribútov X platí t1.X*t2.X
potom n-tica t * R3 nadobúda NULL hodnoty pre chýbajúce atribúty n-tice t.
13. SEMI JOIN
Definícia
Operácia SEMI JOIN (Polospojenie) vytvorí z relácie R1(X,A1,A2,…,An) a z
relácie R2(X,B1,B2, …,Bm ), tretiu reláciu R3(X,A1,A2,…,Aa) takú, že t1 * R1 a t2 * R2
ak pre n-ticu t1 * R1 existuje spojenie aspoň s jednou n-ticou t2 *R2.

14. COMPLEMENT
Definícia
Operácia COMPLEMENT (Doplnok) vytvorí z relácie R1(A1,A2,…,An) reláciu R2(A1,A2,…,Aa) takú, že t2 * R2 obsahuje všetky n-tice, ktoré patria do Karteziánskeho súčinu hodnôt domén atribútov relácie R1 a t2 * R1.


6.1.2.3 Vlastnosti relácie

Relácia má štyri základné vlastnosti :
1. Neobsahuje duplicitné kortéži - táto vlastnosť vychádza s faktu, že telo relácie je matematická množina (množina n-tíc), a podľa definície neobsahuje duplicitné prvky. Základným predpokladom pre splnenie tohto bodu je nutná existencia primárneho kľúča v každej relácii (pozri definíciu primárneho kľúča). Primárny kľúč môže byť tvorený jedným atribútom alebo zložením niekoľkých atribútov relácie.
2. kortéži sú neusporiadané (zhora dolu) – n-tice tvoria matematickú množinu (nie je usporiadaná) hoci z praktického hľadiska je často vhodné udržiavať reláciu ako usporiadanú množinu. Z druhej strany neusporiadanosť umožňuje zjednodušiť a zjednodušiť algoritmy pre prácu nad reláciou.
3. m-tice atribútov sú neusporiadané (zľava doprava) – m-tice tvoria matematickú množinu (nie je usporiadaná). Táto vlastnosť hovorí o tom, že k jednotlivým stĺpcom alebo k hodnotám atribútu pristupuje prostredníctvom identifikátoru (meno atribútu) a nie podľa pozície v riadku. To umožní tvorbu programov nezávislých na dátach.
4. hodnoty atribútov sú atomické – túto vlastnosť môžeme vyjadriť aj inak (menej formálne): každému atribútu je priradená vždy len jedna hodnota a nie množina hodnôt. Je potrebné, aby všetky atribúty boli atomické, čím dosiahneme to, že v relácii sa nemôžu vyskytovať tzv. opakujúce sa skupiny atribútov, ktoré sa vyskytujú v nenormalizovaných záznamoch. Hodnota atribútu je vždy skalár a nie množina. "Relácia neobsahuje opakujúce sa skupiny". Relácii bez opakujúcich sa skupín hovoríme, že je normalizovaná.

Relačná schéma databázy
Relačná schéma databázy je potom definovaná dvojicou (R,I), kde R je množina schém relácií a I je množina integritných obmedzení IO.
Podrobnejšie by to bolo možné vyjadriť i v tvare
R=((R1 ,IO1), (R2,IO2), ..., (Rn,IOn))
ak chceme zdôrazniť, že pre každú reláciu Ri v databáze R existuje vlastná množina integritných obmedzení.

Prípustná relačná schéma databázy
Prípustnou relačnou databázou so schémou (R,I) nazývame množinu relácií R1, R2, ..., Rn takých, že ich prvky (n-tice) vyhovujú I.
Tento fakt je možné vyjadriť aj výrokom, že daná množina relácií je konzistentná.


Relačná databáza ***
Relačná databáza je množina v čase sa meniacich, normalizovaných relácií. Jedným z významných integritných obmedzení relácie R je existencia primárneho kľúča.
Klasifikácia relácií
Podľa pôvodu
základné
odvodené
pohľad
snímka
Podľa spôsobu uloženia
Perzistentné
základné
snímky
dočasné
medzivýsledky
pohľady
Podľa mena
pomenované
základné
pohľady
snímky
nepomenované
dotaz
dočasné (medzivýsledok)

Primárny kľúč (PK) je množina domén (atribútov) K=(A1, A2, ..., Aj) relácie R, vybraná z ďalších takýchto potencionálnych množín, ktorých hodnoty jednoznačne určujú n-tice relácie R. K je minimálna v tom zmysle, že z nej nie je možné odobrať žiadny atribút, pretože by to narušilo identifikačnú vlastnosť.
PK vlastne slúži na odlíšenie kortéží . Atribúty, ktoré sú súčasťou nejakého PK sa nazývajú kľúčové, ostatné atribúty nazývame nekľúčové.
Každá entita (schéma relácie) musí mať definovaný primárny kľúč. Entity, ktoré majú málo atribútov a nie sú schopné vytvoriť primárny kľúč sa nazývajú slabé entity (podriadená entita je obvykle slabou entitou a potom sa primárny kľúč slabej entity definuje ako primárny kľúč silnej entity + diskriminant, ktorý umožní rozlíšiť slabé entity). Entity, ktoré majú dostatok atribútov sa nazývajú silné entity

Druhým dôležitým IO v súčasnosti podporované v DDL v mnohých relačných SRBD, je referenčná integrita. Toto IO popisuje vzťah medzi dátami obsiahnutými v dvoch reláciách. Atribút, ktorého sa referenčná integrita týka sa nazýva cudzí kľúč (foreign key, FK). Ide o atribút (alebo skupinu atribútov), ktorého hodnota v relácii je buď prázdna alebo musí obsahovať hodnotu primárneho kľúča inej relácie. Takto spojené relácie sa obvykle nazývajú hlavná a závislá (ang. master, detail alebo parent, child). Primárny kľúč sa týka hlavnej, cudzí kľúč závislej relácie.
Referenčná integrita je podporovaná niektorými implementáciami SQL, je súčasťou štandardu SQL2. Súvisí to priamo so sémantikou konceptuálnych modelov a transformáciami konceptuálnych schém do databázových.

6.2 Integrita
6.2.1 Relačná integrita
Pojem integrity je v oblasti databáz chápaný vo význame správnosti a zabezpečenia konzistencie dát a taktiež veľmi často je spájaná i s utajením dát. Samotný problém integrity je teda spojený so zabezpečením správnosti dát pri akýchkoľvek zmenách v databáze. Chyby alebo následná nekonzistencia dát môže vzniknúť vstupom dát, chybami obsluhy, chybami programov alebo aj úmyselným poškodením databáze.
Pojem konzistencia dát úzko súvisí s pojmom integrity a dosť často sú považované za synonymá. Je to hlavne v situáciách, ak dochádza súčasne k zmenám vo viacerých databázových objektoch alebo keď v multiužívateľskom systéme, viacerí užívatelia paralelne manipulujú nad rovnakou množinou dát, čo by v konečnom dôsledku mohlo viesť k nesprávnym výsledkom. Preto nástrojom zabezpečenia integrity je transakčný systém, ktorý garantuje prechod databáze z jedného konzistentného stavu do iného konzistentného stavu pri operáciách, ktoré manipulujú s obsahom databázy. V relačných systémoch môže dojsť k situáciám, pri ktorých by došlo k porušeniu konzistencie databázy počas udalostí, ktoré je možné analyzovať na základe znalosti relačného dátového modelu aplikácie.
Relačná integrita je časťou relačného modelu je v súčasnej dobe jednou z najprepracovávanejších oblastí relačných databázových systémov. Je veľmi dôležité, aby :
• Hodnoty uložené v DB reprezentovali realitu modelovanú v danom systéme,
• Hodnoty dát uložené v DB boli správne a mali zmysel.
Z toho vyplýva nutnosť definovať integritné pravidlá, ktoré umožnia zladiť prevádzku DBS s obmedzeniami kladenými reálnym systémom.
Integrita ( celistvosť) – pohotová fyzická disponibilita bázy dát, pričom báza dát je v konzistentnom stave.
Úlohou systému riadenia bázy dát (SRBD) je chrániť integritu bázy dát, ktorá môže byť narušená viacerými spôsobmi:
A) zlyhanie technického zariadenia
B) zlyhanie základného programového vybavenia
C) chybou v aplikačnom programe
D) chybným zásahom obsluhy počítača
E) chybnými údajmi
prípadne kombinácia
Na ochranu integrity bázy dát používajú SRBD rôzne techniky, ktoré možno rozdeliť na:
1) Techniky a metódy na ochranu bežných súborov dát organizovaných prostredníctvom operačného systému.
2) Techniky a metódy vyvinuté špeciálne pre potreby DS

6.2.1.1 Konvenčné metódy ochrany súborov
sú určené na ochranu bežných súborov a sú podporované operačným systémom alebo zvláštnymi programami programového vybavenia.
1) Viacnásobné kópie súboru
- metóda je používaná na ochranu pred poruchami technického vybavenia predovšetkým pamäťových zariadení.
- príslušný súbor existuje vo viacerých kópiách, ktoré by mali byť na rôznych pamäťových médiách alebo ak je to z hľadiska organizácie súboru možné, na rôznych typoch pamäťových zariadení
- využitie – ochrana súborov, ktoré majú kľúčový význam pre prácu systému.
2) Kopírovanie súborov
- najbežnejšia technika ochrany údajov. Spočíva vo vytvorení kópie pre príslušný súbor. Pri zistení poruchy sa vykoná spätný proces: zo záložnej kópie sa objaví pôvodný obsah súboru.
- ak sa pre niektorý aplikačný systém vytvoria v určitom čase kópie všetkých súborov, hovoríme o kontrolnom bode. Pri poruche je potom možné obnoviť všetky súbory na stav v čase vytvorenia kontrolného bodu, a tým zabezpečiť aby v agende boli obnovené všetky prípadné väzby medzi súbormi.
3) Viaceré verzie
- v prípade zmeny údajov sa vytvorí nová verzia súboru, tak že sa na ňu predpíšu všetky pôvodné údaje a namiesto zmenených sa zapíšu nové.
- obyčajne sa nechávajú v archíve 2 a viac generácií súboru.
4) Inkrementálne kopírovanie
- technika spočíva v tom, že po vykonaní kontrolného bodu (úplnej kópie celého súboru alebo viac súborov) sa označkovávajú (poznamenávajú) tie body súboru, v ktorom došlo k zmene. Tie bloky sú potom v kratších intervaloch, než je interval medzi 2 kontrolnými bodmi kopírované na záložné médium, pričom sa rušia značky zmenených blokov.
5) Zaznamenanie zmien
- zmeny vykonané v súbore za predbežne zaznamenajú do súboru zmien. Zaznamenáva sa hodnota príslušnej časti súboru pred zmenou a po jej vykonaní. Súčastne sa zaznamenávajú i ďalšie údaje napr. časové, názov programu atď.
- súbor do ktorého sa zaznamenávajú zmeny = žurnálový súbor.

6.2.1.2 Klasifikácia integritných obmedzení
Základom je množina integritných obmedzení, ktoré reprezentujú tvrdenia o dátach, ktoré musia v databáze platiť. Vychádzajú samozrejme z konceptuálneho modelu, kde je obecne modelovaný informačný systém, pre ktorý sa dátový model pripravuje.
Samotná relačná integrita je potom reprezentovaná nasledovnou klasifikáciou integritných obmedzení:
1. Doménová integrita D-Integrita
2. Integrita stĺpcov C-integrita atribútov
3. Integrita entít E-integrita
4. Referenčná integrita R-integrita
5. Užívateľská integrita U-integrita

Problematika relačnej integrity je jednou z častí RDBS, ktorá sa rozvíjala v posledných rokoch veľmi dynamicky a v každom relačnom databázovom systéme je nutné zabezpečiť, aby podporoval aspoň:
Integritu entít,
ktorá je založená na pojme primárneho kľúča.
Referenčnú integritu,
ktorá je založená na pojme cudzieho (spojovacieho) a primárneho kľúča.

Referenčná integrita je podporovaná niektorými implementáciami SQL, je súčasťou štandardu SQL2. Súvisí to priamo zo sémantikou konceptuálnych modelov a transformáciami konceptuálnych schém do databázových.

6.2.1.3 Spracovanie IO v SRBD
Pretože je nutné správne spracovať IO tak v relačných systémoch sú definované Coddom [Codd90] dve fázy kontroly spracovania IO:
• stĺpcová (TC)
• transakčná (viac tabuľková) (TT).
V stĺpcovej fáze je kontrola integrity vykonávaná SRBD nikdy nie neskôr ako na konci spracovania akejkoľvek požiadavky relačného typu. Zvyčajne je požiadavka súčasťou aplikačného programu alebo interaktívne zadaná užívateľom.
Pri viac tabuľkovom spracovaní sa kontrola IO vykonáva SRBD na konci vykonania transakcie, ktorej súčasťou je daná požiadavka.
Informácie o všetkých typoch IO musia byť súčasťou katalógov, v ktorých SRBD vyhľadáva. Spracovanie SRBD obsahuje nasledovný algoritmus:
1. Na začiatku spracovanie požiadavky SRBD zistí, ktoré IO a akého typu sa viažu na danú požiadavku.
2. SRBD pre danú požiadavku určí stĺpcové IO, t.j. také, ktoré sa týkajú len jednej tabuľky.
3. Pred ukončením spracovania požiadavky SRBD zistí, či uvedená požiadavka vyhovuje definovaným stĺpcovým IO.
4. SRBD spracuje IO, ktoré sa týka viacerých tabuliek.
5. SRBD skontroluje ešte pre potvrdením zmien či požiadavka vyhovuje IO.

Primárny kľúč

Kandidát PK (KPK)
Je taká množina atribútov, ktorá spĺňa podmienku:
• Unikátnosti –
Neexistuje v relácii dve a viac n-tíc, ktoré majú rovnaké hodnoty atribútov atribútov tvoriacich KPK.
• Minimálnosti (Neredukovatelnosť) -
Žiadna podmnožina atribútov KPK nespĺňa podmienku unikátnosti.
Primárny kľúč (PK)
Je práve jedna množina atribútov patriaca jednému z kandidátov primárneho kľúča, ktorá spĺňa podmienky:
• Unikátnosti
• Minimálnosti (Neredukovatelnosť)

Alternatívny kľúč (AK)
Je taká množina atribútov, ktorá tvorí kandidáta primárneho kľúča, ale nie je primárnym kľúčom.

Primárny kľúč (PK) môžeme chápať i ako množinu atribútov K=(A1, A2, ..., Aj) relácie R, vybranú z ďalších takýchto potencionálnych množín, ktorých hodnoty jednoznačne určujú n-tice relácie R. K je minimálna v tom zmysle, že z nej nie je možné odobrať žiadny atribút, pretože by to narušilo identifikačnú vlastnosť.
PK vlastne slúži na odlíšenie entít. Atribúty, ktoré sú súčasťou nejakého PK sa nazývajú kľúčové, ostatné atribúty nazývame nekľúčové.
Každá schéma relácie musí mať definovaný primárny kľúč. Entity, ktoré majú málo atribútov a nie sú schopné vytvoriť primárny kľúč sa nazývajú slabé entity (podriadená entita je obvykle slabou entitou a potom sa primárny kľúč slabej entity definuje ako primárny kľúč silnej entity + diskriminant, ktorý umožní rozlíšiť slabé entity). Entity, ktoré majú dostatok atribútov sa nazývajú silné entity. Tento problém je však nutné riešiť pri tvorbe konceptuálneho modelu. (viď kapitolu 3) .

Cudzí kľúč (Foreign key)

Cudzí kľúč FK je množina atribútov z relácie R taká, že existuje relácia R´ s kandidátom primárneho kľúča KPK, ktorého množina atribútov je identická s atribútmi tvoriacimi FK.

Cudzí kľúč (foreign key, FK) je atribút, ktorého hodnota v relácii je buď prázdna alebo musí obsahovať hodnotu primárneho kľúča inej relácie. Spojené relácie sa obvykle nazývajú hlavná a závislá (ang. master/detail alebo parent/child). Primárny kľúč sa týka hlavnej, cudzí kľúč závislej relácie.
Pre celý čas je nutné, aby hodnota FK v relácii R mala identickú hodnotu s hodnotou KPK v relácii R´.

Pre cudzí kľúč platí :
• FK môže byť množinou atribútov.
• Každá hodnota FK, ktorá sa objaví v relácii sa musí vyskytovať ako hodnota PK v inej relácii (Opačne to neplatí).
• FK je kompozitný len ak PK je kompozitný.
• Každý z atribútov tvoriaci FK musí mať definovanú rovnakú doménu ako príslušný atribút KPK.
• Nie je nutné, aby FK bol KPK alebo jeho súčasťou. Vo všeobecnosti každý atribút relácie alebo množina atribútov relácie môžu byť definované ako FK.
• FK je odkazom na na riadok relácie, kde hodnota KPK je totožná s hodnotou FK.
• Referenčný diagram ST<-ZP->P
• Referenčná cesta Rn->R(n-1)->..->R2->R1
• Relácie R1 s KPK a relácia R2 s FK môžu byť totožné.
• V relácii sa môže vyskytnúť referenčný cyklus. Napr.: Rn->R(n-1)->..->R2->R1->R n
• FK vyjadrením vzťahu medzi dvojicou n-tíc a reprezentuje spojivo medzi reláciami.

6.2.2 Doménová integrita
Doménová integrita reprezentuje množinu integritných obmedzení, ktoré zdieľajú všetky hodnoty atribútov priradených k tejto doméne.
Druhy doménovej integrity:
• Typ dát
• Množinu prípustných hodnôt
• Usporiadatelnosť – t.j. či je možné pre porovnanie hodnôt domény použiť relačný operátor >, >=, =< alebo <.

Použitie s podporou SQL92

CREATE DOMAIN DOM_OC
AS SMALLINT,
CHECK DOM_OC>1 AND DOM_OC<3000,
ORDERABILITY

CREATE DOMAIN DOM_ROK
AS DATE
DEFAULT 10.1.1999
CHECK VALUE >= 1.1.1999 AND VALUE <= 31.12.1999

CREATE DOMAIN STAV
AS CHAR(1)
DEFAULT “S”
CHECK VALUE IN (”S”,”K”, ”P”, ”E”)

CREATE DOMAIN STAV
AS CHAR(1)
DEFAULT “S”
CHECK VALUE IN (SELECT znak FROM CIS_STAVY)

Použitie pri definícii tabuľky:
CREATE TABLE T(
OC DOM_OC,
DATUM DOM_ROK,
PLAT SMALLINT,
....
)
Vo väčšine RDBS je podpora doménovej integrity slabá alebo žiadna. Napriek tomu je možné tento problém riešiť. Najvhodnejším spôsobom môže byť vytvorenie špecializovaných relácií reprezentujúcich doménu (číselníky) a pri operáciách INSERT a UPDATE kontrolovať správnosť použitých hodnôt.

Príklad: Použitie definície domény ako tabuľky:
CREATE TABLE CISELNIK_STAVY(
STAV CHAR(1) NOT NULL UNIQUE
)
Príklad: Použitie v oprácii UPDATE
BEGIN WORK
SELECT COUNT(*) pocet FROM CISELNIK_STAVY
WHERE prem_stav = STAV
IF pocet =