3 Modelování a návrh informačních systémů

2.1 Logická reprezentace dat informačních systémů

Model systému je zjednodušená reprezentace skutečného systému. Umožňuje snadnější orientaci,

zvýrazňuje podstatné a potlačuje nepodstatné funkce systému.

Pro snadnější pochopení vnitřních vazeb skutečného systému je nutno použít nástrojů strukturní

(strukturované) analýzy. K těmto nástrojům patří:

grafické modely;

strukturní diagramy;

vývojové diagramy;

pravdivostní tabulky;

stavové diagramy;

entitně-relační diagramy;

systémové diagramy a další.

Použití jednotlivých nástrojů závisí na konkrétních podmínkách a složitosti analyzovaného problému.

Nejčastěji používáme grafické zpracování modelů. Grafické vyjádření však musí doprovázet

i podpůrné textové informace. Z hlediska přehlednosti je vhodné modelovaný systém zobrazovat

v různých úrovních složitosti podle postupného hierarchického rozkladu shora doků.

2.2 Diagram datových toků

Diagram datových toků (DFD, Data Flow Diagram) patří k nejpoužívanějším nástrojům strukturované

analýzy informačních systémů. Zvýrazňuje funkční vlastnosti informačního systému. Systém zde

zobrazujeme jako síť procesů, představující místa transformace dat, zásobníků jako míst ukládání dat

- kartotéky, soubory- a externích entit, které reprezentují okolní prostředí systému. Tyto prvky

spojujeme pomocí datových toků. Pro grafické znázorňování DFD používáme grafické značky. Jejich

grafická podoba se liší podle jednotlivých autorů. Nejznámější podoby jsou v tabulce Tab. 2.1.

Externí entita

- někdy nazývána jako terminátor je prvek představující okolí modelu. Pomocí této entity

modelujeme vstupní a výstupní komunikaci okolí s modelem. Představuje obecný objekt, se kterým si

model vyměňuje zprávy.

Obsah takovéhoto datového prvku model nemůže ovlivnit. Datový tok, který jej spojuje s modelem

má stanovený obsah a model jej musí akceptovat.

Externí entita musí být spojena vstupně-výstupním datovým tokem s modelem. Pokud tomu tak není

je tato entita nadbytečná a je možno ji z modelu odstranit.

Tok dat

je prvek v diagramu znázorňovaný šipkou. Její směr udává směr toku dat. Každý datový tok musí být

pojmenován a je složený s elementárních datových prvků a jiných datových toků. Jeho konkrétní

obsah je definovaný v datovém slovníku, který je součásti DFD.

Datový tok propojuje zásobník s procesem, který obsah zásobníku edituje. Pokud je tok dat

obousměrný - probíhá dialog mezi zásobníkem a procesem - označuje se oboustrannou šipkou.

Různé datové toky mohou mít na různých místech modelu stejný obsah, ten však nezaručuje stejný

význam dat. Proto i takovéto toky musí být jednoznačně označeny i když se použije označení

zohledňující shodnost obsahu (rozdílnost významu).

Tab. 2.1: Značky pro vyjadřování DFD.

YORDON GANE - SARSON

Externí entita

Datový tok

Zásobník dat

Proces

Zásobník

je prvek představující místo pro uschování dat. Může se jednat o data trvalá ale i data periodicky či

nepravidelně občerstvovaná. Data v jednom zásobníku může využívat více procesů na různých

úrovních. Obecně tyto zásobníky nemusí být jen ve formě počítačové struktury, ale může se jednat

o zakladače dokladů, spisů, archiválií a pod.

Struktura a obsah zásobníku se definuje taktéž v datovém slovníku DFD. Pokud vstupující nebo

vystupující datový tok má stejnou strukturu jako související zásobník, nemusíme jej samostatně

pojmenovávat (ani definovat jeho strukturu – musí však být uveden v datovém slovníku alespoň

odkazem). Při sebemenší odlišnosti od struktury zásobníku však musíme tok pojmenovat a jeho

definici uvést ve slovníku.

Každý zásobník musí být spojen datovým tokem s nějakým procesem, nemůže stát v modelu

osamoceně. Tok ze zásobníku představuje čtení dat, tok do zásobníku představuje záznam. Obsah

informace je závislý na akci realizované procesem.

Proces

V DFD je proces znázorněn symbolem podle tabulky Tab. 2.1. Symbol obsahuje výstižný název pro

prováděnou transformaci dat. V případě, že budeme provádět další dekompozici, proces označíme

i strukturovaným číslem.

Diagram datových toků musí být graficky zpracovaný tak, aby byl přehledný. U složitých systémů

s mnoha vstupy a výstupy se DFD kreslí v několika úrovních. Jako první úroveň se konstruuje

kontextový diagram (konceptuální schéma), který celý systém zobrazuje jako jediný proces a s ním

všechny související externí entity. Kontextový diagram se pak dál rozpracovává v jednotlivých

úrovních. U běžných systémů se používá většinou DFD ve třech, max. ve čtyřech úrovních.

Při zobrazován zásobníků platí následující pravidlo: zobrazují se v nejvyšší úrovni DFD a na nižších

úrovních se jejich zobrazení opakuje jako duplikát (viz obrázek Obr.2.1.

Fyzické a logické diagramy

Velmi často se v počáteční fázi představ o informačním systému stává, že se do diagramu zahrnou

i fyzické objekty či procesy, které jsou ve finální podobě modelu nežádoucí. Takovémuto diagramu

říkáme fyzický diagram datových toků. Takovýto tvar usnadňuje pochopení toho, jak systém pracuje.

Diagram který neosahuje fyzické objekty a procesy se nazývá logický diagram datových toků. Ten

ilustruje to, co systém dělá.

Přechod od fyzického diagramu k logickému provedeme eliminací fyzické podstaty procesů, toků dat

a zásobníků.

Pravidla pro návrh diagramu datových toků

1. Každý zásobník nebo externí entita musí být napojena na proces. Nelze spojit terminátor se zásobníkem nebo zásobník s jiným zásobníkem. Zásobník je součástí modelu, proto jej nemůže ovlivňovat jiný externí systém. Pokud je to nutné, musí se tato editace realizovat jako připojení procesu s připojenou externí entitou. Pokud se jedná o prosté čtení, pak se tímto problémem nemusíme zabývat.

2. U zásobníku, ze kterého pouze vystupuje datový tok je nutno posoudit jeho funkčnost. Postup je regulérní, pokud se jedná o zásobník editovaný jiným systémem. Jinak se musí navrhnou proces, který provádí vlastní editaci údajů v zásobníku.

3. Data přenášená v systému společně mohou být znázorněna jedním datovým tokem. To v jistých situacích zvyšuje přehlednost diagramu. Např. Tok CESTUJÍCÍ je složen s toků DOSPĚLÍ a DĚTI. Názvy datových toků představují podstatná jména.

4. U každého procesu musíme vědět s jakými daty pracuje, proto všechny datové toky musí být jednoznačně pojmenované i v případě že přenášejí stejná data. Naopak, pokud proces nemění procházející data je zbytečný.

5. Do procesu vstupují jen ta data, která tento proces zpracovává.

6. Na každý proces musí navazovat v DFD minimálně jeden vstupní a jeden výstupní datový tok. Jinak vzniká černá díra - toky pouze vstupují nebo divutvorný proces - navazují pouze výstupní toky.

7. Každý proces provádí pokaždé stejnou úlohu. Možné výstupy jsou reprezentovány jeho výstupními toky. Jejich obsluha je daná algoritmem transformace.

8. Procesy na nejnižší úrovni musí provádět jednu přesně definovanou funkci. Složitost algoritmu závisí na stupni dekompozice. Čím větší je stupeň dekompozice, tím jednodušší je algoritmus, ale složitější diagram a opačně.

9. Procesy s jedním vstupním a jedním výstupním datovým tokem mohou, ale nemusí, být dále dekomponovány. Nutnost je závislá na složitosti realizované funkce. Tato řešení napovídají, že tento proces realizuje přesně definovanou funkci.

10. DFD nikdy nevyznačuje časovou závislost datových toků. Tyto a další informace se zaznamenávají v popisech datového slovníku a v popisech procesů.

Obr. 2.2: Rozklad systému včetně kontextového diagramu.

2.3 Datový slovník

Samostatný diagram datových toků ještě nestačí pro tvorbu informačního systému. Chybí přesný

a vyčerpávající popis dat a popis algoritmů jednotlivých transformací dat. Proto je nutno vytvořit

datový slovník, který popisnou formou tyto informace specifikuje.

2.3.1 Datové toky a zásobníky

V DFD se data realizují pomocí zásobníků dat a datových toků. Proto datový slovník popisuje datové

struktury a funkce těchto prvků. Lokální proměnné použité v algoritmech procesů se zde samostatně

neuvádějí.

V obou zmiňovaných prvcích se daty vyskytují ve formě tabulek (relací) a jiných záznamů v roli

subzáznamů. Můžeme říci že jeden datový tok se skládá z jiných datových toků a datových prvků.

Datový prvek je nejmenší - dále nedělitelná - významová jednotka dat. U relačních databází je touto

jednotkou položka (pole) záznamu.

2.2.2 Struktura datového slovníku

Pro přehlednost dokumentace datového slovníku je vhodné jej rozdělit na následující části:

1. Datové toky

2. Zásobníky dat

3. Datové prvky

4. Číselníky

Každá položka v datovém slovníku popisující datový tok nebo zásobník musí být určena:

identifikátorem; názvy prvků v datovém slovníku (identifikátory) volíme stručné a výstižné. V nich nepoužíváme znaky určené pro zvláštní účely (viz Tab. B.1, např.: \, ?, ! a další);

strukturou, obsahující substruktury a názvy položek, případně označení položky představující klíč symbolem @;

popisem, komentář musí být stručný a výstižný. V popisech se mohou objevit i popisy vazeb na okolní prvky DFD.

Pro definování datových prvků se uvádí:

identifikátor - musí být jedinečný výstižný a stručný. Maximální délka je daná zvyklostmi použitého nástroje pro tvorbu;

popis - představuje verbální popis údaje, jeho použití;

délka - uvádí povinně potřebný počet znaků pro každý prvek;

typ datového prvku - je povinný pro každý prvek, udává základní typ prvku: N = číselný, C = textový, D = datum, L = logický;.

interval přípustných hodnot - je-li potřebný uvádí se buď formou intervalu hodnot v případě reálných čísel nebo výčtem přípustných hodnot u textových položek (např. výčet možných titulů).

Je vhodné jednotlivé položky řadit v abecedním pořadí.

Datový slovník je vhodné definovat souběžně s tvorbou grafické části DFD, snižuje to riziko duplicity

identifikátorů a opakování položek!

2.3 Popis procesů

Z DFD poznáme jaká data do procesů vstupují, jaká z něj vystupují, jak jsou procesy dekomponovány.

Datový slovník poskytuje informace o tom, jaká je struktura a skladba dat. Tyto informace nepopisují

však transformaci dat, nepopisuje operace pro změnu dat. Proto bez popisu procesů a jejich

algoritmů nemůže být model informačního systému úplný.

Základní požadavky na popis procesů:

1. Popis musí pravdivě a jednoznačně vyjadřovat funkci jednotlivých procesů i celého IS.

2. Pro popis musíme použít takový nástroj, aby popisu rozuměl uživatel, analytik i programátor.

3. Do popisu neuvádíme již informace, které jsou uvedeny v datovém slovníku nebo jsou zřejmé z grafického vyjádření DFD.

4. Popis provádíme pro elementární procesy (dále nedekomponované), které jsou na nejnižší úrovni.

Pro popis používáme takové prostředky, které nejlépe vystihují činnost procesu. Mezi tyto prostředky

počítáme:

Verbální popis - předností je jednoduchost a srozumitelnost, nedostatkem je rozlehlost při popisu

i jednoduchých algoritmů a značná nepřesnost. Používá se pro popis procesů při ručním zpracování.

Vývojové diagramy - předností je názornost, nevýhodou je pracnost při finální tvorbě a špatná

možnost úprav.

Matematické výrazy - výhodou popisu je kompaktnost a jednoznačnost, nevýhodou je omezená

vyjadřovací schopnost.

Programovací jazyky - výhodné jsou pro další programovou realizaci IS, nejsou většinou srozumitelné

pro uživatele.

Pro praktické použití se jeví jako nejvhodnější použít kombinaci všech čtyřech popisů s využitím jejich

potřebných vlastností. To umožňuje použít pro popis strukturovanou formu přirozeného jazyka. Tím

vzniká možnost použití kombinace běžného jazyka a použití elementárních logických konstrukcí při

popisu algoritmů.

4 Modely organizace dat v relačních databázových systémech

Zásobníky dat navržené v DFD slouží k uchovávání dat, proto při počítačové realizaci jsou tyto prvky

řešeny jako datové soubory. Pro informační systémy malém a střední velikosti se běžně používají

relační databáze. Proto se v následující části budeme zabývat návrhem struktur datových souborů

pro tuto databázovou strukturu.

Pro návrh datových struktur souborů slouží datové modely. Jejich tvorba nezávisí na fyzickém uložení

v paměti počítače a na operačním prostředí. Nejčastěji se používají:

relační model

entitně-relační model

4.1 Entitně - relační model

Stanoví pravidla pro uspořádání dat do relací (dvourozměrných tabulek). Každý záznam obsahuje

údaje o zadaných vlastnostech objektu.

Tento model představuje grafické znázornění entit a jejich vzájemných vazeb. Je sestavený jako

statický model systému. Používá se pro návrh fyzické struktury souborů. Základními vlastnostmi jsou:

slouží pro analýzu vazeb mezi entitami;

je vhodný pro sestavování množiny struktur přímo v 4NF;

poskytuje podklad pro návrh fyzické struktury souborů.

Model se sestavuje ze tří základních komponent:

a) Datová entita - reprezentuje určitý typ objektů. Entitu tvoří skupina datových prvků (položek),

charakterizující tento objekt. Z pohledu databáze entita představuje strukturu položek tabulky, která

obsahuje jednotlivé záznamy. Název je tvořen podstatným jménem v jednotném čísle. Entita musí

splňovat podmínky:

každá entita musí být popsaná pomocí jednoho nebo více datových prvků.

entita musí být obsažena v popisovaném informačním systému.

b) Relační vazby - představují logické vztahy mezi entitami, která se vyjadřuje slovesem. Důležité

i stanovení charakteru vazby - kardinality. Kardinalita popisuje vztah mezi výskyty záznamů

svázaných entit. Může být následující:

N:M N výskytů záznamů v první entitě je svázáno s M výskyty záznamů ve druhé entitě

1:M jeden výskyt záznamu v první entitě je svázán s M výskyty záznamů ve druhé entitě

M:1 M výskytů záznamů v první entitě je svázáno s jedním výskytem záznamu ve druhé

entitě

1:1 jeden výskyt záznamu v první entitě je svázán s jedním výskytem záznamu v entitě

druhé

Graficky jsou tyto komponenty zobrazovány podle obrázku Obr. 4.2.

Modelování pomocí entitně-relačního modelu (ERD) je velmi populární a znázorňuje logickou

strukturu pro každou entitu a relační vazbu mezi entitami.

Ukázka příkladu ERD modelu s vyznačením entit a vazeb je na Obr. N.2.

Algoritmus sestavení ERD modelu je sice jednoduchý, praktická tvorba s velkým počtem datových

prvků je však náročná, Vyžaduje perfektní znalost obsahu a souvislostí všech datových prvků.

Výchozím bodem je sestavený DFD včetně připravených slovníků dat.

Obr. 4.2: Základní komponenty entitně relačního modelu

a) entita, b) relační vazba, c) sub- a super-typ.

Obr. 4.3: Grafické znázornění kardinality vztahů mezi entitami.

Obr. 4.4: Příklad ERD modelu.

Tvorba entitně-relačního modelu (ERD)

Algoritmus tvorby ERD modelu můžeme rozdělit do sedmi základních kroků.

První krok

Ze seznamu všech datových prvků vytvoříme tří základní skupiny podle vlastností:

1. skupina - obsahuje pouze datová prvky s charakterem determinantu.

2. skupina - obsahuje prvky, jejichž hodnoty jsou jednoznačně určeny determinanty z prvků 1.

skupiny.

2. skupina - ostatní prvky, nezařazené do předchozích skupin.

Jména prvků se mohou ve všech skupinách vyskytovat pouze jednou. Determinant ověřujeme tak, že

určíme konkrétní hodnotu vybraného prvku a určíme ty prvky, které jsou touto jeho hodnotou

určeny.

Druhý krok

V tomto kroku provádíme reorganizaci 2. skupiny datových prvků. Prověřujeme možnost

determinovat prvek pomocí složeného determinantu z prvků 1. skupiny. Nemá-li prvek takovouto

možnost, přeřadíme jej do 1. skupiny. a tvoří determinant sám sobě.

Třetí krok

Datové položky roztříděné v kroku 2 spojíme do spolusouvisejících entit a subtypů a přiřadíme jim

vhodné názvy.

Čtvrtý krok

Nyní sestavíme předběžný entitně-relační diagram, která obsahuje pouze jednotlivé entity a určíme

kardinalitu jednotlivých relačních vazeb. Jako nejčastější otázkou při stanovení kardinality je:

"Kolik záznamů v cílové entitě může náležet k jednomu záznamu ve výchozí entitě."

V případě, že jednomu záznamu ve výchozí entitě neodpovídá žádný nebo jeden záznam v cílové

entitě, pak se jedná o kardinalitu 1:M.

Pátý krok

Do předběžného ERD doplníme značky vazeb s výstižným slovesným pojmenováním.

Šestý krok

ERD představuje pouze grafické znázornění modelu. Pro další použití je nutné definovat logické

struktury jednotlivých entit a navrhnou relační vazby. To představuje návrh struktur záznamů včetně

stanovení primárních klíčů.

Sedmý krok

Tento poslední krok představuje normalizaci navržených struktur v závislosti na zajištění funkce

relačních vazeb. Při normalizaci používáme následující pravidla (podle [KONEČNÝ,1996]:

Je-li kardinalita 1:1, vloží se determinant jedné entity do struktury druhé entity. Toto rozšíření se provede u obou entit.

Je-li kardinalita 1:M vloží se primární klíč entity s kardinalitou 1 do logické struktury s kardinalitou M.

Je-li kardinalita M:N můžeme říci, že jsou struktury normalizované, prakticky to však znamená, že tuto vazbu musíme převést přes další entitu, která bude obsahovat determinant složený s determinantů obou entit.

Zrušíme ty struktury, které obsahují pouze jeden prvek, protože zákonitě musí existovat i v jiné struktuře.