Part 1. Database design and architecture

Edited by Paul Nielsen

Any database can be evaluated on six basic criteria: usability, data integrity, scalability, extensibility, availability, and security. Of these database objectives, the first four are primarily driven by the design and development of the database. One of the best practices that serves as a root cause for each of the four design-driven goals is the elegance of the database design itself.

The trouble is that elegance of design can be an elusive creature—difficult to define, difficult to achieve, and difficult to teach. But we do know that at the core of every well-designed database are the principles of normalization. In the application development world, technologies are annual trends, but not so in the database world. Even after nearly 40 years, normalization—one grouping of things is one entity, one thing is one tuple, one fact is one attribute, and every attribute must describe the tuple—is still the foundation of database technology. In the quest for elegance of design, the concepts of generalization and data-driven design augment, but don’t negate, normalization. The war cry of the data architect is still, “The key, the whole key, and nothing but the key!”