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.

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.

There is a clear shift of emphasis in the way in which computer systems in general, and database management systems in particular, are perceived in the marketplace today. Questions of usability are beginning to outweigh the more traditional concerns with raw performance. The reason for this state of affairs is obvious; People costs are rising and machine costs are falling. This presentation consists of a critical examination of database management systems, or more specifically the externals of such systems, from a usability standpoint.The talk is divided into three parts. The first part, What Does Usability Mean?, is an attempt to capture the notion of usability, or at least to characterize certain aspects of the notion in a variety of helpful ways. It is argued that usability is fundamentally concerned with raising the level of abstraction of the user interface in an and coherent manner --- with the emphasis on appropriate and coherent.The second part of the talk, Where We Are Today, contrasts the usability of modern (relational) systems with the comparative lack of usability found in older (nonrelational) systems. The usability advantages of the relational model and of relational systems are summarized and briefly analyzed.The third (and longest) part is called How We Might Improve. Improvements are needed in at least four somewhat overlapping areas:1. Quality of current interfacesEven though they represent a major advance over earlier systems, most relational systems today still suffer from a number of usability problems, specifically with regard to missing function and what might be termed ad hoc-ness. Both of these aspects are illustrated with examples. Some principles of interface design (for example, uniformity and orthogonality) are briefly discussed.2. More semantics over current dataRaising the intelligence of the system (via semantic modeling) can also help to make the system more usable, especially with regard to database design and definition.3. New kinds of dataIncorporating new kinds of data (e.g., text, arrays, noncoded information) can also help to raise the level of the user interface, especially if the database management function is properly integrated with statistics, word-processing, graphics, and similar packages.4. New kinds of interfaceConventional, written-word-oriented query languages are very clumsy in many applications. The Field is wide open for improvements: text-editor-like interfaces, voice input and output, 3D terminals, pictorial interfaces, etc., etc.

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 programmer's 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.