C. J. Date

Simple conditions for guaranteeing higher normal forms in relational databases

A key is simple if it consists of a single attribute. It is shown that if a relation schema is in third normal form and every key is simple, then it is in projection-join normal form (sometimes called fifth normal form), the ultimate normal form with respect to projections and joins. Furthermore, it is shown that if a relation schema is in Boyce-Codd normal form and some key is simple, then it is in fourth normal form (but not necessarily projection-join normal form). These results give the database designer simple sufficient conditions, defined in terms of functional dependencies alone, that guarantee that the schema being designed is automatically in higher normal forms.

A formal definition of the relational model

The relational model of data, originally introduced by Codd in [1], has three components: (1) a set of objects (relations, domains, etc.); (2) a set of operators (union, project, etc.); (3) a set of general integrity rules. The purpose of this paper is to provide a formal definition of each of these three components.

An architecture for high-level language database extensions

This paper describes an architecture for a set of database extensions to the existing high-level languages. The scheme described forms an architecture in the sense that it is not based on any particular language: its constructs and functions, or some suitable subset of them, may be mapped into the concrete syntax of a number of distinct languages, among them COBOL and PL/I. The architecture includes both the means for specifying the programmers view of a database (i.e. for defining the external schema) and the means for manipulating that view. A significant feature is that the programmer is provided with the ability to handle all three of the well-known database structures (relational, hierarchical, network), in a single integrated set of language extensions. Another important aspect is that both record- and set-level operations are provided, again in an integrated fashion. The objectives of the architecture are to show that it is possible for relational, hierarchical and network support to co-exist within a single language, and also, by providing a common framework and treating the three structures in a uniform manner, to shed some new light on the continuing debate on the relative merits of each.The paper is intended as an informal introduction to the architecture, and to this end includes several illustrative examples which make use of a PL/I-based concrete syntax.

File definition and logical data independence

This paper presents an architecture for a data base system which is capable of providing data independence at two levels, viz physical and logical. The architecture employs a schema, which gives an abstract picture of the physical data base, and a subschema, which contains the definitions of an application programs logical files. The language for writing these logical file definitions is then discussed, and a number of features which should be provided in such a language are identified, and descrioed. In particular it is shown that the language should include the quantifiers of the predicate calculus, and should be capable of defining files which span several files in the schema. The use of the subschema in providing logical data independence is then demonstrated, and an appropriate application program discipline discussed. This is the first of two associated papers, the second of which deals with the complementary problems of storage structure and physical data independence.

Storage structure and physical data independence

This paper presents the results of an investigation into the feasibility of physical data independence in a data base system. In theory physical data independence may be achieved by providing a picture of the data which remains invariant as the underlying storage structure of the data base changes. In this paper the data picture is assumed to describe the data base as consisting of a set of records in third normal form. The question is, given this third normal form data picture, to what extent may the storage structure change? The paper attempts to answer this question by first defining and explaining a number of concepts, including the important notions of storage equivalence and conformable representation, and then using these concepts to illustrate some possible storage structures for a sample data base. It is demonstrated in particular that the number of possible conformable representations of the data base is potentially very large, and that certain advantages accrue from the choice of a conformable representation. Some non-conformable representations are also shown. This is the second of two associated papers, the first of which deals with the complementary problems of file definition and logical data independence.

A normal form for preventing redundant tuples in relational databases

We introduce a new normal form, called essential tuple normal form (ETNF), for relations in a relational database where the constraints are given by functional dependencies and join dependencies. ETNF lies strictly between fourth normal form and fifth normal form (5NF, also known as projection-join normal form). We show that ETNF, although strictly weaker than 5NF, is exactly as effective as 5NF in eliminating redundancy of tuples. Our definition of ETNF is semantic, in that it is defined in terms of tuple redundancy. We give a syntactic characterization of ETNF, which says that a relation schema is in ETNF if and only if it is in Boyce-Codd normal form and some component of every explicitly declared join dependency of the schema is a superkey.

Response to “Remarks on two new theorems of Date and Fagin”

In [DF92], we present simple conditions, which we now describe, for guaranteeing higher normal forms for relational databases. A key is simple if it consists of a single attribute. We show in [DF92] that if a relation schema is in third normal form (3NF) and every key is simple, then it is in projection-join normal form (sometimes called fifth normal form), the ultimate normal form with respect to projections and joins. We also show in [DF92] that if a relation schema is in Boyce-Codd normal form (BCNF) and some key is simple, then it is in fourth normal form (4NF). These results give the database designer simple sufficient conditions, defined in terms of functional dependencies alone, that guarantee that the schema being designed is automatically in higher normal forms.

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.”