Report of the DLF Electronic Resource Management Initiative

Appendix D: Entity Relationship Diagram for Electronic Resource Management

Introduction
This document is an entity-relationship diagram, or ERD, for a system to manage
electronic resources. An ERD is a model that identifies the concepts or entities that exist
in a system and the relationships beteen those entities. An ERD is often used as a ay
to !isuali"e a relational database# each entity represents a database table, and the
relationship lines represent the $eys in one table that point to specific records in related
tables. ERDs may also be more abstract, not necessarily capturing e!ery table needed
ithin a database, but ser!ing to diagram the ma%or concepts and relationships. This
ERD is of the latter type, intended to present an abstract, theoretical !ie of the ma%or
entities and relationships needed for management of electronic resources. &t may assist
the database design process for an e-resource management system, but does not identify
e!ery table that ould be necessary for an electronic resource management database.
This ERD should be examined in close consultation ith other components of the Report
of the DLF Electronic Resource Management Initiative, especially Appendix E 'Data
Element Dictionary( and Appendix ) 'Data *tructure(. The ERD presents a !isual
representation of e-resource management concepts and the relationships beteen them.
The Data Element Dictionary identifies and defines the indi!idual data elements that an
e-resource management system must contain and manage, but lea!es the relationship
beteen the elements to be inferred by the reader. The Data *tructure associates each
data element ith the entities and relationships defined in the ERD. Together, these three
documents form a complete conceptual data model for e-resource management.
Understanding the Model
There are se!eral different modeling systems for entity relationship diagramming. This
ERD is presented in the &nformation Engineering style. Those unfamiliar ith entity
relationship diagramming or unfamiliar ith this style of notation may ish to consult
the folloing section to clarify the diagramming symbology.
Entities
Entities are concepts ithin the data model. Each entity is represented by a box ithin
the ERD. Entities are abstract concepts, each representing one or more instances of the
concept in +uestion. An entity might be considered a container that holds all of the
instances of a particular thing in a system. Entities are e+ui!alent to database tables in a
relational database, ith each ro of the table representing an instance of that entity.
Remember that each entity represents a container for instances of the thing in +uestion.
The diagram belo has an entity for student and another for school. This indicates
that the system being modeled may contain one or more students and one or more
schools.
STUDENT SCHOOL
*o far, no relationship beteen students and schools has been indicated.
Relationships
Relationships are represented by lines beteen entities. Relationship lines indicate that
each instance of an entity may ha!e a relationship ith instances of the connected entity,
and !ice !ersa.
STUDENT SCHOOL
The diagram abo!e no indicates that students may ha!e some relationship ith schools.
,ore specifically, there may be a relationship beteen a particular student 'an instance of
the student entity( and a particular school 'an instance of the school entity(.
&f necessary, a relationship line may be labeled to define the relationship. &n this case,
one can infer that a student may attend a school, or that a school may enroll students. -ut
if necessary, this relationship could be labeled for clarification#
STUDENT SCHOOL
attends/
enrolls
Read the first relationship definition, attends, hen tracing the relationship left to right
or top to bottom. Read the second definition, enrolls, hen tracing the relationship
right to left or bottom to top.
Optionality and Cardinality
*ymbols at the ends of the relationship lines indicate the optionality and the cardinality of
each relationship. .ptionality expresses hether the relationship is optional or
mandatory. /ardinality expresses the maximum number of relationships.
As a relationship line is folloed from an entity to another, near the related entity to
symbols ill appear. The first of those is the optionality indicator. A circle ' (
indicates that the relationship is optional0the minimum number of relationships beteen
each instance of the first entity and instances of the related entity is "ero. .ne can thin$
of the circle as a "ero, or a letter . for optional. A stro$e ' 1 ( indicates that the
relationship is mandatory0the minimum number of relationships beteen each instance
of the first entity and instances of the related entity is one.
The second symbol indicates cardinality. A stro$e ' 1 ( indicates that the maximum
number of relationships is one. A cros-foot ' ( indicates that many such
relationships beteen instances of the related entities might exist.

The folloing diagram indicates all of the possible combinations#
A
A
A
A
B
B
B
B
Each instance of A is related to a minimum of
zero and a maximum of one instance of B
Each instance of B is related to a minimum of
one and a maximum of one instance of A
Each instance of A is related to a minimum of
one and a maximum of man instances of B
Each instance of B is related to a minimum of
zero and a maximum of man instances of A
&n our model, e ish to indicate that each school may enroll many students, or may not
enroll any students at all. 2e also ish to indicate that each student attends exactly one
school. The folloing diagram indicates this optionality and cardinality#
SCHOOL
STUDENT
Each school enrolls
at least zero
and at most many
students
Each student attends
at least one
and at most one
school
&t is important to note that relationship optionality and cardinality constraints apply
specifically to the system being modeled, not to all possible systems. According to the
example modeled abo!e, a school might not enroll any students0that relationship is
optional. A school ithout students is not much of a school, and indeed if the system
being modeled ere a school system enrollment database, the relationship ould
probably be mandatory. 3oe!er, if the system being modeled is an extracurricular
honors program, there may be schools that ha!e no students currently participating in the
program. /onsider the function of the system and consult the other documents in the data
model to clarify modeling decisions.
Bridge Entities
2hen an instance of an entity may be related to multiple instances of another entity and
!ice !ersa, that is called a many-to-many relationship. &n the example belo, a
supplier may pro!ide many different products, and each type of product may be offered
by many suppliers#
SU!!L"E# !#ODUCT
$ro%ides/
offered &
2hile this relationship model is perfectly !alid, it cannot be translated directly into a
relational database design. &n a relational database, relationships are expressed by $eys in
a table column that point to the correct instance in the related table. A many-to-many
relationship does not allo this relationship expression, because each record in each table
might ha!e to point to multiple records in the other table.
&n order to build a relational database that captures this relationship, it is necessary to
build a bridge beteen the to entities that uni+uely expresses each relationship instance.
This can be modeled in an ERD ith a bridge entity, an entity box containing a
diamond, hich may replace the many-to-many relationship. 'The diamond is used in
other ER modeling systems to indicate relationships, or may be !ieed as the %oining0
the bridge0of the many-to-many cros-feet(.
SU!!L"E# !#ODUCT
!#O'"DES/
O((E#ED B)
This diagram expresses the same relationship as the diagram abo!e. Each instance of the
pro!ides bridge entity indicates that a certain supplier can pro!ide a certain product.
&n addition to explicitly depicting a relational database structure that can capture a many-
to-many relationship, the bridge entity has an additional function in abstract entity-
relationship modeling# A bridge entity may capture attributes that are specific to the
relationship beteen instances of the bridged entities. &n the supplier and product
example, a product does not ha!e an inherent cost4 it only has a cost in relation to the
supplier ho sells it. *imilarly, a supplier may not ha!e a uniform deli!ery time4
deli!ery times may !ary in relation to the product being deli!ered. Any attributes that are
dependent on the relationship ould be associated ith the relationship5s bridge entity.
Recursive Relationships
&nstances of entities may ha!e relationships ith other instances of the same entity.
These relationships may be dran ith relationship lines that begin and end connected to
the same entity. /ommon occurrences of these recursi!e relationships include
parent6child relationships#
!E#SON
father of/
child of
The diagram abo!e indicates that a person may be the father of "ero or many persons, and
that a person may ha!e "ero or one father. '7ot e!ery person5s father ill be recorded in
the system, so the relationship is modeled as optional(.
Multiple Relationships Between Entities
An entity may ha!e multiple relationships ith another entity. These are depicted in the
ERD ith multiple relationship lines connecting the to entities
E*!LO)EE CL"ENT
sales$erson
customer ser%ice re$
The diagram abo!e indicates that an employee may be the salesperson assigned to "ero or
many clients, and an employee may be the customer ser!ice representati!e for "ero or
many clients. Each client has exactly one salesperson and exactly one customer ser!ice
representati!e. Each client5s salesperson may or may not be the same employee as the
client5s customer ser!ice representati!e4 each relationship is treated independently.
Entity u!types
There are times hen it is con!enient to depict relationships that apply to an entire class
of things, as ell as depict relationships that apply only to certain types of the larger
class. Entity subtypes accommodate these relationship depictions. &n the ERD, entity
subtypes may be depicted by entity boxes shon ithin larger entity boxes. The large
entity represents the class, and the smaller boxes depict the subtypes.
"N'ENTO#)
!A#T
'EH"CLE *ODEL
*(+,
LOCAT"ON
The example abo!e depicts an in!entory entity, ith the subtypes of !ehicle and
part. A !ehicle has one or many parts, and e!ery part is associated ith one and only
one $ind of !ehicle 'according to this diagram, there are no interchangeable components(.
All items in in!entory, hether they are !ehicles or parts, ha!e a manufacturing location,
but only !ehicles are of a particular model.
E"clusive#Or Relationship
&f an entity instance may ha!e either one relationship or another, but not both, the
constraint may be modeled ith an exclusi!e-or relationship, represented as a tree ith a
solid dot here the tree branches. The folloing diagram indicates that each con!ict is
assigned to a prison, or to a parole officer, but not both#
CON'"CT
!#"SON
!A#OLE
O(("CE#
Entity Relationship Diagram for Electronic Resource Management
The folloing diagram is the complete Entity Relationship Diagram for Electronic
Resource ,anagement. &t presents an abstract, theoretical !ie of the ma%or entities and
relationships needed for management of electronic resources#
ELECT#ON"C !#ODUCT
!#"NT 'E#S"ON
-O#.
E/#ESOU#CE
AC0U"S"T"ON USE#+#OU!
A'A"LABLE TO
L"CENSE
L"B#A#)
CONSO#T"AL
!A#T"C"!AT"ON
O#+AN"1AT"ON
is licensee
$u&lishes
$ro%ides
%ends
includes/
is $art of
TE#*S DE("NED
E/!#ODUCT/
L"CENSE
ne2otiates
ACCESS
"N(O
AD*"N
"N(O
is licensor
LOCAT"ON
A'A"LABLE AT
CONSO#T"U*
!A#TNE#L"B#A#)
"NTE#(ACE
deli%ers
-O#.(LO-#ULES
CONTACT
!#OCESS"N+
-O#.(LO-
T#"AL
!#E'A"L"N+TE#*S
CONTACT
#ES!ONS"B"L"T"ES
ne2otiates
L"B#A#)
!A#T"C"!AT"ON
Additional Inheritance onstraints
8nli$e other modeling systems, entity-relationship diagrams do not explicitly depict situations in
hich entity instances are expected to inherit attributes or relationships of related entity
instances.
This data model assumes the folloing relationship inheritance constraints#
An e-resource may inherit its interface5s relationship ith an ac+uisition, administrati!e
information, or access information. Alternati!ely, the e-resource may ha!e a separate ac+uisition
administrati!e information, and6or access information from its interface.
An e-resource must inherit its interface5s relationship or relationships ith licenses 'and ith
the terms defined by the interface5s licenses0although different terms from a different license
may pre!ail for the e-resource(.
An e-resource may inherit its parent e-resource5s relationship ith an ac+uisition,
administrati!e information, or access information. Alternati!ely, the child e-resource may ha!e
a separate ac+uisition administrati!e information, and6or access information from its parent.
An e-resource must inherit its parent e-resource5s relationship or relationships ith licenses
'and ith the terms defined by the parent5s licenses0although different terms from a different
license may pre!ail for the child e-resource(.
Explanation of omplex Relationships or oncepts
Although the o!erall diagram is large and complex, most of the entities and relationships
depicted in the ERD are relati!ely straightforard, and can be fully understood in consultation
ith the definitions pro!ided in Appendix E 'Data Element Dictionary( and Appendix ) 'Data
*tructure(.
*e!eral of the relationships depicted merit further explanation.
Electronic $roduct and its u!types
The electronic product entity represents electronic things that may be ac+uired, licensed, or
managed. Electronic product encompasses interfaces, e-resource pac$ages, pac$ages of
pac$ages, and indi!idual e-resource titles.
ELECT#ON"C !#ODUCT
E/#ESOU#CE
"NTE#(ACE
deli%ers
,any attributes and relationships are shared by all electronic products, regardless of hether the
e-product is an interface, pac$age, or indi!idual title. )or example, all types of e-products may
be licensed, may be ac+uired, may undergo a product trial, etc. .n the other hand, interfaces and
e-resources do ha!e some uni+ue characteristics and in certain cases need to be handled in
distinct ays. The electronic product entity and its subtypes accommodate the depiction of these
relationships.
E#Resource Recursive Relationship
The e-resource entity represents e-resource pac$ages, pac$ages of pac$ages, and indi!idual e-
resource titles. Any gi!en e-resource title may be a standalone product, or may be a part of an e-
resource pac$age. An e-resource pac$age could in turn be part of a larger pac$age. These
possible relationships are accommodated ith the optional recursi!e relationship for e-resources#
E/#ESOU#CE
includes/
is $art of
%he Organi&ation Entity
The organi"ation entity represents any business, !endor, pro!ider, publisher, licensor, etc. ith
hich a library does business related to electronic products. 9enerally, one records the same
attributes of an organi"ation, such as name and address, regardless of the role the organi"ation
plays. )urthermore, a single organi"ation fre+uently fills se!eral roles in the e-resource
management en!ironment, functioning as !endor, licensor, publisher, and6or pro!ider.
Rather than create separate entities for each role, hich may contain duplicate instances of one
another, the model contains the single organi"ation entity, ith the role or roles of the
organi"ation dependent on the relationship or relationships in hich the organi"ation
participates#
O#+AN"1AT"ON
is licensee
$u&lishes
$ro%ides
%ends
ne2otiates
is licensor
ne2otiates
)or definitions of the roles indicated by these relationships, see Appendix E 'Data Element
Dictionary( and Appendix ) 'Data *tructure(.
%erms Defined and $revailing %erms
Each license and each ac+uisition defines 'or may define( a set of associated rights and
restrictions on the usage and management of the e-products co!ered by the license or ac+uisition.
&n some cases, certain terms are defined in licenses, hile in other agreements those same term
concepts might be defined in the business agreement. To accommodate the uncertainty of here
certain rights, responsibilities, and other terms might be defined in any gi!en situation, e ha!e
modeled a separate terms defined entity#
AC0U"S"T"ON
L"CENSE
TE#*S DE("NED
The terms defined entity is able to record all possible rights, responsibilities, and other terms,
including terms that are typically defined in licenses 'such as interlibrary loan or scholarly
sharing permissions(, as ell as terms that are typically defined in ac+uisitions or business
terms 'such as number of concurrent users(.
Each ac+uisition may define at most one terms defined instance. Each license may define at
most one terms defined instance. Each terms defined instance is defined either by one
ac+uisition or by one license4 this relationship is modeled using the exclusi!e-or relationship.
8se, rights, and restrictions for any gi!en electronic resource may be go!erned by multiple
agreements, both legal license terms and negotiated ac+uisition terms. Each ac+uisition defines
one set of terms, and each license defines one set of terms. Through each e-product5s
relationship ith an ac+uisition and its relationship ith one or more licenses, one can find all of
the terms defined instances that apply to each e-resource.
&t may occur that among se!eral terms defined instances that apply to a gi!en e-product, some of
the indi!idual terms are in conflict4 this is especially li$ely in situations here multiple license
agreements co!er a single e-product. &n such cases it is necessary to determine hich of the
conflicting terms pre!ail for the e-product in +uestion. This is modeled ith the pre!ailing terms
entity, and its relationships ith the terms defined entity#
ELECT#ON"C !#ODUCT
TE#*S DE("NED
!#E'A"L"N+ TE#*S
The pre!ailing terms entity represents all possible terms, %ust as the terms defined entity does,
but for each term merely points to the terms defined entity that pre!ails. The three relationships
lines depicted in the draing actually represent many relationships# one for each defined term.
*o hile each electronic product may be go!erned by many different ac+uisitions and licenses
that define terms, each electronic product is go!erned by at most one complete set of pre!ailing
terms.
onclusions
This entity-relationship diagram depicts the ma%or concepts and relationships needed for
managing electronic resources. &t is neither a complete data model depicting e!ery necessary
relational database table, nor is it meant to be a proscripti!e design for implementations of
electronic resource management systems. Alternate models may capture the necessary attributes
and relationships. 3opefully this document, along ith the other components of the Report of
the DLF Electronic Resource Management Initiative ill assist de!elopers ith en!isioning the
complexity of the en!ironment that an ER, system must address, and ensure that crucial
relationships and features ill be included in ER, products.