Thứ Tư, 10 tháng 2, 2016

Phát triển HTTT kế toán bằng MS Access - Chương 2 - Dạng chuẩn ba

James Perry, Richard Newmark


Chương 2
Cơ sở dữ liệu và hệ thống kế toán


Dạng chuẩn ba


Mục tiêu thiết kế cơ sở dữ liệu quan hệ là tạo bảng ở dạng chuẩn ba. Một bảng ở dạng chuẩn ba nếu bảng đó ở dạng chuẩn hai và mọi phụ thuộc bắc cầu đều được loại bỏ. Một phụ thuộc bắc cầu (transitive dependency) tồn tại trong bảng nếu thuộc tính B xác định thuộc tính C, và thuộc tính C xác định thuộc tính D.

Rất có thể bạn đã nghe lời biểu đạt mà có thể giúp bạn hiểu và nhớ sự khác biệt giữa 2NF và 3NF. Lời này dùng để nhân chứng tuyên thệ trước tòa: “… nói sự thật, toàn bộ sự thật, và không gì ngoài sự thật.” Dạng chuẩn hai tương tự với đoạn “toàn bộ sự thật” – từng thuộc tính phụ thuộc toàn bộ khóa chính. Tương tự, dạng chuẩn ba tương đương với “và không gì ngoài sự thật”. Từng thuộc tính chỉ phụ thuộc khóa chính và không vào thuộc tính nào khác trong quan hệ. Chẳng hạn, hãy xét bảng hóa đơn trong Hình 2.13.

Hình 2.13. Bảng hóa đơn ở dạng chuẩn hai.

Khóa chính của bảng hóa đơn là InvoiceID. Vì chỉ một khách hàng có thể được gán cho một mã hóa đơn cụ thể (tức giá trị trong trường InvoiceID), mã hóa đơn xác định duy nhất ngày xuất hóa đơn, ngày đặt hàng, mã đơn mua hàng của khách hàng, mã nhân viên, và nhà vận chuyển. Không có nhóm lặp nào trong bảng. Vì thế bảng hóa đơn ở dạng chuẩn một. Hơn nữa, bảng đó ở dạng chuẩn hai vì mọi thuộc tính đều phụ thuộc khóa chính. Tuy nhiên, bảng đó không ở dạng chuẩn ba, vì mọi thuộc tính không chỉ phụ thuộc hàm vào thuộc tính InvoiceID. Có một phụ thuộc bắc cầu trong thiết kế này. InvoiceID xác định CustomerID, và CustomerID tiếp tục xác định cột Customer. Hình 2.14 cho thấy sự phụ thuộc trong bảng hóa đơn.


Hình 2.14. Các quan hệ bắc cầu trong bảng hóa đơn thể hiện ở Hình 2.13.

Các mũi tên bên trên các ô thuộc tính cho thấy có phụ thuộc hàm giữa các thuộc tính và khóa chính. Những quan hệ đó là tốt. Tuy nhiên, mũi tên bên dưới các ô cho thấy quan hệ bắc cầu giữa CustID (thuộc tính định thức) và Customer. Cách loại bỏ dễ nhất phụ thuộc bắc cầu là tạo một bảng khác chứa tối thiểu thuộc tính định thức và mọi thuộc tính phụ thuộc thuộc tính định thức đó. Một khi loại được phụ thuộc bắc cầu, bảng sẽ ở 3NF. Trường CustID trở thành khóa ngoại để nối hóa đơn với một khách hàng. Để tuân thủ 3NF, các bảng mới có thể được cấu trúc như sau:

        tblInvoice(InvoiceID, InvoiceDate, OrderDate, CustID, EmployeeID)
        tblCustomer(CustID, Customer)

Dạng chuẩn ba áp đặt một qui tắc phi hình thức phát biểu rằng bảng chỉ lưu một và chỉ một sự việc mà thôi. Trước khi phân rã tblInvoice thành 2 bảng, tblInvoice chứa 2 sự việc: một sự việc về hóa đơn (InvoiceDate, OrderDate, …) và một sự việc về khách hàng (Customer). Sau khi tạo 2 bảng từ 1 bảng, cấu trúc bảng mới (thể hiện ở trên) chỉ chứa một sự việc.

Không có nhận xét nào:

Đăng nhận xét