12. Реляционная модель данных. Понятие отношения. Функциональные зависимости и ключи.
Реляционная модель и нормализация
Реляционная модель данных
После построения логической модели данных (например, в виде ER-диаграммы), можно преобразовать ее в физическую модель данных. Физическая модель данных описывает данные средствами конкретной СУБД. Сегодня большинство СУБД основано на реляционной модели.
Реляционная база данных - это база данных, логическая структура которой состоит только из отношений.
Для одной и той же предметной области реляционные отношения можно спроектировать множеством различных способов. Например, можно спроектировать несколько отношений с большим количеством атрибутов, или наоборот, разнести все атрибуты по большому числу мелких отношений.
Нормализацией называется процесс получения “хороших” отношений.
Понятие отношения
Отношение - это двумерная таблица. Каждая строка в таблице содержит данные, относящиеся к некоторой вещи. Каждый столбец таблицы описывает какой-либо атрибут этой вещи. Строки называются кортежами или записями, а столбцы - атрибутами или полями.
Чтобы таблица была отношением, она должна удовлетворять следующим ограничениям:
1. Значения в ячейках таблицы должны быть одиночными - ни повторяющиеся группы, ни массивы не допускаются.
2. Каждый столбец в таблице имеет уникальное имя.
3. Все данные в столбце должны быть одного типа.
4. Порядок столбцов в таблице несущественен.
5. В таблице не может быть двух одинаковых строк.
6. Порядок строк не имеет значения.
При наличии любой группы сущностей и атрибутов имеется большое число способов их объединения в отношения. Не любые отношения являются одинаково желательными.
Функциональные зависимости
Функциональная зависимость - это связь между атрибутами. Атрибут Y функционально зависит от атрибута X, если значение X определяет значение Y. Другими словами, если нам известно значение X, мы можем определить значение Y.
Например, если мы знаем цену и количество приобретенного товара, мы можем определить стоимость покупки по формуле: Стоимость = Цена * Количество. В этом случае можно сказать, что атрибут Стоимость функционально зависит от атрибутов Цена и Количество. Функциональные зависимости между атрибутами в отношении обычно не выражаются уравнениями.
Пусть, например, каждому студенту присвоен уникальный номер, и каждый студент обучается только на одной специальности. Имея номер студента, мы можем узнать его специальность, поэтому атрибут Специальность функционально зависит от атрибута НомерСтудента. В отличие от случая с уравнением, эта функциональная зависимость хранится в базе данных.
В функциональные зависимости могут быть вовлечены группы атрибутов. Рассмотрим отношение ОЦЕНКИ (НомерСтудента, Дисциплина, Оценка). Комбинация номера студента и дисциплины определяет оценку.
Функциональные зависимости обозначаются следующим образом:
НомерСтудента -> Специальность;
(НомерСтудента, Дисциплина) -> Оценка.
Атрибуты слева от стрелки называются детерминантами.
Ключи
Ключ - это группа из одного или нескольких атрибутов, которая уникальным образом идентифицирует строку.
Рассмотрим отношение СЕКЦИЯ, имеющее атрибуты НомерСтудента, СЕКЦИЯ и ПЛАТА.
| НомерСтудента | Секция | Плата |
| Лыжи | ||
| Плавание | ||
| Бокс | ||
| Плавание |
Строка этого отношения содержит информацию о том, что студент посещает определенную секцию за определенную плату.
Предположим, что студент одновременно не может посещать более одной секции. В этом случае атрибут НомерСтудента является ключом.
Ключи могут состоять из нескольких атрибутов. Например, если студентам разрешено одновременно посещать более одной секции, то один и тот же номер студента может появиться в разных строках таблицы, поэтому для указания на строку потребуется сочетание атрибутов, например, комбинация (НомерСтудента, Секция).
Являются ли атрибуты ключами определяется не какими-то абстрактными правилами, а моделями, присутствующими в воображении пользователей (как и предположения о функциональных зависимостях, ограничениях и тому подобных вещах).
Каждое отношение имеет минимум один ключ (в крайнем случае ключ будет состоять из всех атрибутов отношения).
13. Нормализация. Аномалии модификации. Суть нормализации.
Нормализация
Таблица, отвечающая минимальному определению отношения может иметь неэффективную или неподходящую структуру. Для некоторых отношений изменение данных может привести к нежелательным последствиям, называемым аномалиям модификации. Аномалии могут быть устранены путем разбиения исходного отношения на два или более новых отношений.
Аномалии модификации
Рассмотрим опять отношение СЕКЦИЯ. Если мы удалим строку о студенте номер 100, мы потеряем не только информацию, что студент с номером 100 является лыжником, но и тот факт, что абонемент в секцию лыж стоит 200р. Это называется аномалией удаления - удаляя факты, относящиеся к одной сущности (студент с номером 100 является лыжником), мы удаляем факты относящиеся к другой сущности (плата в секции лыж составляет 200р.). Выполняя одну операцию удаления, мы теряем информацию о двух сущностях.
На примере того же отношения рассмотрим теперь аномалию вставки. Предположим, что мы хотим записать в базу данных тот факт, что абонемент в секцию подводного плавания стоит 175р. Мы не можем ввести эти данные в отношение СЕКЦИЯ, пока хотя бы один студент не запишется в секцию подводного плавания. Это выглядит глупо. Суть аномалии вставки в том, что мы не можем записать в таблицу некоторый факт об одной сущности, не указав дополнительно некоторый факт о другой сущности.
Рассмотренное отношение может быть использовано, но оно имеет явные проблемы. Можно устранить как аномалию вставки, так и аномалию удаления, разделив отношения СЕКЦИЯ на два отношения, каждое из которых будет содержать информацию на определенную тему.
Теперь, если мы удалим запись о студенте с номером 100 из таблицы СТУДЕНТ‑СЕКЦИЯ, мы уже не потеряем тот факт, что абонемент в секцию лыж стоит 200р. Теперь можно добавить в таблицу СЕКЦИЯ‑ПЛАТА секцию подводного плавания с указанием стоимости абонемента, не дожидаясь, пока кто-либо запишется в эту секцию. Таким образом, аномалии удаления и вставки устранены.
Предположим, что студент хочет записаться в несуществующую секцию. Например, студент с номером 250 хочет записаться в секцию городки. Мы можем вставить соответствующую строку в отношение СТУДЕНТ‑СЕКЦИЯ, но следует ли это делать? Должна ли система препятствовать добавлению строк в таблицу СТУДЕНТ‑СЕКЦИЯ, если название соответствующей секции отсутствует в таблице СЕКЦИЯ‑ПЛАТА? Ответ на этот вопрос содержится в требованиях пользователя.
Суть нормализации
Аномалии, присутствующие в примере возникают из-за того, что отношение СЕКЦИЯ содержит факты, относящиеся к двум различным темам:
1. Кто из студентов какую секцию посещает.
2. Какова плата за абонемент в каждой из секций.
Каждое нормализованное отношение имеет одну-единственную тему. Любое отношение, содержащее две или более темы, следует разбить на два или более отношения, каждое из которых будет содержать одну тему. Этот процесс составляет суть нормализации.
Всякий раз, когда мы разбиваем отношение, мы, возможно, порождаем ограничение ссылочной целостности.
14. Нормальные формы (1НФ, 2НФ, 3НФ).
Нормальные формы
Теоретические правила, которым отвечает структура отношения, называются нормальными формами. С возрастанием порядкового номера нормальной формы набор правил постоянно усложняется. В теории, чем выше номер нормальной формы, тем лучше структура отношения.
