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

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?

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.

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.

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,

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

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.