Базы данных. Определение базы данных.

Базы данных. Определение базы данных.

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

Архитектура базы данных. Иерархическая модель данных.

Иерархическая модель данных — представление базы данных в виде древовидной (иерархической) структуры, состоящей из объектов (данных) различных уровней.

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

Архитектура базы данных. Сетевая модель данных.

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

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

Сетевая БД состоит из набора экземпляров определенного типа записи и набора экземпляров определенного типа связей между этими записями.

Тип связи определяется для двух типов записи: предка и потомка. Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка. Для данного типа связи L с типом записи предка P и типом записи потомка C должны выполняться следующие два условия:

• каждый экземпляр типа записи P является предком только в одном экземпляре типа связи L;
• каждый экземпляр типа записи C является потомком не более чем в одном экземпляре типа связи L.

Жизненный цикл базы данных.

Жизненный цикл базы данных (ЖЦБД) – это процесс проектирования, реализации и поддержки базы данных. ЖЦБД состоит из семи этапов:

1) предварительное планирование;

2) проверка осуществимости;

3) определение требований;

4) концептуальное проектирование;

5) логическое проектирование;

6) физическое проектирование;

7) оценка работы и поддержка базы данных.

 

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

1. Предварительное планирование базы данных – важный этап в процессе перехода от разрозненных данных к интегрированным. На этом этапе собирается информация об используемых и находящихся в процессе разработки прикладных программах и файлах, связанных с ними. Она помогает установить связи между текущими приложениями и то, как используется их информация. Кроме того, позволяет определить будущие требования к базе данных. Информация документируется в виде обобщенной концептуальной модели данных.

2. Проверка осуществимости предполагает подготовку отчетов по трем вопросам:

1) есть ли технология – необходимое оборудование и программное обеспечение – для реализации запланированной базы данных (технологическая осуществимость);

2) имеются ли персонал, средства и эксперты для успешного осуществления плана создания базы данных (операционная осуществимость);

3) окупится ли запланированная база данных (экономическая эффективность).

3. Определение требований. На этом этапе определяются:

· цели базы данных;

· информационные потребности различных структурных подразделений и их руководителей;

· требования к оборудованию;

· требования к программному обеспечению.

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

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

6. Физическое проектирование. На этом этапе логическая модель расширяется характеристиками, необходимыми для определения способов физического хранения базы данных, типа устройств для хранения, методов доступа к данным базы, требуемого объема памяти, правил сопровождения базы данных и др.

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

 

Определение 1НФ

Таблица находится в 1НФ, если все ее поля содержат только простые неделимые значения.

 

Таблицы ФИЛИАЛ и КЛИЕНТ не удовлетворяют требованиям 1НФ. Для приведения их к 1НФ в них надо вставить новые записи следующим образом:

 

ФИЛИАЛ

НФ	АДР_Ф	НМ	НС	ОСТ	ТИП
	Ванеева, 6				Д
	Ванеева, 6				Т
	Ванеева, 6				Т
	Солтыса, 3				Т
	Солтыса, 3				Д

 

КЛИЕНТ

НК	ФИО_К	СОЦ_П	АДР_К	НС
	Сокол С.С.	Служащий	Садовая, 1
	Сокол С.С.	Служащий	Садовая, 1
	Брас Б.Б.	Рабочий	Гая, 9
	Лань Л.Л.	Служащий	Лесная, 4
	Лань Л.Л.	Служащий	Лесная, 4
	Лань Л.Л.	Служащий	Лесная, 4

 

Но полученные таблицы неэффективны, так как содержат много избыточной информации. Необходимо их привести к 2НФ.

Определение 2НФ

Таблица находится в 2НФ, если она удовлетворяет требованиям 1НФ и неключевые поля функционально полно зависят от первичного ключа.

 

Функциональная зависимость – это понятие, отображающее определенную семантическую связь между полями таблицы. Пусть (Х₁, Х₂,…,Х_к) – множество полей, образующих первичный ключ.

Неключевое поле А функционально полно зависит от первичного ключа, если:

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

(Х1, Х2,…,Хк)®А

· не существует функциональной зависимости А ни от какого подмножества полей первичного ключа (в противном случае А находится в частичной функциональной зависимости от первичного ключа).

В таблице КЛИЕНТ неключевые поля ФИО_К, СОЦ_П, АДР_К функционально зависят от ключа (НК, НС), что запишем

НК, НС ® ФИО_К, СОЦ_П, АДР_К

Кроме того, они функционально зависят от подмножества ключа – НК, что запишем

НК ® ФИО_К, АДР_К, СОЦ_П

Следовательно, неключевые поля ФИО_К, СОЦ_П, АДР_К находятся в частичной функциональной зависимости от первичного ключа (НК, НС) и нарушаются требования 2НФ. Эти поля надо из таблицы КЛИЕНТ удалить. Полученную в результате этого таблицу назовем КЛИЕНТ–СЧЕТ (таблица 1), которая имеет вид

 

КЛИЕНТ–СЧЕТ

НК	НС

 

Эта таблица удовлетворяет требованиям 2НФ.

Удаленные неключевые поля помещаются в новую таблицу совместно с подмножеством НК, от которого они зависят. И это подмножество будет первичным ключом новой таблицы КЛИЕНТ (таблицы 2) вида

КЛИЕНТ

НК	ФИО_К	СОЦ_П	АДР_К
	Сокол С.С.	Служащий	Садовая, 1
	Брас Б.Б.	Рабочий	Гая, 9
	Лань Л.Л.	Служащий	Лесная, 4

 

Новая таблица КЛИЕНТ также удовлетворяет требованиям 2НФ. Ее неключевые поля функционально полно зависят от первичного ключа.

Полученные таблицы 1, 2 не содержат избыточной информации, и нет основания приводить их к 3НФ.

Таблица ФИЛИАЛ удовлетворяет требованиям 2НФ, так как ее неключевые поля НФ, АДР_Ф, НМ, ОСТ, ТИП функционально полно зависят от первичного ключа

НС ® НФ, АДР_Ф, НМ, ОСТ, ТИП

Но в таблице ФИЛИАЛ повторяется информация о филиале для всех счетов, обрабатываемых им. Поэтому ее надо привести к 3НФ.

Определение 3НФ

Таблица находится в 3НФ, если она удовлетворяет требованиям 2НФ и не содержит транзитивных зависимостей.

 

Транзитивной зависимостью называется функциональная зависимость между неключевыми полями. В таблице ФИЛИАЛ она наблюдается

НФ® АДР_Ф, НМ

Следовательно, нарушаются требования 3НФ. Из таблицы ФИЛИАЛ надо удалить поля, участвующие в этой транзитивной зависимости, – АДР_Ф, НМ. Получится таблица, характеризующая счет (таблица 3), вида

 

СЧЕТ

НС	ОСТ	ТИП	НФ
		Д
		Т
		Т
		Т
		Д

 

Затем создается новая таблица, в которую помещаются удаленные поля и поле, от которого они зависят (таблица 4). Она имеет вид

 

ФИЛИАЛ

НФ	АДР_Ф	НМ
	Ванеева, 6
	Солтыса, 3

 

Полученные таблицы 3, 4 приведены к 3НФ. В них каждая запись есть отдельное независимое утверждение. Повторяются только значения внешнего ключа НФ в таблице СЧЕТ, что неизбежно, так как одним филиалом могут обрабатываться несколько счетов.

Как видим, нормализация приводит к фрагментации исходных таблиц. В нашем примере таблица КЛИЕНТ разбивается на таблицы 1, 2, а таблица ФИЛИАЛ – на таблицы 3, 4. Осуществив связь этих таблиц посредством связи первичных и внешних ключей, получим реляционную модель данных предметной области БАНК, в которойминимизирована избыточность данных. Эта модель представлена на рис. 1.8.

Рис. 1.8. Реляционная модель предметной области БАНК после нормализации

4 Нормальная форма (Нормальная форма Бойса-Кодда)

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

 

Модель сущность-связь.

Средством моделирования предметной области на этапе концептуального проектирования является модель "сущность–связь". Часто ее называют ER-моделью (Entity – сущность, Relation – связь). В ней моделирование структуры данных предметной области базируется на использовании графических средств – ER-диаграмм (диаграмм "сущность–связь"). В наглядном виде они представляют связи между сущностями.

Основные понятия ER-диаграммы – сущность, атрибут, связь.

Сущность – это некоторый объект реального мира, который может существовать независимо. Сущность имеет экземпляры, отличающиеся друг от друга значениями атрибутов и допускающие однозначную идентификацию. Атрибут – это свойство сущности. Например, сущность КНИГА характеризуется такими атрибутами, как автор, наименование, цена, издательство, тираж, количество страниц. Конкретные книги являются экземплярами сущности КНИГА. Они отличаются значениями указанных атрибутов и однозначно идентифицируются атрибутом "наименование". Атрибут, который уникальным образом идентифицирует экземпляры сущности, называется ключом. Может быть составной ключ, представляющий комбинацию нескольких атрибутов.

 

Правило 1

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

 

На ER-диаграмме связи 1:1, представленной на рис. 1.5, класс принадлежности сущностей МЕНЕДЖЕР, ФИЛИАЛ является обязательным. Тогда согласно правилу 1 должна быть сгенерирована одна таблица следующей структуры:

 

МЕНЕДЖЕР–ФИЛИАЛ

НМ

СТАЖ

СПЕЦ

НФ

АДР_Ф

 

Первичным ключом этой таблицы может быть и первичный ключ сущности МЕНЕДЖЕР – НМ.

 

Правило 2

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

Представим, что на ER-диаграмме связи 1:1, изображенной на рис. 1.5, класс принадлежности сущности МЕНЕДЖЕР будет обязательный, а сущности ФИЛИАЛ – необязательный. Тогда согласно правилу 2 должны быть сгенерированы две таблицы следующей структуры:

МЕНЕДЖЕР – ФИЛИАЛ

НМ

СТАЖ

СПЕЦ

НФ

 

ФИЛИАЛ

НФ

АДР_Ф

 

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

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

 

Правило 3

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

 

Представим, что на ER-диаграмме связи 1:1, изображенной на рис. 1.5, класс принадлежности сущностей МЕНЕДЖЕР, ФИЛИАЛ будет необязательный. Тогда согласно правилу 3 должны быть сгенерированы три таблицы следующей структуры:

МЕНЕДЖЕР

НМ

СТАЖ

СПЕЦ

 

ФИЛИАЛ

НФ

АДР_Ф

 

МЕНЕДЖЕР–ФИЛИАЛ

НМ

НФ

 

При этом осуществляется декомпозиция связи 1:1 на две связи 1:1 следующим образом:

Итак, для связи типа 1:1 существуют три отдельных правила формирования предварительных таблиц из ER-диаграмм.

 

Правило 4

Если связь типа 1:М и класс принадлежности сущности на стороне М является обязательным, то необходимо построить таблицу для каждой сущности. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Первичный ключ сущности на стороне 1 добавляется как атрибут в таблицу для сущности на стороне М.

 

На ER-диаграмме связи 1:М, представленной на рис. 1.5, класс принадлежности сущности СЧЕТ является обязательным. Тогда согласно правилу 4 должны быть сгенерированы две таблицы следующей структуры:

ФИЛИАЛ

НФ

АДР_Ф

 

СЧЕТ– ФИЛИАЛ

НС

ОСТ

ТИП

НФ

 

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

Примечание. Если внешний ключ представляет связь 1:М, то должны быть разрешены его дублирующие значения.

Правило 5

Если связь типа 1:М и класс принадлежности сущности на стороне М является необязательным, то необходимо построить три таблицы – по одной для каждой сущности и одну для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей.

 

Представим, что на ER-диаграмме связи 1:М, изображенной на рис. 1.5, класс принадлежности сущности СЧЕТ является необязательным. Тогда согласно правилу 5 должны быть сгенерированы три таблицы следующей структуры:

ФИЛИАЛ

НФ

АДР_Ф

 

СЧЕТ

НС

ОСТ

ТИП

 

ФИЛИАЛ – СЧЕТ

НФ

НС

 

При этом осуществляется декомпозиция связи 1:М на две связи – 1:М и 1:1 – следующим образом:

Правило 6

Если связь типа М:N, то необходимо построить три таблицы – по одной для каждой сущности и одну для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей.

 

ER-диаграмма связи М:N имеется на рис. 1.5. Согласно правилу 6 на основе этой ER-диаграммы должны быть сгенерированы три таблицы следующей структуры:

 

КЛИЕНТ

НК

ФИО_К

СОЦ_П

АДР_К

 

СЧЕТ

НС

ОСТ

ТИП

 

КЛИЕНТ– СЧЕТ

НК

НС

 

При этом осуществляется декомпозиция связи М:N на две связи 1:М следующим образом:

В таблице КЛИЕНТ–СЧЕТ клиенту, имеющему, например, три счета будут соответствовать три строки с одним и тем же номером клиента. А счет, у которого, например, два владельца, представляется двумя строками с различными номерами клиентов, владеющими этим счетом.

К ER-модели предметной области БАНК, представленной на рис. 1.5, применимы правила 1, 4, 6. Связь МЕНЕДЖЕР – ФИЛИАЛ представляется (согласно правилу 1) одной таблицей

таблица А

НМ

СТАЖ

СПЕЦ

НФ

АДР_Ф

 

Связь ФИЛИАЛ – СЧЕТ представляется (согласно правилу 4) связью

Связь КЛИЕНТ – СЧЕТ представляется (согласно правилу 6) связью

Анализ состава атрибутов полученных таблиц A, B, C, D, E, F показывает, что таблица В является составной частью таблицы А, таблица Е – составной частью таблицы С. Поэтому таблицы В, Е можно исключить из рассмотрения. Оставшиеся таблицы А, С, D, F можно связать посредством связи первичных и внешних ключей как на рис. 1.7. В результате получим реляционную модель для ER-модели предметной области БАНК.

 

 

Объединение

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

Синтаксис операции объединения:

Замечание. Объединение, как и любое отношение, не может содержать одинаковых кортежей. Поэтому, если некоторый кортеж входит и в отношение , и отношение , то в объединение он входит один раз.

Пример 2. Пусть даны два отношения и с информацией о сотрудниках:

Табельный номер	Фамилия	Зарплата
1	Иванов
2	Петров
3	Сидоров

Таблица 1 Отношение A

Табельный номер	Фамилия	Зарплата
1	Иванов
2	Пушников
4	Сидоров

Таблица 2 Отношение B

Объединение отношений и будет иметь вид:

Табельный номер	Фамилия	Зарплата
	Иванов
	Петров
	Сидоров
	Пушников
	Сидоров

Таблица 3 Отношение A UNION B

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

Пересечение

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

Синтаксис операции пересечения:

Пример 3. Для тех же отношений и , что и в предыдущем примере пересечение имеет вид:

Табельный номер	Фамилия	Зарплата
	Иванов

Таблица 4 Отношение A INTERSECT B

Замечание. Казалось бы, что в отличие от операции объединения, потенциальные ключи могли бы наследоваться пересечением отношений. Однако это не так. Вообще, никакие реляционные операторы не передают результирующему отношению никаких данных о потенциальных ключах. В качестве причины этого можно было бы привести тривиальное соображение, что так получается более просто и симметрично - все операторы устроены одинаково. На самом деле причина более глубока, и заключается в том, что потенциальный ключ - семантическое понятие, отражающее различимость объектов предметной области. Наличие потенциальных ключей не выводится из структуры отношения, а явно задается для каждого отношения, исходя из его смысла. Реляционные же операторы являются формальными операциями над отношениями и выполняются одинаково, независимо от смысла данных, содержащихся в отношениях. Поэтому, реляционные операторы ничего не могут "знать" о смысле данных. Трактовка результата реляционных операций - дело пользователя.

 

Вычитание

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

Синтаксис операции вычитания:

Пример 4. Для тех же отношений и , что и в предыдущем примере вычитание имеет вид:

Табельный номер	Фамилия	Зарплата
2	Петров
3	Сидоров

Таблица 5 Отношение A MINUS B

 

Декартово произведение

Определение 5. Декартовым произведением двух отношений и называется отношение, заголовок которого является сцеплением заголовков отношений и :

,

а тело состоит из кортежей, являющихся сцеплением кортежей отношений и :

,

таких, что , .

Синтаксис операции декартового произведения:

Замечание. Мощность произведения равна произведению мощностей отношений и , т.к. каждый кортеж отношения соединяется с каждым кортежем отношения .

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

Замечание. Перемножать можно любые два отношения, совместимость по типу при этом не требуется.

Пример 5. Пусть даны два отношения и с информацией о поставщиках и деталях:

Номер поставщика	Наименование поставщика
1	Иванов
2	Петров
3	Сидоров

Таблица 6 Отношение A (Поставщики)

Номер детали	Наименование детали
1	Болт
2	Гайка
3	Винт

Таблица 7 Отношение B (Детали)

Декартово произведение отношений и будет иметь вид:

Номер поставщика	Наименование поставщика	Номер детали	Наименование детали
	Иванов		Болт
	Иванов		Гайка
	Иванов		Винт
	Петров		Болт
	Петров		Гайка
	Петров		Винт
	Сидоров		Болт
	Сидоров		Гайка
	Сидоров		Винт

Таблица 8 Отношение A TIMES B

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

Таблица 9 Отношение A

Результат выборки будет иметь вид:

Табельный номер	Фамилия	Зарплата
1	Иванов
2	Петров

Таблица 10 Отношение A WHERE Зарплата<3000

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

Проекция

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

Синтаксис операции проекции:

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

Пример 7. Пусть дано отношение с информацией о поставщиках, включающих наименование и месторасположение:

Номер поставщика	Наименование поставщика	Город поставщика
1	Иванов	Уфа
2	Петров	Москва
3	Сидоров	Москва
4	Сидоров	Челябинск

Таблица 11 Отношение A (Поставщики)

Проекция будет иметь вид:

Город поставщика

Уфа

Москва

Челябинск

Таблица 12 Отношение A[Город поставщика]

 

Соединение

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

Обычно рассматривается несколько разновидностей операции соединения:

• Общая операция соединения
• -соединение (тэта-соединение)
• Экви-соединение
• Естественное соединение

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

Общая операция соединения

Определение 8. Соединением отношений и по условию называется отношение

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

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

Тэта-соединение

Определение 9. Пусть отношение содержит атрибут , отношение содержит атрибут , а - один из операторов сравнения ( и т.д.). Тогда - соединением отношения по атрибуту с отношением по атрибуту называют отношение

Это частный случай операции общего соединения.

Иногда, для операции -соединения применяют следующий, более короткий синтаксис:

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

Номер поставщика	Наименование поставщика	X (Статус поставщика)
1	Иванов
2	Петров
3	Сидоров

Таблица 13 Отношение A (Поставщики)