Web 开发公司的 ERD
Pmp*_*mpr 5 schema erd database-design database-diagrams
我正在研究一个 ERD，它表示Web 开发公司行为模型中实体之间的关系。在那里我有这样的实体：
- 顾客
- 服务 -----------（如：网页开发、网页设计、网页咨询、...）
- 订单项 -------（如：网页开发、网页设计、网页咨询等）
- 命令
- 发票
- 项目
- 项目阶段
- 任务 ---------------（如：网页开发任务 3、网页设计任务 7）
- 开发商
- 交付 -----------（例如：开发的网络应用程序、网络咨询会议、...）
到目前为止，我有这张图，但我知道它仍然存在重大问题，这只是一个起点：
主要概念
- 客户在
order-items 上生成services，组合形成与order相关的invoice。 - 每个
project都有多个project-phases，每个都project-phase与一个 相关order。 - 每个
project-phase都有多个tasks，每个都分配给一个developer。 - 每个
project-phase都有一个delivery，将在相关orders付款后交付invoice。
问题
- 是
has和contains完全一样的吗？如果不是，如何在他们之间选择关系？！什么措施？！ - 主要概念部分是否有任何合理的问题？
- 任何有用的想法或建议来改进这个模型？
对此有任何帮助，将不胜感激。
更新 1
精制版图
更新 2
考虑一个快餐店的类比会有所帮助：
- 客户 ---------- 饥饿的人
- 服务 ------------- 制作汉堡、送货上门、手机送货、...
- Order-item --------- 一个汉堡，...
- 订购 ---------------- 一个送货上门的汉堡
- 发票 -------------- 打印的发票
- 项目 -------------- 为客户服务整整一年（如合同）
- 项目阶段-----服务客户一天
- 任务 ----------------- 准备厨房，加工肉，...
- 开发者 ---------- The cookie
- 送货 ------------- 一个用蜡纸包裹的汉堡和一个带托盘的饮料
更新 3
在您的图表中，项目似乎与客户无关。这是你的本意吗？
我认为Order和Project不应该相关，因为我认为这是场外的东西，客户与它无关。她/他只是在分娩后才关心时间和金钱，没有别的。请告诉我是否错了。
所有订单都是项目的一部分，还是您可以拥有根本不在项目中的订单？
所有订单都是项目的一部分，除了那些在流程队列中等待的新订单。
同样，您将订单项目直接与客户相关，但也与订单相关。订单是否在客户之间分配？
请把Order-Item想象成这些：
- 网页设计
- 网页设计咨询
- 域名咨询
- ...
因此，客户选择其中的一些项目，收集为具有发票并可支付的订单。Order-Item与提供的Service直接相关。我不明白您的意思是订单是否在客户之间拆分？.
如果不是，您不需要客户、订单项和服务之间的三元关系。相反，订单项目是订单和服务之间的交集。订单项目通过从订单（甚至项目？）
这在某种程度上是正确的：订单项目通过从 order 继承而属于客户，但我认为这样说更合理：
从Service继承的Order-Item属于Order，而Order本身属于Customer。
小智 3
你把关系过于简单化了。图中没有两个关系是相同的，因为它们不涉及相同的域。 <ORDER> has <ORDER-ITEM>不等于<PROJECT> has <PROJECT-PHASE>。它们可能都是单射的，但这不足以称它们相同。
尝试给你的亲戚起一个更具描述性的名字。虽然属性（又名一对一二元关系）倾向于聚合在一个共同的决定因素上以创建“实体表”，但多值属性和更复杂的关系（例如 ,Customer和Service之间的三元关系Order-item）通常会独立成为表。 Makes确实没有正确描述关系或结果表。
我建议您在图表中添加基数指示符，并使用每个关系的谓词语句作为指导，为您的关系提供更具描述性的名称。
再想一想，只要您将它们与它们相关的实体集一起阅读，这些名称在概念设计中可能就很好。当您进行物理设计时，一对一和一对多关系可能会被实现为实体集之一的属性，因此关系名称不会影响物理设计。多对多关系和非二元关系将成为它们自己的表，对于表名，最坏的情况是您可以连接实体名称，例如CustomerServiceOrderItems。