Re: One-To-One Relationships
Date: Sat, 1 Dec 2007 09:56:23 -0800 (PST)
On Dec 1, 11:03 pm, JOG <j..._at_cs.nott.ac.uk> wrote:
> On Dec 1, 11:08 am, "David Cressey" <cresse..._at_verizon.net> wrote:
> > "paul c" <toledobythe..._at_ooyah.ac> wrote in message
> > > 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 of
> > > > 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
> staff_member -- teaches --> subject
> 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.
> staff_member -- holds --> lecture <--- involves -- subject
> 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.
> We describe entities via propositions. We describe relationships via
> propositions. Surely there is a common theme there.
When I look at your ER diagrams I see the following nouns
and the following verbs
(where Day comes from attribute of Lecture).
Consider the original intensional definition
teaches(StaffMember,Subject) :- StaffMember teaches Subject
which I'm guessing you were thinking becomes
StaffMember holds lecture involving Subject on Day
As an aside I would tend to avoid nouns that don't directly take part in the predicate, and therefore remove any mention of lecture.
teaches2(StaffMember,Subject,Day) :- StaffMember teaches Subject on Day
Note that the nouns from the ER diagrams (ie entity types or entity attributes) have tended to appear as attribute names in the predicates.
"If one views relationships and entities on the same keel to start with...".
However at least in this particular example, I would say that the intensional definitions of the predicates distinguish the entity types (cf nouns) from the relationships (cf verbs).
One of the problems with the ER approach is the tendency to commit early to a decision about what nouns are attributes and what nouns are entities (eg the idea to think of Day as an attribute of Lecture) Object Role Modelling avoids that.
"The problem is that E/R views binary relationships as somehow a different species from n-ary ones"
My understanding is that ER diagrams quite happily represent n-ary relationships (because a relationship is represented using a diamond shape to which any number of entity types may be connected).
That being said, you are actually right if Day is an attribute, because the ERM doesn't support relationships involving attributes of entity types.
ie the ERM won't let you define a ternary relationship that is the counterpart to the predicate teaches2(StaffMember,Subject,Day) unless you make Day a separate entity type. Received on Sat Dec 01 2007 - 18:56:23 CET