home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / database / theory / 472 < prev    next >
Encoding:
Internet Message Format  |  1992-09-11  |  2.7 KB
  1. Path: sparky!uunet!mcsun!uknet!keele!csa09
  2. From: csa09@seq1.keele.ac.uk (Paul Singleton)
  3. Newsgroups: comp.databases.theory
  4. Subject: Re: Normalization and Relations
  5. Message-ID: <4052@keele.keele.ac.uk>
  6. Date: 11 Sep 92 13:38:18 GMT
  7. References: <gwtn05l.sjs@netcom.com>
  8. Organization: University of Keele, England
  9. Lines: 49
  10.  
  11. From article <gwtn05l.sjs@netcom.com>, by sjs@netcom.com (Stephen Schow):
  12. > There is a methodology called "Extended Relational Analysis" that goes into
  13. > how to design a relational model methodically.
  14. > 
  15. > It basically talks about identifying the entities of your model.  You can
  16. > generally use nouns to refer to these entities.  Each of these entities
  17. > will be represented by a table.
  18.  
  19. Shouldn't this be: "Each of these entities will be represented by a unique
  20. identifier"?  Simple attributes (e.g. 'name') of these may indeed be stored
  21. in a table.  It seems to me that traditional relational analysis likes to
  22. confuse an entity with a (hopefully) distinguishing attribute of that entity.
  23.  
  24. I think "functional data modelling" is more careful about this, but I haven't
  25. studied it.
  26.  
  27. > ... 
  28. > What you have to be careful of is that you could practically call everything
  29. > a noun and get totally out of control trying to normalize your data.  As has
  30. > been said earlier by someone in the group, if a particular entity is not of
  31. > unique interest by itself, or if it does not stand on its own as an entity,
  32. > then it probably shouldn't be one.
  33.  
  34. Sorry, why would you "get out of control"?  You might get close to the truth.
  35.  
  36. > There are many exceptions. If you are talking about gobs and gobs of redundant
  37. > data, then it may be worth it.  If you are talking about a one to many
  38. > relation, then it is neccessary.  There are many variables.  But I think it
  39. > is key to try to find a balance between absolute normalization and a more
  40. > conservative approach.
  41.  
  42. I think it is misguided and hopeless to "try to find a balance ..." without
  43. *first* analysing the application data thoroughly and uncompromisingly.  I
  44. think there should be two data models:
  45.  
  46.   1)  an exhaustive and fastidious analysis of the application, e.g. with
  47.       attributes such as 'colour' being treated as entities unless we can
  48.       be absolutely sure they are OK as attributes;
  49.  
  50.   2)  a pragmatic representation schema, deliberately denormalised for
  51.       efficiency and compactness (if necessary), and with all compromises
  52.       *documented* and *rationalised*.
  53.  
  54. But I've never done this for a living ...
  55. ----
  56.   __   __    Paul Singleton (Mr)           JANET: paul@uk.ac.keele.cs
  57.  |__) (__    Computer Science Dept.        other: paul@cs.keele.ac.uk
  58.  |  .  __).  Keele University, Newcastle,    tel: +44 (0)782 621111 x7355
  59.              Staffs ST5 5BG, ENGLAND         fax: +44 (0)782 713082
  60.