Re: Another view on analysis and ER

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

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.

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

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

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.

-- 
Jon