Jakie jest najlepsze podejście, aby uzyskać z relacyjnej bazy danych OLTP do kostki OLAP?

Mam dość standardową bazę danych OLTP znormalizowaną i zdałem sobie sprawę, że muszę wykonać kilka złożonych zapytań, średnie, odchylenia standardowe w różnych wymiarach danych.

Więc zwróciłem się do SSAS i tworzenia kostek OLAP.

Jednak aby utworzyć kostki uważam, że moja struktura źródła danych musi być w konfiguracji "gwiazdy" lub "płatka śniegu" (co nie wydaje mi się teraz).

Jest normalną procedurą, aby użyć SSIS do zrobienia pewnego rodzaju ETL przetwarzać na moim głównym OLTP DB do innego relacyjnego DB, który jest w odpowiedniej konfiguracji "gwiazdy" z faktami i wymiarami, a następnie użyć tego DB jako źródła danych dla kostek OLAP?

Thanks

Author: dan, 2009-06-23

2 answers

Tak, to jest podstawowa idea. Bierzesz wysoce znormalizowaną bazę danych OLTP i dekormalizujesz ją w kostki w celu pokrojenia i pokrojenia danych, a następnie przedstawienia raportów na jej temat. Technika projektowania logicznego nazywana jest modelowaniem wymiarowym. Istnieje mnóstwo wspaniałych informacji na temat modelowania wymiarowego w Kimball Group. Książki Ralpha Kimballa na ten temat są również doskonałe. Jeśli chcesz dowiedzieć się więcej o samych narzędziach BI, sprawdź virtual labs na SSIS, usługi analityczne i więcej.

 8
Author: JP Alioto,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-06-23 05:28:57

Odpowiedź brzmi: tak, ale.

Wymiar w SSAS ma relacje między atrybutami, które mogą być używane jako seria pól do filtrowania slice przez. Relacje te mogą być hierarchiczne ( więcej niż jeden poziom głębokości-jeden atrybut może mieć rodzica i dzieci. Można również ustanowić ścieżki drill down (zwane hierarchiami w SSAS), które działają jak atrybuty, ale mają przewodnik drilldown.

Aby to zrobić musisz mieć klucze dostępne w bazie danych, które żyją w ściśle hierarchiczna relacja (tzn. klucze nie mogą mieć rozmytych relacji, w których dziecko może mieć więcej niż jednego rodzica). Zauważ, że to nie jest cała historia, ale jest wystarczająco blisko rzeczywistości na ten moment.

Te hierarchie mogą być skonstruowane z płaskiej struktury danych przez system lub przedstawione za pomocą płatka śniegu z relacjami zaznaczonymi w podstawowym widoku źródła danych (DSVs są częścią metadanych kostki i mogą być używane do masażu danych w sposób podobny do widoki bazy danych).

Płatek śniegu jest schematem 3NF-owskim (nie musi to być 3NF - można spłaszczyć jego części w praktyce), który ma tylko relacje 1: M. SSAS mogą obsługiwać kilka innych struktur wymiarowych, takich jak parent-child (relacja rodzic-dziecko z rekurencyjnym połączeniem własnym) I m: m dimensions (relacje M:M - dokładnie to, jak brzmią). Wymiary tego typu są bardziej skrzywione, ale mogą być dla Ciebie przydatne.

Jeśli w danych źródłowych masz klucze, które mogą mieć równoważna semantyka danych do płatka śniegu wtedy możesz być w stanie wypełnić swoją kostkę poprzez serię widoków baz danych w systemie źródłowym, które prezentują podstawowe dane w formacie wystarczająco podobnym do płatka śniegu, aby użyć do wymiarów sześcianu (zrobiłem to już kilka razy). Schematy, które sprawiają, że ciężkie korzystanie z kluczy syntetycznych są bardziej prawdopodobne, aby działać dobrze na to.

Jeśli twój sprzedawca lub inne strony nie pozwolą Ci dodawać widoków do bazy źródłowej, możesz użyć zamiast tego Widok źródła danych. DSV mogą mieć wirtualne tabele o nazwie "named queries", które są wypełniane z zapytania bazy danych.

Tabele faktów łączą się z wymiarami. W SSAS2005+ można dołączyć różne tabele faktów w różnych ziaren w ramach wymiaru. Zwykle nie przydałoby mi się to w hurtowni danych, ale ta funkcja może być przydatna, jeśli próbujesz użyć danych źródłowych bez konieczności ich zbytniego masowania.

Jeśli to nie zadziała to może będziesz musiał napisać proces ETL, aby wypełnić schemat gwiazdy lub płatka śniegu.

Kilka zapisów:

  1. Kostki mogą być uruchamiane w trybie czasu rzeczywistego, w którym po prostu wysyłają zapytanie do bazowych danych. Wiąże się to z pewnym ryzykiem tworzenia nieefektywnych zapytań na podstawie danych źródłowych, więc nie jest to zalecane, chyba że jesteś naprawdę pewny, że wiesz, co robisz.

  2. Apropos (i), prawdopodobnie nie będzie w stanie użyć kostki jako źródło danych dla ekranów w Twoim podanie. Jeśli chcesz obliczyć średnie dla czegoś, co użytkownik chce zobaczyć na ekranie, prawdopodobnie będziesz musiał obliczyć je w procedurze składowanej za ekranem.

  3. Jeśli to zrobisz, skonfiguruj replikowaną bazę danych i uzupełnij kostkę. Okresowo odświeżaj tę bazę danych, aby proces ETL mógł działać z wewnętrznie spójnego zestawu danych. Jeśli uruchamiasz z aktywnej bazy danych, ryzykujesz, że niektóre pozycje zostaną później wypełnione, które zależą od rekordów które zostały utworzone po uruchomieniu odpowiedniego procesu.

    możesz mieć sytuację, w której uruchamiasz obciążenie wymiaru, a następnie nowe dane są wprowadzane do systemu. Po uruchomieniu ładowania tabeli faktów zawiera ona teraz dane zależne od danych wymiarów, które nie zostały załadowane. Spowoduje to złamanie kostki i spowoduje niepowodzenie procesu ładowania. Batch odświeżanie replikowanej bazy danych w celu uruchomienia ETL lub Cube loads off złagodzi ten problem.

    jeśli nie masz możliwości replikowana baza danych możesz skonfigurować więcej zasad slack dla brakujących danych.

  4. Jeśli podstawowe dane produkcyjne mają istotne problemy z jakością danych, zostaną one odzwierciedlone w kostkach. GIGO.

 5
Author: ConcernedOfTunbridgeWells,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-06-22 11:56:48