ŽILINSKÁ UNIVERZITA V ŽILINE

Transcription

1 ŽILINSKÁ UNIVERZITA V ŽILINE Fakulta riadenia a informatiky Spracovanie dát v rozsiahlych databázach Dizertačná práca Študijný program: Pracovisko: Školiteľ: Aplikovaná Informatika Žilinská Univerzita v Žiline Fakulta Riadenia a Informatiky Katedra Informatiky Doc. Ing. Michal Zábovský, PhD. Evidenčné číslo práce: Žilina, apríl 2013 Ing. Ľuboš Takáč

2 ABSTRAKT V dizertačnej práci sú popísané aktuálne poznatky o spracovaní dát v rozsiahlych databázach, hlavne relačných, ich použitie a ich nedostatky. Za tú dobu čo boli relačné databázy vyvíjané paralelne aj s inými informačnými technológiami a hardvérom sa dostali do takého stavu, že už nie je problém dáta zhromažďovať, robiť operácie nad nimi, rýchlo ich sprístupniť v krátkom čase na celom svete, ale pochopiť ich a orientovať sa v nich. Technológia nás predbehla v tomto smere a bez zmeny prístupu k týmto dátam a informáciám sa v nich budeme čoraz viacej strácať. Súčasné veľké objemy dát si vyžadujú nové metódy ich spracovania a používania. Bez toho aby sme sa v dátach vedeli orientovať a poznali vzťahy medzi nimi sú nám zbytočné a nevyužijeme nikdy plne ich potenciál a informácie v nich ukryté. V práci sa venujem hlavne možnostiam spracovania veľkých objemov dát a následne ich efektívneho pochopenia človekom pri danej forme spracovania a podania informácie. Takýto problém tiež nastáva pri snahe o pochopenie rozsiahlej relačnej databázy. Stovky tabuliek a vzťahov medzi nimi sa nedajú chápať naraz a ťažko odhadovať čo je podstatné a kde hľadať relevantné dáta a informácie. V práci sa rieši sémantika relačných databáz a možnosti ako uľahčiť používateľom používanie relačných databáz (najmä rozsiahlych), v ktorých sa ťažko hľadajú informácie a kde sa zle orientuje. V práci sú vytvorené tri prístupy na riešenie tohto problému. Prvým prístupom je vhodná vizualizácia tabuliek a vzťahov (ER diagramu) rozsiahlej relačnej databázy, ktorá umožňuje lepšiu orientáciu a hľadanie kľúčových častí v databáze. Druhým prístupom je skúmanie charakteristík a vizualizácia grafu (siete) vytvoreného zo schémy a dát relačnej databázy. V tomto prístupe je ukázané, že siete vzťahov vo veľkých relačných databázach sú bezškálové a táto vlastnosť sa dá využiť na ich skúmanie. Metódy oboch týchto prístupov sú aplikované vo vytvorenom softvérovom nástroji RDBAnalyzer. Tretím prístupom je využitie sémantických metadát z relačnej databázy na automatické generovanie ontológie, ktorá umožňuje vyhľadávať informácie a orientovať sa v databáze. Všetky tieto prístupy boli overené na reálnej rozsiahlej databáze. Vytvorené prístupy a metódy sa dajú aplikovať aj na nerelačné databázy resp. na všetky databázy, kde sú vzťahy medzi dátami. Kľúčové slová: VLDB, relačné databázy, databázové metriky, rozsiahle databázy, vizualizácia dát, vizualizácia databáz, mapovanie relačných databáz do ontológií, spracovanie rozsiahlych dát, bezškálové siete.

3 ABSTRACT This dissertation thesis describes the current knowledge about data processing over very large databases, especially using and insufficiency in relational databases. During the time that were relational databases developing in parallel with other information technologies and hardware we got to a state where is no longer a problem to collect data, do operations with them, quickly access data in very short time over the whole world but to understand the date and to orientate in them. Technology has overtaken us in this direction and without changing the access and the approaches for processing these data and the information we will be confused with it. The actual large volume of data requires new methods for processing and using it. If we cannot orientate in the data and we do not understand the relationships between them we can never utilize the full potential of this data and discover the hidden information in them. In this thesis I focus mainly in possibilities of processing over large volumes of data and effective understanding by human. This problem also occurs when people try to understand large relational databases and find out information in them. Hundreds of tables and relations between them cannot be seen at once and it is hard to estimate what is important and where to find relevant data and information. This thesis deals also with semantics of relational databases and possible ways to facilitate users to use relational databases (especially large) when is difficult to find information and hard to orientate. In this thesis there are developed and documented three approaches that deal with mentioned problems. The first approach is suitable visualization of relations and tables (ER diagram) in large relational database which allows better orientation and finding the key parts in the database. The second approach is to examine the characteristics and visualization of graph (network) generated from the scheme and data of relational database. In this approach it is shown that the network of relationships in large relational databases is scale-free and this feature can be used for examine it. All methods of these two approaches are applied in developed software tool RDBAnalyzer. The third approach use semantics metadata from relational database to automatically generate an ontology which allows to search information and to orientate in the database. All of these approaches have been tested on real large relational database. Created approaches and methods can be applied to not only relational databases but also for all databases where the data are in relationships. Keywords: VLDB, relational databases, database metrics, very large databases, data visualization, database visualization, mapping relational databases into ontologies, large data processing, scale free networks.

4 Poďakovanie Chcel by som na tomto mieste vyjadriť veľkú vďaku môjmu školiteľovi Doc. Ing. Michalovi Zábovskému, PhD. za jeho neoceniteľnú pomoc, rady, pripomienky a návrhy, ktorými usmerňoval moju prácu. Prehlasujem, že som svoju dizertačnú prácu napísal samostatne a výhradne s použitím citovaných zdrojov. V Žiline, dňa Ľuboš Takáč

5 OBSAH Úvod... 1 Motivácia... 1 Ciele práce... 1 Metodika práce Zdroje a forma dát Dáta, informácie, znalosti a múdrosť Databázové systémy Relačné databázové systémy Relačná algebra Dátové modelovanie Databázové jazyky Optimalizácia dotazov Transakčné a Analytické databázy (Dátové sklady) Distribuované DB systémy (DDBS) Federované DB systémy Rozsiahle DB, (Very Large DataBases) Problémy veľkých databáz Problémy interpretácie dát RDB Metriky a Rankingy Big data Hadoop Hadoop Distributed File System (HDFS) Hadoop MapReduce Ďalšie nástroje z ekosystému Hadoop NoSQL databázy Dolovanie dát (Data Mining) Vizualizácia dát Vizualizácia grafov Ontológie Metodológia tvorby ontológií Komplexné siete Náhodné siete Bezškálové siete Návrh riešenia... 39

6 8.1 Získavanie metadát zo systémového katalógu ER diagram pri rozsiahlych RDB Schemaball Distribučná funkcia veľkosti tabuliek (TS) a dôležitosti vzťahov (DV) Rozdelenie grafu schémy RDB na komponenty Zhrnutie metód pre orientáciu a pochopenie rozsiahlej RDB Ďalšie charakteristiky rozsiahlych RDB Prístup Prístup Skúmanie a vizualizácia grafu RDB Zhrnutie a nedostatky riešenia Vytvorenie nástroja RDBAnalyzer Požiadavky nástroja RDBAnalyzer Návrh a implementácia Pridávanie ďalších funkcionalít Implementácia vizualizácii Multiplatformovosť a univerzálnosť nástroja Nedostatky a odporúčania Mapovanie relačných databáz do ontológií Záver Vedecký prínos práce Možnosti ďalšieho vývoja a výskumu Skratky a vysvetlivky Prílohy A Diagramy tried nástroja RDBAnalyzer B Návod na použitie nástroja RDBAnalyzer Zoznam Použitej Literatúry Vlastné publikácie... 85

7 ÚVOD Databázové systémy (DBS) sú neoddeliteľnou súčasťou takmer všetkých informačných systémov a väčších softvérových aplikácii. Môžeme sa s nimi stretnúť vo väčšine firiem, ale aj v štátnej sfére a inde. Slúžia nám na manipuláciu a uchovávanie väčšieho množstva logicky prepojených dát. Potrebnosť databáz a technologický pokrok dohnal tieto systémy na takú úroveň, že sme schopní uchovávať a manipulovať s obrovským množstvom dát (rádovo giga, tera, ale aj peta bajty), lenže už nie sme schopní len tak jednoducho sa v nich orientovať a využívať ich potenciál. Ide o takzvané zahltenie dátami. Správne využitie a spracovanie existujúcich dát môže pozitívne ovplyvniť zisk a chod firmy alebo byť jej konkurenčnou výhodou na trhu. S narastajúcim počtom dostupných dát je nevyhnutné vyvíjať aj techniky a metódy ich spracovania tak, aby boli pochopiteľnejšie pre človeka a aby sa v nich dokázal jednoduchšie orientovať. To je pohľad z užívateľského hľadiska a potreba využitia už existujúcich dát a dolovanie informácií z nich. Problém vzniká tiež na strane druhej, u databázových architektoch, vývojároch a ľudí čo navrhujú, vyvíjajú prípadne modifikujú takéto úložiská dát alebo databázy. Samotný návrh veľkej databázy nie je triviálna záležitosť. Ešte zložitejšie sú úpravy nevyhnutné pre vývoj a prispôsobenie sa novým požiadavkám systému. Problém skúmania dizertačnej práce sa dá definovať nasledovne: Ako pochopiť rozsiahlu relačnú databázu do takej miery, aby sme ju vedeli efektívne používať, upravovať a orientovať sa v nej. [87] MOTIVÁCIA Hlavnou motiváciou na riešenie tohto problému je moja osobná skúsenosť, keď som vo firme ako programátor potreboval často používať databázu, ktorá bola enormne veľká a bolo len málo ľudí čo ju poznalo tak, aby mi vedeli poradiť čo v nej kde nájdem. Najprv som si myslel, že je to len problém firmy a kompetentní si nevedia urobiť v tom poriadok, ale keď som sa informoval od známych pracujúcich v rovnakej oblasti, bolo mi potvrdené, že to je bežná prax. Bežne dostupné proprietárne nástroje od dodávateľov DBS pre tieto účely (MySQL Workbench, HeidiSQL, EMS SQL Manager for Oracle, IBM Data Studio, PGAdmin, a iné) a tiež komerčné (Bellman data profiler, Polaris Interactive DB Visualization) sú nepostačujúce pre databázy zložité z hľadiska štruktúry dátového modelu. V dostupnej literatúre [16-32], ktorej je k tejto problematike málo, nie je tento problém dostatočne vyriešený. CIELE PRÁCE V práci sú popísané aktuálne poznatky všeobecne o spracovaní dát a hlavne relačných databázach (RDB), ich použitie a ich nedostatky. Za tú dobu čo boli vyvíjané paralelne aj s inými informačnými technológiami a hardvérom sa dostali do takého stavu, že už nie je problém dáta zhromažďovať, robiť operácie nad nimi, rýchlo ich sprístupniť v krátkom čase na celom svete, ale pochopiť ich a orientovať sa v nich. Technológia nás predbehla v tomto smere a bez zmeny prístupu k týmto dátam a informáciám sa v nich budeme čoraz viacej strácať. Súčasné veľké objemy dát si vyžadujú nové metódy ich spracovania a používania. Bez toho aby sme sa v dátach vedeli orientovať a poznali vzťahy medzi nimi, sú nám zbytočné a nevyužijeme nikdy plne ich potenciál a informácie v nich ukryté. V práci sa venujem hlavne možnostiam spracovania veľkých objemov dát a následne ich efektívneho pochopenia človekom pri danej forme spracovania a podania informácie. Takýto 1

8 problém tiež nastáva pri snahe o pochopenie rozsiahlej RDB. Stovky tabuliek a vzťahov medzi nimi sa nedajú chápať naraz a ťažko odhadovať čo je podstatné a kde hľadať relevantné dáta a informácie. V práci riešim sémantika RDB a možnosti ako uľahčiť používateľom používanie RDB (najmä rozsiahlych), v ktorých sa ťažko hľadajú informácie a kde sa zle orientuje. Výsledky práce sú určené pre odborníkov pracujúcich s RDB, databázovým architektom pri údržbe a modifikácií existujúcich databáz, programátorom pracujúcich s RDB, aby sa v nich mohli rýchlo a efektívne orientovať, tiež databázovým špecialistom, ktorí navrhujú, vyvíjajú a optimalizujú RDB, ale aj laikom, ktorí chcú v RDB informácie vyhľadávať bez toho, aby ovládali technológie RDB systémov. Prvým cieľom práce je analýza súčasného stavu spracovania dát. Preskúmanie a popis celého procesu spracovania dát (získanie, extrakcia, transformácia, použitie) a metód, ktoré sa aktuálne na spracovanie dát používajú, ich výhody a nedostatky. V práci je popísaný problém spracovania rozsiahlych dát a prístupov riešenia tohto problému. Zameral som sa hlavne na relačné databázy a získavanie informácií a znalostí z nich. Druhým, hlavným cieľom práce je vytvorenie metodiky, postupu, algoritmu, alebo skupiny algoritmov, ktoré by umožňovali analyzovať rozsiahlu relačnú databázu, jej štruktúru, vybrať dôležité časti a vzťahy, ktoré by pomohli jednotlivcovi pochopiť takýto systém v čo najrýchlejšom čase a vyhľadať v ňom potrebné informácie a vzťahy s minimálnym rizikom chýb. Tieto metódy by mali byť všeobecne použiteľné a nezávislé na databázovom a operačnom systéme. METODIKA PRÁCE Práca je rozdelená na dve veľké časti. Prvá, teoretická časť práce, kapitoly 1 až 7, popisujú súčasný stav skúmanej oblasti spracovania dát v databázach. V prvej kapitole (Zdroje a forma dát) sú zadefinované zdroje a formy dát, čo sú to informácie a aký vzťah majú s dátami a znalosťami. V druhej kapitole (Databázové systémy) sú popísané najmä súčasné, relačné databázové systémy, ich rozdelenie, princíp ich fungovania a nedostatky. Vysvetlené sú tu aj problémy rozsiahlych relačných databáz a problém, ktorý sa v práci rieši, jeho súčasný stav a prístupy jeho riešenia. Kapitola 3 (Big data) popisuje iný, novo vzniknutý prístup riešenia problému spracovania rozsiahlych dát bez požitia relačných databáz. Do práce som túto kapitolu pridal aj keď priamo nesúvisí s problémom, ktorý riešim, ale je to nový smer vývoja databázových systémov a momentálne sa ešte nevie, či plne nahradí súčasne najpoužívanejšie relačné databázy alebo sa bude vyvíjať paralelne popri nich. V kapitole 4 (Dolovanie dát) je popísaný proces spracovania dát a vytvárania informácií z nich. Sú tu kategorizované rôzne prístupy dolovania dát. V ďalšej kapitole 5 (Vizualizácia dát) sú spomenuté výhody, použitie a príklady vizualizácií, ktoré nám umožňujú lepšie a rýchlejšie pochopenie informácie a komunikáciu medzi počítačom a človekom. Vizualizácia je jedným z prístupov k riešeniu problému orientácie v rozsiahlych databázach. Kapitoly 6 (Ontológie) a 7 (Komplexné siete) slúžia ako teoretický základ pre vytvorené prístupy v praktickej časti práce 8 (Návrh riešenia). Druhá, praktická časť práce 8 (Návrh riešenia) obsahuje mnou vytvorené prístupy riešenia problému orientácie, pochopenia a hľadania informácií v rozsiahlych alebo zložitých relačných databázach. Všetky postupy sú overené a demonštrované na reálnych databázach. Najskôr riešim nedostatky súčasne používaného ER diagramu, ktorý je pri zložitých RDB schémach nepoužiteľný. Riešenie spočíva vo vizualizácii schémy so zapracovaním databázových metrík, ktoré nám určujú dôležitosť tabuliek a vzťahov, zvýrazňujú dôležité časti čím urýchľujú 2

9 orientáciu v schéme. Podrobne je tu popísaný postup pri vizualizovaní metódou SchemaBall, ktorú som vylepšil a implementoval, a používaní tohto prístupu. Je tu ďalej navrhnutá metóda ako postupovať pri orientácii a snahe pochopiť neznámu alebo rozsiahlu relačnú databázu aj s praktickým príkladom. V ďalšej časti sa venujem charakteristikám a vizualizácii grafu vytvoreného z databázy kde som zistil, že pri rozsiahlych databázach má tento graf vlastnosti bezškálovej sieti. Graf som vizualizoval pomocou nástroja Gephi a tiež som navrhol vlastnú jednoduchú vizualizáciu kde sa dá overiť či je sieť bezškálová. Ďalej je popísaný nástroj RDBAnalyzer, ktorý som vytvoril a kde sú implementované spomínané postupy, aby sa dali prakticky použiť. V poslednej časti sa venujem automatickému mapovaniu relačných databáz do ontológií za účelom ich pochopenia, orientácie a hľadania informácií v nich. Je tu popísaný postup, ktorý som navrhol na používanie takto vytvorenej ontológie. Na praktickom príklade je ukázané ako sa dajú týmto prístupom hľadať informácie v databáze dokonca aj ľudom neznalých relačných databáz a SQL jazyka. 1 ZDROJE A FORMA DÁT Dáta môžu pochádzať z rôznych zdrojov. Jednak sú to záznamy čo si ľudia alebo firmy evidujú: aktivity, obchodné informácie, účtovníctvo, štatistiky a podobne (berieme do úvahy iba v digitálnej forme). Taktiež sa dáta aj automaticky generujú. Práve týchto automaticky generovaných dát v tejto dobe pribúda. Dobrým príkladom je napr. internet, kde sa denno denne generujú veľké množstvá dát. Napríklad už len z evidovania návštevnosti jednotlivých stránok. Takmer všetko sa eviduje a o všetkých aktivitách sa robia záznamy. Niektoré portály z marketingových dôvodov sledujú a zaznamenávajú dokonca aj pohyb myši na stránke, a aj na základe toho dokážu stanoviť ceny reklamných pútačov. Dáta sú najčastejšie vo forme textov. Takéto dáta sa však najťažšie spracuvávajú. Preto ak chceme dáta analyzovať, tak ich buď extrahujeme z tejto podoby alebo ich uložíme v inej podobe, najčastejšie do tabuľky kde riadok tvorí záznam a stĺpce tvoria atribúty jednotlivého záznamu. Je to najjednoduchší a zároveň najpoužívanejší spôsob uchovania dát určených na ďalšie spracovanie. Aj verejne dostupné dáta poskytované organizáciami na testovanie rôznych algoritmov sú vo forme data setov čo sú tabuľkové dáta. Pre jednoduchosť sú väčšinou ukladané v obyčajných textových súboroch. Záznamy sú oddelené riadkami a atribúty záznamov medzerami. Existujú však aj iné štandardy ako napr. CSV (Comma Separated Values), čo je tiež obyčajný textový súbor, kde záznamy sú v riadkoch oddelené čiarkami alebo bodkočiarkami a môžu byť v úvodzovkách (existuje tu viacero štandardov). Sofistikovanejší spôsob ukladania údajov určených buď na výmenu alebo na ďalšie spracovanie nám poskytuje XML formát. Je štandardizovaný a súčasne často používaný najmä preto, že dáta nielen uchováva, ale ich aj popisuje a dokonca sa dajú v ňom vytvárať aj dátové štruktúry [33]. Iným prípadom sú grafové dáta alebo dáta o vzťahoch a reláciách. Najjednoduchšie je ich reprezentovať TGF (Trivial Graph Format) formátom, kde sú v textovom súbore najskôr v riadkoch zapísané uzly (id_uzla a jeho atribúty) a potom hrany (id_uzol_z id_uzol_do a atribúty hrany). Existujú aj iné formáty, väčšinou sú XML-kové ako napr. GraphML, GXL, GML, XGMML. Takéto formy slúžia hlavne na výmenu a prenositeľnosť dát. V aplikáciách a softvéroch sú dáta väčšinou uložené v binárnych súboroch v nejakej programátorskej internej forme, ktorá je optimalizovaná na ich použitie alebo v externej / internej databáze (2. Databázové systémy), ktorá je pripojená k aplikácií. 3

10 1.1 DÁTA, INFORMÁCIE, ZNALOSTI A MÚDROSŤ Tieto pojmy si treba hneď na začiatku ujasniť a chápať ich, aby sme vedeli o čo nám v procese spracovania dát vlastne ide [1, 2]. DÁTA - sú holé fakty, sami o sebe nám nič nehovoria, napr.: Prší, Audi, INFORMÁCIE sú to vlastne vzťahy medzi dátami, označujú súvislosti medzi nimi, odpovedajú na otázky kto?, čo?, kde?, ako?, atď. napr.: V Žiline prší, Červené Audi najazdilo km. ZNALOSŤ je to súhrn dát a informácií, ktorých obsah nám môže byť užitočný. Odpovedá na otázku Ako? Vhodným príkladom je učenie malej násobilky žiakov na základnej škole. Pamätajú si všetky kombinácie násobenia (napr. 8x8=64, 8x9=72 atď.) a vedia tieto informácie používať. Avšak keď sa ich spýtate koľko je 233x45, to vám už povedať nevedia, lebo takú informáciu nemajú. MÚDROSŤ je to schopnosť z dát, informácií a znalostí chápať princípy a na ich základe vytvárať ďalšie dáta, informácie a znalosti. Napríklad ak spomínaní žiaci vedia násobiť všeobecne všetky čísla na základe znalosti malej násobilky. Musia chápať princíp násobenia. Všeobecne je cieľom spracovania dát získanie nových a nepoznaných informácií, znalostí a múdrosti (viď obr. 1), ktoré nám po aplikovaní prinesú zisk, alebo sú pre nás prospešné. V dnešnej dobe sme zahltený dátami a informáciami a preto na tento proces spracovania používame stroje. V databázach sú uložené dáta a informácie za nejakým konkrétnym účelom, potenciál dát je však často krát oveľa väčší, nad rámec stanoveného účelu. Zoberme si príklad malého obchodu. Eviduje sa tu každý nákup za účelom účtovania. Z týchto dát však taktiež môžeme zistiť, ktoré výrobky ľudia najviac kupujú, kedy je zákazníkov v obchode najviac, či sa oplatí mať obchod otvorený aj v sobotu a podobne. V tomto prípade berieme do úvahy len nejakú lokálnu databázu, predstavme si však, že takéto DBS môžu byť prepojené, môžu mať archívy z predošlých rokov atď.. Správnymi prostriedkami spracovania môžeme z nich vydolovať prospešné informácie a znalosti aplikovateľné v praxi. Obr. 1 Zobrazenie prechodu od dát až k múdrosti. Medzi každým prechodom je potrebné spracovanie [1]. 4

11 2 DATABÁZOVÉ SYSTÉMY S nástupom informačných technológií nastával postupne aj problém s ukladaním a distribúciou dát. Zo začiatku boli dáta a prístup k nim súčasťou aplikácie, čo bolo dosť obmedzujúce hlavne pri väčších aplikáciách. Keď máme dáta závislé na aplikácií a naopak už pri menšej zmene jedného musíme meniť aj to druhé. Postupne sa však programy začali oddeľovať od dát a manipulácie s nimi a vznikali programy konkrétne na spravovanie a manipuláciu s dátami Databázové Systémy. Historické míľniky rozvoja databázových systémov je možné definovať nasledovne [21]: Súborové databázy Dáta boli uložené v súboroch, na manipuláciu s nimi bolo potrebných jeden alebo viacero programov (písaných zväčša v jazykoch COBOL alebo BASIC). Mali zásadné nedostatky ako silné naviazanie dát na konkrétny program, redundanciu dát, slabé zdieľanie a zabezpečenie. Hierarchické a sieťové databázy Hierarchické DBS mali stromovú štruktúru a nevýhody spojené s tým ako neexistencia vzťahu M:N, taktiež pri zmene dát boli potrebné zmeny v programe, čiže závislosť programu na dátach. Sieťové DBS mali štruktúru acyklického grafu, čo dovoľovalo existenciu vzťahu M:N, ale vyhľadávanie v nich bolo náročnejšie ako v hierarchických DBS. Relačné databázy V 70-tych rokoch vznikajú Relačné DBS, ktorých najväčší rozvoj bol v 80-tych rokoch, ale používajú sa dodnes a momentálne sú najrozšírenejšie. Sú postavené na matematickej teórií množín s využitím relačnej algebry a kalkulu. Veľmi dobre je oddelená logická a fyzická reprezentácia dát. Objektové a XML databázy Jedná sa buď o samostatné riešenia, alebo nadstavbu relačných DBS. Objektové DBS umožňujú efektívnejšie uloženie dát vzhľadom na ich ďalšie použitie v aplikácií. Sú vhodné pre objektovo orientovane programované aplikácie, avšak oproti relačným databázam neprinášajú významný výkonnostný nárast. XML DBS umožňujú ukladanie dát v XML formáte, ktorý je momentálne často používaný. Ich výhodou je, že XML jazyk nie len dáta uchováva, ale ich aj popisuje a dáta sú v ňom štruktúrované. 2.1 RELAČNÉ DATABÁZOVÉ SYSTÉMY Vzhľadom na to, že sú relačné DBS momentálne najrozšírenejšie a najpoužívanejšie, tak sa ich budem snažiť bližšie priblížiť a takisto použiť a stavať na nich pri riešení mojej dizertačnej práce. V relačnom DBS sú dáta organizované v tabuľkách (viď obr. 2). Tabuľka (relácia) obsahuje riadky (N-tice), ktoré majú rovnaké atribúty (stĺpce). N-tice nemusia byť usporiadané. Tabuľky na seba navzájom môžu odkazovať, napríklad na obr. 2 vieme podľa atribútu ID_OSOBY zistiť, ktoré autá sú na akú osobu zaevidované. Veľmi dobrá literatúra Obr. 2 Ukážka dvoch relácií (tabuliek) znázorňujúce vzťah 1:N. 5

12 k problematike relačných DBS je [3, 4]. Ako som už spomínal relačné DBS sú založené na matematickej teórií množín a relačnej algebre. Pomocou operátorov relačnej algebry sprístupňujeme uložené dáta a vyberáme si z nich také podmnožiny, ktoré nás zaujímajú a ktoré hľadáme RELAČNÁ ALGEBRA Základom v relačnej algebre [5] je relácia, aby sme mohli definovať reláciu musíme najskôr definovať karteziánsky súčin. Definícia 2.1 (Karteziánsky súčin množín) Majme dve neprázdne množiny A = {a 1, a 2,... a n}, B ={b 1, b 2,...b n}. Karteziánskym súčinom množín A, B nazveme množinu C = A B všetkých usporiadaných dvojíc [x, y], kde prvý prvok dvojice patrí do množiny A a druhý prvok do množiny B. [ ] Definícia 2.2 (Relácia) Ľubovoľnú podmnožinu karteziánskeho súčinu množín A B nazveme reláciou nad množinami A, B. Definície platia všeobecne pre N množín. Každá množina A, B,..., N predstavuje vlastne atribút, alebo stĺpec tabuľky. Na obrázku 3 máme reláciu OSOBA, má atribúty MENO, PRIEZVISKO a ID_OSOBY. Atribút MENO je množina, ktorá obsahuje všetky možné prípustné mená, PRIEZVISKO všetky prípustné priezviska atď. Relácia alebo tabuľka OSOBA je podmnožinou karteziánskeho súčinu množín MENOxPRIEZVISKOxID_OSOBY. Z faktu, že pri množinách sa neuvažuje o poradí, sú neusporiadané, vyplýva, že ani pri reláciách sa neuvažuje o poradí a teda dve tabuľky, ktoré sa líšia len poradím riadkov považujeme za rovnaké relácie. Obr. 3 Tabuľka (relácia) OSOBA s atribútmi MENO, PRIEZVISKO a ID_OSOBY. Na reprezentáciu relácií a manipuláciu s dátami relačná algebra obsahuje 8 operátorov: Selection (selekcia) Projection (projekcia) Product (karteziánsky súčin) Union (množinové zjednotenie) Difference (množinový rozdiel) Intersection (množinový prienik) Join (spojenie) Divide (podiel) Prvých 5 operácií je základných, ostatné môžu byť pomocou nich definované. Po aplikovaní ľubovoľnej operácie nad reláciou/mi je výsledkom tiež relácia. Operácie môžeme ľubovoľne kombinovať a vnárať. Našim cieľom je naformulovať operácie nad reláciami tak, aby sme získali požadovanú výslednú reláciu. 6

13 Selection (selekcia, horizontálna reštrikcia) Pomocou selekcie vyberieme z relácie potrebné riadky na základe súboru podmienok. Podmienky môžu byť jednoduché, alebo zložené obsahujúce relačné (>, <, = a iné.), alebo logické operátory. Obr. 4 Selekcia, výber všetkých riadkov, kde atribút A nadobúda hodnoty a 2. Projection (projekcia, vertikálna reštrikcia) Projekciou vyberáme špecifikované stĺpce. Takisto môžeme pomocou nej preusporiadať ich poradie. Obr. 5 Projekcia, nová relácia vzniká vybratím špecifikovaných stĺpcov z pôvodnej relácie. Product (karteziánsky súčin) Spáruje každý riadok tabuľky A s každým riadkom tabuľky B. ( Obr. 6 Karteziánsky súčin tabuliek. 7

14 Union (zjednotenie) Zjednocuje union-kompatibilné relácie, tj relácie, ktoré majú rovnaký počet, typ, a poradie atribútov. Vytvorená relácia obsahuje všetky riadky z oboch relácií. Difference (rozdiel) Rozdiel dvoch relácií nám vytvorí novú reláciu, ktorá obsahuje všetky riadky patriace do prvej relácie, ktoré však neobsahuje druhá relácia. Relácie musia byť union-kompatibilné. Toto je 5 základných operácií relačnej algebry, pre úplnosť sa niekedy uvádza aj 6ta základná operáciu rename (premenovanie stĺpca/ov). Rename (premenovanie) Táto unárna operácia premenuje jeden, alebo viacero atribútov relácie. Join (spojenie, vertikálna rekonštrukcia) Spojenie dvoch tabuliek na základe spoločného atribútu, alebo atribútov. Obr. 7. Spojenie dvoch tabuliek na základe spoločného atribútu C. Join nie je základným operátorom relačnej algebry, môže byť teda nahradený napr. konkrétne relácia REL_C z obr. 7: Operácia Join má viacero variácii, najznámejšie z nich sú: natural join spája tabuľky podľa rovnako pomenovaných atribútov, θ-join (theta join), equijoin theta join, všeobecný koncept joinu, spája relácie na základe podmienky, ktorá musí platiť medzi hodnotami atribútov, ak je táto podmienka rovnosť, tak sa jedná o equijoin, semijoin ( )( ) spojí relácie ako join, ale výsledkom je relácia len s atribútmi prvej (resp. druhej) relácii, antijoin ( )( ) vráti riadky pôvodnej relácie, ktoré nespojí s druhou reláciou, left outer join ( ) ako join, ale k nespojeným riadkom pridá prázdne hodnoty na miesto hodnôt z druhej relácie, 8

15 right outer join ( ) k nespojeným riadkom pridá prázdne hodnoty na miesto hodnôt z prvej relácie, full outer join ( ) pridá prázdne hodnoty k nespojeným riadkom. Join je často používaná a dôležitá operácia, lebo spája tabuľky. Je však aj výpočtovo najzložitejšia (viď Optimalizácia dotazov). Relačná algebra a jej operácie nám slúžia na manipuláciu s dátami a vyberaním požadovaných informácií z nich. Ako však dáta vhodne rozdelíme do relácií nám nehovorí. Zostavovaním relačných dátových modelov sa preto venujem v nasledujúcej podkapitole DÁTOVÉ MODELOVANIE Pri návrhu každého väčšieho informačného systému sa jeho dátová časť modeluje a navrhuje osobitne. Jednak kvôli zložitosti, ale tak isto aj preto, aby boli dáta čo najmenej redundantné a efektívne rozložené. Výsledkom dátového modelovania je dátový model. Všeobecne sa pod dátovým modelom rozumie abstraktný model, ktorý popisuje ako sú dáta reprezentované a ako sa k nim pristupuje [6]. Dátové modelovanie je vlastne postup pri vytváraní dátového modelu. Dátové modely môžeme chápať na troch úrovniach: konceptuálnej modeluje koncepty, ich vlastnosti a vzťahy medzi nimi, ide o najvšeobecnejšiu formu dátového modelu, logickej jedná sa už o dátový model na konkrétnu aplikáciu pomocou konkrétnej technológie avšak ešte s niektorými zanedbanými prvkami (dátové typy, integritné obmedzenia, indexy pre rýchle vyhľadávanie), fyzickej detailný model použiteľný v aplikácii s konkrétnymi dátovými štruktúrami, typmi, obmedzeniami a pod. Pri dátovom modelovaní s relačnými DB sa používa Entitno Relačný model. Entitno relačný model (ERM) ERM (obr. 8) je dátový model špeciálne prispôsobený na modelovanie relačných databáz. Entity sú tabuľky a reláciami chápeme vzťahy medzi nimi (cudzie kľúče). Úlohou analytika pri návrhu ERM je rozdeliť dáta do tabuliek a vytvoriť vzťahy medzi tabuľkami, ktoré na seba odkazujú. Vhodná analýza a návrh ERM sú dôležité následne pri efektivite informačného systému. Tak isto sa návrh odráža aj pri dodatočných zmenách požiadaviek. Ak je ERM dobre navrhnutý, ľahko sa do neho pri zmene požiadaviek implementujú zmeny, inak je niekedy potrebná aj jeho úplná zmena čo je časovo aj finančne náročné. Pri dátovom modelovaní sa zvyčajne používajú CASE nástroje, ktoré podporujú pri vytvorení dátového modelu generovanie skriptov, ktoré nám reálne databázu vytvoria presne podľa modelu alebo aj naopak. Dokážu z existujúcej databázy automatizovane vytvoriť dátový model (ERM), prípadne dokumentáciu a pod. Príklady takýchto nástrojov sú Toad Data Modeler, Erwin, DB Schema (obr. 8), Enterprise Architect a iné. Návrhu ERM a dátovému modelovaniu sa podrobne venuje literatúra [3, 4, 6]. 9

16 Obr. 8. Príklad logickej vrstvy ERM databázy filmov vytvorenej pomocou CASE nástroja DB Schema DATABÁZOVÉ JAZYKY Na komunikáciu s DBS nám slúžia databázové jazyky [3, 4, 7], tiež známe ako dotazovacie jazyky (Query languages). Pomocou nich môžeme konkrétnu databázu vytvoriť, upravovať ju, sprístupňovať a meniť požadované dáta. Najrozšírenejším databázovým jazykom je SQL, používa sa pri relačných databázach. Sú aj iné DB jazyky napr. XQuery (slúži na prácu s XML dokumentmi), MDX (pre OLAP databázy), COQL, MQL a iné. Štandardne sú DB jazyky neprocedurálne, tj. vyjadrujeme nimi aké dáta požadujeme, nie akým spôsobom sa to má vykonať, ale sú rôzne podpory a nadstavby aj na procedurálnu funkcionalitu. Za pomoci rozhrania určeného na prepojenie medzi informačným systémom, alebo aplikáciou a DBS (napr. ODBC, Open DataBase Conectivity) môžeme priamo v kóde používať DB jazyky na získavanie dát a manipuláciu s nimi. Rozhranie tiež zabezpečuje prístup k vzdialeným DBS, či už na LAN, alebo WAN. SQL (Structured Query Language) Jazyk SQL sa používa pri relačných DBS. História tohto jazyka začína v roku 1974 vo firme IBM. Tu bol vyvinutý jazyk SEQUEL, ktorý sa neskôr po výrazných úpravách premenoval na SQL. V rokoch bol štandardizovaný a prijatý organizáciami ANSI a ISO. Od vtedy bol viac krát revidovaný až po súčasný SQL Všeobecne sa jazyk SQL dá rozdeliť nasledovne: DDL (Data Definition Language) slúži na vytvorenie, upravenie, alebo zrušene tabuliek a vzťahov medzi nimi, definuje tiež typy, obmedzenia, alebo iné DB objekty, príkazy DDL sú CREATE, ALTER, DROP. 10

17 DML (Data Manipulation Language) manipuluje s dátami, pridáva, maže, upravuje, alebo sprístupňuje dáta z tabuliek, taktiež agreguje dáta, alebo vykonáva funkcie nad nimi. Práve DML nám dovoľuje využiť silu relačnej algebry a kalkulu nad reláciami. Medzi príkazy DML patria SELECT, UPDATE, DELETE, INSERT. DCL (Data Control Language) príkazmi GRANT a REVOKE môžeme upravovať práva používateľom, alebo skupinám na prístup a manipuláciu s dátami, objektmi, alebo tabuľkami. DDL Physical Design DML Implementation DCL Maintenance Obr. 9. DDL, DML, DCL a proces vývoja databázy [2]. Štandardne je jazyk SQL neprocedurálny a aj preto si ho väčšina firiem vyvíjajúcich DBS rozširuje o niektoré vlastné prvky. Napríklad firma ORACLE má PL/SQL, POSTGRES PL/pgSQL, MICROSOFT T-SQL atď. Ak však chceme mať aplikáciu nezávislú od výrobcu DBS, mali by sme sa držať štandardu SQL OPTIMALIZÁCIA DOTAZOV Veľmi dôležitým procesom pri spracovaní SQL požiadavky v DBS je optimalizácia dotazu [8, 9]. Na obrázku 10 vidíme proces spracovania SQL požiadavky. Najskôr sa parserom syntakticky rozanalyzuje požiadavka. Takto spracovaná požiadavka je v tvare výrazu relačnej algebry. Optimalizácia dotazu je problém spojený práve s úpravou výrazu do takého tvaru, aby bol čas, alebo počet IO operácií, alebo iný faktor minimalizovaný. Nájdenie optimálneho plánu by však mohlo byť časovo zložité a preto sa na minimalizáciu používajú heuristiky 1, ktoré sú prakticky overené a dávajú vo väčšine prípadov slušné riešenia. Na rýchlosti vykonania požiadavky sa tiež podieľajú iné faktory ako napr. spôsob prehľadávania v tabuľke (index scan, full scan, hash scan), taktiež je niekedy vhodné pri porovnávaní dvoch množín atribútov ich utriedenie a až potom následné porovnanie a podobne. Pri úprave samotného algebrického výrazu sa používajú pravidlá, ktoré neovplyvnia výslednú reláciu. 1 Heuristika optimalizačný algoritmus bez záruky nájdenia najlepšieho riešenia. 11

18 Obr. 10. Proces spracovania SQL dotazu po jeho vykonanie [8]. Príklad niektorých pravidiel: komutatívnosť a asociatívnosť joinu pravidlá pre operácie výberu a projekcií cond1cond2(r) cond1( cond2(r)) cond1( cond2(r)) cond2( cond1(r)) col(r) col( col`(r)), ak col col` col( cond(r)) cond( col(r)) Z týchto ale aj ďalších pravidiel [8] sa konštruujú tzv. stromy vykonania (viď obr. 11). Výsledkom každého z nich je tá istá relácia avšak s inou náročnosťou a časom vykonania pre DBS. Úlohou DB optimalizátora je nájsť čo najlepší strom vykonania. Príklad stromov vykonania pre konkrétny SQL dotaz môžeme vidieť na obrázku 11. select name, floor from emp, dept where emp.dno=dept.dno and sal>100k; 12

19 Obr. 11. Rôzne stromy vykonania pre rovnaký SQL dotaz [8]. Niektoré DBS ponúkajú pre užívateľov možnosť ovplyvniť plán vykonania. Určené je to pre skúsených užívateľov, ktorí vedia najmä z charakteru dát vytušiť ktorý plán je ako efektívny pri konkrétnej požiadavke. Efektívnosť a výkonnosť vykonania dotazu sa dá tiež ovplyvniť vytvorením vhodných indexov nad množinami atribútov tabuliek, ktoré sa často používajú pri sprístupnení dát. Moderné DBS ponúkajú aj možnosť paralelného vykonávania dotazov čo môže tiež urýchliť vykonanie požiadavky TRANSAKČNÉ A ANALYTICKÉ DATABÁZY (DÁTOVÉ SKLADY) Z hľadiska použitia, účelu a stálostí dát sa dajú databázy rozdeliť na transakčné a analytické [10, 11, 12]. Kým dáta v transakčných DB sú v čase meniace sa a ich účelom je popisovať súčasný stav systému, analytické DB slúžia na uchovávanie historických dát, výsledkov hospodárenia a dáta, ktoré sa tu uchovávajú by sa nemali meniť, ale iba pridávať. Transakčné DB (OnLine Transactional Processing OLTP) Tieto databázové systémy sú určené na bežné transakcie ako vkladanie, mazanie, sprístupnenie a zmenu dát. Pod transakciou sa rozumie usporiadaná n-tica príkazov pre prácu s údajmi v DB. Snažia sa popísať aktuálny stav firmy, skladu a podobne. Sú normalizované s minimálnou redundanciou dát. Transakčný model spracovania dát je založený na ACID pravidlách: Atomicity - transakcia sa vykoná úplne, alebo vôbec. Consistency - DB je pred a po vykonaní transakcie konzistentná. Isolation - dve rôzne transakcie sa navzájom nemôžu ovplyvniť. Durability - ukončené transakcie nie je možné prerušiť alebo zmeniť ich výsledok. Dátové sklady a Analytické DB (OnLine Analytical Processing OLAP) Dátové sklady (DS) sa používajú na uchovávanie väčšinou podnikových dát veľkých objemov za účelom ich analýzy. DS integrujú dáta z rôznych, aj nehomogénnych, zdrojov a preto je potrebné ich zjednotiť, očistiť a zabezpečiť ich konzistentnosť. Do DS sa dajú dáta len zapisovať a čítať, čiže pri zmene dát sa musí vytvoriť nový záznam. Takýmto spôsobom je zaznamenávaná história 13

20 dát. Z týchto predpokladov je možná na základe histórie a vývoja dát a informácií analýza, ktorá slúži ako podpora pri rozhodovaní pre firmu. DS sú optimalizované na čítanie, obsahujú nenormalizované dáta, často aj agregované. Charakteristické pre DS je predovšetkým stálosť dát a nevyžaduje sa až tak ich aktuálnosť. Stačí ak sú dáta posielané zo zdrojov v časových intervaloch tak, aby ich to nezaťažovalo a nepomaľovalo ich chod. OLAP OLAP je súhrn technológií a prostriedkov umožňujúcich analýzu multidimenzionálnych dát. Multidimenzionálne dáta sú ekvivalentom tabuľky v relačnej databáze. Taktiež to môže byť chápané ako n rozmerné pole. Pri dimenzii 3 sa hovorí o tzv. OLAP kocke (OLAP CUBE) (viď obr. 12). Obr. 12. OLAP kocka, dimenzie sú regióny, produkty a čas. Hlavnou úlohou OLAP je poskytovať multidimenzionálne pohľady na dáta a operácie s nimi ako (slice, dice, roll-up, drill-down, pivot, rôzne agregačné, matematické funkcie a iné.). Popis je možné nájsť napr. v [10] DISTRIBUOVANÉ DB SYSTÉMY (DDBS) DDBS je množina uzlov počítačovej siete, navzájom prepojených v komunikačnej sieti pričom každý z uzlov je samostatný databázový systém, tieto uzly navzájom spolupracujú tak, že z každého uzla je možné sprístupniť údaje uložené na inom uzle presne tak, akoby boli umiestnené na vlastnom uzle [15]. Inými slovami DDBS zabezpečuje prístup ku viacerým logicky prepojeným DBS tak, aby sa tvárili pre užívateľa ako jeden centralizovaný DBS. C. J. Date definoval 12 vlastností, ktoré by mal splňovať ideálny DDBS: Lokálna autonómnosť Nezávislosť na centrálnom uzle Súvislá prevádzka Nezávislosť na umiestnení dát Nezávislosť na fragmentácií dát 14

21 Nezávislosť na replikácií dát Spracovanie distribuovaných dotazov Distribuované riadenie transakcií Nezávislosť na technickom vybavení Nezávislosť na operačnom systéme Nezávislosť na komunikačnej sieti Nezávislosť na lokálnych DBS Tieto vlastnosti sa nie vždy všetky dodržujú, taktiež na DDBS neexistuje štandard, ktorý musí každý DDBS spĺňať. Dôvodom prečo sa používajú DDBS sú výhody, ktoré z toho plynú: Lokálna autonómnosť Zvýšenie výkonu Zvýšenie spoľahlivosti Zvýšenie dostupnosti dát Vyššia zdieľateľnosť dát Rozširovateľnosť Ekonomická efektívnosť Za hlavné nevýhody DDBS sa považuje zložitosť tohto systému, z toho vyplývajúca cena, riadenie distribuovaného spracovania, zvýšené nároky na bezpečnosť a iné. Problémy spojené s DDBS sa dajú klasifikovať nasledovne: Návrh distribuovaných databáz Distribuované spracovanie dotazov Distribuované riadenie katalógov Distribuované riadenie transakcii Distribuované riadenie paralelného spracovania transakcií Pri návrhu DDBS môžeme zvoliť rôzne stratégie podľa toho ako riadime operácie (synchrónne, asynchrónne) a podľa toho ako máme dáta po jednotlivých uzloch rozložené, či sa replikujú úplne, čiastočne, alebo vôbec. Podrobnejšie o DDBS v [13, 14, 15] FEDEROVANÉ DB SYSTÉMY Federovaný databázový systém spája viaceré autonómne databázové systémy do jedného celku. Tieto autonómne DB môžu mať rôznu štruktúru a obsah dát, môžu sa nachádzať na rôznych uzloch v sieti (podobne ako Distribuované DDBS) a dokonca to môžu byť databázy rôznych typov (relačné, objektové, XML a ďalšie) a od rôznych dodávateľov (IBM, Oracle, MySQL, atď.). Účelom federovaného databázového systému je poskytnúť také rozhranie nad týmito rôznymi DB systémami, ktoré by umožňovalo jednotný prístup a manipuláciu s dátami. Vytvoriť takýto systém je veľmi náročné, keďže spájané DB nie sú homogénne. Špeciálnym prípadom môže byť federovaný DB systém z výlučne relačných databáz. Heterogénnosť schém a údajov v tomto prípade v jednotlivých databázach prináša nasledujúce problémy: Rozdiely v schémach rovnaké tabuľky v rôznych schémach môžu byť pomenované rôzne alebo naopak rôzne nazvané tabuľky môžu byť ekvivalentné. Niektoré rovnaké informácie môžu byť vyjadrené v rôznych schémach rôznym počtom tabuliek alebo atribútov. Nad ekvivalentnými tabuľkami môžu byť rôzne integritné obmedzenia. 15

22 Rozdiely v údajoch okrem toho, že môžu byť údaje v niektorých ekvivalentných tabuľkách nesprávne alebo zastaralé, často sa stáva, že sú rovnaké údaje vyjadrované odlišne (napr. výborný/a/1 a pod.). Ďalej rôzne jednotky (teplota - C/F/K), presnosť, jazyk atď. Niekedy stačí ak federovaný DB systém umožňuje dáta len sprístupňovať a vyhľadávať medzi nimi a nie je nutné aby umožňoval tieto dáta meniť. 2.2 ROZSIAHLE DB, (VERY LARGE DATABASES) Pod pojmom rozsiahle DB (VLDB) sa myslia databázy enormnej veľkosti, alebo zložitosti [21, 87, 88]. V súčasnosti DB s miliónmi záznamov, rádovo stovkami až tisíckami tabuliek a giga až terabajtami dát. Tento pojem nemá jednoznačnú definíciu. Za rozsiahlu DB sa môže považovať aj databáza zložitého modelu alebo s veľkým počtom súčasne pracujúcich užívateľov. Každoročne sa koná medzinárodná konferencia (International Conference on VLDB, tento rok už 39ta), ktorej účastníkmi sú veľké firmy ako Oracle, Microsoft, Google, IBM, SAP, Sysbase, Yahoo, HP, Sun, facebook a iné, špička v informačných technológiách, aby sa stretli, prezentovali vlastné riešenia, vymenili si svoje know how a riešili tento problém. VLDB problémy by sme mohli rozdeliť do dvoch základných typov: problémy spojené so štruktúrou (schéma DB, dátové modelovanie) problémy s dátami samotnými a získavaním informácii z nich (data mining) Pri relačných databázových systémoch nám popisuje štruktúru a vzťahy relačný databázový model. Už ten samotný tvorí pridanú hodnotu databázového systému. Ak je dobre navrhnutý, je nositeľom skrytej informácie, čo si nie všetci uvedomujú. Pri veľmi veľkých RDB nie je problém len s návrhom tohto modelu, ale neskôr najmä s jeho pochopením a orientovaním sa v ňom. Pri práci s RDB schémou s viac ako stovkou tabuliek a rádovo rovnakým počtom vzťahov medzi nimi je ťažké sa vyznať a pochopiť ju do takej miery, aby bolo možné vedieť, ktoré informácie kde hľadať. Pre databázových architektov vznikajú zase iné otázky: Ako RDB model optimalizovať? Ktoré tabuľky a vzťahy sú kľúčové, alebo kritické? V súčasnosti sa tieto problémy riešia viacerými spôsobmi (2.2.3 RDB Metriky a Rankingy, 5 Vizulalizácia dát) a existuje zopár nástrojov k takýmto účelom (IBM SPSS Modeler, Bellman data profiler, Polaris interactive DB visualization a iné) PROBLÉMY VEĽKÝCH DATABÁZ Veľké firmy často používajú viacero databáz. Jednu môžu mať napr. na evidenciu zamestnancov, ďalšiu na informácie o zákazníkoch a ďalšie môžu mať jednotlivo napr. pre každý produkt, ktorý ponúkajú. Tieto databázy zvyknú byť nesprávne štruktúrované, nezdokumentované, často obsahujú redundantné dáta a zamestnanci sa v nich len ťažko vyznajú. Ďalším faktorom, ktorý tento problém ešte viac rozvíja je ten, že každá databáza sa časom vyvíja, mení svoju štruktúru kvôli zmene a vývoju aplikácií, ktoré ju používajú. Vychádzajme z toho, že aj keď by každý databázový architekt, ktorý databázu navrhol, splnil svoju úlohu dokonale k aktuálnym požiadavkám, tak časom by sa pri ďalšom vývoji mohla jej štruktúra meniť a nie vždy správnym smerom. Niektoré banálne zmeny si vyžadujú novú tabuľku a prepojenie, keď je ich však viac, tak zmenu celej štruktúry. To sa však už málokedy robí, lebo je to finančne a časovo náročné. 16

23 Zmena štruktúry celej DB má dôsledky na aplikácie čo sú na nej závislé. Takto sa časom môže dostať databáza to takého stavu, že už aj ten čo ju navrhoval a vyvíjal sa v nej môže strácať. Čiastočným riešením je dodržiavanie istých zásad ako všetky zmeny dôsledne dokumentovať, alebo vytvoriť firemné štandardy pri tvorbe, úpravách a v názvosloví. Dôležité je tiež pravidelné čistenie databázy od nepotrebností. Pri orientovaní sa v neznámej alebo vzhľadom na štruktúru veľkej databáze máme väčšinou nedostatok metadát (dáta o dátach). Metadáta môžeme nájsť v dokumentácií a taktiež ich obsahujú aj systémové tabuľky RDB. V týchto tabuľkách môžeme nájsť informácie o jednotlivých tabuľkách, primárnych a cudzích kľúčoch, obmedzeniach, indexoch a pod. Z týchto metadát sa môžeme dosť o dátach dozvedieť avšak nie vždy sú kompletné. Návrhári RDB zriedka komentujú tabuľky na úrovni katalógu a niekedy dokonca ani neoznačujú primárne a cudzie kľúče. Dokumentácie sú nedostatočné aj z toho dôvodu, že RDB sa časom mení a dokumentácia sa neaktualizuje a potom je zastaraná PROBLÉMY INTERPRETÁCIE DÁT Správna interpretácia dát si vyžaduje v prvom rade pochopenie štruktúry a vzťahov v databáze. Komplikujú ju však nasledovné problémy: Názvy polí Názvy polí sú veľmi dôležité pri orientácií sa v RDB. Názov by mal zrozumiteľne a výstižne identifikovať účel objektu tak pre autora RDB ako aj pre ostatných užívateľov. Názvy v jednej RDB by mali byť konzistentné najlepšie aspoň podľa firemného štandardu. Nie je vhodné ak názvy obsahujú skratky, taktiež keď názvy obsahujú aj typ objektu napr. colname. Ide o redundantné informácie, ktoré nám zo začiatku môžu orientáciu uľahčiť, no v konečnom dôsledku sú však mätúce. Názvy by mali dodržiavať rovnakú konvenciu, nemali by sa v jednej RDB vyskytovať napríklad identifikátory ako middlename a middle_name. Konvenciu si treba na začiatku stanoviť a potom ju dodržiavať. Ďalším problémom je duplicita názvov. Napríklad v tabuľke osoba môžeme mať stĺpec meno a rovnako pomenovaný stĺpec máme aj v tabuľke firma. V takom prípade je vhodné názov buď upraviť, ak to však nejde spoliehať sa na to, že z kontextu sa to bude dať pochopiť. Heterogenita v databáze Heterogenita často nastáva medzi rôznymi DBS, ale nie ojedinele v rámci tej istej. Je spôsobená najmä ak má databáza viacero administrátorov alebo ich počas vývoja menila. Vzniká tiež pri úpravách RDB keď je náročné dodržať stanovenú konvenciu a tak sa porušuje. Kvalita dát Vysoko kvalitné dáta sú presné, aktuálne, zmysluplné a kompletné. Takéto dáta sú vhodné k použitiu pri podpore rozhodovania a získavania znalostí z nich. Práca s nekvalitnými dátami môže a spravidla dáva zlé výsledky a znalosti. Meranie kvality dát je veľmi dôležité pri ich použití. Medzi najčastejšie problémy kvality dát patria: chýbajúce dáta nie vždy máme všetky hodnoty záznamov k dispozícií, avšak takéto chyby môžu vznikať aj nesprávnym extrahovaním dát (viacnásobné alebo chýbajúce oddeľovače, chýbajúce záznamy sú vynechané a podobne), nesprávne hodnoty pri veľkom množstve záznamov je chybovosť veľmi pravdepodobná, napríklad údaj v zlých jednotkách, kódovanie znakov s diakritikou, nesprávne zadané hodnoty a iné, 17

24 spájanie tabuliek pri spájaní tabuliek sa nemusia vždy prepojiť všetky záznamy z čoho vznikajú nevyplnené polia (left join, right join). Dáta sa môžu javiť ako nekvalitné aj zlou interpretáciou. Napríklad keď zle pochopíme význam dát a použijeme ich na niečo iné ako sú určené. Metriky kvality dát Metriky kvality dát nám vyjadrujú a kvantitatívne popisujú kvalitu alebo dôveryhodnosť dát. Merajú spoľahlivosť a použiteľnosť údajov z viacerých pohľadov označovaných ako dimenzie kvality dát. Príklady metrík : počet riadkov obsahujúcich aspoň jednu nesprávnu hodnotu, počet duplicitných kľúčov, počet cudzích kľúčov, ktoré ukazujú na neexistujúci záznam, počet porúch systému pri pokuse vkladať nové dáta. Hodnotu môžeme vypočítať podielom počtu nájdených chýb a celkovým počtom chýb, ktoré mohli eventuálne nastať. Metriky kvality dát sa dajú definovať aj tak, aby nám mohli vyjadriť zhodu s procesnými tokmi. Vznikajú kontrolné databázy pre podporu podnikových operácií pre účel udržania kvality dát, ktoré sú schopné odhaliť okrem chybných dát aj chyby v procesoch. Tieto metriky môžeme deliť na: operačné identifikujú odchýlky procesov od špecifikácie, ktoré pôsobia ako chyby kvality dát a napomáhajú ich úprave, diagnostické len odhaľujú chyby v údajoch. Implementácia metrík kvality dát sa skladá z troch častí: 1. Príprava dát zber, ukladanie, integrácia a manipulácia. 2. Spoznávanie oboru prostredníctvom interakcie so správcami, formulácia podnikových pravidiel, návrh relevantných metrík. 3. Validácia dát a kvantifikácia ich kvality metrikami. Tento postup sa opakuje až kým sa analytici a používatelia nezhodnú na použiteľnosti dát. Použitie tohto postupu je náročné najmä kvôli potrebe odborníkov na kontrolu dát. Pri používaní týchto metrík sa vytvára dokumentácia a metadáta o dátach a procesoch. Mechanizmus riadenia pravidelnej kontroly chýb môže zabrániť poškodeniu väčšej množiny dát, kde ich chceme integrovať. Dimenzie kvality dát Dimenzie kvality dát sú kvalitatívne ukazovatele kvality dát. Patrí medzi ne: Presnosť je to miera akou záznam zodpovedá charakteristikám modelovaných entít. Kompletnosť nie pre všetky atribúty dát sú vyplnené hodnoty. Povinné atribúty by mali byť vždy vyplnené hodnoty, nepovinné nemusia, ale už nám to zmenšuje kvalitu dát. Niektoré atribúty nemôžu byť vyplnené, napríklad prechodné bydlisko ak ho zákazník nemá a podobne. Aktuálnosť dáta je potrebné pravidelne aktualizovať, aby odrážali popis entít reálneho sveta. Neberie sa do úvahy pri historických alebo archívnych dátach. 18

25 Interpretovateľnosť niektoré údaje si nevieme bez dodatočného popisu správne interpretovať, napríklad ak máme údaj pri zamestnancovi výška platu nie je nám bez ďalších informácií jasné, či ide o hrubú alebo čistú mzdu a pod RDB METRIKY A RANKINGY Metrika ako pojem má viacero významov. V matematike je to napríklad funkcia, ktorá priradí dvom prvkom z rovnakej množiny ich vzdialenosť. Iný význam má metrika v muzikológií, literatúre a inde. V oblasti DB sa pod pojmom metrika chápe funkcia, ktorej vstupom je buď tabuľka, databáza, stĺpec, riadok, ich zoskupenie a pod. a výstupom je hodnota, miera na základe ktorej môžeme porovnávať dva a viac objektov rovnakého druhu [16-20, 87]. Príkladom metriky pre tabuľku môže byť počet riadkov, stĺpcov, počet užívateľských prístupov, zmeny dát a podobne. Keď vieme objekty porovnávať, tak môžeme uvažovať o ich podobnosti a dôležitosti. Najväčším problémom pri návrhu metriky je jej relevantnosť. Navrhnúť metriku môžeme ľubovoľne, aby nám však v praxi pomohla a odrážala náš úmysel, nie je to triviálne. Je dôležité si navrhnuté metriky overovať teoreticky, ale najmä empiricky (experimentmi, prípadovými štúdiami) [19] (viď obr. 13). Obr. 13. Proces tvorby metriky [19]. Medzi overené a používané tabuľkové metriky patria: Number of Record, RC (T) počet záznamov tabuľky, Number of Attributes, NA (T) počet atribútov v tabuľke, Table Size, TS (T) veľkosť tabuľky, vypočítame ako súčin RC (T) a NA (T), TS (T) = RC (T) * NA (T), Primary Key Size, PS (T) počet atribútov primárneho kľúča tabuľky, Number of Indices, NI (T) počet indexov definovaných nad tabuľkou, Number of Views, NV (T) počet pohľadov v ktorých sa používa tabuľka, Number of Child Tables, NC (T) počet tabuliek kde je cudzí kľúč primárnym kľúčom tabuľky T, Number of Parent Tables, NP (T) počet cudzích kľúčov v tabuľke, Number of References, NR (T) počet vzťahov tabuľky, NR (T) = NC (T) + NP (T), Depth of Relational Tree, DRT (T) najdlhšia referenčná cesta bez cyklov z tabuľky T do ľubovoľnej tabuľky databázovej v schéme. 19

26 Zoskupovanie metrík rôznych váh do jednej nazývame ranking. Výpočet rankingu R pre tabuľku T s metrikami M 1 až M n a váhami c 1 až c n sa vypočíta nasledovne: Pri skúmaní veľkej DB, tak isto ako pri skúmaní iných veľkých systémov, musíme na istých úrovniach pohľadu abstrahovať od nepodstatných častí aby nám neunikli tie kľúčové a aby sa dalo vôbec niečo skúmať. Práve pomocou systému metrík a rankingov môžeme objekty usporadúvať, rozdeľovať a filtrovať. 3 BIG DATA Fráza Big Data sa po prvý krát objavila v oblasti high performance computingu (HPC) v súvislosti s vizualizačnými platformami, cloudovými riešeniami a úložiskami dát. Big Data môžeme definovať ako súbory dát, ktoré sú tak enormne veľké, že ich nie je možné spracovávať, spravovať a manipulovať s nimi bežnými softvérovými nástrojmi na spracovanie dát v reálnom čase. Veľké môžu byť nielen z pohľadu veľkosti pamäti, ktorú zaberajú (rádovo giga, tera, peta bajty), ale aj z iných hľadísk ako je rýchlosť ich generovania, prenos a rôznorodosť. Zvyčajne nie sú veľmi alebo dokonca vôbec štruktúrované. Príkladom môžu byť dáta o počasí (senzory teplôt, vlhkosti, zrážok, smeru a sile vetra generované v intervaloch na rozľahlom území), ová komunikácia, návštevnosť stránok a iné. Zdroje Big Data by sa dali rozdeliť do troch skupín [34]: Traditional enterprise data (firemné dáta) sú zákaznícke dáta z CRM systémov, transakčné ERP dáta, dáta z internetových obchodov, účtovníctvo a pod. Maschine-generated / sensor data (strojmi a senzormi generované) zahŕňa dáta CDR (call detail records), rôzne logy z webových portálov a stránok, dáta generujúce senzory v továrňach, autách alebo iných strojoch a pod. Napríklad jeden motor lietadla dokáže vygenerovať 10TB dát za 30 minút. Denne sa uskutočňuje viac než 25 tisíc letov. Denný objem dát len z tohto zdroja by bol rádovo v petabajtoch. V ťažkom priemysle ako napr. rafinériách alebo petrochemickom je to podobne. Social data (sociálne) dáta, ktoré sú generované sociálnymi sieťami, blogmi, ale tiež aj používateľmi internetu, ktorí navštevujú ľubovoľné stránky. Napríklad len pri priemernom 140 znakovom tweete, Twitter generuje denne vyše 8TB dát. McKinsey Global Institute odhaduje, že veľkosť dát rastie zhruba 40% ročne a tiež odhadujú, že porastie 44 násobne medzi rokmi 2009 a Priekopníci v tejto problematike sú giganti ako Google a Yahoo. U nich vznikla potreba spracovávať takto rozsiahle neštruktúrované dáta a preto to začali riešiť medzi prvými. Webové portály týchto firiem začínali mať problém s vyhodnocovaním návštevníkov a ich správania sa. Bežné štatistické metódy sa so zvyšujúcim sa počtom užívateľov už nedali riešiť v reálnom čase. Big data si vyžaduje iný prístup k spracovaniu a to najmä distribuované spracovanie. Predchodcom systémov spracúvajúcich Big Data by mohli byť dátové sklady (Data Warehouse, Transakčné a analytické databázy). Dátové sklady (DW) majú tiež jednoduchšiu štruktúru dát. Dáta sú tu podobne ako v Big Data generované v intervaloch (denné, týždenné). Z týchto dát sa potom robia reporty a dotazy a slúžia pre podporu rozhodovania. Na spracovanie Big Data 20

27 však už DW výkonom nestačia. S nástupom a rozšírením webu, mobilných zariadení a aplikácií, a ďalších nových technológií vznikla aj zásadná zmena charakteru dát a spôsobu ich využitia. Tieto dáta už nie sú centralizované a ani veľmi štruktúrované (ako v DW) a je ich oveľa viac. V tomto smere sa hovorí o tzv. trojrozmernej veľkosti 3V. Volume (objem) množstvo dát, ktoré treba spracovať a ktoré sa permanentne generuje. Variety (rôznorodosť) rôznorodosť typu dát, neštruktúrované texty, polo štruktúrované data (XML), geografické dáta, rôzne logovacie dáta a iné. Velocity (rýchlosť) rýchlosť akou dáta vznikajú a potreba analýzy týchto dát v reálnom čase vzrastá vďaka pokračujúcej digitalizácií väčšiny transakcií, mobilnými zariadeniami a vzrastajúcim počtom internetových používateľov. Firma Oracle dokonca udáva aj štvrtý rozmer, pre nich teda 4V a to: Value (hodnota) ide o tzv. ekonomickú hodnotu informácie, ktorú môže súbor obsahovať. Typicky sú hodnotné informácie skryté vo veľkom množstve dát a naším cieľom je ich nájsť. Najbežnejšie sú dáta z Big Data vo forme tabuľky s menším počtom stĺpcov a veľmi veľkým počtom riadkov. Obrázok 14 nám zaujímavo ilustruje koľko dát sa kde vygeneruje za minútu. Aj takéto dáta spadajú do Big Data. Obr. 14 Obrázok ukazuje približne koľko dát sa kde vygeneruje za 60 sekúnd.[36] 3.1 HADOOP Hadoop je open-source softvérový famework od Apachu, ktorý ponúka vlastné kompletné riešenie uchovávania, spracovávania a analyzovania rozsiahlych dát (Big Data). Môžeme sa stretnúť tiež s pojmom Hadoop Ecosystem, ktorý zahŕňa celú škálu nástrojov a okrem Hadoopu tiež aj príbuzné projekty od Apachu na získavanie, spracovanie a analyzovanie rozsiahlych dát (Hive, Mahout, Hue, Avro, Flume, atď.). Väčšina týchto nástrojov je implementovaná v Jave. Hadoop vznikol na základe GFS (Google File System publikované v roku 2003), keď firma 21

28 Google zverejnila systém a know-how ako uchováva a spracováva rozsiahle dáta. Systém Hadoop je podľa mňa výnimočný tým, že nekladie vysoké nároky na hardvér a umožňuje spracovávať rozsiahle dáta aj na priemerných PC, avšak musí ich byť veľa. Je to distribuovaný systém rovnocenných prvkov, ktorý viacnásobne zálohuje dáta, kladie dôraz na vysokú priepustnosť pri zníženej latencii. Je špeciálne vyvinutý na operácie s rozsiahlymi dátami vzhľadom na ich veľkosť. Základ Hadoopu tvorí súborový systém HDFS a MapReduce framework. Obr. 15 Vľavo klasické oddelenie servera od dát. Vpravo Hadoop a sieť rovnocenných komponentov, kde každý má vlastné dátové úložisko [35] HADOOP DISTRIBUTED FILE SYSTEM (HDFS) Je to distribuovaný súborový systém určený pre Hadoop, ale použiteľný aj samostatne. Je dimenzovaný na vysokú priepustnosť za zníženej latencie. Typické súbory sú v gigabajtových veľkostiach. Súbory sú rozdelené do blokov o veľkostiach typicky 64 a 128 MB. Bloky sú replikované na viacerých uzloch (zvyčajne 3 násobná replikácia). Primárne bol systém určený iba na zápis, ale neskôr (HDFS-265) sa umožnilo aj pridávanie na koniec súboru (append). Tento systém má uzly na rôznych počítačoch prepojených sieťou. Je teda odolný aj voči výpadkom PC a internetu, ak máme dostatočný počet PC. Typicky sa tento systém inštaluje na viacero priemerne výkonných PC s pripojením na internet, ale používa ho aj napr. Oracle do svojich Engineered systémov (HW/SW platforma). Je to veľký počítač, ktorý obsahuje viacero menších samostatných jednotiek (PC), ktoré sú prepojené vysokorýchlostnou sieťou HADOOP MAPREDUCE Hadoop MapReduce je technológia, ktorá umožňuje paralelné spracovanie dát na súborovom systéme HDFS. V Hadoope sa spracovávajú dáta na každom uzle, čiže s dátami, ktoré uzol obsahuje sa urobí fáza MAP a potom sa zo všetkých čiastkových medzivýsledkov urobí fáza REDUCE. Výsledok sa zase uloží na HDFS, alebo ho môžeme použiť. 22

29 Obr. 16 MapReduce, najskôr sa predspracujú dáta na jednotlivých uzloch (MAP), potom sa vo fáze REDUCE spracujú všetky tieto dielčie dáta [35]. Uveďme si príklad: Chceme urobiť frekvenčnú analýzu slov z textov uložených na HDFS. V MAP fáze na každom uzle spracujeme všetky texty. For every line for each word emit key-value(word, 1) Potom si utriedime dielčie výsledky abecedne podľa slov a vo fáze REDUCE spočítame ich frekvencie. For each received key-value set(word, 1)... count = 0 for each key-value(word, 1) count++ emit(word, count) Podľa toho ako chceme dáta spracovať, môžeme si implementovať vlastné Mapper a Reduce interfejsy v Jave a vytvorený jar - súbor len vložíme do Hadoop klastra ĎALŠIE NÁSTROJE Z EKOSYSTÉMU HADOOP HIVE dátový sklad, ktorý umožňuje nad uloženými dátami spúšťať HQL (Hadoop Query Language) dotazy, tieto dotazy sú automaticky transformované do MapReduce úloh. Mahout je to knižnica použiteľná v Hadoope pre strojové učenie a data mining. PIG (Pig Latin script) skriptovací jazyk pre písanie dopytov(join, group, sort, filter) z HDSF, tento skript je transformovaný do MapReduce úloh. HBase NoSQL databáza. HUE webový framework pre Hadoop nástoroje. AVRO framework na serializáciu a desesializáciu. 23

30 3.2 NOSQL DATABÁZY NoSQL databázy sú určené na uchovávanie veľkého množstva dát. Nemajú relačný model, lebo nie sú určené pre štruktúrované dáta. Taktiež ako aj názov napovie, nepoužívajú na manipuláciu s dátami jazyk SQL. Sú optimalizované na sprístupňovanie a pridávanie dát. Dáta sú zvyčajne mapované systémom kľúč hodnota (key-value store). Ku každému záznamu sa môžeme dostať pomocou kľúča. Pri porovnaní s relačnými DB je to vlastne jedna veľká tabuľka s dvoma stĺpcami, kde prvý stĺpec je kľúč a druhý je záznam. NoSQL databázy používajú firmy ako Google, Amazon, Twitter pri analýzach dát od užívateľov kde už relačné DB nestíhajú. Fakt, že majú jednoduchú štruktúru a model umožňuje jednoduché zálohovanie a paralelné výpočty. Z pohľadu spôsobu ukladania dát sa rozdeľujú na: Úložisko kľúč - hodnota (Key-value store), Implementácia veľkých tabuliek (BigTable implementation), Úložisko dokumentov (Document store databases), Grafové databázy (Graph databases). Príklady voľne dostupných NoSQL databáz sú Hadoop HBase, Cassandra, MongoDB, CouchDB, exist a iné. 4 DOLOVANIE DÁT (DATA MINING) Pod pojmom Data mining (DM) alebo dolovanie dát sa označujú postupy a technológie nad dátami, ktoré zo vstupnej množiny alebo množín dát generujú informácie a znalosti, ktoré sú v nich skryté a o nich nevieme, respektíve o nich tušíme, alebo informácie, ktoré charakterizujú tieto skúmané dáta. Hlavným cieľom DM je extrahovať z dát informácie a transformovať ich do porozumiteľnej podoby na ďalšie použitie alebo na získanie znalostí z nich. DM sa komerčne využíva vo firmách najmä pre podporu rozhodovania a marketing. Tiež sa používajú vo vede, medicíne, technike a podobne. Data Mining ako proces pozostáva z niekoľkých fáz: Čistenie dát vstupné dáta musíme pre použitím očistiť od irelevantných alebo chybných častí, ktoré by mohli výsledok skresliť. Integrácia dát očistené dáta získané z rôznych zdrojov potrebujeme integrovať do jednotného formátu. Selekcia dát vyberieme zo vstupných dát tie, ktoré sú relevantné pre náš výskum alebo účel. Na tento krok musíme dobre poznať doménu skúmaných dát. Pri neznalosti domény je lepšie tento krok vynechať. Transformácia dát atribúty dát je niekedy potrebné upraviť do vhodnej podoby akú potrebujú konkrétne algoritmy a metódy dolovania. Dáta sa tiež transformujú za účelom zjednodušenia, keď nepotrebujeme niektoré detaily. Dolovanie aplikovanie algoritmov DM na dáta a získanie informácií z nich. Ohodnotenie získaných informácií získané informácie ohodnotíme z hľadiska praktickej použiteľnosti a požadovanej presnosti. Prezentácia získaných informácií získané informácie musíme správne prezentovať, aby sme ich mohli čo najjednoduchšie pochopiť, efektívne skúmať a využiť. V tejto fáze je vhodné použiť vizualizačné techniky (viď kap. 5. Vizualizácia dát). Úlohy DM, vzhľadom na to čo hľadáme, sa dajú rozdeliť do dvoch kategórií: 24

31 Prediktívne úlohy (predictive task) hlavným cieľom je tu predpovedať na základe nami známych atribútov neznámy atribút. Výstupom je najčastejšie model, ktorý reprezentuje súbor pravidiel, ktoré na základe hodnôt známych atribútov určujú hodnoty hľadaných atribútov (klasifikačné pravidlá, rozhodovacie stromy) alebo dátová štruktúra čo predikuje tieto atribúty (napr. neurónová sieť). Popisné úlohy (descriptive task) tu je hlavným cieľom získať vzor, popis, charakteristiku alebo vzťahy medzi dátami (koreláciu, trendy, zhluky, trajektóriu, anomálie apod.). Ďalej môžeme úlohy DM rozdeliť do šiestich tried: Detekcia anomálií (anomaly detection) identifikácia zriedkavých záznamov, vybočujúcich z priemeru. Asociačná analýza (association rule learning) vyhľadávanie vzťahov medzi premennými, napríklad analýzou dát od kupujúcich zákazníkov v supermarkete zistíme, ktoré produkty sa kupujú spolu a túto informáciu využijeme v marketingu. Zhlukovanie, segmentácia (clustering) rozdelí záznamy do skupín bez to aby sme dopredu vedeli do akých a na koľko skupín ich chceme deliť. Klasifikácia (classification) priradí záznamy do vopred definovaných, nami známych skupín. Napríklad vyhodnotenie u či je to nevyžiadaná pošta. Regresia (regression) snaha o nájdenie takej funkcie, ktorá modeluje dáta čo najpresnejšie. Sumarizácia (summarization) prezentovanie dát a informácií prehľadne a čo najpochopiteľnejšie. Využíva sa tu najmä vizualizácia a patrí tu tiež tvorba reportov. DM je tiež kľúčový proces v hľadaní znalostí v databázach (knowledge discovery in databases - KDD). Na obrázku 17 môžeme vidieť kde sa nachádza DM v procese KDD. Input Data Data Preprocessing Data Mining Postprocessing Information Feature Selection Dimensionality Reduction Normalization Data Subsetting Filtering Patterns Visualization Pattern Interpretation Obr. 17 Proces objavovania znalostí v databázach a umiestnenie DM. [38] Pre DM sú na trhu dostupné komerčné nástroje (IBM SPSS Modeler, Oracle Data Mining, STATISTICA Data Miner, Microsoft Analysis Services, SAS Enterprise Miner a iné), ale aj opensource nástroje (Weka, Carrot2, ELKI, GATE, ML-Flex, JHepWork a iné). Medzi metódy DM sa radí aj vizualizácia (viď kap. 5. Vizualizácia dát). 5 VIZUALIZÁCIA DÁT Pri komunikácií medzi počítačom a človekom je veľmi dôležité efektívne podanie informácie. Na začiatkoch počítačovej éry boli vstupy a výstupy z PC podávané pomocou diernych štítkov, či diernych pások. Dnes je to väčšinou monitor a klávesnica. Rýchlosť pochopenia informácie 25

32 z dierneho štítku a monitora je pre človeka neporovnateľná a rozdiel je iba vo vizualizácií. Ďalšími príkladmi efektívnej vizualizácie je obr. 18, 19. Obr. 18 Skúste spočítať nuly na ľavom a na pravom obrázku. Vďaka efektívnej vizualizácii dokážete túto informáciu z dát získať rýchlejšie [26]. Pri vizualizácií je dôležité zobraziť kľúčové prvky tak, aby boli čo najjednoduchšie identifikovateľné človekom. Dobrá a efektívna vizualizácia nielen urýchľuje človeku získať informácie, ale taktiež môže podať informácie, ktoré nie sú zrejmé, tzv. skryté informácie. Naopak však, nevhodná vizualizácia nás môže zmiasť alebo skresliť fakty. V poslednej dobe sa vizualizácia tiež používa na skúmanie veľkých množín dát (sociálne siete, grafy, bioinformatika, medicínske dáta atď.) Obr. 19 Doktor vie určiť diagnózu z grafu, počítač však z čísel. Vizualizácia spája vedu, umenie a technológie za účelom lepšieho poznania objektu reálneho sveta. Obr. 20 Proces tvorby a použitia vizualizácie. 26

33 Pri vizualizácií dát vznikajú nasledovné problémy: Výber vhodnej vizualizačnej techniky vzhľadom na typ dát. Zobrazovanie multidimenzionálnych dát rieši sa buď prevodom do 1, 2 alebo 3 dimenzionálneho priestoru, alebo existujú techniky špecifické pre multidimenzionálne dáta (napr. paralelné súradnice [88]). Zobrazovanie veľkých množín dát keď je dát viac ako pixlov na výslednom obrázku, ťažko z takéhoto obrázku niečo vidieť, rieši sa to buď predspracovaním dát do prijateľnej formy, alebo technikami priesvitného kreslenia (alfa kompozícia) Príklady niektorých vizualizačných techník sú na obrázkoch Obr. 21 Tag cloud zobrazenie 50 najčastejšie používaných kľúčových slov v doterajšom (veľkosť predstavuje frekvenciu). texte Obr. 22 Vizualizácia sociálnej sieti facebook. Zobrazuje okolo 500 miliónov sociálnych kontaktov. 27

34 Obr. 23 Treemap zobrazuje hierarchické dáta v stromovej štruktúre. Konkrétne súborový systém (farby indikujú typ súborov). tento príklad Obr. 24 Paralelné súradnice technika používaná na zobrazovanie multidimenzionálnych dát [88]. 5.1 VIZUALIZÁCIA GRAFOV Vizualizovanie grafov je špecifická oblasť vizualizácií. Grafom sa myslí graf z teórie grafov, ktorý pozostáva z hrán, ktoré môžu byť ohodnotené, orientované, alebo aj viacnásobné a z vrcholov, ktoré môžu byť tiež ohodnotené. Vizualizujú sa z viacerých dôvodov, najmä kvôli lepšiemu pochopeniu, orientácií v nich, hľadaní skrytých informácií a podobne. Najznámejšou vizualizáciou grafov sú napr. mapy území, kde sú obce a mestá vrcholy a cesty medzi nimi hranami grafu. Ohodnotené môžu byť viacerými atribútmi, napr. hrany vzdialenosťou, typom cesty atď. a vrcholy počtom obyvateľov, rozlohou a podobne. Dôležité je tu najmä umiestnenie vrcholov a hrán z geografickej perspektívy. Vizualizovať však môžeme aj ostatné grafy, či už hierarchiu zamestnancov v podniku, interakcie proteínov, sociálne siete, 28

35 vzťahy medzi objektmi v databáze a ďalšie. Graf je možné vytvoriť z čohokoľvek kde majú nejaké entity alebo objekty vzťahy medzi sebou a následne ich môžeme skúmať a vizualizovať. Dobré skúsenosti s vizualizovaním grafov mám vo voľne dostupnom nástroji Gephi [42, 43]. Umožňuje grafy nielen vizualizovať, ale aj štatisticky spracovať (vypočítať parametre ako je napr. diameter, priemerný stupeň vrcholu a graf distribučnej funkcie stupňov vrcholov, Erdȍsové číslo, klasterizačný koeficient atď.). V nástroji je možné použiť známe algoritmy napríklad na automatické zaradenie vrcholov do tried na základe niektorých atribútov alebo rozmiestnenie grafu pri vizualizovaní. Nástroj ďalej umožňuje interaktívne skúmať a premiestňovať vizualizované vrcholy a hrany grafu, jednoducho ich dokážeme zafarbiť alebo im nastaviť veľkosť na základe zvolených metrík. Na obrázkoch 25 a 26 sú ukážky vizualizovaných grafov v tomto nástroji. Nástroj dokáže pracovať s grafmi do veľkosti desiatok tisíc vrcholov a hrán. Obr. 25 Vizualizácia chorôb a ich závislosti. Veľkosť vrcholu označuje početnosť výskytu. [44]. 29

36 Obr. 26 Vizualizácia grafu, ktorý je rozmiestnený podľa klastrov (farebne odlíšené) [45]. 6 ONTOLÓGIE Pojem ontológia je relatívne široký pojem a vo všeobecnosti označuje vedu o bytí, existencii alebo podstate vecí. Tento termín pochádza z filozofie a jeho korene siahajú až k gréckemu filozofovi Aristotelovi a jeho filozofii o metafyzike. V informatike sa tento pojem začal používať až v 80-tych rokoch minulého storočia. Definícií ontológií je z pohľadu informatiky viacero: Definícia 6.1. Ontológia je katalóg kategórií (typov) objektov, o ktorých sa predpokladá, že existujú alebo môžu existovať v určitej doméne záujmu D z pohľadu osoby, ktorá používa jazyk L pre potreby diskusie o témach z domény D [47]. Definícia 6.2. Ontológia je reprezentácia množiny konceptov v určitej doméne a vzťahov medzi nimi. Používa sa na uvažovanie o vlastnostiach tejto domény a môže byt použitá na definíciu domény [46]. Stručnejšia, ale aj tak výstižná a často používaná je definícia od W. N. Borsta z roku 1997, ktorú prevzal od Grubera 1993 a modifikoval. Definícia 6.3. Ontológia je formálna, explicitná špecifikácia zdieľanej konceptualizácie. 30

37 Ontológie sa z hľadiska spôsobu definovania pojmov delia na [47]: terminologické, formálne, založené na prototypoch, zmiešané. Terminologická ontológia je ontológia, ktorej pojmy nie sú špecifikované na základe axióm a definícií. Takéto ontológie iba zoraďujú pojmy do hierarchickej alebo stromovej štruktúry pomocou relácie generalizácie alebo špecializácie. Takéto ontológie sa používajú v prípadoch, keď definície jednotlivých pojmov nie sú potrebné alebo by bolo náročné ich zostaviť a stačí nám informácia o klasifikácii pojmov. Terminologická ontológia o pojmoch muž a žena uchováva informáciu, že sú to špecializácie pojmu človek, ale nie to, v čom sa tieto pojmy líšia. Formálna ontológia pojmy nielen klasifikuje, ale aj definuje na základe nejakých axióm. Formálna ontológia obsahuje napríklad o pojme muž informáciu, že je to osoba, ktorá má mužské pohlavie, pričom pojmy osoba, mužské a pohlavie sú tiež definované kategórie alebo axiómy. Ontológia založená na prototypoch je ontológia, ktorej kategórie sú rozlišované pomocou typických príkladov - prototypov a nie pomocou axióm a definícií. V takýchto ontológiách býva špecifikovaná aj hodnota sémantického rozdielu, pomocou ktorej môžeme posúdiť, do akej miery majú dva rôzne pojmy navzájom podobný význam. Zmiešané ontológie majú vlastnosti terminologických, formálnych aj prototypových. Základné, všeobecné kategórie môžu mat definície ako v terminologických ontológiách a konkrétnejšie pojmy môžu mat definované typické príklady. Vo všeobecnosti môžeme povedať, že ontológia nám popisuje nejakú špecifickú doménu a vzťahy medzi objektmi v nej. Obsahuje informácie a znalosti, ktoré sú tak popísané, že ich vieme spracovať aj strojovo. Dokonca môžeme pomocou známych algoritmov strojovo odvodzovať ďalšie pravidlá a znalosti. Databázy a iné zdroje dát tiež obsahujú dáta a informácie, ale na rozdiel od ontológií neobsahujú ich popis. V ontológiách je kladený dôraz hlavne na popis týchto dát a objektov, ktoré obsahujú. Podobne ako v objektovom programovaní ontológie obsahujú triedy a inštancie. Triedy môžu byť taktiež hierarchicky usporiadané (dedičnosť) viď obr. 27. Predok všetkých tried a inštancií je vec (thing), ktorá sa pre prehľadnosť nie vždy uvádza. Niekedy sa hovorí ešte aj o potomkovi všetkých tried (nothing). 31

38 Obr. 27 Na obrázku je ukážka hierarchického usporiadania tried v ontológii nutričných živín [51]. Každá trieda (class) obsahuje atribúty (data property), ktoré majú jej inštancie (instance, individual) definované. Tieto atribúty majú určený typ (range), ktorý môžu nadobúdať. Vzťahy môžu byť definované medzi triedami, ale aj inštanciami (object property), sú vždy obojsmerné resp. každý vzťah má aj inverznú variantu, ktorá sa nie vždy uvádza kvôli jednoduchosti. Na obrázku 28 vidíme ukážku časti ontológie s jej prvkami (ontológie zobrazujeme najčastejšie sieťovým grafom). Obr. 28 Ukážka časti ontológie v doméne vín. Sú tu triedy (čiernou), inštancie (červenou) [50]. Medzi najrozšírenejšie jazyky na reprezentáciu ontológií patria jazyky RDF a OWL, ktoré sú písane vo formáte XML. RDF Resource Description Framework RDF bol pôvodne určený na popisovanie zdrojov na internete. Je navrhnutý tak, aby bol ľahko spracovateľný počítačom. Ako som spomenul, je písaný vo formáte XML, aby bolo možné RDF súbory ľahko vymieňať medzi rôznymi typmi počítačov. Založený je na grafovom modeli, kde vrcholy predstavujú entity a sú pospájané orientovanými hranami. V RDF terminológií sa hovorí o tzv. tripletoch [podmet predikát - predmet] ([subject predicate - object]), kde každý vzťah je práve takto popísaný. Napr. Lopta je modrej farby je reprezentované tripletom [lopta - má farbu - modrá], ďalšie informácie o tej lopte môžu byť zase v ďalších tripletoch [lopta má tvar - guľa] alebo [futbal sa hrá s - lopta] a podobne. Keď ním popisujeme zdroje na internete, ako bol pôvodne navrhnutý, tak predmetom je URI (uniform resource identifier), adresa, ktorá identifikuje zdroj na internete napr. [ autor - Ľuboš]. Ku 32

39 každému tripletu môžu byť priradené aj atribúty čo zdroj ešte viac popisujú. Pri takejto forme jazyka by sme však ontológiu ešte nezapísali a preto vzniklo rozšírenie o triedy - RDF Schema (RDFS), kde je to už možné. Vízia konzorcia W3C je taká, aby boli internetové zdroje nie len popísané, ale aby nad nimi bola vytvorená ontológia, ktorá by definovala aj samotné triedy a vzťahy medzi nimi (sémantický web). RDF a RDFS je štandardizované a odporúčané konzorciom W3C na používanie na internete. OWL Web Ontology Language Ako nadstavba RDF bol vytvorený jazyk OWL. OWL má vyššiu schopnosť vyjadriť strojovo interpretovateľné znalosti ako RDF vďaka väčšej slovnej zásobe jazyka a svojej formálnej komplexnosti. Existujú tri varianty tohto jazyka: OWL Lite, OWL DL, OWL Full. Rozdelené sú podľa funkcionality a možností od najjednoduchšej OWL Lite. Všetky varianty sú spätne kompatibilné. To znamená že správne zapísaný dokument v jazyku OWL Lite je správny aj v jazyku OWL DL a OWL Full, a dokument OWL DL je tiež kompatibilný s OWL Full. OWL je v súčasnosti najpoužívanejší ontologický jazyk. Existujú aj ďalšie jazyky na zápis ontológií ako KIF (Knowledge Interchange Format), CGIF (Conceptual Graphs Interchange Format) a iné. Medzi najznámejšie softvérové nástroje na vytváranie a prácu s ontológiami patria Protége, OntoStudio, Neologism a ďalšie. Umožňujú vytvoriť ontológiu, hľadať v nej informácie, vizualizovať ju a odvodzovať z nej ďalšie pravidlá. Existuje viacero voľne dostupných ontológií, medzi tie základné patria OpenCYC, SUMO (Suggested Upper Merged Ontology), DOLCE (Descriptive Ontology for Linguistic and Cognitive Engineering). Ontológie sa dosť využívajú aj v medicíne [54]. Na obrázku 29 vidíme ukážku medicínskej ontológie MedDRA, ktorá uchováva znalosti o chorobách. Obr. 29 Medicínska ontológie MedDRA, na ukážke vidíme hierarchické zaradenie kožnej choroby vitiligo. [54]. 33

40 Okrem toho, že si môžeme ontológie zobrazovať graficky a tak hľadať v nich informácie, existujú aj dotazovacie jazyky RQL, SeRQL, RDQL a najpoužívanejší a odporúčaný konzorciom W3C SPARQL. SPARQL je syntakticky podobný jazyku SQL s tým rozdielom, že umožňuje iba dotazy typu SELECT. 6.1 METODOLÓGIA TVORBY ONTOLÓGIÍ Ontológie sa vytvárajú z viacerých dôvodov [50]: na zdieľanie znalostí a informácií medzi ľuďmi alebo počítačmi, aby boli znalosti v takej forme, že im budú rozumieť aj počítače, kvôli viacnásobnému (opätovnému) použitiu znalostí o doméne (tým sa myslí napr. použitie základnej ontológie, ktorá je už vytvorená a jej rozšírenie o znalosti z našej domény, tak aby sme ju mohli použiť), aby boli pravidlá o doméne definované explicitne, oddeľuje znalosti o doméne od aplikácie, na analýzu domény. Ontológiu by mali vytvárať doménový experti, ktorí danú oblasť znalostí dobre poznajú a majú s ňou skúsenosti. Nie je to však triviálna úloha. Neexistuje žiaden presný návod alebo postup na vytvorenie ontológie. Sú len odporúčania a vždy je viacero alternatív ako bude ontológia nejakej domény vyzerať. Najlepšie riešenie a podoba výslednej ontológie úzko súvisí s aplikáciou kde ju chceme použiť. Tvorba ontológie je v zásade iteratívny proces, kde sa vraciame k už vytvoreným častiam a tie rozširujeme, prípadne ak nám niečo nesedí, tak upravujeme. Koncept v ontológii by mal byť úzko spätý s objektmi, ktoré v nej budú vystupovať a vzťahmi medzi nimi, ktoré nás zaujímajú. Existuje taká pomôcka, že keď si zoberieme vety, ktoré popisujú našu doménu, tak často podstatné mená budú objekty a slovesá budú relácie v ontológií, ktorú vytvárame. Netreba to však brať doslovne. Postup vytvorenia ontológie by sme mohli zhrnúť do štyroch nasledujúcich krokov: definícia tried, hierarchické usporiadanie tried (nadtriedy, podtriedy), vzťahy medzi triedami, definovanie atribútov a prípustných hodnôt, ktoré môžu nadobúdať, vytvorenie inštancií a vyplnenie ich atribútov, určenie vzťahov medzi nimi. Pred tým než začneme ontológiu vytvárať je dôležité sa zamyslieť a rozobrať nasledujúce otázky: Aká je doména, ktorú má naša ontológia pokrývať? Na aký účel ideme ontológiu vytvárať? Na aké typy otázok by mali znalosti a informácie v ontológií odpovedať? Kto bude používať túto ontológiu? Vytvorením ontológie sa však proces nekončí, ontológie sú dynamické a v čase sa meniace štruktúry. Treba ich udržiavať a neustále vyvíjať, aby odrážali aktuálne potreby ich použitia. 34

41 7 KOMPLEXNÉ SIETE Štúdium komplexných sietí zažíva v poslednom desaťročí neobyčajný záujem vedcov a inžinierov z rôznych odvetví. Je to najmä vďaka novým poznatkom z tejto oblasti a rozšírenom využívaniu informačných technológií. Komplexné siete sa dajú definovať ako graf (sieť) s netriviálnou (zložitou) topologickou štruktúrou. Existuje veľa takýchto zložitých sietí, napríklad počítačové (prepojenie internetu, šírenie vírusov), sociálne, siete biochemických reakcií, siete leteckých liniek, sieť prenosu chorôb a veľa ďalších. Keď je sieť zložitá z hľadiska jej štruktúry, poznanie typu tejto štruktúry nám môže napomôcť k jej lepšiemu pochopeniu a získaniu nových informácii a poznatkov o nej. Zložitá štruktúrou môže byť aj rozsiahla relačná databáza, keď si v nej ako sieť môžeme predstaviť napríklad tabuľky a vzťahy medzi nimi. V tejto kapitole sa budem venovať teórií komplexných a najmä bezškálových sietí a v praktickej časti práce aplikujem tieto poznatky na rozsiahle RDB. Väčšina veľkých reálnych sietí sa správa podľa rovnakých pravidiel a majú spoločné a podobné vlastnosti. Teória komplexných sietí sa rozšírila najmä za posledných 10 rokov keď sa zistilo, že v reálnych sieťach nie sú uzly pospájané hranami náhodne 2. Do vtedy sa považovali siete za náhodné. 7.1 NÁHODNÉ SIETE V roku 1959 sa snažili prvý krát popísať komplexné siete Paul Erdos spoločne s Alfrédom Rényim v štúdií On evolution of random Graphs [57]. Táto štúdia je považovaná za jednu z najvýznamnejších prác týkajúcich sa skúmaniu náhodných grafov. Teória náhodných grafov, ako bola vtedy pomenovaná sa stala základným kameňom teórie komplexných sietí. Modely ktoré vtedy Erdos s Rényim navrhli pozostávali s N uzlov, ktoré sú navzájom pospájané tak, že hrany sú náhodne priradené medzi niektorými uzlami. V najvýznamnejšom modely z nich, ktorý je označovaný ako G n,p sa predpokladá, že každá možná hrana, ktorá bude spájať v grafe dva uzly sa vyskytne s pravdepodobnosťou p, a naopak hrana, ktorá v grafe nevystupuje má priradenú pravdepodobnosť 1-p. V takomto modeli majú približne všetky uzly siete rovnaký počet hrán. Z tohto modelu tiež vyplýva, že v náhodných sieťach je distribučná funkcia stupňa uzlov 3 Gaussova (zvonového tvaru, viď obr. 30 vľavo) a je veľmi neobvyklé ak majú nejaké uzly stupeň oveľa vyšší alebo nižší ako je priemerný stupeň celého grafu. Náhodné siete sa tiež volajú aj exponenciálne, pretože pravdepodobnosť, že je uzol pripojený ku K ostatným uzlom klesá exponenciálne pre veľké K. Keď v roku 1998 Hawoong Jeong, Albert Lászlo Barabási a Albert Réka z Notrdamskej univerzity pracovali na projekte zmapovania internetových stránok a odkazov 4 medzi nimi predpokladali, že výsledná sieť bude náhodná, avšak nebola. Vtedy sa zistilo, že reálne siete sú málokedy, ak vôbec, náhodné. Zistili, že sieť internetových stránok a odkazov na ne má úplne inú distribúciu stupňa uzlov ako náhodné siete. Táto distribúcia sa riadi mocninovým zákonom (viď obr. 30 vpravo) a má nasledovný predpis: (1) 2 V zmysle rovnomerne medzi všetkými uzlami, tj. pravdepodobnosť hrany je medzi každými dvoma uzlami rovnaká. 3 Stupeň uzla je počet hrán, ktorými je uzol spojený s inými, susednými uzlami. 4 Sieť, kde uzly sú webové stránky a ak je na stránke A odkaz na stránku B, tak je medzi uzlami A a B hrana. 35

42 Znamená to, že pravdepodobnosť P(k), že uzol má stupeň k (k susedov) je pre veľké k približne rovná, kde γ je parameter, ktorého hodnota je väčšinou v intervale (2, 3). Siete, ktoré majú takúto distribúciu stupňov vrcholov sa nazývajú bezškálové. Obr. 30 Grafy distribučných funkcií stupňov vrcholov [62]. 7.2 BEZŠKÁLOVÉ SIETE Pojem bezškálovosť všeobecne znamená, že sa pravidlá popisujúce vlastnosti systému nemenia so zmenou mierky (škály). V tomto prípade je to predpis distribučnej funkcie uzlov (1). Bezškálové siete sa vyznačujú tým, že v nich existujú vrcholy, ktorých stupeň vysoko prevyšuje priemer. Tieto vrcholy, s najvyšším počtom hrán, sa nazývajú centrá (hubs). Ostatné vrcholy, ktoré majú väčšinou len pár hrán, sú k týmto centrám pripojené. Menšie centrá sú zase pripojené k väčším atď. Ako vidíme z grafu na obrázku 30 vpravo, centier v sieti nie je veľa. No práve centrá držia celú sieť pokope v jednom veľkom komponente. Na obrázku 31 vidíme rozdiel v grafoch náhodnej a bezškálovej sieti. Bezškálové siete sú odolné voči náhodnému odstráneniu vrcholov a hrán. Pravdepodobnosť, že odstránime centrum je veľmi malá a navyše odstránenie jedného alebo zopár centier nám aj tak sieť nerozdelí na komponenty a s veľkou pravdepodobnosťou graf siete ostane súvislý. Naopak pri náhodných sieťach by sa pri náhodnom odstraňovaní hrán a uzlov rýchlo sieť rozdelila do viacerých komponentov a nebolo by už možné sa dostať z ľubovoľného uzla do ostatných uzlov. Obr. 31 Graf náhodnej a bezškálovej siete. Na obrázku 32 máme ukážku odolnosti bezškálovej siete proti odstraňovaniu náhodných uzlov / hrán. Pri náhodnej sieti (obrázok 32 hore) už po odstránení prvých náhodných uzlov rozdelíme sieť na viaceré komponenty a graf nám ostane nesúvislý. Na ukážke sú hlavné ťahy amerických ciest 5. Na obrázku 32 (v strede) je bezškálová sieť (letecké linky v USA) po odstránení náhodných vrcholov. Vidíme, že sa stále môžeme dostať do ľubovoľného uzla a teda graf je súvislý. Jediným spôsobom ako rozdeliť bezškálovú sieť na komponenty je odstránením centier ako to vidíme na obrázku 32 (dole). Centrá sú teda na udržanie takejto sieti veľmi dôležité. 5 Grafy ciest nie sú bezškálové siete. Spôsobené je to tým, že prakticky je nemožné vybudovať pri centrách taký počet ciest priamo do iných miest. Graf siete leteckých liniek je už však bezškálová sieť. 36

43 Obr. 32 Ukážka odolnosti náhodnej a bezškálovej siete voči odstraňovaniu náhodných uzlov a centier [62]. Vznik bezškálových sietí, podľa Barabásiho [61], ráta s dvoma základnými predpokladmi: rastom siete a preferenčným pripojovaním. Bezškálové siete vznikajú jednoducho tak, že k existujúcej sieti postupne pripájame nové uzly a pravdepodobnosť, že hrana medzi novým uzlom a nejakým existujúcim zo siete je priamo úmerná stupňu vrcholu tohto existujúceho uzla. Tento postup nám uprednostňuje vytvárať hrany s uzlami s veľkým stupňom, ktoré budú mať po pripojení ešte väčšiu pravdepodobnosť pripojenia. Takýmto spôsobom vznikajú centrá, ktoré sú charakteristické pre tieto siete. Bezškálové siete sa vyznačujú tiež tým, že každý uzol je dosiahnuteľný z ľubovoľného uzla na malý počet krokov resp. že v týchto sieťach je veľmi malá priemerná vzdialenosť medzi uzlami (diameter). Pri bezškálových sieťach s parametrom γ v rozmedzí 2 < γ < 3 je diameter približne d ~ ln ln N, kde N je počet uzlov s sieti [56]. Veľkým grafom, ktoré majú túto vlastnosť sa tiež hovorí malé svety. Malé svety preto, lebo aj napriek tomu, že je sieť veľká, z každého uzla sa ku každému dostaneme na pár krokov. Známym príkladom malého sveta je aj sieť kontaktov ľudí na svete. Je dokázané, že v priemere sa poznáme s každým človekom na svete cez maximálne 6 známych [61]. Ďalším príkladom malého sveta je tiež internet a sieť serverov, ktoré ho spájajú. Môžeme si sami overiť (v príkazovom riadku Windows pomocou príkazu tracert adresa_pc_alebo_www_stranky ), že sa na každý počítač v sieti môžeme dostať na krokov. Bezškálové siete je tiež zaujímavé vizualizovať. Na obrázku 33 môžeme vidieť vizualizáciu sieti internet od Bell Labs. 37

44 Obr. 33 Vizualizácia internetu. Na obrázku sú jasne viditeľné centrá tejto bezškálovej siete. 38

45 8 NÁVRH RIEŠENIA Mojím cieľom práce je vytvorenie postupu alebo metodiky na pochopenie a orientovanie sa v rozsiahlej alebo zložitej RDB. Na testovanie týchto postupov som používal kópiu databázy CEHZ, slúžiacej projektu Centrálna evidencia hospodárskych zvierat SR. Databáza pracuje pod systémom Oracle a má veľkosť približne 2,4 GB. Neboli mi k nej poskytnuté žiadne ďalšie informácie a tak bude vhodne slúžiť na experimentálne účely. 8.1 ZÍSKAVANIE METADÁT ZO SYSTÉMOVÉHO KATALÓGU Niektoré metadáta o RDB je možné získať zo systémového katalógu. Sú to napríklad informácie o názvoch tabuliek a atribútov, rôzne obmedzenia a reštrikcie, primárne a cudzie kľúče, unikátne stĺpce, indexované stĺpce atď. K údajom sa dostaneme pomocou príkazov. Na rozdiel od SQL jazyka, tieto príkazy nie sú štandardizované a preto si ich musíme naštudovať pre konkrétny RDB systém, v ktorom máme uloženú databázu. O RDB CEHZ som zo systémových katalógov zistil, že obsahuje 332 tabuliek a 169 pohľadov, 2339 atribútov a medzi reláciami existuje 192 referenčných vzťahov. Z týchto parametrov môžeme teda považovať RDB CEHZ za pomerne zložitú a rozsiahlu. Ďalej je možné z týchto údajov vytvoriť ER diagram, ktorý by nám mal túto RDB umožniť pochopiť (viď obr. 34). Tu narážame na prvý problém, ER diagram je príliš zložitý a ťažko sa v ňom orientuje. Keď v ňom chceme hľadať nejaké informácie, tak musíme pracne pozerať všetky tabuľky a sledovať vzťahy medzi nimi. 8.2 ER DIAGRAM PRI ROZSIAHLYCH RDB ER diagram je efektívna vizualizácia modelu RDB. Je to najpoužívanejšia pomôcka pre orientáciu sa v RDB. Pri rozsiahlych RDB vzhľadom na ich štruktúru, najmä počet vzťahov a tabuliek, je však ťažko použiteľný a zle sa v ňom orientuje (viď. obr. 34). Keď chceme používať ER diagram pri takýchto väčších RDB, je dôležité aby boli tabuľky v ňom vhodne rozmiestnené. To by mal mať za úlohu autor, ktorý RDB schému navrhol. Tabuľky je vhodné rozmiestniť do menších celkov na ploche tak, aby spolu úzko súviseli a tieto celky vhodne pomenovať. Keď nie je však takýto ER diagram k dispozícii, používajú sa algoritmy čo automaticky tabuľky na ploche rozmiestnia na základe katalógových informácií. Jeden z prístupov je napríklad taký, že tabuľky, ktoré majú najviac vzťahov (centrá, na ktoré sa v schéme odkazuje najviac tabuliek cez cudzí kľúč) budú práve stredmi celkov na ktoré sa plocha rozdelí. Tabuľky, ktoré budú prepojené iba s centrami sa umiestnia okolo nich. Tabuľky, ktoré budú mať viacej vzťahov, no nebudú centrami sa umiestnia k ľubovoľnému centru. Počet centier sa určí empiricky užívateľom. Iný prístup pre vhodné automatické rozmiestnenie tabuliek v ER diagrame môže byť napríklad rozmiestniť tabuľky na plochu tak, aby sa čo najmenej hrán krížilo. Na tento grafársky problém existujú algoritmy a teoreticky by nám mal rozmiestniť tabuľky tak, aby tabuľky umiestnené blízko seba spolu súviseli. Obidva prístupy nám problém čiastočne riešia, nie však vždy a exaktne. Ďalším problémom ER diagramu je pre vizualizáciu rozsiahlych RDB ten, že nám neumožňuje rozoznať dôležité vzťahy a tabuľky. V ER diagrame vyzerajú všetky rovnocenne. Pri menšom počte tabuliek a vzťahov to nie je podstatné, keďže sme schopní si väčšinu z nich zapamätať. Pri väčšom počte tabuliek však potrebujeme odlíšiť tie podstatné a skúmať ich najskôr a až potom 39

46 sa z nich dostať k menej dôležitým, podľa toho či ich potrebujeme skúmať alebo nie. Potrebujeme teda zobraziť v ER diagrame aj informácie o dôležitosti vzťahov a tabuliek. Obr. 34 ER diagram RDBS CEHZ. (obrázok slúži na ukážku zložitosti, preto nepovažujem za dôležité, aby sa dal text z neho čítať) 40

47 8.2.1 SCHEMABALL Myšlienkou zobrazovania schém rozsiahlych RDB sa už zaoberali v [27] a vymysleli vhodný typ vizualizácie. Nazvali ju Schemaball. Tento systém som prevzal, čiastočne upravil a vytvoril vlastnú softvérovú implementáciu, ktorá je použiteľná pre všetky RDBS s podporou JDBC. Schemaball zobrazuje schému RDB ako kružnicu kde tabuľky sú malé kruhy rovnomerne po nej rozmiestnené (viď obr. 35 A). Vzťah medzi dvoma tabuľkami je zobrazený ako bezierová krivka, ktorá ich spája a jej vrchol smeruje ku stredu (viď obr. 35 B). Vedľa kružníc tabuliek smerom od stredu je možné vypisovať názvy tabuliek. V takejto forme by však vizualizácia slúžila horšie ako ER diagram. Obr. 35 Malé kružnice reprezentujú tabuľky a bezierové krivky vzťahy medzi nimi. Pridanou hodnotou schemaballu je práve nedostatok ER diagramu a to zobrazenie dôležitosti vzťahov a tabuliek. V kapitole (2.2.3 RDB Metriky a Rankingy) sú spomenuté metriky RDB. Metriky nám slúžia na porovnávanie jednotlivých objektov v RDB. Tu práve využijeme metriky na ohodnotenie tabuliek a vzťahov. Tabuľky ohodnotíme podľa ich veľkosti metrikou (TS) [64]. Podľa [64] je to počet stĺpcov vynásobený počtom riadkov tabuľky. Podľa tejto hodnoty nastavíme jas farby kruhu reprezentujúceho tabuľku. Obdobným spôsobom zobrazíme aj vzťahy medzi tabuľkami pomocou metriky dôležitosť vzťahu (DV). Dôležitosť vzťahu vypočítame ako počet atribútov cudzieho kľúča vynásobený počtom riadkov, ktoré vzťah prepája tj. počet riadkov v tabuľke s cudzím kľúčom, kde je cudzí kľúč definovaný. Tieto metriky sú overené a často používané, je však na nás aby sme si ich ľubovoľne zmenili v prípade potreby. Pri vzťahoch je tiež dôležité zobraziť ktorá tabuľka sa na ktorú odkazuje (vzťahy v RDB sú jednosmerné). Toto pôvodní autori Schemaball neriešili, upravil som teda zobrazovanie vzťahov tak, že krivka vzťahu nebude jednofarebná, ale bude lineárnym prechodom dvoch farieb počnúc jednou sýtou farbou na začiatku krivky končiac inou sýtou farbou na konci. Na obrázku 35 a 36 (ďalšia strana) vidíme ER diagram a Schemaball rovnakej RDB. Ukážka je z menšej RDB, aby boli jasné a zobrazené všetky vzťahy. Pri rozsiahlej RDB nie je dôležité vidieť všetky vzťahy, ale hlavne vidieť tie podstatné. Tak isto, ak by mala tabuľka veľa menej dôležitejších vzťahov, tak by mala vyniknúť ako dôležitá, lebo veľa tabuliek spája. Hlavnou ideou schemaballu a vizualizácie veľkého množstva dát nie je zobrazenie všetkého, ale hlavne dôležitého. Vykreslenie dát tak, aby sa v zobrazení dali hľadať skryté informácie, potláčali sa nepodstatné časti a zvýrazňovali sa tie podstatné. Sú dva spôsoby ako je to možné dosiahnuť. Jedna možnosť je extrahovať z dát dôležité časti pomocou metrík alebo agregáciou a potom tieto extrahované dáta zobrazovať. Inou možnosťou je vo vizualizácií vykresľovať všetky dáta a zabezpečiť, že vo výslednom zobrazení budú dôležité časti zvýraznené a menej dôležité nie. Schemaball som implementoval týmto druhým spôsobom pomocou metódy kreslenia s alfa kanálom [88]. 41

48 Obr. 36 ER diagram RDB Filmy. Obr. 36 Schemaball RDB Filmy. Podľa jasu farieb vidíme dôležité vzťahy a tabuľky. Vzťahy napr. z tabuľky movie_person začínajú zelenou farbou, čo znamená, že sa odkazuje na iné tabuľky. 42

49 Táto metóda funguje tak, že pri vykresľovaní objektu sa okrem farby nastaví aj jeho priehľadnosť. Keď sa potom na už vykreslený objekt niečo nakreslí, výsledná farba bude závisieť od farieb a priehľadnosti oboch resp. všetkých prekrývajúcich sa objektov (viď obr. 37). V prípade našej vizualizácie je to požadované, lebo pri klasickom algoritme maliara 6 by sme nielen väčšinu vykresľovaných objektov nevideli kvôli tomu, že by boli prekreslené inými, ale výsledná vizualizácia by závisela aj od poradia vykresľovaných objektov čo je absolútne nevhodné. V klasickom ER diagrame tento problém riešiť nemusíme lebo tam sa nám žiadne objekty neprekrývajú, alebo len málo z nich, a to je aj dôvod prečo sa nám ich tam veľa nezmestí. Obr. 37 Na obrázku vidíme tú istú vizualizáciu vľavo bez a vpravo s použitím alfa kanálu. Na obrázku 39 (ďalšia strana) vidíme vizualizáciu našej skúmanej RDB CEHZ pomocou Schemaball. Zvýraznené sú hlavné vzťahy a tabuľky, na ktoré sa máme v prvom rade pri skúmaní zamerať. Z vizualizácie vidíme, že väčšina kriviek intenzívnych farieb smeruje do tabuľky ANIMAL (detail, viď obr. 38). Z tohto hľadiska je zrejme táto tabuľka najdôležitejšia, lebo je s jej riadkami prepojených veľa riadkov z iných tabuliek. Obr. 38 Detail vizualizácie pri tabuľke ANIMAL. Vzťahov s touto tabuľkou je buď veľa alebo spája veľa riadkov, čo sa odráža na intenzite farby kriviek smerujúcich do nej. Farba kružnice tejto tabuľky nám reprezentuje pomer počtu riadkov v tabuľkách, ktoré sa odkazujú na riadky v tejto tabuľke (žltá) a počet riadkov v tabuľkách na ktoré sa odkazujú riadky tejto tabuľky (zelená). V prípade tabuľky ANIMAL je to približne 4 ku 6. Aj z názvu databázy CEHZ Centrálna evidencia hospodárskych zvierat SR je zrejmé, že hlavnou entitou bude ANIMAL (zviera). Tabuľka nad ňou ANIMAL_A je bez výraznejších vzťahov, ale intenzívna modrá farba indikuje, že je veľká. Pozrel som si bližšie stĺpce a pár záznamov týchto tabuliek a zistil som, že sa jedná o archív tabuľky ANIMAL, a že na riadky v tabuľke ANIMAL_A sa žiadne riadky z iných tabuliek neodkazujú a naopak. Takto je tu viacero tabuliek archivovaných 6 Úplné prekreslenie podkladu vykresľovaným objektom. Paralela s maliarom, ktorý vždy pri ťahu štetcom prekryje pôvodný obraz. 43

50 s notáciou _A na konci. Tieto tabuľky by sme mali vylúčiť z ďalšieho skúmania, lebo nám žiadnu novú informáciu pre pochopenie RDB neposkytnú a ich vylúčenie nám zjednoduší model RDB. Ďalšie výrazné tabuľky buď prepojením alebo veľkosťou sú BLOODRACE, RACE, SPECIES, MOVEMENT, FARM, COLOR, CATTLE, BREEDING, ANIMALMOVEMENT, REGION a ďalšie. Len z tých názvov je možné sa domnievať, že RDB CEZH slúži na evidovanie a kategorizáciu zvierat, kde sa evidujú aj ich rodokmene a demografické údaje. Ak nás zaujímajú ďalšie podrobnosti, môžeme si pozrieť konkrétne tabuľky a ich stĺpce kde zistíme čo presne sa tam eviduje. Takýmto spôsobom môžeme preskúmať RDB od najdôležitejších tabuliek a vzťahov tak, aby sme vedeli ak hľadáme v nej nejaké konkrétne informácie, jednak či ich môže obsahovať a kde by mohli byť. Taktiež nám tento postup umožní zistiť o akú RDB obsahovo ide. Obr. 39 Výsledná vizualizácia RDB CEHZ pomocou implementovanej vizualizácie Schemaball. Schemaball je vhodná vizualizačná metóda pre rozsiahle RDB s veľkým počtom tabuliek a vzťahov. Hlavné výhody oproti ER diagramu sú: 44

51 Zvýrazňovanie dôležitých tabuliek a vzťahov. Do relatívne malého obrázka zobrazíme celú RDB. Zobrazuje nielen schému RDB, ale aj je obsah. Tento bod je podľa mňa najdôležitejší, lebo ak chceme pochopiť nejakú RDB, záleží najmä na dátach v nej o akú databázu ide. Schemaball je tiež možné využiť na zobrazenie hocijakých hranovo a vrcholovo ohodnotených grafov. Hlavnou nevýhodou Schemaball je, že nedokážeme na základe nej priamo, tak ako s ER diagramom, vytvárať SQL dotazy. Pre vytváranie dotazov by musela byť interaktívna s možnosťou dodatočného zobrazenia atribútov. 8.3 DISTRIBUČNÁ FUNKCIA VEĽKOSTI TABULIEK (TS) A DÔLEŽITOSTI VZŤAHOV (DV) Pred tým, ako som vizualizoval RDB CEHZ, som predpokladal, že výsledná vizualizácia bude farebnejšia ako je v skutočnosti. Na obrázku 39 (predošlá strana) si môžeme všimnúť, že napríklad modrá farba kruhov reprezentujúcich veľkosť tabuliek je viditeľná len na dvoch tabuľkách a inde vôbec. Podobne je to aj so vzťahmi, napriek tomu, že ich v RDB CEHZ je 192, vidíme ich len zopár. Predpokladal som, že keďže škála intenzity farieb (viď obr. 40) prechádza lineárne od tmavej až po najjasnejšiu, tak podobný efekt budem vidieť aj vo vizualizácií tj. tabuľky budú rôznych intenzít modrej farby (nie iba modré a čierne ako teraz). Obr. 40 Škála farieb pre veľkosť tabuliek (modrá) a dôležitosť vzťahov (zelená, žltá). Pri testovaní implementácie Schemaball som generoval náhodne veľkosti tabuliek a dôležitosti vzťahov medzi nimi. Generoval som tieto hodnoty rovnomerne a výsledkom boli pestrejšie vizualizácie (viď obr. 41). Môžeme na nich vidieť celú škálu farieb pri tabuľkách a vzťahoch. Obr. 41 Schemaball s náhodne (rovnomerne) generovanými veľkosťami tabuliek a dôležitosťami vzťahov medzi nimi. 45

52 Z obrázkov je nám jasné, že pri reálnej RDB nebudú hodnoty veľkosti tabuliek, a tiež ani dôležitosti vzťahov, rozložené rovnomerne. To som tiež predpokladal, ale nečakal som, že budú medzi tými hodnotami až také skoky. Urobil som teda štatistické testy na určenie, z akého rozdelenia pravdepodobnosti by mohli pochádzať tieto hodnoty. Skúmal som konkrétne veľkosti tabuliek podľa metriky TS (počet stĺpcov krát počet riadkov), dôležitosť vzťahov podľa metriky DV (počet atribútov cudzieho kľúča krát počet riadkov, ktoré ho majú definovaný). Oba súbory hodnôt som štatisticky spracoval v programe Input Analyzer, ktorý je súčasťou programu Arena od firmy Rockwell Software. Oba štatistické súbory pochádzajú z Weibulového rozdelenia na hladine významnosti 95 % (viď tab. 1). Softvér robí 2 štatistické testy na určenie vhodného rozdelenie pravdepodobnosti a jeho parametrov (chí kvadrát test dobrej zhody a Kolmogorov- Smirnov test, oba musia potvrdiť hypotézu na určenej hladine významnosti, v tomto prípade 95%). Štatistický súbor Zistené rozdelenie Priemerná štvorcová pravdepodobnosti chyba veľkosť tabuliek (TS) WEIB(5.66e+003, 0,234) 0, dôležitosť vzťahov WEIB(1,22e+004, 0,225) 0, (DV) Tab. 1 Zistené rozdelenia pravdepodobnosti štatistických súborov aj s priemernou štvorcovou chybou na hladine významnosti 95%. Keď sa pozrieme na histogramy oboch štatistických súborov a vhodne si k ním umiestnime farebnú škálu (viď obr. 42) vidíme koľko prvkov je približne akou farbou zafarbených. Väčšina zobrazovaných prvkov je vo vizualizácií zakreslená tmavými nevýraznými farbami. Obr. 42 Početnosti jednotlivých hodnôt v histograme s 13 triedami. Ku každej triede prislúcha približne farba zo škály farieb nad alebo pod stĺpcom v histograme. Vidíme, že väčšina hodnôt je z prvej triedy a prvky z prvej triedy sú zobrazené vo vizualizácii tmavšími farbami. Na jednej strane to môžeme zmeniť tak, že posunieme škálu farieb napríklad z lineárne rastúcej na logaritmicky rastúcu (viď obr. 43). Na druhej strane je otázne či to chceme, lebo práve to, že dôležitých vzťahov a tabuliek je málo nám umožňuje vo vizualizácií vidieť tie podstatné časti. Ostal som teda pri lineárnej škále farieb. 46

53 Obr. 43 Ak zmeníme škálu farieb z lineárne rastúcej na napríklad logaritmicky rastúcu, tak už aj prvky s menšou hodnotou budú pomerne intenzívne zafarbené. Na x-ovej osi nájdeme hodnotu prvku od 0 do 1 a výslednú intenzitu farby (0 až 1, 1 je plne intenzívna) vidíme na y-lonovej osi. 8.4 ROZDELENIE GRAFU SCHÉMY RDB NA KOMPONENTY Ako bolo spomínané v kapitole 8.2 (ER diagram pri rozsiahlych RDB) pri zobrazení RDB CEHZ sme našli tabuľky, ktoré slúžili na archiváciu iných tabuliek. Neboli prepojené vzťahmi so žiadnymi inými tabuľkami. Takéto tabuľky, ktoré nie sú prepojené s inými nám zbytočne zneprehľadňujú vizualizáciu a pôsobia mätúco. Je vhodné takéto tabuľky odstrániť. Samozrejme, že pred tým ako ich odstránime ich analyzujeme, aby sme zistili aký majú význam v RDB. Tento princíp oddelenia samostatných častí RDB sa dá zovšeobecniť tak, že rozdelíme celú schému RDB na samostatné komponenty. Schému RDB si najskôr prevedieme do grafovej formy. Vrcholy grafu budú tabuľky a neorientované hrany medzi nimi budú vzťahy medzi tabuľkami (viď obr. 44). Obr. 44 Grafová reprezentácia RDB schémy. Tabuľky sú vrcholy grafu a neorientované hrany sú vzťahy medzi nimi. Takýto graf sa nazýva pseudograf. Na takto vytvorený graf použijeme napríklad Tarryho algoritmus, ktorý nám rozdelí graf na jednotlivé komponenty. Tieto komponenty následne skúmame ako samostatné celky. Ideálnym prípadom je, ak zistíme, že RDB sa skladá z viacerých menších, nezávislých databáz. Tie sa dajú následne jednoduchšie pochopiť. Po aplikovaní postupu na skúmanú RDB CEHZ sme dostali dva viactabuľkové komponenty a zvyšok boli samostatné tabuľky. Po preskúmaní samostatných tabuliek som zistil, že všetky sú archívne, keďže boli nazvané ako tabuľka, ktorú archivujú s príponou _A a obsahovali rovnaké stĺpce. Zvyšné dva komponenty som si znova zobrazil pomocou vizualizácie Schemaball (viď obr. 45). Prvý, menší komponent (na obrázku 45 A, 9 tabuliek) je databáza webového rozhrania ku prístupu k hlavnej databáze (druhého komponentu). Je tu uložený systém práv užívateľov (tabuľky USERS, GROUP, ROLES, RIGHTS) a dáta webového rozhrania rozdelené do modulov (tabuľky PAGES, MODULES_TO_PAGES, MODULES). Autori RDB CEHZ zrejme chceli mať všetko pokope v jednej RDB, ale bez ich dodatočnej informácie alebo rozdelenia grafu schémy na 47

54 Obr. 45 Výsledné dva nezávislé komponenty skúmanej RDB CEHZ. 48

55 komponenty by sme na to len sotva prišli. Druhý, najväčší komponent (118 tabuliek), je vlastne hlavná databáza, ktorá je teraz už očistená od priamo s ňou nesúvisiacich častí, ktoré nám ju komplikovali. Je však stále dosť veľká na to aby sme sa v nej orientovali pomocou ER diagramu. Na obrázku 45 - B je možné identifikovať hlavné tabuľky a vzťahy (ANIMAL, RACE, FARM, BLOODRACE, SPECIES, SUBJECT, MOVEMENT, CATTLE, COLOR a ďalšie). Skúmaním týchto tabuliek a dát v nich som zistil, že RDB CEHZ je zameraná na evidenciu hospodárskych zvierat (hovädzí dobytok, ošípané, ovce, kozy, hydina a pštrosy). Evidujú sa tu farmy zo slovenských regiónov, rodokmene zvierat, ich choroby, očkovania, kontrola mäsa z týchto zvierat. Takýmto spôsobom je možné pochopiť veľkú RDB, orientovať sa v nej a získavať z nej informácie. 8.5 ZHRNUTIE METÓD PRE ORIENTÁCIU A POCHOPENIE ROZSIAHLEJ RDB Na základe použitia databázových metrík, vizualizácie a grafového algoritmu z predchádzajúcich podkapitol bola vytvorená metóda, ktorá umožňuje efektívny spôsob orientácie sa a pochopenia RDB. Je vhodná na analýzu neznámej RDB, ktorú chceme pochopiť, ale taktiež aj na známu RDB, ktorá je príliš veľká na to, aby sme sa spamäti vedeli v nej orientovať. Vytvorená metóda pozostáva z nasledovných krokov: 1. rozdeľ graf RDB schémy (graf tvoria tabuľky a vzťahy cudzích kľúčov medzi nimi) na komponenty napríklad pomocou Tarryho algoritmu, 2. následne skúmaj každý komponent grafu (krok 3) osobitne ako samostatnú RDB od komponentu s najmenším počtom tabuliek. 3. Ak je tabuľka samostatná (bez vzťahov), je dosť pravdepodobné, že bude archívna. To sa dá overiť jednoducho. Treba sa pozrieť na ostatné tabuľky aj z iných komponentov, či nie sú podobné názvami. Ak sú, tak pozrieme ešte názvy stĺpcov, ktoré by sa mali zhodovať (nemusia všetky). Na základe riadkov v tabuľke určíme spôsob archivácie (za aké časové obdobie sa robí a pod.). Ak nenájdeme žiadnu podobnú tabuľku a zistíme teda, že nejde o archívnu tabuľku, malo by byť možné len na základe názvov stĺpcov a dát v nej určiť jej význam. Ak komponent tvorí viac ako jedna tabuľka, na základe veľkosti komponentu (počet tabuliek) určíme, či ide o hlavnú časť RDB alebo nejaké podčasti priamo nezávislé na zvyšku RDB. Je nepravdepodobné, že RDB obsahuje viac samostatných RDB, kde všetky sú rovnocenné a nezávislé, lebo tvorca RDB by ich vytvoril v osobitných schémach. Ak sa nachádzajú v jednej schéme viaceré RDB, bude to len z toho dôvodu, že nejako, nie priamo, so sebou súvisia. (Napríklad tak ako v našom praktickom príklade, kde menší komponent tvoril RDB pre webové rozhranie na prístup, zmenu dát a systém práv hlavného komponentu.) Následne si komponent zobrazíme pomocou ER diagramu, kde sa na základe názvov tabuliek, ich stĺpcov, dát v nich a vzťahoch budeme snažiť pochopiť databázu. Ak by bol ER diagram príliš veľký na pochopenie, použijeme vizualizáciu Schemaball a budeme skúmať podstatné tabuľky a vzťahy, ktoré budú výrazne označené. Na základe nich zistíme zhruba aké informácie RDB uchováva a čo je jej účelom. Pre konkrétnejšie detaily budeme z týchto kľúčových tabuliek prechádzať k menej dôležitejším cez vzťahy, vždy podľa toho čo chceme zistiť. Popri vizualizácií Schemaball je nutné mať k dispozícií aj nejaký nástroj (napríklad proprietárny od dodávateľa DBS), ktorý by nám zobrazoval stĺpce a dáta tabuliek, lebo Schemaball tieto informácie kvôli prehľadnosti nezobrazuje. Tento postup sa dá využiť aj pri iných ako relačných databázach (objektové, sieťové), vyžadovalo by to však menšie zmeny. 49

56 8.6 ĎALŠIE CHARAKTERISTIKY ROZSIAHLYCH RDB Pri skúmaní schémy RDB CEHZ som si všimol pri použití metriky NR (Number of References počet vzťahov tabuľky), že väčšina tabuliek zo schémy má len málo vzťahov, ale existuje zopár tabuliek, ktoré ich majú výrazne veľa. Graf na obrázku 46 nám zobrazuje distribúciu počtu vzťahov tabuliek (inými slovami, aká je pravdepodobnosť, že má tabuľka T x - vzťahov). Z grafu vidíme, že drvivá väčšina tabuliek nemá viac ako 3 vzťahy. Naopak, existujú aj tabuľky, ktoré majú 17, 18 a aj 29 vzťahov. Táto distribučná funkcia sa nápadne podobá na distribučnú funkciu stupňov vrcholov v bezškálových sieťach (viď kapitola 7.2 Bezškálové siete). Je dosť pravdepodobné, že aj graf RDB schémy 7 je bezškálová sieť. 0,16 0,14 0,12 0,10 0,08 0,06 0,04 0,02 0, Obr. 46 Distribučná funkcia počtu vzťahov tabuliek. Na x-ovej osi je počet vzťahov a na y-lonovej osi príslušný podiel tabuliek s takýmto počtom vzťahov. Ako bolo spomenuté v kapitole 7.2 bezškálové siete vznikajú rozširovaním existujúcej siete o nové uzly a ich preferenčným pripojovaním. Rozsiahle RDB vznikajú tiež rozširovaním existujúcich RDB a pridávaním tabuliek. Či sa pripájajú preferenčne už nie je také jednoznačné. Ďalším znakom bezškálových sietí je existencia centier. V RDB CEHZ existujú. Ak by sa ukázalo, že graf rozsiahlych RDB je bezškálová sieť, mohli by sme jej vlastnosti využiť pri skúmaní RDB. Na zistenie či je sieť bezškálová sa väčšinou skúma len distribučná funkcia stupňov vrcholov grafu. Albert Lászlo Barabási definoval bezškálové siete ako siete s mocninovým chvostom distribučnej funkcie stupňov vrcholov grafu (orig. Networks with a power law tail in their degree distribution are called scale-free networks ) [62]. Na obrázku 46 vidíme mocninovú funkciu aj s takzvaným ťažkým chvostom. Bezškálové siete sú väčšinou rozsiahle, rádovo státisíce, milióny uzlov. Avšak aj túto sieť môžeme považovať za bezškálovú i keď je malá. Graf je možné vytvoriť aj iným spôsobom ako zo schémy RDB. Môžeme zakomponovať do neho aj obsah RDB. Navrhol a otestoval som teda ďalšie dva prístupy PRÍSTUP 2 Tabuľky budú uzly a hrana medzi dvoma uzlami bude za každý záznam prepojený medzi tabuľkami. Napríklad ak má tabuľka A - 10 záznamov, ktoré sa odkazujú na záznamy v tabuľke B, tak medzi tabuľkami A a B je 10 hrán. Tento prístup rozdelí poradie centier vzhľadom na počet záznamov a ich prepojenia s ostatnými záznamami v iných tabuľkách. Graf distribučnej funkcie takejto sieti je na obrázku 47. Vidíme, že uzly majú hrán rádovo v miliónoch a centrá sa oddelili ešte výraznejšie. 7 Neorientovaný graf kde tabuľky sú vrcholy a vzťahy medzi nimi sú hranami grafu. 50

57 1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0 Obr. 47 Distribučná funkcia počtu vzťahov tabuliek (vzťah medzi tabuľkami je za každý prepojený záznam). Na x-ovej osi je počet vzťahov a na y-lonovej osi príslušný podiel tabuliek s takýmto počtom vzťahov. V okolí hodnôt 3E+06 a 1,30E+07 na x-ovej osi sú zaznačené centrá. Výhodou prístupu je, že sieť je závislá najmä na dátach v RDB. Čiže centrá nám vzniknú tam, kde je najviac prepojených záznamov. Málo prepojené tabuľky, čo majú veľa vzťahov by v tomto prípade v sieti neboli dôležité čo je žiadúce PRÍSTUP 3 Vytvorenie grafu môžeme ešte vylepšiť tak, že graf nám budú tvoriť samotné dáta v RDB. Čiže vrcholy grafu budú riadky (n-tice) z tabuliek a hrany budú referencie medzi konkrétnymi riadkami. Napríklad ak je v tabuľke OSOBA evidovaný záznam pod unikátnym ID=11, tento riadok bude vrcholom grafu a hrany bude mať iba ak sa nejaký záznam z ľubovoľnej tabuľky odkazuje na ID=11 alebo ak sa záznam s ID=11 odkazuje na iné riadky v ľubovoľných tabuľkách. Vytvoriť však takýto graf z rozsiahlej RDB nie je triviálna úloha. Vytvoril som na to program, ktorý túto transformáciu urobí pre všetky RDBS s podporou JDBC. Generovanie grafu pre RDB CEHZ trvalo niečo vyše dňa. Vytvorený graf mal okolo 30 miliónov vrcholov a 11 miliónov hrán. Veľký počet vrcholov nemal žiadnu hranu cca 25 miliónov. Tieto vrcholy nás nezaujímajú, keďže nie sú prepojené. Boli najmä z archívnych tabuliek. V kapitole 8.4 (Rozdelenie grafu schémy RDB na komponenty) sa nám RDB CEHZ rozdelila na dva komponenty (komponenty A, B obr. 48, detail, obr. 45 na str. 48). Obr. 48 Dva Komponenty grafu schémy RDB CEHZ. B je hlavná databáza a A je časť, ktorá zabezpečuje webové rozhranie a systém práv prístupu. (detail obrázka je na str. 48, obr. 45) 51

58 Tieto komponenty som skúmal osobitne, keďže ak ich grafy schém sú osobitné komponenty, tak určite nebudú prepojené ani dátami. Hlavný komponent B (obsahuje takmer všetky dáta) bol na moje prekvapenie súvislý. Tj. neexistuje žiaden riadok tabuľky resp. záznam, ktorý by nebol súčasťou jednej veľkej prepojenej sieti záznamov. Z druhého komponentu A (táto časť RDB zabezpečuje webové rozhranie a systém práv) vznikol graf so 7mimi komponentmi. Rozdelenie vzniknutých komponentov z oboch databáz je v tabuľke 2. Komponent Počet vrcholov Databáza Zoznam Tabuliek z ktorých sú záznamy HLAVNÁ - B Všetky (118) A Všetky (9) 3 17 A ENTITIES, MODULES, MODULES_TO_PAGES, MODULES_TO_ROLES, PAGES, RIGHTS, ROLES 4 16 A MODULES, MODULES_TO_PAGES, PAGES 5 3 A MODULES, MODULES_TO_PAGES, PAGES 6 2 A MODULES_TO_PAGES, PAGES 7 2 A MODULES_TO_PAGES, PAGES 8 2 A MODULES_TO_PAGES, PAGES Tab. 2 Vzniknuté komponenty z grafov záznamov. (Na spracovanie grafu bola použitá knižnica SNAP [95]) Aj pri druhej databáze A tu však takmer všetky dáta (98%) sú v jednom komponente. Nie je to zrejme náhoda, že graf záznamov v databáze je tak prepojený, že tvorí jednu sieť a len málo záznamov k nej nie je pripojených. To je tiež jedna z charakteristík bezškálových sietí. Distribúcia stupňov vrcholov grafu nám to potvrdzuje (Obr. 49). Obr. 49 Distribučná funkcia stupňa vrcholov grafu Na x-ovej osi je počet vzťahov a na y-lonovej osi príslušný počet vrcholov s takýmto počtom vzťahov. (Graf je vygenerovaný pomocou knižnice SNAP [95], osi rastú exponenciálne.) 52

59 Vo všetkých troch prístupoch nám vychádza graf vytvorený z RDB ako bezškálová sieť. V bezškálových sieťach sú centrá najdôležitejšími uzlami siete, ktoré držia celú sieť pohromade. V grafoch vytvorených z RDB sú to tabuľky alebo záznamy (prístup 3), ktoré sú v schéme kľúčové. Tak ako pri bezškálových sieťach, ak chceme sieť dobre pochopiť, tak musíme skúmať jej centrá. Pri RDB teda tiež v prvom rade skúmame tabuľky resp. záznamy, ktoré sú centrami. Tiež sa treba zamerať aj na ostatné vrcholy a hrany grafu, po ktorých vylúčení sa nám rozdelí graf na komponenty. Tieto vrcholy, hrany a centrá musíme tiež dobre zabezpečiť, lebo ich odstránenie nám rozdelí celú RDB na komponenty a väčšina z informácií, ktoré v nej ostanú bude nepoužiteľná, lebo ich nebudeme vedieť spolu prepojiť. Pri pohľade na RDB ako na sieť nám teda dôležitosť tabuliek a záznamov určuje počet ich vzťahov. Sú to vlastne databázové metriky (viď kap RDB Metriky a Rankingy). Prvým prístupom sme overili spôsobilosť jednej z existujúcich metrík a vďaka ďalším dvom prístupom môžeme zaviesť dve nové metriky: Metrika 1 - Počet vzťahov tabuliek s inými tabuľkami, kde vzťah medzi tabuľkami je, ak tabuľka A obsahuje cudzí kľúč, ktorý sa odkazuje na stĺpec/e v tabuľke B. Nie je dôležitá orientácia vzťahov, vzťahy považujeme za neorientované. (overili sme použiteľnosť už existujúcej metriky - Number of References, NR (T)) Metrika 2 - Druhá metrika zohľadňuje aj obsah RDB. Tabuľka A má taký počet vzťahov s tabuľkou B, koľko existuje záznamov v tabuľke A, ktoré sa odkazujú cez cudzí kľúč na záznamy v tabuľke B a naopak. Čiže ešte pripočítame k nim aj počet záznamov v tabuľke B, ktoré sa cez cudzí kľúč odkazujú na tabuľku A. Vzťahy sú neorientované a pre tabuľku je to suma vzťahov so všetkými ostatnými tabuľkami. Metrika 3 Počet vzťahov záznamu (n-tice). Táto metrika nie je tabuľková, ale riadková. Na jednoduché identifikovanie centier a ich dôležitosti som vytvoril vizualizáciu (viď obr. 50 a 51). Modré kruhy reprezentujú tabuľky. Intenzita ich vnútorného zafarbenia identifikuje ich veľkosť na základe metriky (TS definovaná v 2.2.3). Tabuľky sú sústredené do kruhu, rozmiestnené sú náhodne po obvode kružnici, pričom vzdialenosť každej tabuľky od stredu je nepriamoúmerná jej počtu vzťahov, vypočítaného podľa metriky 1 NR(T) (čím viac vzťahov má tabuľka, tým je bližšie pri strede). Intenzita farby vzťahu identifikuje dôležitosť vzťahu na základe metriky (DV definovaná v 8.2.1). Z vizualizácie je vidieť, že väčšina tabuliek je rozmiestnená na okraji kruhu (väčšina tabuliek je len pripojená k nejakému centru) a pár tabuliek - centier je blízko stredu. Takouto vizualizáciou sa dajú zobrazovať aj grafy sociálnych sieti resp. všetky bezškálové siete. 53

60 Obr. 50 Vizualizácia vzťahov a tabuliek v RDB CEHZ, modré kruhy reprezentujú tabuľky. Čím sú bližšie ku stredu, tým majú viacej vzťahov. Vizualizácia nám jasne oddelí centrá od ostatných tabuliek. 54

61 Obr. 51 (obr. 3 s názvami centier) Vizualizácia vzťahov a tabuliek v RDB CEHZ, modré kruhy reprezentujú tabuľky. Čím sú bližšie ku stredu, tým majú viacej vzťahov. Vizualizácia nám jasne oddelí centrá od ostatných tabuliek. 8.7 SKÚMANIE A VIZUALIZÁCIA GRAFU RDB Ako už bolo v predchádzajúcej kapitole 8.6 spomenuté, transformovať RDB do grafu sa dá viacerými spôsobmi. Zoberme si ten najjednoduchší spôsob (vrcholy sú tabuľky a orientované hrany sú vzťahy cudzích kľúčov medzi nimi). Takýto graf vlastne zobrazuje aj ER diagram. Konkrétne pre RDB CEHZ som ho vizualizoval pomocou nástroja na vizualizovanie grafov Gephi (5.1 Vizualizácia grafov). Nástroj ponúka viacero algoritmov pre automatické rozmiestnenie vrcholov grafu vo vizualizácii. Použitím algoritmu Force Atlas som dostal najprehľadnejší výsledok (viď obr. 52). Použil som aj automatickú klasterizáciu vrcholov na základe ich vzťahov. Na obrázku sú farebne odlíšené jednotlivé klastre (triedy). Vizualizácia si vyžadovala ešte menšiu interaktívnu úpravu rozmiestnenia, aby boli názvy tabuliek ako tak prehľadné. Ako môžeme vidieť na obrázku 52, samotný algoritmus nám rozdelil dva komponenty grafu 55

62 a umiestnil vrcholy s veľkými stupňami (centrá) do stredu klastrov. Pri spoznávaní a orientovaní sa v schéme RDB opäť postupujeme od centier. Obr. 52 Vizualizácia grafu schémy CEHZ, automatické rozmiestnenie FORCE ATLAS s menšími úpravami a klasterizovanie tabuliek. Vizualizáciu môžeme vylepšiť pridaním metrík do grafu. Ohodnotenie hrán podľa metriky DV (dôležitosť vzťahov), a vrcholov podľa metriky TS (veľkosť tabuliek) definovaných v kapitole nám pridá do vizualizácie ďalšie informácie. Vo vizualizácii to bude znamenať väčšie vrcholy a hrany s väčším ohodnotením. Na obrázku 53 je graf schémy CEHZ aj s príslušnými metrikami. Táto vizualizácia si vyžadovala pomerne veľa úprav. Z kapitoly 8.3 vieme, že veľkosti tabuliek a dôležitosti vzťahov nerastú v schéme lineárne, ale exponenciálne. Vo vizualizácií musíme preto nastaviť, aby veľkosť hrany alebo vrcholu nebola od ohodnotenia závislá lineárne, ale napríklad logaritmicky. V prípade implicitného nastavenia nástroja (lineárna veľkosť v závislosti od ohodnotenia) by sme videli dva vrcholy a pár vzťahov, ktoré by všetko ostatné prekryli. Ďalej bolo nutné ešte čiastočne upraviť rozmiestnenie, aby bola čitateľná väčšina názvov tabuliek. Algoritmus rozmiestnenia Force Atlas bral do úvahy aj ohodnotenia hrán a vrcholov, preto je rozmiestnenie trocha odlišné od predchádzajúcej vizualizácie (viď obr. 53). 56

63 Obr. 53 Vizualizácia grafu schémy CEHZ, pridanie ohodnotenia hrán a vrcholov na základe čoho je zobrazená hrúbka hrany resp. veľkosť vrcholu. Vizualizácia si vyžadovala aj ručnú úpravu rozmiestnenia vrcholov kvôli prehľadnosti. V takejto vizualizácii, kde sú hrany a vrcholy ohodnotené sa môžeme prirodzene zamerať pri skúmaní a orientovaní sa v RDB najskôr na podstatné tabuľky a vzťahy čo nám urýchli proces získavania dôležitých informácii o RDB. Ďalšou výhodou je, že graf nám zobrazuje nepriamo aj informácie o dátach, čo je dôležité. Vizualizačný nástroj umožňuje po nadídení kurzoru myši nad vrchol zobrazenie všetkých priamo prepojených vrcholov a hrán k nemu. Orientácia v grafe sa stáva tak ešte prehľadnejšia. Na obrázkoch 54 a 55 na ďalšej strane sú ukážky priamych vzťahov s vrcholmi (tabuľkami) ANIMAL a FARM ZHRNUTIE A NEDOSTATKY RIEŠENIA Vizualizačný nástroj Gephi nám ponúka veľmi dobré riešenie orientácie sa vo veľkej RDB schéme. Interaktívna vizualizácia nám umožňuje jednoduché skúmanie RDB. V prípade dodatočných informácii k tabuľkám (napr. názvy stĺpcov, primárne a cudzie kľúče, atď.) môžeme dokonca vytvárať SQL príkazy. Nedostatky riešenia sú najmä v tom, že algoritmy na rozmiestnenie grafu vo vizualizácií nie sú úplne dokonalé a prehľadné rozmiestnenie si vyžaduje dodatočné interaktívne úpravy. Ďalším nedostatkom je, že pri aplikovaní metrík na veľkosť hrán a vrcholov je potrebné tiež dodatočné ručné vyladenie vizualizácie, aby sme ju mali prehľadnú a použiteľnú. Export z ľubovoľnej RDB 57

64 aj s metrikami do Gephi som implementoval v nástroji RDBAnalyzer (8.8 Vytvorenie nástroja RDBAnalyzer). Obr. 54 Interaktívne zobrazenie tabuľky ANIMAL a jej priamych vzťahov. Obr. 55 Interaktívne zobrazenie tabuľky FARM a jej priamych vzťahov. 58

65 8.8 VYTVORENIE NÁSTROJA RDBANALYZER Metódy a postupy z predošlých kapitol som implementoval a združil do softvérového nástroja RDBAnalyzer. Nástroj by mal slúžiť ako pomôcka pre ľudí pracujúcich s veľkými RDB, v ktorých sa chcú rýchlejšie orientovať a pochopiť ich. Na rýchle zorientovanie sa v RDB o ktorých nemáme žiadne informácie a chceme zistiť načo slúžia a aké informácie obsahujú a na údržbu rozsiahlych RDB a odhalenie kľúčových tabuliek, vzťahov a dátových tokov POŽIADAVKY NÁSTROJA RDBANALYZER Požiadavky sa dajú zhrnúť do nasledujúcich 5tich bodov: Nástroj s intuitívnym grafickým rozhraním bude schopný pripojiť sa k viacerým existujúcim RDB, načítať potrebné informácie o schémach, tabuľkách, vzťahoch atď. Bude možné sa dotazovať na RDB pomocou SQL príkazov pre dodatočné informácie. Implementovanie vytvorených metód, postupov a vizualizácií. Konkrétne rozdelenie grafu schémy na komponenty, vizualizovanie pomocou Schemaball, vizualizovanie grafu schémy, zobrazenie stĺpcového grafu tabuliek a vzťahov podľa rôznych metrík. Ľahko rozšíriteľný, škálovateľný a objektovo orientovaný návrh vhodný pre dopĺňanie ďalších funkcionalít. Použitie nástroja na rôznych operačných systémoch a podpora RDBS od viacerých poskytovateľov. Export RDB do grafového formátu GEXF 8 aj s metrikami objektov RDB NÁVRH A IMPLEMENTÁCIA Aby sa dal nástroj jednoducho používať, potrebuje jednoduché a prehľadné grafické rozhranie. Na základe skúseností s nástrojmi na manažovanie RDBS (MySQL WorkBench, DB2 Data Studio, HeidiSQL, pgadmin a ďalšie) som si všimol, že majú takmer všetky rovnaké rozloženie grafického rozhrania (viď obr. 56). Človek pracujúci so spomínanými nástrojmi sa v novom nástroji rýchlo zorientuje ak bude rozložený podobne. Zachoval som teda štandard popísaný pod obrázkom 56. Obr. 56 Rozloženie komponentov väčšiny nástrojov na manažovanie RDBS. 1 strom s pripojeniami, databázami a tabuľkami. 2 pracovná časť, zobrazuje výsledky a vizualizácie, komunikácia smerom k užívateľovi. 3 informačný panel, zobrazuje textové informácie o dianí, prípadne chyby. Označením prvku v strome a následným volaním funkcií z horného menu ovládame nástroj. 8 GEXF (Graph Exchange XML Format) je to otvorený a rozšíriteľný XML formát pre popis komplexných sietí, ich štruktúry, atribútov a dát. Vznikol v roku 2007 v projekte Gephi (nástroj na vizualizáciu a analýzu komplexných sietí). 59

66 Program som sa rozhodol vytvoriť v Jave jednak preto, aby bol prenositeľný medzi rôznymi operačnými systémami, ale tiež aj preto, že mám s prácou s grafickými knižnicami v Jave najväčšie skúsenosti. Triedy som rozdelil do 5tich balíkov (packages) (viď obr. 57). Diagramy tried môžete nájsť v prílohe A na konci práce. Aplikačnou vrstvou nástroja je trieda Gui v balíku application. Obr. 57 Balíky obsahujúce triedy rozdeľujú prehľadne model na samostatné celky. Diagramy tried konkrétnych balíkov sú zobrazené a popísané v prílohe A. Na zabezpečenie spojenia aplikácie s databázou slúži balík connection. V tomto balíku sú tiež triedy s grafickým rozhraním GuiPripoj formulár na zadanie hodnôt pre pripojenie a SQLConsole formulár na zadávanie SQL dotazov pre zistenie dodatočných informácií o RDB (viď obr. 58). Balík datastructures obsahuje triedy, ktoré sú dátovou štruktúrou pre schému, tabuľky a vzťahy. Po načítaní databázy sa aj s potrebnými informáciami uložia v inštanciách týchto tried. Obr. 58 Ukážka SQL konzoly, ktorá sa dá zobrazovať pre každú RDB v nástroji. V balíku graph sú triedy na používanie grafu a algoritmov nad ním. Je tu implementovaný Tarryho algoritmus na nájdenie komponentov v grafe. Najväčším balíkom je balík graphics, kde sú triedy na generovanie vizualizácií a grafov. Hlavným prvkom v programe je dátová štruktúra strom. Ukladajú sa tu informácie o pripojeniach a databázach (viď obr. 59). Nástroje sa vykonávajú vždy iba nad označeným prvkom stromu. Strom ide maximálne do hĺbky 3 (adresa pripojenia -> názov schémy -> komponenty schémy). 60

67 Obr. 59 Strom s pripojeniami a databázami PRIDÁVANIE ĎALŠÍCH FUNKCIONALÍT Aktuálne sú implementované v nástroji RDBAnalyzer nasledovné funkcionality : rozdelenie grafu schémy na komponenty, vizualizovanie pomocou Schemaball, vizualizovanie grafu schémy, zobrazenie stĺpcového grafu tabuliek a vzťahov podľa rôznych metrík, exportovanie schémy aj s metrikami do GEXF súboru. Ďalšie funkcionality sa dajú programátorsky pridávať veľmi jednoducho, a to v troch krokoch: vytvorenie triedy s funkcionalitou, pridanie funkčného tlačidla (buttonu) do menu, pridanie nového panelu na aplikačnej vrstve (po kliknutí na funkčné tlačidlo sa pridá ďalší panel medzi záložky s panelmi, pomenuje sa databázou s ktorou chceme použiť funkcionalitu a názvom funkcionality). S databázou môže programátor priamo pracovať pomocou JDBC pripojenia, alebo môže využiť už existujúce štruktúry (schému a graf tabuliek a vzťahov aj s metrikami) podľa UML diagramov z prílohy A IMPLEMENTÁCIA VIZUALIZÁCII Pri implementácii vizualizácii som narazil viacero problémov. Okrem zmieneného problému s vykresľovaním viacerých prekrývajúcich sa objektov riešeného pomocou alfa kanálu (8.2.1 Schemaball) bol ďalším problémom rýchlosť vykresľovania. Pri vykresľovaní napríklad desiatich tisícoch čiar priamo na panel okna čakáme na zobrazenie približne minútu. To je čas len vykresľovania čiar. Keď pridáme do vizualizácie anti-aliasing 9, alfa kanály a zložitejšie objekty ako čiary, čas vykresľovania sa nám ešte predĺži. Navyše ak by sme chceli urobiť vizualizáciu interaktívnu, vždy pri interakcii s obrazom by sme čakali tento dlhý čas na prekreslenie. Vizualizácie som preto riešil iným spôsobom. Obraz som dal vykresľovať do pamäti a až po jeho vytvorení som ho už ako výsledok vykreslil na zobrazovací panel (double buffering). V Jave je na takéto vykresľovanie v pamäti trieda BufferedImage. Tento prístup urýchli celý proces vizualizovania. Vytvorenie vizualizácie je v tomto prípade závislé iba na rýchlosti procesora a nebrzdí ho čas potrebný na vykreslenie. Čas potrebný na vykreslenie je rovný vykresleniu ľubovoľného obrázka rovnakého rozlíšenia na zobrazovací panel. V prípade, že by sme chceli urobiť vizualizácie interaktívne, tak by sme len zistili polohu myši na obraze, našli medzi vizualizovanými objektmi ten, ktorého plocha obsahuje túto polohu, vykonali 9 Anti-aliasing metóda zaoblenia hrán v obraze. 61

68 potrebné zmeny, vygenerovali obraz v pamäti a zase len vykreslili obrázok na zobrazovací panel. Takýmto spôsobom sú implementované vizualizácie v nástroji RDBAnalyzer a pri vytváraní ďalších odporúčam len skopírovať jednu z tried SchemaBall alebo RelationGraph (pri interaktívnej vizualizácií triedu ParallelCoordinates) a vykresľovať v metóde generateimage (pri interaktívnej vizualizácií v metóde kresli) MULTIPLATFORMOVOSŤ A UNIVERZÁLNOSŤ NÁSTROJA Univerzálnosť nástroja z pohľadu operačného systému je zabezpečená Javou. Menším problémom však ostáva zabezpečiť univerzálnosť z pohľadu poskytovateľa RDBS. Jedným z možných prístupov je vytvoriť podporu pre najpoužívanejšie RDBS (Oracle, MySQL, DB2, PostgreSQL, MSSQL). Vtedy však o univerzálnosti veľmi nemôžeme hovoriť a pridanie podpory pre ďalšie RDBS by vyžadovalo programátorské úpravy. SQL štandard (viď Databázové jazyky) nie je dosť univerzálny na to, aby bolo možné pomocou neho získať všetky informácie, ktoré sú potrebné z RDB pre použitie implementovaných funkcionalít. Nie je možné pomocou štandardného SQL dotazu zistiť napríklad zoznam tabuliek schémy alebo vzťahy cudzích kľúčov a podobne. Tieto príkazy sa líšia v závislosti od poskytovateľa RDBS, respektíve závisia aj od štruktúry systémových tabuliek konkrétneho poskytovateľa RDBS. Príklady týchto príkazov a selekcií pre rôzne RDBS uvádzam v tabuľke 3. Poskytovateľ RDBS Oracle Príkaz na získanie názvov všetkých tabuliek schémy Príkaz na získanie vzťahov cudzích kľúčov (vráti tabuľku otec, syn, počet stĺpcov prepojenia) MySQL PostgreSQL Tab. 3 Príklady niektorých príkazov na zistenie informácií o RDB, na ktoré nie sú štandardné príkazy SQL. Tento problém sme riešili spoločne s mojím bakalárom. V jeho bakalárskej práci [65] sme pracovali na univerzálnom nástroji, ktorý exportuje / importuje RDB z / do RDBS od ľubovoľného poskytovateľa. Narazili sme tam na ten istý problém. Vyriešili sme ho tak, že všetky informácie, ktoré sú získané neštandardnými príkazmi resp. príkazmi, ktoré používajú neštandardné systémové tabuľky sa budú zapisovať do externého XML súboru. Ďalej sa do tohto súboru zapíše aj názov a cesta k JDBC 10 ovládaču. Takýmto spôsobom je možné vytvoriť program univerzálne pre rôzne druhy RDBS (samozrejme iba tie, pre ktoré existuje ovládač JDBC). Na obrázku 60 je ukážka XML súboru s týmito informáciami k nástroju RDBAnalyzer. 10 JDBC (Java Database Connectivity) štandardné rozhranie na pripojenie k relačným databázam v programovacom jazyku Java. 62

69 Obr. 60 XML súbor s informáciami o pripojeniach a príkazmi špecifickými pre jednotlivé RDBS. Nástroj som testoval na troch rôznych RDBS (MySQL, Oracle, PostgreSQL). Tieto RDBS sú v nástroji implicitne podporované. Ak chceme analyzovať RDB od iného poskytovateľa musíme si stiahnuť príslušný ovládač JDBC a pridať potrebné informácie do XML súboru db_info.xml (podrobne v prílohe B návod na použitie nástroja RDBAnalyzer). Taktiež ak by niekto vyvíjal do nástroja ďalšiu funkcionalitu, ktorá by si vyžadovala informácie získané z RDBS neštandardne alebo zo systémových tabuliek pomocou príkazov SQL, pridal by do súboru db_info.xml záznam týchto príkazov aj s komentárom ku všetkým implicitne podporovaným RDBS NEDOSTATKY A ODPORÚČANIA Nástroj RDBAnalyzer odporúčam používať spolu s grafickými nástrojmi na manažovanie RDB proprietárnym k RDBS. V nich sa dá zistiť veľa dodatočných informácií o RDB a obsahu tabuliek. Na zisťovanie informácií a obsahu tabuliek sa dá síce použiť aj SQL konzola z RDBAnalyzera, ale nie je to také prehľadné a nie je tam toľko možností. Navyše niektoré proprietárne nástroje k RDBS majú možnosti vizualizovania ER diagramov, modelovania schémy a RDB analýz. RDBAnalyzer poskytuje funkcie, ktoré štandardné proprietárne nástroje neposkytujú avšak neposkytuje všetky štandardné funkcie týchto nástrojov. Jedným z nedostatkov nástroja RDBAnalyzer sú hlavne statické vizualizácie. Bolo by vhodné dorobiť k vizualizáciám interaktívne rozhranie, kde by sa dali pomocou kliknutia myši alebo klávesnice zisťovať informácie o objekte. Nástroj zatiaľ poskytuje relatívne málo funkcií, je však ľahko rozšíriteľný. 8.9 MAPOVANIE RELAČNÝCH DATABÁZ DO ONTOLÓGIÍ Mapovanie RDB do ontológií je jedna z kľúčových metód tejto práce. Ako som už spomínal, hlavným problémom pri orientovaní sa v RDB, ktorú nepoznáme, je jej nedostatočná sémantika. Vytvorením ontológie nad RDB by sme tento problém vyriešili, lenže vyžadovalo to by množstvo ľudskej práce doménové experta (databázový špecialista, ktorý sa v konkrétnej DB vyzná). Iným, ale bohužiaľ iba čiastočným riešením je automatické alebo poloautomatické mapovanie RDB do ontológií [66-86]. Existujú viaceré dôvody na tento proces: umožnenie hľadania informácií v RDB bez poznania modelu, táto metóda umožňuje strojové vyhľadávanie v RDB(napr. internetovým vyhľadávačom), získavanie informácií z RDB aj ľuďmi, ktorí nepoznajú technológiu RDB (laikom), čiastočne sa dajú spájať rôzne RDB, keďže sú metódy na spájanie ontológií, dá sa takto riešiť problém federovaných RDB (viď. kap Federované DB systémy). Metód mapovania RDB je viacero. Spomenul by som ešte, že tento pojem Mapovanie RDB do ontológií sa v literatúre nie vždy používa v správnom zmysle slova. Mapovanie je priradenie 63

70 nejakých hodnôt alebo objektov k iným, existujúcim hodnotám alebo objektom. V literatúre sa pod týmto pojmom tiež myslí aj vytvorenie alebo generovanie ontológie z RDB bez toho aby bola použitá nejaká ontológia na ktorú by sme RDB namapovali. Metódy mapovania môžeme rozdeliť do troch skupín podľa toho, ako mapovanie vytvárame, implementujeme alebo ako implementujeme dotazy nad mapovanými ontológiami (obr. 61). Metóda mapovania závisí najmä od účelu, na aký chceme výslednú ontológiu použiť. Obr. 61 Rozdelenie mapovania ontológií. Mapovanie môže byť buď automatické, poloautomatické alebo manuálne. Pri automatickom dostaneme celú ontológiu rýchlo (generuje sa priamo z RDB) avšak odráža sa to na jej kvalite. Poloautomatické mapovanie je interaktívny proces, kde počas automatického mapovania doménový expert upravuje vzťahy, názvy a rieši nejednoznačnosti a vzniknuté konflikty. Manuálne mapovanie je tvorba len doménovým expertom. Automatické mapovanie môžeme ďalej rozdeliť podľa toho či chceme RDB namapovať na už existujúcu ontológiu alebo či chceme vytvoriť novú len z informácií a znalostí, ktoré sú v RDB. Ešte je aj možnosť do existujúcej ontológie namapovať informácie z RDB, ktoré sú rovnaké a zvyšok ontológie dotvoriť. Keď si zoberieme implementáciu mapovania, tá sa dá rozdeliť na statickú alebo dynamickú podľa toho či ontológiu raz vygenerujeme z RDB a potom používame alebo či sa vždy pri našej požiadavke sprístupní dynamicky tá časť, ktorú chceme použiť. Z toho vyplývajú logicky aj výhody a nevýhody. Statické mapovanie ETL (Extract Transform Load) nám ponúka rýchlosť a dynamické (On-Demand) zase aktuálnosť a úsporu pamäti. Keď potrebujeme mapovať RDB do ontológie len kvôli dotazovaniu sa pomocou dotazovacieho ontologického jazyka (napr. SPARQL), prístupy môžeme rozdeliť podľa toho či sa priamo dotazujeme na ontológiu alebo je možnosť transformovať dotazovací jazyk na SQL a ním sa dotazovať na RDB. Pri transformovaní ontologického jazyka na SQL sú jeho možnosti dosť obmedzené, ale keď nám to stačí, tak ide o najefektívnejšie riešenie. Sú rôzne softvérové nástroje, ktoré mapovanie dokážu spraviť napr. RDBToOnto, D2QR, R2O, Virtuoso, Triplify, Datagrid a iné. 64

71 Pre moju prácu som si vybral statické, plne automatické mapovanie bez použitia existujúcej ontológie. Tento spôsob mapovania je rýchly, nevyžaduje doménového experta a ukážeme, že výsledky sú postačujúce pre účely jeho použitia. Proces generovania prebieha tak, že všetky tabuľky RDB budú triedy, ich atribútmi budú stĺpce s konkrétnymi dátovými typmi, riadky v tabuľkách budú inštancie tried a vzťahy medzi triedami, ale aj inštanciami, budú vlastnosti (object property). Pri testovaní som použil softvér RDBToOnto 1.2 Beta. Je určený pre stredne veľké RDB (rádovo 10ky tisíc riadkov v tabuľkách), podporuje MySQL, ORACLE, MS Access, Excel. Výstupná ontológia je vo formáte OWL. Na testovanie som použil menšiu RDB Northwind (voľne dostupná testovacia RDB od firmy Microsoft). Na obrázku 62 si môžeme pozrieť jej schému. Obr. 62 Entitno relačný diagram testovacej relačnej databázy NORTHWIND od Microsoftu. Po vygenerovaní a zobrazení ontológie vo voľne dostupnom nástroji Protégé 4.2 Beta z nej môžeme vidieť graf tried (Obr 63). Vyzerá podobne ako ER diagram na obr. 62, avšak vzťahy sú všade obojstranné. To je spôsobné tým, že v ontológiách sú vždy aj inverzné vzťahy. Nástroj Protége nám umožnuje aj interaktívne vo vizualizácií zobrazovať atribúty tried, inštancie, ich konkrétne hodnoty a aj konkrétne vzťahy medzi nimi. Ďalej je možné pomocou neho aj vyhľadávať objekty pomocou textového vyhľadávača, dotazovať sa pomocou jazyka SPARQL, ale tiež aj odvodzovať ďalšie znalosti z ontológie pomocou algoritmov FaCT++ a HermiT. Pri takto triviálne namapovanej RDB nám však odvodzovače veľa toho neodvodia. Na odvodenie použiteľných znalostí by musela byť ontológia dotvorená doménovým expertom. 65

72 Obr. 63 Vizualizovanie tried v namapovanej ontológií pomocou aplikácie Protége. Triedy sa dajú pomocou nástroja interaktívne rozkliknúť a hľadať v nich informácie. Na ukážke (Obr. 64) je zobrazený interfejs nástroja Protége a spôsob akým prehľadávame ontológiu, vygenerovanú z databázy. Jednoducho môžeme prehľadávať triedy a inštancie a pátrať po informáciách, ktoré nás zaujímajú. Konkrétne na tejto ukážke máme označenú triedu zákazníkov (customers), vpravo dole zelenou farbou vidíme atribúty jedného zo zákazníkov, ktorého sme si vybrali a nad nimi sú modrou vzťahy ku konkrétnym inštanciám triedy objednávky (orders). Obr. 64 Ukážka nástroja Protége, vľavo hore sú triedy, po rozkliknutí vidíme ich inštancie (vpravo dole) a vzťahy (vpravo v strede). 66

73 Jednoducho môžeme kliknúť na konkrétnu objednávku a pozrieť si jej detaily prípadne iné informácie, ktoré so zákazníkom súvisia. Pomocou vizualizácie v tomto nástroji si môžeme zobraziť aj ich inštancie a ich prepojenie (obr. 65). Na ukážke vidíme napríklad, že zákazník s id 20 (na obr. 65 vpravo dole) má vzťah s triedou customers (je jej inštancia, hrubá modrá čiara). Má objednávky, slabohnedé prerušované čiary. Jeho konkrétna objednávka 732 (na obr. 65 v pravo hore) je od dodávateľa 2 a podobne. Protége umožňuje tento graf interaktívne prehľadávať. Obr. 65 Vizualizácia vzťahov medzi inštanciami a triedami. Takýmto spôsobom dokáže aj laik hľadať informácie, nielen o obsahu a popise RDB na aké účely slúži, ale dokonca aj vyhľadávať informácie v nej. Tento typ mapovania, ktorý som použil je plne automatický a nevyžaduje si žiadnu ľudskú prácu. Je však veľmi dôležité, aby boli názvy objektov vhodne pomenované, aby sa dali chápať bez dodatočných informácií. To už však závisí od autora RDB, ktorý ju modeloval. V zásade však s tým problém nie je. Treba spomenúť aj nedostatky mapovania RDB do ontológií. Medzi ne patria hlavne nasledovné. Je dosť obtiažné udržiavať ontológiu aktuálnu, pri statickej implementácií, by ju bolo treba pravidelne znovu generovať, čo je dosť výpočtovo náročne, keďže RDB obsahujú veľa dát. Pri dynamickej implementácií je zase práca s ontológiou pomalá. Pri dotazovaní sa na ontológiu, napr. pomocou jazyka SPARQL, bude čas výpočtu vždy dlhší ako pri použití jazyka SQL nad RDB pri rovnakom dotaze. Často krát by pri agregovaných dotazoch výpočet ani neskončil v reálnom čase. 67

74 Existujúce nástroje, či už na mapovanie RDB, ale taktiež aj na používanie ontológií nedokážu pracovať s rozsiahlymi RDB. Napriek týmto nedostatkom je toto riešenie dostačujúce na hľadanie informácií a znalostí v malých a stredne veľkých databázach. Na použitie pri veľkých a rozsiahlych RDB by sme však potrebovali upraviť alebo vytvoriť efektívne implementácie, jednak na mapovanie RDB (pri statickom by to nemal byť problém), ale tiež nájsť vhodný nástroj na zobrazenie a hľadanie v tak veľkej ontológií aká by sa vygenerovala. Použitý nástroj Protége mal problém s pamäťou už pri stredne veľkých ontológiách. Ďalším dobrým riešením by bolo generovanie ontológie iba zo schémy RDB bez záznamov, kde by sa dynamicky pri zobrazovaní inštancií volali SQL dotazy na RDB. Užívateľ by mal náhľad k ontológií so sémantikou štruktúry alebo modelu RDB a interaktívne pri požiadavkách by sa automaticky generoval SQL dotaz, ktorý by mu zobrazil informácie o inštanciách v ontológií. Myšlienka polo/automatického sémantického popisu RDB nie je nová. Objavil som ju dokonca v článku z roku 1979 [67], v období keď sa pojem ontológie v informatike ani nepoužíval. Autori článku navrhli urobiť z tabuliek a vzťahov v RDB graf, kde pomenovali hrany výstižnými pojmami, aby bolo z nich jasné ako prepájajú tabuľky (vrcholy grafu). Potom sa v RDB vyhľadávalo tak, že sa interaktívne chodilo po grafe a z pochopenia popisov a spájaním vrcholov sa tvorili dotazy. Nepodarilo sa mi však zistiť ako ich výskum pokračoval, či to nejako vyvíjali a prečo sa to teraz nepoužíva. 9 ZÁVER V práci som sa venoval problematike spracovania, hľadania informácií a orientácie v rozsiahlych, najmä relačných databázach. V teoretickej časti som popísal zdroje a formy dát, spôsoby uchovávania týchto dát v rôznych databázových systémoch. Podrobne sú v práci popísané relačné databázové systémy a spracovanie dát v nich. Vysvetlený je problém rozsiahlych databáz, ktoré sú schopné technologicky uchovávať a spracovávať veľké množstvo dát, avšak pre človeka sú ťažko pochopiteľné a bez vývoja nových metód a algoritmov nie je možné plne využiť potenciál informácií, ktoré obsahujú. Zameral som sa najmä na metódy a postupy, ktoré slúžia pri orientácií a snahe pochopiť rozsiahlu relačnú databázu za účelom vyhľadania dôležitých informácií v nej, jej analýzy, prípadne rozšírenia jej dátového modelu databázovým architektom. V práci je ďalej popísaná vizualizácia dát a databáz, databázové metriky, ontológie, teória komplexných sieti a grafov, čo sú kľúčové východiská k riešeniu tohto problému v tejto práci. V práci som vylepšil a implementoval vizualizáciu SchemaBall (8.2.1), ktorá slúži na zobrazenie entitno relačného diagramu a zvýraznenie dôležitých častí v relačnej databáze so zložitým dátovým modelom. Navrhol a popísal som praktický postup ako skúmať rozsiahlu, zložitú alebo neznámu databázu a pochopiť ju tak, aby sa dal chápať jej účel a dali hľadať v nej informácie (8.5). Ukázal som, že pri zväčšovaní dátového modelu relačnej databázy má jej graf (vzťahy a tabuľky) charakteristiky bezškálovej siete, čo sa dá využiť pri jej skúmaní a orientovaní sa v nej (8.6). Ďalej rôzne prístupy transformácie grafu databázy a jej skúmanie pomocou vizualizácie grafov (Gephi) a grafových algoritmov. Všetky tieto prístupy a metódy som implementoval v otvorenom, ľahko rozšíriteľnom nástroji RDBAnalyzer (8.8), ktorý slúži na orientáciu a analýzu rozsiahlej relačnej databázy. Metódy ako aj nástroj RDBAnalyzer boli overené na reálnej rozsiahlej databáze CEHZ a ďalších dvoch reálnych RDB. Ďalej som ukázal možnosti ako transformovať relačné databázy do ontológií a navrhol postup ako sa v takto 68

75 vytvorených ontológiách orientovať a vyhľadávať v nich informácie (8.9). Týmto spôsobom je možné vyhľadávať a sprístupniť informácie z relačných databáz aj ľuďom, ktorí neovládajú túto technológiu, strojom alebo webovým vyhľadávačom. Tento prístup sa dá však momentálne použiť len na malé a stredne veľké relačné databázy. 9.1 VEDECKÝ PRÍNOS PRÁCE Vedecký prínos mojej práce by som zhrnul do nasledovných bodov: 1. Návrh a tvorba metódy na orientáciu, pochopenie a hľadanie informácii v rozsiahlych alebo neznámych relačných databázach (8.5). Vytvorenie nástroja RDBAnalyzer, kde sú spomínané postupy implementované. 2. Zistenie, že grafy schém a dát rozsiahlych relačných databáz majú charakteristiky bezškálových sietí (8.6) a využitie tohto poznatku (overenie a návrh databázových metrík). 3. Návrh a tvorba metódy pre orientáciu a hľadanie informácií v ontológiách generovaných z relačných databáz (8.9). 9.2 MOŽNOSTI ĎALŠIEHO VÝVOJA A VÝSKUMU Na téme by sa dalo ďalej pracovať hlavne pri probléme mapovania relačných databáz do ontológií (8.9). Súčasné riešenia sú postačujúce tak na malé a stredne veľké databázy. S implementáciou pre veľké databázy som sa nestretol. Navyše ak by aj existovala táto implementácia tohto mapovania, nebolo by ju zložité urobiť na základe programu, ktorý som vytvoril na vygenerovanie grafu n-tíc z rozsiahlych RDB (8.6.2 Prístup 3), tak ďalším problémom by bolo v akom nástroji na spracovanie ontológií by sme ju chceli používať. Pre všetky dostupné nástroje by bola vygenerovaná ontológia priveľká. Vyžadovalo by to teda vytvoriť nástroj na editovanie a hľadanie informácií takto veľkých ontológií. Mohol by to byť nový modul nástroja RDBAnalyzer. Alebo tiež urobiť nejakú rozumnú kombináciu, kde by napríklad ontológia obsahovala nejaké časti databázy (tabuľky a vzťahy) a ďalšie (záznamy) by sa dali interaktívne dotazovať z aktívnej databázy a podobne. Navyše automatické mapovanie, ktoré som v práci popísal a overil by sa mohlo vylepšiť o ďalšie sémantické informácie z databázy. Ďalšou možnosťou vylepšenia v práci popísaných metód a vizualizácii na orientáciu a hľadanie dôležitých častí v rozsiahlej databáze by mohlo byť aj zapracovanie ďalších metainformácií do metrík a rankingov. Informácie o používaní a zmenách jednotlivých tabuliek, záznamov, objektov v databáze a záznamy z logov nám môžu veľa hovoriť o dátach v databáze a ich dôležitosti. 69

76 SKRATKY A VYSVETLIVKY CEHZ - Centrálna Evidencia Hospodárskych Zvierat DM - Data Mining ER Diagram - Entitno Relačný Diagram GEXF - XML formát pre uloženie grafu, používa sa v nástroji GEPHI GEPHI - nástroj na vizualizovanie a analýzu grafov a sieti JDBC - Java Database Connectivity ODBC - Open Database Connectivity OLAP - Online Analytical Processing OLTP - Online Transactional Processing OODB - Object Oriented Database OWL - Web Ontology Language RDB - Relational Database RDBS - Relational Database System RDF - Resource Description Framework RDFS - Resource Description Framework Schema SEQUEL - Structured English Query Language SPARQL - SPARQL Protocol and RDF Query Language URI - Uniform Resource Identifier URL - Uniform Resource Locator URN - Uniform Resource Name VLDB - Very Large Databases W3C - The World Wide Web Consortium 70

77 PRÍLOHY A DIAGRAMY TRIED NÁSTROJA RDBANALYZER Diagramy sú generované v nástroji Enterprise Architect od firmy Sparx. Obr. 1 Triedy sú rozdelené do balíkov. Všetky balíky sú v balíku dbsanalyzer. Obr. 2 Balík application obsahuje jedinú triedu Gui. Trieda zabezpečuje grafický interface alebo aplikačnú vrstvu nástroja. 71

78 Obr.3 Balík connection obsahuje triedy zabezpečujúce spojenie aplikácie s databázou. Sú tu aj dve triedy s aplikačnou vrstvou (SQLConsole a GuiPripoj). Obr. 5 Balík graph je určený na prácu s grafom a jeho reprezentáciu. 72

79 Obr. 4 Balík datastructures obsahuje triedy reprezentujúce tabuľky a vzťahy medzi nimi v databáze. 73

80 Obr. 6 Balík graphics obsahuje triedy s vizualizáciami (Schemaball, RelationGraph, RelationBigGraph). 74

81 B NÁVOD NA POUŽITIE NÁSTROJA RDBANALYZER RDBAnalyzer Nástroj RDBAnalyzer slúži na hľadanie informácií a orientáciu vo veľkej alebo neznámej relačnej databáze. Umožňuje najmä pomocou vizualizácií rýchlejšie pochopiť databázovú schému a na základe toho pomáha hľadať v nej informácie alebo ju upravovať. Nástroj je spustiteľný na operačných systémoch Windows, Unix, Linux, Mac resp. kde je nainštalovaná Java a umožňuje pripojenie na ľubovoľný relačný databázový systém, pre ktorý existuje ovládač JDBC. Implicitne je podpora pre MySQL, Oracle a PostgreSQL. Nástroj ponúka nasledujúce funkcionality: vizualizovanie databázovej schémy metódou SchemaBall, vizualizovanie grafu vzťahov, rozdelenie grafu schémy na komponenty, stĺpcový graf metrík, export grafu schémy do nástroja Gephi. Hlavný formulár spusteného nástroja môžeme vidieť na obrázku 1. Obr. 1 Hlavný formulár nástroja RDBAnalyzer. V ľavej časti je strom s pripojeniami, v pravej je panel pre výstupy operácií a vpravo dole je konzola pre textové výstupy a upozornenia. 75

82 1 Pripojenie k databáze a načítanie schémy Pripojenie k databáze vykonáme pomocou hlavného menu File -> new connection, vyplníme formulár (viď obr. 2) Obr. 2 Formulár pre vytvorenie pripojenia k databáze. V strome sa nám vytvorí pripojenie na schému (obr. 3). Obr. 3 Vytvorené pripojenie k databáze na schému NORTHWIND. Ak chceme použiť funkcionality nástroja, musíme najskôr načítať tabuľky a vzťahy v schéme. Označíme schému, ktorú chceme načítať a v menu klikneme File -> load schema. Tento proces môže niekedy dlhšie trvať, ak má schéma veľa tabuliek a vzťahov. Po úspešnom načítaní v strome pribudne ďalší prvok s už načítanou schémou (obr. 4). Obr. 4 Strom po načítaní informácií o schéme. Nad týmto prvkom už môžeme vykonávať vizualizácie a vytvárať grafy, ale odporúčam ešte rozdeliť graf schémy na komponenty kliknutím v menu na Tools -> split schema. Funkcionalita rozdelí schému na časti a označí percentuálne zastúpenie tabuliek (obr. 5). Obr. 5 Rozdelenie grafu schémy na komponenty. V tomto prípade sú všetky tabuľky v jednom grafe relácií. 76

83 2 Vizualizácia SchemaBall Vizualizáciu spustíme kliknutím v menu na Tools -> SchemaBall. Na pravej strane formulára sa pridá záložka s vizualizáciou (obr. 6). Funkcionalita funguje len na schéme, ktorá už bola načítaná. Obr. 6 Vizualizácia Schemaball. 3 Vizualizácia grafu relácii Vizualizáciu spustíme kliknutím v menu na Tools -> relation graph. Na pravej strane formulára sa pridá záložka s vizualizáciou (obr. 7). Funkcionalita funguje len na schéme, ktorá už bola načítaná. Obr. 7 Vizualizácia grafu relácií. 77

84 4 Zobrazenie grafu tabuliek s počtom ich relácií Graf vytvoríme kliknutím v menu na Tools -> metrics chart -> výber metriky. Na pravej strane formulára sa pridá záložka s grafom (obr. 8). Funkcionalita funguje len na schéme, ktorá už bola načítaná. Obr. 8 Graf tabuliek s počtom ich vzťahov. 5 SQL konzola Na zisťovanie dodatočných informácií z databázy môžeme použiť SQL konzolu. Spustíme ju tak, že si označíme pripojenie k databáze v strome a klikneme v menu na Tools -> SQL Console (viď obr. 9). Obr. 9 Graf tabuliek s počtom ich vzťahov. 78