C. J. Date and C. J. White, "A Guide to DB2," Third Edition, Addison-Wesley, 1989.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....five words. We expect, however, that a compact representation of three words for nonuniform distributions and two words for uniform distributions and for intensional distributions will be sufficient for most applications. As a comparison, the current DB2 timestamp representation is 2. 5 words ([Date White 1990]) the commercial Ingres ( Stonebraker et al. 1976] representation is three words, and the proposed SQL2 ( Melton 1990] representation is six words, all with a significantly shorter extent and without any historical indeterminacy. 25 6.2 Query Evaluation Algorithms The five functions ....

Date, C. J. and C. J. White. "A Guide to DB2." Reading, MA: AddisonWesley, 1990. Vol. 1, 3rd edition.

....to be, very active [Bolour et al. 1982, McKenzie 1986, Snodgrass 1990, Soo 1991, Stam Snodgrass 1988] Among database management system vendors, the need to provide time support has also been recognized. We are aware of several commercial products that provide some sort of temporal support [Date White 1990, Oracle 1987, Tandem 1983] Unfortunately, most are ad hoc and widely regarded as poorly designed [Date 1988] This paper attempts to remedy this situation. We augment a conventional relational query language with time values, i.e. temporal constants. The language to be modified is the ....

....In the commercial arena, as previously mentioned, several systems with support for temporal data types exist [Oracle 1987, Tandem 1983] These implementations are limited in scope and are, in general, unsystematic in their design. Date provides a thorough critique of one of the systems, DB2 [Date White 1990, Date 1988] 2 Lastly, and most importantly, date and time support very similar to that in DB2 is currently being proposed for SQL2 [Melton 1990] SQL2 corrects some of the inconsistencies in the time support provided by DB2 but inherits its basic design limitations. We will discuss the SQL2 ....

Date, C. J. and C. J. White. "A Guide to DB2." Reading, MA: AddisonWesley, 1990. Vol. 1, 3rd edition.

....This value admits that we do not know when Jane will depart the company, and so assumes that she will be working forever. One limitation of using forever is that it is overly optimistic: forever is a long time into the future In SQL and in IBM s DB2, forever is about 8,000 years from the present [5, 9]; in TSQL2 s more liberal design, it is approximately 18 billion years from the present time [6] Hence, to assert that Jane will be employed until forever is most assuredly incorrect (others have also noted that a terminating time of # or forever, has erroneous implications for the future [10] ....

Date, C. J. and C. J. White. "A Guide to DB2." Reading, MA: AddisonWesley, 1990. Vol. 1, 3rd edition.

....timestamps are in use in commercial database management systems and operating systems. These timestamp representations suffer from inadequate range, too coarse granularity, excessive space requirements, or a combination of these drawbacks. For example, the DB2 date type has a granularity of a day [Date White 1990]. Most operating system formats reduce this coarse granularity to a second, but only cover about 120 years. DB2 s timestamp type further reduces the granularity to a microsecond, but requires 10 bytes and still only covers 10,000 years, which is of little use to geologists. The SQL2 standard ....

Date, C. J. and C. J. White. "A Guide to DB2." Reading, MA: AddisonWesley, 1990. Vol. 1, 3rd edition.

.... In DB2, SQL statements are precompiled into a Database Request Module (DBRM) One or more DBRM s are compiled and bound into an application plan which contains a set of internal control structures representing the complied form of the original SQL statements from which the DBRM s are built [12]. Here, we refer to each commit point in a plan as a transaction. Certain information is available at run time indicating the execution behavior of each SQL statement, such as how many tuples have been scanned on the average for each qualified tuple retrieval. We shall explain the methodology ....

....SQL statements. There are several issues that need to be addressed. First of all, consider the case of SQL statements involving views. As views are virtual tables which do not exist physically, views appearing in an SQL statement are replaced during execution plan generation by their definitions [12]. In other words, a simple retrieval statement on a view may in fact be a complex join statement in disguise. Secondly, DB2 has the cursor concept associated with the embedded SQL construct [12] In contrast to COBOL and PL I like programming languages which deal with one record at a time, an SQL ....

[Article contains additional citation context not shown here]

C. J. Date, "A Guide to DB2", MA.: Addison-Wesley, 1988.

....In the commercial arena, as previously mentioned, several systems with support for temporal data types exist [Oracle 1987, Tandem 1983] These implementations are limited in scope and are, in general, unsystematic in their design. Date provides a thorough critique of one of the systems, DB2 [Date White 1990, Date 1988] The extensibility of calendars and calendric systems is a limited form of database extensibility [Carey Haas 1990] Our proposal supports query language extensibility in the form of calendar functions, and presentation extensibility in the form of time display customization. We ....

....al. 1990] and it is reasonable to ask whether time can be adequately supported as an ADT. We feel that it cannot. Time is a fundamental data type many DBMSs provide it and most applications use it. Indeed, the SQL2 proposal [Melton 1990] in addition to the SQL variant supplied with IBM s DB2 [Date White 1990], both provide special support for time. As such it is appropriate for temporal data to be supported by the DBMS directly rather than supported by a local extension. Furthermore, calendar selection would be awkward to specify in a query if added as a database extension rather than providing base ....

Date, C. J. and C. J. White. "A Guide to DB2." Reading, MA: Addison-Wesley, 1990. Vol. 1, 3rd edition.

No context found.

Date, C. J. and C. J. White. "A Guide to DB2." Reading, MA: AddisonWesley, 1990. Vol. 1, 3rd edition.

....reads and writes: it only required operation atomicity. Degrees 1, 2, and 3 correspond to Locking READ UNCOMMITTED, READ COMMITTED, and SERIALIZABLE, respectively. No isolation degree matches the Locking REPEATABLE READ isolation level. Date and IBM originally used the name Repeatable Reads [DAT, DB2] to mean serializable or Locking SERIALIZABLE. This seemed like a more comprehensible name than the [GLPT] term Degree 3 isolation, although they were meant to be identical. The ANSI SQL meaning of REPEATABLE READ is different from Date s original definition, and we feel the terminology is ....

C. J. Date and C. J. White, "A Guide to DB2," Third Edition, Addison-Wesley, 1989.

No context found.

C. J. Date and C. J. White, "A Guide to DB2," Third Edition, Addison-Wesley, 1989.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC