Ydasys1 10 10 2013
This presentation is the property of its rightful owner.
Sponsored Links
1 / 19

YDASYS1 10 .10.2013 PowerPoint PPT Presentation


  • 71 Views
  • Uploaded on
  • Presentation posted in: General

YDASYS1 10 .10.2013. Ing. Monika Šimková. Relační model dat

Download Presentation

YDASYS1 10 .10.2013

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Ydasys1 10 10 2013

YDASYS1 10.10.2013

Ing. Monika Šimková


Ydasys1 10 10 2013

  • 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í.


Z kladn terminologie rmd

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é)


Vlastnosti datab zov tabulky

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é.


Po adavky na rdbms

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í.


Z kladn pravidla

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).


Pravidla t kaj c se struktury dat

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


Pravidla t kaj c se modifikace dat

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)


Pravidla t kaj c se integrity dat

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.


Norm ln formy relac

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.


Funk n z vislost p klady 1

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.


Funk n z vislost p klady 2

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


Norm ln formy relac1

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é.


Proces normalizace rela n ch tabulek 1

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ů.


Proces normalizace rela n ch tabulek 2

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)


P klad normalizace

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.


P klad 1nf

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é.


P klad 2nf

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


P klad 3nf

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.


  • Login