YDASYS1 10 .10.2013

1. YDASYS1 10.10.2013 Ing. Monika Šimková

2. Relační model dat • Základy položil E.F. Codd v roce 1970 a vycházel z matematických pojmů teorie množin a predikátové logiky. Jako základní strukturu modelu použil relaci, jež je matematicky definována jako podmnožina kartézského součinu n množin. Hlavním cílem bylo: vnést disciplínu do způsobu manipulace s daty, • zabezpečit nezávislost dat, • zvýšit produktivitu programování.

3. Základní terminologie RMD • Databáze je kolekce databázových relací reprezentovaných tabulkami, tj. všechny informace jsou uloženy v tabulkách. • Databázová relace se liší od matematické definice relace ve dvou aspektech: • 1. Relace je vybavena pomocnou strukturou – schématem relace, které je tvořeno jménem relace, • jmény atributů, • definicí domén. • 2. Hodnoty jsou atomické (dále nedělitelné)

4. Vlastnosti databázové tabulky • 1. Každá tabulka má jednoznačné jméno. • 2. Každý sloupec v tabulce má jednoznačné jméno. • 3. Všechny hodnoty daného sloupce jsou stejného typu. • 4. Každá tabulka musí mít primární klíč. • 5. Nezáleží na pořadí sloupců. • 6. Nezáleží na pořadí řádků. • 7. Tabulka nemůže mít duplicitní řádky. • 8. Všechny hodnoty jsou atomické.

5. Požadavky na RDBMS • V roce 1985 Codd specifikoval 5 skupin pravidel (celkem 12) pro relační databázové systémy, která jsou měřítkem, zda daný DBMS je „skutečně“ relační: základní pravidla • pravidla týkající se struktury dat • pravidla týkající se integrity dat • pravidla týkající se modifikace dat • pravidla o nezávislosti dat • Dnešní relační databázové systémy tato pravidla splňují.

6. Základní pravidla • RDBMS musí být schopen manipulovat s daty • pomocí operací relační algebry. • Má-li RDBMS jazyk nižší úrovně - tato nižší úroveň nemůže porušit pravidla integrity vyjádřené na vyšší úrovni jazyka (Přístup do DB řídí RDBMS tak, aby integrita dat nemohla být porušena bez vědomí administrátora).

7. Pravidla týkající se struktury dat • RDBMS by mělpodporovat: • relace, • domény, • primární klíče, cizí klíče. • Všechny informace jsou reprezentované explicitně na logické úrovni jediným způsobem: hodnotami v tabulkách - i metadata. • Je-li pohled teoreticky upravitelný, měl by být i fakticky upravitelný. • 7

8. Pravidla týkající se modifikace dat • Garantovaný přístup ke každé atomické hodnotě na základě jména tabulky, hodnoty primárního klíče a názvu sloupce. • Obsáhlý jazyk na manipulaci s daty, který by měl umožňovat: definici dat, • definici pohledů, • modifikaci dat (interaktivní a programovou), • integritní omezení, • autorizaci, • transakce (begin, commit a rollback)

9. Pravidla týkající se integrity dat • Jsou podporovány hodnoty NULL na reprezentaci chybějící informace • Integritní omezení musí být definovány v DDL jazyku a musí být uložitelné v systémovém katalogu (centralizovaná kontrola integrity) • Pravidla o nezávislosti dat • Nezávislost dat na aplikaci, která data používá. • Uživatelé i aplikační programátoři jsou izolováni od organizace dat na nižší úrovni.

10. Normální formy relací • Normální formy lze použít při datovém modelování na kontrolu toho, zda jsou relace správně navrženy. Správnost posuzuje- me na základě splnění určitých pravidel - normálních forem. • Základním pojmem, spojeným s definicí normálních forem relací je funkční závislost, definovaná mezi dvěma množinami atributů jedné relace a je sémantickou vlastností atributů. • Definice 1:Je dána relace R(A,B), kde A, B mohou být složené atributy. Atribut B je funkčně závislý na atributu A, je-li pro každou hodnotu A jednoznačně daná hodnota B. • (Označení A B) • Definice 2: Atribut B je plně funkčně závislý na atributu A, je-li funkčně závislý na A a není funkčně závislý na žádné podmnožině A.

11. Funkční závislost - příklady (1) • U každé z následujících relací najděte funkční závislosti mezi atributy. • ČTENÁŘ(čČt, jméno, obec, ulice, číslo, PSČ) • čČt  jméno, obec, ulice, číslo, PSČ – pokud čČt je primární klíč • Platí také {obec, ulice, číslo}  PSČ - jedná se o plnou funkční závislost, neboť nestačí znát jenom obec nebo jenom ulici a obecně potřebujeme znát obec,ulici a číslo aby bylo možné zjistit PSČ. • REZERVACE(ISBN, čČt, datumRez) • { ISBN, čČt }  datumRez - platí v případě že uchováváme pouze aktuální rezervace. • Jedná se navíc o plnou funkční závislost, neboť stejný titul (ISBN) si může rezervovat více čtenářů a jeden čtenář si může rezervovat více titulů. Neexistuje funkční závislost pouze na ISBN nebo pouze na čČt.

12. Funkční závislost – příklady (2) • KREDITY(čPředm, čUč, jménoUč, čSt, jménoSt, známka, datum) • Předpokládáme, že se evidují i neúspěšné pokusy a student nemůže jít na zkoušku ze stejného předmětu vícekrát za den. • {čPředm, čSt, datum} → jménoSt, známka, čUč, jménoUč • {čPředm, čSt, datum} → známka – toto je plná funkční závislost • čPředm → čUč - tato závislost platí za předpokladu, že ke každému předmětu je evidován pouze jeden učitel – garant • čUč → jménoUč • čSt → jménoSt

13. Normální formy relací • 1. normální forma relace • Relace je v 1. normální formě, když všechny její hodnoty jsou atomické. • 2. normální forma relace • Relace je v 2. normální formě, když je v 1. NF a každý neklíčový atribut je plně funkčně závislý na primárním klíči a na každém kandidátním klíči. • 3. normální forma relace • Relace je v 3. normální formě, když je v 2. NF a všechny neklíčové atributy jsou vzájemně nezávislé.

14. Proces normalizace relačních tabulek (1) • Při návrhu schémat databázových relací potřebujeme dostat tabulky, které budou mít „rozumné vlastnosti“: • eliminované určité typy redundance • zjednodušenou kontrolu integrity dat, • nebude docházet k anomáliím při údržbě dat. • Proces normalizace tabulek je formální technika na- pomáhající při návrhu relačních databázových tabulek. Sestává z posloupnosti kroků, při kterých dochází k dekompozici původních tabulek na základě analýzy funkčních závislostí atributů.

15. Proces normalizace relačních tabulek (2) • Není – li relace v 1.NF (obsahuje vícehodnotový atribut), vytvoříme novou tabulku. • Není-li relace v 2.NF, tak vytvoříme projekci, abychom eliminovali neúplné funkční závislosti na primárním klíči. • Není-li relace v 3.NF, tak vytvoříme projekci, abychom odstranili tranzitivní závislosti. • Příklad: • R(A, B,C,D); A → D …. není v 2.NF – vytvoříme projekci: R1(A,B,C) a R2(A,D) • S(E, F,G); F → G … není v 3.NF – • vytvoříme projekci: R1(E, F) a R2(F,G)

16. Příklad normalizace • KREDITY(čPředm, čUč, jménoUč, čSt, jménoSt, známka,datum) • Tabulka má složený primární klíč: {čPředm, čSt, datum} • a hodnoty jsou atomické; je v 1.NF • Existují neúplné funkční závislosti na primárním klíči – tabulka není v 2.NF. • Odstraníme neúplné závislosti na PK vytvořením nových tabulek pomocí projekce. • Předmět(čPředm, čUč); čPředm je PK • Student(čSt, jménoSt); čSt je PK • Učitel(čUč, jménoUč); čUč je PK • Kredity(čPředm, čSt, datum, známka) • V nových tabulkách nejsou žádné funkční závislosti mezi neklíčovými atributy – tabulky jsou ve 3NF.

17. Příklad – 1NF • V tabulce Zásoby jsou uloženy informace obchodní společnosti, která má prodejny v různých městech. Cena produktů je stejná ve všech prodejnách. Pokud je ale stav zásob jednotlivých produktů v některé prodejně vyšší než daný limit, aplikuje se v té prodejně dané procentuální snížení ceny. • Zásoby(čProdejny, Město, Plocha, čManagera, JménoManagera, čProduktu, názevProduktu, Cena, Množství, Sleva) • Primární klíč: {čProdejny, čProduktu} • Tabulka je v 1NF – všechny hodnoty jsou atomické.

18. Příklad – 2NF • Abychom zjistili, zda je tabulka ve 2NF, musíme prozkoumat, zda neexistují parciální funkční závislosti na PK. • Je zřejmé, že platí: • čProdejny  město, plocha, čManagera, jménoManagera • čProduktu  názevProduktu, cena • Transformujeme proto původní tabulku pomocí projekce na více tabulek, každá je v 2NF: • Prodejny(čProdejny, město, plocha, čManagera, jménoManagera) • čProdejny je PK • Produkty(čProduktu, názevProduktu, cena) • čProduktu je PK • Zásoby (čProdejny, čProduktu, množství, sleva) • {čProdejny, čProduktu} je PK • 18

19. Příklad – 3NF • Abychom zjistili, zda je tabulka ve 3NF, musíme prozkoumat každou tabulku, zda v ní neexistují funkční závislosti mezi atributy. • V tabulce Prodejny platí zřejmě závislost • čManagera->jménoManagera • Transformujeme proto tabulku a projekcí vytvoříme dvě tabulky: • Prodejny(čProdejny, město, plocha, čManagera) • Manageři (čManagera, jménoManagera) • Dostali jsme celkem 4 tabulky, všechny splňují 3NF.