Database Design Relational Database

Relational DB Table: Characteristics 2-dimensional structure with rows & columns

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

Database Design 2

column 열 (attribute, field)

row 행 (tuple, record)

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 3

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

DEPT_CODE DEPT_NAME

243 Astronomy

245 Computer Science

423 Sociology

STU_ID STU_SSN STU_DOB STU_LNAME STU_FNAME DEPT_CODE

12345 111-11-1111 12/12/1985 Doe John 245

12346 222-22-2222 10/10/1985 Dew John 243

12348 123-45-6789 11/11/1982 Dew Jane 423

Database Design 4

Integrity Rules Entity 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 John 243

22134 Dew James

23456 Doe Jane 249

DEPT_CODE DEPT_NAME

243 Astronomy

244 Computer Science

245 Sociology

243 246 Physics

Database Design 5

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

Database Design 6

EMPLOYEE

PILOT MECHANIC

M:N to 1:M Conversion

Database Systems: Design, Implementation, & Management: Rob & Coronel

Database Design 7

M:N to 1:M Conversion

STU_ID STU_Name Sex CLS_ID

1234 John Doe M IT-s16

1234 John Doe M DB-s16

2345 Jane Doe F IT-s16

2345 Jane Doe F DB-s16

3456 GI Joe M DB-s16

CLS_ID CRS_Name Room STU_ID

IT-s16 Web Authoring 403 1234

IT-s16 Web Authoring 403 2345

DB-s16 Database 421 1234

DB-s16 Database 421 2345

DB-s16 Database 421 3456

STU_ID STU_Name Sex

1234 John Doe M

2345 Jane Doe F

3456 GI Joe M

CLS_ID CRS_Name Room

IT-s16 Web Authoring 403

DB-s16 Database 421

STU_ID CLS_ID grade

1234 IT-s16 B

1234 DB-s16 C

2345 IT-s16 A

2345 DB-s16 A

3456 DB-s16 A

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 8

STUDENT CLASS

CLASS STUDENT

ENROLL

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

Database Design 9

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 C1234 2016/01/11 $100 SH002

PRODUCT INVOICE

CUSTOMER

Kiduk Yang’s Account Balance?

CUST_ID = KY123

INVOICE PAYMENT

15/11/01 $280 15/11/15 $120 15/12/24 $ 80

16/01/01 $100

280 + 120 + 80 - 100 = $380

Exercises

Data Modeling Exercises

Database Design 11

1. 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.

1. 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

writes

SALESREP

INVOICE

PRODUCT is in

CUSTOMER generates

VENDOR INV_LINE

includes

PAYMENT makes

SUPPLY

1

1

M M 1 1 1 M M

1 1 M M

Database Design Exercises

Database Design 12

2. 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

PROJECT works on

employs

EMPLOYEE

M M

1

N

manages

1

1

Database Design Exercises

Database Design 13

3. 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?.

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

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

The city names are contained within the address attribute → Decomposing this field at the application level is inefficient (slows down DB execution)

Database Design Exercises

Database Design 14

4. 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?

There is a data redundancy problem (e.g., Class Name, Code, etc.) → Can lead to data anomalies (i.e., Update/Insertion/Deletion Anomaly)

Sample DB

STUDENT

PROFESSOR COURSE CLASS teaches has M M N 1

takes

M

N

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

Database Design Exercises

Database Design 15

4. 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

STUDENT

PROFESSOR COURSE CLASS teaches has M M N 1

takes

M

N

TEACH

ENROLL

Sample DB

1 1 M M 1

1

M

M

Database Design Exercises

Database Design 16

4. 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.

ERD Refinement #3 Relate PROFESSOR to CLASS

STUDENT

PROFESSOR COURSE CLASS teaches has M 1

takes

TEACH

ENROLL

Sample DB

1 1 M M

1

1

M

M

ERD misses the relationship between PROFESSOR and CLASS → does not record who taught the specific classes

STUDENT

PROFESSOR COURSE CLASS teach has M 1

M

1

ENROLL

M

1

M 1