Содержание
Схема базы данных — это коллекция метаданных, которая описывает отношения между объектами и информацией в базе данных. Простой способ представить схему — это представить ее как блок, содержащий таблицы, хранимые процедуры, представления и связанные активы данных. Схема определяет инфраструктуру этого блока.
Определение схемы базы данных
На самом базовом уровне схема служит контейнером для активов данных. Однако разные поставщики баз данных используют схемы по-разному. Oracle, например, рассматривает каждую схему как учетную запись пользователя. Чтобы создать новую схему, администратор базы данных создает нового пользователя базы данных с намеченным именем схемы.
Схема не совпадает с моделью данных.
Почему схемы имеют значение
Поскольку схемы составляют базовую структурную особенность базы данных, большинство сред баз данных применяют права доступа к объектам на уровне схемы.
Например, база данных компании может содержать ряд пользователей. Каждый пользователь использует схему, но доступ к различным схемам предоставляется индивидуально и с детализированными разрешениями пользователям за пределами домашней схемы.
Большинство инструментов управления базами данных не перечисляют схемы; вместо этого они перечисляют базы данных и пользователей.
Например, компания создает учетные записи пользователей (схемы) для Боба и Джейн. Он также создает учетные записи для таких отделов, как отдел кадров и маркетинг. Затем он предоставляет аналитику в каждом отделе доступ к учетной записи схемы отдела.
HR-аналитик создает таблицы и представления в схеме HR и предоставляет Бобу доступ для чтения (но не записи) таблицы, в которой перечислены имена сотрудников и идентификационные номера сотрудников. Кроме того, аналитик отдела кадров может предоставить Джейн доступ для чтения и записи в таблицу, в которой перечислены телефонные номера сотрудников.
Предоставляя доступ таким образом, только нужные роли и пользователи могут читать, записывать или изменять данные в автономном ресурсе данных в более крупной базе данных.
Каждый механизм базы данных рассматривает схемы как основополагающий метод разделения данных в многопользовательской среде.
Различные движки баз данных по-разному обрабатывают пользователей и схемы. Обратитесь к документации, относящейся к вашему ядру базы данных, чтобы узнать конкретные синтаксические и логические модели, окружающие пользователей, схемы и разрешения.
Создание схем
Схема формально определяется с использованием языка структурированных запросов. Например, в Oracle вы создаете схему, создавая учетную запись пользователя, которой она принадлежит:
СОЗДАТЬ ПОЛЬЗОВАТЕЛЯ Боб
ИДЕНТИФИЦИРОВАНО временным паролем
Пример DEFAULT TABLESPACE
QUOTA 10M ON пример
TEMPORARY TABLESPACE temp
QUOTA 5M ON система
ПРОФИЛЬ app_user
ПАРОЛЬ EXPIRE;
Другим пользователям предоставляется доступ к новым схемам в силу их имени пользователя или одной или нескольких ролей, к которым добавлена учетная запись пользователя.
Схемы против моделей данных
Схема не имеет внутренней структуры, чтобы что-либо делать; вместо этого это инфраструктура для поддержки сегментации разрешений в базе данных. Однако термины схема и модель данных используются взаимозаменяемо.
Использование схемы для ссылки на конкретную коллекцию таблиц и представлений, связанных между собой определенными отношениями, сбивает с толку, но не неправильно. Подход «схема как архитектура», описанный в этой статье, представляет собой версию схемы с заглавной буквы S. Отношения схемы-данных-это строчная-S версия — синоним. Многие справочные сайты в Интернете стирают это существенное различие.
Модель данных — это набор таблиц и представлений, объединенных по определенным ключам. Эти активы данных вместе служат бизнес-цели. Вполне приемлемо применять модель данных к схеме — фактически, для больших и сложных моделей данных их сопоставление со схемами делает возможным интеллектуальное администрирование базы данных. Но логически необязательно использовать схему для модели данных или рассматривать модель данных как схему.
Например, отдел кадров может включить в свою схему модель данных для анализа эффективности работы сотрудников. Вместо создания схемы для этих проверок, модель данных может находиться в схеме HR (вместе с другими моделями данных) и оставаться логически отличной через префиксы таблицы и имена представлений для объектов в модели данных.
Модель данных может получить неофициальное имя, например, обзоры производительности, а затем все таблицы и представления могут иметь префикс pr_. Список сотрудников может быть указан как hr.pr_employee не требуя новой схемы для обзоров производительности.
