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. . 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. 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,. 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