在1：N关系中添加什么外键 - 逻辑模型

Question

我对在逻辑模型中标记双向1：N关系感到困惑。

我们有两个表：员工和部门。每个员工都知道＆＃34;他在哪个部门工作，每个部门都知道＆＃34;员工在那里工作 - 换言之，员工标识符的集合。

从正式的角度来看，我是否通过向两个表添加FK来对此进行标记？

|EMPLOYEE    |           |DEPARTMENT|
|____________|           |__________|
|PK EMP_ID   |>O------||-|PK DEPT_ID|
|FK DEPT_ID  |           |FK EMP_ID |
|NAME        |           |NAME      |
|...         |           |...       |

Answer 1

当一个地方的子行值必须出现在其他地方时，FK（外键）成立。

由您决定在哪些表中使用哪些信息，即您希望每个表表示哪些业务关系/关联。 在之后，你有了表的意思，可以出现什么样的商业情况。表的含义决定了可以出现的数据库状态，即约束是什么以及基数是什么。我们告诉DBMS，它可以防止更新不会出现的状态。

在这种情况下，在部门中使用emp_id意味着什么？如果表格表示（具有特征谓词）“department dept_id 有员工 emp_id ...”那么（a）dept_id在Employee＆amp中是多余的; （b）dept_id不是部门和部门的PK。 （c）部门违反了正常化原则。如果表格意味着“department dept_id 有经理 emp_id ...”那么PK / FK就有意义了。但是你碰巧遇到了典型的SQL DBMS（不必要地），没有处理FK周期。但您似乎只想要“department dept_id 具有名称​​ name ...”。所以部门没有emp_id专栏。或许你想要员工和没有彼此的ID的部门加上Works_in（emp_id，dep_id）“employee emp_id 在部门 dept_id 中工作”（这涉及到什么FK？）。

PS“知道”并不是一个有用的概念。 （你似乎怀疑这是因为你把它放在恐慌引用中。）你似乎试图捕捉你有一些涉及雇员和一些意义的意义。部门。确定记录情况所需的谓词。当FK持有时发生的事情是，如果某些值满足某种关系/关联，那么它们也会满足某种其他关系/关联。 “关系”曾经意味着FK虽然很常见，但却源于对关系模型和ER建模的误解。