Path: newssvr20.news.prodigy.com!newsmst01.news.prodigy.com!prodigy.com!news.glorb.com!logbridge.uoregon.edu!arclight.uoregon.edu!news.netins.net!not-for-mail From: "Dawn M. Wolthuis" Newsgroups: comp.databases.theory Subject: Re: Pizza Example Date: Sun, 4 Apr 2004 13:11:13 -0500 Organization: netINS InterNetNews site Lines: 72 Message-ID: References: <6sWdne-mF-RrhO3dRVn-hQ@comcast.com> NNTP-Posting-Host: 199.120.93.7 X-Trace: news.netins.net 1081102281 15729 199.120.93.7 (4 Apr 2004 18:11:21 GMT) X-Complaints-To: usenet@netins.net NNTP-Posting-Date: Sun, 4 Apr 2004 18:11:21 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Xref: newssvr20.news.prodigy.com comp.databases.theory:24991 "Laconic2" wrote in message news:IoudnTt1MJRAs-3dRVn-ug@comcast.com... > > 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? I once heard that there is a philosophy difference among news writers about whether the person writing up the story should have some previous knowledge of the subject matter or be ignorant of it. When it comes to database design, I'd have to disagree with you and suggest that a business analyst who specializes in a particular vertical application will, in general, do a better job with the data design than someone who doesn't know it. When I wrote programs for public television in the early 80's, I stopped turning the channel when they were begging for money -- getting a feel for their promotional practices helped me design the software (including the data structures) better, ask better questions, etc. So, I'll support my choice of a pizza application, figuring that many of us can make many valid assumptions -- at least enough to provide a response to my question that is helpful (at least to me) in understanding how relational modelers think about the data. Of course, I will grant that if you were to do an implementation of this next week you might want to have a few interviews with the users & owners of the application to be sure you hit the nail on the head. For the purposes of my question, feel free to pretend you are the user and make the type of assumptions you would with the limited knowledge you have of a pizza ordering system. Cheers! --dawn > > > > 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.