Связь один — к — одному (1:1)
Тип связи один — к — одному используется, когда необходимо отделить некоторый набор сведений, однозначно связанный с конкретным экземпляром исходного структурного элемента. Так, например, если есть необходимость выделить паспортные данные в отдельный структурный элемент, чтобы обеспечить разграничение прав доступа к соответствующим сведениям, то между элементом "Паспортные данные" и "Сотрудник" будет установлена связь один — к — одному.
К связи один — к — одному (1:1) относят такое взаимодействие структурных элементов, у которых один экземпляр одного элемента может быть связан не более чем с одним экземпляром другого элемента.
Очень важно правильно интерпретировать соответствующие структурные элементы и связи между ними. Рассматривая связь между элементами "Паспортные данные" и "Сотрудник", нужно задаться вопросом: "Нужно ли хранить в базе данных сведения о паспортных данных, если сотрудник сменил паспорт, или паспортные данные должны заменяться?"
Пример данных, по паспортным сведениям, сотрудников
Серия: 45 01 № 657954, выдан ОВД "Выхино" 25.01.2002
Серия: 43 02 № 324891, выдан ОВД "Митино" 15.05.1999
Правильная оценка возможных значений по связям между структурными элементами является залогом дальнейшего проектирования базы данных. Анализ предметной области в рассматриваемом примере показал, что каждому сотруднику устанавливается в соответствие только один вариант паспортных данных. Эго очевидно из структуры табл. 2.11 с данными предметной области. В этой таблице видно, что каждый сотрудник представлен только один раз и каждому представлены паспортные данные, которые также не дублируются.
Особенности предметной области, связанные с паспортными данными, указывают на тот факт, что каждый паспорт является уникальным и совокупность его сведений встречается только один раз и только у одного человека (сотрудника). При этом, совокупность серии и номера можно рассматривать набором атрибутов, которые составляют уникальную комбинацию значений для каждого паспорта. Можно, конечно, проанализировать все данные по паспортным данным в документе "Личный листок" каждого сотрудника организации, но это может оказаться достаточно проблематичной задачей по причине больших объемов анализируемых данных или конфиденциальности сведений. Именно эти факторы требуют от разработчика хорошего знания предметной области и особенностей работы с определенными данными. Но даже знания о предметной области не дадут ответ на поставленный вопрос о возможности наличия нескольких паспортных сведений у одного сотрудника. Здесь важно иметь информацию от сотрудников организации, получаемую в процессе анализа предметной области и деятельности в организации.
Поскольку в рассматриваемом варианте ответом является тот факт, что каждый сотрудник будет в базе данных описываться только одним набором сведений о паспортных данных, то можно сказать, что:
- • для одного сотрудника будут храниться сведения только по одному паспорту (это определяется особенностями хранения информации по сотрудникам в рассматриваемой организации);
- • один паспорт будет идентифицировать только одного сотрудника (это определяется особенностями работы с паспортными данными в предметной области).
В итоге, для рассматриваемого примера связь между структурными элементами "Сотрудник" и "Паспортные данные" можно представить, как на рисунке 2.38.
В дальнейшем, при анализе связи в момент формирования модели базы данных, разработчик определит дополнительные составляющие: смысловую нагрузку связи, количество связываемых экземпляров структурных элементов (мощность, кардинальность), возможность хранения пустого значения и т.д.
1.2 Типы связей (отношений) между таблицами
Связи между любыми двумя таблицами реляционной БД относятся к одному из трех типов: один-к-одному (1:1) , один-ко-многим (1:М) и много-ко-многим (М:М).
1.2.1 Связь типа «один-к-одному» (1:1)
При этом типе связи каждой записи в одной таблице соответствует не более одной записи в связанной таблице. Этот вид связи встречается довольно редко. В основном в тех случаях, когда часть информации об объекте либо редко используется, либо является конфиденциальной (такая информация хранится в отдельной таблице, которая защищена от несанкционированого доступа).
Например, анкетные данные студента (ФИО, факультет, курс, группа, дата рождения и т.п.) могут храниться в одной таблице БД, а сведения о родителях этого студента – в другой, т.к. эта информация используется достаточно редко и может быть отделена от основной.
1.2.2 Связь типа «один-ко-многим» (1:м). Ключевые поля
При таком типе связи каждой записи в одной таблице соответствует одна или более записей в связанной таблице. Для реализации такого отношения используются две таблицы. Одна из них представляет сторону «один», другая — сторону «много».
Например, нужно иметь информацию о студентах и результатах сдачи ими экзаменов (дата сдачи, предмет, оценка и т.д.). Если все это хранить в одной таблице, то ее объем неоправданно возрастет, т.к. в ней для каждой записи об очередном экзамене должны повторяться все анкетные сведения о студенте. Поскольку Студент и Экзамены — это разные сущности, то и атрибуты их должны храниться в разных таблицах. Но эти сущности связаны между собой, т.к. экзамены сдает определенный студент. Причем один студент может сдавать несколько экзаменов, т.е. налицо тип отношения «один-ко-многим».
Решением этой задачи является создание двух таблиц (например, Студенты и Экзамены), в каждой из которых хранятся соответствующие атрибуты (рисунок 2). Для связывания этих таблиц нужно использовать какой-либо атрибут студента, сдающего экзамен, который будет повторяться в обеих таблицах. Но этот атрибут должен однозначно идентифицировать каждый экземпляр сущности Студент, т.е. являться уникальным для каждого студента. Таким атрибутом может стать, например, номер зачетки (он уникален для каждого студента). В данном случае атрибут Номер зачетки будет являться ключом для сущности Студент.
Рисунок 2 Пример связи «один-ко-многим»
Ключ – это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Ключ может быть простым (когда он состоит из одного атрибута) и составным (когда он состоит более чем из одного атрибута). Если в таблице нет поля, однозначно определяющего каждую запись, его нужно создать искусственно.
В таблице со стороны «один» ( в нашем примере Студенты) поле Номер зачетки будет ключевым.
1.2.3 Связь типа «много-ко-многим» (м:м)
При этом типе связи множеству записей в одной таблице соответствует множество записей в связанной таблице. Большинство современных СУБД непосредственно не поддерживают такой тип отношений. Для его реализации отношение разбивается на два, имеющих тип «один-ко-многим». Соответственно, для хранения информации потребуется уже как минимум три таблицы: две со стороны «много» и одна со стороны «один». Связь между этими тремя таблицами также осуществляется посредством ключевых полей.
Виды связей между таблицами в реляционных базах данных (Связь «Один к одному»)
Практически всегда БД не ограничивается одной таблицей. Сложно представить себе какой-либо бизнес-процесс на предприятии, который мог бы сконцентрироваться только на одном предмете в плане информации. Одним из важнейших достоинств реляционных баз данных состоит в том, что можно хранить логически сгруппированные данные в разных таблицах и задавать связи между ними, объединяя в единую базу. Для задания связи таблицы должны иметь поля с одинаковым типом данных. Связь между таблицами устанавливает отношение между совпадающими значениями в этих полях. Такая организация позволяет уменьшить избыточность хранимых данных, упрощает их ввод, удаление, поиск. Рассмотрим виды связей между таблицами.
Связь «Один к одному»
Запись в таблице А может иметь не более одной связанной записи в таблице В и наоборот. Содержимое таких таблиц как правило можно объединить в одну. Этот тип связи используется довольно редко. Такие связи имеет смысл устанавливать для разделения таблиц с очень большим количеством полей, для отделения части таблицы по соображениям защиты или если не все данные из одной таблицы используются в другой. Связь один к одному создается только в том случае, когда оба поля являются ключевыми.
В данном случае только незначительная часть сотрудников занимаются серьезно спортом и имеют спортивные разряды, поэтому данные о сотрудниках спортсменах выделены в отдельную таблицу.
Связь «Один ко многим»
Отношение один-ко-многим (1:M или M:1) является наиболее часто используемым типом связи. В такой связи каждой записи в таблице А (первичный ключ) соответствует несколько записей в таблице В (внешний ключ), а запись в таблице В не может иметь более одной соответствующей ей записи в таблице А. Таблица А называется главной, а таблица В подчиненной таблицей. Или иногда таблицу А называют родительской таблицей, а В – дочерней. Связь один ко многим создается в том случае, когда поле одной из таблиц является ключевым.
Одной записи в таблице Клиенты может соответствовать много записей в таблице Заказы.
Одной записи в таблице Товары может соответствовать много записей в таблице Заказы.
Связь «Многие ко многим»
Отношение многие ко многим (N:M). Одной записи в таблице А может соответствовать несколько записей в таблице В, а одной записи в таблице В может соответствовать много записей в таблице А. Такую связь в MS Access реализовать невозможно. Такая связь реализуется только при помощи третьей таблицы – таблицы связки, имеющей составной ключ. Важно! Связь многие ко многим преобразуется в две связи один ко многим при помощи таблицы связки.
У одной книги может быть несколько авторов, а каждого автора может быть несколько книг.
Вывод
Связи выполняют более важную роль, чем просто информация размещения данных по таблицам. Прежде всего они требуются разработчикам для поддержания целостности баз данных. Правильно настроив связи, можно быть уверенным, что ничего не потеряется.
Ссылки
- https://studfiles.net/preview/3858017/page:4/
- https://spravochnick.ru/bazy_dannyh/relyacionnaya_model_dannyh_osnovy_proektirovaniya_baz_dannyh/vidy_svyazi_v_relyacionnoy_modeli_dannyh/
- http://office-menu.ru/uroki-sql/41-tipy-svyazej-v-relyatsionnykh-bazakh-dannykh
При копировании любых материалов с сайта evkova.org обязательна активная ссылка на сайт www.evkova.org
Сайт создан коллективом преподавателей на некоммерческой основе для дополнительного образования молодежи
Сайт пишется, поддерживается и управляется коллективом преподавателей
Telegram и логотип telegram являются товарными знаками корпорации Telegram FZ-LLC.
Cайт носит информационный характер и ни при каких условиях не является публичной офертой, которая определяется положениями статьи 437 Гражданского кодекса РФ. Анна Евкова не оказывает никаких услуг.
Связи между таблицами базы данных
Связи — это довольна важная тема, которую следует понимать при проектировании баз данных. По своему личному опыту скажу, что осознав связи, мне намного легче далось понимание нормализации базы данных.
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. Как построить такие таблицы?
| 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. Реализация
С помощью ограничения foreign key мы можем ссылаться на primary key или unique другой таблицы. В этом примере мы
- ссылаемся атрибутом PositionId таблицы EmployeesPositions на атрибут PositionId таблицы Position;
- атрибутом EmployeeId таблицы EmployeesPositions — на атрибут EmployeeId таблицы Employee;
4.3. Вывод
Для реализации связи многие ко многим нам нужен некий посредник между двумя рассматриваемыми таблицами. Он должен хранить два внешних ключа, первый из которых ссылается на первую таблицу, а второй — на вторую.
5. Один ко многим
Эта самая распространенная связь между базами данных. Мы рассматриваем ее после связи многие ко многим для сравнения.
Предположим, нам нужно реализовать некую БД, которая ведет учет данных о пользователях. У пользователя есть: имя, фамилия, возраст, номера телефонов. При этом у каждого пользователя может быть от одного и больше номеров телефонов (многие номера телефонов).
В этом случае мы наблюдаем следующее: пользователь может иметь многие номера телефонов, но нельзя сказать, что номеру телефона принадлежит определенный пользователь.
Другими словами, телефон принадлежит только одному пользователю. А пользователю могут принадлежать 1 и более телефонов (многие).
Как мы видим, это отношение один ко многим.
5.1. Как построить такие таблицы?
| PhoneId | PersonId | PhoneNumber |
|---|---|---|
| 1 | 5 | 11 091-10 |
| 2 | 5 | 19 124-66 |
| 3 | 17 | 21 972-02 |
Данная таблица представляет три номера телефона. При этом номера телефона с id 1 и 2 принадлежат пользователю с id 5. А вот номер с id 3 принадлежит пользователю с id 17.
Заметка. Если бы у таблицы «Phones» было бы больше атрибутов, то мы смело бы их добавляли в эту таблицу.
5.2. Почему мы не делаем тут таблицу-посредника?
Таблица-посредник нужна только в том случае, если мы имеем связь многие-ко-многим. По той простой причине, что мы можем рассматривать ее с двух сторон. Как, например, таблицу EmployeesPositions ранее:
- Каждому работнику принадлежат несколько должностей (многие).
- Каждой должности принадлежит несколько работников (многие).
5.3. Реализация
6. Один к одному
Представим, что на работе вам дали задание написать БД для учета всех работников для HR. Начальник уверял, что компании нужно знать только об имени, возрасте и телефоне работника. Вы разработали такую БД и поместили в нее всю 1000 работников компании. И тут начальник говорит, что им зачем-то нужно знать о том, является ли работник инвалидом или нет. Наиболее простое, что приходит в голову — это добавить новый столбец типа bool в вашу таблицу. Но это слишком долго вписывать 1000 значений и ведь true вы будете вписывать намного реже, чем false (2% будут true, например).
Более простым решением будет создать новую таблицу, назовем ее «DisabledEmployee». Она будет выглядеть так:
| DisabledPersonId | EmployeeId |
|---|---|
| 1 | 159 |
| 2 | 722 |
| 3 | 937 |
Но это еще не связь один к одному. Дело в том, что в такую таблицу работник может быть вписан более одного раза, соответственно, мы получили отношение один ко многим: работник может быть несколько раз инвалидом. Нужно сделать так, чтобы работник мог быть вписан в таблицу только один раз, соответственно, мог быть инвалидом только один раз. Для этого нам нужно указать, что столбец EmployeeId может хранить только уникальные значения. Нам нужно просто наложить на столбец EmloyeeId ограничение unique. Это ограничение сообщает, что атрибут может принимать только уникальные значения.
Выполнив это мы получили связь один к одному.
Заметка. Обратите внимание на то, что мы могли также наложить на атрибут EmloyeeId ограничение primary key. Оно отличается от ограничения unique лишь тем, что не может принимать значения null.
6.1. Вывод
Можно сказать, что отношение один к одному — это разделение одной и той же таблицы на две.
6.2. Реализация
7. Обязательные и необязательные связи
Связи можно поделить на обязательные и необязательные.
7.1. Один ко многим
- Один ко многим с обязательной связью:
К одному полку относятся многие бойцы. Один боец относится только к одному полку. Обратите внимание, что любой солдат обязательно принадлежит к одному полку, а полк не может существовать без солдат. - Один ко многим с необязательной связью:
На планете Земля живут все люди. Каждый человек живет только на Земле. При этом планета может существовать и без человечества. Соответственно, нахождение нас на Земле не является обязательным
А) У женщины необязательно есть свои дети. Соответственно, связь необязательна.
Б) У ребенка обязательно есть только одна биологическая мать – в таком случае, связь обязательна.
7.2. Один к одному
- Один к одному с обязательной связью:
У одного гражданина определенной страны обязательно есть только один паспорт этой страны. У одного паспорта есть только один владелец. - Один к одному с необязательной связью:
У одной страны может быть только одна конституция. Одна конституция принадлежит только одной стране. Но конституция не является обязательной. У страны она может быть, а может и не быть, как, например, у Израиля и Великобритании.
А) Наличие загранпаспорта необязательно – его может и не быть у гражданина. Это необязательная связь.
Б) У загранпаспорта обязательно есть только один владелец. В этом случае, это уже обязательная связь.
7.3. Многие ко многим
А) Человек может вообще не инвестировать свои деньги в акции.
Б) Акции компании мог никто не купить.
8. Как читать диаграммы?
Выше я приводил диаграммы созданных нами таблиц. Но для того, чтобы их понимать, нужно знать, как их «читать». Разберемся в этом на примере диаграммы из пункта 5.3.
Мы видим отношение один ко многим. Одной персоне принадлежит много телефонов.