Erste Schritte mit SQL Server Data Services (SSDS) - Teil 1: Registrierung und Grundlagen

Die SQL Server Data Services (SSDS) sind in Microsofts "Software + Services" Strategie im Bereich der Entwickler-Services angesiedelt. SSDS ist Microsofts Cloud Database Service und gehört den sogenannten Building Block Services der Microsoft Services Plattform an. Die SSDS unterstützen sowohl SOAP als auch REST Schnittstellen. Dadurch wird es möglich, die SSDS aus allen Entwicklungsumgebungen (inkl. diverser Programmiersprachen) heraus zu nutzen, die diese Standards unterstützen.

In diesem mehrteiligen Blog möchte ich beschreiben, wie dieser Service zur Datenspeicherung genutzt werden kann. In diesem ersten Teil möchte ich auf die Registrierung bei SSDS eingehen und ein paar Worte zum grundsätzlichen Datenmodell der SSDS eingehen.

Erste Schritte mit SSDS

Schritt 1: Registrierung im Beta-Programm der SSDS

Um die SSDS zu nutzen, ist zunächst eine Registrierung auf dem SSDS Portal erforderlich. Für einen eingeschränkten Nutzerkreis werden auf dem Portal Einladungs-E-Mails verschickt. Diese enthalten eine ID. Diese ID kann auf dem Anmeldeportal eingegeben werden. Hierüber erhält man einen Benutzernamen und ein Passwort für die SSDS. Damit hat man zunächst einmal alle Daten, mit denen sich die SSDS nutzen lassen.

Schritt 2: Grundlagen zum Datenmodell der SSDS

Dem Datenmodell der SSDS liegt das sogenannte ACE-Modell zugrunde. ACE steht dabei für:

  • A - Authority
  • C - Container
  • E - Entity

Diese Elemente sind hierarchisch angeordnet, wie in folgender Abbildung zu sehen:

ACE-Datenmodell der SSDS

Abbildung: ACE-Datenmodell der SSDS

Authoritys sind die oberste Gruppierungseinheit. Eine Authority ist vergleichbar mit einer Web-Domain. Sie legt den Namen und den Speicherort (Rechenzentrum) aller darin enthaltenen Daten fest. Eine Authority ist oberste Adressierungseinheit und enthält eine Menge von Containern.

Ein Container ist in genau einer Authority gespeichert. Er dient zur Gruppierung der darin enthaltenen Entitys und ist vergleichbar mit einem Ordner in einem Dateisystem. Im aktuellen Entwicklungsstand beziehen sich Suchanfragen (hierzu mehr in einem späteren Blog) immer auf einen Container. Container-übergreifende Suchen sind derzeit nicht möglich.

Entitys sind die eigentlichen Datenelemente (und damit vergleichbar mit Dateien in einem Dateisystem), d.h. hier werden die eigentlichen Nutzdaten gespeichert. Dabei sind Entitys Sammlungen von Schlüssel/Wert-Paaren (wobei der Werttyp ebenfalls angegeben wird). Man kann sich Entitys somit als Tabellen, die drei Spalten ("Name", "Typ", "Wert"), enthalten. Alle in einer Entity gespeicherten Werte werden somit in den Tabellenzeilen gespeichert. Dabei gibt es "Pflicht"-Tabellenzeilen, d.h. Zeilen, die enthalten sein müssen - sogenannte Metadaten. Jede Entity enthält die beiden Medatatenzeilen "ID", über die die Entity eindeutig identifiziert wird, "Version", das die Versionsinformation enthält und "Kind", der vom Programmierer frei definierbare Entity-Typ. Spezielle Blob-Entitys enthalten noch das Metadatum "Content", in dem der Inhalt des Blobs gespeichert wird.

Diese drei Elemente - Authority, Container und Entity - sind Adressierungsgrößen für Inhalte in SSDS. So wird eine Entity eindeutig über die übergeordnete Authority, den beinhaltenden Container und die ID der Entity eindeutig identifiziert. Dies ist wichtig, wenn auf spezielle Inhalte zugegriffen werden soll:

  • Für Schreiben, Lesen, Ändern und Löschen von Entitys wird die Authority-, Container- und Entity-ID benötigt.
  • Für Suchoperationen wir die Authority- und die Container-ID benötigt, um den Suchscope zu setzen.

Entitys enthalten neben den Metadaten Propertys auch sogenannte "flexible propertys". Diese frei definierbaren Propertys folgen demselben Aufbau wie die Metadaten Propertys. Der Programmierer kann den Typ des Propertys frei setzen. Er hat dabei die Wahl zwischen folgenden Typen:

  • string
  • base64Binary
  • boolean
  • decimal
  • dateTime

Eine Entity kann damit aus den Metadaten und den "Flexible Propertys" (in C# umgesetzt als Dictionary) wie folgt aufgebaut werden:

Entity e1 = new Entity();

// Setzen der Metadaten

e1.Id = entityId;

e1.Kind = "UsedBookKind";

// Setzen der flexible properties

e1.Properties = new Dictionary<string, object>();

e1.Properties["Title"] = "My Book";

e1.Properties["ISBN"] = "1-57880-066-36";

e1.Properties["Author"] = "Mr. Author";

e1.Properties["Publisher"] = "Mr. Publisher";

e1.Properties["InPrint"] = false;

e1.Properties["NumberOfCopiesSold"] = 250m; //decimal

e1.Properties["PublicationDate"] = DateTime.Parse("27.01.2004");

e1.Properties["CoverPhoto"] = new byte[] { 0x1, 0x2, 0x3 };

In den weiteren Blogs dieser Reihe werde ich darauf eingehen, wie nun auf Basis dieses Modells SOAP- und REST-basierte Zugriffe auf die SQL Server Data Services möglich werden. Alles, was für die Adressierung der zu manipulierenden Objekte benötigt wird ist bereits vorhanden.

Weitere Informationen

Ich bin Referent auf dem Microsoft Technical Summit 2008 - treffen Sie mich vor Ort!

ACE-Konzept der SSDS.png