CREATING THE LOGICAL MODEL - A Developer's Guide to Data Modeling for SQL Server - page 150

to have a consistent naming convention. When you name your entity that
contains employee information, do you name it Employee or Employees?
What about sales info—Sale or Sales? Keeping a consistent naming con-
vention can help avoid confusion as well as ensure readability for future
design reviews.
We address physical naming conventions in Chapter 9, but at this point
you should understand that it is important to designate your naming con-
vention for the data model now, and ensure that it is not a mapping of the
physical naming convention. Because the physical implementation of a
data model usually requires that you create objects that don't exist in the
data model, naming your tables exactly the same as your entities may cre-
ate confusion, because there will be tables that don't map to entities.
Remember that the data model is the logical expression of the data that
will be stored.
The emphasis here is that you have a standard—any standard, as long
as it is consistent. Here, we offer the set of guidelines that we used to de-
velop the data model for Mountain View Music. Figure 7.1 shows each
type of object in the data model. We'll talk about each object, how it's
named, and why.

F IGURE 7.1

The Products entity from the Mountain View Music data model