 |
|
登录注册 |
| ☦ 上海交通大学论坛 > 数据库 > 浏览当前帖子 | 手机版 关闭左侧栏 |
| 我的错误，菜菜鸟们注意更正 |
| 【返回本版】 【发表帖子】 【回复帖子】 | 浏览量 4190 回帖数 1 |
 |
不能超过 等级 ☆ 楼主 发表于 2011/7/3 10:25:07 编 辑 |
|
|
在《菜鸟对菜菜鸟说...》中，我的确犯了错误 现在我手头有一本《SQL Server 7.0开发指南》，Stephen Wynkoop,电子 工业出版社。里面有非常简单的对范式的描述，对照一下，发现我对第一范式 的理解的确是错了。 october_y的《三个范式》里描述的是正确的，即：字段的属性是唯一的。 因为我们平时做表的时候，这一条很自然地就满足了所以我对它也就没怎么在 乎，时间长了，就记成“记录唯一”了请菜菜鸟们注意更正。 至于第二范式，这本书里描述的的和我原来写的是一样的，即：每行都可 被唯一识别。通常也就是加id的做法。但是它没有要求字段依赖于主关键字 （october_y描述中要求）。我想，这里是不是认为，加了id做主关键字，由 主关键字来标识记录。那么其它字段自然就依赖id这个标识了呢？如果主关键 字不是人为加的id序号，而是原有的字段本身那么我们是不是也可以说字段也 都自然依赖主关键字呢？ 关于第三范式，我觉得我的描述“一个或几个字段相同，就不会有其它的字 段也相同”，在实质上与october_y描述的一样。他描述的是：非关键字字段仅依 赖于主关键字，而不相互依赖其它非主关键字。在满足2NF以后，如果两条记录 中的某一个或几个字段相同，假设非关键字字段存在相互依赖的话，那么依赖于 这“某一个或几个字段”的字段也必然相同，就不满足3NF。而这本书里的描述是 “符合3NF时，表中就不会有多余的已在其它表中包含的非关键字信息”，意思也 是一样的。 在某些时候，由于我写这篇文章是写给入门者看的，所以我尽量不使用一些 术语，也不使用严格的数学证明（实际上，我也记不住，需要查书，呵呵...）。 对于数学意义一样的东西，从不同的角度描述，得到的定义也是会不一样的。 非常感谢大家对我的纠正，希望这种良好的讨论氛围继续下去，在将来我写 东西的时候，希望同样也能得到大家的指点。谢谢！ |
||
 |
兵临城下 等级 ☆ 2 楼 发表于 2016/3/2 3:09:39 编 辑 |
|
|
> ==> Senglit_Yang(蜥蜴少校) 说道 > 被唯一识别。通常也就是加id的做法。但是它没有要求字段依赖于主关键字 > （october_y描述中要求）。我想，这里是不是认为，加了id做主关键字，由 > 主关键字来标识记录。那么其它字段自然就依赖id这个标识了呢？如果主关键 > 字不是人为加的id序号，而是原有的字段本身那么我们是不是也可以说字段也 > 都自然依赖主关键字呢？ 纯粹从关系模型的角度来说，好像id不是很受欢迎，关系数据库理论强调数 据是基于属性值上查找和操纵，而id不算是属性值当中的好孩子，:)。ID好像是 对象模型中引入的，作为对象的唯一标识符，它符合面向对象设计的规则，在对 象模型的对象图表示中，这个对象ID好像仍然是不显式地描述的，因为它对用户 来说通常是没有意义的。 对于第二范式，我觉得仅仅靠ID唯一标识仍然是不够的，呵呵。从你举的例 子出发，是可以的，但是如果表格中存在描述本对象与另一个对象之间关联的信 息，这时候可能需要用两个id作主键，这样就存在部分依赖和完全依赖的区别了。 比如在你的第三范式的例子当中，如果允许一个人在多个部门工作，就得考虑这 个了，而且这样你的那个例子就成为第二范式的例子了。 > 关于第三范式，我觉得我的描述“一个或几个字段相同，就不会有其它的字 > 段也相同”，在实质上与october_y描述的一样。他描述的是：非关键字字段仅依 > 赖于主关键字，而不相互依赖其它非主关键字。在满足2NF以后，如果两条记录 > 中的某一个或几个字段相同，假设非关键字字段存在相互依赖的话，那么依赖于 > 这“某一个或几个字段”的字段也必然相同，就不满足3NF。而这本书里的描述是 > “符合3NF时，表中就不会有多余的已在其它表中包含的非关键字信息”，意思也 > 是一样的。 我觉得你描述第三范式的这句话不是很明确，呵呵，两条记录到底在几个字段 的值相同之后，才不允许再有其它的字段相同？因为你的前提条件是一个或者几个， 你应该定义好这几个到底是什么。就像你举的那个例子，tbinfo中dept信息用了两 个字段来表示，为什么要把deptid留下，把dept独立出来，怎么样叫描述性的信息？ 我保证这两个字段的值相同的记录不再有其它字段的值相同不是也满足吗？呵呵。 -- > ==> October_Y(可复用weird) 说道 > 纯粹从关系模型的角度来说，好像id不是很受欢迎，关系数据库理论强调数 > 据是基于属性值上查找和操纵，而id不算是属性值当中的好孩子，:)。ID好像是 > 对象模型中引入的，作为对象的唯一标识符，它符合面向对象设计的规则，在对 > 象模型的对象图表示中，这个对象ID好像仍然是不显式地描述的，因为它对用户 > 来说通常是没有意义的。 > 对于第二范式，我觉得仅仅靠ID唯一标识仍然是不够的，呵呵。从你举的例 > 子出发，是可以的，但是如果表格中存在描述本对象与另一个对象之间关联的信 > 息，这时候可能需要用两个id作主键，这样就存在部分依赖和完全依赖的区别了。 > 比如在你的第三范式的例子当中，如果允许一个人在多个部门工作，就得考虑这 > 个了，而且这样你的那个例子就成为第二范式的例子了。 加id的确不是个好方法，至少是多了一个字段信息，而这个字段信息并非 是用户想处理的信息。但是从广意上来讲，现实世界中，就有很多数据是自带一个 id的，例如工号、学好、发票编号等等。如果需要处理的数据已经自然带有一个id, 或者说是能唯一标识它自身的主关键字，那么自然就不用再另加id了。否则的话， 为了满足第二范式，必须要给记录添加一个主关键字，至于它的名字叫不叫id，那都 无所谓了。 > 我觉得你描述第三范式的这句话不是很明确，呵呵，两条记录到底在几个字段 > 的值相同之后，才不允许再有其它的字段相同？因为你的前提条件是一个或者几个， > 你应该定义好这几个到底是什么。就像你举的那个例子，tbinfo中dept信息用了两 > 个字段来表示，为什么要把deptid留下，把dept独立出来，怎么样叫描述性的信息？ > 我保证这两个字段的值相同的记录不再有其它字段的值相同不是也满足吗？呵呵。 所谓的“一个或者几个”，指的就是非主关键字信息中，假如记录集合b 依赖于记录集合a，那么a就是那“一个或者几个”。至于是“一个”或者“几个” 就要看实际数据中，a集合的大小了。如果b依赖于a的话，那么只要两个记录中的 a相同，b必然也相同。在那个例子中，dept是依赖于deptid的，考虑到输入的笔 误等因素，我不能说deptid相同，dept就一定相同。但是从数据的意义上分析，我们 可以说，deptid相同，dept就一定存在相同的可能性，这跟第三范式要求的“一定 没有其它相同”是违背的。至于把dept独立出去，而不是把deptid独立出去，是 因为考虑到deptid的引入本身就是用来标识dept的，那么显然就应该是dept依赖 于deptid，所以把dept独立出去。如果倒过来的话，如果保证dept存储过程中不会 出现“财务处”、“财会处”这种现象，我们也可以认为是deptid依赖于dept， 而把deptid独立出去。但如果这样的话，deptid的引入就失去了意义，反而给数据 处理带来了麻烦。这里考虑的“相同”或者“不相同”指的是“存在相同的可能性” 和“不存在相同的可能性”，而不是是已经存储的数据中有相同的还是没有相同的。 你当然可以输入一些记录，故意让它不相同，但是你不能保证数据库将要存储的 数据这些字段都不相同。事实上，假如b依赖于a，那么a相同的时候，b相同这是 必然的，b不相同是偶然的，这个偶然由输入错误、定义混乱等因素引入。 |
||
| 1 |
| 论坛帮助 会员认证删帖申请 联系我们 |