Data Modeling

Summary

In this chapter I presented the basic process of graphically documenting the objects that were introduced in the first chapter. I focused heavily on the IDEF1X modeling methodology, taking a detailed look at the symbology that will be used through database designs. The base set of symbols outlined here will enable us to fully model logical databases (and later physical databases) in great detail.

The primary tool of a database designer is the data model. It’s such a great tool because it can show the details not only of single tables at a time, but the relationships between several entities at a time. Of course it is not the only way to document a database; each of the following is useful, but not nearly as useful as a full-featured data model:

• Often a product that features a database as the central focus will include a document that lists all tables, datatypes, and relationships.

• Every good DBA has a script of the database saved somewhere for re-creating the database.

• SQL Server’s metadata includes ways to add properties to the database to describe the objects.

I also briefly outlined the other types of model methodologies, such as Information Engineering, Chen ERD, and Microsoft Management Studio.

Now that we’ve considered the symbology required to model the database, I’ll use data models throughout the book to describe the entities in the conceptual model (Chapter 3), the logical model (Chapter 4), and throughout the implementation presented in the rest of the book.