Что такое схема в sql

Схема базы данных

Схема базы данных включает в себя описания содержания, структуры и ограничений целостности, используемые для создания и поддержки базы данных [1] .

Постоянные данные в среде базы данных включают в себя схему и базу данных. Система управления данными использует определения данных в схеме для обеспечения доступа и управления доступом к данным в базе данных [1] .

Схема как структура базы данных

Схема базы данных MediaWiki

Схема системы базы данных (от англ. Database schema) — её структура, описанная на формальном языке, поддерживаемом системой управления базами данных (СУБД). В реляционных базах данных схема определяет таблицы, поля в каждой таблице, а также отношения между полями и таблицами.

Схемы в общем случае хранятся в словаре данных. Хотя схема определена на языке базы данных в виде текста, термин часто используется для обозначения графического представления структуры базы данных. [2]

Основными объектами схемы являются таблицы и связи.

Схема как объект базы данных

Есть и другое понятие схемы в теории баз данных.

Схема (SCHEMA) [3] — является одним из основных объектов базы данных Oracle. Близкое понятие (RIS Schema) существует в RIS-интерфейсе доступа к базам данных. SCHEMA также появилась и в Microsoft SQL Server 2005 и формально определяется как набор объектов в базе данных [4] .

В Oracle она привязывается только к одному пользователю (USER) и является логическим набором объектов базы данных. Схема создается при создании пользователем первого объекта, и все последующие объекты созданные этим пользователем становятся частью этой схемы.

Она может включать другие объекты, принадлежащие этому пользователю:

• таблицы,
• последовательности,
• хранимые программы,
• кластеры,
• связи баз данных,
• триггеры,
• библиотеки внешних процедур,
• индексы,
• пакеты,
• хранимые функции и процедуры,
• синонимы,
• представления,
• снимки,
• объектные таблицы,
• объектные типы,
• объектные представления.

Существуют и подобъекты схемы, такие как:

• столбцы: таблиц и представлений,
• секции таблиц,
• ограничения целостности,
• триггеры,
• пакетные процедуры и функции и другие элементы, хранимые в пакетах (курсоры, типы и т. п).

Существуют объекты не зависимые от схемы

• каталоги,
• профили,
• роли,
• сегменты,
• табличные области
• пользователи.

Уровни схемы базы данных

• Концептуальная схема — карта концепций и их связей
• Логическая схема — карта сущностей и их атрибутов и связей
• Физическая схема — частичная реализация логической схемы
• Схема объекта — объект БД Oracle

Примечания

1. ↑ 12 ГОСТ Р ИСО МЭК ТО 10032-2007: Эталонная модель управления данными (идентичен ISO/IEC TR 10032:2003 Information technology — Reference model of data management)
2. ↑What is schema? — A Word Definition From the Webopedia Computer Dictionary
3. ↑Основные объекты Oracle — Книги по базам данных
4. ↑Схемы баз данных SQL Server 2005, разделение пользователей и схем — AskIt.RU

См. также

• Моделирование данных

• Моделирование данных
• Базы данных
• Теоретические основы баз данных

Схема базы данных (SQL) — что это такое (+ схема таблицы)

Схема БД (базы данных) — это набор всех схем её таблиц, т.е. описание всех колонок этих таблиц (их типов, допустимых значений, связей между таблицами типа внешних ключей, индексов и т.д.), без учета конкретных данных, записанных в таблицы БД.

Т.е. всё что задаёт таблицы, но не задаёт данные в них — это схема.

Как описывается (задаётся) схема БД

В реляционных СУБД схема обычно описывается с помощью набора SQL команд создания таблиц (типа CREATE TABLE), а также, возможно, модифицирующих запросов (типа ALTER TABLE), меняющих схему таблиц после того, как выполнены запросы на их создание.

Key Words for FKN + antitotal forum (CS VSU):

• схема базы данных
• схема бд
• схема таблицы
• что это такое

Владение и разделение пользователей и схем в SQL Server

Основным принципом безопасности SQL Server является то, что владельцы объектов имеют неотзываемые разрешения на их администрирование. Нельзя удалять права доступа у владельцев объектов. Также нельзя удалять пользователей из базы данных, если они владеют в ней объектами.

Разделение схемы пользователей

Отделение пользователей от схем обеспечивает дополнительную гибкость в управлении разрешениями объектов базы данных. Схема представляет собой именованный контейнер для объектов базы данных, позволяющий группировать объекты по отдельным пространствам имен. Например, образец базы данных AdventureWorks содержит схемы для Production, Sales и HumanResources.

Четырехкомпонентный синтаксис ссылок на объекты указывает имя схемы.

Server.Database.DatabaseSchema.DatabaseObject 

Владельцы схем и разрешения

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

По умолчанию, если разработчик создает объект в схеме, он принадлежит участнику безопасности, являющемуся владельцем схемы, а не разработчику. Владение объектом можно передать с помощью инструкции Transact-SQL ALTER AUTHORIZATION. Схема может также содержать объекты, принадлежащие другим пользователям и иметь более детализированные разрешения, чем назначенные схеме, хотя это не рекомендуется из-за увеличения сложности управления разрешениями. Объекты можно перемещать из одной схемы в другую, а принадлежность схемы передавать от одного участника другому. Пользователей базы данных можно удалять, не влияя этим на схемы.

Встроенные схемы для обратной совместимости

В состав SQL Server входят девять предварительно определенных схем, имена которых совпадают с именами встроенных пользователей и ролей базы данных: db_accessadmin, db_backupoperator, db_datareader, db_datawriter, db_ddladmin, db_denydatareader, db_denydatawriter, db_owner, db_securityadmin. Они существуют ради обратной совместимости. Рекомендуется не использовать их для объектов-пользователей. Схемы, имеющие те же имена, что и предопределенные роли базы данных, можно удалить, если они еще не используются. В этом случае команда drop просто возвратит ошибку и заблокирует удаление используемой схемы.

IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_accessadmin') DROP SCHEMA [db_accessadmin] GO IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_backupoperator') DROP SCHEMA [db_backupoperator] GO IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_datareader') DROP SCHEMA [db_datareader] GO IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_datawriter') DROP SCHEMA [db_datawriter] GO IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_ddladmin') DROP SCHEMA [db_ddladmin] GO IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_denydatareader') DROP SCHEMA [db_denydatareader] GO IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_denydatawriter') DROP SCHEMA [db_denydatawriter] GO IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_owner') DROP SCHEMA [db_owner] GO IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_securityadmin') DROP SCHEMA [db_securityadmin] GO 

Если эти схемы удалить из шаблона базы данных, они не появятся в новых базах данных. Схемы, содержащие объекты, не могут быть удалены.

Невозможно удалить следующие схемы:

Схемы sys и INFORMATION_SCHEMA зарезервированы для системных объектов. В этих схемах нельзя создавать и удалять объекты.

Схема dbo

Схема dbo является схемой по умолчанию для каждой базы данных. Схемой по умолчанию для пользователей, созданных с помощью команды Transact-SQL CREATE USER, является dbo . Владельцем схемы dbo является учетная запись пользователя dbo .

Пользователи, которым назначена схема dbo как схема по умолчанию, не наследуют разрешения учетной записи пользователя dbo . Пользователи не наследуют разрешения схемы, их наследуют объекты базы данных, содержащиеся в схеме. Схема по умолчанию для пользователя используется исключительно для ссылки на объект в том случае, если пользователь опускает схему при выполнении запросов к объектам.

Если на объект базы данных ссылаются с помощью однокомпонентного имени, SQL Server вначале ищет этот объект в схеме пользователя по умолчанию. Если объект не найден, SQL Server ищет его в схеме dbo . Если этот объект не найден в схеме dbo , возвращается ошибка.

Внешние ресурсы

Дополнительные сведения о принадлежности объектов и схемах см. в следующих документах.

Ресурс	Description
Отделение пользователей от схем	Описывает изменения, возникшие из-за отделения пользователей от схем. Сюда входит новое поведение, его влияние на владение, представления каталогов и разрешения.

См. также

• Защита интеллектуальной собственности SQL Server
• Приступая к работе с разрешениями Database Engine
• Роли уровня сервера
• Защита приложений ADO.NET

Что такое схема в sql

Кластер баз данных Postgres Pro содержит один или несколько именованных экземпляров баз. На уровне кластера создаются пользователи и группы, но данные могут относиться только к базам данных. При этом в рамках одного подключения к серверу можно обращаться к данным только одной базы данных, указанной при установлении соединения.

Примечание

Пользователи кластера не обязательно будут иметь доступ ко всем базам данных этого кластера. То, что пользователи создаются на уровне кластера, означает только, что в нём не может быть двух пользователей joe в разных базах данных, хотя система позволяет ограничить доступ joe только некоторыми базами данных.

База данных содержит одну или несколько именованных схем, которые в свою очередь содержат таблицы. Схемы также содержат именованные объекты других видов, включая типы данных, функции и операторы. Одно и то же имя объекта можно свободно использовать в разных схемах, например и schema1 , и myschema могут содержать таблицы с именем mytable . В отличие от баз данных, схемы не ограничивают доступ к данным: пользователь может обращаться к объектам в любой схеме текущей базы данных, если ему назначены соответствующие права.

Есть несколько возможных объяснений, для чего стоит применять схемы:

Чтобы одну базу данных могли использовать несколько пользователей, независимо друг от друга.

Чтобы объединить объекты базы данных в логические группы для облегчения управления ими.

Схемы в некоторым смысле подобны каталогам в операционной системе, но они не могут быть вложенными.

5.8.1. Создание схемы

Для создания схемы используется команда CREATE SCHEMA . При этом вы определяете имя схемы по своему выбору, например так:

CREATE SCHEMA myschema;

Чтобы создать объекты в схеме или обратиться к ним, указывайте полное имя, состоящее из имён схемы и объекта, разделённых точкой:

схема.таблица 

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

Есть ещё более общий синтаксис

база_данных.схема.таблица 

но в настоящее время он поддерживается только для формального соответствия стандарту SQL. Если вы указываете базу данных, это может быть только база данных, к которой вы подключены.

Таким образом, создать таблицу в новой схеме можно так:

CREATE TABLE myschema.mytable ( . );

Чтобы удалить пустую схему (не содержащую объектов), выполните:

DROP SCHEMA myschema;

Удалить схему со всеми содержащимися в ней объектами можно так:

DROP SCHEMA myschema CASCADE;

Стоящий за этим общий механизм описан в Разделе 5.13.

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

CREATE SCHEMA имя_схемы AUTHORIZATION имя_пользователя;

Вы даже можете опустить имя схемы, в этом случае именем схемы станет имя пользователя. Как это можно применять, описано в Подразделе 5.8.6.

Схемы с именами, начинающимися с pg_ , являются системными; пользователям не разрешено использовать такие имена.

5.8.2. Схема public

До этого мы создавали таблицы, не указывая никакие имена схем. По умолчанию такие таблицы (и другие объекты) автоматически помещаются в схему « public » . Она содержится во всех создаваемых базах данных. Таким образом, команда:

CREATE TABLE products ( . );

CREATE TABLE public.products ( . );

5.8.3. Путь поиска схемы

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

Возможность создавать одноимённые объекты в разных схемах усложняет написание запросов, которые должны всегда обращаться к конкретным объектам. Это также потенциально позволяет пользователям влиять на поведение запросов других пользователей, злонамеренно или случайно. Ввиду преобладания неполных имён в запросах и их использования внутри PostgreSQL , добавить схему в search_path — по сути значит доверять всем пользователям, имеющим право CREATE в этой схеме. Когда вы выполняете обычный запрос, злонамеренный пользователь может создать объекты в схеме, включённой в ваш путь поиска, и таким образом перехватывать управление и выполнять произвольные функции SQL как если бы их выполняли вы.

Первая схема в пути поиска называется текущей. Эта схема будет использоваться не только при поиске, но и при создании объектов — она будет включать таблицы, созданные командой CREATE TABLE без указания схемы.

Чтобы узнать текущий тип поиска, выполните следующую команду:

SHOW search_path;

В конфигурации по умолчанию она возвращает:

search_path -------------- "$user", public

Первый элемент ссылается на схему с именем текущего пользователя. Если такой схемы не существует, ссылка на неё игнорируется. Второй элемент ссылается на схему public, которую мы уже видели.

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

Чтобы добавить в путь нашу новую схему, мы выполняем:

SET search_path TO myschema,public;

(Мы опускаем компонент $user , так как здесь в нём нет необходимости.) Теперь мы можем обращаться к таблице без указания схемы:

DROP TABLE mytable;

И так как myschema — первый элемент в пути, новые объекты будут по умолчанию создаваться в этой схеме.

Мы можем также написать:

SET search_path TO myschema;

Тогда мы больше не сможем обращаться к схеме public, не написав полное имя объекта. Единственное, что отличает схему public от других, это то, что она существует по умолчанию, хотя её так же можно удалить.

В Разделе 9.25 вы узнаете, как ещё можно манипулировать путём поиска схем.

Как и для имён таблиц, путь поиска аналогично работает для имён типов данных, имён функций и имён операторов. Имена типов данных и функций можно записать в полном виде так же, как и имена таблиц. Если же вам нужно использовать в выражении полное имя оператора, для этого есть специальный способ — вы должны написать:

OPERATOR(схема.оператор) 

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

SELECT 3 OPERATOR(pg_catalog.+) 4;

На практике пользователи часто полагаются на путь поиска, чтобы не приходилось писать такие замысловатые конструкции.

5.8.4. Схемы и права

По умолчанию пользователь не может обращаться к объектам в чужих схемах. Чтобы изменить это, владелец схемы должен дать пользователю право USAGE для данной схемы. Чтобы пользователи могли использовать объекты схемы, может понадобиться назначить дополнительные права на уровне объектов.

Пользователю также можно разрешить создавать объекты в схеме, не принадлежащей ему. Для этого ему нужно дать право CREATE в требуемой схеме. Заметьте, что по умолчанию все имеют права CREATE и USAGE в схеме public . Благодаря этому все пользователи могут подключаться к заданной базе данных и создавать объекты в её схеме public . Некоторые шаблоны использования требуют запретить это:

REVOKE CREATE ON SCHEMA public FROM PUBLIC;

(Первое слово « public » обозначает схему, а второе означает « каждый пользователь » . В первом случае это идентификатор, а во втором — ключевое слово, поэтому они написаны в разном регистре; вспомните указания из Подраздела 4.1.1.)

5.8.5. Схема системного каталога

В дополнение к схеме public и схемам, создаваемым пользователями, любая база данных содержит схему pg_catalog , в которой находятся системные таблицы и все встроенные типы данных, функции и операторы. pg_catalog фактически всегда является частью пути поиска. Если даже эта схема не добавлена в путь явно, она неявно просматривается до всех схем, указанных в пути. Так обеспечивается доступность встроенных имён при любых условиях. Однако вы можете явным образом поместить pg_catalog в конец пути поиска, если вам нужно, чтобы пользовательские имена переопределяли встроенные.

Так как имена системных таблиц начинаются с pg_ , такие имена лучше не использовать во избежание конфликта имён, возможного при появлении в будущем системной таблицы с тем же именем, что и ваша. (С путём поиска по умолчанию неполная ссылка будет воспринята как обращение к системной таблице.) Системные таблицы будут и дальше содержать в имени приставку pg_ , так что они не будут конфликтовать с неполными именами пользовательских таблиц, если пользователи со своей стороны не будут использовать приставку pg_ .

5.8.6. Шаблоны использования

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

Ограничить обычных пользователей личными схемами. Для реализации этого подхода выполните REVOKE CREATE ON SCHEMA public FROM PUBLIC и создайте для каждого пользователя схему с его именем. Если затрагиваемые пользователи подключались к базе ранее, проведите аудит схемы на предмет наличия таких же имён, как в схеме pg_catalog . Вспомните, что путь поиска по умолчанию начинается со значения $user , которое разрешается в имя пользователя. Таким образом, если у всех пользователей будет отдельная схема, они по умолчанию будут обращаться к собственным схемам.

Удалить схему public из пути поиска по умолчанию для каждого пользователя с помощью команды ALTER ROLE пользователь SET search_path = «$user» . Все сохранят возможность создавать объекты в общедоступной схеме, но обращаться к ним будут только по полным именам. Хотя обращение к таблицам по полным именам вполне безопасно, вызовы функций в схеме public будут небезопасными или ненадёжными. Кроме того, пользователь, имеющий право CREATEROLE , может отменить это назначение и выполнять произвольные запросы от имени пользователей, полагающихся на этот путь. Если вы создаёте функции или расширения в схеме public или даёте пользователям право CREATEROLE , но не хотите, чтобы они стали практически суперпользователями, вам нужно использовать первый шаблон.

Удалить схему public из пути поиска search_path в postgresql.conf . Это будет иметь такое же влияние на пользователей, что и предыдущий шаблон. В дополнение к его особенностям относительно функций и права CREATEROLE , данный шаблон подразумевает также доверие к владельцам базам данных, как к имеющим право CREATEROLE . Если вы создаёте функции или расширения в схеме public, даёте пользователям права CREATEROLE , CREATEDB или делаете их владельцами отдельных баз данных, но не хотите, чтобы они стали практически суперпользователями, вам нужно использовать первый шаблон.

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

5.8.7. Переносимость

Стандарт SQL не поддерживает обращение в одной схеме к разным объектам, принадлежащим разным пользователям. Более того, в ряде реализаций СУБД нельзя создавать схемы с именем, отличным от имени владельца. На практике, в СУБД, реализующих только базовую поддержку схем согласно стандарту, концепции пользователя и схемы очень близки. Таким образом, многие пользователи полагают, что полное имя на самом деле образуется как имя_пользователя . имя_таблицы . И именно так будет вести себя Postgres Pro , если вы создадите схемы для каждого пользователя.

В стандарте SQL нет и понятия схемы public . Для максимального соответствия стандарту использовать схему public не следует.

Конечно, есть СУБД, в которых вообще не реализованы схемы или пространства имён поддерживают (возможно, с ограничениями) обращения к другим базам данных. Если вам потребуется работать с этими системами, максимальной переносимости вы достигнете, вообще не используя схемы.

Пред.	Наверх	След.
5.7. Политики защиты строк	Начало	5.9. Наследование