Copyright (c) 2003 C. J. Date page fm.1 ╔════════════════════════════════════════════════════════════════╗ ║ ║ ║ I N S T R U C T O R ' S M A N U A L ║ ║ ║ ╚════════════════════════════════════════════════════════════════╝ f o r ╔════════════════════════════════════════════════════════════════╗ ║ ║ ║ A n I n t r o d u c t i o n ║ ║ ║ ║ t o ║ ║ ║ ║ D a t a b a s e S y s t e m s ║ ║ ║ ║ ║ ║ ───── ♦♦♦♦♦ ───── ║ ║ ║ ║ ║ ║ Eighth Edition ║ ║ ║ ╚════════════════════════════════════════════════════════════════╝ by C. J. Date Copyright (c) 2003 C. J. Date page fm.2 P r e f a c e General Remarks The purpose of this manual is to give guidance on how to use the eighth edition of the book An Introduction to Database Systems──referred to throughout the manual as simply "the book," or "this book," or "the present book," or just "the eighth edition"──as a basis for teaching a database course. The book is suitable for a primary (one- or two-semester) course at the junior or senior undergraduate or first-year graduate level; it also contains some more forward-looking and research-oriented material that would be relevant to a more advanced course. Students are expected to have a basic understanding of (a) the storage and file management capabilities (indexing, hashing, etc.) of a modern computer system, and (b) the features of a typical high-level programming language (Java, Pascal, C, PL/I, etc.). Let me immediately say a little more regarding these two prerequisites: 1. In connection with the first, please note that although the book proper contains nothing on the subject, there's an online appendix available──Appendix D, "Storage Structures and Access Methods──that does provide a tutorial overview of such matters. That appendix is an upgraded version of material that was included in the book proper in the first six editions. But file management isn't specific to database systems; what's more, it's a huge subject in its own right, and it has textbooks of its own──see, e.g., File Organization for Database Design, by Gio Wiederhold, published by McGraw- Hill in 1987 (which, despite the title, is really about files, not databases). That's why I've dropped the inline coverage of such material from the last two editions of the present book. 2. In connection with the second, please note that the book uses a hypothetical language called Tutorial D as a basis for examples throughout. Tutorial D might be characterized, loosely, as a Pascal-like language; it's defined in detail in reference [3.3]. (See the subsection immediately following for an explanation of this reference format. I'll have more to say regarding reference [3.3] in particular later in these introductory notes──see the subsection on The Third Manifesto, pages 6-8.) All of that being said, I want to say too that I don't think either of these prerequisites is particularly demanding; but you should be prepared, as an instructor, to sidetrack occasionally Copyright (c) 2003 C. J. Date page fm.3 and give a brief explanation of (e.g.) what indexes are all about, if the question arises. A note on style: The book itself follows convention in being written in the first person plural (we, our, etc.). This manual, by contrast, is written in the first person singular (I, my, etc.)──except where (a) it quotes directly from the book, or (b) it reflects ideas, opinions, positions, etc., that are due to both Hugh Darwen and myself (again, see the subsection on The Third Manifesto, pages 6-8). The latter case applies particularly to Chapter 20 on type inheritance, Chapter 23 on temporal databases, and Chapter 26 on object/relational databases. The manual is also a little chattier than the book, using elisions such as "it's" and "they're" instead of the more stilted "it is" and "they are," etc. Structure of the Book The book overall consists of a preface plus 27 chapters (divided into six parts), together with four appendixes, as follows: Part I : Preliminaries 1. An Overview of Database Management 2. Database System Architecture 3. An Introduction to Relational Databases 4. An Introduction to SQL Part II : The Relational Model 5. Types 6. Relations 7. Relational Algebra 8. Relational Calculus 9. Integrity 10. Views Part III : Database Design 11. Functional Dependencies 12. Further Normalization I: 1NF, 2NF, 3NF, BCNF 13. Further Normalization II: Higher Normal Forms 14. Semantic Modeling Part IV : Transaction Management 15. Recovery 16. Concurrency Copyright (c) 2003 C. J. Date page fm.4 Part V : Further Topics 17. Security 18. Optimization 19. Missing Information 20. Type Inheritance 21. Distributed Databases 22. Decision Support 23. Temporal Databases 24. Logic-Based Databases Part VI : Objects, Relations, and XML 25. Object Databases 26. Object/Relational Databases 27. The World Wide Web and XML Appendixes A. The TransRelational tm Model B. SQL Expressions C. Abbreviations, Acronyms, and Symbols D. Storage Structures and Access Methods (online only) The preface gives more specifics regarding the contents of each part, chapter, etc. It also summarizes the major differences between this eighth edition and its immediate predecessor. By the way, if you're familiar with earlier editions, I'd like to stress the point that this edition, like each of its predecessors, is in large degree a brand new book──not least because (of course) I keep learning myself and improving my own understanding, and producing a new edition allows me to correct past mistakes. (In this connection, I'd like to draw your attention to the wonderful quote from Bertrand Russell in the book's preface. Also please note the epigraphs by George Santayana and Maurice Wilkes! It would be nice if the computer science community would take these remarks to heart.) The following notes, also from the book's preface, are lightly edited here: (Begin quote) The book overall is meant to be read in sequence more or less as written, but you can skip later chapters, and later sections within chapters, if you choose. A suggested plan for a first reading would be: • Read Chapters 1 and 2 "once over lightly." Copyright (c) 2003 C. J. Date page fm.5 • Read Chapters 3 and 4 very carefully. • Read Chapters 5, 6, 7, 9, and 10 carefully, but skip Chapter 8──except, probably, for Section 8.6 on SQL (in fact, you might want to treat portions of Section 8.6 "early," perhaps along with the discussion of embedded SQL in Chapter 4). Note: It would be possible to skip or skim Chapter 5, too, but if you do you'll need to come back and deal with it properly before you cover Chapter 20 or Chapters 25-27. • Read Chapter 11 "once over lightly." • Read Chapters 12 and 14 carefully, but skip Chapter 13. (You could also read Chapter 14 earlier if you like, possibly right after Chapter 4. Many instructors like to treat the entity/relationship material much earlier than I do. For that reason I've tried to make Chapter 14 more or less self- contained, so that it can be read "early" if you like.) • Read Chapters 15 and 16 carefully. • Read subsequent chapters selectively (but in sequence), according to taste and interest. I'd like to add that instructors, at least, should read the preface too (most people don't!). Each chapter opens with an introduction and closes with a summary; each chapter also includes a set of exercises (and the online answers often give additional information about the subject at hand). Each chapter also includes a set of references, many of them annotated. This structure allows the subject matter to be treated in a multi-level fashion, with the most important concepts and results being presented inline in the main body of the text and various subsidiary issues and more complex aspects being deferred to the exercises, or answers, or reference annotation, as appropriate. With regard to those references, by the way, I should explain that references are identified in the text by two-part numbers in square brackets. For example, the reference "[3.1]" refers to the first item in the list of references at the end of Chapter 3: namely, a paper by E. F. Codd published in CACM 25, No. 2, in February, 1982. (For an explanation of abbreviations used in references──e.g., "CACM"──see Appendix B. Regarding Codd in particular, let me draw your attention to the dedication in this new edition of the book. It's a sad comment on the state of our field that I often encounter database students or professionals who have never heard of Ted Codd.) Copyright (c) 2003 C. J. Date page fm.6 (End quote) This manual gives more specific guidance, with rationale, on what can safely be skipped and what really ought not to be. As indicated above, it also gives answers to the exercises──or most of them, at any rate; note, however, that some exercises don't have any single "right" answer, but instead are intended to promote group discussion and perhaps serve as some kind of miniproject. Such cases are flagged in this manual by the phrase No answer provided. Note: The book also includes a number of inline exercises embedded in the body of the text, and the remarks of this paragraph apply to those inline exercises too. Structure of this Manual The broad structure of this manual mirrors that of the book itself: It consists of this preface, together with notes on each part, each chapter, and each appendix from the subject book (including the online Appendix D). Among other things, the notes on a given part or chapter or appendix: • Spell out what that piece of the book is trying to achieve • Explain the place of that piece in the overall scheme of things • Describe and hit the highlights from the relevant text • Indicate which items can be omitted if desired and which must definitely not be • Include additional answers to exercises (as already noted) and, more generally, give what I hope are helpful hints regarding the teaching of the material. The Third Manifesto You might be aware that, along with my colleague Hugh Darwen, I published another database book a little while back called The Third Manifesto [3.3]. * The Third Manifesto consists of a detailed technical proposal for the future of data and database systems; not surprisingly, therefore, the ideas contained therein inform the present book throughout. Which isn't to say The Third Manifesto is a prerequisite to the present book──it isn't; but it is directly relevant to much that's in this book, and further pertinent information is often to be found there. Instructors in Copyright (c) 2003 C. J. Date page fm.7 particular really ought to have a copy available, if only for reference purposes. (I realize this recommendation is somewhat self-serving, but I make it in good faith.) Students, on the other hand──at least beginning students──would probably find much of The Third Manifesto pretty heavy going. It's more of a graduate text, not an undergraduate one. ────────── * The full title is Foundation for Future Database Systems: The Third Manifesto (2nd edition, Addison-Wesley, 2000). The first edition (1998) had the slightly different title Foundation for Object/Relational Databases: The Third Manifesto; however, it wasn't exclusively about object/relational databases as such, which was why we changed the title for the second edition. By the way, there's a website, too: http://www.thethirdmanifesto.com. The website http://www.dbdebunk.com also contains much relevant material. ────────── I should explain why we called that book The Third Manifesto. The reason is that there were two previous ones: • The Object-Oriented Database System Manifesto [20.2,25.1] • The Third Generation Database System Manifesto [26.44] Like our own Manifesto, each of these documents proposes a basis for future DBMSs. However: • The first essentially ignores the relational model! In our opinion, this flaw is more than enough to rule it out immediately as a serious contender. • The second does agree that the relational model mustn't be ignored──but unfortunately goes on to say that supporting the relational model means supporting SQL. The Third Manifesto, by contrast, takes the position that any attempt to move forward, if it's to stand the test of time, must reject SQL unequivocally (see the next subsection, "Some Remarks on SQL," for further elaboration of this point). Of course, we're not so stupid as to think SQL is going to go away; after all, COBOL has never gone away. Au contraire, SQL databases and SQL applications are obviously going to be with us for a long time to come. So we do have to worry about what to do about today's "SQL legacy," and The Third Manifesto does include some specific Copyright (c) 2003 C. J. Date page fm.8 suggestions in this regard. Further discussion of those suggestions would be out of place here, however. The Third Manifesto also discusses and stresses several important logical differences (the term is due to Wittgenstein)──i.e., differences that are quite simple, yet crucial, and ones that many people (not to mention products!) seem to get confused over. Some of the differences in question are: • Model vs. implementation • Value vs. variable • Type vs. representation • Read-only operator vs. update operator • Argument vs. parameter • Type vs. relation and so on (this isn't meant to be an exhaustive list). These notes aren't the place to spell out exactly what all of the differences are (in any case, anyone who claims to be an instructor in this field should be thoroughly familiar with them already); rather, my purpose in mentioning them here is to alert you to the fact that they are appealed to numerous times throughout the book, and also to suggest that you might want to be on the lookout for confusion over them among your students. Of course, the various differences are all explained in detail in The Third Manifesto, as well as in the book itself. As noted earlier, The Third Manifesto also includes a definition of Tutorial D──although, to be frank, there shouldn't be any need to refer to that definition in the context of the present book (the Tutorial D examples should all be pretty much self-explanatory). Some Remarks on SQL As noted in the previous subsection, The Third Manifesto takes the position that any attempt to move forward, if it's to stand the test of time, must reject SQL. This rather heretical position clearly needs some defending; after all, earlier editions of An Introduction to Database Systems actually used SQL to illustrate relational ideas, in the belief that it's easier on the student to show the concrete before the abstract. Unfortunately, however, the gulf between SQL and the relational model has now grown so Copyright (c) 2003 C. J. Date page fm.9 wide that I feel it would be actively misleading to continue to use it for such a purpose. Indeed, we're talking here about another huge logical difference: SQL and the relational model aren't the same thing!──and in my opinion it's categorically not a good idea (any more) to use SQL as a vehicle for teaching relational concepts. Note: I make this observation in full knowledge of the fact that many database texts and courses do exactly what I'm here saying they shouldn't. At the risk of beating a dead horse, I'd like to add that SQL today is, sadly, so far from being a true embodiment of relational principles──it suffers from so many sins of both omission and commission (see, e.g., references [4.15-4.20] and [4.22])──that my own preference would have been to relegate it to an appendix, or even to drop it entirely. However, SQL is so important from a commercial point of view (and every database professional does need to have some familiarity with it) that it really wouldn't have been appropriate to dismiss it in so cavalier a fashion. I've therefore settled on a compromise: a chapter on SQL basics in Part I of the book (Chapter 4), and individual sections in later chapters describing those aspects of SQL, if any, that are relevant to the subject of the chapter in question. (You can get some idea of the extent of that SQL coverage from the fact that there are "SQL Facilities" sections in 14 out of a total of 23 subsequent chapters.) The net result of the foregoing is that, while the eighth edition does in fact discuss all of the most important aspects of SQL, the language overall is treated as a kind of second-class citizen. And while I feel this treatment is appropriate for a book of the kind the eighth edition is meant to be, I do recognize that some students need more emphasis on SQL specifically. For such students, I believe the book provides the basics──not to mention the proper solid theoretical foundation──but instructors will probably need to provide additional examples etc. of their own to supplement what's in the book. (In this connection, I'd like, somewhat immodestly, to recommend reference [4.20] as a good resource.) What Makes this Book Different? The following remarks are also taken from the book's preface, but again are lightly edited here: (Begin quote) Every database book on the market has its own individual strengths and weaknesses, and every writer has his or her own particular ax to grind. One concentrates on transaction management issues; another stresses entity/relationship modeling; another looks at Copyright (c) 2003 C. J. Date page fm.10 everything through a SQL lens; yet another takes a pure "object" point of view; still another views the field exclusively in terms of commercial products; and so on. And, of course, I'm no exception to this rule──I too have an ax to grind: what might be called the foundation ax. I believe very firmly that we must get the foundation right, and understand it properly, before we try to build on that foundation. This belief on my part explains the heavy emphasis in this book on the relational model; in particular, it explains the length of Part II──the most important part of the book──where I present my own understanding of the relational model as carefully as I can. I'm interested in foundations, not fads and fashions. Products change all the time, but principles endure. In this regard, I'd like to draw your attention to the fact that there are several important "foundation" topics for which this book, virtually alone among the competition, includes an entire in-depth chapter (or an appendix, in one case). The topics in question include: • Types • Integrity • Views • Missing information • Inheritance • Temporal databases • The TransRelational Model In connection with that same point (the importance of foundations), I have to admit that the overall tone of the book has changed over the years. The first few editions were mostly descriptive in nature; they described the field as it actually was in practice, "warts and all." Later editions, by contrast, were much more prescriptive; they talked about the way the field ought to be and the way it ought to develop in the future, if we did things right. And the eighth edition is certainly prescriptive in this sense (in other words, it's a text with an attitude!). Since the first part of that "doing things right" is surely educating oneself as to what those right things actually are, I hope this new edition can help in that endeavor. (End quote) The foregoing remarks explain (among other things) the comparative lack of emphasis on SQL. Of course, it's true that students who learn the theory thoroughly first are going to have a few unpleasant surprises in store if and when they get out into the commercial world and have to deal with SQL products; it's also [...]... Arlington St #300, Boston, Mass 0 211 6, care of Katherine Harutunian ( 617 /84 8-7 518 ) Thank you for your interest Healdsburg, California 2003 C J Date *** End of Preface *** Copyright (c) 2003 C J Date fm .12 page P A R T I P R E L I M I N A R I E S The introduction to Part I in the book itself is more or less self-explanatory: (Begin quote) Part I consists of four introductory chapters: • Chapter 1 sets... aim is to serve as a gentle introduction to the much more comprehensive discussions of the same subject in Part II and later parts of the book) It also introduces and explains the running example, the suppliers-and-parts database • Finally, Chapter 4 introduces the standard relational language SQL (more precisely, SQL :19 99) (End quote) Chapters 1 and 2 can probably be covered quite quickly Chapter... instance involving exactly two entity instances (again, not necessarily distinct) Note: As an example of a binary relationship instance in which the two entity instances aren't distinct, consider the often heard remark to the effect that so-and-so is his or her own worst enemy! • A command-driven interface is an interface that permits the user to issue requests to the system by means of explicit commands... used to mean either DBMS product or DBMS instance, as the context demands, and the term database is often used to mean DBMS in either sense What's more, the term DBMS is even used on occasion to mean the database! In the book and this manual the unqualified term database ALWAYS means database, not DBMS, Copyright (c) 2003 C J Date page 1. 6 and the unqualified term DBMS ALWAYS means DBMS instance, not... these answers, that all of the data in the system is in fact kept in just one database This assumption is very unrealistic in practice.) • (Physical) data independence is the immunity of applications to changes in storage structure (how the data is physically stored) and access technique (how it is physically accessed) Note: Logical data independence is discussed in Chapters 2, 3, and especially 10 See... should certainly be paid to the concept of (physical) data independence and the associated distinctions between: a Logical vs physical issues b Model vs implementation issues In connection with the second of these distinctions (which is really a special case of the first), the general concept of a data Copyright (c) 2003 C J Date page 1. 2 model should also be covered (with illustrations of objects and... deletion, and replacement They're meant to be (and in fact are) pretty much self-explanatory! b As for the SQL exercises, it seems to me that very little extrapolation from the examples is required on the part of the student in order to understand the exercises and answer Copyright (c) 2003 C J Date page 1. 3 them (they really aren't very difficult) exercises can be skipped if desired Of course, the... (DBMS) is a software component that manages the database and shields users from low-level details (in particular, details of how the database is physically stored and accessed) All requests from users for access to the database are handled by the DBMS Caveat: Care is needed over terminology here The three concepts database, DBMS product, and DBMS instance are (obviously) logically distinct Yet the term... understandable, perhaps You might therefore prefer just to give these first two chapters a "once over lightly" reading for now, and to reread them more carefully later as they become more directly relevant to the topics at hand (End quote) The fact is, given the widespread availability and use of database systems today (on desktop and laptop computers in particular), many people have a basic understanding... the database does not contain any incorrect information Note: The integrity concept is CRUCIAL and FUNDAMENTAL, as later chapters (especially Chapter 9) make clear • A menu-driven interface is an interface that permits the user to issue requests to the system by selecting and combining items from predefined menus displayed on the screen • A multi-user system is a system that supports concurrent access . Forms 14 . Semantic Modeling Part IV : Transaction Management 15 . Recovery 16 . Concurrency Copyright (c) 2003 C. J. Date page fm.4 Part V : Further Topics 17 . Security 18 . Optimization. applications to changes in storage structure (how the data is physically stored) and access technique (how it is physically accessed). Note: Logical data independence is discussed in Chapters. Part I : Preliminaries 1. An Overview of Database Management 2. Database System Architecture 3. An Introduction to Relational Databases 4. An Introduction to SQL Part II : The Relational