为实习生实施数据库的ER图

Question

我编辑并重新制作了ERD。我还有一些问题。

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

问题：

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

2. 对于部分：＆＃34;对于我们想要存储的每个受训者（如果有的话），以及他们工作的以前的公司（雇主），雇佣期限：开始日期和结束日期。＆＃34;

Isn＆＃t; t＆＃34;就业期间：开始日期，结束日期＆＃34;一个组合属性？因为日期用符号＆＃34;显示：＆＃34;另外我相信我没有为＆＃34;他们工作的地方＆＃34; 创建一个属性？

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

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

2. 此ERD中是否存在多值属性？工资和工作是否属于多元化属性，因为雇主有很多工资和工作。

3. 我相信我正确地参与了约束（有一个）和基数约束。但是有些句子例如＆＃34;教练至少教授一门课程。每门课程只由一名教师讲授＆＃34 ;;当我没有课程与教师之间的关系时，我该如何为此写出基数约束？

4. 我的关系名称是否有意义，因为我所看到的只是＆＃34;有＆＃34;也许我没有正确地命名关系的行为？另外我认为时间表取决于实际的实体，因此它们是弱实体....所以这使得课程实体设置也是一个弱实体（我没有在这里将其标记为弱）？

5. 对于公司地址我放了一个组合属性，街道号，街道地址，城市......这是正确的吗？街道号码和街道地址也是主键吗？

6. 我还在课程中添加了最终标记属性，而course_schedule是在正确的实体集中吗？该属性的声明为＆＃34;每位受训者通过以下方式识别：唯一代码，社会安全号码，姓名，地址，唯一电话号码，所参加的课程以及每门课程的最终分数。 ＃34;

7. 对于这部分：＆＃34;我们在网站上存储了所有可用的教室＆＃34;如何制作包含网站信息的合成属性？



问题信息：

实习生可能是自雇人士或公司员工

每位受训者： 唯一代码，社会安全号码，姓名，地址，独特 电话号码，参加的课程和每门课程的最终分数。

如果受训者是公司的员工：存储当前公司（雇主），请开始日期。

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

如果受训者是自雇人士：存储专业领域和职称。

对于为公司工作的实习生：我们存储工资和工作

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

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

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

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

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

教室的特点是建筑物名称和房间号以及最大地点数。

至少在课堂上开设课程，可以在许多教室安排。

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

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

对于每位教师，我们将存储：社会安全号码，姓名和出生日期。

教练至少教授一门课程。

每门课程只由一名教师授课。

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

受训人员可以是针对特定人员的一个或多个受训人员的辅导员 一段时间（开始日期和结束日期）。

对于受训者而言，并非强制要求辅导员，但必须有导师

Answer 1

1. 属性'Code'将是您的PK，因为它的唯一用途似乎是唯一标识符。
2. 关系'是'会起作用，但是对这样的两个表的引用可能会变得混乱。您也可以参考＆＃34;雇主＆＃34;在实习表中这不是一个好习惯。他们应该真的结合起来。请参阅我的有用提示部分，了解如何清理它。
3. 如您的详细信息所示，公司看起来像是该地区公司的完整表格。这意味着表是相当静态的，并在其他表中用作引用。这意味着Employed中的“雇主”属性只是对公司中特定公司的PK的外键引用。你应该在这两者之间建立关系。
4. 好像当雇员“受雇”时，他们要么是公司的雇员，要么是自雇人士。
5. 公司的地址字段将是您当前城市的唯一地址，是的，因为问题表明该表是该城市公司的完整列表。但是，由于这是一个独特的属性，因此您必须具有街道地址等详细信息，因为只需添加城市名称即表示所有公司将拥有在唯一字段中禁止的相同地址。

其他一些有用的提示：

不要在图表上添加复数字段。当您有一个复数字段时，通常意味着您需要一个单独的表，其中包含对该表的外键引用。例如，在您的表培训生中，您有“雇主”。这应该是一个Employer表，其中包含对Trainee Code属性的外键引用。在雇主表中，您可以组合自雇人员和雇员表，以便从实习生到雇主有一个单一的参考。

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

跟进问题：

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

2. 是的，您不需要存储periods_of_employment，因为您可以使用开始日期和结束日期派生该信息。在他们工作的地方，我相信只是想说以前的雇主，所以没有位置，而是意味着你应该能够获得受训者所有雇主的清单。如果您在雇主表中查询受训人员代码等于请求受训人员的所有记录并按开始日期排序，则可以使用当前模式获取该模式。它两次声明start_date的原因是让你知道，对于所有“以前的”雇主，记录将有一个开始和结束日期。因此以前。但是，对于现在的雇主来说，就业还没有结束，这意味着没有end_date所以它将无效。这就是我认为问题所在。

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

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

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

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

7. 是的，您可以将地址设为复合属性，这将在您的图表中正确。要明确使用主键，只是因为属性是唯一的，不会使它成为主键。一个表只能有一个主键，因此您必须选择一个您确定不会重复的列。在这个例子中，您可能认为街道号码可能是唯一的，但如果一家公司留下一个地址而另一家公司进入那个地点会怎么样。这将破坏表的主键。通常，公司名称在城市或州获得许可，因此不能重复。这对您的主键来说是更好的选择。您也可以制作复合主键，但这是一个更高级的主题，我建议您稍后阅读。

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

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