Re: Pizza Example

From: Dawn M. Wolthuis <>
Date: Sun, 4 Apr 2004 09:25:43 -0500
Message-ID: <c4p5td$sck$>

"rkc" <> wrote in message news:KjUbc.26386$
> "Dawn M. Wolthuis" <> wrote in message
> news:c4o2at$frb$
> > "rkc" <> wrote in message
> > news:QtLbc.26194$
> > >
> > > "Dawn M. Wolthuis" <> wrote in message
> > > news:c4nglq$7pt$
> > > > I'll try to see if I can get the essense of the display of data in
> > > pizza
> > > > example to be clearer by removing the first few columns so it
> > > wrap.
> > > > I hope this displays better. Thanks. --dawn
> > > >
> > > > Size....Crust.......Sauce.....Cheese.........Topping
> > > > 16" Chicago Tomato Mozzarella Pepperoni
> > > > Feta Black
> > > > Parmesan
> > > Start with your desired 'display' and apply the rules of
> > > You seem to bright to not understand that, so you must be trying to
> > > make some other point.
> >
> It is that I suspect that someone who thinks in terms of normalized data
> > would not think about the problem domain in the same way. For example,
> > perhaps someone would decide that the number of combinations was a
> > relatively small finite number at this point in time and for the
> foreseeable
> > future and might make a table of all possible combinations of pizzas
> > generated candidate key. Then that would be placed as a foreign key in
> >the
> > ORDER_ITEM table.
> Really? What would that table look like? A spreadsheet?

Yes, all of my attempts to look at this through the eyes of an RDBMS mindset lead to bunches of "spreadsheets" -- that's the idea, right? The model that I "think with" isn't in spreadsheet format, but I can pretty much model it directly in XML or PICK given that I am not constrained to spreadsheets. Am I missing your point?

> > So, you are right, I'm not simply asking for this data to be normalized,
> >but for it to be understood so that a relational database implementation
> >way of thinking is presented. I was going to simply use this as an
> >of the difference between how an XML/PICK model of the data would
> >look compared to
> > a relational model and when I normalized the data, I looked at it and
> > thought that it was unlikely that anyone would actually implement it
> > way. So, how would you do it?


> With no information other than your 'display' probably something
> like this:

> Orders(OrderID*)
> OrderItems(OrderID*, ItemNumber*, Size, Crust)
> OrderItemToppings(OrderID*, ItemNumber*, Topping*)
> Toppings(Topping*, ToppingType, Description)
> ToppingTypes(ToppingType*, Description)

So you would determine that Sauce, Cheese, and Toppings would all be toppings, of different types, and then you would validate all toppings against valid entries for that topping type, right? Yes, that's very helpful, thanks!

If I make it explicit in the spec that there are items that don't have a size or crust, would you still drag the "Size" and "Crust" attributes along with them with NULL values there or would you further normalize this then? If so, how?

> Since I work almost exclusively with MS Access as a front end
> development system getting back to your 'display' would be done
> (by me, anyway) using that systems reporting fuctionality.

I have heard so many people talk about using MS Access as a front-end to their RDBMS. I'm curious what it has that other tools are missing, but that's another topic. Thanks. --dawn Received on Sun Apr 04 2004 - 16:25:43 CEST

Original text of this message