Database Reference
In-Depth Information
Single-Valued and Multivalued Attributes
All the attributes we've talked about thus far represent
single-valued at-
tributes.
That is, for each unique occurrence of an item in an entity, there
is only one value for each of the attributes. However, some attributes nat-
urally have more than one potential value—for example, of the entity.
These are known as
multivalued attributes.
Identifying them can be
tricky, but handling them is fairly simple.
One common example of a potentially multivalued attribute is Phone
Number. For example, when you're storing customer information, it's typ-
ical to store at least one phone number; however, customers often have
multiple phone numbers. Generally, you simply add multiple phone num-
ber fields to the Customer entity, labeling them based either on arbitrary
numbering (Phone1, Phone2, etc.), or on common usage (Home, Mobile,
Office). This is a fine solution, but what do you do if you need to store mul-
tiple office numbers for a single customer? This is a multivalued attribute:
for one customer, you have multiple values for exactly the same attribute.
You don't want to store multiple records for a single customer merely
to account for a different phone number; that defeats the purpose of using
a relational database, because it introduces problems with data retrieval.
Instead, you can create a new entity that holds phone numbers, with a
relationship to the Customer entity (based on the primary key of the
Customer), that allows you to identify all phone numbers for a single cus-
tomer. The resultant entity might have multiple entries for each customer,
but it stores only a unique identifier—CustomerID—and of course the
phone number.
Using this kind of entity is the only way to resolve a true multivalued at-
tribute problem. In the end, the physical implementation will benefit from
this model, because it can take advantage of DBMS-specific search tech-
niques to search the dependent entity separately from the primary entity.
One core aspect of a relational database is that data in one entity can ref-
erence data in another entity. When this scenario occurs, there is almost al-
ways a requirement that the relationship be maintained; the data must be
consistent between the relevant entities. This concept, referred to as
ref-
erential integrity
(RI), is usually enforced in the physical implementa-
Search WWH ::
Custom Search