Связь один к одному access как сделать

Практически всегда БД не ограничивается одной таблицей. Сложно представить себе какой-либо бизнес-процесс на предприятии, который мог бы сконцентрироваться только на одном предмете в плане информации.

Рассмотрим пример учебной базы данных. Имеется отдел, который занимается обработкой звонков, поступающих на различные линии. Линии обслуживаются конкретными операторами. Операторы состоят в разных группах под присмотром супервайзеров.

Только из данного краткого описания можно выделить несколько самостоятельных объектов:

• Телефонные линии обслуживания;
• Сотрудники отдела;
• Должности сотрудников;
• Группы, по которым распределены сотрудники;
• Звонки.

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

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

Логику соединения таблиц в БД важно понять с самого начала изучения SQL, так как наверняка Вы не будете писать запросы только к одной таблице.

Всего существует 3 типа связей:

• Один к одному;
• Один ко многим;
• Многие ко многим.

Примечание: В данном материале обозначения связей приводятся на примере MS SQL Server. В иных СУБД они могут обозначаться по-разному, но у Вас не должно возникнуть проблем с определением их типа, т.к. они либо очень похожи, либо интуитивно понятны.

Связь «Один к одному»

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

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

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

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

Связь «Один ко многим»

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

Рассмотрим связь учебной базы данных между должностями и сотрудниками, которая относится к рассматриваемому типу.

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

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

Связь «Многие ко многим»

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

В нашей базе подобное наблюдается только между таблицами с сотрудниками и линиями.

Из диаграммы видно, что имеются две связи «один ко многим» (один сотрудник может обрабатывать несколько телефонных линий, и одну линию могут обрабатывать несколько сотрудников), но в совокупности они образуют связь «многие ко многим».

Для чего все это нужно?

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

Правильно настроив связи, можно быть уверенным, что ничего не потеряется.

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

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

Поэтому связи называют еще ограничениями.

Новые статьи:

Если материалы office-menu.ru Вам помогли, то поддержите, пожалуйста, проект, чтобы мы могли развивать его дальше.

У Вас недостаточно прав для комментирования.

Источник: http://office-menu.ru/uroki-sql/41-tipy-svyazej-v-relyatsionnykh-bazakh-dannykh

Отношение "один-к-одному"

Отношение или связь «один-к-одному» связывает одну запись таблицы с одной или не связывает ни с одной записью другой таблицы. Иногда этот тип отношения применяется для разбиения таблицы с большим количеством полей на две или несколько меньших таблиц.

Таблица Products (изделия) может содержать подробную информацию, описывающую изделие и его цену, и дополнительные сведения об особенностях его производства.

В другой ситуации можно разбить таблицу на две, просто потому что она слишком велика. (Программа Access не разрешает таблице иметь более 255 полей.)

Рис. 5.15. Когда связываются два поля, в которых не допускаются дублирующиеся данные (и флажок Обеспечение целостности данных установлен), Access считает, что создается связь «один-к-одному».

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

В этом примере столбец ID в таблице Products и столбец ID в таблице ProductsEngineering — первичные ключи соответствующих таблиц, поэтому невозможно связать несколько записей таблицы ProductsEngineering с одной и той же записью таблицы Products

создается так же, как отношение «один-ко-многим» — перетаскиванием с помощью мыши полей на вкладке Схема данных (рис. 5.15). Единственная

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

Примечание

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

Применяйте связи «один-к-одному» с осторожностью

Отношения «один-к-одному» крайне редко применяются в программе Access. Обычно гораздо удобнее использовать скрытие столбцов (см. разд. «Скрытие столбцов» главы 3) и запросы (см. главу 6), если вы хотите видеть только отдельные поля таблицы.

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

•    Две части таблицы необходимо поместить в отдельные БД (см. разд. «Что такое разделенная БД» главы 18) для того, чтобы разные люди могли копировать их на разные компьютеры и редактировать независимо.

•    Вы хотите защитить от любопытных глаз уязвимые данные. Один из возможных способов — поместить информацию, которую нужно защитить, в отдельную таблицу и сохранить эту таблицу в другой, более защищенный файл БД.

•    У вас есть таблица с огромным объемом данных, таких как поля типа Вложение (см. разд. «Вложение» главы 2) с большими документами. В этом случае можно повысить производительность, если разделить таблицу. Вы даже можете решить, что лучше поместить половину таблицы в отдельную БД (см, разд. «Что такое разделенная БД» главы 18).

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

Если у вас нет таких ситуаций, вы больше выиграете от создания одной большой таблицы.

Отношение «многие-ко-многим»

Отношение или связь «многие-ко-многим»связывает одну или несколько записей одной таблицы с одной или несколькими записями в другой таблице. Рассмотрим БД, в которой в отдельных таблицах хранятся данные об авторах и книгах.

Авторы бестселлеров не останавливаются на одной книге (поэтому вы должны иметь возможность связать одного автора с несколькими книгами).

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

Связи «многие-ко-многим» довольно распространены, и программа Access предоставляет два способа их обработки.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Источник: http://crypto.pp.ua/2011/04/otnoshenie-odin-k-odnomu/

jtest.ru

21.03.2011

Представляю Вашему вниманию вольный перевод статьи SQL for Beginners Part 3

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

Предыдущие статьи

• SQL для начинающих. Часть 1
• SQL для начинающих. Часть 2

Вступление

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

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

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

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

• Отношения один к одному
• Один ко многим и многие к одному
• Многие ко многим
• Связь с самим собой

Когда данные выбираются из нескольких связанных таблиц, мы будем использовать запрос JOIN. Есть несколько типов присоединения, мы познакомимся с этими:

• Cross Joins (Перекрестное соединение)
• Natural Joins (Естественное соединений)
• Inner Joins (Внутреннее соединений)
• Left (Outer) Joins (Левое (внешнее) соединение)
• Right (Outer) Joins (Правое (внешнее) соединение)

Также мы изучим предложения ON и USING.

Связь один к одному

Допустим есть таблица покупателей (customers):

Мы можем расположить информацию о адресе покупателя в другой таблице:

Теперь у нас есть связь между таблицами покупателей (Customers) и адресами (Addresses). Если каждый адрес может принадлежать только одному покупателю, то такая связь называется «Один к одному». Имейте ввиду, что такой тип отношений не очень распространен. Наша первоначальная таблица, в которой информация о покупателе и его адресе хранилась вместе, в большинстве случаев работает нормально.

Обратите внимание, что теперь поле с названием «address_id», в таблице покупателей, ссылается на соответствующую запись в таблице адресов. Оно называется внешним ключом (Foreign Key) и используется во всех видах связей в базе. Мы рассмотрим этот вопрос позже в этой статье.

Вот так можно отобразить отношения между покупателями и адресами:

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

Связь один ко многим и многие к одному

Этот тип отношений наиболее часто встречающийся. Рассмотрим такой сайт интернет магазина:

• У покупателей может быть несколько заказов.
• Заказ может содержать несколько товаров.
• Товары могут иметь описание на нескольких языках.

В этих случаях нам потребуется создать связь «Один ко многим». Пример:

Каждый покупатель может иметь 0 или более заказов. Но каждый заказ может принадлежать только одному покупателю.

Связь многие ко многим

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

Для такой связи нам потребуется создать дополнительную таблицу:

Назначение таблицы «Items_Orders» только одно — создать связь «Многие ко многим» между товарами и заказами.

Так можно представить этот тип отношений:

Если добавить записи items_orders к диаграмме, то она будет выглядеть так:

Связь с собой

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

Покупатели 102 и 103 ссылаются на покупателя 101.

Этот тип похож на связь «Один ко многим», поскольку один покупатель может ссылаться на несколько покупателей. Это можно представить как древовидную структуру:

Один покупатель может ссылаться на одного покупателя, на нескольких покупателей, или вообще не ссылаться ни на одного.

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

Внешние ключи

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

• В отношениях, обсуждаемых выше, у нас всегда было поле вида «****_id», которое ссылалось столбец в другой таблице. В нашем примере столбец customer_id, в таблице Orders, является внешним ключом:
• В таких базах как MySQL есть два способа создания внешних ключей:

Задать внешний ключ явно

Создадим простую таблицу с покупателями:

CREATE TABLE customers (
customer_id INT AUTO_INCREMENT PRIMARY KEY,
customer_name VARCHAR(100)
);

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

CREATE TABLE orders (
order_id INT AUTO_INCREMENT PRIMARY KEY,
customer_id INT,
amount DOUBLE,
FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
);

Оба столбца (customers.customer_id и orders.customer_id) должны быть одного типа. Если у первого тип INT, то второй не должен быть типа BIGINT, например.

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

Без явного объявления

Некоторые таблицы заказов могут быть созданы без явного определения внешнего ключа:

CREATE TABLE orders (
order_id INT AUTO_INCREMENT PRIMARY KEY,
customer_id INT,
amount DOUBLE,
INDEX (customer_id)
);

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

SELECT * FROM orders
JOIN customers USING(customer_id)

Мы подошли к изучению запросов JOIN, которые обсудим далее в статье.

Отображение связей

В данный момент, моей любимой программой для проектирования баз данных и отображения связей является MySQL Workbench.

После того как Вы спроектировали базу данных, ее можно экспортировать в SQL и выполнить на сервере. Это очень удобно при создании больших и сложных баз данных.

Запросы JOIN

Чтобы получить связанные данные из базы данных следует использовать запросы JOIN.

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

CREATE TABLE customers (
customer_id INT AUTO_INCREMENT PRIMARY KEY,
customer_name VARCHAR(100)
);

CREATE TABLE orders (
order_id INT AUTO_INCREMENT PRIMARY KEY,
customer_id INT,
amount DOUBLE,
FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
);

INSERT INTO `customers` (`customer_id`, `customer_name`) VALUES
(1, 'Adam'),
(2, 'Andy'),
(3, 'Joe'),
(4, 'Sandy');

INSERT INTO `orders` (`order_id`, `customer_id`, `amount`) VALUES
(1, 1, 19.99),
(2, 1, 35.15),
(3, 3, 17.56),
(4, 4, 12.34);

У нас есть 4 покупателя. У одного из них два заказа, у двоих по одному заказу, и у одного вообще нет заказов. Теперь давайте посмотрим какие виды запросов JOIN мы можем выполнять с этими таблицами.

Cross Join (Перекрестное объединение)

Это вид JOIN запроса по-умолчанию, если не определено условие.

Результатом будет, так называемое, «Декартово объединение» таблиц. Это означает, что каждая строка из первой таблицы сопоставляется с каждой строкой второй таблицы. Т.к. в каждой таблице по 4 строки, мы получили в результате 16 строк.

Ключевое слово JOIN можно заменить на запятую, в этом случае.

Конечно такой результат почти бесполезен. Давайте взглянем на другие виды объединений.

Natural Join (Естественное объединение)

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

Как Вы можете видеть, в этот раз столбец customer_id отображаются только один раз, потому что движок базы рассматривает этот столбец как общий. Мы видим два заказа Adam'а, и другие два заказа Joe и Sandy. Наконец мы получили некоторую полезную информацию.

Inner Join (Внутреннее объединение)

Если условие объединения не указан, то выполняется внутреннее объединение. В этом случае хорошей идеей будет наличие совпадений по полю customer_id в обеих таблицах. Результат должен быть аналогичен естественному объединению.

Результат почти такой же. Столбец customer_id повторяется два раза, по разу для каждой таблицы. Объясняется это тем, что мы попросили базу сравнить значение по двум столбцам. При этом не знаю, что возвращают одну и туже информацию.

1. Добавим побольше условий к запросу.
2. На этот раз возвращается только те заказы, сумма которых превышает $15.

Предложение ON

Прежде чем перейти к другим видам объединяющих запросов, нам нужно рассмотреть предложение ON. Оно служит для вставки условий JOIN в отдельные предложения.

Теперь мы можем различать условия, относящиеся к JOIN и условия в части WHERE. Но еще есть небольшая разница в функционировании. Мы увидим это, когда перейдем к примерам с LEFT JOIN.

Предложение USING

Предложение USING немного похоже на конструкцию ON. Если столбцы в таблицах называется одинаково, можно указать их здесь.

На самом деле это очень похоже на NATURAL JOIN, т.е. объединяющий столбец (customer_id) не повторяется дважды.

Left (Outer) Join (Левое внешнее соединение)

LEFT JOIN это вид внешнего соединения. В следующем запросе, если не найдены совпадения во второй таблице, записи из первой таблице все равно отобразятся.

Хотя у Andy и нет заказов, эта запись все равно отображается. Значение из второй таблицы равно NULL.

Это полезно, когда нужно найти записи, у которых нет связей. Например, мы можем найти всех покупателей, которые ничего не заказывали.

Отметим, что ключевое слово OUTER не обязательно. Вы можете использовать просто LEFT JOIN вместо LEFT OUTER JOIN.

Условия

Теперь давайте посмотрим на запросы с условиями.

Так, что случилось с Andy и Sandy? LEFT JOIN подразумевает, что мы должны получить покупателей, у которых нет заказов. Проблема в том, что условие WHERE скрывает эти результаты. Чтобы получить их, мы можем попытаться включить условие с NULL.

Появился Andy, но нет Sandy. Выглядит неправильно. Для того чтобы получить то, что мы хотим, нужно использовать предложение ON.

Теперь мы получили всех, и все заказы более $15. Как я говорил ранее, предложение ON иногда работает не так как WHERE. В таких внешних объединениях как это, столбцы включаются всегда, даже если нет совпадений в условии предложения ON.

Right (Outer) Join (Правое внешнее соединение)

Объединение RIGHT OUTER JOIN работает также, только порядок таблиц меняется на обратный.

На этот раз мы не получили результатов с NULL, потому что каждый заказ имеет сопоставление с записью покупателя. Мы можем поменять порядок таблиц и получим тот же результат, что и с LEFT OUTER JOIN.

Теперь у нас появились значения NULL, потому что таблица покупателей с правой стороны от объединения.

Заключение

Спасибо за чтение статьи. Надеюсь Вам понравилось!

Источник: http://jtest.ru/bazyi-dannyix/sql-dlya-nachinayushhix-chast-3.html

Типы связей в базе данных примеры (один к одному, один ко многим, многие ко многим)

Если говорить о программировании ряляционных баз данных (типа MySQL), ниже для всех трех типов связи рассматривается один вопрос — «как связать данные из двух таблиц, имеющих отношение друг другу?»
— рассматриваются разные варианты, даются пояснения.

Связь «Один к одному»

Один к одному — у каждой двух сущностей есть лишь один спутник и больше никто.

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

Если один студент может завести только один аккаунт — то мы имеем классический пример связи один к одному.

Проектирование БД:
Если для работы приложения вам требуется получать для данного студента данные его профиле на сайте университета (см. ситуацию выше) — просто добавьте внешний ключ в таблицу «Студент» — т.е.

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

Связь «Один ко многим»

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

Примеры из жизни:
Напр. взаимоотношения командиров в армии — -это серия таблиц, где «соседние» звания связаны как «один ко многим». Например «у одного генерала под командованием несколько полковников».

• Или — одна большая группа учеников ходит в одну школу, другая в другую — тут «у одной школы много учеников».
• Ученик не может ходить сразу в две школы (в обычной ситуации) — а значит, в обратную сторону «от ученика к школе» множественности нет (иначе имели бы связь «многие ко многим») — значит это «один ко многим».
• Проектирование БД:
  В одну из таблицы (для каждой сущности, которых «много») добавляется внешний ключ на связанную сущность, которая («одна»)

Связь «Многие ко многим»

1. Ситуация из жизни:
   Таблица предметов и таблица студентов университета. Рассуждаем: ясно что один студент может ходить на много предметов, при этом один предмет может слушаться многими студентами — значит, это «многие ко многим»
2. Проектирование БД:
   Вводится дополнительная таблицы, в каждый кортеж которой входят два ключа, каждый из этих ключей указывает на одни из двух таблиц сущностей (между которыми таким образом и прокладывается связь «многие ко многим») — см. пример SQL для связи «Многие ко многим»
3. Источники (что почитать):

Источник: http://fkn.ktu10.com/?q=node/9981

Реляционные базы данных | Внешние ключи и связи

Последнее обновление: 02.07.2017

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

При выделении связи выделяют главную или родительскую таблицу (primary key table / master table) и зависимую, дочернюю таблицу (foreign key table / child table). Дочерняя таблица зависит от родительской.

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

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

• Один к одному (One to one)
• Один к многим (One to many)
• Многие ко многим (Many to many)

Связь один к одному

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

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

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

Например, таблица Users представляет пользователей и имеет следующие столбцы:

• UserId (идентификатор, первичный ключ)
• Name (имя пользователя)

И таблица Blogs представляет блоги пользователей и имеет следующие столбцы:

• BlogId (идентификатор, первичный и внешний ключ)
• Name (название блога)

В этом случае столбец BlogId будет хранить значение из столбца UserId из таблицы пользователей. То есть столбец BlogId будет выступать одновременно первичным и внешним ключом.

Связь один ко многим

Это наиболее часто встречаемый тип связей. В этом типе связей несколько строк из дочерний таблицы зависят от одной строки в родительской таблице. Например, в одном блоге может быть несколько статей.

В этом случае таблица блогов является родительской, а таблица статей — дочерней. То есть один блог — много статей. Или другой пример, в футбольной команде может играть несколько футболистов.

К примеру, пусть будет таблица Articles, которая представляет статьи блога и которая имеет следующие столбцы:

• ArticleId (идентификатор, первичный ключ)
• BlogId (внешний ключ)
• Title (название статьи)
• Text (текст статьи)

В этом случае столбец BlogId из таблицы статей будет хранить значение из столбца BlogId из таблицы блогов.

Связь многие ко многим

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

Другой пример — статьи и теги: для одной статьи можно определить несколько тегов, а один тег может быть определен для нескольких статей.

Но в SQL Server на уровне базы данных мы не можем установить прямую связь многие ко многим между двумя таблицами. Это делается посредством вспомогательной промежуточной таблицы. Иногда данные из этой промежуточной таблицы представляют отдельную сущность.

Например, в случае со статьями и тегами пусть будет таблица Tags, которая имеет два столбца:

• TagId (идентификатор, первичный ключ)
• Text (текст тега)

Также пусть будет промежуточная таблица ArticleTags со следующими полями:

• TagId (идентификатор, первичный и внешний ключ)
• ArticleIdId (идентификатор, первичный и внешний ключ)

Технически мы получим две связи один-ко-многим. Столбец TagId из таблицы ArticleTags будет ссылаться на столбец TagId из таблицы Tags.

А столбец ArticleId из таблицы ArticleTags будет ссылаться на столбец ArticleId из таблицы Articles.

То есть столбцы TagId и ArticleId в таблице ArticleTags представляют составной первичный ключ и одновременно являются внешними ключами для связи с таблицами Articles и Tags.

Ссылочная целостность данных

При изменении первичных и внешних ключей следует соблюдать такой аспект как ссылочная целостность данных (referential integrity).

Ее основная идея состоит в том, чтобы две таблице в базе данных, которые хранят одни и те же данные, поддерживали их согласованность.

Целостность данных представляет правильно выстроенные отношения между таблицами с корректной установкой ссылок между ними. В каких случаях целостность данных может нарушаться:

• Аномалия удаления (deletion anomaly). Возникает при удалении строки из главной таблицы. В этом случае внешний ключ из зависимой таблицы продолжает ссылаться на удаленную строку из главной таблицы
• Аномалия вставки (insertion anomaly). Возникает при вставке строки в зависимую таблицу. В этом случае внешний ключ из зависимой таблицы не соответствует первичному ключу ни одной из строк из главной таблицы.
• Аномалии обновления (update anomaly). При подобной аномалии несколько строк одной таблицы могут содержать данные, которые принадлежат одному и тому же объекту. При изменении данных в одной строке они могу прийти в противоречие с данными из другой строки.

Аномалия удаления

Для решения аномалии удаления для внешнего ключа следует устанавливать одно из двух ограничений:

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

Аномалия вставки

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

Аномалии обновления

Для решения проблемы аномалии обновления применяется нормализация, которая будет рассмотрена далее.

Источник: https://metanit.com/sql/tutorial/1.3.php

Процедура создания связей в базе данных Microsoft Access

В реляционной базе данных связи позволяют избежать избыточности данных.

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

Кроме того, есть и дополнительные сведения об издателе, которые может потребоваться сохранить, такие как его телефонный номер, адрес и почтовый индекс. Если хранить их в таблице с книгами, то телефонный номер издателя будет повторяться для каждой опубликованной им книги.

Более правильным вариантом является вынесение сведений об издателях в отдельную таблицу «Издатели». При этом таблица «Книги» будет содержать ссылки на записи таблицы «Издатели».

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

Например, каждая книга в таблице «Книги» связана с определенным издателем в таблице «Издатели». Добавить в таблицу книгу для издателя, отсутствующего в базе данных, невозможно.

Связь осуществляется путем сопоставления данных в ключевых столбцах; обычно это столбцы, имеющие в обеих таблицах одинаковые названия.

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

Например, с каждым из изданий, находящихся в продаже, можно связать объемы его продаж путем создания столбца «ИД_издания» в таблице «Книги» (первичный ключ) и столбца «ИД_издания» в таблице «Продажи» (внешний ключ).

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

Связь «один ко многим» — наиболее распространенный вид связи.

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

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

В Microsoft Access сторона связи «один ко многим», которой соответствует первичный ключ, обозначается символом ключа. Сторона связи, которой соответствует внешний ключ, обозначается символом бесконечности.

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

Например, между таблицами «Авторы» и «Книги» установлена связь вида «многие ко многим», задаваемая с помощью связей вида «один ко многим» между каждой из этих таблиц и таблицей «АвторыКниг».

Первичный ключ таблицы «АвторыКниг» — это сочетание столбцов «ИД_автора» (первичного ключа таблицы авторов) и «ИД_книги» (первичного ключа таблицы заголовков).

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

Этот вид связи используется редко, поскольку в такой ситуации связываемые данные обычно можно хранить в одной таблице. Использовать связь вида «один к одному» можно в указанных ниже случаях.

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

В Microsoft Access сторона связи «один к одному», которой соответствует первичный ключ, обозначается символом ключа. Сторона связи, которой соответствует внешний ключ, также обозначается символом ключа.

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

Поле типа «Счетчик» можно связать с полем типа «Числовой» только в том случае, если для свойства FieldSize (размер поля) каждого из них задано одно и то же значение. Например, можно связать столбцы типов «Счетчик» и «Числовой», если для свойства FieldSize каждого из них установлено значение «Длинное целое».

Чтобы создать связь вида «один ко многим» или «один к одному», воспользуйтесь приведенной ниже последовательностью действий:

1. Закройте все открытые таблицы. Создавать или изменять связи между открытыми таблицами нельзя.
2. В Access версий 2002 или 2003 выполните указанные ниже действия.
   1. Нажмите клавишу F11, чтобы перейти в окно базы данных.
   2. В меню Сервис выберите команду Связи.

   В Access 2007 нажмите кнопку Связи в группе Показать или скрыть вкладки Инструменты для баз данных.

3. Если в базе данных отсутствуют связи, то автоматически появится диалоговое окно Добавление таблицы. Если окно Добавление таблицы не появилось, но при этом нужно добавить таблицы в список связываемых, выберите команду Добавить таблицу в меню Связи.
4. Дважды щелкните названия таблиц, которые необходимо связать, после чего закройте диалоговое окно Добавление таблицы. Чтобы связать таблицу с самой собой, добавьте ее два раза.
5. Перетащите связываемое поле из одной таблицы на связываемое поле в другой. Чтобы перетащить несколько полей, нажмите клавишу CTRL, щелкните каждое поле, а затем перетащите их.

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

6. Появится окно Изменение связей. Убедитесь, что в каждом из столбцов отображаются названия нужных полей. Если нужно, их можно изменить.

   При необходимости задайте параметры связи. Если требуются сведения о конкретном элементе окна Изменение связей, нажмите кнопку со знаком вопроса, а затем щелкните соответствующий элемент. Эти параметры будут подробно описаны ниже.

7. Чтобы установить связь, нажмите кнопку Создать.
8. Повторите действия с 5 по 8 для каждой пары связываемых таблиц.

   При закрытии диалогового окна Изменение связей Microsoft Access спросит, нужно ли сохранить макет. Вне зависимости от ответа на этот вопрос создаваемые связи сохраняются в базе данных.

   Примечание. Создавать связи можно не только в таблицах, но и в запросах. При этом, однако, не обеспечивается целостность данных.

Чтобы создать связь вида «многие ко многим», выполните указанные ниже действия.

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

   Примечание. Чтобы создать первичный ключ, выполните указанные ниже действия.

   1. Откройте таблицу в режиме конструктора.
   2. Выберите одно или несколько полей, которые необходимо определить в качестве первичного ключа. Чтобы выбрать одно поле, щелкните знак выбора строки для нужного поля.

      Чтобы выбрать несколько полей, удерживайте нажатой клавишу CTRL и щелкните знак выбора строки для каждого из полей.

   3. В Access версий 2002 или 2003 нажмите кнопку Первичный ключ на панели инструментов.

      В Access 2007 нажмите кнопку Первичный ключ в группе Сервис вкладки Структура.

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

4. Установите связь вида «один ко многим» между каждой из двух главных таблиц и соединительной таблицей.

Целостность данных — это система правил Microsoft Access, которая используется для проверки допустимости отношений между записями связанных таблиц и для того, чтобы не позволить случайно удалить или изменить связанные данные. Настроить проверку целостности данных можно при соблюдении всех указанных ниже условий.

• Связываемое поле из главной таблицы является первичным ключом или имеет однозначный индекс.
• Связываемые поля должны иметь одинаковый тип данных. Существует два исключения. Поле типа «Счетчик» может быть связано с числовым полем, если для свойства FieldSize у него установлено значение «Длинное целое»; кроме того, можно связать поле «Счетчик» с числовым полем, если у них обоих для свойства FieldSize задано значение «Код репликации».
• Обе таблицы принадлежат к одной и той же базе данных Microsoft Access. Если таблицы связаны, то они должны иметь формат Microsoft Access, а для настройки целостности данных необходимо открыть ту базу данных, в которой они хранятся. Обеспечить целостность данных для таблиц, находящихся в базах данных другого формата, невозможно.

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

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

Если для связи включено обеспечение целостности данных, можно задать режим автоматического каскадного обновления или удаления связанных записей средствами Microsoft Access.

Установка этих параметров разрешает операции удаления и обновления, выполнение которых в противном случае было бы запрещено правилами целостности данных.

При удалении записей или изменении значений первичного ключа в главной таблице Microsoft Access вносит необходимые изменения во все связанные таблицы для сохранения целостности данных.

Если в процессе создании связи установить флажок каскадное обновление связанных полей, то при любом изменении значения первичного ключа записи в главной таблице Microsoft Access автоматически обновит значение соответствующего поля во всех связанных записях. Например, при изменении ИД клиента в таблице «Клиенты» поле «Клиент» в таблице «Заказы» автоматически обновится для всех заказов этого клиента, чтобы сохранить связь. Microsoft Access выполнит каскадное обновление без вывода дополнительных сообщений.

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

Если в процессе создания связи установить флажок каскадное удаление связанных записей, то при удалении любой записи из главной таблицы Microsoft Access автоматически удалит связанные записи и в связанной таблице.

Например, если удалить запись клиента из таблицы «Клиенты», то все заказы данного клиента будут автоматически удалены из таблицы «Заказы» (включая записи таблицы «Сведения о заказе», связанные с записями таблицы «Заказы»).

При удалении записей из формы или таблицы с установленным флажком каскадное удаление связанных записей Microsoft Access предупреждает, что связанные записи также будут удалены. Однако при удалении записей с помощью запроса на удаление Microsoft Access автоматически удалит записи из связанных таблиц без вывода предупреждения.

Ниже перечислены существующие типы соединений.

Вариант 1 — внутреннее соединение.

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

Вариант 2 — левое внешнее соединение. Левое внешнее соединение — это соединение, при котором все записи таблицы по левую сторону от оператора LEFT JOIN (левое объединение) инструкции SQL попадают в результаты запроса даже в том случае, если в связанном поле из правой таблицы отсутствуют соответствующие значения.

Вариант 3 — правое внешнее соединение. Правое внешнее соединение — это соединение, при котором все записи таблицы по правую сторону от оператора RIGHT JOIN (правое объединение) инструкции SQL попадают в результаты запроса даже в том случае, если в связанном поле из левой таблицы отсутствуют соответствующие значения.

Источник: http://www.fordus.org.ua/Domoy/protsedura-sozdaniya-svyazej-v-baze-dannykh-microsoft-access.html