From: tchild@autodesk.com (Timothy Child)
Newsgroups: comp.databases.theory
Subject: Re: Logical design experiences?
Date: 18 Dec 92 17:25:16 GMT
Reply-To: tchild@autodesk.com
Organization: Autodesk, Inc.

In article 1@ilp.mit.edu, gold@ilp.mit.edu () writes:
> Hi!
> 	I am currently working on a large database project and am
> trying to convince some co-workers that a quality logical design is 
> more than just "window dressing."  I am able to present what I 
> believe are fairly detailed explinations of the benefits of creating 
> and maintaining a quality logical design on the creation of the 
> physical database, the creation of the application program, and the 
> maintenance of the system.
> 
> 	However, since it's difficult for me to come up with many 
> scenarios where a poor logical design will cause problems in 
> different areas, I am seeking other people's experiences to show these 
> co-workers how the logical design affects development and maintanence
> of a system.  Please tell me of any positive or negative experiences you
> have had with developing databases with or without quality logical
> designs.  Any stories would be more than welcome.  If you know of any
> studies along these lines, please let me know.  Thank you very much.
> 
> 				- Mark Gold
> 				  gold@ilp.mit.edu

 There are a several ways to design databases. One way is the logical
 design approach and another is way a prototyping approach. A good
 logical design should produce three things:

  	Information (data) model

	Access model with access paths for queries

	Data size and volume semantics


 The information model should be constructed based on user
 requirements.  The model should contain descriptions of all the  major
 entities, relationships and attributes, and preferably normalized to
 third normal form for a relational DB. Having a good data model allows
 you play with what if? scenarios. This allows you to verify the
 design, and verify the requirements. One of the biggest problems in
 design is verification of the users requirements.

 The access model coupled with the data size and volume semantics
 allows modelling of queries and access patterns. This will give you
 an idea of what sort of database operations are involved in a query or
 access.  For example, if you find you are doing too many joins for a
 particular query you could decided to use a lesser degree of
 normalization, or introduce redundant data into the implementation.
 With an information model and an access model you can readily
 figure out the side effects of doing this.

 Prototyping is another way to design databases. Take the user
 requirements do a minimal design and implement a prototype. RDBMS are
 good for prototyping compared to CODASYL ones. The prototype can be
 used to verify the requirements. Users often prefer prototypes as they
 can play around with them and kick the tires.

 Users often see models as to complex and abstract and don't understand
 them well.  For the modelling approach to work well the users must be
 trained in data modelling and and participate in it. On the other hand
 once a user sees a prototype they want the system implemented next
 week.

 The justification for logical design is that it helps minimize the
 risk of failure. A logical design can be used to express to the user
 and management that the database design team completely understands
 what the user wants and has a database design that effective meets
 these requirements.  Additionally it can be used to benefit the user
 by allowing them to see what their problem is. Other benefits of
 good logical design include providing information to be used
 in planning the rest of the development.

 Sorry I can't provide specific examples of how logical design saved the
 day. It shouldn't be a matter of specifics but a matter of principle;
 this is our database design methodology, it works, it's low risk,
 and why take chances?

 -Tim.