Вы находитесь на странице: 1из 95

МИНОБРНАУКИ РОССИИ

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

C. В. Зыкин, А. Н. Полуянов

БАЗЫ ДАННЫХ

Учебное текстовое электронное издание


локального распространения

Омск
Издательство ОмГТУ
2018
————————————————————————————————
Сведения об издании: 1, 2 © ОмГТУ, 2018
ISBN 978-5-8149-2703-3
УДК 004.6
ББК 32.973
З-96
Рецензенты:
А. К. Гуц, заведующий кафедрой кибернетики ОмГУ
им. Ф. М. Достоевского, д. ф.-м. н., профессор;
М. Ю. Савельев, руководитель направления «Управление систем
операционной деятельности» ООО «Автоматика-сервис»», к. т. н.

Зыкин, С. В.
З-96 Базы данных : учеб. пособие / С. В. Зыкина, А. Н. Полуянов ; Минобр-
науки России, ОмГТУ. – Омск : Изд-во ОмГТУ, 2018.
ISBN 978-5-8149-2703-3
Приведен теоретический материал по технологиям построения баз
данных. На основе требований к базам данных предложены эвристиче-
ские и формальные методы построения схем баз данных. Проанализиро-
ваны проблемы, возникающие на практике в процессе применения рас-
смотренных методов. Представлен обзор наиболее популярных методов
доступа, реализуемых в современных системах управления базами дан-
ных и имеющих перспективы использования в будущем.
Учебное пособие предназначено для обучающихся по направлениям
02.03.02 «Фундаментальная информатика и информационные техноло-
гии», 02.03.03 «Математическое обеспечение и администрирование ин-
формационных систем», 09.03.01 «Информатика и вычислительная тех-
ника», 09.03.02 «Информационные системы и технологии», 09.03.04
«Программная инженерия», 09.03.03 «Прикладная информатика».
УДК 004.6
ББК 32.973

Рекомендовано редакционно-издательским советом


Омского государственного технического университета

ISBN 978-5-8149-2703-3 © ОмГТУ, 2018

2
1 электронный оптический диск

Оригинал-макет издания выполнен в Microsoft Office Word 2007/2010


с использованием возможностей Adobe Acrobat Reader.

Минимальные системные требования:


• процессор Intel Pentium 1,3 ГГц и выше;
• оперативная память 256 Мб и более;
• свободное место на жестком диске 260 Мб и более;
• операционная система Microsoft Windows XP/Vista/7/10;
• разрешение экрана 1024×768 и выше;
• акустическая система не требуется;
• дополнительные программные средства Adobe Acrobat Reader 5.0 и выше.

Редактор М. А. Болдырева
Компьютерная верстка Е. В. Беспаловой

Сводный темплан 2018 г.


Подписано к использованию ##.##.18.
Объем 0,94 Мб.
—————————————————
Издательство ОмГТУ.
644050, г. Омск, пр. Мира, 11; т. 23-02-12
Эл. почта: info@omgtu.ru

3
Введение

Целью решения информационных задач является обеспечение поль-


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

4
ные необходимы только для работы одной или нескольких связанных
между собой программ. В этом случае достаточно использовать один из
методов доступа, соответствующий способу обработки данных в про-
граммах.
Если данные имеют самостоятельную ценность (большой жизненный
цикл данных, использование их в различных приложениях и т. д.), то по-
является необходимость использования СУБД. На выбор СУБД оказыва-
ют влияние следующие факторы: 1) наличие или возможность приобрете-
ния ЭВМ и операционной системы, на которую ориентирована СУБД;
2) соответствие типа модели данных, который выбран при проектирова-
нии, и типа СУБД; 3) наличие функциональных возможностей в СУБД,
необходимых для реализации приложений; 4) обеспечение многопользо-
вательского режима доступа к данным; 5) соответствие стандарту языков
описания и манипулирования данными и т. д. Наиболее важным началь-
ным этапом является построение схемы базы данных. Правильно постро-
енная схема обеспечивает устойчивость всей системы к различным изме-
нениям в прикладной области в процессе эксплуатации БД, что суще-
ственно сокращает затраты на сопровождение. Экономия достигается за
счет отсутствия необходимости переписывания старого прикладного про-
граммного обеспечения и локальности необходимых преобразований фи-
зической организации данных.
Отправной точкой для проектирования схемы БД является изучение
документооборота в заданной прикладной области. Самая распространен-
ная ошибка на этом этапе – копирование структуры представленных до-
кументов в схему БД. Любая действующая система подвержена изменени-
ям. За этими изменениями потребуется изменение схемы БД и, как след-
ствие, переписывание прикладных программ. Такие системы «умирают»
почти сразу после опытной эксплуатации из-за необходимости переделы-
вания почти всего, что уже сделано. С другой стороны, большинство пра-
вильно спроектированных систем до сих пор находятся в эксплуатации,
несмотря на устаревшее программное обеспечение, на котором они были
сделаны.

5
1. Основные определения и требования к базам данных

1.1. Определение базы данных

Определение 1.1. Базой данных (БД) называется совокупность спе-


циальным образом организованных данных, которые:
1) подлежат долговременному хранению на внешних запоминающих
устройствах ЭВМ;
2) содержат информацию о сравнительно небольшом (фиксирован-
ном) количестве классов объектов, однако количество экземпляров в каж-
дом классе может быть огромным; все классы объектов относятся к одной
прикладной области;
3) используются в одном или множестве приложений (задач).
Комментарии к определению.
В первом пункте определения говорится о месте и способе хранения
данных. Данные должны храниться на компьютере, но не должны исче-
зать вместе с отключением питания. Жизненный цикл данных должен
быть значительно больше, чем жизненный цикл программного обеспече-
ния, которое с ним работает.
Второй пункт – специфическое требование к БД, которое отделяет БД
от других информационных систем. Альтернативная ситуация наблюдает-
ся для информационно-поисковых систем (ИПС) – огромное количество
классов объектов, в каждом из которых небольшое число экземпляров.
Примерами таких ИПС являются структура данных и программное обес-
печение технологии WWW. Принадлежность всех объектов к одной при-
кладной области гарантируется свойствами проекта БД, в том числе свой-
ством соединения без потерь информации. Принципиальное отличие БД
от баз знаний и экспертных систем – пассивность данных. Данные в БД не
должны содержать сведения о месте и способе их использования (принцип
независимости данных), тогда как знания за счет своего содержимого ак-
тивно влияют на ход выполнения запроса.
Третий пункт определения можно перефразировать следующим обра-
зом: сколько бы ни было приложений в данной прикладной области, все

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

1.2. Категории баз данных

В БД имеется два различных уровня описания и представления дан-


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

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

Сотрудники

№ сотруд- ФИО сотруд- Дата рожде- Должность


ника ника ния сотрудника сотрудника
204 Иванов И. И. 21.04.1981 г. инженер
420 Петров П. П. 01.10.1979 г. программист
513 Сидоров С. С. 05.09.1995 г. кассир
… … … …

схема отношения – описание элементов данных, на которых опреде-


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

Пример. Пусть в БД хранится 3 класса объектов.


Схема БД (логический уровень):

8
На логическом уровне рассматриваются три отношения, соответству-
ющие трем классам объектов: «Сотрудники», «Оборудование» и «Рабо-
чее место».
На схеме подчеркнуты атрибуты – первичные ключи отношений:
в отношении не может быть двух записей с совпадающими значениями
атрибутов первичного ключа. Первичный ключ называется ограничением
сущности. Его наличие гарантирует однозначную идентификацию записи
в отношении экземпляра объекта в БД.
Связи между отношениями задают ссылочные ограничения целостно-
сти и называются внешними ключами. Количество стрелок на концах свя-
зи характеризует тип связи. На схеме изображены две связи типа «один ко
многим», означающие, что одной записи первого отношения соответ-
ствуют несколько записей (возможно 0) второго отношения и каждой за-
писи второго отношения соответствует точно одна запись первого отно-
шения. На схеме изображены типизированные связи: соответствие запи-
сей устанавливается по совпадению значений одноименных атрибутов.
Указанные ограничения задают следующие «бизнес-правила»:
1) не может быть двух сотрудников с одним и тем же номером;
2) не может один и тот же номер соответствовать различному обору-
дованию;
3) не может одно и то же оборудование дважды быть закрепленным за
одним и тем же сотрудником.
Однако за одним сотрудником можно закрепить несколько экземпля-
ров (различного) оборудования, и одно оборудование может быть закреп-
лено за несколькими (различными) сотрудниками.
Дополнительные ограничения обусловлены требованием ссылочной
целостности данных:
4) запись в отношение «Рабочее место» нельзя дополнить, если нет
соответствующего «№ сотрудника» либо «№ оборудования»;
5) запись из отношения «Сотрудники» нельзя удалить, если с ней свя-
зана запись из отношения «Рабочее место»;
6) то же самое справедливо и для отношения «Оборудование». Запись
из отношения «Оборудование» нельзя удалить, если с ней связана запись
отношения «Рабочее место».

9
На физическом уровне эта схема реализуется в виде набора файлов:

Сотрудники

204 Иванов И. И. 21.04.1981 г. инженер

Оборудование

213402 Стол письменный 31.12.2012 г.

Рабочее место

8-й корпус
204 213402
ОмГТУ, каб. 205

Ограничения целостности обычно реализуются в СУБД с помощью


индексных файлов. В данном примере должны быть созданы индексные
файлы по следующим полям:
1) по «№ сотрудника» в файле «Сотрудники»;
2) по «№ оборудования» в файле «Оборудование»;
3) по «№ сотрудника»+«№ оборудования» (сцепленный ключ) в фай-
ле «Рабочее место».
Для поддержания ссылочной целостности также создаются индексные
файлы. Состав и структура индексных файлов различны для различных
СУБД, даже если реализуются одни и те же методы доступа.

1.3. Требования к базе данных

1.3.1. Неизбыточность и непротиворечивость данных


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

10
При этом если в одном приложении данные были изменены, а в другом
нет, то возникает противоречивость данных, т. е. противоречивость –
следствие избыточности.
Пример. Если отдел кадров и бухгалтерия работают с собственными
наборами файлов, то появляется избыточность, так как сведения о сотруд-
никах в этих файлах дублируются. Следствием избыточности может быть
ситуация, когда сотрудник в отделе кадров уволен, а бухгалтерия продол-
жает начислять ему зарплату.
Замечание. В базах данных допускается управляемая избыточность,
когда за непротиворечивостью данных следит СУБД: дублирование зна-
чений ключевых атрибутов в индексных файлах, дублирование данных на
нескольких серверах и т. д.

1.3.2. Защита от программных и аппаратных сбоев


Защита от программных и аппаратных сбоев должна обеспечиваться
средствами СУБД. Сбои бывают двух видов.
1. Логический сбой. Пусть оператор выполняет попытку дополнения
информации об объекте, которая уже содержится в базе. СУБД по значе-
нию ключевых полей должна распознать данную ситуацию и предотвра-
тить операцию дополнения. От проектировщиков требуется определить
первичный ключ и установить его средствами СУБД. Данная ситуация
называется ошибкой I рода. Рассмотрим другую ситуацию. Пусть опера-
тор выполняет удаление информации об объекте, на которую ссылается
другой объект. СУБД должна предотвратить операцию удаления. От про-
ектировщика требуется при разработке схемы БД задать ограничения ссы-
лочной целостности на данные (внешние ключи). Данная ситуация назы-
вается ошибкой II рода.
2. Физический сбой. Допустим, во время работы СУБД возникает
аварийная ситуация, приводящая к аварийному завершению работы
СУБД. Причиной может быть ошибка СУБД или операционной системы
(ОС), отключение электропитания и т. д. При этом СУБД может не успеть
полностью выполнить операции по преобразованию структуры БД,
и структура БД может быть нарушена.

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

1.3.3. Мобильность прикладного программного обеспечения


Определение 1.2. Прикладной программой в БД называется про-
грамма, реализующая какую-либо единичную функцию пользователя
и обеспечиваемая данными из БД посредством СУБД.
Например, расчет заработной платы сотрудников, расчет оптимально-
го плана выпуска продукции и т. п.
Определение 1.3. Прикладная программа называется мобильной, ес-
ли ее исходный код не зависит от операционной системы и аппаратуры.
Таким свойством обычно обладают универсальные языки программи-
рования: C, Java и т. д.
Определение 1.4. Прикладная программа в базах данных должна
быть мобильной и не должна зависеть от места и способа хранения
данных.
Замечание. Сформулированное в определении 1.4 свойство носит
название принципа независимости данных.

12
Для реализации принципа независимости данных рабочая группа
CODASYL (международная рабочая группа по вопросам БД) рекомендо-
вала к реализации трехуровневую модель организации и представления
информации.
Трехуровневая модель
1. Физическое описание и представление. На этом уровне содержит-
ся информация о месте и способе хранения данных, структура основных
файлов данных, характеристика области переполнения и отведенного сво-
бодного пространства, описание индексных файлов и т. д., то есть содер-
жанием физического уровня является информация, достаточная для пре-
образования значения поискового ключа в физический адрес(а) искомых
записей.
2. Глобальное логическое описание. Содержанием этого уровня явля-
ется схема БД: отношения, ограничения целостности, связи. Схема БД не
должна зависеть от места и способа хранения данных, равно как и от спо-
соба использования данных. Данный уровень является основой реализа-
ции принципа независимости, решает проблемы неизбыточности и непро-
тиворечивости данных.
3. Внешние схемы. Этот уровень ориентирован на прикладную про-
грамму, приложение, то есть содержит описание о структуре и составе ло-
гических записей в том виде, в котором они используются в прикладной
программе. Внешняя схема является источником информации для преоб-
разования данных при передаче их из файлов БД в прикладную программу
и обратно. Кроме того, внешние схемы содержат пароль доступа к секрет-
ным данным.
Замечание. При эксплуатации БД наиболее частым изменениям под-
вержены 1-й и 3-й уровни. Если текущие изменения в БД из-за нарушения
принципа независимости приводят к необходимости переписывания всего
прикладного ПО, то эксплуатация системы экономически не целесообраз-
на. Задача второго уровня – отразить фундаментальные свойства приклад-
ной области в виде описания данных, которое, с одной стороны, не зави-
сит от места и способа хранения данных, а с другой – не зависит от спосо-
ба их использования.

13
Поэтому для проектирования второго уровня используются фунда-
ментальные свойства данных в прикладной области. К фундаментальным
свойствам относятся функциональные зависимости, многозначные зави-
симости, зависимости соединений и зависимости включения. Построенная
на основе этих зависимостей схема БД должна удовлетворять одной из
финальных нормальных форм, обладать свойством соединения без потери
информации и сохранять все существующие зависимости.
Второй уровень является «фундаментом» любой информационной си-
стемы, основанной на БД.
В табл. 1.1 приведены основные текущие операции с БД и показано
влияние проводимых операций на прикладную область, глобальное логи-
ческое и физическое описание.
Таблица 1.1
Влияние операций с БД на прикладную область
Не изменяется Не изменяется
Не изменяется
прикладное ПО глобальное
Вид изменения физическое
(кроме одной логическое
описание
программы) описание
Дополняется новая про-
грамма, использующая но- + – –
вые типы данных
Дополняется новая про-
грамма, использующая + + +
старые типы данных
Дополняется новая запись
в БД (изменение представ- + + –
ления, а не описания)
Объединяются две разно-
+ – –
типные БД в одну
Объединяются две одно-
+ + –
типные БД в одну
Заменяется операционная
+ + –
система
Изменяется аппаратный
+ + –
состав сервера БД

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

1.3.4. Защита от несанкционированного доступа (секретность


данных)
Защита от несанкционированного доступа к данным является предме-
том отдельного изучения в различных учебных дисциплинах. В техноло-
гиях БД реализуются следующие уровни защиты:
1) пароль при входе в систему. То есть внешние схемы снабжены па-
ролем доступа к секретным данным. Это самый простой способ защиты
данных, который предназначен, прежде всего, для защиты от неквалифи-
цированного пользователя;
2) защита файловой системы средствами операционной системы. Это
средство становится актуальным, если злоумышленник имеет возмож-
ность напрямую обратиться к файлам БД, минуя СУБД;
3) шифрование данных на физическом уровне. Наиболее надежный
способ закрытия содержимого БД. Если злоумышленнику удалось обойти
средства защиты операционной системы, то он может исказить содержи-
мое файлов, в том числе удалить их, но содержимое ему будет недоступ-
но. Дешифровка может потребовать сотни лет с использованием супер-
компьютеров. В этом случае становится актуальным защищенный пароль
на входе, так как в некоторых системах он используется в качестве ключа
шифрования.

1.4. Представление информации

Рассмотрим тезисы, требующие некоторого осмысления.


Материальна ли информация? А. П. Ершов утверждает, что аргумен-
тов за ее нематериальность много, но за материальность еще больше. Ин-
формация не существует без материальных носителей. Она также не су-
ществует без восприятия себя, то есть осмысления. В этих условиях более
аргументирована точка зрения, что информация не является ни матери-

15
альной, ни идеальной, – она, фактически, третья составляющая мирозда-
ния, мост между материей и сознанием (один из трёх китов, на которых
держится мироздание: материя, сознание, информация).
Окружающая действительность воспринимается как множество объ-
ектов и отношений между ними. Объекты бывают материальными и нема-
териальными; отношения чаще всего нематериальны.
Отношения между объектами сами могут быть интерпретированы как
объекты. Таким образом, информация сводится к объектам, материальным
и нематериальным.
Различие между объектами достигается за счет различия их свойств.
Набор свойств объектов зависит от прикладной области, то есть
от точки зрения. С одной точки зрения объекты могут быть неразличимы,
с другой – резко различаться.
Определение 1.5. Существенные для данной прикладной области
свойства объектов называются атрибутами.

1.4.1. Плоские файлы


Определение 1.6. Два объекта прикладной области являются одно-
типными (принадлежат одному и тому же классу), если они характери-
зуются одинаковым набором атрибутов (имеют одинаковую семантику).
Пример. Описание класса «Студенты».
Номер студенческого
ФИО студента Номер группы Факультет
билета
3154633 Иванов И. И. М-003 Математический
3154639 Петров П. П. Ф-002 Физический

Замечание. В примере информация о классе «Студент» представлена


в виде плоского файла.
Определение 1.7. Табличное представление информации называется
плоским файлом, если выполнены следующие условия:
1) таблица содержит сведения об одном классе объектов;
2) таблица имеет заголовок в виде совокупности атрибутов данного
класса;

16
3) элементы столбца таблицы однородны, то есть отражают одну и ту
же характеристику (свойство объекта). Содержимое столбца зовется
доменом – областью определения атрибута.
Замечание. В примере рассмотрен класс материальных объектов, од-
нако атрибуты его нематериальны.
Пример. Плоский файл для класса объектов «Супруги».
ФИО мужа ФИО жены
Иванов И. И. Иванова М. И.
Петров П. П. Петрова О. И.

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


(отношение супружества – нематериальный объект), при этом атрибуты
материальны. Разница между примерами обусловлена тем, что класс
«Студенты» описывает объекты, а класс «Супруги» описывает отношения
между объектами.
Замечание. Плоский файл является описанием и представлением ин-
формации. Описание представлено именем плоского файла и заголовком
таблицы, представление (или реализация) – содержимым таблицы.

1.4.2. Ключи
Определение 1.8. Для выбранного класса объектов атрибут является
поисковым ключом, если одно его значение идентифицирует от 0 до не-
скольких объектов данного класса.
В приведенном ранее примере для класса «Студенты» любой из атри-
бутов является поисковым ключом.
Определение 1.9. Для выбранного класса объектов атрибут является
первичным ключом, если одно его значение идентифицирует один объект
данного класса.
Для класса «Студенты» первичным ключом является номер студенче-
ского билета.
Определение 1.10. Поисковый ключ в выбранном классе объектов
называется сцепленным, если ключ состоит более чем из одного атрибута.
Для обозначения сцепленного ключа используется оператор конкате-
нации '+'.

17
В примере с классом «Студенты» сцепленным ключом может высту-
пать «ФИО студента» + «Факультет».
Замечание. Для реализации поисковых и первичных ключей на фи-
зическом уровне используются индексные файлы. Ключевые атрибуты
(первичный и поисковый) – основа для обеспечения целостности данных
в СУБД.

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

Определение 1.11. СУБД – программа, работающая под управлением


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

18
5) СУБД передает последовательность команд операционной системе
на чтение блоков данных и передает ей управление;
6) операционная система считывает блоки данных и записывает их
в системные буфера. Затем передается управление СУБД;
7) СУБД преобразует данные в системных буферах в соответствии
с описанием внешних схем, служебная информация обрабатывается в со-
ответствии с физическим описанием;
8) после завершения формирования данных по запросу в системных
буферах СУБД передает их в рабочую область прикладной программы
и передает ей управление.
Схема функционирования СУБД:

Прикладная Прикладная Внешние


Прикладной программа А программа Б схемы
программист

СУБД
Администратор
Системные буферы Глобальное
БД
логическое
описание

Операционная
система

Физическое
описание
Системный БД 1 БД 2
данных
программист

Управляющие воздействия

Потоки данных

19
Замечание. Шаги 5–7 выполняются циклически. Чем лучше СУБД
оптимизирует запрос, тем меньше будет циклов.
Последовательность действий при записи в БД аналогична, только
поток данных идет в обратном направлении.

1.6. Языковые средства для работы с базами данных

Для формирования запросов к БД и написания прикладных программ


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

20
БД; необходима разработка расширенного транслятора, понимающего се-
мантику новых операторов (СУБД ADABAS для IBM-360/370);
в) внутри текста программы оформляются независимые блоки на спе-
циализированном языке, программа должна быть предварительно обрабо-
тана специализированным транслятором, который специализированные
блоки преобразует в конструкции классического языка; далее текст обра-
батывается традиционным транслятором (ЯОД СУБД VISTA).
2. Функции ЯОД и ЯМД реализуются средствами СУБД. Имеется
встроенный язык, реализующий не только ЯОД и ЯМД, но и классические
операции традиционных языков и операторы пользовательского интер-
фейса (СУБД dBase, Clipper, Clarion, FoxPro и т. д.).
3. Разработка независимых ЯОД и ЯМД. Такой подход наиболее пол-
но реализует принцип независимости данных. Это основное направление,
которое поддерживается стандартом SQL.

21
2. Проектирование глобального логического описания БД

2.1. Элементы данных и связи

Определение 2.1. Элементом данных называется неизменяемое ато-


марное данное с определенным типом и семантически однозначным
наименованием.
Замечание. Данное является изменяемым, если в системе (приклад-
ной области) отсутствует событие, приводящее к необходимости его из-
менения. Данное является атомарным, если дальнейшая его детализация
лежит за рамками прикладной области. Семантически однозначное наи-
менование без какого-либо контекста должно определять множество зна-
чений, которые может принимать элемент данных, причем типы этих зна-
чений должны совпадать.
Примеры ошибок в определении элемента данных:
1) «Цех» – этот элемент данных может содержать в себе другие эле-
менты (персонал цеха, выпускаемая продукция, оборудование и др.), то
есть отсутствует семантическая однозначная интерпретация этого элемен-
та: невозможно определить значения, которые может принимать этот эле-
мент, и их тип. Наверное, имелось в виду название цеха или номер цеха;
2) «Средняя зарплата в отделе» – этот элемент не является первичной
информацией, а может быть вычислен, следовательно в базе данных надо
хранить сведения об элементарных выплатах каждому сотруднику от-
дельно, а среднее, минимальное, максимальное значения вычислять в при-
кладной программе;
3) «Возраст сотрудника» – этот элемент имеет изменяемое значение
(в системе отсутствует событие, приводящее к необходимости изменения
этого значения), нужно использовать элемент «Дата рождения», а возраст
вычислять в приложении. Элемент данных «Номер курса студента» не яв-
ляется изменяемым, поскольку для изменения его значения в системе
должно произойти событие: приказ по деканату.

22
Определение 2.2. В БД допускается комплексирование элемента дан-
ных из нескольких значений, если их количество фиксировано и сами зна-
чения существенно зависят друг от друга. Такой элемент данных зовется
агрегатом.
В БД наиболее часто используется агрегат дата/время.
Определение 2.3. Установленная связь на схеме между элементами
данных (или объектами) отражает количественное отношение значений
элементов данных (объектов) друг с другом и не имеет содержания.
Типы связей:
1) 1:1 – «один к одному». Одному значению первого элемента данных
соответствует не более одного значения второго элемента данных.

Номер читательского
Номер зачетной книжки
билета

2) М:1 – «многие к одному». Множеству значений первого элемента


данных соответствует не более одного значения второго элемента данных.

Табельный номер
Должность сотрудника
сотрудника

3) 1:М – «один ко многим». Одному значению первого элемента дан-


ных соответствует множество значений второго элемента данных, где
М∈{0,1,2...}.

Табельный номер
Должность сотрудника
сотрудника

4) М:М – «многие ко многим». Множеству значений первого элемен-


та данных соответствует множество значений второго элемента данных.

Номер группы Дата рождения студента

23
Примечание. Связи на схеме изображаются в виде дуги между свя-
зываемыми элементами данных. Связи первого и второго типа изобража-
ются в виде одиночной стрелки возле второго элемента данных, третьего
и четвертого типа – сдвоенной стрелки. Если связь устанавливается в обе
стороны, то соответствующие стрелки изображаются на одной дуге.
Определение 2.4. Простой путь – направление по одиночным стрелкам.
Определение 2.5. Связи на схеме называются избыточными, если от
одного элемента данных ко второму идет несколько простых путей.
Правило удаления: удаляются все короткие пути (то есть остается
один наиболее длинный путь).
Пример.

А B C

Определение 2.6. Совокупность установленных связей и элементов


данных, в которой удалена семантика и избыточные связи, называется
овал-диаграммой.
Овал-диаграмма – основа эвристического проектирования схемы БД.
Замечание. Установленные на схеме избыточные связи увеличивают
сложность диаграммы. Для дальнейшего проектирования избыточные свя-
зи удаляются.
Определение 2.7. Правило склейки записей: если между элементами
данных A и B установлена связь типа 1 или 2, то элемент данных B присо-
единяется к элементу данных A, образуя логическую запись (тип записи).
Элемент данных A в этом типе записи будет ключевым.

А B А B

24
Замечание. Если существует третий элемент C (связь типа 1 или 2
от A), то связь также удаляется, а элемент присоединяется к уже сформи-
рованной записи. Если к элементу данных C установлена связь типа 1
или 2 от элемента B, то элемент данных C присоединяется к элементу
данных B, образуя новую логическую запись. Элемент данных B в этом
типе записи будет ключевым.

2.2. Классификация моделей данных

В БД рассматриваются три группы классических моделей данных:


1) сетевые;
2) иерархические (древовидные);
3) реляционная.

Сетевая

Иерархическая

Реляционная

После применения правила склейки в общем случае будет получена


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

2.2.1. Иерархические модели данных


Определение 2.8. Дерево – множество узлов, среди которых выделен
«корень», а остальные узлы находятся в попарно непересекающихся мно-
жествах, каждое из которых – дерево.

25
1

2
3

5 6

7 8 9

Вершина 1 – корень, она находится на первом уровне.


Вершины 4, 5, 6, 7, 8, 9 – листья.
Вершины 2, 3, 4 относятся ко второму уровню.
Вершины 5, 6, 7, 8, 9 – третий уровень.
(1, 2, 5), (1, 3, 7) – максимальные пути.
(1, 4) – минимальный путь.
Узел 2 – левый сосед узла 3.
Узел 4 – правый сосед узла 3.
Узел 7 – левый сосед узла 8, но сам не имеет левого соседа.
Узел 9 – правый сосед узла 8, но сам не имеет правого соседа.
Замечание. В иерархических схемах БД изображения стрелок на свя-
зях опускаются, поскольку подразумевается 1:М от предка к потомку.
Определение 2.9. Дерево называется сбалансированным, если длины
всех путей от корня к внешним вершинам равны между собой. Дерево
называется почти сбалансированным, если длины всевозможных путей
от корня к внешним вершинам отличаются не более чем на единицу.
Пример.

Сбалансированное Почти сбалансированное Несбалансированное


дерево дерево дерево

26
Определение 2.10. Дерево называется бинарным, если любой его
узел имеет не более двух потомков.
Замечание. Очень малое количество прикладных областей может
быть описано с помощью сбалансированных и бинарных деревьев.
Например: родословная собаки – сбалансированное бинарное дерево,
а потомки собаки – несбалансированное и не бинарное дерево. Особое
значение сбалансированные и бинарные деревья имеют для представления
информации на физическом уровне (организация индексных файлов).
Зависимость данных от структуры. Если в структурированном
представлении данных для получения каких-либо сведений требуется
воспользоваться связями, то такое представление называется зависимым
от структуры.
Пример.

Отделы
Наименование
Номер отдела Адрес отдела
отдела

Работы
Наименование
Номер работы
работы

Служащие

Номер служащего ФИО служащего

Допустим, имеется экземпляр записи из отношения «Служащие».


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

27
Отделы
Наименование
Номер отдела Адрес отдела
отдела

Работы
Наименование
Номер работы Номер отдела
работы

Служащие

Номер служащего ФИО служащего Номер отдела

Теперь по экземпляру записи из отношения «Служащие» можно ска-


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

2.2.2. Сетевые модели данных


Определение 2.11. Схему данных, в которой потомок может иметь
более одного предка, называют сетевой.
Свойство. Если схема данных содержит связь типа М:М, то она явля-
ется сетевой.
Пример.

Поставщики Потребители

Изделия

В данной схеме один поставщик поставляет множество видов изде-


лий, однако отдельный вид изделия поставляется только одним поставщи-

28
ком. Один потребитель покупает несколько видов изделий, но отдельный
вид изделия покупается только одним потребителем.
Между поставщиками и потребителями неявно установлена связь
М:М.
Определение 2.12. Если на схеме присутствует связь типа М:М, то
модель называется сложной сетевой, иначе – простой сетевой.
Для поддержания связи М:М на уровне СУБД необходимы множе-
ственные перекрестные ссылки, которые противоречат многим принципам
построения баз данных, в том числе локальности модифицирующих воз-
действий. В настоящее время не существует СУБД, поддерживающих
сложную сетевую модель.
Правило преобразования сложной сетевой схемы к простой сете-
вой. Допустим, что схема данных содержит две схемы отношений (типов
записей) со связью М:М. A и B – ключи этих записей. Создается новое от-
ношение с ключом A+B. Со схемы удаляется связь типа М:М, а от нового
отношения устанавливается связь М:1 к исходным отношениям.

A … … …

B … … …

По правилу
преобразования

A … … … B … … …

A B

29
Замечание. Получена простая сетевая схема за счет введения мини-
мальной избыточности. Минимальная избыточность гарантируется нали-
чием только ключевых полей в новом типе записи.
Определение 2.13. Элемент данных на схеме называется общим дан-
ным, если он по правилу склеивания записей может быть присоединен
к нескольким различным типам записей.
Правило преобразования. Формируется новый тип записи, содер-
жащий общий элемент данных и ключевые поля записей, которыми иден-
тифицируется общий элемент (может быть присоединен по правилу
склейки).
Замечание. Семантика общего данного при этом видоизменяется
(детализируется).
Пример. Рассмотрим схему данных, приведенную на рис. 2.1.

Поставщики
Номер Наименование
Адрес поставщика
поставщика поставщика
Общее данное

Количество
изделий
Изделия на складе
Наименование
Номер изделия
изделия

По правилу
преобразования
Поставщики Изделия на складе
Номер Наименование Наименование
Адрес поставщика Номер изделия
поставщика поставщика изделия

Поставка
Номер Количество
Номер изделия
поставщика изделий

Рис. 2.1. Пример схемы данных

30
До преобразования «Количество изделий», с одной стороны, означало
количество не важно каких изделий, поставляемых одним поставщиком,
с другой – количество изделий одного вида, поставленных не важно каким
поставщиком. После преобразования: количество изделий одного вида,
поставленных одним поставщиком.
Определение 2.14. Элемент данных, который по правилу склейки не
может быть присоединен ни к одному из существующих типов записей
(к нему приходят только сдвоенные стрелки), называется данным пересе-
чения, если существует совокупность ключевых полей из других типов
записей, однозначно определяющих значение этого элемента данных.
Правило преобразования. Формируется новый тип записи, содер-
жащий ключевые поля из других типов записей, однозначно определяю-
щих значение данного пересечения, и к новому типу записи дополняется
само данное пересечения.
Пример. Рассмотрим схему данных, приведенную на рис. 2.2.

Поставщики
Номер Наименование
Адрес поставщика
поставщика поставщика
Данное пересечения

Цена изделия
Изделия на складе
Наименование
Номер изделия
изделия

По правилу
преобразования
Поставщики Изделия на складе
Номер Наименование Наименование
Адрес поставщика Номер изделия
поставщика поставщика изделия

Поставка
Номер Количество
Номер изделия Цена изделия
поставщика изделий

Рис. 2.2. Пример схемы данных

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

Поставщики Изделия на складе


Номер Наименование Наименование
Адрес поставщика Номер изделия
поставщика поставщика изделия

Цена реализованных
изделий

Поставка

Номер Количество
Номер изделия Цена изделия
поставщика изделий

В примере цена реализованных изделий зависит от потребителя


(включает в себя стоимость доставки), поэтому между «номером изделия»
и «ценой реализованных изделий» установлена связь 1:M.
Правило преобразования сетевой модели к иерархическому виду.
Если какой-либо тип записей имеет более одного предка (установлено не-
сколько типов входящих связей 1:М), тогда каждому предку приписыва-
ется свой дублированный экземпляр потомка, причем все дубли, кроме
одного, содержат только ключевые атрибуты.

32
A B

C D

По правилу
преобразования

A B

C D C D

После преобразования схема распадается на несколько независимых


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

2.2.3. Реляционные модели данных


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

33
3) каждый столбец таблицы имеет уникальное имя во всей совокуп-
ности таблиц. Имена столбцов (элементов данных) в различных таблицах
должны совпадать, если это одна и та же характеристика;
4) каждая таблица в описании данных должна иметь уникальное имя;
5) каждый элемент таблицы должен быть элементом данных либо аг-
регатом данных;
6) связи между таблицами на схеме БД устанавливаются по одно-
именным атрибутам данных (типизированные связи) и указывают на ко-
личество сопоставленных записей в связанных таблицах.
Таблицу, удовлетворяющую перечисленным требованиям, далее бу-
дем называть отношением (relation). Все записи (кортежи) в таблице бу-
дем называть реализацией отношения. Количество записей в таблице
называется мощностью отношения или кардинальным числом. Отношение
из двух столбцов является бинарным, трех – тернарным, n столбцов –
n-арным. Множество допустимых значений в столбце отношения (элемен-
та данных, атрибута) называется доменом.
Замечание. В различных таблицах один и тот же атрибут может
иметь разные домены.
Определение 2.17. Каждая таблица, удовлетворяющая перечислен-
ным требованиям, называется отношением, находящимся в первой нор-
мальной форме (1НФ).

2.2.4. Преобразование иерархических моделей данных к реляци-


онному виду
В основу преобразования положено удаление зависимости данных от
структуры.
Правило преобразования: если между 1-м и 2-м типом записи уста-
новлена связь 1:M, то ключевой атрибут 1-го типа записи добавляется ко
второму типу записи, где он не будет ключевым.

34
Пример.
Факультеты
Наименование
Номер факультета
факультета

Кафедры Студенты
Наименование
Номер кафедры Номер студента ФИО студента
кафедры

Реляционное представление будет следующим:


Факультеты (номер факультета, наименование факультета)
Кафедры (номер кафедры, наименование кафедры, номер факультета)
Студенты (номер студента, ФИО студента, номер факультета)
Результат преобразования показывает, что реляционная модель не яв-
ляется структурированной (в отличие от сетевой и иерархической моде-
лей), наличие в ней связей («стрелок») не обязательно.
Замечание. Использование нумерации в качестве ключевых атрибу-
тов не является обязательным. Так, наименование факультета вполне мо-
жет быть ключевым атрибутом, однако значение ключа многократно дуб-
лируется в потомках, поэтому желательно использовать наиболее корот-
кий ключ.
Кроме того, в случае переименования факультета пришлось бы об-
новлять данное поле во всех потомках, в то время как при использовании
в качестве ключа номера факультета обновлению подлежит только поле
«Наименование факультета» в отношении «Факультеты».
Определение 2.18. Если в структуре одного типа записи имеется со-
вокупность атрибутов с множеством значений, то такая совокупность
называется циклической или повторяющейся группой.
Такой тип записей имеется, например, в СУБД ADABAS.
Правило преобразования структуры записи с повторяющейся
группой:
Исходный тип записи разбивается на два типа записей.
Тип 1 – исходный тип без циклической группы.
Тип 2 – циклическая группа и ключ исходной записи с ключом повто-
ряющейся группы.

35
A *** A1 …

По правилу
преобразования

(A, ***)
(A+A1, …)

Пример.

Номер Наименование Количество


Номер накладной Номер изделия
поставщика изделия изделий

По правилу
преобразования

Накладная (номер накладной, номер поставщика)


Поставка (номер накладной, номер изделия, наименование изделия,
количество изделий)

2.2.5. Преобразование сетевой модели данных к реляционному


виду
Правило преобразования: если между 1-м и 2-м типом записей
установлена связь 1:M, то преобразование выполняется аналогично пре-
образованию иерархической модели. Если между двумя типами записей
установлена связь M:M, то формируется новый тип записи, содержащий
только ключевые поля исходных типов записей и, возможно, общие дан-
ные и данные пересечения.

36
Пример.
Поставщики Потребители
Номер Наименование Адрес Номер Наименование Адрес
поставщика поставщика поставщика потребителя потребителя потребителя

Изделия на складе
Наименование
Номер изделия
изделия

По правилу
преобразования

Потребители (номер потребителя, наименование потребителя, адрес по-


требителя)
Поставщики (номер поставщика, наименование поставщика, адрес по-
ставщика)
Изделия на складе (номер изделия, наименование изделия, номер потре-
бителя)
Поставка (номер поставщика, номер изделия)
Замечание. Если в схему добавить общие данные – «количество по-
ставленных деталей» и данные пересечения – «цена изделия», то они
должны быть добавлены во вновь введенное отношение «Поставка».

2.2.6. Дополнения к реляционной схеме


Вернемся к схеме из рассмотренного ранее примера.

Факультеты
Наименование
Номер факультета
факультета

Кафедры Студенты
Наименование
Номер кафедры Номер студента ФИО студента
кафедры

Факультеты (номер факультета, наименование факультета)


Кафедры (номер кафедры, наименование кафедры, номер факультета)
Студенты (номер студента, ФИО студента, номер факультета)

37
Допустим, что в схеме данных необходимо отобразить специализа-
цию студентов на кафедре.
Для этого в структурной модели устанавливается связь 1:M от отно-
шения «Кафедры» к отношению «Студенты».
При этом модель данных перестает быть иерархической, следова-
тельно будут некорректно выполняться навигационные операторы в при-
кладном ПО. Например, если текущим является отношение «Студенты»,
то оператор «получить предка» будет выполняться с ошибкой, так как
у этого отношения теперь два предка. Следовательно, необходимо преоб-
разовать схему и внести изменения в соответствующие прикладные про-
граммы.
Для реляционной модели в соответствии с правилом преобразования
в отношение «Студенты» будет добавлен атрибут «номер кафедры». Сде-
лаем это поле необязательным в отношении, тогда все прикладные про-
граммы, работающие со старой схемой, продолжат корректно работать.
Вывод: реляционная модель данных наиболее полно реализует прин-
цип независимости данных.

2.3. Операции реляционной алгебры

Реляционная алгебра является теоретической основой для всех совре-


менных языков запросов к БД.
Определение 2.19. Операндами в реляционной алгебре являются от-
ношения Ri, ki – арность отношения Ri (количество столбцов); ni – количе-
ство строк (кардинальность) в Ri.

2.3.1. Базисный набор операций


1) Объединение: R = R1 ∪ R2.
Результат операции R содержит кортежи из R1 и те кортежи из R2, ко-
торых нет в R1.
Ограничения на операнды:
а) k1 = k2 (теоретическое ограничение);
б) схемы R1 и R2 также должны совпадать (практическое ограничение);
в) дублирующие кортежи в результат включаются только один раз.

38
Пример.
R1 = A B C R2 = A B C R = A B C
a1 b1 c1 a2 b1 c2 a1 b1 c1
a2 b1 c2 a3 b2 c2 a2 b1 c2
a3 b2 c1 a3 b2 c1
a3 b2 c2
SQL: R1 UNION R2.
2. Разность: R = R1 \ R2.
Результат операции R включает в себя кортежи из R1, которых нет в R2.
Ограничения на операнды:
а) k1 = k2;
б) схемы R1 и R2 также должны совпадать.
Пример.
R = A B C
,
a1 b1 c1
a3 b2 c1
SQL: к сожалению, в стандарте SQL нет соответствующего операто-
ра, например, как в ORACLE: R1 MINUS R2, поэтому можно воспользо-
ваться другими конструкциями, например: SELECT * FROM R1 NOT IN
(SELECT * FROM R2).
3. Декартово произведение: R = R1 × R2.
Результат операции R: каждый кортеж из R1 дополняется кортежем из
R2; арность результата – k = k1 + k2; n = n1*n2. Результат декартова произ-
ведения не может содержать дублирующие кортежи, если их не было
в операндах. Одноименные атрибуты получают расширенные имена.
Пример. Пусть
R2 = B C D
b1 c1 d1
b2 c2 d1

39
тогда
R = A R1.B R1.C R2.B R2.C D
a1 b1 c1 b1 c1 d1
a2 b1 c2 b2 c2 d1
a3 b2 c1 b1 c1 d1
a1 b1 c1 b2 c2 d1
a2 b1 c2 b1 c1 d1
a3 b2 c1 b2 c2 d1
SQL: SELECT * FROM R1, R2.
4. Селекция: R = σF(Ri), где F – логическая формула над атрибута-
ми из Ri.
Результатом операции является таблица R, содержащая те же столб-
цы, что и Ri, и строки из Ri, подстановка которых в F дает значение
«истина».
Формула F задается в виде совокупности атомарных условий, свя-
занных между собой операциями ∨, ∧, ¬.
Атомарные условия: <атрибут> 𝜽𝜽 const либо <атрибут>
𝜽𝜽 <атрибут> , где 𝜽𝜽 – операция (=, ≠, ≤, ≥, <, >).
Пример. R = σC=c1 (R1):
R = A B C
a1 b1 c1
a3 b2 c1
SQL: SELECT * FROM Ri WHERE F.
5. Проекция: R = πX(Ri), где X – подмножество атрибутов схемы Ri.
Результат операции – таблица со схемой (заголовком) X; строки таб-
лицы формируются из отношения Ri, но только для атрибутов из X (вы-
резка по столбцам); дублирующие кортежи из результата удаляются.
Пример. R = πBC(R1)
R1 = B C
b1 c1
b1 c2
b2 c1
SQL: SELECT DISTINCT X FROM R1.

40
2.3.2. Дополнительные операции реляционной алгебры
1. Пересечение: R = R1 ∩ R2. Выражение через базисный набор:
R = R1 \ (R1 \ R2).
2. Соединение: 𝑅𝑅 = 𝑅𝑅1 ⋈𝑅𝑅2 , где 𝐹𝐹 ≡ 𝑅𝑅1 𝐴𝐴𝑖𝑖 𝜃𝜃 𝑅𝑅2 𝐴𝐴𝑗𝑗 .
𝐹𝐹
Выражение через базисный набор: 𝑅𝑅 = 𝑅𝑅1 ⋈𝑅𝑅2 = 𝜎𝜎𝐹𝐹 (𝑅𝑅1 × 𝑅𝑅2 ).
𝐹𝐹
Ограничения на операнды: атрибуты Ai и Aj должны быть
θ-сравнимы.
3. Эквисоединение: частный случай соединения, когда 𝐹𝐹 ≡ 𝑅𝑅1 𝐴𝐴𝑖𝑖 =
= 𝑅𝑅2 𝐴𝐴𝑗𝑗 .
4. Естественное соединение: 𝑅𝑅 = 𝑅𝑅1 ⋈ 𝑅𝑅2 .
Каждый кортеж из R1 сопоставляется с каждым кортежем из R2. Два
кортежа соединяются, если все одноименные атрибуты в них имеют оди-
наковое значение, результаты соединения помещаются в R. Столбцы для
одноименных атрибутов не дублируются, так как значения в этих столб-
цах совпадают.
Пример.
R1 = A B C R2 = B C D
a1 b1 c1 b1 c1 d1
a2 b1 c2 b2 c2 d1
a3 b2 c2
Результат естественного соединения:
R = A B C D
a1 b1 c1 d1
a3 b2 c2 d1

Выражение через базисный набор: R = πX(σF(R1×R2)), где


F = ∧i=1,…,k(R1.Ai = R2.Ai) – конъюнкция по всем одноименным атрибутам,
X = [R1]∪[R2] – объединение множеств атрибутов из R1 и R2.

41
Пример.
R1 = поставщики (номер поставщика [А1], наименование поставщи-
ка [А2], адрес поставщика [А3])
R2 = потребители (номер потребителя [А4], наименование потреби-
теля [А5], адрес потребителя [А6])
R3 = детали (номер детали [А7], наименование детали [А8])
R4 = поставка (номер поставщика [А1], номер потребителя [А4], но-
мер детали [А7], цена детали [А9], дата поставки [А10])
Сформулируем запрос: получить список деталей, которые были постав-
лены поставщиком X потребителю Y в период с 20.09.2016 г. по 21.10.2016 г.
π𝐴𝐴8 (σ𝐴𝐴2 =𝑋𝑋 ∧ 𝐴𝐴5 =𝑌𝑌 ∧ 𝐴𝐴10 ≥20.09.2016 ∧ 𝐴𝐴10≤21.10.2016 (𝑅𝑅1 ⋈ 𝑅𝑅2 ⋈ 𝑅𝑅3 ⋈ 𝑅𝑅4 ))
Замечание. Совокупность отношений в выражении должна удовле-
творять локальному свойству соединения без потерь информации и не
должна содержать лишних (для выполнения этого свойства) отношений.
Тогда запрос называется универсальным реляционным запросом.

2.3.3. Свойства операций реляционной алгебры


1. Коммутативность:
𝑅𝑅1 × 𝑅𝑅2 = 𝑅𝑅2 × 𝑅𝑅1 ,
𝑅𝑅1 ⋈𝑅𝑅2 = 𝑅𝑅2 ⋈𝑅𝑅1 ,
𝐹𝐹 𝐹𝐹
где ⋈ – любая операция соединения, в том числе и естественного.
2. Ассоциативность:
(𝑅𝑅1 × 𝑅𝑅2 ) × 𝑅𝑅3 = 𝑅𝑅1 × (𝑅𝑅2 × 𝑅𝑅3 ),

�𝑅𝑅1 ⋈ 𝑅𝑅2 � ⋈ 𝑅𝑅3 = 𝑅𝑅1 ⋈ �𝑅𝑅2 ⋈ 𝑅𝑅3 �,


𝐹𝐹1 𝐹𝐹2 𝐹𝐹1 𝐹𝐹2
где 𝐹𝐹1 – определена на атрибутах 𝑅𝑅1 и 𝑅𝑅2 ,
𝐹𝐹2 – определена на атрибутах 𝑅𝑅2 и 𝑅𝑅3 .
3. Свойство операции проекции:
πХ (𝑅𝑅1 × 𝑅𝑅2 ) = π𝑋𝑋1 (𝑅𝑅1 ) × π𝑋𝑋2 (𝑅𝑅2 ),
где 𝑋𝑋1 = 𝑋𝑋 ∩ [𝑅𝑅1 ], 𝑋𝑋2 = 𝑋𝑋 ∩ [𝑅𝑅2 ].

42
πХ (𝑅𝑅1 ⋈ 𝑅𝑅2 ) = πХ �π𝑋𝑋1 (𝑅𝑅1 ) ⋈ π𝑋𝑋2 (𝑅𝑅2 )�,

где 𝑋𝑋1 = (𝑋𝑋 ∩ [𝑅𝑅1 ]) ∪ ([𝑅𝑅1 ] ∩ [𝑅𝑅2 ]), 𝑋𝑋2 = (𝑋𝑋 ∩ [𝑅𝑅2 ]) ∪ ([𝑅𝑅1 ] ∩ [𝑅𝑅2 ]).
4. Свойство операции селекции:
𝜎𝜎𝐹𝐹 (𝑅𝑅1 × 𝑅𝑅2 ) = 𝜎𝜎𝐹𝐹1 (𝑅𝑅1 ) × 𝜎𝜎𝐹𝐹2 (𝑅𝑅2 ),

𝜎𝜎𝐹𝐹 (𝑅𝑅1 ⋈ 𝑅𝑅2 ) = 𝜎𝜎𝐹𝐹1 (𝑅𝑅1 ) × 𝜎𝜎𝐹𝐹2 (𝑅𝑅2 ),

где 𝐹𝐹1 – определена на атрибутах из 𝑅𝑅1 ,


𝐹𝐹2 – определена на атрибутах из 𝑅𝑅2 ,
𝐹𝐹 = 𝐹𝐹1 ∧ 𝐹𝐹2 .

2.3.4. Формальная оптимизация запросов


Свойства операций используются для формальной оптимизации за-
просов, выполняемой на логическом уровне. Оптимизация «формальная»,
так как не используются сведения о физическом хранении БД, соответ-
ственно отсутствует численный критерий – количество операций вво-
да/вывода.
Механизм оптимизации заключается в наборе правил:
1) операция проекции должна выполняться раньше, чем декартово
произведение и соединение;
2) операция селекции должна выполняться раньше, чем декартово
произведение и соединение;
3) селекция и проекция должны выполняться совместно.
Выполним формальную оптимизацию запроса из предыдущего при-
мера:
π𝐴𝐴8 (π𝐴𝐴1 (𝜎𝜎𝐴𝐴2 =𝑋𝑋 (𝑅𝑅1 )) ⋈ π𝐴𝐴4 (𝜎𝜎𝐴𝐴5 =𝑌𝑌 (𝑅𝑅2 )) ⋈ π𝐴𝐴1 𝐴𝐴4𝐴𝐴7 (𝜎𝜎𝐹𝐹 (𝑅𝑅4 )) ⋈ 𝑅𝑅3 ),
где 𝐹𝐹 = 𝐴𝐴10 ≥ 20.09.2016 ∧ 𝐴𝐴10 ≤ 21.10.2016.

43
2.4. Нормализация отношений

Основной проблемой при проектировании схемы БД является ответ


на вопрос: «Какова должна быть структура логических записей»?
Правильный ответ на этот вопрос является основой принципа незави-
симости данных прежде всего за счет независимости структуры логиче-
ских записей от способа хранения данных и способа их использования
в приложении.
Пример.
Рассмотрим логическую запись со следующей структурой:
Наименование
Номер заказа ФИО заказчика Автор Издательство
книги

Данная совокупность атрибутов не обладает однозначной семантиче-


ской интерпретацией, поэтому имя ей присвоить нельзя.
Следствием некорректного проектирования является, например, невоз-
можность размещения сведений о книге, пока ее кто-нибудь не заказал.
Также при повторном заказе книги информация о ней будет дублироваться.
Основная проблема неправильно сформированных отношений –
наличие аномалий:
1) аномалия дополнения-модификации: при дополнении или моди-
фикации одной записи в отношении БД сразу же возникает необходимость
дополнения или модификации еще нескольких записей;
2) аномалия удаления: при удалении ненужной записи из отношения
БД одновременно удаляется полезная информация, поскольку она хранит-
ся в той же записи.
Для устранения перечисленных недостатков преобразуем структуру
в рассмотренном примере к следующему виду:
Заказчики Книги
Номер Номер Наименование Номер
ФИО заказчика Автор
заказчика книги книги издательства

Издательства Заказы
Номер Номер
Издательство Номер заказа Номер книги
издательства заказчика

44
2.4.1. Функциональные зависимости
Функциональные зависимости являются свойством прикладной обла-
сти и используются для формирования структуры логических записей.
Определение 2.20. Пусть дана схема отношения R, определенная на
множестве атрибутов U = {A1, A2, ..., An}. Пусть X и Y – некоторые под-
множества из множества атрибутов U. Будем говорить, что X функцио-
нально определяет Y (X→Y), если для любой реализации отношения R не
могут присутствовать два кортежа t, u ∈ R такие, что t[X] = u[X] и t[Y] ≠ u[Y]
(кортежи не равны, если не равны значения хотя бы одного атрибута).
Пример 1.
𝐴𝐴1 – табельный номер сотрудника,
𝐴𝐴2 – ФИО сотрудника,
𝐴𝐴3 – должность сотрудника,
𝐴𝐴4 – номер приказа об увольнении.
Прямой способ формирования зависимостей.
𝐴𝐴1 → 𝐴𝐴2 , 𝐴𝐴1 → 𝐴𝐴3 , 𝐴𝐴2 ↛ 𝐴𝐴3 .
Зависимость 𝐴𝐴1 → 𝐴𝐴4 имеет отличную от других область определения,
поскольку атрибут 𝐴𝐴4 определен только для уволенных сотрудников. По-
этому приведенные выше атрибуты не должны объединяться в одну логи-
ческую запись. Заметим, что зависимость 𝐴𝐴2 → 𝐴𝐴2 выполнена всегда, а за-
висимость 𝐴𝐴1 𝐴𝐴2 → 𝐴𝐴3 выполнена, если выполнена 𝐴𝐴1 → 𝐴𝐴3 .
Пример 2.
𝐴𝐴1 – номер дня недели,
𝐴𝐴2 – номер пары,
𝐴𝐴3 – номер группы,
𝐴𝐴4 – номер аудитории.
Обратный способ формирования зависимостей:
𝐴𝐴1 ↚ 𝐴𝐴2 𝐴𝐴3 𝐴𝐴4 , 𝐴𝐴2 ↚ 𝐴𝐴1 𝐴𝐴3 𝐴𝐴4 , 𝐴𝐴3 ↚ 𝐴𝐴1 𝐴𝐴2 𝐴𝐴4 , 𝐴𝐴4 ← 𝐴𝐴1 𝐴𝐴2 𝐴𝐴3 ⇒ 𝐴𝐴1 𝐴𝐴2 𝐴𝐴3 → 𝐴𝐴4
Замечание. Функциональные зависимости – основной вид ограни-
чений целостности данных в БД, которые не могут быть установлены ни-
каким алгоритмическим способом (прежде всего за счет слова «любой»
в определении) – только проектировщиком БД.

45
2.4.2. Правило логического следствия
Дано: схема отношения R на совокупности атрибутов U = {A1, A2, ..., An},
F – множество функциональных зависимостей в R. Правило логического
следствия позволяет обосновать выполнимость того или иного утвержде-
ния. Рассмотрим пример выполнимости функциональной зависимости.
Утверждение 2.1. Если X, Y, Z ⊆U, X→Y∈F и Y→Z∈F, то X→Z вы-
полнена для любой реализации R.
Доказательство: Докажем от противного, пусть X→Z не выполнено
для какой-либо реализации R. Тогда по определению существуют кортежи
t, u ∈ R, такие что t[X] = u[X], t[Z] ≠ u[Z].
Возможны два варианта:
1) t[Y] = u[Y]. Противоречит Y→Z.
2) t[Y] ≠ u[Y]. Противоречит X→Y.
Полученные противоречия доказывают исходное утверждение.

2.4.3. Аксиомы функциональных зависимостей


Впервые свойства данных в виде функциональных зависимостей и их
использование при декомпозиции отношений были предложены Арм-
стронгом (1974 г.). Впоследствии было получено несколько вариантов си-
стем аксиом для этих зависимостей, одна из самых последних состоит из
трех аксиом.
Дано: схема отношения R на совокупности атрибутов U = {A1, A2, ..., An},
F – множество функциональных зависимостей в R.
A1. Рефлексивность: если Y⊆X⊆U, то X→Y.
A2. Пополнение: если X→Y и Z⊆U, то XZ→YZ, где XZ = X ∪ Z,
YZ = Y ∪ Z.
A3. Транзитивность: если X→Y и Y→Z, то X→Z.
Для введенной системы аксиом необходимо доказать полноту и не-
противоречивость (надежность). Система аксиом задает правила выводи-
мости для зависимостей. Для доказательства надежности надо показать,
что выводимые зависимости выполнимы, а для доказательства полноты

46
надо показать, что выполнимые зависимости выводимы. Доказательство
выполняется в рамках метатеории (свойства реализации R).
Для примера рассмотрим доказательство надежности.
A1: если два кортежа в реализации R совпадают по множеству атри-
бутов X, то они совпадают и по множеству атрибутов Y, ч. т. д. (что и тре-
бовалось доказать);
A2: пусть существуют t, u ∈ R такие, что t[XZ] = u[XZ], t[YZ] ≠ u[YZ].
Тогда t[X] = u[X], t[Z] = u[Z], t[Y] ≠ u[Y], что противоречит X→Y, ч. т. д.;
A3: аналогично доказательству правила логического следствия.
Определение 2.21. Пусть F – множество функциональных зависимо-
стей, определенных на множестве атрибутов U = {A1, A2, ..., An}. Множе-
ство всех функциональных зависимостей, выводимых из F посредством
системы аксиом, называется замыканием множества функциональных за-
висимостей и обозначается F+.
Рассмотрим дополнительные правила (теоремы) вывода:
1. Объединение: если X→Y и X→Z, то X→YZ.
2. Псевдотранзитивность: если X→Y и YW→Z, то XW→Z.
3. Декомпозиция: если X→Y и Z⊆Y, то X→Z.
Рассмотрим доказательство правила 3: A1 ⇒ Y→Z, A3 ⇒ X→Z, ч. т. д.
Для доказательства корректности правил в рамках полученной системы
аксиом можно использовать только выводимость.

2.4.4. Ключи
Дано: схема отношения R на совокупности атрибутов U = {A1, A2, ..., An},
F – множество функциональных зависимостей в R.
Определение 2.22. Множество X⊆U является первичным ключом для
R, если X→A1, A2,...,An∈F+ и для любого Y⊂X (Y – истинное подмноже-
ство X) выполнено Y→A1,A2,...,An∉F+.
Замечание. Отношение R может содержать несколько первичных
ключей.

47
2.5. Вторая нормальная форма (2НФ)

Определение 2.23. Атрибут (либо множество атрибутов) B функцио-


нально полностью зависит от множества атрибутов X в отношении R, ес-
ли выполнено X→B∈F+ и для любого Y⊂X (Y – истинное подмножество X)
выполнено Y→B∉F+.
Определение 2.24. Отношение R находится во второй нормальной
форме, если оно удовлетворяет требованиям первой нормальной формы
и любой атрибут B, не являющийся элементом первичного ключа, функ-
ционально полностью зависит от любого первичного ключа в R.

2.5.1. Подходы к построению множества функциональных за-


висимостей
Прямой подход:
Последовательно формируются сочетания без повторений из n эле-
ментов по k, где 𝑘𝑘 = 1, 𝑛𝑛.
Для соответствующих атрибутов текущего сочетания выписывается
множество атрибутов, которое функционально полностью определяется
этим сочетанием.
Процесс формирования сочетаний заканчивается, когда все атрибуты
участвуют в сформированных сочетаниях или в множествах, ими опреде-
ляемых.
Замечание. Если среди атрибутов имеются изолированные, то коли-
чество итераций ∑𝑛𝑛𝑘𝑘=1 𝐶𝐶𝑛𝑛𝑘𝑘 = 2𝑛𝑛 − 1. Поэтому на какой-то итерации необ-
ходимо остановиться и провести анализ на наличие изолированных ат-
рибутов.
Обратный подход:
Последовательно рассматриваем атрибуты из множества U и для каж-
дого атрибута формируем множества атрибутов, которыми этот атрибут
функционально полностью определяется.

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

2.5.2. Построение второй нормальной формы


Дано отношение R, определенное на множестве всех атрибутов
U = {A1, A2, ..., An}, F – множество функциональных зависимостей в R.
Предполагается, что все первичные ключи Xi, i = 1,2,…,m, отношения R
найдены.
Правило построения 2НФ. Выполняем проверку: для каждого Xi
и каждого не ключевого атрибута Bj проверяем выводимость и функ-
циональную полноту зависимости Y→Z, где Y⊂Xi и Bj∈Z. Если зави-
симость найдена, то выполняем декомпозицию: R1 = R[U – Z] = πU–Z(R),
R2 = R[YZ] = πYZ(R). Первичным ключом в R2 становятся атрибуты Y, в R1
ключи такие же, как в R. Для R1 проверка выполняется повторно.
Пример.
𝐴𝐴1 – номер изделия,
𝐴𝐴2 – номер поставщика,
𝐴𝐴3 – наименование поставщика,
𝐴𝐴4 – сведения о поставщике,
𝐴𝐴5 – цена изделия.
Представленный набор атрибутов при объединении в одно отношение
удовлетворяет 1НФ.
Применим прямой подход для построения множества функциональ-
ных зависимостей.
k = 1: 𝐴𝐴1 → ∅, 𝐴𝐴2 → 𝐴𝐴3 , 𝐴𝐴2 → 𝐴𝐴4 , 𝐴𝐴3 → ∅, 𝐴𝐴4 → ∅, 𝐴𝐴5 → ∅.
Зависимости 𝐴𝐴2 → 𝐴𝐴3 , 𝐴𝐴2 → 𝐴𝐴4 объединяем в одну 𝐴𝐴2 → 𝐴𝐴3 𝐴𝐴4 .
k = 2: 𝐴𝐴1 𝐴𝐴2 → 𝐴𝐴5 .
𝐴𝐴1 𝐴𝐴2 функционально определяют 𝐴𝐴3 𝐴𝐴4 𝐴𝐴5 , но функционально полно-
стью определяют только 𝐴𝐴5 .

49
В итоге получим следующие схемы отношений:

Поставщики
Номер Наименование Сведенияо
Сведения
поставщика поставщика опоставщике
поставщике

Поставка
Номер
Номер изделия Цена изделия
поставщика

Замечание. Отношения в 2НФ обладают более определенной семан-


тической интерпретацией по сравнению с 1НФ.

2.5.3. Преимущества 2НФ перед 1НФ


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

2.6. Третья нормальная форма (3НФ)

Дано отношение R, определенное на множестве всех атрибутов


U = {A1, A2, ..., An}, F – множество функциональных зависимостей в R.
Определение 2.25. Отношение R находится в третьей нормальной
форме, если не выполнено следующее условие: пусть X – первичный ключ
в R, существует Y⊆U, существует атрибут (или множество атрибутов)
A∉X∪Y:
1) X→Y∈F+;
2) Y→A∈F+;
3) Y→X∉F+,
где F+ – замыкание множества функциональных зависимостей.

50
Замечание. Если Y⊂X, то указанная зависимость называется частич-
ной, в противном случае – транзитивной.
Пример. A – ФИО студента, X – номер зачетки, Y – номер читатель-
ского билета. X и Y эквивалентные первичные ключи, а требования 3НФ
не нарушены.

2.6.1. Алгоритм построения третьей нормальной формы


Шаг 1: удостоверимся, что схема R удовлетворяет требованиям 2НФ.
Шаг 2: если в отношении R выделены множества X, Y, атрибут A,
удовлетворяющие условиям 1–3 определения, то строится декомпозиция R
на две подсхемы: R1 = R[U–A] = πU–A(R), R2 = R[YA] = πYA(R).
Пример.
𝐴𝐴1 – номер служащего,
𝐴𝐴2 – ФИО служащего,
𝐴𝐴3 – должность служащего,
𝐴𝐴4 – номер проекта,
𝐴𝐴5 – дата окончания проекта,
𝐴𝐴6 – сведения о проекте.
Представленный набор атрибутов при объединении в одно отношение
формально удовлетворяет 2НФ, так как любой атрибут функционально
полностью зависит от атрибута 𝐴𝐴1 .
Выделим функциональные зависимости.
𝐴𝐴1 → 𝐴𝐴2 𝐴𝐴3 𝐴𝐴4 𝐴𝐴5 𝐴𝐴6 .
𝐴𝐴4 → 𝐴𝐴5 𝐴𝐴6 .
𝐴𝐴4 ↛ 𝐴𝐴1 .
𝑋𝑋 = {𝐴𝐴1 }, 𝑌𝑌 = {𝐴𝐴4 }, 𝐴𝐴 = {𝐴𝐴5 , 𝐴𝐴6 }.
После выполнения декомпозиции получаем:

Служащие
Должность
Номер служащего ФИО служащего Номер проекта
служащего

Проекты
Дата окончания Сведенияо
Сведения
Номер проекта опроекте
проекте
проекта

51
Замечание. Отношения в 3НФ обладают более определенной семан-
тической интерпретацией по сравнению с 2НФ.

2.6.2. Преимущества 3НФ перед 2НФ


1. Если над проектом временно никто не работает, то в 2НФ сведения
о нем будут удалены из БД (аномалия удаления).
2. Если изменилась дата окончания проекта, то в 2НФ необходимо
просмотреть всю таблицу, а в 3НФ дата окончания проекта хранится
в единственном экземпляре (аномалия дополнения-модификации).
3. Объем БД в 3НФ обычно меньше, чем в 2НФ, по причине умень-
шения дублирования данных.

2.7. Построение канонической модели реляционного типа

2.7.1. Построение замыканий


При построении 2НФ и 3НФ основной проблемой является определение
принадлежности функциональной зависимости замыканию множества
функциональных зависимостей F+. Построение всего множества F+ имеет
экспоненциальную сложность, поэтому ответ на вопрос о принадлежности
целесообразнее давать с помощью замыкания множества атрибутов.
Дано отношение R, определенное на множестве всех атрибутов
U = {A1, A2, ..., An}, F – множество функциональных зависимостей в R.
Определение 2.26. Пусть F – множество функциональных зависимо-
стей на множестве атрибутов U. Пусть X⊆U. Тогда X+ – это множество ат-
рибутов A таких, что зависимость X→A∈F+. Назовем множество X+ замы-
канием множества атрибутов X. Если X+ = U, то X+ называется обобщен-
ным ключом или суперключом.
Утверждение 2.2. X→Y∈F+⇔ Y⊆X+.
Доказательство: Рассмотрим функциональную зависимость X→Y.
Пусть Y = {A1, A2, ..., Am}.
1. Пусть X→Y∈F+, тогда по правилу декомпозиции X→Ai∈F+ ⇒
Ai∈X+ ⇒ Y⊆X+.
2. Пусть Y⊆X+⇒ Ai∈X+⇒ X→Ai∈F+, тогда по правилу объединения
X→Y∈F+, ч. т. д.

52
Алгоритм построения замыкания множества атрибутов
Шаг 0: полагаем X0=X (по аксиоме рефлексивности).
Шаг i: выполняем очередную итерацию: просматриваем все функци-
ональные зависимости из F. Если для какой-либо зависимости Z→Y∈F,
Z⊆Xi-1 и Y\Xi-1≠∅, то делаем подстановку Xi=Xi-1∪Y и переходим к следу-
ющей итерации. Если на каком-то шаге после просмотра всех функцио-
нальных зависимостей оказалось, что Xi-1=Xi (не было сделано ни одной
подстановки), то полагаем X+=Xi.
Замечание. Количество шагов в алгоритме линейно зависит от коли-
чества атрибутов, поскольку на каждой итерации к множеству Xi дополня-
ется не менее одного атрибута.
Теорема 2.1. Алгоритм корректно формирует множество X+.

2.7.2. Построение минимального покрытия множества функ-


циональных зависимостей
Определение 2.27. Два множества функциональных зависимостей F
и G считаются эквивалентными (F ≡ G), если F+ = G+.
Алгоритм проверки эквивалентности двух множеств функцио-
нальных зависимостей.
Шаг 1: если для каждой зависимости X→Y∈F выполнено 𝑌𝑌 ⊆ 𝑋𝑋𝐺𝐺+ , где
𝑋𝑋𝐺𝐺+ – замыкание множества атрибутов X на множестве функциональных
зависимостей G, то F выводимо из G (𝐺𝐺 ⊢ 𝐹𝐹).
Шаг 2: если для каждой зависимости V→W∈G выполнено 𝑊𝑊 ⊆ 𝑉𝑉𝐹𝐹+ ,
где 𝑉𝑉𝐹𝐹+ – замыкание множества атрибутов V на множестве функциональ-
ных зависимостей F, то G выводимо из F (𝐹𝐹 ⊢ 𝐺𝐺).
Если (𝐺𝐺 ⊢ 𝐹𝐹) и (𝐹𝐹 ⊢ 𝐺𝐺), то F ≡ G.
Утверждение 2.3. Для любого множества функциональных зависимос-
тей F существует эквивалентное множество функциональных зависимостей G,
в котором каждая зависимость в правой части содержит один атрибут.
Доказательство: пусть зависимость X→Y∈F, X→Ai∈G, 𝑖𝑖 = 1, 𝑚𝑚,
Y= {A1, A2, ..., Am}. Докажем эквивалентность множеств F и G.
X→Ai∈G⇒ по правилу объединения X→Y∈G+⇒ 𝑌𝑌 ⊆ 𝑋𝑋𝐺𝐺+ .
X→Y∈F⇒ по правилу декомпозиции X→ Ai∈F+⇒ 𝐴𝐴𝑖𝑖 ⊆ 𝑋𝑋𝐹𝐹+ , ч. т. д.

53
Определение 2.28. Множество функциональных зависимостей G яв-
ляется минимальным покрытием множества функциональных зависимо-
стей F, если:
1) каждая зависимость в G построена из зависимости F с использова-
нием правила декомпозиции и содержит в правой части один атрибут;
2) для любой зависимости 𝑋𝑋 → 𝐴𝐴 ∈ 𝐺𝐺 выполнено 𝐺𝐺– {𝑋𝑋 → 𝐴𝐴} ≢ 𝐺𝐺;
3) для любой зависимости 𝑋𝑋 → 𝐴𝐴 ∈ 𝐺𝐺 и 𝑍𝑍 ⊂ 𝑋𝑋 выполнено
(𝐺𝐺– {𝑋𝑋 → 𝐴𝐴}) ∪ {𝑍𝑍 → 𝐴𝐴} ≢ 𝐺𝐺.
Алгоритм построения минимального покрытия множества функ-
циональных зависимостей (Ульман)
Дано: схема отношения R, определенная на совокупности атрибутов
U = {A1, A2, ..., An}, F – множество функциональных зависимостей в R.
Шаг 1: по правилу декомпозиции преобразуем зависимости из F
к виду с одним атрибутом в правой части.
Шаг 2: по очереди удаляем каждую зависимость из F: G = F–{X→A}
и проверяем эквивалентность полученного множества G исходному F (до-
статочно проверить условие: A∈𝑋𝑋𝐺𝐺+ ). Если получено эквивалентное мно-
жество, то зависимость не возвращается, иначе – возвращается.
Шаг 3: последовательно исключаем по одному атрибуту в левой
части каждой функциональной зависимости X→A∈F. Пусть Z = X–B
и G = {F–{X→A}}∪{Z→A}, если полученное множество G эквивалент-
но F (достаточно проверить условие: A∈𝑍𝑍𝐹𝐹+ ), то атрибут не возвращается,
иначе – возвращается.
Замечание. Мейер ввел численный критерий для задачи построения
минимального покрытия – общее количество атрибутов в функциональ-
ных зависимостях, однако решение все равно не единственное, кроме того
задача в такой постановке становится экспоненциальной.
Замечание. Различный порядок просмотра зависимостей на шагах 2
и 3 может привести к различным результатам. Следовательно, существует
несколько минимальных покрытий множества функциональных зависи-
мостей.

54
Пример. F={A→B, B→C, A→C}
Шаг 1: выполнен.
Шаг 2: G ={B→C, A→C}, 𝐴𝐴+ +
𝐺𝐺 = 𝐴𝐴𝐴𝐴, 𝐵𝐵 ∉ 𝐴𝐴𝐺𝐺 .
G ={A→B, A→C}, 𝐵𝐵𝐺𝐺+ = 𝐵𝐵, 𝐶𝐶 ∉ 𝐵𝐵𝐺𝐺+ .
G ={A→B, B→C}, 𝐴𝐴+ +
𝐺𝐺 = 𝐴𝐴𝐴𝐴𝐴𝐴, 𝐶𝐶 ∈ 𝐴𝐴𝐺𝐺 ⇒ зависимость избыточная.
Шаг 3: выполнен.
В итоге получаем минимальное покрытие {A→B, A→B}.
Пример. Можно заметить, что алгоритм нахождения минимального
покрытия Ульмана не работает в следующем случае (Филиппович А. Ю.):
F={AB→C, A→B, C→B}
Если полностью выполнить первые 3 этапа алгоритма, то получим
следующее покрытие:
F={A→C, A→B, C→B}
Полученное покрытие является избыточным, так как из него можно
исключить транзитивную функциональную зависимость A→B. Чтобы
преодолеть этот недостаток, следует после выполнения третьего этапа еще
раз выполнить второй этап или сначала выполнить 3-й этап, а потом –
2-й. В общем случае итерирование 2-го и 3-го алгоритма необходимо вы-
полнять до тех пор, пока на обоих шагах не будет ни одной подстановки
(количество итераций – полином 4-й степени).

2.7.3. Декомпозиция отношений


Определение 2.29. Декомпозицией ρ(R1, R2, ..,Rk) (или просто ρ) от-
ношения R, определенного на множестве атрибутов U = {A1, A2, ..., An},
называется совокупность отношений {R1, R2, ..,Rk}, где ⋃𝑘𝑘𝑖𝑖=1[𝑅𝑅𝑖𝑖 ] = [𝑅𝑅 ] = 𝑈𝑈
и [Ri] множество атрибутов, на которых определено отношение Ri.
Замечание. Отношения в декомпозиции могут иметь общие атрибу-
ты, то есть для некоторых i, j может быть выполнено [Ri]∩[Rj] ≠ ∅.
Замечание. При построении 2НФ и 3НФ использовалась декомпози-
ция. Там же сформулированы преимущества декомпозиции.

55
Дано: отношение R, определенное на совокупности атрибутов U =
= {A1, A2, ..., An}, F – множество функциональных зависимостей в R, де-
композиция ρ(R1, R2, ..,Rk).
Рассмотрим множество mρ(R) – результат операции естественного со-
единения:
𝑚𝑚𝜌𝜌 (𝑅𝑅) = 𝜋𝜋[𝑅𝑅1 ] (𝑅𝑅) ⋈ 𝜋𝜋[𝑅𝑅2] (𝑅𝑅) ⋈ ⋯ ⋈ 𝜋𝜋[𝑅𝑅𝑘𝑘 ] (𝑅𝑅)

Определение 2.30. Декомпозиция ρ(R1, R2, ..,Rk) обладает свойством


соединения без потерь информации (СБПИ), если для любого отношения
R, удовлетворяющей множеству функциональных зависимостей F, выпол-
нено: mρ(R)=R.
Замечание. В настоящее время свойство СБПИ является вариантом
зависимостей соединения, которые пока еще мало изучены.
Утверждение 2.4. Для любой декомпозиции ρ(R1, R2, ..,Rk) и множе-
ства зависимостей F выполнено R⊆mρ(R).
Доказательство. Выберем произвольный кортеж t ∈R. Любая проек-
ция кортежа t[Ri] содержится в проекции π[Ri](R). По свойству операции
естественного соединения все проекции t[Ri] дадут хотя бы один кортеж,
совпадающий с t. Следовательно, t∈mρ(R), то есть R⊆mρ(R).
Замечание. В обратную сторону включение в общем случае не вы-
полнено.
Алгоритм проверки свойства соединения без потерь информации
Дано отношение R, определенное на множестве всех атрибутов
U = {A1, A2, ..., An}, F – множество функциональных зависимостей в R,
ρ(R1, R2, ..,Rk) – декомпозиция схемы отношения.
Шаг 1: строим таблицу, содержащую k строк (обозначим их символа-
ми Ri) и n столбцов (обозначим их символами Aj). На пересечении i-й
строки и j-го столбца ставим символ aj, если атрибут Aj принадлежит Rj,
иначе – bij.
Шаг 2: выполняется очередная итерация: просматриваются все функ-
циональные зависимости из F, для очередной зависимости X→Y∈F выби-
раем строки из таблицы, значения в которых совпадают для атрибутов

56
из X (совпадающими могут быть не только символы aj, но и bij). Если для
какой-либо строки атрибут Aj*, принадлежащий Y, имеет значение aj*,
то значения bij* в выделенных строках заменяются на aj*. Если во всех
строках атрибут Aj*, принадлежащий Y, имеет значения bij*, то значения bij*
в выделенных строках отождествляются какому-либо одному из этих зна-
чений. Если после очередной итерации появилась строка, полностью со-
стоящая из aj, то декомпозиция ρ обладает свойством соединения без по-
терь информации. Если в одной итерации не было сделано ни одной под-
становки и в таблице отсутствует строка, состоящая из aj, то декомпози-
ция не обладает свойством соединения без потерь информации.
Пример. R(A1, A2, A3), F{A2→A3}, ρ(A1A2, A2A3).
Выполним Шаг 1.
A1 A2 A3
R1 a1 a2 b13
R2 b2 a2 a3
1

Выполним Шаг 2. Для зависимости A2→A3 выделены обе строки. Вы-


полняем подстановку в первую строку:
A1 A2 A3
R1 a1 a2 a3
R2 b21 a2 a3
Получаем, что декомпозиция ρ(A1A2, A2A3) обладает свойством соеди-
нения без потерь информации.
Теорема 2.2. Алгоритм корректно проверяет свойство соединения без
потерь информации для декомпозиции ρ.
Доказательство:
1. Предположим, что в результате работы алгоритма не получено
строки, полностью состоящей из aj. В этом случае достаточно показать,
что существует такая реализация R, для которой выполнено R⊂mρ(R).
В качестве R возьмем результирующую таблицу алгоритма. Строки таб-
лицы являются кортежами R. Символы aj и bij – различные значения атри-
бута Aj. Для различных строк запишем тривиальное равенство aj = aj

57
и для отождествленных значений bij = bij. Отношение R удовлетворяет
всем зависимостям из F, поскольку R – результирующая таблица, а не ис-
ходная, то есть если есть X→Aj∈F, то по построению все строки, в кото-
рых совпадает значение по атрибутам из X, имеют одинаковое значение
и для Aj. Из предположения следует, что R не содержит ни одного корте-
жа, состоящего полностью из aj, однако каждая i-тая проекция π[Ri](R) по
построению содержит кортеж, состоящий из aj. После выполнения опера-
ции естественного соединения эти кортежи соединятся друг с другом,
и полученное множество mρ(R) будет содержать кортеж, состоящий из aj,
что и требовалось доказать.
2. Предположим, что результирующая таблица содержит строку, со-
стоящую из aj. Рассмотрим производящую функцию для множества:
M0={a1, a2,…, an | ∃ bij …(R(w1)∧R(w2)∧…∧R(wk))},

где wi – строки исходной таблицы алгоритма, построенной на первом ша-


ге. Рассмотрим интерпретацию множества M0 на реализации R: строки wi
являются шаблоном, при наложении которого на строку из R получаем
строку, значения в которой останутся без изменения, если в шаблоне им
соответствует символ ai, а в противном случае подставляется символ про-
извольного значения ∗.
Поясним на примере.
R = D E C
d1 e1 c1
d2 e1 c1
d2 e2 c2
ρ(DE, EC)
w1 = a1 a2 b13
w2 = b21 a2 a3
R(w1) = D E C
d1 e1 ∗
d2 e1 ∗
d2 e2 ∗

58
R(w2) = D E C
∗ e1 c1
∗ e2 c2
Далее строки полученных таблиц используются для формирования
строк множества M0: строки ti всех R(wi) сопоставляются каждая с каждой.
Если «склеивается» кортеж t = t1∧t2∧…∧tk, то он добавляется во множе-
ство M0 (сопоставленные кортежи из отношений склеиваются, если нет
противоречащих значений для одноименных атрибутов). При склеивании
считаем, что произвольное значение ∗ равно любому другому значению,
в том числе и произвольному.
M0 = D E C
d1 e1 c1
d2 e1 c1
d2 e2 c2
Рассмотрим произвольный кортеж множества mρ(R). Способом, ана-
логичным предыдущему доказательству (утверждение 2.4), показываем,
что этот кортеж принадлежит M0.
На последующих итерациях алгоритма происходит замена bij на aj,
поскольку вводимое ограничение уже содержалось в другой строке, то
вновь сформированная производная функция для множества M1 совпадает
с множеством M0, и так далее c множеством Ms, для которого в произво-
дящей функции какая-то wi состоит из aj полностью. По предположению,
эта wi накладывает наибольшее ограничение на Ms, то есть не может по-
пасть ни один кортеж, не содержащийся в реализации R, следовательно
Ms ⊆R ⇒ m(R)⊆R. А нами уже доказано, что R⊆m(R) ⇒ m(R)=R. Теорема
доказана.
Определение 2.31. Проекцией πZ(F) множества функциональных за-
висимостей F на множество атрибутов Z называется совокупность функ-
циональных зависимостей X→Y∈F+ таких, что X∪Y⊆Z.
Определение 2.32. Декомпозиция ρ(R1, R2, ..,Rk) сохраняет зависимо-
сти из F, если множество F выводимо из множества ⋃𝑘𝑘𝑖𝑖=1 𝜋𝜋[𝑅𝑅𝑖𝑖 ] (𝐹𝐹).

59
Пример. F = {B→C, AC→B}, декомпозиция ρ(R1, R2), где [R1] = AB
и [R2] = BC.
Декомпозиция ρ удовлетворяет свойству СБПИ, но не сохраняет за-
висимости, так как ⋃𝑘𝑘𝑖𝑖=1 𝜋𝜋𝑅𝑅𝑖𝑖 (𝐹𝐹) = {𝐵𝐵 → 𝐶𝐶}.
Пример. F = {A→B, C→D}, декомпозиция ρ(R1, R2), где [R1] = AB
и [R2] = CD.
Такая декомпозиция не удовлетворяет свойству СБПИ, но зависимо-
сти сохраняются.
Замечание. Сохранение зависимостей – еще один вид требований
к схеме БД. Нарушение этого свойства позволит оператору ввести такие
данные в БД, которые противоречат F и, следовательно, противоречат
прикладной области.

2.7.4. Многозначные зависимости


Дано отношение R, определенное на множестве всех атрибутов
U = {A1, A2, ..., An}, пусть X ⊆ U, Y ⊆ U, Z ⊆ U, X ∩ Y = ∅, X ∩ Z = ∅,
Y ∩ Z = ∅.
Определение 2.33. Множество X мультиопределяет множество Y
в контексте Z: X→→Y(Z) (многозначная зависимость), если для произ-
вольной реализации R схемы R существует два кортежа t1,t2∈R таких, что
t1[X] = t2[X], то существует кортеж t3, для которого выполнено:
t3[X] = t1[X], t3[Y] = t1[Y], t3[Z] = t2[Z],
в силу симметрии существует кортеж t4:
t4[X] = t1[X], t4[Y] = t2[Y], t4[Z] = t1[Z].
Определение 2.34. Многозначная зависимость X→→Y(Z) называется
нетривиальной многозначной зависимостью, если не существует функци-
ональных зависимостей X→Y и/или X→Z.
Определение 2.35. Если Z = U – (X∪Y), то зависимость называется
простой многозначной зависимостью, в противном случае зависимость
называется встроенной многозначной зависимостью.

60
Теорема Фейджина. Пусть X, Y, Z – непересекающиеся множества
атрибутов отношения. Декомпозиция отношения R на проекции R1 = R[X,Y]
и R2 = R[X,Z] будет декомпозицией без потерь тогда и только тогда, когда
существует многозначная зависимость X→→Y(Z).
Признаки наличия многозначной зависимости:
1) если в отношение, содержащее многозначную зависимость, добав-
ляется одна запись, то сразу появляется необходимость дополнения еще
нескольких записей (аномалия дополнения-модификации);
2) для любой реализации R декомпозиция R1 = R[X,Y] и R2 = R[X,Z] об-
ладает свойством СБПИ (согласно теореме Фейджина).
Пример.
A B C D
Номер члена
Дата вылета Номер бригады Номер рейса
экипажа

BD→→C(A)
BD→→A(C)
Замечание. Система аксиом для простых многозначных зависимо-
стей полна и непротиворечива. Система аксиом для встроенных много-
значных зависимостей непротиворечива, но не полна.

2.7.5. Построение канонической модели реляционного типа


Дано отношение R, определенное на множестве всех атрибутов
U = {A1, A2, ..., An}, F – минимальное покрытие множества функциональ-
ных зависимостей в R.
Шаг 1: функциональные зависимости X→Ai∈F, X→Aj∈F …, имею-
щие одинаковые левые части и совпадающие области определения, объ-
единяются в одну зависимость X→AiAj… (по правилу объединения).
Шаг 2: строим декомпозицию ρ(R1, R2, ..,Rk), где [Ri] состоит из атри-
бутов зависимости Fi∈F. Первичным ключом объявляется множество ат-
рибутов в левой части зависимости Fi.
Замечание 1. Атрибуты множества U, не входящие в отношения де-
композиции ρ, называются изолированными. Изолированный атрибут яв-
ляется признаком неполноты множества функциональных зависимостей F

61
и/или множества атрибутов U. В описании прикладной области есть класс
объектов, характеристикой которого является изолированный атрибут, но
для этого класса отсутствует однозначная идентификация экземпляров
объектов (то есть для этого класса нет первичного ключа). В такой ситуа-
ции рекомендуется ввести искусственный первичный ключ (например,
пронумеровать объекты) и вернуться к построению множества F. Если
проблему не удалось решить предлагаемым способом, то переходим к вы-
полнению шага 3.
Замечание 2. Из способа построения Ri очевидно, что декомпозиция ρ
сохраняет функциональные зависимости.
Замечание 3. Не гарантируется выполнение свойства соединения без
потерь информации. Осуществляется проверка этого свойства по алго-
ритму. Если свойство выполнено, – конец построения, если нет, – выпол-
няем шаг 4.
Шаг 3: строится обобщенный ключ (суперключ) W – первичный ключ
для отношения R, и декомпозиция ρ дополняется еще одним отношением:
ρ1 = ρ∪{W}. Если отношение, соответствующее обобщенному ключу, яв-
ляется интерпретируемым и технологичным (см. далее), то ρ1 – результат
построения. В противном случае выполняется шаг 4.
Шаг 4: в обобщенном ключе W определяется многозначная зависи-
мость X→→Y(Z) (возможно их несколько), причем атрибуты X могут пол-
ностью или частично отсутствовать в W, и выполняется декомпозиция от-
ношения W на отношения XY и XZ: ρ2 = ρ∪{XY}∪{XZ}. Чаще всего отно-
шения {XY} и {XZ} уже содержатся в декомпозиции ρ либо представимы
через отношения в ней (тогда ρ2 = ρ), и ρ2 обладает свойством соединения
без потерь информации в рамках четвертой нормальной формы.
Замечания. По правилу проверки свойства СБПИ для четвертой нор-
мальной формы декомпозиция ρ2 обладает свойством СБПИ, если деком-
позиция ρ1 обладает свойством СБПИ в 3НФ. Если в обобщенном клю-
че W несколько многозначных зависимостей, то должен быть вычислен их
базис (аналог минимального покрытия) и декомпозиция осуществляется

62
по каждому элементу базиса. В общем случае суперключ W может содер-
жать нетривиальную зависимость соединения, тогда выполняется переход
к построению пятой нормальной формы.
Рассмотрим основные свойства построенных декомпозиций.
Утверждение 2.5. Декомпозиции ρ, ρ1 и ρ2 находятся в 3НФ.
Доказательство: формирование отношений выполняется в шагах 2, 4
и 5. При построении обобщенного ключа на шаге 3 и его декомпозиции на
шаге 4 вновь вводимые отношения не содержат функциональных зависи-
мостей, следовательно, не могут противоречить 3НФ. Рассмотрим шаг 2.
Допустим, что в отношении Ri, построенном на объединенных зависимо-
стях X→Al и X→Am, появилась транзитивная или частичная зависимость,
то есть существует Y⊆Ri: X→Y и Y→Am, тогда по правилам построения
минимального покрытия зависимость X→Am должна быть удалена. Анало-
гично, если существует Y⊆Ri: X→Y и Y→Al, тогда по правилам построения
минимального покрытия зависимость X→Al должна быть удалена, что
противоречит сделанному предположению.
Утверждение 2.6. Декомпозиция ρ1 обладает свойством СБПИ.
Доказательство: поскольку X – ключ отношения R, то X+= R. Рас-
смотрим атрибуты A1, A2,.., An = R–X, составленные в порядке их включе-
ния в множество X+. Выполняется итерация Xj = X∪{A1, A2,.., Aj–1}. При
добавлении Aj к X+ используется функциональная зависимость Y→Aj, где
Y⊆Xj. По правилу формирования декомпозиции существует Ri, для кото-
рого YAj⊆Ri, следовательно строки в таблице для отношения Ri и X совпа-
дают по атрибутам из Y и равны aj, а в столбце для Aj имеет значение aj,
тогда атрибуту Aj в строке для X будет поставлено значение aj и так далее.
А поскольку X += R, то строка для X будет полностью заполнена aj, ч. т. д.
Проблемы обобщенного ключа:
1. Обобщенный ключ не обладает свойством однозначной семантиче-
ской интерпретации, то есть этому отношению нельзя присвоить одно-
значное имя.

63
Причины и решение:
а) потеря функциональных зависимостей на атрибутах, входящих
в обобщенный ключ. С использованием обратного подхода находим зави-
симости и переходим к построению минимального покрытия;
б) потеря атрибутов и, чаще всего, неверная интерпретация значений
атрибутов. Например, «Номер водителя», «Номер диспетчера» и т. д. надо
заменить атрибутами «Номер сотрудника» и «Должность сотрудника»;
в) наличие многозначных зависимостей и зависимостей соединения
в обобщенном ключе (проблема решается на шаге 4).
2. Нетехнологичность обобщенного ключа. На предприятии отсут-
ствует служба, которая отвечала бы за сопровождение данных в этом от-
ношении.
Решение:
а) сформировать новую схему документооборота на предприятии;
б) придется признать, что на самом деле существует не одна, а не-
сколько БД, они не могут быть интегрированы.

64
3. Физическая организация баз данных

При рассмотрении логической структуры БД не учитывались место


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

3.1. Архитектура ЭВМ

Технология обработки данных зависит от конфигурации вычисли-


тельной системы и ее функциональных возможностей.
В 1966 году М. Флинн предложил классификацию архитектур ЭВМ,
основанную на потоке данных и потоке команд.
Тип 1: ОКОД – одиночные команды, одиночные данные.
SISD – single instruction, single data.

65
В каждый конкретный момент времени выполняется одна команда,
которая обрабатывает единичное данное. Это соответствует фоннейма-
новскому принципу работы ЭВМ, реализованному в первых трех поколе-
ниях ЭВМ.
Тип 2: МКОД – многие команды, одиночные данные.
MISD – multiple instruction, single data.
Одиночный поток данных обрабатывается сразу несколькими коман-
дами. Вычислительная система содержит последовательность процессоров,
где выходные данные одного процессора являются входом для другого.

i i+1

То есть выход одного процессора является входом для другого (маги-


стральная или конвейерная обработка данных). Впервые данная архитек-
тура была реализована в семействе машин Cray (в середине 1980-х годов).
В настоящее время идея потоковой обработки данных нашла успешное
воплощение в графических процессорах (GPU), которые применяются для
высокопроизводительных параллельных вычислений (технология CUDA
компании NVidia).
Тип 3: ОКМД – одиночные команды, многие данные.
SIMD – single instruction, multiple data.
На вход вычислительного устройства поступает массив данных, кото-
рый одновременно обрабатывается одной командой.
К данному классу можно отнести одноядерные процессоры, работа-
ющие в режиме выполнения команд векторных расширений (например,
SSE компании Intel, 3DNow компании AMD, MAJC компании Sun и т. д.).
SSE (Streaming SIMD Extensions) – расширение инструкций процес-
сора для потоковой обработки данных в режиме ОКМД. Расширение SSE
впервые применено в процессоре Intel Pentium III.
Также типичными представителями данного класса являются матрич-
ные процессоры. Вычислительное устройство имеет в этом случае решет-
чатую структуру. Линии – вертикальные и горизонтальные входные ши-
ны. В узлах расположены элементарные процессоры.

66
Простым примером применения данной архитектуры является мат-
ричное устройство умножения, в узлах которого расположены сумматоры.
Первой попыткой построить матричный процессор был компьютер
ILLIAC IV (70-е годы).
Тип 4: МКМД – многие команды, многие данные.
MIMD – multiple instruction, multiple data.
Класс MIMD чрезвычайно широк и включает в себя многопроцессор-
ные системы, многоядерные процессоры, а также разнообразные компью-
терные кластеры.

3.1.1. Факторы, влияющие на физическую организацию базы


данных
При выборе того или иного метода доступа учитываются следующие
факторы:
1) скорость поиска данных (ведущий фактор при выборе структуры БД);
2) скорость модификации (обновления) данных;
3) объем внешней памяти, занимаемой БД;
4) реализация ограничений целостности на данные;
5) обеспечение многопользовательского доступа к данным.
Перечисленные требования к физической организации БД являются
противоречивыми (требуется компромисс).
Требование 1 в явном виде противоречит требованиям 2 и 3.
Поддержка функциональных зависимостей и поддержка ссылочной
целостности реализуются с помощью индексных файлов, поэтому требо-
вание 4 противоречит требованиям 2 и 3. Причем требование 4 не гаран-

67
тирует повышение скорости поиска. Например, ссылки, как правило, идут
от ключевых полей и для поиска данных по содержательным полям не ис-
пользуются.
Критерий 5 не противоречит 1–4, пока БД физически расположена на
одном сервере. Если же БД находится на нескольких серверах, то 5 проти-
воречит 1.
При модификации данных СУБД не даст изменить данные на одном
сервере до тех пор, пока не заблокирует модифицируемые записи на всех
серверах. Также данные не считаются, пока не разблокируются на всех
серверах.

3.1.2. Схема временных затрат при работе с базой данных


Рассмотрим упрощенную схему реализации запроса в СУБД на
устройстве с одним центральным процессором и одним устройством вво-
да/вывода.

Ввод Передача Передача Виуализация


Визуализация
CPU
данных данных данных данных

УВВ

Буфер

CPU –- центральный процессор

УВВ –- устройство ввода/вывода

–- очередь устройства

Очередь к CPU обслуживается примерно на 3 порядка быстрее, чем


очередь к УВВ, следовательно основные задержки возникают при обслу-
живании очереди устройства ввода/вывода.
Основной источник затрат – механическое позиционирование считы-
вающей головки УВВ на нужный блок (дорожку).

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

3.2. Классификация методов доступа

Определение 3.1. Методом доступа называется алгоритм преобра-


зования значения поискового ключа в адреса соответствующих ему запи-
сей в БД.
Поскольку скорость поиска записей является ведущим фактором фи-
зической реализации БД, то в основу классификации методов доступа по-
ложим классификацию запросов пользователей.
В основе классификации запросов – количество исходных записей,
отнесенных к общему количеству записей.
1-й класс запросов. Получить все или многие записи.
При реализации запроса требуется просмотреть от X до 100 % запи-
сей. Осуществляется последовательный просмотр файлов БД без ис-
пользования поиска по ключам. Наиболее типовой пример – составление
отчетов.
Методы доступа, соответствующие этому классу, должны реализовы-
вать эффективную последовательную обработку. Для этого предназначе-
ны безындексные методы доступа, основанные:
– на физически смежном последовательном файле;
– связных списках.
2-й класс запросов. Получить уникальную запись.
Требуется одна запись по значению первичного ключа.
Для решения этой задачи ориентированы практически все индексные
методы доступа:
– индексно-последовательный;
– индексно-произвольный;

69
– иерархические индексные файлы, Б-деревья;
– прямой метод доступа и методы хеширования первичного ключа.
3-й класс запросов. Получить некоторые записи (от 0 до X %).
Запросы данного класса наиболее часто используются в СУБД.
Для реализации таких запросов используются:
– инвертированные файлы;
– мультисписки;
– индексы-соединения.
Значение X – это пороговое значение для СУБД. Когда превышается
порог, СУБД отключает при поиске записей все индексные файлы.
Чем качественнее СУБД, тем больше X.
Для СУБД Oracle X ≈ 25 %, у большинства СУБД X не превышает 10 %.
Рассмотренная классификация запросов основана на первом факторе
физической организации – скорости поиска данных. Выбор метода досту-
па в пределах одного класса запросов зависит от других факторов, влия-
ющих на физическую реализацию:
– от частоты обновления данных;
– объема внешних данных;
– поддержки ограничений целостности и др.

3.2.1. Последовательный метод доступа


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

70
Поиск записей
Утверждение 3.1. Среднее количество прочитанных записей a (длина
поиска) для поиска в последовательном файле k записей равно:
𝑘𝑘∙𝑛𝑛
,
𝑘𝑘+1

где n – общее количество записей в файле.


Доказательство: обозначим через xi местоположение i-й искомой за-
писи, где i = 1, 2, …, k. При достаточно больших n значение xi можно счи-
тать непрерывной случайной величиной. По предположению, xi – незави-
симые случайные величины. Предположим также, что xi имеют равномер-
ное распределение.
Согласно теории вероятностей математическое ожидание непрерыв-
ной случайной величины
𝑛𝑛
𝑎𝑎� = ∫0 𝑎𝑎 ∙ 𝑓𝑓(𝑎𝑎)𝑑𝑑𝑑𝑑,

где f(a) – плотность вероятности случайной величины a.


Для данной постановки задачи можно записать функцию распределе-
ния вероятности F(a) = P(x1≤a ∧ x2≤a ∧ … ∧ xk≤a). Знак ≤ в выражении
следует из определения последовательного доступа.
Из условия независимости случайных величин получаем, что функция
распределения имеет вид
𝑘𝑘

𝐹𝐹 (𝑎𝑎) = � 𝑃𝑃(𝑥𝑥𝑖𝑖 ≤ 𝑎𝑎).


𝑖𝑖=1

С учетом равномерности распределения x получаем


𝑘𝑘
𝑎𝑎 𝑎𝑎 𝑘𝑘
𝐹𝐹 (𝑎𝑎) = � = � � .
𝑛𝑛 𝑛𝑛
𝑖𝑖=1

Выразим плотность вероятности через функцию распределения:

′(
𝑘𝑘 ∙ 𝑎𝑎𝑘𝑘−1 .
𝑓𝑓(𝑎𝑎) = 𝐹𝐹 𝑎𝑎) =
𝑛𝑛𝑘𝑘

71
𝑛𝑛
𝑘𝑘 ∙ 𝑎𝑎𝑘𝑘−1 𝑘𝑘 ∙ 𝑎𝑎𝑘𝑘+1 𝑛𝑛 𝑘𝑘 ∙ 𝑛𝑛𝑘𝑘+1 𝑘𝑘 ∙ 𝑛𝑛 .
𝑎𝑎� = � 𝑎𝑎 ∙ 𝑑𝑑𝑑𝑑 = | = =
𝑛𝑛𝑘𝑘 (𝑘𝑘 + 1) ∙ 𝑛𝑛𝑘𝑘 0 (𝑘𝑘 + 1) ∙ 𝑛𝑛𝑘𝑘 𝑘𝑘 + 1
0

Что и требовалось доказать.


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

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

Рассмотрим операции дополнения и удаления.


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

3.2.2. Индексно-последовательный метод доступа


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

73
Все пространство основного файла БД делится на блоки фиксирован-
ной длины. Нижняя граница размера блока чаще всего определяется объ-
емом данных, перемещаемым в оперативную память за одно обращение
к диску. Верхняя граница размера блока – объем памяти, считываемый
с диска без механического перемещения считывающих головок устрой-
ства ввода/вывода.
Записи могут иметь переменную длину, однако каждый блок содер-
жит целое количество записей. Все записи упорядочены по значению
первичного ключа (сортировка может производиться в любом лексико-
графическом порядке, для определенности будем считать, что записи от-
сортированы «по возрастанию»).
Для доступа к данным по значению первичного ключа организуется
индекс первого уровня, который состоит из блоков фиксированной длины
(размеры блоков совпадают с размерами блоков основного файла).

Индекс 1-го уровня

ключ m ключ n

Основной файл

запись 1 … запись m запись m+1 … запись n

Индекс первого уровня (запись в индексном файле) содержит ссылку


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

74
Поиск записей
Последовательно прочитываются блоки последнего (верхнего) уровня
индекса. Определяется блок предыдущего уровня индекса, и т. д. до ин-
декса первого уровня. По записи индекса первого уровня определяется
блок основного файла, в котором может находиться искомая запись. За-
вершающий поиск – просмотр блока основного файла.
Индексно-последовательный метод доступа (ISAM – Indexed Sequen-
tial Access Method) был разработан компанией IBM для своих мейнфрей-
мов в 1960-е годы. В системах IBM 360, 370 метод ISAM является базис-
ным (то есть реализован средствами ОС) и имеет следующую организа-
цию на пакете дисков:

Дорожки, расположенные друг под другом, называются цилиндром


(внутренние цилиндры имеют большую плотность записи, а внешние –
меньшую, поэтому вместимость всех цилиндров одинаковая).

75
На первой дорожке цилиндра располагается блок индекса первого
уровня. На всех последующих дорожках располагаются блоки основного
файла, которые индексированы этим индексным блоком.
Таким образом, при поиске минимизируется перемещение головок
устройства ввода/вывода.
Даже без такой организации на диске индексно-последовательный
метод доступа имеет следующие преимущества:
1) наивысшая скорость поиска записей;
2) минимальный объем дискового пространства (индекс ссылается
сразу на несколько записей, поэтому размер индексного файла получается
меньше, чем в других методах);
3) индексный метод доступа совмещается с последовательным поис-
ком по первичному ключу (так как записи упорядочены по значению пер-
вичного ключа).
Добавление, удаление и модификация записей
Удаление и модификация записей происходят после их нахождения
процедурой поиска.
Рассмотрим операцию дополнения записей. Поскольку записи упоря-
дочены по первичному ключу, то при дополнении определяются две запи-
си, между которыми необходимо вставить новую запись. Если все записи
помещаются в блок (существующие в блоке записи и новая запись), то но-
вая запись добавляется в блок и операция дополнения завершается.
Если очередная запись не помещаются в блок, то возникает ситуация
переполнения. Для ее решения используются два универсальных метода.
1. Метод отведенного свободного пространства. При первоначаль-
ной загрузке блоки основного файла заполняются частично (примерно на
70 %), тот же метод применяется и к блокам индексных файлов.
2. Метод области переполнения. Определяется местоположение до-
полняемой записи в соответствии с возрастанием первичного ключа. Если
она не помещается в найденный блок, то последние записи, не поместив-
шиеся в блок, перемещаются в область переполнения – отдельное про-
странство на диске. Там они не сортируются, а связываются в цепочку
в соответствии с возрастанием первичного ключа: перемещенные записи

76
становятся первыми в цепочке, соответствующей данному блоку. Таким
образом, область переполнения содержит множество цепочек, «вытолкну-
тых» из различных блоков основного файла, в результате снижается ско-
рость поиска данных.
Для индексно-последовательного доступа необходимо периодическое
выполнение процедуры сопровождения, которая заключается в переписы-
вании данных из старого файла в новый файл с использованием метода
отведенного свободного пространства, а также в формировании новых ин-
дексных файлов и очистке области переполнения.
Вывод: область применения индексно-последовательного метода – ма-
ло изменчивые файлы. Кроме того, ключом может быть только одно поле.
Методика оценки длины поиска
Утверждение 3.2. Для поиска k записей, произвольным образом рас-
положенных в файле, содержащем r записей и b блоков, в среднем необ-
ходимо просмотреть
𝑘𝑘
𝑟𝑟𝑟𝑟 − 𝑖𝑖 + 1
𝑏𝑏 �1 − � �
𝑟𝑟 − 𝑖𝑖 + 1
𝑖𝑖=1

блоков, где
1
𝑑𝑑 = 1 − .
𝑏𝑏
Доказательство: будем использовать предположение о независимо-
сти и равномерности распределения.
Вероятность того, что в i-м блоке не будет ни одной искомой записи,
равна
𝑘𝑘
𝐶𝐶𝑟𝑟−𝑝𝑝 ,
𝐶𝐶𝑟𝑟𝑘𝑘
где p = r/b – среднее количество записей в блоке, r – p = r – r/b = rd, то есть
вероятность равна
𝑘𝑘
𝐶𝐶𝑟𝑟𝑟𝑟 .
𝑘𝑘
𝐶𝐶𝑟𝑟

77
Тогда вероятность того, что в i-м блоке находится хотя бы одна иско-
мая запись, равна
𝑘𝑘
𝐶𝐶𝑟𝑟𝑟𝑟
1 − 𝑘𝑘 .
𝐶𝐶𝑟𝑟
Среднее количество выбранных блоков
𝑘𝑘 𝑘𝑘
𝐶𝐶𝑟𝑟𝑟𝑟 𝑟𝑟𝑟𝑟! 𝑘𝑘! (𝑟𝑟 − 𝑘𝑘 )! 𝑟𝑟𝑟𝑟 − 𝑖𝑖 + 1
𝑏𝑏 �1 − 𝑘𝑘 � = 𝑏𝑏 �1 − � = 𝑏𝑏 �1 − � � , ч. т. д.
𝐶𝐶𝑟𝑟 (𝑟𝑟𝑟𝑟 − 𝑘𝑘)! 𝑘𝑘! 𝑟𝑟! 𝑟𝑟 − 𝑖𝑖 + 1
𝑖𝑖=1

Замечание. Полученное выражение можно использовать для вычис-


ления оптимального размера блока.
∞ 𝑘𝑘
1 𝑟𝑟 − 𝑝𝑝 − 𝑖𝑖 + 1
𝜑𝜑(𝑝𝑝) = � 𝑝𝑝�𝑘𝑘 ∙ ∙ �1 − � � ⟶ 𝑚𝑚𝑚𝑚𝑚𝑚,
𝑝𝑝 𝑟𝑟 − 𝑖𝑖 + 1 𝑝𝑝
𝑘𝑘=1 𝑖𝑖=1

где 𝑝𝑝�𝑘𝑘 – вероятность поступления запроса на k записей, количество запи-


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

3.2.3. Индексно-произвольный метод доступа


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

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

ключ 1 ключ 2

* длина ключ остальные компоненты записи

Запись основного файла всегда занимает целое число логических бло-


ков. Начало записи всегда совпадает с началом очередного свободного
блока.
Запись состоит из следующих полей:
– контрольная сумма;
– длина записи;
– выделенное поле, содержащее ключ записи (ключевое поле записи);
– остальные компоненты записи.
Записи могут иметь переменную длину, и в основном файле по ключу
они не упорядочены.
В качестве контрольной точки может выступать сумма по модулю 2
всех полей текущей записи.
Пример. В .dbf файлах под контрольную сумму отводится один байт.
Если в контрольной сумме стоит символ «∗», значит запись удалена, если
запись не удалена, то ставится символ «пробел».
Для поиска записей формируется индексный файл, содержащий запи-
си фиксированной длины.
Запись индексного файла содержит значение ключа и ссылку на пер-
вый блок основного файла, содержащий соответствующую запись.
Все записи в индексном файле упорядочены в каком-либо лексико-
графическом порядке по значению ключа.
Признак полного индекса – каждая запись основного файла имеет со-
ответствующий ей экземпляр записи в индексном файле.

79
Методы поиска в полном индексе
Метод 1. Блочный поиск.
Пусть индексный файл содержит N записей. Все пространство ин-
дексного файла условно разобьем на блоки по n записей.
Просматривается первая запись каждого блока, то есть сначала иско-
мый ключ сравнивается с ключом 1-й записи, затем с ключом 𝑛𝑛 + 1 запи-
си, далее с ключом 2𝑛𝑛 + 1 записи и т. д. Если для какой-то записи с номе-
ром (𝑖𝑖 × 𝑛𝑛) + 1 ключ записи оказался больше искомого, то искомая запись
находится в 𝑖𝑖 − 1 блоке. Блок просматривается со второй записи (так как
первую запись уже просмотрели).
Если размеры блока велики, то его также можно разбить на блоки, ес-
ли нет, то блок просматривается последовательно.
Оптимальный размер блока 𝑛𝑛 = √𝑁𝑁.
Средняя длина поиска одной записи √𝑁𝑁⁄2.
Метод 2. Бинарный поиск (метод деления отрезка пополам).
Все пространство поиска условно делится пополам. Искомый ключ
сравнивается со значением ключа серединной записи и т. д. Если искомый
ключ больше, то новое пространство поиска – это вторая половина преж-
него пространства поиска. В противном случае – первая. При совпадении
поиск заканчивается.
Длина поиска 𝑙𝑙𝑙𝑙𝑙𝑙2 𝑁𝑁.
Если известна функция распределения значений ключа, то вычисля-
ется не середина отрезка, а математическое ожидание искомой записи. Ес-
ли запись не найдена, то вычисляется условное математическое ожидание
(формулы Байеса).
В этом случае длина поиска 𝑙𝑙𝑙𝑙𝑙𝑙2 𝑙𝑙𝑙𝑙𝑙𝑙2 𝑁𝑁.
Замечание. Бинарный поиск теоретически имеет лучшие оценки по
длине поиска, чем блочный, однако записи в нем выбираются хаотически,
что приводит к многократному перемещению считывающих головок
устройства ввода/вывода, что в свою очередь приводит к увеличению
времени поиска.
Вывод: для файлов небольшого размера более быстрым является
блочный поиск.

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

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

3.2.4. Прямой метод доступа


Основной признак прямого метода – возможность непосредственно-
го преобразования ключа записи в ее адрес в основном файле.
Ключом является, как правило, номер объекта.
Ограничением данного метода является фиксированная длина запи-
си в основном файле.
Пример.

Отделы
Наименование
Номер отдела Адрес отдела ФИО начальника
отдела

Номер отдела интерпретируется как относительный адрес записи от


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

82
Операции поиска, дополнения, удаления и модификации выполняют-
ся за одно обращение к основному файлу. Основной файл не вырождается
и, следовательно, не требует выполнения процедуры сопровождения.
Главный недостаток данного метода доступа – отсутствие универ-
сальности (поэтому в СУБД данный метод не используется в качестве ба-
зисного, а только как вспомогательный).
Допустим, первичный ключ записи состоит из 20 символов латинско-
го алфавита. Пространство, необходимое для хранения записей со всевоз-
можными значениями ключа, занимает 2026 × 𝐿𝐿 байт, где L – длина запи-
си. Это файл огромного размера, который, скорее всего, будет заполнен не
более чем на 10 %.

3.2.5. Методы хеширования


Методы хеширования имеют те же преимущества, что и прямой ме-
тод, но за счет более сложной функции отображения ключа в адрес записи
более эффективно используется пространство основного файла.
Для построения функции хеширования необходимо предварительно
определить интервал изменения первичного ключа (исходного или преоб-
разованного) и приблизительное количество записей в основном файле.
Функция хеширования 𝜑𝜑(𝐾𝐾) = 𝛢𝛢, где K – значение ключа, A – отно-
сительный адрес записи в основном файле.
Основной задачей функции хеширования 𝜑𝜑 является преобразование
интервала измерений значений первичного ключа в квазиравномерное
распределение адресов записей.
Определение 3.2. Ключи K1 и K2 называются синонимами относи-
тельно функции хеширования, если 𝜑𝜑(𝐾𝐾1 ) = 𝜑𝜑(𝐾𝐾2 ).
Естественное требование к функции хеширования – минимизация ко-
личества синонимов. Ситуация появления синонима называется перепол-
нением.
Построение функции хеширования
При построении функции хеширования каждому значению ключа
ставится в соответствие его двоичный эквивалент, интерпретируемый
функцией хеширования как целое число без знака. По интервалу измене-
ния ключа определяется интервал изменения его цифрового эквивалента.

83
Рассмотрим три базисных метода построения функции хеширования 𝜑𝜑.
Метод 1. Метод квадратов
Двоичный эквивалент ключа возводится в квадрат, и из результата
выбирается необходимое количество разрядов центральной части.
Полученное число умножается на масштабный множитель m, приво-
дящий интервал изменения ключа к размеру файла. Полученный резуль-
тат является адресом записи.
Этот метод, как и последующие методы, дает квазиравномерное рас-
пределение адресов.
Определимся с выбором величины масштабного множителя m.
Допустим, 𝑚𝑚 ≅ 10. Тогда в основном файле будет занята только каж-
дая десятая запись (то есть если 𝑚𝑚 > 1, то не все пространство файла бу-
дет занято).
Допустим, 𝑚𝑚 ≅ 0,1. При таком масштабном множителе получим
в среднем 10 синонимов на каждую запись.
Из вышесказанного делаем вывод, что 𝑚𝑚 ≅ 1. Точное соотношение
определяется количеством выбранных срединных разрядов.
Метод 2. Метод деления
Двоичный эквивалент первичного ключа делится на количество запи-
сей в файле либо на число, близкое к этому количеству. Остаток от деле-
ния считается адресом записи.
Делитель должен быть при этом достаточно большим и не должен со-
держать мелких сомножителей (на практике наименьший сомножитель
должен быть не меньше 20). Наилучший результат дает использование
в качестве делителя простого числа. Игнорирование этого требования
приведет к зацикливанию вычисляемых остатков, что приведет к много-
кратному уменьшению их общего количества и, как следствие, к синони-
мам функции хеширования.
Метод 3. Метод замены системы исчисления
Исходное представление первичного ключа в десятичной системе ис-
числения преобразуется в какую-либо другую систему исчисления.
𝑛𝑛 𝑚𝑚

� 𝑎𝑎𝑖𝑖 ∙ 10𝑛𝑛−𝑖𝑖 = � 𝑏𝑏𝑗𝑗 ∙ 𝑝𝑝𝑚𝑚−𝑗𝑗 .


𝑖𝑖=0 𝑗𝑗=0

84
Лучше, когда p – простое число, близкое к 10 (на практике часто ис-
пользуется p = 7).
Двоичное представление младших разрядов полученного преобразо-
вания умножается на масштабный множитель. Результат умножения счи-
тается адресом записи.
Количество младших разрядов числа и масштабный множитель под-
бираются аналогично методу квадратов.
Замечание. Для построения наилучшей функции хеширования необ-
ходимо исследование значений первичного ключа.
Проведенные исследования показали, что приемлемые результаты
в большинстве случаев дает метод деления, хотя в каждом конкретном
случае можно найти более оптимальную функцию хеширования с исполь-
зованием комбинации различных методов.
Обработка переполнений
Метод 1. Метод открытой адресации
При появлении синонима рассматривается запись, следующая за си-
нонимом, и, если она свободна, туда помещается вновь поступившая за-
пись. Если запись занята, то просматривается следующая запись и т. д. до
конца файла, а затем (если не нашли свободного места) – с начала файла
до места поиска. Если найдена свободная запись, то вновь поступившая
запись помещается на это место.
Если достигнуто место поиска, а свободная запись не найдена, значит
свободное место файла исчерпано и необходима смена функции хеширо-
вания.
Применение метода открытой адресации совместно с методом отве-
денного свободного пространства (масштабный множитель 𝑚𝑚 ≈ 1.3) дает
хорошие результаты на практике.
Метод 2. Метод нелинейного поиска
При появлении синонима полученный адрес используется для вычис-
ления нового адреса.
𝜉𝜉 (𝛢𝛢𝑖𝑖−1 ) = 𝛢𝛢𝑖𝑖

85
Пример.
𝜉𝜉 (𝛢𝛢) = 𝑎𝑎𝑖𝑖 2 + 𝑏𝑏𝑏𝑏 + 𝑐𝑐,
где 𝑖𝑖 – номер попытки поиска (номер итерации),
𝑐𝑐 – предыдущий адрес,
𝑎𝑎, 𝑏𝑏 – произвольные константы.
Результат вычисления делится на количество записей в файле. Оста-
ток от деления – новый адрес.

3.2.6. B-деревья
B-деревья лежат в основе методов доступа всех современных СУБД.
Являются разновидностью методов доступа с полным индексом.
Определение 3.3. B-деревом называется дерево, удовлетворяющее
следующим свойствам:
1) узлом B-дерева является блок, содержащий максимально 2𝑛𝑛 − 1 за-
писей;
2) все блоки дерева, за исключением корня, содержат не менее n за-
писей;
3) первая запись блока содержит только указатель на блок-потомок,
все последующие записи блока содержат значение ключа, ссылку на запись
в основном файле и ссылку на блок-потомок. Ключ и ссылку на основной
файл называют содержанием записи;
4) все записи блока упорядочены по возрастанию ключа;
5) листья B-дерева не имеют потомков (все ссылки на блоки-потомки
нулевые). Любой другой узел, содержащий m записей со значениями клю-
чей K2,…, Km (в 1-й записи ключа нет), содержит ссылки на m потомков,
причем выполнено:
– ключи блока-потомка первой записи (и всех его потомков) по зна-
чению меньше K2;
– для любой i-й записи блока, 1< i < m, ключи блока-потомка (и всех
его потомков) по значению больше Ki и меньше Ki+1;
– ключи блока-потомка записи m (и всех его потомков) по значению
больше Km;

86
6) B-дерево всегда сбалансировано по высоте, причем максимальный
и минимальный пути равны.
В классической реализации каждый блок B-дерева дополнительно со-
держит текущее количество записей в блоке и флаг leaf, принимающий
значение «истина», если блок является листом.
Рассмотрим структуру блока классического B-дерева.

Первая запись блока Вторая запись блока


Количество Признак листа Значение ключа
Ключ пустой
записей в блоке leaf записи
Ссылка на СсылкаСсылка
на запись
на Ссылка на
блок-потомок в основном файле
запись в блок-потомок
основном файле

Пример. 2-3-4 B-дерево (каждый узел может иметь 2, 3 или 4 дочер-


них узла). Для упрощения отобразим только ключи и ссылки на блоки-
потомки.

20 60

7 12 17 44 74 91

3 10 13 16 19 25 33 58 69 76 80 85 98

Замечание. В настоящее время существует множество разновидно-


стей B-деревьев.
B+-дерево – копии ключей хранятся во внутренних узлах, записи
в блоках-листьях помимо ключа содержат в себе записи основного файла.
Кроме того, для ускорения последовательного доступа листовой блок мо-
жет содержать ссылку на правого соседа.
B*-дерево – разновидность B-дерева, в которой каждый узел дерева
заполнен не менее чем на 2/3 (в отличие от B-дерева, где этот показатель
составляет 1/2). Для данного вида деревьев, при дополнении записей, про-
цедура деления блока выполняется при заполнении двух соседних блоков
(2 блока делятся на 3).

87
Поиск записи
Поиск начинается с корня. В каждом блоке просматриваются записи,
начиная со второй, и сравниваются с искомым ключом. Как только нашли
запись с большим ключом, чем искомый, выбираем ссылку на блок-
потомок из предыдущей записи и переходим к новому блоку. Если ключ
последней записи блока меньше искомого, то переходим на блок-потомок
по ссылке из последней записи блока.
При совпадении ключей в текущей записи выбирается адрес записи
в основном файле и осуществляется переход к записи в основном файле.
Дополнение записи
Процедурой поиска определяется блок и пара записей, между кото-
рыми должна быть вставлена дополняемая запись. Дополнение всегда
начинается с листа, так как записи еще нет в индексном файле. Иначе –
ошибка.
Если в текущем блоке меньше 2n-1 записей, то новая запись помеща-
ется в текущий блок и операция дополнения завершена.
В противном случае (в блоке 2n-1 записей) переходим к процедуре
«поделись с левым соседом». Первая запись текущего блока (она у нас пу-
стая) забирает содержимое записи предка и перемещается в блок левого
соседа. Вслед за ней перемещаются записи текущего блока так, чтобы за-
писей у текущего блока и соседа было поровну. Содержимое первой запи-
си текущего блока помещается в запись-предок.
Если не удается выполнить процедуру «деления с левым соседом»
(блок заполнен или его нет), то переходим к процедуре «поделись с пра-
вым соседом». Из записи предка правого соседа забираем содержимое
и помещаем его в первую запись правого соседа. Из текущего блока пере-
мещаем часть записей в правого соседа так, чтобы записей у текущего
блока и соседа было поровну. Содержимое первой записи правого соседа
помещается в запись-предок.
Если не удалось поделиться с правым соседом, то переходим к проце-
дуре «деления блока».
В структуре B-дерева добавляется новый блок, и вторая половина за-
писей текущего блока помещается в новый блок. Получаем два блока,
в каждом из которых n записей (в текущем блоке первая запись пустая,

88
в новом блоке все записи заполнены). Содержание первой записи нового
блока удаляется из первой записи и дополняется ссылкой на новый блок.
Сформированная запись помещается в блок-предок текущего блока, и все
действия для нее выполняются заново.
Процедура деления блока может дойти до корня дерева. В этом слу-
чае формируется новый корень, содержащий всего две записи.
Удаление записи
Процедурой поиска определяется удаляемая запись.
Если запись находится не в листе, то содержимое удаляемой записи
замещается содержимым второй записи самого левого потомка-листа. Да-
лее в качестве удаляемой записи рассматривается вторая запись самого
левого потомка-листа.
Таким образом, далее будем считать, что удаление записи всегда идет
с листа.
Блок с удаляемой записью объявляется текущим.
Удаляем запись из текущего блока. Если в текущем блоке после уда-
ления остается не менее n записей, то процедура удаления завершается,
иначе – выполняется процедура «позаимствуй у правого соседа».
Если процедура невыполнима (в правом соседе n записей или его
нет), то выполняется процедура «позаимствуй у левого соседа».
Если не удалось «позаимствовать у левого соседа», то переходим
к процедуре «слияние с правым соседом». Все записи правого соседа,
начиная со второй, помещаются в текущий блок, удаляется запись-предок
правого соседа.
Если правого соседа нет, то переходим к процедуре «слияние с левым
соседом», при этом удаляется запись-предок текущего блока.
Слияние блоков может дойти до корня. В этом случае корнем стано-
вятся два слившихся потомка и высота дерева уменьшается на 1.
Сопровождение B-дерева
B-дерево не вырождается в процессе эксплуатации и не требует вы-
полнения специальной процедуры сопровождения.
Можно выполнить реорганизацию B-дерева с целью реализации ме-
тода отведенного свободного пространства, при этом блоки получают ле-
востороннее упорядочение в файле и заполняются не более чем на 70 %.

89
3.2.7. Мультисписки и инвертированные файлы
Рассмотренные ранее методы доступа ориентированы на 1-й и 2-й
классы запросов («получить все или почти все записи» и «получить уни-
кальную запись»). Класс запросов «получить некоторые записи» для рас-
смотренных методов выполняется не эффективно.
Рассмотрим более подробно класс запросов «получить некоторые
записи».
1. Атомарное условие.
АУ ≔ < имя элемента данных >< операция Θ >< значение >,
где Θ ∈ {>, <, ≥, ≤, =, ≠}.
2. Условие элемента данных.
УЭД ≔ АУ1 ∨ АУ2 ∨ … ∨ АУ𝑛𝑛 – дизъюнкция атомарных условий, отно-
сящихся к одному и тому же элементу данных.
3. Условие выбора записи.
УВЗ ≔ УЭД1 ∧ УЭД2 ∧ … ∧ УЭД𝑚𝑚 – конъюнкция условий элемента
данных, относящихся к различным элементам данных.
4. Условие запроса.
УЗ ≔ УВЗ1 ∨ УВЗ2 ∨ … ∨ УВЗ𝑘𝑘 – дизъюнкция условий выбора записи.
Мультисписки
Рассмотрим пример.
Допустим, что логическая запись содержит следующие элементы
данных: «Номер студента», «ФИО студента», «Номер группы», «Год
рождения».
Первичным поисковым ключом является номер студента. Для его ин-
дексации можно использовать различные индексные методы доступа,
например B-дерево. Для поиска по полям «Номер группы» и «Год рожде-
ния» индексные методы не применимы, так как одно и то же значение
может встречаться в нескольких записях.
Мультисписковая организация для поиска по этим полям может
иметь следующую структуру.

90
1-й уровень индекса 2-й уровень индекса Экземпляры записей основного файла БД

№ группы M01 315 Иванов


Иванов И. И.
И.И. M01 1995

Год рождения M02

412 Петров П. П.
Петров П.П. M01 1996

516 Сидоров С. С.
Сидоров С.С. M02 1995
1995

1996
Достоевский Ф.
610 Достоевский Ф.М.
М. M02 1996

Содержанием индекса первого уровня являются имена индексируе-


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

91
создать указатель в индексе второго уровня. Таким образом, в индексе
второго уровня мы получаем записи переменной длины.
Длина поиска для такого мультисписка может быть сокращена, если
каким-либо образом удастся идентифицировать нужную подцепочку.
Допустим, записи в основном файле упорядочены по значению пер-
вичного ключа и в запросе есть ограничение на значение первичного клю-
ча, тогда по интервалу значений первичного ключа, возможно, удастся
определить нужную подцепочку.
Инвертированный файл
Основным недостатком мультисписка является наличие цепочек в ос-
новном файле (нарушение требования локальности модифицирующих
воздействий).
Определение 3.5. Мультисписок с ограниченной длиной цепочки
называется инвертированным файлом, если максимальная длина подце-
почки равна 1.
Из определения получаем, что все цепочки в основном файле исчеза-
ют, а записи индекса 2-го уровня содержат указатели на все записи основ-
ного файла.
Для решения проблемы переменной длины записи в индексе второго
уровня формируется индекс третьего уровня, состоящий из блоков спис-
ков указателей на записи основного файла.
Поиск записей
По атомарным условиям в индексе второго уровня находим указатели
на 3-й уровень. При вычислении УЭД выполняем объединение множеств
ссылок. При вычислении УВЗ выполняем пересечение множеств ссылок.
При вычислении УЗ объединяем оставшиеся множества ссылок. В итоге
получаем ссылки на нужные записи, не обращаясь в структуру основного
файла.
Определение 3.6. Инвертированный файл называется косвенным,
если в индексе третьего уровня в качестве указателя на запись основного
файла используются значения первичного ключа записи.

92
Преимущества косвенного инвертированного файла:
– записи в основном файле становятся перемещаемыми;
– некоторые запросы могут быть выполнены без обращения к основ-
ному файлу (если в качестве результата выполнения запроса требуются
значения индексируемого атрибута или значения первичного ключа).
Недостаток – замедляется поиск записей, так как необходимо при-
менять дополнительные методы доступа для поиска записей в основном
файле по значениям первичного ключа.
Определение 3.7. Инвертированный файл называется индексом со-
единения, если одновременно индексируются несколько основных файлов
базы данных.
Замечание. В этом случае указатель на 3-м уровне индекса состоит
из номера файла и номера записи.

93
Заключение

Настоящее учебное пособие содержит основы теории и технологии


баз данных. Целью теоретической части пособия является ознакомление
студентов с принципами построения не избыточного и не противоречиво-
го проекта БД. Следует отметить, что представленный материал является
только верхушкой айсберга. Огромное количество монографий и научных
статей на эту тему остается предметом самостоятельного изучения. Это
необходимо не только для научной работы, но и для практики проектиро-
вания БД, поскольку сложные ситуации проектирования явились источни-
ком научных исследований.
Технологическая часть учебного пособия содержит основы знаний,
необходимых для администрирования БД. К сожалению, не рассмотрены
вопросы, посвященные управлению транзакциями. Хотя формально они
относятся к отдельному курсу СУБД, однако являются необходимыми ад-
министратору БД.
В качестве практической рекомендации использования рассмотренно-
го материала приведем слова известного специалиста в области БД Кузне-
цова С. Д.: «Скорее всего, потенциальные читатели ... работают или будут
работать с какой-либо SQL-ориентированной СУБД. Любая компания,
производящая подобные СУБД, называет их реляционными системами.
Очень важно отчетливо понимать, какие свойства таких систем действи-
тельно являются реляционными, а что в них не вполне соответствует ис-
ходным, ясным и строгим идеям реляционного подхода и даже противо-
речит им. Это поможет более правильно организовывать базы данных
и строить приложения в среде SQL-ориентированной СУБД».

94
Библиографический список

1. Мартин, Дж. Организация баз данных в вычислительных системах :


[пер. с англ.] / Дж. Мартин. – М. : Мир, 1980. – 665 с.
2. Дейт, К. Введение в системы баз данных : [пер. с англ.] / К. Дейт. –
М. : Вильямс, 2017. – 1328 с.
3. Ульман, Дж. Основы систем баз данных : [пер. с англ.] / Дж. Уль-
ман. – М. : Финансы и статистика, 1983. – 336 с.
4. Тиори, Т. Проектирование структур баз данных : [пер. с англ.] /
Т. Тиори, Дж. Фрай. – М. : Мир, 1985. – Кн. 2. – 321 с.
5. Калиниченко, Л. А. Методы и средства интеграции неоднородных
баз данных / Л. А. Калиниченко. – М. : Наука, 1987. – 424 с.
6. Замулин, А. В. Типы данных в языках программирования и базах
данных / А. В. Замулин. – Новосибирск : Наука, 1987. – 152 с.
7. Вейнеров, О. М. Разработка САПР. Кн. 4. Проектирование баз
данных САПР / О. М. Вейнеров, Э. Н. Самохвалов. – М. : Высшая школа,
1990. – 144 с.
8. Мейер, Д. Теория реляционных БД : [пер. с англ.] / Д. Мейер. – М. :
Мир, 1987. – 608 с.
9. Цаленко, М. Ш. Моделирование семантики в БД / М. Ш. Цаленко. –
М. : Наука, 1989. – 288 с.
10. Кузнецов, С. Д. Основы баз данных / С. Д. Кузнецов. – М. : Ин-
туит.ру, 2005. – 488 с.

95

Оценить