DISTRIBUOVANÉ A OBJEKTOVĚ-RELAČNÍ DATABÁZE

1

DISTRIBUOVANÉ A OBJEKTOVĚ-RELAČNÍ DATABÁZE

20011/12

J. Mikulecká

DDBS - Motivace 2

Databázová technologie

Počítačové sítě

Distribuce

Integrace Distribuované databázové systémy

Integrace ≠ centralizace

Centralizovaná databáze v síti 3

Komunikační síť

Databáze je na jednom místě Centrálně řízená data Obrázek převzatý z Özsu, M.T., Valduriez, P.: Principles of Distributed Database Systems, Prentice Hall, 2.ed,1999

Distribuovaný databázový systém 4

Site 1

Site 5

Komunikační síť

Site 4

Site 2

Site 3

Distribuovaná databáze je kolekce propojených databází, distribuovaných v počítačové síti. Obrázek převzatý z Özsu, M.T., Valduriez, P.: Principles of Distributed Database Systems, Prentice Hall, 2.ed,1999

DDBMS - realita 5

Aplikace Dotazy uživatele Komunikační systém

Aplikace

Dotazy uživatele

Dotazy uživatele Obrázek převzatý z Özsu, M.T., Valduriez, P.: Principles of Distributed Database Systems, Prentice Hall, 2.ed,1999

Ideální DDBS z pohledu uživatele

Transparentní pro uživatele při zpracování dotazů, transakcích, řízení paralelního přístupu k datům. Obrázek převzatý z prezentace Valduriez, P.: Distributed Data Management in 2020?

DDBMS 7





Sestává z jedné logické databáze, která je rozdělená na několik fragmentů, které jsou rozmístěné na více propojených počítačích, z nichž každý má svůj DBMS. Každý počítač je schopný nezávisle zpracovávat požadavky uživatelů na lokální data a je schopen zpracovávat i požadavky na přístup ke vzdáleným datům.

Charakteristiky DDBMS 8

  





 

Kolekce logicky propojených sdílených dat Data rozdělená do několika fragmentů Fragmenty mohou být replikované Fragmenty/repliky jsou uložené na různých místech, spojených komunikační sítí Lokální data jsou řízena lokálním DBMS Lokální aplikace probíhají autonomně Každý DBMS participuje alespoň v jedné globální aplikaci

Paralelní DBMS 9





Databázový systém běžící na více procesorech, který je navržen tak aby realizoval operace paralelně kdykoliv je to možné, s cílem zvýšit výkonnost systému. Technologie paralelních DBMS se používá v situaci, kdy je potřebné rychle zpracovat velmi velké databáze (v řádu terabytů) Většina dodavatelů moderních DBMS dodává i paralelní verze systémů.

Homogenní vs. heterogenní DBMS 10





Homogenní systém – na každém místě v systému je použitý stejný DBMS. Heterogenní systém – na různých místech různý DBMS, případně založený i na jiném datovém modelu. Tato situace obvykle vzniká při snaze integrovat existující systémy.

1

METODOLOGIE NÁVRHU DISTRIBUOVANÉ DATABÁZE

2011/12

J. Mikulecká

Metodologie návrhu schémat v DDBS 2





V principu lze postupovat  shora–dolů (návrh začíná „na zelené louce“ – databáze se teprve plánují),  zdola-nahoru (návrh směřuje k integraci dat uložených v již existujících autonomních databázích). Návrh shora-dolů vychází z metodologií používaných v centralizovaném případě - vychází se z datových i funkčních požadavků. Zaměříme-li se na data, jde o to jak zkonstruovat globální konceptuální schéma, odpovídající externím schématům jednotlivých uživatelů a navrhnout, jak rozmístit data na jednotlivé uzly.

Architektura distribuované databáze 3

ES1

ES2

ESn

ES – externí schéma

GKS – globální konceptuální schéma

GKS

LKS1

LKS2

LKSm

LKS – lokální konceptuální schéma

LIS1

LIS2

LISm

LIS – lokální interní schéma

Popis jednotlivých hladin 4

Fyzická organizace dat v každém místě může být rozdílná – na každém místě potřebujeme popis interní schémy dat.  Celkový pohled na data v celé distribuované databázi popisuje globální konceptuální schéma.  Organizaci dat na logické úrovni v každém místě popisují lokální konceptuální schémata.  Pohledy uživatelů na data v celé distribuované databázi popisují externí schémata. 

Základní problémy návrhu DDBS 5



Fragmentace  relaci lze rozdělit na několik sub-relací, které potom distribuujeme

Alokace  každý fragment je uložený v místě s optimální distribucí  Replikace  kopii fragmentu lze udržovat na více místech 

5

Základní otázky 6

Proč fragmentovat?  Jak fragmentovat?  Jak moc fragmentovat?  Lze testovat korektnost dekompozice?  Jak alokovat?  Jaké informace jsou klíčové při rozhodování o fragmentaci a alokaci? 

6

Fragmentace 7

Pro správnou fragmentaci dat je vhodné provést kvantitativní i kvalitativní analýzu nejdůležitějších aplikací.  Kvantitativní informace mohou zahrnovat  frekvenci se kterou je aplikace spouštěna,  místo, ve kterém aplikace běží,  výkon transakcí a aplikací.  Kvalitativní informace mohou zahrnovat  přístupy k relacím, atributům a řádkům  typ přístupu (čtení/zápis). 

7

Proč fragmentovat? 8

Aplikace pracují častěji s pohledy než s kompletními relacemi.  Data jsou uložena v místě, kde se nejčastěji používají.  Data nepotřebná pro lokální aplikace se v daném místě neukládají. 

8

Proč fragmentovat? 9

Paralelizmus - tvoří-li fragmenty jednotku distribuce, tak transakce se mohou rozdělit na několik poddotazů, které mohou pracovat nad fragmenty.  Bezpečnost - data nepotřebná pro lokální aplikace nejsou v daném místě uložena. 

Je-li relace malá a nepříliš často upravovaná, tak může být vhodnější nefragmentovat. 9

Korektnost fragmentace 10

Fragmentace by měla být úplná,  rekonstruovatelná,  disjunktní. 

Úplnost Je-li relace R dekomponovaná na fragmenty R1, R2, ... Rn, tak každý element dat který se nachází v R se musí nacházet alespoň v jednom fragmentu. 10

Rekonstruovatelnost 11

Musí být možné definovat relační operaci, pomocí které lze z fragmentů rekonstruovat původní relaci R.  Horizontální fragmentace - Union  Vertikální fragmentace - Join. 

Disjunktnost Je-li prvek dat di ve fragmentu Ri, potom by se neměl objevit v žádném jiném fragmentu.  Výjimka: vertikální fragmentace, kde je nutné opakovat primární klíč z důvodu rekonstruovatelnosti. 

Horizontální fragmentace 12



Sestává z podmnožiny řádků relace: p(R) Příklad: N1 =  type=‘RodDům’ (Nemovitost)

N2 =  type=‘Byt’ (Nemovitost) N3 =  type=‘Chata’ (Nemovitost)

12

Vertikální fragmentace 13

Sestává z podmnožiny atributů relace. Je definovaná pomocí operátoru projekce: a1, ... ,an(R)



Příklad: Z1 =  cZam, pracZar, datumNarozeni, plat (Zamestnanec) Z2 = cZam, Jméno Prijmeni, cPob (Zamestnanec)

Původní relaci dostaneme pomocí operátoru přirozené spojení 13

Smíšená fragmentace 14

Sestává z horizontálního fragmentu, který je vertikálně fragmentovaný, nebo vertikálního fragmentu, který je horizontálně fragmentovaný.  Je definovaná pomocí operátorů selekce a projekce: 

 p(a1, ... , an (R)) a1, ... , an (σp(R))

14

Příklad - smíšená fragmentace 15

Máme vertikálně fragmentovanou tabulku Zaměstnanec Z1 = cZam, pracZar, datumNaroz, plat(Zaměstnanec) Z2 = cZam, Jmeno, prijmeni, cPob(Zaměstnanec) Tabulku Z2 můžeme dále horizontálně fragmentovat dle příslušnosti k pobočce: Z21 =  cPob=‘P01’(Z2) Z22 =  cPob=‘P02’(Z2) Z23 =  cPob=‘P03’(Z2) 15

Odvozená horizontální fragmentace 16

Mnoho aplikací používá přirozené spojení relací. Pokud jsou relace uložené na různých místech, spojení je náročná operace. Je proto vhodné, aby spojované relace nebo jejich fragmenty byly na témže místě. K tomu lze použít odvozenou horizontální fragmentaci.  Odvozený horizontální fragment je založený na horizontální fragmentaci rodičovské relace.  Zajišťuje, že fragmenty, které se používají často společně jsou uložené na stejném místě  Jsou definované použitím polospojení : Ri = R semijoin Si, 1iw 16

Příklad – odvozená horizontální fragmentace 17

Předpokládejme, že máme aplikaci, která používá přirozené spojení tabulek Zaměstnanec a Nemovitost, tabulka Zaměstnanec je horizontálně fragmentovaná. Z3 =  cPob =‘P03’(Zamestnanec) Z4 =  cPob =‘P04’(Zamestnanec) Z5 =  cPob =‘P05’(Zamestnanec) Můžeme použít odvozenou fragmentaci pro Nemovitost Ni = Nemovitost semijoin cZam Zi, 3  i  5 Ni obsahuje ty řádky tabulky Nemovitost, o které se starají zaměstnanci pobočky Pi 17

Alokace dat 18

Alternativní strategie vzhledem k umístění dat:  centralizované,  fragmentované,  plně replikované,  selektivně replikované.

18

REPLIKACE DAT

2011/12

J. Mikulecká

Replikace 2

Replikace je kopírování dat z databáze do více (geograficky vzdálených) míst za účelem podpory distribuovaných aplikací.  Replikuje se 

 



celá tabulka, fragment tabulky, který vznikne jako výsledek dotazu.

V 90. letech se objevily u velkých výrobců databázových systémů replikační servery, které se staly zatím nejefektivnějším přístupem k implementaci distribuovaných databází.

Vlastnosti replikace 3



DDBS založený na replikaci musí:  dopravit replikovaná data (kdekoli a kdykoli),  automaticky synchronizovat kopie po chybě,  co nejrychleji propagovat změny,  chránit transakční a logickou integritu dat,  replikovat data z (do) heterogenních serverů,  podporovat návrh aplikace, který je v souladu s pravidly podniku.

Výhody replikace 4

Replikace může zlepšit výkon a zvýšit dostupnost aplikací, protože lze použít alternativní kopii dat.  Uživatelé mohou použít lokální databázi namísto vzdáleného serveru a minimalizovat tak síťový provoz.  V případě úplného výpadku některých částí distribuované databáze mohou být kopie stále přístupné.  Poskytují uživatelům lokální aktualizované kopie dat. 

Problémy replikace 5

Jak se rozhodneme kolik kopií udržovat?  Čím více kopií vytvoříme, tím je náročnější úprava dat, ale tím efektivnější jsou dotazy.  Jak udržíme kopie v identickém stavu?  Co se stane, je-li porucha na síti a různé kopie v síti mají možnost samostatného vývoje? Jak data po odstranění poruchy sjednotíme?  V důsledku distribuce dat se může stát, že transakce zahrnují více míst. Co se stane, když jedna komponenta transakce bude chtít transakci zrušit a jiná bude chtít transakci řádně ukončit? 

Příklad 6

Předpokládejme, že máme tabulku R, ke které přistupujeme z n míst. N-té místo vyšle za sekundu qi dotazů na R a ui požadavků na změnu dat v tabulce R.  Cena dotazu = d, pokud je dotaz vyslán ze stejného místa v síti, ve kterém je umístěna tabulka R. = 10d, pokud je dotaz vyslán z jiného místa v síti než je umístěna tabulka R.  Cena změny = z, pokud je změna požadována ze stejného místa = 10z, pokud je změna požadována z jiného místa v síti než je umístěna tabulka R.

Příklad - výsledek 7



Jak na základě daných parametrů rozhodnete, na která místa v síti se má tabulka R replikovat? Optimální místa pro umístění replik jsou ta, pro které platí vztah: 9dqi + 9zui ≥ Z Z je cena všech změn dat požadovaných z každého místa v síti na data umístěná na jiném místě: Z= 10zui Preferujeme místa, ve kterých probíhá hodně aktivit, ale čím větší je frekvence požadovaných změn, tím méně replik vytvoříme.

Příklad – ilustrace – pouze 2 místa 8

Místo 1 Dotazy lokální:  Cena dotazu d  Frekvence dotazů q1 Změny lokální Celková cena=z*u1  Cena změny z  Frekvence změn u1

R

Pokud vytvoříme repliku R, tak obě operace budou probíhat lokálně a úspora je 9dq2+9zu2 Místo 2 neobsahuje R Dotazy na jiné místo v síti:  Cena dotazu 10d  Frekvence dotazů q2 Změny na jiném místě v síti  Cena změny 10z  Frekvence změn u2

R

S

Příklad – řešení (pokračování) 9









Tím, že jsme vytvořili repliku tabulky R v místě 2, tak zlevnily dotazy i aktualizace dat v tabulce R; musíme ale udržovat repliku synchronizovanou. Synchronizace vyžaduje propagovat všechny změny v tabulce R realizované v místě 1 na místo 2 a obráceně. Náklady Z na propagaci změn jsou dané vzorcem: Z = 10zu1 +10zu2 Úspora ze zavedení replik by měla převýšit náklady, potřebné na synchronizaci replik, proto repliku tabulky R by bylo vhodné vytvořit v případě, že platí 9dq2 + 9zu2 ≥ Z

Formy replikace 10

Podle místa kde začíná aktualizace  centralizované – aktualizace může začínat pouze v jednom místě (master-slave),  distribuované (aktualizace může začít kdekoliv).  Podle šíření aktualizace (propagace změn)  synchronní probíhá současně s vkládáním dat – replikace je vlastně součástí transakce  asynchronní probíhá pokud nastane nějaká událost (metoda pull nebo push). 

Synchronní replikace 11



 

Změny se propagují v rámci transakce, realizující změny. Požadované vlastnosti transakcí (ACID) platí pro úpravy na všech místech. Po řádném ukončení aktualizace obsahují všechny repliky stejné hodnoty. ROWA protokol: Read-one/Write-all Nevýhody – transakce může být řádně ukončena až po provedení všech změn.

Transakce updates commit

 

 Site 1

Site 2

Site 3

Site 4

Obrázek převzatý z prezentací ke knize Özsu, M.T., Valduriez, P.: Principles of Distributed Database Systems, Springer, 3.ed, 2011

Asynchronní replikace 12



 

Asynchronní replikace nejdříve vykoná aktualizaci na jednom místě (master, primary copy). Poté, co transakce skončí jsou změny propagovány na ostatní kopie. Tj. transakce nečeká na ukončení propagace změn, ale je ukončena ihned po realizaci změn na primární kopii. Repliky můžou být po určitý čas v nekonzistentním stavu. Úprava dat na primární kopii je rychlejší.

Transakce

updates commit





Site 1



Site 2

Site 3

Site 4


Centralizované repliky 13

Pouze jedna kopie může být upravována (primary, master), všechny ostatní (slaves) jsou upravovány na základě dat v master kopii.

Site 1

Site 2

Site 3

Site 4

Site 1

Site 2

Site 3

Site 4


Distribuované repliky 14

Změny mohou být iniciovány na libovolné replice. Každé místo, ve kterém je umístěná replika, může upravovat data. Transakce updates commit

Site 1

Site 2

Site 3

Site 4 Transakce updates commit

Site 1

Site 2

Site 3

Site 4


Formy replikace 15

+ + + −

Synchronní Všechny kopie jsou konzistentní (identické) Lokální kopie poskytují aktuální data Změny jsou atomické Transakce musí upravit všechny repliky  Delší čas potřebný pro realizaci změn  Nízká dostupnost

+ + −

− −

Asynchronní Transakce je vždy lokální (rychlá odezva) Data jsou po určitý čas nekonzistentní Lokální kopie nemusí mít vždy aktuální data Změny na všech kopiích nejsou vždy garantovány Replikace není transparentní

+ +

− −

Centralizovaná Není nutná synchronizace míst (probíhá na master kopii) Vždy existuje jedno místo, kde jsou zaznamenány všechny změny Zatížení master kopie může být vysoké Lokální kopie nemusí mít vždy aktuální data

Distribuovaná + V každém místě může probíhat transakce + Zátěž je rozložená rovnoměrně − Kopie je nutné synchronizovat

Replikační protokoly 16

Předchozí přístupy lze skombinovat do 4 různých replikačních protokolů:

Synchronní

Synchronní centralizované

Synchronní distribuované

Asynchronní

Asynchronní centralizované

Asynchronní distribuované

Centralizované

Distribuované

Replikační strategie

Synchronní

17

+ Změny nemusí být koordinované + Nenastávají inkonzistence - Delší čas odezvy - Užitečné pokud potřebujeme málo úprav - Lokální kopie jsou pouze ke čtení

+ Není potřebná koordinace + Krátký čas odezvy - Lokální kopie nejsou aktuální - Inkonzistence

Centralizované

+ Nenastávají inkonzistence + Elegantní (symetrické řešení) - Dlouhý čas odezvy - Úpravy musí být koordinované

+ Není centrální koordinace + Krátký čas odezvy - Inkonzistence - Úpravy mohou být ztraceny

Distribuované

Využití replikace 18

distribuce dat na síťové servery, včetně mobilních a připojených jen příležitostně  sjednocení dat s centrálním serverem  rozdělení procesu na více než jeden server  informační tok z jednoho serveru na další  sdílení dat mezi více místy 

V praxi je také nutno rozhodnout, zda všechny pobočky potřebují aktuální informace, nebo zda některým stačí třeba informace ze včerejšího dne. Musíme posoudit, kdo a kdy potřebuje které informace, kdo a kdy je aktualizuje a kdo a kdy je vytváří.

1

REPLIKACE V MS SQL SERVERU

J.Mikulecká FIM UHK, 2014/15

Zdroje: MS SQL 2012 help Meine, S.: Fundamentals of SQL Server 2012 Replication, Simple Talk Publishing, 2013

Princip replikace v MS SQL serveru 2

Převzato z knihy Meine, S.: Fundamentals of SQL Server 2012 Replication, Simple Talk Publishing, 2013

Základní pojmy (1) 3

 Článek

(article) - základní jednotka replikace – databázová tabulka nebo její část, která může být replikována.  Publikace (publication) - kolekce článků – různá nebo stejná pro různé odběratele. Články je nutné nejprve přiřadit určité publikaci, kterou lze následně replikovat.  Přihlášení k odběru (subscription) – požadavek, aby kopie publikace byla doručena k odběrateli (subscriber).

Základní pojmy (2) 4

Odběratel (Subscriber) – databáze, která může obdržet replikovaná data. Sama může také data upravovat a předávat je zpět vydavateli. Data mohou být publikována na více odběratelů.  Vydavatel (Publisher) – databáze, která umožňuje replikovat publikaci. Definuje data, jež mohou být zasílána na místo typu odběratel. Jsou na nich dále zaznamenány změny v datech a jiné informace o zdrojových databázích.  Distributor - Tyto servery zajišťují distribuci replikovaných dat. Je na nich uložena distribuční databáze, metadata, historická data a případně transakce. Jedna instance DBS může fungovat jako vydavatel i distributor (lokální distributor). 

Subscription 5

(předplatné) je požadavek na kopii dat a databázových objektů v publikaci.  Subscription definuje, které publikace, kam a kdy budou obdrženy.  Typ předplatného určuje, kde poběží odpovídající replikační agent (na distributorovi nebo na odběrateli).  Po vytvoření subscription není možné změnit jeho typ.  Subscription

Push subscription 6

 Vydavatel

propaguje změny na odběratele bez obdržení požadavku. Změny mohou být protlačeny (push) odběrateli na žádost, kontinuálně nebo podle předdefinovaného plánu.  Použití: Data budou typicky synchronizována kontinuálně nebo pomocí periodicky opakovaného plánu.  Publikace požadují přesun dat téměř v reálném čase.  Vyšší zátěž procesoru na distributorovi neovlivňuje výkon systému.  Velmi často používané se snímkovou a transakční replikací. 

Pull subscription 7

 Odběratel

požaduje změny provedené na vydavateli. Uživatel působící na odběrateli má možnost určit, kdy budou změny dat synchronizovány.  Použití: Data budou typicky synchronizována na žádost nebo prostřednictvím plánu než kontinuálně.  Publikace mají velké množství odběratelů a/nebo provoz všech agentů na distributorovi by byl příliš náročný na zdroje.  Odběratelé jsou autonomní, odpojení a/nebo mobilní.  Odběratelé určují, kdy se připojí a synchronizují změny.  Nejčastěji používaná pro slučovací replikace. 

Agenti replikace 8

Replikace funguje vně modulu systému SQL Server na základě sady spustitelných souborů zvaných agenti replikace. Modul replikace je vlastně jiná aplikace, která se připojuje k systému SQL Server a zpracovává data. Protože se jedná o aplikaci, musí se modul replikace chovat stejným způsobem jako libovolná jiná aplikace, která navazuje připojení OLE DB k systému SQL Server.  Agenti replikace jsou samostatné programy umožňující přenášení změn a distribuci dat - například  Snapshot agent  Distribution agent  Merge agent  Log reader agent

Agent snímků (Snapshot agent) 9

agent je tvořen programem Snapshot.exe a je využíván pro všechny typy replikací.  Odpovídá za extrakci schématu a dat, které je nutné odesílat od vydavatele k odběrateli. Při inicializaci snímku extrahuje Snapshot agent schéma a hromadně zkopíruje data do složky snímků. Po extrakci schématu a všech dat je Snapshot agent ukončen.  Snapshot agent běží na serveru typu Distributor.  Snapshot

Agent distribuce 10

agent se používá při snímkové a transakční replikaci. Plní dvě funkce: aplikuje snímky a odesílá transakce.  Zajišťuje, že všechny snímky generované pomocí snímkové nebo transakční replikace jsou aplikovány u každého odběratele. Odpovídá také za použití všech transakcí zapsaných do distribuční databáze Logreader agentem.  Distribuční agent může běžet buď na serveru typu Subscriber (pull subscription) nebo Distributor (push subscription).  Distribution

Agent slučování 11

agent (Replmerg.exe) je využíván při slučované replikaci.  Aplikuje snímek generovaný při inicializaci odběratele. Stará se také o výměnu transakcí mezi vydavatelem a odběratelem.  Každý požadavek na sloučení má vlastního agenta, který se připojí jak na Publisher server tak na Subscriber server a u obou provede odpovídající změny.  Standardně Merge agent nejprve nahraje změny z odběratele na vydavatele a pak provede download změn zpět z vydavatele na odběratele.  Merge

Agent čtení protokolu 12

Log reader agent tj. program Logread.exe slouží pouze pro transakční replikaci.  Umožňuje z transakčního protokolu vydavatele extrahovat potvrzené transakce, které je nutné replikovat. Po extrakci zajišťuje, že je každá transakce znovu zabalena a zapsána do distribuční databáze v přesně stejném pořadí v jakém byly transakce zadány na straně vydavatele. Řazení má zásadní význam, protože transakce nemohou být u odběratele aplikovány v nesprávném pořadí.  Každá databáze publikovaná pomocí transakční replikace má tento typ agenta, jež běží na distributorovi a připojuje se k vydavateli. 

Typy replikace v MS SQL serveru 13

 Snímková

replikace (snapshot replication),  slučovaná replikace (merge replication),  transakční replikace (transaction replication). Volba typu replikace v MS SQL Serveru je závislá na mnoha faktorech. Mezi ně patří mimo jiné prostředí fyzické replikace, typ a množství dat určených k replikaci a také to, zda budou data aktualizována na odběrateli. Fyzické prostředí zahrnuje počet a umístění počítačů zapojených do replikace a také to, zda se jedná o klienty nebo servery.

Replikace dat mezi servery 14

Je vhodná hlavně z následujících důvodů: Zvýšení škálovatelnosti a dostupnosti - udržování soustavně aktualizovaných kopií dat umožňuje rozložení procesu čtení na více serverů.  Datové sklady a reportování - replikace usnadňují přesun dat mezi OLTP servery a systémy pro vytváření reportů, resp. systémy pro podporu rozhodování.  Integrace dat z více míst - data jsou často dolována ze vzdálených míst a slučována do centrálního sídla. Podobně mohou být data replikována na vzdálená místa.  Integrace heterogenních dat - některé aplikace pracují s daty z jiného databázového systému než je SQL Server. 

Replikace dat mezi serverem a klienty 15

Je vhodná pro podporu následujících aplikací:  Výměna dat s mobilními uživateli - některá data musí být přístupná vzdáleným uživatelům. Jedná se např. o prodejce, doručovatele, bankovní poradce apod.  Pokladní systémy pro spotřebitele - jedná se například o odbavovací terminály, které vyžadují replikaci ze vzdálených míst na centrální sídlo.  Integrace dat z více míst - ve většině případů se jedná o aplikace podporující regionální pobočky.

Snímková replikace 16

Každá replikace typicky začíná synchronizací publikovaných objektů mezi vydavatelem a odběrateli. Tato inicializační synchronizace může být provedena replikací snímků (snapshots), což je kopie všech objektů a dat specifikovaných publikací. Poté, co je vytvořen snímek, je dopraven odběratelům.  Pro některé aplikace je snímková replikace dostatečná např. když  změny dat nejsou časté,  je přijatelné aby po určitý čas data nebyla synchronizována s vydavatelem. Zdroj: Help MS SQL 2012

Slučovaná (merge) replikace 17



 

Používá se zejména v prostředí klient-server a hodí se zejména pro mobilní zpracování off-line. Umožňuje, aby replikovaná data upravoval vydavatel i předplatitel. Modifikuje schéma publikační databáze:  





Identifikuje/přidá primární klíč v replikovaných tabulkách Vytvoří triggery pro replikované tabulky na sledování změn v tabulkách Přidá několik systémových tabulek

Je vhodná pro následující situace:  Více předplatitelů potřebuje upravovat stejná data v různém čase a tyto změny potřebuje propagovat na vydavatele a ostatní předplatitele.  Předplatitelé potřebují obdržet data, upravit je off-line a poté synchronizovat změny s vydavatelem a ostatními předplatiteli.  Každý předplatitel vyžaduje jinou fragmentaci dat.  Replikace typu merge umožňuje, aby různá místa pracovala autonomně a poté sloučila úpravy.

Slučovaná (merge) replikace: agenti replikace a triggery 18

→ směr zápisu dat → čtení dat Při inicializaci přečte Snapshot agent z publikační databáze schéma a hromadně zkopíruje data do složky snímků. Merge agent dopraví snímek do databáze předplatitele. Triggery zaznamenávají změny, které proběhly po inicializaci. Merge agent změny aplikuje na předplatitele i na vydavatele

Převzato z knihy Meine, S.: Fundamentals of SQL Server 2012 Replication, Simple Talk Publishing, 2013

Transakční replikace 19

 Používá

se zejména v prostředí server-to-server a je vhodná pro následující případy: Potřebujeme, aby postupné změny byly průběžně propagovány na předplatitele.  Aplikace vyžaduje, aby byla pouze malá prodleva mezi změnami na vydavateli a na předplatiteli.  Vydavatel má velký objem operací INSERT, UPDATE a DELETE.  Vydavatel nebo předplatitel jsou jiné databáze než SQL server – např. Oracle. 

 Implicitně

se předplatitel považuje za read-only.

Transakční replikace: konfigurace agentů replikace 20

→ směr zápisu dat → čtení dat Při inicializaci přečte Snapshot agent z publikační databáze schéma a hromadně zkopíruje data do složky snímků. Distribution agent dopraví snímek na předplatitele. Log reader agent čte z transakčního protokolu vydavatele potvrzené transakce, které je nutné replikovat. Po extrakci zajišťuje, že je každá transakce znovu zabalena a zapsána do distribuční databáze v přesně stejném pořadí v jakém byly transakce zadány na straně vydavatele. Distribuční agent přečte změny v distribuční databázi a aplikuje je na předplatiteli. Převzato z knihy Meine, S.: Fundamentals of SQL Server 2012 Replication, Simple Talk Publishing, 2013

Správa replikačních služeb 21

 MS

SQL Server nabízí několik možností správy replikačních služeb, mezi něž patří  nástroj SQL Server Management Studio,  programovací rozhraní a  další komponenty systému MS Windows.

SQL Server Management Studio 22

Obsahuje grafické znázornění organizace replikačních objektů, které pomáhá při vytváření a správě kompletního replikačního prostředí. Ve speciální složce Replication lze spouštět následující podpůrné programy:  Replikační průvodci a listy s nastavením - umožňují konfigurovat publikace a subscription a měnit jejich vlastnosti.  Replikační monitor - poskytuje systémový pohled na replikační činnost, zaměřujíc se na pohyb dat mezi vydavatelem a odběrateli. Jedná se o nástroj pro sledování aktivity v reálném čase, řešení problémů a analýzu uplynulé replikační činnosti.  Zobrazovač konfliktů - pomáhá zobrazit a vyřešit konflikty vzniklé během synchronizace.

Replication Programming Interface 23

 Jako

alternativu SQL Server Management studiu lze použít uložené procedury replikačního systému a spouštěcí soubory replikačních agentů.  Tyto prostředky jsou dobře dokumentovány a připraveny jako metody pro použití do dávkových souborů nebo skriptů.  Výhodou použití skriptů pro konfiguraci replikací a vytváření publikací i předplatitelů je možnost generovat skript pomocí SQL Server Management studia a spustit ho na ostatních serverech, což je mnohem rychlejší než definování replikací na každém serveru ručně.

INTEGRACE DAT

2011/12

Zdroj: H. Garcia-Molina, J.D.Ullman, J.Widom: Database systems the Complete Book, 2009, chapter 21

Integrace informací 2

 Integrace

informací je proces, při kterém vezmeme několik databází nebo jiných zdrojů informací a umožníme, aby se k datům přistupovalo jako kdyby byla uložena v jedné databázi.  Zdroje mohou být tradiční databáze, ale může to také být například kolekce informací na webu.  Integrovaná databáze může být  fyzická (datový sklad),  virtuální (mediátor - prostředník, nad kterým lze realizovat dotazy aniž by fyzicky existoval).

Problémy 3

Již existující databáze  nelze měnit jejich strukturu  Nekompatibilita různého druhu i mezi zdánlivě velmi podobnými databázemi:  lexikální – sloupec stejného významu může být v různých databázích různě pojmenován,  v interpretaci dat – například číselný údaj udávající teplotu může vzbudit pochybnosti, zda je to v 0C nebo 0 F  sémantická – je význam např. tabulky Zaměstnanci stejný? Někdo může být zaměstnán v HPP, jiný na DPČ nebo na DPP – je to řešeno v různých databázích stejně? 

Přístupy k integraci informací 4

Federativní databáze:  zdroje jsou nezávislé, ale každý může realizovat dotazy nad ostatními zdroji  Datové sklady:  Kopie dat (většinou vhodně upravené) z různých zdrojů jsou uloženy v jedné databázi a periodicky aktualizované (často v noci).  Mediátor – podporuje pohledy které integrují několik zdrojů velmi podobným způsobem jako materializované pohledy. Protože ale mediátor nemá žádná vlastní data, musí relevantní data získat z původních zdrojů. 

Federativní databáze 5

Wrapper Wrapper Wrapper

Wrapper

Wrapper Wrapper

Wrapper (adaptér) transformuje příchozí dotazy a odchozí odpovědi.

Federace - charakteristiky 6

 Nejjednodušší

architektura  Je potřebné implementovat propojení mezi každými dvěma databázemi, pokud si mají vzájemně poskytovat data.  Toto propojení umožňuje, aby jeden DBS vznášel dotazy na data druhého DBS.  Pokud každá z n databází v systému potřebuje přistupovat k datům ostatních databází, tak potřebujeme implementovat n(n-1) částí kódu na podporu dotazů.

Federace - příklad 7

Automobilka má mnoho dealerů a každý z nich si udržuje svoji vlastní relační databázi automobilů, které má na skladě. Bylo rozhodnuto, že databáze dealerů se budou integrovat, aby každý dealer měl možnost v případě potřeby zjistit, zda požadovaný model nemá na skladě některý z dealerů v blízkosti.  Struktura jednotlivých databází je ale rozdílná:  Dealer1 používá pouze jeden soubor VOZIDLA(Cislo, Model, Barva, AutPrevod) kde AutPrevod jenom indikuje zda ano či ne.  Dealer2 používá dva soubory AUTA(SerioveC, Model, Barva), VYBAVA(SerioveC, Popis) 

Příklad – pokračování 8

 Aby

Dealer1 mohl přistupovat k datům Dealera2, potřebuje adaptovat dotazy na strukturu Dealera2.  Předpokládejme, že Dealer1 potřebuje získat informace o autech specifikovaných v tabulce PozadovanaVozidla(Model, Barva, AutPrevod) V principu bude kód v T-SQL realizující dotaz na Dealera2 následující: Pro každý řádek hodnot @Model, @Barva, @AutPrevod v tabulce PozadovanaVozidla budeme potřebovat dotaz

Příklad - pokračování 9

if @AutPrevod = 1 Begin USE Dealer2 SELECT Auta.SerioveC FROM Auta JOIN Vybava ON Auta.SerioveC=Vybava.SerioveC WHERE Vybava.Popis='AutPrevod' AND Auta.Model=@model AND Auta.Barva=@barva END ELSE


BEGIN USE Dealer2 SELECT Auta.SerioveC FROM Auta WHERE Auta.Model = @model AND Auta.Barva = @barva AND not EXISTS ( SELECT * FROM VYBAVA WHERE SerioveC = Auta.SerioveC AND popis= 'AutPrevod') END

Datový sklad 11

Warehouse

Wrapper

Wrapper

Source 1

Source 2

Datový sklad 12

V datovém skladu se při integraci dat z různých zdrojů vytváří globální schéma. Data se poté uloží v datovém skladu, který vypadá stejně jako standardní databáze. Jsou-li již data ve skladu, tak dotazy se realizují obvyklým způsobem.  Aktualizace datového skladu se dělá obvykle jedním ze dvou způsobů:  Celý datový sklad se vytvoří znovu z aktuálních dat; v té době je sklad pro dotazy nepřístupný.  Datový sklad se periodicky upravuje na základě změn v původních databázích, které nastaly od poslední aktualizace skladu. Tento přístup pracuje s menším objemem dat, je ale výrazně složitější. 

Příklad – vytvoření datového skladu 13

Uvažujme opět předchozí příklad, kde  Dealer1  VOZIDLA(Cislo, Model, Barva, AutPrevod)  Dealer2  AUTA(SerioveC, Model, Barva), VYBAVA(SerioveC, Popis)  Máme vytvořit datový sklad s následujícím globálním schématem:  AUTA_SKLAD(SerioveC, Model, Barva, AutPrevod, Dealer)

Příklad – vložení dat do datového skladu 14

Kód, který vloží data do datového skladu může vypadat následovně:  Vložení dat z databáze Dealera1: INSERT INTO AUTA_SKLAD(SerioveC, Model, Barva, AutPrevod, Dealer) SELECT Cislo, Model, AutPrevod, ‘Dealer 1’ FROM Vozidla Data Dealera1 lze v tomto případě rovnou přidat do datového skladu; často se ale požaduje před přidáním dat do skladu spojení relací nebo výpočet různých agregačních funkcí.

Příklad – vložení dat do datového skladu 15

Vložení dat z databáze Dealera2: INSERT INTO Auta_DWH (SerioveC, Model, Barva, AutPrevod, Dealer) SELECT AUTA.SerioveC, Model, Barva, 1 AutPrevod, 'Dealer2' Dealer FROM AUTA WHERE EXISTS (SELECT * FROM Vybava WHERE Vybava.SerioveC = Auta.SerioveC AND Popis='AutPrevod') UNION SELECT Auta.SerioveC, Model, Barva, 0, 'Dealer2' FROM Auta WHERE NOT EXISTS (SELECT * FROM Vybava WHERE Vybava.SerioveC = AUTA.SerioveC AND Popis='AutPrevod')

Mediátor 16

Result

User query

Mediator

Query

Result Result

Wrapper

Query

Result

Source 1

Query Wrapper

Query

Result

Source 2

Mediátor - charakteristika 17









Mediátor je založen na vytvoření množiny pohledů, které integrují několik zdrojů velmi podobným způsobem jak je tomu u datového skladu; mediátor ale neukládá žádná data. Proto je mechanizmus mediátorů a datových skladů rozdílný. Uživatel adresuje dotaz na mediátora; ten musí získat data z původních zdrojů (protože sám žádná data nemá) a použít je (zkombinovat) na vytvoření odpovědi. Mediátor může poslat i více dotazů na některé wrappery, ale nemusí se vždy dotazovat všech. Postup může být i takový, že nejdříve vyhodnotí výsledky dotazu na podmnožinu zdrojů a až poté případně pokračuje v dotazovaní dále. Wrapper musí být schopen přijímat různorodé dotazy od mediátora a adaptovat je na dotazy nad strukturami zdrojů.

Vytváření adaptérů (wrapperů) 18

V systémech založených na mediátorech jsou potřebné mnohem složitější adaptéry než v systémech pro datové sklady.  Systematický přístup k vytváření adaptérů vychází z určité klasifikace očekávaných dotazů a vytváří šablony dotazů s parametry.  Mediátor poskytuje potom do šablony dotazu příslušnou konstantu a adaptér potom realizuje dotaz s touto hodnotou. Počet šablon dotazů může nepřiměřeně narůstat; existují metody zjednodušení, které jsou založeny na tom, že přidávají wrapperům více schopností – např. wrappery umí filtrovat data nebo kombinovat různé šablony. 

Uživatelsky definované funkce 19

Pohledy neumožňují pracovat s parametry; lze ale využít uživatelsky definované funkce:  buď přímé tabulkové (inline-table-valued) funkce  nebo vícepříkazové tabulkové (multi-statement table-valued) funkce.  Přímá tabulková funkce vrací sadu výsledků na základě jediného příkazu SELECT, jímž se definují vracené řádky a sloupce.  Na rozdíl od uložené procedury se na přímou UDF dá odkazovat v klauzuli FROM dotazu, nebo ji spojit s jinými tabulkami.  Přímá UDF může přebírat parametry. 

Uživatelsky definované funkce 20

 Vícepříkazová

tabulková UDF také vrací sadu výsledků a lze se na ni odkazovat v klauzuli FROM dotazu. Není ale limitovaná jediným příkazem SELECT v těle funkce.  UDF mají dobrý výkon, protože jejich plány vykonání se ukládají do cache, aby se mohly opětovně využívat.

Příklad 21



Uvažujme opět příklad s dealery aut - mediátor integruje stejné zdroje jako v případě datového skladu: 



AUTA_MEDIATOR(SerioveC, Model, Barva, AutPrevod, Dealer)

Předpokládejme, že uživatel položí dotaz na mediátora

SELECT SerioveC, Model, Barva, AutPrevod, Dealer FROM AUTA_MEDIATOR WHERE barva = ‘Zelená’ 

Mediátor v reakci na tento dotaz položí stejný dotaz na wrapper jedné i druhé databáze.



Příslušný wrapper adaptuje dotaz na strukturu základní databáze a vrátí výsledky mediátoru.

Dotaz na Dealera1 v T-SQL 22

CREATE FUNCTION GetAuta1_barva(@barva varchar(20)) RETURNS @NalezenaVozidla TABLE (Cislo char(10), Model char(10), Barva varchar(20) , AutPrevod bit, Dealer varchar(10) ) BEGIN Insert @NalezenaVozidla Select Cislo, Model, Barva, AutPrevod, ‘Dealer1' FROM Vozidla WHERE barva=@barva RETURN END Použití UDF: select * from GetAuta1_barva('Zelená')


V

dalším kroku mediátor pošle dotaz adaptovaný na strukturu databáze Dealera2.  Nakonec mediátor vytvoří sjednocení výsledku obou dotazů a předá výsledek uživateli.

DISTRIBUOVANÉ DOTAZY

2014/15

Zdroje: Connoly, T., Begg, C.: Database Systems, Pearson Education, 2009

Özsu, M.T., Valduriez, P.: Principles of Distributed Database Systems, Springer, 2011

Dotazy v centralizovaných systémech Příklad:

EMP(ENO, ENAME, TITLE) ASG(ENO, PNO, RESP, DUR) SELECT ENAME FROM EMP, ASG WHERE EMP.ENO = ASG.ENO AND RESP = ʹManagerʹ Procesor dotazů vyjádří dotaz prostřednictvím RA. Strategie 1 ENAME(RESP=ʹManagerʹEMP.ENO=ASG.ENO(EMP×ASG)) Strategie 2  ENAME(EMP ⋈ENO (RESP=ʹManagerʹ (ASG))

Zpracování dotazů v distribuovaném prostředí 3

V centralizovaném systému stačí využít transformační pravidla relační algebry a transformovat dotaz do ekvivalentního tvaru o kterém víme, že je efektivnější.  V distribuovaném prostředí musíme ještě určit, na kterém místě budou data zpracována a případně v jakém pořadí budou přenášena.  Příklad: Předpokládejme, že tabulky EMP a ASG jsou horizontálně fragmentovány takto:  EMP1=σENO≤“E3“ (EMP); EMP2=σENO>“E3“ (EMP)  ASG1=σENO≤“E3“ (ASG); ASG2=σENO>“E3“ (ASG) Fragmenty EMP1, EMP2, jsou uloženy v místech 1, 2 a fragmenty ASG1, ASG2 v místech 3, 4. Výsledek se očekává v místě 5. 

V čem je problém? 4

Site 1

Site 2

EMP1= σENO≤ʹE3ʹ(EMP) EMP2= σENO>ʹE3ʹ(EMP)

Site 3

Site 4

ASG1=σENO≤ʹE3ʹ(ASG)

Site 5

ASG2= σENO>ʹE3ʹ(ASG)

Výsledek

DOTAZ: EMP ⋈ENO (RESP=“Manager” (ASG)) nad distribuovanou databází Strategie 1

Strategie 2

Site 5 result  EMP1'  EMP2'

Site 3

EMP1'

EMP’1=EMP1 ⋈ENO ASG’1

Site 1 ASG’1=бRESP=ʹManagerʹ ASG1

result= (EMP1  EMP2)⋈ENOσRESP=ʹManager” (ASG1  ASG2)

EMP2'

Site 4

ASG1

EMP’2=EMP2 ⋈ENO ASG’2

ASG 1'

Site 5

ASG '2

Site 2 ASG '2  σ RESP "Manager"ASG 2

ASG2

Site 1 Site 2

EMP1

Site 3

EMP2

Site 4

Náklady na realizaci dotazů 5



Předpokládejme že data jsou rovnoměrně rozdělena mezi místa v síti a platí: 

  



Strategie 1    



Počet řádků (EMP) = 400, počet řádků (ASG) = 1000 Počet managerů v tabulce ASG = 20 Cena přístupu k řádku = 1 jednotka Cena přenosu 1 řádku = 10 jednotek vytvoření ASG': (10+10)  cena přístupu k řádku přenos ASG' na místo kde je EMP: (10+10)  cena přenosu řádku vytvoření EMP': (10+10)  cena přístupu k řádku  2 přenos EMP' na místo 5: (10+10)  cena přenosu řádku Cena celkem

20 200 40 200 460

Strategie 2

přenos EMP na místo 5: 400  cena přenosu řádku přenos ASG na místo 5: 1000  cena přenosu řádku vytvoření ASG': 1000  cena přístupu k řádku Vytvoření spojení EMP a ASG': 400  20  cena přístupu k řádku Cena celkem Závěr: Strategie 1 je 50 krát lepší než strategie 2.    

4 000 10 000 1 000 8 000 23 000

Metodologie zpracování distribuovaných dotazů 6

Cíl: Transformovat SQL dotaz nad globálními relacemi do posloupnosti databázových operací nad fragmenty.

SQL dotaz

Dekompozice dotazu Algebraický dotaz na distribuované relace

Lokalizace dat

Optimalizátor musí nalézt nejlepší místo pro zpracování dat a určit, v jakém pořadí se budou výsledky v síti přenášet.

GLOBÁLNÍ SCHÉMA

SCHÉMA FRAGMENTACE

Dotaz nad fragmenty Globální optimalizace

STATISTIKY

Optimalizovaný dotaz nad fragmenty Lokální optimalizace

Optimalizované lokální dotazy

LOKÁLNÍ SCHÉMATA

Dekompozice dotazu 7

V

této vrstvě se aplikují optimalizační metody používané v centralizovaných systémech, jejichž základem je vyjádření dotazu ve formě stromu dotazu.  Postup při vytváření stromu dotazu:  Pro každou relaci v dotazu se vytvoří list.  Pro každou relaci vytvořenou operací relační algebry se vytvoří uzel.  Kořen reprezentuje výsledek dotazu.  Posloupnost vykonávání kroků je od listů ke kořeni.

Příklad: strom dotazu 8

SELECT * FROM Staff S, Branch B WHERE S.BranchNo=B.BranchNo AND (S.Position=‘manager’ AND B.City=‘London’)

Poznámka: Symbol ⋈ představuje operátor spojení

Proces dekompozice 9

V

procesu dekompozice se dotaz  normalizuje kvůli jednodušší manipulaci  sémanticky analyzuje  zjednoduší (eliminují se redundantní podmínky)  vyjádří jako algebraický dotaz  Výsledkem je částečně optimalizovaný dotaz, který lze vyjádřit v určité formě stromu dotazu nad globálními relacemi.

Normalizace dotazu 10

 Konvertuje

dotaz do normalizovaného tvaru. Predikát (v SQL podmínka WHERE) může být konvertován do konjunktivní nebo disjunktivní normální formy.  Konjunktivní normální forma je konjunkce () disjunkcí () (p11  p12  …  p1n)  …  (pm1  pm2  …  pmn)  Disjunktivní normální forma je disjunkce () konjunkcí () (p11  p12  …  p1n)  … (pm1  pm2  …  pmn)  Konjunktivní normální forma je „praktičtější“ – podmínky obvykle obsahují více AND než OR.

Příklad 11

 Konjunktivní

normální forma

(Position = ‘Manager’Salary>50000)  BranchNo=‘B003’  Disjunktivní

normální forma

(Position = ‘Manager’  BranchNo = ‘B003’)  (Salary>50000  BranchNo = ‘B003’)

Zjednodušení 12

Cílem zjednodušení dotazu je transformovat dotaz do sémanticky ekvivalentního tvaru, se kterým se lépe manipuluje.  Na normální formy lze aplikovat známá pravidla idempotence boolovské algebry: ppp ppp p  false  false p  false  p p  true  p p  true  true p  (p  q)  p p  (p  q)  p  Tato pravidla lze využít k eliminaci redundantních podmínek. 

Příklad: Zjednodušení dotazu 13

Zjednodušte následující dotaz použitím pravidel idempotence. SELECT ENO FROM ASG WHERE RESP = ʹAnalystʹ AND NOT(PNO=ʹP2ʹ OR DUR=12) AND PNO = ʹP2ʹ AND DUR=12 

ENO (бRESP=ʹAnalystʹ Λ ¬(PNO= ʹP2 ʹ V DUR=12)

Λ PNO= ʹP2ʹ ∧ DUR=12) ASG

Negaci první závorky můžeme rozepsat: ¬(PNO= ʹP2ʹ V DUR=12) ≡¬ (PNO= ʹP2ʹ) Λ ¬ (DUR=12) a dostaneme: ¬ (PNO= ʹP2ʹ) Λ ¬ (DUR=12) Λ PNO=ʹP2ʹ∧ DUR=12 – podmínka je FALSE – a výsledek dotazu je prázdná množina

Optimalizace dotazu 14

 Cílem

optimalizace dotazu je transformovat dotaz do sémanticky ekvivalentního, ale efektivnějšího tvaru.  Pro optimalizaci se používají transformační pravidla relační algebry, která optimalizátoru umožní transformovat výraz relační algebry do tvaru, o němž je známo, že je efektivnější.

Složitost operátorů relační algebry 15

Složitost operátorů je relativní k počtu řádků relací n. Proto by operátory, redukující počet řádků měly být realizovány co nejdříve. Operátory by měly být vykonávány v pořadí od jednoduššího ke složitějšímu a kartézskému součinu bychom se měli vyhnout. V distribuovaném prostředí lze využít SEMIJOIN na zmenšení velikosti přenášených dat.

Transformační pravidla RA (1) 16

 Konjunktivní

selekci lze transformovat na kaskádu selekcí a obráceně: pqr(R) = p(q(r(R)))  Komutativnost selekce: p(q(R)) = q(p(R)) V

posloupnosti projekcí se vyžaduje pouze poslední v pořadí LM … N(R) = L (R)

Příklad: lNamebranchNo, lName(Staff) = lName (Staff)


 Komutativnost

přirozeného spojení a kartézského

součinu. R⋈S=S⋈R RXS=SXR  Komutativnost

selekce a projekce. Obsahuje-li predikát selekce pouze atributy, vyskytující se v projekci, tak operátory selekce a projekce jsou komutativní.


 Komutativnost

součinu):

selekce a spojení (nebo kartézského

Obsahuje-li predikát selekce atributy pouze jedné z relací, tak platí p(R ⋈ S) = (p(R)) ⋈ S p(R X S) = (p(R)) X S

je predikát selekce tvaru p  q (konjunktivní), tak operace selekce a spojení jsou komutativní.

 Pokud

p  q(R ⋈ S) = (p(R)) ⋈ (q(S)) p  q(R X S) = (p(R)) X (q(S))


projekce a spojení (nebo kart. součinu). Je-li projekce tvaru L = L1  L2, kde L1 obsahuje atributy pouze z relace R a L2 pouze atributy z relace S, a spojení je pouze přes atributy L, tak projekce a spojení jsou komutativní:

Komutativnost

L1L2(R ⋈ S) = (L1(R)) ⋈(L2(S))  Obsahuje-li podmínka spojení další atributy, které nejsou obsaženy v L, například M = M1  M2 kde M1 obsahuje atributy pouze z R, a M2 má pouze atributy z S, tak je potřebná konečná projekce.

L1L2(R ⋈ S) = L1L2( (L1M1(R)) ⋈ (L2M2(S)))


 Komutativnost

RS=SR RS=SR

sjednocení a průniku:

selekce a množinových operací (Union, Intersection, Set difference).

 Komutativnost

p(R  S) = p(S)  p(R) p(R  S) = p(S)  p(R) p(R - S) = p(S) - p(R)




Komutativnost projekce a sjednocení L(R  S) = L(S)  L(R)



Asociativnost sjednocení a průniku (R  S)  T = R  (S  T)

(R  S)  T = R  (S  T) 

Asociativnost spojení (a kartézského součinu): (R ⋈ S) ⋈ T = R ⋈ (S ⋈ T) (R X S) X T = R X (S X T)



Pokud podmínky spojení zahrnují atributy pouze z relací S a T, potom spojení je asociativní: (R ⋈ S) ⋈ T = R ⋈ (S ⋈ T)

Příklad ENAME SELECT ENAME FROM PROJ, ASG, EMP WHERE ASG.ENO=EMP.ENO AND ASG.PNO=PROJ.PNO AND ENAME ≠ "J. Doe" AND PROJ.PNAME="CAD/CAM" AND (DUR=12 OR DUR=24)

Project

DUR=12  DUR=24 PNAME=“CAD/CAM”

Select

ENAME≠“J. DOE”

⋈PNO ⋈ENO PROJ

ASG

Join

EMP

Ekvivalentní dotaz ENAME

PNAME=“CAD/CAM”  (DUR=12  DUR=24) ENAME≠“J. Doe”

⋈PNO,ENO × EMP

PROJ

ASG

Restrukturalizovaný dotaz ENAME

⋈PNO PNO,ENAME

⋈ENO PNO

PNAME = "CAD/CAM" PROJ

PNO,ENO

DUR =12DUR=24 ASG

PNO,ENAME

ENAME ≠ "J. Doe" EMP

Vrstva lokalizace dat 25

 Tato

vrstva bere v úvahu distribuci dat. Postará se o další iteraci optimalizace tím, že nahradí globální relace na listech stromu jejich vyjádřením pomocí fragmentů. Pro horizontální fragmentaci na rekonstrukci globální relace použijeme operátor Union  Pro vertikální fragmentaci použijeme na rekonstrukci operátor Join. 

 Poté

použijeme redukci, abychom vytvořili jednodušší a optimalizovaný dotaz.

Příklad ENAME

Předpokládejme: 



EMP je fragmentována:  EMP1= ENO≤“E3”(EMP)  EMP2= “E3”<ENO≤“E6”(EMP)  EMP3= ENO≥“E6”(EMP)

DUR=12 DUR=24 PNAME=“CAD/CAM” ENAME≠“J. DOE”

ASG je fragmentována:  ASG1= ENO≤“E3”(ASG)  ASG2= ENO>“E3”(ASG)

⋈PNO ⋈ENO PROJ





EMP1EMP2 EMP3 ASG1 ASG2

Poskytuje paralelizmus



⋈ENO EMP1

ASG1

⋈ENO EMP2

⋈ENO ASG2 EMP3

ASG1

⋈ENO EMP3

ASG2

Eliminuje



⋈ENO EMP1

⋈ENO ASG1

EMP2

ASG2

⋈ENO EMP3

ASG2

Typy redukce 29

 Typ

redukce, který je vhodné použít je závislý na typu fragmentace:  redukce pro primární horizontální fragmentaci (PHF)  redukce pro vertikální fragmentaci  redukce pro odvozenou fragmentaci  redukce pro hybridní fragmentaci

Redukce pro PHF 30

Pro primární horizontální fragmentaci alternativy  redukci pro operátor selekce 



uvažujeme dvě

Když je operátor selekce v kontradikci s definicí fragmentu, tak získáme jako mezivýsledek prázdnou relaci a tak můžeme tyto operace vynechat.

redukci pro operátor spojení 

Nejdříve použijeme transformační pravidlo o komutativnosti spojení a sjednocení: (R1 U R2 ) ⋈ R3 = (R1 ⋈ R3 ) U (R2 ⋈ R3 )



Potom prověříme každé spojení zda tam nejsou redundantní operace, které lze eliminovat.



Redundantní spojení existují v případě, když se predikáty fragmentů nepřekrývají.

Redukce pro PHF 31

 Redukce

se selekcí

 Příklad SELECT * FROM EMP WHERE ENO="E5"

ENO=“E5”

ENO=“E5”

 EMP1

EMP2

EMP3

EMP2

Reduction pro PHF 32



Redukce pro operátor JOIN 

Použitelné v případě fragmentace na základě společného atributu



Platí (R1 R2)⋈S  (R1⋈S)  (R2⋈S)

Pravidlo redukce: Ri =pi(R) and Rj = pj(R) Ri ⋈Rj = když x in Ri, y in Rj: ¬(pi(x) pj(y))

Redukce pro PHF 33

fragmentováno jako předtím  ASG také fragmentováno

⋈ENO

 EMP

 



ASG1: ENO ≤ "E3"(ASG) ASG2: ENO > "E3"(ASG)

SELECT * FROM EMP,ASG WHERE EMP.ENO=ASG.ENO





EMP1 EMP2 EMP3

ASG1

ASG2

 ⋈ENO EMP1

⋈ENO

ASG1 EMP2

⋈ENO

ASG2 EMP3

ASG2

Redukce pro vertikální fragmentaci 34

pro vertikální fragmentaci spočívá v tom, že odstraní ty vertikální fragmenty, které kromě primárního klíče nemají žádné společné atributy s atributy projekce.

 Redukce

Redukce pro odvozenou HF 35

pro odvozenou horizontální fragmentaci používá pravidlo o komutativnosti operací spojení a sjednocení.  V tomto případě využíváme znalost toho, že fragmentace jedné relace je založená na jiné relaci a při výměně pořadí operací by některé z parciálních sjednocení měly být redundantní.  Redukce

Spojení v distribuované databázi 36

 Operace

spojení (join) je nejnákladnější z operací relační algebry.  Jeden z přístupů k optimalizaci distribuovaných dotazů nahrazuje spojení kombinací polospojení (semi-join).  Polospojení má důležitou vlastnost, že redukuje velikost operandu a snižuje objem přenášených dat.

Výpočet přirozeného spojení 37

 Máme

vypočítat R(A,B)  S(B,C)

R(A,B)

S(B,C)

Máme 2 možnosti:  poslat kopii R na místo, kde je S a tam vypočítat přirozené spojení,  poslat kopii S na místo, kde je R a tam vypočítat přirozené spojení. Pro mnoho situací obě možnosti jsou přijatelné.

Problémy 38

 Co

když propojení má malou kapacitu?  I když kapacita propojení je dostatečná, co když B obsahuje například pouze identifikátory a názvy videí a C obsahuje samotná videa?  V obou případech lze použít takový postup vyhodnocení dotazu, při kterém se pošle pouze relevantní část příslušné relace.

Polospojení relací (semijoin ) 39

relací R a S (tj. R S) je množina n-tic relace R, pro které platí, že existuje alespoň jedna n-tice v S, která má stejné hodnoty společných atributů.  R  S je relace, která obsahuje n-tice z R, které lze spojit s S.  R  S = πR (R ⋈ S)  R  S eliminuje n-tice R, které nelze spojit s S  Polospojení

Redukce použitím polospojení (1) 40

 Máme

R(A,B), S(B,C)  R  S = π A,B (R  S) = R  (πB (S))  To znamená, že vytvoříme projekci S na společné atributy a potom vytvoříme přirozené spojení této projekce s R  Pokud pošleme πB (S) na místo, kde je R, můžeme tam vypočítat R  S. Víme, že ty řádky R, které nejsou v R  S nemohou participovat v (R  S). Proto stačí poslat R  S na místo kde je S a tam vypočítat přirozené spojení.

Redukce použitím polospojení (2) 41

πB (S)

Krok 1

S(B,C)

R(A,B) Krok 2

(R  S) 

Zda je tento postup výhodnější, závisí na několika faktorech. Pokud projekce S na atributy B vytvoří relaci mnohem menší než je S, tak je levnější poslat πB (S) na R než posílat celé S. Toto platí v případě, že  Mnoho řádků S má stejné hodnoty B  Komponenty C jsou mnohem větší než komponenty B. Abychom mohli tvrdit, že použití polospojení je výhodnější, tak R musí mít mnoho řádků, které nelze s ničím spojit.

Příklad 42

Předpokládejme, že potřebujeme vytvořit R(A,B)  S(B,C), přičemž R a S jsou na různých místech sítě a cena za přenos dat po síti je dominantní složkou nákladů na vytvoření. Dále předpokládáme: 1. velikost R je vR 2. velikost S je vS 3. velikost πB(R) je pR a je to pouze zlomek vR 4. velikost πB(S) je pS a je to pouze zlomek vS 5. počet řádků relace R, které nejde spojit s S je nR 6. počet řádků relace S, které nejde spojit s R je nS

Příklad (pokrač.) 43



Máme vyjádřit (použitím výše zmíněných parametrů) cenu každé z následujících možných strategií a určit, za jakých podmínek bude strategie vhodná. a) Poslat R na místo kde je S. b) Poslat S na místo kde je R. c) Poslat πB(S) na místo kde je R a potom poslat R  S na místo kde je S. a) Poslat πB(R) na místo kde je S a potom poslat S R na místo kde je R.

Řešení 44

a) vR  když vR < vS a vR < pS + (vR – nR) je vhodné provést spojení na místě kde je S

b) vS 

Když vR > vS a vS < pR + (vS – nS) je vhodné provést spojení na místě, kde je R

c) pS + (vR – nR)  Když vR < vS a vR > pS + (vR – nR)

d) pR + (vS – nS)  když vR > vS and vS > pR + (vS – nS)

1

OBJEKTOVĚ - RELAČNÍ DATABÁZE

Klady relačních databázových systémů 2

 Relační

systémy nabízí možnosti práce s rozsáhlými soubory dat s relativně jednoduchou strukturou (tabulkami) a se silnými dotazovacími prostředky, které reprezentuje standard SQL89 a SQL92  Relační technologie dospěla ke svému vrcholu v souběžném zpracování požadavků v různých paralelních architekturách  Je rozšířená na většině hardwarových platforem,  Poskytuje "brány" (gateways) mezi jednotlivými relačními databázovými systémy

Nedostatky relačních DB systémů 3

 Relační

systémy se ukázaly jako nevhodné pro aplikace, vyžadující mnohem bohatší datové typy než poskytuje relační model – například modelování objektů v systémech pro návrh (napr. CAD)  geografické IS.  speciální aplikace objevující se v medicíně, (EKG, rentgenové snímky)  ve výzkumu Země (seismická data, snímky ze satelitu). 

90-tých letech do databázové technologie začaly pronikat prvky objektově orientovaných (dále OO) jazyků. Sváděla k tomu představa ukládat objekty do databáze a využít současně mnoha užitečných prvků OO technologie.

V

OO datový model 4

 Objektově

orientovaný datový model (ODM) představuje zcela nový přístup a není postaven jako rozšíření relačního datového modelu.  Do jisté míry zde jde o renezanci původního síťového datového modelu, který je doplněn o možnost práce s objekty tak, jak je známe z objektového programování.  OO DBS jsou na trhu - např. Gemstone, Versant, Caché. Již před 15 lety existovaly názory, že OO DBS zcela vytlačí relační systémy. Dosud se tak nestalo.

Výhody objektového datového modelu 5

 Pro

OO modelování je charakteristická především bohatost typů objektů, které jsou k dispozici.  Ukazuje se, že pomocí těchto typů objektů se snadno modelují a následně snadno implementují objekty používané právě v podnikových systémech Tyto objekty jsou složité nejen z hlediska struktury, ale i z hlediska vzájemných vztahů.  Relační databáze založené na normalizovaných tabulkách umožňují modelovat jednoduše, ovšem za cenu mnohdy složitého a neefektivního přístupu k odpovídajícím datům. Proto mohou OO systémy nabývat pro vývoj budoucích aplikací zásadního významu.

Požadované vlastnosti OO DBS 6





Systém musí být databázový - musí podporovat perzistenci, správu sekundární paměti, paralelizmus, zotavení a prostředky pro kladení „ad hoc dotazů. Systém musí být objektově orientovaný – musí podporovat:  komplexní objekty, nepožaduje se 1NF  uživatelem rozšiřitelné typy  identifikaci objektu,  zapouzdření,  typy nebo třídy,  dědičnost,  polymorfizmus,  pozdní vazbu.

Proč objektově-relační DBS ? 7



 

O-R technologie, se zdá být vhodným kompromisem mezi relační a objektovou technologií. Cílem je:  obdržet maximum z rozsáhlých investic do relační technologie (vybudování databází, zkušenosti vývojářů i uživatelů)  využít výhody v pružnosti a produktivitě OO modelování,  integrovat databázové služby do nových aplikací. O-R datový model ve svých principech zůstává původním relačním datovým modelem. Jde o doplnění relačního datového modelu o možnost práce s některými datovými strukturami, které známe z oblasti objektově orientovaných programovacích jazyků.

Nové črty O-R DBS 8

 Přidávají

možnosti ukládat objekty do relační databáze.  Výrobci relačních databází potřebovali rozšířit možnosti jejich aplikace do oblastí požadujících integraci klasických tabulkových dat a objektů speciálních typu, jako jsou např. časové řady, prostorová data, či binární objekty mezi které patří audio, video, obrázky, či aplety.  Zapouzdřením metod a datových struktur může O-R server vyvolat složité operace pro prohledávání a transformaci těchto složitých multimediálních dat.

Rozšiřitelnost 9

Protože je nemožné, aby každý výrobce DBS byl schopen implementovat širokou škálu různých typů dat a odpovídajících přístupových metod, realizovaly O-R DBS již dávno požadovanou ideu rozšiřitelných relačních DBS.  Rozšiřitelnost zde znamená dát možnost přidávání nových datových typů, ale také potřebných programů (funkcí) pro efektivní vyhledávání dat v souladu s jejich vnitřní strukturou.  "Objektovost" by měla u O-R technologie zahrnovat odpovídající objektový jazyk vyšší úrovně. Jako nejvhodnější se ukázal standard SQL:2003 (který revidoval SQL-99 a přidal několik nových možností.) 

Rozšíření relačního modelu 10

 Strukturované

typy atributů – hodnotou atributu může být celá relace (vnořená relace)  Reference (odkazy) - umožňují sdílení řádků mezi tabulkami a umožňují uživatelům vyjádřit složité spojení tabulek pomocí mnohem jednoduššího vyjádření cesty.  Metody – podobně jako u OO jazyků  Identifikátory řádků (řádek v tabulce představuje objekt) – lze odlišit řádky i v případě, že všechny ostatní atributy (kromě identifikátoru) jsou shodné. Identifikátor řádku je obecně neviditelný pro uživatele, lze jej vidět pouze za určitých okolností.

Vnořené relace – rekurzivní definice 11

 Základ: Atribut

může být atomického typu (integer,

real, string,…)  Indukce: Typem relace může být libovolné schéma, sestávající z názvu jednoho nebo více atributů z nichž každý je přípustného typu. Navíc,  typem atributu může být schéma.  typem atributu může být odkaz na řádek s daným schématem nebo množina odkazů na řádky s daným schématem.

Příklad 1 12



Máme vytvořit O-R schéma pro uložení informací o hercích (jméno, adresa, datum narození), přičemž každý herec bude mít uvedeny i základní informace o filmech, ve kterých hraje (název filmu, rok, délka). Někteří z herců mají více adres.

Složený vícehodnotový atribut Vztah m:n

Příklad – řešení A – vnořené relace 13

Name Fisher

Hamill

Address street

city

Maple

H´wood

Locust

Malibu

street

city

Oak

NY

Birthdate 9/9/50

8/8/54

Movies title

year

lenght

Star Wars

1977

124

Empire

1980

127

Return

1983

133

title

year

lenght

Star Wars

1977

124

Empire

1980

127

Return

1983

133

Příklad – řešení B – vnořené relace a odkazy 14

V případě řešení A předchozího příkladu nastala redundance v údajích, kterou O-R model umožňuje řešit pomocí odkazů. Stars Name

Address

Fisher

street

city

Maple

H´wood

Locust

Malibu

Hamill

Birthdate

street

city

Oak

NY

9/9/50

8/8/54

Movies

Movies title

year

lenght

Star Wars

1977

124

Empire

1980

127

Return

1983

133

Transformace konceptuálního modelu do O-R modelu 15

 



Entitní typ → Strukturovaný typ Atribut  Typ sloupce  Vícehodnotový atribut → ARRAY / MULTISET  Složený atribut→ ROW / Strukturovaný typ sloupce Vztah

1:1 → REF / REF 1:N → REF/ [ARRAY nebo MULTISET ] M:N → ARRAY / [ARRAY nebo MULTISET ] 

Agregace → REF/ [ARRAY nebo MULTISET ]



Kompozice → REF/ [ARRAY nebo MULTISET ]



Generalizace → Hierarchie typů

MULTISET je kolekce prvků, které se mohou opakovat

OO rozšíření jazyka SQL 16

 Základní

rozšíření jazyka SQL, které přidává objektové vlastnosti jsou uživatelem definované typy (UDT); v zásadě jsou to definice třídy s atributy a metodami.  UDT se používají dvěma různými způsoby:  UDT může být typem tabulky,  UDT může být typem atributu v tabulce.

Vytvoření UDT 17



CREATE TYPE AS (

Příklady:  CREATE TYPE Address_UDT AS ( Street CHAR(50), City CHAR(20) )  CREATE TYPE Movie_UDT AS ( Title CHAR(30), Year INTEGER, Genre CHAR(10))  CREATE TYPE Star_UDT AS ( Name CHAR(50), Address Address_UDT, Birthdate DATE, REF (Movie_UDT) SCOPE Student ARRAY[30] )



Typ reference a identita objektu 18

 





Typ reference je možné použít na jednoznačnou identifikaci řádků tabulky a na definování vztahu mezi tabulkami Reference umožňují sdílení řádků mezi tabulkami a umožňují uživatelům vyjádřit složité spojení tabulek pomocí mnohem jednoduššího vyjádření cesty. Tabulka může mít sloupec typu reference který slouží na identifikaci jejích řádků (OID). Tímto sloupcem může být systémem generovaná a udržovaná hodnota. Je-li T uživatelem definovaný typ, potom REF(T) je typ, odkazující na řádek typu T. Reference může mít zadán rozsah – daný názvem relace, na jejíž řádky se odkazujeme.  například REF(T) SCOPE(R)

Vytvoření identifikátoru pro tabulku 19

 Abychom

se mohli odkazovat na řádky tabulky, musí tabulka mít pro každý řádek vytvořen identifikátor (ID).  V příkazu CREATE TABLE, pokud je typ tabulky uživatelem definovaný, může být zahrnut následující element: REF IS <jak je vytvořen>  Název atributu je název sloupce s identifikátorem  Jak je vytvořen může udávat: SYSTEM GENERATED DERIVED (systém použije primární klíč na generování ID)

Reference - příklad 20

CREATE TYPE StarType AS ( Name char(30), address AddressType, bestMovie REF(movieType) SCOPE Movies) Vytvoření ID pro tabulku CREATE TYPE MovieType AS ( title char(30), year INTEGER, genre CHAR(10)) CREATE TABLE Movies OF MovieType( REF IS MovieID SYSTEM GENERATED, PRIMARY KEY (title, year))  REF IS SYSTEM GENERATED indikuje, že aktuální hodnoty příslušného typu REF jsou vytvořeny systémem.

Typ ROW 21

řádek dat - je tvořen posloupností dvojic jméno/typ.

 Definuje 

Příklad: ROW (ulice varchar(200), město(20) varchar, PSČ varchar(5))

 Umožňuje, 

 

aby celé řádky mohly být:

uložené v proměnných, předané jako parametry do procedur a funkcí , vrácené jako návratové hodnoty při volání funkcí.

 Umožňuje

také, aby sloupec tabulky obsahoval hodnoty typu ROW. Typ ROW je v podstatě tabulka vnořená do tabulky.

Metody 22

Deklarace metody je podobná jako u uložené funkce – každá vrací hodnotu určitého typu.  Metoda vyžaduje  Deklaraci v CREATE TYPE  Separátní definici v příkaze CREATE METHOD Příklad: CREATE TYPE AddressType AS (Street char (50), city char (20)) METHOD houseNumber() RETURNS Char(10)) CREATE METHOD houseNumber() RETURNS Char(10) FOR AddressType Begin …… END 

Příklad 23 23

 Máme

vyjádřit vztah (M:N) mezi filmy a herci použitím referencí.  Nejdříve musíme redefinovat tabulku MovieStar, aby se na ni dalo odkazovat CREATE TABLE MovieStar OF StarType ( REF IS starID SYSTEM GENERATED PRIMARY KEY name)  Vyjádříme

vztah

CREATE TABLE StarsIn( Star REF(StarType) SCOPE movieStar, Movie REF(movieType) SCOPE Movies)

Operace s O-R daty 24 24

 Všechny

běžné relevantní operátory jazyka SQL lze použít na tabulky, mající UDT.  Některé operátory mají modifikovanou syntaxi  Jsou definovány nové operátory

Sledování referencí 25 25

 Předpokládejme,

že x je hodnota typu REF(T). Potom x odkazuje na některý řádek t typu T. Můžeme získat samotnou hodnotu t nebo její komponenty dvěma způsoby:  Operátor -> má v podstatě stejný význam jako v jazyce C – tj. je-li x odkaz na řádek t, a je-li a atribut řádku t, tak x->a je hodnota atributu a v řádku t.  Operátor DEREF, který se aplikuje na odkaz a vrací odkazovaný řádek

Příklad 26 26

 Máme

najít filmy, ve kterých hraje Brad Pitt (tabulka StarsIn) SELECT DEREF(movie) FROM StarsIn Where star->name= ´Brad Pitt

Typ kolekce 27

jsou konstruktory typu, používané na definování kolekce jiných typů.  Používají se na uložení více hodnot v jednom sloupci a mohou vyústit do vhnízděné tabulky  Typ kolekce může být  Kolekce

   

ARRAY MULTISET LIST SET

Kolekce 28

 ARRAY

- jednorozměrné pole s daným maximálním počtem prvků  MULTISET – neuspořádané kolekce která může obsahovat duplicity  LIST – uspořádané kolekce, která může obsahovat duplicity  SET – neuspořádané kolekce, která neobsahuje duplicity

OLAP

Zdroj: H.Garcia-Molina, J.D. Ullman, J.Widom: Database systems, 2009, Chap. 10.6

OLTP vs. OLAP 2



Tradiční databázové systémy se používají hlavně na uchovávání a zpracování operativních dat (Online Transaction Processing) a byly optimalizovány na podporu  častých úprav,  krátkých transakcí, dotýkajících se malé části dat,  jednoduchých dotazů.



Pro potřeby hlubších analýz na podporu rozhodování (Online Analytic Processing) se data z různých transakčních systémů transformují, sjednocují a kontrolují a vytváří se datové sklady (samostatné databáze), které se periodicky aktualizují.



Datové sklady jsou optimalizovány na podporu  složitých dotazů nad velkým množstvím dat které nevyžadují absolutně aktuální data,  dlouhých transakcí.

Vícedimenzionální pohled na OLAP data 3

V typické OLAP aplikaci je nejdůležitější tabulka faktů (fact table), která reprezentuje určité události nebo objekty našeho zájmu jako je například Prodej v následujícím příkladě, kde sledujeme cenu, za kterou byly prodány jednotlivé kusy různých druhů zboží:  Obchod (obchodID char(10) primary key, mesto varchar(50), kraj varchar(50), stat varchar(50));  Zbozi(zboziID char(10) primary key, kategorie nvarchar(50), barva nvarchar(50));  Zakaznik (zakaznikID char(10) primary key, jmeno varchar(50), pohlavi nchar(1), vek int);  Prodej(obchodID char(10) references Obchod, zboziID char(10) references Zbozi, zakaznikID char(10) references Zakaznik, cena varchar(50));



Data ve vícerozměrném prostoru 4

zboží

cena

obchod zákazník

Dimenze kostky:  obchod,  zákazník,  zboží. Cena každého prodaného kusu zboží je daná bodem uvnitř kostky. Dimenze reprezentují vlastnosti každého prodeje. 4

Data ve vícerozměrném prostoru 5

zboží

cena

Vícerozměrný prostor dat lze dále dělit podél každé dimenze. Například zboží lze dělit podle kategorie nebo barvy nebo podle kategorie i barvy.

obchod

zákazník

5

Přístup k dimenzionálnímu modelování 6

(relational OLAP) – data jsou uložena v tabulkách se specializovanou strukturou hvězdicové schéma. Jedna z tabulek reprezentuje fakta – primární, neagregovaná data. Ostatní tabulky poskytují údaje o hodnotách v každé dimenzi. Této struktuře jsou potom přizpůsobeny dotazy, indexy a ostatní možnosti systému.  MOLAP (multidimensional OLAP) – data jsou uložena ve vícedimenzionální kostce, která obsahuje kromě původních dat také agregace dat ve všech kombinacích dimenzí.  ROLAP

Hvězdicové schéma 7

Tabulka dimenzí (Obchody)

Atributy dimenzí

Tabulka dimenzí (Zákazníci)

Závislé atributy

Tabulka faktů - Prodej

Tabulka dimenzí (Zboží) 7

Datová kostka (s agregací) 8

zboží

cena

obchod

zákazník

Datová kostka – speciální struktura, která obsahuje i agregace dat ve všech podmnožinách dimenzí. Pro tuto strukturu mohou být implementovány nerelační operátory na podporu OLAP dotazů.

8

Operátor CUBE v SQL 9

SQL umožňuje rozšířit GROUP BY o klauzuli WITH CUBE, čímž ve výsledku dostaneme, kromě řádků pro každou skupinu dat, také řádky reprezentující agregaci podél jedné nebo více dimenzí podle kterých jsme data seskupovali. Příklad: SELECT Zbozi.barva, SUM (cena) AS CekovaCena FROM Prodej JOIN Zbozi ON Prodej.zboziID=Zbozi.zboziID GROUP BY Zbozi.barva WITH CUBE

Použití CUBE 10

SELECT Zbozi.barva, Zbozi.kategorie, SUM (cena) AS CekovaCena FROM Prodej JOIN Zbozi ON Prodej.zboziID=Zbozi.zboziID GROUP BY Zbozi.barva, Zbozi.kategorie WITH CUBE

Dostali jsme agregované tržby za:  každou kategorii zboží,  všechno prodané zboží,  zboží každé barvy

Použití ROLLUP 11

ROLLUP produkuje agregovaná data podobně jako

CUBE s tím rozdílem, že agreguje pouze podle poslední dimenze uvedené v group by. Příklad: SELECT Zbozi.barva, Zbozi.kategorie, SUM (cena) AS CekovaCena FROM Prodej JOIN Zbozi ON Prodej.zboziID=Zbozi.zboziID GROUP BY Zbozi.barva, Zbozi.kategorie WITH ROLLUP

METODOLOGIE NÁVRHU DATOVÉHO SKLADU

Zdroj: Connolly T., Begg C.: Database systems, 2010, Chap. 33

Návrh datového skladu 2



Datový sklad se používá pro podporu rozhodovaní a obsahuje data získaná z databází operativních dat, která byla transformována pro potřeby analytických dotazů, sjednocena a zkontrolována před jejich uložením do datového skladu.



Na začátku vytváření datového skladu je vhodné si položit následující otázky:  Které požadavky uživatelů jsou nejdůležitější?  Která data máme zpracovat jako první?  Je vhodným řešením rozdělit požadavky na datový sklad na více jednodušších částí, pokrývajících požadavky pouze vybraných skupin uživatelů a budovat nejdříve datová tržiště (data marts) s tím, že cílem zůstává kompletní datový sklad?



Málokterý tvůrce datového skladu je ochoten budovat komplexní datový sklad v jednom kroku.

Typická architektura datového skladu 3

Zdroj: Connolly T., Begg C.: Database systems, 2010

Zdroje dat pro datový sklad 4

Operativní data z různých podnikových databází.  Data z dostupných externích systémů (například z komerčních databází, databází dodavatelů a odběratelů).  Sklady operativních dat – předzpracovaná data pro datový sklad, obsahující kromě operativních dat také jednoduché agregace.  ETL (Extraction,Transformation, Loadig) manager 

extrahuje data z prvotních zdrojů,  transformuje je do tvaru vhodného pro analytické zpracování a kompatibilního se strukturou datového skladu,  vloží upravená data do datového skladu. 

Zpracování dat v datovém skladu 5



Warehouse manager zajišťuje konzistenci dat v datovém skladu,  připojí data k existujícím datům,  vytvoří indexy,  vytvoří agregace,  zálohuje data. 

Query manager zajistí zpracování dotazů.  Management metadat je velmi složitý, neboť metadata obsahují informace nejen o struktuře datového skladu, ale také o 

o původních strukturách a jejich transformaci,  o agregacích,  dalších strukturách souvisejících s analytickými dotazy. 

Metodologie návrhu datového skladu 6

Existují dvě hlavní metodologie: 

Corporate Informtion Factory (autor W. H. Inmon, 2001) 





Začíná vytvořením datového modelu pro celý podnik, z něhož se potom odvíjí vytváření datových tržišť - datových skladů pro potřeby jednotlivých oddělení. Využívá tradiční databázové metody a techniky; předpokládá 3NF.

Business Dimensional Lifecycle (autor R. Kimball, 2008) 





Začíná identifikací požadavků na informace (analytických témat) a příslušných business procesů. Vybere první skupinu uživatelů, pro kterou vytvoří datové tržiště; jednotlivá tržiště se potom integrují do datového skladu. Pro návrh datového modelu pro každé tržiště používá novou techniku nazývanou dimenzionální modelování.

Dimenzionální modelování 7

Dimenzionální model má hvězdicové schéma, které má uprostřed jednu tabulku (tabulka faktů) se složeným primárním klíčem a z množiny menších denormalizovaných tabulek (tabulky dimenzí). Každá tabulka dimenzí má jednoduchý umělý primární klíč, který koresponduje s právě jednou složkou primárního klíče tabulky faktů. Dimenze obvykle tvoří hierarchie, jejichž členy jsou vhodnými kandidáty pro agregaci dat (faktů). Většina dimenzí se mění pouze pomalu; některé mají podobné vlastnosti jako číselníky. Obecnější přístup připouští množinu hvězdicových schémat (souhvězdí), kde jedna dimenze může být sdílena několika tabulkami faktů. 

Hlavním předmětem zájmu jsou fakta, která jsou modelována neklíčovými atributy tabulky faktů. Tyto atributy jsou obvykle numerické a aditivní, představují jisté míry (cena, množství, …).

Příklad: Hvězdicové schéma pro prodej nemovitostí v realitní kanceláři, která má několik poboček Fakta (neklíčové položky v tabulce faktů) představují nabídkovou a prodejní cenu, provizi a celkový příjem z každého jednotlivého prodeje – a jsou to numerické a aditivní hodnoty.

Tabulka faktů může být extrémně velká v porovnání s tabulkami dimenzí. Tabulku lze zmenšit použitím agregovaných hodnot.

Uprostřed je tabulka faktů, obklopená denormalizovanými tabulkami dimenzí.


Prodej a inzerce – společné dimenze 9

Zdroj: Connolly T., Begg C.: Database 9 systems, 2010

Příklad: Část schématu sněhové vločky pro prodej nemovitostí 10

Schéma sněhové vločky: Dimenzionální model s tabulkou faktů uprostřed a normalizovanými tabulkami dimenzí.


Kimballova metodologie http://www.kimballgroup.com/ 11


Základní kroky dimenzionálního modelování 12

1.

Vyber business proces 

2.

Vyber granularitu 

3.

první by měl být ten, který bude z ekonomického hlediska zajímavý a u kterého je předpoklad, že bude dokončen včas

granularita určuje co budou reprezentovat hodnoty v tabulce faktů - zda jednotlivé či agregované hodnoty (například za určité období)

Vyber dimenze  dimenze, které budou reprezentované ve více než jednom dimenzionálním modelu musí být shodné, nebo jedna má být podmnožinou druhé. Společné dimenze hrají důležitou roli při integraci jednotlivých datových tržišť.

4.

Identifikuj fakta 

5.

Fakta by měla být numerická a aditivní. Všechna fakta musí být vyjádřena ve stejné (vybrané) granularitě. V předchozím příkladu je úrovní granularity jednotlivý záznam, tj. jednotlivý prodej.

Identifikuj atributy dimenzí 

Dimenze se určují v kontextu požadovaných dotazů na fakta. Obvykle obsahují popisné informace, které se využívají při formulaci dotazů.

Typické dotazy na datový sklad realitní kanceláře 13

Jaký byl celkový příjem v pobočkách ve Skotsku v roce 2012?  Jaký byl celkový příjem ve firmě za rok 2012?  Jaký byl výnos z prodeje jednotlivých typů nemovitostí v roce 2012?  Která byla nejžádanější oblast v jednotlivých městech při pronájmu nemovitostí v roce 2012 a jak se změnily priority v porovnání s předchozími 3 roky?  Jaký je celkový obrat v prodeji nemovitostí v jednotlivých pobočkách?  Jaký je vztah mezi ziskem jednotlivých poboček a celkovým počtem pracovníků pobočky za roky 2005-2012? 

13

Celkový ER model realitní kanceláře s vyznačením business procesů 14

14 Zdroj: Connolly T., Begg C.: Database systems, 2010

Dimenzionální model realitní kanceláře 15

Zdroj: Connolly T., Begg C.: Database systems, 2010 15

Porovnání metodologií Metodologie

Hlavní výhoda

Hlavní nevýhoda

Inmon

Potenciální vytvoření konzistentního a úplného pohledu na všechna data organizace.

Komplexní, rozsáhlý projekt, který může selhat aniž by přinesl očekávané výsledky v plánovaném čase nebo po vynaložení plánovaných prostředků.

Kimball

Rozdělení projektu na etapy umožní demonstrovat přínos prvního datového tržiště v plánovaném čase nebo po vynaložení plánovaných prostředků.

Datová tržiště, vytvářena postupně mohou být budována případně i jinými vývojovými týmy a při použití jiných vývojových systémů. Konečného cíle, kterým je komplexní datový sklad, nemusí být v plné míře nikdy dosaženo.

DISTRIBUOVANÉ A OBJEKTOVĚ-RELAČNÍ DATABÁZE

Recommend Documents