<font color=red>没人愿意讨论一下数据库的“第三范式”吗？ </font> (100分)

好象大家都不乐意。谁说论坛不能讨论复杂问题的？

我觉得主要还有一个效率的问题，如果严格按照第三番是的话
太麻烦了

3nf是传递依赖的问题吧
表中有一个定义在其他列的非主列需要考虑使用3NF
理解的话还是要从2NF出发
要符合2NF同时不存在“传递依赖”
到是还想了解点4NF 5NF或BCNF什么的

找本《数据库原理》看看就知道啦！

在论坛上不太适合讨论这么复杂的问题，一句两句讲不清楚，我可以讲一下我自已的体会：
供你参考：
1、不要凡事总是从3NF的概念去出发考虑问题，这样比较累。
2、学习一些如：“语义对象”或“ERM（实体-联系模型）”的分析设计方法，最好先了解
概念，再试做，没有工具用草纸就行。
3、各种方法实际上是殊途同归，但重要的是哪种方法最易上手和最易软件及文档维护。

这么说各位是不乐意讨论这个问题喽？

douh的意思应该是不要为了理论而理论吧
就象做中间件，如果从那些示例出发是很困难的
具体商业规则的结构化应用还是很费细胞的
如果能从一些角度讨论出新的MIS思维
那在国内当今的MID“引用”应该是很不错的了
难道我们就MIS而MIS？
我想这也是大富翁为什么不是CSDN的原因吧

COW，兄弟想的那么复杂干吗？我就是想学点东西嘛。。。
别告诉我3NF和社会主义建设、马列主义有关。

房客之言是也
如果大富翁仅仅讨论一些细节问题，我也不会上这儿来

吴剑明误解我的意思了，我是说除了范式分析方法之外还有诸如：“语义对象”或
“ERM（实体-联系模型）”、“IDEF”等等方法，其中除了范式分析最费脑细胞，其
它的方法都直接面向应用，不一定最终严格要符合那个范式，但这些设计方法在其它方面
各有千秋，如提高设计效率、降低项目风险等等，千万不要被范式理论困死。
——个人理解

补充一下：如果讨论NF问题的话，最好找一些数学家。这可是纯逻辑问题啊！
要是想讨论一下对不同设计方法的认识，我想听！

理论联系实际

第一范式为：如果一个关系（表）不包含重复组就称它是第一范式（1NF）的。
例：
订单号 订货日期 货号 订货数量 货物描述
12489 9/02/98 AX12 11 洗衣机
12491 9/03/98 BT04 1 冰箱
BZ66 3 电视机
12494 9/04/98 CX11 4 VCD
为非规范关系，将其改为
订单号 订货日期 货号 订货数量 货物描述
12489 9/02/98 AX12 11 洗衣机
12491 9/03/98 BT04 1 冰箱
12491 9/03/98 BZ66 3 电视机
12494 9/04/98 CX11 4 VCD
就转换为满足1NF的表
如果一个关系（表）是第一范式的，并且没有非关键字只依赖于主关键字的一部分，
就称它为第二范式(2NF)的。上表主关键字为（订单号 货号）
将上表变为
（订单号 订货日期 ）
（ 货号 货物描述 ）
（订单号 货号 订货数量）
三个表后，就满足2NF
如果上面第一个表再多两个字段为
（订单号 订货日期 订货人代码 订货人姓名）
显然，订单号决定了所有其他的属性（即只要知道订单号，就可知其它字段的值）
所以订单号为主关键字段，并且满足2NF（主关键字只有一列，该表就自动为2NF）
但是仍然存在冗余问题。如下：
订单号 订货日期 订货人代码 订货人姓名
12489 9/02/98 03 陈强
12491 9/03/98 04 张明
12492 9/03/98 04 张明
12494 9/04/98 07 李伟
如果一个关系（表）是第二范式的，并且它所包含的决定者都是侯选关键字，那么就称它为
第三范式(3NF)的。
（任何可以决定其他属性的属性或属性集合被称为决定者）如上表有二个决定者
订单号和订货人代码，但订货人代码不是候选关键字（它不能做主关键字）
（候选关键字是一个具有和主关键字同样性质的属性的集合。即可用它做主关键字）
将上表改为
（订单号 订货日期 订货人代码）
（订货人代码 订货人姓名）二个表后，就满足3NF。

接受答案了.