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

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

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

Представьте себе, что вы делаете заказ в интернет-магазине. Чтобы этот заказ был успешно обработан и доставлен, системе нужно учесть множество деталей: кто вы (покупатель), какую службу доставки вы выбрали, куда доставить, и как отслеживать статус посылки.

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

На этой схеме показан пример организации данных для процесса отслеживания доставок:

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

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

Условный пример таблицы Доставка заказа:

Преимущества такого подхода:

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

Структура реляционной базы данных

Ядром реляционной базы данных являются таблицы. Каждая таблица имеет:

• Имя (Table Name) чтобы мы могли её идентифицировать — например, customers.
• Набор столбцов (Columns/Attributes), определяющих свойства объекта.
  • При именовании столбцов, которые служат уникальными номерами (первичными ключами), часто используем шаблон имя_id . Суффикс _id здесь означает "identifier". Пример: Номер Покупателя станет customer_id.
  • Например, для таблицы customers: это могут быть customer_id, first_name, email и так далее.
• Данные в строках (Rows/Records) - одна строка в таблице customers: будет содержать полную информацию об одном конкретном покупателе (101, Alex Song и так далее).

Рассмотрим пример таблицы — customers:

Ключи таблиц

Чтобы уникально определить каждую строку в таблице, используется первичный ключ (Primary Key, PK). Это столбец (или несколько), значения которого уникальны для каждой строки и не могут быть пустыми. Представьте его как уникальный номер для каждой записи, например, customer_id в нашей таблице customers: однозначно идентифицирует каждого покупателя.

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

Для установления связей между таблицами используется внешний ключ (Foreign Key, FK). Это столбец в одной таблице, который ссылается на первичный ключ в другой таблице. Внешние ключи – это "мостики" между таблицами. Часто имя столбца внешнего ключа совпадает с именем первичного ключа, на который он ссылается. Например, в таблице deliveries столбец customer_id будет внешним ключом, хранящим значения из столбца customer_id таблицы customers, таким образом связывая доставку с покупателем.

Это знакомая нам схема, но теперь она приведена к более реалистичному виду.

• Таблица customers содержит информацию о клиентах; ее первичный ключ – customer_id.
• Таблица delivery_services хранит данные о службах доставки; ее первичный ключ – service_id.
• Таблица orders (показана для полноты, так как на нее есть ссылка order_id из таблицы доставок) предназначена для информации о заказах, с первичным ключом order_id.
• Таблица deliveries является центральной для отслеживания операций доставки. Она имеет:
  • Собственный первичный ключ: delivery_id.
  • Три внешних ключа для установления связей:
    • customer_id (FK): связывает доставку с конкретным покупателем из таблицы customers.
    • service_id (FK): связывает доставку с выбранной службой из таблицы delivery_services .
    • order_id (FK): связывает доставку с соответствующим заказом из таблицы orders .
  • Поле created_date указывает на дату и время создания записи о доставке.

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

Преимущества реляционной модели

Реляционная модель имеет ряд существенных плюсов, которые делают её лидером среди других подходов:

1. Простота структуры. Таблицы с колонками и строками понятны и просты.
2. Гибкость в работе с данными. Можно легко добавлять новые данные или изменять их, не нарушая целостность.
3. Поддержка сложных запросов. С помощью SQL можно извлекать данные из множества таблиц, комбинировать их, фильтровать и делать практически всё, чего требует ваша задача. Например, найти всех студентов, записанных на конкретный курс — легко!
4. Целостность данных через ключи. Использование первичных и внешних ключей гарантирует, что данные в базе будут согласованными. Нельзя, например, добавить запись о студенте на курс, если такого курса не существует.

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