Schlüsselkonzepte in MDX (MDX)

Aktualisiert: 17. Juli 2006

Mithilfe von MDX (Multidimensional Expressions) können Sie multidimensionale Daten abfragen oder MDX-Ausdrücke zur Verwendung innerhalb eines Cubes erstellen. Voraussetzung dafür ist jedoch, dass Sie über Grundkenntnisse der Dimensionskonzepte und der Terminologie von Microsoft SQL Server 2005 Analysis Services (SSAS) verfügen. Der folgende Abschnitt enthält eine kurze Beschreibung der zum Verständnis von MDX benötigten Grundkonzepte der Dimensionsmodellierung sowie der Terminologie. Die nachfolgenden Abschnitte veranschaulichen, wie diese Konzepte angewendet werden.

Weitere Informationen finden Sie im Abschnitt mit zusätzlichen Informationen auf der Microsoft TechNet-Website SQL Server 2005 – Analysis Services (in Englisch). Weitere Informationen zu Leistungsproblemen im Zusammenhang mit MDX-Abfragen und -Berechnungen finden Sie im Abschnitt "Writing Efficient MDX" (in Englisch) im SQL Server 2005 Analysis Services Performance Guide.

Begriffe und Konzepte der Dimensionsmodellierung

Die Struktur eines Cubes in Microsoft SQL Server 2005 Analysis Services (SSAS) basiert auf Measures, Dimensionen sowie Dimensionsattributen. In der folgenden Tabelle werden die Begriffe und Konzepte der Dimensionsmodellierung erläutert, die Sie zum Verwenden der MDX-Ausdruckssprache kennen müssen.

• Datenbankdimension
  Eine Datenbankdimension ist eine Auflistung von Dimensionsattributen, die mit einem Schlüsselattribut verknüpft sind, welches selbst wiederum mit Fakten in der Measuredimension verknüpft ist.

• Dimensionsattribut
  Ein Dimensionsattribut ist an eine oder mehrere Spalten der Dimensionstabelle gebunden und enthält Elemente. Dimensionsattribute können z. B. Kundennamen, Monatsnamen oder Produktnamen enthalten.

• Element
  Ein Element ist der Wert eines Dimensionsattributs, einschließlich der Measuredimension. Bei einem Element in einer Hierarchie kann es sich um ein Blattelement, ein übergeordnetes Element, ein Datenelement oder ein (Alle)-Element handeln.

• Measure
  Ein Measure ist ein Wert aus einer Faktentabelle, der auch als Fakt bezeichnet wird. Werte in einer Measuredimension werden allgemein gelegentlich auch als Elemente bezeichnet. Measures sind im Allgemeinen numerische Werte, können aber auch Zeichenfolgenwerte sein.

• Measuredimension
  Eine Measuredimension ist eine Dimension, die alle Measures im Cube enthält. Bei der Measuredimension handelt es sich um eine besondere Art von Dimension, in der die Elemente in der Regel aggregiert sind (im Allgemeinen durch Summierung oder Zählen), und zwar basierend auf dem aktuellen Element jedes Dimensionsattributs, zu dem ein angegebenes Measure vorhanden ist.

• Measuregruppe
  Eine Measuregruppe ist eine Auflistung von verknüpften Measures in einem Cube in SQL Server 2005 Analysis Services (im Allgemeinen Measures aus der gleichen Faktentabelle). In SQL Server 2005 Analysis Services kann ein Cube mehrere Measuregruppen enthalten.

• (Alle)-Element
  Das (Alle)-Element ist der berechnete Wert aller Elemente in einer Attributhierarchie oder einer benutzerdefinierten Hierarchie.

• Berechnetes Element
  Ein berechnetes Element ist ein Dimensionselement, das zum Abfragezeitpunkt definiert und berechnet wird. Ein berechnetes Element kann in einer Benutzerabfrage oder in einem MDX-Berechnungsskript definiert und auf dem Server gespeichert werden. Ein berechnetes Element entspricht Zeilen in der Dimensionstabelle der Dimension, in der diese definiert sind.

• Datenelement
  Ein Datenelement ist ein untergeordnetes Element, das mit einem übergeordneten Element in einer Parent-Child-Hierarchie verknüpft ist. Ein Datenelement enthält den Datenwert des ihm übergeordneten Elements, nicht den aggregierten Wert der untergeordneten Elemente des übergeordneten Elements.

• Übergeordnetes Element
  Ein übergeordnetes Element ist ein Element einer Parent-Child-Hierarchie, das den aggregierten Wert der ihm untergeordneten Elemente enthält.

• Blattelement
  Ein Blattelement ist ein Element einer Hierarchie, das keine ihm untergeordneten Elemente besitzt.

• Untergeordnetes Element
  Ein untergeordnetes Element ist ein Element in einer Hierarchie, das sich unterhalb der obersten Ebene befindet.

• Schlüsselattribut
  Das Schlüsselelement einer Datenbankdimension ist das Attribut, mit dem alle Nichtschlüsselattribute in der Dimension (direkt oder indirekt) verknüpft sind. Das Schlüsselattribut ist häufig auch gleichzeitig das Granularitätsattribut.

• Granularitätsattribut
  Das Attribut einer Cubedimension, das eine Dimension mit den Fakten in einer Measuregruppe in der Measuredimension verknüpft. Wenn Granularitätsattribut und Schlüsselattribut unterschiedliche Attribute sind, müssen Nichtschlüsselattribute direkt oder indirekt mit dem Granularitätsattribut verknüpft sein. Innerhalb eines Cubes definiert das Granularitätsattribut die Granularität einer Dimension.

• Cubedimension
  Eine Cubedimension ist eine Instanz einer Datenbankdimension in einem Cube.

• Attributhierarchie
  Eine Attributhierarchie ist eine Hierarchie von Attributelementen, die folgende Ebenen enthält:

  • Eine Blattebene, die die verschiedenen Attributelemente enthält. Die Elemente der Blattebene werden auch als Blattelemente bezeichnet.
  • Zwischenebenen, wenn es sich bei der Attributhierarchie um eine Parent-Child-Hierarchie handelt
  • Eine optionale (Alle)-Ebene (IsAggregatable=True), die die aggregierten Werte der Blattelemente der Attributhierarchie enthält. Die Elemente der (Alle)-Ebene werden auch als (Alle)-Elemente bezeichnet.

  Standardmäßig wird für jedes Dimensionsattribut eine Attributhierarchie definiert (AttributeHierarchyEnabled=True). Attributhierarchien sind standardmäßig sichtbar (AttributeHierarchyVisible=True).

• Ausgeglichene Hierarchie
  Eine ausgeglichene Hierarchie ist eine Hierarchie, in der zwischen der obersten Ebene und jedem Blattelement die gleiche Anzahl von Ebenen liegen.

• Unregelmäßige Hierarchie
  Siehe unausgeglichene Hierarchie.

• Unausgeglichene Hierarchie
  Eine unausgeglichene Hierarchie ist eine Hierarchie, in der zwischen der obersten Ebene und der Blattebene unterschiedlich viele Ebenen liegen. Ein Beispiel für eine unregelmäßige Hierarchie ist die Parent-Child-Hierarchie. Unausgeglichene Hierarchien werden auch unregelmäßige Hierarchien genannt.

• Parent-Child-Hierarchie
  Eine Parent-Child-Hierarchie ist eine besondere Art von Attributhierarchie, in der für ein Attribut in der Dimension der Typ parent festgelegt ist. Eine Parent-Child-Hierarchie ist eine unausgeglichene Hierarchie von untergeordneten und übergeordneten Elementen. Parent-Child-Hierarchien enthalten die folgenden Ebenen:

  • Child-Ebenen (untergeordnete Ebenen), die die untergeordneten Elemente von übergeordneten Elementen enthalten. Die untergeordneten Elemente eines übergeordneten Elements enthalten die Attributelemente, die zum übergeordneten Element aggregiert werden, einschließlich der Datenelemente.
  • Zwischenebenen, die übergeordnete Elemente enthalten
  • Eine optionale (Alle)-Ebene (IsAggregatable=True), die die aggregierten Werte der Blattelemente der Parent-Child-Hierarchie enthält. Die Elemente der (Alle)-Ebene werden auch als (Alle)-Elemente bezeichnet.
  • Nur eine einzige Parent-Child-Hierarchie ist pro Dimension möglich, und die Hierarchie muss mit dem Schlüsselattribut verknüpft sein.

• Benutzerdefinierte Hierarchie
  Eine benutzerdefinierte Hierarchie ist eine ausgeglichene Hierarchie von Attributhierarchien, die es dem Benutzer ermöglicht, Cubedaten zu durchsuchen. Benutzerhierarchien vergrößern nicht den Cuberaum. Ebenen in einer benutzerdefinierten Hierarchie können unter bestimmten Bedingungen ausgeblendet werden. Die Hierarchie erscheint dann unausgeglichen.

• Attributbeziehung
  Eine Attributbeziehung ist eine 1:n-Beziehung zwischen Attributen. Ein Beispiel dafür ist die Beziehung zwischen einem State- und einem City-Dimensionsattribut.

• Elementeigenschaft
  Eine Elementeigenschaft ist eine Eigenschaft eines Attributelements, wie z. B. das Geschlecht eines Kunden oder die Farbe eines Produkts.

• Zelle
  Eine Zelle in einem Cube ist der Raum am Schnittpunkt zwischen einem Element der Measuredimension und einem Element von jeder Attributhierarchie in einem Cube.

  • Beim Element der Measuredimension kann es sich um ein Blattelement (ein einzelner Fakt) oder ein aggregiertes Element (z. B. aggregierte Umsätze für ein bestimmtes Jahr) handeln.
  • Bei einem Element einer Dimension kann es sich um ein Blattelement, ein Datenelement, ein übergeordnetes Element oder ein (Alle)-Element handeln.

• Cuberaum
  Der Cuberaum ist das Produkt aus den Elementen der Attributhierarchien eines Cubes und den Measures des Cubes.

• Teilcube
  Ein Teilcube ist eine Untermenge eines Cubes, die einer gefilterten Sicht des Cubes entspricht. Teilcubes können mithilfe von SCOPE-Anweisungen in einem MDX-Berechnungsskript oder von untergeordneten SELECT-Klauseln in einer MDX-Abfrage definiert werden.

• Mithilfe untergeordneter SELECT-Klausel definierter Teilcube
  Ein Teilcube, der mithilfe einer untergeordneten SELECT-Klausel in einer MDX-Abfrage definiert wird, schließt alle Elemente, die der Teilcubedefinition entsprechen, ein. Dies hat folgende Konsequenzen:

  • Das Einschließen eines (Alle)-Elements einer Hierarchie entspricht dem Einschließen aller Blattelemente der Hierarchie.
  • Durch Einschließen eines beliebigen Elements werden auch die ihm vorausgehenden und nachfolgenden Elemente eingeschlossen.
  • Durch Einschließen aller Elemente einer Ebene einer benutzerdefinierten Hierarchie werden alle Elemente der benutzerdefinierten Hierarchie eingeschlossen. Es können jedoch Elemente ausgeschlossen werden, für die keine Elemente auf der Ebene vorhanden sind (wie z. B. eine Stadt ohne Kunden).
  • Sämtliche (Alle)-Elemente eines Cubes sind stets in seinen Teilcubes vorhanden.
  • Aggregatwerte im Teilcube werden visuell summiert.

Tupel

Ein Tupel dient zur eindeutigen Identifizierung einer Zelle basierend auf einer Kombination von Attributelementen, die jeweils ein Attribut aus jeder Hierarchie des Cubes umfasst. Zum Definieren eines Tupels in einer MDX-Abfrage oder in einem MDX-Ausdruck ist es nicht erforderlich, die Attributelemente aus allen Attributhierarchien explizit einzuschließen. Wenn ein Element aus einer Attributhierarchie nicht explizit in eine Abfrage oder einen Ausdruck eingeschlossen ist, wird das Standardelement der betreffenden Attributhierarchie implizit in das Tupel eingeschlossen. Sofern nicht anderweitig explizit in einem Cube definiert, ist das Standardelement jeder Attributhierarchie das (Alle)-Element, falls ein solches vorhanden ist. Wenn kein (Alle)-Element innerhalb einer Attributhierarchie vorhanden ist, wird als Standardelement ein Element der obersten Ebene der Attributhierarchie verwendet. Sofern kein anderes Standardmeasure explizit definiert wurde, wird als Standardmeasure das erste im Cube angegebene Measure verwendet. Weitere Informationen finden Sie unter Definieren eines Standardelements und DefaultMember (MDX).

Beispielsweise identifiziert das folgende Tupel eine einzelne Zelle in der Adventure Works-Datenbank, wobei nur ein einziges Element der Measuredimension explizit definiert ist.

(Measures.[Reseller Sales Amount])

Im vorherigen Beispiel wurde die Zelle eindeutig identifiziert, die das Reseller Sales Amount-Element der Measure-Dimension und das Standardelement jeder Attributhierarchie im Cube enthält. Das Standardelement jeder Attributhierarchie ist dabei das jeweilige (Alle)-Element. Eine Ausnahme stellt die Destination Currency-Attributhierarchie dar. Das Standardelement der Destination Currency-Hierarchie ist das US Dollar-Element (dieses Standardelement ist im MDX-Skript des Adventure Works-Cube definiert).

Wichtig:
Das Element einer Attributhierarchie in einem Tupel wird auch von den Beziehungen beeinflusst, die zwischen Attributen innerhalb einer Dimension definiert sind. Weitere Informationen finden Sie weiter unten im Abschnitt Attributbeziehungen und Cuberaum.

Die folgende Abfrage gibt den Wert der Zelle zurück, auf die sich das im vorherigen Beispiel angegebene Tupel bezog ($80,450.596.98).

SELECT 
Measures.[Reseller Sales Amount] ON COLUMNS 
FROM [Adventure Works]

Hinweis:
Wenn Sie in einer Abfrage eine Achse für eine Menge angeben (in diesem Fall bestehend aus einem einzigen Tupel), müssen Sie zunächst eine Menge für die Spaltenachse und dann eine Menge für die Zeilenachse angeben. Die Spaltenachse wird auch als axis(0) oder einfach 0 bezeichnet. Weitere Informationen zu MDX-Abfragen finden Sie unter Grundlegende MDX-Abfrage (MDX).

Wie das vorherige Beispiel zeigte, können Sie ein Tupel in einer Abfrage verwenden, um den Wert in der Zelle zurückzugeben, auf die das Tupel verweist. Sie können ein Tupel aber auch in einem Ausdruck verwenden, um explizit auf das im Tupel angegebene Element zu verweisen. Abfragen und Ausdrücke können mithilfe von Funktionen Tupel zurückgeben oder verarbeiten. Mit einem Tupel kann entweder auf den Wert einer Zelle, die das Tupel angibt, verwiesen werden oder, bei Verwendung in einer Funktion, eine Kombination von Elementen angegeben werden.

Mit Dimensionalität eines Tupels ist die Sequenz oder Reihenfolge der Elemente im Tupel gemeint. Da implizite Elemente immer in der gleichen Reihenfolge auftreten, bezieht sich der Begriff Dimensionalität meistens ausschließlich auf die explizit definierten Elemente eines Tupels. Die Reihenfolge der Elemente eines Tupels ist beim Definieren einer Menge von Tupeln von großer Bedeutung. Im folgenden Beispiel werden zwei Elemente in ein Tupel auf der Spaltenachse eingeschlossen.

SELECT 
([Measures].[Reseller Sales Amount],[Date].[Calendar Year].[CY 2004]) ON COLUMNS 
FROM [Adventure Works]

Hinweis:
Wenn Sie in einem Tupel Elemente aus mehreren Dimensionen explizit angeben, müssen Sie das gesamte Tupel in Klammern einschließen. Wenn Sie nur ein einziges Element in einem Tupel angeben, sind die Klammern optional.

Das Tupel in der Abfrage aus dem vorherigen Beispiel gibt den Rückgabewert der Cubezelle an, die sich am Schnittpunkt des Reseller Sales Amount-Measures der Measure-Dimension mit dem CY 2004-Element der Calendar Year-Attributhierarchie in der Date-Dimension befindet.

Hinweis:
Auf ein Attributelement kann entweder mit seinem Elementnamen oder seinem Elementschlüssel verwiesen werden. Der Verweis auf [CY 2004] im vorherigen Beispiel könnte durch &[2004] ersetzt werden.

Mengen

Eine Menge ist eine geordnete Menge von Tupeln gleicher Dimensionalität. Dies ist ein Beispiel für eine Menge:

SELECT 
   {
      ([Measures].[Reseller Sales Amount],
         [Date].[Calendar Year].[CY 2003]),
      ([Measures].[Reseller Sales Amount],
         [Date].[Calendar Year].[CY 2004])
   } ON COLUMNS 
FROM [Adventure Works]

Hinweis:
Verwenden Sie zum Kennzeichnen einer Menge von Tupeln geschwungene Klammern.

Im vorherigen Beispiel hatten alle Tupel in der Menge die gleiche Dimensionalität, weil das erste Element jedes Tupels Element der Measures-Dimension und das zweite Element jedes Tupels Element der Calendar Year-Attributhierarchie war. Wäre das zweite Element jedes Tupels Element einer anderen Attributhierarchie in der Date-Dimension (z. B. Calendar Month) gewesen, wäre wegen des Unterschieds in der Dimensionalität eine Fehlermeldung angezeigt worden.

Tipp:
Sie können eine Menge mit einem Alias erstellen. Solche Mengen werde als benannte Mengen bezeichnet. Benannte Mengen erleichtern das Verständnis und das Wiederverwenden von MDX-Abfragen mit komplexen MDX-Ausdrücken. Zum Verwenden einer benannten Menge geben Sie nach dem Mengenbezeichner das Wort "AS" gefolgt von dem gewünschten Aliasnamen an.

Cuberaum und Auto-exist

Weiter oben in diesem Thema haben wir Cuberaum als Produkt der Elemente der Attributhierarchien des Cubes definiert. Auto-exist schränkt den Cuberaum auf solche Zellen ein, die tatsächlich vorhanden sind. Elemente einer Attributhierarchie in einer Dimension sind möglicherweise nicht gemeinsam mit Elementen einer anderen Attributhierarchie in der gleichen Dimension vorhanden.

Bei einem Cube z. B., der eine City-Attributhierarchie, eine Country-Attributhierarchie und eine Internet Sales Amount-Measure aufweist, schließt der Cuberaum nur solche Elemente ein, die gemeinsam vorhanden sind. Wenn beispielsweise die City-Attributhierarchie die Städte New York, London, Paris, Tokyo und Melbourne und die Country-Attributhierarchie die Länder United States, United Kingdom, France, Japan, and Australia umfasst, schließt der Cuberaum nicht den Raum (die Zelle) am Schnittpunkt von Paris und United States ein.

Beim Abfragen von nicht vorhandenen Zellen wird NULL zurückgegeben, d. h., nicht vorhandene Zellen können keine Berechnungen enthalten, und Sie können auch keine Berechnungen definieren, die in sie schreiben. Die folgende Anweisung beinhaltet beispielsweise Zellen, die nicht vorhanden sind:

SELECT [Customer].[Gender].[Gender].Members ON COLUMNS,
{[Customer].[Customer].[Aaron A. Allen]
   ,[Customer].[Customer].[Abigail Clark]} ON ROWS 
FROM [Adventure Works]
WHERE Measures.[Internet Sales Amount]

Hinweis:
Diese Abfrage verwendet die Members (Menge) (MDX)-Funktion, um eine Menge von Elementen der Gender-Attributhierarchie auf der Spaltenachse zurückzugeben und diese Menge mit der angegebenen Menge von Elementen der Customer-Attributhierarchie auf der Zeilenachse zu kreuzen.

Beim Ausführen der vorherigen Abfrage zeigt die Zelle am Schnittpunkt zwischen Aaron A. Allen und Female eine Null an. Entsprechend zeigt die Zelle am Schnittpunkt zwischen Abigail Clark und Male ebenfalls eine Null an. Diese Zellen sind nicht vorhanden und können daher keine Werte enthalten, sie können jedoch im Ergebnis einer Abfrage angezeigt werden.

Wenn Sie die Crossjoin (MDX)-Funktion verwenden, um das Kreuzprodukt von Attributhierarchie-Elementen und Attributhierarchien in der gleichen Dimension zurückzugeben, beschränkt Auto-exist das zurückgegebene Ergebnis auf die Menge der Tupel, die tatsächlich vorhanden sind, und gibt nicht das vollständige kartesische Produkt zurück. Führen Sie z. B. die folgenden Abfrage aus, und überprüfen Sie die Ergebnisse.

SELECT CROSSJOIN
   (
      {[Customer].[Country].[United States]},
         [Customer].[State-Province].Members
  ) ON 0 
FROM [Adventure Works]
WHERE Measures.[Internet Sales Amount]

Hinweis:
Beachten Sie, dass 0 hier für die Spaltenachse steht (als Kurzform für axis(0)).

Die vorherige Abfrage gibt nur Zellen für Elemente der Attributhierarchien in der Abfrage zurück, die gemeinsam vorhanden sind. Die vorherige Abfrage kann auch mithilfe der neuen *-Variante der * (Crossjoin) (MDX)-Funktion formuliert werden.

SELECT 
   [Customer].[Country].[United States] * 
      [Customer].[State-Province].Members
ON 0 
FROM [Adventure Works]
WHERE Measures.[Internet Sales Amount]

Die vorherige Abfrage kann auch wie folgt formuliert werden:

SELECT [Customer].[State-Province].Members
ON 0 
FROM [Adventure Works]
WHERE (Measures.[Internet Sales Amount],
   [Customer].[Country].[United States])

Die zurückgegebenen Zellenwerte sind identisch, die Metadaten im Resultset sind jedoch verschieden. Beispielsweise wurde in der vorherigen Abfrage die Country-Hierarchie auf die Slicerachse verschoben (in die WHERE-Klausel), sodass sie nicht explizit im Resultset angezeigt wird.

Alle drei vorherigen Abfragen veranschaulichen die Auswirkung des Auto-exist-Verhaltens von SQL Server 2005 Analysis Services.

Benutzerdefinierte Hierarchien und Cuberaum

In den vorherigen Beispielen in diesem Thema wurden Positionen im Cuberaum mithilfe von Attributhierarchien definiert. Es ist jedoch auch möglich, Positionen um Cuberaum mithilfe von benutzerdefinierten Hierarchien zu definieren, die basierend auf Attributhierarchien in einer Dimension definiert wurden. Eine benutzerdefinierte Hierarchie ist eine Hierarchie von Attributhierarchien, die es dem Benutzer ermöglicht, Cubedaten zu durchsuchen.

Beispielsweise ließe sich die CROSSJOIN-Abfrage im vorherigen Abschnitt auch wie folgt formulieren:

SELECT CROSSJOIN
   (
      {[Customer].[Country].[United States]},
         [Customer].[Customer Geography].[State-Province].Members
   ) 
ON 0 
FROM [Adventure Works]
WHERE Measures.[Internet Sales Amount]

In der vorherigen Abfrage wurde die benutzerdefinierte Customer Geography-Hierarchie innerhalb der Customer-Dimension zum Definieren der Position im Cuberaum verwendet, die zuvor über eine Attributhierarchie definiert worden war. Die gleiche Position im Cuberaum kann sowohl mithilfe von Attributhierarchien als auch mithilfe von benutzerdefinierten Hierarchien definiert werden.

Attributbeziehungen und Cuberaum

Das Definieren von Attributbeziehungen zwischen verknüpften Attributen verbessert die Abfrageleistung (durch vereinfachte Erstellung von entsprechenden Aggregationen) und wirkt sich auf das Element einer verknüpften Attributhierarchie aus, das zusammen mit einem Attributhierarchie-Element auftritt. Wenn Sie beispielsweise ein Tupel definieren, das ein Element der City-Attributhierarchie einschließt, und das Tupel nicht explizit die Country-Attributelemente definiert, wäre zu erwarten, dass das Element der Country-Attributhierarchie das verknüpfte Element der Country-Attributhierarchie darstellt. Dies ist jedoch nicht der Fall, wenn eine Attributbeziehung zwischen der City-Attributhierarchie und der Country-Attributhierarchie definiert ist.

Im folgenden Beispiel wird das Element einer verknüpften Attributhierarchie zurückgegeben, die nicht explizit in der Abfrage eingeschlossen ist.

WITH MEMBER Measures.x AS 
   Customer.Country.CurrentMember.Name
SELECT Measures.x ON 0,
Customer.City.Members ON 1
FROM [Adventure Works]

Hinweis:
Beachten Sie, dass das WITH-Schlüsselwort mit der CurrentMember (MDX)-Funktion und der Name (MDX)-Funktion verwendet wird, um ein berechnetes Element für die Abfrage zu erstellen. Weitere Informationen finden Sie unter Grundlegende MDX-Abfrage (MDX).

In der vorherigen Abfrage wurde der Name des Elements der Country-Attributhierarchie zurückgegeben, das mit jedem Element der State-Attributhierarchie verknüpft ist. Das erwartete Country-Element wird angezeigt (weil eine Attributbeziehung zwischen City- und Country-Attributen definiert ist). Ohne Attributbeziehung zwischen Attributhierarchien der gleichen Dimension wäre das (Alle)-Element zurückgegeben worden, wie die folgende Abfrage veranschaulicht.

WITH MEMBER Measures.x AS 
   Customer.Education.Currentmember.Name
SELECT Measures.x  ON 0, 
Customer.City.Members ON 1
FROM [Adventure Works]

In der vorherigen Abfrage wird das (Alle)-Element ("All Customers") zurückgegeben, weil keine Beziehung zwischen Education und City besteht. Daher ist das (Alle)-Element der Education-Attributhierarchie das Standardelement der Education-Attributhierarchie, das in jedem Tupel verwendet wird, in dem die City-Attributhierarchie vorkommt und in dem kein Education-Element explizit bereitgestellt wird.

Berechnungskontext

Alle Mengen, Elemente, Tupel und numerischen Funktionen werden im Kontext des gesamten MDX-Ausdrucks bzw. der gesamten MDX-Anweisung ausgeführt. Beim Übergeben eines Arguments, wie z. B. eines Tupels, an eine Funktion werden nur einige Koordinaten im Cuberaum explizit bereitgestellt. Die anderen Koordinaten werden basierend auf dem aktuellen Berechnungskontext ermittelt. Der Berechnungskontext für nicht angegebene Zellenkoordinaten und Attributelemente wird in der folgenden Reihenfolge bestimmt:

1. Die FROM-Klausel (ggf.) – Diese Klausel kann entweder einen gesamten Cube oder einen Teilcube in Form einer SELECT-Anweisung angeben.
2. Die WHERE-Klausel (ggf.) – Über diese Klausel, die auch Slicerachse genannt wird, werden Mengen, Tupel oder Elemente angegeben, die die von der Abfrage zurückgegebenen Elemente auf der Spalten- und Zeilenachse einschränken. Prinzipiell sind die Standardelemente aller Attributhierarchien, die nicht explizit auf der Spalten- oder Zeilenachse angegeben werden, Teil der Slicerachse.

   Hinweis:

   Wenn Zellenkoordinaten für ein bestimmtes Attribut sowohl auf der Slicerachse als auch auf einer weiteren Achse angegeben sind, werden die in der Funktion angegebenen Koordinaten möglicherweise vorrangig zur Bestimmung der Elemente der Menge auf der Achse verwendet. Die Funktionen Filter (MDX) und Order (MDX) sind Beispiele für solche Funktionen – Sie können ein Ergebnis nach Attributelementen filtern oder sortieren, die von der WHERE-Klausel oder der SELECT-Anweisung in der FROM-Klausel aus dem Berechnungskontext ausgeschlossen sind.

3. Die in der Abfrage oder im Ausdruck definierten benannten Mengen und berechneten Elemente
4. Die auf der Zeilen- und Spaltenachse angegebenen Tupel und Mengen, die die Standardelemente der Attribute verwenden, die nicht auf der Zeilen-, Spalten oder Slicerachse angezeigt werden
5. Die Cube- oder die Teilcubezellen auf jeder Achse unter Entfernung leerer Tupel von der Achse und Anwendung der HAVING-Klausel
6. Weitere Informationen finden Sie unter Festlegen des Cubekontexts in einer Abfrage (MDX).
7. In der folgenden Abfrage ist der Berechnungskontext für die Zeilenachse durch die in der WHERE-Klausel angegebenen Attributelemente Country und Calendar Year eingeschränkt.

SELECT Customer.City.City.Members ON 0
FROM [Adventure Works]
WHERE (Customer.Country.France, [Date].[Calendar].[Calendar Year].[CY 2004],
   Measures.[Internet Sales Amount])

1. Wenn Sie jedoch diese Abfrage ändern, indem Sie die FILTER-Funktion auf der Zeilenachse angeben und ein Element der Calendar Year-Attributhierarchie in der FILTER-Funktion verwenden, kann das Attributelement der Calendar Year-Attributhierarchie, das zum Bereitstellen des Berechnungskontextes für die Elemente der Menge auf der Spaltenachse verwendet wird, geändert werden.

SELECT FILTER
   (
      Customer.City.City.Members, 
         ([Date].[Calendar].[Calendar Year].[CY 2003],
            Measures.[Internet Order Quantity]) > 75 
   ) ON 0
FROM [Adventure Works]
WHERE (Customer.Country.France,
   [Date].[Calendar].[Calendar Year].[CY 2004],
   Measures.[Internet Sales Amount])

1. In der vorherigen Abfrage wird der Berechnungskontext für die Zellen in den Tupeln, die auf der Spaltenachse angezeigt werden, vom CY 2003-Element der Calendar Year-Attributhierarchie gefiltert, obwohl nomineller Berechnungskontext für die Calendar Year-Attributhierarchie das CY 2004-Element ist. Außerdem wird er vom Internet Order Quantity-Measure gefiltert. Sobald jedoch die Elemente der Menge auf der Spaltenachse festgelegt sind, wird der Berechnungskontext für die Werte der Elemente, die auf der Achse angezeigt werden, wieder über die WHERE-Klausel bestimmt.

Wichtig:
Zur Verbesserung der Abfrageleistung sollten Elemente und Tupel beim Auflösungsvorgang so früh wie möglich entfernt werden. Auf diese Weise werden komplexe Abfragezeitberechnungen für die endgültige Menge der Elemente mit minimaler Zellenanzahl durchgeführt.

Siehe auch

Konzepte

MDX-Sprachreferenz (MDX)

Andere Ressourcen

Multidimensional Expressions (MDX) - Referenz

Hilfe und Informationen

Informationsquellen für SQL Server 2005

Änderungsverlauf

Version	Verlauf
17. Juli 2006	Geänderter Inhalt: Konzepte wurden zur Verdeutlichung aktualisiert. Aktualisierte Beispiele wurden hinzugefügt.