The Data Model Resource Book, Volume 1.. The Data Model Resource Book, Volume 2.. The Data Model Resource Book, Volume 3... Identity is relevant to patterns, because identity deeply perv
Trang 1144 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)
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
Vendor someone involved in
the sale of products
• seller
• supplier
Trang 2Bibliographic 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]
31–32
p 29–39 [2001a]
p 35–131 [2009]
p 303–410 [2009]
Course
Event
Flight
Opportunity
p 242–243
p 33–47 [2001a]
p 35–131 [2009]
Vendor
Table 10.2 Coverage of This Chapter’s Archetypes in the Literature
Trang 3146 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
Trang 4Part IV
Identity
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)
Trang 511
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