标签: normalization

我已经阅读了 1NF 的定义，即“如果关系的每个属性都是原子的”。请告诉我什么是原子。

数据库管理员您好。最近，我一直在阅读规范化以提高我的数据库设计技能。但是，我对何时应用此技术有些困惑。在学习规范化之前，我通常会阅读需求中的场景/描述并使用名词作为实体和动词作为它们关系的线索绘制 ER 图（使用陈氏符号），然后直接执行 SQL 语句以创建桌子。

目前在我看来，规范化是在设计 ER 图之后进行的，然后将其应用于包含多值属性的任何实体。

我的想法正确吗？或者我应该在创建 ER 图之前进行规范化，也许是在列出系统的可能属性之后？

在参考互联网和教科书时，我遇到了两种规范化程序。即。

类型 1。范式仅基于主键。

在这种类型中，

-> 2NF 不允许部分依赖于主键。

-> 3NF 不允许对主键的传递依赖。

类型 2。基于所有候选键的更通用的范式

在这种类型中，

考虑了所有候选键的部分依赖和传递依赖。

在我提到的大多数网站中，我找到了仅基于第一种类型的教程和注释。但是 Navathe 和 Elmasri 的教科书“数据库系统基础”描述了这两种类型。甚至维基百科关于 2NF 的页面也分别提到了基于第二种类型的“2NF 和候选键”。

参见2NF 和候选键 - Wiki

但是教科书和维基都没有提到关于哪种类型更好或哪种类型实际上更受欢迎的任何内容。

当没有提到类型时应该遵循哪种类型？希望你明白我的问题。

请帮我解决这些家伙。

如果有人知道 2NF，如果你能告诉我我对它的理解是否正确，我将不胜感激，我的书甚至没有提到它（除了说具有“历史意义”）而且我一直没能找到一个真正的网上的好例子。我正在学习测试，想知道我关于如何完成 2NF 分解的推理是否正确

R = {a, b, c, d, e, f, g} F = {AB --> C, A --> DE, B --> F, F --> GH, D --> IJ }

我做的第一件事是找到很容易看到的超级键 (AB)+ = R，但是我不确定这是否是 2NF 定义在使用术语“键”时的意思

第二，我使用了 AA 并在 F 中组合了一些术语（只是为了使其更易于管理）

F = {AB --> C, A --> DEIJ, B --> FGH}

第三，我删除了部分函数依赖我不太确定（我确实在没有 eval 的情况下查找过它）我认为 PFD 是什么我认为当你有一个 FD 时，在这种情况下，LHS 是超级键的一个适当的子集

A --> DEIJ 和 B --> FGH

第四，我将其分解为从步骤 3 中删除违规的关系

R1 = AB --> C

R2 = A --> …

我有一个大约有 40-50 个表的数据库。除了 5 个之外，所有其他人都是 1:M 关系的巨大层次结构的一部分，这些关系都指向一个单独的父级（称为“项目”）。每个表都使用父主键的外键连接到它的直接父表，主键是一个标识字段。一些分支深达 6 或 7 层。许多表有数百万行。几乎所有查询都需要返回与单个项目有关的特定表的所有记录。查询通常只返回有问题的单个实体的字段。因此，一个典型的查询（实际上除了随机临时查询之外的所有查询）看起来像这样：

SELECT a.* FROM a
JOIN b ON a.id=b.id
JOIN c ON b.id=c.id
JOIN d ON c.id=d.id
JOIN Project p ON d.ProjectID=p.ProjectID
WHERE p.ProjectID = 12345

可以想象，在层次结构中越往下走，查询的性能就越差。我考虑过仅通过在层次结构的所有级别中冗余地保留 ProjectID 字段，并在每个表中的 ProjectID 上创建聚集索引来对一个字段进行非规范化。这将使我能够通过单个索引查找满足所有数据请求。这样做可以显着提高查询性能。但是，我不知道这样做是否会对架构设计的保真度产生负面影响。我希望有人可以为我提供一些见解，以防我遗漏了什么。

我在为包含订单和发票的数据库建模时遇到问题。实际上，从业务的角度来看，这更像是一个问题，但它仍然与数据库建模有关。

Orders表的模型：

现在我有另一个名为 payment_deadline 的专栏，里面有付款截止日期。我在想的是，我的 Orders 表应该有什么信息，我的 Invoices 表应该有什么信息？

哪一个有员工和客户 ID？哪个有价格？哪一个有付款信息？哪一个有截止日期？我完全迷路了。

我了解在商业世界中，订单表示货物供应商必须采取行动，发票表示货物供应商已履行其职责，客户现在必须支付货物/服务费用。但是我不知道如何在数据库中对其进行建模。任何见解都非常感谢。

是否有可能完全摆脱所谓的“虚假元组”？

例如：在教科书中的这个例子中，有一个原始表：

我认为它的两个预测没有任何问题：

但是他们的加入仍然产生虚假的元组：

（这些数字来自ToddEverett 的回答。]

如果之前有人问过并回答过这个问题，请原谅我。

我正在粗略地制定一个库存管理系统的架构，将在 PostgreSQL 中实现。我们所有的产品和服务都有一个 SKU。我们的大部分产品来自制造商或分销商，并带有单独的“项目编号”（无论是分销商的目录号、制造商的型号，等等）。然而，并非所有人都有这样的数字。我们有内部制造的小组件，通常没有项目编号。我们的服务没有项目编号。由于这些原因，以下 CREATE TABLE 对我来说很有意义。

场景A：

CREATE TABLE product (
   sku            text PRIMARY KEY,
   name           text UNIQUE NOT NULL, -- alternate key
   price          numeric NOT NULL CHECK (price > 0),
   quantity       numeric NOT NULL CHECK (quantity > 0),
   item_number   text -- hmmm...
);

但是，我对此有两个问题。

1. 有时（可能有 3% 到 5% 的时间），item_number 实际上等于SKU。也就是说，我的一个供应商特别在他们的产品上贴上了我怀疑不是全球唯一的 SKU，按照他们的项目编号设计。

2. 无论是否等于 SKU，item_number（如果存在）在几乎所有情况下都足以唯一标识我的小商店域中的产品。

我担心将其标准化为 3NF。如果 item_number 有时为 null，则显然不能将其声明为备用键。但是，从语义上讲，它是一个唯一标识符，在我能想到的每种情况下都存在。那么我上面的表格，其中每个属性在功能上都依赖于非主要属性 item_number每当 item_number 存在时，是否标准化？我想不，但我当然不是专家。我想过做以下事情：

情景B

CREATE TABLE product (
   sku            text PRIMARY KEY REFERENCES …

我正在为投票应用程序设计一个数据库。用户可以回答一堆问题，然后我们将它们存储起来。

相关的 ERD 部分

我想存储每个问题的正确答案，以便我们可以检查他们是否正确回答了问题。

问题可以有不同的“类型”：

• 细绳
• 数字
• single_response
• 多重响应

我应该如何存储正确答案？

添加correct_answer到questions和options

加入只是一个correct_answer字段questions将不会在情况下，工作question有type multiple_reponse。我想过添加correct_answer到两者questions和optionswherequestions将有一个字符串或数字与正确的答案，并options会简单地得到一个trueor false。如果所有我们希望检查options与correct_answer设置为true被选中与否，如果一个option与correct_answer设置为false选择

创建一个名为的新表 correct_answer

添加 2 列：

• correct_answer
• options_id

然后检查是否设置了任何一个。我们必须correct_answer为每个option.

添加correct_answer到questions

我们可以使用type来确定如何阅读correct_answer，然后correct_answer直接检查或explode()以逗号分隔的option_id值来检查答案

我想知道哪个选项是最佳实践，或者是否有人有更好的主意。

我的整个 …

我一直教导将格式化数据存储在表格中是不正确的。例子包括：

+----------------+----+
| 数据 | 好的 |
+----------------+----+
| 0370101234 | ? |
+----------------+----+
| 03 7010 1234 | |
+----------------+----+
| (03) 7010 1234 | |
+----------------+----+

（为什么不支持表格？！）

数据是一个澳大利亚电话号码，通常有 10 位数字，包括区号。

包括格式间距或字符会引入歧义，因此更难排序或搜索。

问题是：标准或关系理论中有没有涵盖这个问题的内容？

编辑

这不是关于电话号码的问题。我用应该以最简单的形式存储的数据说明了一个点，即使它是用格式化字符显示的。

其他示例包括$显然从未与货币值一起存储的符号，以及有其自身问题的千位分隔符。