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.