nav line

Relační a nerelační datový model v kontextu business intelligence

Business Intelligence přináší cenné poznatky, umožnuje kvalitnější interpretaci a prezentaci a zároveň může pomoci v lepším rozhodování, což může v konečném důsledku znamenat konkurenční výhodu. Jakou roli v tomto kontextu hraje relační a nerelační databátový model?

prvním díle našeho seriálu jsme prošli vývojem databázových systémů. Historie nám ukázala, jak tato oblast reagovala na stále náročnější požadavky nejen odborné společnosti. S nástupem počítačů a internetu došlo k velkému nárůstu analyzovatelných dat. Tato data mají dnes stále větší význam a hodnotu. Vhodná analýza přináší cenné poznatky, umožnuje kvalitnější interpretaci a prezentaci a zároveň může pomoci v lepším rozhodování, což může v konečném důsledku znamenat konkurenční výhodu. Náš pohled na výhody a problémy již zmíněných technologií bude v závěru dán do kontextu a souvislosti s pojmy webové integrace a systémů pro podporu rozhodování (business intelligence). Tento kontext by měl posloužit k lepšímu pochopení problematiky. Nejprve si ale popíšeme několik důležitých pojmů.

Vertikální a horizontální škálování

Škálování je odpověď na otázku, jak zvýšit výkon, ale zároveň zachovat hospodárnost v reakci na vývoj potřeb systému. Vertikálním škálováním se myslí kvalitativní změna stávajících prvků systému (upgrade/downgrade hardwaru počítače, změna propustnosti síťového připojení, apod.). Horizontálním škálováním se myslí kvantitativní změna prvků systému (při vysoké zátěži může pomoci se zpracováním dat další počítač).

Transakce

Transakce je nedělitelný souhrn operací, který se buď provede celý najednou, nebo se neprovede žádná z operací a entity zůstanou v původním stavu (např. peněžní převod v bance). Tento přístup zajišťuje konzistenci a integritu dat v čase.

Relační databázový model

Pojem „relační“ databázový model souvisí s teorií množin. Základním konstruktorem relačních databází jsou relace (tabulky), které obsahují záznamy (řádky). Většina relačních databází může být horizontálně škálována, tj. rozložena na více uzlů (strojů), což však přináší určitá uskalí.

Pro vytvoření vztahů (relací) mezi daty se využívá tzv. cizích klíčů. Jednotlivé tabulky je možné na základě definovaného vztahu spojit do jednoho logického celku (operacemi JOIN). Spojování tabulek velkých horizontálně škálovaných databazí může být drahé a pomalé, neboť finální spojení relací musí být uskutečněno na jednom uzlu a navíc může docházet k velkému přenosu dat mezi jednotlivými uzly databázového systému. Relační databáze podporují transakce. Vlastnosti transakcí v relačním modelu jsou atomicita, konzistence, izolovanost, trvalost (ACID – vysvětleno níže). Bezpečnost, konzistence a integrita dat v čase je v mnoha případech vykoupena nižším výkonem databáze.

Ne-relační databázový model

Označován jako NoSQL, prezentován v začátcích jako No-SQL (ne SQL), později spíše jako Not-only SQL (nejen SQL). Sám autor Carlo Strozzi v roce 2010 namítl, že označení NoSQL je značně nepřesné a navrhl presnější označení NoREL jako nerelační. NoSQL je nový databázový koncept, který umožňuje “rychlé a efektivní zpracování kolekcí dat se zaměřením na výkon, spolehlivost a agilnost” (zdroj 1).

V počátcích byly NoSQL databáze pravým opakem relačních databází. Zaměřené na dostupnost s co nejkratší odezvou, s možností provozovat je na komoditním hardwaru, bez možnosti definovat strukturu dat, bez podpory vztahů jednotlivých záznamů a bez možnosti provádět spojovácí operace (operace JOIN). Relační databáze využívá transakce s důrazem na ACID, NoSQL využívá u transakcí přístup BASE (vysvětleno níže). Tento přístup není tak striktní jako ACID. Dovoluje dočasnou nekonzistenci dat pro zvýšení dostupnosti a výkonu. Jelikož neblokuje zápis (na rozdíl od transakcí v ACID), projevuje se rychlejší odezvou, byť za cenu dočasné nekonzistence v uložených datech.

K popisu základních typů NoSQL databází (dokumentově orientované, typu klíč-hodnota, typu BigTable, grafové databáze a typ časových řad – time series database), jakož i k výhodám a problémům se dostaneme v přístím díle zaměřeném na Big Data.

S vysokou dostupností a distribuovatelností dat u NoSQL databází velmi úzce souvisí tzv. CAP teorém.

ACID vs. BASE

V předchozí části jsme se dozvěděli, že relační i nerelační databáze využívají jiný přístup k transakcím. Rozdělení přístupů na ACID a BASE však není striktně závislé na druhu databázového modelu. V dnešní době se u některých databází přístupy prolínají (některým relačním databázím je možné nastavovit úroveň “izolovanosti” transakce, některé NoSQL databáze umožňují transakce s vlastnostmi ACID a definece vztahů).

Akronym ACID:

Atomicity (atomicita) – transakce buď proběhne celá, nebo vůbec ne, tj. je atomická.
Consistency (konzistence) – transakce převede databázi z jednoho konzistentního stavu do jiného. Je zaručen zápis pouze platných dat bez poručení integritních omezení.
Isolation (izolovanost) – změny v rámci jedné transakce před jejím dokončením nejsou viditelné ostatním transakcím.
Durability (trvalost) – změny úspěšně dokončené transakce jsou v databázi uloženy natrvalo.

Akronym BASE (zdroj 2):

Basically Available (v základu k dispozici) – Funguje v podstatě po celou dobu…
Soft-State – … nemusí být po celou dobu konsistentní…
Eventual consistency – …ale nakonec bude v nám nějakém známém stavu.

Pěkné a přehledné srovnání obou principů je uvedeno zde (zdroj 2):

ACID BASE
silná konzistence
izolovanost
orientace na komit
vnořené transakce
dostupnost?
konzervativní (pesimistické)
složitá evoluce (např.: schématu)
slabá konzistence (stará data)
dostupnost na prvním místě
přibližné odpovědi jsou OK
jednodušší, rychlejší
dodávka dat „jak to jen půjde“
agresivní (optimistické)
jednodušší evoluce

CAP, též Brewerův teorém (zdroj 3)

CAP teorém rozděluje databáze do tří skupin. Brewer říká, že distribuovaný systém může splňovat maximálně dvě ze tří vlasností:

Consistency (konzistence) - v jeden okamžik jsou na všech uzlech dostupná stejná data
(neplést s konzistencí v popisu ACID vlastností databáze).
Availability (dostupnost) - každý požadavek je obsloužen, buď úspěšně nebo neúspěšně v zanedbatelně krátkém čase.
Partition tolerance (odolnost vůči rozdělení) - funkční navzdory chybám sítě nebo výpadkům/odstávce jednotlivých uzlů.

Z tohoto vyplývá, že většina relačních databází jsou typu CA, kdežto NoSQL databáze jsou více či méně typu AP.

Relační vs. nerelační model

Z uvedených vlastností plyne, že relační databáze je vhodné použít všude tam, kde pracujeme s daty se strukturou s minimalními změnami. Rozdělení relačních databází na více částí je možné, ale velmi neefektivní z důvodu samotných vlastností relačních databází (provázanost dat, JOINy a ACID transakce, blokování při zápisu). Vzhledem k horším vlastnostem při horizontálním škálování se doporučuje pracovat s přijatelným objemem dat vzhledem k výkonu HW a hlavním požadavkem by měla být konzistence dat. Při horizontálním škálování je dobré dělit data tak, aby mezi uzly měla mezi sebou co nejméně sdílených vazeb a byla co nejvíce samostatná a nezávislá. Logicky provázaná data by měla být uchovávána na jednom uzlu.

Naproti tomu NoSQL databáze dokážou velmi rychle přistupovat k datům, ale za cenu případné nekonzistence mezi uzly. Je možné jejich téměř neomezené horizontální škálování a zachování lineárního růstu výkonu. Jelikož dochází k prudkému nárůstu dat, která je potřeba ukládat, analyzovat a zpracovat je, je tato vlastnost velmi důležitá.

Představili jsme si relační a NoSQL databázové modely s popisy jejich výhod a nevýhod. Otázka, zda relační nebo NoSQL databáze, je špatná. Tento popis vlastností měl pouze ukázat výhody a problémy jednotlivých přístupů a nastínit, jak vytěžit z obou přístupů co nejvíce. NoSQL databáze zatím nedokážou plnohodnotně nahradit relační databáze, ale nabízejí spoustu nových směrů pro práci s daty.

Databáze v BI

V úvodu článku jsme se zmínili o systémech pro podporu rozhodování. Do tohoto systému lze zahrnout velké množství nástrojů a systémů. Může se jednat o plánování podnikových zdrojů (ERP), účetní sytémy, řízení vztahů se zákazníky (CRM), záznamy o pohybu uživatelů na webu nebo o jinak pro firmu důležitá a analyticky zajímavá data. Data z těchto systémů můžeme vhodně transformovat pro následnou analýzu a případně doplnit analyzovanými daty s přidanou hodnotou.

Je nutné uvědomit si, že nad produkčními daty bychom nikdy neměli provádět analýzu. Produkční data jsou určena pro rychlý přístup k detailním informacím (objednávky, faktury, zboží,…) a k požadovaným operacím (aktualizace, vložení nového záznamu,…). Rozdíl je i v přístupu. Do produkční databáze může přistupovat zároveň několik tisíc uživatelů, k analytickým datům jen omezené množství lidí. Navíc tato data nebývají zpravidla již měněna a mohou být vhodně doplňována. Při analýze chceme mít možnost pružně měnit kritéria a i složité výsledky mít téměř okamžitě k dispozici.

Způsob, jakým je zacházeno s produkčními daty, je nazýván OLPT (online transaction processing), naproti tomu analytický přístup je označován OLAP (online analytical processing). Základním principem této technologie je OLAP kostka (multidimenzionální tabulka) umožňující rychle a pružně měnit jednotlivé dimenze.

Online analýza se dá vhodně využít ke dvěma základním potřebám. K reportingu a zobrazování analytických dat o firmě nebo v aplikacích reagujících na momentální požadavky uživatele. Obě použití si představíme na konkrétních příkladech.

Analytický proces v dopravním podniku

Představme si firmu zajišťující přepravu, která má v každém autě zabudovaný přístroj pro jeho monitoring. Základní údaje doplníme geolokačními údaji. Můžeme sledovat kromě spotřeby a počtu ujetých kilometrů i dopravní situace v jednotlivých lokalitách v závislosti na čase nebo zhoršený technický stav vozidla v případě vyšší spotřeby pohoných hmot na počet ujetých kilometrů. V ad hoc reportech dokážeme pružně reagovat a zachytit nenadálé výkyvy oproti běžnému stavu. Můžeme implementovat systém notifikací a další procesy automatické reakce.

Doporučení produktů analýzou sociálních sítí

Produktová data online obchodu můžeme rozšířit o data chování uživatelů na sociálních sítích, což je stále oblíbenější praktika (popis dolování dat ze sociálních sítí není předmětem tohoto článku). Na základě definovaných vztahů uživatelů máme možnost nabídnout našim klientům i produkty blízkých přátel. Navíc vhodnou analýzou můžeme získat přehled o chování a aktivitách našich konkurentů, můžeme vhodněji cílit reklamní kampaně, personalizovat reklamní sdělení, apod.

V prvním příkladu, kde pracujeme s geolokačními informacemi, je vhodné využití databáze s implementovanými geolokačními funkcemi (např.: nerelační dokumentově orientovaná databáze MongoDB). Pro zpracování dat ze sociálních sítí se pak skvěle hodí nerelační grafové databáze. Pro oba prezentované příklady se nabízí kromě produktové relační databáze i využití nerelační databáze pro potřeby rozšířené analýzy i některých vnitropodnikových procesů.

Závěrem

Podobných příkladů s implementací kombinace relačních a NoSQL databází lze uvést daleko více. Pro ilustraci je to však myslím dostatečné. O výše zmíněných druzích nerelačních databází, stejně jako o dalších tématech zaměřujících se na pojem Big Data si více řekneme příště.

Zdroje:

Daniel G. McCreary and Ann M. Kelly Making sense of NoSQL: a guide for managers and the rest of us. (Shelter Island: Manning, 2013. ISBN 978-161-7291-074).
Christof Strauch, NoSQL Databases, Hochschule der Medien, (Stuttgart, http://www.christof-strauch.de/nosqldbs.pdf)
Dr. Eric A. Brewer, Towards Robust. Distributed Systems (July 19, 2000, https://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf)
www.wikipedia.org
www.root.cz

Ohodnoťte článek

Relační a nerelační datový model v kontextu business intelligence
Seriál
Svět databází a webová integrace

Související články

Vyhledávání na blogu

Webová integrace

Webová integrace jako nová oblast pro business „velkých" webových agentur.

o webové integraci

Profily blogujících