Planen des Data Marts für BI-Planungslösungen und -Szenarien

Artikel
03/04/2017

Gilt für: SharePoint Server 2010 Enterprise

Letztes Änderungsdatum des Themas: 2016-11-30

Inhalt dieses Artikels

Schema und Layout
Modelle für Lösung
Erstellen von Dimensionstabellen
Erstellen von Hierarchietabellen
Erstellen von Faktentabellen

Schema und Layout

Der Data Mart wird mithilfe einer relationalen SQL Server 2008 R2-Datenbank erstellt, die als zentraler Aufzeichnungsort für Information Worker dient, wobei sämtliche Daten streng kontrolliert in den Data Mart gelangen. Der Data Mart wird vom Server mit SQL Server Analysis Services (SSAS) als zentrale Datenquelle für alle Cubes, Dimensionen und Hierarchien genutzt. Drei Tabellentypen werden benötigt, um das SSAS-Datenmodell zu unterstützen und die Dimensions-, Hierarchie- und Faktenebene einzubeziehen.

Hinweis

Ein Cube kann mit mehreren Faktentabellen arbeiten. Dies kann durch eine Partitionierung anhand der Measuregruppe und auch durch Verwenden mehrerer Measuregruppen innerhalb des Cubes erreicht werden.

Wir erstellen die folgenden Modelle zur Unterstützung der für den Planungsprozess benötigten Datenmodelle. Diese Modelle bestimmen die Anzahl der Tabellen in unserem Data Mart.

Modelle für Lösung

Prognose: Dieses Modell dient hauptsächlich zum Erfassen von Dateneingaben für Prognosen des Umsatzerlöses und der Betriebsausgaben für künftige Zeiträume.
Konto: Die Kontodimension enthält das Diagramm der Konten, in dem Umsatzerlös- und Ausgabenelemente für Prognosen angezeigt werden.
Szenario: Die Szenariodimension unterteilt die Daten in die Typen "Tatsächlich" und "Prognose".
Zeit: Die Zeitdimension legt die Geschäftszeiträume für die Prognose fest.
Region: Die Regionsdimension dient zum Steuern des Dateneingabeprozesses jedes Information Workers. Die einzelnen Information Worker in den jeweiligen Regionen geben Daten in der lokalen Währung ein.
Produkt: Die Produktdimension dient zum Abbilden der vollständigen Liste aktiver und verfügbarer Produkte. Die Umsatzerlösprognose erfolgt nach Produkt.
Personalbudget: Mit diesem Modell können Fachvorgesetzte die für das Geschäftsjahr erwartete Mitarbeiteranzahl budgetieren. Information Worker interagieren mit diesem Modell, indem für jeden Mitarbeiter die erwarteten Arbeitsstunden und die Entgeltgruppe eingegeben werden. Eine Was-wäre-wenn-Analyse wird ausgeführt, um zu bestimmen, welcher Betrag an Löhnen und Gehältern basierend auf Änderungen an den Annahmen budgetiert werden muss.
Metrik: Diese Dimension dient zum Speichern von Werten wie "Geleistete Stunden", "Entgeltgruppe", "Gesamtvergütung" usw.
Region: Der Standort, dem die Ressource zugeordnet wird.
Zeit: Budget für die Mitarbeiteranzahl auf Jahresebene.
Mitarbeiter: Eine Liste aktueller Ressourcen und mit Platzhaltern für neu einzustellende Ressourcen.
Lohnsätze: Dieses Modell dient zum Festlegen der Basislohnsätze für das Jahr. Die Lohnsatzdaten werden in das Personalbudgetmodell als grundlegende Daten für die Verwendung in Berechnungen eingegeben.
Zeit: Lohnsätze werden auf Jahresebene eingegeben.
Entgeltgruppe: Eine Liste mit Entgeltgruppen zum Bestimmen der Basisvergütung.
Wechselkurse: Das Wechselkursmodell dient zum Bestimmen der monatlich festgelegten zu verwendenden Währungsumrechnungskurse, wenn Daten aus dem Prognosemodell im Finanzkonsolidierungsmodell umgerechnet werden. Da Daten in jeder Region in der lokalen Währung eingegeben werden, wird die Wechselkurstabelle für Währungsumrechnungsregeln und Datenflusspakete genutzt.
Zeit: Wechselkurse werden monatlich eingegeben.
Quellwährung: Die Quellwährung einer Umrechnung.
Zielwährung: Die Zielwährung einer Umrechnung.
Finanzkonsolidierung: Das Finanzkonsolidierungsmodell dient zum Erstellen von Finanzberichten in einer Währung für alle Regionen.
Konto: Konsolidiertes Kontendiagramm.
Szenario: Enthält Tatsächlich und Prognose.
Zeit: Die kleinste Einheit ist "Monate".
Region: Alle Regionen mit Gewinn- und Verlustrechnung.
Währungstyp: Daten können entweder in der Berichtswährung (EUR) oder lokalen Währung angezeigt werden, die anhand der aktuell ausgewählten Region bestimmt wird.

Nachdem wir uns mit den benötigten Modellen beschäftigt haben, können wir den Datenspeicher einrichten, der fünf Faktentabellen und die dazugehörigen Dimensions- und Hierarchietabellen enthalten wird. Diese Tabellen werden in einem Sternschema angeordnet, wobei sich die Faktentabellen im Zentrum befinden und die Dimensions- und Hierarchietabellen die äußeren Punkte des Sternschemas bilden. Durch Festlegen von Beziehungen zwischen den Faktentabellen, Dimensionen und Hierarchien im Datenspeicher mithilfe von Fremdschlüsseln können wir in SSAS rasch die Datenquellenansicht erstellen, wenn das Anlegen der Cubes und Dimensionen erforderlich wird.

Erstellen von Dimensionstabellen

Dimensionen sind die Bausteine einer mehrdimensionalen Datenbank. Durch Gruppieren einer Menge von Dimensionen entsteht die allgemeine Basis für einen Cube. In Dimensionstabellen werden Daten eines bestimmten Typs zusammen gespeichert. Wenn Sie beispielsweise über eine Dimensionstabelle zum gemeinsamen Speichern aller Kunden verfügen, stellt jede Zeile der Tabelle ein eindeutiges Kundenelement der Dimension dar. In Dimensionstabellen können mithilfe von Tabellenspalten beliebige zusammengehörige Eigenschaften gemeinsam gespeichert werden. Die Dimension "Konto" kann z. B. die Spalte "Kontotyp" enthalten, in der der Kontentyp des Dimensionselements gespeichert wird.

Element-ID	Elementbeschriftung	Elementname	Sortierreihenfolge	Kontentyp	Ausgabentyp
1	3100	Umsatzerlös	100	Einkünfte	-
2	3200	Weitere Betriebserträge	200	Einkünfte	-
3	8100	Zinserträge	300	Einkünfte	-

Element-ID	Elementbeschriftung	Elementname	Sortierreihenfolge	Eingabewährung	Zielwährung
1	Fra	Frankfurt am Main	100	EUR	EUR
2	Mad	Madrid	200	EUR	EUR
3	Par	Paris	300	EUR	EUR

Empfehlung

Es wird empfohlen, für eine Dimensionstabelle die folgenden Felder zu erstellen:

ID: Es wird empfohlen, für Dimensionsschlüssel zur Optimierung der Leistung einen ganzzahligen Typ (TinyInt, SmallInt, Int, BigInt) und keinen der anderen Typen zu wählen. Im Abschnitt zur Leistung finden Sie weitere Informationen. Wählen Sie außerdem basierend auf der Größenbestimmung der Dimension den am besten geeigneten Datentyp.

Beschriftung: Wählen Sie für die Beschriftung bzw. Namensanzeige eines Dimensionselements einen eindeutigen Code. Bei Beibehaltung der Eindeutigkeit können Sie cubebasierte Regeln mithilfe von MdxScript für Beschriftungen erstellen, die vom Benutzer lesbar sind, im Gegensatz zur Elementangabe mithilfe der Schlüsselwertnotation wie z. B. "&[Schlüssel]".

Name: Endbenutzer möchten fast immer lieber die Elemente einer Dimension mit einem benutzerfreundlichen Namen anstatt mit dem Beschriftungscode bezeichnet sehen. In unserer Lösung gibt es beispielsweise Kontocodes in Beschriftungen, die beim Erstellen von Berechnungsregeln, aber nicht bei Anzeige in einer PivotTable einen Sinn ergeben. Durch Erstellen dieser Eigenschaft wird sichergestellt, dass Anzeigenamen ohne Auswirkungen auf zugrunde liegende Logik von Regeldefinitionen problemlos geändert werden können.

Reihenfolge: Es empfiehlt sich, über eine Sortierspalte zu verfügen, mit deren Hilfe die Dimension die Reihenfolge ihrer Elemente bestimmen kann.

Dimensionstabellen für Planungsszenarien haben meist nicht mehr als 200.000 Elemente. Wenn Sie mit sehr groß gewordenen Dimensionen arbeiten, wird das Verkleinern der Dimension empfohlen. Verkleinerten Dimensionselementen zugeordnete Daten können zusammengeführt und in andere Dimensionselemente eingegeben werden. Je kleiner die Dimensionen, desto besser die Leistung der Planungscubes.

Hinweis

Dimensionsspalten und Elementeigenschaften stehen in engem Zusammenhang.

Erstellen von Hierarchietabellen

Hierarchietabellen werden benötigt, wenn die Hierarchie der über- und untergeordneten Elemente in SSAS verwendet wird. In dieser Hierarchie müssen die drei Spalten Schlüssel (die ein Element der Hierarchiedimension darstellt), übergeordneter Schlüssel (ein weiteres Element in derselben Dimension) und Sortieren für die Anordnung der Elemente auf einer Ebene der Hierarchie vorhanden sein. Die meisten Hierarchien über- und untergeordneter Elemente werden von diesen drei Spalten unterstützt, es sei denn, eine benutzerdefinierte Elementaggregation ist erforderlich. Für ein Diagramm mit Konten muss beispielsweise eine benutzerdefinierte Aggregation definiert werden. Kontoaggregationen werden anhand des Kontotyps des jeweiligen Kontoelements und des entsprechenden übergeordneten Kontoelements bestimmt. Zur Unterstützung von Hierarchien mit erforderlicher benutzerdefinierter Aggregation muss eine vierte Spalte angelegt werden. Diese Spalte vom Typ Unärer Operator enthält die Werte +, - und ~, wobei + die Aggregation mit dem übergeordneten Element, - die Subtraktion vom übergeordneten Element und ~ für die Ignorierung der Aggregation mit dem übergeordneten Element steht.

ID	Übergeordnete ID	Sortierreihenfolge	Unärer Operator	Beschriftung	Name
1	102	100	+	3100	Umsatzerlös
2	102	200	+	3200	Weitere Betriebserträge
3	103	300	+	8100	Zinserträge
4	103	400	+	9100	Gewinn aus Verkauf von Anlagewerten

ID	Übergeordnete ID	Sortierreihenfolge	Beschriftung	Name
1	4	500	Fra	Frankfurt am Main
2	4	700	Mad	Madrid
3	4	600	Par	Paris

Auf Ebenen basierende Hierarchien werden auf der Grundlage der in einer Dimension definierten Spalten erstellt. Mittels der Spalten einer relationalen Tabelle können in SSAS Attributhierarchien angelegt werden. Das Festlegen von Beziehungen zwischen Attributhierarchien ermöglicht das Erstellen effizienter auf Ebenen basierender Hierarchien. Gegenwärtig reicht es aus, alle die zu einer Dimension gehörigen Eigenschaften als Spalten der Dimensionstabelle hinzuzufügen, wenn es an der Zeit ist, auf Ebenen basierende Hierarchien in SSAS zu erstellen.

Weitere Informationen finden Sie unter Hierarchien und Ebenen.

Erstellen von Faktentabellen

In Faktentabellen werden sämtliche numerischen Daten für einen Cube gespeichert. Die Anzahl der Spalten einer Faktentabelle hängt von der Anzahl der Dimensionen ab, die dem Cube zugeordnet sind. Der Cube "Prognose" hat beispielsweise sieben Spalten, wobei sechs Spalten die einzelnen Dimensionen darstellen, die sich auf den Cube "Prognose" beziehen, und eine zum Speichern des numerischen Werts dient. Diese Spalte wird als "Measure" bezeichnet. Bei unserem Beispiel gibt es für die Faktentabelle nur ein Measure.

Alle Spalten mit Ausnahme der Measurespalte sind über ihren Schlüssel einer Dimension zugeordnet. Im folgenden Beispiel sehen Sie, dass das Modell "Personalbudget" fünf Dimensionen hat, die in Bezug zur Faktentabelle stehen, wobei jede Zeile der Faktentabelle einen einzelnen Faktendatensatz darstellt. Es empfiehlt sich, doppelte Werte in den Faktendatensätzen für die Dimensionsschlüssel zu vermeiden, wenn beispielsweise derselbe Wert in allen Dimensionsschlüssel für mehrere Faktenzeilen vorhanden ist. Ist dies der Fall, kombinieren Sie den Wert in einer einzelnen Zeile.

Zeilen-ID	Metrik-ID	Regions-ID	Mitarbeiter-ID	Zeit-ID	Wert
1	2	15	1010	20100000	2000
2	2	15	1009	20100000	2000
3	2	15	1008	20100000	2000

Zeilen-ID	Konto-ID	Zeit-ID	Szenario-ID	Regions-ID	Produkt-ID	Versions-ID	Wert
1151	1	20100200	1	1	232	1	1391
1153	1	20100400	2	1	232	1	1124
1155	1	20100600	2	1	232	1	1322