ORAYLIS veröffentlicht das Projekt ORAYLIS BI.Quality auf Codeplex.
"Durch die Veröffentlichung auf Microsoft's Open Source Projekt Plattform möchten wir die große Microsoft BI Entwickler-Gemeinde erreichen," sagt ORAYLIS Geschäftsführer Thomas Strehlow. "Wir erhoffen uns viele Anregungen und tatkräftige Unterstützung bei der Weiterentwicklung." ORAYLIS BI.Quality ist eines von 4 eigens erstellten Produkten, die ORAYLIS für die Realisierung ihrer BI Projekte einsetzt.
ORAYLIS BI.Quality ist ein Werkzeug zur Sicherstellung der Qualität in einem BI Projekt. Während der Entwicklungs- und Stabiliserungsphase sorgt es für eine kontinuierliche Überwachung der ETL-Prozesse. Gerade in einer agilen Projektumgebung ist diese Methodik besonders hilfreich. Aber auch während der Betriebsphase eines BI-Systems kann es eingesetzt werden, um z.B. Störungen in den Datenquellen zu erkennen, bevor sie der Kunde meldet.
Mit BI.Quality lassen sich Testfälle definieren, die anschließend automatisiert durchgeführt werden können. Dabei lassen sich unterschiedliche Test-Szenarien definieren, z.B. Vergleichstest, Datenverfügbarkeitstests, Strukturtests oder Unknown Meber Tests.
Im Folgenden werden die unterstützten Testprozesse aufgelistet:
Strukturtests Mit Strukturtests kann geprüft werden, ob eine Tabelle noch der Form entspricht, wie sie ursprünglich definiert war. Hierzu gehören z.B. Mengen und Namen der Spalten, Datentypen, Keys, Spaltenreihenfolgen oder ob Null zulässig ist.
Datenverfügbarkeit Diese Tests prüfen, ob in den Tabellen die entsprechenden Daten vorhanden sind. So ist z.B. genau bekannt, dass z.B. in der DimSzenario 10 Rows enthalten sein müssen, oder dass eine definierte Faktentabelle Daten vom Vormonat enthalten muss.
FK Tests Fakten referenzieren mittels ForeignKeys (FK) Dimensionen. Diese FKs werden aus Performancegründen oft nicht eingeschaltet. Gerade hier gibt es zur Entwicklung sehr oft Probleme. Es wird empfohlen je FK einer Faktentabelle zu prüfen, ob jedes der Key-Felder eine Entsprechung in der Zieltabelle existiert.
Unknown Member Test Nahezu jede Dimesionstabelle verfügt über eine unknown Member Row. Je nach Logik soll diese selten oder nie verwendet werden. Es empfiehlt sich je FK Spalte eine Anteilsmessung, d.h. es wird die Menge der Unknown Member Rows ins Verhältnis zu den Gesamtrows gemessen. Wenn der Wert z.B. 1% übersteigt wird ein Fehler gemeldet.
Constraint Tests Jede Datenbank definiert ihre individuelle Logik, der die Daten entsprechen müssen. Diese Regeln können nur selten vollständig durch die Datenbank sichergestellt werden. Vielmehr das Quellsystem muss diese Regeln sicherstellen. Diese Regeln sind oft fundamental und müssen eingehalten werden. Das soll an einem kurzen Beispiel erläutert werden. Ein Quellsystem liefert z.B. Verträge, die im DWH eine Dimension und diverse Fakten speisen müssen. Nach Jeder Vertragsänderung wird im Quellsystem eine neue Row angelegt mit einer gültig von bzw. gültig bis Spalte. Für die ETL Logik ist es fundamental wichtig, dass die Zeitreihen je Vertrag lückenlos und ohne Überlappung vorliegen. Genau solche Regeln können mittels Constraint Tests sichergestellt werden.
Vergleichstests Die Daten laufen innerhalb einer BI Lösung von der Stage in ein bereinigtes Datenbankmodell und anschließend in einen Cube. Der BI Entwickler verbringt sehr viel Zeit damit genau das sicherzustellen. Vergleichstests lesen die Daten aus zwei unterschiedlichen Quellen und vergleichen die Werte. Dabei können auch Daten von relationalen Datenbanken mit Dimensionalen Datenbanken verglichen werden.
Funktionalitäten:
Automatische Query Tests gegen den SQL Server via OLEDB
Automatische Query Tests gegen Analysis Services via OLEDB
Beliebige Anzahl von Connections, die namentlich von den Queries referenziert werden
Vergleich des ResultSets gegen einen RowCount
Aufzeichnung von ganzen ResultSets, Speicherung im Filesystem und Bereitstellung für einen späteren Vergleich
Vergleich eines aktuellen ResultSets gegen ein gespeichertes
Vergleich des ResultSets auf Basis von Feldwerten (nur Zahlen) und einem Toleranzwert (Zahl)
Interne Konfigurationstests um Fehler eines Testprojektes zu erkennen
User Doku inkl. Quick Start
Sample Projekt auf Basis Adventure Works als Vorlage
Einfaches Deployment
ChangeLog mit einer Versionshistorie
Automatische Tests auf der Kommandozeile und Ausgabe eines XML Reports
Gruppierung von Testcases zu Kategorien (z.B. Integration Tests, Long running Tests, etc)
Überführung des xml Testreports in ein html Format für den automatischen Test via Kommandozeile
