Re: One-To-One Relationships

From: David Cressey <>
Date: Sun, 02 Dec 2007 14:34:47 GMT
Message-ID: <boz4j.1963$3W.201_at_trndny04>

"JOG" <> wrote in message
> On Dec 1, 11:08 am, "David Cressey" <> wrote:
> > "paul c" <> wrote in message
> >
> > news:et24j.80277$cD.13174_at_pd7urf2no...
> >
> > > JOG wrote:
> > > ...
> > > > Why don't you first define the term entity, as opposed to just
> > > > assuming their existence as axiomatic. I look forward to there being
> > > > absolutely no room for debate or disagreement! Look, you get a lot
> > > > respect on this forum, particularly off myself, but this does not
> > > > excuse arrogance, so now we are all ears.
> > > > ...
> >
> > > PMFJI but this is just too much fun not to have a go: Something that
> > > exists?
> >
> > Anything that has been reified, and whose instances display haeccity.
> >
> > Sorry, I couldn't resist.


> And not a mention of quiddity. tut!

> Although I have no doubt over-reacted to Jan's dig at the discussion
> (ah, the cold light of day), let me give an example as to why I find
> the breakdown into entities and relationships deleterious. Say I have
> two entity types staff_members and subjects, and a relationship
> teaches:

> This is all good and fine until a requirement changes that we need to
> record the day the lecture is given on. To denote the is new
> information, well I now longer haver a binary relationship, but a
> ternary one, and that requires a rewrite of the E/R representation
> (given that it is a graph). I need a new lecture associative entity
> with 'day' as an attribute.

> There is no need for such brittleness in the face of what is a
> relatively trivial schema change. If one views relationships and
> entities on the same keel to start with its just a simple case of
> adding an extra attribute. The problem is that E/R views binary
> relationships as somehow a different species from n-ary ones, and Kent
> critiqued this very issue in his excellent book 'data and reality' 30
> years ago.

I would like to suggest that there are two kinds of schema changes: schema changes that are the result of different design decisions but based on the same information reqirements; and on the other hand, schema changes that are the adaptation to new requirements. If I were to label either of these two "trivial" it would be the former. Changing the informations requirements is definitely non trivial, regardless of how easy the solution turns out to be.

In the relationship:

> staff_member -- teaches --> subject

The existence of an entity called a "lecture" is not made explicit anywhere. You may think it's implicit in the terms of the relationship, and that "everybody knows" that if a staff member teaches a subject, lectures are involved. I assure you that in the real world, the subject matter often involves concepts, roles, contracts, etc. etc. that no one "knows about" beforehand, let alone everybody.

> staff_member -- holds --> lecture <--- involves -- subject

You can't even state this proposition if there is no such thing as a "lecture". And if there is such a thing as a "lecture" then it's worth making that explicit.


> We describe entities via propositions. We describe relationships via
> propositions. Surely there is a common theme there.

The reverse is equally true: we state propositions in terms of entities. Received on Sun Dec 02 2007 - 15:34:47 CET

Original text of this message