问题标签 [database-normalization]

假设我的数据库跟踪鸟类观察（注意：我真的在刮桶底部的例子）。

这些字段是：

虽然我假设公园总是在同一个位置，但该网站就像一个电子表格。用户输入park_name和location为每个条目。另请注意，我的实际模式还有其他依赖于类似“公园名称”的字段（例如状态）。

我没有办法让用户预定义公园，所以我无法提前知道它们。我是否应该尝试动态规范化这些数据？例如，我的程序是否应该自动填充一个parks表，将观鸟表中的 park_name 和 location 列替换为park_id?

我主要担心性能。列出每个目击事件需要一个连接来填充公园和位置。此外，动态管理这几乎肯定需要比它节省的更多资源。我可能需要一个 Cron 工作来消除孤儿公园，因为它们可能会在多次目击中被引用。

如果这是一个荒谬的问题，请道歉；

我到处寻找答案，但无济于事。

我知道如何计算最小覆盖率；

即确保每个功能依赖在 RHS 上只有一个属性，通过计算每个检查所有 FD 的闭包来移除多余/冗余的 lhs 属性，看看是否可以移除任何（再次通过计算闭包）

“规范”封面只是同一件事的另一个词吗？

我有下表，应该将其转换为 2NF。

在我去过的地方，我有一个答案：

技能：员工，技能

地点：员工，当前工作地点

我有一种感觉我错了这个^上面^虽然。

也有人可以解释1NF，2NF和3NF之间的区别。我知道 1 是第一位的，你必须把它分解成更小的表格，但想要一个非常好的描述来帮助我更好地理解。谢谢

我是个jr。开发人员（工作 5 个月），我有一个关于数据规范化的问题。现在，据我了解，数据规范化背后的一般原则是创建一个 RDBMS，将​​数据冗余保持在最低限度。在我的项目中，其中一位 DB 人员创建了一个 DB。我们有 50 多个表，数据库中的表通常非常零散，即。一张表有两三列，就是这样。现在，当涉及到编写 sql 查询时，它已成为一个小麻烦，因为每个查询都涉及梳理几个不同的表并将它们连接在一起。我想知道这是否是数据规范化的副作用？或者这是否指向别的东西？

我知道对我来说最简单的事情就是根据我必须编写的查询来编写表。这将创建一个包含大量冗余数据的数据库，但我很好奇是否有一个快乐的媒介？

就像附言一样，我不想让人觉得我在抱怨我的工作，但我真的很想了解更多关于这个的信息。我的工作环境不是最友好的，所以我不愿意和同事提出这个问题。但是，如果有经验丰富的人提供任何想法、书籍、教程或意见，我将不胜感激。

谢谢。

我想创建一个费用跟踪应用程序，每个用户都可以在其中输入费用并将其分类到自己的类别中。这是我使用的模型定义：

每个类别都必须与一个用户相关联，以便我们可以在输入费用时向每个用户显示他自己的类别以供选择。出于类似的原因，每个费用记录都应该与一个用户相关联。但是在费用的定义中，我们有两个对用户模型的引用，一个直接通过“用户”字段，另一个通过具有用户参考的“类别”字段。

我相信像这样的多次引用是一件坏事。有没有更好的方法来建模这个？我知道我们可以从类别参考中找到用户，但这似乎是一种迂回的方式。

我有一个满足以下关系的表：

我需要把它分解为第二范式，所以我{AB->HI}, {D->FG}, {E->MN}分成独立的表。但是怎么样{J->KL}？我应该如何规范这个？

做一些数据库思考，并有一个基本表，例如链接表。链接可以有一个指向帐户对象/记录的外键。但是，为了简单和抽象（例如，将链接视为基于内容的资源），我想我会通过通用查找表（例如，称为lookups，不account_links或link_accounts）将链接分配给帐户。

虽然链接只能分配给一个帐户（并且必须始终分配给一个帐户），但内在的我想要创建那个外键。

但我真的很喜欢抽象出一个对象/数据资源并解耦它的上下文的概念（例如，它被分配给一个帐户，或一个用户，或其他什么）。

如果有人得到他们，将不胜感激：）

模式：

链接：

查找：

我正在建立一个在线商店。商店有几个类别（~10），类别有几个产品（每个~10），产品有很多子产品（每个20+）。

这是我陷入困境的部分：

子产品有几列详细信息。这些产品还有 10 个接头。

这是一个产品的样子：

http://www.ampedwebdesign.com/bear/new2/public/products/images/straightpins.jpg

标题是深色背景的单元格，子产品是行。

这是我的头类的一部分：

产品视图调用产品类来显示图像。产品视图然后调用标头类以按 product_id 返回标头。产品视图然后调用子产品类通过product_id返回子产品。产品视图然后调用子产品类以在 foreach 循环中返回子产品详细信息。

任何帮助将不胜感激，当我知道有更好的方法时，我讨厌编写这样的代码。我只是不知道如何找到它。

我的数据库表：产品、子产品、类别、标题

我是否应该规范用户profile_image_url链接和字段，例如profile_background_color用户可以自定义他们的个人资料？

拥有一个包含所有内容的 User 类。

或三班

在规模、性能、修改方面哪个更好？

我的问题是：

1）如果我有关系R(A,B,C)，作为AB主键，并且F = {}，我可以假设C取决于AB？我会说不，但我只是想确定一下。

2) 我想当然地认为AB -> CDE这与说AB -> C,和说AB -> D,是一样的。我对吗？AB -> EAB -> CEAB -> D

3) 取R(A,B,C,D)，作为AB的主键F = {AB->C}。这是在2NF吗？我会说不，因为D不依赖于任何其他属性，更不用说主键了！

4）我试图了解是否与

作为KL主键

R在2NF或中3NF。两者P和都N依赖于（虽然是间接的）整个主键。在里面就够了2NF吗？如果是，我会说不R在，3NF因为关系上的非主要属性之间不应该存在依赖3NF关系，对吧？

谢谢