home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / database / 7878 < prev    next >
Encoding:
Internet Message Format  |  1992-11-16  |  2.9 KB
  1. Path: sparky!uunet!pmafire!mica.inel.gov!ux1!news.byu.edu!gatech!usenet.ins.cwru.edu!agate!doc.ic.ac.uk!uknet!mcsun!sunic!dkuug!diku!elgaard
  2. From: elgaard@diku.dk (Niels Elgaard Larsen)
  3. Newsgroups: comp.databases
  4. Subject: Re: Normalizing 2NF -> 3NF
  5. Message-ID: <1992Nov16.135135.3108@odin.diku.dk>
  6. Date: 16 Nov 92 13:51:35 GMT
  7. References: <1992Nov15.163413.17527@news.uiowa.edu> <1992Nov15.223825.16263@odin.diku.dk> <1992Nov16.103334.15543@neptune.inf.ethz.ch>
  8. Sender: elgaard@trud.diku.dk
  9. Organization: Department of Computer Science, U of Copenhagen
  10. Lines: 51
  11.  
  12. marti@nugget.inf.ethz.ch (Robert Marti) writes:
  13.  
  14. >In article <1992Nov15.223825.16263@odin.diku.dk>, elgaard@diku.dk
  15. >(Niels Elgaard Larsen) writes:
  16. >|> bonak@herky.cs.uiowa.edu (Esmail Bonakdarian) writes:
  17. >|> >E.g., given a relation with three attributes, A, B, and C, where
  18. >|> >attribute A is the PK, the following dependencies exist:
  19. >|> >  R(A*  ,B   ,C)
  20. >|> >    A -> B
  21. >|> >         B -> C
  22. >|> >i.e, A determines B, and B in turn determines C.
  23. >|> >3NF would split this up into two relations:
  24. >|> >  R'(A*,B)
  25. >|> >  and
  26. >|> >  R"(A*,C)  OR  R"(B*,C)
  27. >|> >Which of these two latter relations is the "correct" one according to
  28. >|> >the theory? Or does it always depend on the given semantics of the data
  29. >|> >being modeled? It seems to me that I've seen both.
  30. >|> 
  31. >|> Both are correct since both (A,C) and (B,C) are on 3NF. That does of course
  32. >|> not mean that they are equally good. Depends on the queries on the database.
  33.  
  34. >[note that I have slightly edited the original posting to conserve space]
  35.  
  36. >In the following, I assume that the functional dependency (FD)
  37. >B -> A does _not_ hold, since if it did, no normalization would
  38. >have been necessary in the first place.
  39.  
  40. >I haven't been looking at the theory books (Maier, Ullman) in a
  41. >loooong time, but the solution with R'(A*,B) and R"(B*,C) is much
  42. >better than the other one with R'(A*,B) and R"(A*,C).  Why?  Well,
  43. >if you perceive an FD B -> C in the real world, you probably would
  44. >like your system to enforce this integrity constraint.  (FDs and
  45. >MVDs are really just special cases of integrity constraints.)  The
  46. >simplest (and in some systems still the _only_) way to enforce an
  47. >FD is to make its left hand side a key for a relation consisting of
  48. >the attributes listed on both its left and right hand side.  (In
  49. >older SQL-based systems, this has to be done by CREATing a UNIQUE
  50. >INDEX for column B of table R".)
  51.  
  52. Yes, but this might not be efficient. Fx, if there are two groups of users
  53. that wants to see an (A,B) and an (A,C) view resp., it requires a lot of
  54. unnecessary joins. Eg, (A,B,C) == (Name,Address,Phone#). You typically look up
  55. addresses from names and phone-numbers from names---not phone# from addresses.
  56.  
  57. A DBMS should be able to check other integrity constraints than primary keys. 
  58. -- 
  59.          Niels Elgaard Larsen          
  60.          Institute of Computer Science,        
  61.          University of Copenhagen      
  62.          E-mail: elgaard@diku.dk 
  63.