Re: Another view on analysis and ER

"Jon Heggland" <jon.heggland_at_ntnu.no> wrote in message news:fj8fff$3ed$1_at_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. :)
>

It's even simpler yet: if you're trying to understand a problem, then you're doing analysis; if you're trying to solve a problem you already understand, then you're doing design.

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

If the model represents a requirement, then I would consider the activity that produced it to be analysis; if the model represents a possible implementation, then I would consider the activity that produced it to be design.

>>> 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:
>
> 1. 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 does presentation have to do with the classification of collections of individuals into entities and relationships? Discovering and understanding the individuals that are interesting and how those individuals relate and interact is analysis. Presentation is about communicating that information.

> 2. 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 - 18:07:14 CET