信息系统分析详细设计.ppt

第11章 详细设计 本章内容 先导案例 概述 11.1 数据库设计 11.2 用户界面设计 11.3 系统界面设计 要点回顾 阅读章节要求 先导案例 Aviation Electronic的界面设计 概述 UML模型向关系模型的映射。 系统界面处理需要少量人员干预的输入和输出; 用户界面处理需要人员直接参与的输入和输出。 设计指导原则有助于确保系统的可用性。 11.1 数据库设计 11.1.1 主键的生成 11.1.2 属性类型到域的映射 11.1.3 类的属性到列的映射 11.1.4 类到表的映射 11.1.5 关联关系的映射 11.1.1 主键的生成 1. 将对象标识符映射为主键 2. 将对象的某些属性映射为主键 1. 将对象标识符映射为主键 在将UML中的类映射为RDB中的表时，每张表中都增加一个对象标识符列，该对象标识符列作为表的主键。 在将UML模型中关联关系映射为RDB中的关联表时，关联表的主键由与该关联关系相关的类的标识符组成。 缺点：在DB维护时很难看出基于对象标识符的主键具有什么内在的含义。 带有关联类的大学课程注册类图 2. 将对象的某些属性映射为主键 将类的某些属性映射为RDB中表的主键。 该方法得到的主键具有一定的内在含义，从而为DB的调试和维护提供了方便。 但这种主键的修改比较困难，它们的修改可能要涉及到许多外键的修改。 11.1.2 属性类型到域的映射 属性类型是UML术语，对应于DB的域。 简单域非常容易实现，只需定义相应的数据类型和大小。 每个使用了域的属性，在映射时可能需要为每个域约束加入一条SQL的Check查询子句来表示在域上的约束(如限定域的取值范围等)。 简单域例：名字(name)和电话号码(phone-Number)。 11.1.3 类的属性到列的映射 UML模型中类的属性映射为RDB表中的零列或几列。一般地，可将类的属性直接映射成表的一个字段。 注意两种特殊情况： ①并不是类中的所有属性均是永久的(发票中的“合计”属性)。 ②当UML类的一个属性本身就是对象时要将它映射为DB表中的几列(Customer中包含一个作为其属性的Address对象 )。 11.1.4 类到表的映射 1. 所有的类均映射为DB中的表 2. 具有属性的类映射为DB表 3. 将超类的属性下移 4. 将子类的属性上移 1. 所有的类均映射为DB中的表 为每个超类和子类都创建一张表，这些表共享一个公共的主键。 2. 具有属性的类映射为DB表 所有具有属性的类才映射为DB表，无属性的类不进行映射。 与上一种方法相比，该方法减少了DB表的数量，其他方面与上一种方法大致相同。 3. 将超类的属性下移 每个子类对应的DB表中既包含该子类中的属性，也包含该子类所继承的属性。 超类不映射为DB表，减少DB表的数量。 4. 将子类的属性上移 将所有子类的属性都存放在超类所对应的DB表中。 一个完整的类层次结构只映射为一张DB表，而层次结构中所有类的所有属性都存储在这张DB表中。 避免了将众多的子类映射为DB表，从而减少DB表的数量。 11.1.5 关联关系的映射 1. 多对多关联的实现 2. 一对多关联的实现 3. 零或一对一关联的实现 4. 一对一关联的实现 5. UML模型的映射实例 四种类间的关联 可选对可选(0..1 : 0..*) 强制对可选(1 : 0..*) 可选对强制 (0..* : 1) 强制对强制(1..* : l..*) 1. 多对多关联的实现[可选对可选(0..1 : 0..*)] 引入关联表。 关联表是一张独立的表，它用于在RDB中维护两张或多张表之间的关联。 在RDB中，关联表中包含的属性通常是关系中涉及到的表中的键的组合。 关联表的名字通常是它所关联的表的名字的组合，或者是它实现的关联的名字。 2. 一对多关联的实现[强制对可选(1 : 0..*)] 可将外键放置在“多”的一方，角色作为外键属性名的一部分。 外键的空与非空由对1的强制性决定。 也可用关联表实现。使用关联表可使DB应用程序具有更好的扩展性。但另一方面，关联表增加了RDB中表的数目，并且它不能使一方的最小重复性强制为1。 外键放在“多”方 使用关联表 3. “零或一”对一关联的实现[可选对强制 (0..* : 1)] 可将外键放置在可选的一端 该外键不能为空值 4. 一到一关联的实现[强制对强制(1..* : l..*)] 在实现这种关联时，可将外键放置在任意一边，具体情况依赖于性能等因素。 5. UML模型的映射实例 航空公司的类图 航空公司的数据库表 航空公司的数据库表 遍历航空公司UML类