Databases Reference
In-Depth Information
the information that you need to track about each of the entities. Together, these
give you your basic working set of data.
In the real world, entities never really stand alone; they are typically associ-
ated with each other, or intersect in some fashion. Parents are associated with
their children, automobile parts are associated with the finished automobile, fire-
fighters are associated with the fire engines to which they are assigned, and so
forth. Customers and the items they buy intersect at the point of sale. Recog-
nizing and recording the associations and intersections among entities provides
a far richer description of an environment than recording the entities alone. In
order to intelligently and usefully deal with the associations or relationships
between entities, you must be able to identify and describe both the entities and
the relationships.
3.2.1 Entity-Relationship (E-R) Modeling Concepts
Let's start by making sure that we all have the same idea in mind when dis-
cussing database concepts. We're focusing on
entity-relationship (E-R) modeling.
This is a model commonly used for designing relational databases and is based
on business entities and the relationships between them.
As you've already learned, each “thing” that you want to track in the data-
base is an entity. Many entities are physical objects such as people or product
inventory. Some are less tangible, such as loan balances or interest rates. Your
data modeling process begins with digging through the data you've accumulated
and identifying the entities.
While you are doing this, you will also identify attributes, the information that
describes the entity. Each entity type will have its own attributes. The data collected
for employees, for example, will be somewhat different than the data collected for
customers, and very different than the data collected for inventory items.
Entities
Your best starting points are physical entities, the things you can see and touch,
and related business processes. That's because these are the entities that are usu-
ally the easiest to recognize and understand. For some of your most obvious
physical entities, all you have to do is look around.
Let's take another look at the retailer example we've been using during this
chapter. Assume you need to develop a data model for a department store. What
are some of the entities that immediately come to mind? Physical entities for a
department store database might include product inventory, vendors, customers,
and employees. Now, let's focus more closely on one of these entities—employees.
Each hourly employee must have a time card or other way of tracking time
worked. That's another entity. Pay rates, as a group, might also be considered as
an entity and kept in a separate table. You might want to track vacation time
accrued and used as another separate entity.
