Přechod z relačního světa do světa grafů vyžaduje posun v uvažování a pohledu na data. I když grafy jsou často mnohem intuitivnější než tabulky, postřehl jsem stále opakující se chyby u lidí, kteří s modelováním grafů začínají. V tomto článku se podíváme na jednu z nejčastějších chyb – modelování obousměrných vztahů, a nakonec si ukážeme reálný příklad, ve kterém budeme nadále v seriálu pokračovat.

Jednosměrové vztahy

Vztahy v Neo4j musí být nějakého typu, který dává vztahu sémantický význam a také musí mít určený směr. Právě ten vyjadřuje smysl mezi entitami. Jinými slovy, vztah je nejednoznačný bez určení směru vztahu.

Například následující graf ukazuje, že Česká republika porazila (DEFEATED) Švédsko v ledním hokeji. Kdyby se směr vztahu obrátil, Švédové by byli mnohem šťastnější. Bez směru vůbec nevíme, kdo je vítězem, a proto je takový vztah nejednoznačný.

Všimněte si, že z existence tohoto vztahu vyplývá vztah opačném směru, jak je ukázáno níže v dalším grafu. Jedná se o velmi častý případ. Ještě jednou si popíšeme na jiném příkladu, že film Pulp Fiction režíroval (DIRECTED) Quentin Tarantino znamená také, že Quentin Tarantino je režisérem (IS_DIRECTOR_OF) filmu Pulp Fiction. A tímto by mohlo dojít k velmi mnoho párovým vzhům.

Všimněte si, že z existence tohoto vztahu vyplývá vztah opačném směru, jak je ukázáno níže v dalším grafu. Jedná se o velmi častý případ. Ještě jednou si popíšeme na jiném příkladu, že film Pulp Fiction režíroval (DIRECTED) Quentin Tarantino znamená také, že Quentin Tarantino je režisérem (IS_DIRECTOR_OF) filmu Pulp Fiction. A tímto by mohlo dojít k velmi mnoho párovým vzhům.

Právě této chyby se lidé často dopouštějí při modelování grafu v Neo4j a vytváří obousměrné vztahy. Vzhledem k tomu, že jeden vztah vyjadřuje druhý (symetrická relace), je to nehospodárné jak z hlediska prostoru, tak z průchodu (traverzování) grafem. Neo4j umožňuje procházet vztahy v obou směrech, takzvaně i proti směru hrany. Navíc díky způsobu, jakým Neo4j data ukládá, nezávisí rychlost průchodu vztahem na jeho směru.

Obousměrné vztahy

Některé vztahy jsou přirozeně obousměrné. Klasickým příkladem je Facebook nebo vztah přátelství. Vztah je vzájemný – když s někým přátelíte, tak se on přátelí s vámi (možná tedy… ). V závislosti na tom, jak se díváme na model grafu, bychom o takovém vztahu mohli říci, že je obousměrný neboli neorientovaný.

Příkladem GraphAware a NeoTechnology jsou partnerské společnosti. Jelikož se jedná o vzájemný vztah, mohli bychom modelovat obousměrný neboli neorientovaný vztah.

Ale právě toto není možné v Neo4j – každý vztah musí mít počáteční a koncový uzel. Začátečníci se tak často uchylují k následujícímu modelu, který trpí přesně stejným problémem jako výše zmíněný model ledního hokeje s nadbytečným vztahem.

Neo4j API umožňuje vývojářům zcela ignorovat směrovost vztahů při psaní dotazů, pokud si to přejí. Například v jazyce Cypher by vyhledání všech partnerských společností s NeoTechnology mohlo vypadat takto:

MATCH (neo)-[:PARTNER]-(partner)

Výsledek by byl stejný jako sloučení výsledků z těchto dvou různých dotazů:

MATCH (neo)-[:PARTNER]->(partner) and MATCH (neo)<-[:PARTNER]-(partner)

Proto je správný (nebo alespoň nejúčinnější) způsob modelování partnerských vztahů pomocí jediného PARTNER vztahu s určením libovolného směru.

Shrnutí

Vztahy v Neo4j lze procházet v obou směrech se stejnou rychlostí. Navíc směrovost může být zcela ignorována. Z tohoto důvodu není třeba vytvářet dva různé vztahy mezi entitami, pokud mají hrany opačného směru stejný význam.

Metodika modelování grafové databáze

V následujících článcích si ukážeme návrh, implementaci a testování grafové databáze Neo4j na projektu BestPartyToday (jedná se celosvětový pártylist, který nabízí detailní statistiky k akcím). V současné době se v projektu používá databáze MySQL, která obsahuje desítky milionů záznamů, takže nás také čeká přesunutí dat z relačního databázového úložiště do grafového. Ovšem v dnešním příspěvku si pouze namodelujeme podobu grafové databáze z vybraných tabulek a atributů současné struktury MySQL databáze.

O konceptuálním návrhu grafové databáze se pojednává jako o tzv. whiteboard friendliness. Pro rychlé promítnutí všech myšlenek a postřehů, které byly vzneseny během návrhového brainstormingu, postačí pouze flipchart. Výsledný nákres je velmi jednoduché následně prezentovat ostatním projektovým skupinám (retail department, accound managers, sales managers atd.), které nemají technické vzdělání. Pochopení návrhu pro ně už není překážkou, jelikož nákres je možné jednoduše přizpůsobit do podoby reálného života.

Realizace konceptuálního modelu

Na fotografii finálního návrhu grafové databáze pro projekt BestPartyToday je využito pěti nejvýznamnějších tabulek současné relační databáze, které jsou reprezentovány ikonami znázorňující nodes a směrovými šipkami prorelationships. Skrze entity (nodes a relationships) budeme procházet graf a získávat požadovaná data, která budou zpracována a zobrazena uživateli aplikace. Jejich význam je popsán níže v tabulce Přehled entit grafového modelu.

Přehled entit grafového modelu

Článek vyšel na základě spolupráce s Michalem Bachmanem. Více na http://graphaware.com.

Zdroje:

• EIFREM, E. (2012). Introduction to Neo4j http://www.youtube.com/watch?v=tyNWT85Z0mc