第02章数据库设计

1、第2章 数据库设计数据库设计是系统开发的重要组成部分，要设计并实现信息系统中用来存储、管理数据的数据库，满足用户对信息系统的信息需求。根据本书目标，本章不介绍系统开发的完整过程，而是结合案例，依照结构化设计方法重点介绍数据库设计中数据模型的设计。2.1 数据库设计概述数据库设计定义：针对给定的应用环境，设计构造面向全系统的、最优的数据库结构，建立数据库及其处理系统，使之能有效存储数据，对数据进行管理和操作，以满足用户的需求。按照结构化设计方法，数据库设计过程主要步骤包括：需求调查与分析、概念设计、逻辑设计、物理设计、实施与测试、运行维护等几个阶段。需求调查与分析阶段，从业务入手，调查现有系统情

2、况，了解用户对新系统的信息、功能等方面的需求，完整收集系统要处理的数据，利用各种分析工具，表达系统的数据和数据存储组织、对数据的处理要求及处理过程，写出详细的需求分析报告。概念设计基于需求分析，设计面向用户、面向全系统的概念数据模型。该模型既能清晰反映系统内数据及其联系，又很方便向计算机支持的数据模型转化。常用实体联系模型。逻辑设计将概念模型转化为DBMS支持的逻辑数据模型，但逻辑模型并不依赖于特定的DBMS。目前最重要的数据模型是关系模型。物理设计是将逻辑数据模型与指定的DBMS结合，设计出能在计算机上实现的数据库模式。本书基于SQL Server 2008系统进行物理设计。本章结合案例分析

3、，重点探讨数据库设计中，采用实体联系模型描述需求分析中获得的数据对象的基本方法，以及将实体联系模型转换为关系模型及数据库模式的基本思想，这是数据库设计的核心内容。本章案例是针对专业家电企业库存、销售管理业务进行数据库模型设计，此设计能反映企业“进、销、存”业务，具有典型性。依此建立的数据库作为贯穿全书的实例基础。2.2 需求调查与分析概述需求调查分析是系统开发的重要环节，其目的是通过调查分析，弄清用户对新系统的信息需求和功能需求。若需求分析不正确或不完整，则最终的系统就不能达到开发目标。2.2.1 系统调查基本方法需求分析通常是和系统调查结合在一起，通过调查收集资料，然后进行分析。系统调查的基

4、本方法有： 收集企业资料。如企业组织机构、管理模式、部门职责与业务流程、业务规划、各种报表和单证等。 个别访谈。主要针对企业特定人员，如高层主管、业务骨干等，目的是了解信息系统开发背景、目标，企业发展及对信息系统的要求等涉及系统全局性的信息。 填写调查表。对所有参与信息系统处理和未来系统的使用者，调查他们当前对信息处理和使用的方法以及对未来系统的要求等信息。 跟班参与和观察。对于一些关键环节、或无法了解清楚的处理环节和管理岗位，系统开发人员通过跟班体验、亲自参与和观察，来准确了解所需要的信息。 开调查会：举行由开发人员、部门经理和业务管理人员代表等参加的会议，了解当前的信息处理模式和信息需求。

5、必须准确了解并清晰表达系统开发所需的全部信息。不可能通过一次调查就把所有需求弄清楚，需要综合使用各种方法进行多次调查。但无论采用何种方法，调查前都要认真准备，事先有调查提纲或设计调查表，调查后仔细分析调查结果，撰写调查报告。系统调查是一个和信息系统未来用户沟通的过程，涉及不同部门、不同层次的业务人员和管理者。调查者需要具备良好的与他人特别是非专业人员沟通的能力。系统开发围绕企业业务展开，而企业业务都依附于一定的组织机构，所以调查一般从组织结构开始，采用自顶向下方式进行。根据企业组织结构，明确企业的层次关系和职能分配、管理模式，以及不同部门之间信息的应用、处理和传递关系。调查结果可用“组织结构图

6、”和“信息关联图”来描述。信息关联图描述各部门产生的各种文档、报表、凭证等，以表达部门之间信息的使用、传递和归档情况。在对企业有了全面宏观的了解后，即可展开详细的业务流程调查，业务调查是系统调查的核心,应该由上到下逐步细化。可使用“业务流程图”描述业务流程。企业组织以及业务流程都和信息有关，系统调查要获取当前系统的完整信息、信息处理流程及处理方法，主要表现在作为信息载体的各种凭证和报表等文件的产生及流动。包括：原始凭证、票据、台账、各种报表（如明细报表、汇总表等），以及文件的传递过程和方式，相关的文件如规划、预测、管理制度等。对系统调查获得的各种资料信息，可以编制详细的汇总清单，并和用户一道对

7、信息的准确性和完整性进行审核。2.2.2 需求分析概述在系统调查基础上展开分析，弄清用户需求，并用规范方法表达，形成需求分析报告。用户基本需求分为功能需求和信息需求，与信息需求相关的主要工具包括数据流图（DFD，Data Flow Diagram）和数据字典（Data Dictionary）。（1）数据流图DFD基于业务流程图，采用图形符号和文字，以数据为主线，描述数据的产生、随着业务处理过程流动和变换、数据的存储、以及数据的最终去向。DFD基本构成元素和对应图符有4种：外部实体、处理逻辑、数据存储和数据流。l 外部实体即数据的来源和最终去向。l 处理逻辑针对业务，描述数据从产生到最后到达目的

8、地的全过程中的处理环节。l 数据流是在一个处理环节流向下一个处理环节时，伴随的数据集合。体现了数据的流动过程和格式或构成的变化。l 数据存储表达在数据流动过程中需要存储的环节，并描述要存储的数据的结构。DFD采用自顶向下、逐层分解的绘制方法。DFD是系统开发过程中最常用和最重要的工具之一。绘制出信息系统的DFD是需求分析的主要成果。本书不介绍DFD的具体内容，读者可参阅相关书籍。（2）数据字典数据字典被称为“关于数据的数据”，其作用是对信息系统开发涉及的各种类型数据元素进行定义，保证在整个系统开发和运行过程中（如在数据流图、数据库及处理程序、生成的报表等）数据元素定义的一致性和惟一性。数据字典

9、有设计时数据字典和运行时数据字典之分。需求分析与系统设计阶段，数据字典用来统一数据流图各部分的描述和定义，同时作为数据库实现的依据。在数据库运行阶段，数据字典成为数据库的一部分，一般保存在系统数据库和系统表中，用来保障数据库的正常运行。两类数据字典内容、结构和形态不同，但有内在的逻辑关联和一致性。作为需求分析的数据字典，由对各种类型数据元素的唯一规范的定义组成。数据元素是指DFD中用到的数据流、数据存储、数据处理逻辑和外部实体等对象，以及构成这些对象的数据项和数据结构。数据字典包括的项目如下。 数据项。数据项是数据的最小单位，是信息系统中其他类型数据元素的组成部分。如员工号、姓名、商品名等都是

10、数据项。数据项可以由字符、数值或其他符号组成。数据项的描述包括数据项名称、编号、类型、取值范围和长度等内容。 数据结构。数据结构是有关联的数据项的集合，主要用以描述数据流、数据存储等对象的逻辑构成。数据结构的描述包括数据结构的名称、编号，描述该数据结构包括的所有数据项，并指出涉及的数据流和数据存储的编号。 数据流。用来定义DFD中的数据流，包括数据流的名称、编号、来源、去向、所包含的数据结构的名称、传输的频率和流量等。 数据存储。指系统中需要保存的数据集合。字典中定义数据存储的结构和内容，包括数据存储的名称、编号、所包含的数据结构、数据记录等。 处理逻辑。描述DFD中数据处理逻辑的过程，包括处

11、理逻辑的名称、编号、输入数据流、处理逻辑的算法、输出数据流等。 外部实体。外部实体是信息系统的数据源和数据的归宿，具有各自的数据属性，包括的内容有外部实体名称、编号、输入数据流和输出数据流等。数据字典要对信息系统中使用到的所有的数据进行定义，必须符合以下要求：l 唯一性，即不能有多次定义。l 一致性，即所有的数据元素应保持应用上的一致，无二义性。l 完整性，即必须包括系统中所有数据元素的定义。l 规范性，即数据元素的定义应严格、规范。l 简单性，即表达和描述应尽量简单。生成数据字典，可由开发者手工整理、编辑生成纸质或电子数据字典，也可借助系统开发平台或CASE（ComputE-R Aided

12、Software EngineE-Ring）工具生成电子数据字典。需求分析阶段的数据字典，是由用户认可的对数据的详尽、完整和唯一的定义，并作为后续系统开发工作，包括系统设计、实现、维护和管理等工作的主要依据。2.3 概念模型设计概念设计是在需求分析的基础上来设计概念数据模型。实体联系（E-R，Entity Relationship）模型是常用的设计工具。2.3.1 E-R模型基本概念E-R模型主要包括实体、属性、域、实体集、实体标识符以及实体联系等概念。1实体、属性及域实体（Entity）指现实世界中任何可相互区别的事物。人们通过描述实体的特征即属性来描述实体。在建立DBAS的概念模型时，实体

13、就是系统关注的对象。属性（Attribute）指实体某一方面的特性。一个实体由若干个属性来描述。通过给属性取值，可以确定具体的实体。每个属性都有一个名称，称为属性名。每个属性都有一个确定的取值范围，称为域（Domain）。域是值的集合。2实体型、实体集与实体码实体型（Entity Type）描述同类实体的属性结构。包括实体名及其属性名集合。每个实体的具体取值就是实体值。型描述实体属性结构，值是每个个体的具体内容。同型实体的集合称为实体集（Entity Set）。例如，全体员工实体构成员工实体集。实体集中每个实体都可识别和区分，用来唯一确定或区分实体集中每个实体的属性或属性集称为实体码（Enti

14、ty Key）。实体码具有最小性，即不能去掉其中的任何部分。实体码对于数据处理非常重要，每个实体集中都存在实体码。当有多个属性（集）可作为实体码时，选择实体码的通常原则如下。l 选择属性长度最短的实体码。l 尽量选择单个属性构成的码，而不是复合实体码。l 选择在数据库系统生命周期内属性值最少变化的实体码。l 选择在数据库系统生命周期内更可能包含唯一值的实体码。3实体集与实体集的联系和联系集不同实体间常常发生联系，这种联系反映了事物的关联性。实体集之间的联系构成联系集。参与联系集的实体集的数目称为联系集的度。多数联系发生在两个实体集之间，度数为2，称为二元联系；发生在一个实体集内部的联系称为一元

15、联系或递归联系，如球队集的比赛联系。同时在三个或更多个实体集之间发生的联系称为多元联系，如家电销售是同时发生在员工、商品、顾客实体集之间的多元联系。一个实体集中的一个实体通过一个联系集能同时与另一个实体集相联系的实体数目称为映射基数。共有3种类型的映射基数：一对一（1:1）、一对多（1:n）或多对一（m:1）和多对多（m:n）。设二元联系集R是实体集A和B之间的联系，其可能的映射基数定义如下。 一对一：A中的一个实体至多同B中的一个实体相联系，B中的一个实体也至多同A中的一个实体相联系。 一对多：A中的一个实体可以同B中的任意数目（0）的实体联系，而B中一个实体至多同A中的1个（可以为0）实体

16、相联系。也可称B与A是多对一联系。 多对多：A中的一个实体可以同B中任意数目（0）的实体相联系，而B中的一个实体也可以同A中任意数目（0）的实体相联系。例如，机场航班管理系统中，乘客集与飞机机票集的持有联系是1：1联系；航班与乘客的乘载联系是1：m联系等。再如销售管理中，员工与商品的销售关系是m：n。当一个联系发生时，在联系集中可能会产生一些新的属性。例如销售发生时会出现销售数量、金额等属于销售的属性值。联系集也有码，一对一联系集的码可以使用参与联系集中的任何一方实体集的实体码；一对多（多对一）联系集由“多”方实体集的码组成；多对多联系集由参与联系集中所有实体集的码组成。4参与约束如果实体集A

17、中的每个实体都参与到联系集R上的至少一个联系中，则称实体集A全部参与联系集R。如果允许实体集A中有部分实体可不参与到联系集R的联系中，则称实体集A部分参与联系集R。5实体联系图一般采用实体联系（E-R）图来表示实体联系模型。E-R图中用几种图符分别表示实体型及其属性、实体间的联系等。基本的图符如图2.1所示。图2.1 表示实体型、属性和联系的图符画E-R图时，在矩形框内写上实体名表示实体型，在椭圆框内写上属性名表示实体或联系的属性，作为实体码的属性下画一条下划线。在菱形框内写上联系名。在实体型和它的属性间连上连线。发生联系的实体之间分别用连线连到对应的联系上，并标上映射基数类别。联系若有属性，

18、也通过连线将属性与联系连起来。如果一个系统的E-R图中实体及属性较多，为了简化最终的E-R图，可以将各实体及其属性单独画出，在联系图中只需画出实体间的联系。2.3.2 设计E-R模型的进一步讨论在基本E-R模型的基础上，需要进一步分析并增加新的概念来增强其表达能力。1属性不同特性的划分实体或联系的属性根据其取值的特点可按如下类型划分。 简单属性和复合属性。简单属性也叫原子属性，是指不能再分为更小部分的属性。而复合属性是指有内部结构、可以进一步划分为更小组成部分的属性。 单值属性和多值属性。如果一个实体的某属性任何时候都只能有单独的一个值，则称该属性为单值属性，否则为多值属性。 允许和不允许取空

19、值属性。允许取空值指允许实体在某个属性上没有值，这时使用空值（NULL）表示。NULL表示属性值未知或不存在。而属性不允许取空值，则意味所有实体在该属性上都有确定的取值。 基本属性和派生属性。派生属性的值可以从其他相关属性的值计算或派生出来。在初始E-R图中，可用双线椭圆表示多值或复合属性，用虚线椭圆表示派生属性。最终的E-R图中，必须消去多值和复合属性，因此对它们需要进一步处理。一般情况下，单值复合属性可以按子属性分解为简单属性；多值简单属性可将多值转化为多个单值简单属性（适合值较少的情况），或者将该多值属性转化为实体对待，这样的实体一般就是弱实体；多值复合属性则需要转化为实体来处理。2存在

20、依赖与弱实体集每个实体集都应包含实体码。但在现实世界中存在一类实体集，其属性不足以形成码，它们必须依赖于其他实体集的存在而存在，这样的实体集称为弱实体集。与之相对，具有实体码的实体集称为强实体集。弱实体集所依赖的强实体集称为标识实体集。弱实体集必须与一个标识实体集相联系才有意义，对应的联系集称为标识联系集。单独的弱实体集没有实体码，必须结合所依赖的标识实体集。标识弱实体集中实体是由指定的属性（集）加上其标识实体集中的实体码合在一起来实现。弱实体集中用来参与标识弱实体的属性（集）称为该弱实体集的部分码（Partial Key）。对于弱实体集，必须满足下列限制： 标识实体集和弱实体集的联系必须是“

21、一对多”联系。 弱实体在标识联系集中是全部参与。在E-R图上使用双线矩形表示弱实体集，用双线菱形表示标识联系，用虚下划线表示弱实体的部分码。3类层次、子类和超类实体实体集中可能包含一些子集，该子集中的实体具有不被该实体集中所有实体所共享的一些属性。因此，一个实体集可根据多个不同特征进行分割，将全部实体共有的部分属性保留，构成的实体集称为超类实体集；被分割的各部分称为子类实体集。子类和超类的基本特点是“继承”。子类实体继承超类的全部属性，同时还可以拥有自己的属性。子类对超类的继承性体现在子类实体与超类具有相同的实体码。一个子类还可继续细化为子类。在构建E-R图时，超类实体描述实体的共有属性，而子

22、类实体描述各自特有的属性。在E-R图中，使用图符“”联通子类和超类。E-R模型通过层次关系和继承来体现超类和子类。超类和子类的确定可以从两个方向进行设计。先设计超类实体集，然后根据属性的不同，将实体集分割为不同的子类实体集，这种方式称为“特化（Specification）”；先设计出各子类实体集，然后再将它们的共同属性提取出来，形成超类实体集，这种方式称为“泛化（Generalization）”。出现在超类实体集中的实体，在特化为子类实体的过程中，需要考虑两种特化约束：不相交约束和完备性约束。 不相交约束（Disjointness Constraint）。不相交约束是指特化的子类是否相交。不相

23、交约束又分成不相交和重叠两种情况： 不相交（Disjoint）约束也叫互斥约束，它规定了在特化过程中，子类必须是不相交的。即一个超类实体至多特化为一个子类的成员。例如若员工实体有管理子类和业务子类，则一个员工如果是管理人员，就不能同时为业务人员。 重叠（OvE-Rlap）约束规定了在特化过程中，子类可以相交。这意味着一个实体可同时出现在特化的多个子类中。在E-R图中，在圆圈内标上字母“D”表示互斥子类，标上“O”表示重叠子类。 完备性约束（Complete Constraint）。完备性约束将特化过程分为整体特化和部分特化两种情况： 整体特化约束要求超类中的每个实体必须是特化后某个子类的成员。

24、 部分特化约束允许超类中的实体可以不出现在任何一个子类中。在E-R图中，整体特化在超类实体和小圆圈之间用双线条表示。部分特化在超类实体和小圆圈之间用单线条表示。事实上，部分特化约束意即有些实体只需用超类实体具有的属性就刻画完整。根据不相交约束和完备性约束，对子类和超类进行插入、删除操作时有以下规则： 从超类删除一个实体意味着该实体被自动地从隶属于它的所有子类中删除。 向超类中插入一个实体意味着该实体被强制地插入到满足这两种约束的子类中。在信息系统中，超类和子类实体很常见，只要同类实体需要细分，细分后有不同的属性，就可以采用子类表达。例如企业客户全体可分为VIP客户、普通客户；超市商品全体分为不

25、同的类别，有不同的属性等等。4实例【例2-1】弱实体集的示例。设有“员工”实体，其属性包括：工号、姓名、性别、生日、学位、社会关系、照片。在这些属性中，“学位”属性是简单属性，但若某些员工有多个学位，则其可取多个值，所以是多值属性；“社会关系”属性，由子属性“姓名、（与员工）关系、单位或地址、联系电话”等构成，因此是复合属性，并且一个员工的社会关系不止一个，因此又是多值属性。“员工”实体的E-R图如图2.2所示。图2.2 员工实体型及其属性示例对多值属性的一种处理方式，是将多个可能的取值转换为多个属性。例如，若“学位”能确定最多只填写第一和第二学位，则取消“学位”属性，定义“第一学位”、“第二

26、学位”属性。这种方式适合事先明确知道取值个数很少且有上限的情况。对于“社会关系”这样的多值复合属性，则应该将其转换为实体对待。但“社会关系”实体是弱实体。通过转化，确定“员工”的E-R图如图2.3所示。图2.3 弱实体及其联系示例在弱实体“社会关系”中，没有实体码。只有将所依赖的“员工”实体的实体码“工号”属性与“社会关系”的“姓名”结合，才能唯一识别和确定每个社会关系的值。【例2-2】超类实体集与子类实体集的示例。 “员工”实体是超类实体，包括两个子类：管理人员和业务人员，属性构成有差异。其E-R图如图2.4所示。本例中，假定两类员工不重叠，并且是整体特化。图2.4 超类实体与子类实体示例超

27、类属性即所有员工共有属性为“工号、姓名、性别、生日、学位、照片”，管理类员工还包括：职务、工资。业务类员工还包括：岗位类别、底薪、业绩提成比例。2.3.3 E-R模型设计基本步骤与原则E-R设计一般遵循自底向上的策略。即首先针对需求分析中获得的各个局部应用设计局部E-R图，然后再对局部E-R图进行集成，设计面向全局、统一的E-R图。设计E-R模型的基本步骤如下。 设计局部初始E-R图。 对局部初始E-R图进行优化。 对局部E-R图进行集成、优化。在设计局部初始E-R图时，设计的关键在于确定实体和联系。一般而言，系统的实体，是不依赖其他对象的存在而存在、独立的对象。凡是作为企业业务、实体动作行为

28、发生的数据，都是描述联系的。据此原则，可以确定初始的E-R图。确定初始E-R图后，需要对初始E-R图进行优化，对描述实体或联系的属性中不是原子和单值属性的情况，进行转换处理，使所有属性都成为原子和单值属性。最后，对所有局部E-R图进行集成，得到统一E-R图。E-R图集成要注意以下几点。 同一个实体对象只出现一次。 属性是单值和原子的。 实体名和联系名在一个E-R图（局部或全局）中应唯一。 每个实体有唯一的实体码作为标识，而联系没有标识。 每个子类有唯一的超类，子类本身不定义标识，而从超类中继承标识；不允许弱实体作为子类，但可作为超类。 相同实体之间的多个联系应是可区别的。在设计E-R模型时要注

29、意以下原则。 忠实性。设计应忠实于应用需求，这是首要的也是最重要的原则。即：即实体集、属性、联系集都应当反映现实世界，应根据所了解的现实世界去建模。 简单性。现实世界的对象可能具有许多特征，但在进行概念设计时只需要对数据库使用者所关心、感兴趣的属性建模。不要在设计中增加更多成分。 选择实体还是属性。在对现实世界进行抽象和概括时，实体与属性的划分取决于被建模的实际应用及被讨论属性的相关语义。但实体和属性并没有形式上可以截然划分的界限。通常满足下述两条规则的事物，均可作为属性对待。 l 作为属性，不能再具有要描述的性质，即属性不可分。l 属性不能和其他实体相联系。 选择实体还是联系。一事物是描述为

30、实体集还是联系集没有一个绝对的标准。但通常原则是，实体对应于现实世界中实际存在的事物，是名词；而联系对应的概念一般为一种动作，即关于实体间的一种行为或对事物处理过程的描述。 唯一性。要避免冗余，防止相同实体出现在不同地方，避免异名同义、同名异义的现象。2.4 逻辑设计和物理设计概述逻辑设计将概念模型转化为DBMS支持的数据模型。物理设计则是结合DBMS及数据库系统性能等多方面因素，设计数据库物理结构。而后就可以据此创建物理数据库了。2.4.1 E-R模型转化为关系模型将E-R模型转化为关系模型，基本内容包括：实体转化、联系转化、转化后的优化等几个部分。1实体的转化每个实体型都转化为一个关系模式

31、。给转化得到的关系模式命名，并将实体型的属性作为关系模式的属性，实体码作为关系模式的主键。2弱实体的转化每个弱实体型都转化为一个关系模式。给转化所得关系模式命名，实体型的属性作为关系模式的属性，并将所依赖的标识实体的主键作为弱实体的属性。标识实体的主键与弱实体的部分码共同作为关系模式的主键。3子类实体的转化每个子类实体型都转化为一个关系模式。给转化所得关系模式命名，实体型的属性作为关系模式的属性，并将对应超类实体的主键作为子类实体的属性，同时也作为关系模式的主键。4联系的转化实体集之间的每一个联系集都转化为一个关系。给联系转化的关系模式命名，联系的属性作为该关系模式的属性，同时，与联系相关的各

32、实体的实体码成为该关系模式的属性。5转化的关系模型优化对转化所得关系数据库模式进行优化。 由联系集获得的关系模式，应根据联系集映射基数的类型，进行合并优化。1:1联系，一般没有必要单独成为一个关系模式，可以将它与联系中的某一方实体转化成的关系模式合并(一般与将来元组较少的一方合并)。1:n联系也没有必要单独作为一个关系模式，将其与联系中的n方实体转化成的关系模式合并。m:n的联系必须单独成为一个关系模式。 依据用户对数据的不同要求，并按照关系数据理论，对所有关系模式进行分析，分析其范式级别，可能的约束要求等。可通过关系模式分解要求关系模式达到3NF，减少属性取空值的情况。【例2-3】将图2.3

33、所示的E-R图转化为关系模型。“员工”实体是标识实体，转化为员工关系。“社会关系”是弱实体。通过转化，得到关系模型如下。员工（工号，姓名，性别，生日，第一学位，第二学位，照片）社会关系（工号，关系姓名，关系，地址，联系电话）“工号”是“员工”的主键，“工号+关系姓名”是“社会关系”的主键。【例2-4】将图2.4所示的E-R图转化为关系模型。“员工”实体是超类实体，转化为员工关系。“管理人员”和“业务人员”是子类实体。通过转化，得到关系模型如下。员工（工号，姓名，性别，生日，学位，照片）管理人员（工号，职务，工资）业务人员（工号，岗位类别，底薪，业绩比例）“工号”是超类“员工”的主键，也是两个子

34、类转化的关系的主键。2.4.2 物理设计概述当数据库关系模式确定后，就要结合DBMS的要求和规定，对数据库进行物理设计，作为建立物理数据库的操作基础。物理设计必须考虑实际运行后的多方面要求，要估算最大数据量、考虑数据库要支持的负载和应用需求、用户数和用户类别、数据库访问性能的要求、数据库备份与恢复的要求等等。物理设计包括的主要任务如下。l 设计数据库的存储结构、存储设备及扩展方法等。l 设计数据库表的结构。l 设计索引、约束、触发器等。l 设计其他数据库对象，如视图、存储过程等。l 确定用户和角色、权限分配原则等。l 确定备份、恢复策略等。l 确定其他需要考虑的要素。总之，物理设计是确定将来数

35、据库是否达到设计要求的关键部分，物理设计要求设计人员有丰富的专业知识和经验，对所采用的软硬件和DBMS有充分的认识和了解。2.5 数据库设计实例分析对多数生产或商业企业来说，“进货、库存、销售”业务是主要日常业务，也是企业管理信息系统核心内容。从数据分析的角度，设计“进、存、销”的数据模型具有典型性。以下针对某家电销售企业开发“进、存、销”管理信息系统进行分析，分析过程忽略很多实际业务细节，重点是获得设计数据库所需要的数据元素。2.5.1 系统调查与需求分析概述1组织结构与基本职能企业基本组织结构如图2.5所示。经理室负责全局；人事部负责员工管理；财务部负责资金、财务管理；市场与采购部负责市场

36、调研、制定销售计划、签订订单与采购等；销售部负责商品销售；服务部负责售后安装、维修、用户反馈等；库房存放并管理商品。图2.5 组织结构简图规模不大的专卖店或卖场，会将某些部门撤销或合并，但这些基本职能都具备。2基本业务分析业务调查是系统调查与需求分析的起点。本实例主要分析“进货、库存、销售”业务过程，确定业务涉及的单据、报表和数据以及相关人员等，为了不使系统过分复杂，这里不涉及“签订单”、“售后处理”等业务。基本业务包括：进货业务、库存管理业务、销售业务、其他相关业务。（1）进货业务进货业务是指从家电生产企业购进产品，送入库房存放的过程。进货人员清点进货商品，填写进货单，送入库房。库存管理人员

37、清点进货商品，分类存放，并保存进货信息，修改库存账本。（2）销售业务销售业务指将柜台或仓库中的商品售给顾客的过程。销售单样式如图2.6所示。销售人员填写销售单。然后从仓库提货（或包括放在柜台的样品），由库存管理人员记载出货信息，修改库存账本。图2.6 销售单样式（3）库存管理在进货或出货业务发生时登记进货或出货信息，并同时更改库存账本。另外，库存管理还应包括定期或不定期进行库存清理，并登记相关信息和账本（本实例省略）。（4）其他管理业务根据实际业务的需要而设置。如年度、某个季度、某月销售信息汇总分析、库存情况查询与分析、各部门业务报表输出等等。3相关数据分析需求分析可以采用业务流程图等方式直观

38、展示业务过程。在业务的不同环节，都涉及到相关数据处理。可绘制数据流图，通过图示的方式，对逻辑上有关联的数据集合的产生及转换过程进行描述。这里用文字方式对上述业务的数据进行简要分析。（1）基本数据集合对象及构成分析在上述业务中，产生和需要管理数据的业务是“进货、库存、销售”，其他管理业务是基于已有数据进行。数据对象包括：进货单、库存账、销售单。参照系统调查时收集的原始单据、账本、报表等，可以归纳出各数据对象的构成元素。 进货单。是每次进货的商品清单，供进货人员和库存人员清点核对使用。进货单一单多联，分别由进货部门和库房存档，作为每次进货业务的信息来登记，也备日后查询之用。一张进货单只包含同一生产

39、商的产品，其结构与销售单类似。进货单包括：进货单号、日期、生产商、联系人、联系电话、经手人，以及进货单明细。进货单明细是一张进货单内包括的货物清单列表，包括：序号、商品名称、规格型号、单位、单价、数量、金额。 库存账反映最新的库存状态，商品入库，则库存增加；商品出库，则库存减少。信息包括为：商品名称、生产商、规格型号、单位、单价、数量、金额、备注。新进货商品，若以前库存中没有相同商品，则增加一条库存记录；若有相同商品，由于生产日期或进货日期的不同，可能单价等不相同，因此，要重新计算并给出平均单价。（注：这里简化实际管理，以商品种类为单位登录，不区分和登记单件商品） 销售单是销售的凭证，一单多联

40、，由柜台、顾客、库房、服务部等对象同时拥有，作为业务记录、售后服务依据、日后查询之用。其结构见图2.6。销售单包括：销售单号、日期、经手人、收款员、销售金额，以及顾客信息和销售明细。销售明细是一张销售单内包括的商品列表。一张销售单，可以是针对一个厂家的商品，也可以是多个厂家的商品。如图2.6的销售单中，商品名称中包含了生产厂商信息。销售单明细包括：序号、商品名称、规格型号、单位、单价、数量、金额等。顾客信息包括：姓名、地址、联系电话等信息。（2）其他数据集合及构成分析除了业务数据，还要收集一些有关基本数据，如“部门”等对象。另外有些数据，在业务分析时是某些数据对象的组成部分，但在数据分析时，要

41、归纳为独立数据对象进行分析和描述。例如，很多地方都会出现“经手人”、“收款员”等信息，他们都是单位的员工，因此，要定义“员工”数据集合。其他如“生产厂商”、“商品”等对象。 部门。描述部门基本信息，包括：部门编号、部门名、办公电话。 员工。描述职工的基本信息。包括：工号、姓名、性别、生日、所在部门、职务、基本工资、联系电话。 生产厂商。描述有业务往来的企业基本信息。包括：厂商编号、名称、地址、联系人、厂商电话、备注。 商品。描述商品基本信息。包括：商品编号、商品名、规格型号、单位、商品类别、生产厂商。以上分析可以获得基本数据对象及其构成。不过，得到的结果是比较粗糙、不规范的，需要进一步进行分析

42、和规范，要有统一的命名规则。同一个数据只定义一次，避免重复，在需要的地方引用已定义数据。另外，要避免出现不同元素命名相同的情况，保证命名的规范性、唯一性、一致性。然后在此基础上建立需求分析阶段的数据字典。数据字典需要逐项登记所有的数据元素，包括“数据项、数据结构、数据流、数据存储、处理逻辑、外部实体”等。数据元素要进行编号。数据字典是需求分析的主要成果，是后续数据库设计的依据，必须获得用户的认可。2.5.2 E-R模型设计在系统调查和需求分析的基础上，下一步进行概念设计。【例2-5】家电“进货、销售、库存”管理信息系统概念模型设计分析。对于家电销售的概念模型设计，可按下述过程进行。首先确定初始

43、实体及其属性。然后对实体及其属性进一步分析，如果需要，设计超类实体、子类实体和弱实体。这里不使用弱实体和子类实体等对象。然后确定实体间的联系及其联系集。先设计局部的联系，获得初始联系图，然后对联系集进行分析，如有必要，对联系进行转换。例如，多元联系可变成一组二元联系；具有多值复合特征的属性要提升为实体，从而改变联系集的构成等。最后进行模型优化和集成。 识别并确定初始实体及属性。根据需求分析可以确定最初的实体类及其属性。凡是独立存在的、需要进行结构描述的对象就是实体。本实例的实体包括：部门、员工、生产商、商品、顾客、库房等。其中“库房”只有一个实体名，无需属性描述。其他实体及其属性如图2.7所示

44、。图2.7 实体及其属性初始E-R图 确定初始联系集。初始联系集进行分别设计，以单个的联系为纽带，分析联系及相关实体。本实例的联系如图2.8（a）-（e）所示。通过分析，可以发现，作为“员工”对象数据项的“职务、基本工资”等实际上是“部门”实体集与“员工”集发生联系的属性。在需求分析中获得的表示业务记录的账本、单据等也是实体发生联系的结果。根据E-R模型设计要求，可以看出，图2.8所示的初始E-R图并不符合E-R模型的规定，作为属性的“库存账、销售单、进货单”等都不是原子和单值属性，因此，需要进行E-R模型的改进和优化。（需要说明，生产商在生产商品时，会产生很多属性，如“条形码、生产日期”等，

45、若以每批产品为单位，要探讨细节非常多。这里进行了大量简化，以关注核心设计。）（a）员工-部门聘用联系 （b）厂家-商品生产联系 （c）商品-库房保存联系（d）员工-商品进货联系 （d）员工-商品-顾客销售联系 图2.8 实体联系初始E-R图 对初始E-R模型的改进优化。最终的E-R模型中，所有属性必须是原子和单值属性。而“库存账”、“进货单”、“销售单”都是多值、复合属性。因此，必须对这些属性进行进一步的处理。对于“销售单”和“进货单”，因为它们是不规范的多值、复合属性，解决的方法是将它们当作实体对待。而“库存账”属于规范的复合属性，将其分解为原子属性即可。由于库房只有一个，因此直接用“库存账

46、”作为实体替代库房。将“销售单”作为实体，其实体型及属性的E-R图如图2.9所示。销售单上的“销售金额”是“销售明细”中金额的合计值，所以是可推导的属性。销售单上的其他属性则是“销售单”实体与“员工”、“顾客”、“商品”发生联系产生的属性。对于“进货单”，因为一张进货单只有一家生产商的商品，因此，有关厂商的信息通过商品与生产商的联系可以表达出来，这样，“进货单”的实体型及其属性如图2.10所示，与“销售单”类似。 图2.9 销售单实体及属性 图2.10 销售单实体及属性 “员工”实体与“销售单”发生两种联系：“经手”和“收款”。一名员工可以经手多张销售单、一张销售单只由一名员工经手，是一对多联

47、系。“收款”与“经手”联系方式相同。“商品”实体构成销售单上的明细。一种商品可以出现在多张销售单上，一张销售单可以有多种商品，“商品”与“销售单”构成多对多联系。当每种商品出现在销售单上时，产生“单价、折扣、数量、金额”等属性，其中“金额”属性是其他属性计算出来的，是可推导的属性。“顾客”则通过购买商品而拥有销售单。一名顾客可以拥有多张销售单、一张销售单只由一名顾客拥有，是一对多联系。这样，将“销售”联系改进后的E-R图如图2.11所示。改进“进货”联系得到的E-R图如图2.12所示。图2.11 改进“销售”联系获得的实体联系E-R图图2.12 改进“进货”联系获得的实体联系E-R图 E-R模

48、型的集成将前面设计的局部E-R模型进行集成，相同实体型只出现一次，并进行命名的规范，实体和联系名应具有唯一性。这样，得到的全局E-R图如图2.13所示。图2.13 集成的实体联系E-R图2.5.3 关系模型设计在E-R模型的基础上进行转化，可以获得对应关系数据模型。【例2-6】家电“进货、销售、库存”管理信息系统关系模型设计分析。根据例2-5的分析设计，结合E-R模型转化为关系模型的方法，可以得到家电“进货、销售、库存”管理信息系统的关系模型。 将所有实体型转化为关系模式。得到关系模式如下。l 部门（部门编号，部门名，办公电话）l 员工（工号，姓名，性别，生日，电话）l 生产厂商（厂商编号，厂商名，地址，联系人，厂商电话