Re: Another view on analysis and ER

From: Jon Heggland <jon.heggland_at_ntnu.no>
Date: Thu, 06 Dec 2007 10:30:00 +0100
Message-ID: <fj8fff$3ed$1@orkan.itea.ntnu.no>

Quoth David Cressey:
> "Jon Heggland" <jon.heggland_at_ntnu.no> wrote in message
> news:fj6737$o2p$1_at_orkan.itea.ntnu.no...

>> Quoth David Cressey:

> 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.

Yet when are discovering attributes, you presumably write them down somehow. Is it the case that if you do it using E/R notation, you are doing analysis, but if you do it using some relation- or predicate-based representation, you are doing design?

Or perhaps it's simpler: Analysis is what you're doing when you're talking with the subject matter experts; design is what you're doing when you're not. :)

> 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.

Ceci n'est pas une pipe... Then is the model wholly intangible, existing only in a platonic sense inside the designers (or analyst's) head? Never mind, I see your point---but that doesn't answer my question: When is modelling design, and when is it analysis? A bald statement that relation-based models are designed doesn't cut it, even if it is seconded; I need rational arguments.

>> 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.

Definitely. But this is the (only) important bit. That a reservation is a "thing" is fluff, not crunch.

> 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.

So the thing in and of itself is still a relationship?

In most E/R notations, you cannot represent the alternate key---reservation number---if a reservation is a relationship. Vice versa, if it is an entity, you cannot represent the { CustomerID, CarID, Date } key. This means that you have to have an underlying model, of which any graphical E/R diagrams are merely simplified views. I agree to this, but it raises two points:

The underlying model cannot have a strict distinction between entities and relationships, since the same concept---reservation---can be thought of and presented as both. This relegates entity/relationship thinking to a question of presentation, not analysis.
What is the formalism (if any) of this underlying model? Is relational theory forbidden if I'm doing analysis? What can I use instead?

> 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.

You started with users telling you that reservations have reservation numbers; I believe all will agree that that is analysis. And you end up here with a "design decision". At what point did the transition from analysis to design happen?

I think I'll retract my initial definition of what analysis and design is, and use the one at the top of this post instead. :)

-- 
Jon

Received on Thu Dec 06 2007 - 03:30:00 CST