7.5.2 数据库设计
数据库设计是MIS 电子商务系统设计的核心工作之一, 从20世纪70年代以来, 由于计算机硬件技术的进步, 数据库技术得到迅速发展, MIS 中的数据很多是以数据库为组织形式来存储的。
数据库设计在用户需求分析基础上, 进行数据库的概念结构、逻辑结构和物理结构3部分内容的设计工作。数据库设计是根据电子商务系统数据的加工处理过程、数据的分布和存储形式、安全保密要求等方面, 来决定数据的整体组织形式、数据库表或文件的存放形式、数据库表的物理结构和相互关系等一系列的问题。
数据库设计的主要步骤如图7-24所示。
图7-24 数据库设计的主要步骤
1.数据库设计的目标
数据库设计是电子商务系统设计的关键环节之一, 其设计目标是在选定的MIS 电子商务系统基础上建立数据库的过程, 是数据存储的具体实现, 为数据处理过程实现提供数据的输入和输出平台。良好的数据库设计应体现在对电子商务系统各类数据的管理上, 满足组织管理工作的需求, 操作简单, 维护方便等。
数据库设计应满足以下3点要求。
(1) 用户的应用需求
数据库设计首先应满足用户的各类信息要求和各种数据处理请求, 其次要考虑所选用的MIS 电子商务系统性能是否满足用户的需求, 最后考虑数据库对电子商务系统经济效益的影响。
(2) 良好的数据库管理性能
数据库设计除了满足用户的应用需求外, 还应保证电子商务系统数据的完整性、一致性、可靠性、共享性、最小冗余以及数据安全, 同时还要有良好的数据维护功能。
(3) 数据库设计人员的要求
由于数据库设计涉及MIS 开发的各个环节, 因此, 在数据库设计时要求有电子商务系统分析员、设计员、编程人员、数据库理论专家、电子商务系统数据库管理员等人员的共同参与。
2.数据库设计的步骤
数据库设计过程具有一定的规律和标准。在设计过程中, 通常采用“分阶段法”, 即“自顶向下, 逐步求精” 的设计原则。将数据库设计过程分解为若干相互依存的阶段, 称之为步骤。每一阶段采用不同的技术、工具解决不同的问题, 从而将一个大的问题局部化, 减少局部问题对整体设计的影响及依赖, 并利于多人合作。
目前数据库设计主要采用以逻辑数据库设计和物理数据库设计为核心的规范化设计方法, 即将数据库设计分为需求分析、概念结构设计、逻辑结构设计、数据库物理设计、数据库实施、数据库运行和维护6个阶段。
(1) 需求分析阶段
需求分析是对用户提出的各种要求加以分析, 对各种原始数据加以综合、整理, 是形成最终设计目标的首要阶段, 也是整个数据库设计过程中最困难的阶段, 是以后各阶段任务的基础。因此, 对用户的各种需求及数据, 能否进行准确无误、充分完备的分析, 并在此基础上形成最终目标, 是整个数据库设计成败的关键。
(2) 概念结构设计阶段
概念结构设计是对用户需求进行进一步抽象、归纳, 并形成独立于DBMS 和有关软、硬件的概念数据模型的设计过程, 这是对现实世界中具体数据的首次抽象, 完成从现实世界到信息世界的转化过程。数据库的逻辑结构设计和物理结构设计, 都是以概念结构设计阶段所形成的抽象结构为基础进行的。因此, 概念结构设计是数据库设计的一个重要环节。数据库的概念结构通常用E-R 图等来表现。
(3) 逻辑结构设计阶段
逻辑结构设计是将概念结构转化为某个DBMS 所支持的数据模型, 并进行优化的设计过程。由于逻辑结构设计是一个基于具体DBMS 的实现过程, 所以选择什么样的数据模型尤为重要, 其次是数据模型的优化。数据模型有层次模型、网状模型、关系模型、面向对象模型等, 设计人员可选择其中之一, 并结合具体的DBMS 实现。在逻辑结构设计阶段后期的优化工作, 已成为影响数据库设计质量的一项重要工作。
(4) 数据库物理设计阶段
数据库物理设计是将逻辑结构设计阶段所产生的逻辑数据模型, 转换为某种计算机系统所支持的数据库物理结构的实现过程。这里, 数据库在相关存储设备上的存储结构和存取方法, 称之为数据库的物理结构。完成物理结构设计后, 对该物理结构进行相应的性能评价。若评价结果符合原设计要求, 则进一步实现该物理结构; 否则, 对该物理结构做出相应的修改。若属于最初设计问题所导致的物理结构的缺陷, 则必须返回到概念结构设计阶段修改其概念数据模型或重新建立概念数据模型, 如此反复, 直至评价结构最终满足原设计要求为止。
(5) 数据库实施阶段
数据库实施阶段, 即数据库调试、试运行阶段。一旦数据库物理结构形成, 就可以用已选定的DBMS 来定义、描述相应的数据库结构, 装入数据库数据, 以生成完整的数据库, 编制有关应用程序, 进行联机调试并转入试运行, 同时进行时间、空间等性能分析。若不符合要求, 则需调整物理结构、修改应用程序, 如此反复, 直至高效、稳定、正确地运行该数据库电子商务系统为止。
(6) 数据库运行和维护阶段
数据库实施阶段的结束, 标志着数据库电子商务系统投入正常运行工作的开始。
随着对数据库设计的深刻了解和设计水平的不断提高, 人们已经充分认识到数据库运行和维护工作与数据库设计的紧密联系。数据库是一种动态和不断完善的运行过程, 其运行和维护阶段的开始, 并不意味着设计过程的结束, 任何哪怕只有稍微的结构改变, 也许就会引起对物理结构的调整、修改, 甚至使物理结构改变, 因此数据库运行和维护阶段是保证数据库日常活动的一个重要阶段。
本章重点介绍用结构化开发方法和面向对象的开发方法完成数据库设计的主要阶段。
3.结构化的数据库设计
结构化数据库设计方法的概念结构设计阶段是绘制E-R 图建立概念模型; 逻辑结构设计阶段是将E-R 图转化为DBMS 所支持的数据模型, 目前大多DBMS 都支持关系模型;数据库物理设计阶段是将关系模型转换为某种计算机系统所支持的数据库物理结构。
(1) 概念结构设计阶段
采用E-R 方法进行数据库的概念结构设计, 建立概念模型。
E-R 方法是设计概念模型常用的方法。用设计好的E-R 图再附以相应的说明文件可作为阶段成果。E-R 方法有以下3种。
1) 从用户的需求出发, 为每个用户建立一个局部概念模型。建立局部E-R 图的步骤如下。
①确定局部概念模型的范围。
②定义实体。
③定义联系。
④确定属性。确定属性的原则: 属性是不可再分解的语义单位, 实体与属性间应是1 ∶n 的关联, 隶属不同实体型的属性间无直接关联, 不宜隶属任一实体型的属性应作为联系的属性。
⑤逐一画出所有的局部E-R 图, 附以相应的说明文件。
2) 建立全局概念模型。建立全局E-R 图的步骤如下。
①确定公共实体类型。检查存在于多个局部E-R 图的公共实体类型。这里的公共实体类型是指同名的实体类型和具有相同键的实体类型。
②合并局部E-R 图。把局部E-R 图逐一合并到全局E-R 图中, 对每个局部E-R 图,首先合并公共实体类型, 其次合并那些有联系的局部结构, 最后加入其他独立的局部结构。
③消除不一致因素。局部E-R 图间存在的不一致又称冲突。冲突可分为命名冲突、属性冲突、结构冲突等。
命名冲突有同名异义, 异名同义。例如: 商品实体有编号属性, 订单实体有编号属性, 合并后要修改成不一样的名称, 这就是同名异义; 在两个局部E-R 图中都有订单实体的属性, 一个是订单号, 一个是订单编号, 合并后用其中一个属性名称, 这就是异名同义。
属性冲突是指属性域的冲突, 即属性值的类型、取值范围、属性取值单位或取值集合不同。例如: 某些部门用出生日期表示职工的年龄, 而另一些部门用整数表示职工的年龄; 重量单位有的用公斤, 有的用克。
结构冲突是指同一对象在不同应用中的不同抽象。例如, 对于性别, 在某个应用中为实体, 而在另一个应用中为属性。同一实体在不同局部E-R 图中属性组成不同, 包括属性个数、次序。实体之间的联系在不同的局部E-R 图中呈现不同的类型。例如: E1, E2在某一应用中是多对多联系, 而在另一应用中是一对多联系; 在某一应用中E1和E2发生联系, 而在另一应用中, E1、E2、E3三者之间有联系。
④优化全局E-R 图。经合并得到的全局E-R 图需要进行优化。
⑤画出全局E-R 图, 附以相应的说明文件。
3) 概念模型的优化与评审。一个好的全局E-R 图除能反映用户功能需求外, 还应满足下列条件: 实体类型个数尽可能少; 实体类型所含属性尽可能少; 实体类型间联系无冗余。优化就是要满足这3个条件, 即相关实体类型的合并; 冗余属性的消除; 冗余联系的消除。但要注意效率, 根据具体情况可存在适当冗余。
全局E-R 图的优化原则主要有以下3个。
①实体类型的合并。这里的合并不是前面的“公共实体类型” 的合并, 而是相关实体类型的合并。在公共模型中, 实体类型最终转换成关系模式, 涉及多个实体类型的信息要通过联接操作获得。因而减少实体类型个数, 可减少开销, 提高处理效率。一般可以把1∶1联系的两个类型合并。具有相同码的实体类型常常是从不同角度刻画现实世界, 如果经常需要同时处理这些实体类型, 那么也有必要合并成一个实体类型。但这时可能产生大量空值, 因此, 要对存储代价、查询效率进行权衡。
②冗余属性的消除。通常在各个局部结构中是不允许冗余属性存在的。但在综合成全局E-R 图后, 可能产生全局范围内的冗余属性。例如, 在教育统计数据库的设计中, 一个局部结构中含有高校毕业生数、招生数、在校学生数和预计毕业生数, 另一局部结构中含有高校毕业生数、招生数、分年级在校学生数和预计毕业生数。各局部结构自身都无冗余, 但综合成一个全局E-R 图时, 在校学生数即成为冗余属性, 应予以消除。
一般同一非码的属性出现在几个实体模型中, 或者一个属性值可从其他属性值导出,此时应把冗余属性从全局E-R 图中去掉。
冗余属性消除与否, 也取决于它对存储空间、访问效率和维护代价的影响。有时为了兼顾访问效率, 有意保留冗余属性。这当然会造成存储空间的浪费和维护代价的提高。如果人为地保留一些冗余数据, 则应把数据字典中数据关联的说明作为完整性约束条件。
③冗余联系的消除。在全局模式中可能存在有冗余的联系, 通常利用规范化理论中函数依赖的概念消除冗余联系。
下面以某电子商务企业库存管理来看看如何消除冗余联系。图7-25、图7-26分别是该电子商务企业的局部E-R 图和全局E-R 图。
图7-25 某电子商务企业局部E-R 图
图7-26 某电子商务企业全局E-R 图
(2) 数据库的逻辑结构设计
在逻辑结构设计阶段, 将概念结构设计阶段所得到的以概念数据模型表示且与DBMS无关的数据模式, 转换成以DBMS 的逻辑数据模型表示的逻辑模式, 并对其进行优化。这些模式在功能、性能、完整性和一致性约束及数据库可扩充性等方面均应满足用户提出的要求。
1) 关系数据库的逻辑结构设计过程。
①从E-R 图导出初始关系模式。将E-R 图按规则转换成关系模式。
②规范化处理。消除异常, 改善完整性、一致性和存储效率, 一般达到第三范式要求即可。
③模式评价。模式评价的目的是检查数据库模式是否满足用户提出的要求, 包括功能评价和性能评价。
④优化模式。优化包括对于在设计过程中疏漏的要新增关系或属性, 性能不好的要采用合并、分解或选用另外结构等内容。
⑤形成逻辑结构设计说明书。
2) E-R 图向关系模型的转换。
关系模型的逻辑结构是一组关系模式的集合。E-R 图则是由实体、实体的属性和实体之间的联系3个要素组成的。所以要将E-R 图转换成关系模型实际上就是要将实体、属性和实体之间的联系转化为关系模式, 转化方法有以下3种。
①1 ∶1联系的转换方法。一个1 ∶1联系可以转换为一个独立的关系模式, 也可以与任意一端对应的关系模式合并。1 ∶1联系的E-R 图如图7-27所示。
图7-27 1 ∶1联系的E-R 图
根据E-R 图, 转换后的关系模型如下。
工厂(厂号, 厂名, 地点)
厂长(姓名, 职工号, 年龄)
②1 ∶n 联系的转换方法。在向关系模型转换时, 实体间的1 ∶n 关系可以有两种转换方法: 一种是将联系转换为一个独立的关系, 其关系的属性由与该联系相连的各实体集的键以及联系本身的属性组成, 而该关系的键为n 端实体集的键; 另一种方法是在n 端实体集中增加新属性, 新属性由联系对应的1端实体集的键和联系自身的属性构成, 新增属性后原关系的键不变。1 ∶n 联系的E-R 图如图7-28所示。
图7-28 1 ∶n 联系的E-R 图
转换后的关系模型如下。
方案一: 1 ∶n 联系形成的关系独立存在。
仓库(仓库号, 地点, 面积)
商品(货号, 品名, 价格)
仓储(仓库号, 货号, 数量)
方案二: 联系形成的关系与n 端对象合并。
仓库(仓库号, 地点, 面积)
商品(货号, 品名, 价格, 仓库号, 数量)
③m ∶n 联系的转换方法。在向关系模型转换时, 一个m ∶n 联系转换为一个关系。转换方法: 与该联系相连的各实体集的键以及联系本身的属性均转换为关系的属性, 新关系的键为两个相连实体键的组合。m ∶n 联系的E-R 图如图7-29所示。
图7-29 m ∶n 联系的E-R 图
转换后的关系模型如下。
教师(职工号, 姓名, 职称)
课程(课程号, 课程名, 学时)
授课(职工号, 课程号, 成绩)
(3) 数据库的物理结构设计
物理结构设计是根据数据库管理电子商务系统的特征, 确定数据库的物理结构即存储结构。对一个给定的逻辑数据模型选取一个最适应应用环境的物理结构(存储结构与存取方法) 的过程, 就是数据库的物理结构设计。
1) 物理结构设计的内容。物理结构设计依赖于具体的DBMS 电子商务系统。要着手物理数据库设计, 就必须充分了解所用DBMS 的内部特征, 特别是文件组织方式、索引和它所支持的查询处理技术。
通常对关系数据库物理结构设计的主要内容: 为关系模式选择存取方法; 设计关系、索引等数据库文件的物理存储结构。
2) 存储结构的选择。物理数据库设计的主要目标之一就是以有效方式存储数据。数据库包含两种存储结构, 分别为顺序存储结构和链式存储结构。顺序存储结构是把逻辑上相邻的结点存储在物理位置上相邻的存储单元中, 结点之间的逻辑关系由存储单元的邻接关系来体现; 而链式存储结构是在计算机中用一组任意的存储单元存储线性表的数据元素。
3) 性能评价。衡量一个物理结构设计的好坏, 可以从时间、空间、维护开销和各种用户要求着手, 具体有以下3个方面。
①存取效率。
②存储效率。
③其他性能。
4.面向对象的数据库设计
目前大多数DBMS 数据库都支持面向对象的设计方法。面向对象的数据库设计的主要任务就是将对象模型映射成数据库模式。相对于结构化的数据库设计而言, 面向对象的数据库设计方法更具优势, 因为它可以实现应用电子商务系统对象到数据库对象的直接映射, 转换自然、方便。同时, 数据库逻辑模型又可以直接模拟电子商务系统中各个实体对象的关系。
面向对象的电子商务系统分析阶段建立了实体类图, 它描述了实体类及其之间的静态关系, 不仅定义电子商务系统中的实体类, 表示类之间的联系(关联、依赖、聚集等),还阐述了类的内部结构(类的属性和操作)。
由于电子商务系统数据库中的每张表都有对应的实体类, 因此, 在面向对象的开发方法中通常采用实体类图来描述数据库结构。它不仅指明了电子商务系统数据库中有哪些表和表的具体组成, 还表明了各表之间的联系。
(1) 对象在数据库中的存放策略
用关系数据库存放对象的基本策略: 把由每个类直接定义并需要永久存储的全部对象实例存放在一个数据库表中。每个这样的类对应一个数据库表, 经过规范化之后的类的每个属性对象对应数据库表的一个属性(列), 类的每个对象实例对应数据库表中的一个元组(行)。
(2) 确定关键字
一个数据库表的关键字是一组能够唯一标识该表的每个元组(行) 的属性。对类而言, 关键字就是一组能唯一标识该类的每个对象实例的属性, 用尽可能少的属性(最好是只用一个属性) 作为关键字将给查询和更新操作带来方便。采用对象标识符OID (对象唯一的标识符) 作为相应的数据库中所有表的主键, 也是常用的手段。
(3) 类映射成表的策略
实现类到数据库表的映射, 既可以从分析类图入手, 也可以从设计类图开始。因为分析类图与关系模型更接近, 而且没有显示关联的方向, 因此最好先从分析类图入手将分析类映射到表, 然后结合设计类图进行适当地调整和修改, 并且根据设计类的属性类型确定表中字段的类型。
将单个简单类映射成表, 一般按下列步骤进行。
①类的名称映射成关系模型的名字。
②类的所有属性映射成关系模型的属性。
③类的关键字映射成关系模型的主键, 同时指出关系模型中的外键、列的域以及能否为空值等选项。
④类中任意一个对象集映射成关系模型的一个实例(即关系), 对象集中每一个对象称为此关系中的一个元组。
单个简单类映射成关系模型如图7-30所示。
图7-30 单个简单类映射成关系模型
(4) 关系映射的策略
关系映射不仅必须将类或对象映射到数据库中, 还必须将类或对象之间的关系进行映射。类之间有4种类型的关系: 泛化、关联、聚合和组合。要有效地映射这些关系, 必须理解它们之间的差异。
从数据库的角度来看, 关联和聚合/组合之间的唯一不同是对象相互之间的绑定程度。对于聚合和组合, 在数据库中对整体所做的操作通常需要同时对部分进行操作, 而关联就不是这样。
对象间无论是聚合关系还是关联关系, 从数据库的角度来看, 都是通过表的联系来实现的。关系数据库中的关系是通过使用外码来实现的, 即将主表中的主码加入另一张表的属性作为外码。一对一和一对多的关系就是通过这种方法实现的。其中, 对象的OID 就是联系的外码。下面主要介绍关联关系、聚合关系和单继承关系的映射。
1) 关联关系的映射。关联关系可分为一对一、一对多和多对多关联。
①一对一的关联的映射。一对一关联映射的关系模型有3种算法。
算法1: 一般的一对一的关联, 其关联每一端的类映射为一张表, 外键可放置在任意一边的表中, 具体情况依赖于性能等因素。
算法2: 将两个类合并映射成一张表。映射过程如图7-31、图7-32所示。
图7-31 一对一的关联对象模型
图7-32 一对一的关联映射为关系模型
算法3: 如果一对一关联是可选的1 (0..1) 或强制的1 (1), 则外键放置在可选的一端, 且该外键不能为空值。映射过程如图7-33、图7-34所示。
图7-33 可选的1或强制的1的一对一的关联对象模型
图7-34 可选的1或强制的1的一对一的关联映射为关系模型
②一对多的关联的映射。其指的是将外键放置在“多” 的一方。如果“1” 方是可选的, 则外键可以有空值, 以表明“多” 方的记录可以独立于“1” 方存在; 如果“1” 方是强制性的, 则外键一定要非空。映射过程如图7-35、图7-36所示。
图7-35 一对多的关联对象模型
图7-36 一对多的关联映射为关系模型
③多对多的关联的映射。实现多对多关系, 通常需要建立一张关联表, 并把它与关系两端的表建立联系。在传统实现方式中, 关联表的属性包含关系中的两张表的主键, 并且关联表的主键往往是它们的组合。映射过程如图7-37、图7-38所示。
图7-37 多对多的关联对象模型
图7-38 多对多的关联映射为关系模型
2) 聚合关系的映射。将类间的聚合关系映射为关系模型的算法: 整体类与各个部分类分别映射成关系模型, 整体类映射的关系模型的属性包含原有的所有属性, 但各个部分类映射的关系模型的属性除包含原有的所有属性外, 再加上整体类对象的关键词属性。映射过程如图7-39～图7-41所示。
图7-39 聚合关系的对象模型
图7-40 整体类映射为关系模型
图7-41 部分类映射为关系模型
3) 单继承关系的映射。某类间具有单继承关系, 映射成关系模型有3种算法。
算法1: 将父类与各子类分别映射成关系模型。映射过程如图7-42、图7-43所示。
图7-42 单继承关系对象模型
图7-43 单继承关系映射为关系模型
算法2: 将父类的所有属性复制到所有子类, 从而清除父类, 再把各个子类分别映射成关系模型, 并消除重复的属性。映射过程如图7-44所示。
图7-44 单继承关系映射为关系模型
算法3: 仅创建一个关系模型, 使其包含父类及所有子类的全部属性(消除重复的属性)。映射过程如图7-45所示。
图7-45 单继承关系映射为关系模型