Многотабличная база. Разбиение, типы связей.

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

Если БД состоит из нескольких таблиц, то между ними нужно установить связь, которая для любого значения первичного ключа основной таблицы будет ставить в соответствие единственные записи из всех зависимых таблиц. Такаяинформация называется структурированной. Другими словами, под структурированием информации понимается связь, которая позволяет СУБД при удалении/добавлении записи в основной таблице однозначным образом определить изменения в остальных зависимых таблицах. Для установления этой связи нужно в зависимую таблицу ввести поле (поля), аналогичные первичному ключу главной таблицы. Такие поля зависимой таблицы будут для нее тоже ключевыми и называются, как правило, внешним ключом. Записи в связанных таблицах соединяются по значениям первичного ключа одной таблицы и таким же значением внешнего ключа другой. Внешний ключ другой таблицы не обязательно является ее первичным ключом.

Связь между таблицами может быть следующих типов.

Отношение «один–к–одному» (1-1) означает, что каждой записи в одной таблице соответствует только одна запись в другой таблице. Применяется в случае разделения широких таблиц.

Например, в БД о персонале предприятия в отдельную таблицу вынесены дополнительные сведения о работающем (фотография работающего, автобиография, состояние здоровья, и т.д.). Понятно, что одному работнику будут соответствовать лишь одни дополнительные сведения.

Отношение «один–ко–многим» («много–к–одному»). Это наиболее общий тип отношений. Одной записи в одной таблице соответствует несколько в другой.

Например, в БД о персонале предприятия в одном подразделении (цех, отдел, бригада) будет числиться несколько сотрудников.

Отношение «много–ко–многим»: одна запись из первой таблицы связана со многими записями из 2-ой таблицы и наоборот.

Например, в БД о персонале предприятия при условии возможности совместительства в одном подразделении (цех, отдел, бригада) будет числиться несколько сотрудников, но и сотрудник может числиться в нескольких подразделениях.

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

Детали Поставщик Информация о поставщике

Код детали		Код поставщика	1- 1	Код поставщика
Деталь	 - 1	Название		Телефон
Цена				Адрес
Количество
Код поставщика
		Рис.1

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

Правильное определение отношений между классами объектов и точное указание первичных и внешних ключей составляет основу эффективности проектирования БД .

Такое разбиение на двумерные таблицы было впервые предложено в 70-м году в статье сотрудника фирмы IBM д-ра Э.Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June 1970), где, вероятно, впервые был применен термин "реляционная модель данных".

Будучи математиком по образованию Э.Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как отношение – relation (англ.). Предложив реляционную модель данных, Э.Ф.Кодд создал и инструмент для удобной работы с отношениями – реляционную алгебру. Каждая операция этой алгебры использует одну или несколько таблиц (отношений) в качестве ее операндов и продуцирует в результате новую таблицу, т.е. позволяет "разрезать" или "склеивать" таблицы. Этот инструмент позволил создать СУБД, реализующие реляционную модель. К таким СУБД относится и MS Access, с которым мы в дальнейшем и будем работать.

Для нашего примера соединения между таблицами показаны на рисунке 1. Соединения созданы между полями первичного ключа и полями внешнего ключа реляционных таблиц. Для таблицы «Поставщик» поле Код поставщика будет первичным, а соответствующие поля в таблицах «Детали» и «Информация о поставщике» будут внешними полями. В реляционных базах данных дублирование данных между таблицами неизбежно, но дублирование данных в самих таблицах не допускается. Нам пришлось продублировать значения первичного ключа одной таблицы в качестве значений внешнего ключа зависимых таблиц. Зависимая таблица – это таблица, для которой требуется связь с другой таблицей для полной идентификации своих объектов. Зависимые таблицы иногда называют вторичными или связанными.

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