Во-первых, концептуальный уровень в такой системе определенно будет реляционным в том смысле, что видимые на этом уровне объекты являются реляционными таблицами, а используемые операторы будут реляционными операторами (в частности, включая операторы выборки строк и столбцов, кратко рассмотренные в главе 1).

Во-вторых, каждое внешнее представление, как правило, также будет реляционным или достаточно близким к нему. Например, объявления записей в PL/I и COBOL, представленные на рис. 2.2, упрошенно можно считать аналогами объявления реляционной таблицы в реляционной системе.

Замечание. Между прочим, следует иметь в виду, что термин внешнее представление (часто- просто представление ) имеет, к сожалению, довольно специфический смысл в реляционном контексте, который не полностью совпадает со смыслом, приписанным ему в этой главе. Выяснение реляционного смысла данного термина и его обсуждение приводятся в главах 3 и 9.

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

Теперь перейдем к более детальному исследованию трех уровней архитектуры, начиная с внешнего уровня. На рис. 2.3 показаны основные компоненты архитектуры и их взаимосвязь. На этот рисунок мы будем часто ссылаться в данной главе.

2.3. Внешний уровень

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

У каждого пользователя есть свой язык общения.

Для прикладного программиста это либо один из распространенных языков программирования (например, PL/I, С++ или Java), либо специальный язык рассматриваемой системы. Такие оригинальные языки называют языками четвертого поколения на том (не вполне определенном!) основании, что машинный код, язык ассемблера и такие языки, как PL/I, можно считать языками трех первых поколений , а оригинальные языки модернизированы по сравнению с языками третьего поколения так же, как языки третьего поколения улучшены по сравнению с языком ассемблера.

Для конечного пользователя это или специальный язык запросов, или язык специального назначения, который может быть основан на использовании форм и меню, разработан специально с учетом требований пользователя и интерактивно поддерживаться некоторым оперативным приложением (как указывалось в главе 1).

Для нашего обсуждения важно, что все эти языки включают подъязык данных, т.е. подмножество операторов всего языка, связанное только с объектами баз данных и операциями с ними. Иначе говоря, подъязык данных встроен в базовый язык, который дополнительно обеспечивает различные не связанные с базами данных возможности (такие, как локальные (временные) переменные, вычислительные операции, логические операции и т.д.). Система может поддерживать любое количество базовых языков и любое количество подъязыков данных. Однако существует один язык, который поддерживается практически всеми сегодняшними системами. Это язык SQL, который кратко был представлен в главе L Большинство систем позволяет использовать язык SQL и интерактивно, как самостоятельный язык запросов, и посредством внедрения его операторов в другие языки программирования, такие как PL/I и Java. (Подробности приводятся в главе 4.)

Хотя с точки зрения архитектуры удобно различать подъязык данных и включающий его базовый язык, на практике они могут быть неразличимы настолько, насколько это имеет отношение к пользователю. Безусловно, с точки зрения пользователя предпочтительнее, чтобы они были неразличимы. Если они неразличимы или трудноразличимы, их называют сильно связанными. Если они ясно и легко различаются, говорят, что эти языки слабо связаны. В то время как некоторые коммерческие системы (особенно объектные системы; см. главу 24) поддерживают сильную связь, большинство систем, в частности системы SQL, обычно поддерживают лишь слабую связь. Системы с сильной связью могли бы предоставить пользователю более унифицированный набор возможностей, но, очевидно, они требуют больше усилий со стороны системных проектировщиков и разработчиков, которые, вероятно, рассчитывают на сохранение статус-кво.

В принципе, любой подъязык данных является на самом деле комбинацией по крайней мере двух подчиненных языков - языка определения данных (data definition language - DDL), который поддерживает определения или объявления объектов базы данных, и языка обработки данных (data manipulation language - DML), который поддерживает операции с такими объектами или их обработку. Например, рассмотрим пользователя языка PL/I (см. рис. 2.2). Подъязык данных этого пользователя включает определенные средства языка PL/I, применяемые для организации взаимодействия с СУБД.

Язык определения данных включает некоторые описательные структуры языка PL/I, необходимые для объявления объектов базы данных. Это сам оператор DECLARE (DCL), определенные типы данных языка PL/I, а также возможные специальные дополнения для языка PL/I, предназначенные для поддержки новых объектов, которые не поддерживаются существующей версией языка PL/I.

Язык обработки данных состоит из тех выполняемых операторов языка PL/I, которые передают информацию в базу данных и из нее; опять же, возможно, включая новые специальные операторы.

Пользователь А1 Пользователь А2 Пользователь Б1 Пользователь Б2 Пользователь БЗ

Схемы и отображения создаются сопровождаются администратором базы данных (АБД)

)ТСЯ f

ipoM д

Базовый язык +

юдъязык данных

Бгровый язык +

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

Базовый язык +

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

Базовый язык +

юдъязык данных

Базовый язык +

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

*Внешняя схема А

Определение структур хранения (внутренняя схема)

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

Внешнее представление Б

Внешняя схема Б

Отображение Отображение

внешний/концептуальный схемы А внешний/концептуальный схемы Б

Концептуальная схема

Концептуальное представление

Отобргение концептуальный/внутренний

(С= (С:::! (С (С=::

Хранимая база данных (внутреннее представление)

1 1 L J L J I )

Интерфейс пользователя

Рис. 2.3. Детальная схема архитектуры системы баз данных