Platforma pro archivaci mˇeˇren´ı kvantity a kvality elektrick´e energie

(1)

Platforma pro archivaci mˇ eˇ ren´ı kvantity a kvality elektrick´ e energie

Bakal´ aˇ rsk´ a pr´ ace

Studijn´ı program: B2646 – Informaˇcn´ı technologie Studijn´ı obor: 1802R007 – Informaˇcn´ı technologie Autor pr´ace: Luk´aˇs P´ıcha

Vedouc´ı pr´ace: Ing. Jan Kraus, Ph.D.

(2)

Platform for an archive of power quality and quantity measurements

Bachelor thesis

Study programme: B2646 – Information technology Study branch: 1802R007 – Information technology Author: Luk´aˇs P´ıcha

Supervisor: Ing. Jan Kraus, Ph.D.

(3)

(4)

(5)

(6)

Abstrakt

C´ılem této práce je prozkoumat ukládán´ı ˇcasových ˇrad v relaˇcn´ıch a NoSQL databáz´ıch. Zdrojem ˇcasových ˇrad jsou mˇeˇren´ı nˇekolika veliˇcin elektrické energie z´ıskaná z mˇeˇr´ıc´ıch pˇr´ıstroj˚u od firmy KMB systems s.r.o. Praktická ˇcást se zamˇeˇruje na vývoj webové sluˇzby na architektuˇre REST, která um´ı komunikovat s obˇema typy databáz´ı. Rozhran´ı umoˇzˇnuje jednoduché a rychlé zpra- cován´ı namˇeˇrených veliˇcin. Druhou silnou vlastnost´ı rozhran´ı je prezentován´ı namˇeˇrených dat koncovým zákazn´ık˚um v nejkratˇs´ım moˇzném ˇcasu od ˇcasu namˇeˇren´ı.

Kl´ıˇcová slova: ukládán´ı ˇcasových ˇrad, REST API, relaˇcn´ı da- tabáze, NoSQL databáze, sledován´ı spotˇreby elektrické energie

Abstract

This thesis explores saving of time series in relational and NoSQL databases. Data in time series are taken from measurements by measuring devices in KMB Systems company and contain measuring of several electrical energy quantities. The empirical part of thesis is focused on web service development on REST architecture which is able to communicate with both database types. Due to the interface, the procession of measured quantities is fast and easy. The second key feature of the interface is the ability to present the measured data to customer in shortest time possible from the measurement itself.

Keywords: saving of time series, REST API, relational database, NoSQL database, monitoring of electricity consumption

(7)

Podˇ ekov´ an´ı

T´ımto bych rád podˇekoval Ing. Janu Krausovi, Ph.D. za odborné veden´ı a ˇcas strávený pˇri konzultac´ıch nad bakaláˇrskou prac´ı. Dále pak své rodinˇe, která mi studium umoˇznila a podporovala mˇe.

(8)

Obsah

Seznam zkratek . . . 12

1 Uvod´ 13 2 Analýza datového souboru k praktické ˇcásti 14 2.1 Nevýhody aktuáln´ıho ˇreˇsen´ı . . . 14

3 Casov´ˇ e ˇrady 16 3.1 Dˇelen´ı ˇcasov´ych ˇrad . . . 16

3.2 Upravy ˇ´ casov´ych ˇrad . . . 17

3.2.1 Doplnˇen´ı chybˇej´ıc´ıch hodnot . . . 17

3.2.2 Dalˇs´ı ´upravy . . . 17

3.3 Popisn´e charakteristiky . . . 18

3.4 Probl´emy ˇcasov´ych ˇrad . . . 18

4 Zpracován´ı analýzy poˇzadavk˚u 19 5 Moˇznosti ukládán´ı dat 21 5.1 Relaˇcn´ı MySQL databáze . . . 21

5.1.1 Centr´aln´ı datab´aze vˇsech zaˇr´ızen´ı a uˇzivatel˚u . . . 22

5.1.2 Uˇzivatelsk´e datab´aze . . . 22

5.2 NoSQL datab´aze . . . 25

5.2.1 Ukládán´ı ˇcasových ˇrad do MongoDB . . . 26

5.3 Shrnut´ı. . . 26

6 Principy a technologie pro v´yvoj webov´ych sluˇzeb a aplikac´ı 27 6.1 HTTP protokol . . . 27

6.1.1 Metody . . . 28

6.1.2 Hlaviˇcka a tˇelo . . . 28

6.1.3 Zabezpeˇcen´ı komunikace . . . 29

6.1.4 Stavov´e k´ody . . . 29

6.2 Webov´e aplikace. . . 30

6.2.1 Architektura MVC . . . 30

6.3 V´ybˇer technologi´ı pro v´yvoj . . . 31

6.3.1 Laravel . . . 31

6.3.2 Ostatn´ı n´astroje. . . 33

(9)

7 Realizace ˇreˇsen´ı 36

7.1 KMB Visio Api . . . 36

7.1.1 Zabezpeˇcen´ı a autentizace uˇzivatel˚u . . . 36

7.1.2 Komunikace s KMB Viso API . . . 37

7.1.3 Form´at odpovˇedi a dotazu do API . . . 37

7.2 API dokumentace . . . 38

7.2.1 Registrace a pˇrihlaˇsov´an´ı uˇzivatel˚u . . . 38

7.2.2 Registrace nov´eho zaˇr´ızen´ı . . . 38

7.2.3 Dalˇs´ı modifikace nad zaˇr´ızen´ımi a ostatn´ımi zdroji . . . 39

7.2.4 Odes´ıl´an´ı namˇeˇren´ych hodnot . . . 40

7.2.5 Uprava dat do podoby pro klienta´ . . . 41

7.2.6 Historie namˇeˇren´ych hodnot dan´eho pˇr´ıstroje . . . 41

7.3 KMB Visio Manager / Client . . . 42

7.3.1 Pˇrihlaˇsov´an´ı uˇzivatel˚u . . . 42

7.3.2 Spr´ava datab´az´ı, zaˇr´ızen´ı a uˇzivatel˚u . . . 43

7.3.3 Sledov´an´ı spotˇreby elektrick´e energie . . . 43

8 Z´avˇer 45 8.1 Dalˇs´ı rozvoj pr´ace . . . 45

Literatura 47

Pˇr´ılohy 51

A Obsah pˇriloˇzen´eho CD 51

B UML Use case diagram 52

(10)

Seznam obr´ azk˚ u

5.1 Konceptuáln´ı model centráln´ı databáze pro KMB Visio . . . 22 5.2 Prvn´ı verze tabulky pro záznam mˇeˇren´ı . . . 24 5.3 Druhá verze tabulky pro záznam mˇeˇren´ı . . . 24 5.4 Struktura tabulky, co uchovává ˇcasovou ˇradu v jednom ˇrádku . . . . 25 5.5 Konceptuáln´ı model uˇzivatelské databáze pro KMB Visio . . . 25 7.1 Ukázka grafu z prostˇred´ı KMB Visio Client. . . 44 B.1 UML Use case diagram . . . 52

(11)

Seznam tabulek

2.1 P˚uvodn´ı datový soubor ve formátu csv . . . 15 7.1 Specifikace tˇela zprávy pro registraci nového zaˇr´ızen´ı . . . 39 7.2 Specifikace tˇela zprávy pro odeslán´ı namˇeˇrených . . . 41

(12)

Seznam zdrojov´ ych k´ od˚ u a uk´ azek

1 Datov´y soubor ve form´atu JSON . . . 15

2 Poˇzadavek na server - registrace nov´eho uˇzivatele . . . 28

3 Instalace Laravel frameworku a projektu . . . 32

4 Konfiguraˇcn´ı soubor pro datab´aze . . . 33

5 Definice rout v prostˇred´ı Laravel. . . 33

6 Hlaviˇcka metody sendRequest ve tˇr´ıde KMBVisioApiModel . . . 37

7 Odhlaˇsov´an´ı uˇzivatel˚u v prostˇred´ı Laravel. . . 39

8 Tˇelo a odpovˇed’ zpr´avy pˇri zaloˇzen´ı nov´eho zaˇr´ızen´ı . . . 40

(13)

Seznam zkratek

ACID Atomic, Consistent, Isolated, Durable API Application Programming Interface CSV Comma-separated values

CRUD Create, Read, Update, Delete

DI Dependency Injection (pˇredáván´ı závislost´ı) DoS Denial of service

HMAC Hash-based message authentication code HTML HyperText Markup Language

HTTP(S) Hypertext Transfer Protocol (Secure) JSON JavaScript Object Notation

MIT Massachusetts Institute of Technology MITM Main-in-the-middle

MVC Model-View-Controller

OOP Object-oriented programming ORM Object-relational mapping REST REpresentational state transfer RFC Request For Comments

SMTP Simple Mail Transfer Protocol SOAP Simple Object Application Protocol SQL Structured Query Language

SSL Secure Sockets Layer TLS Transport Layer Security UML Unified Modeling Language URL Uniform Resource Locator XML eXtensible Markup Language

(14)

1 Uvod ´

Ukolem bakal´´ aˇrské práce je vytvoˇren´ı aplikace pro vhodné ukládán´ı dat a následnˇe i uˇzivatelsky pˇr´ıvˇetivé prezentace namˇeˇrených hodnot pro koncové zákazn´ıky. Mˇeˇrené hodnoty pocházej´ı z mˇeˇr´ıc´ıch pˇr´ıstroj˚u z firmy KMB systems s.r.o, které generuje aplikace Envis. Tyto pˇr´ıstroje um´ı mˇeˇrit v ˇrádech stovek veliˇcin v jedné minutˇe.

Motivac´ı je hned nˇekolik. Zákazn´ık chce m´ıt rychlý pˇrehled o tom, co se dˇeje v jeho s´ıti. Takto lze napˇr´ıklad vypozorovat, zda v s´ıti nejsou ˇcern´ı odbˇeratelé nebo jestli s´ıt’ vydrˇz´ı dalˇs´ı energetickou zátˇeˇz. Reˇserˇse ukázala, ˇze nejsou dostupné aplikace, které by o pr˚ubˇehu informovaly v co moˇzná nejkratˇs´ım ˇcase. Dosavadn´ı notifikac´ı je aˇz výzva k zaplacen´ı faktury od poskytovatele elektrické energie.

Prvn´ı kapitoly ˇctenáˇre seznám´ı se zp˚usobem, jak Envis namˇeˇrená data ukládá a co je jejich obsahem. Jsou zde prozkoumány i moˇznosti jiných zp˚usob˚u ukládán´ı za úˇcelem dalˇs´ıho strojového zpracován´ı a uˇsetˇren´ı m´ısta v pamˇeti. Dalˇs´ı kapi- tolou je návrh databázových model˚u pro ukládán´ı ˇcasových ˇrad, které pocházej´ı z namˇeˇrených údaj˚u. Byly prozkoumány relaˇcn´ı i NoSQL databáze, konkrétnˇe jak efektivnˇe ukládat data. Dalˇs´ı ˇcást seznamuje s vývojem webových sluˇzeb aplikac´ı.

Jsou uvedeny technologie, které byly vybrány pro vývoj, jejich výhody, a proˇc jsou lepˇs´ı neˇz jiné technologie.

V praktické ˇcásti je popsán pr˚ubˇeh vývoje API a klientské ˇcásti, je popsán zp˚usob zabezpeˇcen´ı a pˇr´ıstup na urˇcité zdroje. Jedná se o online aplikaci, kterou bude vyuˇz´ıvat mnoho uˇzivatel˚u s r˚uznými oprávnˇen´ımi, jednokrokovou regis- trac´ı bez zbyteˇcných osobn´ıch údaj˚u a extrémnˇe jednoduchým zp˚usobem pˇrenosu dat. Namˇeˇrená data jsou uchovávaná v menˇs´ıch ˇcasových intervalech oproti En- visu. D´ıky detailnˇejˇs´ımu uchováván´ı dat lze pak v pˇr´ıpadˇe problému v s´ıt´ı pˇresnˇeji urˇcit, v jakém ˇcase problémová událost nastala. V závˇeru se lze doˇc´ıst, zda a jakými nejd˚uleˇzitˇejˇs´ımi kroky bylo dosaˇzeno poˇzadovaných c´ıl˚u a je nast´ınˇena otázka dalˇs´ıho rozˇs´ıˇren´ı této práce.

(15)

2 Anal´ yza datov´ eho souboru k praktick´ e ˇ c´ asti

Prvn´ım krokem celé práce bylo porozumˇen´ı problematice mˇeˇren´ı elektrické energie a zp˚usobu, jakým jsou data z mˇeˇren´ı ukládána. Pro tyto úˇcely byla poskytnuta sada csv soubor˚u, které generuje aplikace Envis [21]. CSV soubory jsou výhodné v tom, ˇze pro jejich ˇcten´ı a zápis nen´ı tˇreba speciáln´ıch sloˇzitých program˚u. Data v ˇrádc´ıch jsou nejˇcastˇeji oddˇelená stˇredn´ıkem nebo ˇcárkou. Dalˇs´ımi formáty pro ukládán´ı dat je napˇr´ıklad JSON, viz ukázka 1 a XML formát. JSON formát nen´ı optimáln´ı pro pˇrenos binárn´ıch dat, v XML souboru nalezneme spoustu znak˚u, které tvoˇr´ı tento formát. Uˇzit´ı formátu vˇzdy závis´ı na konkrétn´ım typu aplikace.

Soubor (tabulka 2.1) na prvn´ım ˇrádku obsahuje identifikaci zaˇr´ızen´ı, které data namˇeˇrilo a pˇr´ıznak PQ. Dalˇs´ı ˇrádek informuje o tom, jaké veliˇciny a v jakých jed- notkách byly v daném ˇcase namˇeˇreny, poˇcet veliˇcin se pohybuje v ˇrádu des´ıtek.

V praxi se tento ˇrádek obvykle popisuje jako hlaviˇcka. Prvn´ı poloˇzkou je record time[s], tedy datum a ˇcas mˇeˇren´ı s pˇresnost´ı na milisekundy, dalˇs´ımi prvky v hlaviˇcce jsou jiˇz zmiˇnované veliˇciny, pro pˇredstavu napˇr´ıklad frekvence, napˇet´ı, proud, výkon, konfigurace nastaven´ı parametr˚u, aj. Kaˇzdý csv soubor uchovává data jednoho mˇeˇr´ıc´ıho pˇr´ıstroje za jeden celý den, nejˇcastˇeji po patnáctiminutových intervalech. Po tˇechto ˇrádc´ıch následuj´ı jiˇz konkrétn´ı hodnoty v poˇrad´ı definovaném v hlaviˇcce. Prvn´ı hodnotou je tedy datum a ˇcas mˇeˇren´ı, napˇr. 03.06.201700 : 00 : 00.038, následuj´ı namˇeˇrené hodnoty, které jsou r˚uzných datových typ˚u - celé ˇc´ıslo, ˇc´ısla s plovouc´ı ˇrádovou ˇcárkou a binárn´ı pole o velikosti jednoho bajtu. Spousta veliˇcin má po celý den mˇeˇren´ı nulové hodnoty - to je zapˇr´ıˇcinˇeno t´ım, ˇze pˇr´ıstroj danou veliˇcinu nemˇeˇr´ı, ale ukládá výchoz´ı hodnotu nula. Jeden konkrétn´ı datový soubor je v pˇr´ıloze A.

2.1 Nev´ yhody aktu´ aln´ıho ˇ reˇ sen´ı

Pˇri studii bylo nalezeno pár moˇznost´ı jak toto csv optimalizovat za úˇcelem rych- lejˇs´ıho zpracován´ı a pˇredevˇs´ım zmenˇsen´ı zab´ıraného m´ısta na disku. Pokud by se datum a ˇcas ukládaly v normˇe ISO 8601, bylo by poté moˇzné z tohoto formátu rychle a jednoduˇse vytvoˇrit objekt typu DateT ime. Budeme-li cht´ıt z´ıskat hodnoty pro konkrétn´ı veliˇcinu za celý mˇeˇrený interval, budeme muset prvnˇe zjistit, na kterém prvku hlaviˇckového ˇrádku se nacház´ı (sloˇzitost O(n)), a poté proj´ıt vˇsechny ˇrádky a vybrat hodnotu na indexu mˇeˇrené veliˇciny (opˇet O(n)), celkovˇe tedy sloˇzitost O(n²). V pˇr´ıpadˇe, ˇze by byla data v souboru transformovanˇe, tj. sloupeˇcky ˇcasy

(16)

mˇeˇren´ı a jeden konkrétn´ı ˇrádek by pˇredstavoval mˇeˇrenou veliˇcinu, nalezen´ı hodnot dané veliˇciny pro celý pozorovac´ı interval bude pouze O(n). Posledn´ı moˇznost´ı, která vede k optimalizaci, je problém nulových hodnot v celém sledovaném úseku. Nuly by ˇslo jednak nahradit prázdným ˇretˇezcem, ˇc´ımˇz se dá také zmenˇsit velikost výsledného souboru, nicménˇe lepˇs´ı variantou by bylo veliˇciny s nulovými hodnotami za celý interval nezapisovat, ale zapsat pouze jejich název do hlaviˇckového souboru na posledn´ı m´ısto. Pokud by neexistovala hodnota na indexu v ˇrádc´ıch hodnot, znamenalo by to, ˇze daná veliˇcina v daném ˇcase nic nenamˇeˇrila.

1 {

2 data: {

3 "03.06.2017 00:01:00.000" : {

4 "avg.f[Hz]" : 49.98321,

5 "avg.U1[V]" : 244.821

6 "avg.I1[A]" : 0.9353704,

7 // ...

8 },

9 "03.06.2017 00:02:00.000" : {

10 // ...

11 }

12

13 }

14 }

Ukázka 1: Datový soubor ve formátu JSON

Tabulka 2.1: P˚uvodn´ı datov´y soubor ve form´atu csv

KMB Headquarters/ SMC 235D U X/5A E(6)/ PQ Survey

record time[s] avg.f[Hz] avg.U1[V] avg.I1[A] avg.P1[kW] avg.3Q[kvar]

03.06.2017 00:01:00.000 49.98321 246.0748 0.9353704 0.146431396484375 -0.376471221923828 03.06.2017 00:02:00.000 49.97229 246.2901 0.9507966 0.149623641967773 -0.369777191162109 03.06.2017 00:03:00.000 49.97416 246.5585 0.943457 0.149523010253906 -0.373624664306641 03.06.2017 00:04:00.000 49.97937 246.4277 0.9414431 0.149441955566406 -0.367776519775391 03.06.2017 00:05:00.000 49.97763 246.4431 0.9385444 0.148853408813477 -0.371797271728516 03.06.2017 00:06:00.000 49.96017 246.3116 0.9371952 0.148481750488281 -0.367386169433594 03.06.2017 00:07:00.000 49.95576 246.1986 0.9446217 0.150069046020508 -0.372720794677734 03.06.2017 00:08:00.000 49.9529 246.2795 0.9422051 0.149398193359375 -0.370366790771484 03.06.2017 00:09:00.000 49.96693 246.3747 0.9412095 0.149346862792969 -0.373975128173828 03.06.2017 00:10:00.000 49.97293 246.3651 0.9298881 0.147384735107422 -0.375468139648438

(17)

3 Casov´ ˇ e ˇ rady

Po prozkoumán´ı archivu monitoru kvality bylo zjiˇstˇeno, ˇze data obsaˇzená v nˇem jsou zdrojem pro ˇcasovou ˇradu. ˇZe se v tomhle pˇr´ıpadˇe mluv´ı o ˇcasové ˇradˇe dokazuje definice, která ji popisuje jako ”ˇcasovou posloupnost hodnot ukazatel˚u namˇeˇrených v urˇcitých ˇcasových intervalech”[20]. Kaˇzdou ˇcasovou ˇradu lze zapsat v následuj´ıc´ım tvaru:

y₁, y₂, . . . , y_n (3.1)

kde y znaˇc´ı sledované hodnoty, t je ˇcasová promˇenná a n je poˇcet vzork˚u. Dalˇs´ı moˇznost´ı zápisu je ve tvaru:

yt, t = 1, . . . , n (3.2)

Naˇse ˇcasová ˇrada vznikla ze sledován´ı mˇeˇren´ı veliˇcin v oblasti elektrické energie.

Casov´ˇ e ˇrady slouˇz´ı pro porozumˇen´ı dané situaci, jehoˇz výsledkem je pochopen´ı podm´ınek a pravidel pro zpracován´ı dalˇs´ıch hodnot této ˇcasové ˇrady. Dalˇs´ı moˇznost´ı je také predikce vývoje nových ukazatel˚u. ˇCasové ˇrady maj´ı vyuˇzit´ı témˇeˇr ve vˇsech odvˇetv´ıch, napˇr. sledován´ı akciového trhu, pˇredpovˇed’ poˇcas´ı, doba do poruchy stroje, predikce porodnosti a úmrtnosti obyvatel apod.

3.1 Dˇ elen´ı ˇ casov´ ych ˇ rad

Ne vˇsechny ˇcasové ˇrady pracuj´ı se stejnými ˇcasovými ukazateli a jejich sledovaný interval téˇz nen´ı stejný. Proto je potˇreba dobˇre porozumˇet, do jaké skupiny data patˇr´ı. ˇSpatné zaˇrazen´ı by mohlo m´ıt za následek výbˇer ˇspatných metod pro jejich analýzu, ˇc´ımˇz nelze dosáhnout správných výsledk˚u. Prvn´ı zp˚usob dˇelen´ı je dle délky ˇcasového úseku, kdy pozorujeme nˇejaká data. Je-li perioda delˇs´ı neˇz jeden rok, mluv´ıme o dlouhodobých ˇcasových ˇradách. ˇCasy s menˇs´ı periodou oznaˇcujeme jako krátkodobé ˇcasové ˇrady, kde sledované obdob´ı m˚uˇze být tˇreba ˇctvrtlet´ı, mˇes´ıc, týden. Kratˇs´ı periody neˇz výˇse zmiˇnované jsou udávány vysokofrekvenˇcn´ı ˇcasovou ˇradu.

Druhým zp˚usobem dˇelen´ı je dˇelen´ı dle typu sledovaného ukazatele na ˇrady in- tervalové a okamˇzikové. U intervalových ˇrad záleˇz´ı na délce sledovaného ukazatele, u okamˇzikových naopak. Intervalová ˇcasová ˇrada je jednoduˇs´ı na provádˇen´ı základn´ıch popisných statistik, u okamˇzikových ˇrad je potˇreba se zamyslet, zda napˇr. souˇcet ukazatel˚u dává reálný smysl. Proto se u intervalových ˇcasových ˇrad poˇc´ıtá s prostým a váˇzeným chronologickým pr˚umˇerem.

(18)

Pro doplnˇen´ı lze pak jeˇstˇe ˇcasové ˇrady dˇelit na ˇrady s absolutn´ımi ˇci relativn´ımi ukazateli, deterministické a stochastické, ekvidistantn´ı a neekvidistantn´ı, stacionárn´ı a nestacionárn´ı. V´ıce o ˇcasových ˇradách viz [4].

3.2 Upravy ˇ ´ casov´ ych ˇ rad

U ˇcasových ˇrad lze provádˇet následuj´ıc´ı operace (je tˇreba m´ıt na pamˇeti, zda má daná operace smysl a výsledek bude reálný) - doplnˇen´ı chybˇej´ıc´ıch hodnot,transformace mˇeˇr´ıtka a kombinace ˇcasových ˇrad, ˇcasový posun, sezónn´ı diference, kumulativn´ı souˇcet, vyhlazován´ı ˇcasových ˇrad. Pozornost bude zamˇeˇrena na operace, kterých bylo uˇzito pˇri zpracován´ı reálných dat v praktické ˇcásti této práce [3].

3.2.1 Doplnˇ en´ı chybˇ ej´ıc´ıch hodnot

V praxi m˚uˇze nastat situace, kdy dané pozorovan´ı nemus´ı obsahovat vˇsechny platné hodnoty. Chybˇej´ıc´ı neboli neplatné hodnoty mohou být zp˚usobeny obecnˇe napˇr.

výpadkem mˇeˇr´ıc´ıho pˇr´ıstroje, zapomenut´ım vyplnˇen´ı otázky v dotazn´ıku, pˇrepsán´ım se v desetinné ˇcárce, ˇspatným pochopen´ım otázky apod. Pˇri zpracován´ı jakéhokoliv statistického souboru je tedy nutné chybˇej´ıc´ı hodnoty doplnit a je potˇreba se zamyslet nad t´ım, zda nám doplnˇené hodnoty pˇr´ıliˇs neovlivn´ı výsledek. Opˇet existuje mnoho pˇr´ıstup˚u, jak se s t´ımto vypoˇrádat. Nejjednoduˇsˇs´ı moˇznost´ı je doplnit chybˇej´ıc´ı hodnoty nulami, tento zp˚usob ˇreˇsen´ı ale nen´ı pˇr´ıliˇs vhodný pro okamˇzikové ˇrady. Lepˇs´ı volbou je nahradit chybˇej´ıc´ı hodnoty v datech nˇejakou centráln´ı charakteristikou souboru namˇeˇrených hodnot. Konkrétnˇe mluv´ıme o arit- metickém pr˚umˇeru nebo mediánu. Centráln´ı charakteristika m˚uˇze být poˇc´ıtána na základˇe celého výbˇerového souboru, nebo v okol´ı chybˇej´ıc´ıch bod˚u. Zaj´ımavˇejˇs´ım a mnohdy i pˇresnˇejˇs´ım zp˚usobem je nahrazen´ı chybˇej´ıc´ıch hodnot trendem celé ˇcasové ˇrady a lineárn´ı interpolac´ı. Pro doplnˇen´ı hodnot na konci ˇrady se uˇz´ıvá metoda extrapolace.

3.2.2 Dalˇ s´ı ´ upravy

Sezónn´ı diference. Jedná se o rozd´ıl mezi ˇcasovými okamˇziky o celistvý násobek délky periody. Diference vyjadˇruje velikost zmˇeny, ke které doˇslo mezi dvˇema ˇcasovými okamˇziky mˇeˇren´ı oproti pˇredcházej´ıc´ım obdob´ı. Pokud je rozd´ıl kladný, ˇrada v daném ˇcase roste, v opaˇcném pˇr´ıpadˇe klesá. Opaˇcnou operac´ı je kumulativn´ı souˇcet, který vyjadˇruje souˇcet pozorován´ı za urˇcitý ˇcasový úsek. Pokud aplikujeme tyto dvˇe

´

upravy, z´ıskáme p˚uvodn´ı ˇradu opoˇzdˇenou a jeden ˇcasový interval, zvˇetˇsenou nebo zmenˇsenou o urˇcitou konstantu. Transformaci mˇeˇr´ıtka uˇzijeme v pˇr´ıpadˇe, ˇze je potˇreba potlaˇcit ˇci zm´ırnit nestacionarity ˇrady, kde s rostouc´ımi hodnotami roste i rozptyl ˇclen˚u. Transformaci aplikujeme uˇzit´ım logaritmické funkce, vynásoben´ım konstantou nebo prostým umocnˇen´ım. Po prozkoumán´ı dat opˇet transformujeme do p˚uvodn´ıho tvaru. Posledn´ı ze zmiˇnovaných modifikac´ı je ˇcasový posun, kde ukazatel˚um ˇcasové ˇrady zmˇen´ıme základnu. T´ım pak z´ıskáme ve staré základnˇe bud’

(19)

na zaˇcátku nebo na konci chybˇej´ıc´ı hodnoty, právˇe tolik, o kolik krok˚u byl posun provádˇen.

3.3 Popisn´ e charakteristiky

Následuje výˇcet základn´ıch popisných statistik, které byly uˇz´ıvány pˇri práci. Prostý chronologický pr˚umˇer se spoˇc´ıtá jako:

y1

2 + y₂+ . . . + y_n−1+ ^y₂ⁿ

n − 1 (3.3)

Kde kaˇzdému ˇcasové okamˇziku t₁, t₂, . . . , t_nnáleˇz´ı hodnota ˇcasové ˇrady y₁, y₂, . . . , y_n. Váˇzený chronologický pr˚umˇer se spoˇc´ıtá následovnˇe pro stejná kritéria jako u 3.3:

y1+y2

2 (t₂− t₁) + ^y²^+y₂ ³(t₃ − t₂) + . . . +^yⁿ¹₂^+yⁿ(t_n− t_n−1)

t_n− t_n−1 (3.4)

Prost´y aritmetick´y pr˚umˇer s ukazatele y a poˇcet vzork˚u je t:

y =

Pn t=1y_t

n (3.5)

Omezen´ı ˇrady, kde nás z ˇcasové ˇrady zaj´ımaj´ı pouze hodnoty na urˇcitých indexech, lze napsat v následuj´ıc´ım tvaru 3.3, kde vybereme kaˇzdý k − tý prvek z ˇcasové ˇrady y_t. Omezená ˇrada bude délky n.

{y_ki}ⁿ_i=0 (3.6)

Tohoto je vyuˇzito pˇri ´upravˇe dat do podoby pro klienta, kde parametr k odpov´ıd´a atributu group interval.

3.4 Probl´ emy ˇ casov´ ych ˇ rad

Pˇri analýze ˇrad se lze setkat s mnoha problémy, které je potˇreba pˇri zpracován´ı dat znát. Jedná se pˇredevˇs´ım o problémy s délkou ˇcasové ˇrady, kde pˇri krátkém mnoˇzstv´ı vzork˚u nemus´ı být správnˇe odhadnout dalˇs´ı vývoj, naopak pˇri delˇs´ım po- zorován´ı m˚uˇzeme zaznamenat v´ıce chybných mˇeˇren´ı, coˇz opˇet m˚uˇze vést ke ˇspatným výsledk˚um. S t´ımto lehce souvis´ı i problém se vzorkem mˇeˇren´ı, kde sbˇer datového souboru nemusel být provádˇen stejným zp˚usobem, napˇr. liˇs´ıc´ım se poˇctem dese- tinných m´ıst, tzv. Motýl´ı efekt. Dalˇs´ım problémem pˇri zpracován´ı je problém s ka- lendáˇrn´ımi dny. Pokud napˇr. zpracováváme mˇes´ıˇcn´ı produkci, je tˇreba m´ıt na pamˇeti, ˇze kaˇzdý mˇes´ıc má jiný poˇcet kalendáˇrn´ıch a pracovn´ıch dn˚u. Do modelován´ı je tˇreba zahrnout i státn´ı svátky (problémem jsou mnohdy Velikonoce) [8]. V pˇr´ıpadˇe této práce byl nejvˇetˇs´ı problém s pˇrechodem na letn´ı/zimn´ı ˇcas, kde v jednom pˇr´ıpadˇe data chybˇela, ve druhém naopak pˇrebývala.

(20)

4 Zpracov´ an´ı anal´ yzy poˇ zadavk˚ u

Tato specifikace vyplynula po seznámen´ı s aktuáln´ı problematikou vedouc´ım práce.

Celé chován´ı aplikace je vyobrazena na UML Use Case diagramu v pˇr´ılozeB.1. Proˇc a k ˇcemu jsou dobré UML diagramy se lze doˇc´ıst v [7].

V nejnovˇejˇs´ıch verz´ıch firmwaru vybraných ˇrad pˇr´ıstroj˚u bude pˇridán skript (post request), který kaˇzdou minutu odeˇsle na urˇcitý server namˇeˇrená data vˇsech veliˇcin.

Pro úspˇeˇsnost je tˇreba, aby zaˇr´ızen´ı bylo registrované v centráln´ı databázi, která v sobˇe nese informace o vˇsech zaˇr´ızen´ıch a o tom, do jaké databáze má mˇeˇren´ı uloˇzit. Dále mus´ı být zaˇr´ızen´ı a jeho databáze aktivn´ı a mus´ı být platný API token pro zamezen´ı odes´ılán´ı neplatných mˇeˇren´ı (DoS útoky). Krom tˇechto údaj˚u odeˇsle i svoje unikátn´ı výrobn´ı ˇc´ıslo a namˇeˇrená data. Namˇeˇrená data mohou být dvoj´ıho typu, prvn´ı moˇznost´ı je odeslán´ı jako asociativn´ı pole, kde kl´ıˇcem je název veliˇciny a hodnotou je konkrétn´ı mˇeˇrená hodnota, druhým zp˚usobem je odeslán´ı pouze pole mˇeˇrených veliˇcin. V takovém pˇr´ıpadˇe je nutné, aby zaˇr´ızen´ı mˇelo definováno, která veliˇcina je na daném indexu tohoto pole. V pˇr´ıpadˇe ztráty spojen´ı se serverem je zaruˇceno, ˇze pˇr´ıstroj vˇsechna namˇeˇrená data odeˇsle pˇri obnoven´ı spojen´ı.

Na pozad´ı tohoto modelu bˇeˇz´ı v urˇcitých intervalech skript (spuˇstˇený napˇr. cro- nem), který zpracovává namˇeˇrená data, dle nastaven´ı zaˇr´ızen´ı je modifikuje a uloˇz´ı do lepˇs´ı podoby. Modifikac´ı je myˇsleno agregován´ı po urˇcitých ˇcasových intervalech, tak jako Envis generuje do csv soubor˚u, podpora pro rychlejˇs´ı pˇr´ıstup k dat˚um. Tento proces slouˇz´ı pro optimalizaci databáze, proˇc tomu tak je, se lze doˇc´ıst v následuj´ıc´ı kapitole. Aˇckoliv se v základu zákazn´ık˚um budou zobrazovat data pouze za posledn´ı dva dny v intervalech vˇetˇs´ıch neˇz jedna minuta (minimáln´ı interval pro agregaci zákazn´ık˚um byl stanoven na 15 minut), je tˇreba m´ıt nadále uloˇzená i ”surová”data (minutové záznamy) pro pˇr´ıpadnou zmˇenu konfigurace.

Distributor pˇri odbˇeru mˇeˇr´ıc´ıch pˇr´ıstroj˚u obdrˇz´ı ˇcasovˇe platný registraˇcn´ı kl´ıˇc pro registrace do KMB Visio Manager. Pokud chce svým koncovým zákazn´ık˚um po- skytovat sledován´ı spotˇreby elektrické energie, mus´ı zaregistrovat svá zaˇr´ızen´ı. Re- gistrace spoˇc´ıvá v opsán´ı unikátn´ıho výrobn´ıho ˇc´ısla pro kaˇzdé zaˇr´ızen´ı a zaˇrazen´ı do konkrétn´ı databáze. V jedné konkrétn´ı databázi by mˇela být pouze ta zaˇr´ızen´ı, která jsou montována v jedné konkrétn´ı instituci. Toto opatˇren´ı je zde proto, aby konkrétn´ı koncový zákazn´ık nemˇel pˇr´ıstup k dat˚um (topologie, seznam uˇzivatel˚u, namˇeˇrené

´

udaje) ostatn´ıch zaˇr´ızen´ı a naopak. Dále pak m˚uˇze distributor aktivovat a deakti- vovat databázi a generovat registraˇcn´ı kl´ıˇc (rovnˇeˇz ˇcasovˇe platný) pro své koncové

(21)

zákazn´ıky. Podle preferenc´ı distributora a koncového klienta je zde moˇznost si vybrat i typ databáze (MySQL, NoSQL), kde kaˇzdé ˇreˇsen´ı má své výhody a nevýhody.

Zaˇr´ızen´ım lze vytváˇret konfigurace, které ˇr´ıkaj´ı, jak ˇcasto a v jakých ˇcasových intervalech má modifikace do podoby pro klienta prob´ıhat.

Obdrˇz´ı-li koncový zákazn´ık (osoba jeˇz si zaˇr´ızen´ı nechá instalovat do své elek- trické s´ıtˇe) od svého distributora registraˇcn´ı kl´ıˇc, m˚uˇze se registrovat do KMB Vi- sio Client. Prvn´ı zákazn´ık, který se v dané databázi registruje, je jej´ım správcem.

Správce je povaˇzován za osobu s odbornou zp˚usobilost´ı. Dalˇs´ımi uˇzivateli jsou osoby, co si od montéra zakoupili mˇeˇr´ıc´ı pˇr´ıstroje. Ti maj´ı práva pouze na sledován´ı spotˇreby pˇr´ıstroj˚u, které jim správce povol´ı. Pro kaˇzdé zaˇr´ızen´ı si lze zobrazit konkrétn´ı veliˇcinu a vidˇet jej´ı posledn´ı vývoj. Správce má moˇznosti správy zaˇr´ızen´ı, které m˚uˇze ˇradit do projekt˚u. Projekty slouˇz´ı pro topologické uspoˇrádán´ı zaˇr´ızen´ı tak jak jsou ve skuteˇcnosti rozm´ıstˇena. Stejnˇe jako zaˇr´ızen´ı, se i zákazn´ıci mus´ı autentizovat.

(22)

5 Moˇ znosti ukl´ ad´ an´ı dat

Naj´ıt optimáln´ı zp˚usob uloˇzen´ı dat vyˇzaduje m´ıt urˇcité zkuˇsenosti s modelován´ım databáz´ı, ale i s následným výbˇerem dat z databáze (znalost dotazovac´ıho jazyka SQL). Databázové schéma je tˇreba m´ıt pˇripraveno i pro pˇr´ıpad dalˇs´ıho rozˇs´ıˇren´ı.

Do databáz´ı lze ukládat cokoli, ale kaˇzdá data jsou jinak specifická, jejich zpracován´ı a zpˇetná prezentace se také liˇs´ı specifikac´ı aplikace, pro kterou slouˇz´ı. V prvé ˇradˇe je potˇreba vˇedˇet, co pˇresnˇe za data budeme ukládat, jakých m˚uˇzou nabývat hodnot a jak k nim budeme pˇristupovat a znát celkovˇe poˇzadavky aplikace. Vˇsechny tyto souvislosti je tˇreba dát správnˇe dohromady a zamyslet se nad t´ım, zda bude toto ˇreˇsen´ı dostaˇcuj´ıc´ı. Pˇri nasazen´ı ostré verze aplikace uˇz nen´ı vˇzdy moˇzné struktury následnˇe mˇenit, jelikoˇz se od nich odv´ıj´ı i dalˇs´ı ˇcásti aplikace. V takovém pˇr´ıpadˇe pak nezbývá nic jiného neˇz si vystaˇcit s danou verz´ı nebo celé ˇreˇsen´ı vymyslet znovu, coˇz stoj´ı ˇcas. Následuj´ıc´ı podkapitoly l´ıˇc´ı návrh databáz´ı pro REST API aplikaci.

Jsou zde uvedeny i postupy, které nevedly k výslednému ˇreˇsen´ı.

5.1 Relaˇ cn´ı MySQL datab´ aze

Tento typ databáze si lze pˇredstavit jako sadu tabulek, kde kaˇzdá tabulka má sv˚uj jednoznaˇcný název. Tabulky jsou tvoˇreny sloupci neboli atributy, které mohou být r˚uzných datových typ˚u. ˇRádky pˇredstavuj´ı jednotlivé záznamy, kde kaˇzdý da- tabázový ˇrádek lze jednoznaˇcnˇe identifikovat primárn´ım kl´ıˇcem. Tabulky jsou propojeny vzájemnými relacemi (vazbami), vazba m˚uˇze být i napˇr´ıklad z jedné tabulky na tu samou, tzv. self-relace. Návrh zaˇc´ıná konceptuáln´ım modelem, který je následnˇe pˇreveden na relaˇcn´ı model. V´ıce se lze doˇc´ıst v [9]. Pˇri návrhu bylo uˇzito co nej- vhodnˇejˇs´ıch datových typ˚u s rozumnou délkou. Nen´ı tedy pˇr´ıliˇs vhodné, aby informace o tom, zda je je entita aktivn´ı ˇci nikoliv, byla uloˇzena v datovém typu integer (celé ˇc´ıslo) o velikosti 4 B (32 b), kdyˇz se dá uˇz´ıt datového typu bit o délce jednoho bitu. Dalˇs´ı optimalizac´ı je uˇz´ıvat i neznaménkové datové typy (unsigned). O da- tových typech se lze v´ıce doˇc´ıst v oficiáln´ı pˇr´ıruˇcce MySQL [27]. Pˇri návrhu je dobré se drˇzet i nepsaných programátorských konvenc´ı a doporuˇcených postup˚u. Nˇekteré frameworky dokonce vyˇzaduj´ı, v jakém tvaru maj´ı být názvy tabulek a pˇr´ısluˇsných model˚u. Pro práci s daty v SQL databáz´ı lze vyuˇz´ıvat dotazovac´ıho jazyka SQL.

(23)

5.1.1 Centr´ aln´ı datab´ aze vˇ sech zaˇ r´ızen´ı a uˇ zivatel˚ u

Po d˚ukladném zpracován´ı analýzy poˇzadavk˚u a pochopen´ı, jaká data budou ukládána, bylo dosaˇzeno následuj´ıc´ıho databázového schématu viz 5.1. Schéma obsahuje pˇet tabulek, kde jiˇz podle názvu lze urˇcit, pro kterou entitu byla vytvoˇrena. Tabulka pro entitu zaˇr´ızen´ı je pojmenovaná objects (Laravel kv˚uli práci s ORM [6] nedovoluje m´ıt pojmenovány dvˇe tabulky stejnˇe, a to ani napˇr´ıˇc r˚uznými databázemi), atributy neboli sloupeˇcky jsou téˇz výstiˇznˇe popsány a u modelu vid´ıme i jejich datový typ s maximáln´ı povolenou délkou znak˚u. Tabulky jsou vzájemnˇe propojeny relacemi ve standardu Crow’s Foot [13]. Lze tedy vyˇc´ıst, ˇze distributor spravuje v´ıce da- tabáz´ı a zaˇr´ızen´ı, ale kaˇzdá databáze resp. zaˇr´ızen´ı spadá pod jednoho distributora, zprávy (dotazy do KMB pro zaloˇzen´ı nové databáze) maj´ı svého jasného odes´ılatele, uˇzivatelé (koncov´ı zákazn´ıci) spadaj´ı do jedné databáze.

Obrázek 5.1: Konceptuáln´ı model centráln´ı databáze pro KMB Visio

5.1.2 Uˇ zivatelsk´ e datab´ aze

V naˇsem pˇr´ıpadˇe se mysl´ı ta databáze, která uchovává data o namˇeˇrených hodnotách a dalˇs´ım nastaven´ı dle zmiˇnované specifikace. Jej´ı návrh byl jiˇz sloˇzitˇejˇs´ı, jelikoˇz

(24)

se zde pracuje s v´ıce nesourodými datovými typy mˇeˇrených veliˇcin. Celý výsledný model je na obrázku 5.5. Nejzaj´ımavˇejˇs´ımi tabulkami jsou tabulky measurements a measurement raws, které ukládaj´ı namˇeˇrené hodnoty. Nyn´ı bude popsáno, proˇc a jak se mˇenila jejich struktura.

Verze 1.x

Prvn´ı verze struktury pro ukládán´ı mˇeˇren´ı dat se skládala pouze z jedné tabulky, viz obrázek 5.2, která byla pouze nositelem údaj˚u o mˇeˇren´ı. Pokud chtˇel tedy uˇzivatel zobrazit nˇejaké mˇeˇren´ı, trvalo zpracován´ı do výsledné podoby pˇr´ıliˇs dlouho. Nad ˇrádky bylo sice uˇzito index˚u [26], nicménˇe indexy problém s rychlost´ı vˇzdy neˇreˇs´ı.

Nejpomalejˇs´ım ˇclánkem procesu z´ıskán´ı dat bylo aˇz zpracován´ı dat na úrovni aplikace. SQL dotaz najde historii dat pro konkrétn´ı zaˇr´ızen´ı a jednu jeho mˇeˇrenou veliˇcinu za posledn´ı dva dny. Jelikoˇz je nad touto kombinac´ı vytvoˇren index, je doba vykonán´ı poˇzadavku optimáln´ı. Následnˇe je potˇreba proj´ıt mˇeˇren´ı za jeden den a upravit ˇcasovou ˇradu dle konfigurace. K zjiˇstˇen´ı agregace je tˇreba dalˇs´ıho SQL dotazu. Upravená data je tˇreba vrátit ve formátu JSON, kde kl´ıˇcem je ˇcas mˇeˇren´ı a hodnotou je pole mˇeˇren´ı vˇzdy ve stejný ˇcas pro daný den. Tato struktura v˚ubec neˇreˇs´ı chybˇej´ıc´ı hodnoty v ˇcasové ˇradˇe, tud´ıˇz se m˚uˇze stát, ˇze výsledná agregace bude obsahovat neplatné hodnoty. Uˇzit´ı datového typu varchar nen´ı téˇz správný zp˚usob (zbyteˇcnˇe zab´ırá m´ısto v pamˇeti, potˇreba pˇretypován´ı na ˇc´ıselné typy pˇri matematických operac´ı). Dalˇs´ım problémem je rychle rostouc´ı objem tabulky - pokud by zaˇr´ızen´ı mˇeˇrilo byt’ jen jednu veliˇcinu za minutu, za celý den poˇsle do databáze 1440 záznam˚u.

Vˇsechny tyto podnˇety vedly tedy k opuˇstˇen´ı od tohoto návrhu a ke snaze naj´ıt jiný zp˚usob ukládán´ı dat. Dalˇs´ı výsledný model byl jiˇz propracovanˇejˇs´ı, i tak byl nicménˇe stále nepouˇzitelný. Pozornost byla zamˇeˇrena na lepˇs´ı uˇzit´ı datových typ˚u.

Sloupeˇcek value byl smazán a pˇribyly dva nové, jeden value f loat (pro ˇc´ıselné hodnoty), druhý value text (pro binárn´ı pole). Jak název napov´ıdá, jejich datový typ odpov´ıdal postfixu v názvu, bylo povoleno hodnoty null, která nezab´ırá ˇzádné m´ısto v pamˇeti [10], [30]. Postup pro z´ıskán´ı dat byl obdobný jako v pˇredchoz´ım pˇr´ıpadˇe, rozd´ılem bylo pouze vybrat ten ze sloupeˇck˚u, který nenabývá hodnoty null.

Výsledkem bylo pouze nepatrné zmenˇsen´ı velikosti a oˇsetˇren´ı pˇri ukládán´ı nových hodnot do správných sloupc˚u. Úprava je znázornˇena na obrázku5.3

Verze 2.x

Tuto verzi lze povaˇzovat za revoluˇcn´ı, jelikoˇz mnohem lépe ˇreˇs´ı problémy spjaté s re- alizac´ı pˇredchoz´ıch návrh˚u. Poˇrád bylo uˇzito tabulky measurement raws z verze 1.0, ale byl nasazen skript, který kontroloval, zda pˇr´ıstroj odeslal celou ˇcasovou ˇradu (1440 hodnot pro jeden den). Pokud ano, byla tato data uloˇzena do tabulky measurements minutes a z tabulky measurement raws byla daná ˇrada odstranˇena.

Struktura je na obrázku5.4 T´ım bylo doc´ıleno, ˇze z p˚uvodn´ıch 1440 ˇrádk˚u vznikne pouze jeden s mnohem menˇs´ı velikost´ı. ˇCasová ˇrada se opˇet transformovala do JSON objektu, kde kl´ıˇcem je ˇcas mˇeˇren´ı, a hodnotu mˇeˇrená veliˇcina (ukazatel okamˇzikové

(25)

Obr´azek 5.2: Prvn´ı verze tabulky pro z´aznam mˇeˇren´ı

Obrázek 5.3: Druhá verze tabulky pro záznam mˇeˇren´ı

ˇrady), tento objekt byl poté php funkc´ı unpack() pˇreveden do binárn´ıho pole a uloˇzen do databáze. Z´ıskáván´ı dat vˇsak stále nebylo optimáln´ı. Doba dotazu byla mnohem rychlejˇs´ı, jelikoˇz ˇcasové ˇrady byly brány z tabulky measurements minutes, pra- covalo se pˇritom pouze se dvˇema ˇrádky, které bylo tˇreba funkc´ı pack() dekódovat a agregovat, stejnˇe jako v prvn´ı ˇcásti. V této verzi byl vyˇreˇsen i problém s da- tovými typy hodnot veliˇcin. Tabulka measurement raws obsahovala znovu pouze jeden sloupec value datového typu float. Ukládán´ı ˇc´ıselných hodnot bylo tedy lo- gicky i koncepˇcnˇe správnˇe. Binárn´ı pole byla pˇrevedena do dekadické soustavy a téˇz uloˇzena do sloupeˇcku value, pro jednoduˇs´ı identifikaci, zda je hodnota ve zm´ınˇeném sloupci binárn´ı ˇci nikoliv, pˇribyl dalˇs´ı sloupec binary, který tuto informaci poskytuje.

Toto ˇreˇsen´ı bylo postupnˇe optimalizováno aˇz do výsledné podoby, která bˇeˇz´ı v posledn´ı verzi aplikace (datováno k bˇreznu 2018), kde ke kaˇzdému zaˇr´ızen´ı známe jeho aktuáln´ı agregaˇcn´ı interval (v jakých ˇcasových úsec´ıch zobrazovat data uˇzivateli).

Proto bylo navrˇzeno n´asleduj´ıc´ı. Tabulka measurements minutes zmˇenila n´azev na measurements, a byla obohacena o dalˇs´ı dva sloupeˇcky is f ull a group interval.

Ukládán´ı prob´ıhalo stejnˇe jako v pˇredchoz´ı ˇcásti - uloˇz´ı se celá ˇcasová ˇrada s hodnotou group interval rovnou jedné. Následnˇe byla tato ˇrada upravena na poˇzadovaný poˇcet hodnot dle agregaˇcn´ıho intervalu a uloˇzena jako samostatný ˇrádek, s hodnotou group interval podle aktuáln´ıho nastaven´ı. Pokud je tedy agregaˇcn´ı interval roven ˇsedesáti, ˇcasová ˇrada se skládá pouze z dat namˇeˇrených v kaˇzdou celou hodinu jednoho dne. Tato modifikace (neboli pracovnˇe pojmenováno merge akce) m˚uˇze opˇet dle konfigurace data ukládat bud’ aˇz po pˇrijet´ı vˇsech hodnot za celý den, nebo po ˇcástech. Pokud je pˇrij´ımá po ˇcástech, je is f ull nastaven na nulu, v opaˇcném pˇr´ıpadˇe na hodnotu jedna. Pokud je ˇrada nekompletn´ı, postupnˇe se do n´ı pˇridávaj´ı novˇe dostupná data a poté, co je plná, se pˇr´ısluˇsná data smaˇzou z tabulky measurement raws. Výsledné schéma je na obrázku 5.5.

Pˇred aplikován´ım výˇse popisované verze bylo zamýˇsleno, ˇze by se data rovnou ukládala do measurements, ˇc´ımˇz by se tabulka measurement raws, ze které se pr˚ubˇeˇzné odmazávaj´ı data, v˚ubec nemusela pouˇz´ıvat. Nakonec se tento návrh nere-

(26)

alizoval, jelikoˇz by záznam pro jednu ˇcasovou ˇradu musel být pˇri kaˇzdé nové hodnotˇe aktualizován. Aktualizace by nesla i dalˇs´ı d´ılˇc´ı kroky, poˇc´ınaje pˇrevodem z binárn´ı podoby do normáln´ıho pole, pˇridán´ı nové hodnoty a kontrolu na úplnost ˇcasové ˇrady, pokud by tato byla úplná, agregovat (dˇr´ıve by to nemˇelo smysl) a uloˇzit jako nový záznam, a v posledn´ı ˇradˇe pˇrevést do binárn´ıho pole a následnˇe uloˇzit. Aˇckoliv by tato verze uloˇzen´ı zab´ırala ménˇe m´ısta, sn´ıˇzila by se aktuáln´ı rychlost skriptu, který data modifikuje.

Obrázek 5.4: Struktura tabulky, co uchovává ˇcasovou ˇradu v jednom ˇrádku

Obrázek 5.5: Konceptuáln´ı model uˇzivatelské databáze pro KMB Visio

5.2 NoSQL datab´ aze

Zm´ınˇené SQL databáze vyˇzaduj´ı pˇresnou strukturu ukládán´ı dat, dodrˇzován´ı normáln´ıch forem, ˇci dodrˇzován´ı principu ACID. Toto zaˇc´ınalo být postupnˇe nevýhodné vzhle-

(27)

dem k poˇzadavk˚um na modern´ı aplikace (cloud, ˇskálovatelnost, grafové ukládán´ı, aj.). D´ıky tˇemto poˇzadavk˚um zaˇcaly vznikat nové databáze, které se oznaˇcuj´ı jako NoSQL (Not Only SQL). Hlavn´ımi rozd´ıly oproti SQL databáz´ım je, ˇze nevyuˇz´ıvaj´ı relaˇcn´ı model a struktury pro ukládán´ı dat. V SQL databáz´ıch mluv´ıme o tabulkách a jejich atributech, které jsou urˇcitého datového typu. Existuje nˇekolik model˚u, jak ukládat data. Konkrétnˇe mluv´ıme o tˇechto: kl´ıˇc-hodnota, dokumentový model, sloupcový model a grafový model. Samostatným modelem je i model pro ukládán´ı ˇcasových ˇrad. Oproti SQL databáz´ım, kde se pro práci s daty uˇz´ıvá jazyka SQL, NoSQL databáze nemaj´ı ˇzádný standardn´ı jazyk [23].

5.2.1 Ukl´ ad´ an´ı ˇ casov´ ych ˇ rad do MongoDB

Jako výsledná NoSQL databáze byla vybrána MongoDB [5]. Jedná se o dokumen- tový model databáze. Dokumentem m˚uˇze být XML ˇci JSON formát, v principu se jedná o rozˇs´ıˇrený model kl´ıˇc-hodnota, kde hodnotou je právˇe zmiˇnovaný dokument. Vzhledem k ukládán´ı dat by se vˇsak nab´ızelo uˇzit´ı databáze pro ˇcasové ˇrady, MongoDB bylo nicménˇe vybráno hned z nˇekolika d˚uvod˚u. Jednak se jedná o nej- pouˇz´ıvanˇejˇs´ı NoSQL databázi [2], zm´ınˇený JSON dokument je vhodný pro výsledné rozhran´ı (KMB Visio API), kde se taktéˇz pracuje s JSON objekty. Dalˇs´ım rozhodo- vac´ım faktorem bylo i jednoduché napojen´ı databázového ovladaˇce do prostˇred´ı La- ravel, viz podkapitola6.3.1. Aˇckoliv tento dokumentový model nevyˇzaduje ukládat data v pˇredem dané struktuˇre, i tak bylo potˇreba se zamyslet, jak nejlépe ˇcasové ˇrady ukládat. Jeden návrh vycházel pˇr´ımo ze zdrojového csv, kde kl´ıˇcem byla kombinace ˇcasu namˇeˇren´ı a identifikátor zaˇr´ızen´ı. Hodnotou pak následnˇe asociativn´ı pole, kde kl´ıˇcem byla mˇeˇrená veliˇcina a hodnotou namˇeˇrený údaj. Z´ıskán´ı dat pro danou veliˇcinu v urˇcitých ˇcasech je pak pˇri správnˇe sloˇzeném dotazu velice rychlé.

Data nicm´enˇe nejsou tak spolehliv´a a robustn´ı a jsou silnˇe nekonzistentn´ı.

5.3 Shrnut´ı

Rozhodnout se, zda uˇz´ıt SQL ˇci NoSQL databázi nen´ı jednoduchá otázka [16]. Vˇzdy závis´ı na konkrétn´ım typu aplikace a mnoˇzinˇe ukládaných dat. Podle [38] by roz- hoduj´ıc´ım faktorem mˇel být brán podle ˇcasu odezvy nejˇcastˇeji vykonávaného dotazu. V této aplikaci jde nejˇcastˇeji o vkládán´ı nových dat. V MongoDB nám na to staˇc´ı jedna operace vloˇzen´ı, pro výsledný databázový model SQL databáze je tˇreba n dotaz˚u, kde n pˇredstavuje poˇcet mˇeˇrených veliˇcin pˇrijatých v jednom mˇeˇren´ı.

Uloˇzen´ı je tedy v pˇr´ıpadˇe NoSQL jednoduˇsˇs´ı na reˇzii, ovˇsem velikost uloˇzených dat se nˇekolikanásobnˇe zvˇetˇsuje. Zrychlen´ı bylo zapˇr´ıˇceno i t´ım, ˇze se zde nekon- troluj´ı datové typy, tud´ıˇz pro binárn´ı data nemusela být provádˇena konverze do dekadické soustavy. Na zpˇetnou analýzu (reverse engineering) za úˇcelem optimali- zace databázového modelu téˇz nen´ı MongoDB vhodné, jelikoˇz z uloˇzených dat nelze snadno zjistit, jak se struktura mˇenila. Právˇe pro rychle se mˇen´ıc´ı strukturu je Mon- goDB doporuˇcované, nicménˇe relaˇcn´ımu modelu byl vˇenován dostatek ˇcasu a pro aktuáln´ı verzi aplikace je brán jako dostateˇcný.

(28)

6 Principy a technologie pro v´ yvoj webov´ ych sluˇ zeb a aplikac´ı

Výsledné rozhran´ı má být implementováno jako webová sluˇzba. Webová sluˇzba je urˇcena pro výmˇenu dat mezi klientem a n´ı, dle pˇredem daných pravidel. Pravidly mohou být napˇr´ıklad struktura a formát pˇrenáˇsených dat, zp˚usob autentizace uˇzivatel˚u, uˇzit´ı pˇrenosového protokolu. Jsou dva pˇr´ıstupy, jak vytváˇret webové sluˇzby [25].

Prvn´ı moˇznost´ı je vyuˇz´ıt SOAP protokolu, který je v dneˇsn´ı dobˇe jiˇz zastaralý, ale i tak poˇrád hojnˇe pouˇz´ıvaný. Druhou moˇznost´ı je vyuˇz´ıt pˇr´ıstupu architektury REST neboli RESTfull [31]. Vybrat vhodnou technologii je opˇet záleˇzitost´ı poˇzadavk˚u na výslednou aplikaci, ale i zde existuje pár doporuˇcen´ı, podle jakých kritéri´ı ˇreˇsen´ı vybrat. SOAP vlastnˇe definuje, jak kódovat hlaviˇcku HTTP a soubor XML, aby si dva r˚uzné programy mohly mezi sebou vymˇeˇnovat informace. Zpráva (envelope) se skládá z hlaviˇcky (head) a tˇela (body). Obdobou SOAPu je RPC komunikace, téˇz re- alizovaná HTTP protokolem. Kromˇe výmˇeny dokument˚u lze volat i vzdálené funkce programu beˇz´ıc´ıho na serveru. REST architekturu jako prvn´ı definoval Roy Fielding (jeden ze spoluzakladatel˚u HTTP protokolu) ve své disertaˇcn´ı práci ”Architectu- ral Styles and the Design of Network-based Software Architectures”[14]. Výsledné API bˇeˇz´ı na této architektuˇre z toho d˚uvodu, ˇze se zde nemus´ı vyuˇz´ıvat XML pro výmˇenu obsahu zpráv a je lépe vyuˇzito HTTP protokolu. Posledn´ım d˚uvodem je i veliké mnoˇzstv´ı tutoriál˚u pro tvorbu rozhran´ı nad touto architekturou.

6.1 HTTP protokol

HTTP (HyperText Transfer Protocol) je aplikaˇcn´ı protokol, d´ıky kterému spolu m˚uˇzou komunikovat klient a server. Protokol je jakýsi pˇredpis pro zp˚usob výmˇeny dat mezi zmiˇnovanými stranami. Dotaz, který odes´ılá klient na server, se nazývá request, odpovˇed’ ze serveru pro klienta je response. Jedná se o bezstavový protokol - server nerozpozná, jestli komunikuje stále s jedn´ım a t´ım samým klientem, nebo dotazy na nˇej chod´ı od r˚uzných klient˚u. Stavový protokol je napˇr´ıklad protokol SMTP, kde je spojen´ı otevˇrené po celou dobu komunikace. Výhody bezstavového protokolu jsou jednoduchost na pouˇzit´ı a niˇzˇs´ı náklady na reˇzii pro obˇe strany.

V dalˇs´ıch ˇcást´ı této podkapitoly se opˇet zamˇeˇruji pouze na kl´ıˇcové ˇcásti, zejména v souvislosti s REST architekturou [15].

(29)

6.1.1 Metody

Komunikace klienta se serverem mus´ı prob´ıhat podle pˇredem daných pravidel. Jedn´ım z tˇechto pravidel je komunikovat skrze metody, podle kterých server jednoznaˇcnˇe urˇc´ı, co klient vyˇzaduje a co má s daty udˇelat. V kontextu s vývojem REST aplikac´ı se nˇekdy m´ısto pojmu metoda uˇz´ıvá slovo verb - tento výraz je mnohem výstiˇznˇejˇs´ı.

RFC definuje pro HTTP nˇekolik metod, mezi hlavn´ı se ˇrad´ı POST (vytvoˇren´ı nového zdroje), GET (z´ıskán´ı dat o konkrétn´ım zdroji), PUT (modifikace daného zdroje), DELETE (smazán´ı daného zdroje). Je-li k dispozici tato sada, dá se nad nimi stavˇet aplikace, která plnohodnotnˇe podporuje CRUD operace [39]. Mezi dalˇs´ı metody patˇr´ı i tˇreba HEAD, OPTIONS, CONNECT a TRACE. S RFC 5789 pˇriˇsly i metody PATCH, LINK a ULINK. Metody lze dˇelit na bezpeˇcné a idempotetn´ı, kde pro bezpeˇcné metody plat´ı, ˇze by nemˇely mˇenit data na serveru a odpovˇed’ by mˇela být vˇzdy stejná. Pokud bude volána metoda GET nad konkrétn´ım zdrojem, vrácená odpovˇed’ bude vˇzdy stejná, t´ımto tvrzen´ım je GET zároveˇn i idempotetn´ı metodou. Naopak neidempotetn´ı metodu je tˇreba POST - pˇri vytvoˇren´ı nového zdroje se stejnými daty budeme dostávat vˇzdy jinou odpovˇed’, jelikoˇz bude vytvoˇreno v´ıce unikátn´ıch zdroj˚u, liˇs´ıc´ı se napˇr. o atributy id, created, aj.

6.1.2 Hlaviˇ cka a tˇ elo

Hlaviˇcky jsou ned´ılnou souˇcást´ı pro komunikaci skrze HTTP. Informace v nich jsou jakási metadata, která pˇresnˇe popisuj´ı, co je obsahem dotaz˚u a odpovˇed´ı.

HTTP uvád´ı pˇres 40 hlaviˇcek, v pˇr´ıpadˇe potˇreby si mohou programátoˇri vytvoˇrit svoje vlastn´ı. Hlaviˇcky, se kterými se lze nejˇcastˇeji setkat, jsou: Accept, Accept- Charset,Allow, Authorization, Cache-Control,Content-Type, Location. Tˇelo zprávy nebo-li body m˚uˇze nabývat r˚uzných formát˚u (JSON, XML, HTML, prostý text, . . . ). Jedná se o konkrétn´ı data, která si vymˇeˇnuje klient se serverem, pokud je uˇzito HTTPS komunikace, nen´ı je tˇreba ˇsifrovat. Hlaviˇcka a tˇelo zprávy jsou oddˇeleny jedn´ım prázdným ˇrádkem, v ukázce 2 je pˇr´ıklad registrace nového uˇzivatele.

POST /kmb-visio-api/public/register HTTP/1.1 Host: localhost

Content-Type: application/json Cache-Control: no-cache

Authorization: Bearer 6ae608ea382f072d12f5f872cd064990

{

"email" : "john@doe.com",

"password" : "9963af2f7748a3df6dd3cc24cc150684a7ba4e03",

"name" : "John Doe"

}

Uk´azka 2: Poˇzadavek na server - registrace nov´eho uˇzivatele

(30)

6.1.3 Zabezpeˇ cen´ı komunikace

Prvotn´ım krokem k zabezpeˇcen´ı je uˇzit´ı HTTPS. Je tvoˇren HTTP a SSL ˇci TLS certifikátu a zaruˇcuje pˇredevˇs´ım d˚uvˇeryhodnost a integritu pˇrenáˇsených dat mezi klientem a serverem [41]. K tomu vˇsemu uˇz´ıvá asymetrického ˇsifrován´ı [29]. Lara- vel podporuje m´ıt API funkˇcn´ı pouze pˇri uˇzit´ı HTTPS, ˇcehoˇz bylo vyuˇzito. Dalˇs´ı

´

urovn´ı zabezpeˇcen´ı je ovˇeˇrován´ı uˇzivatel˚u, kteˇr´ı komunikuj´ı se sluˇzbou, byt’ se jedná o pouhé z´ıskán´ı dat konkrétn´ıch zdroj˚u. V nejhorˇs´ım moˇzném pˇr´ıpadˇe by mohli i data metodou DELETE mazat.

Autentizace a autorizace uˇzivatel˚u prob´ıh´a nejˇcastˇeji tˇremi moˇzn´ymi zp˚usoby.

Prvn´ım z nich je pomoc´ı Basic Authorization (nˇekteré zdroje uvád´ı i Basic Auth), kde se v kaˇzdém dotazu odes´ılá jméno a heslo oddˇelené dvojteˇckou zakódované v Base64. V tomto pˇr´ıpadˇe je nutné, aby komunikace bˇeˇzela na protokolu HTTPS, jinak by pˇri útoku Main in the Middle mohlo doj´ıt k z´ıskán´ı tˇechto citlivých údaj˚u.

Pˇri pˇrijet´ı requestu server ´udaje dek´oduje a ovˇeˇr´ı, zda poˇzadavek pˇrijme ˇci nikoliv.

Dalˇs´ı moˇznost´ı je HMAC autorizace, kde obˇe strany znaj´ı tajný kl´ıˇc, kterým ˇsifruj´ı pˇredem daný identifikátor klienta. Následnˇe je vytvoˇren otisk (v HMAC se uˇz´ıvá pojem podpis) hashovac´ı funkc´ı, napˇr. SHA-2 a odesláno v autorizaˇcn´ı hlaviˇcce.

Server prvnˇe zjist´ı (z URL, ˇci tˇela zprávy), kdo se ho pokouˇs´ı kontaktovat a sám stejnými kroky jako klient vytvoˇr´ı podpis. Pokud jsou podpisy od klienta a od serveru shodné, server pokraˇcuje ve zpracován´ı poˇzadavku. Modern´ı API dnes nab´ız´ı autorizaci skrze protokol OAuth2. Pˇri jeho uˇzit´ı si uˇzivatelé pro komunikaci se serverem nemus´ı vytváˇret uˇzivatelský úˇcet, protoˇze lze vyuˇz´ıt sluˇzeb, které OAuth implementuj´ı (Facebook, Github, LindedIn, Shibboleth). Pˇri úspˇeˇsné autorizaci server vrát´ı tzv. API kl´ıˇc s ˇcasovou platnost´ı, kterým se uˇzivatelé autorizuj´ı pˇri dalˇs´ı komunikaci se serverem [19], [22].

6.1.4 Stavov´ e k´ ody

S kaˇzdou odpovˇed´ı, kterou server vrac´ı, pˇricház´ı i stavový kód. Jedná se o tˇr´ım´ıstné ˇc´ıslo, které pˇri správném pouˇzit´ı m˚uˇze klientovi ihned zpracovat výsledek a nemus´ı se sloˇzitˇe zpracovávat slovn´ı odpovˇed’. Ke kódu se pak následnˇe pˇripojuje i jedno- duchá slovn´ı odpovˇed’, která výstiˇznˇe popisuje výsledek jak probˇehlo zpracován´ı od klienta na serveru. RFC skupiny kódu urˇcuje pouze na základˇe hodnoty na ˇrádu stovek. Kaˇzdý vývojáˇr si m˚uˇze nadefinovat vlastn´ı kódy, nicménˇe prvn´ı ˇc´ıslice by vˇzdy mˇela odpov´ıdat standard˚um. Informaˇcn´ı zprávy jsou ve tvaru 1XX, vyuˇz´ıvaj´ı se pro informován´ı klienta, zda server jeho poˇzadavku vyhov´ı. Pokud ano, vrát´ı tento kód a klient odeˇsle zprávu i s tˇelem. Toto lze vyuˇz´ıt pro zprávy, jenˇz maj´ı rozsáhlý obsah dat. Pˇr´ıkladem je odeslán´ı záznamu o mˇeˇren´ı, kde je velký objem odes´ılaných dat. Klient postupuje jako pˇri odes´ılán´ı zprávy s daty, ale bez nich.

Jsou-li splnˇeny vˇsechny náleˇzitosti (platné hlaviˇcky), m˚uˇze poté odeslat poˇzadavek i s POST daty. Je-li poˇzadavek úspˇeˇsný (z´ıskán´ı platného zdroje, pˇridán´ı nového, ˇci modifikace), je vracena odpovˇed’ ve tvaru 2XX, která spadá do skupiny Success

(31)

(tento výraz se nepˇrekládá, ale m˚uˇzeme ˇr´ıct, ˇze se jedná o úspˇeˇsné stavy). Spolu se stavovými kódy jsou d˚uleˇzité i pˇrijaté hlaviˇcky, protoˇze dalˇs´ı skupina Redirect, pˇrekládaná jako Pˇresmˇerován´ı (3XX), v hlaviˇcce Location obsahuje informaci, kam byl daný zdroj pˇrem´ıstˇen, napˇr. zmˇenou struktury API. Pˇresmˇerovac´ı kód slouˇz´ı i pro oznámen´ı, ˇze daný zdroj nebyl od posledn´ıho poˇzadavku zmˇenˇen. Tyto stavy je dobré pouˇz´ıvat, pokud chceme klient˚um umoˇznit ukládat si zdroje do nˇejaké formy mezipamˇeti (cache). V tomto pˇr´ıpadˇe se nab´ız´ı uloˇzen´ı do souboru v JSON formátu, tak jako jej vrac´ı sluˇzba. Uˇzivatelské chyby (4XX) jsou vraceny na základˇe chybnˇe zaslaného poˇzadavku na server. Nejznámˇejˇs´ı chybou, se kterou pˇriˇsla do styku témˇeˇr vˇetˇsina uˇzivatel˚u webových sluˇzeb a aplikac´ı, je 404 Not Found, která informuje, ˇze na dané adrese se zdroj nenacház´ı. Mezi uˇzivatelské chyby patˇr´ı i pˇr´ıstup ke zdroji nepovolenou HTTP metodou (405), kde by se v optimáln´ım pˇr´ıpadˇe mˇel v hlaviˇcce Allow vrátit seznam dovolených metod. Dále chybová autorizace (401), chybný formát odes´ılaných dat (415) nebo odeslán´ı mnoho poˇzadavk˚u v krátkém ˇcase (429). Posledn´ı skupinou stavových kódu (5XX) jsou chyby vzniklé na serveru, nejznámˇejˇs´ı je stav 500, intern´ı chyba serveru.

6.2 Webov´ e aplikace

Výsledné ˇreˇsen´ı je implementováno jako webová aplikace (sluˇzba). Webová aplikace bˇeˇz´ı v oknˇe prohl´ıˇzeˇce a komunikuje po protokolu HTTP, viz. sekce 6.1. Výhodami jsou ˇzádná instalace a ani aktualizace na stranˇe klienta, uˇzivatelská data jsou pˇritom uloˇzena na produkˇcn´ım serveru, popˇr´ıpadˇe v cloudu. Urˇcité fragmenty stránek lze jednoduˇse sd´ılet pomoc´ı konkrétn´ıho url. Nevýhodami je nutnost neustálého pˇripojen´ı k internetu, r˚uzné podpory pro prohl´ıˇzeˇce a r˚uzné velikosti zobrazovac´ıch zaˇr´ızen´ı.

Nˇekteré prohl´ıˇzeˇce ukládaj´ı data v mezipamˇeti (cache) kv˚uli zvýˇsen´ı rychlosti naˇc´ıtán´ı, napˇr. javascriptové soubory, a pˇri zmˇenˇe jádra aplikace se klientovi nemus´ı zmˇeny ihned projevit. Dále je potˇreba m´ıt na pamˇeti i konfiguraci serveru - pokud pouˇzijeme framework vyuˇz´ıvaj´ıc´ı vyˇsˇs´ı verzi PHP neˇz je nainstalovaná na aplikaˇcn´ım serveru, nemus´ı vˇse stoprocentnˇe fungovat.

6.2.1 Architektura MVC

MVC architektura se ˇrad´ı k návrhovým vzor˚um pro tvorbu webových aplikac´ı [11].

Tento pattern oddˇeluje logiku (Model) od výstupu (View), pˇriˇcemˇz dvˇe vrstvy spo- juje Controller. Zjednoduˇsenˇe lze toto chován´ı popsat následovnˇe. Uˇzivatel zadá url adresu, která skrze router volá definovaný controller pro danou url. Pokud url neexistuje, server vrát´ı chybovou hláˇsku, nejˇcastˇeji chyba 404 Not found. Volaná funkce (která um´ı pˇrej´ımat parametry, jeˇz byly souˇcást´ı url) controlleru si vyˇzádá od Mo- delu pˇr´ısluˇsná data. Model vˇetˇsinou pracuje s databáz´ı. Controller data od Modelu zpracuje do podoby vhodné pro uˇzivatele a pˇredá je View (napˇr. html ˇsablona).

Uˇzivateli se vrát´ı data ve zmiˇnované ˇsablonˇe. Nad MVC lze stavˇet i webové sluˇzby.

Pokud by v budoucnu API nemˇelo fungovat jako API, ale jako klasick´a webov´a aplikace, staˇcilo by pouze routy zapsat do konfiguraˇcn´ıch soubor˚u pro webovou aplikaci

(32)

a vytvoˇrit pˇr´ısluˇsné html ˇsablony. MVC pattern ˇr´ıká, ˇze Model nev´ı, kdo s jeho daty a jak pracuje, podobnˇe tomu je i u View - ten analogicky nev´ı odkud data pocházej´ı.

6.3 V´ ybˇ er technologi´ı pro v´ yvoj

Tvorba komplexn´ıch webových aplikac´ı se odráˇz´ı od znalost´ı jednotlivých programovac´ıch jazyk˚u a ostatn´ıch moˇznost´ı pro vývoj s nimi spojených. Zde je nutné m´ıt povˇedom´ı o objektovˇe orientovaném programován´ı v jazyce PHP, umˇet správnˇe a rozumnˇe modelovat databáze (k tomu se váˇze i znalost jazyka SQL), vˇedˇet co je to HTML, kaskádové styly (CSS) a javascript. Vzhledem k tomu, ˇze pˇredchoz´ı zkuˇsenost s tˇemito prostˇredky byla nezbytným pˇredpokladem této práce, nen´ı jim v textu jiˇz vˇenována bliˇzˇs´ı pozornost. Nejkl´ıˇcovˇejˇs´ı fáz´ı práce a celého projektu je bezesporu API ˇcást (rozhran´ı pro záznam a zpˇetnou reprezentaci dat klient˚um), proto zde bylo nutné zvolit co nejlepˇs´ı technologii pro jej´ı návrh. Po pˇredchoz´ıch zkuˇsenostech s vývojem webových aplikac´ı bylo i zde rozhodnuto vyuˇz´ıt existuj´ıc´ıch framework˚u. Práce s frameworkem umoˇzˇnuje rychlý vývoj aplikace a nen´ı nutno napˇr. psát vlastn´ı ˇreˇsen´ı MVC architektury, které je pro vˇsechny aplikace stejné.

V´yhody uˇzit´ı frameworku jsou k nalezen´ı zde [24].

Výsledný framework byl zvolen podle toho, aby v sobˇe obsahoval co nejv´ıce modul˚u pro co nejjednoduˇsˇs´ı tvorbu API. Konkrétnˇe tedy mluv´ıme o:

1. Podpora routov´an´ı pro tvorbu RESTful API.

2. Odpovˇedi ve form´atu json.

3. Implementace autentizace uˇzivatel˚u bez knihoven tˇret´ıch stran.

4. Schopnost pracovat s r˚uzn´ymi typy datab´az´ı (relaˇcn´ı, NoSQL).

5. Dobr´a dokumentace.

Podle hodnocen´ı server˚u Hongiat [24] a Codersye [1], vlastn´ım otestován´ım vy- braných ˇreˇsen´ı - Laravel, Nette s addonem Uplaboo ApiRouter a vyzkouˇsen´ım napsán´ı vlastn´ıho ˇreˇsen´ı s vyuˇzit´ım r˚uzných existuj´ıc´ıch bal´ıˇck˚u se jako vhodná volba pro napsán´ı API jevilo vyuˇzit´ı PHP framework Laravel.

6.3.1 Laravel

PHP framework Laravel vznikl jako open source projekt pod MIT licenc´ı, jehoˇz zakladatelem je Taylor Otwell. Prvn´ı verze je datována k pˇrelomu roku 2011 a 2012 [28]. Detailn´ı popsán´ı funkˇcnosti a chován´ı by zdaleka pˇrekraˇcovalo rozsah této práce, proto byly vybrány jen nejkl´ıˇcovˇejˇs´ı, jedineˇcné vlastnosti oproti ostatn´ım ˇreˇsen´ım ˇcást´ı frameworku.

(33)

Composer a instalace

Composer je program, který stahuje knihovny pro projekty postavené nad PHP. Jiné programovac´ı jazyky disponuj´ı podobnými sluˇzbami - Python vyuˇz´ıvá program pip, NodeJS zase bal´ıˇcek nmp. Oproti tˇemto sluˇzbám vˇsak Composer stahuje knihovny a závislosti vˇzdy pro daný projekt, zmiˇnované alternativy pro jiné jazyky je instaluj´ı globálnˇe. Knihovny jsou stahovány ze vzdáleného serveru Packagist.org, pokud se vˇsak bal´ıˇcek v repositáˇri nevyskytuje, lze jej pˇridat do sloˇzky projektu manuálnˇe.

V obou dvou pˇr´ıpadech pak staˇc´ı zapsat dle poˇzadované syntaxe do konfiguraˇcn´ıho souboru composer.json a spustit proceduru pro aktualizaci bal´ıˇck˚u. T´ımto z´ıskáme základn´ı kostru projektu. Z Packagist repositáˇre se kromˇe samostatných knihoven daj´ı stáhnout i frameworky, coˇz je jedna moˇznost jak framework z´ıskat. Druhá - a v´ıce doporuˇcovaná - moˇznost instalace je pˇr´ımo pˇres sluˇzbu Laravel Installer, která je dalˇs´ı nadstavbou Composeru. Oba pˇr´ıkazy ke staˇzen´ı jsou v následuj´ıc´ı ukázce zdrojového kódu:

composer create-project --prefer-dist laravel/laravel nazev_projektu composer global require "laravel/installer"

laravel new nazev_projektu

Uk´azka 3: Instalace Laravel frameworku a projektu

Pr´ace s datab´azemi a knihovna Jenssengers/MongoDB

Dalˇs´ı silnou stránkou Laravelu jsou jeho pˇr´ıstupy pro práci s databáz´ı. Konkrétnˇe jde o databázové migrace a moˇznost za bˇehu aplikace pouˇz´ıvat r˚uzné databáze (MySQL, NoSQL). V konfiguraˇcn´ım souboru database.php se do pole connections pˇridá dalˇs´ı nastaven´ı pro databázi s identifikátorem, d˚uleˇzité je zm´ınit atribut driver (typ databáze). Pro MongoDB bylo tˇreba doinstalovat opˇet velice populárn´ı bal´ıˇcek Jenssegers/Laravel-mongodb. Bal´ıˇcky této tˇr´ıdy jsou odvozeny od origináln´ıch tˇr´ıd ze základn´ı instalace Laravelu, tud´ıˇz pak pˇri práci s databáz´ı nen´ı nutno rozliˇsovat, s jakou aktuáln´ı databáz´ı se pracuje. Staˇc´ı pˇridat pouze promˇennou connections, která odpov´ıdá identifikátoru v config/database.php [33]. Migrace jsou schémata jednotlivých databázových tabulek. Výhoda migrac´ı spoˇc´ıvá v tom, ˇze danou da- tabázovou tabulku jednou nadefinujeme, pˇredáme ji databáze (identifikátory z kon- figuraˇcn´ıho souboru) nad kterými má migrace probˇehnout a pˇri spuˇstˇen´ı migraˇcn´ıho skriptu php artisan migrate se dané tabulky vytvoˇr´ı. Pˇr´ınosem je i to, ˇze schéma da- tabáz´ı je souˇcást´ı projektu (coˇz napˇr. Nette nepodporuje) a v pˇr´ıpadˇe, ˇze je projekt verzován, lze se jednoduˇse dostat i na souˇcasnou verzi databáze.

Routov´an´ı

Mezi základn´ı kameny frameworku - celkovˇe i pro jakoukoliv webovou aplikaci patˇr´ı bezpodm´ıneˇcnˇe router, neboli smˇerovaˇc. Jeho primárn´ım úkolem je zpracovat url

(34)

'connections' => [

'kmb_visio_main' => [

'driver' => 'mysql',

'host' => '127.0.0.1',

'port' => "3306",

'database' => "22631_kmb_visio_main", 'username' => "root",

'password' => 'root', 'unix_socket' => '', 'charset' => 'utf8',

'collation' => 'utf8_czech_ci',

'prefix' => '',

'strict' => true,

'engine' => null,

], ],

Uk´azka 4: Konfiguraˇcn´ı soubor pro datab´aze

a zavolat pˇr´ısluˇsný controller; pokud controller neexistuje, je vrácena nejˇcastˇeji chyba 404 Not found. V zdrojovém kódu5je ukázka definice dvou rout (v Laravelu).

Prvn´ı je pro pˇrihlaˇsován´ı uˇzivatel˚u - pokud je zavolaný zdroj login() metodou POST, zavolá se metoda login z controlleru LoginController v jmenném prostoru Auth.

Pokud chceme, aby byl zdroj pˇr´ıstupný pouze pro autorizované uˇzivatele, vloˇz´ıme pˇr´ısluˇsné routy do pomyslné obálky. Pˇri zavolán´ı druhého zdroje v ukázce je pˇri

´

uspˇeˇsném zpracován´ı vrácena historie mˇeˇren´ı s daným sériovým (unikátn´ım) ˇc´ıslem.

Chce-li uˇzivatel historii mˇeˇren´ı pouze pro jednu veliˇcinu, odeˇsle poˇzadavek i s pa- rametrem measurand id. D´ıky tomuto zápisu je moˇzno rychle a snadno pˇridávat a upravovat dalˇs´ı routy, napˇr´ıklad zmˇena HTTP metody, úprava parametr˚u aj.

Route::post('login', 'Auth\LoginController@login');

Route::group(['middleware' => 'auth:api'], function {

Route::get("devices/{serial_number}/hist/{measurand_id?}",

"MeasurementController@getAllDeviceHistory");

});

Uk´azka 5: Definice rout v prostˇred´ı Laravel

6.3.2 Ostatn´ı n´ astroje

Nette

Nette je dalˇs´ım z php framework˚u, který spadá pod Nette Foundation a jeho hlavn´ım autorem je David Grudl. Prvn´ı verze byla vydána v roce 2009, je tˇret´ım nejpo- pulárnˇejˇs´ım frameworkem na svˇetˇe [35]. V ˇCeské a Slovenské republice se vˇsak jedná

(35)

o v˚ubec nejv´ıce rozˇs´ıˇrený framework, nad kterým bˇeˇz´ı spousta aplikac´ı. Kromˇe sa- motného autora se na jeho vývoji pod´ıl´ı i ˇsiroká programátorská komunita. Jeho silnou výhodou je, ˇze se skládá z modul˚u, které funguj´ı nezávisle na existenci jakýchkoli jiných modul˚u. M˚uˇze se jednat napˇr´ıklad o modul formuláˇr˚u, ˇsablonovac´ı systém Latte, Tracy neboli Ladˇenka pro debugován´ı a zpracováván´ı chyb. Tento framework splˇnuje vˇsechny mnou definované podm´ınky, a proto byl vybrán k naprogramován´ı klientské aplikace [18]. Jelikoˇz klientská ˇcást nen´ı pro význam této práce tak d˚uleˇzitá, nebudu zde Nette hloubˇeji popisovat. D˚uvod, proˇc klient nen´ı psán ve stejném frameworku, slouˇz´ı jako demonstrace toho, ˇze se jedná o dvˇe naprosto odliˇsné aplikace, které spolu nicménˇe pˇri správném pouˇzit´ı mohou úspˇeˇsnˇe komunikovat, aniˇz by pro- gramátor vˇedˇel, jak bude druhá strana fungovat. D´ıky tomu lze API pouˇz´ıt naprosto v jakémkoliv frameworku a dokonce i v aplikac´ıch, které nejspu psané v jazyce PHP.

Grafick´e frameworky

Chart.js je javascriptová knihovna, která obsahuje nˇekolik r˚uzných typ˚u graf˚u [17].

Knihovna je pod licenc´ı MIT. Vybrána byla na základˇe hodnocen´ı serveru [40]. Jako jedno z mála open-sourcových ˇreˇsen´ı je tato knihovna plnˇe responzivn´ı a proto byla vybrána. Jej´ımi dalˇs´ımi pˇrednostmi jsou jednoduchost pˇri konfiguraci grafu, moˇznost stáhnout pouze vybrané grafy (napˇr. sloupcový) - coˇz má vliv na velikost a t´ım i rychlost naˇc´ıtán´ı, dále pak pro vykreslován´ı vyuˇz´ıvá HTML5 canvas. Semantic UI je css framework, který nab´ız´ı komplexn´ı ˇreˇsen´ı vˇsech komponent, které se bˇeˇznˇe objevuj´ı na webové stránce. Jedná se o open-source projekt pod MIT licenc´ı. Názvy selektor˚u jsou pojmenovány v pˇr´ıvˇetivé formˇe, snaˇz´ı se o co nejlepˇs´ı napodoben´ı lidského jazyka, coˇz umoˇzˇnuje pˇrehlednost a srozumitelnost ve zdrojovém kódu [34].

Stejnˇe jako Nette framework jej vyuˇz´ıv´am pˇres ˇctyˇri roky a vyskytuje se rovnˇeˇz v prvn´ıch pˇeti nejlepˇs´ıch css frameworc´ıch podle hodnocen´ı serveru Hackeroon [37].

Knihovna Guzzle

Klientská ˇcást má dle specifikace pro práci s daty vyuˇz´ıvat výhradnˇe navrˇzené rozhran´ı (KMB Visio), proto bylo tˇreba naj´ıt vhodný zp˚usob, jak vnˇe klientské ˇcásti s t´ımto rozhran´ım komunikovat. ˇReˇsen´ım je knihovna GuzzleHttp, která je velice jednoduchá na pouˇzit´ı. Nam´ısto programu cURL, který ani nemus´ı být vˇsude nain- stalován (jedná se o nástroj pˇr´ıkazové ˇrádky), je i odes´ılán´ı http poˇzadavk˚u mnohem jednoduˇsˇs´ı a ménˇe pracné. Umoˇzˇnuje i odes´ılán´ı asynchronn´ıch dotaz˚u na server a v pˇr´ıpadˇe zmˇeny v API je úprava volán´ı v Guzzle jednoduˇsˇs´ı neˇz v cURL [12]. Do Nette existuje pˇr´ımo rozˇs´ıˇren´ı Guzzlette, tato tˇr´ıda vˇsak nebyla vyuˇzita z toho d˚uvodu, ˇze je na Nette závislá a pokud by byla klientská ˇcást implementována v jiném frameworku, musela by se tato mezivrsta naprogramovat znovu.

Postman - n´astroj pro testov´an´ı API

Ani proces návrhu API se nevyhnul testován´ı, které bylo ned´ılnou souˇcást´ı vytvoˇren´ı kvalitn´ı knihovny. Jednou ze základn´ıch moˇznost´ı testován´ı je napˇr´ıklad utilitou cURL v pˇr´ıkazové ˇrádce, která nicménˇe zaˇcne být ˇcasem nepohodlná. Pˇri sestavován´ı

(36)

dotaz˚u lze lehce doj´ıt k chybˇe, odpovˇedi nejsou pˇr´ıliˇs uˇzivatelsky pˇr´ıvˇetivé a nelze snadno prohl´ıˇzet historii request˚u na API. To nav´ıc nejsou jediné nevýhody, a proto bylo pouˇzito programu Postman, který výˇse zm´ınˇené nedostatky eliminuje [36]. Apli- kace disponuje velice pˇr´ıjemným uˇzivatelským prostˇred´ım, které lze pouˇz´ıvat jako desktopovou aplikaci, nebo jako rozˇs´ıˇren´ı v prohl´ıˇzeˇci Google Chrome. Dalˇs´ı výhodou Postmanu je ukládán´ı jednotlivých dotaz˚u a odpovˇed´ı do kolekc´ı, které se daj´ı sd´ılet mezi dalˇs´ı uˇzivatele k vzájemnému testován´ı naˇseho API.