Konceptuální modelování Pavel Tyl 21. 3. 2013
Vytváření IS
Vytváření IS Analýza Návrh Implementace Testování Předání Jednotlivé fáze mezi sebou iterují
Proč modelovat a analyzovat? Standardizované pracovní postupy Snadnější komunikace v týmu Aktuální a kompletní dokumentace
Fáze návrhu databáze
Analýza Funkční analýza DFD Data Flow Diagram Datová analýza ER Model Entity Relationship Model ERD Entity Relationship Diagram základy zformuloval Peter Chen v roce 1976, mnohostranný vývoj hovoříme o rodině ER modelů
Vztah ER a DFD Kontextový diagram DFD 1. úroveň ERA diagram DFD n-tá úroveň Definice všech datových prvků Specifikace procesů popis všech funkcí s uvedením na datové prvky a s popisem podmínek vykonání funkcí
Funkční analýza Identifikace systémových funkcí Identifikace událostí Definice transakcí Popis transakcí
DFD Data Flow Diagram Stavební prvky DFD Proces 1 Název Terminátor Název Datový tok Název Úložiště dat Název
DFD Top-Down postup Používáme postup shora dolů Úrovně: 1. Kontextový diagram informace o tom, jak bude IS komunikovat se zbytkem světa 2. N. další postupné rozklady (maximální doporučená hodnota N je 3) Je vhodné dodržovat jmennou konvenci
Chyby DFD Datová úložiště, ze kterých se pouze čte nebo se do nich pouze zapisuje Samogenerující funkce funkce, které mají jenom výstupy Černé díry funkce, do nichž data pouze vstupují Nepojmenované datové toky
Seznam událostí p. č. Název události Typ Reakce systému 1 Dílna žádá materiál Data Vyhledá materiál, vystaví výdejku 2 Sklad nemá dostatek materiálu Řídící Vystaví objednávku 3 Dodavatel dodá materiál Data Přijme materiál, potvrdí dodací list 4 Je první den v měsíci Řídící datum Vytvoří přehled o spotřebě
Jednoduchý příklad kontextového diagramu Dodavatel Dílna Sklad Management
Upřesněný příklad kontextového diagramu Dodavatel Objednávka Žádanka Dílna Dodací list Výdejka Sklad Přehled spotřeby Management
Další úrovně rozkladu Sklad Objednávka Žádanka Výdejka Objednávání Mat. dodavatel Mat. Databáze Materiál Zásoba mat. Sklad. zásoby Výdej materiálu Příjem materiálu Tvorba přehledů Přehled spotřeby
Chyby DFD Datová úložiště, ze kterých se pouze čte nebo se do nich pouze zapisuje Samogenerující funkce funkce, které mají jenom výstupy Černé díry funkce, do nichž data pouze vstupují Nepojmenované datové toky
ER model Cílem je vytvořit datový model postihující určitou část reálného světa Svět je chápán jako zjednodušená množina objektů (entit) a vztahů mezi nimi říkáme jí ER diagram ERA diagram ještě přidává atributy Vytváříme jím konceptuální schéma
Postup návrhu databáze Entitní množiny a vztahy Prvotní schéma Osoba (rč,jméno,příjmení,vzdělání, děti, Normalizované schéma Osoba (rč,jméno,příjmení, ) Vzdelani (název, ) Normalizace Návrh fyzické organizace db (indexy, tabulkové prostory, Vytvoření databázových objektů CREATE TABLE Osoba (rč int not null, Jméno varchar(15) NULL, CREATE INDEX irc on Osoba
Postup návrhu databáze Entitní množiny a vztahy Prvotní schéma Produkt (nazev,lokalita,parametry, ) Normalizované schéma Produkt (nazev) Lokalita (nazev,misto,parametry, ) Normalizace Návrh fyzické organizace databáze (indexy, tabulkové prostory, Vytvoření databázových objektů CREATE TABLE Produkt (nazev varchar(15) NULL, CREATE INDEX inazev on Produkt
Primitiva ERD Entita (reálná nebo imaginární část světa) věc, která nás zajímá a ke které chceme sbírat data např. řidič s řidičským průkazem č. 87A73, auto s SPZ 3A4 4536, Entitní množina množina entit téhož typu, které sdílí stejné vlastnosti či atributy např. Řidič, Auto,...
Primitiva ERD Atributy vlastnost entity, která nás v daném kontextu zajímá a jejíž hodnotu chceme mít v DB uloženu např. Jméno, příjmení, SPZ, Doména atributu seznam přípustných hodnot
Primitiva ERD Vztahy mezi entitami asociace mezi entitami např. řidič s řp. č. 23456 řídí vozidlo s SPZ 3A3 6456 Atributy vztahů Parcialita vztahu Kardinalita vztahu (1:1, 1:N, M:N)
Řidič Auto Karel Pavla Jana Řídí Audi Škoda BMW Pavla Audi Jana BMW Škoda Karel
Atributy Jednoduché (Datum, Jméno) Kompozitní (Složené) např. Adresa=(Ulice, Č_domu, Č_orientační, PSČ)
Atributy Vícehodnotové např. Vzdělání={základní, středoškolské, vysokoškolské}
NULL atributy Atributy povolující prázdnou hodnotu Hodnota chybí např. datum narození hodnota existuje, ale není nám známa Hodnota neexistuje např. číslo bytu nevím, jestli hodnota vůbec existuje
Integritní omezení Schéma relace R(A, D, IO) Kardinalita vztahu Členství ve vztahu Slabé entitní typy
Vztahy mezi entitami Vyjadřuje souvislost (vztah, závislost) mezi entitami název je sloveso, obvykle je možné dvojí čtení (jazyková, NE konceptuální záležitost!) např. má, náleží, je členem, obsahuje
Vztahy mezi entitami Jméno vztahové množiny, jméno role vyjadřuje význam vztahu Stupeň 1 1 A R B C 1
Kardinalita vztahu Předpokládejme vztah MA_NA PROGRAMU mezi entitami DIVADLO a PROGRAM Obecně tento vztah může být kardinality: 0:0 1:1 1:N M:N
Vztah 1:1 F. X. Šaldy Naivní Malé Mánesovo Sokolské MA_NA_PROGRAMU Donaha Kolotoč Prkno Želivka Labutě Dané divadlo má na programu maximálně jednu hru Daná hra se hraje v maximálně jednom divadle Obecně lze uvažovat i tzv. částečné vztahy 1:0 a 0:1
Vztah 1:N F. X. Šaldy Naivní Malé Mánesovo Sokolské MA_NA_PROGRAMU Donaha Kolotoč Prkno Želivka Labutě Dané divadlo může mít na programu více než jen jednu hru Daná hra je na programu maximálně v jednom divadle Je důležitý směr, neboť je rozdíl jednomu divadlu více her a jedné hře více divadel
Vztah M:N F. X. Šaldy Naivní Malé Mánesovo Sokolské MA_NA_PROGRAMU Donaha Kolotoč Prkno Želivka Labutě Dané divadlo může mít na programu více her Daná hra je na programu ve více divadlech
ER Entity Relationship Model Stavební prvky ER Atribut vztahu Vztah Atribut entity RC Jméno Plat Od KO Nazev Zaměstnanci Pracuje_V Oddělení Primární klíč Entita
Kardinalita v ER 1 0..* Zaměstnanci Pracuje_V Oddělení 1 N Zaměstnanci Pracuje_V Oddělení M N Zaměstnanci Pracuje_V Oddělení
Ternární vztahy 1 1 A R B 1 C Příklad obsahuje tři determinanty A, B, C Determinant: entita jednoho typu jednoznačně určuje entitu druhého typu (entita determinuje entity druhého typu)
Ternární vztahy 1 1 A R B N C Determinantem je C Každé entitě C je přiřazena entita A a B
Ternární vztahy M N A R B 1 C Determinantem je dvojice typů entit A, B Pro každé dvě entity typů A, resp. B je jednoznačně určena entita typu C
Ternární vztahy M N A R B O C Není žádný determinant
Integritní omezení Schéma relace R(A, D, IO) Kardinalita vztahu Členství ve vztahu Slabé entitní typy
Členství ve vztahu Organizační pravidla mohou určovat, jak se budou entity vyskytovat ve vztahu každý výskyt entity musí být ve vztahu zapojen některé výskyty entity se mohou vyskytovat i mimo vztah
Členství ve vztahu Zaměstnanci Pracuje_V Oddělení
Členství ve vztahu Zaměstnanci Pracuje_V Oddělení Čteme: Zaměstnanec musí pracovat v nějakém oddělení, ale oddělení nemusí mít žádné zaměstnance V entitě oddělení musí existovat alespoň jeden záznam příslušný k entitě zaměstnanci
Členství ve vztahu Zaměstnanci Pracuje_V Oddělení Zaměstnanec == povinné členství (všechny entity typu Zaměstnanec musí být zapojeny ve vztahu) Oddělení == nepovinné členství
Členství ve vztahu Zaměstnanci Pracuje_V Oddělení Zaměstnanec == povinné členství (všechny entity typu Zaměstnanec musí být zapojeny ve vztahu) Oddělení == nepovinné členství
Členství ve vztahu Zaměstnanci Pracuje_V Oddělení
Členství ve vztahu Zaměstnanci Pracuje_V Oddělení Zaměstnanec musí pracovat v nějakém oddělení Oddělení musí mít alespoň jednoho zaměstnance
Členství ve vztahu Zaměstnanci Pracuje_V Oddělení
Členství ve vztahu Zaměstnanci Pracuje_V Oddělení Zaměstnanec nemusí pracovat v žádném oddělení Oddělení nemusí mít žádné zaměstnance Zaměstnanec == nepovinné členství Oddělení == nepovinné členství
Integritní omezení Schéma relace R(A, D, IO) Kardinalita vztahu Členství ve vztahu Slabé entitní typy
Slabé entitní typy Jedná se o rozšíření klasického ER modelu Pokud nebudou součástí klíče entity pouze její vlastní atributy, ale i atributy jiných entit, mluvíme o tzv. slabém entitním typu Opakem jsou silné entitní typy Pokud tedy máme slabou entitu, nelze její instance rozlišit pouze podle vlastních atributů
Identifikační vlastník Řešení: instance lze identifikovat pomocí toho, že jsou v povinném vztahu k jinému entitnímu typu Takovému typu se říká identifikační vlastník Typ vztahu spojující slabý entitní typ s jeho identifikačním vlastníkem nazýváme identifikační vztah
JMENO Identifikační vlastník CK Film Má Kopie Film má několik kopií, z nichž každá je označena číslem od 1 do počtu kopií Máme-li v evidenci více filmů a jejich kopie, může se stát, že bude mít více entit typu Kopie stejné číslo kopie (budou to kopie jiných filmů) Jaké je řešení?
Identifikační vlastník Musíme rozšířit klíč entity Kopie i o primární klíč entity Film Pak tedy PK entity kopie bude dvojice (JMENO, CK) Jinými slovy nemůže nastat stav, že budou existovat dvě kopie stejného filmu se stejným číslem kopie
Identifikační vlastník Další příklad: RC Jméno Cena Plat Pnázev Věk Zaměstnanci Pojistka Pokrytí