标签: erd

我有以下五个表：

• 产品
• 特征
• 供应商
• 供应商_产品
• PROVIDER_FEATURE

逻辑如下：

泛型PRODUCT可以有一个或多个FEATUREs。有不同的PROVIDERs 提供相同的产品，但具有不同的细节，同样的FEATUREs，也具有不同的细节。

问题是，使用这个 ERD，我可以创建一个PRODUCT带有FEATUREf1的p1和一个PRODUCT带有FEATUREf2的p2 。然后我创建PROVIDERpv1。现在我可以PROVIDER_PRODUCT用PROVIDERpv1 和PRODUCTp1创建一个pvp1 。但是当我创建一个PROVIDER_FEATUREpvp1 时，我应该只被允许添加FEATUREf1，因为这是FEATURE通过PROVIDER_PRODUCT表链接到 p1 的那个。但是我也可以添加一个FEATUREf2。

如何创建一个约束防止进入用户PROVIDER_FEATURE即是其中一部分FEATURE即是其中一部分PRODUCT，但事实并非PRODUCT对PROVIDER_PRODUCT是对PROVIDER_FEATURE？我需要在存储过程中解决这个问题，还是有更优雅的方法来强制执行？

+-------------------+       +--------------------+
|                   |       |                    |
| PRODUCT           +-----> | FEATURE            |
|                   |       |                    | …

当我在网上搜索“ER 图”和“数据库模式”时，找到了这 3 种图类型，但它们都被称为“ER 图”。我想知道：

• 什么是数据库架构图，什么是 ER 图？
• 为什么都命名为“ER图”？

抱歉，如果这不是常态，但我正在寻求有关“狗救援/领养”数据库设计的建议。

我已经完成了规范化研究，这是我第一次尝试数据库设计。任何提示/反馈/批评？

最棘手的部分是处理狗/用户/组织并代表谁拥有狗。

1. 一只狗可以属于一个组织。一个组织可以有多个组织用户。想想动物收容所/磅

2. 狗可以属于组织用户。想想一个人的乐队，他们拥有一次容纳多只狗的大房子

3. 狗可以属于单个用户，不隶属于任何组织。认为有人搬到海外，他们需要为他们的狗找一个新主人

因此，dog 表必须附有组织 ID 或用户 ID，或两者兼有。也许是一个触发器，说明一个人必须不为空。

TLDR；以下场景的最佳设计选择是什么，每个设计在极大数据量下会如何反应？

我有使用大型政府数据库系统服务 24/7 数据收集、处理和报告的经验。浏览所有不同设计的模式并了解所有这些不同的人设计的所有这些功能如何以某种方式混杂成一个有效的解决方案是很有趣的。就像我相信你们中的一些人知道的那样，有趣的戳时间是一种奢侈，而且大多数周期都是务实的，让系统保持活力而不是改进设计。

我一直在建模一个新的数据库系统，并想对如何关联这些实体有一些想法。

场景：客户、雇主和从业者需要电话号码。

我们有四个实体：

• CLIENT
• EMPLOYER
• PRACTITIONER
• PHONE

电话号码按用于接听电话的技术进行分类，所使用的技术通知数据格式限制。

• 座机
• 传真
• 移动的

描述字段指示电话的主要用途；家庭、工作等。

关联这些实体的方法

1. 反规范化PHONE为CLIENT, EMPLOYER,PRACTITIONER

让我们从糟糕的设计开始，然后从那里开始。去规范化所有的电话号码！

• 3 个实体，没有关系
• 如果需要新电话号码，则必须创建新列；导致CLIENT.Phone1Number, EMPLOYER.Phone2Type, PRACTITIONER.Phone3Description;
• 或限制可以为每个实体输入的电话号码数量
• 冗余，大量开销
• 进行批量更新或维护会变得乏味

结论：select * from 'no_thanks';

2.建造第n座桥；重命名数据库匹兹堡

对于可以关联电话号码的每个实体，创建一个桥实体将它们组合在一起。

• 7 个实体，6 个关系
• 数据冗余；电话号码填充在多个位置
• 仅PhoneNumber在需要时可以使用桥接表；不需要 JOIN 即可PHONE
• 如果新实体FAMILYMEMBER需要电话号码，则必须创建新的桥接表

结论：也许，取决于维持关系的难度

3. 一个准“星图”

修改PHONE以包含CLIENT.ClientID, EMPLOYER.EmployerID, 的外键 …

业务领域描述

• 每个客户都有一个姓名、一个永久地址和一个社会安全号码。
• 每个客户可以有多个电话号码，同一个电话号码可能被多个客户共享。
• 一个客户可以拥有多个账户，但每个账户由一个客户拥有。
• 每个账户都有账号、类型（如储蓄、支票等）和余额
• 银行为每个账户出具对账单，并每月邮寄给账户所有人。随着时间的推移，同一个账户会出现多张报表。
• 每个报表都有一个发布日期和一个报表 ID。同一个账户的所有报表都有不同的报表 ID，但两个不同的帐户可以有具有相同报表 ID 的报表。例如，账户 A 可能有一个 ID 为“123”的报表，而账户 B 有另一个 ID 为“123”的报表。

我的实体关系表示

我绘制了以下实体关系图 (ERD) 来表示该场景：

问题

1. 是否可以在任何关系的情况下使用 Min-Max 表示法，或者仅在说明中有指示时使用？

2. 我的多对多关系在这里描绘得正确吗？

3. 我能否正确描述 Account vs Account Statement vs StatementID 之间的关系？

4. 根据我的假设，Account Statement 真的是一个弱实体Has吗？真的是一个依赖于 Statement ID 的弱关系吗？发行日期是弱键吗？

我正在研究一个 ERD，它表示Web 开发公司行为模型中实体之间的关系。在那里我有这样的实体：

1. 顾客
2. 服务 -----------（如：网页开发、网页设计、网页咨询、...）
3. 订单项 -------（如：网页开发、网页设计、网页咨询等）
4. 命令
5. 发票
6. 项目
7. 项目阶段
8. 任务 ---------------（如：网页开发任务 3、网页设计任务 7）
9. 开发商
10. 交付 -----------（例如：开发的网络应用程序、网络咨询会议、...）

到目前为止，我有这张图，但我知道它仍然存在重大问题，这只是一个起点：

主要概念

• 客户在order-items 上生成services，组合形成与order相关的invoice。
• 每个project都有多个project-phases，每个都project-phase与一个 相关order。
• 每个project-phase都有多个tasks，每个都分配给一个developer。
• 每个project-phase都有一个delivery，将在相关orders付款后交付invoice。

问题

1. 是has和contains完全一样的吗？如果不是，如何在他们之间选择关系？！什么措施？！
2. 主要概念部分是否有任何合理的问题？
3. 任何有用的想法或建议来改进这个模型？

对此有任何帮助，将不胜感激。

更新 1

精制版图

更新 2

考虑一个快餐店的类比会有所帮助：

1. 客户 ---------- 饥饿的人 …