Databases Reference
In-Depth Information
An attribute may be formed from smaller parts; for example, a postal address is com-
posed of a street number, city, ZIP code, and country. We classify attributes as
com-
posite
if they're composed of smaller parts in this way, and as
simple
otherwise.
Some attributes can have multiple values for a given entity. For example, a customer
could provide several telephone numbers, so the telephone number attribute is
multivalued
.
Attributes help distinguish one entity from other entities of the same type. We could
use the name attribute to distinguish between customers, but this could be an inade-
quate solution because several customers could have identical names. To be able to tell
them apart, we need an attribute (or a minimal combination of attributes) guaranteed
to be unique to each individual customer. The identifying attribute or attributes form
a
key
.
In our example, we can assume that no two customers have the same email address,
so the email address can be the key. However, we need to think carefully about the
implications of our choices. For example, if we decide to identify customers by their
email address, it would be hard to allow a customer to have multiple email addresses.
Any applications we build to use this database might treat each email address as a
separate person, and it might be hard to adapt everything to allow people to have
multiple email addresses. Using the email address as the key also means that every
customer must have an email address; otherwise, we wouldn't be able to distinguish
between customers who don't have one.
Looking at the other attributes for one that can serve as an alternative key, we see that
while it's possible that two customers would have the same telephone number (and so
we cannot use the telephone number as a key), it's likely that people who have the same
telephone number never have the same name, so we can use the combination of the
telephone number and the name as a composite key.
Clearly, there may be several possible keys that could be used to identify an entity; we
choose one of the alternative, or
candidate
, keys to be our main, or
primary
, key. You
usually make this choice based on how confident you are that the attribute will be non-
empty and unique for each individual entity, and on how small the key is (shorter keys
are faster to maintain and use).
In the ER diagram, attributes are represented as labeled ovals and are connected to their
owning entity, as shown in Figure 4-2. Attributes comprising the primary key are shown
underlined. The parts of any composite attributes are drawn connected to the oval of
the composite attribute, and multivalued attributes are shown as double-lined ovals.
Attribute values are chosen from a
domain
of legal values; for example, we could specify
that a customer's given names and surname attributes can each be a string of up to 100
characters, while a telephone number can be a string of up to 40 characters. Similarly,
a product price could be a positive rational number.
