The following diagram shows how the data flows through these components.

The database objects are persisted in the database project in the form of DDL scripts. When you open a database project, those scripts are read and two models are populated: the Script DOM model and the Schema Model. Features of Database Edition interact with both models, and when you save changes to database objects, those changes are persisted back out into DDL scripts.

When you run Database Edition, all database projects, schema providers, features, and feature extensions interact with the singleton ExtensionManager. The extension manager loads a single instance derived from DatabaseSchemaProvider for each database project. For example, when Database Edition opens a Microsoft SQL Server 2005 project, the extension manager loads an instance of Sql90DatabaseSchemaProvider (which it derived from DatabaseSchemaProvider).

The extension manager loads extensions based on the type of interface implemented by those extensions. For example, when you use the database unit testing feature, the extension manager returns a list of registered extensions that inherit the TestCondition base class, and those extensions are compatible with the database schema provider for the database project.

A feature, such as refactoring or static code analysis, is composed of components that are specific to a DSP and components that support all DSPs (DSP-agnostic components). When you define a feature extension, you declare the compatibility of that extension with a specific DSP or with a base DSP so that the extension is only loaded for appropriate project types. For example, you could declare that your extension was compatible either with Sql90DatabaseSchemaProvider (to restrict it to SQL Server 2005 projects) or with SqlDatabaseSchemaProvider (the base class for SQL Server 2000, SQL Server 2005, and SQL Server 2008 DSPs). You can also declare an extension to be compatible with multiple, specific DSPs. You might use this approach if you are not sure whether future releases might break your feature. To declare a feature to be compatible with all DSPs, declare it as compatible with the DatabaseSchemaProvider base class.

Examples

// SqlSchemaObjectDesigners is defined as compatible with all Sql 
// database services providers.  
[DatabaseServicesProviderCompatibility(typeof(SqlDatabaseServicesProvider))]
internal class SqlSchemaObjectDesigners : ISchemaObjectDesigners
{
}

// Extension InconclusiveCondition is defined as compatible with all 
// SQL Server database services providers and Oracle database 
// services providers.
[DatabaseServicesProviderCompatibility(typeof(SqlDatabaseServicesProvider))]
[DatabaseServicesProviderCompatibility(typeof(OracleDatabaseServicesProvider))]
public sealed class InconclusiveCondition : TestCondition
{
}

// Extension ReportingService is defined as compatible with all
// database services providers.
[DatabaseServicesProviderCompatibility(typeof(DatabaseServicesProvider))]
internal class ReportingService : IReportingService
{
}

// Extension ExecutionTimeCondition is defined as compatible with no
// database services providers.  That means if a feature
// has an ExtensionManager constructed with null, it will load
// those extensions defined as binding to 
// DspCompatibilityCategory.None
[DatabaseServicesProviderCompatibility(DspCompatibilityCategory.None)]
public sealed class ExecutionTimeCondition : TestCondition
{
}

A Script DOM provides implementation that parses a DDL script into an object model that represents the script. The Script DOM also provides implementation to reproduce the original script from the model.

The following diagram shows how data flows through the Script DOM.

The Script DOM parser translates the script, stored in an unstructured text file, into an object that inherits the IScriptFragment interface. The script generator in Script DOM takes an object that inherits the IScriptFragment interface and produces the original script. In the database schema providers for SQL Server, which are included with Database Edition, IScriptFragment abstracts an Abstract Syntax Tree (AST) and a token stream.

Tokens provide an unstructured representation of a script. Each token in the collection has:

• The token type (such as keyword or string literal)

• The token string

• The source file in which the token occurred

• The offset within that file at which the token occurred

Abstract Syntax Trees (ASTs) provide a structured representation of the script. Each node in the AST represents a batch of statements, a statement, or a component of a statement (such as an expression). ASTs are used to analyze scripts after they have been parsed. ASTs are also used to programmatically build scripts.

The Schema Model representation is an interface-based object model that models a live database instance. Interfaces are arranged in a derivation hierarchy that includes a single abstract layer that is shared by all DSPs, together with any number of abstract layers targeting more-specific model details. For example, the ISql90Table interface inherits ISqlTable, which inherits the abstract layer interface ITable.

The Schema Model takes the IScriptFragment objects and translates them into Schema Model elements (and also performs the reverse conversion, from Schema Model Elements into IScriptFragment objects). The Schema Model is composed of some number of Model Composer implementations. Each implementation creates a model from some other resource in the system. For example, the ScriptModelComposer composes a model from the script files maintained in the database project.

The Schema Model infrastructure (ModelStore and its supporting classes) implements integrated Script DOM references directly from model elements. This enables modeling of objects, such as stored procedures, which contain arbitrary scripts.

A Schema Model consists of a collection of elements and annotations. Elements describe the artifact being modeled (such as tables, views, stored procedures, triggers, columns, and so on). Annotations are used to associate arbitrary data with the model. Annotations are used by the database project core components, and they can also be used by project features and feature extensions. Both elements and annotations can be named or anonymous.

Model Elements

Elements are composed of properties and relationships. Properties represent basic data such as integers, Boolean values, and strings, and they are used to capture the details of the model. Relationships represent named and typed connections between elements. For example, an ITable element maintains a relationship of type IColumn named “Columns” that associates the table with its columns.

There are three basic types of relationships:

• Peer — represents a dependency by one element on another element in an arbitrary manner. In SQL Server, the relationship between a view and a table would best be modeled as a peer relationship.

• Composing — represents one element that consists of other elements. In SQL Server, the relationship between a table and its columns is best modeled as a composing relationship. A key principle of a composing relationship is that the two elements are created at the same time, as a single action. The elements do not have a dependency order, for creation or removal. However, the dependency direction of parent to child is maintained by the model in order to enable associative dependencies. For example, if a column has a dependency on a particular type, the parent table’s dependency on its composing column means that the table also depends on the type.

• Hierarchical — represents a hierarchy. Hierarchical relationships differ from composing relationships because the dependency direction is from child to parent (instead of the other way around). An example in SQL Server is the relationship between a schema and an owned object such as a table or a view. A table participates in a hierarchical relationship with its schema.

The following diagram shows the three different types of relationships that can be represented in the Schema Model.

Object Relationships in Schema Model

Each relationship in a model declares whether it is a multi-relationship or a single relationship. In all cases, an element can maintain an empty relationship. Models can be incomplete models of the real artifact.

Elements are interface-based in order to support the following features in a store implementation:

• Strong element typing (identity)

• Multiple inheritance

  • To support both DSP-agnostic and DSP-specific parts of the system

  • To support sharing of “qualities” across otherwise unrelated element types

• Version flexibility and extensibility

All model element classes implement the public IModelElement interface. Properties, relationships, and annotations can be accessed by using the ModelStore metadata API from this class. The interfaces, such as ITable, serve to provide access (bound at compile time) to properties and relationships in a simpler and more-maintainable manner.

Model Annotations