1. Database Design
Relational Database

2. Relational DB Table: Characteristics
2-dimensional structure with rows & columns 2차원 구조
Rows (tuples)
Represent single entity occurrence
Columns
Represent attributes
Have a specific range of values
attribute domain
Each table must have a primary key 기본키
Primary key is an attribute (or a combination of attributes) that uniquely identify each row
Relational database vs. File system terminology
Rows == Records, Columns == Fields, Tables == Files
column 열 (attribute, field)
row 행
(tuple, record)
Database Design

3. Relational DB Table: Example
8 rows & 9 columns
Row = single entity occurrence
row 1 describes a student named Jone Doe
Column = an attribute
has specific characteristics (data type, format, value range)
stClass: char(2), {fr,jr,so,sr}
all values adhere to the attribute characteristics
Each row/column intersection contains a single data value
Primary key = stID
Database Design

4. Table: Keys
Consists of one or more attributes that determine other attributes
 Given the value of a key, you can look up (determine) the value of other attributes
e.g., student_ID  student’s name, major, status, grade, etc.
Composite key: Composed of more than one attribute
e.g., building name + room number  location, size, function/purpose, etc.
Candidate key 후보키
Any key that uniquely identifies each row (without redundancies)
e.g., student_ID, SSN
Primary Key (PK) 기본키
The candidate key selected as the unique identifier
Foreign Key (FK) 외래키
An attribute whose values match the primary key values in a related table
Joins tables to derive information
STU_ID
STU_SSN
STU_DOB
STU_LNAME
STU_FNAME
DEPT_CODE
12345
12/12/1985
Doe
John
245
12346
10/10/1985
Dew
243
12348
11/11/1982
Jane
423
DEPT_CODE
DEPT_NAME
243
Astronomy
245
Computer Science
423
Sociology
Database Design

5. Integrity Rules Entity Integrity 개체 무결성 Referential Integrity 참조 무결성
Ensures uniqueness of entities
Primary key values must be unique and not empty
e.g., no department can have duplicate or null DEPT_CODE
Referential Integrity 참조 무결성
Prevents invalid data entry
Foreign key value is null or matches primary key values in related table
i.e., foreign key cannot contain values that does not exist in the related table.
Most RDBMS enforce integrity rules automatically.
STU_ID
STU_LNAME
STU_FNAME
DEPT_CODE
12345
Doe
John
245
12346
Dew
243
22134
James
23456
Jane
249
DEPT_CODE
DEPT_NAME
243
Astronomy
244
Computer Science
245
Sociology
Physics
Database Design

6. Relationships in RDB
Representation of relationships among entities 개체간의 관계 표현
By shared attributes between tables (RDB model)
primary key  foreign key
E-R model provides a simplified picture
One-to-One (1:1)
Could be due to improper data modeling
e.g. PILOT (id, name, dob) to EMPLOYEE (id, name, dob)
Commonly used to represent entity with uncommon attributes
e.g. PILOT (id, license) & MECHANIC (id, certificate) to EMPLOYEE (id, name, dob, title)
One-to-Many (1:M)
Most common relationship in RDB
Primary key of the One should be the foreign key in the Many
Many-to-Many (M:N)
Should not be accommodated in RDB directly
Implement by breaking it into a set of 1:M relationships
Create a composite/bridge entity
EMPLOYEE
PILOT
MECHANIC
Database Design

7. Database Systems: Design, Implementation, & Management: Rob & Coronel
M:N to 1:M Conversion
Database Systems: Design, Implementation, & Management: Rob & Coronel
Database Design

8. M:N to 1:M Conversion Composite Table:
STUDENT
CLASS
STU_ID
STU_Name
Sex
CLS_ID
1234
John Doe M
IT-s16
DB-s16
2345
Jane Doe F
3456
GI Joe
CLS_ID
CRS_Name
Room
STU_ID
IT-s16
Web Authoring
403
1234
2345
DB-s16
Database
421
3456
STU_ID
STU_Name
Sex
1234
John Doe M
2345
Jane Doe F
3456
GI Joe
STU_ID
CLS_ID
grade
1234
IT-s16 B
DB-s16 C
2345 A
3456
CLS_ID
CRS_Name
Room
IT-s16
Web Authoring
403
DB-s16
Database
421
CLASS
STUDENT
ENROLL
Composite Table:
Must contain at least the primary keys of original tables
Contains multiple occurrences of the foreign key values
Additional attributes may be assigned as needed
Database Design

9. Data Redundancy Uncontrolled Redundancy 불필요한 중복
Unnecessary duplication of data
Repeated attribute values  Normalize (e.g., M:N to 1:M conversion)
Derived attributes  Compute as needed
Controlled Redundancy 필요한 중복
Shared attributes in multiple tables
Makes RDB work (e.g. foreign key)
For information requirements or transaction speed
e.g. INV_Price records historical product price
e.g. Account Balance = account receivable - payments
Kiduk Yang’s
Account Balance?
CUSTOMER
CUST_ID = KY123
INVOICE
PAYMENT
15/11/01 $280
15/11/15 $120
15/12/24 $ 80
16/01/01 $100
= $380
PRODUCT
INVOICE
PRD_ID
PRD_Name
PRD_Price
C1234
Chainsaw
$100
H2341
Hammer
$10
INV_ID
PRD_ID
Date
INV_Price
CUST_ID
121
C1234
2015/12/24
$80
KY123
122
H2341
2015/12/25 $5
JJ122
123
2016/01/11
$100
SH002
Database Design

10. Exercises

11. Data Modeling Exercises
Draw an E-R Diagram of the data model described by the business rules below.
A sales rep can write many invoices. Each invoice is written by a single sales rep.
A customer can generate many invoices. Each invoice is generated by a single customer.
Each invoice includes one or more invoice lines. Each invoice line is associated with one invoice. - i.e., Each item purchased is recorded in an invoice line.
Each invoice line records a single product. Each product can be recorded in many invoice lines.
A customer can make many payments. Each payment is made by a single customer.
A vendor supplies many products. A product is supplied by many vendors.
Draw an E-R Diagram of the data model described by the business rules below.
A sales rep can write many invoices. Each invoice is written by a single sales rep.
A customer can generate many invoices. Each invoice is generated by a single customer.
Each invoice includes one or more invoice lines. Each invoice line is associated with one invoice. - i.e., Each item purchased is recorded in an invoice line.
Each invoice line records a single product. Each product can be recorded in many invoice lines.
A customer can make many payments. Each payment is made by a single customer.
A vendor supplies many products. A product is supplied by many vendors. M M 1 1 M
INVOICE
generates
CUSTOMER
makes
PAYMENT 1
writes
includes 1 M
SALESREP
INV_LINE M 1 1 M M 1
is in
PRODUCT
SUPPLY
VENDOR
Database Design

12. Database Design Exercises
Identify the business rules and draw an E-R diagram of the company described below.
Yanghoo is a consulting company with multiple departments and many employees. Each department, run by a manager, has several employees who work on multiple projects.
Business Rules
A department employs many employees.
 Each employee works in one department.
An employee may work on many projects.
A project may have many employees working on it.
A department is managed by one employee.
An employee manages one department.
DEPARTMENT 1 1
manages
employs M 1 M N
EMPLOYEE
works on
PROJECT
Database Design

13. Database Design Exercises
What problem would you encounter if you wanted to produce a listing by city using the table below? How would you solve this problem by altering the file structure?.
The city names are contained within the address attribute
→ Decomposing this field at the application level is inefficient (slows down DB execution)
address
777 Bonham Ct., Durham, NC, USA
21 Jump St., Boston, MA
132 Queen St., London, England
1431-C Broad Ave., Berlin, Germany
3333 Tao St., Shanghai, China
address
777 Bonham Ct., Durham, NC, USA
21 Jump St., Boston, MA
132 Queen St., London, England
1431-C Broad Ave., Berlin, Germany
3333 Tao St., Shanghai, China
Street
City
State
Country
777 Bonham Ct
Durham NC
USA
21 Jump St.
Boston MA
132 Queen St.
London
England
1431-C Broad Ave.
Berlin
Germany
3333 Tao St.
Shanghai
China
Database Design

14. Database Design Exercises
Below is an example of the CLASS entity implemented in MS Access. Do you see a problem? If so, how would you refine your data model?
Sample DB
There is a data redundancy problem (e.g., Class Name, Code, etc.)
→ Can lead to data anomalies (i.e., Update/Insertion/Deletion Anomaly) M N 1 M
PROFESSOR
teaches
COURSE
has
CLASS N
takes
ERD Refinement #1
Separate the course information into a COURSE entity.
A professor can teach many courses. A course can be taught by many professors
A course can consist of many classes. A class belongs to one course
A student can enroll in many classes. Each class can have many students.
Sample DB M
STUDENT
Database Design

15. Database Design Exercises
Below is an example of the CLASS entity implemented in MS Access. Do you see a problem? If so, how would you refine your data model?
ERD Refinement #2
Decompose many-to-many relationship
Sample DB M N 1 M
PROFESSOR
TEACH
teaches
COURSE
has
CLASS 1 M M 1 1 N M
ENROLL
takes M M 1
STUDENT
Database Design

16. Database Design Exercises
The E-R diagram below, which models the course enrollment in a college, has a serious flaw. What is the problem and how can it be fixed? Show a revised E-R diagram. 1 M M 1 1 M
PROFESSOR
TEACH
teaches
COURSE
has
CLASS 1
ERD misses the relationship between PROFESSOR and CLASS
→ does not record who taught the specific classes M
ENROLL
takes M
ERD Refinement #3
Relate PROFESSOR to CLASS
Sample DB 1
STUDENT 1 M M 1
COURSE
has
CLASS
teach
PROFESSOR 1 M
ENROLL M 1
STUDENT
Database Design