1. CAS CS 460/660 Entity/Relationship Model

2. Review What a DBMS offer? Efficient data organization
Efficient data retrieval
Data integrity

3. Review-the big picture
Data Modelling
Relational
E-R
Query Languages
SQL
Relational Algebra
Relational Calculus
Storing Data
File Indexes
Buffer Pool Management
Query Optimization
External Sorting
Join Algorithms
Query Plans, Cost Estimation
Data Integrity
Data Organization
Data retrieval

4. Databases Model the Real World
“Data Model” translates real world things into structures computers can store
Many models:
Relational, E-R, O-O, Network, Hierarchical, etc.
Relational (more next time)
Rows & Columns
Keys & Foreign Keys to link Relations
Students
Enrolled

5. Problems with Relational Model
CREATE TABLE Students
(sid CHAR(20),
name CHAR(20),
login CHAR(10),
age INTEGER,
gpa FLOAT)
CREATE TABLE Enrolled
(sid CHAR(20),
cid CHAR(20),
grade CHAR(2))
With complicated schemas, it may be hard for a person to understand the structure from the data definition.
Enrolled
Students

6. One Solution: The E-R Model
Instead of relations, it has:
Entities and Relationships
These are described with diagrams
both structure, notation more obvious to humans
since
lot
name
Employee
ssn
dname
budget
did
Department
Works_In

7. Steps in Database Design
Requirements Analysis
user needs; what must database do?
Conceptual Design
high level descr (often done w/ER model)
Logical Design
translate ER into DBMS data model
Schema Refinement
consistency, normalization
Physical Design
indexes, disk layout
Security Design
who accesses what, and how

8. Example: DBA for Bank of America
Requirements Specification
Determine the requirements of clients ( Database to store information about customers, accounts, loans, branches, transactions, …)
Conceptual Design
Express client requirements in terms of E/R model.
Confirm with clients that requirements are correct.
Specify required data operations
Logical Design
Convert E/R model to relational, object-based, XML-based,…
Physical Design
Specify file organizations, build indexes

9. ER Model Basics Entity:
Employees
ssn
name
lot
Entity:
Real-world thing, distinguishable from other objects.
Noun phrase (e.g., Bob Smith, Comm Ave Branch, Account 1234, etc)
Entity described by set of attributes.
Entity Set: A collection of similar entities. E.g., all employees.
All entities in an entity set have the same set of attributes. (Until we consider hierarchies, anyway!)
Each attribute has a domain. 3

10. ER Model Basics (Contd.)
since
lot
name
Employees
ssn
dname
budget
did
Departments
Works_In
Relationship: Association among two or more entities. E.g., Bob Smith works in Pharmacy department.
relationships can have their own attributes.
Verb phrases (e.g., works_at, enrolled_in, etc)
Relationship Set: Collection of similar relationships.
An n-ary relationship set R relates n entity sets E1 ... En ; each relationship in R involves entities e1  E1, ..., en  En 4

11. E/R Data Model An Example
Works_At
Employees
Branches
essn
phone
bname
bcity
since
seniority
ename
children
Entity Set
Relationship Set
Attribute
Employee
Works_For
phone
Works_For
manager
worker
Lots of notation to come.

12. E/R Data Model Types of Attributes
Works_At
Employees
Branches
essn
phone
bname
bcity
since
seniority
ename
children
Works_For
manager
worker
ename
Default
children
Multivalued
Derived
seniority

13. E/R Data Model Types of relationships
Works_At
Employees
Branches
essn
phone
bname
bcity
since
seniority
ename
children
Works_For
manager
worker
Works_For
Many-to-One (n:1)
Works_At
Many-to-Many (n:m)

14. E/R Data Model Recursive relationships
Works_At
Employees
Branches
essn
phone
bname
bcity
since
seniority
ename
children
Works_For
Recursive relationships: Must be declared with roles
manager
worker
manager
Employee
Works_For
worker

15. E/R Data Model Design Issue #1: Entity Sets vs. Attributes
An Example: Employees can have multiple phones
(b)
(a)
Uses
Employees vs
Employees
Phones
phone_no
phone_loc no
loc
To resolve, determine how phones are used
1. Can many employees share a phone?
(If yes, then (b))
2. Can employees have multiple phones?
(if yes, then (b), or (a) with multivalued attributes)
3. Else
(a), perhaps with composite attributes
Employees
phone no
loc

16. E/R Data Model Design Issue #2: Entity Sets vs. Relationship Sets
An Example: How to model bank loans
Loans
Borrows
Customers
Branches
Customers
Loans vs
cssn
cname
bname
bcity
cssn
cname
lno
amt
(a)
lno
amt
(b)
To resolve, determine how loans are issued
1. Can there be more than one customer per loan?
If yes, then (a). Otherwise, loan info must be replicated for each customer (wasteful, potential update anomalies)
2. Is loan a noun or a verb?
Both, but more of a noun to a bank. (hence (a) probably more appropriate)

17. E/R Data Model Design Issue #3: Relationship Cardinalities
An Example:
Borrows ? ?
Customers
Loans
Variations on Borrows:
1. Can a customer hold multiple loans?
2. Can a loan be jointly held by more than 1 customer?

18. E/R Data Model Design Issue #3: Relationship Cardinalities
Borrows ? ?
Customers
Loans
Cardinalities of Borrows:
Borrows
Borrows
Borrows
Borrows

19. E/R Data Model Design Issue #3: Relationship Cardinalities (cont)
In general...
1:1
n:1
1:n
n:m

20. E/R Data Model Design Issue #4: N-ary vs Binary Relationship Sets
An Example: Works_At
Works_at
Employees
Branches
Ternary:
Choose n-ary
when possible!
(Avoids redundancy,
update anomalies)
Depts
(Joe, Moody, Acct) Î Works_At vs
Binary:
WAE
WAB
Employees WA
Branches
WAD
(Joe, w3) Î WAE
(Moody, w3) Î WAB
(Acct, w3) Î WAD
Depts

21. E/R Data Model Keys
Key = set of attributes identifying individual entities or relationships
Employees
essn
ename
eaddress
ephone
A. Superkey:
any attribute set that distinguishes identities
e.g., {essn}, {essn, ename, eaddress}
B. Candidate Key:
“minimal superkey” (can’t remove attributes and preserve “keyness”)
e.g., {essn}, {ename, eaddress}
C. Primary Key:
candidate key chosen as the key by a DBA
e.g., {essn} (denoted by underline)

22. E/R Data Model Relationship Set Keys
Works_At
Employees
Branches
...
...
essn
ename
bname
bcity
since
Q: What attributes needed to represent relationships in Works_At? e1 b1 e2 b2 e3
A: {essn, bname, since}

23. E/R Data Model Relationship Set Keys (cont.)
Works_At
Employees
Branches
...
...
essn
ename
bname
bcity
since
Q: What are the candidate keys of Works_At? e1 b1 e2 b2 e3
A: {essn}

24. E/R Data Model Relationship Set Keys (cont.)
Works_At
Employees
Branches
...
...
essn
ename
bname
bcity
since
Q: What are the candidate keys if Works_At is...?
a. 1:n
A: {bname}
b. n:m
A: {essn, bname}
Assumption: employees have <= 1 record per branch
c. 1:1
A: {essn}, {bname}

25. E/R Data Model Relationship Set Keys (cont.)
General Rules for Relationship Set Keys R E1 E2
...
...
P (E1)
P (E2)
If R is: R
1:1
1:n
n:1
n:m
Candidate Keys
P (E1) or P (E2)
P (E2)
P (E1)
P (E1) È P (E2)

26. E/R Data Model Existence Dependencies and Weak Entity Sets
Idea:
Existence of one entity depends on another
Example: Loans and Loan Payments
Loan_Pmt
Payments
Loans
lno
lamt
pno
pamt
pdate
Weak Entity Set
Identifying Relationship
Total Participation

27. E/R Data Model Existence Dependencies and Weak Entity Sets
Loan_Pmt
Payments
Loans
lno
lamt
pno
pamt
pdate
Weak Entity Sets
existence of payments depends upon loans
have no superkeys: different payment records (for different loans) can be identical
instead of keys, discriminators: discriminate between payments for given loan (e.g., pno)

28. E/R Data Model Existence Dependencies and Weak Entity Sets
Loan_Pmt
Payments
Loans
lno
lamt
pno
pamt
pdate
Identifying Relationships
We say:
Loan is identifying owner in Loan_Pmt
Payment is weak entity set in Loan_Pmt
Payment is existence dependent on Loan

29. E/R Data Model Existence Dependencies and Weak Entity Sets
Loan_Pmt
Payments
Loans
lno
lamt
pno
pamt
pdate
Total Participation
All elements of Payment appear in Loan_Pmt

30. E/R Data Model Existence Dependencies and Weak Entity Sets
...
atta1
attam
attb1
...
attbn
Q. Is {attb1, …, attbn} a superkey of E2?
A: No
Q. Name a candidate key of E2
A: {atta1, attb1}

31. E/R Data Model Extensions to the Model: Specialization and Generalization
An Example:
Customers can have checking and savings accts
Checking ~ Savings (many of the same attributes)
Old Way:
Has1
Customers
Savings Accts
acct_no
balance
interest
Has2
Checking Accts
acct_no
balance
overdraft

32. E/R Data Model Extensions to the Model: Specialization and Generalization
An Example:
Customers can have checking and savings accts
Checking ~ Savings (many of the same attributes)
New Way:
acct_no
balance
Has
superclass
Customers
Accounts
Isa
Savings Accts
Checking Accts
interest
overdraft
subclasses

33. E/R Data Model Extensions to the Model: Specialization and Generalization
Subclass Distinctions:
1. User-Defined vs. Condition-Defined
User: Membership in subclasses explicitly determined (e.g., Employee, Manager < Person)
Condition: Membership predicate associated with subclasses - e.g:
Person
Isa
Child
Adult
Senior
age < 18
age³ 18
age³ 65

34. E/R Data Model Extensions to the Model: Specialization and Generalization
Subclass Distinctions:
2. Overlapping vs. Disjoint
Overlapping: Entities can belong to >1 entity set (e.g., Adult, Senior)
Disjoint: Entities belong to exactly 1 entity set (e.g., Child)
Person
Isa
Child
Adult
Senior
age < 18
age³ 18
age³ 65

35. E/R Data Model Extensions to the Model: Specialization and Generalization
Subclass Distinctions:
3. Total vs. Partial Membership
Total: Every entity of superclass belongs to a subclass e.g.,
Partial: Some entities of superclass do not belong to any subclass (e.g., if Adults condition is age³ 21 )
Person
Isa
Child
Adult
Senior
age < 18
age³ 18
age³ 65

36. E/R Data Model Extensions to the Model: Aggregation
E/R: No relationships between relationships
E.g.: Associate loan officers with Borrows relationship set
Borrows
Customers
Loans ?
Loan_Officer
Employees
Associate Loan Officer with Loan?
What if we want a loan officer for every (customer, loan) pair?

37. E/R Data Model Extensions to the Model: Aggregation
E/R: No relationships between relationships
E.g.: Associate loan officers with Borrows relationship set
Borrows
Customers
Loans
Loan_Officer
Employees
Associate Loan Officer with Borrows?
Must First Aggregate

38. E/R Data Model Summary Entities, Relationships (sets)
Both can have attributes (simple, multivalued, derived, composite)
Cardinality or relationship sets (1:1, n:1, n:m)
Keys: superkeys, candidate keys, primary key
DBA chooses primary key for entity sets
Automatically determined for relationship sets
Weak Entity Sets, Existence Dependence, Total/Partial Participation
Specialization and Generalization (E/R + inheritance)
Aggregation (E/R + higher-order relationships)

39. These things get pretty hairy!
Many E-R diagrams cover entire walls!
A modest example:

40. A Cadastral E-R Diagram
cadastral: showing or recording property boundaries, subdivision lines, buildings, and related details
Source: US Dept. Interior Bureau of Land Management, Federal Geographic Data Committee Cadastral Subcommittee