OBSAH WEBU
ČTĚTE!
Rozdíly
Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.
|
temata:32-konceptualni_modelovani_a_rel_dat:main [2011/03/06 16:02] sgs |
temata:32-konceptualni_modelovani_a_rel_dat:main [2014/06/15 00:45] (aktuální) xchomj00 [Proces normalizace] |
||
|---|---|---|---|
| Řádek 1: | Řádek 1: | ||
| + | ~~ODT~~ | ||
| + | |||
| =====Konceptuální modelování a návrh relační databáze===== | =====Konceptuální modelování a návrh relační databáze===== | ||
| Řádek 17: | Řádek 19: | ||
| **Doména atributu** - obor hodnot atributů | **Doména atributu** - obor hodnot atributů | ||
| + | |||
| **Vztah** - asociace mezi entitami (klient 437 vlastní účet 100) | **Vztah** - asociace mezi entitami (klient 437 vlastní účet 100) | ||
| Řádek 47: | Řádek 50: | ||
| **Silná entitní množina** - může existovat sama o sobě | **Silná entitní množina** - může existovat sama o sobě | ||
| *Jsme-li na pochybách, zvolíme silnou | *Jsme-li na pochybách, zvolíme silnou | ||
| + | |||
| + | ====Generalizace / specializace:==== | ||
| + | Dědičnost atributů a účasti ve vztahových množinách, hierarchie generalizace | ||
| + | |||
| + | {{:temata:32-konceptualni_modelovani_a_rel_dat:2.png|}} | ||
| + | |||
| + | ====Návrh relační databáze==== | ||
| + | {{:temata:32-konceptualni_modelovani_a_rel_dat:3.png|}} | ||
| + | |||
| + | **Konceptuální modelování** – patří do etapy analýzy požadavků. Cílem je analyzovat požadavky na | ||
| + | data, která budou uložena v databázi. Výsledkem je ER diagram základní model v požadavcích na | ||
| + | data. | ||
| + | |||
| + | **Logický návrh** | ||
| + | *cílem je navrhnout strukturu databáze, aby v databázi bylo vše požadované (informace, neexistovala redundance | ||
| + | *Výsledkem je logické schéma databáze (návrh tabulek, omezení vazeb atp.) | ||
| + | **Fyzický návrh** | ||
| + | *navržení fyzické uložení tabulek pomocí logického návrhu. | ||
| + | *Bývá složitější struktura, než u logického návrhu | ||
| + | *Důležité je navrhnout strukturu vzhledem k SŘBD pro efektivní přístup k datům | ||
| + | **Přístup** | ||
| + | *Strukturovaný vs. objektově orientovaný | ||
| + | *Pro návrh databáze výhodnější strukturovaný, protože nás zajímají data, nikoliv operace nad nimi | ||
| + | **Přístup k návrhu databáze** | ||
| + | *Transformace koncept. modelu na schéma databáze | ||
| + | *Mezi kroky vložená normalizace (k.m. -> norm. -> schéma) | ||
| + | **Normalizace** - Zkvalitňování návrhu tabulek - lepší schéma databáze (má lepší vlastnosti) | ||
| + | |||
| + | ====Proces normalizace==== | ||
| + | *Proces normalizace umožňuje vyvarovat se: opakující se informace (redundance), nemožnost reprezentovat | ||
| + | určitou informaci, složitá kontrola integritních omezení | ||
| + | *Myšlenka normalizace se opírá o dva základní koncepty: Hierarchii tzv. normálních forem, které odrážejí | ||
| + | kvalitu návrhu a postup dekompozice schématu relace, které vykazuje nedostatky. | ||
| + | *Nejčastěji se uvádí 6 normálních forem: 1NF odráží základní požadavky relačního modelu dat z hlediska | ||
| + | složitosti dat – atomické hodnoty jednoduchých atributů. 2NF, 3NF a BCNF definují požadované vlastnosti z | ||
| + | hlediska funkčních závislostí atributů. Konečně 4NF, 5NF definují požadované vlastnosti z hlediska | ||
| + | vícehodnotových závislostí, resp. Závislostí na spojení. 4 a 5 jsme neřešili- | ||
| + | |||
| + | |||
| + | **Příklad:** | ||
| + | Zakladni nijak nenormalizovana databaze: | ||
| + | |||
| + | {{:temata:32-konceptualni_modelovani_a_rel_dat:4.png|}} | ||
| + | |||
| + | Pravidlo 1NF říká, že všechny tabulky obsahující opakující se sloupce je třeba rozdělit do nových tabulek, v nichž může být údaj uložen pouze jednou (data o výrobku) a pole tabulky musí obsahovat údaje atomicky dále nedělitelné (adresa) | ||
| + | |||
| + | {{:temata:32-konceptualni_modelovani_a_rel_dat:5.png|}} | ||
| + | |||
| + | Pravidlo 2NF říká, že všechny tabulky obsahující sloupce s duplicitními položkami, které mezi sebou vytvářejí částečné závislosti, je třeba rozdělit do tabulek nových, v nichž bude každý údaj uložen pouze jednou. Částečná závislost je pojem, jímž se popisují data, která nelze identifikovat na základě žádného klíče dané tabulky | ||
| + | V našem případě to znamená, že když budeme chtít pro jednoho zákazníka vytvořit více objednávek, je třeba pro objednávky vytvořit samostatnou tabulku | ||
| + | |||
| + | {{:temata:32-konceptualni_modelovani_a_rel_dat:6.png|}} | ||
| + | |||
| + | Pravidlo 3NF vyžaduje důsledné odstranění a oddělení dat, která nejsou v přímém vztahu s primárním klíčem dané tabulky. Hodnota pole každého záznamu musí být závislá na hodnotě klíčové položky, která jednoznačně identifikuje všechna pole daného záznamu. Pole DodavatelNazev není identifikováno hodnotou pole IDOdberatele. Pole Sleva a Mnozství se také nevztahuje přímo k výrobku ale k řádku objednávky. Proto bylo nutné přidat ještě tabulky Dodavatele a DetailObjednavky. V tabulkách není vhodné uvádět vypočtená pole (ObjednavkaCelkem, Celkem). Tyto hodnoty je lépe vypočítat vždy v okamžiku potřeby pomocí dotazu nebo na formuláři či sestavě. | ||
| + | |||
| + | {{:temata:32-konceptualni_modelovani_a_rel_dat:7.png|}} | ||
| + | |||
| + | **Číselník** - tabulka (v tomto případě Dodavatelé) je tabulka pouze s dvěma sloupci, jednym s daty a druhý je klíč, slouží abychom například u tabulky výrobky nemuseli vypisovat dlouze dodavatele, ale pouze kratce odkazujeme číslem na tabulku dodavatelů. | ||
| + | |||
| + | http://www.manualy.net/article.php?articleID=13 | ||
| + | |||
| + | |||
