与所有主要属性的关系的功能依赖性?

时间:2015-05-22 09:02:52

标签: database database-design relational-database database-normalization functional-dependencies

我正在做数据库理论课程作为我的CS学位的一部分,我们必须确认我们设计的数据库是BCNF正常形式。我目前正在尝试创建函数依赖项,但我不确定当关系是全部素数时要做什么(即所有属性都是主键,就像你有M:N关系时那样)

例如,考虑这种关系:

Prod_Cat [name,category_ID,EPC]

其中name,category_id和EPC都是主键。

我如何为此定义功能依赖?

任何帮助都会让我非常感激。

感谢Corey

2 个答案:

答案 0 :(得分:1)

我不确定表中列的含义,但是如果您的主键包含所有列,那么您将只具有A-> B形式的简单功能依赖性,其中B是子集A.(如果你有任何其他功能依赖的形式A-> B,其中B不是A的子集,那么B就不在密钥中。)此外,该表必须在BCNF中(但可能不在4NF)。

答案 1 :(得分:0)

通常我们会考虑应用于实体表的规范化,而不是交集表。这是因为裸交集表只包含独立键,而不包含属性。通常,密钥是在规范化过程中创建的,因此所有依赖关系都已经解决(假设设计正确)。

但是,交集表定义了关系,关系可以有其他属性。

create table DeptMgrs(
    DeptID  int not null references Departments( ID ),
    MgrID   int not null references Employees( ID ),
    Assigned date not null,
    constraint PK_DeptMgrs primary key( DeptID, MgrID )
);

通常,交集表的FK字段之间没有功能依赖关系,因此DeptIDMgrID之间没有任何功能依赖关系 - 它们是导入的关键字段,它们一起形成关系的自然关键字。但是,Assigned字段告诉员工成为那个部门的经理。它不是部门或员工的属性,而是它们之间的关系。当然,这个例子在3nf甚至BCNF中都很简单,但是有了额外的属性,可能需要对交集表进行规范化。

并不应该有趣吗?

由于您的交集表中似乎只有FK字段,因此它们之间不应存在依赖关系。

相关问题