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!”

I am concerned, however, that database development skills—database design, normalization, and T-SQL—seem to be a dying art. In many shops, the lone data architect is outnumbered 50 to 1 by developers who don’t respect the importance of data integrity. Managers listen to the crowd, and systems are designed for today rather than for next year, much less the next decade. The design methods and development tools used to encapsulate data should be at least as stable and live as long as the data. And data lasts a long, long time. Ask around, and see how many DBAs manage data that’s 10, 20, or 50 years old. Most do.

The average lifecycle of a popular application development language is 3 to 5 years; a stored procedure written 20 years ago still runs (with maybe a slight tweak to the JOIN syntax). I picture the database as a granite rock that will last for an eon. Occasionally a UI developer comes along and paints a pretty chalk picture on the rock; it washes off and a few more UI developers add their pictures. They all wash off with time, but the rock remains. OK, it’s a stretch, and I do like a great UI, but the point is that any IT architecture should be founded on data integrity.

This part of the book has three chapters focused on improving your skills in gathering data requirements and designing the database.

About the editor

Paul Nielsen is a SQL Server data architect who has enjoyed playing with data for three decades. He’s the author of the SQL Server Bible series (Wiley), is convinced that SSMS is the ultimate UI, and dreams in E/R diagrams and T-SQL. Paul is the founder of NordicDB—a software startup company that offers a specialized SaaS CRM solution for non-profits. Paul lives in Colorado Springs with a wife who is far more beautiful than he deserves and his three children (ages 22, 21, and 5). He speaks at most conferences and offers seminars in database design. His website is http://www.SQLServerBible.com.