Типы моделей данных

Принцип организации

Данные представляются в виде дерева сегментов. На верхнем уровне расположен единственный корневой сегмент (Root). Каждый подчиненный сегмент (Child) может иметь строго одного родителя (Parent).

Пример: Каталог файловой системы (Диск → Папка → Файл) или организационная структура предприятия.

Критические ограничения

• Проблема M:N: Отношение «многие-ко-многим» (Студент ↔ Курсы) невозможно без грубого дублирования ветвей дерева.
• Аномалия удаления: Удаление узла-родителя автоматически влечет за собой безвозвратное уничтожение всех связанных дочерних данных.
• Сложность реорганизации: Любое изменение бизнес-иерархии требует полного перестроения физической базы.

Архитектурная схема

Узлы сети представляют собой типы записей, а ребра — именованные наборы связей (Sets). Дочерняя запись-член (Member) может входить одновременно в несколько наборов разных типов записей-владельцев (Owner).

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

Слабое место: навигационный доступ

Запросы к сетевой базе требовали от программиста явного императивного обхода структуры с помощью физических курсоров:

FIND FIRST Student WITHIN Faculty-Students.
WHILE DB-STATUS = 0 DO
    GET Student;
    FIND NEXT Student WITHIN Faculty-Students;
END-WHILE;

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

Математический фундамент

База данных состоит из нормализованных отношений (Relations) — математических подмножеств декартова произведения доменов. На физическом уровне они воспринимаются пользователем как простые двумерные таблицы.

Строка таблицы называется кортежем (Tuple), столбец — атрибутом (Attribute), диапазон допустимых значений — доменом (Domain).

Декларативный принцип SQL

Разработчик описывает что именно нужно получить, а СУБД сама решает, как оптимально это вычислить:

SELECT s.name, c.title
FROM students s
JOIN enrollments e ON s.id = e.student_id
JOIN courses c ON e.course_id = c.id
WHERE s.course_year = 2;

Оптимизатор запросов СУБД строит план выполнения с учетом дисковых B-Tree индексов.

Правила независимости (8 и 9)

Физическая независимость: Перенос файлов с HDD на SSD, изменение размера блока или смена структуры индексов не требует переписывания ни единой строчки прикладного SQL-кода.

Логическая независимость: Добавление столбцов или декомпозиция таблиц не нарушают работу существующих программ при условии создания представлений (View).

Правила доступа и целостности (2 и 10)

Гарантированный доступ: Каждое атомарное значение адресуется тройкой: (Имя Таблицы, Первичный Ключ, Имя Столбца).

Независимость целостности: Правила валидации (PRIMARY KEY, FOREIGN KEY, CHECK) хранятся в реляционном каталоге СУБД, а не рассеяны по коду клиентских приложений.

Суть и особенности

Данные хранятся в виде самоописываемых иерархических документов (BSON/JSON), сгруппированных в коллекции. Поддерживается гибкая схема (Schema-on-read): разные документы одной коллекции могут иметь разный набор атрибутов.

Типичные СУБД: MongoDB, Couchbase, Amazon DocumentDB.

Пример документа в MongoDB

{
  "_id": ObjectId("651e0f..."),
  "item_code": "LAP-X1",
  "category": "Электроника",
  "price": 89990.00,
  "specs": {
    "ram_gb": 16,
    "cpu": "Intel Core i7",
    "ssd_gb": 1024
  },
  "tags": ["учеба", "разработка", "4k"]
}

Концепция Property Graph

Модель состоит из трех базовых примитивов:

• Вершины (Nodes): сущности реального мира с набором меток (Labels).
• Ребра (Relationships): направленные типизированные связи между узлами.
• Свойства (Properties): пары ключ-значение у узлов и связей.

Типичные СУБД: Neo4j, Memgraph, Amazon Neptune.

Безындексная смежность (Index-free adjacency)

Каждый узел физически хранит прямые указатели на соседние связанные узлы в оперативной памяти. Сложность обхода связей составляет O(1) на один шаг.

В реляционной СУБД запрос «друзья друзей до 4 уровня» требует каскада тяжелых JOIN с резким падением скорости; в графовой СУБД он выполняется за миллисекунды.

Строчное vs Колоночное хранение

Строчные СУБД (PostgreSQL, OLTP): строка хранится целиком на дисковой странице. Идеально для вставки и точечного чтения единичных записей по ключу.

Колоночные СУБД (ClickHouse, OLAP): каждый столбец пишется в отдельный файл. Однотипные данные сжимаются алгоритмами LZ4/ZSTD в 5–10 раз.

Почему ClickHouse выигрывает в аналитике?

При запросе агрегации SELECT event_type, count(*) FROM clickstream GROUP BY event_type колоночная СУБД считывает с диска только один столбец event_type, полностью игнорируя остальные 50 столбцов таблицы.

Результат: сканирование сотен миллионов событий за доли секунды.

Принцип ассоциативного массива

Данные хранятся в виде пар Key → Value. Доступ возможен исключительно по известному ключу через хэш-таблицу. СУБД хранит весь набор данных в оперативной памяти (In-Memory) с асинхронным сбросом на диск (RDB/AOF).

Типичные СУБД: Redis, KeyDB, Memcached.

Сценарии применения в архитектуре

• Кэширование результатов тяжелых SQL-запросов (снижение нагрузки на PostgreSQL).
• Хранение пользовательских HTTP-сессий и токенов авторизации (JWT / Redis Sessions).
• Счетчики кликов, лайков и просмотров в реальном времени (команда INCR).
• Лидерборды и очереди задач (структуры данных Sorted Sets, Lists, Streams).

Выбирайте реляционную модель (PostgreSQL)

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

Выбирайте документную модель (MongoDB)

• Каталоги товаров с сильно различающимися атрибутами (электроника, одежда).
• Быстро меняющиеся требования к структуре и прототипирование стартапов.
• Агрегация в единый JSON для мобильных и веб-приложений.

Выбирайте графовую модель (Neo4j)

• Социальные графы, анализ взаимодействий и цепочек рекомендаций.
• Антифрод-мониторинг подозрительных переводов по кольцевым схемам счетов.
• Поиск кратчайших логистических маршрутов и зависимостей в сетях.

Выбирайте колоночную модель (ClickHouse)

• Сбор сырых логов, кликстрима, метрик посещаемости и телеметрии IoT.
• Аналитические дашборды (OLAP) с агрегациями по миллиардам строк.
• Поток событий пишется только на вставку (Append-only), без точечных UPDATE.