数据库 - 对于一个独立的实体来说意味着什么？究竟？

Question

我刚刚开始了一个关于数据库设计的课程，并且已经完成了一项功课，其中一项任务是根据这个pdf列出虚构医院的所有实体类型：http://docdro.id/mbzdtUg。

我正在努力弄清楚什么应该是实体类型，什么不应该。我会给你一个基本的例子：

＆＃34;工作人员＆＃34;显然是一个实体类型，但每个工作人员都必须有他们的资格和工作经验的详细信息。由于工作人员可以具有多种资格和多种工作经验，因此这些属性不属于......对吧？应该＆＃34;员工资格＆＃34;和＆＃34;员工工作经验＆＃34;是实体类型？

根据实体定义，我读过的实体应该是独立的，并且代表实际存在的对象。一个实体完全独立意味着什么？ ＆＃34;员工资格＆＃34;和＆＃34;员工工作经验＆＃34;如果实体类型＆＃34;员工＆＃34;不存在。因此它们不是独立的（???）也不代表存在的东西（物理对象）。那么如果不是实体类型，它们是什么？应该例如＆＃34;约会＆＃34;是实体类型？我真的很困惑......任何帮助都表示赞赏。

谢谢！

编辑：应该提到这应该遵循实体 - 关系模型（ER）

编辑2：示例2：患者可以是门诊病人，也可以是住院病人。我应该将它们分为2个实体类型还是仅1个（患者）？

Answer 1

看起来你走在正确的轨道上，你的理解是正确的。如果您预见员工表可以具有多种资格或工作经验 - 那么资格和工作经验本身应该分成不同的实体表，因此预约也应该如此。

这也是规范化到位的地方 - 因为你可以让两个不同的工作人员拥有相同的工作经验（或资格） - 从技术上讲，你不希望只是简单地为员工提供一个子表导致大量数据重复。通常，使用规范化原则，您将创建一个单独的实体表WorkExperience，您将拥有所有不同的WorkExperience。 Staff和WorkExperiences表之间没有任何关系。但是你也会创建StaffWorkExperiences表（加入表/缓冲表），这将是Staff（1：M）的子项，但也会对WorkExperiences表（M：1）有约束。所以基本上你最终会将Staff表链接到StaffWorkExperiences表，而StaffWorkExperiences表又链接到WorkExperiences表。

最后，如果您还有患者病床并且患者可以是门诊病人或住院病人 - 那么这更像是一个财产，而且不需要额外的餐桌 - 所以你只有一张病人餐桌和然后是另一列（PatientType或类似的东西）来描述这个特殊的属性。

修改 我添加了一个示例模式，说明了连接表的结果。