Re: Pizza Example

On Tue, 06 Apr 2004 01:14:39 +0200 in comp.databases.theory, mAsterdam <mAsterdam_at_vrijdag.org> wrote:

>Alan wrote:
>
>> Anyway, I generally try to explain to implementers that implementation is
>> not the time to design a database. Start with the business requirements,
>> create an ERD, and then create the relational schema. So, I would not go
>> from the requirements directly to the tables- at least not in theory. It's a
>> great way to miss cases of specialization, etc.
>
>In the context of this thread: just assume whatever you need to assume
>about taking pizza orders and state your assumption. If there is some
>important dilemma: just ask, and Dawn (or maybe somebody else) will help
>you out. These dilemmas make this thread a worthwhile read.

ISTM where the design comes in is in making decisions like whether to have separate tables for different properties of items, or have a bunch of properties in a single table and add property type columns, and a lot of that decision making comes from requirements and analysis.

Do you really need to be able to distinguish between cheeses, sauces, and other kinds of toppings, or is a single table of toppings acceptable, perhaps with an additional attribute to say whether it is meat, cheese, sauce, or other?
Does the business want to be able to ensure that customers are offered selections of meats, cheeses, sauces, others, or have some other reason for wanting to distinguish between items? Perhaps different types of items come from different suppliers: but then that's really a different issue entirely; or maybe there's multiple suppliers for different types of items, but all suppliers of an item type can supply all the items of that type: a different issue. Is there a need to know that a cheese is not a meat, or is that need driven by some other unstated factor?

And then there are flexibility characteristics. How easy is it to change the model to handle half and half orders? What about offering bottled drinks?

The different types of models allow you to concentrate on different aspects of the database: from the strategic future concepts, down to implementation performance, allowing you to defer thinking about unnecessary details until after you've thought first about the necessary requirements.

The conceptual model should handle anything the business can reasonably conceive of handling or doing to handle an order, at a high strategic level: in the example, orders for a reasonable variety of hand deliverable oven heated foods and cold drinks, and rules for constraints and contingencies.

The logical model needs to handle everything the business currently does, allow for the flexibility to add anything in the conceptual model, do so without breaking the conceptual model, at an immediate tactical level: all the menu items and obvious extensions, all the processes involved in fulfilling the order, and business rules enforceable within the conceptual model.

The physical model needs to handle everything in the logical model, in a timely and effective manner, without imposing undue demands on those operating, maintaining, or accessing the database, in any way anticipated by current demands, at a data and process implementation level: focusing on the pragmatic requirements for information access, process automation, business rule enforcement.

Just my $.02

-- 
Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada

Brian.Inglis_at_CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
    fake address		use address above to reply