This book sheds light on the principles behind the relational model, which is fundamental to all database-backed applications--and, consequently, most of the work that goes on in the computing world today. Database in The Relational Model for Practitioners goes beyond the hype and gets to the heart of how relational databases actually work. Ideal for experienced database developers and designers, this concise guide gives you a clear view of the technology--a view that's not influenced by any vendor or product. Featuring an extensive set of exercises, it will help Database in Depth will appeal not only to database developers and designers, but also to a diverse field of professionals and academics, including database administrators (DBAs), information modelers, database consultants, and more. Virtually everyone who deals with relational databases should have at least a passing understanding of the fundamentals of working with relational models. Author C.J. Date has been involved with the relational model from its earliest days. An exceptionally clear-thinking writer, Date lays out principle and theory in a manner that is easily understood. Few others can speak as authoritatively the topic of relational databases as Date can.
Christopher J. Date (born 1941) is an independent author, lecturer, researcher, and consultant, specializing in relational database theory. —from wikipedia
* I'm writing the review after re-reading the book. My tone is probably less excited than it would have been if this was a first reading.
* This book is "superseded" by another, called "SQL and Relational Theory". You should probably read that instead.
Despite the name, this book is a gentle introduction to the relational theory. It explains the theoretical underpinnings of RDBMSs. If you don't know this stuff, the book is amazing. It uses a very understandable language and doesn't get too much into the math). It makes some very good points about how to use a relational databases (for example, why NULL values can be evil). There's even a chapter on normal forms that goes into satisfying detail.
There are two downsides. First, the author is zealous at times. There is a lot of SQL-bashing that's not constructive – you get that it's not a great language the first time. Every rant rant after that gets annoying. Second, the practical application of the ideas in the book are a bit limited. It would be awesome if we can do everything C. J. Date talks about, but unfortunately existing RDBMS products don't allow it.
Apart from that, it's a great book. It paints a picture of how relational databases should look like and leaves you sad that all the *SQL products look very differently.
»THE RELATIONAL MODEL HAS NEVER BEEN PROPERLY IMPLEMENTED IN COMMERCIAL FORM«
* Autor C.J.Date gründete 1984 mit Relational-Model-Begründer E.F.Codd die Beratungsfirma "Codd and Date Consulting Group"
* "Message of the book: Let's implement the relational model", "The relational model has never been properly implemented in commercial form", SQL only a first approximation
* Autor C.J.Date kritisiert SQL (zu rigide, nutzt Bags statt Sets bzw. erlaubt und erzeugt Duplikate, zudem mit untersch. Grad bei untersch. Formulierungen fürs gleiche Query), kritisiert NULL bzw. dreiwertige Logik, erklärt und verwendet daher im Buch neben SQL seine eigene, der Theorie treuere Sprache Tutorial D
* erste Buchhälfte führt durch die Begriffswelt des relationalen Modells; wer aus der SQL-only-Welt kommt, wird neben Tutorial D vielleicht auch noch neue (alte) Wörter lernen müssen; der Autor spricht irgendwann nicht mehr von Tabellen, Select etc. sondern theoriegemäß von Relation Variables (RelVars) und Relations (deren Werte), Projections usw.
* C.J.Date schreibt gut, will verständlich sein, erwartet Menschen mit einem SQL-only-Hintergrund (das meint "for Practitioners", keine geheimen Praxistipps aus der Theorie), entwickelt manchen Strang "spiralförmig", nimmt also zuvor Behandeltes immer wieder auf und baut es aus (wirkt auf manche mglw. repetitiv); zweite Buchhälfte ist kurzatmiger und fordert mehr Niveau/Selberdenken beim Nachvollziehen der Zusammenhänge; insg. guter Stichwortgeber, musste hin und wieder fremdlesen (zB. Wikipedia); Zusammenfassung und Wiederholungs- bzw. Übungsfragen am Ende jedes Kapitels
* interessantere Stränge im Buch: Database as a logical/formal system und rel. Algebra - DB not just data but facts (can be thought of as a collection of true propositions) - whole apparatus of formal logic becomes available for "the database problem" - when system evaluates some relational expression (when it responds to some query), it's deriving new truths from given ones; it's proving a theorem - "What A Database Really Is: Predicates and Propositions" by Hugh Darwin, 1998 - relational algebra/relational calculus, closure, primitive and derived relational operators <-> expression transformation & transformation laws (autom. query rewrites/optimization) = Autor vermittelt grobe Idee von allem, aber nicht Fisch, nicht Fleisch, hat mehrere Bücher, mglw. mehr in "Logic and Databases"
* Constraints-Kapitel berührt v.a. Datenbank-/Transition-/Type-Constraints; sind Business Rules, keine Praxishinweise (mglw. Off-Topic); bisschen theoret. Kritik an ggw. ACID-Transaktionen
* DB design theory "still largely subjective in nature" - Autor behandelt nur wissenschaftlicheren Teil: formale Prinzipien, v.a. Normalisierung (inkl. 1-6 NF) und Orthogonalität = Reduktion von Redundanz bzw. deren Folgen: update-anomalies, jeopardized integrity, updates and queries harder to formulate (mistakes) - manches zu schnell behandelt, z.B. Zusammenhang Normalformen & Functional Dependencies, Join Dependencies, Mutlivalued Dependencies usw. - logical design: Constraints and predicates highly relevant here; Concentrate on what the data means, rather than on how it will be used; DB = faithul representation of the semantics of the situation, and constraints represent semantics; Process: (1.) pin down the RelVar predicates, (2.) map output from step 1 into RelVars and constraints (FDs, MVDs, JDs, ...) - C.J.Date kein Modeling-Fan: ER etc incapable of representing constraints - almost no "data independence" today: physical design change (performance) => logical design change (denormalization for performance) because phys. design maps 1:1 to logical design (relvar=file, tuple=record); new technology: TransRelational Model (TM) derives phys design autom.
* Relational Model: - by Edgar Frank "Ted" Codd, 1969-paper, IBM - firmly founded in set theory & predicate logic - is rock solid and "right" and will endure because set theory & predicate logic are rock solid: elements of predicate logic go back over 2000 yrs (Aristotle) -- vs: object oriented model, hierarchical model, codasyl network model, semistructured model = arent in the same ballpark; dont deserve to be called models at all; OO = no consensus of what the model consists of - misleading to think in terms of "Structure + Integrity + Manipulation" - "Relations" as in mathematics (https://en.wikipedia.org/wiki/Finitary_relation) - "Types are sets of things we can talk about. Relations are (true) statements about those things. Types are to relations as nouns are to sentences. Without types we have nothing to talk about. Without relations, we can't say anything" - Relationen müssen nicht 2-dimensional sein (Tabellen)
* Autor redet übrigens häufig von "Table Dee" und "Table Dum"; dass sie die Werte TRUE und FALSE als Relation for the sake of relational Algebra darstellen, ist mir erst beim Fremdlesen im Netz klar geworden; im Buch vielleicht irgendwo überlesen
Not all those who wish to learn more about the innards of databases have a deep knowledge of math and are straight out of the academy. This was a very high-brow book, oftentimes hard to read and follow because of the heavily academic language. But I did it. This book gave me a good understanding of the theoretical background on which databases are built and that's great, but it can be written slightly better.
Some strong ideas (domains are types) coupled with some that haven't aged well (the comparison to OO and network is pretty funny).
The basic thesis seems to be, "none of the databases out there actually implement the relational model correctly. This is the source of lots of problems." However, like many relational model purists, Date is less willing to acknowledge, at least in this book, that a correctly implemented relational model might not be the be-all and end-all goal of software development.
(I'm old enough to remember this attitude: that the _real_ problem of databases was that they couldn't enforce integrity constraints because the data wasn't modeled properly...for some applications, yes, but at some point it becomes a solution looking for a problem.)
Very poorly written book about databases. While the content was informative, reading the author's writing was an arduous task. He was repetitive, redundant, and said the same things over and over. He was way too colloquial in his writing, ya know what I mean, dawg? And the wordiness, my God! It's like, as one would say, in my opinion, reading, or thumbing through carelessly, a college freshman's essay. I could go on, and in chapter two of this review I do, about the lack of brevity, or shall I say the lack of interest, the folly or mistake of avoiding concise wording. I'm all like, wtf, bro?
The title says that the book is for practitioners, but still the subject is far from the physical database manager. Not that it is bad, but it is not that practical. I still learned some great things, and got a brush-up on key issues.
A crisp and readable introduction to relational database theory for practitioners, and an entertaining polemic against the current crop of relational database systems and SQL.