The contribution Chris Date (after Ted Codd) has made (with others such as Hugh Darwen) to the development, evolution, and expansion of the Relational Model (RM) is well documented, and correctly so.

Contrary to what some other readers might prefer, I do want to hear want he has to say about the current state of (Database Management System) industry affairs -- I don't believe there's anyone better qualified today to expound on what does or may, and on what does not or may not, constitute the RM. But it's important that you have some experience in the industry; Date does state that this book is for 'professionals' in the field.

Date's ideas on NULLs, Relation Valued Attributes (specifically on how they do not violate first normal form), Boyce-Codd normal form, 5th & 6th normal form, Relational Algebra, Relational Calculus, predicate logic, propositions, etc., are well worth the hearing. It's also instructive why he has so many misgivings about SQL (and here is an individual who, in conjunction with Darwen, has produced a respected reference on the SQL standard), though pre-1992 SQL is a different animal from post-1992 SQL.

In my humble opinion, if even half the originators of some modern day computing 'technologies' were even half as rigorous as Date in subjecting their own ideas to searching logical examinations, we wouldn't have had near as many development cycle overruns, cost breaches, project collapses, etc. And well written too.

The author is quite opinionated, and, in my opinion, can be, since he worked with Codd directly. He covers the relational algebra behind databases. If this sounds technical and theoretical, it is. However, it is quite interesting to learn the reasoning behind SQL and current DBMS engines.

The author writes clearly for the most part. If you use SQL, be careful not to jump to conclusions as you read a section: SQL departs from the theoretical/mathematical underpinnings of databases in many ways, and it is easy to fall into the habit of taking what Date is saying and trying (and failing) to apply it to SQL problems.

Overall a good book if you are interested in the theory behind your database. Purely practical-focused readers will likely be disappointed.

If you work with DataBases, and like me, you learned it on a need-to-know basis, you must get your hands on this book. This is *not* a book about how to write SQL, and if you don't already know SQL fairly well, you'll get nothing out of it. But if you've ever felt you didn't quite grok the deeper techniques of database design, theer is much value in this book. It will slowly chisel away some of your less worthy ideas, and replace them with clear, clean theory. Your database skills will improve by themselves. But again, this is a medium to expert level book. Learn some SQL, and then come back to find out a. what's wrong with SQL, and b. how to build good databases.

Chris Date's newest book reads not like a text nor like a how-to guide. It is more like a discussion with other database professionals about his labor of love. The assumption throughout is that his audience share his passion -- or at least his labor -- and have a significant level of experience in the field but who also have (from his point of view) waivered in the fudamentals of true relational theory.

It is much like a conversation that can be interrupted and resumed and different points in time. In this respect, the book reads very well as compared to his earlier texts. It also explains the use of the first person and the occasional forward-referencing.

That being said, newcomers to realtional theory and practice may be frustrated, but seasoned professionals may enjoy a dialogue with a favorite albeit quirky mentor.

The material is interesting, C.J. Date tries to go beyond the practicality of SQL and back to fundamentals of relational theory. He makes interesting points about NULL, duplicate values and such, but this assumes a fair level of familiarity with SQL (viz. you use SQL on a regular basis).

I find the editing poor in that the author very often states that some point is explained in later chapters or later in a given chapter. While this is fine once or twice, it quickly becomes tiresome and frustrating; to many forward references.

This book is not quite a theory book (light on the math side) but a book to be read nonetheless as it delves into matters seldom found in database books (at least the mainstream crop).

I found that while the content of this book as within my grasp, "Database in Depth" was very hard to read. Judging from the content and writing style, I don't believe this book was written for practitioners.

This book is very focused on the author and his opinions; the word "I" was very much overused. Even each point in the chapter summary is started with "I" which is very unusual for a technical book. Another reviewer wrote "Debates over finer points of arcane minutia will cause me to zone out quickly. Unfortunately, I felt that way through a lot of this book." I couldn't agree more; this book is very dogmatic. The sentence structure and grammar also made Database in Depth a hard read. Runaway ideas and sentences with excessive punctuation left me frustrated.

To demonstrate the above points, here is a portion of the summary of chapter 1.

"- I claimed that SQL and the relational model aren't the same thing. We've seen a few differences already-for example, the fact that SQL permits duplicate rows-and we'll see many more in later chapters.

One last point (I didn't mention this explicitly before, but I hope it's obvious from everything I did say): overall, the relational model is declarative, not procedural, in nature; that is, we favor declarative solutions over procedural ones, wherever such solutions are feasible. The reason is obvious: declarative means the system does the work, procedural means the user does the work (so we're talking about productivity, among other things). That's why the relational model supports declarative queries, declarative updates, declarative view definitions, declarative integrity constraints, and so on."

Today I returned "Database in Depth" and picked up "Designing Effective Database Systems" (Riordan, 2005) instead. I'm already finding this Addison-Wesley title to be much more useful and down to earth.

This book is more or less exactly what it claims to be: a solid theoretical grounding in the relational model targeted at working software developers and database programmers. It combines concise explanations with explorations of pragmatic concerns, and includes genuinely useful exercises at the end of each chapter. If you're somebody who understands things best when you understand why the system is doing what it does, you'll find this book invaluable in sorting through questions like, "Why should I normalize the schema? Why are NULLs bad? What's a quota query?"

Speaking as someone who really enjoys abstract theoretical discussions of programming concepts, my only significant fault with the book was that occasionally Date's use of language was a little more informal than I would have liked; I would have liked a slightly more rigorous explanation of the links between the predicate calculus and set theory and the relational model, and could have used more mathematical notation. In addition, sometimes Date is... if not disingenuous, a little quick in glossing over the changes he has made to the relational model over the years (he and E. F. Codd, the originator of the relational model, diverged in their thinking a bit over the years).

One caveat: this book is not a cookbook or a how-to guide. It works from first principles outwards, and as such isn't exactly filled with immediately useful code snippets. In fact, as much as possible Date uses his own relational data language, Tutorial D, instead of SQL. He does have good reasons for disliking SQL as a pedagogical tool (or much of anything else), which he explains in depth throughout the text, but people who work best with directly applicable code they can pick up and apply to their own problems will find this book frustrating.

Overall, though, this is a quick, dense read and will do an amazing amount to clarify your thinking about how database systems work and what they ought to be.

Many years ago when I was a student we were taught database theory. Although Ted Codd's paper "A Relational Model of Data for Large Shared Data Banks" had been published fifteen years earlier, relational databases hadn't yet become the dominant species and we were taught a number of alternatives (does anyone else remember Codasyl?) systems - relational databases and SQL were just the newest option.

Of course, once I left college and started working for a living, it wasn't long before relational databases were the only game in town. And over the years I've forgotten most of the non-relational theory that I once knew. Or, at least, that's what I thought. Reading this book, I realise that I had forgotten most of the relational theory too.

The relational model is what underpins most of the databases that we use in our day-to-day work. But in many ways, the databases that we use today have diverged greatly from Codd's original ideas. Many of the features of todays databases would have no place in a purely relational database.

And that is what Chris Date's latest book is all about. He reminds us of what a really relational database would look like and points out where current implementations fall short. In particular, it's clear that Date blames the ubiquity of SQL for most of these problems. SQL, he reminds us, started out as an attempt to put a user-friendly(!) query language on top of the relational model. When that didn't really work out, instead of going back to square one and trying to implement a better relational query language the database vendors instead stuck with SQL and ignored the bits of the relational model which it couldn't support. For most of the examples in the book, Date gives an SQL query alongside the same query rewritten in "Tutorial D" a relational query language of his own creation.

The book does contain a useful introduction to the relational model, but I have to say that in doing so it uses some mathematics that many potential readers might find a bit galling. Personally, I'd be very happy if more database practioners understood the underlying maths to the level required to read this book as that would hopefully mean an increase in the average quality of the database designs that I come across.

Date is at his most interesting when he is talking about the advantages that a "proper" relational database implementation would bring us. As he says in a recent interview:

"As far as I'm concerned, an object/relational system done right would simply be a relational system done right, nothing more and nothing less."

There are some exciting possibilities in a truely relational database, but it would mean the industry admitting that its current implementations are flawed. And I don't see that happening.

If you work with databases and you have any interest in the mathematical theories behind how your database works, then I recommend you read this book. You'll come out with a deeper understanding of your current database system. But, perhaps more importantly, you'll also have a slight sense of disappointment when you realise how good your database could be.

A really outstanding presentation of the core of the relational model, and a discussion of where SQL falls short (-- a lot). Date assumes you know a reasonable amount about databases already so he can be concise and to the point.

Some mathematical background would be a plus for reading this book.

I am writing a review on Amazon for the first time. I had thought about writing review of some books I read but I always kept postponing it.
Chris Date's Database in Depth is one of the best written technical books I have ever read. Date is a terminology freak and he leaves no stone unturned in being correct to the last letter. Some people say that its a dry book, but I found it thoroughly enjoyable. Before reading the book I knew little about relational theory (although I could write some SQL queries), infact I thought that "Relational" referred to the relationships between tables. This book has been an awesome revelation and now I have started to read C.J.Date's Introduction to Database Systems book also.
As a side note, I would like to find out whats the expansion of 'J' in C.J.Date :-)
Hope atleast some of you will find the book as beneficial as I did.

I found this book far more accessible than Date's other book; "An Introduction to Database Systems". He provides an explanation of relational theory then demonstrates it in a simplified SQL format. Normalization is covered well. That's critical to understanding proper schema design.

The text of the book is a little dry and academic. Which I suppose is to be expected. In addition Date has his viewpoint expressed clearly in the book. An example is his aversion to the use of nulls.

Over the last week or so, I've been reading C. J. Date's book Database In Depth - Relational Theory for Practitioners (O'Reilly). While it's a well-done title, it's the type of book I have a hard time reading...

Contents:
Introduction; Relations Versus Types; Tuples And Relations; Relation Variables; Relational Algebra; Integrity Constraints; Database Design Theory; What Is The Relational Model?; A Little Bit Of Logic; Suggestions For Further Reading; Index

C. J. Date, along with E. F. Codd (the acknowledged "father" of relational database theory), are probably the two most influential individuals in this field. Much of what we know and practice in today's RDBMS packages all goes back to the work these two have done. Rather than write a textbook style discussion of the finer points of database theory, Date has used this book to update some of his thinking and to consolidate a number of his talks and writings of late. For serious students of relational database concepts, I'd consider this the latest "must read" to keep up with current thinking by one of the masters.

Having said that, I had a hard time slogging through the material. I tend to gravitate to technical reading material that is practical and understandable. Debates over finer points of arcane minutia will cause me to zone out quickly. Unfortunately, I felt that way through a lot of this book. There is a lot of solid technical material here, and it's definitely geared towards serious readers. Date doesn't have a lot of kind words to say about how database vendors have implemented the relational model, nor does he feel SQL is a good thing. I, on the other hand, figure the packages are what they are, and you had better learn to use them to create the systems needed by your customers. That's probably why I'm a developer and not a system architect. Reading a number of pages on why Date and Codd disagree on whether nulls are valid or allowed doesn't do much for me. They're there, you need to understand them, and then you need to move on. Another hard part for me was the heavy emphasis on mathematical proofs and such. Since I don't have that type of background, I'm quickly lost...

Even though I wasn't completely enamored with the book, I still think it is a good title. For the right reader, this will be material that they will benefit from. For the average person who got training on Oracle or DB2 and understand basic relational database theory, this may be a bit more difficult to get through...

Relational atabases are fundamental to today's IT operations. They underpin virtually all transactional and content management systems. Knowing how to work with relational databases is a critical tool in every IT practitioner's kit.

However, many learn how to use RDBMs via practical, on-the-job experience, or perhaps through a RDBMs vendor class, without understanding the underlying theory. Just as many programmers who work with classes and objects could become more proficient with a deeper grasp of object theory, the same is true for database designers, DBAs, and software engineers responsible for data interface layers.

This book provides a great knowledge base of the general theory of RDBMs in an thorough, well-organized and easy to read format - which is not an easy combo to carry off.

Database in Depth is particularly useful if your exposure to RDBMs has been through the lens of a particular vendor. It's easy to get confused between functionality and implementation; this book helps clarify the difference.

If you feel like you use databases without really understanding what does on under the hood, read this book.

Hmm. Didn't look like an O'Reilly book, at first glance. No 19th century style woodcut on the cover. Seriously, though, Date presents what you might call a "clarification" of a relational database usage. He takes issue with current SQL implementations. But to gain from this book, you need proficiency in SQL and some understanding of relational databases. Not for the tyro.

If you also hail from a pure maths background, that will aid in understanding. He revisits the basic concepts of relational databases; injecting considerable rigour into defining these. Perhaps most importantly, he shows why nulls are very bad in a table. Relational theory is built on Boolean logic, but nulls force a ternary logic that can screw everything up. And duplicate tuples (rows) are almost as bad. The fact that all current SQL implementations routinely permit nulls and duplicates shows their limitations.

Rather unsettling, if you thought that db2 or Oracle were the last words in this field.