ado.net tech preview - entity data model (june 2006)

8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)

1/30


2/30


3/30

Table of Contents

Table of Contents

1. Introduction.....................................................................................................................................................1

1.1 Document Outline.......................................................................................................................................1

2. Basic Concepts.................................................................................................................................................2

2.1 Types...........................................................................................................................................................22.2 Instances......................................................................................................................................................2

2.3 Abstract Syntax...........................................................................................................................................32.4 Schema Definition Language (SDL)................................................................................................... ........3

2.5 Simple Types...............................................................................................................................................3

2.6 EntityType...................................................................................................................................................3

2.7 Property.......................................................................................................................................................42.8 ComplexType..............................................................................................................................................5

2.9 RowType................................................................................................................................................... ..6

2.10 Relationship Type......................................................................................................................................6

2.11 Inheritance...............................................................................................................................................11

2.12 Schemas...................................................................................................................................................12

2.13 Taxonomy of EDM Types.......................................................................................................................13

3. EDM Instances..............................................................................................................................................15

3.1 EntitySet....................................................................................................................................................153.2 RelationshipSet .........................................................................................................................................15

3.3 AssociationSet...........................................................................................................................................15

3.4 ContainmentSet..................................................................................................................................... ....16

3.5 Entity Containers.......................................................................................................................................17

4. EDM Primitive Types............................................................................................................................ .......19

4.1 Primitive Types ................................................................................................................................. .......19

4.2 Applicable facets.......................................................................................................................................22

4.3 EDM and Canonical type systems .......................................................................................................... ..23

5. EDM Future Directions.......................................................................................................................... ......26

5.1 Conditional Association................................................................................................................. ...........26

5.2 Relationships.............................................................................................................................................26

CopyrightMicrosoft Corporation 2006. All Rights Reserved. iii


4/30

Chapter 1 Introduction

1. Introduction

The Entity Data Model is an Entity-Relationship data model. The ER model is familiar to most if not alldatabase application developers, and has been used successfully for about 30 years. The central concepts in theEDM are entities and relationships. Entities are instances of Entity Types (e.g., Customer, Employee) which arerichly structured records with a key. An entity key is formed from a subset of properties of the Entity Type. Thekey (e.g., CustId, EmpId) is a fundamental concept to uniquely identify and update entity instances and to allowentity instances to participate in relationships. Entities are grouped in Entity Sets (i.e., Customers is a set ofCustomer instances). Relationships are instances of Relationship Types which are associations among two ormore entity types (e.g., Employee WorksForDepartment). Relationships are grouped in Relationship Sets.

The EDM works in conjunction with a new query language eSQL, a SQL-like query language designed toenable set-oriented, declarative queries and updates in terms of entities and relationships. EDM can work withother query languages as well.

The EDM and eSQL together represent a richer data model and query language and have been designed to

enable applications such as CRM, ERP, data-intensive services such as Reporting Services, BusinessIntelligence, Replication, Synchronization, and data-intensive application developers to model and manipulate

data at a level of structure and semantics that is closer to their needs.

This document is the specification of the EDM. It is intended to provide a precise and complete definition of theEDM.

1.1 Document Outline

This document consists of 4 major sections.

Part 1: Basic concepts describing the core EDM

Part II: Constructs describing instantiation of EDM schema

Part III: Constructs describing management of EDM instances

Part IV: EDM Primitive Types

CopyrightMicrosoft Corporation 2006. All Rights Reserved. 1


5/30

Entity Data Model Specification

2. Basic Concepts

The EDM concepts can be categorized into two kinds. One set of concepts for defining types or structure and theother set for managing instances of these types.

2.1 Types

1. EntityType: An EntityType defines the principal data objects about which information has to be

managed such as person, places, things or activities relevant to the application. An Entity is an instanceof an EntityType. It has a unique identity, independent existence, and forms the operational unit of

consistency.

2. Property: An EntityType can have one or more properties of the specified SimpleType,

ComplexType, orRowType. Properties can be either single-valued or multi-valued.

3. EntityKey: All instances of an EntityType are uniquely identified by the value of its identifying

properties. This set of identifying properties is called an EntityKey.

4. ComplexType: A ComplexType represents a set of related information. Like EntityType, it consists

of one or more properties ofSimpleType,ComplexType, orRowType. However unlike EntityType,

ComplexType is not associated with an EntityKey.

5. RowType: RowType is an anonymous type that is structurally similar to ComplexType except that itcannot participate in type-inheritance. Two (anonymous) RowType instances are comparable if their

corresponding RowTypes have the same number, sequence and type of properties.

6. RelationshipType: While EntityTypes are like nouns of a data model, RelationshipTypes are the

verbs that connect those nouns. A RelationshipType is described over two or more participating

EntityTypes. The EDM supports two kinds ofRelationshipTypes, Association and Containment. An

Association is like a peer-to-peer relationship while Containment is a parent-child relationship withspecific membership semantics

7. Schema: All EDM types are contained within some namespace. The Schema concept defines a

namespace that describes the scope of EDM types.

2.2 Instances

1. EntitySet: An EntitySet for an EntityType holds instances of its EntityType or any of its subtypes.

Multiple EntitySets may be defined for a given EntityType.

2. A RelationshipSet for a given relationship type may hold instances of that type. The relationship

instance connects entity instances contained by the EntitySets participating in this RelationshipSet. A

RelationshipSet description includes the RelationshipType and the corresponding EntitySets of theEntityTypes described in RelationshipType.

3. EntityContainer: All EDM instance-based concepts like EntitySets and RelationshipSets are defined

in the scope of an EntityContainer. Users can have one or more instances ofEntityContainer. An

EntityContainer can reference one or more Schemas.

2 CopyrightMicrosoft Corporation 2006. All Rights Reserved.


6/30

Chapter 5 EDM Future Directions

2.3 Abstract Syntax

We use an Extended Backus-Naur Form (EBNF) based notation to describe syntax for creating EDM concepts.

The abstract syntax is described using the following notation:

Constants, keywords or terminals are expressed using UPPERCASE-BOLD

Literals are expressed using mixed-case italics Non-terminals are expressed using Mixed-case-bold

Default values areunder-lined

2.4 Schema Definition Language (SDL)

We use an XML-based data-definition language based on the abstract syntax to describe EDM schemas, thus

this language is called Schema Definition Language (SDL). The complete SDL is described in SectionError:Reference source not foundError: Reference source not found. We will be using SDL fragmentsto illustrate EDM concepts throughout this document.

2.5 Simple Types

SimpleTypes are atomic and consist of primitive types and EnumerationType.

2.5.1 Primitive Types

The EDM uses an abstract type system to define its primitive types such as String, Boolean, SByte, Int16, Int32,

Int64, Byte, UInt16, UInt32, UInt64, Float, Decimal, Xml, Guid and DateTime. For a complete description of

EDM primitive types see Section 4below.

An Enumeration type defines a set of symbolic names such as (red, blue, green) or (spring, summer, autumn,

winter). An instance of an enumeration type has a value that is a member of this set. The following SDL

example shows the definition of an enumeration type:

Example 1

1. 2. 3. 4. 5. 6.

This defines a type called Seasons. Instances of this type can only take on one of the 4 values specified in lines2-5. An instance of Enumeration type is treated as an EDM simple type. The Enumeration type values are un-

ordered, in other words, they can participate in equality checks but not in sort operations.

2.6 EntityType

An Entity is an instance of an EntityType. It has a unique identity, independent existence and forms the

operational unit of consistency. Intuitively, EntityTypes model the top-level concepts within a data model -such as Customers, Orders, Suppliers, etc (to take the example of a typical line-of-business system). An Entity-

instance represents one particular instance of the EntityType such as a specific customer or a specific order. AnEntityType can be either abstract or concrete where the former cannot have instances.

An EntityType has a name, a payload consisting of one or more properties and an EntityKey that describes the

set of properties, values of which uniquely identify the instance of an entity within an entity set.

The type of a property can be a primitiveType, enumerationType, complexType, or a rowType. See19 for a

complete description ofPrimitiveTypeand its applicable facets.



7/30


2.6.1 EntityKey

An entity-type contains an entity key consisting of one or more of its properties. Any set of non-nullable,

immutable, SimpleType properties can serve as the key. Complex type and multivalued properties cannot bepart of a key. However, a single-value SimpleType property of a ComplexType can be part of the entity key.

Example shows specification of a key composed of a single SimpleType property.

Example 2

1. 2. 3. 4. 5.

2.6.2 Abstract Syntax

The abstract syntax for describing an EntityType is given below:

EntityType ::= ENTITYTYPEentityTypeName [BASE entityTypeName] [ABSTRACT true|false]

KEYpropertyName [,propertyName]*

{(propertyNamePropertyType [PropertyFacet]*) +}

PropertyType ::= ((PrimitiveType [PrimitiveTypeFacets]*) | (complexOrEnumTypeName) | RowType

PropertyFacet ::= ( [NULLABLEtrue | false] | [DEFAULT defaultVal] |[MULTIPLICITY [ 1|*] ] )

PropertyTypeFacet ::= LENGTH|MAXLENGTH|PRECISION|SCALE|UNICODE|COLLATION |DATETIMEKIND|PRESERVESECONDS

PrimitiveType ::= BINARY | BOOLEAN |DATETIME|DOUBLE|DECIMAL|FLOAT|GUID|SBYTE|INT16|INT32 | INT64 | BYTE | UINT16 | UINT32 | UINT64| STRING |XML | MONEY)

2.7 PropertyProperties describe some aspect of an EntityType (or ComplexType) by associating with it a unique name and

type. A property description consists of its name, type and a set of facets like nullable, default, etc. The

propertys type can be any primitive type, ComplexType, or a RowType. The facets associated with a property

can be classified as type-specific and type-agnostic. The type-agnostic facets are applicable to all properties

while type-specific are applicable to EDM primitive types described in section Error: Reference source not

foundError: Reference source not found. The next section describes the set of type-agnostic facets.

2.7.1 Facets

2.7.1.1 Nullable

All properties except for those participating in an EntityKey can be nullable. The value of a nullable property

can be NULL. This is a boolean facet with the default value as true. The example shown below describes this

facets usage.

Example 3

1. 2. 3. 4. 5.



8/30


6.

TheEmailID property cannot be NULL, indicating that aPerson instance has a non-NULL email. Note also thatNullable is allowed on complex-typed and multivalued properties. For example, the Address property can be

NULL, indicating that an Address value need not be supplied for the Address property.

2.7.1.2 DefaultThe default facet may contain a default value for a property. If no explicit value has been specified duringinstantiation, then the property gets assigned its defaultvalue. In EDM v1.0 the default facet is applicable for

single-valued SimpleType properties. The facets type is same as propertys type and its value can be anyconstant of that type.

2.7.1.3 Multiplicity

The notion of multiplicity describes the cardinality of a property. Entity properties can be either single or multi-

valued. The value 1 denotes single-valued and * denotes multi-valued properties where the default is 1.

The collection semantics for the multi-valued property is that of a bag or multi-set, the individual items in a

multi-valued property are un-ordered and may have duplicates.The following example describes the usage of

this facet.Example 3

1. 2. 3. 4. 5.

The PhoneNumbers property described on line 4 is a multivalued string property, indicating that PhoneNumbers

can contain zero or more string values.

2.8 ComplexType

A ComplexType provides a mechanism to create properties with a rich (structured) payload as shown in the

example below. A ComplexType may derive form another ComplexType. Its definition includes its name, an

optional base-ComplexType and payload. The payload of a ComplexType is very similar to that of anEntityType as shown in the abstract syntax described below.

Example 4

1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

Lines 1-5 describe ComplexType AddressType. Line 8 shows the definition of a ComplexType property.


The abstract syntax representation for describing ComplexType is shown below:

ComplexType ::=COMPLEXTYPEname [BASE complexTypeName] [ABSTRACT true|false]



9/30


{ (propertyNamePropertyType PropertyFacet* )* }

2.9 RowType

The EDM types seen so far are all nominal or named types. This section introduces the only anonymous EDM

type, the RowType. Structurally it is similar to a ComplexType except it cannot have a name or derive from

another type. The payload of a RowType is exactly the same as that of a ComplexType as shown below:Example 5

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

Lines 4-8 describe the declaration of the RowType-valued Address Property. Since RowType cannot have a

name that a property can refer to, it has to be defined inline in the scope of a property.

The SDL (XML based DDL) for EDM v1.0 will not support the declaration of RowType-valued properties. However, eSQL query results may contain transient RowType-valued

properties.


An abstract syntax representation for RowType is shown below:

RowType ::=ROWTYPE { (propertyNamePropertyType PropertyFacet* )+ }

2.9.2 Type EqualityThe instances of named-type are considered comparable if their types have the same name. The same

mechanism may not be applicable for anonymous types. This section describes the semantics for determining

comparability of two anonymous types. Two RowTypes are considered comparable if they are structurally

equivalent that means they have the same number, sequence and type of properties. The property name is not

significant for the purposes of comparing RowTypes.

2.10 Relationship Type

While entity types are the nouns of a data model, relationships are the verbs that connect those nouns. A

relationship denotes a connection (a.k.a. relation or link) between two or more Entities. An example of

relationship would be: A customerplaces one or more orders, an ordercontains order details, aproductis

available from on or moresuppliers, and so on. In these sentences, we have shown entity in italics andunderlined the relationships among them. The relationship concept is borrowed from the classic Entity-Relationdata model and made a first-class concept in EDM.

In EDM the relationship type is an abstract notion, the two concrete relationship types are Association andContainment, described later in this section.

2.10.1 Characterization



10/30


Relationships are primarily characterized by its degree, multiplicity, direction and kind. This section describes

these terms in more detail.

2.10.1.1 Degree

The degree (or arity) of a relationship is the number of EntityTypes associated with it. The most common form

of relationship is a binary relationship that relates two EntityTypes, ternary relates three EntityTypes and the

most general form is the n-ary relationship that can relate n EntityTypes.

EDM v1.0 support is restricted to binary relationships.

2.10.1.2 Multiplicity

The multiplicity of a relationship describes the cardinality or number of instances of an EntityType that can be

associated with the instances of another EntityType. The basic types of multiplicity are: one-one, one-many and

many-many as shown below:

Binary Relationships

One to One

EMPLOYEE Is_Assigned

One to Many

ContainsORDER

A one-many is a special case of many-many and one-one is a special case of one-many relationship. Similarly

cardinality or zero (implying that its optional) can be seen as a special case of the above relationships. For

instance 0 or 1 to many is a special case of 1 to many. The example shown below shows the usage of

multiplicity in a relationship.

Example 6

1. 2. 3.

4. 5. 6.

The Multiplicity facet defines the cardinality of a relationship end. In this example, we specify that there is

exactly one Customer (value is 1 on line 2) for zero or more Order instances (value is * on line 3). Other

values for this facet are:

"0..1" zero or one



11/30


"1" exactly one

"*" zero or more

"1..*" one or more

"n" exactly n

"n..m" between n and m, inclusive, where n is less than or equal to m.

2.10.1.3 Direction

In EDM v1.0 all relationships are bi-directional. Conceptually they may be viewed as two mutually inverse

relations. In a future version of EDM, we may add support for uni-directional relationships.

2.10.1.4 Role

A bi-directional relationship instance can be seen as connecting entity-instances in both directions. The label or

name given to a relationship-end is called role. Role names are unique within a relationship.

2.10.1.5 Kind

There are different kinds of relationships. The two kinds supported in EDM v1.0 are Association andContainment. Future versions of the EDM may add support for other relationship notions that capture common

semantic patterns required by applications and services such as Composition, Identifying, and Part-Whole.

2.10.1.6 Operational Behavior

For certain kinds of operations it is useful to operate on related entities as a single unit. This section describes

the kinds of operations and their associated behavior that may be specified on the relationship-type.

2.10.1.6.1 Operations and Actions

The operational semantics are described on the RelationshipType by specifying the desired Operation and its

corresponding action.

Example 7

1. 2. 3. 4. 6. 7. 8. 9. 10.11. 12. 13.

14. 15. 16.

In the above example the element on line 11 is used to define the relationship. The

element on line 13 describes the operational behavior by specifying the OnDelete operation and the Cascade

action for the CustomerOrder association.



12/30


13/30


EndDescription ::= ENTITYTYPE entityTypeName [ROLE roleName]

MULTIPLICITY (0..1 | 1 | * | 1..* | n | n..m) [Operation]*

Operation ::= ONDELETE (CASCADE| RESTRICT | REMOVEASSOCIATION)

2.10.3 Containment

This is a kind of relationship with the following characteristics:

Direction:It is a bi-directional relationship with different semantics for each direction of therelationship.

Multiplicity: This relationship is 1 to 0..N where the cardinality of one end is always 1. For

convenience, we will refer to the 1-end as the parent, and the other end as the child.

Exclusive membership constraint: A child entity-typemay participate in multiple Containment

relationships however a child entity-instancecan be a member of exactly one Containment

relationship-instance. In other words, a child entity-instance at all times is contained in exactly one

parent entity-instance.

Operational Behavior:A Containment child entity-instance always lives in the scope of its parent

entity-instance. As a result the Action on OnDeleteoperation is restricted to be Cascade or Restrictwith Cascade as the default.

The following example shows the definition of a Containment relationship:

Example 9

1. 2. 3. 4.

The element in line 1 defines the Parent_Child relationship between Parent and Child

EntityType.

2.10.3.1 Abstract Syntax

The abstract syntax for describing Containment relationship is shown below:

ContainmentType ::= CONTAINMENT containmentName (ParentEnd, ChildEnd)

ParentEnd ::= PARENT entityTypeName [ROLE roleName] [Operation]

ChildEnd ::= CHILD entityTypeName [ROLE roleName] [ MULTIPLICITY (0..1 | 1 | * | 1..* | n | n..m) ]

Operation ::= ONDELETE (CASCADE | RESTRICT)

2.10.4 Navigation Property

Navigation properties are pseudo-properties on entities that describe the ends of a relationship. Standard-

properties describe a value associated with an entity, while pseudo-properties describe a navigation-path over a

relationship. For example, given a relationship between Customer and Order entities, an Order entity-type maydescribe a navigation property OrderedBy that represents the Customer-instance associated with that

particular Order-instance.

2.10.4.1 DataType

The datatype of a navigation property is always Ref and has the same multiplicity as the associated

relationship end. For example, assuming a 1-n relationship between Customer and Order, a navigation propertyOrderedBy on the Order entity would have type Ref.



14/30


The following example describes the creation of a Navigation property:

Example 10

1. 2. ...3. 5.6. 6.7. 8. ...9. 11. 12.13. 14. 15. 16.

17.18. 19.20. 22.23.


The abstract syntax for describing Navigation property is shown below:

NavigationProperty::= NAVIGATIONPROPERTYNAMEpropertyName

RELATIONSHIPTYPE relationshipName [FROMROLE role] TOROLE role

2.11 Inheritance

Inheritance is a fundamental modeling concept that allows different types to be related in a Is a relationship

enabling extensibility and reuse of existing types. When type A inherits from type B, we say B is the base-typeof A and A is a sub-type orderived-type of B. The derived-type inherits all properties of its base-type and

these properties are called inherited-properties. The derived-type can be extended to have more properties and

these additional properties are called direct-properties. The direct-property name may be the same as its

inherited-property name in which case the direct-property has to be qualified with the new modifier. The name

collision does not result in an ambiguity as based on the type of the instance at the point of access it resolves to

either the direct or inherited-property. All valid derived-type instances at all times are also valid base type

instances and can be substituted for the parent instance.An EDM ComplexType can only inherit from another ComplexType; similarly an EntityType can only inherit

from another EntityType. EDM v1.0 does not support inheritance of RelationshipTypes.

A derived entity type always inherits the definition of its key, from its base type which cannot be changed. The

figure below shows an inheritance example for entity types.



15/30


CustomerType

String: IdName : String

Address : AddressType

CompanyName : String

ContactTypeString: Id

Name: String


EmployeeType

String : IdName: String


HireDate : String

Title : StringExtension : String

Is A Is A

Where : ContactType and other derived Types are EntityType

Id Property is EntityKey for ContactType and other EntityTypes

AddressType is a complexType

Figure 1: Inheritance and Type Hierarchy

PreferredCustomerType

String: IdName : String


CompanyName : String

PreferenceCode : String

CreditLimit : Decimal

ManagerTypeString : IdName: String


HireDate : String

Title : StringExtension : String

BudgetAmount Money

Is AIs A

Inherited

Properties

The SDL example below shows an EntityType CustomerType deriving from ContactType.

Example 11

1. 2. 3. 4. 5. 6. 7.

2.12 Schemas

In general, type and data-model systems allow the created types to physically reside in a repository or file and

logically, live in a namespace. This is similar to the notion of namespace in SQL, CLR, and XSD. All typesreside in some namespace. The Schema is the EDM construct that allows creation of namespaces.

The contents of a namespace can be defined by one or more schema instances. The type names have to be

unique within a namespace. For instance an EntityType cannot have the same name as a ComplexType within

the same namespace. The namespace forms a part of the types fully-qualified name. The following example

demonstrates the use of the Schema construct.

Example 12



16/30


1. 2. 3. ...4. 5. 6. ...7. 8. 9. ...10. 11.

This example shows that the Customerand Orderare defined within the schema called

MyCompany.LOBSchema. Note that every name defined within this schema also has a fully qualified name, e.g.MyCompany.LOBSchema.Customer.

A Schema can refer to contents of another Schema or namespace by importing it with the Using clause. The

imported namespace can be associated with an alias which is then used to refer to its types or the types can be

directly used by specifying its full-qualified name. The following SDL example illustrates these concepts:

Example 13

1. 2. 3. 4. 5. ...6. 7. 8. ...9. 10. 11. 13. ...14.

15. Line 2 imports namespace YourCompany.YourSchema. YourType is defined in this schema and can be usedwithout qualification (as its unique across all visible namespaces), shown in line 4. It is also possible to define

an alias for an imported namespace, as shown in line 3. Types defined in this namespace can be referenced by

qualifying them with the alias - as shown in line 8. The alias name cannot be the same as an existing

namespace.


The abstract syntax for describing Schema is shown below:

Schema ::= SCHEMA namespace [USING namespace [ALIAS aliasName]]*

{(EntityType | ComplexType | RelationshipType | EnumerationType)*}

2.13 Taxonomy of EDM Types

So far we have seen the various categories of types available in the EDM. In this section, we provide a proper

classification of types within the EDM type system. This is shown in figure 2 below



17/30


EDMType[Abstract ]

EntityTypeRelationshipType

[Abstract ]SimpleType

PrimitiveType

EnumType

RefType

string

int 32

Figure 2: EDMType System

ComplexType

Xml

AssociationType

ContainmentType

RowType



18/30


3. EDM Instances

The EDM provides concepts for defining types and managing instances of those types. Top level Instances inEDM are called entities that are of type EntityType and belong to at most one EntitySet. Other types like

relationship-types have instances in the context of a relationship-set while ComplexType, RowType, and

SimpleType have instances in the context of the property of an entity-instance. This section describes the

constructs used for managing instances.

3.1 EntitySet

An EntitySet ES for an entity type ET may contain instances of ET and any of its subtypes. Multiple entity sets

may be defined for a given entity type. The EntitySet may contain any entity instance that satisfies the following

three conditions:

1. The Entity instances type is either the same as EntitySets type or any of its subtype.

2. The Entity instances key value uniquely identifies it in the EntitySet.3. The Entity instance is not a member of any other EntitySet

The following SDL example shows declaration of an EntitySet

Example 14

1.

This example shows the creation of EntitySet named CustomerSet of EntityType CustomerType.


The abstract syntax for describing EntitySet is shown below:

EntitySet ::= ENTITYSET entitySetName ENTITYTYPE entityTypeName

3.2 RelationshipSet

A RelationshipSet contains relationship instances of the specified RelationshipType. A relationship instance

connects two or more entity-instances belonging to the EntitySet(s) associated with the RelationshipSet. The

RelationshipSet description includes EntitySet(s) that can hold instances of EntityTypes associated with ends of

its RelationshipType.

Said in a more formal way: Given a RelationshipType RT, over EntityType ET1 and ET2, a RelationshipSet RS

for RT, EntitySet ES1 and EntitySet ES2 holds instances of RT that connect entity-instances in ES1 and ES2.

RelationshipType and RelationshipSet are abstract concepts. For each concrete implementation of

RelationshipType there exists a corresponding concrete RelationshipSet. For instance AssociationType is aconcrete RelationshipType and AssociationSet is a concrete RelationshipSet. This section describesAssociationSet and ContainmentSet the two concrete RelationshipSets supported by EDM v1.0.

EDM v1.0 allows a maximum of one RelationshipSet per RelationshipType per EntitySet.

3.3 AssociationSet

An AssociationSet contains relationship-instances of the specified AssociationType. The AssociationType

specifies the EntityTypes of the two end points while AssociationSet specifies the EntitySets that correspond to



19/30


these EntityTypes. The association-instances contained in the AssociationSet relate entity-instances belonging to

these EntitySets.

The following SDL example demonstrates the usage of AssociaitonSet

Example 15

1. 2. ...3. 4. 5. ...6. 7. 8. 9. 10. 11.12. 13.14.

15.16. 17. 18. 19.

Lines 1 6 describe creation of EntityTypes Customer and Order. Line 7 defines AssociationType

CustomerOrderType. Lines 12 to 14 describe creation of EntitySet CustomerSet and OrderSet. The

element on line 16 defines AssociationSet named CustomerOrderSet of type

CustomerOrderType defined on line 7 above. The two EntitySets corresponding to the AssociationType-end

EntityTypes are specified on line 17 and 18. The association instances will live in CustomerOrderSet and

connect instances in CustomerSet and OrderSet.


The abstract syntax for describing AssociationSet is shown below:

AssociationSet ::= ASSOCIATIONSET assocSetName TYPE assocType {EndDescription

EndDescription}

EndDescription ::= END ENTITYSET entitySetName

3.4 ContainmentSet

A ContainmentSet contains relationship-instances of the specified ContainmentType. The ContainmentType

specifies the EntityTypes of the parent and child ends while ContainmentSet specifies the EntitySets that contain

instances of these EntityTypes. The Containment instances contained in the ContainmentSet relate entity-instances belonging to these EntitySets.

The following SDL example demonstrates the usage of ContainmentSet

Example 16

1. 2. ...3.



20/30


4. 5. ...6. 7.8. 9. 10. 11. 12. 13. 14. 15. 16.17. 18. 19.20. 21. 22. 23.

24. 25. 26. 27.

Lines 1 6 describe creation of EntityTypes Organization and Department. Lines 8 16 define

ContainmentTypes OrgHasDeptType and DeptHasDeptType Lines 17 to 19 describe creation of EntitySet

OrganizationSet and DepartmentSet. The element on line 20 defines ContainmentSet

named OrgHasDeptSet of type OrgHasDeptType defined on line 8 above. The two EntitySets

corresponding to the parent and child EntityTypes for ContainmentType are specified on line 21 and 22. Lines

25 28 describe another ContainmentSet DeptHasDeptSet over the same EntitySets but different

ContainmentType.


The abstract syntax for describing ContainmentSet is shown below:

ContainmentSet ::= CONTAINMENTSET name TYPE containmentTypeName { Parent Child }

Parent ::= PARENT entitySetName

Child ::= CHILD entitySetName

3.5 Entity Containers

All EDM types are defined in the scope of a namespace, created using the Schema construct. Similarly all EDM

instances are contained in the EntitySet and RelationshipSets defined in the scope of an EntityContainerinstance. The EntityContainer instance is created using the EntityContainer construct. It contains description

of EntitySets and RelationshipSets that may use types defined in one or more namespaces. A RelationshipSet

can only include EntitySets residing in its own EntityContainer.

The following SDL example shows the creation of an EntityContainer instance.

Example 17

1.



21/30


2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.14. 15. 16. 17. 18. 19. 20. 21.

22.23. 24. 25.26. 27. 28. 29. 30.


The abstract syntax for describing EntityContainer is shown below:

EntityContainer ::= ENTITYCONTAINER containerName [USING namespace [ALIAS aliasName] ]*

{ (EntitySet | AssociationSet | ContainmentSet) * }



22/30


4. EDM Primitive Types

Primitive types are the atomic built-in types provided by the system. The EDM uses an abstract type system todefine its primitive types such as Integer, String, Boolean, etc. EDM suggests the default mapping from these

types to the corresponding primitive types in other canonical type systems like CLR, SQL and XSD which can

host or instantiate EDM instances. EDM does not attempt to specify operational or conversion semantics on the

abstract simple types. The concrete instances of these types will exhibit the semantics imposed by the hosting

type system.

The data types described in this section are based on well known abstract concepts like integer and float. In

order to support interoperability and optimal representation across multiple type systems these types support

constraining facets which allow fine tuning of these types. This section describes the complete list of EDM

primitive types.

4.1 Primitive Types

4.1.1 Binary

The binary data type is used to represent fixed or variable length binary data.

4.1.1.1 Facets

The EDM simple type facets applicable for this type are fixedLength and maxLength. These are a set of

mutually exclusive facets where exactly one of them has to be specified for each declaration of this type.

4.1.1.1.1 fixedLength

ThefixedLength facet is a positive integer with value ranging from 1 to 2^31. The size of an instance of a binarydata type is always equal to value of the specified length.

4.1.1.1.2 maxLength

The maxLength facet is a positive integer with value ranging from 1 to 2^31. The maximum size of the declaredbinary data type value is specified by the value of the maxLength facet.

4.1.2 Boolean

The boolean data type is used to represent the mathematical concept of binary valued logic. There are no

applicable facets for this type.

4.1.3 DateTime

The DateTime type represents date and time with values ranging from 12:00:00 midnight, January 1, 0001 A.D.

through 11:59:59 P.M, December 1999 A.D. The maximum granularity of time is in milliseconds.

4.1.3.1 Facets

The DateTime type has two optional facets, one for specifying the time granularity and the other for associating

TimeZone information.

4.1.3.1.1 preserveSeconds



23/30


The preserveSeconds facet is a boolean with a default value of true. The DateTime value preserves the secondsand milliseconds component of the specified time if preserveSeconds is true else it ignores it.

4.1.3.1.2 dateTimeKind

The DateTime value can be expressed using the Coordinated Universal Time (UTC) standard, the local time

zone or it could be time zone agnostic. The dateTimeKind facet can be used to specify the desired time zone

characteristic. It is an EDM enumerator type with values UTC, Local and Unspecified where Unspecified is the

default.

4.1.4 Decimal

The Decimal type represents numeric values with fixed precision and scale. The required precision and scale can

be specified using its optional precision and scale facets. This type can describe a numeric value ranging from

negative 10^38 + 1 to positive 10^38 -1.

4.1.4.1 Facets

4.1.4.1.1 precision

This is a positive integer that specifies the maximum number of decimal digits that an instance of the decimaltype can have, both to the left and to the right of the decimal point. Theprecision value can range from 1through 38. The default precision is 18.

4.1.4.1.2 scale

This is a positive integer that specifies the maximum number of decimal digits to the right of the decimal point

that an instance of this type can have. Thescale value can range from 0 through the specifiedprecision value.The default scale is 0.

4.1.5 Float

The float type represents a floating point number with 7 digits precision that can represent values with

approximate range of 1.18e -38 through 3.40e +38.

4.1.6 Double

The double type represents a floating point number with 15 digits precision that can represent values with

approximate range of 2.23e -308 through 1.79e +308.

4.1.7 Guid

This Guid type represents a 16 byte (128 bit) unique identifier value.

4.1.8 SByte

The sbyte type represents a signed 8 bit integer value

4.1.9 Int16

The int16 type represents a signed 16 bit integer value

4.1.10 Int32


4.1.11 Int64



24/30



4.1.12 Byte

The byte type represents an unsigned 8 bit integer value

4.1.13 UInt16The uint16 type represents an unsigned 16 bit integer value

4.1.14 UInt32

The uint32 type represents an unsigned 32 bit integer value

4.1.15 UInt64

The uint64 type represents an unsigned 64 bit integer value

4.1.16 String

The string type represents fixed or variable length character data. The EDM simple type facets applicable to

string type are described below.

4.1.16.1 Facets

The EDM simple type facets applicable for this type are unicode, collation, length and maxLength. The length

and maxLength facets are mutually exclusive where exactly one of them has to be specified. The other facets

Unicode and collation are optional.

4.1.16.1.1 unicode

The unicode facet is a boolean value. This value when set to true dictates the string type instance stores unicode

characters else its standard ASCII encoding. The default value for this facet is true.

Note: The string data type does not support the kindof unicode to be specified, and leaves it to the concrete type

system hosting EDM to choose the appropriate flavor of Unicode.

4.1.16.1.2 fixedLength

The fixedLength facet specifies the length of an instance of the string type. Forunicode equal to true the lengthcan range from 1 to 2^30 otherwise 1 to 2^31.

4.1.16.1.3 maxLength

The maxLength facet specifies the maximum length an instance of the string type. Forunicode equal to true the

maxlength can range from 1 to 2^30 otherwise 1 to 2^31.

4.1.16.1.4 collation

The collation facet is a string value that specifies the collating sequence (or sorting sequence) to be used forperforming comparison and ordering operations overstringvalues.

4.1.17 Money

The money type represents monetary data which is a numeric value with the specified precision and a fixed

scale of 4. Theprecision facet can be used to specify the desired precision value. This type can describe a valuefrom negative 2^63 through 2^63 -1 with accuracy to a ten-thousandth of a monetary unit.



25/30


4.1.17.1 Facets

4.1.17.1.1 precision

This is a positive integer that specifies the number of bytes used for storing the money type instance; this alsodictates the precision of the money type instance. Theprecision value for this type can be either 4 or 8 with 8 as

the default.

4.1.18 Xml

The xml type is a rich type unlike other EDM simple types which are atomic in nature. An instance of this type

is can contain well-formed XML or valid XML data. The facets described below allow more control the kind of

XML data an instance of xml type can contain.

4.1.18.1 Facets

4.1.18.1.1 xmlFragment [Post EDM v1.0]

ThexmlFragmentis a boolean which is set to true to indicate the instance of xml type can contain fragments. A

value of false conveys that it is a document and cannot contain fragments. This is an optional facet with default

of true.

4.1.18.1.2 xmlSchema [Post EDM v1.0]

The xml data is by default un-typed and is not constraint by any xml schema. The xmlSchema facet describes

the xml schema element that constraints the xml data contained by an instance of this type.

This is an optional facet with a default of xsd:any.

4.2 Applicable facets

EDM defines a number of simple type facets which are used to customize a specific instance of a simple type.

There are a number of facets and not all are applicable to each simple type. The table below lists the simple

types and their applicable facets.

Simple Types and their respective applicable facets

Usage = Required || Optional

Simple Types Facets

fixedLength maxLength Precision Scale unicode collation dateTimeKind preserveSeconds

Binary

(fixedLength

or maxLength)

Yes

Required

Yes

Required

Boolean

DateTime Yes

Optional

Default=unspecified

Yes

Optional

Default=true

Double

Decimal Yes Yes



26/30


Required Required

Float

Guid

Sbyte

Int16

Int32

Int64

Byte

UInt16

UInt32

UInt64

String

( fixedLengthor

maxLength )

Yes

Required

Yes

Required

Yes

Optional

Default=false

Yes

XML

Money Yes

Optional

Default=8

4.3 EDM and Canonical type systems

In terms of simple types EDM is analogous to the SQL scalar type system or the .NET Frameworks commontype system (CTS). EDM uses an abstract type system to define its simple types which can be mapped to

concrete canonical type systems. The table below describes the suggested mapping of EDM simple types to

other type systems. The intent is to have at least one way to map EDM types to these canonical type systems

such that it preserves the fidelity of the data during round tripping across these type systems.

Binary [ML ::= 1 to 8000 || L ::= 1 to 8000 || ( ML>8000 || L>8000)]

L = 1 to 8000 Ml = 1 to 8000 (l>8000 && l 8000 && ml


27/30


XSD = Boolean

DateTime [Kind ::= Unspecified | UTC | Local, preserveSeconds ::= Bool]

preserveSecond True False

SQL Server = DateTime SmallDateTime

CLR = DateTime(Kind) DateTime(Kind)

XSD = DateTime DateTime

Notes:

1. Sql Server is thinking about extending its DateTime type to support Kind like facet we need to align with the extendedDateTime

2. CLR supports the Kind facet with the same semantics

3. XSD does not support facets for TimeZone at the type level. However, XML serialization provides mechanism to encode/decode

TimeZone information.

Decimal [precision ::= positiveInteger 8000



28/30


Max L=2^31

SQL Server = char[1] char(L) Varchar(ML) varchar(max)

Unicode=true

Max L=2^30

L=1 L = 1 to 4000 ML =1 to 4000 L > 4000 || ML > 4000

SQL Server = char[1] Char(L) Varchar(ML) varchar(max)

CLR = Char String String String || StringBuilder?

XSD = String String String String

Where: L=FixedLength, ML = MaxLength

Notes: We need to further specify 1) the default value for maxLength and 2) Add another facet for Collation and specify defaultcollation?

Xml

SQL Server = Xml

CLR = XElement, XmlDocument?

XSD = Xsd:any or xsd:schema?

Money [precision = 4 || 8]

precision = 4 Precision=8

SQL Server = SmallMoney Money

CLR = Decimal Decimal

XSD = Decimal(totalDigits=19, fractionDigits=4) Decimal(totalDigits=19, fractionDigits=4)

Notes:



29/30


5. EDM Future Directions

This section describes some of the concepts being considered for a future version of EDM.

5.1 Conditional Association

A standard relationship instance connects two or more entity-instances identified by the value of their key-

properties. The standard relationship-types are implicitly constrained to refer to entity-types key-properties; itdoes not permit relating of entity-types on arbitrary properties. The Conditional Association relationship allows

two entity-types to be related on any arbitrary set of type-compatible properties. The standard association

instances have to be explicitly created whereas conditional-association instances are implicit; they are a function

of the specified condition and implicitly connect the entity-instances satisfying the condition.

Example 1

1. 7. 8. 9. 10. Customer.CustomerId = Orders.CustomerId11. 12.

The element on line 4 describes the condition that the qualifying association-instances must satisfy.

5.2 Relationships

EDM v1.0 Relationships allows relationship between exactly two EntityTypes where the Relationship itself

cannot have any properties of its own. While this works for most cases there are many cases where itdintuitive for relationships to have properties and be able to relate to more than two EntityTypes. This section

describes the proposed extension to EDM v1.0 Relationships.

5.2.1 Relationships with Payload

The relationship concept allows capturing of relationships between entities. The current constraint that it not has

any properties of its own is very limiting that wed like to relax and allow it to have zero or more properties.These are relationship-properties, a relationship with properties is still a relationship and can be used in all

places where a standard relationship could be used. Specifically it does not mean that relationship-with-

properties can be an end of another relationship, an end of a relationship is always an entity. We use the

Association relationship to further describe the concept of relationship with properties.

The SDL uses the element to create this relationship, as shown below:Example 2

13.14. 15. 16. 17. 18.



30/30


The element in line 1 defines the OfficeHistory relationship between Employee and Office

EntityType.

5.2.2 N-ary Relationships

Binary relationships in most cases are sufficient for capturing the relationships in the user domain-model

however there are many cases where a nary relationship would better serve in describing the domain- model. Anary relationship can have more than two ends (or a degree greater than two). We use the Association

relationship to further describe the concept of n-ary relationships.

Example 3

1. 19. 20. 21. 22.

The element in line 1 defines the Annotations relationship between Document and Contact andComment EntityType.

5.2.3 Relationship Inheritance

EDM supports inheritance for EntityType and ComplexTypes however there is no support for Relationship

inheritance. Consider supporting inheritance where the derived-relationship could choose to add more

properties, constraint the entities at the relationship ends to be of a specific type or both.

5.2.4 Dynamic Entity Extensibility

One of the well known mechanisms of extensibility is through the notion of inheritance. EDM supports

inheritance for EntityTypes and ComplexTypes. This kind of extensibility allows creation of a new type that

extends from other types, a form of static extensibility. The other form of extensibility is dynamic-extensibility

which allows extra structured data to be associated with any element instance. The entity extensibility

mechanisms being considered are listed below:

1) Static Extensibility

a. A new EntityType can inherit from any existing EntityType

2) Dynamic Extensibility

a. A new set of non-queryable name-value property bags to be associated with any EntityType

b. A new set of queryable name-value property bags can be associated with EntityType

c. A new set of queryable strongly-typed queryable properties can be associated with EntityType

d. All 3 of above can be associated with an EntityType scoped to a single EntitySet

e. A new set of queryable strongly-typed properties can be associated with a specific entity-

instance. Optionally the properties may be non-queryable or unTyped string.

5.2.5 Recursive ComplexType

A property P of a ComplexType CT can be of type ComplexType CT.

ado.net tech preview - entity data model (june 2006)

Documents