数据库编程 求解决 如图所示 尽快，拜托

R 数据表具有三个字段依赖关系。
员工和项目决定薪资构成，项目决定部门，部门决定管理者。
R 不符合第二范式，必须拆分为 R1 和 R2 R2 已经是第三范式了。
R1 具有传递依赖性，并分为 R1 1 和 R1 2 最后，R被分为三个表：R1 1 、R1 2 和R2 你自己掂量一下吧。

数据库应用题帮忙

说实话，关系模型还算清晰，但说实话，有一些地方我当时不太明白。
让它同时发生。

FD={(库存号、产品号) -> (库存号、数量)、(库存号、部门号) -> 负责人} 这两个FD的不同之处在于，第一个FD(库存号、产品号)可以从(部门号、数量)中扣除，但第二个FD(库存号、部门号)也可以有负责人。
这有点矛盾。
如果你认为如果同一家店卖同样的产品，属于同一个部门，但负责人不能改变，所以（店号，部门号）领导该人，这是没有问题的。
但（产品编号）、（产品编号、数量）、使用（部门编号）等合作伙伴负责人，过程中可能会出现信息不一致的情况。
例如，A店销售B产品，属于C部门，负责人是张三。
但如果A店卖D产品，也属于C部门，负责人还是张三吗？应该想到的是，但是数据结构的组织方式很容易让人迷惑。

候选代码是谁（库存号、产品号），这个是没有疑问的，这两个一起就可以单独确定表的顺序，部门号和金额之间的顺序。
但关键是你的表R1 =店铺号、产品号、部门号、数量}，部分取决于非主属性的候选代码。
例如，数量仅取决于商店编号、产品编号），而部门编号仅取决于编号（商店、产品编号），因此仅满足1 NF，而不满足2 NF。
我不会说传递客户，比如（商店编号，部门编号）获取人员，但是部门编号不属于候选代码，这是典型的传递依赖。

对于R2 ={店铺号，部门号，负责人}，这个表相对来说比较好，因为（店铺号，部门号）是候选代码，而负责人不是主属性，只依赖于候选代码，满足2 NF。
但说实话，我不运行这个。
我记得有关信息
说白了，设计关系模型的关键是保证非主属性在功能上完全依赖于候选代码，避免部分依赖和传递依赖。
在你的例子中FD计划有些复杂，尤其是第二个FD，很容易导致数据混乱和不一致。
如果需要更详细的分析，建议您在业务场景中添加更多的细节，比如除了库存号、产品号之外，部门号是否会发生变化、负责人是否会跨部门发生变化等。

【数据库】浅谈函数依赖

函数依赖是数据库设计的核心。
FD描述了属性之间的依赖关系。
A→B 表示 A 唯一决定 B。
A 的所有属性必须完全依赖于 A。
部分依赖 A 部分属性就足够了。
传递依赖 A→B 和 B→C 意味着 A→C。
规范化消除了重复的异常。
1 NF保证原子性。
2 NF 非主属性仅依赖于主键。
3 NF 非默认属性不依赖于其他非默认属性。
BCNF 删除非候选关键决定因素。
例如，StudentCourse 表被细分以避免重复。
你自己掂量一下。