Database Reference
In-Depth Information
ponents. Especially observe how the attribute Street may be broken down further
into simple attributes.
Attributes with Stored and Derived Values
In later phases of database devel-
opment, you will transform the data model into the physical structure of how data
gets stored in the database. From our discussion of attributes, you must have real-
ized that the physical data stored in the database consist of values of the attributes
of the complete set of all the entities. Stored data are really values of the attributes.
If you have a CUSTOMER entity type with CustomerName, CustomerAddress, and
Phone as the attributes, then your database stores the values of these attributes for
all the customer entities in your organization. These are attributes whose values are
stored in the database.
Sometimes you would want to calculate and derive values from the values of one
or more attributes and to store the derived values in separate attributes. These are
attributes containing derived values. Look at the following examples.
Attributes with derived values
Entity type:
EMPLOYEE
Derived attribute:
LengthOfEmployee
Attribute derived from:
EmployeeStartDate (and today's date)
Entity type:
PRODUCT
Derived attribute:
ProfitMargin
Attributes derived from:
UnitPrice and UnitCost
Figure 7-10 illustrates how a derived attribute is represented in an E-R data model.
Candidate and Primary Keys
In the discussion of object sets and object instances of object-based data model, we
studied how certain attributes of an object set may be used to uniquely identify the
instances. These were called identifiers. In the same manner, entity-relationship
model has provisions to represent key attributes. All the points discussed on keys
in Chapter 6 apply to the E-R model as well. You also know that underlining the
Derived
PRODUCT
ProdID
ProfitMargin
Unitcost
ProdDesc
UnitPrice
Figure 7-10
Derived attribute.
Search WWH ::
Custom Search