Post on 07-Apr-2018
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
1/30
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
2/30
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
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
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
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
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
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.
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
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.
CopyrightMicrosoft Corporation 2006. All Rights Reserved. 3
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
7/30
Entity Data Model Specification
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.
4 CopyrightMicrosoft Corporation 2006. All Rights Reserved.
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
8/30
Chapter 5 EDM Future Directions
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.
2.8.1 Abstract Syntax
The abstract syntax representation for describing ComplexType is shown below:
ComplexType ::=COMPLEXTYPEname [BASE complexTypeName] [ABSTRACT true|false]
CopyrightMicrosoft Corporation 2006. All Rights Reserved. 5
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
9/30
Entity Data Model Specification
{ (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.
2.9.1 Abstract Syntax
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
6 CopyrightMicrosoft Corporation 2006. All Rights Reserved.
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
10/30
Chapter 5 EDM Future Directions
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
CopyrightMicrosoft Corporation 2006. All Rights Reserved. 7
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
11/30
Entity Data Model Specification
"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.
8 CopyrightMicrosoft Corporation 2006. All Rights Reserved.
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
12/30
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
13/30
Entity Data Model Specification
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.
10 CopyrightMicrosoft Corporation 2006. All Rights Reserved.
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
14/30
Chapter 5 EDM Future Directions
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.
2.10.4.2 Abstract Syntax
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.
CopyrightMicrosoft Corporation 2006. All Rights Reserved. 11
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
15/30
Entity Data Model Specification
CustomerType
String: IdName : String
Address : AddressType
CompanyName : String
ContactTypeString: Id
Name: String
Address : AddressType
EmployeeType
String : IdName: String
Address : AddressType
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
Address : AddressType
CompanyName : String
PreferenceCode : String
CreditLimit : Decimal
ManagerTypeString : IdName: String
Address : AddressType
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
12 CopyrightMicrosoft Corporation 2006. All Rights Reserved.
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
16/30
Chapter 5 EDM Future Directions
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.
2.12.1.1 Abstract Syntax
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
CopyrightMicrosoft Corporation 2006. All Rights Reserved. 13
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
17/30
Entity Data Model Specification
EDMType[Abstract ]
EntityTypeRelationshipType
[Abstract ]SimpleType
PrimitiveType
EnumType
RefType
string
int 32
Figure 2: EDMType System
ComplexType
Xml
AssociationType
ContainmentType
RowType
14 CopyrightMicrosoft Corporation 2006. All Rights Reserved.
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
18/30
Chapter 5 EDM Future Directions
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.
3.1.1.1 Abstract Syntax
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
CopyrightMicrosoft Corporation 2006. All Rights Reserved. 15
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
19/30
Entity Data Model Specification
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.
3.3.1.1 Abstract Syntax
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.
16 CopyrightMicrosoft Corporation 2006. All Rights Reserved.
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
20/30
Chapter 5 EDM Future Directions
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.
3.4.1.1 Abstract Syntax
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.
CopyrightMicrosoft Corporation 2006. All Rights Reserved. 17
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
21/30
Entity Data Model Specification
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.
3.5.1.1 Abstract Syntax
The abstract syntax for describing EntityContainer is shown below:
EntityContainer ::= ENTITYCONTAINER containerName [USING namespace [ALIAS aliasName] ]*
{ (EntitySet | AssociationSet | ContainmentSet) * }
18 CopyrightMicrosoft Corporation 2006. All Rights Reserved.
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
22/30
Chapter 5 EDM Future Directions
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
CopyrightMicrosoft Corporation 2006. All Rights Reserved. 19
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
23/30
Entity Data Model Specification
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
The int32 type represents a signed 32 bit integer value
4.1.11 Int64
20 CopyrightMicrosoft Corporation 2006. All Rights Reserved.
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
24/30
Chapter 5 EDM Future Directions
The int64 type represents a signed 64 bit integer value
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.
CopyrightMicrosoft Corporation 2006. All Rights Reserved. 21
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
25/30
Entity Data Model Specification
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
22 CopyrightMicrosoft Corporation 2006. All Rights Reserved.
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
26/30
Chapter 5 EDM Future Directions
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
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
27/30
Entity Data Model Specification
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
24 CopyrightMicrosoft Corporation 2006. All Rights Reserved.
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
28/30
Chapter 5 EDM Future Directions
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:
CopyrightMicrosoft Corporation 2006. All Rights Reserved. 25
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
29/30
Entity Data Model Specification
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.
26 CopyrightMicrosoft Corporation 2006. All Rights Reserved.
8/4/2019 ADO.net Tech Preview - Entity Data Model (June 2006)
30/30
Chapter 5 EDM Future Directions
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.