Upload
others
View
1
Download
1
Embed Size (px)
Citation preview
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.