Entity Data Model 101 - Part 2

New and Notable 141

Sam Gentile — Mon, 12 Feb 2007 20:58:16 GMT

Found some time to blog. Smart Client/UI Architecture V2 of the User Interface Process Application Block

ADO.Net Entity Framework: Entity Data Model 101

Guy Burstein's Blog — Mon, 12 Feb 2007 21:22:15 GMT

The ADO.Net team has published a serries of posts about the Entity Data Model (EDM) which is part of

re: Entity Data Model 101 - Part 2

Frans Bouma — Mon, 12 Feb 2007 21:25:37 GMT

Maybe I'm overlooking something, but why would you define relations on the entitytype and then AGAIN on the set using an associationSet ? Isn't that redundant?

re: Entity Data Model 101 - Part 2

Eric Vincent — Tue, 13 Feb 2007 22:03:32 GMT

Regarding "inheritance" in the database... what if the schema models inheritance where the sub-class has its own PK, and has an FK to the base clase (1:1 relation). For example, what if "Employee" had PK = EmployeeID int identity(1,1) and a FK ContactID int that referrs to the contact table's PK of ContactID int identity(1,1)?

Selection of Employees in this schema is by joining Contact and Employee, typically in a view. Is there a way to model the Employee object in CSDL / SSDL with this implementation? In the May06 CTP there didn't appear to be a way to handle this.

re: Entity Data Model 101 - Part 2

Mike Dodaro — Tue, 13 Feb 2007 22:17:54 GMT

For the moment let’s just consider many-to-many relationships. Recall that in the relational model, many-to-many relationships are realized by an intermediate “link” table, where each row of the link table holds a pair of foreign keys. Furthermore, a foreign key constraint in SQL must be scoped to a particular table.

Then, roughly speaking, the AssociationType definition specifies the shape of the link table, while the AssociationSet specifies the link table itself. When specifying the shape of a link table, we only need to know the types of the entities which may be related. However, when specifying the link table itself, we must also know which entity sets will hold those related entities.

If each defined entity type appears in at most one EntitySet definition, then you’re quite right: We could determine which entity sets must hold related entities from the AssociationType alone. However, when the same entity type is shared by multiple entity sets, we may need an AssociationSet to resolve the ambiguity.

We’ll try to eliminate redundant definitions in a future release, but for now we’re requiring everything to be defined explicitly.

re: Entity Data Model 101 - Part 2

Frans Bouma — Wed, 14 Feb 2007 18:15:01 GMT

"Then, roughly speaking, the AssociationType definition specifies the shape of the link table, while the AssociationSet specifies the link table itself. When specifying the shape of a link table, we only need to know the types of the entities which may be related. However, when specifying the link table itself, we must also know which entity sets will hold those related entities."

I consider myself not exactly a newbie on the front of O/R mapper development (I wrote one of the market leaders) however I have a hard time understanding what you're saying here.

What's the 'shape' of the link table? You mean by that the definition of the entity mapped onto the link table and the association set the DATA inside the link table ?

I still don't understand why you need an association set, because the relation is between 2 entities via an intermediate entity. That's already defined, so why using a different construct to define it AGAIN? Doesn't every entity instnace in a set has the relations its entity TYPE defined? If not, I really don't understand the necessity for this.

I also find it hard to understand why you use an m:n example while the mapping file you posted contains no m:n relation which would justify the usage of the association set.

An entity set defines a set of entities, though by that it inherits the relations of the entity type of which instances are contained in the set (or am I thinking backwards?), so association sets of associations between sets is redundant, or at least odd, as the associations of the entities themselves already apply.

Or maybe I'm fundamentally not understanding something... Because: when are these associations used? Entity E1 is in set S1 and has a relation with entity E2, and E2 is in set S2 and in S3. I create instances of E1 and E2 in instances of sets S1 and S2 and S3. Because the definitions of E1 and E2 say they have a relation, why on earth do I have to define the relation AGAIN between S1 and S2/3? These are implicit, as E1 and E2 already have a relation defined.

Perhaps you should explain this more clearly in a follow up blogpost because how it's explained now is very obscure. I had a hard time following what you're saying in this post.

re: Entity Data Model 101 - Part 2

Mike Dodaro — Wed, 14 Feb 2007 23:13:46 GMT

RE: Regarding "inheritance" in the database... what if the schema models inheritance where the sub-class has its own PK, and has an FK to the base clase (1:1 relation)?

This is not supported mapping in current EDM.

re: Entity Data Model 101 - Part 2

Mike Dodaro — Wed, 14 Feb 2007 23:19:19 GMT

RE: AssociationType definition specifies the shape of the link table, while the AssociationSet specifies the link table itself.

I think of this in logical rather than structural terms. In this sense the reason for declaration of both an Association and an AssociationSet is that the declaration of the Association defines an Assocation type while the AssocationSet specifies a logical container for instances of the Association. Types and instances are fundamental to object oriented programming. Declaring an EntityType or an Association in the Entity Data Model is analogous to declaring a class. In programming languages a class defines the formal structure of a data type, but memory must be allocated to contain instances of the data type. The Entity Data Model stores instances of entities and associations in a database, so instead of memory allocation, the association must be mapped to storage. Declaration of the AssociationSet inside an EntityContainer provides the logical scope for instances of the Association. This logical grouping of Association instances is mapped to storage structures using storage metadata and a mapping schema. The storage metadata and mapping schemas will be discussed in future posts to this blog, or you can consult the documentation that ships with the February CTP release of ADO.NET.

re: Entity Data Model 101 - Part 2

Douglas Husemann — Thu, 15 Feb 2007 00:30:22 GMT

Know it probably won't be in version 1. But I would like Temporal and Spacial support.

If this can be done through extentions that would be ok also.

thanks

re: Entity Data Model 101 - Part 2

Frans Bouma — Thu, 15 Feb 2007 00:47:07 GMT

Mike, ok. I had to re-read that reply a couple of times, so let me suggest that for the final documentation it's described in more layman's terms, although I am familiar with the theory behind o/r mapping, meta-data etc. (it's my job after all)

What I find odd still is why the association set inside a container is providing a scope for the association instances, while the association is declared in that same container... Perhaps it's useful in a situation which isn't covered by your example (likely) but I don't directly see the necessity of the association set declaration when I look at your example.

The February CTP isn't out yet, or is it released yet?

re: Entity Data Model 101 - Part 2

Mike Dodaro — Thu, 15 Feb 2007 06:06:54 GMT

Frans,

I had to call in the big guns to get to the bottom of this. Abstract syntax is not my forte. But, I have it on good authority that the real explanation runs as follows:

Let T and U be entity types.

Let TU be a relationship type from T to U.

Let ts be an entity set over entity type T.

Let us1 and us2 be entity sets over entity type U.

Let t be an entity within ts.

Now, in which set (us1 or us2) should we look to find the entity related to t? You could imagine that t would contain an indicator (say, the string “us1” or “us2”) to tell us which table to look at, but it’s difficult to enforce referential integrity in the underlying database if we allow that kind of flexibility. So instead, we require relationship set definitions to say, once and for all, where to look.

Putting this in laymans terms will be interesting.

Trio-o-Links

Writing about Programming, Programming about Writing — Thu, 15 Feb 2007 08:44:58 GMT

Here are a few interesting blog posts. Eric White's Functional Programming Tutorial is a few months old

re: Entity Data Model 101 - Part 2

Frans Bouma — Thu, 15 Feb 2007 11:46:28 GMT

Mike: aha, I think we're getting closer. You see, I was thinking along these lines:

any entity instance related to t is referenced at runtime by t, so navigating to that related entity object is easy via the TU definition: it points you to the place where to look.

I think (bash me if I'm wrong) what you're describing here is more along the lines of: (bad metaphore up ahead, but it was as close as I could think of)

see the entity sets as datatables in a dataset and the associations in an association set as the datarelations between the datatables in a dataset. Am I close?

Because indeed, if you don't define the association set in _THAT_ situation, it's hard to define to which entity instance u a given t is related to because you have two sets with u's.

I was thinking along object references, as the entity framework from my point of view (POV) is seen as a way to perform o/r mapping, but that's of course not what you're working with, as the entity framework is a way to define entities on the level of an RDBMS.

I still find it a bit hard to understand why you have two association definitions though, as it seems to me at runtime one is unnecessary (i.e. the association defined on the entity itself, as it's meaningless IMHO, because without the association set definition, you can't find a related entity anyway)

re: Entity Data Model 101 - Part 2

Mike Dodaro — Thu, 15 Feb 2007 22:27:08 GMT

Frans,

Your intuition is right regarding relationship sets being like a little datasets holding the pairs of references.

We can’t just use relationship sets without also having relationship types because we want to be able to emit classes to describe entity types, which includes all the navigation properties needed for relationships on that entity type. We emit one class per entity type, not one class per entity set. Hence we need to know the “shape” of relationships (ie the names of their roles, the target multiplicities, and their target entity types) independently of both entity and relationship sets. This information is captured in the relationship type definition.

Entity Data Model 101: Part 1

ADO.NET team blog — Thu, 15 Feb 2007 23:56:02 GMT

Most developers are familiar with the Object/Relational Mapping (ORM) problem: databases use the abstraction

Mapping 101: Part 1

ADO.NET team blog — Mon, 26 Feb 2007 22:39:23 GMT

Now that you’re getting accustomed to the Entity Framework and Entity Data Model ( Entity Data Model

Mapping 101: Part 2 - Association Mapping

ADO.NET team blog — Thu, 10 May 2007 23:38:07 GMT

Continuing along with posts on the essentials of Entity Framework mapping (see Mapping 101: Part 1 ),

Entity Framework starting points

ADO.NET, LINQ, DataSet and other fun .NET technology — Fri, 03 Aug 2007 23:18:32 GMT

I was recently asked what a high level list of good starting points for the Entity Framework is. This

re: Entity Data Model 101 - Part 2

siriuslek — Thu, 09 Aug 2007 17:41:47 GMT

Hi here how are you? I am newbie in blogs.msdn.com so i hope i will get some friends here :)

Entity Framework - Post 1 of "Many", providing some links

Mike Taulty's Blog — Fri, 10 Aug 2007 02:55:46 GMT

Note: Some of the posts referenced in this post (!) are likely to be more out of date than others but...

re: Entity Data Model 101 - Part 2

James Hancock — Sat, 15 Sep 2007 16:53:00 GMT

Hi all,

I've been reading your articles, and trying to figure out if .net entities will handle our case. It sounds like from the above that entities has the same limitation as Linq to SQL though...

All of our tables are setup like this:

ID (uniqueidentifier, PK)

Modified (datetime)

ModifiedByID (uniqueidentifier)

Changed (bit)

I need to build a base class that handles these fields and maintains their information on changes etc.

I then need to inherit from this base class and add additional properties and methods.

But from your explaination above, it appears that the base class must have a unique table name which won't work.

Is what I'm trying to do possible?

LINQ to Entities

BonzBlog Michaela Juřka — Mon, 17 Sep 2007 22:07:22 GMT

Poslední reinkarnace LINQu, o které jsem se zmínil v přehledovém článku , je LINQ to ADO.NET Entities,

LINQ to Entities

BonzBlog Michaela Juřka — Mon, 17 Sep 2007 22:08:55 GMT

Poslední reinkarnace LINQu, o které jsem se zmínil v přehledovém článku , je LINQ to ADO.NET Entities,

Next-Generation Data Access

Cristian's Blog — Wed, 03 Oct 2007 11:08:35 GMT

SQL Server 2008 is at the door and the same stands for Visual Studio 2008. The data access strategy is

ADO.NET team blog : Entity Data Model 101 - Part 2

Dating — Sat, 31 May 2008 14:14:35 GMT

Entity Containers In part one of this article we looked at declarations of entity and association types in conceptual schema definition language (CSDL). Now we have to be specific about where instances of those types are stored, which we refer to as “scope”

ADO.NET team blog : Entity Data Model 101 - Part 2

Weddings — Thu, 05 Jun 2008 12:09:00 GMT

New and Notable 141

Sam Gentile's Blog — Wed, 03 Dec 2008 18:21:48 GMT

Found some time to blog. Smart Client/UI Architecture V2 of the User Interface Process Application Block (UIPAB) is out from PAG [via Mike ]. I must confess to being confused on how this is different than CAB as "designed to abstract the control

re: Entity Data Model 101 - Part 2

Gaurav — Thu, 23 Jul 2009 18:34:07 GMT

I'm connecting DB2 using DB2 .net provider. Inside the storage model under EntitySet element, there is an attribute called Schema which is hard coded with value of schema name from where that table came from. Now we have different schema name for various environment that we have like test, model, prod etc. How can change it at deployment time to point to correct schema.

please mail me at gaurav.vijaywargia@gmail.com