home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / database / theory / 657 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  4.1 KB
  1. Path: sparky!uunet!nntp1.radiomail.net!fernwood!autodesk!tropic!tchild
  2. From: tchild@autodesk.com (Timothy Child)
  3. Newsgroups: comp.databases.theory
  4. Subject: Re: Logical design experiences?
  5. Message-ID: <18177@autodesk.COM>
  6. Date: 18 Dec 92 17:25:16 GMT
  7. References: <1992Dec15.205623.1@ilp.mit.edu>
  8. Sender: news@Autodesk.COM
  9. Reply-To: tchild@autodesk.com
  10. Organization: Autodesk, Inc.
  11. Lines: 87
  12.  
  13. In article 1@ilp.mit.edu, gold@ilp.mit.edu () writes:
  14. > Hi!
  15. >     I am currently working on a large database project and am
  16. > trying to convince some co-workers that a quality logical design is 
  17. > more than just "window dressing."  I am able to present what I 
  18. > believe are fairly detailed explinations of the benefits of creating 
  19. > and maintaining a quality logical design on the creation of the 
  20. > physical database, the creation of the application program, and the 
  21. > maintenance of the system.
  22. > 
  23. >     However, since it's difficult for me to come up with many 
  24. > scenarios where a poor logical design will cause problems in 
  25. > different areas, I am seeking other people's experiences to show these 
  26. > co-workers how the logical design affects development and maintanence
  27. > of a system.  Please tell me of any positive or negative experiences you
  28. > have had with developing databases with or without quality logical
  29. > designs.  Any stories would be more than welcome.  If you know of any
  30. > studies along these lines, please let me know.  Thank you very much.
  31. > 
  32. >                 - Mark Gold
  33. >                   gold@ilp.mit.edu
  34.  
  35.  There are a several ways to design databases. One way is the logical
  36.  design approach and another is way a prototyping approach. A good
  37.  logical design should produce three things:
  38.  
  39.       Information (data) model
  40.  
  41.     Access model with access paths for queries
  42.  
  43.     Data size and volume semantics
  44.  
  45.  
  46.  The information model should be constructed based on user
  47.  requirements.  The model should contain descriptions of all the  major
  48.  entities, relationships and attributes, and preferably normalized to
  49.  third normal form for a relational DB. Having a good data model allows
  50.  you play with what if? scenarios. This allows you to verify the
  51.  design, and verify the requirements. One of the biggest problems in
  52.  design is verification of the users requirements.
  53.  
  54.  The access model coupled with the data size and volume semantics
  55.  allows modelling of queries and access patterns. This will give you
  56.  an idea of what sort of database operations are involved in a query or
  57.  access.  For example, if you find you are doing too many joins for a
  58.  particular query you could decided to use a lesser degree of
  59.  normalization, or introduce redundant data into the implementation.
  60.  With an information model and an access model you can readily
  61.  figure out the side effects of doing this.
  62.  
  63.  Prototyping is another way to design databases. Take the user
  64.  requirements do a minimal design and implement a prototype. RDBMS are
  65.  good for prototyping compared to CODASYL ones. The prototype can be
  66.  used to verify the requirements. Users often prefer prototypes as they
  67.  can play around with them and kick the tires.
  68.  
  69.  Users often see models as to complex and abstract and don't understand
  70.  them well.  For the modelling approach to work well the users must be
  71.  trained in data modelling and and participate in it. On the other hand
  72.  once a user sees a prototype they want the system implemented next
  73.  week.
  74.  
  75.  The justification for logical design is that it helps minimize the
  76.  risk of failure. A logical design can be used to express to the user
  77.  and management that the database design team completely understands
  78.  what the user wants and has a database design that effective meets
  79.  these requirements.  Additionally it can be used to benefit the user
  80.  by allowing them to see what their problem is. Other benefits of
  81.  good logical design include providing information to be used
  82.  in planning the rest of the development.
  83.  
  84.  Sorry I can't provide specific examples of how logical design saved the
  85.  day. It shouldn't be a matter of specifics but a matter of principle;
  86.  this is our database design methodology, it works, it's low risk,
  87.  and why take chances?
  88.  
  89.  -Tim.
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.