Глава Z

Архитектура системы баз данных

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 NUMBER (длиной шесть символов), номера отдела DEPARTMENT NUMBER (длиной четыре символа) и зарплаты служащего SALARY (пять десятичных цифр).

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

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

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

1 EMPP,

2 EMPI CHAR(6),

3 SAL FIXED BIN(3i;

Внешний (COBOL)

01 EMPC.

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

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

EMPLOYEE

EMPLOYEE NUMBER

DEPARTMENT NUMBER SALARY ~

CHARACTER (6) CHARACTER (4)

NUMERIC (5)

Внутренний 1

STORED EMP PREFIX EMPt

DEPTI PAY

BYTES=20

TYPE=BYTE(6;

TYPE=BYTE(6;

INDEX=EMPX

TYPE=BYTE(4;

OFFSET=0

0FFSET=12

0FFSET=6,

TYPE=FULLWORD, 0FFSET=16

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

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

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

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

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