Database Reference
In-Depth Information
Figure 8.1. Are there any candidate keys in this table?
You probably identified E
MPLOYEE
ID, S
OCIAL
S
ECURITY
N
UMBER
, E
MP
L
AST
N
AME
,
E
MP
F
IRST
N
AME
and
E
MP
L
AST
N
AME
,E
MP
Z
IPCODE
,and E
MP
H
OME
P
HONE
as potential can-
didate keys. But you'll need to examine these fields more closely to determine which ones
aretrulyeligibletobecomecandidatekeys.Rememberthatyoumustautomatically disreg-
ard any field(s) failing to conform to even
one
of the Elements of a Candidate Key.
Upon close examination, you can draw the following conclusions.
•
E
MPLOYEE
ID is eligible.
This field conforms to every element of a candidate key.
•
S
OCIAL
S
ECURITY
N
UMBER
is ineligible because it could contain null values and will
most likely compromise the organization's privacy rules.
Contrary to what the
sample data shows, this field could contain a null value. For example, there are
many people working in the United States who do not have Social Security num-
bers because they are citizens of other countries.
Note
Despite its widespread use in many types of databases, I strongly recommend
that you refrain from using S
OCIAL
S
ECURITY
N
UMBER
as a candidate key (or as a
primary key, for that matter) in any of your database structures. In many instances,
it doesn't conform to the Elements of a Candidate Key.
The Philadelphia Region section of the Social Security Online web site provides
someveryinterestingfactsaboutSocialSecuritynumbersandidentifytheft,which
isyetanothergoodreasonwhyyoushouldavoidusingSSNsascandidate/primary
keys. You can access their site here:
www.ssa.gov/phila/ProtectingSSNs.htm
.
