 |
|
登录注册 |
| ☦ 上海交通大学论坛 > 数据库 > 浏览当前帖子 | 手机版 关闭左侧栏 |
| 三个范式 |
| 【返回本版】 【发表帖子】 【回复帖子】 | 浏览量 4427 回帖数 0 |
 |
qaz 等级 ☆ 楼主 发表于 2011/7/5 2:58:43 编 辑 |
|
|
为什么使用范式？在那本著名的《面向对象设计与分析》里，是这样描述的： 为了避免在表格更新操作中逻辑的不一致性，每个范式在表格组织中禁止冗余的 表格，即如果一个表格被另外一个表格独立地更新，就会产生无意义的结果。范 式是多层次的线性规则，每高一层就增加了对下一层的范式的限制。如果要满足 更高的范式，意味着表格趋于更分裂，即表格越来越小。范式牺牲了导航的开销 和查询执行的速度，强调了数据库的一致性。不应该故意地违背范式规则，但是 可能因为性能的缘故偶尔违反。 在第一范式之前，我们要知道，范式是基于关系的，关系具有以下性质： 1.描述一个实体。 2.没有重复的行，因此必须有一个主键。 3.行和列是无序的（unordered）。 第一范式(First Normal Form)：all column values must be atomic。数据 库中表格不含多种属性。举例如下： 表格a:（主关键字为工厂名称和设备名称） －－ 工厂名称 设备名称 工厂经理 设备制造商 制造商地址 美菱 冷却器、加热器 李达 ABC合作社 北京路1号 荣事达 加热器 张养 ABC合作社 北京路1号 荣事达 水泵 王顺 XYZ水泵 天津路3号 －－ 在表格a的第一行设备名称有两个值，违反第一范式。修改我们采用纵向分解， 将其分成两行，使它满足第一范式。如下表： 表格b:（主关键字为工厂名称和设备名称） －－ 工厂名称 设备名称 工厂经理 设备制造商 制造商地址 美菱 冷却器 李达 ABC合作社 北京路1号 美菱 加热器 李达 ABC合作社 北京路1号 荣事达 加热器 张养 ABC合作社 北京路1号 海信 水泵 王顺 XYZ水泵 天津路3号 －－ 第二范式(2NF)：If it is in 1NF and every non-key column is fully dependent on the (entire) primary key. 表格满足第一范式，并且每个非关键字的属性域完全依 赖于全部的主关键字。每行有一个主关键字，主关键字可以是多个属性组成的，由此引发 第二范式的问题。为了不解释依赖的含义，呵呵，我们依然举例说明： 上面的表格b中，设备制造商和制造商地址完全依赖于主关键字，而工厂经理仅仅依 赖于部分主关键字（工厂名称），违背第二范式。修改：把部分依赖分到另一个表格当中， 使它满足第二范式。 表格c:（primary key工厂名称） －－ 工厂名称 工厂经理 美菱 李达 荣事达 张养 海信 王顺 －－ 表格d:（primary key工厂名称，设备名称） －－ 工厂名称 设备名称 设备制造商 制造商地址 美菱 冷却器 ABC合作社 北京路1号 美菱 加热器 ABC合作社 北京路1号 荣事达 加热器 ABC合作社 北京路1号 荣事达 水泵 XYZ水泵 天津路3号 －－ 第三范式(3NF)：If it is in 2NF and if all non-key columns are mutually independent. 表格满足第二范式并且每个非主关键字的属性不相互依赖，而是直接 依赖于主关键字。举例： 上面的表格d存在传递相关性，设备制造商直接依赖于主关键字，而制造商地址直接 依赖于设备制造商，违背第三范式。修改：分成两个表格，使它满足第三范式，最后得到 的表格设计结果如下三个表： 表格1:（primary key工厂名称，设备名称） －－ 工厂名称 设备名称 设备制造商 美菱 冷却器 ABC合作社 美菱 加热器 ABC合作社 荣事达 加热器 ABC合作社 海信 水泵 XYZ水泵 －－ 表格2:（primary key设备制造商） －－ 设备制造商 制造商地址 ABC合作社 北京路1号 XYZ水泵 天津路3号 －－ 表格3:（primary key工厂名称） －－ 工厂名称 工厂经理 美菱 李达 荣事达 张养 海信 王顺 －－ 呵呵，举一反三，3NF范式差不多就是这样的吧。 |
||
| 1 |
| 论坛帮助 会员认证删帖申请 联系我们 |