数据库设计Power Designer.doc

在Power Designer 中应用概念模型进行数据库设计建立一个概念模型对于数据库的设计，我们一般从概念模型开始，在概念模型设计阶段，我们着重分析数据的逻辑结构，避免陷入具体的存储细节，所有的设计都与将来所要采用的具体数据库产品无关。运行Power Designer程序，使用File|New菜单（或者“Ctrl+N”） 新建模型，在弹出的窗口中选择“Conceptual Data Model”，并为模型命名为：Company,点击“确定”。在窗口左侧浏览器中的当前工作区节点下会新增一个概念模型，自动建立了一个默认的概念图Diagram_1，并且已经在当前工作窗口打开。一个概念模型可以拥有多个这样的概念图，可以在模型的属性中指定其中一个作为默认。工作区中有一个元件面板，包含了在概念模型中可以使用的各种符号。最常用的是：实体（Entity）和关系（Relationship），如下图：定义实体用鼠标双击实体的符号，可以进入实体的属性页。1. General 项目 Name：是用来在模型中标识一个实体，一般用于模型在界面中的显示（这个可以通过更改选项设置进行改变）。在一个模型当中，实体的名字不能重复。Code：在模型转化时一般作为对象的物理名称，比如把实体属性的Code转化为数据库中的列名，当然我们现在不必为了这个实体将来叫什么而费神，一般采取与Name一致即可。Generate：默认是选择状态，如果取消，则在转化为其他模型时，会忽略这个实体。 2. Attributes 项目窗口中下面表格里的各项很类似于一个表结构的定义，但数据类型是经过抽象化的，采用独立的表示方法，不与任何一个具体的数据库系统相关。在此项目中为当前实体添加属性。后面的三列CheckBox分别代表： M：此属性不允许为空值 P：此属性为主键标识 D：为可显示属性按“Crtl+U”呼出“定制列过滤器”的窗口，可以根据自己的喜好和实际需要选择那些列出现在窗口中，那些隐藏。使用快捷键“Crtl+E”可以允许或者禁止当前过滤器。我们分别重新命名了以上两个实体为部门（Department）和雇员（Employee），并分别添加了属性，如下图：默认的，概念图只显示作为主键标识的属性，并且隐藏了数据类型。这样是为了使概念图更加简洁、易于理解，你完全可以通过选项更改这些显示配置。定义关系双击关系（Relationship）的符号，进入关系的属性页，在Detail项目中，我们可以对两个实体的关系进行详细的定义，如下图：1. General 项目 一般最好为关系取一个贴切的名字，本例的业务关系描述如下：一个部门有多个员工，我们使用“Has”作为这个关系的名字。同样的我们也可以描述为：多个员工属于一个部门，可不可以使用“Belong to”作为关系名字呢？一般不推荐这样做，在概念图中有一个约定，关系的名字采用从“1,n”中“1”所在的方向向“n”所在一方进行读取的语义。本例即“1”在部门一方，从部门一方向雇员一方读取语义，即：部门有（Has）多个员工。 2. Detail 项目假定对于实体部门（Department）和雇员（Employee），具有如下关系： 一个部门可以有多个雇员，新成立的部门也可以暂时没有任何雇员； 一个雇员必须属于一个部门，并且同时只能属于一个部门；根据以上关系，我们修改属性页，部门雇员的方向采用默认的0,n，雇员部门的方向修改为强制约束（Mandatory），或者从下拉框中选择“1,1”，如下图：最后定义完成的关系（Relationship）在概念图中表示如下：注：在Power Designer中，关系符号靠近实体端的一个“横线”代表强制性约束，“空心圆圈”代表无强制约束，即这一方可以无对象关联；“非分岔”线代表为“1” 的关系，“分岔”线代表“多”的关系。以上四个符号共可以组合出16种关系（包含反向）。其中“多对多”的关系一般通过给出一个中间实体来进行分解，所以 在许多概念图中，是看不到实际的“多对多”的关系存在的。另外在关系的属性中还有两项：Dominant role 和Dependent，可以表示更复杂的关系。定义更复杂的关系使用依赖关系(Dependent)还是使用上面的例子，我们假定这样的业务描述：雇员享有假期，雇员每次休假，需要记录雇员休假的起始日与结束日，假期以天为单位，一个雇员和一个开 始日唯一确定一个假期。根据这个业务描述，我们知道，对于假期而言，其必须依存于实体“Employee”而存在，即一个休假，必定有一个主体雇员。我们 在上一个模型的基础之上，添加一个实体，名称是“Holiday”，定义假期的属性开始日与结束日，这里并不需要重复定义一个雇员编号，而是替代的，使用 依赖关系，来表示实体“Holiday”依赖于实体“Employee”，关系定义如下图：在实体“Holiday”中，我们需要设置开始日为主键标识符，开始日与其依赖实体中的雇员编号一起作为实体“Holiday”的标识符，用来唯一确定一个假期。这种依赖关系在概念图中表现如下：从途中可以看出，在实体“Holiday”一端多了一个朝外的三角箭头，这个含义就是这个实体“的依赖于三角箭头所指的另外一个实体，在转化出来 的物理模型当中，实体“Employee”的empNo，在Holiday实体中不仅会作为一个外键，还同时会作为主键出现（与startData一起作 为复合主键）。使用Dominant role当两个实体之间的关系是1.1 时（尽管这种关系比较少见，常见于面向对象的设计方法当中，依赖实体中的主键通常与外健重合），你需要明确指定这两个实体，哪一个是父实体，哪一个是依赖实体，否则，系统在由概念模型转化为物理模型时，将不能确定需要在哪一端生成外键，这时就需要用到“Dominant role”选项，这个选项只有在1.1 的关系中才允许进行设置。我们假定这样的业务描述，企业中的部分雇员拥有一个系统帐号，并且是唯一的一个帐号，这些雇员需要保存一些额外的信息，比如帐号名称、密码等等。我们添加了一个新的实体“User”，其与雇员之间为1.1 的关系，由于一个用户帐号必定属于一个雇员，而一个雇员则可能没有用户帐号，所以我们定义实体“Employee”支配实体“User”。同时，由于“User”依赖于“Employee”而存在，所以再定义一个由前者到后者的依赖关系，如下图：Dominant role 选项中，箭头所指的实体为被支配的实体，即作为依赖实体。在模型图中，支配实体的一方会出现一个用圆括号括起来的大写字母“D”。转化出来的物理模型中，表User中，empNo作为单独的主键，同时也是引用Employee表的一个外键。处理多对多(n.n)的关系在概念模型中，一般很少看见两个实体之间是直接的n.n 的关系，一般这种情况下我们会增加一个中间实体，在Power Designer中，提供了一个专门的符号来对应，叫做“Association”。请考虑以下的情形：企业中拥有帐号的雇员在系统中具有不同的操作权限，这通过用户角色来进行管理，权限已经分配给了多个不同的角色，一个用户帐号至少属于一个角色，并 且可能会同时属于多个角色，一个角色可以包含0个或多个用户帐号。根据以上描述，我们添加一个实体“Role”，它与实体“User”之间是n.n 的关系，为了表达这种关系，我们增