Re: Pizza Example

> Of course, of course, but using a Pizza example is a way to provide a
> problem domain of which most of us are somewhat comfortable.

And that's precisely the problem. A problem domain where most of us feel comfortable is a problem domain where we each come to the table with a large number of assumptions. When those assumptions coincide, we move forward quickly. When they don't, we have the illusion of a common data model rather than the reality of one.

Give me a problem domain that I don't know anything about, and a subject matter expert that is willing to work with me on a data model that is subject matter relevant, and I'll come up with something. Give me a subject matter that I think I know, but really do not, and you'll see me make a fool out of myself.

I know how to order pizza from a pizza place, but I never worked at one. Am I a subject matter expert?

 >
> And if you concept of a pizza place includes selling Neapolitan Ice Cream
> with toppings, then I'm sure I can learn something from the way you would
> model that too. So, I can accept some human interpretation of the
situation
> in order to keep the requirements statement short.

They aren't just short, they are laconic. As I said before, it depends. If the mission of the database users is order processing, normalization is important, at least when it comes to data that is written during order placement and order fulfillment. (It would probably be ok to update data that is less than fully normalized when a new kind of cheese comes along.) If the mission is tactical marketing, then a multidimensional model might be more useful.

And even the above statements depend on how the design is going to be used. If its a construction model that is going to be used to create a schema of tables, columns and constraints in a fairly mechanical fashion, I might design it one way. If it's intent is to be an abstract model, from which a schema can be derived, then I might model it differently. Received on Sun Apr 04 2004 - 17:51:29 CEST