标签: normalization

我正在建立一个网站，将托管各种调查问卷。每个问卷都有不同数量的问题，每个问题都有不同数量的答案。我曾尝试设计一个数据库来保存每个问卷的问题和可能的答案，但最终每个问题都有单独的表格。这是正确的还是我在某个地方出错了？

例如

Table for question x

  Answer  | Answer ID
       1         019
       2         089

我无法为所有问题提供固定大小的表格，因为我没有最大数量的答案。这显然意味着我可能会得到数百张桌子，每个问题一张桌子。

在我现在正在处理的数据库中，几乎每个实体都有这 4 列：

CreatedDate
CreatedBy
RetiredDate
RetiredBy

通常这用于记录目的，对于某些实体来说，知道它何时退役的有用性是有争议的（但不要告诉我的老板）。对于其他一些东西，（比如卡车）它更有意义，因为“退役”的车辆可能会重新投入使用。

无论如何，我想知道将这些信息放在一张桌子上是否是个好主意，因为它到处重复。如果是的话，任何人都有一个好名字..？简单created_retired_dates吗？

因此，在工作场所，我们目前将审计日志存储在不同的表中，具体取决于它是什么，例如登录/访问信息、配置更改等。

这些都是独立的数据，没有外键或任何关系。一些列是相似的，例如 ID（显然）、日期时间、进行更改的用户名等，而其他列则不同。

最近，我被要求将所有表合并为一个，其中相似的列将被保留，而不同的列将在 JSON 中，存储在一个 CLOB 列中。

有人告诉我，这个过程称为“规范化”——我们正在将许多表转换为“规范形式”。

现在，我不是数据库专家，但这似乎与我在数据库介绍课程中学到的关于规范化的知识不符。还是我只是无知？

我们以前的 DBA 受够了开发团队频繁请求更改数据库架构以添加和删除列的请求。然后他建议开发人员他将创建具有以下定义的简单表。

+---------------+---------+
| Record Number | VarChar |
+---------------+---------+
| Column Name   | VarChar |
+---------------+---------+
| Column Value  | VarChar |
+---------------+---------+

因此，如果开发人员想要一个通常如下所示的表格

+-------------+---------------+-----------------+
| Employee ID | Employee Name | Employee Salary |
+-------------+---------------+-----------------+
| 0001        | John Doe      | 100000.00       |
+-------------+---------------+-----------------+
| 0002        | Jane Doe      | 110000.00       |
+-------------+---------------+-----------------+
| 0003        | Jack Doe      | 120000.00       |
+-------------+---------------+-----------------+

他们可以按以下方式添加行

+---------------+-----------------+--------------+
| Record Number | Column Name     | Column Value |
+---------------+-----------------+--------------+ …

我正在根据第三方供应商的数据建立车辆记录数据库。有 3 种模型：车辆、变速器和适配器。

车辆和变速器都是 1:n 适配器。从技术上讲，变速箱只是带有附加变速箱柱的车辆，而车辆除了车辆柱之外还包含燃油系统柱。我无法确定将我的数据组合成一个标准化集合的最佳方式。

以下是我的一些数据示例：

传输表

车辆表

数据透视表

如您所见，传输和车辆在trans_type/ fuel_system columns（分别）和之后基本相同。例如，我突出显示的 Vehicle 与用 engine_code 显示的第二个传输相同LML。

理想情况下，我希望最终只得到一张车辆数据表。例如，如果我要合并突出显示的记录，我最终应该只有 2 个记录2013 GMC Sierra 3500 HD：一个使用 6.0L V8 发动机，另一个使用 6.6L V8 发动机，以及相应的燃油系统和变速箱列每个。

数据透视表也将被合并，这意味着我需要以某种方式用合并数据中的新 ID 替换旧 ID。

以下是我对如何解决这个问题的想法：

1. 标准化相似的列（品牌、型号、发动机、变速箱）
2. 简单地将fuel_system和trans_type列拆分到他们自己的表中（但这对我合并没有任何帮助，它只会使事情更易于管理，直到我弄清楚如何合并）
3. 创建一个包含两个表中所有列的新表，并插入来自 Vehicles 和 Transmissions 的数据，填空（即更新fuel_system，其中记录匹配，反之亦然），然后开始清理重复项。

对于这篇冗长的帖子，我深表歉意，但我还没有在我的搜索中找到任何能真正概括这个过程的内容。欢迎任何意见或建议，并在此先感谢您。

我已经读过一段时间，规范化的优点之一是节省磁盘空间（因为规范化最大限度地减少了冗余），但是在当前磁盘存储非常便宜的情况下，节省磁盘空间仍然被认为是规范化的优势吗？

从我遇到的所有与数据库相关的参考书中，有一个通用规则是数据库表应该至少为 3NF。

据我了解，如果表满足 1NF 并且具有单列主键，则该表被认为是 2NF。如果我错了，请纠正我。

所以我不明白为什么有这么多的争论，特别是对于关联 M:N 表的实体；例如：

一个Product_Customer表，列：

• CustomerProductID
• CustomerID
• ProductID

有人说主键 ( CustomerProductID) 不是必需的，应该使用复合键 ( CustomerID, ProductID) 代替。

但这是否违反了表格的通用规则，因为使用复合键甚至不能满足 2NF 的要求，至少应该有 3NF？

如果我错了，请纠正我，尤其是我理解如果表有复合键的部分，它将不在 2NF 中。

我的问题由三部分组成：

我什么时候才能确定我的数据库设计是完美的？

返回数据库设计更改某些问题（即添加新列、删除列、更改数据类型、添加新表等）是否被认为是不好的做法还是正常？

有没有只是在训练的任何网站或书籍ERD和normalization？我想要大量带有推荐答案的示例、实践和案例研究，以加强我在数据库设计方面的技能并避免我所做的糟糕的数据库设计。

注意：我不需要书籍来解释这些概念，我需要的是实践、示例和案例研究以及推荐答案。

在学习 DBMS 作为一门学科之后，我想到了很多问题。规范化就是其中之一。当我了解到它有更多的困惑时，我发现无论我们在规范化过程中做什么，我们也可以通过一般常识来做到。即使在制作项目时，人们也不习惯遵循它。那么真的有必要吗？公司是否遵循它？我问这个问题是因为它可能会消耗更多的时间来规范化数据库。我们可以使用常识直接对其进行规范化，因此我认为没有必要遵循标准规范化程序。如果我错了，请纠正我。

以下哪个是正确的：

1. 如果表是第二范式，那么它必须是第三范式。
2. 如果表是第三范式，那么它必须是第二范式。

我知道其中只有一个是正确的，如果它是第一个是有道理的。如果是第二个 - 对我来说没有任何意义。也许是一个例子？