SQL Server数据库设计的案例分析

数据库设计的案例分析

一、教学管理

1. 基本需求

某学校设计学生教学管理系统。学生实体包括学号、姓名、性别、生日、民族、籍贯、简历、登记照，每名学生选择一个主修专业，专业包括专业编号和名称，一个专业属于一个学院，一个学院可以有若干个专业。学院信息要存储学院号、学院名、院长。教学管理还要管理课程表和学生成绩。课程表包括课程号、课程名、学分，每门课程由一个学院开设。学生选修的每门课程获得一个成绩。

设计该教学管理的ER模型，然后转化为关系模型。

若上面的管理系统还要管理教师教学安排，教师包括编号、姓名、年龄、职称，一个教师只能属于一个学院，一名教师可以上若干门课程，一门课程可以有多名老师来上，每个教师所上的每门课都有一个课堂号和课时数。试修改上题的ER模型，将教师教学信息管理增加进去。

2. 参考设计：

图一教学管理ER图

由ER模型转换的关系模型是：

学生（学号，姓名，性别，生日，民族，籍贯，专业号，简历，登记照）专业（专业号，专业，专业类别，学院号）

学院（学院号，学院，院长）

课程（课程号，课程名，学分，学院号）

成绩（学号，课程号，成绩）

（题目分析：本题中有学生、专业、学院、课程四个实体。一个学生只有一个主修专业，学生与专业有多对一的联系；一个专业只由一个学院开设，一门课程只由一个学院开设，学院与专业、学院与课程都是一对多的联系；学生与课程有多对多的联系。

在转换为关系模型时，一对多的联系都在相应的多方实体的关系中增加一个外键。）

增加教师，ER图如下。

图二有教师实体的教学管理ER图

3. 物理设计

基于Access的数据库结构设计如下。

指定数据库文件的名称，并为设计好的关系模型设计表结构。

数据库文件保存在“E:\教学管理\”文件夹中，数据库文件名：教学管理.MDB。

表包括：学院、专业、学生、课程、成绩单。对应表结构如表1-2至表1-6所示。

表1-1 学院

表1-2 专业

表1-3 学生

表1-4 课程

表1-5 成绩单

1. 当我们进行物理设计时，如果将全校的学生放置在一个关系（表）中，势必带来存储空间大、处理效率低的问题。怎么解决？

2. 如果管理研究生，带来的设计影响是什么？如何解决？

3．在管理教师信息时，如果将教师分类：教师、研究生导师。研究生导师存储“研究方向、学生人数”等信息，怎样设计。

附：教学管理数据库参考数据如表1-1～表1-5所示。

表1-1 学生表

表1-2 学院表

表1-2 专业表

表1-4 课程表

表1-5 成绩单

二、图书销售

建立某中小型书店图书销售管理信息系统的数据库。

1. 基本需求分析

1）组织结构

对组织结构的分析有助于分析业务范围与业务流程。书店的组织结构如图三所示。

图三书店组织结构简图

其中，书库是保存图书的地方；购书/服务部负责采购计划、读者服务、图书预订等业务；售书部负责图书的销售。财务部负责资金管理；人事部负责员工管理与业务考核。

2）业务分析

对于信息处理系统来说，划分系统边界很重要，即哪些功能由计算机来完成，哪些工作在计算机外完成。这些要通过业务分析确定。同时，业务流程中涉及的相关数据也通过业务分析得到归类和明确。在业务分析的基础上，确定数据流图和数据字典。

本系统主要包含以下业务内容。

①进书业务。事先采购员根据订书单采购图书。然后将图书入库，同时登记相应的图书入库数据。

本项业务涉及的数据单据和表格有：进书单（包括进书单编号、日期、金额、经手人等）和进书单细目（一个进书单可能有若干种图书。进书单的细目数据包括每种图书的信息、定价、进价或折扣，数量），以及书库账本（图书信息、库存数量、价格等）。

②售书业务。售书员根据读者所购图书填写售书单（如图四所示）。同时，修改库存信息。

本项业务涉及和产生的数据表格有：售书单（包括售书单编号、售书日期、金

额、员工）、售书细目（一个售书单可能有若干种图书。售书细目包括该次售书的书籍编号、售出数量、折扣、售出价格等），以及书库账本。

图四售书单样式

③图书查询服务业务。根据读者要求，提供本书店特定的图书及库存信息。

本项业务涉及的主要数据是书库账本。

④综合管理业务。包括进书信息、销售信息、库存信息的查询、汇总和报表输出。

本项业务涉及所有的进书数据、销售数据和库存数据等。

3）处理的数据

上面的分析将本系统的业务归纳为4项。在业务分析的基础上，应该画出系统的数据流图。整个系统的分层数据流图将揭示一个系统内全部的数据项、数据结构、数据存储以及对数据的加工处理功能。在此基础上就可以建立系统的数据字典。本书不讨论数据流图和完整的数据字典规范等内容，仅对最后建立数据库所需要的数据进行分析说明。

在上述4项业务中涉及到的业务数据包括：进书数据、库存数据、销售数据。在这些数据中又涉及到图书数据、员工数据等，而图书数据与出版社有关，员工与部门有关。

因此，将所有数据进行归类分析，书店销售管理信息系统要处理的数据应该包括：

企业部门信息（组成：部门编号、部门名、办公电话）；

员工信息（组成：工号、姓名、性别、生日、职务、所属部门、薪金）；

出版社信息（组成：出版社编号、出版社名称、地址、联系电话、联系人）；

基本图书信息（组成：图书编号、ISBN、书名、作者、出版社、版次、出版日期、定价、图书类别、备注）；

进书单及细目（组成：进书单号、日期、{进书细目}、金额、业务员）；

售书单及细目（组成：售书单号、日期、{售书细目}、金额、业务员）；

书库账本（组成：图书编号、库存数量、平均进价折扣、备注）。

这些就是书店销售管理信息系统要处理的各种对象，每一种对象由括号内的属性组合在一起来描述。这些属性有的是基本数据项，有的是数据项集合（由“{、}”括起来），数据项集合要做进一步的说明。

例如，“{进书细目}”由“序号、{基本图书信息}、进价或折扣、数量”等属性组成；“{售书细目}”由“序号、图书编号、售价或折扣、数量”等属性组成。

当所有数据对象都归纳完毕，就可以编制数据字典了。在数据字典中，要对所有这些数据项、数据项集合等的命名、取值方式和范围、作用等进行明确而无异义说明。

4）处理功能分析

数据字典不仅记载所有数据的详情，也要详细记载所有对数据的处理功能。

①进书业务。当进书业务发生时，将所进图书入书库，然后存储进书单及细目数据，同时根据进书单登记图书库存数据。

当登记图书库存数据时，可能有两种情况：新图书或已有图书入库。

对于新图书，本业务要将图书的完整信息记载下来，然后记载图书进价和数量；

已有图书是指同一种书。但同一种书可能有版本方面的区别。为简单起见，规定：“ISBN号”与“版次”相同的就是同一种书，图书编号相同。对于已有图书，将本次进书数加到该图书的库存数中即可，但本次的进价折扣与以前库存的该书的折扣可能存在差异。为了便于计算成本和售书收益，入库已有图书时，这里采用的方法是：将已有图书占用的资金和本次入库的资金加在一起，然后重新计算一个平均价格折扣。因此，书库中该图书的价格折扣是当前所有库存图书占用资金除以当前

库存数量后计算的折扣。

②售书业务。根据读者所购图书的售书单存储售书单及细目数据，这是售书的业务数据。同时，修改图书的库存信息。

③图书查询服务业务。查询服务的输入是读者所提要求，输出是相关图书的库存信息。为方便读者，可以针对书名、ISBN、作者、版次、出版社提供单个或多条件组合查询。

④综合管理业务。管理人员需要定期或不定期汇总统计或查询进书信息、销售信息、库存信息，并按照管理要求制作业务报表。

通过进书单及细目可以对进书业务进行查询、统计汇总和报表输出。

通过售书单及细目可以对售书业务进行查询、统计汇总和报表输出。

通过库存账本可以对图书库存情况进行查询、统计汇总和报表输出。

2. ER模型分析设计

（1）基本实体和联系

首先确定实体类别以及它们各自的属性构成，指出实体标识符，并尽量规范属性名，避免同名异义或异名同义。确定实体后，就可以分析实体之间的联系。

可以很容易确定，部门、员工、出版社、图书、书库是不同的实体。

部门的属性：部门号、部门名、办公电话；

员工的属性：工号、姓名、性别、生日；

部门与员工发生聘用联系。这里规定一个员工只能在一个部门任职，它们是1：n联系。当联系发生时，产生职务、薪金属性。

出版社属性：出版社编号、名称、地址、联系电话、联系人；

图书属性：图书编号、书名、作者；

出版社与图书发生“出版”联系。一本图书只能在一家出版社出版。这是1：n 联系。当联系发生时，产生ISBN、版次、出版日期、定价、图书类别、备注等属性。

由员工购进图书，所以进书业务是员工与图书发生联系的结果。一名员工可以进多种图书，一种图书可由多个业务员购进，所以它们是m：n联系。“进书”联系产生“进书单”属性，进书单本身又由“日期、图书细目、数量、金额”等多个属

性构成，所以是多值的组合属性。

与进书业务类似，售书业务是员工将图书售给读者。本系统不保存读者信息，所以售书是员工与图书发生联系，“售书单”是“售书”联系的属性。

当图书购进后，图书要入书库保存。书库与图书发生“保存”联系。这里假定图书是集中式保管，只有唯一一个书库，所以书库不需要标明属性。书库与图书之间是1：n联系。“保存”联系的属性有数量、存书的价格折扣、存放备注。

(2) 需要解决的问题—售书与进书

以售书为例，当员工在书店售书时，员工就与图书发生“售书”联系。由于一个员工可以售出多种图书，一种图书可以从多名员工那里售出，因此员工与图书的“售书”联系是m：n。在实际售书时，由于一名读者可能购买多种图书，所有这些图书构成一张完整的售书单，所以“售书单”是售书联系的属性，ER图如图五所示，图中略去员工和图书的实体属性。

图五图书销售联系的ER图

仔细分析“售书单”属性，可以发现，售书单不是一个单一的数据，它是由多项内容构成，如日期、图书种类和数量、金额等属性。

对于属性来说，无论是实体属性还是联系属性，根据属性结构特点可以分为原子属性或组合属性。原子属性就是属性是一个不可分割的整体，例如员工的“性别”、“年龄”等。但有些属性是由几个子属性组合起来的。例如，对于员工“薪金”，如果要分解为“基本工资”、“岗位工资”、“业绩提成”等，则成为组合属性。因此，有些属性到底是原子属性还是组合属性，要根据设计的规定。象“姓名”，我国一般是作为一个整体，但西方则分为“First Name”和“Last Name”。而这里的“售书单”属性，很明显只能是组合属性。

从属性的取值情况可以分为单值属性或多值属性。单值属性就是属性只有一种取值，如员工性别、生日等；而多值属性就是该属性可能有多种取值。例如，如果

允许员工兼职，则他的职务可能就不只一个值。另外，若在员工中增加“学位”属性，有的员工可能就有几个学位。

假设在员工实体中增加一个“社会关系”属性，它由“姓名、年龄、关系、地址”组成，所以是组合属性，同时，由于一个员工可能有多个社会关系，则对员工来说，该属性又是多值属性。前述的“售书单”属性，由于一个售书单内部可包含多种图书，所以它也是多值属性。

当实体或联系存在多值、组合属性时，对ER图的表述带来了一定的困难。因为ER图将来将转化为关系模型，而关系中属性必须是原子的，因此在ER图中必须有专门的处理。

对于单值的组合属性，一般将组合属性的子属性分解为独立属性。如“薪金”，若要了解其构成，就可变成。

而对于多值属性，一般会将这个属性变成实体来对待。这样，它与原实体的关系就变成实体间的联系。例如，将图三中的“售书单”当作实体，该实体分别与“员工”和“图书”实体发生联系。一名员工可负责多份售书单，而一份售书单只由一名员工负责，他们之间是1：n联系；一份售书单中可包含多种图书，一种图书可由不同的售书单售出，他们之间是m：n联系。这样，图五所示的ER图就变成图六的样子。

图六售书单ER图

在图四中，售书单的“金额”属性是本单中所有图书销售金额的合计，即：

金额=∑（数量×定价×折扣）

这样的属性称为“导出”属性，由于可以从其他属性导出，在数据库中一般可略去。

（3）完整的ER图

将“进书单”提升为实体来看待，这样，“进书”联系就分解为员工与进书单、图书与进书单两种联系。而其中的“金额”是导出属性，略去。

进书单的属性有：进书单号、日期。

员工与进书单发生“经手”联系。一名员工可经手多张进书单，一张进书单只由一名员工负责，所以它们是1：n联系。

进书单与图书发生“购进”联系。一张进书单可以包含多种图书，一种图书可以由不同的进书单购进。进书单与图书是m：n联系。“购进”联系属性：购进的每种图书数量、进价折扣。

将“售书单”提升为实体，“售书”联系分解为员工和售书单、图书和售书单两个联系。略去“金额”属性。

售书单的属性有：售书单号、日期。

员工与售书单发生“负责”联系，一名员工可负责售出多张售书单，一张售书单只由一名员工负责，所以它们是1：n联系。

图书与售书单发生“售出”联系。一张售书单可以售出多种图书，一种图书可以由不同的售书单售出。图书与售书单的联系是m：n联系。“售出”联系的属性有：售出的每种图书的数量、售价折扣。

这样，根据以上的分析，可以画出图书销售的ER图。为了清晰起见，将实体及属性、实体联系分别画出。如图七所示。

实体及其属性

图七图书销售ER模型联系图

3.关系模型

首先，将每个实体型转化为一个关系模式，于是分别得到部门、出版社、员工、图书、进书单、售书单的关系模式，关系的属性就是实体图中的属性。书库不需要单独列出。

然后，将ER图中的联系转化为关系模式。

ER图中有7个联系，因此，得到7个由联系转化得到的关系模式。它们分别是：

1)聘用（部门号，工号，职务，薪金）

2)出版（出版社编号，图书编号，ISBN，版次，出版日期，定价，图书类别，备注）

3)保存（图书编号，数量，存书折扣，存放备注）

4)经手（工号，进书单号）

5)购进（进书单号，图书编号，数量，进价折扣）

6)负责（工号，售书单号）

7)售出（售书单号，图书编号，数量，售价折扣）

在这些联系中，由1：n联系得到的关系模式可以考虑与n方实体合并，合并时注意属性的唯一性。这样，聘用与员工合并；出版、保存与图书合并，合并时将出版的备注和存放备注也合为一个字段：备注。经手与进书单合并，负责与售书单合并。合并时重名的不同属性要改名。关系模式名和其他属性名也可酌情修改。

保留购进和售出联系的模式，并结合需求分析改名为“进书细目”和“售书细目”。

这样得到如下一组关系模式，这些就构成了图书销售数据库的关系结构模式。

①部门（部门号，部门名，办公电话）

②员工（工号，姓名，性别，生日，部门号，职务，薪金）

③出版社（出版社编号，出版社名，地址，联系电话，联系人）

④图书（图书编号，ISBN，书名，作者，出版社编号，版次，出版时间，图书类别，定价，折扣，数量，备注）

⑤进书单（进书单号，进书日期，工号）

⑥进书细目（进书单号，图书编号，数量，进价折扣）

⑦售书单（售书单号，售书日期，工号）

⑧售书细目（售书单号，图书编号，数量，售价折扣）

4.物理设计

基于Access的设计如下。

表2-1 部门结构

表2-2 员工结构

表2-3 出版社结构

表2-4 图书结构

表2-5 进书单结构

表2-6 进书细目结构

表2-7 售书单结构

表2-8 售书细目结构