Меню

Зачем создают связи между таблицами



Руководство по межтабличным связям

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

В этой статье

Введение

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

1. Эта форма содержит данные из таблицы клиентов,

4. и сведений о заказах.

Имя клиента в поле Плательщик получено из таблицы «Клиенты», значения кода заказа и даты заказа — из таблицы «Заказы», наименование товара — из таблицы «Товары», а цена и количество — из таблицы «Заказано». Чтобы можно было передать данные в форму, эти таблицы связаны друг с другом несколькими способами.

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

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

2. и как внешний ключ.

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

В Access есть три типа связей между таблицами.

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

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

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

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

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

Зачем создавать связи между таблицами?

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

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

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

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

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

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

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

Понятие о целостности данных

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

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

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

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

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

Просмотр связей между таблицами

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

Вызов окна «Схема данных»

Щелкните «Файл», выберите«Открыть», а затем выберите и откройте базу данных.

На вкладке Работа с базами данных в группе Отношения нажмите кнопку Схема данных.

На вкладке Конструктор в группе Связи нажмите кнопку Все связи.

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

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

Читайте также:  Таблица кормления GHE Flora Nova

Когда открыто окно «Схема данных», на ленте доступны указанные ниже команды.

На вкладке Конструктор в группе Сервис

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

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

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

На вкладке Конструктор в группе Отношения

Добавление таблиц (добавление таблицы в Access 2013 Позволяет показывать в окне «Отношения» выбор таблиц.

Скрыть таблицу . Скрывает выбранную таблицу в окне «Схема данных».

Прямые связи . Отображает все связи и связанные таблицы для выбранной таблицы в окне «Схема данных», если они еще не отображены.

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

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

Источник

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

1. Введение

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

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

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

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

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. Как построить такие таблицы?

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. Реализация

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

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

4.3. Вывод

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

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

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

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

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

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

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

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

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. Реализация

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. Реализация

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

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

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

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

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

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

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

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

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

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

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

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

9. Итоги

10. Задачи

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

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

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

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

Источник

Зачем создают связи между таблицами

1. Введение

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

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

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

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

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. Как построить такие таблицы?

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. Реализация

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

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

4.3. Вывод

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

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

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

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

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

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

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

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

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. Реализация

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. Реализация

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

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

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

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

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

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

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

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

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

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

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

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

9. Итоги

10. Задачи

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

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

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

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

Источник

SQL для начинающих: часть 3 — связи базы данных

Russian (Pусский) translation by Yuri Yuriev (you can also view the original English article)

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

Вы также можете увидеть базы данных SQL в действии, просмотрев SQL scripts, apps and add-ons на рынке Envato.

Напоминание

Введение

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

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

  • Отношения один к одному
  • Отношения «один ко многим» и «многие к одному»
  • «Многие ко многим» отношения
  • Самостоятельные ссылки

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

  • Перекрестные соединения
  • Обычные соединения
  • Внутренние соединения
  • Левые (внешние) соединения
  • Правые (внешние) соединения

Мы также узнаем об оговорках ON и USING.

Отношения один к одному

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

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

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

Обратите внимание: теперь в таблице Customers есть поле с именем «address_id», которое ссылается на запись соответствия в таблице Address. Это называется «Foreign Key» и используется для всех видов отношений баз данных. Мы рассмотрим этот вопрос позже.

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

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

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

Это наиболее часто используемый тип отношений. Рассмотрим веб-сайт e-commerce со следующим:

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

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

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

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

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

Для этих отношений нам нужно создать дополнительную таблицу:

Таблица Items_Orders имеет только одну цель, а именно, чтобы создать отношение «многие ко многим» между элементами и заказами.

Вот картинка таких отношений:

Если вы хотите включить записи items_orders в график, это может выглядеть так:

Самостоятельные ссылки

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

Клиенты 102 и 103 были переданы клиентом 101.

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

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

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

Foreign Keys

До сих пор мы узнали только о некоторых концепциях. Теперь пришло время воплотить их в жизнь с помощью SQL. Для этой части нам нужно понять, что такое Foreign Keys.

В приведённых выше примерах отношений мы всегда имели эти поля «**** _ id», которые ссылались на столбец в другой таблице. В этом примере столбец customer_id в таблице Orders является столбцом Foreign Key:

В базе данных типа MySQL есть два способа создания столбцов внешних ключей:

Чёткое определение Foreign Key

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

Теперь таблицу заказов, в которой будет Foreign Key:

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

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

Без явной декларации

Та же таблица заказов может быть создана без явного объявления столбца customer_id как Foreign Key:

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

Далее мы собираемся узнать о JOIN-запросах.

Визуализация отношений

Моим любимым программным обеспечением для проектирования баз данных и визуализации отношений Foreign Key является MySQL Workbench.

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

JOIN Queries

Для извлечения данных из базы, имеющей отношения, нам часто приходится использовать JOIN queries.

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

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

Перекрестное соединение

Это тип JOIN query по умолчанию, если условие не указано.

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

Ключевое слово JOIN может быть опционально заменено запятой.

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

Обычное соединение

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

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

Внутреннее соединение

Когда указано условие соединения, выполняется Inner Join. В этом случае было бы неплохо иметь поле customer_id в обеих таблицах. Результаты должны быть похожими на Natural Join.

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

Давайте добавим еще несколько условий в запрос.

На этот раз мы получили заказы на сумму более $15.

ON Clause

Прежде чем перейти к другим типам соединений, нам нужно посмотреть ON clause. Это полезно для помещения условий JOIN в отдельное предложение.

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

USING Clause

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

На самом деле это похоже на NATURAL JOIN, поэтому столбец join (customer_id) не повторяется дважды в результатах.

Левое (внешнее) соединение

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

Хотя у Энди нет заказов, его запись все ещё отображается. Значения под столбцами второй таблицы имеют значение NULL.

Это полезно для поиска записей, которые не имеют отношений. Например, мы можем искать клиентов, которые не разместили какие-либо заказы.

Всё, что мы сделали, это нашли NULL для order_id.

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

Условия

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

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

У нас Энди, но нет Сэнди. Тем не менее это выглядит не так. Чтобы получить то, что мы хотим, нам нужно использовать ON clause.

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

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

RIGHT OUTER JOIN работает точно так же, но порядок таблиц обратный.

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

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

Заключение

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

Не забудьте проверить SQL scripts, apps and add-ons на рынке Envato. Вы получите представление о возможностях баз данных SQL, и сможете найти идеальное решение, которое поможет вам в текущем проекте разработки.

Следуйте за нами на Twitter или подпишитесь на Nettuts + RSS Feed для получения лучших обучающих материалов по веб-разработке в Интернете.

Источник