ER 建模 - 子类关系和关系实体
ER Modelling - Subclass relationships & Relationship Entities
我有几个关于 ER 建模的具体问题。
为了提供一些具体的背景，这是一个大学项目，我似乎无法找到这些问题的具体答案。
背景
- ER 模型描述了一家会计师事务所的小型数据库，供他们管理客户、审计工作（年度工作）、这些工作的时间和费用以及其他一些小细节。点点滴滴很傻（比如个人助理打字速度，但是项目要求）
- 每个客户每年必须完成 1 次审计，并且该审计由 1 名或多名在会计师事务所工作的员工完成
- 客户端（和审计作业）由经理管理。每个客户只有一个经理管理他们，每个经理可以管理多个客户
- 当工作人员进行审计时，他们会为审计计费时间。审计费用的计算方法是他们的收费率乘以审计费用的总小时数
- 每位员工为 1 个且仅 1 个团队工作。一个团队有 1 名或多名工作人员在其中工作。
- 合伙人是员工超类的子类，具有唯一的 rca 编号来识别他们（会计术语）。每个合伙人带领一个团队，每个团队只有一个合伙人
- 每个合伙人都有一个私人助理，每个私人助理只为一个合伙人工作
ER模型
Audit Time & Fee ER Model
问题
Partner 和 Personal Assistant 都是子类实体，根据我的图表，存在强制的 1..1 关系。是不是"legal"子类之间有特定的关系？
我为 Staff 的子类使用了一个可选的或关系，我认为这很好，因为一个工作人员不能同时担任任何角色。作为子类唯一省略的角色是 "auditor"。如果我要包括这个，"optional, or" 是否会更改为 "mandatory, or"，因为显示了所有可能的选项，并且工作人员必须是这 4 个角色之一？
在 Annual_audit 和 Staff 之间，我有一个关系实体（我可能会说这是错误的）。这是显示关系的正确方法吗？我也尝试过使用三元关系，但最终来回走了好几次。
欢迎任何一般性反馈或指出错误
非常感谢任何人能够提供的帮助。
Partner and Personal Assistant are both subclass entities and per my diagram there is a mandatory 1..1 relationship. Is it "legal" to have a specific relationship between subclasses?
子类型 and/or 超类型之间的关系是完全有效的。
I have used an optional, or relationship for the subclasses of Staff, which I think is fine as a staff member cannot be any of the roles at the same time. The only omitted role as a subclass is that of "auditor". If I were to include this, would "optional, or" change to "mandatory, or", as all possible options are shown and the staff member must be one of those 4 roles?
听起来不错。我宁愿使用 "disjoint" 而不是 "or".
Between Annual_audit and Staff I have a relationship entity (I could be calling this something wrong there). Is this the correct way to show the relationship? I tried using a ternary relationship as well, but ended up going backwards and forwards several times.
ER 模型中没有 "relationship entity" 这样的东西。您可能会想到网络数据模型中用于分解多对多关系的关联实体。 ER 模型直接支持多对多关系，为此不需要关联实体，尽管它们在将关系从属于其他关系方面仍有一席之地。
Annual_audit 在你的图中是一个弱实体关系。 Staff 是正则实体关系。他们之间是Charges time，是多对多的关系。如果您了解这些概念，则该符号具有足够的可读性。不过，陈的符号会更清楚地表示概念，而看起来像 table 模式的图表更适合物理模型。
图表的一个问题是箭头。它们与基数指示符不一致。它们的基数指示符看起来是正确的，但箭头大多没有指向有意义的方向。我会删除它们，除了从子类型指向 Staff.
的那个
最后，我建议您不要混用 OOP 和数据建模的概念和术语。数据建模用于表示知识，OOP 用于建模系统。 "subtyping" 用于 subtypes/subsets 实体集，"subclassing" 用于编程上下文中的派生 类。
我有几个关于 ER 建模的具体问题。
为了提供一些具体的背景，这是一个大学项目，我似乎无法找到这些问题的具体答案。
背景
- ER 模型描述了一家会计师事务所的小型数据库，供他们管理客户、审计工作（年度工作）、这些工作的时间和费用以及其他一些小细节。点点滴滴很傻（比如个人助理打字速度，但是项目要求）
- 每个客户每年必须完成 1 次审计，并且该审计由 1 名或多名在会计师事务所工作的员工完成
- 客户端（和审计作业）由经理管理。每个客户只有一个经理管理他们，每个经理可以管理多个客户
- 当工作人员进行审计时，他们会为审计计费时间。审计费用的计算方法是他们的收费率乘以审计费用的总小时数
- 每位员工为 1 个且仅 1 个团队工作。一个团队有 1 名或多名工作人员在其中工作。
- 合伙人是员工超类的子类，具有唯一的 rca 编号来识别他们（会计术语）。每个合伙人带领一个团队，每个团队只有一个合伙人
- 每个合伙人都有一个私人助理，每个私人助理只为一个合伙人工作
ER模型
Audit Time & Fee ER Model
问题
Partner 和 Personal Assistant 都是子类实体，根据我的图表，存在强制的 1..1 关系。是不是"legal"子类之间有特定的关系？
我为 Staff 的子类使用了一个可选的或关系，我认为这很好，因为一个工作人员不能同时担任任何角色。作为子类唯一省略的角色是 "auditor"。如果我要包括这个，"optional, or" 是否会更改为 "mandatory, or"，因为显示了所有可能的选项，并且工作人员必须是这 4 个角色之一？
在 Annual_audit 和 Staff 之间，我有一个关系实体（我可能会说这是错误的）。这是显示关系的正确方法吗？我也尝试过使用三元关系，但最终来回走了好几次。
欢迎任何一般性反馈或指出错误
非常感谢任何人能够提供的帮助。
Partner and Personal Assistant are both subclass entities and per my diagram there is a mandatory 1..1 relationship. Is it "legal" to have a specific relationship between subclasses?
子类型 and/or 超类型之间的关系是完全有效的。
I have used an optional, or relationship for the subclasses of Staff, which I think is fine as a staff member cannot be any of the roles at the same time. The only omitted role as a subclass is that of "auditor". If I were to include this, would "optional, or" change to "mandatory, or", as all possible options are shown and the staff member must be one of those 4 roles?
听起来不错。我宁愿使用 "disjoint" 而不是 "or".
Between Annual_audit and Staff I have a relationship entity (I could be calling this something wrong there). Is this the correct way to show the relationship? I tried using a ternary relationship as well, but ended up going backwards and forwards several times.
ER 模型中没有 "relationship entity" 这样的东西。您可能会想到网络数据模型中用于分解多对多关系的关联实体。 ER 模型直接支持多对多关系，为此不需要关联实体，尽管它们在将关系从属于其他关系方面仍有一席之地。
Annual_audit 在你的图中是一个弱实体关系。 Staff 是正则实体关系。他们之间是Charges time，是多对多的关系。如果您了解这些概念，则该符号具有足够的可读性。不过，陈的符号会更清楚地表示概念，而看起来像 table 模式的图表更适合物理模型。
图表的一个问题是箭头。它们与基数指示符不一致。它们的基数指示符看起来是正确的，但箭头大多没有指向有意义的方向。我会删除它们，除了从子类型指向 Staff.
最后，我建议您不要混用 OOP 和数据建模的概念和术语。数据建模用于表示知识，OOP 用于建模系统。 "subtyping" 用于 subtypes/subsets 实体集，"subclassing" 用于编程上下文中的派生 类。