Тема: анализ критериев качества нормализованных моделий данных.

ПЛАН

1 Сравнение нормализованных и ненормализованных моделей

2 OLTP и OLAP-системы

3Преобразование концептуальной моделей в реляционную

 

Сравнение нормализованных и ненормализованных моделей

 

Как уже указывалось, на практике 3НФ является последней формой, которая обеспечивает достаточную независимость данных от ключей и устраняет возможные аномалии, возникающие из-за транзитивных зависимостей. Дальнейшая нормализация отношений для задач, которые должны решать разрабатываемые БД, не требуется.

При этом отношения, находящиеся в 1НФ и 2НФ считаются слабо нормализованными, а отношения 3НФ – сильно нормализованными. Уровень нормализации существенно влияет на качество физических моделей данных и производительность базы данных (табл. 2.5):

Таблица 2.5

Критерий	Отношения слабо нормализованы (1НФ, 2НФ)	Отношения сильно нормализованы (3НФ)
Адекватность базы данных предметной области	Хуже(-)	Лучше(+)
Легкость разработки и сопровождения базы данных	Сложнее (-)	Легче (+)
Скорость выполнения встав-ки, обновления, удаления	Медленнее (-)	Быстрее (+)
Скорость выполнения выборки данных	Быстрее (+)	Медленнее (-)

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

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

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

 

OLTP и OLAP-системы

 

Во всём многообразии типов БД (см. п. 1.4) можно выделить некоторые классы систем, для которых больше подходят сильно или слабо нормализованные модели данных.

Сильно нормализованные модели данных хорошо подходят для так называемых OLTP-приложений (On-Line Transaction Processing (OLTP)- оперативная обработка транзакций). Типичными примерами OLTP-приложений являются системы складского учета, системы заказов билетов, банковские системы, выполняющие операции по переводу денег и т.п. Основная функция подобных систем заключается в выполнении большого количества коротких транзакций. Сами транзакции выглядят относительно просто, например, "снять сумму денег со счета А, добавить эту сумму на счет В".

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

Практически все запросы к базе данных в OLTP-приложениях состоят из команд вставки, обновления, удаления. Запросы на выборку, в основном, предназначены для предоставления пользователям возможности выбора из различных справочников, т.е. большая часть запросов известна заранее еще на этапе проектирования БД. Таким образом, критическим для OLTP-приложений является скорость и надежность выполнения коротких операций обновления данных. Чем выше уровень нормализации данных в OLTP-приложении, тем оно, как правило, быстрее и надежнее.

Таким образом, БД, предназначенная для работы с транзакциями в OLTP-приложениях, должна быть приведена к 3НФ или НФБК-4НФ. Отступления от этого правила могут происходить тогда, когда уже на этапе разработки известны некоторые часто возникающие запросы, требующие соединения отношений и от скорости выполнения которых существенно зависит работа приложений. В этом случае можно пожертвовать нормализацией для ускорения выполнения подобных запросов и ограничиться 1НФ или 2НФ.

Другим типом приложений являются так называемые OLAP-приложения (On-Line Analitical Processing (OLAP) - оперативная аналитическая обработка данных). Это обобщенный термин, характеризующий принципы построения систем поддержки принятия решений (Decision Support System - DSS), хранилищ данных (Data Warehouse), систем интеллектуального анализа данных (Data Mining). Такие системы предназначены для нахождения зависимостей между данными (например, можно попытаться определить, как свя

зан объем продаж товаров с характеристиками потенциальных покупателей), для проведения анализа "что если…".

OLAP-приложения оперируют с большими массивами данных, которые взяты из электронных таблиц или других источников данных и уже накоплены в OLTP-приложениях,. Такие системы характеризуются следующими признаками:

· Добавление в систему новых данных происходит относительно редко крупными блоками (например, раз в квартал загружаются данные по продажам из OLTP-приложения).

· Данные, добавленные в систему, обычно никогда не удаляются.

· Перед загрузкой данные проходят различные процедуры "очистки", чтобы привести к одному формату данные, взятые из разных источников.

· Запросы к системе являются нерегламентированными и, как правило, достаточно сложными.

· Скорость выполнения запросов важна, но не критична.

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

Пример2.18 Гиперкуб, измерениями которого являются: время (в кварталах, годах), тип товара и отделения компании, а в ячейках хранятся объемы продаж. Содержат данные о продажах различных типов товаров по кварталам и подразделениям. Основываясь на этих данных, можно отвечать на вопросы типа "Какое подразделение имеет самые лучшие объемы продаж в этом году?", или "Сделать прогноз продаж отделений региона в текущем году на основе продаж прошлого года"

Физически гиперкуб может быть построен на основе специальной многомерной модели данных (MOLAP - Multidimensional OLAP – многоразмерная OLAP) или построен средствами реляционной модели данных ( ROLAP - Relational OLA P ).

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

3Преобразование концептуальной модели в реляционную

 

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

преобразование КМД в РМД.

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

Такой подход отличается от метода декомпозиции ещё и тем, что функциональные зависимости привлекаются не на начальном, а конечном этапе проектирования. Все полученные в результате отношения будут иметь 4НФ, т.е. дальнейшая нормализация им не требуется.

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

• построить набор предварительных отношений и указать первичные
ключи для каждого отношения;

• подготовить список всех представляющих интерес атрибутов и назначить каждый из этих атрибутов одному из предварительных отношений с тем условием, чтобы эти отношения находились в НФБК. На этом шаге должны быть определены для каждого отношения межатрибутные функциональные зависимости, с помощью которых проверяется соответствие отношений НФБК. Если полученные отношения в итоге не находятся в НФБК или некоторым атрибутам не находится ло­гически обоснованных мест в предварительных отношениях, то диаграммы концептуальной модели необходимо пересмотреть.

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

Преобразование объектных множеств и атрибутов

Допустим, проектируемая БД состоит из объектных множеств (рис. 2.2):

 

Рис. 2.2 Объектные множества проектируемой БД

Объектное множество ПРЕПОДАВАТЕЛЬ имеет два атрибута, один из которых (Табельный номер)может быть использован для однозначной идентификации преподавателя, т. е. быть ключом. Таким образом, диаграмму ПРЕПОДАВАТЕЛЬ можно преобразовать в отношение:

ПРЕПОДАВАТЕЛЬ (Табельный номер. Ф_И_О).

Объектное множество КУРС имеет один атрибут, который не может быть ключом, поскольку дисциплины с одинаковым названием могут читаться разным специальностям, иметь различные рабочие программы. Поэтому для идентификации элемента мно­жества необходимо добавить новый атрибут - Номер курса (рис. 2.3).

В результате получим

отношение:

КУРС (Номер курса.

Наименование курса).

 

 

Рис. 2.3 Объектное множество КУРС

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

Преобразование конкретизаций и обобщений

Множество ПРОФЕССОР является конкретизацией объектного множества ПРЕПОДАВАТЕЛЬ (рис. 2.4):

 

U

 

Рис. 2.4 Концептуальная модель ПРЕПОДАВАТЕЛЬ

Объектное множество ПРЕПОДАВАТЕЛЬ преобразуется в отношение:

ПРЕПОДАВАТЕЛЬ (Табельный номер. Ф И О. Адрес).

Объектное множество ПРОФЕССОР является подмножестаом объекта ПРЕПОДАВАТЕЛЬ, поэтому оно наследует его атрибуты и имеет свой атрибут: №_диплома, следовательно, ему соответствует отношение:

ПРОФЕССОР (Табельный номер. Ф_И_О, Адрес, №_диплома).

Ключ Табельный номер является также внешним ключом для связи с отношением обобщения ПРЕПОДАВАТЕЛЬ, атрибуты Ф_И_О и Адрес являются избыточными. Из от­ношения конкретизации ПРОФЕССОР нужно удалить все повторяющиеся неключевые атрибуты. В результате получим:

ПРЕПОДАВАТЕЛЬ (Табельный номер, Ф_И_О, Адрес); ПРОФЕССОР (Табельный номер, № диплома).

Таким образом, конкретизация объектного множества преобразуется в одноименное отношение. Множество атрибутов конкретизации включает собст­венные атрибуты конкретизации, к которым добавляются ключевые ат­рибуты обобщения.

Преобразование бинарных связей

Объектные множества ПРЕПОДАВАТЕЛЬ и КУРС соотносятся с помощью связи читает (рис.2.5).

 

 

Рис. 2.5 Бинарная связь читает

Идентификаторы– ТН для ПРЕПОДАВАТЕЛЬ и НК для КУРС.

Бинарная связь читает может иметь различную мощность – 1:1, 1:N, N:1 и N:M.

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

Рассмотрим процесс формирования отношений для ПрО

ПРЕПОДАВАТЕЛЬ читает КУРС

БД ПрО должна содержать следующие данные:

· ТН– табельный номер преподавателя – первичный атрибут-ключ для ПРЕПОДАВАТЕЛЬ;

· ФИО – фамилия, имя, отчество преподавателя;

· Тел_П – телефон преподавателя;

· НК – номер курса - первичный атрибут-ключ для КУРС;

· Назв_К

Важнейшими факторами, влияющими на структуру проектируемой РБД, являютсямощность связи и класс принадлежности объектов к катего

рии «обязательный».

Бинарная связь может иметь мощность: 1:1, 1:N, N:1 и N:M.

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

Для мощности связи 1:1 возможны 3 варианта построения отношений РБД:

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

ПРЕПОДАВАТЕЛЬ (ТН, Ф_И_О, Тел_П, НК, Назв_К)

В этом отношении содержится вся информация. Т.к. мощность связи 1:1 и класс принадлежности обоих множеств обязательный, то однократное появление ТН и НК гарантируется в любом экземпляре (записи, строке) отношения, т.е. отношение не будет содержать пустой информации или повторяющихся групп избыточных данных. Первичным ключом отношения может быть первичный ключ любого множества - ПРЕПОДАВАТЕЛЬ или КУРС.

Вариант 2. Мощность связи 1:1, класс принадлежности одного из множеств (ПРЕПОДАВАТЕЛЬ) – обязательный, второго (КУРС) – необязательный.

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

ПРЕПОДАВАТЕЛЬ (ТН, Ф_И_О, Тел_П, НК)

КУРС (НК, Назв.К)

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

ПРЕПОДАВАТЕЛЬ (ТН, Ф_И_О, Тел_П)

КУРС (НК, Назв_К)

ЧИТАЕТ (ТН, НК, …)

Отношение ПРЕПОДАВАТЕЛЬ содержит сведения обо всех преподавателях, КУРС – обо всех курсах, ЧИТАЕТ – значения ТН и НК, которые могут появиться только однажды, т.к. мощность связи – 1:1. Отношение ЧИТАЕТ может, кроме ключей объектных множеств, иметь другие атрибуты.

Предварительные отношения для бинарных связей мощности 1::N.

Для мощности связи 1:N также возможно два варианта построения отношений РБД.

Вариант 1. Мощность связи 1:N, класс принадлежности одного из мно

жеств (ПРЕПОДАВАТЕЛЬ) – необязательный, второго (КУРС) – обязательный.

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

КУРС (НК, Назв_К, ТН)

ПРЕПОДАВАТЕЛЬ (ТН, Ф_И_О, Тел_П)

Вариант 2. Мощность связи 1:N, класс принадлежности обоих множеств необязательный.

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

Здесь также требуется 3 отношения:

КУРС (НК, Назв_К)

ПРЕПОДАВАТЕЛЬ (ТН, Ф_И_О, Тел_П)

ЧИТАЕТ (ТН, НК, … )

Для мощности бинарной связи M:N единственно допустимым вариантом является представление РБД тремя отношениями:

КУРС (НК, Назв_К)

ПРЕПОДАВАТЕЛЬ (ТН, Ф_И_О, Тел_П)

ЧИТАЕТ (ТН, НК, … )

Из изложеного выше следуют три правила построения РМД:

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

Правило 2. При мощности связи 1:1 или 1:N между необязательными объектными множествами строится три отношения РБД - два для объектов и одно для связи. Отношение, реализующее связь содержит первичные ключи необязательных отношений и может иметь другие атрибуты.

Правило 3. При мощности связи М:N независимо от категории обязательности строится три отношения РБД - два для объектов и одно для связи. Отношение, реализующее связь содержит первичные ключи отношений и может иметь другие атрибуты.

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

щественное значение, особенно по скорости её работы.

Преобразование трехсторонних связей

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

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

Аналогично, для n – сторонней связи требуется n+1 предварительное отношение.

Пример 2.19:

ПРЕПОДАВАТЕЛЬ (ТН, Ф_И_О, Тел_П, …);

КУРС (НК, Назв_К, …)

СТУДЕНТ (НС, Ф_И_О Ст,.....);

ПРЕП_КУРС_СТУД (ТН, НК, НС,...).

Первичный ключ для отношения ПРЕП_КУРС_СТУД можно будет определить тогда, когда будут распределены все атрибуты всех отношений.

Преобразование составных объектных множеств

Рассмотрим концептуальную модель ПрО (рис. 2.6):

 

 

 

Рис. 2.6 Концептуальная модель составного объекта

Внутреннее составное объектное множество ВЫПОЛНЯЕТ имеет мощность связи M:N, поэтому для РБД реализуется тремя отношениями:

СПЕЦИАЛИСТ (Таб номер, Ф_И_О, Должность)

ВИД РАБОТЫ (Код вида, Характеристика)

ВЫПОЛНЯЕТ (Таб номер, Код вида)

Внутреннее составное множество выполняет вместе с множеством НИР образуют новое составное объектное множество ПО с мощностью связи также M:N, поэтому для РБД эта модель требует генерации еще двух отношений: для множества НИР и для связи ПО:

НИР (Индекс нир, Название, Руководитель)

ПО (Таб номер, Код вида, Индекс нир, Час_оплата, Кол_часов).

В схему ПО вошли также атрибуты всего составного объектного множества Час_оплата и Кол_часов.

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

СПЕЦИАЛИСТ (Таб номер, Ф_И_О, Должность);

ВИД РАБОТЫ (Код вида, Характеристика);

ВЫПОЛНЯЕТ (Таб номер,Код вида):

НИР (Индекс нир, Название, Руководитель);

ПО (Таб номер, Код вида,. Индекс нир, Час_оплата, Кол_часов).

В БД присутствует избыточность данных - вся информация, содержащаяся в отношении ВЫПОЛНЯЕТ, присутствует также в отношении ПО, поэтому отношение ВЫПОЛНЯЕТ можно удалить (если бы оно содержало неключевые атрибуты, то удалить его было бы нельзя).

Окончательно получим:

СПЕЦИАЛИСТ (Таб номер. Ф И О, Должность)

ВИД РАБОТЫ (Код вида, Характеристика)

НИР (Индекс НИР, Название, Руководитель)

ПО (Таб номер, Код вида, Индекс НИР, Час_оплата, Кол_часов).

Данная модель представляет тернарную связь с собственными атрибутами.

Преобразование рекурсивных связей

Согласно «Экономико-математическому словарю

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

Пример 2.20: БД содержит сведения о мастерах и сборщиках. Мастера получают фиксированный оклад, сборщики - почасовую оплату.

Ограничения ПрО:

§ мастер руководит только сборщиками, быть сборщиком не может,

§ сборщик не может быть мастером.

Возможно 2 варианта построения реляционной модели:

Вариант 1 (п ервоначальный). РМД может иметь вид (рис.2.7):

 

1 N

руководит

 

 

Рис. 2.7 Начальный вариант РМД МАСТЕР-СБОРЩИК

Так как мощность связи 1:N и элементы обоих объектов обязательно входят в связь руководит, то в соответствии с правилом 1 реляционная модель должна содержать два отношения:

МАСТЕР (Номер_мастера, …)

СБОРЩИК (Номер_сборщика, …)

В РБД также нужно включить атрибуты:

§ ФИО_РАБ – ФИО работника (мастера или сборщика);

§Р_тел_М – рабочий телефон мастера (сборщик не имеет Р_тел);

§Д_тел_РАБ – домашний телефон работника;

§Адрес_РАБ – домашний адрес работника;

§Т_ставка_СБ – почасовая тарифная ставка сборщика;

§Оклад_М – месячный оклад мастера.

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

МАСТЕР (Ном_М, Оклад_М, Р_тел_М, …);

СБОРЩИК ( Ном СБ, Т_ставка_СБ, …, Ном_М).

Остались неразмещёнными атрибуты, относящиеся к работнику вообще – ФИО_РАБ, Д_тел_РАБ, Адрес_РАБ, их следовало бы поместить в оба отношения, но, согласно общему правилу, для уменьшения избыточности БД неключевой атрибут может быть помещён только в одно отношение.

Эти атрибуты(служащего) можно разделить (переопределить) на атрибуты мастера и сборщика по отдельности:

ФИО_М – ФИО мастера;

Д_тел_М – домашний телефон мастера;

Адрес_М – домашний адрес мастера и

ФИО_СБ – ФИО сборщика;

Д_тел_СБ – домашний телефон сборщика;

Адрес_СБ – домашний адрес сборщика).

Теперь атрибуты мастера можно поместить в отношение МАСТЕР, а атрибуты сборщика – в отношение СБОРЩИК. Это решение является неудачным, т.к. для поиска, например, работника Васильева нужно просмотреть оба отношения и, если есть однофамильцы, то может быть выбран не тот Васильев.

Вариант 2. Рассмотрим ПрО с точки зрения работника – представим всех мастеров и сборщиков в виде обобщающего объектного множества РАБОТНИК, а объекты МАСТЕР и СБОРЩИК - в качестве конкретизаций этого множества (рис. 2.8):

Ном_РАБ

 

U U

1 N

руководит

Ном_М Ном СБ

Рис. 2.8.Концептуальная модель РАБОТНИК

Ключом множества РАБОТНИК является Ном_РАБ, элементы которого состоят из элементов ключей Ном_М и Ном СБ множеств МАСТЕР и СБОРЩИК соответственно.

Окончательный набор отношений такой концептуальной модели данных примет вид:

РАБОТНИК (Ном_РАБ,...., ФИО_РАБ, Д_тел_РАБ, Адрес_РАБ);

МАСТЕР (Ном М, Оклад_М, Р_тел_М,..);

СБОРЩИК (Ном СБ, Т_ставкаСБ, …., Ном_М).

Отношение РАБОТНИК содержит информацию, общую для всех работников. Отношения МАСТЕР и СБОРЩИК содержат специфическую информацию по виду работников. Связь руководит соединяет две роли одного обобщающего объектного множества РАБОТНИК – с одной стороны, мастера руководят сборщиками, с другой - работники руководят работниками. Такой тип связи называется рекурсивным. Эта связь рекурсивна в том смысле, что с точки зрения обобщающего объектного множества работники руководят работниками.

Для увеличения скорости доступа при запросах к РБД в отношение РАБОТНИК можно включить атрибут, определяющий, кем конкретно является

работник - мастером или сборщиком.

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

Описанный процесс преобразования F-зависимостей с атрибутами связей мощностью 1:1 или 1:N гарантирует, что они будут зависеть только от ключевых атрибутов, т.е. каждая реляционная таблица будет иметь НФБК.Многозначные атрибуты со связями M:N преобразуются в реляционные отношения с составными ключами из ключевых атрибутов отдельных объектных множеств. Такие отношения гарантированно имеют 4НФ.

ЛЕКЦИЯ 9

ТЕМА: ОСНОВНЫЕ ПОНЯТИЯ РЕЛЯЦИОННОЙ АЛГЕБРЫ.

ПЛАН

1 Реляционная алгебра

2 Основные операции реляционной алгебры

3 Дополнительные операции реляционной алгебры

 

Реляционная алгебра

 

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

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

§ объединение, § пересечение, § разность, § произведение, § выбор, § создание проекций, § соединение, § деление.

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

Одной из главных операций при работе с БД в реляционной теории является запрос и все перечисленные операции всегда направлены на реализацию запросов.

Запрос – это операция над отношениями, результатом которой является отношение.

Система запросов - формальная система для выражения запросов. Запрос в реляционной алгебре задает алгоритм преобразования отношений.

Операции реляционной алгебры делятся на две группы - основные и дополнительные.