标签: database-normalization

考虑一下这个表:

   +-------+-------+-------+-------+  
   | name  |hobby1 |hobby2 |hobby3 |  
   +-------+-------+-------+-------+   
   | kris  | ball  | swim  | dance |  
   | james | eat   | sing  | sleep |  
   | amy   | swim  | eat   | watch |  
   +-------+-------+-------+-------+

爱好的类型没有优先权,因此所有的爱好都属于同一个领域.也就是说,表格中的爱好可以在任何hobby#列上移动.无论哪一列,特定的爱好都可以在任何列中.

该表违反了哪个数据库规范化规则？

编辑

问:"业余爱好列表是否按任意顺序"？

答:是的.

问:表格有主键吗？

答:是的,假设密钥是一个AUTO_INCREMENT名为的列类型user_id.

问题是列hobby#是否重复组.

旁注:这不是作业.这是一种辩论,它始于 SQL问题的评论 - 基于几个列将记录从一个表匹配到另一个表.我相信这个问题是违反1NF的明显例子.

然而,另一个人认为我" 已经堕落了1NF的谬误之一. "这个论点是基于" 关于第一范式的事实和谬误 "的"重复群体的模糊性" 一节.

我不是写这个来羞辱他,我或任何人.我写这篇文章,因为我可能错了,而且我有一些东西显然是错过的,也许这个家伙并没有对我说好.

我对这些的非正式表述是：

1NF：表格被划分，以便任何项目都不会出现多次。

2NF：我需要一个明确的定义

3NF：值只能由主键确定。

我无法从网上或书中找到的摘录中理解它。如何区分 1NF 和 2NF？

我想存储用户关注者和关注成员列表。现在为了这个，我正在考虑在 USER 表中创建两列，即 FOLLOWING 和 FOLLOWER 来分别存储下面和跟随者的逗号分隔值。

USER TABLE FIELDS:

userid
firstname
lastname
date_of_birth
following   //in this we store multiple following_id as comma separated
follower    //in this we store multiple follower_id as comma separated

另一种方法是创建表 FOLLOWER 和 FOLLOWING 来存储用户的关注者和关注成员 id。

USER TABLE FIELDS:

userid
firstname
lastname
date_of_birth

和

FOLLOWER TABLE FIELDS:

userid
follower_id (also is an user)

和

FOLLOWING TABLE FIELDS:

userid
following_id (also is an user)

由于我正在学习数据库设计，所以我的知识不够。那么，在这里我不知道哪种方式是正确的？我搜索过使用逗号分隔的方式不是一个好主意，但同时它是使用 NF 拥有多个表的好方法吗？使用 JOINS 有什么缺点吗？或者有没有其他有效的方法来处理这种情况？

我正在网上学习网络开发文凭,我刚刚进入数据库设计和开发.我以为我理解了普通形式,但我刚刚达成了一个让我陷入困境的问题.

查看以下客户实体的属性列表:

Customer(cus_ID, name, address, mobile_phone)

Run Code Online (Sandbox Code Playgroud)

为什么这个实体不在3NF？

据我所知,这是在3NF.如果不是客户,名称,地址和移动数据集要求客户存在,那么所有属性都不会存在.

我是否只是错误地了解了3NF的整个概念？

他们中的任何一个都暗示另一个吗？

我的逻辑是，如果保留所有依赖项，则不会丢失信息，同样，如果分解是无损的，则一定不会违反功能依赖项。

所以本质上，依赖保留是一种确保您的分解无损的方法。

我很难接受/拒绝它。那么这两者是相互保证的，还是有一种情况可以在没有另一个的情况下实现？

MySQL支持JSON 数据类型。它是否违反了字段原子性的1NF 规则？如果不是，那么它的合理性如何？

我正与另一位数据库设计师就规范化问题进行有趣的讨论.在这个例子中,我们有一个GameTitles表,每个记录必须包含游戏发布的年份.他说2NF强制要求所有内容都必须标准化,因此,为了符合要求,应将year字段拆分为具有自己的主键的ReleaseYears表,该主键由GameTitles表引用.我说它应该保留为GameTitles表本身的一个字段.

我的论点是,一年只是一个非原始的数值,就其本质而言是静态的(即,2011年将永远是2011年).因此,它作为自己的标识符,不需要任何引用它,因为它就是它.这还引入了额外的维护,因为您现在必须在表中添加新年才引用它.如果您在很长一段时间内预填充表格,那么您将拥有可能根本不会引用它们的额外记录.这也增加了数据库大小,因为您现在有一个额外的表,记录开销以及年份本身的额外主键.如果您将年份保留为GameTitles表中的字段,则可以消除所有这些额外的维护和开销.

对此的想法？

为简单起见,假设我的数据库有两个表,视频和用户.视频是不同视频的列表,用户是不同用户的列表.

我需要能够记录用户何时观看某个视频,所以当他们再次观看视频时,我可以让他们知道他们已经看过了.

信息:可能会有数十万用户可能会有数十万个视频.

我想到这样做的一种方法是为每个视频创建一个表,或者为每个用户创建一个表(两者都会产生数十万个表).

另一种方法是创建一个中性表,其中包含:userID(外键),videoID(外键).但是,我认为这会影响效率(和规范化),因为存在多值依赖关系,或两列中相同userID和videoID的倍数.

我仍然是数据库的新手,我觉得我错过了一些简单的东西.任何帮助将不胜感激.

我正在使用MySQL.

这里的目标是能够查询数据库为它提供一个旅的基础上,旅数据库将返回所有的停止代码通过这次旅程中运行.

因此,例如,我需要能够说,"选择贯穿34行程的所有停止代码".这应该只返回STOP CODE:SZDASDASDE.(在生产中将返回更多代码).

在上面,您可以看到数据库中第一个表的图像.

您还可以看到第二个表,其中每个STOP CODE都有许多JOURNEYS作为父项.据我所知,将多个旅程放入单个字段并不遵循标准数据库设计,所以如果有人可以帮我修复,我会非常感激.

这些图像是在微软的Excel中拍摄的,只是为了计划我将如何做到这一点,生产将使用MySQL数据库.

谢谢

我对标准化（3NF）有一个快速的问题。如果我有一个表定义为...

客户（用户名，名字，姓氏，年龄，性别，种族）

和用户名确定名字，姓氏，年龄，性别，种族

但是..为了便于讨论，我们还可以假定firstName，lastName可用于唯一标识表中的行，因此firstName，lastName确定用户名，年龄，性别，种族

是3NF中的表，因为某些非主要属性（firstName，lastName）可用于确定表中的其他属性，但是PK（用户名）可以确定非主要属性，然后将其用于确定其他属性。

我知道由于循环依赖问题，这不在BCNF中，但我希望至少在3NF中存在。

在此先感谢您的帮助。