管理信息系统第07章.pptVIP

范式 1NF 若一个关系R的所有属性都是原子属性，则该关系属于第一范式，记作R∈1NF。此处所谓的原子属性是指按照应用的目的不需要再细分的属性。第一范式的条件，保证了相应的关系能够在数据库管理系统中实现。 2NF 若关系R∈1NF，且R中不存在非主属性对码的部分函数依赖，则称R∈2NF。 范式 3NF 若关系R∈2NF，且R中不存在非主属性对非主属性函数依赖，则称R∈3NF。 BCNF 若关系R中任何非平凡函数依赖的左面均包含了R的一个码，则称关系R∈BCNF。 若一个关系属于高级范式，则一定属于更低级的范式。 关系的规范化 将关系由低级范式转化为高级范式的过程叫做关系的规范化。规范化的过程是一个按一定规则对关系进行投影或拆分的过程，即将一个关系，分解为几个更小的关系。 将第一范式规范化为第二范式 如果一个关系是第一范式，但不是第二范式，则按照下述规则进行投影或拆分，可以将其转化为第二范式： ①拆分时要破坏非主属性对码的部分函数依赖。即这样的几个属性不能同时出现在一个关系中。 ②不丢失属性。即分解后得到的几个更小的关系中，应该包括原关系的所有属性。 ③维持原有数据间的关系。通过对拆分后得到的关系的连接，可以完全复原为原来的关系。 将1NF规范为2NF示例 学生（学号，姓名，性别，专业编号，专业名称，课程编号，课程名称，成绩） 上述关系的码是学号和课程编号，非主属性姓名依赖于学号，部分依赖于码，因此该关系模式不属于2NF。 按拆分规则，将其拆分为以下几个关系模式： 学生（学号，姓名，性别，专业编号，专业名称） 学习成绩（学号，课程编号，成绩） 课程（课程编号，课程名称） 以上关系属于2NF 将第二范式规范化为第三范式 如果一个关系是第二范式，但不是第三范式，则按照下述规则进行投影或拆分，可以将其转化为第三范式： ①拆分时要破坏非主属性之间的函数依赖关系。即这样的几个属性不能同时出现在一个关系中。 ②不丢失属性。即分解后得到的几个更小的关系中，应该包括原关系的所有属性。 ③维持原有数据间的关系。通过对拆分后得到的关系的连接，可以完全复原为原来的关系。 将2NF规范为3NF示例 学生（学号，姓名，性别，专业编号，专业名称）属于2NF，但不属于3NF 可进一步拆分为： 学生（学号，姓名，性别，专业编号） 专业（专业编号，专业名称） 均属于3NF 面向对象设计方法的数据库设计 面向对象方法中的类图模型与结构化方法中的ER图在本质上是一致的，因此，可以在类图的基础上进行关系型数据库模式的设计。 需要永久保留其状态，并在将来可被提取使用的对象被称为持久对象（Persistent Object）。对象的状态可以保存到关系数据库中。一个简单对象对应关系数据库的一条记录。 用关系数据库保存对象状态的方法 将对象保存到关系型数据库中，有两种方法： 映射法（Mapping）：对每一个类做额外的编程，把对象映射到数据库的表中。 模拟法：将面向对象的应用系统移到关系型数据库中实施，以关系表的形式来模拟对象。 在实际应用中主要采用映射法。将类映射到表；将属性映射成字段；再映射关联、聚集和组成。 将类映射到表 从类图来看，将类映射到表有三种基本的形式：一对一、一对多和多对多。 要实现一对一和一对多的关系，只需要将一张表的主键包括在另一张表中作为外键。关联还可以分为单向关联和双向的关联。 对于多对多关系，需要新创建一个关联表。用于在关系型数据库中维护两个或多个表之间的关联，在类图中表现为添加一个关联类实来现多对多关系。 类映射到关系时对继承的处理方法 整个类层次结构使用一张表 类层次结构中所有类的所有属性都存储在一张表中 每个具体类使用一张表 所建立的每张表既包含它本身的属性，又包含它所表示的类继承的属性，并分别分配各自的主键。对于抽象类不建立表。 每个类使用一张表 为每个类创建一张表，其属性包括主键和特定于该类的所有属性。 将属性映射成字段 注意点： 并不是所有属性都是需要映射为字段。 某些属性本身可能就是一个对象，其对应的类本身就映射成一张表； 还有可能将类中的几个属性映射成表中的一个字段。 映射关联、聚集和组成 从数据库的角度看，关联、聚集与组成之间的唯一不同是对象相互之间的绑定程度。对于聚集和组成，在数据库中对整体所做的操作通常需要同时对其组成部分进行操作，而关联则不是这样。 输入输出设计 输入设计任务 确定系统所有的输入； 确定输入设备和输入机制 对于每个系统输入，确定其必需的控制。 输入设计原则 输入量应保持在能满足处理要求的最低限度。 输入的准备及输入过程应尽量简单易行，从而减少错误的发生； 应尽早对输入数据进行检查（尽量接近原数据发生点），以便使错误及时得到改正； 输入数据应尽早地记录在其处理所需的