计算机三级 数据库技术 学习笔记 - Go语言中文社区

计算机三级 数据库技术 学习笔记


版权声明:本文为CSDN博主「RanLZ」的原创文章,转载请附上原文出处链接

计算机三级 数据库技术


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


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

1.1.1 软件工程与软件开发方法

  1. 瀑布模型
  2. 快速原型模型
  3. 螺旋模型

1.1.2 DBAS生命周期模型

p s . ps. ps.按照瀑布模型原理设计

D B A S DBAS DBAS 的生命周期由以下五个基本活动组成:

  1. 项目规划
  2. 需求分析
  3. 系统设计
  4. 实现与部署
  5. 运行与维护

3 3 3条设计主线:

  1. 数据组织与存储设计
  2. 数据访问与处理设计
  3. 应用设计

设计阶段分为以下3个步骤:

  1. 概念设计
  2. 逻辑设计
  3. 物理设计

1.2 规划与分析

1.2.1 系统规划与分析

  1. 任务称述
  2. 确定任务目标
  3. 确定系统范围和边界
  4. 确定用户视图

1.2.2 可行性分析

  1. 经济可行性
  2. 技术可行性
  3. 操作可行性
  4. 开发方案选择

1.2.3 项目规划

  1. 确定项目的目标和范围
  2. 更加 D B A S DBAS DBAS 软件开发模型,分解和定义整个项目包括的工作活动和任务
  3. 估算完成该项目的规模及所需各种资源
  4. 制定合理的 D B A S DBAS DBAS 项目计划

1.3 需求分析

  1. 需求获取
  2. 需求分析
  3. 需求描述
  4. 规范说明
  5. 需求验证

1.3.1 数据需求分析

描述用户需要组织的信息内容形成数据字典

数据字典包括以下五部分:

  1. 数据项
  2. 数据结构
  3. 数据流
  4. 数据存储和处理过程

1.3.2 功能需求分析

描述系统要做什么。

1.数据处理需求分析

数据处理需求分析结果可表示为数据流图 ( D F D ) (DFD) (DFD) D B A S DBAS DBAS 应支持的各种数据处理事务规范。

事务规范包括以下几方面的事物描述信息:

  1. 事务名称。
  2. 事务描述。功能、性能、完整性约束等方面的描述。
  3. 事务所访问的数据项。
  4. 事务用户。启动或执行该事务的事件或用户。

数据需求分析与数据处理需求分析的结果组织在一起,可以构成数据字典文档,该文档也被成为数据规范说明书。

2.业务规则需求分析

应用领域业务规则(又称为业务处理逻辑、业务逻辑)描述了应用领域中的业务功能处理流程步骤

1.3.3 性能描述

描述系统应当做到什么程度。

D B A S DBAS DBAS 性能指标:

  1. 数据操作响应时间,或数据访问响应时间。
  2. 系统吞吐量。
  3. 运行并发访问的最大用户数。
  4. T P S TPS TPS 代价值。

影响 D B A S DBAS DBAS 性能的主要因素:

  1. 系统的硬件资源。
  2. 网络通信设备性能。
  3. 操作系统环境。
  4. 数据库的逻辑设计和物理设计质量。
  5. D B M S DBMS DBMS 的配置和性能。
  6. 数据库应用程序自身。

1.3.4 其他需求分析

1.存储需求分析
  1. 初始数据库大小。
  2. 数据库增长速度。
2.安全性需求分析
  1. D B A S DBAS DBAS 系统应达到的安全控制级别。
  2. 各类用户的数据视图和视图访问权限。
  3. D B A S DBAS DBAS 应有的口令保护机制或者其他安全认证机制。
3.备份和恢复需求分析
  1. D B A S DBAS DBAS 运行过程中备份数据库的时间和备份周期。
  2. 备份数据是备份全部数据,还是其中的一部分。
  3. 备份方式是采用完全备份还是采用差异备份。

1.4 系统设计

如果需求分析阶段的任务是解决“干什么”的问题,那么系统设计阶段的任务是确定”怎么干“。

1.4.1 概念设计

1.数据库概念模型设计

数据库概念模型可能采用多种方式表示,如最常见的 E R ER ER 方法。

2.系统总体设计
  1. D B A S DBAS DBAS 体系结构设计。
  2. D B A S DBAS DBAS 系统硬件平台的选型和配置。
  3. 应用软件结构设计。
  4. 业务规则初步设计。
  5. 对系统关键技术进行方案选型和初步设计。

1.4.2 逻辑设计

  1. 数据库逻辑结构设计。
  2. 应用程序概要设计。
  3. 数据库事务概要设计。

1.4.3 物理设计

  1. 数据库物理结构设计。
  2. 数据库事务详细设计。
  3. 应用程序详细设计。

1.5 实现与部署

  1. 建立数据库结构。
  2. 数据加载。
  3. 事务和应用程序的编码及测试。
  4. 系统集成、测试与试运行。
  5. 系统部署。

1.6 运行管理与维护

主要包括日常维护、系统监控与分析、系统性能优化调整、系统进化升级等。


第二章 需求分析


2.1 需求分析

2.1.1 需求分析的概念与意义

需求分析是描述待开发的系统所要完成的功能。

目标是深入描述软件的功能和性能,确定软件设计的约束和软件同其他系统元素接口细节,定义软件的其他有效需求。

软件产品的下列特性使得需求获取困难重重:

  1. 软件功能复杂
  2. 需求的可变性
  3. 软件产品的不可见性

通常,一个计算机应用系统的需求分析工作是在系统分析人员用户不断交互的过程中完成的。

2.1.2 需求获取的方法

  1. 面谈
  2. 实地观察
  3. 问卷调查
  4. 查阅资料

2.1.3 需求分析过程

  1. 标识问题
  2. 建立需求模型
  3. 描述需求
    1). 需求概述
    2). 功能需求
    3). 信息需求
    4). 性能需求
    5). 环境需求
    6). 其他需求
  4. 确认需求
    需要评审委员会审核下列内容:
    1). 功能需求
    2). 数据需求
    3). 性能
    4). 数据管理
    5). 其他需求

2.2 需求分析方法

2.2.1 需求分析方法概述

结构化分析与功能建模方法主要有 D F D DFD DFD I D E F 0 IDEF0 IDEF0 等。

结构化分分析方法的基本特征是 抽象分解

结构化分析及建模方法的主要优点是:

  1. 不过早陷入具体的细节。
  2. 从整体或宏观入手分析问题。
  3. 通过图像化的模型对象直观地表示系统要做什么,完成什么功能。
  4. 图像化建模方法方便系统分析员理解和描述系统。
  5. 模型对象不涉及太多技术术语,便于用户理解模型。

2.2.2 DFD需求建模方式

D F D DFD DFD 建模方法的核心是 数据流

1.DFD方法的基本元素
  1. 数据流。数据流用一个箭头描述数据的流向,箭头上标注的内容可以是信息说明或数据项。
  2. 处理。在图中用矩形框表示。指向处理的数据流为该处理的输入数据,离开处理的数据流为该处理的输出数据。
  3. 数据存储。对其进行的存取分别以指向或离开数据存储的箭头表示。
  4. 外部项(也称数据源或数据终点)。以圆角框或平行四边形表示。
    在这里插入图片描述
2.DFD图

采用自顶向下逐步细化的结构化分析方法表示目标系统。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xkGLiIex-1581259229719)(en-resource://database/1973:0)]

3.DFD建模过程
  1. 明确目标,确定系统范围。
  2. 建立顶层 D F D DFD DFD 图。
  3. 构建第一层 D F D DFD DFD 分解图。
  4. 开发 D F D DFD DFD 层次结构图。
    1. 保持均匀的模型深度。
    2. 按困难程度进行选择。
    3. 如果一个处理难以确切命名,可以考虑对它重新进行分解。
  5. 检查确认 D F D DFD DFD 图。
    1. 父图中描述过的数据流必须要在相应的子图中出现。
    2. 一个处理至少有一个输入流和一个输出流。
    3. 一个存储必定有流入的数据流和流出的数据流。
    4. 一个数据流至少有一端是处理框。
    5. 模型图中表达和描述的信息是全面的、完整的、正确的、一致的。

2.2.3其他需求建模方法

1.IDEF0方法简介

I D E F 0 IDEF0 IDEF0 描述系统功能及相互关系;

I D E F 1 IDEF1 IDEF1 描述系统信息及其数据之间的联系;

I D E F 2 IDEF2 IDEF2 用于系统模拟,建立动态模型。

组成 I D E F 0 IDEF0 IDEF0 图的基本元素是矩形框箭头

矩形框代表功能活动,写在矩形框中的动词短语描述功能活动的名称,活动的编号按照要求写在矩形框右下角指定位置。
在这里插入图片描述

  • 左侧输入箭头表示活动需要的数据;
  • 矩形框上方控制箭头描述了影响这个活动执行的事件或约束条件;
  • 右边输出箭头说明由活动产生的结果和信息;
  • 下方的进入的机制箭头表示实施该活动的物理手段或完成活动需要的资源(计算机系统、人或组织)。

输入控制二者的作用是有区别的,输入强调被活动消耗或变化的内容,而控制强调对活动的约束条件。

每个箭头所表示的数据用一个名词短语描述,数据可以是信息对象

2.UML用例模型简介

U M L UML UML 方法采用面向对象思想建模,其中的用例模型用于描述系统功能需求。

2.2.4 DFD与IDEF0比较

  1. I D E F 0 IDEF0 IDEF0 图中箭头不是强调顺序,而是强调数据约束
  2. 相对 D F D DFD DFD 图, I D E F 0 IDEF0 IDEF0 图中的箭头有更加丰富的语义,不仅能够表示出数据流,还可以表示出控制流和说明处理或活动实例方式的一些约束。
  3. 两个模型的组成元素更简单, I D E F 0 IDEF0 IDEF0 模型结构更清楚,容易理解,更适合用于大型复杂系统的需求建模。

第三章 数据库结构设计


3.1 数据库概念设计

概念设计是数据库设计的核心环节。通过对用户需求进行综合、归纳与抽象,形成一个独立于具体DBMS的概念模型。

3.1.1 概念设计的任务

  1. 定义和描述应用领域涉及的数据范围。
  2. 获取应用领域或问题领域的信息模型。
  3. 描述清楚数据的属性特征。
  4. 描述清楚数据之间的关系。
  5. 定义和描述数据的约束。
  6. 说明数据的安全性要求。
  7. 支持用户的各种数据处理需求。
  8. 保证信息模型能转化成数据库的逻辑结构(即数据库模式)。

3.1.2 概念设计的依据及过程

1.概念设计的依据

依据:数据库概念设计以需求分析的结果为依据,即说明书、 D F D DFD DFD 图以及需求阶段收集到的应用领域中的各类报表等。

结果:概念设计需要构造信息模型( E R ER ER )与编写概念设计说明书

2.概念设计的过程
  1. 明确建模目标。(确定模型覆盖的问题范围)
  2. 定义实体集。(自底向上标识和定义实体集)
  3. 定义联系。(实体间关联关系)
  4. 建立信息模型。(构造 E R ER ER 模型)
  5. 确定实体集属性。(属性描述一个实体集的特征或性质)
  6. 对信息模型进行集成与优化。(检查和消除命名不一致、结构不一致等)

概念设计是 D B DB DB 设计的核心环节。概念数据模型是对现实世界的抽象和模拟。

3.1.3 数据建模方法

1.ER建模方法
  1. 实体或实例:客观存在并可相互区分的事物叫实体。
  2. 实体集:同型实体的集合称为实体集。
  3. 属性:实体所具有的某一特性。一个实体可以由若干个属性来刻画。每个属性的取值范围称为
  4. 码:实体集中能唯一标识每一个实例的属性或属性组称为该实体集的码。用来区别同一实体集中的不同实体的称为主码
  5. 联系:描述实体之间的相互关系,联系也可以有属性。同类联系的集合称为联系集
    • 一对一联系(1:1)
    • 一对多联系(1:n)
    • 多对多联系(m:n)
  6. 符号
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dg1Rovot-1581409962530)(en-resource://database/1977:0)]
2.IDEF1X建模方法(了解)

I D E F 1 X IDEF1X IDEF1X 侧重分析、抽象和概括应用领域中的数据需求,被称为数据建模方法。

3.2 数据库逻辑设计

3.2.1 概述

数据库逻辑设计的任务是把数据库概念设计的结果( E R ER ER 模型),转换为具体的数据库管理系统支持的数据模型。
在这里插入图片描述

3.2.2 个人补充

1.关系模型

关系模型就是用二维表结构来表示实体及实体之间联系的模型。

关系的描述称为关系模式。关系模式由五部分组成,即它是一个五元组:R(U,D,DOM,F)

  • R:关系名。
  • U:组成该关系的属性名集合。
  • D:属性组U中属性所来自的域。
  • DOM:属性到域的映射
  • F:属性组U上的一组数据依赖。

由于 D D D D O M DOM DOM对模式设计的关系不大,这里把关系模式简化为一个三元组:R<U,F>

当且仅当 U U U上的一个关系 R R R 满足 F F F 时, R R R 称为关系模式 R < U , F > R<U,F> R<U,F> 的一个关系

关系数据库设计的核心:关系模式的设计。

2.数据依赖

定义:设 R ( U ) R(U) R(U) 是一个属性集 U U U 上的关系模式, X X X Y Y Y U U U 的子集。若对于 R ( U ) R(U) R(U) 的任意一个可能的关系 r r r , r r r 中不可能存在两个元组在 X X X 上属性组相等,而在 Y Y Y 上的属性值不等,则称“X函数确定Y”或“Y函数依赖于X”,记作 X → Y X rightarrow Y XY

2.1函数依赖

普遍存在于生活中,这种依赖关系类似于数学中的函数 y = f ( x ) y=f(x) y=f(x),自变量x确定之后,相应的函数值y也就唯一地确定了。

2.2多值依赖

教师号可能多值依赖课程号,因为给定一个(课程号,参考书号)的组合,可能有对应多个教师号。这是因为多个老师可以使用相同或不同的参考书上同一门课。

简单点讲,函数就是唯一确定的关系;多值依赖却。

2.3函数依赖的几种特例
2.3.1 平凡函数依赖与非平凡函数的依赖

如果 X → Y X rightarrow Y XY,且 Y ⊄ X Y notsubset X YX,则 X → Y X rightarrow Y XY 称为非平凡函数依赖

Y ⊆ X Y subseteq X YX,则称 X → Y X rightarrow Y XY平凡函数依赖

由于 Y ⊆ X Y subseteq X YX时,一定有 X → Y X rightarrow Y XY,平凡函数依赖必然成立,没有意义,所以一般所说的函数依赖总是指非平凡函数依赖

2.3.2 完全函数依赖与部分函数依赖

完全函数依赖:

成绩依赖于学号和课程号两个字段的组合;但只知道学号无法确定成绩,同理只知道课程号也无法确定成绩;只有学号和课程号组合在一起才能标识哪个学生哪门课程的成绩;

因此 (学号,课程号) → rightarrow 成绩 是“完全函数依赖”。

部分函数依赖:

姓名、性别和班级三个属性只依赖于主键中的学号,与“课程号”无关

因此(学号,课程号) → rightarrow 姓名 是“部分函数依赖”。

课程名和学时数只依赖于课程号,

因此(学号,课程号) → rightarrow 课程名 是“部分函数依赖”。

2.3.3 传递函数依赖

班主任依赖于班级,与学号无关,与课程号也无关。又因班级依赖于学号,所以班主任间接依赖于学号。

因此,(学号,课程号 → rightarrow 班主任 是“传递函数依赖”。

3.候选码、主码、外码

如果某属性组的值能唯一确定整个元组的值,则称该属性组为候选码侯选关键字

候选码如果有多个,可以选其中的一个作为主码

属性或属性组 X X X 不是关系模式 R R R 的码(不是主码或候选码),但 X X X 是另一个关系模式的码,则称 X X X R R R外部码,也称外码

4.范式

关系模式满足的约束条件称为范式。根据满足规范化的程度不同,范式由低到高分为1NF,2NF,3NF,BCNF,4NF,5NF。

  • 1NF:如果关系模式 R R R ,其所有属性都是不可再分的基本数据项,则称 R R R 属于第一范式, R ∈ 1 N F R∈1NF R1NF
  • 2NF:如关系模式 R ∈ 1 N F R∈1NF 版权声明:本文来源CSDN,感谢博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
    原文链接:https://blog.csdn.net/RangeLZ/article/details/104235076
    站方申明:本站部分内容来自社区用户分享,若涉及侵权,请联系站方删除。

0 条评论

请先 登录 后评论

官方社群

GO教程

猜你喜欢