3数据库逻辑设计汇编.ppt

* 步骤 3.3 检查表是否支持用户事务 * 步骤 2.4 检查业务规则 业务规则是用于防止数据库不完整、不准确或不一致的约束 * 步骤 2.4 检查业务规则 考虑业务规则的类型: 必须的数据（非空） 列的值域约束（比如职位） 实体完整性 多样性 参照完整性 其他业务规则（一次不得超过10盘） * 步骤 2.4 检查业务规则 – 参照完整性 关于外码，有两点必须强调 外码允许为空吗? （强制参与，不允许） 如何保证参照完整性? 必须指定存在约束, 定义了主码和外码在什么条件下能够被插入、更新或删除 * 如何保证参照完整性? 考虑如下6种情况. 情况 1: 向子表中插入记录 情况 2: 从子表中删除记录 情况 3: 更新子表记录中的外码 情况 4: 向父表中插入记录 情况 5: 从父表中删除记录 情况 6: 更新父记录的主码 有几种策略来处理情况5 * 情况 5: 从父表中删除记录 考虑如下几种操作: NO ACTION：指定如果试图删除/修改某一行，而该行的键被其他表的现有行中的外键所引用，则产生错误并回滚 DELETE/UPDATE语句。 CASCADE：指定如果试图删除/修改某一行，而该行的键被其他表的现有行中的外键所引用，进行级联删除 SET NULL：指定如果试图删除/修改某一行，而该行的键被其他表的现有行中的外键所引用，将引用的值置为null SET DEFAULT：指定如果试图删除/修改某一行，而该行的键被其他表的现有行中的外键所引用，将引用的值置为default值 * 表的参照完整性约束 * 步骤 2.5 与用户讨论逻辑数据库设计 确保逻辑数据库设计真正表达了企业（或企业的一部分）数据库应支持的数据要求 Secondary Storage Device，与备份或归档来自主存储的存储服务器相连的辅助存储设备。如硬盘，光碟或其他速度缓慢但拥有很高容量的设备。 联系“一”端的实体被设计为父实体，“多”端的实体被设计为子实体 * 步骤1.7 检查模型的数据冗余 * 步骤1.8 检查模型是否支持用户事务 ER模型描述组织的数据需求 目标：检查ER模型，确保模型支持所需要的事务. （手工检查） 两种可能的方法: (1)描述事务 （针对每个事务，检查模型中是否提供了事务所需的所有信息（实体、联系、属性）） (2)使用事务路径 * * 步骤1.9 与用户一起检查模型 目标：与用户一起检查ER模型可以确保此模型是“真实”的表达了企业（或企业的一部分）的需求 * 3.3 步骤2 将ER模型映射为表 从ER模型中创建表，并检查这些表的结构 * 步骤2 将ER模型映射为表 步骤 3.1 创建表 步骤 3.2 用规范化方法检查表结构 步骤 3.3 检查表是否支持用户事务 步骤 2.4 检查业务规则 步骤 2.5 与用户讨论逻辑数据库设计 * 步骤3.1 创建表 为ER模型创建表来表达实体、联系、属性和约束 每个表的结构来源于ER模型所描述的信息，这些信息包括ER图、数据字典和任何其他相关的文档 使用DDL（关系数据库定义语言）描述表的组成 * 步骤3.1 创建表 – 以Branch视图的ER模型为例子讨论 * 如何表达实体 对ER模型中的每个实体，创建一个包含实体的所有简单属性的表 对复合属性, 仅在表中包含组成复合属性的简单属性 如果可能, 标识每个表中组成主码的属性 * 描述实体的初始表结构 * 如何表达实体 在有些情况下, 我们不能标识出组成表的所有属性，因为我们还必须要描述实体间的联系 特别的是, 没有表达出ER模型中的联系之前，我们不能标识出组成弱实体的主码的属性 * 如何表达联系 每个联系转换为一个表，这个表在一定情况可以和实体转换的表合并 * 如何表达关系 考虑如何表达下列联系: 一对多 (1:*) 二元联系; 一对多 (1:*) 递归联系; 一对一 (1:1) 二元联系; 一对一 (1:1) 递归联系; 多对多 (*:*) 二元联系; 复杂联系; 多值属性 * 1:* 二元联系 联系“一”端的实体被设计为父实体，“多”端的实体被设计为子实体 父实体主码的拷贝被放置在子实体的表中，作为外码 * 1:* 联系 – (a) ER图; (b) 成为表 * 1:* 递归联系 1:* 递归联系的表示类似于 1:* 二元联系. 不过在这种情况下, 父子实体是同样的实体. * 1:* 递归联系 – (a) ER图; (b) 成为表 * 1:1 二元联系 二元一对一联系： 联系转化的表可以任一端实体转化成的表进行合并 二元一对一联系不能导致相关实体转化成的表合并 示例： E-R图如右所示 转化成的表 Dept(dno,dname) President(pid,name) Manage