Раніше я вважав, що схема є об'єктом "верхньої обгортки" перед самою базою даних. Я маю на увазі DB.schema.<what_ever_object_name_under_schema>.

Що ж, каталог «обгортка» зараз досить заплутаний. Для чого нам потрібен каталог? З якою метою саме слід використовувати каталог?

З реляційної точки зору:

Каталог - це місце, де - серед іншого - зберігаються всі різні схеми (зовнішня, концептуальна, внутрішня) та всі відповідні відображення (зовнішні / концептуальні, концептуальні / внутрішні).

Іншими словами, каталог містить детальну інформацію (яку іноді називають дескриптором або метаданими ) щодо різних об’єктів, які представляють інтерес для самої системи.

Наприклад, оптимізатор використовує інформацію про каталог про індекси та інші фізичні структури зберігання, а також багато іншої інформації, щоб допомогти йому вирішити, як реалізувати запити користувачів. Так само підсистема безпеки використовує каталогічну інформацію про користувачів та обмеження безпеки для надання або відхилення таких запитів в першу чергу.

Вступ до систем баз даних, 7-е видання, CJ Date, p 69-70.

Каталоги називаються колекціями схем у SQL-середовищі. SQL-середовище містить нуль або більше каталогів. Каталог містить одну або кілька схем, але завжди містить схему з назвою INFORMATION_SCHEMA, яка містить подання та домени Інформаційної схеми.

Мова баз даних SQL , (Пропонований доопрацьований текст DIS 9075), стор

Каталог часто є синонімом бази даних . У більшості баз даних SQL, якщо ви запитуєте подання information_schema, ви знайдете, що значення в стовпці "table_catalog" відображаються до імені бази даних.

Якщо ви знайдете свою платформу з використанням каталогу ширшим способом, ніж будь-яке з цих трьох визначень, це може посилатися на щось ширше, ніж база даних - кластер бази даних, сервер або кластер сервера. Але я сумніваюся в цьому, оскільки ви це легко знайшли в документації на свою платформу.

Майк Шеррілл "Відкликання кота" дав чудову відповідь . Додам просто один приклад: Postgres .

Кластер = встановлення Postgres

Коли ви встановлюєте Postgres на машині, це встановлення називається кластером . "Кластер" тут не мається на увазі в апаратному розумінні декількох комп'ютерів, що працюють разом. У Postgres кластер посилається на той факт, що ви можете мати кілька не пов'язаних між собою баз даних, що працюють, використовуючи один і той же серверний механізм Postgres.

Кластер слів також визначається стандартом SQL так само, як і в Postgres. Пильне дотримання стандарту SQL є головною метою проекту Postgres.

Специфікація SQL-92 говорить:

Кластер - це визначена реалізацією колекція каталогів.

і

Рівно один кластер пов'язаний з SQL-сеансом

Це точний спосіб сказати, що кластер - це сервер баз даних (кожен каталог - це база даних).

Кластер> Каталог> Схема> Таблиця> Стовпці та рядки

Отже, і в Postgres, і в SQL Standard ми маємо цю ієрархію стримування:

• Комп’ютер може мати один кластер або кілька.
• Сервер бази даних - це кластер .
• Кластер має каталоги . (Каталог = База даних)
• Каталоги мають схеми . (Схема = простір імен таблиць та межа безпеки)
• Схеми мають таблиці .
• Столи мають рядки .
• Рядки мають значення , визначені стовпцями .
  Ці цінності - це бізнес-дані, про які ваші програми та користувачі дбають, такі як ім’я людини, термін платежу-фактури, ціна товару, висока оцінка гравця. Стовпець визначає тип даних значень (текст, дата, число тощо).

Кілька кластерів

Ця діаграма являє собою єдиний кластер. У випадку 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 - надзвичайно потужний продукт.