7.4.2. Реляционный подход к управлению бд
Все СУБД ориентированы на хранение и обработку информации, но существуют различные подходы к реализации этой задачи.
Реляционный подход к управлению БД основан на математической модели, использующей методы реляционной алгебры и реляционного исчисления. При использовании этого подхода основными свойствами СУБД являются следующие:
– вся информация в БД представлена в виде таблиц;
– поддерживается три реляционных оператора – выбора, проектирования и объединения, с помощью которых можно получить все необходимые данные.
Определение реляционной модели включает ряд фундаментальных правил.
Каждая таблица поименована, состоит из строк и столбцов. Каждая строка описывает объект или сущность. Каждый столбец описывает одну характеристику (атрибут) объекта, его свойство.
Атрибут – это информационное отображение отдельного свойства некоторого объекта. Атрибут характеризуется именем и значением. Имя используется в качестве условного обозначения при обработке данных. Значение атрибута – это величина, характеризующая некоторое свойство объекта при конкретных обстоятельствах. Каждое значение принадлежит определенному типу (число, текст и т.п.).
Отношение (relation), или таблица, определяется как множество упорядоченных строк (хотя упорядочение строк несущественно, оно может повлиять только на эффективность доступа). Реляционные таблицы выражают отношение и состоят из строк и столбцов, удовлетворяющих следующим условиям: имена столбцов уникальны, нет повторяющихся строк, нет повторяющихся групп данных.
Отношение называется нормализованным, если каждый компонент строки является простым (атомарным, не состоящим из группы значений) значением. Это не позволяет заменять значение атрибута другим отношением (это привело бы к сетевому или иерархическому представлению).
Если взять описание данных о клиентах фирмы, занимающейся поставками товаров в магазины города, из приведенного выше примера, представленное следующим образом
то данные, описанные этой таблицей, не могут в таком виде быть представлены в реляционной БД, так как не все значения являются атомарными (компоненты строк «Владелец» и «Адрес» состоят из нескольких значений, т.е. значения этих атрибутов заменяются другими отношениями, расшифровываются ими, в отношении, описывающем владельца, поля «Адрес» и «Паспорт» также не являются атомарными, следовательно, строится иерархия отношений).
Для создания реляционной БД, в которой хранилась бы описанная выше информация, необходимо выполнить ее проектирование, целью которого является определение структуры БД в соответствии с требованиями, предъявляемыми к реляционным БД. Этот процесс очень важен, так как ошибки в проектировании могут привести не только к неэффективной обработке данных, хранящихся в БД, но и к искажению данных, к нарушению их целостности. Более подробно процесс проектирования описан ниже.
В отношении могут существовать несколько одиночных или составных атрибутов, которые однозначно идентифицируют каждую строку таблицы. Такие атрибуты называют ключами. Один из них выбирается в качестве первичного ключа.
Каждый элемент данных (значение атрибута объекта) определяется пересечением строки и столбца. Чтобы найти нужный элемент, необходимо указать имя содержащей его таблицы, значение первичного ключа строки (или ее уникального идентификатора) и столбец, содержащий этот атрибут.
Для упорядочения записей в таблице по значениям выбранного поля или нескольких полей используются индексы, добавляемые к таблицам. Каждой таблице может соответствовать несколько индексов, позволяющих выполнять быстрый поиск данных (используется специальный алгоритм быстрого поиска, например, двоичный поиск) в таблице по различным ключам. Фактически данные в таблице хранятся в неупорядоченном виде (в порядке записи), а упорядоченными являются только индексы.
Данные, хранящиеся в различных таблицах, взаимосвязаны. Поэтому при создании БД в ней размещаются не только сами таблицы, но и сохраняются существующие между ними связи (отношения). Создавать и запоминать связи в БД необязательно, но их использование гарантирует получение правильных результатов при выполнении сложных запросов.
Существуют различные типы отношений:
Один-ко-многим (1:N): единственной записи в первой таблице может соответствовать несколько записей во второй таблице (например, если в первой таблице хранится информация об издательствах, а во второй – о выпущенных ими книгах, то, поскольку каждое издательство может выпустить множество книг, между этими данными существует отношение 1:N ).
Многие-ко-многим (N:N): записям в первой таблице может соответствовать несколько записей во второй и наоборот – каждой записи из второй таблицы может соответствовать множество записей в первой таблице (например, если в одной таблице хранится информация об авторах книг, а в другой – информация о книгах, то, поскольку каждый автор может написать несколько книг, а у каждой книги может быть несколько авторов, между этими таблицами существует связь N:N).
Один-к-одному (1:1): каждой записи в одной таблице соответствует одна запись во второй (эти данные могли бы размещаться в одной таблице, их размещают в различных таблицах обычно только с целью ускорения доступа к ним; например, редко используемые при запросах данные можно вынести в отдельную таблицу, чтобы не обрабатывать их при выполнении каждого запроса).
Реализовать отношение «один-ко-многим» можно, добавив во вторую таблицу внешний ключ, идентифицирующий соответствующую строку в первой таблице. Это обеспечивает минимальную избыточность данных. Внешний ключ – это столбец или комбинация столбцов в таблице, значение которого(ых) совпадает со значением первичного ключа в другой таблице.
Для описания отношения «многие-ко-многим» в БД строится отдельная таблица, описывающая связи между первой и второй таблицами. Вместо объектов такая таблица описывает связи между ними. Она содержит в каждой записи внешние ключи, идентифицирующие взаимосвязанные записи в исходных таблицах.
Таким образом, в реляционных БД есть два типа таблиц: пользовательские (они содержат собственно информацию) и системные (содержат описание самой БД, служебную информацию). Системные таблицы обычно поддерживаются самой СУБД.
Данные объединяются в БД с целью адекватного отображения изменяющегося реального мира, поэтому кроме собственно данных в БД могут храниться специальные процедуры, описывающие алгоритмы функционирования соответствующих объектов. Использование таких процедур позволяет «активизировать» БД, заставить выполняться описанные в них действия автоматически при изменении состояния объектов, которым они приписаны, контролировать изменения информации.
Процесс, в ходе которого решается, какой будет структура создаваемой БД, называется проектированием. Эта работа включает определение набора таблиц, которые будут входить в БД; столбцов, принадлежащих каждой таблице; ключевых атрибутов индексов; взаимосвязей между таблицами и столбцами.
При работе с БД в данных может возникнуть несогласованность по ряду причин: вследствие сбоя, ошибки в программе, некорректного проектирования и т.п. В этом случае говорят о нарушении целостности данных. Данные должны быть защищены от такого рода разрушений. Целостность в первую очередь обеспечивается при проектировании БД. Хорошая структура БД максимально упрощает взаимодействие с ней, гарантирует согласованность данных.
При проектировании БД могут быть приняты различные решения, но существуют базовые требования, которые должны учитываться в процессе работы:
– множество отношений должно обеспечивать минимальную избыточность представления информации;
– манипулирование данными, корректировка отношений не должна приводить к нарушению целостности данных, двусмысленности и потере информации;
– перестройка набора отношений при добавлении в БД новых атрибутов должна быть минимальной.
Описание реальных объектов и взаимосвязей между ними во многом носит субъективный характер, но есть определенные общие правила, в частности, правила нормализации.
В ходе нормализации обеспечивается защита целостности данных путем устранения дублирования данных. В результате представление данных об одном объекте может быть разбито на несколько более мелких связанных таблиц (декомпозиция без потерь).
Ограничения, которые должны соблюдаться при проектировании реляционной БД, достаточно многочисленны. Соблюдение ограничений при определении конкретных отношений в БД связано с реализацией так называемых нормальных форм. Нормальные формы нумеруются последовательно, начиная от первой. Чем больше номер нормальной формы, тем больше ограничений на хранимые в БД данные должно соблюдаться. Можно к типичным для реляционных СУБД ограничениям ввести дополнительный набор ограничений, что приведет к увеличению числа нормальных форм.
Нормальная форма представляет собой определенный стандарт. Обычно рассматривают до пяти нормальных форм. Так как каждая следующая нормальная форма предусматривает дополнительные ограничения, нормализация выполняется в порядке возрастания этих требований – от первой нормальной формы и до пятой.
В плохо спроектированной БД вся информация может храниться в одной таблице. Для описанного выше примера такая таблица могла бы содержать следующие столбцы:
– «Название магазина»,
– «ИНН»,
– «Телефон»,
– «Улица магазина»,
– «Дом магазина»,
– «Офис»,
– «Фамилия»,
– «Имя»,
– «Отчество»,
– «Год рождения»,
– «Улица владельца»,
– «Дом владельца»,
– «Квартира»,
– «Серия»,
– «Номер»,
– «Банк»,
– «Номер счета»,
– «Код по ОКОНХ»,
– «Код по ОКПО».
Компоненты адреса «Улица» и «Дом» переименованы, поскольку имена столбцов в реляционной таблице должны быть уникальны (правила именования зависят от конкретной СУБД).
Какие недостатки имеет такое представление?
Первая нормальная форма требует, чтобы на любом пересечении строки и столбца находилось единственное значение, которое должно быть неделимо (требование атомарности). Кроме того, в реляционной таблице не должно быть повторяющихся строк и групп данных.
Требование атомарности выполнено – составные столбцы «Адрес» и «Владелец» (а для владельца «Адрес» и «Паспорт») разбиты на компоненты, которые включены в общую таблицу. Но у одного магазина может быть несколько владельцев, а один человек может владеть несколькими магазинами. Это приводит к тому, что в таблицу нужно будет включать все строки, представляющие «комбинации» магазинов и их владельцев, т.е. в различных строках будут повторяться группы данных (несколько раз будут повторяться данные о магазине – для каждого его владельца, а данные владельца будут повторяться для каждого его магазина). Такое представление данных ведет к огромной избыточности, к тому, что неэффективно будет расходоваться память на ВЗУ. Кроме того, дублирование информации может привести к проблемам при ее обработке: чтобы внести изменения в информацию о магазине (например, если у него изменится счет в банке) нужно изменить эти данные в нескольких записях, соответствующих разным владельцам.
При определении того, какие таблицы должны входить в БД, и того, какая информация в них должна храниться, следует учитывать следующее правило: каждая таблица описывает объект, существующий самостоятельно, обладающий собственными свойствами. Построение БД следует начать с создания представления каждого объекта в виде строк, содержащих его атрибуты, в соответствующей таблице; определения моделей взаимосвязи объектов.
В рассматриваемом примере в БД фактически должна храниться информация об объектах двух типов: о магазинах и об их владельцах. Эту информацию следует поместить в две различные таблицы («Магазины» и «Владельцы»), имеющие следующие столбцы: