《[计算机软件及应用]第5讲 需求分析阶段-规范化》由会员分享，可在线阅读，更多相关《[计算机软件及应用]第5讲 需求分析阶段-规范化（41页珍藏版）》请在金锄头文库上搜索。
1、数据库系统设计,需求分析阶段规范化,概述,虽然一个数据模型有效地沟通了数据库需求，但它不一定就代表了一个好的数据库设计，其中的某些结构特征可能会降低模型的灵活性和扩展性，或者产生不必要的冗余。所以，我们必须为数据库设计和实现准备好具有完整属性的数据模型。 好的数据模型的标准 好的数据模型是简单的。 好的数据模型基本上是无冗余的。 好的数据模型应该是灵活的而且对未来的需求具有可适应性。,概述,考虑以下的实体定义： course registration=course registration number(PK)+ course registration date+ student id num
2、ber(FK)+ student name+ student major+ 一个或多个course number,概述,好的数据模型是简单的。 作为一条通用规则，描述任何实体的数据属性应该仅仅描述那个实体。 属性student name和student major真的描述了course registration（课程注册）的一个实例吗？ 或者它们仅仅描述了一个不同的实体，即student? 同样的理由可以应用到属性student id number上。 经过进一步考察，student id number属性仍是需要的，它用来“指出”对应的student实体实例。,概述,好的数据模型是简单的。
3、简单性的另一个方面是这样陈述的： 一个实体实例的每个属性只能有一个值。 再看前的例子： 对应一个course registration实体，属性course number可以多个有值供学生选择。,概述,好的数据模型基本上是无冗余的。 这意味着每个数据属性（除了外键）最多在一个实体中描述。 在前面的例子中，发现属性student name和student major实际上描述一个student实体并不困难。故合乎逻辑的选择将是添加student实体。 在数据模型中还可能存在更细微的冗余，例如，相同的属性可能以不同的名称（同义词）被多次记录。,概述,好的数据模型应该是灵活的而且对未来的需求具有可适
4、应性。 没有这条评价准则，我们往往会设计仅实现目前业务需求的数据库。 然后，当一个新的需求产生时，我们若不重写许多或者所有使用那些数据库的程序就无法方便地修改数据库。 虽然我们不能改变这个现实-大多数项目都是应用驱动的，但是我们可以使数据模型做到尽可能地与应用无关，以鼓励采用不影响当前程序扩展或修改的数据库结构。,概述,数据分析：是为将数据模型实现成数据库而改进数据模型的技术。 数据分析是为实现简单的、无冗余的、灵活的并可扩展的数据库而准备数据模型的过程。其专门的技术称为规范化。 规范化：是一种数据分析技术，该技术组织数据属性怪便它们可以组合起来形成无冗余的 、稳定的、灵活的并具有适应性的实体
5、 规范化是一种包括三个步骤的技术，该技术把数据模型规范成1NF、2NF和3NF。 所有的范式都是基于表中的列之间的关系的。,概述,规范化理论是研究如何将一个不好的关系模式转化为好的关系模式的理论，规范化理论是围绕范式而建立的。 规范化理论认为，一个关系数据库中所有的关系，都应满足一定的规范(约束条件)。 规范化理论把关系应满足的规范要求分为几级，满足最低要求的一级叫做第一范式(1NF)，在第一范式的基础上提出了第二范式(2NF)，在第二范式的基础上又提出了第三范式(3NF)，以后又提出了BCNF范式，4NF，5NF。 范式的等级越高，应满足的约束集条件也越严格。规范的每一级别都依赖于它的前一级
6、别，例如若一个关系模式满足2NF，则一定满足1NF。,数据冗余和更新异常,更新异常 引起数据冗余的错误的结构化表的问题叫做更新异常 错误的结构化表可能产生于最初的ER模型或在将ER模型转化成表时出现错误。 有冗余数据的表可能有的问题叫做更新异常，它分为插入、删除和更改异常,数据冗余和更新异常,数据应该尽可能少地冗余，这意味着重复数据应该减少到最少 比如，一个部门雇员的电话就不应该被存储在不同的表中， 因为这里的电话号码是雇员的一个属性。 如果存在过多的冗余数据，这就意味着要占用了更多的物理空间，同时也对数据的维护和一致性检查带来了问题 当这个员工的电话号码变化时，冗余数据会导致对多个表的更新动
7、作，如果有一个表不幸被忽略了，那么就可能导致数据的不一致性。 关系数据库设计的主要目的是把列分组成表，以便最小化数据冗余并减少基表所需的文件存储空间,数据冗余和更新异常,StaffBranch表,冗余数据，因为分公司的细节信息在分公司的每个员工那里被重复了一遍,PK,数据冗余和更新异常,为说明与数据冗余有关的问题，我们来进行个比较：,只有分公司编号被重复,每个分公司的详细信息只出现一次,更新异常插入异常,有两种主要的插入异常 潜在的不一致性。为了插入一新员工到StaffBranch表中，必须包括分公司的详细信息，这个信息决定新员工所属的分公司。而在输入时无法保证输入的信息不出错。,StaffB
8、ranch表,StaffBranch表,如，要插入在B003分公司工作的新员工，必须输入B003分公司的正确的细节情况使得与StaffBranch表中其他分公司的记录信息一致。,更新异常插入异常,避免不一致性问题出现,此时就不存在潜在的不一致性，因为对于每一个员工我们仅需加入正确的分公司号到Staff表中就可以了。 另外，B003分公司在Branch表中作为单独的记录在数据库中仅记录一次。,更新异常插入异常,有两种主要的插入异常 违反实体完整性。如果要在StaffBranch表中插入一个新的，目前还没有员工的分公司的详细信息，需要在与员工有关的列，如staffNo，输入空值，但由于StaffN
9、o在StaffBranch表中是主键，输入null给StaffNo就违反了实体完整性，因此，不允许为空。这就违反了实体完整性。,StaffBranch表,StaffBranch表,更新异常插入异常,避免违反实体完整性问题出现,Staff表和Branch表的设计就避免了这个问题的出现，因为在Branch表中插入分公司情况与员工内容是分开的，在有了分公司之后，就可以在以后插入员工到Staff表中。,更新异常删除异常,如果从StaffBranch表中删除一个记录，而它又是一个分公司的最后一名员工（或唯一的一名），那么关于该分公司的有关信息也被从数据库中删除了。,StaffBranch表,例如，如果我
10、们从StaffBranch表中删除员工S0415的记录，那么与B003分公司相关的情况也从数据库丢失了。,更新异常删除异常,避免出现删除异常,Staff表和Branch表的设计就避免了这个问题的出现，因为在Branch表中插入的分公司情况与员工内容是分开的，仅仅是用BranchNo列把两个表关联起来。 如果从Staff表中删除员工S0415的记录，那么B003分公司的情况在Branch表中依旧存在，不受影响,更新异常更新异常,如果想要改变表中一个特定分公司的一个列的值，如分公司B001的电话号码，就必须更改在那个分公司的所有员工的记录。如果此次更改没有在该表中的所有记录正确进行，那么数据库就变
11、得不一致了。,StaffBranch表,从而会出现分公司的不同员工有不同的电话号码的问题。,更新异常删除异常,避免出现更新异常,Staff表和Branch表的设计就避免了这个问题的出现，因为此时只需要更新Branch表中分公司的电话号码就可以了。,第一范式（1NF）,First Normal Form，1NF 对于关系数据库来说，只有第一范式（1NF）在创建适当的表中是关键的。所有接下来的范式都是可选的。 实体的所有属性对于实体的单个实例都只具有一个值。 每个列和记录包含一个且仅含一个值的表 实体的所有属性对于实体的单个实例（记录）都只具有一个值。 任何可以有多个值的属性实际上描述了一个独立的
12、实体，也可能是一个实体和关系,第一范式（1NF） Branch表不是1NF的一个例子：,Branch表的主键为BranchNo。可以看到BranchNo表中除了TelNo列之外，其他的列都遵守1NF的定义，因为对于每一个记录的TelNo列有多个值。 如，分公司号为B001的分公司有三个电话电码，因此Branch表不属于1NF。,第一范式（1NF） 将Branch表转换为1NF：,为了把Branch表转换成1NF，我们创建一个单独的表，叫做BranchTelephone，此表用来保存分公司的电话电码。此表是把TelNo列从Branch表中去掉，同时把Branch表的主键复制到新表中。新表Bran
13、chTelephone的主键是TelNo。从而得到两个1NF的表，因为符合每一个表的每一个记录的每一列都有单独的值这一标准,第二范式（2NF）,Second Normal Form,2NF 2NF只应用于具有复合主键的表 具有单列主键的表自动成为2NF 不属于2NF的表可能会有更新异常问题 一个1NF的表，在该表中的每个非主键列的值都可以由组成主键的全部的列的确定 实体的所有非主键属性的值都依赖于主键 任何仅仅部分依赖主键的非主键属性应该被移到另一个实体中。这可能需要在模型中创建一个新实体和关系。,第二范式（2NF） TempStaffAllocation表不是2NF,将TempStaffAl
14、location表 转换为 2NF,第三范式（3NF）,Third Normal Form,3NF 一个已经是第一和第二范式的表，并且所有的非主键的值都只可以从主键列得到，而不能从其它的列得到。 实体已经是2NF 实体的非主键属性的值不依赖于任何其它非主键属性 任何依赖于其它非主键属性的非主键属性必须去掉或删除 新的实体和关系可能要被加到新的数据模型中,StaffBranch 表不是3NF,将StaffBranch 表转换成 3NF,NF、NF和NF总结,如果每个非主键属性都依赖于主键（整个主键），而且除了主键以外再不依赖于任何属性，这个实体就被称为是第三范式的。,规范化步骤,专门订单文档模型
15、,仔细检查专门订单文档，会注意到两种情况，在这两种情况中，单个专门订单实例中同样的属性捕获多个值。第一种违反是客户书的爱好，就是那种客户喜欢看的书。属性的复数形式让我们以为每个订单的实例包含了很多种不同爱好，就时爱好就是重复属性。需要建立一个新的包含更多爱好信息的实体去解决这个问题，还要在专门订单和爱好之间添加一个关系。此外，专门订单文档捕获了单个专门订单中多本书的信息这也违反了1NF，这时，每当下一次订单，关于书本的一组信息就会被重复记录。这被叫做组重复，它可以通过创建一个叫书的实体并把所有关于该书的属性放入其中来解决问题。,第一范式,规范化步骤,第二范式要求模型首先是第一范式，还要求数据模
16、型的实体包含依赖于整个主键的属性。这意味着所有作为主键的属性值可以决定实体的一个实例中所有其他属性的值。有时非主键属性只依赖于部分主键（如，部分依赖），这些属性属于其他实体。,注意到在最初，专门订单实体有个用作主键的属性：订单日期、客户姓和客户名。问题在于有一些属性依赖客户的姓和名，但是不依赖于专门订单日期。为了解决这个问题，一个叫客户的新实体被创建，客户的属性都移到新实体中，客户和专门订单之间存在1:N的关系。 同时注意到，我们把与爱好有关的关系移到了新的客户实体。逻辑上说，爱好应该和客户相关联，而不是与专门订单。,第二范式,规范化步骤,第三范式出现在当一个模型是第一范式又是第二范式，并且最终的实体中没有一个属性依赖非主键属性时（如，传递依赖）。,第三范式,书实体的问题在于作者的大学依赖作者，而不是ISBN。换句话说，知道一本书的ISBN，你并不能自动知道作者当前的大学但你
