Re: Another view on analysis and ER

"Jon Heggland" <jon.heggland_at_ntnu.no> wrote in message news:fj6737$o2p$1_at_orkan.itea.ntnu.no...
> Quoth David Cressey:
> > Here's a website I stmbled across:
> >
> > http://www.islandnet.com/~tmc/html/articles/datamodl.htm
> >
> > Note that, at the start of the introduction, the author says that
analysis
> > is the most important part of any project. That's rather different from
the
> > impression I've gotten in response to my topic on "what is analysis".
>
> Well, that depends on what analysis is. It seems this guy thinks it's
> the same as data modeling, which in turn is the same as developing a
> graphical representation of the client's needs and processes. Is it?
> Furthermore, you could interpret Marshall's and my response as "we don't
> do analysis, we just start coding", but I don't think that's what we
> mean. Myself, I'm skeptical of presenting analysis as a very separate,
> distinct kind of activity, defined by the kinds of artifacts it
> produces, i.e. "pretty pictures" to use Bob's term.
>

Not all modeling is analysis. Some of it is design. In particular, I'm going to claim that you discover attributes, but you design relvars. I've already have the second claim confirmed by Bob and others.

Bob's distaste for pretty pictures should not obscure the mian theme. A model isn't a "pretty picture" as such. Rather, a "pretty picture" is the projection of a model on a flat screen. Other projections have been proposed. A table written on a whiteboard, with some imaginary sample data written into it, proposed by another participant, is another projection of a model on a flat screen.

Whether a pretty picture was worth the cost of making it depends on what happens next.

> But I digress. This was what I meant to respond to:
>
> > By the way, I don't like the author's dialect of ER. In particular,
his
> > topic on "resolving many-to-many relationships" is, I believe
extraneous
> > to ER. His reification of a "watering" reminds me of the term
"association
> > entity" that someone wrote in reposnse to me a few days ago.
> >
> > In analysis, there is nothing to resolve in a many-to-many
relationship.
> > You only have to resolve it when you are designing relational tables or
> > relvars.
>
> Both yes and no. Reifying relationships can be helpful, but /not/
> because "Many-to-many relationships cannot be directly converted into
> database tables and relationships". The point is rather to make it
> easier to discover their properties---their attributes, mainly, but
> potentially also other things, e.g. constraints. When I discover a
> many-to-many-relationship, I usually make it a box, with a name, and ask
> if there is anything else we want to be able to say about this thing.
> Often, there is. If there isn't, I can demote it to a line again.
>
> This mainly applies to many-to-many-relationships, because business
> rules / attributes / constraints regarding a one-to-many-relationship
> are often better relegated to the entity on the many-side (though not
> always, of course). It has little to do with the implementation (or
> design?) of many-to-many-relationships in relational databases.
>
> Some might argue that reifying relationships is unnecessary, since
> relationships in "good" E/R dialects can have attributes. What, then, is
> the difference between an entity and a relationship?

If you look at the metadata in the implemented database, none.

> The best answer I
> can think of is that an entity is identified by itself, while a
> relationship is identified by its entities. But what if something has
> more than one way of identification (i.e. multiple keys)? This is where
> classic E/R breaks down for me. A "relationship" may be identified by
> its entities, but also by (say) just one of its entities in combination
> with a subset of its attributes. And/or perhaps a subset of its
> attributes, disregarding any entities. Is it then a relationship, a weak
> entity, or an entity?
>
> This is turning into a rant against the classic(?) E/R notation, but
> here goes anyway. I think it's a bad idea that more than one kind of
> thing can have attributes. I think it's a bad idea that there are two
> (or more) different ways of indicating how something is identified.
> Relationship diamonds are required for non-binary relationships, but are
> just clutter for binary ones---bad idea.
>
> Fortunately, there is (at least) one E/R dialect that resolves all these
> issues, and in so doing, even makes the distinction between entities and
> relationships far less important.
>
> Apropos this distinction: As to whether marriage is a relationship or an
> entity, you said that one should listen to the subject matter experts. I
> have never had such an expert say to me, "No, that's not a relationship,
> that's an entity!" or vice versa. Have you?

Not in so many words. But they have said things like "a reservation for a certain car, on a certain date, by a certain customer has a way of identifying it. We call it a 'reservation number'. What you have now learned is that the UofD people think of a reservation as a thing in and of itself and not just an association between a customer and a car on some future date.

This tells you something you need to know about the problem statement: The database has to store reservation numbers.

It also tells you something you need to know about database design: you have two candidate keys for identifying a relationship, and eventually, a relvar. One is reservation number. The other is customer ID, car type, and date. If you declare primary keys in your database, you need to pick one of these. This could have consequences for performance, ease of programming, "natural joins" etc. etc. You also need to anticipate that the application programmers are going to want to be able to find a reservation, or the absence of a reservation (CWA), based on the reservation number, based on a slip of paper the customer hands the clerk, or based on the customer, the car type, and the date.

In some cases, the business rules will make the design decision for you. In other cases, the business rules are silent on this score. Received on Wed Dec 05 2007 - 16:50:26 CET