Đầu tiên, cần nói về một số thuật ngữ trong conceptual modeling:

• Relation: là một quan hệ, sử dụng trong đại số quan hệ. Relation có ý nghĩa "tương đương" table - bảng mà ta hay nói.
• Attribute: là thuộc tính của relation, tương đương với column - cột mà ta hay dùng.
• Predicate: là một diễn giải dự kiến hay một phát biểu về quy tắc mà dữ liệu trong relation phải tuân thủ. Nói cách khác, nó chính là nghiệp vụ mà mô hình dữ liệu đang cố gắng mô hình hóa.

Giả sử, ta có relation S như sau:

S(SNO, SNAME, STATUS, CITY)

Ngoài key là SNO, ta có thêm một Functional Dependency (FD): CITY => STATUS.

FD trên có thể đọc là: CITY "suy ra" STATUS. Nghĩa là, với mỗi giá trị của CITY, ta xác định được duy nhất một giá trị của STATUS. Do đó, STATUS phụ thuộc vào CITY.

Relation S có data mẫu như sau:

Ta thấy rằng S đạt 2NF nhưng vi phạm 3NF do có phụ thuộc bắc cầu SNO => CITY và CITY => STATUS, vì thế nó gặp phải những vấn đề về dư thừa dữ liệu. Ta thực hiện phân rã S thành hai relation sau:

• SNC = S { SNO , SNAME , CITY }
• CT = S { CITY , STATUS }

Lúc này, SNC và CT đều đạt chuẩn 3NF.

Chú ý rằng, quá trình phân rã này là không mất mát (nonloss).

SNC được mô tả với predicate 1: Nhà cung cấp SNO có tên SNAME và được đặt tại thành phố CITY.

CT được mô tả với predicate 2: Thành phố CITY có trạng thái STATUS.

Bây giờ, giả sử ta có predicate 3: Có thể có những thành phố CITY có trạng thái STATUS mà không có nhà cung cấp SNO nào được đặt tại thành phố đó.

Giả sử ta có thành phố (Rome, 10) nhưng không có nhà cung cấp nào tại đây.

Thiết kế S

Relation S không thể đáp ứng được yêu cầu này do S yêu cầu bất cứ thành phố nào trong đó đều phải có nhà cung cấp SNO.

Điều này cho thấy S là không đầy đủ hoặc không phù hợp để biểu diễn toàn bộ dữ liệu thực tế. Nếu ta chỉ sử dụng relvar S, ta không thể lưu trữ thông tin về những thành phố như Rome trong cơ sở dữ liệu nếu thành phố đó không có nhà cung cấp nào. Như vậy, thiết kế chỉ bao gồm S là sai trong trường hợp cần lưu trữ thông tin về các thành phố mà không có nhà cung cấp.

Đây là sự thiếu sót trong thiết kế mô hình dữ liệu vì nó không thể phản ánh đầu đủ các khả năng có thể xảy ra trong thực tế.

Thiết kế SNC và CT

Tập hợp hai bảng đã phân rã và đạt chuẩn 3NF này hoàn toàn có thể đáp ứng được đúng yêu cầu nghiệp vụ thiếu sót trong S.

Tương tự như thế, giả sử có thể có nhà cung cấp có thể được đặt trong một thành phố ngay cả khi thành phố đó không có status thì thiết kế chuẩn hóa vẫn đáp ứng được còn phi chuẩn thì không bởi vì predicate của nó "mọi thành phố mà trong đó đặt một nhà cung cấp đều phải có trạng thái".

Ta cùng phân tích sâu hơn.

Nếu đọc các bài liên quan tới chuẩn hóa dữ liệu tại đây, bạn sẽ luôn thấy rằng chúng tôi nhấn mạnh "quá trình chuẩn hóa là quá trình không mất mát thông tin". Vậy tại sao với thiết kế SNC và CT, ta lại có thể lưu được những thành phố như (Rome, 10) mà không có nhà cung cấp SNO nào được đặt trong đó? Đây chẳng phải là sự không cân bằng về mặt thông tin sao?

Đúng là quá trình chuẩn hóa là quá trình không mất mát thông tin, bạn có thể join SNC và CT lại để tái tạo dữ liệu của S, nhưng quá trình này tạo ra một mô hình có thể chứa đựng được nhiều thông tin hơn ban đầu nhờ khả năng "chỉnh sửa sai sót về mặt logic" của nó.

Và giả sử, ngay cả khi yêu cầu của ta chỉ có predicate 1 và predicate 2, không có predicate 3, nói cách khác, S phản ánh đúng dữ liệu thì mô hình chuẩn hóa SNC và CT vẫn mang lại lợi ích lớn, đó là giảm sự dư thừa dữ liệu trong mô hình S. Sự giảm dư thừa dữ liệu này giúp cho ta tránh được hiện tượng Update Anomalies.

Tổng kết

Tóm lại, chuẩn hóa cơ sở dữ liệu nhằm hai mục đích chính:

• Sửa một thiết kế không chính xác về mặt logic

• Giảm thiểu dư thừa trong một thiết kế đúng đắn về mặt logic

Mong những phản hồi, trao đổi từ phía người đọc.

Trân trọng.