ydasys1 10 10 2013
Download
Skip this Video
Download Presentation
YDASYS1 10 .10.2013

Loading in 2 Seconds...

play fullscreen
1 / 19

YDASYS1 10 .10.2013 - PowerPoint PPT Presentation


  • 91 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' YDASYS1 10 .10.2013' - teddy


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á

slide2

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