Экспресс-курс · занятие 1 из 3

Обзорная лекция: СУБД и модели данных

О чём эта тема: Сжатое введение в мир баз данных для экспресс-курса: зачем появились СУБД, как развивалась отрасль от перфокарт до стандарта SQL и какими бывают модели данных — от иерархий и сетей до документов и реляционных таблиц.
Аннотация: Лекция открывается историей вопроса: два направления использования вычислительной техники и рождение специализированного ПО — систем управления базами данных — на рубеже 1960–70-х. Интерактивная шкала проводит по ключевым вехам: от первой СУБД Бахмана и реляционной статьи Кодда до стандарта SQL и признания реляционной модели журналом Forbes. Далее классификация моделей данных: иерархическая с её компонентами и ограничениями, сетевая, графовая с критерием выбора по Клеппману, объектно-ориентированная с преимуществами и недостатками, документная и реляционная — со сравнительной таблицей. Завершают лекцию главные концепции реляционных БД — отношение, кортеж, атрибут, домен, первичный ключ — и обзор популярных СУБД, включая российские Postgres Pro и Arenadata DB. Развёрнутая версия материала — в лекции 1 основного курса.
Пререквизиты: Нет — это первое занятие экспресс-курса.
Мотивация: Экспресс-курс за три занятия проходит путь от понятия «данные» до JOIN и агрегатных функций. Обзорная лекция задаёт систему координат: не выучить все модели данных наизусть, а понять, какие задачи каждая решает и почему в практических занятиях мы будем работать именно с реляционной моделью и SQL.

1. Как появились СУБД

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

Однако со временем использование компьютеров для сложных научных расчётов было вытеснено другим направлением. Активно развивались:

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

Развитие этого направления привело к тому, что в конце 60-х — начале 70-х годов появилось специализированное программное обеспечение, получившее название система управления базами данных (DataBase Management System, DBMS).

1.1. Назначение СУБД. Что такое база данных?

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

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

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

СУБД позволяют не только хранить данные, но и управлять ими: создавать, изменять и удалять информацию, выполнять запросы к данным. Благодаря специализированным языкам, таким как SQL (Structured Query Language), пользователи могут эффективно извлекать нужную информацию из базы данных.

Модель данных, на которой основана база, определяет её структуру и способы доступа к данным: реляционные базы организованы в виде таблиц, но есть и другие модели — объектно-ориентированные базы данных, NoSQL-системы — каждая со своими особенностями и применениями.

Итого, СУБД позволяют: систематизировать данные в базе данных и организовывать данные для их сохранения на компьютерах.

2. История развития баз данных

Пройдитесь по вехам на интерактивной шкале — щёлкайте по годам или листайте кнопкой «далее»:

Интерактивная шкала: 1955 — 2002

3. Классификация БД

Классификация моделей данных включает различные подходы к организации и хранению информации.

3.1. Иерархическая модель

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

Базы данных с иерархической моделью — одни из самых старых; они стали первыми СУБД для мейнфреймов. Разрабатывались в 1950–60-х — например, Information Management System (IMS) фирмы IBM.

Компоненты иерархической модели:

поле данных (атрибут) — минимальная неделимая, уникально адресуемая единица хранения данных;
сегмент данных (запись, record) — совокупность полей данных с уникальной идентификацией;
экземпляр сегмента — конкретные значения полей;
дерево — совокупность сегментов, связанных связью «родитель — потомок».

Проблемы иерархической модели Требуется много памяти для хранения (производительность); сложно контролировать целостность данных; дублирование данных; скорость операций записи; огромные трудности при реорганизации структуры; невозможна связь «многие-ко-многим».

3.2. Сетевая модель

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

Сетевая модель состоит из основных компонентов:

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

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

3.3. Графовые модели данных

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

Пример — Amazon Neptune: публично-облачная графовая СУБД в составе Amazon Web Services. Поддерживает графовые модели RDF и LPG и, соответственно, языки запросов SPARQL и Gremlin. Выпущена в тестовом режиме 29 ноября 2017 года, в коммерческую эксплуатацию введена 30 мая 2018 года.

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

Если в вашем приложении планируется много сущностей и связей «многие-ко-многим» — это один из признаков, что предпочтительнее выбрать графовую СУБД (утверждение Мартина Клеппмана в книге «Designing Data-Intensive Applications»). А если у вас уже есть приложение с множеством связей, и обход этих связей занимает много времени и ресурсов, — стоит присмотреться в сторону графов: обход связей в них практически ничего не стоит.

3.4. Объектные модели данных

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

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

Объектно-реляционные модели данных — комбинация объектной и реляционной моделей: позволяют использовать преимущества объектной модели внутри реляционной структуры базы данных.

Преимущества объектно-ориентированных моделей:

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

Недостатки:

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

3.5. Документо-ориентированные модели

Документо-ориентированная модель специально предназначена для хранения иерархических структур данных — документов. Документ — набор атрибутов (ключ и соответствующее ему значение); документ может быть вложен в документ. Представление данных — формат JSON или XML. Такие базы применяются в системах управления содержимым, издательском деле, документальном поиске и т. п.

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

Примеры СУБД: CouchDB, Couchbase, MarkLogic, MongoDB, eXist, Berkeley DB.

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

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

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

Примеры: MySQL, Oracle DB.

3.7. Сравнение основных моделей

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

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

4. Главные концепции реляционных баз данных

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

каждый элемент таблицы — один элемент данных;
все ячейки в столбце однородны: элементы столбца имеют одинаковый тип;
каждый столбец имеет уникальное имя;
одинаковые строки в таблице отсутствуют;
порядок следования строк и столбцов может быть произвольным.

Отношение — фундаментальное понятие реляционной модели данных; по этой причине модель и называется реляционной (от английского relation — отношение).

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

Каждое отношение делится на заголовок и тело. Тело состоит из кортежей, заголовок более мелких компонентов не имеет. Название атрибута может состоять из двух частей, разделённых двоеточием (например, UnitPrice:Currency): имя атрибута и имя домена. Домен атрибута — вид данных, которые представляет атрибут (в примере — валюта); понятие «домен» не эквивалентно понятию «тип данных».

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

Формализованное определение: заголовок H_r — конечное множество пар ⟨A, T⟩ с различными именами атрибутов; кортеж t_r — множество триплетов ⟨A, T, v⟩ с допустимыми значениями доменов; тело B_r — неупорядоченное множество различных кортежей; значение V_r — пара множеств H_r и B_r. Первичный ключ — минимальный набор атрибутов, однозначно определяющий кортеж; при добавлении новых записей он обязан оставаться первичным ключом (поэтому набор «Имя + Отчество + Фамилия» — неверный выбор, даже если тёзок пока нет).

4.1. Домен

Домен определяет «вид» данных атрибута; точнее — это набор всех допустимых значений атрибута. Домен часто путают с типом данных, но тип данных — физическая концепция, а домен — логическая: «целое число» — тип, «возраст» — домен. Домен — это тип данных плюс логические правила, определённые для сущности; правила — механизм целостности данных, а не элемент их описания.

5. Самые популярные СУБД

Российский рынок СУБД постепенно развивается, и на нём появляются многообещающие продукты. Несмотря на популярность мировых лидеров — Oracle, MySQL и Microsoft SQL Server, — в России активно используют и разрабатывают собственные СУБД.

Oracle Database — одна из наиболее узнаваемых СУБД в мире: высокая надёжность и поддержка корпоративных приложений, от аналитики до высокопроизводительной обработки транзакций.

MySQL — открытая реляционная СУБД, популярная в веб-разработке и малом бизнесе благодаря бесплатности и лёгкости использования.

Microsoft SQL Server — функциональность для приложений под Windows и интеграция с продуктами Microsoft.

MongoDB — нереляционная (NoSQL) СУБД с хранением в формате JSON: гибкость для неструктурированных данных, масштабируемость и скорость.

Российская СУБД Postgres Pro основана на открытой PostgreSQL и доработана под требования корпоративного сегмента. Arenadata DB (ADB) — реляционная СУБД на основе распределённой Greenplum, ориентированная на анализ больших объёмов данных; включена в реестр российского ПО.

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

Первое — научные расчёты (численные методы, Fortran). Второе — надёжное хранение и преобразование информации с удобным интерфейсом; развитие именно этого направления к концу 1960-х породило специализированное ПО — системы управления базами данных.
1961–1963 — первая СУБД IDS Чарльза Бахмана (сетевая модель); 1970 — статья Эдгара Кодда о реляционной модели; 1976 — модель «сущность-связь» Питера Чена. Обе премии Тьюринга отрасли: Бахман (1973) и Кодд (1981).
У каждого объекта-потомка по определению ровно один предок. Моделировать M:N приходится дублированием поддеревьев, что порождает избыточность, риск рассогласования и трудности реорганизации структуры.
Комбинация объектной и реляционной моделей: преимущества объектного подхода (свои типы, методы, наследование) используются внутри реляционной структуры базы. По этому пути идёт и PostgreSQL, позволяющий определять пользовательские типы данных.
Каждый элемент — один элемент данных; ячейки столбца однородны по типу; имена столбцов уникальны; одинаковых строк нет; порядок строк и столбцов произволен.
Мощность (кардинальное число) — количество кортежей, то есть строк; размерность — количество атрибутов, то есть столбцов. Отношение с одним атрибутом — унарное, с двумя — бинарное, с n — n-арное.
Реляционная — PostgreSQL/MySQL/Oracle; документная — MongoDB (также CouchDB, Couchbase); графовая — Amazon Neptune (RDF/LPG, SPARQL/Gremlin). Российские: Postgres Pro (на базе PostgreSQL) и Arenadata DB (на базе Greenplum).

Источники

Дейт, К. Дж. Введение в системы баз данных / К. Дж. Дейт. — 8-е изд. — М. : Вильямс, 2005. — 1328 с.
Codd, E. F. A Relational Model of Data for Large Shared Data Banks // Communications of the ACM. — 1970. — Vol. 13, № 6. — P. 377–387.
Клеппман, М. Высоконагруженные приложения. Программирование, масштабирование, поддержка / М. Клеппман. — СПб. : Питер, 2018. — 640 с.
DB-Engines Ranking : [сайт]. — URL: https://db-engines.com/en/ranking (дата обращения: 18.08.2026).