2015版第14章数据接口部分的设计要点分析.ppt

未必规范化程度越高越好 规范化的代价 ——影响系统的可理解性，增加了多表查询和连接操作 面向对象方法与关系数据库的规范化目标 既有相违的一面，又有相符的一面 以对象为中心组织数据与操作，恰恰有助于达到第2NF、3NF、BCNF和4NF要求的条件 对象的数据结构常常连1NF的要求都不能满足 例如“通信地址”属性 HOUSING（SID，Building，Fee） Key:SID Functional Dependencies: Building→Fee SID→Building→Fee 100 Randolph 1200 150 Ingersoll 1100 200 Randolph 1200 250 Pitkin 1100 300 Randolph 1200 SID Building Fee 例1：一个不满足3NF的关系及其规范化 STU-HOUSING（SID，Building） Key:SID SID Building 100 Randolph 150 Ingersoll 200 Randolph 250 Pitkin 300 Randolph BLDG-FEE（Building，Fee） Key:Building?? Building Fee Randolph 1200 Ingersoll 1100 Pitkin 1100 从面向对象的观点看应该定义“学生”和“建筑物”两个类 ——恰好与规范化要求吻合 学生 住所 ······ 建筑物 房费 ······ 分析原因：把描述不同事物的数据组织在一起 摘自：施伯乐等 译，[美] David M. Kroenke 著. 数据库处理. 北京：电子工业出版社，1998 例2：一个不满足4NF的关系及其规范化 STUDENT（SID，Major，Activity） Key:（SID，Major，Activity） ? SID Major Activity 100 Music Swimming 100 Accounting Swimming 100 Music Tennis 100 Accounting Tennis 150 Math Jogging STU-MAJOR（SID，Major） Key:（SID，Major） ? SID Major 100 Music 100 Accounting 150 Math STU-ACT（SID，Activity） Key:（SID，Activity） ? SID Activity 100 Skiing 100 Swimming 100 Tennis 150 Jogging ? SID Major 1 1 1 1 * * * * ? ? ? ? 课程 学生 活动 学生-课程 学生-活动 SID Activity * * * * ? ? ? 课程 学生 活动 用面向对象方法得到的分类——有三类对象 化解多对多关联之后的结果 为什么多出来3个类？ 用面向对象方法未能避免函数依赖的例子 职工 职工编号 月工资 所得税 … … … … 可以不通过规范化解决问题——讨论为什么 规范化的两种策略 保持类图，对表规范化 缺点是对象的存储与恢复必须经过数据格式的转换 修改类图 对问题域的映射可能不像规范化之前那么直接。但是这个问题并不严重 ——利大于弊 采用第二种策略——按规范化的要求修改类图中的类 作为问题域部分的设计内容之一 2）修改类图 3）确定关键字 用较少的属性作关键字，将为含关键字的操作带来方便 常用的技巧——引入编号 最终效果： 经过必要的规范化处理和关键字处理之后，得到一个符合数据库设计要求的类图，其中每个需要映射到数据库表的类，都满足如下条件： 至少满足第一范式 满足所期望的更高范式 有一组属性被确定为关键字 4）从类图到数据库的映射 （1）映射策略概要 对每个要在数据库中存储对象实例的类，都建立一个数据库表 类的每个属性（包括从所有祖先继承来的属性）都对应表的一个属性（列） 名称、数据类型完全相同 其中一组属性被确定为关键字 类的每个对象实例将对应表的一个元组（行） （2）对OO概念的处理 对一般-特殊结构的处理 抽象类不对应数据库表 特殊类包括自己定义的和继承来的所有属性 人员 姓名 出生年月 ······ 教职工 职称 从事专业 ······ 研究生