Dominujące topologie modelowania hurtowni danych (Star, Snowflake) są zaprojektowane z myślą o relacjach jeden do wielu. Czytelność, wydajność i struktura zapytań znacznie się pogarsza w obliczu relacji wiele do wielu w tych schematach modelowania.
Jakie są sposoby implementacji relacji wiele do wielu między wymiarami lub między tabelą faktów a wymiarem w hurtowni danych i jakie kompromisy wprowadzają w odniesieniu do niezbędnej szczegółowości i wydajności zapytań?
database-design
data-warehouse
Brian Ballsun-Stanton
źródło
źródło
Odpowiedzi:
Z mojego doświadczenia wynika, że rekurencyjna hierarchia jest najbardziej praktycznym sposobem rozwiązania tego problemu. Oferuje następujące zalety:
W przeciwieństwie do tego wymaga dodatkowej tabeli dla każdego poziomu złączeń „-to-many”. Jest to mocno zakodowane i trudne do utrzymania w stosunku do aktualizacji schematu.
Dzięki zastosowaniu filtrowanych indeksów duża tabela sprzężeń hierarchicznych może działać szybciej niż tabele dedykowane. Powodem jest to, że każde łączenie jest tylko „rodzicem-dzieckiem” w porównaniu do „łączenia tabeli z tabelą danych”. Ten ostatni ma więcej indeksów do przetwarzania i przechowywania.
Próbowałem rozwiązać ten problem od wielu lat. Ostatnio to wymyśliłem.
źródło
Niektóre scenariusze dla relacji M: M w modelu hurtowni danych
Większość serwerów OLAP i systemów ROLAP ma teraz sposób na radzenie sobie ze strukturami danych M: M, ale są pewne zastrzeżenia, na które należy zwrócić uwagę. Jeśli wdrożysz relacje M: M, musisz monitorować warstwę raportowania i narzędzia, które chcesz obsługiwać.
Scenariusz 1: Wymiar M: M na tabeli faktów
Przykładem może być wiele sterowników w polityce silnika. Jeśli dodasz lub usuniesz sterownik, transakcja dostosowania zasad może mieć związek z listą sterowników, która zmienia się wraz z dostosowaniem.
Opcja 1 - M: M tablica faktów kierowcy M Będzie to dość duża ilość danych, ponieważ zawiera sterowniki x wiersze transakcji dla danej zasady. SSAS może wykorzystywać tę strukturę danych bezpośrednio, ale wolniej jest wyszukiwać za pomocą narzędzia ROLAP.
Jeśli relacja M: M jest oparta na jednostkach specyficznych dla wiersza faktów (np. Kierowcy w samochodzie), może to być odpowiednie również dla narzędzia ROLAP, pod warunkiem, że Twoje narzędzie ROLAP obsługuje relacje M: M (np. Przy użyciu kontekstów w biznesie Obiekty).
Opcja 2 - Tabela wymiarów „kombinacji” manekina Jeśli mapujesz listę wspólnych kodów na tabelę faktów (tzn. Połączone jednostki nie są specyficzne dla wiersza faktów), możesz zastosować inne podejście, które zmniejszy ilość danych. Przykładem tego rodzaju scenariusza są kody ICD podczas wizyty szpitalnej. Każda wizyta w szpitalu będzie miała co najmniej jedną diagnozę ICD i / lub procedury. Kody ICD są globalne.
W takim przypadku możesz utworzyć osobną listę kombinacji kodów dla każdego przypadku. Utwórz tabelę wymiarów z jednym rzędem dla każdej odrębnej kombinacji i miej tabelę połączeń między kombinacjami a tabelami odniesienia dla samych kodów ICD.
Tabela faktów może mieć klucz wymiaru do wymiaru „kombinacji”, a wiersz wymiaru zawiera listę odniesień do rzeczywistych kodów ICD. Większość narzędzi ROLAP może wykorzystywać tę strukturę danych. Jeśli Twoje narzędzie będzie działać tylko z faktyczną relacją M: M, możesz utworzyć widok, który emuluje relację M: M między faktem a tabelą referencyjną kodowania. To byłoby preferowane podejście z SSAS.
Zalety opcji 1: - Odpowiednio zindeksowane zapytania oparte na wyborze wierszy tabeli faktów o określonej relacji w tabeli M: M mogą być dość wydajne.
Zalety opcji 2: - Przechowywanie danych jest bardziej kompaktowe
Scenariusz 2: Relacja M: M między wymiarami:
Trudniej jest wymyślić przypadek użycia, ale można ponownie wyobrazić sobie coś z opieki zdrowotnej dzięki kodom ICD. W systemie analizy kosztów wizyta w szpitalu może stać się wymiarem i będzie miała związek M: M między wizytą (lub epizodem konsultanta w mowie NHS) a kodowaniem.
W takim przypadku można skonfigurować relacje M: M i ewentualnie skodyfikować ich renderowanie przez człowieka w wymiarze podstawowym. Zależności można realizować za pomocą prostych tabel łączy M: M lub poprzez tabelę „kombinacji” mostków, jak poprzednio. Tę strukturę danych można poprawnie przeszukiwać za pomocą obiektów biznesowych lub narzędzi ROLAP lepszej jakości.
Z góry mojej głowy, nie widzę, że SSAS może to wykorzystać bez sprowadzenia relacji do tabeli faktów, więc musiałbyś przedstawić widok relacji M: M między kodowaniem a tabelą faktów wiersze, aby użyć SSAS z tymi danymi.
źródło
Chciałbym dokładnie wiedzieć, jaki rodzaj relacji wiele do wielu masz na myśli w swoim modelu, czy to w systemie transakcyjnym, czy w jakimkolwiek modelu danych, w którym obecnie się znajduje.
Zazwyczaj relacje wiele do wielu między wymiarami są faktami na temat wymiarów. Fakt, że klient zamawia w kilku oddziałach, które obsługują wielu klientów, lub coś w tym rodzaju. Każdy z nich jest faktem. Byłaby to data wejścia w życie lub coś w tym rodzaju, ale związek może być „pozbawiony faktów”. Sama relacja może mieć inne wymiary oprócz klienta i oddziału. Jest to więc typowy schemat gwiazdy z tabelą faktów (potencjalnie bez faktów) na środku. Sposób, w jaki ta gwiazda może odnosić się do innych gwiazd wymiarowych w magazynie, będzie oczywiście zależeć. Za każdym razem, gdy łączysz różne gwiazdy, robisz to na kluczach biznesowych i musisz upewnić się, że nie wykonujesz przypadkowych połączeń krzyżowych.
Zazwyczaj nie raportuje się o takich tabelach relacji wymiarów w takim samym stopniu, jak większe tabele faktów, a kiedy to robią, nie zawsze jest tak dużo danych, więc nie ma to wpływu na wydajność. W powyższym przypadku możesz spojrzeć na wykorzystanie klienta / oddziału w czasie, ale lepsze dane o rzeczywistych wielkościach zamówień byłyby dostępne w tabeli faktów zamówienia, która prawdopodobnie miałaby również wymiary dla klienta, oddziału itp. Nie są to większość osób rozważa wiele do wielu (chociaż można by rozważyć zamówienie w celu zdefiniowania relacji wiele do wielu od klienta do oddziału), więc są one bardziej typowe w środowiskach hurtowni danych. Robiłbyś agregacje liczbowe na modelach wiele do wielu, gdybyś zebrał informacje podsumowujące do tego poziomu relacji - tj. Klient, oddział, miesiąc,
źródło
Oto kilka istotnych artykułów od Kimball i innych, które mogą dotyczyć modelowania danej proponowanej relacji wiele do wielu. Zauważ, że relacja wiele do wielu jest pojęciem tylko w dziedzinie problemowej / modelu logicznym. W znormalizowanym modelu OLTP nadal byłby obsługiwany za pomocą tabeli łączy, która jest oczywiście od jednego do wielu pod każdym względem. W nienormalizowanym modelu hurtowni danych Kimball istnieje na to kilka sposobów, z których jeden zasadniczo traktuje tę tabelę łączy jako fakt w centrum gwiazdy. Innym jest tablica kolumn flag.
Ostatecznie wybór będzie zależeć od tego, co dokładnie modelujesz, jak się zmienia i jak chcesz to raportować. W tym przypadku modelowanie wymiarowe i hurtownia danych zasadniczo różnią się znacznie od znormalizowanego modelu. Znormalizowany model koncentruje się na logicznych i teoretycznych relacjach w danych, które hurtownie danych zawsze pilnują realistycznych przypadków użycia i denormalizują je, aby je wykonać.
Modelowanie alternatywnych hierarchii przy użyciu tabeli mostu:
http://www.kimballgroup.com/wp-content/uploads/2012/05/DT62Alternative.pdf
Trzy opcje relacji wiele do wielu (związane z liczbowymi przydziałami akcji - w komentarzach można znaleźć ciekawe komentarze tam iz powrotem)
http://www.pythian.com/news/364/implementing-many-to-many-relationships-in-data-warehousing/
Niestety wiele artykułów z Tygodnia informacyjnego / DBMS Kimball nie ma już dobrych linków ...
źródło
Jednym ze sposobów rozwiązania tego problemu jest posiadanie tabeli faktów składającej się tylko z 2 kolumn, a klucz obcy z 2 wymiarów ma relację wiele do wielu.
źródło