Wie kann eine Viele-zu-Viele-Beziehung in einem Data Warehouse implementiert werden?

25

Die vorherrschenden Topologien der Data Warehouse-Modellierung (Star, Snowflake) sind auf Eins-zu-Viele-Beziehungen ausgelegt. Die Lesbarkeit, Leistung und Struktur von Abfragen verschlechtert sich erheblich, wenn in diesen Modellierungsschemata eine Viele-zu-Viele-Beziehung besteht.

Welche Möglichkeiten gibt es, um eine Viele-zu-Viele-Beziehung zwischen Dimensionen oder zwischen der Faktentabelle und einer Dimension in einem Data Warehouse zu implementieren, und welche Kompromisse bringen sie in Bezug auf die erforderliche Granularität und Abfrageleistung mit sich?

Brian Ballsun-Stanton
quelle
Sie müssen Ihre Frage klarer formulieren. Dies ist möglicherweise der Grund, warum seit dem 4. keine Antwort mehr eingegangen ist. Was Sie als Antwort auf meine Antwort angeben, stimmt nicht mit Ihrer ursprünglichen Frage überein.
IamIC
@ IanC bearbeitet. Ist es besser?
Brian Ballsun-Stanton
Perfekt :)
IamIC

Antworten:

17

Nach meiner Erfahrung ist eine rekursive Hierarchie der praktischste Weg, um dies anzugehen. Es bietet folgende Vorteile:

  1. Unbegrenzte Tiefe.
  2. Kompaktheit.
  3. Flexibilität.
  4. Geschwindigkeit.

Im Gegensatz dazu wird für jede Ebene von "-to-many" -Verbindungen eine zusätzliche Tabelle benötigt. Dies ist hartcodiert und für Schemaaktualisierungen schwierig zu pflegen.

Durch die Verwendung von gefilterten Indizes kann eine große Tabelle mit hierarchischen Verknüpfungen schneller ausgeführt werden als dedizierte Tabellen. Der Grund dafür ist, dass jeder Join nur "Eltern-Kind" ist, verglichen mit "Tabelle mit Datentabelle verbinden". Letzteres hat mehr Indizes zu verarbeiten und zu speichern.

Ich habe jahrelang versucht, dieses Problem zu lösen. Vor kurzem habe ich mir das ausgedacht.

IamIC
quelle
1
Sie fragten: "Wie lassen sich diese vielen-zu-vielen-Modelle modellieren und was bedeutet dies für die Leistung und die Granularität?" Ich antwortete beim Modellieren. Keine Notwendigkeit, abzustimmen.
IamIC
4
Sie müssen mehr Daten zu dem bereitstellen, was Sie benötigen. Ich habe das genaue Problem, das Sie in einer rekursiven Hierarchie angegeben haben, überwunden. Aber ohne etwas über Ihre Daten und deren Zusammenhänge zu wissen, ist es sehr schwierig zu antworten.
IamIC
2
Ja, sie modellieren dies nicht von Haus aus. Was wäre falsch daran, eine weitere Tabelle und einen Join hinzuzufügen, um das viele-zu-viele zu erreichen? In einem RDBMS haben Sie, unabhängig davon, wie Sie Ihre Tabellen strukturieren, zwei Joins für ein Viel-zu-Viel-Verhältnis. Es gibt keine Abkürzung. Die einzig mögliche Ausnahme sind Arrays in PostgreSQL oder Caché / M.
IamIC
1
(Eine rekursive Hierarchie ist eigentlich eine gute Idee.) Eine Möglichkeit, das Problem zu lösen, bestand darin, die Liste der möglichen Viele-zu-Viele-Beziehungen innerhalb einer Dimension vorab zu berechnen, diese auf eine normale Dimensionstabelle zu verweisen und dann die Faktentabelle damit zu verknüpfen Maßtabelle zusammengefasst. Ihre Antwort auf "rekursive Hierarchie" ist eine weitere nützliche Entwurfsantwort. Ich frage mich, ob die Auswirkungen dieser verschiedenen Hacks auf die Leistung untersucht wurden.
Brian Ballsun-Stanton
3
@Brian vergiss nicht die Stimmen für nützliche Antworten. Es hilft, Gemeinschaft zu schaffen. Um Ihre Frage zu beantworten, habe ich keine Untersuchungen zu diesen Hacks durchgeführt, außer "Was ist schneller: ein rekursiver CTE oder ein manueller Baumaufbau?". Deine vorher angegebene Lösung macht Sinn. Ich würde es mit einer indizierten Ansicht kombinieren, die natürlich sicherstellt, dass Sie immer die richtige vorab ausgefüllte Beziehungszuordnung haben.
IamIC
6

Einige Szenarien für M: M-Beziehungen in einem Data Warehouse-Modell

Die meisten OLAP-Server und ROLAP-Systeme können jetzt mit M: M-Datenstrukturen umgehen, es gibt jedoch einige Einschränkungen, die Sie beachten müssen. Wenn Sie M: M-Beziehungen implementieren, müssen Sie Ihre Berichtsebene und die zu unterstützenden Tools im Auge behalten.

Szenario 1: M: M-Dimension auf eine Faktentabelle

Ein Beispiel hierfür könnten mehrere Fahrer in einer Motorrichtlinie sein. Wenn Sie einen Treiber hinzufügen oder entfernen, hat die Transaktion zur Richtlinienanpassung möglicherweise eine Beziehung zu einer Liste von Treibern, die sich mit der Anpassung ändert.

Option 1 - M: M-Treiber-Fakt-Brückentabelle Diese Tabelle enthält eine ziemlich große Datenmenge, da sie Treiber x Transaktionszeilen für eine bestimmte Richtlinie enthält. SSAS kann diese Datenstruktur direkt verwenden, die Abfrage über ein ROLAP-Tool ist jedoch langsamer.

Wenn Ihre M: M-Beziehung auf Entitäten basiert, die für die Faktenzeile spezifisch sind (z. B. Fahrer in einem Auto), ist dies möglicherweise auch für ein ROLAP-Tool geeignet, sofern Ihr ROLAP-Tool M: M-Beziehungen unterstützt (z. B. Kontexte in Unternehmen verwenden) Objekte).

Option 2 - Dummy-Dimensionstabelle "Kombinationen" Wenn Sie einer Faktentabelle eine Liste gängiger Codes zuordnen (dh die verknüpften Entitäten sind für die Faktzeile nicht spezifisch), können Sie einen anderen Ansatz wählen, mit dem das Datenvolumen reduziert wird. Ein Beispiel für ein solches Szenario sind ICD-Codes bei einem stationären Besuch. Bei jedem stationären Besuch werden eine oder mehrere ICD-Diagnosen und / oder -Verfahren aufgeführt. Die ICD-Codes sind global.

In diesem Fall können Sie eine eindeutige Liste der Codekombinationen für jeden Fall erstellen. Erstellen Sie eine Dimensionstabelle mit einer Zeile für jede einzelne Kombination und erstellen Sie eine Verknüpfungstabelle zwischen den Kombinationen und den Referenztabellen für die ICD-Codes.

Die Faktentabelle kann einen Dimensionsschlüssel für die Dimension "Kombinationen" enthalten, und die Dimensionszeile enthält eine Liste mit Verweisen auf die tatsächlichen ICD-Codes. Die meisten ROLAP-Tools können diese Datenstruktur verwenden. Wenn Ihr Tool nur mit einer tatsächlichen M: M-Beziehung funktioniert, können Sie eine Ansicht erstellen, die die M: M-Beziehung zwischen dem Fakt und der Codierungsreferenztabelle emuliert. Dies wäre der bevorzugte Ansatz bei SSAS.

Vorteile von Option 1: - Entsprechend indizierte Abfragen, die auf der Auswahl von Faktentabellenzeilen mit einer bestimmten Beziehung durch die M: M-Tabelle basieren, können einigermaßen effizient sein.

  • Etwas einfacheres konzeptionelles Modell

Vorteile von Option 2: - Die Datenspeicherung ist kompakter

  • Sie können eine direkte 1: M-Beziehung emulieren, indem Sie die Kombinationen in einem für den Menschen lesbaren Format als Code in der Dimension "Kombinationen" darstellen. Dies ist möglicherweise für weniger benutzerfreundliche Berichterstellungstools hilfreich, die keine Unterstützung für M: M-Beziehungen bieten.

Szenario 2: M: M-Beziehung zwischen Dimensionen:

Es ist schwieriger, sich einen Anwendungsfall vorzustellen, aber man könnte sich wieder etwas aus dem Gesundheitswesen mit ICD-Codes vorstellen. In einem Kostenanalysesystem kann der stationäre Besuch zu einer Dimension werden und M: M-Beziehungen zwischen dem Besuch (oder der Berater-Episode in NHS-Sprache) und den Codierungen aufweisen.

In diesem Fall können Sie die M: M-Beziehungen einrichten und möglicherweise ein für den Menschen lesbares Rendering auf der Basisdimension festlegen. Die Beziehungen können wie zuvor über gerade M: M-Verknüpfungstabellen oder über eine Überbrückungskombinationstabelle hergestellt werden. Diese Datenstruktur kann über Business Objects oder ROLAP-Tools mit höherer Qualität korrekt abgefragt werden.

Ich kann mir nicht vorstellen, dass SSAS dies verbrauchen kann, ohne die Beziehung bis zur Faktentabelle zu übernehmen. Sie müssten also eine Ansicht der M: M-Beziehung zwischen der Codierung und der Faktentabelle anzeigen Zeilen, um SSAS mit diesen Daten zu verwenden.

Betroffen vonTunbridgeWells
quelle
5

Ich möchte genau wissen, welche Art von Viele-zu-Viele-Beziehung Sie in Ihrem Modell haben, entweder wie im Transaktionssystem oder in welchem ​​Datenmodell es sich gerade befindet.

In der Regel sind viele-zu-viele-Beziehungen zwischen Dimensionen Tatsachen über Dimensionen. Die Tatsache, dass ein Kunde von mehreren Niederlassungen aus bestellt, die viele Kunden bedienen, oder so etwas. Jedes davon ist eine Tatsache. Es hätte ein effektives Datum oder so etwas, aber die Beziehung könnte "faktenlos" sein. Die Beziehung selbst kann neben dem Kunden und der Niederlassung auch andere Dimensionen haben. Es ist also ein typisches Sternschema mit einer (möglicherweise faktenlosen) Faktentabelle in der Mitte. Wie sich dieser Stern auf andere dimensionale Sterne im Lager beziehen kann, wird offensichtlich davon abhängen. Jedes Mal, wenn Sie verschiedene Sterne kombinieren, tun Sie dies auf den Geschäftsschlüsseln und müssen sicherstellen, dass Sie keine versehentlichen Cross-Joins ausführen.

In der Regel werden solche Dimensionsbeziehungstabellen nicht in demselben Maße wie größere Faktentabellen gemeldet, und wenn dies der Fall ist, sind es nicht immer so viele Daten, sodass die Leistung nicht beeinträchtigt wird. In dem obigen Fall können Sie die Auslastung von Kunden / Filialen über einen längeren Zeitraum hinweg untersuchen. In Ihrer Bestellfaktentabelle sind jedoch bessere Daten zu den tatsächlichen Bestellmengen verfügbar, die vermutlich auch Abmessungen für Kunden, Filialen usw. haben Die meisten Leute würden viele-zu-viele-Beziehungen in Betracht ziehen (obwohl eine Bestellung als eine Viele-zu-viele-Beziehung von Kunde zu Zweigstelle angesehen werden kann). Sie würden nur numerische Aggregate für viele-zu-viele-Modelle erstellen, wenn Sie zusammenfassende Informationen auf diese Beziehungsebene aufgerollt hätten - dh Kunde, Zweigstelle, Monat,

Cade Roux
quelle
Gute Antwort. Es gibt zwei Fälle, die ich hier untersuche. Ein N: M zwischen Fakt und Dimension und ein 1: N: M zwischen Fakt, Dimension und Dimension.
Brian Ballsun-Stanton
3
@Brian Ballsun-Stanton Wenn Sie N: M zwischen Fakt und Dimension sagen, meinen Sie, dass eine gegebene Tatsache mehrere unterschiedliche und unterschiedliche Kardinalitäts-Geschwisterdimensionen hat, die alle zutreffen, wie Markierungen auf Fragen? So ist eine Frage (Tatsache) mit SQL-Server, Data-Warehouse und eine andere mit Data-Warehouse, SQL-Server, Business-Intelligence gekennzeichnet. Ich würde das immer noch in einen separaten Stern für den Tag-Zuweisungs-Fakt ziehen (der eine etwas andere Maserung als der Fragetatsache hat). Es wird großartige Indizierungsmöglichkeiten geben, und Sie können die Dimensionsänderung offensichtlicher erfassen.
Cade Roux
@Brian Ballsun-Stanton Was 1: N: M betrifft, ist das eine Schneeflocke, und ich neige dazu, das zu vermeiden. Wenn Sie andere Sterne (oder Brücken) für Beziehungen zwischen Dimensionen definieren möchten, ist dies in Ordnung. Denken Sie daran, dass ein Dimensions-Data-Warehouse nicht normalisiert ist und vor allem ein praktisches Konstrukt ist, das bestimmte Arten von Vorgängen unterstützt, nicht die reale Entitätsbeziehung darstellt oder Redundanz beseitigt.
Cade Roux
1
@Brian Ballsun-Stanton Schauen Sie sich das Kimball-Forum an und was er Brücken und Ausleger nennt, in seinen Toolkit-Büchern: forum.kimballgroup.com/…
Cade Roux
@Cade Kannst du eine Antwort geben, die diese beschreibt? :)
Brian Ballsun-Stanton
5

Hier sind einige relevante Artikel von Kimball und andere, die für die Modellierung einer bestimmten vorgeschlagenen Viele-zu-Viele-Beziehung gelten können. Beachten Sie, dass eine Viele-zu-Viele-Beziehung nur ein Konzept in der Problemdomäne / im logischen Modell ist. In einem normalisierten OLTP-Modell würde es immer noch mit einer Verknüpfungstabelle gehandhabt, die natürlich in jeder Hinsicht eins zu viele ist. In einem nicht normalisierten Kimball-Data-Warehouse-Modell gibt es eine Reihe von Möglichkeiten, um dies zu tun, von denen eine im Grunde genommen diese Verknüpfungstabelle als die Tatsache in der Mitte eines Sterns behandelt. Ein anderes ist ein Array von Flag-Spalten.

Letztendlich hängt die Wahl davon ab, was genau Sie modellieren, wie es sich ändert und wie Sie darüber berichten möchten. Hier weichen die dimensionale Modellierung und das Data Warehousing im Allgemeinen stark vom normalisierten Modell ab. Das normalisierte Modell konzentriert sich auf die logischen und theoretischen Beziehungen in den Daten, wobei das Data Warehousing stets die realistischen Anwendungsfälle im Auge behält und diese denormalisiert, um deren Leistung zu erzielen.

Modellierung alternativer Hierarchien mithilfe einer Brückentabelle:

http://www.kimballgroup.com/wp-content/uploads/2012/05/DT62Alternative.pdf

Drei Optionen für eine Beziehung von vielen zu vielen (gebunden an die numerische Zuteilung von Anteilen - in den Kommentaren finden Sie einige interessante Hin- und Her-Optionen)

http://www.pythian.com/news/364/implementing-many-to-many-relationships-in-data-warehousing/

Leider haben viele Artikel der Kimball Information Week / DBMS keine guten Links mehr ...

Cade Roux
quelle
Die Verknüpfung zum Artikel "Alternative Hierarchie" ist unterbrochen. Vielleicht beziehen Sie sich darauf: kimballgroup.com/html/designtipsPDF/DesignTips2004/…
Endy Tjahjono
Vielen Dank für den Link zu vielen Artikeln . Habe mein 'Aha!' Moment davon.
Endy Tjahjono
Der zweite Link ist tot. Hier ist ein neuerer Link zum selben Artikel. Es ist jedoch etwas verstümmelt und hat irgendwann alle Grafiken verloren. blog.pythian.com/…
posfan12
1

Eine Möglichkeit, dies zu beheben, besteht darin, eine Faktentabelle mit nur 2 Spalten mit Fremdschlüsseln aus den 2 Dimensionen zu haben, die eine Beziehung von vielen zu vielen haben.

paranjai
quelle
1
Wie wird das Problem gelöst?
Brian Ballsun-Stanton