Tài liệu Bàn về tính chuẩn hoá trong các cơ sở dữ liệu hiện có pptx

Lĩnh vực Công nghệ thông tin
Bàn về tính chuẩn hóa trong các cơ sở dữ liệu hiện có
TS.Phan Đăng Cầu
Khoa Công nghệ thông tin I
Tóm tắt:
Chuẩn hóa là một khái niệm khá quan trọng trong lý thuyết cơ sở dữ liệu quan hệ và là một
trong những yêu cầu cần đợc đảm bảo khi xây dựng một cơ sở dữ liệu (CSDL). Nói một cách
trực quan thì tính chuẩn hóa bảo đảm cho CSDL loại trừ đợc tính không nhất quán và tránh
đợc sự d thừa dữ liệu. Tuy nhiên nếu khảo sát một số CSDL hiện có ở Việt nam, ta có thể
thấy rằng có khá nhiều trờng hợp tính chuẩn hóa bị vi phạm, nếu ta hiểu tính chuẩn hóa
đúng nh lý thuyết đã định nghĩa. Tuy nhiên, vì bản thân tác giả không phải là chuyên gia về
lý thuyết CSDL nên mục đích bài viết này không nhằm phê phán thực tế đó mà ngợc lại,
thông qua một số kinh nghiệm thực tế đã trải qua, tác giả muốn thuyết phục các nhà lý
thuyết và bạn đọc rằng, thực ra trong thực tế tính chuẩn hóa nên đợc hiểu một cách mềm dẻo
hơn: CSDL phải đợc bảo đảm chuẩn hóa trong thao tác và xử lý, nhng về hình thức có thể
không chuẩn hóa ở mức nào đó. Thí dụ trong một bảng dữ liệu mà có sự lặp lại của tên tỉnh
thì không nhất thiết chỉ có mã tỉnh xuất hiện nh tính chuẩn hóa đòi hỏi, mà có thể có đồng
thời cả mã tỉnh và tên tỉnh. Trong một số trờng hợp khi CSDL đợc bảo trì trong một môi tr-
ờng mà độ an toàn không cao thì đôi khi sự d thừa có thể trở thành những thông tin có ích
giúp ta hiệu chỉnh và khôi phục dữ liệu. Nếu ví von một cách hình ảnh thì việc làm này cũng
giống nh khi ta sắp lên đờng đi đến một nơi mà mọi thứ không dễ mua thì nên có thêm một số
đồ dự phòng thiết yếu, thí dụ nên mang thêm một chiếc lốp xe, cho dù các lốp xe đang dùng
còn rất tốt.
1. Khái niệm chuẩn hóa trong CSDL
Trong mục này chúng tôi trình bày sơ lợc một số khái niệm cơ bản liên quan đến tính chuẩn
hóa trong CSDL quan hệ.
1.1. Khái niệm thực thể
Thực thể là một đối tợng cụ thể tồn tại trong thế giới thực. Đối tợng này có thể là vật chất
nhìn thấy đợc và có thể tiếp xúc đợc bằng tay nh con ngời, hạt cát, mặt hàng; nhng cũng có
thể là khái niệm trừu tợng nh dự án, kế hoạch
1.2. Định nghĩa quan hệ

Cho tập hữu hạn các phần tử U = {A
1
, A
2
, ,A
n
}. Thông thờng A
i
là các thuộc tính của một
thực thể nào đó. Tập U đợc gọi là tập các thuộc tính. Mỗi phần tử của A
i
của tập U có
miền giá trị tơng ứng, ta ký hiệu là D
i
= dom(A
i
) (dom = domain, tức là miền).
Mỗi tập con R của tích Descartes (Đề-Các) của các miền giá trị dom(A
i
) với i = 1,2,3, , n
đợc gọi là một quan hệ trên U và đợc ký hiệu là R (U) hay là R (A
1
, A
2
, ,A
n
). Vậy R là
quan hệ trên tập thuộc tính U nếu:
R D
1

x D
2
x x D
n
Ta cũng có thể viết
R = {(d
1
,d
2
, ,d
n
) / d
i
D
i
, i = 1,2, ,n}
Học viện Công nghệ BCVT
Hội nghị Khoa học lần thứ 5
Các phần tử t = (d
1
,d
2
, ,d
n
) R đôi khi đợc gọi là các bộ, khi cài đặt trên máy tính thì đợc
gọi là các bản ghi (record). Phần tử thứ i của t tơng ứng với thuộc tính A
i
và đợc ký hiệu
là t.A
i

. Nói chung nếu X là một số thuộc tính nào đó trong U (tức là X U) thì ta ký hiệu
t.X là các thành phần của t tơng ứng với các thuộc tính trong X. Nh vậy thì một phần tử t
bất kỳ của R cũng có thể viết là t.U, tuy nhiên trong trờng hợp này để đơn giản ta chỉ viết là
t.
Từ định nghĩa trên ta thấy quan hệ R là một bảng hai chiều, trên cột thứ i là các giá trị của
dom(A
i
), trên mỗi dòng của bảng là bộ n giá trị của các miền giá trị của các thuộc tính A
1
,
A
2
, , A
n
. Mỗi dòng là một phần tử của quan hệ.
Khi cho tập thuộc tính U là ta đã cho bộ khung cho một tập các quan hệ. Vì vậy ngời ta th-
ờng gọi tập thuộct tính U là lợc đồ quan hệ.
Cơ sở dữ liệu quan hệ là một tập hợp các quan hệ biến thiên theo thời gian. Có nghĩa là
số lợng và nội dung các bộ trong một quan hệ thay đổi tùy thuộc vào đối tợng thực tế mà nó
mô tả.
Hệ quản trị cơ sở dữ liệu quan hệ là hệ thống phần mềm trợ giúp cho ngời sử dụng trong
việc tạo lập và khai thác cơ sở dữ liệu quan hệ.
1.3. Khóa của một quan hệ
Siêu khóa (super key) của một quan hệ R trên tập thuộc tính U = {A
1
, A
2
, ,A
n
} là tập con

S U sao cho không có hai phần tử nào của R trùng nhau trên S. Viết một cách hình thức
ta có: x,y R xy x.Sy.S
Ta thấy rằng nếu S là siêu khóa thì mọi S', sao cho S S' U , cũng là siêu khóa.
Nếu K là siêu khóa, nhng bất kỳ tập con thực sự nào của nó đều không phải là siêu khóa thì
K đợc gọi là khóa.
1.4. Phụ thuộc hàm
Phụ thuộc hàm là một khái niệm cơ bản đợc xây dựng để mô tả các ràng buộc dữ liệu trong
một cơ sở dữ liệu.
Phụ thuộc hàm trên một quan hệ
Cho tập thuộc tính U và X, Y là các tập con của U. R là một quan hệ trên U. Ta nói
rằng Y phụ thuộc hàm vào X, ký hiệu là X Y, trên R nếu với mọi phần tử p, q của
R mà chúng bằng nhau trên tập X thì cũng bằng nhau trên Y. Ta có thể diễn đạt điều này
bằng các ký hiệu toán học nh sau: p, q R, p.X=q.X p.Y = q.Y
Phụ thuộc hàm trên lợc đồ quan hệ
Cho lợc đồ quan hệ U = {A
1
, A
2
, A
n
}. Ta nói rằng Y phụ thuộc hàm vào X trên lợc đồ
quan hệ U , nếu X Y trên mọi quan hệ R trên U. Nếu sử dụng ký hiệu ta có:
R(U), p, q R ,p.X=q.X p.Y = q.Y
Nếu có một tập phụ thuộc hàm F trên một lợc đồ quan hệ U thì ta nói rằng có một sơ đồ
quan hệ W = <U,F>.
Học viện Công nghệ BCVT
Lĩnh vực Công nghệ thông tin
1.5. Chuẩn hóa lợc đồ quan hệ
Dạng chuẩn 1NF (First Normal Form)
Một lợc đồ U (hoặc một sơ đồ quan hệ W = <U,F>) ở dạng chuẩn 1NF nếu các miền

giá trị của các thuộc tính dều đơn trị. Về sau trong các dạng chuẩn 2NF, 3NF ta xét trên
sơ đồ quan hệ W = <U,F>. Tuy nhiên có nơi nào đó ta nói R thì hiểu là quan hệ bất kỳ trên
U.
Dạng chuẩn 2NF
Giả sử X và Y là hai tập con của U. Ta nói rằng Y là phụ thuộc hàm đầy đủ vào X
nếu Y phụ thuộc hàm vào X nhng Y không phụ thuộc hàm vào bất kỳ tập hợp con thực sự
nào của X.
Lợc đồ quan hệ U đợc gọi là ở dạng chuẩn 2NF nếu nó là 1NF và mỗi thuộc tính
không khóa của R là phụ thuộc hàm đầy đủ vào khóa.
Vì mỗi thuộc tính bất kỳ luôn luôn phụ thuộc hàm vào khóa. Ta có thể phát biểu lại định
nghĩa trên để nhấn mạnh hơn bản chất của dạng chuẩn 2NF:
Lợc đồ quan hệ U đợc gọi là ở dạng chuẩn 2NF nếu nó là 1NF và mỗi thuộc tính
không khóa của R là không phụ thuộc hàm vào một phần của khóa.
Dạng chuẩn 3NF
Dạng chuẩn hai cho phép loại trừ d thừa về khóa. Dạng chuẩn ba cho phép loại bỏ các phụ
thuộc bắc cầu.
Định nghĩa dạng chuẩn ba (Third normal form):
Một sơ đồ quan hệ W = <U,F> đợc gọi là ở dạng chuẩn 3NF nếu và chỉ nếu:
Nó là dạng chuẩn hai.
Các thuộc tính không khóa không phụ thuộc hàm vào tập con không phải khóa.
Cho sơ đồ quan hệ W = <U,F>, XU. Thuộc tính A trong U đợc gọi là phụ thuộc bắc cầu
vào X nếu tồn tại tập YU sao cho:
XY, YA, Y -/ X và AXY
Trong trờng hợp chỉ có một khóa, có thể định nghĩa quan hệ ở dạng chuẩn ba nh sau:
Nó là dạng chuẩn hai.
Các thuộc tính không khóa, không phụ thuộc bắc cầu vào khóa.
Ngời ta xây dựng nhiều khái niệm chuẩn hóa. Tuy nhiên khi thiết kế các CSDL trong thực tế
thì ngời ta thờng chỉ đòi hỏi là CSDL phải có dạng chuẩn 3NF.
2. Một số CSDL không thỏa tính chuẩn hóa trong thực tế
Sau đây chúng tôi chỉ ra một số trờng hợp các CSDL không thỏa tính chuẩn hóa. Đây là

những CSDL chúng tôi có dịp bảo trì hoặc tham gia xây dựng.
2.1. CSDL ngời hồi hơng Việt nam
Đầu những năm 90 chúng tôi có dịp làm việc trong dự án trợ giúp ngời hồi hơng Việt nam
của Cộng đồng châu Âu (EC). Một trong những công việc của chúng tôi là bảo trì CSDL ngời
hồi hơng Việt nam. CSDL này do Cao ủy Liên hợp quốc về ngời tị nạn ở Hồng Công cung
cấp. CSDL gồm nhiều bảng, trong đó bảng quan trọng nhất là RETURNEE.DBF chứa danh
sách những ngời hồi hơng. Danh sách này đợc cập nhật thờng xuyên. Cho đến khi kết thúc dự
Học viện Công nghệ BCVT
Hội nghị Khoa học lần thứ 5
án thì tổng số ngời hồi hơng khoảng 120 nghìn ngời. Tệp RETURNEE.DBF có nhiều trờng,
ví dụ số cao ủy gồm 12 ký tự, họ tên, mã tỉnh, mã huyện, tên tỉnh, tên huyện, làng xã Dễ
thấy rằng các trờng tên tỉnh và tên huyện là d thừa vì trong tệp này đã có mã tỉnh, mã huyện,
đồng thời có các tệp danh sách tỉnh, danh sách huyện. Tệp này có khóa là số cao ủy. Nh vậy
ta có thể thấy là tên tỉnh phụ thuộc hàm vào mã tỉnh, tên huyện phụ thợc hàm vào mã tỉnh và
mã huyện. Nh vậy CSDL này không thỏa tính chuẩn hóa 3NF. Vào đầu những năm 90 cấu
hình của các máy vi tính còn rất thấp: đĩa cứng chỉ khoảng 40 M, bộ nhớ trong 1 M. Nh vậy
với tệp hàng trăm nghìn bản ghi thì sự d thừa là rất đáng kể. Ban đầu bản thân chúng tôi cũng
thấy rằng thiết kế nh vậy là không hợp lý. Tuy nhiên về sau trong quá trình bảo trì, chúng tôi
nhận ra rằng có lúc dữ liệu d thừa lại trở thành những thông tin có ích giúp chúng tôi hiệu
chỉnh số liệu. Hàng tháng khi nhận số liệu mới chúng tôi phải kiểm tra kỹ trớc khi cập nhật.
Nhiều lúc xảy ra trờng hợp có ngời trong danh sách mới thực ra đã có trong danh sách cũ,
nhng chỉ vì có một số sai sót trong mã cao uỷ hay mã tỉnh, mã huyện. Lúc này nếu kiểm tra
bằng mắt có thể dễ dàng phát hiện ra sai sót nhờ vào thông tin d thừa. Mã tỉnh, mã huyện là
các con số không có tính gợi nhớ: 01 là Hà nội, 02 là Hải Phòng, 03 là Tp HCM Nếu chỉ
căn cứ vào mã số thì chỉ cần một chút sai sót thì có thể chuyển một ngời từ Hà Nội sang tỉnh
khác. Còn nếu có thêm thông tin tên tỉnh thì rất khó có thể xẩy ra sai sót tơng tự. Thật vậy,
nếu không phải là cố tình thì rất khó bằng một vài cú gõ nhầm để chuyển từ "Hà Nội" thành
"Hải Phòng".
2.2. Chơng trình quản lý đào tạo ngời hồi hơng Việt nam
Cũng vào những năm 90 chúng tôi viết phần mềm quản lý đào tạo cho dự án ngời hồi hơng

với sự giúp đỡ của chuyên gia thiết kế ngời Anh. Lúc đầu CSDL đợc thiết kế bảo đảm tính
chuẩn hóa. Chơng trình này đợc cài đặt ở các tỉnh, do nhiều ngời thao tác. Ban đầu chúng tôi
đã bảo mật dữ liệu bằng cách chỉ cho ngời sử dụng thao tác với dữ liệu thông qua chơng
trình. Để làm điều này, chúng tôi mã hóa các tệp CSDL để ngời dùng không thể mở đợc.
Các tệp này chỉ đợc giải mã khi chơng trình bắt đầu hoạt động. Tuy nhiên điều này cũng gây
nên một trở ngại: các tệp dữ liệu *.DBF thờng hay bị hỏng phần đầu file khi có sự cố điện
bất thờng hoặc virus. Nếu là tệp không mã hóa thì có thể dùng các tiện ích NC khôi phục,
còn nếu tệp đã mã hóa thì đành chịu. Chính vì vậy chúng tôi đành khuyên ngời dùng tự ý
thức khi sử dụng và để nguyên tệp không mã hóa. Khi có nhiều ngời thao tác thì dữ liệu th-
ờng có sai sót. Về sau đối với những mã số mà chỉ cần một sai sót nhỏ là chuyển thành một
mã khác ví dụ 01, 02, 03 thì chúng tôi phải lu thêm thông tin giải thích bên cạnh để dựa
vào các thông tin này hiệu chỉnh số liệu khi có sai sót. Ví dụ bên cạnh số cao uỷ còn có thêm
họ tên, bên cạnh mã tỉnh còn có tên tỉnh Và nh vậy CSDL trở thành không chuẩn hóa.
2.3. Chơng trình kế toán quản lý các công trình xây lắp bu điện
Trong năm 2002, do nhu cầu nảy sinh từ một lớp bồi dỡng tin học cho các kế toán viên,
chúng tôi đã viết phiên bản thử nghiệm chơng trình kế toán quản lý các công trình xây lắp bu
điện. Chơng trình đó hiện nay vẫn đợc công ty VTN sử dụng và đã giảm nhẹ đợc một số công
việc của các kế toán viên. Khi thiết kế chơng trình này chúng tôi xây dựng nhiều bảng dữ
liệu, ví dụ danh sách các công ty đối tác, danh sách các công trình, danh sách các ban quản
lý, danh sách các tài khoản, tệp chứa thông tin kế toán liên quan giữa công ty và các đối tác,
tệp chứa thông tin kế toán giữa công ty với Tổng cồng ty Nếu theo quan điểm chuẩn hóa thì
trong tệp QLCT.DBF chứa thông tin kế toán với các đối tác chỉ cần có mã công ty, mã công
trình, mã tài khoản nợ, mã tài khoản có Tuy nhiên chúng tôi thấy rằng các mã công trình
và mã các công ty là những con số không có tính gợi nhớ, rất dễ bị nhầm lẫn từ công trình
này sàng công trình khác, từ đơn vị này sang đơn vị khác, ví dụ đó là các con số 561, 562,
5601, 5602 hay 22, 23, Sự nhầm lẫn trong kế toán phải đợc loại trừ đến mức cao nhất. Do
Học viện Công nghệ BCVT
Lĩnh vực Công nghệ thông tin
đó ngoài mã công trình và mã công ty chúng tôi thêm các trờng tên công ty và tên công trình
vào trong tệp QLCT.DBF. Đối với các tài khoản thì sự khác biệt khá rõ ràng: ví dụ 1111 là

tài khoản tiền mặt, 4141 là Quỹ đầu t phát triển, 1131 Tiền Việt nam đang chuyển nghĩa là
khó nhầm từ tài khoản này sang tài khoản khác. Do vậy đối với các tài khoản thì chúng tôi
cho rằng không cần có thêm thông tin phụ trợ nh tên tài khoản chẳng hạn. Và nh thế trong
tệp QLCT.DBF chỉ có các mã tài khoản mà không có trờng tên tài khoản. CSDL nh thế này
cũng không thỏa tính chuẩn hóa. Chúng tôi chấp nhận sự d thừa dữ liệu để có sự an toàn cao
hơn.
3. Một số nhận xét về các CSDL không thỏa tính chuẩn hoá trong thực tế
Một CSDL chuẩn hóa sẽ bảo đảm đợc tính nhất quán dữ liệu và tránh đợc sự d thừa thông tin.
Trong các ví dụ chúng tôi nêu ra trên đây thì rõ ràng có hiện tợng d thừa dữ liệu. Tuy nhiên
tính nhất quán thì vẫn đợc bảo đảm. Trong các CSDL này các trờng đợc thêm vào chỉ có tác
dụng nh thông tin dự phòng. Khi truy xuất thông tin để làm các báo cáo thì các trờng này
không tham gia. Ví dụ trong một danh sách nhân sự có cả mã tỉnh và tên tỉnh thì khi làm báo
cáo ta chỉ lấy mã tỉnh từ tệp danh sách nhân sự, còn tên tỉnh sẽ đợc lấy từ tệp danh sách tỉnh
bên ngoài, vì vậy sẽ tránh đợc hiện tợng không nhất quán trong tên tỉnh (Trong danh sách
hàng ngàn ngời với hàng ngàn tên tỉnh thì dễ có sự không nhất quán). Hay khi nhập số liệu
cũng vậy, ngời sử dụng không cần nhập các trờng phụ trợ mà các trờng này sẽ đợc tự động
nhập thông tin. Vậy ta có thể nói rằng tuy về hình thức các CSDL đã nêu không chuẩn hóa
nhng về mặt thao tác thì vẫn bảo đảm tính chuẩn hóa. Ngày nay dung lợng các thiết bị
nhớ đã tăng lên đáng kể. Việc chấp nhận d thừa dữ liệu để tăng độ an toàn theo chúng tôi
nghĩ là có ích và nên làm trong một số trờng hợp.
Khi nào thì cần thêm các trờng dự phòng?
Đối với các trờng mà chỉ một sự thay đổi nhỏ có thể làm sai lệch hoàn toàn ý nghĩa của trờng
đó, ví dụ đang là mã công ty này trở thành mã công ty khác, mã công trình này thành mã
công trình khác thì nên thêm trờng dự phòng.
4. Kết luận
Trong nhiều năm cố gắng áp dụng những kiến thức lý thuyết đã học vào công việc thực tế, tôi
cảm thấy câu nói nổi tiếng của Gớt thật chí lý "Mọi lý thuyết đều là màu xám, chỉ có cây đời
là mãi mãi xanh tơi". Cho dù các tính toán lý thuyết có đợc thực hiện cẩn thận và chính xác
đến đâu thì nó vẫn phải đợc kiểm nghiệm bằng thực tế. Chính vì vậy khi đánh giá các vấn dề
thực tế trong nhiều trờng hợp chúng ta không nên chỉ dựa hoàn toàn vào các tiêu chuẩn lý

thuyết đặt ra, mà phải có cách nhìn mềm dẻo hơn. Có lẽ trong hai tiêu chuẩn: thỏa mãn các
quy định của lý thuyết và hoạt động hiệu quả thì tính hiệu quả nên đợc u tiên hơn.
Trở lại vấn đề thiết kế các CSDL trong thực tế: có lẽ rất nhiều ngời không thích sự d thừa dữ
liệu. Điều này nói chung là đúng, sự vừa đủ vẫn đỡ lãng phí hơn sự d thừa. Tuy nhiên đó là
trờng hợp lý tởng, khi mọi thứ hoạt động hoàn hảo. Chúng ta thờng chỉ nói đến u điểm của sự
vừa đủ, nhng lại cha thấy nhợc điểm của nó: vừa đủ có nghĩa là nếu có một thành phần trục
trặc thì trở thành thiếu. Chính lúc đó thì sự d thừa lại phát huy tác dụng, giúp chúng ta khắc
phục sự cố. Nhớ lại thời bao cấp, chúng ta phải dùng rất nhiều hộp thùng để đựng các thứ d
thừa. Nhng nhiều lúc những thứ d thừa đó lại trở thành những thứ có ích cho chúng ta.
Sơ lợc về tác giả:
Ts. Phan Đăng Cầu, sinh năm 1951.
Học viện Công nghệ BCVT
Hội nghị Khoa học lần thứ 5
Nhận học vị Cử nhân toán (1976) và Tiến sĩ toán (1987) tại Hungary.
Hiện là giảng viên Khoa Công nghệ Thông tin I, Học Viện CNBCVT.
Lĩnh vực quan tâm và nghiên cứu: Cấu trúc dữ liệu và giải thuật, Toán rời rạc, Công nghệ
phần mềm, Phơng pháp số, Thống kê ứng dụng và CSDL ứng dụng.
Điện thoại: Cq. 8 545 604, Nr. 8347 209, Email:
Học viện Công nghệ BCVT