tendencje rozwojowe baz danych

Transkrypt

tendencje rozwojowe baz danych
T E NDE NCJ E ROZWOJ OWE B AZ DANYCH
„Współczesne bazy danych rozwijają się w róŜnych kierunkach, ale duŜa liczba
zastosowań... polega na budowaniu jednej duŜej bazy danych.....wirtualnej...tak, aby moŜna było pytać o dane, jakby
pochodziły z jednego źródła...”
Garcia Molina H., Ullman J., Widom J.
INTEGRACJA DANYCH.
We współczesnym świecie pojawiła się potrzeba gromadzenia danych
pochodzących
z róŜnych źródeł, pozwalających na przechowywanie danych
historycznych i potrafiących w dogodny sposób udostępnić dane do analizy.
Dane zarządzane są one poprzez System Zarządzania Baza Danych jako jedna
duŜa całość.
Ok azu je
p o waŜn y
s chematu ,
si ę,
k o rzyst ani e
Ŝe
pro b lem.
ale
RóŜn ice
dan e
w
z
róŜn ych
mi edzy
ró Ŝn ych
źród eł
źró d łami
źró d łach
zn aczeni a mog ą być rep rezent o wan e
s tan o wi
ni e
mimo
b ard zo
d o tyczą
teg o
t yl k o
sameg o
in aczej. RóŜn ice wys tęp ują
międ zy in nymi w:
1. typach danych,
2. wartościach danych,
3. semantyce danych,
4 . w a rto ścia ch po minięty ch w ni ektóry ch ro zw i ąza ni ach.
FEDERACYJNE SYSTEMY BAZ DANYCH.
to najprostsza architektura wspomagająca integrowanie danych.
FBD to kolekcja heterogenicznych, autonomicznych baz połączonych siecią,
zarządzanych przez Federacyjny System Zarządzania Bazami Danych (FSZBD).
System taki umoŜliwia tworzenie aplikacji globalnych, działających na całych
bazach danych. Ponadto powinien on zapewnić przeźroczystość i niezaleŜność
danych
przeźroczystość sieci i rozproszenia – uniezaleŜnienie uŜytkowników od wszystkich
szczegółów sieci takich jak miejsce
przechowywania danych, czy nazwa uŜyta w
systemie,
przeźroczystość współbieŜności przy zachowaniu spójności danych,
przeźroczystość skalowania- wprowadzenie nowych elementów do bazy bez wpływu na
działanie programów i pracę uŜytkowników,
przeźroczystość replikacji umoŜliwiającą synchronizację wszystkich replik
w róŜnych
węzłach sieci bez wiedzy uŜytkownika i wpływu na jego pracę,
przeźroczystość fragmentacji, która pozwala na realizacje zapytań cząstkowych bez wiedzy
uŜytkownika,
przeźroczystość awarii umoŜliwiająca pracę
węzłów sieci,
w systemie w przypadku awarii niektórych
p rzeźro czysto ść m igracji d an ych w sieci,
p rzeźro czysto ść w y d ajn o ści, czyli
m oŜliw ość dodaw ania now ych elem entów
system u bez w pływ u na pracę u Ŝytk ow n ik ów .
p rzeźroczystość
dostępu
czyli
pozbaw ienie
uŜytko w nikó w
inform acji
na
tem at po ło Ŝenia d an ych.
N a rys. 1 przedstaw iono system FB D .
U dostępnienie
d an ych
i usług lokalnych
baz
danych
(LB D i) dla aplikacji
glob alnych od b yw a sie przez prosty in terfejs zw an y osło ną (O i) lu b w rap erem . .
FBD
O1
LBD1
O2
LBD2
R ys. 1 Lokalne bazy dla system u federacyjnego.
On
LBDn
Inne istotne cechy FSZBD to:
prostota,
naturalność,
wysoki poziom abstrakcji interfejsów programistycznych,
dostęp do informacji poprzez języki zapytań.
FBD mogą działać na róŜnym sprzęcie, w róŜnych systemach
operacyjnych, z róŜnymi protokołami komunikacyjnymi.
Mogą bazować na róŜnych Systemach Zarządzania Bazami Danych,
wymieniać pomiędzy sobą niejednorodne dane podlegające róŜnym
modelom danych, schematom, semantyce, czy mechanizmom dostępu.
Na rys.2 p rzedstawio no k olekcje czterech federacyjnych baz danych .
Wszystko
sp rowadza
się
do
u tworzen ia
połączeń
wszystkimi parami b az danych .
BD2
BD3
BD!
BD4
Rys. 2 Kolekcja czterech federacyjnych baz danych.
1:1
między
Połączenia te pozwalają na wysyłanie zapytań z jednego systemu bazy danych
BDi do innego BDj wyraŜonych za pomocą pojęć zrozumiałych dla BDj. Przy
załoŜeniu, ze kaŜda z n baz chce się łączyć z (n-1) bazami trzeba napisać
n(n-1) fragmentów kodów obsługujących zapytania.
Oczywiście bazy danych, które są wykorzystywane w FSZBD rządzą się
własnymi prawami. Podlegają one lokalnym priorytetom, regułom własności,
autoryzacji dostępu, bezpieczeństwa i mogą odrzucać zlecenia, które naruszają
ich lokalne ograniczenia. Trzeba pamiętać o tym, Ŝe zapytania muszą działać
poprawnie w tej bazie do której są skierowane, a niejednokrotnie te same
zapytania mają róŜną postać w zaleŜności od bazy do której są skierowane.
Przykładowo mamy daną bazę danych producenta komputerów BD1 o
schemacie:
Komputery (numer,procesor, pamięć, dysk….)
Monitory (numer, ekran, maxrozX, maxrozY);
oraz drugą bazę BD2 w której komputery i monitory tworzą jeden schemat o nazwie System:
System (id, procesor, pamięć, dysk….),
Atrybuty id, pamięć i dysk
z BD2 odpowiadają atrybutom numer, pamięć, dysk z BD1,
pozostałe nie mają swoich odpowiedników (procesor w jednym przypadku oznacza typ
procesora w drugim częstotliwość zegara). Zapytania SELECT..FROM….WHERE wysyłane
przez producenta z BD1 muszą być zrozumiałe dla BD2 i uwzględniać róŜnice w semantyce
atrybutów.
H u rto w n ie b a z d a n yc h .
H u rto w n ia b a z d a n y ch (a n g .d a ta w a r eh o u se )
jest ro zb u d ow a n ą
b a zą d a n y ch p rzech o w u ją cą o lb rzy m ią ilo ść d a n y ch zb iera n y ch w
czasie.
Przechow yw ane
dane
są
tem atyczn ie
sp ó jn e
oraz
zin teg ro w an e. O p eracje p rzep ro w ad zan e n a d an ych m ają ch arakter
an ality czn y. H u rtow n ie n ajczęściej w y ko rzy stu je się d o tw o rzen ia
system ów , które w ym a ga ja p o d ejm ow an ia d ecyzji
H u rto w n ia p o w in n a m ieć n a stęp u ją ce w ła sn o ści:
•
•
in teg ra cję d an ych , a w ię c u jed n o lice n ie d an yc h z ró Ŝn yc h źró d e ł,
o rie n ta c ję te m a ty c z n ą , c z y li n a s ta w ie n ie n a o k re ślo n ą te m a tyk ę , a
nie o bszar zastosow ań ,
•
nieu lotno ść danych - dan e u m ieszczon e w
h u rto w n i n ie u leg ają
m o d yfik acji, słu Ŝ ą
o g ó ł n ie
tylk o
do
od czytu . N a
sto su je
typ o w ych tran sak cji w b azie.
o rien tacje czaso w ą- d an e m ają p rzyp isan y id e n tyfik ato r czaso w y i są
po praw ne tylko w pew nym ok reślo nym przed ziale czasow ym .
się
Hurtownia przedstawiona na rys.3 stanowi jeden globalny
schemat zasilany z wielu róŜnych źródeł danych (Z1,Z2,…Zn).
Ich zróŜnicowanie powoduje, ze konieczne jest przekształcenie
danych w jednolite, przejrzyste i wiarygodne źródło informacji
korzystając z pewnych programów zwanych
ekstraktorami
(E1,E2,….En), które tłumaczą zapytania i ich wyniki miedzy
schematem globalnym i lokalnymi schematami w źródle.
schematami w źródle.
Hurtownia danych
E1
Z1
Z
1
E2
Z2
Rys.3.Hurtownia danych
En
Zn
Ekstraktory składają się :
1. z zapytania lub wielu zapytań do źródła czyli do lokalnych baz
danych (LBD),
2. mechanizmów komunikacji, które umoŜliwiają i przekazywanie
danych do hurtowni.
Konstruując zapytania na ogół korzysta się z języka SQL lub z
jakiegokolwiek języka właściwego dla lokalnej bazy danych.
Przyklad
CompMag (id, procesor, pamięć, dysk,producent )
Aby utworzyć schemat globalny naleŜy przy pomocy odpowiedniego programu wydobyć
dane z dwóch baz. Z bazy SYSTEM sprawa jest bardzo prosta a kod programu jest
następujący:
INSERT INTO CompMag(id, procesor, pamięć, dysk,producent )
SELECT id, procesor, pamięć, dysk,producent2
FROM SYSTEM;
W przypadku bazy pierwszego producenta kod programu jest znacznie bardziej złoŜony, gdyŜ
naleŜy wziąść pod uwagę wiele warunków .
Zestaw operacji wykonywanych na danych pochodzących z róznych źródeł,
którymi zasilana jest hurtownia określany jest mianem procedur ETL (ang.
Extraction Transformation Loading). Procedura ETL składa sie z trzech
etapów:
1. pobrania danych z ich pierwotnego źródła,
2. łaczenie danych, ich weryfikowanie, oczyszczanie i znakowanie czasowe,
3. wprowadzanie danych do hurtowni.
Istnieje kilka sposobów organizowania hurtowni:
systematyczne rekonstruowanie na podstawie aktualnych danych ze źródeł
danych. Wadą tej metody jest konieczność wyłączania działania hurtowni na
pewien okres czasu oraz przesyłanie
pełnej kopii zawierającej
duŜą liczbę
danych.
aktualizacja przyrostowa na podstawie zmian, które nastapiły w źródłach od
chwili ostatniej aktualizacji,
natychmiastowa aktualizacja, system reaguje bezpośrednio na zachodzące
zmiany. Tego typu organizacja jest bardzo kosztowna i niewygodna.
Pierwszy sposób organizacji jest niezwykle popularny, posiada jednak wiele wad.
Hurtownia na czas rekonstrukcji nie działa, a długi okres pomiędzy kolejnymi
rekonstrukcjami powodują, Ŝe dane tracą na wartości.
Aktualizacja przyrostowa
wymaga kopiowania mniejszej liczby danych co
znacznie skraca czas kopiowania, nie mniej jednak sam algorytm rekonstrukcji
przyrostów informacji jest bardzo złoŜony.
Natychmiastowa aktualizacja wymaga przesyłania duŜej liczby komunikatów więc
sprawdza się tylko wtedy, gdy źródła są rzadko aktualizowane.
WaŜnym zastosowaniem hurtowni danych jest moŜliwość obsługi złoŜonych
zapytań, które wymagają na ogół agregowania danych.
Te zapytania zwane inaczej zapytaniami wspomagającymi podejmowanie decyzji
lub
OLAP
–
analityczne
Processing) sprawdzają
działania
bezpośrednie
(ang.
On-
line
Analityc
bardzo duŜo danych. Są to bardzo długie transakcje
wymagające duŜych przepustowości sieci.
Bardzo często blokują całą bazę danych uniemoŜliwiając wykonywanie zwykłych
operacji zwanych OLTP (ang. On- line Transaction Processing). Podstawowym
zadaniem
operacji OLTP jest przechowywanie danych
relacyjnych. OLTP to
stosunkowo duŜa liczba małych
najczęściej modyfikują dane.
na ogół
w bazach
transakcji, które
Korzyści wynikające z utworzenia hurtowni:
zapewnienie jednolitej, łatwiej w zarządzaniu struktury danych,
które dotyczą wspomagania decyzji,
umoŜliwienie
uŜytkownikom
zadawania
złoŜonych
zapytań,
dotyczących nie jednego lecz kilku obszarów zastosow ań,
moŜliwość w ykorzystania aplikacji OLAP czy teŜ programów
w spomagających eksplorację danych.
N ajw iększy problem pojawia się gdy mamy do czynienia z danymi
pochodzącymi z niezaleŜnych od siebie źródeł o róŜnym nazew nictwie,
z
róŜnie
zdefiniowanymi
wartościami
czy
na
przykład
z
róŜnie
przypisanymi numerami identyfikacyjnymi.
Administrowanie hurtow nią danych i zapewnienie danym
bezpieczeństw a jest duŜo bardziej złoŜone i wymaga odpowiednio
większych umiejętności w porównaniu z administrowaniem zw ykłą baza
danych. Na ogół zajmuje się tym grupa ekspertów dysponująca
odpowiednią wiedzą i duŜym doświadczeniem
3. Mediatory.
Mediator jako baza wirtualna stanowi bardzo ciekawe rozwiązanie
problemu korzystania ze wspólnych danych.
Mediator nie posiadając własnych danych w odpowiedzi na zapytanie
musi
pozyskać
stosowne
dane
ze
źródeł
i
na
ich
podstawie
sformułować odpowiedź.
Mediator stanowi warstwę pośrednią, która oddziela lokalną bazę
danych od globalnych aplikacji.
Podstawowe zadania mediatorów to:
określenie
wszelkich
róŜnic
jakie
zachodzą
między
schematem
lokalnym a schematem globalnym,
wybór odpowiednich danych metodą selekcji,
wspomaganie wyszukiwania znaczących cech w danych, które nie
zostały sformatowane,
wspomaganie szeroko pojętego problemu eksploracji danych.
Mediator przekazuje zapytanie do wraperów, które tak jak ekstraktory
tłumaczą zapytania i ich wyniki między schematem globalnym i
lokalnymi schematami w źródle
Wrapery łączą mediatory ze źródłami.
Wrapery
z
których
korzystają
mediatory
są
na
ogół
bardziej
skomplikowane niŜ ekstraktory.
Wraper
musi
posiadać
umiejętność
akceptowania
róŜnego
typu
zapytań od mediatora i tłumaczenia ich na pojęcia zrozumiałe dla
lokalnej bazy danych.
Tworzenie wrapera polega na sklasyfikowaniu moŜliwych zapytań,
które przekazywane są poprzez szablony z mediatora.
Szablony
są
to
pytania
Mediator
dostarcza
te
z
stałe,
parametrami
a
wraper
reprezentującymi
wykonuje
stałe.
odpowiednie
zapytania z tymi stałymi. Innymi słowy wraper przekształca szablon
T na zapytanie S źródła (T ⇒ S]).
P rz y k ła d o w o m a m y d a n y n a s tę p u ją c y w ra p e r d la ź ró d ła -p ro d u c e n t P 1 , o
sc h em ac ie:
K o m p u te r y (n u m e r ,p r o c e s o r , p a m ię ć , d y s k … .)
S c h e m a t m e d ia to ra je s t n a s tę p u ją c y :
C o m p M e d (n u m e r ,p r o c e s o r , p a m ię ć , d y s k , p r o d u c e n t1 )
In te re s u ją n a s k o m p u te ry o o k re ś lo n e j s z y b k o ś c i. K o d re p re z e n tu ją c y s z y b k o ś ć
o z n a c z y m y $ f. S z a b lo n b ę d z ie w y g lą d a ł n a s tę p u ją c o :
SELECT*
FR O M C om pM ed
W H E R E sz y b k o ść= $ f;
⇒
S E L E C T n u m e r ,p r o c e s o r , p a m i ę ć , d y s k , p r o d u c e n t 1
F R O M K o m p u ter y
W H E R E sz y b k o ś ć = ” $ f” ;
Z a p y ta n ia m o g ą m ie ć p o s ta ć b a rd z ie j s k o m p lik o w a n ą :
SELECT*
FR O M C om pM ed
W H E R E sz y b k o ś ć = ” $ f” A N D d y sk = ” $ d ” ;
⇒
S E L E C T n u m e r ,p r o c e s o r , p a m i ę ć , d y s k , p r o d u c e n t 1
F R O M K o m p u ter y
W H E R E sz y b k o ś ć = ” $ f” A N D d y sk = ” $ d ” ;
Wzorce zapytań zawarte w szablonach oraz źródła zapytań,
które są związane z kaŜdym z nich przechowywane są w
tablicach tworzonych przez generatory wraperów.
Generatorem
tworzące
wraperów
wrapery.
Po
nazywa
pobraniu
się
oprogramowanie
zapytania
od
mediatora
wyszukiwany jest w tablicy szablon pasujący do zapytania.
JeŜeli
znajdzie
się
taki
szablon,
to
wartości
parametru
zapytania są uŜywane do utworzenia zapytania do lokalnej
bazy
danych.
Jeśli
nie
moŜna
znaleźć
odpowiedniego
szablonu to zapytanie nie jest utworzone. W przypadku, gdy
zachodzi
taka
dopiero
wtedy
moŜliwość
potrzeba
wraper
przekazuje
stosowania
ją
większej
przetwarza
do
odpowiedź
mediatora.
liczby
zapytań
i
Istnieje
poprzez
zastosowanie wrapera filtrującego wyniki zapytań, tak aby
do mediatora przekazać tylko informacje potrzebne.
mediator
wraper1
LBD 1
wraper2
LBD 2
wrapern
LBD n
.
Rys.4 Mediatory
Wrapery umoŜliwiają wykonywanie róŜnego typu operacji takich jak:
projekcja, agregacja czy łączenie.W ten sposób do mediatora
przesyłany jest dopiero wynik przeprowadzonej operacji.
Na
p o d sta w ie
uzyskanych
od
w rap eró w
w y n ik ó w
z a p y ta ń
tw o rz o n a je st o d p o w ie d ź d la u Ŝ y tk o w n ik a .
Z
m e d ia to ra m i
c z y li ta b lic y
fiz y c z n ie
p rz e sy ła n e
sk o ja rz o n e
je st
w irtu a ln e j, k tó ra
n ie
do
istn ie ją c .
ró w n ie Ŝ
z a w ie ra
O c z y w iśc ie
p e rsp e k ty w y
ta k
ja k
p o ję c ie
dane
z
p e rsp e k ty w y ,
ró Ŝn ych
z a p y ta n ia
do
kaŜdej
źró d eł
mogą
być
rz e c z y w iste j
ta b lic y . P e rsp e k ty w a m ie d z y in n y m i :
•
•
z w ię k sz a b e z p ie c z e ń stw o d a n y c h ,
z m n ie jsz a z ło Ŝ o n o ść m o d e li k o n c e p tu a ln y c h ,
•
u p ra sz c z a z a p y ta n ia ,
•
z w ię k sz a
o ch ro n ę
p ry w a tn o śc i,
k tó re
spow odow ane
je st
z m n ie jsz e n ie m m o Ŝ liw o śc i d o stę p u d o o b ie k tó w ,
• u m o Ŝ liw ia z a p e w n ie n ie lo g ic z n e j n ie z a le Ŝ n o śc i a p lik a c jo m i
o b ie k to m
• w sp o m a g a w sp ó łp ra c ę m ię d z y sy ste m a m i h e te ro g e n ic z n y m i
p o p rz e z tw o rz e n ie w sp ó ln e g o sc h e m a tu ,
u m o Ŝ liw ia h u rto w n io m d a n y c h p rz e p ro w a d z a n ia a n a liz d a n y c h
p o c h o d z ą c y c h z w ie lu ź ró d e ł
Mediatory w dogodny sposób wspomagają konstruowanie perspektyw wirtualnych.
Taka perspektywa wirtualna istnieje tylko jako definicja, a jej wyliczenie ma
miejsce w momencie jej uŜycia. Wynik pracy perspektywy wirtualnej jest
kasowany zaraz po jego wykorzystaniu. Dzięki temu unika się
dublowania
danych, znikają problemy związane z z aktualizacjami danych, z transakcjami i
ich przetwarzaniem.
Do wad natomiast zaliczyć naleŜy czas jaki potrzebny jest na utworzenie
odpowiednich
perspektyw
i
zapytań,
którego
poziom,
jeśli
nie
jest
optymalizowany, najczęściej jest niedopuszczalnie wysoki
MoŜna by było pokusić się o stwierdzenie, Ŝe mediator sam jest
perspektywą,
która jest zdefiniowana na co najmniej jednym źródle danych. Wprawdzie nie
posiada
on
określonych
Ŝadnych
danych
własnych,
ale
ma
moŜliwość
operacji w taki sposób, jakby rzeczywiście
wykonywania
zawierał dane.
Podstawowym zaś zadaniem mediatora jest odwoływanie się do poszczególnych
źródeł danych w celu wykonywania określonych operacji takich jak na przykład
wyszukiwanie danych czy teŜ ich modyfikacja.
M oŜn a w yró Ŝnić co najm n iej dw ie m etod y d efin iow an ia m ed iatorów
P o d ejście L A V (lo cal – as – v iew ) – w m eto d zie tej
w szy stk ie
sch em aty
lo k aln e
d efin iu je
się
w
p o staci
w id o k ó w n ad sch em atem g lo b aln y m . U Ŝyw a się w tym celu
p o jęć, k tó re są sto so w an e w łaśn ie w sch em acie g lo b aln y m .
P o d ejście G A V (g lo b al – as – v iew ) – w m eto d zie tej
sch em at g lo b aln y d efin iu je się jak o w id o k p o n ad zb io rem
d an ych sch em ató w lo k aln ych .
M ed iatory o d gryw ają o grom n ą ro lę w
p ro cesie integracji danych . M oŜn a
p ow ied zieć, Ŝe p o dstaw ow ym zadan iem m ediato ra jest zbieranie in fo rm acji, k tó re
dotyczą
pewnego
obiektu, z
jednego
bądź
teŜ
kilk u
źródeł danych. P odczas
gro m adzenia takich in fo rm acji usuw a się p ow tarzające się d an e i rozw iązu je się
problem y
dotyczące
niespójności
danych.
W yn ikiem
pracy
m ed ia tora
jest
u jed n o licen ie sem a n ty k i d an y ch zn a jd u ją cy ch się w sy stem ie o ra z stw o rzen ie
tra n slatora op era cji d o ty czący ch sch em atu lo k aln eg o i lo k aln ych sch em a tów
źródeł.
Analityczne przetwarzanie bezpośrednie.
Pojęcie OLAP wprowadzono celem zdefiniowania architektury, która
jest w stanie obsłuŜyć skomplikowane czynności analityczne takie jak na
przykład :
konsolidacje,
która
polega
na
agregowaniu
pewnych,
wcześniej
zagregowanych danych w dane o innych obiektach. Na przykład, w bazie
opisującej wyŜsze uczelnie agregujemy dane o instytutach i katedrach w obiekty
wydziały, a te z kolei agregujemy w dane o uczelniach,
drąŜenie
czyli
operacja
odwrotną
do
konsolidacji
która
polega
na
przedstawianiu jak największej ilości szczegółowych danych
obracanie czyli czynność pozwalającą na przeanalizowanie tych samych
danych w kontekście róŜnych sytuacji, najczęściej na osi czasu,
obsługę wielu uŜytkowników równocześnie w zakresie dostępu do danych,
zapewnienie wewnętrznej wymiarowości czyli wszystkie wymiary w bazie
danych
powinny
posiadać
moŜliwościach działania.
swój
odpowiednik
w
strukturze
oraz
w
Technika OLAP posługuje się narzędziami które powinny spełniać
określone reguły takie jak:
1. przezroczystość , czyli niewidoczność dla uŜytkownika,
2. dostępność,
moŜliwość
korzystania
z
danych
zawartych
w
źródłach w róŜnych formatach
3. stała efektywność raportowania, czyli uŜytkownicy nie powinni
odczuwać spadku efektywności pracy systemu w razie takich
zmian jak chociaŜby powiększanie się rozmiarów baz danych
4. architektura klient – serwer,
5. elastyczność
raportowania
,wygląd
danych
wygodny
dla
uŜytkownika
6. wielowymiarowa perspektywa koncepcyjna, narzędzia OLAP
powinny posługiwać się łatwym w uŜyciu, wielowymiarowym
modelem, który niejako obrazowałby to, w jaki sposób firma
widziana jest przez uŜytkowników,
7. nieograniczoność
wymiarów
i
poziomów
agregacji,
Ŝadne
narzędzie OLAP nie moŜe mieć wpływu na liczbę wymiarów w
modelu analitycznym
Technika OLAP znalazła przede
wszystkim
zastosowanie w
hurtowniach danych.
Przetwarzanie analityczne powinno charakteryzować się następującymi cechami
1. analiza olbrzymiej ilości danych dla duŜej liczby uŜytkowników powinna
być procesem efektywnym,
2. sposób przechowywania danych nie moŜe mieć wpływu na ich późniejszą
prezentację,
3. obsługa zapytań czy wszelkiego rodzaju obliczeń musi następować w
sposób niezwykle szybki,
4. powinna istnieć moŜliwość wykonywania takich operacji jak: agregacja,
prognozowanie, wykonywanie obliczeń statystycznych, obsługa operacji
wielowymiarowych,
5. powinno być moŜliwe bezproblemowe przedstawianie wyników analiz w
róŜnych formach, takich jak raporty czy teŜ arkusze kalkulacyjne.
Aby moŜna było spełnić te wszystkie warunki konieczne stosowanie
odpowiednich, wielowymiarowych struktur danych.
STRUKTURY WIELOWYMIAROWE.
Po d s t a w o w y m el emen t e m j es t f a kt .
Fa kt y z ko l ei o pi s u j e s i ę t a k z w a n y mi mi a ra mi , k t ó r e za zwycz aj
s ą at r yb u t ami l i cz b o wymi
Zb i ó r f a kt ó w t w o r zy t a b el ę f a kt ó w .
T a be l a t a re pr ez en t u j e zd a rze n i a l u b o b i e kt y .
O b i e kt y
są
o s a d zo n e
t r ó j w y mi a ro w e j
s ześ ci en n ej ,
w
p rze s t rz en i
r ep r eze n t o w a ne j
g dz i e
j ed ny m
z
w i e l o w y mi a ro w ej
j a ko
w y mi a r ó w
p u n kt y
mo Ŝe
być
w
na
n p.
ko s t c e
p rz y kł a d
cz a s .
Ta k i e
p o d ejś ci e
n i es i e
za
sobą
k o n i e cz n o ś ć
wp r o wa d z en i a
i
u Ŝywa n i a d r u g i eg o o b o k f a k t ó w r o d za ju t ab el i : t ab el i wymi ar ó w.
T a be l e
w y mi a r ó w
z b ud o w a n e
są
z
kr o t ek
a t r y bu t ó w
o dp o w i ed n i ch w y mi a ró w .
Tab el e
faktów
n a t o mi as t
mo Ŝ n a
sobie
wyo b r aŜa ć
ja k o
p ewn ą
s t r u k t u r ę, k t ó r a za wi er a w s o b i e p o je d n e j k r o t ce d l a k a Ŝd eg o z
f a k t ó w z ar eje s t r o wa n yc h w h u r t o wn i d a n yc h . KaŜd y f ak t z awi e r a
zmi e n n e ,
które
o d p o wi e d n i c h
i n f o r mac je,
r o z p o z n a je
t ab el
które
p r zy
wymi a r ó w.
d ają
Ta b e l a
mo Ŝl i wo ś ć
k r o t e k w o d p o wi e d n i c h wymi a r a ch .
p o mo c y
ws k a źn i k ó w
f ak t ó w
za wi er a
z i d en t yf i k o wa n i a
do
takie
ws zys t k i c h
Dane zorganizowane jako kostka wielowymiarowa.[1]
Dane wielowymiarowe poddaje się kilku operacjom takim jak [17]:
1. obracanie- moŜna zmienić perspektywę z której widzi się na dane,
2. selekcja -moŜna wybrać tylko te elementy wymiarów, które są dla nas
istotne, a pozostałe z nich pominąć,
3. projekcja czyli zredukowanie liczby wymiarów i zaprezentowanie
zagregowanych
danych
z
usuniętych
wymiarów
w
pozostałych
wymiarach,
4. wycinanie czyli połączenie operacji selekcji oraz projekcji co pozwala na
przeprowadzenie projekcji tylko dla wybranych elementów odpowiednich
wymiarów,
5. ranking czyli szeregowanie elementów wymiaru według odpowiednich
wytycznych,
6. zwijanie oraz rozwijanie – czyli nawigacja po hierarchii wymiarów, przy
czym zwijanie polega na uogólnianiu poziomów w tej hierarchii,
natomiast rozwijanie na jej uszczególnianiu,
In te rp re ta c ja d a n yc h w ie lo w ym ia ro w yc h p ro w a d z i d o w yo d rę b n ie n ia d w ó c h typ ó w
p o jęć:
R O L A P - re la c y jn e sy ste m y O L A P ,
M O L A P - w ie lo w y m ia ro w e sy ste m y O L A P .
W
rela cy jn y ch sy stem a ch R O L A P
d an e są p rz ech o w yw an e w relacjach o
sp ecjaln ej stru k tu rz e n az w an ej sch em atem typ u g w iaz d a lu b p łatek śn ieg u . Jed n ą z
tych
relacji
jest
tab ela
z a g re g o w a n e . In n e
fak tó w
relacje
z aw ierająca
z aw ierają
tak
in fo rm acje
zw ane
o
dane
w arto ściach
su row e,
cz yli
n ie
u po rząd ko w an ych
w z d łu Ŝ k aŜ d eg o w ym iaru . D la R O L A P jest sp ecjaln ie d o b ran y jęz yk z ap ytań .
Jęz yk ten p o zw ala n a:
• p rzec h o w y w an ie o g ro m n y ch ilo ści d an y ch ,
• w y stęp o w an ie zło Ŝo n y c h
ty m ,
Ŝe
z a le Ŝ n o śc i
stru k tu r d a n y c h , k tó re sp o w o d o w a n e je st
w ie lo w y m ia ro w e
m uszą
w
ja k iś
sposób
być
o d w z o ro w a n e re la c y jn ie ,
• sto su n k o w o
stru k tu ry
n isk ą
w y d a jn o ść , k tó re j g łó w n ą
re la c y jn e
n ie
są
w
dogodny
p rzyczyną
sposób
je s t to , Ŝ e
d o sto so w an e
do
a n a liz w ie lo w y m ia ro w y c h ,
• d o ść ła tw ą
m o d y fik a c ję d a n y c h .
N a jw ię k s z e w a d y te g o ty p u s y s te m ó w to n is k a w y d a jn o ś ć z a p y ta ń i c z a s
ja k i
p o trzeb n y
je s t
na
u zy sk a n ie
o d p o w ie d z i.
S y stem y
te
są
je d n a k
b a rd z o c z ę sto w y k o rz y sty w a n e p rz y b u d o w ie h u rto w n i d a n y c h , g łó w n ie
z e w z g lę d u n a to , Ŝ e m o g ą p rzech o w yw ać n iez w yk le d u Ŝe ilo ści d an ych .
W systemach MOLAP dane są. przechowywane w specjalizowanej często zagregowanej
strukturze. Struktura ta zwana jest formalną kostką danych w odróŜnieniu od kostki danych
surowych. Podstawowe cechy systemów MOLAP to:
1. mniejsze moŜliwości w zakresie ilości przechowywanych danych,
2. reprezentowanie wielowymiarowych struktur w sposób naturalny,
3. wysoki poziom wydajności przeprowadzanych analiz wielowymiarowych,
4. stosunkowo trudna do realizowania modyfikacja danych, głównie z
powodu stosowania struktur wielowymiarowych
Systemy MOLAP najczęściej wykorzystuje się jako składnice danych lub struktury
pomocnicze dla hurtowni danych. Idealnym rozwiązaniem byłoby połączenie architektury
ROLAP i MOLAP w taki sposób aby umoŜliwiało
ono przechowywanie ogromnych ilości danych oraz przeprowadzanie efektywnych analiz
wielowymiarowych.
Relacyjna
historycznych
i
jak
baza
elementarnych
danych
słuŜyłaby
danych,
do
podczas
przechowywania
gdy
zadaniem
zarówno
serwerów
wielowymiarowych byłoby przechowywanie i przetwarzanie roboczych zbiorów danych
Modele wielowymiarowe danych zwane
kostkami, w rzeczywistości są
macierzami wielowymiarowymi.
Jeśli macierz taka posiada więcej niŜ trzy wymiary, to wtedy określa się ją
terminem hiperkostki.
Kostka danych jest skonstruowana w ten sposób, Ŝe moŜna ja dzielić wzdłuŜ
kaŜdego wymiaru na róŜnym poziomie granulacji czyli kaŜda komórka w
kostce danych powstaje w wyniku przecięcia wszystkich jej wymiarów.
Taki sposób ułoŜenia danych w strukturze wielowymiarowej zwiększa
wydajność zapytań w porównaniu relacyjnym modelem danych.
JeŜeli jednym z wymiarów jest czas to dzieląc na lat, miesiące czy dni
uzyskamy wszystkie informacje z tego okresu. Wybór sposobu dzielenia dla
kaŜdego wymiaru zaleŜy od tego jak szczegółowe informacje chcemy uzyskać.
W efekcie podziału uzyskujemy mniejsze kostki zawierające informacje
podobne do uzyskanych przez klauzulę SQL - ową GROUP BY. Przy pomocy
klauzuli WHERE zapytanie ma moŜliwość ograniczenia
do wybranych
przedziałów wzdłuŜ jednego lub więcej wymiarów. Zapytanie stanowi
podstawowy blok kwalifikacyjny SQL czyli SELECT…FROM….WHERE
z moŜliwością zastosowania dodatkowych klauzul.
Ogólna postać zapytania nazwanego krojeniem i kratkowaniem (ang. sliping and
dicing):
SELECT
atrybuty grupujące i agregacja
FROM
tablica faktów powiązana przez klucze obce z tablicam
i wymiarów
WHERE
ograniczenia do wybranych podziałów wzdłuŜ jednego
lub więcej wymiarów
GROUP BY atrybuty grupujące
Tabela wymiarów w1 Tabela wymiarów w2
w1
w2
Tabela wymiarów w3
w3
TABELA FAKTÓW
Atrybuty wymiarów Aw1,Aw2,.....
Rys.6 Atrybuty wymiarów z tabeli faktów wskazują klucze w tabelach wymiaru.
W ROLAP występują wspomniane juŜ schematy typu gwiazda oraz schemat
płatka śniegu.
Centrum gwiazdy stanowi tabela faktów, która zawiera odpowiedni zestaw
faktów. Tabela ta jest powiązana z innymi relacjami, wspomnianymi wyŜej
tabelami wymiarów. Tabele wymiarów opisują wartości faktów wzdłuŜ kaŜdego
wymiaru. Nawiązując do baz relacyjnych, kaŜdy atrybut wymiaru Awi, w tabeli
faktów jest kluczem obcym ( rys.6) odwołującym się do odpowiedniej tabeli
wymiarów W1, W2……,Wn
W schemacie gwiazdy wszystkie tabele wymiarów są połączone z tabelą faktów
relacjami typu „jeden do wielu”. Oznacza to, Ŝe kaŜda krotka danego wymiaru
jest połączona nie z jedną lecz z kilkoma krotkami faktów. Klucz główny tabeli
faktów natomiast tworzony jest poprzez połączenie kluczy głównych wszystkich
tablic wymiarów . Często zdarza się tak, Ŝe tabele faktów mają duŜe rozmiary, w
przeciwieństwie do tabel wymiarów, a powodem tego jest to, Ŝe niemal
wszystkie dane w hurtowniach danych reprezentowane są właśnie przez fakty.
P o d staw o w e ce c h y ch a ra k te rystyc zn e sch em a tu g w ia zd y to :
• p ro sto ta stru k tu ry,
• d u Ŝ a efe k tyw n o ść za p y ta ń , d zię k i m ałe j lic z b ie p o łą cz eń p o m ię d z y
tab elam i
• dość
d łu g i
czas
p o trzeb n y
na
załad o w an ie
danych
do
tab el
w y m ia ró w ,
• m o Ŝ liw o ść
dogodnej
w sp ó łp ra c y
z
h u rto w n iam i
danych
d z ię k i
istn ie n iu w ie lu n a rz ę d z i w sp o m a g a ją c y c h
Schem at
p ła tk a
śn ieg u
n a to m ia st
g w ia zd y . P o d sta w o w a ró Ŝn ica p o leg a
zn o rm a lizo w a n e,
aby
tw o rzy ły
uznać
m oŜna
za
o d m ia n ę
sch em atu
n a ty m , Ŝe ta b ele w y m ia ró w
h iera rch ię
Schem at
są
p ła tk a
tu
tak
śn ieg u
ch a ra k tery zu je się p rzed e w szy stk im :
• sp ad k ie m w y d ajn o ści z ap ytań w o d n ie sie n iu d o sc h em a tu g w ia zd y (
w ię k sz a lic z b a p o łąc z eń p o m ięd z y tab e lam i),
• s tru k tu rą b a rd z ie j sp rz y ja ją c ą w p ro w a d z a n iu m o d y fik a c ji,
• k ró tk im
czasem
p o trz e b n ym
na
załad o w an ie
danych
do
tab el
w y m ia ró w
Z e w zg lę d u n a m a łą efe k tyw n o ść z ap y tań cz ę śc ie j sto so w an y sch em a t
g w iazd y.
IM P L E M E N T A C J A K O S T E K Z A P O M O C Ą P E R S P E K T Y W
Z M A T E R IA L IZ O W A N Y C H .
K o m e rc y jn e sy s te m y k o s te k
w
o k re śle n iu
P e rsp e k ty w a
chcem y
te
są
na
m a te ria liz o w a n a
trw a le
ty p o w y m i
p ersp ek ty w y
b y ło
p e rsp e k ty w
za p a m iętać
a g reg atam i
m uszą
d o sta te c z n ie
być
one
danych
m o g ą p o m a g a ć u Ŝ y tk o w n ik o w i
z m a te ria liz o w a n y c h
k o stk i
je s t
z a p y ta n ia ,
w
to
b a z ie
w y n ik
A by
dość
duŜe,
N iŜ e j
k tó ry
d a n y c h . Z a z w y c z a j p e rsp e k ty w y
k o stk i.
szc ze g ó ło w e .
pew nego
danych.
z w ię k sz y ć
aby
u Ŝy tec zn o ść
z g ro m a d z e n ie
pokazano
p rz y k ła d
ta k ie j
w y m iaró w
p e rsp e k ty w
z m a te ria liz o w a n y c h .
P ie rw sz ą z b a z d a n y c h w y k o rz y sta n y c h w
p rz y k ła d z ie je s t b a z a „S k le p ” .
O g ó ln ie m o Ŝ n a p o w ie d z ie ć , Ŝ e je st to b a z a , k tó ra z b ie ra w in fo rm a c je n a
te m a t
p o sia d a n y c h
przez
sk le p
p ły t
m uzycznych
o raz
in fo rm a c je d o ty c z ą c e s a m e j s p rz e d a Ŝ y .
D iag ram
R y s .7
z w iąz k ó w
D ia g ra m
e n c ji b a z y „ S k lep ” p rz e d sta w ia się tak :
z w iąz k ó w
e n c ji b a z y „ S k le p ”
sz c z e g ó ło w e
Drugą z baz wykorz yst ywanych w prz ykł adz i e j est baz a „ Kli enci ”. J est to
prost a baza, z budowana j edyni e z dwóch tabel , prz echowująca podst awowe
dane dot ycz ące kli entów skl epu.
Diagram związków encji bazy „Klienci” przedstawia się następująco:
Rys.8 Diagram związków encji bazy „Klienci”
Widok
pierwszy
połączyć
obie
zaimplementowany
wykorzystywane
w
został
projekcie
w
taki
bazy
sposób,
danych.
aby
Jego
zadaniem jest takie przefiltrowanie odpowiednich tabel obu baz
danych,
nazwisku
aby
moŜna
klienta,
było
stylu
uzyskać
muzycznym,
informacje
do
o
którego
imieniu
oraz
zaliczana
jest
kupiona przez niego płyta oraz dacie, która powie nam kiedy
dokonano sprzedaŜy.
Diagram tego widoku przedstawia poniŜszy rysunek:
Rys.9 Diagram widoku 1 zmaterializowanego
A oto kod, przy pomocy którego powstał Ŝądany widok:
SELECT TOP (100) PERCENT Klient.dbo.KLIENT.IMIE,
Klient.dbo.KLIENT.NAZWISKO,
dbo.STYLE.NAZWA_RODZAJU,
dbo.SPRZEDAZ.DATA_SPRZEDAZY
FROM
Klient.dbo.KLIENT INNER JOIN
dbo.SPRZEDAZ ON Klient.dbo.KLIENT.ID_KLIENTA =
dbo.SPRZEDAZ.ID_KLIENTA INNER JOIN
dbo.PLYTY ON dbo.SPRZEDAZ.ID_PLYTY =
dbo.PLYTY.ID_PLYTY INNER JOIN
dbo.STYLE ON dbo.PLYTY.ID_RODZAJU =
dbo.STYLE.ID_RODZAJU
ORDER BY Klient.dbo.KLIENT.NAZWISKO
Widok drugi z kolei zaimplementowany został jedynie na bazie
„Sklep”. Celem jego utworzenia było wybranie z tej bazy informacji
o ilości poszczególnych płyt kaŜdego wykonawcy, które zostały
sprzedane w sklepie oraz o dacie tejŜe sprzedaŜy.
Diagram tego widoku przedstawia rysunek 10:
Rys.10 Diagram widoku 2 zmaterializowanego
K od, który pozw olił na utw o rz enie tego w idok u w ygląda nastepu jaco :
S E L E C T dbo.W Y K O N A W C Y .N A ZW A , dbo.P L Y T Y .T Y T U L _P LY T Y ,
d bo.S P R Z E D A Z.D A T A _S P R Z E D A ZY , dbo.SP R ZE D A Z .ILO S C
FROM
dbo.P LY T Y IN N E R JO IN
d bo.W Y K O N A W C Y O N dbo .P LY T Y .ID _W Y K O N A W C Y =
d bo.W Y K O N A W C Y .ID _W Y K O N A W C Y
IN N ER JO IN
d bo.S P R Z E D A Z O N dbo.P LY T Y .ID _ P LY T Y = dbo.S P R Z E D A Z .ID _P LY T Y
W id ok trz eci p odob nie jak w idok p ierw szy zo stał zaim plem en to w an y w taki
spo sób aby łączył dw ie utw orzo ne dla p otrz eb przyk ład u bazy. W ido k ten p ozw ala
uz yskać inform acje na tem at tego jakie ilości poszczególnych p łyt po szcz egó ln ych
w ykonaw ców sprzedano w róŜnych m iejscow ościach.
D iag ram teg o w id o k u p rzed staw ia rys.1 1
R ys.11 D iagram w id oku 3 zm aterializo w an ego
Kod, który pozwolił na utworzenie tego widoku wygląda natomiast tak:
SE LE CT Klient.d bo. ADRE SY.M I E J SCOW OSC, dbo .W YKON AWCY.NAZWA,
db o.P LYT Y .T YT UL_ P LY T Y, dbo .SP RZED AZ.I LOSC
FRO M
db o.W YK ONAW CY IN NE R J O IN
db o.P LYT Y ON dbo .W YKON AWCY.I D_ WYK ONAW CY =
db o.P LYT Y .I D_W YK ONAW CY IN NE R J O IN
db o.SP RZE DAZ ON dbo .P LY T Y.I D _P LYT Y = db o.SP RZE DAZ.I D_P LYT Y I NN ER J OI N
Klie nt.dbo .ADRESY I NNE R JO I N
Klie nt.dbo .KLI EN T ON Klie nt.dbo .ADRE SY. I D_KLI E NT A =
Klie nt.dbo .KLI EN T .I D_ KLI E NT A ON
db o.SP RZE DAZ.I D_K LI E NT A = Klient. dbo .KLI E NT .I D_K LI E NT A
Istnieje moŜliwość przyspieszenia wielu zapytań poprzez zastosowanie
specjalizowanego operatora kostki CUBE, który słuŜy do wstępnego agregowania
tabeli faktów wzdłuŜ wszystkich podzbiorów wymiarów. Mocniejszym sposobem
jest utworzenie siatki ziarnistości do agregowania wzdłuŜ wszystkich wymiarów.
Siatka ta nosi nazwę kraty perspektyw. Umieszczanie zapytań w kracie perspektyw
pomaga przy projektowaniu baz danych opartych na kostkach danych. W procesie
projektowania najpierw ustala się zbiór zapytań jakie są przewidywane do
określonych zastosowań. Następnie określa się zbiór perspektyw do
zmaterializowania.

Podobne dokumenty