    Глава 2 

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

    2.1. Цель 

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

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

    Архитектура ANSI/SPARC включает три уровня: внутренний, концептуальный и 
внешний (рис. 2.1). В общих чертах они представляют собой следующее: 
    •   Внутренний уровень — это уровень, наиболее близкий к физическому 
хранению, т.е. связанный со способами сохранения информации на физических 
устройствах хранения. 
    •   Внешний уровень наиболее близок к пользователям, т.е. он связан со 
способами представления данных для отдельных пользователей. 
    •  Концептуальный уровень — это "промежуточный" уровень между двумя первыми. 
    Если внешний уровень связан с индивидуальными представлениями 
пользователей, то концептуальный уровень связан с обобщенным представлением 
пользователей. Иначе говоря, может быть несколько внешних представлений, 
каждое из которых состоит из более или менее абстрактного представления 
определенной части базы данных, и может быть только одно концептуальное 
представление, состоящее из абстрактного представления базы данных в целом. 
(Вспомните, что большинство пользователей интересует не вся база данных, а 
только определенная ограниченная ее часть.) Также есть единственное внутреннее 
представление, отражающее всю базу данных как физически хранимую. 

    36	Часть I. Основные понятия 

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


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


Вннешний  (PL/I)________		Внешний (CCBOL)___________
DCL	1 ЕМРР,			01 ЕМРС.
	2 EMPt CHAR(6),		02 EMPNO PIC X(6) . ________
	3 SAL FIXED BIN(31);	02 РЕРТЮ PIC X(4) .

Концептуальный_________
EMPLOYEE
EMPLOYEE_SIUMBER	CHARACTER   (6) 
DEPARTMENTJCMBER	CHARACTER   (4)
SALARY			NUMERIC          (5)

Внутренний____________
STORED_EMP	LENTH=20
PREFIX		TYPE=BYTE(6),   	OFFSET=0 
EMP#                         TYPE=BYTE(6),   	OFFSET=6,   INDEX=EMPX 
DEPT#		TYPE=BYTE(4),   	OFFSET=12 
PAY		TYPE=FULLWORD,OFFSET=16

Рис, 2.2. Пример трех уровней


Пример нуждается в пояснениях.

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

•  На внутреннем уровне служащие представлены типом хранимой записи STORED_EMP, длина которой 
двадцать байтов. Запись STORED_EMP содержит четыре хранимых поля: шестибайтовый префикс 
(возможно, содержащий управ-

Глава 2. Архитектура системы баз данных 37

ляющую информацию, такую как флаги или указатели) и три поля данных, 
соответствующих трем свойствам служащих. Кроме этого, записи STORED_EMP 
индексированы по полю ЕМР# индексом ЕМРХ, определение которого не показано.
    •  Пользователь PL/I имеет дело с внешним представлением базы данных, в 
котором' каждый сотрудник представлен записью на языке PL/1, содержащей два 
поля (номера отдела не представляют интереса для этого пользователя и поэтому 
в представлении опущены). Тип записи определен с помощью обычной структуры, 
соответствующей правилам PL/1. 
    •  Точно так же и пользователь COBOL имеет дело с внешним представлением 
базы данных, в котором каждый сотрудник представлен записью на языке COBOL, 
содержащей опять же два поля (в данном случае опущен размер оклада). Тип 
записи определен с помощью обычного описания на языке COBOL в соответствии с 
его стандартными правилами. 
    Обратите внимание, что соответствующие объекты могут иметь различные имена 
в каждом случае. Например, к номеру сотрудника обращаются: ЕМР# в 
представлении PL/1, EMPNO в представлении COBOL, EMPLOYEE_NUMBER в 
концептуальном представлении и вновь ЕМР# во внутреннем представлении. 
    В данном случае не имеет особого значения, является ли рассматриваемая 
система реляционной или какой-нибудь иной. Но было бы полезно показать, как 
три уровня архитектуры обычно реализуются в реляционной системе. 
    •  Во-первых, концептуальный уровень в такой системе будет определенно 
реляционным в том смысле, что объекты, которые видны на этом уровне, являются 
реляционными таблицами (также и операторы будут реляционными, включая те, 
которые работают с такими таблицами, например операторы выборки строк и 
столбцов, кратко рассмотренные в главе 1). 
    •  Во-вторых, данное внешнее представление будет также реляционным или, во 
вся-ком случае, очень близким к этому. 
    Замечание. Между прочим, следует иметь в виду, что термин "внешнее 
представление" (часто просто "представление") имеет, к сожалению, довольно 
специфический смысл в реляционном контексте, который не полностью совпадает со 
смыслом, приписанным ему в этой главе. (Выяснение реляционного смысла термина 
приводится далее в этой книге.) 
    •  В-третьих, внутренний уровень не будет реляционным, поскольку объекты 
на этом уровне не будут реляционными таблицами (сохраняемыми), а наоборот, 
будут объектами такого же типа, как и находящиеся на внутреннем уровне объекты 
любой другой системы (сохраняемые записи, указатели, индексы, случайные данные 
и т.п.). В действительности реляционная теория как таковая ничего 
существенного не может сказать о внутреннем уровне; она, как было отмечено в 
главе 1, имеет отношение к тому, как воспринимает базу данных пользователь. 
Теперь перейдем к более детальному исследованию трех уровней архитектуры. 
Начнем с внешнего уровня. На рис. 2.3 показаны основные компоненты архитектуры 
и их взаимосвязь. На этот рисунок мы будем часто ссылаться в данной главе. 

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

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

    38	Часть I. Основные понятия 

    У каждого пользователя есть свой язык общения. 
    •  Для прикладного программиста это либо один из распространенных языков 
программирования, такой как С, COBOL или PL/1, либо специальный язык 
рассматриваемой системы. Такие оригинальные языки называют (неформально!) 
языками четвертого поколения на том основании, что машинный код, язык 
ассемблера и такие языки, как COBOL, можно считать языками трех первых 
"поколений", а оригинальные языки модернизированы по сравнению с языками 
третьего поколения так же, как языки третьего поколения улучшены по сравнению 
с языком ассемблера. 
    •  Для конечного пользователя это или специальный язык запросов, или язык 
специального назначения, возможно, основанный на формах и меню, созданный 
специально с учетом требований пользователя и поддерживаемый некоторым 
оперативным приложением. 
    Для нашего обсуждения важно, что все эти языки включают подъязык данных, 
т.е. подмножество операторов всего языка, связанное только с объектами и 
операциями баз данных. Иначе говоря, подъязык данных встроен в базовый язык, 
который также обеспечивает различные не связанные с базами данных возможности, 
такие как локальные (временные) переменные, вычислительные операции, 
логические операции типа if-then-else и т.д. Система может поддерживать любое 
количество базовых языков и любое количество подъязыков данных. Однако 
существует один язык, который поддерживается практически всеми сегодняшними 
системами — это язык SQL, который кратко был описан в главе 1. Большинство 
систем позволяет использовать SQL и как отдельный язык запросов, и как 
встроенный в другие языки, такие как С и COBOL. (Подробнее это обсуждается в 
последующих главах книги.) 
    Хотя с точки зрения архитектуры удобно различать подъязык данных и 
включающий его базовый язык, на практике они могут быть неразличимы настолько, 
насколько это имеет отношение к пользователю. Безусловно, с точки зрения 
пользователя, предпочтительнее, чтобы они были неразличимы. Если они 
неразличимы или трудноразличимы, их называют сильно связанными. Если они ясно 
и легко различаются, говорят, что они слабо связаны. Большинство систем на 
сегодняшний день поддерживает лишь слабую связь. Системы с сильной связью 
могли бы предоставить пользователю более унифицированный набор возможностей, 
но, очевидно, требуют больше усилий со стороны системных проектировщиков и 
разработчиков (которые, вероятно, рассчитывают на статус-кво); однако есть 
основания предполагать, что на протяжении следующих нескольких лет будет 
происходить постепенное продвижение к более сильно связанным системам. 
    В принципе любой подъязык данных является на самом деле комбинацией по 
крайней мере двух подчиненных языков — языка определения данных (data 
definition language— DDL), который поддерживает определения или объявления 
объектов базы данных, и языка обработки данных (data manipulation language — 
DML), который поддерживает операции с такими объектами или их обработку. 
Например, рассмотрим пользователя языка PL/I (см. рис. 2.2). Подъязык данных 
для этого пользователя содержит такие возможности PL/1, которые используются 
для поддержки связи с СУБД. 
    • Язык определения данных содержит такие описательные структуры PL/1, 
которые требуются для объявления объектов базы данных, — сам оператор DECLARE 
(DCL), определенные типы данных PL/1, возможные специальные дополнения для 
языка PL/1, чтобы поддерживать новые объекты, которые не обрабатываются 
существующим PL/I. 
    • Язык обработки данных состоит из таких выполняемых операторов PL/1, 
которые передают информацию в и из базы данных; опять же, возможно, включая 
специальные новые операторы. 
    
    Глава 2, Архитектура системы баз данных 39 


Рис. 2.3. Детализированная архитектура системы

    Глава 2, Архитектура системы баз данных 40


    Замечание. Современный язык PL/I на самом деле вовсе не включает никаких 
особых возможностей для работы с базами данных. Оператор языка обработки 
данных, в частности, обычно просто обращается к СУБД (хотя такие обращения 
могут быть синтаксически скрыты, чтобы сделать их несколько дружественнее для 
пользователя). Так происходит потому, что системы PL/1, подобно большинству 
других существующих сегодня систем, реально предоставляют лишь очень слабо 
связанные подъязыки данных и его базовый язык. 
    Вернемся к архитектуре. Как уже отмечалось, отдельного пользователя 
интересует только некоторая часть всей базы данных; кроме того, 
пользовательское представление такой части будет вообще чем-то абстрактным по 
сравнению со способом физического хранения данных. В соответствии с 
терминологией ANSI/SPARC представление отдельного пользователя называется 
внешним представлением. Таким образом, внешнее представление — это содержимое 
базы данных, каким видит его определенный пользователь (т.е. для этого 
пользователя внешнее представление и есть база данных). Например, пользователь 
из отдела кадров может рассматривать базу данных как набор записей с 
информацией об отделах плюс набор записей с информацией о служащих и ничего не 
знать о записях с информацией о деталях и поставщиках, с которыми работают 
пользователи в отделе обеспечения. 
    В общем, внешнее представление состоит из множества экземпляров каждого 
типа внешней записи, которые, в свою очередь, отнюдь не обязательно должны 
совпадать с хранимыми записями. Находящийся в распоряжении пользователя 
подъязык данных определен в терминах внешних записей; например, операция 
выборки языка обработки данных будет проводить выборку из экземпляров внешних, 
а не хранимых записей. 
    Замечание. В данный момент предполагается, что вся информация представлена 
на внешнем уровне в форме записей. Некоторые системы представляют информацию 
иначе, например в форме "связей" или указателей. Для систем, использующих 
такие альтернативные методы, все определения и пояснения этого раздела требуют 
соответствующих изменений. Это замечание касается также концептуального и 
внутреннего уровней. 
    Здесь необходимо отметить, что термин "логическая запись", который 
употреблялся в главе 1, на самом деле имеет тот же смысл, что и термин 
"внешняя запись". В дальнейшем мы будем избегать использования термина 
"логическая запись". 
    Каждое внешнее представление определяется средствами внешней схемы, 
которая в основном состоит из определений каждого типа записей во внешнем 
представлении. Внешняя схема написана с помощью языка определения данных из 
пользовательского подъязыка данных. (Поэтому язык определения данных иногда 
называют внешним языком определения данных.) Например, тип внешней записи (см. 
рис. 2.2) можно определить как шестисимвольное поле с номером служащего плюс 
пятицифровое (десятичное) поле его зарплаты и т.д. Кроме этого, необходимо 
определить отображение между внешней схемой и основной концептуальной схемой. 
Это отображение рассматривается ниже в этой главе. 

    2.4. Концептуальный уровень 

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

    Глава 2, Архитектура системы баз данных	41 

    Концептуальное представление состоит из множества экземпляров каждого типа 
концептуальной записи. Например, оно может состоять из набора экземпляров 
записей, содержащих информацию об отделах, плюс набор экземпляров, содержащих 
информацию о поставщиках, плюс набор экземпляров, содержащих информацию о 
деталях и т.д. Концептуальная запись вовсе не обязательно должна совпадать с 
внешней записью, с одной стороны, и с хранимой записью — с другой. 
    Замечание. Необходимо отметить, что могут быть и другие способы 
представления данных на концептуальном уровне, которые вообще не используют 
записей как таковых и поэтому в некотором отношении предпочтительнее [2.7]. 
Например, вместо того чтобы рассматривать понятие концептуальной записи, можно 
рассматривать объекты и, возможно, отношения между ними в несколько более 
прямой форме. Однако такие рассуждения выходят за рамки первой части книги. (К 
ним мы вернемся в последующих частях книги.) 
    Концептуальное представление определяется с помощью концептуальной схемы, 
которая включает определения каждого типа концептуальных записей (см. рис. 
2.2). Концептуальная схема использует другой язык определения данных — 
концептуальный. Чтобы добиться независимости данных, нельзя включать в 
определения концептуального языка любое рассмотрение структуры хранения или 
метода доступа. Определения концептуального языка должны относиться только к 
содержанию информации. Это означает, что в концептуальной схеме не должно быть 
никакого упоминания о представлении хранимого файла, последовательности 
хранимых записей, индексировании, хеш-адресации, указателях или других 
подробностях хранения или доступа. Если концептуальная схема действительно 
обеспечивает независимость данных в этом смысле, то внешние схемы, 
определенные на основе концептуальной, заведомо будут обеспечивать 
независимость данных. 
    Концептуальное представление — это представление всего содержимого базы 
данных, а концептуальная схема — это определение такого представления. Однако 
было бы ошибкой полагать, что концептуальная схема — это не более чем набор 
определений, больше напоминающих простые определения записей в программе на 
языке COBOL (или каком-либо другом). Определения в концептуальной схеме могут 
включать определения многих дополнительных средств, таких как средства 
безопасности или правила для обеспечения целостности, упомянутые в главе 1. 
Более того, некоторые авторитетные специалисты предлагают в качестве конечной 
цели концептуальной схемы описание всего предприятия — не только самих его 
данных, но также и того, как эти данные используются: как они перемещаются 
внутри предприятия, для чего используются в каждом конкретном месте, какая 
ревизия или иной контроль применяется к ним в каждом отдельном случае и т.д. 
[2.3]. Однако необходимо подчеркнуть, что ни одна сегодняшняя система реально 
не поддерживает такого концептуального уровня, который хотя бы немного 
приблизился к этой степени развитости; в большинстве существующих систем 
"концептуальная схема" в действительности представляет собой немного больше, 
чем простое объединение всех отдельных внешних схем с дополнительными 
средствами безопасности и правилами обеспечения целостности. Вероятно, со 
временем системы будут гораздо "интеллектуальнее" в поддержке концептуального уровня. 

    2.5. Внутренний уровень 

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

    42	Часть I. Основные понятия 

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

    2.6. Отображения 

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

    1 Блоки (или страницы) устройства ввода-вывода — это количество данных, 
передаваемых из вторичной памяти (памяти накопителя) в главную (оперативную) 
за одно обращение. Обычно страницы имеют размер 1, 2 или 4 Кбайт, 

    Глава 2. Архитектура системы баз данных	43 

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

    2.7. Администратор базы данных 

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

    •  Определение концептуальной схемы. 

    Администратор данных определяет, какие именно данные необходимо сохранять 
в базе данных, т.е. определяет объекты, в которых заинтересовано предприятие, 
а также информацию, которую необходимо записывать об этих объектах. Этот 
процесс обычно называют логическим (или концептуальным) проектированием базы 
данных. После того как содержимое базы данных определено администратором 
данных на абстрактном уровне, АБД создает соответствующую концептуальную схему 
с помощью концептуального языка определения данных. Объектная 
(откомпилированная) форма этой схемы будет использоваться СУБД при ответах на 
запросы, связанные с доступом. Исходная (не откомпилированная) форма будет 
играть роль справочного документа для пользователей системы. 
    (На практике редко все происходит точно по описанной схеме. Иногда сам 
администратор данных создает концептуальную схему, а иногда АБД занимается 
логическим проектированием.) 

    •  Определение внутренней схемы. 

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

    •  Взаимодействие с пользователями. 

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

    44	Часть I. Основные понятия 

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

    •  Определение правил безопасности и целостности. 

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

    •  Определение процедур резервного копирования и восстановления. 

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

    •  Управление производительностью и реагирование на изменяющиеся требования. 

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

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

    Система управления базой данных (СУБД) представляет собой программное 
обеспечение, которое управляет доступом к базе данных. Это происходит 
следующим образом. 
    1. Пользователь выдает запрос на доступ, применяя определенный подъязык 
данных (обычно SQL). 
    2. СУБД перехватывает этот запрос и анализирует его. 
    3. Затем СУБД просматривает внешнюю схему для этого пользователя, 
соответствующее отображение (внешний-концептуальный), концептуальную схему, 
отображение концептуальный-внутренний и определение структуры хранения. 
    4. И наконец, СУБД выполняет необходимые операции над хранимой базой данных. 

    Глава 2. Архитектура системы баз данных 45 

    В качестве примера предположим, что рассматривается выборка определенной 
экземпляра внешней записи. В общем случае поля будут использоваться из нескольких 
экземпляров концептуальных записей, которые, в свою очередь, будут запрашивать 
поля из нескольких экземпляров хранимых записей. СУБД должна сначала выбрать 
все требуемые экземпляры хранимых записей, затем построить требуемые 
экземпляры концептуальных записей и после этого сформировать экземпляр внешней 
записи. На каждом этапе могут требоваться преобразования типов данных или 
другие преобразования. 
    Конечно, описание предыдущего примера весьма упрощено; в данном случае 
предполагается, что весь процесс является интерпретируемым, т.е. анализ 
запроса, проверка различных схем и другие процедуры осуществляются во время 
выполнения. Интерпретация, в свою очередь, обычно имеет низкую 
производительность, поскольку на ее выполнение затрачивается много времени. На 
практике, однако, обычно имеется возможность скомпилировать запрос доступа 
перед его выполнением. Реальный пример системы, которая применяет такой подход 
— СУБД DB2 фирмы IBM. 
    Теперь рассмотрим функции СУБД немного подробнее. 

    •  Определения данных. 

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

    •  Обработка данных. 

    СУБД должна уметь обрабатывать запросы пользователя на выборку, изменение 
или удаление существующих данных в базе данных или на добавление новых данных 
в базу данных. Другими словами, СУБД должна включать в себя компонент 
процессора языка обработки данных. 
    Запросы языка обработки данных бывают "планируемые" и "непланируемые". 
    1.  Планируемый запрос — это запрос, необходимость которого предусмотрена 
заранее. Администратор базы данных, возможно, должен настроить физический 
проект базы данных таким образом, чтобы гарантировать достаточное 
быстродействие для таких запросов. 
    2.  Непланируемый запрос — это, наоборот, специальный запрос, 
необходимость которого не была предусмотрена заранее. Физический проект базы 
данных может подходить, а может и не подходить для рассматриваемого 
специального запроса. В общем, получение наибольшей возможной 
производительности для непланируемых запросов представляет собой одну из 
проблем СУБД. (Подробнее эта проблема будет обсуждаться в следующих частях книги.) 
    Согласно терминологии, введенной в разделе 1.3, планируемые запросы 
характерны для "операционных" приложений, а непланируемые — для приложений 
"поддержки решений". Более того, планируемые запросы обычно осуществляются из 
написанных заранее приложений, а непланируемые запросы по определению 
производятся интерактивно. 

    •  Безопасность и целостность данных. 

    СУБД должна контролировать пользовательские запросы и пресекать попытки 
нарушения правил безопасности и целостности, определенные АБД. 

    •  Восстановление данных и дублирование. 

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

    46 Часть I. Основные понятия 

    •  Словарь данных. 

    СУБД должна обеспечить функцию словаря данных. Сам словарь данных можно по 
праву считать базой данных (но не пользовательской, а системной). Словарь 
"содержит данные о данных" (иногда называемые метаданными), т.е. определения 
других объектов системы, а не просто "сырые данные". В частности, исходная и 
объектная формы различных схем (внешних, концептуальной и т.д.) и отображений 
будут сохранены в словаре. Расширенный словарь будет включать также 
перекрестные ссылки, показывающие, например, какие из программ какую часть 
базы данных используют, какие отчеты требуются тем или иным пользователям, 
какие терминалы подключены к системе и т.д. Словарь может быть (а на самом 
деле даже должен быть) интегрирован в определяемую им базу данных, а значит, 
должен содержать описание самого себя. Конечно, должна быть возможность 
обращения к словарю, как и к другой базе данных, например, для того чтобы 
узнать, какие программы и/или пользователи будут затронуты при предполагаемом 
внесении изменения в систему. (Дальнейшее обсужде ние этого вопроса 
приводится в следующих главах книги.) 
    Замечание. Здесь мы затронули область, в которой может возникнуть путаница 
из-за терминологии. То, что мы называем словарем, некоторые пользователи 
называют директорией или каталогом, потому что директории и каталоги в 
некотором смысле хуже настоящего словаря, а термин "словарь" зарезервирован 
для специального (важного) вида инструментов разработки приложений [2.6]. 
Также встречаются и другие термины —"хранилище данных" и "энциклопедия данных" [2.4-2.6] 

    •  Производительность. 

    Очевидно, что СУБД должна выполнять все указанные функции с максимально 
возможной эффективностью. 

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

    •  В системах управления файлами не учитывается внутренняя структура 
хранимых записей, а следовательно, они не могут обрабатывать запросы, 
предполагающие знание этой структуры (к подобным запросам относится, например, 
такой: "Найти всех служащих с зарплатой меньше $500"). 
    •  Они обычно предоставляют плохую поддержку правил безопасности и 
целостности, а также управления восстановлением данных и дублированием или 
вообще не предоставляют такой поддержки. 
    •  На уровне управления файлами нет настоящего словаря данных. 
    •  Они обеспечивают независимость данных гораздо хуже, чем это делают СУБД. 

    Глава 2. Архитектура системы баз данных 47 

    2.9. Система управления передачей данных 

    В этом разделе вкратце рассматривается тема передачи данных. Запросы к 
базе данных от конечных пользователей в действительности передаются в форме 
коммуникационных сообщений (от рабочей станции пользователя, которая может 
быть физически удалена от самой системы, к некоторому оперативному приложению, 
встроенному или нет, а от него к СУБД). Более того, ответы пользователю (от 
СУБД и оперативного приложения к станции пользователя) также передаются в 
форме таких сообщений. Передача подобных сообщений происходит под управлением 
другого программного компонента — диспетчера передачи данных. 
    Диспетчер передачи данных не является частью СУБД, а представляет собой 
автономную систему со своими собственными правами. Однако, поскольку от 
диспетчера передачи данных и СУБД требуется, очевидно, согласованная 
совместная работа, они иногда рассматриваются как равноправные партнеры 
"совместного предприятия" высокого уровня, называемого системой базы данных и 
передачи данных; в этой системе после обработки базой данных и диспетчером 
передачи данных СУБД просматривает все сообщения в и из используемого ею 
приложения. В этой книге, однако, нам еще нужно сравнительно немного сказать 
об обработке сообщений. Ниже кратко обсуждаются вопросы передачи данных между 
отдельными системами (т.е. между отдельными машинами в сети передачи данных), 
но это уже другая тема. 

    2.10. Архитектура клиент/сервер 

    В предыдущих разделах этой главы в подробностях обсуждалась так называемая 
архитектура ANSI/SPARC для систем баз данных. В частности, на рис. 2.3 
приведена упрощенная схема этой архитектуры. В этом разделе мы посмотрим на 
базу данных с несколько иной точки зрения. Общая цель систем баз данных — это, 
конечно, поддержка разработки и выполнения приложений баз данных. Поэтому на 
высоком уровне систему баз данных можно рассматривать как систему с очень 
простой структурой, состоящей из двух частей — сервера (или машины базы 
данных) и набора клиентов (или внешнего интерфейса), см. рис. 2.4. 
    •  Сервер — это собственно СУБД. Он поддерживает все основные функции 
СУБД, которые обсуждались выше, а именно: определение данных, обработку 
данных, защиту и целостность данных и т.д. В частности, он предоставляет 
полную поддержку на внешнем, концептуальном и внутреннем уровнях. Поэтому 
"сервер" в этом контексте — это просто другое имя СУБД. 
    •  Клиенты — это различные приложения, которые выполняются "над" СУБД: 
приложения, написанные пользователями, и встроенные приложения, 
предоставляемые поставщиками СУБД или некоторыми сторонними поставщиками 
программного обеспечения. Конечно, с точки зрения пользователей, нет разницы 
между встроенными приложениями и приложениями, написанными пользователем, — 
все они используют один и тот же интерфейс сервера, а именно интерфейс 
внешнего уровня. 
    Замечание. Исключениями являются специальные "служебные" приложения. Как 
упоминалось выше, такие приложения иногда могут работать только 
непосредственно на внутреннем уровне системы. Такие утилиты скорее относятся к 
непосредственным компонентам СУБД, чем к приложениям в обычном смысле. В 
следующем разделе утилиты обсуждаются более подробно. 
    Приложения, в свою очередь, делятся на несколько четко определенных категорий. 
    1. Приложения, написанные пользователями. Это в основном профессиональные 
прикладные программы, написанные (обычно) либо на общепринятом языке 
программирования, таком как С или COBOL, либо на некоторых оригинальных 
языках, таких как FOCUS, хотя в обоих случаях эти языки должны как-то 
связываться с соответствующим подъязыком данных, как указывалось выше в этой главе. 

    48 Часть I. Основные понятия 

    Приложения, предоставляемые поставщиками (часто называемые 
инструментальными средствами). В целом назначение таких средств — 
содействовать в процессе создания и выполнения других приложений, т.е. 
приложений, которые делаются специально для некоторой специфической задачи 
(хотя созданные приложения могут и не выглядеть как приложения в общепринятом 
смысле); и действительно, эта категория инструментальных средств позволяет 
пользователям, особенно конечным, создавать приложения без написания 
традиционных программ. Например, одно из предоставляемых поставщиками 
инструментальных средств может быть процессором языка запросов, с помощью 
которого конечный пользователь может выдавать незапланированные запросы к 
системе. Каждый такой запрос является, по существу, не чем иным, как маленьким 
(а может быть, и не совсем маленьким) специальным приложением, предназначенным 
для выполнения некоторых специфических функций. 

    Конечные пользователи 
    Клиенты 
    Сервер 
    База данных 

    Рис. 2.4, Архитектура клиент/сервер 

    Поставляемые инструментальные средства, в свою очередь, делятся на 
несколько самостоятельных классов: 
    • процессоры языков запросов; 
    • генераторы отчетов; 
    • графические бизнес-подсистемы; 
    • электронные таблицы; 
    • процессоры обычных языков; 
    • средства управления копированием; 
    • генераторы приложений; 
    • другие средства разработки приложений, включая CASE-продукты (CASE или 
Computer-Aided Software Engineering — автоматизация разработки программного 
обеспечения), и т.д. 
    Подробности об этих приложениях выходят за рамки данной книги, однако 
следует отметить, что (как утверждалось ранее) главная задача системы баз 
данных — это поддержка создания и выполнения приложений, поэтому качество 
имеющихся клиентных инструментальных средств должно быть главным фактором при 
выборе базы данных (т.е. процессе выбора подходящей системы для данного 
заказчика). Другими словами, СУБД сама по себе не единственный и не 
обязательно важнейший фактор, который нужно учитывать. 

    Глава 2. Архитектура системы баз данных 49 

    Завершим этот раздел предварительным указанием. Так как система в целом 
может быть четко разделена на две части (сервер и клиенты), появляется 
возможность работы этих двух частей на разных машинах. Иначе говоря, 
существует возможность распределенной обработки. Распределенная обработка 
предполагает, что отдельные машины можно соединить какой-нибудь 
коммуникационной сетью таким способом, что определенная задача, обрабатывающая 
данные, может быть распределена на нескольких машинах в сети. (На самом деле, 
эта возможность настолько заманчива по различным соображениям, главным образом 
практическим, что термин "клиент/сервер" стал применяться исключительно в 
случае, если сервер и клиенты действительно находятся на разных машинах. Такое 
применение термина — небрежное, но очень распространенное.) Более подробно 
распределенная обработка рассматривается ниже в этой главе. 

    2.11. Утилиты 

    Утилиты — это программы, разработанные для администратора и используемые 
при выполнении различных административных задач. Как уже упоминалось выше, 
некоторые утилиты выполняются на внешнем уровне системы и потому представляют 
собой не что иное, как приложения специального назначения; некоторые из них 
могут предоставляться даже не поставщиками СУБД, а скорее некоторыми 
сторонними поставщиками программного обеспечения. Однако другие утилиты 
выполняются непосредственно на внутреннем уровне (т.е. действительно являются 
частью сервера) и поэтому должны предоставляться поставщиками СУБД. 
    Ниже приводится несколько типичных примеров типов утилит, которые часто 
применяются на практике. 
    •  Процедуры загрузки, применяемые для создания первоначальной версии базы 
данных из одного или более файлов, которые не принадлежат базе данных. 
    •  Процедуры выгрузки-перезагрузки, применяемые для выгрузки базы данных 
или порции из нее, дублирования памяти с целью восстановления и перезагрузки 
данных из таких дублированных копий (конечно, "утилита перезагрузки", по 
существу, идентична рассмотренной утилите загрузки). 
    •  Процедуры реорганизации, применяемые для перераспределения данных в 
базе данных по различным соображениям (обычно выполняется для повышения 
производительности), например, для группировки некоторых данных каким-то 
определенным способом на диске или освобождения пространства, занятого 
данными, которые больше не используются. 
    •   Статистические процедуры, применяемые для вычисления различных 
статистических показателей производительности, таких как распределение 
размеров файлов или значений данных и счетчиков ввода-вывода и т.п. 
    •  Процедуры анализа, применяемые для анализа только что упомянутой статистики. 
    Этот список охватывает лишь небольшую часть функций, предоставляемых 
утилитами. Кроме перечисленных видов функций, существует множество других. 

    2.12. Распределенная обработка 

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

    50	Часть I, Основные понятия 

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

    Компьютер клиента 
    Удаленный доступ 
    Компьютер сервера 

    Рис. 2.5. Клиент и сервер запускаются на разных машинах 

    Как уже говорилось, термин "клиент/сервер" фактически стал синонимом 
структуры, изображенной на рис. 2.5, в соответствии с которой клиент и сервер 
запускаются на разных машинах. В действительности существует множество 
аргументов в пользу такой схемы. 
    •   Первый аргумент связан с параллельной обработкой, а именно: в этом 
случае для всей задачи применяется несколько процессоров и обработка сервера 
(базы данных) и клиента (приложения) осуществляется параллельно. Поэтому время 
ответа и производительное время должны уменьшиться. 
    •  Машина сервера может быть изготовлена по специальному заказу, 
приспособлена для работы с СУБД ("машина базы данных") и может обеспечить 
лучшую производительность СУБД. 
    •  Машина клиента может быть персональной станцией, приспособленной к 
потребностям конечного пользователя, и поэтому обеспечивать лучший интерфейс, 
полное соответствие требованиям, быструю реакцию и в целом дополнительные 
удобства при использовании. 
    •  Несколько разных машин клиентов могут иметь доступ к одной и той же 
машине сервера. Поэтому одна база данных может совместно использоваться 
несколькими отдельными клиентными системами (рис. 2.6). 
    К сказанному выше можно добавить еще одно преимущество выполнения сервера 
и клиента на отдельных машинах — соответствие практической работе многих 
предприятий. Это довольно распространенный способ для отдельного предприятия; 
например, банк работает со многими компьютерами, сохраняющими данные для одной 
части предприятия на одном компьютере, а данные для другой части— на другом. 
Это также очень распространено среди пользователей, которым необходим, по край-

    Глава 2, Архитектура системы баз данных 51 

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

    Компьютеры клиентов 
    Коммуникационная сеть 
    Компьютер сервера 

    Рис. 2.6. Один сервер, много клиентов 

    В заключение отметим последнее преимущество, которое состоит в том, что 
отдельная машина клиента может иметь доступ к нескольким разным машинам 
серверов (противоположный случай иллюстрирует рис. 2.6). Это полезная 
возможность, поскольку, как уже упоминалось, предприятие обычно выполняет 
обработку данных таким образом, что полный набор всех данных не сохраняется на 
одной машине, а распределяется на отдельных машинах, а для приложений иногда 
необходим доступ к данным нескольких машин. Такой доступ в основном 
предоставляется двумя способами. 
    1. Клиент может получать доступ к любому количеству серверов, но лишь к 
одному в одно и то же время (т.е. каждый запрос к базе данных должен быть 
направлен только к одному серверу). В такой системе невозможно за один запрос 
получить комбинированные данные двух или более серверов. Кроме того, 
пользователь в такой системе должен знать, на какой именно машине какая часть 
данных содержится. 
    2. Клиент может получать доступ к любому количеству серверов одновременно 
(т.е. за один запрос можно получить комбинированные данные двух или более 
серверов). В этом случае серверы рассматриваются клиентом как один (с 
логической точки зрения), и пользователь может не знать, на какой именно 
машине какая часть данных содержится. 

    52 Часть I. Основные понятия 

    
    Рис. 2.7. Каждая машина одновременно является и клиентом и сервером 

    Второй случай — это пример системы, которую обычно называют распределенной 
системой баз данных. Тема распределенных баз данных сама по себе весьма 
обширна. Подводя ее к логическому завершению, отметим следующее: полная 
поддержка для распределенных баз данных означает, что отдельное приложение 
может "прозрачно" обрабатывать данные, распределенные на множестве различных 
баз данных, управление которыми осуществляют разные СУБД, работающие на 
многочисленных машинах с различными операционными системами, соединенных 
вместе коммуникационными сетями. Здесь понятие "прозрачно" означает, что 
приложение выполняет обработку данных с логической точки зрения, как будто 
управление данными полностью осуществляется одной СУБД, работающей на 
отдельной машине. Такая возможность может показаться невероятно трудной 
задачей, но весьма желанной с практической точки зрения; ну а производители 
напряженно работают, чтобы сделать подобные системы реальностью. (Подробнее 
распределенные базы данных рассматриваетс я далее в этой книге.) 

    2.13. Резюме 

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

    Глава 2. Архитектура системы баз данных 53 

    физически); внешний уровень, наиболее близкий к пользователям (т.е. 
имеющий отношение к способу представления данных для отдельных пользователей); 
концептуальный уровень, который является промежуточным между двумя предыдущими 
(он предоставляет обобщенное представление данных). Восприятие данных на 
каждом из уровней описывается с помощью схемы (или нескольких схем в случае 
внешнего уровня). Отображения описывают соответствие между данной внешней 
схемой и концептуальной схемой, а также концептуальной и внутренней схемами. 
    Пользователи, т.е. конечные пользователи и прикладные программисты, 
которые работают на внешнем уровне, взаимодействуют с данными с помощью 
подъязыка данных, который разбивается по крайней мере на два компонента: язык 
определения данных и язык обработки данных. Подъязык данных встроен в базовый язык. 
    Замечание. Разделяющие границы между базовым языком и подъязыком данных, а 
также между языком определения данных и языком обработки данных в основном 
умозрительны по природе; в идеале они должны быть "прозрачны для пользователя". 
    Мы также детально рассмотрели функции администратора базы данных и СУБД. 
Кроме всего прочего, АБД несет ответственность за создание внутренней схемы 
(физическое проектирование базы данных); за создание же концептуальной схемы 
(логическое или концептуальное проектирование базы данных) несет 
ответственность администратор данных. А в функции СУБД среди прочих входит 
реализация запросов пользователей, написанных на языке определения данных и 
языке обработки данных. Функцией СУБД также является предоставление словаря данных. 
    Системы баз данных удобно рассматривать как простую структуру, состоящую 
из сервера (собственно СУБД) и набора клиентов (приложений). Клиент и сервер 
могут выполняться и зачастую выполняются на отдельных машинах, обеспечивая 
таким образом одну простую распределенную обработку. Каждый сервер может 
обслуживать много клиентов, а каждый клиент может работать так, как будто он 
имеет дело с одним сервером на одной машине, невзирая на реальное физическое 
положение дел, — в таком случае мы имеем настоящую распределенную систему баз данных. 

    Упражнения 

    2.1. Начертите схему архитектуры системы баз данных, представленной в этой 
главе (архитектура ANSI/SPARC). 
    2.2. Дайте определения следующим терминам: машина базы данных; внешний 
интерфейс; клиент; базовый язык; концептуальный язык определения; загрузка дан 
ных; схема; представление; отображение концептуальный-внутренний; логический 
проект базы данных; язык определения данных; словарь данных; физический проект 
базы данных; язык обработки данных; планируемый запрос подъязык данных; 
система базы данных и передачи данных; сервер; диспетчер передачи данных; 
распределенная база данных; выгрузка-перезагрузка; распределенная обработка; 
непланируемый запрос; пользовательский интерфейс; отображение 
внешний-концептуальный; утилита. 
    2.3. Объясните последовательность шагов, применяемых при выборке 
определенного экземпляра внешней записи. 
    2.4. Перечислите главные функции, выполняемые СУБД. 
    2.5. Перечислите главные функции, выполняемые АБД. 
    2.6. Укажите различия между СУБД и системой управления файлами. 
    2.7. Приведите несколько примеров приложений, предоставляемых 
поставщиками, или инструментальных средств. 
    2.8. Приведите несколько примеров утилит базы данных. 
    2.9. Рассмотрите любую доступную вам систему баз данных. Попытайтесь 
начертить эту систему в виде архитектуры ANSI/SPARC, как описано в этой главе. 
Полностью ли она поддерживает три уровня архитектуры? Как определены 

    54	Часть I. Основные понятия 

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

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

    Хотя некоторые из перечисленных ниже изданий были выпущены давно, в них 
можно найти полезную информацию, касающуюся понятий, представленных в этой главе. 
    2.1. ANSI/X3/SPARC Study Group on Data Base Management Systems. Interim 
Report // FDT (ACM SIGMOD bulletin). — 1975. — 7, № 2. 
    2.2. T'sichritzis 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, Архитектура системы баз данных	55 

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

    56	Часть I. Основные понятия 