Seit DeltaMaster ETL Version 6.2.5 ist es möglich Synonyme automatisch anlegen zu lassen. Nach Veröffentlichung der Funktion ernteten wir mehrfach fragende Blicke in Bezug auf dieses Feature. Zumeist wurde der Begriff “Synonym” in Verbindung mit Thesaurus aus der gängigen Textverarbeitungssoftware gebracht. Wie sich herausstellte, ist die SQL-Server-Funktion der Synonyme kaum bekannt. Was SQL-Server-Synonyme sind, wozu man sie einsetzen kann und wie DeltaMaster ETL dabei unterstützt, ist Bestandteil des vorliegenden Blogbeitrags. 

Synonyme – WTF?

Die Funktion der SQL-Server-Synonyme ist bereits seit langem vorhanden, mindestens seit der Version 2008R2. Die SQL-Server-Hilfe schreibt zum Zweck der Synonyme:
“Ein Synonym ist ein Datenbankobjekt, das zu folgenden Zwecken dient:

• Ein Synonym stellt einen alternativen Namen für ein anderes Datenbankobjekt bereit, das als Basisobjekt bezeichnet wird und auf einem lokalen Server oder Remoteserver gespeichert sein kann.
• Ein Synonym stellt eine Abstraktionsschicht bereit, die eine Clientanwendung vor Änderungen schützt, die am Namen oder Speicherort des Basisobjekts vorgenommen werden.”

Damit ist schon fast alles gesagt. Technisch gesehen ist es eigentlich nur ein Verweis auf ein existierendes Datenbankobjekt (ähnlich einer Verknüpfung). Synonyme werden allerdings wie ein “normales” Objekt in einem Schema angelegt und müssen daher vom Namen her über alle Objekttypen eindeutig sein. Sprich eine Tabelle kann nicht den gleichen Namen wie ein Synonym haben und umgekehrt.

Wenn man ein Synonym anlegt, muss man also lediglich den Namen des Synonyms sowie das Objekt, auf welches das Synonym zeigt, angegeben werden. Anschließend kann das Synonym genau wie das Basisobjekt selbst verwendet werden (also z.B. ein SELECT auf das Synonym ausgeführt werden, sofern es sich um eine Tabelle oder eine View handelt).

Nach Erzeugung des Synonyms ist es im Hauptordner “Synonyme” unterhalb der Datenbank zu finden:

Abbildung 1: Systemordner

In den Eigenschaften erkennt man den simplen Aufbau:

Abbildung 2: Eigenschaften eines Synonyms

Wie man in folgendem Bild sehen kann, unterscheiden sich beide Objekte in keinster Weise von der Nutzung her:

Abbildung 3: Vergleich Tabelle vs. Synonym

Wozu soll das ganze jetzt also nochmal gut sein? Schauen wir uns dazu die Definition von Microsoft noch einmal genauer an.

Zunächst wird von einem “alternativen Namen für ein anderes Datenbankobjekt” geschrieben. Genau das ist schon der trivialste Anwendungsfall. Wenn Objektnamen z.B. zu lang und unhandlich sind, kann man sich einfach ein Synonym anlegen und künftig deutlich kürzer darauf zugreifen. Dies wird in ETL unter anderem für einige der Logging-Prozeduren gemacht. Hier wird z.B. das Synonym “P_SYLSOG_DED” für die Prozedur “P_SYSLOG_DataErrorDetail” angeboten. Eine Hommage an die “Tippfaulen”.

Weiterhin wird in dem gleichen Punkt noch unterschieden zwischen “lokaler Server und Remoteserver”. Hierin verbirgt sich eine der größten Stärken der Synonyme. Synonyme funktionieren nicht nur innerhalb der gleichen Datenbank, sondern auch datenbank- und serverübergreifend. Damit kann ein ganz zentraler Pferdefuß der SQL-Entwicklung elegant umschifft werden. Nämlich die explizite Verwendung von Datenbank- und/oder Servernamen in SQL-Code. Dies fällt einem nämlich meist bei Migrationen oder dem Aufbau von DEV-Umgebungen auf die Füße. Wenn man stattdessen Synonyme verwendet, ist dort zwar immer noch der Datenbank- und/oder Servername hinterlegt, allerdings an einer zentralen Stelle. Man kann über eine kleine Routine die Verbindungen der Synonyme austauschen und der Code läuft wieder. Das ist deutlich sicherer und schneller als die explizite Verwendung von Datenbank- und/oder Servernamen im Coding. Genau deswegen werden auch seit der ETL-Version 6.2.2 die “Cross-Datenbank-Referenzen” im Bericht “SQL Code Quality Check” explizit ausgewiesen:

Abbildung 4: Prüfungen von “Cross-Datenbank-Referenzen” in ETL

DeltaMaster ETL hat dieses Konzept mittlerweile auch vollkommen “verinnerlicht” und legt zum Beispiel die Zugriffe auf die Rückschreib-Datenbank mittlerweile konsequent nur als Synonym an. Ändert man den Namen dieser Datenbank im Parameter-Bericht werden im Hintergrund alle Synonyme automatisch auf den neuen Namen umgezogen (ohne, dass der Anwender dies bemerkt). Ab der nächsten Version werden Synonyme auch als SourceTable vollständig unterstützt. Damit könnte man sich z.B. bei rechenintensiven Views die Hintertür offen lassen irgendwann auf eine materialisierte Tabelle umzustellen und zwar ohne “Create relational schema”. Weiterhin kann man auch hier deutlich eleganter datenbankübergreifend arbeiten, ohne in der Model-Datenbank Referenzviews anlegen zu müssen. Das trägt insbesondere der neuen Enterprise Architecture Rechnung, die z.B. in den SAP-Systemen Verwendung findet.

Der zweite von Microsoft genannte Punkt hat uns auch schon im Zusammenspiel mit DeltaMaster geholfen. So wurden zum Beispiel die allerersten Versionen der Hybrid-Prozeduren im Namensraum “P_WriteBack_…” gesucht. Mittlerweile ist dies konsequent auf “P_WriteBackSQL_…” umgestellt. Damit auch ältere DeltaMaster-Versionen sauber mit den neuesten Hybrid-Versionen zusammenarbeiten, erstellen wir aus ETL heraus einfach neben der Rückschreibroutine selbst noch ein Synonym im alten Namensraum, welches auf die neue Routine verweist. Damit sind wir ohne Parallelentwicklung voll kompatibel. Auch im Projekteinsatz könnte das durchaus hilfreich sein, wenn es verschiedene Versionen von Funktionen oder Prozeduren gibt, die parallel vorgehalten werden sollen.

Synonyme in ETL – WTF

DeltaMaster ETL stellt seit der Version 6.2.5 zahlreiche Funktionen zur Verfügung, um den Umgang mit Synonymen zu vereinfachen. Zunächst mal (für die Gruppe der “Tipp- und Merkfaulen”) eine ganz einfache Prozedur zum Anlegen von Synonymen “dbo.P_BC_Create_Synonym”. Hier muss man sich nicht den vollständigen Sourcecode merken und bekommt das vorherige Löschen (inkl. dem Wiederherstellen vorhandener Rechte) abgenommen. Weiterhin werden auch die Datenbanknamen auf Konsistenz geprüft. Dass die Routine auch datenbankübergreifend arbeitet, versteht sich fast von selbst.

Mit o.g. Routine kann allerdings nur ein Synonym für ein Objekt angelegt werden. Gerade in der noch recht neuen Enterprise Architecture gibt es allerdings den Bedarf sehr viele Synonyme im jeweils darüber liegenden Datenbank-Layer anzulegen. Zur Erinnerung an die ebenfalls noch wenig bekannte Enterprise Architecture hier nochmal eine Übersicht:

Abbildung 5: Enterprise architecture

Es ist also z.B. notwendig alle V_Import-Views aus der Staging-Datenbank als Synonym in der darüberliegenden DWH-Datenbank anzulegen. Selbiges gilt für den Zugriff von Model auf DWH.

Dafür wurde eigens ein neuer Bericht “Custom Synonyms” geschaffen, in welchem man Gruppen von Objekten über ein Namensmuster identifizieren und in einer Zieldatenbank anlegen lassen kann. Hier ein Auszug aus einem gängigen SAP-System:

Abbildung 6: Konfiguration von “Custom Synonyms”

Einmal eingetragen werden diese Synonyme bei der nächsten Ausführung des Prozessschritts “Create relational schema” angelegt. Will man das abkürzen, kann man die Synonyme auch durch manuelle Ausführung der Erzeugungsroutine “P_Model_Create_CustomSynonyms” direkt erzeugen.

Fazit

Synonyme sind unserer Meinung nach, gerade in Multi-Datenbank-Architekturen, unverzichtbar. Neben dem reinen Grundkonzept helfen insbesondere die produktivitätssteigernden Komponenten von DeltaMaster ETL diese Funktion auch effizient im Projektalltag nutzen zu können.

Wer sich noch nicht damit befasst hat, konnte seine Wissenslücken nach der kurzen Lektüre hoffentlich erfolgreich schließen. Synonyme gibt es auch ohne Thesaurus.