2017-01-17 2 views
0

Ich habe Daten im folgenden Format.DataWarehouse - Fact-Tabellen mit unterschiedlicher Granularität/Dimensionsmessungen

RoadAccidents (pk_accidentIdentifier) mit Beziehung 1..*-Vehicles(fk_accidentIdentifier, ordinalNumber)-> natürlichen PK (Verbindung) und Surrogat, die einfach eine rowID).

ordinalumber ist nur eine Nummer, um durch Fahrzeuge zu iterieren, die in einen Unfall verwickelt waren.

--Sample Row 
Accident001, 1, [list of attributes of a vehicle] -- 1st car involved in an inc 
Accident001, 2, [list of attributes of a vehicle] -- 2nd car involved in an inc 

Vehicles mit 1..* Beziehung mit Tisch Casualties, die in der gleichen Art und Weise verbunden ist, wie Fahrzeuge mit RoadAccidents Bedeutung sind:

Casualties (Compound PK: (fk_vehicleID, casualtyOrdinalNumber)

--Sample Row: 
Vehicle001, 1, [list of attributes of a casualty] -- 1st casualty involved in inc 
Vehicle001, 2, [list of attributes of a casualty] -- 2st casualty involved in inc 

So sieht die Beziehung wie folgt.

RoadAccidents 1..* Vehicles 1..* Casualties

Zusätzlich Tabelle RoadAccidents hat bereits Maßnahmen von numberOfVehiclesInvolved und numberOfCasualties aggregiert.

Es gibt 3 (möglicherweise mehr) hier für die fact tables

  1. Zwei auf RoadAccident -> Vehicles -> Casualties JOINS Ansätze -> löschen Spalten mit aggregierten Zahlen -> Extrakt Attribute jeweiligen Dimensionen. Lose aggregierte Daten -> haben keine sinnvolle Kennzahl -> erstellen Sie Kennzahlen in SQL Server-Datentools.

  2. Haben Sie 3 Fakten Tabellen. FactRoadAccident, FactVehiclesCollision, FactCasaultiesInvInCollision

Das Problem, das ich konfrontiert: Faktentabellen nicht direkt durch Fremdschlüssel verknüpft werden soll. Daher kann ich Dimensionen wie z.

DimRoadAccident *..1 DimRoadAccidentLocation 
DimRoadAccident` *..1 DimWeatherConditions 

Faktentabelle würde wie folgt aussehen:

FactAccident (fk_DimRoadAccidentPK, measure_numberOfVehicles, measure_numberOfCasualties).

Mit diesem Ansatz. Faktentabellen für Vehicles und Casualties wären nur ein Ersatz FK mit der ID eines Vehicle oder Casualty. Die einzigen Maßnahmen wären die Zeilenanzahl, dh die Nummer Vehicles oder die Nummer Casualties.

  1. halten nur 1 Faktentabelle

FactAccident (fk_DimRoadAccidentPK, measure_numberOfVehicles, measure_numberOfCasualties).

Lassen Sie die Dimensionen verknüpft werden DimRoadAccident 1..* DimVehicle 1..* DimCasualty und haben Hierarchien in Data Tools erstellt und möglicherweise einige neue semi-additive Kennzahlen für Dimensionen erstellen.

Welche Appraoch würden Sie vorschlagen?

+0

Es gibt eine sehr ähnliche Frage hier (möglicherweise sogar basierend auf dem gleichen Datensatz?), Meine Antwort darauf kann Ihnen helfen: http://stackoverflow.com/q/40774305/3964881. Wenn Sie immer noch stecken bleiben, werde ich versuchen, eine detailliertere Antwort zu schreiben, da Sie hier mehr Informationen gegeben haben als der andere. Überlegen Sie sich die geringste Granularität der Daten, bevor Sie entscheiden, was Ihre Fakt- oder Dimensionstabellen sind. Sobald Sie die geringste Granularität verstehen, werden die Fakten und Dimensionen deutlicher. –

+0

Danke deine Antwort Joe, es scheint in der Tat der gleiche Datensatz zu sein. Ich habe auf den Kern der Daten in meinem Kommentar in der Post darunter hingewiesen. –

Antwort

-1

Verwenden Sie eine Bridge-Tabelle. Bridge-Tabellen werden verwendet, wenn Sie eine Viele-zu-Viele-Beziehung haben. Sehen Sie hier http://www.kimballgroup.com/2012/02/design-tip-142-building-bridges/

+0

Bridge-Tabellen sind nicht unbedingt die Antwort darauf. Die Kimball Group nimmt Bridge-Tabellen an: "Wenn Ihr Design mit Bridge-Tabellen gespickt ist, um mehrwertige Dimensionsbeziehungen zu erfassen, müssen Sie wieder zum Zeichenbrett zurückkehren. Wahrscheinlich haben Sie ein Problem mit der Granularität der Faktentabelle. " (http://www.kimballgroup.com/2003/10/fistful-of-flauws/) –

+0

Dieser Artikel von ihnen diskutiert auch die Probleme mit und Alternativen zu Bridge-Tabellen: http://www.kimballgroup.com/2014/ 05/design-tip-166-potential-bridge-table-umwege/- ein wichtiger Punkt ist, dass es keine umfassende Lösung für den Umgang mit vielen-zu-vielen Situationen gibt. Aber sie sind in allen ihren Schriften sehr klar, dass Sie zuerst sicherstellen müssen, dass Sie das richtige Korn haben - so sollte das der erste Ort sein, um zu schauen, und Dinge wie Brückentische (die außerhalb des Standardmodells liegen) sollten nur verwendet werden, wenn absolut notwendig. –

+0

Wird das wirklich als Viele-zu-Viele Beziehung betrachtet? Diese sind meiner Meinung nach rein 1 .. * hinsichtlich der logischen Verbindung zwischen den Daten. Der einzige Unterschied besteht darin, dass die denormalisierte Tabelle (Rohdaten) auch bereits aggregierte Kennzahlen für Nein enthält. von Fahrzeugen und nein. von Opfern. –

Verwandte Themen