Wieder einmal das Repository… oder auch Repository driven BI / everything in SQL Server FAQ…

Auf Repositorys und Meta Daten komme ich ja immer wieder gerne zu sprechen. :^)

Zuletzt hatte ich die Gelegenheit meine Ideen von Repository getriebenen Architekturen einer Community in Nürnberg, in der PASS Regionalgruppe Franken, vorzustellen. Vielen Dank an den Klaus Oberdalhoff für die Organisation dieses Events und vielen Dank an die Raumsponsoren! Kommt gar nicht so häufig vor, dass ich bei einem RG Treffen vor mehr als 40 Teilnehmern spreche. Kam fast ein wenig Konferenzstimmung auf. Des Weiteren war die Session schön interaktiv und es wurden einige sehr gute Fragen gestellt.

Ein paar dieser Fragen und natürlich die Antworten hier nun für den Online Teil der Community. Fragen folgen in Fett.

Ein wesentlicher Teil der Fragen zielte darauf ab, was denn nun so ein Repository ausmache bzw. ob das nichts anderes ist als eine Konfiguration?

Zwar bauen meine Ansätze immer auf einem Repository auf, welches die beschreibenden Daten für die eigentliche Zielplattform hält, aber es handelt sich dabei nicht nur um eine andere Organisationsform einer Konfigurationsdatei für eine existierende Technologieplattform!

Ich vergleiche das gerne mit einem Navigationsgerät. Technologie ist klar, das gute Stück kann sich super orientieren und mit ein wenig Kartenzauber und Routenfindung äußerst praktisch. Nur wie verwenden wir es? Wir geben in der Regel die Route nicht im Detail vor, also jede Straße, jede Kreuzung usw. Wir kommunizieren über eine Metaebene mit der eigentlichen Logik, welche eine für uns plausible Information abfragt: Eine Zieladresse. Die restliche Magie findet auf sehr wahrscheinlich mehreren Ebenen darunter statt. Der letzte Level kennt den aktuellen Standort und kommuniziert wiederum mit dem Routenplaner eine Etage über ihm, usw. Also ist das Adressbuch eine Metaebene (-> Repository) und auch das Kartenmaterial (noch eine Ebene).

Daher ist ein wesentlicher Aspekt des Ansatz, dass es mir NICHT allein um das an-codieren der SQL Server Funktionen geht, sei es nun SMO oder AMO. Die eigentliche Magie spielt sich meiner Meinung nach in den Ebenen darüber ab. Denn in diesen Ebenen werden erweiterte Funktionalitäten hinzugefügt. Ein bei mir sehr beliebtes Muster (ich sage mal absichtlich nicht Pattern, das führt nur zu Missverständnissen) ist das Hinzufügen der Möglichkeit Objekte zu Gruppen zusammenzufassen, was in der Regel auf der Zielplattform nicht möglich bzw. nicht “Solution” übergreifend anwendbar ist.

Beispiele für Ziel- bzw. Technologieplattformen können sein: SQL Server Analysis Services (SSAS), SQL Server Integration Services (SSIS), SQL Server Replikation, Trigger, Service Broker, Extended Events oder auch SharePoint.

Und Beispiele für Gruppen können damit sein:

- Attribute in SSAS Projekten, aber über mehrere Dimension und auch Solutions hinweg.
- Steuerung von Triggern bzw. asynchronen Triggern, welche auch noch mit Service Broker Diensten verbunden sind.
- Abonnenten innerhalb einer Replikationsstruktur können sehr gut zu Gruppen zusammengefasst werden, um diese mittels eines Eintrags im Repository an einen anderen Verteiler “zu hängen”. Glaubt mir, sowas macht in schön großen Replikationsstrukturen (>200 Abonnenten) und 1-2 mehr Servern richtig Spaß!
- Listen und was alles damit zusammenhängt (hehe…) innerhalb von SharePoint. Damit lassen sich auch schöne Projekte realisieren, aber sprengt gerade den Rahmen hier.

Wie steuere ich das dann alles von oben? In der Regel durch eine domänenspezifische Sprache, wobei ich gerne noch weiter gehen möchte und das einfach mal projektspezifische Sprache (PSL) nenne. Also hier drin steckt meiner Meinung nach die eigentliche Magie (ich mag das Wort in dem Zusammenhang) in den Projekten.

Wie komme ich auf sowas? Schon sehr früh, noch zu Zeiten als ich mit Clipper (und es war Sommer 87…*flöt*) und MUMPS unterwegs war, habe ich mir Codegeneratoren entwickelt, welche zum Beispiel das damalige Clipper (vor dem CA Zeug) um die Möglichkeit von eigenen Klassen erweitert haben. Sowas prägt fürs ganze IT-Leben! by the way, Dank an den Jan Welker für den Tipp mit T4! Äußerst spannend!  

Wie speichere ich das Repository? Schwieriges Thema… gerne als einfache relationale Struktur. Dann kann mittels SQL DML Befehlen direkt darauf eingewirkt werden und auch evtl. notwendige GUIs brauchen “nur” SQL DML beherrschen. Damit auch mal was passiert in den Strukturen kommen da dann ausnahmsweise Trigger dazu, welche auf Veränderungen reagieren. Die Daten im Repository bildet dann die Strukturen auf der jeweiligen Zielplattform ab.

So, damit sind die wohl häufigsten Fragen persistiert worden. Bei weiteren Fragen einfach auf mich zukommen!

Für Alle, die die Session Repository Driven Business Intelligence aka The Developer Side of MS BI bisher nicht gesehen haben, die gibt es als englischen Cast auch noch auf den SQLBits Seiten!