Câu hỏi này cho thấy rằng bạn không hiểu đầy đủ về các mối quan hệ thực thể (không có ý định thô lỗ). Trong đó có bốn (về mặt kỹ thuật chỉ có 3 loại) dưới đây:
One to One One to Many Many to One Many to Many
Một đối một (1:1): Trong trường hợp này, một bảng được chia thành hai phần nhằm mục đích tuân thủ quá trình chuẩn hóa, hoặc thường là nguyên tắc đóng mở.
Chuẩn hóa tuân thủ:Bạn có thể có một quy tắc kinh doanh rằng mỗi khách hàng chỉ có một tài khoản. Về mặt kỹ thuật, trong trường hợp này, bạn có thể nói rằng tất cả khách hàng và tài khoản đều có thể ở trong cùng một bảng, nhưng điều này phá vỡ các quy tắc chuẩn hóa, vì vậy bạn tách chúng ra và tạo thành 1:1.
Nguyên tắc đóng mở tuân thủ:Một bảng khách hàng, có thể có id, họ và tên và địa chỉ. Sau đó, một người nào đó quyết định thêm ngày sinh và kèm theo đó là khả năng tính tuổi cùng với một loạt các trường cần thiết khác. Đây là một ví dụ đơn giản hóa quá mức của 1-1, nhưng bạn có thể sử dụng nó chính là để mở rộng cơ sở dữ liệu của bạn mà không phá vỡ mã hiện có. Nhiều mã được viết (thật đáng buồn là) được kết hợp chặt chẽ với cơ sở dữ liệu nên những thay đổi trong cấu trúc của bảng sẽ phá vỡ mã. Việc thêm tỷ lệ 1:1 như vậy sẽ mở rộng bảng để đáp ứng các yêu cầu mới mà không cần sửa đổi mã gốc, do đó cho phép mã cũ tiếp tục hoạt động bình thường và mã mới sử dụng các tính năng db mới.
Nhược điểm của việc chuẩn hóa và mở rộng bảng sử dụng mối quan hệ 1:1 theo cách này là hiệu suất. Thông thường, trên các hệ thống được sử dụng nhiều, mục tiêu đầu tiên để tăng hiệu suất cơ sở dữ liệu là hủy chuẩn hóa và kết hợp các bảng như vậy thành một bảng duy nhất và tối ưu hóa các chỉ mục do đó loại bỏ nhu cầu sử dụng các phép nối và đọc từ nhiều bảng. Chuẩn hóa / Không chuẩn hóa không phải là một điều tốt hay xấu, vì nó phụ thuộc vào nhu cầu của hệ thống. Hầu hết các hệ thống thường bắt đầu thay đổi chuẩn hóa trở lại khi cần thiết, nhưng thay đổi này cần được thực hiện rất cẩn thận như đã đề cập, nếu mã được kết hợp chặt chẽ với cấu trúc DB, nó gần như chắc chắn sẽ khiến hệ thống bị lỗi. tức là khi bạn kết hợp 2 bảng, một bảng không còn tồn tại, tất cả mã bao gồm bảng hiện không tồn tại đó sẽ không thành công cho đến khi nó được sửa đổi (theo điều khoản db, hãy tưởng tượng kết nối các mối quan hệ với bất kỳ bảng nào trong tỷ lệ 1:1, khi bạn xóa các bảng đó , điều này phá vỡ các mối quan hệ và do đó cấu trúc phải được sửa đổi rất nhiều để bù đắp. Thật không may, những thiết kế xấu như vậy dễ phát hiện hơn nhiều trong thế giới DB so với thế giới phần mềm trong hầu hết các trường hợp và bạn thường không nhận thấy có gì đó sai trong mã cho đến khi tất cả sụp đổ) trừ khi hệ thống được thiết kế phù hợp với tách các mối quan tâm trong tâm trí.
Đó là thứ gần nhất bạn có thể nhận được để kế thừa trong lập trình hướng đối tượng. Nhưng nó không hoàn toàn giống nhau.
Một đến nhiều (1:M) / Nhiều đến một (M:1): Hai mối quan hệ này (hense tại sao 4 trở thành 3), là những kiểu quan hệ phổ biến nhất. Cả hai đều là một kiểu quan hệ giống nhau, điều duy nhất thay đổi là quan điểm của bạn. Một ví dụ Một khách hàng có nhiều số điện thoại hoặc luân phiên, nhiều số điện thoại có thể thuộc về một khách hàng.
Trong lập trình hướng đối tượng, điều này sẽ được coi là thành phần. Nó không phải là sự kế thừa, nhưng bạn đang nói rằng một mục bao gồm nhiều phần. Điều này thường được biểu diễn bằng mảng / danh sách / bộ sưu tập, v.v. bên trong các lớp thay vì cấu trúc kế thừa.
Nhiều đến Nhiều (M:M): Mối quan hệ kiểu này với công nghệ hiện tại là không thể. Vì lý do này, chúng ta cần chia nó thành hai mối quan hệ từ một đến nhiều với một bảng "liên kết" tham gia chúng. Nhiều mặt của hai mối quan hệ từ một đến nhiều luôn nằm trong bảng liên kết / liên kết.
Đối với ví dụ của bạn, người nói bạn cần nhiều đến nhiều là chính xác. Bởi vì một từ hai đến nhiều thực sự là một mối quan hệ nhiều (có nghĩa là nhiều hơn một) với nhiều. Đây là cách duy nhất bạn có thể làm cho hệ thống của mình hoạt động. Trừ khi bạn đang có ý định nghiên cứu lĩnh vực phép tính quan hệ để tìm một số kiểu quan hệ mới cho phép điều này.
Ngoài ra đối với các mối quan hệ như vậy (m2m), bạn có hai lựa chọn, hoặc tạo một khóa ghép trong bảng trình liên kết để kết hợp các trường trở thành một mục nhập duy nhất (nếu bạn quan tâm đến việc tối ưu hóa db thì đây là lựa chọn chậm hơn, nhưng chiếm ít không gian hơn). Ngoài ra, bạn tạo trường thứ ba với cột id được tạo tự động và đặt đó làm khóa chính (để tối ưu hóa db, đây là lựa chọn nhanh hơn, nhưng tốn nhiều dung lượng hơn).
Trong ví dụ của bạn cụ thể ở trên ...
Đây sẽ là một mối quan hệ rất nhiều với bảng số điện thoại như một bảng liên kết giữa công ty và người dùng. Như đã giải thích, để đảm bảo không có số điện thoại nào bị lặp lại, bạn chỉ cần đặt nó làm khóa chính hoặc sử dụng một khóa chính khác và đặt trường số điện thoại thành duy nhất.
Đối với những loại câu hỏi, nó thực sự phụ thuộc vào cách bạn diễn đạt chúng như thế nào. Điều gì đang khiến bạn bối rối về điều này, và cách bạn vượt qua sự bối rối này để thấy giải pháp thật đơn giản. Diễn đạt lại vấn đề như sau. Bắt đầu bằng cách hỏi từng người một, nếu câu trả lời là không, hãy tiếp tục. Tiếp theo hãy hỏi nó có phải là một đối với nhiều không, nếu câu trả lời là không tiếp tục. Lựa chọn duy nhất còn lại là nhiều đến nhiều. Tuy nhiên, hãy cẩn thận, hãy đảm bảo rằng bạn đã xem xét 2 câu hỏi đầu tiên một cách cẩn thận trước khi tiếp tục. Nhiều người thiếu kinh nghiệm về cơ sở dữ liệu thường làm phức tạp hóa các vấn đề bằng cách xác định một đến nhiều hoặc nhiều. Một lần nữa, kiểu quan hệ phổ biến nhất cho đến nay là một với nhiều (tôi muốn nói là 90%) với nhiều với nhiều và một đối một gắn liền 10% còn lại 7/3 một cách tôn trọng. Nhưng những số liệu đó chỉ là quan điểm cá nhân của tôi, vì vậy đừng trích dẫn chúng như là số liệu thống kê tiêu chuẩn của ngành. Quan điểm của tôi là phải đảm bảo thêm rằng nó chắc chắn không phải là một trong nhiều trước khi chọn nhiều. Đó là giá trị nỗ lực thêm.
Vì vậy, bây giờ để tìm bảng liên kết giữa hai bảng, hãy quyết định xem hai bảng nào là bảng chính của bạn và trường nào cần được chia sẻ giữa chúng. Trong trường hợp này, cả bảng công ty và người dùng đều cần chia sẻ điện thoại. Rất tiếc, bạn cần tạo một bảng điện thoại mới làm trình liên kết.
Báo động cảnh báo về sự hiểu lầm sẽ hiển thị ngay sau khi bạn quyết định không có điều nào trong 3 điều đó phù hợp với bạn. Điều này đủ để cho bạn biết rằng đơn giản là bạn đang diễn đạt không chính xác câu hỏi về mối quan hệ. Bạn sẽ tiến bộ hơn khi thời gian trôi qua, nhưng đây là một kỹ năng cần thiết và thực sự nên thành thạo càng sớm càng tốt vì sự lành mạnh của chính bạn.
Tất nhiên, bạn cũng có thể truy cập cơ sở dữ liệu hướng đối tượng sẽ cho phép một loạt các mối quan hệ khác được gọi là mối quan hệ "Phân cấp". Thật tuyệt nếu bạn cũng đang nghĩ đến việc trở thành một lập trình viên. Nhưng tôi không khuyến khích điều này vì nó sẽ khiến bạn đau đầu khi bạn bắt đầu tìm cách kết hợp nhiều kiểu quan hệ khác nhau. Đặc biệt là không cần nhiều vì gần như tất cả các cơ sở dữ liệu trên thế giới chỉ bao gồm 3 loại mối quan hệ đó trừ khi chúng là một thứ gì đó siêu đặc biệt.
Hy vọng đây là một câu trả lời hợp lý. Cảm ơn vì đã dành thời gian đọc nó.
