数据库理论新探：第三宣言

需积分: 10 145 浏览量更新于2024-07-16 收藏 3.42MB PDF 举报

"数据库，类型和关系模型-第三宣言(Databases, Types and the Relational Model - The Third Manifesto)，由C.J. Date和Hugh Darwen合著，是数据库专业人员深入理解关系模型与类型理论相互影响的重要著作。本书对类型继承提供了一个全面的模型，并作为DBMS设计和这类DBMS语言界面的抽象蓝图。" 《第三宣言》是计算机科学领域的经典文献，主要探讨了类型理论如何影响关系模型，并在此基础上提出了新的见解和理论。在数据库领域，关系模型是最广泛使用的数据模型之一，它以表格的形式存储数据，强调数据之间的数学关系。类型理论则是计算机科学中的基础概念，用于定义和区分数据的种类，确保数据的准确性和一致性。作者C.J. Date和Hugh Darwen在书中详细阐述了类型理论如何增强关系模型的表达力，特别是在处理复杂的数据结构如类型继承时。类型继承允许数据类型从一个基本类型派生出更具体或更专业的类型，这在数据库中对于描述层级关系或分类数据非常有用。他们提出的模型旨在解决传统关系数据库系统在处理复杂数据类型时的局限性，使系统能更好地支持对象-关系数据库的概念。书中的一个重要观点是"所有逻辑上的差异都是重要的"，引用了哲学家路德维希·维特根斯坦的观点。这意味着在设计数据库时，逻辑结构的选择会直接影响到系统的功能和性能。然而，作者也引用了T.S.艾略特的诗来提醒读者，虽然逻辑差异很重要，但并非决定一切，逻辑之外的因素也需要考虑，这在数据库设计中意味着需兼顾实际应用和用户需求。此外，本书是对之前两部作品的修订版，包括《未来数据库系统的基础：第三宣言》和《对象/关系数据库系统的基础：第三宣言》。这些修订旨在不断优化和更新理论，以适应数据库技术的快速发展。《第三宣言》是数据库专业人士、软件工程师、数据架构师以及对数据库设计和理论感兴趣的人士的宝贵参考资料。通过深入理解书中阐述的关系模型和类型理论的结合，读者能够更好地设计和实现高效、灵活且可靠的数据库系统。

Part I / Preliminaries Chapter 1 / Background and Overview

were capable of at the time; in other words, we needed to find a way of extending, dramatically, the

range of possible kinds of data we could keep in our databases. For example, we might imagine a

biological database that included a BIRD relation like the one shown in Fig. 1.1. Note: We follow

convention in Fig. 1.1 and similar figures throughout this book in using double underlining to mark

components of primary keys—despite the fact that (as we will see in the next chapter) the Manifesto

does not require primary key support.

╔═════════════════════════════════════════════════════════════════╗

║ ┌────────┬───────┬─────┬───────┬──────┬──────┐ ║

║ BIRD │ NAME │ DESCR │ PIC │ VIDEO │ SONG │ MIGR │ ║

║ ├════════┼───────┼─────┼───────┼──────┼──────┤ ║

║ │ Robin │ xxxxx │ ... │ ..... │ ♪♫♪♫ │ .... │ ║

║ │ Osprey │ xxxxx │ ... │ ..... │ ♪♪♪♪ │ .... │ ║

║ │ ...... │ ..... │ ... │ ..... │ .... │ .... │ ║

║ ║

║ where NAME is a bird name (text) ║

║ and DESCR is a description of that bird (XML doc) ║

║ and PIC is a picture of the bird (photo) ║

║ and VIDEO is a movie of the bird (video) ║

║ and SONG is the bird's song (audio) ║

║ and MIGR is the bird's migration route (map) ║

║ ║

╚═════════════════════════════════════════════════════════════════╝

Fig. 1.1: The BIRD relation

Before going any further, we should make it clear that, strictly speaking, the table in Fig. 1.1 is

not really a relation at all, even though we said it was just now. Rather, it is a picture of a relation, as

displayed on a computer screen perhaps, that contains among other things certain icons. Clicking on,

say, the SONG (“♪♫♪♫”) icon in the Robin row in that picture might cause the system to play a

recording of a robin singing; and, loosely speaking, it is that recording, not the icon, that is the actual

value of the SONG component of the Robin row within the BIRD relation.

To get back to the main thread of our discussion: Of course, we would need to be able to operate

on such new kinds of data, too. In the case of the BIRD relation, for example, we might want to find

information concerning birds whose migration route includes Italy:

SELECT NAME, DESCR, SONG, VIDEO

FROM BIRD

WHERE INCLUDES ( MIGR, COUNTRY('Italy') )

Note: We use SQL as the basis for this example for reasons of familiarity, despite the fact that (as

indicated in the previous subsection) the Manifesto expressly proscribes it.

So the problem we were addressing was this: How could we support new kinds of data within the

classical relational framework? (Of course, we did take it as axiomatic that we wanted to stay in that

framework; it would be unthinkable to walk away from what is, at the time of writing, well over 35

years of relational research and development.) And the key to the solution was, of course, type theory:

It all boiled down to the issue of what types of data we were allowed to keep within database relations.

Hence our focus on type theory in this book.

Part I / Preliminaries Chapter 1 / Background and Overview

Topics Deliberately Omitted

As you know by now, this book is not about SQL (at least, not directly). Nor is it about commercial

products. Rather, it is about principles (in this context, just another word for foundations). Why?

Because principles endure;

principles are solid; principles are what you need to know in order to be

able to understand—and analyze, and evaluate, and perhaps judge—vendor claims, commercial

products, the SQL language, and numerous other developments and pronouncements in the database

field.

Of course, a real DBMS will necessarily include many features over and above those that can

properly be regarded as foundation features as such. Such features include:

■ Recovery and concurrency controls

■ Security and authorization controls

■ Stored and triggered procedures (the latter more usually known, somewhat inappropriately, as just

triggers)

■ Support for the development of generic applications (e.g., some kind of call-level interface)

■ Performance tuning and other administration controls

and many other things besides. Now, we recognize that such features can be extremely important in

practice—in fact, the quality of support for them can make or break a DBMS as a commercial

proposition. As already stated, however, they are not part of the foundation per se; they are therefore

not addressed in the Manifesto, and they are not discussed in the present book (at least, not much).

We also have little to say regarding matters of implementation. As explained in more detail in the

section “Some Crucial Logical Differences” later in this chapter, we draw a sharp distinction between

model issues and implementation ones, and we believe it is important to get the model right first before

worrying about how to implement it—though we should immediately add that we have at least thought

about implementation matters enough to have reason to believe that everything we propose is indeed

implementable.

In particular, much existing SQL implementation technology should be useful and

usable in implementing the ideas of the Manifesto, even though we reject SQL as such. (In fact, we

venture to suggest that implementing the Manifesto should actually be easier than implementing SQL,

for reasons we hope will become clear as we proceed.)

By contrast, products change all the time, and so does SQL.

In this respect, we might again claim to be following Codd, who wrote, possibly tongue in cheek, in his famous 1970

paper [21]: “Implementation problems are [not] discussed. Nevertheless, the material presented should be adequate for

experienced systems programmers to visualize several approaches.”

Part I / Preliminaries Chapter 1 / Background and Overview

What about Objects?

Something else we need to explain at the outset has to do with our adoption—or lack thereof, rather, for

the most part—of terminology from the object world.

In the early to mid 1990s, there were those who

argued that object technology was destined to replace relational technology. Few now subscribe to that

position, but it might still be claimed that object technology at least does have some contributions to

make to the database field. We do not dispute that claim; however, we prefer not to use object

terminology, even when we make use of object concepts (or, at least, concepts that might have some

counterpart in the object world), because we do not find that terminology appropriate to our purpose.

For consider:

■ First of all, the very term object itself does not seem to have a precise or universally agreed

meaning. Sometimes it seems to mean a value; sometimes a variable; sometimes even a type;

and there might be other interpretations as well. (Sometimes an object is defined to be an

instance, but that definition merely shifts the question of interpretation on to this latter term. In

this book, therefore, we avoid the use of the term instance also, except in very informal contexts.)

■ As a label, moreover, that same term object is applied to a wide variety of quite distinct

endeavors. It is used among other things to describe a certain graphic interface style, a certain

programming style, certain programming languages (not the same thing as programming style, of

course), and certain analysis and design techniques—all of these in addition to a certain approach

to what is after all the principal focus of this book, database management. And it is quite clear

that the term does not mean the same thing in all of these different contexts (see, e.g., the

annotation to reference [9] in Appendix K).

Similar comments apply to other object terms as well (class, method, and so on). Given this state

of affairs, therefore, and given also that we are trying to be precise in this book (for the most part, at

any rate), we prefer to avoid terminology that might be subject to misinterpretation.

There is another point we need to make clear in this connection, though. In this book, we are (of

course) interested in the field of database management. We are therefore interested in—among many

other things—the applicability of object concepts and technology to that field. Please note, therefore,

that all remarks made in this book concerning object concepts and technology must be understood in

this light. We offer no opinion whatsoever regarding the usefulness of object ideas in any other

context.

A Little History

Being organized as it is around The Third Manifesto, this book can be seen as a reincarnation of, and

replacement for, two previous books (though it has been drastically revised, and in fact totally

rewritten). The first of those previous books was published in 1998, under the title Foundation for

Object/Relational Databases: The Third Manifesto [82]. We chose that title because “object/relational”

DBMSs were a hot topic at the time; we were concerned in particular that certain portions of the

industry were going about implementing such DBMSs in a way that seemed to us seriously flawed, and

Throughout this book we favor the abbreviated form object over the longer term object-oriented.

Part I / Preliminaries Chapter 1 / Background and Overview

we wanted to do our best to help correct matters. In retrospect, however, we now realize the title was a

little unfortunate in at least two respects:

■ It got the emphasis wrong, in that it suggested that the book was concerned with

“object/relational” databases exclusively, whereas (as already indicated) the ideas of the

Manifesto are much wider-ranging.

■ In any case, we regard “object/relational” primarily as a marketing term. Indeed, it is our

contention that a true relational system—that is, a system that supported the relational model

properly, with all that such support entails—would in fact be an “object/relational” system (which

is why we usually set the term in quotation marks).

We went on to publish a revised version of that first book in 2000 under the somewhat better title

Foundation for Future Database Systems: The Third Manifesto [83]. But that title too was not perfect.

The problem with the future is, it never arrives!—and we would like to see the industry in general act

on the ideas of the Manifesto as soon as possible (we take this subject seriously). Certainly there is

room for improvement in the current crop of commercial products.

And so to the present book. This time we have chosen what we hope is a more appropriate title;

in particular, we have tried to get away from the shortcomings of the two earlier titles. And we have, as

already indicated, taken the opportunity to overhaul the text from beginning to end. Thus, although the

overall message remains unchanged, what you hold in your hands is to all intents and purposes a brand

new book.

BACK TO THE RELATIONAL FUTURE

It is a major thesis of both the Manifesto and this book that we need to move away from SQL and get

back to our relational roots. In other words, we do not believe that SQL is capable of providing the

kind of solid foundation we seek. Rather, we believe any such foundation must be firmly rooted in the

relational model of data, first presented to the world in 1969 by E. F. Codd in reference [20].

Now, we have already said we acknowledge the desirability of supporting certain features that are

commonly regarded as aspects of object orientation. However, we believe the features in question are

orthogonal to (i.e., independent of) the relational model as such. In other words, we claim that the

relational model needs no extension, no correction, no subsumption—and, above all, no perversion—in

order for it to be possible to define some database language that (a) is truly relational, (b) does

accommodate those desirable orthogonal features, and (c) can represent the firm foundation we seek.

Let there be such a language, and let its name be D. Please note immediately that no special

significance attaches to this choice of name—we use it merely to refer generically to any language that

conforms to the principles laid down in the Manifesto. There could be any number of distinct

languages all qualifying as a valid D. We define one such language in this book; we call it Tutorial D,

and we use it as the basis for most of our examples.

The Manifesto defines a variety of prescriptions and proscriptions that apply to any such D.

Some of those prescriptions arise from the relational model, and these we call Relational Model

Prescriptions (RM Prescriptions). Prescriptions that do not arise from the relational model we call

Other Orthogonal Prescriptions (OO Prescriptions). We similarly classify the Manifesto’s

Part I / Preliminaries Chapter 1 / Background and Overview

proscriptions into RM and OO categories. The various prescriptions and proscriptions are itemized and

discussed in detail in Parts II and III of this book.

In addition to the prescriptions and proscriptions just mentioned, the Manifesto includes a series

of Very Strong Suggestions, likewise divided into RM and OO categories; again, see Parts II and III.

Also, Part IV contains the definition of a model of type inheritance, and that model is likewise

formulated as a series of prescriptions—Inheritance Model Prescriptions (IM Prescriptions). Please

note, however, that almost everything to do with that inheritance model is ignored prior to Part IV,

except for the occasional remark here and there. The material of Part IV extends, but does not

invalidate, the material presented in earlier parts of the book.

For definiteness, we assume throughout the Manifesto and throughout this book that the language

D is imperative in style. Like all such languages, therefore, it is based on the four core concepts type,

value, variable, and operator.

For example, we might have a type called INTEGER; the integer 3

might be a value of that type; N might be a variable of that type, whose value at any given time is some

integer value (i.e., some value of that type); and plus might be an operator that applies to integer values

(i.e., to values of that type). See the section “Some Crucial Logical Differences” later in this chapter

for further elaboration of these concepts.

As an aside, we remark that if it is true that the Manifesto can be regarded as defining a

foundation for database technology, then the concepts of type, value, variable, and operator can be

regarded as providing a foundation for that foundation. And since the value, variable, and operator

concepts in turn all rely on the type concept, we might go further and say the type concept can be

regarded as a foundation for the foundation for the foundation ... In other words, the type concept is the

most fundamental of all, as we will soon see.

Back to the language D. We have said that D is imperative in style (or so we will assume). Now,

some writers equate the term imperative with the term procedural, but we do not (even though they

both refer to a style of programming in which the programmer explicitly directs the computer to carry

out certain processes). Actually, neither term is very precisely defined; however, procedural usually

connotes a rather low level of abstraction, while imperative does not (at least, not necessarily). In other

words, procedural languages are imperative, but imperative languages are not necessarily procedural.

In particular, the language D—or its relational portion, at any rate—is at a comparatively high level of

abstraction and is thus imperative but not procedural.

One last point to close this section: Do not infer from our assumption of an imperative style that

we discount the possibility of (e.g.) a functional style; at the time of writing, however, we have not

investigated such a possibility in any depth. But we should point out that certain of the prescriptions,

proscriptions, and suggestions spelled out in this book would have to be reformulated in the context of a

functional D. For example, a functional D would obviously have no need of variables at all, in the

usual programming sense of that term, and hence would not need any update operators either.

Note that we distinguish between operators and operations—an operation is the process carried out when an operator is

invoked. That said, however, we should say too that the terms can often be used interchangeably. For example, no real

harm is done if we replace “operator” by “operation” in the sentence “Plus is an operator that takes two integers as input and

returns another integer as output.”

剩余603页未读，继续阅读

weixin_38743968

粉丝: 404
资源: 2万+

数据库理论新探：第三宣言

Object-Relational Databases

数据库管理系统：ch02 Relational Model.ppt

Incremental-Information-Extraction-Using-Relational-Databases

knex-relational-databases-and-related-tools

The Theory of Relational Databases 关系数据库理论

Backup-and-Restore-SQLServer-Databases:从SQLServer实例备份和还原所有数据库的最简单方法

MySQL数据库应用与管理-第章-数据库的创建和管理-创建数据库.pptx

藏经阁-Horizontally Scalable Relational Databases with Spark.pdf

High-Performance-Parallel-Database-Processing-And-Grid-Databases

High-Performance-Parallel-Database-Processing-And-Grid-Databases.pdf

最新资源