数据库管理系统

1.5 数据模型和数据存储

2021-04-11  本文已影响0人  橡树人

数据库管理系统的用户最终关心的是某个现实世界中的企业,在数据库管理系统中存储的数据描述了该企业的方方面面。比如,在一个大学里,有学生、教师、课程等实体。在大学数据库中的数据描述了这些实体及其之间的关系

一个数据模型就是一个由高级数据描述结构组成的集合,隐藏了许多底层的存储细节。数据库管理系统允许用户使用数据模型的术语来定义要存储的数据。本书重点介绍的是关系数据模型,它是今天许多数据库管理系统的基础。

虽然数据模型隐藏了很多细节,但是跟用户如何看待蕴含的企业相比,数据模型还是更接近数据库管理系统如何存储数据。

一个语义数据模型是一个更抽象的高级数据模型,使得用户能够更容易地构想出一个良好的有关企业数据的初始描述。

这些模型包含了许多对描述企业实际场景有帮助的结构。数据库管理系统并不打算直接支持所有的结构,它是围绕仅有几个基础结构的数据模型构建的,比如关系模型。

使用语义模型描述的数据库设计可以作为一个很好的开始,并在接下来被转换成使用数据库管理系统实际支持的数据模型描述的数据库设计。

一个广泛使用的语义模型是实体-关系模型,允许我们图形化描述实体及其之间的关系,详情请看第2章。

1.5.1 关系数据模型

本小节简单介绍了关系模型。

在关系模型中,核心的数据描述结构是关系,关系可被认为是一个由记录组成的集合。

一个schema就是使用数据模型提供的术语对数据进行的一个描述。

在关系模型中,一个关系的schema描述了关系的名字、每个字段的名字、每个字段的类型。比如,在一个大学数据库中的学生信息可能存储在一个有如下schema的关系中:

Student(sid:string,name:string,login :string,age:integer,gpa:real)

上述schema说的是在Student关系中的每个记录有5个字段,且指出了每个字段的名字和类型。

在Student关系中的每一行是一条描述了一个学生的记录。注意,虽然这份描述是不完整的,但是对一个大学数据库的潜在应用已经足够了。每行遵守了Student关系的schema。因此,可以认为schema是描述一个学生的模板。

通过应用在一个关系中的每个记录必须要满足的完整性约束,我们可以更精确地描述多个学生组成的集合。比如,我们可以要求:每个学生必须有唯一的sid。注意到,简单地向Student关系中添加一个字段是不能实现前述要求的。对一个字段的值的唯一性描述会提升数据描述的精确性。可用的描述完整性约束的结构是一个数据模型中很重要的方面。

其他的数据模型

除了关系模型外,还有分层模型、网络模型、面向对象数据模型、对象关系数据模型。虽然有许多数据库使用层级和网络模型,基于面向对象与对象关系模型的数据库系统在市场上不断获得认可,但是占主导位置的模型依然是关系模型。

在这本书中,我们的重点是关系模型,因为它的广泛使用和重要性。确实,对象-关系模型正在努力地整合关系模型和面向对象的基本特征,理解关系模型对理解对象关系概念是必须的,详情请看第23章。

1.5.2 分层抽象

在数据库管理系统中,通过三个抽象层来描述数据。数据库描述是由在每个抽象层上的一个schema组成的。这3个抽象层依次是概念层、物理层、外部层。

使用数据定义语言DDL来定义外部schema和概念schema。我们将在第3章中讨论SQL的DDL。虽然所有数据库管理系统都支持命令来描述物理schema,但是这些命令不是SQL语言标准的一部分。有关概念schema、外部schema、物理schema的信息被保存在系统目录中,详情请看12.1节。本节剩余部分讨论3个抽象层。

概念schema

概念schema是用数据库管理系统的数据模型术语来描述被存储的数据。

在关系数据库系统中,概念schema描述了在数据库中存储的所有关系。在我们简单的大学示例中,这些关系包括了有关实体的信息,比如学生和教师等实体,以及实体之间的关系,比如学生注册课程等关系。如前面所示,使用Student关系中的记录来描述所有学生的实体。实际上,每个由实体组成的集合以及每个由关系组成的集合都可用一个关系来描述,得到了如下所示的概念schema:

选择关系及其字段并不是那么的显然,获取一个良好的概念schema的过程就是概念数据库设计,详情请看第2、19章。

物理schema

物理schema描述了额外的存储细节。从本质上看,物理schema总结了在概念schema中描述的数据是如何被保存在诸如硬盘等二级存储设备中的。

我们必须决定使用什么样的文件组织来存储关系。为了加速数据检索操作,我们必须创建索引这类额外的数据结构。

大学数据库的物理schema示例如下所示:

基于对如何访问数据的理解,做出有关物理schema的决定。达到一个良好的物理schema的过程就是物理数据库设计,详情请看第20章。

外部schema

外部schema也是用数据库管理系统的数据模型来描述的,允许数据被独立的用户或者用户群自定义访问。

任何一个给定的数据库有且只有一个概念schema和一个物理schema,因为虽然它仅有一个存储的关系集,但是它可能有多个为特定用户群组自定义的外部schema。

每个外部schema是由一个或者多个视图及来自概念schema的关系组成的集合。

从概念上讲,一个视图就是一个关系,但是在数据库管理系统中不存储它的记录。视图的记录是使用视图的定义、通过存储在DBMS中的关系计算出来的。详情请看第3章、第25章。

终端用户的需求指导着外部shema的设计。比如,假设要找出所有教课的教师姓名以及课程注册人数。可定义如下视图:

Courseinfo(rid:string, fname:string, enrollment:integer)

用户把视图看做是关系,对视图中的记录提出问题。视图中的记录不是被显式地被存储,是被按需计算出来的。因为能根据来自概念schema的关系中计算出Courseinfo,且额外存储Courseinfo是多余的,所以概念schema中不包括Courseinfo。这样的冗余不仅浪费空间,而且会导致不一致。比如,有可能出现:向Enrolled关系中插入一条记录表明某个学生注册了某门课,但是没有增加Courseinfo中的enrollment字段的值。

1.5.3 数据独立性

使用DBMS的一个非常重要的优点是它提供了数据独立性,即应用程序不受数据结构和存储方式变化的影响

通过使用3层数据抽象可以实现数据独立性,尤其是概念shecma和外部schema为数据独立性提供了明显的好处。

从原理上看,在外部shema(视图关系)中的关系是按需从概念schema的关系中生成。如果底层的数据被重新组织了,即概念schema发生了变化,则可以修改视图关系的定义来使得:可以向之前一样来计算同样的视图关系。

比如,在我们的大学数据库中的Faculty关系被如下两个关系取代:

Faculty_public(fid:string, fname:string, office:integer)
Faculty_private(fid:string, sal:real)

从直觉上看,有关教师的一些保密信息被放到了一张单独的表里,并增加了有关office的信息。Courseinfo视图关系可以用Faculty_public和Faculty_private来重新定义,以便一个查询Courseinfo的用户可跟之前一样得到相同的答案。

因此,用户是被屏蔽了数据的逻辑结构的改变,或者选择存储哪些关系的改变。这种性质就是逻辑数据独立性

接着,概念schema向用户屏蔽了物理存储细节的改变,比如数据在硬盘上如何放置、文件结构、索引的选择等细节,这种性质就是物理数据独立性。只要概念schema保持一样,则我们就可以改变存储细节而不用改变应用。

上一篇下一篇

猜你喜欢

热点阅读