Có khi nào sử dụng cơ sở dữ liệu mối quan hệ 1: 1 có ý nghĩa không?

Tôi đã suy nghĩ vào một ngày khác về việc bình thường hóa và điều đó xảy ra với tôi, tôi không thể nghĩ đến thời điểm cần có mối quan hệ 1: 1 trong cơ sở dữ liệu.

• Name:SSN? Tôi sẽ có chúng trong cùng một bảng.
• PersonID:AddressID? Một lần nữa, cùng một bảng.

Tôi có thể đưa ra hàng trăm ví dụ về 1: nhiều hoặc nhiều: nhiều (với các bảng trung gian phù hợp), nhưng không bao giờ là 1: 1.

Tôi có thiếu một cái gì đó rõ ràng?

Mối quan hệ 1: 1 thường chỉ ra rằng bạn đã phân vùng một thực thể lớn hơn vì một số lý do. Thông thường đó là vì lý do hiệu suất trong lược đồ vật lý, nhưng nó cũng có thể xảy ra ở khía cạnh logic nếu một khối lớn dữ liệu được dự kiến ​​là "không xác định" cùng một lúc (trong trường hợp đó bạn có tỷ lệ 1: 0 hoặc 1: 1, nhưng không còn nữa).

Ví dụ về phân vùng logic: bạn có dữ liệu về một nhân viên, nhưng có một bộ dữ liệu lớn hơn cần được thu thập, nếu và chỉ khi họ chọn có bảo hiểm y tế. Tôi sẽ giữ dữ liệu nhân khẩu học về bảo hiểm y tế trong một bảng khác để vừa phân vùng bảo mật dễ dàng hơn vừa tránh việc thu thập dữ liệu xung quanh trong các truy vấn không liên quan đến bảo hiểm.

Một ví dụ về phân vùng vật lý sẽ là cùng một dữ liệu được lưu trữ trên nhiều máy chủ. Tôi có thể giữ dữ liệu nhân khẩu học bảo hiểm y tế ở một trạng thái khác (ví dụ như văn phòng nhân sự) và cơ sở dữ liệu chính chỉ có thể liên kết với nó thông qua một máy chủ được liên kết ... tránh sao chép dữ liệu nhạy cảm sang các vị trí khác, nhưng vẫn có sẵn cho (giả sử ở đây hiếm) các truy vấn cần nó.

Phân vùng vật lý có thể hữu ích bất cứ khi nào bạn có các truy vấn cần tập hợp con nhất quán của một thực thể lớn hơn.

Một lý do là hiệu quả cơ sở dữ liệu. Có mối quan hệ 1: 1 cho phép bạn tách ra các trường sẽ bị ảnh hưởng trong quá trình khóa hàng / bảng. Nếu bảng A có hàng tấn cập nhật và bảng b có hàng tấn đọc (hoặc có rất nhiều cập nhật từ ứng dụng khác), thì bảng A khóa sẽ không ảnh hưởng đến những gì đang diễn ra trong bảng B.

Những người khác đưa ra một điểm tốt. Bảo mật cũng có thể là một lý do tốt tùy thuộc vào cách các ứng dụng, vv đang tấn công hệ thống. Tôi có xu hướng thực hiện một cách tiếp cận khác, nhưng nó có thể là một cách dễ dàng để hạn chế quyền truy cập vào dữ liệu nhất định. Thật dễ dàng để từ chối truy cập vào một bảng nhất định trong một nhúm.

Mục blog của tôi về nó.

Độ thưa thớt. Mối quan hệ dữ liệu có thể là về mặt kỹ thuật 1: 1, nhưng các hàng tương ứng không phải tồn tại cho mỗi hàng. Vì vậy, nếu bạn có hai mươi triệu hàng và có một số giá trị chỉ tồn tại 0,5% trong số chúng, thì tiết kiệm không gian là rất lớn nếu bạn đẩy các cột đó ra một bảng có thể được đặt rải rác.

Hầu hết các câu trả lời được xếp hạng cao đều đưa ra lý do điều chỉnh và tối ưu hóa cơ sở dữ liệu rất hữu ích cho các mối quan hệ 1: 1, nhưng tôi muốn tập trung vào không có gì ngoài các ví dụ "trong tự nhiên" trong đó các mối quan hệ 1: 1 xảy ra một cách tự nhiên.

Xin lưu ý một đặc điểm quan trọng của việc triển khai cơ sở dữ liệu của hầu hết các ví dụ này: không có thông tin lịch sử nào được giữ lại về mối quan hệ 1: 1. Đó là, các mối quan hệ này là 1: 1 tại bất kỳ thời điểm nào. Nếu người thiết kế cơ sở dữ liệu muốn ghi lại các thay đổi trong những người tham gia mối quan hệ theo thời gian, thì các mối quan hệ trở thành 1: M hoặc M: M; họ mất bản chất 1: 1 của họ. Với sự hiểu biết đó, ở đây đi:

• Mối quan hệ "Is-A" hoặc supertype / subtype hoặc thừa kế / phân loại: Thể loại này là khi một thực thể là một loại cụ thể của thực thể khác. Ví dụ: có thể có một thực thể Nhân viên với các thuộc tính áp dụng cho tất cả nhân viên và sau đó các thực thể khác nhau để chỉ ra các loại nhân viên cụ thể có thuộc tính duy nhất cho loại nhân viên đó, ví dụ: Bác sĩ, Kế toán, Phi công, v.v. Thiết kế này tránh được nhiều null nhiều nhân viên sẽ không có các thuộc tính chuyên biệt của một kiểu con cụ thể. Các ví dụ khác trong danh mục này có thể là Sản phẩm dưới dạng siêu kiểu, và Sản phẩm và Bảo trìSupply dưới dạng các kiểu con; Động vật như siêu nhân và Chó và Mèo là tiểu loại; v.v ... Lưu ý rằng bất cứ khi nào bạn cố gắng ánh xạ phân cấp thừa kế hướng đối tượng vào cơ sở dữ liệu quan hệ (chẳng hạn như trong mô hình quan hệ đối tượng), đây là loại mối quan hệ đại diện cho các tình huống như vậy.

• Các mối quan hệ "ông chủ" , chẳng hạn như người quản lý, chủ tịch, chủ tịch, v.v., trong đó một đơn vị tổ chức chỉ có thể có một ông chủ và một người chỉ có thể là ông chủ của một đơn vị tổ chức. Nếu những quy tắc đó được áp dụng, thì bạn có mối quan hệ 1: 1, chẳng hạn như một người quản lý của một bộ phận, một giám đốc điều hành của một công ty, v.v. Mối quan hệ "ông chủ" không chỉ áp dụng cho mọi người. Loại mối quan hệ tương tự xảy ra nếu chỉ có một cửa hàng là trụ sở của một công ty, hoặc nếu chỉ có một thành phố là thủ đô của một quốc gia, ví dụ.

• Một số loại phân bổ nguồn lực khan hiếm , ví dụ một nhân viên chỉ có thể được chỉ định một xe công ty tại một thời điểm (ví dụ: một xe tải cho mỗi người lái xe tải, một xe taxi cho mỗi tài xế taxi, v.v.). Một đồng nghiệp đã cho tôi ví dụ này gần đây.

• Hôn nhân (ít nhất là trong các khu vực pháp lý nơi chế độ đa thê là bất hợp pháp): một người chỉ có thể kết hôn với một người khác tại một thời điểm. Tôi lấy ví dụ này từ một cuốn sách giáo khoa đã sử dụng nó như một ví dụ về mối quan hệ đơn phương 1: 1 khi một công ty ghi lại các cuộc hôn nhân giữa các nhân viên của mình.

• Đặt chỗ phù hợp : khi đặt chỗ duy nhất được thực hiện và sau đó được thực hiện dưới dạng hai thực thể riêng biệt. Ví dụ: hệ thống cho thuê xe hơi có thể ghi lại một đặt chỗ trong một thực thể và sau đó là cho thuê thực tế trong một thực thể riêng biệt. Mặc dù một tình huống như vậy có thể được thiết kế thay thế thành một thực thể, nhưng có thể có ý nghĩa để tách các thực thể vì không phải tất cả các đặt phòng đều được thực hiện và không phải tất cả các dịch vụ cho thuê đều yêu cầu đặt trước và cả hai tình huống đều rất phổ biến.

Tôi nhắc lại lời cảnh báo mà tôi đã thực hiện trước đó rằng hầu hết đây chỉ là mối quan hệ 1: 1 nếu không có thông tin lịch sử nào được ghi lại. Vì vậy, nếu một nhân viên thay đổi vai trò của họ trong một tổ chức, hoặc người quản lý chịu trách nhiệm của một bộ phận khác, hoặc một nhân viên được chỉ định lại một chiếc xe, hoặc ai đó bị góa và tái hôn, thì những người tham gia mối quan hệ có thể thay đổi. Nếu cơ sở dữ liệu không lưu trữ bất kỳ lịch sử nào trước đây về các mối quan hệ 1: 1 này, thì chúng vẫn là các mối quan hệ 1: 1 hợp pháp. Nhưng nếu cơ sở dữ liệu ghi lại thông tin lịch sử (chẳng hạn như thêm ngày bắt đầu và ngày kết thúc cho mỗi mối quan hệ), thì tất cả chúng đều biến thành mối quan hệ M: M.

Có hai trường hợp ngoại lệ đáng chú ý đối với ghi chú lịch sử: Thứ nhất, một số mối quan hệ thay đổi rất hiếm khi thông tin lịch sử thường không được lưu trữ. Ví dụ: hầu hết các mối quan hệ IS-A (ví dụ: loại sản phẩm) là bất biến; đó là họ không bao giờ có thể thay đổi Vì vậy, điểm ghi chép lịch sử là moot; những điều này sẽ luôn được thực hiện như các mối quan hệ 1: 1 tự nhiên. Thứ hai, các cửa hàng quan hệ đặt phòng-cho thuê ngày riêng biệt, vì đặt phòng và cho thuê là các sự kiện độc lập, mỗi sự kiện có ngày riêng của họ. Vì các thực thể có ngày riêng của chúng, thay vì chính mối quan hệ 1: 1 có ngày bắt đầu, các mối quan hệ này sẽ vẫn là mối quan hệ 1: 1 mặc dù thông tin lịch sử được lưu trữ.

Câu hỏi của bạn có thể được diễn giải theo nhiều cách, vì cách bạn diễn đạt nó. Các câu trả lời cho thấy điều này.

Chắc chắn có thể có mối quan hệ 1: 1 giữa các mục dữ liệu trong thế giới thực. Không có câu hỏi về nó. Mối quan hệ "là một" nói chung là một đối một. Một chiếc xe là một phương tiện. Một chiếc xe là một chiếc xe. Một chiếc xe có thể là một chiếc xe. Một số phương tiện là xe tải, trong trường hợp một phương tiện không phải là ô tô. Một số câu trả lời giải thích điều này.

Nhưng tôi nghĩ những gì bạn thực sự đang hỏi là ... khi các mối quan hệ 1: 1 tồn tại, các bảng có bao giờ bị chia tách không? Nói cách khác, bạn có bao giờ nên có hai bảng chứa chính xác các khóa không? Trong thực tế, hầu hết chúng ta chỉ phân tích các khóa chính chứ không phải các khóa ứng viên khác, nhưng câu hỏi đó hơi khác.

Quy tắc chuẩn hóa cho 1NF, 2NF và 3NF không bao giờ yêu cầu phân tách (tách) một bảng thành hai bảng có cùng khóa chính. Tôi đã không biết liệu việc đặt một lược đồ trong BCNF, 4NF hay 5NF có thể dẫn đến hai bảng có cùng khóa hay không. Ngoài đỉnh đầu, tôi sẽ đoán rằng câu trả lời là không.

Có một mức độ chuẩn hóa được gọi là 6NF. Quy tắc chuẩn hóa cho 6NF chắc chắn có thể dẫn đến hai bảng có cùng khóa chính. 6NF có lợi thế hơn 5NF mà NULLS hoàn toàn có thể tránh được. Điều này rất quan trọng đối với một số, nhưng không phải tất cả, các nhà thiết kế cơ sở dữ liệu. Tôi chưa bao giờ bận tâm để đưa một lược đồ vào 6NF.

Trong 6NF, dữ liệu bị thiếu có thể được biểu thị bằng một hàng bị bỏ qua, thay vì một hàng có NULL trong một số cột.

Có nhiều lý do khác ngoài việc chuẩn hóa để tách bảng. Đôi khi các bảng phân chia dẫn đến hiệu suất tốt hơn. Với một số công cụ cơ sở dữ liệu, bạn có thể nhận được các lợi ích hiệu suất tương tự bằng cách phân vùng bảng thay vì thực sự chia tách nó. Điều này có thể có lợi thế là giữ cho thiết kế logic dễ hiểu, đồng thời cung cấp cho công cụ cơ sở dữ liệu các công cụ cần thiết để tăng tốc mọi thứ.

Tôi sử dụng chúng chủ yếu vì một vài lý do. Một là sự khác biệt đáng kể về tốc độ thay đổi dữ liệu. Một số bảng của tôi có thể có các đường kiểm toán nơi tôi theo dõi các phiên bản hồ sơ trước đó, nếu tôi chỉ quan tâm theo dõi các phiên bản trước đó của 5 trên 10 cột chia 5 cột đó thành một bảng riêng biệt với cơ chế theo dõi kiểm toán trên đó sẽ hiệu quả hơn. Ngoài ra, tôi có thể có hồ sơ (nói cho một ứng dụng kế toán) chỉ được viết. Bạn không thể thay đổi số tiền đô la hoặc tài khoản mà họ đã sử dụng, nếu bạn mắc lỗi thì bạn cần tạo một bản ghi tương ứng để viết điều chỉnh khỏi bản ghi không chính xác, sau đó tạo một mục sửa lỗi. Tôi có các ràng buộc trên bảng thực thi thực tế là chúng không thể được cập nhật hoặc xóa, nhưng tôi có thể có một vài thuộc tính cho đối tượng đó có thể uốn được, những cái đó được giữ trong một bảng riêng biệt mà không bị hạn chế sửa đổi. Một lần khác tôi làm điều này là trong các ứng dụng hồ sơ y tế. Có dữ liệu liên quan đến lượt truy cập không thể thay đổi sau khi đăng nhập và dữ liệu khác liên quan đến lượt truy cập có thể được thay đổi sau khi đăng xuất. Trong trường hợp đó, tôi sẽ phân tách dữ liệu và đặt một kích hoạt trên bảng bị khóa từ chối cập nhật vào bảng bị khóa khi đăng xuất, nhưng cho phép cập nhật dữ liệu mà bác sĩ không đăng xuất.

Một poster khác nhận xét 1: 1 không được chuẩn hóa, tôi sẽ không đồng ý với điều đó trong một số tình huống, đặc biệt là phân nhóm. Giả sử tôi có một bảng nhân viên và khóa chính là SSN của họ (đó là một ví dụ, hãy lưu lại cuộc tranh luận về việc liệu đây có phải là khóa tốt hay không cho một luồng khác). Các nhân viên có thể thuộc nhiều loại khác nhau, nói tạm thời hoặc vĩnh viễn và nếu họ là vĩnh viễn, họ có nhiều trường hơn để điền vào, như số điện thoại văn phòng, chỉ nên không có giá trị nếu loại = 'Vĩnh viễn'. Trong cơ sở dữ liệu biểu mẫu bình thường thứ 3, cột chỉ nên phụ thuộc vào khóa, nghĩa là nhân viên, nhưng nó thực sự phụ thuộc vào nhân viên và loại, do đó, mối quan hệ 1: 1 là hoàn toàn bình thường và mong muốn trong trường hợp này. Nó cũng ngăn các bảng quá thưa thớt, nếu tôi có 10 cột thường được lấp đầy,

Kịch bản phổ biến nhất tôi có thể nghĩ đến là khi bạn có BLOB. Giả sử bạn muốn lưu trữ hình ảnh lớn trong cơ sở dữ liệu (thông thường, không phải là cách tốt nhất để lưu trữ chúng, nhưng đôi khi các ràng buộc giúp thuận tiện hơn). Bạn thường muốn blob ở trong một bảng riêng biệt để cải thiện việc tra cứu dữ liệu không phải là blob.

Về mặt khoa học thuần túy, vâng, chúng là vô dụng.

Trong cơ sở dữ liệu thực tế đôi khi rất hữu ích khi giữ một trường hiếm khi được sử dụng trong một bảng riêng biệt: để tăng tốc truy vấn bằng cách sử dụng trường này và chỉ trường này; để tránh ổ khóa, vv

Thay vì sử dụng các khung nhìn để hạn chế quyền truy cập vào các trường, đôi khi có ý nghĩa giữ các trường bị hạn chế trong một bảng riêng biệt mà chỉ một số người dùng nhất định có quyền truy cập.

Tôi cũng có thể nghĩ về các tình huống trong đó bạn có một mô hình OO trong đó bạn sử dụng tính kế thừa và cây thừa kế phải được duy trì cho DB.

Chẳng hạn, bạn có một lớp Chim và Cá mà cả hai đều thừa hưởng từ Động vật. Trong DB của bạn, bạn có thể có bảng 'Động vật' chứa các trường chung của lớp Thú và bảng Thú có mối quan hệ một đối một với bảng Chim và mối quan hệ một đối một với Cá bàn.

Trong trường hợp này, bạn không cần phải có một bảng Động vật chứa nhiều cột không thể chứa các thuộc tính Bird và Fish, trong đó tất cả các cột chứa dữ liệu Cá được đặt thành NULL khi bản ghi đại diện cho một con chim.

Thay vào đó, bạn có một bản ghi trong bảng Chim có mối quan hệ một đối một với bản ghi trong bảng Động vật.

Mối quan hệ 1-1 cũng là cần thiết nếu bạn có quá nhiều thông tin. Có giới hạn kích thước bản ghi trên mỗi bản ghi trong bảng. Đôi khi các bảng được chia thành hai (với thông tin được truy vấn phổ biến nhất trong bảng chính) chỉ để kích thước bản ghi sẽ không quá lớn. Cơ sở dữ liệu cũng hiệu quả hơn trong việc truy vấn nếu các bảng hẹp.

Đó cũng là một cách để mở rộng một bảng đã được sản xuất với ít rủi ro (nhận thức) hơn là thay đổi cơ sở dữ liệu "thực". Nhìn thấy mối quan hệ 1: 1 trong một hệ thống cũ thường là một chỉ báo tốt cho thấy các trường được thêm vào sau thiết kế ban đầu.

Trong SQL, không thể thực thi mối quan hệ 1: 1 giữa hai bảng bắt buộc ở cả hai bên (trừ khi các bảng chỉ đọc). Đối với hầu hết các mục đích thực tế, mối quan hệ "1: 1" trong SQL thực sự có nghĩa là 1: 0 | 1.

Không có khả năng hỗ trợ cardinality bắt buộc trong các ràng buộc tham chiếu là một trong những hạn chế nghiêm trọng của SQL. Các ràng buộc "có thể bảo vệ" không thực sự được tính bởi vì chúng chỉ là một cách để nói rằng các ràng buộc không được thi hành trong một số thời gian.

Nếu bạn đang sử dụng dữ liệu với một trong các ORM phổ biến, bạn có thể muốn chia một bảng thành nhiều bảng để khớp với Phân cấp đối tượng của bạn.

Tôi đã thấy rằng khi tôi thực hiện mối quan hệ 1: 1 thì hoàn toàn vì lý do hệ thống chứ không phải lý do quan hệ.

Chẳng hạn, tôi đã thấy rằng việc đặt các khía cạnh dành riêng của người dùng vào 1 bảng và đặt các trường người dùng có thể chỉnh sửa của người dùng vào một bảng khác cho phép viết một cách hợp lý các quy tắc đó về quyền trên các trường đó dễ dàng hơn nhiều.

Nhưng bạn đã đúng, theo lý thuyết, các mối quan hệ 1: 1 hoàn toàn bị chiếm đoạt và gần như là một hiện tượng. Tuy nhiên về mặt logic, nó cho phép các chương trình và tối ưu hóa trừu tượng hóa cơ sở dữ liệu dễ dàng hơn.

Hầu hết thời gian, các thiết kế được cho là 1: 1 cho đến khi ai đó hỏi "tốt, tại sao nó không thể là 1: nhiều"? Việc phân chia các khái niệm từ nhau sớm được thực hiện trong dự đoán của kịch bản phổ biến này. Người và Địa chỉ không ràng buộc quá chặt chẽ. Rất nhiều người có nhiều địa chỉ. Và như thế...

Thông thường hai không gian đối tượng riêng biệt ngụ ý rằng một hoặc cả hai có thể được nhân (x: many). Nếu hai đối tượng thực sự, thực sự là 1: 1, thậm chí về mặt triết học, thì đó là mối quan hệ nhiều hơn. Hai "đối tượng" này thực sự là một phần của toàn bộ một đối tượng.

thông tin mở rộng chỉ cần thiết trong các kịch bản nhất định. trong các ứng dụng kế thừa và ngôn ngữ lập trình (như RPG) trong đó các chương trình được biên dịch qua các bảng (vì vậy nếu bảng thay đổi, bạn phải biên dịch lại (các) chương trình). Thẻ dọc theo các tệp cũng có thể hữu ích trong trường hợp bạn phải lo lắng về kích thước bảng.

Thường xuyên nhất nó là một vật lý hơn là xây dựng hợp lý. Nó thường được sử dụng để phân vùng theo chiều dọc một bảng để tận dụng việc phân chia I / O trên các thiết bị vật lý hoặc tối ưu hóa truy vấn khác liên quan đến cách ly dữ liệu hoặc dữ liệu ít được truy cập thường xuyên hơn để giữ an toàn hơn các thuộc tính còn lại trên cùng một đối tượng (SSN, Mức lương, v.v.).

Việc xem xét logic duy nhất quy định mối quan hệ 1-1 là khi các thuộc tính nhất định chỉ áp dụng cho một số thực thể. Tuy nhiên, trong hầu hết các trường hợp, có một cách tốt hơn / bình thường hóa hơn để mô hình hóa dữ liệu thông qua trích xuất thực thể.

Lý do tốt nhất tôi có thể thấy cho mối quan hệ 1: 1 là SubType SuperType của thiết kế cơ sở dữ liệu. Tôi đã tạo cấu trúc dữ liệu MLS Bất động sản dựa trên mô hình này. Có năm nguồn cấp dữ liệu khác nhau; Khu dân cư, thương mại, đa gia đình, khách sạn và đất đai.

Tôi đã tạo một SuperType được gọi là thuộc tính chứa dữ liệu chung cho mỗi năm nguồn cấp dữ liệu riêng biệt. Điều này cho phép tìm kiếm "đơn giản" rất nhanh trên tất cả các kiểu dữ liệu.

Tôi tạo năm SubTypes riêng biệt lưu trữ các thành phần dữ liệu duy nhất cho mỗi năm nguồn cấp dữ liệu. Mỗi bản ghi SuperType có mối quan hệ 1: 1 với bản ghi SubType thích hợp.

Nếu một khách hàng muốn tìm kiếm chi tiết, họ phải chọn loại Super-Sub, ví dụ như PropertyResquil.

Theo tôi, mối quan hệ 1: 1 ánh xạ Kế thừa lớp trên RDBMS. Có một bảng A chứa các thuộc tính chung, tức là trạng thái lớp một phần Mỗi trạng thái lớp được kế thừa được ánh xạ trên RDBMS với bảng B có mối quan hệ 1: 1 với bảng A, chứa các thuộc tính chuyên biệt. Tên bảng A cũng chứa trường "loại" đại diện cho chức năng "truyền"

Tạm biệt Mario

Bạn có thể tạo một bảng mối quan hệ 1-1 nếu có bất kỳ lợi ích hiệu suất đáng kể nào. Bạn có thể đặt các trường hiếm khi được sử dụng vào bảng riêng biệt.

Các mối quan hệ 1: 1 không thực sự có ý nghĩa nếu bạn bình thường hóa vì mọi thứ sẽ là 1: 1 sẽ được giữ trong cùng một bảng.

Trong thế giới thực, nó thường khác nhau. Bạn có thể muốn phá vỡ dữ liệu của mình để phù hợp với giao diện ứng dụng của bạn.

Có thể nếu bạn có một số loại đối tượng gõ trong cơ sở dữ liệu của bạn.

Nói trong một bảng, T1, bạn có các cột C1, C2, C3 có mối quan hệ 1-1. Không sao, nó ở dạng bình thường. Bây giờ hãy nói trong một bảng T2, bạn có các cột C1, C2, C3, Tầm (tên có thể khác nhau, nhưng nói các loại và vai trò là như nhau) với mối quan hệ một đối một. Nó ổn đối với T2 vì những lý do tương tự như với T1.

Tuy nhiên, trong trường hợp này, tôi thấy một sự phù hợp cho một bảng T3 riêng biệt, giữ C1, C2, C3 và một mối quan hệ 1-1 với T3 và từ T2 đến T3. Tôi thậm chí còn thấy phù hợp hơn nếu tồn tại một bảng khác, trong đó đã tồn tại một từ nhiều đến nhiều C1, C2, C3, nói từ bảng A đến nhiều hàng trong bảng B. Sau đó, thay vì T3, bạn sử dụng B và có mối quan hệ một đối một từ T1 đến B, giống nhau từ T2 đến B, và vẫn là mối quan hệ tương tự với nhiều mối quan hệ từ A đến B.

Tôi tin rằng bình thường hóa không đồng ý với điều này và đó có thể là một ý tưởng bên ngoài nó: xác định các loại đối tượng và di chuyển các đối tượng cùng loại vào nhóm lưu trữ của riêng chúng, sử dụng một mối quan hệ từ một đến nhiều bảng quan hệ từ một số bảng khác.

Nó là không cần thiết tuyệt vời cho mục đích bảo mật nhưng có những cách tốt hơn để thực hiện kiểm tra bảo mật. Hãy tưởng tượng, bạn tạo một chìa khóa chỉ có thể mở một cánh cửa. Nếu chìa khóa có thể mở bất kỳ cánh cửa nào khác, bạn nên bấm chuông báo động. Về bản chất, bạn có thể có "CitizenTable" và "V biểu đồ". Citizen One bỏ phiếu cho Ứng cử viên Một được lưu trữ trong Bảng bỏ phiếu. Nếu một công dân xuất hiện trong bảng biểu quyết một lần nữa, thì họ sẽ là một báo động. Hãy cho lời khuyên, đây là mối quan hệ một đối một vì chúng tôi không đề cập đến lĩnh vực ứng cử viên, chúng tôi đang đề cập đến bảng biểu quyết và bảng công dân.

Thí dụ:

 Citizen Table
 id = 1, citizen_name = "EvryBod"
 id = 2, citizen_name = "Lesly"
 id = 3, citizen_name = "Wasserman"

 Candidate Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"

Sau đó, nếu chúng ta thấy bảng biểu quyết như vậy:

 Voting Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"
 id = 4, citizen_id = 3, candidate_name = "Hill Arry"
 id = 5, citizen_id = 3, candidate_name = "Hill Arry"

Chúng ta có thể nói rằng công dân số 3 là một kẻ nói dối trên lửa đã lừa dối Bern Nie. Chỉ là một ví dụ.

Khi bạn đang xử lý cơ sở dữ liệu từ sản phẩm của bên thứ ba, thì có lẽ bạn không muốn thay đổi cơ sở dữ liệu của họ để ngăn chặn khớp nối chặt chẽ. nhưng bạn có thể có dữ liệu tương ứng 1: 1 với dữ liệu của họ

Bất cứ nơi nào có hai thực thể độc lập hoàn toàn chia sẻ mối quan hệ một đối một. Phải có rất nhiều ví dụ:

người <-> nha sĩ (1: N, vậy là sai!)

người <-> bác sĩ (1: N, vậy cũng sai!)

người <-> người phối ngẫu (tỷ lệ 1: 0 | 1, vì vậy hầu hết là sai!)

EDIT: Vâng, đó là những ví dụ khá tệ, đặc biệt nếu tôi luôn tìm kiếm 1: 1, không phải 0 hoặc 1 ở hai bên. Tôi đoán bộ não của tôi đã bắn nhầm :-)

Vì vậy, tôi sẽ thử lại. Hóa ra, sau một chút suy nghĩ, cách duy nhất bạn có thể có hai thực thể riêng biệt phải (theo phần mềm đi cùng nhau) là tất cả thời gian để chúng tồn tại cùng nhau trong phân loại cao hơn. Sau đó, nếu và chỉ khi bạn rơi vào tình trạng phân hủy thấp hơn, mọi thứ sẽ và nên tách biệt, nhưng ở cấp độ cao hơn, chúng không thể sống thiếu nhau. Bối cảnh, sau đó là chìa khóa.

Đối với cơ sở dữ liệu y tế, bạn có thể muốn lưu trữ thông tin khác nhau về các vùng cụ thể của cơ thể, giữ chúng như một thực thể riêng biệt. Trong trường hợp đó, một bệnh nhân chỉ có một cái đầu, và họ cần phải có nó, hoặc họ không phải là bệnh nhân. (Họ cũng có một trái tim, và một số cơ quan đơn lẻ cần thiết khác). Nếu bạn quan tâm đến việc theo dõi các ca phẫu thuật chẳng hạn, thì mỗi vùng sẽ là một thực thể riêng biệt.

Trong hệ thống sản xuất / kiểm kê, nếu bạn đang theo dõi việc lắp ráp xe, thì bạn chắc chắn muốn xem động cơ tiến triển khác với thân xe, nhưng vẫn có mối quan hệ 1-1. Một chăm sóc phải có một động cơ, và chỉ có một (hoặc nó sẽ không còn là 'xe hơi' nữa). Một động cơ chỉ thuộc về một chiếc xe.

Trong mỗi trường hợp, bạn có thể tạo ra các thực thể riêng biệt như một bản ghi lớn, nhưng với mức độ phân tách, điều đó sẽ sai. Chúng, trong các bối cảnh cụ thể, là các thực thể độc lập thực sự, mặc dù chúng có thể không xuất hiện ở mức cao hơn.

Paul.