三级结构的组织形式称为数据库的体系结构或数据抽象的三个级别。这个结构是于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所示。
三级模式所描述的仅仅是数据的组织框架,而不是数据本身。在内模式这个框架填上具体数据就构成物理数据库,它是外部存储器上真实存在的数据集合。模式框架下的数据集合是概念数据库,它仅是物理数据库的逻辑映像。子模式框架下的数据集合是用户数据库,它是概念数据库的逻辑子集。
模型的转换 E-R图如何转换为关系模型呢?我们先看一个例子。
图21是学生和班级的E-R图,学生与班级构成多对一的联系。根据实际应用,我们可以做出这个简单例子的关系模式:
学生(学号,姓名,班级)
班级(编号,名称)
“学生班级”为外键,参照“班级编号”取值。
这个例子我们是凭经验转换的,那么里面有什么规律呢?在22节,我们将这些经验总结成一些规则,以供转换使用。 (1)一个实体型转换为一个关系模式
一般E-R图中的一个实体转换为一个关系模式,实体的属性就是关系的属性,实体的码就是关系的码。
(2)一个1:1联系可以转换为一个独立的关系模式,也可以与任意一端对应的关系模式合并。
图22是一个一对一联系的例子。根据规则(2),有三种转换方式。
(i) 联系单独作为一个关系模式
此时联系本身的属性,以及与该联系相连的实体的码均作为关系的属性,可以选择与该联系相连的任一实体的码属性作为该关系的码。结果如下:
职工(工号,姓名)
产品(产品号,产品名)
负责(工号,产品号)
其中“负责”这个关系的码可以是工号,也可以是产品号。
(ii) 与职工端合并
职工(工号,姓名,产品号)
产品(产品号,产品名)
其中“职工产品号”为外码。
(iii) 与产品端合并
职工(工号,姓名)
产品(产品号,产品名,负责人工号)
其中“产品负责人工号”为外码。
(3)一个1:n联系可以转换为一个独立的关系模式,也可以与n端对应的关系模式合并。
(i) 若单独作为一个关系模式
此时该单独的关系模式的属性包括其自身的属性,以及与该联系相连的实体的码。该关系的码为n端实体的主属性。
顾客(顾客号,姓名)
订单(订单号,……)
订货(顾客号,订单号)
(ii) 与n端合并
顾客(顾客号,姓名)
订单(订单号,……,顾客号)
(4)一个m:n联系可以转换为一个独立的关系模式。
该关系的属性包括联系自身的属性,以及与联系相连的实体的属性。各实体的码组成关系码或关系码的一部分。
教师(教师号,姓名)
学生(学号,姓名)
教授(教师号,学号)
(5)一个多元联系可以转换为一个独立的关系模式。
与该多元联系相连的各实体的码,以及联系本身的属性均转换为关系的属性,各实体的码组成关系的码或关系码的一部分。
(6)具有相同码的关系模式可以合并。
(7)有些1:n的联系,将属性合并到n端后,该属性也作为主码的一部分
这类问题多出现在聚集类的联系中,且部分实体的码只能在某一个整体中作为码,而在全部整体中不能作为码的情况下才出现(其它情况本人还没碰到,呵呵,欢迎指教)。
比如上篇文章介绍的管理信息系统中订单与订单细节的联系。
关于什么是聚集,23节介绍。 这部分本应在概念设计中介绍的,用到了才想起来,这里补充一下。
关于现实世界的抽象,一般分为三类:
(1) 分类:即对象值与型之间的联系,可以用“is member of”判定。如张英、王平都是学生,他们与“学生”之间构成分类关系。
(2) 聚集:定义某一类型的组成成分,是“is part of”的联系。如学生与学号、姓名等属性的联系。
(3) 概括:定义类型间的一种子集联系,是“is subset of”的联系。如研究生和本科生都是学生,而且都是集合,因此它们之间是概括的联系。
例:猫和动物之间是概括的联系,《Tom and Jerry》中那只名叫Tom的猫与猫之间是分类的联系,Tom的毛色和Tom之间是聚集的联系。
订单细节和订单之间,订单细节肯定不是一个订单,因此不是概括或分类。订单细节是订单的一部分,因此是聚集。 有了关系模型,可以进一步优化,方法为:
(1) 确定数据依赖。
(2) 对数据依赖进行极小化处理,消除冗余联系(参看范式理论)。
(3) 确定范式级别,根据应用环境,对某些模式进行合并或分解。
以上工作理论性比较强,主要目的是设计一个数据冗余尽量少的关系模式。下面这步则是考虑效率问题了:
(4) 对关系模式进行必要的分解。
如果一个关系模式的属性特别多,就应该考虑是否可以对这个关系进行垂直分解。如果有些属性是经常访问的,而有些属性是很少访问的,则应该把它们分解为两个关系模式。
如果一个关系的数据量特别大,就应该考 虑是否可以进行水平分解。如一个论坛中,如果设计时把会员发的主贴和跟贴设计为一个关系,则在帖子量非常大的情况下,这一步就应该考虑把它们分开了。因为 显示的主贴是经常查询的,而跟贴则是在打开某个主贴的情况下才查询。又如手机号管理软件,可以考虑按省份或其它方式进行水平分解。 这部分主要是考虑使用方便性和效率问题,主要借助视图手段实现,包括:
(1) 建立视图,使用更符合用户习惯的别名。
(2)对不同级别的用户定义不同的视图,以保证系统的安全性。
(3)对复杂的查询 *** 作,可以定义视图,简化用户对系统的使用。
物理设计主要工作是选择存取方法(索引),以及确定数据库的存储结构,这里就不说明了。
看看你要找的这里有没有?
※数据库的概念与用途
?数据库的概念
什么是数据库呢当人们从不同的角度来描述这一概念时就有不同的定义(当然是描述性的)。例如,称数据库是一个"记录保存系统"(该定义强调了数据库是若干记录的集合)。又如称数据库是"人们为解决特定的任务,以一定的组织方式存储在一起的相关的数据的集合"(该定义侧重于数据的组织)。更有甚者称数据库是"一个数据仓库"。当然,这种说法虽然形象,但并不严谨。严格地说,数据库是"按照数据结构来组织、存储和管理数据的仓库"。在经济管理的日常工作中,常常需要把某些相关的数据放进这样"仓库",并根据管理的需要进行相应的处理。例如,企业或事业单位的人事部门常常要把本单位职工的基本情况(职工号、姓名、年龄、性别、籍贯、工资、简历等)存放在表2063中,这张表就可以看成是一个数据库。有了这个"数据仓库"我们就可以根据需要随时查询某职工的基本情况,也可以查询工资在某个范围内的职工人数等等。这些工作如果都能在计算机上自动进行,那我们的人事管理就可以达到极高的水平。此外,在财务管理、仓库管理、生产管理中也需要建立众多的这种"数据库",使其可以利用计算机实现财务、仓库、生产的自动化管理。
JMartin给数据库下了一个比较完整的定义:数据库是存储在一起的相关数据的集合,这些数据是结构化的,无有害的或不必要的冗余,并为多种应用服务;数据的存储独立于使用它的程序;对数据库插入新数据,修改和检索原有数据均能按一种公用的和可控制的方式进行。当某个系统中存在结构上完全分开的若干个数据库时,则该系统包含一个"数据库集合"。
数据库的优点
使用数据库可以带来许多好处:如减少了数据的冗余度,从而大大地节省了数据的存储空间;实现数据资源的充分共享等等。此外,数据库技术还为用户提供了非常简便的使用手段使用户易于编写有关数据库应用程序。特别是近年来推出的微型计算机关系数据库管理系统dBASELL, *** 作直观,使用灵活,编程方便,环境适应广泛(一般的十六位机,如IBM/PC/XT,国产长城0520等均可运行种软件),数据处理能力极强。数据库在我国正得到愈来愈广泛的应用,必将成为经济管理的有力工具。
数据库是通过数据库管理系统(DBMS-DATA BASE MANAGEMENT SYSTEM)软件来实现数据的存储、管理与使用的dBASELL就是一种数据库管理系统软件。
数据库结构与数据库种类
数据库通常分为层次式数据库、网络式数据库和关系式数据库三种。而不同的数据库是按不同的数据结构来联系和组织的。
1数据结构模型
(1)数据结构
所谓数据结构是指数据的组织形式或数据之间的联系。如果用D表示数据,用R表示数据对象之间存在的关系集合,则将DS=(D,R)称为数据结构。例如,设有一个电话号码簿,它记录了n个人的名字和相应的电话号码。为了方便地查找某人的电话号码,将人名和号码按字典顺序排列,并在名字的后面跟随着对应的电话号码。这样,若要查找某人的电话号码(假定他的名字的第一个字母是Y),那么只须查找以Y开头的那些名字就可以了。该例中,数据的集合D就是人名和电话号码,它们之间的联系R就是按字典顺序的排列,其相应的数据结构就是DS=(D,R),即一个数组。
(2)数据结构种类
数据结构又分为数据的逻辑结构和数据的物理结构。数据的逻辑结构是从逻辑的角度(即数据间的联系和组织方式)来观察数据,分析数据,与数据的存储位置无关。数据的物理结构是指数据在计算机中存放的结构,即数据的逻辑结构在计算机中的实现形式,所以物理结构也被称为存储结构。本节只研究数据的逻辑结构,并将反映和实现数据联系的方法称为数据模型。
目前,比较流行的数据模型有三种,即按图论理论建立的层次结构模型和网状结构模型以及按关系理论建立的关系结构模型。
2层次、网状和关系数据库系统
(1)层次结构模型
层次结构模型实质上是一种有根结点的定向有序树(在数学中"树"被定义为一个无回的连通图)。例如图2064是一个高等学校的组织结构图。这个组织结构图像一棵树,校部就是树根(称为根结点),各系、专业、教师、学生等为枝点(称为结点),树根与枝点之间的联系称为边,树根与边之比为1:N,即树根只有一个,树枝有N个。这种数据结构模型的一般结构见图2065所示。
图2064 高等学校的组织结构图 图2065 层次结构模型
图2065中,Ri(i=1,2,…6)代表记录(即数据的集合),其中R1就是根结点(如果Ri看成是一个家族,则R1就是祖先,它是R2、R3、R4的双亲,而R2、R3、R4互为兄弟),R5、R6也是兄弟,且其双亲为R3。R2、R4、R5、R6又被称为叶结点(即无子女的结点)。这样,Ri(i=1,2,…6)就组成了以R1为树根的一棵树,这就是一个层次数据结构模型。
按照层次模型建立的数据库系统称为层次模型数据库系统。IMS(Information Manage-mentSystem)是其典型代表。
(2)网状结构模型
在图2066中,给出了某医院医生、病房和病人之间的联系。即每个医生负责治疗三个病人,每个病房可住一到四个病人。如果将医生看成是一个数据集合,病人和病房分别是另外两个数据集合,那么医生、病人和病房的比例关系就是M:N:P(即M个医生,N个病人,P间病房)。这种数据结构就是网状数据结构,它的一般结构模型如图2067所示。在图中,记录Ri(i=1,2,8)满足以下条件:
①可以有一个以上的结点无双亲(如R1、R2、R3)。
②至少有一个结点有多于一个以上的双亲。在"医生、病人、病房"例中,"医生集合有若干个结点(M个医生结点)无"双亲",而"病房"集合有P个结点(即病房),并有一个以上的"双亲"(即病人)。
图2066 医生、病房和病人之间的关系
图2067 网状结构模型
按照网状数据结构建立的数据库系统称为网状数据库系统,其典型代表是DBTG(Data Base Task Group)。用数学方法可将网状数据结构转化为层次数据结构。
(3)关系结构模型
关系式数据结构把一些复杂的数据结构归结为简单的二元关系(即二维表格形式)。例如某单位的职工关系就是一个二元关系(见表2068)。这个四行六列的表格的每一列称为一个字段(即属性),字段名相当于标题栏中的标题(属性名称);表的每一行是包含了六个属性(工号、姓名、年龄、性别、职务、工资)的一个六元组,即一个人的记录。这个表格清晰地反映出该单位职工的基本情况。
表2068 职工基本情况
通常一个m行、n列的二维表格的结构如表2069所示。
表中每一行表示一个记录值,每一列表示一个属性(即字段或数据项)。该表一共有m个记录。每个记录包含n个属性。
作为一个关系的二维表,必须满足以下条件:
(1)表中每一列必须是基本数据项(即不可再分解)。
(2)表中每一列必须具有相同的数据类型(例如字符型或数值型)。
(3)表中每一列的名字必须是唯一的。
(4)表中不应有内容完全相同的行。
(5)行的顺序与列的顺序不影响表格中所表示的信息的含义。
由关系数据结构组成的数据库系统被称为关系数据库系统。
在关系数据库中,对数据的 *** 作几乎全部建立在一个或多个关系表格上,通过对这些关系表格的分类、合并、连接或选取等运算来实现数据的管理。dBASEII就是这类数据库管理系统的典型代表。对于一个实际的应用问题(如人事管理问题),有时需要多个关系才能实现。用dBASEII建立起来的一个关系称为一个数据库(或称数据库文件),而把对应多个关系建立起来的多个数据库称为数据库系统。dBASEII的另一个重要功能是通过建立命令文件来实现对数据库的使用和管理,对于一个数据库系统相应的命令序列文件,称为该数据库的应用系统。因此,可以概括地说,一个关系称为一个数据库,若干个数据库可以构成一个数据库系统。数据库系统可以派生出各种不同类型的辅助文件和建立它的应用系统。
数据库的要求与特性
为了使各种类型的数据库系统能够充分发挥它们的优越性,必须对数据库管理系统的使用提出一些明确的要求。
1建立数据库文件的要求
(1)尽量减少数据的重复,使数据具有最小的冗余度。计算机早期应用中的文件管理系统,由于数据文件是用户各自建立的,几个用户即使有许多相同的数据也得放在各自的文件中,因而造成存储的数据大量重复,浪费存储空间。数据库技术正是为了克服这一缺点而出现的,所以在组织数据的存储时应避免出现冗余。
(2)提高数据的利用率,使众多用户都能共享数据资源。
(3)注意保持数据的完整性。这对某些需要历史数据来进行预测、决策的部门(如统计局、银行等)特别重要。
(4)注意同一数据描述方法的一致性,使数据 *** 作不致发生混乱。如一个人的学历在人事档案中是大学毕业,而在科技档案中却是大学程度,这样就容易造成混乱。
(5)对于某些需要保密的数据,必须增设保密措施。
(6)数据的查找率高,根据需要数据应能被及时维护。
2数据库文件的特征
无论使用哪一种数据库管理系统,由它们所建立的数据库文件都可以看成是具有相同性质的记录的集合,因而这些数据库文件都有相同的特性:
(1)文件的记录格式相同,长度相等。
(2)不同的行是不同的记录,因而具有不同的内容。
(3)不同的列表示不同的字段名,同一列中的数据的性质(属性)相同。
(4)每一行各列的内容是不能分割的,但行的顺序和列的顺序不影响文件内容的表达。
3文件的分类
对文件引用最多的是主文件和事物文件。其他的文件分类还包括表文件、备份文件、档案的输出文件等。下面将讲述这些文件。
(1)主文件。主文件是某特定应用领域的永久性的数据资源。主文件包含那些被定期存取以提供信息和经常更新以反映最新状态的记录。典型的主文件有库存文件、职工主文件和收帐主文件等。
(2)事务文件。事务文件包含着作为一个信息系统的数据活动(事务)的那些记录。这些事务被分批以构成事务文件。例如,从每周工资卡上录制下来的数分批存放在一个事务文件上,然后对照工资清单文件进行处理以便打印出工资支票和工资记录簿。
(3)表文件。表文件是一些表格。之所以单独建立表文件而不把表设计在程序中是为了便于修改。例如,一个公用事业公司的税率表或国内税务局的税率就可以存储在表中文件。
(4)备用文件。备用文件是现有生产性文件的一个复制品。一旦生产性文件受到破坏,利用备用文件就可以重新建立生产性文件。
(5)档案文件。档案文件不是提供当前处理使用的,而是保存起来作为历史参照的。例如,国内税务局(IRS)可能要求检查某个人最近15年的历史。实际上,档案文件恰恰是在给定时间内工作的一个"快照"。
(6)输出文件。输出文件包含将要打印在打印机上的、显在屏幕上的或者绘制在绘图仪上的那些信息的数值映象。输出文件可以是"假脱机的"(存储在辅存设备上),当输出设备可
用时才进行实际的输出。
典型矿床数据库是实物地质资料数据库的一个重要组成部分,主要用于管理收集到国家实物库内的典型矿床实物地质资料,为用户和政府管理部门提供动态、准确、可靠的实物资料信息。
典型矿床数据库主要实现矿种、矿床、岩心、标本等属性数据录入、查询以及图层(像)信息采集入库和可视化浏览。典型矿床实物地质资料数据信息按统一的属性标准确定所需收集各项属性指标并编录入库,进行统一管理,为用户提供方便、快捷的查询界面。该库包含了大量的实物地质资料数据信息,如:矿床规模、矿床成因、成矿时代、矿体形状等反映矿床特征的数据信息。
典型矿床数据库采用SQL-SERVER-2000、ACCESS-97数据库软件开发属性数据库,空间数据库采用ARC/INFO8x软件开发,用户界面采用Visual-Basic-60语言和Map Objects控件开发。
一、属性数据
典型矿床数据库的属性数据由10个数据表组成,矿种表主要描述矿种的信息,ID号表示矿种的序列号,与矿床表、岩矿心表等其他数据表的ID号一一对应。岩心表主要描述岩心的产生情况和属性参数。数据库基表如表1所示。
表1 典型矿床数据库基本参数
续表
岩矿心、标本以矿床(点)或勘探区的单个钻孔、标本采集点为基本单元,其副样、光薄片与之对应。
属性表之间的关系如图1所示。
图1 典型矿床属性表关系
二、空间数据
空间数据主要由中国政区图、地理地图、典型矿床的图层、图像组成。利用ARC/INFO软件,根据典型矿床属性表中的位置属性项建立典型矿床空间数据的专题图层。
典型矿床数据的图层包括(图2):矿床种类图层、岩矿心图层、岩石标本图层;根据不同的矿床种类,建立各种矿床的图层(40~50个);同种矿床的点图元,构成同种矿床的图层(如铜、铁、金等);每种矿床的岩矿心图斑(点图元组成),构成同种矿床的岩矿心图层;每种矿床的岩石标本图斑,构成同种矿床的岩石标本图层。
图像:岩矿心柱状图、岩矿心荧光图、岩矿心自然光图、岩石标本图、光薄片图。
空间数据与属性数据采用ARC/INFO软件格式建立拓扑关系。
图2 典型矿床数据结构图
三、用户界面
用户界面采用VB的多文档(MDI)界面样式[1]。主窗体界面采用下拉式菜单显示典型矿床数据库属性表的信息。典型矿床属性数据、空间数据的录入、修改、查询,采用卡片式的界面。典型矿床实物地质资料数据库的主窗体界面和卡片式录入界面如图3、图4所示。
图3 典型矿床实物地质资料数据库主窗体界面
图4 卡片式录入界面
以上就是关于什么是数据库系统的体系结构全部的内容,包括:什么是数据库系统的体系结构、数据库的逻辑结构设计的图向关系、数据库的组织结构是什么等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)