简单数据库设计实例.docxVIP

数据库设计实例 数据库设计是数据库应用系统设计的一个组成部分，其核心是针对于特定的应用环境，设计合理的数据模型，创建数据库及其应用系统，使之能够有效地存储和处理数据，以满足用户的应用需求。从实用角度出发，数据库设计可分为如下几个步骤： 第一步：创建概念数据模型 确定实体和关系 确定属性 规范化数据 第二步：生成物理数据模型 第三步：验证设计 为便于学习者理解和掌握，下面结合具体的实例来讲解和展示数据库设计的详细过程。假定我们要开发一个小型的 ERP 系统，以管理公司内部资源，其应用业务场景描述如下： v512 工作室由 IT 业界专业人士组成， 在提供高端 IT 培训业务的同时， 还自主制作并免费发布大量公 益性学习资源，工作室以公司形式运营，目前共拥有 18 名员工，这些员工分属于 4 个部门，且员工之间 存在上下级管理关系。计划将来根据业务的发展设立更多的部门，聘用更多的员工。为保证质量，工作室对其成员的各项专业技能进行了级别评定。 8.5.1 确定实体和关系 1. 确定高级别的活动 要确定本 ERP 系统数据库设计中的实体和实体间关系，首先应明确要基于该数据库执行的高级别活 动，这里所谓的高级别活动是指从用户的视角出发， 确定本数据库设计中系统所涉及到的业务活动。 比如， 存储和维护员工的个人信息等。 在前述的应用业务场景中， v512 工作室需要考虑的高级别活动包括： 聘用新员工 解雇现有员工 维护员工的个人信息 增设新部门 裁撤现有部门 维护部门信息 维护工作室业务相关的技能信息 维护各员工的业务技能掌握情况 确定实体 接下来要确定的是，针对上述的高级别活动需要记录和维护有关哪些事物的信息，这些事物将被转换 为实体。其中，员工相关信息可抽象为“ Employee ”实体、部门相关信息可抽象为“ Department ”实体、技能相关信息抽象为“ Skill ”实体，为规范和方便起见，这些实体均采用英文命名，并尽量在名称中体现 其含义。 共10页第1页 确定关系 进一步对上述高级活动进行分析，以确定实体间存在何种关系。具体包括： Employee-Department 实体之间存在隶属关系 员工必须且只能隶属于某一个特定的部门，一个部门可以包含 0～多名员工，此为一对多关系。 这种从两个方向上对同一个关系的细化描述被称为关系的角色，每个关系都对应两种角色。 Employee-Department 实体之间存在管理关系 每一名员工可以管理 0～ 1 各部门，每个部门必须由一名员工负责管理（其管理者不必须隶属于本部门），此为一对一关系。 Employee-Skill 实体之间存在掌握关系 每一名员工均应掌握 1～多项业务技能，每项技能可能被 0～多名员工掌握，此为多对多关系。 Employee-Employee 实体之间存在管理关系 每位员工由 0～ 1 位上级员工负责管理，有的员工可能没有上司（比如公司经理），但有的话只 能有一位直接上级。上级员工可以管理0～多位为下级员工。 经分析而得的上述实体间关系如图8-14 所示。 Department 被管理 Employee Skill 管理 掌握 包含 被掌握 隶属 被管理 管理 图 8-14 数据库设计实例 CDM 之 1 将多对多关系更改为实体 前文中已讲过，在多对多关系中，可能会出现有属性与关系相关联、而不是单纯的与实体相关联的情 况，将这样的属性添加到任何一个实体中都是不合理的，此时应将该关系转换为、或者说定义为实体。我们这里的 Employee 与 Skill 实体之间就存在这种情况——员工所掌握的技能项目及其评定等级信息就与两 个实体之间的多对多关系相关联，因此将此多对多关系定义为“人力资源”（ HR）实体，转换后的实体 - 关系如图 8-15 所示。 Skill 被掌握 HR 掌握 Department 被管理 Employee 管理 包含 隶属 被管理 管理 图 8-15 数据库设计实例 CDM 之 2 共10页第2页 在实际的数据库应用设计中，更简单而可行的处理原则是，将一切多对多关系均转换为实体，而不必逐个对其进行细化分析，这样可以很好地解决违背数据库规范化第二范式的问题。 分解活动 接下来，需要对前述的高级别业务活动做进一步分析，看是否可以将其中的部分或全部项目分解为相对低级别、或者说更细致的业务活动，比如，其中“维护工作室业务相关的技能信息”这一高级别的活动可继续分解为： 添加新的技能项目 删除不再使用的技能项目 维护 /更新现有技能项目的详细详细 最后一项高级活动“维护各员工的业务技能掌握情况”也可以进行类似的分解。需要说明的是高级业 务活动的确定以及这里的细化分解并没有一成不变的标准，这就好比实现某一预期功能的编程工作是没有标准答案的