Einführung in Dimensionen

Alle Dimensionen von Microsoft SQL Server 2005 Analysis Services bestehen aus Gruppen von Attributen, die auf Spalten aus Tabellen oder Sichten in einer Datenquellensicht basieren. Dimensionen sind unabhängig von einem Cube vorhanden, können sowohl in mehreren Cubes als auch mehrfach in einem einzelnen Cube verwendet und zwischen Analysis Services-Instanzen verknüpft werden. Eine unabhängig von einem Cube vorhandene Dimension wird als Datenbankdimension bezeichnet und eine innerhalb eines Cubes verwendete Instanz einer Datenbankdimension als Cubedimension.

Dimension auf Basis eines Sternschemaentwurfs

Die Struktur einer Dimension hängt größtenteils von der Struktur der zugrunde liegenden Dimensionstabellen ab. Die einfachste Struktur ist das Sternschema, bei dem jede Dimension auf einer einzelnen Dimensionstabelle basiert, die über einen Primärschlüssel direkt mit der Faktentabelle verknüpft ist - Fremdschlüsselbeziehung.

Das folgende Diagramm zeigt einen Ausschnitt der Adventure Works DW-Beispieldatenbank, in der die FactResellerSales-Faktentabelle mit den zwei Dimensionstabellen DimReseller und DimPromotion verknüpft ist. Die ResellerKey-Spalte in der FactResellerSales-Faktentabelle definiert eine Fremdschlüsselbeziehung mit der ResellerKey-Primärschlüsselspalte in der DimReseller-Dimensionstabelle. Ähnlich definiert die PromotionKey-Spalte in der FactResellerSales-Faktentabelle eine Fremdschlüsselbeziehung mit der PromotionKey-Primärschlüsselspalte in der DimPromotion-Dimensionstabelle.

Dimension auf Basis eines Schneeflocken-Schemaentwurfs

In vielen Fällen ist eine komplexere Struktur erforderlich, da zum Definieren der Dimension Informationen aus mehreren Tabellen erforderlich sind. In dieser Struktur, die als Schneeflockenschema bezeichnet wird, basieren die einzelnen Dimensionen auf Attributen aus Spalten mehrerer Tabellen, die über Primärschlüssel-Fremdschlüssel-Beziehungen miteinander und letztendlich mit der Faktentabelle verknüpft sind. Die folgende Abbildung zeigt die Tabelle, die für eine vollständige Beschreibung der Product-Dimension im Adventure Works DW-Beispielprojekt erforderlich ist:

Um ein Produkt vollständig beschreiben zu können, müssen Kategorie und Unterkategorie des Produkts in der Product-Dimension enthalten sein. Diese Informationen befinden sich jedoch nicht direkt in der Haupttabelle für die DimProduct-Dimension. Eine Fremdschlüsselbeziehung zwischen DimProduct und DimProductSubcategory, die wiederum eine Fremdschlüsselbeziehung zur DimProductCategory-Tabelle hat, ermöglicht das Einschließen der Informationen für Produktkategorien und -unterkategorien in der Product-Dimension.

Schneeflockenschema im Vergleich zur Bezugsdimensionsbeziehung

Manchmal haben Sie die Wahl, ob Sie Attribute in einer Dimension mithilfe eines Schneeflockenschemas aus mehreren Tabellen erstellen oder ob Sie zwei separate Dimensionen definieren und eine auf dem Konzept der Bezugsdimension basierende Beziehung zwischen ihnen festlegen. Das folgende Diagramm veranschaulicht dieses Szenario.

Im oben dargestellten Diagramm verfügt die FactResellerSales-Faktentabelle über keine Fremdschlüsselbeziehung zur DimGeography-Dimensionstabelle. Die FactResellerSales-Faktentabelle verfügt allerdings nicht über eine Fremdschlüsselbeziehung zur DimReseller-Dimensionstabelle, die wiederum über eine Fremdschlüsselbeziehung zur DimGeography-Dimensionstabelle verfügt. Zum Definieren einer Reseller-Dimension, die geografische Informationen zu jedem Wiederverkäufer enthält, müssten diese Attribute aus den Dimensionstabellen DimGeography und DimReseller abgerufen werden. In Analysis Services erzielen Sie dasselbe Ergebnis, wenn Sie zwei separate Dimensionen erstellen und diese innerhalb einer Measuregruppe verknüpfen, indem Sie eine auf dem Konzept der Bezugsdimension basierende Beziehung zwischen beiden Dimensionen definieren. Weitere Informationen zu auf dem Konzept der Bezugsdimension basierenden Beziehungen finden Sie unter Dimensionsbeziehungen.

Ein Vorteil der Verwendung von Bezugsdimensionsbeziehungen in diesem Szenario liegt darin, dass Sie eine einzelne Geography-Dimension und anschließend mehrere darauf basierende Cubedimensionen erstellen können, ohne zusätzlichen Speicherplatz zu benötigen. Sie können z. B. eine der Geography-Cubedimensionen mit einer Reseller-Dimension verknüpfen und eine andere mit einer Customer-Dimension. Verwandte Themen:Dimensionsbeziehungen, Definieren einer referenzierten Beziehung und von Eigenschaften einer referenzierten Beziehung

Verarbeiten einer Dimension

Wenn Sie eine Dimension erstellt haben, müssen Sie diese verarbeiten, bevor Sie die Elemente der Attribute und Hierarchien in der Dimension anzeigen können. Wenn sich die Struktur einer Dimension geändert hat oder die Informationen in den zugrunde liegenden Tabellen aktualisiert wurden, müssen Sie die Dimension erneut verarbeiten, bevor Sie die Änderungen anzeigen können. Beim Verarbeiten einer Dimension nach einer strukturellen Änderung müssen sämtliche Cubes, die die Dimension enthalten, ebenfalls verarbeitet werden. Andernfalls kann der Cube nicht angezeigt werden.

Sicherheit

Alle untergeordneten Objekte einer Dimension, einschließlich Hierarchien, Ebenen und Elementen, werden mithilfe von Rollen in Analysis Services gesichert. Die Dimensionssicherheit kann für alle Cubes in der Datenbank angewendet werden, die die Dimension verwenden, oder nur für einen bestimmten Cube. Weitere Informationen zur Dimensionssicherheit finden Sie unter Erteilen des Dimensionszugriffs.

Siehe auch

Konzepte

Speichern von Dimensionen
Dimensionsübersetzungen
Dimensionen mit aktiviertem Schreibzugriff
Verwenden des Dimensions-Assistenten zum Definieren einer neuen Dimension
Verwenden des Cube-Assistenten zum Definieren von Cubes, Dimensionen, Hierarchien und Attributen

Hilfe und Informationen

Informationsquellen für SQL Server 2005