Khi nào bạn nên không chuẩn hóa?

Tôi nghĩ rằng tất cả chúng ta đều quen thuộc với chuẩn hóa cơ sở dữ liệu .

Câu hỏi của tôi là: một số hướng dẫn mà bạn sử dụng khi bạn muốn không chuẩn hóa các bảng là gì?

Không chuẩn hóa khi hoạt động OLAP, chuẩn hóa khi OLTP (từ bài viết được liên kết trong phần Không chuẩn hóa)

Cơ sở dữ liệu dành cho xử lý giao dịch trực tuyến (OLTP) thường được chuẩn hóa hơn so với cơ sở dữ liệu dành cho xử lý phân tích trực tuyến (OLAP). Các ứng dụng OLTP được đặc trưng bởi một khối lượng lớn các giao dịch nhỏ như cập nhật hồ sơ bán hàng tại quầy thanh toán siêu thị. Kỳ vọng là mỗi giao dịch sẽ rời khỏi cơ sở dữ liệu ở trạng thái nhất quán. Ngược lại, cơ sở dữ liệu dành cho hoạt động OLAP chủ yếu là cơ sở dữ liệu "đọc chủ yếu". Các ứng dụng OLAP có xu hướng trích xuất dữ liệu lịch sử đã tích lũy trong một khoảng thời gian dài. Đối với các cơ sở dữ liệu như vậy, dữ liệu dư thừa hoặc "không chuẩn hóa" có thể tạo điều kiện cho các ứng dụng kinh doanh thông minh. Cụ thể, các bảng chiều trong lược đồ sao thường chứa dữ liệu không chuẩn hóa. Dữ liệu không chuẩn hóa hoặc dự phòng phải được kiểm soát cẩn thận trong quá trình trích xuất, chuyển đổi, tải (ETL) và người dùng không được phép xem dữ liệu cho đến khi nó ở trạng thái nhất quán. Thay thế chuẩn hóa cho lược đồ sao là lược đồ bông tuyết. Trong nhiều trường hợp, nhu cầu không chuẩn hóa đã giảm đi khi máy tính và phần mềm RDBMS trở nên mạnh mẽ hơn, nhưng vì khối lượng dữ liệu thường tăng lên cùng với hiệu suất phần cứng và phần mềm, cơ sở dữ liệu OLAP vẫn thường sử dụng các lược đồ không chuẩn hóa.

Việc không chuẩn hóa cũng được sử dụng để cải thiện hiệu suất trên các máy tính nhỏ hơn như trong máy tính tiền và thiết bị di động, vì chúng có thể chỉ sử dụng dữ liệu để tra cứu (ví dụ: tra cứu giá). Việc không chuẩn hóa cũng có thể được sử dụng khi không có RDBMS cho nền tảng (như Palm) hoặc không có thay đổi nào được thực hiện đối với dữ liệu và phản hồi nhanh là rất quan trọng.

Bình thường hóa cho đến khi nó đau, không chuẩn hóa cho đến khi nó hoạt động (nghĩa là: hiệu suất trở nên chấp nhận được) :)

Một lý do có thể hợp lý để áp dụng sự không chuẩn hóa có kiểm soát là nếu nó cho phép bạn áp dụng một số ràng buộc toàn vẹn cho dữ liệu mà nếu không thì không thể. Hầu hết các DBMS SQL có hỗ trợ cực kỳ hạn chế cho các ràng buộc nhiều bảng. Trong SQL đôi khi cách hiệu quả duy nhất để thực hiện các ràng buộc nhất định là đảm bảo rằng các thuộc tính liên quan đến ràng buộc đều có trong cùng một bảng - ngay cả khi chuẩn hóa sẽ ra lệnh rằng chúng thuộc các bảng riêng biệt.

Sự không chuẩn hóa có kiểm soát có nghĩa là các cơ chế được thực hiện để đảm bảo rằng sự không nhất quán không thể phát sinh do dữ liệu dư thừa. Chi phí của các kiểm soát bổ sung này và rủi ro của dữ liệu không nhất quán cần được xem xét khi quyết định liệu việc không chuẩn hóa có đáng giá hay không.

Một lý do phổ biến khác cho việc không chuẩn hóa là cho phép một số thay đổi trong cấu trúc lưu trữ hoặc cho phép một số tối ưu hóa vật lý khác mà DBMS không cho phép. Theo nguyên tắc Độc lập dữ liệu vật lý, DBMS phải có phương tiện để cấu hình các cấu trúc lưu trữ nội bộ mà không cần thay đổi cách biểu diễn logic của dữ liệu trong cơ sở dữ liệu. Thật không may, nhiều DBMS rất hạn chế các tùy chọn triển khai vật lý có sẵn cho bất kỳ lược đồ cơ sở dữ liệu nào. Họ có xu hướng thỏa hiệp độc lập cơ sở dữ liệu vật lý bằng cách chỉ hỗ trợ triển khai dưới mức tối ưu của mô hình logic mong muốn.

Điều này là hiển nhiên nhưng vẫn cần phải nói: trong mọi trường hợp, đó chỉ là những thay đổi trong các tính năng triển khai vật lý có thể quyết định hiệu năng - các tính năng như cấu trúc dữ liệu nội bộ, tệp, lập chỉ mục, phần cứng, v.v. Chuẩn hóa và không chuẩn hóa không liên quan gì đến hiệu suất hoặc tối ưu hóa lưu trữ.

Không chuẩn hóa nếu bạn thường xuyên truy cập dữ liệu tính toán, như được đề xuất trong câu trả lời cho câu hỏi này . Chi phí lưu trữ và duy trì dữ liệu tính toán thường sẽ thấp hơn chi phí tính toán lại nhiều lần nếu hồ sơ tải của bạn nặng.

Tôi thường xuyên không chuẩn hóa để tôi có thể thực thi tính toàn vẹn dữ liệu với các ràng buộc. Một ví dụ là một câu hỏi gần đây trên trang web này - tôi sao chép một cột trong một bảng khác, để tôi có thể sử dụng một ràng buộc CHECK để so sánh nó với một cột khác. Một ví dụ khác về kỹ thuật này là bài viết trên blog của tôi .

Bạn không thể sử dụng các ràng buộc CHECK để so sánh các cột trong các hàng khác nhau hoặc trong các bảng khác nhau, trừ khi bạn bao bọc chức năng đó trong các UDF vô hướng được gọi là một ràng buộc CHECK. Điều gì xảy ra nếu bạn thực sự cần so sánh các cột trong các hàng khác nhau hoặc trong các bảng khác nhau để thực thi quy tắc kinh doanh? Ví dụ: giả sử bạn biết giờ làm việc của bác sĩ và bạn muốn chắc chắn rằng tất cả các cuộc hẹn phù hợp trong giờ làm việc? Tất nhiên, bạn có thể sử dụng trình kích hoạt hoặc quy trình được lưu trữ để thực hiện quy tắc kinh doanh này, nhưng không phải trình kích hoạt cũng như quy trình được lưu trữ có thể đảm bảo 100% rằng tất cả dữ liệu của bạn sạch sẽ - ai đó có thể vô hiệu hóa hoặc thả trình kích hoạt của bạn, nhập một số dữ liệu bẩn và kích hoạt lại hoặc tạo lại kích hoạt của bạn. Ngoài ra ai đó có thể trực tiếp sửa đổi bảng của bạn bỏ qua các thủ tục được lưu trữ.

Hãy để tôi trình bày cách thực hiện quy tắc kinh doanh này chỉ bằng các ràng buộc FK và CHECK - điều đó sẽ đảm bảo rằng tất cả dữ liệu thỏa mãn quy tắc kinh doanh miễn là tất cả các ràng buộc được tin cậy.

Tuy nhiên, một ví dụ khác là một cách để thực thi rằng các khoảng thời gian không có khoảng trống và không có sự chồng chéo .