Considering the generally very poor database implementations (it's a stretch to even say most implementations rise to the level of a "design" as they seem to be about 90% ad hoc) I encounter in the field every day, I guess I should not be surprised that in all the books listed by responders to this question, I do not see even one that concentrates on the fundamental concepts and theory provided to us by Dr. Codd for designing reliable and flexible solutions for databases.
Instead we see a plethora of "how-tos" for specific functional tasks for specific manufacturer's (ever-changing I might add) products and syntax.
To about 95% of the database practitioners I encounter in the field, databases seem to be thought of as spreadsheets that use SQL. There are many reasons for this serious deficiency in our industry-RDBMS manufacturer vested interests, deficiencies in academic CS and IS programs, customer short-sitedness, I could go on.
The books I value the most about database work are the ones that have helped me to understand and follow the fundamental logical rules for RDBMS design that Dr. Codd first synthesized. These rules are like the basic mathematical theorems of brick and mortor construction engineering, but for database work, not building bridges. Sure you can build a bridge, or a building, or a database without knowing, understanding , or following the theorems, but what you build will always be unsafe, and never stand the test of time. Not to mention the myriad practical daily problems and failures that users of your artifact will experience as they try to live with what was built.
There are a few authors who have spent a good part of their careers as writers trying to raise the level of understanding of RDBMS theory and practice in our industry. See any of the works of Fabian Pascal as some of the most readable, useful, and practical, IMHO.
Ken Ambrose
The essential characteristic of an outstanding solution is simplicity. If everyone who sees it doesn't slap their heads and say "of course- that's obvious and simple!" then it is too complicated.