database design - knuwidit.knu.ac.kr/~kiyang/teaching/gdb/f17/lectures/4.gdb-rdbconcepts.pdf ·...
TRANSCRIPT
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