
- •Введение
- •Глава 1 информационные системы
- •1.1 Информация как ресурс
- •1.2 Файловые системы
- •1.3 Информационные системы, использующие базы данных
- •1.3.1 Иерархические и сетевые модели данных
- •1.3.2 Реляционные системы управления базами данных
- •1.4 Компоненты информационных систем
- •1.4.1 Технические средства
- •1.4.2 Программное обеспечение
- •1.4.3 Данные
- •1.4.4 Пользователи
- •1.4.5 Организационное обеспечение
- •1.4.6 Отношения между компонентами системы
- •1.5 Основы проектирования информационных систем
- •1.5.1 Жизненный цикл программного обеспечения
- •1.5.2 Модели жизненного цикла по
- •1.5.3 Подходы к проектированию ис
- •1.6 Задания и вопросы для повторения
- •2.2 Подходы к проектированию баз данных
- •2.3 Создание базы данных
- •2.4 Основы концептуального проектирования баз данных
- •Объекты и отношения
- •2.3.2. Атрибуты
- •2.3.3 Ключи
- •2.3.4 Наследование
- •2.3.5 Составные объекты
- •2.3.6 Моделирование концептуальных и физических объектов
- •2.4 Реляционная модель данных
- •2.4.1 Поддержка целостности данных
- •Процесс нормализации таблиц
- •2.4.3 Пример построения нормализованной базы данных
- •2.4.4 Преобразование концептуальной модели в реляционную
- •2.5 Элементы er-моделирования
- •2.5.1 Основные понятия модели «сущность-связь»
- •2.5.2 Основные графические обозначения элементов модели
- •2.6 Заключительный этап проектирования
- •2.7 Сравнение концептуального и реляционного моделирования
- •2.8 Вопросы и задания для повторения
- •2.9 Упражнения и задачи
- •2.10 Проекты и профессиональные вопросы
- •Глава 3 реляционная алгебра и реляционное исчисление
- •3.1 Реляционная алгебра
- •3.1.1 Обзор реляционной алгебры
- •3.1.2 Теоретико-множественные операторы
- •3.1.3 Специальные реляционные операторы
- •3.1.4 Зависимые реляционные операторы
- •3.1.5 Примитивные реляционные операторы
- •3.2 Реляционное исчисление
- •3.2.1 Целевой список и определяющее выражение
- •3.2.2 Квантор существования
- •3.2.3 Квантор всеобщности
- •3.3 Заключение
- •3.4 Вопросы на повторение
- •3.5 Упражнения и задачи
- •Глава 4 управление реляционной базой данных с помощью sql
- •4.1 Элементы Transact-sql
- •Комментарии
- •4.1.2 Алфавит
- •4.1.3 Идентификаторы
- •Выражения
- •4.1.5 Ключевые слова
- •Операторы
- •4.1.7 Логические операторы
- •Типы данных
- •- Функции Transact-sql
- •4.2 Выборка данных из таблиц
- •4.2.1 Структура команды select
- •Результаты выборки
- •Отбор столбцов
- •Select Фамилия, Город from Гостиница.Dbo.Клиент
- •4.2.4 Определение заголовков столбцов
- •Выражения в выборках
- •Отбор записей
- •Порядок вывода данных
- •Котов Кузьма Кузьмич
- •Группировка данных
- •Отбор данных для групп
- •4.2.10 Директива compute
- •Выборка данных из нескольких таблиц
- •Объединение с помощью предложения where
- •Внутреннее объединение
- •4.2.14 Объединение и опция join
- •Оператор union
- •Подзапросы и структурированные запросы
- •Создание таблицы на основе выборки
- •Предложение for browse
- •4.3 Модификация данных
- •Добавление данных
- •Изменение данных
- •Удаление строк
- •Управляющие конструкции
- •Создание таблиц базы данных
- •4.6 Транзакции и блокировки
- •4.6.1 Понятие транзакций и блокировок
- •Управление транзакциями
- •Явные транзакции
- •Автоматические транзакции
- •Неявные транзакции
- •Управление блокировками
- •4.7 Хранимые процедуры
- •4.7.1 Типы хранимых процедур
- •Создание хранимых процедур
- •4.8 Триггеры
- •Создание триггера
- •Ограничения при создании триггеров
- •Использование триггеров
- •Вопросы на повторение
- •4.10 Упражнения и задачи
- •4.11 Проекты и профессиональные вопросы
- •Заключение
- •Приложение а sql скрпит, для создания таблиц согласно модели бд "Университет"
- •Литература
Процесс нормализации таблиц
Среди целей проектирования баз данных наиболее важными представляются следующие:
возможность хранения в базе данных всех необходимых данных;
исключение избыточности данных;
сведение к минимуму числа хранимых в базе данных таблиц;
нормализация таблиц для упрощения решения проблем, связанных с обновлением и удалением данных.
Необходимость исключения избыточности не всегда очевидна начинающему проектировщику баз данных. Здесь следует различать дублирование данных и избыточное дублирование данных. Поясним это на примере. В таблице 2.1 содержатся данные о преподавателях университета.
Таблица 2.1 - Пример таблицы
Дисциплина |
Преподаватель |
Информационное обеспечение систем управления |
Гришин |
Базы данных и знаний |
Гришин |
Программирование и основы алгоритмизации |
Градусов |
Автоматизация проектирования систем и средств управления |
Градусов |
В этой таблице фамилии преподавателей появляются неоднократно, поскольку один преподаватель может читать лекции по нескольким предметам. Однако повторение фамилий в данном случае нельзя считать избыточным. Причина заключается в том, что при удалении повторяющихся фамилий теряется информация о том, кто ведет данный предмет.
Небольшое изменение этой таблицы приводит к появлению избыточного дублирования данных.
Таблица 2.2 - Пример избыточного дублирования данных
Дисциплина |
Преподаватель |
Должность |
Информационное обеспечение систем управления |
Гришин |
Доцент |
Базы данных и знаний |
Гришин |
Доцент |
Программирование и основы алгоритмизации |
Градусов |
Доцент |
Автоматизация проектирования систем и средств управления |
Градусов |
Доцент |
Исключение избыточности в данном случае можно исключить путем разбиения таблицы 2.2 на две таблицы: ДИСЦИПЛИНЫ И ПРЕПОДАВАТЕЛИ (таблица 2.1) и ПРЕПОДАВАТЕЛИ И ДОЛЖНОСТИ (таблица 2.3).
Таблица 2.3 - Преподаватели и должности
Преподаватель |
Должность |
Гришин |
Доцент |
Градусов |
Доцент |
Необходимость сведения к минимуму числа таблиц базы данных обусловлена тем, что разбиение одной таблицы на несколько таблиц меньшего размера полезно с точки зрения исключения определенных проблем (например, позволяет исключить избыточность данных). Однако это не совсем удобно для пользователя, поскольку при этом усложняется разработка пользовательских приложений, увеличивается время формирования отчетов.
Нормализация. Для большинства таблиц важны проблемы удаления и обновления данных, исключения избыточности данных. Эти проблемы могут решаться с помощью процесса нормализации посредством разбиения определенным образом исходной таблицы на несколько таблиц. В теории проектирования баз данных известны пять нормальных форм. Однако практическое значение имеют первые четыре нормальные формы, которые рассматриваются ниже.
Первая нормальная форма (1НФ) – это основа реляционной системы. При этом требуется, чтобы таблица была двумерной и не содержала ячеек, включающих несколько значений. Примером таблицы, которая не приведена к первой нормальной форме, служит таблица 2.4.
Таблица 2.4 - Пример ненормализованной таблицы.
Дисциплина |
Преподаватель |
Информационное обеспечение систем управления. Базы данных и знаний. |
Гришин
|
Программирование и основы алгоритмизации. Автоматизация проектирования систем и средств управления. |
Градусов
|
Ячейки столбца «дисциплина» этой таблицы содержат множественные значения. Приведение такой таблицы к 1НФ осуществляется путем разбиения строк таким образом, чтобы в ее ячейках не содержались множественные значения. В результате этого получим таблицу 2.1, являющейся таблицей в первой нормальной форме.
биения строк таким образом, чтобы в ее полях не содержались множест |
|
|
|
|
---|---|---|---|---|
|
|
|
|
|
Вторая нормальная форма (2НФ). Рассмотрим таблицу 2.5, которая является таблицей в первой нормальной форме. В таблице содержатся данные о работниках строительной фирмы.
Таблица 2.5 - Первая нормальная форма
Табельный номер рабочего |
Фамилия |
Специальность |
Табельный номер менеджера |
Номер объекта |
1234 |
Иванов |
Электрик |
2345 |
1 |
1234 |
Иванов |
Электрик |
2345 |
2 |
1235 |
Петров |
Плотник |
|
1 |
1235 |
Петров |
Плотник |
|
4 |
1235 |
Петров |
Плотник |
|
8 |
1236 |
Сидоров |
Маляр |
|
2 |
Приведенная таблица 2.5 спроектирована неудачно. Например, в трех записях, соответствующих рабочему с табельным номером 1235, повторяется одно и то же имя и информация о специальности. Эта избыточность данных приводит не только к увеличению объема требуемой памяти компьютера, но может вызвать и нарушение целостности данных в базе данных.
Проблема возникает из-за того, что один и тот же работник может работать в разных бригадах. Предположим, что специальность Петрова была указана неверно, а исправление было внесено только в первую запись. Тогда между записями, содержащими информацию о Петрове, возникает несоответствие, которое называется аномалией обновления.
Теперь предположим, что Петров длительное время был на больничном и все объекты были завершены. Принято решение удалить все записи таблицы, связанные с завершенными объектами. В этом случае информация о Петрове будет потеряна полностью. Это называется аномалией удаления. Рассмотрим обратный случай. Принят новый работник. Этот работник еще не получил назначения ни на один из объектов. Если пустые значения не допускаются в базе данных, то нельзя ввести информацию о новом работнике. Это называется аномалией ввода.
Чтобы избежать аномалий обновления, удаления и ввода, необходимо применить к таблице метод, называемый разбиением. Разбиение – это процесс разделения таблицы на несколько таблиц в целях избавления от аномалий и поддержания целостности данных.
Прежде, чем перейти к следующим нормальным формам, рассмотрим определение функциональной зависимости.
Функциональные зависимости. Функциональные зависимости (ФЗ) позволяют накладывать дополнительные ограничения на реляционную схему. Основная идея состоит в том, что значение одного атрибута в кортеже однозначно определяет значение другого атрибута. Например, в таблице РАБОТНИК атрибут ТАБЕЛЬНЫЙ НОМЕР однозначно определяют значение атрибутов СПЕЦИАЛЬНОСТЬ и ФИМИЛИЯ. Это можно записать следующим образом:
ТАБЕЛЬНЫЙ НОМЕР -> ФАМИЛИЯ,
ТАБЕЛЬНЫЙ НОМЕР -> СПЕЦИАЛЬНОСТЬ.
Атрибут в левой части ФЗ называется детерминантом, так как его значение определяет значение атрибута в правой части. Ключ таблицы является детерминантом, так как его значение однозначно определяет значение каждого атрибута таблицы.
Вторая нормальная форма. Реляционная таблица находится во второй нормальной форме (2НФ), если никакие неключевые атрибуты не являются функционально зависимыми лишь от части ключа. Следовательно, 2НФ может быть нарушена только в том случае, если ключ составной, то есть ключом является набор из нескольких атрибутов. В таблице РАБОТНИК ключ состоит из атрибутов ТАБЕЛЬНЫЙ НОМЕР и НОМЕР ОБЪЕКТА. При этом фамилия определяется атрибутом ТАБЕЛЬНЫЙ НОМЕР, то есть функционально зависит от части ключа. Эта таблица не удовлетворяет 2НФ. Если таблицу оставить в таком виде, то могут возникнуть следующие проблемы:
Имя работника повторяется в каждой строке, относящейся к назначению этого работника.
Если имя работника изменяется, то требуется обновить все строки, содержание информацию о назначениях этого работника.
Из-за избыточности может возникнуть несоответствие данных, когда в разных строках содержатся разные фамилии для одного и того же работника.
Если в какой-то момент времени работник не имеет назначений, то может отсутствовать строка, в которой хранится фамилий работника.
Для решения этих проблем таблицу необходимо разбить на две реляционные таблицы, каждая из которых удовлетворяет 2НФ:
НАЗНАЧЕНИЕ (ТАБЕЛЬНЫЙ НОМЕР, НОМЕР ОБЪЕКТА);
РАБОТНИК (ТАБЕЛЬНЫЙ НОМЕР, ФАМИЛИЯ, ТАБЕЛЬНЫЙ НОМЕР МЕНЕДЖЕРА.).
Внешним ключом является ТАБЕЛЬНЫЙ НОМЕР.
2НФ сокращает избыточность данных и несоответствия, но она может усложнить работу некоторых приложений, извлекающих данные.
Полученные таблицы меньшего размера называются проекциями исходной таблицы. Проекция таблицы – это таблица, состоящая из нескольких выбранных атрибутов другой таблицы.
Процесс разбиения на две таблицы во второй нормальной форме состоит из следующих шагов:
В исходной таблице выявляются атрибуты, зависящие от части ключа. Создается новая таблица, атрибутами которой будут атрибуты исходной таблицы, входящие в противоречащую правилу ФЗ. Детерминант ФЗ становится ключом новой таблицы.
Атрибут, стоящий в правой части ФЗ, исключается из исходной таблицы
Если более одной ФЗ нарушают 2НФ, то шаги 1 и 2 повторяются для каждой такой ФЗ.
Если один и тот же детерминант входит в несколько ФЗ, то все функционально зависящие от него атрибуты помещаются в качестве неключевых атрибутов в таблицу, ключом которой будет детерминант.
Третья нормальная форма. Реляционная таблица имеет третью нормальную форму (3НФ), если для любой функциональной зависимости X->Y X является ключом. Из определения следует, что любая таблица, удовлетворяющая 3НФ, также удовлетворяет и 2НФ.
Рассмотрим таблицу РАБОТНИК (ТАБЕЛЬНЫЙ НОМЕР, СПЕЦИАЛЬНОСТЬ, ПРЕМИЯ). Полагаем, что размер премиальных зависит от специальности. В этом случае имеют место следующие ФЗ:
ТАБЕЛЬНЫЙ НОМЕР -> СПЕЦИАЛЬНОСТЬ,
ТАБЕЛЬНЫЙ НОМЕР -> ПРЕМИЯ,
СПЕЦИАЛЬНОСТЬ -> ПРЕМИЯ.
Первые две ФЗ удовлетворяют критерию 3НФ. В третьей ФЗ атрибут СПЕЦИАЛЬНОСТЬ не является ключом. Следовательно, критерий 3НФ нарушен. В то же время таблица удовлетворяет 2НФ, так как ключ состоит из одного атрибута. Рассмотрим недостатки, присущие таблицам, не удовлетворяющим 3НФ:
Размер премиальных для вида специальности повторяется в каждой строке, относящейся к работнику этой специальности. Это избыточные данные.
Если размер премиальных для вида специальности изменяется, то нужно обновить все строки, содержащие эту специальность. Если строка удаляется, то можно потерять информацию о размере премиальных для данной специальности. Следовательно, таблица подвержена аномалиям обновления и удаления.
Если в какой-то момент времени отсутствуют работники данной специальности, то может не оказаться строки, в которой можно хранить размер премиальных. Это аномалия ввода.
Для приведения таблицы к 3НФ воспользуемся методом разбиения. Разобьем таблицу РАБОТНИК на две таблицы: Т1 (ТАБЕЛЬНЫЙ НОМЕР, СПЕЦИАЛЬНОСТЬ) и Т2 (СПЕЦИАЛЬНОСТЬ, ПРЕМИЯ). Внешним ключом является СПЕЦИАЛЬНОСТЬ. Если хотя бы одна из полученных таблиц нарушает 3НФ, то процесс разбиения продолжается.
ЧЕТВЕРТАЯ НОРМАЛЬНАЯ ФОРМА. Первая нормальная форма запрещает таблицам иметь неатомарные (многозначные) атрибуты. Однако на практике существует множество ситуаций моделирования, требующих многозначных атрибутов. Например, преподаватель университета может вести несколько предметов и работать в нескольких комиссиях (таблица 2.6).
Таблица 2.6 - Таблица с многозначными атрибутами
Фамилия |
Комиссия |
Предмет |
Иванов |
Государственная аттестационная |
|
Иванов |
Приемная |
|
Иванов |
|
Информатика |
Иванов |
|
Базы данных |
Иванов |
|
Программирование |
В таблице 2.6 показан подход к решению проблемы участия преподавателя в комиссиях и ведения предметов. Здесь имеют место пустые значения атрибутов, что нарушает категорную целостность, поскольку все атрибуты вместе составляют ключ таблицы. Кроме того, очевидно, что атрибуты КОМИССИЯ и ПРЕДМЕТ не зависят друг от друга. Устранить это можно следующим образом. Потребуем, чтобы каждое значение атрибута КОМИССИЯ сочеталось с каждым значением атрибута ПРЕДМЕТ как минимум в одной строке (таблица 2.7).
Таблица 2.7 – Таблица с многозначной зависимостью атрибутов
Фамилия |
Комиссия |
Предмет |
Иванов |
Государственная аттестационная |
Информатика |
Иванов |
Государственная аттестационная |
Базы данных |
Иванов |
Государственная аттестационная |
Программирование |
Иванов |
Приемная |
Информатика |
Иванов |
Приемная |
Базы данных |
Иванов |
Приемная |
Программирование |
Условие, обеспечивающее независимость атрибутов путем обязательного повторения значений, называется многозначной зависимостью (МЗЗ). МЗЗ является таким же ограничительным условием, как и ФЗ. Недостатком таблицы 2.7 является большое число повторений значений данных. Поэтому важным этапом процесса нормализации является избавление от многозначных зависимостей.
Таблица имеет четвертую нормальную форму (4НФ), если она имеет 3НФ и не содержит многозначных зависимостей. Так как проблема многозначных зависимостей возникает в связи с многозначными атрибутами, то можно решить эту проблему, поместив каждый многозначный атрибут в отдельную таблицу вместе с ключом, от которого атрибут зависит. В нашем примере таблица может быть разбита на две таблицы: КОМИССИЯ (ФАМИЛИЯ, КОМИССИЯ) и ПРЕДМЕТ (ФАМИЛИЯ, ПРЕДМЕТ). Ключом каждой полученной таблицы 4НФ являются оба атрибута таблицы.
Другие нормальные формы. Для избавления от некоторых других аномалий были предложены еще несколько нормальных форм. Но эти нормальные формы имеют в основном теоретический интерес и сомнительную практическую ценность. Поэтому в рамках настоящих методических указаний их рассматривать не будем.