Связи. 
Экономическая информатика

Связи между объектами представляются в реляционной модели связями между таблицами по значениям ключевых атрибутов.

Связь один-ко-многим означает, что для одной записи с некоторым значением первичного ключа одной таблицы может существовать 0, 1 или более записей с тем же значением соответствующего поля в другой таблице.

На рис. 3.6 показана связь один-ко-многим между таблицами Покупатель и Заказ по столбцу Код покупателя. В таблице Покупатель для наглядности приведены первые три поля отношения Покупатель. Первичные ключи таблиц здесь выделены жирным шрифтом. Каждой строке таблицы Покупатель должны соответствовать одна или несколько строк таблицы Заказ с тем же значением атрибута Код покупателя. Во взаимоотношении этих таблиц первую таблицу можно назвать главной, а вторую — подчиненной.

Рис. 3.6. Связь таблиц Покупатель и Заказ

Атрибут подчиненной таблицы, по которому осуществляется связь, называется внешним ключом главной таблицы.

В данном случае внешним ключом таблицы Покупатель во взаимосвязи Покупатель — Заказ является атрибут Код покупателя таблицы Заказ.

В чем же состоят характерные особенности реляционных СУБД, которые должны обеспечить управление совокупностью таких отношений, представляющих базу данных? Этими особенностями являются ненавигационность и обеспечение целостности.

Ненавигационность. При описании логической модели базы данных в реляционной СУБД описываются только таблицы, их атрибуты, первичные и внешние ключи. При выполнении запросов описываются условия, накладываемые на запрашиваемые данные, но не процесс поиска этих данных в таблицах. Процесс навигации по базе данных скрыт от пользователя и разработчика прикладных программ и должен выполняться средствами СУБД автоматически.

Требования целостности. Любая реляционная СУБД должна обеспечивать два базовых требования целостности реляционной модели данных: целостность сущностей и целостность по ссылкам.

Требование целостности сущностей состоит в том, что любой кортеж отношения отличим от любого другого кортежа этого отношения. Это означает, что для каждого отношения должен быть определен первичный ключ. Требование целостности сущностей иначе называют требованием первичного ключа. При вводе новой записи в таблицу СУБД автоматически проверяет уникальность введенного значения первичного ключа и не допускает повторов.

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

Целостность по ссылкам должна поддерживаться СУБД при выполнении операций модификации первичного ключа и удаления кортежа.

При операциях модификации возможны два варианта. В первом случае запрещается изменять значение первичного ключа в записи главной таблицы, если это значение использовано в одной или нескольких записях связанных с ней по данному ключу таблиц. Во втором варианте при изменении значения первичного ключа автоматически изменяется его значение в соответствующих записях всех связанных таблиц (каскадное обновление записей).

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

Выбор варианта зависит от требований предметной области и существующих бизнес-правил. Так, для связи между таблицами Покупатель и Заказ (по коду покупателя) нельзя удалять запись о покупателе, который оформил хотя бы один заказ.

Существуют и другие ограничения, накладываемые на атрибуты отношений для получения «хорошей» реляционной структуры. Процесс приведения структуры отношений к некоторой оптимальной структуре называется нормализацией и будет рассмотрен при описании проектирования реляционной базы данных.

Структурной частью реляционной модели данных является нормализованное отношение.

Перечислим достоинства реляционной модели.

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

Отметим и недостатки данной модели.

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

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