1 Informační systémy. 1.1 Základní pojmy a souvislosti

Transkript

1 Informační systémy Stránka č. 1 z 5 1 Informační systémy 1.1 Základní pojmy a souvislosti Informační systém je takový systém, kde informace jsou definované jeho vazby a místa transformace jsou realizována jako prvky systému. Informace je charakterizována základními vlastnostmi: informace je nehmotná; informace může být obsažena jak ve znacích (signálech), tak i v jejich vzájemných uspořádáních; znaky i signály poskytují informaci pouze tomu, kdo jim rozumí - je schopen je rozpoznat. Rozpoznání informace spočívá v přiřazení znaků nebo signálů reálným objektům, jevům a jejich vztahům. Informace je pak výsledkem pozorování objektů a jevů. Znaky se obvykle používají pro uchovávání informace, signály pro přenos informace, kdy se znakům přiřazují jednoznačné signály. Toto přiřazení nazýváme kódování. Opačným procesem je dekódováni. Posloupnosti znaků a signálů nazýváme zprávy (sdělení). Rozdíl mezi pojmem data a informace: Data lze považovat za zprávy, které mohou ale nemusí snižovat entropii systému (neurčitost systému). Informace je tvořena věcným obsahem zprávy. Tzn. informaci lze považovat za součást dat, ale data nemusí obsahovat informaci. Vždy snižuje entropii (neurčitost) systému. Informace lze členit: v z hlediska času: statistické; plánované; prognostické; v v v v podle působení na systém: vnitřní; vnější; aktivní; pasivní; podle opakovatelnosti: jednorázové; periodické; podle uchovávání: uchovávané; neuchovávané; z hlediska významu: nezbytné; důležité; zajímavé. Informační systém může sloužit následujícím účelům: dokumentačním - chovávání informací pro případné pozdější použití - např. údaje o skutečném technickém stavu vozidel při kontrole na STK; statistickým - zvláštní případ dokumentačního informačního systému - informace určeny pro statistické a přehledové vyhodnocování, které současně provádí; řídícím - slouží k potřebám řídícího systému (Management Information Systéms) nebo potřebám řízení, což je cílevědomé působení na řízený objekt za účelem dosažení jeho žádoucího stavu. Posledně vzpomínaný IS je nejsložitější a předchozí většinou bývají jeho součástí. Tento systém musí poskytovat nezbytné informace pro všechny úrovně řízení. Obecné pojetí řídícího IS je na obrázku Obr file://\\fs1\dat\fs\kat\342\s1i95\public.www\isvdas\is\is_uvod.htm

2 Informační systémy Stránka č. 2 z 5 dokumentační IS informace do okolí statistický IS informace z okolí systém řízení řídící IS řídící informace stavové informace VSTUP ŘÍZENÝ PROCES VÝSTUP Obr. 1.1: Obecné schéma funkce řídícího informačního systému. Vzhledem k náročnosti cíle činnosti ŘIS je nutné aby fungoval jako automatizovaný řídící systém, tzn., že musí být realizovaný takovými prostředky, které umožňují automatizovaný sběr informací o stavu systému a prostředky, které výsledky rozhodovacích algoritmů transformují na příslušné povely pro řízení procesu. 1.2 Životní cyklus projektu informačního systému a jeho zavádění do provozu Návrh jakéhokoliv složitého systému, a tím IS určitě je, je nutné rozložit na řadu dílčích kroků, které odpovídají možnostem projektanta i uživatele. Tyto kroky musí být sestaveny tak, aby představovaly systémový přístup k problému. Tento musí obsahovat: 1. Rozklad původního problému do množiny jednodušších problémů. Rozklad se opakuje pro všechny dílčí problémy do té doby, než vzniknou základní problémy (triviální - dále již nedělitelné), které jsou již řešitelné. 2. Návrh řešení pro každý triviální problém. 3. Spojení řešení dílčích problémů podle úrovní do jednoho (vyššího) celku. 4. Aplikace kompletního řešení na původní problém. 5. Ověření správnosti řešení. Pozn.: Body 3. až 5. se opakují pro každý dílčí problém, který byl rozložený do další nižší úrovně. Jako analogie mohou sloužit programovací techniky v procedurově orientovaných programovacích jazycích (např. Pascal, C++ a pod.), kde hlavní program se skládá z jednotlivých procedur a ty zase používají jiné procedury, funkce a proměnné. Pořadí činností, které je nutno realizovat při návrhu informačního systému se nazývá životní cyklus projektu informačního systému (ŽCS, System Development Life Cycle). Konkrétní definice se různí podle jednotlivých zdrojů, ale hlavní fáze je možno podle../isds_zdroje.htm#konecny1996 nazvat a interpretovat následovně: Studijní fáze účelem je co nejpřesnější specifikace problému. Analytik (projektant) získává informace k řešení problému od odborných pracovníků uživatele. Hlavním výstupem této fáze je zpráva (Úvodní studie a pod.), která definuje základní problémy a způsoby jejich řešení. Tato zpráva by měla obsahovat: detailní a precizní specifikaci základních problémů; formulaci požadavků pro řešení problémů; postup realizace; odhad nákladů na projekt; odhad doby potřebné k realizaci. Schválení této zprávy startuje druhou fázi návrhu IS. file://\\fs1\dat\fs\kat\342\s1i95\public.www\isvdas\is\is_uvod.htm

3 Informační systémy Stránka č. 3 z 5 Analýza tato fáze předpokládá naprosto přesné pochopení řešených problémů a návrh jejich definitivních řešení. Analytik opět musí úzce spolupracovat s pracovníky uživatele, aby získal podrobné a přesné informace o jeho požadavcích na IS a vazbách na existující IS. V této fázi se provádí: sestavení modelů existujících systémů - datové toky, datové slovníky, popisy procesů (viz následující kapitoly); návrh nového IS - precizní zpracování datových toků, datových slovníků a popisů procesů pro nová řešení. Výstupem je analytický návrh nového IS. Tento musí být opět oponován a odsouhlasen budoucím uživatelem. Návrh v této fázi se získávají informace a podklady pro tvorbu dílčích programů IS. To představuje: volbu software a hardware a jeho osvojení; návrh datových souborů a programů, formulářů, sestav a obrazovek; návrh struktura programů; návrh a příprava testovacích úloh. Výstupem je specifikace programů IS (návrh jejich zdrojových kódů). Implementace podstatou je tvorba a testování programových modulů IS a příprava instalace. Tato fáze je zaměřena na: tvorba jednotlivých modulů; tvorba testovacích dat a testovacích programů; dokumentování programů; tvorba provozní dokumentace; školení pracovníků uživatele; příprava instalačního plánu. Instalace je poslední fází před rutinním provozem IS. Součástí instalace je konverze stávajících datových souborů stávajícího IS a zpracování zkušebních úloh. Zahajuje se zkušební provoz IS. Vyhodnocení je závěrečná fáze životního cyklu projektu IS. Jeho doba je závislá na rozsahu projektu. Výstupem je mimo jiné: připomínky uživatele IS; výstupy testovacích programů; Závěrem je protokol o zkušebním provozu IS, který uvádí i případné závady a jejich odstranění. Jednotlivé fáze a činnosti ŽCS nemusí mít vždy postupný charakter. Některé činnosti se mohou provádět paralelně, tím se zkrátí celková doba projektu. Vlastní tvorba IS však není přímočará. Po každé fázi se provádí vyhodnocení a na jeho základě se přikročí k následující činnosti. V případě nesouladu s požadavky je nutné se vrátit k předchozí fázi a tuto přehodnotit. file://\\fs1\dat\fs\kat\342\s1i95\public.www\isvdas\is\is_uvod.htm

4 Informační systémy Stránka č. 4 z 5 Vyhodnocení Instalace Implementace Návrh Analýza Studijní fáze Obr. 1.2: Životní cyklus projektu informačního systému. t 1.3 Způsoby zavádění informačních systémů do provozu Zavedení nového IS je ve firmě vždy problémem. Proto pro úspěšnou realizaci tohoto zásadního kroku je nutná volba vhodného způsobu zavedení IS do rutinního provozu. Tato volba závisí od mnoha faktorů jako např.: typ a funkce předchozího IS; objem změn a způsobu ovládání IS; připravenost jednotlivých pracovišť a pracovníků na zavedení IS; a mnohé další. Postupů pro zavádění IS do rutinního provozu je veliké množství. Liší se od sebe rychlostí, zaváděcí metodou a pod. Mezi používané strategie patří podle../isds_zdroje.htm#molnar1992: Souběžné zavádění Informační systém je zaveden souběžně na všech pracovištích najednou. Tento postup je vhodné použít při zavádění jednodušších IS, které nevyžadují náběhovou fázi zavádění (složitá školení, konverzi dat z předchozích IS). Obr. 1.3: Souběžné zavedení informačního systému. Pilotní zavádění Informační systém se zavede na jednom pracovišti, které je na tuto činnost připraveno. Po zavedení probíhá ověřovací provoz a posléze zde probíhá zacvičování pracovníků ostatních pracovišť. Tento způsob je vhodný pro zavádění kvalitativně odlišných IS, které vyžadují rozsáhlé testování nového IS v provozních podmínkách. Toto pilotní zavádění umožňuje postupnou transformaci dat z předchozích IS. V závěru pilotní fáze dochází k zavádění IS na ostatní pracoviště, které jsou již připravena. Obr. 1.4: Pilotní zavádění informačního systému. file://\\fs1\dat\fs\kat\342\s1i95\public.www\isvdas\is\is_uvod.htm

5 Informační systémy Stránka č. 5 z 5 Postupné zavádění Zavádění IS na jednotlivá pracoviště probíhá postupně, bez pilotní fáze. Rychlost zavádění je závislá na připravenosti jednotlivých pracovišť a na složitosti IS. Tento způsob je vhodný pro takový systém, u kterého není nutné provozní ověřování (komerčně dodávaný IS, IS převzatý z podobně fungujících pracovišť). Obr. 1.5: Postupné zavádění informačního systému Nárazová strategie zavádění Strategie zavádění, kde najednou ukončíme činnost jednoho IS a po nezbytně nutné pauze spustíme nový informační systém. Tento postup je riskantní, používá se tak, kde souběh IS není možný. Obr. 1.6: Nárazová strategie zavedení informačního systému. V praxi však nastává nutnost kombinovat jednotlivé postupy. Nejčastější je kombinace postupu nárazového a postupného. file://\\fs1\dat\fs\kat\342\s1i95\public.www\isvdas\is\is_uvod.htm

6 Databázové systémy Rozvoj IS je spjatý s rozvojem výpočetní techniky, především počítačů. V počátcích se zpracovávaly velké objemy informací na jednom počítači, tomuto způsobu říkáme systém hromadného zpracování dat nebo agendové zpracování. Data se zapisovaly do připravených formulářů, dále se přepisovaly ručně na záznamové médium (děrné pásky, později diskety) pak teprve na centrálním počítači primárně a sekundárně zpracovány. Výsledkem je vytištění výstupních sestav (většinou v papírové podobě) a zpětná distribuce k prvotnímu pořizovateli. Celková doba takovéhoto zpracování byla velmi dlouhá, proto nebylo možno zpracovávat dynamické informace. Typickým příkladem byly měsíční statistické sestavy (mzdy, uzávěrky). Programy pro zpracování byly jednoúčelové bez možnosti změn výstupů, realizované byly v nejjednodušších jazycích (Cobol a pod.). Pro odstranění těchto nevýhod bylo nutné k oddělení dat od programu. Data jsou uloženy v bázi dat (BD) a programy si z ní vybírají potřebné informace, této části se říká systém řízení báze dat (SŘBD). Počátky těchto systémů spadají do 60. let a proti předchozímu stavu přestavují kvalitativní skok. Tato změna byla umožněna přechodem od sálových počítačů k počítačům stolním a později osobním. Databázový systém vzniká spojením systému řízení báze dat a vlastní báze dat. Základní pojmy Systém řízení báze dat je možno chápat jako soubor procedur a datových struktur, které zajišťují nezávislost databázových aplikací na fyzickém uspořádání paměťových struktur počítače. SŘBD podporuje tvorbu formulářů (vstupní a výstupní obrazovky, formuláře - Forms) pro zadávání dat, výstupních sestav (přehledy, uzávěrky - Reports) a aplikačních programů. Další pojmy se kterými operují databázové systémy jsou: Data jsou údaje, které jsou předem určeným způsobem uspořádány v různých formách (např. tabulky, grafy, akustické signály a pod.). Jsou to určitým způsobem uspořádané informace v atributech o popisovaných objektech. Z těchto dat můžeme získat požadované informace pro řídící procesy. Záznam (Record) je souhrn údajů (atributů) o daném popisovaném objektu, které jsou uloženy v položkách (polích - Field). Jako příklad mohou sloužit informace o motorovém vozidle: Struktura záznamu je dána názvy jednotlivých položek: typ vozidla, modifikace typu, datum výroby, SPZ, příjmení majitele, jméno majitele. Data pak tvoří obsah jednotlivých položek pro konkrétní motorové vozidlo, např.: Škoda Felicie, LX, , OVX 19 90, Novák, Josef. Datové typy (type) jsou označení typu údaje v položce. Nejčastěji se používají typy: Text - textový řetězec složený z alfanumerických znaků, Číslo - číselný údaj o předem stanovené max. délce a počtu desetinných místech, Logický typ - dvoustavová hodnota typu Ano/Ne, True/False apod., Datum - položka pro záznam datumu a času Memo - položka pro textové řetězce libovolné délky. Označení konkrétních typů se liší podle konkrétní ho databázového systému. Architektura databází Centrální architektura U databázového systému tohoto typu je báze dat i systém řízení báze dat v centrálním počítači. Komunikaci s uživateli zprostředkovávají terminály na pracovištích. Po síti se přenášejí vstupní údaje z terminálu do centrálního počítače a tam se zpracovávají centrálním programem. Tím že data se zpracovávají centrálně, kde může probíhat i více úloh, mohou mít odezvy na dotazy určité zpoždění.

7 Obr. Y1.: Centrální architektura. Architektura file-server Tento typ architektury souvisí s rozšířením PC a lokálních sítí. Data v BD jsou umístěna na počítači pracujícím jako file-server a jsou sdílena pro jednotlivé aplikace a SŘBD na jednotlivých počítačích. Vzhledem k tomu, že k datům může přistupovat více aplikací, musí být zajištěna ochrana používaných záznamů. Komunikace probíhá podle následujícího postupu: uživatelský dotaz SŘBD zpracuje dotaz a odešle požadavek na DB, file-server odesílá bloky dat na lokální počítač, kde jsou data dále zpracovávána SŘBD výsledky se zpravidla uloží na PC, zobrazí na monitoru, ev, vytiskne jako sestavu. Obr. Y2.: Architektura file-server Architektura klient-server Tato architektura je umožněna rozvojem sítí LAN (lokálních sítí) rozdělených na osobní počítače (PC) a databázový server. Na PC běží aplikace, které předávají dotazy na datový server (většinou pomocí strukturovaného jazyka), který je zpracovává a potřebné výsledky předává zpět na PC. Proto je server nejvíce zatíženým počítačem. Průběh je následující: aplikace na PC připraví dotaz na data v podobě SQL dotazu a odešle jej na server, server zpracuje dotaz, výsledek dotazu je odeslán na PC, kde jej aplikace převede do výstupní podoby. Tato architektura snižuje požadavky na množství dat pohybujících se v síti, proto vyhovuje i rozsáhlým aplikacím od renomovaných firem.

8 Obr. Y3.: Architektura klient-server Architektura distribuovaných databází V tomto systému jsou data rozložena v několika počítačích. Navenek se tváří jako jediná veliká datadáze. Je charakterizovaná třemi vlastnostmi: Transparentnost - klientovi připadá, že data jsou zpracovávána na jediném serveru v síti, není specifikováno místo uložení dat, to řídí SŘBD. Autonomnost - s každou částí BD je možno pracovat samostatně, data jsou spojována dynamicky podle potřeby SŘBD. Nezávislost na typu sítě - architektura podporuje různé typy sítí a jejich vzájemné propojení. Pro komunikaci se nejčastěji používá strukturovaný dotazovací jazyk SQL. Obr. Y4.: Architektura distribuovaných databází Modely datových struktur Model dat je souhrn pravidel pro reprezentaci logické organizace dat v databázi. Rozeznáváme tři základní modely dat - hierarchický, síťový a relační. Nejnovější a zároveň nejpoužívanější je relační model, který odstraňuje některé nedostatky ostatních modelů. Hierarchický model dat Data jsou organizována do stromové struktury. Každý záznam představuje uzel ve stromové struktuře. Vzájemný vztah mezi záznamy můžeme označit jako rodič a potomek. Obr. Y4.: Hierarchický model dat {obrázk3. FAR95} Použití tohoto modelu je vhodné tam, kde i popisovaná skutečnost má obdobnou stromovou strukturu. Při pohybu v datech se pohybujeme směrem dolů (od rodiče k potomkovi), nahoru ( od potomka k rodiči) nebo na stejné úrovni (od potomka přes rodiče k potomkovi - sourozenci. Nevýhody tohoto hierarchického modelu: v některých případech nepřirozená organizace dat (zejména obtížné znázornění vztahu mezi více rodiči a více potomky), složité operace vkládání a rušení záznamů. Síťový model dat

9 Síťový model dat je v podstatě zobecněním hierarchického modelu dat, který doplňuje o mnohonásobné vztahy, které předchozí model neumožňoval přímou cestou. Tyto propojují záznamy různého či stejného typu, přičemž spojení může být realizováno na jeden nebo více záznamů. Obr. Y5. Schéma síťového modelu báze dat a její zobrazení pro dva záznamy. {obrázk3. FAR95- upravit pro dodavatele vozidel} Nevýhodou síťové modelu databáze je zejména nepružnost a obtížná změna její struktury. Relační model dat Nejmladším databázovým modelem je model relační. V současnosti je tento model nejčastěji využíván u SŘBD. Pro tento model platí následující vlastnosti: 1. Databáze je chápana uživatelem jako množina relací a nic jiného. 2. V relačním SŘBD jsou k dispozici minimálně operace selekce, projekce a spojení (viz dále), aniž by se vyžadovaly explicitně předdefinované přístupové cesty pro jednotlivé relace. Obr. Y6. Příklad relačního modelu báze dat a její zobrazení pro dvě relace. {vytvořit obr s vazbou mezi třemi tabulkami - pomocí vystřižených tabulek z Excelu - vycházet z Obr Y5} Systém řízení báze dat má definovánu spoustu pravidel, která umožňují jednoduchý přístup k jednotlivým údajů. Tato pravidla jsou přímo implementována v komerčních programech, které se používají při tvorbě aplikací pro informační systémy. Jako příklad může sloužit prostředí FoxPro(R), Visual FoxPro, Access a mnoho dalších. Proto při dalším popisu IS budeme vycházet právě z tohoto relačního modelu dat. Relační databázový model má jednoduchou strukturu. Data jsou organizována v tabulkách, které se skládají z řádků a sloupců. Všechny operace s daty jsou prováděny na těchto tabulkách.pro práci v tomto modelu je nezbytné, aby každá tabulka v databázi měla své jedinečné jméno. Záznam (Record) jako souhrn stanovaných údajů o daném objektu je v tabulce reprezentován jedním řádkem tabulky. Sloupec tabulky definuje jednu položku (pole, Field) záznamu, musí mít svůj název a musí být určitého datového typu. Z popisu tabulkového vyjádření tohoto modelu vyplývají tyto vlastnosti: 1. Homogenita sloupců - v každém sloupci jsou všechny položky stejného typu. 2. V tabulce neexistují dva stejné řádky, což je dáno nutností primárního klíče, který popisuje konkrétní záznam a je pro danou tabulku jedinečný. 3. Pořadí řádků je nevýznamné, protože jednotlivé řádky jsou identifikovatelné pomocí primárního klíče. 4. Pořadí sloupců (položek) je nevýznamné, protože sloupce jsou označeny názvem položky. Obr. Y7: Příklad tabulky relačního modelu dat

10 Relační algebra Pro práci s tabulka v relační databázi je nutné definovat alespoň základní aparát, který nám umožní zpracovávat data z tabulek. K těmto činnostem slouží prostředek nazývaný relační algebra. Relační algebra je nejzákladnějším prostředkem pro práci s tabulkami. Mezi základní operace patří projekce, selekce a spojení. Tyto operace lze definovat takto: Projekce tabulky (relace) R s položkami A na množinu položek B, kde B A: -vytvoří tabulku s položkami B a záznamy, které vzniknou z původní tabulky R odstraněním položek A-B. Odstraněny jsou i eventuelně opakující se záznamy. -značení : R[B] Selekce tabulky R s položkami A podle logické podmínky F: -vytvoří tabulku s týmiž položkami a ponechá ty záznamy z původní tabulky, které splňují logickou podmínku F. Podmínka F je logický výraz, jehož formule nad jednoduchými položkami tabulky mají tvar: Φ = t Θ kde: t 1, t 2 1 t 2 jména položek tabulky, konstanty nebo výrazy Θ logické operátory - Θ { <, >, =,, } -značení: R(Θ) Spojení tabulek R a S se položkami A a B: -vytvoří minimalizovanou tabulku se schématem A B a se záznamy, jejichž projekce na A je z tabulky R a projekce na B je z tabulky S. -značení: R * S U spojení pracujeme s několika možnými případy. Nejčastější je spojení přes rovnost (přirozené spojení). Výsledná tabulka obsahuje jen ty záznamy z obou zdrojových tabulek, které se shodují v položkách, přes které se spojení provádí. Pokud některý záznam z jedné tabulky nemá odpovídající záznam v tabulce druhé, ve výsledné tabulce se neobjeví. Takový postup se nám však ve všech případech nehodí, proto je nutno používat další typy spojení, levé -polospojení a pravé -polospojení, které z určené tabulky (stojící v operaci jako levý či pravý argument) připojí všechny záznamy, bez ohledu na to, zda mají odpovídající záznam v druhé zdrojové tabulce. Použití polospojení je důležité tam, kde není programově zajištěna plná integrita dat, případně pokud nemáme jistotu, že nemůže být porušena. Příklad jednotlivých operací relační algebry si ukážeme na dvou tabulkách - OPRAVY a VOZIDLO. Tabulky OPRAVY a VOZIDLO jsou definované položkami podle obrázku Y.1. Tyto tabulky obsahují jednotlivé záznamy podle obrázku Obr. Y.2 a Obr. Y.3. Obr. Y. 1: Tabulky příkladu. Obr. Y.1: Tabulka OPRAVY.

11 Obr. Y.2: Tabulka Vozidlo. Na těchto tabulkách provedeme jednotlivé operace: a) Projekce tabulky OPRAVY položkami Dat_opravy, Zakázka. Výsledek je na Obr. Y.4. Obr. Y.4: Projekce OPRAVY[Dat_opravy,Zakázka]. b) Selekce tabulky OPRAVY. Podmínka pro selekci je dána výrazem F: Dat_opravy = Výsledná tabulka je na obrázku Obr. Y.5. Obr. Y.5: Selekce OPRAVY[Dat_opravy = ]. c) Spojení tabulek OPRAVY a VOZIDLA. Spojení těchto tabulek se děje pomocí spojení přes rovnost položek OPRAVY.SPZ a VOZIDLA.SPZ (viz Obr. Y.6). Vznikne tabulka obsahující záznamy, jejichž struktura je dána souhrnem všech položek spojovaných tabulek. Takto vzniklá tabulky je ukázkou nejjednodušší formy spojení. Obr. Y.6: Vazba položek při spojení. Obr. Y.7: Spojení přes OPRAVY.SPZ = VOZIDLA.SPZ (zobrazeny jen některé položky tabulky). Z příkladu a předchozích definic je zřejmé, že operace projekce vybírá sloupce, operace selekce vybírá řádky (záznamy) a operace spojení provádí spojení dvou tabulek přes zvolenou položku nebo skupinu položek.

12 Dotazovací jazyky Dotazovací jazyky představují standardizovaný nástroj pro komunikaci mezi aplikacemi a bází dat. QBE Rozhraní QBE (Query By Example, dotaz podle vzoru) je rozhraní pro tvorbu dotazů na data většinou formou grafické komunikace. Tento přístup nevyžaduje znalost struktury a syntaxe dotazovacího jazyka. Umožňuje realizovat dotazy v relačních databázích na základě kombinace pravidel relační algebry. Umožňuje také realizovat další operace, jako třídění, součty a pod. Některé aplikace umožňují i tvorbu složitých dotazů s logickými vazbami. Konkrétní podoby rozhraní jsou závislé na aplikaci a BD, ke které dotaz směřuje. Na následujících obrázcích jsou ukázky tvorby QBE v prostředí Microsoft Access pro základní relační operace projekci, selekci a spojení. Data jsou tvořena již známými tabulkami ORAVY a VOZIDLO. Obr. A.1: Dotaz pro operaci projekce na tabulce OPRAVY. Operace podle Obr. A.1 vytvoří tabulku odpovídající tabulce na Obr. Y.4. Operaci selekce na tabulce OPRAVY je realizovaná dotazem podle Obr. A.2. Výsledek tvoří záznamy, kdy Dat_Opravy= viz Obr. Y.5. Obr. A.2: Dotaz pro operaci selekce. Dotaz pro vytvoření tabulky realizující pravé polospojení tabulky OPRAVY a VOZIDLO podle položky SPZ je zobrazen na obrázku Obr. A.3. Dotaz pro obdobné spojení spojené s projekcí pro vybrané položky z nové tabulky je na Obr. A.4. Výsledkem tohoto dotazu je tabulka podle Obr. Y.7.

13 Obr. A.3: Zadání dotazu pro realizaci oprace spojení. Obr. A.4: Dotaz realizující aperaci spojení a projekce. Ukázka jiného prostředí pro tvorbu QBE vidíte na obrázku Abr. A.5.Jedná se o nástroj ve FoxPro 2.5. Obr. A.5: Návrh dotazu QBE v prostředí FOXPRO 2.5 (bez návaznosti na předchozí tabulky).

14 SQL Jazyk strukturovaných dotazů (SQL, Structured Query Language) vznikl na počátku sedmdesátých let jako standard pro komunikaci v oblasti databázových prostředí. Mezi základní vlastnosti můžeme zařadit [FAR95]: Interaktivní dotazovací jazyk - uživatel zapíše příkazy SQL do interaktivního SQL programu, který najde potřebná data a zobrazí je na obrazovce. Databázový programovací jazyk - k použití při tvorbě databázové aplikace. Jazyk pro správu databází - správci databází využívají SQL pro definici datových struktur a kontrolu uložených dat. Klient/server jazyk - programy pro počítače používají SQL pro komunikaci v lokální počítačové síti (LAN) s databázovými stanicemi (database servers), kde jsou uložena sdílená data. Jazyk distribuované báze dat - systémy spravující distribuované databáze, používají SQL jako doplněk pro distribuci dat mezi několika spojenými počítačovými systémy. Komunikační jazyk SŘBD v LAN - v síti s několika různými SŘBD je SQL jedinou cestou pro jejich vzájemnou komunikaci. Syntaxe tohoto jazyka je odvozena na základě anglického jazyka. Vysoký úroveň strukturovanosti je podmínkou pro obsluhu databází a interaktivní práci s ní. Neobsahuje však příkazy nutné pro strukturovanou stavbu aplikačního programu (např. testy podmínek, skoky, cykly apod.). Proto je nutné používat tento jazyk ve spojení s programovacími jazyky nebo jako součást již naprogramované databázové aplikace (např. Access, Excel, FoxPro a další. Jazyk SQL má definován ANSI/ISO standard. Je sestavován formou ASCII textů v předem stanovené struktuře. Konkrétní SŘBD někdy ne zcela přesně tento standard dodržují, často jsou doplněny ještě další nadstandardní příkazy. Následuje výběr příkazů tohoto jazyka: Definice datových struktur CREATE TABLE vytvoření tabulky DROP TABLE zrušení tabulky CREATE WIEV přidání pohledu do SŘBD DROP WIEV odstranění pohledu Získávání dat SELECT výběr dat (položek) z databáze Manipulace s daty (záznamy) INSERT vložení záznamu do tabulky DELETE odstranění záznamu z tabulky UPDATE úprava obsahu existujícího záznamu Agregované funkce COUNT() počet záznamů SUM() součet hodnot za položku MIN() nejmenší hodnota ve sloupci tabulky (nejmenší z hodnot položky) MAX() největší hodnota ve sloupci tabulky (největší z hodnot stanovené položky určených záznamů) AVG() aritmetický průměr hodnot V aplikacích je možné SQL vytvořit většinou třemi způsoby: Interaktivně - aplikace ve vestavěném rozhraní přijímá pokyny pro tvorbu jednotlivých částí struktury dotazu. Aplikace kontroluje správnost struktury a syntaxi. Přímým zápisem dotazu - uživatel přímo (pomocí vestavěného textového editoru) zaznamenává jednotlivé části dotazu. Tento přístup předpokládá detailní znalost struktury a syntaxe SQL. Aplikace tento dotaz realizuje. Programové sestavení - programové struktury aplikace sestavují jednotlivé části SQL na základě požadavků uživatelských programů. Uživatel aplikace nemůže přímo ovlivňovat obsah dotazu. Jsou mu dostupné pouze data získaná na jeho základě. Příklady dotazů SQL Jako příklad si uvedeme SQL dotazy pro realizaci základních relačních operací podle předchozího. Pro realizaci projekce na tabulce OPRAVY je možno definovat dotaz podle Obr. A.6. Výsledkem je tabulka podle Obr. Y.4.

15 Obr. A.6: Operace projekce na tabulce OPRAVY. Pro realizace selekce na téže tabulce je dotaz již poněkud složitější viz (Obr. A.7). Obr. A.7: Operace selekce na tabulce OPRAVY. Dotaz pro realizaci spojení a projekce na již známých tabulkách je na Obr. A.8. Výsledek dotazu odpovídá Tabulce na Obr. Y.7. Obr. A.8: Dotaz pro realizace spojení a současně projekce na nové tabulce. Vytvořené dotazy na obrázcích A.6 až A.8 jsou výsledkem intrraktivní spolupráce uživatele s aplikací pro obsluhu databází. Na Obr. A.9 je ukázka dotazu vytvořeného jinou aplikací (FoxPro 2.5). Obr. A.9: Zápis dotazu SQL v prostředí FoxPro.

16 Modelování informačních systémů a návrh struktury dat Logická reprezentace 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 textové podpůrné 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ů. 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 systému. Systém zobrazuje 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 spojujeme pomocí datových toků. Pro grafické znázorňování DFD používáme grafické značky. Jejich grafická podoba se liší podla jednotlivých autorů. Nejznámější podoby jsou v tabulce Tab. B.1. Tab. B.1: Značky pro vyjadřování DFD. YORDON GANE - SARSON Externí entita Datový tok Zásobník dat Proces Externí entita - někdy nazývána jako terminátor je prvek představující okolí modelu. Pomocí této entity modelujeme komunikaci okolí s modelem (vstupní i výstupní). 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 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

17 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 může být složený s elementárních údajů a jiných datových toků. Jeho konkrétní obsah je definovaný v datovém slovníku, jež 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). 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á. Tato data 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í jej pojmenovávat (ani definovat jeho strukturu - viz datový slovník).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. B.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, 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. Pro zásobníky platí následující pravidlo: zobrazují se v nejvyšší úrovni DFD a na nižších úrovních se jejich zobrazení opakuje. Doplňkové symboly v DFD Pro zvýšení přehlednosti v diagramu datových toků se ke značkám přidávají doplňkové symboly. Ty zdůrazňují: Označení místa realizace zásobníku dat D - realizace na počítači M - ruční zásobník dat (kartotéka) T - dočasný zásobník (ruční i počítačový) Externí entity se vyznačují většinou v konceptuálních schématech. V diagramech nižší úrovně se používají duplikáty externích entit a označují se šiknou čárou v levém horním rohu značky. Podobně i v diagramech nižších úrovních se používají duplikáty zásobníku dat. Označují se zdvojením levé čáry u uzávěry značky. Označují se i procesy, které již v dalším nejsou podrobovány rozkladu (nejsou dekomponované). Označením je hvězdička pod šikmou čárou v pravém dolním kvadrantu značky procesu. Umístění zásobníku Duplikát terminátoru Duplikát zásobníku Nedekomponovatelný proces Obr. B.2: Doplňkové symboly v DFD

18 Obr. B.1: Rozklad systému včetně kontextového diagramu. Pravidla pro návrh diagramu datových toků 1. Každý zásobník nebo externí entita musí být napojena na proces. Nelze terminátor spojit 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 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ý. Názvy datových toků představují podstatná jména. 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. 4. Do procesu vstupují jen ta data, která tento proces zpracovává. 5. 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. 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ší dekompozice, tím jednodušší 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. Tyto vstupy napovídají že tento proces realizuje přesně definovanou funkci.

19 10. DFD nikdy nevyznačuje časovou závislost datových toků. Tyto a další informace se zaznamenávají v popisech v datovém slovníku. Porušení těchto pravidel vede většinou k narušení formální stránky diagramu. Ale i formálně správný diagram nemusí být ještě správný z logického hlediska. Při tvorbě diagramu je nutné dodržet návaznost jednotlivých úrovní. Při kontrole této návaznosti používáme kontrolu pomocí návaznosti datových toků. Vstupní/výstupní informace procesu na vyšší úrovni musí být shodná se vstupními/výstupními daty jemu odpovídajícího diagramu nižší úrovně. Fyzické a logické diagramy Velmi často se v počáteční fázi představ o systému stává, že do diagramu se 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á. Fyzický diagram může obsahovat následující fyzické procesy, jejichž eliminací přejdeme na logický diagram. 1. Procesy, které využívají fyzický objekt. Např. v IS kolejových vozidel se může vyskytnou datový tok LOKO. V tomto případě se však jedná jen o dílčí informace o základních provozních parametrech lokomotivy, které nás zajímají, nikoli o jejich fyzickou podstatu. 2. Procesy, které provádí záznam do zásobníku dat. Vlastní vkládání se děje např. pomocí klávesnice, proces by se mohl jmenovat např. ZADÁNÍ Z KLÁVESNICE. V logickém diagramu nás však zajímá logika prováděných změn touto činností a ta se musí objevit v popisu procesu, např. změna technických údajů a jeho řízení. 3. Procesy představující přenos dat v diagramu z místa na místo. Tyto procesy lze v diagramu vynechat, neboť se nejedná o proces transformace dat. 4. Procesy provádějící řazení dat do jiného tvaru. Tento činnost je většinou jako součást algoritmu jiného procesu, provádějícího transformace dat. Příklad fyzického diagramu a jemu odpovídajícího logického procesu jsou na obrázku Obr. B.3. {upravit obrázek podle KON96 2.9} Obr. B.3:Fyzický a logický diagram téhož podsystému. 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. Mezi hlavní důvody tvorby datového slovníku jako součásti projektové dokumentace patří: Bez přesné specifikace dat a algoritmů procesu není možné DFD jednoznačně interpretovat při tvorbě IS. Pečlivé sestavení datového slovníku umožňuje analýzu jednoznačnosti označení tatových toků a datových prvků. Datový slovník představuje spojení mezi projektem představovaným DFD a realizací IS. Systém tvorby datového slovníku umožňuje určitou automatizaci tvorby programového vybavení (CASE TOOLS). Datový slovník představuje základ pro návrh struktury báze dat projektovaného IS (viz relační model dat). Datový slovník obsahuje komponenty nutné pro přesné specifikace dat. 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ů s 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. Navržení správné struktury dat je jednou z nejdůležitějších činností při návrhu informačního systému. Pro jednotný a srozumitelný návrh musí existovat jednotný vyjadřovací prostředek. Používají se struktury z vyšších programovacích jazyků, kterou používají i prostředky pro návrh struktury SDW. Tuto syntaxi použijeme i v jiných popisech relačních databázových systémů - viz Tab. B.1.

20 Tab. B.1: Symboly pro popis struktury dat. = údaj je složen (rovná se) + logické spojené (and) { } opakování obsahu v závorkách [ ] obsah závorek obsahuje výčet možností (odděleny " ") ( ) parametr může ale nemusí existovat *...* označení klíčového prvku (primárního klíče) 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, \,?,! a další). V případě, že datová struktura je shodná se strukturou již definovaného toku, již ji znovu nedefinujeme a přiřadíme ji. OBJEDNÁVKA_A = OBJEDNÁVKA Identifikátor datového toku může sloužit jako základ pro popis jiných struktur. OBJEDNÁVKA_B = OBJEDNÁVKA + {ZBOŽÍ} + Čis_faktury Každá položka v datovém slovníku popisující datový tok nebo zásobník musí být určena: identifikátorem; strukturou (obsahující substruktury a názvy položek, případně označení položky představující klíč 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í potřebný počet znaků povinně 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ů). 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 Příklady slovníku dat: Datové toky: Datový tok: ADRESA=NÁZEV+ULICE+ČÍSLO_DOMU+PSČ+MĚSTO+ STÁT Popis: Adresa osoby nebo firmy. Datový tok: Popis: Datový tok: Popis: Datový tok: Popis: DODAVATEL=ADRESA Jméno nebo název firmy a přesná adresa dodavatele zboží. OBJEDNÁVKA=DODAVATEL+{ZBOŽÍ}+ODBĚRATEL+DATUM Základní údaje dokumentu, kterým ODBĚRATEL objednává specifikované zboží OBJEDNÁVKA_A=OBJEDNÁVKA Akceptovaná objednávka - bude dodavatelem vyřízena kladně. Datový tok: ROZMĚR=VÝŠKA + ŠÍRKA + DÉLKA Popis: Zřejmý z obsahu (není nutno uvádět). Zásobníky dat: Zásobník: + PŘÍ.JMENI + JMÉNO + MÍSTONAROZENÍ + OKRESNAROZENÍ Popis: Základní osobní údaje studenta. Zásobník: ZÁKAZNIK=INTČÍSLO + ADRESA +

21 Popis: Seznam zákazníků firmy. Zásobník: ZBOŽÍ =KÓDOZNAČENÍ+NÁZEVZBOŽÍ+CENA+MNOŽSTVÍ Datové prvky: Datový prvek CENA Typ: N Délka: 30 Popis: Cena prodávaného zboží. Interval: Kč. Datový prvek: DÉLKA Typ: N Délka: 5 Datový prvek: PROFESE Typ: N Délka: 2 Popis: Údaj označující profesi, ve které je pracovník vyučen. Interval: viz dále interní číselník PROFESE Datový prvek: PŘÍJMENÍ Typ: A Délka: 25 Popis: Příjmení osoby. Interval: Datový prvek: RODNÉ.ČÍSLO Typ: AN Délka: 11 Popis: Rodné číslo osoby, dle celostátního číselníku. Interval: Datový prvek: STAV Typ: A Délka: 1 Popis: Údaj definující rodinný stav. ["s" "S"] - svobodný(á) ["r" "R"] - rozvedený(á) ["v" "V"] - vdaná ["ž" "Ž"] - ženatý Interval: ["s" "S" "r" "R" "v" "V" "ž" "Ž"] Číselníky: Číselník: PROFESE Struktura: XX - kde X je číslice O div 9 Obsah: 01 - dělník 02 - soustružník 03 - frézař 04 - svářeč atd. 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. 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ě 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 nekomponované), 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.

22 Matematické výrazy - výhodou popisu je kompaktnost a jednoznačnost, nevýhodou je omezená vyjadřovací schopnost. Programovací jazyky - výhodné pro další programovou realizaci IS, nejsou většinou srozumitelné pro uživatele. Pro praktické použití se její 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 postupů a použití logických konstrukcí při popisu algoritmů. Strukturovaná forma přirozeného jazyka Pro vyjádření algoritmů používá slova přirozeného jazyka (anglického, českého), z vyšších programovacích jazyků používá některé konstrukce. Výhody použití strukturované formy jazyka: Popis je stručný a jasný. Popis je nezávislý na použitém programovacím jazyku. Popis je přístupný jak programátorů a analytikům tak je srozumitelný i budoucím uživatelům. Využitím popisů dat z datového slovníku můžete kontrolovat konzistenci DFD. Popis umožňuje snadnou transformaci do zvoleného vyššího programovacího jazyka. Příkazové sekvence Obsahují jeden nebo více jednoduchých příkazů, které se plní v pořadí, v jakém jsou zapsány. Příklad: Čistá_mzda=Hrubá:mzda-Srážky Zapiš záznam ZAKÁZKA do zásobníku ZAKÁZKY_A Cena=235,20 Každý příkaz musí být jednoznačný. Pokud další provádění příkazů závisí na předem stanovených podmínkách, musíme použít programovací struktury. Rozhodovací struktury Používají se pro větvení algoritmu podle podmínky. Jako podmínka se používá logický výraz, který se vyhodnocuje na svou pravdivost. JE-LI podmínka PAK příkazy 1 JINAK příkazy 2 KONEC IF podmínka THEN END ELSE příkazy 1 příkazy 2 Platí-li podmínka, provedou se příkazy 1, v opačném případě příkazy 2. Po splnění příkazu se ukončí celá struktura a provádí se příkazy na klíčovým slovem KONEC. Přepínač - postupně se vyhodnocují podmínky podmínka n a provedou se ty příkazy, pro které je podmínka platná. Tím se ukončí činnost celé struktury a provádí se další příkazová sekvence. VYBER VARIANTA 1 podmínka 1 příkazy 1 VARIANTA 2 podmínka 2 příkazy 2... JINAK příkazy j

23 KONEC SELECT CASE CASE 1 podmínka 1 příkazy 1 CASE 2 podmínka 2 příkazy 2... OTHERWISE příkazy j END Struktury pro znázornění cyklu Struktura pro realizaci opakujících se příkazů, které jsou v těle definovaného cyklu. Používají se tří základní struktury cyklů: Cyklus s předem definovaným počtem průchodů: PRO počet PROVEĎ příkazy těla DALŠÍ FOR počet DO příkazy těla NEXT Po vyčerpání počtu počet průchodů se struktura ukončí. Není vhodné v příkazech těla měnit hodnotu počet. Cyklus s podmínkou na počátku: POKUD podmínka PROVEĎ příkazy těla KONEC WHILE podmínka DO příkazy těla END V případě že při prvém vyhodnocení podmínky cyklus zjistí její neplatnost, tělo cyklu se nevykoná a struktura se ukončí. Provede se příkaz za koncem cyklu. Cyklus s podmínkou na konci: OPAKUJ příkazy těla DOKUD podmínka REPEAT příkazy těla UNTIL podmínka Oproti předcházející struktuře se příkazy těla provedou minimálně jednou i přesto, že podmínka není platná. Na rozdíl do programovacích jazyků je možná volnější syntaxe (není omezována). Je však nutno dodržovat pravidla: 1. pro označení operací se používají aktivní slovesa (odečíst, zapsat apod.); 2. pro označování datových prvků ev. paměťových proměnných používáme podstatná jména; 3. pro vyhodnocování a používání hodnot datových a paměťových prvků platí, že musí být vždy z jejich definičního oboru; 4. logické výrazy se mohou vyskytovat pouze v podmínkách rozhodovacích struktur a struktur cyklu struktur;

24 5. pro formulaci logických výrazů se musí používat pouze srozumitelná klíčová slova elementárního významu (rovná se, je menší a pod. - operátor je z intervalu není elementární operátor a je nutno jej rozložit).

25 Logická reprezentace dat Zásobníky dat v DFD slouží z dlouhodobému uchovávání dat, proto při počítačové realizaci jsou tyto prvky řešeny jako datové soubory. Datové modely slouží pro návrh datových struktur souborů. 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 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. Při uchovávání dat se setkáváme se dvěma základními problémy: redundance dat - nadbytečnost - údaje se zbytečně opakují ve více záznamech - řeší se přesunutím do samostatných tabulek opakující se skupiny dat - v jednom záznamu se vyskytují skupiny položek, které se v záznamu opakují. Tyto problémy je nutno z navržené struktury odstranit. K tomu slouží postup nazvaný normalizace logické struktury. Normalizace logické struktury Provádí se postupně od první normální formy (1NF) až ke čtvrté normální formě (4NF). Jejich řešení vyžaduje důkladnou znalost souvislostí mezi jednotlivými položkami. Praktický význam pro tvorbu má 1NF, BCNF - Boyce-Coddova normální forma a 4NF. Normalizace představuje rozklad výchozí struktury dat do několika nových struktur tak, aby byly vyloučeny redundance a opakující se skupiny. První normální forma Definice: Struktura záznamu odpovídá 1NF tehdy, obsahují-li všechny možné druhy záznamů vždy stejný počet datových prvků. Logické struktura v 1NF obsahuje prostý výčet identifikátorů jednotlivých atributů záznamu. Záznamy v takovéto struktuře obsahují množství redundantních údajů. Proto tato forma slouží jako výchozí forma pro transformaci do vyšších normálních forem. Příkladem je modelová struktura dat pro sledování údržby lokomotiv: LOKO.1NF=C_loko+C_loko+Rok_vyroby+Datum_zar+Stup_udržby+Datum_udržby+Mistr+ Mistr_Jméno+Mistr_Příjmení Pokud použijeme tuto strukturu jako základ k popisu každého údržbového zásahu provedeného na lokomotivě, výsledný soubor bude obsahovat mnoho redundantních údajů. Struktura totiž obsahuje atributy, které se vztahují k různým objektům (Loko a Mistr). Proto je nutné rozdělit strukturu do samostatných struktur. Každá takováto struktura musí obsahovat takový atribut, aby jednoznačně určil příslušnost k objektu - klíčový prvek. Tím je C_loko a Mistr. LOKO UDRŽBA +Mistr PRACOVNICI=@Mistr+ Mistr_Jméno+Mistr_Příjmení V těchto strukturách je pak každý záznam definován svým klíčem. Pro další postup normalizace jsou nutné další pojmy: Definiční obor atributu - interval jeho přípustných hodnot. Jednoznačný prvek - prvek, kterému lze v záznamu přiřadit vždy pouze jednu jedinou hodnotu z jeho definičního oboru. Příklad: Hmotnost v kg - nemůže být současně hodnota 20 kg a 30 kg. Mnohoznačný prvek - prvek, u kterého v rámci jednoho záznamu můžeme přidělit víc než jednu hodnotu. Příklad: Vzdělání - obsahuje výčet absolvovaných škol. Mnohoznačný a nezávislý prvek - prvek jehož každá hodnota je určena pouze hodnotou jednoho jednoznačného prvku. Příklad: Datum_udržby - jeho výskyt závisí na hodnotě jednoznačného prvku C_loko.