Database Design and Relational Theory: Normal Forms and A... and over 2 million other books are available for Amazon Kindle . Learn more
£25.49
  • RRP: £29.99
  • You Save: £4.50 (15%)
FREE Delivery in the UK.
Only 5 left in stock (more on the way).
Dispatched from and sold by Amazon.
Gift-wrap available.
Quantity:1
Database Design and Relat... has been added to your Basket
Trade in your item
Get a £3.52
Gift Card.
Have one to sell?
Flip to back Flip to front
Listen Playing... Paused   You're listening to a sample of the Audible audio edition.
Learn more
See all 2 images

Database Design and Relational Theory: Normal Forms and All That Jazz (Theory in Practice) Paperback – 27 Apr 2012

1 customer review

See all 3 formats and editions Hide other formats and editions
Amazon Price New from Used from
Kindle Edition
"Please retry"
Paperback
"Please retry"
£25.49
£14.65 £15.57
£25.49 FREE Delivery in the UK. Only 5 left in stock (more on the way). Dispatched from and sold by Amazon. Gift-wrap available.

Frequently Bought Together

Database Design and Relational Theory: Normal Forms and All That Jazz (Theory in Practice) + Database in Depth: Relational Theory for Practitioners: The Relational Model for Practitioners + SQL and Relational Theory: How to Write Accurate SQL Code
Price For All Three: £74.96

Buy the selected items together


Trade In this Item for up to £3.52
Trade in Database Design and Relational Theory: Normal Forms and All That Jazz (Theory in Practice) for an Amazon Gift Card of up to £3.52, which you can then spend on millions of items across the site. Trade-in values may vary (terms apply). Learn more

Product details

  • Paperback: 278 pages
  • Publisher: O'Reilly Media; 1 edition (27 April 2012)
  • Language: English
  • ISBN-10: 1449328016
  • ISBN-13: 978-1449328016
  • Product Dimensions: 17.8 x 1.8 x 23.3 cm
  • Average Customer Review: 5.0 out of 5 stars  See all reviews (1 customer review)
  • Amazon Bestsellers Rank: 680,498 in Books (See Top 100 in Books)
  • See Complete Table of Contents

More About the Author

Discover books, learn about writers, and more.

Product Description

About the Author

C.J. Date has a stature that is unique within the database industry. C.J. is a prolific writer, and is well-known for his best-selling textbook: An Introduction to Database Systems (Addison Wesley). C.J. is an exceptionally clear-thinking writer who can lay out principles and theory in a way easily understood by his audience.


Customer Reviews

5.0 out of 5 stars
5 star
1
4 star
0
3 star
0
2 star
0
1 star
0
See the customer review
Share your thoughts with other customers

Most Helpful Customer Reviews

By Bret McGee on 2 April 2015
Format: Paperback Verified Purchase
Love this book. Chris Date does come accross as stern and old fashioned, but watch one of his videos to see his personailty and it helps you read his text. Not for the faint hearted.
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again

Most Helpful Customer Reviews on Amazon.com (beta)

Amazon.com: 11 reviews
32 of 33 people found the following review helpful
Nobody teaches normalization any more! 3 Nov. 2012
By Amazon Customer - Published on Amazon.com
Format: Paperback Verified Purchase
You ought to know who Chris Date is. Return with me now to those thrilling days of yesteryear (the late 1970's, early 1980's) when RDBMS has just been created by Dr. E. F. Codd. The problem was that Dr. Codd was a mathematician whose earlier work was with self-reproducing cellular automata. He wrote and thought like a mathematician, not a programmer. His notation was abstract and mathematical. He used standard set operators for Union, Intersect, Set Difference, membership and so forth. Projections (SELECT in SQL) was shown with a letter pi (ð) with subscript parameters, the selection (FROM in SQL) was shown with a letter sigma (ó) with subscript parameters and he invented the butterfly or bow ties for joins. In short, nobody could read it unless they were a math major. We did a lot of work with this notation and if you like curling up with a glass of sherry and a warm calculus book, the best mathematical book on RDBMS is still Theory of Relational Databases by David Maier (Mar 1983, ISBN: 978-0914894421).

But the real problem was not that the early papers were academic. When the first SQL products came out, RDBMS was like pre-teen sex. Everyone claimed that they knew what it was and that they were good at it. Yeah. Right. Chris Date and Dr. Codd formed a consultancy to educate the world. Dr. Codd was the brains and the big name; Chris Date was the "Great Explainer" who wrote magazine articles and gave lectures. People could understand Chris Date! His INTRODUCTION TO DATABASES was a standard college textbook in the early days of RDBMS. His collections of columns in DBMS and DATABASE PROGRAMMING & DESIGN should be part of any RDBMS library.

Date has since written a lot of books on databases for many different publishers. But even today, his sample database of Suppliers who provide Parts for Jobs is referred to by the name "SPJ" in the literature. Chris Date does not like SQL and writes his books in a language called Tutorial D. This language is directly based on Relational Algebra and Relational Calculus. You can find more about it at [...]. But you do not need to know this language to read the book; the code used is obvious and can quickly map into SQL when an equivalent SQL code is not given.

If you think you know enough about Normal Forms and all that jazz, then you are wrong. I was. Date is back to being "The Great Explainer" again. He has a running examples thru the whole book that use simple, small data base schemas. He does not assume you are a math major, but just a working programmer who needs to be grounded in real work to get to the theory.

The chapters come in pairs; the first is an informal look at the topic, the second is more formal explanation. For example: Chapter 4 is "FDS and BCNF (Informal)" then Chapter 5 is "FDs and BCNF (Formal)" and that pattern continues in the rest of the book. When you get bogged down in the formal stuff, go back to the previous section. Each chapter ends with exercises; do not worry, there are answers in the back of the book. Chris has written too many textbooks, and a lot of his exercises are really discussion questions.

Keys are discussed in detail and he demolishes the surrogate key concept. Then he spends all of chapter 8 debunking the myths of denormalization. Yes, people still do it after all this time.

Do you know the two purposes Normalization serves? I think of it as a method (not the only one) to reduce redundancy in a schema. But it can also correct a bad design. These are two distinct problems, but people get them confused. I am now thinking of which normal form I need from the hierarchy before I design a schema instead of a clean up after the first design.

Seeing the current Normal Form Hierarchy made me feel like I had not kept up with my reading. The few SQL programmers that even know what a Normal Form is at all, think that it is "First Normal Form (1NF) is flat files", they have no idea about Second Normal Form (2NF), think that "Third Normal Form (3NF) is when I declare some column as PRIMARY KEY, and I am done" and they have no idea about other normal forms at all.

Date gives a list of the following nine Normal Forms. Then he shows how something can be in one Normal Form and is by implication in all the lesser Normal Forms, but not in any of the higher Normal Forms.

1NF = First Normal Form
2NF = Second Normal Form
3NF = Third Normal Form
BCNF = Boyce-Codd Normal Form
4NF = Fourth Normal Form
RFNF = Redundancy Free Normal Form
SKNF = Superkey Normal Form
5NF = Fifth Normal Form
6NF = Sixth Normal Form

But this is not all of them! We also have Elementary Key Normal Form (EKNF), Complete Key Normal Form (CKNF) and Domain Key Normal form (DKNF) as well.

You get a simple introduction to Functional Dependencies (FD) and Multi-Valued Dependencies (MVD) and the algebra that goes with them. This how we can safely get rid of redundant tables in a schema and know with mathematical certainty we have not lost data.

There are also a lot of discussion of practical considerations. Let me throw out one example for your to play with, re-written in SQL:

CREATE TABLE Payments
(cust_nbr INTEGER NOT NULL
REFERENCES Customer_Accounts (cust_nbr),
payment_date DATE NOT NULL,
PRIMARY KEY (cust_nbr, payment_date),
payment_amt DECIMAL (10,2) NOT NULL
CHECK (payment_amt > 0.00))

CREATE TABLE Customer_Accounts
(cust_nbr INTEGER NOT NULL PRIMARY KEY,
payment_amt_tot DECIMAL (10,2) NOT NULL
CHECK (payment_amt_tot > 0.00));

The business rule is that account balance agrees with the sum of the payments:

CREATE ASSERTION Correct_Balances
CHECK
(NOT EXISTS
(SELECT *
FROM (SELECT A.cust_nbr, A.payment_amt_tot,
SUM(P.payment_amt)
OVER (PARTITION BY P.cust_nbr) AS P_amt_tot
FROM Customer_Accounts AS A, Payments AS P
WHERE P.cust_nbr = A.cust_nbr)
WHERE P_amt_tot <> A.payment_amt_tot));

The Customer_Accounts table is clearly redundant, since it is all derived data. There are four possible ways to handle this.
1) Ignore the problem and do not write the constraint. You see this "solution" all too often. And then someone tries to fix it in the application layers of the system.
2) Declare the constraint. This happens to be harder in T-SQL because we do not have a CREATE ASSERTION statement. You might try using Triggers, but what happens when someone monkeys with the Customer_Accounts directly without waiting for a trigger to fire in the Payments table?
3) Create a VIEW. But the user has to know that he cannot touch the Customer_Accounts
4) Create a snapshot. Now the user can touch the Customer_Accounts, but that this is dangerous for data integrity.

So, how would you fix it? And why?
30 of 34 people found the following review helpful
I couldn't read it. 7 Sept. 2012
By Alexei Lebedev - Published on Amazon.com
Format: Paperback Verified Purchase
Mr. Date has a wandering style of presentation that I find impossible to follow. Most statements either state that an earlier definition was not strictly speaking, correct, or a promise to say more on the subject in another chapter. Every sentence has parenthetical asides or begins with decorations such as "Note, carefully, however"; "Now, we might say, very loosely, that..."; "However there is a significant difference also."; "In order to understand this state of affairs a little better, it's helpful to go back to..."; "As an aside, I note that the foregoing discussion goes a long way toward..." etc. etc. etc. Every definition is "preliminary",

Some examples:

Exercise 2.1 is "What's the Information Principle?" -- a seemingly important question. The information principle is not discussed in chapter 2 at all. The answer in given in Appendix D: "The Information Principle is a fundamental principle that underpins the entire relational model." Shouldn't perhaps Chapter 1 begin with this definition?

Here is a paragraph from Chapter 3 whose only purpose seems to be to reference a concept from Chapter 1 and delegate it to Chapter 15:

"In chapter 1, I said design theory is largely about reducing redundancy, and I've referred to the concept repeatedly in the present chapter; in particular, I've said the higher the level of normalization, the more redundancy is prevented. But coming up with a precise definition of redundancy seems to be quite difficult -- much more so, in fact, than I think is appropriate for this early point in the book. For that reason, I'm not even going to try to define it here; I'm just going to assume until further notice that we can at least recognize it when we see it (though even that's a pretty big assumption, actually). Chapter 15 examines the concept in depth".

I learned more from Codd 1970 paper and wikipedia article on normal forms.
11 of 11 people found the following review helpful
Database Design and Relational Theory: Normal Forms and All That Jazz 3 July 2012
By J. W. Rine - Published on Amazon.com
Format: Paperback
C. J. Date is an independent author, lecturer, researcher, and consultant specializing in relational database theory. My introduction to his work came while I studied the Php/SQL course series online via the O'Reilly School of Technology. I received a copy of Database in Depth: Relational Theory for Practitioners, ISBN 0-596-10012-4, to accompany the online coursework. A couple of chapters into Database Design and Relational Theory I stopped and read again the aforementioned Database In Depth as a refresher.

Database Design and Relational Theory: Normal Forms and All That Jazz is about the logical design of a database as it relates to the relational data model. It's about the theory of the relational model and the accompanying algebra. These concepts are separated from physical design as physical design relates to how a particular logical design will map to actual physical storage.

The book is written for an audience accustomed to the terminology and concepts of the relational model. Definitions are introduced moving from the informal to the formal. Throughout the book the discussion involves relations, relvars, tuples, functional dependencies, join dependencies and various algebraic operators. If all this seems foreign, then I would suggest another text to be read as prerequisite to this book. Admittedly, I do not have a background in computer science or mathematics. I found the material difficult at times but not overly so. I think that after reading this book I have a much better grasp on normalization when it comes to creating my own database.

I would recommend this book to those readers with a desire to learn about relational design theory. It is product agnostic with mentions of SQL limited to instances where SQL breaks from the relational model. It is an advanced text and requires thought and concentration commensurate to the fields of computer science and mathematics.

Disclosure: I recieved a free ebook copy for review purposes.
8 of 8 people found the following review helpful
Excellent book - difficult typesetting 21 Jun. 2012
By B Miller - Published on Amazon.com
Format: Paperback Verified Purchase
I recommend this work to anyone who is required to architect database solutions, especially complex ones. This book deals with rather dry topics in a clear and helpful manner. Other than vendor specific database references, this book and SQL Antipatterns (Karwin) are the two most referenced database books on my shelf.

The only caveat is the book is typeset in a fairly small font which may prove tiring over long reading session. If small fonts are an issue I highly recommend the electronic edition.
7 of 9 people found the following review helpful
A good intro but too pedantic about relvars vs. relations 28 Sept. 2012
By Eric B. - Published on Amazon.com
Format: Paperback Verified Purchase
This book is a good introduction to relational theory. I found it helpful, along with Wikipedia and other online reference material, in learning the normal forms and what they really mean. It is highly theoretical, which I can relate to, holding a bachelor's degree in mathematics. The author develops the material at a good pace, until he arrives at a point where he has developed enough rigor to be able to develop the concepts more rigorously.

However, he emphasizes the distinction between relations and relvars (relation variables) to a fault. Though that distinction is important when actually programming or when using proper jargon, it is not as important as emphasized throughout the book when developing the relational algebra and theory. For instance, mathematicians have gone hundreds of years saying, "let x be an integer," rather than, "let x be an integer variable," when writing theorems regarding an unknown integer. In fact, the set membership symbol is exactly the same regardless of saying "x in Z" or "3 in Z" (where I use "in" for the set membership symbol and Z for the set of all integers).

The pedantic treatment of relations vs. relvars wasn't enough to make me toss the book, but I feel like I could have understood it just as well without such an obsessive treatment of it. Not to mention that I could have paid more attention to the definitions of the more important concepts of relational theory in the book.
Were these reviews helpful? Let us know


Feedback