为实习生实现数据库的ER图
ER diagram that implements a database for trainee
我编辑并重新制作了 ERD。我还有几个问题。
我包括参与约束（受训者和导师之间）、基数约束（M 表示很多）、弱实体（双线矩形）、弱关系（双线菱形）、组合属性、派生属性（白色 space 带圆圈）和主键。
问题：
显然，为了减少冗余属性，我应该只保留主键和描述性属性，出于简单原因，我将删除其他属性。在这种情况下哪些属性是多余的？我在想 start_date、end_date、phone 号码和地址 但这取决于实体集吗？例如属性地址将从 Trainee 中删除，因为我们真的不需要它？
对于这部分：“对于每个学员，我们希望存储（如果有的话）他们以前工作过的公司（雇主），就业期：开始日期和结束日期."
“任职期间：开始日期、结束日期”不是组合属性吗？因为日期用符号“：”显示，而且我相信我没有为 “他们工作的地方” 设置属性，这是位置？
另外，当我们已经有雇主属性和不同的开始日期时，如何显示以前的公司（雇主）？因为如果您查看问题信息，它两次为雇主说明 start_date，第二次它说 start_date 和 end_date。
我将许多属性标记为主键，但如何区分派生属性、主键以及哪些属性是多余的？
这个ERD中是否有多值属性？薪水和所持有的工作是否会是一个多值属性，因为雇主有很多薪水和工作。
我相信我正确地执行了参与约束（有一个）和基数约束。但是有些句子例如“一位讲师至少教授一门课程。每门课程仅由一位讲师教授”；当我 没有 课程和讲师之间的关系时，如何为此编写基数约束？
我的关系名称是否有意义，因为我所看到的只是“有”，也许我没有正确命名关系的行为？此外，我认为时间表取决于实际实体，因此它们是弱实体....那么这是否会使课程实体集也成为弱实体（我在这里没有将其标记为弱实体）？
对于公司地址，我输入了一个组合属性、街道编号、街道地址、城市...这样对吗？街道编号和街道地址也可以作为主键吗？
我还向课程添加了 最终标记 属性，course_schedule 这是在正确的实体集中吗？此属性的声明是“每位学员通过以下方式识别：唯一代码、社会安全号码、姓名、地址、唯一电话phone 号码、参加的课程和每门课程的最终分数."
对于这部分：“我们将站点上所有可用的教室存储在数据库中”我是否制作包含站点信息的组合属性？
问题信息：
一个受训者可能是self-employed或公司的雇员
确定的每位学员：
唯一代码、社会安全号码、姓名、地址、唯一
电话phone号码、参加的课程和每门课程的最终分数。
如果实习生是某公司的雇员：存储当前公司（雇主），开始日期。
对于每个实习生，我们希望存储（如果有的话）他们之前工作的公司（雇主）、就业时间：开始日期和结束日期。
如果受训者是 self-employed：存储专业领域和头衔。
对于在公司工作的实习生：我们存储薪水和工作
对于每家公司（雇主）：名称（唯一）、地址、唯一电话phone号码。
我们将所有知名公司存储在数据库中
城市。
我们还需要代表每个学员参加的课程。
每门课程都有一个 唯一代码和一个标题。
对于每门课程，我们必须存储：课程的教室、日期和时间（开始时间和持续时间（以分钟为单位））。
一间教室的特征是楼名和房间号以及最大座位数
一门课程至少在一个教室，并且可以安排在许多教室。
我们在数据库中存储al教室
在网站上可用。
我们将在公司至少开设过一次的所有课程存储在数据库中。
对于每位讲师，我们将存储： 社会安全号码、姓名和出生日期。
一名讲师至少教授一门课程。
每门课程仅由一位讲师教授。
还必须存储所有讲师的电话phone号码（每个讲师至少有一个电话phone号码）。
一个学员可以是一个或多个学员的导师
时间段（开始日期和结束日期）。
实习生不一定要当导师，但一定要有导师
- “代码”属性将成为您的 PK，因为它的唯一用途似乎是唯一标识符。
- 关系“是”会起作用，但引用两个 table 这样的关系会变得混乱。另外，您在实习生 table 中提到了 "Employers"，这不是好的做法。他们真的应该结合起来。请参阅我的有用提示部分，了解如何清理它。
- 根据您的详细信息，公司看起来像是该地区的完整 table 家公司。这意味着 table 是相当静态的，并在您的其他 table 中用作参考。这意味着 Employed 中的属性“雇主”将只是对 Company 中特定公司 PK 的外键引用。你应该画出这两者之间的关系。
- 似乎当雇员被“雇用”时，他们要么是公司的雇员，要么是self-employed。
- Company 中的地址字段将是您当前所在城市的唯一地址，是的，正如问题所述，table 是该城市中公司的完整列表。然而，因为这是一个独特的属性，您必须具有街道地址等细节，因为简单地添加城市名称将意味着所有公司都将拥有相同的地址，而这在一个独特的字段中是被禁止的。
其他一些有用的提示：
远离将带有复数的字段添加到图表中。当你有一个复数字段时，它通常意味着你需要一个单独的 table 和一个指向 table 的外键引用。例如，在您的 Table 实习生中，您有“雇主”。那应该是一个 Employer table，它有一个指向 Trainee Code 属性的外键引用。在 Employer Table 中，您可以组合 Self-employed 和 Employed table 以便从 Trainee 到 Employer 有一个参考。
ERD Link http://www.imagesup.net/?di=1014217878605。这是我为您创建的快速 ERD。注意使用链接器 tables 来防止 table 中的多对多关系。重要的是要注意有几种方法可以解决这个模式问题，但这就像我看到你的问题一样。该设计旨在帮助数据库的规范化。那是防止数据库中的冗余数据。希望这可以帮助。如果您需要对我提供的设计进行更多说明，请告诉我。将您的设计参数与其进行比较时，它应该是相当不言自明的。
跟进问题：
如果您希望减少可能是任意的属性，也许 phone_number 和地址可能是要消除的属性，但是开始和结束日期对于确定是否是排序和归档原因很有用条目是当前或过去的记录。
是的，periods_of_employment 不需要存储，因为您可以通过开始和结束日期推导出该信息。我认为他们工作的地方只是说以前的雇主，所以没有位置，而是意味着您应该能够获得受训人员曾经拥有的所有雇主的列表。如果您查询雇主 table 以获取实习生代码等于请求的实习生并按开始日期排序的所有记录，则可以使用当前模式获得它。它两次声明 start_date 的原因是让您知道对于所有“以前的”雇主，该记录将有一个开始和结束日期。因此是前者。但是，对于当前雇主而言，雇佣关系尚未结束，这意味着将不会有 end_date，因此它将为空。我认为这就是问题所在。
为简单起见，PK 是用于在另一个 table 中引用记录的唯一值。冗余值是您在 table 中基本上不需要的值，因为可以通过查询另一个 table 来导出相同的值。在这种情况下，除了课程 table 中的 Final_Mark 之外，您的大部分属性都很好。这是多余的，因为 Course_Schedule 将存储收到的 Final_Mark。课程 table 旨在简单地保存要被 Course_Schedule 引用的所有潜在课程的列表。
此设计中没有多值属性，因为这是不好的做法 工作和薪水是单一的，如果工作或薪水发生变化，您将向雇主添加新记录 table 不是添加到该列。多值属性使查询数据库变得困难，我建议不要这样做。这就是为什么我之前提到将所有具有复数的属性抽象为它们自己的 table 并使用外键引用。
你基本上确实把它写在这里了，因为 Course_Schedule 是一个链接器 table 意味着它旨在简化 table 之间的关系，所以你不需要没有多对多关系。
我觉得你所有的关系都很合适。此外，由于调度是链接器 tables 并且没有支持 tables 就无法存在，因此您可以将它们视为弱实体。此架构中的课程是所有可用课程的定义列表，因此可以独立于任何其他 table。根据定义，这不是弱实体。创建时使用此数据库时，您可能会填写课程 table，此后它可能不会更改，除非在添加或删除可用课程选项时很少更改。
是的，您可以使地址成为复合属性，这在您的图表中是正确的。要清楚您对主键的使用，仅仅因为属性是唯一的并不能使它成为主键。 table 可以有一个且只有一个主键，因此您必须选择一个您确定不会重复的列。在此示例中，您可能认为街道号码可能是唯一的，但如果一家公司留下地址而另一家公司搬入该地址怎么办。那会破坏 table 的主键。通常，公司名称在城市或州获得许可，因此不能重复。这将是您的主键的更好选择。您也可以制作复合主键，但这是一个更高级的主题，我建议您稍后阅读。
取消课程final_mark。那就是 table 将只包含几行课程，这些课程不会链接到任何受训者，除了 course_schedule table。 Final_Mark 应该只在 table 中。如果您将 final_mark 添加到课程 table，那么，如果您的课程中有 10 名学员，那么您在课程 table 中将有 10 个重复的行，只有 final_mark 不同.而是仅保留 course_code 和标题，这样您就可以使用链接器 tables.
使用此架构不需要复合属性。您有一个教室 table，它将容纳所有可用的教室及其相关信息。然后使用 Classroom_Schedule 链接器 table 将给定的教室分配给 Course_Schedule。课堂的所有属性都不能分解为更简单的属性。
我编辑并重新制作了 ERD。我还有几个问题。
我包括参与约束（受训者和导师之间）、基数约束（M 表示很多）、弱实体（双线矩形）、弱关系（双线菱形）、组合属性、派生属性（白色 space 带圆圈）和主键。
问题：
显然，为了减少冗余属性，我应该只保留主键和描述性属性，出于简单原因，我将删除其他属性。在这种情况下哪些属性是多余的？我在想 start_date、end_date、phone 号码和地址 但这取决于实体集吗？例如属性地址将从 Trainee 中删除，因为我们真的不需要它？
对于这部分：“对于每个学员，我们希望存储（如果有的话）他们以前工作过的公司（雇主），就业期：开始日期和结束日期."
“任职期间：开始日期、结束日期”不是组合属性吗？因为日期用符号“：”显示，而且我相信我没有为 “他们工作的地方” 设置属性，这是位置？
另外，当我们已经有雇主属性和不同的开始日期时，如何显示以前的公司（雇主）？因为如果您查看问题信息，它两次为雇主说明 start_date，第二次它说 start_date 和 end_date。
我将许多属性标记为主键，但如何区分派生属性、主键以及哪些属性是多余的？
这个ERD中是否有多值属性？薪水和所持有的工作是否会是一个多值属性，因为雇主有很多薪水和工作。
我相信我正确地执行了参与约束（有一个）和基数约束。但是有些句子例如“一位讲师至少教授一门课程。每门课程仅由一位讲师教授”；当我 没有 课程和讲师之间的关系时，如何为此编写基数约束？
我的关系名称是否有意义，因为我所看到的只是“有”，也许我没有正确命名关系的行为？此外，我认为时间表取决于实际实体，因此它们是弱实体....那么这是否会使课程实体集也成为弱实体（我在这里没有将其标记为弱实体）？
对于公司地址，我输入了一个组合属性、街道编号、街道地址、城市...这样对吗？街道编号和街道地址也可以作为主键吗？
我还向课程添加了 最终标记 属性，course_schedule 这是在正确的实体集中吗？此属性的声明是“每位学员通过以下方式识别：唯一代码、社会安全号码、姓名、地址、唯一电话phone 号码、参加的课程和每门课程的最终分数."
对于这部分：“我们将站点上所有可用的教室存储在数据库中”我是否制作包含站点信息的组合属性？
问题信息：
一个受训者可能是self-employed或公司的雇员
确定的每位学员： 唯一代码、社会安全号码、姓名、地址、唯一 电话phone号码、参加的课程和每门课程的最终分数。
如果实习生是某公司的雇员：存储当前公司（雇主），开始日期。
对于每个实习生，我们希望存储（如果有的话）他们之前工作的公司（雇主）、就业时间：开始日期和结束日期。
如果受训者是 self-employed：存储专业领域和头衔。
对于在公司工作的实习生：我们存储薪水和工作
对于每家公司（雇主）：名称（唯一）、地址、唯一电话phone号码。
我们将所有知名公司存储在数据库中 城市。
我们还需要代表每个学员参加的课程。
每门课程都有一个 唯一代码和一个标题。
对于每门课程，我们必须存储：课程的教室、日期和时间（开始时间和持续时间（以分钟为单位））。
一间教室的特征是楼名和房间号以及最大座位数
一门课程至少在一个教室，并且可以安排在许多教室。
我们在数据库中存储al教室 在网站上可用。
我们将在公司至少开设过一次的所有课程存储在数据库中。
对于每位讲师，我们将存储： 社会安全号码、姓名和出生日期。
一名讲师至少教授一门课程。
每门课程仅由一位讲师教授。
还必须存储所有讲师的电话phone号码（每个讲师至少有一个电话phone号码）。
一个学员可以是一个或多个学员的导师 时间段（开始日期和结束日期）。
实习生不一定要当导师，但一定要有导师
- “代码”属性将成为您的 PK，因为它的唯一用途似乎是唯一标识符。
- 关系“是”会起作用，但引用两个 table 这样的关系会变得混乱。另外，您在实习生 table 中提到了 "Employers"，这不是好的做法。他们真的应该结合起来。请参阅我的有用提示部分，了解如何清理它。
- 根据您的详细信息，公司看起来像是该地区的完整 table 家公司。这意味着 table 是相当静态的，并在您的其他 table 中用作参考。这意味着 Employed 中的属性“雇主”将只是对 Company 中特定公司 PK 的外键引用。你应该画出这两者之间的关系。
- 似乎当雇员被“雇用”时，他们要么是公司的雇员，要么是self-employed。
- Company 中的地址字段将是您当前所在城市的唯一地址，是的，正如问题所述，table 是该城市中公司的完整列表。然而，因为这是一个独特的属性，您必须具有街道地址等细节，因为简单地添加城市名称将意味着所有公司都将拥有相同的地址，而这在一个独特的字段中是被禁止的。
其他一些有用的提示：
远离将带有复数的字段添加到图表中。当你有一个复数字段时，它通常意味着你需要一个单独的 table 和一个指向 table 的外键引用。例如，在您的 Table 实习生中，您有“雇主”。那应该是一个 Employer table，它有一个指向 Trainee Code 属性的外键引用。在 Employer Table 中，您可以组合 Self-employed 和 Employed table 以便从 Trainee 到 Employer 有一个参考。
ERD Link http://www.imagesup.net/?di=1014217878605。这是我为您创建的快速 ERD。注意使用链接器 tables 来防止 table 中的多对多关系。重要的是要注意有几种方法可以解决这个模式问题，但这就像我看到你的问题一样。该设计旨在帮助数据库的规范化。那是防止数据库中的冗余数据。希望这可以帮助。如果您需要对我提供的设计进行更多说明，请告诉我。将您的设计参数与其进行比较时，它应该是相当不言自明的。
跟进问题：
如果您希望减少可能是任意的属性，也许 phone_number 和地址可能是要消除的属性，但是开始和结束日期对于确定是否是排序和归档原因很有用条目是当前或过去的记录。
是的，periods_of_employment 不需要存储，因为您可以通过开始和结束日期推导出该信息。我认为他们工作的地方只是说以前的雇主，所以没有位置，而是意味着您应该能够获得受训人员曾经拥有的所有雇主的列表。如果您查询雇主 table 以获取实习生代码等于请求的实习生并按开始日期排序的所有记录，则可以使用当前模式获得它。它两次声明 start_date 的原因是让您知道对于所有“以前的”雇主，该记录将有一个开始和结束日期。因此是前者。但是，对于当前雇主而言，雇佣关系尚未结束，这意味着将不会有 end_date，因此它将为空。我认为这就是问题所在。
为简单起见，PK 是用于在另一个 table 中引用记录的唯一值。冗余值是您在 table 中基本上不需要的值，因为可以通过查询另一个 table 来导出相同的值。在这种情况下，除了课程 table 中的 Final_Mark 之外，您的大部分属性都很好。这是多余的，因为 Course_Schedule 将存储收到的 Final_Mark。课程 table 旨在简单地保存要被 Course_Schedule 引用的所有潜在课程的列表。
此设计中没有多值属性，因为这是不好的做法 工作和薪水是单一的，如果工作或薪水发生变化，您将向雇主添加新记录 table 不是添加到该列。多值属性使查询数据库变得困难，我建议不要这样做。这就是为什么我之前提到将所有具有复数的属性抽象为它们自己的 table 并使用外键引用。
你基本上确实把它写在这里了，因为 Course_Schedule 是一个链接器 table 意味着它旨在简化 table 之间的关系，所以你不需要没有多对多关系。
我觉得你所有的关系都很合适。此外，由于调度是链接器 tables 并且没有支持 tables 就无法存在，因此您可以将它们视为弱实体。此架构中的课程是所有可用课程的定义列表，因此可以独立于任何其他 table。根据定义，这不是弱实体。创建时使用此数据库时，您可能会填写课程 table，此后它可能不会更改，除非在添加或删除可用课程选项时很少更改。
是的，您可以使地址成为复合属性，这在您的图表中是正确的。要清楚您对主键的使用，仅仅因为属性是唯一的并不能使它成为主键。 table 可以有一个且只有一个主键，因此您必须选择一个您确定不会重复的列。在此示例中，您可能认为街道号码可能是唯一的，但如果一家公司留下地址而另一家公司搬入该地址怎么办。那会破坏 table 的主键。通常，公司名称在城市或州获得许可，因此不能重复。这将是您的主键的更好选择。您也可以制作复合主键，但这是一个更高级的主题，我建议您稍后阅读。
取消课程final_mark。那就是 table 将只包含几行课程，这些课程不会链接到任何受训者，除了 course_schedule table。 Final_Mark 应该只在 table 中。如果您将 final_mark 添加到课程 table，那么，如果您的课程中有 10 名学员，那么您在课程 table 中将有 10 个重复的行，只有 final_mark 不同.而是仅保留 course_code 和标题，这样您就可以使用链接器 tables.
分配不同的讲师、学员和教室
使用此架构不需要复合属性。您有一个教室 table，它将容纳所有可用的教室及其相关信息。然后使用 Classroom_Schedule 链接器 table 将给定的教室分配给 Course_Schedule。课堂的所有属性都不能分解为更简单的属性。