分布式数据库设计报告

分布式数据库设计报告案例：书店管理信息系统
学号：
专业：
姓名：
目录
1 需求分析.......................................... 错误!未定义书签。

1.1 案例背景.................................... 错误!未定义书签。

1.2 系统功能需求................................ 错误!未定义书签。

1.3 系统数据流图................................ 错误!未定义书签。

2 分布式数据库设计.................................. 错误!未定义书签。

2.1 设计目标.................................... 错误!未定义书签。

2.1.1 总体设计目标........................... 错误!未定义书签。

2.1.2 总店设计目标........................... 错误!未定义书签。

2.1.3 分店设计目标........................... 错误!未定义书签。

2.2 概念结构设计................................ 错误!未定义书签。

2.3 逻辑结构设计................................ 错误!未定义书签。

2.4 分片设计.................................... 错误!未定义书签。

2.5 分配设计.................................... 错误!未定义书签。

2.6 物理设计.................................... 错误!未定义书签。

3 总结.............................................. 错误!未定义书签。

书店管理系统分布式数据库设计
1 需求分析
要对书店管理信息系统进行分布式数据库设计，首先应了解该案例的背景信息，掌握系统功能需求，根据系统的具体业务需求判断数据的具体流向，然后在此基础上对整个系统进行分布式数据库设计，以满足客户需求。

1.1 案例背景
随着书店效益的增加，书店规模越来越大，分店数量越来越多，这就要求书店管理信息系统应具备分布式管理数据的能力。

传统的书店管理系统采用集中式的数据管理方式，主要有两种形式：一是各个分店各自存储自己的数据信息，各家分店之间没有数据关联，数据存储分散，而且冗余量大，经常出现数据不一致的问题，不易于统一管理及数据库的维护；二是各个分店由一个总店数据库保存数据信息，各个分店联网登录该总数据库存储数据，这样经常造成数据访问瓶颈，造成资源利用率低下，而且效率较低。

因此，对传统的书店管理信息系统进行数据库的分布式设计已成为此类用户的迫切需求。

1.2 系统功能需求
书店分布式数据管理是由物理上分布在一个城市的许多书店销售点组成的，包括由一个总店和其下属的多个分店。

每个店面都是一个独立的场地，每个场地上都有属于自己的局部业务应用，同时也能够支持全局的业务应用。

本系统在总体上要实现的功能包括库存管理、进货管理、批发销售、磁卡管理、退货管理、结算、查询统计等功能。

通过以上分析，书店管理信息系统根据用户的需求，总体上需满足以下要求：（1）系统用户基本设置功能：主要包括客户、分店负责人、营业员及管理员的不同权限设置功能、密码设置、更改功能等。

（2）图书信息管理功能：主要包括图书类别管理和图书书号、书名、作者、以及库存量等基本信息的录入、修改、删除、查询及报表生成等功能。

（3）员工信息管理系统：主要包括对书店员工基本信息的增加、修改、删除和查询以及报表生成功能，记录书店员工绩效与职责，薪资水平等。

（4）进销存管理功能：主要包括供应商管理，记录各个分店库存状况，统计
总库存量，以及各分店的销售情况和图书供求状态。

（5）会员管理功能：包括会员客户基本信息的管理，客户订单管理功能，各个会员基本情况管理，包括记录会员生日信息，会员卡消费状况等。

1.3 系统数据流图
传统书店采用集中式数据管理，数据库中存放各类图书信息，供应商信息，会员信息以及员工信息等数据。

顾客购书时，给出顾客会员编号，销售人员操作系统，从数据库中调出该图书详细信息，并更改信息，售书完毕。

当藏书量不足时，采购人员根据供应商信息采购图书。

同时，系统管理人员管理数据库信息并进行系统维护。

其系统数据流图如图1所示：
图1 系统总数据流图
2 分布式数据库设计
分布式数据库系统是数据库系统与计算机网络相结合的产物，它具备三方面的特点：一是物理分散性，即数据分散存储在各个不同的场地上；二是逻辑整体性，即分散的数据库在逻辑上是一个整体，在逻辑上就好像是一个集中的数据库系统；三是场地自治性，即各个场地上的数据由本地的数据库管理系统DBMS管理，具有自治的处理能力，能够独立完成本站点的局部业务应用。

2.1 设计目标
2.1.1 总体设计目标
根据分布式数据库设计的总体要求，结合本书店案例的具体业务需求，该案例的总体设计目标如下：
（1）安全性：包括保证网络安全、数据库安全、审计安全、磁卡安全等。

（2）配置方便：分布式数据库是物理上分散的，逻辑上统一的数据库系统。

其地理位置分散且实现复杂，系统的初始配置也比较繁琐。

而且系统采用C/S模式，这就要求其在配置上尽可能的简单。

（3）可扩充性：该分布式数据库的设计必须保证一定的可扩充性，以满足业务发展的需求，当系统增加分店时，必须保证系统能够方便的将其加入，而并不需要修改源程序。

（4）可靠性：针对系统运行时可能遇到的各种软硬件故障，分布式数据库应提供一定的系统恢复机制和数据备份功能，使故障发生时遭受的损失最小。

（5）可维护性：分布式数据库的设计必须保证可维护性，保证系统中数据的一致性、完整性，充分避免数据的冗余，使数据得到充分利用。

2.1.2 总店设计目标
分布式数据库系统是地理上分散而逻辑上集中的数据库系统，它通过计算机网络将地理位置上分散的各个局域节点连接起来，共同组成一个逻辑上统一的数据库系统。

该案例中的总店在整个分布式数据库系统中处于核心的地位，它包括基本信息维护子系统，采购子系统，库存子系统，销售子系统，磁卡管理子系统以及查询子系统。

根据系统的需求分析及总店具备的相应功能，依据该分布式数据库的设计目标，在本案例中定义总店存储该书店所有店面的员工信息、本店的会员信息，存储各个书店的藏书信息，各个店面的信息，以及各个店面的供应商信息。

2.1.3 分店设计目标
分店的设计更趋向于局部应用，同时要保证支持全局应用。

本书店案例中的分店的数据库系统仅包括局部销售管理子系统和磁卡管理子系统。

其中，分店的供应商信息以及采购管理均统一由总店管理，以保证总店对各个分店的有效控制与支配，当分店库存不足时，由总店为分店采购图书并统一配货。

根据分店具备的具体功能和业务需求，在本案的设计中定义各个分店只存储本分店的员工信息，本分店的会员信息，本分店的藏书信息以及各个店面的信息。

2.2 概念结构设计
概念结构设计是整个数据库设计的关键。

概念结构是对现实世界的一种抽象，所谓抽象是对实际的人、物、事和概念进行人为处理，抽取所关心的共同特性，忽略非本质细节，并把这些特性用各种概念精确地加以描述，这些概念组成了某种模型，描述概念模型的有力工具是E-R模型，这种E-R模型能够说明实体间语义的联系。

在本案例中，定义的实体包括图书、店面、供应商、员工以及会员。

其实体属性图分别图2-图6所示：
图2 图书实体属性图
图3 店面实体属性图
图4 供应商实体属性图
图5 员工实体属性图
图6 会员实体属性图
根据系统的业务需求，该分布式数据库系统的总体E-R图如图7所示。

其中，分店与总店均各自销售图书，管理各自会员信息。

分店负责人负责分店的管理，总店负责人负责总店的管理，总店负责给分店配货，总店负责联系供应商进行采购管理，而分店不参与采购书籍。

图7 分布式数据库系统总体E-R图
2.3 逻辑结构设计
逻辑结构设计就是把概念结构设计阶段设计好的E-R图转换为与数据模型相符合的逻辑结构，将E-R图转化为关系模式实际上就是将实体型、实体的属性和实体之间的联系转换为关系模式。

但是首先要规范化数据的存储结构，因为任何一个数据库都不可能是一层不变的，而是在经常地变化着。

由于应用的需要，随时可能要求修改数据库。

这就要求在对数据进行插入、修改和删除时，尽可能消除产生的相互影响，在引进新的数据时，尽可能减少对原有的数据结构的修改，从而减少对应用程序的影响。

因为修改一个处理逻辑要比修改一个数据存储的结构容易，所以要用规范化方法设计数据存储结构，提高数据的完整性、一致性和
可修改性。

本系统中将数据的数据结构转换成第三规范化形式，首先把所有的有重复数据组项的数据结构分解成若干二维表形式的数据结构，指定一个或若干数据元素作为关键字，唯一标识每个元组，这样就将非规范化的数据结构转换成第一规范化形式。

再确保所有的非关键字数据元素都完全函数依赖于整个关键字，消除某些数据元素部分函数依赖于整个关键字，这就将第一规范化形式转换成了第二规范化形式。

最后检查所有的非关键字数据元素是否彼此独立，如果不是，消除传递依赖关系，通过去掉冗余的数据元素或用分解的办法，转换成若干满足这种要求的数据结构，这就将第二规范化形式转换成了第三规范化形式。

本系统中m:n的联系转换成关系模式时，把与该联系相连的各实体的主码以及联系本身的属性均转换为关系的属性，各实体的主码组成关系的主码或关系主码的一部分。

对于1:n的联系，将1端对应的主码转换为n端的外码。

另外，本系统对于具有相同码的关系模式进行合并，如系统总体E-R图中，出现的两个m:n关系的联系“订购”，在对其进行关系模式转化时，将得到的两个具有相同码的关系模式合并为一个关系模式“订购项目”。

通过以上分析，结合系统总体E-R图，本系统中的实体、实体的属性和实体之间的联系可转化为如下关系模式：
图书（编号，藏书单位，书名，作者，出版社，书目类别，定价，数量）店面（店面编号，地址，店长，联系电话，开业时间，店面等级）
供应商（编号，负责人姓名，地址，电话，供应店面，单位名称）
员工（编号，姓名，性别，电话，家庭地址，出生年月，单位编号，职位）会员（编号，姓名，性别，电话，年龄，家庭地址，所属店铺）
订购项目（会员编号，图书编号，藏书单位，定价，数量）
根据本案例系统的要求和转换的关系模式建立一个数据库，数据库中各个表的结构设计结果如表1到表6所示。

表1 图书信息表
本书店案例的逻辑结构设计应用了规范化理论，对数据模型进行了优化，得到的关系模式满足第三范式要求。

本案例的以下设计均是在此逻辑设计结构的基础上展开，并应用于各个场地。

通过以上各个表的逻辑设计结构，可以按照用户需求添加元组，得到实际用户视图，但是本案例为书店管理信息系统的分布式数据库设计，需要根据各个表的逻辑结构，结合书店的地理位置以及分布式设计需求，对关系进行分片设计，即对数据进行分片存储，以便于分布地处理数据，解决传统的集中式处理方式存在的不足之处，以下详细讨论本案例的分片设计过程。

2.4 分片设计
分片是把一个全局对象细分为若干个逻辑片段的过程。

有两种基本的数据分片方法，水平分片与垂直分片。

水平分片相当于对某一全局对象的实例进行选择而得到的子集；垂直分片相当于对全局对象在其属性集上进行投影操作。

根据以上分析，对本案例得到的逻辑关系模式进行分片设计。

根据总店设计与分店设计原则可知，以“图书”关系为例，总店存储所有书店的藏书信息，分店仅存储本分店的藏书信息，所以对于“图书”关系，以其属性“藏书单位”的不同取值为分片条件，对其进行水平分片，以得到不同的逻辑片段。

在本案例中，设有1家总店，2家分店，总店的“藏书单位”属性取值为0，分店的“藏书单位”属性取值分别为1和2。

其中“图书”关系表的部分元组如表7所示，由总店存储该“图书”关系总表。

表7 图书关系中部分元组
该关系表中有6种图书，分别为《丰乳肥臀》、《分布式数据库》、《计算机网络》、《自然辩证法》、《志摩的诗》和《猛虎集》，各种图书的藏书单位不同，比如，《丰乳肥臀》只有总店出售，而《分布式数据库》在总店与两家分店均出售。

所以对于“图书”关系进行水平分片设计，可以得到如下内容：
分片属性：藏书单位
分片条件：藏书单位=0；藏书单位=1；藏书单位=2
各个子关系的内容分别如表8到表10所示。

其中，由各个分店分别存储属于各自店面的分片关系。

表8 总店的图书
表9 分店1存储的图书关系
表10 分店2存储的图书关系
其中，各个分片与总表的关系模式相同，即表2-表4均与表1的关系模式相同；而且各表的并集就是总的“图书”关系表；各个分片之间的交集为空，所以满足分片定义，而且满足总店设计与分店设计要求。

按照总店设计与分店设计要求，总店与分店均存储各个店面的信息，以方便各个店面的联系。

所以对“店面”关系不需要进行分片设计，各个场地分别进行复制存储。

其店面关系的部分元组如表11所示：
表11 店面关系中部分元组
按照总店设计与分店设计要求，只有本店存储各个店面的供应商信息，所以对“供应商”关系不需要进行分片设计，只在总店存储其关系总表。

“供应商”关系的部分元组如表12所示：
表12 供应商关系中部分元组
按照总店设计与分店设计要求，总店存储所有店面的员工信息，各个分店只存储自己的员工信息，所以对于“员工”关系，以“单位编号”为分片属性，按照单位编号=0，单位编号=1，单位编号=2的条件对“员工”关系进行水平分片，其中“员工”关系的部分元组如表13所示，各个分片关系表如表14到表16所示。

其中，总店存储员工关系总表，各个分店存储属于各自店面的分片关系。

表13 员工关系中部分元组
表14 总店的员工关系
表15 分店1存储的员工关系
表16 分店2存储的员工关系
对“会员”关系进行分片设计，以“所属店铺”为分片属性，按照所属店铺=0，所属店铺=1，所属店铺=2的条件进行分片。

其中，各个店面分别存储自己的会员信息，即总店仅存储总店的会员信息，各个分店仅存储各个分店的会员信息，其总逻辑关系的部分元组如表17所示，各个分片关系如表18到表20所示。

表17 会员关系中部分元组
表18 总店存储的会员关系
表19 分店1存储的会员关系
表20 分店2存储的会员关系
按照总店设计与分店设计原则，仅由总店存储订购项目关系，所以对于“订购项目”关系不需要分片设计，其关系的部分元组如表21所示：
表21 订购项目关系中部分元组
2.5 分配设计
根据系统的功能需求，结合以上分析，在本案例中，图书关系、员工关系以及会员关系分为3个子关系，其中，会员关系为非复制型分配，即各个店面分别存储自己的会员信息，所以会员关系属于数据分割型存储。

而供应商关系与订购项目关系只存储在总店，所以它们也属于非复制型分配。

而对于图书关系和员工关系来说，由于各个分店只存储自己的员工信息与藏书信息，而总店存储所有店面的员工信息和藏书信息，所以图书关系与员工关系均属于复制型存储。

其具体的分配模型如图8所示：
图8 分配设计模型
2.6 物理设计
数据库性能的好坏很大程度上取决于数据库的物理设计，而不仅仅是关系模式设计的好坏和SQL语句写的好坏。

通常关系数据库物理设计的内容包括：为关系模式选取存取方法，设计关系和索引等数据库文件的物理存储结构。

数据库系统是多用户共享的系统，对同一个关系要建立多条存取路径才能够满足多用户的多种应用要求。

物理设计的第一个任务就是要确定选择哪些存取方法，即建立哪些存取路径。

目前，常用的存取方法有三种：一是索引方法，目前主要是B+树索引方法；二是聚簇方法；三是HASH方法。

在本案例中，可对访问频繁的“图书”关系建立聚簇索引，建立索引后，基
表中的数据也需要按指定的聚簇属性值的升序或降序存放，这里是按照编号的升序存放。

也就是说，聚簇索引的索引项顺序与表中元组的物理顺序一致。

这样可以提高检索效率。

具体操作如下：
CREATE CLUSTER INDEX 图书编号 ON 图书（编号）；
即在图书表的编号列上建立一个聚簇索引，而且图书表中的记录将按照编号值的升序存放。

数据库物理设计的第二个方面是确定数据库的存储结构，这主要是指确定数据的存放位置和存储结构，包括：确定关系、索引、聚簇、日志、备份等的存储安排和存储结构，确定系统配置等。

在本案例中，数据的存储是按照分配设计分场地进行存储，各个场地上又是按照集中数据库确定存放位置的原则来确定数据的存放位置。

比如在各个分店，图书关系存取频率较高，员工关系存取频率较低，可将这两个关系在每个分店场地分开存放，以提高系统性能。

3 总结
在本书店案例的分布式数据库设计中，采用了Top-Down的设计方案。

从需求分析开始，分别进行概念设计，模式设计，分片设计，分配设计，物理设计等一系列设计过程。

该设计过程是系统从无到有的设计与实现过程，比较适合该书店管理信息系统的分布式数据库设计。

该分布式数据库设计过程基于分布式应用需求，符合分布透明性原则，满足整个数据库系统在物理上分散而逻辑上统一的设计要求，基本能够实现用户的功能需求，改善书店工作效率，解决原来集中式处理的传输瓶颈问题，有效的利用了局部数据来处理资源，使系统基本实现负载均衡。

但是该设计仍然存在一些不足之处，比如对于将概念模式转换为逻辑模式时，可以按照更高的范式级别来进行模式设计，以进一步减少数据冗余。

还可以对各分片按照水平分片与垂直分片原则再进一步划分，以便进一步减少网络传输量，进一步增加事务处理的局部性。

所以该系统仍然需要进一步完善。