schema sql что это
Create Schema, Database
Схема Schema с точки зрения базы данных представляет собой контейнер объектов типа таблиц, триггеров, хранимых процедур и т.п. В данной статье будут рассмотрены вопросы создания и удаления схемы БД следующих СУБД :
Создание схемы, CREATE SCHEMA
Для создания схемы необходимо использовать SQL скрипт CREATE SCHEMA. Разные схемы могут включать одноименные объекты. При обращении к объектам разных схем необходимо указывать наименование схемы как префикс. Для создания схемы пользователь должен иметь соответствующие привилегии. Конечно же, superuser’ы данной привилегией владеют.
Создание схемы Oracle
Oracle относится к тем платформам СУБД, которые не имеют явной поддержки команды CREATE SCHEMA. Однако он все же неявно создаёт схему, когда пользователь создаёт свой первый объект базы данных. Данная СУБД использует команду «CREATE SCHEMA» для создания за одну транзакцию таблиц и представлений вместе с предоставлением доступа к ним.
Необходимо отметить, что Oracle разрешает дополнительно использовать в инструкции CREATE SCHEMA стандартные скрипты CREATE TABLE, CREATE VIEW и GRANT. Нельзя использовать любые расширения этих команд, имеющиеся в Oracle, если эти команды включены в инструкцию CREATE SCHEMA. Синтаксис создания объектов со схемой.
В следующем примере для схемы «painter»» создаются таблица и представление. Коме этого в инструкции CREATE SCHEMA определен доступ к объектам.
Порядок команд создания объектов и предоставления прав доступа в инструкции CREATE SCHEMA не критичен, но все же следует соблюдать синтаксис. Oracle выполняет инструкцию CREATE SCHEMA только в том случае, если все входящие в нее инструкции CREATE и GRANT были выполнены успешно.
Создание схемы MS SQL
В СУБД MS SQL при помощи транзакции CREATE SCHEMA можно создать схему одновременно с созданием в ней таблиц, представлений и предоставить или запретить доступ на эти объекты с использованием операторов GRANT, DENY или REVOKE.
Транзакция CREATE SCHEMA являются атомарной. Если в процессе выполнения инструкции CREATE SCHEMA возникают ошибки, то ни один из указанных объектов не создается и ни одно разрешение не предоставляется.
Объекты, которые необходимо создать при помощи инструкции CREATE SCHEMA, могут быть перечислены в любом порядке, за исключением представлений, ссылающихся на другие представления. В этом случае ссылающееся представление должно быть создано после того представления, на которое оно ссылается.
При помощи инструкции GRANT можно предоставлять разрешения на объект еще до того, как он будет создан, а инструкция CREATE VIEW может появляться раньше инструкций CREATE TABLE, создающих таблицы, на которые ссылается представление. Кроме того, инструкции CREATE TABLE могут декларировать внешние ключи к таблицам, определенным позже в инструкции CREATE SCHEMA.
Создание схемы PostgreSQL
Новая схема создается в текущей базе данных сервера, с которым установлено соединение. Наименование схемы должно быть уникально для данной Database.
Примеры создания схемы в PostgreSQL :
Примечание : Согласно SQL стандарту, владелец схемы всегда является «хозяином» всех находящихся внутри объектов. PostgreSQL, также как и MSSQL, разрешает создание внутри схем объектов, «хозяином» которых может быть не владелец схемы, но имеющий соответствующие привилегии данной схемы.
Создание базы данных MySQL
Если при создании таблицы эти параметры CHARACTER SET и COLLATE не указываются, то кодировка и порядок сортировки вновь создаваемой таблицы берутся из значений, указанных для текущей базы данных.
Примеры использования CREATE DATABASE
Создание схемы Derby
Наименование схемы не должно содержать более 128 символов и быть уникальным внутри базы данных. Также наименование не должно начинаться с префикса SYS.
Только владелец базы данных может создавать схему с наименованием, отличным от имени/логина пользователя, и только владелец базы данных может определять AUTHORIZATION username с именем/логином пользователя, отличным от текущего логина.
Примечание : username может принадлежать только пользователю, а не role.
Удаление схемы, DROP SCHEMA
Для удаления схемы необходимо использовать SQL скрипт drop schema.
Удаление схемы Oracle
Для удаление схемы СУБД Oracle необходимо удалить пользователя; объекты схемы удаляются автоматически :
Ключевое слово CASCADE означает удалить все связанное со схемой (пользователем) объекты.
Удаление схемы MSSQL
Удаляемая схема не должна содержать никаких объектов. Если схема содержит объекты, выполнение инструкции DROP заканчивается сбоем. Сведения о схемах можно увидеть в представлении каталога sys.schemas.
Удаление схемы PostgreSQL
Схема может быть удалена только её владельцем или superuser’ом. Необходимо помнить, что владелец owner может удалить схему и все содержащиеся в ней объекты даже если они ему не принадлежат.
При удалении схемы в PostgreSQL можно дополнительно включить параметры :
Пример удаления схемы orders вместе с содержащимися в ней объектами :
Удаление базы данных MySQL
В СУБД MySQL удалить можно не только пустую базу данных.
Если не указать параметр IF EXISTS, то при попытке удаления не существующей базы данных, возникнет ошибка выполнения команды. Данный параметр доступен в MySQL 3.22 и более поздних версиях. При выполнении команды DROP DATABASE удаляется как сама база данных, так и все объекты, которые в ней находятся.
В следующем примере удаляется база данных «forum» :
Удаление схемы Derby
В СУБД Derby удалить можно только пустую схему. Схемы SYS и APP (схема пользователя по умолчанию) не могут быть удалены.
Ключевое слово RESTRICT является обязательным и обязывает выполнение проверки наличия объектов в удаляемой схеме.
Обновление схемы, ALTER SCHEMA
В SQL стандарте скрипт ALTER SCHEMA не определен.
В PostgreSQL владельца или наименование схемы можно изменить скриптом ALTER SCHEMA.
Чтобы использовать ALTER SCHEMA необходимо быть владельцем схемы и иметь соответствующие привилегии. При изменении наименования схемы нужно иметь привилегии CREATE для текущей базы данных. Чтобы сменить владельца, необходимо быть членом соответствующей роли и иметь в ней привилегии CREATE.
В СУБД MSSQL с помощью скрипта ALTER SCHEMA можно перенести объекты из одной схемы в другую.
Пользователи и схемы в MSSQL полностью разделены. Инструкция ALTER SCHEMA применяется только для перемещения объектов между схемами в пределах одной базы данных. В следующем примере схема Customers изменяется путем перемещения в нее таблицы Cities из схемы Persons.
Создание схемы базы данных
В этом разделе описывается создание схемы в SQL Server с помощью среды SQL Server Management Studio или Transact-SQL.
Перед началом
Ограничения
Новая схема принадлежит одному из следующих участников уровня базы данных: пользователю базы данных, роли базы данных или роли приложения. Объекты, создаваемые в схеме, принадлежат владельцу схемы и имеют значение NULL для principal_id в sys.objects. Владение объектами, содержащимися в схеме, можно передать любому участнику уровня базы данных, однако у владельца схемы всегда остается разрешение CONTROL на объекты в схеме.
Если при создании объекта базы данных указать допустимый субъект домена (пользователя или группу) в качестве владельца объекта, то этот субъект добавляется в базу данных в качестве схемы. Новая схема принадлежит этому субъекту домена.
безопасность
Permissions
Требует разрешения CREATE SCHEMA в базе данных.
Чтобы назначить другого пользователя владельцем создаваемой схемы, у участника должно быть разрешение IMPERSONATE на этого пользователя. Если роль базы данных указана в качестве владельца, то вызывающий объект должен входить в роль или иметь на нее разрешение ALTER.
Использование среды SQL Server Management Studio
Создание схемы
Разверните базу данных, в которой создается новая схема базы данных.
Нажмите кнопку ОК.
Диалоговое окно не будет отображаться, если вы создаете схему с помощью SSMS для Базы данных SQL Azure или Azure Synapse Analytics. Потребуется создать схему шаблона T-SQL.
Дополнительные параметры
Диалоговое окно Схема — создать также содержит параметры на двух дополнительных страницах: Разрешения и Расширенные свойства.
На странице Разрешения перечислены все возможные защищаемые объекты и разрешения на эти объекты, которые могут быть предоставлены для имени входа.
Страница Расширенные свойства позволяет добавлять пользовательские свойства пользователям базы данных.
Использование Transact-SQL
Создание схемы
В обозревателе объектов подключитесь к экземпляру компонента Компонент Database Engine.
На стандартной панели выберите пункт Создать запрос.
Чтобы просмотреть схемы в этой базе данных, выполните следующую инструкцию.
Следующие шаги
Дополнительные сведения см. в разделе CREATE SCHEMA (Transact-SQL).
Что такое схемы базы данных? 5-минутное руководство с примерами
При создании серверной части приложения необходимо учитывать, как интерфейс будет взаимодействовать с серверной частью. Однако более важным является построение и дизайн вашей базы данных. Отношения между вашими формами данных приведут к построению вашей схемы базы данных.
Схема базы данных является абстрактным дизайн, который представляет собой хранение ваших данных в базе данных. Он описывает как организацию данных, так и отношения между таблицами в данной базе данных. Разработчики заранее планируют схему базы данных, чтобы знать, какие компоненты необходимы и как они будут соединяться друг с другом.
В этом руководстве мы узнаем, что такое схема базы данных и почему они используются. Мы рассмотрим несколько распространенных примеров, чтобы вы могли узнать, как настроить схему базы данных самостоятельно.
Что такое схемы базы данных?
Когда дело доходит до выбора базы данных, одна из вещей, о которой вы должны подумать, — это форма ваших данных, модель, которой они будут следовать, и то, как сформированные отношения помогут нам при разработке схемы.
Схема базы данных — это план или архитектура того, как будут выглядеть наши данные. Он не содержит самих данных, а вместо этого описывает форму данных и то, как они могут быть связаны с другими таблицами или моделями. Запись в нашей базе данных будет экземпляром схемы базы данных. Он будет содержать все свойства, описанные в схеме.
Думайте о схеме базы данных как о типе структуры данных. Он представляет собой структуру и структуру содержимого данных организации.
Схема базы данных будет включать:
Размер и сложность схемы вашей базы данных зависит от размера вашего проекта. Визуальный стиль схемы базы данных позволяет программистам правильно структурировать базу данных и ее взаимосвязи, прежде чем переходить к коду. Процесс планирования дизайна базы данных называется моделированием данных.
Схемы важны для проектирования систем управления базами данных (СУБД) или систем управления реляционными базами данных (СУБД). СУБД — это программное обеспечение, которое хранит и извлекает пользовательские данные безопасным способом в соответствии с концепцией ACID.
Во многих компаниях ответственность за проектирование базы данных и СУБД обычно ложится на роль администратора базы данных (DBA). Администраторы баз данных несут ответственность за обеспечение беспрепятственного доступа к информации аналитикам данных и пользователям баз данных. Они работают вместе с командами менеджеров для планирования и безопасного управления базой данных организации.
Примечание. Некоторыми популярными СУБД являются MySQL, Oracle, PostgreSQL, Microsoft Access, MariaBB и dBASE, а также другие.
Типы схемы базы данных
Существует два основных типа схемы базы данных, которые определяют разные части схемы: логическую и физическую.
Логический
Схема логической базы данных представляет, как данные организованы в виде таблиц. Он также объясняет, как атрибуты из таблиц связаны друг с другом. В разных схемах используется разный синтаксис для определения логической архитектуры и ограничений.
Примечание. Ограничения целостности — это набор правил для СУБД, которые поддерживают качество вставки и обновления данных.
Чтобы создать логическую схему базы данных, мы используем инструменты для иллюстрации отношений между компонентами ваших данных. Это называется моделированием сущности-отношения (моделирование ER). Он определяет отношения между типами сущностей.
Схема ниже представляет собой очень простую модель ER, которая показывает логический поток в базовом коммерческом приложении. Он объясняет продукт покупателю, который его покупает.
Идентификаторы в каждом из трех верхних кружков указывают первичный ключ объекта. Это идентификатор, который однозначно определяет запись в документе или таблице. FK на схеме — это внешний ключ. Это то, что связывает отношения от одной таблицы к другой.
Модели сущностей-отношений могут быть созданы всевозможными способами, и существуют онлайн-инструменты, которые помогают в построении диаграмм, таблиц и даже SQL для создания вашей базы данных из существующей модели ER. Это поможет создать физическое представление схемы вашей базы данных.
Физический
Схема физической базы данных представляет, как данные хранятся на диске. Другими словами, это реальный код, который будет использоваться для создания структуры вашей базы данных. Например, в MongoDB с мангустом это примет форму модели мангуста. В MySQL вы будете использовать SQL для создания базы данных с таблицами.
По сравнению с логической схемой она включает имена таблиц базы данных, имена столбцов и типы данных.
Теперь, когда мы знакомы с основами схемы базы данных, давайте рассмотрим несколько примеров. Мы рассмотрим наиболее распространенные примеры, с которыми вы можете столкнуться.
Пример NoSQL
Базы данных NoSQL в первую очередь называются нереляционными или распределенными базами данных. Разработка схемы для NoSQL является предметом некоторых дискуссий, поскольку они имеют динамическую схему. Некоторые утверждают, что привлекательность NoSQL заключается в том, что вам не нужно создавать схему, но другие говорят, что дизайн очень важен для этого типа базы данных, поскольку он не предоставляет одно решение.
Этот фрагмент является примером того, как будет выглядеть физическая схема базы данных при использовании Mongoose (MongoDB) для создания базы данных, представляющей приведенную выше диаграмму отношения сущность. Просматривайте вкладки кода, чтобы увидеть различные части.
CREATE SCHEMA (Transact-SQL)
Creates a schema in the current database. The CREATE SCHEMA transaction can also create tables and views within the new schema, and set GRANT, DENY, or REVOKE permissions on those objects.
Transact-SQL Syntax Conventions
Syntax
To view Transact-SQL syntax for SQL Server 2014 and earlier, see Previous versions documentation.
Arguments
schema_name
Is the name by which the schema is identified within the database.
AUTHORIZATION owner_name
Specifies the name of the database-level principal that will own the schema. This principal may own other schemas, and may not use the current schema as its default schema.
table_definition
Specifies a CREATE TABLE statement that creates a table within the schema. The principal executing this statement must have CREATE TABLE permission on the current database.
view_definition
Specifies a CREATE VIEW statement that creates a view within the schema. The principal executing this statement must have CREATE VIEW permission on the current database.
grant_statement
Specifies a GRANT statement that grants permissions on any securable except the new schema.
revoke_statement
Specifies a REVOKE statement that revokes permissions on any securable except the new schema.
deny_statement
Specifies a DENY statement that denies permissions on any securable except the new schema.
Remarks
Statements that contain CREATE SCHEMA AUTHORIZATION but do not specify a name, are permitted for backward compatibility only. The statement does not cause an error, but does not create a schema.
CREATE SCHEMA can create a schema, the tables and views it contains, and GRANT, REVOKE, or DENY permissions on any securable in a single statement. This statement must be executed as a separate batch. Objects created by the CREATE SCHEMA statement are created inside the schema that is being created.
CREATE SCHEMA transactions are atomic. If any error occurs during the execution of a CREATE SCHEMA statement, none of the specified securables are created and no permissions are granted.
Securables to be created by CREATE SCHEMA can be listed in any order, except for views that reference other views. In that case, the referenced view must be created before the view that references it.
Therefore, a GRANT statement can grant permission on an object before the object itself is created, or a CREATE VIEW statement can appear before the CREATE TABLE statements that create the tables referenced by the view. Also, CREATE TABLE statements can declare foreign keys to tables that are defined later in the CREATE SCHEMA statement.
DENY and REVOKE are supported inside CREATE SCHEMA statements. DENY and REVOKE clauses will be executed in the order in which they appear in the CREATE SCHEMA statement.
The principal that executes CREATE SCHEMA can specify another database principal as the owner of the schema being created. This requires additional permissions, as described in the «Permissions» section later in this topic.
The new schema is owned by one of the following database-level principals: database user, database role, or application role. Objects created within a schema are owned by the owner of the schema, and have a NULL principal_id in sys.objects. Ownership of schema-contained objects can be transferred to any database-level principal, but the schema owner always retains CONTROL permission on objects within the schema.
Beginning with SQL Server 2005, the behavior of schemas changed. As a result, code that assumes that schemas are equivalent to database users may no longer return correct results. Old catalog views, including sysobjects, should not be used in a database in which any of the following DDL statements have ever been used: CREATE SCHEMA, ALTER SCHEMA, DROP SCHEMA, CREATE USER, ALTER USER, DROP USER, CREATE ROLE, ALTER ROLE, DROP ROLE, CREATE APPROLE, ALTER APPROLE, DROP APPROLE, ALTER AUTHORIZATION. In such databases you must instead use the new catalog views. The new catalog views take into account the separation of principals and schemas that was introduced in SQL Server 2005. For more information about catalog views, see Catalog Views (Transact-SQL).
Implicit Schema and User Creation
In some cases a user can use a database without having a database user account (a database principal in the database). This can happen in the following situations:
A login has CONTROL SERVER privileges.
A Windows user does not have an individual database user account (a database principal in the database), but accesses a database as a member of a Windows group which has a database user account (a database principal for the Windows group).
When a user without a database user account creates an object without specifying an existing schema, a database principal and default schema will be automatically created in the database for that user. The created database principal and schema will have the same name as the name that user used when connecting to SQL Server (the SQL Server authentication login name or the Windows user name).
This behavior is necessary to allow users that are based on Windows groups to create and own objects. However it can result in the unintentional creation of schemas and users. To avoid implicitly creating users and schemas, whenever possible explicitly create database principals and assign a default schema. Or explicitly state an existing schema when creating objects in a database, using two or three-part object names.
The implicit creation of an Azure Active Directory user is not possible on SQL Database. Since creating an Azure AD user from external provider must check the users status in the AAD, creating the user will fail with error 2760: The specified schema name » » either does not exist or you do not have permission to use it. And then error 2759: CREATE SCHEMA failed due to previous errors. To work around these errors, create the Azure AD user from external provider first and then rerun the statement creating the object.
Deprecation Notice
CREATE SCHEMA statements that do not specify a schema name are currently supported for backward compatibility. Such statements do not actually create a schema inside the database, but they do create tables and views, and grant permissions. Principals do not need CREATE SCHEMA permission to execute this earlier form of CREATE SCHEMA, because no schema is being created. This functionality will be removed from a future release of SQL Server.
Permissions
Requires CREATE SCHEMA permission on the database.
To create an object specified within the CREATE SCHEMA statement, the user must have the corresponding CREATE permission.
To specify another user as the owner of the schema being created, the caller must have IMPERSONATE permission on that user. If a database role is specified as the owner, the caller must have one of the following: membership in the role or ALTER permission on the role.
For the backward-compatible syntax, no permissions to CREATE SCHEMA are checked because no schema is being created.
Examples
A. Creating a schema and granting permissions
Examples: Azure Synapse Analytics and Analytics Platform System (PDW)
B. Creating a schema and a table in the schema
The following example creates schema Sales and then creates a table Sales.Region in that schema.
C. Setting the owner of a schema
CREATE SCHEMA (Transact-SQL)
Создает схему в текущей базе данных. При помощи транзакции CREATE SCHEMA также можно создавать таблицы и представления в новой схеме и предоставлять разрешения GRANT, DENY или REVOKE на такие объекты.
Синтаксические обозначения в Transact-SQL
Синтаксис
Ссылки на описание синтаксиса Transact-SQL для SQL Server 2014 и более ранних версий, см. в статье Документация по предыдущим версиям.
Аргументы
schema_name
Имя, по которому схема идентифицируется в данной базе данных.
AUTHORIZATION owner_name
Указывает имя участника уровня базы данных, который является владельцем схемы. Этому участнику могут принадлежать и другие схемы, при этом текущая схема может не использоваться по умолчанию.
table_definition
Указывает инструкцию CREATE TABLE, которая создает таблицу внутри схемы. У участника, выполняющего эту инструкцию, должно быть разрешение CREATE TABLE в текущей базе данных.
view_definition
Указывает инструкцию CREATE VIEW, которая создает представление внутри схемы. У участника, выполняющего эту инструкцию, должно быть разрешение CREATE VIEW в текущей базе данных.
grant_statement
Указывает инструкцию GRANT, которая предоставляет разрешения на любой защищаемый объект, за исключением новой схемы.
revoke_statement
Указывает инструкцию REVOKE, которая отменяет разрешения на любой защищаемый объект, за исключением новой схемы.
deny_statement
Указывает инструкцию DENY, которая запрещает разрешения на любой защищаемый объект, за исключением новой схемы.
Remarks
Выражения, которые содержат инструкцию CREATE SCHEMA AUTHORIZATION, но не определяют имя, разрешены только для обратной совместимости. Выражение не вызывает ошибку, но не создает схему.
Инструкция CREATE SCHEMA создает схему, содержащиеся в ней таблицы и представления, а также разрешения GRANT, REVOKE или DENY на любой защищаемый объект в одной инструкции. Эта инструкция должна выполняться как отдельный пакет. При помощи инструкции CREATE SCHEMA объекты создаются внутри создаваемой схемы.
Транзакции CREATE SCHEMA являются атомарными. Если в процессе выполнения инструкции CREATE SCHEMA возникают ошибки, ни один из указанных защищаемых объектов не создается и ни одно разрешение не предоставляется.
Защищаемые объекты, которые необходимо создать при помощи инструкции CREATE SCHEMA, могут быть перечислены в любом порядке, за исключением представлений, ссылающихся на другие представления. В этом случае ссылающееся представление должно быть создано после того представления, на которое оно ссылается.
Таким образом, при помощи инструкции GRANT можно предоставлять разрешения на объект еще до того, как он будет создан, а инструкция CREATE VIEW может появляться раньше инструкций CREATE TABLE, создающих таблицы, на которые ссылается представление. Кроме того, инструкции CREATE TABLE могут декларировать внешние ключи к таблицам, определенным позже в инструкции CREATE SCHEMA.
В инструкциях CREATE SCHEMA поддерживаются DENY и REVOKE. Предложения DENY и REVOKE будут исполняться в той последовательности, в которой они появляются в инструкции CREATE SCHEMA.
Участник, выполняющий инструкцию CREATE SCHEMA, может указать другого участника базы данных в качестве владельца создаваемой схемы. Для этого необходимы дополнительные разрешения, описанные в подразделе «Разрешения» далее в этом разделе.
Новая схема принадлежит одному из следующих участников уровня базы данных: пользователю базы данных, роли базы данных или роли приложения. Объекты, создаваемые в схеме, принадлежат владельцу схемы и имеют значение NULL для principal_id в sys.objects. Владение объектами, содержащимися в схеме, можно передать любому участнику уровня базы данных, однако у владельца схемы всегда остается разрешение CONTROL на объекты в схеме.
Начиная с SQL Server 2005 поведение схем изменилось. В результате программный код, предполагающий, что схемы эквивалентны пользователям базы данных, возможно, не будет более возвращать правильные результаты. Старые представления каталогов, включая sysobjects, не должны использоваться в базах данных, где когда-либо выполнялась любая из следующих инструкций DDL: CREATE SCHEMA, ALTER SCHEMA, DROP SCHEMA, CREATE USER, ALTER USER, DROP USER, CREATE ROLE, ALTER ROLE, DROP ROLE, CREATE APPROLE, ALTER APPROLE, DROP APPROLE, ALTER AUTHORIZATION. В таких базах данных необходимо использовать новые представления каталога. Новые представления каталога учитывают разделение участников и схем, введенное в SQL Server 2005. Дополнительные сведения о представлениях каталогов см. в статье Представления каталогов (Transact-SQL).
Неявное создание схемы и пользователя
В некоторых случаях пользователь может использовать базу данных без учетной записи пользователя базы данных (субъект базы данных в базе данных). Это может случаться в следующих ситуациях:
Имя входа имеет привилегии CONTROL SERVER.
Пользователь Windows не имеет индивидуальной учетной записи пользователя базы данных (субъект базы данных в базе данных), однако получает доступ в базу данных как член группы Windows, которая имеет учетную запись пользователя базы данных (субъект базы данных для группы Windows).
Когда пользователь без учетной записи пользователя базы данных создает объект без определения существующей схемы, субъект базы данных и схема по умолчанию будут автоматически созданы в базе данных для этого пользователя. Созданные субъект и схема базы данных будут иметь то же имя, которым пользовался пользователь при подключении к SQL Server (имя входа в систему проверки подлинности или имя пользователя Windows SQL Server).
Данное поведение необходимо, чтобы позволить пользователям, базирующимся в группах Windows, создавать и обладать объектами. Однако это может привести к неумышленному созданию схем и пользователей. Во избежание неявного создания пользователей и схем каждый раз, при возможности, явно создавайте субъекты базы данных и назначайте схему по умолчанию. Или явно выражайте существующую схему при создании объектов в базе данных, используя двух- или трехчастные имена объектов.
Неявное создание пользователя Azure Active Directory невозможно в База данных SQL. Так как при создании пользователя Azure AD из внешнего поставщика необходимо проверить состояние пользователей в AAD, создание пользователя завершится ошибкой 2760: Указанное имя схемы « » не существует, или у вас нет разрешения для его использования. Затем выводится ошибка 2759: Выполнение CREATE SCHEMA завершилось неудачно из-за предыдущих ошибок. Чтобы устранить эти ошибки, сначала создайте пользователя Azure AD из внешнего поставщика, а затем повторно запустите инструкцию для создания объекта.
Уведомление об устаревании
Инструкции CREATE SCHEMA, не указывающие имя схемы, поддерживаются в данный момент только для обратной совместимости. Такие инструкции на самом деле не создают схему внутри базы данных, а создают таблицы и представления, а также предоставляют разрешения. Участникам не нужны разрешения CREATE SCHEMA для выполнения этой более ранней формы инструкции CREATE SCHEMA, поскольку схема не создается. Эта функция не будет включена в последующие версии SQL Server.
Разрешения
Требует разрешения CREATE SCHEMA в базе данных.
Чтобы создать объект, указанный в инструкции CREATE SCHEMA, у пользователя должно быть соответствующее разрешение CREATE.
Чтобы назначить другого пользователя владельцем создаваемой схемы, у участника должно быть разрешение IMPERSONATE на этого пользователя. Если роль базы данных указана в качестве владельца, то вызывающий объект должен входить в роль или иметь на нее разрешение ALTER.
Для обеспечения обратной совместимости синтаксиса разрешения на CREATE SCHEMA не проверяются, поскольку схема не создается.