Nikos A. Lorentzos

Database Design I: Structure

This chapter is the first of three devoted to the topic of logical database design in the temporal context. Database design in that context has the potential to be a much more complicated matter than its analog in the conventional (nontemporal) context. There are several reasons for this state of affairs, including (a) the need to deal with the fact that different “properties” of the same “entity” tend to vary at different rates and (b) the need to deal with the concept of “until further notice”—i.e., the need to be able to record the fact that a given “property” of a given “entity” has a given value right now and will continue to have that same value until some unknown time in the future. The chapter proposes some new design techniques (in particular, a new normal form) for dealing with such matters.

Time and the Database

This chapter discusses time and the database. A temporal database is a database that contains historical data instead of or in addition to current data. Such databases have been under active investigation since the early 1980s. Some of those investigations have taken the extreme position that data in such a database, once inserted, should never be deleted or changed in any way, in which case the database can be thought of as containing historical data only. Conventional databases, by contrast, are typically at the other extreme; such a database typically contains current data only, and data in such a database is changed or deleted as soon as the propositions represented by that data cease to be ones that evaluate to true. The propositions in nontemporal database are generally taken to be true “now,” that is, at the time the database is inspected. Temporal database research has therefore involved a certain amount of investigation into the nature of time itself. This chapter explores some questions that regarding whether or not time has a beginning or an end; if time is a continuum or is it divided into discrete quanta; and the best way to characterize the important concept “now.”

Chapter 3 – Time and the Database

Publisher Summary This chapter discusses time and the database. A temporal database is a database that contains historical data instead of or in addition to current data. Such databases have been under active investigation since the early 1980s. Some of those investigations have taken the extreme position that data in such a database, once inserted, should never be deleted or changed in any way, in which case the database can be thought of as containing historical data only. Conventional databases, by contrast, are typically at the other extreme; such a database typically contains current data only, and data in such a database is changed or deleted as soon as the propositions represented by that data cease to be ones that evaluate to true. The propositions in nontemporal database are generally taken to be true “now,” that is, at the time the database is inspected. Temporal database research has therefore involved a certain amount of investigation into the nature of time itself. This chapter explores some questions that regarding whether or not time has a beginning or an end; if time is a continuum or is it divided into discrete quanta; and the best way to characterize the important concept “now.”

Chapter 5 – Intervals

Publisher Summary This chapter discusses intervals. Intervals are the fundamental abstraction needed for dealing with temporal data satisfactorily. The first and most fundamental step is to recognize the need to deal with intervals as such that is, the need to treat intervals as values in their own right, instead of treating them as pairs of separate values. Conventionally, therefore, an interval is denoted by a pair of points separated by a colon, preceded by an opening bracket or parenthesis and followed by a closing bracket or parenthesis. A bracket is used where one wants the closed interpretation, a parenthesis where one wants the open one. The applications for intervals are varied. Tax brackets are represented by taxable-income ranges—in other words, intervals whose begin and end points are money values. Machines are built to operate within certain temperature and voltage ranges—in other words, intervals whose contained points are temperatures and voltages, respectively. Animals vary in the range of frequencies of light and sound waves to which their eyes and ears are receptive. Various natural phenomena occur and can be measured in ranges in depth of soil or sea or height above sea level.

Chapter 11 – Integrity Constraints I: Candidate Keys and Related Constraints

Publisher Summary This chapter discusses addresses the question of the integrity constraints that might apply to temporal data. It discusses integrity constraints candidate keys and related constraints, which are further segmented into the redundancy problem, the circumlocution problem, the contradiction problem, combining specifications, PACKED ON without WHEN/THEN, WHEN/THEN without PACKED ON, neither PACKED ON nor WHEN/THEN, candidate keys revisited, and PACKED ON revisited. The redundancy problem is addressed by considering the revlar S_STATUS_DURING specifically. The limitations of using this revlar are then discussed and the method of addressing the circumlocution problem is illustrated. The methods of fixing the redundancy problem and circumlocution problem are also discussed. The contradiction problem is also addressed using the revlar definition of S_STATUS_DURING specifically and the method to fix the contradiction problem is described.

Logged Time and Stated Time

This chapter takes a much closer look at two concepts originally introduced in Chapter 4, viz., “valid time” and “transaction time.” Valid time has to do with when we believe (explicitly or implicitly) that some proposition is, was, or will be true. Transaction time has to do with when the database said (explicitly or implicitly) that we believe (again, explicitly or implicitly) that some proposition is, was, or will be true. Valid times are maintained—at least in a relational system—just like any other kind of data; in particular, they’re updatable just like any other kind of data. By contrast, transaction times are maintained by the system; in particular, therefore, they’re read-only (at least from the user’s point of view). The chapter proposes a model for querying transaction times. It also proposes some alternative technology: stated time for valid time, and logged time for transaction time.

Database Design III : General Constraints

This chapter proposes a general framework for dealing with temporal database design questions. To be specific, it describes a set of requirements that apply to the design of the running example and (it’s claimed) can be used as a template for pinning down the requirements that apply to any temporal database. The chapter then shows how those requirements can be expressed in terms of formal integrity constraints for (a) a database consisting of current relvars only, (b) a database consisting of historical relvars only, and (c) a database consisting of a mixture of current and historical relvars. The chapter also offers some hope for automating the definitions of such constraints.

Types and Relations

This chapter is the first of three devoted to reviewing the basics of relational theory. It explains relations as such, as well as the supporting notion of types (aka domains), in considerable depth. With regard to types; it discusses values, variables, operators, parameters, arguments, expressions, and polymorphism; equality and assignment; system defined vs. user defined types; scalar vs. nonscalar types; possible vs. physical representations; type generators and generated vs. nongenerated types; type constraints; and selectors, literals, and THE_ operators. With regard to relations, it discusses tuples, attributes, and relation headings and bodies; relation and tuple types; TABLE_DEE and TABLE_DUM; relation valued attributes; predicates and propositions; and The Closed World Assumption. The chapter also introduces the running example (i.e., the suppliers-and shipments-database).

The PACK and UNPACK Operators I: The Single-Attribute Case

This chapter and the next build on the notions introduced in the previous chapter—viz., expanded form and collapsed form, which apply to sets of intervals as such—to define two further canonical forms, viz., unpacked and packed form, which apply to relations with zero or more attributes of some interval type. The present chapter considers what’s probably the most important special case, viz., the case of unpacking or packing a relation on the basis of exactly one interval attribute. In particular, the usefulness of the two canonical forms, and the corresponding UNPACK and PACK operators, in dealing with the sample queries from Chapter 5 is clearly demonstrated.

Chapter 15 – Queries

The various shorthands introduced in earlier chapters—especially Chapters 9 and 11—can help to reduce the complexity of temporal queries in general. Even with those shorthands, however, queries on a temporal database still have the potential to be quite complicated. This chapter considers a set of twelve sample queries and shows how those queries might be formulated on (a) a database consisting of current relvars only, (b) a database consisting of historical relvars only, and (c) a database consisting of a mixture of current and historical relvars. The chapter also discusses the possibility of using automatically defined views to simplify the formulation of such queries.