数据库关系模式有哪些类型

数据库关系模式有哪些类型,第1张

关系数据库中有型和值两种类型结构。关系模式是型,关系是值,关系模式是对关系的描述。

描述一个关系需要从以下两个方面来定义:第一方面,关系实质上是一个二维表,表的每一行为一个元组,每一列为一个属性。一个元组就是该关系所涉及的属性集的笛卡儿积的一个元素。关系是元组的集合,因此关系模式必须指出这个元组集合的结构,即它由哪些属性构成,这些属性来自哪些域,以及属性与域之间的映象关系。

第二方面,一个关系通常是由赋予它的元组语义来确定的。元组语义实质上是一个n目谓词(n是属性集中属性的个数)。凡使该n目谓词为真的笛卡儿积中的元素(或者说凡符合元组语义的那部分元素)的全体就构成了该关系模式的关系。

131关系数据库基本概念关系数据中,关系模式涉及众多概念、术语,初学者对这方面不容易把握与理解,以下用通俗易懂的语言来对这些概念及术语作简单的介绍。

1关系关系(Relation)是指数据库中实体的信息,也就是数据库中二维表的数据。一个关系就是一个数据库表的值,表中的内容是对应关系模式在某个时刻的值,称为一个关系。例如,关系A表示数据库有一张名字为A的数据表所记录的所有数据。关系数据库中每一个关系都具有以下六方面的性质:((1)列是同质的。即每一列中的分量为同一类型的数据,来自同一个域。

(2)不同的列可出自同一个域,称其中的每列为一个属性,不同的属性要给予不同的属性名。

(3)列的顺序无所谓。即列的次序可以任意交换。

(4)任意两个元组不能完全相同。

(5)行的顺序无所谓。即行的次序可以任意交换。

(6)分量必须取原子值。即每一个分量都必须是不可分的数据库属性。

2模式模式(Schema)是数据库中全体数据的逻辑结构和特征的描述,是所有用户的公共数据视图,也称逻辑模式。有以下几方面性质:((1)一个数据库只有一个模式。

(2)模式是数据在逻辑级上的视图。

(3)以某一种数据模型为基础。

定义模式时不仅要定义数据的逻辑结构,包括数据项的构成、名字、类型、取值范围等,而且要定义与数据有关的安全性、完整性要求,定义这些数据之间的联系。

3关系模式关系模式(RelationSchema)描述的是与关系相对应的二维表的表结构,即关系中包含哪些属性,属性来自哪些域,以及与域之间的映象关系。

关系模式与关系的区别:((1)关系模式描述了关系数据结构和语义,是关系的型。而关系是一个数据集合,是关系模式的值,是关系模式的一个实例。

(2)关系实际上就是关系模式在某一时刻的状态或内容。关系模式是静态的、稳定的,而关系是动态的、随时间不断变化的,因为数据库 *** 作会不断地更新数据库中的数据。

4元组元组(Tuple)是关系数据库中的基本概念,一个关系表中的每行就是一个元组。也就是说数据库表中的每条记录都是一个元组,表结构的每列就是一个属性,在二维表里,元组也称为记录。元组可表示一个关系或关系之间的联系。

一般情况下,一个关系数据表中的每条记录均有一个唯一的编号(记录号),这个编号也叫元组号。

5码码(Key)是关系数据库系统中的基本概念。所谓码,就是能唯一标识实体的属性集,是整个属性集,而不是单个属性。在关系数据库中,码包括多种类型,如超码、候选码和主码。

((1)超码(SuperKey)。超码是一个或多个属性的集合,这些属性可以在一个实体集中唯一地标识一个实体。如果K是一个超码,那么K的任意超集也是超码,也就是说如果K是超码,那么所有包含K的集合也是超码。例如,学生是一个实体,则学生的集合是一个实体集,而超码用来在学生的集合中区分不同的学生。假设学生(实体)具有多个属性:学号,身份z号,姓名,性别。因为通过学号可以找到唯一一个学生,所以{学号}是一个超码,同理{学号,身份z号}、{学号,身份z号,姓名}、{学号,身份z号,姓名,性别}、{身份z号}、{身份z号,姓名}、{身份z号,姓名,性别}也是超码。在这里,因为不同的学生可能拥有相同的姓名,所以姓名不可以区别一个学生,即{姓名}不是一个超码,{性别}、{姓名,性别}也不是。

(2)候选码(CandidateKey)。候选码是可以唯一标识一个元组的最少的属性集合。候选码是从超码中选出的,因此候选码也是一个或多个属性的集合。因为超码的范围太广,很多是无用的,所以候选码是最小超码,它们的任意真子集都不能成为超码。例如,如果K是超码,那么所有包含K的集合都不能是候选码;如果K,J都不是超码,那么K和J组成的集合{K,J}有可能是候选码。

虽然超码可以唯一标识一个实体,但是可能大多数超码中含有多余的属性,所以需要候选码。

例如学生表,学生(学号,姓名,年龄,性别,专业),其中的学号是可以唯一标识一个元组,所以学号可以作为候选码。既然学号都可以作候选码,那么学号和姓名这两个属性的组合就可以唯一区别一个元组。此时的学号可以成为码,学号和姓名的组合也可以成为码,但是学号和姓名的组合不能成为候选码,因为即使去掉姓名属性,剩下的学号属性也完全可以唯一地标识一个元组。也就是说,候选码中的所有属性都是必需的,缺少任何一个属性,都不能唯一标识一个元组。

(3)主码(PrimaryKey)。主码是从多个候选码中任意选出一个作为主键,这个被选中的候选码就称为主码。如果候选码只有一个,那么候选码就是主码。虽然说主码的选择是比较随意的,但在实际开发中还是需要一定的经验,不然开发出来的系统会出现问题。一般来说,主码都应该选择那些从不或者极少变化的属性。

例如,在一个职工实体中,职工(职工号,姓名,入职时间,部门,岗位,工资,职级,工龄,电话),职工号可以用来唯一确定实体中的一个元组,所以职工号是一个候选码。如果实体属性——姓名、入职时间、部门三者组合也能唯一地确定一个元组,则(姓名,入职时间,部门)也是一个候选码。在上述两个候选码中任选一个均可作为职工实体的主码,一般来说直接选择职工号作为实体的主码是最为简单方便的。

132关系模式的定义关系是数据库二维表中的数据记录,关系模式是数据库二维表的表结构,关系是动态的,关系模式是静态的。

关系模式可由六个元素来描述,分别是R、U、D、dom、I、F。其中,R为关系的名称;

U为组成该关系的属性名的集合;D为U集合中属性的域集合;dom为属性集U向域集D的映射;I为完整约束集合;F为属性间数据的依赖关系集合。

一个关系模式通常表示为R(U,D,dom,I,F),也可以忽略其他元素,直接简化为R(U)或R(A1,A2,A3,…,An),其中A1,A2,A3,…,An为属性名。

例如,在一个选课模块中,包含“学生”“课程”“选修”等关系实体。“学生”实体的属性有SNO(学号)、SNAME(姓名)、AGE(年龄)、SEX(性别)、SDEPT(系部),其中“学号”为主键;“课程”实体的属性有CNO(课程号)、CNAME(课程名称)、CDEPT(系部)、TNAME(教师),其中“课程号”为主键;“选修”实体的属性有GRADE(成绩)、SNO(学号)、CNO(课程号),其中“学号”和“课程号”为联合主键。学生和课程之间是多对多的关联关系,即一个学生可以同时选修多门课程,一门课程也可以同时被多个学生选修。这种多对多的关联关系可以通过“选修”关系实体作为中间桥接实体,变成两个一对多的实体关联关系,如图所示。

图学生选课实体

从图的实体关系图中可以得到选课模块的实体关系模式集——学生关系、课程关系、选修关系,具体关系模式如下:学生关系模式Student(SNO,SNAME,AGE,SEX,SDEPT);

课程关系模式Course(CNO,CNAME,CDEPT,TNAME);

选修关系模式StudentCourse(SNO,CNO,GRADE)。

对以上定义的三个关系模式实例化,插入初始化数据后,可得到学生、课程、选修三个关系的实例,如图所示。图中矩形框圈住部分为选课模块中的关系模式(表结构);椭圆框圈住部分为选课模块中的关系(数据)。整个选课模块的表环境由关系模式与关系两部分共同组成,缺一不可。关系模式的分解标准关系模式的规范化过程实际上就是关系模式的“分解”过程,即把逻辑上独立的信息放在独立的关系模式中。分解是解决数据冗余的主要方法,也是规范化的一条原则——关系模式有冗余问题就要分解。

数据库设计者在进行关系数据库设计时,应参照模式规范化理论,尽可能使数据库模式保持高的标准。一般尽量把关系数据库设计成巴斯−科德范式(BCNF)的模式集,如果设计成巴斯−科德范式(BCNF)模式集时达不到保持函数依赖的标准,那么只能降低要求,设计成第三范式(3NF)的模式集,以达到保持函数依赖和无损分解的基本要求。

学生、课程、选修三个关系的实例

1分解的定义一个关系模式可以分解成众多子关系模式,分解方式不同,得到的子关系模式也不同。

关系模式的分解是指把某一个关系模式按照某一种方式进行分解得到的所有子关系模式。

如关系模式R按照某一种方式分解,可以得到一个关系集ρ={R1,R2,…,Rn}。其中属性集U=U1∪U2∪…∪Un,并且不能存在Ui⊆Uj,1≤i,j≤n。

函数依赖关系集F=F1∪F2∪…∪Fn,其中F1,F2,…,Fn是F在U1,U2,…,Un上的投影。

2分解的标准把低级的关系模式分解成高级的关系模式的方法不是唯一的,只要能够保证分解后的关系模式与原关系模式等价,就是一个完整、标准的分解方法。关系模式的标准分解方法应同时达到以下两方面的要求:((1)分解具有无损连接性。

(2)分解要保持函数依赖性。

具有无损连接性的分解保证信息不会丢失,但无损连接不一定能解决插入异常、删除异常、修改复杂、数据冗余等问题,如要解决这些问题,则要考虑更高的关系数据范式理论原则。

数据库关系模型(数据库逻辑模型)是将数据概念模型转换为所使用的数据库管理系统(DBMS)支持的数据库逻辑结构,即将E-R图表示成关系数据库模式。数据库逻辑设计的结果不是唯一的,需利用规范化理论对数据库结构进行优化。

在关系模型中,数据库的逻辑结构是一张二维表。在数据库中,满足下列条件的二维表称为关系模型:

1)每列中的分量是类型相同的数据;

2)列的顺序可以是任意的;

3)行的顺序可以是任意的;

4)表中的分量是不可再分割的最小数据项,即表中不允许有子表;

5)表中的任意两行不能完全相同。

由此可见,有序的航空物探测量剖面数据不满足数据库关系模型条件第3条“行的顺序可以是任意的”,因此,不能简单地直接利用关系数据库(如Oracle,SQL Server,Sybase等)来管理剖面数据,需将数据在数据库中的存储方式改为大字段存储,确保不因数据库数据的增加和删除等 *** 作改变剖面数据有序特性。

一、大字段存储

(一)大字段存储技术

大字段LOB(Large Object)技术是Oracle专门用于存放处理大对象类型数据(如多媒体材料、影像资料、文档资料等)的数据管理技术。LOB包括内部的和外部的两种类型。内部LOB又分CLOB(字符型)、BLOB(二进制型)等3种数据类型,其数据存储在数据库中,并且支持事务 *** 作;外部LOB只有BFILE类型,其数据存储在 *** 作系统中,并且不支持事务 *** 作。LOB存放数据的长度最大可以达到4G字节,并且空值列(没有存放数据)不占空间(图2-6)。

图2-6 大字段存储示意图

由于外部LOB存放在 *** 作系统文件中,其安全性比内部LOB差一些。此外,大字段的存储支持事务 *** 作(批量提交和回滚等),而外部LOB不支持事务 *** 作。所以,航空物探测量剖面数据采用BLOB来存储。对于BLOB类型,如果数据量小于4000字节,数据库通常采用行内存储,而数据量大于4000字节采用行外存储。分析航空物探测量剖面数据,每个场值数据占4个字节(单精度),目前航磁数据采样率为10次/s,4000字节只能存储100s数据;一般情况下航空物探测量每条测线飞行时间至少在10min以上,每条测线数据量远远大于4000字节。所以,航空物探测量剖面数据采用行外存储方式,即大字段列指定“Disable Storage In Row”的存储参数。

由于大字段类型长度可变,最大可到4G。假设测线飞行时间为T,场值采样率为n次/s,测线场值数据量为4Tn,所以有4Tn≤4G。单条测线飞行时间T不会超过10h(36000s,航空物探测量1架次至少飞行1个往返2条测线),则场值的采样率n≤4G/4T=4×1024×1024×1024/4×36000次/s=29826次/s。采用大字段来存储测量数据,不仅能够减少数据表的记录数,提高查询效率,而且使得采样率的扩展不受限制。

(二)大字段存储技术应用

由于航空物探数据的数据量较大,现有的航磁测量数据按基准点方式(点存储)存储可达几亿个数据记录。若按磁场数据采样点存储方式(简称“场值存储方式”),则记录条数=(磁场数据采样率/坐标采样率)点存储方式的记录数,达几十亿条数据记录,且随着数据采样率的扩展、测点的加密,航空物探测量数据量随着时间的推移呈现快速增长之势。显然,如果采用常规的表结构来存储,势必造成数据的存储、管理、检索、浏览和提取都非常困难。另一方面,从航空物探专业应用需求来说,很少对单个测点的场值数据进行运算、分析等 *** 作,一般至少是对一条测线或以上测线,多数时候是需要对整个测区的场值数据进行化极、上延、正反演拟合等。

因此,在航空物探数据库表结构设计时,改变过去将基准点或场值点数据记录作为数据库最小管理对象的理念,采用了大字段存储技术,将测线作为数据库最小管理对象,将测线上的测量数据,如坐标数据和磁场、重力场数据分别存储在相应大字段中。在航空物探数据库建设中,大量采用数据库的大字段存储技术(详见《航空物探信息系统数据库结构设计》)。

(三)大字段存储效率

以航磁测量数据为例分析大字段存储技术优势。如果以场值存储方式存储测线数据,则每条记录包含架次号、测线号、基准号、地理坐标、投影坐标、磁场数据等,由于坐标数据采样率2次/s,磁场数据采样率10次/s,每5个磁场数据中,只有第1个磁场数据有坐标数据,其他4个坐标数据是内插出来,因此在测线记录中会产生大量冗余的数据坐标数据。采用点存储方式存储的测线数据记录数等于线上基准点数,若采用大字段存储方式,一条测线数据只存储为1条数据记录(图2-7),一般一条测线的测点数近万个,甚至更多,可见采用大字段存储大大减少测线数据存储记录数,提高数据的存取效率。

以某测区的两条航迹线为例,分别采用3种方式测试数据库的数据存储效率。磁场数据的采样率10次/s,坐标数据采样率2次/s,两条测线上共有基准点8801个。以场值方式存储先内插坐标信息,使得每个场值数据都拥有自己的坐标,然后存入数据库,共有数据记录44005条,写入数据库时间为5722s,读取时间为103s。第二种方式是以采样点的方式进行存储,共有8801条记录,写入数据库时间为947s,读取需要091s。第三种方式是以大字段的形式存储,只有2条记录,写入数据库103s,读取时间为044s(表2-2)。大字段数据存储记录数最少,存取效率最高。用整个测区数据测试效果更加明显。

表2-2 三种数据存储方法的存取效率比较

图2-7 大字段存储方式示意图

二、联合主键

主外键是关系型数据库建立表间关系的核心。在航空物探空间数据库建设过程中,要素类与要素类之间、要素类与对象类之间,以及对象类与对象类之间的关系的描述有3种形式,即拓扑关系——描述要素类与要素类之间结点、邻接和联通关系;叠加关系——描述要素类与要素类之间的相交、包含与分类关系;隶属关系——描述对象类与对象类之间的派生关系。前两种关系是采用空间数据模型建立的关系,而隶属关系是通过主键建立的对象类与对象类之间的关系。在建立一对一、一对多的表间关系时,需要在整个数据库表中确定具有唯一性的一个字段作为主键(主关键字)。

按照传统的航空物探数据的档案管理模式,每个项目分配一个自然数作为档案号,项目的所有资料均与此档案号相联系。勘查项目和科研项目的档案号是独立编号的,且均从001开始。加之人工管理的原因,存在1个项目2个档案号和2个项目1个档案号的情况,因此现行的档案号与项目之间的对应关系不具备唯一性,不能作为项目的唯一标识,即不能作为数据库表的主键。项目编号也不能作为数据库表的主键,项目编号也只是近十年的事,以前的项目没有项目编号。

综合考虑上述因素和项目具有分级、分类的特点,提出了构造项目唯一标识码(简称“项目标识”)的方法,并以此码作为数据库表的主键。

项目标识(主键):AGS+项目类别(2位)+项目起始年份(4位)+档案号(6位)

标识含义:AGS——航空物探的缩位代码;

项目类别——2位代码,01代表勘查项目、02代表科研项目;

起始年份—4位代码,项目开始年号;

档案号—6位代码,为了与传统的项目管理方式相衔接,后面3~4位是

项目档案管理模式下的档案号,不足部分补零。

以上15位编码是一级项目的项目标识,二级及其以下级别的项目标识是在上一级项目标识基础上扩展2位数字代码,中间用“”号隔开,数字为该级项目的序号。项目标识定义为30位编码,适用于六级以内的项目。例如:AGS022004000576080402,表示该项目为2004年开展的档案号为576的航空物探科研项目(一级项目)的第8课题(二级项目)第4子课题(三级项目)的第2专题。由此可见,该项目标识不仅仅是一个建立表间关系的关键字,同时还表达了不同级别项目间的隶属关系。在系统软件开发时,利用此关系生成了项目的分级树形目录,用户对项目的层次关系一目了然,便于项目查询。

数据库的主键一经确定,相应地需要确定联合主键的组成及其表达方式。所谓联合主键就是数据资料的唯一标识,在一个数据库表中选择2个或者2个以上的字段作为主键。由于航空物探数据绝大部分与项目标识有关,加之数据的种类较多,分类复杂,单凭主键确定数据库表中记录的唯一性,势必需要构建极其复杂的主键,这种方法既不利于主键的数据 *** 作,又会造成大量的数据冗余,合理地使用联合主键技术可以很好地解决资料唯一问题。以项目提交资料为例,提交的资料分为文字类资料、图件类资料和媒体类资料,我们对资料进行分类和编号,例如100代表文字资料(110——World文档,120——PDF文档),200代表图件资料(210——基础地理资料、220——基础地质资料,230——航迹线图,240——剖面图,250——等值线图等),300代表媒体资料(310——PPT文档,320——照片等),第1位(百位)表示该资料的类型,第2~3位表示该类资料的序号。

在数据库管理和项目资料查询时,采用项目标识与资料分类编号作为联合主键(图2-8),可以高效地实现复杂数据的查询。在整个数据库系统中多处(项目查询、数据提取等模块)使用联合主键技术。

图2-8 联合主键实例

三、信息标准化

为了实现数据共享,在航空物探数据库建模过程中,参考和引用了近百个国家信息化标准,编制了4个中心信息化标准和1个图件信息化工作指南。

(一)引用的国家信息化标准

1)地质矿产术语分类代码:地球物理勘查,地球化学勘查,大地构造学,工程地质学,结晶学及矿物学,矿床学,水文地质学,岩石学,地质学等。

2)国家基础信息数据分类与代码,国土基础信息数据分类与代码,地球物理勘查技术符号,地面重力测量规范,地面磁勘查技术规程,地面高精度磁测技术规程,大比例尺重力勘查规范,地理信息技术基本术语,地理点位置的纬度、经度和高程的标准表示法,地名分类与类别代码编制规则。

3)地球空间数据交换格式;数学数字地理底图数据交换格式;数字化地质图图层及属性文件格式。

(二)本系统建立的信息化标准

编写了“航空物探空间数据要素类和对象类划分标准”,“航空物探项目管理和资料管理分类代码标准”,“航空物探勘查分类代码标准”,“航空物探信息系统元数据标准”,“航空物探图件信息化工作指南”,以便与其他应用系统进行信息交换,实现数据库资料共享。

航空物探空间数据要素类和对象类划分标准:根据物探方法、数据处理过程以及推断解释方法和过程,把与GIS有关的数据划分为不同类型的要素类-对象类数据,按专业、比例尺、数据内容对要素类和对象类进行统一命名,使空间数据库中的每个要素类和对象类的命名具有唯一性,防止重名出现。规定要素类-对象类数据库表结构及数据项数值类型。

航空物探项目管理和资料管理分类代码标准:规定了航空物探项目管理和资料管理的相关内容,包括航空物探勘查项目和科研项目的项目立项、设计、实施、成果、评审、资料汇交等项目管理的全过程中的内容,以及项目成果资料和收集资料的归档、发送、销毁、借阅等资料管理与服务过程中的内容和数据项代码。

航空物探勘查分类代码标准:在“地质矿产术语分类代码地球物理勘查”(国家标准GB/T964928—1998)增加了航磁、航重专业方面所涉及的数据采集、物性参数、方法手段、仪器设备、资料数据解释及成图图件等内容和数据项代码。

航空物探信息系统元数据标准:规定了航空物探空间数据管理与服务的元数据(数据的标识、内容、质量、状况及其他有关特征)的内容。

四、航迹线数据模型

(一)航迹线模型的结构

航空物探测量是依据测量比例尺在测区内布置测网(测线和切割线)。当飞机沿着设计的测线飞行测量时,航空物探数据收录系统按照一定的采样率采集采样点的地理位置、高度和各种地球物理场信息。采用属性数据分置的方法,将测线地理位置信息从航空物探测量数据中分离出来,形成航迹线要素类表,在此表中只存储与航迹线要素类有关的数据,如项目标识、测区编号、测线号、测线类型(用于区分测线、切割线、不同高度线、重复线等)、坐标、高度值等;将航迹线的对象类数据(磁场、重力场基础数据)分别以大字段形式存储在各自的二维表中,它们共享航迹线,解决了多源有序不同采样率的航空物探测量数据的数据存储问题,在满足要素类空间查询的同时,统一数据的存储方式(图2-9)。航迹线要素类隶属于测区要素类,它们之间为空间拓扑(包含)关系。测区从属于勘查项目,每个勘查项目至少有一个测区,它们之间为1对多关系。有关项目信息存放在项目概况信息对象类表中,各种表之间通过项目标识进行联接。

图2-9 航迹线数据模型结构

(二)航迹线的UML模型

统一建模语言UML(Unified Modeling Language)是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它溶入了软件工程领域的新思想、新方法和新技术。UML是面向对象技术领域内占主导地位的标准建模语言,成为可视化建模语言的工业标准。在UML基础上,ESRI定义了空间数据库建模的ArcGIS包、类库和扩展原则。

图2-10 与航迹线有关的数据库表逻辑模型结构图

在确定航迹线数据模型后,以它为基础,使用UML完成与航迹的有关的项目概况信息、测区信息、原始数据等数据库表逻辑模型设计(图2-10)。

由UML模型生成Geodatabase模式时,模型中的每个类都对应生成一个要素类或对象类。类的属性映射为要素类或对象类的字段。基类属性中包含的字段,在继承类中不需重复创建。例如,每个类都包括项目标识等字段,可以创建一个包含公共属性的基类,其他类从该类继承公共的属性,而无需重复建基类中包含的属性。因为基类没有对应的要素类或对象类,所以将基类设置为抽象类型。要素类之间的关系采用依赖关系表示。

五、数据库逻辑模型

关系数据库的逻辑结构由一组关系模式组成,因而从概念结构到关系数据库逻辑结构的转换就是将概念设计中所得到的概念结构(ER图)转换成等价的UML关系模式(图2-11)。在UML模型图中,要素数据集用Geodatabase工作空间下的静态包表示。要素集包不能互相嵌套,为了容易组织,在生成物理模型后,在要素数据集包中自定义嵌套。要素数据集与空间参考有关,但是空间参考不能在UML中表达。要素类和二维表都是以类的形式创建的,区别是要素类继承Feature Class的属性,而二维表继承Object属性。为了表达每种元素的额外属性,比如设置字符型属性字段的字符串长度,设置要素类的几何类型(点、线或面)需要使用Geodatabase预定义的元素标记值。

图2-11 逻辑设计关系转换

基于航空物探数据的内在逻辑关系进行分析,使用统一建模语言(UML)构建数据实体对象间的关系类,定义了航空物探数据库的逻辑模型(图2-12)。

数据库系统3级模式

外模式、模式、内模式

外模式是某个或某几个用户所看到的数据库的数据视图,是与某一应用有关的数据的逻辑表示;模式是数据的逻辑存储结构,通常都是基本表;内模式是基本表对应数据物理存储结构,以文件的形式存在。

外模式/模式映像、模式/内模式映像

用户应用程序根据外模式进行数据 *** 作,通过外模式一模式映射,定义和建立某个外模式与模式间的对应关系,将外模式与模式联系起来,当模式发生改变时,只要改变其映射,就可以使外模式保持不变,对应的应用程序也可保持不变;另一方面,通过模式一内模式映射,定义建立数据的逻辑结构(模式)与存储结构(内模式)间的对应关系,当数据的存储结构发生变化时,只需改变模式一内模式映射,就能保持模式不变,因此应用程序也可以保持不变。

三级结构的组织形式称为数据库的体系结构或数据抽象的三个级别。这个结构是于1975年在美国ANSI/X3/SPARC(美国国家标准协会的计算机与信息处理委员会中的标准计划与需求委员会)数据库小组的报告中提出的。

1141三级数据视图

数据抽象的三个级别又称为三级数据视图,是不同层次用户(人员)从不同角度所看到的数据组织形式。

(1) 外部视图 第一层的数据组织形式是面向应用的,是应用程序员开发应用程序时所使用的数据组织形式,是应用程序员所看到的数据的逻辑结构,是用户数据视图,称为外部视图。外部视图可有多个。这一层的最大特点是以各类用户的需求为出发点,构造满足其需求的最佳逻辑结构。

(2) 全局视图 第二层的数据组织形式是面向全局应用的,是全局数据的组织形式,是数据库管理人员所看到的全体数据的逻辑组织形式,称为全局视图,全局视图仅有一个。这一层的特点是对全局应用最佳的逻辑结构形式。

(3) 存储视图 第三层的数据组织形式是面向存储的,是按照物理存储最优的策略所组织形式,是系统维护人员所看到的数据结构,称为存储视图。存储视图只有一个。这一层的特点是物理存储最佳的结构形式。

外部视图是全局视图的逻辑子集,全局视图是外部视图的逻辑汇总和综合,存储视图是全局视图的具体实现。三级视图之间的联系由二级映射实现。外部视图和全局视图之间的映射称为逻辑映射,全局视图和存储视图之间的映射称为物理映射。

1142 三级模式

三级视图是用图、表等形式描述的,具有简单、直观的优点。但是,这种形式目前还不能被计算机直接识别。为了在计算机系统中实现数据的三级组织形式,必须用计算机可以识别的语言对其进行描述。DBMS提供了这种数据描述语言(Data Description Language 简记为DDL)。我们称用DDL精确定义数据视图的程序为模式(Scheme)。与三级视图对应的是三级模式。

(1) 子模式定义外部视图的模式称外模式,也称子模式。它由对用户数据文件的逻辑结构描述以及和全局视图中文件的对应关系的描述组成,用DBMS提供的子模式DDL定义。一个子模式可以由多个用户共享,而一个用户只能使用一个子模式。

(2) 模式  定义全局视图的模式称逻辑模式,简称模式。它由对全局视图中全体数据文件的逻辑结构描述以及和存储视图中文件的对应关系的描述组成,用DBMS提供的模式DDL定义。逻辑结构的描述包括记录的型(组成记录的数据项名、类型、取值范围等),还有记录之间的联系,数据的完整性、安全保密要求等。

(3) 内模式  定义存储视图的模式称内模式,又称物理模式。它由对存储视图中全体数据文件的存储结构的描述和对存储介质参数的描述组成,用DBMS提供的内模式DDL定义。存储结构的描述包括记录值的存储方式(顺序存储、hash方法、B树结构等),索引的组织方式等。

三级模式的结构如图18所示。

三级模式所描述的仅仅是数据的组织框架,而不是数据本身。在内模式这个框架填上具体数据就构成物理数据库,它是外部存储器上真实存在的数据集合。模式框架下的数据集合是概念数据库,它仅是物理数据库的逻辑映像。子模式框架下的数据集合是用户数据库,它是概念数据库的逻辑子集。

以上就是关于数据库关系模式有哪些类型全部的内容,包括:数据库关系模式有哪些类型、数据库逻辑模型、数据库三级模式结构是指什么等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/9350296.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-27
下一篇 2023-04-27

发表评论

登录后才能评论

评论列表(0条)

保存