2 Konceptuální modelování a návrh databáze 2.. Ú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 2.. Ú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 Konceptuální schéma (ERD) Logický návrh Logické schéma (tabulky) Fyzický návrh Fyzické schéma (uložené záznamy, přístupové metody) J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 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 J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh 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 J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 4
Přístup k návrhu databáze: Entitní množiny (třídy) + vztahy Seznam atributů entit (objektů) + závislosti Transformace Normalizace Prvotní schéma (r_číslo,,, příjmení, č_účtu, stav, ) Normalizace Normalizované schéma relační databáze (r_číslo,, příjmení, ), (č_účtu, stav, ) Návrh fyzické organizace (tabulkové prostory, indexy, clustery, ) Vytvoření databázových objektů CREATE TABLE () CREATE INDEX I ON () 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). J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 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ř) banky s identifikačním číslem 999, účet s číslem účtu 00. Entitní množina - množina entit téhož typu, které sdílí tytéž vlastnosti neboli atributy. Př), J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 7 U00 U50 K999 K628 K23 U48 U79 vlastní U00 U50 U48 U79 K999 K628 K23 vlastní J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 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ř) : čísloa,, příjmení, adresa, Doména atributu - obor hodnot atributu. Vztah asociace mezi několika entitami. Př) s číslem klienta K999 vlastní účet s číslem účtu U00. Vztahová množina - množina vztahů téhož typu, které sdílí tytéž vlastnosti. Př) vlastní pro vztah mezi entitami typu a 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. J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 9 Typy atributů Jednoduché (simple) a složené (composite) atributy Př) Entitní množina Složené atributy adresa Složky křestní prostřední příjmení ulice město PSČ Složky číslo číslobytu J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 0
Jednohodnotové (single-valued) a vícehodnotové (multiplevalued) (někdy také opakující se atributy) Př) Entitní množina Vícehodnotový atribut telefon Hodnoty atributu číslo, čí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 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, role Vyjadřuje význam vztahu. Př) vztahové množiny role vlastník vlastní J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 2
Stupeň Př) Zaměstnanec vlastní nadřízený unární (reflexivní) binární Programátor používá Projekt ternární Jazyk J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 3 Kardinalita (cardinality) (maximální kardinalita), Maximální počet vztahů daného typu (vztahové množiny), ve kterých může participovat jedna entita (,M, případně přesněji). Př) Zaměstnanec nadřízený vlastní Programátor používá Projekt Jazyk J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 4
Č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é/ povinné), resp. účast entitní množiny ve vztahu (částečná (partial)/úplná (total)). Př) Zaměstnanec nadřízený 0.... vlastní 0.. Programátor 0.. používá 0.. Projekt.. Jazyk J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 5 Kardinalita i členství představují omezeni (constraint) Jiným důležitým typem omezení je existenční závislost. Př) (vlastník účtu) a Atributy vztahu čísloa adresa telefon 0.. disponuje 0.. čísloúčtu datumzřízení stav limit J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 6
Používané notace pro kreslení ER diagramu Název IČO Adresa Telefon Dodavatel M Dodává Zboží Název Číslo zboží Barva Dodavatel Dodává Zboží Dodavatel Dodavatel Dodavatel Dodává Je dodáváno Zboží Dodává Dodává Dodavatel Dodává Zboží 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 7 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 <<PK>> čísloúčtu datumzřízení stav 0.. <<identif>> vlastní <<weak>> Příkaz <<D>> pořčíslo typ částka datum identifikující dominantní (nezávislá) diskriminátor (dílčí identifikátor) slabá (závislá) J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 8
- identifikátor = identifikátor_dominantní + diskriminátor - existenční závislost slabé množiny na identifikující J. Zendulka: Databázové s ystémy a návrh databází 2 Konceptuální modelování a návrh databáze 9 Generalizace/specializace (ISA vztah) S2 S S3 B B2 << PK>> čísloúčtu datumzřízení stav S4 S5 B3 Spořitelní Běžný Spořitelní úrok 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šší J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 20
Omezení generalizace/specializace o příslušnost disjunktní/překrývající se o úplnost totální/částečná J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 2 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 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 vztahové množiny nebo role. čísloa adresa telefon vlastní disponuje čísloúčtu datumzřízení stav disponuje limit J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 22
Celkový systém by neměl být zahrnut do ERD Banka má 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) J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 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 <<PK>> rodnéčíslo <<PK>> IČO nevhodné Vozidlo <<PK>> poznznačka Firma <<PK>> IČO Osoba <<PK>> rodnéčíslo 0.. 0.. zaregistrovala zaregistrovala Vozidlo <<PK>> poznznačka vhodné další možnost - generalizace J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 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... (čísloa, čísloúčtu) disponuje (čísloa, čí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 <<PK>> výrčíslo barva? Automobil <<PK>> výrčíslo má Barva <<PK>> 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. J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 25 Atributy a vztahy :M zaregistrovala Osoba <<PK>> rodnéčíslo Vozidlo <<PK>> poznznačka datregistrace? Osoba <<PK>> rodnéčíslo Vozidlo <<PK>> poznznačka zaregistrovala datregistrace 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ě. J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 26
Náhrada vztahů M:M vazební entitní množinou <<PK>> čísloa adresa telefon <<PK>> čísloa adresa telefon 0.. disponuje.. disponuje limit Disponuje <<PK>> čísloa.. <<PK>> čísloúčtu 0.. limit <<PK>> čísloúčtu datumzřízení stav <<PK>> čísloúčtu datumzřízení stav - zpravidla před transformací na schéma relační databáze J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh 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 <<PK>> datum Zájezd 0.. <<weak> Zastávka <<D>> město <<identif>> Zájezd <<PK>> číslozájezdu datum 0.. <<weak>> Zastávka <<identif>> <<D>> číslozastávky 0.. v Město <<PK>> název J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 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 Dodavatel uzavřel <<PK>> IČO realizuje? <<identif>> <<weak>> Dodávka <<D>> pořčíslo Kontrakt <<PK>> KontraktID v rámci Vyvarování se redundance - slabá entitní množina má jen jednu identifikující množinu, se kterou je ve vztahu :M nelze takto modelovat vztahy M:M J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 29 Př) disponující <<identif>> <<weak>> Disponent ŠPATNĚ Slabá nebo silná entitní množina? Pravidlo: 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 <<PK>> čísloobjednávky položka[..] J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 30
Použití pro modelování časových změn Osoba <<PK>> rodnéčíslo Změny atributů Osoba <<PK>> rodnéčíslo Změny vztahů pracuje 0.. <<identif>> <<weak>> Vážení 0.. <<D>> pořčíslo datum váha Oddělení <<PK>> číslooddělení název Osoba <<PK>> rodnéčíslo 0.... Pracovala od do Oddělení <<PK>> číslooddělení název Osoba <<PK>> rodnéčíslo Oddělení <<PK>> číslooddělení název <<identif>>.. na 0.. <<weak>> Zařazení <<D>> pořčíslo od do J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 3 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) Kód aplikace (klient) 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 formálně BCNF, resp. 3NF J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 32
č_účtu r_číslo stav pobočka jmění 00 600528/0275 00000 Jánská 0000000 00 5805/9327 00000 Jánská 0000000 30 600528/0275 50000 Palackého 5000000 50 450205/349 50000 Palackého 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 NF) Složený atribut několik jednoduchých (složky) <<PK>> č_klienta adresa telefon <<PK>> č_klienta ulice město PSČ telefon J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 33 Vícehodnotový atribut slabá entitní množina nebo náhrada pevným počtem opakování <<PK>> č_klienta adresa {telefon} <<PK>> č_klienta adresa telefon [3] <<PK>> č_klienta adresa telefon telefon2 telefon3 <<PK>> č_klienta adresa <<identif>> <<weak>> Telefon <<D>> pořčíslo telčíslo - případně lze provést transformaci a potom normalizovat Reprezentace silné entitní množiny E <<PK>>a a2 an TE a a 2 a n J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 34
Reprezentace vztahů E <<PK>>a a 2 a n R a R a R2 a Rk E 2 <<PK>>a 2 a 22 a 2m TE a a 2 a n TE 2 a 2 a 22 a 2m a ar ar2 ark E <<PK>>a a 2 a n R a R a R2 a Rk E 2 <<PK>>a 2 a 22 a 2m TE a a 2 a n TE 2 a 2 a22 a 2m a ar ar2 ark E <<PK>>a a 2 a n R a R a R2 a Rk E 2 <<PK>> a 2 a 22 a 2m TE a a2 a n TR a a 2 TE 2 a R a R2 a Rk a 2 a22 a 2m J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 35 Reprezentace slabé entitní množiny - jako silné + vztah :M E <<PK>>a a 2 a n <<identif>> <<weak>> E 2 <<D>>a 2 a 22 a 2m TE a a2 a n a TE 2 a 2 a22 a 2m a J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 36
Př) Ilustrační příklad - Spořitelna <<PK>> r_číslo ulice město vlastní.. <<PK>> č_účtu stav <<identif>> veden Pobočka <<PK>> název jmění <<weak>> Transakce <<D>> č_transakce datum částka Pobočka r_číslo ulice město název jmění č_účtu stav r_číslo pobočka Transakce č_transakce č_účtu datum částka J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 37 Reprezentace ternárních vztahů Programátor <<PK >>osčíslo 0.. používá.. Jazyk 0.. Projekt <<PK>>čísloProj <<PK>>název Programátor Jazyk Projekt osčíslo název čísloproj Používá osčíslo název čí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. J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 38
Př) penále <<PK>> č_účtu dat_zřízení stav ) (č_úč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) Běžný účet Spoření 3) (č_účtu, dat_zřízení, stav, úrok, úrok penále) resp. (č_úč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. J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 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) J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 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 J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 4 Př) Učitel - -příjmení -titul +ZměňPříjmení() +ZměňTitul() učí Předmět -název -rozsah -kredity +ZměňRozsah() +UkažPřednášky() +PřidejPřednášku(datum, téma) Přednáška -datum -téma -slajdy +ZměňDatum(novéDatum) Učebnice ExterníUčitel -pracoviště -adresa InterníUčitel pracoviště Ústav -zkratka -název -název -autoři -vydavatel -rok -ISBN -titulnístrana J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 42
Literatura. Silberschatz, A., Korth H.F, Sudarshan, S.:Database System Concepts. Fourth Edition. McGRAW-HILL. 200, str. 27 77. 2. T. Hawryszkiewycz, I.T.: Relational Database Design. An Introduction.Prentice Hall Inc. 990. str. 85 52. 3. Batini, C., Ceri, S., Navathe, S., B.: Conceptual Database Design. Benjamin/ Cummings. 992. s. 460. 4. Pokorný, J.: Databazová abeceda. Science, Veletiny, 998, str. 73 76, 9 96. J. Zendulka: Databázové systémy a návrh databází 2 Konceptuální modelování a návrh databáze 43