BC范式.docVIP

A（仓库号，，职工号，数量a.一个仓库有多个职工。b.一个职工仅在一个仓库工作。c.每个仓库里一种型号的配件由专人负责，但一个人可以管理几种配件。d.同一种型号的配件可以分放在几个仓库中。 由以上得 不能确定，由组合属性（，）来决定，存在函数依赖（，） - 。由于每个仓库里的一种配件由专人负责，而一个人可以管理几种配件，所以有组合属性（，）才能确定负责人，有（，）- 。因为 一个职工仅在一个仓库工作，有 - “仓库号”。由于每个仓库里的一种配件由专人负责，而一个职工仅在一个仓库工作，有（，）- 。找一下候选关键字，因为（，） - ，（，）- ，因此（，）可以决定整个元组，是一个候选关键字。根据-“仓库号”，（，）-，故（，）也能决定整个元组，为另一个候选关键字。属性，， 均为主属性，只有一个非主属性。它对任何一个候选关键字都是完全函数依赖的，并且是直接依赖，所以该关系模式是3NF。分析一下主属性。因为-“仓库号”，主属性是的决定因素，但是它本身不是关键字，只是组合关键字的一部分。这就造成主属性对另外一个候选关键字（，）的部分依赖，因为（，）- 但反过来不成立，而P-，故（，）- 也是传递依赖。虽然没有非主属性对候选关键辽的传递依赖，但存在主属性对候选关键字的传递依赖，同样也会带来麻烦。如一个新职工分配到仓库工作，但暂时处于实习阶段，没有独立负责对某些配件的管理任务。由于缺少关键字的一部分而无法插入到该关系中去。又如某个人改成不管配件了去负责安全，则在删除配件的同时该职工也会被删除。解决办法：分成管理EP（，，），关键字是（，）工作EW（，）其关键字是缺点：分解后函数依赖的保持性较差。如此例中，由于分解,函数依赖（，）- 丢失了, 因而对原来的语义有所破坏。没有体现出每个仓库里一种部件由专人负责。有可能出现一部件由两个人或两个以上的人来同时管理。因此，分解之后的关系模式降低了部分完整性约束。 一个关系分解成多个关系，要使得分解有意义，起码的要求是分解后不丢失原来的信息。这些信息不仅包括数据本身，而且包括由函数依赖所表示的数据之间的相互制约。进行分解的目标是达到更高一级的规范化程度，但是分解的同时必须考虑两个问题：无损联接性和保持函数依赖。有时往往不可能做到既有无损联接性，又完全保持函数依赖。需要根据需要进行权衡