Re: Another view on analysis and ER

"Jon Heggland" <jon.heggland_at_ntnu.no> wrote in message news:fjb0nv$jnt$1_at_orkan.itea.ntnu.no...
> Quoth Brian Selzer:
>> "Jon Heggland" <jon.heggland_at_ntnu.no> wrote in message
>> news:fj8fff$3ed$1_at_orkan.itea.ntnu.no...
>>> 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.
>
> Too simple. It assumes that understanding is binary: either you
> understand the problem, or you don't. Furthermore, that you know whether
> or not you understand it.
>

I think it is just that simple: if you don't understand the problem, then you're shooting in the dark. I would consider trial and error is a form of analysis, not design. Understanding is binary. It may be possible to break down a big problem into a heirarchy of more manageable subproblems, such that a set of solutions to each subproblem is a solution to the big problem, but that doesn't mean that understanding is any less binary.

>> 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.
>
> And if it represents both? How can you sharply delineate one from the
> other?
>

I don't think it /can/ represent both. Is there such a thing as a possible requirement? If there were, then it would clearly be implementation-specific.

>>> 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.
>
> I can only repeat what I've said: As far as I can tell, the decision of
> whether or not an "individual" is an entity or a relationship is quite
> arbitrary---it may have aspects of both. To communicate all these
> aspects, it may be necessary/useful to present it sometimes as an
> entity, and sometimes as a relationship. If instead you insist on
> classifying your individual as /either/ and entity /or/ a relationship,
> you lose information.
> --

I'm thinking that I'm agreeing with you on this. If an entity has attributes, then it is also a relationship. If a relationship is greater than the sum of its parts, then it is also an entity.

> Jon
Received on Sun Dec 09 2007 - 15:13:35 CET