Jedna sa o model uchovavania entit a vztahov v tabulkach. Jedna entita je reprezentovana jednym riadkom tabulky. Atribut A entity je reprezentovany stlpcom tabulky. Schema tabulky oznacuje popis struktury tabulky, teda S(A1:T1, ..., An:Tn), kde S je nazov tabulky, A je atribut a T je typ. Schema relacnej databaze je mnozina schemat tabuliek (+ dalsie veci, ako integritne obmedzenia a pod.).
Nad tabulkami mozu existovat IO, ako napriklad
- obmedzenie na unikatnost entit,
- jednoznacnu identifikovatelnost riadkov jednym, alebo viacerimi urcenymi atributmi v ramci tabulky
- takato skupina sa nazyva nadkluc tabulky
- nadkluc s minimalnym poctom atributov sa nazyva kluc tabulky (moze existovat viac klucov, ale jeden nadkluc)
- lepsie povedane
- kluc k schematu R(A) je mnozina atributov z A, ktora jednoznacne urci n-tice relace R
- ak je kluc K klucom schemat A, tak pre kazdu pripustnu relaci R plati, ze ak u, v su dve rozne n-tice z R*, tak u[K] <> v[K]
- cudzi kluc
- skupina atributou z referencnej tabulky
- existuje aj zlozeny cudzi kluc, ked je klucom do referencnej tabulky viac ako 1 atribut
Priklad cudzieho kluca na obrazku. Vsimnite si deklaraciu v notacii relacneho modelu.
IO nam pomahaju zaistit, aby sa do DB dostali len spravne data, alebo teda pripustne n-tice. Uplna definicia relacnej databaze zahrna aj IO. Pripustna relacna DB so schematom (R, I) je mnozina relaci R1 * R2 ... * Rk takych, ze ich n-tice vyhovuju tvrdenim v I.
Tolko neformalny popis a teraz trochu real world :).
"Relace je množina uspořádaných n-tic. Relace obvykle značíme velkými písmeny stejně jako množiny. Často se značí R a S. Mějme dány dvě libovolné množiny A a B. Relace je poté jakákoliv podmnožina kartézského součinu mezi těmito podmnožinami. Pokud si za obě množiny dosadíme přirozená čísla, můžeme získat takovouto relaci: {<1, 2>, <3, 4>, <74, 42>, <1, 0>}, která je podmnožinou kartézského součinu N×N. Pro n-ární relaci bychom předchozí definici akorát lehce poupravili a místo dvou množin bychom měli n množin a místo uspořádaných dvojic uspořádané n-tice."
Ak hovorime o relacnom modele, tak musime hovorit o relaciach, nie o tabulkach. Prirovnanie pekne, ale zavadzajuce. Takze, tabulky su relace, riadky su prvky relace, schema tabulky je schema relace a typy atributov su domeny relace.
Schema relace je
R(A1 : D1, A2 : D2, ... ,An : Dn), kde
- Di = dom(Ai), pre i z <1,n> a predstavuje domenu atributu, teda mnozinu hodnot, ktore moze atribut nadobudat
- Ai predstavuje hodnotu atributu
Matematicky ide o podmnozinu kartezskeho sucinu D1x ... xDn. Relace neobsahuju duplicitne n-tice!
Vyhoda je v tom, ze sa nemusime zaujimat o konkretne pristupove mechanizmy pri manipulaciach s datami. Dotazovaci jazyk, ktory pouzivame sa nazyva relacna algebra a relacny kalkul. Dekompoziciou a syntezou (normalizaciou) je mozne vhodne navrhovat relacne schemy.
Pretoze pri navrhoch relacnych schem (a vlastne vsetkych DB schem) moze dojst k redundancii, tak navrhujeme schemy v normalovych formach (neskor). Redundancie a nenormalizovane schemy prinasaju aktualizacne anomalie. Tie sa vyskytuju pri insert-och, delete-och, update-och. Napriklad musime data vlozit 2x do dvoch roznych entit a pod.
Takze, relacny model:
- relace su v 1NF
- pristup k prvkom relace je podla obsahu
- n-tice su jedinecne (pretoze toto je vlastne taka mnozinologia a budeme pracovat najma s mnozinami)
- abstrakcia je nezavisla na fyzickom ulozeni dat
- silny dotazovaci jazyk
- existuju metody, ktore nam pomozu navrhnut "dobru schemu"
Schemy normalizujeme s vyuzitim funkcnych zavislosti. Normalizacia je proces postupnej transformacie tabulky do vhodnejsieho tvaru, ktory je zalozeny na teorii zavislosti. Proces prebieha postupnou dekompoziciou. Aky je vhodny tvar vieme podla zavedenych normalovych foriem. Ak robime dekompoziciu, tak ta musi
- byt bezstratova pri spatnom spojeni
- zachovavat zavislosti
- odstranovat opakovane informacie
Zavislosti, ktore zachovavame sa nazyvaju funkcne zavislosti. Funkcna zavislost vravi, ze Y funkcne zavisi na X, ak hodnota atributu X jednoznacne urcuje hodnotu atributu Y tej istej relacie, X -> Y. Inak povedane, ku kazdej hodnote X existuje max. 1 hodnota Y. Toto vyplyva z vyznamu atributov a predstavuje IO.
Funkcne zavislosti nam dokonca umoznuju definovat kluc, v scheme R(A, F), kde kluc K je podmnozinou A plati, ze K -> A a neexistuje K' tak, ze K' -> A. To znamena, ze K je jediny kluc.
Majme R(A,F), kde X,Y,Z je podmnozinou A a mnozinu funkcnych zavislosti F.
- ak Y je podmnozinou X, tak potom X -> Y (trivialni FZ)
- ak X -> Y a Y -> Z, tak X -> Z (tranzitivita)
- ak X -> Y a X -> Z, tak X -> YZ (kompozicia)
- ak X -> YZ, tak X -> Y a X -> Z (dekompozicia)
Pravidla uvedene vyssie sa nazyvaju Armstrongove pravidla.Mnozina vsetkych FZ relace R sa znaci R+.
Z tejto tabulky by sme mohli usudit, ze
ZamID -> vsechno (ZamID urcuje cely riadok)
Jmeno -> vsechno
Funkce -> hodinova mzda
Odpracoval hodin -> vsetko
ak zmazeme zaznam c.6, tak uz nebudeme vediet, aku hodnovu mzdu ma lektor.
Z tejto tabulky by sme mohli usudit, zeZamID -> vsechno (ZamID urcuje cely riadok)
Jmeno -> vsechno
Funkce -> hodinova mzda
Odpracoval hodin -> vsetko
ak zmazeme zaznam c.6, tak uz nebudeme vediet, aku hodnovu mzdu ma lektor.
Taketo funkcne zavislosti su jasnym nezmyslom. Preto analyticky definujeme FZ, ktore budu klast IO na dalsie data.
Funkce -> Hodinova Mzda
ZamId -> vsetko
tym ale vznikne aj dalsie IO a to, ze ZamId musi byt unikatne. Zaroven, celkom logicky, by sme si vytvorili tabulku, kde bude platiti Funkce -> Hodinova mzda a Funkce by sa mohla stat cizim klucom v povodnej tabulke.
