Модель данных (Data Model) — это формализованное абстрактное описание структуры данных, принципов их логической организации, допустимых ограничений целостности и набора базовых операций манипулирования, поддерживаемых соответствующей системой управления базами данных (СУБД).
В классической теории баз данных любая модель данных включает в себя три неотъемлемых компонента:
Чтобы понять различия между архитектурами, рассмотрим способ представления одной и той же сущностной задачи («Студент обучается на Факультете и записан на Курсы») в четырех фундаментальных представлениях.
+-----------------------------------------------------+
| ФАКУЛЬТЕТ (Root) |
| id: 101, name: "ИСиП" |
+-----------------------------------------------------+
|
+-----------+-----------+
| 1:N | 1:N
v v
+---------------------------+ +---------------------------+
| ГРУППА (Child 1) | | КАФЕДРА (Child 2) |
| id: 11, code: "ИС-22" | | id: 401, name: "Прогр" |
+---------------------------+ +---------------------------+
|
| 1:N
v
+---------------------------+
| СТУДЕНТ (Leaf) | * Ограничение: каждый дочерний узел
| id: 501, name: "Иванов" | имеет СТРОГО одного предка (Parent).
+---------------------------+ * Связь M:N требует дублирования ветвей!
+----------------------+ +----------------------+
| ФАКУЛЬТЕТ (Owner 1) | | КУРС (Owner 2) |
| id: 101, name: ИТ | | id: C1, title: СУБД |
+----------------------+ +----------------------+
| |
| Set: "Факультет-Студенты" | Set: "Курс-Записи"
v v
+------------------------------------------------------------+
| СТУДЕНТ (Member) |
| id: 501, name: "Иванов" |
| [Next_in_Fac_ptr] ------> [Next_in_Course_ptr] |
+------------------------------------------------------------+
^ ^
| Навигация по указателям | Допускаются множественные
+--------------------------------------+ родители разных типов
ТАБЛИЦА: faculties ТАБЛИЦА: courses
+----+-------------+ +----+-------------+
| id | name | | id | title |
+----+-------------+ +----+-------------+
| 1 | Информатика | | 7 | Базы данных |
+----+-------------+ +----+-------------+
^ ^
| FK (1:N) | FK (1:N)
ТАБЛИЦА: students ТАБЛИЦА: student_courses (M:N junction)
+----+---------+------------+ +------------+-----------+
| id | name | faculty_id | | student_id | course_id |
+----+---------+------------+ +------------+-----------+
| 55 | Иванов | 1 |----------->| 55 | 7 |
+----+---------+------------+ (FK) +------------+-----------+
{
"_id": "student_55",
"name": "Иванов Иван",
"faculty": {
"id": 1,
"name": "Информатика и программирование"
},
"contacts": {
"email": "ivanov@college.ru",
"phone": "+7-999-123-4567"
},
"enrolled_courses": [
{ "course_id": 7, "title": "Базы данных", "grade": 5 },
{ "course_id": 12, "title": "Архитектура ЭВМ", "grade": 4 }
],
"skills": ["SQL", "Linux", "Python", "Git"]
}
В 1970 году доктор Эдгар Кодд математически сформулировал принципы реляционной модели данных (РМД), основанной на n-арных отношениях и предикатах. Главным достижением стало абсолютное разделение логической структуры данных от их физического размещения на жестких дисках.
| № | Название правила | Суть и инженерное значение |
|---|---|---|
| 0 | Фундаментальное правило | СУБД должна управлять базой данных исключительно посредством своих реляционных возможностей. |
| 1 | Информационное правило | Вся информация логически хранится только в виде табличных значений. |
| 2 | Гарантированный доступ | Каждая ячейка доступна по связке: Имя Таблицы + Первичный Ключ + Имя Столбца. |
| 3 | Систематическая обработка NULL | Поддержка отсутствующих или неприменимых данных на уровне ядра СУБД. |
| 4 | Динамический реляционный каталог | Метаданные (схема БД) доступны через такие же SQL-запросы к системным таблицам. |
| 8 | Физическая независимость | Смена B-Tree на хэш или изменение размера дискового сектора не ломает SQL-запросы. |
| 9 | Логическая независимость | Разбиение одной таблицы на две не ломает программы при создании покрывающих View. |
| 10 | Независимость целостности | Ограничения CHECK, UNIQUE, FOREIGN KEY контролирует СУБД, а не код клиентского приложения. |
Современная архитектурная парадигма — Polyglot Persistence (многоязычное хранение): в крупной информационной системе разные задачи решаются разными специализированными СУБД.
| Критерий сравнения | Реляционная (SQL) | Документная (NoSQL) | Графовая (NoSQL) | Колоночная (NoSQL) | Ключ-значение (NoSQL) |
|---|---|---|---|---|---|
| Базовая структура | Связанные таблицы | Иерархические документы JSON/BSON | Вершины, ребра, свойства | Семейства колонок, хранение по столбцам | Хеш-таблица (Key-Value) |
| Схема данных | Жесткая (Schema-on-write) | Гибкая (Schema-on-read) | Гибкая схема графа | Секционная с гибкими колонками | Бессхемная (строка/бинарник) |
| Язык запросов | SQL | MQL, JSON-запросы | Cypher, Gremlin | CQL, SQL-диалекты | Простые команды GET/SET |
| Связи и объединения | JOIN на стороне СУБД | Вложенность либо агрегации | Нативные ребра (без JOIN) | Денормализация, без JOIN | Отсутствуют |
| Транзакции | Строгий ACID | Внутри документа (ACID), BASE | ACID (Neo4j) | BASE / Настраиваемый уровень | Атомарность по ключу |
| Типичные СУБД | PostgreSQL, MySQL, Oracle | MongoDB, Couchbase | Neo4j, Memgraph | ClickHouse, Cassandra | Redis, Memcached, KeyDB |
В распределенных системах действует CAP-теорема Эрика Брюэра: из трех свойств — Согласованность (Consistency), Доступность (Availability) и Устойчивость к сетевому разделению (Partition tolerance) — распределенная система способна одновременно гарантировать только два.