2.4 数据库系统基础
作为信息系统核心和基础的数据库技术得到越来越广泛的应用，从小型单项事务处理系统到大型信息系统，从联机事务处理到联机分析处理，从一般企业管理到计算机辅助设计与制造、计算机集成制造系统、电子政务、电子商务和地理信息系统等，越来越多新的应用领域采用数据库技术来存储和处理信息资源。
2.4.1 数据模型
数据模型（Data Model）是对现实世界数据特征的抽象，是用来描述数据、组织数据和对数据进行操作的。
由于计算机不可能直接处理现实世界中的具体事物，所以人们必须事先把具体事物转换成计算机能够处理的数据。也就是首先要数字化，把现实世界中具体的人、物、活动、概念用数据模型这个工具来抽象、表示和处理。
通俗地讲，数据模型就是现实世界的模拟。现有的数据库系统均是基于某种数据模型的。数据模型是数据库系统的核心和基础。了解数据模型的基本概念是学习数据库的基础。
1.两类数据模型
数据模型应满足三方面要求：一是能比较真实地模拟现实世界；二是容易被人所理解；三是便于在计算机上实现。一种数据模型要很好地、全面地满足这三方面的要求目前尚很困难。因此，在数据库系统中针对不同的使用对象和应用目的，采用不同的数据模型。
如同在建筑设计和施工的不同阶段需要不同的图纸一样，在开发实施数据库应用系统中，也需要使用不同的数据模型：概念模型、逻辑模型和物理模型。
根据模型应用的不同目的，可以将这些模型划分为两类，它们分别属于两个不同的层次。第一类是概念模型，第二类是逻辑模型和物理模型。
第一类是概念模型（Conceptual Model），也称信息模型，它按用户的观点来对数据和信息建模，主要用于数据库设计。
第二类中的逻辑模型主要包括层次模型（Hierarchical Model）、网状模型（Network Model）、关系模型（Relational Model）、面向对象模型（Object Oriented Model）和对象关系模型（Object Relational Model）等。它按计算机系统的观点对数据建模，主要用于数据库管理系统（DBMS）的实现。
第二类中的物理模型是对数据最低层的抽象，它描述数据在系统内部的表示方式和存取方法，在磁盘或磁带上的存储方式和存取方法，是面向计算机系统的。物理模型的具体实现是DBMS的任务，数据库设计人员要了解和选择物理模型，一般用户则不必考虑物理级的细节。
数据模型是数据库系统的核心和基础。各种机器上实现的DBMS软件都是基于某种数据模型或者说是支持某种数据模型的。
为了把现实世界中的具体事物抽象、组织为某一DBMS支持的数据模型，人们常常首先将现实世界抽象为信息世界，然后将信息世界转换为机器世界。也就是说，首先把现实世界中的客观对象抽象为某一种信息结构，这种信息结构并不依赖于具体的计算机系统，不是某一个DBMS支持的数据模型，而是概念级的模型；然后再把概念模型转换为计算机上某一DBMS支持的数据模型。
从现实世界到概念模型的转换是由数据库设计人员完成的，从概念模型到逻辑模型的转换可以由数据库设计人员完成，也可以用数据库设计工具协助设计人员完成，从逻辑模型到物理模型的转换一般是由DBMS完成的。
2.数据模型的组成要素
一般地讲，数据模型是严格定义的一组概念的集合。这些概念精确地描述了系统的静态特性、动态特性和完整性约束条件（Integrity Constraints）。因此，数据模型通常由数据结构、数据操作和完整性约束三部分组成。
1）数据结构
数据结构描述数据库的组成对象及对象之间的联系。也就是说，数据结构描述的内容有两类：一类是与对象的类型、内容、性质有关的，如网状模型中的数据项、记录及关系模型中的域、属性、关系等；另一类是与数据之间联系有关的对象，如网状模型中的系型（Set Type）。
数据结构是刻画一个数据模型性质最重要的方面。因此，在数据库系统中，人们通常按照其数据结构的类型来命名数据模型。例如，层次结构、网状结构和关系结构的数据模型分别命名为层次模型、网状模型和关系模型。
总之，数据结构是所描述的对象类型的集合，是对系统静态特性的描述。
2）数据操作
数据操作是指对数据库中各种对象（型）的实例（值）允许执行的操作的集合，包括操作及有关的操作规则。
数据库主要有查询和更新（包括插入、删除、修改）两大类操作。数据模型必须定义这些操作的确切含义、操作符号、操作规则（如优先级）及实现操作的语言。
数据操作是对系统动态特性的描述。
3）完整性约束
数据的完整性约束条件是一组完整性规则。完整性规则是给定的数据模型中数据及其联系所具有的制约和依存规则，用以限定符合数据模型的数据库状态及状态的变化，以保证数据正确、有效、相容。
数据模型应该反映和规定本数据模型必须遵守的基本的通用的完整性约束条件。例如，在关系模型中，任何关系必须满足实体完整性和参照完整性两个条件（在关系数据库和数据库完整性等有关章节中将详细讨论这两个完整性约束条件）。
此外，数据模型还应该提供定义完整性约束条件的机制，以反映具体应用所涉及的数据必须遵守的特定的语义约束条件。例如，某大学的数据库中规定学生成绩如果有6门以上不及格将不能授予学士学位，教授的退休年龄是65 周岁，男职工的退休年龄是60周岁，女职工的退休年龄是55周岁等。
2.4.2 概念模型
概念模型实际上是现实世界到机器世界的一个中间层次，用于信息世界的建模，是现实世界到信息世界的第一层抽象，是数据库设计人员进行数据库设计的有力工具，也是数据库设计人员和用户之间进行交流的语言，因此概念模型一方面应该具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识，另一方面它还应该简单、清晰、易于被用户理解。
1.信息世界中的基本概念
信息世界涉及的概念主要有如下几个。
（1）实体（Entity）。客观存在并可相互区别的事物称为实体。实体可以是具体的人、事、物，也可以是抽象的概念或联系，如一个职工、一个学生、一个部门、一门课、学生的一次选课、一次订货、老师与院系的工作关系（即某位老师在某院系工作）等都是实体。
（2）属性（Attribute）。实体所具有的某一特性称为属性。一个实体可以由若干个属性来刻画。例如，学生实体可以由学号、姓名、性别、出生年月、所在院系、入学时间等属性组成。（94002268，张山，男，197605，计算机系，1994）这些属性组合起来表征了一个学生。
（3）码（Key）。唯一标识实体的属性集称为码，如学号是学生实体的码。
（4）域（Domain）。域是一组具有相同数据类型的值的集合。属性的取值范围来自某个域。例如，学号的域为8 位整数，姓名的域为字符串集合，学生年龄的域为整数，性别的域为（男，女）。
（5）实体型（Entity Type）。具有相同属性的实体必然具有共同的特征和性质。用实体名及其属性名的集合来抽象和刻画同类实体，称为实体型。例如，学生（学号，姓名，性别，出生年月，所在院系，入学时间）就是一个实体型。
（6）实体集（Entity Set）。同一类型实体的集合称为实体集。例如，全体学生就是一个实体集。
（7）联系（Relationship）。在现实世界中，事物内部及事物之间是有联系的，这些联系在信息世界中反映为实体（型）内部的联系和实体（型）之间的联系。实体内部的联系通常指组成实体的各属性之间的联系；实体之间的联系通常指不同实体集之间的联系。
2.两个实体型之间的联系
两个实体型之间的联系可以分为以下三种。
1）一对一联系（1:1）
如果对于实体集A中的每一个实体，实体集B中至多有一个（也可以没有）实体与之联系，反之亦然，则称实体集A与实体集B具有一对一的联系，记为1:1。
例如，学校里面，一个班级只有一个正班长，而一个班长只在一个班中任职，则班级与班长之间具有一对一联系。
2）一对多联系（1:n）
如果对于实体集A中的每一个实体，实体集B中有n个实体（n≥0）与之联系，反之，对于实体集B中的每一个实体，实体集A中至多只有一个实体与之联系，则称实体集A与实体集B有一对多联系，记为1:n。
例如，一个班级中有若干名学生，而每个学生只在一个班级中学习，则班级与学生之间具有一对多联系。
3）多对多联系（m:n）
如果对于实体集A中的每一个实体，实体集B中有n个实体（n≥0）与之联系，反之，对于实体集 B 中的每一个实体，实体集 A 中也有 m个实体（m≥0）与之联系，则称实体集A与实体集B具有多对多联系，记为m:n。
例如，一门课程同时有若干名学生选修，而一名学生可以同时选修多门课程，则课程与学生之间具有多对多联系。
实际上，一对一联系是一对多联系的特例，而一对多联系又是多对多联系的特例。
3.概念模型的表示方法
概念模型是对信息世界建模，所以概念模型应该能够方便、准确地表示出信息世界中的常用概念。概念模型的表示方法很多，其中最为著名、最为常用的是陈（P.P.S. Chen）于1976年提出的实体-联系方法（Entity-Relationship Approach）。该方法用E-R图（E-R Diagram）来描述现实世界的概念模型，E-R方法也称为E-R模型。
E-R图提供了表示实体型、属性和联系的方法。
● 实体型：用矩形表示，矩形框内写明实体名。
● 属性：用椭圆形表示，并用无向边将其与相应的实体型连接起来。
● 联系：用菱形表示。菱形框内写明联系名，并用无向边分别与有关实体型连接起来，同时在无向边旁标上联系的类型（1:1、1:n或m:n）。
须注意的是：如果一个联系具有属性，则这些属性也要用无向边与该联系连接起来。
2.4.3 关系模型
关系模型是目前最重要的一种数据模型。关系数据库系统采用关系模型作为数据的组织方式。
1970年，美国IBM公司San Jose研究室的研究员柯德（E.F. Codd）首次提出了数据库系统的关系模型，开创了数据库关系方法和关系数据理论的研究，为数据库技术奠定了理论基础。由于柯德的杰出工作，他于1981年获得ACM图灵奖。
20 世纪80年代以来，计算机厂商推出的数据库管理系统几乎都支持关系模型，非关系系统的产品大都加上了关系接口。数据库领域当前的研究工作也都是以关系方法为基础的。
1.关系模型的数据结构
关系模型与以往的模型不同，它是建立在严格的数学概念的基础上的。这里只简单勾画一下关系模型。从用户的角度看，关系模型由一组关系组成。每个关系的数据结构是一张规范化的二维表。现在以学生登记表（见图2.16）为例，介绍关系模型中的一些术语。
图2.16 关系模型的数据结构
（1）关系（Relation）：一个关系对应一张二维表，如图2.16所示的这张学生登记表。
（2）元组（Tuple）：表中的一行即为一个元组。
（3）属性（Attribute）：表中的一列即为一个属性，给每一个属性起一个名称即属性名。例如，学生登记表有6 列，对应6个属性（学号，姓名，年龄，性别，系名和年级）。
（4）码（Key）：也称为码键。表中的某个属性组，它可以唯一确定一个元组，如图2.16所示的学号，可以唯一确定—个学生，也就成为本关系的码。
（5）域（Domain）：属性的取值范围，如人的年龄一般在1～150岁之间，大学生年龄属性的域是（14～38），性别的域是（男，女），系名的域是一个学校所有系名的集合。
（6）分量：元组中的一个属性值。
（7）关系模式：对关系的描述，—般表示为
关系名（属性1，属性2，…，属性n）
例如，上面的关系可描述为
学生（学号，姓名，年龄，性别，系名，年级）
在关系模型中，实体及实体间的联系都是用关系来表示的。例如，学生、课程、学生与课程之间的多对多联系在关系模型中可以表示如下：
学生（学号，姓名，年龄，性别，系名，年级）
课程（课程号，课程名，学分）
选修（学号，课程号，成绩）
关系模型要求关系必须是规范化的，即要求关系必须满足一定的规范条件，这些规范条件中最基本的一条就是：关系的每个分量必须是一个不可分的数据项，也就是说，不允许表中还有表。
2.关系模型的操作与完整性约束
关系模型的操作主要包括查询、插入、删除和更新数据。这些操作必须满足关系的完整性约束条件。关系的完整性约束条件包括三大类：实体完整性、参照完整性和用户定义的完整性。
关系模型中的数据操作是集合操作，操作对象和操作结果都是关系，即若干元组的集合，而不像格式化模型中那样是单记录的操作方式。另一方面，关系模型把存取路径向用户隐蔽起来，用户只要指出“干什么”或“找什么”，不必详细说明“怎么干”或“怎么找”，从而大大地提高了数据的独立性，提高了效率。
在关系数据库中，典型的操作包括：插入、删除、更新、选择、投影、连接、并、交和差等。
插入操作是一种一元操作，它应用于一个关系，其操作是在表中插入新的元组。
删除操作也是一元操作，它根据要求删去表中相应的元组。
更新操作也是一元操作，它应用于一个关系，用来更新元组中的部分属性值。
选择操作也是一元操作，它应用于一个关系并产生另外一个新关系。新关系中的元组（行）是原关系中元组的子集。选择操作根据要求从原关系中选择部分元组。该操作中属性（列）的数量保持不变。
投影操作也是一元操作，它用于一个关系并产生另外一个关系。新关系中的属性（列）是原关系中属性的子集。投影操作所得到的新关系中的元组属性减少。在这个操作中元组（行）的数量保持不变。
连接操作是二元操作。它基于共有的属性把两个关系组合起来。连接操作十分复杂并有很多变化。
并操作也是二元操作。它将两个关系组合成一个新的关系。不过这里对这两个关系有一个限制，即它们必须有相同的属性。根据集合论中的定义，并操作创建的新关系中的每一个元组在第一个关系、第二个关系，或者在两关系中皆有。
交操作也是二元操作，它对两关系进行操作，创建一个新关系。和并操作一样，进行交操作的两个关系必须有相同的属性。根据集合论中的定义，交操作创建的新关系中的每一个元组必须是两个原关系中共有的成员。
差操作也是二元操作，它应用于具有相同属性的两个关系。生成的关系中的元组是那些存在于第一个关系中而不在第二个关系中的元组。
3.关系模型的存储结构
在关系数据模型中，实体及实体间的联系都用表来表示。在关系数据库的物理组织中，有的DBMS中一个表对应一个操作系统文件，有的DBMS从操作系统获得若干个大的文件，自己设计表索引等存储结构。
4.结构化查询语言
结构化查询语言（SQL）是美国国家标准协会（ANSI）和国际标准组织（ISO）用于关系数据库的标准化语言。这是一种描述性（不是过程化）的语言，这意味着使用者不需要编写一步步的详细程序而只须声明它。结构化查询语言最早于1979年首次被Oracle公司实现，之后有了更多的新版本SQL。
下面是与关系模型的操作有关的结构化查询语言中的常用语句。
插入操作使用如下格式。values子句定义了与插入的元组相对应的属性值。
INSERT INTO RELATION-NAME
VALUES{…, …, …}
删除操作的一般格式如下。删除需要满足的条件定义在WHERE子句中。
DELETE FROM RELATION-NAME
WHERE criteria
更新操作使用如下的格式。需要更新的属性在set子句中定义。where子句中则定义了要更新的元组须满足的条件。
UPDATE RELATION-NAME
SET attribute1=value1,attribute2 = value2, …
WHERE criteria
选择操作使用如下的格式。*表示选择所有的属性。
SELECT *
FROM RELATION-NAME
WHERE criteria
投影操作使用如下的格式，新关系的列名被显式地列出。
SELECT attribute-list
FROM RELATION-NAME
连接操作使用如下的格式，属性列表是原来两个输入关系的属性的组合。where子句明确定义了用于连接的共有属性。
SELECT attribute-list
FROM RELATION1,RELATION2
WHERE criteria
并操作使用如下的辂式。同样，这里*表示选择所有的属性。
SELECT *
FROM RELATION1
UNION
SELECT *
FROM RELATION2
交操作使用如下的格式。同样，这里*表示选择所有的属性。
SELECT *
FROM RELATION1
intersection
SELECT *
FROM RELATION2
差操作使用如下的格式。同样，这里*表示选择所有的属性。
SELECT *
FROM RELATIONl
minus
SELECT *
FROM RELATION2
SQL还允许用户组合使用上述语句以便从数据库中获得更复杂的信息。
2.4.4 数据库系统结构
认识数据库系统的结构可以有多种不同的层次或不同的角度。
从数据库管理系统角度看，数据库系统通常采用三级模式结构，这是数据库管理系统内部的系统结构。
从数据库最终用户角度看，数据库系统的结构分为单用户结构、主从式结构、分布式结构、客户机/服务器、浏览器/应用服务器/数据库服务器多层结构等，这是数据库系统外部的体系结构。
1.数据库系统模式的概念
在数据模型中有“型”（Type）和“值”（Value）的概念。型是指对某一类数据的结构和属性的说明，值是型的一个具体赋值。例如，学生记录定义为（学号，姓名，性别，系别，年龄，籍贯）这样的记录型，而（900201，李明，男，计算机，22，江苏）则是该记录型的一个记录值。
模式（Schema）是数据库中全体数据的逻辑结构和特征的描述，它仅涉及型的描述，不涉及具体的值。模式的一个具体值称为模式的一个实例（Instance）。同一个模式可以有很多实例。
例如，在学生选课数据库模式中，包含学生记录、课程记录和学生选课记录，则2003年有一个学生数据库的实例，该实例包含了2003年学校中所有学生的记录（如果某校有10000 名学生，则有10000个学生记录）、学校开设的所有课程的记录和所有学生选课的记录。
2002年度学生数据库模式对应的实例与2003年度学生数据库模式对应的实例是不同的。实际上，2003年度学生数据库的实例也会随时间变化，因为在此年度有的学生可能退学，有的学生可能转系。各个时刻学生选课数据库的实例是不同的、在变化的，而不变的是学生选课数据库模式。
模式是相对稳定的，而实例是相对变动的，因为数据库中的数据是在不断更新的。模式反映的是数据的结构及其联系，而实例反映的是数据库在某一时刻的状态。
虽然实际的数据库管理系统产品种类很多，它们支持不同的数据模型，使用不同的数据库语言，建立在不同的操作系统之上，数据的存储结构也各不相同，但它们在体系结构上通常都具有相同的特征，即采用三级模式结构（早期微型计算机上的小型数据库系统除外）并提供两级映像功能。
2.数据库系统的三级模式结构
数据库系统的三级模式结构是指数据库系统是由外模式、模式和内模式三级构成的，如图2.17所示。
图2.17 数据库系统的三级模式结构
1）模式（Schema）
模式也称逻辑模式，是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图。它是数据库系统模式结构的中间层，既不涉及数据的物理存储细节和硬件环境，也与具体的应用程序、所使用的应用开发工具及高级程序设计语言（如C、COBOL、Fortran）无关。
模式实际上是数据库数据在逻辑级上的视图。一个数据库只有一个模式。数据库模式以某一种数据模型为基础，统一综合地考虑了所有用户的需求，并将这些需求有机地结合成一个逻辑整体。定义模式时不仅要定义数据的逻辑结构，例如，数据记录由哪些数据项构成，数据项的名字、类型、取值范围等，而且要定义数据之间的联系，定义与数据有关的安全性、完整性要求。
DBMS提供模式描述语言（模式DDL）来严格地定义模式。
2）外模式（External Schema）
外模式也称子模式（Subschema）或用户模式，它是数据库用户（包括应用程序员和最终用户）能够看见和使用的局部数据的逻辑结构和特征的描述，是数据库用户的数据视图，是与某一应用有关的数据的逻辑表示。
外模式通常是模式的子集。一个数据库可以有多个外模式。由于它是各个用户的数据视图，如果不同的用户在应用需求、看待数据的方式、对数据保密的要求等方面存在差异，则其外模式描述就是不同的。即使对于模式中同一数据，在外模式中的结构、类型、长度、保密级别等都可以不同。另一方面，同一外模式也可以为某一用户的多个应用程序所使用，但一个应用程序只能使用一个外模式。
外模式是保证数据库安全性的一个有力措施。每个用户只能看见和访问所对应的外模式中的数据，数据库中的其余数据是不可见的。
DBMS提供子模式描述语言（子模式DDL）来严格地定义子模式。
3）内模式（Internal Schema）
内模式也称存储模式（Storage Schema），一个数据库只有一个内模式。它是数据物理结构和存储方式的描述，是数据在数据库内部的表示方式。例如，记录的存储方式是堆存储，还是按照某个（些）属性值的升（降）序存储，还是按照属性值聚簇（Cluster）存储；索引按照什么方式组织，是B+树索引，还是hash索引；数据是否压缩存储，是否加密；数据的存储记录结构有何规定，如定长结构或变长结构，一个记录不能跨物理页存储；等等。
DBMS提供内模式描述语言（内模式DDL或存储模式DDL）来严格地定义内模式。
3.数据库的二级映像功能与数据独立性
数据库系统的三级模式是对数据的3个抽象级别，它把数据的具体组织留给DBMS管理，使用户能逻辑地、抽象地处理数据，而不必关心数据在计算机中的具体表示方式与存储方式。为了能够在系统内部实现这3个抽象层次间的联系和转换，数据库管理系统在这三级模式之间提供了两层映像：
● 外模式/模式映像；
● 模式/内模式映像。
正是这两层映像保证了数据库系统中的数据能够具有较高的逻辑独立性和物理独立性。
1）外模式/模式映像
模式描述的是数据的全局逻辑结构，外模式描述的是数据的局部逻辑结构。对应于同一个模式可以有任意多个外模式。对于每一个外模式，数据库系统都有一个外模式/模式映像，它定义了该外模式与模式之间的对应关系。这些映像定义通常包含在各自外模式的描述中。
当模式改变时（如增加新的关系、新的属性、改变属性的数据类型等），由数据库管理员对各个外模式/模式的映像做相应的改变，可以使外模式保持不变。应用程序是依据数据的外模式编写的，进而应用程序不必修改，保证了数据与程序的逻辑独立性，简称数据的逻辑独立性。
2）模式/内模式映像
数据库中只有一个模式，也只有一个内模式，所以模式/内模式映像是唯一的，它定义了数据全局逻辑结构与存储结构之间的对应关系。例如，说明逻辑记录和字段在内部是如何表示的。该映像定义通常包含在模式描述中。当数据库的存储结构改变了（如选用了另一种存储结构），由数据库管理员对模式/内模式映像做相应的改变，可以使模式保持不变，进而应用程序也不必改变。保证了数据与程序的物理独立性，简称数据的物理独立性。
在数据库的三级模式结构中，数据库模式即全局逻辑结构是数据库的中心与关键，它独立于数据库的其他层次。因此设计数据库模式结构时应首先确定数据库的逻辑模式。
数据库的内模式依赖于它的全局逻辑结构，但独立于数据库的用户视图，即外模式，也独立于具体的存储设备。它将全局逻辑结构中定义的数据结构及其联系按照一定的物理存储策略进行组织，以达到较好的时间与空间利用效率。
数据库的外模式面向具体的应用程序，它定义在逻辑模式之上，但独立于存储模式和存储设备。当应用需求发生较大变化使相应外模式不能满足其视图要求时，该外模式就要做相应的改动，所以设计外模式时应充分考虑到应用的扩充性。
特定的应用程序是在外模式描述的数据结构上编制的，它依赖于特定的外模式，与数据库的模式和存储结构独立。不同的应用程序有时可以共用同一个外模式。数据库的二级映像保证了数据库外模式的稳定性，进而从底层保证了应用程序的稳定性，除非应用需求本身发生变化，否则应用程序一般都不需要修改。
数据与程序之间的独立性使得数据的定义和描述可以从应用程序中分离出去。另外，由于数据的存取由DBMS管理，用户不必考虑存取路径等细节，从而简化了应用程序的编制，大大减少了应用程序的维护和修改。
2.4.5 数据库系统的组成
数据库系统一般由数据库、数据库管理系统（及其开发工具）、应用系统和数据库管理员组成。下面分别介绍这几个部分内容。
1.硬件平台及数据库
由于数据库系统数据量很大，加之DBMS丰富的功能，使得自身的规模也很大。因此，整个数据库系统对硬件资源提出了较高的要求，这些要求如下：
（1）要有足够大的内存来存放操作系统、DBMS的核心模块、数据缓冲区和应用程序；
（2）要有足够的大的磁盘或磁盘阵列等设备存放数据库，有足够多的磁带（或光盘）进行数据备份；
（3）要求系统有较高的通道能力，以提高数据传送率。
2.软件
数据库系统的软件主要包括：
（1）DBMS，DBMS是为数据库的建立、使用和维护配置的系统软件；
（2）支持DBMS运行的操作系统；
（3）具有与数据库接口的高级语言及其编译系统，便于开发应用程序；
（4）以DBMS为核心的应用开发工具，应用开发工具是系统为应用开发人员和最终用户提供的高效率、多功能的应用生成器、第四代语言等各种软件工具，它们为数据库系统的开发和应用提供了良好的环境；
（5）为特定应用环境开发的数据库应用系统。
3.人员
开发、管理和使用数据库系统的人员主要有：数据库管理员、系统分析员和数据库设计人员、应用程序员和最终用户。不同的人员涉及不同的数据抽象级别，具有不同的数据视图，各种人员的数据库视图如图2.18所示，其各自的职责分别如下所述。
图2.18 各种人员的数据库视图
1）数据库管理员（DBA，DataBase Administrator）
在数据库系统环境下，有两类共享资源：一类是数据库；另一类是数据库管理系统软件。因此，需要有专门的管理机构来监督和管理数据库系统。DBA则是这个机构中的一个（组）人员，负责全面管理和控制数据库系统。具体职责包括：
（1）决定数据库中的信息内容和结构。数据库中要存放哪些信息，DBA要参与决策。因此，DBA必须参加数据库设计的全过程，并与用户、应用程序员、系统分析员密切合作、共同协商，搞好数据库设计。
（2）决定数据库的存储结构和存取策略。DBA要综合各用户的应用要求，和数据库设计人员共同决定数据的存储结构和存取策略，以求获得较高的存取效率和存储空间利用率。
（3）定义数据的安全性要求和完整性约束条件。DBA的重要职责是保证数据库的安全性和完整性。因此，DBA负责确定各个用户对数据库的存取权限、数据的保密级别和完整性约束条件。
（4）监控数据库的使用和运行。DBA还有一个重要职责就是监视数据库系统的运行情况，及时处理运行过程中出现的问题。例如，系统发生各种故障时，数据库会因此遭到不同程度的破坏，DBA必须在最短的时间内将数据库恢复到正确状态，并尽可能不影响或少影响计算机系统其他部分的正常运行。为此，DBA要定义和实施适当的后备和恢复策略，如周期性地转存数据、维护日志文件等。
（5）数据库的改进和重组重构。DBA还负责在系统运行期间监视系统的空间利用率、处理效率等性能指标，对运行情况进行记录、统计分析，依靠工作实践并根据实际应用环境不断改进数据库设计。不少数据库产品都提供了对数据库运行状况进行监视和分析的工具，DBA可以使用这些软件完成这项工作。
另外，在数据运行过程中，大量数据不断插入、删除、修改，时间一长，会影响系统的性能。因此，DBA要定期对数据库进行重组织，以提高系统的性能。
当用户的需求增加和改变时，DBA还要对数据库进行较大的改造，包括修改部分设计，即数据库的重构造。
2）系统分析员和数据库设计人员
系统分析员负责应用系统的需求分析和规范说明，要和用户及DBA合作，确定系统的硬件和软件配置，并参与数据库系统的概要设计。
数据库设计人员负责数据库中数据的确定、数据库各级模式的设计。数据库设计人员必须参加用户需求调查和系统分析，然后进行数据库设计。在很多情况下，数据库设计人员就由数据库管理员担任。
3）应用程序员
应用程序员负责设计和编写应用系统的程序模块，并进行调试和安装。
4）用户
这里的用户是指最终用户（End User）。最终用户通过应用系统的用户接口使用数据库。常用的接口方式有浏览器、菜单驱动、表格操作、图形显示、报表书写等。
最终用户可以分为以下三类。
第一类：偶然用户。这类用户不经常访问数据库，但每次访问数据库时往往需要不同的数据库信息，这类用户一般是企业或组织机构的中高级管理人员。
第二类：简单用户。数据库的多数最终用户都是简单用户。其主要工作是查询和更新数据库，一般都是通过应用程序员精心设计的具有友好界面的应用程序存取数据库。银行的职员、航空公司的机票预定工作人员、旅馆总台服务员等都属于这类用户。
第三类：复杂用户。复杂用户包括工程师、科学家、经济学家、科学技术工作者等具有较高科学技术背景的人员。这类用户一般都比较熟悉数据库管理系统的各种功能，能够直接使用数据库语言访问数据库，甚至能够基于数据库管理系统的API编制自己的应用程序。