Каталог базы данных¶

Каталог базы данных — это структурированный набор метаданных, описывающих объекты базы данных (таблицы, представления, индексы, хранимые процедуры, триггеры, типы данных и т. д.), а также правила их хранения, доступа и взаимосвязи. Каталог является системным словарём данных, который обеспечивает целостность, согласованность и возможность администрирования базы данных. В реляционных системах управления базами данных (СУБД) каталог обычно реализуется в виде набора системных таблиц (например, pg_catalog в PostgreSQL, INFORMATION_SCHEMA в SQL-стандарте).

¶История развития

Концепция каталога базы данных возникла вместе с первыми реляционными СУБД в 1970-х годах. В ранних системах (например, System R компании IBM) каталог был отдельной структурой, хранящейся в виде текстовых файлов. С развитием SQL-стандарта в 1980-х годах появилась необходимость стандартизации доступа к метаданным. В 1989 году был опубликован стандарт ISO/IEC 9075 (SQL-89), который ввёл понятие информационной схемы (INFORMATION_SCHEMA) — единого набора представлений для чтения данных каталога.

В 1990-х годах, с распространением объектно-реляционных СУБД (Oracle, IBM DB2), каталоги стали включать не только реляционные объекты, но и пользовательские типы данных, методы и индексы. В современных СУБД (PostgreSQL, MySQL, Microsoft SQL Server) каталог является неотъемлемой частью метаданных, доступной только для чтения привилегированным пользователям.

¶Структура и содержимое каталога

Каталог базы данных содержит иерархически организованные записи. Основные компоненты:

¶Системные таблицы

Системные таблицы хранят информацию обо всех объектах базы данных. Каждая СУБД имеет свои уникальные системные таблицы, но многие элементы следуют SQL-стандарту.

Компонент	Описание	Примеры записей
Таблицы и представления	Имена, владельцы, даты создания, количество строк	`pg_class` (PostgreSQL), `sys.tables` (MSSQL)
Столбцы	Имена, типы данных, допустимость NULL, значения по умолчанию	`pg_attribute`, `sys.columns`
Индексы	Типы (B-tree, хеш, GiST), уникальность, столбцы	`pg_index`, `sys.indexes`
Ограничения (Constraint)	PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK, NOT NULL	`pg_constraint`, `sys.check_constraints`
Хранимые процедуры и функции	Параметры, возвращаемый тип, исходный код	`pg_proc`, `sys.sql_modules`
Пользователи и роли	Имена, права доступа, группы	`pg_user`, `sys.database_principals`

¶Информационная схема (INFORMATION_SCHEMA)

Стандартизированный набор представлений, определённый в SQL (ISO/IEC 9075). Позволяет получать метаданные независимо от конкретной СУБД. Включает такие представления, как:

tables — список таблиц
columns — описание столбцов
table_constraints — ограничения целостности
referential_constraints — внешние ключи
routines — хранимые процедуры и функции

¶Каталоги в нереляционных СУБД

В NoSQL-системах (MongoDB, Cassandra, Redis) каталог может отсутствовать в классическом понимании. Вместо этого используются:

внутренние системные коллекции (MongoDB: system.namespaces);
метаданные, хранимые в распределённых словарях (Cassandra: системное пространство ключей system_schema).

¶Назначение и функции

Каталог базы данных выполняет несколько ключевых задач:

Целостность данных — каталог предотвращает создание дублирующихся имён, нарушение типов и ограничений. Например, попытка создать таблицу с уже существующим именем приводит к ошибке.
Авторизация доступа — проверка прав доступа на объекты базы данных осуществляется через записи каталога. СУБД сравнивает идентификатор пользователя с записями в системных таблицах прав (например, pg_authid в PostgreSQL).
Оптимизация запросов — планировщик запросов использует статистику из каталога (размер таблиц, распределение значений, наличие индексов) для выбора наиболее эффективного плана выполнения.
Администрирование — администраторы базы данных (DBA) используют каталог для мониторинга, аудита и рефакторинга схемы. Утилиты типа pg_dump (PostgreSQL) или mysqldump (MySQL) генерируют скрипты восстановления на основе содержимого каталога.
Совместимость и переносимость — информационная схема позволяет приложениям получать метаданные без привязки к конкретной СУБД, что упрощает миграцию.

¶Управление каталогом

Каталог обычно управляется автоматически СУБД при выполнении операторов DDL (Data Definition Language). Например:

CREATE TABLE — добавляет запись в системные таблицы таблиц и столбцов.
ALTER TABLE — изменяет существующие записи (например, добавляет столбец).
DROP TABLE — удаляет соответствующие записи.

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

¶Примеры реализации

¶PostgreSQL

В PostgreSQL каталог реализуется в схеме pg_catalog. Основные системные таблицы:

pg_class — хранит информацию обо всех объектах, сопоставимых с таблицами (включая индексы, последовательности, представления).
pg_attribute — содержит записи о столбцах.
pg_type — описание типов данных.
pg_namespace — схемы (пространства имён).

Для доступа через информационную схему используется INFORMATION_SCHEMA, доступная в любой базе данных.

¶MySQL

В MySQL каталогом служит служебная база данных mysql, содержащая таблицы:

tables_priv — права доступа на уровне таблиц.
columns_priv — права на уровне столбцов.
procs_priv — права на хранимые процедуры.

Информационная схема представлена как information_schema.

¶Microsoft SQL Server

В MSSQL системные таблицы находятся в схеме sys (например, sys.objects, sys.indexes). Стандартизированные представления доступны через INFORMATION_SCHEMA. Кроме того, существует подсистема sys.dm_* (диспетчерские представления) для мониторинга производительности.

¶Безопасность и ограничения

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

Доступ к каталогу обычно ограничен администраторами и владельцами объектов.
В некоторых СУБД (например, PostgreSQL) чтение системных таблиц требует привилегии SELECT на конкретные таблицы или роль pg_read_all_data.
Атаки типа SQL-injection могут позволить злоумышленнику извлечь данные из каталога (например, названия таблиц и столбцов) для подготовки дальнейшей атаки.

¶Критика

Хотя каталог базы данных является стандартным механизмом управления метаданными, существуют недостатки:

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

¶Интересные факты

В SQL-стандарте каталог определяется как catalog — третий уровень иерархии после кластера и базы данных. Однако на практике (в MySQL, PostgreSQL) каталог часто отождествляется с базой данных.
Системные таблицы PostgreSQL (pg_class, pg_attribute) были разработаны так, чтобы быть совместимыми с объектно-реляционными расширениями (например, поддержка наследования таблиц).
В Oracle Database каталог называется data dictionary и хранится в пространстве имен SYS. Доступ к нему осуществляется через представления DBA_, ALL_ и USER_*.

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

¶Источники

Стандарт ISO/IEC 9075:2023 (SQL:2023)
Документация PostgreSQL 16: Chapter 37. System Catalogs
Документация MySQL 8.0: Chapter 5.3. The mysql System Schema
Документация Microsoft SQL Server: System Catalog Views (Transact-SQL)
Garcia-Molina, H., Ullman, J. D., Widom, J. (2008). Database Systems: The Complete Book (2nd ed.). Pearson.

Заметили ошибку или не согласны с информацией в статье? Напишите нам support@bfometr.ru