Jeder, der selbst SQL- oder MDX-Statements schreibt und die Anderer lesen und verstehen möchte, wird feststellen, dass jeder einen etwas anderen Schreibstil verwendet. Da T-SQL eine flexible Gestaltung der Statements zulässt, können Schlüsselwörter, Objektnamen und Konstanten frei über die Zeilen der Statements verteilt werden.

Das gilt sowohl für SQL- und MDX-Statements im Microsoft SQL Server Management Studio als auch für Berechnungen mit MDX im Microsoft Visual Studio. Dies kann vor allem bei längeren Statements schnell unübersichtlich werden und damit viel Zeit kosten diese zu verstehen. Das betrifft auch uns selbst, wenn wir nach längerer Zeit das Statement wieder aufrufen und uns fragen, was wir damit eigentlich bewirken wollten. Ähnlich ist es bei SSIS-Paketen. Hier sind zwar die einzelnen Elemente vorgegeben, aber ihre Anordnung und ihre konkrete Funktion sind jeweils frei definierbar.

Daher können ein paar grundsätzliche Stilregeln für SQL- und MDX-Statements sowie für SSIS-Pakete für mehr Übersichtlichkeit und Lesbarkeit sorgen.

SQL

Anhand von einem Beispiel aus unserer Demo-Datenbank Chair sollen die Stilregeln für SQL-Statements erläutert werden.

Stilregeln bei der Benennung von Objekten

Die Benennung der Objekte richtet sich nach dem Objekttyp und der Herkunft der Daten. Grund-legende Namenskonventionen werden in folgender Tabelle aufgelistet:

Ziel dieser einheitlichen Benennung ist es, dass DM ETL die Quellen automatisch erkennt und die Objektnamensräume für DM ETL freigehalten werden. Die reservierten Namensräume können in der Prozedur P_BC_Help nachgelesen werden.

Stilregeln in SQL-Statements

Aus der Tabelle T_Import_Periode_manuell, die eine Spalte mit Datumswerten enthält, werden per SQL-Funktionen die verschiedensten Datumsinformationen erstellt. Das Beispiel kann leicht auf jeder beliebigen Datenbank nachvollzogen werden, in der eine Tabelle mit Datumswerten vorliegt.

Das hier gezeigte SQL-Statement funktioniert fehlerfrei, gut lesbar ist dieser Spaghetti-Code aber nicht. Was können wir besser machen?

Zum einen sollten wir pro Zeile nur einen Ausdruck (Tabellenspalte oder Bedingung) zulassen und zum anderen den Schlüsselwörtern SELECT, FROM, WHERE, GROUP BY, ORDER BY und Ähnlichen je eine eigene Zeile einräumen. Auch jedes ON mit Bedingung in einem Join gehört in eine eigene Zeile. Die Bestandteile des Statements werden durch Tabulator eingerückt:

Nun sollten wir alle Schlüsselwörter in Großbuchstaben schreiben. Funktionen können in Großbuchstaben geschrieben werden, müssen aber nicht. Man sollte lediglich konsequent bleiben – entweder alle Funktionen in Großbuchstaben oder alle klein:

Um es sich besser einzuprägen, hilft vielleicht die Eselsbrücke: blau = großschreiben (im Abfragefenster des Microsoft SQL Management Studios). Auch die CASE-WHEN-Anweisungen und die FROM-Klausel sollten strukturiert werden:

Ob man auch den Subselect strukturiert, hängt von seiner Komplexität ab. Ein einfacher Subselect kann in einer Zeile stehen, schließlich soll sich das vollständige Statement nicht über mehrere Seiten erstrecken. Bei einem komplexeren Subselect, wie in unserem Beispiel, empfiehlt es sich, zumindest den Schlüsselwörtern SELECT, FROM und WHERE und den Ausdrücken je eine separate Zeile zu spendieren.

Wenn am Schluss nicht nur für alle Spalten, sondern auch für alle verwendeten Tabellen eindeutige und sprechende Alias-Namen vergeben und Kommentarzeilen für nicht auf einen Blick ersichtliche Statement-Details eingefügt werden, kann man auch nach längerer Zeit verstehen, was mit diesem SQL-Statement bezweckt werden soll.

Tabellenaliasse werden auch dann vergeben, wenn nur eine Quelltabelle verwendet wird. Man er-leichtert sich die Arbeit zum einen, wenn später doch noch weitere Tabellen hinzugefügt werden müssen und zum anderen bei der Auswahl der Tabellenspalten mittels IntelliSense in Microsoft SQL Management Studio. Bei Eingabe <Tabellenalias.> erscheinen in alphabetischer Sortierung alle Spaltennamen dieser Tabelle zur Auswahl und man erspart sich das Eintippen des gesamten Spaltennamens. Damit es tatsächlich eine Zeitersparnis wird, sind die Aliasnamen kurz, aber sprechend zu wählen. Von der Verwendung einzelner Buchstaben (a, b, c, …) wird abgeraten. Bei großen Scripts verliert man schnell den Überblick, welche Tabellen mit a und welche mit b bezeichnet wurden.

Wenn ein Statement später Verwendung in DeltaMaster Modeler findet, sollten bei den Spaltenaliassen modeler-konforme Aliasnamen verwendet werden. Also für Key-Spalten <Spaltenname>ID und für Namens-Spalten <Spaltenname>BEZ verwenden, dann werden diese Spalten automatisch in DeltaMaster Modeler erkannt, was die Arbeit wieder ein kleines Stück vereinfacht.

Kommentare in SQL-Statements

Kommentare, die sich auf das gesamte SQL-Statement beziehen, sollten oberhalb des eigentlichen Statements dessen Zweck und die Änderungshistorie mit Datum und Namenskürzel enthalten.
Sollen einzelne Zeilen des Statements zur besseren Verständlichkeit kommentiert werden, so ist dies oberhalb der Zeile oder auch rechts neben der Zeile möglich.

Die WHERE-Bedingung ist zu kommentieren, da hierdurch Einschränkungen vorgenommen wer-den, die in der Regel einer Erklärung bedürfen.

Das ist immer noch das gleiche Statement wie in unserem Spaghetticode in Abschnitt 1.1, aber durch die konsequente Strukturierung wesentlich besser lesbar. Existieren in einem SQL-Statement sowohl Dimensionsspalten, Kennzahlen als auch Info-Spalten, ist es empfehlenswert, diese auch entsprechend zu sortieren und mit einem entsprechenden Kommentar zu versehen, wie im nach-folgenden Beispiel aus unserer Datenbank Chair gezeigt:

Zusammenfassung der Stilregeln und Hinweise für Kommentare in SQL-Statements

• Stilregeln
  • Statement-Bestandteile durch Tab einrücken
  • Ein Ausdruck (Tabellenspalte, Bedingung, Schlüsselwort) pro Zeile
  • Schlüsselwörter und Funktionen einheitlich groß schreiben
  • Joins und ggf. Subselects ebenfalls in Zeilen zerlegen, Reihenfolge und Einrückung der Joins sinnvoll wählen gemäß sinnvoller Semantik
  • Tabellenaliasse grundsätzlich auch bei nur einer Quelltabelle verwenden
  • Sprechende Spaltenaliasse verwenden
  • Für Spaltenaliasse DeltaMaster Modeler-konforme Bezeichnungen verwenden (xxxID, xxxBEZ,…)
  • Spaltenalias = Level-Name + Standard-Modeler-Suffix
  • Spalten in Faktentabellen nach Dimensionsspalten, Kennzahlen, Info-Spalten sortieren und entsprechend kommentieren
• Kommentare
  • Oberhalb des Statements Einsatzzweck, Änderungshistorie mit Datum und Personenkürzel notieren
  • Auf einen Blick ersichtliche Statement-Details jeweils oberhalb oder rechts der betroffenen Zeile erklären
  • WHERE-Bedingung kommentieren

MDX

Stilregeln in MDX-Statements

Für MDX-Statements gilt prinzipiell das gleiche wie für SQL-Statements. Auch die Zeilen eines MDX-Statements sollten sinnvoll aufgeteilt, alle Schlüsselwörter in Großbuchstaben geschrieben und mit Einrückungen und Kommentaren versehen werden.

Da es in MDX keine Aufteilung in Tabellen/Views wie im T-SQL gibt, sollte jede Bedingung, jede Anweisung und jeder Ausdruck in einer Zeile stehen. Stellt man zusammengehörige Klammerpaare in jeweils einer Zeile untereinander und rückt die Elemente innerhalb der Klammer ein, wird auf einen Blick deutlich, welche Elemente zu einer Funktion gehören.

Beispiel ohne Struktur:

Die einzelnen Elemente des IIF-Befehls (Bedingung, dann, sonst) sind in der obigen Darstellung nur schwer voneinander zu trennen, was das gesamte Statement schwer lesbar macht. Besser ist eine Trennung in einzelne Zeilen und das Einrücken der Elemente:

Kommentare in MDX-Statements

Jetzt ist das Statement leichter lesbar, nicht zuletzt aufgrund der konsequent untereinanderstehenden Klammern und der eingefügten Kommentare.

Nachfolgender SCOPE ist dank der Strukturierung und Kommentierung sehr schnell lesbar, obwohl hier eine nicht ganz unkomplizierte Berechnung ausgeführt wird.

Zusammenfassung der Stilregeln und Hinweise für Kommentare in MDX-Statements

• Stilregeln
  • Sinnvolle Aufteilung in Zeilen
  • Schlüsselwörter einheitlich groß schreiben
  • Zeilen durch Tab einrücken
  • Klammerpaare untereinander stellen
• Kommentare
  • Oberhalb des Statements Einsatzzweck, Änderungshistorie mit Datum und Personenkürzel notieren
  • Semantik kommentieren (z. B. SCOPE-Umfang)
  • Sinnvolle Reihenfolge einhalten und Bereiche durch Kommentare bzw. Linien trennen
  • Jedes SCOPE-Element in einer Zeile
  • Jede Bedingung, jede Anweisung, jeder Ausdruck in eine Zeile (z. B. IIF (Bedingung, dann, sonst))

SSIS-Pakete

Stilregeln in SSIS-Paketen

In SSIS-Paketen verläuft der Datenfluss eines Prozesses von oben nach unten. Parallele Prozesse können auch nebeneinander abgebildet werden, erst recht, wenn sie in einem gemeinsamen Prozess münden.

Beinhaltet ein Prozess mehrere Prozessschritte (Zieltabelle leeren, Quelldaten einlesen und in Zieltabelle schreiben etc.) ist es sinnvoll, diese in einem Sequenzcontainer zu bündeln. Ein Beispiel für parallele Prozesse kann das Einlesen verschiedener Quelldateien für Finanzdaten, Kundenstammdaten, Produktdaten etc. sein, die alle in die gemeinsame Aufbereitung der Daten (Transform_All) münden. Alle Objekte sollten sinnvoll und nachvollziehbar beschriftet werden. So ist im DataFlowSource der Name der Quelltabelle/Quelldatei anzugeben und im DataFlowDestination der Name der Zieltabelle/Zieldatei.

Die Description ist für jedes Objekt auszufüllen, wobei hier mindestens der Name des Objekts an-gegeben werden sollte, da die Description im ErrorLog verwendet wird. Generell sollte darauf geachtet werden, dass Umlaute und Sonderzeichen vermieden werden. Außerdem sollte man sich für eine Sprache (deutsch oder englisch) entscheiden.

Kommentare in SSIS-Paketen

Für Kommentare stehen in SSIS-Paketen Textfelder zur Verfügung über „Anmerkung hinzufügen“.

Abb. 1: Kommentare per Anmerkung hinzufügen

Auf jeden Fall sollte am Anfang des SSIS-Pakets ein Textfeld mit dem Zweck des SSIS-Pakets, dem Datum der letzten Änderung und dem entsprechenden Personenkürzel eingefügt werden.

Werden spezielle Verbindungstasks, spezielle Datenkonvertierungen, Umrechnungen, Script-Tasks oder selten eingesetzte Tools verwendet, sind diese ebenfalls zu kommentieren.

SQL-Tasks, die nicht nur den Prozeduraufruf Transform_All enthalten, sollten entweder über eine detaillierte Bezeichnung oder über eine separate Anmerkung kommentiert werden.

Im nachfolgenden Beispiel kann man aus dem eingefügten Kommentar und den Bezeichnungen der einzelnen Tasks (Ausnahme Script-Task) entnehmen, was in jedem Schritt ausgeführt wird. Der Script-Task ist separat kommentiert.

Abb. 2: Beispiel für einen Kommentar

Der Script-Task enthält selbst die entsprechenden Kommentare:

Ebenso ist auch der Datenflusstask über die Beschreibung der einzelnen Task dokumentiert:

Abb. 3: Dokumentation des Datenflusstasks

Benennungen im Datenflusstask:

• Quelle: Die Benennung sollte Hinweis auf den Inhalt geben „Stammdaten_Kunde“
• Ziel: T_IMPORT_<Quelle>
• Transformation: Hinweis auf Aktion, z.B. „Datum aus Dateinamen einlesen“

Zusammenfassung der Stilregeln und Hinweise für Kommentare in SSIS-Paketen

• Stilregeln
  • Datenfluss der Prozesse von oben nach unten modellieren
  • Einzelne Verarbeitungen ggf. sinnvoll in Sequenzcontainern logisch und optisch bündeln
  • Alle Objekte sinnvoll bezeichnen
  • Description ausfüllen, mindestens Description = Name
  • DataFlowSource ausfüllen: Name = Quelltabelle
  • DataFlowDestination ausfüllen: Name = Zieltabelle
• Kommentare
  • Textfeld für Einsatzzweck des Pakets, Änderungshistorie mit Datum und Personenkürzel einfügen
  • Textfeld für Besonderheiten bzw. bei nicht selbsterklärenden Sonderfällen einfügen
  • Spezielle Verbindungen (wenn Ausdrücke verwendet werden) kommentieren
  • SQL-Tasks kommentieren, wenn Inhalt <> exec P_Transform_All