nhập môn cơ sở dữ liệu - phần 5

Nội dung• Việc chuẩn hóa và việc mô hình E-R được dùng đồng thời với nhau để thực hiện tốt việc thiết kế CSDL • Trong một vài trường hợp yêu cầu phải de-normalization để phát sinh thông

Nhập môn Cơ sở Dữ liệu

Phần 5 – Chuẩn hóa

• Chuẩn hóa là gì, vai trò của nó trong việc

thiết kế CSDL

• Các dạng chuẩn 1NF, 2NF, 3NF, BCNF, và

4NF

• Cách chuyển từ dạng chuẩn thấp lên dạng

chuẩn cao hơn

Nội dung

• Việc chuẩn hóa và việc mô hình E-R được

dùng đồng thời với nhau để thực hiện tốt việc thiết kế CSDL

• Trong một vài trường hợp yêu cầu phải

de-normalization để phát sinh thông tin một cách hiệu quả

chuẩn hóa

• Bảng là thành phần cơ sở trong thiết kế CSDL

• Cấu trúc bảng là mối quan tâm hàng đầu

• Có hai trư trư ờng hợp:

– Vẫn có thể còn tồn tại các bảng có cấu trúc không tốt trong thiết kế CSDL hợp lý

– Hiệu chỉnh CSDL sẵn có, và cấu trúc các bảng không tốt

• Chuẩn hóa có thể giúp ta nhận biết các bảng có

cấu trúc không tốt và chuyển nó thành các bảng có cấu trúc tốt hơn

– Trải qua một dãi các bước gọi là các dạng chuẩn

• Các giai đoạn chuẩn hóa

– 1NF - First normal form – 2NF - Second normal form – 3NF - Third normal form – 4NF - Fourth normal form

Better in dependency

Worse in performance (I/O)

Business Bioinformatics Statistical data

Database Tables and

Ví dụ:

một mẫu báo cáo định kỳ tại công ty.

Table 4.1 should be here

Kết quả quan sát từ hình 4.1

• PRO_NUM intended to be primary key, but

it contains null values.

• Table entries invite data inconsistencies

Figure 4.2 is insert here.

Repeating group (any project can have a group of data entries) which should not to be appeared in relational table

Data Organization: 1NF

Figure 4.3

Conversion to 1NF

• Repeating groups must be eliminated

– Proper primary key developed

• Uniquely identifies attribute values (rows)

Conversion to 1NF

• Repeating groups must be eliminated

– Dependencies can be identified – Desirable dependencies based on primary key – Less desirable dependencies

Dependency Diagram (1NF)

Figure 4.4

Above: Desired Dependencies

Below: Less Desired Dependencies

Composite primary key

PROJ_NUM,EMP_NUM Æ PROJ_NAME, EMP_NAME,

1NF Summarized

• All key attributes defined

• No repeating groups in table

• All attributes dependent on primary key

Conversion to 2NF

• Start with 1NF format:

• Write each key component on separate line

• Write original key on last line

• Each component is new table

• Write dependent attributes after each key

PROJECT ( PROJ_NUM , PROJ_NAME)

EMPLOYEE ( EMP_NUM , EMP_NAME, JOB_CLASS, CHG_HOUR )

ASSIGN (PROJ_NUM, EMP_NUM, HOURS)

2NF Conversion Results

Figure 4.5

2NF Summarized

• In 1NF

• Includes no partial dependencies

– No attribute dependent on a portion of primary key

• Still possible to exhibit transitive dependency

– Attributes may be functionally dependent on

JOB (JOB_CLASS, CHG_HOUR)

3NF Summarized

• In 2NF

• Contains no transitive dependencies

Additional DB Enhancements

Figure 4.6

3NF Table Not in BCNF

Figure 4.7

Structure to Meet BCNF

Figure 4.8

Example: BCNF conversion

Decomposition into BCNF

Figure 4.9

Normalization and Database

Design

• Normalization should be part of the design

process

• Make sure the proposed entities meet the

required normal form before the table structures are created

• Used to redesign or modify the existing

table structures.

• E-R Diagram provides macro view

Normalization and Database

Design

• Contracting company’s example:

PROJECT (PROJ_NUM, PROJ_NAME)

EMPLOYEE(EMP_NUM, EMP_LNAME,EMP_FNAME,EMP_INITAL,

JOB_DESCRIPTION, JOB_CHG_HOUR);

Initial ERD for Contracting

Company

Figure 4.10

Already 3NF There is a transitive dependency

PROJECT (PROJ_NUM, PROJ_NAME)

EMPLOYEE(EMP_NUM, EMP_LNAME,EMP_FNAME,EMP_INITAL,

JOB_CODE) JOB (JOB_CODE, JOB_DESCRIPTION, JOB_CHG_HOUR);

Removal

Contracting Company

Final ERD for Contracting Company

Figure 4.12

PROJECT (PROJ_NUM, PROJ_NAME, EMP_NUM)

EMPLOYEE(EMP_NUM, EMP_LNAME,EMP_FNAME,EMP_INITAL,

EMP_HIREDATE, JOB_CODE) JOB (JOB_CODE,, JOB_DESCRIPTION, JOB_CHG_HOUR);

ASSIGN((ASSIGN_NUM, ASSIGN_DATE, ASSIGN_HOURS,

ASSIGN_CHG_HOURS, ASSIGN_CHARGE, EMP_NUM, PROJ_JUM)

Higher-Level Normal Forms

• Fourth Normal Form (4NF)

– Table is in 3NF – Has no multiple sets of multivalued dependencies

Conversion to 4NF

Figure 4.14

Figure 4.15 Set of Tables in 4NF

• Normalization purity is difficult to sustain due to conflict in:

– Design efficiency – Information requirements – Processing

Unnormalized Table Defects

• Data updates less efficient

• Indexing more cumbersome

• No simple strategies for creating views

INVOICE table structure

Draw dependency diagram Identify all dependencies 2NF?

Properties table structure

Dinner club table structure