- Tapa blanda: 278 páginas
- Editor: O'Reilly Media; Edición: 1 (27 de abril de 2012)
- Idioma: Inglés
- ISBN-10: 1449328016
- ISBN-13: 978-1449328016
- Valoración media de los clientes: 1 opinión de cliente
- Clasificación en los más vendidos de Amazon: nº366.124 en Libros en idiomas extranjeros (Ver el Top 100 en Libros en idiomas extranjeros)
- Ver el Índice completo
Compara Precios en Amazon
+ Envío GRATIS
Database Design and Relational Theory: Normal Forms and All That Jazz (Inglés) Tapa blanda – 27 abr 2012
|Nuevo desde||Usado desde|
Los clientes que compraron este producto también compraron
Descripción del producto
Reseña del editor
What makes this book different from others on database design? Many resources on design practice do little to explain the underlying theory, and books on design theory are aimed primarily at theoreticians. In this book, renowned expert Chris Date bridges the gap by introducing design theory in ways practitioners can understand—drawing on lessons learned over four decades of experience to demonstrate why proper database design is so critical in the first place.
Every chapter includes a set of exercises that show how to apply the theoretical ideas in practice, provide additional information, or ask you to prove some simple theoretical result. If you’re a database professional familiar with the relational model, and have more than a passing interest in database design, this book is for you.
Questions this book answers include:
- Why is Heath’s Theorem so important?
- What is The Principle of Orthogonal Design?
- What makes some JDs reducible and others irreducible?
- Why does dependency preservation matter?
- Should data redundancy always be avoided? Can it be?
Databases often stay in production for decades, and careful design is critical for avoiding subtle errors and processing problems over time. If they’re badly designed, the negative impacts can be incredibly widespread. This gentle introduction shows you how to use important theoretical results to create good database designs.
Biografía del autor
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.
No es necesario ningún dispositivo Kindle. Descárgate una de las apps de Kindle gratuitas para comenzar a leer libros Kindle en tu smartphone, tablet u ordenador.
Obtén la app gratuita:
Detalles del producto
Si eres el vendedor de este producto, ¿te gustaría sugerir ciertos cambios a través del servicio de atención al vendedor?
Opiniones de clientes
Principales opiniones de clientes
Ha surgido un problema al filtrar las opiniones justo en este momento. Vuelva a intentarlo en otro momento.
Especialmente recomendable para los estudiantes universitarios y de Formación Profesional.
Opiniones de clientes más útiles en Amazon.com
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
FROM (SELECT A.cust_nbr, A.payment_amt_tot,
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?
But not exactly. This book focuses on database design under a quasi-mathematical model (borrowing from discrete mathematics) and provides valuable insight into database design without being limited by any database system. If you're trying to get into the database industry with your own fancy pants database model, then this would be a good read.
Otherwise, this book isn't very helpful. It teaches you how to develop the logical design, but it stops there. You have to figure out how to derive the physical design, i.e. implement the design on an existing database management system. And thats what really counts if you're out there doing this for a living.
I guess it would be great for students in academia, but no student can afford a book this expensive. : /
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.
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.