数据库 - 物理设计

数据库的物理设计

数据库在物理设备上的存储结构与存取方法称为数据库的物理结构,它依赖于选定的数据库管理系统

为一个给定的逻辑数据模型选取一个最适合应用环境的物理结构的过程,就是数据库的物理设计

数据库物理设计的步骤

确定数据库的物理结构,在关系数据库中主要指存取方法和存储结构

对物理结构进行评价,评价的重点是时间和空间效率

如果评价结果满足原设计要求,则可进入到物理实施阶段,否则,就需要重新设计或修改物理结构,有时甚至要返回逻辑设计阶段修改数据模型

数据库物理设计的内容和方法

设计物理数据库结构的准备工作

对要运行的事务进行详细分析,获得选择物理数据库设计所需参数

充分了解所用RDBMS的内部特征,特别是系统提供的存取方法和存储结构

选择物理数据库设计所需参数

数据库查询事务

查询的关系

查询条件所涉及的属性

连接条件所涉及的属性

查询的投影属性

选择物理数据库设计所需参数(续)

数据更新事务

被更新的关系

每个关系上的更新操作条件所涉及的属性

修改操作要改变的属性值

每个事务在各关系上运行的频率和性能要求

关系数据库物理设计的内容

为关系模式选择存取方法(建立存取路径)

设计关系、索引等数据库文件的物理存储结构

关系模式存取方法选择

数据库系统是多用户共享的系统,对同一个关系要建立多条存取路径才能满足多用户的多种应用要求

物理设计的任务之一就是要确定选择哪些存取方法,即建立哪些存取路径

DBMS常用存取方法

索引方法

目前主要是B+树索引方法

经典存取方法,使用最普遍

聚簇(Cluster)方法

HASH方法

选择索引存取方法

根据应用要求确定

对哪些属性列建立索引

对哪些属性列建立组合索引

对哪些索引要设计为唯一索引

选择索引存取方法的一般规则
如果一个(或一组)属性经常在查询条件中出现,则考虑在这个(或这组)属性上建立索引(或组合索引)
如果一个属性经常作为最大值和最小值等聚集函数的参数,则考虑在这个属性上建立索引
如果一个(或一组)属性经常在连接操作的连接条件中出现,则考虑在这个(或这组)属性上建立索引
关系上定义的索引数过多会带来较多的额外开销
 维护索引的开销
 查找索引的开销

聚簇

为了提高某个属性(或属性组)的查询速度,把这个或这些属性(称为聚簇码)上具有相同值的元组集中存放在连续的物理块称为聚簇

聚簇的用途

  1. 大大提高按聚簇码进行查询的效率

    例:假设学生关系按所在系建有索引,现在要查询信息系的所有学生名单。

    信息系的500名学生分布在500个不同的物理块上时,至少要执行500次I/O操作

    如果将同一系的学生元组集中存放,则每读一个物理块可得到多个满足查询条件的元组,从而显著地减少了访问磁盘的次数

  2. 节省存储空间

    聚簇以后,聚簇码相同的元组集中在一起了,因而聚簇码值不必在每个元组中重复存储,只要在一组中存一次就行了

聚簇的局限性

  1. 聚簇只能提高某些特定应用的性能
  2. 建立与维护聚簇的开销相当大

    对已有关系建立聚簇,将导致关系中元组移动其物理存储位置,并使此关系上原有的索引无效,必须重建

    当一个元组的聚簇码改变时,该元组的存储位置也要做相应移动

聚簇的适用范围

1. 既适用于单个关系独立聚簇,也适用于多个关系组合聚簇

例:假设用户经常要按系别查询学生成绩单,这一查询涉及学生关系和选修关系的连接操作,即需要按学号连接这两个关系,为提高连接操作的效率,可以把具有相同学号值的学生元组和选修元组在物理上聚簇在一起。这就相当于把多个关系按“预连接”的形式存放,从而大大提高连接操作的效率。

  1. 当通过聚簇码进行访问或连接是该关系的主要应用,与聚簇码无关的其他访问很少或者是次要的时,可以使用聚簇。

    尤其当SQL语句中包含有与聚簇码有关的ORDER BY,GROUP BY,UNION,DISTINCT等子句或短语时,使用聚簇特别有利,可以省去对结果集的排序操作

设计候选聚簇
对经常在一起进行连接操作的关系可以建立聚簇
如果一个关系的一组属性经常出现在相等比较条件中,则该单个关系可建立聚簇
如果一个关系的一个(或一组)属性上的值重复率很高,则此单个关系可建立聚簇。即对应每个聚簇码值的平均元组数不太少。太少了,聚簇的效果不明显

优化聚簇设计

从聚簇中删除经常进行全表扫描的关系;

从聚簇中删除更新操作远多于连接操作的关系;

不同的聚簇中可能包含相同的关系,一个关系可以在某一个聚簇中,但不能同时加入多个聚簇

从这多个聚簇方案(包括不建立聚簇)中选择一个较优的,即在这个聚簇上运行各种事务的总代价最小

选择HASH存取方法的规则

当一个关系满足下列两个条件时,可以选择HASH存取方法

该关系的属性主要出现在等值连接条件中或主要出现在相等比较选择条件中

该关系的大小可预知,而且不变;

该关系的大小动态改变,但所选用的DBMS提供了动态HASH存取方法

确定数据库的存储结构

确定数据库物理结构的内容

1. 确定数据的存放位置和存储结构

关系

索引

聚簇

日志

备份

2. 确定系统配置

确定数据存放位置和存储结构的因素

存取时间

存储空间利用率

维护代价

这三个方面常常是相互矛盾的

例:消除一切冗余数据虽能够节约存储空间和减少维护代价,但往往会导致检索代价的增加

必须进行权衡,选择一个折中方案

确定数据的存放位置

基本原则

根据应用情况将

易变部分与稳定部分分开存放

存取频率较高部分与存取频率较低部分,分开存放

例:
数据库数据备份、日志文件备份等由于只在故障恢复时才使用,而且数据量很大,可以考虑存放在磁带上
如果计算机有多个磁盘或磁盘阵列 ,可以考虑将表和索引分别放在不同的磁盘上,在查询时,由于磁盘驱动器并行工作,可以提高物理I/O读写的效率 

例(续):
可以将比较大的表分别放在两个磁盘上,以加快存取速度,这在多用户环境下特别有效
可以将日志文件与数据库对象(表、索引等)放在不同的磁盘以改进系统的性能

DBMS产品一般都提供了一些存储分配参数

同时使用数据库的用户数

同时打开的数据库对象数

内存分配参数

使用的缓冲区长度、个数

存储分配参数

…….

评价物理结构

评价内容

对数据库物理设计过程中产生的多种方案进行细致的评价,从中选择一个较优的方案作为数据库的物理结构

评价方法(完全依赖于所选用的DBMS )

定量估算各种方案

存储空间

存取时间

维护代价

对估算结果进行权衡、比较,选择出一个较优的合理的物理结构

如果该结构不符合用户需求,则需要修改设计

数据库结构建立好后,就可以向数据库中装载数据了。组织数据入库是数据库实施阶段最主要的工作。

数据装载方法

人工方法

计算机辅助数据入库

数据库的试运行

强调两点:

分期分批组织数据入库

重新设计物理结构甚至逻辑结构,会导致数据重新入库。

由于数据入库工作量实在太大,费时、费力,所以应分期分批地组织数据入库

先输入小批量数据供调试用

待试运行基本合格后再大批量输入数据

逐步增加数据量,逐步完成运行评价

数据库的转储和恢复

在数据库试运行阶段,系统还不稳定,硬、软件故障随时都可能发生

系统的操作人员对新系统还不熟悉,误操作也不可避免

因此必须做好数据库的转储和恢复工作,尽量减少对数据库的破坏。

数据库的运行与维护

数据库试运行合格后,数据库即可投入正式运行。

数据库投入运行标志着开发任务的基本完成和维护工作的开始

对数据库设计进行评价、调整、修改等维护工作是一个长期的任务,也是设计工作的继续和提高。

应用环境在不断变化

数据库运行过程中物理存储会不断变化

在数据库运行阶段,对数据库经常性的维护工作主要是由DBA完成的,包括:

数据库的转储和恢复

数据库的安全性、完整性控制

数据库性能的监督、分析和改进

数据库的重组织和重构造

数据库的重组织和重构造

重组织的形式

全部重组织

部分重组织

只对频繁增、删的表进行重组织

重组织的目标

提高系统性能

重组织的工作

按原设计要求

重新安排存储位置

回收垃圾

减少指针链

数据库的重组织不会改变原设计的数据逻辑结构和物理结构

数据库重构造

根据新环境调整数据库的模式和内模式

增加新的数据项

改变数据项的类型

改变数据库的容量

增加或删除索引

修改完整性约束条件

数据库各级模式的形成

数据库的各级模式是在设计过程中逐步形成的

需求分析阶段综合各个用户的应用需求(现实世界的需求)

概念设计阶段形成独立于机器特点、独立于各个DBMS产品的概念模式(信息世界模型),用E-R图来描述

在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型,形成数据库逻辑模式。然后根据用户处理的要求,安全性的考虑,在基本表的基础上再建立必要的视图(VIEW)形成数据的外模式

在物理设计阶段根据DBMS特点和处理的需要,进行物理存储安排,设计索引,形成数据库内模式

时间: 2024-10-14 06:32:57

数据库 - 物理设计的相关文章

MySQL 数据库设计 笔记与总结(3)物理设计

[物理设计的工作] ① 选择合适的数据库管理系统:Oracle,SQLServe,MySQL,PgSQL ② 定义数据库.表及字段的命名规范 ③ 根据所选的 DBMS 系统选择合适的字段类型 ④ 反范式化设计 —— 考虑读效率,在一些表中增加适当的冗余(空间换时间) [数据库选择] [MySQL 常用的存储引擎] 注:Archive 主要用于存储日志:Ndb cluster 是 MySQL 集群(内存型集群)所使用的存储引擎. [表及字段的命名规则] [建立数据库及表结构 —— 字段类型的选择原

数据库物理分布设计(转)

概述我们无论使用哪种数据库,无论怎样设计数据库,我想都会遵从一个原则:数据安全性和性能高效这两个主要方面,但是关于这两个方面的话题太多,在这里就不一 一陈述,我只是从数据库物理分布设计方面和大家一起简单的探讨一下.因为数据库良好的物理分布设计也是对数据安全性和性能高效影响比较大, 就象我们在建大楼之前一定要先打好地基一样.現实中我们在应用各种不同数据库的时候,往往会忽略数据库的物理布局,只有在数据库性能遇到问题的时候才去考虑,但这是得不偿失的,这样一来不仅会导致与 设计相关的问题出现,而且会影响

数据库设计理论与实践·<三>物理设计

一.物理设计核心任务与关键细节 二.物理设计经验之谈 1.数据类型的设计:建议字段数据类型定义时结合以下几点(以MYSQL为例) 1)不适用image,而使用varbinary等 2)不使用text和ntext,而使用varchar或者nvarchar 3)不使用money和small,而使用decimal 4)使用bit而非char(1) 来表示男/女,或者是/否的布尔值 5)自增主键根据预期范围选择int或者bigint,GUID使用unique identifier而非varchar(N)

20170105数据库表设计知识点

20170105数据库表设计知识点 ------指导老师    星哥 1.PHP(MYSQL)擅长单表操作,不要做过多无谓的连接查询 2.表字段名不要使用大驼峰命名方式,最好采用下划线,命名要和团队习惯一致,通俗易懂. 3.表级.字段都要有注释 4.MyISAM 适合于一些需要大量查询的应用,但其对于有大量写操作并不是很好.甚至你只是需要update一个字段,整个表都会被锁起来,而别的进程,就算是读进程都无法操作直到读操作完成.另外,MyISAM 对于 SELECT COUNT(*) 这类的计算

数据库schema设计与优化

原文地址 1. 前言 对于数据库而言,在日常开发中我们主要的关注点有两块,一个是schema的结构设计,另一个就是索引的优化,这两块是影响我们最终系统结构和性能的关键部分,自然也是我们花费精力最多的部分: 本文主要介绍数据库设计中的一般原则和优化手段,包括数据库的一半范式.反范式设计.数据切分.数据路由与合并等等 2. Schema设计的一般性原则 2.1 概述 范式理论是关系型数据库设计的黄金法则,它提供了数据结构化的理论基础,有效地保证了数据的一致性,应该说,关系型数据库就是在范式的基础上才

数据库课程设计

数 据库课程设计是在学生系统的学习了数据库原理课程后,依照关系型数据库的基本原理,综合运用所学的知识,以小组为单位,设计开发一个小型的管理信息系统 (MIS).通过对一个实际问题的分析.设计与实现,将原理与应用相结合,使学生学会怎样把书本上学到的知识用于解决实际问题,培养学生的动手能力:还有一 方面,使学生能深入理解和灵活掌握教学内容. 整体设计要求: 四到五人为一个小组,小组成员既要有相互合作的精神,又要分工明白.每一个学生都必须充分了解整个设计的全过程. 通讯录 1.功能需求: 1)网络版,

数据库架构设计思路

一 .58同城数据库架构设计思路 (1)可用性设计 解决思路:复制+冗余 副作用:复制+冗余一定会引发一致性问题 保证"读"高可用的方法:复制从库,冗余数据,如下图  带来的问题:主从不一致 解决方案:见下文 保证"写"高可用的一般方法:双主模式,即复制主库(很多公司用单master,此时无法保证写的可用性),冗余数据,如下图  带来的问题:双主同步key冲突,引不一致 解决方案: a)方案一:由数据库或者业务层保证key在两个主上不冲突 b)方案二:见下文 58同

数据库范式的思考以及数据库的设计

数据库范式--通俗易懂[转] 数据库范式是数据库设计中必不可少的知识,没有对范式的理解,就无法设计出高效率.优雅的数据库.甚至设计出错误的数据库.而想要理解并掌握范式却并不是那 么容易.教科书中一般以关系代数的方法来解释数据库范式.这样做虽然能够十分准确的表达数据库范式,但比较抽象,不太直观,不便于理解,更难以记忆. 本文用较为直白的语言介绍范式,旨在便于理解和记忆,这样做可能会出现一些不精确的表述.但对于初学者应该是个不错的入门.我写下这些的目的主要是为了加强 记忆,其实我也比较菜,我希望当我

互联网数据库架构设计思路

一 .58同城数据库架构设计思路 (1)可用性设计 解决思路:复制+冗余 副作用:复制+冗余一定会引发一致性问题 保证"读"高可用的方法:复制从库,冗余数据,如下图   带来的问题:主从不一致 解决方案:见下文 保证"写"高可用的一般方法:双主模式,即复制主库(很多公司用单master,此时无法保证写的可用性),冗余数据,如下图   带来的问题:双主同步key冲突,引不一致 解决方案: a)方案一:由数据库或者业务层保证key在两个主上不冲突 b)方案二:见下文 5