Jakie są sposoby wdrożenia relacji wiele do wielu w hurtowni danych?

25

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ń?

Brian Ballsun-Stanton
źródło
Musisz podać swoje pytanie jaśniej. Być może dlatego nikt nie odpowiedział na to pytanie od czwartego. To, co podałeś w odpowiedzi na moją odpowiedź, nie jest tym samym, co twoje pierwotne pytanie.
IamIC
@IanC Edytowane. Czy lepiej?
Brian Ballsun-Stanton
idealne :)
IamIC

Odpowiedzi:

17

Z mojego doświadczenia wynika, że ​​rekurencyjna hierarchia jest najbardziej praktycznym sposobem rozwiązania tego problemu. Oferuje następujące zalety:

  1. Nieograniczona głębokość.
  2. Ścisłość.
  3. Elastyczność.
  4. Prędkość.

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.

IamIC
źródło
1
Zapytałeś „Jakie są sposoby modelowania tych wielu do wielu i jakie są ich konsekwencje dla wydajności i szczegółowości?”. Odpowiedziałem na temat modelowania. Nie ma potrzeby głosowania w dół.
IamIC
4
Musisz podać więcej danych o tym, czego potrzebujesz. Pokonałem dokładny problem, który zgłosiłeś za pomocą hierarchii rekurencyjnej. Ale bez wiedzy na temat twoich danych i ich połączeń bardzo trudno jest odpowiedzieć.
IamIC
2
Tak, nie modelują tego natywnie. Co byłoby złego w dodawaniu jeszcze jednego stołu i łączenia, osiągając w ten sposób liczbę do wielu? W RDBMS, bez względu na to, jak ustrukturyzujesz swoje tabele, będziesz mieć 2 złączenia dla wielu do wielu. Nie ma skrótu. Jedynym możliwym wyjątkiem są tablice w PostgreSQL lub Caché / M.
IamIC
1
(Właściwie to hierarchia rekurencyjna.) Jednym ze sposobów rozwiązania tego problemu było wstępne obliczenie listy możliwych relacji wiele do wielu w wymiarze, odniesienie tego do normalnej tabeli wymiarów, a następnie połączenie tabeli faktów z tym skrócona tabela wymiarów. Twoja odpowiedź na „hierarchię rekurencyjną” jest kolejną przydatną odpowiedzią projektową. Zastanawiam się, czy były jakieś badania dotyczące wpływu różnych hacków na wydajność?
Brian Ballsun-Stanton
3
@Brian nie zapomnij głosów na użyteczne odpowiedzi. Pomaga tworzyć społeczność. Aby odpowiedzieć na twoje pytanie, nie spotkałem się z żadnymi badaniami dotyczącymi tych hacków, z wyjątkiem „co jest szybsze: rekurencyjna CTE lub ręczna kompilacja drzewa?”. Wcześniej podane rozwiązanie ma sens. Chciałbym połączyć to z widokiem indeksowanym, co oczywiście zapewnia, że ​​zawsze masz poprawną, wstępnie wypełnioną mapę relacji.
IamIC
6

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.

  • Nieco prostszy model koncepcyjny

Zalety opcji 2: - Przechowywanie danych jest bardziej kompaktowe

  • Można emulować prosty związek 1: M, prezentując kombinacje w formacie czytelnym dla człowieka jako kod w wymiarze „kombinacji”. Może to być bardziej przydatne w przypadku głupszych narzędzi do raportowania, które nie obsługują relacji M: M.

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.

ConcernedOfTunbridgeWells
źródło
5

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,

Cade Roux
źródło
Dobra odpowiedź. Badam tutaj dwa przypadki. N: M między faktem a wymiarem oraz 1: N: M między faktem, wymiarem i wymiarem.
Brian Ballsun-Stanton
3
@Brian Ballsun-Stanton Kiedy mówisz N: M między faktem a wymiarem, masz na myśli, że dany fakt ma kilka nierozróżnialnych i różnorodnych wymiarów rodzeństwa liczności, które wszystkie mają zastosowanie, jak tagi na pytaniach? Tak więc jedno pytanie (fakt) jest oznaczone jako sql-server, data-warehouse, a drugie jest oznaczone tagiem data-Warehouse, sql-server, business-intelligence. Nadal przyciągałbym to do osobnej gwiazdy dla faktu przypisania znaczników (który ma trochę inne ziarno niż fakt pytania). Będzie miał świetne możliwości indeksowania i będziesz w stanie uchwycić zmianę wymiarów w bardziej oczywisty sposób.
Cade Roux,
@Brian Ballsun-Stanton Jeśli chodzi o 1: N: M, to chyba płatek śniegu i staram się tego unikać. Jeśli chcesz zdefiniować inne gwiazdy (lub mosty) dla relacji między wymiarami, to dobrze. Pamiętaj, że hurtownia danych wymiarowych nie jest znormalizowana, a przede wszystkim jest praktyczną konstrukcją przeznaczoną do obsługi określonych rodzajów operacji, a nie do konkretnej reprezentacji relacji między podmiotami w świecie rzeczywistym lub eliminacji nadmiarowości.
Cade Roux,
1
@Brian Ballsun-Stanton Spójrz na Forum Kimball i to, co nazywa mostami i wysięgnikami, w swoich książkach z narzędziami: forum.kimballgroup.com/...
Cade Roux
@Cade Czy możesz udzielić odpowiedzi opisującej je? :)
Brian Ballsun-Stanton 15.01.11
5

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 ...

Cade Roux
źródło
Link do artykułu o „alternatywnej hierarchii” jest zepsuty. Może odnosisz się
Endy
Dzięki za link do wielu artykułów . Mam moją „Aha!” chwila od tego.
Endy Tjahjono
Drugi link jest martwy. Oto nowszy link do tego samego artykułu. Jest jednak nieco zniekształcony i w pewnym momencie utracił całą grafikę. blog.pythian.com/…
posfan12
1

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.

Paranjai
źródło
1
Jak to rozwiązuje sprawy?
Brian Ballsun-Stanton