Možnosti nástrojů firmy Microsoft v oblasti Business Intelligence

Transkript

1 Mendelova univerzita v Brně Provozně ekonomická fakulta Možnosti nástrojů firmy Microsoft v oblasti Business Intelligence Diplomová práce Vedoucí práce: Ing. Jan Přichystal, Ph.D. Bc. Petr Procházka Brno 2013

2 Na tomto místě bych chtěl poděkovat vedoucímu práce Ing. Janu Přichystalovi, Ph.D., za cenné rady a čas věnovaný konzultacím a také Ing. Eriku Cahovi ze společnosti BI Experts, s. r. o., za odborné vedení práce a poskytnutí prostředků pro tvorbu práce. Dále bych rád poděkoval své rodině za podporu při psaní této práce.

3 Prohlašuji, že jsem diplomovou práci na téma Možnosti nástrojů firmy Microsoft v oblasti Business Intelligence vypracoval samostatně a použil jen pramenů, které cituji a uvádím v přiloženém seznamu literatury. Brno

4 4 Abstract PROCHÁZKA, P. Opportunities of Microsoft Business Intelligence tools. Diploma thesis. Brno: Mendel University in Brno, This diploma thesis is focused on exploring the opportunities and functions of Microsoft Business Intelligence. For this purpose, the tabular data model was created. The functionality is designed for the self-service access by Power View tool. Another part of the thesis is dedicated to analyse of Helios Green Information System. The possibilities of tabular solution are compared with multidimensional solution. The result of the thesis are required reports according to business layout. Keywords: Analysis Services, Power View, self-service, tabular modeling Abstrakt PROCHÁZKA, P. Možnosti nástrojů firmy Microsoft v oblasti Business Intelligence. Diplomová práce. Brno: Mendelova univerzita v Brně, Diplomová práce je zaměřena na prozkoumání možností a funkcí Microsoft v oblasti Business Intelligence. Za tímto účelem byl vytvořen tabulární datový model. Funkcionalita Microsoft Business Intelligence je navrhnuta k samoobslužnému přístupu prostřednictvím nástroje Power View. Další částí práce je analýza informačního systému Helios Green. Možnosti tabulárního řešení jsou srovnávány s multidimenzionálním řešením a výstupem práce jsou požadované reporty dle business zadání. Klíčová slova: Analysis Services, Power View, samoobsluha, tabulární modelování

5 OBSAH 5 Obsah 1 Úvod a cíl práce Úvod Cíl práce Materiál a metodika Současný stav Představení firmy Data Warehousing, Business Intelligence Data Management MS SQL Server MS Office PowerPivot Power View MS SharePoint Vývojový nástroj SSDT SQL Server Data Tools Shrnutí konfigurace pracovní stanice Základní pojmy Business Intelligence Vymezení základních pojmů Business Intelligence Pojem Business Intelligence Vývoj Business Intelligence Nástroje a aplikace Business Intelligence Produkční (zdrojové) systémy ETL Extraction, Transformation, Loading Datový sklad (Data WareHouse = DWH) Datové tržiště Principy budování datového skladu OLTP a OLAP Schémata hvězda a sněhová vločka Fakta Tabulky dimenzí a její stromová struktura OLAP kostka OLAP databáze Reporting BISM tabulární datový model BISM Business Intelligence Semantic Model BISM multidimenzionální vs. tabulární Datové zdroje Externí klient DAX xvelocity

6 OBSAH Změna stávajících principů Cesta k BISM Analýza Helios Green Pohled na jádro Provozní data vs. metadata Komponenty Helios Green Třída Pořadač Funkce Shrnutí Základní typy tříd Subjektová třída Dokladová třída Nonsubjektová třída Konfigurační třída Tabulární model Samoobslužný přístup Mód serveru Analysis Services Server pro SSAS Architektura Analysis Services Import dat do tabulárního modelu Import tabulky Tabulární model v SSDT Instance Analysis Serveru Aktivní a neaktivní relace Funkce CALCULATE Časová tabulka SWITCH Saldo importovaná část Saldo kalkulovaná část RELATED IF Země Útvar Organizace Další tabulky modelu Prezentační vrstva tabulárního modelu Připojení pro analýzu Budování hierarchií V PowerPivot

7 OBSAH V Power View KPI Key Peformance Indicator Další volby KPI Časová inteligence v DAX Tržby dle států Tržby dle místa Problém s geolokací Největší dlužníci RANKX Doklady po splatnosti Odběratelé, dodavatelé (průměrná doba splatnosti) Největší dodavatelé, odběratelé Zakázka Čištění reportů a nasazení na SharePoint Diskuze Existující řešení Srovnání s existujícími řešeními Tabulární modelování Pro tabulární modelování Proti tabulárnímu modelování Multidimenzionální modelování Pro multidimenzionální modelování Proti multidimenzionálnímu modelování Závěr 58 9 Reference Přílohy 61 A Business zadání 61 A.1 Tržby dle států A.2 Tržby dle místa A.3 Největší dlužníci A.4 Doklady po splatnosti A.5 Odběratelé průměrná doba splatnosti A.6 Největší dodavatelé A.7 Zakázka B Další funkce časové inteligence 68 B.1 Porovnávání paralelních období B.2 Sledování tržeb v čase B.3 Klouzavý průměr

8 1 ÚVOD A CÍL PRÁCE 8 1 Úvod a cíl práce 1.1 Úvod Podniky jsou v dnešní době nuceny sledovat velké množství dat. Většina podniků k tomuto účelu vlastní informační systém. Je důležité nejen tyto data sledovat, ale také je využít k získání informace, popřípadě znalosti. V této chvíli se nám nabízí řešení Business Intelligence (BI). Přestože pro něj neexistuje jednoznačný a přesný český ekvivalent, jako nejbližší se jeví termín obchodní inteligence pro podporu rozhodování. Business Intelligence dnes nevyužívají jenom velké organizace, ale čím dál častěji se s ní setkáváme u středních nebo malých podniků, které začaly chápat důležitost získání konkurenční výhody oproti těm podnikům, které řešení Business Intelligence z různých důvodů nevyužívají a připravují se tak o možnost efektivněji řídit organizaci. Business Intelligence má za úkol podporovat analytické a rozhodovací činnosti v podnicích. Obecně se dá vyjádřit jako proces nebo soubor prostředků, materiálních zdrojů a odborných znalostí na podporu procesů a podnikatelských aktivit. Za účelem podpory podnikatelských aktivit pak provádíme sběr, integraci, analýzu a interpretaci obchodních informací. Hlavní výhodou Business Intelligence je, že poskytuje každému vedoucímu pracovníkovi stejnou informaci, což umožňuje rychlé nalezení chyby nebo hledání odchylky od strategie. V návaznosti také předvídáme události spojené s podnikem. Mnou vybrané téma spadá do oblasti informatiky a řízení podniku. Bylo zvoleno především z důvodu jeho aktuálnosti, protože společnost Microsoft jako nastupující technologii nabízí vývoj tzv. samoobslužného BI řešení prostřednictvím tabulárního (tabulkového) modelu. Kritickým bodem řešení Business Intelligence je tvorba datového skladu. Jak říká Pavel Procházka, proces extrakce, transformace, čištění a načítání dat je časově a finančně nákladný. Odhaduje se, že tvoří až 70 % nákladů na tvorbu datového skladu. Datová pumpa totiž musí zajistit čtení dat z různorodých datových zdrojů, jejich konzolidaci, čištění, korektnost, konzistenci a transformaci. (Procházka, 2013) Představa je taková, že bude přistupováno přímo k produkční databázi, nad kterou bude vytvořen tabulární model. Tento přístup by měl ušetřit čas při vývoji požadovaného řešení v porovnání s klasickým přístupem v podobě budování datového skladu a vytvoření multidimenzionálního řešení. Dalším důvodem vzniku samoobslužného řešení je tedy úspora času. Můžeme tedy mluvit o jakémsi rychlém vývoji požadovaného Business Intelligence řešení a zjištění možností nebo omezení, která nabízí. Tabulární model by měl být intuitivnější než dosud preferovaný multidimenzionální model a staví na platformě firmy Microsoft, kterou mnoho podniků již vlastní. Hovoříme o nástroji Microsoft Excel 2013, který většina uživatelů dobře zná. Jeho rozšíření, PowerPivot, zvládne zpracovat velké objemy dat a nástroj Power View slouží pro interaktivní zkoumání dat a tvorbu vizualizací a prezentací. To by mohlo

9 1 ÚVOD A CÍL PRÁCE 9 znamenat dostupnost Business Intelligence pro všechny, bez ohledu na stupeň dovednosti. Do tabulárního modelu můžeme jednoduše sesbírat data z více zdrojů a vytvářet sestavy. Především vzniká velký prostor pro nápady, které by jinak asi neměly naději na úspěch. Abychom po týdnu práce s vytvořením a naplněním datového skladu například zjistili, že určitá korelace, například mezi počasím a prodejem bot, neexistuje, celý proces budování datového skladu by přišel vniveč. Z výše popsaného příkladu by mohla být pro určitou skupinu zákazníků zajímavá tvorba samoobslužného řešení Business Intelligence bez nutnosti vytvářet datový sklad. 1.2 Cíl práce Hlavním cílem práce je zhodnotit možnosti nástrojů firmy Microsoft v oblasti Business Intelligence. Pro tyto účely bude aplikován tabulární model jako přístup k modelování analytické databáze. Na základě tohoto modelu pak sestaveny požadované reporty, na které bude všem uživatelům poskytnut samoobslužný přístup k funkcím Business Intelligence. Umožní jim tak vytváření samoobslužných analýz. Dílčím cílem je zhodnotit možnosti platformy samoobslužného BI řešení v prostředí Microsoft pro malou až střední firmu z hlediska časové náročnosti projektu a obtížnosti implementace. Práce by měla dále odpovědět na otázku, jaká je schopnost samoobslužného modelu vypořádat s časovými kalkulacemi, porovnáváním paralelních období, rekurzivními hierarchiemi a škálovatelností řešení. Vlastní implementace je cíleně zaměřena na aktuální platformu Microsoftu SQL Server 2012, Office 2013 a SharePoint 2013.

10 2 MATERIÁL A METODIKA 10 2 Materiál a metodika Diplomová práce nabízí vhled do tabulárního modelování Business Intelligence. Nejprve jsou představeny základní pojmy Business Intelligence a vysvětlení pojmu Business Intelligence Semantic Model. Dále je potřeba vymezit postup vlastní práce. Ta začíná analýzou ERP 1 HELIOS Green. Vzhledem k rozhodnutí, že nebude přikročeno k budování datového skladu, pokračujeme návrhem tabulárního datového modelu v programovém nástroji SSDT 2, tedy importem tabulek a vytvořením funkcí Busines Intelligence. Zbývá provést implementaci BI řešení v prostředí Microsoft pomocí samoobslužného nástroje Power View, u které zkoumáme vlastnosti a možnosti navrženého řešení. Náplní práce je také zhodnocení tabulární modelování z hlediska času, obtížnosti implementace a schopností modelu časovými kalkulacemi (porovnávání paralelních období), dynamickými hierarchiemi (rekurzivními hierarchiemi) a konečně škálovatelností řešení. Poslední část se věnuje sledování splnění cíle, diskuzi a vyhodnocení splnění cíle. 2.1 Současný stav V současné době existují dvě různé modelovací techniky BISM 3. BISM multidimenzionální, která je založena na klasické dimenzionální struktuře, tedy rozdělení tabulek na fakta a dimenze, používá při dotazování jazyk MDX 4 a modelování staví na datovém skladu. Tabulární modelovací technika strukturu na dimenze a fakta v podstatě stírá. Je založena na tabulkách, které mohou být zároveň fakty i dimenzemi. Používáme dotazovací jazyk DAX 5. Modelování ve většině případů staví na datovém skladu, ale v diplomové práci budou data pro tabulární projekt čerpána přímo ze zdrojové databáze. Tabulární modelovací technika bude použita k vytvoření samoobslužného Business Intelligence řešení prostřednictvím nástrojů firmy Microsoft. Vstupem je existující ERP HELIOS Green s BI nadstavbou implementovanou klasickými postupy a metodami. Business Intelligence nadstavba je zaměřena na část ekonomiky, tedy zpracování účetní osnovy, standardního výkaznictví a standardních finančních indikátorů. Výstupem bude řešení implementované pomocí samoobslužných BI nástrojů (SQL Server 2012, Office 2013, SharePoint 2013), které by mělo poskytovat stejné vlastnosti a schopnosti jako řešení existující, případně odpovědět na otázku, jaké jsou limity tohoto přístupu. 1 Enterprise Resource Planning 2 SQL Server Data Tools 3 Business Intelligence Semantic Model 4 MultiDimensional expressions 5 Data Analysis expressions

11 2 MATERIÁL A METODIKA Představení firmy Samoobslužné řešení Business Intelligence je zpracováno pro firmu BI Experts, s. r. o. Působí na trhu od roku 2008, aktuálně má 7 pracovníků. Realizovali projekty Business Intelligence například pro firmy Českomoravská záruční a rozvojová banka, Honeywell, Teplárny Brno, Gopas nebo Daquas Data Warehousing, Business Intelligence Analýza potřeb, uživatelských požadavků a firemních procesů, návrh struktur relačního datového skladu, implementace ETL procesů, konzolidace a čistění dat, integrace externích systémů a heterogenních zdrojů dat, návrh a tvorba OLAP databází a datových kostek, manažerské informační systémy, reportovací portály, dolování dat (segmentace, klasifikace, predikce). (BI Experts, 2013) Data Management Monitorování běhu a výkonu MS SQL Serveru, identifikace a odstranění úzkých hrdel systému, optimalizace výkonu OLTP a OLAP databází, SQL a MDX dotazů, správa a automatizace databází a databázových serverů, plánování a příprava přechodu stávajících systémů na vyšší verzi, upgrade. (BI Experts, 2013) MS SQL Server Je relační databázový systém vyvíjený firmou Microsoft. V diplomové práci jsou použita ostrá data kladenské společnosti Poldi, z pochopitelných důvodů budou především názvy organizací skryty. Pro vývoj je použit MS SQL Server 2012 Developer Edition, který je omezen licencí, která slouží pouze k vývoji a ladění systému. Vypsání verze SQL Serveru na pracovní stanici docílíme příkazem v MS Visual Studio: Select /@/@version MS Office 2013 K nasazení samoobslužného řešení je potřeba Office Professional Plus 2013, který nabízí kromě funkcí edice Professional také doplňky Excelu jako PowerPivot a Power

12 2 MATERIÁL A METODIKA 12 View a spolupráci se SharePointem. Na kancelářský balík je použita licence firmy BI Experts jakožto partnera Microsoftu PowerPivot Tento doplněk MS Excel, funguje na stejných principech jako známý Excel a v této práci byl využit pro testování hierarchií, měřítek a KPI Power View Nástroj integrovaný v MS Excel pro tvorbu interaktivní sestavy, kterou pak můžeme publikovat na serveru SharePoint Server, kde je mohou ostatní uživatelé zobrazit a být tak v interakci s podnikovými aktivitami MS SharePoint 2013 Hlavní idea této služby je možnost sdílení nápadů a znalostí, v návaznosti na to vytváření vlastních řešení pro konkrétní potřeby a vyhledávání správných podnikových informací, které přispívají k lepšímu rozhodování Vývojový nástroj SSDT SQL Server Data Tools Dříve BIDS (Business Intelligence Development Studio) nebo také Visual Studio, je vývojové prostředí od Microsoftu, které poskytuje jednotné prostředí i serverovou infrastrukturu a zjednodušuje tak celý vývoj aplikace. Všechny panely jsou samozřejmě přizpůsobovatelné uživateli, je možné přidávat a odebírat potřebné moduly. Samoobslužné BI řešení je konstruováno v Microsoft Visual Studio 2010 Shell, edici licencované pro firmu BI Experts. Pro testování a přístup do zdrojové databáze a do Service Analysis databáze byl používán také nástroj SQL Server Management Studio Shrnutí konfigurace pracovní stanice MS Windows 7 Enterprise, MS SQL Server 2012, MS Office Professional Plus 2013, MS Sharepoint 2013, MS Visual Studio 2010 Shell.

13 3 ZÁKLADNÍ POJMY BUSINESS INTELLIGENCE 13 3 Základní pojmy Business Intelligence 3.1 Vymezení základních pojmů Business Intelligence V této kapitole budou vymezeny některé základní pojmy Business Intelligence jako takové a rozebrány přístupy k její tvorbě její nástroje Pojem Business Intelligence Business Intelligence (BI) představuje komplex přístupů a aplikací IS/ICT, které téměř výlučně podporují analytické a plánovací činnosti podniků a organizací a jsou postaveny na principu multidimenzionality, kterým zde rozumíme možnost pohlížet na realitu z několika možných úhlů. (Novotný O., Pour J., Slánský D., 2005) S touto definicí lze souhlasit, například klasický multidimenzionální přístup k tvorbě business intelligence nabízí obvykle časovou, geografickou a produktovou dimenzi. Na obecnější rovině můžeme realitu vnímat z několika úhlů. Jako příklad si uvedeme tvorbu informačního systému jako takového. Můžeme se na problém dívat z pohledu dodavatele (kdo ho vyvine), uživatele (jaké funkce budu mít k dispozici), objednatele (kolik to bude stát). Důležité je, že žádný z těchto pohledů není více či méně důležitý, ale až správnou integrací neboli sloučením jednotlivých dimenzí získáme požadované řešení. Odtud tedy multidimenzionální přístup k řešení problému Vývoj Business Intelligence V dnešní době mají podnikoví manažeři důležitý úkol v rychlém rozhodování pod velkým časovým tlakem. K tomu ale potřebují správné a relevantní informace včas. Řešení směřující k podpoře manažerských a analytických úloh v podnikovém řízení se začala objevovat již na konci sedmdesátých let minulého století v souvislosti s rozvojem on-line zpracování dat. Prvotní pokusy a aplikace jsou spojeny s americkou firmou Lockheed. V druhé polovině osmdesátých let přišly na trh v USA první firmy s komerčními produkty, založenými na multidimenzionálním uložení a zpracování dat, označovanými jako EIS (Executive Information System), a to firmy Comshare a Pilot. Trh s EIS produkty se pak velmi rychle rozvíjel a na začátku devadesátých let (od roku 1993) se tyto produkty začaly prosazovat i na českém IS/ICT trhu. (Novotný O., Pour J., Slánský D., 2005) Nástroje a aplikace Business Intelligence Business Intelligence je založena na principu multidimenzionality, tedy nahlížení na skutečnost z několika úhlů a dá se vyjádřit jako podpora rozhodování. Do nástrojů a aplikací Business Intelligence můžeme zařadit: Produkční, zdrojové systémy, transformační nástroje (ETL),

14 3 ZÁKLADNÍ POJMY BUSINESS INTELLIGENCE 14 datové sklady (DWH Data Warehouses), datová tržiště (DMA Data Marts), OLAP, OLTP, reporting. (Novotný O., Pour J., Slánský D., 2005) Z uvedených nástrojů a aplikací je zřejmé, že kvalita Business Intelligence je nejvíce závislá na faktoru kvality produkčních a zdrojových systémů Produkční (zdrojové) systémy Produkční (zdrojové, primární, transakční, OLTP) systémy jsou systémy podniku, ze kterých aplikace Business Intelligence získávají data. Tyto systémy nejsou obvykle navrženy pro analytické úlohy. Příkladem může být IS Helios Green. (Novotný O., Pour J., Slánský D., 2005) ETL Extraction, Transformation, Loading ETL je často velmi důležitý a časově kritický komplex procesů celého projektu BI. Někdy se také nazývá datová pumpa. Úkolem procesů ETL je získat ze zdrojového systému data (fáze Extraction), upravit je do požadovaného formátu (Transformation) a nahrát do nastavených datových struktur (Loading). Proces ETL získal svoje místo s použitím aplikačních analytických systémů, kdy potřebujeme přenést data mezi dvojím databázovým prostředím. Pro potřeby samoobslužné analýzy a vytvoření tabulárního modelu ovšem budeme přistupovat přímo ke zdrojové OLTP databázi, tudíž fáze časově velmi náročná fáze ETL, odpadne. Otázkou zůstává možnost historizace dat. (Novotný O., Pour J., Slánský D., 2005) Datový sklad (Data WareHouse = DWH) Lze definovat mnoha způsoby. Definice jednoho ze zakladatelů Data Warehousingu, Billa Inmona, říká: Datový sklad (Data Warehouse) je integrovaný, subjektově orientovaný, stálý a časově rozlišený souhrn dat, uspořádaný pro podporu potřeb managementu. Pojmy integrovaný, subjektově orientovaný, stálý a časově rozlišený lze interpretovat: Subjektově orientovaný data jsou rozdělována podle jejich typu, ne podle aplikací, ve kterých vznikla. Jde tedy o případ, kdy jsou data o zaměstnanci uložena pouze jednou, a to v jedné databázi datového skladu, kdežto v produkčním systému bývají rozptýlena do různých souborů podle toho, pro kterou aplikaci mají být použita. Integrovaný data jsou ukládána v rámci celého podniku, a ne pouze v rámci jednotlivých oddělení.

15 3 ZÁKLADNÍ POJMY BUSINESS INTELLIGENCE 15 Stálý datové sklady jsou koncipovány jako Read Only, což znamená, že zde žádná data nevznikají ručním pořízením a nelze je ani žádnými uživatelskými nástroji měnit. Data jsou do DWH načítána z operativních databází či jiných externích zdrojů a existují zde po celou dobu života datového skladu. Časově rozlišený aby bylo možné provádět analýzy za určitá období, je nutné, aby byla do DWH uložena i historie dat. Načítaná data sebou tedy musí nést i informaci o dimenzi času. (Novotný O., Pour J., Slánský D., 2005) Datové tržiště Rozdíl mezi datovým tržištěm a datovým skladem je v tom, že datové tržiště poskytuje informace pouze určitým skupinám (oddělením), je využit princip decentralizace, kdy datový sklad vzniká integrací více datových tržišť. (Novotný O., Pour J., Slánský D., 2005) Principy budování datového skladu Existují dva rozdílné principy budování datového skladu. 1. Podle Ralpha Kimballa Datový sklad není nic jiného než sjednocení datových tržišť, říká zakladatel dimenzionálního modelování Ralph Kimball. Namísto vytváření jednoho datového skladu tak postupně budujeme jednotlivá datová tržiště. Sjednocením těchto datových tržišť pak rozumíme datový sklad. (Novotný O., Pour J., Slánský D., 2005) 2. Podle Billa Inmona Tento přístup ukládá data z provozních systémů do centrálního datového skladu, který se tak stává centrem podnikové architektury pro podporu rozhodování. Nad tímto datovým skladem jsou pak budována datová tržiště, která slouží pro podporu rozhodovacích procesů jednotlivých oddělení firmy. Myšlenka byla vytvořit architekturu, která by minimalizovala redundantní data. (Novotný O., Pour J., Slánský D., 2005) OLTP a OLAP Informační systémy pracují se dvěma typy informací, operativními (OLTP) a analytickými (OLAP). 1. OLTP (Online Transaction Processing) Transakční databáze, jejímž primárním účelem je vykonávání velkého množství on-line bankovních nebo obchodních transakcí. Výsledkem dotazování jsou databázové tabulky a souhry získané pomocí agregačních funkcí. OLTP databáze jsou z důvodu jednoduchého dotazování a vyloučení redundance zpravidla normalizované. Takovéto systémy dosahují vysoké výkony spíše při on-line transakcích než při složitých analýzách, které jsou velmi náročné na výpočtovou kapacitu. (Lacko, 2006) Takovým transakčním systémem je i HELIOS Green, který pokryje většinu podnikových

16 3 ZÁKLADNÍ POJMY BUSINESS INTELLIGENCE 16 aktivit a můžeme ho tak nazvat ERP (Enterprise Resource Planning). Aplikace Business Intelligence z něj čerpá data. 2. OLAP (Online Analytical Processing) Zahrnuje struktury údajů a analytické služby, které slouží pro analýzu velkého množství údajů. Multidimenzionální OLAP databáze obsahuje fakta vztáhnutá k jednotlivým dimenzím. Tabulky faktů a dimenzí mohou vytvářet schémata, jako například hvězdicovou (star schéma) nebo sněhové vločky (snowflake schéma). Na obrázcích 1 a 2 vidíme schémata hvězdy a sněhové vločky. (Lacko, 2006) Jak vidíme z obrázku 1 hvězdicového schématu, pohled na faktovou tabulku je tvořen jednotlivými dimenzemi. Star schéma poskytuje vysoký dotazovací výkon Schémata hvězda a sněhová vločka Obrázek 1: Schéma hvězda (Prashanth, 2012) Na obrázku 2, schématu sněhové vločky, se dimenze zanořují dále. Dotazovací výkon je pak horší. Obrázek 2: Schéma sněhová vločka (Prashanth, 2012) Fakta Fakta jsou numerické měrné jednotky obchodování. Tabulka faktů zpravidla obsahuje velký objem dat. Příklad faktové tabulky objem nákladů, výnosů, marže

17 3 ZÁKLADNÍ POJMY BUSINESS INTELLIGENCE 17 atd. Dimenze obsahují logicky anebo organizačně hierarchicky uspořádané údaje. Nejčastěji se setkáme s dimenzí časovou, produktovou, geografickou. (Lacko, 2006) Tabulky dimenzí a její stromová struktura Produktová: Kategorie Subkategorie Název. Geografická: Stát Region Město. Časová: Rok Kvartál Měsíc Týden OLAP kostka OLAP kostka je vlastně ekvivalent tabulky v relační databázi. Každá kostka má několik dimenzí. Jednotlivé záznamy se v OLAP kostkách nachází na průsečnících jednotlivých dimenzií. Nejlépe si dokážeme představit trojrozměrnou kostku tak, jak je na obrázku 3, nicméně počet dimenzí bývá zpravidla větší. (Lacko, 2006) Obrázek 3: Dimenze kostka (P.V.A. Systems, 2010) OLAP databáze OLAP databáze představují jednu nebo několik souvisejících OLAP kostek. Ty většinou, na rozdíl od datových skladů, již zahrnují předzpracované agregace dat podle definovaných hierarchických struktur dimenzí a jejich kombinací. Technologie OLAP se prakticky realizuje v několika variantách: 1. MOLAP (Multidimensional OLAP) je speciální uložení dat v multidimenzionálních databázích, data jsou v určeném časovém intervalu aktualizována.

18 3 ZÁKLADNÍ POJMY BUSINESS INTELLIGENCE ROLAP (Relational OLAP) řeší multidimenzionalitu uložením dat v relační databázi. 3. HOLAP (Hybrid OLAP) je kombinací předchozích přístupů, kdy detailní data jsou uložena v relační databázi a agregované hodnoty jsou uloženy v multidimenzionálních OLAP kostkách. (Lacko, 2006) Reporting Reportingem rozumíme dotazování se do databází pomocí standardních rozhraní těchto databází (např. SQL dotaz v rámci relačních databází). Reporting lze rozdělit na standardní reporting, kde se v určitých časových periodách spouštějí předpřipravené dotazy a ad hoc reporting, kdy jsou na databáze jednorázově formulovány specifické dotazy, které jsou explicitně vytvořené uživatelem. (Novotný O., Pour J., Slánský D., 2005) 3.2 BISM tabulární datový model Následující část se bude snažit odpovědět na otázku, co je to BISM, DAX, xvelocity, co nás vede ke změně stávajících principů a jak se dostaneme k řešení Business Intelligence pomocí tabulárního modelu. V MS SQL Server 2012 můžeme tvořit v nástroji Power View reporty z tabulárního modelu, který vzniknem v programu SQL Server Data Tools, případně v PowerPivot BISM Business Intelligence Semantic Model BISM, to není jenom tabulární modelovací technika Analysis Services, ačkoliv termín BISM je tak často používán. Analysis Services se skládají ze dvou částí. Multidimenzionální modelovací technika, která nabízí služby analýzy z datových kostek tak, jak jsou přístupné v SQL Serveru 2008 R2 a dřívějších verzích SQL Serveru s Analysis Services. Nová modelovací technika tabulární, v níž jsou služby analýzy založeny na tabulkách a jejich relacích. Využívá služby xvelocity, která je založena na paměti a principu sloupcové databáze. BISM nabízí k řešení Business Intelligence obě modelovací techniky. Rozdělení je zřejmé z obrázku 4. (Webb, 2012) Od SQL Serveru 2008 R2 je k dispozici nová technologie pro osobní a týmové BI řešení, PowerPivot, která se stala základem pro pozdější tabulární modelovací techniku v BISM. (Lachev, 2012)

19 3 ZÁKLADNÍ POJMY BUSINESS INTELLIGENCE 19 Obrázek 4: BISM (TechEd North America, 2012) BISM multidimenzionální vs. tabulární BISM zobrazuje třístupňový model zahrnující: přístup k datům, logiky přístupu a vrstvy datového modelu. Jak již bylo řečeno, existují dvě modelovací techniky, které využívají rozdílných principů. Multidimenzionální technika k datům přistupuje na základě principu ROLAP nebo MOLAP, ve vrstvě logiky přístupu používá dotazovací jazyk MDX a staví multidimenzionální datový model. Tabulární technika k datům přistupuje prostřednictvím xvelocity sloupcové databáze, případně Direct Query. Na logické vrstvě využívá dotazovací jazyk DAX a tvoříme tabulární datový model.(russo, Ferrari, Webb, 2012) James Serra rozebírá faktory volby mezi multidimenzionálním a tabulárním datovým modelem: Když chcete používat DAX a Power View, přistupovat k více externím datovým zdrojům a mít k dispozici velký dotazovací výkon, zvolte tabulární. Když potřebujete komplexní kalkulace a relace typu M:N, zvolte multidimenzionální. Doporučuje zvolit tabulární datový model, když je to možné. Uvádí pro to několik důvodů používá existující relační model a dotazovací jazyk DAX, který je podle Jamese Serry jednodušší než MDX, alespoň pro základy DAX, protože optimalizace dotazů DAX je složitější. Tabulární datový model také využívá službu založenou na paměti xvelocity. Je méně nákladný z hlediska času a zdrojů. Můžeme prostřednictvím kalkulovaného sloupce rozšířit datový model bez nutnosti přepracování celé databáze. (Serra, 2012)

20 3 ZÁKLADNÍ POJMY BUSINESS INTELLIGENCE 20 Tabulární datový model je založen na nově kalkulovaném sloupci, který přidáváme do modelu a dále jej používáme ve funkcích a měřítkách Datové zdroje Co se týče vrstvy datových zdrojů, multidimenzionální datový model nejlépe pracuje s jednou databází, datovým skladem. Naproti k tabulárnímu datovému modelu obvykle připojujeme heterogenní datové zdroje, jako databáze nebo textové soubory. (Lachev, 2012) Externí klient Používáme k dotazování se na multidimenzionální nebo tabulární modely. Prohlížeč OLAP, jako například Microsoft Excel, může vidět oba modely jako OLAP kostku. K dotazování na tabulární model slouží také klient Power View prostřednictvím DAX dotazů. (Lachev, 2012) DAX Jednoduše řečeno, DAX je dotazovací jazyk využívaný v BISM. Obsahuje kolekce funkcí, operátorů a konstant, které lze použít ve vzorci nebo výrazu k výpočtu a vrácení jedné nebo více hodnot. Lze také vytvořit nové informace z dat, která již jsou v modelu. (Microsoft, 2013) Pro představu, DAX je velmi blízký konceptu MS Excel xvelocity Tabelární model používá službu xvelocity (dříve nazýván VertiPaq), založenou na paměti. Ukládá pouze kopii dat na disk tak, aby nedošlo ke ztrátě dat v případě restartování služby. Multidimenzionální model, stejně jako většina relačních databázových strojů, ukládá data v řádcích, zatímco tabelární model používá sloupcově orientovanou a vysoce komprimovanou databázi s názvem xvelocity in-memory analytics, která ve většině případů nabízí významné zlepšení výkonu dotazování. (Russo, Ferrari, Webb, 2012) Jaký mód dotazování bude zvolen, lze zvolit v nástroji SSDT. (viz obrázek 5) Existuje také dotazovací mód DirectQuery, kdy je každý dotaz konvertován na SQL dotaz, který se dotazuje na zdrojovou databázi. DirectQuery DAX nepodporuje, proto v tabulárním modelu určitě zvolíme na rychlosti založený xvelocity (In-Memory) s podporou DAX.

21 3 ZÁKLADNÍ POJMY BUSINESS INTELLIGENCE 21 Obrázek 5: xvelocity Změna stávajících principů K odpovědi na to, co nás vede ke změně stávajících principů a proč vznikla nová modelovací technika, by měl navést následující text. Vyvstává z potřeby zaměstnanců po relevantních informacích a v návaznosti na to pomáhá lepšímu a strategičtějšímu rozhodování. Úkolem business inteligence je zpřístupňování správných informací správným lidem. Poskytnutí samoobslužného přístupu k funkcím business intelligence uživatelům a zaměstnancům umožňuje přistupovat k informacím, provádět jejich analýzu a využívat je při spolupráci a díky tomu přijímat nejlepší možná rozhodnutí. V neposlední řadě samoobslužný přístup k datům snižuje závislost uživatelů na oddělení IT, urychluje přístup k datům. Současně se umožňuje soustředit oddělení IT na projekty s vyšší hodnotou. Řešení Microsoft Business Intelligence self-service 6 umožňuje uživatelům využití samoobslužné analýzy, vytváření sestav a přizpůsobených řídicích panelů. Například zaměstnanci určitého podniku mohou využívat nástroje Business Intelligence k vyhodnocení informací, které jim pomáhají odhalit příležitosti pro prodej souvisejících produktů. Vedoucí oddělení prodeje mohou získávat přehled o prodejním kanálu a mohou stanovit priority pro práci se zaměřením na nejziskovější zákazníky. Díky samoobslužnému přístupu k informacím shromážděným v reálném čase mohou zaměstnanci rychle zanalyzovat, co se daný den ve firmě děje a přijmout rozhodnutí založená na informacích, které jsou aktuální, což napomáhá efektivnímu řízení společnosti. (Microsoft, 2013) 6 samoobslužné

22 3 ZÁKLADNÍ POJMY BUSINESS INTELLIGENCE Cesta k BISM Business Intelligence bychom měli podle Teo Lacheva rozdělit do tří skupin, dle obrázku 6: 1. Osobní BI PowerPivot for Excel - BI řešení vytvořené uživatelem, dostupné pouze pro uživatele, stačí nástroj PowerPivot. 2. Týmové BI PowerPivot For SharePoint - BI řešení vytvořené pokročilým uživatelem, pro malé týmové projekty, uložen na serveru, dostupné týmu přes SharePointnástroj PowerPivot for SharePoint. 3. BI Organizace vytvořeno IT odborníkem, od SQL Serveru 2012, tabulární technika Analysis Services, reporting pomocí Power View, nasazení na Share- Point. (Lachev, 2012) Obrázek 6: Rozdělení BISM (Lachev, 2012) Rozdíl mezi PowerPivot pro Excel a PowerPivot pro SharePoint je ve skutečnosti, že PowerPivot pro Excel, jakožto volný doplněk pro MS Excel 2010, obsahuje Vertipaq a SSAS běží jako proces Excelu, zatímco PowerPivot pro SharePoint běží Vertipaq na straně serveru. (Lachev, 2012)

23 4 ANALÝZA HELIOS GREEN 23 4 Analýza Helios Green HELIOS Green je komplexní ERP systém pro velké a střední společnosti. (Helios, 2013) Tato kapitola rozebírá pohled na jádro systému a jednotlivé komponenty HE- LIOS Green. 4.1 Pohled na jádro Bez ohledu na verzi má HELIOS jako informační systém společné jádro, jednotlivé edice se liší robustností řešení. Pro optimalizaci a efektivní přístup k datům HELIOS Green využívá dvou možností na způsob uložení dat. První možností je uložení společných vlastností pro všechny třídy v jediném místě. Požadavky na tyto společné vlastnosti se pak dají jednoduše plnit. Druhou možností optimalizace uložení se týká vztahů. Poměrně jednoduše pak dosáhneme toho, že vztahy mohou být definovány a případně měněny bez nutného zásahu do programového vybavení. Vlastníkem všech tabulek a uložených procedur v databázi HELIOS Green je zvláštní databázový uživatel LCS (role dbowner). Pouze při přihlášení s tímto jménem je možné tabulky a uložené procedury vytvářet. Při přístupu k nim musíme použít prefix LCS před jejich jménem. (Helios, 2012) Všechny subjektové a dokladové třídy mají některé atributy společné. Ty jsou uloženy ve zvláštní tabulce subjekty. Jedná se zejména o tyto atributy: cislo_subjektu Primární klíč tabulky subjekty, tedy jednoznačné číslo v rámci celé tabulky subjektů, které generuje SQL server sám. Každý záznam libovolné třídy je tak jednoznačně identifikovatelný. reference_subjektu Slouží pro uživatelskou číselnou nebo abecedně číslicovou identifikaci záznamu. Tento atribut uživatelé vidí, případně ho mohou zadávat či měnit. Například u faktury vydané zde bude uváděno pořadové číslo faktury, u organizace pak identifikační číslo organizace. cislo_poradace Odkaz do Pořadače v modulu Správa programu, kde jsou uloženy definice pořadačů. priznak_metatridy U záznamů HELIOS Green vždy I nebo NULL. datum_vzniku Datum vzniku záznamu. created_by Vztah na uživatele, který vztah založil. last_update Datum poslední změny na záznamu. pachatel Vztah na uživatele, který záznam naposledy měnil. období HELIOS Green obsahuje podporu zařazení záznamů do let. Záznamy mohou být platné vždy v jednom nebo více období. Toto rozdělení se nastavuje pro celou třídu v pořadači Třídy.

24 4 ANALÝZA HELIOS GREEN 24 timestamp Systémový čas poslední změny záznamu, používá se při replikaci dat. (Helios, 2012) Subjektové třídy mají atributy, které jsou pro ně specifické, uloženy v tabulce hlaviček. Totéž platí pro hlavičky dokladových tříd. Tabulka hlaviček má jako první atribut číslo subjektu, který je také primárním klíčem tabulky a odkazuje na příslušný řádek v tabulce subjekty. 4.2 Provozní data vs. metadata V databázi HELIOS Green jsou uloženy dva typy informací, provozní informace a informace o provozních informacích, čili metadata. Provozními informacemi jsou například jednotlivé faktury došlé. Kromě toho je v databázi i podrobná informace o tom, jak jsou faktury došlé do databáze uloženy, kteří uživatelé si je smějí prohlížet a kteří smějí měnit záznamy o nich. Dále kdo smí pouštět jaké funkce a je zde uvedeno, jaké mají atributy, vztahy, jaké jsou nad nimi definovány funkce a podobně. Na obrázku 7 vidíme hranici mezi provozními daty a metadaty v databázi HELIOS Green. Obrázek 7: Databáze HELIOS Green, (Helios, 2011) 4.3 Komponenty Helios Green Mezi komponenty informačního systému Helios Green patří Třída, pořadač a funkce.

25 4 ANALÝZA HELIOS GREEN Třída Základní komponentou je třída, ta představuje úložiště pro informace určitého typu (například třída Faktura došlá nebo Organizace). Podle toho, o jaké informace jde, má každá třída definovány vlastnosti. Informaci o jedné konkrétní instanci z dané třídy (např. o jedné konkrétní faktuře došlé, resp. o jedné konkrétní organizaci) říkáme záznam, ten se samozřejmě skládá z více atributů. Pokud k záznamu z jedné třídy patří záznam z jiné třídy (např. jednu konkrétní fakturu došlou vystavila jedna konkrétní organizace), víme, že záznamy mají mezi sebou určitý vztah. Každý vztah má svou definici, která určuje, jaké třídy mezi sebou vztah mají. Jeden konkrétní záznam se tedy skládá z údajů v jednotlivých atributech a z odkazů na jiné záznamy čili vztahů. Musíme také rozlišovat pojmy záznam HELIOS Green a záznam jako řádek tabulky. V některých jiných systémech se pojem záznam používá pro právě jeden řádek v jedné tabulce. V HELIOS Green se jím však rozumí uložení informací o jedné konkrétní instanci z nějaké třídy. Uložení těchto informací potom může být ve více tabulkách. (Helios, 2011) Pořadač Se záznamy jedné třídy obvykle pracuje více uživatelů. Různí uživatelé mohou mít přístup pouze k některým záznamům. Například jeden fakturant zpracovává faktury došlé tuzemské a jiný faktury došlé zahraniční. Každý nese odpovědnost za ty své a nechce, aby druhý fakturant mohl měnit jeho data. Proto jsou pro každou třídu definovány tzv. pořadače a každý záznam z jedné třídy patří právě do jednoho pořadače. V uvedeném příkladu by např. na třídě Faktury došlé vznikly dva pořadače Faktury došlé tuzemské a Faktury došlé zahraniční. Všechny pořadače od jedné třídy mají stejné atributy a vztahy, využívají stejná okna pro zobrazení informací, ale liší se v možnosti přístupu jednotlivých uživatelů k těmto datům (tzv. přístupovými právy). Každý pořadač má svou definici, která určuje jeho vlastnosti. Jeden konkrétní záznam se tedy skládá z údajů v jednotlivých atributech a z odkazů na jiné záznamy čili vztahů, a patří právě do jedné třídy a v rámci ní právě do jednoho pořadače. (Helios, 2011) Funkce Když se záznamy vybrané třídy mění určitým definovaným způsobem, realizuje tuto změnu funkce - vytváří, mění či maže záznamy. Jako hlavní podklad pro práci funkce slouží záznamy třídy, ke které funkce patří. Například funkce Zaúčtování faktury vydané. Každá funkce má svou definici, která určuje, jak funkce probíhá, zda se před jejím spuštěním objeví kontrolní dotaz na spuštění, jak jsou uživateli oznámeny chyby, pokud se v průběhu funkce vyskytnou. (Helios, 2011)

26 4 ANALÝZA HELIOS GREEN 26 Obrázek 8: Pořadače, (Helios, 2011) Shrnutí Základní komponentou HELIOS Green je třída, pro každou třídu jsou definovány její atributy, pořadače a funkce, v každé existují záznamy a mezi třídami jsou navázány vztahy. Popis tříd, pořadačů, funkcí, vztahů a atributů se nachází ve stejné databázi jako provozní data, jde tedy o metadata. (Helios, 2011)

27 4 ANALÝZA HELIOS GREEN Základní typy tříd Na obrázku 9 vidíme schéma základních typů tříd v HELIOS Green. Obrázek 9: Základní typy tříd Subjektová třída Atributy třídy jsou pouze základního typu (číslo, řetězec, pravdivostní hodnota). Na třídu je možné se odkazovat z jiných tříd. Mezi příklady patří následující číselníky: Organizace, Útvary, Zaměstnanci. (Helios, 2011) Dokladová třída Třída je rozdělena na dvě části. Základní část (tzv. hlavička třídy) i pole (tzv. položky třídy) pak obsahují atributy pouze základního typu (číslo, řetězec, pravdivostní hodnota). Hlavičky a položky jsou implementovány dvěma tabulkami. Na třídu je možné se odkazovat z jiných tříd.

28 4 ANALÝZA HELIOS GREEN 28 Jako příklad lze uvést následující doklady: Faktura vydaná, Faktura došlá, Účetní doklad. (Helios, 2011) Nonsubjektová třída Jedná se většinou o tzv. slabou entitu (záznamy musejí být vždy povinně svázány se záznamy jiné třídy) nebo se jedná o způsob implementace atributů vztahu (například vztah Likvidoval fakturu mezi fakturou a zaměstnancem bude mít jako atribut datum likvidace). (Helios, 2011) Konfigurační třída Její záznamy slouží jako konfigurace pořadačů jiné třídy. (Helios, 2011)

29 5 TABULÁRNÍ MODEL 29 5 Tabulární model V této kapitole po důkladné analýze zdrojové databáze následuje postup importu tabulek do tabulárního modelu a problémy, které mohou být v procesu importu řešeny. Dále jsou zde zobrazeny funkce, které byly použity pro potřeby samoobslužného přístupu k Business Intelligence. 5.1 Samoobslužný přístup Nástroje samoobslužného přístupu mají za cíl poskytnout pokročilým uživatelům možnost vytvářet řešení BI s malou nebo žádnou pomocí oddělení IT. Služba Analysis Services systému MS SQL Server poskytuje koncovým uživatelům možnost vytvářet vlastní dotazy a sestavy, ale stále je vyžadován odborník v oblasti IT pro potřebu návrhu Analysis Services databáze. Microsoft v roce 2010 vydal svůj vlastní samoobslužný nástroj PowerPivot, volně stažitelný doplněk MS Excel, kde mohou uživatelé importovat data z několika zdrojů, budovat své vlastní modely a pak se dotazovat pomocí kontingenčních tabulek. Databáze PowerPivot běží v procesu uvnitř Excelu, jsou tam uložena všechna importovaná data, na která se dotazujeme z Excelu. Samoobslužný přístup nabízí výhody ve vytváření BI řešení z hlediska rychlosti vývoje, avšak jsou s tím spojeny problémy jako špatná kvalita vstupních dat nebo historizace údajů. 5.2 Mód serveru Analysis Services Bylo potřeba nainstalovat na Analysis Services instanci pro tabulární mód. 0 multidimenzionální 1 SharePoint 2 tabulární Na kartě Object Explorer má tabulární instance Analysis Serveru odlišnou ikonu. (viz obrázek 10) Obrázek 10: Mód serveru AS

30 5 TABULÁRNÍ MODEL Server pro SSAS Z toho důvodu, že výpočty probíhají v paměti, je velmi důležitá velikost RAM, rychlost sítě a jádra, zatímco na rychlosti disku nezáleží, pro tyto účely byl zřízen virtuální server. 5.4 Architektura Analysis Services V MS SQL Serveru 2012 je architektura Analysis Services rozdělena na dva modely. První z nich je klasický multidimenzionální model, ten má několik vylepšení týkajících se výkonu a škálovatelnosti, ale není zde žádná nová funkce. Druhý, tabulární model, je novinkou a právě jemu se práce věnuje. Při instalaci Analysis Services na SQL Server musíme vybrat v procesu instalace právě instanci, která se spouští v tabelárním režimu. 5.5 Import dat do tabulárního modelu Do tabulárního modelu můžeme importovat data z jednoho či více datových zdrojů a následně je v tabulární databázi Analysis Services, případně pracovní databázi (workspace database), použít pro tvorbu analýz a sestav. Je také vhodné použít workspace server stejný jako Analysis Services server. Existuje více možností načtení dat, které je nutno rozebrat a posléze vybrat vyhovující řešení pro tento model. Analysis Services nabízí několik podporovaných datových zdrojů, které můžeme vidět na obrázku Relační databáze Analysis Services může načíst prostřednictvím tabulek, pohledů a dotazů data uložená v relačních databázích jako MS SQL Server, Oracle, Sybase, MS Access. 2. Multidimenzionální zdroj do tabulárního modelu můžeme importovat multidimenzionální model z Analysis Services jako datového zdroje. 3. Data Feeds z dynamických datových zdrojů jako Open Data Protocol (OData). 4. Textové soubory textové (oddělené čárkou), Excel. 5. Další kopírování ze schránky.

31 5 TABULÁRNÍ MODEL 31 Obrázek 11: Import dat Import tabulky Pro import tedy vybereme požadovaný datový zdroj, například relační databázi Microsoft SQL Server a pokračujeme přihlášením na poskytnutý server. Po autentizaci pokračujeme výběrovým oknem, jak importovat data. Na výběr jsou dvě možnosti, první z nich umožňuje k importu vybrat jednu a více tabulek, druhá nabízí napsání dotazu na zdrojovou databázi. Z poskytnuté databáze na databázovém serveru byly selektovány tabulky pro vytvoření tabulárního datového modelu. Jako příklad je na obrázku 12, tabulka saldo, která sleduje přijaté a vydané faktury. V této fázi můžeme změnit název tabulky pro tabulární model. Přejmenování tabulky lze provést i později přímo v nástroji SSDT. Ze zdrojové databáze vybíráme a filtrujeme kromě tabulek také požadované sloupce. (obrázek 13) Musíme vědět, co chceme importovat a také nastudovat, jakou informací poskytují výčtové typu v jednotlivých sloupcích. Do tabulárního datového modelu můžeme také importovat ze zdrojové databáze všechny provázané tabulky s importovanou tabulkou. Tuto volbu nedoporučuju, protože při robustní databázi se do tabulárního modelu načte mnoho tabulek, které do řešení nepotřebujeme.

32 5 TABULÁRNÍ MODEL 32 Obrázek 12: Import tabulky Takto byly postupně filtrovány a importovány všechny potřebné tabulky: cas, saldo, vydejka, druh_skladoveho_pohybu, organizace, utvar, sklad, zakazka, zeme, kmenova_karta_skladu, prijemka, varianta_zbozi. Import časové tabulky probíhal v podstatě stejně jako import ze zdrojové databáze SQL Serveru, s tím rozdílem, že jako datový zdroj byl pochopitelně vybrán Excel File. Může se stát, že bude zapomenuta určitá tabulka nutná pro vytvoření požadovaného modelu. V této situaci nemusíme vytvářet nové spojení tak, jak je popsáno výše. V hlavním menu SSDT je možné otevřít připojení, které chceme využívat. Následuje postup importu tabulky do modelu z tohoto aktivního připojení. Výsledkem tedy jsou dva datové zdroje a dvě připojení. Zdrojová data z SQL Serveru a časová tabulka vytvořená v MS Excel.

33 5 TABULÁRNÍ MODEL 33 Obrázek 13: Filtrování atributů 5.6 Tabulární model v SSDT V pravém dolním rohu okna tabulární modelu můžeme přepnout dva režimy vývoje, na obrázku 14 je režim mřížky tabulka. V tomto režimu pracujeme se dvěma pracovními okny, oddělenými vodicí linkou. Jedna z nich zobrazuje náhled zdrojové tabulky, kde kalkulujeme nové sloupce a druhá část je pro zápis měřítek. Dalším režimem je zobrazení diagramu, kde se nachází zobrazení vztahů mezi tabulkami tak, jak jej vidíme na obrázku 15. Obrázek 14: Okno SSTD mřížka

34 5 TABULÁRNÍ MODEL 34 Obrázek 15: Okno SSTD diagram 5.7 Instance Analysis Serveru Databáze na instanci Analysis Serveru jsou dvě. První z nich, databáze PoldiTabular2, vznikne okamžikem nasazení na Analysis Server, tedy provedením Deploy 7. OLAP kostka, uvedená na obrázku 3, vzniká v paměti, není tedy vytvořena fyzicky jako u multidimenzionálního modelování. Druhá databáze, (např. PoldiTabular2_pprochazka_1f98f c-485b-a06f-940b1a8f87de), je tzv. pracovní databáze. Tedy databáze, vytvořená pro potřeby tabulárního modelu, kde se změny promítnou ihned po uložení tabulárního modelu, aniž bychom provedli Deploy. Výborně pak slouží pro testování navrženého řešení. Ukázka je zobrazena v nástroji SQL Server Management Studio na obrázku 16. Časová tabulka byla vytvořena v Excelu za účelem budování časové hierarchie a importován podobným způsobem jako tabulky z SQL Serveru. Po importu potřebných tabulek můžeme v nástroji SQL Server Data Tools sledovat, jak importem tabulek vznikne model, jehož entity nejsou navzájem provázány. Je tedy potřeba vytvořit relace mezi jednotlivými tabulkami, respektive atributy v nich uložených. Tabulární model je schopen nativně zpracovávat pouze základní typ vztahu mezi tabulkami 1:N. To znamená jeden sloupec, který má klíč v cílové tabulce. Pokročilejší vztahy jako M:N je řešitelný pomocí složitějších výrazů DAX. 7 nasazení dané aplikace

35 5 TABULÁRNÍ MODEL 35 Obrázek 16: Připojení k SQL Serveru a SS Analysis Services 5.8 Aktivní a neaktivní relace V tabulárním modelu lze vytvářet vazby mezi jednotlivými tabulkami. Ovšem manuálně nelze označit jako aktivní více než jedna vazba. Řešením je pak funkce USE- RELATIONSHIP. Aktivní vznikne tažením mezi dvěma atributy ze zdrojové do cílové tabulky, nastavit lze pouze jedna aktivní vazba. Na následujícím obrázku je vztah atributu vyrovnano(datový typ datum) na F1(datový typ datum) znázorněn plnou čarou. Neaktivní pokud je vazba neaktivní, lze samozřejmě aktivovat klepnutím na vazbu, ale to nám v případě existence nějaké jiné aktivní vazby mezi danými tabulkami přepne tuto vazbu na neaktivní. Jak již bylo uvedeno, vyvstal problém s tím, kterou z vazeb v případě, že je jich více, necháme aktivní. Protože v reportech potřebujeme většinou sumu plateb dle vyrovnání, zjednodušíme si cestu tím, že vytvoříme neaktivní vazbu saldo(splatno) cas(f1). Jak ji pro správnou funkčnost a použitelnost v datovém modelu aktivujeme? V DAX je řešením právě funkce USERELATIONSHIP. 1 USERELATIONSHIP(<sloupec1>,<sloupec2>). Listing 1: Syntaxe USERELATIONSHIP

36 5 TABULÁRNÍ MODEL 36 Obrázek 17: Aktivní vs. neaktivní vazba Tato funkce, vytvořená ve vyhrazené části nástroje SSDT pro tvorbu měřítek, nám v průběhu výpočtu povolí určenou relaci. Tato relace musí existovat, v modelu bude znázorněna přerušovanou čárou a lze ji použít pouze ve funkcích, které přebírají jako argument filtr, například níže uvedené CALCULATE. Pro potřeby vytvoření reportu časové linie splatnosti vs. vyrovnání plateb bylo potřeba vytvořit měřítko suma_splatno, která pomocí funkce USERELATIONSHIP korektně přiřadí sumu faktur dle splatnosti do časové hierarchie. 1 suma_splatno:=calculate(sum([ fakturykc ]),USERELATIONSHIP(saldo [ splatno ], cas [F1])) Listing 2: Měřítko suma_splatno Funkce CALCULATE 1 CALCULATE(<vyraz>,<filtr >) Listing 3: Syntaxe CALCULATE 5.9 Časová tabulka Pro potřebu vytvoření časové hierarchie v časové tabulce (obrázek 18) v nástroji SSDT byly vytvořeny další 3 kalkulované sloupce pojmenované mesic3, mesic2 a mesic. mesic3 využita funkce SWITCH pro formátování hodnot ve sloupci z typu čísla na typ text, například z 1 na =switch(cas [F3],1, 01,2, 02,3, 03,4, 04,5, 05,6, 06,7, 07,8, 08,9, 09,10, 10,11, 11,12, 12 ) Listing 4: První SWITCH pro měsíc mesic2 pro zlepšení přehlednosti uživatelského rozhraní byl číselný údaj o pořadí měsíce v roce změněn na český název měsíce pomocí funkce SWITCH, například z 1 na Leden.

37 5 TABULÁRNÍ MODEL 37 Obrázek 18: Časová tabulka 1 =switch(cas [F3],1, Leden,2, Unor,3, Brezen,4, Duben,5, Kveten,6, Cerven, 2 7, Cervenec,8, Srpen,9, Zari,10, Rijen, 11, Listopad,12, Prosinec ) Listing 5: Druhý SWITCH pro měsíc Aby dobře časová hierarchie fungovala korektně, zřetězíme předchozí dva kalkulované sloupce, v jiném případě v nástroji MS Excel nesprávně řadila jednotlivé měsíce v hierarchii. 1 =[mesic3]\& \&[mesic2 ] Listing 6: Spojení předchozích SWITCH Výsledkem tohoto zřetězení je kalkulovaný sloupec mesic: 01 Leden, 02 Únor, 03 Březen, 04 Duben, 05 Květen, 06 Červen, 07 Červenec, 08 Srpen, 09 Září, 10 Říjen, 11 Listopad, 12 Prosinec. název popis datový typ F1 jednoznačný identifikátor (klíč) datum F2 den číslo F3 měsíc číslo F4 rok číslo Tabulka 1: Popis časové tabulky SWITCH 1 SWITCH(<vyraz>, <hodnota>, <vysledek>[, <hodnota>, <vysledek >][, <jinak>]) Listing 7: Syntaxe SWITCH Funkce SWITCH vyhodnotí výraz na základě seznamu hodnot a vrátí jeden z několika možných výsledných výrazů.

38 5 TABULÁRNÍ MODEL Saldo importovaná část Do tabulky saldo (obrázek 19) bylo importováno 9 atributů. Obrázek 19: Saldo importovaná část název popis datový typ cislo_subjektu jednoznačný identifikátor číslo organizace organizace (klíč) číslo typ Z=Závazek, P=Pohledávka, O=Ostatní text splatno datum splatnosti datum vyrovnano datum vyrovnání datum obchodni_pripad číslo zakázky (klíč) číslo fakturykc fakturováno měna(czk) platbykc rok měna (CZK) utvar útvar (klíč) číslo Tabulka 2: Saldo

39 5 TABULÁRNÍ MODEL Saldo kalkulovaná část Dále byly kalkulováno 8 nových sloupců (obrázek 20). Rozdil_FAvsPlatba, jako rozdíl mezi fakturou a platbou. Typ salda, kde pro uživatelskou přívětivost modelu bylo potřeba přepnout pomocí funkce switch plné názvy typu obratu (namísto Z Závazky, P Pohledávky a O Ostatní. Název organizace, název zakázky, číslo zakázky a název útvaru jakožto odkaz na názvy v příslušných tabulkách modelu. Dalším výpočtem byl kalkulovaný sloupec po_splatnosti, který zobrazuje počet dní mezi vyrovnáním platby a splatností faktury. Konečně kalkulovaný sloupec FA_po_splatnosti. Je-li rozdíl mezi datem splatnosti a datem vyrovnání kladný, znamená to, že faktura je po splatnosti, vypiš tedy číslo faktury. Není-li to pravda, vypiš číslo 0. Obrázek 20: Saldo kalkulovaná část 1 rozdil_favsplatba = [ fakturykc ] [ platbykc ] 2 typ salda = switch([typ], Z, Zavazky, P, Pohledavky, O, Ostatni, N, Nesledovat ) 3 název organizace = related(organizace [název subjektu ]) 4 po_splatnosti = [vyrovnano] [ splatno ] 5 název zakázky = related(zakazka[název subjektu ]) 6 FA_po_splatnosti = if ([ po_splatnosti]>0,[cislo_subjektu ],0) 7 cislo_zakazky = related(zakazka[ cislo_zakazky ]) 8 název utvaru =related(utvar [ cislo útvaru ]) Listing 8: Saldo kalkulované sloupce RELATED 1 RELATED(<sloupec>) Listing 9: Syntaxe RELATED Funkce RELATED vyžaduje, aby mezi aktuální tabulkou a tabulkou se souvisejícími informacemi existovala relace. Tedy mezi tabulkami saldo a organizace. Je potřeba určit sloupec obsahující požadovaná data. V našem případě název organizace v tabulce saldo, vepsat příkaz =related(organizace[název subjektu]) a funkce prostřednictvím existující relace M:1 načte hodnotu ze zadaného sloupce v související tabulce (v našem případě název subjektu v tabulce organizace).

40 5 TABULÁRNÍ MODEL IF 1 IF(<podminka>,pravda(),0) nebo IF(<podminka>, pravda(), nepravda()) Listing 10: Syntaxe IF Funkce IF (použita u atributu FA_po_splatnosti) zkontroluje, zda je splněna podmínka zadaná v podmínce. Pokud je podmínka splněna, výsledkem jejího vyhodnocení je hodnota PRAVDA, vrátí jednu hodnotu. Pokud podmínka splněna není, je výsledkem vyhodnocení hodnota NEPRAVDA a vrátí druhou hodnotu Země Obrázek 21: Země název popis datový typ cislo_subjektu jednoznačný identifikátor (klíč) číslo plny_nazev plný název země text celni_nazev celní název země text Tabulka 3: Popis země

41 5 TABULÁRNÍ MODEL Útvar Importován byl pouze jeden atribut, cislo_subjektu, jakožto klíč na název útvaru, jehož název bylo potřeba získat ze zdrojové databáze. Kalkulován byl potom jeden nový sloupec číslo útvaru, které bylo třeba pomocí funkce SWITCH přepsat na text. Obrázek 22: Útvar 1 =SWITCH([ cislo_subjektu ], , utvar reditele spolecnosti, , centralni udrzba, , utvar reditele pro jakost, , utvar reditele pro finance a nakup, , utvar reditele pro obchod, , divize Hridele sprava, , divize Hridele M3, , divize Hridele M2, , divize Valce a Nastroje sprava, , divize Valce a Nastroje kalirna, , divize Valce a Nastroje vyr. nastroje, , divize Valce a Nastroje vyr. valce ) Listing 11: Útvar SWITCH 5.14 Organizace Jak vidíme z obrázku 23, do datového modelu bylo v rámci tabulky organizace importováno 7 atributů, zbývající atribut názvu země byl pak kalkulován prostřednictvím funkce RELATED. název popis datový typ cislo_subjektu jednoznačný identifikátor (klíč) číslo reference_subjektu reference na subjekt číslo název organizace název organizace text ulice název ulice text misto název města text psc PSČ číslo zeme číslo země číslo Tabulka 4: Popis organizace

42 5 TABULÁRNÍ MODEL 42 Obrázek 23: Organizace 5.15 Další tabulky modelu Pro konstrukci datového modelu podle business zadání byly důležité všechny předchozí tabulky. Především saldo, na kterém sledujeme všechny pohyby faktur a zakázek. Ostatní tabulky (zakázka, sklad, typ kmenové karty, druh skladového pohybu, příjemka, výdejka, varianta zboží), jsou součástí modelu pro možnost jeho rozšíření.

43 6 PREZENTAČNÍ VRSTVA TABULÁRNÍHO MODELU 43 6 Prezentační vrstva tabulárního modelu V prezentační vrstvě tabulárního modelu jsou vytvořeny pomocí nástroje Power View interaktivní reporty z business zadání. Je řešena otázka časové inteligence, budování hierarchií a chování funkcí nebo KPI. 6.1 Připojení pro analýzu V modelu do PowerPivot a PowerView záložce Data v nástrojích PowerPivot a PowerView se můžeme připojit na Analysis Services databázi nebo také na workspace databázi modelu. Na workspace databázi pouze v případě, mámeli model otevřen v SSDT či jiném nástroji pro vytvoření a správu datového model, který je uložen právě na workspace databázi. 6.2 Budování hierarchií V PowerPivot Hierarchie byla vytvořena v nástroji SSDT. Jak vidíme na obrázku 24, v okně tabulky je maximalizační tlačítko a vlevo od něj tlačítko pro vytvoření hierarchie. Hierarchii pojmenujeme a kliknutím na levé tlačítko myši tažením na příslušnou úroveň tvoříme hierarchii. V tomto případě rok, měsíc a den (opět je možnost přejmenovat či vymazat). Předpoklad byl takový, že časová hierarchie bude podobně fungovat i v nástroji Power View, tam je ale nutno zvolit jiný přístup. Obrázek 24: Hierarchie v PowerPivot V Power View Když se připojíme na příslušný datový zdroj, ať už Analysis Services, nebo workspace database, vložíme do okna Power View časovou hierarchii, musíme se přepnout na kartě Design a zde vybrat Column Chart (sloupcový graf) Clustered Column (skupinový, sloupcový graf). V této chvíli se nám hierarchie rozpadne do polí, kde je

44 6 PREZENTAČNÍ VRSTVA TABULÁRNÍHO MODELU 44 nechceme. Musíme proto v pravé části pracovní plochy Power View, v okně Power View Fields, tažením vytvořit odshora dolů požadovanou hierarchii tak, jak vidíme na obrázku 25. Obrázek 25: Hierarchie v Power View V nástroji Power View vidíme na obrázku 26 sumu plateb za jednotlivé roky, vybráním konkrétního sloupce lze zanořit hierarchii na konkrétní měsíc a pak také na konkrétní dny. Report se v tuto chvíli interaktivně mění dle úrovně hierarchie. Obrázek 26: Ukázka hierarchie v Power View 6.3 KPI Key Peformance Indicator Český ekvivalent klíčový ukazatel výkonu. Porovnává mezi sebou dvě měřítka nebo také sleduje procento plnění cíle tak, jako v našem případě. Příklad procentuálního plnění cíle je na obrázku 27: narust_faktur:=([sum of fakturykc]/[fakturyisply]). Název měřítka, narust_faktur, sleduje procentuální porovnání sumy faktur (Sum of fakturykc) za určité období v Kč se stejným obdobím minulého roku (fakturyis- PLY) Další volby KPI KPI base measure (value) měřítko, které se KPI týká.

45 6 PREZENTAČNÍ VRSTVA TABULÁRNÍHO MODELU 45 Measure využili bychom v případě, kdybychom porovnávali dvě měřítka. Absolute value je popsáno na příkladě z obrázku 27. V tomto případě 1 = 100 %, tedy když bude aktuální fakturace v porovnání s fakturou z minulého roku do 80 %, zobrazí se červený status hodnocení klíčového ukazatele, pokud bude výsledek KPI %, zobrazí se žlutě. Když bude suma faktur aktuálního roku větší než 1, tedy suma faktur aktuálního roku překročí 100 %, zobrazí se ukazatel KPI zeleně. Select icon style možnost výběru z grafických návrhů ikon KPI. Obrázek 27: KPI 6.4 Časová inteligence v DAX Pro potřeby časové inteligence je nutno vytvořit časovou tabulku. Takových časových tabulek může být více, podle potřeby tabulárního modelu. Pro označení tabulky jako časové klikneme v hlavní nabídce SSDT na Table Date Mark as Date. Datum jako klíč máme obvykle ve více záznamech tabulky. Problém s nastavením aktivní vazby tak, jak ho vidíme na obrázku 17, můžeme řešit pomocí funkce USE- RELATIONSHIP. Existuje také alternativa a to vytvoření více časových tabulek a propojit každou tabulku s datumem se samostatnou časovou tabulku, vytvořenou jen pro účely vytvoření aktivní vazby.

46 6 PREZENTAČNÍ VRSTVA TABULÁRNÍHO MODELU 46 V tabulárním modelu se nabízí několik šikovných funkcí pro výpočet po časové linii. Z funkce 12 je zřejmé, že v SSDT lze pomocí měřítka napevno vypočítat, jaká byla suma plateb v určitém období, ale to je použitelné spíše při dotazování na tabulární databázi. Pro naše potřeby vytvoření interaktivního reportu v Power View je samozřejmě interaktivita nebo míra přizpůsobitelnosti uživateli na prvním místě. 1 obdobikc:=calculate(sum(saldo [ platbykc ]),DATESBETWEEN(saldo [ splatno ],DATE(2010,1,1),DATE(2010,1,2))) Listing 12: Útvar SWITCH

47 6 PREZENTAČNÍ VRSTVA TABULÁRNÍHO MODELU Tržby dle států Report má za úkol dle business zadání na obrázku 36 sledovat tržby za určená období roku s filtrací států. Obrázek 28: Tržby dle státu Při tvorbě tohoto reportu byla využita vytvořená časová i organizační hierarchie, které jsou navázány na hlavní tabulku saldo, s filtrem typu salda na pohledávky. V interaktivním nástroji Power View, na obrázku 28, vidíme konkrétně tržby ze státu Finsko za období srpen Období je řešeno v nástroji Power View objekty, tzv. průřezy 8, které nám umožňují interaktivní filtraci atributů. Do reportu byl taky přidán mapový podklad zobrazující tržby v jednotlivých státech. V reportu je možné filtrovat tržby za období roku a konkrétního měsíce. 8 Slicer

48 6 PREZENTAČNÍ VRSTVA TABULÁRNÍHO MODELU Tržby dle místa Tržby dle místa vznikly podobým způsobem jako tržby dle států, s tím rozdílem, že používáme státy jako filtr. Pro tento účel používáme v nástroji Power View tzv. průřez, který filtruje konkrétní místa daného státu dle časového období. Takových průřezů může být i více, v tomto reportu jsou přidány průřezy na roky a měsíce. Obrázek 29: Tržby dle místa

49 6 PREZENTAČNÍ VRSTVA TABULÁRNÍHO MODELU Problém s geolokací Vybráním státu Spojené království Velké Británie (na obrázku 30) vznikl problém s geolokací dle místa tržby. Mapový server Bing vyhodnotil z hlediska tržby anglická města Lincoln a Birmingham jako americká a tak tržbu vykazuje na mapě právě v amerických městech Lincoln a Birmingham. Tento problém vznikal i u vyhodnocení tržby geolokace Velkých Albrechtic, které se také zobrazovaly ve Spojených státech amerických. Tento problém bude nejspíše způsoben diakritikou a tedy obecně problém mapového serveru Bing. Řešením by mohla být změna mapového serveru. Obrázek 30: Tržby dle místa problém s geolokací

50 6 PREZENTAČNÍ VRSTVA TABULÁRNÍHO MODELU Největší dlužníci Cílem reportu je vybrat 10 největších dlužníků k určitému dni splatnosti s filtrováním útvarů. K tomu jsou využit kalkulovaný sloupec rozdil_favsplatba, který zobrazuje rozdíl mezi fakturovanou částkou a zaplacenou částkou a funkcí, která vypočítá pořadí dlužníka na základě rozdílu mezi fakturovanou a zaplacenou částkou k určitému dni splatnosti (poradi_dluznik_veritel). Zvolen typ salda pohledávky. Konstruována statistická funkce RANKX, která vrátí pořadí čísla v seznamu čísel pro každý řádek v názvu organizace. Tento atribut můžeme filtrovat a zvolit například největších 10 dlužníků tak, jak vidíme na obrázku RANKX 1 RANKX(<tabulka>, <výraz>[, <hodnota>[, <ASC, DESC>]]) Listing 13: Sytnaxe funkce RANKX Funkce RANKX obsahuje volbu tabulka, ve které probíhá vyhodnocení výrazu. Výraz se tedy hodnotí pro každý řádek tabulky, vzniknou tedy všechny možné hodnoty pořadí. Samozřejmě dlužníky řadíme od největšího po nejmenšího a v okně filtrace vybíráme TOP 10 dlužníků. 1 Poradi_dluznik_veritel:=RANKX( all (saldo [název organizace ]), saldo [Sum of rozdilfavsplatba ]) Listing 14: Funkce k reportu dlužníků Report 31 zobrazuje název organizace, dlužnou částku a pořadí dlužníka na jednotlivých útvarech k určenému dni splatnosti. Výběr více útvarů v nástroji Power View řešíme stisknutím klávesy CTRL a kliknutím na požadované útvary. Funguje i pro největší věřitele, jedinou změnou je filtrace typu salda na závazky.

51 6 PREZENTAČNÍ VRSTVA TABULÁRNÍHO MODELU 51 Obrázek 31: Největší dlužníci (věřitelé) 6.8 Doklady po splatnosti Doklady po splatnosti dle business zadání na obrázku 32 sledují číslo dokladu, která je po splatnosti, název organizace, počet dní, které je doklad po splatnosti a částku, která byla po splatnosti okamžikem vyrovnání zaplacena. Použit byl kalkulovaný sloupec po_splatnosti, který zobrazuje rozdíl mezi dnem vyrovnání a dnem splatnosti, tedy počet dní, které byl doklad po splatnosti. Doklady po splatnosti můžeme dále prostřednicvím průřezu filtrovat dle útvaru. Lze opět využít na typ salda pohledávek nebo závazků, případně ostatní. Obrázek 32: Doklady po splatnosti

52 6 PREZENTAČNÍ VRSTVA TABULÁRNÍHO MODELU Odběratelé, dodavatelé (průměrná doba splatnosti) Report 33 počítá průměrné doby splatnosti odběratelů, stejně tak dodavatelů. Vytvořeno měřítko pro průměr z kalkulovaného sloupce dne vyrovnání a dne splatnosti (Average of splatnost). Na to navazovala funkce RANKX pro určení pořadí organizace podle doby splatnosti. Nejlepší organizace má nejnižší dobu splatnosti, to znamená, že ve funkci RANKX bylo nutno nastavit jako poslední parametr 1 (nejmenší = nejlepší). 1 Average of splatnost:=average([ po_splatnosti ]) 2 Poradi_prumerne_splatnosti:=RANKX( all (saldo [název organizace ]), 3 saldo [Average of splatnost ], saldo [Average of splatnost ],1) Listing 15: Funkce k reportu dlužníků Obrázek 33: Odběratelé, dodavatelé průměrná doba splatnosti

53 6 PREZENTAČNÍ VRSTVA TABULÁRNÍHO MODELU Největší dodavatelé, odběratelé Report na obrázku 34 sleduje největší dodavatele a odběratele. Dále průřezy na rok, konkrétní měsíc a útvar. Filtrovat lze také na typ salda závazků a pohledávek. Ke zjištění největších 10 dodavatelů (odběratelů) opět využita funkce RANKX, ve které můžeme ve filtračním okně Power View vybírat požadovaný počet (většinou TOP 10). Ekvivalentní funkce existuje jako filtrační funkce také v MS Excel. 1 Organizace_poradi_nej_dodavatele:=RANKX( all (saldo [název organizace ]), [Sum of fakturykc ]) Listing 16: Funkce RANKX k reportu největších dodavatelů Obrázek 34: Největší dodavatelé, odběratelé

54 6 PREZENTAČNÍ VRSTVA TABULÁRNÍHO MODELU Zakázka Report na obrázku 35 zobrazuje detaily zakázky. Zde byla využita organizační hierarchie Země Místo Ulice Organizace. K vidění jsou dva sloupce, červený pro součet vyfakturovaných a modrý pro součet vyplacených faktur za určité období. Vidíme číslo zakázky přiřazené do konkrétních států, procházením hierarchie se zakázky filtrují dále. Prostřednictvím průřezů je možné procházet jednotlivé roky a měsíce. V nástroji Power View můžeme procházet až na nejnižší úroveň, tedy organizace a zjistit její zakázky. Konkrétně na obrázku 35 vidíme čísla zakázek a sumu plateb a fakturace pro Jihoafrickou republiku, Rakouskou republiku, Slovenskou republiku a Spojeného království Velké Británie a Severního Irska. Obrázek 35: Zakázka 6.12 Čištění reportů a nasazení na SharePoint V konečné fázi byly jednotlivé reporty v program SSDT pro uživatele reportů skryty nepotřebné nebo výpočtové sloupce, aby uživatele nemátly při tvorbě sestav a nasazeny na službu SharePoint pro sdílení dokumentů.

55 7 DISKUZE 55 7 Diskuze V teoretické části se lze seznámit s oblastí tabulárního modelování, jakožto nového myšlenkového směru, kterým se Business Intelligence ubírá. Vytvořený datový model se určitě dá rozšiřovat v závislosti na transakční databázi. Záleží ovšem na požadované komplexnosti řešení a rozhodnutí, zda se nám vyplatí tvorba datového skladu. V okamžiku nahrávání dat do tabulárního modelu je také vhodné použít řazení, protože xvelocity je výkonná a vysoce komprimovaná sloupcová databáze, která po seřazení poskytuje lepší výkon při dotazech a nižší využití paměti. Při importu tabulek jinak nenastaly výraznější problémy, složitější bylo nastudovat problematiku časové inteligence v integraci s Power View a vytvoření funkcí Business Intelligence. Praktický přínos práce je jednoznačný. Vytvoření uživatelsky přívětivých interaktivních reportů s poskytnutím funkcí k samoobslužnému využití těchto reportů. 7.1 Existující řešení Dostupné materiály uvádí jako podmínku pro tvorbu tabulárního modelu existenci datového skladu. V případě kvalitní transakční databáze u projektů menšího rozsahu není nutný. Při rozšíření tabulárního modelu je na zvážení tvůrce modelu, jestli je model stále jednoduchý nebo má příliš mnoho vazeb a tabulek. V tom případě by se vyplatila konsolidace dat a tvorba datového skladu. S časovými kalkulacemi se tabulární model dokáže velmi dobře vypořádat, stejně tak porovnáváním paralelních období a rekurzivními hierarchiemi. Škálovatelnost jde pak na vrub přehlednosti řešení a vede k redundanci dat v modelu. 7.2 Srovnání s existujícími řešeními Jelikož tabulární modelování je relativně nový přístup k modelování Business Intelligence a velká většina těchto existujících řešení staví na datovém skladu, je srovnání obtížné. Časová náročnost projektu se odvíjí od rozhodnutí budování datového skladu. Bez něj se dá mluvit o rychlém vývoji Business Intelligence řešení, které je vhodné spíše na projekty menšího rozsahu bez nutnosti náročné implementace. Jaké je tedy tabulární řešení Business Intelligence ve vztahu k multidimenzionálnímu řešení? To záleží na zadání projektu. Pro méně rozsáhlé projekty je určitě použitelné, obzvláště při kvalitním datovém skladu. Pokud chceme pracovat s transakční databází, záleží pak na její kvalitě, resp. jejím naplnění a kompletnosti tak, abychom mohli získat relevantní výsledky. Co se týče vytvořeného tabulárního projektu, lze vylepšit v okamžiku importu dat do tabulárního modelu, kdy se dá použít řazení, protože xvelocity je výkonná a vysoce komprimovaná sloupcová databáze, která data v segmentech podle počtu hodnot ve sloupci, při řazení pak poskytuje lepší výkon při dotazech a nižší využití paměti.

56 7 DISKUZE 56 Zbývá odpovědět na otázku, jestli by měl zákazník migrovat multidimenzionální na tabulární. Odpovědí je ne v případě, že už multidimenzionální řešení má. V tom případě lze pokračovat v něm a pro odlišný přístup nebo pro specifický datový trh, reporty a kalkulace si může navrhnout tabulární model. Nejdůležitější fakta o tabulárním a multidimenzionálním modelování Business Intelligence jsou zmapovány v následujícím odstavci. U každého jsou pak vybrány důvody pro a proti řešení. 7.3 Tabulární modelování Jednoduchý datový model. Není zde koncept na fakta a dimenze, v podstatě stírá rozdíl mezi faktem a dimenzí. Každý sloupec lze použít jako dimenzi. Každý sloupec můžeme použít jako měřítko. Vztahy (1:N). Nejsou zde agregace, výpočet probíhá v paměti. Výborný výpočetní výkon díky xvelocity Pro tabulární modelování Rychlost vytvoření. Jednoduchá spolupráce s uživatelsky přívětivým tvůrcem reportů Power View. Rozdělení na menší celky. Integrace s Power View Proti tabulárnímu modelování Neexistence datového skladu a tím pádem i procesů čištění a konsolidace dat. Rozdělení na menší celky plodí redundantní práci. 7.4 Multidimenzionální modelování Silná separace na fakta a dimenze. Podpora vztahů Many-to-Many. Pokročilé vazby. Horší výpočetní výkon než tabulární.

57 7 DISKUZE Pro multidimenzionální modelování Větší flexibilita výpočetní části. Spolupráce v týmu. Možnost větší expanze řešení a jeho škálovatelnosti Proti multidimenzionálnímu modelování Složitost řešení. Nelze použít Power View.

58 8 ZÁVĚR 58 8 Závěr Cílem diplomové práce bylo prozkoumat možnosti nástrojů firmy Microsoft v oblasti Business Intelligence. Za tím účelem byl vytvořen tabulární modelu Business Intelligence a sestaveny požadované reporty, na které je uživatelům poskytnut samoobslužný přístup k funkcím Business Intelligence. V první fázi došlo k nastudování problematiky tabulárního modelování. Čerpal jsem především z knihy Microsoft SQL Server 2012 Analysis Services: The BISM Tabular Model, kterou sepsali Marco Russo, Alberto Ferrari a Chris Webb. Marco Russo také poskytl cenné názory k časové inteligenci při tvorbě reportů a problémy s nimi spojenými. Další důležitou knihou, nutnou k pochopení problematiky tabulárního modelování, byla Applied Microsoft SQL Server 2012 Analysis Services: Tabular Modeling od Teo Lacheva. Obě tyto knihy jsou uvedeny v přehledu literatury. Na základě získaných znalostí byla navržena metodika práce. Po nastudování literatury a vymezení důležitých pojmů došlo k analýze informačního systému HELIOS Green. Sestavení kvalitního modelu bylo totiž možné pouze důkladnou analýzou zdrojové transakční databáze, jelikož přímo z ní byla čerpána data pro tabulární model. Vlastní práce se zabývala importem tabulek ze zdrojové databáze na SQL Serveru 2012, tvorbou kalkulovaných sloupců, vytvořením hierarchií, měřítek a čištěním datového modelu pro samoobslužný přístup prostřednictvím interaktivních reportů a v návaznosti na to zhodnocení tabulárního modelování a samoobslužného přístupu k funkcím Business Intelligence. Veškerý vývoj probíhal pod platformou Microsoftu. Diplomová práce splnila požadovaný cíl, tím je zmapování možností tabulárního modelování Business Intelligence obsahující požadované reporty se samoobslužným přístupem.

59 9 REFERENCE 59 9 Reference INMON, W. Building the Data Warehouse. 1. vyd. Wiley, s. ISBN KIMBALL R., ROSS M. The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling. 2. vyd. Wiley, s. ISBN LACHEV, T. Applied Microsoft SQL Server 2012 Analysis Services: Tabular Modeling. 1.vyd. USA: Prologika Press, s. ISBN LACKO, Ľ. Business Intelligence v SQL Serveru 2005: Reportovací, analytické a další datové služby. 1.vyd. Brno: Computer Press, s. ISBN NOVOTNÝ O., POUR J., SLÁNSKÝ D. Jak využít bohatství ve vašich datech. 1. vyd. Praha: Grada, s. IBSN RUSSO M., FERARRI A., WEBB Ch. Microsoft SQL Server 2012 Analysis Services: The BISM Tabular Model. 1. vyd. USA: Microsoft Press, s. ISBN BIEXPERTS. Poskytované služby [online] [cit ]. Dostupné z: DOKUMENTACE HELIOS. Metadata [online] [cit ]. Dostupné z: DOKUMENTACE HELIOS. Pohled na jádro z hlediska analýzy [online] [cit ] Dostupné z: DOKUMENTACE HELIOS. Jádro ve vrstvě uložení dat [online] [cit ]. Dostupné z: HELIOS. Vyberte si svůj informační systém [online] [cit ]. Dostupné z: MICROSOFT. Rychlý úvod: Naučte se základy jazyka DAX za 30 minut [online] [cit ]. Dostupné z: cz/excel-help/rychly-uvod-naucte-se-zaklady-jazyka-dax-za-30-minut- HA aspx. MICROSOFT. Dostupnost business intelligence pro všechny 2013 [cit ]. Dostupné z: TECHED NORTH AMERICA: BISM: Multidimensional vs. Tabular [online] [cit ]. Dostupné z:

60 9 REFERENCE 60 PRASHANTH M. Star Schema and Snowflake Schema [online] [cit ]. Dostupné z: PROCHÁZKA, P. Data Warehousing v praxi [online] [cit ]. Dostupné z: PVA SYSTEMS. Datový sklad, OLAP, Business Inteligence [online] [cit ]. Dostupné z: SERRA, J. SQL Server 2012: Multidimensional vs tabular [online] [cit ]. Dostupné z: multidimensional-vs-tabular. WEBB Ch. So, what is the BI Semantic Model? [online] [cit ]. Dostupné z:

61 10 PŘÍLOHY Přílohy A Business zadání A.1 Tržby dle států Report dle business zadání na obrázku 36 vytvořit report sumy tržby za určená období roku s filtrací států. Obrázek 36: Tržby dle státu

62 10 PŘÍLOHY 62 A.2 Tržby dle místa Tržby dle místa (obrázek 37) sleduje konkrétní místa a jejich tržby, podobně jako tržby dle státu. Obrázek 37: Tržby dle místa

63 10 PŘÍLOHY 63 A.3 Největší dlužníci Obrázek 38 sleduje největší dlužníky, tedy rozdíl mezi fakturací a vyplacenou částkou pro konkrétní organizaci. Obrázek 38: Největší dlužníci

64 10 PŘÍLOHY 64 A.4 Doklady po splatnosti Cílem bude zjistit doklady po splatnosti k určenému datu dle útvarů (obrázek 39). Obrázek 39: Doklady po splatnosti

65 10 PŘÍLOHY 65 A.5 Odběratelé průměrná doba splatnosti Report na obrázku 40 má za úkol zobrazit průměrnou dobu splatnosti jednotlivých odběratelů k určitému datu. Obrázek 40: Odběratelé průměrná doba splatnosti

66 10 PŘÍLOHY 66 A.6 Největší dodavatelé Report na obrázku 41 má za úkol zobrazit největší dodavatele. Obrázek 41: Největší dodavatelé

67 10 PŘÍLOHY 67 A.7 Zakázka Report na obrázku 42 cílí na zakázky a její detaily. Obrázek 42: Zakázka

68 10 PŘÍLOHY 68 B Další funkce časové inteligence Další z časových funkcí je funkce pro porovnávání paralelních období, uvedena ve vzorci 17. Na obrázku 43 vidíme, že v roce 2010 jsme vydali faktury za částku, kterou pak srovnáváme v roce 2011 s aktuální výší fakturace. Lze vyčíst, že jsme na 105,26 % procentech výše faktur z minulého roku, což znamená 5,26 % nárůstu výše fakturace. Také bylo vytvořeno KPI, když do 90 % se zobrazuje červeně (mohlo by znamenat, že neplníme nějaký svůj plán), žlutě % (v normě) a nad 100 %, tedy nárůst, zeleně. B.1 Porovnávání paralelních období 1 fakturyisply:=calculate( SUM (saldo [ fakturykc ]), DATEADD (cas [F1], 1, YEAR) ) Listing 17: Výpočet paralelního období předchozího roku Obrázek 43: Srovnávání paralelních období v PowerPivotu