Re: Another view on analysis and ER

"Jon Heggland" <jon.heggland_at_ntnu.no> wrote in message news:fjba56$p98$1_at_orkan.itea.ntnu.no...
> Quoth David BL:
> > I wasn't actually intending that Location be necessary for
> > identification of a marriage. I'll make the intensional definition
> > clearer:-
> >
> > married(Husband, Wife, Location) :-
> > Husband is *currently* married to Wife
> > and they (last) got married at Location
> >
> > Candidate keys are { Husband } or { Wife }, enforcing monogamy
> > integrity constraints.
>
> So Marriage is a relationship between a Husband and a Wife, yet it is
> identified by either, not the combination? I thought I finally had the
> common definition of "relationship" pegged, and then this comes along.
>
> I suppose I am looking for rigor where there is none, though. The
> definition of entity---something that is identified independently of
> other entities---is also rather half-baked. Take weak entities, for
> instance.
>
> >> What if
> >> Location does not correspond to an entity type? I assume that might be
> >> the case if it were simply a spatial coordinate. Is marriage still a
> >> relationship? If not, what is is?
> >
> > I agree that it is strange to think of a spatial coordinate as an
> > entity type.
>
> My attempted point was to posit that a Location might be a non-entity
> attribute, /or/ an entity (say, a church or temple or official building
> of some kind), and to ask whether this made any difference as to whether
> the marriage is a relationship or an entity.
>
> >>> By contrast the following predicates are consistent with thinking of a
> >>> marriage itself as an entity
> >>> husband(MarriageId, Husband).
> >>> wife(MarriageId, Wife).
> >>> location(MarriageId, Location).
> >>> or maybe just
> >>> married(MarriageId, Husband, Wife, Location)
> >>> Now whether one "thinks in ER" or "thinks in propositional encodings",
> >>> there has to be good reason to introduce a MarriageId.
> >> Perhaps marriage certificates has a unique number stamped on them, and
> >> you want to record this in your database.
> >
> > Yes, that could be a reason. Consider the following intensional
> > definition
> >
> > married(MarriageId, Husband, Wife, Location) :-
> > The marriage identified by MarriageId was
> > between Husband and Wife at Location.
> >
> > In this case the relation can record marriages that are no longer
> > current, and the only candidate key is { MarriageId }.
>
> And you say this now is an entity, right? But what if the MarriageId
> represents an entity, just like Husband and Wife presumably do? Do we
> not then have a situation analogous to the first case, except that the
> relationship is ternary? It is, after all, identified by one of the
> entities it relates, just like the first Marriage.
>
> > Well I can see you are technically picking holes in my
> > "characterisation" of entity, but I wasn't really putting forward a
> > definition. I think the "characterisation" was very informal and more
> > along the lines of being necessary but not sufficient.
>
> Why necessary?
>
> > Actually, I would prefer to steer clear of trying to pin down such
> > informal words as "entity" and "relationship".
>
> But that is one of the main points of my involvement in this discussion!
>
> > However, I still believe particular entity types are implicit in the
> > intensional definitions of the predicates. How can they not be?
>
> I think the burden of proof is on your side here. I have tried to show
> that predicates can be interpreted as both entities and relationships
> (and probably even as parts of entities). You seem to admit as much,
> given that you you use the word "informal" about the whole E/R shebang.
> I note that Jan Hidders claimed that the E/R distinction carries through
> to the logical/relational level, but I cannot see how---except by
> arbitrary claims along the lines of "if a relvar has but one key, and
> this key's components are all foreign keys, then the relvar represents a
> relationship".
>

Unlike Jan, I do not claim that the distinction between entities and relationships carries through to the logical/relational level.

Indeed, the more I look at entity tables, the more I think that they don't really describe entities at all! What they really describe are "unary relationships" that span the attributes that "pertain to the same entity". In this way of looking at things, the only thing that makes it down to the logical/relational level are relationships. The entities are abstractions.

Given that relvars, as currently implemented, identify the attributes that make up the tuples by name, rather than by position, I think it's fair to say that the state of a relvar is a "relationship" rather than a "relation". Most of the regulars in here use the word "relation" in the data modeling sense, and don't make any distinction between tuples whose components are known by name and tuples whose components are known by position. I adopt that terminlogy myself. Received on Fri Dec 07 2007 - 14:15:28 CET