Database Reference
In-Depth Information
stakeholder perspective, an employee is a single object, which happens to contain phone numbers and devices.
The developer is unaware, and does not care, that the DBA has normalized this employee object into three separate
database tables. Once configured, the mapping between the single class and three database tables is abstracted away
and handled by the Entity Framework.
A reverse situation can be seen for the single Department table, which programmatically maps to three entity
classes that represent individual departments. Again, to the developer and project stakeholders, a separate entity
object represents each department (Accounting, Marketing, Finance, and so on), but DBA optimizes and collapses
these objects into a single database table for data storage purposes.
Of course, as can be seen in the Location table, you can easily map a single entity class to a single database table,
which is the
default behavior
for Entity Framework.
The key takeaway here is that developer and project stakeholders work with a representation of domain classes
that make sense in the context of the application. The DBA can structure the underlying database tables in order to
efficiently tune the database. And you can easily bridge these two worlds with the Entity Framework.
The Layers
The Entity Data Model consists of three separate layers: the conceptual, store, and mapping layers. Each layer is
decoupled from the others.
The entity classes are contained in the
conceptual layer
of the Entity Data Model. This is layer in which developers
and project stakeholders work. Depending upon how you implement the Entity Framework, the conceptual layer can
be modeled with a designer or from code. Once you make that decision, you can reverse- engineer your model from
an existing database, leveraging the designer and extensive tooling that ships with Entity Framework or create your
model with code and have Entity Framework generate the database for you. The syntax for the conceptual layer is
defined in the
Conceptual Schema Definition Language
(CSDL).
Every useful application needs to persist objects to some data store. The
store layer
of the Entity Data Model
defines the tables, columns, relationships, and data types that map to the underlying database. The
Store Schema
Definition Language
(SSDL) defines the syntax for the store model.
Finally, the mapping layer defines the mapping between the conceptual and store
layer
. Among other things,
this layer defines how properties from entity classes map to columns in database tables. This layer is exposed to the
developer from the Mapping Details window contained in the Entity Framework designer or data annotations and
fluent API if choosing a code-based approach. The
Mapping Specification Language
(MSL) defines the syntax for the
mapping layer.
The Terminology
As expected, the Entity Framework comes with its own vocabulary. If you have used any of the popular ORM tools
or are familiar with database modeling, you've probably encountered some of the terminology before. Although the
entire vocabulary is extensive, we'll provide just a few of the basic terms to get us started.
As discussed earlier, an
EntityType
represents a class in your domain model. An instance of an EntityType is often
referred to as an
entity
. If you are using the Entity Framework designer, an EntityType is represented on the design
surface as a box with various properties. Figure
1-3
shows two EntityTypes: Employee and Task.
