Tại sao nhiều thiết kế bỏ qua chuẩn hóa trong RDBMS?

Tôi đã thấy nhiều thiết kế rằng bình thường hóa không phải là sự cân nhắc đầu tiên trong giai đoạn ra quyết định.

Trong nhiều trường hợp, các thiết kế đó bao gồm hơn 30 cột và cách tiếp cận chính là "đặt mọi thứ vào cùng một vị trí"

Theo những gì tôi nhớ bình thường hóa là một trong những điều đầu tiên, quan trọng nhất, vậy tại sao đôi khi nó lại bị giảm dễ dàng như vậy?

Chỉnh sửa:

Có đúng là các kiến ​​trúc sư và chuyên gia giỏi chọn một thiết kế không chuẩn hóa trong khi các nhà phát triển không có kinh nghiệm chọn ngược lại? Các đối số chống lại việc bắt đầu thiết kế của bạn với bình thường hóa trong tâm trí là gì?

Điều thú vị về chủ đề Q & A này là thực sự có 3 câu hỏi. Mọi người đã trả lời một câu hỏi khác nhau và hầu như không ai trả lời câu hỏi đầu tiên:

1. Tại sao không có một số cơ sở dữ liệu trong tự nhiên được chuẩn hóa?
2. Tại sao / khi nào một cơ sở dữ liệu chuẩn hóa nên được chuẩn hóa ?
3. Trong những tình huống có hại hoặc không cần thiết để bình thường hóa ở nơi đầu tiên?

Người đọc thông báo sẽ lưu ý rằng đây là những câu hỏi rất khác nhau và tôi sẽ cố gắng trả lời riêng từng câu hỏi trong khi tránh quá nhiều chi tiết. "Quá nhiều", ý tôi là tôi không nghĩ rằng đây là bối cảnh thích hợp để tiến hành một cuộc tranh luận mở rộng về giá trị của các lập luận khác nhau có lợi cho hoặc chống lại bình thường hóa; Tôi chỉ đơn giản là sẽ giải thích những tranh luận đó là gì, có thể liệt kê một vài cảnh báo và lưu lại triết lý cho những câu hỏi cụ thể hơn, nếu chúng xuất hiện.

Ngoài ra, trong câu trả lời này, tôi giả định rằng "bình thường hóa" ngụ ý "BCNF, 3NF hoặc ít nhất là 2NF" , vì đó là mức độ chuẩn hóa mà các nhà thiết kế thường hướng tới. Thật hiếm khi thấy các thiết kế 4NF hoặc 5NF; mặc dù chúng chắc chắn không phải là mục tiêu bất khả thi, nhưng chúng quan tâm đến ngữ nghĩa của các mối quan hệ hơn là chỉ đại diện của chúng , đòi hỏi nhiều kiến ​​thức hơn về miền.

Vì vậy, trở đi trở lên:

1. Tại sao một số cơ sở dữ liệu trong tự nhiên được chuẩn hóa?

Câu trả lời cho điều này có thể là "bởi vì họ không nên", nhưng đưa ra giả định đó ngay lập tức là một công việc thám tử khá khó chịu. Chúng ta sẽ không đạt được nhiều tiến bộ như một xã hội nếu chúng ta luôn vận hành với giả định rằng bất cứ điều gì, nên có.

Những lý do thực sự khiến cơ sở dữ liệu không được chuẩn hóa ở nơi đầu tiên phức tạp hơn. Dưới đây là top 5 mà tôi đã đi qua:

• Các nhà phát triển đã thiết kế nó không biết hoặc không hiểu cách bình thường hóa. Bằng chứng mạnh mẽ về điều này xuất hiện dưới dạng nhiều lựa chọn thiết kế xấu đi kèm khác, như sử dụng các cột varchar cho mọi thứ hoặc có một mớ hỗn độn spaghetti của các tên bảng và cột vô nghĩa . Và tôi đảm bảo với bạn, tôi đã thấy các cơ sở dữ liệu "thực", mỗi bit đều tệ như các cơ sở dữ liệu trong các bài viết TDWTF.

• Các nhà phát triển đã thiết kế nó không quan tâm hoặc chủ động chống lại bình thường hóa trên nguyên tắc . Lưu ý, ở đây tôi không nói về những trường hợp mà một quyết định có chủ ý được đưa ra không bình thường hóa dựa trên phân tích theo ngữ cảnh, mà là các nhóm hoặc công ty nơi bình thường hóa ít nhiều được hiểu nhưng chỉ đơn giản là bỏ qua hoặc tránh xa thói quen. Một lần nữa, đáng ngạc nhiên phổ biến.

• Phần mềm này được / được thực hiện như một dự án Brownfield . Nhiều người theo chủ nghĩa thuần túy bỏ qua việc kinh doanh hoàn toàn hợp pháp này hơn là lý do kỹ thuật cho việc không bình thường hóa. Đôi khi bạn không thực sự thiết kế một cơ sở dữ liệu mới từ đầu, bạn phải tìm đến một lược đồ kế thừa hiện có và cố gắng bình thường hóa vào thời điểm đó sẽ gây ra quá nhiều đau đớn. 3NF không được phát minh cho đến năm 1971 và một số hệ thống - đặc biệt là hệ thống tài chính / kế toán - có nguồn gốc thậm chí còn xa hơn thế!

• Cơ sở dữ liệu ban đầu được chuẩn hóa , nhưng sự tích lũy của những thay đổi nhỏ trong một thời gian dài và / hoặc một nhóm phân phối rộng rãi đã đưa ra các hình thức sao chép tinh vi và các vi phạm khác của bất kỳ hình thức bình thường nào ban đầu. Nói cách khác, việc mất bình thường hóa là tình cờ và quá ít thời gian dành cho tái cấu trúc.

• Một quyết định kinh doanh có chủ ý đã được đưa ra không dành bất kỳ thời gian nào cho phân tích kinh doanh hoặc thiết kế cơ sở dữ liệu và chỉ "hoàn thành nó". Đây thường là một nền kinh tế sai lầm và cuối cùng trở thành một hình thức nợ kỹ thuật , nhưng đôi khi là một quyết định hợp lý, ít nhất là dựa trên thông tin đã biết vào thời điểm đó - ví dụ, cơ sở dữ liệu có thể được dự định là nguyên mẫu nhưng cuối cùng được thúc đẩy sử dụng sản xuất do hạn chế về thời gian hoặc thay đổi trong môi trường kinh doanh.

2. Tại sao / khi nào một cơ sở dữ liệu chuẩn hóa nên được chuẩn hóa?

Thảo luận này thường xuất hiện khi cơ sở dữ liệu được chuẩn hóa để bắt đầu. Hiệu suất kém hoặc có nhiều sự trùng lặp trong các truy vấn (tham gia) và nhóm cảm thấy, đúng hay sai, rằng họ đã đi xa hết mức có thể với thiết kế hiện tại. Điều quan trọng cần lưu ý là việc bình thường hóa giúp cải thiện hiệu suất trong hầu hết thời gian và có một số tùy chọn để loại bỏ các phép nối dư thừa khi chuẩn hóa dường như đang chống lại bạn, nhiều trong số đó ít xâm lấn và rủi ro hơn là thay đổi thành mô hình không chuẩn hóa:

• Tạo các khung nhìn được lập chỉ mục đóng gói các khu vực vấn đề phổ biến nhất. Các DBMS hiện đại có khả năng làm cho chúng có thể chèn hoặc cập nhật được (ví dụ: INSTEAD OFtrình kích hoạt SQL Server ). Điều này có chi phí thấp cho các báo cáo DML trên các bảng / chỉ mục cơ bản nhưng nói chung là tùy chọn đầu tiên bạn nên thử vì gần như không thể làm hỏng và chi phí gần như không có gì để duy trì. Tất nhiên, không phải mọi truy vấn đều có thể được chuyển thành dạng xem được lập chỉ mục - các truy vấn tổng hợp là rắc rối nhất. Điều này dẫn chúng ta đến mục tiếp theo ...

• Tạo các bảng tổng hợp không chuẩn hóa được tự động cập nhật bởi các kích hoạt. Các bảng này tồn tại cùng với các bảng được chuẩn hóa và tạo thành một loại mô hình CQRS . Một mô hình CQRS khác, phổ biến hơn hiện nay, là sử dụng pub / sub để cập nhật các mô hình truy vấn, điều này mang lại lợi ích của sự không đồng bộ, mặc dù điều đó có thể không phù hợp trong những trường hợp rất hiếm khi dữ liệu không thể cũ.

• Đôi khi, các chế độ xem được lập chỉ mục là không thể, tốc độ giao dịch và khối lượng dữ liệu quá cao để thừa nhận các kích hoạt có hiệu suất chấp nhận được và các truy vấn phải luôn trả về dữ liệu thời gian thực. Những tình huống này rất hiếm khi xảy ra - tôi có thể đoán rằng chúng có thể áp dụng cho những thứ như Giao dịch tần số cao hoặc cơ sở dữ liệu thực thi pháp luật / tình báo - nhưng chúng có thể tồn tại. Trong những trường hợp này, bạn thực sự không có lựa chọn nào khác ngoài việc không chuẩn hóa các bảng gốc.

3. Trong trường hợp đầu tiên có hại hay không cần thiết phải bình thường hóa?

Trên thực tế, có một số ví dụ hay ở đây:

• Nếu cơ sở dữ liệu đang được sử dụng chỉ để báo cáo / phân tích. Thông thường, điều này ngụ ý rằng có một cơ sở dữ liệu chuẩn hóa bổ sung đang được sử dụng cho OLTP, được đồng bộ hóa định kỳ với cơ sở dữ liệu phân tích thông qua ETL hoặc nhắn tin.

• Khi thực thi một mô hình chuẩn hóa sẽ yêu cầu phân tích dữ liệu đến phức tạp không cần thiết. Một ví dụ về điều này có thể là một hệ thống cần lưu trữ các số điện thoại được thu thập từ một số hệ thống hoặc cơ sở dữ liệu bên ngoài. Bạn có thể không chuẩn hóa mã cuộc gọi và mã vùng, nhưng bạn phải tính đến tất cả các định dạng có thể khác nhau, số điện thoại không hợp lệ, số không phù hợp (1-800-GET-STUFF), không đề cập đến các địa phương khác nhau. Nó thường rắc rối hơn giá trị của nó và số điện thoại thường chỉ được đưa vào một lĩnh vực duy nhất trừ khi bạn có nhu cầu kinh doanh cụ thể cho riêng mã vùng.

• Khi cơ sở dữ liệu quan hệ chủ yếu ở đó để cung cấp hỗ trợ giao dịch cho cơ sở dữ liệu bổ sung, không liên quan. Ví dụ: bạn có thể đang sử dụng cơ sở dữ liệu quan hệ dưới dạng hàng đợi tin nhắn hoặc để theo dõi trạng thái của giao dịch hoặc saga, khi dữ liệu chính đang được lưu trữ trong Redis hoặc MongoDB hoặc bất cứ điều gì. Nói cách khác, dữ liệu là "dữ liệu điều khiển". Thường không có điểm nào trong việc bình thường hóa dữ liệu không thực sự là dữ liệu kinh doanh .

• Kiến trúc hướng dịch vụ chia sẻ cơ sở dữ liệu vật lý. Đây là một chút của một số lẻ, nhưng trong một SOA thực sự, đôi khi bạn sẽ cần phải có dữ liệu trùng lặp về mặt vật lý vì các dịch vụ không được phép truy vấn trực tiếp dữ liệu của nhau. Nếu họ xảy ra để được chia sẻ cơ sở dữ liệu vật lý như nhau, dữ liệu sẽ xuất hiện không được bình thường - nhưng nhìn chung, các dữ liệu thuộc sở hữu của mỗi dịch vụ cá nhân được vẫn bình thường trừ khi một trong những tình tiết giảm nhẹ khác được đặt ra. Ví dụ: Dịch vụ thanh toán có thể sở hữu thực thể Hóa đơn, nhưng dịch vụ Kế toán cần nhận và lưu trữ Ngày và Số tiền hóa đơn để đưa nó vào doanh thu cho năm đó.

Tôi chắc chắn có nhiều lý do mà tôi chưa liệt kê; Về bản chất, điều tôi nhận được là chúng khá cụ thể và sẽ khá rõ ràng khi chúng xuất hiện trong thực tế. Cơ sở dữ liệu OLAP được cho là sử dụng các lược đồ sao, các API được cho là có một số trùng lặp, v.v. Nếu bạn đang làm việc với một mô hình kiến ​​trúc nổi tiếng mà đơn giản là không hoạt động với chuẩn hóa, thì bạn không bình thường hóa; nói chung, mô hình kiến ​​trúc được ưu tiên hơn mô hình dữ liệu.

Và để trả lời câu hỏi cuối cùng:

Có đúng là các kiến ​​trúc sư và chuyên gia giỏi chọn một thiết kế không chuẩn hóa trong khi các nhà phát triển không có kinh nghiệm chọn ngược lại? Các đối số chống lại việc bắt đầu thiết kế của bạn với bình thường hóa trong tâm trí là gì?

Không, đó là hoàn chỉnh và hoàn toàn BS Đó cũng là BS mà các chuyên gia luôn chọn một thiết kế chuẩn hóa . Các chuyên gia không chỉ làm theo một câu thần chú. Họ nghiên cứu, phân tích, thảo luận, làm rõ và lặp đi lặp lại, và sau đó họ chọn bất kỳ cách tiếp cận nào có ý nghĩa nhất cho tình huống cụ thể của họ.

Cơ sở dữ liệu 3NF hoặc BCNF thường là điểm khởi đầu tốt để phân tích vì nó đã được thử nghiệm và chứng minh thành công trong hàng chục ngàn dự án trên toàn thế giới, nhưng sau đó, một lần nữa, C. Điều đó không có nghĩa là chúng tôi tự động sử dụng C trong mọi dự án mới. Các tình huống trong thế giới thực có thể yêu cầu một số sửa đổi cho mô hình hoặc sử dụng một mô hình khác hoàn toàn. Bạn không biết cho đến khi bạn ở trong tình huống đó.

Giả định được xây dựng trong câu hỏi và trong một số câu trả lời là chuẩn hóa đồng nghĩa với thiết kế cơ sở dữ liệu tốt. Đây là thực tế thường không phải là trường hợp. Chuẩn hóa là một cách để đạt được một bộ mục tiêu thiết kế cụ thể và một yêu cầu nếu bạn phụ thuộc nhiều vào cơ sở dữ liệu để thực thi "quy tắc kinh doanh" về mối quan hệ giữa các yếu tố dữ liệu.

Bình thường hóa mang lại cho bạn một vài lợi ích chính:

1. Giảm thiểu lượng dữ liệu dư thừa.
2. Tối đa hóa mức độ mà các cơ chế toàn vẹn được xây dựng trong cơ sở dữ liệu (các ràng buộc khóa ngoài, các ràng buộc duy nhất) có thể được tận dụng để đảm bảo tính toàn vẹn của dữ liệu.
3. Giảm số lượng cột trên mỗi hàng làm tăng hiệu quả của IO trong một số trường hợp. Hàng rộng mất nhiều thời gian hơn để lấy.

Điều đó nói rằng, có rất nhiều lý do hợp lệ để không chuẩn hóa:

1. Hiệu suất, đặc biệt đối với phân tích, có thể bị tê liệt do chuẩn hóa. Để phân tích dựa trên cơ sở dữ liệu quan hệ, các mô hình chiều không chuẩn hóa là cách tiếp cận tiêu chuẩn.
2. Lợi ích của việc thực thi tính toàn vẹn dữ liệu bên trong cơ sở dữ liệu đang bắt đầu giảm. Khi ngày càng có nhiều sự phát triển tập trung vào tầng trung lưu hướng đối tượng thường thực thi các quy tắc kinh doanh, việc phụ thuộc vào các ràng buộc quan hệ trong cơ sở dữ liệu là ít quan trọng hơn.
3. Như những người khác đã đề cập, chuẩn hóa sẽ làm phức tạp các truy vấn cần thiết để lấy dữ liệu liên quan.

Không rõ ràng rằng bình thường hóa là một dấu hiệu của thiết kế tốt. Trong một số trường hợp, chuẩn hóa là một yếu tố của thời gian khi không gian lưu trữ ở mức cao và khi phần lớn trách nhiệm mã hóa các quy tắc kinh doanh nằm trong cơ sở dữ liệu (hãy nghĩ về các ứng dụng máy khách-máy chủ 2 tầng với hầu hết không phải là logic kinh doanh thủ tục lưu trữ). Cũng có thể là nhiều dự án xoay quanh việc bình thường hóa dựa trên các quyết định kiến ​​trúc tốt thay vì nắm bắt kém các nguyên tắc thiết kế cơ sở dữ liệu.

Bài viết của Jeff Atwood được tham chiếu trong các ý kiến ​​trên cung cấp một số thảo luận chi tiết tốt - "Có thể bình thường hóa không bình thường" .

1. Rất nhiều nhà phát triển không biết hoặc quan tâm đến việc chuẩn hóa hoặc về mô hình hóa dữ liệu hoặc cơ sở dữ liệu.
2. Đối với một số công việc, nó thực sự không quan trọng.
3. Đôi khi có một lý do thực sự tốt để không bình thường hóa, ví dụ để làm cho một khối lượng công việc khó khăn đặc biệt hoạt động tốt.
4. Các khái niệm cơ sở dữ liệu quan hệ gần đây ít thời trang hơn so với những năm 1990 và 2000. Các nhà phát triển có xu hướng bị ảnh hưởng bởi thời trang, ngay cả khi họ tuyên bố là rất hợp lý. Không có điểm nào để tranh cãi về hương vị.

Bình thường hóa, trong lịch sử, là một lãnh thổ cho tranh luận gần như tôn giáo, vì vậy tôi ngần ngại nói nhiều hơn nữa.

Trong các dự án lớn, và đặc biệt là những dự án trong máy tính lớn, đây không phải là trường hợp. Trong thực tế nếu bạn tìm kiếm các trang web việc làm, bạn sẽ thấy một số vị trí cho người lập mô hình dữ liệu. Ngoài ra, có nhiều cột trên một bảng không đi ngược lại quá trình chuẩn hóa. Tuy nhiên, quan sát của bạn là hợp lệ cho một số dự án.

Thiết kế cơ sở dữ liệu là một trong những kỹ năng cần thiết để xây dựng hệ thống chất lượng. Phải nói rằng, một số nhà phát triển không biết đủ về thiết kế cơ sở dữ liệu và vẫn được giao cho nhiệm vụ mô hình hóa dữ liệu và thiết kế cơ sở dữ liệu. Một số dự án thậm chí bỏ qua mô hình dữ liệu. Việc tập trung vào nhiều dự án chủ yếu là mã hóa và thiết kế mặt trước.

Một yếu tố khác cho thiết kế cơ sở dữ liệu kém là thực tế rằng Chuẩn hóa không phải là một chủ đề tầm thường đặc biệt khi nói đến NF thứ 4, NF thứ 5, v.v. Hầu hết các cuốn sách tôi đã xem không thể giải thích rõ ràng về các hình thức đó. Thường có những ví dụ tồi tệ và quá nhiều lý thuyết. Điều này làm cho chủ đề ít phổ biến hơn nó nên.

Lỗi trong thiết kế cơ sở dữ liệu rất khó xảy ra trừ khi bạn tìm kiếm chúng hoặc bạn gặp phải chúng trong quá trình thử nghiệm. Không có tiêu chuẩn cho chất lượng thiết kế cơ sở dữ liệu cho phép lỗi xảy ra nhiều hơn.

Thêm vào đó, thực tế là một số dự án không tuân theo một phương pháp phát triển nghiêm ngặt (một dự án thúc đẩy thiết kế cơ sở dữ liệu), do đó, các trách nhiệm bị lẫn lộn và các nhiệm vụ bị mất giữa nhà phân tích kinh doanh, nhà phát triển và DBA. Các nhà phát triển nói chuyện trong OO và UML trong đó các DBA nói chuyện với DD và một số trong ERD và có lẽ nhiều người không nhận được UML hoặc OO. Nói tóm lại, thiếu kiến ​​thức, thiếu tài nguyên rõ ràng tốt, thiếu ngôn ngữ thống nhất để mô tả dữ liệu và thiếu phương pháp là tất cả để đổ lỗi.