Montag, 9. Juni 2014

SQL Server Data Tools - die Entwicklungsumgebung für Datenbankentwickler

Mit welchen Werkzeugen haben sie bisher Ihre Datenbanktabellen, Views und Stored Procedures erstellt? Die SQL Server Umgebung bot hier bisher nur wenig Unterstützung, so dass Entwicklerteams auf Produkte von Drittanbietern angewiesen waren. Das ändert sich durch die SQL Server Data Tools (SSDT), die Microsoft lizenzkostenfrei anbietet.

"BI or not BI" - Begriffsklärung

Die Namensgebung ist etwas verwirrend, denn wenn Sie bereits mit SQL Server 2012 arbeiten und die Reporting Services, Integration Services oder Analysis Services einsetzen, dann haben Sie bereits "Data Tools" installiert. Diese heißen jetzt zur Unterscheidung mit vollem Namen "SQL Server Data Tools – Business Intelligence" (SSDT-BI). Darüber habe ich bereits in diesem Blogbeitrag geschrieben.

Hier geht es nun um die Server Data Tools (SSDT) für die Entwicklung von Datenbank-Projekten.

Einsatz

SSDT kommt dem Bedürfnis von Projektteams entgegen, Datenbankprojekte genauso wie BI Projekte in Visual Studio zu entwickeln und dabei eine Quellcodeverwaltung (z.B. Team Foundation Server TFS) einzusetzen. Zu diesem Zweck gibt es neben dem Online-Arbeiten, wo Änderungen direkt auf die Datenbankobjekte angewendet werden, die Offline-Projekte, wo Entwickler auch ohne direkte Verbindung zum SQL Server Objekte wie Tabellen etc. modellieren können. Grafische Editoren für Tabellen, Views, Stored Procedures usw. erleichtern und beschleunigen diese Arbeiten sehr.
Darüber hinaus bietet der Schema-Vergleich die Möglichkeit, ALTER-Skripte zu generieren, mit denen beispielsweise der Stand der Produktionsdatenbank auf den der Test-Datenbank gebracht wird - eine ganz wichtige Arbeitserleichterung. Auch für den Vergleich und das Angleichen von Daten in Tabellen gibt es ein Werkzeug. Und beim Überarbeiten umfangreicher SQL-Skripte, zum Beispiel dem Umbenennen einer Tabellenspalte, identifiziert die Funktion "Refactor" alle Referenzen, die in Folge ebenfalls angepasst werden müssen.
Mein erster Eindruck ist, dass hier kein Wunsch offen bleibt und ich bin gespannt, was nach einigen Wochen Projekterfahrung mit SSDT zu ergänzen ist. SSDT unterstützt als Quell- und Zieldatenbanken die SQL Server Versionen 2005 bis 2014 sowie SQL Azure. 

Eindrücke

Die folgenden Bilder geben einen kleinen Eindruck von der Entwicklungsumgebung. Eine anschauliche Schritt-für-Schritt Anleitung stellt Microsoft hier bereit: Dokumentation zu SSDT 
 
Der Schemavergleich zeigt Unterschiede in den Strukturen zweier Datenbanken und generiert ein passendes ALTER Skript.
 
 
Der Datenvergleich zeigt die unterschiedlichen Daten in zwei Tabellen und generiert ein Skript, um die Inhalte anzugleichen.
Der linke Teil zeigt die grafische und die Skript-Darstellung einer Tabelle, während der rechte Teil die Projektstruktur anzeigt.
 

Installation

Die SQL Server Data Tools können Sie hier herunterladen. Es gibt einen Web-Installer sowie ein ISO-Image, das die Installation ohne Internetzugang ermöglicht. Wenn Sie bereits die Professional, Ultimate oder Premium Edition von Visual Studio 2012 installiert haben, dann ist SSDT bereits darin enthalten. Wenn Sie jedoch noch kein Visual Studio 2012 auf dem Computer installiert haben, dann erhalten Sie bei der Installation die Visual Studio 2012 Shell, die keine Unterstützung für die Programmiersprachen wie C# oder Visual Basic bietet.
Die Visual Studio Shell wird übrigens auch bereitgestellt, wenn Sie die SQL Server Data Tools für BI (SSDT-BI) installieren. Wenn Sie SSDT und SSDT-BI installieren, dann integrieren sie sich in dieselbe Visual Studio Shell.
Fazit: Egal, ob Sie eine Vollversion von Visual Studio haben oder nicht, beide Projekttypen integrieren sich in dieselbe Entwicklungsumgebung.

Alle Links auf einen Blick


Download der SSDT
Dokumentation zu SSDT
Übersicht der SQL Server Data Tools

Donnerstag, 5. Juni 2014

Data Tools für Business Intelligence

Die Installations-DVD von SQL Server 2012 enthält - wie die vorherigen Versionen auch - als Entwicklungsumgebung für die BI-Komponenten eine Version von Visual Studio. Diese trägt zwar aus Marketing-Gründen die Bezeichnung "SQL Server Data Tools", ist aber nichts anderes als Visual Studio 2010 mit den Projektvorlagen für Business Intelligence Projekte (Reporting Services, Integration Services, Analysis Services).

Zwei Versionen der SQL Server Data Tools: VS2010 und VS2012

Seit März 2013 ist die Situation etwas komplizierter geworden, da es zusätzlich möglich ist, Visual Studio 2012 als BI Entwicklungsumgebung einzusetzen. Der korrekte Name für diese Version ist "SQL Server Data Tools – Business Intelligence for Visual Studio 2012". Diese neuere Version der Data Tools steht hier zum Herunterladen bereit:
http://www.microsoft.com/en-us/download/details.aspx?id=36843

Wenn zwei Versionen verfügbar sind, welche sollten Sie dann einsetzen? Glücklicherweise vertragen sich beide Versionen sehr gut, so dass ein Projektteam sogar beide gleichzeitig einsetzen kann:
  • Beide Versionen lassen sich nebeneinander auf einem Rechner installieren
  • Projekte können abwechselnd mal mit der neueren und dann wieder mit der älteren Version bearbeitet werden - es findet keine Konvertierung der Dateien statt
Sie haben also die freie Wahl, mit welcher Version Sie arbeiten.

Und was ist mit Visual Studio 2013?

Die Produktzyklen bei Microsoft werden kürzer, so ist bereits Visual Studio 2013 verfügbar und auch SQL Server 2014 ist bereits seit April auf dem Markt. Die gute Nachricht ist: Da es an den BI Komponenten von SQL Server 2014 keine Veränderungen gegenüber SQL Server 2014 gegeben hat, können Sie problemlos mit den "alten" Data Tools für SQL Server 2012 auch für SQL Server 2014 entwickeln.
Falls Sie die letzte verfügbare Entwicklungsumgebung einsetzen möchten, können Sie hier die "Microsoft SQL Server Data Tools - Business Intelligence for Visual Studio 2013 " herunterladen:
http://www.microsoft.com/en-us/download/details.aspx?id=42313

Zusammenfassung

Diese Matrix stellt das vorher Beschriebene in kompakter Form dar:

  Visual Studio 2010 Visual Studio 2012 Visual Studio 2013
SQL Server 2012 auf Installations-DVD SSTD-BI für SQL Server 2012 --
SQL Server 2014 -- SSTD-BI für SQL Server 2012 SSTD-BI für SQL Server 2014

Einfache Installation

Die Installation ist unkompliziert. Nach dem Download und Start der Installationsdatei sollten Sie die Standardeinstellung "Perform a new Installation..." belassen, wie das folgende Bild zeigt (die andere Option führt zu einem Abbruch der Installation).

Diese Standardeinstellung sollten Sie nicht ändern

Danach stehen die Data Tools als Shared Feature für die Installation zur Verfügung.

Außer dem Setzen dieses Hakens gibt es keine weiteren Auswahlmöglichkeiten




Quelle:
http://blogs.msdn.com/b/mattm/archive/2013/03/07/sql-server-data-tools-business-intelligence-for-visual-studio-2012-released-online.aspx

Dienstag, 20. Mai 2014

Freigegebene Datenquellen und Datasets richtig einsetzen

Reporting Services (SSRS) bieten ja die Möglichkeit, zwei unterschiedliche Entwicklungsumgebungen für Berichte zu verwenden:
  • Report Designer in Visual Studio (bzw. "Business Intelligence Studio" oder "Data Tools", wie es aus Marketinggründen heißt, wenn es mit SQL Server installiert wird)
  • Report Builder, den berechtigte Anwender selbst von SharePoint oder vom Report Manager herunterladen und nutzen können
Report Builder mit seiner an Office Anwendungen angelehnten Oberfläche für Fachanwender

Während Report Designer eher das Werkzeug für IT-Profis ist, soll der Office-ähnlich aufgemachte Report Builder Mitarbeitern in den Fachabteilungen die Möglichkeit geben, selbständig Berichte zu erstellen. Eine gute Ergänzung, die gleichermaßen der Forderung nach qualitätsgesicherten Standard-Berichten von der IT-Abteilung und dem Bedürfnis nach hoher Flexibilität für die Fachanwender gerecht wird.

Nun haben IT-Verantwortliche naturgemäß Schwierigkeiten damit, allen Anwender direkten Zugriff auf die Unternehmensdatenbanken zu gewähren. Das ist ja auch nachvollziehbar, denn in diesem Fall könnten einzelne Berichtsautoren durch (ungewollt) massive Datenbankabfragen die Verfügbarkeit für alle Anwender gefährden. Hier kommen freigegebene Datenquellen (shared data sources) und freigegebene Datasets (shared datasets) ins Spiel. Datenquellen enthalten die Verbindungszeichenfolge zu einer Datenbank (Server, Datenbank, Benutzername und Passwort), während Datasets die SQL Abfrage enthalten. Das ermöglicht eine klare Rollenverteilung:
  • Alle Anwender, die direkten Zugriff auf eine Datenbank haben, dürfen freigegebene Datenquellen und freigegebene Datasets hierfür erstellen und modifizieren.
  • Anwender, die keinen Zugriff auf eine Datenbank haben, können dennoch die freigegebenen Datenquellen und die freigegebenen Datasets in eigenen Berichten nutzen.
  • Wenn Anwender ohne Zugriff auf eine Datenbank versuchen, eine Datenquelle oder ein Dataset zu verändern, erhalten sie die Aufforderung, einen Datenbankbenutzer samt Passwort anzugeben.
Auf diese Weise ist sichergestellt, dass nur eingewiesene Programmierer die SQL Abfragen erstellen. Die IT Verantwortlichen behalten so die Kontrolle über die Art des Zugriffs auf die Datenbank. Gleichzeitig können Fachanwender auf Basis dieser Datasets ihre eigenen Berichte erstellen.

Wäre noch zu klären wie es sein kann, dass Fachanwender ohne direkten Datenbankzugriff dennoch über die vorhandenen Datenquellen und Datasets die Berichtsdaten abrufen können. Dazu muss ein Mitglied der Rolle "Content Manager" auf dem Report Manager den Eigenschaften-Dialog der Datenquelle öffnen.

Hier erhält die Datenquelle Zugriff auf die Datenbank

Der Benutzername und das Kennwort des hier angegebenen Benutzerkontos werden verschlüsselt auf dem Berichtsserver gespeichert. Bitte achten Sie darauf, hier einen technischen Benutzer und nicht die Anmeldeinformationen eines echten Mitarbeiters anzugeben, denn wenn dieser sein Kennwort ändert, dann funktioniert die Datenquelle nicht mehr.
Diese Funktionsweise von freigegebenen Datenquellen und Datasets ist unabhängig davon, ob Reporting Services im nativen Modus ("stand-alone") oder im SharePoint integrierten Modus laufen. Einziger Unterschied ist, dass im ersten Fall die Webanwendung "Berichts-Manager" den Speicherort für Quellen, Datasets und Berichte bereitstellt und im zweiten Fall SharePoint Bibliotheken diese Aufgabe übernehmen.

Dienstag, 22. April 2014

Kostenloses E-Book zu SQL Server 2014

So wie schon für die letzten beiden Versionen von SQL Server haben nun die beiden Autorinnen Ross Mistry und Stacia Misner ein E-Book zum SQL Server 2014 geschrieben. Es behandelt die Neuerungen gegenüber der Version 2012 und ist dank des anschaulichen Schreibstils, klarer Abbildungen und prägnanter Codebeispiele wieder sehr nützlich für alle, die sich mit den neuen Möglichkeiten vertraut machen möchten.

Dieses E-Book ist kostenfrei bei Microsofts Virtual Academy zum Download erhältlich:
http://www.microsoftvirtualacademy.com/ebooks

Meine Empfehlung an alle, die bereits mit den früheren SQL Server Versionen vertraut sind und die SQL Server 2014 verstehen und einsetzen möchten: Unbedingt lesen!

Freitag, 28. Februar 2014

Beziehungen zwischen Tabellen dokumentieren

"Herzlichen Glückwunsch - Sie haben eine Datenbank gewonnen!" Mit diesen Worten bekam ich vor einigen Jahren anlässlich der Verabschiedung eines Kollegen die Verantwortung für den Betrieb und die Weiterentwicklung einer Datenbank überreicht. Wie Sie sich vorstellen können, hatte ich daraufhin erst einmal einiges an Arbeit, um mir einen Überblick über Art und Umfang des "Geschenks" zu verschaffen.

Beziehungen automatisch dokumentieren


Insbesondere um die existierenden Abfragen gegen die nicht so gut dokumentierte Datenbank zu verstehen und weiterentwickeln zu können, brauchte ich schnell eine Zusammenstellung der Beziehungen zwischen den Tabellen:
  • von Tabelle
  • nach Tabelle
  • Namen der Primär- und Fremdschlüsselspalten
Die folgende Abfrage auf Basis der Sichten in INFORMATION_SCHEMA hat mir dabei sehr geholfen.


SELECT FKT.TABLE_NAME AS FK_Table -- Fremdschlüssel-Tabelle
,CU.COLUMN_NAME AS FK_Column -- Fremdschlüssel-Spalte
,PKT.TABLE_NAME AS PK_Table -- Primärschlüssel-Tabelle
,PKT1.COLUMN_NAME AS PK_Column -- Primärschlüssel-Spalte
,C.CONSTRAINT_NAME AS Constraint_Name -- Name des Constraints
FROM INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS C
INNER JOIN INFORMATION_SCHEMA.TABLE_CONSTRAINTS FKT
  ON C.CONSTRAINT_NAME = FKT.CONSTRAINT_NAME
INNER JOIN INFORMATION_SCHEMA.TABLE_CONSTRAINTS PKT
  ON C.UNIQUE_CONSTRAINT_NAME = PKT.CONSTRAINT_NAME
INNER JOIN INFORMATION_SCHEMA.KEY_COLUMN_USAGE CU
  ON C.CONSTRAINT_NAME = CU.CONSTRAINT_NAME
INNER JOIN (
  SELECT TCI.TABLE_NAME
    ,CUI.COLUMN_NAME
    ,CUI.ORDINAL_POSITION
  FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS TCI
  INNER JOIN INFORMATION_SCHEMA.KEY_COLUMN_USAGE CUI
    ON TCI.CONSTRAINT_NAME = CUI.CONSTRAINT_NAME
  WHERE TCI.CONSTRAINT_TYPE = 'PRIMARY KEY'
  ) PKT1
  ON PKT1.TABLE_NAME = PKT.TABLE_NAME
    AND PKT1.ORDINAL_POSITION = CU.ORDINAL_POSITION

Aus SQL-Sicht ist daran interessant, dass die Tabellen TABLE_CONSTRAINTS und KEY_COLUMN_USAGE mehrfach vorkommen, aber in unterschiedlichen Rollen. Durch Vergabe unterschiedlicher Alias-Namen für dieselbe Tabelle (FKT, PKT, TCI bzw. CU, CUI) wird das unterschieden. So, als handle es sich jedes Mal um eine andere Tabelle. Eine Technik, die Sie immer dann anwenden können, wenn dieselbe Tabelle in einer Abfrage unterschiedliche Rollen einnimmt.