DISTRIBUOVANÉ A OBJEKTOVĚ

Transkript

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.
DDBMS - realita
5
Aplikace
Dotazy
uživatele
Komunikační
systém
Aplikace
Dotazy
uživatele
Dotazy
uživatele
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)
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
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.
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
10
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á')
23
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)
17
 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í.
18
 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))
19
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)))
20
 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)
21

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 <TypeName> AS (<attribute declarations>
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 <název atributu> <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í.
Zdroj: Connolly T., Begg C.:
Database systems, 2010
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
Database systems, 2010
Dimenzionální model realitní kanceláře
15
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Ě

Transkript

Podobné dokumenty

MANUÁL OBCHODU VLTAVA2000

aruba networks_hotel lev_netlancers_30_5_13

Odbor informačních a komunikačních technologií

collate "cs_CZ"

Západočeská univerzita