2 какие типы данных типы связей вы знаете

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

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

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» (работники и должности). Эта таблица-посредник связывает между собой работника и должность следующим образом:

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.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.

• SQL
• Microsoft SQL Server

Система управления базами данных SQLite. Изучаем язык запросов SQL и реляционные базы данных на примере библиотекой SQLite3. Курс для начинающих.

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

• 26.05.2016
• SQLite библиотека, Базы данных
• 3 комментария

Здравствуйте, уважаемые посетители сайта ZametkiNaPolyah.ru. Продолжаем изучать базы данных и наше знакомство с библиотекой SQLite3. Продолжаем изучать теорию реляционных баз данных и в этой части мы познакомимся с видами и типами связей между таблицами в реляционных базах данных. Так же мы познакомимся с такими термина, как: кортеж, атрибут и отношения. Данная тема является базовой и ее понимание необходимо для работы с базами данных и для их проектирования.

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

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

Термины кортеж, атрибут и отношение в реляционных базах данных

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

Таблица с данными из базы данных World

У нас есть простая таблица City из базы данных World, в которой есть строки и столбцы. Но термины: таблица, строка, столбец – это термины стандарта SQL.
Кстати: ни одна из существующих в мире СУБД не имеет полной поддержки того или иного стандарта SQL, но и ни один стандарт SQL полностью не реализует математику реляционных баз данных.
В терминологии реляционных баз данных: таблица – это отношение (принимается такое допущение), строка – это кортеж, а столбец – атрибут. Иногда вы можете услышать, как некоторые разработчики называют строки записями. Чтобы не было путаницы в дальнейшем предлагаю использовать термины SQL.
Если рассматривать таблицу, как объект (например книга), то столбец – это характеристики объекта, а строки содержат информацию об объекте.

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

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

Реализация связи один ко многим в теории баз данных

Связь один ко многим в реляционных базах данных реализуется тогда, когда объекту А может принадлежать или же соответствовать несколько объектов Б, но объекту Б может соответствовать только один объект А. Не совсем понятно, поэтому смотрим пример ниже.

Реализация связи один ко многим в реляционных базах данных

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

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

Связь многие ко многим реализуется в том случае, когда нескольким объектам из таблицы А может соответствовать несколько объектов из таблицы Б, и в тоже время нескольким объектам из таблицы Б соответствует несколько объектов из таблицы А. Рассмотрим простой пример.

Пример связи многие ко многим

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

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

Связь один к одному – самая редко встречаемая связь между таблицами. В 97 случаях из 100, если вы видите такую связь, вам необходимо объединить две таблицы в одну.

Пример связи один к одному

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

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

Еще записи о создании сайтов и их продвижении, базах данных, IT-технология и сетевых протоколах

• Часть 11.2: Ограничения уровня таблицы в базах данных SQLite3
• Часть 11.4: Внешние ключи в базах данных SQLite: FOREIGN KEY в SQLite3
• Часть 3.3: Ключи и ключевые атрибуты в базах данных
• Тема 3: Теория реляционных баз данных
• Тема 10: Работа с таблицами в базах данных SQLite3
• Базы данных. Виды и типы баз данных. Структура реляционных баз данных. Проектирование баз данных. Сетевые и иерархические базы данных
• Часть 3.10: Словарь терминов реляционных баз данных
• Часть 11.7: Индексы в базах данных SQLite. Индексация таблиц в SQLite3. Алгоритм B-дерева в базах данных

Возможно, эти записи вам покажутся интересными

Related Posts

Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем изучать базы данных и наше знакомство с библиотекой SQLite3. При…

Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем рубрику реляционные базы данных и начинаем новый раздел библиотека SQLite. Данной…

Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем изучать базы данных и наше знакомство с библиотекой SQLite3. Работать…

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

This article has 3 comments

Deer-door 08.10.2020 Reply
> В 97 случаях из 100 Как производилось измерение частоты случаев? Каковы были условия измерения?
Автор жжёт 01.03.2022 Reply

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

Кирилл 24.03.2022 Reply

Из-за вашего комментария ко мне домой приехало два наряда пожарных, тушили весь вечер. Не нужно так, я очень впечатлительный. А теперь по факту: 1. Может вы все-таки подумаете, почему я так ответил, с учетом общей направленности всего цикла публикаций по SQLite. Может человеку сперва нужно понять как вещь работает в общем, прежде чем начинать к ней приделывать костыли? 2. Если хотите высказаться конструктивно, напишите свою публикацию с примерами и пояснениями, готов опубликовать со ссылками на вас и ваши ресурсы, если они не противоречат законам РФ.

Пособие для студентов Модуль 3

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

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

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

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

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

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

Пример. Рассмотрим базу данных «Деканат», состоящую из трех таблиц: СТУДЕНТ, СЕССИЯ, СТИПЕНДИЯ, имеющих показанную ниже структуру.

Номер личного дела

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

Номер личного дела

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

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

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

Рис. 6. Пример реляционной структуры данных.

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

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

Различают три типа связей (отношений) между таблицами реляционной базы данных:

• отношение «один-к-одному» (1 — 1)
• отношение «один-ко-многим» (1 — М)
• отношение «многие-ко-многим» (М — М)

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

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

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

Рассмотренные ранее таблицы СТУДЕНТ и СЕССИЯ находятся в отношении «один-к-одному» (иначе говоря, между таблицами установлена связь типа «один-к-одному») (рис. 7).

Рис. 7. Пример таблиц, находящихся в отношении «один-к-одному».

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

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

Например, рассмотренные ранее таблицы СТИПЕНДИЯ и СЕССИЯ находятся в отношении «один-ко-многим» (рис. 8). При этом на стороне «один» находится таблица СТИПЕНДИЯ, а на стороне «многие» – таблица СЕССИЯ. Связь устанавливается по полю Результат. Каждая запись таблицы СТИПЕНДИЯ может иметь много связанных с ней записей в таблице СЕССИЯ, иначе говоря, в таблице СЕССИЯ может быть много строк с заданным значением в поле Результат (например, со значением 1). В то же время, если взять любую строку в таблице СЕССИЯ, то для нее найдется не более одной строки в таблице СТИПЕНДИЯ с таким же значением в поле Результат.

Рис. 8. Пример таблиц, находящихся в отношении «один-ко-многим».

Говорят, что таблицы А и В находятся в отношении «многие-ко-многим», если каждая запись таблицы А может быть связана с несколькими записями в таблице В, и наоборот, каждая запись таблицы В может быть связана с несколькими записями в таблице А.

Такая связь всегда реализуется с помощью третьей (связующей) таблицы. Примером могут служить таблицы Читатели и Книги (рис. 9). Связь между ними организуется посредствам таблицы Абонемент.

Рис. 9. Пример таблиц, находящихся в отношении «многие-ко-многим».

Каждой записи в таблице Читатели могут соответствовать несколько записей в таблице Книги, и наоборот, каждая запись таблицы Книги может иметь более одной соответствующей ей записи в таблице Читатели. Соответствие устанавливается с помощью таблицы абонемент. При этом между таблицами ЧИТАТЕЛИ и АБОНЕМЕНТ установлено отношение «один-ко-многим», в котором таблица ЧИТАТЕЛИ является главной, а таблица АБОНЕМЕНТ – подчиненной. Аналогично между таблицами КНИГИ и АБОНЕМЕНТ установлено отношение «один-ко-многим», в которой таблица КНИГИ является главной.

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

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

В этой статье

• Введение
• Типы связей между таблицами
• Зачем создавать связи между таблицами?
• Понятие о целостности данных
• Просмотр связей между таблицами

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Щелкните «Файл»,выберите«Открыть», а затем выберите и откройте базу данных.
2. На вкладке Работа с базами данных в группе Отношения нажмите кнопку Схема данных.
3. На вкладке Конструктор в группе Связи нажмите кнопку Все связи.

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

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

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

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

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

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