1
Slezská univerzita v Opavě, FPF Podklady k přednáškám
Studijní obor: IVT Ročník: IV.
Vyučující: dr. Dušan Kajzar Školní rok: 2020/2021
Obsah:
1. Diagram datových toků (DFD)............................................................................ 2
2. Datový model (ERD)........................................................................................... 7
3. Datový slovník (Data Dictionary - DD) ............................................................ 14
Opakování - „Modely strukturovaného přístupu ...“
Předmět: Projektování IS
Téma: Strukturovaný přístup k vývoji IS (část B)
Datový model (Entity Relationship
Diagram - ERD)
Diagram datových toků
(Data Flow Diagram - DFD)
Kontextový diagram (KD)
Stavový diagram (model řízení)
(State Transition Diagram - STD)
Diagram struktury programového
systému (Structure Chart - SCH)
Diagram funkční struktury systému
(Function Structure Diagram - FSD)
Statické modely IS
Modely dynamiky systému
Datový slovník (Data Dictionary)
Výchozí modely
Seznam událostí (SU)
2
1. Diagram datových toků (DFD)
Účel modelu:
 zobrazit dynamický pohled na vyvíjený IS
o procesy zpracovávající data,
o datové toky mezi jednotlivými procesy,
 znázornění
o interních procesů v systému,
o datových toků mezi procesy,
o vstupních a výstupních datových toků vzhledem k systému.
Grafické znaky - viz obrázek:
 procesy, datové toky (Data Flow), úložiště dat (Data Store),
 externí entity (terminátory).
Ukázka (fragment) diagramu datových toků - výběr z účtu:
Poznámka – co DFD nezobrazuje:
 časovou návaznost mezi procesy resp. datovými toky,
 tj. nevidíme zde pořadí datových toků a procesů,
 zobrazená vazba mezi procesy je čistě datová, nikoliv časová.
výběr peněz
požadavek
výběru
Klient účetní doklad
účetní
doklad do
archivu
příkaz k aktualizaci
prověření
stavu účtu
1
Ověření
účtu
2
Aktualizace
účtu
Archiv dokladů
Účty
aktualizace
stavu účtu
3
Bližší vysvětlení DFD:
 vlastnosti procesů
o hierarchické číslování,
o vhodné pojmenování,
o procesy datové a řídicí,
 vlastnosti datových toků,
o data v pohybu (pohyb informací, materiálu, peněz, ...),
o abstrakce od konkrétního způsobu přenosu dat,
o datový tok do úložiště (insert, update, delete),
o datový tok z úložiště (select),
 vlastnosti datových úložišť
o množina dat „v klidu“,
o abstrakce od konkrétního způsobu uložení dat,
o data podniku + pracovní data (mezivýsledky),
o pozor „pasivní prvek“ – práce s daty vždy vykonává proces,
 vlastnosti externích entit
o prvky mimo náš vyvíjený systém,
o důležité pro tvorbu rozhraní „systém – okolí“,
o vazby mezi externími entitami – nás již nezajímají.
Hierarchie DFD:
 zcela na vrcholu – Kontextový diagram,
KD
IS
4
 nejhrubší úroveň zobrazení DFD – základní, nultá
o vidíme hlavní subsystémy a vazby mezi nimi,
o na dané úrovni - doporučeno zobrazit 3-9 subsystémů,
o hierarchické číslování procesů,
 zobrazení na vyšších rozlišovacích úrovních
o pohled na dekomponovanou část „zvětšovacím sklem“,
 postupná dekompozice (rozklad)
o procesů,
o datových toků,
o datových úložišť,
 zobrazení datových toků a úložišť
o datové toky a úložiště jsou „ukryté“ v procesech,
o viditelné až při rozpracování procesu na dané úrovni podrobnosti,
 dbát na konzistenci mezi úrovněmi zobrazení,
 rozklad až na tzv. „elementární procesy“ (viz dále)
o dostatečná podrobnost pro implementaci.
DFD - 0
DFD - 1
5
Poznámky k zobrazení DFD:
 formální požadavky
o např. „hlavička“ modelu (technického výkresu),
 zobrazení procesů
o účelnost (užitečnost) zobrazovaných procesů,
o estetický vzhled diagramů,
o procesy vs. datové toky,
 zobrazení datových úložišť
o datová úložiště vs. datové toky,
o atributy datových toků a úložišť.
Řídicí proces:
 umožňuje vnést pohled návaznosti (posloupnosti) procesů a datových
toků,
 řídicí pokyny, impulsy, události
o zahájení, ukončení datových procesů,
 doporučení - max. jeden řídicí proces v systému
o je-li jich více – koordinovat jejich součinnost,
 úložiště událostí - Event Store,
 rozpracování algoritmu řídicího procesu v STD
o v různých stavech systém generuje řídicí impulsy.
DFD – n (detaily)
Control
6
Elementární procesy:
 kdy proces považujeme za „elementární“?,
 popis elementárního procesu
o tzv. minispecifikace (Process specification),
o „hrubý“ algoritmus procesu, nejde o program (!),
 jazykové prostředky pro popis minispecifikací
o vstupy, výstupy, sekvence, větvení, cyklus,
o speciální strukturovaný jazyk,
o vývojový diagram,
 srozumitelnost popisu
o pro analytika, programátora, uživatele,
o Proč pro uživatele?
Výsledek tvorby DFD:
 hierarchie dílčích modelů vyvíjeného IS.
Úzká souvislost DFD s jinými modely:
 souvislost s KD a SU,
 souvislost s ERD (viz dále),
 souvislost s STD (viz dále),
 souvislost s SCH (viz dále),
 souvislost s Data Dictionary (slovní popis prvků).
Rozdíl mezi DFD a FSD:
 FSD – statický pohled, hierarchická struktura subsystémů,
 DFD – dynamický pohled, procesy zpracování dat a datové toky mezi
procesy.
ProcesVstupy Výstupy
EL
7
Poznámka – souvislost s modely OOP:
 v OOP (UML 2.0) nemá přímo odpovídající model
o do jisté míry lze nahradit Activity diagramem,
 v UML 2.5 byl doplněn Information Flow Diagram.
2. Datový model (ERD)
Účel modelu:
 zobrazit strukturu dat vyvíjeného IS,
 entity, atributy entit, relace mezi množinami entit.
Pojmy známé z předmětu „Databázové systémy“:
 entita, atributy entity, množina entit,
 primární klíč, cizí klíč, alternativní klíč,
 jednoduchý a složený klíč, nejednoznačný klíč.
Vazby mezi množinami entit:
 stupeň vazby (unární, binární, ...),
 kardinalita (násobnost, 1:M),
 volitelnost (vazba povinná, volitelná).
Binární relace:
 obrázek - vazba množin entit přes cizí klíč "číslo pracoviště".
Osobní číslo
Příjmení
Číslo pracoviště
.....
Číslo pracoviště
Název pracoviště
.....
Atributy množiny entit "zaměstnanci" Atributy množiny entit "pracoviště"
8
Unární relace:
Kardinalita (násobnost) relace:
Povinnost a volitelnost relace:
být podřízeným vedoucího
Osobní číslo
Příjmení
Číslo pracoviště
.....
Osobní číslo vedoucího
....
1 vlastnit 1zaměstnanci pracovní průkazy
1 vlastnit N
zaměstnanci pracovní pomůcky
N pracuje 1
zaměstnanci pracoviště
M používá N
zaměstnanci pracovní nástroje
M napsat N
autoři knihy
1 používat Nzaměstnanci ochranné pomůcky
1 vlastnit 1zaměstnanci pracovní průkazy
9
Generalizace a specializace množin entit:
 např. hlavní karta a podkarty investičního majetku.
Ukázka datového modelu:
 databáze CMDB (Configuration Management DB),
 poznámka - použití Sybase Power Designer Viewer.
investiční majetek
budovy stroje a zařízení software pozemky
10
Rámcový postup tvorby ERD:
1) výběr nejdůležitějších množin entit
o např. zaměstnanec, pracoviště, útvary, povolání, mzdové složky, atd.,
2) určení základních atributů jednotlivých množin entit,
o např. zaměstnanec – ID, jméno, příjmení, dat. narození, dat. nástupu, ...
3) určení primárního klíče jednotlivých množin entit,
4) průběžné zakreslování množin entit a vazeb do ERD,
5) vyhledávání vazeb (relací) mezi množinami entit,
6) doplňování dalších prvků do modelu
o doplňování dalších entit,
o doplňování dalších atributů,
7) určování kardinality a volitelnosti vazeb,
8) průběžná revize modelu, např.
o odstranění nadbytečných množin entit a atributů,
o odstranění zbytečných vztahů mezi entitami,
9) normalizace datového modelu,
10) stanovení omezujících podmínek pro hodnoty atributů
o integritní omezení,
11) kompletace hierarchie množin entit
o generalizace a specializace, nadřízené a podřízené entity,
12) důkladné ověření úplnosti datového modelu,
13) doplňování a úpravy modelu na základě ověřování úplnosti.
Opakování z předmětu „Databázové systémy“:
 normalizace modelu:
o 1. NF - každý sloupec obsahuje atomické hodnoty,
o 2. NF - 1. NF + každá neklíčová položka závisí na celém klíči,
o 3. NF - 2. NF + neklíčová položka nezávisí na jiné neklíčové položce,
o proces normalizace a denormalizace,
 integrita dat (celistvost, ucelenost, neporušenost):
o integrita entity,
o doménová integrita,
o referenční integrita.
11
Ověření úplnosti datového modelu (!):
 Řeší model všechny potřebné úkony a SQL dotazy nad daty IS?
 např. Jak zaeviduji ... ?
o že daná virtuální IP adresa balancuje nad několika logickými IP,
o že logické IP adresy mohou migrovat mezi uzly v clusteru,
o že logická IP adresa se váže k daným fyzickým IP adresám,
o zachycení více síťových interfaces v serveru, IP multipathing, ...
o apod.
 např. „Jak vypíši ... ?“
o všechny servery s končící dobou supportu k 31.12. v lokalitě Vítkov,
o všechny db systémy Oracle a jejich licenční pokrytí,
o všechny servery Linux, jejich umístění v serverovně a racku,
tříděné podle účelu serveru (databázový, aplikační, ...),
o na kterých db serverech pracuje aplikace „platební styk“, včetně jejich
umístění v lokalitě, serverovně, racku, odpovědný správce, ...
o ve kterých verzích provozujeme db Sybase, kdo tyto systémy spravuje a
kde jsou instalační média jednotlivých verzí,
o které systémy budou nepřístupné po výpadku switche AX254,
o přehled virtuálních IP adres a systémů, ke kterým se vztahují,
o atd.
Příklady otázek, které je nutno řešit během tvorby ERD:
Nebylo by vhodnější
rozdělit danou množinu
entit (horizontálně,
vertikálně) na několik
dílčích množin entit?
Jaké budou atributy
jednotlivých množin
entit?
Kolik bude k jednotlivým
množinám entit příslušet
klíčů?
Které množiny entit
se budou v systému
vyskytovat?
Jaké máme zvolit
primární klíče
jednotlivých množin
entit?
12
Poznámka ke kvalitě návrhu DB modelu:
 návrh datového modelu by měl garantovat „zkušený“ návrhář,
 nevhodný návrh DB
o v praxi častou příčinou výkonnostních problémů IS,
 často se návrh ukáže nevhodný až po jisté době rutinního provozu
o např. po zaplnění velkými objemy dat,
o po doplnění další funkcionality systému (problém zamykání zdrojů),
o tj. změní se provozní podmínky, pro které byl vytvořen (nemusí jít přímo
o chybu návrháře),
 ladění výkonnosti IS
o může vést k potřebě upravit datový model,
 úpravy datového modelu u IS v rutinním provozu
o provozně náročné akce,
o v databázi jsou již velké objemy dat (např. stovky GB, ...),
o jak transformovat data do nové struktury?
o kde aspoň dočasně alokovat diskový prostor (diskové pole je zaplněné)?
o jak se vejít do provozně akceptovatelné doby odstávky systému?
o apod.
Bylo by vhodné databázový
model účelově
denormalizovat?
Které množiny entit budou
obsahovat relativně stálá data,
které pak data rychle
se měnící?
Které množiny entit budou
obsahovat data charakteru
číselníků?
Na implementační úrovni:
Jakým způsobem
zajistíme požadovanou
bezpečnost systému ?
Jakým způsobem
zajistíme aplikační
logiku (uložené
procedury, triggers)?
Jakým způsobem
zajistíme integritu dat
(použitím constraints,
triggers)?
Je DB model
dostatečně
normalizovaný
(ve 3. NF)?
13
Iterativní způsob tvorby modelu:
 datový model na konceptuální úrovni zobrazení,
 datový model na technologické (logické) úrovni zobrazení,
 datový model na implementační (fyzické) úrovni zobrazení.
Transformace zobrazení v ERD:
Souběžná tvorba ERD a DFD:
 paralelní vývoj a vzájemné doplňování modelů,
 iterativní postup.
Úzká souvislost ERD s jinými modely:
 souvislost s DFD,
 souvislost s SCH (viz dále),
 souvislost s Data Dictionary (slovní popis prvků).
Poznámka – souvislost s modely OOP:
 diagram tříd – Class diagram.
 ERD je nutný, pokud IS má mít relační databázi,
 + zpracování návrhu tzv. objektově relačního mapování.
technologická (logická) úroveň implementační (fyzická) úroveň
množiny entit
atributy
vazby (relace) mezi entitami
integritní omezení
klíče
databázové tabulky
sloupce databázových tabulek
reference constraints
DT, defaults, check constraints,
indexy db tabulek
14
3. Datový slovník (Data Dictionary - DD)
Účel modelu:
 popis prvků, které se v modelech IS vyskytují,
 významový slovník pojmů (prvků) v modelech IS,
 grafické modely IS jsou názorné, ale rovněž je potřebný popis.
Struktura popisu prvku:
 jednoznačný identifikátor prvku,
 význam prvku v rámci vyvíjeného IS,
 popis struktury prvku (složení z elementárních prvků),
 formát prvku a přípustné hodnoty.
Například:
 Objednávka .... vysvětlení významu,
 Objednávka .... popis struktury prvku,
 Objednávka = Hlavička objednávky + Tělo objednávky,
 Hlavička objednávky = Číslo obj. + ID zákazníka + Datum vystavení obj.,
 Číslo obj. = ABCXXXX, kde A= ...., B= ...., C= ....., XXXX= .....,
 atd.
Poznámky ke tvorbě DD:
 popisované prvky musí mít jednoznačné identifikátory,
 elementární prvky - charakterizuje typ dat a množina povolených hodnot,
 složené položky - popsat odkazem na elementární prvky,
 nutno dbát - na minimální redundanci informací v DD.
Použití CASE nástroje:
 ke tvorbě DD nás vede CASE nástroj,
 průběžně vede k zadávání údajů a jejich popisů,
 DD je pak součástí repository (tj. databáze) použitého CASE.