The Data Model Resource Book

Chapter 1: Introduction
Why Is There a Need for This Book?
On many of our data modeling consulting engagements, our clients ask us the same question: "Where can
we find a book showing a standard way to model this structure? Surely, we are not the first company to
model company and address information."
ased upon our consulting e!periences, most companies de"elop their data models or data warehouse
designs with "ery little outside reference materials. #here is a large cost associated with either hiring
e!perienced consultants or using internal staff to de"elop this critical component of the system design. Often
there is no ob$ecti"e reference material which they can use to "alidate their data models or data warehouse
designs, or seek alternate options for database structures.
%n general, one third of a data model &corporate or logical' consists of common constructs that are applicable
to most organi(ations and the other two thirds of the model are either industry) or enterprise)specific. #his
means that most data modeling efforts are recreating data modeling constructs that ha"e already been
created many times before in other organi(ations.
With this in mind, doesn*t it make sense to ha"e a source upon which to get a head start on your data model
so you are not "rein"enting the wheel" each time a company de"elops a new system? Organi(ations can
sa"e time and money by le"eraging the use of common or uni"ersal database structures. +"en if a company
has data models from its pre"ious systems de"elopment efforts, it is "ery helpful to be able to check the
designs against an unbiased source in order to e"aluate alternati"e options.
,lthough there are a large number of publications which describe how to model data, there are "ery few
compilations of data model e!amples in published form. #his book pro"ides both a starting point and a
source for "alidating data models. %t can assist data modelers to minimi(e design costs and de"elop more
effecti"e database designs.
Who Can Benefit from Reading This Book?
#his book can assist many different systems de"elopment professionals: data administrators, data modelers,
data analysts, database designers, data warehouse administrators, data warehouse designers, data
stewards, and corporate data integrators. Systems professionals can use the database constructs contained
within this book to increase their producti"ity and pro"ide a checkpoint for quality designs.
The Need for Universal Data Models
-ata modeling has been an art that first gained recognition since -r. .eter /hen*s 0123 article which
illustrated his new)found approach called "+ntity)4elationship 5odeling." Since then it has become the
standard approach used towards designing databases. y properly modeling an organi(ation*s data, the
database designer can eliminate data redundancies which are a key source for inaccurate information and
ineffecti"e systems.
/urrently, data modeling is a well)known and accepted method for designing effecti"e databases. #herefore,
there is a great need to pro"ide standard templates to enterprises &the term enterprise is used to describe
the organi(ations for whom the models and systems are being de"eloped' so they can refine and customi(e
their data models instead of starting from scratch.
,lthough many standards e!ist for data modeling, there is a great need to take data modeling to the ne!t
step: pro"iding accessibility to libraries of common data model e!amples in a con"enient format. #hese
libraries of models should be able to be used across many different organi(ations and industries. Such
uni"ersal data models can help sa"e tremendous amounts of time and money in the systems de"elopment
process.
Page 1 of 14
A Holisti A!!roah to "ystems Develo!ment
One of the largest challenges to building effecti"e systems is integration. Systems are often built separately
since there are particular needs at different times within each enterprise. +nterprises ha"e needs to build
many systems: contact management systems, sales order systems, pro$ect management systems,
accounting systems, budgeting systems, purchase order systems, and human resources systems, to name a
few.
When systems are built separately, there are separate pools of information for each system. 5any of these
systems will use common information about organi(ations, people, geographic locations, or products. #his
means that each separate system will build and use its own source of information. , huge problem with this
approach is that it is almost impossible to maintain accurate up)to)date information since the same type of
information is stored redundantly across many systems. %n large organi(ations, it is not uncommon to see
information about customers, employees, organi(ations, products, and locations stored in do(ens of
separate systems. 6ow is it possible to know which source of information is most current or accurate?
,nother way to approach systems de"elopment is from a perspecti"e that an enterprise*s systems are
connected and, in fact, may be "iewed as one interconnected system. 7rom this perspecti"e, there are
tremendous benefits to building an enterprise)wide framework so that systems can work together more
effecti"ely. .art of this enterprise)wide framework should include a corporate data model which can assist the
enterprise in maintaining one of its most "alued assets: information. Since each system or application may
use similar information about people, organi(ations, products, and geographic locations, a shared
information architecture can be in"aluable.
#he %S &information systems' industry has recogni(ed the need for integrated designs and this is why many
corporate data modeling and corporate data warehouse modeling efforts ha"e taken place. 8nfortunately,
the %S track record for building and implementing corporate data models has been "ery poor. +nterprises
ha"e reali(ed that it takes a tremendous amount of time and resources to build these models.
+nter /,S+ &/omputer),ided Systems +ngineering' tools. #hese tools claimed tremendous producti"ity and
time sa"ings when used for corporate)wide modeling efforts. While these tools help document the models,
unfortunately they do not reduce the time to de"elop good corporate models.
5any enterprises ha"e stopped building corporate data models because of their time constraints. #hey are
looking at the track record of corporate data modeling and /,S+ efforts and choosing other alternati"es.
+nter data warehousing. 7inally, here is an approach to pro"ide e!ecuti"es with the management information
they need, without all the time and e!pense of corporate data modeling. +nterprises are now e!tracting the
"arious pieces of information they need directly from their operational systems in order to build decision
support systems.
#he only problem with this approach is that the same problem e!ists9 7irst of all, the information in the data
warehouse may be e!tracted from se"eral different, inconsistent sources. %f there are multiple places that
customer information is being held, which system represents the most accurate source of information?
,ccording to data warehousing principles, the transformation routines are responsible for consolidating and
cleansing the data. 6owe"er, if different departments ha"e different needs for "arious pieces of data, then
each department may build its own e!tracts from the operational systems. One department may transform
the information using one algorithm while a different department may use another algorithm. 7or e!ample, if
two departments are e!tracting sales analysis information, one department may use the order entry system
as its source and another department may use the in"oicing system as its source. , high)le"el manager may
"iew information from both data warehouses and see inconsistent results, thus questioning the credibility of
any of the information. #his type of scenario actually compounds the initial problem of many data sources by
creating e"en more slices of data.
#his is not to say that data warehousing is the wrong approach. %t is an ingenious approach which can be
used e!tremely effecti"ely not only to create decision support systems but also to build a migration path to an
integrated en"ironment. #he data warehouse transformation process helps to identify where there are data
inconsistencies and data redundancies in the operational en"ironment. 6owe"er, it is imperati"e to use this
information to migrate to new integrated data structures.
Page 2 of 14
#he answer is still to build integrated data structures in order to pro"ide good, accurate information. %t is also
necessary to understand the nature of the data in order to build effecti"e systems. %nstead of saying that
corporate data modeling or /,S+ is the wrong approach because it $ust takes too long, the %S community
needs to find a way to make it work effecti"ely. y building common reusable data structures, the %S
community can produce quicker results and mo"e toward integrated structures in both the transaction
processing and data warehouse en"ironments.
What Is the Intent of This Book and These Models?
5ost data modeling books focus on the techniques and methodologies behind data modeling. #he approach
behind this book is dramatically different. #his book assumes that the reader knows how to model data. -ata
modeling has been around long enough that most information systems professionals are familiar with this
concept and will be able to understand this book. #herefore, this book makes no efforts to teach data
modeling principles, e!cept by e!ample. -ata modelers can use this book, and their pre"ious e!perience, to
build upon and refine the data model e!amples contained within the book in order to de"elop more
customi(ed data models. +ssentially, it is pro"iding the modeler with fundamental tools and building blocks
which can be reused. #herefore, the modeler can be more producti"e and sa"e a great deal of time by
starting with standard data models instead of building data models from scratch.
7urthermore, the reader can also benefit from the data warehouse models which are applicable to decision
support en"ironments. #his book not only presents e!amples of data warehouse designs, but also e!plains
in detail how to con"ert the logical data models to an enterprise)wide data warehouse, then to departmental
data marts. #he logical data models and data warehouse models presented here are applicable across a
wide "ariety of enterprises.
#hese models are intended to be a starting point for de"eloping logical and data warehouse data models for
an enterprise. +ach enterprise will ha"e its own detailed requirements: the models will need to be modified
and customi(ed in order to be implemented for a specific enterprise. Since the data warehouse data models
reflect actual database designs &as opposed to logical data models', they are e"en more dependent on the
business needs of the specific enterprise wishing to use these models. %n addition, the models in this book
can be used to "alidate an enterprise*s e!isting data models.
#he models presented in the first part of this book &/hapters ; through <' are logical data models, not
physical database designs. #herefore, these models are normali(ed and may require some denormali(ation
when designing the physical database. 5ethodologies for physical database design are not discussed in this
book. /onsistent with this point, the logical data models do not include any deri"ed attributes since deri"ed
attributes do not add anything to the information requirements of a business. #hey merely ser"e to enhance
performance of the physical database.
#hese logical data models represent possible data requirements for enterprises. #hey do not include many of
the business processing rules that may accompany data models. #he data models generally pro"ide all the
information needed to enforce business rules: howe"er, the reader is ad"ised in many cases that additional
business rules may need to be de"eloped to supplement the data models. +!amples of the need for
business rules are pro"ided throughout this book.
#hese data models were designed to benefit many different industries and enterprises. #hey were picked
specifically because they represent "ery common data constructs that appear in most organi(ations. Within
these models, whene"er there was a data modeling decision which may ha"e been dependent on a specific
enterprise, the most fle!ible data modeling option was chosen in order to accommodate many different
enterprises.
Page 3 of 14
Conventions and "tandards Used in This Book
#he following section describes the naming standards and diagramming con"entions used for presenting the
models within this book. -etails are described for entities, sub)types, attributes, relationships, foreign keys,
physical models, and illustration tables.
#ntities
,n entity is something of significance about which the enterprise wishes to store information. Whene"er
entities are referenced throughout the book, they are shown in capital letters. 7or e!ample, O4-+4
represents an entity which stores information about a commitment between parties to purchase products.
When the name of an entity is used in a sentence in order to illustrate concepts and business rules, it may be
shown in normal te!t. 7or e!ample, "5any enterprises ha"e mechanisms such as a sales order form to
record sales order information."
#he naming con"entions for an entity include using a singular noun that is as meaningful as possible to
reflect the information it is maintaining. ,dditionally, the suffi! #=.+ is added to the entity name if the entity
represents a classification of information such as an O4-+4 #=.+ &i.e., sales "ersus purchase order' rather
than a specific instance of a real thing such as an O4-+4 &"order >;?1<2"'.
#he data models in this book include #=.+ entities on the diagrams, e"en though they usually only ha"e a
code and description. #hese entities are included for completeness and to show where allowable "alues or
look)ups are stored.
+ntities are included in the data model if it is a requirement of the enterprise to maintain the information
included in the entity. 7or e!ample, if an enterprise doesn*t really care about tracking the tasks associated
with a shipment, then, e"en though this information e!ists in the real world, the data model should not
incorporate this information since it does not add "alue. +ntities are represented by rounded bo!es. 7igure
0.0 shows an e!ample of the entity O4-+4.
"$%&ty!es and "$!er&ty!es
, sub)type, sometimes referred to as a sub)entity, is a classification of an entity which has characteristics
such as attributes or relationships in common with the more general entity. %@#+4@,A O4B,@%C,#%O@ and
+D#+4@,A O4B,@%C,#%O@ are for e!ample, sub)types of O4B,@%C,#%O@.
Sub)types are represented in the data modeling diagrams by entities inside other entities. #he common
attributes and relationships between sub)types are shown in the outside entity which is known as the super)
type. #he attributes and relationships of the super)type are therefore inherited by the sub)type. 7igure 0.;
shows the super)type O4B,@%C,#%O@ and its sub)types %@#+4@,A O4B,@%C,#%O@ and +D#+4@,A
O4B,@%C,#%O@. @otice that the name and federal ta! %- apply to both sub)types and are therefore shown
at the super)type le"el of O4B,@%C,#%O@. ,nything specific to an internal organi(ation would be tied to only
that sub)type.
#he sub)types within an entity should represent a complete set of classifications &meaning that the sum of
the sub)types co"ers the super)type in its entirety' and at the same time be mutually e!clusi"e of each other.
5any times the data model includes an O#6+4 . . . sub)type to pro"ide for other possible classifications of
the entity which may be defined by the enterprise using the model.
While the sub)types represent a complete set of possible classifications, there may be more detailed sub)
types which are not included in the data model: instead, they may be included in a #=.+ entity. %n this case,
sub)types are shown in two places on a model: as a sub)type and in a #=.+ entity which shows the domain
of allowed types for the entity.
Attri%$tes
,n attribute holds a particular piece of information about an entity, such as the order date on an order.
,ttributes are identified in the te!t of the book by boldface, lowercase letters such as the pre"ious order date
e!ample.
,ttributes may be either part of the unique identifier of an entity &also referred to as a primary key',
mandatory, or optional. #he primary key attribute&s' is identified by a *>* sign preceding the attribute name on
the diagram. 5andatory attributes are signified by a *E* before the attribute name. Optional attributes ha"e a
Page 4 of 14
*o* before the attribute. 7igure 0.? shows that the O4-+4 entity has order %- as a primary key attribute, order
date as a mandatory attribute, and entry date and shipping instructions as optional attributes.
/ertain strings included in an attribute*s name ha"e meanings based upon the con"entions in #able 0.0.
Relationshi!s
4elationships define how two entities are associated with each other. When relationships are used in the
te!t, they are usually shown in lowercase as a normal part of the te!t. %n some situations, where they are
specifically highlighted, they are identified by boldface lowercase letters. 7or e!ample, manufactured by
would be the way a relationship may appear in the te!t of this book.
4elationships may be either optional or mandatory. , dotted relationship line means that the relationship is
optional and a continuous line means that the relationship is mandatory &the relationship is present in all
occurrences of each entity'. 7igure 0.F shows a relationship that "each .4O-8/# must be manufactured by
one and only one O4B,@%C,#%O@." #his means that the manufacturer for each product must be specified.
#he same relationship has an optional aspect when read in the other direction: "+ach O4B,@%C,#%O@ may
be the producer of one or more .4O-8/#s."
4elationships may be one)to)one, one)to)many, or many)to)many. #his is generally known as the cardinality
of the relationship. #he presence of a crowsfoot &a three)pronged line which looks like a crow*s foot' defines
if an entity points to more than one occurrence of another entity. 7igure 0.G shows that "each O4-+4 may
be composed of one or more O4-+4 A%@+ %#+5s," since the crowsfoot is at the O4-+4 A%@+ %#+5 side.
#he other relationship side states that "each O4-+4 A%@+ %#+5 must be part of one and only one O4-+4."
, one)to)one relationship doesn*t ha"e any crowsfeet on the relationship and a many)to)many relationship
has crowsfeet at both ends of the relationship. Sometimes, one)to)many relationships are referred to as
parent)child relationships.
Sometimes the term "o"er time" needs to be added to the relationship sentence to "erify whether the
relationship is one)to)many. 7or instance, an O4-+4 may only appear to ha"e one O4-+4 S#,#8S.
6owe"er, if status history is required, then each O4-+4 may be described by one or more O4-+4
S#,#8S, o"er time.
#he data models in the book ha"e "ery few one)to)one relationships, since most of the time one)to)one
relationships can be grouped together into a single entity when normali(ed. #he data model diagrams show
"ery few many)to)many relationships, since most of the time many)to)many)relationships are broken out into
intersection entities.
%ntersection entities are also known as associati"e entities or cross)reference entities. #hey are used to
resol"e many)to)many relationships by cross)referencing one entity to another. Often they include additional
attributes which may further delineate the relationship. 7igure 0.3 shows a many)to)many relationship
between a .4O-8/# and an O4B,@%C,#%O@ which is resol"ed in this way. #he diagram indicates that a
.4O-8/# may be supplied through more than one O4B,@%C,#%O@ and an O4B,@%C,#%O@ may be the
seller of more than one .4O-8/#. #his many)to)many relationship is resol"ed by the intersection entity
.4O-8/# S8..A%+4.
@otice that in all the e!amples gi"en, each relationship has two relationship names associated with it that
describe the relationship in both directions. #he relationship names should be combined so that they read as
a complete sentence, as shown in the following format: "+ach +@#%#= Hmust beImay beJ relationship name
Hone and only oneIone or moreJ +@#%#=, o"er time," where the appropriate choices are filled in.
%n the models presented, the crowsfeet on the relationships generally point up and to the left in order to
pro"ide a consistent mechanism for reading the diagrams. #his tends to organi(e the data models in a more
understandable format.
+!clusi"e arcs are relationships where an entity is related to two or more other entities, but only one
relationship can e!ist for a specific entity occurrence. #he e!clusi"e arc is represented by a cur"ed line going
through two or more relationship lines with little circles identifying the relationships it co"ers. 7igure 0.2
shows an e!ample of an e!clusi"e arc. #he relationships are read as "+ach ,B4++5+@# A%@+ %#+5
.4%/+ may be either a price specified for one and only one .,4#= ,--4+SS or a price specified for one
and only one B+OB4,.6%/ O8@-,4=, but not both."
Page 5 of 14
4ecursi"e relationships are either modeled "ia a relationship pointing from an entity to itself or "ia a many)to)
many)relationship. 7igure 0.< shows an e!ample of a one)to)many recursion around the .4O-8/# entity
and a many)to)many recursion which is resol"ed by the intersection entity .4O-8/# /O5.O@+@#.
'oreign (ey Relationshi!s
, foreign key is defined as the presence of another entity*s &or table*s' primary key in an entity &or table'. 7or
e!ample, in 7igure 0.G the order %- from the O4-+4 entity is part of the O4-+4 A%@+ %#+5 entity:
therefore, it is a foreign key. ,ny one)to)many relationship indicates that the primary key of the entity on the
one side of the relationship is brought into the entity on the many side of the relationship. Some data
modelers show this foreign key as an attribute of the entity &this is sometimes known as key migration'. #he
data models in this book do not show the foreign keys of entities as attributes since this is redundant.
%nstead, the relationship itself identifies the foreign key. %n 7igure 0.G, the order %- is not shown as an
attribute in the O4-+4 A%@+ %#+5 entity since the one)to)many nature of the relationship re"eals it is a
foreign key. ,nother diagramming con"ention in this book is to use a crossed relationship line to indicate that
the inherited foreign key is part of the primary key of the child entity. #he small hori(ontal line across the
relationship in 7igure 0.G indicates that the hori(ontal order %- is part of the O4-+4 A%@+ %#+5 entity
primary key.
)hysial Models
#he data warehouse models and diagrams &/hapters 1 through 0;' represent physical database designs for
decision support en"ironments: therefore, the notation is slightly different. Since these models represent
physical database designs, each square &not rounded as in the entity' bo! represents a table and the field
names are columns. ,ll the lines connecting tables in the model are solid lines and the foreign keys of the
relationships are now shown in each appropriate table as columns since these columns will ultimately be
implemented.
#he naming con"ention for tables is to keep them plural and the column names ha"e underscores instead of
blanks between them. &#he entities had singular names and attributes allowed blank spaces between the
names.'
Conventions Used for Ill$stration Ta%les
5any parts of the data models are illustrated "ia tables which contain possible "alues for attributes. +ach
illustration table is normally defined to show a specific entity and the rele"ant information from related
entities. 7or instance, there may be a table illustrating the O4-+4 A%@+ %#+5 entity as shown in #able 0.;.
%n order to illustrate the details of an O4-+4 A%@+ %#+5, #able 0.; brings in some attribute information from
the O4-+4 entity. @otice that there is an asterisk on the order date column of the table. #he asterisk
indicates that e"en though the table is designed to illustrate O4-+4 A%@+ %#+5 information, the order date
information resides in an entity other than the main entity being illustrated and is included for conte!t.
Whene"er data from each illustration table is referenced in the te!t of this book, it is surrounded by double
quotes. 7or instance, the te!t may refer to specific order "0;1?K", line item seq "0" which has a comment of
"@eed this item urgently".
The Com!anion CD&R*M
Within this book and its appendices, are "ery detailed descriptions of the models discussed. #he diagrams
lay out all the relationships, the mandatory attributes and columns, the primary keys, and e"en include some
optional attributes. #he appendices include the physical details for the attributes and columns, such as the
datatype and si(e. With this information, it would be possible for a data modeler or database designer to
recreate these models in the tool of their choice or write the SLA code to build them in a database.
#his, howe"er, would take a substantial amount of time and opens the possibility of data entry errors. #o
assist those interested in quickly implementing the models discussed in the following pages, a companion
/-)4O5 is a"ailable for sale separately. On the /-)4O5 is a series of SLA scripts deri"ed directly from the
models in the book. ,ll the entities, attributes, tables, and columns discussed are implemented with this
code. Scripts are pro"ided for Oracle, %nformi!, Sybase SLA Ser"er, and 5icrosoft SLA Ser"er. +ach of
these scripts has been tested and "erified against the abo"e databases. Since these are standard SLA
scripts, they should work with not only the current "ersions of these database management systems but also
with future "ersions &i.e. Oracle<'. #here are also ,@S% standard SLA scripts which could be used with other
,@S% compliant databases.
Page 6 of 14
Since the /4)4O5 includes standard SLA scripts, they should work with not only the current "ersions of
these databse management systems but also with future "ersions. #his includes ob$ect)relational databases
&i.e. Oracle<, %nformi! 8ni"ersal Ser"er' which should continue to support relational designs. #he constructs
in the book are, of course, also generally applicable to any relational or ob$ect)relational database.
8se of the scripts on the /-)4O5 will allow an enterprise to more rapidly deploy the models presented in
this book. %n addition to the time sa"ings, there is ob"iously a cost sa"ings as well &nobody has to type in all
the definitions or write SLA scripts'. Once the scripts ha"e been run, the models could be re"erse)
engineered into the enterprise*s fa"orite /,S+ tool &most popular /,S+ tools pro"ide a re"erse engineering
feature'. Once the models ha"e been brought into a repository, they are easily accessible and may be
customi(ed for a specific enterprise*s needs. ,dditionally, they can be used to $ump)start the de"elopment of
corporate data models, new applications, data warehouse designs, or decision support systems.
#he remainder of this book will pro"ide many e!amples of uni"ersal data models and data warehouse
designs which can assist in increasing the producti"ity of system de"elopment efforts.
Page 7 of 14
The Data Model Resource Book
Chapter 2: People and Organizations
Introd$tion
#he most frequent business information need is to ask questions about people and organi(ations and to be
able to rely on accurate information. 7or instance:
What are the attributes or characteristics of the people and organi(ations that are in"ol"ed in the
course of conducting business?
What relationships e!ist between "arious people, between "arious organi(ations, and between
people and organi(ations?
What are the addresses of people and organi(ations, and how can they be contacted?
What types of communication or contacts ha"e occurred between "arious parties?
,lmost all business applications track information about people and organi(ations, recording information
about customers, suppliers, subsidiaries, departments, employees, and contractors, redundantly in many
different systems. 7or this reason, it is "ery difficult to keep key information such as client contact data
consistent and accurate. +!amples of applications that store information about people and organi(ations
include sales, marketing, purchasing, order entry, in"oicing, pro$ect management, and accounting.
#he data model within this chapter can be used for most organi(ations and applications. Subsequent
chapters use this data model as a basis upon which to add more detail. #his chapter includes data models
on:
Organi(ation definition
.erson definition
.arty definition
.arty relationship
,ddress definition
/ontact mechanism definition
/ontact information
*rgani+ation Definition
5ost data models maintain organi(ational information in "arious entities. 7or instance, there may be a
customer entity, a "endor entity, and a department entity. +ach application within an enterprise has its own
needs: therefore, the data modeler will often base the model upon the needs of a particular application. 7or
e!ample, when building an order entry application, the customer information is crucial: therefore, the data
modeler shows a separate entity for customer. Aikewise, the supplier information is critical when building a
purchasing application: hence there is normally a supplier entity. 7or a human resources system, the data
modeler might show an entity called a department within which the employees work.
#he problem is that an organi(ation may play many roles, depending on the particular circumstance. 7or
instance, in larger companies, internal organi(ations sell to each other. #he property management di"ision
may be a supplier to the product sales di"ision. #he property management di"ision may also be a customer
of the product sales di"ision. %n this case, there would normally be both a customer and supplier record, with
redundant data, for each of these di"isions. @ot only could there be a customer and supplier record, but
there could also be many additional records for the organi(ation depending on how many roles the
organi(ation plays within the enterprise.
When an organi(ation*s information changesMsuch as a change in addressMthe information might be
updated in only one of the many systems where organi(ation information is stored. #his, of course, results in
inconsistent information within the enterprise. %t may also result in ma$or frustration on the part of managers,
customers, suppliers, and anyone who might want to get out a correct mailing list9
#he solution to this redundancy problem is to model an entity called O4B,@%C,#%O@ which stores
information about a group of people with a common purpose such as a corporation, department, di"ision,
go"ernment agency, or nonprofit organi(ation. asic organi(ational information such as its name and federal
Page 8 of 14
ta! %- is stored once within this entity, reducing redundancy of information and eliminating possible update
discrepancies.
7igure ;.0 shows the data model for organi(ation information. #he O4B,@%C,#%O@ entity is sub)typed into
%@#+4@,A O4B,@%C,#%O@ and +D#+4@,A O4B,@%C,#%O@. ,n %@#+4@,A O4B,@%C,#%O@ is one that
is part of the enterprise for whom the data model is being de"eloped and an +D#+4@,A O4B,@%C,#%O@ is
not part of that enterprise.
#his model reduces redundancy since the organi(ation name is stored only once, as opposed to storing this
information redundantly in a customer entity, supplier entity, department entity, or any other entity storing
organi(ation information.
#able ;.0 gi"es e!amples of data in the O4B,@%C,#%O@ entity. @otice that organi(ations include not only
businesses but also other groups of indi"iduals such as departments. 7or e!ample, the accounting and
information systems departments are included as organi(ations.
7or the remainder of this book, the term "enterprise" will be used to refer to all the internal organi(ations for
whom the data model is being de"eloped. 7or instance, each enterprise will ha"e its own specific needs and
business rules which will determine how the enterprise will customi(e these models for its own use.
)erson Definition
Nust as most data models show separate entities for "arious types of organi(ations, they also show separate
entities for "arious types of people such as employees, contractors, supplier contacts, and customer
contacts. #he problem with keeping this information in separate entities is that people may also ha"e
different $obs and roles which change o"er time. 5ost systems will record redundant information about a
person since they store a record each time the person*s role changes.
7or e!ample, Nohn Smith was a good customer of ,/ /orporation. Nohn then decided to perform contract
labor for ,/ /orporation. #he people at ,/ /orporation liked his work so much that they then hired him
as an employee. 7or most systems, there would be a separate record for Nohn Smith as a customer contact,
then as a contractor, then as an employee. 6owe"er, much of Nohn Smith*s information has remained the
same, such as his name, se!, birth date, skills and other demographics. ecause Nohn Smith*s information is
stored in se"eral locations, many systems would ha"e trouble keeping his information accurate and
consistent.
,nother problem is that the same person may ha"e many different roles at the same time. 7or instance, ,/
/orporation is a large company with many di"isions. Shirley Nones is an employee and manager of the
transportation di"ision. She is also considered a customer for the supplies di"ision. ,t the same time, she is
the supplier for the publishing di"ision which needs her ser"ices to transport catalogues. #herefore, Shirley is
an employee of yet one di"ision, a customer contact of yet another di"ision, and a supplier contact of another
di"ision. 4ather than ha"e three separate records for Shirley with redundant information, there should only
be one record.
#o address this issue, 7igure ;.; shows a .+4SO@ entity which stores a particular person*s information,
independent of his or her $obs or roles. ,ttributes of the .+4SO@ entity could include se!, birth date, height,
weight, and any other characteristics which describe the person.
Nust as the O4B,@%C,#%O@ entity is sub)typed, the .+4SO@ entity is sub)typed into +5.AO=++ and
@O@)+5.AO=++. ,n +5.AO=++ is a person who is employed by the enterprise for whom the data model
is being de"eloped and a @O@)+5.AO=++ is not employed by that enterprise.
#able ;.; shows some e!ample data for the .+4SO@ entity. #his model has again helped reduce
redundancy since the person*s base information is only maintained once, e"en though the person may play
many different roles. #he .arty 4elationships section later in this chapter will describe how to model the
"arious roles each person and organi(ation can play.
)arty Definition
Organi(ations and people are similar in many respects. #hey both ha"e common characteristics which
describe them, such as their credit rating, address, phone number, fa! number, or e)mail address.
Organi(ations and people can also ser"e in similar roles as parties to contracts, buyers, sellers, responsible
Page 9 of 14
parties, or members of other organi(ations. 7or e!ample, membership organi(ations &like a computer users
group' may keep similar information on their corporate members and their indi"idual members. /ontracts
can usually specify an organi(ation or a person as a contracted party. #he customer for a sales order may be
either an organi(ation or a person.
%f person and organi(ation were modeled as separate entities, the data model would be more comple!. +ach
contract, sales order, membership, or transaction that in"ol"ed either a person or an organi(ation would need
two relationships: one to the person entity and one to the organi(ation entity. 7urthermore, these
relationships are mutually e!clusi"e and thus form an e!clusi"e arc &see /hapter 0 for a discussion on
e!clusi"e arcs'. 7or instance, a sales order could either be placed by a person or an organi(ation, but a
single sales order cannot be placed by both a person and an organi(ation at the same time.
#herefore, 7igure ;.? shows a super)entity named .,4#= which has as its two sub)types, .+4SO@ and
O4B,@%C,#%O@. #his .,4#= entity will enable storage of some of the common characteristics and
relationships which people and organi(ations share.
.arties are classified into "arious categories using the entity .,4#= -+7%@%#%O@ which stores each
category into which parties may belong. #he possible "alues for categories are maintained in the .,4#=
#=.+ entity. 7or e!ample, a type of party may be "minority)owned business", "<, business", "woman)owned
business", "go"ernment institute", or "manufacturer". #he categori(ations of parties can be used to determine
if there are any special business considerations for parties, special pricing arrangements, or special terms
based upon the type of party. %t is also a mechanism for classifying businesses into types of industries for
market segmentation. , from date and thru date are included so history can also be tracked, since it is
possible for the definition to change o"er time Oe.g., businesses may "graduate" from the <, &minority startup'
programP.
#able ;.? shows se"eral party occurrences that are merely consolidations from the person and organi(ation
e!amples. #his single entity allows the data models to refer to either a person or organi(ation as a party to a
transaction.
)arty Relationshi!
,s noted pre"iously, a person or organi(ation may play any number of roles such as a customer, supplier,
employer, or subsidiary. +ach role that a party plays only makes sense in relation to another party. %f ,/5+
/ompany is a customer, is it a customer of ,/ Subsidiary or a customer of the parent company, ,/
/orporation? 5aybe it is a customer of the widgets di"ision or the gadgets di"ision.
%nstead of modeling $ust the roles of the party, there is a need to model the relationship between parties. 7or
e!ample, there is a need to know not only that ,/5+ /ompany is a customer, but that ,/5+ /ompany is a
customer of ,/ Subsidiary. y default, this fact also implies that the ,/ Subsidiary is a supplier of the
,/5+ /ompany.
, relationship is comprised of two parties and their respecti"e roles. 7or e!ample, customerIsupplier,
parentIsubsidiary, and di"isionIdepartment are possible organi(ation relationships.
#he .,4#= 4+A,#%O@S6%. entity shown in 7igure ;.F allows parties to be related to other parties and
maintains the respecti"e roles in the relationship. #he .,4#= 4+A,#%O@S6%. entity has attributes of from
date and thru date in order to show the "alid time frames of the relationship. #he .,4#= 4+A,#%O@S6%.
#=.+ entity in 7igure ;.F consists of a pair of roles which are used to define the nature of a .,4#=
4+A,#%O@S6%.. /ustomerISupplier is a "alid pair of roles, while the combination of /ustomerISales ,gent
roles would not be "alid because these roles do not complement each other &,uthori(orISales ,gent would
make more sense'. #he description attribute describes the nature of a specific relationship. 7or e!ample, a
customerIsupplier relationship description may be "where the customer has purchased or is planning on
purchasing items or ser"ices from the supplier."
#he .,4#= 4OA+ #=.+ entity is a list of possible roles that can be played by the parties within a .,4#=
4+A,#%O@S6%. #=.+. #he two relationships from .,4#= 4OA+ #=.+ to .,4#= 4+A,#%O@S6%. #=.+
define the nature of the relationship. #o form a "customerIsupplier" .,4#= 4+A,#%O@S6%. #=.+, there
would be two relationships: one to the "customer" instance in the .,4#= 4OA+ #=.+ entity, and another to
the "supplier" instance.
Page 10 of 14
#he .,4#= 4+A,#%O@S6%. S#,#8S entity defines the current state of the relationship. +!amples include
"acti"e", "inacti"e", or "pursuing more in"ol"ement". #he .,4#= .4%O4%#= entity establishes the relati"e
importance of the relationship to the enterprise. +!amples may include ""ery high", "high", "medium", and
"low". ,lternati"ely, an enterprise may choose to use "first", "second", "third", and so on to prioriti(e the
importance of "arious relationships.
7igure ;.G illustrates the relationships for the organi(ation, ,/ Subsidiary. #able ;.F shows the data which
is stored in the .,4#= 4+A,#%O@S6%. entity to represent these relationships. #he internal organi(ations
within the table are ,/ /orporation, ,/ Subsidiary, and ,/*s /ustomer Ser"ice -i"ision. #he first row
shows that ,/ Subsidiary is a subsidiary of the parent corporation, ,/ /orporation. #he second row
shows that the /ustomer Ser"ice -i"ision is a di"ision of ,/ Subsidiary. #he third row shows that ,/5+
/ompany is a customer of ,/ Subsidiary. @otice that the fifth row shows that ,/ Subsidiary is a customer
of 7antastic Supplies, or in other words, 7antastic Supplies is a supplier for ,/ Subsidiary. %f 7antastic
Supplies was a supplier for all of ,/ /orporation, there would be a relationship to the parent company, ,/
/orporation, instead of to the subsidiary.
Nust as organi(ations ha"e relationships with other organi(ations, people ha"e relationships with other
people. +!amples of person)to)person relationships include people*s mentors, people*s family structures, and
people*s business contacts. #able ;.G shows person)to)person relationship e!amples. #hese relationships
are stored in the same entity &.,4#= 4+A,#%O@S6%.' as organi(ation)to)organi(ation relationships:
howe"er, #able ;.G breaks out the person)to)person relationships for ease of understanding.
%n #able ;.G, Nohn Smith has arry Boldstein as a mentor. Nudy Smith is Nohn Smith*s daughter. Noe Schmidt
is the customer representati"e whom @ancy arry calls upon to sell her company*s products. Nohn Smith is
arry /unningham*s customer &contact'.
7inally, a person may play any number of roles within an organi(ation: an employee, a supplier contact, a
customer contact, and so on. #able ;.3 shows e!amples of people*s roles within organi(ations. 7or e!ample
@ancy arry, Nohn Smith, and William Nones are all employees of ,/ Subsidiary. William Nones is not only
an employee of ,/ Subsidiary but also contracts to 6ughes /argo. arry /unningham is a supplier
representati"e for 7antastic Supplier: therefore, people can contact him to purchase items from 7antastic
Supplies. Noe Schmidt is the customer representati"e for ,/5+ /ompany and represents its interests as a
customer.
Address Definition
7igure ;.3 shows the data model for address)related information. #he B+OB4,.6%/ O8@-,4= entity
stores the /O8@#=, /%#=, S#,#+, and /O8@#4= of an ,--4+SS. #he ,--4+SS entity maintains all
addresses used by the enterprise in a central place. #he .,4#= ,--4+SS entity shows which ,--4+SS is
related to which .,4#=. #he .,4#= ,--4+SS 4OA+ entity defines the roles that a .,4#= ,--4+SS may
ha"e and is primarily used to "alidate that the address is used for its intended purpose. .,4#= ,--4+SS
4OA+ #=.+ maintains the possible "alues of the roles which addresses may play.
Address
+ach ,--4+SS has geographic boundaries in which it resides. #hese could include counties, cities, states,
territories, pro"inces &/anada', prefectures &Napan', regions, and countries: they will "ary by country. ,s an
e!ample, the model in 7igure ;.3 includes the sub)types /O8@#=, /%#=, S#,#+, /O8@#4=, and the super)
type B+OB4,.6%/ O8@-,4= with appropriate relationships between them.
#he ,--4+SS entity stores attributes to identify the specific location within the geographic boundary. #he
address0 and address; attributes pro"ide a mechanism for two te!t lines of an address. #here may be a
need for more address line attributes depending on the needs of the enterprise. #he postal code identifies
the mailing code that is used for deli"ery. %n the 8nited States, the postal code is referred to as the (ip code.
#he directions attribute pro"ides instructions on what roads to tra"el and what turns to take in order to arri"e
at that address.
)arty Address
,n organi(ation may ha"e many addresses or locations. 7or instance, a retailer might ha"e se"eral outlets at
different addresses. %n this instance, there is only one O4B,@%C,#%O@ or .,4#= but many locations or
addresses. ,dditionally, the same address might be used by many organi(ations. 7or instance, many
subsidiaries of an organi(ation might share the same address. ,lso, different organi(ations might share the
same address if they are in a shared office facility.
Page 11 of 14
#herefore, there is a many)to)many relationship between O4B,@%C,#%O@ and ,--4+SS. #here is also a
many)to)many relationship between .+4SO@ and ,--4+SS. , particular address may ha"e many people
residing there, such as when many employees work at the same facility. ,nd, of course, people generally
ha"e many addresses: their home address, work address, "acation address, and so forth.
%nstead of two separate relationships for people and organi(ations, the model shows a many)to)many
relationship between .,4#= and ,--4+SS that is resol"ed "ia an intersection entity &sometimes referred to
as an associati"e or cross)reference entity' named .,4#= ,--4+SS, as shown in 7igure ;.3. @otice that
.,4#= ,--4+SS has a from date and thru date which allows the ability to track the address history of
parties.
#ables ;.2 and ;.< gi"e e!amples of party addresses. #able ;.2 lists the indi"idual address records, while
#able ;.< cross)references parties to addresses. With this model, addresses are only stored onceMthus
eliminating redundant data problemsMand can be reused many times in relationship to many parties. 7or
instance, in #ables ;.2 and ;.<, the same address, address %- ;?KK, is used by ,/ /orporation and ,/
Subsidiary. ,dditionally, ,/ Subsidiary has more than one address as illustrated by its two entries in #able
;.<.
Address Role
7or each party located at an address, or .,4#= ,--4+SS, there may be many purposes or roles for the
address. #he address might be a mailing address, a headquarters address, a ser"ice address, and so on.
5ost systems ha"e a separate record for the mailing address, headquarters address, and ser"ice address,
e"en though the address information may be e!actly the same. #herefore, the data model in 7igure ;.3
shows that each .,4#= ,--4+SS must ha"e one or more .,4#= ,--4+SS 4OA+s. #he .,4#=
,--4+SS 4OA+ stores the roles a party address may play. , list of possible "alues is a"ailable in the
.,4#= ,--4+SS 4OA+ #=.+ entity.
,nother way this could be modeled is to include the role in the .,4#= ,--4+SS entity and ha"e additional
cross)reference records for each of the address* roles. 7or e!ample, if the same party*s address ser"ed as a
mailing, headquarters, and ser"ice address, it would be stored as three instances in the .,4#= ,--4+SS
entity. +ach instance would ha"e the same party and address %- but would ha"e a different role. #he
disad"antage of this model is that the .,4#= ,--4+SS entity has significance on its own. 7or instance,
each .,4#= ,--4+SS may ha"e telephone and fa! numbers associated with it. 7or this reason, our model
shows separate .,4#= ,--4+SS and .,4#= ,--4+SS 4OA+ entities.
#able ;.1 illustrates that ,/ /orporation*s address can be used as the corporate headquarters, central
mailing address, and legal office. #he .,4#= ,--4+SS 4OA+ entity pro"ides for the storage of a party
address only once with many roles for that party*s address.
Contat Mehanism Definition
%n many data models, phone numbers are shown as attributes of the organi(ation or person. 8sually, there
are also fields for fa! numbers, modem numbers, pager numbers, cellular numbers, and electronic mail
addresses. #his often leads to limitations in the systems built. 7or instance, if someone has two business
phone numbers and there is only one business phone number field for a person, where is the other business
phone number entered? %n this new world where there are many methods for contacting parties, more
fle!ible data structures are needed.
#he /O@#,/# 5+/6,@%S5 entity in 7igure ;.2 stores access numbers for parties. +ach /O@#,/#
5+/6,@%S5 may be the way to contact either a particular .,4#= or .,4#= ,--4+SS. #he intersection
entity .,4#= /O@#,/# 5+/6,@%S5 shows which contact mechanisms are related to which parties or
addresses. #he model also shows "alid roles a"ailable "ia the relationship from .,4#= /O@#,/#
5+/6,@%S5 to .,4#= /O@#,/# 5+/6,@%S5 4OA+. #he /O@#,/# 5+/6,@%S5 #=.+ and .,4#=
/O@#,/# 5+/6,@%S5 4OA+ #=.+ are entities which maintain allowable "alues.
Contat Mehanism
/O@#,/# 5+/6,@%S5s are sub)typed to include #+A+/O5 @85+4 and +A+/#4O@%/ ,--4+SS.
#+A+/O5 @85+4 includes any access "ia telecommunications lines such as phones, fa!es, modems,
pagers, and cellular numbers. +A+/#4O@%/ ,--4+SS includes any access "ia ser"ices like the %nternet or
other electronic mail ser"ices.
Page 12 of 14
#he /O@#,/# 5+/6,@%S5 #=.+ entity shows all the possible "alues for types of contact mechanism.
+!amples include office phone, home phone, office fa!, modem, cellular, %nternet address, and other
electronic addresses. With technology growing so quickly, it is "ery likely that there will be many ways to get
in touch with someone. #he data structure in 7igure ;.2 pro"ides an easy method for adding any new contact
mechanisms by simply inserting and using new /O@#,/# 5+/6,@%S5 #=.+s.
Contat Mehanism Relationshi!s to )arty and )arty Address
, contact mechanism could be tied to particular physical locations &namely, .,4#= ,--4+SS' such as the
telephone number for a retailer*s store location, or it might be tied to a particular .,4#=, such as a person*s
cellular telephone number. #here is a many)to)many relationship from /O@#,/# 5+/6,@%S5 to both
.,4#= ,--4+SS and .,4#=. 7or e!ample, a contact mechanism may be used to contact more than one
party, such as a $oint telephone number for a family. #he contact mechanism may also be for more than one
party address, such as a roaming telephone number that co"ers more than one location. #herefore, the
.,4#= /O@#,/# 5+/6,@%S5 is used as the intersection entity and represents the combination of a
/O@#,/# 5+/6,@%S5 used by either a .,4#= or .,4#= ,--4+SS.
#able ;.0K gi"es e!amples of party contact mechanisms. #he first two entries show the phone and fa!
numbers which are tied to the .,4#= ,--4+SS for ,/ /orporation at 0KK 5ain Street. #he third and
fourth rows show that Nohn Smith*s number at 0KK 5ain Street is &;0;' ;?F)1<G3, but he has another office
phone at ?FG 6amulet .lace. #hese are both tied to a .,4#= ,--4+SS. Nohn Smith also has a cellular
number which is tied directly to his .,4#= instance. arry Boldstein has an office phone which is tied to one
.,4#= ,--4+SS &his work address' and a home phone which is tied to a different .,4#= ,--4+SS &his
home address'. 6e also has an %nternet address which is tied directly to his .,4#= instance, since he can
access his e)mail from any location that is properly equipped.
Contat Mehanism Role
7urthermore, $ust as addresses are intended for specific purposes, so are party contact mechanisms. ,
single contact mechanism may ha"e more than one purpose. 7or e!ample, business people sometimes ha"e
a single number for both their phone and fa! needs. #herefore, the .,4#= /O@#,/# 5+/6,@%S5 4OA+
defines the designated purposes for each .,4#= /O@#,/# 5+/6,@%S5. #he "alid roles are described in
.,4#= /O@#,/# 5+/6,@%S5 4OA+ #=.+.
,n e!ample of a party contact mechanism role is that a telephone number may be playing roles as the
"primary business contact number" and the "general information number". Other possible party contact
mechanism roles include "customer ser"ice number" or "in"oicing questions line".
%n the comple! world of today, in which there are usually many contact mechanisms, it is "ery useful to
identify the purposes of each contact mechanism. Since the purposes of "arious contact mechanisms
change o"er time, the from date and thru date identify when the purposes are "alid.
)arty ,oation
#hink of a party address as a physical location and a party contact mechanism as a "irtual location.
#herefore, the term party location is used throughout this book to mean the location of the party, whether it*s
a physical location such as the address of a retail store or a "irtual location such as an %nternet address.
,lthough this model defines physical locations and "irtual locations as "ery different and separate entities, it
is concei"able to model a super)type .,4#= AO/,#%O@ which has as its sub)types .,4#= /O@#,/#
5+/6,@%S5 and .,4#= ,--4+SS. #his could be useful, for e!ample, in identifying where an order came
fromMit could ha"e been from a physical location or a "irtual location such as an %nternet address.
Contat Information
%t is important in many applications to track information regarding with whom and when contact was made
during a business relationship. 7or instance, sales or account representati"es often need to know who was
called for what purpose and when in order to properly follow up with their customers. #he contact might ha"e
been "ia a telephone call, an in)person sales meeting, a conference call, a letter, or through any other
method of encounter.
%n 7igure ;.<, the entity /O@#,/# @O#+ pro"ides a history of the "arious encounters or contacts made
within a particular .,4#= 4+A,#%O@S6%.. #he /O@#,/# @O#+ maintains the date of contact, a note
describing the contact, and the type of contact. #he status of the contact is maintained through the @O#+
S#,#8S #=.+ entity. +!ample statuses include "scheduled", "in progress", and "completed". #he /O@#,/#
Page 13 of 14
#=.+ entity is used to define the possible types of contacts such as "initial sales call", "ser"ice repair call",
"demonstration", "sales lunch appointment", or "telephone solicitation". #able ;.00 gi"es other e!amples of
types of contacts.
#he /O@#,/# @O#+ is related to the .,4#= 4+A,#%O@S6%. and not the parties since it is within a
relationship that contacts make sense. %t is possible to ha"e se"eral relationships between two parties. 7or
instance, Noe Schmidt might be the customer contact for @ancy arry in one relationship. ,t a later date, Noe
Schmidt might decide to work for @ancy arry*s company and report to her. %t would be appropriate to track
the contacts for these relationships separately. #able ;.00 gi"es e!amples of possible contacts. @ancy arry,
a sales person for ,/ /orporation, has made se"eral sales contacts with Noe Schmidt, the customer
representati"e for ,/5+ /orporation. #he first four entries in #able ;.00 show the date and the nature of
these calls. @otice that contacts ha"e a status to indicate if the acti"ity has been completed or if it is $ust
scheduled. #he fifth entry shows a contact initiated by Nohn Smith in accounting to arry /unningham who is
a supplier representati"e. #his data structure pro"ides a mechanism for tracking contacts for any type of
relationship and is a "ery powerful business tool. Summary 5ost data models and database designs
unnecessarily duplicate information regarding people and organi(ations. ,s a result, many organi(ations
ha"e a "ery difficult time maintaining accurate information. #his chapter has illustrated how to build a "ery
fle!ible and normali(ed data model for people, organi(ations, party relationships, addresses, contact
mechanisms, and contacts made between parties. 7igure ;.1 shows the key entities discussed in this
chapter and their relationship to each other.
.lease refer to ,ppendi! , for more detailed attribute characteristics. SLA scripts to build tables, columns,
and constraints deri"ed from this logical model can be found on the accompanying /-)4O5 that is sold
separately.
Page 14 of 14