- •Введение
- •Глава 1. Основные понятия баз данных
- •1.1. История возникновения баз данных
- •1.2. Модели данных
- •1.2.1. Иерархическая модель данных
- •1.2.2. Сетевая модель базы данных
- •1.2.3. Реляционная модель базы данных
- •1.2.4. Другие модели баз данных (ООСУБД)
- •2.1. История появления и развития SQL
- •Глава 2. SQL
- •2.2. Стандарты SQL
- •2.2.1. Стандарты ANSI/ISO
- •2.2.2. ODBC и консорциум SQL Access Group
- •2.2.3. JDBC и серверы приложений
- •2.3. SQL и переносимость
- •2.4. SQL и сети
- •2.4.1. Централизованная архитектура
- •2.4.2. Архитектура файлового сервера
- •2.4.3. Архитектура “клиент/сервер”
- •2.4.4. Многоуровневая архитектура
- •2.4.5. SQL и мэйнфреймы
- •2.4.7. SQL и UNIX
- •2.4.8. SQL и персональные компьютеры
- •2.4.9. SQL, хранилища данных и интеллектуальные ресурсы предприятия
- •2.4.10. SQL и интернет-приложения
- •2.5. Основы SQL
- •2.5.1. Использование SQL для извлечения информации из таблиц
- •2.5.2. Команда SELECT
- •2.5.3. Создание более сложных предикатов в предложении SELECT
- •2.5.4. Формирование вывода запросов
- •2.5.5. Агрегатные группы
- •2.6. Запросы к нескольким таблицам
- •2.6.1. Подзапросы
- •2.6.2. Использование операторов ANY, ALL и SOME
- •2.6.3. Использование предложения UNION
- •2.6.4. Ввод, удаление и изменение значения поля
- •2.7. DDL (Язык описания данных)
- •2.7.1. Создание таблиц
- •2.7.2. Индексы
- •2.7.3. Изменение структуры таблицы после ее создания
- •2.8. Ограничение данных
- •2.8.1. Ограничение таблиц
- •2.8.2. Установка значений по умолчанию
- •2.9. Поддержка целостности данных
- •2.9.1. Первичные ключи
- •2.9.2. Пользовательские представления
- •2.10. Модификация данных с помощью представлений
- •2.11. Разграничение доступа в базе данных
- •Глава 3. Математические основы реляционных баз данных
- •3.1. Отношения и их схемы
- •3.2. Реляционные операторы
- •3.2.1. Булевы операции
- •3.2.2. Оператор выбора
- •3.2.3. Оператор проекции
- •3.2.4. Оператор соединения
- •3.2.5. Другие операции на отношениях
- •3.2.6. Оператор деления
- •3.2.7. Оператор переименования атрибутов
- •3.2.8. Оператор эквисоединения
- •3.2.9. Расширения для сравнения на доменах
- •3.2.9.1. Расширение выбора
- •3.3. Реляционная алгебра
- •3.3.1. Дополнительные операторы
- •3.3.1.1. Оператор расщепления
- •3.3.1.2. Оператор FACTOR
- •3.4. Функциональные зависимости
- •3.4.1. Определение
- •3.4.2. Аксиомы вывода
- •3.4.3. Применение аксиом вывода
- •3.4.4. Выводы на основе аксиом вывода
- •3.4.6. Направленные ациклические графы вывода
- •3.4.7. Проверка принадлежности к замыканию множества функциональных зависимостей
- •3.5. Покрытия функциональных зависимостей
- •3.5.1. Покрытия и эквивалентность
- •3.5.2. Неизбыточные покрытия
- •3.5.3. Редуцированные покрытия
- •3.5.3.1. Посторонние атрибуты
- •3.5.3.3. Алгоритм построения редуцированного покрытия
- •3.5.3.4. Канонические покрытия
- •3.5.3.5. Структура неизбыточных покрытий
- •3.5.4. Минимальные покрытия
- •3.5.4.1. Прямая определяемость
- •3.5.4.2. Вычисление минимальных покрытий
- •3.5.4.3. Оптимальные покрытия
- •3.5.5. Составные функциональные зависимости
- •3.5.6. Кольцевые покрытия
- •3.6. Многозначные зависимости и зависимости соединения
- •3.6.1. Многозначные зависимости
- •3.6.2. Многозначные и функциональные зависимости
- •3.6.3. Аксиомы вывода для многозначных зависимостей
- •3.6.4. Только многозначные зависимости
- •3.6.5. Функциональные и многозначные зависимости
- •3.6.6. Зависимости соединения
- •3.7. Синтез схем реляционных баз данных
- •3.7.1. Базы данных и их схемы
- •3.7.2. Нормальные формы баз данных
- •3.7.2.1. Первая нормальная форма
- •3.7.2.2. Вторая нормальная форма
- •3.7.2.4. Нормальная форма Бойса - Кодда (НФБК)
- •3.7.2.5. Четвертая нормальная форма
- •3.7.2.3. Третья нормальная форма
- •3.8. Алгоритмы синтеза схем баз данных
- •3.8.1. Нормализация через декомпозицию
- •3.8.2. Недостатки нормализации через декомпозицию
- •3.8.3. Нормализация посредством синтеза
- •Глава 4. Система управления базами данных PostgreSQL
- •4.1. Установка
- •4.2. Запуск и останов сервера PostgreSQL
- •4.2.1. Утилита psql
- •4.2.2. Создание базы данных
- •4.3. Объекты базы данных
- •4.4. Функции и операторы
- •4.4.1. Логические операторы
- •4.4.2. Операторы сравнения
- •4.5. Клиентские приложения PostgreSQL
- •4.5.1. clusterdb
- •4.5.2. createdb
- •4.5.3. createuser
- •4.5.4. dropdb
- •4.5.5. dropuser
- •4.5.6. ecpg
- •4.5.7. pg_basebackup
- •4.5.8. pgbench
- •4.5.9. pg_config
- •4.5.10. pg_dump
- •4.5.11. pg_dumpall
- •4.5.12. pg_isready
- •4.5.13. pg_receivewal
- •4.5.14. pg_restore
- •4.5.15. psql
- •4.5.16. reindexdb
- •4.5.17. vacuumdb
- •4.6. Серверные приложения PostgreSQL
- •4.6.1. initdb
- •4.6.2. pg_archivecleanup
- •4.6.3. pg_checksums
- •4.6.4. pg_controldata
- •4.6.6. pg_resetwal
- •4.6.7. pg_rewind
- •4.6.8. pg_test_fsync
- •4.6.9. pg_test_timing
- •4.6.10. pg_upgrade
- •4.6.11. pg_waldump
- •4.6.12. postgres
- •4.6.13. postmaster
- •4.7. Серверное программирование
- •4.7.1. Расширение SQL
- •4.7.2. Триггеры
- •Заключение
- •Библиографический список
- 125 -
Схема отношения R = (S , K) включает F-зависимость K R, если K K.
Пример. Схема отношения предметы включает F-зависимость ПРЕДМЕТ ПРЕДМЕТ СЕМЕСТР.
Схема базы данных R = {R1, R2, ..., Rp} представляет множество функциональных зависимостей G = { X Y | некоторое Ri из R включает X Y}. Схема базы данных полностью характеризует множество функциональных зависимостей F, если F G.
Пример. Схема базы данных R представляет множество F- зависимостей G = { ФАМИЛИЯ ПРЕДМЕТ ФАМИЛИЯ ПРЕДМЕТ ОЦЕНКА, ПРЕДМЕТ ПРЕДМЕТ СЕМЕСТР }.
Та же схема R полностью характеризует множество F = = { ФАМИЛИЯ ПРЕДМЕТ ФАМИЛИЯ ПРЕДМЕТ ОЦЕНКА СЕМЕСТР, ПРЕДМЕТ ПРЕДМЕТ СЕМЕСТР }. Множество F не может быть представлено схемой R, поскольку первая F-зависимость содержит атрибут СЕМЕСТР (во множестве он специально подчеркнут), который не входит в схему отношения оценки.
3.7.2. Нормальные формы баз данных
В данном разделе будут приведены основные нормальные формы, которые являются ограничениями, накладываемыми на схему базы данных, которые позволяют избавить базу данных от некоторых нежелательных свойств, основными из которых являются нарушение целостности данных, избыточность и невозможность представления некоторых видов данных. Для всех нормальных форм характерно то, что они первоначально рассматриваются относительно отношений, а затем распространяются на базу данных целиком. Другими словами, первоначально к определенной нормальной форме приводятся все отношения базы данных, и после этого автоматически вся база данных начинает удовлетворять той же нормальной форме, что и все входящие в нее отношения. Нормальная форма базы данных определяется по наиболее «слабому» с точки зрения нормальных форм отношению. Сама операция приведения и отношения и базы данных в целом называется нормализацией.
-126 -
3.7.2.1.Первая нормальная форма
Схема отношения R находится в первой нормальной (1НФ) форме, если значения доменов всех атрибутов из схемы R — атомарны (неделимы).
Понятие атомарности в данном случае — аналог понятия неделимости с точки зрения представляемой информации. Другими словами, значения в доменах не должны представлять собой списки, множества простых и сложных значений. Примеры, которые рассматривались нами ранее, уже были в первой нормальной форме. Определить атомарность не всегда легко, так как в различных приложениях одни и те же атрибуты могут рассматриваться как атомарные или не атомарные. При определении свойства атомарности следует постараться в первую очередь определить: будут ли значения использоваться в приложении по частям или нет.
Пример. Рассмотрим отношение рождение, в котором указываются дни рождения:
рождение( |
ИМЯ |
ДАТА_РОЖДЕНИЯ ) |
|
|
Павел |
4 сентября 1984 |
|
|
Наталья |
3 января 1980 |
|
|
Антонина |
12 апреля 1967 |
|
Если при работе с отношением рождение следует решать задачи, которые требуют обработки, например, только числа или только месяца (выбрать все записи, касающиеся только тех, кто родился в сентябре), то данное отношение не будет находиться в первой нормальной форме и его атрибуты надо будет разбить на части, как это показано в отношении рождение , которое уже находится в первой нормальной форме:
рождение ( |
ИМЯ |
ДЕНЬ |
МЕСЯЦ |
ГОД РОЖДЕНИЯ |
) |
|
|||||
|
Павел |
4 |
сентября |
1984 |
|
|
Наталья |
3 |
января |
1980 |
|
|
Антонина |
12 |
апреля |
1967 |
|
Пример. Отношение зачет, приведенное ниже, не находится в первой нормальной форме, потому что значение первого атрибута представлено множеством атомарных значений:
зачет( |
СТУДЕНТ |
ЗАЧЕТ ) |
|
|
{Балашов, Колобаев} |
Нет |
|
|
{Колычева, Сидоров, Гаплыков} |
Да |
|
- 127 -
Для приведения его к первой нормальной форме требуется разделить значения атрибута СТУДЕНТ, как это сделано в отношении
зачет .
зачет ( СТУДЕНТ ЗАЧЕТ )
Балашов Нет Колобаев Нет Колычева Да Сидоров Да Гаплыков Да
Постараемся ответить на вопрос, чем вызвана необходимость приведения отношений к первой нормальной форме? Можно выделить две основные причины.
Во-первых, только первая нормальная форма позволяет представлять F-зависимости с должной степенью детализации. Предположим, что нами модернизировано отношение рождение и к нему добавлен атрибут ЗНАК, определяющий, к какому знаку зодиака относится тот или иной человек. Как известно, знак зодиака определяется только числом и месяцем, но ни в коем случае не годом. Следовательно, существует F-зависимость ДЕНЬ_РОЖДЕНИЯ МЕСЯЦ_РОЖДЕНИЯ ЗНАК. Однако в схеме отношения рождение такую зависимость можно представить только как ДАТА_РОЖДЕНИЯ ЗНАК, что позволит двум людям с одинаковыми днями и месяцами рождения, но с различным годом рождения иметь различные знаки зодиака.
Во-вторых, в не приведенных к первой нормальной форме отношениях могут возникнуть трудности при изменении данных, например после получения зачета студентом Колобаевым требуется удалить его из множества {Балашов, Колобаев} и добавить к множеству {Колычева, Сидоров, Гаплыков}, что достаточно трудно выполнимо.
3.7.2.2. Вторая нормальная форма
Если первая нормальная форма представлялась необходимой для представления ограничений, накладываемых на данные в реляционной модели данных, то последующие нормальные формы — результат попыток избавиться от аномалий при изменении и избыточности данных. Аномалии возникают в процессе работы информационной системы и могут быть вызваны как ошибками в программном обеспечении, так и в результате аппаратных сбоев. Попробуем рассмотреть более подробно отношение расписание:
- 128 -
расписание ( ГРУППА |
ПРЕДМЕТ |
СПЕЦИАЛЬНОСТЬ |
ЛЕКТОР ) |
||
|
740 |
физика |
2201 |
Гущин |
|
740 |
химия |
2201 |
Пронин |
||
741 |
физика |
2201 |
Гущин |
||
741 |
химия |
2201 |
Пронин |
||
742 |
химия |
2206 |
Никитин |
||
Ключом данного отношения является составной атрибут ГРУППА ПРЕДМЕТ, кроме того , в отношении выполняется F- зависимость ГРУППА СПЕЦИАЛЬНОСТЬ. Отношение обладает рядом нежелательных свойств:
1.Операция изменения данных CH(расписание ; ГРУППА = 740, ПРЕДМЕТ = «физика»; СПЕЦИАЛЬНОСТЬ = 2202) приводит к нарушению F-зависимости ГРУППА СПЕЦИАЛЬНОСТЬ, поскольку теперь группа 740 относится одновременно к специальности 2201 и 2202.
2.Операция удаления DEL(расписание ; ГРУППА = 742, ПРЕДМЕТ = = «химия») приводит к потере информации о том, что группа 742 обучается по специальности 2206.
3.Отношение не содержит информации о принадлежности к специальностям групп, расписание для которых еще не составлено.
4.Для групп 740 и 741 дублируется информация об их принадлежности к соответствующим специальностям.
Все приведенные недостатки будут устранены, если провести декомпозицию отношения расписание на два отношения предметы и специальности следующим образом:
предметы( ГРУППА |
ПРЕДМЕТ |
ЛЕКТОР ) |
||
|
740 |
физика |
Гущин |
|
740 |
химия |
Пронин |
||
741 |
физика |
Гущин |
||
741 |
химия |
Пронин |
||
742 |
химия |
Никитин |
||
специальности ( ГРУППА СПЕЦИАЛЬНОСТЬ )
7402201
7412201
7422206
- 129 -
Обратим внимание на то, что исходное отношение полностью восстанавливается: предметы специальности = расписание.
Для того чтобы дать определение второй нормальной формы, следует ввести еще один вид функциональной определяемости:
Атрибут Y частично зависит от атрибута X относительно множества F-зависимостей F тогда, когда зависимость X Y не редуцирована слева относительно F. Другими словами, атрибут X функционально полно определяет атрибут Y, если нет такого собственного подмножества X X, что F X
→ Y.
Пример. В множестве F-зависимостей
F = { ГРУППА ПРЕДМЕТ СПЕЦИАЛЬНОСТЬ ЛЕКТОР,
ГРУППА СПЕЦИАЛЬНОСТЬ } атрибут ЛЕКТОР функционально полно зависит от ГРУППА ПРЕДМЕТ, а атрибут СПЕЦИАЛЬНОСТЬ — нет.
Для данной схемы отношения R и множества функциональных зависимостей F над R атрибут A из R называется первичным в R , если он входит в состав одного из ключей схемы R. В противном случае атрибут называется
непервичным.
В литературе наряду с этим названием часто используется термин
ключевой и неключевой атрибуты.
Пример. Для схемы R = ГРУППА ПРЕДМЕТ СПЕЦИАЛЬНОСТЬ ЛЕКТОР атрибуты ГРУППА ПРЕДМЕТ являются ключевыми, а СПЕЦИАЛЬНОСТЬ ЛЕКТОР — нет.
Схема отношения R находится во второй нормальной форме относительно множества функциональных зависимостей F, если она находится в первой нормальной форме относительно F, и каждый непервичный атрибут в R функционально полно зависит от любого ключа схемы. Схема базы данных R находится во второй нормальной форме, если каждая из составляющих ее схем отношений также находится во второй нормальной форме.
Пример. Отношение расписание не находится во второй нормальной форме из-за того, что атрибут СПЕЦИАЛЬНОСТЬ функционально неполно зависит от ключа K = ГРУППА ПРЕДМЕТ, поскольку имеется зависимость ГРУППА СПЕЦИАЛЬНОСТЬ, а атрибут ГРУППА - подмножество ключа {ГРУППА ПРЕДМЕТ}.
