34,590
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
wuguangyao 2002-11-14
- 打赏
- 举报
wu_07(BLUETLCK)老大贴的很棒，看了之后茅塞顿开，可惜的是3NF的例子没有贴完啊，好像看看哪
cl2002 2002-11-14
- 打赏
- 举报
谢了！！
wu_07 2002-11-12
- 打赏
- 举报
一范式
一个数据结构，首先要考虑是否达到“一范式”（1-NF）。如果一个数据结构含有多值项（即“不平坦项”），就说它是非一范式的；将它分解，移除其多值项另设一表，即可达到一范式。
例1. 职工档案（工号，姓名，出生时间，受奖情况，...）。
其中，“受奖情况”即为多值项，包括“受奖时间”和“受奖称号”两项内容。
通常设计这种职工档案的数据结构方法有二：
一是“横向冗余”法，即多设几个受奖项目，如“受奖时间１”和“受奖称号１”，“受奖时间２”和“受奖称号２”，“受奖时间３”和“受奖称号３”，等等；
二是“纵向冗余”法，即只有一个“受奖时间”和“受奖称号”，一个人如有三次受奖，则记成三行，后面两行除“受奖时间”和“受奖称号”外，其它完全重复第一行的信息。这都是不好的方法。
科学的方法是，移出“受奖情况”成一个新表，这样就有如下的一范式数据模型：
职工档案（基本信息）
*工号 姓名 出生时间 ...
职工受奖情况
*工号 *受奖时间 受奖称号
该模型中的第一个表，由“工号”作为唯一识别每一行数据的标识，称为“主码”（或“主键”）；第二个表由“工号”加上“受奖时间”作为每一行数据的唯一标识，是一种由两个数据元素组成的“主码”。因为，一个人可能有多次受奖，所以由上表到下表是“一对多”关系；而多个受奖记录可能是属于一个人的，即由下表到上表对应是“多对一”的关系。
二范式
其次，是考虑一个数据结构是否达到“二范式（2-NF）”。如果数据结构中非主码元素不完全依赖于整个主码（即含有“不完全依赖性”），则说它是非二范式的；将之进一步分解，作到每个非主码元素都完全依赖于主码，即达到二范式。
例２. 一初学者搞出的企业部门人员登记表的数据结构如下：
*部门号 *职工号 工种 工资 部门负责人
它的主码定义为“部门号”加上“职工号”，这就有许多问题：
“工种”、“工资”仅仅依赖“职工号”，即部分依赖于主码；“部门负责人”仅仅依赖于“部门号”，也是部分依赖于主码，所以是非二范式的。
经过优化后，得出下面的二范式模型：
*部门号 部门负责人
*部门号 *职工号
*职工号 工种 工资
这里有一个有趣的现象是：第二个表的两个数据元素都列为主码，除此之外再无“非主码元素”。这是允许的，而且在关系型数据库中是常见的，它表明了两个表的关系，在这里是表明每个部门中都有哪些职工。
三范式
第三，要考虑一个数据结构是否达到“三范式（3-NF）”。如果数据结构中有的非主码元素依赖于另一个非主码元素，即为非三范式。这种依赖现象也称为“传递依赖”，因为，如果 Ａ→Ｂ，Ｂ→Ｃ， 那么Ｂ就起到中间“传球手”的作用了，这是一种不好的结构。在二范式的基础上消除这种传递依赖，就达到了三范式。
例3.有的统计数据结构含有一些“计算项”，实际上，在组织数据存储时是不必要的。
一个数据结构，首先要考虑是否达到“一范式”（1-NF）。如果一个数据结构含有多值项（即“不平坦项”），就说它是非一范式的；将它分解，移除其多值项另设一表，即可达到一范式。
例1. 职工档案（工号，姓名，出生时间，受奖情况，...）。
其中，“受奖情况”即为多值项，包括“受奖时间”和“受奖称号”两项内容。
通常设计这种职工档案的数据结构方法有二：
一是“横向冗余”法，即多设几个受奖项目，如“受奖时间１”和“受奖称号１”，“受奖时间２”和“受奖称号２”，“受奖时间３”和“受奖称号３”，等等；
二是“纵向冗余”法，即只有一个“受奖时间”和“受奖称号”，一个人如有三次受奖，则记成三行，后面两行除“受奖时间”和“受奖称号”外，其它完全重复第一行的信息。这都是不好的方法。
科学的方法是，移出“受奖情况”成一个新表，这样就有如下的一范式数据模型：
职工档案（基本信息）
*工号 姓名 出生时间 ...
职工受奖情况
*工号 *受奖时间 受奖称号
该模型中的第一个表，由“工号”作为唯一识别每一行数据的标识，称为“主码”（或“主键”）；第二个表由“工号”加上“受奖时间”作为每一行数据的唯一标识，是一种由两个数据元素组成的“主码”。因为，一个人可能有多次受奖，所以由上表到下表是“一对多”关系；而多个受奖记录可能是属于一个人的，即由下表到上表对应是“多对一”的关系。
二范式
其次，是考虑一个数据结构是否达到“二范式（2-NF）”。如果数据结构中非主码元素不完全依赖于整个主码（即含有“不完全依赖性”），则说它是非二范式的；将之进一步分解，作到每个非主码元素都完全依赖于主码，即达到二范式。
例２. 一初学者搞出的企业部门人员登记表的数据结构如下：
*部门号 *职工号 工种 工资 部门负责人
它的主码定义为“部门号”加上“职工号”，这就有许多问题：
“工种”、“工资”仅仅依赖“职工号”，即部分依赖于主码；“部门负责人”仅仅依赖于“部门号”，也是部分依赖于主码，所以是非二范式的。
经过优化后，得出下面的二范式模型：
*部门号 部门负责人
*部门号 *职工号
*职工号 工种 工资
这里有一个有趣的现象是：第二个表的两个数据元素都列为主码，除此之外再无“非主码元素”。这是允许的，而且在关系型数据库中是常见的，它表明了两个表的关系，在这里是表明每个部门中都有哪些职工。
三范式
第三，要考虑一个数据结构是否达到“三范式（3-NF）”。如果数据结构中有的非主码元素依赖于另一个非主码元素，即为非三范式。这种依赖现象也称为“传递依赖”，因为，如果 Ａ→Ｂ，Ｂ→Ｃ， 那么Ｂ就起到中间“传球手”的作用了，这是一种不好的结构。在二范式的基础上消除这种传递依赖，就达到了三范式。
例3.有的统计数据结构含有一些“计算项”，实际上，在组织数据存储时是不必要的。
