数据库结构设计

一、数据库结构设计步骤

二、需求分析

三、概念结构设计

四、逻辑结构设计

五、数据库物理设计

数据库结构设计

一、数据库结构设计步骤

一般可将数据库结构设计分为四个阶段，即需求分析、概念结构设计、逻辑结构设计和物理设计。

下面各节分别介绍各阶段设计内容和具体方法。

二、需求分析

需求分析的任务是具体了解应用环境，了解与分析用户对数据和数据处理的需求，对应用系统的性能的要求，提出新系统的目标，为第二阶段、第三阶段的设计奠定基础。一般需求分析的操作步骤如下所述。

1．了解组织、人员的构成

子系统的划分常常以现有组织系统为基础，再进行整合，而新系统首先必须达到的目的是尽可能地完成当前系统中有关信息方面的工作，在原有系统中，信息处理总是由具体人来实施的。我们要了解组织结构情况、相互之间信息沟通关系、数据（包括各种报告、报表、凭证、单据）往来联系情况。

具体弄清各个数据的名称，产生的时间与传递所需时间与周期，数据量的大小，所涉及（传送）的范围，使用数据的权限要求，数据处理过程中容易发生的问题及其影响，各个部门所希望获得的数据的情况等。

然后了解每个人对每一具体数据处理的过程，基本数据元素来源于哪些地方、获取的途径、处理的要求、数据的用途，进而弄清数据的构成、数据元素的类型、性质、算法、取值范围、相互关系。

在上述调查基础上，首先画出组织机构及工作职能图。我们以一个学校的基层单位——某大学一个系的管理为例来简要说明。

系的组织机构及工作职能如图7.1所示。

图7．1 系管理体系结构图

作为管理层经常需要的信息和工作有：

．查询老师个人基本情况及打印相应内容

．查询与统计科研项目情况及相关报表

．查询与统计论文著作情况及相关报表

．上级部门及其他部门来文管理与查询（要求能全文检索）

．系部发文管理

．任务下达、检查及管理

．信件、通知的收发及管理

．日程安排调度及管理

．设备仪器计划及管理

．设备入库与库存情况管理与查询

．设备借还领用管理及相应报表

．耗材计划与领发管理及相应统计报表

．图书管理及借还情况查询

．学生毕业设计文档管理

．专业与班组编制与查询

．教学文档管理及查询（安排与检查，包括课表、考试日程安排、监考安排等）．学生成绩管理与查询和统计

．教师、学生、实验室课表管理及查询

．学生基本情况管理与查询（包括社会活动、奖惩、家庭情况及学校校友管理）

．实验安排与管理

．实验成绩管理及查询与统计

．奖金计算与发放

．收支情况管理及统计与查询

我们仅以设备仪器管理为例说明。现有设备表格有七种，名字及数据栏目如下：

①入库单（代码，院内编号，名称，型号，规格，单价，数量，金额，生产厂，购入单位，采购员，管理员，入库日期，经费来源，批准人，计划号）

②领用单（代码，院内编号，名称，型号，规格，单价，数量，领用人，批准人，领用单位，管理员，领用日期）

③报废单（代码，院内编号，名称，型号，规格，单价，数量，报废原因，批准人，管理员，报废日期）

④借条（代码，院内编号，名称，型号，规格，单价，数量，借用日期，拟还时间，借用人，批准人，管理员，设备状况）

⑤请购计划（名称，型号，规格，估计单价，请购数量，计划员，计划时间，批准人，批准时间，设备用途，计划号）

⑥设备明细账（代码，院内编号，名称，型号，规格，单价，生产厂，购入单位，采购员，入库时间，设备类别，当前状况）

⑦设备统计表（名称，型号，规格，单价，数据，金额，备注）

其中入库单由采购员填写，经批准交管理员输入办理入库手续，管理员签收并形成入库凭证下转财务。领用单由领用人填写，经批准交管理员办理领用手续，当报废时或归还时应办报废手续或归还手续。借条由借用人填写，经批准交管理员办理借用手续，当归还时应归还借条并办归还手续。设备明细账、设备统计表均由设备管理员填写。报废单要经批准报上级主管部门。其他账表要供上级主管部门及系部检查、查询。请购计划由计划员填写经批准交采购员实施，要能供查证。

各表格、各栏目数据之名称、数据类型等特性应专门说明并记载入数据字典中。

2．数据字典

数据字典（Data Dictionary DD）用于记载系统定义的或中间生成的各种数据、数据元素，以及常量、变量、数组及其他数据单位，说明它们的名字、性质、意义及各类约束条件，是系统开发与维护中不可缺少的重要文件。数据与数据元素分别用数据表、数据元素表记载。数据表、数据元素表的格式如下表7．1和表7．2所示。

表7．1 数据表格式

其中，数据号是设计人员给定的顺序编号，用于分类清查与整理，并且与数据元素代码相关联。数据名是原有表格或凭证的名称，如成绩单、人事卡片、档案……。其他各项的意义说明如下：

主人：生成该数据的单位与个人代表。数据有一个主要生成者，有多个使用者，使用者即用户是使用生成的数据或其拷贝的单位或个人（包括仅使用该表部分数据元素的单位和个人）

生成时间：计算、打印或显示本数据的时间，有些数据只生成一次，例如一些突如其来的查询或统计操作的结果；有些每年生成一次，例如年报；还有依半年、季、月、半月、旬、周、日、时生成的，此处记载每次生成的大体时间。例如年报记每年何月（何日）生成，月报记每月何日生成等。

数据量：一条记录最大长度（不考虑备注与通用字段实际长度）。数据用途记该数据在系统中的作用或使用意义，例如设备统计表，是当前所存物资的统计生成表，提供决策依据等。

保存时间：有些数据是系统的基本数据，长期保存，如人事卡片、设备帐本。有些数据生成后只需再保存一段时间，以供其他应用，例如工资表及其相关数据，每月发放工资后还要继续保存3至5年，用于工资构成和成本分析，工资表相关的考勤、行政扣资、公积金等许多数据往往要保持一年，供年度统计使用等。也有些统计查询的结果则无须保存。

数据源：本表某些数据元素是来自另一个表或文件，应在此处及数据元素表中同时标明，以便将来某些数据结构修改时分析其附带影响，保证数据一致性和完整性。

关联数据：本表中有些数据将被用作另一些数据的源，需要列出这“另一些”数据的名字，以便将来对本表结构修改时考虑对其他数据的影响。

别名：该数据表的其他取名。

表7．2 数据元素表格式

其中，数据号是本数据元素所属数据的代号，要与数据表中编号对应。数据元素号是在该数据中的各数据元素的顺序编号。物理名称是实际数据中使用的名称。逻辑名称是指将来在系统数据结构中采用的名称。来源或算法指数据元素有些直接从另一些数据中提取，有些按一定方法或公式求取，在此应予注明来源或计算方法。完整性指是否为关键字，是否允许重复值，是否允许空值，取值范围限制等。安全性指对该数据元素查询、显示、使用及录入、修改、删除等操作权限是否有要求及什么样的要求。用户数据名指本数据元素可能用到哪些表的名称。

数据字典还将包含今后开发中涉及到的其他数据，例如在程序中使用的常量、变量、数组、集合、函数……要在开发过程中不断补充。即使是上述数据、数据元素，许多最终将被认定为数据库中的字段或系统中其他数据，要再作说明，也有些将不再出现。有些元素的性质、意义会有所改变，都将在开发过程中不断修改和补充。

在需求分析最后阶段，要进一步描述数据处理的流程，并写出需求分析说明书。

3．需求分析说明书

需求分析说明书是对需求分析过程的记载与总结，也是将来开发的依据和标准，将作为开发方和最终用户间交接的依据，是一个纲领性的文件。要使用尽可能精炼、通俗易懂、准确无二义性的语言表达对系统功能、性能的要求。需求分析说明书一般包括下述内容：．数据库系统应用范围与环境条件

．工作流程图

．数据流程图

．数据字典（包括数据表与数据元素表）

．IPO图与加工说明

．数据库性能要求

．对操作界面的要求

．各类约束条件

．开发目标与方法

．组织机构

．系统当前状况分析

．数据库系统功能设计目标

．对系统结构的初步规划

．日程进度

．验收标准

其中关于当前系统状况分析应提交前述数据字典及全部原始材料，并进一步分析当前系统的工作、数据处理情况、存在问题并提出解诀方案。关于系统当前工作，数据处理情况的分析是新系统功能、性能设计的依据。

我们常常首先以工作流程图描述当前各部门、各主要业务人员的工作过程。一个工作流程图实例如图7．2所示。根据有关部门、工作人员对自己工作的描述，可画出工作流程图形象地表示组织与个人工作情况，主要是涉及数据和信息工作的情况。其主要图例中用矩形表示部门或组织，用圆圈表示工作人员，用双横线表示文件、数据库，用箭头线表示数据及其流向。在箭头线上标注数据名称。例如入库工作我们可用图7．2表示。

图7．2 入库工作流程图

从工作流程图，我们看不清数据处理情况，可再进一步抽象，工作流程图中可以由计算机处理的部分抽象出来，画成数据流程图，得到系统的逻辑模型。数据流程图图例中以圆圈表示数据源、数据结果或外部实体，矩形表示数据处理，箭头线表示数据，线上标注数据名称，双横线表示文件或数据库。入库过程数据流程图如图7．3所示。

图7．3 入库过程数据流程图

这个图对于处理逻辑仍表现不充分，我们可用输入一处理一输出图（IPO图）进一步表示清楚。IPO图由三个矩形框组成，它们分别描述输入（I）、处理（P）和输出（O），用箭头线表示数据的传入传出，线旁标注处理条件或备注内容。上述入库过程用IPO图的描述如图7．4所示。

图7．4 用IPO图描述系统处理过程

如果处理过程比较复杂，图示仍不清楚，我们可附加加工说明，用文字详细说明每上步的处理过程和处理逻辑。

例如，关于“检查计划”的说明：

如果采购单上无领导签字

输入采购单上计划号

打开计划库

查找上述计划号

如果查到

读出计划数

查同一计划号物品已入库数量

如果小于等于计划数-采购数

办理入库

否则

说明计划额度已使用，退出

结束

否则

说明无此计划，不能入库

结束

结束

加工说明是用文字语言表述处理逻辑，尽量接近程序语言，又要通俗易懂，使得一方面能和业务人员展开讨论，进一步了解清楚业务人员的要求，另一方面又能较容易地转为实际程序。

在需求分析说明书中，还应具体写明有关处理安全性、时间性、可靠性、适应性等方面的要求，整理形成文档，经批准之后生效。

三、概念结构设计

概念结构设计是在需求分析的基础上对所有数据要求按一定方法进行抽象与综合处理，设计出不依赖于某种具体DBMS的满足用户应用需求的信息结构。这种信息结构我们称为概念模型。

最常用的概念结构设计方法有实体分析法、面向对象设计方法、属性综合法和规范化关系方法。我们此处主要讨论实体分析法。这是一种自上而下抽象的方法。

这种方法要求根据前面数据的需求分析，确定系统范围，确定实体及其属性，画出系统的实体联系模型（E－R图）

第一步划分系统范围。一般数据库应用系统的管理对象不外乎人、财、物、事几个方面。

与“人”有关的对象包括组织机构、职工或其他人员（以下以职工为代表）的基本情况、职工或其他人员各类活动。其中组织机构例如单位、部门、机构，它们的主要属性是地址、联系人、单位性质、单位概况……是职工的所属和依附或交往的实体。职工基本情况包括个人情况、简历、爱人情况、家庭情况、社会关系情况等几大块，而简历又包括调动史、进修与学习、奖惩、工作史（科研、著作、教学、参军史、从政史及其他业务），组织与社团历史、对外交往或社会活动等。在以往，简历往往以一个文本进行记载，而如今管理逐渐细化，要求能对人员活动和各方面情况作多种查询统计，使用文本已难满足应用要求。另外“人”

在管理中也分为不同的群体，例如学校中教师、职工、学生就各具有自己特殊的属性，教师、职工有工资、福利、教学等内容，学生有学习课程等内容，各自管理重点也不相同，应划分为不同分系统。

“财”一般涉及各种帐目、凭证、合同、协议计划、分析数据等。主要是人与物之间某些关系的数字体现，是一般管理系统管理的重要对象，在处理中有些被视为实体存储（例如流水帐）,有些是数学处理的结果（例如统计数据、报表等），这些数据许多无须保存，也有一些需留存供决策分析使用，如不需保留的数据无须实际存储。

“物”如设备、材料、产品、房产、车辆、能源、原料、物品、图书、行政用品等。我们常常依据上面各个方面或依据部门，确定局部信息范围。基本准则是功能相对独立，和其他局部信息范围相互影响较小，且实体个数尽量在10个以内。许多管理部门都是围绕上述一

个方面或彼此有较多关联的几个方面开展工作的，我们也往往依据一些局部范围划分分系统或子系统。进行实体分析也按一个个局部范围展开。在展开时注意，每一局部范围有自己管理的主要内容，在其他局部范围中也可能涉及这些内容，要尽量不重复设置实体以防冗余。

第二步选择实体。开始我们总是依据所获系统的各种数据作为信息单位，并作为选择实体的依据，如上所述我们制定的人、财、物、事等是典型的内容，根据具体环境还应进一步具体分析。依据实体定义，确定实体关键是善于找到具有共同属性的群体。例如，在设备管理中，数据有入库单、领用单、报废单、借条、领条、计划单、账本、统计表等，我们对其属性进行分析，可见有一个中心内容——设备及其自身的属性，另外还涉及到一些人如采购员、管理员、负责人、使用人等，涉及到一些单位和部门如生产厂、销售部门、管理部门、使用部门等，涉及到和财务有关的内容如单价、数量、金额等。

其中有些内容如管理部门、使用部门是单位管理分系统中管理的主要对象。管理人员、采购人员、使用人员等是职工人事管理分系统中管理的主要对象，它们对于设备管理分系统只是外部实体。在这一分系统中要注意：使用这些数据的名字、属性时要与其他两个分系统保持一致。

还有一些内容如生产厂、销售单位的情况可能只要求作为查询使用，不关心这些单位进一步的属性和细节，那么在做E-R图时可只指定它们作为属性，而不作为实体。不过如果我们要存储这些联系单位的数据，以为将来发展业务打基础，例如还希望存储关于他们的产品情况、质量情况、资金情况等数据，那就要单列实体了。

有些数据看上去是属于同一对象，但它们涉及的范围、信息内容并不相同，应区分为两个实体。例如，在设备管理中，设备计划虽也属设备管理，但它是对尚未购进的设备的计划，与已有设备在管理重点上不同、管理的内容也不同，有一些属性也有区别，关键字也互不相同，因而应列为两类实体。

第三步确定联系。通过进一步对它们之间关系的确定，可以得到设备管理的E-R图（本图省去一对多的联系菱形），如图7．5所示。

图7．5 设备管理E-R图

第四步确定实体的属性，依据需求分析中的数据元素整合得到。在分析时注意以下几点：（1）每个实体至少有一个关键字，这是唯一标识一条记录的属性。其他属性的值必须

由它唯一确定，否则就不是该实体的属性。

（2）找出所有同名属性，如满足上一条，则可合并为该实体的一个属性。有些同名，但实际代表意义不同，则应作为该实体不同属性，并给以不同命名。例如在文件管理中，随着文件传递将有多个“经手人”—一收文经手人、阅文经手人、执行（办文）经手人等，实际上他们代表的是不同的人在管理中执行不同的角色，因而应以收文人、传阅人、办文人等不同的命名加以区分。

另外，对于不同实体的同名属性，如果意义不相同，最好也以不同名字命名。例如企业生产最终产品和中间产品都是局部部门的产品，但意义不一样，中间产品是最终产品的子集，因此最好以不同名字命名，例如中间产品改名为“中间产品”或“XX部门产品”，企业最终产品仍命名为“产品”。

（3）对于一些计算数据，例如“金额＝单价*数量”可不作为属性列入。

（4）有些名字相同，意义也相同，但在不同范围内特性不相同，如精度、长度，取值范围等存在不同。这些属性在统一标准后可合并为一个属性，在未来不同范围的软件中加以区分，要求最终存储时数据能包容、满足各种需求。

（5）有些名字不同，但意义相同的属性，应统一名字，合并为一个属性。例如在企业中生产部门对产品命名时，通常按原料成分、加工工艺等定义，而进入销售部门后名字按商品名定义。两个名字不同，为了管理方便，在一个企业内最好都改为同一名字，可另外规定别名或另外设计相同的统一的代码表，通过代码联系名字可任其不同。对所有属性，在E-R 图中以前述对照表的形式标识。

最后一步分析和确定全局信息结构。我们从开始就划分了范围及各个范围的主要实体，一个范围在涉及另一个范围的主要实体时，我们也强调了主从关系并强调了保持一致性，防止冲突或重复。但由于是分为分系统研究的，因而冲突与重复仍然可能发生，完成各分系统E-R图之后，有必要进行一次全盘的检验，一方面对所有同名实体检查与其主系统中该实体属性是否在名字、性质、精度、范围等方面一致，尤其关键字是否相同，防止冲突。另外，对非主系统的同名实体做出标志，将来在转化为关系模型时，只转换其中主要的一个。

四、逻辑结构设计

1．关系数据模型

逻辑结构设计的任务是把概念模型，例如E-R图转换成所选用的具体的DBMS所支持的数据模型。此处我们主要介绍将E－R图转换为关系数据模型的方法，以及设计视图（子模式）的方法。在一些应用中，利用视图实现表与表的连接，将可简化程序设计。逻辑结构的设计与算法密切相关，在设计逻辑结构的同时，还要考虑应用程序的设计。一般说来，两个实体间如是一对一联系，在转化为关系模型时，可直接将两实体数据合为一表，属性为原两个实体的全部属性组合。例如单位与单位的法人之间是一对一关系可以用一个表描述，属性包括原来“单位”实体的全部属性和法人实体的全部属性。其优点是涉及单位与法人间相互关系的查询时无须联接，既简单便于维护，运行效率也高。但是也有些表合为一表后可能因为表中每条记录太长而影响效率。例如职工与职工爱人两表，由于许多职工的职工爱人一栏空缺，两表相连为一表后会产生大量空字段，而且两表相连后，记录太长，表的规模太大，效率肯定降低。加上在正常应用中，职工与家庭相关的查询统计毕竟不多，因而我们设计时也常按1：N方式设计成两个独立的表。

对于一对多联系的两个实体，分别建立两个表，在多方表中增加一方表中的关键字属性，作为其外码，按照参照完整性要求，外码要么为空值，要么必须是一方主码中的一个值。

对于多对多联系的两个实体要建立联系实体，其属性由互相联系的各实体的关键字组

成。例如学生和课程间的联系定为多对多联系，因而应建立联系表：“成绩”，其属性包括学生和课程两表中关键字“学号”、“课程号”，此外包括“成绩”自身的属性“分数”。一般讲每建立一个表，在应用系统中都需要建立相应维护程序，设计复杂度加大，工作量加大。因此在一些特殊情况下，我们总设法减少“表”的数量，采用特殊处理方法。例如设备和部门之间是多对多关系，一台设备和保管部门、使用部门、所属部门等多部门相关，而一个部门也总是和许多设备相关。双方如建立多对多联系表，其属性应包括设备号、单位代码及关系类型（保管、使用、所属等）这样增加了一个表，应用程序如涉及显示每台设备由谁维护，由谁使用，属于谁。设计起来反而麻烦，不如考虑另一种处理方式：在设备表中同时设三个属性：保管部门名，使用部门名，所属部门名，就将设备和单位的联系变成三个一对多联系，减少了一个表，程序设计反而更加方便。

又例如，教师和科研项目之间是多对多联系，在应用中常常要回答一个老师参与了哪些科研项目，是哪些项目的项目负责人，又要回答每个项目有哪些老师参加。我们在处理时，在科研项目中设置两个属性：课题负责人，课题组成员。在数据录入课题组成员时，人名之间以“，”分隔，其中允许一栏填多人。这种做法不符合关系的基本要求，但是可少建一个表，在回答前一个问题时，在VFP中只需利用包含运算符（＄）就能查到结果，在回答第二个问题时，则直接取“课题组成员”的值。由于应用问题简单，这样设计能满足要求，还使程序大大简化。

从以上分析可见，我们进行逻辑转换时常遵循一般规律，但也常常根据应用问题实际需要做一些特殊设计使问题简化，并不一定要追求高规范化，问题简化将使设计效率提高，使设计正确率提高，更方便用户使用，而这才应是我们所要达到的目标。

2．代码设计

在设计关系模型时，为了将来查询统计的需要，也有些是为了标准化的需要，对于某些属性要采用代码。例如，关于政治面貌的输入，对于是“党员”的情况就可能有不同的输入方法：“党员”，“中共党员”，“共产党员”等。而如果不统一，将来统计党员人数时，如你的判断条件是政治面貌＝“党员”，那么在政治面貌栏中，后两种填法的记录都将不被统计进入，而形成数据错误。为此常建立代码表，在数据表中以代码存放该属性的值，将保证无二义性。也可直接按汉字内容存储，但在录入界面中，要求显示代码表，并只允许用户从中选取值录入，这样可保证该数据准确可靠，同时还方便了用户录入操作。

又例如设备，在应用中要求有按年份、按使用部门、按经费来源、按使用方向等不同要求分组统计设备的台数、金额等数据，为此我们设计了院内编码，分别由表示年份、使用部门经费来源及使用类型的代码加上顺序号连接成12位长度的字符串，在VFP中可以利用SUBSTR（）函数从中取不同部分的字符串作为分组依据进行查询统计。这样的代码可以是关键字，也可以是为查询或统计应用需要而设计的属性。

关于应用程序结构设计，我们将在7．3节讨论。

五、数据库物理设计

对一个给定的逻辑数据模型求取与应用需要相适应的物理结构的过程称为数据库物理设计。这种物理结构主要指数据库在物理设备上的存储结构和存取方法。对于关系数据库系统，数据的存储结构与存取方法由DBMS决定并自动实现，我们物理设计主要考虑的是在网络环境下数据库的分布及索引结构。

在现代网络环境支持下，数据库共享范围已超越地域，一个管理系统中的数据库将可能有多个，且不一定存在于一台服务器或一台主机中，在设计时我们需考虑数据怎样分布才能最好地满足应用需求，主要要考虑怎样提高工作效率，防止冲突及保证数据安全。

1．两层C/S结构

由服务器、客户机在局部范围内建立局域网，数据库设置在服务器中，客户机中可存放其备份或临时表，就构成所谓两层C/S结构，如图7．6所示。

图7．6 C/S结构图

服务器中数据被众多客户机程序所共享，它们可以同时读或写服务器中的数据，如有多台客户机中程序对同一数据做读写操作，就可能发生冲突。这一问题我们已在并发控制中作了说明。在设计时，对数据可能有如下不同处理形式。

．在处理时，客户机先向服务器索取数据，然后释放数据库，在客户机端处理数据，最后将结果送回服务器。这种处理方式对服务器、通信线路利用效率较高，但要注意防止并发操作错误。

．在处理时，客户机接受用户要求，并发给服务器，在服务器端处理，最后将结果传回客户机显示或打印。这种处理方式网络通信量较小、能防止并发操作错误，但服务器的CPU 特别繁忙，反应速度较低，且容易出现死锁或活锁。

2．三层C/S结构（B/S结构）

在Internet网络支持下，系统可更大规模扩大，出现了三层客户／服务器体系结构，即Browser/server模式，其拓扑结构如图7．7所示。

图7.7 三层C/S网络结构

这种结构使系统从封闭的集中式主机向开放的与平台无关的环境过渡，服务器端可以不只一台主机，可采用主机的群集技术构成，客户端程序极大简化。在客户端借助Web游览器可以处理简单的客户端处理请求，显示用户界面及服务器端运行结果，Web服务器负责接收远程或本地的数据查询请求，然后运行服务器脚本，借助于中间件把数据通过ODBC 发送到数据库服务器上以获取相关数据，再把结果数据传回客户的Browser。数据库服务器端负责管理数据库，处理数据更新及完成查询要求，运行存储过程。这种方式使应用面极大扩展，而安全问题也变得更加令人重视。

我们应根据需要选择合适的存储方式。例如在系管理系统中，教师基本情况中的某些内容及科研情况、设备情况、日程表等部分数据，只允许少数具有特权的人查询和修改，一般不提供给其他人，我们将它们放在系内局域网服务器上，部分内容甚至放在单机上。对于教师教学进度计划、教学大纲等在系内共享要求较高的数据，我们存放在系内局域网服务器上，在各客户机中存放备份或提供视图以实现对服务器的访问。关于学生成绩信息、在学分制环境中学生选课及相关资料的数据，我们将之同时存放在本地局域网服务器中及远程服务器数据库中，允许学生远程访问。本地数据库是系统基本数据库，远程服务器中存放的是一个发布数据库。发布数据库的内容应随基本数据库内容改变而修改，注意和基本数据库保持一致。

为了提高存取效率，关系数据库都提供索引结构，索引使查询及与查询有关的修改、删除等操作效率提高，但插入和某些修改操作变得困难。

关系数据库系统中可以用静态或动态两种方式创建索引，静态索引指编程人员事先建立相应索引，在应用程序中打开它之后再对表操作，这种操作效率较高。动态索引指在程序中建立索引并使之成为主索引，这种方式较灵活，但在多用户共享并且录改操作比较频繁时会使处理速度变慢。

数据库表结构设计参考

数据库表结构设计参考

表名外部单位表（DeptOut） 列名数据类型（精度范围）空/非空约束条件 外部单位ID 变长字符串(50) N 主键 类型变长字符串(50) N 单位名称变长字符串(255) N 单位简称变长字符串(50) 单位全称变长字符串(255) 交换类型变长字符串(50) N 交换、市机、直送、邮局单位邮编变长字符串(6) 单位标识(英文) 变长字符串(50) 排序号整型(4) 交换号变长字符串(50) 单位领导变长字符串(50) 单位电话变长字符串(50) 所属城市变长字符串(50) 单位地址变长字符串(255) 备注变长字符串(255) 补充说明该表记录数约3000条左右，一般不做修改。初始化记录。 表名外部单位子表（DeptOutSub） 列名数据类型（精度范围）空/非空约束条件 外部子单位ID 变长字符串(50) N 父ID 变长字符串(50) N 外键 单位名称变长字符串(255) N 单位编码变长字符串(50) 补充说明该表记录数一般很少 表名内部单位表（DeptIn） 列名数据类型（精度范围）空/非空约束条件 内部单位ID 变长字符串(50) N 主键 类型变长字符串(50) N 单位名称变长字符串(255) N 单位简称变长字符串(50) 单位全称变长字符串(255) 工作职责 排序号整型(4) 单位领导变长字符串(50) 单位电话（分机）变长字符串(50) 备注变长字符串(255)

补充说明该表记录数较小（100条以内），一般不做修改。维护一次后很少修改 表名内部单位子表（DeptInSub） 列名数据类型（精度范围）空/非空约束条件内部子单位ID 变长字符串(50) N 父ID 变长字符串(50) N 外键 单位名称变长字符串(255) N 单位编码变长字符串(50) 单位类型变长字符串(50) 领导、部门 排序号Int 补充说明该表记录数一般很少 表名省、直辖市表（Province） 列名数据类型（精度范围）空/非空约束条件ID 变长字符串(50) N 名称变长字符串(50) N 外键 投递号变长字符串(255) N 补充说明该表记录数固定 表名急件电话语音记录表（TelCall） 列名数据类型（精度范围）空/非空约束条件ID 变长字符串(50) N 发送部门变长字符串(50) N 接收部门变长字符串(50) N 拨打电话号码变长字符串(50) 拨打内容变长字符串(50) 呼叫次数Int 呼叫时间Datetime 补充说明该表对应功能不完善，最后考虑此表 表名摄像头图像记录表（ScreenShot） 列名数据类型（精度范围）空/非空约束条件ID 变长字符串(50) N 拍照时间Datetime N 取件人所属部门变长字符串(50) N 取件人用户名变长字符串(50) 取件人卡号变长字符串(50) 图片文件BLOB/Image

学生管理系统数据库设计文档范文

学生管理系统数据库设计文档

学生选课系统 数据库表结构设计（09软工第八组） 12月

目录 1.1. 管理员信息表.......................................... 错误!未定义书签。 1.2. 新闻信息表 (3) 1.3. 教学楼信息表 (3) 1.4. 专业信息表 (4) 1.5. 课程信息表 (4) 1.6. 选课时间信息表 (4) 1.7. 新闻类别信息表 (5) 1.8. 通知信息表 (5) 1.9. 教室信息表 (5) 1.10.学生专业信息表 5 1.11.学生信息表 错误!未定义书签。 1.1 2.学生课程信息表 错误!未定义书签。 1.13.教师课程信息表 错误!未定义书签。 1.14.教师信息表

7 1.15.教师所在院系信息表 (7) 1.16.学院信息表 7 2.1. 各个表之间的关系 (8) 1.1. 管理员信息表 create table Admin （ AdminId (PK,bigint, not null) /*管理员ID号*/ AdminKey (nvarchar(50),not null) /*管理员密码 */ AdminPhone (nvarchar(50), null) /*管理员电话号码 */ AdminAge (int,null) /*管理员年龄 */ AdminEmail (nvarchar(50), null) /*管理员邮箱 */ AdminName (nvarchar(50), null) /*管理员名字 */ ） 索引： 对AdminId唯一索引

概念结构设计和逻辑结构设计

概念结构设计和逻辑结构设计 一.系统概述 本系统通过调查从事医药产品的零售，批发等工作的企业，根据其具体情况设计医药销售管理系统。医药管理系统的设计和制作需要建立在调查的数据基础上，系统完成后预期希望实现药品基本信息的处理，辅助个部门工作人员工作并记录一些信息，一便于药品的销售和管理。通过此系统的功能，从事药品零售和批发等部门可以实现一些功能，如：基础信息管理，进货管理，库房管理，销售管理，财务统计，系统维护等。 二．概念结构设计 1.员工属性 2.药品属性 3.客户属性 4.供应商属性 5.医药销售管理系统E--R 图 三．逻辑结构设计 该设计概念以概念结构设计中的E--R 图为主要依据，设计出相关的整体逻辑结构，具体关系模型如下：（加下划线的表示为主码） 药品信息（药品编号，药品名称，药品类别，规格，售价，进价，有效期，生产日期，产地，备注） 供应商信息（供应商编号，供应商名称，负责人，） 员工 姓名 家庭地址 E-maill 电话 员工 编号 年龄 帐号

四．系统各功能模块如何现（数据流实图）；1.基本信息管理子系统 基本信息管理子系统 药品信息员工信息客户信息供应商信息2.库存管理子系统 库存管理子系 统 库存查询库存信息出入库登记库存报表3.销售管理子系统 销售管理 销售登记销售退货销售查询 4.信息预警子系统 信息预警 报废预警库存预警 5.财务统计子系统 财务统计 统计销售额打印报表 6.系统管理子系统

系统管理 权限管理修改密码系统帮助 五．数据库设计（E-R图，数据库表结构） 1.药品基本信息表 列名字段数据类型可否为空说明药品编号 药品名称 药品类别 规格 进价 有效期 生产日期 售价 产地 备注 2.员工基本信息表 列名字段数据类型可否为空说明员工编号 性别 身份证号 员工年龄

数据库设计各阶段

1.数据库应用系统的设计步骤 按规范设计的方法可将数据库设计分为以下六个阶段 （1）需求分析; （2）概念结构设计; （3）逻辑结构设计; （4）数据库物理设计; （5）数据库实施; （6）数据库运行和维护。 2.需求分析 需求收集和分析是数据库应用系统设计的第一阶段。明确地把它作为数据库应用系统设计的第一步是十分重要的。这一阶段收集到的基础数据和一组数据流图（Data Flow Diaˉgram———DFD）是下一步设计概念结构的基础。概念结构对整个数据库设计具有深刻影响。而要设计好概念结构，就必须在需求分析阶段用系统的观点来考虑问题、收集和分析数据及其处理。如何分析和表达用户需求呢？在众多的分析方法中，结构化分析（Structured Analysis，简称SA方法）是一个简单实用的方法。SA方法用自顶向下、逐层分解的方式分析系统。用数据流图，数据字典描述系统。然后把一个处理功能的具体内容分解为若干子功能，每个子功能继续分解，直到把系统的工作过程表达清楚为止。在处理功能逐步分解的同时，它们所用的数据也逐级分解。形成若干层次的数据流图。数据流图表达了数据和处理过程的关系。处理过程的处理逻辑常常用判定表或判定树来描述。数据字典（Data Dictionary，简称DD）则是对系统中数据的详尽描述，是各类数据属性的清单。对数据库应用系统设计来讲，数据字典是进行详细的数据收集和数据分析所获得的主要结果。数据字典是各类数据描述的集合，它通常包括以下5个部分： （1）数据项，是数据最小单位。 （2）数据结构，是若干数据项有意义的集合。 （3）数据流，可以是数据项，也可以是数据结构。表示某一处理过程的输入输出。 （4）数据存储，处理过程中存取的数据。常常是手工凭证、手工文档或计算机文件。 （5）处理过程。

学生成绩管理系统数据库设计文档 - (全)

“学生成绩管理”数据库设计文档 0、前言（一些必要的说明。） 0.1 数据库说明 数据库名：PXSCJ 逻辑名称：学生成绩数据库 数据文件：PXSCJ.mdf 日志文件：PXSCJ_Log 登录名：admin,密码：123456 0.2表命名说明 Cjb:成绩表，保存选课信息 Cxb:查询表，记录boolean值对应信息，1代表男，0代表女。Kcb:课程表。 Tjb:统计表，统计成绩段分布。 Xsb:学生表。 Yhb:用户表，保存系统用户信息。 Jsb: 教师表。 Skb:授课表，记录授课信息。 0.3 系统功能模块图

1、需求分析阶段 说明：学生成绩管理系统需要实现以下功能：一个学生可以选修多门课程，一门课程可以由多个学生选修，学生选修一门课会有一个成绩。一个教师可以教授多个班级，一个教师也可以教授多门课程，一个班级有多个学生，一门课程也可以由多个老师来上，一个老师给一个班级上一门课有确定的时间和地点。不同的用户根据身份不同拥有不同的权限。 （1）数据流图 老师----成绩管理，学生信息管理，权限管理---学生成绩管理系统—成绩查询--学生（要求：用visio实现第一层数据流图，第二层数据流图，第三层数据流图）p121 第一层数据流图 第二层数据流图 第三层数据流图（略） （2）数据字典 （每个实体的详细说明）

2、概念设计阶段 （1）分ER图 （两个分ER图，1）学生和课程，2）教师，课程，班级）

（2） 总ER 图 （由分ER 图画出总ER 图） 3、 逻辑设计阶段 （1） 表关系图 （看是否可以画出） （2） 表结构图 Xsb 结构

数据库设计的基本步骤

数据库设计的基本步骤 一、数据库设计的生存期 按照规范设计的方法，考虑到数据库及其应用系统开发的全过程，将数据库 设计分为六个阶段。如下图。 ① 需求分析 需求收集和分析, 需求。 ② 概念结构设计 对需求进行综合、归纳与抽象，形成一个独立于具体 DBMS 的概念模型（用 E-R 图表示）。 ③ 逻辑结构设计 将概念结构转换为某个DBMS 所支持的数据模型（例如关系模型），并对其 进行优化。 ④ 物理结构设计 为逻辑数据模型选取一个最适合应用环境的物理结构 （包括存储结构和存取 方法）。 ⑤ 数据库实施 需求A 祈断段 T 1 概念设计阶段 i 逻辑 q 丰计阶段 1 物理. 1 殳计阶段 j 数据E L 支实施阶段 数据库运荷? 维护阶段 得到用数据字典描述的数据需求，用数据流图描述的处理

运用DBMS 提供的数据语言（例如 SQL ）及其宿主语言（例如C）,根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。 ⑥数据库运行和维护 数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。 说明：设计一个完善的数据库应用系统是不可能一蹴而就的，它往往是上述 六个阶段的不断反复。 二、数据库设计阶段的内容 设计步骤既是数据库设计的过程，也包括了数据库应用系统的设计过程。下面针对各阶段的设计内容给出各阶段的设计描述。如下图。 阶段 濮块结构） 三、数据库设计阶段的模式 数据库结构设计的不同阶段形成数据库的各级模式，如下图 需求数据字睦、全系统中数据项、 分析數据證、数据存储的描述 数1E流图和判定我（利宦 闕）、数据字典中处理过程的 描述 设计 概念模型〔E?兄图） 模块设计 IPO表 编写模武装入 数JE 实施数揭库试 运行阶段 Create … L o豆恋■?. 程序编码 编译联结 测试 Tlain () * ■ A if???then ■■ i HUl 数据宇典 系窥说朋书包括： ①新系统要求、 方案和概图 ②反映新系统信息 流的数据流图 方法选择物理 存取路径建立设计

数据库概念结构设计和逻辑结构设计举例

数据库概念结构设计和逻辑结构设计举例 某超市公司要设计一个数据库系统来管理公司的业务信息，该超市公司的业务管理大致可分为三部分： 1、超市公司的仓库管理业务； 2、连锁商店的商品销售业务； 3、连锁商店的集团购买业务。 业务管理规则如下： （1）该超市公司有若干仓库，若干连锁商店，供应若干商品； （2）超市公司的业务员负责与供应商联系商品进货业务； （3）购进的商品按类存放在仓库中，每个仓库有若干保管员； （4）每个连锁商店有一个经理和若干收银员，每个收银员只在一个连锁商店工作。 （5）每个商品编号只有一个商品名称，但不同商品编号可以有相同的商品名称，每种商品可有多种销售价格； （6）连锁商店实行会员制，通过会员卡收集顾客信息。顾客办理会员卡后，可享受一定的优惠； （7）连锁商店要处理客户和销售员送来的集团购买大宗商品的订单，并根据库存情况交出货物同时开出发票，收到付款后应进行收款处理； （8）连锁商店对大宗订货给予优惠，每种商品规定了不同订货数量和折扣。

一、设计局部ER模式 1、仓库管理子系统分ER图 根据管理规则（2），（3），与仓库管理子系统有关的实体包括：业务员、商品、供应商、仓库、职工。 因为每个业务员都可以与若干家供应商联系多项商品或进货业务，所以在业务员、商品、供应商之间存在一个三元的多对多的联系。仓库与商品之间存在多对多，仓库与职工之间存在一对多的联系。

2、根据规则（1）（4）（5）（6），与商品销售业务有关的实体有商店、商品、收银员、顾客。 因为每个收银员都要与多个顾客购买的多种商品发生业务联系，所以在收银员、商品与顾客之间存在一个多对多的联系。商品与商存在多对多的联系，商店与收银员之间存在一对多的联系。

网店信息及销售管理系统数据库设计文档

数据库设计文档目录 1. 引言 1.1 编写目的 1.3 定义 1.4 参考资料 2. 外部设计 2.1目标 .................................................. .5 2.2标识符和状态 .......................................... .5 2.3约定 .................................................. .5 2.4运行环境 .............................................. .5 2.5专门指导 .............................................. .6 3. 数据流图 .......................................... 6 4. 数据词典 .............................................. 10 5. 功能概述 5.1系统功能概述 .......................................... .11 5.2系统功能模块 ............................................. .13 6. 结构设计 6.1概念结构设计 ............................................. .16 6.2逻辑结构设计 ............................................. .17 6.2.1表的结构 .......................................... ..17 6.2.2 表的关系图 ........................................ .22 7. .................................................................................................................... 其 1.2 背景 (4) .4 .4 .4

进销存数据库表结构设计

1.帐类表（KIND） 无索引 序号中文名称英文名称类型备注 1 帐类编号K_SERIAL byte 2 帐类名称K_NAME text*10 本表系统自动建立，共划分为15种帐类,不可增删 帐类编号帐类名称备注 0 上期结存进货，不参加进货统计 1 购入进货，购入时必需输入供货单位名称 2 自制进货 3 投资转入进货 4 盘盈进货 5 领料出库，领料必需输入领料部门名称 6 调拨出库 7 报损出库 8 盘亏出库 9 退库对低值易耗品，在用品退为在用库存 10 直接报废对于低值易耗品，在用品转报废 11 领用对于低值易耗品，在用库存转在用 12 调拨对于低值易耗品，在用库存减少 13 报废对于低值易耗品，在用库存报废 14 直进直出进出库，购入与领料对库存无影响 2.物品表（GOODS） 序号索引名称索引域唯一? 主索引? 1 G_CODING +G_CODING Y N 2 G_SERIAL +G_SERIAL Y Y 序号中文名称英文名称类型备注 1 物品内部编号G_SERIAL INT->long 系统内部唯一标识该物品 2 物品编号G_CODING TEXT * 10 用户使用此编号访问物品 &3 物品名称G_NAME TEXT*40 非空 &4 物品单位G_UNIT TEXT*8 非空 &5 物品规格G_STATE TEXT*20

6 物品类别G_CLASS INT 取自表CLASS 7 备注G_REMARKS MEMO 8 最小库存量G_MIN CURRENCY 为零，即无最小库存 9 最大库存量G_MAX CURRENCY 为零，即无最大库存 10 库存数量G_QUANT CURRENCY 控制出库数量 11 虚拟库存数量G_VQUANT CURRENCY 出库时用 12 库存金额G_AMOUNT CURRENCY 3.类别表（CLASS） 序号索引名称索引域唯一? 主索引? 1 C_CODING +C_CODING Y N 2 C_SERIAL +C_SERIAL Y Y 序号中文名称英文名称类型备注 1 类别内部序号C_SERIAL INT 系统内部唯一标识该物品 2 类别编号C_CODING TEXT *10 用户使用该编号访问类别信息 3 类别名称C_NAME TEXT*20 非空 4 出库类型C_KIND BYTE 1.移动平均 2..先进先出 3.后进先出 4.实际计价 *5.月末平均 5 备注C_REMARKS MEMO *6 底标志C_BOTTOM BOOLEAN *7 类别级别C_LEVEL BYTE 4.供货单位、使用部门(DEPART) 序号索引名称索引域唯一? 主索引? 1 D_CODING +D_CODING Y N 2 D_SERIAL +D_SERIAL Y Y 序号中文名称英文名称类型备注 1 内部序号D_SERIAL INT 系统内部唯一标识该部门 >0 供货单位 =0 库房 <0 使用部门 2 单位编号D_CODING TEXT*10

毕业设计管理系统数据库设计文档

访问统计 数据库设计文档 编写： 编写日期： 审核日期： 批准日期：

变更记录 签字确认

目录 1.1预期的读者 (4) 1.2数据库 (4) 1.2.1数据库类型及版本 (4) 1.2.2数据库命名规范 (4) 1.3目的和作用 (5) 2数据库设计 (5) 2.1物理结构设计 (5) 2.2数据库表结构设计 (5) 2.2.1访问统计......................................................................... 错误！未定义书签。

引言 预期的读者 1）项目经理 2）客户项目经理 3）系统开发人员 4）系统测试人员 数据库 数据库类型及版本 数据库类型：MySQL 版本：5.5.15 数据库命名规范 1、数据库表 根据表所属的子系统/模块，命名方式为： 数据库表名 = 子系统_模块 2、表字段 概念模型中，每个数据库中为每个表定义唯一的缩写 字段名为多个单词的组合时，第一个单词首字母小写，其他单词的首字母大写； 字段名为多个单词的组合时，若单词过长，截取3-5个字母 3、索引 索引名 = Idx + _ + 表缩写 + 相关字段/索引含义 4、关联 关联指数据库表之间的外键关系 关联名 = rl + _ + 主表 + 从表 (首字母大写） 5、存储过程

存储过程名 = proc + _ + 存储过程含义(首字母大写） 目的和作用 将数据分析的结果进一步整理，形成最终的计算机模型，以便开发人员建立物理数据库。 数据库设计 物理结构设计 数据库表结构设计 毕业设计管理系统 用户表（user）

数据库课后题答案 第7章 数据库设计

第7章数据库设计 1．试述数据库设计过程。 答：这里只概要列出数据库设计过程的六个阶段：( l ）需求分析；( 2 ）概念结构设计；( 3 ）逻辑结构设计；( 4 ）数据库物理设计；( 5 ）数据库实施；( 6 ）数据库运行和维护。这是一个完整的实际数据库及其应用系统的设计过程。不仅包括设计数据库本身，还包括数据库的实施、运行和维护。设计一个完善的数据库应用系统往往是上述六个阶段的不断反复。 2 ．试述数据库设计过程各个阶段上的设计描述。 答：各阶段的设计要点如下：( l ）需求分析：准确了解与分析用户需求（包括数据与处理）。( 2 ）概念结构设计：通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS 的概念模型。( 3 ）逻辑结构设计：将概念结构转换为某个DBMS 所支持的数据模型，并对其进行优化。( 4 ）数据库物理设计：为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。( 5 ）数据库实施：设计人员运用DBMS 提供的数据语言、工具及宿主语言，根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。( 6 ）数据库运行和维护：在数据库系统运行过程中对其进行评价、调整与修改。 3 ．试述数据库设计过程中结构设计部分形成的数据库模式。 答：数据库结构设计的不同阶段形成数据库的各级模式，即：( l ）在概念设计阶段形成独立于机器特点，独立于各个DBMS 产品的概念模式，在本篇中就是 E 一R 图；( 2 ）在逻辑设计阶段将 E 一R 图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式，然后在基本表的基础上再建立必要的视图( Vi 娜），形成数据的外模式；( 3 ）在物理设计阶段，根据DBMS 特点和处理的需要，进行物理存储安排，建立索引，形成数据库内模式。 4 ．试述数据库设计的特点。 答：数据库设计既是一项涉及多学科的综合性技术又是一项庞大的工程项目。其主要特点有：( l ）数据库建设是硬件、软件和干件（技术与管理的界面）的结合。( 2 ）从软件设计的技术角度看，数据库设计应该和应用系统设计相结合，也就是说，整个设计过程中要把结构（数据）设计和行为（处理）设计密切结合起来。 5 ．需求分析阶段的设计目标是什么？调查的内容是什么？ 答：需求分析阶段的设计目标是通过详细调查现实世界要处理的对象（组织、部门、企业等），充分了解原系统（手工系统或计算机系统）工作概况，明确用户的各种需求，然后在此基础上确定新系统的功能。调查的内容是“数据’夕和“处理”，即获得用户对数据库的如下要求：( l ）信息要求，指用户需要从数据库中获得信息的内容与性质，由信息要求可以导出数据要求，即在数据库中需要存储哪些数据；( 2 ）处理要求，指用户要完成什么处理功能，对处理的响应时间有什么要求，处理方式是批处理还是联机处理；( 3 ）安全性与完整性要求。 6 ．数据字典的内容和作用是什么？ 答：数据字典是系统中各类数据描述的集合。数据字典的内容通常包括：( l ）数据项；( 2 ）数据结构；( 3 ）数据流；( 4 ）数据存储；( 5 ）处理过程五个部分。其中数据项是数

数据库结构设计

一、数据库结构设计步骤 二、需求分析 三、概念结构设计 四、逻辑结构设计 五、数据库物理设计 数据库结构设计 一、数据库结构设计步骤 一般可将数据库结构设计分为四个阶段，即需求分析、概念结构设计、逻辑结构设计和物理设计。 下面各节分别介绍各阶段设计内容和具体方法。 二、需求分析 需求分析的任务是具体了解应用环境，了解与分析用户对数据和数据处理的需求，对应用系统的性能的要求，提出新系统的目标，为第二阶段、第三阶段的设计奠定基础。一般需求分析的操作步骤如下所述。 1．了解组织、人员的构成 子系统的划分常常以现有组织系统为基础，再进行整合，而新系统首先必须达到的目的是尽可能地完成当前系统中有关信息方面的工作，在原有系统中，信息处理总是由具体人来实施的。我们要了解组织结构情况、相互之间信息沟通关系、数据（包括各种报告、报表、凭证、单据）往来联系情况。 具体弄清各个数据的名称，产生的时间与传递所需时间与周期，数据量的大小，所涉及（传送）的范围，使用数据的权限要求，数据处理过程中容易发生的问题及其影响，各个部门所希望获得的数据的情况等。 然后了解每个人对每一具体数据处理的过程，基本数据元素来源于哪些地方、获取的途径、处理的要求、数据的用途，进而弄清数据的构成、数据元素的类型、性质、算法、取值范围、相互关系。 在上述调查基础上，首先画出组织机构及工作职能图。我们以一个学校的基层单位——某大学一个系的管理为例来简要说明。 系的组织机构及工作职能如图7.1所示。

图7．1 系管理体系结构图 作为管理层经常需要的信息和工作有： ．查询老师个人基本情况及打印相应内容 ．查询与统计科研项目情况及相关报表 ．查询与统计论文著作情况及相关报表 ．上级部门及其他部门来文管理与查询（要求能全文检索） ．系部发文管理 ．任务下达、检查及管理 ．信件、通知的收发及管理 ．日程安排调度及管理 ．设备仪器计划及管理 ．设备入库与库存情况管理与查询 ．设备借还领用管理及相应报表 ．耗材计划与领发管理及相应统计报表 ．图书管理及借还情况查询 ．学生毕业设计文档管理 ．专业与班组编制与查询 ．教学文档管理及查询（安排与检查，包括课表、考试日程安排、监考安排等）．学生成绩管理与查询和统计 ．教师、学生、实验室课表管理及查询 ．学生基本情况管理与查询（包括社会活动、奖惩、家庭情况及学校校友管理）

新闻管理系统数据库设计说明书

新闻管理系统数据库设计说明书 目录 1引言 (1) 1.1编写目的 (1) 1.2背景 (1) 1.3定义 (1) 1.4参考资料 (1) 2外部设计 (2) 2.1标志符和状态 (2) 2.2使用它的程序 (2) 2.3约定 (2) 2.4专门指导 (5) 2.5支持软件 (5) 3结构设计 (5) 3.1概念结构设计 (5) 3.2逻辑结构设计 (11) 3.3物理结构设计 (11) 4运用设计 (15) 4.1数据字典设计 (15) 4.2安全保密设计 (16)

1引言 1.1编写目的 本文档为新闻管理系统的数据库设计报告，为新闻管理系统的设计主要依据，主要针对新闻管理系统的概要设计和详细设计人员，作为项目验收的主要依据。 1.2背景 （1）待开发的软件系统名称：新闻管理系统 （2）本项目的任务提出者：team小分队 （3）开发者：team小分队 （4）用户：社会各阶级人群，主要人群大学生 1.3定义 （1）可靠性（Reliable），软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。 （2）安全性（Secure），软件系统所承担的交易的商业价值非常高，系统的安全性非常重要。（3）可伸缩性（SCAlable），软件必须能够在用户的使用率、用户的数目增长很快的情况下，保持合理的性能。只有这样，才能适应用户市场拓张的可能。 （4）可定制化（CuSTomizable），同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。 （5）可扩展性（Extensible），在新技术出现的时候，一个软件系统应当导入新技术，从而对现有系统进行功能和性能的拓展。 （6）可维护性（MAIntainable），软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有的系统中去。一个易于维护的系统可以有效地降低技术支持的花费。 （7）客户体验（Customer Experience），软件系统必须易于使用。 （8）市场时机（Time to Market），软件用户要面临同业竞争，软件提供商也要面临同业竞争，以最快的速度争夺市场先机非常重要。 1.4参考资料 《软件工程》

7.3 概念结构设计(S)

7.3 概念结构设计 将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计。它是整个数据库设计的关键。(概念结构是对用户需求的客观反映，不涉及到软硬件环境，也不能直接在数据库管理系统DBMS上实现，是现实世界与机器世界的中介。这一阶段所产生的工作结果一般表现为E-R图的形式，它不仅能够充分反映客观世界，而且易于非计算机人员理解，易于向关系、网状、层次等各种数据模型转换。) 7.3.1 概念结构 在需求分析阶段所得到的应用需求应该首先抽象为信息世界的结构，才能更好地、更准确地用某一DBMS实现这些需求。 概念结构的主要特点是: (1) 能真实、充分地反映现实世界，包括事物和事物之间的联系，能满足用户对数据的处理要求。是对现实世界的一个真实模型。 (2) 易于理解，从而可以用它和不熟悉计算机的用户交换意见，用户的积极参与是数据库的设计成功的关键。 (3) 易于更改，当应用环境和应用要求改变时，容易对概念模型修改和扩充。 (4) 易于向关系、网状、层次等各种数据模型转换。 概念结构是各种数据模型的共同基础，它比数据模型更独立于机器、更抽象，从而更加稳定。 描述概念模型的有力工具是E-R模型。有关E-R模型的基本概念已在第一章介绍。下面将用E-R模型来描述概念结构。 7.3.2 概念结构设计的方法与步骤 设计概念结构通常有四类方法: ·自顶向下。即首先定义全局概念结构的框架，然后逐步细化，如图7.7(a)所示。 ·自底向上。即首先定义各局部应用的概念结构，然后将它们集成起来，得到全局概念结构，如图7.7（b）所示。 ·逐步扩张。首先定义最重要的核心概念结构，然后向外扩充，以滚雪球的方式逐步生成其他概念结构，直至总体概念结构，如图7.7(c)所示。 ·混合策略。即将自顶向下和自底向上相结合，用自顶向下策略设计一个全局概念结构的框架，以它为骨架集成由自底向上策略中设计的各局部概念结构。 其中最经常采用的策略是自底向上方法。即自顶向下地进行需求分析，然后再自底向上地设计概念结构。如图7.8所示。这里只介绍自底向上设计概念结构的方法。它通常分为两步:第1步是抽象数据并设计局部视图，第2步是集成局部视图，得到全局的概念结构，如图7.9所示。

数据库表结构设计参考

数据库表结构设计参考． ）表名外部单位表（DeptOut 约束条件非空空数据类型（精度范围） /列名外部单位ID N 变长字符串(50) 主键 N 变长字符串类型 (50)

N 单位名称(255) 变长字符串 (50) 单位简称变长字符变长字符(255)单位全交换类交换、市机、直送、邮变长字符(50)N (6)单位邮变长字符 变长字符(50))单位标英整排序(4) (50)交换变长字符变长字符(50)单位领 变长字符单位电(50) 变长字符所属城(50) 变长字符(255)单位地 备(255) 变长字符 补充说300条左右，一般不做修改。初始化记录该表记录数 表外部单位子表DeptOutSu 数据类型（精度范围列非约束条 变长字符(50)外部子单IDN 外ID变长字符(50)N单位名N变长字符(255) 变长字符单位编(50) 该表记录数一般很补充说 表内部单位表DeptI

数据类型（精度范围非列约束条IDN(50)变长字符主内部单类N变长字符(50) (255)变长字符N单位名 (50)变长字符单位简 变长字符单位全(255) 工作职 排序整(4) 单位领导(50) 变长字符串 (50) 单位电话（分机）变长字符串 (255) 变长字符串备注． 条以内），一般不做修改。维护一次后很少修改补充说明该表记录数较小（100 内部单位子表（DeptInSub）表名 约束条件数据类型（精度范围）空列名/非空 (50) N 变长字符串内部子单位ID 变长字符串(50) 父ID N 外键 (255) 单位名称 N 变长字符变长字符(50)单位编领导、部变长字符(50)单位类 Int 排序 该表记录数一般很补充说 省、直辖市表Provinc表

数据库设计方法

数据库设计方法

数据库设计步骤简述 数据库技术是信息资源的开发、管理和服务的最有效的手段，因此数据库的应用范围越来越广，从小型的单项事物处理系统到大型的信息服务系统大都利用了先进的数据库技术来保持系统数据的整体性、完整性和共享性。 数据库应用软件和其他软件一样，也有它的诞生和消亡。数据库应用软件作为软件，在其生命周期可以看作有三个大的时期：软件定义时期，软件开发时期和软件运行时期。 按照规范化设计方法，从数据库应用系统设计和开发的全过程来考虑，将数据库及其应用软件系统的生命周期的三个时期又可以细分为六个阶段：需求分析、概念结构设计、逻辑结构设计、物理结构设计、实施及运行维护。 一、需求分析 信息需求：指目标系统设计的所有实体、属性、以及实体间的联系等，包括信息的内容和性质，以及由信息需求导出的数据需求。 处理需求：指为得到需要的信息而对数据进行加工处理的要求，包括处理描述，发生的频度、响应时间以及安全保密要求等。进行数据库设计首先必须准确了解与分析用户需求。需求分析是真个设计过程的基础，是最困难、最耗费时间的一步。作为地基的需求分析是否做得充分与准备，决定了在其上构建数据库大厦的速度与质量。需求分析做得不好，甚至会导致整个数据库设计返工重做。 需求任务分析：

需求分析的任务是通过详细调查现实世界要处理的对象（组织、部门、企业等），充分了解原系统（手工系统或计算机系统）工作概况，明确用户的各种需求，然后在此基础上确定新系统的功能。新系统必须充分考虑今后可能的扩充和改变，不能仅仅按当前应用需求来设计数据库。 需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。信息要求是指用户需要从数据库中获得信息的内容与性质。由用户的信息要求可以导出数据要求，即在数据库中需要存储哪些数据。处理要求是指用户要求完成什么处理功能，对处理的响应时间有什么要求，处理方式是批处理还是联机处理。新系统的功能必须能够满足用户的信息要求、处理要求、安全性与完整性要求 需求分析的方法： 通过调查了解了用户需求后，需要进一步分析和表达用户的需求。分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。 二、概念设计 将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计。 概念结构是对现实世界的一种抽象，即对实际的人、物、事和概念进行人为处理，抽取人们关心的共同特性，忽略非本质的细节，并把这些特性用各种概念精确地加以描述。

结构设计中的概念设计与结构措施一

1．概念设计的重要性 概念设计是展现先进设计思想的关键，一个结构工程师的主要任务就是在特定的建筑空间中用整体的概念来完成结构总体方案的设计，并能有意识地处理构件与结构、结构与结构的关系。一般认为，概念设计做得好的结构工程师，随着他的不懈追求，其结构概念将随他的年龄与实践的增长而越来越丰富，设计成果也越来越创新、完善。遗憾的是，随着社会分工的细化，大部分结构工程师只会依赖规范、设计手册、计算机程序做习惯性传统设计，缺乏创新，更不愿（不敢）创新，有的甚至拒绝对新技术、新工艺的采纳（害怕承担创新的责任）。大部分工程师在一体化计算机结构程序设计全面应用的今天，对计算机结果明显不合理、甚至错误而不能及时发现。随着年龄的增长，导致他们在大学学的那些孤立的概念都被逐渐忘却，更谈不上设计成果的不断创新。 强调概念设计的重要，主要还因为现行的结构设计理论与计算理论存在许多缺陷或不可计算性，比如对混凝土结构设计，内力计算是基于弹性理论的计算方法，而截面设计却是基于塑性理论的极限状态设计方法，这一矛盾使计算结果与结构的实际受力状态差之甚远，为了弥补这类计算理论的缺陷，或者实现对实际存在的大量无法计算的结构构件的设计，都需要优秀的概念设计与结构措施来满足结构设计的目的。同时计算机结果的高精度特点，往往给结构设计人员带来对结构工作性能的误解，结构工程师只有加强结构概念的培养，才能比较客观、真实地理解结构的工作性能。 概念设计之所以重要，还在于在方案设计阶段，初步设计过程是不能借助于计算机来实现的。这就需要结构工程师综合运用其掌握的结构概念，选择效果最好、造价最低的结构方案，为此，需要工程师不断地丰富自己的结构概念，深入、深刻了解各类结构的性能，并能有意识地、灵活地运用它们。 2．协同工作与结构体系 协同工作的概念广泛存在于工业产品的设计和制造中，对于任一个工业产品，我们均不希望其在远未达到其设计寿命（负荷、功能）时，它的某些部件（或零件）即出现破坏。对于建筑结构，协同工作的概念即是要求结构内部的各个构件相互配合，共同工作。这不仅要求结构构件在承载能力极限状态能共同受力，协同工作，同时达到极限状态，还要求他们能有共同的耐久寿命。结构的协同工作表现在基础与上部结构的关系上，必须视基础与上部结构为一个有机的整体，不能把两者割裂开来处理。举例而言，对砖混结构，必须依靠圈梁和构造柱将上部结构与基础连接成一个整体，而不能单纯依靠基础自身的刚度来抵御不均匀沉降，所有圈梁和构造柱的设置，都必须围绕这个中心。 对协同工作的理解，还在于当结构受力时，结构中的各个构件能同时达到较高的应力水平。在多高层结构设计时，应尽可能避免短柱，其主要的目的是使同层各柱在相同的水平位移时，能同时达到最大承载能力，但随着建筑物的高度与层数的加大，巨大的竖向和水平荷载使底层柱截面越来越大，从而造成高层建筑的底部数层出现大量短柱，为了避免这种现象的出现，对于大截面柱，可以通过对柱截面开竖槽，使矩形柱成为田形柱，从而增大长细比，避免短柱的出现，这样就能使同层的抗侧力结构在相近的水平位移下，达到最大的水平承载力；而对于梁的跨高比的限制，一般还没有充分认识到。实际上与长短柱混杂的效果一样，长、短梁在同一榀框架中并存，也是极为不利的，短跨梁在水平力的作用下，剪力很

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）读者注册。 （2）读者借书。 （3）读者还书。 （4）图书查询。 1、数据流图 顶层数据流图反映了图书管理系统与外界的接口，但未表明数据的加工要求，需要进一步细化。根据前面图书管理系统功能边界的确定，再对图书管理系统顶层数据流图中的处理功能做进一步分解，可分解为读者注册、借书、还书和查询四个子功能，这样就得到了图书管理系统的第0层数据流图 从图书管理系统第0层数据流图中可以看出，在图书管理的不同业务中，借书、还书、查询这几个处理较为复杂，使用到不同的数据较多，因此有必要对其进行更深层次的分析，即构建这些处理的第1层数据流图。下面的图8-7分别给出了借书、还书、查询子功能的第1层数据流图 2、数据字典 数据项 数据项名称：借书证号 别名：卡号 含义说明：惟一标识一个借书证 类型：字符型 长度：20 …… 数据结构 （1）名称：读者类别 含义说明：定义了一个读者类别的有关信息 组成结构：类别代码+类别名称+可借阅数量+借阅天数+超期罚款额 （2）名称：读者 含义说明：定义了一个读者的有关信息 组成结构：姓名+性别+所在部门+读者类型 （3）名称：图书 含义说明：定义了一本图书的有关信息 组成结构：图书编号+图书名称+作者+出版社+价格 ……

数据流 （1）数据流名称：借书单 含义：读者借书时填写的单据 来源：读者 去向：审核借书 数据流量：250份/天 组成：借书证编号+借阅日期+图书编号 （2）数据流名称：还书单 含义：读者还书时填写的单据 来源：读者 去向：审核还书 数据流量：250份/天 组成：借书证编号+还书日期+图书编号 …… 数据存储 （1）数据存储名称：图书信息表 含义说明：存放图书有关信息 组成结构：图书+库存数量 说明：数量用来说明图书在仓库中的存放数 （2）数据存储名称：读者信息表 含义说明：存放读者的注册信息 组成结构：读者+卡号+卡状态+办卡日期 说明：卡状态是指借书证当前被锁定还是正常使用 （3）数据存储名称：借书记录 含义说明：存放读者的借书、还书信息 组成结构：卡号+书号+借书日期+还书日期 说明：要求能立即查询并修改 …… 处理过程 （1）处理过程名称：审核借书证 输入：借书证 输出：认定合格的借书证 加工逻辑：根据读者信息表和读者借书证，如果借书证在读者信息表中存在并且没有被锁定，那么借书证是有效的借书证，否则是无效的借书证。 …… 二、概念结构设计实例 1．标识图书管理系统中的实体和属性 参照数据字典中对数据存储的描述，可初步确定三个实体的属性为： 读者：｛卡号，姓名，性别，部门，类别、办卡日期，卡状态｝ 读者类别：{类别代码，类别名称，可借阅天数、可借阅数量，超期罚款额}