В реляционной базе данных

В терминологии реляционных баз данных таблицы называют отношениями – ведь, включая в записи таблицы определенные поля, мы устанавливаем отношения между информационными объектами. Поскольку одни и те же данные можно по-разному сгруппировать в таблицы, то требуются некоторые правила, оптимизирующие группировку полей - свойств объектов. Такие правила были сформулированы применительно к реляционным базам данных. Это правила нормализации отношений.

Нормализация отношений – формальный аппарат ограничений на формирование отношений (таблиц), который позволяет устранить дублирование, обеспечивает непротиворечивость хранимых данных, уменьшает трудозатраты на их ввод и корректировку. И.Ф.Коддом выделены три нормальные формы отношений и предложены методы преобразования отношений к третьей, самой совершенной нормальной форме.

Отношение считается нормализованным, или приведенным к первой нормальной форме, если все его атрибуты (свойства объектов, описываемые в полях записей) простые, т.е. далее неделимы. Отношение Организации (см. подраздел 9.1) можно считать приведенным к первой нормальной форме. Единственный его атрибут, который теоретически еще можно разделить на части, - это Адрес. Но практически этот атрибут уже не делим, так как улица и дом, где расположена каждая организация, нам не могут потребоваться в отдельности. А такие атрибуты, как Город, уже отделены от адреса. Так что, если нам потребуется какая-нибудь сводка по организациям-подрядчикам, расположенным в определенном городе, то мы легко сможем отобрать соответствующие записи.

Отношение находится во второй нормальной форме, если оно приведено к первой нормальной форме, и его каждый неключевой атрибут функционально зависит от ключа. Функциональная зависимость от ключа означает, что в экземпляре информационного объекта (в записи таблицы) конкретному значению ключа соответствует определенное значение описательного атрибута. Так, в таблице Затраты нашего примера коду (например, номеру) каждой затраты соответствует ее название, код объекта, в который вложены средства, коды вида работ и организации-подрядчика, дата и сумма платежа. Перечисленные атрибуты функционально зависят от ключа Код затр. Если бы ключ был составным, то для приведения отношения ко второй нормальной форме потребовалась бы функционально полная зависимость атрибутов от ключа. Она заключается в том, что каждый неключевой атрибут функционально зависит от ключа, но не находится в функциональной зависимости ни от какой части составного ключа.

Понятие третьей нормальной формы основывается на понятии нетранзитивной зависимости [3]. Транзитивная зависимость наблюдается, если один из атрибутов зависит от ключа, а другой – от этого атрибута. Например, если в таблицу Затраты включить не только код организации, но и город, в котором она расположена, то получится, что атрибут Код орг функционально зависит от ключа Код затр, а атрибут Город зависит, в свою очередь, от атрибута Код орг и, следовательно, транзитивно зависит от ключа. Отношение находится в третьей нормальной форме, если оно находится во второй нормальной форме, и каждый неключевой атрибут нетранзитивно зависит от первичного ключа. Если бы мы включили в записи таблицы Затраты не только код организации-подрядчика, но и ее атрибуты (название, адрес и др.), то отношение уже не находилось бы в третьей нормальной форме, а это резко осложнило бы работу с базой данных. Во-первых, во все записи таблицы Затраты, где в качестве подрядчика выступает эта организация, пришлось бы вводить не только ее код, но и длинные названия, дублируя их многократно. Во-вторых, в случае изменения адреса, факса или другой характеристики организации пришлось бы вносить коррективы не в единственную запись таблицы Организации, а во множество записей таблицы Затраты.

Приведенный пример показывает, что, казалось бы, теоретическое понятие нормализации отношений играет важную практическую роль, позволяя устранить дублирование данных, облегчить их ввод и корректировку в базе данных. Другое важное понятие – обеспечение целостности данных в базе данных. Этот термин подразумевает, что в СУБД должны иметься средства, не позволяющие нарушать корректность и полноту хранимой информации. Например, СУБД обычно содержат средства поддержания ссылочной целостности. Так, если мы попытаемся в запись таблицы Затраты ввести код объекта 777, а в таблице Объекты еще нет объекта с кодом 777, то СУБД должна воспрепятствовать нашему намерению, если, конечно, мы выбрали соответствующий режим ее работы. Кроме того, когда мы вводим новую запись, СУБД проверяет уникальность ее ключа, обеспечивая целостность таблицы. Наконец, СУБД проверяет целостность домена. Домен – это множество допустимых значений столбца. Так в столбец Код орг могут входить только целые числа. Если при вводе записи введем в поле Код орг хотя бы одну букву или действительное число, запись не будет включена в таблицу.

Дальнейшее изложение ориентировано на изучение возможностей СУБД Access, но прежде приведем схему [3] обобщенной технологии работы с СУБД (рис. 9.1).

Рис. 9.1. Схема обобщенной технологии работы с СУБД

Поиск по сайту: