«Boston • San Francisco • New York London • Toronto • Sydney • Tokyo • Singapore • Madrid Mexico City • Munich • Paris • Cape Town • Hong Kong • Montreal Введение в системы баз данных К. Дж. Дейт Москва • Санкт-Петербург ...»

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

это трудности, порождаемые используемой структурой интерфейса управления данными.

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

1. Для разных приложений требуются разные представления одних и тех же данных.

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

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

2. Администратор базы данных должен иметь определенные возможности (завися щие от применяемой СУБД) по изменению физического представления или метода доступа к данным в случае изменения требований, причем без необходи мости модифицировать существующие приложения. Например, к базе данных могут быть добавлены новые виды данных, на предприятии могут быть приняты новые стандарты, могут быть изменены приоритеты приложений (а следовательно, и 64 Часть I. Основные понятия связанные с ними требования к производительности), могут появиться новые типы запоминающих устройств и т.д. Если приложения зависят от данных, то подобные изменения потребуют внесения корректировок в программы, а значит, дополнительных трудозатрат программистов, которые можно было бы направить на создание новых приложений. До сих пор подобные проблемы не являются исключением. И сегодня случается, что значительная часть рабочего времени программистов тратится на подобную работу (достаточно вспомнить хотя бы проблему 2000-го года!), а это, конечно, бесполезная трата дефицитных Таким образом, обеспечение независимости от данных — важнейшая цель создания систем баз данных. Независимость от данных можно определить как невосприимчивость приложений к изменениям в физическом представлении данных и в методах доступа к ним, а это означает, что рассматриваемые приложения не зависят от любых конкретных способов физического представления информации или выбранных методов доступа к ним. В главе 2 будет описана архитектура систем баз данных, обеспечивающая основу для достижения этой цели. Однако прежде всего рассмотрим более подробно некоторые примеры тех видов изменений, в выполнении которых может возникнуть необходимость и к которым, следовательно, должны быть невосприимчивы приложения.

Начнем с определения трех новых терминов: хранимое поле, хранимая запись и хранимый файл (рис. 1.6).

Хранимое поле — это наименьшая единица хранимых данных. Типичная база данных содержит множество экземпляров (occurence, или instance) каждого из нескольких описанных в ней типов хранимых полей. Например, база данных, содержащая информацию о деталях, может включать тип хранимого поля с име нем "номер детали" и для каждого описанного в базе данных вида детали (винта, шарнира, колпака и т.д.) будет существовать отдельный экземпляр этого храни Примечание. На практике часто опускают квалификаторы тип и экземпляр, полагая, что точный смысл ясен из контекста. Хотя и существует небольшая вероятность путаницы, это удобная практика, и мы будем ей время от времени следовать. (Такое примечание относится также к хранимым записям, речь о которых пойдет в следующем абзаце.) Хранимая запись — это набор взаимосвязанных хранимых полей. И снова мы раз личаем для них тип и экземпляр. В данном случае экземпляр хранимой записи со стоит из группы связанных экземпляров хранимых полей. Например, экземпляр хранимой записи в базе данных деталей состоит из экземпляров каждого из сле дующих хранимых полей: "номер детали", "название детали", "цвет детали" и "вес детали". Мы говорим, что база данных содержит множество экземпляров храни мой записи типа "деталь" (опять же, по одному экземпляру для каждой конкрет Наконец, хранимый файл — это набор всех существующих в настоящий момент эк земпляров хранимых записей одного и того же типа. (Для упрощения предполага ется, что любой заданный хранимый файл может содержать хранимые записи только одного типа. Это упрощение не окажет существенного влияния на последующие рассуждения.) В современных системах, отличных от баз данных, логическая (с точки зрения разработчика приложения) запись обычно совпадает с соответствующей хранимой записью.

Как было показано выше, в базах данных это вовсе не обязательно, поскольку в любой момент может потребоваться внести изменения в структуру хранения данных (т.е. в хранимые поля, записи, файлы), в то время как структура данных с точки зрения приложения должна остаться неизменной. Например, поле SALARY В файле EMPLOYEE ДЛЯ ЭКОНОМИИ памяти может быть сохранено в двоичном формате, а в приложении, написанном на языке COBOL, это поле может рассматриваться в качестве символьной строки.

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

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

66 Часть I. Основные понятия Однако, в принципе, разница между теми данными, к которым получает доступ приложение, и теми, которые хранятся в базе на самом деле, может быть весьма значительной.

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

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

Представление символьных данных Поле в формате символьной строки может храниться с использованием любого из существующих наборов кодировок символов (например ASCII, EBCDIC, Unicode).

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

Кодирование данных В некоторых ситуациях может понадобиться представлять хранимые данные в виде кодированных значений. В частности, поле "цвет детали", которое представлено в приложении как символьная строка ("красный", "голубой", "зеленый"), может храниться в виде десятичной цифры в соответствии с некоторой таблицей перекодировки, например 1 = "красный", 2 = "голубой" и т.д.

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

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

Структура хранимых записей Две существующие хранимые записи можно объединить в одну. Например, хранимые записи можно представить в форме:

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

некоторые поля хранимой записи "невидимы" для рассматриваемого приложения.

И наоборот, одна хранимая запись может быть разделена на две. Воспользуемся записями из предыдущего примера. Тогда хранимую запись можно разбить на две:

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

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

Этим мы ограничим перечень тех характеристик структуры хранения данных, которые могут подвергаться изменениям. Здесь среди всего прочего предполагается, что база данных может расти и развиваться, не оказывая влияния на приложения. В действительности, возможность развития базы данных без нарушения логической структуры существующих приложений является одним из наиболее важных стимулов для обеспечения независимости от данных. Например, можно было бы расширить существующий 68 Часть I. Основные понятия тип хранимой записи, добавив новые хранимые поля, которые обычно представляют дополнительную информацию о некоторых возможных типах сущностей (скажем, к хранимой записи "деталь" можно добавить поле "цена за штуку"). Такие новые поля будут невидимы для существующих приложений. Точно так же можно добавить новые типы хранимых записей (а следовательно, новые хранимые файлы), не изменяя существующих приложений. Подобные записи обычно представляют собой новые типы сущностей (например, к базе данных "детали" можно добавить тип записи "поставщик").

Эти изменения также будут незаметны для существующих приложений.

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

Примечание. Последнее примечание (относительно использующих язык SQL современных систем) вовсе не означает, что в подобных системах совершенно не обеспечена независимость от данных. Оно лишь указывает, что эти системы обеспечивают независимость от данных в значительно меньшей степени, чем теоретически возможно в реляционных системах4. Иными словами, независимость от данных — понятие относительное.

Различные системы обеспечивают ее в разной мере или не обеспечивают вообще. Системы, базирующиеся на языке SQL, более развиты в этом направлении, чем старые системы, но, как будет показано в следующих главах, все они еще далеки от совершенства.

1.6. РЕЛЯЦИОННЫЕ И ДРУГИЕ СИСТЕМЫ Как уже было сказано выше, системы с поддержкой SQL, или просто системы SQL, в настоящее время стали преобладающими на рынке баз данных, и одной из важных причин подобного состояния дел является именно то, что такие системы основаны на реляционной модели данных. Поэтому не удивительно, что в неформальном общении системы SQL часто называют просто реляционными системами5. Кроме того, подавляющее большинство научных исследований в области баз данных в течение последних 30 лет было посвящено (иногда косвенно) именно этой модели. Фактически, введение реляционной модели в 1969 и 1970 годах было, несомненно, наиболее важным событием во всей истории развития теории баз данных. По этим причинам, а также учитывая то, что реляционная модель основана на определенных математических и логических принципах и, следовательно, идеально подходит для изложения теоретических концепций систем баз данных, основное внимание в настоящей книге уделяется именно реляционным системам и реляционному подходу.

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

В приложении А приведен поразительный пример того, на что реляционные системы способны в этом отношении.

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

Итак, кратко и не совсем точно можно определить, что реляционная система — это система, основанная на описанных ниже принципах.

Данные рассматриваются пользователем как таблицы (и никак иначе).

Пользователю предоставляются операторы (например, для выборки данных), позволяющие генерировать новые таблицы на основании уже существующих.

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

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

Как уже упоминалось, в дальнейшем будет дано более точное определение, а пока мы будем использовать приведенное выше. На рис. 1.7 представлен пример структуры данных и операторов, используемых в реляционных системах. Данные, приведенные на рис. 1.7, а, состоят из одной таблицы CELLAR (в действительности это еще одна версия таблицы CELLAR (см. табл. 1.1), которая просто была уменьшена для того, чтобы с ней было легче работать). На рис. 1.7, б показаны два примера выборки данных: один— с получением подмножества строк (оператор сокращения), а другой — с получением подмножества столбцов (оператор проекции). В обоих этих примерах снова применяется язык SQL.

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

На основании изложенного можно сделать вывод, что системы баз данных могут быть пегко распределены по категориям в соответствии со структурами данных и операциями, которые они предоставляют пользователю. Прежде всего, старые (дореляционные) 70 Часть I. Основные понятия системы можно разделить на три большие категории6: системы с инвертированными списками (inverted list), иерархические (hierarchic) и сетевые (network). {Примечание. Термин сетевая система в данном случае не имеет ничего общего с коммуникационной сетью, как описано в следующей главе.) В настоящей книге эти категории подробно не рассматриваются, поскольку, по крайней мере, с точки зрения технологии, их можно считать устаревшими. Заинтересованный читатель может найти методическое описание всех трех систем в [1.5].

Рис. 1.7. Структура данных и операторы в реляционной системе (примеры) Следует отметить, что сетевые системы иногда называют системами CODASYL или системами DBTG (Data Base Task Group) в честь предложившего их подразделения организации CODASYL (Conference on Data Systems Language). Пожалуй, наиболее известной из таких систем была IDMS корпорации Computer Associates International, Inc. Подобно иерархическим системам (но в отличие от реляционных), все подобные системы предоставляют пользователю доступ к указателям.

Первые реляционные продукты начали появляться в конце 1970-х и начале 1980-х годов. Ко времени написания этой книги преобладающее большинство СУБД были реляционными (по меньшей мере, они поддерживали язык SQL) и предназначались для работы практически на любой существующей программной и аппаратной компьютерной платформе. Среди них ведущими (в алфавитном порядке) являлись следующие: DB По аналогии с реляционной моделью, в ранних изданиях книги использовались термины модель инвертированных списков, иерархическая модель и сетевая модель (они также использовались в других книгах). Однако это не совсем верно, поскольку по сравнению с реляционной моделью, "модели" инвертированного списка, иерархическая и сетевая были определены после свершившегося факта, т.е. соответствующие коммерческие продукты были реализованы раньше, а "модели" были определены впоследствии "по индукции" (в данном контексте так мы из вежливости назвали не подкрепленные теорией рассуждения) из уже существующих реализаций. Дополнительная информация по этой теме приведена в аннотации к [1.1].

(всевозможные версии) корпорации IBM; Ingres II корпорации Computer Associates International, Inc.; Informix Dynamic Server корпорации Informix Software, Inc.7; Microsoft SQL Server корпорации Microsoft; Oracle 8i корпорации Oracle и Sybase Adaptive Server компании Sybase, Inc.

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

DB2, Ingres (произносится "ингресс"), Informix, SQL Server, Oracle и Sybase.

В последнее время стали появляться объектно-ориентированные и объектно-реляционные продукты: первые объектные системы были выпущены в конце 1980-х и начале 1990-х годов, а объектно-реляционные системы были созданы в конце 1990-х годов. Большинство объектно-реляционных СУБД основываются на расширенных оригинальных реляционных продуктах, как в случае с DB2 или Informix. Существующие объектноориентированные системы иногда представляют собой попытки создать нечто совершенно отличное от других систем, как это имеет место в случае с системой GemStone корпорации GemStone Systems, Inc. и системой Versant ODBMS компании Versant Object Technology. Эти новые системы рассматриваются в части VI данной книги. (Следует отметить, что термин объект, применяемый в данном абзаце, имеет довольно специальное значение, как будет описано в части VI. Но в остальных частях настоящей книги, если не указано иное, этот термин используется в его обычном, универсальном смысле.) В дополнение к различным уже упоминавшимся выше подходам, в течение нескольких лет проводились исследования множества альтернативных схем, включая многомерный (multi-dimensional) подход и логический (logic-based) подход, называемый еще дедуктивным или экспертным. Мы рассмотрим многомерные системы в главе 22, а логические — в главе 24. Кроме того, в связи с наблюдающимся в последнее время стремительным ростом World Wide Web и расширением области применения языка XML, проявляется значительный интерес к направлению научной деятельности, которое получило (не совсем удачное) название полуструктурированный подход. Полуструктурированные системы рассматриваются в главе 27.

1.7. РЕЗЮМЕ Итак, подведем итог обсуждению основных вопросов. Систему баз данных можно рассматривать как компьютеризированную систему хранения записей. Такая система включает сами по себе данные (хранимые в базе данных), аппаратное обеспечение, программное обеспечение (в частности, систему управления базами данных, или СУБД), а также пользователей (что наиболее важно). Пользователи, в свою очередь, подразделяются на прикладных программистов, конечных пользователей и администраторов базы данных, или АБД. Последние отвечают за администрирование базы данных и всей системы баз данных в соответствии с требованиями, устанавливаемыми администратором данных.

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

Отделение разработки СУБД компании Informix Software, Inc. было приобретено корпорацией IBM в 2001 году.

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

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

И с экономической, и с формальной точек зрения можно считать, что реляционные системы являются наиболее важным сегментом рынка баз данных (и это положение дел, по-видимому, не изменится в обозримом будущем). Мы рассмотрели несколько примеров использования языка SQL — стандартного языка для работы с реляционными системами (в частности, были приведены примеры операторов SELECT, INSERT, DELETE И UPDATE этого языка). Материал данной книги в значительной мере ориентирован на реляционные системы и в меньшей мере — на сам язык SQL (по причинам, указанным в предисловии).

УПРАЖНЕНИЯ

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

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

1.3. Как вы понимаете термин реляционная система? Укажите различия между реляционной и нереляционной системами.

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

1.5. Приведите результат выполнения следующих операторов SQL выборки информации из базы данных винного погреба, представленной в табл. 11.

а) SELECT WINE, PRODUCER

FROM CELLAR

б) SELECT WINE, PRODUCER

FROM CELLAR

B) SELECT BIN#, WINE, YEAR

FROM CELLAR WHERE READY <

Г) SELECT WINE, BIN#, YEAR FROM CELLAR WHERE PRODUCER = 'Robt.

Mondavi' AND BOTTLES > б ;

1.6. Дайте собственную словесную интерпретацию типичной строки в одном из ответов на упр. 1.5, представив ее в виде истинного высказывания.

1.7. Приведите результат выполнения следующих операторов SQL внесения изменений в базу данных винного погреба, представленную в табл. 11.

а) INSERT INTO CELLAR (BIN#, WINE, PRODUCER, YEAR, BOTTLES, READY )f?

VALUES (80, 'Syrah', 'Meridian', 1998, 12, 2003 );

б) DELETE

FROM CELLAR

WHERE READY > 2004 ;

B) UPDATE CELLAR

SET BOTTLES = 5 WHERE

Г) UPDATE CELLAR

SET BOTTLES = BOTTLES + 1.8. Напишите оператор SQL для выполнения приведенных ниже операций в базе данных винного погреба.

а) Выбрать номер ячейки, наименование вина и количество бутылок для всех вин производства Geyser Peak.

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

в) Выбрать номер ячейки для всех красных вин.

г) Добавить три бутылки в ячейку с номером 3 0.

74 Часть I. Основные понятия д) Удалить из всего запаса вин все вина производства компании Chardonnay. % е) Добавить данные нового поступления (12 бутылок): производитель — Gary Farrell, сорт — Мегlot, ячейка номер 55, год выпуска — 2000, будет готово 1.9. Предположим, что у вас есть коллекция записей классической музыки, содержащаяся на компакт-дисках, мини-дисках, долгоиграющих пластинках и аудиокассетах, и вы хотите создать базу данных, которая позволит находить записи определенного композитора (например, Сибелиуса), дирижера (например, Симона Ратла), солиста (например, Артура Грюмикса), произведения (например, Пятой симфонии Бетховена), оркестра (например, Нью-Йоркского филармонического), вида произведения (например, концерта для скрипки) или оркестровой группы (например, квартета Кронус). Начертите диаграмму "сущность—связь" для этой базы данных по образцу, представленному на рис. 1.5.

СПИСОК ЛИТЕРАТУРЫ

1.1. Codd E.F. Data Models in Databases Management // Proc. Workshop on Data Abstrac tion, Database and Conceptual Modelling. — Pingree Park, Colo, June 1980. Эту статью можно также найти в ACM S1GART Newsletter.— January 1981, №74; ACM SIGMOD Record 11. — February 1981, № 2 и в других источниках.

Кодд является создателем реляционной модели, которую он впервые описал в [6.1]. Но в этой работе он на самом деле не дал определения термину модель данных как таковому; оно было дано гораздо позже, лишь в данной работе. В ней рассматривается вопрос "Каково назначение моделей данных вообще и реляционной модели в частности?", а также приводятся факты, подтверждающие, что вопреки распространенному мнению реляционная модель фактически стала самой первой моделью данных, которая была когда-либо определена. Иначе говоря, Кодда по праву называют создателем концепции модели данных вообще, а также реляционной модели в частности.

1.2. Darwen H. What a Database Really Is: Predicates and Propositions // Date C.J., Darwen H., and McGoveran D. Relational Database Writings 1994—1997. — Reading, Mass.:

Addison-Wesley, 1998.

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

1.3. Date C.J. and Hopewell P. Storage Structures and Physical Data Independence // Proc.

ACM SIGFIDET Workshop on Data Definition, Access, and Control. — San Diego, California. — November 1971.

1.4. Date C.J. and Hopewell P. File Definition and Logical Data Independence // Proc.

ACM SIGFIDET Workshop on Data Definition, Access, and Control. — San Diego, California. — November 1971.

Статьи [1.3], [1.4] являются первыми письменными работами, в которых было определено различие между физической и логической независимостью отданных.

1.5. Date C.J. Relation Database Writtings 1991-1994. — Reading, Mass.: Addison-Wesley, 1995.

Архитектура системы баз данных 2.1. Введение 2.2. Три уровня архитектуры 2.3. Внешний уровень 2.4. Концептуальный уровень 2.5. Внутренний уровень 2.6. Отображения 2.7. Администратор базы данных 2.8. Система управления базой данных 2.9 Система управления передачей данных 2.10. Архитектура "клиент/сервер" 2.11 Утилиты 2.12. Распределенная обработка 2.13. Резюме Список литературы 2.1. ВВЕДЕНИЕ Теперь, после изучения вводной главы, мы можем ознакомиться с архитектурой системы баз данных. Наша цель — "заложить фундамент", на котором будет строиться дальнейшее изложение. Именно на него мы будем опираться при описании общих понятий и изучении структуры конкретных систем баз данных.

Однако это отнюдь не означает, что каждая система баз данных обязательно должна соответствовать этому определению или что предложенная конкретная архитектура является единственно возможной. Например, "малые" системы (см. главу 1), весьма вероятно, не будут поддерживать все функции предложенной архитектуры. Тем не менее, рассматриваемая архитектура с достаточной точностью описывает большинство систем (и не только реляционных). Более того, она практически полностью согласуется с архитектурой, предложенной исследовательской 76 Часть I. Основные понятия группой 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 Внутренний уровень (называемый также физическим) наиболее близок к физиче скому хранилищу информации, т.е. связан со способами сохранения информации на физических устройствах.

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

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

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

Для лучшего понимания этих идей рассмотрим пример, представленный на рис. 2.2.

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

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

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

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

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

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

Обратите внимание, что в каждом случае соответствующие элементы данных могут иметь различные имена. Например, к номеру сотрудника обращаются как к полю ЕМР# в представлении для языка PL/I и как к полю EMPNO В представлении для языка COBOL.

Этот же атрибут в концептуальном представлении имеет имя EMPLOYEE_NUMBER, а во внутреннем представлении — имя ЕМР#. Конечно, в системе должны быть известны все эти соответствия. Например, известно, что поле EMPNO В представлении для языка COBOL образовано из концептуального поля EMPLOYEE_NUMBER, которое, в свою очередь, отвечает хранимому полю ЕМР# ВО внутреннем представлении. Такие соответствия, или отображения (mapping), на рис. 2.2 явно не показаны (дальнейшее обсуждение этих вопросов будет продолжено в разделе 2.6).

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

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

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

Примечание. Следует иметь в виду, что термин внешнее представление (часто — просто представление) в реляционном контексте имеет, к сожалению, довольно специфический смысл, который не полностью совпадает со смыслом, приписанным ему в этой главе. Выяснению реляционного смысла данного термина и его обсуждению посвящены главы 3 и (особенно) 10.

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

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

Рис. 2.3. Подробная схема архитектуры системы баз данных 2.3. ВНЕШНИЙ УРОВЕНЬ Внешний уровень — это индивидуальный уровень пользователя. Как было сказано в главе 1, пользователь может быть прикладным программистом или конечным пользователем с любым уровнем профессиональной подготовки. Особое место среди пользователей занимает администратор базы данных (АБД). В отличие от остальных пользователей, АБД интересуют также концептуальный и внутренний уровни. Об этом еще будет сказано в следующих двух разделах.

У каждого пользователя есть свой язык для работы с СУБД.

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

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

Для нашего обсуждения важно, что все эти языки включают подъязык данных, т.е.

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

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

В принципе, любой подъязык данных является на самом деле комбинацией по крайней мере двух подчиненных языков — языка определения данных (Data Definition Language — DDL), который позволяет формулировать определения или объявления объектов базы данных, и языка манипулирования3 данными (Data Manipulation Language — DML), который поддерживает операции с такими объектами или их обработку. Например, рассмотрим пользователя языка PL/I (см. рис. 2.2). Подъязык данных этого пользователя В этом смысле языком программирования базы данных вполне можно назвать язык Tutorial D, ко торый будет использоваться в следующих главах в качестве основы для примеров (см. примечания на эту тему в предисловии к данной книге).

Термин "манипулирование" (буквально — выполнение действий вручную), не очень удачный, но получил широкое распространение и поэтому утвержден официально.

включает определенные средства языка PL/I, применяемые для организации взаимодействия с СУБД.

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

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

Примечание. В качестве уточнения следует отметить, что современный язык PL/I на самом деле вообще не включает никаких особых средств для работы с базами данных.

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

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

В общем случае внешнее представление состоит из некоторого множества экземпляров каждого из многих типов внешних записей (которые вовсе не обязательно должны совпадать с хранимыми записями)4. Предоставляемый в распоряжение пользователя подъязык данных всегда определяется в терминах внешних записей. Например, операция выборки языка обработки данных осуществляет выборку экземпляров внешних, а не хранимых записей. (Теперь становится очевидно, что термин логическая запись, употреблявшийся в главе 1, на самом деле относится к внешним записям. Поэтому в дальнейшем мы будем избегать его использования.) Каждое внешнее представление определяется посредством внешней схемы, которая в основном состоит из определений записей каждого из типов, присутствующих в этом внешнем представлении (см. рис. 2.2). Внешняя схема записывается с помощью языка В данном случае предполагается, что вся информация на внешнем уровне представлена в форме записей. Но некоторые системы позволяют представлять информацию иначе: либо вместо записей, либо совместно с ними. Для использующих такие альтернативные методы систем все определения и пояснения этого раздела требуют соответствующих изменений. Это замечание касается также концептуального и внутреннего уровней. Детальное обсуждение подобных вопросов в этой части книги было бы преждевременным, поэтому мы вернемся к ним позднее, в главах 14 (в особенности — в разделе "Список литературы") и 25. См. также приложение А (где приведена подробная информация о внутреннем уровне).

82 Часть I. Основные понятия определения данных, являющегося подмножеством подъязыка данных пользователя.

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

2.4. КОНЦЕПТУАЛЬНЫЙ УРОВЕНЬ Концептуальное представление — это представление всей информации базы данных в несколько более абстрактной форме (как и в случае внешнего представления) по сравнению с описанием физического способа хранения данных. Однако концептуальное представление существенно отличается от представления данных какого-либо отдельного пользователя. Вообще говоря, концептуальное представление — это представление данных в том виде, какими они являются на самом деле, а не в том, какими их вынужден рассматривать пользователь в рамках, например, определенного языка или используемого аппаратного обеспечения.

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

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

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

2.5. ВНУТРЕННИЙ УРОВЕНЬ Третьим уровнем архитектуры является внутренний уровень. Внутреннее представление — это низкоуровневое представление всей базы данных как базы, состоящей из некоторого множества экземпляров каждого из существующих типов внутренних записей.

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

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

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

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

84 Часть I. Основные понятия правила защиты) и сохранения целостности данных (правила целостности также игнорируются). К тому же такая программа будет зависеть от определения обрабатываемых данных. Однако иногда подобный подход может быть единственным способом реализации требуемой функции или достижения необходимого быстродействия (иногда по аналогичным причинам приходится обращаться к средствам языка ассемблера пользователю языка высокого уровня).

2.6. ОТОБРАЖЕНИЯ Представленная на рис. 2.3 архитектура, кроме элементов самих трех уровней, включает определенные отображения: отображение концептуального уровня на внутренний и несколько отображений внешних уровней на концептуальный.

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

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

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

Очевидно, что отображение "концептуальный—внутренний" служит основой физической независимости от данных, а отображения "внешний—концептуальный" являются ключом к логической независимости от данных. Как было показано в главе 1, система обеспечивает физическую независимость от данных [1.3], если пользователи и пользовательские программы обладают невосприимчивостью к изменениям в физической структуре хранимой базы данных. Аналогично, система обеспечивает логическую независимость от данных [1.4], если пользователи и пользовательские программы обладают невосприимчивостью к изменениям в логической структуре базы данных (подразумеваются изменения на концептуальном или "общем логическом" уровне). Этот важный вопрос будет обсуждаться в главах 3 и 10.

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

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

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

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

Следует отметить, что на практике редко все происходит точно по описанной выше схеме. Иногда концептуальную схему создает сам АД, а логическим проектированием занимается АБД.

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

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

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

Каждая внешняя схема и соответствующее ей отображение будут существовать в исходной и объектной формах.

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

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

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

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

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

1024 Гбайт = 1 Тбайт (терабайт); 1024Тбайт = 1 Пбайт (петабайт); 1024 Пбайт = 1 Эбайт (эксабайт);

1024 Эбайт = 1 Дбайт (дзетабайт); 1024 Дбайт = 1 Йбайт (йотабайт). Кстати, вопреки распространенному мнению, первый слог в английском слове gigabyte является открытым и произносится с мягким начальным g (как в слове "gigantic").

еще более крупными. Понятно, что такие системы очень больших баз данных (Very Large DataBase — VLDB) требуют тщательного и продуманного администрирования, в особенности если необходимо обеспечить для пользователей постоянный доступ к базе данных (а часто именно так и бывает). Однако для простоты рассуждений будем по-прежнему подразумевать, что мы имеем дело с единственной базой данных.

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

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

2.8. СИСТЕМА УПРАВЛЕНИЯ БАЗОЙ ДАННЫХ

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

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

2. СУБД перехватывает этот запрос и анализирует его.

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

4. СУБД выполняет необходимые операции в хранимой базе данных.

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

Конечно, описание предыдущего примера весьма упрощено; в частности, в данном случае предполагается, что весь процесс основан на интерпретации (т.е. анализ запроса, проверка различных схем и другие процедуры осуществляются непосредственно во время 88 Часть I. Основные понятия выполнения). Однако интерпретация обычно характеризуется невысокой производительностью, поскольку на ее выполнение затрачивается много времени. На практике обычно существует возможность предварительно откомпилировать запрос на доступ к данным до начала его выполнения; в частности, в современных системах SQL применяется именно такой подход (см. аннотации к [4.131 и [4.271 в главе 4).

Теперь рассмотрим функции СУБД немного подробнее. Они обязательно будут включать поддержку работы компонентов базы данных, показанных на рис 2. Рис. 2.4. Основные функции и компоненты типичной СУБД Определение данных СУБД должна предоставлять средства определения данных в виде исходной формы (внешних схем, концептуальной схемы, внутренней схемы, а также всех необходимых отображений) и преобразования этих определений в соответствующую объектную форму. Иначе говоря, СУБД должна включать в себя компоненты процессора ЯОД (языка определения данных) или компилятора ЯОД для каждого из поддерживаемых ею языков определения данных. СУБД должна также правильно трактовать синтаксис языка определения данных, чтобы ей можно было, например, сообщить, что внешние записи EMPLOYEE включают поле SALARY. Эту информацию СУБД должна использовать при анализе и выполнении запросов обработки данных (таких как "Найти всех служащих с зарплатой, составляющей меньше 50 тыс. долл".).

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

а) Планируемый запрос — это запрос, необходимость выполнения которого была предусмотрена заранее. Администратор базы данных, возможно, должен будет разработать физический проект базы данных таким образом, чтобы гарантиро вать достаточное быстродействие выполнения подобных запросов.

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

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

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

90 Часть I. Основные понятия обсуждается в главе 18. Затем оптимизированные запросы выполняются под управлением диспетчера этапа прогона (run-time manager). На практике диспетчер этапа прогона для получения доступа к хранимым данным, возможно, будет использовать что-то подобное диспетчеру доступа к файлам. (Последний компонент кратко обсуждается в конце данного раздела.) Защита и поддержка целостности данных СУБД должна контролировать пользовательские запросы и пресекать любые попытки нарушения ограничений защиты и целостности данных, определенные АБД (см.

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

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

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

Следует отметить, что здесь мы коснулись области, в которой может возникнуть путаница из-за несовершенства используемой терминологии. То, что мы называем словарем (dictionary), иногда называют справочником (directory) или каталогом (catalog), потому что справочники и каталоги считаются в некотором смысле менее важными по сравнению с настоящими словарями, а термин словарь применяют для обозначения специального (более важного) вида инструментов разработки приложений. Также встречаются и другие термины — репозитарий данных (глава 14) и энциклопедия данных.

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

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

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

Система управления файлами не имеет никаких сведений о внутренней структуре хранимых записей и, следовательно, не способна обрабатывать запросы, требую щие знания этой структуры.

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

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

Вообще говоря, эти системы обеспечивают независимость от данных гораздо хуже по сравнению с СУБД.

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

2.9. СИСТЕМА УПРАВЛЕНИЯ ПЕРЕДАЧЕЙ ДАННЫХ

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

Передача таких сообщений происходит под управлением еще одного программного компонента — диспетчера передачи данных.

Диспетчер передачи данных не является частью СУБД; он представляет собой автономную систему со своими правами. Однако, поскольку очевидно, что от диспетчера передачи данных и СУБД требуется согласованная совместная работа, они иногда рассматриваются как равноправные компоненты программного продукта более высокого уровня, называемого системой базы данных и передачи данных (DataBase/Data-Communications — DB/DC). В такой системе СУБД отвечает за работу с базой данных, а диспетчер передачи данных обрабатывает все сообщения, поступающие в СУБД и из нее (точнее, поступающие в то приложение, в котором используется СУБД, и из него). Однако в этой книге мы можем рассмотреть лишь относительно небольшой объем информации об обработке сообщений (поскольку такая обширная тема вполне заслуживает самостоятельного обсуждения). В разделе 2.12 кратко рассматриваются вопросы передачи данных между отдельными системами (т.е. между отдельными компьютерами в сети передачи данных, подобной Internet), но это действительно отдельная тема.

2.10. АРХИТЕКТУРА "КЛИЕНТ/СЕРВЕР" В предыдущих разделах этой главы подробно обсуждалась так называемая архитектура ANSI/SPARC для систем баз данных. Ее упрощенная схема приведена на рис. 2.3.

В настоящем разделе мы будем изучать базы данных с несколько иной точки зрения.

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

2.5.

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

2. Клиенты — это различные приложения, которые выполняются с помощью СУБД.

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

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

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

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

Отдельно поставляемые инструментальные средства, в свою очередь, делятся на несколько самостоятельных классов.

а) Процессоры языков запросов.

б) Генераторы отчетов.

94 Часть I. Основные понятия в) Графические бизнес-подсистемы.

г) Электронные таблицы.

д) Процессоры команд на естественных языках.

е) Статистические пакеты.

ж) Средства управления копированием или средства извлечения данных, з) Генераторы приложений (включая процессоры языков четвертого поколения).

и) Другие средства разработки приложений, включая CASE-инструменты (CASE, или Computer-Aided Software Engineering — автоматизированное проектирование и создание программ) и т.д.

к) Инструментальные средства интеллектуального анализа данных и визуализации.

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

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

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

2.11. УТИЛИТЫ Утилиты — это программы, разработанные для администратора базы данных и используемые им при решении различных административных задач. Как упоминалось выше, некоторые утилиты выполняются на внешнем уровне системы и потому представляют собой не что иное, как приложения специального назначения. Одни из них могут быть созданы даже не поставщиком данной СУБД, а какими-то сторонними разработчиками. Однако другие утилиты выполняются непосредственно на внутреннем уровне (т.е. действительно являются частью сервера) и поэтому должны предоставляться поставщиками СУБД.

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

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

Инструменты выгрузки—перезагрузки, применяемые для выгрузки базы данных или ее части, создания резервных копий хранимых данных и восстановления базы данных из этих копий. (Безусловно, инструменты перезагрузки по сути идентичны упомянутым выше инструментам загрузки.) Инструменты реорганизации, применяемые для перераспределения данных в хранимой базе данных (обычно в целях повышения производительности).

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

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

Инструменты анализа, применяемые для анализа упомянутой выше статистиче ской информации.

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

2.12. РАСПРЕДЕЛЕННАЯ ОБРАБОТКА Как было указано в разделе 2.10, средства распределенной обработки позволяют соединить отдельные компьютеры в коммуникационную сеть (такую как Internet) для организации совместного решения общей задачи обработки данных на нескольких компьютерах сети. (Термин параллельная обработка используется практически в том же смысле, но в параллельных системах взаимодействующие компьютеры должны быть расположены физически достаточно близко, тогда как для распределенной системы это вовсе не обязательно, и отдельные компьютеры могут быть удалены на большие расстояния.) Взаимодействие между компьютерами осуществляется с помощью специального программного обеспечения, предназначенного для управления сетью, которое может представлять собой некоторое расширение диспетчера передачи данных (см. раздел 2.9), но чаще всего применяется в виде отдельного программного компонента.

Организация распределенной обработки может быть весьма разнообразной и осуществляется на разных уровнях. Как отмечалось в разделе 2.10, один из простейших случаев, представленный на рис. 2.6, — это случай, когда сервер СУБД запускается на одном компьютере, а клиентское приложение — на другом.

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

Главным доводом является возможность организации параллельной обработки.

В этом случае для решения общей задачи применяются сразу несколько компьютеров, поэтому работа сервера (базы данных) и клиента (приложения) осуществляется 96 Часть I. Основные понятия параллельно. В результате улучшаются такие показатели, как скорость обработки запросов в системе и производительность системы.

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

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

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

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

Клиент может получить доступ к любому количеству серверов, но лишь к одному из них в каждый момент времени (т.е. каждый запрос к базе данных может быть направлен только к одному серверу). В такой системе невозможно за один запрос получить комбинированные данные от двух и более серверов. Кроме того, пользователь в 98 Часть I. Основные понятия такой системе должен знать, на каком именно компьютере содержится конкретная Клиент может получить доступ к любому количеству серверов одновременно (т.е. за один запрос можно получить комбинированные данные с двух и более серверов).

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

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

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

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

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

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