Temporalne magazyny danych

Magazyny danych (1) Magazyn danych (hurtownia danych) – zintegrowana materializowana perspektywa (zbiór perspektyw) zdefiniowana na zbiorze heterogenicznych i autonomicznych źródeł danych (systemy informatyczne funkcjonujące w danym przedsiębiorstwie)

Magazyny danych (2)

Magazyny danych (4) PKB w Niemczech – aktualne rozwiązania Ignoruj połączenie Niemiec (Skąd wziął się skok PKB dla FRG pomiędzy rokiem 1989 a 1990?) Usuń rozszerzenie GDR (gubimy informację o GDR w latach )

Poprawna ewolucja schematu czas Ignoruj : GDR FRG obecnie Usuń : FRG Poprawnie : GDR FRG Niemcy

Problem założenie (większość systemów magazynów danych) - wymiary magazynu danych są stałe i wzajemnie ortogonalne wymiary nie są stałe i również ewoluują: struktura organizacyjna przedsiębiorstwa się zmienia, produkty znikają z rynku, pojawiają się nowe produkty, zmieniają się również miary i ich relacje do wymiarów

Podstawowe pojęcia sklep sklepId adres typ rozmiar miasto il_miesz region nazwa_reg produkt prodId nazwa typ podatek klientId nazwa adres miasto klient sprzedazId data klientId prodId sklepId ilość podatek sprzedaż Tablice wymiarów Tablica faktów miary

Struktura gwiazdy

Hierarchia wymiaru Atrybuty opisujące pojedynczy wymiar tworzą hierarchię nazywaną hierarchię wymiaru - umożliwia definiowanie różnych poziomów agregacji danych sklep typ miasto region Hierarchia wymiaru może być reprezentowana w magazynie danych implicite w pojedynczej tablicy wymiaru lub explicite w postaci zbioru powiązanych tablic reprezentujących jeden wymiar

Płatek śniegu

Ewolucja magazynów danych Aspekt dynamiczny świata zewnętrznego : nowe fakty modyfikacja elementów tablic wymiarów modyfikacja hierarchii wymiarów modyfikacja relacji pomiędzy miarami a wymiarami modyfikacja relacji pomiędzy miarą a hierarchią wymiaru Aktualnie aspekt dynamiczny świata rzeczywistego jest odzwierciedlany tylko i wyłącznie w tablicach faktów, podczas gdy tablice i hierarchie wymiarów pozostają niezmienione (reprezentują aspekt statyczny)

Ewolucja schematu - Przykład 1 Zapytanie: „ Podaj łączną sprzedaż różnych typów produktów z podziałem na sklepy” Załóżmy, że w 6/05/01 produkt p1 został zaklasyfikowany do typu t2. interpretacja wyniku (2 możliwości) źle naliczono podatek

Ewolucja schematu - Przykład 2 Załóżmy, że w dniu 3/01/2001 nastąpiło połączenie sklepów s1 i s2, a na ich miejsce pojawił się nowy supermarket s4. Usunięto zatem z magazynu danych krotki opisujące sklepy s1 i s2, i wprowadzono krotkę opisującą sklep s4. Co z krotkami opisującymi sprzedaż w sklepach s1 i s2 pamiętanymi dotychczas w tablicy faktów ?

Ewolucja schematu - Przykład 2 Usuwamy krotki reprezentujące s1 i s2 (opcja delete): „manko” w ilości sprzedanych produktów jak w ostatnich latach wyglądała sprzedaż z podziałem na małe i duże sklepy ? Pozostawiamy krotki reprezentujące s1 i s2 (krotki s1 i s2 również zostają – opcja ignore): średnioroczna sprzedaż produktów w poszczególnych sklepach Podobnie jak w przykładzie z PKB Niemiec, poprawna inter- pretacja musi uwzględnić czas aktualizacji magazynu danych

Ewolucja schematu - Przykład 3 sprzedazId dateId klientId prodId sklepId ilość prodId nazwa typ podatek sklepId adres typ wielkość miasto il_miesz region klientId nazwa adres miasto podatekId dateId sklepId podatek dateId dzień miesiąc rok ProduktSklep Klient Czas Podatek Sprzedaż Konstelacja faktów

Ewolucja schematu - Przykład 3 Załóżmy, że dotychczas podatek był płacony od wielkości sklepu niezależnie od wartości sprzedanych produktów czy też zysku. Podatek był płacony rocznie ryczałtem Załóżmy, że zmieniono zasady obliczania podatku i przyjęto zasadę, że podatek jest płacony raz w miesiącu od zysku (lub obrotu) ze sprzedaży produktów W jaki sposób obliczyć średnią wartość podatku płaconą rocznie od sprzedaży produktów określonego typu?

Problemy związane z ewolucją schematów Kwestia interpretacji wyników: W jaki sposób zdefiniować na poziomie zapytania kontekst zapytania (jak było poprzednio czy jak aktualnie)? W jaki sposób modyfikować np. tablicę wymiarów (delete czy ignore)? W jaki sposób interpretować otrzymany wynik? Kwestia istniejących raportów analitycznych: Raporty nie ulegają zmianie Raporty wymagają modyfikacji Raporty są trudno interpretowalne Raporty niepoprawne i niemodyfikowalne

Temporalne i/lub wielowersyjne magazyny danych (1) Większość proponowanych rozwiązań opiera się na propozycji wprowadzeniu do magazynów danych elementów systemów temporalnych lub wielowersyjnych Podstawowym mechanizmem, którego zadaniem jest umożliwienie śledzenia zmian zachodzących w schemacie magazynu danych, jest mechanizm etykiet czasowych (ang. timestamp) Każdy obiekt w magazynie danych otrzymuje etykietę czasową. Etykieta czasowa obiektu określa przedział czasu, w którym obiekt jest ważny (aktualny)

Temporalne i/lub wielowersyjne magazyny danych (2) Przez obiekt rozumiemy rekordy tablic wymiarów, rekordy tablic faktów, przypisanie elementów tablic wymiarów do hierarchii wymiarów, zależności pomiędzy miarami a wymiarami Przydzielenie etykiet czasowych do obiektów w magazynie danych pozwala na wyspecyfikowanie różnych wersji schematu logicznego magazynu danych. Wersje te reprezentują spójny stan magazynu danych w określonym przedziale czasowym

Etykietowany wymiar Każdy wymiar składa się z dwóch elementów: składników wymiaru (rekordy tablic wymiarów) oraz hierarchicznej relacji opisującej zależności pomiędzy składnikami danego wymiaru (graf hierarchii wymiaru) [M1, M3] [M4, ∞][M1, ∞] [M4, ∞] Wydzia³ [M1, M3] Produkt [M1, ∞] Typ_1 [M1, ∞] Typ_2 [M1, ∞] Typ_3 [M1, ∞] Produkt A [M4, ∞] Produkt B [M4, ∞] [M1, ∞]

Wielowersyjny magazyn danych Dwie wersje schematu logicznego magazynu danych, które obowiązywały w dwóch różnych okresach czasu: Wersja SV1: ważna w okresie od M1 do M3 - Wersja SV2: ważna w okresie od M4 do ∞ - <SV2, [M4, ∞ ], {{Produkt, Typ_1, Typ_2, Typ_3, Produkt A, Produkt B}, {miara}, { Typ_1 → Produkt, Typ_2 → Produkt, Typ_3 → Produkt, Produkt A → Typ_1, Produkt B → Typ_1,...}}>

Operatory zmian struktury wymiaru Koncepcja temporalnego wielowersyjnego magazynu danych wymaga nowych operatorów służących do pielęgnacji temporalnego wielowersyjnego magazynu danych. Trzy podstawowe operatory zmian struktury logicznej tablicy wymiaru (insert, delete, update) Operatory złożone: split (podziel pojedynczy składnik wymiaru na n składników), merge (połącz n składników wymiaru w jeden składnik), change (zmień wartość atrybutu składnika wymiaru), move (zmień pozycje składnika w hierarchii wymiaru), new-member (wprowadź nowy składnik), delete-member (usuń składnik wymiaru).

Operatory zmian schematu logicznego magazynu danych Uwzględniając inne możliwe modyfikacje schematu logicznego magazynu danych zbiór operatorów musi być, dodatkowo, rozszerzony m. in. o: operacje modyfikacji tablic faktów (np. zmiana schematu płatka śniegu na schemat konstelacji faktów, operacje łączenie dwóch tablic faktów czy też ich podział, wprowadzenie nowego faktu) operacje modyfikacji relacji pomiędzy tablicami faktów a wymiarami

Ograniczenia integralnościowe Ograniczenia integralnościowe: ograniczenia integralnościowe związane z pojedynczą wersją schematu logicznego magazynu danych (ograniczenia intra-wersyjne) ograniczenia integralnościowe pomiędzy wersjami schematu logicznego magazynu danych (ograniczenia inter-wersyjne)

Język zapytań Powinien umożliwiać definiowanie kontekstu zapytania – przez kontekst rozumiemy schemat logiczny magazynu danych istniejący w danej chwili czasowej (reprezentowany przez określoną wersje schematu logicznego) Zapytanie „Podaj produkt krajowy brutto w okresie od 1970 – 1994” odnosi się do składników wymiarów istniejących w schemacie magazynu danych w roku 1979 (NRD, RFN, Czechosłowacja)

Język zapytań – funkcja transformacji (1) Można wyróżnić następujące przypadki formułowania zapytań do wielowersyjnego temporalnego magazynu danych: zapytanie jest formułowane w odniesieniu do danych należących do pojedynczej wersji schematu. Ten przypadek odpowiada zapytaniu do klasycznego magazynu danych zapytanie jest formułowane w odniesieniu do danych należących do dwóch kolejnych wersji schematu magazynu danych. Jeżeli istnieje funkcja transformująca dane pomiędzy tymi wersjami danych, to po transformacji otrzymujemy przypadek (1). Jeżeli taka funkcja jest niezdefiniowana, to wynik zapytania jest „niezdefiniowany”

Język zapytań – funkcja transformacji (2) Można wyróżnić następujące przypadki formułowania zapytań do wielowersyjnego temporalnego magazynu danych: zapytanie jest formułowane w odniesieniu do danych należących do dwóch, ale nie kolejnych wersji schematu magazynu danych. Jeżeli istnieje funkcja transformująca dane pomiędzy tymi wersjami danych, to po transformacji otrzymujemy przypadek (1). Jeżeli taka funkcja jest niezdefiniowana, to wynik zapytania jest „niezdefiniowany” zapytanie jest formułowane w odniesieniu do danych należących do trzech i więcej wersji schematu magazynu danych. Jeżeli istnieją funkcje transformujące dane pomiędzy tymi wersjami danych do jednej wybranej wersji schematu, to po transformacji otrzymujemy przypadek (1). Jeżeli takie funkcje są niezdefiniowane, to wynik zapytania jest również „niezdefiniowany”