Vizualizace dat - Vizualizace dat uložených v Cloudu na webu

Vizualizace dat je prezentování dat v obrázkovém či grafickém formátu.

Umožňuje lidem, kteří se na základě stavu těchto dat mají nějakým způso-bem rozhodovat, lépe uchopit jejich koncept a charakter.

S pomocí interaktivní webové aplikace má člověk možnost zobrazit data, která jsou jinak například uložena v surové podobě v databázi kdesi na Cloudovém serveru. Tato data může přes tuto aplikaci interaktivně filtrovat tak, aby viděl opravdu pouze ta data, která ho zajímají, například v podobě grafu.

Koncept vizualizace dat je velice důležitý, protože umožňuje lidskému mozku zpracovat informace pomocí diagramů či grafů, což je především při velkém množství komplexních dat mnohem jednodušší a přehlednější než kvanta tabulek.

Takový graf dokáže člověku pomoci snadněji identifikovat oblast, která si zaslouží větší pozornost. Díky tomu lze pak najít hlavní faktory, které mo-hou ovlivňovat stav daných dat. Zároveň je v některých případech možné na základě viditelného průběhu funkce v grafu předpovídat i jeho budoucí prů-běh, což se v mnoha oblastech dá využít.

Datová vizualizace mění způsob, jak analytici s daty pracují. Očekává se, že budou schopni reagovat na problém rychleji. Jsou schopni se dívat na data jinak, s větší představivostí a dokážou odhalit mnohem více, než kdyby se dívali pouze do rozsáhlých tabulek s číselnými informacemi.

Před implementací nové technologie pro vizualizaci dat, je důležité vzít v potaz několik kroků. Nejen, že je nutné přesně rozumět datům, která se mají prezentovat, ale také je potřeba znát cíle a potřeby konečných uživatelů těchto dat. Proto je potřeba, jak bylo řečeno [1], v přípravě zohlednit násle-dující:

 Porozumět datům, která se snažím vizualizovat, včetně jejich veli-kosti a kardinality (unikátnost hodnot ve sloupci)

 Určit, co se snažím zobrazit a jaké informace chci předávat

 Znát konečného uživatele a vědět jak bude zpracovávat zobrazené informace

 Použít takové zobrazení, které bude předávat informace co nejlepším a zároveň nejjednodušším způsobem

Jakmile jsou tyto kroky týkající se typu dat a konečných uživatelů splněny, je třeba se připravit na velikost dat, se kterými se má pracovat. Velká data s sebou přináší nové výzvy, protože velké objemy a různorodost je nutné vzít v potaz.

Jednou z největších výzev je rozhodování, která vizualizace je pro konkrétní případ nejvhodnější.

Všechny webové stránky jsou ve své podstatě interaktivní. Uživatelé se v nich navigují pomocí klikání myší a scrollováním, aby našli informace, stahovali dokumenty nebo třeba vyplňovali formuláře. V tomto kontextu však interaktivita znamená specifickou věc, kdy vlastnost webové aplikace jako je mapa, diagram nebo animace může být manipulována uživatelem bez potřeby znovu načítat webovou stránku.

Těmto typům vlastností se říká driven graphics. Hlavním účelem data-driven graphics je zobrazení komplexních informací tak, aby byly srozumi-telné a snadno analyzovasrozumi-telné. Tento typ vizualizací je vhodný, když je za-potřebí prezentace komplexních dat, které uživatel potřebuje analyzovat.

Běžnými nevýhodami data-driven graphics můžou být následující:

 Mohou být drahé na vytvoření

 Nemusí být dostatečně flexibilní, pokud se změní datový model

 Těžko editovatelné

 Těžko optimalizovatelné pro mobilní zařízení

 Mohou se snadno „rozbít“, pokud do nich vstupují nesprávná data Uživatel se k jejich použivání musí naučit jejich práci s jejich rozhraním

16 1.2 Dostupné technologie

S tím jak jde doba, uživatelé očekávají od webových aplikací, že budou schopny pracovat téměř na stejné úrovni co se výkonu a interaktivity týče, jako desktopové nebo mobilní aplikace. Samozřejmě se také od vývojářů očekává, že budou schopni takovou aplikaci rychle a efektivně rozšiřovat a především udržovat. Je proto zapotřebí vybrat si vhodnou technologii při jejím vytváření, která by měla zaručit, že s časem nebude příliš klesat její podpora a popularita. Často je takových technologií více, kde každá plní určitou část práce, pro kterou byla vytvořena a poté spolu spolupracují a tvoří takzvaný technologický stack.

Pro tuto práci byl vybrán MERN stack, což je zkratkou pro technologie MongoDB, Express, React a Node.js. To co mají tyto technologie společné je JavaScript a jeho následníky jako ES6, Typescript nebo JSX. Dříve bylo využití JavaScriptu značně limitující, když víceméně pouze přidával vizuál-ní efekty na webové stránce. V dnešvizuál-ní době je však JavaScript již tak rozší-řený, že jej vývojáři používají také pro tvorbu aplikační logiky a pro práci s databází.

Hlavním důvodem pro volbu MERN stacku byl fakt, že obsahuje právě Re-act, což je hlavní frontendový prvek. React je knihovna vytvořená Faceboo-kem umožňující vývoj interaktivních a reaktivních uživatelských rozhraní ve webové aplikaci. Rozděluje front end aplikace na jednotlivé komponenty, z nichž každá může udržovat svůj vlastní stav.

Komponenty jsou v Reactu implementovány pomocí JSX, což je syntaktic-ké rozšíření pro JavaScript. React využívá faktu, že logika vykreslování je úzce spjata ostatní logikou uživatelského rozhraní: jak se zpracovávají udá-losti, jak se v čase mění stav a jak se data připravují k vykreslení. Na místo toho, aby se uměle oddělovaly technologie tak, aby logika webu a značko-vací jazyk byly v rozdílných souborech, React je volně spojuje do kompo-nent, které obsahují obojí.

Obrovskou výhodou při vytváření rozhraní v Reactu je široká škála kniho-ven obsahující komponenty, které byly již vytvořeny jinými vývojáři. Je to jeden z důvodů proč je vhodné zvolit populární technologii jako je React,

17 s těmito daty schopna efektivně nakládat.

1.3.1 Relační databáze

Jedním velkým typem databáze jsou takzvané relační databáze, kterým se také říká SQL databáze. Mezi nejznámějšími zástupci tohoto typu jsou:

 Microsoft SQL Server

 Oracle Database

 MySQL

 PostgreSQL

V relačních databázích jsou data reprezentována pomocí tabulek a řádků.

Jsou založeny na základě odvětví algebry známém jako relační algebra.

Jak zmiňuje Keith D. Foote [6], relační databáze používají SQL(Structured Query Language), což z nich dělá správnou volbu pro aplikace, ve kterých je obsaženo řízení několika transakcí. Struktura relační databáze umožňuje propojení informací z různých tabulek použitím cizích klíčů či indexů, které slouží i unikátní identifikaci jednotlivých dat v rámci tabulky. Další tabulky se mohou na takový cizí klíč odkazovat, čímž vznikne chtěné propojení dat mezi tabulkami. Takové vlastnosti jsou velmi užitečné v aplikacích, které se silně soustředí na analýzu dat.

Jsou-li vysoké nároky na databázi v podobě složitých dotazů, transakcí a častých analýz, potom je relační databáze vhodnou volbou. V případě vel-kého množství transakcí je důležité, aby tyto transakce proběhly spolehlivě.

Zde přichází v potaz sada vlastností, které tuto spolehlivost u relačních da-tabází zajišťují, známá jako ACID.

 Atomicita

 Konzistence

 Izolovanost

 Trvalost

Tyto vlastnosti zaručují, že databázové transakce proběhnou v pořádku a nepoškodí data v případě chyb, výpadku elektřiny apod.

Atomicita znamená, že transakce je jako operace nedělitelná. Provede se buď celá, nebo vůbec.

Konzistence zajišťuje, že kterákoli transakce převede databázi z validního stavu do jiného, opět validního stavu. To znamená, že data, která budou psána do databáze, musí splňovat veškerá pravidla včetně integritních ome-zení, kaskád, triggerů a jejich kombinací.

Izolovanost znamená, že operace uvnitř transakce jsou skryty před vnějšími operacemi. Je-li vrácením transakce (ROLLBACK) zasažena jiná transakce, musí se i tato transakce vrátit. Tím může vzniknout tzv. kaskádový rollback.

Trvalost zaručuje, že změny provedené transakcemi se skutečně uloží do databáze a nemohou být ztraceny.

Silné stránky relačních databází:

 Práce se strukturovanými daty

 Podpora transakční konzistence (ACID) a podpora spojení (JOIN)

 Vztahy v tomto systému mají omezení

 Indexování nemá limit. Silné SQL.

Slabé stránky relačních databází:

 Špatná horizontální škálovatelnost (pokud se nepoužije „sharding“)

 Data jsou normalizována, nutnost velkého množství spojení (JOI-Nů), což má silný vliv na rychlost

 Problémy, nejsou-li data správně strukturována

1.3.2 Nerelační databáze

Jacqueline Homan [3] píše o tom, jak během posledních deseti let se výraz-ně změnil způsob, jakým webové aplikace nakládají s daty. Stále větší množství dat je shromažďováno a stále více uživatelů k těmto datům přistu-puje zároveň. To znamená, že škálovatelnost a výkon jsou stále větší výzvou pro relační databáze, které jsou založeny na určitém schématu, a tudíž je jejich škálovatelnost do jisté míry omezená.

Na tyto problémy narazily firmy pracující s velkými daty a jejich infrastruk-turami, jako Google, Amazon nebo Facebook. Tyto firmy následně začaly přicházet s vlastními řešeními, technologiemi jako BigTable, DynamoDB nebo Cassandra.

Začaly vznikat spousty alternativ v podobě NoSQL Database Management Systems (DBMS), jejichž primárními cíly byly rychlost, spolehlivost a kon-zistence. Již první takové systémy se staly brzy velice úspěšnými a to dalo za vznik spoustě nových, open-source systémů jako MongoDB, HBase nebo Redis.

Typickým rozdílem NoSQL databází od běžných relačních databází je fakt, že NoSQL je formou nestrukturovaného úložiště. To znamená, že NoSQL databáze nemají fixní tabulkovou strukturu typickou právě pro relační typ databází.

Důležitým faktorem, který může odradit od použití většiny nerelačních da-tabází je ten, že tyto databáze nativně nepodporují vlastnosti zaručující spo-lehlivost, jako tomu je u relačních databází (Atomicita, Konzistence, Izolovanost, Trvalost). NoSQL databáze, které tyto vlastnosti nemají, tedy získávají výkon a škálovatelnost na úkor konzistentního chování. To je evi-dentně závažný problém a proto musí v mnoha případech vývojáři imple-mentovat vlastní kód řešící tyto nedostatky, což dělá systém komplexnějším.

Další komplexita vzniká z faktu, že NoSQL databáze, jak již název napoví-dá, nepodporují standardní SQL dotazy. To způsobí, že je navíc potřeba vytvořit vhodný dotazovací jazyk.

Kategorie nerelačních databází

Key-value Store

Tento typ funguje jako hash tabulka, v níž unikátní klíč ukazuje na specific-kou hodnotu. Tyto klíče mohou být organizovány do logických skupin tak, že jejich unikátnost se může vztahovat pouze na jejich vlastní skupinu.

K přístupu k datům je zapotřebí pouze tento klíč a data jsou uložena ve for-mě textových řetězců nebo JSONu. Nejznáfor-mější databází tohoto typu je DynamoDB od Amazonu.

Document Store

Typ, který se velice podobá typu key-value v tom, že postrádá schéma a je také založen na modelu klíč-hodnota. Zrovna tak se příliš neliší jejich výho-dy a nevýhovýho-dy. Významým rozdílem je ten, že hodnoty v tomto typu (do-kumenty) poskytují zakódování pro uložená data. Tyto kódování mohou být XML, JSON nebo BSON (Binárně zakódovaný JSON). Zároveň je u tohoto typu možné používat dotazy pracující přímo s daty. Nejpopulárnější databá-ze tohoto typu je MongoDB.

Column Store

V tomto typu databáze jsou data ukládány do sloupců na rozdíl od řádků, jak je tomu u sytémů relačních databází. Toto úložiště se skládá z jedné ne-bo více rodin sloupců, které logicky seskupují specifické sloupce databáze.

Klíč je používán k identifikaci a jako ukazatel na počet sloupců. Tento klíč obsahuje atribut keyspace, který definuje rozsah toho klíče. Každý sloupec obsahuje n-tice typu jméno-hodnota, které jsou seřazené a oddělené čárkami (comma separated). Vzhledem ke způsobu, jakým jsou data ukládány na disk, umožňuje tento typ databáze rychlé čtecí a zápisové operace. Mezi významné databáze tohoto typu patří například Cassandra, BigTable nebo HBase.

Graph Base

U tohoto modelu jsou pro reprezentaci dat užívána struktura orientovaných grafů, skládajících se z hran a uzlů. Graf je reprezentací skupiny objektů,

kde některé páry těchto objektů jsou propojeny. Vzájemně propojené objek-ty jsou poté reprezentovány vrcholy a jejich propojení je hranou. Typicky se tento typ databáze používá pro aplikace, u nichž jsou důležitější vztahy mezi objekty než hodnota samotných objektů. Mezi současné populární databáze tohoto typu patří InfoGrid nebo InfiniteGraph.

Silné stránky nerelačních databází:

 Efektivní horizontální škálovatelnost a práce s částečně strukturova-nými daty

 Není zapotřebí schéma

 Vysoká dostupnost

Slabé stránky nerelačních databází:

 Slabší nebo eventuální konzistence

 Limitovaná podpora spojení

 Data nejsou normalizována, vyžadují hromadné updaty.

 Nemají vestavěnou datovou integritu

 Limitované indexování 1.3.3 MongoDB

Document-oriented databáze bez fixního schéma. Je napsána v C++ a hod-noty ukládá coby dokumenty ve formě zakódovaných dat. Formátem kódo-vání u MongoDB je JSON, což znamená, že zapouzdřené hodnoty v dokumentech jsou indexovatelné a lze na ně tedy aplikovat dotazy.

Mezi klíčové vlastnosti MongoDB patří sharding. Jak je popisováno v do-kumentaci MongoDB [4], tato vlastnost umožňuje rozdělit data mezi více uzlů (strojů) a tím zajistit schopnost efektivně pracovat s enormním množ-stvím dat. Tento způsob získávání výpočetního výkonu se nazývá právě horizontálním škálováním. Naopak pokud se výkon zvyšuje v rámci pouze jednoho serveru, potom se jedná o škálování vertikální. Vertikální škálování je samozřejmě limitováno dostupností technologií, proto u něj existuje urči-tý strop.

22 Horizontální škálování zahrnuje rozdělování dat a zátěže mezi více serverů, kde každý nový přidaný server zvyšuje celkovou kapacitu a výkon, je-li potřeba. Zatímco celková rychlost či kapacita jednoho stroje nemusí být příliš vysoká, každý ze strojů pracuje pouze s podmnožinou z celkové zátě-že, čímž potenciálně poskytuje vyšší efektivitu než-li jediný silný stroj. Ne-výhodou je potom samozřejmě komplexnost infrastruktury a vyšší náročnost na údržbu.

MongoDB používá RESTful API. K získání dokumentů z kolekce v databázi se vytvoří dotazový dokument, který obsahuje jednotlivá pole, která by měl hledaný dokument obsahovat.

1.4 HTML

Hypertext Markup Language je standardní značkovací jazyk, který se vyu-žívá k tvorbě webových stránek a aplikací. Společně s kaskádovými styly (Cascading Style Sheets) a JavaScriptem tvoří základní trojici technologií ve World Wide Webu.

Webové prohlížeče získávají HTML dokumenty z webových serverů nebo z lokálního úložiště a tyto dokumenty následně vykreslují uživateli jako multimediální webové stránky. HTML jako takové slouží především k popisu obsahu dokumentu a sémantické struktury. Navzdory tomu, že je to do jisté míry možné, nedoporučuje se pomocí HTML popisovat vzhled stránky. O design se starají především kaskádové styly.

HTML elementy jsou stavebními kameny HTML stránek. Tento jazyk po-skytuje prostředky pro sestavení strukturovaných dokumentů pomocí množ-ství tagů, které mají každý svou vlastnost a tyto tagy určují, o jaká data se jedná. Je tedy možné pomocí HTML tagů určit, zda je daný text hlavičkou, odstavcem, seznamem, odkazem apod. Zrovna tak je možné vkládat do do-kumentů obrázky nebo například vytvářet interaktivní formuláře.

Do HTML lze vkládat programy psané ve skriptovacím jazyce, jako je na-příklad právě zmíněný JavaScript, který ovlivňuje chování obsahu webové stránky. Díky základní struktuře, kterou HTML poskytuje, je velice

pohodl-23

né pro tyto scriptovací jazyky přistupovat k datům, se kterými se má praco-vat.

Současným standardem je od roku 2014 HTML 5, který je pátou hlavní ver-zí HTML standardu. Tento standard zahrnuje detailní procesové modely, aby bylo možné psát lépe spolupracující implementace. Dále rozšiřuje a vylepšuje značky (tagy) dostupné pro strukturování dokumentů. Zahrnuje mnoho nových syntaktických vlastností pro inkluzi multimediálních dat a grafického obsahu. Mezi tyto nové vlastnosti patří především elementy

<canvas>, <audio> a <video> nebo například podpora Scalable Vector Graphics (SVG) obsahu.

1.5 Kaskádové styly

Nezbytnou součástí každého webového front endu jsou kaskádové styly.

Zkratka CSS z anglického originálu Cascading Style Sheets. Používají se pro popis vzhledu dokumentu napsaného ve značkovacím jazyce.

Primárně slouží k oddělení obsahu od formy, jakým je obsah prezentován.

Upravují například rozvržení obsahu, barvy nebo písmo. Díky tomu, že se na toto nastylování dokumentů lze odkazovat v jiném dokumentu, umožňuje to vývojáři snadno specifikovat styly, které chce aplikovat ve kterých do-kumentech a pro které elementy.

Kaskádové styly se aplikují na určitý selektor, který deklaruje, na kterou část dokumentu se má styl aplikovat. Těmto selektorům odpovídají značky (tagy) nebo identifikační atributy:

 id – je unikátní, aplikuje se pouze k jedinému elementu

 class – pomocí tohoto atributu lze identifikovat vícero elementů Kromě toho se lze odkazovat na část dokumentu vzhledem k relativnímu umístění v rámci dokumentového stromu.

Pro formátování na základě informací, které nejsou obsaženy v dokumentovém stromu, existují takzvané pseudo-třídy. Typickým příkla-dem takové pseudo-třídy je :hover, která identifikuje pouze ten obsah, na který uživatel právě ukazuje, zpravidla prostřednictvím ukazetele myši.

Ta-24 ková pseudo-třída se potom přidá k selektoru, na který se má speciální pra-vidlo aplikovat.

Kaskádové styly je možné do dokumentu zavést několika způsoby:

 Inline styly

 Vložené styly

 Externí styly 1.5.1 Inline styly

Jedná se o styly, které jsou aplikovány na obsah ihned při jeho vytváření, protože jsou vepsány přímo coby atribut v tagu. Např.:

Takto psané styly se však nedoporučují především proto, aby zůstalo zacho-váno oddělení obsahu dokumentu od formy. Zároveň je však v některých případech takové psaní stylů pohodlné a lze vzít v potaz i fakt, že takto apli-kované styly mají přednost před ostatními, takže mohou přepsat formátova-ní, aplikované jiným způsobem.

1.5.2 Vložené styly

Tyto styly jsou definované v párovém tagu <style>, zachovávají přehled-nost značkování, nicméně jsou svázány s jediným dokumentem. Proto ani tento způsob nebývá doporučován, neboť ve většině případů je zapotřebí styly aplikovat ve vícero dokumentech.

1.5.3 Externí styly

Preferovaný způsob zápisu kaskádových stylů, protože umožňuje sdílení stylů mezi více dokumenty a snižují tak celkový objem kódu, který musí prohlížeč stáhnout. V HTML dokumentu se na soubor, kde jsou styly defi-novány lze jednoduše odkázat.

V této práci byly některé styly aplikovány prostřednictvím pre-processoru CSS.

1.6 CSS Pre-processory

Již několik let jsou k vývoji u některých webových front endů využívány takzvané CSS pre-processory. Během času získaly mnoho vlastností, mezi něž se řadí možnost práce s proměnnými, operátory, interpolacemi, funkce-mi a dalšífunkce-mi užitečnýfunkce-mi prvky. Mezi nejznámější pre-processory CSS patří SASS, LESS a Stylus.

Důvodem, proč se tyto pre-processory používají je fakt, že CSS jako takové je velice primitivní a dalo by se říct neúplné. S těží v něm lze například vy-tvořit funkci nebo využít dědičnosti. Jakmile se projekty rozrostou do vel-kých rozměrů, z údržby kódu se stává větší a větší problém.

Aby se daly psát lepší kaskádové styly, vytvářely se různé přístupy jako například rozdělení definic stylů do menších souborů a jejich následný im-port do hlavního souboru. Tento přístup pomohl se vypořádat s komponentami, ale nevyřešil opakování kódu a problém s náročnou údrž-bou. Dalším přístupem bylo původní zobjektizování kaskádových stylů. V tomto případě šlo o aplikaci dvou a více definic tříd, kde každá přídává da-nému elementu jeden typ stylování. Díky tomu se zvýšila možnost znovu použití již implementovaného kódu, ale zároveň se opět snížila jeho udržo-vatelnost.

Pre-processory se svými pokročilými vlastnostmi pomohly k dosáhnutí na

In document Vizualizace dat uložených v Cloudu na webu (Page 14-0)