Konceptuální modelování. Pavel Tyl

Transkript

1 Konceptuální modelování Pavel Tyl

2 Vytváření IS

3 Vytváření IS Analýza Návrh Implementace Testování Předání Jednotlivé fáze mezi sebou iterují

4 Proč modelovat a analyzovat? Standardizované pracovní postupy Snadnější komunikace v týmu Aktuální a kompletní dokumentace

5 Fáze návrhu databáze

6 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ů

7 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í

8 Funkční analýza Identifikace systémových funkcí Identifikace událostí Definice transakcí Popis transakcí

9 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

10 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

11 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

12 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ě

13 Jednoduchý příklad kontextového diagramu Dodavatel Dílna Sklad Management

14 Upřesněný příklad kontextového diagramu Dodavatel Objednávka Žádanka Dílna Dodací list Výdejka Sklad Přehled spotřeby Management

15 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

16 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

17 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

18 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

19 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

20 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,...

21 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

22 Primitiva ERD Vztahy mezi entitami asociace mezi entitami např. řidič s řp. č řídí vozidlo s SPZ 3A Atributy vztahů Parcialita vztahu Kardinalita vztahu (1:1, 1:N, M:N)

23 Řidič Auto Karel Pavla Jana Řídí Audi Škoda BMW Pavla Audi Jana BMW Škoda Karel

24 Atributy Jednoduché (Datum, Jméno) Kompozitní (Složené) např. Adresa=(Ulice, Č_domu, Č_orientační, PSČ)

25 Atributy Vícehodnotové např. Vzdělání={základní, středoškolské, vysokoškolské}

26 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

27 Integritní omezení Schéma relace R(A, D, IO) Kardinalita vztahu Členství ve vztahu Slabé entitní typy

28 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

29 Vztahy mezi entitami Jméno vztahové množiny, jméno role vyjadřuje význam vztahu Stupeň 1 1 A R B C 1

30 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

31 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

32 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

33 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

34 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

35 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í

36 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)

37 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

38 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

39 Ternární vztahy M N A R B O C Není žádný determinant

40 Integritní omezení Schéma relace R(A, D, IO) Kardinalita vztahu Členství ve vztahu Slabé entitní typy

41 Č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

42 Členství ve vztahu Zaměstnanci Pracuje_V Oddělení

43 Č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

44 Č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í

45 Č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í

46 Členství ve vztahu Zaměstnanci Pracuje_V Oddělení

47 Č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

48 Členství ve vztahu Zaměstnanci Pracuje_V Oddělení

49 Č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í

50 Integritní omezení Schéma relace R(A, D, IO) Kardinalita vztahu Členství ve vztahu Slabé entitní typy

51 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ů

52 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

53 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í?

54 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

55 Identifikační vlastník Další příklad: RC Jméno Cena Plat Pnázev Věk Zaměstnanci Pojistka Pokrytí