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.