hurtownia%2Bdanych praca%2Binzynierska

[ Pobierz całość w formacie PDF ]
.13).Wymaganiem, jakie stawiamy tworzonemu jest ciągłe utrzymywanie jego zawartości w stanie spójności w stosunku do źródłowych informacji.Oznacza to utrzymywanie informacji w magazynie w stanie zgodnym ze stanem źródłowych baz danych.Ta cecha odróżnia nasz system od typowych systemów OLAP, a wprowadzamy taką innowację ze względu na wymagania firm korzystających z takich systemów informacji - zwykle decyzje podejmuje się szybko i wiele zależy od szybkiego uzyskania aktualnych informacji.Owa szybkość uzyskiwania informacji narzuca kolejną pożądaną cechę systemu - jego efektywność.Ponieważ jest to dosyć istotna sprawa, nasz system musi składować dane inkrementalnie - czyli uzupełniać zawartość magazynu jedynie o nowe informacje.Kolejnym założeniem projektowanego systemu jest komunikacja z użytkownikiem za pomocą języka SQL.Wynika to z faktu, iż język ten jest dziś standardem w dziedzinie relacyjnych bazach danych i jego wybór jest właściwie naturalny.W kolejnym punkcie przedstawiono architekturę systemu i wymagania, jakie stawiamy jego otoczeniu, a dalej opisano przeznaczenie wszystkich modułów systemu.lArchitektura systemulArchitekturę projektowanego systemu można przedstawić na rysunku:Całość systemu składa się z kilku elementów: magazynu danych, źródłowych baz danych i czterech modułów projektowanego systemu „rozpiętych” pomiędzy tymi bazami, a użytkownikiem.Zakładamy istnienie poprawnie skonstruowanych źródłowych baz danych - za ich utrzymywanie odpowiedzialny jest odbiorca systemu.Zakładamy również fizyczne istnienie bazy danych przeznaczonej na magazyn.Sam projekt składa się z czterech głównych modułów - query processora, integratora, monitora i wrappera oraz narzędzi konfiguracyjnych.Aby dokładnie omówić zadania systemu, niezbędne jest przedstawienie jego wymagań, co do struktury źródłowych baz danych.lWymagania dla źródłowych baz danychlZ założeń systemu (jest to system ROLAP) wynikają wymagania, jakie muszą spełniać źródłowe bazy danych.Przyjęliśmy, że układ relacji w tych bazach ma układ płatka śniegu.Dokładne założenia tej struktury są następujące:lW zbiorze relacji możemy wyróżnić jedną relację centralną, zwaną tabelą faktów.Gromadzi ona informacje o wartościach liczbowych pewnych operacji, np.o wartościach sprzedanych towarów, ilości itd.llPozostałe relacje nazywamy relacjami bocznymi - zawierają one jedynie informacje o podmiotach, na których są wykonywane operacje - np.w przypadku systemu sprzedaży o towarach, klientach, sprzedawcach itd.llKlucz główny relacji bocznej składa się z jednego atrybutu (jest to zwykle identyfikator numeryczny, ale nie jest to wymogiem).llRelacje mogą łączyć się ze sobą za pomocą kluczy obcych, przy czym atrybutem wskazywanym przez klucz obcy musi być klucz główny relacji bocznej.llUkład relacji wraz z powiązaniami tworzy strukturę płatka śniegowego.Jego centrum stanowi relacja centralna, która zawiera powiązania do relacji bocznych, te zaś zawierają powiązania do kolejnych relacji bocznych itd.Wymogiem jest, aby klucz obcy tworzący powiązanie zawsze wskazywał na relację boczną tworzącą nową gałąź, a nie dołączał się do gałęzi już istniejącej.Inaczej mówiąc: każda relacja może zawierać wiele kluczy obcych, ale może być wskazywany tylko przez jeden klucz obcy.lAby zobrazować tę strukturę, przedstawimy przykładowy schemat prawidłowo utworzonych relacji źródłowych - schemat systemu sprzedaży:Klucze obce podkreślono na rysunku linią przerywaną, natomiast klucze główne linią ciągłą.Klucz obcy `zamówienie' relacji `sprzedaż' wskazuje na klucz główny relacji `zamówienia' (`id'), klucz obcy `towar' w relacji `sprzedaz' wskazuje na klucz główny `id' w relacji `towary', itd.Podobnie z relacjami bocznymi - klucz obcy `kategoria' relacji `towary' wskazuje na klucz główny relacji `kategorie' (`id') itd.Relacja centralna zawiera dwa atrybuty nie będące kluczami - `ilość' i `wartość'.Każdy wpis w tabeli `sprzedaż' opisuje więc jeden fakt sprzedaży - podaje identyfikatory klienta, sprzedawcy, towaru, itd.oraz wartość sprzedaży i ilość sprzedanych towarów.Korzystając z dalszych relacji bocznych możemy również na podstawie tego faktu określić do jakiej kategorii należy sprzedany towar, do jakiego województwa trafił itd.Jak widać, przykład nie wykorzystuje wszystkich możliwości układu płatka śniegu - z każdej relacji bocznej może przecież wychodzić więcej niż jedno powiązanie z kolejnymi relacjami.Jest jednak wystarczający do zilustrowania struktury ROLAPu i będzie często wykorzystywany w dalszej części pracy jako przykład.Efektem prawidłowo działającego systemu powinno być utrzymywanie w magazynie (przez cały czas pracy systemu) zagregowanych danych zawierających wartości funkcji grupujących, których argumentem będą wybrane atrybuty relacji centralnej (w przedstawionym przykładzie byłyby to `ilość' i `wartość') pogrupowane według różnych kombinacji kluczy głównych relacji bocznych.Umożliwi to „wyciąganie” z magazynu informacji typu: „ile towarów z branży kosmetycznej trafia do różnych województw?”, „Jak rozkłada się sprzedaż dla konkretnego klienta w poszczególnych miesiącach?” itd.Są to zwykle informacje mające dla firmy znaczenie strategiczne - mówiące gdzie inwestować, dokąd lepiej sprzedawać itd.W naszym przypadku w magazynie zbieramy zagregowane wartości pięciu funkcji grupujących języka SQL.Są to:lAVG - wartość średnia,llSUM - suma,llMIN - wartość minimalna,llMAX - wartość maksymalna,llCOUNT - liczba krotek.llFunkcje poszczególnych modułów systemulJak już zaznaczono, w skład projektu wchodzą cztery moduły, współpracujące ze sobą oraz moduł do konfiguracji systemu.Od modułu konfiguracji wymaga się przede wszystkim łatwości obsługi i przejrzystego interfejsu użytkownika.Program sam powinien zapytać o wszystkie niezbędne informacje (adresy źródłowych baz danych, schematy relacji itd.) i poprawnie skonfigurować system magazynowania.Wymagany jest interfejs graficzny.Moduł query processora jest pośrednikiem pomiędzy użytkownikiem, a magazynem danych.Jak wcześniej zaznaczono, użytkownik komunikuje się z tym modułem w języku SQL, zadaniem query processora jest natomiast zrealizowanie jego poleceń.Ponieważ użytkownik korzysta z informacji zawartych w magazynie w trybie „tylko do odczytu”, jego polecenia są zapytaniami (queries) [ Pobierz całość w formacie PDF ]

Linki