2.13. Резюме

В этой главе рассматривались системы баз данных с точки зрения общей архитектуры. Во-первых, описана архитектура ANSI/SPARC, которая делит систему баз данных на три уровня следующим образом: внутренний уровень, наиболее близкий к физическо­му хранению (т.е. рассматривающий способ, с помощью которого данные сохраняютсяфизически); внешний уровень, наиболее близкий к пользователям (т.е. имеющий отношение к способу представления данных для отдельных пользователей); концептуальный уровень, который является промежуточным между двумя предыдущими (а предоставляет обобщенное представление данных). Восприятие данных на каждом и уровней описывается с помощью схемы (или нескольких схем в случае внешнего уров- ня). Отображения описывают соответствие между данной внешней схемой и концепту­альной схемой, а также концептуальной и внутренней схемами.

Пользователи, т.е. конечные пользователи и прикладные программисты, которые работают на внешнем уровне, взаимодействуют с данными с помощью подъязыка данных, который разбивается по крайней мере на два компонента: язык определе­ния данных и язык обработки данных. Подъязык данных встроен в базовый язык.

Замечание. Разделяющие границы между базовым языком и подъязыком данных, а также между языком определения данных и языком обработки данных в основном умозрительны по природе; в идеале они должны быть "прозрачны для пользователя".

Мы также детально рассмотрели функции администратора базы данных и СУБД. Кроме всего прочего, АБД несет ответственность за создание внутренней схемы (физическое проектирование базы данных); за создание же концептуальной схемы (логическое или концептуальное проектирование базы данных) несет ответствен­ность администратор данных. А в функции СУБД среди прочих входит реализация запросов пользователей, написанных на языке определения данных и языке обработ­ки данных. Функцией СУБД также является предоставление словаря данных.

Системы баз данных удобно рассматривать как простую структуру, состоящую из сервера (собственно СУБД) и набора клиентов (приложений). Клиент и сервер мо­гут выполняться и зачастую выполняются на отдельных машинах, обеспечивая таким образом одну простую распределенную обработку. Каждый сервер может обслужи­вать много клиентов, а каждый клиент может работать так, как будто он имеет дело с одним сервером на одной машине, невзирая на реальное физическое положение дел, — в таком случае мы имеем настоящую распределенную систему баз данных.

Упражнения

2.1. Начертите схему архитектуры системы баз данных, представленной в этой главе (архитектура ANSI/SPARC).

2.2. Дайте определения следующим терминам: машина базы данных; внешний ин­терфейс; клиент; базовый язык; концептуальный язык определения; загрузка дан­ных; схема; представление; отображение концептуальный-внутренний; логиче­ский проект базы данных; язык определения данных; словарь данных; физиче­ский проект базы данных; язык обработки данных; планируемый запрос; подъязык данных; система базы данных и передачи данных; сервер; диспетчер передачи данных; распределенная база данных; выгрузка-перезагрузка; распре­деленная обработка; непланируемый запрос; пользовательский интерфейс; ото­бражение внешний-концептуальный; утилита.

2.3. Объясните последовательность шагов, применяемых при выборке опреде­ленного экземпляра внешней записи.

2.4. Перечислите главные функции, выполняемые СУБД.

2.5. Перечислите главные функции, выполняемые АБД.

2.6. Укажите различия между СУБД и системой управления файлами.

2.7. Приведите несколько примеров приложений, предоставляемых поставщика­ми, или инструментальных средств.

2.8. Приведите несколько примеров утилит базы данных.

2.9. Рассмотрите любую доступную вам систему баз данных. Попытайтесь начер­тить эту систему в виде архитектуры ANSI/SPARC, как описано в этой главе. Полностью ли она поддерживает три уровня архитектуры? Как определены отображения между уровнями? На что похоже множество языков определения данных (внешний, концептуальный и внутренний)? Какой подъязык данных поддерживает система? Какой базовый язык? Кто выполняет функции АБД? Имеются ли какие-нибудь возможности защиты и целостности данных? Есть ли словарь? Какие приложения, предоставляемые поставщиками, поддерживает система? Какие утилиты? Есть ли отдельный диспетчер передачи данных? Имеются ли какие-либо возможности распределенной обработки?

Список литературы

Хотя некоторые из перечисленных ниже изданий были выпущены давно, в них можно найти полезную информацию, касающуюся понятий, представленных в этой главе.

2.1. ANSI/X3/SPARC Study Group on Data Base Management Systems. Interim Report // FDT (ACM SIGMOD bulletin). — 1975. — 7, № 2.

2.2. Tsichritzis D.C. and Klug A. (eds). The ANSI/X3/SPARC Framework: Report of the Study Group on Data Base Management Systems // Information Systems. — 1978.—3.

Эти два документа [2.1, 2.2]— соответственно предварительный и оконча­тельный отчеты группы ANSI/X3/SPARC Study Group. Группа ANSI/X3/SPARC (полное название Study Group on Data Base Management Systems) была организована в 1972 году комитетом Standards Planning and Requirements Committee (SPARC) института American National Standards Institute on Computers and Information Processing (ANSI/X3). В задачи группы входило определение того, нуждаются ли какие-то области (если да, то какие) технологии баз данных в стандартизации, и выработка набора рекомендаций по действиям в каждой из этих областей. В работе над этими задачами группа пришла к выводу, что единственный подходящий способ стандартизации — это интерфейсы, и в соответствии с этим определила общую архитектуру, или фундамент, системы баз данных и указала на важную роль таких интер­фейсов. В окончательном отчете представлено подробное описание архитек­туры и некоторых из 42 указанных интерфейсов. Предварительный отчет — это более ранний документ, который представляет определенный интерес, так как в нем некоторые вопросы рассмотрены более детально.

2.3. Van Griethuysen J.J. (ed.). Concepts and Terminology for the Conceptual Schema and the Information Base // Intern. Organization for Standardization Document. — 1982.— № ISO/TC97/SC5-N695.

ISO/TC97/SC5 — это название рабочей группы Международной организации по стандартизации (International Standard Organization — ISO). В обязанности этой группы входит "определение понятий для языков концептуальных схем". В отчете рабочей группы предложено три альтернативных подхода (точнее, три группы подходов) к формализации концептуальной схемы. Каж­дый из трех подходов был применен к стандартному примеру, связанному с деятельностью гипотетического управления регистрацией машин. Три груп­пы — это подходы "объект-атрибут-отношение", подходы "бинарных отно­шений" и подходы "интерпретируемой предикатной логики". В отчете обсу­ждаются фундаментальные понятия, лежащие в основе понятия концептуаль­ной схемы, а также излагаются некоторые принципы реализации системы, которая должным образом поддерживает концептуальную схему. Местами достаточно сложный, однако очень важный документ для всех, кто серьезно интересуется концептуальным уровнем системы.

2.4. Data Dictionary Systems Working Party of the British Computer Society. Report // Data Base (ACM SIGBDP newsletter). — 9, № 2; SIGMOD Record (ACM SIGMOD bulletin). — 1977. — 9, № 4.

Прекрасное описание роли словаря данных; содержит небольшое, но хоро­шее описание концептуальной схемы.

2.5. Uhrowczik P.P. Data Dictionary/Directories // IBM Sys. — 1973. — 12, № 4.

Хорошее введение в основные понятия системы словаря данных. Кратко опи­санная реализация основана на системе IMS (изначально выпущенная система словаря данных фирмы IBM полностью согласуется с этим описанием).

2.6. Winsberg P. Dictionary Standards: ANSI, ISO, and IBM; and Industry Views of the Dictionary Standards Muddle // InfoDB. — 1988/89. — 3, № 4.

Прекрасное введение и анализ мировых стандартов словарей; в частности, рассмотрен стандарт ANSI Information Resource Dictionary Systems (IRDS).

2.7. Kent W. Data and Reality. — Amsterdam, Netherlands: North-Holland; New York, N.Y.: Elsevier Science, 1978.

Искусственное и немного раздражающее описание природы информации, в частности концептуальной схемы. Книгу можно рассматривать как краткое руководство по решению реальных проблем, с которыми трудно справиться из-за существующего формализма в базах данных, в частности формализма в структурах, подобных записям при реляционном подходе. Рекомендуется.