christoph f. eick: designing e/r diagrams 1 designing e/r diagrams updated: january 25. 2005
TRANSCRIPT
Christoph F. Eick: Designing E/R Diagrams 1
Designing E/R Diagrams
Updated: January 25. 2005
Christoph F. Eick: Designing E/R Diagrams 2
Conceptual Data Models
Conceptual data models provide languages to describe conceptual schemas.
Conceptual schemas are used to describe the classes of objects that occur in an application area, their properties, their relationships, and the constraints that hold with respect to those classes of objects.
Center on “what kind of objects a database contains” and not on “how these objects are stored” ( Internal Schema) and not on “how these objects are represented / displayed to a person that accesses the database” ( External Schema).
Christoph F. Eick: Designing E/R Diagrams 3
Conceptual Data Models ---What are they good for?
As a database design tool formalizing the information requirements of the end users
As a documentation tool for databases (to help programmers, especially those that have to update the database)
As a data model of a database management system (only very few experimental systems exist)
As a tool to describe domain ontologies (terminology and concepts in a UoD)
As a tool of system analysis
X
X
Person
name
ssn
Wedding
E/R Model Symbols for COSC 3480
occurred
to
Is-insured
T1
amount
(n,m)
phone#
from-------
Entity Type
Attribute
RelationshipType
Weak Entity Type
IdentifyingRelationship
Key Attribute
Partial Key
Optional Attribute
R
Entities of type X participate at least n, at most mtimes in relationship R; * indicates .
Y
Entity type X is a subtype of type Y
T2
Type T1 and T2 are overlapping; an entity canbelong to both T1 and T2; default is disjoint
Multi-valued Attribute
Derived Attribute
T2
T3
T1
T3=T2 T1
Course
Student
Department
name
ssn
grade
took
semesterid title
salary
(0,30)
(0,*)
(1,1)
University Problem Final’03 COSC 3480
employs
Cou#
Semester
took-not-a-set: -2.5Other Errors: -1.5 (or 3-4 if major)
Grad
UGrad
gre
(0,*)
(0,*)
mentor
name
(0,25)
(0,2)
home
(0,*)
(1,1))
Christoph F. Eick: Designing E/R Diagrams 6
Exam1 Fall 2005 Problem Design a “good” entity-relationship diagram that describes the following
objects in a university application: students, departments, sections taught in the present and future, and courses. Departments have a name that uniquely identifies the department. Students are identified by a unique social security number, zero, one or multiple e-mail addresses, and an optional gpa (new students do not have a gpa yet). Courses have a unique course number and a course title. Courses are offered in one or more sections at a particular time. Sections are identified by the time they are offered (e.g. 10:30-noon TUTH) and by the course they are associated with. Additionally sections are characterized by the class room the section is taught in. Only information concerning sections that are taught in the present or in the future is stored in the database. Students take a course in a particular semester and receive a grade for their performance. Sometimes students take the same course again in a different semester. There are no limits on how many courses a student can complete, and on how many students completed a particular course. Each student is associated with a least one department. Some students are graduate students that are additionally characterized by their most recent GRE-score. Some graduate students work for a department and receive a salary for their services. Each department employs at most 75 graduate students; graduate students are not allowed to work for multiple departments.
Course
Student
Department
name
ssn
grade
took
semesterid
title
salary
(0,75)
(0,*)
(0.*)
University Problem Exam1’05
employs
Cou#
Semester
took-not-a-set: -1.5Section not weak: -2Other Errors: -0.5--1 if minor -2—3 if major
Grad
(0,*)
(0,*)
assoc
name
(0,1)
(0,*)
(1,1)
gpa(1,*)
gre
Section
offered
Time-offered classroom
Christoph F. Eick: Designing E/R Diagrams 8
Team contr
name
cityPlayer
namessn
birthd
played-in.
Date
pos
score
Home Visit
Sal
(1,1)
(25,*)
(18,*)
(0,*)(0,*)
Solution Problem6 Exam0 Spring 2003
(0,*)
play
Game#
Game
Contract set viol –3, Other: -2
pos
Month
fromto(0,*)
(0,*)
(0,*)
name
Christoph F. Eick: Designing E/R Diagrams 9
Team
empl.
contr
name
city
Manager
Player
Person
namessn
weight pos
birthd
height
Game
play played-in.
Date
minscore
Home Visit
Sal
Sal
(1,3)
(0,4)
(1,1)
(24,99) (0,1)
(22,*)
(0,*)(0,*)NFLE/RProblem
(0,*)
Scoring: 1. Play relationship a Set: 32. Person/Player/Manager: 33. Weak Game Entity: 34. Played-in: 25. Can Only Play once on a day: 16. Contract: 37. Salary, score, min attribute: 3
Christoph F. Eick: Designing E/R Diagrams 10
Identifying Keys and Relationships
for Entity TypesEach entity type that is not subtype of another entity
type needs: Case1: Normal Entity Type (single rectangle)
1. A single attribute (straight line) or2. A set of attributes or
Case2: Weak Entity Type (double rectangle)1. A set of relationships (double diamond) or2. A set of relationships or a single attribute (dotted line) or3. A set of relationships and a set of attributes (dotted line)
that uniquely identifies the instances of the entity type
Remark: min-max cardinalities for weak entity types for their participation in identifying relationships have to be (1,1)!!
Male
Female
Person
namessn
Wedding
(0,*)
E/R Diagram for Multi-Weddings
occurred
(0,*)
fromto
(1,1)
Is-insured Company
nameamount
(0,*)(0,*)
location
husband
wife
Christoph F. Eick: Designing E/R Diagrams 12
Valid E/R Diagrams
An E/R diagram is valid if and only if: It is syntactically correct (e.g.
specifies all key constraints,…) It specifies the entity types, relationship
types, attribute types, and subtype relationships necessary to satisfy all information requirements.
It does not specify any invalid constraints.
Christoph F. Eick: Designing E/R Diagrams 13
Priorities when Choosing Between Valid E/R Diagrams
1. Express all constraints (you can express!)
2. Use and do not change terminology and class structure of the application domain
3. Keep it simple (avoid defining entity types that do not serve any purpose)
4. Avoid redundancy (but derived attributes are okay)!
Christoph F. Eick: Designing E/R Diagrams 14
A Quite Bad E/R Diagrams
Company
ssn
gender
works-for
departmentgpa
(0,*)
Name
Person
salary
(0,*)(0,*)
is-married-to
husbandwife
(0,*) takes
Section
(0,*)
Course
(0,*)
C#
S#
time
Christoph F. Eick: Designing E/R Diagrams 15
Example: Too many Entity Types /Don’t use Foreign Keys
Company
ssn
name
is-insured
Name
Person(0,*)(0,*)
Example: Persons as well as animals can be insured
Animal
P#
(0,*)
A#
Boss-ssn
Bad E/R Diagram!
Christoph F. Eick: Designing E/R Diagrams 16
E/R Diagram Design – Typical Errors
1. Missing Constraints2. Unexpressed Constraints due to bad design3. Every entity type needs a key4. Attribute associated with the wrong entity type (relationship type)5. Relationships are sets!6. No partial participation in relationships!7. Missing existence dependencies (use subclasses)8. Invalid constraints9. Using Subtypes for n:1 relationships; using relationships when subtypes should
be used.10. When defining relationships: Too general entity types for participating entities 11. Too many entity types12. Using foreign keys instead of relationships
Christoph F. Eick: Designing E/R Diagrams 17
Other Issues in E/R Design
1. No relationships of relationships --- solution: create an entity type that represent instances of the relationship (or use aggregation as discussed in the textbook)
2. value or entity type --- solution: choose entity type if it helps expressing constraints; otherwise, use value-type.
Christoph F. Eick: Designing E/R Diagrams 18
University E/R Design Problem
Design a “good” entity-relationship diagram that describes the following objects in an university application: students, instructors, professors, and courses. Students are subdivided into graduate and undergraduate students. Students take a course in a particular semester and receive a grade for their performance. Sometimes students take the same course again in a different semester. There are no limits on how many courses a student can take, and on how many students completed a particular course. Each graduate student has exactly one advisor, who must be a professor, whereas each professor is allowed to be the advisor of at most 20 students. Courses have a unique course number and a course title. Students and professors have a name and a unique ssn; students additionally have a gpa; moreover, graduate students have a GRE-score, and undergraduate students have a single or multiple majors. Professors can be students and take courses, but graduate students cannot be undergraduate students.
Indicate the cardinalities for each relationship type; assign roles (role names) to each relationship if there are ambiguities! Use sub-types, if helpful to express constraints!
Course
Student
Professor
Person
namessn
gradegpa
took
semesteridtitle
gre(0,1)
(0,*)
(0,20)
University Problem (slightly different from Exam0’03)
advises
Cou#
Semester
Enrolls-not-a-set: -4Student must be ugrad or grad: -1Other Errors: -2 (or –3 if quite major)
Ugrad
Grad
major
(0,*)
(0,*)
Hotel
Gold_Cl.
Client
addr
ssn
discount
G#
room-type
address
number
(0,*)
A:=guaranteed; B:=has_transaction; C:=for_hotel; D:=consists_of; E:=for_category; F=avail-rooms; G=total-rooms; modified on Feb. 3, 2004
Ho#
Transaction
Category
Cred-Card
(0,*)
(0,1)
Reservation
company
C
E
D
(1,1)
B
(1,50)
(1,1)
(0,300)
(1,1)
F
#avail
from rateto
day_made
Res#
(1,1)
tr#
(0,*)
(0,*)
(1,*)
phone#
A
Problem 1
Exam1 Fall’03
Grading:Minor Error: -1Medium Error: -2Major Error: -3 or –40-4 points if too many errors
day
Date#totalG
(0,*)
(1,*)
Christoph F. Eick: Designing E/R Diagrams 21
Aggregation Used when we
have to model a relationship involving (entity sets and) a relationship set. Aggregation
allows us to treat a relationship set as an entity set for purposes of participation in (other) relationships.
Aggregation vs. ternary relationship: Monitors is a distinct relationship, with a descriptive attribute. Also, can say that each sponsorship is monitored by at most one employee.
budgetdidpid
started_on
pbudgetdname
until
DepartmentsProjects Sponsors
Employees
Monitors
lotname
ssn
since
Christoph F. Eick: Designing E/R Diagrams 22
NFL E/R Design ---Ungraded Homework --- due: Th., Jan.
27,2005
Design an Entity-Relationship Diagram that models the following objects and relationships in the world of football (NFL): teams, players, games, managers and contracts. Each (NFL-) team has a unique team name, and a city it plays in. Each person being part of the NFL-world has a unique ssn and a name. Additionally, for players their weight, height, position and birth dates are of importance. Players have a contract with at most one team and receive a salary for their services, and teams have at least 24 and at most 99 players under contract. Each team has one to three managers; managers can work for at most 4 teams and receive a salary for each of their employments. Players cannot be managers. A game involves a home-team and visiting-team; additionally, the day of the game, and the score of the game are of importance; teams play each other several times in a season (not on the same day!). Moreover, for each game played we like to know which players participated in the game and how many minutes they played.
Indicate the cardinalities for each relationship type; assign roles (role names) to each
relationship if there are ambiguities! Use sub-types, if helpful to express constraints!