编写功能依赖关系

Question

第一个模块是用户模块。管理员，学生，讲师或嘉宾是从系统中受益的用户，他们参与此模块。管理员将为每个用户分配角色作为学生或讲师。每个角色都有不同的权限，即讲师可以上传作业和课程资料，创建在线测验和单个上传文件。用户拥有诸如用户ID，注册日期，最新登录日期，登录帐户，密码，名字，姓氏以及其他所需详细信息等信息。只要说学生证和讲师ID不能成为主键。因此，当分配ID和我的测验ID是主键时，我想如何声明分配或测验ID在功能上依赖于讲师？基于我的函数依赖关系，我不太确定我如何将它们与函数依赖关系联系起来？

Entity: User 
User(user ID, student ID, lecturer ID, guest ID, course ID, assignment ID, quiz ID, file upload, date of registration, date of latest logon, login account, password, first name, last name, e-mail, birthdate) 

Functional dependency 
user ID -> {student ID, lecturer ID, guest ID, date of registration, date of latest logon, login account, password, first name, last name, e-mail, birthdate} 
lecturer ID -> {course ID, assignment ID, quiz ID, file upload} 

Full dependency 
user ID, lecturer ID -> {student ID, guest ID, course ID, assignment ID, quiz ID, file upload, date of registration, date of latest logon, login account, password, first name, last name, e-mail, birthdate} 

Answer 1

首先，在形式A-函数依赖>乙意味着，给定为1个值，就可以确定一个且只有一个为B. A和B两者代表值集合的列。 （这就是为什么他们用大写字母写的原因。）

键确实与状态没有任何关系。

如果“讲师ID”在功能上确定“分配ID”，则FD是“讲师ID” - >“分配ID”。如果“讲师ID”也在功能上确定“测验ID”，则另一个FD是“讲师ID” - >“测验ID”。

如果你想写得更紧凑，你可以像这样陈述两个FD。

"lecturer id"->{"assignment id", "quiz id"} 

如果您分配字母L，A和Q，则可以像这样陈述两个FD。

L->AQ 

由于每个人都知道他们应该在那里，所以大括号通常会被忽略。

我不确定你想要与你的最后一节。但在其中，标有“功能依赖”的部分不表示任何依赖; “完全依赖”不表示完整的依赖关系，但可能表达一些部分依赖关系; “部分依赖关系”不表示任何部分依赖关系; “传递依赖性”不表示任何传递性依赖性。

Answer 2

目前尚不清楚你在努力完成什么。你似乎并不了解我们在模式设计中经历的步骤。

首先我们确定我们感兴趣的应用程序关系，例如“用户[用户ID]有角色讲师”或“用户[用户ID]有名字[名]和密码[密码]和...”。每一个都获得一个基本关系，该基础关系保存那些与这种方式相关的值的行。

对于每个关系，其应用程序关系的含义为每列确定它在功能上依赖于哪些列。然后我们找到一个最小的封面。这决定了候选键。我们可以选择一个候选键作为主键。

这确定了每个候选键上的非主列的完全和部分依赖关系。这允许我们通过分解我们的关系来将归一化为2NF，以将候选关键字上的非主列部分功能依赖分解为单独的关系。

只要说学生证和讲师ID不能成为主键。 因此，我想如何陈述分配或测验ID是 功能上依赖于讲师何时分配ID和我的测验ID 是主键？

这没有意义。在我们确定所有函数依赖之前，我们不能确定候选键。另外：你的意思是{studentID，lecturerID}“不能成为主键”，或者你的意思是{学生ID}“不能”和{讲师ID}“不能”？另外：你的意思是“不能”？

我们说assignmentID和quizID是在功能上有一定的关系依赖于lecturerID方式：

{lecturer ID} -> {assignment ID} 
{lecturer ID} -> {quiz ID} 

我们可以用相同的左侧设置（确定）的右手边（确定列集）结合：

{lecturer ID} -> {assignment ID, quiz ID} 

但还有其他规则，如寻找最小封面。

基于我的函数依赖关系，我不太确定我如何 假设他们与功能依赖关系？

这没有意义。将什么与你的函数依赖关系联系起来？

如果“用户”的唯一的功能性依赖是在“功能依赖性”的传递闭包的那些（即，仅文件描述符是必须在那里当那些者是那些），则最小的盖是

{user ID} -> {student ID, lecturer ID, guest ID, course ID, assignment ID, quiz ID, file upload, date of registration, date of latest logon, login account, password, first name, last name, e-mail, birthdate} 

，唯一的候选键是

{user ID} 

，并有一个候选键没有非黄金柱部分的依赖。