179.关系数据库设计技术(需求分析、设计、实施、运行、维护)

 

1.概述

数据库设计是指在现有的应用环境下，从创建问题的概念模型开始，逐步创建和优化问题的逻辑模型，最后创建其高效的物理模型，并据此创建数据库及其应用系统，使之可以有效地收集、存储和管理数据，知足用户的各类应用需求。

数据库设计最终目的：（1）知足用户的需求；（2）简化应用程序的编程设计，实现系统协同、高效的开发，减小开发成本。

数据库设计步骤：系统需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施、数据库系统运行和维护。

各步骤的前后关系如图3.1所示。其中，对每个步骤，若是设计结果不知足要求，都有能够返回前面的任一步骤，直到知足要求为止。

 

 

 

2. 需求分析

需求分析是了解用户需求、而后明确用户需求、最后造成需求文字表达（需求分析说明书）的一个过程。需求分析的最终结果就是造成一份有效的需求分析说明书。

2.1 系统调研过程

系统调研也称项目调研，即把系统开发看成项目来运做，其主要目的是经过接触用户以了解并最终明确用户的实际需求。这个过程是一个系统分析人员理解和掌握用户业务流程的过程，是一个须要不断与用户进行沟通和磋商的过程。系统调研方法比较灵活，因人、因系统而异。大体过程能够分为如下几个步骤来完成：

 

　　充分了解项目背景以及开发的目的。

　　深刻用户单位（指使用该系统的机构和组织）进行调查。包括了解单位的组织结构、运做方式，了解各部门的职责和功能。而后从数据流的角度分析各个部分的特性以及它与其余部门之间的关系，如各部门的输入（输出）数据及其格式是什么，这些数据来自哪里、去向何方等，并做相应的记录。

这个步骤是调查的重点，并且难度比较大，难点在于如何创建与用户理性的沟通渠道。用户与系统分析人员通常都具备不一样的技术背景，因此常常致使这种状况的出现：用户认为已经说清楚了的东西而分析人员也许对之还不能理解，或者用户提出的要求太高，超出了计算机可以处理的范围等。当出现这种状况时，须要分析人员不断的询问或说明，久了就会致使用户的厌倦。在进行这项调查前分析人员应该作好充分的准备，例如拟好调查方案、设计合理而简洁的调查表等。

 

给出了一种调查方法，可供读者参考和选用：

单位状况及其运做方式的介绍。

对部门工做职能的深刻了解。

召开调查会。

若是与用户尚未就需求达成共识，相关分析人员可有选择地重复②和③步。

 

　　肯定用户需求、明确系统功能和边界。综合各个分析人员的调查结果，造成系统的功能说明，肯定哪些功能是系统要实现的，哪些是不该该实现的，或者是不能实现的。全部这些结果都应该跟用户确认后予以书面形式肯定下来。

 

 

2.2 需求分析的方法

2.2.1 SA方法

针对数据库设计，造成用户需求的有效表达，这种表达在说明书中多以数据流图、数据字典等形式来描述。

为创建用户需求的表达，能够采用多种分析方法来完成。这些方法主要包括自顶向下和自底向上两种方法，其中常采用的方法是自顶向下的结构化分析方法（SA, structured analysis）。

SA方法的分析过程符合人类对问题的认识并最终解决的通常过程，其分析过程简单、实用，现已在众多领域中获得应用。

SA特色能够归结为一棵树的产生过程：先建立树根，而后建立树根节点的子节点，接着建立各子结点的子节点，直到建立全部的树叶节点为止。在这棵树中，树根节点至关于整个系统（第一层次上的系统），其子节点至关于第二层次上的系统，…，最后层次上的系统由叶子节点表示，它对系统分析人员是可认知的（认为已经清楚而没必要再分解了）。自顶向下的SA方法是从整个系统开始，采用逐层分解的方式对系统进行分析的方法。

 

 

2.2.2 数据流图（data flow diagram）

SA方法只是对问题分析的一种思想，在具体的分析过程当中还须要借助其余的分析工具，这样才能完成对分析过程和结果的记录、对用户需求的表达等，数据流图就是最为经常使用的辅助分析工具和描述手段。

数据流图是以图形的方式来刻画数据处理系统中信息的转变和传递过程，是对现实世界中实际系统的一种逻辑抽象表示，但又独立于具体的计算机系统。

 

数据流图常采用的符号：

数据流

数据流是流动中的数据。因此数据流图是用有方向的曲线或直线来表示，用前头表示数据流的方向，其旁边标以数据流的名称，其格式以下：

 

 

 

数据流名不是随意取的，它可以简要地归纳数据流的含义，且易于理解。下文提到的数据名、加工名、文件名等都有一样的要求。

数据流能够来自数据的源点、加工和数据文件，能够流向数据的终点、加工和数据文件。当数据取自文件或者流向文件时，相应的有向直线或曲线能够不命名，由于从相应的文件中便可知道流动的是什么数据。

 

数据的源点和终点

系统中的数据是来自系统之外的其余数据对象，其最终的流向也是系统之外的有关数据对象。

这种向系统提供数据的数据对象统称为系统的数据源点，而系统数据所流向的数据对象则统称为数据终点。这两个概念的引入是为了帮助用户对系统接口界面的理解。

在数据流图中，数据源点和数据终点都是用方框来表示，方框中标以数据的名称。其格式以下：

 

 

加工

加工是对数据处理的一个抽象表示。若是这种“加工”还不为系统分析员所理解，则须要SA方法对其进行分解，直到所获得的加工已经足够简单、没必要再分时为止。这时的加工也称为基本加工。在数据流图中，加工是用圆圈（或椭圆）表示，圆圈标以加工的名称。其格式以下：

 

数据文件

数据文件是表示数据临时存放的地方，“加工”可以对其进行数据读取或存入。在数据流图中，数据文件一般用平行的双节线表示，旁边标以数据文件名。其格式以下：

 

　　对于数据流图中的一个节点，可能有几条表示数据流的有向线出自或指向该节点。该节点对数据流的影响方式（流出状况）或这几股数据流对该节点的做用方式是有多种的。这种影响和做用方式说明如表3.1所示。

 

 

2.2.3基于数据流图的SA方法

自顶向下的SA分析方法能够与数据流图有机地结合起来，将对系统的分析过程和结果形象地表示出来。

在数据流图中，SA分析方法主要体如今对“加工”进行分解的过程。对数据流图的绘制和分解过程就是用户需求的分析及其表达的造成过程。

一个系统的数据流图是由多个子图构成，若是加上子图之间的分解关系，就能够造成一棵树。但因为全部的子图经过表示分解关系的边连在一块儿而造成的树将是很庞大的，没法在同一平面中画出，因此在绘制数据流图时要分为多个子图来画。

绘制的原则通常是，先绘制树根节点对应的子图，而后绘制根节点的子节点所对应的子图，一直绘制到全部叶子节点对应的子图为止。

 

 

下面以某中石化集团的样品分析管理系统（一个子系统）的开发为例，介绍数据流图的基本绘制方法。

1）绘制根节点图。从加工粒度上看，根节点图（即根节点对应的数据流图）是最大的数据流图，它是将整个应用系统看成一个加工。

【例子】 对于样品分析管理系统（YPFXMS），其根节点子图如图3.2所示。

 

2）绘制子节点图。数据流图的根节点不提供任何有用的信息，须要对加工“样品分析管理系统”做进一步的分解。在调研中发现，不是每一种样品都须要分析的，可以分析的是那些已经有计算公式或分析方案的样品，并且送样（被送用于分析的样品）要先存在样品分析员那里，样品分析员则按照某一个原则一次对这些送样进行分析。在送样被分析，还须要对分析的结果进行检查，若是发现分析结果不合格（是指分析手段和方法出错）则返回给样品分析员从新进行分析，分析合格则返回给送样人员。因而，分解后获得如图3.3所示的数据流图。

 

 

 

 

2.2.4 造成数据字典

数据流图主要是表示数据和处理之间的关系，但缺少对数据流、数据文件、加工等图中各个元素进行描述的能力。

数据流图是将用户头脑中的须要转化为机器可以接受的表达的一个中转站，但数据流图表示的信息离机器可以接受的信息还比较远。若是把用户需求和机器表示放在两头，数据流图放在二者之间，那么数据流图更靠近用户需求一些，而相对远离机器表示。

须要引入数据字典的概念，经过数据字典能够增强数据流图的信息表达能力，同时这种表达拉近了与机器表示的距离，使得用户需求从纯粹的逻辑表达逐步转向机器表示，为数据库的实施奠基基础。

与数据流图同样，数据字典也是SA方法中一种有力的工具。数据字典与数据流图结合使用，主要是用于对数据流图中出现的各类元素进行描述，给出全部数据元素的逻辑定义。数据字典是数据流图中数据元素的描述。这种描述是由一系列的条目组成，但不一样的应用、不一样的系统其组成的条目可能有所不一样。至少应该包括数据流、数据文件、加工和数据项等四种条目。

 

数据项条目

     数据项是数据构成的最小组成单位，它不能再分割。数据项条目用于说明数据项的名称、类型、长度、取值范围等。

    例如，在课题管理系统中数据项“课题申请代码”条目可描述以下：

数据项名：课题申请代码

类型：字符型

长度：12

取值范围：000000000000～999999999999

取值说明：前4为年号，第5到第6位、第7到第8位分别表示月份和日期，后4位表示     当天的课题序号

 

数据流条目

    数据流条目主要用于说明数据流的组成（由哪些数据项组成），数据流的来源和流向以及数据流量等信息。

    例如，数据流“样品分析请求信息”条目描述以下：

数据流名称：样品分析请求信息

组成：申请表编号、申请表名称、分析项目代码、样品编号、

            样品名称、送样日期、送样人员

来源：记录送样信息（加工）

去向：样品分析请求信息（文件）

流量：10～20/天天

 

数据文件条目

    数据文件条目用于说明数据文件是由哪些数据项组成，组织方式、存储频率如何等信息。

例如，数据文件“一审合格实验信息”条目以下：

文件名：一审合格实验信息

数据组成：试验记录表编号、试验记录表名称、试验日期、试验环境、试验目的、     操做人员、原料规格、试验配方与工艺、操做过程与现象、

                                  试验结果与讨论、记录人员、试验组长、课题代码

组织方式：按试验记录表编号递增排列

存储频率：1次/天

 

加工条目

    加工条目主要用于说明加工的逻辑功能、指明输入数据和输出数据等信息。其中逻辑功能项用于指出该加工用来作什么、对加工处理的一些要求等。

       例如，

加工编号：1

加 工 名：记录送样信息

输入数据：样品数据

输出数据：样品分析请求信息

逻辑功能：对送检的样品数据进行登记，并由此转化成样品分析请求信息。

 

 

3. 数据库结构设计

3.1 概念结构设计

3.1.1概念结构定义

　　需求分析的成果是数据流图和数据字典，概念结构设计的目的就是将抽象转化为信息世界中基于信息结构表示的数据结构——概念结构，即概念结构是用户需求在信息世界中的模型。

　　数据库的概念结构独立于它的逻辑结构，更与数据库的物理结构无关。它是现实世界中用户需求与机器世界中机器表示之间的中转站。它既有易于用户理解、实现分析员与用户交流的优势，也有易于转化为机器表示的特色。当用户的需求发生改变时，概念结构很容易做出相应的调整。因此，概念结构设计是数据库设计的一个重要步骤。

　　概念模式描述的经典工具是E-R图，由E-R图表示的概念模型就是所谓的E-R模型。E-R模型的建立和设计过程就是概念结构的建立和设计过程，概念结构的设计集中体现为E-R模型的设计。

E-R模型的优势：

　　它具备较强的表达能力，能够充分表示各类类型数据及数据之间的联系；

　　数据表达形式简单，没有过多的概念，定义严格，无二义性等；

　　E-R模型是以图形的形式出现，表示直观。

 

 

3.1.2设计思想

　　四种概念结构的设计指导思想：

自顶向下：首先根据用户需求定义全局概念结构的E-R模型，而后对其分解，逐步细化。

自底向上：首先根据各个部门的需求定义局部概念结构的E-R模型，而后将这些局部的E-R模型并接成为全局的E-R模型，造成全局概念结构。

先主后次：分析各类子须要的“轻重”，首先设计最重要的概念结构，造成它的E-R模型，而后定义次要概念结构的E-R模型，接着按照相似的方法定义其余全部概念结构的E-R模型，最后将这些模型继承起来，造成全局概念结构。

上下混合：这是指将自顶向下和自底向上这两种方法结合起来使用的一种设计方法。

 

　　概念结构设计一般采用的是自底向上的设计方法（而需求分析通常是采用自顶向下的方法），即这种方法分为两步：

• 　　先创建局部概念结构的E-R模型；
• 　　而后将全部的局部E-R模型集成起来造成全局概念结构。

 

如下主要介绍这种自底向上的概念结构设计方法：

步骤一： 局部E-R模型的设计

　　E-R模型的设计基于需求分析阶段产生的数据流图和数据字典来进行。一个系统的数据流图是按分层来绘制，是由多张数据流图构成。基于一张数据流图及其对应的数据字典部分进行的E-R模型设计获得的是一个局部概念。

实体和实体间联系的划分并没有统一的标准，通常采用的划分原则是，先是凭经验，后再做调整。

　　经验是指在通常状况下对于那些具备共同特征和行为的对象，能够将之抽象为实体；对象的共同特征和行为能够抽象为实体的属性。

　　调整是指在凭经验做出抽象后，根据具体的应用和建模环境对实体与其属性之间的关系以及实体与实体之间的关系做出相应的更改，有可能使得原来的属性变为实体，原来是实体的变为属性等，从而也致使了实体间关系的改变。

 

实体及实体间关系的抽象注意如下三点：

   （1）在同一应用环境中，被抽象为属性的事物就不能再被抽象为实体了，不然会致使“属性又包含属性”的错误，这违反第一范式；

   （2）属性具备不可再分性，因此具备不可再分性的事物通常都应抽象为属性，而具备可再分性的事物通常不能抽象为属性；

   （3）一个事物不能同时被抽象为两个实体的属性，即一个属性只能隶属于一个实体。

 

【例子】  对于一个企业信息管理系统来讲，企业中的工做人员能够抽象为“职工”实体，而工做人员的姓名、性别、年龄、职称、所在部门等能够抽象为“职工”实体的属性，如图3.4所示。

 

 

【例子】  若是在这个系统中除了“职工”信息之外还须要考虑部门的一些信息，如部门的名称、人数、经理、位置等信息，那就应该对前面的抽象做调整：应该将“部门”由原来做为“职工”的属性改成一个新的实体——“部门”实体，同时原来做为属性的“部门”被删除（这避免了一个事物既做为属性又做为实体的状况出现）。这两个实体的关系是“部门”拥有“职工”（或者“职工”隶属于“部门”），即“拥有”是这两个实体之间的联系。这样，原来的E-R图进一步获得调整和扩充，如图3.5所示。

 

 

从需求分析中发现，部门中的职工所作的工做是开发项目，用于说明项目的信息包括项目名称、项目性质、项目开发的起始时间、项目经费、项目经理等。将项目抽象为实体，造成“项目”实体，其E-R图如图3.6所示。

 

 

步骤二：全局E-R模型的集成

相对于一个总体而言，以上是E-R局部图，这些E-R图应该可以合成一张总的E-R图。对概念结构来讲，就是将局部概念结构集成为全局的概念结构。

【例子】 根据需求分析结果，在这个企业中每一个部门都有承接多个项目的可能，每一个职工只参加一个项目。将图3.5和图3.6所示的E-R图并接起来，结果获得了整个系统的E-R图，如图3.7所示。

 

 

　　局部E-R图的并接过程当中产生许多问题，这些问题主要体现为各个局部E-R图之间的冲突，其中包括命名冲突、属性冲突和结构冲突等。

• 命名冲突

命名冲突是指意义不一样的元素在不一样的局部E-R图中有相同的名字，或者是有相赞成义的元素在不一样的局部E-R图中具备不相同的名字。

• 属性冲突

 属性冲突是指同义同名的属性在不一样的局部E-R图中的取值类型、范围、所使用的单位等却彻底不同。

  【例子】 有的将职工编号定义为长度为12个字节的字符串类型，有的则定义为8个字节的字符串类型，有的可能将职工编号定义为整型。

在一个E-R图中不该该存在属性冲突。

• 结构冲突

结构冲突是指一个事物在一个局部E-R图被抽象为实体，而在另外一个局部E-R图中又被抽象为属性。

　　这不能直接将这两个局部E-R图并接为一个E-R图，首先要解决结构冲突问题。解决的办法是，视具体状况将相应的属性改成实体，或者将相应的实体改成属性。

　　还有一种结构冲突是相同的实体在不一样的局部E-R图中有不一样的属性或不一样的联系。对于前一种状况，一种简单的解决方法是：使该实体的属性集为它在各E-R图中的属性集的并；对于后一种状况，解决方法相对复杂，要视具体状况对联系进行分解，或者进行其余的调整。

 

　　在构建的E-R图中，最好不要包含环形结构，由于这容易出现“死循环”参照关系。

【例子】 假设实体X、Y和Z以及它们之间的联系a、b和c构成如图3.8所示的E-R图，则该E-R图出现“死循环”问题，由于在据此图创建数据表时，将出现X参照Y、Y参照Z、Z参照X的“死循环”参照关系，从而没法建立数据表。所以，若是一个E-R图包含环形结构，则须要进一步确认对概念结构的建模是否正确？从新修改E-R图，或者直接将环中的一条边（关联）去掉，以破坏“死循环”结构。

 

 

 

3.1.3步骤 

　　概念结构设计中，实体集中的实体彼此是可区别的。若是实体集中的属性或最小属性组合的值能惟一标识其对应实体，则将该属性或属性组合称为码。对于每个实体集，可指定一个码为主码。

　　若是用矩形框表示实体集，用带半圆的矩形框表示属性，用线段链接实体集与属性，当一个属性或属性组合指定为主码时，在实体集与属性的链接线上标记一斜线，则能够用图1.4描述学生成绩管理系统中的实体集及每一个实体集涉及的属性。

 

 

图1.4 学生和课程实体集属性的描述   其中 \主键

1．一对一的联系（1 : 1）
A中的一个实体至多与B中的一个实体相联系，B中的一个实体也至多与A中的一个实体相联系。例如，“班级”与“正班长”这两个实体集之间的联系是一对一的联系，由于一个班级只有一个正班长，反过来，一个正班长只属于一个班级。“班级”与“正班长”两个实体集的E-R模型如图1.5所示。

 

 

2．一对多的联系（1 : n）
A中的一个实体能够与B中的多个实体相联系，而B中的一个实体至多与A中的一个实体相联系。例如，“班级”与“学生”这两个实体集之间的联系是一对多的联系，由于，一个班级可有若干学生，反过来，一个学生只能属于一个班级。“班级”与“学生”两个实体集的E-R模型如图1.6所示。

 

 

 

 

3．多对多的联系（m : n）
A中的一个实体能够与B中的多个实体相联系，而B中的一个实体也可与A中的多个实体相联系。例如，“学生”与“课程”这两个实体集之间的联系是多对多的联系，由于，一个学生可选多门课程，反过来，一门课程可被多个学生选修。“学生”与“课程”两个实体集的E-R模型如图1.7所示。

 

注意：实体图ER图能够分开

 

 

 

 

 

3.2 逻辑结构设计

数据库的逻辑结构设计就是将以E-R图表示的概念结构转换为DBMS支持的数据模型并对其进行优化的过程。

概念结构是由E-R图来描述的，概念结构到关系模型的转换能够归结为E-R图到关系模型的转换问题。E-R图的基本元素是实体、属性和联系等，因而E-R图到关系模型的转换就变成了实体、属性和联系等基本元素到关系模式的转化问题。

 

 

1. 实体和属性的转变

这种转变比较简单、直观，即一个实体转化为一个关系模式，其中实体名变成了关系模式的名称，实体属性相应地变成了关系的属性。

 【例子】 图3.7中的三个实体分别转化为如下三个关系模式：

项目（编号，名称，经理，性质，启动时间，结题时间，经费）

部门（编号，名称，经理，人数，地址）

职工（编号，姓名，性别，职称，年龄）

 

 

2. （1:1）联系的转变

一对一联系的转变：建立一个独立的关系模式，该关系模式的属性是由该联系自己的属性以及与之相连的实体的候选码（每一个实体中取一个候选码）组成。

 

1 : 1联系的E-R图到关系模式的转换

1∶1的联系既可单独对应一个关系模式，也能够不单独对应一个关系模式。

能够放在一个里，不用单建表
（1）联系单独对应一个关系模式，则由联系属性、参与联系的各实体集的主码属性构成关系模式，其主码可选参与联系的实体集的任一方的主码。
例如，对于图1.5描述的“班级（BJB）”与“正班长（BZB）”实体集经过属于（SYB）联系E-R模型，可设计以下关系模式（下横线表示该字段为主码）：
BJB（班级编号，院系，专业，人数 ）
BZB（学号，姓名）
SYB（学号，班级编号）

（2）联系不单独对应一个关系模式，联系的属性及一方的主码加入另外一方实体集对应的关系模式中。
例如，对于图1.5描述的“班级（BJB）”与“正班长（BZB）”实体集经过属于（SYB）联系E-R模型，可设计以下关系模式：
BJB（班级编号，院系，专业，人数）
BZB（学号，姓名，班级编号）
或者
BJB（班级编号，院系，专业，人数，学号）
BZB（学号，姓名）

 

【例子】 一个仓库仅由一个仓库管理员管理，而一个仓库管理员也只能管理一个仓库，因此仓库管理员和仓库之间的联系是管理，管理时间为8小时（一天），其E-R图如图3.9所示。

 

 

“仓库管理员”和“仓库”之间的联系是（1:1），该联系转换后造成以下的关系模式：管理（管理员编号，仓库编号，时间）

管理员编号和仓库编号分别为“仓库管理员”实体和“仓库”实体的候选码，时间是“管理”联系的属性。

 

 

有时候为了减小数据冗余，能够将联系对应的关系合并到与之相连的某一个实体对应的关系中去。

方法：将一个实体的候选码以及联系的属性添加到另外一个实体对应的关系中。

 【例子】 对于以上例子，易知“仓库管理员”实体对应的关系以下：

仓库管理员（管理员编号，姓名）

咱们只需将“仓库”实体的候选码“仓库编号”以及联系的属性“时间”一块儿添加到仓库管理员关系中便可，从而实现对联系“管理”的转换，结果获得的关系模式以下：

             仓库管理员（管理员编号，姓名，仓库编号，时间）

也能够将“仓库管理员”的候选码和联系的属性“时间”一块儿添加到仓库关系中，结果获得以下的关系模式：

            仓库（仓库编号，仓库规模，管理员编号，时间）

联系能够合并到任意与之相连的实体对应的关系中。但在实际应用，每每从效率的角度来考虑如何进行合并。

 

 

 

3.（1:n）联系的转变

一对多联系能够转化为一个独立的关系模式，也能够将联系合并到n端对应的关系模式中。

能够放在一个里，不用单建表

 【例子】 对于图3.7所示的E-R图，“拥有”联系是一对多联系，当把这个联系转化为独立的关系模式时，则获得以下的关系模式：

拥有（职工.编号，部门.编号）  

用合并的方法对该联系进行转换，则获得以下的关系模式：

职工（职工.编号，姓名，性别，年龄，职称，部门.编号）

        其中，以上的“编号”属性都是相应实体的主码。

 

1 : n联系的E-R图到关系模式的转换
1∶n的联系既可单独对应一个关系模式，也能够不单独对应一个关系模式。
（1）若联系单独对应一个关系模式，则由联系的属性、参与联系的各实体集的主码属性构成关系模式，n端的主码做为该关系模式的主码。
例如，对于图1.6描述的“班级（BJB）”与“学生（XSB）”实体集E-R模型，可设计以下关系模式：
BJB（班级编号，院系，专业，人数）
XSB （学号，姓名，性别，出生时间，专业，总学分，备注）
SYB （学号，班级编号）
（2）若联系不单独对应一个关系模式，则将联系的属性及1端的主码加入n端实体集对应的关系模式中，主码仍为n端的主码。
例如，对于图1.6描述的“班级（BJB）”与“学生（XSB）”实体集E-R模型，可设计以下关系模式：
BJB（班级编号，院系，专业，人数）
XSB （学号，姓名，性别，出生时间，专业，总学分，备注，班级编号）

 

 

 

4.（m:n）联系的转变

多对多必须创建一个表

多对多联系只能转换为一个独立的关系模式，其属性集是由与该联系相连的实体的属性（码）以及该联系自己的属性转换而获得的。

【例子】 一个仓库能够存放多种零件，一种零件也能够存放在多个仓库中，可见仓库和零件之间的联系——“存放”是（m:n）联系。假设其E-R图如图3.10所示。

 

 

“存放”联系转换为独立的关系模式后，结果以下： 

存放（仓库编号，零件编号，数量）

 

m : n联系的E-R图到关系模式的转换
m : n的联系单独对应一个关系模式，该关系模式包括联系的属性、参与联系的各实体集的主码属性，该关系模式的主码由各实体集的主码属性共同组成。
例如，对于图1.7描述的“学生（XSB）”与“课程（KCB）”实体集之间的联系可设计以下关系模式：
XSB（学号，姓名，性别，出生时间，专业，总学分，备注）
KCB（课程号，课程名称，开课学期，学时，学分）
CJB（学号，课程号，成绩）
关系模式CJB的主码是由“学号”和“课程号”两个属性组合起来构成的一个主码，一个关系模式只能有一个主码。

 

 

5. 应用规范化理论实现逻辑结构的优化

逻辑结构设计的结果是数据模型。以上主要介绍了如何将以E-R图表示的概念结构转化为以关系模型表示的逻辑结构。在造成关系模式后，还须要对其进行优化处理，以尽量地减小数据冗余、删除冲突和插入冲突等问题。

 

6. 用户子模式的设计

用户子模式也称为外模式，它是面向用户的，是用户可见的数据模型部分。它能够屏蔽概念模式，有助于实现程序与数据的独立，能够知足不一样用户对数据的个性化需求，同时也有利于数据库的管理。

用户子模式的设计主要是利用局部E-R图，由于每一张E-R图通常都是表示局部概念结构。如今流行的DBMS通常都提供了视图功能，支持用户的虚拟视图。咱们能够利用这个功能设计符合不一样局部应用须要的用户子模式。

 

 

 

3.3 物理结构设计

物理结构设计就是为既定的数据模型选取特定的、有效的存储结构和存储路径的过程。

　　特定性是指跟具体的计算机系统有关，包括操做系统和DBMS等；

　　有效性是指以尽量少的系统资源获取数据库尽量高的运行效率。

物理结构设计的内容主要包括数据库存储结构的肯定和数据库存取方法的肯定。

 

 

数据库存储结构的设计

任务：肯定数据的存放位置和使用的存储结构，肯定在磁盘空间中存储关系、索引、日志、备份等的数据库文件，设置系统存储参数，目的是使得以最小的系统资源获取最高的系统性能。

存储结构的设计是在已选定的DBMS和硬件条件下进行的，主要从如下两个方面考虑:

（1）肯定数据的存放方式

在大多的关系DBMS中，数据的分类和指定存储是经过数据文件的划分和存储来实现。

在DBMS中，不能直接指定数据的存放位置，而只能经过必定的机制实现数据文件的指定存放，从而实现将数据存放在指定的位置。肯定了数据文件的存放位置也就肯定了数据的存放位置。

数据文件的划分和存储主要是基于数据访问的稳定性、安全性、效率等方面考虑的，相应的指导性规则包括：

　　数据库文件和日志文件应该分开存放在磁盘中。

　　若是计算机系统中有多个磁盘，能够将数据库文件分为多个文件，并分布在不一样的磁盘中。

　　将数据表和索引等分开存放在不一样的数据库文件中。

　　大的数据对象要分散存储在不一样的数据库文件中。

（2）肯定系统参数的配置

系统参数是指DBMS提供设置参数。这些参数主要包括数据库的大小、同时链接的用户数、缓冲区个数和大小、索引文件的大小、填充因子等。DBMS通常都对这些参数设置了初始值，但这些设置并不必定适应每一种应用环境，这须要设计人员从新设计。

这些参数的配置操做通常均可以在DBMS提供管理工具中完成。

【例子】 SQL Server 2008提供的管理工具是SQL Server Management Studio（SSMS），SSMS能够管理SQL Server 2008的全部组件，包括访问、配置、控制和开发这些组件。

 

 

2. 肯定存取方法

　　存取方法即关系模式的存取方法，目的是实现数据的快速存取。每一种DBMS都提供了多种不一样的存取方法，索引法是最经常使用的一种，在实际开发当中用得最多。如下重点介绍索引法。

索引为何能够提升数据库中数据的存取速度呢？

　　这道理与目录能够提升书的查阅速度的道理同样，便可以将索引形象地比喻为目录。索引正是基于目录的原理来设计，它是“数据标题”和数据内存地址的列表。经过索引能够从部分数据检索中实现数据的快速查找，从而提升数据的查询效率。

索引的建立并非无代价的。

　　索引自己也是一种数据表，一样占用存储资源，并且要保持与数据表的同步，这要求在进行数据更新操做（包括添加、删除和修改操做）时也要对索引进行相应的更新操做。若是索引很大时，其占用的空间资源以及对其更新维护所须要的代价一样是很是可观的。对索引的建立与否，应该慎重考虑。

 

 

　　在建立索引时，几个经验性的指导原则：

　　　　在常常用于检索的列上建立索引，特别是要对主码建立索引（通常是由DBMS自动完成）。

　　　　在外键上建立索引，由于它常常用于与其余关系进行链接查询。

　　　　多在以读为主或者常常须要排列的列上建立索引。由于索引已经排序，它能够加快读取速度和排序效率。

　　　　多在常常用于条件查询的列上建立索引，特别是对那些经常出现少许元组知足条件的列。

　　　　而对具备如下性质的列，则不宜对其建立索引：

　　　　　　对于不常常用于检索的列，则不宜在其上建立索引。

　　　　　　对于那些值域很小的列不该该建立索引。

　　　　　　对于值域严重分布不均匀的列不宜在其上建立索引。

　　　　　　对于更新操做很是频繁的列，不宜在其上建立索引。

　　　　　　对于长度超过30个字节的列，通常不要在其上建立索引。

 

 

4. 数据库实施

数据库实施包括如下几方面的内容：

1. 创建数据库结构

根据物理结构的设计结果，选定相应的DBMS。而后在该DBMS系统中利用其提供的DDL语言创建数据库结构。

例如，在SQL Server中，可用下列的SQL语句来分别建立数据库和数据表：    CREATE DATABASE database_name

             CREATE TABLE table_name

在数据库结构定义之后，经过DBMS提供的编译处理程序编译后便可造成了实际可运行的数据库。但这时的数据库还仅仅一个框架，内容是空的。要真正发挥它的做用，还须要编写相应的应用程序，将数据保存在其中，造成一个“有血有肉”的动态系统。

 

 

2. 装载测试数据，编写调试应用程序

应用程序设计与数据库设计能够同时进行，应用程序的代码编写和调试则在数据库结构建立之后进行的。

应用程序的编写和调试是一个反复进行的过程，其中须要对数据库进行测试性访问。这时应该在数据库中装载一些测试数据。这些数据能够随机产生，也能够用实际数据做为测试数据（但这些实际数据要留有副本）。

 

3. 试运行

　　在应用程序调试之后，给数据库加载一些实际数据并运行应用程序，但尚未正式投入使用，而只是想查看数据库应用系统各方面的功能，那么这种运行就称为试运行，试运行也称联合调试，

　　试运行与调试的区别：二者目的基本同样，但侧重点有所不一样。调试主要是为了发现系统中可能存在的错误，以便及时纠正；试运行虽然也须要发现错误，但它更注重于系统性能的检测和评价。

　　试运行的主要工做包括：

　　　　系统性能检测。包括测试系统的稳定性、安全性和效率等方面的指标，查看是否符合设计时设定的目标。

　　　　系统功能检测。运行系统，按各个功能模块逐项检测，检查系统的各个功能模块是否可以完成既定的功能。

　　　　若是检测结果不符合设计目标，则返回相应的设计阶段，从新修改程序代码或数据库结构，直到知足要求为止。

 

 

5. 数据库系统的运行和维护

试运行结束并被证明符合设计要求后，数据库就能够正式投入使用。

数据库的正式使用标志着数据库开发阶段的基本结束，同时意味着数据库运行和维护阶段的开始。

数据库的运行和维护并非数据库设计的终点，而是数据库设计的延续和提升。

数据库的平常运行和维护也是一项专业性很强的工做，须要很强的专业技术。维护工做不是普通的用户就可以胜任的，通常是由系统管理员（DBA）完成。这种工做就是软件产生品的售后服务。

 

 

在数据库的运行和维护阶段，DBA的主要工做包括：

1.数据库的转储和恢复

一旦数据库正式投入使用，企业的相关数据将所有存入数据库（通常不会另记在纸质材料中）。若是数据库发生故障，可能会致使这些数据的丢失，从而形成企业的重大损失。为了尽可能避免在数据库发生故障时形成数据丢失，DBA应当根据应用的具体要求指定相应的备份和恢复方案，保证一旦发生故障，可以尽快将数据库恢复到某一种一致性的最近状态，尽可能减小损失。

数据库转储：数据库恢复技术，是指按期地把整个数据库复制到磁盘或者其余存储设备上保护起来的过程。数据库的转储和恢复是数据库运行维护中最重要的工做之一。

2. 数据库性能的检测、分析和改善

随着运行时间的增长，数据库的物理存储不断发生改变，加上数据量和用户的不断增长，这都使得数据库的运行性能不断降低。DBA必须利用DBMS提供的性能监控和分析工具按期地对数据库的各类性能指标进行检测，以便及早地发现问题并采起相应的优化和改善措施。

3. 数据库的安全性和完整性维护

无论是从企业内部仍是从企业外部来说，数据库的安全性和完整性都是相当重要的。做为数据库的管理者，DBA必须对数据库的安全性和完整性负责。DBA应该认真审核每个用户的身份，并正确授予相应的权限；随着时间的推移和应用环境的改变，对安全性的要求也随之发生变化，这要求DBA对数据库的安全性控制做出相应的调整，以适应新的状况。相似地，数据库的完整性约束条件也会发生变化，这一样要求DBA做出相应的修正，以知足新的要求。

4. 数据库的重组和重构

　　数据的插入、修改和删除是数据库的基本操做。这些操做的屡次使用会使得数据在磁盘上的存储分布愈来愈散，致使数据的存储效率下降，整个系统性能降低。这时应该对数据库进行从新组织（即重组），以提升系统的性能。如今流行的DBMS通常都提供重组功能。

　　数据库的重构:对数据库的模式和内模式进行调整，如增长或删除某些列和表、增长或删除某些索引、修改数据库的完整性约束条件等，这种调整就是对数据库进行从新构造的过程。

　　数据库重组和数据库重构有着本质的区别：

　　　　数据库重组的目的：提升系统的性能，经过DBMS提供的功能对数据库在磁盘上的存储分布进行调整来达到重组的目的，重组不会改变数据库的模式和内模式；

　　　　数据库重构的目的：实现新的用户需求，须要修改数据库结构，从而使得数据库的概念模式和内模式也被修改。

　　不是在迫不得以的状况下，不要使用数据库重构。数据库重构不但使数据库结构发生了改变，并且在多数状况下也要求应用程序做出相应的修改。这会致使“牵一发而动全身”的后果，由数据库重构而引发的修改工做量是很是大的。

　　数据库重构并非“无所不能”，数据库重构能够实现新的用户需求，但这种需求的变化幅度必须限制在必定的范围内。超过这个范围，数据库重构可能没法实现，也多是实现的代价过高而失去重构的意义。