SQL Biểu mẫu thông thường của miền - miền (DK / NF) và hình dạng bất thường - núm vú

Sau khi một cơ sở dữ liệu SQL ở dạng bình thường thứ ba, bạn đã loại bỏ hầu hết, nhưng không phải tất cả, cơ hội sửa đổi bất thường. Các hình thức thông thường vượt ra ngoài thứ ba được định nghĩa để thu nhỏ những lỗi còn lại.

Mẫu bình thường của tên miền (DK / NF)

Mẫu bình thường Boyce-Codd (BCNF), dạng bình thường thứ tư (4NF) và dạng bình thường thứ 5 (5NF) là những ví dụ của các dạng như vậy. Mỗi hình thức loại bỏ một dị thường sửa đổi có thể nhưng không đảm bảo ngăn ngừa được tất cả các dị thường sửa đổi có thể. Hình thức bình thường của tên miền, tuy nhiên, cung cấp bảo đảm như vậy.

Một mối quan hệ nằm trong hình thức bình thường của tên miền (DK / NF) nếu mọi ràng buộc về mối quan hệ này là hậu quả hợp lý của việc định nghĩa các khóa và tên miền. Hạn chế trong định nghĩa này là bất kỳ quy tắc nào đủ chính xác để bạn có thể đánh giá liệu nó có đúng hay không. Phím là một số nhận dạng duy nhất của một hàng trong một bảng. Một miền là tập các giá trị cho phép của một thuộc tính.

Hãy xem cơ sở dữ liệu này, có trong 1NF, để xem bạn phải làm gì để đưa cơ sở dữ liệu đó vào DK / NF.

Khách hàng xác định sản phẩm Sản phẩm xác định giá

Customer_ID phải là một số nguyên Bảng:

BÁN HÀNG (Customer_ID, Product, Price)

• Key:

• Customer_ID

• > 1000

Để thi hành Hạn chế 3 (Customer_ID phải là một số nguyên lớn hơn 1000), bạn chỉ cần xác định tên miền cho Customer_ID để kết hợp ràng buộc này. Điều đó làm cho ràng buộc một hậu quả hợp lý của miền của cột CustomerID. Sản phẩm phụ thuộc vào Customer_ID, và Customer_ID là một chìa khóa, do đó bạn không có vấn đề với Hạn chế 1, đó là một hậu quả hợp lý của định nghĩa của khóa.

Hạn chế 2 là một vấn đề. Giá phụ thuộc vào (là hậu quả hợp lý của) Sản phẩm và Sản phẩm không phải là chìa khoá. Giải pháp là phân chia bảng SALES thành hai bảng. Một bảng sử dụng Customer_ID làm khoá và một sản phẩm khác sử dụng Sản phẩm làm khoá. Cơ sở dữ liệu, ngoài việc có trong 3NF, cũng có trong DK / NF.

Thiết kế cơ sở dữ liệu của bạn để chúng ở trong DK / NF nếu có thể. Nếu bạn có thể làm điều đó, việc thực thi các hạn chế chính và tên miền sẽ gây ra tất cả các ràng buộc, và không thể sửa đổi các dị thường. Nếu cơ cấu của cơ sở dữ liệu được thiết kế để ngăn cản bạn đưa nó vào DK / NF, thì bạn phải xây dựng các ràng buộc vào chương trình ứng dụng sử dụng cơ sở dữ liệu. Cơ sở dữ liệu chính nó không đảm bảo rằng các khó khăn sẽ được đáp ứng.

Hình dạng bất thường

Như trong cuộc sống, vì vậy trong cơ sở dữ liệu: Đôi khi bất thường trả giá.Bạn có thể nhận được mang đi với bình thường hóa và đi quá xa. Bạn có thể chia nhỏ cơ sở dữ liệu thành nhiều bảng mà toàn bộ điều trở nên khó sử dụng và không hiệu quả. Hiệu suất có thể giảm xuống. Thông thường cấu trúc tối ưu cho cơ sở dữ liệu của bạn là hơi denormalized.

Trong thực tế, cơ sở dữ liệu thực tế (những cái thực sự lớn, anyway) hầu như không bao giờ bình thường hóa tất cả các cách để DK / NF. Bạn muốn bình thường hoá cơ sở dữ liệu mà bạn thiết kế càng nhiều càng tốt, để loại trừ khả năng tham nhũng dữ liệu là kết quả của các dị thường sửa đổi.

Sau khi bạn bình thường hóa cơ sở dữ liệu càng xa càng tốt, hãy thực hiện một số truy xuất như là một lần chạy khô. Nếu hiệu suất không đạt yêu cầu, hãy kiểm tra thiết kế của bạn để xem liệu denormalization chọn lọc sẽ cải thiện hiệu suất mà không bị mất tính toàn vẹn. Bằng cách cẩn thận thêm sự thừa trong các vị trí chiến lược và denormalizing chỉ đủ , bạn có thể đến một cơ sở dữ liệu đó là cả hai hiệu quả và an toàn từ dị thường.