Question

请考虑以下情况。

我们有一个0NF表

StudentTeacherTable：

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表

Answer 1

您的问题与规范化无关。您问的是，如果不是物理连接相似类型和相同属性集的表。归一化在这个问题上没有偏好。基本上没有错误或正确。这更多是关于根据特定设计设置的平衡权衡：

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

缺点： - 使用代理或其他非自然密钥时：没有唯一的交叉表标识符可能会使更改的潜在上升需求难以管理 - 查看所有表格需要大量的工会（特别是如果超过两个表格）

选项2：让一个表具有附加类型列：选项1相反方向的利弊;

G ***可能会为您找到很多资源。

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

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

Answer 2

你写＆＃34;理想情况下，在标准化之后我想...＆＃34;

这表明你已经得到了解决方案，就练习而言。务必将任何工作改装为预先设定的解决方案;在规范化的情况下，这取决于/有助于揭示数据元素之间的关系，你应该非常谨慎地考虑一个或另一个解决方案的假设。

那就是说，让我们试着解决这个问题，记住一组规范化的表是你的结果，但规范化是一个过程：更确切地说，按顺序产生1,2，3NF，从一个小的数据样本，是一个精确的过程，通常在学习规范化时实施。

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

StudentID
StudentName
StudentDepartment
StudentDepartmentAdd
TeacherID
TeacherName
TeacherDepartment (repeating)
TeacherDepartmentAdd

您的数据令人困惑，因为样本很小，并且填写的表单或报告中可能存在少量提示。但我相信我可以做两个假设：（1）教师部门依赖于教师，顾名思义; （2）每位教师（如数据中的Dave）有许多学生在他们工作的每个部门。如果是这种情况，那么＆＃34; studentdept＆＃34;和＃34; teacherdept＆＃34;最好作为一个属性处理，这两个列有助于简单地计算出依赖关系。

在这两个假设下，该过程变得熟悉，只有两个级别的重复组：

      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相同，所以我不在上面写。

因此，所提供的数据与您要查找的结果兼容。但是，你应该明白：

通常不会根据此类不完整信息进行规范化。在这里，为了达到预期的结果，我们必须承担很多事情补偿缺少真实数据。
此过程的目的是确定正确的决定因素选择，但它并不能代替数据中明智的确定性关系的推理。同样，从这个案例中可以看出这一点，以及数据样本给出的有限信息。

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

2 个答案: