The architecture of DBMS packages has evolved from the early monolithic systems, where the whole
DBMS software package was one tightly integrated system, to the modern DBMS packages that are modular in design, with client/server system architecture. This evolution mirrors the trends in computing, where large centralized mainframe computers are being replaced by hundreds of distributed workstations and personal computers connected via communications networks to various types of server machines—Web servers, database servers, file servers, application servers, and so on.
In a basic client/server DBMS architecture, the system functionality is distributed between two types of modules.1 A client module is typically designed so that it will run on a user workstation or personal computer. Typically, application programs and user interfaces that access the database run in the client module. Hence, the client module handles user interaction and provides the user-friendly interfaces such as forms- or menu-based GUIs (graphical user interfaces). The other kind of module, called a server module, typically handles data storage, access, search, and other functions. We discuss client/server architectures in more detail in Section 2.5. First, we must study more basic concepts that will give us a better understanding of modern database architectures.
In this chapter we present the terminology and basic concepts that will be used throughout the book. Section 2.1 discusses data models and defines the concepts of schemas and instances, which are fundamental to the study of database systems. Then, we discuss the three-schema DBMS architecture and data independence in Section 2.2; this provides a userrsquo;s perspective on what a DBMS is supposed to do. In Section 2.3 we describe the types of interfaces and languages that are typically pro- vided by a DBMS. Section 2.4 discusses the database system software environment. Section 2.5 gives an overview of various types of client/server architectures. Finally, Section 2.6 presents a classification of the types of DBMS packages. Section 2.7 summarizes the chapter.
The material in Sections 2.4 through 2.6 provides more detailed concepts that may be considered as supplementary to the basic introductory material. 2.1 Data Models, Schemas, and Instances
One fundamental characteristic of the database approach is that it provides some level of data abstraction. Data abstraction generally refers to the suppression of details of data organization and storage, and the highlighting of the essential features for an improved understanding of data. One of the main characteristics of the database approach is to support data abstraction so that different users can perceive data at their preferred level of detail. A data model—a collection of concepts that can be used to describe the structure of a database—provides the necessary means to achieve this abstraction.2 by structure of a database we mean the data types, relationships, and constraints that apply to the data. Most data models also include a set of basic operations for specifying retrievals and updates on the database.
In addition to the basic operations provided by the data model, it is becoming more common to include concepts in the data model to specify the dynamic aspect or behavior of a database application. This allows the database designer to specify a set of valid user-defined operations that are allowed on the database objects.3 An example of a user-defined operation could be COMPUTE_GPA, which can be applied to a STUDENT object. On the other hand, generic operations to insert, delete, modify, or retrieve any kind of object are often included in the basic data model operations. Concepts to specify behavior are fundamental to object-oriented data models (see Chapter 11) but are also being incorporated in more traditional data models. For example, object-relational models (see Chapter 11) extend the basic relational model to include such concepts, among others. In the basic relational data model, there is a provision to attach behavior to the relations in the form of persistent stored modules, popularly known as stored procedures (see Chapter 13).
2.1.1 Categories of Data Models
Many data models have been proposed, which we can categorize according to the types of concepts they use to describe the database structure. High-level or conceptual data models provide concepts that are close to the way many users perceive data, whereas low-level or physical data models provide concepts that describe the details of how data is stored on the computer storage media, typically magnetic disks. Concepts provided by low-level data models are generally meant for computer specialists, not for end users. Between these two extremes is a class of representational (or implementation) data models,4 which provide concepts that may be easily understood by end users but that are not too far removed from the way data is organized in computer storage. Representational data models hide many details of data storage on disk but can be implemented on a computer system directly.
Conceptual data models use concepts such as entities, attributes, and relationships. An entity represents a real-world object or concept, such as an employee or a project from the miniworld that is described in the database. An attribute represents some property of interest that further describes an entity, such as the employeersquo;s name or salary. A relationship among two or more entities represents an association among the entities, for example, a works-on relationship between an employee and a project. Chapter 7 presents the Entity-Relationship model—a popular high-level conceptual data model. Chapter 8 describes additional abstractions used for advanced modeling, such as generalization, specialization, and categories (union types).
Representational or implementation data models are the models us
全文共32331字，剩余内容已隐藏，支付完成后下载完整资料
DBMS包的架构已经从早期的整体系统演变而来， DBMS软件包是一个紧密集成的系统，适用于设计模块化，具有客户端/服务器系统架构的现代DBMS软件包。 这种演变反映了计算的趋势，其中大型集中式主机计算机被数百个分布式工作站和通过通信网络连接到各种类型的服务器机器的个人计算机所取代 - Web服务器，数据库服务器，文件服务器，应用程序服务器等。
在ab asic客户端/服务器DBMS架构，系统功能分布在两种类型的模块之间.1客户端模块通常设计成可以在用户工作站或个人计算机上运行。 通常，访问数据库的应用程序和用户界面在客户端模块中运行。 因此，客户端模块处理用户交互，并提供用户友好的界面，如基于窗体或菜单的GUI（图形用户界面）。 称为服务器模块的另一种模块通常处理数据存储，访问，搜索和其他功能。 我们在2.5节中更详细地讨论客户端/服务器体系结构。 首先，我们必须研究更多的基本概念，这将使我们更好地了解现代数据库架构。
在本章中，我们将介绍本书将使用的术语和基本概念。 第2.1节讨论数据模型并定义了模式和实例的概念，这些是对数据库系统研究的基础。 然后，我们在2.2节讨论三模式DBMS架构和数据独立性; 这提供了用户对DBMS应该做什么的看法。 在2.3节中，我们描述了通常由DBMS提供的接口和语言的类型。 第2.4节讨论了数据库系统的软件环境。 第2.5节概述了各种类型的客户端/服务器体系结构。 最后，第2.6节介绍了DBMS包类型的分类。 第2.7节总结了本章。
第2.4至2.6节中的材料提供了更为详细的概念，可以被认为是对基本介绍材料的补充。
2.1数据模型，模式和实例
数据库方法的一个基本特征是它提供了一定程度的数据抽象。 数据抽象通常是指对数据组织和存储的细节的抑制，以及对数据的更好理解的重要特征。 数据库方法的主要特征之一是支持数据抽象，以便不同的用户能够以其首选的细节级别感知数据。 数据模型 - 可用于描述数据库结构的概念的集合 - 提供了实现此抽象的必要手段.2通过数据库的结构，我们意味着适用于数据的数据类型，关系和约束。 大多数数据模型还包括一组用于指定数据库上的检索和更新的基本操作。
除了数据模型提供的基本操作之外，在数据模型中包含概念以指定数据库应用程序的动态方面或行为变得越来越普遍。 这允许数据库设计者指定在数据库对象上允许的一组有效的用户定义的操作.3用户定义操作的示例可以是COMPUTE_GPA，可以应用于STUDENT对象。 另一方面，通常在基本数据模型操作中包含插入，删除，修改或检索任何类型的对象的通用操作。 指定行为的概念是面向对象数据模型的基础（参见第11章），但也被纳入到更传统的数据模型中。 例如，对象关系模型（见第11章）将基本关系模型扩展到包括这些概念等。 在基本关系数据模型中，有一个规定是以持久存储的模块（通常被称为存储过程）的形式将行为附加到关系中（见第13章）。
2.1.1数据模型类别
已经提出了许多数据模型，我们可以根据它们用于描述数据库结构的概念的类型进行分类。 高级或概念数据模型提供了接近于许多用户感知数据的方式的概念，而低级或物理数据模型提供了描述数据如何存储在计算机存储介质（通常为磁盘）上的细节的概念。 低级数据模型提供的概念通常用于计算机专家，而不是终端用户。 在这两个极端之间是一类代表性（或实现）的数据模型，4提供了最终用户可以很容易理解的概念，但是从计算机存储中数据的组织方式来看，这些概念并不是太远。 表示数据模型隐藏了磁盘上的数据存储的许多细节，但可以直接在计算机系统上实现。
概念数据模型使用诸如实体，属性和关系之类的概念。 一个实体表示一个真实世界的对象或概念，例如数据库中描述的来自miniworld的员工或项目。 属性表示进一步描述实体的一些感兴趣的属性，例如雇员的姓名或工资。 两个或多个实体之间的关系表示实体之间的关联，例如，员工和项目之间的工作关系。 第7章介绍了实体关系模型 - 一种流行的高级概念数据模型。 第8章介绍了用于高级建模的其他抽象，如泛化，专业化和类别（联合类型）。
代表性或实施数据模型是传统商业DBMS中最常用的模型。 这些包括广泛使用的关系数据模型，以及过去被广泛使用的所谓遗留数据模型 - 网络和层次模型。 第2部分致力于关系数据模型及其约束，操作和语言.5第4章和第5章描述了关系数据库的SQL标准。表示数据模型通过使用记录结构来表示数据，因此有时被称为基于记录的数据模型。
我们可以将对象数据模型作为更接近概念数据模型的更高层次的实现数据模型的新系列的例子。 被称为ODMG对象模型的对象数据库的标准已由对象数据管理组（ODMG）提出。 我们描述了第11章中对象数据库的一般特征和对象模型提出的标准。对象数据模型也经常被用作高级概念模型，特别是在软件工程领域。
物理数据模型描述如何通过表示诸如记录格式，记录顺序和访问路径之类的信息将数据作为文件存储在计算机中。 访问路径是使特定数据库记录的搜索有效的结构。 我们在第17章和第18章讨论物理存储技术和访问结构。索引是允许使用索引项或关键字直接访问数据的访问路径的示例。 它与本书末尾的索引类似，不同的是它可以以线性，分层（树结构）或其他方式组织。
2.1.2模式，实例和数据库状态
在任何数据模型中，区分数据库和数据库本身的描述很重要。 数据库的描述称为数据库模式，它在数据库设计期间指定，并且预计不会频繁更改.6大多数数据模型具有将模式显示为图表的一些约定.7显示的模式称为架构图。 图2.1显示了图1.2所示数据库的架构图; 该图显示每个记录类型的结构，但不显示实际的记录实例。 我们调用模式中的每个对象，如STUDENT或COURSE - 一个模式构造。
模式图仅显示模式的某些方面，例如记录类型和数据项的名称以及某些类型的约束。 架构图中未指定其他方面; 例如，图2.1既不显示每个数据项的数据类型，也不显示各种文件之间的关系。 许多类型的约束不在模式图中表示。 计算机科学专业的学生必须在大二学年结束之前采取CS1310，难以用图解表示。
数据库中的实际数据可能会频繁更改。 例如，图1.2所示的数据库每次添加新学生或输入新的成绩时都会发生变化。 数据库中特定时刻的数据称为数据库状态或快照。 它也被称为数据库中的当前事件集或实例。 在给定的数据库状态中，每个模式构造都有自己的当前实例集; 例如，STUDENT构造将包含一组单独的学生实体（记录）作为其实例。 可以构造许多数据库状态以对应于特定的数据库模式。 每次插入或删除记录或更改记录中数据项的值时，我们将数据库的一个状态更改为另一个状态。
数据库模式和数据库状态之间的区别非常重要。 当我们定义一个新的数据库时，我们只将数据库模式指定给DBMS。 此时，相应的数据库状态为空状态，无数据。 当数据库首次填充或加载初始数据时，我们得到数据库的初始状态。 从那时起，每当对数据库应用更新操作时，我们得到另一个数据库状态。 在任何时间点，数据库都具有当前状态.8 DBMS部分负责确保数据库的每个状态都是有效状态，即满足模式中指定的结构和约束的状态。 因此，向DBMS指定正确的模式是非常重要的，并且模式必须非常小心设计。 DBMS将DBMS目录中的模式结构和约束（也称为元数据）的描述存储在DBMS目录中，以便DBMS软件可以在需要时引用模式。 模式有时称为intension，数据库状态称为模式的扩展。
尽管如前所述，架构不应该频繁更改，但随着应用程序需求的变化，这种变化偶尔也需要应用于模式。 例如，我们可能会决定为文件中的每个记录需要存储另一个数据项，例如将Date_of_birth添加到图2.1中的STUDENT模式。 这被称为模式演进。 大多数现代DBMS包括一些模式演进的操作，可在数据库运行时应用。
2.2三模式体系结构与数据独立性
第1.3节列出的数据库方法的四个重要特征之一是（1）使用目录来存储数据库描述（模式），以使其自我描述，（2）程序和数据的绝缘（程序数据和程序操作独立性），（3）支持多个用户视图。 在本节中，我们为数据库系统指定了一种称为三架构架构的架构，9是为了帮助实现和可视化这些特性而提出的。 然后进一步讨论数据独立的概念。
2.2.1三层架构
图2.2所示的三模式架构的目标是将用户应用程序与物理数据库分开。 在这种架构中，可以在以下三个层面定义模式：
内部级别有一个内部模式，它描述了数据库的物理存储结构。 内部模式使用物理数据模型，并描述数据库的数据存储和访问路径的完整详细信息。
概念层面有一个概念模式，它描述了一个用户群体的整个数据库的结构。 概念模式隐藏物理存储结构的细节，并集中于描述实体，数据类型，关系，用户操作和约束。 通常，当实现数据库系统时，使用表示数据模型来描述概念模式。 该实现概念模式通常基于高级数据模型中的概念模式设计。
3.外部或视图级别包括多个外部模式或用户视图。 每个外部模式描述特定用户组感兴趣的数据库部分，并隐藏该用户组的其余数据库。 与上一级相似，每个外部模式通常使用表示数据模型实现，可能基于高级数据模型中的外部模式设计。 三模架构是一个方便的工具，用户可以在数据库系统中可视化模式级别。 大多数DBMS不会完全和明确地分离三个层次，而是在一定程度上支持三层架构。 一些较旧的DBMS可能包括概念模式中的物理级细节。 三级ANSI架构在数据库技术开发中占有重要地位，因为它清楚地分离了用户的外部级别，数据库的概念级别和设计数据库的内部存储级别。 它甚至在今天的DBMS设计中非常适用。 在支持用户视图的大多数DBMS中，在描述概念级信息的相同数据模型中指定了外部模式（例如，Oracle使用SQL的关系DBMS）。 一些DBMS允许在概念和外部层面使用不同的数据模型。 一个例子是通用数据库（UDB），一个来自IBM的DBMS，它使用关系模型来描述概念模式，但可以使用面向对象的模型来描述外部模式。
请注意，三个模式只是数据的描述; 实际存在的存储数据仅在物理级别。 在基于三架构架构的DBMS中，每个用户组都引用其自己的外部架构。 因此，DBMS必须将外部模式上指定的请求转换为针对概念模式的请求，然后将内部模式的请求转换为对存储的数据库进行处理。 如果请求是数据库检索，则从存储的数据库提取的数据必须重新格式化以匹配用户的外部视图。 在层次之间转换请求和结果的过程称为映射。 这些映射可能很耗时，因此一些DBMS（特别是那些旨在支持小数据库的DBMS）不支持外部视图。 然而，即使在这样的系统中，需要一定量的映射来在概念层面和内部层次之间转换请求。
2.2.2数据独立性
三模式架构可用于进一步解释数据独立性的概念，可以将其定义为在数据库系统的一个级别更改模式的能力，而无需在下一个更高级别更改模式。 我们可以定义两种类型的数据独立性：
逻辑数据独立性是改变概念模式而不必更改外部模式或应用程序的能力。 我们可以更改概念模式以扩展数据库（通过添加记录类型或数据项），更改约束或减少数据库（通过删除记录类型或数据项）。 在最后一种情况下，仅引用剩余数据的外部模式不应受到影响。 例如，图1.5（a）的外部架构不应受图1.2（a）所示的GRADE_REPORT文件（或记录类型）的影响。 需要在支持逻辑数据独立性的DBMS中更改视图定义和映射。 在概念模式经历了逻辑重组之后，引用外部模式构造的应用程序必须像以前那样工作。 对约束的更改可以应用于概念模式，而不会影响外部模式或应用程序。
2.物理数据独立性是改变内部模式而不必更改概念模式的能力。 因此，外部模式也不需要改变。 可能需要对内部模式进行更改，因为某些物理文件被重组 - 例如，通过创建其他访问结构来改进检索或更新的性能。 如果与数据库中相同的数据保留在数据库中，则不必更改概念模式。 例如，提供一个访问路径来提高每个学期和年份的段记录（图1.2）的检索速度，不应该要求查询，例如列出2008年秋季提供的所有部分的列表，尽管查询将被更高效地执行DBMS通过利用新的访问路径。
通常，在大多数数据库和文件环境中存在物理数据独立性，其中物理细节（如磁盘上的数据的确切位置）以及存储编码，布局，压缩，拆分，记录合并等硬件细节隐藏起来用户。 应用程序仍然不了解这些细节。 另一方面，逻辑数据独立性更难实现，因为它允许结构和约束更改而不影响应用程序 - 更严格的要求。
每当我们有一个多级DBMS，它的目录必须被扩展，包括如何映射请求和数据在各个级别之间的信息。 DBMS使用附加软件通过参考目录中的映射信息来完成这些映射。 发生数据独立性是因为当某个级别更改模式时，下一个较高级别的模式保持不变; 只有两级之间的映射发生变化。 因此，不需要更改引用到较高级别架构的应用程序。
三模式架构可以使物理和逻辑上的数据独立性变得更加容易。 但是，两个级别的映射在编译或执行查询或程序期间会产生开销，导致DBMS效率低下。 正因为如此，很少的DBMS已经实现了全三维架构。
2.3数据库语言和接口
在第1.4节中，我们讨论了DBMS支持的用户种类。 DBMS必须为每类用户提供适当的语言和界面。 在本节中，我们将讨论由DBMS提供的语言和接口的类型以及每个接口所针对的用户类别。
2.3.1 DBMS语言
一旦完成了数据库的设计，并选择了DBMS来实现数据库，那么第一步是为数据库和两者之间的任何映射指定概念和内部模式。 在许多DBMS中，没有保持严格的级别分离，一种称为数据定义语言（DDL）的语言被DBA和数据库设计人员用于定义两种模式。 DBMS将具有DDL编译器，其功能是处理DDL语句，以便识别模式结构的描述，并将模式描述存储在DBMS目录中。
在DBMS中，在概念层面和内部层次之间保持明确的分离，DDL仅用于指定概念模式。 另一种语言是存储定义语言（SDL），用于指定内部模式。 两种模式之间的映射可以以这两种语言之一来
全文共9308字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[144929]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
