数据库规范化 - 合并/组合表答案

【问题标题】：database normalization - merge/combine tables数据库规范化 - 合并/组合表
【发布时间】：2015-06-10 00:25:54
【问题描述】：

请考虑以下情况。

我们有一个 0NF 表

学生教师表：

StudentName StudentDepartment StudentDepartmentAdd TeacherName TeacherDepartment TeacherDepartmentAdd
    John          CS                  London           Dave        Eng, CS             Oxford
    Mike          CS                  London           Dave        Eng, CS             Oxford
    Chris         Eng                 Oxford           Dave        Eng, CS             Oxford

理想情况下，标准化后我希望有类似的表格

学生桌：

StudentName Department TeacherName
    John        CS         Dave
    Mike        CS         Dave
    Chris       Eng        Dave

教师桌：

Name 
Dave

教师部门表：

TeacherName DepartmentName
     Dave         CS
     Dave         ENG

部门表：

   Name Address
    CS   London
    ENG  Oxford

但是，如果我遵循 3NF 的规范化。我会得到的

学生桌：

StudentName Department TeacherName
    John        CS         Dave
    Mike        CS         Dave
    Chris       Eng        Dave

DepartmentForStudent 表：

   Name Address
    CS   London
    ENG  Oxford

教师桌：

Name 
Dave

TeacherToDepartment 表：

TeacherName DepartmentName
     Dave         CS
     Dave         ENG

DepartmentForStudent 表：

   Name Address
    CS   London
    ENG  Oxford

我的问题是，在数据库规范化的哪个步骤（1NF、2NF、3NF 等）中，我可以将 studentDepartement 与teacherDepartment 列合并/组合到一个表中以导出上述规范化形式？

换句话说，遵循规范化规则。我最终将拥有一个 StudentDepartment 表和一个 TeacherDepartment 表，而不是一个学生和教师的 Department 表

【问题讨论】：

规范化不会引入“TeacherID”、“DepartmentId”等新列
@MikeSherrill'CatRecall' 是的。好点子。我已经更新了它。但是问题仍然有效。
@JonathanLeffler 不确定您的意思。 “StudentTeacherTable”是被规范化为下面几个表的表。
Student 表看起来不会被规范化，除非所有学生只允许有一位老师。（其他评论撤回。）
通过 BCNF 标准化是基于函数依赖的。函数依赖是什么？

标签： database relational-database database-schema database-normalization

【解决方案1】：

您的问题与规范化无关。您在问这个问题，如果不物理连接相似类型和相同属性集的表。规范化在这方面没有偏好。而且基本上没有对错之分。这更多是关于根据特定设计设置进行平衡权衡：

选项 1：有多个表（如您在示例中所示）：优点： - 显式数据库设计 -> 易于阅读 - 由于不需要类型列，因此需要较低的内存/磁盘空间

缺点： - 使用代理或其他非自然键时：没有唯一的交叉表标识符，这可能会使潜在的即将到来的变更需求难以管理 - 查看所有表需要大量的联合（特别是如果超过两个表）

选项 2：有一个带有附加类型列的表：与选项1相反的利弊

G*** 可能会为您找到有关该主题的大量资源。

2 个例子：存储分层数据（例如，具有类型的单个表与具有 1:1 键和差异的多个表......）在Relational Database Design Patterns?

http://sqlmag.com/sql-server/trouble-type-tables

【讨论】：

你的回答太实用了，不够学术。我的问题纯粹是关于正确和错误的理论。
确定正确或错误的问题意味着您知道问题的答案，在您发表评论后我不再理解。如果你能用你的发现更新你的听众，那将是公平的。
我的意思是我确信在规范化理论中存在明确的对与错（而不是基于你想要优化多少的对/错）。但我不知道我的问题的答案。
如果你不知道答案，你为什么确定？您正在一组不适合您的问题的规则中搜索答案。您也不会在交通法中找到有关如何处理谋杀案的规则。说明您的问题在“规范化定律”中有一个答案意味着您假设您的问题符合该“定律”（可以说：这是搜索的正确位置）。你是怎么得出这个假设的？
好吧，忽略我的问题，如果你愿意，可以找一些其他地方争论。

【解决方案2】：

您写“理想情况下，我希望在标准化之后......”

这表明您已经获得了关于练习的解决方案。始终小心将任何工作改装为预设的解决方案；在标准化的情况下，这取决于/有助于揭示数据元素之间的关系，您应该非常谨慎地考虑一个或另一个解决方案的假设。

也就是说，让我们尝试解决这个问题，记住一组规范化表是您的结果，但规范化是一个过程：更准确地说，从小数据中按顺序生成 1、2、3NF样本，是一个精确的过程，在学习归一化时经常练习。

首先，让我们列出所涉及的属性。此时，我将添加此数据明确需要的代理键，并用 ID 标识它们：

StudentID
StudentName
StudentDepartment
StudentDepartmentAdd
TeacherID
TeacherName
TeacherDepartment (repeating)
TeacherDepartmentAdd

您的数据令人困惑，因为样本量很小，而且在填写的表格或报告中几乎没有线索。但我相信我可以做出两个假设：（1）教师部门依赖教师，顾名思义； (2) 每位老师（如数据中的戴夫）在他们工作的每个部门都有很多学生。如果是这种情况，那么“studentdept”和“teacherdept”最好作为一个属性处理，这两列有助于简单地计算出依赖关系。

在这两个假设下，过程变得熟悉了，只有两个层次的重复组：

      UNF                     1NF                   2NF (and 3NF)

  _TeacherID_            _TeacherID_           _TeacherID_
   TeacherName            TeacherName           TeacherName
   TeacherDepartmentAdd   TeacherDepartmentAdd  TeacherDepartmentAdd
|  Department 
|| StudentID             _TeacherID_*          _TeacherID_*
|| StudentName           _Department_          _Department_
|| StudentDepartmentAdd
                         _TeacherID_  )*       _StudentID_*
                         _Department_ )        _Department_
                         _StudentID_            TeacherID *
                          StudentName         
                          StudentDepartmentAdd _Department_
                                                StudentDepartmentAdd

                                               _StudentID_ 
                                                StudentName

还需要两个假设：学生和部门决定教师；并且该部门确定部门地址（该部门任教的地方）。这些从小数据样本中完全不确定，但我根据你说你应该得到的结果接受它们。在任何实际情况下，您都会要求更大的数据样本，或者与实际用户确认数据的结构。在此基础上，3NF和2NF是一样的，所以上面就不写了。

因此，给出的数据与您正在寻找的结果兼容。但是，你应该明白：

通常不会根据这些不完整的信息进行标准化。在这里，为了达到预期的结果，我们必须假设很多事情以弥补真实数据的缺失。
此过程的目的是确定决定因素的正确选择，但它不能取代对数据中合理决定关系的推理。同样，从这个案例中可以明显看出这一点，并且数据样本提供的信息有限。

【讨论】：