Keywords, variable names, and the like are set in all uppercase throughout.

Coding examples are expressed (mostly) in a language called Tutorial D. I believe those examples are reasonably self-explanatory, but in any case the Tutorial D language is largely defined in the dictionary itself, in the entries for the various relational operators (union, join, restriction, etc.). If needed, a comprehensive description of the language can be found in the book Databases, Types, and the Relational Model: The Third Manifesto, Third Edition, by C. J. Date and Hugh Darwen (Addison-Wesley). Note: As the subtitle indicates, that book also introduces and explains The Third Manifesto, a precise though somewhat formal definition of the relational model and a supporting type theory (including a comprehensive model of type inheritance). In particular, it uses the name D as a generic name for any language that conforms to the principles laid down by The Third Manifesto. Any number of distinct languages could qualify as a valid D; sadly, however, SQL isn’t one of them, which is why examples in this dictionary are expressed in Tutorial D and not SQL. (Tutorial D is, of course, a valid D.)

Following on from the previous point, I should make it clear that all relational definitions in this dictionary are intended to conform fully to the relational model as defined by The Third Manifesto. Consequently, you might find certain aspects of those definitions a trifle surprising—for example, the assertion in the entry for deferred checking that such checking is logically flawed. As I’ve already said, this is a dictionary with an attitude.

It has become standard practice in the industry to use terms such as projection and join (and so on) in two somewhat different senses: they’re used to refer both to the operators identified by those names and also to the results obtained when those operators are invoked. I’ve followed this practice myself in this dictionary on occasion, and hope it won’t lead to confusion.

It has become standard practice to interpret the terms projection and join (and so on) in another sense as well. By definition, these operators apply to relation values specifically. In particular, of course, they apply to the values that happen to be the current values of relvars. It thus clearly makes sense to talk about, for example, the projection on attribute A of relvar R, meaning the relation that results from taking the projection on that attribute A of the current value r of that relvar R. In some contexts, however (normalization, for example), it is convenient to use expressions such as “the projection on attribute A of relvar R" in a slightly different sense. To be specific, we might say, loosely but very conveniently, that some relvar (RA, say) is the projection on attribute A of relvar R—meaning, more precisely, that the value of RA at all times is the projection on A of the value of R at the time in question. In a sense, therefore, we can talk in terms of projections of relvars per se, rather than just in terms of projections of current values of relvars. Analogous remarks apply to all of the relational operations.

Certain definitions (of certain operators, for example) require certain values to be of certain specific types. For simplicity, I haven’t bothered to spell out this fact in detail in every case but have simply assumed the requirement is satisfied wherever necessary.

Several definitions and examples make use of a simplified notation for tuples. For example, consider the SP tuple shown in Figure 1 for supplier S1 and part P1. A formal Tutorial D representation of that tuple might look like this:

	TUPLE { S# S#('S1'), P# P#('P1'), QTY QTY(300) }

In the simplified notation under discussion, however, the same tuple would be represented as:

	<S1,P1,300>

The notion of set is ubiquitous in the database world. On paper, a set is usually represented by a comma-separated list (or commalist) of symbols denoting the elements, enclosed in braces as here: {a,b,c}. In what follows, therefore, I use braces to enclose commalists of items when the items in question are meant to denote the elements of some set, implying among other things that (a) the order in which the items appear within that commalist is immaterial, and (b) if an item appears more than once, it’s treated as if it appeared only once.

The notion of logic is also ubiquitous in the database world. The relational model in particular is firmly based on logic. More precisely, it’s based on conventional two-valued predicate logic, 2VL (q.v.), and all references to logic in this dictionary should be taken as referring to that logic specifically, except where the context demands otherwise.

Continuing from the previous point, many of the entries in this dictionary have to do with concepts from logic. Unfortunately, logic texts (and logicians) vary widely not only in the terminology they use but also, in some cases, in the substance of their definitions. The definitions I give are the ones I find most appropriate myself, but be warned that they’re sometimes at odds with others you can find in the literature.