我正在創建一個概念圖

$$ yes, I know I’ve included attributes and keys - but this is just for me to consolidate what I’m doing whilst learning $$- 所以請將其視為概念性的，重點是關係和表格，而不是如何繪製圖表；) 我的思想障礙是： 我正在嘗試確定對個人資料、位置和組織關係建模的最佳方式。

首先，規則：

• 一個或多個個人資料可以是一個或多個組織的成員/朋友；反之亦然。
• 一個或多個Profile可以是其他 Profile 的成員/朋友。
• 一個或多個組織可以是其他組織的成員/朋友。

Friend 和 Member 的不同之處在於，Friends 是只讀的，而 Member

$$ depending on level $$完全可以修改東西。 更複雜的是，地點有自己的一套“進一步”可完善的規則，例如，一個組織擁有兩個地點，但根據地點規則，該組織的成員 [個人資料] 可能在一個地點擁有完全訪問權限，但在其他。$$ Sorry: you’ll most likely have to open the image in another window for better viewing size. $$

如您所見，個人資料和組織的概念非常相似，還有尚未建模的朋友和成員概念

$$ …which I imagine will be handled much like the current intermediary tables with setting Owner / Admin / Member / Friend etc. in the record $$. 因此，為什麼我在考慮以下概念： 請參閱上圖中的 Option.2：這將刪除目前的Organization和Organization_Locations表及其關係，將其替換為 Option.2 組織表作為與Profile的某種遞歸關係。

我想問題的癥結在於我是否對多態性過於注重程序化，從而損害了簡單性和靈活性，在這個過程中完全混淆了自己；）

提前感謝您的想法，非常感謝 - M :)。

修改後的圖表：

針對 MDCCL 的問題：

1. 是的，Profile由一個 Person 組成並且具有相同的含義-儘管您的基本原理在哪裡-我相信您是正確的：Organization和Person可能是Profile的子類型；因此，個人資料要麼由一個人組成，要麼由一個組織組成。
2. 每個配置文件一個電子郵件地址。
3. 是的。如上所述，組織至少應該有一個電子郵件地址。
4. 正確，一個固定地址。
5. 這是一種可能性，但很少見 - 儘管從我所學到的 - 因此應該為未來的長壽等建模，並且只是為了確認，因此一個位置可能由多個人擁有。
6. 位置絕對是大多數其他實體之間不可或缺的實體。也許我會在這裡簡明扼要地澄清什麼可以做，然後讓你閱讀我的其他答案，希望首先對這個問題有有益的補充[然後在最後看到我對 #6 的回答] ;)回复：角色所有者。 An **Organization** can be an Owner of zero or more **Locations**. A Person can be an owner of zero of more Locations[因此，正如你之前推測的那樣；簡而言之，個人資料可以是零個或多個位置的所有者。
7. 是的，作為位置所有者的個人資料承擔所有角色權限

$$ super user $$; 作為管理員的個人資料可以修改位置的某些詳細資訊，但主要幫助/編輯通過所有其他個人資料提供的詳細資訊/數據- 這將主要由所述位置的“基本會員”提供；剩下的Basic Member可以只讀所有相關的Location詳細資訊並提供必須由Admin/Owner審查的數據。除此之外，任何個人資料 $$ Organization/Person $$很像Basic Member ‘read-only’ - 讓我們稱他們為Guest - 但前提是 Location 設置為Public [而不是Private ]，儘管他們不能像Basic Member那樣提供輸入。 8. 正確的。 9. 你的直覺是驚人的！是的，it is foreseen that a single Location could contain one to many LocationTypes- 使事情進一步複雜化 - 預計這些單獨的 LocationTypes 可能對與“父”位置關聯的配置文件具有不同的權限；其中，權限將從 Location 過濾到 LocationType/s$$ much like OS folder security permissions $$. 我通過您的圖表注意到您可能指的是輸入更多作為描述？ 10. 是的。 11. 見 12。 12. 正確，Profile1的能力 $$ Person or Organization $$對Profile2採取行動 $$ Person or Organization $$自有地點 $$ if they’re Friend/Member with correct permissions $$是最重要的。 13. 非常合理 - a)同意。b)同意。c)是的，嗯？…也許應該和Profile 差不多$$ person $$配置文件$$ person $$=朋友。無論描述如何，它將圍繞Location展開，因為Organization /s 將作用於其他Organization Location /s；儘管從語義上講，我懷疑任何組織都希望以該地點組織的“成員”的身份出現，以便能夠做到這一點，“無論事業多麼好。”

$$ 6 $$. 這對我來說仍然有點灰色，但是這裡有……可能對我不利的是，成員/朋友關係之間的相似性非常接近，以至於我想將它們結合起來；事後看來，您的圖表和解釋似乎將它們分開可能是正確的[我打算通過列舉屬性區分單一關係：所有者/管理員/成員/朋友]。您的概念例如：組織擁有的位置將具有零到多個配置文件$$ Person or Organization $$對其採取行動，儘管配置文件如何通過其關係對位置採取行動之間應該有明顯的區別$$ Member or Friend $$通過角色表示。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.

很高興您花時間來理解、分類和建模您正在處理的數據，因為根據我的個人經驗，所有這些都使整個開發過程更容易，並且對於未來的變化非常靈活。我很確定你也已經意識到了這一點。

初步數據模型和假設的業務規則

在閱讀您的問題並仔細檢查您的圖表後，我定義了一個業務規則列表，以描述我對您的規範的理解。在定義了這樣的列表之後，我得到了一個 IDEF1X**$$ 1 $$我決定在外部平台 (Dropbox) 中以 .PDF 文件的形式上傳的數據模型，因為由於其格式，該數據模型不太適合嵌入圖像。這兩個工具對於我在下面標題為要解決的方面以繼續前進**的部分中列舉的一些重要點將是有用的參考。

首先，這裡是…

• 組織和概況初步數據模型。

因為它只是初步的，將其視為幫助我們完成所需的最終數據模型的一種手段。

假定的業務規則

所述初步數據模型源自一組業務規則（從您的問題推斷），我將列舉如下：

組織和簡介

請注意，Profile目前被理解為 的同義詞Person。

• AnOrganization是一對多 Profiles的朋友。
• AnOrganization是一對多 Organizations的朋友。
• AnOrganization是一對多 Organizations的成員。
• AProfile是一對多Organizations的成員。
• AProfile是一對多 Profiles的朋友。
• AProfile是一對多 Profiles的成員。

地點和地址

• AnOrganization擁有一對多 Locations。

• ALocation按一對多 LocationTypes分類（在給定時間點只有一個）。

• ALocation可能有一對多 Addresses（一個 Physical、一個用於Shipping、一個用於或一個用於所有上述目的，Billing或者一個結合了兩個目的而另一個僅用於其中一個目的）。

• AnAddress可以保持一對多 Profiles，或者換句話說，aProfile保持一對多 Addresses。

• 一個特定的Address可以被一對多 使用Profiles（作為一個，被另一個使用，等等）。因此， an對和的工作方式類似。Physical Profile``Billing``Address``Locations``Profiles

  • 因此，一個人可能Address同時屬於****和類型。Physical``Shipping Billing

位置和角色

• ALocation打開一對多 Roles。
• ARole可以以一對多的 Locations方式進行。
• A Profile（一旦被設置為Membera Organization）可以執行一對多 Roles，一對多 Locations（但在特定時間點每個中只有一個特定的，即不會同時有兩個或多個）。Role``Location Roles

為了繼續前進需要解決的方面

為了不斷提高數據模型的解析度，這裡列出了相關要點，一旦我們解決了這些要點，將幫助我們實現這一目標：

1. 我假設Profile您上下文中的術語與 的 具有相似（或相同）的含義Person，但可能會有所不同。這樣，您是否會說，在您的場景中，實體Organization和Person是 的子類型Profile？
2. a Profile(or Person) 可以擁有one-to-many EmailAddresses，還是a Profile(or Person) 固定為one EmailAddress？
3. 您是否想提供Organization通過Telephoneand聯繫 a 的可能性Email，或者您想將其限制為僅適用於 a Profile(or Person)？
4. 我假設 aLocation被固定為type之一 ，這是正確的嗎？Address``Physical
5. a 是否有可能由一對多不同的人Location共享，或者，a只能由一個人擁有？Organizations Location Organization
6. 您已通過評論表示，作為 aMember和 a的事實Friend是相同的。正如您在我提出的初步數據模型中看到的那樣，我遵循了您的原始規範並描述了不同實體中Organization和Profile（或Person）之間所有可能的成員資格和友誼組合，因為我認為這有助於定義最佳可能方案的那一部分的結構。在這個意義上說：

• 我假設該語句與該語句對名為 的實體an Organization is a Member of another Organization具有不同的效果。a Profile (or Person) is a Member of an Organization``Location
• 正如您在數據模型中看到的那樣，我認為RoleofOwner僅對 an 有效Organization，對我來說，Roles對 a Profile(or Person) 有效，在 a 內部Location是Adminand Member。你怎麼看這一切？由於您直接接觸適用於您的情況的業務規則，因此您需要告訴我我的假設是否正確。

7. 一個Profile（或）可以在同一個里面Person玩不同的嗎？即，a可以同時是 the和 a of the same嗎？這方面的規則是什麼？Roles``Location``Person``Admin``Member``Location
8. 我認為相同的Profile（或Person）可以Roles在不同的Locations. 例如：一個特定的Profile（或Person）是Location“1”中的“Admin”，同時這個Profile（或Person）是“2”Member中的Location“”。我對嗎？
9. 一個特定Location的人是否有可能同時擁有不同LocationTypes的人，或者一個人是否Location固定持有一個人LocationType？
10. 該屬性是否Organization.Website代表特定組織的網站地址，例如“dba.stackexchange.com”？
11. 如果Profile“1”（理解為Person）是“2”的一個Member（或Friend），那麼“1”Profile是否有可能在“2”擁有的ProfileaRole中進行a ？我認為這樣的場景只對an和a之間的關係有效，你怎麼看？Location``Profile``Organization``Member Person
12. 類似地，如果Organization“1”是“2”的一個Member（或Friend） ，那麼“1”是否Organization有可能在“2”擁有的a中Organization執行a ？同樣，我認為這種情況僅對 an和 a之間的關係有效，這是正確的嗎？Role``Location``Organization``Organization``Member Person
13. 在這方面——當我寫這個問題時——我認為可以合理地說只有三種不同類型的關係涉及Organizations和Persons，我們可以定義：

• Organization(a) a和 a之間的關係Person為“ Membership”。
• (b) aPerson與另一個不同Person為“ Friendhip”的關係。
• (c) 我們還沒有找到一個有意義的名字來描述一個Organization人和另一個不同的人之間的關係Organization。
• 所以，讓我知道你對 (a)、(b) 和 (c) 的看法。

14. a是否有可能同時成為一對多不同的Organizationa Friend（或 a Member）？或者，一個人只可能只與一個不同的人有關係Organizations``Organization``Organization?

描述第一次進展的連續數據模型

考慮到您對我上面列出的未決方面的回應和解決方案，我創建了以下內容……

• 組織和概況初步數據模型——第一次進展。

雖然我還不太適應，但這個新的數據模型表達了以下業務規則：

• AProfile是a或a 。Organization _Person$$ 2 $$
• AProfile可能是一對多 FriendProfiles的提供朋友，而 aProfile可能是一對多的接受朋友 FriendProfiles。$$ 3 $$
• ALocation可能由一對多 Locations組成。$$ 4 $$

對您隨後的具體評論的答复

注意到/複合關注點的分離對我來說真的很有趣

$$ e.g. LocationAddress and ProfileAddress $$- 因為我顯然想衝進去並在沒有正確關係的情況下抓住它們$$ funnily, It didn’t feel right with my original ERD $$.

是的，這是一個很好的比較，儘管我不會將其稱為關注點分離（這當然是應用程序程式和設計中的基本原則），因為這個術語通常與應用程序開發階段有關，我們目前發現自己處於理解數據並設計其邏輯結構的階段。

從我個人的經驗來看，我認為這個階段與將重要的事物置於其整個背景中有關，它與查看在特定感興趣的場景中相關的不同實體之間存在的關聯有關，然後在數據模型中描述這些東西。在您評論的特定案例中，該Address實體可能與其他實體有不同類型的連接，一種與 . Profile，另一種與Location.

而且，是的，當某些事情感覺不對或不自然時，這很可能表明人們需要付出更多努力才能理解相關數據。以這種方式，Address實體是我認為需要更多關注的事情之一，因為我認為 aProfile和 an之間的關係Address 可以通過Location實體來處理（由於每個Location必須至少有一個物理Address)，因此我們可以忽略ProfileAddress最新模型中描述的關聯實體，但您應該繼續分析這些要點並讓我知道您的想法。

此外，IDEF1X 中的常見做法是更改實體中的 PK/FK 表示以提高可讀性嗎？

$$ e.g ProfileId - LocationOwnerProfileId $$?

是的，這是您的一個非常聰明的評論，因為 IDEF1X 建議使用角色名稱來命名 FOREIGN KEYS，以便根據使用它的實體來擷取這些屬性的含義。還值得注意的是，這也與主鍵遷移的概念密切相關。事實上，角色名稱的使用早於 IDEF1X，因為它最初是由 EF Codd 博士在其 1970 年的開創性文本中提出的。通過這種方式，可以清楚地看到 IDEF1X 標準對關係模型的保真度。

我很想知道在解決方案中/在解決方案中您不特別喜歡/覺得它沒有建模的東西？

除了上面已經描述的關於Address實體的詳細資訊外，我不確定特定中Roles給定Profile的 a執行的Location是否等同於 anOrganization或 an Person。從我的角度來看，aPerson首先需要與 an 相關聯Organization，然後 thisOrganization會指定Person執行 aRole在特定Location中，但是您更了解場景，因此此規則可能是不必要的。在這方面，我將堅持這樣一個事實，即了解該資料結構的未來使用者對、和的上下文描述或含義對我很有幫助Organization``Profile``Location，但我知道這可能被視為機密資訊，因此這是一個限制。

使用目前的結構，似乎每個人（Organization或Person）都可以與任何人（再次，Organization或Person）相關，並且可以在任何地方（）做/做任何事情（Role）Location但是，perharps，這正是您和使用者對這個數據庫的期望，當然，您將為此提供明確定義的約束。如果是這種情況，那麼我們幾乎提供了最終解決方案。既然你的意見在這種情況下自然是決定性的，你也應該分析這些想法，然後讓我知道你的結論，以便我們採取最後的步驟。

可行的二次推進

不幸的是，幾週前溝通停止了，我猜是因為你必須滿足的工作承諾，這是完全合理的。如果我們開發了一個更穩定和健壯的模型，我會更加滿意，但是由於我們之前的互動，我可以假設我已經能夠為您指出正確的方向。

除了這個問答過程中已經提出的內容之外，我認為從以前的數據模型中提供新的進展可能對其他有類似問題的尋求者有所幫助。所以，我創造了……

組織和概況初步數據模型——第二次進展

從這樣的數據模型中可以看出，我已經刪除了我在前面模型中描述的和之間的多對多關係，因為給定已經通過其擁有的 與一對多相關。Profile``Address``Profile Addresses``Locations

這一新進展中說明的另一個變化是，它現在包括給定對象Location可以由一對多 Profiles擁有的可能性。因此，我更改了LocationPRIMARY KEY（通過解除LocationOwnerProfileId屬性），然後添加了一個關聯實體（多對多）Profile與Location.

筆記

1. IDEF1X是一種高度推薦的數據建模技術，於1993 年 12 月被美國國家標準與技術研究院 ( NIST ) 定義為****標準。

2. 這是**（超）類型-子類型群的出現。如果您有興趣，這裡有一個答案**，我在其中更詳細地處理了這種關係。

3. 一個多對多層次關係的例子，非常類似於最終解決**“零件開發問題”的結構。當然，這種解決方案是由Edgar Frank Codd 博士在其 1970 年極具影響力的論文“大型共享數據庫的數據關係模型”中提出的**。

4.因此，這是一對多（或多對一）層次關係的實例。

引用自：https://dba.stackexchange.com/questions/105195