强实体和弱实体 MYSQL

4
为了完成一个 MySQL/SQL 的作业,我需要创建两个不同的表来展示强实体和弱实体之间的差别。
是否有人可以给我展示如何做到这一点的例子?
我知道一个强实体可以独立存在而不需要另一个实体,但对于弱实体则不是如此。因此,例如,强实体将如下所示:
Employee(EmpNo, Name, EmpId)

但是我不确定如何创建一个展示差异的表格。


创建一个名为Employee的表格,其中包含所有员工的列表和一个名为Managers的表格。现在,Managers表格将具有EmployeeID的外键,因此Manager表格将依赖于Employee表格,并使其成为弱实体。 - Abhishek Ghosh
你能再明确一点吗?这是正确的做法吗? 员工(employees) 管理(Employeeid) - user3773272
抱歉,我仍然不理解,为了澄清一下,您是说将employeeid实体放在employee表中吗? - user3773272
请查看我的答案,如果需要更多澄清,请评论。 - Abhishek Ghosh
如果这个答案对你有帮助,请标记为已接受,这样其他遇到相同问题的用户也可以从中获得帮助! - Abhishek Ghosh
显示剩余4条评论
2个回答

3
如您所知,弱实体是没有主键的表,但弱实体集的主键由其存在依赖的强实体集的主键以及弱实体集的判别式组成。与强实体集之间的关系称为识别关系。在上述图片中提到的示例中,loan-payment是payment实体的识别关系。弱实体集用双线框表示,相应的识别关系用双线菱形表示。这里双线表示弱实体在强实体集中的总参与度,也就是每个支付必须通过loan-payment与某个账户相关联。从loan-payment指向loan的箭头表示每个支付都是针对单笔贷款的。弱实体集的判别式使用虚线下划线而不是实线下划线。
现在考虑另一种情况,我们想要存储雇员及其家属的信息。每个雇员可能有零个或多个家属。每个家属都有一个id号和姓名。
现在考虑以下数据模型:
有三个雇员,分别为E# 1、2和3。
-E#为1的雇员有两个家属,分别为1、Rahat和2、Chahat。 -E#为2的雇员没有家属。 -E#为3的雇员有三个家属,分别为1、Raju;2、Ruhi;3、Raja。
在Dependent实体中,id无法充当主键,因为它不是唯一的。因此,Dependent是一个弱实体集,具有id作为判别式。它与关系“has”的总参与度是因为没有家属可以存在于雇员之外(公司关心的是雇员)。
需要创建两个表以上e-r图。这些是Employee,其E#作为单列充当主键。另一个表是Dependent,具有E#、id和name列,其中主键是(E#和id)的组合。

1
看,强实体将有一个“id”,例如您的示例中有一个具有主键“emp num”的“employee”表,这是一个“强实体”。正如@AbhishekGosh所说,现在如果您有另一个表,比如没有任何“主键”的“Managers”,那么它将被视为“弱实体”,但它将引用“employee”的“emp num”,因为所有经理都是员工,并且这将被视为“Managers”表的外键。 - Guruprasad J Rao
1
希望他现在明白了.. :) - Guruprasad J Rao
1
@GuruprasadRao:是的 :) - Abhishek Ghosh
1
@user3773272:表格应该是自解释的...其余的解释应该是口头的,我认为。 - Abhishek Ghosh
1
只有EmployeeID是主键,因为可能存在姓名相同的员工! - Abhishek Ghosh
显示剩余13条评论

1

想象一下以下列的员工(Employee) 表:

员工ID(EmployeeID),员工姓名(EmpName),员工部门(EmpDept),...

经理(Managers)表将如下:

经理ID(ManagerID),员工ID(foreign-key)(EmployeeID),经理姓名(ManagerName),...

现在,每个经理都是一个员工,因此如果经理(Manager)表中有一个经理,那么在员工(Employee)表中也会有相同的记录。

"是一个"关系得到维护:每个经理都是员工,但不是每个员工都是经理


查询内容大致如下:
CREATE TABLE Employee
(
EmployeeID int NOT NULL,
LastName varchar(255),
FirstName varchar(255),
Address varchar(255),
City varchar(255),
PRIMARY KEY (EmployeeID)
)

CREATE TABLE Managers
(
ManagerID int NOT NULL,
EmployeeID int NOT NULL,
..
...
FOREIGN KEY (EmployeeID) REFERENCES Employee(EmployeeID)
)

你现在明白了吗? - Abhishek Ghosh
我认为这里不会有“主键”来表示“经理”作为弱实体!! - Guruprasad J Rao
我已经将其删除了。但我不认为这会造成什么问题? - Abhishek Ghosh
这不会造成任何问题,但它将不被视为“弱实体”。 - Guruprasad J Rao
1
好的!注意到了! - Abhishek Ghosh

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接