home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / database / 8003 < prev    next >
Encoding:
Internet Message Format  |  1992-11-21  |  3.8 KB

  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!natinst.com!hrd769.brooks.af.mil!hrd769.brooks.af.mil!not-for-mail
  2. From: burgess@hrd769.brooks.af.mil (Dave Burgess)
  3. Newsgroups: comp.databases
  4. Subject: Re: Normalizing 2NF -> 3NF
  5. Date: 20 Nov 1992 17:44:58 -0600
  6. Organization: Armstrong Lab MIS, Brooks AFB TX
  7. Lines: 71
  8. Distribution: world
  9. Message-ID: <1ejt9qINN340@hrd769.brooks.af.mil>
  10. References: <1992Nov16.103334.15543@neptune.inf.ethz.ch> <1992Nov16.135135.3108@odin.diku.dk> <69674@cup.portal.com>
  11. NNTP-Posting-Host: hrd769.brooks.af.mil
  12.  
  13. In article <69674@cup.portal.com> DVaz@cup.portal.com (David D Vazquez) writes:
  14. |marti@nugget.inf.ethz.ch (Robert Marti) writes:
  15. |.  :
  16. |.  FDs:  A -> B and B -> C
  17. |.  Relation: R(A*,B,C)
  18. |.  Problem: How to decompose?
  19. |.  Suggestion: R1(A*,B) and R2(B*,C) or R1(A*,B) and R2(A*,c)
  20. |.              ^^^^^^^^^^^^^^^^^^^^^
  21. |.Yes, but this might not be efficient. Fx, if there are two groups of users
  22. |.that wants to see an (A,B) and an (A,C) view resp., it requires a lot of
  23. |.unnecessary joins. Eg, (A,B,C) == (Name,Address,Phone#). You typically look up
  24. |.addresses from names and phone-numbers from names---not phone# from addresses.
  25. |.
  26.  
  27.   While the statement you make in the example is true, you are not adhering to
  28. the original statement.  The One to One relationship described in Name, Address
  29. and Phone is not valid for this question.  Phone Number is Fully Functionally
  30. Dependent on Address, not Name.  Suppose four students share a house, or (a
  31. military example) 50 airmen share a single barracks.  The phone is only
  32. transitively dependent on the name.  It is functionally dependent on the
  33. address.  It is transitively dependent on the name (if it is dependent at all).
  34.  
  35.   One of the references I use when I teach this course (Mary E.S. Loomis) says:
  36. "A relation is in 'third normal form' if, and only if, it is in 2NF and no 
  37. non-key attribute is ''transitively dependent'' on the primary key."
  38.  
  39.   A Student/Dormitory relationships might be a good example of the original 
  40. question.  R1(A,B,C) == (Student Name, Dorm, Dorm Address), where every
  41. student has a room in a dormitory.  The Address of the dorm is Functionally
  42. Dependent on the Dormitory (yes, or vice versa, it's only an example), not
  43. the student name.  In addition, every student is in a dorm.  This relation
  44. is NOT in 3NF.  The dependency between R1(A) and R1(C) is transitive (at best)
  45. based on the value of R1(B).
  46.  
  47. |
  48. |It may make that specific query faster, but it can wind up costing you more
  49. |disk space.  While R1(A*,B) and R2(A*,C) are in 3NF given the above stated FDs,
  50. |you will have alot of redundant (repeated) data (3NF is supposed to solve this
  51. |correct?).
  52. |
  53.  
  54.   Where is the redundancy?  In the foreign key element?  That is where your
  55. cardinality will help determine the actual implementation, but we are talking
  56. Form Normalization, not implementation.  In normalization, the concepts of 
  57. query speed and disk space have no place.  Save them for the physical 
  58. implementation phase.
  59.  
  60. |.A DBMS should be able to check other integrity constraints than primary keys. 
  61. |
  62. |Correct, but a 'database design' should enforce all of the given functional 
  63. |dependencies (R1(A*,B) + R2(A*,C) will not).
  64. |
  65.  
  66.   I agree.  The only problem with the statement is that what a DBMS 'should'
  67. do and what a DBMS 'will' do are neither germaine nor controllable by the
  68. database designer.  Every DBMS implements different levels of integrity 
  69. constraint, even with a particular model.
  70.  
  71. |.-- 
  72. |.         Niels Elgaard Larsen          
  73. |.         Institute of Computer Science,        
  74. |.         University of Copenhagen      
  75. |.         E-mail: elgaard@diku.dk 
  76. |
  77. |  David Vazquez
  78. |  Computer Science major @ University of New Orleans
  79. |  E-mail: dvaz@cup.portal.com and dvazquez@sdiserv.cs.uno.edu
  80.  
  81. TSgt Dave Burgess
  82. NCOIC, AL/MIS
  83. Brooks AFB, TX
  84.