Access

Как сделать связь многие ко многим в access: MS Access — отношения «многие ко многим»

Содержание

база данных — Пример связи «многие-ко-многим»

Вопрос задан

Изменён 4 года 11 месяцев назад

Просмотрен 109k раза

Здравствуйте! Не могу понять связь «многие ко многим». Что она значит? Приведите, пожалуйста, пример, когда эту связь нужно устанавливать. Лучше даже пример из жизни приведите, пожалуйста, когда такая связь осуществляется.

  • база-данных

«Один-ко-многим» — тип связи таблиц, когда одной записи главной таблицы можно сопоставить несколько записей подчинённой таблицы. Это наиболее частый вид связи между таблицами. Ну, например, если создавать телефонный справочник, то необходимо учесть, что у одного человека может быть несколько телефонов (2 мобильных, 1 домашний и 1 служебный).

Или ещё пример: студент (записи о студентах хранятся в главной таблице) обучается в ВУЗе — он изучает несколько предметов (записи о предметах хранятся в подчинённой таблице), по которым сдаёт экзамены и зачёты.

А связь «многие-ко-многим» возникает в тех случаях, когда одной записи одной таблицы может соответствовать несколько записей другой таблицы и наоборот: когда одной записи второй таблицы может соответствовать несколько записей первой таблицы. От такого типа связи следует избавляться и приводить к виду «один-ко-многим». Пример такого вида связи: имеем 2 таблицы «Товары» и «Клиенты», каждый клиент может приобрести несколько товаров, в свою очередь каждый товар (по наименованию) может быть приобретён (или заказан) несколькими клиентами. Ещё пример (по ВУЗ): пусть есть 2 таблицы «Преподаватель» и «Студент», каждый преподаватель может обучать нескольких студентов, в то же время каждый студент может обучаться у нескольких преподавателей.

3

К примеру есть у нас некий список людей:

people

id | name | last_name

и список книг

books

id | name | author

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

people_book_like

people_id | book_id | liked_time

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

Далеко ходить не будем и возьмем примеры из жизни: Допустим создаем БД описывающее работу какой-то школы

  1. Каждая школа гарантированно имеет 1-го директора. Это связь 1 к 1. 1 школа -> 1 директор

  2. В каждой школе есть несколько классов это связь 1 ко многим. 1 школа -> много классов

  3. Теперь учителя предметники. Если попробовать составить таблицу отношений учителей с классами то получим довольно сложную картину: 1 учитель может преподавать в нескольких классах, в то же самое время в одном классе может преподавать несколько учителей. Это и есть классическое отношение многие ко многим. Несколько учителей <-> Несколько классов.

Как уже было верно сказано выше такие связи принято описывать промежуточной таблицей связи

Зарегистрируйтесь или войдите

Регистрация через Google

Регистрация через Facebook

Регистрация через почту

Отправить без регистрации

Почта

Необходима, но никому не показывается

Отправить без регистрации

Почта

Необходима, но никому не показывается

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

Связи между таблицами базы данных / Хабр

1.

Введение

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

1.1. Для кого эта статья?

Эта статья будет полезна тем, кто хочет разобраться со связями между таблицами базы данных. В ней я постарался рассказать на понятном языке, что это такое. Для лучшего понимания темы, я чередую теоретический материал с практическими примерами, представленными в виде диаграммы и запроса, создающего нужные нам таблицы. Я использую СУБД Microsoft SQL Server и запросы пишу на T-SQL. Написанный мною код должен работать и на других СУБД, поскольку запросы являются универсальными и не используют специфических конструкций языка T-SQL.

1.2. Как вы можете применить эти знания?


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

2. Благодарности

Учтены были советы и критика авторов jobgemws, unfilled, firnind, Hamaruba.
Спасибо!

3.1. Как организовываются связи?

Связи создаются с помощью внешних ключей (foreign key).
Внешний ключ — это атрибут или набор атрибутов, которые ссылаются на primary key или unique другой таблицы. Другими словами, это что-то вроде указателя на строку другой таблицы.

3.2. Виды связей

Связи делятся на:

  1. Многие ко многим.
  2. Один ко многим.
    • с обязательной связью;
    • с необязательной связью;
  3. Один к одному.
    • с обязательной связью;
    • с необязательной связью;

Рассмотрим подробно каждый из них.

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

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

  • Работник может иметь одну и более должностей. Например, некий работник может быть и админом, и программистом.
  • Должность может «владеть» одним и более работников. Например, админами является определенный набор работников. Другими словами, к админам относятся некие работники.

Работников представляет таблица «Employee» (id, имя, возраст), должности представляет таблица «Position» (id и название должности). Как видно, обе эти таблицы связаны между собой по правилу многие ко многим: каждому работнику соответствует одна и больше должностей (многие должности), каждой должности соответствует один и больше работников (многие работники).

4.1. Как построить такие таблицы?

Мы уже имеем две таблицы, описывающие работника и профессию. Теперь нам нужно установить между ними связь многие ко многим. Для реализации такой связи нам нужен некий посредник между таблицами «Employee» и «Position». В нашем случае это будет некая таблица «EmployeesPositions» (работники и должности). Эта таблица-посредник связывает между собой работника и должность следующим образом:

EmployeeId PositionId
1 1
1 2
2 3
3 3

Слева указаны работники (их id), справа — должности (их id). Работники и должности на этой таблице указываются с помощью id’шников.

На эту таблицу можно посмотреть с двух сторон:

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

4.2. Реализация


Диаграмма



Код на T-SQL

create table dbo.Employee
(
	EmployeeId int primary key,
	EmployeeName nvarchar(128) not null,
	EmployeeAge int not null
)
-- Заполним таблицу Employee данными.
insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (1, N'John Smith', 22)
insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (2, N'Hilary White', 22)
insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (3, N'Emily Brown', 22)
create table dbo.Position
(
	PositionId int primary key,
	PositionName nvarchar(64) not null
)
-- Заполним таблицу Position данными.
insert into dbo.Position(PositionId, PositionName) values(1, N'IT-director')
insert into dbo.
  Position(PositionId, PositionName) values(2, N'Programmer')
insert into dbo.Position(PositionId, PositionName) values(3, N'Engineer')
-- Заполним таблицу EmployeesPositions данными.
create table dbo.EmployeesPositions
(
	PositionId int foreign key references dbo.Position(PositionId),
	EmployeeId int foreign key references dbo.Employee(EmployeeId),
	primary key(PositionId, EmployeeId)
)
insert into dbo.EmployeesPositions(EmployeeId, PositionId) values (1, 1)
insert into dbo.EmployeesPositions(EmployeeId, PositionId) values (1, 2)
insert into dbo.EmployeesPositions(EmployeeId, PositionId) values (2, 3)
insert into dbo.EmployeesPositions(EmployeeId, PositionId) values (3, 3)


Объяснения

С помощью ограничения foreign key мы можем ссылаться на primary key или unique другой таблицы. В этом примере мы

  • ссылаемся атрибутом PositionId таблицы EmployeesPositions на атрибут PositionId таблицы Position;
  • атрибутом EmployeeId таблицы EmployeesPositions — на атрибут EmployeeId таблицы Employee;


4.

3. Вывод

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

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

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

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

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

Другими словами, телефон принадлежит только одному пользователю. А пользователю могут принадлежать 1 и более телефонов (многие).

Как мы видим, это отношение один ко многим.

5.1. Как построить такие таблицы?

Пользователей будет представлять некая таблица «Person» (id, имя, фамилия, возраст), номера телефонов будет представлять таблица «Phone». Она будет выглядеть так:

PhoneId PersonId PhoneNumber
1 5 11 091-10
2 5 19 124-66
3 17 21 972-02

Данная таблица представляет три номера телефона. При этом номера телефона с id 1 и 2 принадлежат пользователю с id 5. А вот номер с id 3 принадлежит пользователю с id 17.

Заметка

. Если бы у таблицы «Phones» было бы больше атрибутов, то мы смело бы их добавляли в эту таблицу.

5.2. Почему мы не делаем тут таблицу-посредника?

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

  1. Каждому работнику принадлежат несколько должностей (многие).
  2. Каждой должности принадлежит несколько работников (многие).

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

5.3. Реализация

Диаграмма



Код на T-SQL

create table dbo.Person
(
	PersonId int primary key,
	FirstName nvarchar(64) not null,
	LastName nvarchar(64) not null,
	PersonAge int not null
)
insert into dbo.Person(PersonId, FirstName, LastName, PersonAge) values (5, N'John', N'Doe', 25)
insert into dbo.Person(PersonId, FirstName, LastName, PersonAge) values (17, N'Izabella', N'MacMillan', 19)
create table dbo. Phone
(
	PhoneId int primary key,
	PersonId int foreign key references dbo.Person(PersonId),
	PhoneNumber varchar(64) not null
)
insert into dbo.Phone(PhoneId, PersonId, PhoneNumber) values (1, 5, '11 091-10')
insert into dbo.Phone(PhoneId, PersonId, PhoneNumber) values (2, 5, '19 124-66')
insert into dbo.Phone(PhoneId, PersonId, PhoneNumber) values (3, 17, '21 972-02')


Объяснения

Наша таблица Phone хранит всего один внешний ключ. Он ссылается на некого пользователя (на строку из таблицы Person). Таким образом, мы как бы говорим: «этот пользователь является владельцем данного телефона». Другими словами, телефон знает id своего владельца.


6. Один к одному

Представим, что на работе вам дали задание написать БД для учета всех работников для HR. Начальник уверял, что компании нужно знать только об имени, возрасте и телефоне работника. Вы разработали такую БД и поместили в нее всю 1000 работников компании. И тут начальник говорит, что им зачем-то нужно знать о том, является ли работник инвалидом или нет. Наиболее простое, что приходит в голову — это добавить новый столбец типа bool в вашу таблицу. Но это слишком долго вписывать 1000 значений и ведь true вы будете вписывать намного реже, чем false (2% будут true, например).

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

DisabledPersonId EmployeeId
1 159
2 722
3 937

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

только

уникальные значения.

Выполнив это мы получили связь один к одному.

Заметка. Обратите внимание на то, что мы могли также наложить на атрибут EmloyeeId ограничение primary key. Оно отличается от ограничения unique лишь тем, что не может принимать значения null.

6.1. Вывод

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

6.2. Реализация


Диаграмма



Код на T-SQL

create table dbo.Employee
(
	EmployeeId int primary key,
	EmployeeName nvarchar(128) not null,
	EmployeeAge int not null
)
insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (159, N'John Smith', 22)
insert into dbo. Employee(EmployeeId, EmployeeName, EmployeeAge) values (722, N'Hilary White', 29)
insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (937, N'Emily Brown', 19)
insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (100, N'Frederic Miller', 16)
insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (99, N'Henry Lorens', 20)
insert into dbo.Employee(EmployeeId, EmployeeName, EmployeeAge) values (189, N'Bob Red', 25)
create table dbo.DisabledEmployee
(
	DisabledPersonId int primary key,
	EmployeeId int unique foreign key references dbo.Employee(EmployeeId)
)
insert into dbo.DisabledEmployee(DisabledPersonId, EmployeeId) values (1, 159)
insert into dbo.DisabledEmployee(DisabledPersonId, EmployeeId) values (2, 722)
insert into dbo.DisabledEmployee(DisabledPersonId, EmployeeId) values (3, 937)


Объяснения

Таблица DisabledEmployee имеет атрибут EmployeeId, что является внешним ключом. Он ссылается на атрибут EmployeeId таблицы Employee. Кроме того, этот атрибут имеет ограничение unique, что говорит о том, что в него могут быть записаны только уникальные значения. Соответственно, работник может быть записан в эту таблицу не более одного раза.


7. Обязательные и необязательные связи

Связи можно поделить на обязательные и необязательные.

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


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

Одну и ту же связь можно рассматривать как обязательную и как необязательную. Рассмотрим вот такой пример:

У одной биологической матери может быть много детей. У ребенка есть только одна биологическая мать.

А) У женщины необязательно есть свои дети. Соответственно, связь необязательна.
Б) У ребенка обязательно есть только одна биологическая мать – в таком случае, связь обязательна.

7.2. Один к одному


  1. Один к одному с обязательной связью:
    У одного гражданина определенной страны обязательно есть только один паспорт этой страны. У одного паспорта есть только один владелец.
  2. Один к одному с необязательной связью:
    У одной страны может быть только одна конституция. Одна конституция принадлежит только одной стране. Но конституция не является обязательной. У страны она может быть, а может и не быть, как, например, у Израиля и Великобритании.

Одну и ту же связь можно рассматривать как обязательную и как необязательную:

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

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

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

Любая связь многие ко многим является необязательной. Например:

Человек может инвестировать в акции разных компаний (многих). Инвесторами какой-то компании являются определенные люди (многие).

А) Человек может вообще не инвестировать свои деньги в акции.
Б) Акции компании мог никто не купить.

8. Как читать диаграммы?

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

Мы видим отношение один ко многим. Одной персоне принадлежит много телефонов.

  1. Возле таблицы Person находится золотой ключик. Он обозначает слово «один».
  2. Возле таблицы Phone находится знак бесконечности. Он обозначает слово «многие».

9. Итоги


  1. Связи бывают:
    • Многие ко многим.
    • Один ко многим.
      1) с обязательной связью;
      2) с необязательной связью.
    • Один к одному.
      1) с обязательной связью;
      2) с необязательной связью.
  2. Связи организовываются с помощью внешних ключей.
  3. Foreign key (внешний ключ) — это атрибут или набор атрибутов, которые ссылаются на primary key или unique другой таблицы. Другими словами, это что-то вроде указателя на строку другой таблицы.

10. Задачи

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

  1. Описать таблицу фильм: id, название, длительность, режиссер, жанр фильма. Обратите внимание на то, что у фильма может быть более одного жанра, а к одному жанру может относится более, чем один фильм.
  2. Описать таблицу песня: id, название, длительность, певец. При этом у песни может быть более одного певца, а певец мог записать более одной песни.
  3. Реализовать таблицу машина: модель, производитель, цвет, цена
    • Описать отдельную таблицу производитель: id, название, рейтинг.
    • Описать отдельную таблицу цвета: id, название.

    У одной машины может быть только один производитель, а у производителя — много машин. У одной машины может быть много цветов, а у одного цвета может быть много машин.
  4. Добавить в БД из пункта 6.2. таблицу военно-обязанных по типу того, как мы описали отдельную таблицу DisabledEmployee.

Обеспечение связи «многие ко многим» в Access

Внедрение связи «многие ко многим» в Access

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

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

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

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

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

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

Таблица А

Таблица
Имя 		Поле
Имя 		Данные
Тип
Книги BookID
(ПК)		 Автономер
Титул Текст
ISBN Текст
АвторIDFK Номер
Авторы AuthorID
(ПК)		 Автономер
Фамилия Текст
Имя Текст

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

  • Книги:
    TitleISBN
  • Авторы:
    ФамилияИмя

На рисунке A показано отношение «один ко многим» между Books и
Авторы.

Рисунок А

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

На рисунке B
представлена ​​типичная форма ввода данных. (Мы использовали мастер AutoForm и
основывали форму на таблице Authors.) Мастер
автоматически представляет отношение «один ко многим» в схеме «основная/подчиненная», где основная форма
0007 отображает записи на стороне одна сторона
отношения (таблица Авторы), а подчиненная форма отображает сторону много (таблица Книги). Форма
выглядит так, как будто она может обрабатывать нескольких авторов для одной и той же книги, но попробуйте
ввести следующие записи книги:

  • Руководство по обновлению
    для Microsoft Office System 2003, 0-7897-3176-2 Майк Гандерлой и
    Сьюзен Харкинс
  • Автоматизация
    Microsoft Access 2003 с VBA, 0-7897-3244-0 Майк Гандерлой и Сьюзан
    Харкинс

Рисунок B показывает
запись для Сьюзен Харкинс после ввода бухгалтерских книг для Майка Гандерлоя. Когда
вы пытаетесь сохранить запись, Access отображает ошибку, поскольку записи книги
в подчиненной форме нарушают уникальный индекс таблицы. (Вы вошли в эти книги, когда
вошли в запись Майка Гандерлоя.)

Как видно из Рисунок
C , Access сохранил имена авторов и записи обеих книг, но книг 9.0007 относится только к Майку Гандерлою (значение AuthorIDFK 1). Невозможно связать эти две книги с более чем одним автором. Без уникального индекса в полях Название
и ISBN Access сохраняет каждую запись книги дважды, но повторение данных
нарушает первую нормальную форму нормализации — для каждой книги должна быть только одна запись
.

Рисунок В

Вы можете подумать, что эта форма может работать с книгами, написанными более чем одним автором….

Рисунок С

… Но Access не может связать книги со вторым автором.

Приспособление отношения «многие ко многим» представляет собой простой четырехэтапный процесс
:

  1. Удалить
    существующую связь между двумя таблицами.
  2. Создайте
    ассоциированную таблицу и включите поле внешнего ключа для обеих связанных
    таблиц данных.
  3. Создайте
    отношение «один ко многим» между каждой из таблиц данных и
    соответствующим внешним ключом в ассоциированной таблице.
  4. Удалить
    поле внешнего ключа в таблице many
    исходной связи «один ко многим».

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

  • AuthorBookID
    (Автонумерация)
  • BookIDFK
    (Номер)
  • АвторIDFK
    (Номер)

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

Теперь назначьте уникальный многопольный индекс как для BookIDFK 9,0007 и поля AuthorIDFK. Откройте окно «Отношения», добавьте AuthorsBooksmm и создайте
следующие отношения «один ко многим», как показано на рис. D :

.
  • Books:BookID
    в AuthorsBooksmm:BookIDFK
  • Authors:AuthorID to AuthorsBooksmm:AuthorIDFK.

Закройте окно «Взаимосвязи» и сохраните изменения. Затем
откройте таблицу «Книги» и удалите AuthorIDFK. Закройте и сохраните таблицу авторов.

Рисунок D

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

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

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

Чтобы продолжить наш пример, создайте запрос, показанный на рис. E , и сохраните его как AuthorsBooks.
В настоящее время запрос не отображает записей, так как в ассоциированной таблице
нет записей, связывающих две книги с любым из авторов. Откройте AuthorsBooksmm и
, введите две записи, показанные в Рисунок F ,
, которые связывают обе книжные записи с автором Майком Гандерлоем.

Рисунок Е

Создайте новую форму ввода данных на основе этого запроса.

Рисунок F

Эти две записи связывают обе книги с Майком Гандерлоем.

Используйте мастер форм (не мастер автоформ) для создания новой формы
на основе запроса AuthorsBooks. Включите все поля и выберите представление подчиненной формы
, как показано на рисунке G . Заполненная форма
правильно отображает автора Майка Гандерлоя как автора для
обеих книжных записей.

Рисунок G

Мастер форм распознает отношения между тремя таблицами.

На этом этапе вы можете легко добавить Сьюзен Харкинс в обе книжные записи
, но здесь ситуация становится немного затруднительной, особенно
, если вы преобразуете отношение, в котором данные уже существуют. Susan Harkins
уже существует в таблице Authors; таким образом, ввод Susan Harkins в подчиненную форму
вызовет ошибку дубликатов. Без уникального индекса Access
позволяет ввести Сьюзен Харкинс, создав дубликат записи.

Простое исправление состоит в том, чтобы превратить поле внешнего ключа в подчиненной форме
в поле со списком, а затем выбрать существующего автора из списка или ввести
нового. Чтобы выполнить эту задачу, откройте заполненную форму в представлении «Дизайн» и
измените связанный элемент управления поля внешнего ключа (AuthorIDFK) на поле со списком. (Щелкните правой кнопкой мыши
элемент управления, выберите «Изменить на», а затем выберите «Поле со списком
».) Задайте для свойства «Источник строки» элемента управления «поле со списком» следующий код SQL 9.Оператор 0007:

 ВЫБЕРИТЕ AuthorID, Фамилию, Имя ОТ авторов ORDER BY LastName

Кроме того, установите для свойства Column Count значение 3. Вернитесь к
представлению формы и отобразите раскрывающийся список элемента управления, как показано на Рисунок H . Выберите Susan Harkins и повторите
для записи второй книги.

Рисунок H

Выберите автора из раскрывающегося списка нового поля со списком.

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

Рисунок I

Связанная таблица поддерживает эти отношения.

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

Сьюзан Сейлз Харкинс —
независимый консультант и автор нескольких статей и книг по
базам данных и веб-технологиям. Ее последние книги Автоматизация
Microsoft Access 2003 с помощью VBA , Руководство по обновлению
для Microsoft Office System 2003 , ICDL
Практические вопросы Exam Cram , ICDL
Exam Cram 7 Абсолютный Cram 2 , , Руководство по Microsoft Access 2003 и Absolute
Руководство для начинающих по Microsoft Access 2002 ,
с Майком Гандерлоем, все опубликовано Que. В настоящее время Сьюзан работает добровольцем в качестве директора по публикациям
в Database Advisors.

Сьюзен Харкинс

Опубликовано: . Изменено: Увидеть больше Управление данными Поделиться: создание отношений «многие ко многим» в Access
  • Управление данными

Выбор редактора

  • Изображение: Rawpixel/Adobe Stock ТехРеспублика Премиум

    Редакционный календарь TechRepublic Premium: ИТ-политики, контрольные списки, наборы инструментов и исследования для загрузки

    Контент TechRepublic Premium поможет вам решить самые сложные проблемы с ИТ и дать толчок вашей карьере или новому проекту.

    Персонал TechRepublic

    Опубликовано: Изменено: Читать далее Узнать больше
  • Изображение: ириска/Adobe Stock Искусственный интеллект

    Шпаргалка ChatGPT: полное руководство на 2023 год

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

    Меган Краус

    Опубликовано: Изменено: Читать далее Увидеть больше Искусственный интеллект
  • Изображение: Nuthawut/Adobe Stock
  • Изображение: Song_about_summer/Adobe Stock Безопасность

    1Password стремится к будущему без паролей. Вот почему

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

    Карл Гринберг

    Опубликовано: Изменено: Читать далее Узнать больше Безопасность
  • Изображение: klss777/Adobe Stock Безопасность

    10 основных рисков безопасности и операционных рисков с открытым исходным кодом в 2023 году

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

    Франклин Океке

    Опубликовано: Изменено: Читать далее Узнать больше Безопасность
  • Изображение: Джек Уоллен/TechRepublic Разработчик

    Как исправить установку Docker Desktop Linux с добавлением двух файлов

    Джек Валлен покажет вам, что делать, если вы столкнулись с ситуацией, когда вы установили Docker в Linux, но ему не удается подключиться к Docker Engine.

    Джек Уоллен

    Опубликовано: Изменено: Читать далее Увидеть больше Разработчик

Управление связями «многие ко многим» в Microsoft Access | Решения для баз данных для Microsoft Access

Управление отношениями «многие ко многим» в Microsoft Access:

Как упоминалось ранее (см. Отношения таблиц), СУБД не поддерживают отношения «многие ко многим». между столами. Вот пример такого типа отношений:

СОТРУДНИКИ
Идентификатор сотрудника Фамилия Имя номер проекта
EN1-26 О’Брайен Шон 30-452-Т3
EN1-26 О’Брайен Шон 30-457-Т3
EN1-26 О’Брайен Шон 31-124-Т3
EN1-33 Гайя Эми 30-452-Т3
EN1-33 Гайя Эми 30-482-ТК
EN1-33 Гайя Эми 31-124-Т3
EN1-35 Баранко Стивен 30-452-Т3
EN1-35 Баранко Стивен 31-238-ТК
EN1-36 Рослин Элизабет 35-152-ТК
EN1-38 Шааф Кэрол 36-272-ТК
EN1-40 Крыло Александра 31-238-ТК
EN1-40 Крыло Александра 31-241-ТК
ПРОЕКТЫ
номер проекта Название проекта ID сотрудника
30-452-Т3 Деревообработка вокруг дома ЕН1-26
30-452-Т3 Деревообработка вокруг дома ЕН1-33
30-452-Т3 Деревообработка вокруг дома ЕН1-35
30-457-Т3 Основная бытовая электроника ЕН1-26
30-482-ТК Полное руководство по ремонту американских автомобилей ЕН1-33
31-124-Т3 Спорт дельтапланеризма ЕН1-26
31-124-Т3 Спорт дельтапланеризма ЕН1-33
31-238-ТК Полный справочник по бейсболу ЕН1-35
31-238-ТК Полный справочник по бейсболу ЕН1-35
31-241-ТК Улучшение вашей игры в теннис ЕН1-40
35-152-ТК Управление личными финансами ЕН1-36
36-272-ТК Эффективное использование электронной почты ЕН1-38

Выше таблицы с отношением «многие ко многим»

Обычное решение состоит в том, чтобы разбить это отношение на два отношения «один ко многим».

Добавить комментарий

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