Связи между таблицами базы данных
Связи — это довольна важная тема, которую следует понимать при проектировании баз данных. По своему личному опыту скажу, что осознав связи, мне намного легче далось понимание нормализации базы данных.
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. Виды связей
Связи делятся на:
- Многие ко многим.
- Один ко многим.
- с обязательной связью;
- с необязательной связью;
- Один к одному.
- с обязательной связью;
- с необязательной связью;
4. Многие ко многим
Представим, что нам нужно написать БД, которая будет хранить работником IT-компании. При этом существует некий стандартный набор должностей. При этом:
- Работник может иметь одну и более должностей. Например, некий работник может быть и админом, и программистом.
- Должность может «владеть» одним и более работников. Например, админами является определенный набор работников. Другими словами, к админам относятся некие работники.
4.1. Как построить такие таблицы?
Мы уже имеем две таблицы, описывающие работника и профессию. Теперь нам нужно установить между ними связь многие ко многим. Для реализации такой связи нам нужен некий посредник между таблицами «Employee» и «Position». В нашем случае это будет некая таблица «EmployeesPositions» (работники и должности). Эта таблица-посредник связывает между собой работника и должность следующим образом:
| EmployeeId | PositionId |
|---|---|
| 1 | 1 |
| 1 | 2 |
| 2 | 3 |
| 3 | 3 |
Слева указаны работники (их id), справа — должности (их id). Работники и должности на этой таблице указываются с помощью id’шников.
На эту таблицу можно посмотреть с двух сторон:
- Таким образом, мы говорим, что работник с id 1 находится на должность с id 1. При этом обратите внимание на то, что в этой таблице работник с id 1 имеет две должности: 1 и 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 ранее:
- Каждому работнику принадлежат несколько должностей (многие).
- Каждой должности принадлежит несколько работников (многие).
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. Один ко многим
- Один ко многим с обязательной связью:
К одному полку относятся многие бойцы. Один боец относится только к одному полку. Обратите внимание, что любой солдат обязательно принадлежит к одному полку, а полк не может существовать без солдат. - Один ко многим с необязательной связью:
На планете Земля живут все люди. Каждый человек живет только на Земле. При этом планета может существовать и без человечества. Соответственно, нахождение нас на Земле не является обязательным
У одной биологической матери может быть много детей. У ребенка есть только одна биологическая мать.
А) У женщины необязательно есть свои дети. Соответственно, связь необязательна.
Б) У ребенка обязательно есть только одна биологическая мать – в таком случае, связь обязательна.
7.2. Один к одному
- Один к одному с обязательной связью:
У одного гражданина определенной страны обязательно есть только один паспорт этой страны. У одного паспорта есть только один владелец. - Один к одному с необязательной связью:
У одной страны может быть только одна конституция. Одна конституция принадлежит только одной стране. Но конституция не является обязательной. У страны она может быть, а может и не быть, как, например, у Израиля и Великобритании.
У одного человека может быть только один загранпаспорт. У одного загранпаспорта есть только один владелец.
А) Наличие загранпаспорта необязательно – его может и не быть у гражданина. Это необязательная связь.
Б) У загранпаспорта обязательно есть только один владелец. В этом случае, это уже обязательная связь.
7.3. Многие ко многим
Любая связь многие ко многим является необязательной. Например:
Человек может инвестировать в акции разных компаний (многих). Инвесторами какой-то компании являются определенные люди (многие).
А) Человек может вообще не инвестировать свои деньги в акции.
Б) Акции компании мог никто не купить.
8. Как читать диаграммы?
Выше я приводил диаграммы созданных нами таблиц. Но для того, чтобы их понимать, нужно знать, как их «читать». Разберемся в этом на примере диаграммы из пункта 5.3.
Мы видим отношение один ко многим. Одной персоне принадлежит много телефонов.
- Возле таблицы Person находится золотой ключик. Он обозначает слово «один».
- Возле таблицы Phone находится знак бесконечности. Он обозначает слово «многие».
9. Итоги
- Связи бывают:
- Многие ко многим.
- Один ко многим.
1) с обязательной связью;
2) с необязательной связью. - Один к одному.
1) с обязательной связью;
2) с необязательной связью.
- Связи организовываются с помощью внешних ключей.
- Foreign key (внешний ключ) — это атрибут или набор атрибутов, которые ссылаются на primary key или unique другой таблицы. Другими словами, это что-то вроде указателя на строку другой таблицы.
10. Задачи
Для лучшего усвоения материала предлагаю вам решить следующие задачи:
- Описать таблицу фильм: id, название, длительность, режиссер, жанр фильма. Обратите внимание на то, что у фильма может быть более одного жанра, а к одному жанру может относится более, чем один фильм.
- Описать таблицу песня: id, название, длительность, певец. При этом у песни может быть более одного певца, а певец мог записать более одной песни.
- Реализовать таблицу машина: модель, производитель, цвет, цена
- Описать отдельную таблицу производитель: id, название, рейтинг.
- Описать отдельную таблицу цвета: id, название.
У одной машины может быть только один производитель, а у производителя — много машин. У одной машины может быть много цветов, а у одного цвета может быть много машин.
- Добавить в БД из пункта 6.2. таблицу военно-обязанных по типу того, как мы описали отдельную таблицу DisabledEmployee.
- SQL
- Microsoft SQL Server
Какие связи не допускают многотабличные реляционные базы данных
Базы данных могут содержать таблицы, которые связаны между собой различными связями. Связь (relationship) представляет ассоциацию между сущностями разных типов.
При выделении связи выделяют главную или родительскую таблицу (primary key table / master table) и зависимую, дочернюю таблицу (foreign key table / child table). Дочерняя таблица зависит от родительской.
Для организации связи используются внешние ключи. Внешний ключ представляет один или несколько столбцов из одной таблицы, который одновременно является потенциальным ключом из другой таблицы. Внешний ключ необязательно должен соответствовать первичному ключу из главной таблицы. Хотя, как правило, внешний ключ из зависимой таблицы указывает на первичный ключ из главной таблицы.
Связи между таблицами бывают следующих типов:
- Один к одному (One to one)
- Один к многим (One to many)
- Многие ко многим (Many to many)
Связь один к одному
Данный тип связей встречает не часто. В этом случае объекту одной сущности можно сопоставить только один объект другой сущности. Например, на некоторых сайтах пользователь может иметь только один блог. То есть возникает отношение один пользователь — один блог.
Нередко этот тип связей предполагает разбиение одной большой таблицы на несколько маленьких. Основная родительская таблица в этом случае продолжает содержать часто используемые данные, а дочерняя зависимая таблица обычно хранит данные, которые используются реже.
В этом отношении первичный ключ зависимой таблицы в то же время является внешним ключом, который ссылается на первичный ключ из главной таблицы.
Например, таблица Users представляет пользователей и имеет следующие столбцы:
- UserId (идентификатор, первичный ключ)
- Name (имя пользователя)
И таблица Blogs представляет блоги пользователей и имеет следующие столбцы:
- BlogId (идентификатор, первичный и внешний ключ)
- Name (название блога)
В этом случае столбец BlogId будет хранить значение из столбца UserId из таблицы пользователей. То есть столбец BlogId будет выступать одновременно первичным и внешним ключом.
Связь один ко многим
Это наиболее часто встречаемый тип связей. В этом типе связей несколько строк из дочерний таблицы зависят от одной строки в родительской таблице. Например, в одном блоге может быть несколько статей. В этом случае таблица блогов является родительской, а таблица статей — дочерней. То есть один блог — много статей. Или другой пример, в футбольной команде может играть несколько футболистов. И в то же время один футболист одновременно может играть только в одной команде. То есть одна команда — много футболистов.
К примеру, пусть будет таблица Articles, которая представляет статьи блога и которая имеет следующие столбцы:
- ArticleId (идентификатор, первичный ключ)
- BlogId (внешний ключ)
- Title (название статьи)
- Text (текст статьи)
В этом случае столбец BlogId из таблицы статей будет хранить значение из столбца BlogId из таблицы блогов.
Связь многие ко многим
При этом типе связей одна строка из таблицы А может быть связана с множеством строк из таблицы В. В свою очередь одна строка из таблицы В может быть связана с множеством строк из таблицы А. Типичный пример — студенты и курсы: один студент может посещать несколько курсов, и соответственно на один курс могут записаться несколько студентов.
Другой пример — статьи и теги: для одной статьи можно определить несколько тегов, а один тег может быть определен для нескольких статей.
Но в SQL Server на уровне базы данных мы не можем установить прямую связь многие ко многим между двумя таблицами. Это делается посредством вспомогательной промежуточной таблицы. Иногда данные из этой промежуточной таблицы представляют отдельную сущность.
Например, в случае со статьями и тегами пусть будет таблица Tags, которая имеет два столбца:
- TagId (идентификатор, первичный ключ)
- Text (текст тега)
Также пусть будет промежуточная таблица ArticleTags со следующими полями:
- TagId (идентификатор, первичный и внешний ключ)
- ArticleIdId (идентификатор, первичный и внешний ключ)
Технически мы получим две связи один-ко-многим. Столбец TagId из таблицы ArticleTags будет ссылаться на столбец TagId из таблицы Tags. А столбец ArticleId из таблицы ArticleTags будет ссылаться на столбец ArticleId из таблицы Articles. То есть столбцы TagId и ArticleId в таблице ArticleTags представляют составной первичный ключ и одновременно являются внешними ключами для связи с таблицами Articles и Tags.
Ссылочная целостность данных
При изменении первичных и внешних ключей следует соблюдать такой аспект как ссылочная целостность данных (referential integrity). Ее основная идея состоит в том, чтобы две таблице в базе данных, которые хранят одни и те же данные, поддерживали их согласованность. Целостность данных представляет правильно выстроенные отношения между таблицами с корректной установкой ссылок между ними. В каких случаях целостность данных может нарушаться:
- Аномалия удаления (deletion anomaly). Возникает при удалении строки из главной таблицы. В этом случае внешний ключ из зависимой таблицы продолжает ссылаться на удаленную строку из главной таблицы
- Аномалия вставки (insertion anomaly). Возникает при вставке строки в зависимую таблицу. В этом случае внешний ключ из зависимой таблицы не соответствует первичному ключу ни одной из строк из главной таблицы.
- Аномалии обновления (update anomaly). При подобной аномалии несколько строк одной таблицы могут содержать данные, которые принадлежат одному и тому же объекту. При изменении данных в одной строке они могу прийти в противоречие с данными из другой строки.
Аномалия удаления
Для решения аномалии удаления для внешнего ключа следует устанавливать одно из двух ограничений:
- Если строка из зависимой таблицы обязательно требует наличия строки из главной таблицы, то для внешнего ключа устанавливается каскадное удаление. То есть при удалении строки из главной таблицы происходит удаление связанной строки (строк) из зависимой таблицы.
- Если строка из зависимой таблицы допускает отсутствие связи со строкой из главной таблицы (то есть такая связь необязательна), то для внешнего ключа при удалении связанной строки из главной таблицы задается установка значения NULL. При этом столбец внешнего ключа должен допускать значение NULL.
Аномалия вставки
Для решения аномалии вставки при добавлении в зависимую таблицу данных столбец, который представляет внешний ключ, должен допускать значение NULL. И таким образом, если добавляемый объект не имеет связи с главной таблицей, то в столбце внешнего ключа будет стоять значение NULL.
Аномалии обновления
Для решения проблемы аномалии обновления применяется нормализация, которая будет рассмотрена далее.
Пособие для студентов Модуль 3
Базы данных могут содержать различные объекты, но основными объектами любой базы данных являются таблицы. Простейшая база данных имеет хотя бы одну таблицу. Даже если таблица не содержит данных, она уже содержит информацию – это информация о структуре таблицы. Структура таблицы определяет методы занесения данных и хранения их в базе данных. Таблицы базы данных создаются таким образом, чтобы каждая из них содержала информацию об одном информационном объекте. Не следует сводить в одну таблицу данные, относящиеся к разным информационным объектам.
После создания различных таблиц, содержащих данные, относящиеся к различным информационным объектам базы данных, между этими таблицами должны быть установлены реляционные связи. Установка таких связей делает возможным выполнение одновременной обработки данных из нескольких таблиц. Для установки связей обычно используют ключевые поля таблиц.
Первичный ключ реляционной таблицы – это поле или группа полей, которые позволяют однозначно определить каждую строку в таблице. Первичный ключ должен обладать двумя свойствами:
- однозначная идентификация записи – запись должна однозначно определяться значением ключа;
- отсутствие избыточности – никакое поле нельзя удалить из ключа, не нарушая при этом свойства однозначной идентификации записи.
Если первичный ключ состоит из одного поля, то он называется простым ключом или ключевым полем. Если первичный ключ состоит из нескольких полей, то такая таблица базы данных имеет составной ключ.
Чтобы связать две реляционные таблицы, необходимо ключ одной связываемой таблицы ввести в состав ключа другой связываемой таблицы (возможно совпадение ключей) или ввести в структуру одной таблицы внешний ключ, т.е. поле, не являющееся ключевым в первой таблице, но являющееся ключевым во второй.
Пример. Рассмотрим базу данных «Деканат», состоящую из трех таблиц: СТУДЕНТ, СЕССИЯ, СТИПЕНДИЯ, имеющих показанную ниже структуру.
Номер личного дела
В этой таблице ключевым полем является поле Номер личного дела, оно однозначно определяет каждую запись (строку) таблицы, т.к. не существует двух или более личных дел с одинаковыми номерами.
Номер личного дела
В столбце Результат содержатся числа 0, 1 или 2 в зависимости от того, получает ли студент стипендию по результатам сессии (0 – студент не получает стипендию, 1 – обычная стипендия, 2 – увеличенная в 2 раза стипендия). В этой таблице ключевым полем также является поле Номер личного дела.
Эта таблица содержит информацию о проценте начисляемой студенту стипендии в зависимости от результата сдачи сессии. В этой таблице ключевым является поле Результат.
Для наглядности представления связей между таблицами перейдем к представлению таблиц в виде структур этих таблиц, т.е. будем указывать только имена полей таблиц. Итак, наша база данных содержит три таблицы (рис. 6).
Рис. 6. Пример реляционной структуры данных.
Таблицы СТУДЕНТ и СЕССИЯ имеют совпадающие первичные ключи (Номер личного дела), что дает возможность легко организовать связь между ними. Таблица СЕССИЯ имеет первичный ключ Номер личного дела и содержит внешний ключ Результат, который обеспечивает ее связь с таблицей СТИПЕНДИЯ.
Будем говорить, что некоторая запись таблицы А связана с некоторой записью таблицы В, если в обеих таблицах эти записи содержат одно и то же значение в поле, по которому установлена связь между таблицами.
Различают три типа связей (отношений) между таблицами реляционной базы данных:
- отношение «один-к-одному» (1 — 1)
- отношение «один-ко-многим» (1 — М)
- отношение «многие-ко-многим» (М — М)
Говорят, что таблицы А и В находятся в отношении «один-к-одному», если каждая запись в таблице А может иметь не более одной связанной с ней записи в таблице В и наоборот, каждая запись в таблице В может иметь не более одной связанной с ней записи в таблице А.
В этом случае для связи используются ключевые поля связываемых таблиц. Этот тип связи используется достаточно редко, т.к. в этом случае данные двух таблиц могут быть объединены в одну таблицу. Можно указать следующие причины, по которым все-таки выполняется разбиение одной таблицы на несколько таблиц, связанных отношением «один-к-одному»:
- разделение очень «широкой» таблицы на несколько таблиц с целью облегчения работы;
- отделение части таблицы по соображениям защиты ее от несанкционированного доступа.
Рассмотренные ранее таблицы СТУДЕНТ и СЕССИЯ находятся в отношении «один-к-одному» (иначе говоря, между таблицами установлена связь типа «один-к-одному») (рис. 7).
Рис. 7. Пример таблиц, находящихся в отношении «один-к-одному».
Говорят, что таблицы А и В находятся в отношении «один-ко-многим», если каждая запись в таблице А может быть связана с несколькими записями таблицы В, но каждая запись в таблице В не может быть связана более чем с одной записью таблицы А. Таблица А в этом случае называется главной таблицей, а таблица В – подчиненной.
В этом случае для связи используется поле, которое является первичным ключом таблицы, находящейся на стороне отношения «один» (таблица А), и являющееся внешним ключом в таблице, находящейся на стороне отношения «многие» (таблица В).
Например, рассмотренные ранее таблицы СТИПЕНДИЯ и СЕССИЯ находятся в отношении «один-ко-многим» (рис. 8). При этом на стороне «один» находится таблица СТИПЕНДИЯ, а на стороне «многие» – таблица СЕССИЯ. Связь устанавливается по полю Результат. Каждая запись таблицы СТИПЕНДИЯ может иметь много связанных с ней записей в таблице СЕССИЯ, иначе говоря, в таблице СЕССИЯ может быть много строк с заданным значением в поле Результат (например, со значением 1). В то же время, если взять любую строку в таблице СЕССИЯ, то для нее найдется не более одной строки в таблице СТИПЕНДИЯ с таким же значением в поле Результат.
Рис. 8. Пример таблиц, находящихся в отношении «один-ко-многим».
Говорят, что таблицы А и В находятся в отношении «многие-ко-многим», если каждая запись таблицы А может быть связана с несколькими записями в таблице В, и наоборот, каждая запись таблицы В может быть связана с несколькими записями в таблице А.
Такая связь всегда реализуется с помощью третьей (связующей) таблицы. Примером могут служить таблицы Читатели и Книги (рис. 9). Связь между ними организуется посредствам таблицы Абонемент.
Рис. 9. Пример таблиц, находящихся в отношении «многие-ко-многим».
Каждой записи в таблице Читатели могут соответствовать несколько записей в таблице Книги, и наоборот, каждая запись таблицы Книги может иметь более одной соответствующей ей записи в таблице Читатели. Соответствие устанавливается с помощью таблицы абонемент. При этом между таблицами ЧИТАТЕЛИ и АБОНЕМЕНТ установлено отношение «один-ко-многим», в котором таблица ЧИТАТЕЛИ является главной, а таблица АБОНЕМЕНТ – подчиненной. Аналогично между таблицами КНИГИ и АБОНЕМЕНТ установлено отношение «один-ко-многим», в которой таблица КНИГИ является главной.
Многотабличные базы данных. Виды связей между таблицами. Создание запросов, форм, отчетов
Одной из важнейших областей применения компьютеров является переработка и хранение больших объемов информации в различных сферах деятельности человека: в экономике, банковском деле, торговле, транспорте, медицине, науке и т. д.
Существующие современные информационные системы характеризуются огромными объемами хранимых и обрабатываемых данных, сложной организацией, необходимостью удовлетворять разнообразные требования многочисленных пользователей.
Информационная система — это система, которая реализует автоматизированный сбор, обработку и манипулирование данными и включает технические средства обработки данных, программное обеспечение и обслуживающий персонал.
Цель любой информационной системы — обработка данных об объектах реального мира. Основой информационной системы является база данных. В широком смысле слова база данных — это совокупность сведений о конкретных объектах реального мира в какой-либо предметной области. Под предметной областью принято понимать часть реального мира, подлежаще11го изучению для организации управления его объектами и, в конечном счете, автоматизации, например предприятие, вуз и т. д.
Создавая базу данных, пользователь стремится упорядочить информацию по различным признакам и быстро производить выборку с произвольным сочетанием признаков. При этом очень важно выбрать правильную модель данных. Модель данных — это формализованное представление основных категорий восприятия реального мира, представленных его объектами, связями, свойствами, а также их взаимодействиями.
База данных — это информационная модель, позволяющая упорядоченно хранить данные о группе объектов, обладающих одинаковым набором свойств.
Информация в базах данных хранится в упорядоченном виде. Так, в записной книжке все записи упорядочены по алфавиту, а в библиотечном каталоге либо по алфавиту (алфавитный каталог), либо в соответствии с областью знания (предметный каталог).
Система программ, позволяющая создавать БД, обновлять хранимую в ней информацию, обеспечивающая удобный доступ к ней с целью просмотра и поиска, называется системой управления базами данных (СУБД).
Реляционные базы данных состоят из нескольких таблиц, связь между которыми устанавливается с помощью совпадающих полей. Каждая запись в таблицах идентифицирует один объект. Отношение между объектами определяет отношение между таблицами. Существует 3 типа отношений:
1. Отношение «один к одному» означает, что каждая запись в одной таблице соответствует только одной записи в другой таблице. Одному гражданину страны соответствует только один номер паспорта, в то же время как один номер паспорта соответствует только одному человеку.
2. Отношение «один ко многим» означает, что каждой записи в одной таблице соответствует одна или несколько записей в другой таблице. Один абитуриент может поступать во многие вузы и в тоже время в один вуз может поступать много абитуриентов.
3. Отношение «многие ко многим» возникает между двумя таблицами в тех случаях, когда:
* одна запись из первой таблицы может быть связана более чем с одной записью из второй таблицы;
* одна запись из второй таблицы может быть связана более чем с одной записью из первой таблицы.
Например, связь между преподавателями и группами студентов. Несколько преподавателей ведут занятия в нескольких группах, и несколько групп занимаются у нескольких преподавателей.
В большинстве случаев любые две таблицы связаны отношением «один — ко многим».
Создание связей между таблицами
Для того чтобы рассмотреть создание связей между таблицами построим в базе данных «Профконсультант» еще две таблицы:
Таблица пересечения Связь
Первые два поля являются ключевыми, причем для таблицы тСвязь-Абвузы они являются чужими ключами.
Рисунок 1 — Схема данных
Чтобы определить связи, необходимо использовать команду Сервис->Схема данных. Если связь определяется впервые в базе данных, то Access откроет пустое окно Схема данных, а затем выведет на экран окно диалога Добавление таблицы. В этом окне необходимо выделить нужные таблицы и нажать кнопку Добавить. В нашем случае в окно схемы данных надо добавить все три таблицы. Чтобы установить связь между таблицами твузы и тСвязьАбвуз, надо выделить поле Кодвуза в таблице твузы (щелкнуть левой кнопкой «мыши»), перетащить и опустить его на поле Кодвуза в таблице тСвязьАбвуз. Аналогично устанавливается связь между двумя другими таблицами.
Когда вы отпустите кнопку мыши, Microsoft Access откроет окно диалога Связи, представленное на рис. 2.
Рисунок 2- Настройка связей между полями таблиц
После установки флажка Обеспечение целостности данных, Access делает доступными еще два флажка: Каскадное обновление связанных полей и Каскадное удаление связанных записей. При установленном флажке Каскадное обновление связанных полей Microsoft Access обновляет все значения чужих ключей в дочерних таблицах (то есть в таблицах на стороне отношения «многие» при связи «один ко многим») при изменении значения первичного ключа в родительской таблице, которая находится на стороне отношения «один» при связи «один ко многим». Если же вы установите флажок Каскадное удаление связанных записей, Microsoft Access удалит дочерние строки (связанные строки в дочерних таблицах) при удалении родительской строки (связанная строка в родительской таблице). Установите флажок Каскадное обновление связанных полей, чтобы при изменении кода вуза Access автоматически обновлял записи в таблице тСвязьАбвуз.
После нажатия кнопки Создать Access создаст связь и нарисует линию между двумя таблицами, указывающую на наличие связи между ними. Заметьте: когда вы просите обеспечить целостность данных, Access изображает на конце линии у таблицы, находящейся на стороне отношения «один», цифру 1, а на другом конце у таблицы со стороны отношения «многие» — символ бесконечности. Чтобы удалить связь, щелкните по ее линии и нажмите клавишу Del. Если вы хотите отредактировать или изменить существующую связь, дважды щелкните по соответствующей линии, чтобы снова открыть окно диалога Связи.