Star-Schema Design [zamknięty]

Trwa debata w datawarehousing litteratura o Gdzie w datawarehouse-architecture należy zastosować projekt Star-Schema .

W skrócie Kimball opowiada się bardzo wysoko za używaniem tylko schematu Star w datawarehouse, podczas gdy Inmon najpierw chce zbudować Enterprise Datawarehouse używając znormalizowanego projektu 3NF {6]}, a później użyć schematu Star w datamarts.

DODATKOWO tutaj można również powiedzieć, że Snowflake schema design {[6] } jest innym podejściem.

Czwarty projekt może być podejściem Modelowanie skarbca danych .

Schematy gwiazdek są używane, aby umożliwić szybki dostęp do dużych ilości danych. Wysoka wydajność jest umożliwiona poprzez zmniejszenie liczby połączeń potrzebnych do satsyfikacji wszelkich zapytań, które mogą być wykonane w odniesieniu do obszaru tematycznego. Odbywa się to poprzez umożliwienie redundancji danych w tabelach wymiarów.

Należy pamiętać, że schemat gwiazdy jest wzorem dla górnej warstwy magazynu. Wszystkie modele obejmują również schematy inscenizacji na dole stosu magazynowego, a niektóre obejmują również uporczywy przekształcono scalony obszar postojowy, w którym wszystkie systemy źródłowe są scalane w schemat modelowany 3NF. Nad tym znajdują się różne obszary tematyczne.

Alternatywy dla schematów gwiazd na najwyższym poziomie obejmują odmianę, która jest schematem płatka śniegu. Nową metodą, która może również prowadzić pewne badania, jest modelowanie skarbca danych zaproponowane przez Dana Linstedta.

Rzecz o Schematy gwiazd jest to, że są one naturalnym modelem dla rodzajów rzeczy większość ludzi chce zrobić z hurtowni danych. Na przykład łatwo jest tworzyć raporty o różnych poziomach szczegółowości (na przykład miesiąc, dzień lub rok). Skuteczne jest również wstawianie typowych danych biznesowych do schematu Gwiazdy, co jest powszechną i ważną cechą hurtowni danych.

Z pewnością możesz użyć dowolnej bazy danych, ale jeśli dobrze nie znasz swojej domeny biznesowej, to jest prawdopodobne, że Twoje raporty nie będą działać tak sprawnie, jak to możliwe, jeśli użyłeś schematu Gwiazdy.

Schematy gwiazdek są naturalnym dopasowaniem do ostatniej warstwy hurtowni danych. Jak się tam dostać, to kolejne pytanie. Z tego co wiem, Są dwa duże obozy, Billa Inmona i Ralpha Kimballa. Może warto spojrzeć na teorie tych dwóch facetów, jeśli / kiedy zdecydujesz się iść z gwiazdą.

Również niektóre narzędzia do raportowania bardzo lubią konfigurację schematu Gwiazdy. Jeśli jesteś zablokowany w konkretnym narzędziu do raportowania, może to wpłynąć na to, jak wygląda Platforma raportowania w Twoim magazynie.

Schemat gwiazdy jest logicznym modelem danych dla relacyjnych baz danych, który pasuje do zwykłych potrzeb hurtowni danych; jeśli podano środowisko relacyjne, schemat gwiazdy lub płatka śniegu będzie dobrym wzorcem projektowym, przewodowym w wielu metodologiach projektowania DW.

Istnieją jednak inne niż relacyjne silniki baz danych, które mogą być używane do wydajnej hurtowni danych. Wielowymiarowe silniki pamięci masowej mogą być bardzo szybkie Dla zadań OLAP (np.); nie możemy zastosować schematu gwiazd projekt w tym przypadku. Inne przykłady wymagające specjalnych modeli logicznych to bazy danych XML lub bazy kolumnowe (np. eksperymentalny C-store)).

Można się bez tego obejść. Jednak, będzie utrudnić życie dla siebie -- Twoja organizacja będzie chciał używać standardowych narzędzi, które żyją na górze DWs, i te narzędzia będą oczekiwać schemat Gwiazdy -- wiele wysiłku będzie spędził montażu kołek kwadratowy W okrągłym otworze.

Wiele optymalizacji na poziomie bazy danych zakłada, że masz schemat Gwiazdy; poświęcisz dużo czasu na optymalizację i restrukturyzację, aby DB zrobił "właściwą rzecz" z Twoim niezbyt dobrym układem Gwiazdy.

Upewnij się, że plusy przeważają nad minusami..

(czy to brzmi jakbym już tam był?)

- D

Są trzy problemy, które musimy rozwiązać.

1) Jak uzyskać dane z operacyjnego systemu źródłowego bez wywierania na nie nadmiernej presji poprzez łączenie tabel wewnątrz i między nimi, czyszczenie danych podczas wyodrębniania, tworzenie pochodnych itp.

2) Jak połączyć dane z różnych źródeł-niektóre legacy, niektóre pliki oparte, z różnych działów w integralną, dokładne, skutecznie przechowywane całość, która modeluje biznes, a nie odzwierciedla struktury systemy źródłowe. Pamiętaj, że systemy zmieniają się / są wymieniane stosunkowo szybko, ale podstawowy model biznesu zmienia się powoli.

3) jak uporządkować dane tak, aby jak najszybciej i dokładnie spełniały określone wymagania analityczne i raportowe dla poszczególnych osób/działów w biznesie.

Rozwiązanie tych trzech bardzo różnych problemów wymaga różnych warstw architektonicznych, aby je rozwiązać

Warstwa Stagingowa Powielamy struktury źródła, ale tylko zmienione dane ze źródeł są ładowane każdej nocy. po pobraniu danych z warstwy przejściowej do następnej warstwy, dane są upuszczane. Zapytania są pojedynczymi zapytaniami tabel z prostym filtrem data_time. Bardzo mały wpływ na źródło.

Enterprise Layer Jest to zorientowana na biznes baza danych 3rd normal form. Dane są wyodrębniane (a następnie upuszczane) z warstwy przejściowej do warstwy korporacyjnej, gdzie są czyszczone, integrowane i znormalizowany.

Warstwa Prezentacji (Schemat Gwiazdy) Tutaj modelujemy wymiarowo, aby spełnić określone wymagania. Dane są celowo de-normalizowane, aby zmniejszyć liczbę połączeń. Hierarchie, które mogą zajmować kilka tabel w warstwie korporacyjnej, są zwijane w jedną tabelę wymiarów, a wiele tabel transakcyjnych może być scalonych w jedną tabelę faktów.

Zawsze masz do czynienia z tymi trzema problemami. Jeśli zdecydujesz się zrezygnować z warstwy enterprise, nadal musisz rozwiązać drugi problem, ale trzeba to zrobić w warstwie schematu gwiazdy, a moim zdaniem, to jest złe miejsce, aby to zrobić.