标签: normalization

我正在创建一个书签系统，人们可以在其中保存他们的书签。每个用户都有自己的带有书签的个人页面。书签应至少有一个标签，最多五个。每个用户可以创建无限的书签/标签。

我创建了以下表格：

User
----
Id
Email


Bookmark
--------
Id
UserId
Title
Url


Tag
---
Id
UserId
Title
Description


TagBookmark
-----------
TagId
BookmarkId

这是正常化了吗？或者我应该采取不同的做法？对于一百万个书签来说，这会表现良好吗？

我也不确定是否应该重用现有的书签/标签。

示例1：

User1 和 User2 都创建书签“ http://google.com ”。我应该将其保存为一个书签吗？或者为每个用户单独保存它们？

示例2：

User1 和 User2 都创建标签“search-engine”。我应该将其另存为一个标签吗？或者为每个用户单独保存它们？

如果我不在用户之间重复使用书签和标签，这些表可能会变得相当大。

我非常仔细地问过表设计师为什么他选择在多个表中创建 CSV 列。

设计师的回答是，将 CSV 列拆分为单独的表是“不必要的复杂”。

在隐式连接中使用一个 CSV 列来计算 CSV 列中众多值中的一个值已被使用的次数。

where绑定两个表的原因使用了一个like % | table_b.csv_column | %操作。

我阅读并了解到，如果有充分的理由，并不总是需要规范化。
但是，我不知道什么是不正常化的充分理由。

这是（避免“复杂化”）不强制执行第一范式（1NF）的一个很好的理由吗？

桌子： TB_DISASTER_CAUSE_CATE

CATEGORY_ID   CATEGORY_N CATEGORY_L L
------------- ---------- ---------- -
DC006001002   ****                3 Y
DC006001003   ****                3 Y
DC006002001   ****                3 Y
DC007001001   ****                3 Y
DC007002001   ****                3 Y
DC007002002   ****                3 Y
DC007003001   ****                3 Y
DC007003002   ****                3 Y
DC007003003   ****                3 Y

桌子： TB_DISASTER_HISTORY

SEQ DISASTER_TYPE DISASTER_CAUSE                                             
----- ------------- ------------------------------------------------------------
   32 DT001003002   DC001001004|DC002001002|DC003001001|DC007002001 …

TLDR；以下场景的最佳设计选择是什么，每个设计在极大数据量下会如何反应？

我有使用大型政府数据库系统服务 24/7 数据收集、处理和报告的经验。浏览所有不同设计的模式并了解所有这些不同的人设计的所有这些功能如何以某种方式混杂成一个有效的解决方案是很有趣的。就像我相信你们中的一些人知道的那样，有趣的戳时间是一种奢侈，而且大多数周期都是务实的，让系统保持活力而不是改进设计。

我一直在建模一个新的数据库系统，并想对如何关联这些实体有一些想法。

场景：客户、雇主和从业者需要电话号码。

我们有四个实体：

• CLIENT
• EMPLOYER
• PRACTITIONER
• PHONE

电话号码按用于接听电话的技术进行分类，所使用的技术通知数据格式限制。

• 座机
• 传真
• 移动的

描述字段指示电话的主要用途；家庭、工作等。

关联这些实体的方法

1. 反规范化PHONE为CLIENT, EMPLOYER,PRACTITIONER

让我们从糟糕的设计开始，然后从那里开始。去规范化所有的电话号码！

• 3 个实体，没有关系
• 如果需要新电话号码，则必须创建新列；导致CLIENT.Phone1Number, EMPLOYER.Phone2Type, PRACTITIONER.Phone3Description;
• 或限制可以为每个实体输入的电话号码数量
• 冗余，大量开销
• 进行批量更新或维护会变得乏味

结论：select * from 'no_thanks';

2.建造第n座桥；重命名数据库匹兹堡

对于可以关联电话号码的每个实体，创建一个桥实体将它们组合在一起。

• 7 个实体，6 个关系
• 数据冗余；电话号码填充在多个位置
• 仅PhoneNumber在需要时可以使用桥接表；不需要 JOIN 即可PHONE
• 如果新实体FAMILYMEMBER需要电话号码，则必须创建新的桥接表

结论：也许，取决于维持关系的难度

3. 一个准“星图”

修改PHONE以包含CLIENT.ClientID, EMPLOYER.EmployerID, 的外键 …

我正在为我的数据库考试复习一些过去的论文，它问：

指定 R 的所有最小键

R(A,B,C,D,E)
A ? B
CD ? E
E ? A
B ? D

我不确定最小键是什么意思，我试过在谷歌上搜索它，但它只提供了最小的超级键。它是否仅意味着最短的候选键：CD、CA、CE、CB？

我很困惑，因为在每个问题中他都使用了不同的名称，据我所知，最小超级键是候选键？

我一直在阅读 Connolly 和 Begg 的“数据库系统：设计、实施和管理的实用方法”以了解数据库规范化（第 14 章）。我现在更好地理解了三种数据库规范化形式：

• 第一范式 (1NF)
• 第二范式 (2NF)
• 第三范式 (3NF)

我也了解三个更新异常：

• 插入异常
• 删除异常
• 更新/修改异常

我现在正在努力理解的是如何将两者联系在一起。例如，哪些不同的形式有助于修复插入异常？其他异常也类似。理想情况下，我想知道这两个组之间的映射关系以及为什么这些形式会修复某些异常。

这是我在这里的第一个问题，我在谷歌和这个网站上搜索，试图首先找到答案，但无济于事。

谢谢你。

总的来说，我知道即使有加入成本，规范化通常也是有益的。然而，我最近想到了一个有趣的困境。

如果数据重复但不太可能改变怎么办。这是可能的，但我不会预料到。

我有一个nutrients表，一unit列和单位将g，kg，ug，等。

我看不到这些值每次都在变化。

我很想将它们作为表中的一列，而不是规范化并拥有一个units表并使用外键并且在从nutrients表中获取一行时必须加入。同时，我知道总的来说，即使有加入币，我们也应该正常化。

我应该怎么做（以及为什么）？

鉴于R[c, f, g, h, e, j, a, b, d, i]与以下功能依赖项的关系，我提出了以下解决方案。但是，我不确定它，R8即使它具有某些 LHS，也没有列出的函数依赖项。我按照分解成 BCNF 的说明进行操作，但我不确定这是正确的解决方案吗？

功能依赖

a ? b
{ c, a } ? d
c ? e
f ? { g, h, i, j }

解决方案

In BCNF:
R1[f, g, h, i, j]
R3[a, b]
R5[c, a, d]
R7[c, e]
R8[c, f, a]

我相信这个关系/表是第一范式（1NF）：

集合（cd_id，标题，标签，艺术家，类型，国家，song_id，song_title，长度）

注意：粗体表示键。

我设法确定的内容：

{cd_id, song_id} ? {song_title, length}
{cd_id} ? {title, label, artist, type, country}

• 这是正确的，说它满足1NF是否正确？
• 我是否缺少更多的功能依赖项？

额外细节

所涉及的属性/列的上下文信息和/或样本值：

• CD_id：009329
• 标题：CD的标题
• 艺术家：镍背
• 类型：团体 | 独奏
• 国家/地区：引用艺术家的国家或地区
• Song_title: "把它烧到地上"
• 时长：3:32 分钟

附加功能

一张CD下的每首歌，意味着会有重复。每次添加属于 CD 的歌曲。

我发现 Hugh Darwen 为避免我的数据库中的空值而写的这篇论文：链接，它描述了如何以第 6 范式实现数据库，以便您可以避免空值。语言教程 D 中描述了逻辑。我了解如何将所有这些逻辑转换为 SQL Server。但是在最后他展示了在当前的数据库管理系统中可以很好地实现这一点，然后我看到了我需要实现的部分：

• 重组查询：可以完成，但可能执行得很糟糕。最好将 PERS_INFO 存储为一个单独的表，以便分解产生的表可以作为到它的映射来实现。但是当前的技术并没有将物理存储与逻辑设计完全分开。也许是下一代软件工程师需要解决的问题？

它建议将 PERS_INFO 存储为一个单独的表，但这到底意味着什么？我将如何在 SQL Server 中实现它？

我和我的同事正在讨论数据库中描述性特征的规范化，例如“状态”或“类型”。让我们将讨论的中心表称为“订单”。

在我的常规设计方法中，我会定义另一个表“OrderStatus”来描述订单的状态，然后在“Order”表上创建一个具有关系的外键，即“OrderStatusID”。

这会给我参考完整性。我可以随时加入状态，并且我的可能值始终存在于“OrderStatus”表中。

我的同事不喜欢这种标准化程度，因此他将在“Order”表上定义一个 varchar 字段“OrderStatus”。该字段将直接包含值。

status 的可能值在他的应用程序中定义，更具体地说，在 OrderStatuses 的枚举中定义，因此，除非我可以访问所述应用程序的源代码，否则我无法使用。

我习惯于将数据库的整个上下文作为关系和表存在于数据库中，并且不得不编写“WHERE OrderStatus = 'Sold'”而不是“WHERE OrderStatusID = 3”让我感到烦恼。

怎么想？我正在寻找两种方法的优点和缺点，但我主要关注性能和可读性/可维护性。