22
Návrh Databází Štěpán Šípal

Návrh Databází

Embed Size (px)

DESCRIPTION

Návrh Databází. Štěpán Šípal. Přehled témat hodiny. Dokonalé E-R diagramy Multiplicita v E-R diagramech Atomicita atributů Vícehodnotové atributy Normalizace Design databáze v DBDesigner 4. Dokonalé ER diagramy. - PowerPoint PPT Presentation

Citation preview

Návrh Databází

Štěpán Šípal

Přehled témat hodiny

Dokonalé E-R diagramy Multiplicita v E-R diagramech Atomicita atributů Vícehodnotové atributy Normalizace Design databáze v DBDesigner 4

Dokonalé ER diagramy

ER diagram je základem pro další návrh databáze, zobrazuje skutečný stav věcí.

Entita – objekt, abstraktní, nikoliv specifickýEntitou je pes, jejím výskytem je „Haryk“.Všechny výskyty entit mají obdobné atributy,

nikoliv však jejich hodnoty!

ER diagramy II.

Atribut entity je její vlastností, například „jméno“.

Jednotlivé hodnoty atributů („Haryk“) nás při modelování nezajímají.

Atributům můžeme určovat takzvané domény – slovně popíšete, jakých hodnot může u jednotlivých výskytů entity nabývat.

Relace v ER diagramech

Relace označují určitý vztah mezi jednotlivými entitami.

Musí být popsány a mohou mít vlastní atributy (relace mezi zákazníkem a zbožím bude „zakoupil“ s atributy kdy a za kolik).

Zaměstnanec PobočkaPracuje v

Relace v ER diagramech

Noviny AutomobilMají reklamu na

Atributy:odKdyCena

Multiplicita

1:1 – jednomu výskytu entity A náleží vždy jeden výskyt entity B (pobočka a její vedoucí manažer).

1:n – jednomu výskytu entity A náleží více výskytů B (pobočka a zaměstnanci).

M:n – Jednomu výskytu A náleží více B a jednomu B více A (noviny a propagovaná auta).

Problémy s ER - pasti

Pokud od jedné entity existuje více vazeb s multiplicitou 1:n.

Firma PobočkaZaměstnanecn zam. 1 1 má n

Takovýto zápis je teoreticky správně, ale logicky nám neposkytuje informace o tom, v jaké pobočce zaměstnanec pracuje – musíme jej tedy předělat.

Vyřešení pasti

Přetvoříme tedy tuto past na „vláček“, kde se budou entity vázat jasněji:

FirmaPobočkaZaměstnanecn zam. 1 n má 1

Atomicita atributů

Pokud jednotlivé atributy je možné dále rozložit, jsou to atributy tzv. složené Například adresa – rozložitelné na ulici, město, PSČ,

… Atributy které nelze dále rozkládat nazýváme

atomickými. Rozhodnutí zda rozložit záleží na budoucím

využití DB – obecně je lepší vždy mít atomické hodnoty.

Vícehodnotové atributy

Pokud nějaký atributy může mít více hodnot v jeden okamžik – například entita firmy může mít najednou tři telefonní čísla.

Je lépe takový atribut odpojit a vytvořit jej jako novou entitu ve vztahu 1:n.

Vytvoříme novou entitu telefonní čísla.

Normalizace

Co je normalizace

Normalizace je činnost, při které se snažíme vytvořit tabulky s minimálním nutným počtem atributů s jasným vztahem a s minimální redundancí (opakováním) dat.

Normalizace zabraňuje možných chybám při práci s DB.

Redundance dat a problémy změn

idZaměst jméno pozice plat pobočka

Z002 Roman manager 20000 B002

Z003 Pavel uklízeč 15000 B002

Z005 Michal manager 20000 B003

idZaměst jméno pozice plat idPob pAdresa

Z002 Roman manager 20000 B002 Tupolevova 478, …

Z003 Pavel uklízeč 15000 B002 Vratimovská 456, …

Z005 Michal manager 20000 B003 Fryčovická 555, …

idPob pAdresa

B002 Tupolevova 478, …

B002 Vratimovská 456, …

B003 Fryčovická 555, …

Zaměstnanci

Pobočky

ZaměstnanciPobočky

Problémy při vkládání

Při vkládání datDo špatně navržené tabulky musíme zbytečně

vkládat informace navíc (při vložení zaměstnance také adresu pobočky).

Pokud chceme vložit novou pobočku, která zatím nemá zaměstnance, musíme do atributů zaměstnance vložit samé „null“.

Tabulka obsahuje zbytečně redundantní data.

Problémy při odstraňování

Pokud chceme odstranit posledního zaměstnance určité pobočky z tabulky ZaměstnanciPobočky, údaje o této pobočce budou také smazány.

Problémy při změnách

Pokud chceme změnit adresu určité pobočky v tabulce ZaměstnanciPobočky, musíme změnit všechny záznamy, ve kterých se tato pobočka vyskytuje.

Může se snadno stát, že přidáme zaměstnance k pobočce a přiřadíme ji špatnou adresu.

První normální forma

Zajištění, aby v každé „buňce“ tabulky s daty byla pouze jedinečná hodnota.

Zjistíme chyby v tabulkách typu atributu „telefonní čísla“ s X možnými hodnotami.

Pro tyto atributy se vytvoří nové tabulky.

První normální forma II.

IdZaměstnance zJmeno zTelefon

Z0001 Robert 777691889, 26282884

Z0002 Pavel 735778086, 28873445

Z0003 Štěpán 736778086, 23345674

IdZaměstnance zJmeno

Z0001 Robert

Z0002 Pavel

Z0003 Štěpán

FKIdZaměstnance telefon

Z0001 777691889

Z0001 26282884

Z0002 735778086

Z0002 28873445

Z0003 736778086

Z0003 23345674

Druhá normální forma

Zjistíme, zda jsou všechny atributy závislé na primárním klíči.

Pokud nejsou, vytvoříme pro ně nové tabulky a rozumně je propojíme.

Druhá normální forma II.IdZaměstnance zJmeno idPobočky adresaPobočky

Z0001 Robert B004 Tupolevova 456

Z0002 Pavel B004 Tupolevova 456

Z0003 Štěpán B005 Beranových 556

IdZaměstnance zJmeno FKidPobočky

Z0001 Robert B004

Z0002 Pavel B004

Z0003 Štěpán B005

idPobočky adresaPobočky

B004 Tupolevova 456

B005 Beranových 556

Třetí normální forma

Zajistíme, aby veškeré atributy byly na primárním klíči závislé přímo.

Tabulce nájemních domů je jméno nájemníka závislé na jeho id a teprve jeho id na primárním klíči domu.

Takovým atributům vytvoříme samostatnou tabulku.