Có bao giờ có ý nghĩa KHÔNG ngưng tụ một mối quan hệ?

Nếu chúng ta có Bảng A có mối quan hệ 1-1 với Bảng B, liệu có bao giờ có ý nghĩa để tách chúng ra không? Hoặc nó không bao giờ bị tổn thương khi kết hợp chúng vào một bảng duy nhất? Do một trong hai kịch bản này (hai bảng so với một bảng kết hợp) có ảnh hưởng gì đến hình thức thông thường của nó (1NF, 2NF, 3NF, v.v.) không?

Vâng, có rất nhiều lý do tại sao điều này có thể là thiết kế tốt hơn.

Bạn có thể có mối quan hệ kế thừa / mở rộng, ví dụ: bạn có thể có một Userbảng và sau đó một Administratorbảng có nhiều trường hơn. Cả hai bảng có thể có khóa chính là ID người dùng (và do đó có mối quan hệ 1: 1) nhưng không phải tất cả người dùng sẽ có bản ghi trong Administratorbảng. Bạn sẽ cần một cái gì đó tương tự nếu bạn đang hỗ trợ một quy trình công việc, ví dụ như một ScheduledTaskbảng và CompletedTaskbảng.

Bạn có thể muốn có một bảng nhẹ cho dữ liệu thường được sử dụng Uservà sau đó là một bảng lớn hơn để biết chi tiết bạn không cần thường xuyên UserDetails. Điều này có thể cải thiện hiệu suất vì bạn sẽ có thể điều chỉnh nhiều bản ghi hơn vào một trang dữ liệu.

Bạn có thể muốn các quyền khác nhau cho các bảng, ví dụ UservàUserCredentials

Bạn có thể muốn các chiến lược sao lưu khác nhau và do đó đặt hai bảng trên các phân vùng khác nhau, ví dụ TransactionvàTransactionArchive

Bạn có thể cần nhiều cột hơn mức có thể được hỗ trợ trong một bảng, ví dụ: nếu có nhiều cột văn bản lớn mà bạn cần để có thể lập chỉ mục và nền tảng DB của bạn bị giới hạn ở các trang dữ liệu 4K hoặc whathaveyou.

Thêm vào câu trả lời xuất sắc của @ john-wu khác, một lý do khác là khi bạn có loại cột BLOB như hình ảnh.

Bạn muốn có cột BLOB đó trong một bảng riêng biệt, không chỉ cho các truy vấn trên bảng người dùng nhanh hơn mà còn vì bạn có thể di chuyển bảng chứa blob sang một vùng bảng khác trên bộ lưu trữ chậm hơn, rẻ hơn, giữ dữ liệu được truy vấn nhiều nhất trong không gian bảng chính trên bộ lưu trữ nhanh hơn.

Các mối quan hệ 1-1 chỉ thực sự có ý nghĩa khi bạn muốn bản ghi liên quan trong Bảng B là tùy chọn.

Đôi khi những gì bạn muốn là một bản ghi biến thể hoặc Liên minh được gắn thẻ . Điều đó có nghĩa là bạn có nhiều bảng chứa thông tin khác nhau, nhưng tất cả đều liên quan đến Bảng A trong các mối quan hệ một-một. Sau đó, bạn chọn bảng nào để liên kết dựa trên một trường trong Bảng A

Ví dụ:

type Transaction(The_Type: PaymentType := Cash) is record

    Amount: Integer;

    case The_Type is
        when Cash =>
            Discount: boolean;
        when Check =>
            CheckNumber: Positive;
        when Credit =>
            CardNumber: String(1..5);
            Expiration: String(1..5);
    end case;
end record;

Trong mô hình hóa kinh doanh, hai thực thể A và B tách biệt khỏi quan điểm kinh doanh thường ánh xạ tới các bảng khác nhau.

Ví dụ, khi thực hiện mô hình hóa kinh doanh với các phương tiện hướng đối tượng, bạn thường có một số loại ánh xạ quan hệ đối tượng tại chỗ. Bạn có thể bắt đầu với một mô hình đối tượng và rút ra mô hình quan hệ của bạn từ đó. Vì vậy, hãy tưởng tượng trong mô hình đối tượng của bạn, bạn đã tạo các lớp A và B, mặc dù các đối tượng có sự tương ứng 1: 1, nên được tách ra vì nguyên tắc trách nhiệm duy nhất . Lưu ý trong mô hình đối tượng của bạn, các lớp này không chỉ là các bảng có thuộc tính, chúng có thể đại diện cho các đối tượng kinh doanh, với một số hành vi được thực hiện trong các phương thức. Và khi bạn ánh xạ các lớp đó ngay bây giờ theo mô hình quan hệ, bạn sẽ nhận được các bảng A và B riêng biệt với mối quan hệ 1: 1.

Theo kinh nghiệm của tôi, khi tạo mô hình dữ liệu kinh doanh hoặc OO, sự phân tách logic này điển hình hơn nhiều cho các mối quan hệ 1: 1 so với các lý do "vật lý" như hiệu suất, bảo mật cá nhân hoặc phân vùng.