Раньше я думал, что схема - это объект «верхней оболочки» перед самой базой данных. Я имею в виду DB.schema.<what_ever_object_name_under_schema>.
Что ж, каталог «обертка» сейчас довольно запутанный. Зачем нужен каталог? С какой именно целью следует использовать каталог?
С реляционной точки зрения:
Каталог - это место, где, помимо прочего, хранятся все различные схемы (внешние, концептуальные, внутренние) и все соответствующие сопоставления (внешние / концептуальные, концептуальные / внутренние).
Другими словами, каталог содержит подробную информацию (иногда называемую дескрипторной информацией или метаданными ) о различных объектах, представляющих интерес для самой системы.
Например, оптимизатор использует информацию каталога об индексах и других физических структурах хранения, а также много другой информации, чтобы помочь ему решить, как реализовать пользовательские запросы. Точно так же подсистема безопасности использует информацию каталога о пользователях и ограничениях безопасности, чтобы в первую очередь разрешить или отклонить такие запросы.
Введение в системы баз данных, 7-е изд., CJ Date, p 69-70.
Каталоги - это именованные коллекции схем в SQL-среде. SQL-среда содержит ноль или более каталогов. Каталог содержит одну или несколько схем, но всегда содержит схему с именем INFORMATION_SCHEMA, которая содержит представления и домены информационной схемы.
Язык баз данных SQL , (Предлагаемый пересмотренный текст DIS 9075), стр. 45
Каталог часто является синонимом базы данных . В большинстве баз данных SQL, если вы запросите представления information_schema, вы обнаружите, что значения в столбце table_catalog сопоставлены с именем базы данных.
Если вы обнаружите, что ваша платформа использует каталог в более широком смысле, чем любое из этих трех определений, это может относиться к чему-то более широкому, чем база данных - кластеру базы данных, серверу или кластеру серверов. Но я как бы сомневаюсь в этом, поскольку вы бы легко нашли это в документации своей платформы.
Майк Шерилл из «Cat Recall» дал отличный ответ . Я просто добавлю один пример: Postgres .
Когда вы устанавливаете Postgres на машину, такая установка называется кластером . «Кластер» здесь не подразумевается в аппаратном смысле, когда несколько компьютеров работают вместе. В Postgres под кластером понимается тот факт, что у вас может быть несколько несвязанных баз данных, работающих и работающих с использованием одного и того же серверного движка Postgres.
Слово « кластер» также определяется стандартом SQL таким же образом, как и в Postgres. Следование стандарту SQL является основной целью проекта Postgres.
В спецификации SQL-92 говорится:
Кластер - это набор каталогов, определяемый реализацией.
а также
Ровно один кластер связан с SQL-сессией
Это тупой способ сказать, что кластер - это сервер базы данных (каждый каталог - это база данных).
Итак, как в Postgres, так и в стандарте SQL у нас есть такая иерархия включения:
Эта диаграмма представляет собой один кластер. В случае с Postgres у вас может быть более одного кластера на хост-компьютер (или виртуальную ОС). Обычно используется несколько кластеров для тестирования и развертывания новых версий Postgres (например: 9.0 , 9.1 , 9.2 , 9.3 , 9.4 , 9.5 ).
Если у вас было несколько кластеров, представьте, что диаграмма выше продублирована.
Разные номера портов позволяют нескольким кластерам работать бок о бок и работать одновременно. Каждому кластеру будет назначен собственный номер порта. Обычное значение 5432является только значением по умолчанию и может быть установлено вами. Каждый кластер прослушивает свой назначенный порт для входящих подключений к базе данных.
Например, в компании могут быть две разные группы разработки программного обеспечения. Одна пишет программное обеспечение для управления складами, а другая команда создает программное обеспечение для управления продажами и маркетингом. Каждая команда разработчиков имеет свою собственную базу данных, не подозревая о чужой.
Но группа ИТ-операций приняла решение запускать обе базы данных на одном компьютере (Linux, Mac и т. Д.). Итак, на этот ящик они установили Postgres. Итак, один сервер базы данных (кластер базы данных). В этом кластере они создают два каталога, каталог для каждой команды разработчиков: один с именем «склад» и один с именем «продажи».
Каждая команда разработчиков использует множество десятков таблиц с разными целями и ролями доступа. Таким образом, каждая команда разработчиков объединяет свои таблицы в схемы. По совпадению, обе группы разработчиков отслеживают данные бухгалтерского учета, поэтому у каждой команды есть схема под названием «учет». Использование одного и того же имени схемы не является проблемой, потому что каждый каталог имеет собственное пространство имен, поэтому конфликтов нет.
Кроме того, каждая команда в конечном итоге создает таблицу для бухгалтерских целей, называемую «бухгалтерская книга». Опять же, никаких конфликтов имен.
Вы можете представить этот пример как иерархию…
Postgres 9.2 кластер (установка)
warehouse каталог (база данных)
inventory схема
accounting схема
ledger Таблицаsales каталог (база данных)
selling схема
accounting схема (совпадение с тем же именем, что и выше)
ledger таблица (совпадение с тем же именем, что и выше)Postgres 9.3 кластер
Программное обеспечение каждой группы разработчиков подключается к кластеру. При этом они должны указать, какой каталог (база данных) принадлежит им. Postgres требует, чтобы вы подключились к одному каталогу, но вы не ограничены этим каталогом. Этот исходный каталог является просто каталогом по умолчанию, который используется, когда в ваших операторах SQL отсутствует имя каталога.
Поэтому, если команде разработчиков когда-либо понадобится доступ к таблицам другой команды, они могут это сделать, если администратор базы данных предоставил им для этого права . Доступ осуществляется с явным именованием в шаблоне: catalog.schema.table . Поэтому, если «складской» команде нужно увидеть бухгалтерскую книгу другой команды («отдел продаж»), они пишут операторы SQL с помощью sales.accounting.ledger. Чтобы получить доступ к своей бухгалтерской книге, они просто пишут accounting.ledger. Если они обращаются к обеим бухгалтерским книгам в одном и том же фрагменте исходного кода, они могут выбрать, чтобы избежать путаницы, указав свое собственное (необязательное) имя каталога warehouse.accounting.ledgerвместо sales.accounting.ledger.
Кстати…
Вы можете слышать, что слово « схема» используется в более общем смысле, означающем весь дизайн структуры таблицы конкретной базы данных. Напротив, в стандарте SQL это слово означает конкретно конкретный уровень в Cluster > Catalog > Schema > Tableиерархии.
Postgres использует как базу данных слов, так и каталог в различных местах, например, в команде CREATE DATABASE .
Не все системы баз данных обеспечивают эту полную иерархию Cluster > Catalog > Schema > Table. Некоторые имеют только один каталог (базу данных). У некоторых нет схемы, только один набор таблиц. Postgres - исключительно мощный продукт.
...Catalog > Schema..., то может ли кто-нибудь сказать мне, почему узлы «Каталог» и «Схема» в pgAdmin (пользовательский интерфейс PostgreSQL) являются узлами-родственниками, а не узлом схемы в качестве дочернего узла каталога?PostgreSQL (pg_catalog), системный каталог, десятки «PG_» таблица , в которых хранятся определение метаданных из баз данных, такие какpg_index,pg_triggerиpg_constraint. (2)ANSI (information_schema), доступное только для чтения представление того же системного каталога, определенного стандартом SQL какinformation_schema. Лучшим названием для узла «Каталоги» в pgAdmin может быть «Система» или «Системные таблицы».