21-12-2012, 05:31 PM
ENTITY-RELATIONSHIP MODEL
ENTITY-RELATIONSHIP MODEL.pdf (Size: 1.92 MB / Downloads: 377)
Beyond the ER Model
ER modeling is sometimes regarded as a complete approach to designing a logical
database schema. This is incorrect because the ER diagram is just an approximate
description of the data, constructed through a very subjective evaluation of the infor-
mation collected during requirements analysis. A more careful analysis can often refine
the logical schema obtained at the end of Step 3. Once we have a good logical schema,
we must consider performance criteria and design the physical schema. Finally, we
must address security issues and ensure that users are able to access the data they
need, but not data that we wish to hide from them. The remaining three steps of
database design are briefly described below:
ENTITIES, ATTRIBUTES, AND ENTITY SETS
An entity is an object in the real world that is distinguishable from other objects.
Examples include the following: the Green Dragonzord toy, the toy department, the
manager of the toy department, the home address of the manager of the toy depart-
The Entity-Relationship Model 27
ment. It is often useful to identify a collection of similar entities. Such a collection is
called an entity set. Note that entity sets need not be disjoint; the collection of toy
department employees and the collection of appliance department employees may both
contain employee John Doe (who happens to work in both departments). We could
also define an entity set called Employees that contains both the toy and appliance
department employee sets.
An entity is described using a set of attributes. All entities in a given entity set have
the same attributes; this is essentially what we mean by similar. (This statement is
an oversimplification, as we will see when we discuss inheritance hierarchies in Section
2.4.4, but it suffices for now and highlights the main idea.) Our choice of attributes
reflects the level of detail at which we wish to represent information about entities.
For example, the Employees entity set could use name, social security number (ssn),
and parking lot (lot) as attributes. In this case we will store the name, social secu-
rity number, and lot number for each employee. However, we will not store, say, an
employee’s address (or gender or age).
ADDITIONAL FEATURES OF THE ER MODEL
We now look at some of the constructs in the ER model that allow us to describe some
subtle properties of the data. The expressiveness of the ER model is a big reason for
its widespread use.
Key Constraints
Consider the Works In relationship shown in Figure 2.2. An employee can work in
several departments, and a department can have several employees, as illustrated in
the Works In instance shown in Figure 2.3. Employee 231-31-5368 has worked in
Department 51 since 3/3/93 and in Department 56 since 2/2/92. Department 51 has
two employees.
Key Constraints for Ternary Relationships
We can extend this convention—and the underlying key constraint concept—to rela-
tionship sets involving three or more entity sets: If an entity set E has a key constraint
in a relationship set R, each entity in an instance of E appears in at most one rela-
tionship in (a corresponding instance of) R. To indicate a key constraint on entity set
E in relationship set R, we draw an arrow from E to R.