Database Reference
In-Depth Information
CHAPTER 7
Everything you've read until now has been laying the foundation for build-
ing a data model. In this chapter, we finally start to use the concepts intro-
duced in the first six chapters. We begin by taking a look at the modeling
semantics, or notation standards, and discussing the features you'll need in
a modeling tool. Then we work through the process of turning require-
ments into organized pieces of data, such as entity lists. Finally, after we
have created all the objects that our model needs, we build the model, de-
riving its form and content from all the pieces of information we've gath-
ered. So let's dig in.
Obviously, most of the concepts we've covered are just that—conceptual-
ized information about what a data model is and what it contains. Now we
need to put into practice some guidelines and standards about how the
model is built. We need to put names to entities, outline what those enti-
ties look like on paper (well, not necessarily paper, but you know what we
mean), determine how to name all the objects relating to those entities,
and finally, decide which tool we'll use to create the model.
Suggested Naming Guidelines
If you've spent any time developing software, in any system, you've come
to understand that consistent naming standards throughout a system are a
must. How much time does a developer waste fixing broken code because
of a case-sensitive reference that uses a lowercase letter instead of an up-
percase letter? In database systems, how much time do developers waste
searching through the list of objects in a database manually because the
objects aren't named according to type? Although the names you use in
your logical model don't affect physical development, it's just as important
149
Search WWH ::
Custom Search