2 Konceptuální modelování a návrh databáze

2 Konceptuální modelování a návrh databáze 2.1. Úloha konceptuálního modelování v procesu návrhu databáze ... 2 2.2. E - R modely ....................................................................................... 6 2.3. Doporučení pro modelování a tvorbu ER diagramu ..................... 22 2.4. Transformace ER diagramu na tabulky relační databáze ............ 32 2.5. Transformace objektového modelu (diagramu tříd)..................... 40 Literatura................................................................................................... 43

J. Zendulka: Databázové systémy a návrh databází – 2 Konceptuální modelování a návrh databáze

1

2.1. Úloha konceptuálního modelování v procesu návrhu databáze Konceptuální modelování - fáze datové, případně objektové analýzy využívající modelů založených na objektech aplikační domény. • Fáze návrhu databáze Požadavky na data

Konceptuální návrh Logický návrh

Konceptuální schéma (ERD)

Logické schéma (tabulky)

Fyzický návrh Fyzické schéma (uložené záznamy, přístupové metody)


2

Přístup: strukturovaný (klasický): východiskem pro návrh databáze je ER model Datové modelování (ERD)

Funkční modelování (DFD)

Modifikace datového modelu na základě funkčních požadavků

Převod datového modelu na logické schéma databáze


3

objektově-orientovaný: východiskem pro návrh databáze je diagram tříd

Model použití

Modely interakce

…

¨Diagram tříd aplikační domény

Převod objektového modelu logické schéma databáze


4

• Přístup k návrhu databáze: Entitní množiny (třídy) + vztahy

Seznam atributů entit (objektů) + závislosti

Normalizace

Transformace Prvotní schéma Klient(r_číslo, jméno, …, příjmení, č_účtu, stav, …) Normalizace

Normalizované schéma relační databáze Klient(r_číslo, jméno, příjmení, …), Účet(č_účtu, stav, …) Návrh fyzické organizace (tabulkové prostory, indexy, clustery, …) Vytvoření databázových objektů CREATE TABLE Klient (…) CREATE INDEX IKlient ON Klient(…) J. Zendulka: Databázové systémy a návrh databází – 2 Konceptuální modelování a návrh databáze

5

2.2. E - R modely ER model je založen na chápání světa jako množiny základních objektů - entit (Entity) a vztahů (Relationship) mezi nimi. Popisuje data "v klidu", neukazuje, jaké operace s daty budou probíhat. Někdy se označuje také jako ERA – třetím základním prvkem modelu jsou atributy (Attributes).


6

Př) vkládání

rušení klient účet

účet příkaz

modifikace

dotazy

• Základní pojmy Entita – „věc“ nebo objekt reálného světa rozlišitelný od jiných objektů, o níž chceme mít informace v DB. Př) Klient banky s identifikačním číslem 999, účet s číslem účtu 100. Entitní množina - množina entit téhož typu, které sdílí tytéž vlastnosti neboli atributy. Př) Klient, Účet


7

K999

K628 Klient

K123

U100

U150

U48

U79

Účet

vlastní U100 K999

U150

U48 K628

Klient

vlastní


U79 K123

Účet

8

Atribut - vlastnost entity, která nás v kontextu daného problému zajímá a jejíž hodnotu chceme mít v DB uloženu. Př) Klient: čísloKlienta, jméno, příjmení, adresa, … Doména atributu - obor hodnot atributu. Vztah – asociace mezi několika entitami. Př) Klient s číslem klienta K999 vlastní účet s číslem účtu U100. Vztahová množina - množina vztahů téhož typu, které sdílí tytéž vlastnosti. Př) Klient vlastní Účet – pro vztah mezi entitami typu Klient a Účet Identifikátor (primární klíč) entitní nebo vztahové množiny – atribut, jehož hodnota je v rámci dané množiny jednoznačná a neredukovatelná (v případě složeného atributu – viz dále). Poznámka.: Často se používá označení entita i ve významu entitní množiny, entita se potom zpravidla označuje jako instance entity. Analogicky pro vztahové množiny a vztahy.


9

• Typy atributů Jednoduché (simple) a složené (composite) atributy Př) Entitní množina Složené atributy Složky Složky

Klient adresa

jméno křestní prostřední

příjmení jméno


ulice číslo

město

PSČ

čísloBytu

10

Jednohodnotové (single-valued) a vícehodnotové (multiplevalued) (někdy také opakující se atributy) Př)

Entitní množina

Klient

Vícehodnotový atribut

telefon

Hodnoty atributu

číslo1, číslo2, číslo3, …

Povolující prázdnou hodnotu Mohou nabývat speciální hodnoty NULL. Význam hodnoty NULL: hodnota chybí (missing) - existuje, ale my ji neznáme, Př) datum narození hodnotu neznáme (unknown) – nevíme, jestli vůbec existuje Př) čísloBytu J. Zendulka: Databázové systémy a návrh databází – 2 Konceptuální modelování a návrh databáze

11

Odvozené Hodnotu lze odvodit od jiných atributů nebo entit. Př) věk, početDispOsob • Identifikátor (primární klíč) entitní množiny - entity a vztahy musí být identifikovatelné - hodnota identifikátoru musí být unikátní (a minimální) - identifikátorem je jednoduchý nebo složený atribut • Parametry vztahů Jméno vztahové množiny, jméno role Vyjadřuje význam vztahu. Př)

jméno vztahové množiny Klient

vlastní vlastník

Účet

jméno role J. Zendulka: Databázové systémy a návrh databází – 2 Konceptuální modelování a návrh databáze

12

Stupeň Př)

Zaměstnanec

Klient

vlastní

Účet

nadřízený unární (reflexivní) Programátor ternární

binární používá

Projekt

Jazyk


13

Kardinalita (cardinality) (maximální kardinalita), Maximální počet vztahů daného typu (vztahové množiny), ve kterých může participovat jedna entita (1,M, případně přesněji). Př)

Zaměstnanec *

Klient

vlastní

Účet

*

1 nadřízený 1

Programátor *

používá

*

Projekt

* Jazyk


14

Členství (membership) (také účast (participation), minimální kardinalita) Vyjadřuje minimální počet vztahů daného typu (vztahové množiny), ve kterých musí participovat jedna entita (0 – volitelné/1 – povinné), resp. účast entitní množiny ve vztahu (částečná (partial)/úplná (total)). Př)

Zaměstnanec 1..*

Klient

1

nadřízený 0..1

Programátor 0..*

vlastní

používá

0..*

Účet

0..*

Projekt

1..* Jazyk J. Zendulka: Databázové systémy a návrh databází – 2 Konceptuální modelování a návrh databáze

15

Kardinalita i členství představují omezeni (constraint) Jiným důležitým typem omezení je existenční závislost. Př) Klient (vlastník účtu) a Účet Atributy vztahu

Klient čísloKlienta jméno adresa telefon

0..*

0..*

disponuje

Účet čísloÚčtu datumZřízení stav

limit


16

• Používané notace pro kreslení ER diagramu Název

Název IČO

Dodavatel

1

Adresa

Dodává

M

Číslo zboží

Zboží

Barva

Telefon

Dodavatel

Dodavatel

Dodává

Dodává Je dodáváno

Zboží Dodavatel

Zboží

Dodává Zboží

Dodavatel

Dodává

Dodavatel Dodává Zboží

Zboží

- my budeme používat notaci odvozenou z jazyka UML (Unified Modeling Language) J. Zendulka: Databázové systémy a návrh databází – 2 Konceptuální modelování a návrh databáze

17

• Rozšíření klasického ER modelu Slabé (weak) entitní množiny Silná (strong) entitní množina – má identifikátor tvořený vlastními atributy. Slabá entitní množina – nemá identifikátor tvořený z vlastních atributů, nýbrž obsahuje identifikátor jiné entitní množiny (pouze jedné), na níž závisí tzv. dominantní). identifikující vztahová množina

Účet <> čísloÚčtu datumZřízení stav

<<weak>> 1

0..*

Příkaz

<> pořČíslo <> typ částka datum

„vlastní“ identifikující dominantní (nezávislá)

diskriminátor (dílčí identifikátor)


slabá (závislá)

18

-

identifikátor = identifikátor_dominantní + diskriminátor existenční závislost slabé množiny na identifikující


19

Generalizace/specializace (ISA vztah)

Účet S1 S2 S4

<> čísloÚčtu datumZřízení s tav

B1 S3

B2 B3

S5

Spořitelní Spořitelní

Účet

Běžný

úro k

Běžný limitČerpání

vyjádření rozdílů (atributy, vztahy)- specializace pojmy entitní množina vyšší/nižší úrovně (nadtřída/podtřída) dědičnost atributů a účasti ve vztahových množinách, hierarchie generalizace (viz OO přístup) - identifikátor entitních množin nižší úrovně je stejný jako vyšší -


20

Omezení generalizace/specializace o příslušnost – disjunktní/překrývající se o úplnost – totální/částečná


21

2.3. Doporučení pro modelování a tvorbu ER diagramu • Jména - srozumitelná, musí vyjadřovat význam entitních a vztahových množin - entitní množiny: podstatná jména - vztahové množiny: slovesa, předložky - je-li jméno vztahové množiny jasné ze jmen entitních množin, není nutné uvádět • Několik různých vztahových množin mezi stejnými entitními - nutno použít jméno vztahové množiny nebo jméno role.

Klient čísloKlienta jméno adresa telefon

1 *

vlastní disponuje

* *

Účet čísloÚčtu datumZřízení stav

disponuje limit


22

• Celkový systém by neměl být zahrnut do ERD

Banka

1

má

*

Klient

• Identifikátor entitní množiny - identifikátorem je jednoduchý nebo složený atribut - situace, kdy používáme složené identifikátory: přirozená identifikace spojením několika atributů vazební entitní množiny nahrazující vztahové s kardinalitou M:M u slabých entitních množin při modelování časových změn - unikátnost hodnoty jen v rámci vyvíjeného systému (ne celého světa)


23

- Nevytvářet entitní množinu s různými identifikátory entit na základě jejich výskytu ve stejné vztahové množině.

zaregistroval

Vlastník <> rodnéČíslo 1 <> IČO

Vozidlo *

<> poznZnačka

nevhodné Firma

0..1

<> IČO

*

Osoba <> rodnéČíslo

zaregistrovala

0..1

zaregistrovala

*

Vozidlo <> poznZnačka

vhodné další možnost - generalizace


24

• Identifikátor vztahové množiny - zpravidla složený z identifikátorů participujících entitních množin, případně ještě v kombinaci s některým z atributů vztahu, pokud kombinace identifikátorů nepostačuje. Př) disponuje ... (čísloKlienta, čísloÚčtu) disponuje … (čísloKlienta, čísloÚčtu, platnostOd), za předpokladu, že vztah má např. atribut limit, jehož výši lze měnit a je potřeba uchovávat historii změn • Entitní množina nebo atribut?

Automobil <> výrČíslo barva

?

má

Automobil <> výrČíslo

*

Barva 1 <> barva

Pravidlo: Je-li hodnota atributu důležitá, i když neexistuje žádná entita s touto hodnotou jako vlastností, pak bychom ji měli modelovat jako entitu. - Z modelování entitní množinou pak vyplývá omezení na hodnotu odpovídajícího atributu.


25

• Atributy a vztahy 1:M

Osoba

Osoba

<> rodnéČíslo

<> rodnéČíslo

1

zaregistrovala *

1

?

zaregistrovala datRegistrace

*

Vozidlo

Vozidlo

<> poznZnačka datRegistrace

<> poznZnačka

Pravidlo: Měli bychom dávat přednost modelování jako atributu vztahu. Hrozí-li nebezpečí, že by se mohla časem kardinalita vztahové množiny změnit na M:M, pak modelujeme jako atribut vztahu v každém případě.


26

• Náhrada vztahů M:M vazební entitní množinou

Klient <> čísloKlienta jméno adresa telefon

0..*

disponuje disponuje

1..*

Účet <> čísloÚčtu datumZřízení stav

limit

Klient <> čísloKlienta jméno adresa telefon

Disponuje 1

Účet

<> čísloÚčtu <> čísloKlienta 1..* <> čísloÚčtu 0..* 1 datumZřízení stav limit

- zpravidla před transformací na schéma relační databáze


27

• Doporučení pro použití slabých entitních množin Volba identifikátoru slabé entitní množiny - zpravidla speciální atribut jako diskriminátor

Zájezd <> datum 1

Zájezd <> čísloZájezdu datum 1 <>

<>

0..* <<weak>

Zastávka <> město

0..*

v

<<weak>>

Zastávka <> čísloZastávky


0..*

Město 1 <> název

28

Volba správné identifikující entitní množiny - vycházet z přirozené závislosti Př) Dodavatel realizuje kontrakt a v jeho rámci dodávky uzavřel

Dodavatel <> IČO

1

1

?

realizuje

<>

*

Kontrakt

*

<> KontraktID 1 v rámci

* <<weak>> Dodávka <> pořČíslo

Vyvarování se redundance - slabá entitní množina má jen jednu identifikující množinu, se kterou je ve vztahu 1:M → nelze takto modelovat vztahy M:M


29

Př) Klient – disponující – Účet <>

Účet *

*

<<weak>> Disponent

ŠPATNĚ

Slabá nebo silná entitní množina? Pravidlo1: Jako slabou modelovat tehdy, kdy entita kompletně zmizí při odstranění odpovídající identifikující entity. Př) Objednávka – PoložkaObjednávky Pravidlo2: Cokoliv s atributem, který je jednoznačný, by nemělo být modelováno jako slabá entitní množina. Pravidlo3: Jsme-li na pochybách, modelujeme jako silnou entitní množinu. Možnost modelování jako vícehodnotového atributu

Objednávka <> čís loObjednávky položka[1..*]


30

Použití pro modelování časových změn Změny atributů <<weak>>

Osoba

<>

<> rodnéČíslo jméno

1

Vážení

0..* <> pořČíslo datum váha

Změny vztahů

pracuje

Osoba <> rodnéČíslo jméno

Oddělení 1

0..*

Osoba

<> čísloOddělení název

Osoba

Oddělení

<> rodnéČíslo 0..* jméno

1..* <> čísloOddělení název

<<weak>> <>

<> rodnéČíslo 1 jméno

na

Pracovala

Zařazení

1..* <> pořČíslo od do 0..*

od do

Oddělení

1

<> čísloOddělení název


31

2.4. Transformace ER diagramu na tabulky relační databáze Datové modelování (ERD)

Funkční modelování (DFD)

Logické schéma tabulky, integritní omezení

Databázové objekty

indexy, uložené procedury, triggery, … (serverová část)

• Hlavní problémy špatného návrhu opakující se informace (redundance) nemožnost reprezentovat určitou informaci složitá kontrola integritních omezení Př)r_číslo – rodné číslo disponující osoby J. Zendulka: Databázové systémy a návrh databází – 2 Konceptuální modelování a návrh databáze

Kód aplikace (klient)

formálně BCNF, resp. 3NF

32

č_účtu 100 100 130 150

r_číslo 600528/0275 581015/9327 600528/0275 450205/3419

stav 100000 100000 50000 150000

pobočka Jánská Jánská Palackého Palackého

jmění 10000000 10000000 5000000 5000000

• Cíle návrhu vyvarování se problémů špatného návrhu splnění dalších kritérií, především výkonnostních (nevytvářet zbytečné tabulky!) • Pravidla transformace Odstranění složených a vícehodnotových atributů (převod do 1NF) Složený atribut → několik jednoduchých (složky) Klient <> č_klienta jméno adresa telefon

Klient <> č_klienta jméno ulice město PSČ telefon


33

Vícehodnotový atribut → slabá entitní množina nebo náhrada pevným počtem opakování

Klient

Klient

<> č_klienta jméno adresa {telefon}

<> č_klienta jméno adresa telefon [3]

Klient <> č_klienta jméno adresa

<> č_klienta jméno adresa telefon1 telefon2 telefon3

<<weak>>

<> 1

Klient

Telefon * <> pořČíslo telČíslo

- případně lze provést transformaci a potom normalizovat Reprezentace silné entitní množiny E <>a1

TE a1

a2

…

an

a2 … an J. Zendulka: Databázové systémy a návrh databází – 2 Konceptuální modelování a návrh databáze

34

Reprezentace vztahů E1 <>a11

a12 … a1n

E2 1 R 1 aR1 aR2 … aRk

<>a21

a22 … a2m

E1

E2

<>a11

<>a21

a12 … a1n

1 R * aR1 aR2 … aRk

E1 <>a11

a12 … a1n

a22 … a2m

E2 * R * aR1 aR2 … aRk

<>a21

a22 … a2m

TE1 a11 a12

…

a1n

…

a2m a11 aR1 aR2

…

a1n

…

a2m a11 aR1 aR2

TE2 a21 a22

…

aRk

TE1 a11 a12 TE2 a21 a22 TE1 a11 a12

…

aRk

TE2 …

a1n

a21 a22

…

a2m

TR a11 a21 aR1 aR2


…

aRk

35

Reprezentace slabé entitní množiny - jako silné + vztah 1:M <<weak>>

E1 <>a11

a12 … a1n

E2 <> <>a21 a22 * 1 … a2m


TE1

a11 a12

…

a1n a11

…

a2m a11

TE2

a21 a22

36

Př) Ilustrační příklad - Spořitelna

Klient <> r_číslo jméno ulice město

vlastní

<> č_účtu 1..* stav

1

veden

Účet 1 *

Pobočka <> název 1 jmění

*

<>

<<weak>>

Transakce <> č_transakce datum částka

Klient r_číslo Účet č_účtu

jméno ulice město

stav

Transakce č_transakce

r_číslo č_účtu

Pobočka název jmění

pobočka datum částka


37

Reprezentace ternárních vztahů Programátor

0..*

používá

<>osČíslo

1..* Jazyk <>název

Projekt

0..*

<>čísloProj

Programátor osČíslo Používá

osČíslo

Jazyk název název

Projekt čísloProj čísloProj

Generalizace/specializace - Možnosti: tabulka pro nadtyp + pro podtypy s primárním klíčem nadtypu pouze tabulky pro podtypy i s atributy nadtypu všechno v jedné tabulce - rozlišení podle prázdné hodnoty nebo tzv. diskriminátoru.


38

Př)

Účet <> č_účtu dat_zřízení stav

Běžný účet penále

-

1) Účet(č_účtu, dat_zřízení, stav), Běžný_účet(č_účtu, penále), Spoření(č_účtu, úrok) 2) Běžný_účet(č_účtu, dat_zřízení, stav, penále), Spoření(č_účtu, dat_zřízení, stav, úrok)

Spoření

3) Účet(č_účtu, dat_zřízení, stav, úrok, úrok penále) resp. Účet(č_účtu, dat_zřízení, stav, typ, úrok, penále). Nutno přihlížet zejména k tomu: zda jsou specializace disjunktní, zda je specializace totální, operace s jakými daty (jen specializace nebo i generalizace) budou prováděny.


39

2.5. Transformace objektového modelu (diagramu tříd) Modelování objektové struktury (diagram tříd)

Další modely (použití, interakce, …)

Logické schéma tabulky, integritní omezení

Databázové objekty

indexy, uložené procedury, triggery, … (serverová část)


Kód aplikace (klient)

40

• Problémy: operace - při návrhu tabulek neuvažujeme (bereme v úvahu při případné optimalizaci, návrhu uložených procedur apod.) identifikace pomocí OID - neexistuje-li atribut s vlastnostmi identifikátoru → přidat složené, složité, vícehodnotové atributy - viz normalizace u ER modelu, podpora typů proměnné délky v moderních relačních systémech (VARCHAR, BIT VARYING (BLOB)), generalizace/specializace agregace – „část“ jako silná nebo slabá entitní množina kompozice(zanořené objekty) - viz složené a vícehodnotové atributy


41

Př) Přednáška

Předmět

Učitel -jméno -příjmení -titul

učí *

*

*

-název -rozsah -kredity

*

+ZměňDatum(novéDatum)

+ZměňRozsah() +UkažPřednášky() +PřidejPřednášku(datum, téma)

+ZměňPříjmení() +ZměňTitul()

*

ExterníUčitel -pracoviště -adresa

InterníUčitel

* 1

pracoviště

Ústav -zkratka -název


-datum -téma -slajdy

Učebnice -název -autoři -vydavatel -rok -ISBN -titulníStrana

42

Literatura 1. Silberschatz, A., Korth H.F, Sudarshan, S.:Database System Concepts. Fourth Edition. McGRAW-HILL. 2001, str. 27 – 77. 2. T. Hawryszkiewycz, I.T.: Relational Database Design. An Introduction.Prentice Hall Inc. 1990. str. 85 – 152. 3. Batini, C., Ceri, S., Navathe, S., B.: Conceptual Database Design. Benjamin/ Cummings. 1992. s. 460. 4. Pokorný, J.: Databazová abeceda. Science, Veletiny, 1998, str. 73 – 76, 191 – 196.


43

2 Konceptuální modelování a návrh databáze

Recommend Documents