Лекции · конспект 2 из 9

Механизмы управления реляционными базами данных

О чём эта тема
Математический фундамент реляционных СУБД: строгое определение отношения через декартово произведение доменов, восемь операций реляционной алгебры Кодда — с живым тренажёром, где каждую операцию можно выполнить руками, — и три уровня моделирования базы данных: концептуальный, логический и физический.
Аннотация
Конспект открывается формальным определением отношения: домены, заголовок, тело, кортежи, мощность и арность — с числовым примером, где из 18 кортежей декартова произведения тело отношения оставляет пять осмысленных. Далее вводится реляционная алгебра и её главное свойство — замкнутость: результат каждой операции сам является отношением, поэтому операции можно вкладывать друг в друга. Разобраны восемь операций Кодда: четыре теоретико-множественные (произведение, объединение, пересечение, вычитание) и четыре специальные (выборка, проекция, соединение, деление), для соединения — иерархия частных случаев от θ-соединения до естественного. Тренажёр в середине конспекта выполняет каждую операцию на маленьких таблицах и показывает SQL-эквивалент. Завершает конспект методология проектирования: концептуальная, логическая и физическая модели на сквозном примере базы данных авиаперелётов и три нотации ER-диаграмм.
Пререквизиты
Лекция 1 — понятия отношения, атрибута, кортежа, домена. Из математики — множества и операции над ними на уровне первого курса.
Мотивация
Каждый SQL-запрос, который вы напишете в этом курсе, — это выражение реляционной алгебры, замаскированное английскими словами. Когда PostgreSQL получает SELECT name FROM nyc_neighborhoods WHERE boroname = 'Brooklyn', он строит план из тех самых операций Кодда: выборки и проекции. Понимание алгебры — это умение читать планы запросов, предсказывать их стоимость и понимать, почему оптимизатор переставляет операции местами. А уровни моделирования — это язык, на котором проектировщик БД разговаривает с заказчиком, не упоминая ни одного типа данных.

1. Реляционные базы данных: основные понятия

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

Основные понятия:

2. Формальное определение отношения

Пусть дана совокупность типов данных \(T_1, T_2, \ldots, T_n\), называемых также доменами, не обязательно различных. Тогда n-арным отношением R, или отношением R степени n, называют подмножество декартова произведения множеств \(T_1 \times T_2 \times \ldots \times T_n\).

Отношение как подмножество декартова произведения доменов

Отношение R состоит из заголовка (схемы) и тела. Более строго:

Количество кортежей называют кардинальным числом отношения (кардинальностью), или мощностью отношения. Количество атрибутов называют степенью, или «арностью», отношения: отношение с одним атрибутом — унарное, с двумя — бинарное, с n атрибутами — n-арное. С точки зрения теории вполне корректно и отношение с нулевым количеством атрибутов, которое либо не содержит кортежей, либо содержит единственный пустой кортеж.

Основные свойства отношения:

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

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

По определению К. Дж. Дейта, таблица является прямым и верным представлением отношения, если она удовлетворяет пяти условиям:

  1. нет упорядочивания строк сверху вниз (порядок строк не несёт информации);
  2. нет упорядочивания столбцов слева направо;
  3. нет повторяющихся строк;
  4. каждое пересечение строки и столбца содержит ровно одно значение из соответствующего домена — и больше ничего;
  5. все столбцы являются «обычными»: в таблице нет скрытых компонентов, доступных только через специальные операторы, нет скрытых идентификаторов строк и временных меток — строки идентифицируются только значениями потенциальных ключей.

2.1. Пример

Пусть заданы следующие типы (домены): T1 = {Иванов, Петров, Сидоров}, T2 = {Информатика, Геодезия}, T3 = {3, 5, 4}.

Декартово произведение \(T_1 \times T_2 \times T_3\) состоит из 18 кортежей, где каждый кортеж содержит три значения: фамилию, учебную дисциплину и оценку. Фрагмент произведения:

ФамилияДисциплинаОценка
ИвановИнформатика3
ИвановИнформатика5
ИвановИнформатика4
ИвановГеодезия3
СидоровГеодезия4

Тело отношения R моделирует реальную ситуацию и содержит пять кортежей, соответствующих результатам сессии (при условии, что Петров экзамен по информатике не сдавал):

ФамилияДисциплинаОценка
ИвановИнформатика5
ИвановГеодезия4
ПетровГеодезия5
СидоровИнформатика3
СидоровГеодезия5
Типичная ошибка Путать отношение с декартовым произведением доменов. Произведение перечисляет все возможные комбинации значений (18 кортежей), а отношение — лишь те, что соответствуют действительности (5 кортежей). Отношение — всегда подмножество произведения своих доменов.

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

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

N-арную реляционную операцию f можно представить функцией, возвращающей отношение и имеющей n отношений в качестве аргументов:

\[ R = f(R_1, R_2, \ldots, R_n) \tag{2.1} \]

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

\[ R = f\bigl(f_1(R_{11}, R_{12}, \ldots),\; f_2(R_{21}, R_{22}, \ldots), \ldots\bigr) \tag{2.2} \]

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

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

Теоретико-множественные операторы
объединение UNION пересечение INTERSECT вычитание DIFFERENCE ×произведение CARTESIAN PRODUCT
Специальные реляционные операторы
σвыборка SELECT πпроекция PROJECT соединение JOIN ÷деление DIVISION

3.1. Теоретико-множественные операторы

ПРОИЗВЕДЕНИЕ (×) — построить декартово произведение двух отношений. Пусть R — таблица степени k1, S — таблица степени k2. Тогда R × S — множество всех (k1 + k2)-кортежей, первые k1 элементов которых образуют кортеж из R, а последние k2 — кортеж из S.

ОБЪЕДИНЕНИЕ, UNION (∪) — построить теоретико-множественное объединение двух таблиц. Даны таблицы R и S (обе должны иметь одинаковую степень); объединение R ∪ S — множество кортежей, принадлежащих R, или S, или обоим.

ПЕРЕСЕЧЕНИЕ, INTERSECT (∩) — построить теоретико-множественное пересечение таблиц: множество кортежей, принадлежащих и R, и S. Отношения также должны иметь одинаковую степень.

ВЫЧИТАНИЕ, DIFFERENCE (−) — построить множество различий двух таблиц одинаковой степени: R − S — это множество кортежей R, не принадлежащих S.

3.2. Специальные реляционные операторы

ВЫБОРКА, SELECT (σ) — извлечь кортежи отношения, которые удовлетворяют заданным условиям. Пусть R — таблица с атрибутом A. Тогда

\[ \sigma_{A=a}(R) = \{ t \in R \mid t(A) = a \}, \tag{2.3} \]

где t — кортеж R, а t(A) — значение атрибута A кортежа t. В простейшем случае условие имеет вид \(\sigma_C(R)\), где C — сравнение с одним из операторов (=, ≠, <, > и т. д.). Такие выборки называются θ-выборками (тэта-выборками).

Синтаксис операции выборки: \(\sigma_C(R)\), что эквивалентно SELECT * FROM R WHERE C.

Пример. Дано отношение A с информацией о сотрудниках:

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

Результат выборки \(\sigma_{\text{Зарплата} < 3000}(A)\):

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

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

ПРОЕКЦИЯ (π) — извлечь заданные атрибуты (колонки) из отношения. Пусть R — отношение с атрибутом X. Тогда

\[ \pi_X(R) = \{ t(X) \mid t \in R \}, \tag{2.4} \]

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

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

Пример. Отношение о поставщиках:

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

Проекция на атрибут «Город поставщика» содержит три кортежа — дубликат «Москва» удалён:

Город поставщика
Уфа
Москва
Челябинск
Типичная ошибка Забывать об удалении дубликатов. В строгой реляционной алгебре проекция четырёх строк на город даёт три кортежа, а SQL по умолчанию дубликаты сохраняет: чтобы получить алгебраическую проекцию, нужен SELECT DISTINCT.

СОЕДИНЕНИЕ, JOIN (⋈) — соединить две таблицы по их общим атрибутам. Пусть R — таблица с атрибутами A, B, C, а S — таблица с атрибутами C, D, E; общий атрибут — C. Тогда

\[ R \bowtie S = \pi_{R.A,\,R.B,\,R.C,\,S.D,\,S.E}\bigl(\sigma_{R.C=S.C}(R \times S)\bigr). \tag{2.5} \]

Что здесь происходит? Сначала вычисляется декартово произведение R × S. Затем выбираются кортежи, у которых значения общего атрибута совпадают (σR.C=S.C). Полученная таблица содержит атрибут C дважды — повторяющаяся колонка удаляется проекцией.

Пример. Отношения «Служащий» и «Отдел», условие соединения — «Служащий.[Код отдела] = Отдел.[Код отдела]»:

ФамилияКод отдела
Иванов34
Петров36
Сидоров34
Сергеев34
НазваниеКод отдела
Бухгалтерия34
Маркетинг36

Результат соединения:

ФамилияКод отделаНазвание
Иванов34Бухгалтерия
Петров36Маркетинг
Сидоров34Бухгалтерия
Сергеев34Бухгалтерия

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

Разновидности операции соединения:

Наиболее важный частный случай — естественное соединение. Пусть даны отношения A(A1, …, An, X1, …, Xp) и B(X1, …, Xp, B1, …, Bm) с одинаковыми атрибутами X1, …, Xp (одинаковые имена, одинаковые домены). Тогда естественным соединением A и B называется отношение с заголовком (A1, …, An, X1, …, Xp, B1, …, Bm) и телом, содержащим кортежи (a1, …, an, x1, …, xp, b1, …, bm) такие, что (a…, x…) ∈ A и (x…, b…) ∈ B. Для него используется специальный синтаксис — A JOIN B.

Замечания

1. В синтаксисе естественного соединения не указываются атрибуты соединения: оно производится по всем одинаковым атрибутам.

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

3. Можно выполнять последовательное естественное соединение нескольких отношений: соединение обладает свойством ассоциативности.

ДЕЛЕНИЕ, DIVISION (÷) — применяется, когда нужно найти множество значений, связанных со всеми значениями другого множества. Пусть R — отношение с атрибутами A и B, а S — унарное отношение с атрибутом B. Тогда R ÷ S — множество значений A, для которых в R существуют все соответствующие значения из S.

Замечание Типичные запросы, реализуемые делением, обычно содержат в формулировке слово «все»: «студенты, сдавшие все дисциплины», «поставщики, поставляющие все детали».

В общем виде: пусть отношения R и S имеют атрибуты X1, …, Xm и Y1, …, Yn соответственно, причём имена не пересекаются, а отношение-посредник T имеет заголовок из объединения заголовков R и S. Рассматривая {X1, …, Xm} и {Y1, …, Yn} как составные атрибуты X и Y, операцию деления R на S по T записывают как R DIVIDEBY S PER T. Результат — отношение с заголовком {X} и телом из таких кортежей {X x}, присутствующих в R, что кортеж {X x, Y y} присутствует в T для всех кортежей {Y y} из S. Иными словами, результат состоит из тех значений X, для которых соответствующие значения Y в T включают все значения Y из S.

3.3. Выразимость одних операций через другие

Некоторые реляционные операции выражаются через другие — базис алгебры избыточен:

4. Тренажёр реляционной алгебры

Все восемь операций Кодда — на маленьких отношениях из этой лекции. Выберите операцию: тренажёр покажет операнды, вычислит результат и приведёт SQL-эквивалент. У выборки и проекции есть параметры — условие и набор атрибутов; попробуйте разные комбинации и проследите, как меняется результат. Кортежи, попавшие в результат, подсвечиваются в исходных таблицах.

Тренажёр: операции реляционной алгебры

5. Методы моделирования БД

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

5.1. Концептуальное моделирование

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

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

Основные компоненты:

Создание концептуальной модели включает этапы:

  1. Определить сущности — перечислить ключевые объекты домена, которые требуют хранения и поиска.
  2. Определить атрибуты — зафиксировать основные свойства каждой сущности, не углубляясь в типы данных и ограничения.
  3. Установить отношения — проанализировать связи и убедиться, что они имеют смысл с точки зрения бизнеса.
  4. Обзор и уточнение — проверить модель на несоответствия, избыточность и недостающую информацию, при необходимости обновить.

Пример — концептуальная модель авиаперелётов:

Концептуальная модель базы данных перелётов

Основная сущность — бронирование (bookings). В одно бронирование можно включить несколько пассажиров, каждому выписывается отдельный билет (tickets). Билет имеет уникальный номер и содержит информацию о пассажире; как таковой пассажир отдельной сущностью не является — имя и номер документа могут меняться со временем, так что однозначно найти все билеты одного человека невозможно; для простоты считаем всех пассажиров уникальными.

Билет включает один или несколько перелётов (ticket_flights): когда нет прямого рейса и полёт идёт с пересадками либо когда билет взят «туда и обратно». Жёсткого ограничения в схеме нет, но предполагается, что все билеты одного бронирования имеют одинаковый набор перелётов.

Каждый рейс (flights) следует из одного аэропорта (airports) в другой. Рейсы с одним номером имеют одинаковые пункты вылета и назначения, но отличаются датой отправления.

При регистрации пассажиру выдаётся посадочный талон (boarding_passes) с указанием места. Пассажир может зарегистрироваться только на рейс из своего билета; комбинация рейса и места уникальна — чтобы не выдать два талона на одно место.

Количество мест (seats) и их распределение по классам обслуживания зависит от модели самолёта (aircrafts), выполняющего рейс. Предполагается, что каждая модель имеет одну компоновку салона. Схема не контролирует соответствие мест в талонах реальным местам самолёта — такая проверка делается табличными триггерами или в приложении.

5.2. Логическое моделирование

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

Важнейшие компоненты:

Шаги создания: уточнение сущностей, атрибутов и связей → определение типов данных и ограничений → нормализация (устранение избыточности, проверка соответствия 1НФ, 2НФ, 3НФ — подробно в лекции 3).

Пример — логическая модель перелётов:

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

Таблицы:

  1. Aircrafts — код самолёта, модель, максимальная дальность полёта (км);
  2. Airports — код аэропорта, название, город, координаты (широта, долгота), временная зона;
  3. Boarding_passes — номер билета, идентификатор рейса, номер посадочного талона, номер места;
  4. Bookings — номер бронирования, дата, полная сумма;
  5. Flights — идентификатор рейса, номер рейса, время вылета и прилёта по расписанию, аэропорты отправления и прибытия, статус, код самолёта, фактические времена вылета и прилёта;
  6. Seats — код самолёта, номер места, класс обслуживания;
  7. Ticket_flights — номер билета, идентификатор рейса, класс обслуживания, стоимость перелёта;
  8. Tickets — номер билета, номер бронирования, идентификатор, имя и контактные данные пассажира.

Представления:

  1. bookings.flights_v — рейс со временами по расписанию и местными, планируемой и фактической продолжительностью полёта, кодами, названиями и городами аэропортов отправления и прибытия, статусом и кодом самолёта;
  2. routes — материализованное представление: номер рейса, аэропорты отправления и прибытия с городами, код самолёта, продолжительность полёта, дни недели выполнения рейса.

5.3. Физическое моделирование

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

Ключевые компоненты:

Этапы: выбор СУБД (PostgreSQL, MySQL, SQL Server — выбор определяет доступные типы и ограничения) → сопоставление логических сущностей таблицам → определение индексов и ограничений → создание объектов базы инструментом моделирования или SQL-скриптами. Физическая модель — важный справочный документ и для разработчиков, и для аналитиков, и для системных администраторов.

5.4. Методики логического проектирования

Для логического проектирования реляционных хранилищ данных применяются методики:

5.5. Основные понятия модели «сущность-связь»

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

В системе сущность представлена экземплярами: экземпляры сущности «Аэропорт» — аэропорты «Домодедово», «Пулково», «Воронеж». У сущностей есть атрибуты — характеристики, которые их описывают: код, адрес, номер телефона. Атрибуты есть у каждого экземпляра, но значения у них разные: у «Домодедово» и «Воронежа» одинаковый атрибут «Адрес» с разными значениями.

Собрав сущности, аналитик выясняет, как они связаны, и составляет ER-модель (entity–relationship, модель «сущность-связь»). Типы связей:

Аналитик создаёт ER-диаграмму — схему, которая показывает, с какими данными предстоит работать и как они связаны: например, что багаж связан с номером рейса, но не связан со временем окончания посадки. Специальные инструменты не обязательны — диаграмму можно построить в любом графическом редакторе из прямоугольников, стрелок и линий.

Для построения ER-диаграмм используют разные нотации. Три самые известные:

  1. Нотация IDEF1X — фундаментальная, но на практике давно не используется: есть более удобные варианты.
  2. Нотация Чена — классическая, из простых символов: прямоугольников, овалов и линий. Её часто используют для концептуальных моделей, которые презентуют заказчику: человеку, далёкому от аналитики данных, проще разобраться в понятных диаграммах.
  3. Нотация Мартина («воронья лапка», Crow's Foot) — компактнее нотации Чена, поэтому используется для моделей логического уровня, где нужно описать все атрибуты сущностей.
Нотации ER-диаграмм

Элементы диаграммы в нотации Чена соединяются линиями; над линией между сущностями обозначают тип связи: 1:1 — «один-к-одному», 1:N — «один-ко-многим», M:N — «многие-ко-многим».

Связи в нотации Чена

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

Сущность и атрибуты в нотации Мартина

Три типа связи в нотации Мартина изображаются разными комбинациями окончаний линий; например, связь «многие-ко-многим» выглядит так:

Связь многие-ко-многим в нотации Мартина

Контрольные вопросы

Источники

  1. Codd, E. F. A Relational Model of Data for Large Shared Data Banks // Communications of the ACM. — 1970. — Vol. 13, № 6. — P. 377–387.
  2. Дейт, К. Дж. Введение в системы баз данных / К. Дж. Дейт. — 8-е изд. — М. : Вильямс, 2005. — 1328 с.
  3. Гарсиа-Молина, Г. Системы баз данных. Полный курс / Г. Гарсиа-Молина, Дж. Ульман, Дж. Уидом. — М. : Вильямс, 2003. — 1088 с.
  4. Демобаза данных «Авиаперевозки» — Postgres Professional : [сайт]. — URL: https://postgrespro.ru/education/demodb (дата обращения: 18.08.2026).