Konceptuální modelování - jedním ze tří kroků návrhu databáze

• cílem je analyzovat požadavky na data, která budou uložena v databázi
• výsledkem je model - ER diagram - základní model v požadavcích na data

ERD - entity-relationship, chápe modelovanou aplikační doménu jako množinu entit

• důležité je, že ERD popisuje data tzv. v klidu, neukazuje operaci nad daty
• základní objekty - entita (entity) a vztah (releationship), třetím je atribut

Entitní množina - množina entit téhož typu (klient, účet), sdílí stejné atributy

Entita - objekt rozlišitelný od jiných (klient banky s číslem 437)

Atribut - vlastnost entity, která nás zajímá a chceme ji mít v databázi (jméno)

Doména atributu - obor hodnot atributů

Vztah - asociace mezi entitami (klient 437 vlastní účet 100)

Vztahová množina - množina vztahů téhož typu (klient vlastní účet)

Identifikátor (primární klíč) entitní nebo vztahové množiny - atribut jehož hodnota je v dané množině jednoznačná, může být jednoduchý nebo složený atribut

Složené - jméno - křestní | příjmení

Jednoduché (křestní, příjmení) - pokud rozhodneme jméno jako celek (křestní+příjmení) potom je i tento atribut jednoduchý

Jednohodnotové vs. vícehodnotové - například telefon - číslo1, číslo2, …

Povolující prázdnou hodnotu NULL - hodí se například pokud víme, že hodnota existuje, pouze ji v dané chvíli neznáme

Odvozené - věk odvozený z datumu narození

Kardinalita - Maximální počet vztahů dané vztahové množiny, ve kterých může hrát roli jedna entita, vlastnost konce vztahu (nutno „číst“ z obou stran)

Členství - Minimální kardinalita - vyjadřuje minimální počet vztahů dané vztahové množiny (0-volitelné, 1-povinné)

Slabá entitní množina - Je závislá na jiné entitní množině a je pomocí ní identifikovatelná

• identifikátor (slabé) obsahuje identifikátor dominantní množiny

Silná entitní množina - může existovat sama o sobě

• Jsme-li na pochybách, zvolíme silnou

Dědičnost atributů a účasti ve vztahových množinách, hierarchie generalizace

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 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:

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)

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

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

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