Relační model reprezentuje databázi jako soubor relací. Kaţdá relace představuje tabulku nebo soubor (ve smyslu soubor na nosiči dat).

Transkript

1 3. Relační model Relační model reprezentuje databázi jako soubor relací. Kaţdá relace představuje tabulku nebo soubor (ve smyslu soubor na nosiči dat). Příklad 3.1: Filmová databáze relace: FILM REŢISÉR ŢÁNR SPOLEČNOST HEREC ROLE Terminologie v relačním modelu relační model relační schéma relace (tabulka) řádek sloupec doména superklíč klíč primární klíč kandidátní klíč cizí klíč n-tice (n-tuple, tuple) atribut Relační schéma R označené jako R(A 1, A 2,...., A n ) je tvořeno jménem relace a seznamem atributů. Kaţdý atribut A i zastupuje určitou doménu D, kterou značíme dom(a i ). Počet atributů n určuje tzv. stupeň relace. Nezáleţí na pořadí atributů ani řádků. Příklad 3.2: ŢÁNR(id_ţánr, název) stupeň 2 REŢISÉR(id_reţisér, příjmení, jméno, stát) stupeň 4 FILM(id_film, název, reţisér, společnost, rok, délka, přístupno, ţánr) stupeň 8

2 Datový typ určující typy hodnot, kterých můţe atribut nabývat (které se tedy mohou objevit v konkrétním sloupci tabulky), se nazývá doména. Doména - mnoţina atomických hodnot (hodnot, které se dále nedělí, přesněji řečeno pro potřeby daného relačního modulu se tyto hodnoty uţ dále nedělí) Doména je tedy dána svým jménem, datovým typem a formátem, eventuelně můţe být doplněna o dodatečné informace ohledně např. měřící jednotky. Relace r (instance relace - tj. konkrétní výskyt relace) z relačního schématu R(A 1, A 2,..., A n ) se značí také jako r(r) a je to mnoţina n-tic r = { t 1, t 2,...., t m }. Kaţdá n-tice je uspořádaný seznam n hodnot t = < v 1, v 2,.... v n >, kde kaţdé v i, 1 i n, je prvkem domény dom(a i ) nebo je specielní hodnota null. Relace r(r) je podmnoţina kartézského součinu domén, které definují R r(r) ( dom(a 1 ) x dom(a 2 ) x.... x dom(a n ) ) Kartézský součin určuje všechny moţné kombinace hodnot z uvedených domén. Pokud označíme kardinalitu domény D jako D a předpokládáme, ţe všechny domény jsou konečné, potom celkový počet n-tic v kartézském produktu je dom(a 1 ) * dom(a 2 ) *.... * dom(a n ) Použitá notace relační schéma R stupně n R(A1, A2,..., An) n-tice t v relaci r(r) t = < v1, v2,.... vn >, kde vi je hodnota odpovídající atributu Ai hodnota atributu Ai vi =t[ai] relační jména R, S, Q,... relační stavy r, s, q,... n-tice t, u, v kvalifikovaná jména atributů STUDENT.Jméno, STUDENT.Příjmení,... aktuální relační stav STUDENT relační schéma STUDENT(Jméno, Příjmení,... ) Příklad 3.3: n-tice t=< Jana Bláhová, /1234, Kaplice,null, 21, 3, 12> viz relace STUDENT (Jméno, Rod. číslo, Adresa, Telefon, Věk, Ročník, Obor) t Jméno = Jana Bláhová, t Ročník = 3

3 DB tabulka - vlastnosti má jednoznačné jméno charakterizuje jedinou entitu kaţdý sloupec (atribut) v tabulce má jednoznačné jméno všechny hodnoty daného sloupce jsou stejného typu nezáleţí na pořadí sloupců nezáleţí na pořadí řádků neobsahuje! duplicitní řádky všechny hodnoty jsou atomické má primární klíč Operace s tabulkami mnoţinové operace selekce podmnoţina řádků projekce podmnoţiny sloupců operace spojení kombinace více vyuţití operací výrokové logiky Omezení podmínky relačního modelu Podmínky pro domény hodnota kaţdého atributu musí být atomická hodnota a musí být prvkem mnoţiny dom(a). Datové typy pro doménu zahrnují standardní číselné datové typy (celočíselné short integer, integer, long integer, reálné typy jako float, double), dále řetězcové typy (řetězce pevné i proměnné délky), měnové, datumové, časové typy. Ostatní datové typy domén se definují jako podintervaly nebo výčtové typy výše uvedených typů. Klíčová omezení relace je dána jako mnoţina n-tic (záznamů, vět). Dle definice mnoţiny jsou všechny její prvky různé tj. i pro všechny záznamy v relaci musí platit, ţe jsou navzájem různé neboli ţe neexistují dvě n-tice, které mají tutéţ kombinaci hodnot atributů. Obvykle existují různé podmnoţiny atributů SK, které mají tu vlastnost, ţe ţádné dva záznamy nemají stejnou kombinaci hodnot atributů tj. pro libovolné dvě n-tice t 1 a t 2 v relaci r (relační schéma R) platí, ţe t 1 SK t 2 SK. Kaţdá takováto podmnoţina atributů je označována jako superklíč relačního schématu R. Kaţdá relace má nejméně 1 superklíč - mnoţinu všech atributů. Superklíč můţe obsahovat redundantní atributy, nicméně rozumná koncepce klíče je pochopitelně klíč bez nadbytečných atributů. Jako klíč K relačního schématu R tedy označíme superklíč schématu R, který má tu vlastnost, ţe odebereme-li libovolný atribut A z klíče K, zbyde mnoţina atributů K, která není superklíč. Tj. klíč je minimální superklíč - nemůţeme odebrat jediný atribut k zachování jednoznačnosti.

4 Příklad 3.4: Relace STUDENT (Stud_číslo, Rodné číslo, Jméno, Adresa, Ročník, Obor) Stud_číslo, Příjmení, Jméno, Ročník je superklíč, ne klíč Stud_číslo, Příjmení, Jméno je superklíč Stud_číslo, Příjmení je superklíč {Stud_číslo } je klíč Příjmení, Jméno, Ročník není superklíč, tedy ani klíč Rodné číslo je klíč Klíč musí obsahovat jedinečné hodnoty v rámci celé tabulky nesmí obsahovat NULL nesmí to být vícesloţkové pole jeho hodnota nesmí způsobit narušení bezpečnosti a únik informací jeho hodnota není ani částečně, ani jako celek volitelná skládá se z nejmenšího moţného počtu polí jeho hodnota musí jednoznačně identifikovat hodnoty všech polí daného záznamu klíč je časový invariant (jeho hodnota se mění zcela výjimečně) Relační schéma můţe mít víc klíčů, který z nich bude označen jako primární je v podstatě libovolné, ostatní klíče se pak označují jako kandidátní. Relační databázové schéma a integritní omezení Relační databázové schéma S je mnoţina všech relačních schémat S = R 1, R 2,..., R m a mnoţina integritních podmínek ( omezení ) IO. Instance relační databáze DB ze schématu S je mnoţina relačních instancí DB = r 1, r 2,.., r m, kde r i je instance R i a splňuje podmínky integritních omezení. Integrita dat Stanovení jistých pravidel na úrovni tabulek na úrovni polí na úrovni vztahů RI na úrovni business pravidel na úrovni pohledů

5 Integrita na úrovni tabulek tabulka obsahuje jedinečné záznamy tabulka neobsahuje duplicitní pole vypočítaná pole vícehodnotová pole vícesloţková pole duplicitní záznamy tabulka má primární klíč Integrita na úrovni polí Doménová integrita hodnoty kaţdého pole jsou platné, přesné hodnoty stejného typu jsou definovány stejně Referenční integrita Podmínky specifikované pro vztah dvou relací - uţívá se pro zachování konzistence mezi záznamy dvou relací. Záznam relace R 1, která je spojena s jinou relací R 2, se musí odkazovat na existující (odpovídající) záznam v R 2 Příklad 3.5: ŢÁK (Číslo, Jméno, Adresa, Třída ) TŘÍDA(Id třídy, Umístění, Třídní) Pojem cizí klíč se zavádí v souvislosti se vztahem dvou relací R 1 a R 2. Mnoţina atributů FK z relačního schématu R 1 je cizím klíčem R 1, pokud splňuje následující dvě pravidla : 1. Atributy zahrnuté v FK mají tutéţ doménu jako primární klíč PK v R 2, FK se odkazuje na PK. 2. Hodnota FK v záznamu t 1 z R 1 se buďto vyskytuje jako hodnota PK v nějakém záznamu t 2 v R 2 nebo je NULL t 1 FK = t 2 PK

6 Příklad 3.6: Cizí klíče TŘÍDA (Číslo třídy, Třídní, Umístění) UČITEL (Číslo, Příjmení, Jméno, Kabinet ) MÍSTNOST (Číslo, Název, Kapacita, Typ) TYP (Číslo, Označení) Bussiness pravidla Předchozí typy podmínek ovšem nezahrnují velké skupiny obecných podmínek tzv. podmínek sémantické integrity, které mohou být specifikovány na relační databázi a mohou ovlivňovat uloţená data. vycházejí z poţadavků uţivatele, logiky aplikace souvisejí se způsobem pořizovaní a zpracování dat, schodem firmy vymezení povolených hodnot v polích pomocí číselníků, matematických, logických, formátovacích pravidel vzájemné logické vazby polí vzájemné hierarchické vazby polí pravidla pro vztahy Příklad 3.7: Sportovní klub smlouva hráče je nejvýše na 3 roky v klubu smí působit nejvýše 5 cizinců Příklad 3.8: Firma kaţdý zaměstnanec je zařazen na právě jedno pracoviště plat zaměstnance musí být menší neţ plat vedoucího maximální počet hodin odpracovaných v týdnu < 56 hod roční počet přesčasů < 181 hod Příklad 3.9: Knihovna kniha je zařazena na jediné oddělení od kaţdé evidované knihy můţe být více výtisků délka výpůjčky knihy je 1 měsíc délka výpůjčky časopisu je 1 týden čtenář můţe mít půjčeno nejvýše 15 knih čtenář musí zaplatit roční poplatek nejpozději do 30 dnů po přihlášení

7 Potenciální chybové situace - aktualizační operace na relaci INSERT můţe nastat porušení podmínek na doménu porušení klíčových podmínek porušení entitních podmínek (klíč NULL) porušení RI podmínek porušení business pravidel DELETE můţe nastat porušení RI podmínek porušení business pravidel MODIFY jedná se vlastně o DELETE a INSERT, z toho vyplývají příslušné moţné porušení všech podmínek Transformace ER model do relačního DB modelu entitní typ = tabulka její sloupce odpovídají atributům vztahový typ kardinalita 1:1 není nutná další speciální tabulka je-li účast na vztahu oboustranná, lze provést sloučení do jediné tabulky kardinalita 1:N, N:1 není nutná další speciální tabulka do tabulky na straně N je nutné zahrnout cizí klíč kardinalita M:N, N:1 Coddova pravidla nutná další speciální (průniková, asociační) tabulka průniková tabulka obsahuje cizí klíče do obou tabulek a eventuelně další atributy vztahu 1. Pravidlo SŘBD: data spravována pouze pomocí relačních operací 2. Pravidlo informační: data reprezentována na logické úrovni jako hodnoty relačních tabulek 3. Pravidlo přístupu: kaţdý údaj logicky dosaţitelný pomocí kombinace názvu tabulky, sloupce a hodnoty primárního klíče 4. Pravidlo zpracovatelnosti neznámých hodnot: kaţdou neznámou hodnotu lze určit pomocí jiných známých hodnot 5. Pravidlo relačního katalogu: popis celé databáze je na logické úrovni reprezentován jako relační systémový katalog

8 6. Pravidlo pro jazyk: pro komunikaci se SŘBD: jazyk pro definici dat (DDL) jazyk pro manipulaci s daty (DML) jazyk pro definici integritní omezení (DCL) 7. Pravidlo pohledů: SŘBD musí umoţňovat konstrukci pohledů 8. Pravidlo operací: všechny relační operace pracují s tabulkami jako s celky 9. Pravidlo fyzické a logické nezávislosti dat 10. Pravidlo nezávislosti dat na integritních omezeních: výsledky operací musí být nezávislé na změnách IO 11. Pravidlo nezávislosti dat na distribuci: výsledky operací nesmí být ovlivněny konkrétním umístěním dat v distribuovaných databázích 12. Pravidlo nenarušitelnosti SŘBD: ţádný uţivatel nesmí obcházet nebo narušovat rozhraní SŘBD Příklady Příklad 3.10: BANKA část databáze ÚČET Číslo účtu Číslo klienta Kód Datum Datum posled. měny zaloţení pohybu Zůstatek 124df45f CZK h1g USD o1k GBP KLIENT Číslo klienta Jméno klienta Adresa Podpisový vzor Dvořák Petr Český Krumlov, Špičák 127 Petr Dvořák ALFA s. r. o. Tábor, Praţská 1882 Peterka Metrostav a. s. Praha, I. P. Pavlova 174 Svoboda Pavel

9 Příklad 3.11: KNIHOVNA část databáze ČTENÁŘ Id Datum Příjmení Jméno Město Ulice Psč čtenář registrace 0001 Adamec Petr Český Krumlov Fialková Dvořáková Jana Kaplice Luční Vávrová Alena Besednice Dlouhá 11 NULL Suchánek Jakub Kaplice Náměstí ŢÁNR Id ţánr Ţánr 01 dětská literatura 02 dobrodruţství 03 sci-fi 04 cestopis 05 román 06 thriller 07 detektivky 08 literatura faktu VÝTISK Evidenční Datum Kniha číslo pořízení Cena / , , , ,00 VÝPUJČKA Čtenář Výtisk Datum Datum výpůjčky vrácení

10 Příklad 3.12: FIRMA ZAMĚSTNANEC Id_zam Příjmení Jméno Rod.číslo Adresa Oddělení ODDĚLENÍ Číslo Název Vedoucí Pracoviště PRACOVIŠTĚ Číslo pracoviště Název Místo PROJEKT Číslo projektu Název projektu Pracoviště PRACUJE_NA Projekt Zaměstnanec Počet hodin DÍTĚ Zaměstnanec Jméno Rodné číslo dítěte

11 Příklad 3.13: ZÁSILKOVÁ FIRMA ZÁKAZNÍK Číslo Jméno Osoba Adresa IČO DIČ DPH SKLAD Číslo zboţí Mnoţství CENÍK Číslo zboţí Název Měr. jednotka Cena za mj OBJEDNÁVKA Číslo Datum Zákazník Číslo účtu POLOŢKA_OBJ Číslo obj Název zboţí Mnoţství FAKTURA Číslo faktury Číslo obj Datum Splatnost POLOŢKA_FAK Číslo fak Název zboţí Mnoţství Cena za mj

12 Příklad 3.14: ZOO ZVÍŘE Číslo Jméno Pohlaví Druh Narození Umístění DRUH Číslo druhu Číslo třídy Číslo řádu Název TŘÍDA Číslo třídy Název ŘÁD Číslo řádu Název PAVILON Číslo pavilonu Název Vedoucí Umístění MÍSTO Číslo Číslo pavilonu ZAMĚSTNANEC Osobní číslo Jméno Adresa Rod. číslo Funkce FUNKCE Číslo funkce Název funkce PEČUJE Osobní číslo Číslo místa

13 Příklad 3.15: MUZEUM EXPONÁT Číslo Název Období Původ Místnost MÍSTNOST Číslo Číslo budovy Patro BUDOVA Číslo budovy Adresa Stát OBDOBÍ Číslo období Název EXPOZICE Číslo expozice Název UMÍSTĚNÍ Číslo expozice Místnost

14 Příklad 3.16: KNIHOVNA podrobněji ČTENÁŘ Příjmení Jméno Rod.číslo Adresa Datum Číslo průkazky VÝPŮJČKA Výtisk Vypůjčeno Vráceno Čtenář REZERVACE Číslo knihy Datum Čtenář KNIHA Číslo knihy Název Ţánr ŢÁNR Číslo ţánru Název VYDÁNÍ Číslo vydání Kniha Rok vydání Nakladatelství VÝTISK Evidenční číslo Vydání Cena Stav NAKLADATELSTVÍ Číslo Název Město Stát AUTOR Číslo Příjmení Jméno Národnost Narození AUTORSTVÍ Autor Kniha Literatura: [1] ELMASRI, R., NAVATHE, S., B. Fundamentals of Database Systems, 5th edition. Addison-Wesley, ISBN [2] SILBERSCHATZ, A., KORTH H. F., SUDARSHAN S. Database System Concepts, 5 th edition, New York: McGraw-Hill, ISBN [3] CONOLLY, T., BEGG, C., HOLOWZAK R. Profesionální průvodce tvorbou databází. Praha: Computer Press, a. s., ISBN [4] HERNANDEZ, M., J. Návrh databází. Praha: Grada, ISBN [5] POKORNÝ, J. Databázová abeceda. Veletiny: Science, 1998, ISBN [6] POKORNÝ, J., HALAŠKA, I. Databázové systémy, 2. vydání. Praha Vydavatelství ČVUT, 2003, ISBN