home *** CD-ROM | disk | FTP | other *** search
/ Complete Linux / Complete Linux.iso / docs / apps / database / postgres / postgre2.z / postgre2 / doc / implementation / planner / 1.intro < prev    next >
Encoding:
Text File  |  1992-08-27  |  3.4 KB  |  72 lines
  1. .sh 1 "INTRODUCTION"
  2. .pp
  3. Relational database management systems are widely available in the
  4. commercial market.
  5. Currently available systems run on a variety of hardware, ranging from
  6. DEC minicomputers (e.g., Informix, Oracle, Unify) to IBM mainframes
  7. (e.g., Adabas, Datacom/DB, DB2, IDMS/R).
  8. These systems have been successful because of the merits of 
  9. the relational model, as first illustrated by
  10. two research prototypes, INGRES [STON76]
  11. and SYSTEM-R [ASTR76].
  12. INGRES and SYSTEM-R not only illustrated the feasibility of
  13. the relational model, but their respective query languages,
  14. QUEL [HELD75b] and SQL [CHAM76], also
  15. showed that it is possible to ask queries without explicitly
  16. specifying access paths.
  17. The ability to support these non-procedural query languages is a result of
  18. sophisticated query optimization algorithms.
  19. INGRES introduced a technique known as query decomposition [WONG76],
  20. while SYSTEM-R employed an exhaustive search algorithm [SELI79].
  21. Largely due to the success of these algorithms, relational systems were made
  22. efficient.
  23. Therefore, coupled with the simplicity and uniformity of the 
  24. relational model, it
  25. is not surprising that relational databases have established a
  26. formidable presence in the commercial market.
  27. .pp
  28. The relational model, however, has been criticized for its impoverished
  29. semantics [KENT79], [ZANI83] and inability to provide strong support
  30. for non-business applications [HASK82].
  31. In recent years, researchers have been investigating the possibility of
  32. extending query languages in relational systems to support new application
  33. areas as well as better semantics.
  34. Examples include:
  35. .ip "\(bu"
  36. a proposal to support abstract data types (ADTs) and operators
  37. in INGRES to improve the semantics of applications [FOGG82], [ONG82]
  38. .ip "\(bu" 
  39. a new language, QUEL*, to support the transitive
  40. closure operations required in artificial intelligence applications [KUNG84]
  41. .ip "\(bu"
  42. a proposal to support QUEL as a data type
  43. to increase the data modeling power of relational systems [STON84], [STON85b]
  44. .ip "\(bu"
  45. a proposal to support rules and triggers in a relational system to
  46. provide inference and forward chaining needed in 
  47. expert system applications [STON85a].
  48. .lp
  49. .pp
  50. The ideas behind these proposals are being incorporated into POSTGRES
  51. (\*(lqPOSTinGRES\*(rq),
  52. a next-generation relational database system being built at
  53. the University of California, Berkeley [STON86b].
  54. Providing better support for engineering design and artificial intelligence
  55. applications are among the goals of POSTGRES.
  56. To meet these goals, POSTGRES will support extendible and user-defined
  57. access methods [STON86a] as well as abstract data types, transitive
  58. closure queries, procedural data fields, triggers, and rules.
  59. The query language for the system will be called \*(lqPOSTQUEL.\*(rq
  60. .pp
  61. POSTGRES is still in its preliminary implementation phase.
  62. However, a query optimizer for the system has been built.
  63. Although the basic optimization algorithm is modeled after the SYSTEM-R
  64. approach, there are many other issues that the optimizer must
  65. contend with given the novel features of POSTGRES.
  66. Section 2 will introduce these features.
  67. Section 3 will then discuss design decisions that were made in formulating 
  68. optimization algorithms.
  69. Section 4 will discuss implementation decisions made, and finally
  70. section 5 will evaluate the performance of the POSTGRES optimizer by comparing
  71. it with the query optimizer of another relational system.
  72.