Re: Pizza Example

From: Dawn M. Wolthuis <>
Date: Sun, 4 Apr 2004 08:56:38 -0500
Message-ID: <c4p46s$hd3$>

"mAsterdam" <> wrote in message news:406fe30f$0$568$
> Dawn M. Wolthuis wrote:
> > In trying to get a better handle on relational database design compared
> > XML or PICK database design, I'm writing up the example below and got
> > on just how a relational theorist would likely design this.
> Will the true relational theorist please stand up ;-)
> One swampy area where one may get stuck in is in the use of
> constrained lists: the fields Cheese and Toppings
> have listvalues, with a constraint on
> the individual items (every individual value has
> to be present in a vocabulary).
> From earlier back and forth on that it looks
> like a sensitive issue. There are choices here,
> some of which depend on what we want, some depend on
> the DBMS, maybe some on both. When reverse
> engineering/refactoring it helps to know
> something about the target(s).
> Where *did* you get stuck?

I think Tony picked up on part of the issue I was having -- to keep the example short enough, I modeled only one proposition and it is a line item for a pizza. However, if one were to order something else, such as garlic bread, it might not have a sauce, for example. So the attributes that relate to Pizza would be overlapping with attributes for other items ordered (or completely distinct in some cases). So that brings us to types and sub-types, inheritance, and normalization rules. My problem was that I was ending up with too many tables EVEN FOR A RELATIONAL structure.

Also, with the model I used, I ignored both the fact that some attributes would not be needed for some items, but that some value lists would be different for different items. The user might be instructed to select no Cheese for garlic bread without cheese and to just select "Mozzarella" as the Cheese. This might be done with no database intelligence to indicate that Mozzarella is the only valid value for this item. An application programmer might decide to write the application differently and add constraints or even have a "Cheese?" flag for the display when the item is garlic bread, but the only constraint on the items that is "in the database" would be the validation lists for these possible item attributes.

> > ... Function/File: VALIDATIONS
> >
> > Purpose: This file maps a validation list name to the set of valid
> > and their descriptions
> >...
> Maybe it also helps to know someting about the source:
> could you show how/where this constraint is/should be
> enforced?

I believe in an RDBMS you would need to have separate tables, one per validation list, so that individual attributes (Cheese, for example) could be constrained by separate lists. So, in my attempt to normalize the data for an RDBMS, I did separate out all of the validation lists into individual tables. There have been some threads on this forum regarding this "problem" for relational databases.

Did that clarify? Thanks. --dawn Received on Sun Apr 04 2004 - 15:56:38 CEST

Original text of this message