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

Konceptuální modelování