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

You can see that the attributes are ordered in what we might consider
a common order: name, phone, address, and status. We could easily order
these in any way, but this order is closer to what most people think of as in-
formation about a person. It's certainly not set in stone, nor is there a hard-
and-fast rule about attribute ordering. Just remember that you'll be
explaining this model to nontechnical personnel, and they'll be looking at
these attributes as simply labels of information. Ordering them can make
it easier to explain and easier for users to review on their own if necessary.
In any case, most modeling software allows you to rearrange the order of
attributes after they have been added, so you should be able to rearrange
these if the need arises.
As you add attributes, be sure to constantly review your domain list to
make sure you haven't either (1) missed a domain that should have been
created or (2) missed using a domain in an entity. This is sometimes an it-
erative process, and you are likely to make changes here (as well as in the
rest of the model) when you review the model with the business stake-
holders.
We have completed our first version of the MVM data model. If all the
previous steps have been done correctly, then building the model is the
easiest step, because all we're doing is creating a logical, visual representa-
tion of the information obtained and analyzed during requirements gath-
ering.
Summary
In this chapter, we've finally built our model by using techniques described
throughout the rest of the topic. We've addressed specific issues regarding
entity lists, attribute lists, and the hows and whys of relationship modeling
in logical models. Next, in Chapter 8, we look at the various generic pitfalls
that most modelers run into and explore ways to avoid them.