Datový sklad k technologiím budov

M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

}

w A| y < 5 4 23 1 0 / -. , )+ ( %&' $ # !"

Æ

Datový sklad k technologiím budov D IPLOMOVÁ PRÁCE

Bc. Jan Rokyta

Brno, jaro 2013

Prohlášení Prohlašuji, že tato diplomová práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.

Bc. Jan Rokyta

Vedoucí práce: doc. RNDr. Tomáš Pitner, Ph.D. i

Podˇekování Dˇekuji vedoucímu práce doc. RNDr. Tomáši Pitnerovi, Ph.D. a dále kolegum ˚ z Oddˇelení facility managementu SUKB a bývalého oddˇelení GIS ÚVT za konzultace. Zejména dˇekuji Mgr. Adamu Kuˇcerovi za vytvoˇrení aplikace pro syntaktickou analýzu rˇ ídicích programu. ˚

ii

Shrnutí Pˇredmˇetem práce je analýza datových zdroju˚ vztahujících se k provozu budov a návrh postupu pro zpˇrístupnˇení a archivaci vybraných dat, vˇcetnˇe vytvoˇrení prototypu. Poˇcáteˇcní kapitoly obsahují úvod do problematiky a popis zvolené metodiky, poté pˇrehled možných zdroju˚ dat a specifické vlastnosti vybraných z nich. V praktické cˇ ásti je sestaven návrh rˇ ešení od konceptuálního pˇres logický a fyzický model, následuje kapitola popisující vlastní implementaci. Výsledkem je úložištˇe obsahující záznamy systému rˇ ízení budov (Building Management System), technologického pasportu a dalších zdroju, ˚ tvoˇrící platformu pro další využití dat.

iii

Klíˇcová slova Building management system, data mart, datový sklad, Dimensional Fact Model, SSIS, SQL Server 2012, Technologický pasport MU.

iv

Obsah 1 2

3

4

5

Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metodika v souvislostech . . . . . . . . . . . . . . . . . . . . 2.1 Historické pozadí . . . . . . . . . . . . . . . . . . . . . . 2.2 Souˇcasnost, významní hráˇci . . . . . . . . . . . . . . . . 2.3 Metodická východiska . . . . . . . . . . . . . . . . . . . 2.3.1 Fáze návrhu data martu . . . . . . . . . . . . . . 2.3.2 Dimensional Fact Model . . . . . . . . . . . . . 2.3.3 Pˇrístup Microsoft . . . . . . . . . . . . . . . . . . Možné zdroje dat . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Stavební pasport . . . . . . . . . . . . . . . . . . . . . . 3.2 Technologický pasport . . . . . . . . . . . . . . . . . . . 3.3 Dokumentace stavebních projektu˚ . . . . . . . . . . . . 3.4 Technologická sít’ . . . . . . . . . . . . . . . . . . . . . . 3.5 Archivní data BMS . . . . . . . . . . . . . . . . . . . . . 3.6 Data systému Archibus . . . . . . . . . . . . . . . . . . . 3.7 Data IS BAPS . . . . . . . . . . . . . . . . . . . . . . . . 3.8 Data systému˚ monitorování provozu sítˇe . . . . . . . . 3.9 Další zdroje . . . . . . . . . . . . . . . . . . . . . . . . . 3.10 Vybrané zdroje . . . . . . . . . . . . . . . . . . . . . . . . Specifika prostˇredí . . . . . . . . . . . . . . . . . . . . . . . . 4.1 BMS a technologická sít’ . . . . . . . . . . . . . . . . . . 4.2 Stavební a technologický pasport . . . . . . . . . . . . . Návrh rˇešení . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Architektura . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Analýza a úprava datových zdroju˚ . . . . . . . . . . . . 5.2.1 HistorianDB – archivní data BMS . . . . . . . . 5.2.2 Technologický pasport . . . . . . . . . . . . . . 5.2.3 Dokumentace stavebních projektu˚ . . . . . . . . 5.2.4 Analýza rˇ ídících programu˚ v technologické síti 5.2.5 Shrnutí . . . . . . . . . . . . . . . . . . . . . . . 5.3 Požadavky . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Sbˇer uživatelských požadavku˚ . . . . . . . . . . 5.4 Konceptuální návrh . . . . . . . . . . . . . . . . . . . . . 5.4.1 Identifikace faktu˚ . . . . . . . . . . . . . . . . . 5.4.2 Atributy . . . . . . . . . . . . . . . . . . . . . . . 5.4.3 Dimenze . . . . . . . . . . . . . . . . . . . . . . . ˇ . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.4 Cas

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 3 3 4 5 6 7 9 10 10 11 11 11 12 12 12 13 13 14 15 15 18 21 21 23 23 26 27 28 29 29 30 33 33 33 34 34 v

6

7 A B C D E

5.4.5 Umístˇení v BMS . . . . . . . . . . . . . . . . . . . 5.4.6 Umístˇení v prostoru . . . . . . . . . . . . . . . . . 5.5 Logický návrh . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.1 Otázka denormalizace . . . . . . . . . . . . . . . . 5.5.2 Otázka granularity . . . . . . . . . . . . . . . . . . ˇ 5.5.3 Casová dimenze . . . . . . . . . . . . . . . . . . . 5.5.4 Klíˇce . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.5 Míry . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.6 Aditivita . . . . . . . . . . . . . . . . . . . . . . . . 5.5.7 Pˇrevod konceptuálního modelu na logický . . . . 5.5.7.1 Dimenzionální tabulky . . . . . . . . . . 5.5.7.2 Subdimenze . . . . . . . . . . . . . . . . 5.5.7.3 Faktové tabulky . . . . . . . . . . . . . . 5.6 Návrh zpracování dat . . . . . . . . . . . . . . . . . . . . ˇ 5.6.1 Casová platnost dat . . . . . . . . . . . . . . . . . 5.7 Fyzický návrh . . . . . . . . . . . . . . . . . . . . . . . . . 5.7.1 Indexování . . . . . . . . . . . . . . . . . . . . . . 5.7.2 Pokroˇcilé metody správy dat pro velké databáze Popis implementace . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Použité metody prubˇ ˚ ežného získání dat . . . . . . . . . . 6.1.1 Dimenze . . . . . . . . . . . . . . . . . . . . . . . . 6.1.2 Faktové tabulky . . . . . . . . . . . . . . . . . . . 6.2 Definice struktury . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Balíˇcek StageDB_struktura . . . . . . . . . . . . . 6.2.2 Balíˇcek TDM_struktura . . . . . . . . . . . . . . . 6.3 Pˇrístup k datum ˚ a plnˇení oblasti zpracování . . . . . . . . 6.3.1 Balíˇcek Mereni_stazeni . . . . . . . . . . . . . . . 6.3.2 Balíˇcek Udalosti_stazeni . . . . . . . . . . . . . . 6.3.3 Balíˇcek TP_stazeni . . . . . . . . . . . . . . . . . . 6.4 Mapování BMS TP . . . . . . . . . . . . . . . . . . . . . . 6.4.1 Balíˇcek Pomocne_zdroje . . . . . . . . . . . . . . . 6.5 Plnˇení TDM . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5.1 Balíˇcek TDM_plneni . . . . . . . . . . . . . . . . . Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Slovník pojmu˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . ER model HistorianDB a TP . . . . . . . . . . . . . . . . . . . Ukázka rˇídícího programu . . . . . . . . . . . . . . . . . . . . Ukázky struktury SSIS balíˇcku˚ . . . . . . . . . . . . . . . . . . Datová pˇríloha . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34 35 35 37 38 39 39 40 40 41 42 44 44 45 46 46 47 49 50 51 51 52 52 52 52 53 53 54 54 55 55 56 57 61 66 69 70 71 72

vi

1 Úvod Masarykova univerzita (MU) zažívá v posledních nˇekolika letech období rychlého rozvoje zejména v oblasti výstavby nových budov. Dosud je evidováno pˇres 150 vlastních objektu˚ s více než 22 000 místnostmi, což pˇredstavuje celkovou plochu asi 384 000 metru˚ cˇ tvereˇcních [26]. V roce 2013 probíhá nebo je naplánováno devˇet investiˇcních akcí zahrnující výstavbu deseti nových budov a rekonstrukci rˇ ady stávajících. To s sebou v dnešní dobˇe pˇrináší i znaˇcné požadavky na technické vybavení, zejména pak technologie sloužící k zajištˇení podmínek v budovˇe, jako je vzduchotechnika, vytápˇení, osvˇetlení atp. Souˇcasným trendem je budovat takzvané inteligentní budovy, jejichž hlavním pˇrínosem má být propojení dílˇcích systému˚ a tím i zjednodušení jejich monitorování a rˇ ízení. Pokud se jedná nikoliv o samostatné domy, ale o celou lokalitu sestávající z nˇekolika desítek budov, jakou je napˇríklad Univerzitní kampus Bohunice, tato úloha získává ponˇekud jiný rozmˇer. K tomu, aby bylo možné areál budovaný v prubˇ ˚ ehu nˇekolika let z pohledu technologií ucelenˇe spravovat, tedy mít ideálnˇe k dispozici nástroje pro vzdálený pˇrístup k rozhraním jednotlivých zaˇrízení, je tˇreba zvolit dostateˇcnˇe silný prostˇredek integrace. Zde byl zvolen protokol BACnet, který umožnuje ˇ prvkum ˚ rˇ ídícího systému budovy (tzv. Building management system, BMS) komunikovat, v tomto pˇrípadˇe s využitím infrastruktury tzv. technologické sítˇe. Prostˇredí BMS MU je dále rozebráno v cˇ ásti 4.1. Jednotné prostˇredí rˇ ízení budov pˇrináší rˇ adu výhod, napˇríklad možnost globálnˇe sledovat dˇeje v systému a v kontextu této práce pak zejména možnost archivace dat z provozu technologií. Jednotlivé datové body, které reprezentují napˇr. cˇ idla, spínaˇce, ventily apod., jsou na základˇe urˇcitého pˇredpisu sledovány a údaje z nich mohou být dlouhodobˇe ukládány, aby bylo možné vyhodnocovat prubˇ ˚ eh hodnot v cˇ ase. Ukazuje se ale, že takto vytvoˇrené záznamy, kterých je znaˇcné množství (aktuálnˇe pˇres 300 miliónu, ˚ nashromáždˇených bˇehem témˇerˇ šesti let provozu postupnˇe se rozšiˇrujícího systému), je bez odpovídajících prostˇredku˚ obtížné pˇrijatelným zpusobem ˚ vyhodnocovat. Data jsou ukládána do relaˇcních databází, odkud mohou být extrahována pro další analýzu, nicménˇe ad-hoc pˇrístup pˇrestal být pro stále se zvyšující množství monitorovaných vstupu˚ a rostoucí nároky na získané informace vyhovující. Možným rˇ ešením je vytvoˇrení úložištˇe zamˇerˇ eného na analýzu dat, které by na rozdíl od tˇechto tzv. transakˇcních databází bylo optimalizované pro cˇ tení, se strukturou odpovídající potˇrebám analytiku˚ BMS i ostatních uživatelu. ˚ Jde o tzv.

1

1. Ú VOD datový sklad (data warehouse) cˇ i data mart 1 (ˇceský pˇreklad datové tržištˇe není pˇríliš zaužívaný a obsah tohoto pojmu neodpovídá intuici, proto je v následujícím textu použit anglický termín), plnˇený daty zdrojových databází a tvoˇrící platformu pro další vyhodnocování. Návrh a implementace pilotního projektu tohoto úložištˇe je úkolem této práce. Kromˇe zmínˇeného úložištˇe pro data provozu budov existují další zdroje dat, která mají nˇejaký vztah k provozu budov a u kterých je tˇreba zvážit, nakolik je možné je v datovém skladu (ˇci data martu) využít. Touto otázkou se zabývá kapitola 3. Nejvýznamnˇejším v této oblasti je Stavební a Technologický pasport MU (dále stavební, technologický pasport, SP, TP). Jde o systém správy zejména geografických dat o budovách, vyvinutý na Masarykovˇe univerzitˇe. Stavební pasport se zabývá daty jednotlivých staveb (místností, podlaží, lokalit), tvorbou pudorys ˚ u˚ a modelu. ˚ Do kontextu SP jsou pak zasazována data o technickém vybavení budov (které cˇ asto souvisí s výše zmínˇenou oblastí rˇ ízení provozu budovy), tedy technologický pasport. Vzhledem k tomu, že oblast zájmu (resp. popisované objekty) BMS a technologického pasportu se cˇ ásteˇcnˇe pˇrekrývá, nabízí se možnost tato data integrovat. Tím by bylo umožnˇeno obohatit data provozu rˇ ídícího systému budovy o údaje z evidence zaˇrízení, tedy zejména jejich skuteˇcné umístˇení, ale i další atributy. Nicménˇe tato integrace není triviálnˇe realizovatelná, v této práci je uvažována pouze pro potˇreby analytického úložištˇe, tedy na úrovni archivních dat. V kapitole 2 je uvedeno nˇekolik poznámek o oblasti zpracování dat v moderní dobˇe, dále struˇcný pohled na aktuální vývoj v této oblasti a nakonec popis zvolené metodiky. Po již zmínˇené tˇretí kapitole následuje popis prostˇredí, do kterého je práce zasazena, v kapitole 4. Dvojice závˇereˇcných kapitol popisuje návrh a implementaci Technologického data martu (TDM), jak byl projekt nazván.

1. Pojmem data mart je zpravidla oznaˇcováno menší, specializovanˇejší úložištˇe, cˇ asto odvozené z datového skladu.

2

2 Metodika v souvislostech 2.1

Historické pozadí

Potˇreba zpracovávání dat roste v prubˇ ˚ ehu dˇejin v závislosti na rozvoji stále komplexnˇejších lidských spoleˇcenstev a technologických systému, ˚ ostatnˇe významným milníkem v dˇejinách automatizované práce s daty je vytvoˇrení stroje pro potˇreby sˇcítání obˇcanu˚ USA v roce 1890. Spoleˇcnost Hermana Holleritha, tvurce ˚ tohoto stroje, se pozdˇeji stala základem pro korporaci IBM [2]1 . Další vývoj poˇcítaˇcu˚ pak byl akcelerován zejména díky vojenským potˇrebám, at’ už šlo o 2. svˇetovou válku a stroje pro šifrování a dešifrování, nebo následnˇe poˇcítaˇce sloužící k provádˇení výpoˇctu˚ pˇri vývoji atomové a pozdˇeji vodíkové bomby [19]. Nicménˇe tyto stroje nevyužívaly databáze v dnešním slova smyslu, jejich práce s daty se omezovala na obsloužení vstupu, výstupu a vnitˇrní pamˇeti. Pˇrehled historie datových skladu, ˚ systému˚ pro podporu rozhodování (decision support systems, DSS) a obecnˇe zpracování elektronických dat uvádí Inmon [21, Kapitola 1, cˇ ást The Evolution], zde následuje struˇcný výtah. V prubˇ ˚ ehu šedesátých let minulého století došlo na tomto poli k významnému posunu. Rozvoj poˇcítaˇcových systému˚ vedl zárovenˇ k masivnímu nárustu ˚ množství ukládaných dat, která byla v té dobˇe ukládána sekvenˇcnˇe na magnetických páskách. Správa tˇechto úložišt’ a související úkoly, jako vývoj a údržba strojového vybavení, zaˇcala být neudržitelná. Poˇcátkem 70. let se objevila nová technologie pˇrímého pˇrístupu k datum, ˚ v souvislosti s tím pak rovnˇež tzv. systém pro rˇ ízení báze dat (termín se však zpravidla nepˇrekládá, rozšíˇrenˇejší je Database Management System, DBMS). Dále v 70. letech s nástupem tzv. online transaction processing (OLTP) mohlo dojít k rozvoji informaˇcních systému, ˚ které se již svou podstatou zaˇcaly blížit dnešnímu pojetí - napˇr. rezervaˇcní a bankovní systémy, rˇ ízení výroby atd. Pojem OLAP, tedy online analytical processing, jako de facto protiklad k OLTP, byl zaveden v roce 1993 E. F. Coddem (který je také autorem konceptu relaˇcních databází) [15, 24]. Spolu s tímto termínem pˇrichází i multidimenzionální modelování, analytická (OLAP) kostka atp. Jde o stále platnou doktrínu pˇrerodu dat v informace, kterou dnes vnímáme spíše skrze 1. Jinou kapitolou je pak role IBM pˇri podobném úkolu pro nacistické Nˇemecko, viz [29], i když je tato aféra spoleˇcností IBM bagatelizována ([5]). Každopádnˇe jde o pouˇcnou ukázku možností výpoˇcetní techniky a hromadného zpracování dat.

3

2. M ETODIKA V SOUVISLOSTECH termín Business Intelligence (viz napˇr. [16]), obecnˇeji pak jako již zmínˇené systémy pro podporu rozhodování. Ještˇe o rok dˇríve však byla publikována klíˇcová kniha Building the Data Warehouse od Williama Inmona, která je jednou ze základních publikací v oboru datových skladu. ˚ V roce 1996 pak Ralph Kimball vydal The Data Warehouse Toolkit, neménˇe duležitou ˚ publikaci. Tyto dvˇe knihy stojí na poˇcátku dvou odlišných pˇrístupu˚ k návrhu datových skladu, ˚ které jsou dodnes aktuální, budou proto zmínˇeny i v následující cˇ ásti. Samotný termín datový sklad byl však použit již v 70. letech právˇe W. Inmonem ([38]), stejnˇe tak koncept faktu˚ a dimenzí pochází z 60. let, data mart pak ze 70. let ([22, s. 16]), nicménˇe moderní pojetí datového skladu je zpravidla datováno do konce 80. let, kdy byla publikována práce An architecture for a business and information system B. Devlina a P. Murphyho, kteˇrí zde použili termín business data warehouse v dnešním významu tohoto pojmu.

2.2

Souˇcasnost, významní hráˇci

Pˇrestože se oblast datových skladu˚ (nyní cˇ asto oznaˇcovaných jako EDW, Enterprise data warehouse) stále rozvíjí, mužeme ˚ rˇ íci, že jde o dobˇre definované a uznávané odvˇetví IT, která má za sebou desetiletí vývoje. Dnes se již objevují názory, že se tento koncept pˇrežil a bude nahrazen prostˇrednictvím tzv. big data, jež se nyní zdá být na vrcholu, cˇ i dokonce už za vrcholem tzv. hype curve (ˇcesky obˇcas jako kˇrivka humbuku) [30]. Spíše je však pravdˇepodobné, že - jak se domnívá i již zmínˇený Barry Devlin - nastane nˇejaká forma koexistence obou svˇetu˚ [14, 36]. Možným scénáˇrem muže ˚ být i prezentace tˇechto údaju˚ (tedy z oblasti big data - napˇr. Hadoop - spoleˇcnˇe s daty EDW) tak, aby z uživatelského pohledu byly jednotné a fakticky vzájemnˇe nerozpoznatelné [31]. Jak již bylo zmínˇeno, v oboru datových skladu˚ existují dvˇe hlavní školy, které jsou zpravidla oznaˇcovány jmény svých zakladatelu, ˚ Inmona a Kimballa (nejde pochopitelnˇe o jediné možné pˇrístupy, existují ruzné ˚ alternativy, nicménˇe tyto dva lze i vzhledem k dobˇe vzniku považovat za základní). Rozbor a srovnání jednotlivých pˇrístupu˚ byl proveden už nesˇcetnˇekrát2 , vzhledem k tomu, že díla ani jednoho z autoru˚ nebyla použita jako primární zdroj pro tuto práci, není dle mého názoru nezbytné je zde hloubˇeji rozebírat a porovnávat. V kostce se dá rˇ íci, že Inmon zakládá svuj ˚ pˇrí2. Viz napˇr. [11], již dle názvu je patrné, že jde srovnání dvou zdánlivˇe nesluˇcitelných pˇrístupu. ˚ Ukazuje se však, že tomu tak vždy být nemusí (vyjadˇruje se tak údajnˇe i sám Inmon [13])

4

2. M ETODIKA V SOUVISLOSTECH stup na centrálním datovém skladu, který je budován jako normalizované datové úložištˇe, které je strukturované s ohledem na pˇredmˇet zájmu, data jsou zde dlouhodobˇe archivována s minimem zmˇen, lze sledovat trendy v cˇ ase, a koneˇcnˇe, tento datový sklad v sobˇe zahrnuje co nejvˇetší poˇcet dostupných zdroju˚ a tím zajišt’uje integritu dat (zpravidla napˇríˇc korporací) [21, Kapitola 2]. Základem Kimballova pˇrístupu je pak dimenzionální modelování, jehož varianta je popsána v 2.3.2. Integrita dat je zajištˇena pomocí takzvané sbˇernice (Data Warehouse Bus Architecture), která propojuje jednotlivé data marty prostˇrednictvím sdílených dimenzí [22, Kapitola 3]. Co se týˇce spoleˇcností zabývajících se nástroji pro data warehousing, v souˇcasné dobˇe (tedy v roce 2013) mužeme ˚ podle analytiku˚ spoleˇcnosti Gartner jmenovat šest vedoucích hráˇcu˚ na tomto poli. Jde o (v pˇribližném poˇradí od nejvýznamnˇejšího) Teradata, Oracle, IBM, SAP, Microsoft a EMC [12]. Produkty jednotlivých firem pochopitelnˇe mají svá specifika, výhody a nevýhody, nicménˇe vzhledem k možnostem projektu TDM není tˇreba provádˇet srovnání a výbˇer platformy3 . Pro tuto práci bylo zvoleno rˇ ešení spoleˇcnosti Microsoft, a to z nˇekolika duvod ˚ u, ˚ z nichž nejvýznamnˇejším je dostupnost potˇrebného software. Nicménˇe dalšími duvody, ˚ proˇc zvolit SQL Server, je fakt, že jak nástroj pro archivní data BMS, tak stavební a technologický pasport jsou spravovány pomocí tˇechto DBMS, lze tedy oˇcekávat nejmenší potíže s kompatibilitou. Kromˇe toho Microsoft nabízí pomˇernˇe široké spektrum nástroju˚ (napˇríklad široce rozšíˇrený MS Excel), které lze použít pro potˇreby analýzy dat, a mohou tak tvoˇrit s úložištˇem dat ucelený systém (jakkoliv je zde již možné pozorovat pˇríznaky vendor lock-in).

2.3

Metodická východiska

Hlavním zdrojem informací pˇri návrhu úložištˇe byla kniha Data Warehouse Design: Modern Principles and Methodologies ([18]), která se velice podrobnˇe vˇenuje všem fázím celého procesu. Nebere v úvahu žádný konkrétní software pro návrh ani realizaci díla, je zamˇerˇ ena teoreticky. Naopak silnˇe prakticky zamˇerˇ ená je pˇríruˇcka ke kurzu Implementing a Data Warehouse with Microsoft SQL Server 2012 ([25]) spoleˇcnosti Microsoft, jejíž zamˇerˇ ení je popsáno v 2.3.3. Oba zdroje jsou však v souladu co se týˇce základních architektonických rysu, ˚ tedy použití (multi)dimenzionálního modelo3. Tím není rˇ eˇceno, že je relevantní provádˇet výbˇer pouze z této skupiny, ostatnˇe jsem pˇresvˇedˇcen o tom, že kvalitní rˇ ešení lze realizovat i napˇr. s použitím freeware cˇ i open source nástroju˚ a jejich kombinací, jeden pˇríklad za všechny muže ˚ být CloverETL dostupný v použitelné verzi zdarma, navíc je poskytována i open source knihovna pro datové transformace, viz http://www.cloveretl.com/)

5

2. M ETODIKA V SOUVISLOSTECH vání - faktových a dimenzionálních tabulek, hierarchií apod. (tyto pojmy jsou zavedeny v 2.3.2). Výsledkem je kombinace obou pˇrístupu. ˚ 2.3.1

Fáze návrhu data martu

Tato cˇ ást se vˇenuje postupu tvorby datového skladu navrženému v [18], pˇredevším pak popisu vybraných fází. •

Analýza a úprava datových zdroju˚

•

Analýza požadavku˚

•

Konceptuální návrh

•

Logický návrh

•

Návrh zpracování dat

•

Fyzický návrh

Analýza a úprava datových zdroju˚ V této úvodní fázi je tˇreba zmapovat dostupné datové zdroje a zpracovat schéma datové vrstvy urˇcené pro naplnˇení data martu ([18, s. 51]). Souˇcástí je také transformace dat a jejich vzájemných vztahu˚ a zhodnocení jejich kvality. V pˇrípadˇe použití více zdroju˚ je pak pochopitelnˇe tˇreba sjednotit jejich schémata (pokud nejsou k dispozici, vytvoˇrit modely tˇechto databází za využití shodné notace, napˇr. ERD). Analýza požadavku˚ Další fází je analýza uživatelských požadavku, ˚ k cˇ emuž lze využít ruz˚ ných technik, od neformálního interview po formalizované pˇrístupy. Dále by mˇely být identifikovány fakty (viz 2.3.2) a s nimi související granularita, neboli stupenˇ detailu ukládaných dat. Výsledky této fáze jsou pak použity pˇri konceptuálním návrhu. Konceptuální návrh První etapa návrhu vychází jednak ze struktury vstupních dat, a rovnˇež z uživatelských požadavku˚ (v jakém pomˇeru jsou tyto dva vstupy zohlednˇeny závisí na zvoleném pˇrístupu, viz [18, s.54]). Aplikaci této metody konceptuálního návrhu lze vidˇet v 5.4. 6

2. M ETODIKA V SOUVISLOSTECH Logický návrh V této fázi je rˇ ešen pˇrevod konceptuálního modelu na logický, tedy definice tabulek faktu˚ a dimenzí, uspoˇrádaných v tzv. hvˇezdicovém schématu (star schema, pˇrípadnˇe alternativˇe nazvané snˇehová vloˇcka - snowflake schema). Dalším tématem jsou pohledy na data, jejich materializace a fragmentace. Návrh zpracování dat Hlavním cílem této cˇ ásti je sestavení procedur pro plnˇení data martu (pˇrípadnˇe vrstvy zpracování dat). Jde o takzvané ETL procedury, z Extract Transform Load. Je tedy zˇrejmé, že jde po rˇ adˇe o získání dat, jejich úpravu a oˇcištˇení a následnˇe nahrání do finálního umístˇení. Fyzický návrh Kromˇe volby konkrétního databázového stroje je zde rˇ ešena otázka indexování dat (jedná se o klíˇcový aspekt významnˇe ovlivnující ˇ výkon data martu), dále problematika fyzického ukládání dat (redundance a dˇelení). 2.3.2

Dimensional Fact Model

Souˇcástí metodiky dle [18] je i postup pro tvorbu konceptuálních modelu˚ nazvaný Dimensional Fact Model (DFM) [18, s. 103]. Ten byl sestaven pˇrímo pro dimenzionální modelování data martu, ˚ což je jeden z duvod ˚ u, ˚ proˇc byl vybrán. Takto vytvoˇrené modely jsou dobˇre cˇ itelné a snadno pochopitelné, zárovenˇ je ale metodika kvalitnˇe teoreticky podepˇrena. Nevýhodou DFM je malá rozšíˇrenost (možná kvuli ˚ akademickému puvodu) ˚ a s tím související nepˇríliš velké množství anglicky psaných materiálu. ˚ Dusledkem ˚ je pak i nedostatek kvalitních nástroju˚ používajících tento zpusob ˚ zápisu. Základem DFM je stejnˇe jako u multidimenzionálního modelování, ze kterého vychází, trojice pojmu˚ – fakt, dimenze a míra (fact, dimension, measure). Pojem fakt popisuje skupinu událostí, ke kterým dochází v rámci sledovaného prostˇredí. Jinak rˇ eˇceno, jedná se o záznamy jednotlivých dˇeju, ˚ obvykle zasazené alesponˇ do cˇ asového a prostorového kontextu. Tˇemto kontextum ˚ rˇ íkáme dimenze. Dále fakty mohou mít jistou míru, což je jejich mˇerˇ itelná, numerická vlastnost. Pomocí uvedených entit je modelována struktura dat tak, aby bylo možné se v nich orientovat na základˇe bˇežného úsudku, nebot’ výsledné modely by mˇely co nejvíce odpovídat uživatelskému pohledu. 7

2. M ETODIKA V SOUVISLOSTECH

Obrázek 2.1: Ukázka DFM (pˇrevzato z [18])

Ukázka schématu pro fakt Prodej s pˇríslušnými dimenzemi znázornuje ˇ obrázek2.1. Na této ukázce budou demonstrovány i další pojmy DFM. Jedná se zejména o primární událost, což je výskyt daného faktu identifikovaný n-ticí hodnot pro každou dimenzi (a hodnotou pro každou míru). S tímto pojmem úzce souvisí granularita, neboli úrovenˇ detailu. Pokud je dostaˇcující znát souhrn prodeju˚ daného produktu v dané prodejnˇe za den, lze použít zobrazené schéma - které ale neobsahuje napˇríklad informace o cˇ asu prodeje nebo prodavaˇci, který prodej realizoval. S takto jednoduchým modelem pochopitelnˇe nelze vystaˇcit, proto je tˇreba zavést další prvky. Jedná se o rozvinutí konceptu dimenzí do tzv. hierarchií, které se skládají z jednotlivých dimenzionálních atributu. ˚ Hierarchie popisuje vztahy mezi jednotlivými atributy, jedná se o orientovaný strom, jehož uzly jsou dimenzionální atributy a hrany znázornují ˇ vazby s kardinalitou 1:N mezi jednotlivými dvojicemi. Smˇerem od koˇrene (kterým je vlastní dimenze, napˇríklad Produkt) tedy vychází hrana do atributu Typ produktu. Potom platí, že Typ produktu je jednoznaˇcnˇe urˇcen Produktem (N produktu, ˚ 1 Typ), lze rˇ íci, že Typ je na Produktu funkcionálnˇe závislý (podobnˇe jako u ER modelování) – viz obrázek 2.1. Následuje popis vybraných pokroˇcilých prvku˚ DFM, které byly použity pˇri modelování Technologického data martu. Prvním z nich jsou popisné atributy, které mohou být pˇripojeny k jednotlivým dimenzionálním atributum, ˚ ale neslouží k agregaci, cˇ asto nemají koneˇcný obor hodnot. Z pohledu hierarchie jako stromu jsou popisné atributy vždy listy. Mezidimenzionální atributy jsou závislé 8

2. M ETODIKA V SOUVISLOSTECH na více dimenzích - typicky napˇr. výše DPH muže ˚ záviset na typu zboží, tedy atributu dimenze Produkt, a na státu, kde je zboží prodáváno, tedy geografické dimenzi. Násobné hrany se používají v pˇrípadˇe, že vazba mezi dimenzionálními atributy má vˇetší kardinalitu než 1:N, tedy na rodiˇcovském atributu ve stromˇe závisí více než jeden uzel. Na pˇríkladu Produktu by to byl pˇrípad, kdy Produkt spadá do více Typu˚ (tˇemto Typum ˚ pak muže ˚ být pˇriˇrazena ruzná ˚ váha tak, aby bylo možné podle nich agregovat). Nepovinné hrany spojují rodiˇcovský uzel s uzlem, který pro daný fakt nemusí nabývat žádné hodnoty (v pˇrípadˇe, že primární událost tento atribut postrádá). Nekompletní hierarchie jsou takové, jejichž nˇekteré prvky mohou být pro danou primární událost vynechány. Rozdíl mezi nekompletními hierarchiemi a nepovinnými hranami je ten, že v pˇrípadˇe hierarchií se nepovinnost týká jednotlivých uzlu, ˚ kdežto u hran jsou takto ovlivnˇeny všechny následující uzly ve stromu (je možné modelovat i celé nepovinné dimenze). 2.3.3

Pˇrístup Microsoft

V souladu s tvrzením, že proces pˇresunu a transformace dat ze zdrojové do cílové lokality (tedy Extract, Transform, Load, ETL) tvoˇrí nejvýznamnˇejší a nejnároˇcnˇejší fázi tvorby datového skladu (viz napˇr. [8], [34]), je v materiálech Microsoft nejvˇetší prostor vˇenován platformˇe SQL Server Integration Services, SSIS. Samotný návrh datového skladu je zde spíše okrajové téma, zaˇcíná logickým návrhem4 , kde se vˇenuje pˇrevážnˇe dimenzionálním schématum ˚ (hvˇezda, snˇehová vloˇcka) a návrhu faktových a dimenzionálních tabulek. Fyzický návrh pak rˇ eší umístˇení dat, indexování a další techniky pro zvýšení výkonu (rozkládání tabulek na oddíly neboli partitioning, komprese dat). Celkovˇe lze rˇ íci, že oblast návrhu je oproti [18] nˇekolikanásobnˇe zestruˇcnˇena, nicménˇe zdá se, že pro bˇežné potˇreby je tato úrovenˇ dostaˇcující. Pˇri vlastní realizaci je pak pochopitelnˇe nutné vycházet z možností daného software, proto jsou zejména v pozdˇejších etapách návrhu a realizace použity zdroje [25] a [28].

4. Tento postup je kritizován Golfarellim, kde je pˇrirovnáván k návrhu relaˇcní databáze bez použití entitnˇe-relaˇcního modelování. Údajnˇe takto vznikají nevyhovující produkty zejména z pohledu naplnˇení požadavku, ˚ nároˇcnosti údržby a znovupoužitelnosti [18, s. 99].

9

3 Možné zdroje dat Jedním z prvních kroku˚ pˇri tvorbˇe datového skladu by mˇela být analýza dostupných datových zdroju, ˚ at’ už jde o bˇežné relaˇcní databáze, textové nebo tabulkové dokumenty, XML nebo jiné zdroje. Níže je uveden pˇrehled oblastí, které mají nˇejaký vztah obecnˇe ke správˇe budov a technologií, pˇrípadnˇe z tˇechto oblastí cˇ erpají data. V této fázi jsou uvažovány z konceptuálního pohledu, bez ohledu na svou fyzickou reprezentaci. •

stavební pasport

•

technologický pasport

•

dokumentace stavebních projektu˚

•

technologická sít’

•

archivní data BMS

•

data systému Archibus

•

data IS BAPS

•

data systému˚ monitorování provozu sítˇe

•

další zdroje

Tento seznam si neklade ambice být kompletním výˇctem potenciálních vstupu˚ pro vybudování datového skladu, nicménˇe jedná se i tak o pomˇernˇe obsáhlou množinu ruzných ˚ zdroju˚ dat. Následuje orientaˇcní popis jednotlivých zdroju˚ spolu s jejich využitelností v kontextu této práce.

3.1

Stavební pasport

Digitální stavební pasport MU slouží k poˇrizování, správˇe, aktualizaci a prezentaci dat popisujících již témˇerˇ 23 tisíc místností v 268 budovách, pˇricˇ emž více než 20 tisíc místností a 139 budov má vlastní grafickou reprezentaci [33]. Obsahuje grafickou a atributovou složku, tedy pudorysy ˚ místností a budov spolu s jejich vlastnostmi (plocha, povrchy). Používá je jako podklad pro další aplikace, jako jsou napˇr. evakuaˇcní a navigaˇcní plány, 3D modely budov apod. Z pohledu správy budov je zˇrejmˇe nejvýznamnˇejším použitím SP jako podkladového plánu pro technologický pasport. Je tedy z pohledu prezentace geografických dat klíˇcovým, jeho úloze v TDM se dále vˇenuje 4.2. 10

3. M OŽNÉ ZDROJE DAT

3.2

Technologický pasport

Databáze technologického pasportu je úzce spojena se stavebním pasportem, jde o jednu fyzickou databázi, ale vzhledem k rozdílnému užití obou skupin dat je lze považovat za dva logicky oddˇelené zdroje dat (pro stavební i technologický pasport existují oddˇelené aplikace apod.). Jsou zde evidovány prvky jednotlivých technologií (napˇr. napájení, rozvody vody, laboratorních médií, vytápˇení,. . . ). Grafická data reprezentují pudorysy ˚ zarˇ ízení a propojovacích prvku˚ technologií. Atributová data popisují vlastnosti prvku˚ výše zmínˇených technologií a vazby mezi nimi. V souˇcasné dobˇe je evidováno 107 tisíc zaˇrízení s vlastní geometrií, 37 tisíc bez vlastní geometrie a 144 tisíc vazeb mezi zaˇrízeními. [33]. Vzhledem k zadání práce bude technologický pasport tvoˇrit jeden z pilíˇru˚ zamýšleného výsledku, v cˇ ásti 5.2 je rovnˇež podrobnˇeji popsán. Specifikem jak stavebního, tak technologického pasportu je zejména jejich prostorová složka, kterou je tˇreba zohlednit.

3.3

Dokumentace stavebních projektu˚

S každou novˇe projektovanou budovou, pˇrípadnˇe rekonstrukcí, je tˇreba dodat zevrubnou dokumentaci popisující její parametry, vybavení apod. Z hlediska rˇ ízení provozu budov jsou klíˇcové pˇredevším cˇ ásti týkající se tzv. mˇerˇ ení a regulace (MaR), slaboproudu, a dalších návazných technologií (napˇr. osvˇetlení, vzduchotechnika apod.). V této dokumentaci by mˇela být obsažena evidence jednotlivých prvku˚ systému, na základˇe které pak v nˇekterých pˇrípadech lze poloautomaticky odvodit vazbu mezi fyzickými prvky (evidovanými v technologickém pasportu) a zapojením rˇ ídících komponent (kontroleru) ˚ a periferií do sítˇe – tedy struktura použitá pˇri provozu technologií. Návrhu možného postupu, jak toho docílit, se vˇenuje [27], zde tedy není úˇcelné se jím hloubˇeji zabývat. Podstatné ale je, že využití tˇechto dat muže ˚ významnˇe usnadnit vytvoˇrení vazby mezi technologickým pasportem a BMS.

3.4

Technologická sít’

Jedná se o pomˇernˇe specifický datový zdroj, nicménˇe lze ho principiálnˇe využívat podobnˇe jako napˇr. relaˇcní databázi. Jednotlivé záznamy takto reprezentují bud’ samotné objekty (zaˇrízení, datové body, rozvrhy, trendlogy, alarmy,. . . ), nebo záznamy probˇehlých událostí cˇ i mˇerˇ ení ve speciálních objektech urˇcených pro jejich ukládání (trendlogy, eventlogy apod.). Podrob11

3. M OŽNÉ ZDROJE DAT nˇejší popis zpusobu ˚ nakládání s daty v technologické síti je uveden v cˇ ásti 4.1, pro potˇreby této kapitoly postaˇcí uvést, že s využitím technologické sítˇe pro získání primárních dat se nepoˇcítá, ovšem data z ní budou v TDM nepˇrímo, zpracována službou Historian. Kromˇe toho poslouží technologická sít’ jako zdroj metadat, konkrétnˇe pomocí analýzy rˇ ídících programu˚ bude zmapována vazba mezi trendlogy a jejich skuteˇcnými (fyzickými) vstupy. Podrobnosti jsou uvedeny v cˇ ásti 5.2.4.

3.5

Archivní data BMS

V popisu technologické sítˇe výše bylo zmínˇeno, že data jsou archivována pomocí služby Historian. Jde o specializovaný software, který v síti komunikuje jako bˇežné zaˇrízení a na základˇe daného algoritmu shromažd’uje data z vybraných objektu˚ (nejˇcastˇeji trendlogu˚ a eventlogu) ˚ která pak ukládá do relaˇcní databáze HistorianDB. Podrobnosti jsou popsány v cˇ ásti 4.1. Data získaná službou Historian budou tvoˇrit nejpodstatnˇejší cˇ ást plánovaného úložištˇe.

3.6

Data systému Archibus

Archibus je systém pro podporu centralizované správy a údržby budov a jejich technologií [32]. Na Masarykovˇe univerzitˇe by mˇel být využíván pro plánování pravidelné údržby zaˇrízení a výhledovˇe i mnohé další úkoly. Projekt je nyní v poˇcáteˇcní fázi realizace, v plánu je postupné zprovoznoˇ vání jednotlivých agend. Do budoucna se s velkou pravdˇepodobností bude jednat o klíˇcový nástroj pro facility management, a tedy i potenciální zdroj dat pro datový sklad. Pro TDM však není uvažován, jeho data jsou spíše provoznˇe-administrativního rázu.

3.7

Data IS BAPS

BAPS je zkratka pro Brnˇenská akademická poˇcítaˇcová sít’, IS BAPS vznikl kvuli ˚ potˇrebˇe evidence jejích elementu, ˚ tedy zejména prvku˚ sít’ové infrastruktury (switchu, ˚ patch panelu, ˚ kabelu, ˚ ale i napˇr. prvku˚ hlasové sítˇe). Sem pochopitelnˇe spadá i technologická sít’. Databáze systému obsahuje informace pˇribližnˇe o 450 lokalitách1 , 9 000 zaˇrízeních, 15 000 patch panelech a 218 000 vláknech kabelu˚ [33]. V souˇcasné dobˇe by mˇel být IS BAPS alesponˇ cˇ ásteˇcnˇe provázán s technologickým pasportem, nicménˇe obsahuje pˇrevážnˇe data 1.

Termín lokalita je zde zaveden ve významu budova, tedy odlišnˇe než v SP a TP.

12

3. M OŽNÉ ZDROJE DAT o zaˇrízeních, která se pˇrímo na provozu budovy ve smyslu BMS nepodílejí, takže využit nebude. Do budoucna by ale mohlo být velmi pˇrínosné zamˇerˇ it se na provázání dat technologické sít’ové infrastruktury s daty systému˚ monitorování provozu sítˇe, které jsou zmínˇeny v další cˇ ásti.

3.8

Data systému˚ monitorování provozu sítˇe

Spolu s rostoucím rozsahem a komplexností technologické sítˇe vznikla potˇreba monitorovat v ní provoz v podobném režimu jako v bˇežné datové síti. V souˇcasné dobˇe jsou nasazeny tˇri takové nástroj, Nagios, Flowmon, a separátní sledování prostˇrednictvím SNMP. Nagios je na Masarykovˇe univerzitˇe již široce nasazen pro sledování serveru˚ a prvku˚ datové sítˇe, umožnuje ˇ i ukládání trendu˚ a historické reporty poplachu˚ a dalších událostí [10]. V technologické síti slouží kromˇe sledování serveru˚ a switchu˚ také pro dohled nad specializovanými zaˇrízeními, jako jsou napˇr. DVR (záznamové zaˇrízení obrazu z kamer), brány (gateway) pro zprostˇredkování komunikace ze specifických systému˚ (zabezpeˇcovací, pˇrístupový, požární systém). Flowmon je oproti tomu nástroj urˇcený pro analýzu toku˚ v síti, slouží tedy ke zvýšení její bezpeˇcnosti, umožnuje ˇ odhalovat útoky. Statistiky o provozu jsou dlouhodobˇe archivovány a analyzovány [7]. Poslední ze zmínˇené trojice je monitorování pomocí SNMP pˇrímo v BMS, které je v souˇcasnosti použito u záložních zdroju˚ (UPS). Oproti Nagiosu jsou zde sledovány mnohé další parametry jako napˇr. provozní napˇetí, stav baterie apod., data mohu být archivována pomocí Historianu. Zdá se tedy, že tato oblast má znaˇcný potenciál, i když jednotlivé agendy spolu nemusejí pˇrímo souviset. Vhodným rˇ ešením by mohlo být vybudování data martu pro sít’ový provoz jako dalšího ze skupiny úložišt’ provozních dat (resp. cˇ lánku˚ velkého datového skladu).

3.9

Další zdroje

Mimo zmínˇené zdroje existuje samozˇrejmˇe celá rˇ ada dalších, které však zpravidla nemají pˇrímou vazbu na provoz budovy – skupiny osob využívané pro systém EKV v IS MU, nebo napˇríklad evidence majetku v systému Inet, využívající jako podklad stavební pasport. Jsou zde uloženy i potenciálnˇe zajímavé informace o úˇcelech místností, které vlastní stavební pasport neobsahuje, ale možnost využití tˇechto dat vyžaduje další pruzkum. ˚ Dále je vhodné zmínit napˇr. evidenci klíˇcu˚ tamtéž, což je ale opˇet spíše administrativní než technická záležitost (jakkoliv se tyto oblasti mohou prolínat). Je 13

3. M OŽNÉ ZDROJE DAT otázkou, zda vubec ˚ má smysl uvažovat o propojování svˇeta provozu technologií s jinými oblastmi, i když jistý potenciál zde zˇrejmˇe je – napˇríklad elektronický zabezpeˇcovací systém (EZS), který muže ˚ být integrován do BMS, zprostˇredkovává obvykle nadˇrazenému systému zejména informace o stavu jednotlivých zón. Je ale možné získat i údaje o uživatelských úˇctech v zabezpeˇcovací ústˇrednˇe, které logicky úzce souvisejí s již zmínˇenou evidencí klíˇcu˚ (mohou mít i podobnou hierarchickou strukturu). V praxi se ale stˇeží dosahuje konzistence mezi tˇemito dvˇema systémy, pokud je správa uživatelských úˇctu˚ v EZS pouze lokální. Podobných pˇríkladu˚ je jistˇe možné najít více (dohledávání osob k zaˇrízením podle evidence majetku), za soucˇ asného stavu provázání jednotlivých systému˚ se však nejedná o reálný úkol.

3.10

Vybrané zdroje

Z výše popsaných zdroju˚ byly vybrány ty, které umožní realizovat cíle práce, a tedy mají pˇrímý vztah k provozu technologického vybavení budov jako takového. Jde o následující: •

archivní data BMS

•

dokumentace stavebních projektu˚

•

technologická sít’

•

technologický pasport

Dle doporuˇcení pro výbˇer pˇrístupu ke tvorbˇe datového skladu ([18, s. 44]) byl vzhledem ke zvážení rizikových faktoru˚ (velký poˇcet potenciálních datových zdroju˚ a z toho plynoucí nároˇcné sjednocení, nepˇredvídatelnost specifických potˇreb jednotlivých skupin uživatelu,. ˚ . . ) zvolen postup bottomup, tedy odspodu nahoru, iterativnˇe budovat menší, specializovaná úložištˇe dat (data marty), které budou tvoˇrit souˇcásti vlastního datového skladu. Tento pˇrístup je v rozporu napˇr. s doporuˇcením Inmona postupovat takzvanˇe top-down, tedy navrhnout nejdˇríve kompletní strukturu datového skladu vˇcetnˇe všech zdroju, ˚ nicménˇe riziko neúspˇechu v pˇrípadˇe snahy o komplexní rˇ ešení naráz je velmi vysoké. Detailnˇejší rozbor jednotlivých zdroju˚ následuje v cˇ ásti 5.2, kapitola 4 pak ještˇe zminuje ˇ nˇekteré rysy, které jsou specifické pro prostˇredí správy budov.

14

4 Specifika prostˇredí Prostˇredí rˇ ízení provozu budov (zde myšleno v rámci MU), obecnˇeji pak doména tzv. technologických informaˇcní systému˚ 1 , má mnohé rysy, které jej mohou odlišovat od prostˇredí bˇežných (relaˇcních) databází. Nˇekteré z nich významné pro návrh datového úložištˇe jsou dále rozebrány.

4.1

BMS a technologická sít’

Pojmem technologická sít’ rozumíme soustavu zaˇrízení komunikujících spolu po vlastní sít’ové infrastruktuˇre pomocí specifických protokolu, ˚ jako hlavní 2 komunikaˇcní protokol je zde použit BACnet . V kontextu této práce je pˇredevším významné, jakým zpusobem ˚ se v takové síti nakládá s daty. Vzhledem k tomu, že BACnet je objektovˇe orientovaný, i komunikace probíhá prostˇrednictvím zpráv, které zpravidla obsahují dotazy na jednotlivé objekty pˇripojených zaˇrízení. Za místo vzniku dat mužeme ˚ považovat objekty, které jsou pˇrímou reprezentací zaˇrízení pˇripojených do kontroleru – jde o objekty vstupu˚ a výstupu˚ (analogové, binární cˇ i vícehodnotové vstupy a výstupy). V tˇechto objektech jsou k dispozici údaje o stavu zaˇrízení, napˇr. teplota cˇ idla, otáˇcky ventilátoru, stupenˇ otevˇrení ventilu apod. Aby bylo možné s údaji dále pracovat, je definováno nˇekolik možných zpusob ˚ u˚ výmˇeny dat mezi objekty. Na tomto místˇe postaˇcí zmínit základní pˇrístupy, a sice: •

polling - ukládání dat na základˇe cˇ asového intervalu

•

COV – ukládání dat na základˇe definované zmˇeny jejich hodnoty

Pˇrístup COV dále dˇelíme na potvrzovaný a nepotvrzovaný. Pro jednotlivé objekty (jak vstupy a výstupy, tak napˇr. promˇenné) lze definovat objekt typu trendlog. Tento funguje, jak název napovídá, jako sbˇerný koš údaju˚ z objektu, ˚ které jsou sbírány na základˇe definovaného pˇredpisu (COV nebo polling). Pro každý objekt muže ˚ být definováno více trendlogu, ˚ napˇríklad pokud bychom chtˇeli sledovat hodnoty jak v pravidelných intervalech, tak pˇri jejich zmˇenˇe. Zmˇena hodnoty, pˇri které dojde k vyslání zprávy (prahová 1. Jakkoliv není tento termín pˇríliš rozšíˇren, mužeme ˚ ho chápat jako spojení IS a technologií obecnˇe, v tomto pˇrípadˇe v prostˇredí budov. Mimo jiné jím byla oznaˇcována skupina oddˇelení na ÚVT zabývající se GIS a BMS. 2. Více o BACnetu se lze doˇcíst napˇríklad na stránkách asociace ASHRAE http://www.bacnet.org, o jeho aplikaci v technologické síti Masarykovy univerzity pak na http://ics.muni.cz/zpravodaj/articles/678.html.

15

ˇ 4. S PECIFIKA PROST REDÍ

Polling

COV

Množství dat

v závislosti na intervalu, spíše velké

v závislosti na prahové hodnotˇe, spíše menší

Vypovídací hodnota

obvykle nižší

vysoká

Detekce výpadku˚

snadná

obtížná

ˇ Cerstvost dat

zpravidla dostaˇcující (v závislosti na intervalu)

muže ˚ být problematická

Tabulka 4.1: Vlastnosti ruzných ˚ metod archivace dat hodnota), je však stanovena pˇrímo ve zdrojovém objektu, není tedy možné ukládat data pˇri zmˇenˇe o pul ˚ stupnˇe a o stupenˇ (ani by to ostatnˇe nedávalo pˇríliš smysl, stejnˇe jako ukládat paralelnˇe data z jednoho objektu v ruzných ˚ intervalech). Z toho plyne potˇreba nastavit ve zdrojovém objektu odpovídající prahovou hodnotu pro vyslání zprávy (COV) a definování trendlogu˚ s odpovídajícím intervalem (polling). Je zjevné, že každý režim je vhodný pro jiné použití, obecnˇe se ale dá rˇ íci, že COV je vhodnˇejší, pˇres nˇekteré nevýhody diskutované dále. Je možné mít napˇr. v místnosti sledovánu teplotu v režimu hodinový polling, tím pádem je za den poˇrízeno 24 záznamu˚ v pravidelných intervalech, které poskytují pomˇernˇe dobrý obrázek o pru˚ bˇehu teploty (za pˇredpokladu, že se nebude pˇríliš prudce mˇenit). Pokud bychom ovšem tento pˇrístup použili pˇri sledování napˇr. topného ventilu, který se otevˇre a zavˇre nˇekolikrát dennˇe bˇehem velice krátké doby, nemáme prakticky žádné informace o jeho cˇ innosti. Zde je tˇreba zvolit COV, aby bylo možnéi zachytit extrémy. Tabulka 4.1 popisuje jednotlivé pˇrístupy ke sbˇeru dat z pohledu jejich archivace. V pˇrípadˇe požadavku na zachycení skuteˇcného prubˇ ˚ ehu hodnot na sledovaném objektu (resp. jeho vlastnosti, zpravidla jde ale o hodnotu) bude použito COV. I zde je ovšem riziko pˇrehlcení daty, napˇr. pokud u ventilu s možností otevˇrení 0-100 % nastavíme prahovou hodnotu 1%, pouhé jeho otevˇrení a uzavˇrení teoreticky vygeneruje 201 zpráv a tedy i 201 záznamu˚ v databázi (tento pˇredpoklad je teoretický proto, že zmˇeny následující rychle po sobˇe nelze obvykle zachytit). Vypovídací hodnota dat již byla ilustrována výše, dalším zajímavým aspektem je detekce mezer v datech. V síti muže ˚ nastat situace, kdy je nˇekterý kontroler mimo provoz, pˇrípadnˇe došlo ke komunikaˇcním problé16


mum, ˚ a výsledkem je nˇekdy i ztráta dat. Pokud budeme posuzovat jednotlivé trendlogy izolovanˇe, základním poznatkem je, že zatímco pˇri použití pollingu je mezera v datech zjevná (místo obvyklého intervalu cˇ tvrt hodiny je najednou mezera tˇri hodiny), u COV je situace podstatnˇe komplikovanˇejší. Pro orientaci zde poslouží rozdíl hodnoty jednotlivých záznamu, ˚ která by mˇela vždy (témˇerˇ ) pˇresnˇe odpovídat stanovené prahové hodnotˇe u zdrojového objektu. Pokud tedy je sledována teplota se zmˇenou o jeden stupenˇ s výslednou sekvencí 20, 21, 25, 24, 23, 22, je zjevné, že mezi 21 a 25 došlo k výpadku. O prubˇ ˚ ehu teploty v této dobˇe nejsou žádné informace (je to v podstatˇe analogická situace jako u pollingu). Navíc ale není možné s jistotou rˇ íci, zda k výpadku nemohlo dojít i kdykoliv jindy, a data jsou spojitá jen „náhodou“, resp. bˇehem výpadku došlo k výkyvu hodnot, ale pˇred obnovením ukládání se opˇet ustálily na spojitých hodnotách. Tato situace je ale hypotetická a ve skuteˇcnosti se u nekritických aplikací s danou mírou nejistoty lze pravdˇepodobnˇe smíˇrit. Dalším krokem pˇri archivaci dat je pˇrihlášení trendlogu˚ na jednotlivých zaˇrízeních k archivaci, tedy jejich registrace službou Historian. Ta se stará o pˇresun záznamu˚ do databáze, kde vytváˇrí takzvané archivní trendlogy, což jsou protˇejšky trendlogu˚ na zaˇrízeních. Jejich výhodou je prakticky neomezená kapacita (resp. limitující jsou pouze databázový stroj a místo na disku). Historian je schopen vypoˇcíst interval stahování dat z jednotlivých trendlogu, ˚ pˇrípadnˇe pˇrijímá notifikace od COV trendlogu, ˚ a zajišt’uje pravidelnou archivaci dat. Kromˇe toho monitoruje cˇ etnost ukládání záznamu˚ a další ukazatele, které umožnují ˇ spravovat celý proces archivace. Další z ukládaných dat jsou takzvané události. Jedná se o dˇeje v systému vyvolané objekty typu Event, které jsou, podobnˇe jako trendlogy, navázány na zdrojové objekty a na základˇe definovaného pˇredpisu vytváˇrí novou událost (napˇr. pokud teplota v místnosti pˇrekroˇcí 30 stupnˇ u, ˚ je pˇríslušným objektem vytvoˇrena zpráva, která je dle nastavení šíˇrena do ostatních zaˇrízení sítˇe). Ta pak muže ˚ být ukládána v objektu eventlog a dále archivována. V pˇrípadˇe, že zdrojový objekt opustí stav definovaný jako alarmový, je vygenerována zpráva o návratu do normálu. Obˇe tyto události jsou v pˇrípadˇe pˇriˇrazení do daného eventlogu uloženy v HistorianDB, mužeme ˚ z ní tak vyˇcíst historický prubˇ ˚ eh a trvání alarmových stavu. ˚ Zajímavá je otázka, zda je nutné využívat archivní databázi služby Historian (oznaˇcovanou jako HistorianDB) jako meziˇclánek mezi technologickou sítí a datovým skladem. Služba Historian archivuje jen zlomek dostupných trendlogu˚ v síti, vynecháním jejího úložištˇe by teoreticky bylo možné jich obsáhnout libovolné množství. Rozvinutím této úvahy lze dojít k myšlence úplného vynechání trendlogu˚ a shromažd’ování dat ze samotných da17


tových bodu, ˚ což by poskytlo ještˇe vˇetší možnosti co se týˇce výbˇeru dat k archivaci. Ovšem námitky proti takovému postupu jsou pádné. Zˇrejmˇe nejvýznamnˇejším problémem by byla nutnost vybudovat celou strukturu pro práci se sítí (kromˇe vytvoˇrení nebo použití tzv. BACnet stack, tedy nástroje pro pˇrístup do sítˇe rovnˇež aplikace pro údržbáˇre apod.), protože provozování paralelních nástroju˚ je už z hlediska zátˇeže sítˇe stˇeží akceptovatelné. Dosavadní software sice vykazuje jistou míru nedostatku, ˚ nicménˇe rˇ ešení jako takové je funkˇcní, jedná se o pomˇernˇe komplexní sestavu, kterou by bylo možné nahradit jen obtížnˇe. Momentálnˇe je separátní pˇrístup pˇrímo do sítˇe využíván pouze nástrojem BMS Sentinel (a jeho rozšíˇrením pro CEP), u nˇejž je to již z povahy vˇeci (tedy sledování výpadku˚ a poruch na síti) žádoucí. Závˇerem tedy lze konstatovat, že data v HistorianDB získané z technologické sítˇe pˇredstavují v podstatˇe standardní datový zdroj, ovšem je tˇreba zohlednit nˇekterá specifika. Dalším aspektum ˚ této problematiky se vˇenuje cˇ ást 5.2. Jednou z dalších vlastností systému BMS (resp. dohledového systému použitého na UKB) je pomˇernˇe pokroˇcilá práce s daty, kdy jsou použity nˇekteré techniky z oblasti Business Intelligence. Jde zejména o generování reportu, ˚ které lze sestavovat napˇr. z jednotlivých vlastností zaˇrízení, datových bodu˚ apod. Získáme tak textový výstup (pdf i jiné) s požadovanými daty, napˇr. prubˇ ˚ eh teplot, ale tˇreba i pˇrehled nastavení sít’ových adaptéru˚ a dalších parametru˚ pˇripojených zaˇrízení, což je neocenitelná pomucka ˚ pˇri konfiguraci sítˇe, pˇrípadnˇe rˇ ešení komunikaˇcních problému. ˚ Velkou výhodou je pˇrístup rovnou do technologické sítˇe, jsou tedy dostupné informace, které v archivním úložišti již obsaženy nejsou. Pro operativní práci jsou tedy zˇrejmˇe nenahraditelné, protože rozšíˇrení archivace na všechny potenciálnˇe využitelné údaje z technologické sítˇe není reálné a ani by to nebylo úˇcelné – jde pˇrevážnˇe o záležitosti operativního charakteru. Dalším nástrojem jsou alarmy, jež jsou ovšem archivovány, a proto jsou také zahrnuty do analýzy datových zdroju˚ dále.

4.2

Stavební a technologický pasport

Problematika geografických informací v datových skladech je (nejen) v kontextu této práce zásadní, uvádí se, že 80 procent business dat ([35, Introduction]), nebo dokonce všech elektronických dat ([17, s. 48]) má nˇejaký geografický kontext. Proto není možné tuto složku opominout. Na Masarykovˇe univerzitˇe je situace specifická tím, že je vypracována podrobná me18


Obrázek 4.1: Struktura technologického kódu (pˇrevzato z [27])

todika poˇrizování a správy tˇechto dat, navíc velká cˇ ást budov je již takto zmapována. Staˇcí tedy tato data vhodným zpusobem ˚ použít v zamýšleném skladu. Stavební a technologický pasport je postaven na platformˇe ESRI, konkrétnˇe využívá Spatial Database Engine (SDE), který tvoˇrí mezivrstvu mezi relaˇcní databází a geografickými objekty [4]. S daty musí být zacházeno speciálním zpusobem, ˚ aby bylo možné využít jejich prostorovou složku. Pro TDM by to zejména znamenalo, že v pˇrípadˇe plné integrace dat SP a TP, tedy jejich zahrnutí do vlastního úložištˇe, by bylo tˇreba tuto databázi ˇ provozovat s pomocí SDE. Rešení této otázky je diskutováno dále a v 5.2.2. Technologický pasport používá pro evidenci prvku˚ hierarchickou strukturu zachycenou pomocí technologického kódu (TK). Jak je patrné z obrázku 4.1, TK popisuje zaˇrízení vˇcetnˇe umístˇení v rámci SP, poskytuje tedy jednoznaˇcný identifikátor. Polohová cˇ ást se skládá z identifikace lokality (BHA), budovy (01), podlaží vˇcetnˇe typu (N01) a místnosti (1001a). Tento klíˇc lze jednoznaˇcnˇe mapovat na SP. Co se týˇce dat samotného SP, vzhledem k již uvedenému není úˇcelné tato data separátnˇe zpracovávat v datovém skladu a tím duplikovat geodatabázi. V souˇcasné dobˇe jsou plánovány rozsáhlé zmˇeny v prezentaci dat SP a TP (která jsou poˇrizována v Oddˇelením facility managementu Správy UKB, nicménˇe prezentaci zajišt’uje Ústav výpoˇcetní techniky, konkrétnˇe od19


dˇelení Geografických informaˇcních systému), ˚ souˇcástí kterých jsou i jednání o jejich využití v rámci TDM. Pravdˇepodobným rˇ ešením je použití webové služby, stejnˇe jako je tomu u ostatních aplikací využívajících SP.

20

5 Návrh rˇešení Základem návrhu je metodika z knihy Data Warehouse Design: Modern Principles and Methodologies [18, kapitola 2]. Podle etap vývoje jsou v této kapitole popsány jednotlivé kroky. Vzhledem k relativnˇe velkému množství potenciálních datových zdroju˚ byl zvolen pˇrístup postupného budování jednotlivých dílˇcích úložišt’ (data martu), ˚ která budou obsahovat úzce provázaná data pro jednu oblast užití. Tento pˇrístup je oznaˇcován jako bottom-up, tedy odspodu nahoru. Pro pilotní projekt data martu byly zvoleny datové zdroje popsané v kapitole 3 – databáze služby Historian, která ukládá data z technologické sítˇe (aktuálnˇe ve dvou instancích), data technologického pasportu, výstup analýzy rˇ ídících programu˚ a data z projektové dokumentace. Toto úložištˇe je nazýváno data mart (nikoliv datový sklad, data warehouse), protože jde o propojení pouze vybrané cˇ ásti datových zdroju, ˚ a ne o zahrnutí všech potenciálnˇe využitelných. Technologický data mart bude plnit cíle zmínˇené v úvodu práce, tedy bude sloužit pro sledování vlastního provozu budov. Další, související zdroje sloužící napˇr. pro správu majetku a další specifické úkoly, které ovšem mají vazbu obvykle zejména na stavební pasport, mohou být iterativnˇe zapojovány do dalších data martu, ˚ ve výsledku by tak mohl vzniknout datový sklad zahrnující prakticky všechny relevantní zdroje. Toto je postup, který je v souladu s metodikou R. Kimballa, jak je diskutováno v 2.2, nicménˇe bylo by zˇrejmˇe pomˇernˇe obtížné udržovat jednotlivá úložištˇe vzájemnˇe konzistentní, tedy udržovat je ve shodˇe pomocí sdílených dimenzí. Další variantou je celkové pˇrepracování koncepce a adaptování jiného pˇrístupu - centrální datový sklad dle Inmona.

5.1

Architektura

Struktura systému je navržena jako tˇrívrstvá, tedy kromˇe zdrojové vrstvy a vlastního úložištˇe obsahující rovnˇež mezivrstvu pˇredzpracovaných dat (tzv. reconciled layer), viz 5.1. Tato je pˇrítomná kvuli ˚ potˇrebˇe netriviálního zpracování vstupních dat (zejména provázání jednotlivých zdroju˚ pomocí dále popsaných postupu) ˚ a pˇrípadnˇe jejich ruˇcní úprava, hlavnˇe v iniciální fázi. Tento postup sice potenciálnˇe prodlužuje zpracování dat a muže ˚ tedy mít vliv dobu, za kterou se data dostanou do data martu, nicménˇe zmínˇené výhody pˇrevažují. 21

ˇ 5. N ÁVRH REŠENÍ

Obrázek 5.1: Pˇrehled prvku˚ a toku˚ dat

22


5.2

Analýza a úprava datových zdroju˚

5.2.1

HistorianDB – archivní data BMS

Jde o relaˇcní databázi provozovanou na MS SQL Serveru 2008. Je plnˇena archivaˇcní službou Historian, která získává data z technologické sítˇe z trendlogu˚ (datových bodu), ˚ které jsou urˇceny pro archivaci. Aktuálnˇe existují dvˇe instance této databáze, ve kterých je dohromady nadefinováno pˇres 2000 trendlogu˚ s celkovým poˇctem záznamu˚ pˇresahující 300 miliónu. ˚ Tabulky v HistorianDB mužeme ˚ rozdˇelit do nˇekolika skupin: •

•

•

•

týkající se provozu služby Historian: –

DevOff

–

Historian

–

HistorianDebug

–

Ops

–

ScheduleInfo

–

Stats

obsahující záznamy z tzv. trendlogu, ˚ jejich definice a pomocné vazební tabulky: –

ObjectMap

–

RefNames

–

TL

–

TLData

týkající se ukládání událostí: –

EVL

–

EVLData

–

EVLFilters

s informacemi o událostech pˇrístupového systému: –

ACEvent

–

ENUM_BAC_AC_EventType 23


První skupina tabulek není s nejvˇetší pravdˇepodobností dále využitelná pro zpracování v datovém skladu, jedná se o data použitelná výluˇcnˇe pro funkci Historianu. Informace o nedostupných zaˇrízeních a údaje o provozu služby jsou operativního charakteru a nemají dlouhodobˇejší význam. Z hlediska dalšího využití dat v datovém skladu je evidentnˇe nejvýznamnˇejší skupina 2, kde je rovnˇež soustˇredˇeno nejvíce dat - tabulka TLData obsahuje naprostou vˇetšinu všech záznamu˚ v databázi. Tato data mohou být s pomocí definic v tabulce TL pˇriˇrazena jednotlivým archivovaným trendlogum. ˚ Každý záznam v TL popisuje jeden archivní trendlog. Tabulka ObjectMap poskytuje vazbu mezi trendlogy v databázi (tzv. archivními) a tˇemi na zaˇrízeních v síti. Tabulka RefNames je v podstatˇe pˇrebyteˇcná, protože duplikuje informace již obsažené v ostatních. Skupina 3 obsahuje archiv takzvaných událostí (neboli alarmu), ˚ které vyvstaly na základˇe urˇcitých zmˇen na sledovaných objektech v síti. Typicky jde o pˇrekroˇcení pˇredepsaných hodnot, aktivaci (deaktivaci) nˇekterého z bezpeˇcnostních systému, ˚ ztrátu komunikace se sledovaným zaˇrízením apod. Je otázka, nakolik jsou tato data využitelná v datovém skladu, protože jsou také pˇrevážnˇe operativního charakteru a nemá nejspíš smysl vˇetšinu z nich nadále zpracovávat. Na druhou stranu už nyní se ukazuje, že mnohé z tˇechto událostí mohou zaznamenávat dlouhodobý trend, který je tˇreba podchytit (opakované výpadky s daným zaˇrízením/skupinou zarˇ ízení). Navíc mnohé spolu mohou souviset, a to i zpusobem, ˚ který není na první pohled odhalitelný. Z tˇechto duvod ˚ u˚ je vhodné i alarmové zprávy dále archivovat. Poslední skupinou jsou tabulky týkající se událostí pˇrístupového systému. Tyto specializované tabulky jsou v databázi zavedeny proto, že spoleˇcnost Delta Controls dodává kromˇe bˇežných kontroleru˚ pro rˇ ízení a regulaci (a archivaˇcního software Historian) i kontrolery specializované na rˇ ízení pˇrístupového systému. Na Masarykovˇe univerzitˇe je ovšem tento systém nasazen pouze ve velmi omezeném rozsahu, a proto je otázka, zda má smysl tato data uvažovat jako relevantní pro datový sklad – valná vˇetšina informací týkajících se kontroly vstupu není v Historianu obsažena. Existuje zde nˇekolik dalších systému, ˚ které nˇejakým zpusobem ˚ operují s EKV (centrální správa karet a pˇrístupových bodu˚ v IS MU, systém IRIS pro evidenci pruchod ˚ u), ˚ bylo by tedy nutné situaci hloubˇeji prozkoumat a navrhnout pˇrijatelné rˇ ešení zasazené do stávajícího režimu fungování elektronické kontroly vstupu (ˇci šíˇreji správy identit). Šlo by však nejspíše o vlastní úložištˇe (data mart), v první iteraci proto nebudou tato data uvažována. Níže je uveden seznam tabulek, které budou použity v datovém úložišti. U nˇekterých tabulek bude oproti puvodní ˚ struktuˇre omezen poˇcet 24


sloupcu. ˚ Dokumentace této databáze je nedostateˇcná, sestává z výˇctu sloupcu˚ jednotlivých tabulek, výjimeˇcnˇe spolu se struˇcným popisem jejich významu. Tato dokumentace navíc ne vždy odpovídá skuteˇcné struktuˇre dat, proto je nutné vycházet pˇredevším ze vzorku˚ dat a odvozovat, zda jsou jednotlivá pole užiteˇcná pro další zpracování. TL Poskytuje definici jednotlivých trendlogu˚ (TL), každý tedy reprezentuje jeden datový bod - zdrojový trendlog na zaˇrízení v síti. Je generována automaticky službou Historian, název zdroje je doplnˇen pˇredponou s adresou zaˇrízení a pˇríponou Archive. Tabulka uchovává vazbu na monitorovaný objekt, ale nikoliv na zdrojový TL. TLData Obsahuje vlastní záznamy z jednotlivých archivních trendlogu. ˚ ObjectMap Uchovává vazbu mezi archivními trendlogy a jejich zdroji (TL na kontrolerech). EVL Analogicky k TL ukládá definice eventlogu. ˚ Rozdíl je pˇredevším ve hierarchii dat, zatímco jednomu zdrojovému trendlogu pˇrísluší jeden archivní, zde jsou události zaˇrazovány do jednotlivých logu, ˚ mohou být zaˇrazeny i do více. Poˇcet archivovaných eventlogu˚ je i díky tomu rˇ ádovˇe nižší než archivních TL (cca stokrát). Rovnˇež existuje rozdíl v režimu ukládání, zatímco TL jsou rozdˇeleny podle geografické pˇríslušnosti mezi jednotlivé uzly serveru Historian, EVL jsou duplikována na obou uzlech, data jsou tedy shodná a je tˇreba zajistit, aby si navzájem odpovídala. EVLData Analogicky k TLData ukládá výskyty událostí. Z výše uvedeného vyplývá, že tato tabulka musí obsahovat i definice jednotlivých událostí, je tedy znaˇcnˇe širší než TLData (u EVL a TL je tomu naopak). Díky možnosti zaˇrazovat definici události do více EVL se zde muže ˚ vyskytovat i více záznamu˚ pro jeden výskyt - pro každý pˇríslušný EVL jeden. 25


Obrázek 5.2: Zjednodušený ER diagram HistorianDB ER model Pro zpˇrehlednˇení vazeb mezi entitami archivních dat BMS byl sestaven entitnˇe-relaˇcní model (5.2). 5.2.2

Technologický pasport

Analýzu této databáze ponˇekud ztˇežuje velký poˇcet tabulek (témˇerˇ 500), které navíc mezi sebou nemají definovány vazby a ani nemají primární klíˇce. Tím je prakticky znemožnˇeno použití alesponˇ cˇ ásteˇcnˇe automatizovaných postupu. ˚ K dispozici je ovšem datový model TP v notaci UML, pomocí kterého byly identifikovány tabulky TP nezbytné pro obsáhnutí potˇrebných informací: •

ZarizeniTP

•

TechnologickyKod

•

Vztah

•

ProstredkyPodsystemu

•

Podsystem

•

System

•

Prostredek 26


•

AtributyProstredku

•

Atribut

•

VycetAtributu

•

Vycet

•

TypAtributu

•

Jednotka

•

Hodnota

•

ZarizeniCastGeometrie

•

CastGeometrie

•

BodovaGeometrie

•

LiniovaGeometrie

•

PolygonovaGeometrie

Posledních pˇet tabulek popisujících geografickou složku dat najde uplatnˇení pˇri prezentaci spoleˇcnˇe se SP (jde pouze o referenˇcní tabulky, samotná geometrie je prezentována pomocí SDE). Ze sestaveného ER diagramu 5.3 vyplývá, že technologický pasport je uchováván v silnˇe normalizované struktuˇre, která klade duraz ˚ na maximální flexibilitu ve smyslu umožnˇení ruznˇ ˚ e obsáhlých, specifických údaju˚ o zaˇrízení. Tento pˇrístup ovšem není vhodný z pohledu prezentace dat, proto je tˇreba provést výraznou denormalizaci (zploštˇení struktury), ovšem se zachováním klíˇcových údaju. ˚ 5.2.3

Dokumentace stavebních projektu˚

ˇ Cást této dokumentace použitelná k propojení systému˚ BMS a TP je zpravidla dodávána ve formˇe tabulek obsahujících záznamy pro každý datový bod (tedy adresa kontroleru apod., tyto atributy jej jednoznaˇcnˇe identifikují v technologické síti) spolu s jeho oznaˇcením v dokumentaci, které by mˇelo být využito i v TP. Problémem této dokumentace je zejména obtížné zpracování, výskyt chyb a cˇ asto rovnˇež obtížnˇe mapovatelné cˇ i zcela chybˇející oznaˇcení v TP. Z globálnˇejšího hlediska pak její úplná absence zvláštˇe u nˇekterých starších etap (kde ovšem cˇ asto nebyla provedena ani technologická pasportizace). 27


Obrázek 5.3: Zjednodušený ER diagram Technologického pasportu Procesu zpracování této dokumentace se vˇenuje [27], zde z velké cˇ ásti využijeme již stanoveného postupu. Výsledkem je tedy v ideálním pˇrípadˇe vazba mezi objektem technologické sítˇe a zaˇrízením (obecnˇe s kardinalitou M:N, nebot’ jeden objekt muže ˚ reprezentovat více zaˇrízení a stejnˇe tak pro jedno zaˇrízení muže ˚ být vytvoˇreno více objektu). ˚ Objekty v tomto pˇrípadˇe uvažujeme ty „nejblíže“ vlastní technologii, tedy zpravidla pˇrímé reprezentace vstupu˚ a výstupu˚ (kromˇe nˇekterých speciálních pˇrípadu˚ diskutovaných v [27, s. 25-30]). Kvuli ˚ složitˇejším vztahu˚ mezi objekty je však tˇreba zapojit další postupy, které jsou rozvedeny v následující cˇ ásti. 5.2.4

Analýza rˇídících programu˚ v technologické síti

Objekty starající se o ukládání dat (trendlogy) mohou cˇ erpat data z jiných objektu, ˚ než tˇech, které pˇrímo reprezentují vstupy a výstupy. Ze vstupu muže ˚ být hodnota pˇriˇrazena promˇenné, a její hodnota teprve archivována (pˇrípadnˇe provedena nˇejaká další operace, jako napˇr. prumˇ ˚ erování, zjištˇení maximální hodnoty z více objektu˚ apod.) Proto je tˇreba tyto vazby rozklíˇcovat a doplnit tak informace v rˇ etˇezci zaˇrízení-objekt-(objekt)-trendlogarchivní trendlog. Vazbu archivní trendlog-zdrojový objekt poskytuje pˇrímo tabulka TL v HistorianDB, vazbu trendlog-archivní trendlog pak tabulka ObjectMap tamtéž. Nyní tedy jde o pˇrípady, kdy zdrojový objekt (archivního) trendlogu je odlišný od toho zastoupeného ve vazbˇe zaˇrízení-objekt, 28


jinými slovy pokud je v tomto rˇ etˇezci zapojen další objekt. Konkrétnˇe toho lze dosáhnout zpracováním zdrojového kódu programu˚ použitých pro rˇ ízení, kde jsou uvedena jednotlivá pˇriˇrazení mezi objekty, jak je ilustrováno v pˇrílozeC.1. 5.2.5

Shrnutí

Výsledkem této fáze je celkový ER diagram zdrojových dat v pˇríloze B.1. Schéma technologického pasportu bylo propojeno se schématem databáze archivních dat BMS, tedy HistorianDB. Vazba entity Objekt sama na sebe je, jak již bylo zmínˇeno, zachycena v rˇ ídících programech BMS. Tento diagram poslouží jako jeden ze zdroju˚ pro tvorbu konceptuálního modelu navrhovaného úložištˇe.

5.3

Požadavky

Kromˇe požadavku˚ kladených na práci prostˇrednictvím jejího zadání mu˚ žeme identifikovat i další vstupní body. Nedílnou souˇcástí tvorby datových skladu˚ je sbˇer a analýza uživatelských požadavku. ˚ Pravdˇepodobnˇe nejbˇežnˇejším zpusobem ˚ získání tˇechto informací je rozhovor neboli interview s uživateli. Nejedná se v tomto pˇrípadˇe o hlavní zdroj, pˇripomínky uživatelu˚ zde spíše doplnkem ˇ pro návrh vycházející ze struktury vstupních dat. V prubˇ ˚ ehu návrhu bylo na základˇe konzultací se znalcem problematiky1 rozhodnuto o sbˇeru a vyhodnocení tˇechto dat až na základˇe funkˇcní ukázky. Tento postup je umožnˇen díky znalosti rˇ ešených domén (tato role bývá nazývána data steward). Je tedy možné pro první iteraci využít dosavadní poznatky o struktuˇre dat a jejich využití a sbˇer požadavku˚ od ostatních koncových uživatelu˚ realizovat ve chvíli, kdy bude možné jim pˇredložit reálné výstupy. Dalším duvodem ˚ proˇc zvolit tento postup (kromˇe lepší pˇredstavy o nabízených možnostech, které si lze rovnou vyzkoušet), je snaha nebudit v potenciálních uživatelích pˇrehnaná oˇcekávání. Formulace a sbˇer požadavku˚ je tedy rozdˇelena na dvˇe etapy. První vychází z cílu˚ práce, jsou použity poznatky získané bˇehem provozu (zejména) úložištˇe historických dat BMS. Jde napˇríklad o: •

dosud realizované projekty zamˇerˇ ené na využití archivních dat (vyhodnocování spotˇreb elektrické energie. . . )

1. Nˇekteré aspekty projektu byly konzultovány s panem Jiˇrím Neoralem, odborníkem v oblasti Business Intelligence a datových skladu˚ a také školitelem spoleˇcnosti Gopas, viz http://www.biexperts.cz/index.php/cs/konzultanti/49-jirineoral.html.

29


•

používání nástroju˚ BMS pro historickou analýzu dat – tzv. multitrendy, které umožnují ˇ sestavovat grafy zahrnující data vybraných datových bodu˚

•

požadavky na data pro akreditaci laboratoˇrí (podmínky v místnostech, zejména teplota a vlhkost)

•

jednorázové požadavky na urˇcitá data (ad-hoc dotazy)

Dále je po zhotovení a otestování funkˇcního prototypu plánováno zmapovat názory a pˇrípadné požadavky potenciálních uživatelu. ˚ Je možné vymezit nˇekolik základních uživatelských rolí: •

vedoucí správy budov

•

provozní technik

•

analytik BMS

•

uživatel budovy (vedoucí laboratoˇre, vedoucí centra ICT,. . . )

•

správce DWH

Pˇredpoklad je, že uživatelé budou využívat jak možností periodického zasílání reportu˚ (e-mail), tak jejich prohlížení napˇr. ve webovém rozhraní. Externí prací s daty rozumíme pˇredevším využití nástroju˚ pro synchronizaci dat s MS Excel. Na základˇe uvedeného rozdˇelení byl sestaven pˇredbˇežný diagram pˇrípadu˚ užití 5.4. 5.3.1

Sbˇer uživatelských požadavku˚

Pro každý typ úˇcastníka bylo sestaveno nˇekolik otázek, které kombinují jak problematiku stávajícího využívání dat, tak možnosti novˇe zavádˇeného rˇ ešení. Velká cˇ ást se jich opakuje, protože jsou relevantní u všech skupin uživatelu, ˚ nicménˇe v každé zárovenˇ existují i specifické otázky. K interview bude vhodné pˇripravit statické výstupy dat, ideálnˇe ale pˇrístup do uživatelského rozhraní. Vedoucí správy budov 1.

Jaké formy pˇrístupu k údajum ˚ preferujete? (možnost získávání dat pˇres webové rozhraní, formulování vlastních dotazu, ˚ pravidelnˇe dodávané reporty) 30


Obrázek 5.4: Návrh využití TDM 2.

Jak detailní informace potˇrebujete (jaká je pˇrípustná úrovenˇ souhrnu napˇr. u spotˇreb energie, pˇríp. ve vztahu ke stáˇrí dat)?

3.

Lze pˇribližnˇe stanovit, jak stará data jsou potˇreba (pˇríp. s ohledem na jejich typ)?

4.

Bylo by pro vás užiteˇcné zahrnout vybrané ekonomické ukazatele? (napˇr. cena energií, pronájmy prostor apod.). Jsou nˇejaké možnosti, jak tato data automatizovanˇe získávat?

Provozní technik 1.

Jaké formy pˇrístupu k datum ˚ preferujete? (možnost získávání dat pˇres webové rozhraní, formulování vlastních dotazu, ˚ pravidelnˇe dodávané reporty)

2.

Existují nˇejaké pˇrekážky omezující pˇrístup k potˇrebným datum? ˚

3.

Jakým zpusobem ˚ sledujete potˇrebné údaje (prubˇ ˚ ežná kontrola, pravidelné reporty,. . . )? 31


4.

Jaké je minimální stáˇrí dat které berete v úvahu pˇri sledování dlouhodobˇejších trendu? ˚ (staˇcí data týden stará, jeden den, nˇekolik hodin)

5.

Jaké cˇ asové úseky považujete za duležité ˚ pro práci s daty (den v týdnu, víkend, týden v roce, mˇesíc, semestr, topná sezóna, prázdniny, rok,. . . )

6.

Jste spokojen se zasazením vámi využívaných údaju˚ (zejména historických) do kontextu (napˇr. z hlediska orientace v budovˇe apod.)?

7.

Jste ochoten zadávat do systému vybrané provozní údaje (pˇres webové rozhraní, email, jinak)?

Analytik BMS 1.

V jakém režimu nyní pracujete s daty BMS?

2.

Máte pˇripraveny šablony, skripty cˇ i jiné pomucky ˚ pro usnadnˇení vaší práce?

3.

Používáte dosavadní metody v provozním software, napˇríklad generování reportu˚ nebo multitrendy?

4.

Znáte pojem datová kostka, pˇrijde vám tato možnost analýzy dat pˇrínosná?

5.


6.


Uživatel budovy 1.

Jakým zpusobem ˚ využíváte BMS? / Co oˇcekáváte od zavedení BMS na vaši fakultu?

2.

Máte pˇredstavu, jaké informace o provozu technologií byste si pˇrál získávat?

3.

V jakém režimu je pro vás nejvhodnˇejší získávat potˇrebné údaje (prubˇ ˚ ežná kontrola, pravidelné reporty,. . . )?

4.

Jak detailní data potˇrebujete (jaká je pˇrípustná úrovenˇ agregace, pˇríp. ve vztahu ke stáˇrí dat)? 32


5.


6.


Zámˇerem je použít získané odpovˇedi pˇri upˇresnování ˇ struktury datového skladu, stupni agregace historických dat a dalších otázek. Jak již bylo zmínˇeno, vzhledem ke zvolenému modelu vývoje budou takto získané informace doplnkovým ˇ zdrojem. Nicménˇe mohou být užiteˇcné i pro pˇrípravu dalšího rozvoje datového skladu.

5.4

Konceptuální návrh

Cílem této kapitoly je sestavit prvotní návrh struktury dat, na základˇe kterého pak budou odvozeny navazující modely. Popis použité metodiky je v 2.3.2. Není zde aplikována doslovnˇe, nicménˇe v základních rysech je stanovený postup dodržen. Zejména v pozdˇejších fázích návrhu je však brán vˇetší zˇretel na postupy popsané v [25], a to z toho duvodu, ˚ že fyzický a cˇ ásteˇcnˇe i logický návrh již závisí na použití konkrétního software. 5.4.1

Identifikace faktu˚

Klíˇcové pˇri tvorbˇe jakéhokoliv dimenzionálního modelu je identifikovat takzvané fakty. Faktem rozumíme zpravidla nˇejaký typ opakujících se událostí, které nastávají v rámci pozorovaného prostˇredí. Vzhledem k tomu, že pracujeme v podstatˇe se dvˇema hlavními zdroji dat, z nichž jeden je primárnˇe založen na archivaci událostí (HistorianDB), zatímco druhý postihuje relativnˇe stabilní struktury budov a zaˇrízení (SP a TP), fakty je vhodné hledat spíše v tom prvním, tedy HistorianDB. Jako první fakt se pˇrirozenˇe nabízí Mˇerˇ ení, tedy vlastní událost, pˇri které dojde k uložení hodnoty na sledovaném objektu. Dále mužeme ˚ rozpoznat Událost (zde bohužel dochází k jistému terminologickému pˇretížení), tedy zprávu generovanou systémem za úˇcelem informování uživatele. 5.4.2

Atributy

U každého faktu je tˇreba stanovit jeho tzv. míry (measures). Jde o zpravidla numerické parametry popisující vlastnosti dané události. V pˇrípadˇe Mˇerˇ ení jde evidentnˇe o jeho vlastní hodnotu – namˇerˇ ená teplota, aktuální prutok ˚ apod. Pokud jde o Událost i, situace není tak jednoznaˇcná, žádný z podstaty 33


numerický atribut se zde nevyskytuje. Pujde ˚ nejspíš o takzvaný prázdný fakt, bez míry. 5.4.3

Dimenze

Tˇretím krokem je stanovení dimenzí, tedy jakýchsi souˇradnic (z pohledu myšlené datové kostky) faktu. U obou dosud stanovených faktu, ˚ tedy Mˇerˇ ení a Události, lze rozpoznat tyto dimenze: •

cˇ as

•

umístˇení v síti

•

umístˇení v prostoru

Následuje upˇresnování ˇ obsahu jednotlivých dimenzí. 5.4.4

ˇ Cas

U cˇ asové dimenze se projevuje specifická vlastnost databáze HistorianDB, která se sama stará o poˇrizování cˇ asová razítka pro data mˇerˇ ení a událostí. Tyto budou využity namísto poˇrizování vlastních. Ruzné ˚ režimy poˇrizování dat, rozvedené v 4.1, mají vliv zejména na pˇrístup k analýze dat. cˇ asové razítko ze zdrojového systému není pˇríliš použitelné pro analýzu, nebot’ obsahuje všechny cˇ asové jednotky dohromady. Je tˇreba jej upravit takovým zpusobem, ˚ aby bylo možné tento údaj využívat pro typické dotazy, napˇr. jaká byla v místnosti teplota v pondˇelí ráno, spotˇreba v nepracovní dny apod. Na koˇrenovém elementu, cˇ asovém razítku, závisejí atributy den, nepracovní den, pracovní doba a mˇesíc (další potenciální atributy, napˇr. týden jsou vynechány, protože pro analýzu nejspíš nemají smysl - z poznatku˚ uživatelu˚ však mohou vyplynout další požadavky). Atribut mˇesíc dále urˇcuje cˇ tvrtletí a následnˇe rok. Tím je pokryta cˇ asová dimenze. 5.4.5

Umístˇení v BMS

Tato dimenzionální hierarchie se rovnˇež odkazuje na data HistorianDB, popisuje strukturu objektu˚ v síti BACnet, které mají vztah k danému Mˇerˇ ení. Koˇrenovým prvkem je zde trendlog, ze kterého mˇerˇ ení pochází. Na nˇej navazuje zdrojový objekt (trendlog má právˇe jeden zdrojový objekt, jehož hodnoty sleduje, nicménˇe pro jeden objekt muže ˚ být definováno více trendlogu, ˚ napˇr. s jiným režimem ukládání vzorku, ˚ viz 4.1), následuje kontroler a sít’ová lokalita na základˇe adresy. 34


5.4.6

Umístˇení v prostoru

Fyzickou polohu zaˇrízení mužeme ˚ zjistit pouze z technologického pasportu, proto je celá tato dimenze nepovinná pro pˇrípad, že chybí potˇrebná data (neexistují nebo se je nepodaˇrilo navázat). Zaˇrízení TP, tedy zaˇrízení v kontextu technologického pasportu (zde vzniká potenciální homonymie s umístˇením v síti, kde jsou rˇ ídící úˇcastníci komunikace v síti oznaˇcováni jako device, bude tedy použito oznaˇcení kontroler, pˇrestože obecnˇe muže ˚ jít i o jiné zaˇrízení), je zde koˇrenovým prvkem, na kterém funkˇcnˇe závisí technologický kód, který v sobˇe obsahuje polohovou a technologickou cˇ ást. Z nˇej vedou dvˇe vˇetve, stavebního a technologického pasportu. Vˇetev SP pokraˇcuje místností, podlažím, budovou a lokalitou, TP pak prostˇredkem, podsystémem a systémem. Vzhledem k tomu, že zaˇrízení TP muže ˚ mít více kódu, ˚ je vazba násobná. Položky Místnost, Podlaží a Budova jsou nepovinné, protože jak Mˇerˇ ení, tak Událost se nemusí vztahovat pˇrímo je konkrétní Místnosti ani Budovˇe (napˇr. venkovní teplota, událost týkající se areálu). Na základˇe získaných poznatku˚ je možné sestavit schémata pro jednotlivé fakty, Mˇerˇ ení a Událost 5.52 . Vzhledem k podobné struktuˇre, resp. analogickým vztahum ˚ mezi BACnet objekty, jsou i schémata podobná, dvˇe ze tˇrí dimenzí jsou sdílené (tzv. conformed dimensions, viz 2.3.2).

5.5

Logický návrh

Dalším krokem pˇri návrhu datového skladu je sestavení logického modelu. Východiskem je konceptuální model, nicménˇe nejde o automatizovaný postup. Je vhodné zmínit, že od této kapitoly dále jsou poznatky cˇ erpány pˇredevším z materiálu˚ spoleˇcnosti Microsoft ke kurzu Implementing a Data Warehouse with Microsoft SQL Server 2012 ([25]), kde jsou teoretické poznatky uvedené v [18] nazírány z pohledu implementace za použití konkrétních softwarových nástroju. ˚ Nˇekteré cˇ ásti této kapitoly jsou teoretiˇctˇejší, nicménˇe zmínˇená východiska jsou vzápˇetí aplikována pˇri tvorbˇe vlastního logického schématu, proto byla zvolena tato struktura. Klíˇcovým pojmem pˇri sestavování logického modelu je tzv. star schema, neboli hvˇezdicové schéma. Tento pojem oznaˇcuje strukturu tabulek, kde je centrální tabulka faktu˚ obklopena dimenzionálními tabulkami, na které se odkazuje. Jde tedy o obdobu konceptuálního modelu, který je pˇreuspoˇrádán do podoby tabulek. Každá dimenzionální tabulka je zpravidla identifikována novˇe pˇriˇrazeným, syntetickým klíˇcem (tzv. surrogate key, viz 5.5.4) 2. K vytvoˇrení modelu byla použita alfa verze nástroje Business Intelligence Modeler, jehož autorem je Stefano Cazzella.

35


Obrázek 5.5: Konceptuální model

36


a obsahuje jednotlivé atributy dané dimenze. Faktová tabulka je identifikována klíˇci jednotlivých dimenzionálních tabulek (které zde vystupují jako cizí klíˇce), a ty pak dohromady tvoˇrí její primární klíˇc. Faktové tabulky obsahují zpravidla navzájem porovnatelné, cˇ íselné údaje, dimenzionální tabulky jim pak, jak už název napovídá, dodávají další rozmˇery (typicky cˇ as, prostor apod.). 5.5.1

Otázka denormalizace

Základním rysem, který odlišuje hvˇezdicové uspoˇrádání od bˇežných schémat používaných v relaˇcních databázích, je denormalizace. To v principu znamená vˇedomé porušení normálních forem, které jsou aplikovány na operativní databáze kvuli ˚ snížení objemu dat a optimalizaci struktury vzhledem ke správˇe jednotlivých souvisejících množin údaju. ˚ Na datové sklady jsou však obecnˇe kladeny výraznˇe jiné požadavky než na bˇežné provozní databáze, z hlediska výkonu jde pˇredevším o orientaci na co nejrychlejší cˇ tení dat, a nikoliv zápis cˇ i úpravu. Pokud by data mˇela být uspoˇrádána po de facto atomických logických celcích, pˇri komplexním získávání údaju˚ by se daly oˇcekávat výkonové problémy zpusobené ˚ pˇredevším nutností velkého poˇctu spojení (joinu) ˚ mezi tabulkami. Pokud budou data vhodnˇe denormalizována, za cenu zavedení jisté redundance bude dosaženo struktury, která je podstatnˇe vhodnˇejší pro daný zpusob ˚ dotazování. Získané tabulky jsou zpravidla znaˇcnˇe široké, tedy obsahují velký poˇcet sloupcu. ˚ Proto existuje alternativa k hvˇezdicovému schématu, a to sice tzv. schéma snˇehové vloˇcky. V podstatˇe jde o cˇ ásteˇcný návrat k normalizovaným tabulkám. Toto schéma je doporuˇcováno pokud ([25, 3-11]): •

poddimenze muže ˚ být sdílena mezi více dimenzemi

•

v rámci hierarchie existuje podmnožina cˇ asto mˇenˇených dat

•

rˇ ídká dimenze má nˇekolik ruzných ˚ podtypu˚

•

více faktových tabulek odlišné granularity (viz 5.5.2) se odkazuje na ruzné ˚ úrovnˇe dimenzionální hierarchie

Pˇri návrhu TDM byly identifikovány dva z tˇechto scénáˇru, ˚ a sice poddimenze Lokalita, která tvoˇrí vazbu mezi umístˇením v prostoru a v BMS, a podmnožina cˇ asto mˇenˇených dat v dimenzích BMS pro Mˇerˇ ení i Události (poˇcty záznamu, ˚ které byly z výsledného modelu vypuštˇeny, protože neodrážejí data obsažená v TDM, ale ve zdrojovém systému). Proto je použito 37


schéma snˇehové vloˇcky se dvˇema sdílenými dimenzemi (ˇcas, prostor) a jednou sdílenou poddimenzí (lokalita)3 . 5.5.2

Otázka granularity

Termínem granularita je zde myšlena úrovenˇ detailu, tedy míra sumarizace jednotlivých záznamu˚ pro každou faktovou i dimenzionální tabulku. Tabulka s atributy rok, mˇesíc, den má granularitu na úrovni dní, tabulka s atributy lokalita, budova, podlaží pak na úrovni podlaží. Tato otázka je zásadní pˇredevším proto, že kromˇe množství dat urˇcuje také, jakým zpu˚ sobem je mužeme ˚ využívat. Ani jeden z výše uvedených pˇríkladu˚ by pro potˇreby analýzy dat provozu budov nebyl pˇríliš použitelný, protože zpravidla potˇrebujeme znát pˇresný cˇ as a umístˇení (na úrovni místností), kdy ke sledovanému jevu došlo. Udržení maximální možné granularity (tedy na vstupní úrovni) se v oblasti datových skladu˚ zpravidla neuvažuje, nicménˇe zde jde o jeden z výrazných rozdílu˚ mezi strukturou a použitím datového skladu napˇríklad pro potˇreby analýzy prodeju˚ a jako nástroje pro monitorování technologií. Pˇrestože datový sklad nemuže ˚ a nemá zastupovat roli operativních databází, v tomto pˇrípadˇe požadujeme možnost používat vstupní data v nezmenšené míˇre podrobnosti po znaˇcnou dobu. Duvodem ˚ je mimo jiné potˇreba hledání souvislostí mezi dˇeji probíhajícími na ruzných ˚ datových bodech, které jsou však spojeny s jedním technologickým procesem a úzce spolu souvisejí (vliv otevˇrení ventilu/okna na teplotu v místnosti/vody; soubˇeh stisknutí tlaˇcítka, pˇriložení karty ke cˇ teˇcce a otevˇrení a zavˇrení dveˇrí atp.). Povaha a výskyt jednotlivých typu˚ dˇeju˚ se navíc mˇení v závislosti na roˇcním období (napˇr. chlazení, topení, protimrazová ochrana), minimální hranice, kterou mužeme ˚ stanovit pro kompletní poˇcet záznamu, ˚ je tedy zhruba jeden rok. Nedá se vylouˇcit, že se v prubˇ ˚ ehu používání TDM se vyskytne potˇreba uchovávat data s ruznou ˚ úrovní granularity. Taková situace muže ˚ nastat, pokud je dat takové množství, že není únosné je schranovat ˇ v puvodním ˚ rozsahu v celém intervalu archivace.Vzhledem k tomu, že uchovávat je v jedné (faktové) tabulce není vhodné (více napˇr. [6, Identifying the data]), nabízí se vytvoˇrit alternativní strukturu více faktových tabulek s totožným subjektem, ale s ruznou ˚ mírou detailu. K nim je pak tˇreba vytvoˇrit odpovídající dimenzionální tabulky. Vzhledem k objemu dat a tempu rustu ˚ HistorianDB však podobná opatˇrení nejsou (a nejspíš ani nebudou) tˇreba. 3. Jiný materiál od Microsoftu uvádí ([28, s. 11]) , že schéma snˇehové vloˇcky je vhodné použít výhradnˇe pro tzv. POC (proof-of-concept) projekty, tedy v podstatˇe pilotní projekty, kterým je i TDM.

38


Výhody

Nevýhody

menší prostorové nároky (používány jako FK)

zvˇetšení dimenzionální tabulky (atribut navíc)

rychlý pˇrístup díky jednoduchému indexování

nutnost zavedení další metody hlídání integrity

lze mˇenit identifikátory ve zdrojovém systému

nutnost pˇrepisu business klíˇcu˚

Tabulka 5.1: Srovnání použití surrogate key 5.5.3

ˇ Casová dimenze

Samostatnou otázkou je granularita cˇ asové dimenze, která již byla otevˇrena v 5.5.2. Vzhledem ke specifické povaze technologických dˇeju˚ je úrovenˇ detailu navržena na hodiny, ovšem i samotné cˇ asové razítko bude v TDM ukládáno, a to ve faktových tabulkách. Kromˇe údaju˚ týkajících se numerického cˇ asu jsou zde uvedeny rovnˇež údaje o názvech a poˇradí dnu˚ a mˇesícu˚ a údaje o pracovních dnech a pracovní dobˇe. ˇ Casová dimenze obsahuje rˇ adu dalších atributu˚ specifických pro dané prostˇredí (tzv business-specific temporal attributes, [25, 3-13]), které ovšem nelze generovat, ani nejsou obsaženy ve zdrojových systémech. Jde zejména o rozsah akademického roku, resp. výuky, dále topná sezóna (provoz systému˚ topení/chlazení, protimrazových ochran,. . . ), a pravdˇepodobnˇe budou v prubˇ ˚ ehu používání data martu odhaleny i další. Nˇekteré tyto údaje by bylo možné doplnovat ˇ z externích zdroju, ˚ napˇr. IS MU, nicménˇe jiné bude pravdˇepodobnˇe nutné nˇejakým zpusobem ˚ zadávat uživatelsky (aktuálnˇe není možné jednoznaˇcnˇe automaticky zjistit napˇr. zahájení topné sezóny). 5.5.4

Klíˇce

V oblasti DWH v zásadˇe rozlišujeme dva typy klíˇcu˚ – tzv. business key a surrogate key. Jde tedy o klíˇc pocházející ze zdrojového systému a klíˇc novˇe definovaný v datovém skladu. Druhý z nich je pak zpravidla primárním klíˇcem dané dimenzionální tabulky. Mužeme ˚ zmínit výhody i nevýhody tohoto pˇrístupu (dle [18, s. 223, 224]), shrnuté v tabulce 5.1. Uvádˇené nevýhody jsou však naprosto marginální, použití novˇe vytvorˇ ených numerických klíˇcu˚ je obecnˇe zˇrejmˇe nejˇcastˇejší rˇ ešení. 39


Co se týˇce klíˇcu˚ ve faktových tabulkách, primární klíˇc je zpravidla složen z cizích klíˇcu˚ odkazujících na jednotlivé dimenze, pˇrípadnˇe k nim muže ˚ být pˇridán business klíˇc dané zdrojové tabulky. 5.5.5

Míry

Míry neboli measures jsou obvykle numerické atributy obsažené ve faktových tabulkách, jde o vlastní sledované údaje. V použitém modelu (5.6) je obsažena jen jedna míra, a to Hodnota ve faktové tabulce Mˇerˇ ení. Druhá faktová tabulka, Událost, nemá žádnou míru, zde sledujeme vlastní nastoupení události. Míry obecnˇe dˇelíme do tˇrí druhu, ˚ aditivní, semiaditivní a neaditivní. Objasnit je tˇreba význam semiaditivních – jsou to ty míry, které lze sumarizovat (sˇcítat, prumˇ ˚ erovat) pouze napˇríˇc nˇekterými dimenzemi. 5.5.6

Aditivita

V BMS sledujeme mnoho druhu˚ údaju, ˚ jejichž aditivita se v ruzných ˚ pˇrípadech liší. Muže ˚ jít napˇríklad o sledování teploty, kde lze uvažovat o pru˚ mˇerování (ovšem nikoliv souˇctu), ale tˇreba i o sumární hodnotu elektromˇeru sledovaného v pravidelných intervalech, ke kterému takto pˇristupovat nelze (je možné odeˇcítat od sebe hodnoty dvou po sobˇe jdoucích záznamu˚ záznamu˚ a získat tak údaj o spotˇrebˇe za dobu mezi jejich poˇrízením), datové body poskytující jen binární informaci (otevˇreno, zavˇreno) u které mužeme ˚ chtít znát cˇ as otevˇrení atp. Pˇrestože tedy jde o jeden typ faktu, ˚ co se týˇce aditivity, mají odlišné vlastnosti. Jako nejvhodnˇejší rˇ ešení se zdá opatˇrit jednotlivé trendlogy údajem o tom, jakým zpusobem ˚ lze jejich data zpracovávat. Pro potˇreby TDM rozeznáváme (zatím) tyto typy aditivity: •

prumˇ ˚ er (AVG)

•

extrémní hodnoty (MAX,MIN)

•

souˇcet (SUM)

•

poˇcet výskytu˚ (COUNT)

Možnosti pro jednotlivé druhy trendlogu˚ (pracovní rozdˇelení) jsou uvedeny v tabulce 5.2. V databázi je pak aditivita rˇ ešena sadou pˇríznaku˚ u každého záznamu v dimenzionální tabulce Mˇerˇ ení BMS. V pˇrípadˇe událostí tyto pˇríznaky použity nejsou, nebot’ zde je z podstaty vˇeci možné použít pouze COUNT, tedy poˇcet výskytu˚ události. 40


Druh (pˇríklad)

AVG

MAX, MIN

SUM

COUNT

fyzikální veliˇciny (teploty, vlhkosti)

ano

ano

ne

ne

spotˇreby (elektrické energie)

ano

ano

ano

ne

regulaˇcní prvky (otevˇrení ventilu)

ne

ano

ne

ne

stavové prvky (bˇeh motoru, stav cˇ idla)

ne

ne

ne

ano

Tabulka 5.2: Možnosti agregace dle typu˚ trendlogu˚ Mˇerˇ ení jsou z hlediska dimenzí plnˇe aditivní, nejsou tedy omezena na vybrané dimenze (prumˇ ˚ er teplot lze stanovit jak pro jednotlivé dny jednoho mˇerˇ idla, tak pro jednotlivá mˇerˇ idla v jednom okamžiku), kromˇe již zmínˇených dat spotˇreb. 5.5.7

Pˇrevod konceptuálního modelu na logický

Zvolená metodika návrhu obsahuje pomˇernˇe velké množství kroku, ˚ jednotlivé fáze byly rozloženy do delšího cˇ asového období a výsledný logický návrh byl prubˇ ˚ ežnˇe upravován. Neodpovídá tedy zcela konceptuálnímu návrhu, který nezahrnuje poznatky získané bˇehem implementace. Napˇríklad byla doplnˇena tabulka popisující Lokalitu, která tvoˇrí vazbu mezi daty BMS a pasportu (nicménˇe tato vazba není zcela zˇrejmá, už proto, že údaje o lokalitˇe nejsou v BMS explicitnˇe zavedeny). Specifické problémy, které je tˇreba v logickém modelu ošetˇrit, pˇredstavují tyto prvky konceptuálního modelu (seznam vychází z prvku˚ použitých pˇri konceptuálním modelování pomocí metodiky DFM): •

sdílené hierarchie (dimenze)

•

násobné hrany

•

nepovinné hrany

•

rekurzivní hierarchie

•

nekompletní hierarchie

Sdílené dimenze jsou dvˇe, cˇ asová a prostorová. Vzhledem k tomu, že jde o totální sdílení ([18, s.243]), rˇ ešení je pˇrímoˇcaré – na každou dimenzi se pomocí cizích klíˇcu˚ budou odkazovat všechny dotˇcené faktové tabulky. Stejnˇe je tomu u sdílené poddimenze Lokalita. 41


Násobná hrana se vyskytuje jednou, mezi zaˇrízením a technologickým kódem (z duvodu, ˚ že zaˇrízení muže ˚ mít více kódu). ˚ Zaˇrízení tedy není v prostorové dimenzi unikátní, pro každý jeho kód bude existovat jeden záznam. Nepovinné hrany se vyskytují u obou faktových tabulek u dimenze Umístˇení v prostoru, protože tato data nemusí být dostupná. Vzhledem k tomu, že jde o celou dimenzi, jejíž primární klíˇc je odkazován ve faktových tabulkách, je tˇreba vyˇrešit pˇrípadnou absenci tˇechto dat. Golfarelli ([18, s. 248]) v tomto pˇrípadˇe doporuˇcuje vytvoˇrení „falešného“ záznamu (aby v databázi nebyla obsažena hodnota NULL). Nekompletní hierarchie, zde opˇet Umístˇení v prostoru, vzniká, pokud muže ˚ být nˇekterý z prvku˚ rˇ etˇezce funkcionálnˇe závislých kategorií vynechán. Pˇricházíme tím o danou úrovenˇ agregace. V tomto pˇrípadˇe nejde o nepovinnou hranu, protože koncový prvek Lokalita je povinný. Problémem chybˇejících stupnˇ u˚ hierarchie je pˇredevším možné zkreslení výsledku˚ pˇri agregování dat. Dle [18, s. 249] jsou v zásadˇe možná tˇri rˇ ešení: •

dosazení neutrálního prvku („jiný“)

•

dosazení prvku podˇrazeného v hierarchii

•

dosazení prvku nadˇrazeného v hierarchii

Z tˇechto tˇrí pˇrístupu˚ první porušuje sémantiku operace roll-up, tedy posun o úrovenˇ výš, a sice tím, že data jsou zneˇcištˇena údaji z jiné úrovnˇe agregace (více [18, s. 135, 249]). Pokud je množství chybˇejících prvku˚ malé (což zˇrejmˇe bude, týká se to typicky datových bodu˚ obsahující data z cˇ idel mimo budovu apod.), je zˇrejmˇe nejvhodnˇejší použít dosazení podˇrazeného prvku (na úrovni Místnost, Podlaží, Budova bude stále figurovat jen Zaˇrízení)4 . 5.5.7.1 Dimenzionální tabulky Dim_Mereni_BMS Kromˇe sloupcu˚ získaných nebo odvozených z TL a ObjectMap, tedy identifikace archivních a zdrojových trendlogu˚ a dalších parametru, ˚ pˇrípadnˇe odvozených sloupcu, ˚ obsahuje navíc:

4.

•

sloupec identifikace zdrojového serveru

•

sloupce pro urˇcení aditivity

•

sloupce pro oznaˇcující platnost záznamu (využito pˇri ukládání historických verzí, viz 6.5) To je zajištˇeno již strukturou technologického kódu.

42


Obrázek 5.6: Logický model TDM

43


Dim_Udalost_BMS Má podobnou strukturu jako Dim_Mereni_BMS, s tím rozdílem, že obsah hlavní zdrojové tabulky EVL je na obou serverech shodný, proto nejsou sjednocovány, ale pouze porovnávány na shodu. Také zde nejsou uvedeny pˇríznaky aditivity, protože události z podstaty aditivní nejsou (ani neobsahují míru), resp. prakticky lze sledovat jen poˇcty jejich výskytu˚ (tedy COUNT). Každá událost (EV) muže ˚ být zaˇrazena do více logu˚ (EVL), pro každý EVL je však vygenerován vlastní záznam. puvodním ˚ zámˇerem bylo tuto duplicitu odstranit, nicménˇe to by si vyžádalo zavedení vazební tabulky pro vztah EV-EVL, což není v souladu s principy návrhu datových skladu. ˚ Proto byla nakonec tato struktura zachována (je však tˇreba s tím poˇcítat pˇri následném využití dat). Dim_Cas Tato dimenze neˇcerpá žádná data ze zdrojových systému, ˚ je kompletnˇe generovaná. Podrobnosti jsou uvedeny v cˇ ásti 5.5.3. Dim_Prostor Reprezentuje vazbu na data pasportu. Vznikne sjednocením (denormalizováním) velké cˇ ásti tabulek vyjmenovaných v 5.2.2. Geografické údaje budou ukládány zvlášt’, nicménˇe tato otázka bude zcela doˇrešena až v souvislosti s napojením na nástroje vyvíjené Ústavem výpoˇcetní techniky MU. 5.5.7.2 Subdimenze Subdim_Lokalita Propojuje dimenze umístˇení v BMS s prostorovou dimenzí, obsahuje data ze stavebního pasportu (konkrétnˇe z cˇ íselníku lokalit, fm_lokalita). Tato data jsou pak mapována na adresní plán technologické sítˇe, který pˇridˇeluje každé (sít’ové) lokalitˇe rozsah adres.5 5.5.7.3 Faktové tabulky Fakt_Mereni Tato tabulka vychází zejména z tabulky TLData, obsahuje záznamy vlastních mˇerˇ ení. V TLData jsou kromˇe vlastních dat mˇerˇ ení uchovávány další provozní informace, jako napˇríklad posun cˇ asu zaˇrízení se sledovaným objektem, záznamy o chybách mˇerˇ ení, spuštˇení a ukonˇcení archivace atp. Nabízí se tedy nˇejakým zpusobem ˚ 5. Technicky není možné zajistit, aby byl tento rozsah spojitý, nicménˇe je možné získat alesponˇ vazbu Geografická lokalita : Rozsah adres s kardinalitou 1 : N. Bohužel pˇredpis adresního rozsahu není dostupný v žádném zdroji dat, je dosud spravován pouze ruˇcnˇe a stejnˇe je tedy tˇreba doplnovat ˇ tuto subdimenzi - vzhledem k poˇctu záznamu˚ v rˇ ádu jednotek to však nepˇredstavuje zásadní problém.

44


tato „metadata“ oddˇelit a vytvoˇrit paralelní faktové tabulky, tím by ale došlo k další fragmentaci a potenciálnˇe by to mohlo zkomplikovat analýzu dat (v pˇrípadˇe, že by bylo tˇreba sledovat souvislosti mezi tˇemito typy záznamu). ˚ Proto jsou všechny tyto typy dat ponechány v jedné tabulce. Fakt_Udalost Vychází z EVLData, obsahuje jednotlivé výskyty událostí. Na rozdíl od Fakt_Mereni neobsahuje pole pro hodnotu (jedná se o fakt bez míry) ani typ záznamu, oproti tomu je zde evidován typ pˇrechodu, tedy hodnoty pˇred a po výskytem události. Tím je umožnˇeno události párovat (objekt se dostal do stavu zpusobujícího ˚ alarm a pak zpˇet, tím vzniknou dvˇe související události).

5.6

Návrh zpracování dat

Po definování logické struktury TDM pˇrichází na rˇ adu otázka pˇrenosu dat ze zdrojových systému do koneˇcného umístˇení. Vzhledem k použití mezilehlého úložištˇe (oznaˇceného jako StageDB, v textu také jako meziúložištˇe), sestává tento proces ze dvou hlavních fází ([18, Kapitola 10, s. 275]): •

extrakce dat ze zdrojového systému do meziskladu

•

transformace dat a jejich nahrání do data martu

Hlavními zdroji dat TDM jsou archivní data BMS a pasport. Rozdíl mezi databázemi HistorianDB (archivní data BMS) a databází pasportu spoˇcívá zejména v tom, že BMS generuje vˇetšinu dat (až na výjimky, jako jsou uživatelské texty) programovˇe, na základˇe definovaných pˇredpisu, ˚ odpadá tedy vˇetšina problému˚ s cˇ istotou dat, duplicit apod. Oproti tomu stavební a technologický pasport je poˇrizován lidmi a pˇres sofistikovaný systém kontroly pˇri nahrávání do cílové geodatabáze je zde pravdˇepodobnost chyb a nekonzistencí rˇ ádovˇe vˇetší. Bohužel jsou však tyto chyby zpravidla obtížnˇe (ˇci vubec) ˚ strojovˇe odhalitelné, pˇrímoˇcaˇre lze kontrolovat pouze referenˇcní integritu (popsáno v 6.3.3). Jiné údaje, které nemají definované cˇ íselníky (jde o volný text), pˇredstavují vˇetší problém. Jedním z uvažovaných rˇ ešení je snaha o maximální možné ošetˇrení hodnot cˇ íselníky tak, jde však o opatˇrení na úrovni zdrojové databáze. Klíˇcový atribut, který je použit pro párování záznamu˚ z BMS a TP, je oznaceni_dle_dokumentace. Ze strany BMS je jisté, že daná zaˇrízení existují (protože generují data), v pˇrípadˇe, že se nepodaˇrí dohledat protˇejšek v TP, je tˇreba hledat pˇríˇcinu bud’ v projektové dokumentaci, nebo v TP. Chyby projektové dokumentace lze odstranit úpravou výstupu zpracování, pˇrípadnˇe opravou zdroje a opˇetovného 45


provedení procedury mapování s BMS. Problémy s kvalitou dat je tˇreba rˇ ešit pˇrímo s jejich správci, za tím úˇcelem budou pˇri plnˇení StageDB i TDM zavedeny tabulky obsahující nevyhovující data, které budou dále pˇredány správcum ˚ databáze SDE k nápravˇe chyb. 5.6.1

ˇ Casová platnost dat

Duležitou ˚ vlastností datového skladu (a samozˇrejmˇe i data martu) je ukotvenost dat v cˇ ase, všechna, u kterých je to relevantní, by mˇela mít evidovánu historii. V pˇrípadˇe TDM se to týká jak dat mˇerˇ ení a událostí, tak jejich pˇredpisu, ˚ tedy dimenzí BMS, a rovnˇež prostorové dimenze. U mˇerˇ ení a událostí jsou cˇ asová razítka ukládána již v okamžiku vytvoˇrení záznamu, navíc tato data ze své podstaty nebudou mˇenˇena (mˇerˇ ení ani událost v cˇ ase nemají žádný referenˇcní údaj, podle kterého by mohly být upraveny), zde je tedy situace nejjednodušší. Bude použita technika nahrání dat do meziúložištˇe na základˇe doby provedení posledního nahrání. Složitˇejší je situace u tabulek TL a EVL, které cˇ asové údaje neobsahují. Je ale žádoucí v nich evidovat zmˇeny a ukládat historické verze zejména pˇredpisu˚ trendlogu, ˚ aby pak bylo možné správnˇe vyhodnocovat archivní data mˇerˇ ení. U eventlogu˚ je naopak možnost zmˇeny smˇerování a tedy nastává stejná situace. SQL Server od verze 2008 obsahuje nˇekolik nástroju˚ pro archivaci ruzných ˚ verzí dat, z nichž nejpokroˇcilejší, umožnující ˇ plnohodnotné sledování historie, se nazývá Change Data Capture. Bohužel, jeho zavedení by znamenalo zmˇeny v databázích Historian, které vzhledem trvající záruce nejsou akceptovatelné. Proto je tˇreba sledování zmˇen provádˇet externˇe, mimo vlastní databázi, i za cenu snížení pˇresnosti zachycení zmˇen konkrétnˇe s pˇresností odpovídající intervalu stahování dat do meziúložištˇe. Existuje teoretická, i když zatím neovˇerˇ ená možnost zpˇetnˇe odvozovat tyto zmˇeny pomocí sledování zmˇen ve faktových tabulkách, jenže pak by zase nebylo možné použít dimenzionální tabulky pro detekci chyb ve faktech. Tyto tabulky tedy budou periodicky celé stahovány a následnˇe nahrávány do TDM v režimu SCD 26 .

5.7

Fyzický návrh

V této cˇ ásti jde jak o pˇrenesení dosud provedených návrhových rozhodnutí do úrovnˇe fyzické reprezentace dat, tak o rˇ ešení indexování, dˇelení (parti6. V praxi se nejˇcastˇeji setkáme s dˇelením SCD na tˇri kategorie: SCD 1 znamená pˇrepisování starých dat, SCD 2 archivaci všech zmˇen SCD 3 pak uchovávání aktuální a pˇredchozí hodnoty.

46


tioning) a kompresi dat. Jedná se o oblast úzce spjatou s konkrétním databázovým produktem, v tomto pˇrípadˇe tedy MS SQL Server 2012. Z toho duvodu ˚ i tato cˇ ást cˇ erpá vˇetšinu poznatku˚ z [25]. Vzhledem k tomu, že jde o návrh pilotního data martu, které bude sloužit jako podklad k pˇrípadnému dalšímu rozvoji v této oblasti, neˇreší se zde problematika konkrétního hardwaru, jako jsou napˇríklad parametry použitého serveru, konfigurace disku˚ cˇ i diskového pole (vˇcetnˇe redundance dat pomocí RAID) atp. Tyto otázky jsou ponechány návazným projektum. ˚ Z logického modelu byl v této fázi vytvoˇren model fyzický (Obrázek 5.7), do kterého byly pˇridány údaje o klíˇcích, indexech a datových typech atributu, ˚ dále je z nˇej patrné, které vazby jsou povinné identifikující (plnou cˇ arou), povinné neidentifikující (ˇcárkovanˇe) a nepovinné (ˇcárkovanˇe s kosoˇctvercem). Došlo také ke zmˇenám v atributech jednotlivých tabulek, zejména se podstatnˇe zvˇetšil rozsah dimenze Prostor. 5.7.1

Indexování

Indexování v datovém skladu má nˇekteré specifické rysy spojené pˇredevším s již zmínˇeným režimem využití dat, tedy zejména orientací na nejlepší výkon pˇri cˇ tení. Co se týˇce dimenzionálních tabulek, podstatným rozdílem je, že index, podle kterého je vytváˇrena fyzická struktura dat (klastrovaný, clustered index), zde zpravidla není vytváˇren na primárním klíˇci (tedy syntetický, novˇe vytvoˇrený tzv. surrogate key), ale na puvodním ˚ klíˇci (tedy business key). Fyzická struktura dat je tedy podobná jako ve zdrojových systémech. Další, podružné indexy (nonclustered) jsou pak definovány na primárním klíˇci a zárovenˇ na cˇ asto dotazovaných sloupcích. U faktových tabulek je doporuˇcováno vytvoˇrit klastrovaný index na cizím klíˇci odkazujícím se na nejpoužívanˇejší dimenzi, což je zpravidla cˇ asová. Rovnˇež lze vytvoˇrit další indexy na jednotlivých cizích klíˇcích cˇ asto používaných dimenzí. Novinkou SQL Serveru verze 2012 je technika indexování po sloupcích, resp. tzv. columnstore index. Tento zpusob ˚ indexování, který pracuje s tabulkou „opaˇcnˇe“ než klasický index (seskupuje data po sloupcích namísto po rˇ ádcích), byl vyvinut pro Business Intelligence a datové sklady (resp. obecnˇe pro potˇreby analýzy velkého množství dat). Díky columnstore indexu by nadále nemˇelo být nutné ukládat pˇredem vypoˇctené hodnoty agregaˇcních funkcí [9]. Protože je index pouze pro cˇ tení, je tˇreba jej pˇri každém nahrávání dat zrušit a po dokonˇcení obnovit, což muže ˚ znamenat potenciální prodloužení této operace. Vzhledem k pˇredpokládanému provozu 47


Obrázek 5.7: Fyzický model TDM

48


TDM (tedy pˇrevážnˇe v pracovní dobˇe, není plánován režim 24x7) však toto nepˇredstavuje problém. Columnstore index bude nasazen na faktových tabulkách, tedy Fakt_ Mereni a Fakt_Udalost. 5.7.2

Pokroˇcilé metody správy dat pro velké databáze

V úvodu této práce byla uvedeno na první pohled vysoké množství (300 miliónu) ˚ záznamu˚ archivovaných z BMS, pokud budeme pˇredmˇetné databáze posuzovat z fyzického hlediska, jedná se o pˇribližnˇe 35 GB dat, s prumˇ ˚ erným denním pˇrírustkem ˚ obou instancí HistorianDB zhruba 24 MB. Zmínˇený rustový ˚ potenciál by i v pˇrípadˇe znˇekolikanásobení archivovaného objemu dat 7 stále nebyl natolik dramatický, abychom mohli TDM oznaˇcovat jako VLDB, tedy velmi velkou databázi (databáze pasportu je pak rˇ ádovˇe menší a plní se spíše nárazovˇe, podstatnˇe pomaleji, což je dáno i zpu˚ sobem vzniku dat - nejsou generována, ale poˇrizována víceménˇe ruˇcnˇe). Jakkoliv tento pojem není obecnˇe definován, má se za to, že jde o databázi, která je tak velká, že zpravidla není možné ji duplikovat pro vývoj a testování, nelze ji standardnˇe zálohovat za dobu menší než 24 hodin atp. ([37]), tˇechto kritérií lze nalézt hodnˇe, každopádnˇe jde zcela jistˇe o databázi o velikosti v rˇ ádu (desítek) TB, zcela jiných dimenzí než zde uvažované úložištˇe. Jak bylo uvedeno v 5.7.1, vzhledem k úˇcelu, rozsahu a potenciálnímu poˇctu uživatelu˚ TDM se pˇredpokládá režim zátˇeže, který nebude extrémní (zejména ve smyslu velkého množství paralelních nároˇcných dotazu). ˚ Není tˇreba implementovat napˇr. partitioning (dˇelení tabulek), které najde využití zejména pro správu dat a muže ˚ potenciálnˇe zvýšit výkon pomocí paralelního pˇrístupu (ˇcasto v kombinaci s tzv. filegroups, které umožnují ˇ fyzické oddˇelení cˇ ásti DB) a vzhledem k objemu dat ani jejich kompresi. Mnohé z tˇechto technik však mohou být plnˇe využity teprve v kombinaci s odpovídajícím HW vybavením, je pravdˇepodobné, že v pˇrípadˇe rozšiˇrování tohoto rˇ ešení (nebo budování tzv. Enterprise Data Warehouse - EDW, tedy nˇejaké formy celouniverzitního úložištˇe) najdou uplatnˇení.

7. Což není v horizontu nˇekolika málo pˇríštích let pˇríliš pravdˇepodobné, vzhledem ke stávajícímu a plánovanému poˇctu budov pujde ˚ spíše o nárust ˚ zhruba o polovinu, aˇckoliv výrazný vliv mohou mít u rekonstrukce stávajících budov, které jsou cˇ asto spojené s jejich pˇripojením do BMS.

49

6 Popis implementace V této cˇ ásti je popsána vlastní realizace pilotního projektu Technologického data martu, který byl navržen v pˇredchozích cˇ ástech. Kapitola pokrývá proces získávání a cˇ ištˇení dat, následnˇe pak naplnˇení vlastního úložištˇe. Zvláštní cˇ ástí je popis propojení dat BMS a pasportu, které je nutné realizovat pro naplnˇení prostorové dimenze. Vzhledem ke specifické povaze zdrojového systému jsou v tomto pˇrípadˇe aplikovány ne zcela standardní techniky získání dat, jak je rozvedeno v 6.4. Jako referenˇcní zdroje bylo vybráno nˇekolik budov Univerzitního kampusu (konkrétnˇe etapy Zelená F a CETOCOEN), celkem jde o šest pavilonu, ˚ což pˇredstavuje zhruba pˇetinu stávajícího rozsahu. Volba byla provedena s ohledem na získávání dat z obou uzlu˚ HistorianDB a zárovenˇ stav zpracování technologického pasportu. Projekt TDM je z pˇrevážné cˇ ásti realizován pomocí nástroje SQL Server Integration Services (SSIS), který poskytuje vˇetšinu potˇrebné funkcionality. Jednotlivé cˇ ásti rˇ ešení jsou zde organizovány do takzvaných balíˇcku˚ (packages), které tvoˇrí logické celky seskupující dílˇcí úlohy, lze je samostatnˇe spouštˇet, pˇridávat a odebírat z projektu atp. Základní pohled na každý balíˇcek nabízí tzv. Control Flow (ˇrídící tok), znázornující ˇ jednotlivé komponenty (jako jsou napˇr. provedení SQL pˇríkazu, tok dat neboli Data Flow, vyhodnocení výrazu,. . . ), mezi nimiž jsou precedenˇcní vazby vyhodnocené na základˇe úspˇešného cˇ i neúspˇešného provedení pˇredcházející komponenty. Klíˇcovou komponentou je Data Flow, který se sám skládá z vnoˇrených úloh a poskytuje tak druhý, detailnˇejší pohled na strukturu balíˇcku. Mezi jeho souˇcástmi jsou vazby organizovány obdobnˇe, zde však jde pˇrímo o jednotlivé datové toky, které mohou být ruznˇ ˚ e smˇerovány.1 Ukázku Control Flow znázornuje ˇ D.1, Data Flow pakD.2. V projektu TDM je použito osm balíˇcku, ˚ dva pro definici struktury oblasti zpracování StageDB a TDM vˇcetnˇe vytvoˇrení procedury pro generování obsahu cˇ asové dimenze (StageDB_struktura.dtsx, TDM_struktura.dtsx), další tˇri pro plnˇení meziúložištˇe (Mereni_stazeni.dtsx, Udalosti_stazeni.dtsx, TP_stazeni.dtsx), jeden pro zpracování pomocných zdroju˚ dat (Pomocne_ zdroje.dtsx) a pro plnˇení samotného TDM (TDM_plneni.dtsx). Osmý balíˇcek je rˇ ídící, tzv. master (Master.dtsx). Volá jednotlivé balíˇcky v daném poˇradí (pochopitelnˇe mohou být vybrány pouze nˇekteré). Koncept master balíˇcku umožnuje ˇ lepší správu a vývoj jednotlivých balíˇcku˚ a pˇrináší i další 1. Detailnˇejší informace lze nalézt napˇr. v cˇ lánku http://msdn.microsoft.com/enus/library/ms141134.aspx.

50

6. P OPIS IMPLEMENTACE výhody (dle [28, Lesson 3: Using a Master Package for Advanced Control Flow]). Pro potˇreby inkrementálního ETL a rovnˇež z duvodu ˚ pˇrehledné správy prubˇ ˚ ehu plnˇení je v obou databázích zavedeno logování událostí. Z dostupných možností byla vybrána možnost zápisu prostˇrednictvím SQL Serveru, to znamená, že tato data jsou v každé databázi uchovávána v systémové tabulce sysssislog. Odsud je pak možné získat jednak cˇ as poslední extrakce, který je použit v balíˇccích Mereni_stazeni a Udalosti_stazeni, a zejména vyhodnocovat pˇrípadné problémy provádˇení jednotlivých komponent. Je možné konfigurovat, které události vztahující se k jednotlivým komponentám budou zachycovány (napˇr. OnPreExecute, OnPostExecute, OnError, OnWarning), aktuálnˇe jsou pro úˇcely ladˇení sledovány všechny.

6.1

Použité metody prubˇ ˚ ežného získání dat

V prubˇ ˚ ehu návrhu TDM se ukázalo, že je tˇreba pˇristupovat k datovým zdrojum ˚ jako k nemˇenným databázím, a proto není zejména možné zavádˇet zde sledování zmˇen (tedy použít nástroj Change Data Capture nebo Change Tracking). To s sebou pˇrináší jisté komplikace, nicménˇe nikoliv zásadní. Zejména je tˇreba zvolit vhodný postup získávání a udržování aktuálních dat, s ohledem na jejich vlastnosti (množství, možnost zmˇen atp.). Tato problematika je cˇ ásteˇcnˇe rˇ ešena v 5.6.1, zde jsou uvedeny podrobnosti ve vztahu k vlastní implementaci. 6.1.1

Dimenze

Vyznaˇcují se menším poˇctem záznamu˚ než faktové tabulky (ˇrádovˇe pouze desítky až malé tisíce u BMS a desetitisíce u TP), jejich obsah je v cˇ ase relativnˇe stabilní. Zdrojová data pro dimenze z BMS ani pasportu neobsahují údaje o cˇ asové platnosti tˇechto dat (ˇcasová dimenze je pochopitelnˇe výjimka, z tohoto pohledu není tˇreba se jí zabývat). Tyto charakteristiky umožnují ˇ zvolit na stranˇe meziúložištˇe (StageDB) pˇrístup stahování celého obsahu zdroje pˇri každé extrakci, což je nejjednodušší varianta. Zmˇeny jsou pak detekovány pˇri plnˇení TDM s využitím komponenty SCD2 , která pˇri správné konfiguraci zajistí odpovídající zacházení s atributy (které jsou oty2. Komponenta SCD bývá nˇekdy hodnocena jako problematická z hlediska výkonu (viz napˇr. http://connect.microsoft.com/SQLServer/feedback/details/632052/ssis-slowlychanging-dimension-scd-component-performance-unusably-slow), nicménˇe v tomto rozsahu by nešlo závažný problém, nízká rychlost této komponenty se pˇri nasazení navíc nepotvrdila.

51

6. P OPIS IMPLEMENTACE povány jako fixní, mˇenitelné a historické). Pˇridáním pˇríznaku˚ platnosti jednotlivých záznamu˚ (Platne_od, Platne_do) je pak zajištˇena historizace potˇrebných atributu. ˚ 6.1.2

Faktové tabulky

Velký poˇcet záznamu˚ (ˇrádovˇe až stovky milionu) ˚ neumožnuje ˇ použití stejnˇe pˇrímoˇcarého rˇ ešení jako u dimenzí, tedy opakované získávání celého obsahu zdrojových tabulek. Záznamy obou zdrojových tabulek faktu˚ z Historian DB, TLData a EVLData, obsahují cˇ asové razítko urˇcující záznamy, které je tˇreba stáhnout. K tomu jsou využity údaje ukládané pˇri logování pru˚ bˇehu vykonání balíˇcku. ˚ Konkrétnˇe je pˇri každé extrakci získán cˇ as zahájení pˇredchozí extrakce a záznamy s vˇetším cˇ asovým razítkem jsou staženy do StageDB. Pˇri plnˇení TDM jsou pak použity všechny tyto záznamy (protože dané tabulky ve StageDB jsou pˇred každou extrakcí vyprázdnˇeny).

6.2

Definice struktury

6.2.1

Balíˇcek StageDB_struktura

Obsahuje jedinou komponentu, provedení skriptu pro vytvoˇrení databáze StageDB a pˇríslušných tabulek. Struktura primárních tabulek (tedy tˇech urcˇ ených pro data ze zdrojových databází) je pochopitelnˇe odvozena z pu˚ vodních tabulek. Dále jsou zde tabulky pro ukládání dat, která nˇejakým zpusobem ˚ nevyhovˇela pˇri plnícím procesu (typicky nebyl nalezen odpovídající protˇejšek v referenˇcní tabulce), napˇr. Nedohledane_adresy_Mereni, Nedohledane_EVLData_BMS, Nesparovane_TL apod. Tyto tabulky jsou plnˇeny z alternativních destinací v rámci Data Flow se shodným názvem jako je název tabulky. Nakonec StageDB obsahuje tabulky s údaji získanými z rˇ ídících programu˚ (viz 6.4) a údaji z projektové dokumentace a další (ˇcíselník lokalit fm_lokalita, cˇ íselník objektu˚ technologické sítˇe Pom_ciselnik_typu_ objektu_EV). 6.2.2

Balíˇcek TDM_struktura

Slouží k vytvoˇrení databáze TDM, faktových a dimenzionálních tabulek (viz 5.6).3 Dále obsahuje komponentu pro vytvoˇrení procedury uspLoad3. K pˇrevodu fyzického modelu databáze ze SW Visio 2010 do podoby SQL skriptu byl použit addin Visio Forward Engineer, jehož autorem je Alberto Ferarri, viz http://www.sqlbi.com/tools/visio-forward-engineer.

52

6. P OPIS IMPLEMENTACE DimTime, která plní dimenzionální tabulku Dim_Cas4 .

6.3

Pˇrístup k datum ˚ a plnˇení oblasti zpracování

Jak je patrné z 5.1, je využito celkem pˇet datových zdroju, ˚ dvˇe databáze archivních dat BMS s identickou strukturou (Historian A a Historian B), databáze pasportu a dále dva specifické zdroje, technologická sít’ a projektová dokumentace. První tˇri jmenované jsou instance SQL Serveru 2008, resp. 2005, k pˇripojení k nim jsou použity standardní datové zdroje ODBC (které jsou novˇe doporuˇcovány jako standard, proprietární API Microsoftu OLE DB nemá být v dalších verzích podporováno a tedy ani používáno pro nový vývoj [28, s. 135]5 ). Využití zbývajících dvou zdroju˚ je pˇredmˇetem 6.4. 6.3.1

Balíˇcek Mereni_stazeni

Zabezpeˇcuje získání dat vztahujících se k mˇerˇ ením BMS. Postup je následující: 1.

Vyprázdnˇení dotˇcených tabulek, tedy ObjectMap, Sloucene_TL a Sloucene_TLData.

2.

Stažení obsahu ObjectMap (které obsahují vazby mezi archivními a zdrojovými trendlogy) z obou serveru˚ Historian, opatˇrení záznamu˚ identifikací serveru a následnˇe uložení do Sloucene_ObjectMap.

3.

Stažení obsahu TL (definice archivních trendlogu) ˚ z obou serveru˚ Historian, opatˇrení záznamu˚ identifikací serveru a následnˇe uložení do Sloucene_TL.

4.

Získání cˇ asu poslední extrakce dat z logu.

5.

Stažení obsahu TLData (vlastní data mˇerˇ ení) z obou serveru˚ Historian, který pˇribyl od poslední extrakce, opatˇrení záznamu˚ identifikací serveru a následnˇe uložení do Sloucene_TLData.

4. Tato procedura cˇ ásteˇcnˇe vychází ze studijních materiálu˚ poskytnutých na školení Implementace Data Warehouse v Microsoft SQL Server 2012 spoleˇcnosti Gopas. 5. Na základˇe této informace byla provedena zmˇena datových zdroju˚ z OLE DB na ODBC, bohužel se ukazuje, že novˇe preferovaný pˇrístup není dosud v SSIS implementován ve srovnatelné kvalitˇe s OLE DB, zejména co se týˇce parametrizace dotazu˚ a citlivosti na chyby v datech, resp. schopností jejich reportování (to se týká komponent pro zápis dat).

53

6. P OPIS IMPLEMENTACE 6.3.2

Balíˇcek Udalosti_stazeni

Slouží k získání dat událostí BMS. Postup se liší od mˇerˇ ení kvuli ˚ odlišnému mechanismu práce s událostmi, viz 5.2.1. Je tedy tˇreba ovˇerˇ it shodu EVL, prunik ˚ uložit do Sloucene_EVL a symetrický rozdíl tˇechto množin do Liche_EVL. U vlastních dat událostí je postup obdobný, s tím rozdílem, že jsou podobnˇe jako u mˇerˇ ení stažena pouze novˇe uložená data. Níže následuje postup po krocích. 1.

Vyprázdnˇení EVL_A, EVL_B, Sloucene_EVL a Sloucene_EVLData.

2.

Stažení obsahu EVL (eventlogy) z obou serveru˚ Historian, opatˇrení záznamu˚ identifikací serveru a uložení do EVL_A, resp. EVL_B.

3.

Provedení pruniku ˚ (SQL operátor INTERSECT) EVL_A a EVL_B, uložení výsledku do Sloucene_EVL.

4.

Provedení symetrického rozdílu (kombinace SQL operátoru˚ EXCEPT a UNION) EVL_A a EVL_B, uložení výsledku do Liche_EVL.

5.

Stažení obsahu EVLData (vlastní záznamy o událostech) z obou serveru˚ Historian, který pˇribyl od poslední extrakce, opatˇrení záznamu˚ identifikací serveru a uložení do EVLData_A, resp. EVLData_B.

6.

Provedení pruniku ˚ (SQL operátor INTERSECT) EVLData_A a EVLData_B, uložení výsledku do Sloucene_EVLData.

7.

Provedení symetrického rozdílu (kombinace SQL operátoru˚ EXCEPT a UNION) EVLData_A a EVLData_B, uložení výsledku do Liche_ EVLData.

6.3.3

Balíˇcek TP_stazeni

Slouží k získání dat technologického pasportu. Zdrojová data jsou specifická tím, že navzdory existenci vazeb tyto nejsou ošetˇreny pomocí cizích klíˇcu˚ a tabulky dokonce nemají ani primární klíˇce. Pˇrestože to není typickou úlohou pro získání surových dat (staging), do cílových tabulek byly tyto klíˇce doplnˇeny, aby byla zajištˇena integrita dat již v první fázi. Stahování dat tedy musí probíhat od tabulek, které se neodkazují na žádné další, postup svým zpusobem ˚ kopíruje datový model TP, od nˇehož byl odvozen. Pro každou tabulku existuje jedna komponenta Data Flow, jejímž obsahem je pak pouze zdrojové a cílové umístˇení, pˇrípadnˇe pomocný cíl pro data, která z nˇejakého duvodu ˚ nebylo možné uložit do standardního umístˇení 54

6. P OPIS IMPLEMENTACE (nejˇcastˇeji z duvodu ˚ porušení referenˇcní integrity). Tato data budou dále pˇredána správcum ˚ pasportu pro sjednání nápravy (lze uvažovat o automatických notifikacích, toto bude ovˇerˇ eno v provozu). Dalším krokem je normalizace, probíhající v rámci StageDB. Výstupem je tabulka Pom_Dim_ Prostor, která poslouží jako zdroj pˇri plnˇení TDM. Vynechány byly tabulky vztahující se ke geometrii a také tabulka Vztah, popisující vazby mezi objekty TP. Tato data nelze vzhledem k povaze vazeb (netvoˇrí strom, ale graf) jednoduše denormalizovat, bylo by však možné ji zahrnout v nezmˇenˇené podobˇe (tedy záznam se dvˇema TK a typem vztahu), v pˇrípadˇe, že by vyvstala potˇreba mít tuto informaci dostupnou (stejnˇe jako u ostatních otázek v souvislosti s pasportem záleží na výsledku jeho transformace).

6.4

Mapování BMS TP

Ani databáze archivních dat BMS, ani technologického pasportu neobsahují vazbu na druhý systém. Je proto tˇreba tuto vazbu dodat externˇe. Ve své bakaláˇrské práci jsem navrhl postup, jak (ne zcela spolehlivˇe, zejména s velkými nároky na kvalitu vstupních dat obou zdroju) ˚ mapovat objekty technologické sítˇe na TP s využitím projektové dokumentace. Tato ovšem popisuje pouze fyzické vstupy a výstupy zaˇrízení (tzv. objekty typu IO), je tedy tˇreba získat další informace o vztazích mezi objekty BMS (typicky pˇrirˇ azení hodnoty do jiného objektu a archivace tohoto odvozeného objektu). Navržený postup spoˇcívá v analýze rˇ ídících programu˚ technologické sítˇe (celkem se jedná o vzorek 1139 rˇ ídících programu) ˚ a jejich zpracování pomocí aplikace PGReader6 . Výstupem je tabulka pˇriˇrazení mezi dvojicemi objektu˚ (bylo získáno 3547 záznamu). ˚ 6.4.1

Balíˇcek Pomocne_zdroje

Zajišt’uje zpracování výstupu˚ utility PGReader a projektové dokumentace. Následuje popis jednotlivých kroku: ˚

6.

1.

Naplnˇení tabulky bmslinks ve StageDB z výstupu PGReader ve formátu CSV.

2.

Pomocí rekurzivního skriptu (s využitím tzv. CTE, common table expression) získání tras pˇriˇrazení od posledního cˇ lánku až ke zdrojovému objektu (komponenta Mapování tras (CTE)). Tato utilita byla vyvinuta Adamem Kuˇcerou.

55

6. P OPIS IMPLEMENTACE 3.

Filtrace zdrojových objektu˚ (komponenta Získání zdrojových objektu). ˚ Výsledkem tohoto kroku je seznam objektu, ˚ které svou hod7 notu nepˇrebírají , považujeme je tedy za zdrojové. V ideálním pˇrípadˇe by mˇelo jít o objekty vstupu˚ a výstupu, ˚ není tomu tak ale vždy. ˇ Casto se trendují i žádané hodnoty a jiné ukazatele bez pˇrímé vazby na zaˇrízení.

4.

Spárování zdrojových objektu˚ trendlogu˚ (z puvodní ˚ tabulky TL) s objekty na poˇcátku trasy (komponenta Propojení TL a BMS).

5.

Paralelnˇe s pˇredchozími kroky probíhá naplnˇení tabulky Propojene_ TP_TeNe, která obsahuje vazbu mezi TL a projektovou dokumentací.

6.

Po dokonˇcení všech pˇredchozích kroku˚ lze propojit získané údaje o zdrojových objektech s trendlogy a projektovou dokumentací, která obsahuje vazbu na TP (komponenta Napojení odvozených zdroju). ˚

7.

Dále opˇet s využitím Propojene_TP_TeNe je provedeno propojení pˇrímých zdroju˚ (v pˇrípadˇe, že TL jako vstup využívá objekt typu IO, a tedy není tˇreba mapovat vazby v BMS).

Pˇri zkoušce na testovacích datech probˇehlo zpracování dat získaných pomocí PGReaderu v poˇrádku, nicménˇe pˇri aplikaci na reálná data vyhodnocení CTE probˇehlo neúspˇešnˇe z duvodu ˚ nekoneˇcné rekurze, což je v tomto pˇrípadˇe pˇríznakem cyklické výmˇeny hodnot mezi objekty. Ukázalo se, že na daném vzorku jde pouze o jeden výskyt, který byl ruˇcnˇe opraven, avšak do budoucna by bylo vhodné detekovat podobné pˇrípady automatizovanˇe, už proto, že s nejvˇetší pravdˇepodobností jde o známku ne zcela ideální implementace rˇ ídícího programu. Výstupem balíˇcku Pomocne_zdroje.dtsx jsou tabulky s pˇrímými i odvozenými vazbami na TP, které budou dále využity pˇri plnˇení faktové tabulky mˇerˇ ení.

6.5

Plnˇení TDM

Po dokonˇcení aktualizace databáze StageDB lze v každé iteraci pˇristoupit k plnˇení vlastního data martu. Postup plnˇení znázornuje ˇ D.1, je tˇreba plnit 7. Pˇresnˇeji rˇ eˇceno nepˇrebírají ji prostˇrednictvím protokolu BACnet, bohužel v síti existuje rˇ ada zaˇrízení, která jsou od jisté úrovnˇe cˇ ernou skˇrínkou ˇ a nelze se tak dopátrat zcela puvodního ˚ zdroje dat.

56

6. P OPIS IMPLEMENTACE „zvenku“, tedy zaˇcít tabulkami, na které se pomocí cizích klíˇcu˚ odkazují jiné - tedy od okrajových dimenzionálních tabulek po faktové tabulky. 6.5.1

Balíˇcek TDM_plneni

Plnˇení TDM z meziúložištˇe (StageDB), jde o nejkomplexnˇejší balíˇcek. Struktura se odvíjí od modelu databáze, nejdˇríve je tˇreba plnit dimenzionální tabulky, resp. ty, které nejsou odkazovány cizími klíˇci.. 1.

Naplnˇení subdimenze Lokalita. Vychází z fm_lokalita doplnˇené o Adresa_od, Adresa_do pro povolený rozsah adres zaˇrízení BMS dané lokality. Jak již bylo zmínˇeno, tato informace není dosud nikde vedena ve zpracovatelné podobˇe, proto je tˇreba hodnoty doplnit ruˇcnˇe, resp. generovat napevno.

2.

Naplnˇení dimenze Dim_Mereni_BMS. (a)

Získání Sloucene_TL. Ke zdrojovým datum ˚ je doplnˇen sloupec Typ, jehož hodnota je odvozena na základˇe rozboru názvu˚ jednotlivých trendlogu˚ (viz skript TL_types.sql v pˇriložených materiálech). Jde pouze o hrubé rozdˇelení, do budoucna by bylo vhodnˇejší pro tyto úˇcely pracovat se zaˇrízeními TP.

(b) Dohledání (komponenta typu Lookup) v ObjectMap, zápis nedohledaných do Nesparovane_TL. (c)

Dohledání v Subdim_Lokalita (Adresní rozsahy). Jde o specifické použití Lookup, protože je tˇreba použít upravený dotaz s parametrem, kterým je adresa zaˇrízení; nejde o pˇrímé párování, ale o zasazení hodnoty do rozsahu v referenˇcní tabulce (SQL operátor BETWEEN). Nedohledané trendlogy jsou zapsány do Nedohledane_adresy_Mereni.

(d) Úpravy a pˇridání sloupcu. ˚ Jde po rˇ adˇe o stanovení hodnoty pˇríznaku Je_polling na základˇe hodnoty sloupce LogInterval (0 znamená nepravda, ostatní pravda), obdobnˇe Typ_logovani_ nazev s hodnotami „COV” a „polling” (tyto dva jsou informaˇcnˇe identické, jsou zavedeny pro zlepšení práce s daty). Dále sumarizaˇcní pˇríznaky (AVG, MAX_MIN, SUM, COUNT), jejichž hodnoty jsou odvozeny na základˇe sloupce Typ. Nakonec sloupce Platne_od, Platne_do pro urˇcení platnosti záznamu (viz další bod). 57

6. P OPIS IMPLEMENTACE (e)

3.

Použití komponenty SCD pro zachycení promˇen obsahu dimenze v cˇ ase. V této komponentˇe je nastaveno, jaké sloupce reprezentují puvodní ˚ klíˇce (business keys) a pro každý atribut pak, zda je fixní, mˇenící se nebo historický, tedy je tˇreba archivovat všechny jeho stavy. Jako fixní je nastaveno pouze ID_ Lokalita, protože se nepˇredpokládá pˇresun mezi nimi, mˇenící se jsou sumarizaˇcní pˇríznaky, ostatní atributy jsou historické. SCD generuje tˇri výstupy, Historical Attributes Inserts Output, Historical Attributes Updates Output a New Output, následnˇe jsou pomocí dalších komponent upraveny data platnosti, pˇrípadnˇe zmˇenˇeny atributy, u nichž je to dovoleno, výsledek sjednocen a zapsán do Dim_Mereni_BMS. Chyby jsou pˇresmˇerovány do Chyby Dim_Mereni_BMS.

Naplnˇení dimenze Dim_Udalost_BMS. (a)

Získání Sloucene_EVLData. Pˇrestože jde zárovenˇ o zdroj faktové tabulky událostí, je tˇreba ji použít pro identifikaci jednotlivých EV (nikoliv EVL), protože tato informace není jinde v HistorianDB uchovávána.

(b) Dohledání v EVL (komponenta Lookup) pro získání dalších atributu˚ (název EVL, práh notifikace,. . . ). (c)

Dohledání v Subdim_Lokalita (Adresní rozsahy). Použito identicky jako u Dim_Mereni_BMS.

(d) Úpravy a pˇridání sloupcu. ˚ Konverze sloupce s prahovou hodnotou, pˇridání Platne_od, Platne_do pro urˇcení platnosti záznamu (viz další bod).

4.

(e)

Použití komponenty SCD pro zachycení promˇen obsahu dimenze v cˇ ase, podobnˇe jako u Dim_Mereni_BMS.

(f)

Zápis do Dim_Udalost_BMS, resp. Chyby Dim_Udalost_BMS.

Naplnˇení dimenze Prostor. (a)

Získání Pom_Dim_Prostor.

(b) Pˇridání odvozených sloupcu˚ Podlazi, Budova, Lokalita, Technologicky_kod pro usnadnˇení využití dat (nebude nutné dˇelit, resp. sluˇcovat jiné sloupce). (c)

Dohledání lokality na základˇe shody sloupce Lokalita s Polohovy_kod subdimenze Lokalita. 58

6. P OPIS IMPLEMENTACE (d) Použití komponenty SCD pro zachycení promˇen obsahu dimenze v cˇ ase, podobnˇe jako u pˇredchozích dimenzí. (e)

Zápis do Dim_Prostor, resp. Chyby Dim_Prostor.

5.

ˇ Naplnˇení dimenze Cas. Je realizováno voláním procedury uspLoadDimTime, vytvoˇrené balíˇckem TDM_struktura.dtsx, s parametry urˇcujícími rozsah generovaných záznamu. ˚ Každý záznam reprezentuje jednu hodinu, identifikátor je tedy složen z roku, mˇesíce, dne a hodiny (napˇr. 2013051216). Pro potˇreby TDM byly generovány záznamy v rozsahu srpen 2007 (poˇcátek archivace dat BMS) až prosinec 2015, celkem tedy tato dimenze obsahuje 73777 rˇ ádku. ˚ Záznamy jsou denormalizované, obsahují jednotlivé cˇ íselné údaje pro rok, mˇesíc, den v mˇesíci, den v týdnu a hodinu, datum ve formátu date, dále názvy mˇesícu˚ a dnu˚ v týdnu. Kromˇe toho jsou zde cˇ tyˇri binární sloupce indikující, zda jde o pracovní den a pracovní dobu, topnou sezónu a semestr. Pracovní den a pracovní doba jsou odvozovány, zbývající dva jsou pak zatím nevyužity. Do budoucna by bylo vhodné tyto hodnoty získávat externˇe, údaje o prubˇ ˚ ehu semestru nejspíš z IS MU, topnou sezónu lze odvozovat z chování technologií, tedy se nabízí analyzovat nˇekterá archivní data, pˇrípadnˇe zadávat obsluhou (stejnˇe tak pracovní dny, protože za stávajícího stavu nejsou ošetˇreny napˇr. dny pracovního klidu).

6.

Naplnˇení faktové tabulky Fakt_Mereni. Prvním krokem je zrušení columnstore indexu, který je jen pro cˇ tení. Po dokonˇcení úlohy je pak znovu obnoven pro obˇe faktové tabulky. Postup vlastního plnˇení: (a)

Získání Sloucene_TLData.

(b) Dohledání v Dim_Mereni_BMS (Dohledání BMS) na základˇe shody TLInstance a Server s Archivni_trendlog_cislo a Archivni_ trendlog_server, zápis nedohledaných do Nedohledane_TLData_ BMS. (c)

Pˇridání Rok, Den, Mˇesíc a Hodina odvozené od cˇ asového razítka pro úˇcely spárování s Dim_Cas.

(d) Dohledání v Dim_Cas na základˇe novˇe pˇridaných sloupcu˚ s Rok, Den_mesic, Mesic a Hodina v této dimenzi, zápis nedohledaných do Nedohledane_TLData_Cas. 59

6. P OPIS IMPLEMENTACE (e)

Kompletace cˇ asového razítka, pˇridání složky Hundredths obsahující setiny sekundy okamžiku poˇrízení záznamu do celkového cˇ asového razítka (tedy cˇ asu v rámci dne).

(f)

Dohledání referenˇcních dat dokumentace ve výstupech balíˇcku Pomocne_zdroje.

(g) Dohledání v Dim_Prostor. Vzhledem k tomu, že porovnávané rˇ etˇezce nemusejí být zcela totožné, je tˇreba použít komponentu fuzzy lookup, která ma nastavitelnou toleranci shody - prahovou hodnotu v rozsahu 0-1 (bohužel se tím pádem nedá eliminovat riziko chybného spárování). (h) Pˇridání odvozených sloupcu˚ Nazev_typu_zaznamu, jehož hodnota je odvozena od hodnoty slouce Type, a Numericka_hodnota, která je pˇrevzata ze sloupce Data. Protože Data obsahuje i nenumerické, servisní záznamy, je ve formátu varchar, což je ovšem nevyhovující z hlediska práce se záznamy a rovnˇež kvuli ˚ diskretizaci hodnot (která je provedena po ukonˇcení Data Flow). (i) 7.

Zápis do Fakt_Mereni, nevyhovujících záznamu˚ do Chyby Fakt_ Mereni.

Naplnˇení faktové tabulky Fakt_Udalost. Stejnˇe jako u pˇredchozí faktové tabulky je tˇreba pˇred zapoˇcetím zrušit sloupcový index, dále pak: (a)

Získání Sloucene_EVLData.

(b) Dohledání v Dim_Mereni_BMS (Dohledání BMS) na základˇe shody EVLInstance, EVLRefDeviceNo, EventRefObjectType a EevntRefInstance s Archivni_EVL_cislo, Zarizeni_definice_adresa, Definice_udalosti_typ a Definice_udalosti_cislo, zápis nedohledaných do Nedohledane_ELData_BMS. ˇ odvozené od cˇ asového (c) Pˇridání Rok, Den, Mˇesíc, Hodina a Cas razítka pro úˇcely spárování s Dim_Cas, resp. pro použití jako cˇ asu události.. (d) Dohledání v Dim_Cas na základˇe novˇe pˇridaných sloupcu˚ s Rok, Den_mesic, Mesic a Hodina v této dimenzi, zápis nedohledaných do Nedohledane_EVLData_Cas. (e)

Zápis do Fakt_Udalost, nevyhovujících záznamu˚ do Chyby Fakt_ Udalost.

60

7 Závˇer V této práci byly analyzovány možnosti dalšího zpracování dat souvisejících s provozem budov, byla provedena rozvaha stran možného využití jednotlivých zdroju˚ a ve výsledku bylo navrženo a implementováno úložištˇe pro vybraná data - Technologický data mart. Dalším bezprostˇrednˇe navazujícím krokem je zpˇrístupnˇení dat z této novˇe vzniklé platformy uživatelum, ˚ a to zpoˇcátku zejména prostˇrednictvím generovaných reportu. ˚ Dále bude nutné zajistit vhodné prostˇredí pro prezentaci geografických informací. TDM mužeme ˚ chápat jako základ pro potenciální datový sklad zahrnující vˇetšinu zde uvažovaných datových zdroju. ˚ Pro návrh byl zvolen pˇrístup tzv. zespodu nahoru (bottom-up) dle Kimballa (viz 2.2), tedy postupné budování jednotlivých dílˇcích data martu, ˚ které jsou propojeny prostˇrednictvím sdílených dimenzí. Pro realizaci pilotního projektu pˇredstavuje tento pˇrístup optimální rˇ ešení z pohledu cˇ asové nároˇcnosti, nicménˇe dá se oˇcekávat, že rozšíˇrením zábˇeru by se objevily jisté pˇrekážky. Vzhledem k povaze této architektury je rozsah na úrovni celé organizace obtížnˇe zvládnutelný, je tˇreba zavádˇet nástroje pro globální konsolidaci dat. Inmon tvrdí ([20]), že vývoj Kimballovy architektury (propagované i Microsoftem) v podstatˇe ˇ smˇerˇ uje k pˇrijetí jeho pojetí, tedy návrhu svrchu dolu˚ (top-down). Rešení této otázky je prozatím otevˇrené. Kromˇe technických otázek je však tˇreba brát v úvahu i možné organizaˇcní obtíže, které se napˇríˇc tak rozsáhlou institucí, jako je Masarykova univerzita, nutnˇe objevují. Zejména je však klícˇ ové zjistit skuteˇcné potˇreby a praktickou použitelnost takového díla - inspiraci v univerzitním prostˇredí nabízí napˇr. [1], [3] nebo [23], jakkoliv zde jde spíše o personální a jinou agendu bˇežnou i v korporacích, než o prostˇredí budov. Zdá se, že tato oblast je v datových skladech stále spíše okrajovou záležitostí. Každopádnˇe lze rˇ íci, že cíle práce se podaˇrilo naplnit, zejména mi však tento projekt umožnil získání vhledu do problematiky datových skladu˚ a obecnˇe zpracování dat za úˇcelem jejich lepší využitelnosti pro koncové uživatele, což poslouží pˇri dalším vývoji v této oblasti.

61

Literatura [1] Enterprise Data Warehouse. Information Services and Technology. [online], 2008. Dostupné z: . [cit. 2013-05-02]. [2] Herman Hollerith. Census Bureau Homepage. [online], 2013. Dostupné z: . [cit. 2013-04-21]. [3] Enterprise Data Warehouse: University BI Services. [online], 2013. Dostupné z: . [cit. 2013-0502]. [4] ArcSDE Technology. Esri - GIS Mapping Software, Solutions, Services, Map Apps, and Data. [online], 2012. Dostupné z: . [cit. 2013-04-21]. [5] IBM Statement on Nazi-era Book and Lawsuit. IBM - United States. [online], 2001. Dostupné z: . [cit. 2013-05-16]. [6] Help - InfoSphere Data Architect. IBM - United States. [online], 2007. Dostupné z: . [cit. 2013-04-21]. [7] Flowmon. INVEA-TECH: High-Speed Networking and FPGA Solutions. [online], 2013. Dostupné z: . [cit. 2013-04-21]. [8] Data Warehousing Project - ETL Design Phase. Data Warehousing What Is Data Warehouse. [online], 2013. Dostupné z: . [cit. 2013-04-21]. [9] Columnstore Indexes. Microsoft Developer Network. [online], 2012. Dostupné z: . [cit. 2013-05-10]. [10] Nagios Features. Nagios: The Industry Standard In IT Infrastructure Monitoring. [online], 2013. Dostupné z: . [cit. 2013-04-21]. 62

ˇ 7. Z ÁV ER

[11] ABRAMSON, I. Data Warehouse: The Choice of Inmon versus Kimball, 2009. Dostupné z: [cit. 2013-05-04]. [12] BEYER, M. A. et al. Magic Quadrant for Data Warehouse Database Management Systems. [online], 2013. Dostupné z: . [cit. 2013-05-04]. [13] BRUNELLI, M. Can’t Inmon and Kimball just get along? [online], 2011. Dostupné z: . [cit. 2013-05-04]. [14] DEVLIN, B. Will data warehousing survive the advent of big data? [online], 2011. Dostupné z: . [cit. 2013-05-04]. [15] ELLIOTT, T. OLAP is Dead (Long Live Analytics). [online], 2009. Dostupné z: . [cit. 2013-05-04]. [16] EVELSON, B. Topic Overview: Business Intelligence. [online], 2008. Dostupné z: . [cit. 2013-05-04]. [17] FANGYAN, R. et al. Spatial hierarchy and OLAP-favored search in spatial data warehouse. In Proceedings of the 6th ACM international workshop on Data warehousing and OLAP, DOLAP ’03, s. 48–55, New York, NY, USA, 2003. ACM. doi: 10.1145/956060.956070. Dostupné z: . ISBN 158113-727-3. [18] GOLFARELLI, M. – RIZZI, S. Data Warehouse Design: Modern Principles and Methodologies. New York : McGraw-Hill Osborne Media, 2009. ISBN 978-0-07-161039-1. [19] HARLOW, F. H. – METROPOLIS, N. Computing & Computers: Weapons Simulation Leads to the Computer Era. [online], 1983. Dostupné z: . [cit. 2013-04-21]. 63

ˇ 7. Z ÁV ER

[20] INMON, W. H. A tale of two architectures. Corporate Information Factory. [online], 2010. Dostupné z: . [cit. 2013-05-02]. [21] INMON, W. H. Building the Data Warehouse. Indianapolis, Ind. : Wiley, 4th ed. edition, 2005. ISBN 978-0-7645-9944-6. [22] KIMBALL, R. – ROSS, M. The data warehouse toolkit. New York : Wiley, 2nd ed. edition, 2002. ISBN 04-712-0024-7. [23] LEONARD, E. M. Design and Implementation of an Enterprise Data Warehouse. Master’s Theses, Marquette University, 2011. [24] LU, H. Online Analytical Processing (OLAP). [online], 2007. Dostupné z: . [cit. 2013-05-04]. [25] Implementing a Data Warehouse with Microsoft SQL Server 2012. Microsoft Corporation, 2012. [26] Oddˇelení pasportizace budov ÚVT MU. Stavební a technologický pasport MU. interní prezentace, 2012. [cit. 2013-05-04]. [27] ROKYTA, J. Integrace dat pro oblast facility managementu s využitím sémantiky. Bakaláˇrská práce, Masarykova univerzita, Fakulta informatiky, 2011. Dostupné z: . [28] SARKA, D. – LAH, M. – JERKIC, G. Training Kit (Exam 70-463): Implementing a Data Warehouse with Microsoft SQL Server 2012. Microsoft Press, 2012. ISBN 978-0-7356-6609-2. [29] SCHIFFMAN, B. IBM Gets An Ugly History Lesson. Forbes.com. [online], 2001. Dostupné z: . [cit. 2013-05-16]. [30] SICULAR, S. Big Data is Falling into the Trough of Disillusionment. [online], 2013. Dostupné z: . [cit. 2013–04]. 64

ˇ 7. Z ÁV ER

[31] STACKPOLE, B. Data warehousing architecture takes logical turn in big data era. [online], 2013. Dostupné z: . [cit. 2013-05-04]. [32] Ústav výpoˇcetní techniky MU. Projekt Nasazení modulu˚ Archibus pro podporu údržby budov a jejich technologií: základní informace o projektu. interní zpráva, 2011. [33] Ústav výpoˇcetní techniky MU. Výroˇcní zpráva za rok 2011, 2012. [34] ULRYCH, J. ETL. [online], 2011. Dostupné z: . [cit. 2013-04-21]. [35] BERKEL, J. Datawarehouse: where to locate GIS. [online], 1997. Dostupné z: . [cit. 2013-04-21]. [36] WEXLER, S. Big Data Versus Data Warehouse: Only One Will Survive. [online], 2013. Dostupné z: . [cit. 2013-05-04]. [37] WIDLAKE, M. What is a VLDB?. Martin Widlake’s Yet Another Oracle Blog. [online], 2009. Dostupné z: . [cit. 2013-05-11]. [38] WILLIAMS, P. A Short History of Data Warehousing. [online], 2012. Dostupné z: . [cit. 2013-05-04].

65

A Slovník pojmu˚ Text práce obsahuje pojmy, které nemusejí být obecnˇe známé, proto je pˇriložen struˇcný slovník tˇech nejduležitˇ ˚ ejších. Nˇekteré jsou cˇ ásteˇcnˇe cˇ i úplnˇe pˇrevzaty z [27]. V závorce je pˇrípadnˇe uvedena použitá zkratka. Archibus Systém pro podporu centralizované správy a údržby budov a jejich technologií. BACnet Komunikaˇcní protokol urˇcený k použití v systémech automatizace budov (zkratka pochází z anglického Building Automation and Control networks). Je standardizován organizacemi ASHRAE, ANSI a ISO. Building Management System (BMS) Komplexní systém pro rˇ ízení provozu technologií v budovách, cˇ esky systém pro správu budov, pˇrípadnˇe rˇ ízení systému˚ budov. Data Mart (DM) Úložištˇe specializovaných dat, zamˇerˇ ené na konkrétní obˇ last. Casto odvozené z datového skladu. ˇ Data Warehouse (DW, DWH) Cesky datový sklad, viz EDW. ˇ Decision support system (DSS) Cesky systém pro podporu rozhodování, kterou zajišt’uje poskytováním relevantních dat. Jedná se o širší termín, souˇcástí muže ˚ být i datový sklad. Dimensional Fact_Model (DFM) Pˇredpis pro tvorbu konceptuálních modelu˚ data martu, ˚ vycházející z multidimenzionálního modelování. Enterprise Data Warehouse (EDW) Celostní datový sklad, zahrnující co nejvˇetší množství zdroju˚ dat (typicky z celé korporace, univerzity,. . . ). Jde o úložištˇe dat, které zachycuje jejich zmˇeny v cˇ ase a je uspoˇrádáno pro snadnou analýzu dat. Eventlog (EVL) Objekt BMS použitý pro archivaci událostí v systému. Extract Transform Load (ETL) Pˇrístup k pˇresunu dat mezi databází a datovým skladem, zahrnuje po rˇ adˇe získání dat, jejich pˇremˇenu a nahrání do cílového úložištˇe. Geodatabáze Rovnˇež prostorová databáze, obsahuje údaje popisující geografické vlastnosti obsažených záznamu˚ (tvar, polohu,. . . ). 66

A. S LOVNÍK POJM U˚ Historian Služba pro archivaci dat BMS, ukládá data do HistorianDB. HistorianDB Databáze archivních dat BMS, obsahuje mˇerˇ ení a události získané z technologické sítˇe. Informaˇcní systém Brnˇenské akademické poˇcítaˇcové sítˇe (IS BAPS) Slouží k evidenci prvku˚ sít’ové infrastruktury, jde o systém provozovaný Ústavem výpoˇcetní techniky MU. Kontroler Rovnˇež automat, PLC (programmable logic controller), zaˇrízení sloužící pro monitorování a ovládání systému˚ správy budov. Kontrolery jsou zapojeny v technologické sítí, po které spolu vzájemnˇe komunikují. PGReader Utilita pro zpracování zdrojového kódu rˇ ídících programu˚ zarˇ ízení v technologické síti. ˇ ezec identifikující prvky evidované ve stavebním Polohový kód (PK) Retˇ pasportu (místnost, podlaží, budova, lokalita). Spatial Database Engine (SDE) Software spoleˇcnosti ESRI sloužící ke správˇe geografických databází (propojuje grafickou a atributovou cˇ ást dat). SQL Server Integration Services (SSIS) Platforma pro práci z daty, zejména jejich extrakci a plnˇení datových skladu˚ (viz ETL). Základním prvek je tzv. SSIS balíˇcek. Stavební pasport (SP) Soubor grafických a atributových dat popisujících budovy vlastnˇené a užívané univerzitou. Jednotlivým prvkum ˚ je pˇriˇrazen polohový kód. Technologická sít’ (TeNe) Vyhrazená infrastruktura pro komunikaci prvku˚ rˇ ídícího systému (BMS). Technologický data mart (TDM) Úložištˇe obsahující archivní data BMS (získaná z databází HistorianDB), technologického pasportu a dalších zdroju. ˚ Je navrženo pro archivaci a prezentaci tˇechto dat. ˇ ezec identifikující prvky technologického pasportu Technologický kód (TK) Retˇ na základˇe jejich pˇríslušnosti do daného geografického umístˇení (s využitím polohového kódu stavebního pasportu) a zaˇrazení do hierarchie TP. 67

A. S LOVNÍK POJM U˚ ˇ Technologický pasport (TP) Cást pasportu zabývající se evidencí technologií v budovách – napˇr. vzduchotechnika, požární signalizace, osvˇetlení. Pro identifikaci zaˇrízení používá technologický kód. Trendlog (TL) Objekt BMS použitý pro sbˇer dat ze sítˇe, muže ˚ být archivován prostˇrednictvím služby Historian do HistorianDB.

68

B ER model HistorianDB a TP

Obrázek B.1: Spoleˇcný ER model HistorianDB a TP

69

C Ukázka rˇídícího programu

Obrázek C.1: Ukázka zdrojového kódu rˇ ídícího programu

70

D Ukázky struktury SSIS balíˇcku˚

Obrázek D.1: Ukázka Control Flow balíˇcku TDM_plneni.dtsx

Obrázek D.2: Ukázka Data Flow Naplnˇení Dim_Mereni_BMS

71

E Datová pˇríloha Souˇcástí práce je DVD, které obsahuje: •

rˇ ešení DWH.sln vytvoˇrené pomocí SQL Server Data Tools (ve formátu pro Visual Studio 2010), s projektem TDM, jehož souˇcástí jsou i všechny SSIS balíˇcky.

•

vybrané SQL skripty (ostatní jsou souˇcástí balíˇcku) ˚

•

zálohy databází StageDB a TDM pro simulaci plnˇení TDM

•

jednotlivé SSIS balíˇcky

•

komentáˇr a pokyny k provedení simulace

•

text práce v PDF

72

Datový sklad k technologiím budov

Recommend Documents