Modeling Data in the Organization

1
A Good Business Rule is:
 Declarative – what, not how
 Precise – clear, agreed-upon meaning
 Atomic – one statement
 Consistent – internally and externally
 Expressible – structured, natural language
 Distinct – non-redundant
 Business-oriented – understood by
business people

2
A Good Data Name is:
 Related to business, not technical,
characteristics
 Meaningful and self-documenting
 Unique
 Readable
 Composed of words from an approved list
 Repeatable

Chapter 3 3
 Overview of db design
 Requirement analysis
– Data to be stored
– Applications to be built
– Operations (most frequent) subject to performance requirement
 Conceptual db design
– Description of the data (including constraints)
– By high level model such as ER
 Logical db design
– Choose DBMS to implement
– Convert conceptual db design into database schema
 Beyond ER design
 Schema refinement (normalization)
 Physical db design
– Analyze the workload
– Refine db design to meet performance criteria (focus on Indexing)
 Security design

4
A
simplified
diagram to
illustrate
the main
phases of
database
design.

Chapter 3 5
Conceptual design
 Issues to consider: (ER Model is used at this stage.)
 What are the entities and relationships in the enterprise?
 What information about these entities and relationships
should we store in the database (i.e., attributes)?
 What are the integrity constraints or business rules that
hold?
 Solution:
 Can map an ER diagram into a relational schema.

Chapter 3 6
 E-R Model Constructs
 Entities:
 Entity instance–person, place, object, event, concept (often corresponds to a
row in a table)
 Entity Type–collection of entities (often corresponds to a table)

 Relationships:
 Relationship instance–link between entities (corresponds to primary key-
foreign key equivalencies in related tables)
 Relationship type–category of relationship…link between entity types

 Attribute – property or characteristic of an entity or relationship type (often

corresponds to a field in a table)

Chapter 3 7
 ER Model Concepts
 Entities and Attributes
 Entities are specific objects or things in the mini-
world that are represented in the database.
 For example the EMPLOYEE John Smith, the Research
DEPARTMENT, the Airline Client
OR
 Entities are Real-world object distinguishable from other objects.
An entity is described (in DB) using a set of
attributes.
name
ssn address

Employee
Chapter 3 8
Sample E-R Diagram (Figure 3-1)

9
Basic E-R notation (Figure 3-2)

Entity
Attribute
symbols
symbols

A special entity
that is also a Relationship
relationship symbols

Relationship
degrees specify
number of
entity types Relationship
involved cardinalities
specify how
many of each
entity type is
allowed
10
Figure 3-4 Example of inappropriate entities

System System
user Inappropriate output
entities

Appropriate
entities
Chapter 3
ER Model Concepts
 Attributes
 Are properties used to describe an entity.
 For example an EMPLOYEE entity may have a
Name, SSN, Address, Sex, BirthDate
 A specific entity will have a value for each of its
attributes.
 For example a specific employee entity may have
Name='John Smith', SSN='123456789', Address ='731,
Fondren, Houston, TX', Sex='M', BirthDate='09-JAN-55‘
 Each attribute has a value set (or data type)
associated with it – e.g. integer, string, subrange,
enumerated type, …
Chapter 3 12
 Types of Attributes (1)
 Simple
 Each entity has a single atomic value for the attribute. For example,
SSN or Email.
 Composite
 The attribute may be composed of several components.
components For example,
 Address (Apt#, House#, Street, City, State, ZipCode, Country)
 Name (FirstName, MiddleName, LastName).
 Composition may form a hierarchy where some components are
themselves composite.
 Multi-valued
 An entity may have multiple values for that attribute. For example,
 Color of a CAR (Blue, White, ..)
 PreviousDegrees of a STUDENT.
 Denoted as {Color} or {PreviousDegrees}.

Chapter 3 13
 Types of Attributes (2)
 In general, composite and multi-valued attributes
may be nested arbitrarily to any number of levels
although this is rare. E.g.
 PreviousDegrees of a STUDENT is a composite multi-
valued attribute denoted by {PreviousDegrees (College,
Year, Degree, Field)}.
 Address

Chapter 3 14
Figure 3-7 A composite attribute

An attribute
broken into
component parts

Figure 3-8 Entity with multivalued attribute (Skill)

and derived attribute (Years_Employed)

Multivalued
an employee can have
Derived
more than one skill
from date
employed and
current date
15
Entity Types and Key Attributes
 Entities with the same basic attributes are grouped or typed into an entity
type.
type For example, the EMPLOYEE entity type or the PROJECT entity type.

Entity Set: A collection of similar entities. E.g., all employees.

 An attribute of an entity type for which each entity must have a unique value is
called a key attribute of the entity type. For example, SSN of EMPLOYEE.
 A key attribute may be composite. For example, VehicleTagNumber is a key of
the CAR entity type with components (Number, State).
 An entity type may have more than one key. For example, the CAR entity type
may have two keys:
 VehicleIdentificationNumber (popularly called VIN) and
 VehicleTagNumber (Number, State), also known as license_plate number.

Chapter 3 16
Identifiers (Keys)
 Identifier (Key) –An attribute (or combination
of attributes) that uniquely identifies individual
instances of an entity type
 Simple versus Composite Identifier
 Candidate Identifier/Key –an attribute that
could be a key…satisfies the requirements for
being an identifier

Chapter 3 17
Identifiers / Key
 A key is a minimal set of attributes whose
values uniquely identify an entity in the
set.
 Candidate key.
 Primary key.

Chapter 3 18
Characteristics of Identifiers/Keys
 Will not change in value
 Will not be null
 No intelligent identifiers (e.g., containing locations or
people that might change)
 Substitute new, simple keys for long, composite keys

Chapter 3 19
Figure 3-9 Simple and composite identifier attributes

The identifier is boldfaced and underlined

20
Figure 3-19 Simple example of time-stamping

This attribute
that is both
multivalued and
composite

21
ENTITY SET corresponding to the
ENTITY TYPE CAR

Chapter
22 3
 Entity, Entity Set, Attribute, and
Schema
ID or SSN Name UserID Age GPA
999-38-4431 John Smith jsmith 21 3.68

999-28-3341 Miki Jordan mjordan 28 3.45

331-43-4567 David Kim dkim 25 4.00

535-34-5678 Paul Lee plee 26 3.89

Chapter 3 23
 Entity
Entity is basically a single
ROW in the table.

Attributes
Attributes are columns in
the database table

Identify Entity, Entity Set and Attributes

Chapter 3 24
 More on Relationships
 Relationship Types vs. Relationship Instances
 The relationship type is modeled as lines between entity types…
the instance is between specific entity instances
 Relationships can have attributes
 These describe features pertaining to the association between the entities in
the relationship
 Two entities can have more than one type of relationship
between them (multiple relationships)
 Associative Entity –combination of relationship and
entity

Chapter 3 25
 Figure 3-10 Relationship types and instances

a) Relationship type

b) Relationship
instances

26
 Example of Keys

Primary key Candidate key

999-21-3415, jsmith@, John Smith, 18, 3.5

999-31-2356, jzhang@, Jie Zhang, 20, 3.0
999-32-1234, ajain@, Anil Jain, 21, 3.8

Chapter 3 27
 Relationship vs. Relationship Set

John Smith

(999-21-3415, jsmith@, John Smith, 18, 3.5)

Relationship

ITCS3160

(3160, ITCS, DBMS, J. Fan, 3, Kenn. 236)

Chapter 3 28
 Relationship vs. Relationship Set
999-21-3415, jsmith@, John Smith, 18, 3.5 Students
999-31-2356, jzhang@, Jie Zhang, 20, 3.0
999-32-1234, ajain@, Anil Jain, 21, 3.8

Relationship set(“Enrolled in”)

3160, ITCS, DBMS, J. Fan, 3, Kenn. 236 Courses

6157, ITCS, Visual DB, J. Fan, 3, Kenn. 236

Chapter 3 29
Example 1
 Build an ER Diagram for the following
information:
 Students
 Have an Id, Name, Login, Age, GPA
 Courses
 Have an Id, Name, Credit Hours
 Students enroll in courses
 Receive a grade

Chapter 3 30
Example 1 Answer
Name Login Age Id Name Credit

Id GPA
Students Courses

Enrolled_In

Grade

Chapter 3 31
Example 2
 Build an ER Diagram for the following
information:
 Patients
 Name, Address, Phone #, Age
 Drugs
 Name, Manufacturer , Expiration Date
 Patients are prescribed drugs
 Dosage, # Days

Chapter 3 32
Example 2 Answer

Name Addr Phone Name Manuf Exp

Age
Patients Drug

Prescribed

Dosage #days

Chapter 3 33
Degree of Relationships
 Degree of a relationship is the number of
entity types that participate in it
 Unary Relationship
 Binary Relationship
 Ternary Relationship

Chapter 3 34
Degree of relationships – from Figure 3-2

Entities of
One entity two different
related to types related
another of to each other Entities of three
the same different types
entity type related to each
other
35
Cardinality of Relationships
 One-to-One
 Each entity in the relationship will have exactly one related
entity
 One-to-Many
 An entity on one side of the relationship can have many
related entities, but an entity on the other side will have a
maximum of one related entity
 Many-to-Many
 Entities on both sides of the relationship can have many
related entities on the other side

Chapter 3 36
 Potential Relationship Types

1-to-1 1-to Many Many-to-1 Many-to-Many

Chapter 3 37
Many-to-one (N:1) RELATIONSHIP
EMPLOYEE WORKS_FOR DEPARTMENT

r1
e1   d1
r2
e2 

e3 r3  d2


e4  r4
 d3
e5  r5
e6 
r6
e7 
r7

Chapter
38 3
Many-to-many (M:N) RELATIONSHIP

Chapter 3 39
 Cardinality Constraints
 Cardinality Constraints -
 the number of instances of one entity that can or must
be associated with each instance of another entity
 Minimum Cardinality
 If zero, then optional
 If one or more, then mandatory
 Maximum Cardinality
 The maximum number

Chapter 3 40
Figure 3-12 Examples of relationships of different degrees

a) Unary relationships

41
Figure 3-12 Examples of relationships of different degrees (cont.)

b) Binary relationships

42
Figure 3-12 Examples of relationships of different degrees (cont.)

c) Ternary relationship

Note: a relationship can have attributes of its own

43
Figure 3-17 Examples of cardinality constraints

a) Mandatory cardinalities

A patient history is A patient must have recorded

recorded for one and at least one history, and can
only one patient have many

44
Figure 3-17 Examples of cardinality constraints (cont.)

b) One optional, one mandatory

A project must be An employee can be assigned

assigned to at least one to any number of projects, or
employee, and may be may not be assigned to any
assigned to many at all

45
Figure 3-17 Examples of cardinality constraints (cont.)

a) Optional cardinalities

A person is is
married to at most
one other person,
or may not be
married at all

46
Figure 3-21 Examples of multiple relationships

a) Employees and departments

Entities can be related to one another in more than one way

47
Figure 3-21 Examples of multiple relationships (cont.)

b) Professors and courses (fixed lower limit constraint)

Here, min
cardinality
constraint is 2

48
Participation Constraints
 The participation constraint specifies whether the
existence of an entity depends on its being related
to another entity via the relationship type.
 The constraint specifies the minimum number of
relationship instances that each entity can
participate in.
 There are two types of participation constraints:
 Total
 Partial

Chapter 3 49
Types of Participation Constraints
 Total:
 If an entity can exist, only if it participates in at least one
relationship instance, then that is called total participation,
meaning that every entity in one set, must be related to at least
one entity in a designated entity set.
 An example would be the Employee and Department
relationship. If company policy states that every employee
must work for a department, then an employee can exist only
if it participates in at lest one relationship instance (i.e. an
employee can’t exist without a department)
 It is also sometimes called an existence dependency.
 Total participation is represented by a double line, line going
from the relationship to the dependent entity.
Chapter 3 50
Types of Participation Constraints
 Partial:
 If only a part of the set of entities participate in a
relationship, then it is called partial participation.
 Using the Company example, every employee will
not be a manager of a department,
so the participation of an employee in the
“Manages” relationship is partial.
partial
 Partial participation is represented by a single line.

Chapter 3 51
Participation Constraints
 Every “did” value in Departments table must appear in a row
of the Manages table (with a non-null ssn value!)

since
name dname
ssn lot did budget

Employees Manages Departments

Partial Total w/key
constraint
Total
Works_In
Total

since

Chapter 3 52
Attributes of Relationship Types
 Relationships can have attributes similar to entity types.
 For example, in the relationship Works_On, between the
Employee entity and the Department entity we would like to keep
track of the number of hours an employee works on a project.
Therefore we can include “Number_of_ Hours” as an attribute of
the relationship.
 Another example is for the “manages” relationship between
employee and department, we can add “Start_Date” as an
attribute of the Manages relationship.
 For some relationships (1:1, or 1:N), the attribute can be
placed on one of the participating entity types.
 For example the “Manages” relationship is 1:1, StartDate can
either be migrated to Employee or Department.

Chapter 3 53
Weak Entity
“An entity set may not have sufficient attributes to
form a PRIMARY KEY and is fully existent
dependant on Strong Entity. Such entity set is termed
as WEAK ENTITY SET”.

An entity set that has a PRIMARY KEY is termed as

a STRONG Entity Set

Chapter 3 54
Weak Entity Types
 An entity that does not have a key attribute
 Entities that belong to a weak entity type are identified by being
related to specific entities from another entity type in combination
with one of their attribute values.
 This entity type is called an identifying or owner entity type.
 The relationship that relates the identifying entity type with the weak entity
type is called an identifying relationship.

Example:
Suppose that a DEPENDENT entity is identified by the dependent’s first name
and birhtdate, and the specific EMPLOYEE that the dependent is related to.
DEPENDENT is a weak entity type with EMPLOYEE as its identifying entity
type via the identifying relationship type DEPENDENT_OF

Chapter 3 55
Weak Entity Types
 A weak entity must participate in an identifying relationship type
with an owner or identifying entity type
 A weak entity type always has a total participation constraint with respect
to the identifying relationship, because a weak entity cannot exist without
its owner.
 Not all existence dependencies (Total participation ) result in a
weak entity type; if an entity has a key attribute then it is not a
weak entity.
 A weak entity type usually has a partial key, which is the set of
attributes that can uniquely identify weak entities that are related
to the same owner entity
 Entities are identified by the combination of:
 A partial key of the weak entity type
 The particular entity they are related to in the identifying
entity type

Chapter 3 56
Example - Weak Entity Types (1)
 For example, lets assume in a library database, we have an
entity type Book.
Book For each book, we keep track of the
author, ISBN, and title. The library may own several
copies of the same book, and for each copy,
copy it keeps track
of the copy number (a different copy number for each
copy of a given book) and price of each copy.

Chapter 3 57
 Example - Weak Entity Types (1)
 Because the copy number is only unique for each book (meaning
Book 123 may have copy 1, copy 2, copy 3, and book 456 may
also have copy 1, copy 2 and copy 3) and not for all copies of all
books, it cannot be considered unique for each copy.
 Therefore because the Copy entity does not have a key attribute,
it is considered a weak entity type, an is identified by being
related to the Book entity.
entity The book entity is the identifying
entity, and the relationship is the identifying relationship.
 Because a copy cannot exist without the owner (Book) the Copy
entity type has a total participation constraint with respect to the
identifying relationship.
 The partial key of the Copy entity is Copy Number, for each
owner entity Book, the Copy Number uniquely identifies the
copy.

Chapter 3 58
SUMMARY OF
ER-DIAGRAM
NOTATION
FOR ER
SCHEMAS

Chapter 3 59
 An ER schema diagram for the
COMPANY database.

ER DIAGRAM – Entity Types are:

EMPLOYEE,
DEPARTMENT,
PROJECT,
DEPENDENT
Chapter 3 60
Foreign Key
 A foreign key is an attribute or combination of
attributes of an entity that is the primary key of
another entity.
entity

Chapter 3 61
Foreign Key contd..
Example:
In Faculty  Class relationship, FacID can appear
as Foregin Key in Class. As FacID is a primary Key
in faculty table.

How to identify Foreign keys?

Chapter 3 62
One to many
 “Each entity in X is associated with many
entities in Y and each entity in Y associated
with at most one entity in X”.

. .
. .
. .

Chapter 3 63
One to many

Smith . . JAVA
Jane . . C++
Kyle . . Databases

Foreign Key will be on "MANY" side

64
Many to one (Exactly same as one-many)
 “Each entity in X is associated with at most one entity in Y and
each entity in Y associated with many entities in X”.

.
. .
. .
. .
.

Chapter 3 65
Many to one

.
. .
. .
. .
.

Foreign Key will be on "MANY" side

Chapter 3 66
Many to many
 “Each entity in X is associated with many entities in Y and each
entity in Y associated with many entities in X”.

. .
. .
. .
. .
. .

Chapter 3 67
 Many to many

. .
. .
. .
. .
. .

Chapter 3 68
Many to many
For Many to many relationship
we make a bridge table.
table
 That contains PRIMARY Keys
 of both sides
 Along some extra required attributes

Chapter 3
 One to one
 If each entity is associated with at most one entity.
 “Each entity in X is associated with at most one entity in Y and
each entity in Y associated with at most one entity in X”.

S101 M_01
S102 M_02
S103 M_03

Chapter 3 70
 For ONE to ONE Relationship
if one side is optional
then Foreign Key will be on
optional side

71
One-to-One Relationships
One employee has one employment history; no
others have same history

Employee 1:1 EmpHistory

In This case FK will be on the Optional Side

Chapter
72 3
 One-to-Many Relationships
One building can have many apartments, but
one apartment is only in one building

Building 1:N Apartment

Where FK will be???

73
One-to-Many Relationships
One department can have many projects

Dept. 1:N Projects

Customer. 1:N Phone

Numbers

Where FK will be???

Chapter 3 74
Weak Entity (once again)
Example:
Case: Payments of loan.

Consider the entity set “PAYMENT”, which has three

attributes: payment_number, payment_date,
Payment_amount

This entity set (PAYMENT) does not have a

PRIMARY KEY; it is a week entity set
Chapter 3 75
 Weak Entity (once again)

One to Many (Loan – Payment)

pay-date
Loan-No Amount
pay-num
amount

loan LP payment

Chapter 3 76
Weak Entity (once again)

Identifying Relationship

loan R payment

Must be part of many-to-one relationship

with strong entity set.

Chapter
77 3
Weak Entity (once again)
1:N
1:N

loan R payment

Where will be Foreign key???

Chapter
78 3
Relationships and Relationship Types (3)
 We can also have a recursive relationship type.
 Both participations are same entity type in different roles.
roles
 For example, SUPERVISION relationships between
EMPLOYEE (in role of supervisor or boss) and (another)
EMPLOYEE (in role of subordinate or worker).
 In ER diagram, need to display role names to distinguish
participations.

Chapter 3 79
A RECURSIVE RELATIONSHIP
SUPERVISION
EMPLOYEE SUPERVISION

e1 2

1 r1
e2 2
 1
r2
e3 2

1
e4  2 r3
1
e5 1

2 r4
e6 1


2 r5
e7 
In figure, first role participation labeled with 1
and second role participation labeled with 2. r6
Chapter
80 3
Recursive Relationship Type is: SUPERVISION
(participation role names are shown)

Chapter
81 3
Structural Constraints –
one way to express semantics of relationships
Structural constraints on relationships:
 Cardinality ratio (of a binary relationship): 1:1, 1:N,
N:1, or M:N
SHOWN BY PLACING APPROPRIATE NUMBER ON
THE LINK.
 Participation constraint (on each participating
entity type): total (called existence dependency) or
partial.
SHOWN BY DOUBLE LINING THE LINK
NOTE: These are easy to specify for Binary
RelationshipTypes.
Chapter 3 82
Alternative (min, max) notation for
relationship structural constraints:
 Specified on each participation of an entity type E in a relationship type R
 Specifies that each entity e in E participates in at least min and at most
max relationship instances in R
 Default(no constraint): min=0, max=n
 Must have minmax, min0, max 1
 Derived from the knowledge of mini-world constraints

Examples:
 A department has exactly one manager and an employee can manage at
most one department.
– Specify (0,1) for participation of EMPLOYEE in MANAGES
– Specify (1,1) for participation of DEPARTMENT in MANAGES
 An employee can work for exactly one department but a department can
have any number of employees.
– Specify (1,1) for participation of EMPLOYEE in WORKS_FOR
– Specify (0,n) for participation of DEPARTMENT in WORKS_FOR

Chapter 3 83
The (min,max) notation relationship
constraints

(0,1) (1,1)

(1,1) (1,N)

Chapter 3 84
COMPANY ER Schema Diagram
using (min, max) notation

Chapter 3 85
Data Modeling Tools
 A number of popular tools that cover conceptual
modeling and mapping into relational schema design.
Examples: ERWin, S- Designer (Enterprise
Application Suite), ER- Studio, etc.
POSITIVES: serves as documentation of application
requirements, easy user interface - mostly graphics editor
support

Chapter 3 86
Problems with Current Modeling Tools
 DIAGRAMMING
 Poor conceptual meaningful notation.
 To avoid the problem of layout algorithms and aesthetics
of diagrams, they prefer boxes and lines and do nothing
more than represent (primary-foreign key) relationships
among resulting tables.(a few exceptions)
 METHODOLGY
 lack of built-in methodology support.
 poor tradeoff analysis or user-driven design preferences.
 poor design verification and suggestions for improvement.

Chapter 3 87
 Some of the Currently Available Automated Database
Design Tools

COMPANY TOOL FUNCTIONALITY

Embarcadero ER Studio Database Modeling in ER and IDEF1X
Technologies
DB Artisan Database administration and space and security
management
Oracle Developer 2000 and Database modeling, application development
Designer 2000
Popkin Software System Architect 2001 Data modeling, object modeling, process modeling,
structured analysis/design
Platinum Platinum Enterprice Data, process, and business component modeling
Technology Modeling Suite: Erwin,
BPWin, Paradigm Plus
Persistence Inc. Pwertier Mapping from O-O to relational model

Rational Rational Rose Modeling in UML and application generation in C++

and JAVA
Rogue Ware RW Metro Mapping from O-O to relational model

Resolution Ltd. Xcase Conceptual modeling up to code maintenance

Sybase Enterprise Application Data modeling, business logic modeling

Suite
Visio Visio Enterprise Data modeling, design and reengineering Visual Basic
Chapter 3 88 and Visual C++
 PROBLEM with ER notation
 The ER Model in its original form did not support
 SPECIALIZATION
 GENERALIZATION ABSTRACTIONS
 AGGREGATION

Chapter 3 89
Extended Entity-Relationship (EER) Model
 Incorporates Set-subset relationships
 Incorporates Specialization/Generalization Hierarchies

NEXT LECTUER ILLUSTRATES HOW THE ER

MODEL CAN BE EXTENDED WITH
- Set-subset relationships and
Specialization/Generalization Hierarchies and how to
display them in EER diagrams

Chapter 3 90
 MORE PRATICE EXAMPLES

Chapter 3 91
 Designing an ER Diagram
Consider the following set of requirements for a University database. Design an ER diagram
for this application:
 The university keeps track of each student's name, student number, social security number,
current address and phone number, permanent address and phone number, birthdate, sex,
class (freshman, graduate), major department, minor department (if any), degree program
(B.A., B.S., ... Ph.D.). Some user applications need to refer to the city, state, and zip code
of the student's permanent address and to the student's last name. Both social security
number and student number are unique for each student. All students will have at least a
major department.
 Each department is described by a name, department code, office number, office phone, and
college. Both the name and code have unique values for each department.
 Each course has a course name, description, course number, number of credits, level and
offering department. The course number is unique for each course.
 Each section has an instructor, semester, year, course, and section number. The section
number distinguishes sections of the same course that are taught during the same
semester/year; its value is an integer (1, 2, 3, ... up to the number of sections taught during
each semester).
 A grade report must be generated for each student that lists the section, letter grade, and
numeric grade (0,1,2,3, or 4) for each student and calculates his or her average GPA.
Chapter 3 92
 University ER Diagram

Degree DName DCode OfficeNumber

Name StudentID SSN
Major In
Birth date
OfficePhone
Department
Sex Student
College
Class Minor In

Address

City State Zip

Offer

CName

Grade_Report
CourseDesc
Letter Grade Instructor Year Course
CNumber
GPA
Credits
Numeric Grade Section Belong_To

SectionNumber Semester

Chapter
93 3
ER DIAGRAM FOR A BANK DATABASE

© The Benjamin/Cummings Publishing Company, Inc. 1994, Elmasri/Navathe, Fundamentals of Database Systems, Second Edition

Chapter
94 3
ER DIAGRAM FOR A BANK DATABASE
 Consider the ER model shown in previous slide for
part of BANK database. Where each bank can have
multiple branches, and each branch can have multiple
accounts and loans.
 List non weak, weak and identifying entity types
 For weak entity what is the relationship that it has with other
entities and of what type.
 List concisely the user requirements that led to this ER
schema diagram


Chapter 3 95
Figure 3-15a and 3-15b Multivalued attributes can be represented as relationships

simple

composite

96
Associative Entities
 An entity –has attributes

A relationship –links entities together
 The database relational model doesn't offer direct support to
many-to-many relationships, even though such relationships
happen frequently in normal usage.
 The solution to this problem is the creation of another table to hold
the necessary information for this relationship. This new table is
called an associative entity.
 An associative entity can be thought of as both an entity and a
relationship since it encapsulates properties from both. It is a
relationship since it is serving to join two or more entities together,
but it is also an entity since it may have its own properties.
 The associative entity must have identifiers, Primary Keys, for
both adjoining tables, but may also contain its own unique
identifier and other information about the relationship.

Chapter 3 97
 Associative Entities
 When should a relationship with attributes instead be
an associative entity?
 All relationships for the associative entity should be many to
many
 The associative entity could have meaning independent of the
other entities
 The associative entity preferably has a unique identifier, and
should also have other attributes
 The associative entity may participate in other relationships other
than the entities of the associated relationship
 Ternary relationships should be converted to associative entities

Chapter 3 98
Figure 3-11a A binary relationship with an attribute

Here, the date completed attribute pertains specifically to the

employee’s completion of a course…it is an attribute of the
relationship

99
Figure 3-11b An associative entity (CERTIFICATE)

Associative entity is like a relationship with an attribute, but it is

also considered to be an entity in its own right.

Note that the many-to-many cardinality between entities in

Figure 3-11a has been replaced by two one-to-many relationships
with the associative entity.
100
Figure 3-13c An associative entity – bill of materials structure

This could just be a relationship with

attributes…it’s a judgment call

101
 Figure 3-18 Ternary relationship as an associative entity

102
 Microsoft Visio
Notation for Pine
Valley Furniture
E-R diagram

Different modeling
software tools may have
different notation for the
same constructs

103
 END

Chapter 3 104