标签: database-normalization

我已经阅读了不同的教程并看到了标准化的不同例子,特别是第一范式中"重复组"的概念.从他们那里我已经认识到,重复的群体是"有点"的多值属性(例如这里和这里).

但是,在将ERM(实体关系模型)映射到RDM(关系数据模型)的过程中,我们已经通过在父表中包含外键来为每个多值属性创建单独的表？参考:这个

其次,那些"重复组"基本上是在同一行中水平排列,还是可以在同一列中反复出现相同的值,即一次又一次地出现属性的相同值,也是一个重复的组,应该被消除？

在此示例中,英语值一次又一次地重复.这是一个重复的群体吗？如果我删除它以使用Subject Name和Module_ID(外键)创建另一个表SUBJECT,这就是我得到的.当然它摆脱了重复的价值,但我不确定这是否是正确的.这样对吗？

Haskell如何解决"规范化的不可变数据结构"问题？

例如,让我们考虑代表前女友/男朋友的数据结构:

data Man = Man {name ::String, exes::[Woman]}

data Woman = Woman {name :: String, exes::[Man]}

如果一个女人改变她的名字并且她和13个男人在一起会怎么样？然后所有13个人都应该"更新"(在Haskell意义上)？需要某种规范化来避免这些"更新".

这是一个非常简单的例子,但想象一个具有20个实体的模型,以及它们之间的任意关系,那么该做什么呢？

在不可变语言中表示复杂的规范化数据的推荐方法是什么？

例如,可以在此处找到Scala解决方案(请参阅下面的代码),它使用引用.在Haskell可以做些什么

class RefTo[V](val target: ModelRO[V], val updated: V => AnyRef) {
  def apply() = target()
}

我想知道,如果像上面的那些(在Scala中)更通用的解决方案在Haskell中不起作用或者它们不是必需的吗？如果它们不起作用,为什么不呢？我试图搜索在Haskell中执行此操作的库,但它们似乎不存在.

换句话说,如果我想在Haskell中建模规范化的SQL数据库(例如与酸状态一起使用),是否有一种描述外键的通用方法？一般来说,我的意思是,不要按照以下评论中chepner的建议手工编码ID.

编辑:

换句话说,是否存在一个库(用于Haskell或Scala)在内存中实现SQL /关系数据库(可能还使用事件源来实现持久性),这样数据库是不可变的和大多数SQL操作(查询/连接/插入/删除/等.)是否已实现并且是类型安全的？如果没有这样的图书馆,为什么不呢？这似乎是个不错的主意.我该如何创建这样的库？

编辑2:

一些相关链接:

• https://realm.io/news/slug-peter-livesey-managing-consistency-immutable-models/
• https://tonyhb.gitbooks.io/redux-without-profanity/content/normalizer.html
• https://github.com/agentm/project-m36
• https://github.com/scalapenos/stamina
• http://www.haskellforall.com/2014/12/a-very-general-api-for-relational-joins.html

给出以下星型模式表.

• 事实上,两个维度,两个措施.

#   geog_abb  time_date amount     value
#1:       AL 2013-03-26  55.57 9113.3898
#2:       CO 2011-06-28  19.25 9846.6468
#3:       MI 2012-05-15  94.87 4762.5398
#4:       SC 2013-01-22  29.84  649.7681
#5:       ND 2014-12-03  37.05 6419.0224

• 地理维度,单层次结构,层次结构中的3个级别.

#   geog_abb  geog_name geog_division_name geog_region_name
#1:       AK     Alaska            Pacific             West
#2:       AL    Alabama East South Central            South
#3:       AR   Arkansas West South Central            South
#4:       AZ    Arizona           Mountain             West
#5:       CA California            Pacific             West

• 时间维度,两个层次结构,每个层次结构4个级别.

#    time_date time_weekday time_week time_month time_month_name time_quarter time_quarter_name time_year
#1: 2010-01-01       Friday …

我们要求每秒存储500次测量,来自多个设备.每个度量由时间戳,数量类型和几个向量值组成.现在每次测量有8个矢量值,我们可能会认为这个数字对于原型项目的需求是恒定的.我们正在使用HNibernate.测试是在SQLite(磁盘文件db,而不是内存)中完成的,但生产可能是MsSQL.

我们的Measurement实体类是包含单个度量的类,如下所示:

public class Measurement
{
    public virtual Guid Id { get; private set; }
    public virtual Device Device { get; private set; }
    public virtual Timestamp Timestamp { get; private set; }
    public virtual IList<VectorValue> Vectors { get; private set; }
}

矢量值存储在单独的表中,以便它们中的每一个通过外键引用其父测量值.

我们已经做了几件事情,以确保生成的SQL(合理)高效:我们正在使用Guid.Comb生成的ID,我们正在冲洗在一个事务中约500项,ADO.Net批量大小设置为100(我认为SQLIte不支持批量更新？但以后可能会有用).

问题

现在我们可以每秒插入150-200个测量值(这还不够快,尽管这是我们正在讨论的SQLite).查看生成的SQL,我们可以看到在单个事务中插入(按预期):

• 1个时间戳
• 1测量
• 8个矢量值

这意味着我们实际上要多做10倍的单表插入:每秒1500-2000.

如果我们将所有内容(所有8个向量值和时间戳)放入测量表(添加9个专用列),似乎我们可以将插入速度提高10倍.

切换到SQL服务器将提高性能,但我们想知道是否有办法避免与数据库组织方式相关的不必要的性能成本.

[编辑]

对于内存中的SQLite,我得到大约350项/秒(3500个单表插入),我相信它与NHibernate一样好(以此帖子作为参考:http://ayende.com/Blog/archive/ 2009/08/22/nhibernate-perf-tricks.aspx).

但我不妨切换到SQL服务器并停止假设,对吧？我会在测试后立即更新我的帖子.

[更新]

我已经转移到SQL服务器并使我的层次结构扁平化,我通过存储3000次测量/秒几个小时来测试它,它似乎工作正常.

假设我在数据库上有两个表,T ₁₀和T ₁₁,分别有10和11列,其中10列在两者上完全相同.

我违反了什么(如果有的话)规范化规则？

我和我的朋友正在建立一个网站并且存在重大分歧.该网站的核心是一个关于"人"的评论数据库.基本上人们可以输入评论,他们可以进入评论的人.然后,查看者可以在数据库中搜索注释中的单词或人名的部分内容.它完全由用户生成.例如,如果有人想对一个人姓名的拼错版本发表评论,他们可以,那就没问题.因此,可能有多个不同人的拼写被列为几个不同的条目(一些具有中间名,一些具有昵称,一些具有错误,等等),但这一切都可以.我们不在乎人们是否对随机人或想象的人做出评论.

无论如何,问题在于我们如何构建数据库.现在它只是一个表,注释ID作为主键,然后有一个关于评论的'人'的字段:

评论ID - 评论 - 人

1 - "他很奇怪" - 约翰史密斯

2 - "臭女孩" - 珍妮

3 - "同性恋" - 约翰史密斯

4 - "欠我20美元" - Jennyyyyyyyyy

一切都很好.使用数据库,我能够创建列出特定"人"的所有"评论"的页面.但是,他痴迷于数据库没有规范化.我读到了规范化并得知他错了.表IS当前已标准化,因为评论ID是唯一的并且指示"评论"和"人".现在他坚持认为'人'应该拥有自己的桌子,因为它是一个"东西".我不认为这是必要的,因为即使'人'真的是更大的容器(一个'人'可以对它们有很多'评论'),数据库似乎运行得很好,'人'是一个属性评论ID.我使用各种PHP调用来进行不同的SQL选择,使其在输出上神奇地显得更加复杂,以及用户可以搜索和查看结果的不同方式,但实际上,设置非常简单.我现在让用户用竖起大拇指向下评论评论,并在同一张桌子上保留一个"得分"作为另一个字段.

我觉得目前没有必要为独特的"人"条目设置单独的表格,因为"人"没有自己的"分数"或任何属性.只有评论.我的朋友是如此坚强,以至于效率是必要的.最后我说,"好吧,如果你想让我创建一个单独的表,让'人'成为它自己的领域,那么第二个字段是什么？因为如果一个表只有一个列,那似乎毫无意义.我同意我们以后可能会创建一个需要给'人'自己的桌子,但我们可以处理它." 然后他说字符串不能是主键,我们会将当前表中的'人'转换成数字,而数字将是新'人'表中的主键.对我来说,这似乎是不必要的,这将使当前的表更难阅读.他还认为以后创建第二张表是不可能的,而且我们现在需要预测到以后我们可能会需要它.

谁是对的？

鉴于一个数据库系统处理员工,客户和供应商,所有这些都有多个可能的电话号码,您将如何以良好的标准化方式存储这些数字？我有一点思考,合乎逻辑的方式并没有跳出来.

我正在从网上完成规范化练习,以测试我的数据规范化能力.这个特殊问题发现于:https://cs.senecac.on.ca/~dbs201/pages/Normalization_Practice.htm(练习1)

这个问题的基础表如下:

可以从此表创建的非标准化表是:

为了符合First Normal表单,我必须通过将visitdate,procedure_no和procedure_name移动到它们各自的表来摆脱表中的重复字段:

这也符合2NF和3NF,这使我怀疑我是否正确执行了标准化过程.如果我没有从UNF正确地搬到1NF,请提供反馈.

我是数据库设计的新手,我已经阅读了很多关于规范化的内容.如果我有三张桌子:住宿,火车站和机场.我是否在每个表中都有地址列或其他表引用的地址表？是否存在过度规范化的问题？

谢谢

我面临以下问题.我有一张非常大的桌子.此表是以前参与该项目的人员的遗产.该表位于MS SQL Server中.

该表具有以下属性:

1. 它有大约300列.它们都有"文本"类型,但其中一些最终应该代表其他类型(例如,整数或日期时间).因此,必须在使用它们之前将这些文本值转换为适当的类型
2. 该表有超过100毫米的行.桌子的空间很快就会达到1TB
3. 该表没有任何索引
4. 该表没有任何实现的分区机制.

正如您可能猜到的,无法对此表运行任何合理的查询.现在人们只在表中插入新记录,但没有人使用它.所以我需要对其进行重组.我计划创建一个新结构,并使用旧表中的数据重新填充新结构.显然,我将实施分区,但这不是唯一要做的事情.

该表最重要的特征之一是那些纯文本字段(即它们不必转换成另一种类型)通常具有频繁重复的值.因此,给定列中实际值的变化范围为5-30个不同的值.这导致了进行规范化的想法:对于每个这样的文本列,我将创建一个附加表,其中包含可能出现在此列中的所有不同值的列表,然后我将在此附加表中创建一个(tinyint)主键,然后将在原始表中使用适当的外键,而不是将这些文本值保留在原始表中.然后我将在这个外键列上放一个索引.以这种方式处理的列数约为100.

它提出了以下问题:

1. 这种标准化真的会增加这些100个领域中某些领域的条件速度吗？如果我们忘记了保留这些列所需的大小,那么由于初始文本列与tinyint-columns的替换,是否会增加性能？如果我不进行任何规范化并简单地在这些初始文本列上放置索引,那么性能是否与计划的tinyint-column上的索引相同？
2. 如果我执行所描述的规范化,那么构建一个显示文本值的视图将需要将我的主表加入大约100个附加表.一个积极的时刻是我将为对"主键"="外键"进行那些连接.但是仍然应该加入相当多的表.这是一个问题:对此视图的查询性能是否与初始非规范化表的查询性能相比是否会更差？SQL Server Optimizer是否真的能够以允许规范化的优势的方式优化查询？

抱歉这么长的文字.

感谢您的评论!

PS我创建了一个关于加入100个表的相关问题; 加入100张桌子