问题标签 [database-normalization]

规范化的优点是什么。以及我们为什么这样做。有人可以解释一下吗？？？？？？

首先很抱歉我的英语不好呵呵我需要一些帮助，我想为一个网站设计一个数据库，比如一个迷你亚马逊。该数据库将管理各种产品（电视、汽车、电脑、书籍、电子游戏、铅笔、桌子、裤子......），而且，每个产品都必须有一些属性（将被索引），例如，如果产品是一本书，属性将类似于流派、年份、作者。如果产品是电视，属性将是尺寸、颜色和年份。如果产品是汽车，属性将是年份、颜色、型号等。所以，这是我的想法：

1. 一张桌子来管理部门（如电子、书籍……）
2. 一个表来管理部门的类别，这个表将是前一个表的子表。如果部门是电子，这里是音频、电视和视频、游戏……（每个类别属于一个部门，关系是一个部门对多个类别）
3. 一表管理产品（每个产品属于一个类别，关系是一个类别对多个产品）
4. 一张表来管理属性（如年份、颜色、流派、型号......）
5. 一张表，用于与属性关联的产品，此表将称为 ProductProperties

我不确定这是否是最好的方法，数据库会很大，我将在 MySQL 上开发数据库。但是，我认为这不是最好的方法，这篇文章讲的是“数据库抽象：聚合和泛化” http://cs-exhibitions.uni-klu.ac.at/index.php?id=433，换句话说通用对象（我认为），但这种方式很旧（70 年代）。在这篇文章http://www.simple-talk.com/sql/database-administration/ten-common-database-design-mistakes/在“一个表保存所有域值”部分中说这是一种错误的方式...我说这一切都是因为表格 ProductProperties，我不知道我是否制作了这张表格，或者我是否为每种产品制作了特定的表格。

你有什么建议吗？还是你有更好的主意？

先谢谢了，保重！！！

我知道标准化已经在 Stack Overflow 上进行了广泛的讨论。我已经阅读了许多以前的讨论。不过，我还有一些其他问题。

我正在开发一个至少有 100 个表的遗留系统。数据库存在一些非规范化的结构、包含各种不同数据的表以及其他问题。我被赋予了尝试改进它的任务。我不能只是重新开始，而是需要修改现有架构。

过去我一直尝试设计规范化的数据库。现在的问题。一位高级开发人员建议在某些情况下我们无法规范化：

1. 有时间数据。例如，创建链接到产品的发票。如果客户在一年后要求提供此发票的副本，我们必须能够提供原件的准确副本。如果产品价格、名称或描述已更新怎么办？大佬建议将价格等产品信息复制到发票表中。我在想也许我们应该有另一个表，比如 productPrice ，它有一个日期字段，这样我们就可以跟踪价格随时间的变化。我猜我们需要相同的产品描述和名称吗？看起来很复杂。你怎么看？

2. 数据库是一个会计系统。我对会计不是很熟悉。目前，一些汇总数据被导出并存储在数据库中。例如当年的总销售额。我的高级助理说会计师喜欢通过将该值与实际从发票等计算的数据进行比较来检查事情是否正确，以使他们相信应用程序正常运行。

他说，例如，目前我们可以判断是否有人错误地删除了去年的发票，因为总数不会相同。他还指出，动态计算这些总数可能会很慢。当然我说过数据不应该重复，应该总是在需要的时候计算。我建议我们可以使用 SQL Reporting Services 或其他可以在一夜之间生成这些报告并缓存它们的解决方案。反正他不信。对此有何评论？

我正在尝试决定数据库设计。更具体地说，这是更大设计的子部分。基本上，有“位置”——每个位置可以有任意数量的传感器与之关联，它可以有一个记录器（但只有 1 个）。

我有传感器读数和记录仪读数，每个读数都足够不同，我认为需要单独的表格。

如果传感器读数超出范围，则会生成警报。虽然传感器读数超出范围，但它们仍与该警报相关联，因此您最终会收到 1 个包含许多读数的警报，以便我稍后绘制警报图，以便发现趋势等。

与记录仪读数相同。

到目前为止，这是我存储这些数据的 3 个想法：

选项1：

• 问题：很多重复的表格（这真的很重要吗？？）

选项 2：

• 问题：不强制执行“每个警报至少 1 个读数”规则。
• 问题：允许不止一种类型的读数引用相同的警报。

选项 3：

• 问题：没有什么能阻止 LoggerAlert 和 SensorAlert 引用相同的警报（与选项 2 相同的问题）。
• 问题：混淆数据库（超级表不是更多的 OO 概念吗？数据库意味着纯粹是关系，不是吗？）

我认为到目前为止我更喜欢选项 1，因为它看起来很干净而且意图很明确（我希望！），即使我有效地重复表格。

我刚刚想到的唯一一个小问题是，不同传感器的读数仍然可能与一个警报相关联。

我想知道人们对上述选项的看法。我经常看到使用建议安静的“超级表”，但由于某种原因，它感觉不对 - 几乎感觉有点像黑客，尤其是当我看到试图确保数据完整性的方法时。它似乎更类似于 OO 编程而不是关系设计。

谢谢。

编辑： 一些进一步的信息，以帮助回答以下一些问题：

大多数情况下，数据库仅通过应用程序服务器进行操作，如果这有什么不同的话。

实时警报和记录器警报通常被视为相同，因此我可能会在大多数时间处理所有警报，而不是以不同的方式处理记录器警报和实时警报。

记录器在位置表中具有相当特定的列。由于位置和记录器将是一对一的映射，我决定不使用单独的记录器表，到目前为止，它似乎工作得很好并保持简单。示例列：LoggerRFID (int)、LoggerUpperLimit (float)、LoggerLowerLimit (float) 等。您几乎可以争辩说记录器是传感器，但我沿着这条路走下去，结果并不好。

我几乎可以接受将警报设为通用，但正如其中一个答案所说，我正试图对此非常确定，因此在选择特定路径之前尽可能长时间地继续研究。

我正在建立一个数据库来存储与游戏相关的属性，例如它是否支持多人游戏、它是什么类型、发布日期等。

似乎为每个类别类型创建两个额外的表（例如，genres、genres_data）并没有像它应该的那样动态。我最初的想法是设置它的两种方式之一......

有一个包含骨架信息的游戏表，然后是一个列出所有属性的属性表，还有一个包含与游戏相关的所有数据的第三个表，其中基本上只使用与每个属性相关的列：

或者，让游戏表相同，并让属性包含列名，然后使用第三个表中的列：

在这种情况下，您有六种左右类型的数据与一行相关，但每个类别中有大量类别和支持属性，那么实际的方法是什么？为每种属性类型或类别（对我而言）制作表格似乎效率不高。

As sort of a follow up to this previous question: Normalizing a variety of properties with similar data types

I've created this setup now: http://schemabank.com/p/VwWHn

My question is am I on the right path with this method? Is there an obvious mistake to the setup I'm using, or something about the concepts of normalization I'm missing? I'm trying to go for a practical approach that works in real world scenarios, so if there is a better method to configure this database I'd be happy to hear it.

问：

我想要任何仅用于ERD和规范化培训的网站或书籍。我想要大量带有推荐答案的示例、实践和案例研究，以加强我在数据库设计方面的技能并避免我所做的糟糕的数据库设计。

笔记：我不需要书籍来解释这些概念，我需要的是带有推荐答案的实践、示例和案例研究。

提前致谢。

这是一个常见的面试问题。我面临一次面试，面试官给了我一张桌子，问我告诉他这张桌子是哪种正常形式？如果它在##NF 中，那么将其标准化为下一个 NF？

我总是对这些正常形式的数据库感到困惑。任何人都可以通过适当的示例向我解释这些正常形式，说明如何将每个 NF 建模为表格，以便在我的下一次面试中有所帮助？

我只是想知道其中哪一个更适合在 Web 应用程序中使用。我有一个网络应用程序，可让用户发布到该网站。有三种不同类型的帖子，但足够相似，我可以将它们放在一张桌子下。这样做可以吗？

我可以用这种方式规范化表格吗？（将 type 置于其中之一下）

表格1

表 2

或者使用一张桌子会更好吗？

桌子

我倾向于第三种方式，除非有人能指出缺点。

我有这样的数据集合

最初我将其标准化为两个表，如下所示

我想我想在另一张桌子上代表表演者，但不知道如何代表它。据我所知，存在以下关系

• 一对多：一个节目可以有很多表演者
• 一对多：表演者可以出现在许多节目中

我不确定我将如何表示这一点？

编辑 啊，我明白了，例如，我实际上会有这样的表格吗？