为受训者实现数据库的 ER 图

Question

我编辑并重新制作了 ERD。我还有几个问题。

我包括参与约束（受训者和导师之间）、基数约束（M 表示许多）、弱实体（双线矩形）、弱关系（双线菱形）、组合属性、派生属性（带圆圈的空白区域） , 和主键。

问题：

1. 显然，为了减少冗余属性，我应该只保留主键和描述性属性，以及出于简单原因我将删除的其他属性。在这种情况下，哪些属性是多余的？我在想 start_date、end_date、电话号码和地址，但这取决于实体集对吗？例如，属性地址将从 Trainee 中删除，因为我们真的不需要它？

2. 对于部分：“对于每个实习生，我们希望存储（如果有的话）他们以前工作过的公司（雇主），雇佣期：开始日期和结束日期。”

“工作期间：开始日期，结束日期”不是一个组合属性吗？因为日期用符号“：”显示而且我相信我没有为“他们工作的地方”创建一个属性，即位置？

当我们已经有一个属性雇主和不同的开始日期时，如何显示以前的公司（雇主）？因为如果您查看问题信息，它会两次显示雇主的 start_date，第二次显示 start_date 和 end_date。

1. 我将许多属性标记为主键，但我如何区分派生属性、主键以及哪个属性是多余的？

2. 此 ERD 中是否有多值属性？工资和所从事的工作是否会是一个多值属性，因为雇主有很多工资和工作。

3. 我相信我正确地做了参与约束（有一个）和基数约束。但也有一些句子，例如“一名教师至少教授一门课程。每门课程仅由一名教师教授”；当我没有课程和讲师之间的关系时，如何为此编写基数约束？

4. 我的关系名称是否有意义，因为我看到的只是“有”，也许我没有正确命名关系的动作？另外我相信课程表取决于实际的实体，所以它们是弱实体......所以这是否使课程实体集也是一个弱实体（我在这里没有将其标记为弱实体）？

5. 对于公司地址，我输入了一个组合属性，街道编号、街道地址、城市……这样是否正确？街道编号和街道地址也是主键吗？

6. 我还为课程添加了 final mark 属性，而 course_schedule 是否在正确的实体集中？此属性的说明是“每位学员由以下各项标识：唯一代码、社会保险号、姓名、地址、唯一电话号码、参加的课程和每门课程的最终分数。”

7. 对于这部分：“我们将站点上所有可用的教室都存储在数据库中”我是否要创建一个包含站点信息的组合属性？

问题信息：

实习生可能是个体经营者或公司雇员

由确定的每位学员： 唯一代码、社会安全号码、姓名、地址、唯一 电话号码、参加的课程和每门课程的最终分数。

如果实习生是公司员工：存储当前公司（雇主）、开始日期。

对于每个受训者，我们还希望存储（如果有的话）他们以前工作的公司（雇主）的工作时间：开始日期和结束日期。

如果学员是个体经营者：存储专业领域和职位。

对于在公司工作的实习生：我们存储薪水和工作

对于每个公司（雇主）：名称（唯一的）、地址、唯一的电话号码。

我们将所有已知公司存储在数据库中 城市。

我们还需要代表每个学员正在参加的课程。

每门课程都有一个唯一的代码和标题。

对于我们必须存储的每门课程：开设课程的教室、日期和时间（开始时间和持续时间，以分钟为单位）。

教室的特点是建筑物名称和房间号以及最多可容纳的人数。

至少在一个教室里开设一门课程，并且可以安排在许多教室里。

我们在数据库中存储所有教室 可在网站上找到。

我们在数据库中存储公司至少提供一次的所有课程。

我们将为每位教师存储：社会保险号、姓名和出生日期。

一名讲师至少教授一门课程。

每门课程仅由一位讲师授课。

还必须存储所有讲师的电话号码（每位讲师至少有一个电话号码）。

一名学员可以是一名或多名学员的导师 时间段（开始日期和结束日期）。

对于实习生来说，不一定要当导师，但必须要有导师

Answer 1

1. 属性“代码”将是您的 PK，因为它似乎只用作唯一标识符。
2. 关系“是”可以工作，但引用两个这样的表可能会变得混乱。此外，您在实习生表中提到了“雇主”，这不是一个好的做法。他们真的应该结合起来。请参阅我的有用提示部分，了解如何清理它。
3. Company 看起来像您的详细信息所显示的该地区公司的完整表。这意味着表是相当静态的，并在您的其他表中用作参考。这意味着 Employed 中的属性“employer”只是对 Company 中特定公司的 PK 的外键引用。你应该画出这两者之间的关系。
4. 似乎当员工“受雇”时，他们要么是公司员工，要么是个体经营者。
5. 公司中的地址字段将是您当前城市的唯一地址，是的，因为问题表明该表是该城市公司的完整列表。但是，因为这是一个独特的属性，所以您必须具有街道地址等详细信息，因为简单地添加城市名称将意味着所有公司都将拥有相同的地址，这在唯一字段中是被禁止的。

其他一些有用的提示：

不要在图表中添加带有复数的字段。当您有复数字段时，通常意味着您需要一个单独的表，其中包含对该表的外键引用。例如，在您的 Table Trainee 中，您有“雇主”。那应该是一个雇主表，其中包含对实习生代码属性的外键引用。在 Employer 表中，您可以合并 Self-employed 和 Employed 表，以便有一个从 Trainee 到 Employer 的引用。

ERD Link http://www.imagesup.net/?di=1014217878605。这是我为您创建的快速 ERD。请注意使用链接器表来防止表中的多对多关系。重要的是要注意有几种方法可以解决这个模式问题，但这就像我看到你的问题一样。该设计旨在帮助规范化数据库。那是防止数据库中的冗余数据。希望这可以帮助。如果您需要对我提供的设计进行更多说明，请告诉我。与您的设计参数进行比较时，它应该是不言自明的。

后续问题：

1. 如果您希望减少可能是任意的属性，可能 phone_number 和 address 可能是要消除的属性，但在确定条目是当前记录还是过去记录时，开始和结束日期有利于排序和归档原因.

2. 是的，periods_of_employment 不需要存储，因为您可以通过开始和结束日期得出该信息。我相信他们工作的地方只是说以前的雇主，所以没有位置，而是意味着您应该能够获得实习生拥有的所有雇主的列表。如果您在雇主表中查询实习生代码等于请求的实习生并按开始日期排序的所有记录，则可以使用当前模式获得该信息。它两次声明 start_date 的原因是为了让您知道对于所有“以前的”雇主，该记录将有一个开始和结束日期。因此上一个。但是，对于当前雇主而言，就业尚未结束，这意味着不会有 end_date，因此它将为空。这就是我认为的问题所在。

3. 为了简单起见，PK 是用于引用另一个表中的记录的唯一值。冗余值是您在表中基本上不需要的值，因为可以通过查询另一个表来派生相同的值。在这种情况下，除了 Course 表中的 Final_Mark 之外，您的大多数属性都很好。这是多余的，因为 Course_Schedule 将存储收到的 Final_Mark。 Course 表旨在简单地保存 Course_Schedule 引用的所有潜在课程的列表。

4. 此设计中没有多值属性，因为这是不好的做法 工作和薪水是单数的，如果工作或薪水发生变化，您将向雇主表添加一条新记录，而不是添加到该列。多值属性使查询数据库变得困难，我建议不要这样做。这就是为什么我之前提到将所有具有复数的属性抽象到它们自己的表中并使用外键引用。

5. 您基本上确实已经写到这里了，因为 Course_Schedule 是一个链接器表，这意味着它旨在简化表之间的关系，因此您没有多对多的关系。

6. 你所有的关系在我看来都是正确的。此外，由于时间表是链接器表，没有支持表就无法存在，您可以将它们视为弱实体。此模式中的课程是所有可用课程的定义列表，因此可以独立于任何其他表。根据定义，这不是一个弱实体。创建此数据库时，您可能会填写课程表，之后它可能不会更改，除非在添加或删除可用课程选项时很少。

7. 是的，您可以将 address 设为复合属性，这在您的图表中是正确的。要清楚您对主键的使用，仅仅因为属性是唯一的并不能使其成为主键。一个表可以有一个且只有一个主键，因此您必须选择一个您确定不会重复的列。在此示例中，您可能认为门牌号可能是唯一的，但如果一家公司留下地址而另一家公司搬入该地点会怎样。那会破坏该表的主键。通常，公司名称在城市或州获得许可，因此不能重复。这将是您主键的更好选择。您也可以创建复合主键，但这是一个更高级的主题，我建议您稍后阅读。

8. 将 final_mark 从课程中删除。该表将仅包含课程行，这些课程不会链接到除 course_schedule 表之外的任何学员。 Final_Mark 应该只在该表中。如果您将 final_mark 添加到课程表中，那么如果您的课程中有 10 名学员，那么课程表中将有 10 个重复的行，只有不同的 final_marks。而是只保留 course_code 和标题，这样您就可以使用链接器表分配不同的讲师、学员和教室。

9. 使用此架构不需要复合属性。您有一个 Classroom 表，其中包含所有可用的教室及其相关信息。然后，您使用 Classroom_Schedule 链接器表将给定的教室分配给 Course_Schedule。 Classroom 的任何属性都不能分解为更简单的属性。