1 Introduction

The conceptual schema definition file format provides the
structure and semantics of the conceptual schema definition language (CSDL) for
the Entity Data Model (EDM). CSDL is a language based on XML that can be used
for defining EDM-based conceptual models.

The EDM is an entity-relationship (ER) model. The ER model
has existed for more than 30 years and differs from the more familiar
relational model, because associations and entities are all first-class
concepts.

The EDM defines some well-known primitive types, such as
Edm.String, that are used as the building blocks for structural types such as
entity types and complex types.

Entities are instances of entity types (for example,
customer or employee) that are richly structured records with a key. The
structure of an entity type is provided by its properties. An entity key is
formed from a subset of the properties of the entity type. The entity key (for
example, CustomerId or EmployeeId) is a fundamental concept that is used to
uniquely identify and persist entity instances and to allow entity instances to
participate in relationships or associations.

Entities are grouped in entity sets; for example, the entity
set customers is a set of customer instances.

Associations (occasionally referred to as relationships) are
instances of association types. Association types are used to specify a named
relationship between two entity types. Thus, an association is a named
relationship between two or more entities. Associations are grouped into
association sets.

Entity types may include one or more navigation properties.
A navigation property is tied to an association type and allows the navigation
from one end of an association--the entity type that declares the navigation property--to
the other related end, which can be anything from 0 or more related entities.
Unlike standard properties, navigation properties are not considered to be
structurally part of an entity.

Complex types, which are structural types similar to an entity
type, are also supported by the EDM. The main difference is that complex types
have no identity and cannot support associations. For these reasons, complex
types instances only exist as properties of entity types (or other complex
types).

The EDM also supports entity type and complex type
inheritance.

Inheritance is a fundamental modeling concept that allows
different types to be related in an "Is a" relationship that makes it
possible to extend and reuse existing entity types and complex types. When type
B inherits from type A, type A is the base-type of B, and B is a sub-type or
derived-type of A. The derived-type inherits all the properties of its
base-type; these properties are called inherited-properties. The derived-type
can be extended to have more properties; these additional properties are called
direct-properties. A direct-property name has to be unique; it cannot be the
same as an inherited-property name. All valid derived-type instances at all
times are also valid base-type instances and can be substituted for the parent
instance. In the EDM a derived entity type always inherits the definition of
its entity key from its base type.

Function imports are also supported by the EDM. A function
import is conceptually similar to a method declaration in a header file, in
that a function import defines a function signature, but includes no
definition. The parameters and return type of the function import are one of
the EDM's built-in primitive types, one of the structural types defined in the
rest of the model, or a collection of primitive types and structural types.

Entity sets, association sets, and function imports are
grouped into one or more entity containers. Entity containers are conceptually
similar to databases; however, because entity types, association types, and
complex types are declared outside of an entity container, entity types,
association types, and complex types can be re-used across entity containers.

An example of a model that is defined by using CSDL is shown
in section 3.

Sections 1.7 and 2 of this specification are normative. All
other sections and examples in this specification are informative.