数据库设计
数据库结构设计
一、数据库结构设计步骤 一般可将数据库结构设计分为四个阶段，即需求分析、概念结构设计、逻辑结构设计和物理设计。 下面各节分别介绍各阶段设计内容和具体方法。
二、需求分析 需求分析的任务是具体了解应用环境，了解与分析用户对数据和数据处理的需求，对应用系统的性能的要求，提出新系统的目标，为第二阶段、第三阶段的设计奠定基础。一般需求分析的操作步骤如下所述。 1．了解组织、人员的构成 子系统的划分常常以现有组织系统为基础，再进行整合，而新系统首先必须达到的目的是尽可能地完成当前系统中有关信息方面的工作，在原有系统中，信息处理总是由具体人来实施的。我们要了解组织结构情况、相互之间信息沟通关系、数据（包括各种报告、报表、凭证、单据）往来联系情况。 具体弄清各个数据的名称，产生的时间与传递所需时间与周期，数据量的大小，所涉及（传送）的范围，使用数据的权限要求，数据处理过程中容易发生的问题及其影响，各个部门所希望获得的数据的情况等。 然后了解每个人对每一具体数据处理的过程，基本数据元素来源于哪些地方、获取的途径、处理的要求、数据的用途，进而弄清数据的构成、数据元素的类型、性质、算法、取值范围、相互关系。 在上述调查基础上，首先画出组织机构及工作职能图。我们以一个学校的基层单位——某大学一个系的管理为例来简要说明。系的组织机构及工作职能如图7.1所示。
图7．1 系管理体系结构图
作为管理层经常需要的信息和工作有：
．查询老师个人基本情况及打印相应内容
．查询与统计科研项目情况及相关报表
．查询与统计论文著作情况及相关报表
．上级部门及其他部门来文管理与查询（要求能全文检索）
．系部发文管理
．任务下达、检查及管理
．信件、通知的收发及管理
．日程安排调度及管理
．设备仪器计划及管理
．设备入库与库存情况管理与查询
．设备借还领用管理及相应报表
．耗材计划与领发管理及相应统计报表
．图书管理及借还情况查询
．学生毕业设计文档管理
．专业与班组编制与查询
．教学文档管理及查询（安排与检查，包括课表、考试日程安排、监考安排等）
．学生成绩管理与查询和统计
．教师、学生、实验室课表管理及查询
．学生基本情况管理与查询（包括社会活动、奖惩、家庭情况及学校校友管理）
．实验安排与管理
．实验成绩管理及查询与统计
．奖金计算与发放
．收支情况管理及统计与查询
我们仅以设备仪器管理为例说明。现有设备表格有七种，名字及数据栏目如下：
①入库单（代码，院内编号，名称，型号，规格，单价，数量，金额，生产厂，购入单位，采购员，管理员，入库日期，经费来源，批准人，计划号）
②领用单（代码，院内编号，名称，型号，规格，单价，数量，领用人，批准人，领用单位，管理员，领用日期）
③报废单（代码，院内编号，名称，型号，规格，单价，数量，报废原因，批准人，管理员，报废日期）
④借条（代码，院内编号，名称，型号，规格，单价，数量，借用日期，拟还时间，借用人，批准人，管理员，设备状况）
⑤请购计划（名称，型号，规格，估计单价，请购数量，计划员，计划时间，批准人，批准时间，设备用途，计划号）
⑥设备明细账（代码，院内编号，名称，型号，规格，单价，生产厂，购入单位，采购员，入库时间，设备类别，当前状况）
⑦设备统计表（名称，型号，规格，单价，数据，金额，备注）
其中入库单由采购员填写，经批准交管理员输入办理入库手续，管理员签收并形成入库凭证下转财务。领用单由领用人填写，经批准交管理员办理领用手续，当报废时或归还时应办报废手续或归还手续。借条由借用人填写，经批准交管理员办理借用手续，当归还时应归还借条并办归还手续。设备明细账、设备统计表均由设备管理员填写。报废单要经批准报上级主管部门。其他账表要供上级主管部门及系部检查、查询。请购计划由计划员填写经批准交采购员实施，要能供查证。
各表格、各栏目数据之名称、数据类型等特性应专门说明并记载入数据字典中。
2．数据字典
数据字典（Data Dictionary DD）用于记载系统定义的或中间生成的各种数据、数据元素，以及常量、变量、数组及其他数据单位，说明它们的名字、性质、意义及各类约束条件，是系统开发与维护中不可缺少的重要文件。数据与数据元素分别用数据表、数据元素表记载。数据表、数据元素表的格式如下表7．1和表7．2所示。
作为管理层经常需要的信息和工作有：
．查询老师个人基本情况及打印相应内容
．查询与统计科研项目情况及相关报表
．查询与统计论文著作情况及相关报表
．上级部门及其他部门来文管理与查询（要求能全文检索）
．系部发文管理
．任务下达、检查及管理
．信件、通知的收发及管理
．日程安排调度及管理
．设备仪器计划及管理
．设备入库与库存情况管理与查询
．设备借还领用管理及相应报表
．耗材计划与领发管理及相应统计报表
．图书管理及借还情况查询
．学生毕业设计文档管理
．专业与班组编制与查询
．教学文档管理及查询（安排与检查，包括课表、考试日程安排、监考安排等）
．学生成绩管理与查询和统计
．教师、学生、实验室课表管理及查询
．学生基本情况管理与查询（包括社会活动、奖惩、家庭情况及学校校友管理）
．实验安排与管理
．实验成绩管理及查询与统计
．奖金计算与发放
．收支情况管理及统计与查询
我们仅以设备仪器管理为例说明。现有设备表格有七种，名字及数据栏目如下：
①入库单（代码，院内编号，名称，型号，规格，单价，数量，金额，生产厂，购入单位，采购员，管理员，入库日期，经费来源，批准人，计划号）
②领用单（代码，院内编号，名称，型号，规格，单价，数量，领用人，批准人，领用单位，管理员，领用日期）
③报废单（代码，院内编号，名称，型号，规格，单价，数量，报废原因，批准人，管理员，报废日期）
④借条（代码，院内编号，名称，型号，规格，单价，数量，借用日期，拟还时间，借用人，批准人，管理员，设备状况）
⑤请购计划（名称，型号，规格，估计单价，请购数量，计划员，计划时间，批准人，批准时间，设备用途，计划号）
⑥设备明细账（代码，院内编号，名称，型号，规格，单价，生产厂，购入单位，采购员，入库时间，设备类别，当前状况）
⑦设备统计表（名称，型号，规格，单价，数据，金额，备注）
其中入库单由采购员填写，经批准交管理员输入办理入库手续，管理员签收并形成入库凭证下转财务。领用单由领用人填写，经批准交管理员办理领用手续，当报废时或归还时应办报废手续或归还手续。借条由借用人填写，经批准交管理员办理借用手续，当归还时应归还借条并办归还手续。设备明细账、设备统计表均由设备管理员填写。报废单要经批准报上级主管部门。其他账表要供上级主管部门及系部检查、查询。请购计划由计划员填写经批准交采购员实施，要能供查证。
各表格、各栏目数据之名称、数据类型等特性应专门说明并记载入数据字典中。
2．数据字典
数据字典（Data Dictionary DD）用于记载系统定义的或中间生成的各种数据、数据元素，以及常量、变量、数组及其他数据单位，说明它们的名字、性质、意义及各类约束条件，是系统开发与维护中不可缺少的重要文件。数据与数据元素分别用数据表、数据元素表记载。数据表、数据元素表的格式如下表7．1和表7．2所示。
表7．1 数据表格式数据号数据名主人用户生成时间数据用途数据量保存时间数据源关联数据别名 其中，数据号是设计人员给定的顺序编号，用于分类清查与整理，并且与数据元素代码相关联。数据名是原有表格或凭证的名称，如成绩单、人事卡片、档案……。其他各项的意义说明如下：
主人：生成该数据的单位与个人代表。数据有一个主要生成者，有多个使用者，使用者即用户是使用生成的数据或其拷贝的单位或个人（包括仅使用该表部分数据元素的单位和个人）
生成时间：计算、打印或显示本数据的时间，有些数据只生成一次，例如一些突如其来的查询或统计操作的结果；有些每年生成一次，例如年报；还有依半年、季、月、半月、旬、周、日、时生成的，此处记载每次生成的大体时间。例如年报记每年何月（何日）生成，月报记每月何日生成等。
数据量：一条记录最大长度（不考虑备注与通用字段实际长度）。数据用途记该数据在系统中的作用或使用意义，例如设备统计表，是当前所存物资的统计生成表，提供决策依据等。
保存时间：有些数据是系统的基本数据，长期保存，如人事卡片、设备帐本。有些数据生成后只需再保存一段时间，以供其他应用，例如工资表及其相关数据，每月发放工资后还要继续保存3至5年，用于工资构成和成本分析，工资表相关的考勤、行政扣资、公积金等许多数据往往要保持一年，供年度统计使用等。也有些统计查询的结果则无须保存。
数据源：本表某些数据元素是来自另一个表或文件，应在此处及数据元素表中同时标明，以便将来某些数据结构修改时分析其附带影响，保证数据一致性和完整性。
关联数据：本表中有些数据将被用作另一些数据的源，需要列出这“另一些”数据的名字，以便将来对本表结构修改时考虑对其他数据的影响。
别名：该数据表的其他取名。
表7．2 数据元素表格式
数据号数据元素号物理名称用户数据名说明逻辑名称类型长度来源或算法完整性安全性小数位 其中，数据号是本数据元素所属数据的代号，要与数据表中编号对应。数据元素号是在该数据中的各数据元素的顺序编号。物理名称是实际数据中使用的名称。逻辑名称是指将来在系统数据结构中采用的名称。来源或算法指数据元素有些直接从另一些数据中提取，有些按一定方法或公式求取，在此应予注明来源或计算方法。完整性指是否为关键字，是否允许重复值，是否允许空值，取值范围限制等。安全性指对该数据元素查询、显示、使用及录入、修改、删除等操作权限是否有要求及什么样的要求。用户数据名指本数据元素可能用到哪些表的名称。
数据字典还将包含今后开发中涉及到的其他数据，例如在程序中使用的常量、变量、数组、集合、函数……要在开发过程中不断补充。即使是上述数据、数据元素，许多最终将被认定为数据库中的字段或系统中其他数据，要再作说明，也有些将不再出现。有些元素的性质、意义会有所改变，都将在开发过程中不断修改和补充。
在需求分析最后阶段，要进一步描述数据处理的流程，并写出需求分析说明书。
3．需求分析说明书
需求分析说明书是对需求分析过程的记载与总结，也是将来开发的依据和标准，将作为开发方和最终用户间交接的依据，是一个纲领性的文件。要使用尽可能精炼、通俗易懂、准确无二义性的语言表达对系统功能、性能的要求。需求分析说明书一般包括下述内容：
．数据库系统应用范围与环境条件
．工作流程图
．数据流程图
．数据字典（包括数据表与数据元素表）
．IPO图与加工说明
．数据库性能要求
．对操作界面的要求
．各类约束条件
．开发目标与方法
．组织机构
．系统当前状况分析
．数据库系统功能设计目标
．对系统结构的初步规划
．日程进度
．验收标准
其中关于当前系统状况分析应提交前述数据字典及全部原始材料，并进一步分析当前系统的工作、数据处理情况、存在问题并提出解诀方案。关于系统当前工作，数据处理情况的分析是新系统功能、性能设计的依据。
我们常常首先以工作流程图描述当前各部门、各主要业务人员的工作过程。一个工作流程图实例如图7．2所示。根据有关部门、工作人员对自己工作的描述，可画出工作流程图形象地表示组织与个人工作情况，主要是涉及数据和信息工作的情况。其主要图例中用矩形表示部门或组织，用圆圈表示工作人员，用双横线表示文件、数据库，用箭头线表示数据及其流向。在箭头线上标注数据名称。例如入库工作我们可用图7．2表示。图7．2 入库工作流程图
从工作流程图，我们看不清数据处理情况，可再进一步抽象，工作流程图中可以由计算机处理的部分抽象出来，画成数据流程图，得到系统的逻辑模型。数据流程图图例中以圆圈表示数据源、数据结果或外部实体，矩形表示数据处理，箭头线表示数据，线上标注数据名称，双横线表示文件或数据库。入库过程数据流程图如图7．3所示。
图7．3 入库过程数据流程图
主人：生成该数据的单位与个人代表。数据有一个主要生成者，有多个使用者，使用者即用户是使用生成的数据或其拷贝的单位或个人（包括仅使用该表部分数据元素的单位和个人）
生成时间：计算、打印或显示本数据的时间，有些数据只生成一次，例如一些突如其来的查询或统计操作的结果；有些每年生成一次，例如年报；还有依半年、季、月、半月、旬、周、日、时生成的，此处记载每次生成的大体时间。例如年报记每年何月（何日）生成，月报记每月何日生成等。
数据量：一条记录最大长度（不考虑备注与通用字段实际长度）。数据用途记该数据在系统中的作用或使用意义，例如设备统计表，是当前所存物资的统计生成表，提供决策依据等。
保存时间：有些数据是系统的基本数据，长期保存，如人事卡片、设备帐本。有些数据生成后只需再保存一段时间，以供其他应用，例如工资表及其相关数据，每月发放工资后还要继续保存3至5年，用于工资构成和成本分析，工资表相关的考勤、行政扣资、公积金等许多数据往往要保持一年，供年度统计使用等。也有些统计查询的结果则无须保存。
数据源：本表某些数据元素是来自另一个表或文件，应在此处及数据元素表中同时标明，以便将来某些数据结构修改时分析其附带影响，保证数据一致性和完整性。
关联数据：本表中有些数据将被用作另一些数据的源，需要列出这“另一些”数据的名字，以便将来对本表结构修改时考虑对其他数据的影响。
别名：该数据表的其他取名。
表7．2 数据元素表格式
数据号数据元素号物理名称用户数据名说明逻辑名称类型长度来源或算法完整性安全性小数位 其中，数据号是本数据元素所属数据的代号，要与数据表中编号对应。数据元素号是在该数据中的各数据元素的顺序编号。物理名称是实际数据中使用的名称。逻辑名称是指将来在系统数据结构中采用的名称。来源或算法指数据元素有些直接从另一些数据中提取，有些按一定方法或公式求取，在此应予注明来源或计算方法。完整性指是否为关键字，是否允许重复值，是否允许空值，取值范围限制等。安全性指对该数据元素查询、显示、使用及录入、修改、删除等操作权限是否有要求及什么样的要求。用户数据名指本数据元素可能用到哪些表的名称。
数据字典还将包含今后开发中涉及到的其他数据，例如在程序中使用的常量、变量、数组、集合、函数……要在开发过程中不断补充。即使是上述数据、数据元素，许多最终将被认定为数据库中的字段或系统中其他数据，要再作说明，也有些将不再出现。有些元素的性质、意义会有所改变，都将在开发过程中不断修改和补充。
在需求分析最后阶段，要进一步描述数据处理的流程，并写出需求分析说明书。
3．需求分析说明书
需求分析说明书是对需求分析过程的记载与总结，也是将来开发的依据和标准，将作为开发方和最终用户间交接的依据，是一个纲领性的文件。要使用尽可能精炼、通俗易懂、准确无二义性的语言表达对系统功能、性能的要求。需求分析说明书一般包括下述内容：
．数据库系统应用范围与环境条件
．工作流程图
．数据流程图
．数据字典（包括数据表与数据元素表）
．IPO图与加工说明
．数据库性能要求
．对操作界面的要求
．各类约束条件
．开发目标与方法
．组织机构
．系统当前状况分析
．数据库系统功能设计目标
．对系统结构的初步规划
．日程进度
．验收标准
其中关于当前系统状况分析应提交前述数据字典及全部原始材料，并进一步分析当前系统的工作、数据处理情况、存在问题并提出解诀方案。关于系统当前工作，数据处理情况的分析是新系统功能、性能设计的依据。
我们常常首先以工作流程图描述当前各部门、各主要业务人员的工作过程。一个工作流程图实例如图7．2所示。根据有关部门、工作人员对自己工作的描述，可画出工作流程图形象地表示组织与个人工作情况，主要是涉及数据和信息工作的情况。其主要图例中用矩形表示部门或组织，用圆圈表示工作人员，用双横线表示文件、数据库，用箭头线表示数据及其流向。在箭头线上标注数据名称。例如入库工作我们可用图7．2表示。图7．2 入库工作流程图
从工作流程图，我们看不清数据处理情况，可再进一步抽象，工作流程图中可以由计算机处理的部分抽象出来，画成数据流程图，得到系统的逻辑模型。数据流程图图例中以圆圈表示数据源、数据结果或外部实体，矩形表示数据处理，箭头线表示数据，线上标注数据名称，双横线表示文件或数据库。入库过程数据流程图如图7．3所示。
图7．3 入库过程数据流程图
这个图对于处理逻辑仍表现不充分，我们可用输入一处理一输出图（IPO图）进一步表示清楚。IPO图由三个矩形框组成，它们分别描述输入（I）、处理（P）和输出（O），用箭头线表示数据的传入传出，线旁标注处理条件或备注内容。上述入库过程用IPO图的描述如图7．4所示。
图7．4 用IPO图描述系统处理过程
如果处理过程比较复杂，图示仍不清楚，我们可附加加工说明，用文字详细说明每上步的处理过程和处理逻辑。
例如，关于“检查计划”的说明：
如果采购单上无领导签字
输入采购单上计划号
打开计划库
查找上述计划号
如果查到
读出计划数
查同一计划号物品已入库数量
如果小于等于计划数-采购数
办理入库
否则
说明计划额度已使用，退出
结束
否则
说明无此计划，不能入库
结束
结束
加工说明是用文字语言表述处理逻辑，尽量接近程序语言，又要通俗易懂，使得一方面能和业务人员展开讨论，进一步了解清楚业务人员的要求，另一方面又能较容易地转为实际程序。
在需求分析说明书中，还应具体写明有关处理安全性、时间性、可靠性、适应性等方面的要求，整理形成文档，经批准之后生效。三、概念结构设计
概念结构设计是在需求分析的基础上对所有数据要求按一定方法进行抽象与综合处理，设计出不依赖于某种具体DBMS的满足用户应用需求的信息结构。这种信息结构我们称为概念模型。
最常用的概念结构设计方法有实体分析法、面向对象设计方法、属性综合法和规范化关系方法。我们此处主要讨论实体分析法。这是一种自上而下抽象的方法。
这种方法要求根据前面数据的需求分析，确定系统范围，确定实体及其属性，画出系统的实体联系模型（E－R图）
第一步划分系统范围。一般数据库应用系统的管理对象不外乎人、财、物、事几个方面。
与“人”有关的对象包括组织机构、职工或其他人员（以下以职工为代表）的基本情况、职工或其他人员各类活动。其中组织机构例如单位、部门、机构，它们的主要属性是地址、联系人、单位性质、单位概况……是职工的所属和依附或交往的实体。职工基本情况包括个人情况、简历、爱人情况、家庭情况、社会关系情况等几大块，而简历又包括调动史、进修与学习、奖惩、工作史（科研、著作、教学、参军史、从政史及其他业务），组织与社团历史、对外交往或社会活动等。在以往，简历往往以一个文本进行记载，而如今管理逐渐细化，要求能对人员活动和各方面情况作多种查询统计，使用文本已难满足应用要求。另外“人”在管理中也分为不同的群体，例如学校中教师、职工、学生就各具有自己特殊的属性，教师、职工有工资、福利、教学等内容，学生有学习课程等内容，各自管理重点也不相同，应划分为不同分系统。
“财”一般涉及各种帐目、凭证、合同、协议计划、分析数据等。主要是人与物之间某些关系的数字体现，是一般管理系统管理的重要对象，在处理中有些被视为实体存储（例如流水帐）,有些是数学处理的结果（例如统计数据、报表等），这些数据许多无须保存，也有一些需留存供决策分析使用，如不需保留的数据无须实际存储。
“物”如设备、材料、产品、房产、车辆、能源、原料、物品、图书、行政用品等。我们常常依据上面各个方面或依据部门，确定局部信息范围。基本准则是功能相对独立，和其他局部信息范围相互影响较小，且实体个数尽量在10个以内。许多管理部门都是围绕上述一个方面或彼此有较多关联的几个方面开展工作的，我们也往往依据一些局部范围划分分系统或子系统。进行实体分析也按一个个局部范围展开。在展开时注意，每一局部范围有自己管理的主要内容，在其他局部范围中也可能涉及这些内容，要尽量不重复设置实体以防冗余。
第二步选择实体。开始我们总是依据所获系统的各种数据作为信息单位，并作为选择实体的依据，如上所述我们制定的人、财、物、事等是典型的内容，根据具体环境还应进一步具体分析。依据实体定义，确定实体关键是善于找到具有共同属性的群体。例如，在设备管理中，数据有入库单、领用单、报废单、借条、领条、计划单、账本、统计表等，我们对其属性进行分析，可见有一个中心内容——设备及其自身的属性，另外还涉及到一些人如采购员、管理员、负责人、使用人等，涉及到一些单位和部门如生产厂、销售部门、管理部门、使用部门等，涉及到和财务有关的内容如单价、数量、金额等。
其中有些内容如管理部门、使用部门是单位管理分系统中管理的主要对象。管理人员、采购人员、使用人员等是职工人事管理分系统中管理的主要对象，它们对于设备管理分系统只是外部实体。在这一分系统中要注意：使用这些数据的名字、属性时要与其他两个分系统保持一致。
还有一些内容如生产厂、销售单位的情况可能只要求作为查询使用，不关心这些单位进一步的属性和细节， 那么在做E-R图时可只指定它们作为属性，而不作为实体。不过如果我们要存储这些联系单位的数据，以为将来发展业务打基础，例如还希望存储关于他们的产品情况、质量情况、资金情况等数据，那就要单列实体了。
有些数据看上去是属于同一对象，但它们涉及的范围、信息内容并不相同，应区分为两个实体。例如，在设备管理中，设备计划虽也属设备管理，但它是对尚未购进的设备的计划，与已有设备在管理重点上不同、管理的内容也不同，有一些属性也有区别，关键字也互不相同，因而应列为两类实体。
第三步确定联系。通过进一步对它们之间关系的确定，可以得到设备管理的E-R图（本图省去一对多的联系菱形），如图7．5所示。
图7．5 设备管理E-R图 第四步确定实体的属性，依据需求分析中的数据元素整合得到。在分析时注意以下几点：
（1）每个实体至少有一个关键字， 这是唯一标识一条记录的属性。其他属性的值必须由它唯一确定，否则就不是该实体的属性。
（2）找出所有同名属性，如满足上一条， 则可合并为该实体的一个属性。有些同名，但实际代表意义不同，则应作为该实体不同属性，并给以不同命名。例如在文件管理中，随着文件传递将有多个“经手人”—一收文经手人、阅文经手人、执行（办文）经手人等，实际上他们代表的是不同的人在管理中执行不同的角色，因而应以收文人、传阅人、办文人等不同的命名加以区分。
另外，对于不同实体的同名属性，如果意义不相同，最好也以不同名字命名。例如企业生产最终产品和中间产品都是局部部门的产品，但意义不一样，中间产品是最终产品的子集，因此最好以不同名字命名，例如中间产品改名为“中间产品”或“XX部门产品”，企业最终产品仍命名为“产品”。
（3）对于一些计算数据，例如“金额＝单价*数量”可不作为属性列入。
（4）有些名字相同， 意义也相同，但在不同范围内特性不相同，如精度、长度，取值范围等存在不同。这些属性在统一标准后可合并为一个属性，在未来不同范围的软件中加以区分，要求最终存储时数据能包容、满足各种需求。
（5）有些名字不同，但意义相同的属性，应统一名字，合并为一个属性。例如在企业中生产部门对产品命名时，通常按原料成分、加工工艺等定义，而进入销售部门后名字按商品名定义。两个名字不同，为了管理方便，在一个企业内最好都改为同一名字，可另外规定别名或另外设计相同的统一的代码表，通过代码联系名字可任其不同。对所有属性，在E-R图中以前述对照表的形式标识。
最后一步分析和确定全局信息结构。我们从开始就划分了范围及各个范围的主要实体，一个范围在涉及另一个范围的主要实体时，我们也强调了主从关系并强调了保持一致性，防止冲突或重复。但由于是分为分系统研究的，因而冲突与重复仍然可能发生， 完成各分系统E-R图之后，有必要进行一次全盘的检验，一方面对所有同名实体检查与其主系统中该实体属性是否在名字、性质、精度、范围等方面一致，尤其关键字是否相同，防止冲突。另外，对非主系统的同名实体做出标志，将来在转化为关系模型时，只转换其中主要的一个。四、逻辑结构设计
1．关系数据模型
逻辑结构设计的任务是把概念模型，例如E-R图转换成所选用的具体的DBMS所支持的数据模型。此处我们主要介绍将E－R图转换为关系数据模型的方法，以及设计视图（子模式）的方法。在一些应用中，利用视图实现表与表的连接，将可简化程序设计。逻辑结构的设计与算法密切相关，在设计逻辑结构的同时，还要考虑应用程序的设计。一般说来，两个实体间如是一对一联系，在转化为关系模型时，可直接将两实体数据合为一表，属性为原两个实体的全部属性组合。例如单位与单位的法人之间是一对一关系可以用一个表描述，属性包括原来“单位”实体的全部属性和法人实体的全部属性。其优点是涉及单位与法人间相互关系的查询时无须联接，既简单便于维护，运行效率也高。但是也有些表合为一表后可能因为表中每条记录太长而影响效率。例如职工与职工爱人两表，由于许多职工的职工爱人一栏空缺，两表相连为一表后会产生大量空字段，而且两表相连后，记录太长，表的规模太大，效率肯定降低。加上在正常应用中，职工与家庭相关的查询统计毕竟不多，因而我们设计时也常按1：N方式设计成两个独立的表。
对于一对多联系的两个实体，分别建立两个表，在多方表中增加一方表中的关键字属性，作为其外码，按照参照完整性要求，外码要么为空值，要么必须是一方主码中的一个值。
对于多对多联系的两个实体要建立联系实体，其属性由互相联系的各实体的关键字组成。例如学生和课程间的联系定为多对多联系，因而应建立联系表：“成绩”，其属性包括学生和课程两表中关键字“学号”、“课程号”，此外包括“成绩”自身的属性“分数”。一般讲每建立一个表，在应用系统中都需要建立相应维护程序，设计复杂度加大，工作量加大。因此在一些特殊情况下，我们总设法减少“表”的数量，采用特殊处理方法。例如设备和部门之间是多对多关系，一台设备和保管部门、使用部门、所属部门等多部门相关，而一个部门也总是和许多设备相关。双方如建立多对多联系表，其属性应包括设备号、单位代码及关系类型（保管、使用、所属等）这样增加了一个表，应用程序如涉及显示每台设备由谁维护，由谁使用，属于谁。设计起来反而麻烦，不如考虑另一种处理方式：在设备表中同时设三个属性：保管部门名，使用部门名，所属部门名，就将设备和单位的联系变成三个一对多联系，减少了一个表，程序设计反而更加方便。
又例如，教师和科研项目之间是多对多联系，在应用中常常要回答一个老师参与了哪些科研项目，是哪些项目的项目负责人，又要回答每个项目有哪些老师参加。我们在处理时，在科研项目中设置两个属性：课题负责人，课题组成员。在数据录入课题组成员时，人名之间以“，”分隔，其中允许一栏填多人。这种做法不符合关系的基本要求，但是可少建一个表，在回答前一个问题时，在VFP中只需利用包含运算符（＄）就能查到结果， 在回答第二个问题时，则直接取“课题组成员”的值。由于应用问题简单，这样设计能满足要求，还使程序大大简化。
从以上分析可见，我们进行逻辑转换时常遵循一般规律，但也常常根据应用问题实际需要做一些特殊设计使问题简化，并不一定要追求高规范化，问题简化将使设计效率提高，使设计正确率提高，更方便用户使用，而这才应是我们所要达到的目标。
2．代码设计
在设计关系模型时，为了将来查询统计的需要，也有些是为了标准化的需要，对于某些属性要采用代码。例如，关于政治面貌的输入，对于是“党员”的情况就可能有不同的输入方法：“党员”，“中共党员”，“共chan党员”等。而如果不统一，将来统计党员人数时，如你的判断条件是政治面貌＝“党员”，那么在政治面貌栏中，后两种填法的记录都将不被统计进入，而形成数据错误。为此常建立代码表，在数据表中以代码存放该属性的值，将保证无二义性。也可直接按汉字内容存储，但在录入界面中，要求显示代码表，并只允许用户从中选取值录入，这样可保证该数据准确可靠，同时还方便了用户录入操作。
又例如设备，在应用中要求有按年份、按使用部门、按经费来源、按使用方向等不同要求分组统计设备的台数、金额等数据，为此我们设计了院内编码，分别由表示年份、使用部门经费来源及使用类型的代码加上顺序号连接成12位长度的字符串， 在VFP中可以利用SUBSTR（）函数从中取不同部分的字符串作为分组依据进行查询统计。这样的代码可以是关键字，也可以是为查询或统计应用需要而设计的属性。
关于应用程序结构设计，我们将在7．3节讨论。
图7．4 用IPO图描述系统处理过程
如果处理过程比较复杂，图示仍不清楚，我们可附加加工说明，用文字详细说明每上步的处理过程和处理逻辑。
例如，关于“检查计划”的说明：
如果采购单上无领导签字
输入采购单上计划号
打开计划库
查找上述计划号
如果查到
读出计划数
查同一计划号物品已入库数量
如果小于等于计划数-采购数
办理入库
否则
说明计划额度已使用，退出
结束
否则
说明无此计划，不能入库
结束
结束
加工说明是用文字语言表述处理逻辑，尽量接近程序语言，又要通俗易懂，使得一方面能和业务人员展开讨论，进一步了解清楚业务人员的要求，另一方面又能较容易地转为实际程序。
在需求分析说明书中，还应具体写明有关处理安全性、时间性、可靠性、适应性等方面的要求，整理形成文档，经批准之后生效。三、概念结构设计
概念结构设计是在需求分析的基础上对所有数据要求按一定方法进行抽象与综合处理，设计出不依赖于某种具体DBMS的满足用户应用需求的信息结构。这种信息结构我们称为概念模型。
最常用的概念结构设计方法有实体分析法、面向对象设计方法、属性综合法和规范化关系方法。我们此处主要讨论实体分析法。这是一种自上而下抽象的方法。
这种方法要求根据前面数据的需求分析，确定系统范围，确定实体及其属性，画出系统的实体联系模型（E－R图）
第一步划分系统范围。一般数据库应用系统的管理对象不外乎人、财、物、事几个方面。
与“人”有关的对象包括组织机构、职工或其他人员（以下以职工为代表）的基本情况、职工或其他人员各类活动。其中组织机构例如单位、部门、机构，它们的主要属性是地址、联系人、单位性质、单位概况……是职工的所属和依附或交往的实体。职工基本情况包括个人情况、简历、爱人情况、家庭情况、社会关系情况等几大块，而简历又包括调动史、进修与学习、奖惩、工作史（科研、著作、教学、参军史、从政史及其他业务），组织与社团历史、对外交往或社会活动等。在以往，简历往往以一个文本进行记载，而如今管理逐渐细化，要求能对人员活动和各方面情况作多种查询统计，使用文本已难满足应用要求。另外“人”在管理中也分为不同的群体，例如学校中教师、职工、学生就各具有自己特殊的属性，教师、职工有工资、福利、教学等内容，学生有学习课程等内容，各自管理重点也不相同，应划分为不同分系统。
“财”一般涉及各种帐目、凭证、合同、协议计划、分析数据等。主要是人与物之间某些关系的数字体现，是一般管理系统管理的重要对象，在处理中有些被视为实体存储（例如流水帐）,有些是数学处理的结果（例如统计数据、报表等），这些数据许多无须保存，也有一些需留存供决策分析使用，如不需保留的数据无须实际存储。
“物”如设备、材料、产品、房产、车辆、能源、原料、物品、图书、行政用品等。我们常常依据上面各个方面或依据部门，确定局部信息范围。基本准则是功能相对独立，和其他局部信息范围相互影响较小，且实体个数尽量在10个以内。许多管理部门都是围绕上述一个方面或彼此有较多关联的几个方面开展工作的，我们也往往依据一些局部范围划分分系统或子系统。进行实体分析也按一个个局部范围展开。在展开时注意，每一局部范围有自己管理的主要内容，在其他局部范围中也可能涉及这些内容，要尽量不重复设置实体以防冗余。
第二步选择实体。开始我们总是依据所获系统的各种数据作为信息单位，并作为选择实体的依据，如上所述我们制定的人、财、物、事等是典型的内容，根据具体环境还应进一步具体分析。依据实体定义，确定实体关键是善于找到具有共同属性的群体。例如，在设备管理中，数据有入库单、领用单、报废单、借条、领条、计划单、账本、统计表等，我们对其属性进行分析，可见有一个中心内容——设备及其自身的属性，另外还涉及到一些人如采购员、管理员、负责人、使用人等，涉及到一些单位和部门如生产厂、销售部门、管理部门、使用部门等，涉及到和财务有关的内容如单价、数量、金额等。
其中有些内容如管理部门、使用部门是单位管理分系统中管理的主要对象。管理人员、采购人员、使用人员等是职工人事管理分系统中管理的主要对象，它们对于设备管理分系统只是外部实体。在这一分系统中要注意：使用这些数据的名字、属性时要与其他两个分系统保持一致。
还有一些内容如生产厂、销售单位的情况可能只要求作为查询使用，不关心这些单位进一步的属性和细节， 那么在做E-R图时可只指定它们作为属性，而不作为实体。不过如果我们要存储这些联系单位的数据，以为将来发展业务打基础，例如还希望存储关于他们的产品情况、质量情况、资金情况等数据，那就要单列实体了。
有些数据看上去是属于同一对象，但它们涉及的范围、信息内容并不相同，应区分为两个实体。例如，在设备管理中，设备计划虽也属设备管理，但它是对尚未购进的设备的计划，与已有设备在管理重点上不同、管理的内容也不同，有一些属性也有区别，关键字也互不相同，因而应列为两类实体。
第三步确定联系。通过进一步对它们之间关系的确定，可以得到设备管理的E-R图（本图省去一对多的联系菱形），如图7．5所示。
图7．5 设备管理E-R图 第四步确定实体的属性，依据需求分析中的数据元素整合得到。在分析时注意以下几点：
（1）每个实体至少有一个关键字， 这是唯一标识一条记录的属性。其他属性的值必须由它唯一确定，否则就不是该实体的属性。
（2）找出所有同名属性，如满足上一条， 则可合并为该实体的一个属性。有些同名，但实际代表意义不同，则应作为该实体不同属性，并给以不同命名。例如在文件管理中，随着文件传递将有多个“经手人”—一收文经手人、阅文经手人、执行（办文）经手人等，实际上他们代表的是不同的人在管理中执行不同的角色，因而应以收文人、传阅人、办文人等不同的命名加以区分。
另外，对于不同实体的同名属性，如果意义不相同，最好也以不同名字命名。例如企业生产最终产品和中间产品都是局部部门的产品，但意义不一样，中间产品是最终产品的子集，因此最好以不同名字命名，例如中间产品改名为“中间产品”或“XX部门产品”，企业最终产品仍命名为“产品”。
（3）对于一些计算数据，例如“金额＝单价*数量”可不作为属性列入。
（4）有些名字相同， 意义也相同，但在不同范围内特性不相同，如精度、长度，取值范围等存在不同。这些属性在统一标准后可合并为一个属性，在未来不同范围的软件中加以区分，要求最终存储时数据能包容、满足各种需求。
（5）有些名字不同，但意义相同的属性，应统一名字，合并为一个属性。例如在企业中生产部门对产品命名时，通常按原料成分、加工工艺等定义，而进入销售部门后名字按商品名定义。两个名字不同，为了管理方便，在一个企业内最好都改为同一名字，可另外规定别名或另外设计相同的统一的代码表，通过代码联系名字可任其不同。对所有属性，在E-R图中以前述对照表的形式标识。
最后一步分析和确定全局信息结构。我们从开始就划分了范围及各个范围的主要实体，一个范围在涉及另一个范围的主要实体时，我们也强调了主从关系并强调了保持一致性，防止冲突或重复。但由于是分为分系统研究的，因而冲突与重复仍然可能发生， 完成各分系统E-R图之后，有必要进行一次全盘的检验，一方面对所有同名实体检查与其主系统中该实体属性是否在名字、性质、精度、范围等方面一致，尤其关键字是否相同，防止冲突。另外，对非主系统的同名实体做出标志，将来在转化为关系模型时，只转换其中主要的一个。四、逻辑结构设计
1．关系数据模型
逻辑结构设计的任务是把概念模型，例如E-R图转换成所选用的具体的DBMS所支持的数据模型。此处我们主要介绍将E－R图转换为关系数据模型的方法，以及设计视图（子模式）的方法。在一些应用中，利用视图实现表与表的连接，将可简化程序设计。逻辑结构的设计与算法密切相关，在设计逻辑结构的同时，还要考虑应用程序的设计。一般说来，两个实体间如是一对一联系，在转化为关系模型时，可直接将两实体数据合为一表，属性为原两个实体的全部属性组合。例如单位与单位的法人之间是一对一关系可以用一个表描述，属性包括原来“单位”实体的全部属性和法人实体的全部属性。其优点是涉及单位与法人间相互关系的查询时无须联接，既简单便于维护，运行效率也高。但是也有些表合为一表后可能因为表中每条记录太长而影响效率。例如职工与职工爱人两表，由于许多职工的职工爱人一栏空缺，两表相连为一表后会产生大量空字段，而且两表相连后，记录太长，表的规模太大，效率肯定降低。加上在正常应用中，职工与家庭相关的查询统计毕竟不多，因而我们设计时也常按1：N方式设计成两个独立的表。
对于一对多联系的两个实体，分别建立两个表，在多方表中增加一方表中的关键字属性，作为其外码，按照参照完整性要求，外码要么为空值，要么必须是一方主码中的一个值。
对于多对多联系的两个实体要建立联系实体，其属性由互相联系的各实体的关键字组成。例如学生和课程间的联系定为多对多联系，因而应建立联系表：“成绩”，其属性包括学生和课程两表中关键字“学号”、“课程号”，此外包括“成绩”自身的属性“分数”。一般讲每建立一个表，在应用系统中都需要建立相应维护程序，设计复杂度加大，工作量加大。因此在一些特殊情况下，我们总设法减少“表”的数量，采用特殊处理方法。例如设备和部门之间是多对多关系，一台设备和保管部门、使用部门、所属部门等多部门相关，而一个部门也总是和许多设备相关。双方如建立多对多联系表，其属性应包括设备号、单位代码及关系类型（保管、使用、所属等）这样增加了一个表，应用程序如涉及显示每台设备由谁维护，由谁使用，属于谁。设计起来反而麻烦，不如考虑另一种处理方式：在设备表中同时设三个属性：保管部门名，使用部门名，所属部门名，就将设备和单位的联系变成三个一对多联系，减少了一个表，程序设计反而更加方便。
又例如，教师和科研项目之间是多对多联系，在应用中常常要回答一个老师参与了哪些科研项目，是哪些项目的项目负责人，又要回答每个项目有哪些老师参加。我们在处理时，在科研项目中设置两个属性：课题负责人，课题组成员。在数据录入课题组成员时，人名之间以“，”分隔，其中允许一栏填多人。这种做法不符合关系的基本要求，但是可少建一个表，在回答前一个问题时，在VFP中只需利用包含运算符（＄）就能查到结果， 在回答第二个问题时，则直接取“课题组成员”的值。由于应用问题简单，这样设计能满足要求，还使程序大大简化。
从以上分析可见，我们进行逻辑转换时常遵循一般规律，但也常常根据应用问题实际需要做一些特殊设计使问题简化，并不一定要追求高规范化，问题简化将使设计效率提高，使设计正确率提高，更方便用户使用，而这才应是我们所要达到的目标。
2．代码设计
在设计关系模型时，为了将来查询统计的需要，也有些是为了标准化的需要，对于某些属性要采用代码。例如，关于政治面貌的输入，对于是“党员”的情况就可能有不同的输入方法：“党员”，“中共党员”，“共chan党员”等。而如果不统一，将来统计党员人数时，如你的判断条件是政治面貌＝“党员”，那么在政治面貌栏中，后两种填法的记录都将不被统计进入，而形成数据错误。为此常建立代码表，在数据表中以代码存放该属性的值，将保证无二义性。也可直接按汉字内容存储，但在录入界面中，要求显示代码表，并只允许用户从中选取值录入，这样可保证该数据准确可靠，同时还方便了用户录入操作。
又例如设备，在应用中要求有按年份、按使用部门、按经费来源、按使用方向等不同要求分组统计设备的台数、金额等数据，为此我们设计了院内编码，分别由表示年份、使用部门经费来源及使用类型的代码加上顺序号连接成12位长度的字符串， 在VFP中可以利用SUBSTR（）函数从中取不同部分的字符串作为分组依据进行查询统计。这样的代码可以是关键字，也可以是为查询或统计应用需要而设计的属性。
关于应用程序结构设计，我们将在7．3节讨论。
五、数据库物理设计
对一个给定的逻辑数据模型求取与应用需要相适应的物理结构的过程称为数据库物理设计。这种物理结构主要指数据库在物理设备上的存储结构和存取方法。对于关系数据库系统，数据的存储结构与存取方法由DBMS决定并自动实现，我们物理设计主要考虑的是在网络环境下数据库的分布及索引结构。
在现代网络环境支持下，数据库共享范围已超越地域，一个管理系统中的数据库将可能有多个，且不一定存在于一台服务器或一台主机中，在设计时我们需考虑数据怎样分布才能最好地满足应用需求，主要要考虑怎样提高工作效率，防止冲突及保证数据安全。
1．两层C/S结构
由服务器、客户机在局部范围内建立局域网，数据库设置在服务器中，客户机中可存放其备份或临时表，就构成所谓两层C/S结构，如图7．6所示。
图7．6 C/S结构图 服务器中数据被众多客户机程序所共享，它们可以同时读或写服务器中的数据，如有多台客户机中程序对同一数据做读写操作，就可能发生冲突。这一问题我们已在并发控制中作了说明。在设计时，对数据可能有如下不同处理形式。
．在处理时，客户机先向服务器索取数据，然后释放数据库，在客户机端处理数据，最后将结果送回服务器。这种处理方式对服务器、通信线路利用效率较高，但要注意防止并发操作错误。
．在处理时，客户机接受用户要求，并发给服务器，在服务器端处理，最后将结果传回客户机显示或打印。这种处理方式网络通信量较小、能防止并发操作错误，但服务器的CPU特别繁忙， 反应速度较低，且容易出现死锁或活锁。
2．三层C/S结构（B/S结构）
在Internet网络支持下，系统可更大规模扩大，出现了三层客户／服务器体系结构，即Browser/server模式，其拓扑结构如图7．7所示。
图7.7 三层C/S网络结构
这种结构使系统从封闭的集中式主机向开放的与平台无关的环境过渡，服务器端可以不只一台主机，可采用主机的群集技术构成，客户端程序极大简化。在客户端借助Web游览器可以处理简单的客户端处理请求， 显示用户界面及服务器端运行结果， Web服务器负责接收远程或本地的数据查询请求，然后运行服务器脚本，借助于中间件把数据通过ODBC发送到数据库服务器上以获取相关数据，再把结果数据传回客户的Browser。 数据库服务器端负责管理数据库，处理数据更新及完成查询要求，运行存储过程。这种方式使应用面极大扩展，而安全问题也变得更加令人重视。
我们应根据需要选择合适的存储方式。例如在系管理系统中，教师基本情况中的某些内容及科研情况、设备情况、日程表等部分数据，只允许少数具有特权的人查询和修改，一般不提供给其他人，我们将它们放在系内局域网服务器上，部分内容甚至放在单机上。对于教师教学进度计划、教学大纲等在系内共享要求较高的数据，我们存放在系内局域网服务器上，在各客户机中存放备份或提供视图以实现对服务器的访问。关于学生成绩信息、在学分制环境中学生选课及相关资料的数据，我们将之同时存放在本地局域网服务器中及远程服务器数据库中，允许学生远程访问。本地数据库是系统基本数据库，远程服务器中存放的是一个发布数据库。发布数据库的内容应随基本数据库内容改变而修改，注意和基本数据库保持一致。
为了提高存取效率，关系数据库都提供索引结构，索引使查询及与查询有关的修改、删除等操作效率提高，但插入和某些修改操作变得困难。
关系数据库系统中可以用静态或动态两种方式创建索引，静态索引指编程人员事先建立相应索引，在应用程序中打开它之后再对表操作，这种操作效率较高。动态索引指在程序中建立索引并使之成为主索引，这种方式较灵活，但在多用户共享并且录改操作比较频繁时会使处理速度变慢。
对一个给定的逻辑数据模型求取与应用需要相适应的物理结构的过程称为数据库物理设计。这种物理结构主要指数据库在物理设备上的存储结构和存取方法。对于关系数据库系统，数据的存储结构与存取方法由DBMS决定并自动实现，我们物理设计主要考虑的是在网络环境下数据库的分布及索引结构。
在现代网络环境支持下，数据库共享范围已超越地域，一个管理系统中的数据库将可能有多个，且不一定存在于一台服务器或一台主机中，在设计时我们需考虑数据怎样分布才能最好地满足应用需求，主要要考虑怎样提高工作效率，防止冲突及保证数据安全。
1．两层C/S结构
由服务器、客户机在局部范围内建立局域网，数据库设置在服务器中，客户机中可存放其备份或临时表，就构成所谓两层C/S结构，如图7．6所示。
图7．6 C/S结构图 服务器中数据被众多客户机程序所共享，它们可以同时读或写服务器中的数据，如有多台客户机中程序对同一数据做读写操作，就可能发生冲突。这一问题我们已在并发控制中作了说明。在设计时，对数据可能有如下不同处理形式。
．在处理时，客户机先向服务器索取数据，然后释放数据库，在客户机端处理数据，最后将结果送回服务器。这种处理方式对服务器、通信线路利用效率较高，但要注意防止并发操作错误。
．在处理时，客户机接受用户要求，并发给服务器，在服务器端处理，最后将结果传回客户机显示或打印。这种处理方式网络通信量较小、能防止并发操作错误，但服务器的CPU特别繁忙， 反应速度较低，且容易出现死锁或活锁。
2．三层C/S结构（B/S结构）
在Internet网络支持下，系统可更大规模扩大，出现了三层客户／服务器体系结构，即Browser/server模式，其拓扑结构如图7．7所示。
图7.7 三层C/S网络结构
这种结构使系统从封闭的集中式主机向开放的与平台无关的环境过渡，服务器端可以不只一台主机，可采用主机的群集技术构成，客户端程序极大简化。在客户端借助Web游览器可以处理简单的客户端处理请求， 显示用户界面及服务器端运行结果， Web服务器负责接收远程或本地的数据查询请求，然后运行服务器脚本，借助于中间件把数据通过ODBC发送到数据库服务器上以获取相关数据，再把结果数据传回客户的Browser。 数据库服务器端负责管理数据库，处理数据更新及完成查询要求，运行存储过程。这种方式使应用面极大扩展，而安全问题也变得更加令人重视。
我们应根据需要选择合适的存储方式。例如在系管理系统中，教师基本情况中的某些内容及科研情况、设备情况、日程表等部分数据，只允许少数具有特权的人查询和修改，一般不提供给其他人，我们将它们放在系内局域网服务器上，部分内容甚至放在单机上。对于教师教学进度计划、教学大纲等在系内共享要求较高的数据，我们存放在系内局域网服务器上，在各客户机中存放备份或提供视图以实现对服务器的访问。关于学生成绩信息、在学分制环境中学生选课及相关资料的数据，我们将之同时存放在本地局域网服务器中及远程服务器数据库中，允许学生远程访问。本地数据库是系统基本数据库，远程服务器中存放的是一个发布数据库。发布数据库的内容应随基本数据库内容改变而修改，注意和基本数据库保持一致。
为了提高存取效率，关系数据库都提供索引结构，索引使查询及与查询有关的修改、删除等操作效率提高，但插入和某些修改操作变得困难。
关系数据库系统中可以用静态或动态两种方式创建索引，静态索引指编程人员事先建立相应索引，在应用程序中打开它之后再对表操作，这种操作效率较高。动态索引指在程序中建立索引并使之成为主索引，这种方式较灵活，但在多用户共享并且录改操作比较频繁时会使处理速度变慢。
