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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Типы связей в реляционных базах данных

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

Приступая к изучению данного материала, рекомендуется ознакомиться с описанием учебной БД.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читать еще:  Как сделать в microsoft powerpoint анимацию текста?

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

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

HTML, CSS, JavaScript, JQuery, PHP, MySQL

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

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

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

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

Вступление

При проектировании базы данных, здравый смысл подсказывает нам, что мы должны использовать различные таблицы для разных данных. Пример: клиенты, заказы, записи, сообщения и т.д. Так же мы должны иметь взаимосвязи между этими таблицами. Например, клиент имеет заказы, а у заказа есть позиции (товары). Эти взаимосвязи должны быть отражены в базе данных. А также, когда мы получаем данные с помощью 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 есть два способа создания внешних ключей:

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

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

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

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

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

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

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

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

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

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

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

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

Запросы JOIN

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

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

У нас есть 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 повторяется два раза, по разу для каждой таблицы. Объясняется это тем, что мы попросили базу сравнить значение по двум столбцам. При этом не знаю, что возвращают одну и туже информацию.

Читать еще:  Как сделать свою игру в powerpoint 2013?

Добавим побольше условий к запросу.

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

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

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

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

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

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

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

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

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

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

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

Все что мы сделали — нашли все значения NULL для order_id.

Отметим, что ключевое слово 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, потому что таблица покупателей с правой стороны от объединения.

Заключение

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

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

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

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

Между таблицами можно установить связи одного из трех видов: один-ко-многим (one-to-many), многие-ко-многим (many-to-many) и один-к-одному (one-to-one).

  • Один-ко-многим (one-to-many). Является наиболее часто употребляемым видом связи. В этом случае каждой записи таблицы А может соответствовать много записей таблицы Б (или ни одной). В свою очередь, каждой записи таблицы Б соответствует в точности одна запись таблицы А. Таблица А в такой связи называется главной, а таблица Б — связанной или подчиненной.
  • Многие-ко-многим (many-to-many). Многим записям из таблицы А может соответствовать много записей из таблицы Б (и наоборот). Такую связь в Microsoft Access можно организовать при помощи третьей вспомогательной таблицы, в которой каждому первичному ключу из таблицы А сопоставлен первичный ключ из таблицы Б. По сути, связь типа многие-ко-многим (many-to-many) представляет собой две связи типа один-ко-многим (one-to-many). При этом таблицы А и Б расположены со стороны один (one), а вспомогательная таблица — со стороны многие (many). Такой тип связи используется реже, но существуют ситуации, когда без нее не обойтись. В учебной базе данных Борей (Northwind) примером связи многие-ко-многим (many-to-many) является связь между таблицами Заказы (Orders) и Товары (Products), организованная при помощи таблицы Заказано (Order Details).
  • Один-к-одному (one-to-one). Одной записи таблицы А соответствует в точности одна запись таблицы Б и наоборот. Этот тип связи практически никогда не применяется. Единственный случай, когда применение этого типа связи оправданно — разбивка таблицы, содержащей очень большое количество полей, на несколько частей.

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

  • Внутреннее объединение (Inner Join). Объединяются только те записи из таблиц, связанные поля которых совпадают. Остальные записи в итоговую выборку не попадут. Например, таблицы Товары (Products) и Типы (Categories) связаны между собой по полям КодКатегории (CategoryW). При выборке записей из этих таблиц в итоговую выборку попадут только те записи из таблицы Типы (Categories), ссылка на которые есть в таблице Товары (Products). Этот тип объединения используется в подавляющем большинстве случаев.
  • Левое внешнее объединение (Left Join). Объединяются все записи таблицы со стороны один (one) и только те записи таблицы со стороны многие (many), значения связанного поля которых совпадают со значениями соответствующего поля первой таблицы. Попросту говоря, к результатам выборки по внутреннему объединению добавятся все записи из таблицы со стороны один (one), первоначально в нее не вошедшие. Соответствующие поля этих записей второй таблицы в выборке будут иметь пустое (Null) значение.
  • Правое внешнее объединение (Right Join). Аналогично левому внешнему объединению, но таблицы со стороны один (one) и со стороны многие (many) меняются ролями, т.е. к результатам выборки по внутреннему объединению добавятся не вошедшие в нее записи из таблицы со стороны многие (many).

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

Постоянные связи между таблицами устанавливаются в диалоговом окне Схема данных (Relationships). Доступ к этому окну можно получить, выбрав одноименный пункт в меню Сервис (Tools) (см. рис. 3.20). Прежде чем приступить к установлению связей, необходимо закрыть все открытые таблицы. Это нужно сделать для того, чтобы можно было задать обеспечение целостности данных — для открытых таблиц этого сделать не удастся.

Прежде всего, нужно добавить в диалоговое окно Схема данных (Relationships) те таблицы, между которыми предполагается установить связь. Для этого можно выбрать пункт Отобразить таблицу (Show Table) меню Связи (Relationships) или щелкнуть на соответствующей кнопке панели инструментов (). В появившемся окне нужно дважды щелкнуть на именах связываемых таблиц и закрыть окно. Можно также, используя клавиши и , выделить мышью несколько таблиц и нажать кнопку Добавить (Add). Для того чтобы установить связь между полями, необходимо перетащить мышью поле из одной таблицы на соответствующее поле другой таблицы. На экране появится диалоговое окно Изменение связей (Edit Relationships) (см. рис. 3.21).

Читать еще:  Как сделать сноску в презентации powerpoint?

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

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

Флажок Обеспечение целостности данных (Enforce Referential Integrity). Целостностью данных или ссылочной целостностью (Referential Integrity) называют набор правил, которые Microsoft Access использует для поддержания допустимых межтабличных связей и запрета на случайное изменение или удаление связанных данных. Этот флажок можно устанавливать при выполнении всех следующих условий: связываемое поле из главной таблицы является полем первичного ключа или имеет уникальный индекс; связанные поля имеют один и тот же (или совместимый) тип данных; обе таблицы содержатся в одной и той же базе данных Microsoft Access. Снимите этот флажок, чтобы допустить изменения в связанных таблицах, которые приводят к нарушению условий целостности данных.

Флажок Каскадное обновление связанных полей (Cascade Update Related Fields). Установите этот флажок для того, чтобы Microsoft Access автоматически обновлял соответствующие значения в связанной таблице при любом изменении значения первичного ключа в главной таблице. Для предотвращения изменений значения первичного ключа в главной таблице, если существуют соответствующие записи в связанной таблице, нужно установить флажок Обеспечение целостности данных (Enforce Referential Integrity) и снять флажок Каскадное обновление связанных полей (Cascade Update Related Fields).

Флажок Каскадное удаление связанных записей (Cascade Delete Related Records). Флажок нужно установить для автоматического удаления связанных записей в связанной таблице при удалении записи в главной таблице. Для предотвращения удаления записей из главной таблицы, если имеются соответствующие записи в связанной таблице, нужно установить флажок Обеспечение целостности данных (Enforce Referential Integrity) и снять флажок Каскадное удаление связанных записей (Cascade Delete Related Records).

Для того чтобы определить способ объединения связываемых таблиц, нажмите кнопку Объединение (Join Type). На экране появится диалоговое окно Параметры объединения (Join Properties) (см. рис. 3.22). Здесь можно выбрать подходящий вариант объединения (различные способы объединения (внешние и внутренние) были описаны чуть выше).

Если флажок Каскадное удаление связанных записей (Cascade Delete Related Records) установлен, любое удаление записи в главной таблице приведет к автоматическому удалению связанных записей во всех подчиненных таблицах. Например, при удалении из таблицы Клиенты (Customers) записи о конкретном клиенте будут автоматически удалены все связанные с ним записи из таблицы Заказы (Orders) и, как следствие, соответствующие записи из таблицы Заказано (Orders Details). При этом, если записи удаляются при помощи запроса на удаление, Microsoft Access даже не выдает предупреждающего сообщения.

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

Типы связей в реляционных базах данных

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

Приступая к изучению данного материала, рекомендуется ознакомиться с описанием учебной БД.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ссылка на основную публикацию
Adblock
detector