这个数据规范化策略是一个好的实现吗？答案

【问题标题】：Is this data normalization policy a good implementation?这个数据规范化策略是一个好的实现吗？
【发布时间】：2017-01-29 03:16:03
【问题描述】：

我正在开发一个数据库，该数据库将包含来自不同应用程序的信息，其中一些多选标签在同一字段中包含多个值。

例如最简单的情况是在一个应用程序中存在以下选择器：

You are: Lord
         Lady

花药有这个：

You are: Monsieur
         Madame

最后，我需要在集中式数据库 (DataWarehouse) 中提供每个客户的标准化表格。

customer_id | customer_name | customer_type
--------------------------------------------
      1     |       John    |       Sir
      2     |        Sia    |     Madame

我认为，当我在源中开发此数据的标准化时，为了规范化这些数据，最好的策略是创建辅助表来保存我的规范化数据 (output) 和 input 数据的关系应用。

例如：

我的标准化期望值

   id  |  value 
----------------
    1  |   Sir  
    2  | Madame

我的输入期望值

   id  |  value 
----------------
    1  | Lord  
    2  | Lady 
    3  | Monsieur
    4  | Madame

我的关系表

 id | normalized_value_id | expected_value_id
----------------------------------------------
 1  |           1         |          1
 2  |           1         |          3
 3  |           2         |          2
 4  |           2         |          4

我认为在这种情况下这是正确的策略，因为我不知道确切的值，以及一旦值标准化后与我的预期输入和预期输出的确切关系。此外，我不知道要规范化的应用程序数量（可能是 2 个，也可能是 100 个）。

在这种情况下，如果我一开始有 2 个应用程序要规范化，我可以毫无复杂地创建规范化的预期值表，然后我可以在发现新值时添加输入的预期值，然后在关系中将其关联起来表而不会对规范化过程产生任何影响。

此外，我可以使用这三个表来生成所有多选器的所有规范化过程，例如：

街道多选器：

You live: Str
          Ave

另一个：

You live: St
         Av

我的标准化期望值

   id  |  value 
----------------
    1  |   Sir  
    2  | Madame
    3  | Street
    4  | Avenue

我的输入期望值

   id  |  value 
----------------
    1  | Lord  
    2  | Lady 
    3  | Monsieur
    4  | Madame 
    5  | Str
    6  | St
    7  | Av
    8  | Ave

我的关系表

 id | normalized_value_id | expected_value_id
----------------------------------------------
 1  |           1         |          1
 2  |           1         |          3
 3  |           2         |          2
 4  |           2         |          4
 5  |           3         |          5
 6  |           3         |          6
 7  |           4         |          7
 8  |           4         |          8

这个实现对于我想做的事情是否足够好并且一致？

【问题讨论】：

@philipxy 你为什么这么说？最后，您要做的是规范化数据（使用 id，您可以引用任何这些值，然后您就可以减少数据冗余）
数据库“规范化”减少冗余涉及用其他加入它的关系替换关系。它不涉及添加ID。（如果有的话，那就是数据压缩。）如果您认为确实如此，则需要阅读教科书。当我第一次阅读您的消息时，我编辑了您的标题，添加了标签“数据库规范化”并评论说规范化不涉及添加 id。但是后来我认为您的意思是在系统地更改数据值的意义上“规范化”，例如在统计中，每个标签“规范化”，例如将许多输入值转换为一个规范化的值。所以我取消了这些更改。

标签： sql database database-normalization

【解决方案1】：

首先 - 如果你还没有检查过 ETL 过程，我会推荐它：https://en.m.wikipedia.org/wiki/Extract,_transform,_load

我觉得这个计划不错。我有两年在数据仓库中进行自定义分析的经验。我会添加一个默认映射，这样您就可以在不使用 NULL 的情况下轻松标记新值，并且我会在您用于映射的表上添加一个源列，否则这似乎是一个不错的计划。

【讨论】：

感谢您的回答。我有ETL过程的经验。我会将这些过程用于数据传输和规范化过程，但我希望将规范化参数导入数据库。默认映射是什么意思？您的意思是例如为任何新值分配默认值，例如将 Sir 分配给那些多选器类型中的任何新值？我猜你是用 source-column 来分配这个默认值的吧？
是的 - 应该将默认映射分配给尚未映射的新值，以避免必须将 NULL 放入规范化值中。当然，默认值应该有一个名称，它永远不会是预期的或标准化的值，例如 # 或 *。这是为了避免 NULL，老实说，我不知道这是 DWH 的最佳实践还是只是一种偏好。源列只是为了方便。
此外，我会在 1.000 左右开始标准化值 id，以便为下面的默认值腾出空间。每个来源一个。
我理解并同意你的看法。我不知道为什么要为默认值保留大约 1000 个 id，最好只使用一个 dfault 值，或者您只是为了区分每个来源的默认值？
是 - 1.000 能够为每个源设置默认值。您不知道将包含多少个来源，但我认为在 DWH 的生命周期内它会少于 1.000。为每个来源设置默认值，有望减少识别任何新值源自哪个来源的时间。

【解决方案2】：

你的实现只需要申请多对多的关系。我猜这些表中的关系是一对多的。您应该阅读如何实现一对多关系的解决方案。

【讨论】：

确实是这样，但是我不知道要规范化多少参数，所以我看不出有什么改进可以避免使用关系表而只使用简单的表来使用 1-多对多关系。谁能给我解释一下？
你需要标准化多少参数并不重要。它首先取决于为 OLTP 或 OLAP 创建表的目的。如果要为 OLTP 创建表，则需要对表进行规范化，直到 4NF。如果您希望表适用于 OLAP，则需要对表进行非规范化。
当我将从应用程序 (OLTP) 收到的内容规范化为 DWH (OLAP) 时，我认为我必须将其作为 OLAP 规范化过程来关注。非规范化表是什么意思？
在你的情况下，我猜你的数据库是 OLTP，所以尝试规范化数据并遵循规范化规则。当您了解规范化规则及其目的时，您的问题就会得到解决
非规范化意味着您将表合并到一个表中以适应雪花模式。

【解决方案3】：

总体而言，该计划似乎还可以。也许规范化的第一件事是：没有列意味着不止一件事。

在实践中，大多数时间都使用一对多。本质上：

表格标题

ID  |  Desc
 1  |   Sir
 2  | Madam

桌人

ID | Name | Title
 1 | Dean |   1
 2 | Jess |   2

只有标题被添加到标题表中。 person 表中只有 Persons，但 Title ID 可以是 Title 中的任何内容。在执行 Many-Many 时，您希望保持相同的概念。

【讨论】：