Informatiker sind stets bestrebt, Komplexität zu reduzieren, Performance zu steigern und sich das Arbeitsleben so leicht wie möglich zu gestalten: Quellcode wird beispielsweise nicht kopiert, sondern wiederverwendet; eine Dokumentation wird nach Möglichkeit automatisiert erstellt und eine gute Entwicklungsumgebung soll die Erstellung von Software umfassend unterstützen.

In unseren Projekten verwenden wir für die Entwicklung größtenteils die gleichen Projektwerkzeuge. Die wahrscheinlich am häufigsten eingesetzte Projektumgebung besteht aus nur drei Tools: SQL Server Management Studio (SSMS), Business Intelligence Development Studio (BIDS) bzw. Visual Studio (ab SQL Server 2012) und DeltaMaster Modeler (DMM). Mit dieser schlichten Projektumgebung lassen sich relativ schnell und einfach BI-Projekte umsetzen. Aber es gibt durchaus Möglichkeiten, Effizienz und Qualität weiter zu steigern.

In diesem Blogbeitrag wird zunächst eine Übersicht über das SQL Developer Bundle von der Firma redgate aus Cambridge gegeben. Anschließend wird gezeigt, wie diese Tools die Entwicklung von BI-Projekten unterstützen können. Insbesondere wird auf das Thema Versionskontrolle eingegangen.

SQL Developer Bundle – Toolübersicht

Das SQL Developer Bundle von redgate umfasst zwölf Tools für eine einfachere und schnellere Bereitstellung und Entwicklung mit dem Microsoft SQL Server. Auch zur Fehlerbehebung und Dokumentation können die Werkzeuge sehr gut eingesetzt werden.

Werkzeuge zur Datenbank-Bereitstellung

SQL Source Control: Versionsverwaltung von SQL-Datenbanken

• Quellcodeverwaltung: Entwicklungsverlauf und Änderungsverfolgung
• Einfachere Zusammenarbeit im Team
• Vermeidung von Codeverlusten durch Wiederherstellung vergangener Versionen

SQL Compare Pro: Synchronisation und Bereitstellung von SQL-Datenbankschemata

• Synchronisation von SQL-Code aus Versionen oder Entwicklungsdatenbanken
• Generierung von SQL-Skripten zur Aktualisierung der Datenbankschemata
• Aufzeigen von Unterschieden zwischen Datenbanken oder Versionen

SQL Data Compare: Vergleich und Synchronisation von Datenbankinhalten

• Vergleich und Synchronisation von Daten aus Backups oder Produktiv- bzw. Testdatenbanken
• Generierung von SQL-Skripten zur Aktualisierung von Daten
• Kopieren von Daten zwischen Datenbanken

SQL Packager: Zusammenfassung aller Änderungen einer SQL-Datenbank in einem Paket

• Berücksichtigt Schema- und Daten-Änderungen (konfigurierbar)
• Kann SQL-Skripte oder ausführbare Dateien erstellen
• Vereinfacht Rollouts und Updates

SQL Multi Script: Ausführung mehrerer Skripte auf mehreren Datenbanken zur gleichen Zeit

SQL Connect: Datenbankentwicklung in Visual Studio statt in SSMS

Werkzeuge zur Datenbank-Entwicklung

SQL Prompt: Effizienter lesbaren SQL-Code schreiben

• Automatische Code-Formatierung (konfigurierbar)
• Erweiterte IntelliSense Code Vervollständigung
• Wiederverwendbarkeit von SQL-Code

SQL Dependency Tracker: Aufzeigen von Objekt-Abhängigkeiten

• Visualisierung von Objekt-Abhängigkeiten innerhalb und zwischen
  SQL-Datenbanken
• Dokumentation von SQL-Datenbanken
• Unterstützt beim Prüfen und Aufräumen von SQL-Datenbanken

SQL Search: Erweiterte Suche innerhalb von SQL-Datenbankschemata

• Findet alle Vorkommen innerhalb einer SQL-Datenbank oder SQL-Servers
• Suche kann auf bestimmte Bereiche, z. B. Views oder Prozeduren, eingeschränkt werden
• Kostenlos!

SQL Test: Unit Tests für SQL-Datenbanken

• Automatisierte Tests in T-SQL schreiben
• Möglichkeit zur testgetriebenen Entwicklung
• Integration in SSMS

SQL Data Generator: Einfache Generierung von Test-Daten

• Schnelle und einfache Generierung von Test-Daten auf Basis von Spalten- und Tabellennamen
• Konfigurierbare Erstellung
• Vorführung eines Systems ohne Echt-Daten oder Test einer neuen Datenbank

Werkzeuge zur Datenbank-Dokumentation

SQL Doc: Automatische Dokumentation von SQL-Datenbanken

• Schnelle und einfache Erstellung
• Geänderte Beschreibungen werden in der Datenbank gespeichert
• Unterstützung von .chm, .doc und .html

Unterstützung in BI-Projekten

In einem klassischen BI-Projekt können diese Tools die Entwickler während des gesamten Entwicklungsprozesses als auch bei der Wartung unterstützen.

SQL Search

Einfaches, nützliches und kostenloses Tool. Nach der Installation steht im SSMS ein neuer Button „SQL Search“ zur Verfügung (siehe Abb. 1). Ist mit dem SSMS eine Verbindung zu einem SQL Server hergestellt, kann eine gesamte Datenbank durchsucht werden. Die Suche kann auf Prozeduren, Constraints, Views o. ä. eingeschränkt werden. Im mittleren Bereich werden alle Treffer und im unteren Bereich das Skript zum Treffer angezeigt. Zum Editieren gelangt man über den Link „Select object in Object Explorer“.

Praxisbeispiel: Eine View soll durch eine andere View ersetzt werden. Mit Hilfe von SQL Search kann sehr schnell herausgefunden werden, an welchen Stellen im Datenbankschema die View benutzt wird. Alle direkten Abhängigkeiten werden zwar auch über SSMS angezeigt, aber nicht, wenn die View als Parameter verwendet wird oder Abhängigkeiten zu einer anderen Datenbank bestehen. Außerdem muss nicht erst mühsam an die entsprechende Stelle im Objekt-Explorer navigiert werden.

Abb. 1: SQL Search im SSMS

SQL Prompt

Wahrscheinlich kennt jeder schlecht lesbaren Quellcode. Bevor der Code gelesen und verstanden werden kann, muss dieser teilweise erst mühsam bearbeitet werden – lästige Fleißarbeit. Mittels SQL Prompt wird der Code auf Knopfdruck lesbar formatiert. Zu diesem Zweck können Vorgaben hinterlegt werden, um so eigene Vorlieben oder einen vereinbarten Code-Style umzusetzen. Sinnvolle Kommentare müssen aber weiterhin vom Programmierer eingefügt werden.

Vorher:

alter view [dbo].[V_Import_DIM_Kunden]as
select Kunde KundeID, Kundenbezeichung, Land LandID, Land LandText, Konzern KonzernID, Konzern KonzernText
from T_Import_Kunden

Nachher:

ALTER VIEW [dbo].[V_Import_DIM_Kunden]
AS
SELECT
      Kunde KundeID
      ,Kundenbezeichung
      ,Land LandID
      ,Land LandText
      ,Konzern KonzernID
      ,Konzern KonzernText
FROM
      T_Import_Kunden

Versionsverwaltung

Das wahrscheinlich wichtigste Tool aus dem SQL Developer Bundle ist SQL Source Control. Mit sehr einfachen Mitteln kann sehr viel erreicht werden. Dazu vorab noch ein paar einleitende Worte.

Was ist eine Versionsverwaltung, warum sollte diese nach Möglichkeit eingesetzt werden und welche Vorteile entstehen dadurch? Hauptmerkmal von Versionsverwaltungs- bzw. Versionskontrollsystemen ist die Protokollierung von Änderungen über einen Zeitraum. Zu jedem Zeitpunkt kann auf eine bestimmte Version zugegriffen oder diese sogar wiederhergestellt werden. Wenn beispielsweise eine Datenbank unter Versionskontrolle in einem Repository steht, können alle Änderungsschritte im Datenbankschema nachverfolgt oder auch in einen früheren Zustand zurückgesetzt werden, falls es zu einem Fehler oder unbeabsichtigtem Verlust kommt.

Darüber hinaus wird protokolliert, wer was wann geändert hat, was die Zusammenarbeit im Team vereinfacht. Jeder kann prüfen, ob ein Kollege seine Änderungen umgesetzt hat und ob eigene Änderungen mit anderen Änderungen überschneidungsfrei sind. Außerdem räumt die Versionsverwaltung die Möglichkeit ein, fast automatisiert bestimmte Änderungen aus einem Entwicklungssystem auf ein Produktivsystem zu übertragen. Zudem ist es möglich, mehrere Entwicklungszweige gleichzeitig zu verfolgen, wenn z. B. nicht klar ist, welches der beste Weg ist, eine neue Anforderung umzusetzen.

SQL Source Control

SQL Source Control wird direkt in das SSMS integriert, so dass kein zusätzliches Programm geöffnet werden muss. Es ist auf Datenbank-Entwicklungstätigkeit ausgerichtet und arbeitet mit allen Versionsverwaltungsprogrammen zusammen, die über eine Kommandozeile angesprochen werden können. Die integrierte Versionsverwaltung ist nur für Evaluierungszwecke gedacht.

Eines der bekanntesten Versionsverwaltungssysteme ist Subversion (SVN), das zu den zentralisierten Versionsverwaltungssystemen zählt. SVN kann unter Linux, Mac und Windows genutzt werden und ist OpenSource. Möchte man ein verteiltes Versionsverwaltungssystem nutzen, wäre Git eine Alternative, ebenfalls Open Source. In diesem Blog wird SQL Source Control mit SVN gezeigt.

Installation und Einrichtung von SQL Source Control und Subversion

Als erstes muss ein SVN-Server installiert werden. Auf der Website von Apache-Subversion (siehe Kapitel 6 „Quellen“) kann unter dem Link Packages ein SVN-Server für das passende Betriebssystem heruntergeladen werden, z. B. VisualSVN für Windows mit Active Directory Single Sign-On. Die Installation wird über eine Microsoft Installationsroutine vorgenommen, ist also genauso einfach wie bei DeltaMaster. Nach der Installation legt man ein Repository für die Datenbank an, die unter Versionsverwaltung gestellt werden soll.

Danach kann SQL Source Control Standalone oder das redgate SQL Developer Bundle installiert werden – ebenfalls über eine Installationsroutine. Nach der Installation von SQL Source Control steht im SSMS ein neuer Button „SQL Source Control“ zur Verfügung.

Sind die Installationen getätigt, kann eine Datenbank in nur zwei Schritten unter Versionsverwaltung gestellt werden. Dazu einfach im Objekt-Explorer die entsprechende Datenbank auswählen und anschließend das Setup von SQL Source Control über den entsprechenden Button öffnen. Im Setup-Fenster ist zu sehen, welche Datenbank gewählt wurde und ob diese bereits unter Versionsverwaltung steht. Ist dies nicht der Fall, befindet sich unter „Linked to:“ der Eintrag „Not linked“ (siehe Abb. 2). Über „Link database to source control…“ gelangt man zum nächsten Schritt, bei dem die weiteren Einstellungen vorgenommen werden.

Abb. 2: SQL Source Control im SSMS – Setup

Datenbank Entwicklungsmodell

Im nächsten Fenster muss festgelegt werden, welches Versionskontrollsystem verwendet wird, wie das dazugehörige Repository erreicht werden kann und welches Entwicklungsmodell – „dedicated database“ oder „shared database“ – verwendet werden soll (siehe Abb. 3).

Abb. 3: SQL Source Control – Link to source control

Dedicated database

„Dedicated database“ bedeutet, dass jeder Entwickler auf seiner eigenen Datenbank arbeitet. Die Datenbank, die unter Versionsverwaltung gestellt wird, ist also eine Kopie. Ob diese Kopie wiederum lokal auf dem eigenen PC oder auf einem Server liegt, spielt keine Rolle. Die Änderungen der einzelnen Entwickler werden in dem Versionsverwaltungssystem zusammengeführt. Nach erfolgreichen Tests kann zu einem definierten Zeitpunkt ein Rollout auf die originale Datenbank vorgenommen werden.

Um Änderungen anderer Entwickler zu erhalten, müssen diese aus dem Versionsverwaltungssystem abgerufen werden („Get latest“), was regelmäßig gemacht werden sollte, um Konflikte zu vermeiden. Aus dem gleichen Grund sollten auch regelmäßig eigene Änderungen in das Versionsverwaltungssystem geladen werden („Commit changes“).

Da jeder Entwickler auf seiner eigenen isolierten Umgebung arbeitet, besteht kein Risiko, dass man Änderungen anderer überschreibt bzw. eigene Änderungen überschrieben werden. Komplizierten Änderungen, die ein System zeitweise nicht nutzbar machen würden, steht damit auch nichts mehr im Wege. Und selbst wenn die eigene Datenbank nicht mehr funktioniert, hat dieses keinen Einfluss auf andere Teammitglieder. Zusätzlich kann jederzeit zu einem definierten Stand zurückgekehrt werden.

Shared database

Bei der zweiten einfacheren Option „Shared database“ arbeiten alle Entwickler auf einer Datenbank. Diese kann eine produktive Datenbank sein oder typischerweise eine Test- oder Entwicklungsdatenbank. Nachdem eine Entwicklung abgeschlossen und getestet ist, kann leicht ein Änderungsskript erstellt werden, um den Entwicklungsstand auf eine produktive Datenbank zu migrieren.

In diesem Modell müssen Änderungen nicht bereitgestellt und abgerufen werden, denn alle Entwickler erhalten diese natürlich automatisch durch die gemeinsam verwendete Datenbank. Trotzdem empfiehlt es sich, regelmäßig Änderungen in die Versionsverwaltung zu bestätigen, falls z. B. ein alter Stand wiederhergestellt werden soll.

Welches Entwicklungsmodell für eine Datenbank genutzt wird, hängt von den gegebenen Möglichkeiten und dem Einsatzzweck ab. Das gewählte Modell kann jederzeit im Setup-Fenster nachvollzogen und geändert werden. In den meisten Fällen wird die zweite Option der gemeinsamen Datenbank ausreichen. In größeren Teams sind sogar Kombinationen der beiden Entwicklungsmodelle möglich.

Arbeiten mit SQL Source Control

Im SSMS Objekt-Explorer ist auf einen Blick zu erkennen, ob

• eine Datenbank unter Versionsverwaltung steht
• Änderungen in einer Datenbank noch nicht bestätigt wurden
• eine Datenbank nicht unter Versionsverwaltung steht .

Wird nun beispielsweise eine View neu angelegt oder verändert, dann wird dies automatisch im Hintergrund gegen die letzte Version in dem Versionsverwaltungssystem geprüft. Nach wenigen Sekunden ändern sich die Symbole der Datenbank, der darunter liegenden Ordner und auch die Symbole der Views. Dadurch wird sofort erkannt, was sich gegenüber der aktuellsten Version in der Versionsverwaltung geändert hat und dass diese Änderungen noch bestätigt werden müssen (siehe Abb. 4).

Abb. 4: SSMS Objekt Explorer

Änderungen bestätigen und übertragen

Die Bestätigung erfolgt über den Reiter „Commit changes“. In diesem Fenster (siehe Abb. 5) werden im mittleren Bereich alle Änderungen aufgelistet. Die Darstellung zeigt, wer welches Objekt wie geändert hat. Auf diese Weise ist es möglich, z. B. nur seine eigenen Änderungen und nicht die Änderungen eines Kollegen mit in das Repository zu bestätigen, da dieser vielleicht noch daran arbeitet. Im unteren Bereich besteht die Möglichkeit, sich detailliert anzusehen, was genau gegenüber der Version im Repository geändert wurde. Vor einem Commit sollte auch ein aussagekräftiger Kommentar angegeben werden, damit leichter nachvollzogen werden kann, was im Vergleich zur letzten Version geändert wurde.

Abb. 5: SQL Source Control – Commit changes

Migrationsskript erstellen

Über den Reiter „Migrations“ definiert die Anwendung automatisch ein Migrationsskript mit allen Änderungen von einer Version zur nächsten Version. Sie erstellt ein SQL-Skript, dass dann auf einer anderen, z. B. der produktiven Datenbank, ausgeführt werden kann, um die letzten Änderungen live zu schalten.

Nachfolgend ein Beispiel für ein solches Skript. In dem Skript wird die View V_inventory_fact_2007 geändert und die View V_Import_Dim_Product neu angelegt:

/*
This is the script that will be used to migrate the database from revision 2 to revision 3.

You can customize the script, and your edits will be used in deployment.
The following objects will be affected:
 dbo.V_inventory_fact_2007, dbo.V_IMPORT_DIM_Product
*/

SET NUMERIC_ROUNDABORT OFF
GO
SET ANSI_PADDING, ANSI_WARNINGS, CONCAT_NULL_YIELDS_NULL, ARITHABORT,
QUOTED_IDENTIFIER, ANSI_NULLS ON
GO

PRINT N'Altering [dbo].[V_inventory_fact_2007]'
GO
ALTER VIEW [dbo].[V_inventory_fact_2007]
AS

-- 2013-10-23, TUN: add an alias to the table
SELECT
              i.*
              ,1 TimeUtilityID
              ,1 CumulationID
              ,1 ValueTypeID
FROM
              dbo.inventory_fact_2007 i

GO
PRINT N'Creating [dbo].[V_IMPORT_DIM_Product]'
GO
CREATE VIEW [dbo].[V_IMPORT_DIM_Product] AS

SELECT
       pc.product_category product_category_id
      ,pc.product_category product_category_name
      ,pc.product_class_id product_subcategory_id
      ,pc.product_subcategory product_subcategory_name
      ,p.product_id
      ,p.product_name
FROM
      dbo.product_class pc
      JOIN dbo.product p
            ON p.product_class_id = pc.product_class_id
       
-- ORDER BY 1, 3, 5
GO