我一直堅持這個很長一段時間，嘗試了不同的設計，但總是有些東西關閉。我正在設計一個藝術學校/舞蹈或健身中心類的業務數據庫。 我只是試圖設計實體關係和信息。 假設我們有person類 - 包括以下類型的'學生'，'監護人'，'老師'。每個人可能不止一種類型。 未成年人會有監護人（家長，可能有多個）來保存聯繫信息，處理註冊等。一些成年人也可以有監護人（比如說老人或PWD），老師也可以是另一個班的學生/服務。多角色系統的數據建模幫助
我一直在打破我的頭如何設置（尤其是聯繫信息），而不會打破常規形式。我的最後一次嘗試是在下圖中。 我不知道在哪裏綁定聯繫信息，整個事情看起來不正確。
任何幫助/指導表示讚賞。
我覺得你在你的模型overabstracting。將您的不同角色作爲具體類型而不是一般來說，將允許您爲每個角色指定唯一的屬性，關係和約束。
考慮以下表圖：
我建模teacher和student爲person具體亞型。它們可以重疊，即一個人可以是兩種類型。錄製學生時，需要student_number。錄製教師時，錄製employee_number。我添加了這些屬性只是爲了表明特定於子類型的屬性。
Guardian被建模爲人與人之間的多對多關係。這可以創建遞歸關聯。根據你想如何使用監護人，這種關係可以進一步細化。
我在person上添加了聯繫信息。這意味着學生可以從他們的監護人獲得不同的聯繫信息，您可以選擇在查詢中使用什麼。一個限制是每個人只能有一個address,phone,mobile和email;你可以考慮支持多個。
一個class有一個名字和一個老師，有class和student之間的許多一對多的關係（student_class）。
要牢記的一個總體限制是該模型沒有解決時間問題。總而言之，像這樣的系統必須跟蹤每學期的課程，學期或年份，每年的學生註冊等。
難以解釋的原因是關係數據庫模型不能很好地支持繼承。它當然不支持多重繼承。
你可以在這個主題上找到許多關於SO的問題; this one是一個開始的好地方。
@ reaanb的答案是「每個子類一個表」的示例。這是一個很好的模型，併爲您提供了清晰的模式 - 但這意味着您的應用程序必須將「person」映射到所有可能的子類，然後獲取數據屬性。
總之 - 沒有乾淨的解決方案。儘可能保持一致，儘可能保持乾淨，但不要指望完美。
感謝您的輸入，非常感謝 –
關係模型不包括表繼承，但它也不排除它。 RM解決了邏輯建模問題，但繼承將適用於表的物理實現。它可能會在應用程序/查詢中節省一些工作量，但這會進一步加劇數據建模與面向對象編程的混合，所以我不確定這是否是一個好主意。對於數據庫繼承，我會比表繼承更興奮。 – reaanb
謝謝。我會嘗試並實施你的例子。是的，這只是模型的一小部分，我還沒有解決時間表，出勤和付款問題。 –