[TOC]
前言
考试环境介绍:
? 考试范围类型: 选择题【40分40道】 ,应用题(填空题【30分10题】), 设计题【30分3题】
? 应用题: 在多空题上加顿号。
? 分值主要集中于数据库的操作上,数据库的概念很充要
考试要求:
? 1、掌握数据库技术的基本概念、原理、方法和技术。
? 2、能够使用SQL语言实现数据库操作。
? 3、具备数据库系统安装、配置及数据库管理与维护的基本技能。
? 4、掌握数据库管理与维护的基本方法。
? 5、掌握数据库性能优化的基本方法。
? 6、了解数据库应用系统的生命周期及其设计、开发过程。
? 7、熟悉常用的数据库管理和开发工具,具备用指定的工具管理和开发简单数据库应用系统的能力。
? 8、了解数据库技术的最新发展。
1 数据库基本概念
1 数据库的基本概念
1.1.1 数据
定义:描述事物的符号序列
种类:数字、文字、图形、图像声音及其他特殊符号
计算机中数据分为两部分:
临时性数据(内存),计算机关机后将全部丢失, 具体易失性。
非易失性 持久性数据(硬盘) ,计算机关机后不必丢失
graph LR
F[数据,是描述事物的符号序列]==>A
A((计算机中数据)) ==> B[临时性数据,计算机关机后将全部丢失]
A ==> C[非易失性数据,计算关机后不丢失]
数据有型(Type)与值(Value)之分:
型:数据表示的类型,如整型、字符型等
值:给出了符合给定型的值
graph TD
A((数据))--> B[型 Type]
A-->C[值 Value]
B-->D[数据表表示的类型]
C-->E[给出了符合给定型的值]
1.1.2 数据库 Database
简称 DB
数据的集合,具有统一的结构形式并存放于统一的存储介质内,是多种应用数据的集成,并可被各个应用程序所共享 按数据所提供的数据模式存放的
1.1.3 数据库系统 Datebase System
简称DBS 简称为数据库
组成:
? 数据库(数据)
? 数据库管理系统 DBMS(软件)
? 数据库管理员(人员)DBA
? 硬件平台:计算机和网络
? 软件平台:操作系统、数据库系统开发工具、接口软件
graph TD
A((数据库))--> B(数据库 数据)
A((数据库))--> C("数据库管理系统(软件)")
A((数据库))--> D(数据库管理员)
A((数据库))--> E[硬件平台和软件平台]
1.1.4 数据库应用系统 (Datebase Application System)
简称DBAS ,列如信息管理系统
组成:数据库系统+应用软件+应用界面
硬件(裸机)->操作系统->数据库管理系统->应用开发工具软件(IDE)->应用软件
```mermaid
graph LR
F(数据库应用系统)
硬件--> 操作系统
操作系统 --> 数据库管理系统
数据库管理系统 --> 应用开发工具软件IDE
应用开发工具软件IDE --> 应用软件
1.2 软件工程与数据库技术
1.2.1 软件工程和数据库工程的基本概念
软件工程:用工程、科学和数学的原则与方法,来开发软件
软件生存周期:软件产品从定义开始,经过开发、使用与维护,直到退役
数据库工程:属于软件工程,数据库工程
1.数据库设计 2.相应的应用的设计与实现
数据库应用系统的设计开发必须有软件过程模型作为指导
1.2.2 软件开发模型
瀑布模型(从上到下)
快速设计模型(按照样品的形式,快速的开发第一代产品)
螺旋模型(引入风险控制)
graph TD
A((软件开发模型))==自上而下==>B[瀑布模式]
A((软件开发模型))==快速的开发第一代产品==>C[快速设计模型]
A((软件开发模型))==引入风险控制==>D[螺旋模型]
1.2.3 总结
软件工程包括数据库系统开发,而且数据应用系统的设计开发必须有软件过程模型作为指导。
软件开发模型中主要使用瀑布模型,采用自上而下的方式开发。
1.3 DBAS 生命周期模型【瀑布模型】
1.3.1 规划与分析
是DBAS生命周期的第一步,目标是面向实际应用和需求,确定整个数据库应用系统的目标和任务
从技术、操作和经济三个方面进行可行性分析,并制定合理的项目开发计划。
主要工作内容:
? 系统规划与定义:任务陈述、确定任务目标、确定范围和边界、确定用户视图
? 可行性分析:技术、经济、操作可行性及开发方案选择
? 项目规划:项目团队、环境、活动、成本、预算,进度计划(时间要求)
1.3.2 需求分析(目标)
准确了解与分析用户需求(包括数据与处理)是最困难、最耗费时间的一步。
需求分析过程由需求获取、需求分析、需求描述与规范说明、需求验证等步骤组成。
各种需求的主要工作:
? 数据需求分析:描述用户需要组织的信息内容 ==》形成数据字典
? ==功能需求分析:描述系统做什么 》 功能建模
? 数据处理需求分析、业务规则需求分析 ==》满足用户的功能性需求,同时也要分析用户的非功能性需求。
? 性能需求分析:描述系统应当做到什么程度 ==》 数据操作响应时间、系统吞吐量、硬件资源等等
? 其他需求:存储需求、安全性需求、备份与恢复等需求
1.3.3 系统设计【过程】——数据库设计
如果需求分析阶段的任务是解决“干什么”的问题,那么系统设计阶段的任务是确定“怎么干”
系统设计包括:
a.概念模式设计:数据库概念模型设计、系统总体设计
b.逻辑模式设计(理论上):数据库逻辑结构设计、应用程序概要设计、数据库事物概要设计
c.物理设计(真实上):数据库物理结构设计、数据库事务详细设计、应用程序详细设计
1.3.4 实现与部署
也称为DBAS的实施。需要根据设计结果建立数据库,编写应用程序,集成DBAS软硬件,组成完整的DBAS
建立数据库结构,数据加载,事务和应用程序的代码及测试,系统集成 、测试与运行,系统部署。
1.3.5运行管理与维护
DBAS生命周期模型中时间最长,具有不可预知性
主要包括日常维护、系统监控与分析、系统性能优化调整、系统进化升级等。
这些工作主要由数据库管理员DBA负责。
graph LR
A(("DBAS生命周期(瀑布模型)"))-->B[规划与设计]
B-->从技术经济可操作性上判断
A-->C[需求分析]
Z[目标]-.->C
C-->Q(功能需求分析)
Q-->数据库概念模型设计
Q-->系统总体设计
C-->性能需求分析
C-->非功能性需求
A-->D[系统设计]
X[过程]-.->D
D-->概念设计
D-->逻辑设计
D-->物理设计
A-->E[实现与部署]
A-->F[运行与维护]
F-->G["DBAS生命周期模型中时间最长,具有不可预知性"]
2 需求分析
2.1.需求分析的概念与意义
需求是指用户对软件的功能和性能的要求
就是用户希望软件能做什么事情,完成什么样的功能,达到什么性能。
需求分析是在计算机系统的软件功能分配和软件设计之间起重要桥梁作用的一项软件工程活动。
1 描述待开发的系统所要完成的功能。
2 需求分析使系统工程师能够刻画出软件的功能和性能
3 指明软件和系统其它元素的接口并建立软件必须满足的约束。
需求分析的目标是深入描述软件的功能和性能
确定软件设计的约束和软件同其它系统元素的接口细节,定义软件的其他有效性需求。
2.2.需求分析的难点
a.软件功能复杂
b.需求的可变性 用户的不明确性
c.软件产品的不可见性 软件必须运行才能知道
2.3 需求获取的方法(重点)
a.面谈 系统分析员与用户方的专家和业务人员进行知识交流、与他们会谈,获得需求
b.实地观察 实地观察用户的操作过程。对比现有的系统,思考如何采取更高效的方式
c.问卷调查 若需访谈的个体太多,且需要回答容易确定的细节问题,可采取问卷调查方式
d.查阅资料 收集和查阅相关的文献资料,如组织机构图、规章制度、相关文档、图表及报告等。
a.面谈 对象——负责当前业务的核心人员
? 准备访谈
? 计划和安排访谈日程
? 访谈开始和结束
? 引导访谈——技巧 如:数据的值的精确度
? 访谈整理工作 ——文档
b.实地考察
? 现场观察法
? 询问法
? 直接访问、堵截访问、电话访谈
c.问卷调查——细节
? 适合使用情况:
? 需访谈的个体太多
? 需要问答容易确定的细节问题
? 希望有详细的结果
注意事项:
? 使用问卷表尽可能的简短
? 估计回答问题需要时间,并在问卷表开头标注
? 制定问题前,要确定你需要的答案
d.查阅资料
? 收集用户以下材料:
? 书面需求文档
? 现在的业务操作流程及其改进意见
? 现在使用的数据表和文件及其格式,并确定数据的来源
2.4 需求分析的过程
a.标识问题: 需求分析的第一步,通过对问题和标识获得对所有求解问题及其运行环境的理解
b.建立需求模型: 目前在信息系统的需求分析中可使用结构化分析模型或面向对象分析模型
c.描述需求:需求、功能、信息、性能、环境、其他需求
- 确定需求:需求确认及评审。审核功能需求、数据需求、性能、数据管理及其他需求
?
2.4.1 需求分析的方法
目前在信息系统的需求分析中可使用如下方法:
结构化分析与建模方法 SAD 如:DFD建模、IDEFO建模
面向对象分析与建模方法OOA(第五章介绍) 如:UML用例建模 OOAD
?
结构化设计(Stuctured Design,SD) 结构化分析(Structured Analysis,SA)
结构化分析与设计方法(SAD)
结构分析与设计方法是瀑布模型的首次实践
?
结构化分析任务
建立分析模型。SA模型是描述软件需求的一组模型,主要包括功能模型、数据模型和行为模型。
编写需求规格说明书(没有固定的模式,每个公司都不一样)。
SRS是分析阶段编写的以文字为主的文档,
主要内容包括:引言、信息描述功能描述、行为描述、质量保证、接口描述以及其他需求等。
? 结构化分析的指导思想。抽象与分解是结构化分析的主要指导思想。
DFD需求建模方法
I -> P ->O
数据流图(Data Flow Diagram,DFD):
DFD建模方法的核心是数据流,从应用系统的数据流着手以图形方法刻画和标识
一个具体业务系统的数据处理过程和数据流

1 DFD建模的基本元素
a.数据流
数据流是数据在系统内传播的路径,因此有一组成分固定的数据组成。
如订票单有旅客姓名、年龄、单位、身份证号、日期、目的等数据项组成。
由于数据流是流动中的数据,所以必须有流向
除了与数据存储之间的数据流不用命名外,数据流应该用名词或名词短语命名。
b.数据源(源点)
代表系统之外的实体,可以是人、吴或其他软件系统。
c.对数据的加工(处理)
? 加工时对数据进行处理的单元,它接受一定的数据输入,对其进行处理,并产生输出
d.数据存储:
? 表示信息的静态存储,可以代表文件、文件的一部分、数据库的元素等。
?
2.DFD建模过程 DFD功能建模 业务流程 Database Flow Diagram
具体建模过程及步骤:
1.明确目标,确定系统范围。
? 将用户对目标系统的功能需求完整、准确、一致地描述出来。
2.建立顶层DFD图。
? 说明系统边界,即系统的输入和输出数据流,顶层DFD只有一张
3.构建第一层DFD分解图。
? 中间层DFD,描述了某个过程的分解,而它的组成部分又要进一步分解
4.开发DFD层次结构图(源则:保持均匀的模型深度,按困难程度选择)。
? 底层DFD,由一些不可再分解的过程组成
5.检查确认DFD图
5条规则
父图中描述过的数据流必须在相应子图出现。
一个处理至少有一个输入流和输出流
一个存储必定有流入的数据流和流出的数据流
一个数据流至少有一端是处理框。
表达描述的信息是全面、完整、正确和一致的。
3.IDEFO需求建模方法
最常使用的是IDEF0~IDEF4:
IDEF0:描述系统功能及其相互关系
IDEF1:系统信息及其数据之间联系
IDEF2:系统模拟,动态建模
IDEF3:过程描述及获取方法
IDEF4 :面向对象设计
4.UML用例建模方法
UML方法采用面向对象思想建模,使用用例图来描述系统功能需求。
用例图由系统、角(jue)色、用例三种模型元素及其之间的 关系构成。
3 数据库概念设计
概念设计是数据库设计的核心环节。
通过对用户需求进行综合、归纳与抽象,形成一个独立与具体DBMS的概念模型。
3.1 数据库概念设计的目标
定义和描述应用领域设计的数据范围
获取信息模型
描述数据的属性特征
描述数据之间的关系
定义和描述数据的约束
说明数据的安全性要求
支持用户的各种数据处理需求
保证信息模型能转化成数据库的逻辑结构(即数据库模式)。
3.2 概念设计的依据及过程
概念设计是DB设计的核心环节。概念数据模型是对现实世界的抽象和模拟。
依据:
? 数据库概念设计以需求分析的结果为依据,即需求说明书、DFD图以及需求阶段收集到的应用领域
? 中的各类报表等。
结果:
? 概念设计的结果是概念模型(ER)与概念设计说明书。
过程:
? 1.明确建模目标(模型覆盖范围)
? 2.定义实体集(自底向上标识和定义实体集)
? 3.定义联系(实体间关联关系)
? 4.建立信息模型(构造ER模型)
? 5.确定实体集属性(属性描述一个实体集的特征或性质)
? 6.对信息模型进行集成与优化(检查和消除命名不一致、结构不一致等)
3. 3概念模型设计-ER图
ER建模方法,用E-R图来描述数据库的概念模型
观点:世界是由一组称作实体的基本对象
这些对象之间的联系构成的与E-R模型有关的概念
3.3.1 E-R 模型的概念
实体(Entity)或实例(Instance)
客观存在并可相互区分的事物叫实体
实体集(Entity Set)
同型实体的集合称为实体集。如全体学生
属性(Attibute)
实体所具有的某一特性。一个实体可以由若干属性来刻画。每个属性范围称为域。
注意:
一个属性的值必须属于唯一的域,域在这里相当于数据类型的子集,属性的取值必须为同一域。
标识属性的值不能重复且不可以为空。
例如:学生可由学号、姓名、年龄、系、年纪等组成。
码(key):键
实体集中唯一标识每一个实体的属性或属性组合。
用来区别同一实体集中的不同实体的称作主码。 主键
一个实体集中任意两个实体在主码上的取值不能相同如:学号是学生实体的主码
联系(Relationshi)
描述实体之间的相互关系
如学生与老师间的授课关系,学生与学生间有班长关系。
联系也可以有属性,如学生与课程之间有选课联系,
每个选课联系都有一个成绩作为其属性
?
同类联系的集合称为联系集
实体间的联系有三类:
实体之间的联系的数量,即一个实体通过一个联系集能与另一实体集相关联的实体的数目
一对一联系(1:1)
? 如:“系”与“系主任”(一个系只有一个系主任,一个系主任只负责管理一个系)
一对多联系(1:n)
? 如:“系”与“学生”(一个系招收若干学生,一个学生只属于一个系)
多对多联系(m:n)
? 如:“学生”与“课程”(一名学生可选修多门课程,每门课程可被多名学生选修)
graph TB
B((用户编号))--- A[用户]
C((用户名))--- A
D((密码))--- A
E((真实姓名))--- A
F((角色))--- A
A--- R{担任}
R--- J[角色]
J--- H((角色编号))
J---I((角色名称))
J--- K((角色描述))


4 数据库逻辑设计
4.1 逻辑设计的任务:
将概念模型(如ER图)转化为DBMS支持的数据模型(如关系模型),并对其进行优化。
4.2 逻辑设计的依据和阶段目标:
? 
4.3数据模型
数据模型是对现实世界的抽象,是用来表示实体与实体之间联系的模型。
graph TB
A((数据模型))==>层次模型
A==>B["关系数据模型(若干个关系模式组成的集合)"]
A==>网状模型
关系是关系模式的实例-.->B
B-->数据结构
B-->C[关系的完整性约束]
C-->|实体完整性|主码不能为空
C-->|参照完整性|外码不能为空
C-->|用户参照完整性|针对某一具体的关系数据库约束条件
style B fill:red,font:white
4.3.1 关系数据模型
关系数据模型就是用二维表格结构来表示实体及实体之间联系的模型。
特点:简单灵活
注意:
关系模式描述关系的静态结构,它是静态、稳定
而关系是动态、随用户对数据库的操作而变化的
4.3.1.1 关系模式
关系的描述称为关系模式(Relation Scheme)。
关系模式由五部分组成即它是一个五元组:R(U,D,DOM,F)
R:关系名
U:组成该关系的属性名集合
D:属性组U中属性所来自的域(取值范围)
DOM:属性到域的映射
F:属性组U上一组数据依赖
由于D、DOM对模式设计的关系不大,这里把关系迷失简化为一个三元组:
R<U,F>,当且仅当U上的一个关系R满足F时,R称为关系模式R<U,F>的一个关系

? 
1 关系模式设计的要求
1、关系数据库设计的核心: 关系模式的设计。
2、关系模式的设计目标:
按照一定的原则从数量众多而又相互关联的数据中,构造出一组既能较好地反映现实世界
而又有良好的操作性能的关系模式。
2 数据库设计步骤
新奥尔良法,数据库设计步骤:
需求分析 -> 概念结构设计 -> 逻辑结构设计-> 物理结构设计
? E-R图 关系模式设计
4.3.2 数据依赖
数据依赖是关系内部属性与属性之间的一种约束关系
1、 现实解释属性间相互联系的抽象
2、 数据的内在性质
3、 语义的体现
完整性约束的表现形式
限定属性的取值范围,如年龄<60
定义属性间值得相互关联(主要体现于值得相等与否),这就是数据依赖
1 函数依赖
(Functional Dependency,FD ) 唯一确定
\[如果 X \to Y,且Y \notin X,则 X \to Y 称为非平凡函数依赖。\\如果 Y \subseteq X,则称 X \to Y 为平凡函数依赖。\\由于 Y \subseteq x时,一定有 X \to Y,平凡函数依赖必然成立,没有意义\\所有一般所说的函数依赖总是值非平凡函数依赖
\]
)

? 
)
?
?
2 多值依赖
(Multivalued Dependency,MD) 不是唯一确定
教师号可能多值依赖课程号,因为给定一个(课程号,参考书号)的组合,可能有对
应多个教师号。这是因为多个老师可以使用相同或不同的参考书上同一门课。
简单点讲,函数就是唯一确定的关系;多值依赖却不能唯一确定。
?
4.3.4 候选码主码外码
如果某属性组的值能唯一确定整个元组的值,则称该属性组为候选码或候选关键字。
例如:(学号,姓名,性别,年龄)中,学号是关键字,(学号,姓名)不是关键字,性别不是关键字。
候选码如果有多个,可以选其中的一个作为主码(Primary Key)。
4.3.5 数据规范化
关系数据库的设计主要是关系模式设计。关系模式设计的好坏直接影响到数据
库设计的成败。将关系模式规范化,是设计较好的关系模式的惟一途径。
关系模式的规范化主要是由关系范式来完成的。
关系模式的规范化:把一个低一级的关系模式分解为高一级关系模式的过程。
目的:尽量消除插入、删除异常,修改复杂,数据冗余的问题
4.3.6 范式(约束)
范式:关系模式满足的约束条件称为范式。根据满足规范化的程度不同
范式由低到高分为 1NF,2NF,3NF,BCNF,4NF,5NF。
作用:用于消除数据库中的多余数据,改进数据库整体组织,增强数据的一致性,增加数据库设计的灵活性
1 NF:如果关系模式R,其所有属性都是不可再分的基本数据项,则称R属于第一范式,
R∈1NF

?
2NF:如果关系模式R∈1NF,且每个非主属性完全函数依赖于主码,
则称R属于第二范式 ,R属于2NF
列如:判断R(学号,姓名,年龄,课程名称,成绩,学分)是否属于第二范式
主码(学号,课程名称)
非主属性:姓名,年龄,成绩,学分
存在如下决定关系:
学号,课程名称)->(姓名,年龄,成绩,学分)
但(课程名称)->(学分) R不属于2NF
学号)->(姓名,年龄)
3NF:如果关系模式R为2NF,并且中的每个非主属性不传递依赖于R的主码,
则称关系R是属于第3范式的,R属于3NF.
例如:判断R(学号,姓名,年龄,所在学院,学院地点,学院电话)是否属于第三范式。
主码:(学号)
非主属性:姓名,年龄,所在学院,学院地点,学院电话
存在非关键字段"学院地点"、“学院电话”对关键字段“学号”的传递函数依赖
3NF要求实体的属性不能存在传递依赖 R不属于3NF


?
4.4 数据库逻辑设计方法
E-R图 -> 关系模型
设计逻辑结构分分三步:
a.将概念结构转化为一般的关系模型
b.将转化来的关系模型向特D定DBMS支持下得数据模型转换
c.对数据模型进行优化
如果是关系型数据库管理系统,就应将概念模型转换为关系模型,即将E-R图中的实体
联系转换为关系模式。
数据库逻辑模型的产生,即概念模型按一定规则可以转换成数据模型。
这种转换的原则如下:
1、一个实体转换成一个关系模式
2、一个1:1联系可以转换为一个独立的关系模型 也可以与任意一端对应的关系模式合并。
3、一个1:n联系可以转换为一个独立的关系模式,也可以与n端对应的关系模式合并。
4、一个m:n联系转换为一个关系模型
5、三个或三个以上实体间的一个多元联系转换为一个关系模式。
6、同一实体集的实体间的联系,也可以按1:1、1:n和m:n三种情况分别处理
?
5 数据库物理设计1
5.1 物理设计概述
物理数据库设计是设计数据库的存储结构和物理实现方法
目的:将数据的逻辑描述转换为实现技术规范,设计数据存储方案,
以便提供足够好的性能并确保数据库数据的完整性、安全性、可靠性。
?
5.2 数据库的物理结构
物理设备上的存储结构存取方法称为数据库的物理结构
数据库中的数据以文件形式存储在外设存储介质上。
一个文件在物理上可看做是存放记录的一列磁盘块组成的,成为物理文件。
文件组织、文件结构、文件存取、索引技术
5.3 索引
索引(Index)是数据库中独立的存储结构
作用是提供一种无须扫描每个页面(存储表格数据的物理块)而快速访问数据页的方案
索引技术(Indexing)是一种快速数据访问技术。
索引技术的关键:建立记录域取值到记录的物理地址(如页码)间的映射关系
即索引索引能提高性能,但是有代价的。
设计和创建索引是,应确保对性能的提高程度大于在存储空间和处理资源方面的代价
? 
1 有序索引
索引文件机制:
利用索引文件(索引记录组成)实现记录域(查找码,排序域)取值到记录物理地址间的映射关系。
数据文件(主文件)和索引文件(索引记录或索引项的集合)是
有序索引技术中的两个主数据文件常采用顺序文件结构。
几种主要的有序索引:
1**.聚集索引**(索引项与数据记录顺序一致,索引顺序文件)和非聚集索引。
一个数据文件只可建立一个聚集索引,但可建立多个非聚集索引。逻辑地址和物理地址相同
2.稠密索引(数据文件中每个查找码都对应索引记录)和稀疏索引(部分查找码的值对应索引记录)。
3.主索引(主码属性集上建立的索引)与辅索引(非主属性上建立的索引)。
4.唯一索引(索引列不包含重复值)
5.单层索引(线性索引,每个索引项顺序排列直接指向数据文件中的数据记录)和多层索引(大数据量文件中的采用多层树型(B,B+树)索引快速定位)。
2 散列索引
哈希(Hash)索引机制,利用散列函数实现记录域取值到记录物理地址间的直接映射关系。
6 数据库的物理设计2
目标是得到存储空间占用少,数据访问效率高和维护代价低的数据库物理模式。
数据库底层物理存储与存取,与DBS所依赖的硬件环境、操作系统和DBMS密切相关。
目前大部分DBS都是关系数据库系统。
6.1 数据库逻辑模型描述
根据数据库逻辑结构信息设计目标DBMS可支持的关系表(这里称为基本表)的模式信息
这个过程称为数据库逻辑模式描述关系模式及其视图转换基本表和视图,
利用完整性机制(如触发器)设计面向应用的业务规则。
SQL Server 采用T-SQL语言。
为基本表选择合适的文件结构(堆文件、顺序文件、聚集文件、索引文件和散列文件)
6.2 文件组织与存取设计
基本原则:
根据应用情况将易变部分与稳定部分、存取频率较高部分与存取频率较低部分分开存放以提高系统性能。
分析理解数据库事务访问特性:
- 使用事务-基本表交叉引用矩阵;
- 估计各事务执行频率;
- 汇总每基本表各事务操作频率信息;
- 根据结果设计文件结构可以考虑将表和索引分别放在不同的磁盘上。
在查询时,由于两个磁盘驱动器分别在工作,因而可以保证物理读写速度比较快。
6.2.1 影响数据文件存储结构的因素
这三个方面常常是相互矛盾的
解决办法
- 适当冗余
- 增加聚簇功能
- 必须进行权衡,选择一个折中方案
6.2.2 存取路径
在关系数据库中,选择存取路径主要指确定如何建立索引。
对同一个关系要建立多条存取路径才能满足多用户的多种应用要求。
物理设计的第一个任务就是要确定选择那些存取方法
6.2.3 DBMS常用存取方法
索引方法,目前主要是B+树索引方法、聚簇(Cluster)方法、 HASH方法
建立索引原则
- 一个(组)属性经常在操作条件中出现
- 一个(组)属性经常在连接操作的连接条件中出现
- 一个(组)属性经常作为聚集函数的参数。
建立聚集索引
检索数据时,常以某个(组)属性作为排序、分组条件。
检索数据时,常以某个(组)属性作为检索限制条件,并返回大量数据。
表中某个(组)的值重复性较大。
?
6.2.4 数据分布设计
不同类型数据的物理分布将应用数据(基本表)、索引、日志、数据库备份数据等合理安排在不同介质中。
应用数据的划分与分布
根据数据的使用特征划分(频繁使用分区和非频繁使用分区)
根据时间、地点划分(时间或地点相同的属于同一分区)
分布式数据库系统(DDBS)中的数据划分(水平划分或垂直划分)
派生属性数据分布(增加派生列或不定义派生属性)
关系模式的去规范化(降低规范化提高查询效率)
将基本表划分为多张具有相同属性、结构完全相同的子表,子表包含的元
组是基本表中元组的子集。
例如,对商品按照商品的生产年份进行划分就属于水平划分。
将基本表划分为多张子表,每张子表包含的属性是原基本表的子集。
例如:商品表(商品编号、品名、单价、库存量、销售单件、备注)
可垂直划分为两张子表:
商品表(商品编号、品名、销售单价)
商品表(商品编号、单价、库存量、备注)
?
6.3 确定系统配置
DBMS产品一般都提供了一些存储分配参数
同时使用数据库的用户数
同时打开的数据库对象数
使用的缓冲区长度、个数
时间片大小
数据库的大小
装填因子
锁的数目.........
?
需要根据应用环境确定这些参数值
系统都为这些变量赋予了合理的缺省值。
但不一定适合每一种应用环境。
根据具体情况确定这些参数值以使系统性能最优。
6.4 物理模式评估
对数据库物理设计结构从存取时间、存储空间、维护代价等方面进行评估,
重点是时间和空间效率。
如果评价结果满足原设计要求则可进入到物理实施阶段,否则,就需要重新设计或修改
物理结构,有是甚至要返回逻辑设计阶段修改数据模型。
7 功能设计与实施
DBAS功能设计包括应用软件中的数据库事务设计和应用程序设计
功能设计过程一般被划分为总体设计、概要设计和详细设计。
而具体到数据库事务设计部分,又可分成事务概要设计和事务详细设计。
完成系统设计工作之后,就进入系统实现与部署阶段
7.1 软件架构与设计过程
1、软件体系结构与设计过程 DBAS
软件体系结构又称软件架构,软件体系结构={构件,连接件,约束}
软件体系结构是软件系统中最本质的东西。良好的体系结构 必须是普适、高效和稳定的。
软件体系结构有多种风格和类型,
如分层体系结构、模型-视图-控制器(MVC)体系结构客户端/服务器体系结构等。
2、软件设计过程
软件开发由设计、实现、测试三个环节组成,设计又包含概要设计和详细设计。
a .概要设计的任务是进行软件总体结构设计,可采用层次结构图建立软件总体结构图。
b .详细设计的任务是进行数据设计、过程设计及人机界面设计。
设计原则:模块化、信息隐藏、抽象与逐步求精。
软件设计可选用结构化设计方法、面向对象设计方法或面向数据设计方法等。
7.2 DBAS 总体设计
DBAS总体设计的任务是确定系统总体框架,主要内容包括
DBAS体系结构设计
软件体系结构设计
软件硬件选型与配置设计
业务规则初步设计
?
1、DBAS体系结构设计
将系统从功能、层次/结构、地理分布等角度进行分解,划分为各子系统,定义个子系统功能;
设计系统的全局控制,明确各子系统间的交互和接口关系。
两种常见的DBAS体系结构:
客户/服务器体系结构 (C/S) Client/Server
浏览器/服务器体系结构(B/S) Brower/Server
? 
2、软件体系结构设计
DBAS软件包括操作系统、数据库管理系统、开发环境、、中间件、应用软件(数据库事务和应用程序)
从需求分析出发分解成各子系统,分配相应功能,定义相互间交互机制,完成子系统结构设计,将各子系统从
功能上分成数据库事务模块(事务自身处理逻辑)与粒度大的应用该程序模块(业务规则),确定全局控制和调
用关系,可用模块结构图(模块+调用+数据+控制+转接)表示系统总体结构和分层模块结构。
3、软硬件选型与配置设计
规划分析阶段提出系统功能、性能及实现的约束对软硬件做了评估和选择建议;需求对系统功能性能提出了具体要求。为保证DBAS功能性能顺利实现,总体设计阶段需要对软硬件设备做出合理选择,并进行初步配置设计。
软硬件选型涉及的内容:
网络及设备选型;数据存储及备份方案;服务器选型;
终端软件环境;软件开发平台和语言、工具;
系统中间件及第三方软件选型。
4、业务规则初步设计
任务:从系统的角度,规划DBAS的业务流程,使之符合客户的实际业务需要。
DBAS的各项业务活动具有逻辑上的先后关系,可将它们表示成一个操作序列并用业务流程图表示。
7.3 DBAS功能概要设计
在总体设计结果基础上,将DBAS应用软件进一步细化为模块/子模块
组成应用软件的系统-子系统-模块-子模 块层次结构,并从结构、行为、数据三方面进行设计。
从功能角度,DBAS系统通常划分为四个层次实现:
表示层
业务逻辑层
数据访问层
数据持久层 索引设计
graph LR
F[按照功能角度划分]-.-A
A(("DBAS系统功能概要"))-->|表示层|人机界面设计
A-->|业务逻辑层|高内聚低耦合
A-->|数据访问层|事务概要设计
A-->|数据持久层|索引设计
1、表示层概要设计
人机界面设计,影响系统易用性。目前第四代是WIMP(窗口、图标、菜单、指示器)
与Web技术、多任务处理技术相结合。
设计原则:‘用户自主控制’;反馈及时上下文感知;容错与错误恢复;界面标准常规;输入灵活;
界面简洁交互及时... 简洁友好 容错率低
2、业务逻辑层概要设计
耦合是模块之间的,高内是模块内的
设计原则:高内聚低(松)耦合,即构件单一原则;构建独立功能;接口简单明确;
构件间关系简单,过于复杂,就细化,分解。
设计内容:结构,行为,数据,接口,故障处理、安全设计,系统维护和保障等。
3、数据访问层概要设计
任务:针对DBAS的数据处理需求设计用于操作数据库的各类事务。
事务概要设计核心在与辨识和设计事务自身处理逻辑,注重流程,不考虑与平台相关、具体操作方法和事
事务实现机制。
一个完整的事务概要设计包括事务名称、访问的关系表及其数据项、事务逻辑(事务描述)、事务用户
使用,启动、调用该事务的软件模块和系统)。
事务:事务(Transaction)是访问并可能是更新数据库中各种数据项的一个程序执行单元(unit)
事务的特性:原子性、一致性、隔离性、持续性。称为ACID特性。
- 原子性(atomicity)一个不可分割的工作单位。 要么全部执行,要么全不执行
- 一致性(consisitency)从一个一致性状态变成另一个一致性状态。
- 隔离性(isolation)执行不能被其他事务干扰。
- 持久性(durability)永久性(permanence)指一个事务一旦提交,对数据库中数据的改变就应该是永久性的。
4、数据持久层概要设计
属于数据组织与存储方面的设计内容,
7.4 DBAS功能详细设计
1、表示层详细设计
人机界面采用原型迭代法合适,三个步骤:
a.初步设计:设计人机交互命令系统并优化。(总体设计)
- 用户界面细节设计。如组织形式、风格、彩色,操作方式。(概要设计)
c.原型设计与改进(详细设计)
2、业务逻辑层详细设计
设计各模块内部处理流程和算法、具体数据结构、对外详细结构等。
7.5 应用系统安全架构设计
7.5.1 数据安全设计
安全性保护:防止非法用户对数据库的非法使用,避免数据泄露、篡改或破坏。
完整性保护:保证数据源的正确性、一致性和相容性。
并发性控制:保证多个用户能共享数据库,并维护数据一致性。
数据备份与恢复:系统失效后的数据恢复,配合定时备份数据库,不丢失数据。
数据加密传输:将一些高级的敏感数据通过一定的加密算法后传输。
a.数据库的安全性保护
主要保护方式:
用户身份鉴别: Windows身份验证、SQL身份验证。
权限控制
对后台数据库是不同用户对数据的不同存取需求设置不同权限;
对前台程序是为每个合法用户设定权限登记,外部用户设置有限查询功能。
视图机制: 通过视图机制把保密数据对无权用户隐藏。
b . 数据库的完整性保护
数据库的完整性指数据库中数据的正确性、一致性及相容性。
方法:设置完整性检查
即对数据设置一些约束条件(如实体完整性、参考完整性、用户自定义完整性)
完整性约束条件作用对象:列(类型、范围、精度、排序)、元组(记录中各属性之间的联系
约束) 、关系(若干记录间、关系集合与集合之间的联系)三种级别。
DBAS中,完整性约束功能包括完整性约束条件设置和检查。
c.数据库的并发性控制
并发访问(Concurrent Access):事务在时间上重叠执行。
对多用户并发存取同一数据的操作可能导致数据不一致,并破坏事务的隔离性,
因此DBMS必须提供并发控制机制,并发控制机制是衡量一个DBMS性能的重要标志之一。
实现数据库并发控制的常用方法是封锁技术。
所谓封锁,是指事务T在对某个数据对象(例如表、记录等)操作之前,先向系统发出请
求, 对其加锁,加锁后,事务T就对该数据对象有了一定的控制,在事务T释放它的锁之前,
其它的事务不能更新此数据对象
基本锁类型
排它锁(eXclusive lock,简记为X锁),写锁,若事务T对数据对象A加上X锁,则只允许
T读取和修改A,其它任何事务都不能再对A加任何类型的锁,直到T释放A上的锁.
排它锁保证了其它事务在T释放A上的锁之前不能再读取和修改A。
共享锁(Share lock,简记为S锁),读锁,若事务T对数据对象A加上S锁,则其它事务
只能再对A加S锁,而不能加X锁,直到T释放A上的S锁。
共享锁保证了其它事务可以读A,但在T释放A上的S锁之前不能对A做任何修改。
避免死锁
死锁是两个或两个以上的事务之间的循环等待。
设计避免死锁的原则:
(1)按照同一顺序访问资源。(如第一个事务提交或然后第二个事务进行)先来先服务
(2)避免事务交互性
(3)采用小事务模式,缩短长度和占用时间。 短事务优先
(4)尽量使用记录级别的所(行锁),少用表级别锁。
(5)使用绑定连接,同一用户打开的两个或多个连接可以互相合作。
d、数据库的数据备份与恢复
数据库恢复的基本原理:利用存储在系统其他存储器上的冗余数据(即数据备份)来重建。
数据库备份与恢复策略:
双机热备(基于Active/Standby方式的服务器热备) 有两台服务器同时运行,存储相同的据
数据转储(也称为数据备份)
数据加密存储(针对高敏感数据)
?
e 数据加密
数字安全证书
对称密钥加密数字
数字签名
数字信封
实施购买第三方中间件产品整合是一个快速有效的解决方案。
7.5.2 环境安全设计
环境安全设计漏洞与补丁:定期查找漏洞更新补丁
计算机病毒防护:杀毒软件;实时监控 ;
网络环境安全:防火墙;入侵检测系统;网络隔离(逻辑隔离与物理隔离) 防火墙
物理环境安全 :如防盗设施;UPS(电源,防止断电);温湿度报警器等
7.5.3 制度安全设计
管理层面安全措施
7.6 DBAS实施
DBAS实施阶段主要包括以下工作:
1、创建数据库考虑因素:
初始空间大小;
数据库增量大小;访问性能(如并发数,访问频率)
2、数据装载
步骤:筛选数据—转换数据格式—输入数据—校验数据
3、编写与调试应用程序
4、数据库系统试运行(功能测试与性能测试)
8 UML与数据库应用系统
8.1 DBAS建模
1 统一建模语言(UML)
英文全称为 Unified Modeling Language
UML是一种基于面向对象的可视化的通用(General)建模语言
UML只是一种建模语言,不是一种建模方法
- 建模语言:
- 建模过程
2 UML的组成
由语义(自然语言)和**表示法(**可视化标准符号)组成
元元模型 ——抽象
元模型——具体 元元模型与元模型是抽象和具体的关系,类似于类与对象的关系
模型层,UML的模型,类模型或类型模型
用户模型,UML模型的实例,对象模型或实例模型。
graph LR
X((UML组成))-->A[语义定义在一个四层建模概念框架中]
X-->Y[表示法]
A[语义]-->元元模型
A-->元模型
A-->模型层
A-->用户模型
UML的五种视图 结构、实现、行为、环境和用例视图
13种图(UML2.0):静态结构图和行为结构图
8.2 DBAS业务流程与需求表达
8.2.1 业务流程与活动图
描述系统或子系统的工作流程
活动图可以描述并行
注意:活动图只能有一个起点,但是可以有多个终点

8.2.2 系统需求与用例图
系统需求:用户心中的真正期望
用例模型是把满足用户需求的所用功能表示出来的工具
用例模型由用例、角色和系统三部分组成
? 系统:各种用例的“黑匣子”
角色:与系统交互的人或其他实体
用例:完整功能所有动作(一次操作)集合
注意:用例图是用例视图,不是行为视图
graph LR
A((用例模型))==>|用例|完整功能所有动作集合
A==>|角色|与系统交互的人或其他实体
A==>|系统|各种用例的黑匣子

角色之间的关系
通用化关系:指把某些角色的行为抽取出来作为通用行为,这些通用行为构成超类

用例与角色之间的关系
连接关系(关联,通信关联):表明那种角色能与该用例通信,是双向的一对一关系。

用例之间的关系
扩展: 一用例增加新内容成为另一个用例。 extends
包含(使用): 一个用例使用另一个用例。 include
关联(组合): 把相关用例打成包当作整体


8.3 DBAS 系统内部结构的表达
1 系统结构与类图
系统内部结构一般分为静态结构和动态结构。
在UML中,用类图来描述系统静态结构,用顺序图和通信图来表示系统动态结构。
类图主要表达的是问题领域的概念模型。
类图由类名、属性及操作组成。
graph LR
A((系统内部结构))-->|静态结构|B[类图]
B-->类名
B-->属性
B-->D["操作(方法)"]
A-->C[动态结构]
C-->顺序图
C-->通信图
类与类之间的关系
关联(聚集(共享聚集,组成或组合)),继承(或叫泛化),依赖,精化(或叫实现)


2 系统结构与顺序图
针对每一个特定用例,如何利用类图规范的对象来完成用例交付的任务,必须要利用顺序图
顺序图主要用于描述系统内对象之间的消息发送和接收序列。
顺序图中所有的元素,都必须在类图中存在。
强调时间上的先后顺序

3 系统结构与通信图
通信图是交互图的一种,也称为协作图。
通信图显示对象间组织交互关系和链接。不侧重交互顺序,用序列号来确定消息及其并发线程的顺序。
顺序图强调时间,通信图强调空间。
? 
8.4 DBAS系统微观设计的表达
1 微观设计与对象图
系统设计中,需要考虑细节部分。
UML中,对于细节方面的内容可用对象图、状态机图及时间图来表达、分析和
描述某个特定状况下系统的运作情况。
对象图是类图的实例,描述特定时间中所有对象在系统中的结构,是一个快照。

2 微观设计与状态机图
状态图用来描述有关事件或对象的状态转移。
状态图只能有一个起始状态,可有多个结束状态。
状态间的转移由事件驱动

3 微观设计与时间图
当状态的转换由时间因素决定时,使用时间图来描述状态的变化。
描述时间驱动的状态转换,即当状态维持多少时间后转移。
时间图中,整个矩形框就是一个生命线。

8.5 DBAS系统宏观设计的表达
1 宏观设计与包图
宏观设计指将涉及的焦点放在研究比较大范围中的元素之间的联系,如包、命名空间、子系统等。
这里的包表示盘符,命名空间表示文件夹,子系统表示源代码
一个良好的命名空间,便于开发人员理解,并使得各个命名空间之间能够松耦合,
而命名空间内则可满足高内聚的要求。
包图表示系统中不同包、命名空间或不同项目间的彼此关系。也就是逻辑层次上与实体层次上的关联性。

2 宏观设计与交互概述图
是将活动图和顺序图嫁接在一起的图 。
以活动图为基础,在控制流间连接交互图,从而将所有交互图关系呈现出来。
交互概述图可以把不同的交互图结合在同一张图中来表达。


3 宏观设计与复合结构图
外部系统的整合关系着项目的成败。
在项目开始前,最好将待开发的系统与外部系统的关系做一个初步的定义。
复合结构图适用于系统间的沟通接口,适合做构架师在初期阶段评估系统复杂度的工具,也可以是系统维护的参考图。

8.6 DBAS系统实现与部署的表达
1 系统实现与组件图
组件图用来表示系统的静态实现视图。
用来展现一组组件间的组织和依赖,用于对源代码、可执行的发布、物理数据库等的系统建模。
组件是逻辑设计中定义的概念和功能在物理构架中的实现。

2 系统实现与部署图
部署图又叫配置图,描述系统中硬件和软件的物理配置情况与系统体系结构。
部署图说明实体组件,如可执行程序,将如何部署到实际的计算机中。
部署图要在项目进行集成测试前提供

9 数据库及数据库对象
9.1 创建及维护数据库
SQL Server将数据库映射为一组操作系统文件:
1 SQL Server中数据库的分类
系统数据库(自动创建)
master :所有系统级信息,元数据、端点、连接服务器
msdb:代理服务调度报警和作业、记录操作员时使用保存
tempdb:用于保存临时对象和中间结果,每次启动会重置 备份数据库是无须保存
model :所有数据库的模板,存放用户数据库公共信息
esource:只读数据库。在对象资源管理器中看不到。
用户数据库(保存于用户业务有关的数据)
graph LR
A((SQL Server))===B["系统数据库"]
B-->|master|所有系统级信息
B-->|msdb|日志
B-->|tempdb|保存临时对象
B-->|model|模板
B-->|esource|只读数据库
A==>C[用户数据库]
C-->用户业务相关数据
9.2 SQL Server 数据库的组成
SQL Server 将数据库映射为一组操作系统文件【持久】
数据文件
主要数据文件 .mdf :只有一个,大小不得小于3mb
次要数据文件 .ndf :有0个或多个,可在一个或多个磁盘存放
日志文件 .ldf :事务日志文件 。 至少有一个日志文件。
数据库存储空间的分配
创建用户数据库时,model数据库被自动复制到新建库
数据存储的最小单位,数据页(Page,简称页 )
1页是一块8KB的连续磁盘空间
页的大小决定了数据库表中一行数据的最大大小。行不能跨页存储。
\[例:一个数据表10000行数据,每行3000字节,计算表需要的存储空间。\答案:10000/2*8KB=40MB\空间利用率75%\\]
9.3 数据库文件组
两种类型的文件组
主文件组(PRIMARY)
系统定义,包括主要数据文件和任何没有明确分配的其他文件组的其他数据文件,
系统表所有页均分分配在主文件组中。
用户定义文件组
在定义或修改数据库是用FILEGROUP
关键字指定。
9.4 数据库文件的属性
定义数据库的数据文件和日志文件所需信息:
文件名及其位置
逻辑文件名,物理文件名(硬盘上)
初始大小 不能小于model数据库主要数据文件的大小
增长方式
可指定文件是否自增长(默认)
最大大小
文件增长的最大限制。默认无限制
9.5 用T-SQL创建数据库
创建数据库一般有两种方式:
通过SQL Server Managerment Studio 创建数据库
通过T-SQL语句创建数据库
CREATE DATABASE databaseName
[ ON --指定创建的数据库主文件(mdf)存放的路径比如 e:\Studentdb.mdf
[<filespec> [, … n] ]
[, <filegroup> [,…n] ]
]
[LOG ON {<filespec> [,…n]}]
[COLLATE collation_name] --指定创建的数据库日志文件(ldf)存放的路径比如e:\Studentdb_log.ldf
[FOR LOAD| FOR ATTACH]
说明
PRIMARY :指定为主要数据库文件,没有指定默认第一个文件是主要数据文件。
LOG ON :自动创建日志文件,大小为数据文件总和25%或512KB中大的。
NAME :逻辑文件名,唯一。
FILENAME :物理文件名。
SIZE:初始大小,.mdf大小不小于model,.ndf默认为1MB
MAXSIZE:最大大小,未指定则文件自动增长到磁盘满。
UNLIMITED :增长无限制,一般指定为日志文件2TB,数据文件16TB.
FILEGROWTH:指定文件自动增量,不超过MAXSIZE.默认数据文件1MB,日志文件为当前文件的10%。
FILEGROUP :文件组逻辑名,唯一,不能是系统名。
DEFAULE :指定该文件组为默认文件组。

9.6 修改数据库
扩大数据库空间
扩大数据库中已有文件的大小
为数据库添加新的文件
收缩数据库空间
即释放数据库中未使用的空间,文件的收缩从末尾开始
自动收缩:AUTO_SHRINK
, 默认false。
手工收缩:收缩数据库中某个文件大小;
? 按比例收缩整个数据库大小。
添加和删除数据库文件
?
-- 修改数据库
ALTER DATABASE database
{ ADD FILE < filespec > [ ,...n ] [ TO FILEGROUP filegroup_name ]
| ADD LOG FILE < filespec > [ ,...n ]
| REMOVE FILE logical_file_name
| ADD FILEGROUP filegroup_name
| REMOVE FILEGROUP filegroup_name
| MODIFY FILE < filespec >
| MODIFY NAME = new_dbname
| MODIFY FILEGROUP filegroup_name {filegroup_property
| NAME = new_filegroup_name }
| SET < optionspec > [ ,...n ] [ WITH < termination > ]
| COLLATE < collation_name > }
扩大指定文件的大小:
ALTER DATEBASE STU_DB
MODIFY FILE (NAME=student_data, SIZE=8MB)
添加新的数据文件:
ALTER DATABASE STU_DB
ADD FILE (NAME=student_data2,
FILENAME = 'E:\Data\student_data2.ndf' ,SIZE=6MB,FILEGROWTH=0)
收缩整个数据库的大小
DBCC SHRINKDATABASE
收缩指定文件的大小
DBCC SHRINKFILE
例1:DBCC SHRINKDATABASE(students,20)
收缩数据库,该数据库所用文件都有20%可用空间
例2:DBCC SHRINKFILE(students_data1,4)
收缩数据库到4MB大小
删除数据库文件:
ALTER DATABASE STU_DB
REMOVE FILE student_log1
注意:
添加文件时,每个文件组中的数据文件
按比例填充,日志文件时依次增加的。
文件为空才能删除
9.7 分离和附加数据库
分离数据库
作用:实现将数据库从一台数据库服务器移到另一台,不需要重建。
从实例中删除,不删除数据文件和日志文件,保持了数据文件和日志文件完整一致。
使用 sp_detach_db
系统存储过程实现
如:
EXEC sp_detach_db‘student’,‘true’
附加数据库
将分离的数据库重新附加到数据库管理系统中。
必须指定主要数据文件的物理存储位置和文件名。
CREATE DATABASE ……
FOR ATTACH|ATTACH_REBUILD_LOG
例:
CREATE DATABASE students
On(FILENAME=‘F:\Data\Students_data1.mdf’)
FOR ATTACH
9.2 架构
架构(Schema,也称模式),是数据库下的一个逻辑命名空间,是数据库对象的容器,一个数据库包含一个或多个构架,同一个数据库内架构名唯一。
定义构架
CREATE SCHEMA [<构架名>]
AUTHORIZATION<用户名>
删除构架
DROP SCHEMA [<构架名>]
9.3 分区表
分区表是将表中的数据按水平分割成不同子集,并将数据子集存储在数据库一个或多个文件组中。
物理上将大表分成几个小表,逻辑上还是一个大表。
合理使用分区能提高数据库性能。
1 创建分区的因素
是否创建分区取决于表当前数据量大小,以及将来数据量,还取决于表中数据的操作特点。
表包含(或将包含)以多种不同方式使用的大量数据
数据是分段的,比如以年份分隔。
2 创建分区表
三个步骤:
(1)创建分区函数:告诉DBMS以什么方式进行分区
CREATE PARTITION FUNCTION
(2)创建分区方案:作用是将分区函数生成的分区映射到文件组中
CREATE PARTITION SCHEME
(3)使用分区创建表
实例1:
在分区列coll(int)上创建左侧分区函数:
CREATE PARTITION FUCNTION myPF1(int)
AS RANGE LEFT FOR VALUES(1,100,1000);
分区 |
1 |
2 |
3 |
4 |
值 |
col1<=1 |
col1>1 AND col1<=100 |
col1>100 AND col1<=1000 |
col1>1000 |
后序
1 相关概念问题
列 == 属性 == 属性名
一行数据 == 一条记录 == 一个元组
?
?