Как связать таблицы в sql

Обновлено: 22.04.2024

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

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

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

Существует по сути три типа отношений:

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

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

При определении связей между таблицами необходимо сделать объявления CONSTRAINT на уровне поля. Это означает, что ограничения определяются в заявлении CREATE TABLE . Чтобы применить ограничения, используйте ключевое слово CONSTRAINT после объявления поля, назови ограничение, назови таблицу, на которую ссылается, и назови поле или поля в этой таблице, которые будут соответствовать иностранному ключу.

В следующем заявлении предполагается, что таблица tblCustomers уже построена и что она имеет основной ключ, определенный в поле CustomerID. Теперь в заявлении создается таблица tblInvoices, определяющая ее основной ключ в поле InvoiceID. Кроме того, создается связь между таблицами tblCustomers и tblInvoices, определяя другое поле CustomerID в таблице tblInvoices. Это поле определяется как иностранный ключ, который ссылается на поле CustomerID в таблице клиентов. Обратите внимание, что имя каждого ограничения следует ключевому слову CONSTRAINT .

Обратите внимание, что основной индекс ключа (PK_InvoiceID) для таблицы счетов объявляется в заявлении CREATE TABLE . Чтобы повысить производительность основного ключа, для него автоматически создается индекс, поэтому нет необходимости использовать отдельное заявление CREATE INDEX . Теперь создайте таблицу доставки, которая будет содержать адрес доставки каждого клиента. Предположим, что для каждой записи клиента будет иметься только одна запись доставки, поэтому вы будете устанавливать отношения один к одному.

Обратите внимание, что поле CustomerID является как основным ключом для таблицы доставки, так и ссылкой на иностранный ключ в таблице клиентов.

Ограничения

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

Существует два типа ограничений: ограничение на уровне одного поля или поля и ограничение на уровне нескольких полей или таблиц. Оба типа ограничений можно использовать в заявлении CREATE TABLE или ALTER TABLE .

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

Обратите внимание, что имя ограничения дано. Можно использовать ярлык для объявления основного ключа, полностью отметаемого в пункте CONSTRAINT .

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

Чтобы снять ограничение, используйте пункт DROP CONSTRAINT с заявлением ALTER TABLE и укай имя ограничения.

Ограничения также могут использоваться для ограничения допустимых значений для поля. Можно ограничить значения NOT NULL или UNIQUE или определить ограничение проверки, которое является типом бизнес-правила, которое можно применить к полю. Предположим, что необходимо ограничить (или ограничить) значения полей имени и фамилии уникальными, что означает, что никогда не должно быть сочетания имени и фамилии, одинаковой для любых двух записей в таблице. Поскольку это ограничение с несколькими полями, оно объявляется на уровне таблицы, а не на уровне поля. Используйте пункт ADD CONSTRAINT и определите список с несколькими полями.

Ограничение проверки — это мощная SQL, которая позволяет добавлять проверку данных в таблицу, создавая выражение, которое может ссылаться на одно поле или несколько полей в одном или нескольких таблицах. Предположим, что необходимо убедиться, что суммы, вписаные в запись счетов, всегда больше $ 0,00. Для этого используйте ограничение проверки, объявив ключевое слово CHECK и выражение проверки в пункте ADD CONSTRAINT из заявления ALTER TABLE .

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

Предположим, что необходимо проверить кредитный лимит каждого клиента, прежде чем он будет добавлен в таблицу клиентов. Используя заявление ALTER TABLE с оговорками ADD COLUMN и CONSTRAINT , создайте ограничение, которое будет проверять значение в таблице CreditLimit для проверки кредитного лимита клиента. Используйте следующие SQL для создания таблицы tblCreditLimit, добавьте поле CustomerLimit в таблицу tblCustomers, добавьте ограничение проверки в таблицу tblCustomers и проверьте ограничение проверки.

Поддержка и обратная связь

Есть вопросы или отзывы, касающиеся Office VBA или этой статьи? Руководство по другим способам получения поддержки и отправки отзывов см. в статье Поддержка Office VBA и обратная связь.

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

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-компании. При этом существует некий стандартный набор должностей. При этом:

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

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


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

Слева указаны работники (их 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. Как построить такие таблицы?


Пользователей будет представлять некая таблица «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.3. Реализация



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

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

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

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

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

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

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

6.1. Вывод

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Я уже показал вам как данные из разных таблиц могут быть связаны при помощи связи по внешнему ключу. Вы видели как заказы связываются с клиентами путем помещения 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 уникальны в соединительной таблице.

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


image

Таблицы выше связывают поставщиков и пиво связью многие-ко-многим, используя соединительную таблицу. Обратите внимание, что пиво '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 имеет первичный ключ, составленный из двух внешних ключей. Соединительная таблица всегда имеет составной первичный ключ.

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

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

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

image


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

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

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

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

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

В одной таблице.

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

В отдельных таблицах.

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

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

image

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

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

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

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

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

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

Разрешения

Создание новой таблицы с внешним ключом требует разрешения CREATE TABLE в базе данных и разрешения ALTER на схему, в которой создается таблица.

Создание внешнего ключа в существующей таблице требует разрешения ALTER на таблицу.

Пределы и ограничения

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

Ограничения FOREIGN KEY могут ссылаться только на таблицы в пределах той же базы данных на том же сервере. Межбазовую ссылочную целостность необходимо реализовать посредством триггеров. Дополнительные сведения см. в статье об инструкции CREATE TRIGGER.

Ограничения FOREIGN KEY могут ссылаться на другие столбцы той же таблицы и считаются ссылками на себя.

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

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

Компонент Database Engine не имеет предопределенного ограничения на число ограничений FOREIGN KEY, которые могут содержаться в таблице, ссылающейся на другие таблицы. Компонент Database Engine также не ограничивает число ограничений FOREIGN KEY, принадлежащих другим таблицам, которые ссылаются на определенную таблицу. Но фактическое количество используемых ограничений FOREIGN KEY ограничивается конфигурацией оборудования, базы данных и приложения. Максимальное количество таблиц и столбцов, на которые может ссылаться таблица в качестве внешних ключей (исходящих ссылок), равно 253. SQL Server 2016 (13.x); и последующие версии увеличивает ограничение на количество других таблиц и столбцов, которые могут ссылаться на столбцы в одной таблице (входящие ссылки), с 253 до 10 000. (Требуется уровень совместимости не менее 130.) Увеличение имеет следующие ограничения:

  • Превышение 253 ссылок на внешние ключи поддерживается только для операций DELETE и UPDATE DML. Операции MERGE не поддерживаются.
  • Таблица со ссылкой внешнего ключа на саму себя по-прежнему ограничена 253 ссылками на внешние ключи.
  • Превышение числа в 253 ссылки на внешние ключи в настоящее время недоступно для индексов columnstore, оптимизированных для памяти таблиц или Stretch Database.

Ограничения FOREIGN KEY не применяются к временным таблицам.

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

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

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

Использование SQL Server Management Studio

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

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

В диалоговом окне Связи внешнего ключа нажмите кнопку Добавить.

Связь отображается в списке "Выбранные связи" с именем, предоставленным системой, в формате FK_tablename_tablename>>, где имя первой таблицы является именем таблицы внешнего ключа, а вторая — именем таблицы первичного ключа. Это просто принятое по умолчанию и распространенное соглашение об именах для поля (Name) объекта внешнего ключа.

Выберите нужную связь в списке Выбранные связи.

Выберите Спецификация таблиц и столбцов в сетке справа и нажмите кнопку с многоточием ( … ) справа от свойства.

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

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

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

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

Создание внешнего ключа в новой таблице

Использование Transact-SQL

В следующем примере создается таблица и определяется ограничение внешнего ключа для столбца TempID , ссылающегося на столбец SalesReasonID в таблице Sales.SalesReason базы данных AdventureWorks . Предложения ON DELETE CASCADE и ON UPDATE CASCADE используются для обеспечения распространения изменений, вносимых в таблицу Sales.SalesReason на таблицу Sales.TempSalesReason .

Создание внешнего ключа в существующей таблице

Использование Transact-SQL

В следующем примере создается внешний ключ для столбца TempID , ссылающегося на столбец SalesReasonID в таблице Sales.SalesReason базы данных AdventureWorks .

На этом уроке мы в основном закрепим навыки использования оператора JOIN для соединения нескольких таблиц базы данных.

Вывод данных не из всех соединяемых таблиц

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

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

Работать будем с базой данных Mediastar. Схема базы данных - на рисунке ниже. Для увеличения рисунка щёлкните по нему левой кнопкой мыши.


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

Таблица Reader (Читатель). Содержит данные о читателях медиа (сайтов), которые дали своё согласие на отслеживание их активности в сети. Данные анонимны. В нашей базе представлены 100 читателей, что представляет некоторую уменьшенную модель данных, используемых в реальных исследованиях. Данные были уменьшены во избежание громоздкости выводимых результатов. В таблице содержатся столбцы:

  • Reader_ID - идентификационный номер читателя, первичный ключ таблицы;
  • Age - возраст в годах;
  • Sex - пол (M - мужской, F - женский);
  • City_ID - идентификационный номер города проживания, внешний ключ, связывающий эту таблицу с таблицей City.

Таблица City (Город) В таблице содержатся столбцы:.

  • City_ID - идентификационный номер города, первичный ключ таблицы;
  • Name - название;
  • District - область;
  • Populsize - численность населения в тысячах человек.

Таблица Visit (Визит) Содержит данные о визитах в интернет в течение 4 недель в пределах одного месяца. В таблице содержатся столбцы:.

  • Visit_ID - идентификационный номер визита, первичный ключ таблицы;
  • Datetimestart - дата и время начала визита в формате 'ДД-ММ-ГГГГ чч:мм:сс';
  • Duration - продолжительность в секундах;
  • Reader_ID - идентификационный номер читателя, внешний ключ, связывающий эту таблицу с таблицей Reader;
  • Media_ID - идентификационный номер медиа (сайта), внешний ключ, связывающий эту таблицу с таблицей Media;
  • Adv_ID - идентификационный номер единицы рекламы, внешний ключ, связывающий эту таблицу с таблицей Advertisment.
  • Media_ID - идентификационный номер медиа, первичный ключ таблицы;
  • Name - название, например, "Всегда на колёсах";
  • Mlevel - уровень, допустимые значения: "National" (национальный) "Regional" (региональный);
  • Mcont_ID - идентификационный типа содержания (контента) медиа, внешний ключ, связывающий эту таблицу с таблицей Mconttype;
  • Mtheme_ID - идентификационный темы медиа (сайта), внешний ключ, связывающий эту таблицу с таблицей Mediatheme.

Таблица Mconttype (Тип контента медиа) Содержит данные о типах контента сайтов. В таблице содержатся столбцы:.

  • Mcont_ID - идентификационный номер типа контента медиа, первичный ключ таблицы;
  • Ctype - тип контента медиа, состоит из латинских букв T (текст), A (аудио), V (видео), буквы располагаются в обозначении типа в порядке убывания удельного веса того или иного подтипа содержания.

Таблица Mediatheme (Тема медиа) Содержит данные о темах сайтов. В таблице содержатся столбцы:.

Таблица Advertisment (Реклама) Содержит данные о единицах рекламы, которая показывалась читателям во время визита. В таблице содержатся столбцы:.

  • Adv_ID - идентификационный номер единицы рекламы, первичный ключ таблицы;
  • Acont_ID - идентификационный типа содержания (контента) рекламы, внешний ключ, связывающий эту таблицу с таблицей Advconttype;
  • Advtheme_ID - идентификационный темы рекламы, внешний ключ, связывающий эту таблицу с таблицей Advtheme.

Таблица Advconttype (Тип контента рекламы) Содержит данные о типах контента сайтов. В таблице содержатся столбцы:.

  • Acont_ID - идентификационный номер типа контента рекламы, первичный ключ таблицы;
  • Advtype - тип контента рекламы, состоит из латинских букв T (текст), A (аудио), V (видео), буквы располагаются в обозначении типа в порядке убывания удельного веса того или иного подтипа содержания.

Таблица Advtheme (Тема рекламы) Содержит данные о темах рекламы. В таблице содержатся столбцы:.

Пример 1. Вывести темы медиа (сайтов) и соответствующую каждой среднюю длительность просмотра. Отсортировать по возрастанию длительности просмотра.

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

SELECT t.Name, AVG (v.Duration) AS Avgdur FROM Mediatheme t JOIN Media m ON m.Mtheme_ID=t.Mtheme_ID JOIN Visit v ON m.Media_ID=v.Media_ID GROUP BY t.Name ORDER BY Avgdur

В результате выполнения этого запроса будет выведена следующая таблица:


Если вы хотите выполнить запросы к базе данных из этого урока на MS SQL Server, но эта СУБД не установлена на вашем компьютере, то ее можно установить, пользуясь инструкцией по этой ссылке .

Должны ли соединяемые таблицы быть "соседями" по запросу?

Работаем с таблицами, показанными на рисунке ниже, кроме таблицы City. Для увеличения рисунка щёлкните по нему левой кнопкой мыши.


До сих пор мы рассматривали запросы, в которых условие в ключевом слове ON действовало для двух таблиц, между которыми располагался JOIN. А что делать, если требуется с какой-либо таблицей соединить не одну, а, например, две таблицы? Самое удобное решение - расположить эту ещё одну таблицу последней в запросе и далее задать условие ON. В этом примере в начале цепочки соединяются таблицы Mediatheme, Media и Mconttype. Но к таблице Media нужно "прицепить" ещё и таблицу Visit. Спокойно располагаем эту таблицу в конце запроса: JOIN Visit v, а в условии ON задаём совпадение значений Media_ID из этой таблицы и таблицы Media. Таким образом, соединяемые таблицы могут и не быть "соседями" по расположению в запросе.

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

SELECT mt.Name FROM Mediatheme mt JOIN Media m ON m.Mtheme_ID=mt.Mtheme_ID JOIN Mconttype mc ON mc.Mcont_ID=m.Mcont_ID JOIN Visit v ON v.Media_ID=m.Media_ID GROUP BY mt.Name HAVING COUNT (v.Visit_ID) >= ALL ( SELECT COUNT (v.Visit_ID) FROM Mediatheme mt JOIN Media m ON m.Mtheme_ID=mt.Mtheme_ID JOIN Mconttype mc ON mc.Mcont_ID=m.Mcont_ID JOIN Visit v ON v.Media_ID=m.Media_ID WHERE mc.Ctype='VAT')

Читайте также: