Blog
The Entity Data Model Designer
By Martin Schaeferle | September 07, 2012
Entity Framework's Entity Data Model is the key link between the entity data objects in your application and the backend data store where data resides. It provides all the pieces that Entity Framework needs to provide your application with a conceptual model that the application uses, a storage model of the data store schema, and mappings between the two, along with support for relationships between the various entities in the model. Entity Framework uses the model to generate .NET entity classes and APIs that provide powerful data access features to an application.
At design time, you'll most often work with the Entity Data Model in the graphical designer in Visual Studio, which provides a great way to see, understand, and modify the model. But all of the details of the model, including how it appears in the designer, are stored in a .edmx XML file.
The Entity Framework takes care of all the work of connecting to the data store, generating commands and executing them, providing entity data objects to the application, and processing changes to the data.
In this blog, you'll learn about how the Entity Data Model Designer works, so that you can make effective use of it in applications.
Entity Data Model Designer
Your model will open in the Entity Data Model designer, shown in the figure below, once the Entity Data Model Wizard finishes its work. The wizard creates an entity for each table and view you selected in the database and association lines that reflect the table relationships defined in the database. Each entity has properties that reflect the corresponding table's fields, and entities with associations that have navigation properties. Notice how all the entity names are singular, and the navigation properties are either singular or plural, reflecting whether they reference a single entity or a collection, which in turn reflects the multiplicity of the relationship. For example, a Customer can have multiple addresses so it has a CustomerAddresses navigation property to the CustomerAddress entity.
But a customer address can have only a single associated customer, so the CustomerAddress entity has a Customer property. The model implemented this singular/plural naming scheme because you left the Pluralize or singularize generated object names option checked in the wizard. Each entity has scalar properties-listed under the header Properties on each entity in the designer-that have values contained within the entity. The Customer entity includes CustomerID, Title, FirstName, and LastName scalar properties, and more, each of which will contain the current value of the corresponding field in the Customer table from the database when the object is materialized at runtime.
Entities that have associations with other entities also have one or more navigation properties. These properties are references to the related entities. For example, the Customer entity can have one or more addresses and sales orders, so the entity has CustomerAddresses and SalesOrderHeaders navigation properties. These properties let you navigate from a Customer to its addresses or orders without having to write a join in a LINQ expression. The lines that connect related entities are associations, which represent the relationships between the tables in the database, and define the relationship between the associated entities. Each end of an association is described by its multiplicity, which is the number of entities that can be on that end. (Multiplicity is often referred to as cardinality in relational database theory, but Entity Framework more often uses the term multiplicity.)
There are three options for the multiplicity of each end of an association, with the symbol used in the designer:
- One: 1
- Zero or one: 0..1
- Many: *
WARNING! The location of the end points of an association line in the designer have no bearing on the fields involved in the relationship between the two entities. If you look back at the figure above, the association between the Customer and SalesOrderHeader entities has nothing to do with the Customer's FirstName field, even though that end of the line is adjacent to FirstName. You can then combine the multiplicity of the two ends of an association to describe the relationship, such as:
- 1:* means "one to many." For example, a single customer can have many orders.
- *:* means "many to many." An example of this relationship would be customers to addresses (although this is not the type of relationship in the AdventureWorksLT database). A customer can have many addresses (home, school, work, mailing), and each address can be used by multiple people, such as several family members living at the same home address.
- 0..1:* means "zero or one to many." An example of this relationship is the association between the ProductCategory and Product entities in AdventureWorksLT. A product category can have many products, and a product can optionally have a category assigned to it.
NOTE: The CustomerAddress entity, shown back in the figure above, is a many-to-many table in the AdventureWorksLT database. If a many-to-many table in the database contains only the foreign keys to the related tables, the Entity Data Model Wizard simply creates a many-to-many association between the two tables, and doesn't include an entity for the many-to-many table. But because CustomerAddress includes other fields-AddressType, rowquid, and ModifiedDate-that describe the type of customer address, the model includes it as a separate entity so that you can access those additional properties in your application. NQMDTN5Y47AP
