56 - OLAP-určení, rozdíly oproti OLTP, datový model (datová kostka a operace, zobrazení kostky), datové sklady (struktura, komponenty) Flashcards
Základní pojmy, big data, databázový model
Konceptuální schéma -> popisuje metadata systému, je v drtivé většině OBJEKTOVÉ, může mít grafickou syntax (ER, UML) nebo textovou syntax (CDL – Concept Definition Language). Schéma se používá jak pro vývojáře, tak pro uživatele.
Relační konceptuální schéma je velmi odlišné od objektového, v tomto ohledu jsou výhodné objektové databázové systémy, není potřeba složité transformace, ale relační systémy jsou mnohem používanější v praxi (často s doplněním objektových vlastností)
Big data
• Big data jsou data tak veliká a komplexní, že se stává obtížným zpracovávat je dostupnými databázovými prostředky nebo tradičními aplikacemi.
• musíme nově řešit výpočetní prostředky a ostatní technologie pro sběr, zpracování, ukládání, vyhledávání, sdílení, přenos, analýzu a vizualizaci.
• Hlavní důvody pro zavedení a další používání pojmu big data:
○ nárůst kapacity pro ukládání dat
○ nárůst výpočetní síly
○ velká dostupnost dat
• 3 (až 4)V: ○ Volume (objem): generovaná data jsou produkována ve větších kvantech, nežli tradiční data ○ Velocity (rychlost): rychlost zpracování ○ Variety (různost): velká různost vstupních dat, která jsou zpracována na různá výstupní data ○ někdy se přidává i Veracity (ne-pravdivost)
Databázový model
• Modely, které je schopen interpretovat systém pro řízení databázového systému SŘBD
• Jinak též zvané produkční modely
• V jejich definičním jazyku musejí být zapsána metadata pro všechny datové struktury uložené v databázi
• Prozatím budeme uvažovat relační a objektový datový model
pyramida - big data ExecutiveIS -> DecisionSS -> ManagementIS -> OLTP online transaction processing
OLTP
OLTP - on-line transaction processing
• Třída informačních systémů, které zpracovávají transakčně orientované aplikace • Termín transakční je dvojznačný: ○ databázové transakce ○ komerční transakce • mohou se ovšem překrývat • Tento termín je rovněž používán v případě, kdy systém odpovídá okamžitě na uživatelovy požadavky změnou stavu. • příkladem aplikace pro komerční transakce může být např. bankomat. * metodologie, která poskytuje koncovému uživateli přístup k rozsáhlým objemům dat a pomáhá jejich zkoumání. * podpora pro databázové transakce, které zahrnují i síťové zpracování a mohou být dlouhé a distribuované * užívají zpracování typu klient/server a dovolují transakcím běžet na rozdílných platformách v síti * pro decentralizované databázové systémy musejí OLTP distribuovat transakce mezi mnoho počítačů a síť
aneb.
* slouží pro každodenní operace * zaměřené na přesné uchovávání aktuálních dat * krátké jednoduché ACID transakce * velké množství změn relativně jednoduchých dat * strukturované a opakující se dotazy * velikost - řádově jednotky až desítky GB * metrika - průchodnost TRANSAKCÍ * probíhá nad operačními DB -> důraz na konzistenci a možnost zotavení * výkonné pro jednotlivé operace, pomalé pro komplexní agregované dotazy
OLAP
OLAP - On-Line Analytical Processing
• slouží k podpoře rozhodování
• pracuje s konsolidovanými agregovanými daty z heterogenních zdrojů (operační DB - i několik různých, pomocné soubory - text, CSV, excel)
• malé množství změn složitých dat
• velká intenzita jedinečných a složitých dotazů
• důraz na sumarizaci a konsolidaci dat, ne na přesnost jednotlivých záznamů
• průchodnost dotazů mnohem důležitější, nežli spolehlivé zpracování transakce
• velikost - řádově stovky GB až jednotky TB
• metrika - průchodnost DOTAZŮ, odezva
• pracuje nad datovými skladišti: ○ databáze sloužící k podpoře rozhodování, která je uložena odděleně od operační databáze ○ data typicky ukládána multidimenzionálně (dimenze často hierarchické) ○ ukládají i všechna historická data ○ vyžadují speciální organizaci dat, přístupové a implementační metody
Business intelligence
• procesy, technologie a nástroje potřebné k přetvoření dat a informací do znalostí pro podporu rozhodování na různých úrovních
• Př.:
○ Manager potřebuje vědět, kterým klientům může nabídnout po telefonu úvěrovou kartu, u kterých klientů je vysoké riziko odchodu ke konkurenci
○ Manager potřebuje znát vývoj tržeb za posledních třicet dní v členění dle regionů a produktů či jak se liší skutečný výkon společnosti od plánovaného
* Vstup: velké objemy (big data) primárních (produkčních) dat * Výstup: znalosti, které lze využít v procesu rozhodování • Prostředky business intelligence: 1. Datové sklady (data warehouses) § systém převodu a uložení dat pro analýzu, definovaní formálního modelu dat § slouží především pro ukládání primárních detailních dat izomorfní homodelu (modelování reálného systému) § výsledkem vesměs pevného počtu dotazů jsou především data explicitně uvedená v databázi bez dalších agregačních úprav § výhodné především pro jednoduché transakce (vkládání, mazání…) -OLTP, naopak nevhodné pro složitější analýzu velkých dat 2. OLAP (On-line AnalyticalProcessing) § rozhraní pro manipulaci s modelem a zpřístupnění výsledků uživateli a dalším aplikacím 3. Data Mining(dolování dat)
DATOVÉ SKLADY (DATA WAREHOUSES)
• Podnikově strukturovaný depozitář subjektově orientovaných, integrovaných, časově proměnlivých, historických dat použitých na získávání znalostí a podporu rozhodování
• obsahuje operační i agregovaná data.
• Datovým skladem nazýváme technologii
○ natažení (extrakce a transformation)
○ uložení (loading) a
○ poskytování
• dat pro podporu rozhodování prováděnou analýzou informací a vytvářením znalostí
• je typicky provozován odděleně od základní operační databáze (též databáze detailů nebo produkční databáze)
Datové trhy (Data mart) - podmnožiny datového skladiště poskytující data jednotlivým oddělením
Nevhodnost produkčních databází jako datových skladů:
○ slouží především pro ukládání primárních detailních dat izomorfního modelu (modelování reálného systému) ○ výsledkem vesměs pevného počtu dotazů jsou především data explicitně uvedená v databázi bez dalších agregačních úprav ○ výhodné především pro jednoduché transakce (vkládání, mazání…) - OLTP, naopak nevhodné pro složitější analýzu velkých dat ○ obvykle decentralizovanost systémů OLTP - data potřebná pro analýzu jsou většinou uložena v různých heterogenních DB na různých serverech, není většinou k dispozici integrovaný zdroj údajů a je složité tato data integrovat a homogenizovat ○ nehomogenní struktura údajů – různé názvy vlastností, datové typy… ○ nevhodnost technologie pro analýzy pro standardní výpočtové prostředky a modely ○ degradace výpočetního výkonu databázového stroje –neustále se opakujícími stejnými agregačními výpočty ○ případně nejsou uchovávány historické údaje – uchovávají se zpravidla pouze aktuální dat
Vhodný model = vícerozměrnost
○ aby bylo možno provádět komplexní analýzu a vizualizaci, jsou data v datovém skladu typicky modelována multidimenzionálně. ○ jiný datový model, nežli relační ○ klade důraz na strukturu pro budoucí dotazy ad hoc vyžadující agregační a statistické výpočty
Vlastnosti datového skladu, Datový sklad x produkční databáze, Požadavky na datový sklad
Vlastnosti datového skladu
1. Orientace podle dimenzí = Fakta jsou zapisována podle vlastností vyjádřeného průsečíkem n-dimenzí 2. Integrace ○ data týkající se konkrétního předmětu se ukládají pouze jednou § jednotná terminologie, jednotky veličin ○ vytvořen případně integrací několika heterogenních zdrojů dat - relační databáze, textové soubory, on-line transakce § problém nekonzistentních zdrojů dat ○ nutnost úpravy, vyčištění a sjednocení (integrace) vstupních dat § je nutné ověřit konzistenci v pojmenování proměnných, jejich struktury a jednotkách pro různé zdroje dat 3. Čas ○ klíčový atribut (lineární, uspořádaný a spojitý), vhodný na spojité grafy ○ Časový horizont datového skladu je zpravidla podstatně delší než u produkční databáze § Produkční databáze: pouze současně aktuální data § Data v datovém skladu: poskytují informace z historické perspektivy (např. posledních 5-10 let) ○ Každá klíčová struktura v datovém skladu § obsahuje čas, explicitně nebo implicitně § klíč u produkčních dat nemusí vždy obsahovat čas 4. Neměnnost ○ Zpravidla fyzicky oddělené uložení dat transformovaných z produkčních databází ○ V datových skladech se data nemění, manipulace s daty je tedy jednodušší. § dva typy operací: vkládání dat a čtení dat § optimalizace a normalizace ztrácí smysl § nepotřebuje se zpracování transakcí, zotavení, mechanismy pro řízení souběžného přístupu
produkční databáze X Datový sklad
Uživatelé a orientace systému: zákazník X obchodník
Datový obsah: současná, detailní X historická, sloučená
Návrh databáze: ER model + aplikace X multidimenzionální kostka, dimenze, fakta
Pohled na data: aktuální, lokální X evoluční, agregovaný
Přístupové vzory: jednoduchá aktualizace X read-only, ale komplexní dotazy
Požadavky na datový sklad
• schopnost agregace
• databáze navržená pro analytické dotazy
• možnost integrovat data z více aplikací
• častá operace čtení z databáze
• nahrání dat po určité časové periodě
• možnost využití současných i historických dat
Architektura datového skladu (získání dat, uložení dat, předávání výsledků)
Schéma: -> data (produkční db, monitoring data,..) -> ETL (extrakce, transformace, zavedení (loading)) -> datový sklad (a datové trhy) -> OLAP -> uživatelé (analýza,..)
!!! Získání dat !!! (Hlavní cíl: integrace údajů)
* Zdrojová data + místo přípravy dat (ETL) * extrahování dat z mnoha produkčních databází a externích zdrojů * čištění, transformování a integrování těchto dat - Extraction, Transformation, Loading - ETL * Periodické doplňování datového skladu tak, aby odrážel změny v produkčních databázích a přenos dat z datového skladu, nejčastěji do pomalejší archivní paměti. • Extrakce – výběr dat různými metodami ○ Přímá extrakce § Liší se způsobem zachycení změn v DB od posledního nahrání □ Zachycení pomocí log souborů (vytvořených databází) □ Zachycení pomocí databázových triggerů § Při každé změně se spustí trigger, který zapíše změnu do souboru □ Zachycení pomocí samotných databázových aplikací ® Editace aplikace tak, aby ukládala záznamy o provedených změnách v DB ○ Odložená extrakce § Nezachycují změny při jejich vzniku, ale až při nahrávání se porovnává zdrojová a cílová DB □ Zachycení pomocí časových razítek § Razítky jsou označeny záznamy, které byly přidány nebo editovány – ty se pak při nahrávání dat naleznou (problém s mazáním) □ Zachycení pomocí porovnávání souborů § Vytvoří se soubor s kopií dat ve stavu současném a včerejším, pak se soubory porovnají (velmi neefektivní) • Transformace – ověření, čištění (ověření nekonzistencí), integrace a časové označení dat
- různé typy polí
- různé názvy polí
- různá sémantika polí (stejná pole různé sémantiky)
- chybějící položky (povinné/volitelné položky)
- různá integritní omezení• Loading – přesun dat do datového skladu
○ Iniciální nahrávání - Nahrávání všech dat do prázdného skladu
○ Inkrementální nahrávání - promítnutí změn v DB do datového skladu (provádí se periodicky)
○ Přepis dat - kompletní smazání obsahu skladu a nahrání aktuálních dat
!!! Uložení dat !!!
• Datový sklad + datové trhy + uložení metadat • Datové trhy (Data mart) - podmnožiny datového skladiště poskytující data jednotlivým oddělením - k hlavnímu datovému skladu je přidruženo několik datových trhů (data marts) různých dílčích uživatelů. • data ve skladu a trhu jsou uložena a spravována jedním nebo více skladovými servery, které prezentují multidimenzionální pohled na data OLAPu a/nebo přímo různým koncovým prostředkům • Jde o oddělené skladiště pro uložení velkého množství především historických dat • Je navrženo pro analýzu, ne pro rychlý přístup k datům • Jsou pro uživatele read-only • Musí být přístupná pro více druhů nástrojů –odpovídající rozhraní Repozitory -> pro ukládání a správu metadat(katalogu) a pro monitorování a administraci systému datového skladu • Typy metadat: ○ Produkční metadata - obsahují informace o všech zdrojích dat pro datový sklad (struktura, umístění atd.) ○ Metadata o extrakci a transformaci - informace o tom, jaké metody byly použity při ETL fázi, různá omezení apod. ○ Metadata pro koncového uživatele - informace o datovém skladu a datech v něm, další obchodní a jiné informace, které může využít pro analýzu • Uložiště multidimenzionálních údajů ○ relační x multidimenzionální databázový model § formát dat § objem dat – nutnost komprese
○ 4 základní typy uložišť –podle způsobu uložení dat (viz dále) § MOLAP § ROLAP § HOLAP § DOLAP
!!! Předávání výsledků !!!
• přes model multidimenzionální databáze samotné získání informací (OLAP, data mining, tiskové sestavy atd.) • Tenký klient ○ Pro přístup k údajům požívá např. www prohlížeč ○ Vše ostatní běží na serveru ○ Výhoda: možnost použití různých platforem, levný HW ○ Nevýhoda: omezení uživatelského rozhraní (protokol HTTP) • Tlustý klient ○ Aplikace běží na lokálním počítači, údaje jsou na serveru ○ Vyšší nároky na hardware pro lokální stanice ○ Nutnost více kopií SW –dražší licence ○ Nutnost vývoje aplikace pro různé OS zvlášť
OLAP: Online Analytical Processing (Data Warehousing)
- technologie uložení dat v databázi, která umožňuje uspořádat velké objemy dat tak, aby byla data přístupná a srozumitelná uživatelům zabývajícím se analýzou obchodních trendů a výsledků (Business Intelligence).
- Způsob uložení dat se svým zaměřením liší od běžněji užívaného OLTP (Online Transaction Processing), kde je důraz kladen především na snadné a bezpečné ukládání změn v datech v konkurenčním (víceuživatelském) prostředí.
Základní rozdíly mezi OLAP a OLTP vyplývají z rozdílného použití – u OLAP se jedná o jednorázově nahrávaná data, nad kterými jsou prováděny složité dotazy, u OLTP jsou data průběžně a často modifikována a přidávána, a to obvykle mnoha uživateli zároveň.
OLTP
- slouží pro každodenní operace
- zaměřené na přesné uchovávání aktuálních dat
- krátké jednoduché ACID transakce (atomicity, consistency, isolation, durability)
- velké množství změn relativně jednoduchých dat
- strukturované a opakující se dotazy
- velikost - řádově jednotky až desítky GB
- metrika - průchodnost transakcí
- probíhá nad operačními DB
• důraz na konzistenci a možnost zotavení
• výkonné pro jednotlivé operace, pomalé pro komplexní agregované dotazy
OLAP
- slouží k podpoře rozhodování
- pracuje s konsolidovanými agregovanými daty z heterogenních zdrojů (operační DB - i několik různých, pomocné soubory - text, CSV, excel)
- malé množství změn složitých dat
- velká intenzita jedinečných a složitých dotazů
- důraz na sumarizaci a konsolidaci dat, ne na přesnost jednotlivých záznamů
- průchodnost dotazů mnohem důležitější, nežli spolehlivé zpracování transakce
- velikost - řádově stovky GB až jednotky TB
- metrika - průchodnost dotazů, odezva
- pracuje nad datovými skladišti
• databáze sloužící k podpoře rozhodování, která je uložena odděleně od operační databáze
• data typicky ukládána multidimenzionálně (dimenze často hierarchické)
• ukládají i všechna historická data
• vyžadují speciální organizaci dat, přístupové a implementační metody
- NEMÁ NF, VÍCE INDEXŮ, AGREGOVANÉ A PŘEDPOČÍTÁNÉ HODNOTY
• OLAP nepoužívá na rozdíl od OLTP normalizované uložení dat v 3NF formě – data jsou v uložena tak, aby umožňovala rychlou realizaci složitých dotazů, časté je zdvojené (redundantní) uložení, které by v případě OLTP komplikovalo provádění změn v datech,
• OLAP používá podstatně více indexů než OLTP – opět to souvisí se zaměřením, kde indexy umožňují rychlé provedení složitých dotazů,
• OLAP na rozdíl od OLTP často používá přepočítané agregované a odvozené hodnoty.• 12 pravidel pro OLAP:
1. Multidimenzionální konceptuální model - OLAP by měl poskytovat uživateli multidimenzionální model tak, aby odpovídal jeho potřebám a aby tento model mohl využívat pro analýzu shromážděných údajů.2. Transparentnost - Aby uživatel mohl plně využít svoji produktivitu, odbornost a prostředí docílíme tím, že technologie systému OLAP, jeho databáze a architektura výpočtu bude transparentní. Důležité je, že vstupní data jsou heterogenní a jejich homogenitu zajistíme pomocí ETL. 3. Dostupnost - Systém OLAP by měl přistupovat pouze k údajům, které jsou potřebné pro analýzu. Systém by měl navíc být schopen přistupovat ke všem takovým údajům nezávisle na tom, z kterého heterogenního podnikového zdroje pocházejí a jak často jsou obnovované. 4. Stabilní výkonnost - Při rostoucí velikosti DB by nemělo nastat snížení výkonu, Uživatel nesmí pocítit žádné podstatné snížení výkonu i když velikost databází postupem času narůstá 5. Architektura klient-server - Systém OLAP musí fungovat na základě architektury klient/server. Důležitá je cena, výkon, flexibilita, interoperabilita 6. Generická dimenzionalita - Každá dimenze údajů musí být ekvivalentní jak ve struktuře, tak v operačních schopnostech 7. Dynamické ošetření řídkých matic - Systém OLAP musí být schopen přizpůsobit svoje fyzické schéma na konkrétní analytický model, který optimálně ošetří řídké matice za současného udržení požadované úrovně výkonu 8. Podpora pro více uživatelů - Systém OLAP musí být schopen podporovat více uživatelů nebo skupin uživatelů pracujících současně na konkrétním modelu. 9. Neomezené křížové dimenzionální operace - Systém OLAP musí rozeznat dimenzionální hierarchie a automaticky vykonávat výpočty v rámci dimenzí a mezi dimenzemi 10. Intuitivní manipulace s údaji - Možnost přeorientování na detailní úroveň a zpět, Uživatelské rozhraní musí umožňovat všechny manipulace s daty v pro něj přístupném (user-friendly) prostředí. Například musí zvládat intuitivně operace drill-down a roll-up 11. Flexibilní vykazování - Schopnost uspořádat řádky, sloupce a buňky způsobem, který umožní analýzu a intuitivní prezentaci analytických sestav 12. Neomezené dimenze a úrovně agregace -V závislosti na požadavcích procesu rozhodování může mít analytický model více dimenzí, přičemž každá z nich může mít víceúrovňovou hierarchii. Analytický model by neměl být uměle omezovaný počtem dimenzí a úrovní hierarchie
Architektury serveru OLAP
Shrnutí
MOLAP - Multidimenzionální paměťový stroj založený na polích (array) - techniky řídkých matic
ROLAP - Užívá relační nebo rozšířená relační SŘBD
Hybridní OLAP (HOLAP) - Uživatelská flexibilita kombinující MOLAP a ROLAP
- Data v relačních tabulkách, agregace se ukládají do multidimenzionálních struktur
- Využití multidimezionální cache
DOLAP = Desktop OLAP, Multidimenzionální tabulky uloženy na klientském počítači, datový sklad na serveru ve formě relačních tabulek - prostě multidimenzialita uložená na desktopu v nějákém spešl softwaru
Multidimenzionální OLAP (MOLAP)
* Multidimenzionální paměťový stroj založený na polích (array) - techniky řídkých matic * Rychlé indexování předzpracovaných agregovaných dat * Data se získávají z DB nebo datového skladu * Ukládají se do vlastních datových struktur * Databáze konstruována pro rychlé vyhledávání údajů * Výhoda: maximální výkon * Nevýhoda: redundance údajů, velké prostorové nároky
Relační OLAP (ROLAP)
• Užívá relační nebo rozšířená relační SŘBD • Zahrnují optimalizaci back-endu SŘBD, implementaci agregační navigační logiky a dodatečných pomůcek a služeb • Velká možnost škálování • Údaje jsou získávány z relačních tabulek, jsou uživateli předkládány jako multidimenzionální pohled • Data jsou uložena jako záznamy relační tabulky (datová skladiště nad klasickými nebo rozšířenými relačními DB) • Žádná redundance - speciální SQL podpora pro multidimenzionální dotazování
- Hvězdicové schéma
○ užívá většina datových skladišť k reprezentaci multidimenzionálního modelu
○ jedna tabulka hodnot
○ jedna tabulka pro každou dimenzi (sloupce odpovídají atributům dimenze)
○ Každá n-tice v CENTRÁLNÍ TABULKA HODNOT sestává z ukazatele do každé dimenze, který poskytuje jeho multidimensionální souřadnice. - Sněhová vločka (snowflake) - hierarchie dimenzí je explicitně reprezentována normalizováním tabulek dimenzí (vlastně to samé ale jednotlivé tabulky normalizovány)
- Sumarizační tabulky - obsahují předagregovaná data - v nejjednodušším případě odpovídají předagregovaná data agregování tabulky hodnot podle jedné nebo více vybraných dimenzí
Porovnání !!!
ROLAP
- Data uložena v relačních tabulkách
- Možnost získat detailní i agregovaná data
- Velké datové prostory
- Veškerý přístup k datům prostřednictvím datového skladu
- Použití komplexních SQL dotazů k získání dat ze skladu
- Datové kostky jsou vytvářeny za běhu
- Multidimenzionální pohledy vytváří prezentační vrstva
- Známé prostředí a možnost použití známých nástrojů
- Limitované použití komplexních analýz
- Omezené použití operace drill-across
MOLAP
- Data neuložena v relačních tabulkách
- Různá agregovaná data uložena v multidimenz. databázi
- Průměrně velké datové prostory
- Přístup jak do MDDB (sumy), tak do datového skladu (detailní data)
- Vytváření datových kostek předem
- Použití technologie pro ukládání multidim. dat v polích, ne tabulkách
- Technologie pro zpracování řídkých matic
- Rychlejší přístup
- Velká knihovna funkcí pro komplexní analýzu
- Snadná analýza bez ohledu na počet dimenzí
- Rozšiřující prostor pro operace drill-downa slice-and-dice
Multidimenzionální datová kostka
Definice multidimenzionální kostky
• Nechť existuje uspořádaná množina n dimenzí{D1, D2, D3, … ,Dn}
• tj. existuje relace uspořádání R ( < ) nad množinou dimenzí (např. čas, katalog, místo)
* počet různých prvků relace R je n! (počet permutací nad n, počet různých uspořádání) (čas, katalog, místo; místo, katalog, čas;...)
* je to také počet stěn n-dimenzionální kostky. Proto má 3D kostka na vrhcáby 6, tj. 3! stěn a dvoudimenzionální čtverec 2, tj. 2! stěn.
• Nechť existuje uspořádaná podmnožina aktivních dimenzí{A1, A2, A3, … ,Am}, kde m < =n,A1 =Di1, A2= Di2, A3= Di3, … ,Am= Dim a Di1 < Di2 < Di3 < … < Dim Aktivní dimenze budou uspořádány stejně jako v původní množině všech dimenzí
roll-up–(vyrolování) - vzrůst agregace a zobecnění - posun o jednu úroveň výše v uspořádání kuboidů -> snížení počtu aktivních dimenzí o 1
○ vzrůst úrovně agregace
○ Posun o jednu úroveň výše v uspořádání kuboidů
○ Vstup: uspořádaná množina m aktivních dimenzí {A1, A2, A3, … , Ai,… ,Am-1 , Am}, kde m>=1
○ Výstup: uspořádaná množina m-1aktivních dimenzí {A1, A2, A3, … ,Am}, tj. Ai bylo deaktivováno.
○ Nejčastěji se deaktivuje nejmenší dimenze Am, tj. z {A1, A2, A3, … ,Am} vznikne {A1, A2, A3, … , Am-1 }
drill-down(zavrtání) - snížení úrovně agregace a zvýšení detailu, Posun o jednu úroveň níže v uspořádání kuboidů, zvýšení počtu aktivních dimenzí o jedna
○ Vstup: uspořádaná množina m viditelných dimenzí {A1, A2, A3, … ,Am}, kde m<=n
○ Výstup: uspořádaná množina m+1aktivních dimenzí {A1, A2, A3, … , Ai,… ,Am-1 , Am}, kde Ai je vybrána z neaktivních Di tak, aby platila definice aktivních dimenzí
○ Nejčastější variantou je přidání nejmenší neaktivní dimenze na konec, tedy vznikne {A1, A2, A3, … ,Am, Am+1}
○ Pro m=n bude výsledkem detail všech hodnot
○ Je možné provést i zavrtání do základního kuboidu, neboť i jeho fakta jsou agregací detailních hodnot pro všechny aktivní dimenze
pivoting(přetočení) – změna relace R pro uspořádání dimenzí (prostě to prohážeš - “otočíš”)
○ Změna uspořádání R nad stejnou množinou dimenzí
○ Vstup: uspořádaná množina dimenzí {D1, D2, D3, … ,Dn}, kde uspořádání je jedna z možných relací R, kterých je n!
○ Výstup: uspořádaná množina dimenzí {Dx1, Dx2, Dx3, … ,Dxn} a obecně jiná relace uspořádání R(jedna z možných n!)
○ Jde o otočení jedné ze stěn kostky k sobě, proto pivoting.
slicing&dicing(seříznutí) – výběr projekce = Změna skutečné kardinality jedné nebo více dimenzí = prostě SELECT WHERE -
○ Změna skutečné kardinality jedné nebo více dimenzí
○ Vstup: uspořádaná množina dimenzí {D1, D2, D3, … ,Dn}, kde k1, k2, k3, … ,ki,…,kn jsou skutečné kardinality jednotlivých dimenzí
○ Výstup: uspořádaná množina dimenzí {D1, D2, D3, … ,Dn}a obecně jiné k1, k2, k3, … ,li,…,kn, kde ki <>li
!!! ○ Změnu lze provést výběrem, nastavením filtru ve tvaru predikátu apod. Výsledek ovlivňují i filtry neaktivních dimenzí !!!
Reprezentace multidimenzionálních dat ve 2D
- například pro tisk, zobrazení na monitoru, …
Dynamická tabulka (DT)
• od společnosti Vema
• rozdělena na sloupce dimenzí a sloupce faktů
• hierarchie dimenzí není – dimenze jsou ploché
• řádek tvoří uspořádanou n-tici dimenzních a faktových položek
• sloupce klíčů lze zaměňovat a třídit – pivoting
• zakrýváním klíčových sloupců lze zvyšovat a snižovat agregaci – roll-up, drill-down
• všechny sloupce lze zneviditelnit, případně nastavit filtry – slice & dice
• prostorově náročnější, avšak jsou vidět všechny agregační i dimenzní položky
Kontingenční tabulka (KT)
• od společnosti MS
• řádky i sloupce jsou dimenze (hierarchické)
• fakta jsou průsečíky dimenzí
• fakt je proto v zásadě pouze jediný, více faktů se v průsečíku hůře zobrazuje, řeší se to záložkami nebo více sloupci, což je nepřehledné
• dimenze lze přesunovat a zaměňovat – pivoting
• zakrýváním hierarchie dimenzí lze zvyšovat a snižovat agregaci – roll-up, drill-down
• všechny sloupce lze zneviditelnit nebo nevyužívat – slice&dice
• prostorově méně náročná, avšak nejsou vidět všechny faktové položky a hierarchie dimenzí může být nepřehledná
