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)