Содержание

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

Внешние ключи и связи

Последнее обновление: 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.

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

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

Руководство по проектированию реляционных баз данных (7-9 часть из 15) [перевод]

Продолжение.
Предыдущие части: 1-3, 4-6
7. Связь один-ко-многим.

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

Другой пример связи один-ко-многим – это связь, которая существует между матерью и ее детьми. Мать может иметь множество детей, но каждый ребенок может иметь только одну мать.

(Технически лучше говорить о женщине и ее детях вместо матери и ее детях потому, что, в контексте связи один-ко-многим, мать может иметь 0, 1 или множество потомков, но мать с 0 детей не может считаться матерью. Но давайте закроем на это глаза, хорошо?)

Когда одна запись в таблице А может быть связана с 0, 1 или множеством записей в таблице B, вы имеете дело со связью один-ко-многим. В реляционной модели данных связь один-ко-многим использует две таблицы.


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

Как опознать связь один-ко-многим?

Если у вас есть две сущности спросите себя:
1) Сколько объектов и B могут относится к объекту A?
2) Сколько объектов из A могут относиться к объекту из B?

Если на первый вопрос ответ – множество, а на второй – один

(или возможно, что ни одного), то вы имеете дело со связью один-ко-многим.

Примеры.

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

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

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

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

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

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

Создание связи многие-ко-многим.

Связь многие-ко-многим создается с помощью трех таблиц. Две таблицы – “источника” и одна соединительная таблица. Первичный ключ соединительной таблицы A_B –
составной
. Она состоит из двух полей, двух внешних ключей, которые ссылаются на первичные ключи таблиц A и B.

Все первичные ключи должны быть уникальными. Это подразумевает и то, что комбинация полей A и B должна быть уникальной в таблице A_B.

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

Таблицы “о пиве”.

Таблицы выше связывают поставщиков и пиво связью многие-ко-многим, используя соединительную таблицу. Обратите внимание, что пиво ‘Gentse Tripel’ (157) поставляют Horeca Import NL (157, AC001) Jansen Horeca (157, AB899) и Petersen Drankenhandel (157, AC009). И vice versa, Petersen Drankenhandel является поставщиком 3 видов пива из таблицы, а именно: Gentse Tripel (157, AC009), Uilenspiegel (158, AC009) и Jupiler (163, AC009).

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

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

Другой пример связи многие-ко-многим: заказ билетов в отеле.

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


Соединительная таблица связи многие-ко-многим имеет дополнительные поля.

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

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

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

В связи один-к-одному каждый блок сущности A может быть ассоциирован с 0, 1 блоком сущности B. Наемный работник, например, обычно связан с одним офисом. Или пивной бренд может иметь только одну страну происхождения.
В одной таблице.

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

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

  • Люди и их паспорта. Каждый человек в стране имеет только один действующий паспорт и каждый паспорт принадлежит только одному человеку.

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

Какой же вид связи вам нужен?

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

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

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

А когда у вас есть набор уникальных данных, которые имеют отношение только друг к другу, то храните все в одной таблице. Ваш выбор – связь один-к-одному. Например, у вас есть небольшая коллекция автомобилей и вы хотите хранить информацию о них (цвет, марка, год выпуска и пр.).

Определение связей между таблицами в базе данных Access

  • Чтение занимает 10 мин
  • Применяется к:
    Access 2013, Access 2010, Microsoft Office Access 2007, Microsoft Office Access 2003

В этой статье

Примечание

Office 365 ProPlus переименован в Майкрософт 365 корпоративные приложения. Для получения дополнительной информации об этом изменении прочитайте этот блог.

Оригинальный номер КБ:   304466

Примечание

Внимание! Материал, изложенный в этой статье, требует знания пользовательского интерфейса на компьютерах с одним пользователем. Эта статья относится только к базе данных Microsoft Access (.mdb или .accdb).

Аннотация

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

  • Что такое связи между таблицами?
  • Виды связей между таблицами
    • Связи «один ко многим»
    • Связи «многие ко многим»
    • Связи «один к одному»
  • Как определить связи между таблицами
    • Как определить связи «один ко многим» или «один к одному»
    • Как определить связь «многие ко многим»
  • Целостность данных
  • Каскадные обновления и удаления
  • Типы соединения

Что такое связи между таблицами?

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

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

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

Логические отношения в базе данных позволяют эффективно запрашивать данные и создавать отчеты.

Виды связей между таблицами

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

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

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

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

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

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

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

В связи «многие ко многим» строка в таблице А может иметь много совпадающих строк в таблице B, и наоборот. Вы создаете такую связь, определяя третью таблицу, которая называется промежуточной таблицей. Первичный ключ промежуточной таблицы состоит из внешних ключей как таблицы А, так и таблицы B. Например, таблица «Авторы» и таблица «Названия» имеют связь «многие ко многим», которая определяется связью «один ко многим» из каждой из этих таблиц к таблице «TitleAuthors». Первичным ключом таблицы «TitleAuthors» является комбинация столбца au_ID (первичный ключ таблицы «Авторы») и столбца title_ID (первичный ключ таблицы «Названия»).

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

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

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

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

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

Как определить связи между таблицами

При создании связи между таблицами связанные поля не должны иметь одни и те же имена. Однако связанные поля должны иметь один и тот же тип данных, если только поле первичного ключа не является полем AutoNumber. Вы можете сопоставить поле AutoNumber с полем Number, только если свойство FieldSize обоих совпадающих полей совпадает. Например, можно сопоставить поле AutoNumber и поле Number, если свойство theFieldSizeproperty обоих полей имеет значение Long Integer. Даже если оба совпадающих поля являются числовыми полями, они должны иметь параметр sameFieldSizeproperty.

Как определить связи «один ко многим» или «один к одному»

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

  1. Закройте все таблицы. Нельзя создавать или изменять связи между открытыми таблицами.

  2. В Access 2002 и Access 2003 выполните следующие действия.

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

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

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

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

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

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

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

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

  7. Нажмите кнопку Создать, чтобы создать связь.

  8. Повторите шаги с 4 по 7 для каждой пары таблиц, которые вы хотите связать.

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

    Примечание

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

Как определить связь «многие ко многим»

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

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

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

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

    Примечание

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

    1. Откройте таблицу в Конструкторе.

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

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

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

      Примечание

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

  4. Определите связь один-ко-многим между каждой основной и связующей таблицами.

Целостность данных

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

  • Совпадающие поля из основной таблицы являются первичным ключом или имеет уникальный индекс.
  • Связанные поля имеют один и тот же тип данных. Из этого правила есть два исключения: Поле AutoNumber может быть связано с полем Number, которое имеет FieldSize настройку свойства Long Integer, а поле AutoNumber, которое имеет  FieldSize настройку свойства Replication ID, может быть связано с полем Number, которое имеет  FieldSize настройку свойства Replication ID.
  • Обе таблицы относятся к одной и той же базе данных Access. Если таблицы являются связанными таблицами, они должны быть таблицами в формате Access, и необходимо открыть базу данных, в которой они хранятся, чтобы установить целостность данных. Референтная целостность не может быть применена для связанных таблиц из баз данных в других форматах.

При использовании целостности данных применяются следующие правила:

  • Невозможно ввести значение во внешнем ключевом поле связанной таблицы, которое не существует в первичном ключе первичной таблицы. Тем не менее, можно ввести значение Null во внешнем ключе. Это указывает на то, что записи не связаны между собой. Например, невозможно иметь заказ, который назначается клиенту, который не существует. Тем не менее, можно иметь заказ, который не назначается никому, введя значение Null в поле CustomerID.
  • Вы не можете удалить запись из основной таблицы, если в соответствующей таблице существуют соответствующие записи. Например, вы не можете удалить запись сотрудника из таблицы «Сотрудники», если в таблице «Заказы» есть заказы, назначенные сотруднику.
  • Невозможно изменить основное ключевое значение в основной таблице, если эта запись имеет соответствующие записи. Например, вы не можете изменить идентификатор сотрудника в таблице «Сотрудники», если в таблице «Заказы» есть заказы, назначенные этому сотруднику.

Каскадные обновления и удаления

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

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

Примечание

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

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

Типы соединения

Существует три основных типа соединения: Вы можете увидеть их на следующем снимке экрана:

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

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

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

Установка связей между таблицами БД Access 2007

2.4. Microsoft Access 2007

2.4.3. Установка логических связей в БД Access 2007

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

Для установления связей используем ключевые поля: КодГруппы, КодСтудентов и КодДисциплины. Например, между первичным ключом (КодГруппы) tables Группы студентов и вторичным ключом (КодГруппы) tables Студенты устанавливаем связь один — ко — многим.

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


Рис. 1.

В окне Добавление таблиц необходимо выделить имена таблиц и нажать кнопку Добавить, при этом в окне «Схема данных» появятся все tables (рис. 2). После этого необходимо закрыть окно диалога.


Рис. 2.

Далее необходимо установить связи между табл. в окне Схема данных. Для этого в окне Схема данных необходимо отбуксировать (переместить) поле КодГруппы из таблицы Группы студентов на соответствующее поле tables Студенты, в результате этой операции появится окно «Изменение связей» (рис. 3) .


Рис. 3.

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

В окне Схема данных появится связь один-ко-многим между таблицами Группы студентов и Студенты. Аналогичным образом надо связать поля КодСтудента в таблицах Студенты и Успеваемость, а затем поля КодДисциплины в таблицах Успеваемость и Дисциплины. В итоге получим Схему данных, представленную на рисунке 4.


Рис. 4.

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

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

Далее >>> Раздел: 2.4.4. Заполнение таблиц базы данных Access 2007

отношение «один ко многим» в концепции проектирования базы данных



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

author(id,otherAttributtes)
books(id,authorid,otherAttributes)

или

 author(id,otherAttributtes)
    books(id,otherAttributes)
    authorConnectsBooks(authorid,booksid)

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

database database-design
Поделиться Источник user666     13 апреля 2012 в 17:16

5 ответов


  • Отношения базы данных многие ко многим в модели ER

    Как мы можем реализовать корабль отношений многие ко многим в модели ER? Если это невозможно сделать, то почему и какие проблемы возникают при реализации отношений многие ко многим? Почему мы преобразуем отношение многие ко многим в отношение один ко многим в модели ER?

  • SSAS отношение одного ко многим измерениям

    Вопрос в SSAS для вас всех. Я пытаюсь определить отношение один ко многим в среде Куба OLAP SSAS. Однако у меня возникли проблемы с определением первичного ключа. Примеры таблиц приведены ниже. Отношения между первыми 3 таблицами легко определяются (TradeDate, NYMEX Trades & NYMEX Contract)….



23

В первом примере показано отношение «один ко многим», а во втором-отношение «многие ко многим».

Пример Допустим мы используем первый пример

Author
AuthorID

Book
BookID
AuthorID

Как бы вы представили, что и Джейн, и Джон написали книгу «Stackoverflow for fun»? В этой таблице отношений вы не можете, вы выразили, что один автор может написать много книг. Так что либо Джейн написала его, либо Джон. Если бы только один из них написал книги, вы могли бы использовать этот тип отношений. Однако если вы хотите показать, что обе написали эту книгу, вам нужны отношения «многие ко многим».

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


Давайте используем Stackoverflow в качестве примера начиная с отношения один ко многим и заканчивая отношением многие ко многим:
Authors
Joel
Jeff

Books
Stackoverflow Joel

Бедный Джефф, ему не приписывают stackoverflow из вышеприведенного example…so нам нужно это исправить:

Author
Joel
Jeff

Books
Stackoverflow

AuthorBooks
Stackoverflow Jeff
Stackoverflow Joel

Теперь все счастливы…

Поделиться JonH     13 апреля 2012 в 17:22



5

Отношение one-to-many должно быть реализовано с помощью 2 таблиц.

Но отношения, которые вы предлагаете в своем примере (между авторами и книгами), не one-to-many, а many-to-many.

«Автор может написать много книг, и книга может быть написана одним или несколькими авторами. »

И отношение many-to-many должно быть реализовано с помощью 3 таблиц.

Хорошего дня.

Поделиться Cesar Daniel     13 апреля 2012 в 17:29



4

один ко многим — это два стола.

второй — многие ко многим.

Authors
1 Larry Niven
2 Jerry Pournelle

Books
1 Integral Trees
2 King David's Spaceship
3 The Mote in God's eye

AuthorsBooks
1 1
2 2
1 3
2 3

Поделиться Tony Hopkinson     13 апреля 2012 в 17:23


  • Смоделируйте отношение ноль или один ко многим

    Как я должен моделировать отношение ноль или один ко многим в базе данных? Например, запись пользователя может иметь или не иметь родителя. Итак, должна ли моя пользовательская таблица иметь t_user.parent_id или у меня должна быть ассоциативная таблица под названием t_user_hierarchy со столбцами…

  • один ко многим против многих ко многим отношения

    Я только начал изучать базу данных, и меня смущает использование отношений один ко многим и многие ко многим. поэтому я привел простой пример, касающийся отношений между покупателем и едой. Клиенты заказывают еду. 1)Если я использую отношение один ко многим, я скажу, что клиент может заказать еду…



1

Если отношение на самом деле одно ко многим, то нет необходимости в связывающей таблице ( authorConnectsBooks в вашем примере). Однако в вашем примере у вас нет отношения one-to-many, поскольку один автор может написать много книг, а одна книга может быть написана многими авторами. В вашем примере у вас действительно есть отношения many-to-many. Если у вас действительно есть отношение many-to-many, то вам действительно нужна связывающая таблица ( authorConnectsBooks в вашем примере).

Поделиться Justin Cave     13 апреля 2012 в 17:20



0

Как все уже говорили, первое-это отношение «один ко многим», в котором вам не нужна дополнительная таблица. Всего два стола должны работать. Но во втором случае, поскольку это много ко многим реальностям, вам нужно будет добавить дополнительную таблицу, известную как соединение или таблица перекрестных ссылок, поскольку большинство систем управления базами данных поддерживают только отношения one-to-many, необходимо реализовать такие отношения вручную через третью таблицу соединений. Первичный ключ соединительной таблицы обычно формируется с использованием первичных ключей таблиц, которые она соединяет. Вот страница wiki, которая объясняет точно такой же пример, о котором вы спрашивали:

LINK

Поделиться Nemin     30 ноября 2013 в 18:39


Похожие вопросы:


Проблема Проектирования Базы Данных

Я пытаюсь создать базу данных для сервера и инвентаризации баз данных, и я ищу хороший дизайн базы данных. У нас есть таблицы для кластеров серверов, автономных серверов и баз данных. Я хотел бы…


Это отношение «один ко многим» или «многие ко многим»?

Поэтому я делаю диаграмму E/R, основанную на наркотиках. В нем говорится, что каждое лекарственное средство производится данной фармацевтической компанией и торговое наименование препарата…


sql один ко многим

Я просто хочу убедиться, что это отношения один ко многим. У меня есть опрос, в котором есть список флажков, где пользователь может выбрать несколько проблем в списке checkbox. Поэтому я поставил…


Отношения базы данных многие ко многим в модели ER

Как мы можем реализовать корабль отношений многие ко многим в модели ER? Если это невозможно сделать, то почему и какие проблемы возникают при реализации отношений многие ко многим? Почему мы. ..


SSAS отношение одного ко многим измерениям

Вопрос в SSAS для вас всех. Я пытаюсь определить отношение один ко многим в среде Куба OLAP SSAS. Однако у меня возникли проблемы с определением первичного ключа. Примеры таблиц приведены ниже….


Смоделируйте отношение ноль или один ко многим

Как я должен моделировать отношение ноль или один ко многим в базе данных? Например, запись пользователя может иметь или не иметь родителя. Итак, должна ли моя пользовательская таблица иметь…


один ко многим против многих ко многим отношения

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


Отношение один ко многим проектная производительность

Когда мы создаем дизайн базы данных, который включает отношения 1-to-many, существует потенциальный риск потери производительности по мере роста данных в отношениях. Например, возьмем простое…


Пар 2, отношение один ко многим

Есть ли у вас какой-нибудь пример того, как создать отношение один ко многим с помощью Vapor 2? Есть несколько примеров того, как это сделать, но они используют старую версию Vapor. Спасибо вам за…


архитектура базы данных многие ко многим

Я новичок в базах данных , я просто застрял со многими ко многим отношениям данных в моей базе данных. например У меня есть массив действий с первичным ключом Activity_Id , и одно действие может…

Схема данных в Access — Базы данных Access

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

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

Создание схемы данных

Создание схемы данных начинается с выполнения команды Схема данных (Relationships) в группе Отношения (Relationships) на вкладке ленты Работа с базами данных (Database Tools). В результате выполнения этой команды открывается окно схемы данных и диалоговое окно Добавление таблицы (Show Table), в котором осуществляется выбор таблиц, включаемых в схему (см. рис. 3.48). Диалоговое окно Добавление таблицы откроется автоматически, если в базе данных еще не определена ни одна связь. Если окно не открылось, на ленте Работа со связями | Конструктор (Relationship Tools | Design) в группе Связи (Relationships) нажмите кнопку Отобразить таблицу (Show Table).

Включение таблиц в схему данных

В окне Добавление таблицы (Show Table) (рис. 3.48) отображены все таблицы и запросы, содержащиеся в базе данных. Выберем вкладку Таблицы (Tables) и с помощью кнопки Добавить (Add) разместим в окне Схема данных (Relationships) все ранее созданные таблицы базы данных Поставка товаров, отображенные в окне Добавление таблицы (Show Table). Затем нажмем кнопку Закрыть (Close). В результате в окне Схема данных (Relationships) таблицы базы будут представлены окнами со списками своих полей и выделенными жирным шрифтом ключами (см. рис. 3.52).

Создание связей между таблицами схемы данных

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

Создание связей по простому ключу

Установим связь между таблицами ПОКУПАТЕЛЬ и ДОГОВОР, которые находятся в отношении «один-ко-многим». Устанавливая связи между парой таблиц, находящихся в отношении типа 1 : M, выделим в главной таблице ПОКУПАТЕЛЬ ключевое поле КОД_ПОК, по которому устанавливается связь. Далее при нажатой кнопке мыши перетащим его в соответствующее поле подчиненной таблицы ДОГОВОР.

Поскольку поле связи является уникальным ключом в главной таблице связи, а в подчиненной таблице связи не является ключевым, схема данных в Access выявляет отношение «один-ко-многим» между записями этих таблиц. Значение «один-ко-многим» (One-To-Many) отобразится в окне Изменение связей (Edit Relationships) в строке Тип отношения (Relationship Type) (рис. 3.49).

ЗАМЕЧАНИЕ
Если поле связи является уникальным ключом в обеих связываемых таблицах, схема данных в Access выявляет отношение «один-к-одному«. Если для связи таблиц вместо ключевого поля главной таблицы используется некоторый уникальный индекс, система также констатирует отношение таблиц как 1 : М или 1 : 1.

Определение связей по составному ключу

Определим связи между таблицами НАКЛАДНАЯ ОТГРУЗКА, которые связаны по составному ключу НОМ_НАКЛ + КОД_СК. Для этого в главной таблице НАКЛАДНАЯ выделим оба этих поля, нажав клавишу <Ctrl>, и перетащим их в подчиненную таблицу ОТГРУЗКА.

В окне Изменение связей (Edit Relationships) (рис. 3.50) для каждого поля составного ключа главной таблицы НАКЛАДНАЯ, названной Таблица/запрос (Table/Query), выберем соответствующее поле подчиненной таблицы ОТГРУЗКА, названной Связанная таблица/запрос (Related Table/Query).

Каскадное обновление и удаление связанных записей

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

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

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

Установить в окне Изменение связей (Edit Relationships) (см. рис. 3.49) флажки каскадное обновление связанных полей (Cascade Update Related Fields) и каскадное удаление связанных записей (Cascade Delete Related Records) можно только после задания параметра обеспечения целостности данных.

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

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

Вот основное, что мы хотели рассказать на тему «Схема данных в Access».

Дальше будем изучать запросы в Access.

Связь между объектами (одиночная, многие ко многим) ELMA BPM– Y A M B R

Создавая объекты в ELMA BPM — неизбежно придет момент когда нужно будет связать их между собой.

  • Как выбрать правильную связь?

Новичка этот вопрос поставит в тупик, а у опытного возникнут вопросы по неоднозначным вариантам предлагаемым ELMA BPM.

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

Существует 4 типа связей (на примере ELMA BPM):

  • 1-1 — один к одному (например в заказе указан один клиент)
  • 1-N — один ко многим (например у клиента много заказов, но у заказа один клиент )
  • N-N — многие ко многим (например пользователь и группа пользователей — у пользователя много групп и наоборот, в группах много пользователей)
  • N-N (инверсия) — многие ко многим инверсия (пользователь связан N-N c группой, эта же связь обратном направлении называется инверсией )
    • где примененять этот тип связи сложно понять сходу, читайте дальше и поймете — «что это и с чем это едят»

далее подробно рассмотрим каждый тип

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

Вернемся к нашему примеру

  • Заказ (объект) относится к Клиенту (объект)- один к одному, в заказе нужно знать клиента
    • в одном заказе — один клиент

Настройка в ELMA:

  1. Создадим 2 сущности с наименованием — заказ и клиент
  2. Добавим свойство клиент в заказ

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

Как это выглядит в базе данных

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

  • Добавилось только одно поле в таблицу заказа

А вот и таблицы, в поле каждого заказа указан идентификатор клиента:

В справочнике ELMA выглядит так:

Связь 1-N — один ко многим

Помним:

  • у одного клиента — много заказов, нужен список заказов клиента

и тут нюанс — в заказе клиент уже указан:

  • зачем создавать и вручную заполнять список заказов..? пахнет костылем
  • решение — связь 1-N

Настройка в ELMA:

  1. Перейдем в клиента
  2. Добавим свойство заказы
  3. Укажем тип свойства «Множественная (1-N)» и укажем «ключевую колонку» Клиент из объекта Заказ

дальше интереснее

Посмотрим в базу данных

На диаграмме ничего не поменялось и вот почему:

  • база данных знала заранее и нарисовала связь 1-N
  • в направлении Заказ -> Клиент соответствие 1-1 , в обратном N-1 ( это пытались сказать разработчики ELMA в начале)

Таблицы выглядят по прежнему:

На этом чудеса не заканчиваются:

  1. Добавьте еще один заказ клиенту
  2. Теперь откройте карточку клиента

Что тут произошло:

  • ELMA не создавала новое поле в таблице а только создала список в объекте клиент который определяется по свойству клиент в поле объекта заказ

Нюансы работы со связями 1-1 и 1-N (также работает из кода)

  1. Если в заказе указать клиента — он отразится в списке заказов клиента (это известно)
  2. Если в список заказов клиента добавить заказ — в добавленном заказе изменится клиент (поэтому будьте уверены что нужна связь 1-N а не N-N, читайте о ней дальше)

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

Продолжим развивать нашу историю, условия:

  • добавим к заказу промокоды (скидки)
  • у заказов много промокодов, и наоборот промокод применяется в нескольких заказах

по условиям не подходят связи 1-1 и 1-N, попробуем что то новенькое

Настройка в ELMA:

  1. Создадим сущность промокод
  2. Добавим в заказ список промокодов и укажем тип свойства «Многие-ко-многим»

Посмотрим в базу данных

Изменения в базе данных :

  • Появилась развязочная таблица (M_Order_UsedPromocodes)
    • хранит каждое соответствие заказ -> промокод (1-1)
  • если присмотреться в базе данных всегда используется 1-N — так и есть, других связей в реляционных базах не бывает

Посмотрите как работает развязочная таблица:

В справочнике ELMA выглядит так:

Связь N-N (инверсия) — многие ко многим инверсия

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

  • в объекте промокод должны отражаться заказы где применялся этот промокод
  • — нужен список заказов в промокоде

опять связь многие ко многим, но постоянно добавлять заказ в список заказов по промокоду (в объект промокод) — костыль,

снова нужно человеческое решение

Настройка в ELMA:

  1. Добавим в объект промокод свойство применен в заказах
  2. Укажем тип связи «Многие ко многим (инверсия)» и ключевую колонку примененные промокоды

Посмотрим в базу данных

Уже не стоит гадать :

  • в базе данных ничего не изменилось
  • теперь та же связь N-N из заказа — используется в обратном направлении

В таблицах ничего не поменялось:

В справочнике ELMA:

  • добавьте один и тот же промокод в 2 заказа
  • и в промокоде отобразится список заказов

Нюансы работы со связями N-N и N-N(инверсия) (также работает из кода)

  1. Если в заказе указать промокоды — заказы отразятся в промокодах (это уже известно, работает связь N-N)
  2. Если изменить список «применен в заказах» в промокоде (неважно, добавить или удалить) — список промокодов в заказе не изменится (неизвестно так задумано или это недоработка…)

Общие нюансы для связей

  1. В контексте процесса доступно только два варианта связей 1-1 и 1-N (особенность контекста процесса, потому что доступно редактирование контекста без перезагрузки ELMA, но это уже другая история)
  2. Будьте аккуратны с копированием свойств — списков:
    • 1-N — при копировании проверяйте ключевую колонку
      • если запустить «как есть» будет общая связь для разных свойств — что в последствии нарушит целостность базы данных (будут битые связи) и при перестроении базы данных — система не запустится — бомба замедленного действия (починить можно — как расскажу в следующий раз)
      • если открыть свойство на редактирование — ключевая колонка будет пустой и потребуется ее заполнить — тогда все будет хорошо
    • N-N — при копировании проверяйте название развязочной таблицы
      • если запустить «как есть» будет общая развязочная таблица для разных свойств — будут путаться списки и в последствии нарушится целостность базы данных и при перестроении базы данных ELMA не запустится — снова бомба замедленного действия
      • если открыть свойство на редактирование — система не даст сохранить развязочную таблицу с наименованием, которое уже есть в системе — тогда все будет хорошо
    • N-N (инверсия) — при копировании проверяйте ключевую колонку, как с 1-N — последствия те же
  3. Не приравнивайте в коде один список к другому
    • нельзя писать Клиент1.Заказы = Клиент2.Заказы, при сохранении будет ошибка — найдены общие связи коллекций
    • нужно писать Клиент1.Заказы.AddAll( Клиент2.Заказы)
  4. В объектах ELMA BPM разработчики решили даже в незаполненных объектах создавать пустые коллекции
    • не привыкайте к этому, так никто не делает и даже если свойство это список — проверяйте на null (пустоту)
  5. Для создания списков — старайтесь не использовать блоки, тем более если элемент списка — независимый объект.(иногда для создания списка новички создают блок с одним свойством (получается развязочная таблица) — знайте это костыль
  1. Чаще используются связи 1-1 и N-N
  2. 1-N и N-N (инверсия) -ипользуйте с умом

Списки можно вывести таблицей — выведите на форму «Список связанных сущностей»

  • со связями 1-N и N-N(инверсия) можно указать ключевую колонку и получится удобная таблица:
  • со связью N-N придется заморочиться и придумать EQL вот из статья базы знаний

вопросы пишите в комментариях

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Понравилось это:

Нравится Загрузка…

Похожее

Руководство Airtable по отношениям «многие ко многим» — Airtable Support

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

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

Типы отношений

Индивидуальные встречи

Один ко многим

Многие ко многим

Отношения «многие ко многим» и таблицы соединений

Пример 1: Студенты и классы

Пример 2: Кандидаты и интервьюеры

Пример 3: Клиенты, заказы клиентов, продукты и производители

Расчетные поля и таблицы соединений


Типы отношений

Airtable — это база данных.В базах данных есть несколько разных способов описания отношений между разными списками сущностей.

Индивидуальные встречи

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

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

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

  • Люди-паспорта (у каждого человека есть только один паспорт из определенной страны, и каждый паспорт предназначен только для одного человека.)
  • Country-Flag (У каждой страны есть только один флаг, и каждый флаг принадлежит только одной стране.)
  • Супружеские отношения (У каждого человека только один супруг).

Один ко многим

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

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

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

Вот еще несколько примеров отношений «один ко многим»:

  • Люди-Адреса (Каждый человек может проживать по одному адресу, но по каждому адресу может проживать один или несколько человек.)
  • Владельцы-домашние животные (У каждого питомца есть один хозяин, но у каждого владельца может быть одно или несколько домашних животных.)
  • Фермерское оборудование (Каждая единица сельскохозяйственного оборудования принадлежит одному фермеру, но каждый фермер может владеть несколькими единицами оборудования.)

Многие ко многим

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

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

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

Вот еще несколько примеров отношений «многие ко многим»:

  • Ингредиенты-Рецепты (Каждый продукт можно использовать в нескольких рецептах, и каждый рецепт требует нескольких ингредиентов.)
  • Врачи-пациенты (Каждый врач принимает множество пациентов, а каждый пациент — многих врачей.)
  • Сотрудники-Задачи (Каждый сотрудник работает над множеством задач одновременно, в то время как над каждой задачей работает один или несколько сотрудников.)
  • Клиенты-продукты (Каждый покупатель может приобрести множество продуктов, и каждый из этих продуктов может быть приобретен множеством разных клиентов.)

Отношения «многие ко многим» и таблицы соединений

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

Пример 1: Студенты и классы

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

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

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

Мы можем создать новую таблицу, в которой есть поле, связанное со студентами, и поле, связанное с классами. Вы можете назвать таблицу «Оценки», «Зачисление», «Студенты / классы» или как-то иначе, что поможет вам запомнить, что эта таблица является соединительной таблицей между таблицами «Студенты» и «Классы».

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

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

Пример 2: Кандидаты и интервьюеры

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

Пример 3: Клиенты, заказы клиентов, продукты и производители

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

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

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

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

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

Таблица заказов клиентов связана с таблицей клиентов и таблицей позиций заказа:

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

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

И таблица производителей связана с таблицей продуктов по принципу «один ко многим».

Расчетные поля и таблицы соединений

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

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

Затем с помощью формулы можно рассчитать общую стоимость позиции.

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

Базовый учебник по взаимосвязям между базами данных

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

Один к одному

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

Отношения «один к одному» всегда взаимно однозначны, независимо от того, с какой таблицы вы начинаете.

Примеры однозначных отношений:

  • Во многих странах мира супружеские отношения носят индивидуальный характер.
  • Ваш адрес связан с одним почтовым индексом, а этот почтовый индекс привязан к одной географической области.
  • У сотрудника компании единая базовая ставка оплаты труда.
  • Только один посетитель может получить копию библиотечной книги за раз.
  • У клиента компании есть единый идентификатор клиента.
  • Идентификатор учащегося для школы привязан к одному учащемуся.
  • Дед Мороз связан с одним праздником.
  • Водитель обычно имеет одну лицензию.
  • У одного издания книги есть один издатель.
  • Большинство стран имеют один национальный флаг и одну столицу, хотя есть несколько стран с двумя (например, Боливия, Свазиленд и Гондурас) и одна страна с тремя столицами (Южная Африка). Из-за таких редких исключений администраторам баз данных необходимо тщательно продумать, следует ли устанавливать отношения один-к-одному.

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

Один ко многим

В этом отношении есть одна запись с одной стороны отношения и ноль, одна или несколько записей с другой.Это изображено так:

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

Примеры отношений «один ко многим»:

  • У одной книги может быть более одного автора. Например, книга Tube: The Invention of Television 1996 года была написана Дэвидом Э.Фишер и Маршалл Джон Фишер.
  • В городе может быть много почтовых индексов.
  • В штате может быть несколько кодов города.
  • В штате может быть много городов.
  • Клиент может сделать много заказов от поставщика, и в каждом заказе может быть несколько продуктов.
  • Один ученик может быть зарегистрирован во многих классах.
  • Альбом (обычно) содержит много песен.


Многие ко многим

Это наиболее гибкий тип отношений.На одной стороне отношения имеется ноль, одна или несколько записей, а на другой — ноль, одна или несколько записей. Это изображено так:

Примеры отношений «многие ко многим»:

  • Книга может быть связана со многими категориями. Например, Бессмертная жизнь Генриетты Лакс , книга Ребекки Склут 2010 года, связана со следующими категориями Библиотеки Конгресса: Лакс, Генриетта, 1920–1951 — Здоровье; Рак — Пациенты — Вирджиния — Биография; Афро-американские женщины — История / Человеческие эксперименты в медицине — США — История; Клетки HeLa; Рак — Исследования / Культура клеток; Медицинская этика.Каждая из этих категорий связана со многими другими книгами.
  • Члены семьи могут иметь много домашних животных.
  • Рецепты состоят из нескольких ингредиентов, и один ингредиент можно использовать во многих рецептах.
  • У врача много пациентов, и некоторые пациенты обращаются к нескольким врачам.
  • Рабочий может отвечать за множество задач, и каждая задача может выполняться многими работниками.
  • Многие клиенты могут покупать несколько товаров.
  • В каждом классе несколько учеников; каждый учитель ведет несколько классов.
  • У продавца может быть много клиентов, и у каждого клиента может быть много продавцов (особенно, если они являются более крупными клиентами).
  • Пользователь Twitter, вероятно, подписан многими людьми и подписан на многих других; эти две группы не обязательно совпадут.

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

  • Переход
  • Связывание
  • Перекрестная ссылка
  • Отображение
  • Присоединиться к
  • Ассоциативный

Соединительный стол работает так:


Самореференция

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

Расчетные поля

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

Как создать отношение «многие ко многим»

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

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

Что такое отношения «многие ко многим»

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

Рис. 1 Пример отношения «многие ко многим»

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

Соединительный стол

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

Рис. 2 Пример распределительной таблицы

Как создать отношение «многие ко многим» в dbForge Studio для MySQL

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

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

Рис. 3 Создание диаграммы базы данных

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

Рис. 4 Добавление таблиц для создания связи «многие ко многим» между

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

Рис. 5 Создание таблицы соединений для установления отношения «многие ко многим»

4. В диалоговом окне Редактор таблиц введите имя таблицы. Например, соединительная таблица между таблицей Authors и таблицей Books может быть названа Books_Authors .

Рис. 6 Ввод имени соединительного стола

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

Рис.7 Построение соединительного стола

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

Рис. 8 Создание новых отношений

7. Определите отношение «один ко многим» между каждой из двух основных таблиц и таблицей соединений.

Рис. 9 Создание отношения «многие ко многим» между таблицами

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

 ВСТАВИТЬ В tbl_temp2 (fld_id)
     ВЫБЕРИТЕ tbl_temp1.fld_order_id
     ОТ tbl_temp1 ГДЕ tbl_temp1.fld_order_id> 100;
 

Заключение

В базе данных существует три различных типа отношений данных: «один к одному», «один ко многим» и «многие ко многим». И если вы можете справиться с первыми двумя довольно просто, справиться с отношениями «многие ко многим» может оказаться непростой задачей. В этой статье мы предоставили пошаговое руководство, показывающее, как легко установить модель отношений «многие ко многим» с помощью нашего превосходного инструмента dbForge Studio for MySQL.

Загрузите бесплатную 30-дневную пробную версию dbForge Studio для MySQL прямо сейчас и попробуйте функциональность диаграммы базы данных вместе со многими другими мощными функциями лучшего инструмента с графическим интерфейсом пользователя MySQL, который вы можете найти!

Последние сообщения от команды dbForge (посмотреть все)

диаграмма базы данных, studio для mysql

Схема базы данных и типы отношений

Каждая база данных имеет схему . Схема базы данных — это структура, которая представляет способ построения базы данных.Схема базы данных определяет, как данные хранятся в таблицах базы данных и как связаны отношения между таблицами.

В этом уроке мы создадим визуальные представления схемы базы данных и поговорим о наиболее распространенных отношениях между базами данных SQL: * один ко многим * многие-ко-многим * индивидуально

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

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

Это представление включает в себя обе наши таблицы, свойства каждой таблицы и отношения между двумя таблицами.

На данный момент наше приложение довольно простое. Есть таблица на альбомов и таблица на песен . Каждая песня принадлежит к альбому, который мы представляем линией между свойством id в таблице Album и свойством album_id в таблице песен .

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

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

Отношения «многие-ко-многим» сложнее, потому что они связаны с таблицей соединений.Давайте посмотрим на пример: отношение «многие ко многим» между Album s и Artist s.

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

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

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

Иногда объединенная таблица может быть более сложной. Некоторые соединяемые таблицы также имеют другие поля. Примером может быть checkout таблица соединения между Patron s и Book s в библиотеке. due_date книги, скорее всего, попадет в таблицу соединения checkout .

Таблицы соединения могут иметь свои собственные описательные имена, такие как в примере checkout выше. Однако также часто имя представляет собой комбинацию двух соединяемых таблиц.В этом случае имена следует указывать в алфавитном порядке. Другими словами, мы всегда будем называть таблицу соединения для Artist s и Album s Albums_artists , а не художников-альбомов . Нам нужно использовать подчеркивание для разделения имен таблиц, а не символ типа тире, который SQL не примет.

Индивидуальные отношения

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

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

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

Визуальное представление схемы базы данных

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

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

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

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

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

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

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

Когда отношение является «многие ко многим», необходимы три таблицы: по одной для каждого объекта данных и одна для отношения. Сущности ORDER и ITEM в нашем примере имеют отношение «многие ко многим». Первичный ключ каждого объекта данных хранится как внешний ключ реляционной таблицы. Реляционная таблица может просто содержать первичные ключи для каждого объекта данных или может содержать дополнительные данные, такие как оценка, полученная за курс, или количество заказанного элемента.См. Схему таблицы, показанную на Рисунке 13.24. Таблица ORDER ITEM содержит информацию о том, какой заказ содержит какие позиции, и обеспечивает связь между таблицей ORDER и таблицей ITEM MASTER.

Когда отношение «многие-ко многим», необходимы три файла.

Таблица отношений должна быть проиндексирована по каждому внешнему ключу — по одному для каждой из таблиц в отношении — и может иметь первичный ключ, состоящий из комбинации двух внешних ключей. Часто корпорации используют уникальный ключ, например порядковый номер, в качестве первичного ключа для реляционной таблицы.Чтобы найти много записей из второй таблицы с учетом первой таблицы, непосредственно прочитайте реляционную таблицу для нужного ключа. Найдите соответствующую запись во второй таблице many. Продолжайте просматривать реляционную таблицу до тех пор, пока нужный ключ больше не будет найден. Например, чтобы найти записи в ITEM MASTER для конкретной записи в таблице ORDER, непосредственно прочитайте таблицу ORDER-ITEM, используя ORDER-NUMBER в качестве индекса. Записи логически упорядочены на основе данных в индексе, поэтому все записи для одного и того же НОМЕРА ЗАКАЗА группируются вместе.Для каждой записи ORDER-ITEM, которая соответствует желаемому ORDER-NUMBER, непосредственно прочитайте таблицу ITEM MASTER, используя ITEM-NUMBER в качестве индекса.

Логика аналогична обратной ситуации, например, поиск всех заказов для полученного товара с отложенным заказом. Используйте желаемый НОМЕР ПУНКТА, чтобы прочитать таблицу ПУНКТОВ ЗАКАЗА напрямую. Индекс ORDER-ITEM установлен на ITEM-NUMBER. Для всех совпадающих записей ORDER ITEM используйте ORDER-NUMBER для непосредственного чтения таблицы ORDER. Наконец, прочтите таблицу CUSTOMER MASTER напрямую, чтобы получить CUSTOMER-NAME и ADDRESS, используя CUSTOMER-NUMBER в таблице ORDER.

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

Определение отношений между таблицами в базе данных Access — Office

  • Читать 12 минут
  • Применимо к:
    Access 2013, Access 2010, Microsoft Office Access 2007, Microsoft Office Access 2003

В этой статье

Примечание

Office 365 профессиональный плюс переименовывается в Microsoft 365 Apps для предприятий .Дополнительные сведения об этом изменении см. В этом сообщении в блоге.

Оригинальный номер базы знаний: 304466

Примечание

Новичок: требуется знание пользовательского интерфейса на однопользовательских компьютерах. Эта статья относится только к базе данных Microsoft Access (.mdb или .accdb).

Сводка

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

  • Что такое отношения таблиц?
  • Виды связей таблиц
    • Отношения «один ко многим»
    • Отношения «многие ко многим»
    • Индивидуальные отношения
  • Как определить отношения между таблицами
    • Как определить отношение «один ко многим» или «один к одному»
    • Как определить отношение «многие ко многим»
  • Ссылочная целостность
  • Каскадное обновление и удаление
  • Типы соединений

Что такое отношения таблиц?

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

Лучшее решение — сохранить информацию об издателе только один раз в отдельной таблице, которую мы назовем «Издатели». Затем вы поместите указатель в таблице «Заголовки», который ссылается на запись в таблице «Издатели».

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

Логические отношения в базе данных позволяют эффективно запрашивать данные и создавать отчеты.

Виды связей таблиц

Отношение работает путем сопоставления данных в ключевых столбцах, обычно столбцах (или полях) с одинаковыми именами в обеих таблицах. В большинстве случаев связь связывает первичный ключ или столбец уникального идентификатора для каждой строки из одной таблицы с полем в другой таблице.Столбец в другой таблице известен как «внешний ключ». Например, если вы хотите отслеживать продажи каждого названия книги, вы создаете связь между столбцом первичного ключа (назовем его title_ID ) в таблице «Заголовки» и столбцом в таблице «Продажи» с именем . title_ID . Столбец title_ID в таблице «Продажи» является внешним ключом.

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

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

Отношения «один ко многим» — наиболее распространенный вид отношений. При таком виде отношений строка в таблице A может иметь много совпадающих строк в таблице B. Но строка в таблице B может иметь только одну совпадающую строку в таблице A. Например, в таблицах «Издатели» и «Заголовки» есть отношения один-ко-многим. То есть каждый издатель выпускает множество наименований. Но каждое название принадлежит только одному издателю.

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

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

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

В отношении «многие ко многим» строка в таблице A может иметь много совпадающих строк в таблице B, и наоборот. Вы создаете такую ​​связь, определяя третью таблицу, которая называется соединительной таблицей. Первичный ключ соединительной таблицы состоит из внешних ключей как из таблицы A, так и из таблицы B.Например, таблица «Авторы» и таблица «Заголовки» имеют отношение «многие ко многим», которое определяется отношением «один ко многим» от каждой из этих таблиц к таблице «TitleAuthors». Первичный ключ таблицы «TitleAuthors» представляет собой комбинацию столбца au_ID (первичный ключ таблицы «Авторы») и столбца title_ID (первичный ключ таблицы «Заголовки»).

Индивидуальные отношения

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

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

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

В Access сторона первичного ключа взаимно-однозначного отношения обозначается символом ключа. Сторона внешнего ключа также обозначается символом ключа.

Как определить отношения между таблицами

Когда вы создаете связь между таблицами, связанные поля не обязательно должны иметь одинаковые имена. Однако связанные поля должны иметь один и тот же тип данных, если только поле первичного ключа не является полем AutoNumber.Вы можете сопоставить поле AutoNumber с полем Number, только если свойствоFieldSize обоих совпадающих полей одинаково. Например, вы можете сопоставить поле AutoNumber и поле Number, если свойство FieldSize обоих полей равно Long Integer. Даже если оба совпадающих поля являются числовыми полями, они должны иметь одинаковое значение свойстваFieldSizeproperty.

Как определить отношение «один ко многим» или «один к одному»

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

  1. Закройте все таблицы.Вы не можете создавать или изменять отношения между открытыми таблицами.

  2. В Access 2002 или Access 2003 выполните следующие действия:

    1. Нажмите F11, чтобы переключиться в окно базы данных.
    2. В меню Инструменты щелкните Взаимосвязи .

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

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

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

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

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

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

    Установите параметры взаимосвязи, если это необходимо. Если вам нужна информация об определенном элементе в диалоговом окне Изменить отношения , нажмите кнопку со знаком вопроса, а затем щелкните элемент. (Эти параметры будут подробно описаны позже в этой статье.)

  7. Щелкните Создать , чтобы создать отношение.

  8. Повторите шаги с 4 по 7 для каждой пары таблиц, которую вы хотите связать.

    Когда вы закрываете диалоговое окно Изменить отношения , Access спрашивает, хотите ли вы сохранить макет.Независимо от того, сохраняете ли вы макет или нет, созданные вами связи сохраняются в базе данных.

    Примечание

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

Как определить отношение «многие ко многим»

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

  1. Создайте две таблицы, которые будут иметь отношение «многие ко многим».

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

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

    Примечание

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

    1. Откройте таблицу в режиме конструктора.

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

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

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

      Примечание

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

  4. Определите отношение «один ко многим» между каждой первичной таблицей и таблицей соединений.

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

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

  • Соответствующее поле из первичной таблицы является первичным ключом или имеет уникальный индекс.
  • Связанные поля имеют один и тот же тип данных. Есть два исключения. Поле AutoNumber может быть связано с полем Number , для которого значение свойства FieldSize равно Long Integer, а поле AutoNumber с параметром свойства FieldSize для идентификатора репликации может быть связано с номером . поле, которое имеет значение свойства FieldSize для идентификатора репликации.
  • Обе таблицы принадлежат одной базе данных Access.Если таблицы являются связанными таблицами, они должны быть таблицами в формате Access, и вы должны открыть базу данных, в которой они хранятся, чтобы установить ссылочную целостность. Ссылочная целостность не может быть применена для связанных таблиц из баз данных в других форматах.

При использовании ссылочной целостности применяются следующие правила:

  • Вы не можете ввести значение в поле внешнего ключа связанной таблицы, которое не существует в первичном ключе первичной таблицы. Однако вы можете ввести значение Null во внешний ключ.Это указывает на то, что записи не связаны. Например, у вас не может быть заказа, назначенного несуществующему клиенту. Однако у вас может быть заказ, который никому не назначен, путем ввода значения Null в поле CustomerID .
  • Вы не можете удалить запись из первичной таблицы, если совпадающие записи существуют в связанной таблице. Например, вы не можете удалить запись сотрудника из таблицы «Сотрудники», если в таблице «Заказы» есть заказы, назначенные этому сотруднику.
  • Вы не можете изменить значение первичного ключа в первичной таблице, если у этой записи есть связанные записи. Например, вы не можете изменить идентификатор сотрудника в таблице «Сотрудники», если этому сотруднику назначены заказы в таблице «Заказы».

Каскадное обновление и удаление

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

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

Примечание

Если первичным ключом в первичной таблице является поле AutoNumber, установка флажка Cascade Update Related Fields не действует, поскольку вы не можете изменить значение в поле AutoNumber.

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

Типы соединений

Есть три типа соединения. Вы можете увидеть их на следующем снимке экрана:

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

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

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

Отношения «многие ко многим» | Моделирование данных

В мире моделирования данных существует несколько типов отношений между сущностями. В этой статье мы расскажем вам больше о типе отношений «многие ко многим».

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

Отношения «многие ко многим» между сотрудником и проектом.

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

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

Для этого выберите инструмент «Вставить связь« многие ко многим »» в меню инструментов рисования (см. Рисунок 1). Теперь щелкните сущность «Сотрудник» и отпустите кнопку мыши, когда вы окажетесь над сущностью «Проект». DeZign для баз данных теперь автоматически разрешит отношение «многие ко многим» и создаст для вас объект пересечения Employee_Project (см. Рисунок 2).Первичный ключ сущности «Сотрудник» и первичный ключ сущности «Проект» образуют первичный ключ новой сущности пересечения.

Рисунок 1. Выберите инструмент «Вставить связь многие ко многим»

Рисунок 2: Создан новый объект пересечения.

.