1. Основные понятия реляционных баз данных
База данных (БД) – это средство накопления и организации больших массивов информации об объектах некоторой предметной области (ПО). БД является частью сложной системы, называемой банком данных или системой баз данных (СБД). Эта система включает в себя собственно БД, программные, технические, языковые и организационно-методические средства, обеспечивающие централизованное накопление и коллективное многоцелевое использование данных. Компонентой СБД является система управления БД (СУБД) представляет собой совокупность языковых и программных средств, с помощью которых создается и поддерживается БД.
Одним из наиболее важных этапов жизненного цикла БД является этап проектирования. Главная задача, которая решается в процессе проектирования, – это организация данных. Способ организации данных определяется логической моделью. Различные формы представления связей между объектами породили различные логические модели – иерархическую, сетевую, реляционную. Наибольшей популярностью пользуется реляционная модель данных (РМД) в силу ее простоты и математической обоснованности. Большинство СУБД поддерживают эту модель.
Реляционная база данных (РБД) представляет собой совокупность отношений. Отношением называется любая взаимосвязь между объектами и их свойствами. Отношение задается именем и списком атрибутов. Имя отношения выбирается так, чтобы оно поясняло смысл связи между элементами отношения. Для описания некоторого свойства объекта или связи используется неделимый элемент данных, называемый атрибутом. Атрибут характеризуется именем, типом и значением. Список имен атрибутов отношения и их характеристик называют схемой отношения. Атрибут или набор атрибутов, которые могут быть использованы для однозначной идентификации конкретного экземпляра отношения (кортежа), называется первичным ключом отношения или ключом.
База данных о поставке деталей может быть описана следующими отношениями (первичные ключи подчеркнуты, для отношения Поставка деталей первичный ключ является составным):
Деталь (Номер детали, Название детали, Материал, Вес),
Поставщик (Код поставщика, Фамилия, Город),
Поставка деталей (Код поставщика, Номер детали, Количество).
Ограничения на значения атрибутов могут быть заданы типом данных для соответствующего атрибута.
Другая форма представления отношения – табличная. Каждому отношению соответствует таблица, атрибуту – столбец таблицы, кортежу отношения – строка таблицы. Строка таблицы часто называется записью, а значение атрибута – полем записи. Отношения БД о поставке деталей могут быть описаны таблицами 1–3.
Таблица 1
Деталь
Номер детали |
Название детали |
Материал |
Вес |
101 |
Болт |
Сталь |
16 |
102 |
Муфта |
Алюминий |
90 |
Таблица 2
Поставщик
Код поставщика |
Фамилия |
Город |
П1 |
Иванов |
Ярцево |
П2 |
Алексин |
Курск |
Таблица 3
Поставка деталей
Код поставщика |
Номер детали |
Количество |
П1 |
102 |
400 |
П2 |
101 |
600 |
В ходе разработки РБД должен быть определен состав реляционных таблиц и состав атрибутов каждого отношения с указанием ограничений на их допустимые значения. Состав атрибутов должен отвечать требованиям нормализации.
Существует несколько нормальных форм реляционной модели данных, которые позволяют исключить избыточное дублирование данных, обеспечить целостность и непротиворечивость данных.
При первой нормальной форме (1НФ) все атрибуты отношения должны быть простыми (атомарными, неделимыми) с точки зрения СУБД.
Нормальные формы более высокого порядка основаны на понятии функциональной зависимости (ФЗ), которая может быть определена следующим образом. Пусть А и В – атрибуты отношения. Говорят, что В функционально зависит от А (А→В), если для каждого значения А существует ровно одно связанное значение В. ФЗ можно выявить, анализируя базовые свойства атрибутов.
При второй нормальной форме (2НФ) отношение находится в 1НФ и каждый неключевой атрибут функционально полно зависит от ключа. Полная ФЗ от ключа означает, что если ключ составной, то любой неключевой атрибут зависит от всего ключа и не зависит ни от какой его части.
При третьей нормальной форме (3НФ) отношение находится во 2НФ и отсутствуют ФЗ между неключевыми атрибутами.
Нормальная форма Бойса-Кодда (НФБК) является развитием 3НФ и требует, чтобы в отношении были только такие ФЗ, левые части которых (детерминанты) являются потенциальными ключами отношения. Потенциальным ключом называется подмножество атрибутов, удовлетворяющее определению первичного ключа отношения. Первичный ключ – это один из потенциальных ключей. Поясним эти определения на примере БД Успеваемость студентов общежития. БД состоит из отношения, в котором представлена информация о студентах, проживающих в общежитии, и их оценках по изучаемым дисциплинам в различных семестрах:
Студент (Сном, Сфам, Кном, Тном, Дисциплина, Семестр, Оценка).
Основные атрибуты отношения: Сном – номер зачетной книжки студента; Сфам – фамилия студента; Кном – номер комнаты; Тном – номер телефона в комнате; Дисциплина; Семестр; Оценка. Диаграмма на рис. 1 отражает ФЗ между атрибутами отношения: Сном→Сфам, Сном→Кном, Сном→Тном, Кном→Тном, Тном→Кном, <Сном, Дисциплина, Семестр>→Оценка.
Рис. 1. Диаграмма ФЗ отношения Студент
В отношении студент один потенциальный ключ <Сном, Дисциплина, Семестр>. Детерминантами являются: <Сном, Дисциплина, Семестр>, Сном, Кном, Тном. Это отношение не находится в НФБК, так как детерминанты Сном, Кном, Тном не являются потенциальными ключами. Для приведения отношения к НФБК его следует разбить на три отношения:
Студент (Сном, Сфам, Кном),
Успеваемость (Сном, Дисциплина, Семестр, Оценка),
Телефон (Кном, Тном).
Каждое из этих отношений находится в НФБК, так как в них все детерминанты являются потенциальными ключами.
Большинство аномалий в БД будет устранено в случае приведения каждого отношения в НФБК. Существуют нормальные формы более высокого уровня, но на практике в большинстве случаев достаточно получить отношения в НФБК.
Логические ограничения, накладываемые на данные, называются ограничениями целостности. Ограничения используются для поддержания целостности данных при функционировании системы. То есть СУБД должна контролировать соответствие данных ограничениям при переводе БД из одного состояния в другое. Выделяют два основных вида ограничений: внутренние и явные.
Внутренние – это ограничения, свойственные модели данных. Они накладываются на структуру отношений, на связи, на допустимые значения наборов данных, заложенные в выбранной модели данных.
Явные ограничения – это ограничения, задаваемые семантикой ПО. Они описывают области допустимых значений атрибутов, динамику их изменения и т. д.
В РМД существует два вида внутренних ограничений целостности:
1. Целостность по существованию – потенциальный ключ отношения не может иметь пустого значения (NULL).
2. Целостность по связи – определяется понятием внешнего ключа, связывающего отношения. Означает систему правил для поддержания связей между записями в связанных таблицах. Обеспечивает защиту от случайного изменения связанных данных и некорректного изменения ключевых полей.
Способы реализации внутренних ограничений целостности зависят от СУБД.
Реляционные модели обеспечивают простоту представления данных, минимальную избыточность данных при нормализации отношений, независимость приложений пользователя от данных. Однако нормализация данных приводит к их значительной фрагментации, в то время как в большинстве задач необходимо объединение фрагментированных данных.