home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / database / 6114 < prev    next >
Encoding:
Text File  |  1992-08-14  |  2.4 KB  |  56 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!cs.utexas.edu!sdd.hp.com!wupost!darwin.sura.net!mlb.semi.harris.com!controls.ccd.harris.com!yaseen
  3. From: yaseen@controls.ccd.harris.com (Rahim M. Yaseen)
  4. Subject: Re: Object What is an OODBMS?
  5. Message-ID: <1992Aug14.124148.15752@ccd.harris.com>
  6. Originator: yaseen@rs2
  7. Keywords: OODBMS, C++, POET
  8. Sender: yaseen@controls (Rahim M. Yaseen)
  9. Organization: Harris Controls
  10. References: <RCZ5NS@netmbx.netmbx.de> <1992Aug13.170024.11525@genghis.borland.com>
  11. Date: Fri, 14 Aug 1992 12:41:48 GMT
  12. Lines: 42
  13.  
  14.  
  15. In article <1992Aug13.170024.11525@genghis.borland.com>, cy@genghis.borland.com (Cy Shuster) writes:
  16. |> [discusses limits of the relational model to store real world
  17. |> relationships, such as many-to-many]
  18. |> 
  19. |> Have we really come full circle, back to Codasyl networked structures?
  20.  
  21. In a sense, yes and no.
  22.  
  23. The yes applies to the fact that networked structures would appear to be 
  24. similar to the physical (storage-level) structures for OODBMSs.
  25.  
  26. The no applies to the fact that in Codasyl databases, the user-level 
  27. abstractions of relationships is very close to that at the physical-level
  28. (i.e., parent-child) thus requiring users to think like programmers.
  29. In OODBMSs, there is usually a user-level abstraction of relationships
  30. and corresponding semantics of such relationships (e.g. IS-A, IS-PART-OF,
  31. superclass-subclass, inheritance, etc. etc.). Several semantic data models
  32. capture such relationships e.g., extended ER, NIAM, Express, ..
  33. The argument is that if one knows the static relationships ahead of time,
  34. go ahead and define them (note that nothing prevents these relationships 
  35. from being re-defined or changed later i.e., schema evolution)
  36.  
  37.  
  38. |> What about the vaunted features of ad hoc queries and on-the-fly
  39. |> joins, over casting relations into concrete at schema design time?
  40. |> 
  41.  
  42. The way I see ad-hoc queries and on-the-fly joins is that dynamic 
  43. relationships are being created at run-time using domain-compatible values.
  44. There is nothing preventing a query language in OODBMSs from querying
  45. pre-defined relationships AND creating dynamic on-the-fly relationships. 
  46. (I have seen a couple of experimental query languages attempt to do this)
  47. I see this concept as derived relationships: a concept similar to that of 
  48. derived data.
  49.  
  50. Thus, you have the advantages of two worlds: static (pre-defined) relationships
  51. (which are definable in many large applications) and dynamic (on-the-fly)
  52. relationships.
  53.  
  54. - yaseen
  55.  
  56.