计算机三级数据库
Posted 364.99°
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了计算机三级数据库相关的知识,希望对你有一定的参考价值。
目录
- 1.数据库应用系统开发方法
- 2.需求分析
- 3.数据库结构设计
- 4.数据库应用系统功能设计与实施
- 5.UML与数据库应用系统
- 6.高级数据查询
- 7.数据库及数据库对象
- 8.数据库后台编辑技术
- 9.安全管理
- 10.数据库运行维护与优化
- 11.故障处理
- 12.备份与恢复数据库
- 13.大规模数据库架构
- 14.数据仓库与数据挖掘
1.数据库应用系统开发方法
选择、填空出现
1.1.数据库应用系统生命周期
1.1.1. 数据库简介
- 数据库(DB):存储数据的容器,存储了一系列有组织的数据
- 数据库系统(DBS):主要提供应用数据的组织、存储、维护、访问等数据管理功能。
- 数据库管理系统(DBMS):用于管理DB中的数据
分类:基于共享文件系统的DBMS
基于客户机-服务器的DBMS(mysql、Oracle、Microsoft SQL Server)
- 数据库管理员(DBA)
- 数据库应用系统(DBAS):
功能:为用户提供数据管理功能
根据具体的应用领域业务规则、通过数据库应用程序,实现更为复杂的数据处理功能。
DBAS的生命周期的基本活动:
描述:一类典型的面向数据管理和数据处理的复杂软件系统,其设计开发满足实际应用需求,遵循数据库系统三级模式结构所规定的数据库设计范型。
方法:按软件工程定义的复杂软件系统开发原则,采取工程化方法,按计划、分步骤地进行。
目的:保证系统开发质量、降低开发成本、加快开发进度
1.1.2. 软件工程与软件开发方法
2.1. 软件工程思想:用工程的概念、原理、技术和方法对软件生产、开发的全过程进行跟踪与管理
2.2. 软件工程开发的目的:提高软件的质量、加快软件开发的速度、降低成本
2.3.典型方法:瀑布模型(软件过程模型或生命周期模型 6个阶段)—— 逻辑严谨但难以修改
快速原型模型—— 开发快速,可修改性但是会导致分析不完善导致整个模型没有实用价值
螺旋模型(结合前两个模型的有点 4个阶段)—— 有效降低了大型项目实施过程因成本进度质量等因素的不确定性带来的风险但对开发人员评估风险的经验要求较高
1.2.规划与分析
1.2.1.系统规划与定义
面向要开发的DBAS,通过了解用户实际需求,明确该系引用需要实现的目标和任务,并从数据管理和数据处理的角度,确定系统中数据库软件的功能、性能范围
系统规划与定义设计内容:
- 任务陈述:描述要开发的DBAS的总体目标
- 确定任务目标:为了实现总体目标,DBAS应该支持的一系列数据管理和数据处理任务与活动
- 确定系统范围和边界:定义DBAS做什么、不做什么、做到什么程度
- 确定用户视图:对用户进行分类,明确每类用户需要访问数据库中的哪些数据以及如何使用这些数据,组成用户所对应的用户视图
1.2.2.可行性分析
在明确了DBAS的任务目标和系统范围之后,要进行可行性分析,评估判断DBAS的可行性
四点:
- 经济可行性研究:成本效益分析
- 技术可行性研究:根据用户需求,对系统硬件和技术方案做出评估和选择
- 操作可行性研究:对人员资源、软件资源、硬件资源和工作环境等进行探讨、优化
- 开发方案选择的目标:提出并评价开发方案,并选择最佳方案
DBAS成本划分:
- 系统软硬件购置费用(DBAS、计算机、存储设备、网络设备的购置费用)
- 系统开发费用(人工费用、材料费用、成本费用等)
- 系统安装、运行、维护费用等
1.2.3.项目规划
项目管理者对资源、成本和进度做出合理估算,并在此基础上制定切实可行的DBAS项目开发计划的过程
项目规划工作内容:
- 确定项目的目标和范围,根据系统规划与定义的工作内容,具体说明项目的最终产品以及期望的时间、成本和质量目标
- 根据DBAS的软件开发模型,分解和定义整个项目包括的工作活动和内容
- 估算完成该项目的规模以及所需各种资源
- 制定合理的DBAS项目计划、包括进度、成本、质量等方面的预测和控制方案
1.3.需求分析
1.3.1.数据需求分析
从对数据库进行组织和存储的角度,从用户视图触发,分析与便是应用领域所管理的各类数据项和数据结构,构成 数据字典 的主要内容
数据字典:
1.3.2.功能需求分析
主要针对DBAS应具有的功能进行分析,是DBAM需求分析的核心缓解,描述了一个系统应该做什么
分析类别
- 数据处理需求分析:从数据访问和处理的角度,明确对各类数据项所需进行的数据访问操作,分析结果可表示为数据流图(DFD)或DBAS应支持的各种数据处理事务规范
- 业务规则需求分析:从DBAS高层目标和整体功能出发,分析系统/子系统赢具备的业务类型和功能,明确用户或外部系统与DBAS的交互模式
数据处理需求分析
1.3.3.性能需求分析
性能需求分析描述了系统应当做到什么程度
DBAS性能指标:
- 数据库操作响应时间
指用户向数据库系统提交数据操作请求到操作结果返回给用户的时间- 系统吞吐量
指系统在单位时间内可以完成的数据库事务或数据查询的数量
系统吞吐量可以表示为事务数/每秒 TPS- 允许并发访问的最大用户数
指在保证单个用户查询响应时间的前提下,系统最多允许多少用户同时访问数据库- TPS代价值
用于衡量系统性价比的指标
影响DBAS性能指标的因素:
- 系统的硬件资源
- 网络通信设备性能
- 数据库的逻辑设计和物理设计质量
- DBAS的配置和性能
- 数据库应用程序自身
1.4.系统设计
根据DBAS生命周期模型,数据库应用系统设计包括概念设计、逻辑设计、物理设计
1.4.1.概念设计
包括数据库 概念模型设计 和 系统总体设计
数据库概念模型设计
依据数据需求分析阶段的得到的需求规范说明文档,常用ER方法
系统总体设计
一个大型数据库应用系统是由硬件和软件组成的复杂系统,在设计上依据 自上而下、由简到繁、逐步求精 的原则
系统总体设计的内容:
- DBAS体系结构设计
- DBAS系统硬件平台的选型和配置
- 应用软件结构设计
- 对系统采用的关键技术进行方案选型和初步设计
- 对需求分析阶段识别出的业务规则进行初步设计,细化业务规则流程,分析所处理的业务数据和处理方式,明确采用的关键技术和算法等
1.4.2.逻辑设计
包括三个方面
三个方面:
- 数据库逻辑结构设计
从数据库的概念模型出发,设计表示为逻辑模式的数据库逻辑结构- 应用程序概要设计
按照逐步求精、信息隐藏和功能细化原则,进一步划分为子模块,组成应用软件的系统-子系统-模块-子模块层次结构- 事务概要设计
根据需求分析阶段识别出的各种DBAS事务,设计与具体DBAS和实现方法无关的事务数据处理流程,明确事务所访问的个关系表
1.4.3.物理设计
- 数据库物理结构设计
数据库中的数据以文件形式存放在外存物理设备上,数据库物理结构主要指数据文件在外存上的存储结构和存取方法,她依赖于系统具体的硬件环境、操作系统和DBAS- 数据库事务详细设计
将事务概要设计中的read和write操作替换为DBAS支持的增删查改等具体数据库访问操作或数据库访问API调用- 应用程序详细设计
定义的各模块和功能和输入/输出数据需求,结合具体的程序设计环境和机制,设计各模块的内部处理流程和算法、数据库结构、对外详细接口等
1.5.实现与部署(DBAS的实施)
DBAS的开发人员根据DBAS设计结果,建立数据库、编写应用程序、集成DBAS硬件,组成完整的DBAS。系统经测试和试运行,经过验证,在功能、性能等方面达到设计要求之后,可以交付用户使用。
工作内容:
1.6.运行管理与维护
主要包括日常维护、监控与分析、性能优化调整、系统进化
- 日常维护
备份与恢复、完整性维护、安全性维护、存储空间管理、并发控制- 监控与分析
数据采集与统计、操作分析、基准程序评估- 性能优化与调整
查询调整与优化、索引调整、事务调整、模式调整、参数调整、硬件调整和升级、应用程序优化- 系统进化
应用程序升级、数据库重组、DBMS和OS升级
2.需求分析
2.1.需求分析概述
2.1.1.简介
- 概念
对待开发的系统要做什么,完成什么功能的全面描述
- 具体工作
对需求调查、了解、观看和分析,对原始资料进行加工整理,得到有关目标系统需要实现的功能及其相互关系等一系列活动的集合
- 目标
以使用者和开发人员都容易理解的文档形式提供一个关于目标系统所完成的全部功能及性能等需求的完整描述,为最终开发出一个满意度搞得系统打下基础
- 软件产品的一些特征需求获取面临的困难
- 需求的可变性
- 软件功能复杂
- 软件产品的不可见性
- 主要任务
分析清除当前系统的与业务流程,包括系统的体系结构,各职能部门完成的主要任务,各职能部门之间的关系及其交流的信息
- 存在的问题
分析清除现行系统存在的问题,包括需要解决的问题
- 最终的结果
以模型形式展示,如DFD图,IDEF0图等建模工具和方法描述系统的信息流、功能结构及完成各功能需求的数据
- 基本的要求
需求描述要准确、清除、已知、不存在任何不完全、含混或者二义性的描述
2.1.2.获取需求的方法
查阅资料、问卷调查、实地观察、面谈
2.1.3.需求分析的过程
建立和开发应用信息系统或软件产品的基础
需求获取的过程及需求分析阶段的工作内容
- 标识问题
- 建立需求模型
- 描述需求
- 需求确认
2.2.需求分析方法
2.2.1.需求分析方法概述
目前在信息系统的需求分析中广为使用的结构化分析与功能建模方法主要有DFD、IDEF0等
优点:
- 不过早陷入具体细节
- 从整体或宏观入手分析问题,如业务系统的总体结构、系统及子系统的关系
- 通过图形化的模型对象直观的表示系统要做什么,完成什么功能
- 图形化建模方法方便系统分析员理解和描述系统
- 模型对象不涉及太多技术术语,便于用户理解模型
2.2.2.DFD需求建模方法
- DFD方法的基本元素
- DFD建模方法,又称过程建模和功能建模方法,核心是数据流,从应用系统的数据流着手以图形方式刻画和表示一个具体业务系统中的数据处理过程和数据流
- DFD方法有四种基本元素(建模对象)组成:数据流、处理、数据存储和外部项
- DFD图
DFD采用自项向下逐步细化的结构化分析方法来表示目标系统。有顶层图分解出下一层,然后再细分,直到每项功能活动都是具体的、可操作的,用一个程序模块可以实现其功能为止
- DFD的建模过程
建立DFD图的目的是描述系统的功能需求,其步骤:
- 明确目标,确定系统范围
- 建立顶层DFD图
- 构建第一层DFD分解图
- 开发DFD层次结构图
- 检查确认DFD图
检查和确认DFD图的规则
- 父图中描述过的数据流必须在相应的子图中出现
- 一个处理至少有一个输入流和一个输出流
- 一个存储必定有流入的数据流和流出的数据流
- 模型图中表达和描述的信息是全面的、完整的、正确的和一致的
层次结构图中的上一层是下一层的抽象,下一层是上一层的求精和细化,而最后一层中的每个处理都是具体的面向一个具体实现的描述,即一个处理模块仅描述和解决一个问题
2.2.3.其他需求建模方法
IDEF系列描述:最常使用的是IDEF0~IDEF4
IDEF0 | IDEF1 | IDEF1x | IDEF2 | IDEF3 | IDEF4 | IDEF5 | IDEF6 | IDEF7 | IDEF8 | IDEF9 | IDEF10 | IDEF11 | IDEF12 | IDEF13 | IDEF14 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
功能建模 | 信息建模 | 数据建模 | 仿真建模设计 | 过程描述获取 | 面向对象设计 | 本体论描述获取 | 设计原理获取 | 信息系统审定 | 用户界面建模 | 场景驱动信息系统设计 | 实施体系结构建模 | 信息制品建模 | 组织建模 | 三模式映射设计 | 网络规划 |
IDEF0建模方法
- 组成基本元素:矩形框与箭头
- 矩形框:功能活动,写在矩形框内的动词短语描述功能活动的名称
- 活动的编号按照要求写在矩形框右下角指定的位置
IDEF0层次结构
- IDEF0的基本思想是结构化分析,强调自项向下有控制地逐步地展开细节,精确、准确、全面地描述系统,通过建模过程与建模来理解一个系统
- 模型由图形、文字说明、词汇表及相互的交叉引用表组成,图形是其主要成分
2.2.4.DFD与IDEF0比较
相同点
- 基础都是结构化分析思想
- 强调用自项向下逐步求精的方法建模
不同点
- 箭头(数据流):都是用来描述数据流,但DFD强调流或顺序,IDEF0强调数据约束
- 表达形式:DFD用箭头和处理来表达出数据流,IDEF0用箭头表达数据流,控制流和说明处理或活动实施方式的一些约束
- 模型元素组成:DFD由外部项、数据流、数据存储和处理组成,IDEF0由箭头和活动组成
3.数据库结构设计
选择题与设计题
3.1.数据库概念设计
3.1.1.概念设计的任务
主要解决数据需求:如何准确地理解数据需求,真实地吧应用领域重要处理的数据组织、定义描述清除,以支持数据库设计后续阶段的工作
数据库概念设计阶段目标
- 定义和描述应用领域涉及的数据范围
- 获取应用领域或问题域的信息模型
- 描述清除数据的属性特征
- 描述清楚数据之间的关系
- 定义和描述数据的约束
- 说明数据的安全性需求
- 支持用户的各种数据处理需求
- 保证信息模型方便地转换成数据库的逻辑结构(数据库模式),同时也便于用户理解
3.1.2.概念设计的依据和过程
依据:需求分析阶段的文档
包括:需求说明书、功能模型(数据流程图或IDEF0图),在需求分析阶段收集到的应用领域或问题域中的各类报表等
过程
- 明确建模目标
- 定义实体集
- 定义联系
- 建立信息模型
- 确定实体集属性
- 对信息模型进行集成与优化
3.1.3.数据建模方法
ER模型:面向数据存储需求建模,仅从存储秀描述数据的属性特征及数据之间的关系
实体或实例:指客观存在并可相互区分的事物(也称实体集实例或实例),如某个具体的人
实体集:表示一个现实的和抽象事物的集合,这些事物必须具有相同的属性或特征,如无产阶级
属性:描述一个实体集的性质和特征,如阶级的财产,社会地位
码:实体集中能唯一标识每一个实例的属性或属性组,如人的身份证号
联系:现实世界中实物之间的关系,如人A是人B的爹,有三大类:一对一(1:1)一对多(1:n)多对多(m:n)
ER建模方法
基本元素:
IDEF1x建模方法:侧重分析、抽象和概括应用领域中的数据需求,被称为数据建模方法
IDEF1x建模元素:实体集、联系
实体集:
- 独立标识符实体集或独立实体集:一个实体机的每个实例都能被唯一的标识而不决定于它与其他实体集的联系
- 从属标识符实体集或从属实体集:实体集的一个实例的唯一依赖于该实体集与其他实体集的联系
IDEF1x中,每一个实体集定义有唯一的名字和编码,名字与编码之间用 / 写在矩形框的上方,编码为正整数
联系:实体集之间的一种连接或关系
分类:
- 标定型联系:子女实体集必须确认双亲实体集
- 非标定型联系:子女实体集都能唯一被确认,而不需要知道双亲实体集
- 分类联系:在不同的情况下,分为不同的类别
- 非确定联系:无法相互确定
3.2.数据库逻辑设计
3.2.1.概述
- 依据:信息模型和数据库概念设计说明书(用户确认数据需求的依据)
1.1. 概念模型
1.2. 数据处理要求
1.3. 数据的约束及安全性要求
1.4. DBMS的相关信息 - 任务:将数据库概念设计的结果(ER),转换为具体的数据库管理系统支持的数据模型
- 阶段目标:DBMS可处理的模式、数据库物理设计指南
- 面向机器世界的
3.2.2.逻辑设计步骤
- 将ER图转换成关系模式
1.1. 表示ER模型中的联系
1.2. 依次转换每个联系相关联的实体集及联系 - 命名确认:根据项目选定的数据库管理系统支持的命名规则,检查确认关系名与属性名是否符合同一命名规则
- 优化关系模式:应用规范化理论逐一检查每一个关系模式,是指满足3NF
3.2.3.关系模式转换
- 转换准则:
二元关系模式:
1.1:1 两个实体任选一个添加另一个实体的主键即可
2. 1:N 在关系N端添加另一端的主键
3. M:N 在联系实体上添加M端N端的主键,然后加上联系实体自身的属性
三元关系模式:
- 1:1:N:当转换为关系模型时,将N端添加另外两端的主键即可
- M:N:P:再联系实体上添加M端N端P端的主键,然后加上联系实体自身的属性
- 转换案例:
将学生实体和课程实体关系的E-R图转换为数据库关系模式
学生和课程之间是多对多的关系,需要转化,引入联系实体:成绩表
课程(课程代号,课程名称),主键:课程代号
学生(学号,姓名,年龄),主键:学号
成绩表(学号,课程代号,成绩),复合主键(学号,课程代号)
3.2.4.范式
范式是符合某一种级别的关系模式的集合。关系数据库中的关系必须满足一定的要求,满足不同程度要求的为不同范式。
- 第一范式(1NF)
在任何一个关系数据库中,第一范式(1NF) 是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库
- 概念:指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性
- 如下图,研究生有两个值,不属于第一范式
- 第二范式(2NF)
在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)
- 概念:每个表必须有且仅有一个数据元素为主关键字,其他数据元素与主关键字一一对应(函数依赖关系),即表中其他数据元素都依赖于主关键字
- 规则:要求实体的属性完全依赖于主关键字,如果一个数据表的主键只有单一一个字段,它就符合2NF
- 2NF案例:其他属性都依赖于订单编号这一主键
- 第三范式(3NF)
- 概念:满足第三范式(3NF) 必须先满足第二范式(2NF)。简而言之,第三范式(3NF)表中所有数据元素不但要能唯一地被主键标识,且要求一个数据库表中不包含已在其它表中已包含的非主关键字信息,即相互独立
实体的转换:从ER图转换为关系模式时,一个实体就能转换成一个关系模式,实体的属性就是关系模式的属性,实体的键就是关系的主键
实体间联系的转换:实体间存在三中联系(1:1 1:N M:N),M:N可以转换为单独的模式,1:N需要合并到实体中
3.3.数据库物理设计
3.3.1.概念
- 通过数据库概念设计和逻辑设计已得到规范化的关系模式(3NF),数据库物理设计的目的是将数据的逻辑描述转换为实现技术规范,其目标是设计数据存储方案,以便提供足够好的性能并确保数据库的完整性、安全性和可恢复性。
- 此阶段,将根据数据库中存储的数据量、用户对数据库的使用要求和使用方式,选择数据存储方案以加快数据检索速度。
- 需要了解不同文件组织方式、索引技术及其使用方法
3.3.2.数据库的物理结构
- 数据库中的应用数据是以文件形式存储在外设存储介质(如磁盘)上,文件在逻辑上被组成记录的序列——每个DB文件可以看做是逻辑记录的集合
- 物理文件可以看做是由存放文件记录的一系列磁盘块组成,文件的逻辑记录与磁盘块间的映射关系是由操作系统或DBMS来管理的
- 从数据库物理结构角度需要解决的问题
3.1. 文件的组织
3.2. 文件的结构
3.3. 文件的存取
3.4. 索引技术
3.3.3.索引
- 索引技术
索引技术(Indexing)是一种快速数据访问技术,将一个文件的每个记录在某个或某些域上的取值与该记录的物理地址直接联系起来,提供一种根据记录域的取值快速访问文件记录的机制
索引技术的关键是建立记录域取值到记录的物理地址间的映射关系
- 索引技术分类
两大类:有序索引(Ordered Index)、散列索引(Hash)
- 散列索引:只适合点查询
1.1. 散列技术,也称哈希(Hash)索引机制
1.2. 利用一个散列函数(HashFunction)实现记录域取值到记录物理地址间的直接映射关系
1.3. 记录域就是查找码,也称为散列函数的散列域或排序域
- 有序索引:数据文件和索引文件是有序索引技术中的两个个体,数据文件也被称为索引文件或主文件
2.1. 有序索引作为基于索引文件的索引技术,需要考虑两个问题:
①如何组织索引文件中的索引技术
②如何从索引文件出发,访问数据文件中的数据记录
2.2. 索引文件的建立方法:
①选定数据文件中的某个或某些记录作为查找码
②建立数据记录在查找码上的取值与该记录的物理地址间的映射关系,组成索引项
③索引文件根据某特定的查找码值的升/降序存储索引记录,并且组织为顺序文件
一个数据文件可以有多个查找码和多个索引文件
数据文件中存储了关系模式为R(A,B,S,…D)的关系表的元组数据
2.3. 类别和特点
①聚集索引(Clustering Index)和非聚焦索引(Non-clustering Index)
聚焦索引:数据文件中数据记录的排列顺序与索引文件中索引项的排列顺序相一致,一个表只能有一个聚集索引
非聚焦索引:…不一致,一个表可以有多个非聚集索引
②稠密索引与稀疏索引
稠密索引:数据文件中每个查找码值在索引文件中都对应一个索引记录
稀疏索引:只是一部分查找码的值有对应的索引记录
③主索引与辅索引
主索引:主码属性集上建立的索引
辅索引:非主属性上建立的索引
聚集、稠密、辅索引如图:
非聚集、稠密、主索引如图:
④唯一索引
确保索引列不包含重复的值
⑤单层索引和多层索引
单层索引(线性索引):索引项根据键值在索引文件中顺序排列,每个索引项直接指向数据文件中的数据记录
多层索引:可以建立多层树型索引结构来快速定位大数据量文件中的数据记录,如B树和B+树索引
当数据文件很大时,可以对索引文件中的索引项本身再建立一级稀疏索引,组成二层索引结构,用于快速查找索引项
建立索引会加快查找效率,但会降低增、删、改效率
3.3.4.物理设计内容
数据库物理结构设计是在具体的硬件环境、操作系统和DBMS约束下,根据数据库逻辑设计结果设计合适的数据库物理结构。其目标是得到存储空间占用少、数据访问效率高和维护代价低的数据库物理模式。
数据库物理设计环节
- 数据库逻辑模式描述
- 文件组织与存取设计
- 数据分布设计
- 确定系统配置
- 物理模式评估
- 数据库逻辑模式描述
1.1. 数据库逻辑设计产生了数据库的逻辑结构,其中有数据库的关系模式、关系模式上的完整性约束和面向具体应用的业务规则。这些内容都是独立于DBAS所采用的具体目标DBMS平台的。
1.2. 数据库物理设计需要根据数据库逻辑结构信息设计目标DBMS平台可支持的关系表(这里称为基本表)的模式信息,这些模式信息代表了所要开发的具体目标数据库的结构。
设计内容:
- 面向目标数据库描述基本表和视图
- 采用目标DBMS所支持的建表语法,描述基本表及满足应用要求的完整性约束。设计基本表业务规则
- 利用目标DBMS提供的完整性控制机制设计基本表应遵守的面向应用的完整性约束
- 文件组织与存取设计
2.1. 为了进行有效地数据库文件组织和存取路径设计,必须分析和理解数据库事务的数据访问特性
分析步骤:
- 使用事务-基本表交叉引用矩阵
- 估计各事务的执行频率
- 对每张基本表,汇总所有作用于该表上的各事务的操作频率信息
事务-基本表交叉引用矩阵:
根据是无数据访问特性分析结果,可以将基本表设计成更为有效的文件组织和索引方式
数据库文件结构
- 堆文件:使用表中数据很少,且插入、删除、更改等操作非常频繁
- 顺序文件:支持基于查找码的顺序访问,也支持快速的二分查找,适合用户的查询条件定义在查找码上
- 聚集文件:适合某些频繁执行且需要进行多表连接操作的查询
- 索引文件:适合用户查询是基于散列域值的等值匹配,特别是访问顺序是随机,不适合基于散列域值的非精确查询与基于非散列域进行的查询
- 散列文件:适合定义在数据量基本表上,基于查找码的等值查询、范围查询、横糊查询和部分查询
- 涉及存储路径时索引的设计原则
3.1. 设计索引时,必须权衡考虑索引的优点与索引的维护代价
基本表建立索引的原则
- 对于经常需要进行查询、连接、统计操作,且数据量大的基本表可考虑建立索引
- 而对于经常执行插人、删除、更新操作或小数据量的基本表应尽量避免建立索引
- 一 个基本表上除了可以建立一 个聚集索引外。还可以建立各个非聚索引
- 索引可以由用户根据需要随时创建或删除,以提高数据查询性能
基本表可以在一些属性上建立索引
1.表的主码 2.在WHERE查询子句中引用率较高的属性 3.参与连接操作的属性
4.在Ordere By子句、Group By子句中出现的属性 5.在某一范围内频繁搜索的属性
6.如果在WHERE子句中同时包含一个表中的多个属性 7.当一个属性有相对较多的不同值时可以使用索引
8.包含大量空值的属性建立索引是要仔细考虑
- 数据分布设计
4.1. 不同类型数据的物理分布
数据库系统中不仅有组织为基本表的应用数据,还有索引、8志数据库备份数据等其他类型数据。各种数据在系统中的作用不同,使用频率也不一样,根据实际使用情况存放在合适的物理介质上,以优化系统I/O性能。
4.2. 应用数据的划分与分布
为改善大数据量基本表的访问性能,将基本表划分为若干分区,各分区数据分别存储在不同位置的磁盘上,并采用不同物理组织方式。
4.3. 派生属性数据分布
基本表中的派生属性是指该属性的取值可根据表中其他属性的取值唯一确定。 对带有派生属性的基本表可以采用如下两种实现方式。
4.4.关系模式去规范化
在数据库物理设计阶段,可以根据实际需要对数据库中某些3NF、BCNF模式考虑是否可以降低其规范化程度,提高查询效率
不同类型数据的物理分布
- 数据库备份文件、日志文件备份数据用于故障恢复,使用频率低,而且数据量很大,可以存储在磁带中
- 应用数据、索引和日志则应用数据、索引和日志则使用频繁,要求的响应时间短,必须放在支持存取的磁盘存储介质上
基本表划分的原则
- 根据数据库中的使用特征划分:可以根据数据使用的频家将基本表分为频繁使用分区和非频繁使用分区.分别存储在不同的磁盘上。对于频来使用分区中的数据可以考虑建立B+树等多层索引,而对非频繁使用分区中的数据可以不建或只建立单层素引
- 根据时间、地点划分:对于同一时间点生产的商品或者同一地点的商品归为同一个分区中
- 分布式数据库系统中数据划分:DDBS采用水平划分或垂直划分两种方法。水平划分将一张基本表划分为多张具有相同属性,结构完全相同的子表,子表包含的元组是基本表中元组的子集;重直划分是将一张基本表划分为多张子表,每张子表包含的属性是原基本表的子集
派生属性数据分布
- 将派生属性作为基本表中单独的一列(称为派生列):Age
- 派生属性不出现在基本
以上是关于计算机三级数据库的主要内容,如果未能解决你的问题,请参考以下文章