2 Analýza

Samotná analýza nastáva vo chvíli, keď vznikne potreba nového spôsobu ukladania a spracovania údajov. V tomto prípade nezáleží na tom, či prechádzame z klasického systému a teda súborového spracovania údajov (napríklad kartotéky) na spôsob databázového spracovania alebo je dôvodom zastaraný pôvodný databázový systém – napríklad generuje chyby alebo nezvláda zaťaženie. Všeobecne ide o fázu, v ktorej sa realizuje skúmanie existujúceho systému a požiadaviek používateľa.

V tejto fáze je potrebné vytvoriť zoznam otázok, na ktoré budeme potrebovať jednoznačné odpovede a musíme takisto vykonať nasledujúce činnosti:

2.1 Analýza organizácie

Je potrebné vziať do úvahy širší obraz organizácie začínajúc hardvérom, existujúcej štruktúry databázy a takisto obraz situácie celej organizácie. Je rozdiel medzi veľkou nadnárodnou spoločnosťou a malou tuzemskou firmou. Nemôžeme implementovať riešenie, ktoré by bolo vytvorené pre malú firmu do návrhu databázy veľkej nadnárodnej spoločnosti. Účelom analyzovania je zistiť čo najviac informácií o organizácii, aj keď nie úplne súvisia s návrhom databázy. Hlavným cieľom analýzy organizácie je pochopiť čo organizácia vykonáva, ako funguje a pracuje. Pochopenie organizácie, pre ktorú je databáza vytváraná je zásadnou podmienkou dobrého návrhu databázy [1].

Otázky súvisiace s organizáciou:

Aký je účel dotknutej organizácie? Ako by bol tento účel vysvetlený zákazníkovi?
Čo je podľa vedenia organizácie účelom a hlavným zámerom organizácie?
Aká je hlavná funkcia organizácie?
Ako je možné opísať, čo táto organizácia robí?
Aká je organizačná štruktúra v organizácii?
Koľko má organizácia zamestnancov? Čo majú v náplni práce? [1]

2.2 Definovanie problémov, možností a obmedzení

Táto fáza nasleduje po úspešnom pochopení organizačnej štruktúry a je potreba sa používateľov existujúceho systému pýtať na problémy a obmedzenia vyskytujúce sa v súčasnom systéme a na následné potreby a ciele nového DBS. Nemôžeme zabudnúť zistiť, aké obmedzenia budú fungovať aj naďalej. Obmedzenia myslíme napríklad aj požiadavky na hardvér (staré riešenie databázového servera), ľudí, prípadne limity rôznych hodnôt [1].

Je potrebné pýtať sa nielen jedného používateľa, ale širšieho spektra používateľov, ktorí budú mať k údajom a neskôr k informáciám v databáze prístup. Postup týchto rozhovorov je vhodný od vedúcich funkcií k bežným zamestnancom. Zamestnanci na vedúcich pozíciách sú schopní definovať základné problémy a požiadavky. Naopak bežní zamestnanci, ktorí k databáze pristupujú každodenne sú schopní požiadavky a problémy následne konkretizovať z používateľského pohľadu [1].

Tiež je dôležité sa pýtať na budúce požiadavky kladené na databázu, ktoré súvisia napríklad s rozširovaním spoločnosti a podobne. Zjednoduší sa tým implementácia a môže sa tým ušetriť veľa času v budúcnosti [1].

Otázky k existujúcej databáze:

Prečo vzniká potreba tvorby novej databázy? Aký je dôvod tejto potreby?
Aké údaje súvisia s procesom zberu – o aké údaje ide?
Akým spôsobom organizácia zhromažďuje a prezentuje údaje?
Ako organizácia používa a spravuje svoje údaje v súčasnosti?
Aké informácie v súčasnosti získava organizácia z databázy a aké sú potreby informácií v organizácii? [1]

Otázky k použitiu databázy – vo vzťahu rozhovorov s používateľmi a manažmentom:

Ako pracujú s databázou jednotlivé skupiny používateľov?
Aké aplikácie pristupujú k databáze?
Aké sú požiadavky jednotlivých skupín používateľov na informácie?
Aké obmedzenia sa predpokladajú?
Ako je definovaná náplň práce jednotlivých používateľov? Akú prácu denne vykonávajú?
S akým typom údajov pracujú?
Aké veci sa sledujú a zaznamenávajú a aké typy správ a hlásení sú požadované?
Existujú ešte nejaké ďalšie veci, ktoré by bolo dobré do databázy implementovať?
Aká je predstava do budúcna ohľadne rozšírenia organizácie a tým aj rozšírenia databázy? [1]

2.3 Definovanie cieľov

Z odpovedí na predchádzajúce otázky je možné vytvoriť zoznam požiadaviek, ktoré po doladení definujú jednotlivé ciele. Ciele reprezentujú všeobecné činnosti používateľa s údajmi, ktoré môžeme v databáze uskutočňovať. Tvoria ich základné požiadavky organizácie na informácie a zaisťujú východiskový a finálny bod návrhu novej databázy. Každý cieľ jasne definuje jednu všeobecnú úlohu a je ľahko pochopiteľný. Nič však nie je definitívne a v priebehu návrhu sa tieto ciele môžu čiastočne meniť, rozširovať a ďalej upresňovať [1].

2.4 Definovanie rozsahu

Ako návrhári DBS musíme jasne a zreteľne určiť rozsah a časový plán čiastkových úloh a to vrátane rozsahu samotnej implementácie [1].

2.5 Údajová analýza

Údajová analýza definuje hlavne údajové toky, ktoré súvisia s vybraným systémovým procesom. Analýza sa sústreďuje rovnako na vstupné a výstupné údaje a takisto na samotnú transformáciu vstupných údajov na výstupné. Výsledok analýzy nám poskytuje dostatočný prehľad o potrebných údajoch a väzbách medzi nimi tak, aby mohol riešiteľ projektu vytvoriť požadovaný databázový prípadne informačný systém [1].

Môžeme povedať, že údajová analýza pre koncového používateľa systému vyjadruje spôsob komunikácie s riešiteľmi konkrétneho systému. Údajovú analýzu preto vykonávame v rámci definovania problémov, možností a obmedzení, keď sme na základe predložených údajových formulárov, tlačových zostáv a vhodne položených otázok schopní identifikovať prebiehajúce údajové toky v celom procese. Výsledkom údajovej analýzy je model na konceptuálnej úrovni, ktorý vyjadruje statický obraz opisu reality. Vyjadrujeme ho napríklad s pomocou E‑R diagramu. Táto analýza často pomáha odstrániť bariéru medzi konečnými používateľmi na jednej strane a realizátormi produktu na strane druhej. Prax ukazuje, že používatelia obvykle opisujú svoje požiadavky na základe svojich skúseností, ale hlavne v začiatkoch analýzy nedokážu domyslieť využitie všetkých možností respektíve potenciálu, ktoré im poskytuje konečný systém. Naopak realizátori podrobne poznajú softvérové a hardvérové možnosti. Na druhú stranu im však nie sú obvykle dobre známe potreby a požiadavky od používateľov. Na účely vzájomného pochopenia medzi oboma stranami boli vytvorené špeciálne vyjadrovacie prostriedky napríklad už spomínaný E‑R diagram [1].

2.6 Funkčná analýza

Funkčná analýza sa spoločne s údajovou vykonáva na začiatku návrhu databázových systémov a sú spolu prepojené. S pomocou nej vykonávame návrh činnosti DBS a vyjadruje, ako má proces pracovať. Môžeme povedať, že je to zoznam a opis jednotlivých akcií uskutočňovaných nad konceptuálnym návrhom a externými návrhmi DBS. Ide o opis stavov údajových štruktúr a prechodov medzi nimi [1].

Pri funkčnej analýze sa vytvárajú modely na správne pochopenie systému a na komunikáciu medzi zadávateľom projektu, realizátorom a konečným používateľom. Tento model musí byť zrozumiteľný a čo najviac presný pre budúcu implementáciu [1].

Výsledkom funkčnej analýzy je:

Zoznam funkčných požiadaviek.
Zoznam udalostí a reakcií – model vonkajšieho správania sa systému.
Požadované vstupy a výstupy [1].

Funkčná analýza definuje najmä obsah a rozsah výstupných zostáv ako elektronické súbory, zostavy na tlačenie, výstupy na monitor a potrebných vstupných údajov ako interné a externé údaje, číselníky. Súčasťou analýzy je aj opis transformácie vstupných údajov na výstupné, vrátane logických a formálnych kontrol týchto údajov. Funkčná analýza sa teda zaoberá definíciou základných funkcií DBS a môžeme ju vyjadriť viacerými rôznymi modelmi, ktoré opisujú funkcionalitu systému, ako napríklad [1]:

Diagram toku údajov (data flow diagram) – zobrazuje procesy a toky údajov medzi nimi (ako sú údaje použité a transformované pri postupne systémom). Opisuje vnútornú funkcionalitu systému na základe analýzy toku údajov medzi internými funkciami systému navzájom a s okolím systému. Pri zložitejších systémoch s viacerými vstupmi a výstupmi sa tento diagram kreslí v niekoľkých úrovniach. Ako prvá úroveň sa vytvára kontextový diagram, ktorý celý systém zobrazuje ako jediný proces a s ním všetky súvisiace externé entity. Kontextový diagram sa potom rozpracúva v jednotlivých úrovniach. Pri bežných systémov sa používa väčšinou diagram v troch maximálne štyroch úrovniach [1].
Kontextový diagram – opisuje vonkajšie správanie sa systému respektíve vzťah systému k jeho okoliu. Diagram odpovedá tomu, čo potrebuje používateľ od systému. Získame ho analýzou udalostí, ktoré sa môžu vyskytnúť medzi systémom a subjektmi v jeho okolí. Medzi tieto subjekty patria napríklad iní používatelia nadväzujúcich prípadne spolupracujúcich systémov alebo nadradený informačný systém. Celý systém (celá databáza) je pri tomto type diagramu zobrazená ako celok. Subjekt mimo systému sa zvykne označovať pojmom „terminátor.“ Každá udalosť medzi systémom a jeho okolím vyvolá konkrétny väčší alebo menší prenos informácií (niekedy aj prenos materiálov) [1].
Stavový diagram (state transition diagram – STD) – definuje možné stavy, možné prechody medzi stavmi, udalosti, ktoré prechody iniciujú, podmienky prechodov a akcie, ktoré s prechodmi súvisia. Stavový diagram je možné použiť aj na opis dynamiky objektu (ak má rozpoznateľné stavy), na opis metódy (ak poznáme algoritmus) alebo na opis protokolu (vrátane protokolu o spojenie používateľa so systémom). Je veľmi potrebný z hľadiska pochopenia logiky aplikácie. Používateľ nám neoznámi algoritmus celého procesu, ale pozná stavy – napríklad stav objednávky, stav faktúry, stav palety a podobne. Dá sa z neho odvodiť funkcionalita systému a následne algoritmus spracovania údajov [1].

2.7 Katalóg požiadaviek na databázové systémy

Katalóg požiadaviek je základným analytickým materiálom na vytvorenie databázového systému. V tomto dokumente sa zvyčajne nepoužíva žiadna technická terminológia, ktorej by zadávateľ projektu (budúci používateľ systému) nemusel rozumieť. Autormi sú obvykle riešitelia projektu, ktorí jeho vypracovaním dávajú najavo, že správne pochopili zadanie. Dokument tvorí formálnu dohodu medzi zadávateľom a riešiteľom, takže musí obsahovať všetky špecifikácie a definovanie požiadaviek, ktoré zadávateľ má na konkrétny systém. Jeho finálna podoba preto vzniká až po viacnásobnom stretnutí alebo komunikáciách so zadávateľom. Môžeme teda povedať, že katalóg požiadaviek je súčasťou záväzného zadania na vypracovanie databázového systému.

Katalóg požiadaviek zvyčajne nerieši otázky implementácie systému a takisto špecifikácií technologických prostriedkov, na ktorých bude systém fungovať. Môže sa to stať v prípade, ak by na tento aspekt kládol zadávateľ projektu nejaké zvláštne nároky. V takom prípade musia byť tieto požiadavky uvedené v prislúchajúcom dokumente. Katalóg požiadaviek môže obsahovať aj grafickú dokumentáciu na zvýšenie názornosti.

Zhrnutie 2. kapitoly

Analýza nastáva v počiatočnej fáze vývoja databázového systému. Tvorca systému musí podrobne spoznať činnosť organizácie, pre ktorú sa systém vytvára. Správne pochopenie činnosti organizácie, pre ktorú je databáza vytváraná je teda zásadnou podmienkou na dobrý návrh DBS. Dôležité je takisto zistiť problémy s používaním aktuálneho systému, rôzne obmedzenia (napríklad hardvérové požiadavky), limity rôznych hodnôt a tým zamerať návrh na následné potreby, požiadavky a ciele nového systému.

V údajovej analýze sa sústredíme na vstupné a výstupné údaje, a rovnako na samotnú transformáciu vstupných údajov a údaje výstupné. Údajová analýza nám poskytuje prehľad o údajoch a takisto o jednotlivých väzbách (vzťahoch) medzi nimi.

Okrem údajovej analýzy vykonávame aj funkčnú. Funkčná analýza sa zaoberá definíciou základných funkcií DBS a vyjadrujeme ju s pomocou rôznych modelov. Definuje najmä obsah a rozsah výstupných zostáv ako elektronické súbory, zostavy na tlačenie, výstupy na monitor a potrebných vstupných údajov ako interné a externé údaje, číselníky.

Výsledkom analýzy organizácie je katalóg požiadaviek, ktorý je základným analytickým materiálom na vytvorenie databázového systému. Výsledkom katalógu je súhrn požiadaviek, ktoré zadávateľ má na konkrétny systém. Tvorca DBS ním dáva najavo, že správne pochopil fungovanie organizácie, pre ktorú DBS buduje.

Otázky na zopakovanie

Vlastnými slovami opíšte, čo sa vykonáva vo fáze analýzy organizácie pri tvorbe DBS.
Čo sa vykonáva v údajovej analýze?
Čo sa vykonáva vo funkčnej analýze?
Čo je obsahom katalógu požiadaviek pri tvorbe DBS?
Vymenujte modely, ktoré opisujú funkcionalitu systému.

Doplňujúci materiál ku štúdiu

Otte, Lukáš: Databázové systémy – Životní cyklus databáze. Ostrava : Vysoká škola Baňská, Technická univerzita Ostrava, Fakulta strojní, 2013. [Cit. 2020‑14‑05]. Dostupné na internete: ⟨http://projekty.fs.vsb.cz/463/edubase/VY_01_044/Datab%C3%A1zov%C3%A9%20syst%C3%A9my.pdf ⟩.