Dieser Artikel wurde maschinell übersetzt.

Aus SQL Server

Komponententests von OLAP-Cubes in SQL Server mit C#

Mark Nadelson

Beispielcode herunterladen

Ich fühle mich ein wenig wie Thomas Jefferson, wenn ich sage, "wir halten diese Wahrheiten für selbstverständlich, dass der gesamte Code bestimmte unveräußerliche Rechte hat, und dass unter dieser Rechte ist die Fähigkeit, gründlich Einheit getestet in eine einfache und übersichtliche Weise damit Fehler leicht identifiziert werden können und Produktionsausfällen minimiert." Ein bisschen dramatisch, ja, aber es worauf ankommt.

Natürlich glauben die meisten Entwickler Codeprobleme sollte Einheit getestet, aber was passiert, wenn die Definition der "Code" ist verschwommen? Dies war die Situation, die ich fand mich in vor kurzem, wenn eine komplizierte Frage vorgelegt und beauftragt, um eine Lösung zu finden. Eine Gruppe von Entwicklern beteiligte sich mit dem Schreiben eines komplexen online analytical Processing (OLAP)-Cubes mit SQL Server Analysis Services (SSAS). Dieser Würfel hatte zahlreiche Dimensionen, die alle mit einer extrem komplexen Faktentabelle verknüpft. Weil die Entwickler ganz geschickt in der Entwicklung von Würfel waren, konnten sie den Würfel zusammenzusetzen, sondern überprüfen die Ergebnisse ihrer Abfragen (Multidimensional Expressions) war eine schwierige Aufgabe. Die Schwierigkeit wurde verstärkt durch eine Reihe von Faktoren, einschließlich die Datenmenge in den Dimensionen sowie Faktentabelle und die Zeit und computing-Ressourcen, um den Würfel zu bauen. Sobald der Cube erstellt wurde, waren die Ergebnisse (produziert von MDX-Abfragen) an den Benutzer gesendet. Wenn der Benutzer ein Problem mit den Daten gefunden, dauert es lange, bis das Problem ausfindig zu machen. Auch, wenn das zugrunde liegende Problem entdeckt und behoben war, der Cube müssten regeneriert werden. Erschwerend, wenn Dimensionen wurden hinzugefügt, die zugrunde liegenden Faktentabelle aktualisiert wurde oder der Cube entstand unter Verwendung unterschiedliche Aggregationen, gab es keine Möglichkeit, die gesamten Auswirkungen dieser Veränderungen zu ermitteln. Eine scheinbar harmlose Änderung hätte eine weit reichende und kaskadierende Wirkung auf Abfragen auf den Cube.

Die Lösung für die Cube-Rätsel ist die Schaffung einer Umgebung und einen Prozess worin können des Cubes Dimensionen und Fakten über eine begrenzte Menge an Daten zu inszenieren und Abfragen für Cube mithilfe die Serienversion des Schema der Cubes auszuführen. Idealerweise würde die Test-Version des Cubes neu jedes Mal erstellt werden die Komponententests beseitigen die Chance für Nebenwirkungen, die aus bereits vorhandenen Artefakte. Weitere Anforderungen für das Unit-Test Framework (und wirklich diese gelten für die meisten Unit-Test-Frameworks, unabhängig von der Zielanwendung) um sicherzustellen, dass die Test-Validierungen wiederholbar sind und wenn Fehler, um schnell und einfach auftritt ermitteln, warum der Test ist fehlgeschlagen (mit den Testfall sagen "ist fehlgeschlagen, da die Daten nicht übereinstimmen" ist weniger als ideal).

In diesem Artikel präsentiere ich ein Framework, mit dem Sie eine Suite von Unit-Tests überprüfen die MDX-basierte Ausgabe von einem OLAP-Cube erstellen. Die beschriebenen Architektur ermöglicht die Erstellung eines Würfels mit einem vorhandenen Schema, in eine eigene Unit-Test-Datenbank neu erstellt jedes Mal, wenn die Testsuite ausgeführt wird. Außerdem können Sie MDX-Abfragen zur Verfügung zu stellen, die gegen die neu gegründeten Unit-Test-Version des Cubes ausgeführt werden. Weiter, es überprüft die Ergebnisse gegen eine bereits vorhandene Vorlage und präsentiert sie in einfachen HTML-Format. Dieses Muster der Testfall Validierung anhand einer Vorlage kann zu Komponententests Frameworks erweitert werden, in denen die Ergebnisdaten großer und komplexer sind.

Cube-Übersicht

Vor dem Eintauchen in die Lösung für die Cube-Test-Ausgabe, gehe ich kurz über die Konzepte und Komponenten ein Cubes. Würfel sind ein Mittel schnell Zugriff auf Daten in einem Datawarehouse. Würfel organisieren und Zusammenfassen von Daten in einer mehrdimensionalen Struktur. Würfel sind die wichtigste Komponente der OLAP-Technologie, und sie bieten einen einfach zu bedienenden Mechanismus zum Abfragen von Daten mit schnellen und vorhersagbare Antwortzeiten. Ein Cube besteht aus die Dimensionsdaten und Maßnahmen (numerische Tatsachen). Die zentrale Tabelle in einem Cube ist bekannt als der Faktentabelle, und es ist die Quelle des Cubes Maßnahmen. Die Dimensionstabellen sind der Faktentabelle verweist, und sie enthalten Hierarchieebenen von Informationen, die abgefragt werden kann. Die Dimensionshierarchie kann Benutzer Fragen auf hohem Niveau. Dann können mit der Dimensionshierarchie Benutzer nach mehr Details erhalten.

Würfel sind in einer Datenbank enthalten. Die Objekte, aus denen sich die Cubestruktur für eine bestimmte Datenbank sind wie folgt:

• Datenquellen: Dies sind die Quellen der Informationen in den Cube geladen werden.
• Maßnahmen: Dies sind die Zahlenwerte in den Cube vertreten. Sie können Termine, aber sind in der Regel numerisch mit unterschiedlichem Aggregation (z. B. Summe, Max, Min und Anzahl).
• Abmessungen: Diese sind Attribute Maßnahmen zugeordnet. Geschäftsdaten, Kundennamen und geographischen Regionen sind gängige Beispiele für Dimensionen.
• Partitionen: Eine Partition definiert einen Teil der Daten in einer Measuregruppe geladen. Wenn Sie mehrere Partitionen erstellen, der Cube kann parallel verarbeitet werden und gespeichert und abgefragt, getrennt, wodurch die Leistung verbessert. Sie können einzelne Partitionen neu verarbeiten, ohne die anderen Partitionen.
• Würfel Rollen: Jeder Cube sollte mindestens eine Cuberolle Zugriff auf Endbenutzer haben. Rollen können Zugriff auf alle Daten oder eine Teilmenge der Daten innerhalb des Cubes, die basierend auf einem einzelnen Benutzer-ID oder eine Active Directory-Gruppe gespeichert.

Die Definition für das Schema eines Cubes kann SSAS in Form von XML for Analysis (XMLA) entnommen werden. XMLA ist ein SOAP-basierte XML-Protokoll, das über HTTP auf den Cube zugreifen. Die XMLA-Definition enthält alle Details für jede der fünf Würfel Objekte wie oben beschrieben. XMLA können Sie den Cube auf verschiedenen Datenbanken oder Servern schnell und einfach neu zu erstellen. Es ist der Eckstein, mit denen der Einheit getestet werden Cube erstellt wird.

Sobald ein Cube erstellt und verarbeitet ist, können die Daten-Maßnahmen mit einen Mix und Match von der Vielfalt der Dimensionen erstellt abgefragt werden. Würfel werden mit der oben genannten MDX-Syntax abgefragt. Wie eine SQL-Abfrage enthält eine MDX-Abfrage eine Datenanforderung (mithilfe der SELECT-Anweisung), einen Datenpunkt (mithilfe der FROM-Anweisung) und einer optionalen Daten-Filter (mit der WHERE-Klausel). Hier ist ein einfaches Beispiel:

    SELECT {[<axis specification using Measures>]...} ON AXIS(0),
           {[<axis specification using a dimension hierarchy>]...} ON AXIS(1)
    FROM [<cube>]
    WHERE (<filter specification>)

Der Beispiel-Sales-Cube

Ich habe einen Beispiel-Cube, mit dem Sie schnell Abfrage Verkaufsdaten für verschiedene Läden an verschiedenen Terminen von verschiedenen Kunden (siehe Abbildung 1).

Abbildung 1 Beispiel Sales-Cube Datenbankdiagramm

Der Würfel besteht aus vier Dimensionstabellen mit einer Faktentabelle verbinden. Der Einfachheit halber enthält die Faktentabelle eine Maßnahme bezeichnet die Menge, die die Menge eines bestimmten Elements verkauft an einem bestimmten Kunden an einem Speicherort auf einem bestimmten Datum darstellt. Mit dieser Cubekonfiguration kann der Benutzer schnell verschiedene Fakten mit verschiedenen Dimensionen Abfragen. Z. B. Führungskräfte erhalten eine klare Vorstellung davon Produkte verkaufen in die Läden, oder sie können Tauchen Sie ein in Details wie z. B. die Artikel bei einem bestimmten Jahr oder Monat am besten verkaufen. Eine große Anzahl von Dimensionen kann ein sales executive Anzeigen von Daten in eine Vielzahl von Möglichkeiten, bessere Einblicke in die Leistung des Shops.

Die Unit-Test-Version des Cubes erstellen

Wie bereits erwähnt, kann die Cube-Definition von SSAS in Form von einem XMLA-Dokument extrahiert werden. Dieses XMLA-Dokument wird verwendet, um die Unit-Test-Version des Cubes erstellen. Anwendung der Definition der Produktion des Cubes stellt sicher, dass die Tests genau alle Features des betreffenden Cubes ausüben werden. Schnittstelle mit der SSAS-Engine mit Microsoft.AnalysisServices.dll, die in den SQL Server -SDK-Assemblys gefunden werden können.

Das Objekt, verwendet um den Cube zu generieren ist XMLAtoCube. Der Konstruktor nimmt in einem Basis-Konfiguration-Verzeichnis, unter dem die XMLA gespeichert werden. Die Verzeichnisstruktur, ich entschied mich für den Cube XMLA Haus, ist < Basisverzeichnis > \ < Servername Produktion > \­< Produktion Datenbankname >.

XMLAtoCube enthält eine öffentliche Methode, CreateCubeFromXMLA, die die folgenden Parameter annimmt (siehe die Methode Code in Listing 1 in der Listings.zip-Datei im Codedownload):

• Servicesname_des_quellservers: Der Name des Produktionsservers, die den Cube enthält.
• TargetServerName: Der Name des Servers, der die Unit-Test-Version des Cubes beherbergen wird.
• SourceDatabaseName: Der Name der Produktionsdatenbank, die den Cube enthält.
• Zieldatenbankname: Der Name der Datenbank, die die Unit-Test-Version des Cubes beherbergen wird.
• DataSourceProviderDefinition: Die Verbindung Zeichenfolge-URL, die Unit-Test-Version des Würfels auf den Speicherort der seinen Originalabmessungen und Faktentabelle zeigt. Dies wird die Datenquelle für den Komponententest verkleinerten sein.

CreateCubeFromXMLA zuerst baut eine Verbindung auf die Version von dem Komponententest-Analytics-Server und die Unit-Test-Version von der Cubedatenbank löscht, falls es bereits vorhanden ist. Das Löschen der Datenbank ist wichtig, weil dadurch sichergestellt wird, die Tests werden durchgeführt auf eine saubere Umwelt ohne jede verbleibende Artefakte Contam­Inating das Ergebnis. Die Verbindung mit dem Analytics-Server wird in der ConnectToServer-Methode, die mithilfe einer Instanz von Microsoft.AnalysisServices.Server ausgeführt. Ein Aufruf von Process-(< Verbindungszeichenfolge >) mit der Komponententest-Servernamen übergeben stellt die Verbindung her (siehe Listing 2 im Codedownload). Wenn die Verbindung erfolgreich eingerichtet ist, wird die Unit-Test-Version von der Cubedatenbank entfernt, wenn es bereits vorhanden ist. Diese Entfernung erfolgt mit der DropDatabase-Methode, die die angeschlossenen Server-Instanz und den Namen der Komponententest Datenbank (TargetServerName) fallen übergeben wird. DropDatabase wird sichergestellt, dass die Server-Instanz verbunden ist, sucht die Microsoft.Analysis­Services.Database mit dem Komponententest-Datenbanknamen übergeben und, falls die Datenbank vorhanden ist (die Datenbankinstanz ist nicht null), die Datenbank wird gelöscht (finden Sie unter Listing 3 im Codedownload).

Der nächste Schritt ist die ursprünglichen Cube-XMLA-Definition und die Unit-Test-Version zu generieren. Die Unit-Test-Version enthält die gleichen Abmessungen, Dimensionshierarchien, Maßnahmen, Partitionen, Rollen usw. als den original-Cube. Der Unterschied ist, dass es in einer neuen Datenbank auf einen anderen Speicherort für die Quelldaten erzeugt wird. Die AddCubeToDatabase-Methode erstellt den Testcube (siehe Listing 4 im Codedownload). AddCubeToDatabase liest die XMLA-Definition aus dem Dateisystem der Namenskonvention erwähnt. Der XMLA-Dateiname wird auf eine Instanz der XmlTextReader-Bauweise übergeben. Die XMLA wird gelesen mithilfe der Microsoft.AnalysisServices.Utils.Deserialize-Methode, die XmlTextReader und eine neu erstellte Instanz von Microsoft.AnalysisServices.Database übergeben wird. Die Datenbank-Objekt-Instanz enthält jetzt die komplette Definition des Würfels, aber diese Definition hat noch den original-Cube Datenbank Name und der Datenquelle. Auf der Unit-Test-Datenbank einfach beinhaltet, setzen die Eigenschaften Name und ID der "Datenbank Komponententest Datenbanknamen" (Zieldatenbankname) Parameter. Diese Datenbank kann dann mit der Instanz von dem Komponententest-Analytics-Server hinzugefügt werden, durch Server.Databases.Add (< Unit-Test-Datenbank >) gefolgt von einer Database.Update-Methode aufrufen.

Nachdem die Datenbank erstellt wurde, müssen Sie den Cube-Datenquelle die externe Komponententest-Datenerhebung zu aktualisieren. Die Datenbankinstanz hat eine Liste der DataSource-Instanzen (in der Regel nur eine Datenquelle ist verknüpft mit einem Würfel) und die Komponententest-Verbindungszeichenfolge wird verwendet, um die Verbindungszeichenfolge, die die XMLA-Definition enthaltenen ersetzen. Nachdem die Verbindungszeichenfolge ersetzt wird, aktualisiert sie ein Aufruf der DataSource.Update-Methode innerhalb der SSAS-Server. Zu diesem Zeitpunkt die Anpassung der XMLA-Definition abgeschlossen ist und die restlichen Stücke des Cubes (DataSourceView, Dimension und Cube) aktualisiert und verarbeitet werden.

Nach der Aufruf von AddCubeToDatabase abgeschlossen ist, wurde die Unit-Test-Version des Würfels innerhalb des angegebenen Servers mithilfe der ausgewählten Unit-Test-Datenbank erstellt. Es weist auf einen benutzerdefinierten Satz von Quelldaten. Obwohl der Cube erstellt wurde, ist es noch leer. Um die Dimensionen mit den Quelldaten zu füllen, müssen die Dimensionen verarbeitet werden. Die ProcessDimensions-Methode aufgerufen und die Datenbank-Instanz übergeben. Alle Dimensionen innerhalb der Datenbank werden mithilfe der Dimension.Process(ProcessType.ProcessFull)-Methode verarbeitet. Sobald die Dimensionen erfolgreich verarbeitet wurden, werden die Würfel in der Unit-Test-Datenbank mithilfe der ProcessCube-Methode verarbeitet. Wie ProcessDimensions, ProcessCube nimmt die Datenbankinstanz, durchläuft alle Cubes in der Datenbank und ruft Cube.Process(ProcessType.ProcessFull) (siehe Listing 5 im Codedownload). An dieser Stelle wurde der Komponententest-Cube erstellt und mit der gezielten Testdaten gefüllt. Der nächste Schritt ist zum Ausführen von Tests dagegen um sicherzustellen, dass der Cube sich wie erwartet verhält.

Überprüfen den Cube

Obwohl die Lösung für die Validierung für den Cube ausgerichtet wird, kann anderen Unit-testing-Frameworks sowie das verwendete Entwurfsmuster zuweisen. Das Muster beschäftigt testet mit Vorlage-Überprüfung. Einfach ausgedrückt: Wenn der Test ausgeführt wird, wird eine Datenstruktur mit den Ergebnissen erstellt und überprüft mit einer zuvor gespeicherten Version der Datenstruktur, die als richtig erachtet wurde. Denn es schwer eine binäre Datenstruktur zu überprüfen ist, wird eine HTML-Darstellung der Struktur der Einheit-Tester vorgestellt. Der Tester die HTML-Darstellung verwendet, um die ersten Testergebnisse des Komponententests (um sicherzustellen, dass die Ergebnisse übereinstimmen, was erwartet wird) zu überprüfen und zu prüfen, was einen Unit-Test während der nachfolgenden Ausführungen fehlschlagen verursacht. In einem Ausfall der HTML-Code zeigt die ursprüngliche Datenstruktur als sowie welches Stück der Daten Struktur Fehler bei der Überprüfung und warum. Dies ist wichtig, zu helfen, das Problem zu debuggen.

Der beste Weg die meisten Szenarios zu testen ist die "Black-Box"-Testverfahren verwenden. Ein Black-Box-Test übergibt Eingabe und Ausgabe überprüft. Da die Ausgabe für einen Cube ein Abfrageergebnis ist, ist die Eingabe der Abfrage. Einen Cube Abfragen verwenden Sie MDX-Anweisungen. Nachdem der Würfel die MDX-Abfrage interpretiert, gibt es ein Ergebnis. Das Ergebnis ist in Form von Zeilen und Spalten, die eine Darstellung der Dimensionen, die für Sie die MDX-Abfrage ausführen ausgewählt sind. Das Ergebnis der MDX-Abfrage kann sehr aufwendig sein, da die Abfrage viele Dimensionen, die in einer Vielzahl von Zeilen und Spalten in der Ausgabe umfassen kann. Die Datenstruktur gewählt, die Cubedaten ein Wörterbuch von CubeRow-Instanzen sortiert nach den Namen der Cube-Zeile ist zu halten. Die CubeRow-Klasse enthält zwei alternative Datenstrukturen — verwendet wird hängt von der Situation. Eine Datenstruktur ist ein Wörterbuch von CubeTuple-Instanzen sortiert nach den Namen der Spalte Cube. Die CubeTuple ist einfach ein Objekt, das den Cube Spaltenname und Wert der angegebenen Spalte enthält. Das Wörterbuch der CubeTuble-Objekte wird verwendet, wenn die angegebenen Cube-Spalte einen Wert enthält. Die zweite Datenstruktur ist ein anderes Wörterbuch, eine CubeRow-Instanz einen Zeilennamen zuordnen. Da eine MDX-Abfrage viele Ebenen der Zeile Dimensionen aufweisen kann, enthält CubeRow eigenes Wörterbuch mit Zeilenname und CubeRow Instanzen.

Nicht nur sind die Ergebnisse des Würfels in ein Dictionary < String, CubeRow > gespeichert Instanz, die Ergebnisse werden auch in einer HTML-Zeichenfolge gespeichert. Die HTML-Zeichenfolge ermöglicht den Tester eine visuelle Darstellung der Cube-Ergebnisse haben. Die HTML-Tabelle enthält mehrere Ebenen von Spalte und Zeile Spaltenüberschriften und die HTML-Tabellenzellen enthalten die MDX-Werte. Abbildung 2 zeigt den Aufbau der HTML-Darstellung des eine MDX-Abfrage-Ergebnis.

Abbildung 2 das Layout der HTML-Darstellung des eine MDX-Abfrage-Ergebnis

		Spalte Dimension Beschriftung 1 (Wert 1)	Spalte Dimension Beschriftung 1 (Wert 1)	Spalte Dimension Beschriftung 1 (Wert 2)	Spalte Dimension Beschriftung 1 (Wert 2)
		Spalte Dimension Beschriftung 2 (Wert 1)	Spalte Dimension Beschriftung 2 (Wert 2)	Spalte Dimension Beschriftung 2 (Wert 1)	Spalte Dimension Beschriftung 2 (Wert 2)
Zeilendimension Beschriftung 1 (Wert 1)	Zeilendimension Beschriftung 2 (Wert 1)	MDX Ergebniswert	MDX Ergebniswert	MDX Ergebniswert	MDX Ergebniswert
Zeilendimension Beschriftung 1 (Wert 1)	Zeilendimension Beschriftung 2 (Wert 2)	MDX Ergebniswert	MDX Ergebniswert	MDX Ergebniswert	MDX Ergebniswert
Zeilendimension Beschriftung 1 (Wert 2)	Zeilendimension Beschriftung 2 (Wert 1)	MDX Ergebniswert	MDX Ergebniswert	MDX Ergebniswert	MDX Ergebniswert
Zeilendimension Beschriftung 1 (Wert 2)	Zeilendimension Beschriftung 2 (Wert 2)	MDX Ergebniswert	MDX Ergebniswert	MDX Ergebniswert	MDX Ergebniswert

BaseMDXTest enthält den Code zum Ausführen einer MDX-Abfrage und die MDX-Ergebnis-Datenstruktur sowie die Vertreter-XML. BaseMDXTest verwendet Microsoft.Analysis­Services.AdomdClient.dll, gefunden in der SQL Server -SDK-Assemblys, um eine Verbindung zu den SSAS-Cube und die MDX-Abfragen. BuildTemplate ist die Methode, die die MDX-Abfrage ausgeführt wird und baut der MDX Wörterbuch sowie die HTML-Darstellung. Zunächst wird eine Verbindung zum Cube hergestellt. Um festzulegen, und eine Verbindung zu öffnen, wird die Verbindungszeichenfolge in eine Instanz von MicrosoftAnalysisServices.AdomdClient.AdomdConnection übergeben. Die Open-Methode wird auf die neu erstellte Verbindung-Instanz aufgerufen und die Connection-Instanz wird an den Aufrufer zurückgegeben. Sobald eine Verbindung hergestellt wird, eine Instanz von der MicrosoftAnalysis­Services.AdomdClient.AdomdCommand-Methode wird hergestellt und der MDX-Abfrage-String und des AdomdConnection-Instanz übergeben wird. Ein Aufruf der AdomdCommand.ExecuteCellSet-Methode führt die MDX-Abfrage gegen die Unit-Test-Version des Cubes und gibt eine MicrosoftAnalysisServices.AdomdClient.CellSet-Instanz (siehe Listing 6 im Codedownload).

Nachdem die CellSet-Instanz abgerufen wird, wird eine Überprüfung durchgeführt, um sicherzustellen, dass die Ergebnismenge zwei Achsen hat. Achse 0 enthält die Spalten und Achse 1 enthält die Zeilen. Jede Achse enthält eine Auflistung von Positionierung von Objekten. Eine Position repräsentiert ein Tupel auf der angegebenen Achse und enthält ein oder mehrere Mitgliedsobjekte. Ein Mitglied stellt die Spalte oder Zeile Header für die angegebene Position (siehe Listing 7 im Codedownload).

Als nächstes wird die Anzahl der Zeilen und Spalten, die von der MDX-Abfrage zurückgegebenen berechnet. Dies geschieht, indem man die Anzahl der Zeilen (die Anzahl der Positionierung von Objekten auf Achse 1) plus die Anzahl der Spaltendimensionen (CellSet.Axes[0].Positionen [0].Members.Count). Die Anzahl der Spalten ist zu den Zeilen hinzugefügt, weil wenn die MDX-Ergebnisse als zweidimensionale Tabelle dargestellt werden, die Spalten in die Menge der Zeilen enthalten sind. Ebenso die Anzahl der Spalten wird berechnet, indem man die Anzahl der Positionierung von Objekten auf Achse 0 plus die Anzahl der Zeile Dimensionen (siehe Codebeispiel 8 im Codedownload).

Angesichts der Zahl von Zeilen und Spalten, können die Wörterbuch von CubeRow-Objekten sowie die HTML-Darstellung der MDX-Ausgabe generiert werden. Codebeispiel 9 im Code Download enthält den Code für durchlaufen die MDX-Ergebnismenge, erstellen den HTML-Code und speichern die Ergebnisse im CubeRow Wörterbuch. Zunächst ist die Anzahl der Zeilen durchgeschleift. Wenn die Nummer der Zeile größer als die Anzahl der Spaltendimensionen ist, ist dann es bekannt, dass eine neue Zeile mit MDX-Ergebnisse verfügbar ist. Mit anderen Worten, wenn die Zeilen von Spaltenköpfen übergeben wurden, ist die MDX-Daten verfügbar. An dieser Stelle entsteht ein neues CubeRow-Objekt.

Der nächste Schritt ist es, jede Spalte in der Zeile durchlaufen. Wenn die Nummer der aktuellen Zeile die Anzahl der Spaltendimensionen unterschreitet, ist die aktuelle Zeile tatsächlich eine Zeile mit den Spaltenüberschriften. Für das Wörterbuch sind die Header-Beschriftungen für jede Spalte Ort, getrennt durch einen Doppelpunkt verkettet. Dies bedeutet, dass wenn ein Header aus mehreren Dimensionen besteht, jede Spalte mit der angegebenen Dimension in absteigender Reihenfolge der Auflösung verkettet werden. Die HTML-Generierung für einen Spaltenheader ist einfacher. Die Dimension-Beschriftung ist einfach von der HTML-Table-Header-Tags (< th >< /th >) umgeben. Für jeden Fall die aktuelle Dimension-Beschriftung wird abgerufen, indem man den Header Achse (CellSet.Axis[0]) und den Zugriff auf die Spaltenposition (aktuelle Spalte Count-die aktuelle Zeilenanzahl Dimension) und dem aktuellen Element innerhalb dieser Position (aktuelle Zeilenanzahl).

Wenn die Nummer der aktuellen Zeile größer ist werden die Anzahl der Spaltendimensionen, dann die Spaltenüberschriften nicht mehr verarbeitet. Legen Sie stattdessen das MDX-Ergebnis-Zeile, die Tupel, die nächste in der Linie für Verarbeitung sind. Ähnlich wie Spalten, die Kopfzeilen, MDX-Resultsetzeilen Header haben auch. Wenn die Spaltennummer verarbeiteten kleiner als die Anzahl der Dimensionen der Zeile ist, wird dann ein Zeilenkopf verarbeitet. Für jede Zeilenheader, ein neues Wörterbuch < String, CubeRow > erstellt, in das aktuelle Wörterbuch aufgenommen und als das aktuelle MDX-Ergebnis Wörterbuch festgelegt. Das bedeutet, dass für jede Zeilenheader gibt es ein Wörterbuch der Zeilen, mehr granulierte MDX-Ergebnis-Daten enthält.

Extrahieren die Zeile Header Beschriftung ähnelt dem Extrahieren der Spaltenbezeichnung Header. Die Zeile-Beschriftung wird abgerufen aus dem Member-Objekt an der aktuellen Spaltenposition von der Position in der aktuellen Zeile aus CellSet.Axis[1]. Die Zeile-Beschriftung ist der Schlüssel für das Wörterbuch der CubeRows und der aktuellen CubeRow-Wörterbuch die extrahierten Zeile Beschriftung vorhanden, ist das CubeRow-Objekt zum Wörterbuch sortiert nach der Zeile Beschriftung hinzugefügt. Wenn die Zeile Beschriftung im aktuellen CubeRow-Wörterbuch vorhanden ist, wird das CubeRow-Objekt abgerufen und als CurrentCubeRow festgelegt.

Nach der Zeile Beschriftung Mitglieder erschöpft (das heißt, die aktuelle Spaltenanzahl ist größer als die Anzahl der Zeile Dimensionen) und die Spalte-Kopfzeilen haben durchlaufen wurde (d. h. die aktuelle Zeilenanzahl ist größer als die Anzahl der Spaltendimensionen), es ist Zeit, MDX-Zellwerte mit dem aktuellen CubeRow-Objekt hinzufügen. Jede Kombination aus einem Spaltenheader und Spaltenwert gilt eine CubeTuple Instanz bilden. Jede CubeRow enthält ein Wörterbuch von CubeTuple-Objekten, die durch die Überschrift der Spalte eingegeben. Die Spaltenüberschrift wird aus einem Array von Spaltenköpfen zuvor konstruierte abgerufen (erinnern ein Spaltenheader ist ein Doppelpunkt -­Trennzeichen getrennte Zeichenfolge von alle Spaltenbezeichnungen verkettet). Der Index des Spaltenkopfes ist die aktuelle Spaltenanzahl minus der Anzahl der Dimensionen der Zeile (Anzahl der Ergebnisspalte beinhaltet die Zeile-Abmessungen). Der aktuelle MDX CellSet-Wert wird abgerufen, indem den Zugriff auf die entsprechenden zweidimensionalen (Spalte, Zeile) zeigen. Dies basiert auf der aktuellen Spaltenanzahl (minus der Anzahl der Zeile Dimensionen) und die aktuelle Zeilenanzahl (minus der Anzahl der Spaltendimensionen). Dieser Wert wird auf das CubeRow-Objekt mithilfe der AddTuple-Methode auf, und übergeben sie die Spaltenüberschrift und die Spaltenwert hinzugefügt. Zur gleichen Zeit wird die HTML-Darstellung aktualisiert, indem der MDX-Zelle-Wert zwischen HTML Tabelle Dimension (< td >< / td >) Token. Finden Sie unter Abbildung 3 für eine grafische Darstellung des Wörterbuchs < String, CubeRow >.

Sowohl das Wörterbuch als auch die HTML-Darstellung der Vorlage werden beibehalten, um einen vorher definierten Speicherort mithilfe der BaseMDXTest.PersistTemplate-Methode. Da die Vorlage manuell vom Entwickler Komponententest überprüft werden muss, ist die Prüfung als gescheitert, weshalb die BaseMDXTest.TestMDXQuery-Methode für den Erfolg false zurückgibt.

Abbildung 3 grafische Darstellung des CubeRow Dictionary

Nachdem die Vorlage erstellt wurde, werden die nachfolgende Ausführungen des gleichen Tests anhand der zuvor gespeicherten Vorlage validiert. Wenn die TestMDXQuery-Methode aufgerufen wird, wird zunächst geprüft, ob ein Test mit dem angegebenen Namen vorhanden ist. Wenn dies der Fall ist und eine neue Vorlage-Schöpfung ist nicht angefordert (die Vorlage neu anfordern kann auftreten, wenn die aktuelle Vorlage falsch ist), dann die Test-Ergebnis-Vorlage in den Speicher geladen wird. Die Vorlage enthält die Objektdarstellung und die HTML-Darstellung der Ergebnismenge MDX. Die BaseMDXTest.RunComparison-Methode führt die MDX-Abfrage und vergleicht das Ergebnis mit der gespeicherten Vorlage. Die MDX-Abfrage-Ergebnisse werden in der gleichen Weise durchlaufen, wie sie bei der Vorlagenerstellung waren. Der Hauptunterschied zwischen der Schaffung der Originalvorlage und der Validierung anhand der Vorlage ist, dass anstatt das Wörterbuch < String, CubeRow >, Lookups, anhand der Vorlage Wörterbuch durchgeführt werden, gucken ob die gleichen MDX-Abfrage-Ergebnisse vorhanden sind. Beim Durchlaufen der Zeilen und Spalten, wird die HTML-Tabelle genauso wie bei der Vorlagenerstellung, erstellt, außer jetzt die Zellen innerhalb der HTML-Tabelle farbig sind. Eine grüne Zelle gibt an, dass die Zelle die ursprüngliche Vorlage entspricht; einen roten Blutkörperchen zeigt ein Missverhältnis. Durch die Färbung der Zellen und präsentiert sie in einer HTML-Tabelle, hat der Einheit-Tester eine Sofortansicht von Warum den Testfall erfolgreich oder fehlgeschlagen ist. Immer wenn ein Konflikt gefunden wird, wird ein boolescher Wert (TestPass) auf False festgelegt, an den Testfall ist fehlgeschlagen.

Beim Durchlaufen der MDX-Abfrage Ergebnisse und überprüfen sie anhand der Vorlage Wörterbuch, jedes CubeTuple (ein Objekt, das die Spalte Dimension, verketteten Namen und den Wert der Spalte enthält) aus dem aktuellen CubeRow-Wörterbuch von CubeTuple-Objekten entfernt ist fand. Daher nach das gesamte MDX-Abfrage-Ergebnis übergeben wird, sollte die ursprüngliche Vorlage Wörterbuch CubeRow Objekte mit einer leeren Wörterbuch von CubeTuple-Objekten verfügen, wenn das MDX-Ergebnis ein komplettes Spiel war. Sonst hatte das neue MDX-Abfrage-Ergebnis, fehlende Daten, die in das ursprüngliche Ergebnis enthalten war. Die BaseMDXTest.CheckForExtraDataInTemplate-Methode untersucht die Vorlage Wörterbuch für verbleibende CubeTuple Objekte, rekursiv, ausführen und gibt den Wert True zurück, wenn CubeTuple Objekte bleiben. Die TestPass ist Boolean innerhalb der RunComparison-Methode auf False festgelegt, wenn zusätzliche Daten gefunden werden, und den Testfall schlägt fehl.

Nach der MDX Ergebnisse wurden vollständig durchlaufen und überprüft anhand der Vorlage Wörterbuch, eine Instanz des Würfels­ComparisonResult-Objekt wird zurückgegeben. Es ist mit der TestPass Boolean und die HTML-Tabelle zeigt das Ergebnis gebaut. Die BaseMDXTest.TestMDXQuery-Methode verwendet CubeComparisonResult, um eine HTML-Seite, die mit der ursprünglichen MDX-Abfrage Ergebnis HTML-Tabelle und die Vergleich-HTML-Tabelle zu erstellen. Der HTML-Code wird durch einen Aufruf an die BaseMDXTest.PersistTestReport-Methode, die eine Zusammenfassung TestReport.html-Webseite, die alle Testläufe mit erstellt im Dateisystem beibehalten und Hyperlinks zu ihren HTML Seiten, sowie eine Übersicht über die Anzahl von Testfällen, die erfolgreichen und fehlgeschlagenen haben.

Testen den Kauf-Cube

Verwenden beide Komponenten des Cube-Test-Frameworks — der Cube-Erstellung-Code (XMLAtoCube) und der MDX query Ergebnisschablone (BaseMDXTest) — Sie können erstellen, Unit-Test Cases, die den Cube zu überprüfen. Der Code für das Framework umfangreiche ist zwar die Testfälle erstellen einfach und unkompliziert. Liste 10 im Code Download enthält Beispiel-Unit-Tests für die Validierung des Cubes kaufen. Diese Testfälle verwenden das Microsoft-Test-Framework, aber Test-Framework integriert werden kann.

Das Unit-Test-Objekt (im Beispiel PurchaseCubeTest) erbt von BaseMDXTest. Der Standardkonstruktor des PurchaseCubeTest erstellt BaseMDXTest mit der URL den SSAS-Server befindet sich der Würfel und das Basis-Verzeichnis in dem Sie die MDX-Abfrage-Ergebnis-Vorlage und nachfolgenden Testergebnisse zu speichern.

Eine [TestInitialize]-Methode wird verwendet, um die Unit-Test-Version des Cubes kaufen zu erstellen. Es verwendet die XMLA-Definition des ursprünglichen Würfels und schafft es auf den Komponententest SSAS-Server (TargetServerName) mit einem Unit-Test-Datenbank (Zieldatenbankname). Er weist auch die Quell-Daten-URL auf den Speicherort der die Testdaten für die Dimension und Tatsache. [TestInitialize] wird nur einmal ausgeführt, für eine gegebene [TestClass], sichert den Cube nur zu Beginn des Tests erstellt wird.

Die Testfälle selbst sind ausgeführte innerhalb [TestMethod] kommentierte Methoden. Jeden Testfall ist einfach. Die MDX-Abfrage definiert ist und dann über die geerbte BaseMDXTest.TestMDXQuery-Methode, benennen den Testfall und übergeben sie die MDX-Abfrage ausgeführt. TestMDXQuery gibt true zurück, wenn der Test bestanden oder False zurück, wenn dies nicht der Fall, und eine Assert.IsTrue-Methode verwendet wird, um Erfolg oder Fehlschlag des Komponententests. Nachdem alle Tests ausgeführt wurden, das resultierende HTML-Test-Dokument geöffnet werden kann und die fehlerhafte Testfälle geprüft werden kann. Abbildung 4 enthält ein Beispiel HTML-Ausgabe einer der Tests.

Abbildung 4 die HTML-Ausgabe eines Beispiel-Tests

Richtig getesteten Code

Obwohl es nicht einfach ist, kann sogar ein OLAP-Cube Gerät mit c# getestet werden. Die Aufnahme der Microsoft.AnalysisServices.dll und Microsoft.AnalysisServicesAdomdClient.dll Dateien innerhalb der SQL Server -Assemblies bietet Ihnen die APIs für das Erstellen und Abfragen von SSAS Würfel. Die Architektur dargestellt können Sie einen umfangreichen Satz von Unit-Tests hinzufügen, die Ausgabe in einem lesbaren Format erzeugt, damit Testfall Fehler schnell identifiziert werden können. Die Methode der Testfall Validierung durch Vorlage kann auf andere Komponententest-Architekturen angewendet werden, wo Ausgabe Validierung ist nicht einfach. Beispiele für diese reichen von Anwendungen, die auf herkömmlichen relationalen Datenbank-Persistenz zu verlassen, wo die Vorlage die Daten enthält, voraussichtlich in der Datenbank gespeichert werden, nachdem die Anwendung ausführt, auf UI-Anwendungen, die den Zustand der Benutzeroberfläche in eine Datenstruktur speichern und anzeigen die Benutzeroberfläche in einem HTML-Formular.

Ich bin nicht ganz sicher, wenn die Freiheiten einer Nation auf die Rechte der Thomas Jefferson oder unsere Gründerväter ordnungsgemäß geprüft vergleichen würde Code, aber ich bin ziemlich sicher, dass Ihre Benutzer und Aufsichtsbehörden würde mich freuen zu wissen, dass die Anwendung korrekt Nieren gebracht worden ist.

Mark Nadelson ist ein professioneller Software-Entwickler mit 22 Jahre Erfahrung in den Branchen Telekommunikation, Internet und Finanzen. Im Laufe seiner Karriere hat er eine Reihe von Programmiersprachen einschließlich Montage, C, C++, Java und c# verwendet. Nadelson ist auch der Autor zweier Bücher und zahlreicher Fachartikel.

Unser Dank gilt den folgenden technischen Experten für die Durchsicht dieses Artikels: David Neigler (SAC Capital Advisors LP) und Joe Sampino(SAC Capital Advisors LP)
David Neigler ist ein Entwicklungsmanager in der Finanzdienstleistungsbranche arbeiten bei SAC Capital Advisors LP.  Sein Schwerpunkt ist die Entwicklung von Systemen, die große Datenmengen Probleme der finanziellen Unternehmen, die große Mengen des Handels zu lösen.

Joe Sampino arbeitet bei SAC Capital Advisors LP, Entwicklung von Enterprise-Business-Intelligence-Plattformen für große Banken und Wertpapierfirmen.  Er erstellt und verwaltet von Datawarehouses, SQL Server Analysis Services-Cubes und Analyse/reporting Systemen für interne, externe, regulatorische und Compliance muss. "