Re: Objects and Relations

On Feb 22, 10:32 pm, "Walt" <wami..._at_verizon.net> wrote:
> "JOG" <j..._at_cs.nott.ac.uk> wrote in message
>
> news:1172092159.136958.258750_at_m58g2000cwm.googlegroups.com...
>
> > On Feb 20, 2:18 pm, "David BL" <davi..._at_iinet.net.au> wrote:
> > > [snip]
> > > I still think we have a quite different understanding of what (in
> > > practical terms) we mean by "entity". I think you're still
> > > associating it with ERMs (even if you distinguish instance from type)
> > > while I'm not. Let me explain what I mean by that...
>
> > > You question whether written papers have an authors property or vice
> > > versa. For me that question only arises at the point where you try
> > > to create an ERM.
>
> > Well yes I do see that. But I /don't/ think those issues start at the
> > ERM, so I'm more than happy to address things outside the E/RM, at a
> > 'real world' level (apologetic quotes for obvious reasons).
>
> I'm a little confused by this. Perhaps I'd better explain what I use ERM
> for. I use it for talking with subject matter experts about the data.
> Subject matter experts never see the subject matter (aka universe of
> discoure) as one vast amorphous blob of reality. They always see the
> subject matter as made up of "things" and "associations among things".

It would be useful if you could qualify whether you mean instances or types.

> The word "entity" is just a fancy word for "thing". It has some advantages
> over "thing". One of them is that if you call a person a "thing", some
> people will be offended. If you call a person an "entity", no one will be
> offended. The word "relationship" for "association" ias a little more
> troublesome. In the RM, "relation" is used for mathematical relations
> which are thought of, outside the area of data management, as ordered
> tuples. "relationship" is a word that is used in the RM to describe
> something very much like a relation, except that the components of the
> tuples are referenced by name, and not by position.

I thought the RM community had hijacked the word "relation" for their own purposes (ie for where a tuple is a map from attribute to value).

> I'm so accustomed to thinking in terms of tables with rows and columns,
> that I almost never make the distinction between a "relation" and a
> "relationship", except in discussions like this one.
>
> At the other end of the spectrum, we have the entire universe of data
> values that are to be served up on demand by the database server attached to
> the database. It's convenient, for conceptual purposes, to connect each
> value to an attribute, each attribute to a domain, and also each attribute
> to some characteristic of either an entity or a relationship (a
> characteristic that can be described by data). This is where an ER model
> comes in.
>
> An ER model is not a database design. It is an analysis of the connection
> between the data and the "real world".

I'm not sure I agree. Consider a database that is to store vast amounts of facts about a relatively small set of humans. RM copes very well by using a large number of relations. One relation can record birth events, another marriages, and a third can store eye colour. It is straightforward to add many more relations. The knowledge about a particular human is spread around, and only in the relations that are relevant to that human. For example a human may not be married, or may not have eyes.

The relations give you exponential order classifications. For example, you can ask for the married, female, green eyed, brain surgeons born on a Saturday. You can have more classifications than humans!

The corresponding ERD will be rather useless in this example. Furthermore it provides no help to establish the connection between the RM and the "real world".

I would say that an ERD is all about (simplistic) classification. The boxes are entity-types not particular entities. This is only useful where it is appealing to uniquely classify the entities.

> An RM, constructed on the basis of an ERM, might be called a "logical
> database design". The propositions captured by such an RM are only the
> "obvious" propositions suggested by the attributes that describe the
> entities and relationships, namely one proposition for each entity, and one
> for each relationship. In many situations, these obvious propositions are
> the only ones needed for a satisfactory database implementation. So, if you
> do ERM, you don't need to count on propositions falling from the sky.
>
> That's about it.
>
> It took me a long time to come to this view. When I first saw ERM, I
> thought of it as "RM lite". That's not the best way to use it. The best
> way to use it is to distinguish between data analysis (ERM), and abstract
> (logical?) database design, (RM).
>
> Just my two cents.
Received on Fri Feb 23 2007 - 02:32:13 CET