Re: database design

I think our disagreement is minor, but not entirely trivial.

I am making more of a difference between analysis and design than you are.

And, even when it has to do with analysis, determining what part of reality to put in the model
and what part to leave out is predicated, in some way, to the intended use of the data.

For example, take an item like "Date of birth". Is this merely a date, or is it actually a time stamp,
with a date and time on it. Well, it depends on what you intend to do with the data. Again, is the
date of birth an attribute of a person? Well, in some versions of reality, a date of birth is not an
attribute of a person, but an attribute of a separate entity called a "birth". And there's a relationship between a birth and the person(s) being born, the person giving birth, and maybe some attending health care people.

Would I model reality that way for a personnel application? I don't think so. Would I model reality
that way for an obstetrics ward administration system? maybe.

Again, it depends on your intended use of the data.

I do, however, agree with you that sometimes you have to start modeling, or even begin building,
the database at a time when the final use is still quite hazy. I'll stand on my original statement that,
in those cases, you are making guesses about the intended use of the data.

Jan Lenders wrote in message <8orjj4$4cq$1_at_nnrp1.deja.com>... [snip]
>So, when you use "database design" only for the implementation you are
>right. But when database design covers the whole track from analysis to
>implementation then you might even HAVE to start designing before any
>application has been determined.
Received on Sat Sep 02 2000 - 23:43:56 CEST