2.1. Введение

Теперь, после изучения вводной главы, можно познакомиться с архитектурой систе- мы баз данных. Наша цель — заложить фундамент, на котором будет строиться даль- нейшее изложение. Именно на этот фундамент мы будем опираться при описании общих понятий и объяснении структуры специфических систем баз данных. Однако это вовсе не означает, что каждая система баз данных обязательно должна отвечать конкретному фундаменту или что предложенная конкретная архитектура является единственно воз- можным вариантом. Например, "малые" системы (см. главу 1), весьма вероятно, не бу- дут поддерживать все аспекты предложенной архитектуры. Тем не менее рассматривае- мая архитектура с достаточной точностью описывает большинство систем (и не только реляционных). Более того, она практически полностью согласуется с архитектурой, предложенной исследовательской группой ANSI/SPARC (Study Group on Data Management Systems), — так называемой архитектурой ANSI/SPARC [2.1], [2.2]. Однако здесь мы не будем придерживаться терминологии ANSI/SPARC во всех деталях.

Замечание. Материал этой главы подобен материалу предыдущей в том смысле, что он является основой, необходимой для полного понимания структуры и возможностей современных систем баз данных. По этой причине он также носит несколько абстракт- ный характер, а следовательно, он достаточно "сухой". Учитывая это, как и в случае изу- чения главы 1, предварительно можно бегло просмотреть настоящую главу, а затем, по мере освоения излагаемого в книге материала, возвращаться к отдельным ее разделам, непосредственно связанным с той или иной изучаемой вами темой.

2.2. Три уровня архитектуры

Архитектура ANSI/SPARC включает три уровня: внутренний, внешний и концепту- альный (рис. 2.1). В общих чертах они представляют собой следующее.

• Внутренний уровень (также называемый физическим) наиболее близок к физи- ческому хранилищу информации, т.е. связан со способами сохранения информа- ции на физических устройствах.

• Внешний уровень (также называемый пользовательским логическим) наиболее близок к пользователям, т.е. связан со способами представления данных для от- дельных пользователей.

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

Внешний уровень (представления отдельных пользователей)Концептуальный уровень (обобщенное представление пользователей)

Внутренний уровень (представление физического хранения) |

Рис. 2.1. Три уровня архитектуры ANSI/SPARC

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

Для лучшего понимания этих идей рассмотрим пример, представленный на рис. 2.2. Здесь отображено концептуальное представление простой базы данных о персонале, а также соответствующие ему внутреннее и два внешних представления (одно — для поль- зователя, применяющего язык PL/I, а другое — для пользователя, применяющего язык COBOL). Конечно, этот пример полностью гипотетичен и мало похож на реальные сис- темы, поскольку в нем умышленно опущены многие не относящиеся к делу детали.

Рассматриваемый здесь пример нуждается в пояснениях.

' Называя некоторое представление абстрактным, мы имеем в виду лишь то, что оно включа- ет логические конструкции, ориентированные на пользователя (например, логические записи или поля), и не включает машинно-ориентированные конструкции (например, биты или байты).

• На концептуальном уровне база данных содержит информацию о типе сущности с именем EMPLOYEE (служащий). Каждый экземпляр сущности EMPLOYEE включает атрибуты номера служащего EMPLOYEE_NOMBER (длиной шесть символов), номера отдела DEPARTMENT_NUMBER (длиной четыре символа) и зарплаты служащего SALARY (пять десятичных цифр).

• На внутреннем уровне служащие представлены типом хранимой записи STORED_EMP, длина которой составляет 20 байт. Запись STORED_EMP содержит че- тыре хранимых поля: шестибайтовый префикс (возможно, содержащий управ- ляющую информацию, такую как флаги или указатели) и три поля данных, соот- ветствующие трем свойствам сущности, которая представляет служащего. Кроме того, записи ST0RED_EMP индексированы по полю ЕМР# с помощью индекса ЕМРХ, определение которого не показано.

Внешний (PL/I)

Внешний (COBOL)

DCL

1. EMPP,

2. EMPi CHAR(6),

3. SAL FIXED BIN(31)

01 EMPC.

02 EMPNO PIC X(6) 02 DEPTNO PIC X(4]

Концептуальный 1

EMPLOYEE

EMPLOYEE JJUMBER

DEPARTMENT NUMBER SALARY ~

CHARACTER (6) CHARACTER (4)

NUMERIC (5)

Внутренний

STORED EMP PREFIX EMPi

DEPTi PAY

OFFSET=0

BYTES=20 TYPE=BYTE(6) TYPE=BYTE(6j INDEX=EMPX TYPE=BYTE(4)

OFFSET=12

TYPE=FULLWORD, OFFSET=16

OFFSET=6,

Рис. 2.2. Пример трех уровней представления базы данных

• Пользователь, применяющий язык PL/I, имеет дело с соответствующим внеш- ним представлением базы данных. В нем каждый сотрудник представлен за- писью на языке PL/I, содержащей два поля (номера отделов не представляют интереса для данного пользователя, поэтому в представлении они опущены). Тип записи определен с помощью обычной структуры, соответствующей пра- вилам языка PL/I.

• Аналогично пользователь, применяющий язык COBOL, имеет дело с собст- венным внешним представлением базы данных, в котором каждый сотрудник представлен записью на языке COBOL, содержащей, опять же, два поля (в данном случае опущен размер оклада). Тип записи определен с помощью обычного описания на языке COBOL в соответствии с принятыми в нем стан- дартными правилами.

Обратите внимание, что в каждом случае соответствующие элементы данных могут иметь различные имена. Например, к номеру сотрудника обращаются, как к полю EMPi в представлении для языка PL/I и как к полю EMPNO в представлении для языка COBOL. Этот же атрибут в концептуальном представлении имеет имя EMPLOYEE_NUMBER, а во внутреннем представлении— имя EMPi. Конечно, системе должны быть известны все эти соответствия. Например, она должна знать, что поле EMPNO в представлении для язы- ка COBOL образовано из концептуального поля EMPLOYEE_NUMBER, которое, в свою оче- редь, отвечает хранимому полю EMPI во внутреннем представлении. Такие соответствия, или отображения (mapping), явно не показаны на рис. 2.2 (дальнейшее обсуждение этих вопросов будет продолжено в разделе 2.6).

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

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

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

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

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

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