Databases. Part IV

Databases. Part IV

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

P. S. Обратите внимание на комментарии.

Далее отношения между таблицами я буду называть связи, поскольку отношение – это еще и синоним таблицы, а «отношения между отношениями» звучит очень глупо :whistle:

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

Главная таблица – таблица, атрибутам которой не нужны другие атрибуты для расшифровки. Все остальные таблицы – зависимые.

На самом деле, абсолютно главная таблица – это большая редкость, ведь все таблицы базы данных взаимосвязаны. И та таблица, которая являлась главной для одной таблицы, может быть зависимой для другой. Вот такие метаморфозы :wacko:

Как сделать связь??

Для этого разберем два понятия, первое, конечно же, виды связей, и второе… о нем чуть позже

Итак, если между таблицами произошла связь, то она была:

1. ОДИН К ОДНОМУ

При связи один к одному, одной строке главной таблицы соответствует не более одной строки зависимой таблицы.

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

Вообще, связь один к одному имеет намного большее значение, чем могло показаться, с помощью такого разделения таблицы пополам, мы можем ввести разграничение прав доступа. Таким образом, некоторые данные о сотруднике будут доступны всем пользователям, а вот специальная информация, только отделу кадров и руководству B)

2. ОДИН КО МНОГИМ

При связи один ко многим, одной строке главной таблице соответствует 0, 1 или более строк зависимой таблицы.

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

3. МНОГИЕ КО МНОГИМ

Если честно, хотел сюда другую картинку вставить…. :whistle:

При связи многие ко многим… одной строчке главной таблицы может соответствовать много строчек зависимой, равно как и наоборот, одной строчке из зависимой – много строчек из главной.

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

Однако реально такая связь вполне может существовать. :shock: Примеры?? Один преподаватель может вести несколько предметов, тогда как один предмет могут вести несколько преподавателей. Один покупатель может купить несколько товаров, так же как один товар могут купить множество покупателей, и т. д.

Про реализацию таких связей расскажу чуть позже… А сейчас второе понятие – внешний ключ.

Внешний ключ – это тот столбец главной таблицы, значения которого соответствуют первичному ключу в главной. То есть своеобразное поле связи. Графически внешние ключи как правило не отображаются.

Пример:

Даны таблицы

Содержимое заказов (номер заказа, код товара) и Товары (код товара, название товара)

Решение-размышление:

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


Карта сайта


Информационный сайт Webavtocat.ru