it-swarm.com.de

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

Die vorherrschenden Topologien der Data Warehouse-Modellierung (Star, Snowflake) wurden unter Berücksichtigung von Eins-zu-Viele-Beziehungen entwickelt. 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, eine Viele-zu-Viele-Beziehung zwischen Dimensionen oder zwischen der Faktentabelle und einer Dimension in einem Data Warehouse zu implementieren, und welche Kompromisse gehen sie hinsichtlich der erforderlichen Granularität und Abfrageleistung ein?

26

Nach meiner Erfahrung ist eine rekursive Hierarchie der praktischste Weg, 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 schwer gegen Schemaaktualisierungen zu pflegen.

Durch die Verwendung gefilterter Indizes kann eine große Tabelle hierarchischer Verknüpfungen eine höhere Geschwindigkeit als dedizierte Tabellen aufweisen. Der Grund dafür ist, dass jeder Join nur "Eltern-Kind" ist, verglichen mit "Join-Tabelle zu Datentabelle". Letzterer muss mehr Indizes verarbeiten und speichern.

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

17
IamIC

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

Die meisten OLAP Server und ROLAP-Systeme haben jetzt die Möglichkeit, mit M: M-Datenstrukturen umzugehen, aber es gibt einige Einschränkungen, die Sie beachten müssen. Wenn Sie M implementieren: M Beziehungen, die Sie benötigen, um Ihre Berichtsebene im Auge zu behalten und welche Tools Sie unterstützen möchten.

Szenario 1: M: M-Dimension in einer Faktentabelle

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

Option 1 - M: M-Treiber-Fakt-Brückentabelle Dies hat ein ziemlich großes Datenvolumen, da es 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. die Verwendung von Kontexten in Unternehmen) Objekte).

Option 2 - Dimensionstabelle für Dummy-Kombinationen Wenn Sie einer Faktentabelle eine Liste allgemeiner Codes zuordnen (dh die verknüpften Entitäten sind der Faktzeile nicht eigen), können Sie einen anderen Ansatz wählen Reduzieren Sie das Datenvolumen. Ein Beispiel für diese Art von Szenario sind ICD-Codes bei einem stationären Besuch. Bei jedem stationären Besuch sind eine oder mehrere ICD-Diagnosen und/oder -Verfahren aufgeführt. Die ICD-Codes sind global.

In diesem Fall können Sie eine eigene 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 tatsächliche 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 indiziert können Abfragen, die auf der Auswahl von Faktentabellenzeilen mit einer bestimmten Beziehung über die M: M-Tabelle basieren, einigermaßen effizient sein.

  • Etwas einfacheres konzeptionelles Modell

Vorteile von Option 2 : - Die Datenspeicherung ist kompakter

  • Sie können eine gerade 1: M-Beziehung emulieren, indem Sie die Kombinationen in einem für Menschen lesbaren Format als Code in der Dimension "Kombinationen" darstellen. Dies ist möglicherweise nützlicher bei dümmeren Berichterstellungstools, 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 außerhalb des Gesundheitswesens mit ICD-Codes vorstellen. Bei 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 eine für Menschen lesbare Darstellung in der Basisdimension codieren. Die Beziehungen können wie zuvor über gerade M: M-Verknüpfungstabellen oder über eine Überbrückungstabelle 'Kombinationen' hergestellt werden. Diese Datenstruktur kann über Business Objects oder ROLAP-Tools von besserer Qualität korrekt abgefragt werden.

Auf den ersten Blick kann ich nicht sehen, dass SSAS dies nutzen kann, ohne die Beziehung bis zur Faktentabelle zu führen. Sie müssten also eine Ansicht der M: M-Beziehung zwischen der Codierung und der Faktentabelle präsentieren Zeilen, um SSAS mit diesen Daten zu verwenden.

Ich würde gerne genau wissen, an welche Art von Viele-zu-Viele-Beziehung Sie in Ihrem Modell denken, entweder wie im Transaktionssystem oder in welchem ​​Datenmodell es sich derzeit befindet.

In der Regel sind viele-zu-viele-Beziehungen zwischen Dimensionen Fakten über Dimensionen. Die Tatsache, dass ein Kunde bei mehreren Niederlassungen bestellt, die viele Kunden bedienen, oder so ähnlich. Jedes davon ist eine Tatsache. Es hätte ein Datum des Inkrafttretens 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 handelt sich also um ein typisches Sternschema mit einer (möglicherweise faktenlosen) Faktentabelle in der Mitte. Wie sich dieser Stern auf andere dimensionale Sterne im Lager beziehen kann, hängt offensichtlich davon ab. 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 durchführen.

In der Regel werden solche Dimensionsbeziehungstabellen nicht im gleichen Maße wie größere Faktentabellen gemeldet, und wenn dies der Fall ist, sind nicht immer so viele Daten vorhanden, sodass die Leistung nicht beeinträchtigt wird. In dem oben genannten Fall könnten Sie sich die Auslastung der Kunden/Filialen im Laufe der Zeit ansehen, aber bessere Daten über die tatsächlichen Bestellmengen wären in Ihrer Bestellfaktentabelle verfügbar, die vermutlich auch Dimensionen für den Kunden, die Filiale usw. haben würde. Dies ist nicht was Die meisten Menschen würden viele-zu-viele in Betracht ziehen (obwohl eine Bestellung eine Viele-zu-viele-Beziehung vom Kunden zur Niederlassung definieren könnte), sind also in Data-Warehouse-Umgebungen typischer. Sie würden nur numerische Aggregate für viele-zu-viele-Modelle erstellen, wenn Sie zusammenfassende Informationen auf dieser Beziehungsebene zusammengefasst hätten - dh Kunde, Branche, Monat, Gesamtumsatz -, eine zusammenfassende Faktentabelle, die eher wie eine einzige Tatsache aussieht Dimensionsmodell jetzt, da es numerische Daten hat.

5
Cade Roux

Hier sind einige relevante Artikel von Kimball und andere, die möglicherweise für die Modellierung einer bestimmten vorgeschlagenen Viele-zu-Viele-Beziehung gelten. 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 behandelt, die natürlich jeweils eine bis viele ist. In einem nicht normalisierten Kimball-Data-Warehouse-Modell gibt es eine Reihe von Möglichkeiten Dazu behandelt eine diese Verknüpfungstabelle im Grunde genommen als die Tatsache in der Mitte eines Sterns. Eine andere ist ein Array von Flaggenspalten.

Letztendlich hängt die Wahl davon ab, was genau Sie modellieren, wie es sich ändert und wie Sie darüber berichten möchten. Hier weicht 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 Data Warehousing immer die realistischen Anwendungsfälle im Auge behält und denormalisiert, um diese auszuführen.

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 numerische Freigabezuweisungen - siehe die Kommentare für einige interessante Hin- und Herbewegungen)

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

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

5
Cade Roux

Eine Möglichkeit, dies zu beheben, besteht darin, dass eine Faktentabelle nur zwei Spalten mit Fremdschlüsseln aus den beiden Dimensionen enthält, die eine Beziehung von vielen zu vielen haben.

1
paranjai