Лекции по управлению данными

Лекции по управлению данными

 

План лекций

1. Основные понятия управления данными в вычислительных системах.

2. Реляционные системы.

2.1. Понятие и структура реляционных систем.

2.1.1. Реляционные модели данных.

2.1.1.1.Понятие и уровни представления реляционных моделей.

2.1.1.2.Нормализация реляционных моделей.

2.1.1.3.Операции над отношениями.

2.1.2. Проектирование реляционных моделей.

2.1.2.1.Организация проектирования реляционных моделей.

2.1.2.2.Эмпирическая схема проектирования модели данных.

2.1.2.3.Синтез реляционных моделей с использованием множества функциональных зависимостей.

2.1.3. Запросы в реляционных системах.

2.1.3.1.Понятие и структура запроса.

2.1.3.2.Способы формирования запроса.

2.1.3.3.Язык SQL как основная форма описания запросов.

2.1.3.3.1. Основные конструкции SQL.

2.1.4. Проектирование приложений к реляционным базам данных.

2.1.4.1.Структура приложений.

2.1.4.2.Объектно - ориентированный подход к разработке приложений.

2.1.4.3.Понятие объекта, метода, свойств.

2.1.4.4.Классы, экземпляры и семейства.

2.1.4.5.Иерархии классов.

2.1.5. Проектирование объектно ориентированных приложений.

2.2. Распределенная обработка данных.

2.2.1. Понятие транзакции.

2.2.1.1.Восстановление системы. Двухфазная фиксация.

2.2.1.2.Параллелизм.

2.2.1.3.Безопасность.

 

Основные понятия управления данными в вычислительных системах.

 

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

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

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

 

 

Аппаратная среда это совокупность вычислительных и сетевых средств организованных в функциональные структуры. Управление работой аппаратных средств осуществляется с помощью специальных программных средств, называемых операционными системами. Кроме того, в целях поддержания нормальной работы системы «аппаратная среда – операционная система», называемой вычислительной системой используются системные программные средства. Накопление и хранение данных поддерживается системами управления данными, с помощью которых создаются базы данных. Базы данных могут быть использованы различными приложениями для решения задач пользователей. Такая схема использования вычислительной среды для решения информационных задач в настоящее время наиболее распространенной.

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

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

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

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

Системы управления базами данных (СУБД);

Администратор данных (АД) и администратор базы данных (АБД);

 

СУБД представляет собой совокупность программных средств, предназначенных для организации хранения данных в электронном виде и доступа к ним.

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

В основе БД лежит модель данных.

Модели данных

 

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

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

Уровни представления данных

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

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

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

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

Пример.

 

 

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

Пример.

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

Связи в моделях

Говорят, что между объектами или атрибутами существует связь, если между экземплярами различных объектов (атрибутов) можно установить закономерность соответствия. Различают два основных типа связей – один к одному (1:1) и один ко многим (1:М).

Определения:

Между элементами А и В определена связь один к одному, если в каждый момент времени каждому элементу А соответствует только один ассоциированный с ним элемент В.

Между элементами А и В определена связь один ко многим, если в каждый момент времени каждому элементу А соответствует ноль, один или несколько ассоциированных с ним элементов В.

Связи между объектами (атрибутами) могут существовать в обоих направлениях, т.е. возможны четыре варианта связей: 1:1, 1:М, М:1, М:М.

Примеры.

Данная классификация связей исчерпывает возможные варианты и позволяет строить модели со строгим упорядочением отношений между данными.

 

Иерархические модели данных

 

В иерархической модели все логические записи распределены по уровням. Причем каждая логическая запись связана с 0, 1 или несколькими записями нижнего уровня и одной записью верхнего, если он есть. Причем используются связи 1:М сверху вниз. В качестве примера приведем фрагмент модели ВУЗа. Связи, относящиеся к данной модели, показаны сплошными стрелками.

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

Найти группу, где учится студент А.

Найти факультет, где учится студент А.

Найти дисциплины, которые изучает студент А.

Для получения ответа на первый запрос необходимо найти запись о студенте среди записей «Студент» и далее найти связанную с ним запись из записей «Группа».

Для получения ответа на второй запрос необходимо найти запись о студенте среди записей «Студент», найти связанную с ним запись из записей «Группа» и далее связанную с последней запись из группы записей «Факультет».

При ответе на третий запрос, можно найти группу, где учится студент. Искать факультет нет смысла, так как между записями о факультете и записями о дисциплинах невозможно установить однозначной связи. Ответ на запрос может быть получен, если ввести дополнительную связь между записями «Группа» и «Дисциплины». Причем это должна быть связь М:М, так как в каждой группе одновременно читаются несколько дисциплин, а каждая дисциплина может читаться в нескольких группах. Эта связь указана в модели пунктирной линией. Полученную в результате появления этой связи модель, нельзя назвать иерархической и оно переходит в класс сетевых.

Сетевые модели данных.

В сетевых моделях связи могут устанавливаться произвольным образом. Кроме того в них допускаются связи М:М. Однако этот тип связей несет неопределенность соответствия записей. Этот тип связей показывает только характер соответствия записей, но не может быть использован для получения ответов на запросы. Проблемы, связанные с применением этого типа связей рассмотрим на следующем примере.

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

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

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

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

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

 

В ней введены дополнительные записи, связанные с существовавшими связями М:1. В соответствии с этой моделью каждой записи об изделиях соответствует столько записей с данными пересечения «изделие-узел», сколько узлов в нем содержится. Каждой записи об узлах соответствует столько записей с данными пересечения «изделие-узел», во сколько изделий входит данный узел. Та же логика и в связях между узлами и деталями.

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

Реляционные модели данных

 

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

Пусть задано отношение, содержащее данные о поставке продукции некоторыми поставщиками.

 

№ заказа	Поставщик	Дата	Товар	Характеристики	Цена
	А…	17.04.03	П…	О……	256.00
	А…	17.04.03	Р…	Л…	4598.00
	А…	17.04.03	Е…	Н…..	785.00
	В…	18.04.03	П…	О……	256.00

 

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

№ заказа	Поставщик	Дата
	А…	17.04.03
	В…	18.04.03

 

№ заказа	Товар	Характеристики	Цена
	П…	О……	256.00
	Р…	Л…	4598.00
	Е…	Н…..	785.00
	П…	О……	256.00

 

В первой из них приводятся неповторяющиеся сведения о заказах. При этом данные в домене «№ заказа» по смыслу не повторяются, т.е. этот домен обладает основным признаком ключа. Во второй таблице введен дополнительный столбец «№ заказа». Он необходим для установления связи со строками первой таблицы. Таким образом, для установления связи между двумя отношениями необходимо наличие в каждом из них одинаковых доменов, т.е. доменов имеющих одинаковый тип данных и данные соответствующие друг другу. Совпадение названий доменов необязательно. В данном примере в первом отношении «№ заказа» является ключом, и следовательно его значения не повторяются. Во втором отношении ключом является совокупность атрибутов «№ заказа», «Товар», поэтому допускается повторение номера заказа. Следовательно, между первым и вторым отношениями существует связь 1:М по домену «№ заказа».

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

ЗАКАЗ(№ заказа, Поставщик, Дата)

ТОВАРЫ(№ заказа, Товар, Характеристики, Цена)

Преобразование сетевых моделей в реляционные

Сетевые модели имеют минимум ограничений и позволяют максимально полно отразить связи в информационной среде проектируемого объекта. Однако для этих моделей почти не существует СУБД из-за плохой формализации моделей и сложности построения программного обеспечения. Поэтому часто используют следующий подход к проектированию моделей баз данных.:

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

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

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

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

 

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

 

 

 

Как видно из полученной модели связующие атрибуты добавлялись в отношения стоящие в исходной модели по стрелке со стороны М. Для устранения связи М:М и размещения данных пересечения (количество персонала отделов, работающих в зданиях) создано отношение Размещение с составным ключом. Записанная по правилам записи реляционных моделей полученная схема примет следующий вид.

ОТДЕЛЕНИЯ(Код отделения, Наименование, Руководитель, Город)

ЗДАНИЯ(Номер здания, Адрес)

ОТДЕЛЫ(Код отдела, Код отделения, Наименование, Начальник, Телефон)

РАЗМЕЩЕНИЕ(Номер здания, Код отдела, Количество персонала)

ПРОЕКТ(Номер проекта, Код отдела, Содержание, Дата окончания)

ПЕРСОНАЛ(Табельный номер, Код отдела, Номер проекта, Имя, Должность, Дата рождения)

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

 

Вторая нормальная форма

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

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

ЗАКАЗ(Код поставщика, Код товара, Наименование поставщика, Адрес, Наименование товара, Характеристики товара, Цена)

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

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

Если из отношения удаляются сведения о поставщике, то удалятся и сведения о товарах.

Для изменения адреса поставщика, наименование товара нужно проделывать это в нескольких строках отношения.

Для того, чтобы устранить эти проблемы, необходимо разбить это отношение на три следующим образом.

ПОСТАВЩИКИ(Код поставщика, Наименование поставщика, Адрес)

ТОВАРЫ(Код товара, Наименование товара, Характеристики товара)

ЗАКАЗ(Код поставщика, Код товара, Цена)

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

 

Третья нормальная форма

 

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

ПЕРСОНАЛ(Табельный номер, ФИО, Должность, Номер проекта, Дата окончания)

Дата окончания зависит от ключа через Номер проекта. Наличие транзитивной зависимости приводит к следующим проблемам:

1. при известных номере проекта и дате окончания их негде разместить пока не появятся сведения хотя бы об одном исполнителе;

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

Устранение этих проблем можно сделать, преобразовав исходное отношение к третьей нормальной форме:

ПЕРСОНАЛ(Табельный номер, ФИО, Должность, Номер проекта)

ПРОЕКТЫ(Номер проекта, Дата окончания)

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

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

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

 

Схема проектирования реляционной модели данных (эмпирический подход)

 

Для создания реляционной модели данных при разработке базы данных для заданного объекта – предприятия необходимо выполнить следующие действия:

· Обследование информационной деятельности предприятия;

· Анализ информационных потоков и интеграция требований;

· Проектирование сетевой модели, отражающей структуру и информационные связи предприятия;

· Преобразование сетевой модели к реляционной;

· Нормализация отношений реляционной модели

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

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

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

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

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

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

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

Операция проекции;

Операция объединения;

Операция разности;

Операция декартова произведения;

Операция селекции.

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

Операция проекции

Обозначение π_R(A).

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

Пример.

Сессия

Студент	Предмет	Семестр	Оценка
А..	Математика
А…	Информатика
Б..	Математика
Б…	Информатика
Б…	История
В...	Математика
В...	Информатика
В...	История

 

Проекция отношения π_{Сессия(Студент)} будет выглядеть так:

Студент	Предмет	Семестр	Оценка
А..	Математика
Б..	Математика
В...	Математика

 

 

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

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

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

Пример. Пусть даны два отношения результатов сессии за 1 и 2 семестр.

Студент	Предмет	Семестр	Оценка
А..	Математика
Б..	Математика
В...	Математика

Сессия1

 

 

Сессия2

Студент	Предмет	Семестр	Оценка
А..	Математика
Б..	Математика
В...	Информатика
В...	История

 

 

Выполнение операции Сессия1 U Сессия2

Студент	Предмет	Семестр	Оценка
А..	Математика
Б..	Математика
В...	Математика
А..	Математика
Б..	Математика
В...	Информатика
В...	История

 

Операция разности

Математическое обозначение R – S.

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

Пример. Пусть даны списки студентов получивших зачет и экзамен. Требуется выявить студентов, сдавших только зачет.

Зачет Экзамен Зачет – Экзамен

ФИО

Аверьянов

Грачев

 

ФИО

Аверянов

Баранов

Вольский

Грачев

Григорьев

Дмитриев

ФИО

Баранов

Вольский

Григорьев

Дмитриев

Петров

Семенов

 

Операция селекции

 

Математическое обозначение σ_{(А θ В)} или σ_{(А θ V)}.

Здесь А и В обозначения доменов, V – числовая или символьная константа, θ – знак логической операции (<,>,<>,<=,>=).

Операция селекции, это выборка кортежей со значениями доменов, удовлетворяющих заданному условию. Например, операция селекции σ_{(Оценка > 3)} на приведенном ниже отношении

 

Студент	Предмет	Семестр	Оценка
А..	Математика
Б..	Математика
В...	Информатика
В...	История

 

 

Студент	Предмет	Семестр	Оценка
А..	Математика
Б..	Математика
В...	История

 

даст отношение

 

 

На базе основных операций реляционной алгебры основаны операции пересечения и соединения.

Операция пересечения

Операция обозначается R ∩ S и может быть выражена через операцию вычитания следующим образом: R – (R – S). По смыслу операция образует из двух отношений новое, которое включает совпадающие кортежи исходных отношений. Для примера рассмотрим исходные отношения операции вычитания. Если необходимо выяснить какие студенты сдали и зачет и экзамен, то результат будет получен при выполнении операции

Зачет –(Зачет –Экзамен)

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

Математическое обозначение R [σ _{(A θ B)} ]S

Операция соединения представляет собой селекцию из декартова произведения. Разделяют θ – соединение и естественное соединения. В θ соединении из декартова произведения исходных отношений производится селекция по произвольному условию выборки. Например даны два отношения: «Наряд» и «Нормы»

Наряд Нормы

Код	Наименование	Норма
	Сварка
	Расточка
	Резка
	Укладка

 

ФИО	Код	Объем
А…
Б…
В…
Г…

 

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

Наряд [Код = Код And Объем < Норма] Нормы

Выполнение операции включает два этапа декартово произведение и выборка в соответствии с условием.