Schemas (EDM)

Article
04/16/2009

An Entity Data Model (EDM) schema is an XML text file that describes entity and relationship types. The schema also defines a container within which instances of these types are logically organized. Entities and associations in the EDM define both the basic types installed with the Entity Framework and the types designed by developers.

A design schema is written in conceptual schema definition language (CSDL). A second schema written in store schema definition language (SSDL) defines the storage model for an application that uses the EDM.

This topic describes design schemas written in CSDL. For more information about storage metadata and mapping schemas, see Schemas and Mapping Specification (Entity Framework).

The top-level element in a schema assigns a namespace within which name-uniqueness rules apply. The types defined in the following abbreviated schema are logically organized under the namespace MyCompany.LOBSchema. This namespace resembles a namespace in object-oriented programming that contains classes and procedural code. The EDM does not define procedures. For information about implementing procedures in the EDM, see Helper Methods (EDM)

Each entity and association defined in the following schema has a fully qualified name, such as MyCompany.LOBSchema.Customer. Fully qualified names are shortened in the example by the Self alias declared for the namespace MyCompany.LOBSchema, as in the usage Self.Customer.

Entities and associations are defined in the body of the schema. The properties of entities defined in this example are omitted to show the overall structure of a CSDL schema.

<?xml version="1.0" encoding="utf-8"?>
<Schema xmlns="https://schemas.microsoft.com/ado/2006/04/edm" 
        Namespace="MyCompany.LOBSchema" Alias="Self">

    <Documentation>
      <Summary>Conceptual schema (csdl)</Summary>
      <LongDescription>This schema is an example showing 
        general syntax.</LongDescription>
    </Documentation>

    <EntityType Name="Customer">
        <Key>
            <PropertyRef Name="CustomerId" />
        </Key>
        <Property Name="CustomerId" Type="Guid" Nullable="false" />
        <!-- Other properties-->
    </EntityType>

    <EntityType Name="Order">
        <Key>
            <PropertyRef Name="OrderId" />
        </Key>
        <Property Name="OrderId" Type="Guid" Nullable="false" />
        <!-- Other properties-->
    </EntityType>

    <Association Name="Customer_Order">
        <End Role="Customer" Type="Self.Customer" Multiplicity="0..1" />
        <End Role="Order" Type="Self.Order" Multiplicity="*" />
    </Association>

    <EntityContainer Name="LOBSchemaData">
        <EntitySet Name="Customers" EntityType="Self.Customer" />
        <EntitySet Name="Orders" EntityType="Self.Order" />
        <AssociationSet Name="Customer_Orders" Association="Self.Customer_Order">
            <End Role="Customer" EntitySet="Customers" />
            <End Role="Order" EntitySet="Orders" />
        </AssociationSet>
    </EntityContainer>
</Schema>

An alias for a schema defined in another CSDL file can be defined with the Using tag, so existing types in external schemas can be used in the namespace being defined without fully qualified syntax.

In complete schemas, entity declarations include properties. One of the properties is designated the Key property. The Key attribute of an EntityType specifies one or more properties of the entity as the Key. The Key can be a composite of more than one property. The Key uniquely identifies instances of an entity for all operations.

Within the openingEntityType tag of the following example, after the Name attribute is assigned for the entity, the Key attribute is assigned CustomerId. The Type attribute of the CustomerId Key property is set to Guid to specify a unique value for the Key. The declaration of the CustomerId property follows in the second line of this CSDL segment.

    <EntityType Name="Customer" >
        <Key>
            <PropertyRef Name="CustomerId" />
        </Key>
        <Property Name="CustomerId" Type="Guid" Nullable="false" />
        <Property Name="Title" Type="String" Nullable="false" />
    </EntityType>

The last line of the example declares a property named Title and assigns the Type of the Title property as String. The Title property identifies the customer's job role. The Title property cannot be Null, as specified by the constraint Nullability="false". The Default attribute of the String type of the Title property is set to "NewHire".

A composite key can be specified as shown in the following example.

<EntityType Name="EmployeePayHistory">
    <Key>
      <PropertyRef Name="EmployeeID" />
      <PropertyRef Name="RateChangeDate" />
    </Key>
    <Property Name="EmployeeID" Type="Int32" Nullable="false" />
    <Property Name="RateChangeDate" Type="DateTime" Nullable="false"/>
    <Property Name="Rate" Type="Decimal" Nullable="false"/>
    <Property Name="PayFrequency" Type="Boolean" Nullable="false" />
    <Property Name="ModifiedDate" Type="DateTime" Nullable="false" />
    <NavigationProperty Name="Employee"
Relationship="Adventureworks.FK_EmployeePayHistory_Employee_EmployeeID"
 FromRole="EmployeePayHistory" ToRole="Employee" />
  </EntityType>

Entity Container

Schemas that use the EDM define an entity container to specify the sets of data types that will be available in the namespace being defined. The entity container is the basis for the namespace in the programmable object model that will be built from the CSDL schema.

In the XML hierarchy, the EntityContainer element is separate from the Schema element even though the EntityContainer is defined in a schema. This is important in mapping the EntityContainerto storage. TheEntityContainer tags in the conceptual schema are mapped to corresponding EntityContainer tags in the storage metadata. Note that in the mapping file, the fully qualified name of the EntityContainerdoes not include the schema namespace name.

Entity sets model the classes of the programmable object model. Association sets define the scope of relationships. For more information on entity sets and association sets, see Entity Sets (EDM) and Association Sets (EDM).

The following schema segment contains theEntityContainer declaration for the LOBSchemaData namespace in the MyCompany.LOBSchema namespace.

    <EntityContainer Name="LOBSchemaData">
        <EntitySet Name="Customers" EntityType="Self.Customer"/>
        <EntitySet Name="Orders" EntityType="Self.Order"/>
        <AssociationSet Name="Customer_Orders" 
                          Association="Self.Customer_Order">
            <End Role="Customer" EntitySet="Customers"/>
            <End Role="Order" EntitySet="Orders"/>
        </AssociationSet>
    </EntityContainer>

This EntityContainer declaration includes all the entities and associations defined in the earlier code segments, now in the form of sets specified by EntitySet and AssociationSet tags.

When the specifications of this schema are implemented as data types, each instance of a Customer or Order will be a member of the appropriate EntitySet. This entity container defines sets of Customer and Order entities named in the plural forms: Customers and Orders. Developers can define their own naming conventions. For more information about how the names correspond to those in the storage metadata and mapping specification, see Schemas and Mapping Specification (Entity Framework).

The AssociationSet tags in the previous EntityContainerdeclaration specify an association set named Customer_Orders. This association set contains instances of the Customer_Order association.

These elements (EntityType, EntitySet, Association, AssociationSet, and EntityContainer) combine to form the basic structure of a schema. For more line-by-line information about declarations in schemas, see Schemas and Mapping Specification (Entity Framework).

Deployment

The EDM specification does not dictate the storage model used after the entity types are defined in CSDL. In the most common scenario, the data source is a relational database management system (RDBMS). Deployment of the storage model requires creating a database and tables that correspond to the entities defined in the schema. Implementation may also require foreign keys in the data tables and/or link tables to support associations.

The EDM can be used with an existing database by mapping the database and tables to EDM types. Existing programming object models can also be mapped to EDM types.

Share via

Schemas (EDM)

Entity Container

Deployment

See Also

Concepts

Other Resources

Additional resources