Tôi đang tạo một sơ đồ khái niệm [vâng, tôi biết tôi đã bao gồm các thuộc tính và khóa - nhưng đây chỉ là để tôi củng cố những gì tôi đang làm trong khi học] - vì vậy hãy coi đó là Khái niệm với trọng tâm là Mối quan hệ và bảng và không làm thế nào để sơ đồ;)

Rào cản tâm trí của tôi là: Tôi đang cố gắng xác định cách tốt nhất để mô hình hóa các mối quan hệ Hồ sơ, Vị trí và Tổ chức.

Trước hết, QUY TẮC:

• Một hoặc nhiều Hồ sơ có thể là Thành viên / Bạn bè của một hoặc nhiều Tổ chức ; và ngược lại.
• Một hoặc nhiều Hồ sơ có thể là Thành viên / Bạn bè của Hồ sơ khác.
• Một hoặc nhiều Tổ chức có thể là Thành viên / Bạn bè của các Tổ chức khác.

Bạn bè và Thành viên khác nhau, ở chỗ, Bạn bè giống như chỉ đọc và Thành viên [tùy theo cấp độ] có toàn quyền truy cập để sửa đổi mọi thứ.

Để làm phức tạp hơn nữa, các Địa điểm có bộ quy tắc có thể tái cấu trúc "xa hơn" của riêng họ, ví dụ: Một Tổ chức sở hữu hai Địa điểm , nhưng tùy thuộc vào quy tắc Vị trí, Thành viên [ Hồ sơ ] của Tổ chức đó có thể có quyền truy cập đầy đủ tại một Địa điểm, nhưng quyền truy cập bị hạn chế tại khác [Xin lỗi: rất có thể bạn sẽ phải mở hình ảnh trong một cửa sổ khác để có kích thước xem tốt hơn.]

Vì vậy, như bạn có thể thấy, khái niệm Hồ sơ và Tổ chức rất giống nhau, cũng như khái niệm Bạn bè và Thành viên này chưa được mô hình hóa [... mà tôi tưởng tượng sẽ được xử lý giống như các bảng trung gian hiện tại với cài đặt Chủ sở hữu / Quản trị viên / Thành viên / Bạn bè, vv trong hồ sơ]. Do đó, tại sao tôi nghĩ về khái niệm sau:

Xem Tùy chọn.2 trong hình trên: sẽ xóa Bảng Tổ chức và Tổ chức hiện tại và các mối quan hệ của chúng, thay thế bằng Bảng tổ chức Tùy chọn.2 dưới dạng mối quan hệ đệ quy với Hồ sơ .

Tôi cho rằng mấu chốt của vấn đề là liệu tôi có quá bận tâm về mặt lập trình với Đa hình đối với sự bất lợi của sự đơn giản và linh hoạt hay không, làm tôi bối rối hoàn toàn trong quá trình;)

Cảm ơn những suy nghĩ của bạn trước, đánh giá cao - M :).

Sơ đồ sửa đổi:

Trả lời các câu hỏi của MDCCL:

1. Đúng, Hồ sơ được tạo thành từ một Người và có cùng một ý nghĩa - mặc dù lý do của bạn hướng đến - Tôi tin rằng bạn đúng: Tổ chức và Người có thể là các kiểu con của Hồ sơ ; do đó, một Hồ sơ được tạo thành từ một Người hoặc một Tổ chức.
2. Một địa chỉ email trên mỗi hồ sơ.
3. Đúng. Như trên, Tổ chức ít nhất phải có một Địa chỉ Email.
4. Đúng, một địa chỉ cố định.
5. Đó là một khả năng, nhưng rất hiếm - mặc dù từ những gì tôi đang học - do đó, người ta nên mô hình hóa như vậy cho tuổi thọ trong tương lai, v.v., và chỉ để xác nhận, một Địa điểm có thể được sở hữu bởi nhiều hơn một Người.

6. Vị trí chắc chắn là thực thể không thể thiếu giữa hầu hết những người khác. Có lẽ tôi sẽ làm rõ những gì có thể được thực hiện ngắn gọn ở đây, sau đó cho phép bạn đọc mặc dù các câu trả lời khác của tôi hy vọng sẽ có được những bổ sung có lợi cho câu hỏi này trước [ sau đó hãy xem câu trả lời của tôi cho # 6 ở cuối ];) Re: Chủ sở hữu vai trò. An **Organization** can be an Owner of zero or more **Locations**. A Person can be an owner of zero of more Locations[do đó, như bạn đã phỏng đoán trước đây; nói một cách đơn giản, một Hồ sơ có thể là chủ sở hữu của 0 hoặc nhiều Địa điểm / s.

7. Có, Hồ sơ là Chủ sở hữu của Địa điểm đảm nhận tất cả các Quyền vai trò [siêu người dùng]; một hồ sơ đó là một quản trị có thể sửa đổi một số chi tiết của Location , nhưng chủ yếu là giúp / chỉnh sửa các chi tiết / dữ liệu được cung cấp thông qua tất cả các khác Hồ sơ / s - điều này chủ yếu sẽ được cung cấp bởi 'Basic Member / s' của nói Location / s; khiến Thành viên cơ bản , người chỉ có thể đọc tất cả các chi tiết về Địa điểm và dữ liệu cung cấp có liên quan phải được Quản trị viên / Chủ sở hữu xem xét kỹ lưỡng . Ngoài ra, bất kỳ hồ sơ[Tổ chức / Người] giống như Thành viên cơ bản 'chỉ đọc' - hãy gọi họ là Khách - nhưng chỉ khi Vị trí được đặt là Công khai [và không riêng tư ], mặc dù họ không thể cung cấp đầu vào như Thành viên cơ bản có thể .

8. Chính xác.
9. Trực giác của bạn thật tuyệt vời! Có, it is foreseen that a single Location could contain one to many LocationTypes- để làm phức tạp mọi thứ hơn nữa - dự đoán rằng các LocationTypes riêng lẻ đó có thể có các quyền khác nhau cho Hồ sơ được liên kết với Vị trí 'Phụ huynh'; trong đó, các quyền sẽ lọc từ Location sang LocationType / s [giống như các quyền bảo mật thư mục hệ điều hành]. Tôi lưu ý thông qua sơ đồ của bạn, bạn có thể đề cập đến gõ nhiều hơn như một mô tả?
10. Đúng.
11. Xem 12.
12. Chính xác, khả năng Hồ sơ1 [Người hoặc Tổ chức] hành động theo Địa điểm thuộc sở hữu của Hồ sơ2 [Người hoặc Tổ chức] [nếu họ là Bạn bè / Thành viên có quyền chính xác] là điều tối quan trọng.
13. Rất hợp lý - a) đồng ý. b) đồng ý. c) Có, hmm? ... Có lẽ nó giống với Hồ sơ [người] với Hồ sơ [người] = Bạn bè . Dù mô tả là gì, nó sẽ xoay quanh Vị trí , vì Tổ chức / s sẽ hành động theo các Vị trí / Tổ chức khác ; mặc dù về mặt ngữ nghĩa, tôi nghi ngờ bất kỳ Tổ chức nào cũng muốn xuất hiện với tư cách là 'Thành viên' của Tổ chức Địa điểm đó để có thể như vậy, 'cho dù nguyên nhân tốt đến đâu'.

[6]. Đây vẫn là một màu xám đối với tôi, nhưng ở đây đi ... Để có thể gây bất lợi cho tôi, sự tương đồng giữa các mối quan hệ Thành viên / Bạn bè rất gần đến nỗi tôi nghĩ sẽ kết hợp chúng; nhìn chung với sơ đồ và diễn giải của bạn, có vẻ như bạn có thể giữ chúng tách biệt [ Tôi sẽ phân biệt mối quan hệ duy nhất thông qua thuộc tính enum: Chủ sở hữu / Quản trị viên / Thành viên / Bạn bè ]. Khái niệm của bạn như ví dụ: Vị trí được sở hữu bởi một Tổ chức sẽ có 0 đối với nhiều Hồ sơ [Người hoặc Tổ chức] hành động theo nó, mặc dù cần có sự khác biệt rõ ràng giữa cách thức Tiểu sử hành động theo địa điểm thông qua mối quan hệ [Thành viên hoặc Bạn bè ] ký hiệu thông qua Vai trò.So perhaps, the default relation between any Profile is Friend [much like Guest at Answer#7], enabling them to view the read-only Location data and msg/email the Location Owner/Admin - but not allow them to receive Location updates, news, etc., as a Member would.

Thật tuyệt khi bạn dành thời gian để hiểu, phân loại và mô hình hóa dữ liệu bạn đang xử lý, từ kinh nghiệm cá nhân của tôi, tất cả điều này làm cho toàn bộ quá trình phát triển dễ dàng hơn và rất linh hoạt cho những thay đổi trong tương lai. Và tôi khá chắc chắn rằng bạn cũng nhận thức được điều này rồi.

Mô hình dữ liệu sơ bộ và quy tắc kinh doanh giả định

Tôi đã xác định một danh sách các quy tắc kinh doanh mà tôi đã thừa nhận sau khi đọc câu hỏi của bạn và kiểm tra chặt chẽ sơ đồ của bạn, để mô tả sự thiếu hiểu biết của tôi về thông số kỹ thuật của bạn. Sau khi xác định danh sách đó, tôi đã lấy mô hình dữ liệu IDEF1X ^[1] mà tôi quyết định tải lên dưới dạng tài liệu .PDF trong một nền tảng bên ngoài (Dropbox), do định dạng của mô hình dữ liệu này không phù hợp với hình ảnh nhúng. Hai công cụ này sẽ hữu ích khi tham khảo cho một số điểm quan trọng mà tôi liệt kê dưới đây trong phần có tiêu đề Các khía cạnh để giải quyết để tiếp tục tiến về phía trước .

Đầu tiên, đây là trò chơi

• Mô hình dữ liệu sơ bộ tổ chức và hồ sơ .

Vì chỉ có vậy, sơ bộ, hãy coi nó như một phương tiện giúp chúng tôi hoàn thành mô hình dữ liệu cuối cùng mong muốn.

Quy tắc kinh doanh giả định

Mô hình dữ liệu sơ bộ cho biết được lấy từ một tập hợp các quy tắc kinh doanh (được suy ra từ câu hỏi của bạn) mà tôi sẽ liệt kê như sau:

Tổ chức và hồ sơ

Lưu ý rằng Profilehiện được hiểu là một từ đồng nghĩa cho Person.

• An Organizationlà bạn của nhiều người Profiles .
• An Organizationlà bạn của nhiều người Organizations .
• An Organizationlà thành viên của một-nhiều Organizations .
• A Profilelà thành viên của một-nhiềuOrganizations .
• A Profilelà bạn của nhiều người Profiles .
• A Profilelà thành viên của một-nhiều Profiles .

Địa điểm và địa chỉ

• An Organizationsở hữu một-nhiều Locations .
• A Locationđược phân loại theo một-nhiều LocationTypes ( chỉ một tại một thời điểm nhất định).
• Một Locationcó thể có một-nhiều Addresses ( một Physical , một cho Shipping, một cho Billing, hoặc một trong đó phục vụ mục đích tất cả nói, hoặc một kết hợp hai mục đích và khác phục vụ duy nhất một trong số họ).

• An Addresscó thể được giữ bởi một-nhiều Profiles hoặc, nói cách khác, Profilegiữ một-nhiều Addresses .

• Một cụ Addresscó thể được sử dụng bởi một-nhiều Profiles (phục vụ như Physicalcho một Profile , được sử dụng cho Billingbởi một chương trình khác , vv). Vì vậy, một Addresscông trình theo cách tương tự cho Locationsvà Profiles.

  • Do đó, một cá nhân Addresscó thể, cùng một lúc , thuộc loại Physical, Shipping và Billing .

Vị trí và vai trò

• A Locationmở một-nhiều Roles .
• A Rolecó thể được thực hiện trong một-nhiều Locations .
• Một Profile(một khi nó đã được đặt là Membermột Organization) có thể thực hiện một-nhiều Roles , trong một-nhiều Locations (nhưng chỉ một cụ thể Roletrong mỗi Locationtại một thời điểm cụ thể, nghĩa là không bao giờ hai hoặc nhiều hơn Roles cùng một lúc ).

Các khía cạnh để giải quyết để tiếp tục tiến về phía trước

Để tiếp tục cải thiện độ phân giải của mô hình dữ liệu của bạn, đây là danh sách các điểm có liên quan mà một khi chúng tôi giải quyết chúng sẽ giúp chúng tôi đạt được mục tiêu này:

1. Tôi đã giả định rằng thuật ngữ Profiletrong ngữ cảnh của bạn có nghĩa tương tự (hoặc giống nhau) với nghĩa của Personnó, nhưng nó có thể hơi khác một chút. Theo cách này, bạn có nói rằng, trong kịch bản của bạn, các thực thể Organizationvà Personlà kiểu con của Profile?

2. Một Profile(hoặc Person) có thể sở hữu một-nhiều EmailAddresses , hoặc một Profile(hoặc Person) cố định với chính xác một EmailAddress ?

3. Bạn có muốn cung cấp khả năng cho một Organizationliên hệ thông qua Telephonevà Email, hoặc bạn muốn hạn chế điều đó chỉ có thể cho một Profile(hoặc Person)?

4. Tôi giả sử rằng a Locationđược cố định chính xác với một Address trong các loại Physical, điều này có đúng không?

5. Có thể Locationchia sẻ cho một người với nhiều người khác nhau Organizations hay không, nếu không, chỉ Locationcó thể được sở hữu bởi một người Organization ?

6. Bạn đã tuyên bố thông qua ý kiến ​​rằng thực tế là một Membervà một Friendlà như nhau. Như bạn có thể thấy trong mô hình dữ liệu sơ bộ được đề xuất của mình, tôi đã theo dõi các thông số kỹ thuật ban đầu của bạn và mô tả tất cả các kết hợp thành viên và tình bạn có thể giữa Organizationvà Profile(hoặc Person) trong các thực thể khác nhau vì tôi nghĩ rằng nó có thể hữu ích trong nỗ lực xác định tốt nhất có thể cấu trúc cho phần đó của kịch bản của bạn. Trong trường hợp này:

   • Tôi giả sử rằng câu lệnh an Organization is a Member of another Organizationcó tác dụng khác với câu lệnh a Profile (or Person) is a Member of an Organizationliên quan đến thực thể được gọi Location.
   • Như bạn có thể thấy trong các mô hình dữ liệu, tôi nghĩ rằng Rolecác Ownerchỉ áp dụng cho một Organizationvà, với tôi, sự hợp lệ Rolescho một Profile(hoặc Person), bên trong một Locationlà Adminvà Member. Bạn nghĩ gì về tất cả những điều này? Vì bạn đang tiếp xúc trực tiếp với các quy tắc kinh doanh áp dụng cho tình huống của bạn, bạn cần cho tôi biết nếu các giả định của tôi là đúng.

7. Một Profile(hoặc Person) chơi khác nhau Rolestrong cùng một Location? tức là, một cái Personcó thể, cùng một lúc, Adminvà cũng là một Membercái giống nhau Locationkhông? Các quy tắc trong vấn đề này là gì?

8. Tôi nghĩ rằng cùng Profile(hoặc Person) có thể chơi khác nhau Rolestrong khác nhau Locations. Ví dụ: Một Profile(hoặc Person) cụ thể là một Admin Admin trong trò chơi Location1, và cùng một Profile(hoặc Person) là một MemberTrò chơi trong trò chơi Location2 lần, cùng một lúc. Tôi có đúng không

9. Có thể một cụ thể Locationcó sự khác biệt LocationTypescùng một lúc, hoặc một cá nhân được Locationcố định để giữ chính xác một LocationType?

10. Có phải thuộc tính Organization.Websiteđại diện cho địa chỉ trang web của một tổ chức cụ thể, chẳng hạn như là dba.stackexchange.com không?

11. Nếu một trong những thứ Profile1 (được hiểu là Person) là một Member(hoặc Friend) của Profile1 2, thì có thể để Profile1 1 1 thực hiện Roletrong một Locationsở hữu bởi một 2 sở hữu Profilekhông? Tôi nghĩ rằng các kịch bản như vậy chỉ có giá trị cho các mối quan hệ giữa một Organizationvà Member Personvì vậy, bạn nghĩ gì?

12. Theo cách tương tự, nếu Lọ Organization1 1 là một Member(hoặc Friend) của OrganizationGiv 2, thì có thể để Organization1 1 1 thực hiện một Rolecách Locationthuộc sở hữu của một Organization2 2 không? Một lần nữa, tôi nghĩ rằng loại kịch bản này chỉ có giá trị cho các mối quan hệ giữa một Organizationvà một Member Person, điều này có đúng không?

13. Về vấn đề này, trong khi tôi đang viết câu hỏi này, tôi nghĩ rằng sẽ hợp lý khi nói rằng chỉ có ba loại mối quan hệ khác nhau liên quan Organizationsvà Persons, và chúng ta có thể định nghĩa:

    • (a) Mối quan hệ giữa một Organizationvà Personnhư là tôn phạm Membership.
    • (b) Mối quan hệ giữa a Personvà một người khác khác nhau Personnhư Quy phạm Friendhip.
    • (c) Chúng tôi vẫn chưa tìm thấy một tên có ý nghĩa để mô tả mối quan hệ giữa một cá nhân Organizationvà một người khác Organization.
    • Vì vậy, hãy cho tôi biết những gì bạn nghĩ về (a), (b) và (c).

14. Có thể Organizationmột Friend(hoặc a Member) của một-nhiều- khác nhau Organizationscùng một lúc không? Hoặc chỉ có thể là Organizationchỉ có một mối quan hệ với độc quyền khác nhauOrganization?

Mô hình dữ liệu kế tiếp mô tả bước tiến đầu tiên

Để ý các câu trả lời và giải quyết của bạn đối với các khía cạnh đang chờ xử lý mà tôi đã liệt kê ở trên, tôi đã tạo ra các bản sau

• Mô hình dữ liệu sơ bộ của tổ chức và hồ sơ - Trước tiên .

Mặc dù tôi không cảm thấy khá thoải mái với nó, nhưng mô hình dữ liệu mới này thể hiện các quy tắc kinh doanh sau:

• Một Profilelà một trong hai một Organization hoặc một Person. ^[2]
• A Profilecó thể là bạn của một người với nhiều người FriendProfiles , và Profilecó thể là bạn chấp nhận của một người với nhiều người FriendProfiles . ^[3]
• A Locationcó thể bao gồm một-nhiều Locations . ^[4]

Câu trả lời cho ý kiến ​​cụ thể tiếp theo của bạn

Nó thực sự thú vị đối với tôi khi lưu ý / gộp các mối quan tâm [ví dụ: LocationAddress và ProfileAddress] - vì rõ ràng tôi muốn lao vào và giữ tất cả chúng mà không có mối quan hệ chính xác [vui thay, nó không cảm thấy đúng với ERD ban đầu của tôi].

Vâng, đó là một so sánh tốt, mặc dù tôi sẽ không gọi đó là sự tách biệt các mối quan tâm (chắc chắn là nguyên tắc cơ bản trong lập trình và thiết kế ứng dụng), vì thuật ngữ này thường liên quan đến giai đoạn phát triển ứng dụng và chúng tôi hiện đang tìm thấy chính mình trong giai đoạn hiểu dữ liệu và thiết kế cấu trúc logic của nó.

Từ kinh nghiệm cá nhân của tôi, tôi cho rằng giai đoạn này có liên quan đến việc đưa những điều quan trọng vào toàn bộ bối cảnh của họ, nó phải làm với việc nhìn thấy các mối liên hệ tồn tại giữa các thực thể khác nhau có liên quan trong kịch bản quan tâm cụ thể, và sau đó mô tả những điều này trong một mô hình dữ liệu. Trong trường hợp cụ thể mà bạn đang bình luận, Addressthực thể có thể có các loại kết nối khác nhau với các thực thể khác, một với Profilevà một khác với Location.

Và, vâng, khi một cái gì đó không cảm thấy đúng hoặc tự nhiên , đó cũng có thể là một dấu hiệu cho thấy một người cần phải nỗ lực nhiều hơn để hiểu được dữ liệu thích hợp. Theo cách này, Addressthực thể là một trong những điều mà tôi cho rằng cần được chú ý nhiều hơn, vì tôi nghĩ rằng mối quan hệ giữa a Profilevà an Address có thể được xử lý bằng phương tiện của Locationthực thể (do thực tế là mọi người Locationphải có ít nhất một vật lý Address), do đó chúng tôi có thể loại bỏ ProfileAddressthực thể liên kết được mô tả trong mô hình mới nhất, nhưng bạn nên tiếp tục phân tích những điểm này và cho tôi biết ý tưởng của bạn.

Ngoài ra, có phải thông lệ trong IDEF1X là thay đổi các từ chối PK / FK trong các thực thể để dễ đọc hơn [ví dụ: ProfileId - LocationOwnerProfileId]?

Vâng, đó là một nhận xét rất thông minh từ bạn, vì IDEF1X khuyên bạn nên sử dụng tên vai trò để định danh TỪ KHÓA NGOẠI TỆ, để nắm bắt ý nghĩa của các thuộc tính đó theo thực thể mà nó đang được sử dụng. Cũng cần lưu ý rằng điều này cũng liên quan mạnh mẽ đến khái niệm di chuyển khóa chính . Như một vấn đề thực tế, việc sử dụng tên vai trò có trước IDEF1X, do nó ban đầu được trình bày bởi Tiến sĩ EF Codd trong văn bản bán kết năm 1970 của ông. Theo cách này, người ta có thể thấy rõ độ trung thực mà tiêu chuẩn IDEF1X giữ cho mô hình quan hệ .

Tôi có muốn tìm hiểu những gì bạn không đặc biệt thích / cảm thấy nó không phải là mô hình, với / trong giải pháp không?

Bên cạnh các chi tiết đã được mô tả ở trên về Addressthực thể, tôi không chắc liệu các Rolesthực hiện được đưa ra Profiletrong một cụ thể Locationcó tương đương với một Organizationhoặc một Person. Từ quan điểm của tôi, Persontrước tiên cần phải được liên kết với một Organization, và sau đó điều này Organizationsẽ chỉ định nói Personđể thực hiện một Rolecách cụ thể Location, nhưng bạn biết kịch bản tốt hơn, vì vậy quy tắc này có thể là không cần thiết. Về vấn đề này, tôi sẽ nhấn mạnh về thực tế là nó sẽ rất hữu ích cho tôi để biết mô tả theo ngữ cảnh hoặc ý nghĩa rằng những người sử dụng trong tương lai điều này tạo cấu trúc dữ liệu để Organization, ProfilevàLocation, nhưng tôi hiểu rằng đây có thể được coi là thông tin bí mật, vì vậy đây sẽ là một hạn chế.

Với cấu trúc hiện tại, có vẻ như mọi người ( Organizationhoặc Person) có thể liên quan đến bất kỳ ai (một lần nữa, Organizationhoặc Person) và có thể / làm bất cứ điều gì ( Role) ở bất cứ đâu ( Location), nhưng, chia sẻ, đây là điều mà bạn và người dùng đang mong đợi từ cơ sở dữ liệu này , trong đó bạn sẽ cung cấp các ràng buộc được xác định rõ, tất nhiên. Nếu đây là trường hợp, thì chúng tôi gần như cung cấp một giải pháp cuối cùng. Vì, một cách tự nhiên, ý kiến ​​của bạn là quyết định trong tình huống này, bạn cũng nên phân tích ý tưởng này và sau đó cho tôi biết kết luận của bạn để chúng tôi có thể thực hiện các bước cuối cùng.

Thứ hai khả thi

Thật không may, sự hài hước đã dừng lại vài tuần trước, tôi đoán vì những cam kết công việc mà bạn phải đáp ứng, điều này là hoàn toàn hợp lý. Tôi sẽ có nhiều nội dung hơn nếu chúng tôi đã phát triển một mô hình ổn định và mạnh mẽ hơn, nhưng do các tương tác trước đây của chúng tôi, tôi có thể cho rằng tôi đã có thể chỉ cho bạn đi đúng hướng.

Ngoài những gì đã được trình bày trong quy trình trả lời câu hỏi này, tôi cho rằng việc cung cấp một tiến trình mới từ các mô hình dữ liệu trước đó có thể hữu ích cho những người tìm kiếm khác có vấn đề tương tự. Vì vậy, tôi đã tạo ra các bản vá

Mô hình dữ liệu sơ bộ của tổ chức và hồ sơ - Thứ hai

Như có thể thấy trong mô hình dữ liệu như vậy, tôi đã loại bỏ mối quan hệ nhiều-nhiều mà tôi đã mô tả trong các mô hình trước đó giữa Profilevà Address, vì một cái đã cho Profileđã liên quan đến một-nhiều Addresses thông qua sở hữu của nó Locations.

Một thay đổi khác được minh họa trong tiến bộ mới này là thực tế là bây giờ nó bao gồm khả năng một cái đã cho Locationcó thể được sở hữu bởi nhiều người Profiles . Do đó, tôi đã thay đổi LocationPRIMARY KEY (bằng cách gạt bỏ những LocationOwnerProfileIdthuộc tính) và sau đó thêm vào một thực thể kết hợp ( nhiều-nhiều ) có liên quan Profilevới Location.

Ghi chú

_{1. IDEF1X là một kỹ thuật mô hình hóa dữ liệu rất được khuyến khích , được định nghĩa là một tiêu chuẩn vào tháng 12 năm 1993 bởi Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa Kỳ ( NIST ).}

_{2. Đây là một ocurrence của một cụm (siêu) kiểu phụ . Trong trường hợp bạn quan tâm, đây là một câu trả lời trong đó tôi giải quyết một cách chi tiết hơn với loại mối quan hệ này.}

_{3. Một ví dụ về mối quan hệ phân cấp nhiều-nhiều , và rất giống với cấu trúc đã đưa ra giải pháp dứt khoát cho Vấn đề Khám phá Bộ phận của Hồi . Tất nhiên, giải pháp như vậy được Tiến sĩ Edgar Frank Codd giới thiệu trong bài báo có ảnh hưởng rất lớn của ông 1970 Một mô hình dữ liệu quan hệ cho các ngân hàng dữ liệu chia sẻ lớn .}

_{4. Như vậy, đây là một ví dụ của mối quan hệ phân cấp một-nhiều (hoặc nhiều-một) .}

Tôi nghĩ rằng bạn đang cố gắng kết hợp các khái niệm từ mô hình đối tượng và khái niệm từ mô hình hóa dữ liệu theo cách không giúp bạn làm rõ sự hiểu biết của riêng bạn về vấn đề. Tôi hy vọng tôi có thể xóa sự lộn xộn một chút mà không quá lan man.

Mô hình quan hệ, như vậy, không hỗ trợ kế thừa, không bao giờ quan tâm đến đa hình. Điều này có nghĩa là một mẫu thiết kế khá chuyên dụng phải được sử dụng khi mô hình hóa một tình huống thực tế dễ xử lý bởi tính kế thừa và tính đa hình trong mô hình đối tượng. Thêm về mẫu thiết kế đặc biệt đó sau.

Khi mô hình ER được phát triển lần đầu tiên, nó được cho là một sự thay thế bất khả tri đối với mô hình quan hệ. Lúc đầu, nó cũng không có gì giống như thừa kế. Nhưng một thời gian trong những năm 1980 hoặc 1990, mô hình đã được mở rộng để cung cấp một số khả năng biểu cảm tương tự mà bạn có được với sự kế thừa. Đây được gọi là "mô hình ER mở rộng", nhưng với tất cả các mục đích thực tế, mô hình ER ngày nay bao gồm các tính năng EER.

Một tính năng EER có tên là "khái quát hóa / chuyên môn hóa". Bạn có thể tìm kiếm và đọc lên khái niệm này trên web. Gen-spec cung cấp nhiều khả năng biểu cảm giống như các lớp và các lớp con cung cấp trong một mô hình đối tượng. Tuy nhiên, Gen-spec không giải quyết các vấn đề xung quanh thiết kế bảng quan hệ cho tình huống gen-spec. Thêm về điều đó sau.

Trong mô hình ER, một mối quan hệ luôn liên quan đến cùng các thực thể. Do đó, mối quan hệ bạn bè giữa một tổ chức và một hồ sơ không giống như mối quan hệ bạn bè giữa một hồ sơ và một hồ sơ khác. Hai mối quan hệ cần tên khác nhau. Bạn sẽ tự trói mình trong các nút thắt nếu bạn không tuân theo quy tắc này.

Dù vậy, hoặc bạn cần đưa ra một thực thể tổng quát trong đó Tổ chức, Hồ sơ và có thể là Địa điểm đều là các chuyên ngành. Tôi không hiểu trường hợp của bạn đủ tốt để giúp bạn với điều đó.

Tiếp tục, tôi nhận thấy rằng bạn đang kết hợp mô hình quan hệ và mô hình ER của bạn lại với nhau thành một mô hình duy nhất. Hầu hết các kiến ​​trúc sư cơ sở dữ liệu dày dạn làm điều này. Nhưng tôi khuyên bạn nên giữ hai mô hình riêng biệt (mặc dù đối chiếu với nhau) cho đến khi bạn đạt được trình độ thành thạo.

Cuối cùng, làm thế nào để một thiết kế các bảng quan hệ đại diện cho một tình huống gen-spec? Hãy thử tra cứu hai mẫu thiết kế này "Kế thừa bảng lớp" và "Kế thừa bảng đơn". Có hai thẻ cho những thứ này trong Stackoverflow. Ngoài ra còn có một số bài thuyết trình khá tốt về các mẫu trên web. Tôi đặc biệt thích cách đối xử của Martin Fowler. Anh ta dường như biết những người làm mô hình đối tượng nghĩ như thế nào. Hi vọng điêu nay co ich.