This dictionary contains more than 600 entries dealing with issues, terms, and concepts involved in, or arising from use of, the relational model of data. Many of the entries include not only definitions but also one or more illustrative examples. I’ve done my best to make the definitions as clear, precise, and accurate as possible; they’re based on my own best understanding of the material, an understanding I’ve been honing gradually over some 35 years of involvement in this field.
I’d like to stress the point that the dictionary is, as advertised, relational. To that end, I’ve deliberately omitted terms and concepts that are only tangentially connected to relational matters (e.g., almost all details of the supporting type theory, including type inheritance details in particular). I’ve also omitted various topics that are part of database technology in general and aren’t particular to relational databases (e.g., security issues, the log, recovery and concurrency control, and so forth). What’s more, I’ve also omitted certain SQL terms and concepts that—the fact that SQL is supposed to be a relational language notwithstanding—aren’t really relational at all (outer join, UNION ALL, and updating through a cursor are examples). That said, I should add that I have deliberately included a few nonrelational terms in order to make it clear that, contrary to popular opinion, the concepts in question are indeed not relational (index is a case in point here).
I must explain too that this is a dictionary with an attitude. It’s my very firm belief that the relational model is the right and proper foundation for database technology and will remain so for as far out as anyone can see, and many of the definitions in what follows reflect this belief. As I said in my book Database in Depth: Relational Theory for Practitioners (O’Reilly):
[It’s] my opinion that the relational model is rock solid, and “right,” and will endure. A hundred years from now, I fully expect database systems still to be based on Codd’s relational model. Why? Because the foundations of that model—namely, set theory and predicate logic—are themselves rock solid in turn. Elements of predicate logic in particular go back well over 2000 years, at least as far as Aristotle (384-322 BCE).
In addition, I haven’t hesitated to mark some term or concept as deprecated if I believe there are good reasons to avoid it, even if the term or concept in question is in widespread use at the time of writing. Materialized view is a case in point here.
The examples that illustrate the definitions are based for the most part on the familiar—not to say hackneyed—suppliers-and-parts database. I apologize for dragging out this old warhorse yet one more time, but I believe that using the same example in a variety of different publications can be a help, not a hindrance, to learning. Here are the relvar definitions (and if you aren’t familiar with the term relvar, then please check the corresponding dictionary entry!):
VAR S BASE RELATION
{ S# S#, SNAME NAME, STATUS INTEGER, CITY CHAR }
KEY { S# } ;
VAR P BASE RELATION
{ P# P#, PNAME NAME, COLOR COLOR,
WEIGHT WEIGHT, CITY CHAR }
KEY { P# } ;
VAR SP BASE RELATION
{ S# S#, P# P#, QTY QTY }
KEY { S#, P# } ;The semantics are as follows:
- Relvar S
Represents suppliers under contract. Each supplier has one supplier number (S#), unique to that supplier; one name (SNAME), not necessarily unique; one status value (STATUS); and one location (CITY). Attributes S#, SNAME, STATUS, and CITY are of types S#, NAME, INTEGER, and CHAR, respectively.
- Relvar P
Represents kinds of parts. Each kind of part has one part number (P#), which is unique; one name (PNAME); one color (COLOR); one weight (WEIGHT); and one location where parts of that kind are stored (CITY). Attributes P#, PNAME, COLOR, WEIGHT, and CITY are of types P#, NAME, COLOR, WEIGHT, and CHAR, respectively.
- Relvar SP
Represents shipments (it shows which parts are shipped, or supplied, by which suppliers). Each shipment has one supplier number (S#), one part number (P#), and one quantity (QTY); there is at most one shipment at any given time for a given supplier and given part. Attributes S#, P#, and QTY are of types S#, P#, and QTY, respectively.
Figure 1 shows a set of sample values. Examples in the body of the dictionary assume these specific values, where it makes any difference.