SSDS offers a simple, easy-to-understand data model. This post is an overview in order to get strated quickly. To learn more go to SQL Server Data Services Primer on MSDN.

The SSDS data model is a three-level containment model that includes authorities, containers and entities.

  • Authority: At the top level of this containment hierarchy is an authority. After you sign up for the data service, you begin by creating an authority. An authority is represented by a DNS name. For example:mydomain.data.beta.mssds.com. Where mydomain is an authority and data.beta.mssds.com refers to the service. The DNS name of an authority resolves to an IP address that maps to a specific data center. An authority, then, is the unit of geo location.
  • Container: An authority is a collection of containers. Each container has a unique id within an authority. A container stores data (entities). You create a container and then immediately begin storing entities of various kinds without having to worry about any container schema. A container is also the largest domain for search and update. In this beta release, cross-container queries are not supported.
  • Entity: Each entity inside a container can store any number of user-defined properties and corresponding values. An entity is the smallest object that can be updated, that is, you can retrieve an entire entity; add, update, delete properties; and then replace the original entity with the updated one. Partial updates are not supported. Blobs in SSDS are entities. These blob entities can only have metadata properties.

Depending on your application needs, you container can be a homogeneous or heterogeneous.

  • Homogeneous model: a container stores entities of the same kind. In this model, a container is like a table in a database. Some of the examples of homogeneous containers are as follows:
    • In an Employee table, you store employee records. These are all records of the same kind. In SSDS, you would create an Employee container that stores Employee entities. These entities can have different properties, but they are all Employee entities.
    • In a sample authority, books-docsamples (DNS name books-docsamples.data.beta.mssds.com), you can create containers such as ChildrensBooks and TechnicalBooks. You then store book entities in appropriate containers.
  • Heterogeneous model: a container is like a database that stores entities of all kinds. For example, a database can have Orders, Employees, and OrderDetails tables. In SSDS, you can create a single container to store orders, employees, and order details entities. The advantage in this case is that you can query across heterogeneous entities within the same container.

In SQL Server Data Services, the flexible entity is a key concept.

  • Flexible entity: each of these entities is a set of metadata properties and a bag of flexible properties. You can think of flexible entities as sparse tables in the relational data model or an XML fragment with one element per property value. Each property has a name and a value. The value can only be a simple scalar type. The simple scalar types supported in this release are string, binary, Boolean, decimal, and datetime.
  • Metadata Properties: Each flexible entity carries a fixed set of properties (Id, Version, and Kind). A blob entity has additional Content property. These are called metadata properties. The Id property uniquely identifies a flexible entity. The Version property acts like a timestamp. The Kind property value is user-defined and identifies the entity type. The Content blob property describes the blob.
  • Flexible Properties: In addition to the metadata properties, an entity can also have zero or more additional flexible properties. These flexible properties can have any name and any scalar value of one of the above scalar types.

NOTE In the current implementation, there are limits to using the user-defined and metadata properties.

Service Interface: SSDS supports both the SOAP and REST interfaces.

The URI Space: there are four kinds of URIs that you will work with if you are using the REST head.

  • Service: Used only during the authority creation process.
  • Authority: Used while creating and querying containers. In addition, the authority URI is used to retrieve metadata regarding a particular authority.
  • Container: Used while creating and querying entities. In addition, the container URI is used to retrieve metadata regarding a particular container or to delete a particular container.
  • Entity: Used while retrieving, updating, and deleting a particular entity.

Examples:

  • Service URI used when creating an authority. In the URI, v1 refers to version of service interface to be used. For this beta release, the value of version must always be v1

          https://data.beta.mssds.com/v1/

  • An authority URI is the service URI preceded by the authority id.

          https://<authority_id>.data.beta.mssds.com/v1/

  • A container URI is the authority URI followed by a container id.

         https://<authority_id>.data.beta.mssds.com/v1/<container_id>

The container URI fetches a single entity that conatins container metadata

An entity URI is a container URI followed by entity id. It returns a specific entity. The result includes all the metadata properties (id, version, and kind) and any user-defined flexible properties.

         https://<authority_id>.data.beta.mssds.com/v1/<container_id>/<entity_id>

A sample book entity is shown below:

<UsedBookKind xmlns:s="http://schemas.microsoft.com/sitka/2008/03/"        
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
              xmlns:x="http://www.w3.org/2001/XMLSchema">
  <s:Id>MySampleBook</s:Id>
  <s:Version>1</s:Version>
  <Title xsi:type="x:string">My Book</Title>
  <ISBN xsi:type="x:string">1-57880-066-36</ISBN>
  <Author xsi:type="x:string">Mr. Author</Author>
  <Publisher xsi:type="x:string">Mr. Publisher</Publisher>
  <InPrint xsi:type="x:boolean">false</InPrint>
  <NumberOfCopiesSold xsi:type="x:decimal">250</NumberOfCopiesSold>
  <PublicationDate xsi:type="x:dateTime">2004-01-27T00:00:00</PublicationDate>
  <CoverPhoto xsi:type="x:base64Binary">AQID</CoverPhoto>
</UsedBookKind>