Введение в базы данных

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

Модель DIKW

Методологической основой здесь выступает модель DIKW (Data, Information, Knowledge, Wisdom — Данные, Информация, Знания, Мудрость). В рамках текущей дисциплины основное внимание уделяется нижним уровням иерархии, так как именно они подлежат автоматизированной обработке средствами СУБД.

Данные (Data)

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

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

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

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

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

Информация (Information)

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

Информация отвечает на вопросы идентификации: «Кто?», «Что?», «Где?», «Когда?».

Роль СУБД

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

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

Ценность информации зависит от задач конкретного потребителя (пользователя системы или алгоритма). Один и тот же набор данных может быть интерпретирован различным образом. Например, журнал событий сервера (log-файл) может быть преобразован в статистическую информацию о загрузке канала связи или в информацию о попытках несанкционированного доступа. В контексте языка SQL, процесс извлечения информации реализуется посредством выборки (SELECT) с наложением условий фильтрации, что позволяет выделить из общего массива данных сведения, релевантные текущей задаче.

Знания (Knowledge)

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

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

Уровень иерархии (DIKW)	Форма представления (Пример)	Характеристика и результат обработки
Данные	1705315200; SRV_DB_01; 92	Набор символов и числовых значений. Отсутствует семантический контекст: не определены единицы измерения, критичность показателей и временные метки (для внешнего наблюдателя).
Информация	«20.01.2026 в 14:00 зафиксирована температура процессора сервера БД №1, равная 92°C»	Данные структурированы и интерпретированы. Определен контекст (объект мониторинга, параметр, время). Зафиксирован факт выхода показателя за пределы эксплуатационной нормы.
Знания	Правило: «Сохранение температуры > 90°C более 3 минут приводит к термическому троттлингу и отказу СУБД»	Выявлена устойчивая причинно-следственная связь на основе анализа исторической выборки. Сформировано управляющее воздействие: автоматическая инициация миграции нагрузки на резервный узел.

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

Эволюция хранения данных: От файлов к СУБД

На ранних этапах развития вычислительной техники (1950–60-е годы) основным способом хранения информации являлись файловые системы. В рамках данного подхода каждое прикладное приложение (программа) самостоятельно управляло собственными данными, хранящимися в отдельных файлах. Логика работы с данными (чтение, запись, поиск, сортировка) была жестко зашита внутри кода конкретной программы. Операционная система предоставляла лишь базовые механизмы доступа к файлам, не контролируя их содержимое.

Недостатки файлового подхода

Несмотря на простоту реализации, децентрализованный файловый подход выявил ряд критических архитектурных недостатков:

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

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

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

Внедрение СУБД обеспечило реализацию фундаментального принципа независимости данных:

1. Физическая независимость: Изменение способа хранения данных на дисках (структуры файлов, индексов) не влияет на логику работы прикладных программ.
2. Логическая независимость: Изменение логической схемы данных (добавление новых полей или таблиц) не требует изменения кода программ, которые эти новые поля не используют.

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

СУБД как центр информационной системы

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

Концепция «Полиглотного хранения»

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

• Реляционные СУБД (PostgreSQL) — для хранения критически важных данных, требующих строгой согласованности.
• Кэширующие системы (Redis) — для снижения нагрузки путем размещения данных в оперативной памяти.
• Документо-ориентированные и колоночные СУБД — для неструктурированного контента и аналитической обработки логов.

Выбранная стратегия хранения данных определяет архитектурный стиль всей системы:

• Монолитная архитектура. Единая БД, максимальная целостность, но единая точка отказа.
• Сервис-ориентированная и микросервисная архитектура. Паттерн «Database per Service». Повышает отказоустойчивость, но требует сложных механизмов синхронизации.
• Распределенные (Cloud Native) системы. Гео-распределенное хранение, автоматическая репликация.

Классификация СУБД по модели данных

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

1. Реляционные СУБД (Relational DBMS)

Это исторически сложившийся стандарт для хранения структурированной информации. Данные организованы в виде двумерных таблиц. Основной характеристикой является жесткая схема (Schema-on-write). Сфера применения: учетные системы, финансовые транзакции, везде, где требуется строгая целостность и отсутствие дубликатов.

Импортозамещение и РФ

Мировым стандартом Open Source является PostgreSQL. В РФ данная СУБД стала стандартом де-факто:

• ФНС: Миграция с Oracle на Postgres Pro Enterprise (петабайты данных).
• Яндекс: Геоинформационные сервисы (Яндекс.Карты) на PostgreSQL + PostGIS.
• Avito: Высоконагруженные сервисы.
• 1С:Предприятие: Официальная поддержка PostgreSQL.

2. NoSQL (Not Only SQL)

Класс систем для специфических задач (сверхвысокая нагрузка, неструктурированные данные). NoSQL отказывается от ACID в пользу масштабируемости (теорема CAP).

Основные подклассы NoSQL:

• Документо-ориентированные. Хранят данные в виде документов (JSON/BSON). Пример: MongoDB.
  • В России: Разрабатывается СУБД «Енисей» (на базе CouchBase), интегрируемая в систему «Честный знак» для объединения миллионов кассовых аппаратов.
• Ключ-Значение (Key-Value). Хеш-таблица, максимальная скорость. Пример: Redis.
  • В России: СУБД Tarantool (VK Group). Используют: Аэрофлот, Т-Банк, Альфа-Банк, Мегафон.
• Колоночные (Column-oriented). Хранение по столбцам, стандарт для OLAP.
  • Пример: ClickHouse (Яндекс). Используют: Яндекс, ВК, Т-Банк, Авито, а в мире — ByteDance, Microsoft, Uber.
• Графовые. Хранение узлов и связей. Пример: Neo4j.
  • Применение: Microsoft, Cisco, PayPal, Сбер (Anti-Fraud).

Кейс: Панамское досье и Neo4j (развернуть)

Одним из ярких примеров использования СУБД Neo4j стало применение в проекте Panama Papers. Панамское досье — это утечка 2,6 ТБ документов (11,5 млн файлов) из Mossack Fonseca. Данные раскрыли схемы офшоров политиков и бизнесменов из 200 стран. Журналисты ICIJ использовали Neo4j для построения интерактивной платформы, позволяющей исследовать связи между людьми и компаниями в реальном времени, что было бы невозможно сделать эффективно с помощью обычных табличных СУБД.

3. NewSQL

Объединение горизонтальной масштабируемости NoSQL и транзакционных гарантий ACID. Примеры: CockroachDB, а в России — YDB (Yandex Database) (используется в Яндексе, ВК, Сбере, Ростелекоме).

Классификация по характеру нагрузки (OLTP и OLAP)

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

Системы транзакционной обработки (OLTP)

On-Line Transaction Processing — ориентированы на оперативную работу.

• Задача: Надежная фиксация состояния в реальном времени.
• Нагрузка: Тысячи коротких транзакций (INSERT, UPDATE, DELETE).
• Пример: Банковский процессинг, биллинг.
• Требования: Строгая нормализация, ACID, минимальное время отклика (Latency).

Системы аналитической обработки (OLAP)

On-Line Analytical Processing — поддержка принятия решений.

• Задача: Анализ истории, тренды, прогнозы.
• Нагрузка: Редкие, но тяжелые запросы на чтение (SELECT) огромных массивов.
• Пример: DWH, бизнес-аналитика.
• Требования: Денормализация, пропускная способность (Throughput). Представители: ClickHouse, Google BigQuery.

Архитектура разделения

В промышленной эксплуатации стандартом является разделение контуров:

1. OLTP принимает нагрузку от пользователей.
2. Данные через ETL выгружаются в OLAP.
3. Аналитики строят отчеты по OLAP, не замедляя боевую систему.

Современные тренды СУБД

Облачная модель потребления (DBaaS)

Переход от On-Premise к Database as a Service. Заказчик не занимается администрированием «железа» и ОС. В России: Yandex Cloud, VK Cloud, SberCloud. Оплата за фактически использованные ресурсы.

Конвергенция и Мультимодельные СУБД

Стирание границ между классами.

• PostgreSQL де-факто стал мультимодельной платформой (поддержка JSONB).
• Интеграция аналитических функций в транзакционные системы (HTAP).

Вывод по первому учебному вопросу

Современная экосистема СУБД — это сложный набор инженерных решений без универсального стандарта. Многообразие моделей (SQL, NoSQL) и нагрузок (OLTP, OLAP) требует от специалиста архитектурного анализа.

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