Appendix G

Suggestions for Further Reading

As the title says, this appendix gives some suggestions for further reading. The publications are listed in alphabetical order by author and chronological order within author.¹ Note: This book isn’t concerned with specific SQL products, and I therefore don’t mention any product oriented publications in this appendix. But many such publications exist, and I’m sure you’ll want to refer to one or more of them as well if you want to apply the ideas discussed in the present book to some individual project or product.

1. Surajit Chaudhuri and Gerhard Weikum: “Rethinking Database System Architecture: Towards a Self-Tuning RISC-style Database System,” Proc. 26th Int. Conf. on Very Large Data Bases, Cairo, Egypt (September 2000).

   Among other things, this paper strongly endorses one of the messages of this book—viz., that SQL is complicated, confusing, and error prone. Here’s what Chaudhuri and Weikum have to say on the matter: “SQL is painful. A big headache that comes with a database system is the SQL language. It is the union of all conceivable features (many of which are rarely used or should be discouraged to use anyway) and is way too complex for the typical application developer. Its core, say selection-projection-join queries and aggregation, is extremely useful, but we doubt that there is wide and wise use of all the bells and whistles. Understanding semantics of SQL (not even of SQL-92), covering all combinations of nested (and correlated) subqueries, null values, triggers, etc. is a nightmare. Teaching SQL typically focuses on the core, and leaves the featurism as a ‘learning-on-the-job’ life experience.”

2. Donald D. Chamberlin and Raymond F. Boyce: “SEQUEL: A Structured English Query Language,” Proc. 1974 ACM SIGMOD Workshop on Data Description, Access, and Control, Ann Arbor, Mich. (May 1974).

   This is the paper that first introduced the SQL language (or SEQUEL—Structured English QUEry Language—as it was originally called; the name was subsequently changed for legal reasons). There are some interesting differences between SEQUEL as described in this paper and SQL as generally understood today.² Here are some of them:

   • There were no nulls.

   • Although the SELECT clause was supported, the “SELECT *” form didn’t exist. Thus, for example, to get all suppliers in London, you just wrote S WHERE CITY = 'London'—and to get all suppliers, you just wrote S.

   • Duplicates were eliminated by default (though not in “set functions”).

   • The FROM clause always contained exactly one table name. In other words, what I called in Chapter 6 “the only [form of join] supported in SQL as originally defined” wasn’t supported at all in SEQUEL as originally defined!

   • The right comparand (but not the left) in a comparison in a WHERE clause was allowed to be a subquery, in which case the comparison was in fact an ANY or ALL comparison. (Note, however, that the term subquery didn’t exist—the construct was called a mapping instead.) ANY was the default, and could only be specified implicitly. IN syntax as such was not supported; “=” (meaning, by default, “=ANY”) was used instead.

   • Set comparison operators (“⊆” etc.) were supported.

   • There was no GROUP BY clause as such; instead, GROUP BY could be specified as an option on the FROM clause.

   • There was no HAVING clause; “set functions” could be invoked in the WHERE clause instead.

   • There were no correlation names. Instead, “blocks” (apparently another term for SELECT – FROM – WHERE expressions, or in other words “mappings” in the sense indicated above) could be labeled, and block labels could be used as dot qualifiers.

   • Expressions such as QTY / AVG(QTY)—i.e., expressions involving “set function” invocations in addition to simple column references and the like—were legal in the SELECT clause, and presumably in the WHERE clause also.

   • “Blocks” or “mappings” could be combined by means of intersection, union, and difference (and these operators were denoted by conventional mathematical symbols instead of English keywords).

   The paper also discusses several perceived differences between SEQUEL and the relational calculus, claiming in every case an advantage for SEQUEL over the calculus. However, the differences and claims in question don’t really stand up to careful analysis.

3. E. F. Codd: “Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks,” IBM Research Report RJ599 (August 19th, 1969); “A Relational Model of Data for Large Shared Data Banks,” CACM 13, No. 6 (June 1970). Note: The first of these papers was reprinted in ACM SIGMOD Record 38, No. 1 (March 2009); the second was reprinted in Milestones of Research—Selected Papers 1958-1982 (CACM 25th Anniversary Issue), CACM 26, No. 1 (January 1983) and elsewhere.

   Codd’s first two papers on the relational model. The 1969 paper was, of course, the very first; essentially, it’s a preliminary version of the 1970 paper, with a few interesting differences (the main one being that the 1969 paper permitted relation valued attributes while the 1970 one didn’t). The 1970 paper was the first widely available paper on the subject, by Codd or anyone else. In fact, it’s usually credited with being the seminal paper in the field, though that characterization is a little unfair to its 1969 predecessor. I would like to suggest, politely, that every database professional should read one or both of these papers every year. Note: For some detailed analysis of both papers, see references [12] and [37]. See also reference [9].

4. E. F. Codd: “Relational Completeness of Data Base Sublanguages,” in Randall J. Rustin (ed.), Data Base Systems, Courant Computer Science Symposia Series 6. Englewood Cliffs, N.J.: Prentice Hall (1972).

   This is the paper in which Codd first formally defined the original relational algebra and relational calculus. Not an easy read, but it repays careful study.

5. E. F. Codd and C. J. Date: “Much Ado about Nothing,” in C. J. Date, Relational Database Writings 1991-1994. Reading, Mass.: Addison-Wesley (1995).

   Codd was perhaps the foremost advocate of nulls and three-valued logic as a basis for dealing with missing information (a curious state of affairs, you might think, given that nulls violate Codd’s own Information Principle). This article contains the text of a debate between Codd and myself on the subject. It includes the following delightful remark: “Database management would be easier if missing values didn’t exist” (Codd). Note: I include this particular reference, out of a huge number of available publications on the topic, because it does at least touch on most of the arguments on both sides of the issue.

6. Hugh Darwen: “The Role of Functional Dependence in Query Decomposition,” in C. J. Date and Hugh Darwen, Relational Database Writings 1989-1991. Reading, Mass.: Addison-Wesley (1992).

   This paper gives a set of inference rules by which functional dependencies (FDs) satisfied by the relation r denoted by an arbitrary relational expression can be inferred from those holding for the relvar(s) referenced in the expression in question. The set of FDs thus inferred can then be inspected to determine the key constraints satisfied by r, thus providing a basis for the key inference rules mentioned in passing in Chapter 4 of the present book.

7. Hugh Darwen: An Introduction to Relational Database Theory. Frederiksberg, Denmark: Ventus Publishing (2010), available as a free download from http://bookboon.com.

   From the preface: “This book introduces you to the theory of relational databases, focusing on the application of that theory to the design of computer languages that properly embrace it. The book is intended for those studying relational databases as part of a degree course in Information Technology (IT).”

8. Hugh Darwen: SQL: A Comparative Survey. Frederiksberg, Denmark: Ventus Publishing (2012), available as a free download from http://bookboon.com.

   This book is a companion to reference [7], showing how the coding examples in that book can be expressed in SQL. From the preface: “SQL’s many deviations from relational database theory are thus exposed and their consequences discussed. Drawing on the author’s long experience as a member of the committee responsible for production of the ISO SQL standard, the book includes copious Historical Notes showing how SQL has evolved from its very beginnings in the 1970s.” As you can see, references [7] and [8] between them cover territory somewhat similar to that covered by the present book, albeit from a rather different perspective.

9. Hugh Darwen: “Why Are There No Relational DBMSs?”, www.thethirdmanifesto.com (2015).

   Darwen’s own abstract for this paper reads somewhat as follows: “I describe the circumstances in which I obtained, in 1978, a good answer to a burning question: How can Codd’s relational model be properly embraced by a computer language? Considering that the answer to that question was publicly available in 1975, I wonder why it all went wrong and suggest some possible reasons.” Note: The answer that Darwen refers to here is documented in reference [52] in the present appendix.

10. Hugh Darwen and C. J. Date: “Textbook Treatments of Relational Algebra,” www.thethirdmanifesto.com (2015).

    This reference isn’t so much a technical paper as such, in the usual sense of that term; rather, it consists essentially of an annotated bibliography, listing some 15 database textbooks and offering opinions on the quality of the treatment of the relational model found in those books, with special attention to the treatment of relational algebra in particular.

11. C. J. Date: “Fifty Ways to Quote Your Query,” www.dbpd.com (July 1998).

    A discussion of redundancy in the SQL language.

12. C. J. Date:The Database Relational Model: A Retrospective Review and Analysis. Reading, Mass.: Addison-Wesley (2001).

    From the preface (but lightly edited here): “This book consists in essence of a series of twelve articles, originally published in the print and online portions of the Miller Freeman magazine Intelligent Enterprise (Vol. 1, Nos. 1-3, and Vol. 2, Nos. 1-9, October 1998 onward. The overall title for the series was 30 Years of Relational, on the grounds that the articles were written, in part, to celebrate the relational model's 30th birthday. The intent was to provide a historical account and impartial analysis of E. F. Codd’s (huge!) contribution to the field of database technology. Codd’s relational model, represented by a startlingly novel series of research papers appearing over the period 1969-1979, was a revolution at the time, albeit one that was desperately needed. Now, however, it seems that—despite the fact that the entire multibillion dollar database industry is founded on Codd’s original ideas—those ideas are in danger of being ignored or forgotten (or, at best, being paid mere lip service to). Certainly we can observe many examples today of those ideas being flouted in (among other things) database products, database designs, and database applications. It thus seems appropriate to take another look at Codd’s original papers, with a view to assessing their true significance and restating (and reinforcing) their message for a new generation of database professionals.” Note: The papers by Codd considered in this book include “Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks” and “A Relational Model of Data for Large Shared Data Banks” (see reference [3]); “Relational Completeness of Data Base Sublanguages” (reference [4]); and several others not mentioned elsewhere in this appendix.

13. C. J. Date: Go Faster! The TransRelational™ Approach to DBMS Implementation. Frederiksberg, Denmark: Ventus Publishing (2002, 2011), available as a free download from http://bookboon.com.

    A detailed description of The TransRelational^™ Model, a novel and radically different implementation technology mentioned in passing at various points in the present book (see, e.g., Appendixes A and F). A short and very incomplete introduction to that technology can also be found in Appendix A of reference [14]. Note: By “radically different” here, I mean radically different from the “direct image” style of implementation mentioned in passing in Chapter 1 and found in just about every mainstream SQL product today.

14. C. J. Date: An Introduction to Database Systems (8th edition). Boston, Mass.: Addison-Wesley (2004).

    A college level text on all aspects of database management. SQL discussions are at the SQL:1999 level, with a few comments on SQL:2003; in particular, they include a detailed discussion of SQL’s “object/relational” features (REF types, reference values, and so on), explaining why they violate relational principles. Note: Other textbooks covering similar territory are references [49], [60], and [61].

15. C. J. Date: “Edgar F. Codd (August 23rd, 1923 - April 18th, 2003): A Tribute and Personal Memoir,” in reference [23].

16. C. J. Date: “Double Trouble, Double Trouble,” in reference [23].

    An extensive and detailed treatment of the problems caused by duplicates. The discussion of duplicates in Chapter 4 of the present book is based in part on an example from this paper.

17. C. J. Date: “What First Normal Form Really Means,” in reference [23].

    First normal form has been the subject of much misunderstanding over the years. This paper is an attempt to set the record straight—even to be definitive, as far as possible. The crux of the argument, as indicated in Chapter 2 of the present book, is that the concept of data value atomicity (the basis of first normal form as originally defined) has no absolute meaning.

18. C. J. Date: “A Sweet Disorder,” in reference [23].

    Relations don’t have a left to right ordering to their attributes, but SQL tables do have such an ordering to their columns. This paper explores some of the consequences of this state of affairs, which turn out to be much less trivial than many seem to think. (Many of the recommendations in the present book have to do with techniques for behaving as if the state of affairs in question didn’t exist after all.)

19. C. J. Date: “On the Notion of Logical Difference,” “On the Logical Difference Between Model and Implementation,” and “On the Logical Differences Between Types, Values, and Variables,” all in reference [23].

    The titles say it all.

20. C. J. Date: “Two Remarks on SQL’s UNION,” in reference [23].

    This short paper describes some of the weirdnesses that arise in connection with SQL’s UNION operator (and by implication its INTERSECT and EXCEPT operators as well) and are caused by its support for (a) coercions and (b) duplicate rows.

21. C. J. Date: “A Cure for Madness,” in reference [23].

    A detailed examination of the fact that, very counterintuitively, the SQL expressions

    SELECT sic FROM ( SELECT * FROM t WHERE p ) WHERE q

    and

    SELECT sic FROM t WHERE p AND q

    aren’t always logically equivalent—even though they ought to be, and even though at least one current SQL product does sometimes transform the former into the latter. Note: For simplicity I choose to ignore the fact that the standard would actually require the subquery in the FROM clause in the first of the foregoing expressions to be accompanied by an AS specification.

22. C. J. Date: “Why Three- and Four-Valued Logic Don’t Work,” in reference [23].

    As noted in the body of the present book, SQL’s null support is based on three-valued logic. Actually its implementation of that logic is seriously flawed—but even if it weren’t, it would still be advisable not to use it, and this paper explains why.

23. C. J. Date: Date on Database: Writings 2000-2006. Berkeley, Calif.: Apress (2006).

24. C. J. Date: “The Closed World Assumption,” in reference [26].

    The Closed World Assumption is seldom articulated, and yet it forms the basis of almost everything we do when we use a database. This paper examines that assumption in detail; in particular, it shows why it’s preferred to its rival, The Open World Assumption (on which the “semantic web” is based, incidentally, or so it has been claimed).

25. C. J. Date: “The Theory of Bags: An Investigative Tutorial,” in reference [26].

    Among other things, this paper discusses what happens to operators such as join and union when their operands are bags (as they are in SQL, loosely speaking) instead of sets.

26. C. J. Date: Logic and Databases: The Roots of Relational Theory. Victoria, BC: Trafford Publishing (2007).

27. C. J. Date: “Inclusion Dependencies and Foreign Keys,” in reference [45].

    An alternative title for this paper might be “Rethinking Foreign Keys”; it demonstrates among other things that the foreign key notion encompasses far more than it’s usually given credit for. It also includes a detailed discussion of the logical differences between foreign keys and pointers. (As noted in passing in Chapter 2 of the present book, some writers have claimed that foreign keys are nothing more than traditional pointers in sheep’s clothing, but such is not the case.)

28. C. J. Date: “Image Relations,” in reference [45].

29. C. J. Date: “N-adic vs. Dyadic Operators: An Investigation,” in reference [45].

    Tutorial D supports n-adic versions of several relational operators—union, join, and so on—that are usually considered to be dyadic operators merely. This paper examines the twin questions of (a) what makes it possible to define an n-adic version of some dyadic operator and (b) how such n-adic versions can sensibly be defined.

30. C. J. Date: “A Remark on Prenex Normal Form,” in reference [45].

31. C. J. Date: “Is SQL’s Three-Valued Logic Truth Functionally Complete?”, in reference [45].

    Among other things, this paper includes a comprehensive description of SQL’s support for nulls and three-valued logic.

32. C. J. Date: “A Brief History of the Relational Divide Operator”, in reference [45].

33. C. J. Date: Database Design and Relational Theory: Normal Forms and All That Jazz. Sebastopol, Calif.: O’Reilly Media Inc. (2012).

    Design theory is the scientific foundation for database design, just as the relational model is the scientific foundation for database technology in general. This book, a companion to the present book, is a tutorial on database design theory (normalization, orthogonality, and related matters) for database professionals.

34. C. J. Date: View Updating and Relational Theory: Solving the View Update Problem. Sebastopol, Calif.: O’Reilly Media Inc. (2013).

    The problem of (a) updating base relvars appropriately in order to support updates on views is, abstractly, the same problem as (b) the problem of updating stored data appropriately in order to support updates on base relvars. They just show up at different points in the overall system architecture, that’s all. It follows that we must solve this problem, for otherwise we have to give up on the goal of data independence. (Note, therefore, that logical and physical data independence are really the same problem, too; they differ only in that they too show up at different points in the overall architecture.) This book argues that, contrary to popular belief, views should always be updatable, modulo only integrity constraint violations. More particularly, it elaborates on the idea, briefly discussed in Chapter 9, that a fruitful way to think about view updating in general is to consider what would happen if the view in question were defined as a base relvar instead, living alongside (as it were) the base relvar(s) in terms of which it’s defined, with constraints interrelating the two.

35. C. J. Date: “Some Comments on Iggy Fernandez’s Paper The Rise and Fall of the NoSQL Empire,” NoCOUG Journal 29, No. 2 (May 2015), www.nocoug.org/Journal/NoCOUG_Journal_201505.pdf.

    See reference [51].

36. C. J. Date: Relational Theory for Computer Professionals: What Relational Databases Are Really All About. Sebastopol, Calif.: O’Reilly Media Inc. (2013).

    The book you’re looking at right now, SQL and Relational Theory: How to Write Accurate SQL Code, discusses relational theory on the assumption that you’re already a database professional. This reference [36], by contrast, covers much of the same territory without making that same assumption. It also provides a brief introduction to transaction management and database design theory, matters not discussed in the present book.

37. C. J. Date: “Codd’s First Relational Papers: A Critical Analysis,” www.thethirdmanifesto.com (2015).

    Reference [12] analyzes Codd’s early writings with a view to highlighting all the many, many things he got right. By contrast, the present reference focuses on some of the things he at least arguably got wrong (in his first two papers [3], that is).

38. C. J. Date: The New Relational Database Dictionary. Sebastopol, Calif.: O’Reilly Media Inc. (2015).

    Many of the definitions given in the body of the present book are based on ones in this reference.

39. C. J. Date and Hugh Darwen: A Guide to the SQL Standard (4th edition). Reading, Mass.: Addison-Wesley (1997).

    This book provides thorough coverage of the SQL standard as of early 1997. Numerous features have been added to the standard since that time (including the so called “object/relational” features—see reference [14]), but they’re mostly irrelevant so far as the goal of using SQL relationally is concerned. In my not unbiased opinion, therefore, the book is still a reasonably good source for more detail on just about every aspect of SQL—at least in its standard incarnation—touched on in the body of the present book.

40. C. J. Date and Hugh Darwen: Databases, Types, and the Relational Model: The Third Manifesto (3rd edition). Boston, Mass.: Addison-Wesley (2007).

    This book introduces and explains The Third Manifesto, a detailed proposal for the future of data and database management systems. It includes a precise though somewhat formal definition of the relational model; it also includes a detailed proposal for the necessary supporting type theory (including a comprehensive model of type inheritance). See also references [42] and [45].

41. C. J. Date and Hugh Darwen: “Multiple Assignment,” in reference [23].

42. C. J. Date and Hugh Darwen: “The Third Manifesto,” in reference [45].

    This paper (Chapter 1 of reference [45]) presents the very latest version of The Third Manifesto. It consists for the most part of a revised version of the pertinent chapter from reference [40].

43. C. J. Date and Hugh Darwen: “Tutorial D,” in reference [45].

    This paper provides a comprehensive description of the most recent version of Tutorial D (which is essentially the version used in examples in the present book). Note: The website www.thethirdmanifesto.com gives information regarding a variety of existing Tutorial D implementations, as well as other projects related to proposals of The Third Manifesto.

44. C. J. Date and Hugh Darwen: “Toward an Industrial Strength Dialect of Tutorial D,” in reference [45].

    A proposal for upgrading Tutorial D to make it more suitable for commercial implementation. Certain of the ideas from this proposal (including in particular image relation and foreign key support) have been assumed in the body of the present book.

45. C. J. Date and Hugh Darwen: Database Explorations: Essays on The Third Manifesto and Related Matters. Bloomington, Ind.: Trafford Publishing (2010). Also online at www.thethirdmanifesto.com.

46. C. J. Date and Hugh Darwen: “No to SQL! No to NoSQL!” (interview by Iggy Fernandez), NoCOUG Journal 27, No. 3 (August 2013), www.nocoug.org/Journal/NoCOUG_Journal_201308.pdf.

    See Appendix F.

47. C. J. Date, Hugh Darwen, and Nikos A. Lorentzos: Time and Relational Theory: Temporal Databases in the Relational Model and SQL. Waltham, Mass.: Morgan Kaufmann (2003).

    This book is a replacement for an earlier book by the same authors, viz., Temporal Data and the Relational Model (Morgan Kaufmann, 2003). A very brief indication of what it covers can be found in Appendix A of the present book.

48. C. J. Date and David McGoveran: “Why Relational DBMS Logic Must Not Be Many-Valued,” in reference [26].

    This paper presents a series of logical arguments in support of the position that database languages should be based (like the relational model, but unlike SQL) on two-valued logic.

49. Ramez Elmasri and Shamkant Navathe: Fundamentals of Database Systems (6th edition). Boston, Mass.: Addison-Wesley (2011).

50. Stéphane Faroult with Peter Robson: The Art of SQL. Sebastopol, Calif.: O’Reilly Media Inc. (2006).

    A practitioner’s guide on how to use SQL to get good performance in currently available products. The following lightly edited list of subtitles from the book’s twelve chapters gives some idea of the scope:

    1. Designing Databases for Performance

    2. Accessing Databases Efficiently

    3. Indexing

    4. Understanding SQL Statements

    5. Understanding Physical Implementation

    6. Classic SQL Patterns

    7. Dealing with Hierarchic Data

    8. Difficult Cases

    9. Concurrency

    10. Large Data Volumes

    11. Response Times

    12. Monitoring Performance

    The book doesn’t deviate much from sound relational principles in its suggestions and recommendations—in fact, it explicitly advocates adherence to those principles, for the most part. But it also recognizes that today’s optimizers are less than perfect; thus, it gives guidance on how to choose the specific SQL formulation for a given problem, out of many logically equivalent formulations, that’s likely to perform best (and it explains why). It also describes a few coding tricks that can help performance, such as using MIN to determine that all entries in a yes/no column are yes (instead of doing an explicit existence test for no). On the question of hints to the optimizer (which many products do support), it includes the following wise words: “The trouble with hints is that they are more imperative than their name suggests, and every hint is a gamble on the future—a bet that circumstances, volumes, database algorithms, hardware and the rest will evolve in such a way that [the] forced execution path will forever remain, if not absolutely the best, at least acceptable ... Remember that you should heavily document anything that forces the hand of the DBMS.”

51. Iggy Fernandez: “The Rise and Fall of the NoSQL Empire,” NoCOUG Journal 29, No. 1 (February 2015), www.nocoug.org/Journal/NoCOUG_Journal_201502.pdf. Note: There was a mistake in this paper as originally printed—the title was given as “The Rise and Fall of the SQL Empire” (italics added).

    A good analysis of what NoSQL is all about. Appendix F was influenced by this paper.

52. Patrick Hall, Peter Hitchcock, and Stephen Todd: “An Algebra of Relations for Machine Computation,” Conf. Record of the 2nd ACM Symposium on Principles of Programming Languages, Palo Alto, Calif. (January 1975).

    This paper is perhaps a little “difficult,” but I think it’s important. Tutorial D and the version of the relational algebra I’ve described in this book both have their roots in this paper. See also references [9] and [10].

53. G. D. Held, M. R. Stonebraker, and E. Wong: “INGRES—A Relational Data Base System,” Proc. NCC 44, Anaheim, Calif. Montvale, N.J.: AFIPS Press (May 1975).

    There were two major relational prototypes under development in the mid to late 1970s—System R at IBM, and Ingres (originally INGRES, all uppercase) at the University of California at Berkeley. Unlike System R, Ingres was not originally an SQL system; instead, it supported a language called QUEL (“Query Language”), which was based on relational calculus and in many ways was technically superior to SQL. This paper, which was the first to describe the Ingres prototype, includes a preliminary definition of QUEL.

54. Jim Gray and Andreas Reuter: Transaction Processing: Concepts and Techniques. San Mateo, Calif.: Morgan Kaufmann (1993).

    The standard text on transaction management.

55. Lex de Haan and Toon Koppelaars: Applied Mathematics for Database Professionals. Berkeley, Calif.: Apress (2007).

    Among other things, this book includes an extensive set of identities (here called rewrite rules) that can be used as in Chapter 11 of the present book to help with the formulation of complex SQL expressions. It also shows how to implement integrity constraints by means of procedural code (if necessary!—see Chapter 8 of the present book). Recommended.

56. Wilfrid Hodges: Logic. London, England: Penguin Books (1977).

    A gentle introduction to logic for the layperson.

57. International Organization for Standardization (ISO): Database Language SQL, Document ISO/IEC 9075:2008 (2011).

    The official SQL standard (2011 version). Note that it is indeed an international standard and not just (as so many seem to think) an American or “ANSI” standard. Note too that although SQL:2011 is the current version of the standard, almost all of the SQL features discussed in the present book were already included in SQL:2008 or SQL:2003 or SQL:1999; in fact, most of them were included in SQL:1992 or even earlier versions.

58. David McGoveran: “Nothing from Nothing” (in four parts), in C. J. Date, Hugh Darwen, and David McGoveran, Relational Database Writings 1994-1997. Reading, Mass.: Addison-Wesley (1998).

    This paper is referenced in Appendix C of the present book.

59. Jim Melton and Alan R. Simon: SQL:1999—Understanding Relational Components; Jim Melton: Advanced SQL:1999—Understanding Object-Relational and Other Advanced Features. San Francisco, Calif.: Morgan Kaufmann (2002 and 2003, respectively).

    As mentioned in Chapter 1, the SQL standard has been through several versions over the years— the current version is SQL:2011 [57], the previous version was SQL:2008, the one before that was SQL:2003, the one before that was SQL:1999, and the one before that was SQL:1992. So far as I know, these two books are the only ones available that cover, between them, any version later than SQL:1992 in detail. Melton was the editor of the SQL standard for many years.

60. Raghu Ramakrishnan and Johannes Gehrke: Database Management Systems (3rd edition). New York, N.Y.: McGraw-Hill (2003).

61. Avi Silberschatz, Henry F. Korth, and S. Sudarshan: Database System Concepts (6th edition). New York, N.Y.: McGraw-Hill (2009).

62. Robert R. Stoll: Sets, Logic, and Axiomatic Theories. San Francisco, Calif.: W. H. Freeman and Company (1961).

    The relational model is solidly founded on logic and set theory. This book provides a fairly formal but not too difficult introduction to these topics. Note: For a less formal introduction, see the book by Hodges [56].

63. Dave Voorhis: Rel: An Implementation of Date and Darwen’s Tutorial D Database Language, http://dbappbuilder.sourceforge.net/Rel.html.

    Downloadable code for a prototype implementation of (a dialect of) Tutorial D.

64. Moshé M. Zloof: “Query-By-Example,” Proc. NCC 44, Anaheim, Calif. (May 1975). Montvale, N.J.: AFIPS Press (1977).

    Query-By-Example (QBE) is a nice illustration of the fact that it’s entirely possible to produce a very “user friendly” language based on relational calculus instead of relational algebra. (In the interest of accuracy, however, I should note that QBE is really based more on the domain calculus than it is on the tuple calculus, which is the version of the calculus discussed in the body of this book.) Zloof was the original inventor and designer of QBE, and this paper was the first of many by Zloof on the subject.