1. The Entity-Relationship Diagram for Data Modeling

2. Overview of Database Design 1
Steps in building a database for an application
Requirement analysis. Specify what need to be modeled in a real-world domain
Conceptual design. Specify a high level schema using a database design model
Logical design. Refine a conceptual design to a schema using the data model of a DBMS
Physical design. Define the schema using the DDL of the DBMS
Database creation. Load data into a database

3. Overview of Database Design 2
Real-world domain
Database design model (Conceptual) (ERD, ODL)
DBMS data model (Logical) (relational, OO, OR)
Design-to-DBMS step may be automated (e.g., ER-to-relational)
Middle step sometimes skipped (directly to relational model)

4. Requirement Analysis Need to interact with domain experts
Interviews and/or Q&A
Application specific
Time consuming
Very important
Difficult to be thorough

5. A Sample Requirement Consider a regional hospital.
There are doctors, patients, nurses, prescriptions, tests, …
Each doctor has ID, Name, Specialty, Age, Sex, …
Patients see doctors, doctors prescribe drugs to patients, …
Each patient has one primary care physician, a nurse is assigned to at most 5 patients, …

6. Conceptual Design
Design a high level schema based on user requirements
Why do we do a conceptual design?
To communicate with domain experts (use concepts of the application domain).
It is easier to set up a good model (focus on data content not structure)
Flexible (system independent)
How to describe a conceptual design?
Use an ER Diagram (most popular), ODL

7. Entity-Relationship Model
Proposed by Peter Chen in 1976
Historically very popular
Graphical
Major concepts: entity type, relationship type, attribute, constraints, …

8. Entity-Relationship Diagrams
Entity-Relationship Diagrams
Three principal components
Entity set (= class), Entity (= object)
Attributes
Relationship
has one name in both directions
can involve more than two entity sets

9. Entity Entity Entity Type
A real-world object distinguishable from other objects.
Each entity is described by a set of attributes (or properties).
Realized as Tuple or Record
cf) Object
Entity Type
A definition of a collection of entities with identical set of attributes.
cf) Class
Students ID
name
school

10. Relationship Relationship Relationship Type
An association between two or more entities (usually of different types).
A relationship may also have attributes.
Relationship Type
A definition of a collection of relationships with the identical set of attributes.
Address
Name
Qty
PID
Order
Product
Customer ID
Date

11. Attributes Domain Types of attributes
The set of values the attribute may take.
Types of attributes
simple vs composite, single-value vs multi-value, stored vs derived
Students ID
gpa
name
fname
minit
lname
hobby
bdate
age

12. Degree of Relationships
Number of entity types involved in a relationship type.
unary, binary, ternary, …
Role
Part played by entities of a unary relationship.
Reports_To
lot
name
subor-dinate
super-visor
ssn
Employees
name
city S#
Suppliers P#
color
Parts
Order
Projects J#
dept
qty

13. Key Constraint Key Attribute(s) Key Constraint
A set of attributes of an entity type whose values are unique for each entity of that type.
Key Constraint
Every (almost!) entity type must have a key attribute(s). (e.g., ID of Students)

14. Participation Constraint
Whether or not every entity in an entity type participates in a type of relationship
Either total or partial
gpa
grade
name
takes
Students ID
title
credit
cno
Courses
Every course is taken by some students

15. Cardinality Constraints
Cardinality Ratio.
Whether or not an entity of a type may involve in a type of relationship with multiple entities of another entity type.
One-to-one (1-to-1).
Each entity in E1 is associated with 0 or one entity in E2, and vice versa.
Employees
manages
Departments
ssn
dno
name
age
since
room 1
cf) Other notation exists (James Martin’s IE, IDEF1X,..)

16. Cardinality Constraints
One-to-many (1-to-m).
Each entity in E1 is associated with 0 or more entities in E2, and each entity in E2 is associated with 0 or one entity in E1.
The reverse is many-to-one (m-to-1).
Professors
advises
Students
ssn ID
name
room
gpa 1 m

17. Cardinality Constraints
Many-to-many (m-to-n).
Each entity in E1 is associated with 0 or more entities in E2, and vice versa
This is the default case if not labeled ID
Students
takes
Courses
cno
name
gps
title
credit m n
grade

18. Cardinality Every F participate to Relationship R1 1 R E F 1 m R E F m n R E F 1 m R E F
Every F participate to Relationship R R E F
Each E is related to unique F

19. IE Notation for Cardinality
James Martin’s Information Engineering
0 or 1 A B A B
exactly 1 A B
0 or more than 1 A B
1 or more than 1 A B
more than 1

20. Multiway Relationships
Multiway Relationships
Relationships involving more than two entity sets
Ternary (three-way) or higher-degree relationships are rare.
Stars
Contracts
Movies m n
Studios 1
A studio has contracted with a particular star to act in a particular movie. : (studio, star, movie)
For a particular star and a movie, there is only one studio.
Studio 는 여러 star 와 한 movie 에 출연하는 것에 계약가능
한 star 는 한 studio 와 여러 movie 에 출연하는 것에 계약.
Star - Studio, Movie- Studio, Star-Movie 간의 relationship 이 따로 존재하는 경우와는 어떻게 틀리는가?

21. Roles in Relationships
Roles in Relationships
One entity type can appear two or more times in a single relationship.
Label for each edge: “role”
Sequel-of
Movies
Original 1 m
Sequel
한 영화의 속편은 여러 개 일 수 있다.
어떤 속편의 original 은 한 개 뿐이다.

22. Attributes on Relationships
Attributes on Relationships
Stars
Contracts
Movies m n
Studios 1
Salary
Stars
Contracts
Movies m n
Studios 1
Salary
Salaries
Salary 를 추가하고 싶은데 이것을
star 의 attribute 로 하면 : star 가 다른 영화마다 다른 salary 를 받으므로 적당치 않음.
Movie 의 attribute 도: movie 에 나오는 star 마다 salary 가 다르므로 적당치 않음.
Studio 의 attribute ??
그러므로 salary 는 (star,movie,studio) 의 attribute 가 되어야 한다.
Relationship의 attribute 는 두 번째 그림과 같이 새로운 entity 를 추가함으로써 없애 버릴 수 있다.

23. Multiway to Binary Relationship
Multiway to Binary Relationship
Multiway relationship -> connecting entity
Stars
Contracts
Movies m
Studios
Studio of Star
Producing
Studio 1
Star-of
Movies m
Contracts 1
Studios
Stars
Movie-of
Producing
Studio
Studio of
Star
E/R 을 ODL로 바꿀 때 유용 하다. 과정
Relationship 에 대응하는 connecting entity 를 만들고,
Connecting entity로 부터 원래 entity 들로 many-one relationship을 각각 만든다.
Role 이 붙어 있는 relationship edge 는 각기 다른 relationship 으로 만든다.
Connecting entity 는 tuple 을 나타내는 entity 이다. 그러므로 connecting entity 로 부터 각 original entity 로 가는 relationship 들은 many-one 이다.

24. Subclass in E/R Diagrams (isa Relationship)
Subclass in E/R Diagrams (isa Relationship)
Movies
Cartoons
Murder-
Mysteries
isa
voices
length
title
year
filmType
weapon
Stars
address
name 1 1 1 1

25. Inheritance in the E/R Model
Inheritance in the E/R Model
In E/R model we do not need a new entity set for a derived entity.
Cartoon-MurderMystery is not needed
cf) In Object-oriented systems, fourth class Cartoon-MurderMystery is needed
Movies, Cartoons, Murder-Myesteries are connected by “isa” relationship.
They implies a new fourth entity set together (Cartoon-MurderMystery) ex) in the E-R, the effect of this fourth subclass is obtained by putting components of the movie “Roger-Rabbit” in both the Cartoons and Murder-Mysteries entity type => Join !
ODL 에서는 object 가 반드시 한 class 의 member 이어야 한다. 따라서 Cartoon-MurderMystery 를 반드시 만들어야 한다.
E/R 에서는 한 entity 가 isa-hierarchy 로 연결된 몇 개의 entity set 들에 속하는 component 를 가진다고 가정한다.
3개의 entity set Movies, Cartoons, Murder-Mysteris 가 isa relationship 에 의해 연결되어 있으므로, 어떤 component (object) 가 이 세개의 entity set 에 동시에 속하는 것이 가능해 진다. Roger Rabbit 은 Movie 의 모든 attribute 와 relationship + Murder Mystery 의 weapon attribute + Cartonns 의 voice 를 모두 attribute 로 가질 수 있다.
그러나 만일 Roger rabbit 이 이 세개의 entity 이외에 다른 attribute 를 가진다면 다시 새로운 entity “Cartoon-MurderMystery” 를 만들어야 할 것이다.

26. The Modeling of Constraints
The Modeling of Constraints
Keys: attribute(s) that uniquely identify an object within its class.
Single-value constraints: the value in a certain role be unique, ex) keys.
Referential integrity constraints: a value should exist in DB. No dangling pointers.
Domain constraints: the values should lie within a specific range.
General constraints: arbitrary assertion, ex) no more than ten stars be listed for one movie.

27.
Keys
In E/R model: Key for an entity set is a set K of one or more attributes that distinguish an entity E1 from another entity E2.
Movie: (title) or (title, year)
Studio: (name)
Star: (name) or (name, address)
Creating an attribute whose purpose is to serve as a key
Corporation DB: employee ID
US country: social security number

28. Representing Keys in E/R Model
Representing Keys in E/R Model
Underline at key attributes
More than one keys: primary and secondary keys, underline only at primary keys, side remarks for indicating secondary keys
title
length
year
filmType
Movies

29. Single Value Constraints in E/R
Single Value Constraints in E/R
By implication, each attribute has a single value.
We generally assume that it is possible for a value to be null. If not, side remark.
“1” for many-one, one-one relationships: single-value constraints.

30. Referential Integrity
Referential Integrity
Asserts exactly one value exists in a given role.
Ways to enforce referential integrity
Forbidding the deletion of referenced object
If referenced object is deleted, all referencing objects are deleted as well.
When creation time
ex) movie creation -> automatic reference to a studio.
예를 들어 movie 의 owner 인 studio 가 delete 되면 그 studio 가 own 하고 있는 모든 movie 의 data 가 delete 되는 것..

31. Referential Integrity in E/R
Referential Integrity in E/R 1
Owns
Runs
Movies
Studios
Presidents
A movie must have its owner studio.
A president must have his/her studio.
A studio can be alive without president.
That Studio entity is required to exist. ( rounded arrowhead )
If a studio is deleted, the president of the studio should be deleted from Presidents DB.
rounded arrow 사용

32. Other Kinds of Constraints
Other Kinds of Constraints
Domain constraints
X is integer.
X is positive integer.
X is between 60 and 240: ODL not support but SQL
General constraints
Movies
Stars-in
Stars

33. Weak Entity Type : First Case
Weak Entity Type : First Case
An entity type’s key is composed of attributes some or all of which belong to another entity set.
When an entity is a sub-entity of another entity
Crews of Movie Studio
Each crew has his number (1, 2, 3, …)
But, number is not unique (Other crews in other studio)
Key of Crew = Crew’s number + Studio’s name
Number
name
addr
Weak entity set 이 생기는 첫번째 이유.
어떤 eneity set E 가 다른 entity set F 의 subunit 일 때 이런 현상이 생긴다.
Work 1
Crews
Studios

34. Weak Entity Type : Second Case
Weak Entity Type : Second Case
Connecting entity set (to be introduced to eliminate a multiway relationship)
Usually, the connecting entity set have no attribute of its own
Its key is formed from the attributes that are the key attributes for the entity sets it connect
Salary
두번째 이유

35. Requirements for Weak Entity Types
Requirements for Weak Entity Types
Weak entity type W should have relationship R with other entity types F offering key attributes K
R must be a binary, many-one relationship from W to F. (many-one includes one-one)
K should be a key attributes of F
If F is itself weak, key K may be from another entity set connected to F by a many-one relationship.
If there are several many-one relationship from W to F, then each relationship may be used to supply a copy of the key attributes of F to help form the key of W.
일단 E 의 어떤 attribute 도 E 의 entity 를 unique 하게 define 하지 못하는 경우, E에서 many-one 으로 relate 된 F 로 가서 그 key 를 합쳐서 key로 나타낸다.