Re: Another view on analysis and ER

"Jon Heggland" <jon.heggland_at_ntnu.no> wrote in message news:fje94d$gv7$1_at_orkan.itea.ntnu.no...

> I have tried to argue against the notion that most relvars correspond to
> entities (or entity classes/types, to be more precise), and that
> relationships correspond to foreign keys (except for
> many-to-many-relationships, non-binary relationships etc.).

I never had this notion. I hope you didn't read my comments wrong.

Even a so-called "entity table" exists to relate an entity to the values of its attributes.

So if a row in "Employees" says that: EmployeeID = 101, FirstName = "John",
"LastName= "Smith" and so on, all those values are doing is specifying the values of some attributes. The row can be said to be about an employee (an instance of an entity) but all of the data in the row specifies nothing but attribute values.

Actually, let me correct the above to make it a little more precise: it isn't the row that is about an employee. It's the data contained in a row. If I were to delete the row in one transaction, and then in a later transaction (or even the same transaction) insert a row that's about a different employee, the fact that it gets stored in the "same row" is completely irrelevant.

That is why RowId is such a bad idea.

In the course of this discussion, I've been coming to the notion that it would be good to think of a relvar that I might call an "entity table" as representing a unary relationship, one that involves only one entity.

Foreign keys to play a role, of course. Foreign keys do not exist in a "pure ER" model, in my dialect of ER. They of course must exist in an equivalent RM, for reasons you already understand completely. Received on Sat Dec 08 2007 - 16:00:21 CET