2.1. Реляционные объекты данных

2.1.1. Домены

2.1.2. Отношения

2.2. Целостность реляционных данных

2.2.1. Потенциальные, первичные и альтернативные ключи

2.2.2. Внешние ключи

2.2.3. Null-значения

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

2.3.1. Язык SQL

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

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

2.3.4. Операции обновления

2.3.5. Значение реляционной алгебры

2.1. Реляционные объекты данных

Существует специальная терминология, принятая в теории реляционных БД (рис. 3)

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

Отношение характеризуется следующими понятиями:

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

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

Кортеж соответствует заполненной строке таблицы. В конкретных СУБД кортежи называют записями.

Степень отношения – количество его атрибутов.

Кардинальное число – количество кортежей в отношении в текущий момент времени.

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

2.1.1. Домены

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

Например, если имеется атрибут (свойство объекта) «ФИО», он предусматривает скаляры, содержащие фамилию, имя и отчество. Конечно, эти скаляры можно еще разбить на буквы, но тогда будет утрачен нужный смысл. То есть для данной модели наименьшими семантическими единицами данных будут именно фамилия, имя и отчество.

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

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

Например: Если для атрибутов №ЗачетнойКнижки отношения Студенты и №Кабинета для отношения Кабинеты домены заданы следующим образом:

№ зачетной книжки = {100000, 100001, 100002, … 999999}

№ кабинета = {1, 2, 3, … 999},

то система выдаст ошибку на запрос типа: «Вывести всех студентов, № зачетной книжки которых совпадает с № кабинета». Если же домены не определены, а определен только целый тип данных для атрибутов №ЗачетнойКнижки и №Кабинета, то подобный запрос выполнится, хотя не будет иметь смысла.

Еще одно возможное применение доменов – использование их в специальных запросах. Например, «Какие отношения в БД включают атрибуты, определенные на домене «№ зачетной книжки»?». В системе, поддерживающей домены, такой запрос будет иметь смысл и результатом его будет список отношений, где используется № зачетной книжки (это могут быть отношения Студенты,Занятия,Успеваемость, …). А в системе, где домены не определены, реализовать такого рода запрос гораздо сложнее – если через имена атрибутов, то они могут не совпадать (имена атрибутов, содержащих № зачетной книжки могут варьироваться: № зачетки, № зачетной книжки и т.п.), а если через тип – то получится много лишних отношений, т.к. немало атрибутов может иметь целый тип данных.

2.1.2. Отношения

С отношением связаны понятия переменной отношения и значения отношения.

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

Значение отношения — значение переменной отношения в конкретный момент времени (по сути - это сохраненные кортежи отношения).

Дадим более точное, формальное, определение отношения.

Отношение R1, определенное на множестве доменов D1, D2, …, Dn (необязательно различных), состоит из двух частей: заголовка и тела.

Заголовок содержит фиксированное множество пар {Ai:Di}, где Ai – имя атрибута, Di – имя домена.

Тело содержит множество пар {Ai:Zij}, где Ai – имя атрибута, Zij – значение i-ого атрибута в j-ом кортеже.

i = 1,2,…n, где n – степень отношения,

j = 1,2,…m, где m – кардинальное число.

Например, рассмотрим отношение Студенты БД Факультет:

Заголовок: {№ЗачетнойКнижки : Целый; Фамилия : Текстовый; Имя : Текстовый; ДатаРождения : Дата; Адрес : Текстовый; Группа : Текстовый}

Тело: {№ЗачетнойКнижки : 111111; Фамилия : Петров; Имя : Петр; Отчество : Петрович; ДатаРождения : 12.03.83; Адрес : Свободы, 12-45; Группа : ИНФ-21}

{№ЗачетнойКнижки : 222222; Фамилия : Иванов; Имя : Иван; Отчество : Иванович; ДатаРождения : 25.11.83; Адрес : Ленина, 65-9; Группа : ИНФ-21}

и т.д.

Для упрощенного описания отношения и его атрибутов будем использовать следующую запись:

ИмяОтношения (ИмяАтрибута1, ИмяАтрибута2, …, ИмяАтрибутаN),

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

Свойства отношений

1. Нет одинаковых кортежей. Это следует из того, что тело отношения определено как математическое множество кортежей, а множество по определению не содержит одинаковых элементов.

Следствие этого свойства: в отношении всегда существует первичный ключ.

2. Кортежи неупорядочены. Это следует также из того, что тело отношения определено как математическое множество кортежей. А математическое множество по определению не упорядочено. Именно поэтому в отношении не существует таких понятий, как «следующий», «предыдущий», «второй кортеж» и т.п.

3. Атрибуты не упорядочены. Это следует из того, что заголовок отношения определен как математическое множество атрибутов. А множество не упорядочено по определению. Т.е. опять нет понятий «первый атрибут», «следующий атрибут» и т.п.

4. Все значения атрибутов неделимы. Это следствие того, что каждый атрибут определен на своем домене, а домен – множество неделимых скаляров.

2.2. Целостность реляционных данных

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

Но таких правил целостности недостаточно – не менее важно, чтобы данные внутри самой БД не противоречили друг другу.

Например, в БД Факультет случайно указали, что Иванов Петр учится в группе ИНФ-15, но такой группы на данном факультете нет. Или для того же Петра группу указали правильно – ИНФ-13, но в качестве ФИО ее старосты написали Сидорова Н.М., а на самом деле старостой ИНФ-13 является Андреева С.В.

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

2.2.1. Потенциальные, первичные и альтернативные ключи

Пусть R – некоторое отношение, тогда потенциальный ключ K для R это подмножество множества атрибутов R, для которого выполняются следующие свойства:

1) уникальность, т.е. нет двух различных кортежей в текущем значении переменной отношения R с одинаковыми значениями K;

2) неизбыточность, т.е. никакое подмножество K не обладает свойством уникальности.

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

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

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

В СУБД Access для первичного ключа значением свойства Индексированное поле указывается значение «Да (совпадения не допускаются)», а для альтернативного может быть такое же или «Да (совпадения допускаются)».

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

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

2.2.2. Внешние ключи

В базах данных отношения могут быть связаны друг с другом. Например, в БД Факультет отношение Студенты (№ЗачетнойКнижки, Фамилия, Имя, Отчество, КодГруппы) связано с отношением Группы (КодГруппы, Специальность, Курс, Староста). Значение атрибута КодГруппы в отношении Студенты допустимо только в том случае, если такое значение имеется в качестве значения первичного ключа отношения Группы. В этом случае атрибут КодГруппы в отношении Студенты является внешним ключом, ссылающимся на первичный ключ – КодГруппы отношения Группы.

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

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

Пусть R2 — базовое отношение некой БД. Тогда внешний ключ FK (foreign key) отношения R2 – это подмножество множества атрибутов R2, такое, что:

1) существует базовое отношение R1, содержащее потенциальный ключ CK;

2) каждое значение FK в текущем значении R2, всегда совпадает со значением CK некоторого кортежа в текущем значении отношения R1.

Некоторые замечания по этому определению:

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

2. Данный внешний ключ будет составным тогда и только тогда, когда соответствующий потенциальный ключ также будет составным. Аналогично – внешний ключ будет простым (состоящим из одного атрибута) тогда и только тогда, когда соответствующий потенциальный ключ – простой. Например, пусть в БД Факультет имеются отношения Занятия (КодГруппы, Дисциплина, Преподаватель) и Расписание (№Недели, ДеньНедели, №пары, КодГруппы, Дисциплина, Преподаватель, Кабинет). Здесь внешний ключ отношения Расписание {КодГруппы, Дисциплина, Преподаватель} - составной, как и соответствующий первичный ключ в отношении Занятия.

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

4. R1 и R2 не обязательно различны Например, …..

С понятием внешнего ключа связывается еще ряд терминов:

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

С внешними ключами связано одно из основных правил целостности.

Правило ссылочной целостности:

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

По сути, это правило эквивалентно определению внешнего ключа.

Правила внешних ключей

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

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

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

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

1) Что должно произойти при попытке удалить объект ссылки внешнего ключа? (Например, убрать все группы 5 курса из таблицы Группы в конце года) Возможны как минимум два варианта ответов на этот вопрос:

a) ограничить, т.е. не удалять, пока пользователь не удалит ссылающиеся кортежи, т.е. отложить удаление;

b) каскадировать, т.е. удалить, удаляя все соответствующие ссылающиеся кортежи.

2) Что должно произойти при попытке изменить (обновить) значение потенциального ключа, на который имеется ссылка? (Например, заменить названия группы ИНФ-11 на ИНФ-21 в таблице Группы в начале учебного года). Также возможны два варианта:

a) ограничить, т.е. отложить до удаления значений ссылающихся кортежей;

b) каскадировать, т.е. обновить во всех ссылающихся кортежах.

Выбор ответов на эти два вопроса и является заданием (или определением) правил внешних ключей. В СУБД MS Access определение правил внешних ключей осуществляется при создании связей между таблицами: если будет отмечен параметр Каскадное обновление связанных полей, то выбрана операция каскадирование для обновления, если не отмечен – ограничение; аналогично с параметром Каскадное удаление связанных записей.

2.2.3. Null-значения

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

Для решения проблем отсутствия значений Кодд предложил ввести специальные метки, названные им Null-значениями, которые определил так: если данный кортеж имеет Null-значение данного атрибута, то это означает, что в нем значение атрибута отсутствует.

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

Большинство современных реляционных СУБД поддерживают Null-значения.

С Null-значениями связано второе правило целостности.

Правило целостности объектов:

Ни один элемент первичного ключа базового отношения не может быть Null-значением.

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

Необходимо сделать некоторые уточнения по этому правилу:

1) это правило касается только базовых отношений (т.е. не вычисляемых, не производных);

2) правило применимо только для первичных ключей, а для альтернативных ключей Null-значения могут быть запрещены или разрешены.

Применение Null-значений для внешних ключей:

  • Когда нет данных, т.е. нет соответствующего кортежа в ссылочном отношении (Например, нет данных о родителях ученика);
  • При каскадном удалении. (Например, на факультете расформировали одну из групп, а студентов этой группы распределяют в другие, но пока точно не известно в какие. Тогда при каскадном удалении этой группы из таблицы Группы удалятся также все студенты этой группы из таблицы Студенты. Но их не надо удалять, поэтому для этих студентов временно заменяют значение атрибута КодГруппы в отношении Студенты на Null-значения.

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

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

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

2.3.1. Язык SQL

Реляционные операции реализуются на языке SQL. Действующим на данный момент стандартом является принятая Американским национальным институтом стандартов (ANSI) версия SQL92.

В СУБД Microsoft Access используется язык Access SQL (Jet SQL), который немного отличается от стандартной версии, но основные операторы и правила - стандартные.

Как и любой язык программирования, язык SQL имеет свои правила записи инструкций. Основные из них:

  1. Запятая используется для разделения элементов списков. Например, списка имен полей.
  2. Для задания имен полей, которые содержат недопустимые символы (например, пробел), используются квадратные скобки. Например, [Дата Рождения].
  3. Если в запрос включены поля нескольких таблиц, то используется полное имя поля, которое состоит из имени таблицы и имени поля, разделенных точкой. Например, Студенты.Фамилия.
  4. Символьные строки заключаются в апострофы или кавычки.
  5. В конце инструкции ставиться точка с запятой (;).
  6. В инструкциях SQL, разбитых на несколько строк, можно использовать отступы, которые указывают на продолжение предыдущей строки.

Основным видом запроса на SQL является SELECT – запрос на выборку. Его общий вид:

SELECT <список имен полей> (если все поля, то *)

FROM <имя таблицы>

[WHERE <условия выбора>] (можно использовать <, >, =, BETWEEN, AND, NOT, OR)

[GROUP BY <имена полей>] (группировка)

[ORDER BY <имена полей>] (сортировка)

Примеры:

1) Вывести из таблицы Студенты имя, фамилию, адрес и телефон, отсортировав по фамилии

SELECT Фамилия, Имя, Адрес, Телефон

FROM Студенты

ORDER BY Фамилия;

2) Вывести все поля таблицы Студенты, произведя группировку по группам

SELECT *

FROM Студенты

GROUP BY Группа;

3) Вывести всех студентов из таблицы Студенты, проживающих на улице Ленина

SELECT *

FROM Студенты

WHERE left([Адрес], 9)=’ул.Ленина’;

4) Выбрать студентов из таблицы Студенты, которые родились в сентябре 1985 года

SELECT *

FROM Студенты

WHERE [Дата Рождения] between 31.08.85 and 1.10.85;

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

Реляционная алгебра, определенная Коддом, состоит из 8 операторов. Их можно разделить на две группы: реляционные операции, аналогичные традиционным операциям над множествами, и собственно реляционные операции.

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

Реляционные операторы, аналогичные традиционным операциям над множествами:

1) Объединение. Результатом объединения отношений R1 и R2 является отношение R3, содержащее все кортежи, которые принадлежат хотя бы одному из R1 и R2.

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

a) каждое из них имеет одно и то же множество атрибутов;

b) соответствующие атрибуты определены на одном и том же домене.

На языке SQL: R1 UNION R2

Например: допустим, в БД Факультет имеются отдельные отношения Лаборанты и Преподаватели. Эти две таблицы можно объединить, в результате получиться отношение, содержащее все данные на сотрудников факультета: и преподавателей, и лаборантов.

2) Пересечение. Результатом пересечения отношений R1 и R2 является отношение R3, содержащее кортежи, принадлежащие и R1, и R2. Для этой операции также должно выполняться условие совместимости по типу.

НаязыкеSQL: R1 Intersect R2

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

3) Вычитание. Результатом вычитания отношения R2 из отношения R1 является отношение R3, все кортежи которого принадлежат R1 и не принадлежат R2. Условие совместимости по типу также должно выполняться.

На языке SQL:R1 Minus R2

Например, из тех же отношений Лаборанты и Студенты базы данных Факультет можно выяснить, какие студенты не работают лаборантами на факультете и наоборот.

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

R1

R2

R3

a

x

a

x

b

y

a

y

c

b

x

b

y

c

x

c

y

5) соответственно отношениям R1 и R2.

На языке SQL:R1 TIMES R2

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

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

Собственно реляционные операторы:

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

Можно сказать, что это «горизонтальное» подмножество начального отношения.

На языке SQL:R1 WHERE xθy (θ (тэта) – любой оператор сравнения: <,>,=,…)

Например, из отношения Студенты (№ЗачетнойКнижки, Фамилия, Имя, Отчество, КодГруппы) вывести данные о тех, кто учится в группе ИНФ-31.

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

Можно сказать, что это «вертикальное» подмножество начального отношения.

Специального оператора на SQL для проекции нет, т.к. для ее выполнения достаточно в стандартной конструкции запроса SELECT указать, какие атрибуты отношения берутся.

Обратим внимание на частные случаи:

·возможно указание списка всех атрибутов исходного отношения - это тождественная проекция;

·возможно указание пустого списка атрибутов – это нулевая проекция.

Например, из отношения Студенты (№ЗачетнойКнижки, Фамилия, Имя, Отчество, ДатаРождения, Адрес, Телефон, Группа) вывести для всех студентов информацию только о фамилии, имени, отчестве и группе.

7) Соединение. Результатом соединения отношений R1 и R2 является отношениеR3, кортежи которого – это сцепление двух кортежей (принадлежащих соответственно R1 и R2), имеющих общее значение для одного или нескольких общих атрибутов R1 и R2.

Общий случай

Частный случай

R1

R2

R1

R2

a

x

x

l

a

x

x

l

b

y

y

m

b

y

y

m

c

z

z

n

c

z

y

n

R3

R3

a

x

l

a

x

l

b

y

m

b

y

m

c

z

n

b

y

n

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

На языке SQL:R1 JOIN R2

Соединение обладает свойствами:

  • ассоциативность: (R1 JOIN R2) JOIN R3=R1 JOIN (R2 JOIN R3);
  • коммутативность: (R1 JOIN R2) JOIN R3=R1 JOIN R2 JOIN R3.

Эта операция имеет несколько разновидностей, но самое распространенное – естественное соединение (на схеме). Есть еще θ(тэта)-соединение. Оно предназначено для случаев, когда два отношения соединяются на основе некоторых условий (xθy), отличных от эквивалентности.

В этом случае на SQL: (R1 TIMES R2) WHERE xθy,т.е. сочетание произведения и выборки.

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

Пример θ-соединения: соединение отношений Студенты и Группы по атрибуту Группа так, чтобы получить информацию о студентах только групп 5 курса.

8) Деление. Дадим определение для частного случая: для отношений R1 (бинарного) и R2 (унарного) результатом деления является отношение R3, содержащее все значения одного

R1

R2

a

x

x

a

y

y

a

z

b

x

R3

c

y

a

9) атрибута R1, которые соответствуют в другом атрибуте всем значениям R2. Для отношений с большим количеством атрибутов – аналогично.

НаязыкеSQL: R1 DIVIDEBY R2

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

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

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

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

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

EXTEND <имя отношения> ADD (<скалярное выражение>) AS< имя нового атрибута>

Примеры:

1) Пусть есть отношение Преподаватели (КодПреподавателя, Фамилия, Имя, Отчество, ДатаПринятия). Для каждого преподавателя вывести стаж работы.

EXTEND Преподаватели ADD (year(date())-year(ДатаПринятия)) AS Стаж

2) Частный случай - добавление нового атрибута, заполненного одинаковыми значениями: в отношение СекцииКружки базы данных Факультет добавить атрибут МестоПроведения, заполнив его одинаковыми значениями для всех секций – «ВятГГУ».

EXTEND СекцииКружки ADD («ВятГГУ») AS МестоПроведения

3) Частный случай - переименование атрибута Адрес отношения Студенты в АдресРегистрации.

EXTEND Студенты ADD (Адрес) AS АдресРегистрации

Операция подведения итогов

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

SUMMARIZE <имя отношения> BY (<список имен атрибутов>)

ADD< групповая операция> AS <имя поля для итогового значения>

Групповыми операциями могут быть:

sum (<имя атрибута>) – сумма числовых значений;

count (<имя атрибута>) – количество значений;

min (<имя атрибута>) – минимальное значение;

max (<имя атрибута>) – максимальное значение.

Примеры:

1) Имеется отношение Студенты (№ЗачетнойКнижки, Фамилия, Имя, Отчество, КодГруппы) Подсчитать количество студентов в каждой группе.

SUMMARIZE Студенты BY (КодГруппы) ADD count(№ЗачетнойКнижки)

AS КоличествоСтудентов

2) Имеется отношение Занятия (КодГруппы, Дисциплина, Преподаватель). Подсчитать количество групп, которые изучают более 10 дисциплин.

(SUMMARIZE Занятия BY (КодГруппы) ADD count(Дисциплина) AS N) WHERE N>10

2.3.4. Операции обновления

К операциям обновления относятся операции вставки, изменения и удаления.

Вставка: INSERT (<реляционное выражение или список атрибутов>) INTO <имя отношения>

Примеры:

1) Вставить новую запись в отношение Студенты.

INSERT (№зачетки=123456; Фамилия=«Иванов»; Имя=«Иван») INTO Студенты

2) В отношение Студенты31группы вставить те записи из отношения Студенты, которыесоответствуют студентам группы ИНФ-31.

INSERT (Студенты WHERE КодГруппы = «ИНФ-31») INTO Студенты31группы

Изменение: UPDATE <имя отношения> <реляционное выражение>

Пример: В отношении Студенты изменить группы «ИНФ-31» на «ИНФ-41».

UPDATE Студенты WHERE КодГруппы=«ИНФ-31» КодГруппы:=«ИНФ-41»

Удаление: DELETE< реляционное выражение>

Пример: Из отношения Студенты удалить всех студентов группы ИНФ-51.

DELETE Студенты WHERE КодГруппы=«ИНФ-51»

2.3.5. Значение реляционной алгебры

Основная цель реляционной алгебры – обеспечить запись выражений. А реляционные выражения не ограничиваются запросами.

В качестве примеров можно привести такие применения выражений:

  • определение области выборки (WHERE…);
  • определение области обновления (т.е. данных для вставки, изменения или удаления);
  • определение правил целостности;
  • определение правил безопасности (т.е. данных, для которых осуществляется контроль доступа).

То есть, можно сказать, что выражения обозначают символическую запись намерений пользователя БД, и эта символическая запись существует на языке SQL.

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