Fakulta informatiky a managementu · zpravodajská analýza. Nejprve je čtenář seznámen s teoretickými základy nutnými pro dobré porozumění celému konceptu linkových analýz

Univerzita Hradec Králové

Fakulta informatiky a managementu

Katedra informatiky a kvantitativních metod

Návrh a implementace systému pro rozsáhlé linkové analýzy

Diplomová práce

Autor: Bc. Jan Kropáček

Studijní obor: Aplikovaná informatika

Vedoucí práce: Ing. Barbora Tesařová, Ph.D.

Hradec Králové srpen 2016

Prohlášení

Prohlašuji, že jsem diplomovou práci zpracoval samostatně a s použitím

uvedené literatury.

V Hradci Králové dne 17.8.2016 Jan Kropáček

Poděkování

Rád bych poděkoval vedoucí této diplomové práce Ing. Barboře Tesařové, Ph.D.

za metodické vedení práce, za konzultace, její rady a připomínky v průběhu příprav

práce. Dále bych rád poděkoval své ženě Zuzce za podporu a hlavně za její trpělivost.

Anotace

Předkládaná diplomová práce se zabývá možností využití grafových databází

pro účely tvorby linkových analýz a to především pro obory jako jsou kriminální či

zpravodajská analýza. Nejprve je čtenář seznámen s teoretickými základy nutnými

pro dobré porozumění celému konceptu linkových analýz nad grafovými daty. Jsou

proto probrány základní formy ukládání a práce s daty majícími charakter sítě uzlů a

vazeb. Stejně tak je pozornost věnována i elementárním principům analýzy

takovýchto dat a problémům specifickým právě pro tento obor. Následně je

popsaných poznatků využito pro výběr vhodných technologií a pro teoretický návrh

struktury aplikace určené pro provádění linkových analýz. Základní funkční kostra

takto navržené aplikace je i prakticky realizována.

Annotation

Title: Design and implementation of a system for large link analysis

This diploma thesis deal with possibility of using graph databases for link

analysis, especially in domains such as criminal or intelligece analysis. The first part

presents teoretical foundations essential for good understanding the whole concept

of link analysis and graph data processing. There are discussed basic forms of storing

and working with graph data. In the second part of the thesis, this basic principles

are used for the design of link analysis application and for selection of aplicable

technologies. Core of the designed application is practically implemented.

Obsah

1 Úvod ........................................................................................................................................... 1

2 Analýza dat, linkové analýzy a analýza sociálních sítí ................................................................ 2

2.1 Význam vizualizace grafových dat ...................................................................................... 6

3 Grafová data v oboru linkových analýz ...................................................................................... 8

3.1 Není graf jako graf .............................................................................................................. 8

3.2 Typy grafů ........................................................................................................................... 9

3.3 Reprezentace dat a jejich ukládání .................................................................................. 12

3.3.1 Relační databáze ...................................................................................................... 13

3.3.2 NoSQL databáze ....................................................................................................... 14

4 Teorie grafů a teorie sítí ........................................................................................................... 21

4.1 Základní parametry grafů a jejich prvků ........................................................................... 23

4.2 Problémy řešené pomocí teorie grafů a sítí ..................................................................... 25

4.3 Využití teorie grafů a grafových algoritmů v praxi linkových analýz ................................ 26

4.4 Další oblasti použití grafových dat ................................................................................... 28

5 Návrh systému pro linkové analýzy nad grafovou databází ..................................................... 30

5.1 Požadavky na navrhovaný systém.................................................................................... 30

5.2 Přehled existujících nástrojů použitelných pro linkové analýzy ....................................... 32

5.3 Volba použitých technologií ............................................................................................. 38

5.3.1 Aplikační server ........................................................................................................ 41

5.3.2 Grafová databáze ..................................................................................................... 43

5.3.3 Webový klient .......................................................................................................... 48

5.4 Grafické uživatelské prostředí a základní funkce systému OrientLink ............................. 55

5.5 Vnitřní struktura systému OrientLink ............................................................................... 60

5.6 Zpracování dat v rámci aplikace OrientLink ..................................................................... 64

6 Příklady práce využívající linkové analýzy ................................................................................ 67

7 Závěr ......................................................................................................................................... 72

Seznam použité literatury ................................................................................................................ 73

Seznam obrázků ............................................................................................................................... 75

Seznam tabulek ................................................................................................................................ 75

1

1 Úvod

Předkládaná diplomová práce se zabývá návrhem a implementací analytického

prostředí umožňujícího zpracování různorodých vzájemně provázaných dat

ukládaných ve formě grafu a to hlavně formou vizualizace takovýchto dat. Činnost

využívající k vyhodnocování data vizualizovaná ve formě síťového grafu je nazývána

linková analýza a některé z jejích forem jsou využívány v mnoha oborech lidské

činnosti.

Pro návrh výše zmíněného analytického systému je nutné zvolit vhodné

technologie, algoritmy a pracovní postupy. Proto jsou v úvodu této diplomové práce,

po stručném nastínění problematiky linkových analýz samotných, probrány možné

technologie využitelné v jednotlivých částech výsledného systému. Pozornost je

věnována především formám ukládání a zpracování grafových dat. Dále také samotné

struktuře vytvářené aplikace. Na základě zvolené struktury pak i jednotlivým

využitým technologiím, nástrojům či aplikačním rámcům (frameworkům).

Cílem práce je kromě samotného výběru vhodných nástrojů také následná

realizace zamýšleného analytického prostředí. Nemělo by se jednat o konečný

produkt, nýbrž o zjednodušenou kostru analytického prostředí. Pomocí takovéhoto

funkčního prototypu bude dokázáno, že v předešlém kroku zvolené postupy

a technologie splňují požadované předpoklady a že bude možné je pro vývoj

obdobných systémů efektivně využít. Výsledný prototyp aplikace by v případě

potřeby mohl být použit i jako základ při vývoji požadovaného analytického

prostředí.

2

2 Analýza dat, linkové analýzy a analýza sociálních

sítí

V dnešní informační době je stále větší důraz kladen na využití pokud možno

všech poznatků, které se mohou nacházet v nepřeberném množství poměrně

jednoduše dostupných dat. Často se může jednat o poznatky, které nemusí být při

prvním pohledu na tato data vůbec zřejmé. Právě s tímto problémem nám pomáhá

analýza dat.

Analýza dat je komplexním oborem využívajícím velmi rozsáhlý aparát

matematických, statistických a informatických metod, často navíc ještě spolu

s principy strojového učení a umělé inteligence. Kromě využití výše vyjmenovaných

principů je pro úspěšnou analýzu vždy zásadní i dobrá znalost zkoumaného oboru.

Při analytickém procesu je využíváno procesů redukce, řazení, třídění,

restrukturalizace a vzájemného spojování datových záznamů. Výsledkem analýzy by

mělo být buď pochopení nějakých dosud neznámých principů skrytých

ve zkoumaných datech, ověření platnosti hypotézy, nebo predikce budoucích stavů

zkoumaného procesu. (1)

Pod analýzou dat je možné vidět proces vedoucí k převedení surových dat

v informace a ty následně v prakticky využitelné znalosti. Přičemž za data v tomto

procesu považujeme jakákoli známá fakta o vnějším světě. Informacemi se data

stávají ve chvíli zpracování, kdy známe jejich hodnotu a reálný význam. O znalostech

poté mluvíme ve chvíli, kdy jsme schopni pomocí zpracovaných informací (a dat)

spolu s vlastním úsudkem (zkušeností) vytvářet rozhodnutí, která bychom bez těchto

znalostí pravděpodobně neudělali. (1)

Tématem této práce jsou linkové analýzy, které můžeme považovat za užší

podmnožinu všeobecné analýzy dat. Pojmem linková analýza je myšleno především

vyhodnocování dat majících grafový charakter popisující vzájemné vztahy mezi

různými entitami pomocí jejich vizualizace. K analýze takto uspořádaných dat je pak

možné využít principy vycházející z matematického oboru nazývaného teorie grafů.

Právě v případě takovéhoto typu dat se stává možnost zobrazení vzájemných vztahů

jednou ze zásadních podmínek dobrého porozumění zkoumanému vzorku dat. Mohou

tak jednoduše vyplynout dodatečné poznatky, které by při klasickém náhledu na

3

stejná data byly jen těžko rozpoznatelné. Z tohoto pohledu je provádění linkových

analýz považováno spíše za analyticko-vizualizační proces (2). Náhled na data

v grafické podobě je nutné podpořit sadou nástrojů umožňujících filtrování, řazení,

případně i zvýraznění vybraných entit a jejich vazeb na základně hodnot různých

parametrů. Za tímto účelem jsou používány různé grafové algoritmy a nástroje

analýzy sociálních sítí (SNA1). Jarke J. van Wijk ve své práci The Value of Visualization

(3) popisuje proces vizuální analýzy jako cyklus činností zahrnující významnou část

iniciativy uživatele (analytika) avšak podpořený strojovým předzpracováním dat a

tvorbou počáteční vizualizace (viz obrázek 2.1). Tento cyklus popisuje přesně

provádění linkových analýz a tím, dá se říci, i požadované schopnosti navrhované

aplikace pro linkové analýzy.

Analýza sociálních sítí1 je jedním z oborů využívajících užší část teorie grafů

nazývanou teorie sítí. SNA se dnes stala mezi odbornou veřejností asi nejvíce

skloňovaným oborem využívajícím principů vycházejících z teorie grafů. Zřejmě proto

se také pojem SNA pomalu stává synonymem pro celý obor využívající k analýze

pohled na data jako na síť navzájem provázaných uzlů. Nemusí se ovšem zdaleka

jednat pouze o data popisující mezilidské vztahy či přímo pocházející ze sociálních

1 SNA – Social Network Analysis

Obrázek 2.1: Proces vizuální analýzy, zdroj: (3)

4

sítí. Stejnými postupy bývají vyhodnocována například data z diskuzních příspěvků,

záznamy o nákupech v e-shopu, data z obchodního rejstříku, geografická data nebo

třeba transakční data o finančních převodech či telefonních hovorech. Značný

informační přínos může navíc vyplynout při propojení a společném využití více

takovýchto datových zdrojů najednou. Pomocí analýzy sociálních sítí pak lze získávat

zajímavé a jiným způsobem těžko odvoditelné poznatky o rozložení celé sítě na různé

skupiny, o vzájemné provázanosti těchto skupin, o něčem výjimečných entitách nebo

třeba o opakujících se vzorech chování těchto entit.

Oba pojmy SNA a linkové analýzy jsou často ztotožňovány a používány

ve stejném kontextu. I tak je ale vhodné tyto obory analýzy rozlišovat. O linkových

analýzách většinou hovoříme zejména při ruční práci s daty ve vizualizované podobě

zejména v oborech, jako jsou kriminální (především odhalování organizovaného

zločinu a podvodného jednání) a zpravodajská analýza, v bankovním a pojišťovacím

sektoru nebo třeba v oblasti bezpečnosti a spolehlivosti počítačových sítí. Základní

principy a grafová struktura dat jsou v obou případech shodné, rozdílem však bývá

zejména rozsah zpracovávaných dat. Zatímco v analýze sociálních sítí se pracuje

s velmi rozsáhlými datovými soubory, které by nebylo vůbec možné rozumně

vizualizovat a následně zpracovat lidskou silou, při použití linkových analýz se

donedávna většinou pracovalo s objemy dat o poznání menšími a většina práce zde

byla ponechána na subjektivním posouzení analytika. Tento rozdíl se však v současné

době pomalu smazává a i do linkových analýz vstupují tak objemné soubory dat, že

jejich ruční zpracování již téměř není realizovatelné. Právě v těchto případech je

přistoupeno k využití principů SNA k nutnému předzpracování dat. Zejména

k vyhledávání významných částí grafu nebo významných entit, na které je nutné se

následně zaměřit podrobněji. Právě to je úkolem systému vytvářeného v rámci této

diplomové práce. Mělo by se jednat o systém, který je schopen uchovávat velmi

rozsáhlé soubory dat a v nich efektivně vyhledávat požadované (zájmové) entity a

jejich vzájemné vazby. Pro vyhledávání těchto zájmových dat by výsledný systém měl

nabídnout řadu různých přístupů tak, aby si koncový uživatel mohl v konkrétní

situaci zvolit ten správný nástroj.

Jako další rozdíl mezi SNA a linkovými analýzami bývá také uváděno schéma

zpracovávaných dat. Rozdíl mezi linkovou analýzou a analýzou sociálních sítí z tohoto

5

pohledu vidíme v odlišné struktuře zkoumaného grafu. Data zkoumaná v analýze

sociálních sítí bývají tvořena entitami a vazbami stejných nebo alespoň podobných

(souvisejících) typů. Těchto typů je velmi omezená množina (například vztahy mezi

osobami nebo mezi osobami a organizacemi, viz obrázek 2.2). V některých případech

dokonce nemusí být typ vazeb či uzlů rozlišován vůbec a informace je nesena pouze

tím faktem, že víme o vzájemném propojení dvou uzlů. Na rozdíl od toho se v případě

linkových analýz ve zkoumaných datech nachází velmi různorodé typy entit a vazeb,

často pocházející z naprosto odlišných oborů lidské činnosti (4) (5).

Může se jednat o osoby a osobní vztahy mezi nimi, navíc o vazbu těchto osob

například na bankovní účty, vlastnictví (nebo užívání) určitého předmětu (vozidlo,

mobilní telefon, atd.), účast na události (nebo přítomnost v určitém čase na určitém

místě), příslušnost k organizaci, atd. Mezi všemi těmito druhy entit pak mohou být

sledovány různé vazby (finanční transakce mezi účty, telefonní hovory mezi telefony,

atd.). Navíc je zde nutné mít možnost u jednotlivých entit a vazeb vyhodnocovat i

řadu doplňujících atributů (viz obrázek 2.3). Je vhodné, aby množina takto

posuzovaných entit, vazeb a atributů nebyla uzavřená a aby do systému pro linkové

analýzy bylo možné kdykoli zařadit nový typ entity nebo vazby i s jejich různými

atributy. Na takto vytvořeném datovém souboru je pak možné provádět stejné úkony

a výpočty jako v případě SNA a to v závislosti na konkrétních požadavcích buď cíleně

jen na předem zvolených typech entit a vazeb anebo globálně přes všechny prvky.

Obrázek 2.3: Příklad linkové analýzy, zdroj: autor Obrázek 2.2: Příklad SNA, zdroj: autor

6

2.1 Význam vizualizace grafových dat Vizualizace obecně napomáhá lidskému mozku snadněji a lépe porozumět

zpracovávaným datům. Například rozdíly nebo poměry hodnot vyjádřené čísly nejsou

pro mozek na první pohled jednoduše srozumitelné. Tato situace se navíc ještě zhorší,

pokud je nutné srovnávat více než pouze dvě hodnoty. V takovém případě až jejich

vhodně zvolené společné zobrazení značně napomůže k rychlému vnímání skutečné

podstaty popsané předkládanými hodnotami. (6) (7)

Vizualizace ve formě síťového grafu přináší oproti ostatním formám vizualizace

jiný pohled na informace v datech obsažená. Jedná se zejména o vzájemné vztahy

jednotlivých entit. To jsou poznatky, které z běžného zobrazení dat nejsou ve většině

případů na první pohled patrné. Zejména pak, pokud roste objem zobrazovaných dat.

Správně navržená a provedená vizualizace ve formě síťového grafu na rozdíl od

tabulkové formy náhledu na data znázorňuje kromě hodnot dat i jejich strukturu

(topologii) (8). Pro představu je možné si porovnat, jak přehledné jsou na první

pohled následující tabulka 2.1 a obrázek 2.4, ve kterých jsou zobrazena totožná data.

Tabulka 2.1: Výpis finančních transakcí, zdroj: autor

Obrázek 2.2: Linková analýza finančních toků, zdroj: autor

7

Jedná se o krátký výpis bezhotovostních finančních transakcí mezi pěti účty.

V obou případech jsou zobrazena naprosto stejná data. Na obrázku je však již na první

pohled patrný „směr“ toku podstatné části převáděných peněz. Navíc už počet účtů

zapojených do transakcí je zde při prvním pohledu jasně viditelný, což se o zobrazení

stejných dat ve formě tabulky zdaleka říci nedá. A to se jedná o příklad s minimálním

objemem dat, význam obdobných vizualizací poroste úměrně s tím, jak poroste objem

zobrazených dat. Stručně řečeno, tabulka s výpisem transakcí o 100 řádcích podá, na

rozdíl od linkové analýzy, analytikovi jen velmi malou představu o tom, jak se finance

mezi jednotlivými entitami skutečně přesouvají. Je však nutné podotknout, že při

značném nárůstu objemu zpracovávaných dat brzo přestane být přehledný i obrázek

linkové analýzy. V tom okamžiku je nutné přistoupit k použití různých nástrojů

umožňujících vhodné filtrování či zvýraznění pouze některých částí dat.

8

3 Grafová data v oboru linkových analýz

Společným jmenovatelem každé práce využívající linkové analýzy (případně SNA)

je právě struktura zpracovávaných dat odpovídající síťovému grafu. S těmito daty se

dá pracovat v různých podobách. Proto je důležité ujasnit si výhody i případné

nevýhody jednotlivých přístupů. V této kapitole budou proto stručně rozebrány různé

možnosti ukládání dat v dnešních databázových systémech. Právě z formy uložení dat

vychází i možnosti a efektivita jejich následného zpracování.

3.1 Není graf jako graf Většina lidí si pod pojmem graf představí obrázek názorně zobrazující například

množství nějaké veličiny, srovnávající číselné hodnoty, vyjadřující trend vývoje nebo

popisující průběh nějaké matematické funkce (viz obrázek 3.1). Zkrátka některý z

řady různých grafů, se kterými se v běžném životě všichni setkáváme. Takovéto grafy

jsou hojně využívány snad ve všech oborech a to zejména pro názornější prezentaci

předkládaných informací. V této práci (a v teorii grafů obecně) je pod pojmem graf

myšleno něco odlišného. Jedná se o množinu navzájem propojených uzlů vyjadřující

topologii celé zkoumané sítě. Tato množina uzlů a jejich vazeb je základním

stavebním kamenem celé teorie grafů.

Obrázek 3.1: Příklady běžně používaných grafů, zdroj: autor

9

Každý graf se v tomto oboru skládá ze dvou množin základních prvků a to z uzlů,

někdy také nazývaných vrcholy (anglicky vertex, node nebo jednoduše point), a hran,

někdy nazývaných linkami nebo vazbami (anglicky edge, line).

Obrázek 3.2: Graf z oboru teorie grafů skládající se z uzlů a hran, zdroj: autor

V anglicky psané literatuře týkající se souvisejících oborů je tento problém

rozlišení jednotlivých výše popsaných variant grafu o něco jednodušší. Přesto, že

slovo „graph“ může být překládáno také v obou významech, bývá v odborné literatuře

většinou používáno ve významu grafu jako množiny uzlů a vazeb. Naopak pro graf ve

významu diagramu nebo schématu bývá používáno slovo „chart“. V této práci bude

nadále pod pojmem graf myšlen výhradně jeho význam z teorie grafů.

3.2 Typy grafů Tato kapitola se nebude zabývat všemi typy grafů tak, jak je definuje obecná teorie

grafů, nýbrž pouze jejich variantami používanými v praxi v námi zkoumaných

oborech linkových analýz (případně SNA). V praxi linkových analýz se můžeme setkat

s několika pohledy na dělení grafů do různých typů, každý z těchto typů má své

specifické vlastnosti a také omezení.

Základní dělení rozlišuje grafy na orientované a neorientované. V případě

orientovaného grafu lze jednoznačně určit směr hrany (od kterého uzlu, ke kterému

10

daná hrana vede). Lze proto také říci, že každá hrana takového grafu má jasně daný

začátek (anglicky Head) a konec (anglicky Tail). Naproti tomu u neorientovaného

grafu nelze takto jednoznačně směr vedení hrany specifikovat (9). To je většinou

interpretováno tak, že jedna hrana je považována za spojení dvou uzlů vedoucí jak

z uzlu A do uzlu B, tak zároveň i opačným směrem (z uzlu B do uzlu A). I v případě

orientovaného grafu se můžeme často setkat s vizualizací znázorňující hranu mající

protichůdné šipky směřující k oběma jejím uzlům. Nejedná se v tom případě o hranu

neorientovanou, nýbrž o dvě opačně orientované hrany mezi shodnými dvěma uzly.

Tato varianta může být znázorněna jako výše zmíněná jedna hrana se šipkami na obě

strany nebo jako dvě samostatné hrany každá v jiném směr (viz obrázek 3.3).

Obrázek 3.3: Dvě možnosti vizualizace protichůdných rovnoběžných hran, zdroj: autor

Dále grafy dělíme na grafy prosté a multigrafy. Toto dělení odráží možnost

vytvoření násobných hran mezi dvojicí uzlů (10). Multigraf může mezi dvěma uzly

obsahovat více než jednu hranu. Takovýmto hranám spojujícím shodné dva uzly

říkáme rovnoběžné. V prostém grafu se může mezi dvěma uzly vyskytovat vždy

nanejvýš jedna hrana (viz obrázek 3.4). Neobsahuje tudíž žádné rovnoběžné hrany.

V oboru linkových analýz jsou téměř výhradně využívány multigrafy. V případě

potřeby je však možné omezit počet rovnoběžných hran na základě konkrétního typu

vazby.

Obrázek 3.4: Srovnání prostého grafu (vlevo) a multigrafu (vpravo), zdroj: autor

11

Poměrně specifickou množinou grafů jsou takzvané hypergrafy. V jejich případě

může hrana spojovat více než dva uzly (viz obrázek 3.5). V oboru linkových analýz

nejsou hypergrafy běžně používány. Jestliže je třeba v některém případě zaznamenat

vzájemné spojení více než dvou uzlů, je takováto hrana nahrazena uzlem. Ten je poté

pomocnými hranami napojen na všechny uzly, které bylo třeba spojit původní hranou

(obrázek 3.6 vlevo). V argumentech tohoto vytvořeného uzlu jsou pak ukládány

informace náležící jím nahrazené hraně. Druhým možným přístupem k vyřešení

problému uložení hypergrafu do ekvivalentního grafu bez použití vazeb mezi více

uzly je nahrazení takové hrany více hranami (stejného typu) mezi všemi propojenými

uzly (tzv. „každý s každým“) (obrázek 3.6 vpravo). Hypergrafy nacházejí své

uplatnění například v oboru elektrických obvodů, kde vodič (plošný spoj) spojující

více než dvě součástky je právě hranou hypergrafu.

Obrázek 3.5: Hypergraf, zdroj: (11)

Obrázek 3.6: Dvě možnosti nahrazení hypergrafu hranami prostého grafu, zdroj: autor

12

Všechny výše popsané varianty grafů se mohou vyskytovat v takzvané

ohodnocené formě. V tom případě je ke každé hraně přiřazeno číslo udávající její

váhu. Váha hrany a její význam je blíže popsán v kapitole 4.

V oborech grafových databází i linkových analýz jsou téměř výhradně využívány

tzv. grafy atributové (anglicky property graph). V nich je možné ke každému uzlu, a ve

většině implementací také ke každé hraně, ukládat další informace ve formě atributů.

Takovým atributem může být například jméno či věk v případě uzlu vyjadřujícího

osobu, IČO a sídlo v případě uzlu vyjadřujícího organizaci nebo časové razítko či

finanční obnos v případě vazby reprezentující bankovní finanční převod.

3.3 Reprezentace dat a jejich ukládání Z historických důvodů je doposud nejrozšířenějším systémem ukládání dat relační

model. Ten byl a stále je hojně využíván pro ukládání a zpracování snad všech

možných datových struktur. Ačkoli je většinou možné pomocí různých úprav uložit do

relačních databází jakákoliv data, v řadě případů není takové řešení tou

nejefektivnější metodou. Právě proto se v dnešní době v praxi kromě relačního

modelu již citelně rozšiřují i takzvané NoSQL databáze. Jedná se o množinu

databázových nástrojů využívajících pro ukládání dat jiný model než relační.

Postupem času se v této kategorii databází vytvořilo několik základních konceptů,

které se zásadně liší využívanými principy a tím také oblastí možného nasazení.

Nutné je zde poznamenat, že označení NoSQL neznamená, že tyto databáze

nepoužívají populární standardizovaný dotazovací jazyk SQL (využívaný v relačních

databázích), jak bylo v počátcích jejich vývoje často milně uváděno. Zkratka „NoSQL“

je dnes čtena jako „Not Only SQL“. To naznačuje, že použití SQL je i v těchto

databázových modelech možné. Navíc je zde ovšem každý takovýto databázový

systém rozšířen o další možnosti práce s uloženými daty. Tyto nové formy dotazování

se u jednotlivých kategorií NoSQL databází mohou značně lišit a vždy se snaží vytěžit

maximum z výhod té konkrétní koncepce uložení dat, pro kterou jsou určeny. (12)

V reálně používaných informačních systémech jsou často požadovány takové

protichůdné vlastnosti, že volbou některé z dále popisovaných struktur ukládání dat

by došlo ke zlepšení konkrétních vlastností vždy na úkor jiných požadavků. Proto je

v takových případech nutné přistoupit k řešení využívajícímu kombinace různých

13

datových struktur. Často to bývá právě využití klasické relační databáze spolu

s některou z NoSQL databází. Nevýhodou takto složeného systému je pak zejména

jeho složitost a náročnost zajištění kompatibility a vzájemné spolupráce jeho

jednotlivých částí. Tento přístup k zajištění ukládání dat ve složitém informačním

systému byl nazván „Polyglotní persistence“ (13).

3.3.1 Relační databáze

Základní strukturu relačních databází tvoří dvourozměrné tabulky, ve kterých

jsou data ukládána. Každý řádek tabulky je považován za samostatný záznam. Tyto

databáze jsou nazývány relačními, protože je v nich využita možnost v některých

sloupcích dané tabulky ukládat klíče, pomocí nichž jsou uchovávány relace daného

řádku na jiné tabulky. Jednotlivé sloupce každé tabulky (atributy) mají v relačních

databázích přesně definovaný použitý datový typ a význam.

V praxi dnes existuje celá řada relačních databází od jednoduchých

minimalistických řešení určených pro nasazení uvnitř programu pouze pro jeho

vlastní potřeby (embedded databáze), až po distribuované serverové databázové

systémy schopné bez problému obsloužit velmi velké množství současných

požadavků. Stejně tak můžeme nalézt volně šiřitelné databázové projekty spravované

komunitou i profesionální komerční distribuce vyvíjené nadnárodními společnostmi.

Samozřejmě i do relačních databází je možné ukládat data ve formě grafu, která

v oboru linkových analýz zpracováváme. Jedna z možných forem takového uložení je

zobrazena na obrázku 3.7.

Obrázek 3.7: Příklad uložení grafových dat v relační databázi, zdroj: (14)

14

Takovéto řešení však skýtá několik zásadních nevýhod. Zejména se jedná o velmi

neefektivní realizaci průchodů grafem. Takovéto operace v praxi vedou na algoritmy

využívající iterace a velké množství spojování (JOIN) tabulek. Příklad takového

dotazovaní nad daty v relační databázi je uveden v přiloženém kódu 3.1. V levé části

je jednodušší případ, kdy se ptáme pouze na přátele Boba. V pravé části je pak patrný

nárůst počtu operací JOIN (a tím i složitosti) když se chceme ptát na „přátele všech

přátel Alice“.

Kód 3.1: SQL dotazy nad grafovými daty v relační databázi, zdroj: (14)

Další nevýhodou použití relačních databází v oboru linkových analýz je nutnost

velmi striktního nadefinování schématu ukládaných dat. To v případě nutnosti

uložení například vazby nového typu vede k složitým změnám struktury tabulek

relační databáze.

3.3.2 NoSQL databáze

V této kapitole budou stručně popsány základní principy nejrozšířenějších

typů NoSQL databázových systémů i s jejich možnostmi, výhodami a oblastmi, kde je

možné jejich využitím dosáhnout vyšší efektivity. Hranice mezi jednotlivými zde

popsanými kategoriemi databázových systému však mohou být dosti nejasné a

v praxi se můžeme setkat se systémy implementujícími prvky z více NoSQL

paradigmat. Takové systémy je pak těžké jednoznačně zařadit do jedné

z popisovaných kategorií NoSQL.

15

Key-Value store

V případě Key-Value2 databází jsou data ukládána v podobě asociativních polí. To

znamená, že ke každé uložené hodnotě je přiřazen určitý klíč, pomocí nějž k datům

přistupujeme. Pro každý takovýto klíč je vždy jednoznačně přiřazena pouze jedna

hodnota ukládaných dat. Tento princip ukládání dat umožňuje velmi rychlý přístup

ke konkrétním datům v případě, že známe klíč, pod kterým jsou uložena. Naopak

Key-Value databáze ve své původní podobě vůbec neumožňují v datech vyhledávat

podle hodnoty obsahu (jak si řekneme dále, lze dnes tento nedostatek poměrně

jednoduše obejít). Není proto možné využívat složité dotazování nad daty a další

pokročilé funkce jako u ostatních databázových paradigmat. Například jedna ze

základních SQL operací JOIN nelze v tomto případě realizovat v podobě dotazu na

data, ale musíme jí řešit buď už při ukládání dat (potažmo při návrhu struktury

realizované databáze) nebo až při dotazování na data programově. Právě výše

popsané vlastnosti databází typu Key-Value store je předurčují zejména pro

specifické případy použití, kdy není nutné dělat dekompozici ukládaných dat. Na

rozdíl od některých jiných NoSQL databází tak Key-Value store nejsou plnohodnotnou

náhradou za relační databáze, ale pouze doplňkem vhodným k použití v úzce

specifických případech a to často právě ve spolupráci s další hlavní databází jiného

typu. (12)

Ukládané hodnoty mohou být v různých datových formátech od jednoduchého

textového řetězce, seznamů a sad (řazené či neřazené) až po libovolné komplexní

objekty. Ty jsou pak ukládány v serializované podobě.

Naproti výše popsaným nevýhodám mohou Key-Value databáze kromě extrémně

rychlého přístupu k obsahu pomocí známého klíče nabídnou také řadu dalších

užitečných vlastností a funkcí. V neposlední řadě je pozitivní to, že implementace

systému Key-Value bývá velmi jednoduchá. Rozhraní každé takovéto databáze vlastně

obsahuje tři základní funkce: PUT (vložení hodnoty pod zadaný klíč), GET (přečtení

hodnoty identifikované daným klíčem) a DELETE (smazání konkrétní dvojice

klíč-hodnota). Konkrétní systémy používané v praxi pak navíc k těmto základním

funkcím mohou nabízet i pokročilejší metody vhodné pro specifické využití.

2 Key-Value store lze do češtiny přeložit jako databáze Klíč-Hodnota, přesto se však v odborné literatuře používá anglického názvu bez počešťování.

16

V dnešní době se již některé ze systémů Key-Value store snaží odstranit výše

zmíněný nedostatek zapříčiněný nemožností vyhledávání podle hodnot vytvářením

sekundárních indexů. Díky těmto sekundárním indexům pak můžeme vyhledávat i

v obsahu.

Pro účel uchování grafových dat nepřináší využití databáze typu Key-Value store

žádné výhody. Spíše naopak, realizace takového uchování dat by nebyla efektivní.

Dokumentové databáze

Jak již název tohoto NoSQL databázového systému napovídá, základním

stavebním prvkem je zde dokument. Jedná se o datovou strukturu, která v sobě nese

nejen samotný obsah, ale také náležitá metadata. Tato metadata popisují význam a

případně i vlastnosti jednotlivých částí ukládaného dokumentu. Na dokument proto

lze v zásadě nahlížet jako na množinu Key-Value párů rozšířených o možnost

ukládání i dalších metadat kromě klíče. Právě díky těmto metadatům můžeme o

takovémto dokumentu říci, že je samopopisný. Nejznámějšími takovými dokumenty

jsou například data uložená ve formátech XML3 a JSON4, proto také řada

dokumentových databází je dnes založena právě na některém z těchto formátů.

Vzhledem k tomu, že v řadě případů (zejména webové aplikace) je pro přenos dat

používáno právě XML nebo JSON, může využití těchto formátů pro ukládání dat často

ušetřit značnou část prostředků. Ty by v případě klasických relačních databází

musely být vynaloženy na nutný převod relačních dat před přenosem. (12)

Zřejmě jako první dokumentové databáze vznikaly systémy určené právě pro

uchovávání XML dokumentů. Z těchto historických důvodů jsou často takové úložiště

označovány konkrétně jako XML databáze. Zásadním rozdílem oproti dokumentovým

databázím jak je dnes chápeme je možnost (v některých případech dokonce nutnost)

přesné specifikace schématu ukládaných dokumentů a také možnost využití

pokročilých dotazovacích metod (pomocí dotazovacího jazyka xQuery5). Pro naše

potřeby je však budeme považovat za konkrétní užší typ dokumentových databází.

3 XML - Extensible Markup Language 4 JSON - JavaScript Object Notation 5 xQuery – XML Query Language. Zjednodušeně řečeno obdoba SQL jazyka určená pro dotazování nad dokumenty typu XML.

17

Dokumentové databáze již z principu těží z výše zmíněné vlastnosti

samopopisnosti. Není totiž problém v takových databázích ukládat data s různou

strukturou. Nebo například v průběhu vývoje aplikací pracujících nad danou databází

bez problému měnit schéma ukládaných dat. Přidávat nebo odebírat položky

v dokumentech. Případně i ukládat dokumenty obsahující odlišná pole ve stejné

kolekci v případě, kdy popisují shodnou entitu. Jediným povinným polem, které musí

každý dokument v dokumentové databázi obsahovat, bývá pouze identifikátor

(id dokumentu) fungující jako primární klíč u relačních databází. Jeho hodnota musí

být v dané kolekci jedinečná a navíc konstantní.

Různorodost dokumentových databázových systémů je bohužel příčinou toho, že

neexistuje jednotný způsob dotazování a modifikace dat. Téměř každý konkrétní

produkt využívá vlastní specifické API6 pro přístup k datům. To má za následek

nutnost učení se konkrétní syntaxe pro vývojáře aplikací nad různými

dokumentovými databázemi. Nutno však v tomto případě podotknout, že základní

filozofie všech těchto API zůstává velmi podobná a mění se pouze použité názvosloví

a syntaxe. Větší problém tak tato nejednotnost přináší v případě, kdy je požadován

přechod fungující aplikace na jiný databázový systém (ač stále dokumentový).

V dokumentových databázích lze použít dva přístupy pro uchování vzájemných

vazeb dokumentů. Jednak se jedná o vnořené dokumenty, kdy je jako hodnota pole

dokumentu vložen sám navázaný dokument. Tato varianta je však vhodná pouze pro

realizaci vztahů 1:1 nebo 1:N. Druhá varianta vhodná pro vztahy M:N je ukládání

odkazu na druhý dokument. Výhodou prvního přístupu (vnořené dokumenty) je

jednoduchá manipulace se všemi daty najednou (v jedné operaci, dotazu). Naproti

tomu při využití odkazů je nutné si při zpracování opětovně vyžádat dokumenty, na

něž je odkazováno. Opačná situace však panuje v případě požadavku na editaci

uložených dat. V případě vnořeného dokumentu může zaprvé nastat problém při

snaze vkládat velké množství takovýchto „pod dokumentů“. Stejně tak při změně dat,

která jsou tímto způsobem navázána na větší množství dokumentů vyšší úrovně,

musí dojít k přepsání všech takto dotčených záznamů. V případě použití odkazu

můžeme ve stejné situaci jednoduše zeditovat pouze odkazovaný dokument a tím

dojde ke změně u všech dokumentů, které se na něj odkazují, aniž bychom se jich

6 API – Application Programming Interface

18

jakkoli museli dotknout. Právě druhá možnost ukládání relací pomocí odkazů

umožňuje také poměrně efektivní uchování dat majících charakter navzájem

provázaných uzlů.

Sloupcové databáze

Tato množina NoSQL databází bývá v anglické literatuře nazývána Wide Column

Databases, což popisuje jejich podstatu ještě přesněji než český překlad „sloupcové

databáze“. Za předchůdce všech sloupcových databází je považován proprietární

systém firmy Google nazvaný Bigtable, který byl představen roku 2006. (15)

Základní princip těchto NoSQL databázových systémů spočívá v ukládání

datových řádků, jež obsahují hodnoty spolu s názvem daného sloupce. Spolu

s hodnotou a názvem sloupce jsou navíc často ukládána i časová razítka

zaznamenávající přesný čas uložení dané hodnoty. Jednotlivé sloupce se sdružují do

takzvaných rodin sloupců. Ty by měly uchovávat sloupce s tematicky blízkými

hodnotami. Každý řádek navíc obsahuje identifikátor. Pomocí tohoto identifikátoru

pak jsou sdružovány řádky v jednotlivých rodinách sloupců popisující shodnou entitu.

Podstatný je fakt, že jednotlivé řádky mohou v jedné rodině sloupců obsahovat i

sloupce s různými názvy. (12)

V tomto modelu lze pozorovat podobnost s dokumentem v pojetí dokumentových

databází (případně s formátem JSON). Názvy sloupců jsou zde analogií k polím

v dokumentu. Rozdíl je však v tom, že v případě sloupcových databází je přesněji

definováno schéma ukládaných dat již při vytváření dané databáze. Konkrétně je zde

nutné definovat právě výše zmíněné rodiny sloupců. Takto nadefinované rodiny pak

mohou obsahovat různé počty sloupců s různými názvy.

Na data ve sloupcových databázích je často z pohledu přístupu nahlíženo jako na

multidimenzionální asociativní pole. Jednotlivými dimenzemi zde jsou: id řádku,

název sloupce a časové razítko. Právě pomocí těchto základních identifikátorů je pak

možné čtení dat. Názorně lze tuto strukturu vyjádřit například ve formě dokumentu

JSON (viz kód 3.2 na následující straně).

19

Kód 3.2: Struktura odpovídající záznamu v dokumentové databázi, zdroj: (12) upraveno autorem

Také do sloupcové databáze by v případě potřeby bylo možné uložit grafová data.

Ovšem stejně jako například u databází relačních by průchod grafem byl značně

neefektivní operací.

Grafové databáze

Tento typ databázových systémů se značně liší od všech výše popsaných a je

uzpůsoben pro uchovávání informací o objektech reálného světa v podobě uzlů a

jejich vzájemných vazeb. Navíc jsou data uložena tak, aby bylo vždy možné efektivně

získat informaci nejen o daném uzlu, ale také o jeho vazbách na další uzly (sousedy).

Tato vlastnost je základním rysem každé grafové databáze a bývá nazývána jako

bezindexová sousednost (anglicky index-free adjacency). Z tohoto pojmu je patrné, že

díky možnosti uložení informací o sousedech přímo v rámci každého vrcholu, není

nutné pro průchod grafem využívat prohledávání pomocí indexů. To má za důsledek,

že i se zvyšujícím se počtem uzlů zůstává cena lokálního kroku stejná, což například

v relačních databázích neplatí. Samozřejmě i v grafových databázích jsou využívány

indexy. Ne však pro průchod grafem, ale pro umožnění efektivního vyhledávání na

základě hodnot atributů. (14)

Právě při práci využívající linkových analýz, SNA nebo jakýchkoliv principů

z obecné teorie grafů se oproti klasickým relačním databázím případně i jiným NoSQL

databázím jeví jako vhodnější využití těchto grafových databázových systémů. V nich

20

jsou data nativně ukládána ve formě grafu obsahujícího jednotlivé entity spolu

s informacemi o jejich vazbách (viz obrázek 3.8). Kromě těchto základních informací

o vlastní struktuře grafu je samozřejmě v grafové databázi ke všem uzlům i vazbám

možné ukládat také řadu různých atributů, pomocí nichž jsou v grafové databázi

uchovávány další známé informace popisující daný objekt reálného světa. Tyto

atributy umožňují rozšíření možností práce nad takovýmto grafem tím, že umožňují

např. vyhledávání či řazení.

Obrázek 3.8: Příklad základní struktury dat uložených v grafové databázi, zdroj: (12)

21

4 Teorie grafů a teorie sítí

V této kapitole se stručně seznámíme s podstatnými základy teorie grafů, které

jsou nezbytnou součástí oboru analýzy sociálních sítí i linkových analýz. Po

teoretickém představení základních pojmů a principů se zaměříme zejména na

praktickou stránku použití nabytých znalostí. Vzhledem k tomu, že teorie grafů je

velmi dobře zdokumentovaný obor a je jednoduše k dostání řada materiálů různé

úrovně podrobnosti a náročnosti, není již třeba sepisovat další z takovýchto popisů.

Případné zájemce o hlubší prostudování teorie grafů lze odkázat na některý z řady

dostupných zdrojů, například (16) (9) (17).

Teorie grafů je jednou z poměrně specifických matematických disciplín, jejíž

historie zdaleka nesahá tak daleko do minulosti jako v dalších matematických

oborech. Za zakladatele celého oboru teorie grafů je dnes obecně považován Leonard

Euler, který v roce 1736 řešil známý problém sedmi mostů ve městě Královci

(Königsbergu, dnes Kaliningradu) (18) (19).

Základní strukturou, se kterou se v teorii grafů pracuje, je právě graf skládající se

z množiny bodů (vrcholů), které jsou vzájemně provázány hranami. Tato základní

struktura grafu byla již popsána v předešlých kapitolách. Z matematického hlediska

může být každý graf popsán jako uspořádaná dvojice množiny vrcholů V a množiny

hran E.

G = (V, E)

Množina vrcholů takovéhoto grafu G se poté značí V(G) a množina hran E(G).

Takovýto matematický aparát je vhodný k popisu všech reálných systémů, které lze

znázornit konečným počtem uzlů a jejich vzájemných vazeb.

V grafu jako celku poté můžeme pracovat se základními strukturami vyšší úrovně,

kterými jsou sled, cesta a tah. Sledem rozumíme střídavou posloupnost uzlů a hran.

Musí vždy začínat a končit v uzlu. Tah je sledem, ve kterém se nesmí opakovat žádná

hrana. Cesta je naopak sledem, ve kterém se neopakuje žádný vrchol. Mezi dvěma

uzly je často možné nalézt více cest, v takovém případě se stává významnou

tzv. minimální cesta. Tou je vždy ta z cest, která má nejmenší počet hran, nebo

22

v případě ohodnoceného grafu má nejmenší součet vah7 všech hran, kterými

prochází. Někdy může být žádoucí znalost tzv. maximální cesty, u které hledáme

naopak maximum součtu vah všech hran.

Dalšími významnými pojmy z teorie grafů, které nacházejí své uplatnění v oblasti

linkových analýz, jsou komponent grafu, most a artikulace. Komponentem grafu

se nazývá maximální souvislý podgraf. Most je hrana, jejímž odstraněním se zvýší

počet komponent uvažovaného grafu. Artikulace je obdobou mostu, jen jde o uzel. Po

jeho odstranění (i se všemi jeho hranami) se taktéž zvýší počet komponent grafu.

Zjednodušeně řečeno je graf odstraněním mostu nebo artikulace rozdělen na více

souvislých podgrafů.

Grafy je možné reprezentovat různými způsoby. Buď lze použít zápis množinový

nebo zápis maticový (matice sousednosti, matice ohodnocení hran či incidenční

matice). Další možností je pak znázornění pomocí diagramu. Právě v případě

grafického znázornění pomocí diagramu lze plně využít základní sílu grafů a to jejich

přehlednost a možnost zaměřit se na topologii sledované množiny objektů

popisujících nějaký reálný stav či problém (20). Výše vyjmenované maticové zápisy

mohou být naopak vhodnější pro realizaci některých grafových algoritmů.

Teorie grafů je velmi rozsáhlou matematickou disciplínou a při jejím hlubším

zkoumání by zde bylo nutné obsáhlé rozebrání řady dalších pojmů, typů grafů a

principů. Pro námi zkoumaný obor linkových analýz je důležitá pouze část z těchto

teoretických základů, přičemž jsme se jimi již zabývali v předchozích kapitolách. Nyní

se tedy již budeme věnovat konkrétním typům a parametrům grafů a vybraným

grafovým algoritmům. Zaměříme se pouze na ty, které se jeví jako využitelné při práci

využívající linkových analýz případně analýz sociálních sítí.

Teorie grafů samotná pracuje s abstraktními grafy, které nemají přímou vazbu na

reálné objekty. Existuje však oblast teorie grafů využívající kromě základní struktury

grafu skládajícího se z uzlů a hran navíc ještě jejich další přidané atributy. Jedná se o

teorii sítí. Ta ve své podstatě vychází z čisté teorie grafů, ovšem řešené problémy jsou

obohaceny o uvažování přidaných atributů jednotlivých zpracovávaných entit (21).

Za síť lze považovat v podstatě jakoukoliv grafovou strukturu, která ve své reálné

7 Váha hrany je blíže popsána v následující kapitole.

23

podstatě zajišťuje přenos nějakého média (elektřina, voda, plyn, informace,

finance, atd.) (9). Dá se tedy říci, že teorie sítí je použitím principů teorie grafů v praxi

na systémech reálného světa modelovaných právě grafovou strukturou. Právě teorie

sítí představuje samotnou podstatu linkových analýz a samozřejmě, jak samotný

název napovídá, i analýzy sociálních sítí.

4.1 Základní parametry grafů a jejich prvků V čisté teorii grafů lze pracovat pouze s několika základními měřítky týkajícími se

jednotlivých uzlů a hran. Základním parametrem každého vrcholu je jeho stupeň.

Ten udává počet hran, které s daným vrcholem incidují (začínají či končí v daném

vrcholu). Stupeň vrcholu můžeme v orientovaných grafech ještě rozdělit na vstupní a

výstupní stupeň daného vrcholu8. Obdobně důležitým parametrem hrany je její

váha9. Ta při použití grafového modelu reprezentujícího nějaký reálný problém

nejčastěji představuje vzdálenost (délku hrany), časovou náročnost, či množství

nějakého média přenášeného ve směru hrany. Obdobně lze reprezentovat i váhu uzlů.

Při pohledu na graf jako celek lze zjišťovat ještě další parametry týkající se jeho

topologie. Nejčastěji se jedná o vzdálenost vrcholů. Ta udává délku nejkratší možné

cesty mezi těmito vrcholy. V případě ohodnoceného grafu se jedná o součet vah všech

hran, kterými tato nejkratší cesta prochází. V případě neohodnoceného grafu jde

pouze o počet kroků nalezené nejkratší cesty.

Kromě těchto elementárních atributů vycházejících přímo ze základní teorie grafů

můžeme v grafu sledovat také řadu dalších pokročilejších příznaků popisujících určité

vlastnosti celého grafu či konkrétních uzlů či hran. Tyto parametry většinou vycházejí

právě z teorie sítí (či konkrétně z SNA). Často používanými atributy jednotlivých uzlů

jsou míry centrality (8). Ty v zásadě popisují význam daného uzlu v celé síti.

Rozlišujeme výše popsanou centralitu měřenou stupněm uzlu (degree centrality),

centralitu měřenou blízkostí polohy ke středu (closeness centrality) a centralitu

měřenou středovou mezipolohou (betweenness centrality).10 Další množinou

parametrů uzlů sítě jsou tzv. ranky. Ty popisují významnost daného uzlu z různých

8 Stupeň vrcholu anglicky Degree. V orientovaném grafu se skládá z Indegree a Outdegree. 9 Váha hrany se uvažuje pouze u ohodnocených grafů. 10 Počeštěné názvy centralit se v odborné literatuře téměř nepoužívají.

24

pohledů. Nejznámějším je tzv. PageRank využívaný v oboru hodnocení významnosti

webových stránek (22). V případě měřítka popisujícího graf jako celek je nejčastěji

počítána tzv. hustota grafu.

Density (česky hustota) je bezrozměrné číslo na škále od 0 do 1 vyjadřující poměr

skutečného počtu hran v grafu k maximálnímu možnému počtu hran v uvažovaném

grafu (2).

Betweenness (česky zkráceně mezilehlost) vyjadřuje počet nejkratších cest mezi

všemi dvojicemi uzlů v celém grafu procházejících popisovaným uzlem.

Closeness (česky se překládá jako blízkost či dosažitelnost) je dána součtem

všech nejkratších cest z daného uzlu do všech ostatních uzlů sítě.

Eigenvector (vlastní vektor) je centralitou, která neuvažuje pouze vazby daného

uzlu, ale je počítána také z centralit uzlů okolních.

Obrázek 4.1: Jednotlivé metriky uzlů grafu vypočítané pomocí aplikace IBM i2 Analyst’s Notebook, zdroj: autor

25

4.2 Problémy řešené pomocí teorie grafů a sítí V teorii grafů se můžeme setkat s řadou problémů, z nichž některé mají i několik

známých algoritmů řešení. Dále si stručně uvedeme některé z těchto problémů

případně i s vybranými algoritmy vhodnými k jejich řešení. Jednotlivé algoritmy jsou

opět podrobně popsány v celé řadě hojně dostupných publikací (10) (18) (9) (17).

Prohledávání grafu je základním úkonem prováděným nad grafem, který nachází

své uplatnění v řadě dalších algoritmů. Někdy bývá použito názvů procházení grafu

nebo také traverzování, ve všech případech se jedná o stejný proces. Rozlišujeme

prohledávání do hloubky11 a do šířky12, které se liší pouze strategií při rozhodování o

dalším kroku. Společným rysem je princip, že začínáme prohledávat od zvoleného

uzlu a pokračujeme přes jednotlivé hrany tak dlouho, dokud neprojdeme všechny

ostatní dosažitelné uzly (23) (24).

Hledání nejkratší cesty je velmi často řešeným problémem teorie grafů, čemuž

odpovídá i to, že je známo několik algoritmů jeho řešení. V zásadě jde o to, ze všech

možných cest mezi dvěma uzly nalézt tu s nejmenším součtem vah všech projitých

hran. Mezi známé algoritmy pro hledání nejkratší cesty patří Dijkstrův algoritmus,

Bellman-Fordův algoritmus, či Floyd-Warshallův algoritmus a řada dalších (17).

Hledání minimální (maximální) kostry grafu řeší problém jak pospojovat

všechny uzly grafu s co nejnižším (nejvyšším) součtem vah použitých hran. Problém

hledání minimální kostry grafu řeší například Borůvkův, Jarník-Primův nebo

Kruskalův algoritmus. Dále také Chu-Liu-Edmondsův algoritmus, který však na rozdíl

od všech výše vyjmenovaných řeší hledání kostry grafu orientovaného (17).

Barvení grafu bývá popisováno na příkladu obarvení mapy států tak, aby žádné

dva sousední státy neměly shodnou barvu. Obecně je v této úloze řešen problém jak

přiřadit uzlům kategorii takovou, aby žádný z jeho sousedních uzlů neměl přiřazenu

kategorii shodnou (17) (20).

Toky sítí se řeší u orientovaných grafů, ve kterých je určen zdroj a tzv. stok (cíl,

spotřebič) a váhy hran představují jejich kapacitu. V takové síti poté můžeme hledat

maximální možný tok plynoucí ze zdroje do stoku (9).

11 Prohledávání do hloubky - anglicky depth-first search (DFS) 12 Prohledávání do šířky – anglicky breadth-first search (BFS)

26

Hledání komponent grafu je v principu velmi jednoduchý problém. Jeho řešením

je použití algoritmu pro prohledávání grafu (např. DFS). Algoritmus zahájíme

z vybraného uzlu a při prohledávání grafu označujeme všechny uzly, kterými jsme

prošli. Pokračujeme do té doby, dokud máme kam postoupit. Takto najdeme celou

komponentu, do které daný uzel náleží. Pokud hledáme všechny komponenty grafu,

pokračujeme stejným postupem z některého z doposud neoznačených uzlů.

Isomorfismus grafů řeší určení totožnosti dvou grafů i v případě, že jsou jejich

uzly různě pojmenovány a rozmístěny. Jinak řečeno jsou dva grafy izomorfní, pokud

lze pouhým přemístěním a přejmenováním uzlů dosáhnout shodného grafu.

Obrázek 4.2: Příklad izomorfních grafů, zdroj (25)

4.3 Využití teorie grafů a grafových algoritmů v praxi linkových

analýz V práci využívající linkových analýz lze s výhodou využít přímo hodnoty výše

popsaných centralit uzlů. V různých případech je možné podle konkrétních podmínek

volit různé druhy centrality. Pomocí centrality pak můžeme i ve velmi rozsáhlé a

nepřehledné síti poměrně jednoduše určit potencionálně zajímavé uzly z pohledu

jejich významu v této síti. Tak například díky mezilehlosti lze vyhledat ty uzly, které

mohou mít kontrolu nad podstatnou částí toku v síti. Z opačného pohledu mohou být

takto nalezena citlivá místa sítě, jejichž vyřazení bude mít na síť největší dopad. Dále

je možné pomocí dosažitelnosti (closeness centrality) ve výsledku hledat uzly, které

mají nejlepší přístup do ostatních částí celé sítě. Posledně jmenovaný vlastní vektor

(eigenvector) dokáže poukázat na subjekty, které mohou mít v síti silný vliv

27

v důsledku přímých vazeb na další velmi aktivní uzly. To může být často velmi

zajímavý poznatek, který běžně není na první pohled patrný.

Pokud máme soubor dat tvořících síť navzájem provázaných uzlů a víme, že se

v těchto datech nacházejí i údaje o několika pro nás zajímavých entitách, bude nás

v dalším kroku pravděpodobně také zajímat, zda existuje mezi těmito zájmovými

entitami cesta. Pokud ano, může svůj význam mít kromě délky nejkratší cesty i

celkový počet všech dalších cest tyto uzly spojujících. V nejjednodušším případě

hledáme cestu pouze mezi dvěma uzly, ovšem stejně tak můžeme požadovat i

nalezení cest mezi více než dvěma uzly. Většinou budeme hledat cestu tvořenou

pouze konkrétními typy vazeb, se zohledněním směrů těchto vazeb a také nás budou

zajímat pouze cesty do určité délky.

Také hledání komponent grafu je v praxi velmi přínosné. Lze pomocí něj celou síť

rozdělit na jednotlivé celky, kterým se poté můžeme věnovat samostatně a

podrobněji. Toho lze s výhodou využít také pro prvotní filtrování dat.

Například pokud nás zajímá organizovaná skupina osob, přičemž máme v našem

grafu jeden uzel reprezentující některého člena této pro nás doposud neznámě

skupiny, bude nejefektivnější podrobně se zaměřit na komponent grafu, který

získáme okolo tohoto známého uzlu. V takovém případě však bývá nutné pro nalezení

komponentu grafu omezit množinu uvažovaných vazeb. Můžeme například uvažovat

pouze vazby určitého typu, pouze vazby od určité intenzity (četnosti) nebo jen vazby

s daným maximálním stářím. Právě stáří vazeb bývá často prvním uvažovaným

kritériem.

Nakonec jednou z pokročilých technik linkových analýz je vyhledávání v grafu

pomocí vzorů13. Cílem je zjistit, zda se v rozsáhlém grafu vyskytuje podgraf, který

bude izomorfní s grafem zadaného vzoru (5). V některých případech může být

užitečné upustit od podmínky čistého izomorfismu obou grafů a můžeme požadovat

pouze nalezení velmi podobných částí grafu. V takovém případě je však velmi důležité

určení metriky, podle které se podobnost grafů bude posuzovat.

13 Často se využívá anglický název této techniky Pattern Matching.

28

4.4 Další oblasti použití grafových dat Teorie grafů (potažmo teorie sítí) zdaleka nenachází své uplatnění pouze ve zde

zkoumaném oboru. Naopak rozsah jejich využitelnosti je značně různorodý. Můžeme

se tak setkat s řešením problémů pomocí některého z grafových algoritmů třeba

v oblasti počítačových sítí, energetiky, elektroniky, biologie, ekonomie, logistiky,

navigace, genetiky, chemie, medicíny a epidemiologie či ve strojovém zpracování

přirozeného jazyka14.

Obecně jsou pravděpodobně nejpoužívanějšími problémy z teorie grafů

procházení grafem a hledání (nejkratších) cest mezi zvolenými uzly. Těchto principů

hojně využívají mimo jiné i navigační systémy. Jednotlivé uzly reprezentují města,

křižovatky, případně další potenciálně cílová místa (POI15). Hrany poté reprezentují

silniční síť a bývají pro tyto potřeby ohodnoceny buď vzdáleností (délkou cesty),

nebo časovou náročností (standardní čas potřebný pro překonání daného úseku

trasy). Pomocí algoritmu pro nalezení nejkratší cesty poté navigační systém uživateli

doporučí sled silničních úseků a průjezdních bodů na trase. Obdobně fungují i

vyhledávače spojení hromadnými dopravními prostředky (26). Ty však musí navíc

obsahovat a vyhodnocovat časová data z jízdních řádů. Pomocí nich poté řeší

návaznost v jednotlivých přestupních místech (uzlech grafu).

Hojně využíván je také problém toků v síti. Tento princip je využíván také

v dopravě, dále však i v energetice, v oblasti počítačových sítí a v řadě dalších oborů.

Modelem orientovaného grafu je zde reprezentována síť, kterou prochází médium

(elektřina, plyn, silniční vozidla, apod.). Váha jednotlivých hran pak může

představovat omezení maximálního průchodnosti daného úseku. Na takto

připraveném modelu lze řešit například ovlivnění celé sítě v případě výpadku některé

její části, nebo třeba hledat slabá místa v síti omezující celkovou její průchodnost

(tzv. bottlenecks).

Jako další využitelný problém z teorie sítí je možné uvést třeba barvení grafu,

které lze v různých formách využít například při návrhu frekvenčního plánu pokrytí

území rádiovými vysílači. Vysílače reprezentují uzly grafu a sousedící vysílače jsou

14 NLP – Natural Language Processing 15 POI – Point Of Interest

29

vždy propojeny vazbou. Barvami jsou v tomto případě myšleny frekvence

jednotlivých vysílačů, které se nesmí u blízkých vysílačů shodovat.

30

5 Návrh systému pro linkové analýzy nad grafovou

databází

Praktická část této diplomové práce se zabývá návrhem a realizací systému

určeného pro provádění linkových analýz nad daty ukládanými v grafové databázi.

Účelem není vytvořit plnohodnotný SW pro linkové analýzy, který by byl

alternativou na trhu dostupných nástrojů. Cílem bylo pouze vytvořit funkční

prototyp, na kterém bude ověřena funkčnost a tím i vhodnost vybraných technologií.

Zároveň by měl posloužit jako základ pro případný další vývoj komplexního

analytického prostředí. Tento systém by měl být vytvořen s ohledem na to, aby

umožňoval vyhnout se překážkám a nevýhodám dostupných stejně zaměřených

nástrojů, se kterými se v praxi setkáváme. Nejprve budou rozebrány základní

požadavky na vytvářený systém, stejně jako několik dostupných aplikací

umožňujících provádění linkových analýz. Na základě takto nadefinovaných

požadavků budou poté zvoleny vhodné nástroje, které budou využity pro realizaci

prototypu.

5.1 Požadavky na navrhovaný systém Jak již bylo uvedeno v předešlém textu, je rozsah oblastí ve kterých je možné

uplatnit přístupy práce využívající linkové analýzy relativně široký. Obsah této

diplomové práce je proto blíže zaměřen zejména na využití takovýchto analytických

postupů v oblasti bezpečnosti. Může se jednat jak o bezpečnostní složky státu

(policejní či zpravodajské), o zajištění bezpečnosti například v bankovním sektoru či

pojišťovnictví, případně i o oblast kybernetické bezpečnosti. Obdobný styl práce

může v některých případech vykazovat také investigativní žurnalistika. Zásadně se ve

všech těchto odvětvích liší pouze dostupné zdroje dat, ta jsou pak již zpracovávána

obdobnými způsoby a nástroji.

Vytvářený systém pro linkové analýzy by měl umožňovat zpracování i velmi

rozsáhlých datových souborů. Navíc i za předpokladu, že bude docházet k neustálému

přírůstkovému vkládání nových dat. Vzhledem k tomu, že není možné předem

striktně definovat, jakých objemů budou zpracovávaná data nabývat (navíc se tento

požadavek může diametrálně lišit v jednotlivých případech nasazení), je nutné zajistit

31

možnost dodatečného navýšení kapacity provozovaného úložiště. A to vždy

s podmínkou zachování již uložených dat.

Kromě zpracování centrálně uložených dat musí prostředí umožnit každému

uživateli import vlastních dat pro tvorbu analýzy. Takto vkládaná data by mělo být

možné použít jak pro jednoúčelové zpracování, tak i pro dlouhodobé zapsání do již

provozovaných datových souborů (databází). Lze předpokládat, že touto cestou

vkládaná data (myšleno koncovým uživatelem) budou vždy dosahovat citelně

menších objemů než data dlouhodobě ukládaná (například správcem systému).

Vzhledem k tomu, že je často nutné, aby na daném problému (případu)

spolupracoval tým lidí, musí tuto spolupráci podporovat i použité analytické

prostředí. Základní požadavek práce nad stejnými daty je v zásadě splněn už použitím

centrální databáze. Centrální úložiště taktéž zajistí dostupnost dat vložených jedním

uživatelem i pro ostatní členy týmu. V praxi je samozřejmě takovýto společný přístup

k datům nutno zabezpečit na požadované úrovni pomocí autentizace a autorizace

uživatele. Zabezpečení takovéhoto informačního systému je značně rozsáhlou

otázkou a bylo by spíše tématem pro práci obdobného rozsahu. Pro potřeby

vytvářené vzorové aplikace nebudou proto otázky zabezpečení přístupu k datům

uvažovány. V úvahu bude brán pouze požadavek na nutnost jednoduché dodatečné

implementace bezpečnostních algoritmů v případě reálného nasazení.

Jednu ze základních funkcí vytvářeného konceptu analytického prostředí lze

spatřovat ve zjednodušení a zrychlení práce koncovému uživateli (analytikovi). Toho

lze často dosáhnout pouze za využití komplikovaných algoritmů a technik. Konkrétně

v oblasti linkových analýz se bude jednat zejména o algoritmy vycházející z teorie

grafů. Případně i některých dalších nástrojů z oboru statistiky či informatiky. V praxi

právě zde často narazíme na nemožnost využití těchto složitých principů v důsledku

naprosto odlišného vzdělání a zaměření analytika. Jak již bylo zmíněno v úvodu této

práce, ke kvalitní analytické práci je mimo jiného potřeba zejména dostatečná znalost

oboru zpracovávaných dat. Právě tato nutnost je většinou v opozici k požadavku na

znalost pokročilých matematických či statistických technik. Nelze například

předpokládat, že i zkušený kriminalista, který pracuje na odhalování určité formy

trestné činnosti, bude schopen psaní dotazů v dotazovacím jazyce SQL (nebo jiném),

či dokonce implementace algoritmu například pro výpočet mezilehlosti všech uzlů

32

zpracovávaného grafu. Přitom právě pomocí takovýchto nástrojů lze plně využít

výhody celého konceptu zpracování grafových dat a linkových analýz. V takovém

případě je právě dobře vytvořené analytické prostředí tím vhodným článkem

zprostředkovávajícím tyto specifické (a často velmi náročné) techniky širokému

okruhu koncových uživatelů. Je proto zřejmé, že podmínkou úspěšného analytického

prostředí je mimo jiné právě jeho uživatelská přívětivost a přehlednost. Navíc musí

umožňovat interaktivní práci s vizualizovanými daty, nikoli pouze pasivní přijímání

předkládaných údajů.

Další požadavek částečně vyplývá z faktů popsaných v předešlém odstavci. Jedná

se o potřebu vytvoření systému modulárního natolik, aby umožňoval co

nejjednodušší rozšiřitelnost o další podpůrné prvky, algoritmy, přístupy

k vyhledávání a organizaci či samotné výsledné vizualizaci zpracovávaných dat. Tento

požadavek vyplývá zejména z rychle se měnících okolností a z nich vyplývajících

potřeb při analytické práci. A to často i v případě zpracování totožných dat. Je

naprosto běžné, že v jednotlivých případech je zapotřebí využít značně odlišných

technik například k vyhledání a následnému vyhodnocení relevantních poznatků.

Ideální se tak jeví struktura organizace, kde jsou analytici při své práci nepřetržitě

podporováni informatiky právě cestou vývoje a úprav používaných nástrojů podle

aktuálních potřeb. To se může týkat jak například dodatečného importu dat doposud

neobsažených v databázi, tak i kompletního vývoje nového filtru či nové grafické

reprezentace lépe vystihující právě řešenou problematiku.

5.2 Přehled existujících nástrojů použitelných pro linkové analýzy Pro provádění linkových analýz je dostupných několik softwarových nástrojů a to

ve značném rozsahu funkčnosti ale také ceny. Podstatně širší výběr je mezi nástroji

určenými pro analýzy sociálních sítí. Navíc se portfolio softwarových nástrojů

určených pro SNA, zřejmě díky stále narůstající oblibě této techniky v různých

oborech, neustále rozšiřuje. Jak bylo uvedeno v úvodních kapitolách této práce,

je značná část využívaných principů při linkových analýzách a SNA stejná. I proto by

bylo možné v některých případech využít pro linkovou analýzu nástrojů původně

určených pro SNA. Není cílem tvořit zde kompletní přehled všech dostupných

33

produktů. Vzhledem k jejich množství ani není možné je spravedlivě vzájemně

srovnávat, k čemuž by navíc bylo naprosto nezbytné i jejich praktické testování.

IBM i2 Analyst´s Notebook

Jedná se o dlouhodobě vyvíjený profesionální analytický produkt určený přímo

na provádění linkových analýz. Zejména v kruzích policejní a zpravodajské analýzy se

stal Analyst´s Notebook16 jakýmsi standardem pro zpracování a sdílení informací

majících charakter síťového diagramu. Mimoto je hojně využíván například

v bankovním nebo pojišťovacím sektoru. Mezi jeho přednosti patří zejména

propracovanost uživatelského rozhraní, rozsáhlá sada ikon pro znázornění

všemožných entit či událostí, řada možností vizualizace diagramů („layoutů“) u

některých i s možností podrobné volby jejich parametrů (viz obrázek 5.1). A

v neposlední řadě také podpora jednoduchého provedení výpočtů řady SNA

parametrů a metrik. Jedná se však o značně nákladné řešení, které navíc ve své

základní verzi umožňuje pouze lokální práci nad jednotlivými diagramy. Přičemž

takováto forma práce je naprosto nevhodná pro zpracování velkých objemů dat.

V případě potřeby týmové spolupráce nad velkými datovými soubory je nutné využít

ANB spolu s dalším produktem IBM i2 iBase. Analyst´s Notebook pak slouží jako

klient umožňující analyzovat data ukládaná v úložišti iBase. Právě tato kombinace se

poté blíží v předešlé kapitole nadefinovaným požadavkům a vytvářenému

analytickému prostředí. Na jeho pozadí však nenajdeme grafovou databázi nýbrž

klasický relační model ukládání dat. Konkrétně je možné použít Microsoft Access

nebo Microsoft SQL Server. V obou případech je však nutné mít zakoupenu zvlášť

licenci k databázovému systému, který není součástí iBase. Je tak téměř jisté, že

takovýto systém je dostačující pro ukládání dat, jejich následné načtení a vizualizaci.

Ovšem například využití grafových algoritmů zde bude o poznání méně efektivní než

nad grafovou databází. V případě využití kombinace Analyst’s Notebooku spolu

s iBase je nutné vyhledat a zobrazit požadovaná data, a až poté nad takto načtenými

daty lze lokálně v prostředí Analyst´s Notebooku prováděny požadované výpočty a

analýzy. Tento přístup však znemožňuje aplikaci náročnějších postupů na kompletní

16 Pro název IBM i2 Analyst’s Notebook se často používá zkratka ANB.

34

uložená data. Zejména zmíněná absence grafové databáze je tak důvodem proč by ani

kombinace iBase a Analyst´s Notebook pro potřeby této práce nabyla zcela vyhovující.

Obrázek 5.1: Uživatelské rozhraní IBM i2 Analyst’s Notebook, zdroj: autor

OrientDB Studio

OrientDB Studio je standardní součástí distribuce všech verzí grafové databáze

OrientDB. Jedná se o webové rozhraní umožňující základní přístup k datům uloženým

v databázi OrientDB. V tomto prostředí je možné i zobrazení výsledků dotazů

ve formě vizualizace vyhledaných uzlů a jejich vazeb (viz obrázek 5.2). Částečně by

tak toto prostředí mohlo plnit funkce potřebné pro linkové analýzy. Pro praktickou

činnost analytika je však toto prostředí zcela nevhodné zejména z důvodu nutnosti

znalosti dotazovacího jazyka Extended SQL, ve kterém je nutné psát dotazy pro

získávání požadovaných dat. Navíc není určeno přímo pro analytickou práci se všemi

jejími aspekty jako například prezentace dosažených výsledků či týmová spolupráce

více uživatelů.

Z tohoto důvodu je OrientDB Studio vhodné zejména pro testovací a ladící účely

tvůrce dalších aplikací přistupujících ke grafové databázi OrientDB. Za tímto účelem

bylo také vyvíjeno. Kromě přístupu k uloženým datům umožňuje OrientDB Studio

také správu modelu jednotlivých databází (tvorba tříd a definice jejich atributů).

35

Navíc je zde možné psát vnitřní funkce ukládané na samotném databázovém serveru

OrientDB, které poté lze využít například pro zjednodušení dotazování z externích

aplikací.

Obrázek 5.2: Webové prostředí OrientDB Studio, zdroj: autor

Obdobné nástroje jsou dostupné pro řadu dalších grafových databází. Filozofie i

zpracování všech těchto nástrojů jsou většinou velmi podobné. Například

pro databázi Neo4J je dostupné obdobné webové prostředí (Neo4J Browser) i

desktopová aplikace (Neoclipse).

Gephi

Gephi17 je open-source projekt zaměřený na analýzu a vizualizaci grafových dat.

Jedná se o velmi propracovaný desktopový SW s nepřeberným množstvím funkcí.

Zejména je zaměřen na výpočty různých metrik SNA a na následnou tvorbu

vizualizací (viz obrázek 5.3). Množství dostupných nastavení jednotlivých parametrů

grafových algoritmů i vizualizačních layoutů je velmi rozsáhlé. Gephi je proto

použitelný pro tvorbu velmi bohatých vizualizací. Jeho základní funkcionalita je

snadno přístupná i uživatelům bez hlubších znalostí. Ovšem pro jeho efektivní

17 URL – gephi.org

36

pokročilé využití je již nutné mít značné znalosti z oboru teorie grafů a statistiky, což

neodpovídá požadavku na produkt pro analytiky bez této odbornosti. Navíc je zde

také omezení pouze na práci nad momentálně naimportovanými daty a to pouze

lokálně, nejedná se tedy o platformu pro společnou práci nad grafovou databází. I

když Gephi umožňuje načítání dat z mnoha různých zdrojů, grafové databáze

nevyjímaje. Výše popsané vlastnosti předurčují Gephi spíše než pro práci

informačního analytika pro využití na akademické či vědecké úrovni, případně

v novinářské práci pro tvorbu názorných vizualizací.

Obrázek 5.3: Uživatelské rozhraní aplikace Gephi, zdroj: gephi.org

Podobných aplikací určených pro vizualizaci grafových dat, případně pro výpočty

různých metrik SNA lze i v množině volně dostupných nástrojů nalézt celou řadu.

Některé z nich jsou striktně zaměřeny na tvorbu vizualizací, jiné se naopak více

zaměřují právě na provádění grafových algoritmů a na statistické hodnocení

zpracovávaných sítí, případně navíc cílí na konkrétní oblast využití grafových dat a

algoritmů (např. NLP, biologické či chemické sítě, sociální sítě, atd.…). Z těch,

které nejsou takto cíleny a jsou obecně zaměřeny na vizualizaci a práci s grafy,

37

jmenujme například Tulip18, Cytoscape19, NodeXL20, Neoclipse21, Graphviz22,

UCINET23, Pajek24 a řada dalších. Podle veřejně dostupných informací o těchto

nástrojích, žádný z nich zcela neodpovídá požadavkům na analytické prostředí, které

je cílem této práce.

Tovek Tools (Vizualizace)

V případě nástroje Tovek Tools se nejedná přímo o produkt určený k práci

s grafovými daty, avšak v jeho aktuální verzi je implementována možnost vizualizace

informací v podobě síťového grafu. Původně je celý systém Tovek zaměřen na

zpracování nestrukturovaných textových dat. Až díky modulu „Vizualizace“ je možné

ho využít i k analytické práci podobné naším požadavkům (viz obrázek 5.4).

Obrázek 5.4: Prostředí Tovek Tools při použití modulu Vizualizace, zdroj: www.tovek.cz

18 URL - http://tulip.labri.fr/TulipDrupal/ 19 URL - http://www.cytoscape.org/ 20 URL - https://nodexl.codeplex.com/ 21 URL - https://github.com/neo4j-contrib/neoclipse/wiki 22 URL - http://www.graphviz.org/ 23 URL - https://sites.google.com/site/ucinetsoftware/home 24 URL - http://mrvar.fdv.uni-lj.si/pajek/

38

Tovek Tools jsou schopné pracovat jak lokálně nad daty importovanými

uživatelem, tak i nad daty uloženými na serveru (Tovek Server). Právě ve spojení s

tímto serverem umožňují širokou nabídku funkcí podporujících týmovou spolupráci.

Značně se tak blíží námi tvořenému systému. Jediným rozdílem tak zde je, že pro

ukládání dat není využívána přímo grafová databáze. Z důvodu původního zaměření

na práci nad textovými daty je zde využíváno fulltextové jádro Lucene, přičemž pro

účely Vizualizace jsou indexy upraveny tak, aby umožňovaly efektivní práci nad daty

požadovaného grafového formátu.

Při porovnání faktů uvedených v předešlé kapitole popisující požadavky na

vytvářený systém s poznatky o možnostech jednotlivých aplikací, lze dojít k závěru, že

většina dostupných systému se od požadovaného konceptu více či méně liší. Zřejmě

nejblíže záměru jsou komerční systémy firem IBM i2 a Tovek. V principu se jedná o

značně odlišné nástroje, ovšem v obou případech je lze použít pro linkové analýzy.

Přičemž systém Tovek je sice komplexní analytický nástroj, ovšem původně určený ke

zpracování textových dat a jeho možnosti vizualizace jsou tak spíše doplňkem. Ačkoli

už v současné verzi velice silným a použitelným. Navíc je každé vydání nové verze

doprovázeno určitým posunem ve schopnostech podporujících provádění linkových

analýz.

5.3 Volba použitých technologií Jako koncepce navrhovaného systému bylo s ohledem na výše popsané požadavky

zvoleno serverové řešení s lehkým webovým klientem pro práci uživatelů. Na straně

serveru bude kromě prostředí pro běh webového rozhraní a aplikační logiky

nasazena také grafová databáze, do které budou požadovaná data před zpracováním

ukládána. Základní struktura celého systému je spolu s výčtem konkrétních použitých

technologií zobrazena na přiloženém obrázku 5.5.

39

Obrázek 5.5: Schéma znázorňující základní stavební prvky prostředí OrientLink, zdroj: autor

Serverové řešení bylo zvoleno zejména z důvodu nutnosti zajištění spolupráce

více uživatelů. Dále je tato struktura vhodná pro nasazení na výkonném dedikovaném

hardwaru, čímž zajišťuje možnost zpracování požadovaných objemů dat. Volba

grafové databáze jako systému pro ukládání dat je v tomto případě téměř

nevyhnutelná. I když byly uvedeny i jiné možnosti ukládání a zpracování grafových

dat, je zřejmé, že právě výhody nativního ukládání dat v podobě grafu jsou pro tyto

potřeby nepřekonatelné. Již v úvodu byly navíc popsány základní principy linkových

analýz, mezi nimiž je i nutnost značné různorodosti ukládaných druhů entit a dále

také umožnění jednoduchého přidávání těchto druhů až za běhu systému. Snaha o

dosažení takových vlastností přináší v případě realizace systému linkových analýz na

relačních databázích značné komplikace. Na tomto místě přichází ke slovu právě

databáze grafové, které nemají žádný problém s absencí pevně daného schématu

ukládaných dat. Navíc bývá jejich standardní výbavou implementace řady základních

i pokročilých grafových algoritmů, které je tak možné jednoduše využít bez nutnosti

složitých výpočtů na straně klienta. Na rozdíl od výběru serverového řešení a typu

databáze nebyla volba realizace klientského uživatelského prostředí již tak

jednoznačná. Existuje celá řada přístupů, či aplikačních frameworků vhodných pro

vývoj aplikací požadovaného analytického prostředí. Může se jednat o variantu

tlustého klienta ve formě desktopové aplikace nebo tenkého webového klienta.

40

Nakonec volba padla na druhou možnost a uživatelské prostředí bylo realizováno ve

formě webového klienta. Tato varianta byla zvolena zejména z důvodu rychlého

vývoje a snadného nasazení. Navíc umožňuje velmi jednoduše zavádět do celého

systému opravy, změny a nové funkce. Není vůbec nutné v takovém případě řešit

jakékoli upgrady či přeinstalace SW na klientských stanicích, stačí pouze požadované

změny nasadit na webový server a všichni uživatelé od té chvíle používají aktuální

verzi. Stejně tak jednoduchá může být i personalizace uživatelského prostředí na

základě přihlášení uživatele. Není například problém mít více skupin uživatelů

(administrátor, power-user25, user) s různými požadavky na funkcionalitu a

přístupová oprávnění. Když se pak daný uživatel přihlásí do webového prostředí

z kteréhokoliv počítače v síti, okamžitě má přístup ke všem funkcím, na které je

zvyklý.

V této kapitole budou o něco podrobněji probrány jednotlivé technologie a

frameworky zvolené pro realizaci ukázkové webové aplikace OrientLink. Zaměřena

bude především na popis základních principů a výhod zvolených technologií. Jejich

podrobný popis by značně přesahoval rozsah této diplomové práce, proto v případě

zájmu o podrobnější informace bude čtenář vždy odkázán na další zdroje vhodné

k prostudování.

Popsány zde budou pouze stěžejní technologické bloky celé aplikace (tedy Spring

Framework, databáze OrientDB, technologie AJAX a vizualizační knihovna D3.js). To

však zdaleka neznamená, že jsou to jediné technologie, které je nutné pro realizaci

obdobné aplikace ovládat. Kromě těchto prvků je v průběhu vývoje používána řada

dalších více či méně sofistikovaných nástrojů.

Jedná se zejména o verzovací nástroj Git26, který byl používán ve spolupráci

s webovou službou Bitbucket27. Tato kombinace umožňuje jednoduchou správu verzí

zdrojového kódu. Tyto nástroje značně pomůžou zejména v případě takzvaných

„slepých uliček“, na které člověk při vývoji složitější aplikace téměř vždy narazí.

V případě využití verzovacího systému poté není žádný problém bez většího úsilí se

25 Pojmem power-user bývá běžně označován uživatel informačního systému, který je schopný vykonávat náročnější úlohy než běžný uživatel. Od toho se také odvíjí fakt, že má zpravidla o poznání vyšší přístupová práva než běžný uživatel, ne však tak vysoká jako administrátor. 26 URL - https://git-scm.com/ 27 URL - https://bitbucket.org/

41

navrátit zpět k fungujícímu stavu a vydat se jinou cestou. Navíc pokud by na aplikaci

pracoval tým vývojářů, byly by možnosti těchto nástrojů využívány ještě o poznání

více.

Dále je ve vyvíjené aplikaci využito frameworku pro tvorbu webových stránek

Apache Tiles28. Ten umožňuje snadnější a rychlejší tvorbu jednotlivých stránek na

základě opakovaného využití předpřipravených funkčních bloků (tzv. tiles). Ty

mohou být libovolně skládány do požadované výsledné podoby.

Pro řešení závislostí byl využíván systém Maven29. Maven je rozsáhlý nástroj pro

usnadnění celého procesu sestavování aplikací v jazyce Java. V tomto případě byla

hojně využívána zejména jeho schopnost řešení závislostí. Díky tomu lze snadno do

celého projektu přidávat jednotlivé potřebné knihovny.

5.3.1 Aplikační server

Pro tvorbu jádra systému, kterým je aplikační webový server, byl zvolen

programovací jazyk Java a Spring Framework. Využita je zde ověřená architektura

MVC30, která využívá oddělené struktury jednotlivých komponent starajících se o

zajištění datového modelu, aplikační logiky a přípravy uživatelského rozhraní.

Samotný aplikační server zajišťuje uživateli zpřístupnění dat uložených

v grafové databázi a to ve vhodné formě, zejména pak za využití vhodného filtrování

pouze požadovaných záznamů. Navíc samozřejmě musí zajišťovat všechny podpůrné

funkce celé webové aplikace (např. zpřístupnění konkrétních funkcí nebo dat až na

základě autorizace, ukládání práce, export či tisk výsledků, atd.) a zejména také

pokročilé funkce potřebné pro analýzu zobrazených dat (např. výpočet statistických

metrik grafu, provádění grafových algoritmů, atd.). Po dokončení nutného

předzpracování dat je provedena následná příprava výsledného uživatelského

rozhraní. Dále musí aplikační server umožnit již zmíněný import dat na přání

uživatele, vkládání nových entit do grafů v databázi a úpravu či přidávání jejich

atributů.

28 URL - https://tiles.apache.org/ 29 URL - https://maven.apache.org/ 30 MVC – Model-View-Controller

42

Spring Framework

Spring Framework je rozsáhlý soubor nástrojů vytvářených pro podporu,

usnadnění a zrychlení vývoje Enterprise aplikací v jazyce Java. Počátek jeho vývoje se

datuje do roku 2002. Nejprve byl zaměřen především na vývoj Enterprise aplikací.

Dnes je možné za použití Spring Frameworku a řady k němu přidružených projektů

vytvářet aplikace různého druhu. (27) Mezi základní principy uznávané a používané

při vývoji aplikací ve Springu patří návrhový vzor Inversion of Control (IoC) a

Dependency Injection, dále pak aspektově orientované programování (AOP) či využití

POJO (Plain Old Java Objects). Všechny tyto principy společně zajišťují vysokou

modularitu výsledné aplikace a tím podstatné zjednodušení případných úprav či

rozšíření.

Spring Framework se dnes skládá z široké škály modulů (projektů), které je

možné v případě potřeby dle libosti kombinovat a využívat při tvorbě komplexní

aplikace (viz obrázek 5.6). Podle dokumentace je v současné verzi frameworku

zhruba 20 takovýchto modulů. (28) V případě této práce je zpočátku využit jen

základní modul projektu Spring Framework (Spring Core), který umožňuje právě

využití výše zmíněného vzoru dependency injection, návrhového vzoru pro webové

aplikace MVC, REST rozhraní a další základní prvky potřebné při vývoji webové

aplikace.

Obrázek 5.6: Přehled základních modulů Spring Frameworku, zdroj: http://docs.spring.io

43

Aplikačních frameworků, na kterých by se dala vyvíjená aplikace postavit, je dnes

celá řada. Volba právě Spring Frameworku tak byla do značné míry ovlivněna znalostí

jeho základních principů a zkušenostmi se základy tvorby Spring webové aplikace

z předchozí realizace seminární práce. Navíc se jedná o velmi rozšířenou a komplexní

sadu nástrojů, u které téměř nehrozí, že by se v průběhu případného rozšiřování

aplikace o další funkce mohlo narazit na problém, který nebude snadné řešit právě

pomocí některého z modulů Spring Frameworku. Právě díky jeho současné popularitě

je kromě rozsáhlé dokumentace také volně dostupná široká škála dostatečně

podrobných návodů a tutoriálů. Velni početná a aktivní je komunita okolo Spring

Frameworku také na odborných webových diskuzích31, které jsou častým zdrojem

řešení řady konkrétních problémů.

5.3.2 Grafová databáze

Takto vytvořený systém by v zásadě mohl pracovat s jakoukoliv grafovou databází

na pozadí (pouze za předpokladu, že zvolená databáze a aplikační server budou

schopny navzájem komunikovat na společném API). Pro zde navrhovanou aplikaci

byla zvolena volně dostupná verze grafové databáze OrientDB. Právě z toho byl

odvozen i název aplikace „OrientLink“. Tato grafová databáze slouží pro ukládání

samotných dat určených pro analytické zpracování. Navíc by systém mohl obsahovat

další provozní databázi jiného vhodného typu (např. relační databázi) určenou pro

ukládání potřebných provozních údajů.

Jedním z důvodů volby právě databáze OrientDB bylo to, že se jedná o takzvanou

multi-model databázi. To znamená, že podporuje využití ve více režimech. Pro

navrhovaný systém linkových analýz předpokládáme potřebu ukládání i rozsáhlých

dokumentů, nejen jednoduchých atributů. Obsah takového dokumentu může být

použit jak na straně uzlů grafu, tak i u jeho vazeb. Přesně to je forma ukládání dat

v systému OrientDB, uzly i vazby jsou v podstatě ukládány ve formě dokumentů

obsahujících mimo jiné i odkazy na další na ně navázané dokumenty. Právě

kombinace dokumentové a grafové databáze je proto značnou výhodou OrientDB.

31 Jednou z nejznámějších je zajisté StackOverflow. URL: http://stackoverflow.com/questions/tagged/spring

44

Databázi OrientDB je možné provozovat i v distribuovaném prostředí, kdy jsou

data ukládána na více navzájem propojených uzlů (tzv. cluster). Díky této vlastnosti

lze zajistit požadavek možnosti případného navýšení objemu ukládaných dat.

OrientDB

OrientDB je open-source dokumentově-grafový NoSQL databázový systém. Co si

představit pod pojmem dokumentově-grafový databázový systém? Jedná se o NoSQL

databázi, která svojí strukturou nezapadá přímo do jedné z kategorií NoSQL databází,

tak jak jsou popsány v kapitole 3.3.2. V případě OrientDB je použita právě kombinace

grafového a dokumentového modelu NoSQL databází. V zásadě se jedná o grafovou

databázi, v níž jsou jednotlivé uzly a vazby ukládány v podobě dokumentů a

umožňuje tak využití veškeré funkčnosti dokumentových databází. V dokumentaci

projektu OrientDB jsou navíc uváděny možnosti použití tohoto systému ve formě

Key-Value databáze nebo objektové databáze. Proto je také OrientDB často

popisována zkráceně jako multi-model32 databázový NoSQL systém (29). Tyto

posledně jmenované modely nebudou dále podrobněji rozebírány, protože nejsou

v případě této práce podstatné a jejich vlastností v systému pro linkové analýzy

nejsou využity. Jak je zřejmé, v případě nasazení v systému pro linkové analýzy je

nejpodstatnějším modelem OrientDB právě ten grafový.

Systém OrientDB je napsán v jazyce Java a je tak možné ho provozovat na

jakémkoli operačním systému umožňujícím běh JVM33. Klientské aplikace pak mohou

pro přístup k datům využít některého ze široké škály dostupných aplikačních

rozhraní (API34) nebo přímý HTTP/REST přístup. Z řady dostupných API bývá

nejčastěji využíváno rozhraní například pro programovací jazyky Java, JavaScript,

Python či C#.

Technicky vzato je spojení se serverem možné realizovat dvěma způsoby. Buď

binárním síťovým připojením (defaultně mu server naslouchá na portu 2424), které

je využíváno právě formou API jednotlivých programovacích jazyků35. Nebo

prostřednictvím HTTP spojení (defaultně mu server naslouchá na portu 2480),

32 URL - http://orientdb.com/docs/last/Tutorial-Document-and-graph-model.html 33 JVM - Java Virtual Machine 34 API - Application Programming Interface 35 URL - http://orientdb.com/docs/last/Network-Binary-Protocol.html

45

využívající protokol REST a přenos dat ve formátu JSON. První varianta binárního

spojení je sice nejefektivnější, avšak vývoj klientských aplikací je naopak jednodušší a

rychlejší při použití REST rozhraní36.

Základní princip práce s daty v OrientDB vychází z paradigmatu objektově

orientovaného programování, ze kterého přebírá koncept tříd (Class) a to i se

zachováním možnosti dědičnosti. Z objektově orientovaného programování si

OrientDB přináší také možnosti abstraktních tříd (třídy, které nemohou mít

vytvořenu instanci a jsou určeny pro tvorbu dalších tříd právě pomocí dědičnosti).

Jednotlivé instance tříd tak jak je známe z OOP, jsou zde představovány záznamy uzlů

a vazeb ukládanými do databáze. Koncept tříd je zde navíc rozšířen o použití

tzv. clusterů pro podrobnější shlukování záznamů z jedné třídy. Cluster lze vnímat

jako obdobu tabulky v relační databázi, přesněji však představuje kolekci v databázi

dokumentové. Pro každou novou třídu je standardně vytvořen jeden cluster a

všechny záznamy jsou ukládány do něj37.

Obrázek 5.7: Příklad využití rozdělení třídy do více clusterů, zdroj: http://orientdb.com/docs/last/Tutorial-Clusters.html

OrientDB lze provozovat ve třech režimech označovaných jako schema-full,

schema-less a schema-mixed38. Jednotlivé módy se liší tím, jak striktně jsou

definovány struktury ukládaných dat. V případě použití schema-full jsou přesně

definovány třídy (uzlů a vazeb) i se všemi jejich atributy. V případě ukládání nového

záznamu do databáze v tomto režimu jsou vždy nastaveny hodnoty všech takto

36 URL - http://orientdb.com/docs/last/OrientDB-REST.html 37 Reálně je v nových verzích OrientDB tvořeno pro každou novou třídu více clusterů a to podle počtu jader procesoru použitého v HW, na kterém je server provozován. Důvodem tohoto dělení je zvýšení efektivity paralelizace zpracování dat. 38 Režim schema-mixed bývá někdy označován také jako „schema-hybrid“.

46

definovaných atributů (pokud to není u daného atributu zakázáno, může být

samozřejmě uložena hodnota null). V případě schema-less módu nejsou u

jednotlivých tříd přesně definovány jejich atributy. Jaké informace do kterých

atributů budou uloženy, je dáno až v okamžiku zápisu nového záznamu do databáze.

Posledně jmenovaný mód schema-mixed je jakýmsi kompromisem mezi oběma výše

popsanými. V tomto případě mají třídy pevně definovány některé atributy a navíc je

možné v okamžiku zápisu nového záznamu do databáze přidat i další doplňující

atributy. V praxi při provozu systému OrientDB není striktně vybrán některý z výše

popsaných módů datového schématu. To, zda jsou třídy předdefinovány i se svými

atributy, je řízeno až na aplikační úrovni. Není proto problém na jedné instanci

databáze pracovat ve kterémkoli z těchto režimů, což lze vlastně chápat tak, že je vždy

použit mód schema-mixed a záleží na konkrétních třídách, zda mají všechny své

atributy nadefinovány.

V následujících odstavcích jsou stručně popsány základní principy a možnosti

databázového systému OrientDB.

Dokumentový model OrientDB

V případě využití dokumentového modelu OrientDB jsou data ukládána v podobě

dokumentů, stejně jako v řadě dalších dokumentových databází (viz kapitola 3.3.2).

I zde je dokument vnímán jako množina párů klíč-hodnota (Key-Value). Dokumenty

v tomto případě nemusí mít předem definovanou strukturu a jsou ukládány

v kolekcích, které jsou tvořeny třídami a clustery. V rámci dokumentu navíc lze

uchovávat informaci o vazbě na jiný dokument ve formě tzv. linku. V přiložené

tabulce 5.1 jsou znázorněny ekvivalenty jednotlivých prvků relačních databází,

dokumentových databází a OrientDB (pracující v dokumentovém režimu).

Tabulka 5.1: Srovnání modelů relační databáze, dokumentové databáze a OrientDB v režimu dokumentového modelu, zdroj: http://orientdb.com/docs/2.1/Tutorial-Document-and-graph-model.html

47

Grafový model OrientDB

Při využití grafového modelu se dostáváme do oblasti grafových databází tak,

jak jsou popsány v kapitole 3.3.2. I zde se stejně jako ve valné většině jiných grafových

databází jedná o uchovávání atributových multigrafů. Z tohoto popisu je zřejmé, že

v databázi OrientDB lze v tomto módu ukládat grafy obsahující orientované hrany

různých typů a s různými atributy. Stejně tak u uzlů lze ukládat širokou škálu

doplňujících atributů. Také zde je pro názornost přiložena tabulka srovnávající prvky

relační databáze, grafové databáze a OrientDB pracující v grafovém režimu

(viz tabulka 5.2).

Tabulka 5.2: Srovnání modelů relační databáze, grafové databáze a OrientDB v režimu grafového modelu, zdroj: http://orientdb.com/docs/2.1/Tutorial-Document-and-graph-model.html

Extended SQL

Pro dotazování je v grafové databází OrientDB používán vlastní dotazovací jazyk

označovaný jako Extended SQL. Jedná se o dotazovací jazyk vycházející ze

standardního jazyka SQL (základní funkce jsou naprosto stejné) rozšířený právě o

možnost práce nad grafovým modelem dat. Díky tomu je zachována převážná část

syntaxe běžně užívaného jazyka SQL. Alternativně lze pro dotazování použít kromě

Extended SQL či API jednotlivých programovacích jazyků také framework Gremlin39.

39 Gramlin je jazyk určený pro provádění operací nad grafovými daty.

48

Licenční politika OrientDB

Databáze OrientDB je dostupná ve dvou verzích a to ve verzi Community Edition a

Enterprise Edition. Community Edition je open-source vydání pod licencí Apache 2

(30). Enterprise Edition je komerční vydání, které oproti Community verzi obsahuje

navíc některé rozšiřující vlastnosti. Jedná se zejména o možnost profilace dotazů

(Query Profiller), monitoring zdrojů serveru (Metrics Analysis), rozšířené nastavení

distribuovaného nasazení serverů (Cluster Management), rozšířené možnosti

zálohování dat a v neposlední řadě také plnou technickou podporu. V případě této

diplomové práce byla při tvorbě ukázkové aplikace využita komunitní verze

OrientDB, jejíž základní vlastnosti jsou pro nadefinované požadavky dostačující.

5.3.3 Webový klient

Posledním prvkem celého systému pro linkové analýzy je webové uživatelské

rozhraní, které musí zajistit komfortní práci analytika a to i bez nutnosti podrobných

znalostí dotazovacích jazyků či konkrétních grafových algoritmů potřebných k získání

požadovaného výsledku. Jedná se o poměrně standardní webové rozhraní, ve kterém

hraje velkou roli část grafické reprezentace načtených dat. Použity jsou zde klasické

prvky webových aplikací jako HTML a JavaScript. Komunikace se serverem je

zajišťována pomocí technologie AJAX40. Pro grafickou část aplikace byla zvolena

JavaScriptová knihovna D3.js41 určená pro tvorbu vizualizací na základě

předkládaných dat.

V případě realizované aplikace není nutné se příliš zabývat jednou ze základních

nevýhod webového prostředí využívajícího jazyk JavaScript, kterou je možná

nekompatibilita s některými prohlížeči a zařízeními, ze kterých dnes uživatelé na web

přistupují. Vytvářená aplikace je totiž zamýšlena jako podnikové řešení přístupné

pouze pro interní zaměstnance a tím pádem pouze z koncových zařízení omezené

pestrosti. V takovém případě není příliš složité zajistit všem uživatelům stejné

prohlížeče (pokud tomu tak již není).

Volba konkrétní vizualizační knihovny není snadnou otázkou a skutečná vhodnost

daného řešení se většinou ukáže až v průběhu vývoje. Varianta knihovny D3.js byla

40 AJAX - Asynchronous JavaScript and XML. Podrobněji viz kapitola 6.3. 41 URL - https://d3js.org/

49

zvolena z důvodu její univerzálnosti. U analytického prostředí lze do budoucna

předpokládat rozšiřování o řadu funkcionalit, z nichž ne všechny musí nutně využívat

pouze vizualizaci síťových grafů. Naopak je pravděpodobné, že bude nutné

vizualizovat i řadu jiných datových typů. Často se jedná především o časové osy,

histogramy, či další grafy znázorňující hodnoty různých veličin. Právě všestrannost

knihovny D3.js ji předurčuje pro všechny takovéto úlohy. Pro samotnou vizualizaci

síťových grafů by zřejmě byly dostupné i vhodnější nástroje. Vhodnější zejména

z pohledu nižší náročnosti vývoje. Například produkt KeyLines42 britské společnosti

Cambridge Intelligence43, je určený přímo pro tvorbu vizualizací pro linkové analýzy.

Jedná se taktéž o JavaScriptový toolkit, který slibuje podstatně snadnější

implementaci než například D3.js. Navíc obsahuje širokou škálu podpůrných funkcí

(určených přímo pro linkové analýzy) již připravených ke snadnému použití. Bohužel

jde o komerční produkt a společnost Cambridge Intelligence nebyla ochotna

poskytnout testovací licenci za účelem použití v rámci tvorby diplomové práce.

AJAX

V této kapitole budou stručně popsány základní principy, možnosti, výhody a

případné nevýhody technologie AJAX. Název AJAX je akronym z anglického

„Asynchronous JavaScript and XML“. (31) Název sám o sobě stručně popisuje základní

používané principy tohoto přístupu k tvorbě webových aplikací. Pouze s tím detailem,

že poslední slůvko XML již v dnešní době nemusí platit a často jsou k přenosu

využívány i jiné datové formáty. Velmi často (stejně jako v případně projektu

OrientLink) se jedná například o formát JSON. Srovnání modelu běžné webové

aplikace a aplikace využívající AJAX je patrné na přiloženém obrázku 5.8.

42 URL - http://cambridge-intelligence.com/keylines/ 43 Vzhledem k zaměření společnosti Cambridge Intelligence není velkým překvapením, že byla založena několika bývalými zaměstnanci společnosti i2 (tvůrce výše popisované aplikace Analyst’s Notebook), kteří z ní odešli v roce 2011 poté, co byla společnost i2 pohlcena korporací IBM. Nutno také podotknout, že z pohledu uživatele od té doby nedochází v produktu Analyst’s Notebook k příliš velkému vývoji či přidávání zásadních funkcí.

50

Obrázek 5.8: Srovnání tradičního modelu webové aplikace a aplikace využívající AJAX, zdroj: (31)

Rozeberme si jednotlivé principy AJAXu od začátku. Asynchronous naznačuje, že

se jedná o asynchronní přenos dat. Ten má ve výsledku vliv na zlepšení interaktivity

tvořené aplikace. Jedná se totiž o zpracování dat asynchronně přenesených (právě

například pomocí formátu XML) ze serveru na stranu klienta a to bez nutnosti

opětovného načítání celé webové stránky. Takto přenesená data jsou poté

zpracována pomocí JavaScriptu (jak napovídá druhé slovo názvu) a výsledkem je

vyvolání požadovaného efektu na zobrazené webové stránce prohlížeče. Tento

princip umožňuje tvorbu podstatně bohatších a uživatelsky přívětivějších aplikací,

než jaké by bylo možné tvořit za použití základních principů webu. Poslední písmeno

v názvu vyjadřuje právě datový formát XML. Jak již bylo nastíněno dříve, pochází toto

označení z počátků vývoje, kdy byl pro přenos dat ze serveru ke klientovi (i ve směru

opačném) používán výhradně formát XML. V současnosti se ještě častěji než

s formátem XML můžeme u webových stránek a aplikací setkat s použitím formátu

JSON.

Zásadní nevýhodou využití AJAXu v běžných situacích je zejména to, že stránky,

které ho využívají, jsou jen těžko přístupné pro roboty vyhledávačů. Navíc nemusí být

vždy stoprocentně zajištěna kompatibilita potřebného JavaScriptového kódu na všech

prohlížečích. Oba tyto problémy však nejsou v případě vývoje zde tvořeného

51

analytického prostředí, u kterého předpokládáme provoz pouze v lokální síti,

relevantní.

D3.js

Na straně uživatelského rozhraní klientské aplikace je v případě práce s daty

v grafové podobě poměrně zásadní otázkou vizualizace analyzovaných dat. V případě

webové aplikace OrientLink bylo pro tuto funkci zvoleno využití JavaScriptové

knihovny D3.js44. Název této knihovny je tvořen zkratkou D3 znamenající Data-Driven

Documents. To napovídá, že se nejedná o nástroj určený výhradně pro vizualizaci

síťových grafů. Možnosti knihovny D3.js mají mnohem širší záběr. Je určena pro

tvorbu interaktivních vizualizací všeobecně. Pojem Data-Driven Documents lze

chápat tak, že data nejsou pouze převedena do grafické podoby, avšak jsou navázána

na jednotlivé HTML objekty zobrazovaného dokumentu (DOM elementy). To

následně umožňuje změnu grafické reprezentace objektu na základě změny vstupních

dat. (32)

Při práci s D3.js je využíváno základních stavebních prvků moderního webu, jako

jsou SVG či canvas, CSS, selektory, HTML5 a JavaScript. Data mohou být pro knihovnu

D3.js předkládána v různých formátech, nejčastěji a velmi jednoduše lze využít právě

formátu JSON. Pro práci s knihovnou D3.js je nutné se seznámit alespoň se základními

principy výše zmíněných webových technologií45.

DOM

Název DOM46 je akronymem z anglického Document Object Model (objektový

model dokumentu) a naznačuje, že se jedná o přístup k dokumentům využívající

objektového pohledu na obsah zpracovávaného dokumentu (viz obrázek 5.9). Stručně

řečeno se jedná o rozhraní umožňující programový přístup k obsahu, struktuře či

stylu dokumentu. DOM obecně se věnuje jakýmkoliv dokumentům. Běžně se pomocí

něj pracuje s dokumenty XML či HTML. Právě využití HTML DOM je pro tuto práci

44 URL - https://d3js.org/ 45 Navíc se jedná o základní poznatky nutné pro tvorbu celého webového uživatelského prostředí, nejen pro práci s knihovnou D3.js. 46 URL - https://www.w3.org/DOM/

52

stěžejní. Jedná se o zásadní technologii využívanou pro tvorbu dnešních webových

stránek. Za využití JavaScriptu je pomocí DOM možné měnit pouze konkrétní

požadované prvky ve webovém dokumentu.

Obrázek 5.9: Příklad struktury HTML dokumentu pomocí DOM, zdroj: http://www.w3schools.com/js/js_htmldom.asp

HTML DOM definuje veškeré HTML elementy jako objekty DOM. Pomocí těchto

objektů máme poté přístup nejen k textovému obsahu daného objektu, ale také

ke všem jeho vlastnostem (atributům). HTML DOM dále definuje i metody pro přístup

k elementům a události vyvolávané při určitých akcích.

CSS a selektory

Kaskádové styly, zkráceně CSS (Cascading Style Sheets)47, je jazyk používaný pro

definici způsobu zobrazení HTML dokumentů. Pomocí kaskádových stylů je možné

při psaní HTML dokumentu oddělit jeho obsah od definice jeho vzhledu. Díky tomu je

pak možné například použití více vzhledů pro jeden dokument, nebo naopak

jednoduše tvořit více dokumentů tak, aby měly stejný vzhled.

Definice vzhledu příslušného dokumentu se skládá ze souboru pravidel určujících

jednotlivé vlastnosti stylu. Každé z těchto pravidel musí vždy obsahovat selektor a

blok deklarací navzájem oddělených středníky. Každá takováto deklarace obsahuje

identifikátor vlastnosti a její hodnotu (oddělené dvojtečkou).

47 URL - https://www.w3.org/Style/CSS/, http://www.w3schools.com/css/default.asp

53

Z výše popsaného principu je zřejmé, že základním kamenem CSS jsou právě

selektory. Selektory jsou definovány ve specifikaci SCC (v současnosti CSS3), je jich

celá řada a navíc je možné je vzájemně kombinovat. Mezi ty úplně nejzákladnější

selektory patří selektor elementu (např. body, table), selektor třídy (.nazevTridy) či

selektor podle id (#idElementu). V případě zájmu je vhodné si podrobně prostudovat

veškeré možnosti CSS selektorů na některém z mnoha webových zdrojů. Například na

oficiálních stránkách organizace W3C https://www.w3.org/Style/CSS/, v tutoriálech na

webu W3Schools http://www.w3schools.com/cssref/css_selectors.asp nebo na některém

z řady dalších takto zaměřených webů.

SVG

Vektorový grafický formát SVG (Scalable Vector Graphics)48 je základním

formátem používaným pro vektorovou 2D grafiku ve webovém prostředí. Pro jeho

zápis je použit značkovací jazyk XML. To umožňuje implementaci grafických prvků

pomocí SVG přímo do zdrojového kódu HTML stránky. I se všemi důsledky, jako třeba

možnost manipulace s jednotlivými elementy SVG obrázku pomocí JavaScriptového

kódu, možnost interaktivních reakcí jednotlivých jeho elementů, možnost stylování

pomocí CSS nebo třeba možnost vyhledávání textu obsaženého v SVG.

Právě popsané základní stavební kameny jsou v D3.js využity tak, že libovolná

vstupní data jsou navázána na objekty DOM modelu HTML stránky. Následně je

možné využít různých, také na vstupních datech závislých, transformací. Vstupní data

jsou vkládána ve formě pole hodnot, případně pole objektů, a následně je každý prvek

těchto vstupních polí navázán na konkrétní element v HTML dokumentu. Je zde

možné využít jakýchkoliv elementů HTML. Pro tvorbu pokročilejších vizualizací je

samozřejmě nejvýhodnější využít právě prvky SVG grafiky. V rámci každého

propojení datového prvku s elementem DOM je možné v závislosti na hodnotách

vstupních dat měnit i hodnoty vybraných atributů tohoto elementu. Právě díky tomu

se ve výsledku mění grafická reprezentace jednotlivých elementů na základě hodnot

vstupních dat. Touto cestou jsou v případě vyvíjené aplikace OrientLink do SVG

48 URL - https://www.w3.org/Graphics/SVG/

54

obrázku vloženy všechny uzly a hrany. Posledním krokem nutným před samotným

vykreslením celého grafu je určení vhodného rozložení všech uzlů v prostoru. Tento

proces bývá v odborné literatuře nazýván tvorba „layoutu“49. Layoutů, myšleno

konkrétních algoritmů pro výpočet pozic jednotlivých uzlů, existuje celá řada (8).

Zpravidla je dobré mít možnost vykreslení načtených dat pomocí různých layoutů,

protože pro konkrétní případy může být výsledná přehlednost značně rozdílná.

V navrhované aplikaci byl pro vykreslování zvolen „Force-Directed Layout“, který je

přímo součástí knihovny D3.js (32). Jedná se o značně univerzální zobrazení hojně

využívané právě v oblasti linkových analýz. To ovšem zdaleka neznamená, že

automaticky vytvořené rozložení uzlů je pro uživatele vždy tím nejlepším. Proto je

následně možné jednotlivé uzly si ručně přesunout a celé zobrazení grafu si tak

přizpůsobit konkrétním podmínkám a potřebám.

49 Pojem layout by se dal v tomto kontextu přeložit jako rozmístění, či dispozice. Ovšem zpravidla nebývá počešťován.

55

5.4 Grafické uživatelské prostředí a základní funkce systému

OrientLink Celé grafické uživatelské rozhraní webové aplikace OrientLink se skládá pouze

z několika málo HTML stránek. Na přiloženém obrázku 5.10 jsou znázorněny možné

přechody mezi jednotlivými stránkami aplikace. Návrat na domovskou stránku je

samozřejmě možný ze všech ostatních stránek, z důvodu přehlednosti není ovšem

v diagramu vyznačen. Veškerá stěžejní funkcionalita týkající se práce se síťovým

grafem a tvorby linkové analýzy se totiž odehrává pouze na jedné stránce bez

nutnosti jejího opakovaného překreslování nebo bez přechodů na další stránky.

K tomu je využito již popsaného principu komunikace klienta se serverem za pomoci

AJAX. Ostatní serverem nabízené HTML stránky zajišťují spíše podpůrné funkce

využívané většinou před zahájením samotné práce na linkové analýze.

Obrázek 5.10: Diagram přechodů mezi stránkami aplikace OrientLink, zdroj: autor

Na hlavní stránce aplikace „OrientLink – Home“ se uživatel dozví pouze základní

stručný popis aplikace. Také je zde zobrazen aktuální stav grafového databázového

serveru. Může totiž dojít k situaci, kdy je dostupná webová aplikace OrientLink,

ovšem z různých důvodů (údržba, havárie, aktualizace) nemusí být dostupná grafová

databáze. V takovém případě není možné celou aplikaci OrientLink používat.

56

V případě pokračování v rozvoji aplikace zcela jistě bude další funkcí hlavní

stránky také umožnění přihlášení uživatele do celého systému. V dalších částech

aplikace mu poté budou zpřístupněny pouze pro něj určené funkce a zdroje dat. Navíc

bude poté možné personalizovat vzhled a chování některých částí aplikace podle

požadavků jednotlivých uživatelů.

Další krok uživatele běžně povede na stránku s přehledem dostupných

databází (viz obrázek 5.11). Zde jsou v tabulce přehledně vypsány všechny databáze,

na kterých může uživatel pracovat. Ke každé databázi jsou zpřístupněny dvě

podpůrné stránky zobrazující podrobnější popis zvolené databáze („Podrobnosti“) a

výpis všech nadefinovaných tříd a jejich atributů („Schéma“). Hlavním odkazem je pak

u každé databáze vstup na stránku pro prohlížení a práci s konkrétními daty

v grafické podobě „Linkové analýzy“.

Dále je na této stránce umožněno vytvořit databázi novou. V tomto kroku uživatel

vytvoří pouze prázdnou databázi na serveru OrientDB. Následně může v této databázi

nadefinovat třídy jednotlivých typů uzlů a vazeb i s požadovanými parametry a to

právě na stránce zobrazující schéma databáze. Tato funkce je dostupná také u již

dříve vytvořených a používaných databází.

Obrázek 5.11: Stránka zobrazující dostupné grafové databáze, zdroj: autor

57

Ještě před popisem samotného prostředí určeného pro práci s daty a pro

provádění linkových analýz se podíváme na další funkční celek aplikace, kterým je

část obstarávající import uživatelských dat do grafových databází na serveru

OrientDB. To je možné na stránce „Načítání dat“ (viz obrázek 5.12). Zde jsou uživateli

zpřístupněny různé formy vkládání vlastních dat. Jedná se o načítání dat ze souboru

ve formátu csv50, o načítání cestou vestavěné funkce OrientDB – ETL51. Navíc je zde

pro potřeby testování, případně z pohledu koncového uživatele pro potřeby

seznámení se s funkcemi a principy práce celého systému OrientLink, zpřístupněna

možnost automatického generování grafových dat několika různých struktur. Pro

další vývoj se již nyní počítá i s implementací možnosti importu dat z relačních

databází pomocí definice vhodných SQL dotazů vracejících seznamy uzlů a jejich

vazeb.

Obrázek 5.12: Stránka pro import uživatelských dat, zdroj: autor

50 CSV - comma-separated values neboli hodnoty oddělené čárkami. V praxi se však kromě čárek často používají i další oddělovače. 51 Jedná se o nástroj pro import dat dodávaný s databází OrientDB.

58

Aplikace dále obsahuje odkaz na stránku s uživatelskou nápovědou stručně

popisující základní pracovní postupy. Navíc je přidán odkaz do výše popsané externí

webové aplikace OrientDB Studio (viz kapitola 5.2), ve které je také možné pracovat

s dostupnými grafovými databázemi a v nich uloženými daty.

Poslední, avšak nejdůležitější částí uživatelského prostředí webové aplikace

OrientLink, je právě HTML stránka určená pro vyhledávání, zobrazování, editaci a

vkládání uzlů a vazeb (viz obrázek 5.13). Stručně řečeno se jedná o prostředí pro

samotné linkové analýzy. Tato stránka je dostupná pro každou z databází

zpřístupněných uživateli ve výše popsaném seznamu databází.

Obrázek 5.13: Prostředí pro zpracování linkové analýzy, zdroj: autor

Po otevření této části aplikace je uživateli zpřístupněna prázdná vykreslovací

plocha a tři základní ovládací nabídky. Na levé straně je zobrazeno menu pro

vyhledávání a načítání dat v grafové databázi na serveru a také pro vyhledávání

v zobrazeném grafu. Ve vrchní části stránky je přístupné menu umožňující základní

práci s objekty zobrazenými na pracovní ploše. Vpravo je pak možné si zobrazit další

nabídku, ve které je kromě zjištění základních informací o právě označeném uzlu

59

možné také zobrazení podrobnějších informací o označených částech grafu a

statistiky celého načteného grafu. Obě postranní nabídky jsou z důvodu umožnění

maximalizace plochy dostupné pro práci s vizualizovaným grafem vysouvací. Přičemž

levé menu pro vyhledávání dat je po otevření stránky defaultně zobrazeno. Je totiž

velmi pravděpodobné, že první kroky každého uživatele povedou vždy právě do této

části aplikace.

Vyhledávání dat ve zvolené grafové databázi je uživateli umožněno pomocí

několika metod. První možností je zvolení konkrétní třídy z nabízeného seznamu,

poté je zpřístupněn i seznam atributů nadefinovaných ve schématu dané databáze

k této třídě. Vzhledem k tomu, že v grafové databázi mohou některé uzly (i vazby)

obsahovat také dodatečné atributy, které nejsou ve schématu definovány, je

umožněno i vyhledávání v takovýchto atributech. V tom případě však uživatel musí

znát přesný název prohledávaného atributu a ten zadat do pro to určeného pole.

Pokud nezná název atributu a přesto chce vyhledávat určitý textový řetězec, může tak

učinit tím, že ponechá v příslušném poli hodnotu „any()“. V tom případě dojde

k prohledávání všech atributů u uzlů zvolené třídy. Dále je zde dostupná i možnost

nechat vykreslit všechny objekty v dané třídě. V tomto případě je však výsledek

omezen maximálním počtem navrácených entit, který je nastaven na 100052.

Další metodou vyhledávání v grafové databázi je vyhledávání podle vzoru

(takzvaný Pattern Matching). Jedná se o metodu, při které uživatel v editoru vzoru

nadefinuje schéma obsahující požadované uzly a vazby mezi nimi (viz obrázek 5.14).

K jednotlivým uzlům i vazbám může zvolit, v jaké třídě musejí být. Navíc je možné

určit doplňující podmínky vztahující se k hodnotám atributů. Následně je možné

v celé grafové databázi vyhledat všechny skupiny uzlů a vazeb, které přesně

odpovídají nadefinovanému vzoru. Jedná se o pokročilou metodu vyhledávání, jejíž

možnosti by při využití například relační databáze byly jen těžko realizovatelné.

52 Tato hodnota lze spolu s dalšími parametry snadno změnit v konfiguračním souboru aplikačního serveru „settings.properties“.

60

Obrázek 5.14: Definice vzoru pro hledání v grafové databázi, zdroj: autor

5.5 Vnitřní struktura systému OrientLink Jádro celého systému tvoří již zmíněný webový aplikační server. Ten je vyvíjen

s využitím Spring Frameworku a skládá se z několika částí. Tyto submoduly poté

zajišťují vždy pouze specifické úlohy. Jednotlivé funkční celky jsou navzájem

provázány pomocí konfigurace aplikačního kontextu. Na přiloženém obrázku 5.15 (na

následující straně) je zobrazen UML diagram tříd. Z důvodu vyšší přehlednosti jsou

v tomto diagramu zahrnuty pouze základní třídy obstarávající samotnou logiku

aplikace, přístup k datům a komunikaci s klienty. Celá aplikace pak obsahuje ještě

několik podpůrných tříd. Na dalším obrázku 5.16 jsou proto zobrazeny již všechny

Java balíčky a do nich náležící třídy tvořící aplikaci OrientLink.

61

Obrázek 5.15: UML diagram tříd jádra aplikace OrientLink, zdroj: autor

62

Obrázek 5.16:Přehled všech Java balíčků a tříd aplikačního serveru OrientLink, zdroj: autor

Vrstva kontrolérů je z důvodu přehlednosti rozdělena do více tříd. Všechny tyto

třídy se nachází v balíčku „cz.krn.orientlink.controllers“.

První z nich je třída AppController, která se stará o vyřizování požadavků

týkajících se základní navigace v uživatelském prostředí webové aplikace. Přijímá a

zpracovává tak požadavky směřující na hlavní (Home) stránku celé aplikace, na

stránky zobrazující přehled dostupných databází a podrobnější informace o zvolené

databázi, na stránku umožňující import dat do grafové databáze a nakonec také na

stránku pro tvorbu linkových analýz z dat uložených v jednotlivých databázích.

Druhou třídou v balíčku „controllers“ je IOController, který obstarává požadavky

týkající se importu a exportu dat. V případě importu dat zajišťuje načtení zvoleného

souboru z klientské stanice na server a následně i ukládání dat z přeneseného

souboru do zvolené grafové databáze. Do této třídy budou nadále přidávány veškeré

funkce týkající se například i exportu dat do dalších požadovaných formátů. Může se

jednat například o převedení do formy vhodné pro tisk, export do PDF nebo o

63

vytvoření datového souboru (CSV, JSON, GrphML, atd.) obsahujícího uživatelem

vybranou část grafových dat.

Poslední třídou v balíčku je AjaxController. Jedná se o stěžejní kontrolér zajišťující

veškerou AJAX komunikaci mezi klientem a serverem. Právě tato AJAX komunikace je

využívána zejména v té části aplikace, kde dochází k načítání a zobrazování dat

z grafových databází. Na rozdíl od předešlých dvou kontrolérů, jejichž metody

standardně vrací cestu k JSP53 souboru generujícímu danou HTML stránku, jsou

kontrolérem AjaxController vraceny přímo požadovaná data ve formátu JSON.

Dalším balíčkem ve struktuře aplikačního serveru je „cz.krn.orientlink.daos“,

ve kterém se nacházejí třídy zajišťující veškerou komunikaci mezi aplikací a

databázovým serverem OrientDB. V případě potřeby změny použité grafové databáze

by právě tento balíček byl místem prováděných změn. Právě z toho důvodu jsou zde

nejprve nadefinována rozhraní (Interface) DAO tříd. Samotný výkonný kód je poté

obsažen až ve třídách implementujících tato rozhraní. Tím je zajištěno, že při výměně

těchto DAO tříd za jiné (určené pro jiný typ grafové databáze), implementující stejné

rozhraní, bude zachována funkčnost ostatních částí aplikace. Opět zejména z důvodu

zpřehlednění zdrojových kódů a struktury celé aplikace jsou pro přístup k databázi

vytvořena dvě rozhraní. Jedná se o rozhraní SchemaDAO a GraphDAO. Následně jsou

vytvořeny dvě DAO třídy implementující tato rozhraní (OrientSchemaDAO a

OrientGraphDAO). Prvně jmenovaná třída zajišťuje veškerou komunikaci týkající se

grafového schématu zvolené databáze. Jedná se o funkce jako získání seznamu

databází dostupných na serveru, seznamu tříd uzlů a hran v grafu zvolené databáze i

s jejich atributy nebo vytvoření nových třídy či atributů již existujících tříd.

Druhá třída OrientGraphDAO se poté stará o veškerou výměnu dat ukládaných

v samotných grafech jednotlivých databází. Obsahuje proto řadu metod určených pro

vyhledávání a načítání uzlů či hran zvoleného grafu podle široké řady kritérií, stejně

tak umožňuje uložení nově vytvořeného uzlu (vazby) do grafu v databázi či

aktualizaci hodnot atributů u již existujících záznamů.

Dále můžeme ve struktuře aplikačního serveru nalézt balíček

„cz.krn.orientlink.wrapers.visual“, ve kterém jsou umístěny třídy umožňující

předávání dat mezi aplikačním serverem a grafickou částí uživatelského prostředí.

53 JSP – Java Server Pages – technologie pro vývoj dynamických HTML stránek v jazyce Java.

64

Jedná se o třídy datového modelu zapouzdřující entity (uzel, hrana a celý graf) určené

pro přenos do prostředí webového prohlížeče za účelem zobrazení. Od toho se také

odvíjí jejich struktura. Obsahují všechny atributy potřebné pro vizualizaci. Obdobně

jsou tvořeny také třídy reprezentující stejnou grafovou strukturu ovšem určenou pro

tvorbu vzoru pro vyhledávání (Pattern Matching). Tyto třídy jsou umístěny v balíčku

„cz.krn.orientlink.wrappers.pattern“.

V ostatních balíčcích jsou umístěny podpůrné třídy poskytující jednotlivým

funkčním blokům další požadované funkce. Jedná se o třídu GraphToVisulaConvertor

starající se o převod objektů získávaných z grafové databáze na instance tříd určené

pro přenos do prohlížeče a následné zobrazení. To jsou právě třídy z výše popsaného

balíčku „visual“. Dále je v projektu využíván balíček „cz.krn.orinetlink.utils.dbutils“

zastřešující podpůrné nástroje pro různé akce nad databázovým serverem.

V současné verzi aplikace se jedná zejména o zjišťování stavu databázového serveru a

spouštění procesu ETL. Dále jsou zde připraveny metody zajišťující startování a

zastavování samotného databázového serveru. Ty však nejsou v uživatelském

prostředí zpřístupněny. Není totiž žádoucí, aby běžný koncový uživatel mohl vypínat

databázový systém, na kterém jsou závislí i všichni ostatní uživatelé. S použitím

těchto funkcí se počítá až po implementaci uživatelské autorizace, kdy budou

zpřístupněny uživatelům s právy databázového či systémového správce. Dalším

podpůrným balíčkem je „cz.krn.orientlink.utils.graphstream“, ve kterém jsou dvě

třídy zajišťující generování testovacích grafů a zpracování některých grafových

algoritmů. V těchto třídách je využívána knihovna GraphStream54 určená pro práci

s dynamickými grafy.

5.6 Zpracování dat v rámci aplikace OrientLink Podle konkrétních podmínek a potřeb je možné v celém systému OrientLink

provádět zpracování dat na třech různých úrovních. Zaprvé lze s daty pracovat ještě

v grafové databází OrientDB (případně v jiné použité grafové databází), dále lze

některé algoritmy efektivně využít v rámci aplikačního serveru, a v neposlední řadě

lze některé požadavky plnit už na straně klienta ve webovém prohlížeči pomocí kódu

v jazyce JavaScript. Tyto jednotlivé úrovně je nutné volit na základě požadovaného

54 URL - http://graphstream-project.org/

65

množství dat potřebných pro daný úkon, dostupnosti všech potřebných dat v daném

místě systému a navíc i požadované rychlosti provedení celého algoritmu.

Zpracování v prohlížeči na straně uživatele je vhodné pouze v případě, kdy nám

k vyřešení požadované úlohy postačí pouze data již načtená. Je použito například pro

vyhledávání ve zobrazeném grafu, filtrování či zvýrazňování zvolených entit. Vždy je

použito pro výpočet rozložení vizualizace grafu (tzv. layout). V tomto místě je

využíván skriptovací jazyk JavaScript. S výkonem dnešních počítačů není již téměř

žádný problém ani s prováděním relativně složitých výpočtů přímo v prostředí

webového prohlížeče. Navíc v případě potřeby lze využít i moderních nástrojů ze

specifikace HTML5 jakými jsou Web Workers. Ty umožňují provádění

JavaScriptového kódu na pozadí, aniž by tím byla narušena plynulá reakce samotné

webové stránky. Umožňují tak v JavaScriptu zavedení paralelismu.

Vždy je dobré objektivně zvážit, kdy je ještě předešlé řešení vhodné a kdy už bude

výhodnější data odeslat na server a tam provést potřebné zpracování a výsledky

předat zpět prohlížeči. Tento druhý přístup může být výhodnější, pokud kvůli objemu

zpracovávaných dat a složitosti algoritmu hrozí zhoršení uživatelského pohodlí

zpomalením reakcí prohlížeče. Dále vždy, když v průběhu provádění algoritmu může

dojít k potřebě získávat dodatečná data jejich načtením z databáze nebo pokud

samotným výsledkem budou další data, která bude potřeba načíst a zobrazit.

Poslední místem, kde lze provádět zpracování dat, je přímo na databázovém

serveru. Nejen grafová databáze OrientDB, ale téměř všechny pokročilejší

databázové systémy (klasické relační i NoSQL) nabízejí možnost implementace

takzvaných uložených procedur. V případě databáze OrientDB jsou nazývány

funkcemi uloženými na serveru (Server-Side Functions). Takovéto funkce či

procedury jsou ukládány přímo v samotné databázi a mohou být spouštěny na

základě dotazu nebo v případě nějaké události. Zpracování dat touto formou přímo na

databázovém serveru má řadu výhod. Není nutné přenášet všechna potřebná data, ale

až konečný výsledek. Vykonávaný kód je odladěn přímo na prostředí, na kterém běží

a může tak být efektivnější. Pokud je to vhodné, může být uložená procedura

spouštěna i bez zásahu z vnějšku databáze (například pomocí trigeru). V případě

grafové databáze OrientDB je možné psát takovéto funkce v jazycích Java, JavaScript,

Ruby, Scala nebo SQL.

66

Vzhledem k možnostem databázového systému OrientDB volat uložené funkce

cestou HTTP požadavku a schopnosti vracet výsledky v podobě JSON dokumentu se

naskýtá i možnost spolupráce webového uživatelského prostředí přímo s databází.

Touto cestou by byl vynechán aplikační server běžně zajišťující veškerou tuto

komunikaci. Takové řešení by za určitých podmínek zřejmě mohlo přinést drobné

zlepšení odezvy. Ovšem z koncepčního pohledu to není příliš šťastným přístupem. Na

straně databáze by v tom případě bylo nutné ošetřit řadu možných výjimečných stavů

a zejména pak i bezpečnostních opatření, o která se běžně aplikační server postará.

Nejen zpracování dat uložených v grafové databázi, ale také vstup dat nových je

principiálně možné provádět více způsoby. Zaprvé cestou aplikačního serveru, který

může skrze zvolené API zapisovat například výsledky práce uživatele, doplňující

údaje k datům v databázi již uloženým nebo kompletní datové soubory určené pro

analýzu. Tato cesta je vhodná spíše pro jednorázově vkládané datové soubory

menšího rozsahu. Naopak druhá možnost vkládání dat přímo cestou importu do

grafové databáze je vhodná zejména pro import rozsáhlých objemů dat a pro často se

opakující přírůstkové vkládání a aktualizace dat.

67

6 Příklady práce využívající linkové analýzy

V této poslední kapitole bude stručně nastíněno využití popisovaných principů a

realizované aplikace k provedení základních úkonů využitelných při tvorbě linkové

analýzy. Z důvodu zjednodušení bude uvažován případ využití linkové analýzy až

v rámci vyšetřování již provedených činů (např. kriminálních). Opačným případem, a

většinou o poznání obtížnějším, je využití linkových analýz k odhalení příprav

zamýšleného činu. Pro zde prezentované příklady byla zvolena data reprezentující

bezhotovostní finanční převody, které jsou typickým příkladem transakčních dat

vhodných pro vytváření linkových analýz. Jedná se o data fiktivní, která v žádném

případě nemají spojitost s reálně provedenými finančními transakcemi. V

testovací databázi55 je uloženo celkem 2123 uzlů reprezentujících bankovní účty a

přes 6800 vazeb reprezentujících bezhotovostní převody peněz.

Stejně jako v praxi i ve zde prezentovaných příkladech je nutné počítat s tím, že

data obsažená v dostupném poznatkovém fondu nemusí zdaleka být úplná. V tomto

konkrétním případě to může být dáno například možností přesunů financí v hotovosti

přímo mezi sledovanými osobami. Případně i stále častěji využívanými převody

pomocí digitálních měn. Jedním ze zásadních problémů komplikujících využití

linkových analýz bývá právě neúplnost dat. Dalšími omezujícími faktory pak mohou

být také neurčitost hranic skupin tvořených v celé síti (obtížné rozhodnutí, který uzel

do skupiny ještě zahrnout a který už ne) a změny sítě v čase (dynamičnost). (33)

Dále bude probráno několik zjednodušených modelových situací, se kterými se lze

běžně při tvorbě linkové analýzy setkat. Nejprve uvažujme případ, kdy jsou známy

konkrétní účty osob podezřelých z trestné činnosti, a je vhodné zjistit, zda v minulosti

došlo k přesunům peněz mezi těmito účty. V případě výpisů v klasické tabulkové

podobě by i tato jednoduchá otázka mohla vést na zdlouhavé prohledávání. V případě

dat v grafové podobě stačí zkusit najít cestu mezi zájmovými uzly. V případě aplikace

OrientLink toho lze dosáhnout jednoduše. Nejprve je nutné vyhledat oba zájmové

účty (jejich číslo zadat do příslušného políčka v levém postranním menu a stisknou

tlačítko „Vyhledat“). Následně lze v grafu označit oba uzly (kliknutím myší při

55 Použitá databáze je obsažena v instalaci OrientDB přiložené k této diplomové práci. Spolu s touto databází jsou pro potřeby testování vloženy ještě další tři vzorové databáze přímo od tvůrců systému OrientDB.

68

stisknuté klávese Ctrl) a z horního menu „Grafové funkce“ zvolit akci

„Hledání nejkratší cesty“. Výsledek tohoto kroku je vidět na obrázku 6.1 (použity čísla

účtů „3171564“ a „77352034“). Následně je možné například blíže prostudovat

jednotlivé transakce. Po přidržení myši nad vazbou se zobrazí okno s vypsanými

všemi jejími atributy (zde datum a částka).

Obrázek 6.1: Výsledek vyhledávání nejkratší cesty, zdroj: autor

Dalším příkladem využití může být snaha o prozkoumání veškerých vazeb

zájmového subjektu. Při zpracování zde použitých finančních transakcí se jedná o

případ, kdy jsou dostupná data o osobě zapojené do vyšetřované události (číslo jejího

účtu) avšak není dostatek dalších poznatků o okolí dané osoby. Zde je dobré opět

postupovat od známého uzlu (lze ho vyhledat stejně jako v předešlém příkladu).

Následně je využita funkce „Hledání sousedů“, která umožní zobrazení všech vazeb až

do zvolené úrovně. Je vhodné začít od vyhledání vazeb pouze několika málo prvních

úrovní. Pokud je diagram stále dostatečně přehledný, je možné nechat zobrazit

sousedy na hlubších úrovních průchodu grafem. Často se takto lze dostat až ke

kompletnímu podgrafu spojenému se zájmovým uzlem, který již nemá další vazby na

zbývající data v databázi (viz obrázek 6.2). Tímto jednoduchým krokem lze získat

69

seznam potenciálně zájmových uzlů (účtů) které je vhodné blíže prozkoumat. U řady

z nich bude samozřejmě určeno, že se jednalo o běžný platební styk bez vazby na

jakékoliv podvodné jednání. Takové uzly je vhodné z grafu ihned odstranit, čímž

může dojít k „odtržení“ celé nezájmové větve.

Obrázek 6.2: Výsledek vyhledávání sousedů zájmového uzlu, zdroj: autor

Posledním příkladem bude využití vyhledávání pomocí nadefinovaného vzoru.

V tomto případě se už jedná o relativně sofistikovaný a v řadě případů mocný a těžko

nahraditelný nástroj. Uvažujme situaci, kdy byla odhalena organizovaná skupina osob

podílejících se na trestné činnosti. Dále byl zjištěn jeden případ kdy si v rámci trestné

činnosti tyto osoby vzájemně přeposílaly finance. Přičemž panuje podezření, že

někteří členové skupiny disponují ještě dalšími bankovními účty, které však dosud

nejsou známy. Je tedy vhodné zkusit zjistit, zda nebyly i tyto další účty použity

stejným způsobem. V takovém případě lze pomocí metody „Pattern Matching“

vyhledat všechny případy ve kterých se vyskytují právě hledané návaznosti uzlů a

hran mezi nimi.

70

Na obrázku 6.3 je zobrazen nadefinovaný vzor, ve kterém dochází k toku financí

mezi dvěma koncovými účty a to dvěma cestami.

Obrázek 6.3: Nadefinování vzoru pro vyhledávání, zdroj: autor

Jedna z cest vede přes jeden mezilehlý uzel a druhá přes dva takovéto tranzitní

uzly. Takto jednoduchá struktura hledaného vzoru zde byla zvolena především

z důvodu přehlednosti výsledků. V praxi by hledaný vzor mohl být o poznání

složitější. Navíc je možné, kromě hodnocení topologie vzoru, pracovat i se všemi

atributy jednotlivých uzlů a vazeb. Například u finančních transakcí je takto možné

hledat ty výskyty vzoru, ve kterých dochází k přesunům částek vyšších než je určitá

suma nebo ke kterým došlo jen v požadovaném časovém období. Stejně tak u uzlů lze

zohlednit třeba zůstatek na daném bankovním účtu. V případě aplikace OrientLink lze

všechny takovéto požadavky definovat do políčka „Podmínka WHERE:“, přičemž je

zde nutné dodržet syntaxi dotazovacího jazyka Extended SQL.

Na obrázku 6.4 je poté vidět výsledek vyhledávání podle takto nadefinovaného

vzoru. Je na něm patrné, že v uložených datech se nachází hned tři skupiny uzlů, mezi

nimiž jsou vazby uspořádány přesně stejně jako v případě vzoru. Nyní by se již

analytik mohl zaměřit na bližší prozkoumání účtů představovaných jednotlivými

71

nalezenými uzly. Při této práci se opět může vrátit k využití dříve popsaných funkcí.

Může si tak například vždy vykreslit všechny sousedy zrovna analyzovaného účtu

nebo zkusit vyhledat zda existují cesty mezi jednotlivými nalezenými podgrafy.

Obrázek 6.4: Výsledek vyhledávání podle vzoru, zdroj: autor

Na těchto příkladech bylo představeno pouze několik málo základních

možností práce při tvorbě linkové analýzy. V případě provádění podrobnějších analýz

se fantazii meze nekladou a je stále možné vymýšlet nové cesty, kudy se lze dobrat k

dalším zajímavým poznatků.

72

7 Závěr

Cílem této diplomové práce bylo zejména zpřístupnit zájemcům náhled do obsáhlé

oblasti analýzy dat majících charakter vzájemně provázaných entit a jejich vazeb.

Popsat „state of the art“ v této oblasti a aktuální trendy vývoje. Spolu s teoretickým

popisem využívaných technologií a principů byl po výběru vhodných nástrojů

navržen a zrealizován prototyp ukázkové webové aplikace. Tato aplikace nemá

ambice stát se sama o sobě funkčním systémem pro provádění linkových analýz.

Jedná se spíše o ukázku základní kostry systému, který bude-li postaven na zde

vybraných technologiích, bude možné ho dle potřeb koncových uživatelů dále rozvíjet

až do podoby komplexního analytického prostředí pokrývajícího často protichůdné

požadavky různých uživatelů. Vzhledem k tomu, že vytvořená aplikace již v současné

podobě splňuje základní požadavky definované před jejím samotným návrhem

(v kapitole 5.1), lze konstatovat, že zvolené technologie, nástroje a frameworky jsou

pro tvorbu uvažovaného analytického prostředí vhodné.

Potenciál skrývající se ve spojení vizualizace a grafových databází může

naznačovat mimo jiného i rychlost současného rozvoje různých prostředků pro tuto

oblast zpracování dat. Například použitá grafová databáze OrientDB prochází

intenzivním vývojem. Pouze za dobu dokončování této práce (zhruba v průběhu dvou

měsíců) bylo vydáno celkem 7 aktualizací release verze. Stejně tak i nástroje určené

přímo pro vizualizaci dat ukládaných v grafových databázích jsou na rychlém

vzestupu.

73

Seznam použité literatury 1. Cuesta, Hector. Analýza dat v praxi. Brno : Computer Press, 2015. ISBN 978-80-251-4361-2.

2. Mazák, Jaromír, a další. Využití analýzy sociálních sítí ve vyšetřování. Praha : Kompetenční

centrum IBM při Katedře sociologie Filozofické fakulty Univerzity Karlovy, 2015.

3. Wijk, Jarke J. van. The Value of Visualization. místo neznámé : Dept. Mathematics and

Computer Science, Technische Universiteit Eindhoven.

4. Nyk, Michal. Určování významnosti vrcholů grafu: PageRank a jeho modifikace. Plzeň :

Západočeská univerzita v Plzni, Katedra informatiky a výpočetní techniky, 2013.

5. Šuták, Petr. Vyhledávání ve velkých grafech. Praha : České vysoké učení technické v Praze,

Fakulta informačních technologií, 2016.

6. Yau, Nathan. Visualize This: The FlowingData Guide to Design, Visualization, and Statistics.

Indianapolis : Wiley Publishing, inc., 2011. ISBN: 978-0-470-94488-2.

7. Yau, Nathan. Data Points: Visualization That Means Something. Indianapolis : John Wile & Sons,

Inc., 2013. ISBN: 978-1-118-46219-5.

8. Brath, Richard a Jonker, David. Graph Analysis and Visualization: Discovering Business

Opportunity in Linked Data. Indianapolis : John Wiley & Sons, Inc., 2015. ISBN: 978-1-118-84584-4.

9. Doc. RNDr. Petr Hliněný, Ph.D. Teorie Grafů. Brno : Masarykova Univerzita, 2008.

10. Černý, Jakub. Základní grafové algoritmy. Praha : MFF UK, 2010.

11. Philippe Jégou, Samba Ndojh Ndiaye. Discrete Mathematics - On the notion of cycles in

hypergraphs. ScienceDirect. [Online] 2009.

http://www.sciencedirect.com/science/article/pii/S0012365X09003446.

12. Holubová, Irena, a další. Big Data a NoSQL databáze. Praha : Grada Publishing, a.s., 2015.

ISBN: 978-80-247-5466-6.

13. Fowler, Martin. http://martinfowler.com. [Online] 16. 11 2011.

http://martinfowler.com/bliki/PolyglotPersistence.html.

14. Robinson, Ian, Webber, James a Eifrem, Emil. Graph databases. Sebastopol : O'Reilly, 2013.

ISBN: 978-1-449-35626-2.

15. Chang, Fay, a další. Bigtable: A Distributed Storage System for Structured Data. místo

neznámé : Google, Inc., 2006.

16. J.A. Bondy, U.S.R. Murty. Graph Theory with Applications. [Online] 1982.

http://book.huihoo.com/pdf/graph-theory-With-applications/. ISBN: 0-444-19451-7.

17. Doc. RNDr. Petr Hliněný, Ph.D. Zaklady teorie grafů pro (nejen) informatiky. Brno :

Masarykova univerzita, 2010.

18. Večerka, Arnošt. Grafy a grafové algoritmy. Olomouc : Univerzita Palackého, 2007.

19. Historie teorie grafů. [Online] 2010. http://teorie-grafu.cz/uvod/historie.php.

20. Kovář, Petr. Teorie grafů. Matematika pro inženýry 21. století. [Online] 2012.

http://mi21.vsb.cz/modul/teorie-grafu.

74

21. Albert-László Barabási, Gabriele Musella, Mauro Martino, Nicole Samay, Kim Albrecht,

Márton Pósfai. Network Science Book. Network Science Book. [Online]

http://barabasi.com/networksciencebook/.

22. Page, Lawrence, a další. The PageRank Citation Ranking:. místo neznámé : Stanford InfoLab,

1999.

23. Prohledávání do šířky. Algoritmy.net. [Online] INFO WEB s.r.o., 2015.

https://www.algoritmy.net/article/1399/Prohledavani-do-sirky.

24. Prohledávání do hloubky. Algoritmy.net. [Online] INFO WEB s.r.o., 2015.

https://www.algoritmy.net/article/1378/Prohledavani-do-hloubky.

25. Jirovský, Lukáš. Vybrané problémy z teorie grafů. Bakalářská práce. Praha : Univerzita Karlova

v Praze, Matematicko-fyzikální fakulta, 2008.

26. Vachler, M. Využití grafové databáze pro hledání vlakových spojů. Bakalářská práce. Brno :

Mendelova univerzita v Brně, 2014.

27. Schaefer, Chris, Ho, Clarence a Harrop, Rob. Pro Spring. : Apress, 2014. ISBN: 978-1-430-

26151-3.

28. Johnson, Rod a kol. Spring Framework Reference Documentation. Spring Framework

Reference Documentation. [Online] 2016. http://docs.spring.io/spring/docs/current/spring-

framework-reference/htmlsingle/.

29. Online dokumentace OrientDB. [Online] 2016. http://orientdb.com/docs/master/.

30. Apache License, Version 2.0. The Apache Software Foundation. [Online] 2004.

http://www.apache.org/licenses/LICENSE-2.0.html.

31. Zakas, Nicholas C., McPeak, Jeremy a Fawcet, Joe. Ajax Profesionálně. Brno : Zoner Press,

2007. ISBN: 978-80-86815-77-0.

32. Meeks, Elijah. D3.js in Action. Shelter Island : Manning Publications Co., 2015. ISBN:

9781617292118.

33. Sparrow, Malcolm K. The application of network analysis to criminal intelligence: An

assessment of the prospects. Cambridge : Kennedy School of Government, Harvard University,

1991.

34. Thelwall, Michael Arijan. Link Analysis: An Information Science Approach. Boston : Elsevier

Academic Press, 2004. ISBN: 9780120885534.

35. Daniel Keim, Gennady Andrienko, Jean-Daniel Fekete, Carsten Görg, Jörn Kohlhammer, Guy

Melancon. Visual Analytics: Definition, Process and Challenges. místo neznámé : Springer, 2008.

75

Seznam obrázků Obrázek 2.1: Proces vizuální analýzy .................................................................................................. 3

Obrázek 2.2: Linková analýza finančních toků ................................................................................... 6

Obrázek 3.1: Příklady běžně používaných grafů ................................................................................ 8

Obrázek 3.2: Graf z oboru teorie grafů skládající se z uzlů a hran ..................................................... 9

Obrázek 3.3: Dvě možnosti vizualizace protichůdných rovnoběžných hran .................................... 10

Obrázek 3.4: Srovnání prostého grafu (vlevo) a multigrafu (vpravo) .............................................. 10

Obrázek 3.5: Hypergraf .................................................................................................................... 11

Obrázek 3.6: Dvě možnosti nahrazení hypergrafu hranami prostého grafu ................................... 11

Obrázek 3.7: Příklad uložení grafových dat v relační databázi......................................................... 13

Obrázek 4.1: Jednotlivé metriky uzlů grafu vypočítané pomocí aplikace Analyst’s Notebook........ 24

Obrázek 4.2: Příklad izomorfních grafů ............................................................................................ 26

Obrázek 5.1: Uživatelské rozhraní IBM i2 Analyst’s Notebook ........................................................ 34

Obrázek 5.2: Webové prostředí OrientDB Studio ............................................................................ 35

Obrázek 5.3: Uživatelské rozhraní aplikace Gephi ........................................................................... 36

Obrázek 5.4: Prostředí Tovek Tools při použití modulu Vizualizace ................................................ 37

Obrázek 5.5: Schéma znázorňující základní stavební prvky prostředí OrientLink ........................... 39

Obrázek 5.6: Přehled základních modulů Spring Frameworku ........................................................ 42

Obrázek 5.7: Příklad využití rozdělení třídy do více clusterů ........................................................... 45

Obrázek 5.8: Srovnání tradičního modelu webové aplikace a aplikace využívající AJAX ................. 50

Obrázek 5.9: Příklad struktury HTML dokumentu pomocí DOM ..................................................... 52

Obrázek 5.10: Diagram přechodů mezi stránkami aplikace OrientLink ........................................... 55

Obrázek 5.11: Stránka zobrazující dostupné grafové databáze ....................................................... 56

Obrázek 5.12: Stránka pro import uživatelských dat ....................................................................... 57

Obrázek 5.13: Prostředí pro zpracování linkové analýzy ................................................................. 58

Obrázek 5.14: Definice vzoru pro hledání v grafové databázi ......................................................... 60

Obrázek 5.15: UML diagram tříd jádra aplikace OrientLink ............................................................. 61

Obrázek 5.16:Přehled všech Java balíčků a tříd aplikačního serveru OrientLink ............................. 62

Obrázek 6.1: Výsledek vyhledávání nejkratší cesty .......................................................................... 68

Obrázek 6.2: Výsledek vyhledávání sousedů zájmovéhu uzlu ......................................................... 69

Obrázek 6.3: Nadefinování vzoru pro vyhledávání .......................................................................... 70

Obrázek 6.4: Výsledek vyhledávání podle vzoru .............................................................................. 71

Seznam tabulek Tabulka 2.1: Výpis finančních transakcí ............................................................................................. 6

Tabulka 5.1: Srovnání modelů relační databáze, dokumentové databáze a OrientDB v režimu

dokumentového modelu .................................................................................................................. 46

Tabulka 5.2: Srovnání modelů relační databáze, grafové databáze a OrientDB v režimu grafového

modelu ............................................................................................................................................. 47

Příloha č. 1

Návod na zprovoznění aplikace OrientLink

Jelikož je aplikace OrientLink, vytvořená v rámci této diplomové práce,

realizována ve formě webového prostředí, je pro její spuštění nutné provést několik

kroků.

Zaprvé je třeba nainstalovat webový server, na kterém bude celá aplikace

provozována. V průběhu vývoje byl využíván volně dostupný server Apache Tomcat,

proto je právě tento server přiložen k aplikaci (verze 8.5.4). Pro funkci tohoto

webového serveru je nutné mít na PC nainstalováno také běhové prostředí Java (JRE)

ve verzi 7 nebo vyšší. Samotná instalace Apache Tomcat se spustí souborem

apache-tomcat-8.5.4.exe. V průběhu instalace není třeba zasahovat do nastavení.

Pokud proběhne instalace v pořádku, je již možné spustit webový server Tomcat

pomocí manažeru (Tomcat Monitor), který naleznete v nabídce Start. Druhou

možností je spuštění serveru přímo souborem Tomcat8.exe, který se nachází ve složce

/bin/ v místě instalace serveru.

(např. c:\Program Files\Apache Software Foundation\Tomcat 8.5\bin\)

Následně je nutné na právě nainstalovaný server nasadit (deploy) aplikaci

OrientLink, která je přiložena ve formě war balíčku (soubor OrientLink.war). To lze

provést dvěma způsoby. První možností je soubor OrientLink.war nakopírovat přímo

do složky /webapps/ (také se nachází v instalační složce Tomcat). Poté je při dalším

startu Tomcat serveru tento balíček extrahován a aplikace je připravena k použití.

Druhou možností je nasazení aplikace pomocí webového prostředí pro správu

Tomcat serveru, které je dostupné na adrese http://localhost:8080/manager/html.

Pro tuto variantu je nutné při instalaci Tomcat serveru zadat administrátorské

uživatelské jméno a heslo, kterým se budete přihlašovat při přístupu do webového

prostředí pro správu serveru. Zde naleznete položku „WAR file to deploy“, kde je

možné zvolit příslušný soubor (OrientLink.war) a pomocí tlačítka „Deploy“ ho nasadit

na server.

Nyní už by byla aplikace OrientLink funkční, avšak pro její plnohodnotný provoz

je dále nutné spustit databázový server OrintDB. Ten je přiložen v komprimované

podobě v balíčku orientdb-comunity.zip. Po jeho rozbalení je možné ho spustit

souborem server.bat (v adresáři /orientdb-comunity/bin/). Po ukončení práce

s aplikací OrientLink lze databázový server vypnout, což lze provést souborem

stopServer.bat.

Pokud se vám předešlé kroky podařily, můžete již vstoupit do webové aplikace

OrientLink na adrese http://localhost:8080/OrientLink/. Celý tento instalační proces je

standardně záležitostí administrátora a běžný uživatel ho nemusí řešit. Ten má

aplikaci vždy přístupnou na požadované webové adrese.

Příloha č. 2

Obsah přiloženého CD

Přílohou této diplomové práce je CD, které obsahuje celý projekt realizované

aplikace OrientLink (projekt pro IDE Eclipse). Dále jsou na CD uloženy potřebné

instalační soubory nutné pro běh aplikace OrientLink (Apache Tomcat, OrientDB) a

aplikace samotná i ve formě war balíčku připraveného k nasazení na webový server.