Konceptuální modelování. Pavel Tyl

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ň

DFD n-tá úroveň ERA diagram

Specifikace procesů Definice všech datových prvků

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

Datový tok

1 Název

Název

Terminátor

Úložiště dat

Název

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

Dílna Objednávka

Žádanka

Dodací list

Výdejka Sklad

Přehled spotřeby Management

Další úrovně rozkladu – Sklad Žádanka

Objednávka

Výdejka Výdej materiálu

Objednávání Materiál Mat. dodavatel

Zásoba mat. Databáze

Mat. Příjem materiálu

Sklad. zásoby 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,… Normalizace Normalizované schéma Osoba (rč,jméno,příjmení,…) Vzdelani (název,…) 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,…) Normalizace Normalizované schéma Produkt (nazev) Lokalita (nazev,misto,parametry,…) 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

Audi Pavla Škoda

Jana Řídí Audi Pavla

Karel BMW Jana

Škoda

BMW

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ň A

1

1

R

1 C

B

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 MA_NA_PROGRAMU F. X. Šaldy

Donaha

Naivní

Kolotoč

Malé

Prkno

Mánesovo

Želivka

Sokolské

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 MA_NA_PROGRAMU

●

●

●

F. X. Šaldy

Donaha

Naivní

Kolotoč

Malé

Prkno

Mánesovo

Želivka

Sokolské

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 MA_NA_PROGRAMU F. X. Šaldy

Donaha

Naivní

Kolotoč

Malé

Prkno

Mánesovo

Želivka

Sokolské

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 ●

Vztah

Atribut vztahu

Stavební prvky ER

Atribut entity Jméno RC

Od Plat

Zaměstnanci

Primární klíč

Pracuje_V

Entita

KO

Nazev

Oddělení

Kardinalita v ER 1 Zaměstnanci

Pracuje_V

1 Zaměstnanci

Pracuje_V

M Zaměstnanci

Pracuje_V

0..* Oddělení

N Oddělení

N Oddělení

Ternární vztahy A

1

1

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 A

1

1

R

B

N C ●

Determinantem je C

●

Každé entitě C je přiřazena entita A a B

Ternární vztahy A

M

N

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 A

M

N

R

O C ●

Není žádný determinant

B

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 Film

●

●

●

Má

CK

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: Jméno

RC

Cena Plat

Zaměstnanci

Pojistka

Pnázev

Věk

Pokrytí