Có phải là một thực tế xấu khi có một vài mối quan hệ độc quyền lẫn nhau?

Say, một bảng carcó one-to-one mối quan hệ cho các bảng electric_car, gas_carvà hybrid_car. Nếu một carlà electric_car, nó không còn có thể xuất hiện trong gas_carhoặc hybrid_carvv

Có điều gì sai với thiết kế như vậy? Một số vấn đề có thể xảy ra xuống đường?

Các loại ô tô khác nhau là một ví dụ của một vấn đề chung xuất hiện nhiều lần trong mô hình dữ liệu. Nó được gọi là "khái quát hóa / chuyên môn hóa" trong mô hình ER và "siêu lớp / lớp con" trong mô hình đối tượng.

Một người lập mô hình đối tượng sử dụng các tính năng kế thừa được tích hợp trong mô hình đối tượng để giải quyết vấn đề khá dễ dàng. Các lớp con chỉ đơn giản là mở rộng siêu lớp.

Người lập mô hình quan hệ phải đối mặt với một vấn đề. Làm thế nào để thiết kế các bảng sao cho mô phỏng những lợi ích mà người ta sẽ nhận được từ thừa kế?

Kỹ thuật đơn giản nhất được gọi là kế thừa bảng đơn . Dữ liệu về tất cả các loại ô tô được nhóm thành một bảng duy nhất cho ô tô. Có một cột, car_type, nhóm tất cả các xe cùng một loại. Không có chiếc xe có thể thuộc nhiều hơn một loại. Nếu một cột không liên quan đến ô tô điện, nó sẽ bị bỏ lại NULL trong các hàng liên quan đến ô tô điện.

Giải pháp đơn giản này hoạt động tốt cho các trường hợp nhỏ hơn và đơn giản hơn. Sự hiện diện của rất nhiều NULL thêm một chút nhỏ vào chi phí lưu trữ và một chút cho chi phí truy xuất. Nhà phát triển có thể phải học logic ba giá trị SQL nếu các bài kiểm tra boolean được thực hiện trên các cột không thể. Điều này có thể gây trở ngại lúc đầu, nhưng người ta đã quen với nó.

Có một kỹ thuật khác, được gọi là kế thừa bảng lớp . Trong thiết kế này, có các bảng riêng biệt cho gas_car, Electric_car và hybrid_car, ngoài ra còn có một bảng kết hợp, xe hơi, cho tất cả chúng. Khi bạn muốn tất cả các dữ liệu về một loại xe cụ thể, bạn tham gia bảng xe với bảng chuyên dụng phù hợp. Có ít NULL hơn trong thiết kế này, nhưng bạn tham gia nhiều hơn. Kỹ thuật này hoạt động tốt hơn trong các trường hợp lớn hơn và phức tạp hơn.

Có một kỹ thuật thứ ba được gọi là khóa chính được chia sẻ. Kỹ thuật này thường được sử dụng kết hợp với kế thừa bảng lớp. Các bảng chuyên biệt cho các lớp con có, như là khóa chính của chúng, một bản sao của khóa chính của mục tương ứng trong bảng ô tô. Cột id này có thể được khai báo là cả khóa chính và khóa ngoại.

Điều này liên quan đến việc lập trình thêm một chút khi những chiếc xe mới được thêm vào, nhưng nó làm cho việc tham gia trở nên đơn giản, dễ dàng và nhanh chóng.

Các siêu lớp và các lớp con xảy ra mọi lúc trong thế giới thực. Đừng sợ. Nhưng hãy kiểm tra thiết kế ban đầu của bạn để thực hiện. Nếu lần thử đầu tiên của bạn đơn giản và âm thanh, bạn sẽ có thể điều chỉnh nó để tăng tốc nó.

Không có gì sai khi có càng nhiều loại phụ thực thể trong mô hình của bạn là cần thiết để phản ánh thực tế của dữ liệu mà bạn đang cố gắng mô hình hóa. Câu hỏi không phải là liệu các loại phụ có phải là một thực tiễn xấu hay không. Vấn đề có thể là một mô hình tốt ?

Ví dụ, dưới ví dụ của bạn, bạn sẽ làm gì với một cái gì đó giống như một chiếc Audi A4 eTron - vốn là một chiếc hybrid cắm điện? Đó có phải là "xe điện" hay là "xe hybrid"?

Một câu hỏi khác bạn phải tự hỏi mình là tại sao bạn lại gõ phụ? Bạn có bao nhiêu vị từ riêng biệt trong các loại phụ của bạn? Có bất kỳ vị từ nào được chia sẻ giữa các loại phụ không? Tình hình có thể trở nên phức tạp.

Gõ phụ không được sử dụng trong thiết kế cơ sở dữ liệu để phân loại. Bạn có thể thực hiện phân loại với mã, khóa ngoại cho bảng mã hoặc bằng cờ. Gõ phụ được sử dụng để mô hình các bộ vị ngữ riêng biệt cho các loại khác nhau của một điều quan tâm. Nếu bạn đang sử dụng các loại phụ chỉ để phân loại thì đó là một thực tế tồi.

Nếu các kiểu con của bạn mô hình rõ ràng và rõ ràng các bộ vị ngữ khác nhau cho những thứ mà cơ sở dữ liệu của bạn quan tâm, thì đó là một cách thực hành hoàn toàn tốt, bất kể bạn cần bao nhiêu loại phụ.