2.13. Резюме

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

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

Замечание. Границы, разделяющие базовый язык и подъязык данных, а также язык определения данных и язык обработки данных по своей природе, в основном, умозри- тельны. В идеале, они должны быть прозрачны для пользователя.

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

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

Упражнения

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

2. Дайте определения следующим терминам.

базовый язык отображение "концептуальный-

внутренний"

внешний интерфейс

внешний язык определения, схема,

представление

внутренний язык определения, схема, представление выгрузка-перезагрузка загрузка данных

клиент

концептуальный язык определения, схема, представление логический проект базы данных

машина базы данных

менеджер передачи данных непланируемый запрос определение структуры памяти отображение "внешний- планируемый запрос

подъязык данных

пользовательский интерфейс

распределенная база данных распределенная обработка реорганизация сервер

система базы данных и передачи дан- ных

словарь данных утилита

физический проект базы данных язык манипулирования данными язык определения данных

концептуальный"

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

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

5. Укажите различия между логической и физической независимостью от данных.

6. Как вы понимаете термин метаданные"!

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

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

9. Приведите несколько примеров инструментальных средств, предоставляемых раз- личными поставщиками.

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

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

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

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

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

2. Dionysios C. 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 // International Organization for Standardization (ISO) Technical Report ISO/TR 9007. — July, 1987.

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

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

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

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

2.5. Odysseas G. Tsatalos, Marvin Н. Solomon, and Yannis E. Ioannidis. The GMAP: A Versatile Tool for Phisical Data Independence. Proc. 20th Int. Conf. On Very Large Data Bases. — Santiago, Chile. — September, 1994.

Сокращение GMAP означает обобщенный многоуровневый путь доступа (Generalized Multi-Level Access Path). Авторы статьи справедливо отмечают, что современные продукты баз данных "вынуждают пользователей составлять запросы в терминах логической схемы, которая непосредственно связана с физическими структурами" и поэтому усиливают зависимость от физических данных. В этой статье предлагается язык отображения "концептуальный-внутренний" (по терми- нологии данной главы), который можно использовать для значительно большего количества видов отображений, чем обычно обеспечивается в современных про- дуктах. Предоставляются конкретная "логическая схема" и язык, основанный на реляционной алгебре (см. главу 6), и, следовательно, описательный, а не проце- дурный по своей природе, что позволяет описать множество физических схем, ко- торые формально образуются из такой логической схемы. Кроме всего прочего, подобные физические схемы могут включать вертикальное и горизонтальное раз- деления (глава 20), произвольное количество путей физического доступа, группи- рование и контроль избыточности.

В статье также приводится алгоритм преобразования пользовательских операций над логической схемой в эквивалентные операции над физической схемой. Прото- тип реализации показывает, что АБД может настроить физическую схему, чтобы "достичь значительно более высокой производительности по сравнению с той, ко- торой можно достичь обычными методами".

Глава

Введение в реляционные базы данных