规范化和多值字段

Posted 2021-05-05

我的学生在访问中使用多值字段时遇到了问题，因此对规范化感到困惑。

这是我能做出的。给定1对多的关系，例如

Articles    Comments
--------    --------
artID{PK}   commID{PK}
text        text
            artID{FK}

Access可以将这些信息存储到看似一个表的地方，例如

Articles
--------
artID{PK}
text
comment
   + value

“value”指的是注释“column”的多个注释值，该访问实际上存储为单独的表。存储值如何存储的细节 - 表，其PK和FK - 是完全隐藏的，但是可以查询多值字段，例如，在上面的示例中使用查询

INSERT INTO article( [comment].Value )
VALUES ('thank you')
WHERE artID = 1;

但是查询并没有完全揭示实现多值字段的隐藏表的底层结构。

鉴于此（灾难，在我看来） - 我的问题是如何帮助新手进行数据库设计和规范化，了解Access提供什么，为什么它可能没有帮助，并且它不是忽略关系基础的理由模型。进一步来说：

• 除了上面的查询之外，还有更好的方法来揭示多值字段背后的结构吗？
• 是否有很好的例子说明多值字段不够好，并显示了显式标准化的优势？
• 是否有直接的方法来获取Access多值的多选视觉输出，但是基于单独的显式表？

谢谢！

答案

我不能给你使用这个功能的建议，因为我从来没用过它;但是，我可以告诉你不使用它的理由。

• 我想完全掌控自己在做什么。对于多值字段不是这种情况，因此我不使用它们。
• 此功能无法扩展。例如，如果您想在评论中添加日期字段，该怎么办？
• 有时需要将Access（后端）数据库升迁到“大”数据库（SQL Server，Oracle）。这些数据库不提供此类功能。通常是客户决定必须使用哪个数据库。最近我不得不使用Oracle后端将Access应用程序（前端）迁移到SQL-Server后端，因为我的客户决定放弃他的Oracle服务器。因此，限制自己仅使用常用功能是个好主意。
• 对于编辑查找表等常见任务，我创建了通用表单。我现有的解决方案不适用于多值字段。
• 我有一个（自制）工具，可以将开发人员站点上数据库结构的变化与客户端站点上的数据库同步。此工具无法处理多值字段。
• 我有安全管理工具，可以授予表的SELECT，INSERT，UPDATE和DELETE权限或撤销它们。同样，管理工具不适用于多值字段。
• 为注释提供单独的表允许您快速检查所有注释（通过打开表）。您不能使用多值字段执行此操作。
• 您将看不到文章与数据库关系图中的注释之间的1到n关系。
• 使用单独的表，您可以选择是否要将删除级联到详细信息表。如果不这样做，只要附有评论，您就无法删除文章。如果您希望保护注释不会被无意删除，这可能是可取的。

另一答案

重要的是要认识到物理和逻辑关系之间的差异。今天，整个互联网和Web服务（SOAP）在很多数据格式上实现了很多数据格式。

当您使用关系数据库（例如Access）表示多值数据时，则在幕后使用传统（和合法）关系。我不能强调，因此在Access中使用多值列实际上是一个LEGITIMATE关系模型。

表未暴露的事实并不能否定这个问题。实际上，如果您将发票（主记录和重复详细信息）表示为XML数据多维数据集，那么我们会看到两件事：

1）您可以使用Access 2这样的关系数据库来构建和表示该发票。这种规范化的关系数据模型也可以表示为SINGLE xml字符串。 3）删除XML记录（或字符串）意味着必须发生子行的级联删除（发票详细信息）。

因此，虽然确实已将多值字段添加到Access以处理SharePoint，但最重要的是要意识到这些数据可以映射到关系数据库（如果您不能这样做，那么Access就不会使用该XML）使用关系数据库表的数据作为当前正确的访问权限。

通过XML和SharePoint等网络，消费，管理和利用此类数据的需求不仅广泛存在，而且实际上是互联网的基本主要内容。

随着越来越多的数据变得复杂，我们发现在使用中需要爆炸多值数据。因此，任何使用互联网所谓的“时尚”的人都依赖并使用实际上非常有用的数据并且本质上是多值（复杂）的。

只要保留逻辑（非物理）关系数据模型，就可以使用多值列来表示这样的数据，这正是Access正在做的事情（它将关系数据模型映射到复杂模型）。请注意，复杂（xml）数据模型本质上不一定必须是关系型的。但是，如果您要将此类数据映射到Access，则复杂的多值模型必须符合RELATIONAL数据模型。

这完全是Access中发生的事情。

这种正确和合法的数学关系模型没有暴露的事实在这里几乎没有问题。我们是否建议因为Excel不公开使用的二进制代码，那么用户永远不会了解计算机？或许我们都必须在汇编程序中编程，这样我们才能正确地了解计算机的工作原理。

在一天结束时，谁在乎，为什么这很重要？今天人们驾驶自动驾驶汽车的事实并没有抛弃他们使用不同齿轮来操作汽车的概念。我们关闭整个社会的想法是因为有人要驾驶自动驾驶汽车，或者在这种情况下使用复杂的数据，这对我们来说是愚蠢的。

所以请记住，SQL中的扩展确实存在于查询多值数据的Access中，但是这里也指出了那些基础表没有公开。然而，正如所指出的那样，暴露这样的表仍然需要一个不改变或混乱级联删除，因为该特征需要在复杂数据模型（xml）和使用两个之间保持特征的交叉和正确的MATH关系模型。用于表示此类数据的相关表。

换句话说，如果您删除了用户使用参照完整性选项的能力，则可以使用相关表来表示复杂数据模型。 RI选项必须保持在那些隐藏表中的设置，否则这些数据将无法返回到XML或从中消耗它的复杂数据模型。

如上所述，关于用户被教导汽油如何与氧气反应以学习驾驶汽车，或者使用文字处理器并被迫学习关系模型并暴露基础表格在这里毫无意义。

但是，这些关于暴露这些表格的观点是合理的担忧。

REAL问题是SQL服务器和Oracle等不能使用或代表复杂数据，而访问可以消耗这些数据。

如上所述，复杂的数据船已经很久了！ XML，soap和互联网的基本技术都基于这种复杂的数据模型。

实际上，SQL服务器，Oracle和大多数数据库不能消耗这种多值数据代表它，而用户不必以关系方式创建和建模这样的数据是SQL服务器等的一大缺点。

在这种使用此数据的能力中，访问权限是独立的。

因此，对于使用智能手机，iPad或网络的任何人来说，您使用的是基于使用复杂数据构建的基本技术，这是Access现在允许的。

考虑到越来越多的数据本质上是复杂的，业内其他人可能会效仿。如果数据库行业没有改变，那么主流的传统关系数据库系统将不会成为这类数据的休息场所。

目前，在相关表格中存储数据的趋势正在快速发展，而像SharePoint，甚至Google文档这样的产品就证明了这一概念。因此，Access只会对市场压力做出反应，其他数据库供应商可能不得不效仿，或者只是放弃成为被称为互联网的“时尚”的一部分。

XML和复杂的数据结构现在是STAPLE和我们行业的事实 - 这不是我们都应该逃避的问题，但实际上是拥抱。

Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
[e-mail]

另一答案

技术讨论很有意思。我认为真正的问题在于学生的理解。因为它可以在Access中使用，所以学生将使用它，并且最初它可能会为一些设计问题提供简单的解决方案。否定将在以后尝试使用数据时发生。也许一个展示问题的简单例子可以说服一些学生避免使用多值字段？也许以另一种更有用的格式存储数据的例子会有所帮助吗？

祝好运 ！

彼得布拉德

另一答案

MS Access在简化数据库管理和抽象出很多复杂性方面做得很好。然而，这使得dbms概念的学习变得有点困难。您是否尝试过使用其他“标准”dbms工具，如mysql（甚至是sqlite）。从学习的角度来看，他们可能会更好。

另一答案

我知道这篇文章很老了。但是，这与我在这个主题上看到的所有其他帖子并不完全相同。这个人有一个很好的案例，使用多值字段......

作为一个正在努力尝试的人，他仍然非常努力地想要了解Access，我发现支持和反对使用Multi Valued Fields令人难以置信的令人沮丧。

我正试图对它进行整理，但如果每个人都如此反对它们，那么另一种方法是什么呢？似乎在每个搜索结果中我发现每个人都在告诉你如何使用多值字段和控件，或者告诉你它们有多可怕以及它们是多么的错误。许多人提到了他们的替代品，但没有人说“这是一个例子”。我在这里了解这些事情。虽然我知道这对于这些论坛中的很多人来说是一个更简单的概念，但我真的可以用一些例子来看一看。

我现在必须决定走哪条路。比较使用多值字段和备选方案以及使用控件选择多个值的示例会很棒。

或者我错了，只有通过Access才能选择多个项目的组合框功能？

另一答案

我想先解决你的最后一个问题。有一种方法可以提供父母子女关系的视觉呈现。它被称为子表单。如果您在Access中获得有关子表单的帮助，它将解释该概念。 我在项目中使用了子表单，我希望在表单中显示事务标题，并在子表单中显示事务详细信息。即使数据存储在两个规范化表中，也没有什么可以阻止这种构造。

当然，这会影响屏幕，而不会影响数据库。这就是重点。规范化与存储和检索有关，而与数据的其他用途无关。