规范化和多值字段

Question

我遇到了一个问题，那就是我的学生在访问中使用多值字段并因此而对正常化感到困惑。

这是我能做的。鉴于一对多关系，例如

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

访问能够将此信息存储到这似乎是一个表，像

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

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

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

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

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

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

谢谢！

Answer 1

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

• 我想完全控制我在做什么。对于多值字段，情况并非如此，因此我不使用它们。

• 此功能不可扩展。例如，如果你想添加一个日期字段到你的评论？

• 有时需要将Access（后端）数据库升迁为“大”数据库（SQL Server，Oracle）。这些数据库不提供这样的功能。通常，客户决定使用哪个数据库。最近我不得不使用Oracle后端将Access应用程序（前端）迁移到SQL-Server后端，因为我的客户端决定放弃他的Oracle服务器。因此，限制自己只使用通用功能是个不错的主意。

• 对于编辑查找表等常见任务，我创建了通用表单。我现有的解决方案不适用于多值字段。

• 我有一个（自制）工具，同步在我的开发人员的网站与客户端的站点数据库的数据库结构的变化。该工具无法处理多值字段。

• 我对安全管理工具，可以授予SELECT，INSERT，UPDATE和DELETE表的权利或吊销它们。同样，管理工具不适用于多值字段。

• 有一个单独的表的评论允许你快速检查所有的意见（通过打开表）。你不能用多值字段来做到这一点。

• 您不会看到文章和数据库图表中的注释之间的1对n关系。

• 使用单独的表格可以选择是否要级联删除细节表。如果您不这样做，只要有附带评论，您将无法删除文章。如果你想保护评论不被意外删除，这可能是可取的。

Answer 2

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

Answer 3

重要的是要认识到物理和逻辑关系之间的差异。今天，整个互联网和网络服务（SOAP）在一种本质上具有多值性的数据格式上非常实现。

当你代表关系数据库（如Access）多值数据，然后在后台使用的是传统的（和合法）的关系。我不能这样强调，那么在Access中使用多值列实际上是一个LEGITIMATE关系模型。

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

1）您可以使用关系数据库构建并表示该发票，如Access 2）这样规范化的关系数据模型也可以表示为一个单一的xml字符串。 3）删除XML记录（或字符串）意味着级联删除子行（发票明细）必须发生。

所以，尽管将多值字段添加到Access以处理SharePoint是事实，但认识到这些数据可以映射到关系数据库是非常重要的（如果您不能这样做，那么Access可以不使用关系数据库表中的XML数据作为ACCESS当前的权利）。

而且随着网络如XML和SharePoint则需要消耗以及管理和利用这些数据不仅分布广泛，但实际上是互联网的一个基本的主食。

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

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

这完全是在Access中发生的。

这样一个正确和合法的数学关系模型没有暴露的事实在这里没什么问题。我们是否建议，因为Excel不公开使用的二进制代码，那么用户将永远不会了解计算机？或者，也许我们都必须编写汇编程序，以便我们都正确地学习计算机的工作方式。

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

因此请记住，SQL中的扩展确实存在于Access中以查询多值数据，但这里也指出这些基础表未公开。但是，如上所述，暴露这样的表将仍然需要一个不改变或混乱级联删除，因为该功能是必需的维护复杂数据模型（xml）和使用两个之间的特征交集和正确的数学关系模型相关表格来表示这些数据。

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

如前所述，关于用户被教授汽油如何与氧气反应以学习驾驶汽车，或者使用文字处理器以及被迫学习关系模型以及暴露底层表格在这里没什么意义。

但是，这里提到的关于这样的表格暴露的观点是合理的担忧。

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

如前所述，复杂的数据船在LONG前航行！ XML，soap和互联网的基本技术都基于这种复杂的数据模型。

在效果上，SQL服务器，Oracle和大多数数据库不能消耗此多值数据表示它无需用户具有在关系的方式来创建和模型这样的数据是SQL服务器等的大的缺点

访问权独立于使用此数据的能力。

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

由于越来越多的数据本质上是复杂的，很可能其他行业将不得不效仿。如果数据库行业没有改变，那么主流的传统关系数据库系统将不会成为这些数据的休憩处。

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

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

Albert D. Kallal (Access MVP) 
Edmonton, Alberta Canada 
kallal@msn.com 

Answer 4

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

祝你好运！

Peter Bullard

Answer 5

我知道这个帖子太旧了。但是，它与我在这个主题上看到的其他任何帖子都不尽相同。这个人有一个使用多值字段的好例子...

作为一个正在尝试谁仍然努力尝试让他们的头绕过Access的人，我发现讨论和反对使用多值字段令人难以置信的挫败感。

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

我现在正要决定走哪条路。比较使用多值字段和替代方法的示例并使用控件选择多个值将是一件好事。

或者我错了，您可以选择多个项目的组合框的功能只能通过访问？

Answer 6

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

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