Database Reference
In-Depth Information
CHAPTER 2
Imagine, for a moment, that you've been asked to build a house. One of
the first questions you'd ask yourself is, “Do I have all the tools and mate-
rials I need?” To answer this question, you need a plan for building the
house. The plan, a construction blueprint, will provide the information on
the required tools and materials. So step 1 is to design a blueprint. If
you've never done this before, you'll probably need to do some research to
make sure you understand the overall process of designing the blueprint.
Like a blueprint, the logical database model you build will be the
source for all the development of the physical database. Additionally, the
logical model provides the high-level view of the database that can be pre-
sented to the key project stakeholders. For these reasons, the logical model
is generally devoid of RDBMS specifics; instead it contains the key infor-
mation that defines how the model, and eventually the database, will meet
business requirements. But before you can begin to construct a logical
model, it's important to understand all the tools that you will need.
In this chapter, we cover the objects and concepts related to the cre-
ation of a logical data model; you'll use these objects in Chapter 7 to start
building the data model for Mountain View Music. For now, let's talk about
entities and attributes and see how relationships are built between them.
Entities represent logical groupings of data and are the central concept
that defines how data will be stored in the database. Common examples of
entities are customers, orders, and products. Each entity, which should
represent a single type of information, contains a collection of occurrences,
or instances, of the entity. An
instance
of an entity is very similar to a
23
Search WWH ::
Custom Search