ADO.NET Entity Data Model

The Entity Data Model (EDM) is a set of concepts that describe the structure of data, regardless of its stored form. The EDM borrows from the Entity-Relationship Model described by Peter Chen in 1976, but it also builds on the Entity-Relationship Model and extends its traditional uses.

The EDM addresses the challenges that arise from having data stored in many forms. For example, consider a business that stores data in relational databases, text files, XML files, spreadsheets, and reports. This presents significant challenges in data modeling, application design, and data access. When designing a data-oriented application, the challenge is to write efficient and maintainable code without sacrificing efficient data access, storage, and scalability. When data has a relational structure, data access, storage, and scalability are very efficient, but writing efficient and maintainable code becomes more difficult. When data has an object structure, the trade-offs are reversed: Writing efficient and maintainable code comes at the cost of efficient data access, storage, and scalability. Even if the right balance between these trade-offs can be found, new challenges arise when data is moved from one form to another. The Entity Data Model addresses these challenges by describing the structure of data in terms of entities and relationships that are independent of any storage schema. This makes the stored form of data irrelevant to application design and development. And, because entities and relationships describe the structure of data as it is used in an application (not its stored form), they can evolve as an application evolves.

A conceptual model is a specific representation of the structure of data as entities and relationships, and is generally defined in a domain-specific language (DSL) that implements the concepts of the EDM. Conceptual schema definition language (CSDL) is an example of such a domain-specific language. Entities and relationships described in a conceptual model can be thought of as abstractions of objects and associations in an application. This allows developers to focus on the conceptual model without concern for the storage schema, and allows them to write code with efficiency and maintainability in mind. Meanwhile storage schema designers can focus on the efficiency of data access, storage, and scalability.

Topics in this section describe the concepts of the Entity Data Model. Any DSL that implements the EDM should include the concepts described here. Note that the ADO.NET Entity Framework uses CSDL to define conceptual models. For more information, see CSDL Specification.

Entity Data Model Key Concepts

Entity Type

The entity type is the fundamental building block for describing the structure of data with the Entity Data Model. In a conceptual model, entity types are constructed from properties and describe the structure of top-level concepts, such as a customers and orders in a business application. In the same way that a class definition in a computer program is a template for instances of the class, an entity type is a template for entities. An entity represents a specific object (such as a specific customer or order). Each entity must have a unique entity key within an entity set. An entity set is a collection of instances of a specific entity type. Entity sets (and association sets) are logically grouped in an entity container.

Inheritance is supported with entity types: that is, one entity type can be derived from another. For more information, see Entity Data Model: Inheritance.

Association Type

An association type (also called an association) is the fundamental building block for describing relationships in the Entity Data Model. In a conceptual model, an association represents a relationship between two entity types (such as Customer and Order). Every association has two association ends that specify the entity types involved in the association. Each association end also specifies an association end multiplicity that indicates the number of entities that can be at that end of the association. An association end multiplicity can have a value of one (1), zero or one (0..1), or many (*). Entities at one end of an association can be accessed through navigation properties, or through foreign keys if they are exposed on an entity type. For more information, see foreign key property.

In an application, an instance of an association represents a specific association (such as an association between an instance of Customer and instances of Order). Association instances are logically grouped in an association set. Association sets (and entity sets) are logically grouped in an entity container.

Property

Entity types contain properties that define their structure and characteristics. For example, a Customer entity type may have properties such as CustomerId, Name, and Address.

Properties in a conceptual model are analogous to properties defined on a class in a computer program. In the same way that properties on a class define the shape of the class and carry information about objects, properties in a conceptual model define the shape of an entity type and carry information about entity type instances.

A property can contain primitive data (such as a string, an integer, or a Boolean value), or structured data (such as a complex type). For more information, see Entity Data Model: Primitive Data Types.

Representations of a Conceptual Model

A conceptual model is a specific representation of the structure of some data as entities and relationships. One way to represent a conceptual model is with a diagram. The following diagram represents a conceptual model with three entity types (Book, Publisher, and Author) and two associations (PublishedBy and WrittenBy):

Diagram showing a conceptual model with three entity types.

This representation, however, has some shortcomings when it comes to conveying some details about the model. For example, property type and entity set information are not conveyed in the diagram. The richness of a conceptual model can be conveyed more clearly with a domain-specific language (DSL). The ADO.NET Entity Framework uses an XML-based DSL called conceptual schema definition language (CSDL) to define conceptual models. The following is the CSDL definition of the conceptual model in the diagram above:

XML

  <Schema xmlns="http://schemas.microsoft.com/ado/2008/09/edm"
          xmlns:cg="http://schemas.microsoft.com/ado/2006/04/codegeneration"
          xmlns:store="http://schemas.microsoft.com/ado/2007/12/edm/EntityStoreSchemaGenerator"
          Namespace="BooksModel" Alias="Self">
    <EntityContainer Name="BooksContainer" >
      <EntitySet Name="Books" EntityType="BooksModel.Book" />
      <EntitySet Name="Publishers" EntityType="BooksModel.Publisher" />
      <EntitySet Name="Authors" EntityType="BooksModel.Author" />
      <AssociationSet Name="PublishedBy" Association="BooksModel.PublishedBy">
        <End Role="Book" EntitySet="Books" />
        <End Role="Publisher" EntitySet="Publishers" />
      </AssociationSet>
      <AssociationSet Name="WrittenBy" Association="BooksModel.WrittenBy">
        <End Role="Book" EntitySet="Books" />
        <End Role="Author" EntitySet="Authors" />
      </AssociationSet>
    </EntityContainer>
    <EntityType Name="Book">
      <Key>
        <PropertyRef Name="ISBN" />
      </Key>
      <Property Type="String" Name="ISBN" Nullable="false" />
      <Property Type="String" Name="Title" Nullable="false" />
      <Property Type="Decimal" Name="Revision" Nullable="false" Precision="29" Scale="29" />
      <NavigationProperty Name="Publisher" Relationship="BooksModel.PublishedBy"
                          FromRole="Book" ToRole="Publisher" />
      <NavigationProperty Name="Authors" Relationship="BooksModel.WrittenBy"
                          FromRole="Book" ToRole="Author" />
    </EntityType>
    <EntityType Name="Publisher">
      <Key>
        <PropertyRef Name="Id" />
      </Key>
      <Property Type="Int32" Name="Id" Nullable="false" />
      <Property Type="String" Name="Name" Nullable="false" />
      <Property Type="String" Name="Address" Nullable="false" />
      <NavigationProperty Name="Books" Relationship="BooksModel.PublishedBy"
                          FromRole="Publisher" ToRole="Book" />
    </EntityType>
    <EntityType Name="Author">
      <Key>
        <PropertyRef Name="Name" />
        <PropertyRef Name="Address" />
      </Key>
      <Property Type="String" Name="Name" Nullable="false" />
      <Property Type="String" Name="Address" Nullable="false" />
      <NavigationProperty Name="Books" Relationship="BooksModel.WrittenBy"
                          FromRole="Author" ToRole="Book" />
    </EntityType>
<Association Name="PublishedBy">
      <End Type="BooksModel.Book" Role="Book" Multiplicity="*" />
      <End Type="BooksModel.Publisher" Role="Publisher" Multiplicity="1" />
    </Association>
    <Association Name="WrittenBy">
      <End Type="BooksModel.Book" Role="Book" Multiplicity="*" />
      <End Type="BooksModel.Author" Role="Author" Multiplicity="*" />
    </Association>
  </Schema>

Entity Data Model: Namespaces

A namespace in the Entity Data Model (EDM) is an abstract container for entity types, complex types, and associations. Namespaces in the EDM are similar to namespaces in a programming language: they provide context for the objects that they contain and they provide a way to disambiguate objects that have the same name (but are contained in different namespaces).

Example

The ADO.NET Entity Framework uses a domain-specific language (DSL) called conceptual schema definition language (CSDL) to define conceptual models. The following CSDL code uses a namespace to identify a type that is defined in a different conceptual model. The example defines an entity type (Publisher) that has a complex type property (Address) that is imported from the ExtendedBooksModel namespace. Note that the Using element indicates that a namespace has been imported. Also note that the type of the Address property is defined by using its fully qualified name (ExtendedBooksModel.Address), indicating that this type is defined in the ExtendedBooksModel namespace.

XML

  <Schema xmlns="http://schemas.microsoft.com/ado/2008/09/edm"
          xmlns:cg="http://schemas.microsoft.com/ado/2006/04/codegeneration"
          xmlns:store="http://schemas.microsoft.com/ado/2007/12/edm/EntityStoreSchemaGenerator"
          Namespace="BooksModel" Alias="Self">

    <Using Namespace="BooksModel.Extended" Alias="BMExt" />
    
<EntityContainer Name="BooksContainer" >
      <EntitySet Name="Publishers" EntityType="BooksModel.Publisher" />
    </EntityContainer>
    
<EntityType Name="Publisher">
      <Key>
        <PropertyRef Name="Id" />
      </Key>
      <Property Type="Int32" Name="Id" Nullable="false" />
      <Property Type="String" Name="Name" Nullable="false" />
      <Property Type="BMExt.Address" Name="Address" Nullable="false" />
    </EntityType>
  
</Schema>

Entity Data Model: Primitive Data Types

The Entity Data Model (EDM) supports a set of abstract primitive data types (such as String, Boolean, Int32, and so on) that are used to define properties in a conceptual model. These primitive data types are proxies for actual primitive data types that are supported in the storage or hosting environment, such as a SQL Server database or the common language runtime (CLR). The EDM does not define the semantics of operations or conversions over primitive data types; these semantics are defined by the storage or hosting environment. Typically, primitive data types in the EDM are mapped to corresponding primitive data types in the storage or hosting environment. For information about how the Entity Framework maps primitive types in the EDM to SQL Server data types, see SqlClient for Entity FrameworkTypes.

Note

The EDM does not support collections of primitive data types.

For information about structured data types in the EDM, see entity type and complex type.

Primitive Data Types Supported in the Entity Data Model

The table below lists the primitive data types supported by the EDM. The table also lists the facets that can be applied to each primitive data type.

Primitive Data Type	Description	Applicable Facets
Binary	Contains binary data.	MaxLength, FixedLength, Nullable, Default
Boolean	Contains the value true or false.	Nullable, Default
Byte	Contains an unsigned 8-bit integer value.	Precision, Nullable, Default
DateTime	Represents a date and time.	Precision, Nullable, Default
DateTimeOffset	Contains a date and time as an offset in minutes from GMT.	Precision, Nullable, Default
Decimal	Contains a numeric value with fixed precision and scale.	Precision, Nullable, Default
Double	Contains a floating point number with 15 digit precision.	Precision, Nullable, Default
Float	Contains a floating point number with seven digit precision.	Precision, Nullable, Default
Guid	Contains a 16-byte unique identifier.	Precision, Nullable, Default
Int16	Contains a signed 16-bit integer value.	Precision, Nullable, Default
Int32	Contains a signed 32-bit integer value.	Precision, Nullable, Default
Int64	Contains a signed 64-bit integer value.	Precision, Nullable, Default
SByte	Contains a signed 8-bit integer value.	Precision, Nullable, Default
String	Contains character data.	Unicode, FixedLength, MaxLength, Collation, Precision, Nullable, Default
Time	Contains a time of day.	Precision, Nullable, Default

Entity Data Model: Inheritance

The Entity Data Model (EDM) supports inheritance for entity types. Inheritance in the EDM is similar to inheritance for classes in object-oriented programming languages. Like with classes in object-oriented languages, in a conceptual model you can define an entity type (a derived type) that inherits from another entity type (the base type). However, unlike classes in object-oriented programming, in a conceptual model the derived type always inherits all the properties and navigation properties of the base type. You cannot override inherited properties in a derived type.

In a conceptual model you can build inheritance hierarchies in which a derived type inherits from another derived type. The type at the top of the hierarchy (the one type in the hierarchy that is not a derived type) is called the root type. In an inheritance hierarchy, the entity key must be defined on the root type.

You cannot build inheritance hierarchies in which a derived type inherits from more than one type. For example, in a conceptual model with a Book entity type, you could define derived types FictionBook and NonFictionBook that each inherit from Book. However, you could not then define a type that inherits from both the FictionBook and NonFictionBook types.

Example

The following diagram shows a conceptual model with four entity types: Book, FictionBook, Publisher, and Author. The FictionBook entity type is a derived type, inheriting from the Book entity type. The FictionBook type inherits the ISBN (Key), Title, and Revision properties, and defines an additional property called Genre.

Diagram that shows a conceptual model with four entity types.

XML

<EntityType Name="FictionBook" BaseType="BooksModel.Book" >
  <Property Type="String" Name="Genre" Nullable="false" />
</EntityType>

association end

An association end identifies the entity type on one end of an association and the number of entity type instances that can exist at that end of an association. Association ends are defined as part of an association; an association must have exactly two association ends. Navigation properties allow for navigation from one association end to the other.

An association end definition contains the following information:

One of the entity types involved in the association. (Required)

Note

For a given association, the entity type specified for each association end can be the same. This creates a self-association.
An association end multiplicity that indicates the number of entity type instances that can be at one end of the association. An association end multiplicity can have a value of one (1), zero or one (0..1), or many (*).
A name for the association end. (Optional)
Information about operations that are performed on the association end, such as cascade on delete. (Optional)

Example

The diagram below shows a conceptual model with two associations: PublishedBy and WrittenBy. The association ends for the PublishedBy association are the Book and Publisher entity types. The multiplicity of the Publisher end is one (1) and the multiplicity of the Book end is many (*), indicating that a publisher publishes many books and a book is published by one publisher.

Example model with three entity types

The ADO.NET Entity Framework uses a domain-specific language (DSL) called conceptual schema definition language (CSDL) to define conceptual models. The CSDL below defines the PublishedBy association shown in the diagram above. Note that the type, name, and multiplicity of each association end are specified by XML attributes (the Type, Role, and Multiplicity attributes, respectively). Optional information about operations performed on an end is specified in an XML element (the OnDelete element). In this case, if a publisher is deleted, so are all associated books.

XML

  <Association Name="PublishedBy">
    <End Type="BooksModel.Book" Role="Book" Multiplicity="*" />
    <End Type="BooksModel.Publisher" Role="Publisher" Multiplicity="1" >
  <OnDelete Action="Cascade" />
</End>
  </Association>

association end multiplicity

Association end multiplicity defines the number of entity type instances that can be at one end of an association.

An association end multiplicity can have one of the following values:

one (1): Indicates that exactly one entity type instance exists at the association end.
zero or one (0..1): Indicates that zero or one entity type instances exist at the association end.
many (*): Indicates that zero, one, or more entity type instances exist at the association end.

An association is often characterized by its association end multiplicities. For example, if the ends of an association have multiplicities one (1) and many (*), the association is called a one-to-many association. In the example below, the PublishedBy association is a one-to-many association (a publisher publishes many books and a book is published by one publisher). The WrittenBy association is a many-to-many association (a book can have multiple authors and an author can write multiple books).

Example

Example model with three entity types

XML

<Association Name="PublishedBy">
      <End Type="BooksModel.Book" Role="Book" Multiplicity="*" />
      <End Type="BooksModel.Publisher" Role="Publisher" Multiplicity="1" />
    </Association>

association set

An association set is a logical container for association instances of the same type. An association set is not a data modeling construct; that is, it does not describe the structure of data or relationships. Instead, an association set provides a construct for a hosting or storage environment (such as the common language runtime or a SQL Server database) to group association instances so that they can be mapped to a data store.

An association set is defined within an entity container, which is a logical grouping of entity sets and association sets.

A definition for an association set contains the following information:

The association set name. (Required)
The association of which it will contain instances. (Required)
Two association set ends.

Example

The diagram below shows a conceptual model with two associations: PublishedBy, and WrittenBy. Although information about association sets is not conveyed in the diagram, the next diagram shows an example of association sets and entity sets based on this model.

Example model with three entity types

The following example shows an association set (PublishedBy) and two entity sets (Books and Publishers) based on the conceptual model shown above. Bi in the Books entity set represents an instance of the Book entity type at run time. Similarly, Pj represents a Publisher instance in the Publishers entity set. BiPj represents an instance of the PublishedBy association in the PublishedBy association set.

Screenshot that shows a Sets example.

The ADO.NET Entity Framework uses a domain-specific language (DSL) called conceptual schema definition language (CSDL) to define conceptual models. The following CSDL defines an entity container with one association set for each association in the diagram above. Note that the name and association for each association set are defined using XML attributes.

XML

<EntityContainer Name="BooksContainer" >
  <EntitySet Name="Books" EntityType="BooksModel.Book" />
  <EntitySet Name="Publishers" EntityType="BooksModel.Publisher" />
  <EntitySet Name="Authors" EntityType="BooksModel.Author" />
  <AssociationSet Name="PublishedBy" Association="BooksModel.PublishedBy">
    <End Role="Book" EntitySet="Books" />
    <End Role="Publisher" EntitySet="Publishers" />
  </AssociationSet>
  <AssociationSet Name="WrittenBy" Association="BooksModel.WrittenBy">
    <End Role="Book" EntitySet="Books" />
    <End Role="Author" EntitySet="Authors" />
  </AssociationSet>
</EntityContainer>

It is possible to define multiple association sets per association, as long as no two association sets share an association set end. The following CSDL defines an entity container with two association sets for the WrittenBy association. Notice that multiple entity sets have been defined for the Book and Author entity types and that no association set shares an association set end.

XML

<EntityContainer Name="BooksContainer" >
  <EntitySet Name="Books" EntityType="BooksModel.Book" />
  <EntitySet Name="FictionBooks" EntityType="BooksModel.Book" />
  <EntitySet Name="Publishers" EntityType="BooksModel.Publisher" />
  <EntitySet Name="Authors" EntityType="BooksModel.Author" />
  <EntitySet Name="FictionAuthors" EntityType="BooksModel.Author" />
  <AssociationSet Name="PublishedBy" Association="BooksModel.PublishedBy">
    <End Role="Book" EntitySet="Books" />
    <End Role="Publisher" EntitySet="Publishers" />
  </AssociationSet>
  <AssociationSet Name="WrittenBy" Association="BooksModel.WrittenBy">
    <End Role="Book" EntitySet="Books" />
    <End Role="Author" EntitySet="Authors" />
  </AssociationSet>
  <AssociationSet Name="FictionWrittenBy" Association="BooksModel.WrittenBy">
    <End Role="Book" EntitySet="FictionBooks" />
    <End Role="Author" EntitySet="FictionAuthors" />
  </AssociationSet>
</EntityContainer>

association set end

An association set end identifies the entity type and the entity set at the end of an association set. Association set ends are defined as part of an association set; an association set must have exactly two association set ends.

An association set end definition contains the following information:

One of the entity types involved in the association set. (Required)
The entity set for the entity type involved in the association set. (Required)

Example

The diagram below shows a conceptual model with two associations: WrittenBy and PublishedBy.

Example model with three entity types

The following diagram shows an association set (PublishedBy) and two entity sets (Books and Publishers) based on the conceptual model shown above. The association set ends are the Books and Publishers entity sets. Bi in the Books entity set represents an instance of the Book entity type at run time. Similarly, Pj represents a Publisher instance in the Publishers entity set. BiPj represents an instance of the PublishedBy association in the PublishedBy association set.

Screenshot that shows a Sets example.

The ADO.NET Entity Framework uses a DSL called conceptual schema definition language (CSDL) to define conceptual models. The following CSDL defines an entity container with one association set for each association in the diagram above. Note that association set ends are defined as part of each association set definition.

XML

<EntityContainer Name="BooksContainer" >
  <EntitySet Name="Books" EntityType="BooksModel.Book" />
  <EntitySet Name="Publishers" EntityType="BooksModel.Publisher" />
  <EntitySet Name="Authors" EntityType="BooksModel.Author" />
  <AssociationSet Name="PublishedBy" Association="BooksModel.PublishedBy">
    <End Role="Book" EntitySet="Books" />
    <End Role="Publisher" EntitySet="Publishers" />
  </AssociationSet>
  <AssociationSet Name="WrittenBy" Association="BooksModel.WrittenBy">
    <End Role="Book" EntitySet="Books" />
    <End Role="Author" EntitySet="Authors" />
  </AssociationSet>
</EntityContainer>

association type

An association type (also called an association) is the fundamental building block for describing relationships in the Entity Data Model (EDM). In a conceptual model, an association represents a relationship between two entity types (such as Customer and Order). In an application, an instance of an association represents a specific association (such as an association between an instance of Customer and an instance of Order). Association instances are logically grouped in an association set.

An association definition contains the following information:

A unique name. (Required)
Two association ends, one for each entity type in the relationship. (Required)

Note

An association cannot represent a relationship among more than two entity types. An association can, however, define a self-relationship by specifying the same entity type for each of its association ends.
A referential integrity constraint. (Optional)

Each association end must specify an association end multiplicity that indicates the number of entity type instances that can be at one end of the association. An association end multiplicity can have a value of one (1), zero or one (0..1), or many (*). Entity type instances at one end of an association can be accessed through navigation properties or foreign keys if they are exposed on an entity type. For more information, see Entity Data Model: Foreign Keys.

Example

Example model with three entity types

XML

<Association Name="PublishedBy">
      <End Type="BooksModel.Book" Role="Book" Multiplicity="*" />
      <End Type="BooksModel.Publisher" Role="Publisher" Multiplicity="1" />
    </Association>

complex type

A complex type is a template for defining rich, structured properties on entity types or on other complex types. Each template contains the following:

A unique name. (Required)

Note

The name of a complex type cannot be the same as an entity type name within the same namespace.
Data in the form of one or more properties. (Optional.)

Note

A property of a complex type can be another complex type.

A complex type is similar to an entity type in that a complex type can carry a data payload in the form of primitive type properties or other complex types. However, there are some key differences between complex types and entity types:

Complex types do not have identities and therefore cannot exist independently. Complex types can only exist as properties on entity types or other complex types.
Complex types cannot participate in associations. Neither end of an association can be a complex type, and therefore navigation properties cannot be defined on complex types.

Example

The ADO.NET Entity Framework uses a domain-specific language (DSL) called conceptual schema definition language (CSDL) to define conceptual models. The following CSDL defines a complex type, Address, with the primitive type properties StreetAddress, City, StateOrProvince, Country, and PostalCode.

XML

<ComplexType Name="Address" >
  <Property Type="String" Name="StreetAddress" Nullable="false" />
  <Property Type="String" Name="City" Nullable="false" />
  <Property Type="String" Name="StateOrProvince" Nullable="false" />
  <Property Type="String" Name="Country" Nullable="false" />
  <Property Type="String" Name="PostalCode" Nullable="false" />
</ComplexType>

To define the complex type Address (above) as a property on an entity type, you must declare the property type in the entity type definition. The following CSDL declares the Address property as a complex type on an entity type (Publisher):

XML

<EntityType Name="Publisher">
      <Key>
        <PropertyRef Name="Id" />
      </Key>
      <Property Type="Int32" Name="Id" Nullable="false" />
      <Property Type="String" Name="Name" Nullable="false" />
      <Property Type="BooksModel.Address" Name="Address" Nullable="false" />
      <NavigationProperty Name="Books" Relationship="BooksModel.PublishedBy"
                          FromRole="Publisher" ToRole="Book" />
    </EntityType>

entity container

An entity container is a logical grouping of entity sets, association sets, and function imports.

The following must be true of an entity container defined in a conceptual model:

At least one entity container must be defined in each conceptual model.
The entity container must have a unique name within each conceptual model.

An entity container can define entity sets or association sets that use entity types or associations defined in one or more namespaces. For more information, see Entity Data Model: Namespaces.

Example

The diagram below shows a conceptual model with three entity types: Book, Publisher, and Author. See the next example for more information.

Example model with three entity types

Although the diagram does not convey entity container information, the conceptual model must define an entity container. The ADO.NET Entity Framework uses a DSL called conceptual schema definition language (CSDL) to define conceptual models. The following CSDL defines an entity container for the conceptual model shown in the diagram above. Note that the entity container name is defined in an XML attribute.

XML

<EntityContainer Name="BooksContainer" >
  <EntitySet Name="Books" EntityType="BooksModel.Book" />
  <EntitySet Name="Publishers" EntityType="BooksModel.Publisher" />
  <EntitySet Name="Authors" EntityType="BooksModel.Author" />
  <AssociationSet Name="PublishedBy" Association="BooksModel.PublishedBy">
    <End Role="Book" EntitySet="Books" />
    <End Role="Publisher" EntitySet="Publishers" />
  </AssociationSet>
  <AssociationSet Name="WrittenBy" Association="BooksModel.WrittenBy">
    <End Role="Book" EntitySet="Books" />
    <End Role="Author" EntitySet="Authors" />
  </AssociationSet>
</EntityContainer>

entity key

An entity key is a property or a set of properties of an entity type that are used to determine identity. The properties that make up an entity key are chosen at design time. The values of entity key properties must uniquely identify an entity type instance within an entity set at run time. The properties that make up an entity key should be chosen to guarantee uniqueness of instances in an entity set.

The following are the requirements for a set of properties to be an entity key:

No two entity keys within an entity set can be identical. That is, for any two entities within an entity set, the values for all of the properties that constitute a key cannot be the same. However, some (but not all) of the values that make up an entity key can be the same.
An entity key must consist of a set of non-nullable, immutable, primitive type properties.
The properties that make up an entity key for a given entity type cannot change. You cannot allow more than one possible entity key for a given entity type; surrogate keys are not supported.
When an entity is involved in an inheritance hierarchy, the root entity must contain all the properties that make up the entity key, and the entity key must be defined on the root entity type. For more information, see Entity Data Model: Inheritance.

Example

The diagram below shows a conceptual model with three entity types: Book, Publisher, and Author. The properties of each entity type that make up its entity key are denoted with "(Key)". Note that the Author entity type has an entity key that consists of two properties, Name and Address.

Example model with three entity types

XML

<EntityType Name="Book">
  <Key>
    <PropertyRef Name="ISBN" />
  </Key>
  <Property Type="String" Name="ISBN" Nullable="false" />
  <Property Type="String" Name="Title" Nullable="false" />
  <Property Type="Decimal" Name="Revision" Nullable="false" Precision="29" Scale="29" />
  <NavigationProperty Name="Publisher" Relationship="BooksModel.PublishedBy"
                      FromRole="Book" ToRole="Publisher" />
  <NavigationProperty Name="Authors" Relationship="BooksModel.WrittenBy"
                      FromRole="Book" ToRole="Author" />
</EntityType>

The ISBN property is a good choice for the entity key because an International Standard Book Number (ISBN) uniquely identifies a book.

The CSDL below defines the Author entity type shown in the diagram above. Note that the entity key consists of two properties, Name and Address.

XML

<EntityType Name="Author">
  <Key>
    <PropertyRef Name="Name" />
    <PropertyRef Name="Address" />
  </Key>
  <Property Type="String" Name="Name" Nullable="false" />
  <Property Type="String" Name="Address" Nullable="false" />
  <NavigationProperty Name="Books" Relationship="BooksModel.WrittenBy"
                      FromRole="Author" ToRole="Book" />
</EntityType>

Using Name and Address for the entity key is a reasonable choice, because two authors of the same name are unlikely to live at the same address. However, this choice for an entity key does not absolutely guarantee unique entity keys in an entity set. Adding a property, such as AuthorId, that could be used to uniquely identify an author would be recommended in this case.

entity set

An entity set is a logical container for instances of an entity type and instances of any type derived from that entity type. (For information about derived types, see Entity Data Model: Inheritance.) The relationship between an entity type and an entity set is analogous to the relationship between a row and a table in a relational database: Like a row, an entity type describes data structure, and, like a table, an entity set contains instances of a given structure. An entity set is not a data modeling construct; it does not describe the structure of data. Instead, an entity set provides a construct for a hosting or storage environment (such as the common language runtime or a SQL Server database) to group entity type instances so that they can be mapped to a data store.

An entity set is defined within an entity container, which is a logical grouping of entity sets and association sets.

For an entity type instance to exist in an entity set, the following must be true:

The type of the instance is either the same as the entity type on which the entity set is based, or the type of the instance is a subtype of the entity type.
The entity key for the instance is unique within the entity set.
The instance does not exist in any other entity set.

Note

Multiple entity sets can be defined using the same entity type, but an instance of a given entity type can only exist in one entity set.

You do not have to define an entity set for each entity type in a conceptual model.

Example

The diagram below shows a conceptual model with three entity types: Book, Publisher, and Author.

Example model with three entity types

The following diagram shows two entity sets (Books and Publishers) and an association set (PublishedBy) based on the conceptual model shown above. Bi in the Books entity set represents an instance of the Book entity type at run time. Similarly, Pj represent a Publisher instance in the Publishers entity set. BiPj represents an instance of the PublishedBy association in the PublishedBy association set.

Screenshot that shows a Sets example.

The ADO.NET Entity Framework uses a domain-specific language (DSL) called conceptual schema definition language (CSDL) to define conceptual models. The following CSDL defines an entity container with one entity set for each entity type in the conceptual model shown above. Note that the name and entity type for each entity set are defined using XML attributes.

XML

<EntityContainer Name="BooksContainer" >
  <EntitySet Name="Books" EntityType="BooksModel.Book" />
  <EntitySet Name="Publishers" EntityType="BooksModel.Publisher" />
  <EntitySet Name="Authors" EntityType="BooksModel.Author" />
  <AssociationSet Name="PublishedBy" Association="BooksModel.PublishedBy">
    <End Role="Book" EntitySet="Books" />
    <End Role="Publisher" EntitySet="Publishers" />
  </AssociationSet>
  <AssociationSet Name="WrittenBy" Association="BooksModel.WrittenBy">
    <End Role="Book" EntitySet="Books" />
    <End Role="Author" EntitySet="Authors" />
  </AssociationSet>
</EntityContainer>

It is possible to define multiple entity sets per type (MEST). The following CSDL defines an entity container with two entity sets for the Book entity type:

XML

<EntityContainer Name="BooksContainer" >
  <EntitySet Name="Books" EntityType="BooksModel.Book" />
  <EntitySet Name="FictionBooks" EntityType="BooksModel.Book" />
  <EntitySet Name="Publishers" EntityType="BooksModel.Publisher" />
  <EntitySet Name="Authors" EntityType="BooksModel.Author" />
  <AssociationSet Name="PublishedBy" Association="BooksModel.PublishedBy">
    <End Role="Book" EntitySet="Books" />
    <End Role="Publisher" EntitySet="Publishers" />
  </AssociationSet>
  <AssociationSet Name="BookAuthor" Association="BooksModel.BookAuthor">
    <End Role="Book" EntitySet="Books" />
    <End Role="Author" EntitySet="Authors" />
  </AssociationSet>
</EntityContainer>

entity type

The entity type is the fundamental building block for describing the structure of data with the Entity Data Model (EDM). In a conceptual model, an entity type represents the structure of top-level concepts, such as customers or orders. An entity type is a template for entity type instances. Each template contains the following information:

A unique name. (Required.)
An entity key defined by one or more properties. (Required.)
Data in the form of properties. (Optional.)
Navigation properties that allow for navigation from one end of an association to the other end. (Optional)

In an application, an instance of an entity type represents a specific object (such as a specific customer or order). Each instance of an entity type must have a unique entity key within an entity set.

Two entity type instances are considered equal only if they are of the same type and the values of their entity keys are the same.

Example

The diagram below shows a conceptual model with three entity types: Book, Publisher, and Author:

Example model with three entity types

Note that the properties of each entity type that make up its entity key are denoted with "(Key)".

XML

<EntityType Name="Book">
  <Key>
    <PropertyRef Name="ISBN" />
  </Key>
  <Property Type="String" Name="ISBN" Nullable="false" />
  <Property Type="String" Name="Title" Nullable="false" />
  <Property Type="Decimal" Name="Revision" Nullable="false" Precision="29" Scale="29" />
  <NavigationProperty Name="Publisher" Relationship="BooksModel.PublishedBy"
                      FromRole="Book" ToRole="Publisher" />
  <NavigationProperty Name="Authors" Relationship="BooksModel.WrittenBy"
                      FromRole="Book" ToRole="Author" />
</EntityType>

facet

A facet is used to add detail to a primitive type property definition. A property definition contains information about the property type, but often more detail is necessary. For example, an entity type in a conceptual model might have a property of type String whose value cannot be set to null. Facets allow you to specify this level of detail.

The table below describes the facets that are supported in the EDM.

Note

The exact values and behaviors of facets are determined by the run-time environment that uses an EDM implementation.

Facet	Description	Applies to
Collation	Specifies the collating sequence (or sorting sequence) to be used when performing comparison and ordering operations on values of the property.	String
ConcurrencyMode	Indicates that the value of the property should be used for optimistic concurrency checks.	All primitive type properties
Default	Specifies the default value of the property if no value is supplied upon instantiation.	All primitive type properties
FixedLength	Specifies whether the length of the property value can vary.	Binary, String
MaxLength	Specifies the maximum length of the property value.	Binary, String
Nullable	Specifies whether the property can have a null value.	All primitive type properties
Precision	For properties of type Decimal, specifies the number of digits a property value can have. For properties of type Time, DateTime, and DateTimeOffset, specifies the number of digits for the fractional part of seconds of the property value.	DateTime, DateTimeOffset, Decimal, Time,
Scale	Specifies the number of digits to the right of the decimal point for the property value.	Decimal
Unicode	Indicates whether the property value is stored as Unicode.	String

Example

The ADO.NET Entity Framework uses a domain-specific language (DSL) called conceptual schema definition language (CSDL) to define conceptual models. The following CSDL defines a Book entity type. Note that facets are implemented as XML attributes. The facet values indicate that no property can be set to null, and that the Scale and Precision of the Revision property are each set to 29.

XML

<EntityType Name="Book">
  <Key>
    <PropertyRef Name="ISBN" />
  </Key>
  <Property Type="String" Name="ISBN" Nullable="false" />
  <Property Type="String" Name="Title" Nullable="false" />
  <Property Type="Decimal" Name="Revision" Nullable="false" Precision="29" Scale="29" />
  <NavigationProperty Name="Publisher" Relationship="BooksModel.PublishedBy"
                      FromRole="Book" ToRole="Publisher" />
  <NavigationProperty Name="Authors" Relationship="BooksModel.WrittenBy"
                      FromRole="Book" ToRole="Author" />
</EntityType>

foreign key property

A foreign key property in the Entity Data Model (EDM) is a primitive type property (or a set of primitive type properties) on an entity type that contains the entity key of another entity type.

A foreign key property is analogous to a foreign key column in a relational database. In the same way that foreign key columns are used in a relational database to create relationships between rows in tables, foreign key properties in a conceptual model are used to establish associations between entity types. A referential integrity constraint is used to define an association between two entity types when one of the types has a foreign key property.

Example

The diagram below shows a conceptual model with three entity types: Book, Publisher, and Author. The Book entity type has a property, PublisherId, that references the entity key of the Publisher entity type when you define a referential integrity constraint on the PublishedBy association.

RefConstraintModel

The ADO.NET Entity Framework uses a domain-specific language (DSL) called conceptual schema definition language (CSDL) to define conceptual models. The following CSDL uses the foreign key property PublisherId to define a referential integrity constraint on the PublishedBy association shown in the conceptual model shown above.

XML

<Association Name="PublishedBy">
  <End Type="BooksModel.Book" Role="Book" Multiplicity="*" >
  </End>
  <End Type="BooksModel.Publisher" Role="Publisher" Multiplicity="1" />
  <ReferentialConstraint>
    <Principal Role="Publisher">
      <PropertyRef Name="Id" />
    </Principal>
    <Dependent Role="Book">
      <PropertyRef Name="PublisherId" />
    </Dependent>
  </ReferentialConstraint>
</Association>

model-declared function

A model-declared function is a function that is declared in a conceptual model, but is not defined in that conceptual model. The function might be defined in the hosting or storage environment. For example, a model-declared function might be mapped to a function that is defined in a database, thus exposing server-side functionality in the conceptual model.

The declaration of a model-declared function contains the following information:

The name of the function. (Required)
The type of the return value. (Optional)

Note

If no return value is specified, the return type is void.
Parameter information, including parameter name and type. (Optional)

Example

The ADO.NET Entity Framework uses a domain-specific language (DSL) called conceptual schema definition language (CSDL) to define conceptual models. In CSDL, one implementation of a model-declared function is a function import (using the FunctionImport element). The following CSDL defines an entity container with a function import definition. Note that the return type for the function is void since no return type is specified.

XML

<FunctionImport Name="UpdatePublisher">
  <Parameter Name="PublisherId" Mode="In" Type="Int32" />
  <Parameter Name="PublisherName" Mode="In" Type="String" />
</FunctionImport>

model-defined function

A model-defined function is a function that is defined in a conceptual model. The body of a model-defined function is expressed in Entity SQL, which allows for the function to be expressed independently of rules or languages supported in the data source.

A definition for a model-defined function contains the following information:

A function name. (Required)
The type of the return value. (Optional)

Note

If no return type is specified, the return value is void.
Parameter information. (Optional)
An Entity SQL expression that defines the body of the function.

Note that model-defined functions do not support output parameters. This restriction is in place so that model-defined functions can be composed.

Example

The diagram below shows a conceptual model with three entity types: Book, Publisher, and Author.

Screenshot that shows a model with published date.

The ADO.NET Entity Framework uses a domain-specific language (DSL) called conceptual schema definition language (CSDL) to define conceptual models. The following CSDL defines a function in the conceptual model that returns the numbers of years since an instance of a Book (in the diagram above) was published.

XML

<Function Name="GetYearsInPrint" ReturnType="Edm.Int32" >
      <Parameter Name="book" Type="BooksModel.Book" />
      <DefiningExpression>
        Year(CurrentDateTime()) - Year(cast(book.PublishedDate as DateTime))
      </DefiningExpression>
    </Function>

Navigation property

A navigation property is an optional property on an entity type that allows for navigation from one end of an association to the other end. Unlike other properties, navigation properties do not carry data.

A navigation property definition includes the following:

A name. (Required)
The association that it navigates. (Required)
The ends of the association that it navigates. (Required)

Note that navigation properties are optional on both entity types at the ends of an association. If you define a navigation property on one entity type at the end of an association, you do not have to define a navigation property on the entity type at the other end of the association.

The data type of a navigation property is determined by the multiplicity of its remote association end. For example, suppose a navigation property, OrdersNavProp, exists on a Customer entity type and navigates a one-to-many association between Customer and Order. Because the remote association end for the navigation property has multiplicity of many (*), its data type is a collection (of Order). Similarly, if a navigation property, CustomerNavProp, exists on the Order entity type, its data type would be Customer, because the multiplicity of the remote end is one (1).

Example

The diagram below shows a conceptual model with three entity types: Book, Publisher, and Author. Navigation properties, Publisher and Authors, are defined on the Book entity type. Navigation property Books is defined on both the Publisher entity type and the Author entity type.

Diagram showing a conceptual model with three entity types.

XML

<EntityType Name="Book">
  <Key>
    <PropertyRef Name="ISBN" />
  </Key>
  <Property Type="String" Name="ISBN" Nullable="false" />
  <Property Type="String" Name="Title" Nullable="false" />
  <Property Type="Decimal" Name="Revision" Nullable="false" Precision="29" Scale="29" />
  <NavigationProperty Name="Publisher" Relationship="BooksModel.PublishedBy"
                      FromRole="Book" ToRole="Publisher" />
  <NavigationProperty Name="Authors" Relationship="BooksModel.WrittenBy"
                      FromRole="Book" ToRole="Author" />
</EntityType>

Note that XML attributes are used to communicate the information necessary to define a navigation property: The attribute Name contains the name of the property, Relationship contains the name of the association it navigates, and FromRole and ToRole contain the ends of the association.

property

Properties are the fundamental building blocks of entity types and complex types. Properties define the shape and characteristics of data that an entity type instance or complex type instance will contain. Properties in a conceptual model are analogous to properties defined on a class. In the same way that properties on a class define the shape of the class and carry information about objects, properties in a conceptual model define the shape of an entity type and carry information about entity type instances.

Note

Properties, as described in this topic, are different from navigation properties. For more information, see navigation properties.

A property definition contains the following information:

A property name. (Required)
A property type. (Required)
A set of facets. (Optional)

A property can contain primitive data (such as a string, an integer, or a Boolean value), or structured data (such as a complex type). Properties that are of primitive type are also called scalar properties. For more information, see Entity Data Model: Primitive Data Types.

Note

A complex type can, itself, have properties that are complex types.

Example

The diagram below shows a conceptual model with three entity types: Book, Publisher, and Author. Each entity type has several properties, although type information for each property is not conveyed in the diagram. Properties that are entity keys are denoted with (Key).

Example model with three entity types

The ADO.NET Entity Framework uses a domain-specific language (DSL) called conceptual schema definition language (CSDL) to define conceptual models. The following CSDL defines the Book entity type (as shown in the diagram above) and indicates the type and name of each property by using XML attributes. An optional facet, Nullable, is also defined by using an XML attribute.

XML

<EntityType Name="Book">
  <Key>
    <PropertyRef Name="ISBN" />
  </Key>
  <Property Type="String" Name="ISBN" Nullable="false" />
  <Property Type="String" Name="Title" Nullable="false" />
  <Property Type="Decimal" Name="Revision" Nullable="false" Precision="29" Scale="29" />
  <NavigationProperty Name="Publisher" Relationship="BooksModel.PublishedBy"
                      FromRole="Book" ToRole="Publisher" />
  <NavigationProperty Name="Authors" Relationship="BooksModel.WrittenBy"
                      FromRole="Book" ToRole="Author" />
</EntityType>

It is possible that one of the properties shown in the diagram is a complex type property. For example, the Address property on the Publisher entity type could be a complex type property composed of several scalar properties, such as StreetAddress, City, StateOrProvince, Country, and PostalCode. The CSDL representation of such a complex type would be as follows:

XML

<ComplexType Name="Address" >
  <Property Type="String" Name="StreetAddress" Nullable="false" />
  <Property Type="String" Name="City" Nullable="false" />
  <Property Type="String" Name="StateOrProvince" Nullable="false" />
  <Property Type="String" Name="Country" Nullable="false" />
  <Property Type="String" Name="PostalCode" Nullable="false" />
</ComplexType>

referential integrity constraint

A referential integrity constraint in the Entity Data Model (EDM) is similar to a referential integrity constraint in a relational database. In the same way that a column (or columns) from a database table can reference the primary key of another table, a property (or properties) of an entity type can reference the entity key of another entity type. The entity type that is referenced is called the principal end of the constraint. The entity type that references the principal end is called the dependent end of the constraint.

A referential integrity constraint is defined as part of an association between two entity types. The definition for a referential integrity constraint specifies the following information:

The principal end of the constraint. (An entity type whose entity key is referenced by the dependent end.)
The entity key of the principal end.
The dependent end of the constraint. (An entity type that has a property or properties that reference the entity key of the principal end.)
The referencing property or properties of the dependent end.

The purpose of referential integrity constraints in the EDM is to ensure that valid associations always exist. For more information, see foreign key property.

Example

The diagram below shows a conceptual model with two associations: WrittenBy and PublishedBy. The Book entity type has a property, PublisherId, that references the entity key of the Publisher entity type when you define a referential integrity constraint on the PublishedBy association.

RefConstraintModel

The ADO.NET Entity Framework uses a domain-specific language (DSL) called conceptual schema definition language (CSDL) to define conceptual models. The following CSDL defines a referential integrity constraint on the PublishedBy association shown in the conceptual model above.

XML

<Association Name="PublishedBy">
  <End Type="BooksModel.Book" Role="Book" Multiplicity="*" >
  </End>
  <End Type="BooksModel.Publisher" Role="Publisher" Multiplicity="1" />
  <ReferentialConstraint>
    <Principal Role="Publisher">
      <PropertyRef Name="Id" />
    </Principal>
    <Dependent Role="Book">
      <PropertyRef Name="PublisherId" />
    </Dependent>
  </ReferentialConstraint>
</Association>

Content

ADO.NET Entity Data Model

See also

Entity Data Model Key Concepts

Entity Type

Association Type

Property

Representations of a Conceptual Model

See also

Entity Data Model: Namespaces

Example

See also

Entity Data Model: Primitive Data Types

Primitive Data Types Supported in the Entity Data Model

See also

Entity Data Model: Inheritance

Example

See also

association end

Example

See also

association end multiplicity

Example

See also

association set

Example

See also

association set end

Example

See also

association type

Example

See also

complex type

Example

See also

entity container

Example

See also

entity key

Example

See also

entity set

Example

See also

entity type

Example

See also

facet

Example

See also

foreign key property

Example

See also

model-declared function

Example

See also

model-defined function

Example

See also

Navigation property

Example

See also

property

Example

See also

referential integrity constraint

Example

See also

Source/Reference