144 Chapter 10 / Archetypes
Bibliographic Notes
In some regards, this chapter is similar in style to other data pattern books and their emphasis
on seed models. The difference is that this chapter emphasizes the core concepts rather than
the details that applications add. My purpose is to call attention to concepts that often occur
and can be overlooked.
The term archetype is taken from [Arlow-2004]. I had used critical concept in an earlier
draft, but there is no point to creating a new term when the literature already has a suitable term.
The actor model is consistent with the literature but is more robust. [Arlow-2004], [Hay-
1996], and [Silverston-2001a] define a party as a person or an organization. [Fowler-1997]
defines a party as a person, organization, or role type (Fowler’s term is post). The model in
this book broadens the notion to include roles and applications. The term actor is also con-
sistent with UML terminology.
Table 10.1 Summary of Archetypes (continued)
Archetype Definition Sample applications Related terms
Location
a physical place in
space
• place
•site
• venue
Opportunity
an inquiry that can
result in business
• marketing
• sales
• campaign
• lead
Part
a specific good that
can be described

• manufacturing
•engineering
• item
• product
Payment
the assignment of
money in return for
something of value
• business
• financial
Position
a job held by someone
in an organization
• human resources • employee
• employer
•job
• assignment
Product
the packaging of a
physical item for a
particular marketplace
• banking
• mechanical parts
• service companies
• item
•part
• service
Role
a function played by
someone or something

Transaction
an exchange that must
be completed in its
entirety or not at all
• computing
• financial
Ven do r
someone involved in
the sale of products
•seller
• supplier
Bibliographic Notes 145
Chapters 2 and 3 of [Silverston-2009] have an especially good discussion of party (com-
parable to actor in this book). The authors distinguish between a declarative role (a role that
a person or organization plays within an entire enterprise) and a contextual role (a role in a
specific relationship).
[Arlow-2004] discusses party roles, but their representation is flawed as there is no need
to distinguish between a client and supplier in a party relationship, given that they have a role
type. I suspect that the authors are thinking in terms of directed relationships, which is an
inferior approach. (See Section 8.7.4.)
[Blaha-1998] has a further discussion of catalog parts and physical parts.
The Wikipedia Web site was helpful for constructing some definitions. Table 10.2 shows
significant coverage by other books of the archetypes.
Archetype [Arlow-2004] [Fowler-1997] [Hay-1996] [Silverston]
Account p 97–132 p 118–121 p 260–277 [2001a]
Actor
p 119–155 p 18–33 p 23–28,
31–32
p 29–39 [2001a]
p 35–131 [2009]

Address
p 132–137 p 33–36 p 49–57 [2001a]
p 303–410 [2009]
Asset p 149–150
Contract p 303–389 p 176–180 p 95–116 p 105–158 [2001a]
Course
Customer p 190–191 p 33–34 [2001a]
Document p 205–234
Event
Flight
Item p 203–265 p 46–61 p 69–104 [2001a]
Location p 36–40 p 380–410 [2009]
Opportunity
Part p 203–265 p 46–61 p 100–104 [2001a]
Payment p 425–431 p 250–254 [2001a]
Position p 32–33 p 28–31 p 303–314 [2001a]
Product p 203–265 p 46–61 p 69–104 [2001a]
Role
p 160–179 p 106–108
p 242–243
p 33–47 [2001a]
p 35–131 [2009]
Transaction p 98–101 p 122–124 p 265–275 [2001a]
Vend or
Table 10.2 Coverage of This Chapter’s Archetypes in the Literature
146 Chapter 10 / Archetypes
References
[Arlow-2004] Jim Arlow and Ila Neustadt. Enterprise Patterns and MDA: Building Better Software
with Archetype Patterns and UML. Boston, Massachusetts: Addison-Wesley, 2004.
[Blaha-1998] Michael Blaha and William Premerlani. Object-Oriented Modeling and Design for Da-

tabase Applications. Upper Saddle River, New Jersey: Prentice-Hall, 1998.
[Fowler-1997] Martin Fowler. Analysis Patterns: Reusable Object Models. Boston, Massachusetts:
Addison-Wesley, 1997.
[Hay-1996] David C. Hay. Data Model Patterns: Conventions of Thought. New York, New York:
Dorsett House, 1996.
[Silverston-2001a] Len Silverston. The Data Model Resource Book, Volume 1. New York, New York:
Wiley, 2001.
[Silverston-2001b] Len Silverston. The Data Model Resource Book, Volume 2. New York, New York:
Wiley, 2001.
[Silverston-2009] Len Silverston and Paul Agnew. The Data Model Resource Book, Volume 3. New
York, New York: Wiley, 2009.
[Wikipedia] www.wikipedia.org
147
Part IV
Identity
Chapter 11 Identity 149
Identity is the property that distinguishes an entity from all others. Identity is a prominent
concern in databases because developers must be able to find and reference data. This chap-
ter focuses on conceptual aspects of identity and minimizes the discussion of implementa-
tion.
Identity is relevant to patterns, because identity deeply pervades models and thinking
about models. There are three purposes of data models: to define data structure, to constrain
data, and to provide a blueprint for accessing data. Identity is important for all three. Identi-
fying fields are prominent in the declaration of data structure. Identity is by its very nature a
constraint on uniqueness. And finally, unique fields and unique combinations of fields are
anchor points for starting navigation of a database to access data.
I debated whether or not to include a chapter on identity. I decided to include the chapter
because identity is such an important aspect of modeling. Identity pervades both conceptual
models (unique keys and traversals of models—this chapter) as well as design models (dif-
ferent approaches to defining primary keys—Chapter 16).

149
11
Identity
Identity is the property that distinguishes an entity from all others. In concept, an entity has
intrinsic identity apart from how the entity may happen to be implemented. Users must be
able to find data in a database or the database is compromised.
11.1 Intrinsic Identity
Intrinsic identity is the ability to find data with fields that have meaning. Starting from out-
side a database, a user specifies real-world fields to find one or more entities and then navi-
gates the database to find the desired data. Intrinsic identity has no bearing on how identity
is implemented. Rather intrinsic identity provides a way for logically finding entities when
searching a database.
11.1.1 Candidate Keys
Candidate keys provide one aspect of intrinsic identity. A candidate key is a combination of
one or more fields that uniquely identify the records in a table. The set of fields in a candidate
key must be minimal; no field can be discarded from the candidate key without destroying
uniqueness. No field in a candidate key can be null. When a candidate key is defined, the
DBMS guarantees that the combination of fields will be unique. I strongly encourage the use
of candidate keys. After all, the purpose of a database is not only to store data but also to
assure data’s quality. When you use a candidate key as the starting point for a search, you are
guaranteed to obtain no more than one entity.
The UML lacks a notation for candidate keys. This book uses the notation {unique} to
flag a unique field. In Figure 11.1 Airline has two candidate keys, each of which consists of
one field. Thus, for example, the name American Airlines and the code AA both denote the
same airline.