计算机三级数据库技术备考知识点总结：第1~3章

(黑色为普通内容，蓝色备注，红色重点)

第一章 数据库应用系统开发方法

        数据库系统 DBS 主要提供应用数据的组织、存储、维护、访问等数据管理功能，数据库应用系统 DBAS 不仅为用户提供数据管理功能，还根据具体应用领域业务规则，通过应用程序实现更为复杂的数据处理功能。数据库 DBS 就是基本的操作，在之上根据具体需要调整结构，优化使用体验，就是应用系统 DBAS考虑的。

1.1 数据库应用系统生命周期

       1.1.1 软件工程与软件开发方法  用工程的概念思想来管理软件开发的过程。瀑布模型，项目规划----系统分析----总体设计----详细设计----编码调试与集成调试----运行维护，可以保持较高的效率和前后一致，但是一些需求在前期尚不明确以及具体阶段落实的难度会阻碍该模型的有效性；快速原型模型，快速分析----设计构造原型----运行原型----评价原型----改进原型，后三个不停重复直到满足需求，优点是前期不用做太过详尽的调查，重在中后期用户参与后的反馈；螺旋模型，全过程分成四象限，项目规划-----风险评估----工程实现----用户评估，然后螺旋线增加一轮，持续迭代，综合了前两者的优点 “系统且可修改”，不过就是对开发人员评估风险的经验要求较高。

       1.1.2 DBAS 生命周期模型  由项目规划----需求分析----系统设计----实现与部署----运行与维护五个基本活动组成，这是一个自上而下的纵向顺序，又是快速原型模型和螺旋模型思路的结合。设计阶段细分为概念设计、逻辑设计、物理设计(横向)，另外还有三条设计主线，分别设计与实现 DBAS 中的数据库、数据库事务和应用程序(纵向)。

1.2 规划与分析

       规划与分析有三大部分：

       1.2.1 系统规划与定义  了解客户需求，从数据管理和数据处理的角度确定功能与性能范围。分为任务陈述、确定任务目标、确定系统范围和边界做什么不做什么做到什么程度、确定用户视图不同用户展示不同的内容。

       1.2.2 可行性分析  开发是受限的。经济可行性，技术可行性，操作可行性和开发方案选择。

       1.2.3 项目规划  开始规划实施的具体步骤。确定项目的目标和范围、根据模型分解定义任务，估算各种资源，制定合理的项目计划。

1.3 需求分析

       1.3.1 数据需求分析 

       1.3.2 功能需求分析  核心环节  描述一个系统应当做什么，可以分成数据处理需求分析和业务规则需求分析。

       1.3.3 性能需求分析  描述系统应当做到什么程度，也就是 DBAS 应具有的性能指标。 

       1.3.4 其他需求分析  存储需求分析估计系统需要的数据存储量包括初始及未来，安全性需求分析包括系统应达到的安全控制级别、不同用户的视图访问权限以及安全认证机制，备份和恢复需求分析备份时间和周期、全部数据备份还是部分备份、备份方式的选择。

1.4 系统设计

       1.4.1 概念设计  分为数据库概念模型设计例如ER方法、系统总体设计。

       1.4.2 逻辑设计  包括数据库逻辑结构设计大多数都是基于关系数据模型，应用程序概要设计对整个应用软件进行划分，形成"系统--子系统--模块--子模块"的层次结构，数据库事务概要设计把1.3.2 中分析的各种功能需求设计相应的处理方法/流程。

       1.4.3 物理设计  数据库物理结构设计、数据库事务详细设计、应用程序详细设计。

1.5 实现与部署

1.6 运行管理与维护

 

第二章 需求分析

2.1 需求分析

        2.1.1 需求分析的概念与意义  需求=系统服务或约束的描述。

        2.1.2 需求获取的方法  面谈、实地观察、问卷、查阅资料。

        2.1.3 需求分析过程

2.2 需求分析方法

        2.2.1 需求分析方法概述  结构化分析方法的基本特征视抽象把握本质与分解自上而下大化小。

        2.2.2 DFD需求建模方法  DFD=Data Flow Diagram，成为过程建模和功能建模方法，它的核心就是数据流。先抽象出具体应用的主要业务流程，分析其中每一项的输入即数据来源，经过了什么处理，得到的什么结果，总之以数据流来刻画整个系统。

        DFD 有四种基本元素：数据流、处理、数据存储和外部项源头或者是终点。DFD 图采用自顶向下逐步细化的结构化分析方法，类似于树状的分解，直到每项功能活动都是可以通过一个程序模块来实现。以书中给出的例子"商场业务活动"来看，通常处理这个元素出现的频率不高，很多情况只是数据的流动。

        建模的过程分为几步：明确目标确定系统范围，建立顶层 DFD 图抽象出主要功能，细化输入、处理和结果，构建第一层DFD 分解图进一步分解顶层 DFD 中的基本功能或者元素，开发 DFD 层次结构图继续细化。

         在分解的时候，以“商场业务活动”为例，我们顾客、售货员、采购员等都可以视为外部项，然后最核心的就是储存数据的中心——商场经营管理，他们之间的数据流动补充完整后就形成了顶层的 DFD；之后我们细化分解，在没有处理这种元素的情况下仅考虑分解数据存储的元素，也就是中心——商场经营管理，分解成例如顾客管理、采购与库存管理、销售管理等小的数据存储元素，同时补充齐数据流。至于包含有处理元素的情况，把顶层 DFD 中的处理分解成第一层 DFD 中更具体的处理，再逐层细化。过程中一定要注意数据流不可丢失，要在较高层次上出现的数据流在分解后的较低层次中同样存在。

        2.2.3 其他需求建模方法  

        IDEF0 方法的基本元素是表示功能活动的矩形框，左边输入箭头表示需要的数据，上方控制箭头表示约束，下方进入的机制箭头表示实施的物理手段或者资源，右方的输出箭头表示活动产生的结果及信息。

        同样的也是用自顶向下逐步细化的分解方式，这是与 DFD 的共同点，分解的对象也同样是基本功能。具体的思想可以参考 DFD，只不过只需要分解一种元素即功能活动，想必会更好理解一些。

        2.2.4 DFD 与 IDEF0 的比较

        DFD 中的箭头表示数据的流动方向，而在 IDEF0 中箭头在可以表示数据输入的同时，更多强调的是数据约束，于是 IDEF0 中的箭头有着比 DFD 更丰富的语义，这就使得在大型复杂系统的需求建模更加青睐 IDEF0 模型。

 

第三章 数据库结构设计

3.1 数据库概念设计 

        解决数据需求，把应用领域中要处理的数据结构、定义描述清楚。

        3.1.1 概念设计的任务  

        3.1.2 概念设计的依据及过程  依据就是需求分析阶段的文档。过程包括(1)明确建模目标，(2)定义实体集就是从原始数据中归类出来的“类”，例如顾客类供应商类就是实体集，(3)定义联系联系描述实体集之间的关联关系，联系的实例表示一个练习中的两个实例之间有意义的关联或连接，例如实体集“收银台”和实体集“销售单据”之间存在 1:n 的连接关系，(4)建立信息模型选择ER方法先建立局部信息模型再综合为总体信息模型，(5)确定实体集属性，(6)对信息模型进行集成与优化。

         3.1.3 数据建模方法  

        ER 建模方法。ER=Entity Relationship 实体联系，面向数据存储需求建模，把数据抽象成某种信息结构。构成概念包括：实体/实例，实体集(矩形框)即拥有相同属性或特征的实体的集合，属性(椭圆或圆角矩形框)描述一个实体集的性质和特征，码在实体集中用来唯一标识实体的属性或属性组，联系(菱形框)分为1:1，1:n 和 m:n 三种。

        IDEF1X 建模方法。其元素中也有实体集，分为独立实体集(矩形)能唯一地被标识而不依赖与与其他实体集的联系与从属实体集(圆角矩形)唯一标识依赖于与其他实体集的联系。例如学生这个实体集可以由学号这个属性唯一标识，它就是独立实体集；考试成绩实体集中的实例可以由学号和科目号两个属性唯一标识，但是这两个属性都是来自于别的实体集，也就是 FK 而不是 PK，所以考试成绩是从属实体集；还有联系，有四种，标定型联系例如考试成绩这个从属实体集由其“双亲”学生和课程两个独立实体集标定，他们构成了标定型联系，非标定型联系例如班级与学生，分类联系和非确定联系补充一定关系之后可以转化成确定联系。

         3.1.4 概念设计实例

        以商场经营管理为例，到了这个设计环节就是实实在在开始做东西了。我们的目标，就是从冗杂的数据中，找出彼此之间的联系，把数据抽象成实体集，实体集是更高层次的概念，例如定义了一些实体集：顾客、会员卡、销售单据等等。实体集之间的联系也就是表与表之间的约束，例如顾客与会员卡的联系为拥有，但不是每个顾客都会有员卡，所以这种联系属于非标定型联系。

       之后开始确认实体集属性，进一步把数据详细“分配”到对应的实体集上。 要注意实体集并不意味着就是一个表！

3.2 数据库逻辑设计

        3.2.1 概述  逻辑设计就是把概念设计得到的结果 ER 模型，转换成具体的数据库管理系统支持的数据模型。

        3.2.2 逻辑设计实例  把 ER 图转换成关系模式(表)，一般包含两个步骤：识别 ER 模型中的联系，依次转换与每个联系相关联的实体集与联系为关系。

        以顾客和会员卡两个实体集之间的联系“拥有”为例，顾客实体集与会员卡实体集的联系基数为 1:n，n 为 0 或 1 。所以我们可以转换成 3 个关系：关系 1 是顾客，包含了顾客编号、会员卡号(如果没有的话就设为 None，小问题)、姓名、生日等信息；关系 2 是会员卡，包含了会员卡号、有效起始日期、有效截止日期、积分数等信息；关系 3 是拥有，也就是联系的实际意义所在，包含顾客编号和会员卡号属性。

        再举一个例子，销售单据和商品之间的联系称为“销售单据明细”。实体集销售单据首先转化成一个关系“销售单据”，该关系中涵盖每张单据的基本信息但不包括售出的商品的售价和数量等信息，之所以不包括是因为销售单据这个实体集还与收费、收银员等实体集相关联，它更多需要体现出的是每张单子产生了多少的收入是哪个柜台哪个收银员哪个时间开的这种数据；商品实体集转化成一个关系，着重关注商品编号、销售单价进货单价、库存、类别等信息；两个实体集之间的联系便转化为关系 3 “销售单据明细”与原本的联系同名，包含销售单据编号(是“销售单据”关系的主键)、商品编号(“商品”关系的主键)、单价、数量、总价等信息，更具体地说再“销售单据明细”中相同的销售单据编号和相同的商品编号会出现多次因为每一行数据只是代表每张单子中的一个记录，而一张单子通常不止一条购物记录，所以销售单据实体集与商品实体集之间的联系基数是 m:n。

3.3 数据库物理设计

        3.3.1 物理设计概述  数据库物理结构需要考虑的内容，以及数据库系统次啊用的主要文件组织形式。

        3.3.2 数据库的物理结构

        数据库中的数据是以文件形式存储在外设存储介质上的，每个 DB 文件可以看成逻辑记录的集合。

        文件的逻辑记录与磁盘块间的映射关系由 DBMS 来管理。

        从数据库物理结构角度需要解决几个问题：文件的组织如何将关系数据库中的关系表映射为数据库文件，文件的结构如何将 DB 文件的逻辑记录映射到物理文件中的磁盘块，文件的存取对具有某种结构的 DB 文件如何去查找插入删除修改其中的逻辑记录，索引技术。

         3.3.3 索引  

         1. 索引技术 Indexing 索引是一种快速数据访问技术，将文件的每个记录在某个或某个域上的取值与该纪录的物理地址直接联系起来(我个人的理解是，每张关系表中逻辑记录都是存储在某个特定地址上的，通常我们通过某种数据结构建立起关系表中数据的联系，如果要去获取其中某个，就按照从头到尾的查找方式，像链表一样，但现在我们额外创建了一个表来建立索引关系，就可以直接跳到对应的地址上)。索引加快了我们的速度，但是占用了一定的存储空间，而且当对表改动时索引也需要做出相应的改动。

         不过有疑问就是在索引中查找不也是查找，和直接在关系表中查找有什么区别吗？

         2. 索引技术分类  有序索引、散列技术利用散列函数实现记录域取值到记录物理地址间的直接映射关系。

         3. 有序索引  数据库中的数据文件常使用顺序文件结构，文件的数据记录按照某个特定的查找码值的升序或降序顺序(连续)地存储在文件中。索引文件的建立是选定数据文件中的某个或某些记录域作为查找码，然后建立起数据记录在查找码上的取值于该记录的物理地址间的映射关系。

         聚集索引的特征是数据文件中数据记录的排列顺序与索引文件中索引项的排列顺序相一致，非聚集索引则不一致。

        稠密索引的特征是数据文件中的每个查找码值在索引文件中都对应一个索引记录，稀疏所以则只有一部分有对应的记录。

        在数据文件的主码属性集建立的索引称为主索引，非主码属性上建立的索引称为辅索引。

        唯一索引，不包含重复值的索引列。

        单层索引也称为线性索引，多层索引例如二层索引，是对索引项再建立一级稀疏索引，用于快速查找索引项。

        3.3.4 数据库物理设计

        3.3.5 其他物理设计环节

        这两个小节东西巨多而且很杂很深，战略性放弃。