использование отношений для представления данных
Использование отношений для представления данных.
• для представления набора объектов (напомним, что набор объектов представляет собой группу подобных объектов);
• для представления связей между наборами объектов.
Для представления набора объектов атрибуты интерпретируются столбцами отношения, а множество допустимых значений атрибута — соответствующим доменом. Каждый кортеж отношения выполняет роль описания отдельного объекта из набора, само отношение — всего набора объектов.
1) набор объектов Е
2) множество атрибутов, описывающих набор
3) множество значений по каждому атрибуту (которые этот атрибут может принимать):
При выполнении интерпретации объявляем, что:
1) 1-й столбец отношения соответствует атрибуту А\\ 2-й столбец отношения — атрибуту А2\. ; т-й столбец отношения — атрибуту Ат.
2) каждому атрибуту соответствует домен:
В этом отношении 7? будет п кортежей — по числу объектов в наборе Е. Каждый кортеж г <отношения К описывает отдельный объект е1 из набора объектов Е.
Отношение также используется для представления связей между наборами объектов Е], Е2,Ек.
Кортеж г, в отношении Я в этом случае обозначает список объектов:
Чтобы реализовать такую ситуацию, каждому столбцу отношения Я ставят в соответствие ключевой атрибут соответствующего набора объектов. Например, 1-й столбец соответствует ключевому атрибуту набора Е\ \ 2-й столбец — Е2\к-й столбец — Ек.
. ек ассоциируют между собой с помощью связи, представляемой отношением Я.
Схема отношения. Традиционная форма определения теоретикомножественного отношения предполагает работу с линейными списками при обработке данных. Такая форма представления оказывается удобной для обсуждения операций реляционной алгебры, но не всегда целесообразна из-за фиксированного порядка столбцов в отношении (в целом ряде практических приложений возникает необходимость перестановки столбцов в отношениях в любом порядке). Чтобы устранить необходимость фиксированного порядка столбцов в отношении, последние именуют. Присвоение столбцам отношений имен делает их порядок в отношении несущественным (т.е. столбец определяется по его имени, а не по порядковому номеру). При таком подходе оказываются эквивалентными отношения (например, два отношения, отличающиеся порядком столбцов), которые не были бы эквивалентными при традиционном определении.
Итак, столбцы отношения назовем атрибутами и присвоим им имена. В этом случае можно будет говорить об отображении имен атрибутов в множества значений, принадлежащих доменам атрибутов.
Существует аналогия между схемой отношения и форматом записи, между кортежем и записью, между отношением и файлом. Одной из возможных реализаций отношения является файл записей, формат которых соответствует схеме отношения.
Реляционная БД содержит конечное множество экземпляров отношений. Схему реляционной базы данных можно представить в виде
8. Соединение отношений R\ и Л2:
где 0 — арифметический оператор сравнения; п — арность отношения R\\ iwj — номера столбцов соответственно в отношениях R\ и R2.
Если 0 является арифметическим оператором равенства, то операцию называют эквисоединением.
В приведенных выше операциях использовано обращение к элементам кортежей по номерам столбцов отношения. Если будет обращение по имени столбцов, при этом, естественно, должны выполняться преобразования имени столбца в его порядковый номер и обратно. Тогда в случае использования имен атрибутов отношения R можно подставлять имена в формулы. Например, если имеется отношение со схемой R(A, 5, С, £>), то можно записать
9. Естественное соединение отношений R\ и R2.
Эта операция применяется только тогда, когда столбцы отношений R\ и R2 имеют имена.
Пусть отношения R\ и R2 имеют соответственно схемы:
где R\A\ — имя столбца отношения (/?] х /?2), соответствующего столбцу Л] в отношении R\ \ Ri-A \ — имя столбца отношения (R\ х /?2), соответствующего столбцу А] в отношении R2.
В заключение отметим, что конечность отношений делает недопустимой в реляционной алгебре операцию дополнения 1/?, поскольку отношение 1/? является бесконечным (это бесконечное множество всех кортежей, не принадлежащих R).
Реальным языком запросов, реализующим реляционную алгебру, является, например, алгебраический язык ISBL (Information System Base Language).
Руководство по проектированию реляционных баз данных (7-9 часть из 15) [перевод]
Продолжение.
Предыдущие части: 1-3, 4-6
7. Связь один-ко-многим.
Я уже показал вам как данные из разных таблиц могут быть связаны при помощи связи по внешнему ключу. Вы видели как заказы связываются с клиентами путем помещения customer_id в качестве внешнего ключа в таблице заказов.
Другой пример связи один-ко-многим – это связь, которая существует между матерью и ее детьми. Мать может иметь множество детей, но каждый ребенок может иметь только одну мать.
(Технически лучше говорить о женщине и ее детях вместо матери и ее детях потому, что, в контексте связи один-ко-многим, мать может иметь 0, 1 или множество потомков, но мать с 0 детей не может считаться матерью. Но давайте закроем на это глаза, хорошо?)
Когда одна запись в таблице А может быть связана с 0, 1 или множеством записей в таблице B, вы имеете дело со связью один-ко-многим. В реляционной модели данных связь один-ко-многим использует две таблицы.
Схематическое представление связи один-ко-многим. Запись в таблице А имеет 0, 1 или множество ассоциированных ей записей в таблице B.
Как опознать связь один-ко-многим?
Если у вас есть две сущности спросите себя:
1) Сколько объектов и B могут относится к объекту A?
2) Сколько объектов из A могут относиться к объекту из B?
Если на первый вопрос ответ – множество, а на второй – один (или возможно, что ни одного), то вы имеете дело со связью один-ко-многим.
Примеры.
Некоторые примеры связи один-ко-многим:
В данном случае все настолько просто, что только поэтому может оказаться трудным понимание. Возьмем последний пример с домами. На улице ведь действительно может быть любое количество домов, но у каждого дома именно на этой улице может быть только одна улица (не берем дома, которые на практике принадлежат разным улицам, возьмем, к примеру, дом в центре улицы). Ведь не может конкретно этот дом быть одновременно в двух местах, на двух разных улицах, а мы говорим не про какой-то абстрактный дом вообще, а про конкретный.
8. Связь многие-ко-многим.
Связь многие-ко-многим – это связь, при которой множественным записям из одной таблицы (A) могут соответствовать множественные записи из другой (B). Примером такой связи может служить школа, где учителя обучают учащихся. В большинстве школ каждый учитель обучает многих учащихся, а каждый учащийся может обучаться несколькими учителями.
Связь между поставщиком пива и пивом, которое они поставляют – это тоже связь многие-ко-многим. Поставщик, во многих случаях, предоставляет более одного вида пива, а каждый вид пива может быть предоставлен множеством поставщиков.
Обратите внимание, что при проектировании базы данных вы должны спросить себя не о том, существуют ли определенные связи в данный момент, а о том, возможно ли существование связей вообще, в перспективе. Если в настоящий момент все поставщики предоставляют множество видов пива, но каждый вид пива предоставляется только одним поставщиком, то вы можете подумать, что это связь один-ко-многим, но… Не торопитесь реализовывать связь один-ко-многим в этой ситуации. Существует высокая вероятность того, что в будущем два или более поставщиков будут поставлять один и тот же вид пива и когда это случится ваша база данных — со связью один-ко-многим между поставщиками и видами пива – не будет подготовлена к этому.
Создание связи многие-ко-многим.
Связь многие-ко-многим создается с помощью трех таблиц. Две таблицы – “источника” и одна соединительная таблица. Первичный ключ соединительной таблицы A_B – составной. Она состоит из двух полей, двух внешних ключей, которые ссылаются на первичные ключи таблиц A и B.
Все первичные ключи должны быть уникальными. Это подразумевает и то, что комбинация полей A и B должна быть уникальной в таблице A_B.
Пример проект базы данных ниже демонстрирует вам таблицы, которые могли бы существовать в связи многие-ко-многим между бельгийскими брендами пива и их поставщиками в Нидерландах. Обратите внимание, что все комбинации beer_id и distributor_id уникальны в соединительной таблице.
Таблицы “о пиве”.
Таблицы выше связывают поставщиков и пиво связью многие-ко-многим, используя соединительную таблицу. Обратите внимание, что пиво ‘Gentse Tripel’ (157) поставляют Horeca Import NL (157, AC001) Jansen Horeca (157, AB899) и Petersen Drankenhandel (157, AC009). И vice versa, Petersen Drankenhandel является поставщиком 3 видов пива из таблицы, а именно: Gentse Tripel (157, AC009), Uilenspiegel (158, AC009) и Jupiler (163, AC009).
Еще обратите внимание, что в таблицах выше поля первичных ключей окрашены в синий цвет и имеют подчеркивание. В модели проекта базы данных первичные ключи обычно подчеркнуты. И снова обратите внимание, что соединительная таблица beer_distributor имеет первичный ключ, составленный из двух внешних ключей. Соединительная таблица всегда имеет составной первичный ключ.
Есть еще одна важная вещь на которую нужно знать. Связь многие-ко-многим состоит из двух связей один-ко-многим. Обе таблицы: поставщики пива и пиво – имеют связь один-ко-многим с соединительной таблицей.
Другой пример связи многие-ко-многим: заказ билетов в отеле.
В качестве последнего примера позвольте мне показать как бы могла быть смоделирована таблица заказов номеров гостиницы посетителями.
Соединительная таблица связи многие-ко-многим имеет дополнительные поля.
В этом примере вы видите, что между таблицами гостей и комнат существует связь многие-ко-многим. Одна комната может быть заказана многими гостями с течением времени и с течением времени гость может заказывать многие комнаты в отеле. Соединительная таблица в данном случае является не классической соединительной таблицей, которая состоит только из двух внешних ключей. Она является отдельной сущностью, которая имеет связи с двумя другими сущностями.
Вы часто будете сталкиваться с такими ситуациями, когда совокупность двух сущностей будет являться новой сущностью.
9. Связь один-к-одному.
В связи один-к-одному каждый блок сущности A может быть ассоциирован с 0, 1 блоком сущности B. Наемный работник, например, обычно связан с одним офисом. Или пивной бренд может иметь только одну страну происхождения.
В одной таблице.
Связь один-к-одному легко моделируется в одной таблице. Записи таблицы содержат данные, которые находятся в связи один-к-одному с первичным ключом или записью.
В отдельных таблицах.
В редких случаях связь один-к-одному моделируется используя две таблицы. Такой вариант иногда необходим, чтобы преодолеть ограничения РСУБД или с целью увеличения производительности (например, иногда — это вынесение поля с типом данных blob в отдельную таблицу для ускорения поиска по родительской таблице). Или порой вы можете решить, что вы хотите разделить две сущности в разные таблицы в то время, как они все еще имеют связь один-к-одному. Но обычно наличие двух таблиц в связи один-к-одному считается дурной практикой.
Примеры связи один-к-одному.
Проект реляционной базы данных – это коллекция таблиц, которые перелинковываются (связываются) первичными и внешними ключами. Реляционная модель данных включает в себя ряд правил, которые помогают вам создать верные связи между таблицами. Эти правила называются “нормальными формами”. В следующих частях я покажу как нормализовать вашу базу данных.
Какой же вид связи вам нужен?
А если есть некие данные, которые могу быть присвоены любому человеку, то имеем дело со связью многие-ко-многим. Например, есть таблица со списком людей и мы хотим хранить информацию о том, какие страны посетил каждый человек. В данном случае имеется две сущности: люди и страны. Любой человек может посетить любое количество стран равно, как и любая страна может быть посещена любым человеком. Т.е., в данном случае, страна не является уникальными данными для конкретного человека и может использоваться повторно.
В таких случаях использование связи многие-ко-многим с использованием трех таблиц и с хранением общей информации централизованно очень удобно. Ведь если общие данные меняются, то для того, чтобы информация в базе данных соответствовала действительности достаточно подправить ее только в одном месте, т.к. хранится она только в одном месте (таблице), в остальных таблицах имеются лишь ссылки на нее.
А когда у вас есть набор уникальных данных, которые имеют отношение только друг к другу, то храните все в одной таблице. Ваш выбор – связь один-к-одному. Например, у вас есть небольшая коллекция автомобилей и вы хотите хранить информацию о них (цвет, марка, год выпуска и пр.).
Связи между таблицами базы данных
1. Введение
Связи — это довольна важная тема, которую следует понимать при проектировании баз данных. По своему личному опыту скажу, что осознав связи, мне намного легче далось понимание нормализации базы данных.
1.1. Для кого эта статья?
Эта статья будет полезна тем, кто хочет разобраться со связями между таблицами базы данных. В ней я постарался рассказать на понятном языке, что это такое. Для лучшего понимания темы, я чередую теоретический материал с практическими примерами, представленными в виде диаграммы и запроса, создающего нужные нам таблицы. Я использую СУБД Microsoft SQL Server и запросы пишу на T-SQL. Написанный мною код должен работать и на других СУБД, поскольку запросы являются универсальными и не используют специфических конструкций языка T-SQL.
1.2. Как вы можете применить эти знания?
2. Благодарности
Учтены были советы и критика авторов jobgemws, unfilled, firnind, Hamaruba.
Спасибо!
3.1. Как организовываются связи?
Связи создаются с помощью внешних ключей (foreign key).
Внешний ключ — это атрибут или набор атрибутов, которые ссылаются на primary key или unique другой таблицы. Другими словами, это что-то вроде указателя на строку другой таблицы.
3.2. Виды связей
4. Многие ко многим
Представим, что нам нужно написать БД, которая будет хранить работником IT-компании. При этом существует некий стандартный набор должностей. При этом:
4.1. Как построить такие таблицы?
Слева указаны работники (их id), справа — должности (их id). Работники и должности на этой таблице указываются с помощью id’шников.
На эту таблицу можно посмотреть с двух сторон:
4.2. Реализация
С помощью ограничения foreign key мы можем ссылаться на primary key или unique другой таблицы. В этом примере мы
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». Она будет выглядеть так:
Но это еще не связь один к одному. Дело в том, что в такую таблицу работник может быть вписан более одного раза, соответственно, мы получили отношение один ко многим: работник может быть несколько раз инвалидом. Нужно сделать так, чтобы работник мог быть вписан в таблицу только один раз, соответственно, мог быть инвалидом только один раз. Для этого нам нужно указать, что столбец EmployeeId может хранить только уникальные значения. Нам нужно просто наложить на столбец EmloyeeId ограничение unique. Это ограничение сообщает, что атрибут может принимать только уникальные значения.
Выполнив это мы получили связь один к одному.
Заметка. Обратите внимание на то, что мы могли также наложить на атрибут EmloyeeId ограничение primary key. Оно отличается от ограничения unique лишь тем, что не может принимать значения null.
6.1. Вывод
Можно сказать, что отношение один к одному — это разделение одной и той же таблицы на две.
6.2. Реализация
7. Обязательные и необязательные связи
Связи можно поделить на обязательные и необязательные.
7.1. Один ко многим
У одной биологической матери может быть много детей. У ребенка есть только одна биологическая мать.
А) У женщины необязательно есть свои дети. Соответственно, связь необязательна.
Б) У ребенка обязательно есть только одна биологическая мать – в таком случае, связь обязательна.
7.2. Один к одному
У одного человека может быть только один загранпаспорт. У одного загранпаспорта есть только один владелец.
А) Наличие загранпаспорта необязательно – его может и не быть у гражданина. Это необязательная связь.
Б) У загранпаспорта обязательно есть только один владелец. В этом случае, это уже обязательная связь.
7.3. Многие ко многим
Человек может инвестировать в акции разных компаний (многих). Инвесторами какой-то компании являются определенные люди (многие).
А) Человек может вообще не инвестировать свои деньги в акции.
Б) Акции компании мог никто не купить.
8. Как читать диаграммы?
Выше я приводил диаграммы созданных нами таблиц. Но для того, чтобы их понимать, нужно знать, как их «читать». Разберемся в этом на примере диаграммы из пункта 5.3.
Мы видим отношение один ко многим. Одной персоне принадлежит много телефонов.
9. Итоги
10. Задачи
Для лучшего усвоения материала предлагаю вам решить следующие задачи:
Реляционная модель данных
Формы представления отношений
Как мы уже упоминали выше, отношения можно представлять в виде таблиц. Но в табличном представлении сложно показывать некоторые свойства отношений. Например, неоднозначность трактовки домена колонки. Поэтому предпринимаются попытки строить более четкие схемы описания отношений в реляционных базах данных. Ниже представлен фрагмент такого описания в виде примера схемы базы данных «КАДРЫ»:
Подобное описание не прижилось среди проектировщиков баз данных. На практике прибегают к такому описанию крайне редко.
Внимание! На данном этапе изложения мы не проводим особого различия между понятиями «ключ отношения» и «ключ сущности» предметной области, хотя далее мы будем эти ключи различать.
Заметим, что ключ в контексте модели предметной области базы данных всегда отражает ту или иную степень связи между атрибутами сущностей предметной области, т.е. семантически ключ есть средство моделирования связей в модели.
Пример: рассмотрим предложение «Гражданин Иванов проживал в городе Москве 10 лет». Возможными атрибутами в отношении Место_жительства являются фамилия гражданина, название города проживания и время проживания. Фамилия гражданина может выступать в качестве первичного ключа этого отношения, так как личность однозначно определяет время ее проживания в конкретном городе. Таким образом, в этом отношении моделируется связь «проживал» между атрибутами «фамилия» и «город».
Отметим, что представление фрагментов реального мира через отношения даже в рамках одной модели данных не характеризуется единственностью. Например, зададимся вопросом: «Что есть цвет автомобиля? Связь, объект или атрибут?» Если за объект принять автомобиль, то цвет может выступать в качестве атрибута автомобиля. Если рассматривать зависимость отражательной способности покрытия автомобиля от его цвета, то цвет можно считать объектом. Если рассматривать взаимосвязь между цветом модели автомобиля и ее номером, то цвет можно считать связью.
В любом случае при представлении какого-либо качества реального мира в модели следует четко понимать, какие запросы в рамках создаваемой модели данных должны быть разрешимыми. Рассмотрим отношение КРАСНЫЙ (модель). При использовании такого отношения на вопрос: «Является ли модель X красного цвета?» может быть получен ответ: «Да» или «Нет». Вопрос: «Какой цвет у модели Х?» ответа не имеет, так как в отношении отсутствует атрибут «цвет».
Программно-аппаратный комплекс, предназначенный для выполнения следующих функций, задач: централизованное хранение, накопление и выдача по запросам пользователей данных
Использование понятия отношения для представления данных.
Математическое отношение используется для представления данных двояко. 1) Во-первых, для представления набора объектов. При этом под набором объектов понимают множество подобных объектов. 2) Во-вторых, для представления связей между наборами объектов.
Для представления наборов объектов атрибуты интерпретируются столбцами отношения. Множество значений, которые может принимать атрибут, интерпретируется соответствующим доменом. Каждый кортеж отношения выполняет роль описания отдельного объекта, т.е. экземпляра из набора. Само отношение выполняет роль описания всего набора объектов.
Н
есколько атрибутов отношения м.б. определены на одном и том же домене: рассмотрим отношение:
Атрибуты различных отношений также м.б. определены на одном и том же домене. Атрибут или совокупность атрибутов, которые однозначно идентифицируют кортеж в отношении, носят название ключа отношения.
Пример: для таблицы “Деталь” – это один атрибут номер детали.
^
Важные особенности реляционной модели.
Если в сетевой и иерархической моделях для отображения связей между записями использовались групповые отношения, то в реляционной модели такого понятия не существует. Для связи между кортежами используется дублирование ключей.
А
трибуты, которые представляют собой копии ключей в других отношениях, называются – внешними ключами.
Перечень атрибутов отношения и его свойства определяют схему отношения. Под схемой отношения понимают перечень имен атрибутов и домены, на которых они определены.
Первоначально модель Кодда (реляционная модель) содержала небольшой набор ограничений целостности. В частности, не допускалось дублирование ключей и обеспечивалась возможность наложения ограничений на значения полей.
Механизмов поддержания ссылочной целостности в начальной модели не предусматривалось. Т.о. отношения существовали в базе самостоятельно и требование ссылочной целостности не обеспечивались. Из-за неразвитости средств поддержания ссылочной целостности появилась новая модель, которая стала носить название расширенная модель Кодда, в которую были внесены требования по поддержанию ссылочной целостности.
^
Операции над данными.
Основные операции обработки отношений.
Единицей обработки этих операций является не кортеж, а отношения. Т.о. на входе каждой операции используется одно или несколько отношений, а результатом выполнения операции является новые отношения. Т.о. смысл обработки отношений состоит в обновлении существующих отношений, либо в создании новых.
(1) Операция “объединение” 
Предполагается, что на входе имеются два односхемных отношения А и В. Результирующее отношение С1 построено по той же схеме и включает в свой состав все кортежи отношений А и В.
Пример: А (Сбербанки Выборгского района) В (Сбербанки ВО)
(2) Операция “пересечение” 
Предполагается, что на входе также имеется два односхемных отношения. Результирующее отношение построено по той же схеме и содержит только те кортежи отношения А, которые есть в отношении В.
Пример: А (пациенты поликлиники №59) В (сотрудники БГТУ) 
С2 (сотрудникик БГТУ, прикрепленные к поликлинике № 59)
(3) Операция “вычитание” 
Все три отношения также построены по одной схеме. В состав результирующего отношения включаются только те кортежи из отношения А, которых нет в отношении В.
А – сведения о всех жителях района.
В – сведения о жителях района, которые прошли диспансеризацию в 2005 г.
С3 – сведения о жителях района, которые не прошли диспансеризацию.
(4) Операция “декартово произведение” 
Если отношение А имеет арность k1, а отношение В имеет арность k2, то результирующее отношение С4 будет иметь арность k1+k2, причем первые k1 элементов берутся из отношения А, а последние k2 элементов из отношения В. Отношение С4 включает кортежи, которые получаются путем соединения каждого кортежа отношения А с каждым из кортежей отношения В. При этом схемы построения отношений м.б. различными.
Пример: А (студенты) В (экзамены)
С4 (экзаменационная ведомость)
(5) Операция “выборка” (“горизонтальное подмножество”)
На входе данной операции используется только одно отношение. Результирующим является отношение, которое построено по такой же схеме, и включает в свой состав те кортежи, которые удовлетворяют заданному условию выборки.
(6) Операция “проекция” (“вертикальное подмножество”)
Необходимо построить проекцию отношения “жители” на два атрибута – номер поликлиники и наименование организации:
Операция соединения похожа на операцию декартова произведения отношений. Отличие состоит лишь в том, что в декартовом произведении осуществляется сцепление каждого кортежа отношения А с каждым кортежем отношения В, а в операции соединение это выполняется только для тех кортежей, для которых выполняется условие А1=В1.
Пример: А (отношений Сбербанк) В (сберкнижка)
Необходимо произвести соединение этих двух отношений по атрибуту № Сбербанка. Результирующее отношение будет построено по схеме (k1+k2-1), и будет включать: