Chuẩn hóa cơ sở dữ liệu

Chuẩn hóa cơ sở dữ liệu

Hình 3.1 Các mức của chuẩn hoá

 Codd là ngời đầu tiên đ định nghĩa ba mức chuẩn hoá mà ông gọi làã đ

dạng chuẩn thứ nhất, thứ hai và thứ ba

Các quan hệ tổng quát (đ chuẩn hoá và ch a chuẩn hoá)ã đ

Các quan hệ 1NF (các quan hệ đ chuẩn hoá)ã đ

Các quan hệ 2NF

Các quan hệ 3NF, BCNF

Các quan hệ 4NF

 Sau đó, Fagin đ định nghĩa dạng chuẩn thứ bốn (4NF: Fourth Normalã đ

Form) với tính chất một số quan hệ 3NF cũng ở dạng chuẩn thứ bốn

 Hình 3.1 cho ta thấy, "dạng chuẩn mong muốn hơn" mà đ đ ã đ ợc lu ý đến trong chơng trớc là dạng chuẩn thứ bốn

 Nh vậy, mục đích của chơng này là:

 minh hoạ các u điểm của dạng chuẩn thứ ba, BCNF

cho biết làm thế nào để chuyển một quan hệ cha ở dạng chuẩn

thứ ba, BCNF thành một tập hợp các quan hệ tơng đơng ở dạng chuẩn 3NF, BCNF

3.2 Phụ thuộc hàm

 Phụ thuộc hàm (Funtional dependency - FD) trong một quan hệ là khái niệm rất quan trọng, đặc biệt đối với ngời quản trị hệ thống khi thiết kế mô hình dữ liệu

 Định nghĩa:

 Cho trớc một quan hệ R, chúng ta nói rằng, thuộc tính

Y của R là phụ thuộc hàm vào thuộc tính X của R nếu và chỉ nếu mỗi giá trị của X trong R đợc kết hợp với đúng một giá trị của Y trong R tại bất kỳ thời điểm nào

 Lu ý là, một giá trị của X có thể xuất hiện trong nhiều bộ khác nhau của

R nhng nếu Y là phụ thuộc hàm vào X thì định nghĩa trên nói với chúng

ta là các bộ khác nhau đó phải chứa cùng một giá trị của Y

 Ví dụ:

 Trong quan hệ S của mô hình dữ liệu h ng-cung-cấp-và-mặt-ã đ

hàng có các thuộc tính SNAME, STATUS và CITY đều là phụ thuộc hàm vào thuộc tính S# vì:

 nếu cho trớc một giá trị của S# thì sẽ có đúng một giá trị tơng ứng của từng thuộc tính SNAME, STATUS và CITY

 Chúng ta có thể biểu thị các phụ thuộc hàm này bằng sơ đồ nh trên hình 3.2.

Hình 3.2 Các phụ thuộc hàm trong quan hệ S

SNAME

STATUS S#

CITY

 Sự nhận biết các phụ thuộc hàm là một phần rất quan trọng để hiểu ý nghĩa hoặc ngữ nghĩa của dữ liệu

 mỗi h ng cung cấp chỉ đặt trụ sở ở đúng một thành phốã đ

 Vì đây là một phần ngữ nghĩa của tình huống này nên sự áp đặt này cần phải đợc thể hiện trong mô hình dữ liệu

 Cách thức để đảm bảo điều này đợc thể hiện là chỉ định điều kiện áp

đặt này trong định nghĩa mô hình dữ liệu (nghĩa là, trong lợc đồ khái niệm) sao cho hệ quản trị CSDL có thể thi hành nó

 Cách thức để chỉ định điều kiện áp đặt trong lợc đồ khái niệm là khai báo sự phụ thuộc hàm

 Sau này chúng ta sẽ thấy các khái niệm về chuẩn hoá sẽ cho ta các cách khai báo đơn giản các phụ thuộc hàm nh vậy.

 Sự phụ thuộc hàm có thể mở rộng để bao trùm cả trờng hợp mà X hoặc

Y hoặc cả hai là các thuộc tính ghép (composit attributes)

 Ví dụ:

 Trong quan hệ SP của mô hình dữ liệu h ng-cung-cấp-và-mặt-ã đ

hàng, thuộc tính QTY là phụ thuộc hàm vào thuộc tính ghép (S#, P#)

 Chúng ta có thể biểu diễn tình huống này nh trong hình 3.3.

S#

P#

QTY

Hình 3.3 Phụ thuộc hàm trong quan hệ SP

 Theo lý thuyết quan hệ, ta có thể định nghĩa phụ thuộc hàm nh sau:

là tập thuộc tính X và Y là tập con của U.

thuộc hàm vào X) nếu r là một quan hệ xác định trên

t1[X] = t2[X] thì t1[Y] = t2[Y]

 Phụ thuộc hàm đầy đủ (fully functionally dependent):

 Thuộc tính Y đợc gọi là phụ thuộc hàm đầy đủ vào

thuộc tính X nếu nó là phụ thuộc hàm vào X và không phụ thuộc hàm vào bất kỳ một tập con nào của các thuộc tính của X (X phải là thuộc tính ghép)

 Sau đây chúng ta sẽ nói "phụ thuộc hàm" với ý nghĩa phụ

thuộc hàm đẩy đủ trừ khi có giải thích tờng minh

 Cho đến giờ, tất cả các ví dụ mà chúng ta xét (trong quan hệ S, P và SP) đều có các tính chất phụ thuộc hàm vào khoá chính

 Tuy nhiên không phải trờng hợp này cũng nh vậy

 Một quan hệ mà các phụ thuộc hàm đều là phụ thuộc hàm vào khóa chính nh vậy phải ít nhất là ở dạng chuẩn thứ ba, mặc dầu không nhất thiết là ở dạng chuẩn thứ bốn

 Nhng nh sau này chúng ta sẽ thấy, không phải tất cả các quan hệ đ ởã đ

dạng chuẩn thứ ba đều tuân theo mẫu chuẩn đơn giản này

3.3 Các dạng chuẩn thứ nhất, thứ hai và thứ ba

 Để thuận tiện, mục này sẽ làm việc với ba dạng chuẩn đầu tiên, còn dạng chuẩn BCNF sẽ đợc nghiên cứu sâu hơn trong mục 3.4

 Tuy nhiên, để có thể có đợc ý niệm về mục đích nghiên cứu các dạng chuẩn, mục này sẽ đa ra định nghĩa về dạng chuẩn thứ bốn một cách theo cảm giác cho dễ hiểu

 Sau đó, mục này và các mục sau sẽ nghiên cứu quá trình chuyển một quan hệ bất kỳ thành một tập tơng đơng các quan hệ ở dạng chuẩn thứ BCNF

chỉ nếu tại mọi thời điểm, mỗi bộ của R gồm giá trị khoá chính (dùng để nhận dạng duy nhất một thực thể nào đó)

và một tập các giá trị của các thuộc tính độc lập với nhau

để mô tả thực thể

 Hai thuộc tính đợc gọi là độc lập với nhau nếu không thuộc tính nào là phụ thuộc hàm vào thuộc tính kia; các thuộc tính này có thể là các thuộc tính ghép

 Ví dụ:

 Quan hệ S là ở dạng chuẩn thứ bốn

 Các quan hệ P và SP cũng trong dạng chuẩn thứ bốn

 Nói chung, các thực thể đợc nhận dạng duy nhất bởi các giá trị khoá chính là các thực thể cơ sở đợc ghi nhận bởi dữ liệu trong CSDL

chỉ nếu tất cả các miền đều chỉ chứa các giá trị nguyên tố.

 Định nghĩa này chỉ đơn thuần cho ta biết là bất kỳ quan hệ đ chuẩnã đ

hoá nào cũng ở dạng chuẩn thứ nhất

 Một quan hệ chỉ ở dạng chuẩn thứ nhất (nghĩa là một quan hệ 1NF mà

không là 2NF, do đó cũng không là 3NF hoặc BCNF) có cấu trúc không mong muốn do một số lý do

 Để minh hoạ điểm này, giả thiết:

 Thông tin liên quan đến h ng cung cấp và số lã đ ợng đặt hàng thay vì chia thành hai quan hệ tách biệt nhau (S và P), sẽ kết hợp lại thành một quan hệ

FIRST (S#, STATUS, CITY, P#, QTY)

 Các thuộc tính ở đây có ý nghĩa thông thờng của chúng

 Tuy nhiên, để thuận tiện cho ví dụ, thêm một điều kiện:

 STATUS là phụ thuộc hàm vào CITY

 Ngoài ra, chúng ta cũng bỏ qua thuộc tính SNAME cho đơn giản

 Khoá chính của quan hệ FIRST là (S#, P#)

 Hình 3.4 là sơ đồ phụ thuộc hàm của quan hệ FIRST này

b Các thuộc tính STATUS và CITY là không độc lập với nhau

 Chính hai điều kiện này làm cho sơ đồ các phụ thuộc hàm của quan hệ

FIRST trên hình 3.4 phức tạp hơn sơ đồ các phụ thuộc hàm của các quan hệ 4NF là S và SP trên hình 3.2 và 3.3

 Và chính chúng làm nảy sinh các vấn đề khó khăn cho các phép toán cơ sở mà ta sẽ xét sau đây

 Để minh hoạ các vấn đề này, chúng ta xem xét một bảng dữ liệu mẫu của quan hệ FIRST trên hình 3.5

S2 10 Paris P2 400

Hình 3.5 Bảng dữ liệu mẫu của quan hệ FIRST

 Quan hệ FIRST có các dị thờng trong các phép toán lu trữ giống nh các

dị thờng đ thấy trong mô hình phân cấp đ đã đ ã đ ợc mô tả trong chơng 1

 Các vấn đề xuất hiện với ba phép toán cơ bản đợc thể hiện nh sau:

 Trớc khi h ng S5 cung cấp một mặt hàng nào đó thìã đ

chúng ta vẫn cha có khoá chính tơng ứng với h ng S5ã đ

này

 Cần nhớ lại trong mục 2.2 chúng ta đ chỉ rõ là khôngã đ

một thành phần nào trong khoá chính đợc rỗng

 Còn trong quan hệ FIRST, các giá trị khoá chính bao gồm số hiệu h ng cung cấp và số hiệu mặt hàngã đ

ii Xoá (Delete):

Nếu chúng ta xoá đi một bộ duy nhất của một h ng cung cấpã đ

nào đó trong quan hệ FIRST, chúng ta sẽ huỷ mất không chỉ số lợng hàng liên kết h ng cung cấp này với một mặt hàng nào đóã đ

mà cả thông tin về địa chỉ thành phố của h ng cung cấp nàyã đ

iii Thay đổi (Update):

Địa chỉ thành phố của một h ng cung cấp nào đó (Ví dụ h ngã đ ã đ

S1) trong quan hệ FIRST có thể xuất hiện nhiều lần

 Sự d thừa dữ liệu này gây nên các vấn đề trong phép toán thay

đổi

Ví dụ:

 Nếu h ng cung cấp S1 chuyển từ London đếnã đ

Amsterdam, chúng ta sẽ hoặc gặp phải bàI toán tìm kiếm hoặc dữ liệu không nhất quán

Hình 3.6 Các phụ thuộc hàm trong quan hệ SECOND và SP

 Để giải quyết các vấn đề trên, chúng ta thay thế quan hệ FIRST bằng hai quan hệ

SECOND (S#, STATUS, CITY)

SP (S#, P#, QTY)

 Hình 3.6 chỉ ra các sơ đồ phụ thuộc hàm của hai quan hệ này

 Hình 3.7 cho thấy bảng dữ liệu mẫu tơng ứng với các giá trị của hình 3.5

 Quan hệ SP bây giờ thực tế giống hệt nh đ cho trên hình 2.5ã đ

Hình 3.7 Bảng dữ liệu mẫu của các quan hệ SECOND và SP

 Cấu trúc đ đã đ ợc sửa lại trên hình 3.7 này đ giải quyết đã đ ợc tất cả các vấn đề về các phép tóan lu trữ liên quan đến sự kết hợp của S# và

SECOND S# STATUS CITY

S1 20 London

S4 20 London S5 30 Athens

SP S# P# QTY

S1 P1 300 S1 P2 200 S1 P3 400 S1 P4 200 S1 P5 100 S1 P6 100 S2 P1 300 S2 P2 400 S3 P3 200 S4 P2 200 S4 P4 300 S4 P5 400

i Chèn (Insert):

Thậm chí hiện tại S5 không cung cấp bất kỳ một mặt hàng nào, chúng ta vẫn có thể đa vào thông tin S5 có địa chỉ ở Athens

ii Xoá (Delete):

Chúng ta có thể xoá số lợng hàng cung cấp nối S3 và P2 bằng cách xoá bộ tơng ứng khỏi quan hệ SP mà không bị mất các thông tin về h ng S3ã đ

iii Thay đổi (Update):

Không còn d thừa dữ liệu trong cấu trúc đ đ ã đ ợc sửa lại

 So sánh các hình 3.4 và 3.6 chúng ta thấy, ảnh hởng của sự thay đổi cấu trúc là hạn chế đợc các phụ thuộc hàm không đầy đủ và sự hạn chế này đ giải quyết đã đ ợc các khó khăn

 Sau đây là định nghĩa của dạng chuẩn thứ hai

chỉ nếu nó ở dạng chuẩn thứ nhất và mọi thuộc tính không khoá đều phụ thuộc hàm đầy đủ vào khoá chính

tham dự vào thành phần của khoá chính hoặc khóa ứng cử

 Các quan hệ SECOND và SP đều là 2NF

 Quan hệ FIRST không phải là 2NF

 Một quan hệ ở dạng chuẩn thứ nhất và không ở dạng chuẩn thứ hai luôn luôn có thể chuyển thành một tập tơng đơng các dạng chuẩn 2NF

 Ta có thể chuyển bằng cách thay thế các quan hệ bằng các ánh xạ thích hợp

 Tập các ánh xạ này là tơng đơng với quan hệ ban đầu theo nghĩa quan

hệ ban đầu luôn luôn có thể khôi phục lại bằng cách kết hợp một cách thích hợp các ánh xạ này

 Nh vậy, thông tin sẽ không bị mất mát trong quá trình chuyển (điều này là rất quan trọng)

 Nói một cách khác, quá trình là hai chiều

 Cũng cần lu ý là quan hệ 1NF mà không phải là 2NF cần phải có khoá chính là khoá ghép

 Vì thông tin không bị mất trong quá trình chuyển nên bất kỳ thông tin nào mà rút ra đợc từ cấu trúc ban đầu đều có thể đợc rút ra từ cấu trúc mới

 Tuy nhiên, điều ngợc lại là không đúng:

Cấu trúc mới có thể chứa thông tin (nh thông tin là S5 có địa chỉ

ở Athens) mà không thể biểu thị đợc trong cấu trúc ban đầu

 Với ý nghĩa này, cấu trúc mới là ánh xạ đôi chút hợp lý hơn của thế giới thực

 Tuy nhiên, cấu trúc SECOND/SP vẫn còn tồn tại một số vấn đề:

 Quan hệ SP là thoả đáng và nó là quan hệ ở dạng chuẩn thứ

bốn, do đó sẽ không xét đến nó trong mục này

 Ngợc lại, quan hệ SECOND vẫn còn cha đảm bảo sự độc lập lẫn nhau giữa các thuộc tính không khoá:

 Sơ đồ phụ thuộc của quan hệ SECOND vẫn còn phức tạp hơn sơ đồ 4NF

 Sự phụ thuộc của STATUS vào S# là phụ thuộc hàm bắc cầu (thông qua thuộc tính CITY): mỗi giá trị S# xác định một giá trị CITY và giá trị này đến lợt mình lại xác định giá trị STATUS

 Sự bắc cầu này một lần nữa lại dẫn đến những khó khăn trong các phép toán lu trữ:

i Chèn (Insert):

Không thể đa thêm thông tin về một thành phố nào đó có một giá trị trạng thái nào đó

Ví dụ:

 Không thể nói là bất kỳ h ng cung cấp nào ở thành phốã đ

Rome cũng phải có trạng thái là 50 - cho đến khi có một

h ng cung cấp có địa chỉ ở thành phố nàyã đ

ii Xoá (Delete):

Nếu xoá đi một bộ duy nhất cho một thành phố nào đó trong quan hệ SECOND, ta sẽ huỷ mất không chỉ thông tin về h ngã đ

cung cấp có liên quan mà còn huỷ mất cả thông tin về giá trị trạng thái của thành phố đó

Ví dụ:

 Nếu huỷ bộ S5 trong quan hệ SECOND, sẽ mất thông tin về giá trị trạng thái là 30 cho thành phố Athens

iii Thay đổi (Update):

Quan hệ SECOND vẫn còn chứa sự d thừa thông tin về trạng thái STATUS

 Nh vậy, nếu phải thay đổi giá trị trạng thái của London

từ 20 thành 30, sẽ hoặc phải giải quyết bàI toán tìm kiếm hoặc không nhất quán về dữ liệu

SC CS

Hình 3.8 Các phụ thuộc hàm trong các quan hệ SC và CS

CITY

Hình 3.9 Các bảng dữ liệu mẫu của các quan hệ SC và CS

 Một lần nữa, để giải quyết vấn đề này, thay thế quan hệ ban đầu (SECOND) bằng hai ánh xạ:

tơng ứng với các giá trị của quan hệ gốc SECOND ở hình 3.7

 Một lần nữa, quá trình là thuận nghịch vì SECOND là kết nối của SC và

CS

 Rõ ràng là cấu trúc mới đ giải quyết tất cả các vấn đề của các phépã đ

toán lu trữ

 So sánh các hình 3.8 và 3.6, thấy rằng ảnh hởng của việc tiếp tục thay

đổi cấu trúc là hạn chế đợc sự phụ thuộc bắc cầu của STATUS vào S#

nếu nó ở dạng chuẩn thứ hai và mọi thuộc tính không khoá

đều không phụ thuộc hàm bắc cầu vào khoá chính thông

qua các thuộc tính không khoá

X thông qua thuộc tính Z nếu thuộc tính Y phụ thuộc hàm

phụ thuộc hàm vào thuộc tính Z hoặc Y)

 Cả hai quan hệ SC và CS trên hình 3.9 đều ở dạng 3NF, còn quan hệ SECOND thì không phảI

 Một quan hệ ở dạng chuẩn thứ hai mà không ở dạng chuẩn thứ ba luôn luôn có thể chuyển thành một tập tơng đơng gồm các quan hệ ở dạng chuẩn thứ ba

 Quá trình chuyển đổi là thuận nghịch vì vậy không có sự mất mát thông tin trong khi chuyển đổi

 Tuy nhiên, tập các quan hệ 3NF có thể chứa thêm thông tin

Ví dụ: trạng thái của thành phố Rome là 50 mà không thể biểu thị đợc trong quan hệ 2NF ban đầu

Nh vậy, cấu trúc SECOND/SP biểu diễn thế giới thực tốt hơn quan hệ SECOND ở dạng 2NF

 Kết thúc mục này cần nhấn mạnh một điều rằng mức độ chuẩn hoá đối với một lợc đồ quan hệ đ cho đã đ ợc xác định bởi ngữ nghĩa (semantic) chứ không phải bởi các giá trị đ có mặt trong quan hệ tã đ ơng ứng tại một thời điểm cụ thể nào đó

 Điều quan trọng là phải biết ý nghĩa của dữ liệu rồi mới có thể đa ra nhận định hiện tại lợc đồ tơng ứng của quan hệ đó ở dạng chuẩn nào

 HQTCSDL không thể khẳng định rằng một lợc đồ quan hệ đ ở dạngã đ

chuẩn tốt nhất (3NF chẳng hạn) nếu nh cha nhận đầy đủ thông tin về các phụ thuộc dữ liệu tơng ứng

 Đối với 3NF và BCNF khi thông báo cho HQTCSDL về các phụ thuộc dữ liệu thì cũng chính là đ chỉ rõ các thuộc tính tạo nên khoá chínhã đ

 Sau đó, HQTCSDL sẽ biết các phụ thuộc hàm của tất cả các thuộc tính khác vào khoá chính và có thể thi hành sự phụ thuộc này

 Đối với quan hệ cha ở dạng chuẩn thứ ba thì cần có thêm một

số chỉ định nữa

3.4 Các quan hệ với hơn một khoá ứng cử

 Bản thân các quan hệ 1NF và 2NF không thực sự quan trọng, chúng chỉ

là các điểm trung gian trên đờng dẫn tới 3NF và 4NF

Thực vậy, không thể đa ra định nghĩa của dạng chuẩn thứ ba

mà không tham khảo đến dạng chuẩn thứ nhất và thứ hai thông qua các khái niệm về phụ thuộc hàm đầy đủ và phụ thuộc hàm bắc cầu

 Tuy nhiên những định nghĩa này không xem xét các trờng hợp nếu nh các phụ thuộc hàm này tồn tại trên các khoá ứng cử, nếu có

 Boyce và Codd đ xem xét các phụ thuộc hàm của cả các khoá ứng cửã đ

trong quan hệ và đ đã đ a ra một định nghĩa mà đợc gọi là dạng chuẩn Boyce-Codd (Boyce-Codd Normal Form - BCNF)

 Đối với quan hệ chỉ có một khoá ứng cử thì các định nghĩa 3NF và BCNF là tơng đơng.

tính quyết định (determinant) nếu một thuộc tính khác nào

đó là phụ thuộc hàm đầy đủ vào nó

 Quan hệ đ đ ã đ ợc chuẩn hoá R đợc gọi là ở dạng chuẩn BCNF (hay 3NF) nếu mọi thuộc tính quyết định đều là khoá ứng cử (candidate key)

 BCNF không nêu lên điều kiện đầu tiên quan hệ đ cho phải ở dạngã đ

chuẩn 3NF và sau đó mới thoả m n thêm điều kiện nữaã đ

Nh vậy, cần lu ý là định nghĩa BCNF không hoàn toàn tơng

đ-ơng với định nghĩa 3NF

Định nghĩa 3NF không hoàn toàn phù hợp với trờng hợp của một quan hệ có hai khoá ứng cử phủ nhau nh sẽ thấy

 Tuy nhiên, điều sau đây vẫn còn đúng:

 Bất kỳ một quan hệ nào không ở dạng chuẩn 3NF (hay BCNF) đều có thể đợc tách thành một tập tơng đơng ở dạng chuẩn 3NF (hay BCNF)

 Xét các trờng hợp khác nhau để thấy rõ tác dụng của định nghĩa