Bàn về tính chuẩn hóa trong các cơ sở dữ liệu hiện có

Bàn về tính chuẩn hóa trong các cơ sở dữ liệu hiện có

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 = {A1, A2, ,An} Thông thờng Ai 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 Ai của tập U có miền giá trị tơng ứng, ta ký hiệu là Di = dom(Ai) (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(Ai) 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 (A1, A2, ,An) Vậy R là quan hệ trên tập thuộc tính U nếu:

R  D1 x D2 x x Dn

Ta cũng có thể viết

R = {(d1,d2, ,dn) / di  Di, i = 1,2, ,n}

Các phần tử t = (d1,d2, ,dn)  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 Ai và đợc ký hiệu

là t.Ai 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(Ai), 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 A1,

A2, , An 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 = {A1, A2, ,An} 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  xy  x.Sy.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 = {A1, A2, An} 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>.

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

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>, XU 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 YU sao cho:

XY, YA, Y -/ X và AXY

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ự

á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

đó 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

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: minhly@fpt.vn