4 ．4 数据库设计与管理

　　数据库设计是数据库应用的核心。本节讨论数据库设计的任务特点、基本步骤和方法，重点介绍数据库的需求分析、概念设计及逻辑设计三个阶段，并用实际例子说明如何进行相关的设计。此外本节还简单讨论数据库管理的内容及DBA的工作。

　　4.4.1 数据库设计概述
　　4.4.2 数据库设计的需求分析
　　4.4.3 数据库概念设计
　　4.4.4 数据库的逻辑设计
　　4.4.5 数据库的物理设计
　　4.4.6 数据库管理

　　4.4.1数据库设计概述　

　　在数据库应用系统中一个核心问题就是设计一个能满足用户要求，性能良好的数据库，这就是数据库设计（Database design）
　   数据库设计的基本任务是根据用户对象的信息需求、处理需求和数据库的支持环境（包括硬件、操作系统与DBMS）设计出数据模式。所谓信息需求主要是指用户对象的数据及其结构，它反映了数据库的静态要求；所谓处理需求则表示用户对象的行为和动作，它反映了数据库的动态要求。数据库设计中有一定的制约条件，它们是系统设计平台，包括系统软件、工具软件以及设备、网络等硬件。因此，数据库设计即是在一定平台制约下，根据信息需求与处理需求设计出性能良好的数据模式。
　　在数据库设计中有两种方法，一中是以信息需求为主，兼顾处理需求，称为面向数据的方法（data-orented approach）;另一种方法是以处理需求为主，兼顾信息需求，称为面向过程的方法（process-oriented）。 这两种方法目前都有使用，在早期由于应用系统中处理多于数据，因此以面向过程的方法使用较多，而近期由于大型系统中数据结构复杂的方法较多。由于数据在系统中稳定性高，数据已成为系统的核心，因此面向数据的设计方法已成为主流方法。
　　数据库设计目前一般采用生命周期（life cycle）法，即将整个数据库应用系统的开发分解成目标独立的若干阶段。它们是：需求分析阶段、概念设计阶段、逻辑设计阶段、物理设计阶段、编码阶段、测试阶段、运行阶段、进一步修改阶段。在数据库设计中采用上面几个阶段中的前四个阶段，并且重点以数据结构与模型的设计为主线，如图4.17所示。
　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　图4.17 数据库设计的四个阶段

　　4.4.2数据库设计的需求分析

　　需求收集和分析是数据库设计的第一阶段，这一阶段收集到的基础数据和一组数据流图（Data Flow Diagram简记为DFD）是下一步设计概念结构的基础。概念结构是整个组织中所有用户关心的信息结构，对整个数据库设计具有深刻影响。而要设计好概念结构，就必须在需求分析阶段用系统的观点来考虑问题、收集和分析数据及其处理。
　　需求分析阶段的任务是通过详细调查现实世界要处理的对象（组织、部门、企业等），充分了解原系统的工作概况，明确用户的各种需求，然后在此基础上确定新系统的功能。新系统必须考虑今后可能的扩充和改变，不能今按照当前应用需求来设计数据库。
　　调查的重点是“数据”和“处理”，通过调查要从中获得每个用户对数据库的如下要求：
　　① 信息要求。指用户需要从数据库中获得信息的内容与性质。由信息要求可以到出数据要求，即在数据库中需存储那些数据。
　　② 处理要求。指用户要完成什么处理功能，对处理的响应时间有何要求，处理的方式是批处理还是连机处理。
　　③ 安全性和完整性的要求。
　　为了很好地完成调查的任务，设计人员必须不断地与用户交流，与用户达成共识，以便逐步确定用户的实际需求，然后分析和表达这些需求。需求分析是整个设计活动的基础，也是最困难、最花时间的一步。需求分析人员既要懂得数据库技术，又要对应用环境的业务比较熟悉。
　　分析和表达用户的需求，经常采用的方法有结构化分析方法和面向对象的方法。结构化分析方法采用自顶向下、逐层分解的方式分析系统。用数据流图表达了数据和处理过程的关系，数据字典对系统中数据的详尽描述，是个类数据属性的清单。对数据库设计来讲，数据字典是进行详细的数据收集和数据分析所获得的主要结果。
　　数据字典是各类数据描述的集合，他通常包括5个部分，即数据项，是数据的最小单位；数据结构，是若干数据项有意义的集合；数据流，可以是数据项，也可以是数据结构，表示某一处理过程的输入或输出；数据存储，处理过程中存取的数据，常常是手工凭证。手工文档或计算机文件；处理过程。
　　在实际开展需求分析工作时有两点需要特别注意：
　　第一， 在需求分析阶段一个重要而困难的任务是收集将来应用所涉及的数据。若设计人员仅仅按当前应用来设计数据库，新数据的加入不仅会影响数据库的概念结构，而且将影响逻辑结构和物理结构，因此设计人员应充分考虑到可能的扩充和改变，使设计易于更动。
　　第二， 必须强调用户的参与，这是数据库应用系统设计的特点。数据库应用系统和广泛的用户有密切的联系，其设计和建立又可能对更多人的工作环境产生重要影响。因此，设计人员应该和用户充分合作进行设计，并对设计工作的最后结果承担共同的责任。

　　4.4.3数据库概念设计

　　1.数据库概念设计概述
　　数据库概念设计的目的分析数据间内在语意关连，在此基础上建立一个数据的抽象模型。数据库概念设计的方法有以下两种：
　　（1） 集中式模式设计法
这是一种统一的模式设计方法，她根据需求由一个统一机构或人员设计一个综合的全局模式。这种方法设计简单方便，它强调统一与一致，适用于小型或并不复杂的部门或单位，而对大型的或语义关联复杂的单位则并不适合。
　　（2） 视图集成设计法
这种方法是将一个单位分解成若干个部分，先对每个部分作局部模式设计，建立各个部分的视图，然后以各视图为基础进行集成。在集成过程中可能会出现一些冲突，这是由于视图设计的分散性形成的不一致所造成的，因此需对视图作修正，最终形成全局模式。
视图集成设计法是一种由分散到集中的方法，它的设计过程复杂但它能较好地反映需求，适合于大型与复杂的单位，避免设计的粗糙与不周到，目前此种方法使用比较多。
　　2.数据库概念设计的过程
　　使用E-R模型与视图集成法进行设计时，需要按以下步骤进行：首先选择局部应用，再进行局部视图设计，最后对局部视图进行集成得到概念模式。
　　（3） 选择局部应用
根据系统的具体情况，在多层的数据流图中选择一个适当层次的数据流图，让这组图中每一部分对应一个局部应用，以这一层次的数据流图为出发点，设计E-R图。
　　（4） 视图设计
　　视图设计一般有三种设计次序，它们是：
　　① 自顶向下。这种方法是先从抽象级别高且普遍性强的对象开始逐步细化、具体化与特殊化，如学生这个视图可先从一般学生开始，再分成大学生、研究生等，进一步再由大学生细化为大学本科与专科，研究生细化为博士生与硕士生等，还可以再细化成学生姓名、年龄、专业等细节。
　　② 由底向上。这种设计方法是先从具体的对象开始，逐步抽象，普遍化与一般化，最后形成一个完整的视图设计。
　　③ 由内向外。这种设计方法是先从最基本与最明显的对象着手逐步扩充至非基本、不明显的其他对象，如学生视图可以从最基本的学生开始逐步扩展至学生所学的的课程、上课的教室与任课的教师等其他对象。
　　上面3种方法为视图设计提供了具体的操作方法，设计者可根据实际情况灵活掌握，可以单独使用也可混合使用。有些共同特性和行为的对象可以抽象为一个实体。对象的组成成分可以抽象为实体的属性。
　　在进行设计时，实体与属性是相对而言的。同一事物，在一种应用环境中作为“属性”，在另一种应用环境中就必须作为“实体”。但是，在给定的应用环境中，属性必须是不可分的数据项，属性不能与其他实体发生联系，联系只发生在实体之间。
　　例4．6 学籍管理局部应用中主要涉及的实体包括学生、宿舍、档案材料、班级、班主任。这些实体之间发生连系有：
　　① 一个宿舍可以住多个学生，一个学生只能住一个宿舍，因此宿舍与学生的联系是1：N。
　　② 一个班有若干名学生，一个学生只能属于一个班级，因此班级与学生的关系也是1：N。
　　③ 班主任与学生的关系也是1：N。
　　④ 学生与自己档案的关系是1：1。
　　⑤ 班级与班主任之间都是1：1的联系。
　　于是，省略了实体的属性后学籍管理的E-R图如图4.18所示。
　　　　　
　　　　　　　　　　　　　　　　　　　图4.18　省略了实体属性的学籍管理Ｅ－Ｒ图
　　对应于各实体的属性分别为：
　　学生：{学号，姓名，出生日期，所在系，何时入学，平均成绩}
　　档案材料：{档案号，……}
　　班级：{班级号，学生人数}
　　班主任：{职工号，姓名，性别，是否为优秀班主任}
　　宿舍：{宿舍编号，地址，人数}
　　教室：{教室编号，地址，容量}
　　其中有下划线的属性为实体的的码。
　　例4．7课程管理局部视图的设计：在这一试图中共有五个实体，分别是学生、课程、教室、教师及教科书，描述这些实体的属性分别为：
　　学生：{学号，姓名，年龄，性别，入学时间}
　　课程：{课程号，课程名，学时数}
　　选修：{学号，课程名，成绩}
　　教科书：{书号，书名，ISBN，作者，出版时间，关键字}
　　教室：{教室编码，地址，容量}
　　同样省略了实体的属性后课程管理的E-R图如图4.19所示。
　　　　　　
　　　　　　　　　　　　　　　　　　　　图4.19　省略了实体属性的课程管理Ｅ－Ｒ图
　　（3）视图集成
　　视图集成的实质是将所有的局部试图统一与合并成一个完整的数据模式。在进行视图集成时，最重要的工作边式解决局部设计中的冲突。在集成过程中由于每个局部视图在设计时的不一致性因而会产生矛盾，引起冲突，常见的冲突有下列几种：
　　① 命名冲突。命名冲突有同名异议和同和同义异名两种。如上面的示例中学生属性“何时入学”与“入学时间”属同义异名。
　　② 概念冲突。同一概念在一处为实体而在另一处为属性或联系。
　　③ 域冲突。相同的属性在不同视图中有不同的域，如学号在某视图中的域为字符串而在另一个视图中可为整数，有些属性采用不同度量单位也属冲域突。
　　④ 约束冲突。不同的视图可能有不同的约束。
　　视图经过合并生成的是初步的E-R图，其中可能存在冗余的数据和冗余的实体间联系。冗余数据和冗余联系容易破坏数据库的完整性，给数据库维护增加困难。因此，对于视图集成后形成的整体的数据库概念结构还必须进行一步验证，确保它能满足下列条件：
　　整体概念结构内部必须具有一致性，既不能存在相互矛盾的表达；
　　整体概念结构能准确的反映原来的每个视图结构，包括属性、实体及实体间的联系；
　　整体概念结构能满足需求分析阶段所确定的所有要求；
　　整体概念结构最终还应该提交给用户，征求用户和有关人员的意见，进行评审、修改和优化，然后把她确定下来，作为数据库的概念结构，作为进一步设计数据库的依据。
　　例4．8学籍管理局部视图与课程管理局部视图的集成。
　　根据上面所述的方法，集成过程可按下面步骤进行：
　　① 消除冲突
　　这两个子E-R图存在着多方面的冲突：
　　（1） 班主任也属于教师，学籍管理中心的班主任实体与课程管理中的教师实体属于异名同义，可以统一称为教师。
　　（2） 将班主任改为教师后，教师与学生之间的关系呈现两种不同类型的联系：指导联系和教学联系。由于指导联系实际上可以包含在教学联系中，因此可以将这两种联系综合为教学联系。
　　（3） 调整学生实体属性组成及次序，调整结果可为：
　　学生：{学号，姓名，出生日期，年龄，所在系，年级，平均成绩}
　　② 消除冗余
　　（1） 学生实体中的年龄可以由出生日期推算出来，属于冗余数据。
　　学生：{学号，姓名，出生日期，所在系，年级，平均成绩}
　　（2） 教室实体与班级实体之间的上课联系可以由教室和课程之间的开设联系、课程与学生之间的选修联系、学生与班级之间的组成联系三者推导出来，因此属于冗余联系。
　　（3） 学生实体中的平均成绩可以从选修联系中的成绩属性中推算出来。
　　如果需要经常查询学生的平均成绩，可以考虑保留该冗余数据，提高效率。但是为了维护数据的一致性，应采用一定的机制以保持数据的一致性。
　　这样，集成这两个子E-R图后的学生管理子系统的E-R图如图4.20所示。
　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　图4.20　学生管理子系统的Ｅ－Ｒ图
　　学生管理子系统的基本E-R图还必须进一步和教师管理子系统以及后勤管理子系统等的基本E-R图合并，才能生成整个学校管理系统的基本E-R图。

　　4.4.4 数据库的逻辑设计

　　1. 从 E-R图向管理模式转换
　　数据库的逻辑设计主要工作是将E-R图转换成指定RDBMS中的关系模式。首先，从E-R图到关系模式的转换是比较直接的，实体与联系都可以表示成关系，E-R图中属性也可以转换成关系的属性。实体集也可以转换成关系。E-R图模型与关系间的转换如表4.10所示。
　　　　　
　　　　　　　　　　　　　　　　　　　　　表4.10　Ｅ－Ｒ模型与关系间的比较表

　　下面讨论由E—R图转换成关系模式时会遇到的一些转换问题。
　　（1） 命名与属性域的处理
　　关系模式中的命名可以用E—R图中原有命名，也可另行命名，但是应尽量避免重名，RDBMS一般只支持有限种数据类型而E—R图中的属性域则不受此限制，如出现有RDBMS不支持的数据类型时则要进行类型转换。
　　（2） 非原子属性处理
　　E—R图中允许出现非原子属性，但在关系模式中一般不允许出现非原子属性，非原子属性主要有集合型和元组型。如出现次种情况时可以进行转换，其转换办法是集合属性纵向展开而元组属性则横向展开。
例4.9 学生实体有学号、学生姓名及选读课程，其中前两个为原子属性而后一个为集合型非原子属性，因为一个学生可选读若干课程，设有学生S1307，王承志，他修读DATABASE，OperatingSystem及ComputerNetwork三门课，此时可将其纵向展开用关系形式如表4.11所示。
　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　表4.11　学生实体
　  （3）联系的转换
　　在一般情况下联系可用关系表示，但是在有些情况下联系可归并到相关的实体中。
　　2. 逻辑模式规范化及调整、实现
　　（1） 规范化
　　在逻辑设计中还需对关系做规范化验证。
　　（2） RDBMS
　　对逻辑模式进行调整以满足RDBMS 的性能、存储空间等要求，同时对模式做适应RDBMS 限制条件的修改，它们包括如下内容：
　　① 调整性能以减小连接运算；
　　② 调整关系大小，使每个关系数量保持在合理水平，从而可以提高存取效率；
　　③ 尽量采用快照（snapshot）,因在应用中经常仅需某固定时刻的值，此时可用快照将某时某刻值固定，并定期更换，此种方式可以显著提高查询速度。
　　3. 关系视图设计
　　逻辑设计的另一个重要内容是关系视图的设计，它又称为外模式设计。关系视图是在关系模式基础上所设计的直接面向操作用户的视图，它可以根据用户需求随时创建，一般RDBMS 均提供关系视图的功能。
关系视图的作用大致有如下几点：
　　（1） 提供数据逻辑独立性：使应用程序不受逻辑模式变化的影响。数据的逻辑模式会随着应用的发展而不断变化，逻辑模式的变化必然会影响到应用程序的变化，这就会产生极为麻烦的维护工作。关系视图则起了逻辑模式与应用程序之间的隔离作用，有了关系视图后建立在其上的应用程序就不会随逻辑模式修改而产生变化，此时变动的仅是关系试图的定义。
　　（2） 能适应用户对数据的不同需求：每个数据库有一个非常庞大的结构，而每个数 据库用户则希望只知道他们自己所关心的那部分结构，不必知道数据的全局结构以减轻用户在此方面的负担。此时，可以关系视图屏蔽用户所不许要的模式，而仅将用户感兴趣的部分呈现出来。
　　（3） 有一定数据保密功能：关系视图为每个用户划定了访问数据的范围。从而在应用的各用户间起了一定保密隔离作用。

　　4.4.5 数据库的物理设计

　　数据库物理设计的主要目标是对数据库内部物理结构作调整并选择合理的存取路径，以提高数据库访问速度及有效利用存储空间，在现代关系数据库中已大量屏蔽了内部物理结构，因此留给用户参与物理设计的余地并不多，一般的 RDBMS 中留给用户参与物理设计的内容大致有如下几种：索引设计、集簇设计和分区设计。

　　4.4.6 数据库管理

　　 数据库是一种共享资源，它需要维护与管理，这种工作称为数据库管理（Database administration）,而实施此项管理的人则称为数据库管理员（Database administration）简称DBA。数据库管理一般包含如下一些内容：数据库的建立、数据库的调整、数据库的重组、数据库的安全性与完整性控制、数据库的故障恢复和数据库的监控。下面对这些管理内容作简单的讨论。
　　1. 数据库的建立
　　数据库的建立包括两部分内容，数据模式的建立及数据加载。
　　（1）数据模式建立 数据模式由DBA负责建立，DBA利用RDBMS中的语言定义 据库名,定义表及相应属性，定义主关键字，索引，完整性约束，用户访问权限，申请空间资源，定义分区等，此外还需要定义视图。　
　　（2）数据加载 在数据模式定义后即可加载，可以编制加载程序将外在程序加载枝到数据模式内，从而完成数据库的建立。
　　2.数据库的调整
　　在数据库建立并经过一段时间运行后往往回产生些不适应的情况，此时需要对此作调整，数据库的调整一般由完成，调整包括下面一些内容：
　　（1） 调整关系模式与视图使之能适应用户的需求；
　　（2） 调整索引与集粗使数据库性能与效率更佳；
　　（3） 调整分区，数据库缓冲区大小以及并发度使数据库物理性能更佳；
　　3.数据库的重组
　　数据库在经过一定时间运行后，其性能会逐步下降，下降的原因主要是由于不断的修改、删除与插入造成的。由于不断的删除而造成盘区内废块的增多而影响I/O速度，由于不断的删除与插入而造成集簇的性能下降，同时也造成了存储空间分配的零散化，使得一个完整表的空间分散，从而造成存取效率下降。基于这些原因需要对数据库进行重新整理，重新调整存储空间，此种工作叫数据库重组。一般数据库重组需要花大量时间，并做大量的数据搬迁工作。实际中，往往是先做数据卸载，然后再重新加载从而达到数据重组的目的。目前一般RDBMS都提供一定手段，以实现数据重组功能。
　　4.数据库安全性控制与完整性控制
数据库是一个单位的重要资源，它的安全性是极端重要的，DBA应采取措施保证数据不受非法盗用与破坏。此外，为保证数据的正确性，是录入库内的数据均能保持正确，需要有数据库的完整性控制。
　　5.数据库的故障恢复
一旦数据库中的数据遭受破坏，需要及时进行恢复，RDBMS 一般都提供此种功能，并由DBA 负责执行故障恢复功能。
　　6.数据库监控
DBA 需随时观察数据库的动态变化，并在发生错误、故障或产生不适应情况时随时采用措施，如数据库死锁、对数据库的误操作等；同时还需要监视数据库的性能变化，在必需时对数据库作调整。