Перейти к основному содержимому

Эволюция систем хранения данных

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Разработчику Аналитику Архитектору

История моделей данных - от иерархии к реляционной​

Понимание эволюции хранения данных объясняет, почему в SQL есть таблицы, ограничения целостности и декларативные запросы, а не только "как написать SELECT". Материал основан на учебном плане "Введение в системы хранения данных".

Физические уровни storage (кэш, RAM, диски, SAN, облако) — в шпаргалке Современные системы хранения данных. Ниже — логические модели данных и история их появления.

Эволюция моделей хранения​

Файловые системы​

Данные хранятся в отдельных файлах приложения. Типичные проблемы:

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

Иерархические и сетевые модели​

Данные организованы как дерево (иерархия) или граф (сеть). Запросы привязаны к физической навигации по связям. Недостатки:

  • жёсткая структура — изменение схемы дорого;
  • сложные запросы "в обход" дерева трудоёмки.

Реляционная модель (Кодд, 1970)​

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

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

Ключи, типы связей (1:1, 1:N, M:N), внешние ключи и обзор JOIN — в Реляционной модели данных; проектирование схемы от ER до DDL — Проектирование баз данных.

Современный контекст​

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

Базовая терминология​

ТерминОпределение
ДанныеФакты в формализованном виде, пригодные для обработки
МетаданныеСведения о структуре: таблицы, типы, ограничения, права
Схема базы данныхОписание логической структуры на момент проектирования
Экземпляр базы данныхФактическое состояние данных в конкретный момент времени

Схема задаёт "каркас"; экземпляр — текущее наполнение таблиц.

Классификация СУБД​

По модели данных: реляционные (PostgreSQL), документные (MongoDB), ключ-значение (Redis), графовые (Neo4j), колоночные (ClickHouse).

По архитектуре: встроенные (SQLite), клиент-серверные (PostgreSQL), распределённые кластеры.

По лицензированию: открытые (PostgreSQL), коммерческие (Oracle Database), гибридные (MySQL с коммерческой поддержкой).

Первое подключение к PostgreSQL​

Проверка работоспособности сервера и клиента:

SELECT version();

Просмотр пользовательских баз на сервере:

SELECT datname
FROM pg_database
WHERE datistemplate = false
ORDER BY datname;

Список таблиц через стандартный каталог (подробнее — в статье Словарь данных и системные каталоги):

SELECT table_schema, table_name
FROM information_schema.tables
WHERE table_schema NOT IN ('pg_catalog', 'information_schema')
ORDER BY table_schema, table_name;

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

  1. В чём принципиальное отличие реляционной модели от файлового хранения?
  2. Как соотносятся понятия "схема" и "экземпляр" базы данных?
  3. Почему клиент-серверная архитектура стала стандартом для корпоративных СУБД?
  4. Какую роль играют метаданные в обеспечении целостности данных?

См. также​

Содержание