34,576
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
feilniu 2010-05-23
- 打赏
- 举报
范式是为了消除冗余，防止数据不一致。但考虑JOIN操作的性能成本，有些高负载高可用性要求高的系统会进行“反范式”的设计，从而减少查询时需要的联接操作，提高性能，但同时也需要在程序中合理地处理更新问题，人工防止出现数据不一致。
具体的设计，需要根据系统的具体需求来权衡。
具体的设计，需要根据系统的具体需求来权衡。
feilniu 2010-05-23
- 打赏
- 举报
答案1楼以给出，不多说了。
对于我们现在用的关系数据库，关系理论当然非常重要。否则设计出的表可能包含大量冗余，并且容易出现数据不一致。
事实上，范式就是DRY原则在数据库设计方面的一个表现。（DRY, Don't Repeat Yourself. 参看《程序员修炼之道》）
纯理论的东西可以不深究（当然理解更好，看个人兴趣和能力），在应用上主要记住3点：
1NF：表中所有字段都是原子的。
即列是查询处理的最小单位，不需要拆分字段。
比如员工表中的字段PhoneNumbers，包含'号码1,号码2'这样的多值。如果该字段只是记录信息，不需要对单独号码进行处理，这并不违背1NF；反之，统计对单独的号码进行查询处理，则PhoneNumbers不是原子的，需要拆分。
2NF：表要有主键，并且表中所有字段均完全依赖于主键。
即一个完整的主键就决定（代表）一行记录。
完全依赖的反面是部分依赖。比如用户权限表的主键是(用户ID, 权限ID)，如果该表中包含用户名（只依赖于用户ID）或权限描述（只依赖于权限ID）的字段，则违背2NF。
3NF：除主键外，表中其它字段之间不存在依赖关系。
比如产品表中包含两个字段类别ID和类别名称，其中类别名称依赖于类别ID，则该表违背3NF。
对于我们现在用的关系数据库，关系理论当然非常重要。否则设计出的表可能包含大量冗余，并且容易出现数据不一致。
事实上，范式就是DRY原则在数据库设计方面的一个表现。（DRY, Don't Repeat Yourself. 参看《程序员修炼之道》）
纯理论的东西可以不深究（当然理解更好，看个人兴趣和能力），在应用上主要记住3点：
1NF：表中所有字段都是原子的。
即列是查询处理的最小单位，不需要拆分字段。
比如员工表中的字段PhoneNumbers，包含'号码1,号码2'这样的多值。如果该字段只是记录信息，不需要对单独号码进行处理，这并不违背1NF；反之，统计对单独的号码进行查询处理，则PhoneNumbers不是原子的，需要拆分。
2NF：表要有主键，并且表中所有字段均完全依赖于主键。
即一个完整的主键就决定（代表）一行记录。
完全依赖的反面是部分依赖。比如用户权限表的主键是(用户ID, 权限ID)，如果该表中包含用户名（只依赖于用户ID）或权限描述（只依赖于权限ID）的字段，则违背2NF。
3NF：除主键外，表中其它字段之间不存在依赖关系。
比如产品表中包含两个字段类别ID和类别名称，其中类别名称依赖于类别ID，则该表违背3NF。
挨踢直男 2010-05-23
- 打赏
- 举报
看数据库书籍的时候 关系理论那些章节简直就是看天书一样
这些东西 对于数据库的应用 重要吗?
这些东西 对于数据库的应用 重要吗?
feixianxxx 2010-05-23
- 打赏
- 举报
R的候选码
CD 是候选码
3NF
r1(C D)
r2(C B)
r3(B A )
CD 是候选码
3NF
r1(C D)
r2(C B)
r3(B A )
