|
登录注册 |
☦ 上海交通大学论坛 > 数据库 > 浏览当前帖子 | 手机版 关闭左侧栏 |
三个范式 |
【返回本版】 【发表帖子】 【回复帖子】 | 浏览量 4424 回帖数 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 |
论坛帮助 会员认证删帖申请 联系我们 |