在我的第一个 ER 图上需要帮助

Question

我刚刚开始了我的第一个在线数据库课程，我有一个家庭作业，从规范列表中创建实体关系图 (ERD)。

规格如下：

1. 公司按部门组织。每个部门都有一个名称、一个唯一编号和管理该部门的特定员工。我们跟踪员工开始管理部门的开始日期。一个部门可能有多个位置。

2. 一个部门控制多个项目，每个项目都有一个名称、唯一编号和一个位置。

3. 我们存储每个员工的姓名、SSN、地址、薪水、性别和 DOB。一名员工被分配到一个部门，但可能从事多个项目，这些项目不一定受同一部门控制。我们会跟踪员工每周为每个项目工作的小时数。我们还跟踪每位员工的直接主管。

4. 为了保险起见，我们希望跟踪每个员工的家属。我们保留每个受抚养人的姓名性别、出生日期以及与员工的关系。

Answer 1

对于您的第一个数据库课程和第一次尝试 ER 图表 (ERD)，我认为您做得很好！我想在我用来分解一组要求（如您所给的要求）并创建草图的过程中向您提供一些反馈。希望通过采用这种方法，我将帮助您发展 ER 建模和数据库设计的技能，而不仅仅是给您一个家庭作业的答案。

查找实体和关系

ERD 背后的想法是确定实体（对业务具有根本重要性的事物）以及它们之间的关系。因此名称实体关系图。此时的目标不是设计或实现数据库，而是对数据库最终将基于的兴趣领域进行更结构化的理解。开始查找实体的一个好方法是查找需求中的名词，然后挑选出那些是人、地点、事物、概念或事件的名词。然后，您可以通过查找连接这些名词的动词来找到大部分关系。这是我在提供的要求中查找实体和关系的第一遍：

我用亮绿色突出显示名词，用亮粉色突出显示动词。现在请注意有一个名词 - 主管 - 以深绿色突出显示。我们暂时忽略它。将我发现的内容与您放置在 ERD 上的内容进行比较，我们在同一页面上！唯一的区别是我还突出显示了location。我可以理解为什么这被排除在您的 ERD 之外，因为它显然不是一个实体。您可以很容易地将其视为部门和项目的属性- 这是一个实体类型中的所有实体共享的公共属性或特征，这就是您对其进行建模的方式。我将其提升为实体类型的原因是：

一个部门可能有多个位置

这表明每个部门都将与一个或多个位置相关联，因此需要将其分解为自己的实体类型。提升它的第二个原因是我们可以将位置视为一个地方，因此将具有自己的属性，例如名称、地址、城市、州、邮政编码等。提升它的第三个原因是该位置被多个实体类型引用 - 部门和项目。如果您发现有问题的元素被多个已识别的实体引用，您应该将其视为一个与其他实体相关的实体，而不仅仅是一个属性其他人。然而，这没有科学依据——这纯粹是一种判断。这就是为什么 ER 图表处于概念级别，因为它对个人观点具有主观性。一个人的实体是另一个人的属性，这取决于他们对感兴趣领域的看法。

关于关系，这里是我用粉红色突出显示的列表：

1. 员工管理部门
2. 部门控制项目
3. 分配到部门的员工
4. 员工在项目上工作
5. 员工有依赖

其中，您确定了除第一个之外的所有内容。这与我之前提到的主管一起，进入了我们将推迟到稍后讨论的角色的讨论。现在我们只是试图确定基本面，我想说你是对的。

关联实体

看看我们有几个多对多的关系。要求规定一名员工可以从事多个项目，这些项目不一定由同一部门控制。鉴于大多数项目有多个成员，我们可以安全地假设这是一种多对多关系。当您在 ERD 上有这样的关系时，显示多对多关系线是完全可以接受的。如果我根本不显示属性，我通常只使用多对多关系。由于我们在这里展示它们，我更喜欢用关联实体解决多对多关系。即使现在没有实体的属性，随着分析的进行，我们也可能会发现一些属性。但是，在员工和项目的情况下，我们有属性- 工作时间 - 必须为该关系添加，因此必须通过创建关联实体来显示它们来解决。因此，我们将创建一个名为Project Assignment的关联实体。但我们还没有完成。该要求要求我们知道每周的工作时间。当您考虑它时，您会意识到项目的生命周期会有很多周，我们需要记录该员工每周在该项目上的工作时间。因此需要另一种实体类型，我称之为“工作时间”，其中每个项目分配都会出现很多次。此实体类型将保存周结束日期和工作小时数。

接下来，通过创建位置实体类型，声明一个部门可能有多个位置的要求意味着我们现在有了一个部门可以有多个位置的关系。也可以安全地假设一个地点将有许多部门在那里运作。因此，我添加了另一个名为Operating Site 的关联实体来展示这一点。

查找属性

这些属性在要求中非常清楚地列出，如下所示：

1. 每个部门都有一个名称，一个唯一的编号，
2. 跟踪员工开始管理部门的开始日期
3. 项目，每个项目都有一个名称、唯一编号、
4. 存储每个员工的姓名、SSN、地址、工资、性别和出生日期。
5. 跟踪员工每周为每个项目工作的小时数。
6. 保留每个受抚养人的名字性别、出生日期以及与雇员的关系。

在这一点上，我要做的是列出识别的实体和关系，并放置用它所属的实体类型识别的属性：

1. 部门- 编号、姓名
2. 员工- 姓名、SSN、地址、薪水、性别、出生日期
3. 位置- ???
4. 项目- 编号、名称
5. 受抚养人- 名字、性别、出生日期、亲属关系

注意我找不到任何位置属性。这将是一个危险信号，需要返回业务以获取有关位置的一些其他信息！

然后列出关系及其属性：

1. 员工管理部门 - 开始日期
2. 部门控制项目-
3. 分配到部门的员工-
4. 员工在项目上工作 - 每周工作时间
5. 员工有依赖 -
6. 部门有位置 -

对于最后两个关系，动词所具有的描述性不是很强，但这就是要求的措辞方式。实体有一个属性，那么为什么这些不是属性呢？我之前讨论过为什么我会选择将位置作为实体类型。对于受抚养人，选择更加明确，因为每个员工都有许多受抚养人，因此必须将其分解为自己的实体。一旦完成，我们就可以飞跃改进动词。也许像员工照顾家属和部门在当地运营之类的东西。

现在我们可以创建图表了。这是我所拥有的：

这是使用Oracle SQL Developer Data Modeler创建的- 免费下载 - 如果您想继续进行数据库设计和创建过程，这是一个很好的工具。

主键

您已确定主键。从技术上讲，ERD 甚至不需要您考虑密钥。如果您将 ERD 视为对业务建模的工具，那么此时确定您将如何唯一标识每个实体的出现并不重要。相反，您可以假设稍后您会解决这个问题，而只关注实体、它们的关系和它们的属性。最好注意哪些属性是每个实体都是唯一的，因为这将有助于选择密钥。完成图表并使用业务对其进行迭代后，您可以返回并通过选择正确的键来完成它。在我的图中，我只注意到需求中提到的两个唯一数字在图中使用属性名称旁边的 U 是唯一的。

实体角色

现在解决我之前提到的深绿色突出显示的主管。要求规定“一个部门有一个员工来管理这个部门”。他们接着说：“我们还跟踪每位员工的直接主管。” 所以我们这里有一个实体——一个人——扮演不同的角色。员工可能是经理。该员工可能是主管。那么我们如何解决这个问题呢？首先，我们需要判断manager和supervisor是不是同一个东西！是不是一个部门的经理也是分配给它的员工的主管？如果是，解决方案很简单。一种名为的新实体类型分配的经理可以创建为具有从部门到它以及从员工到它的一对多关系，具有该员工开始管理该部门的开始日期的单个属性。然后，每个员工的主管被假定为他们分配到的部门的经理。如果不是，那么我们可以添加一个从员工到员工的递归关系来代表主管和员工。这是最简单的方法，但确实在同一实体类型中引入了角色的混合。更好的方法是添加一个名为“分配的主管”的新实体类型从员工到它有两个一对多的关系 - 一个代表主管，另一个代表被监督。如果有分配开始和结束的日期，也可以添加。

结论

希望这与用于开发它的流程的描述相结合，将成为一个很好的学习工具，让您了解如何从业务流程的描述到 ERD 草案。我说草稿是因为它只是一个起点。一旦完成，它就可以作为一种沟通工具，在任何编程甚至系统设计开始之前验证需求、发现其中的漏洞、发现新的漏洞等等。请记住，在构建实现​​被误解的需求的系统方面做得很好将是失败的，并且修改 ERD 比修改工作系统要便宜得多！

参考

ER 图表的两个非常好的参考资料是 Steve Hoberman 的Data Modeling Made Simple，这是一个很好的概述，以及 David Hay 的Enterprise Model Patterns，它对您在分析组织时发现的常见模式提供了深入的了解。这两个参考文献都提供了更多关于使用动词和介词短语、识别和非识别关系以及强实体和弱实体来描述关系的详细信息——我没有提到的概念。Fabian Pascal 的实用数据库基础系列也很出色，并且有一篇很棒的首篇论文，这是对书籍的完美赞美，因为 Fabian 描述了确定数据需求的整个过程。请记住，ER 图只能显示键和引用，而实际上在最终数据库中可以探索和实现更多种类的业务规则。

Answer 2

本着学习的精神，由于这是家庭作业，我将给您一些反馈，但不会给您图表。我还将使用一些 SqlServer 特定术语，但您应该能够通过最少的研究明白我在说什么。

我立即注意到的一件事是你使用 SSN 作为 PK。我知道这似乎是一个好主意，因为理论上它是一些独特的个人身份信息。不幸的是，如果您允许的话，世界上有一些坏人会滥用您数据库中的数据。因此，我们不想将有价值的信息存储为纯文本。因此，您需要告知 SSN 已加密。另一件事是您经常在另一个表中使用 PK 作为 FK。我们不想将敏感数据散布在整个表中，即使数据已加密。

这引出了我的下一条一般性建议。我会使用IDENTITYorGUID作为你的Employee/Dependant表的 PK。您可以在此处和此处查看有关权衡的讨论。我个人倾向于支持IDENTITY专栏，但也有很多人出于很多充分的理由不同意这一点。

另外，您似乎还没有计算每个项目每周的时间。就目前情况而言，Employee有Employee Weekly Hours. 他们需要为每个项目分配几个小时。

最后，列名WeeklyHoursorweekly_hours对每个人来说都比 好得多Weekly Hours，因为空格需要转义名称，而不会获得真正的可读性。也不需要将表名添加到列名前面，即EmployeeSalary坏、Salary好。以类似的方式，情况DependentSex会更糟，IsMale除非您想要更具包容性的性别/性别选项，在这种情况下，您需要一张包含选项的表格。