Trennung von Benutzer und Schema

Aktualisiert: 12. Dezember 2006

Seit SQL Server 2005 gehört jedes Objekt zu einem Datenbankschema. Ein Datenbankschema stellt einen eindeutigen Namespace dar, der unabhängig von einem Datenbankbenutzer ist. Sie können sich ein Schema als Container für Objekte vorstellen. Schemas können in einer Datenbank erstellt und geändert werden, und Benutzern kann der Zugriff auf ein Schema gewährt werden. Ein Schema kann im Besitz eines beliebigen Benutzers sein, und der Besitz des Schemas ist übertragbar.

Hinweis:
Datenbankschemas unterscheiden sich von XML-Schemas. Weitere Informationen zu XML-Schemas finden Sie unter Verwalten von XML-Schemaauflistungen auf dem Server.

Weitere Informationen zum Erstellen eines Datenbankobjektschemas finden Sie unter CREATE SCHEMA (Transact-SQL).

Neues Verhalten

In früheren Versionen von SQL Server hat es sich bei Datenbankbenutzern und Schemas konzeptionell um das gleiche Objekt gehandelt. Seit SQL Server 2005 wird zwischen Benutzern und Schemas unterschieden, und Schemas fungieren als Container für Objekte.

Die Trennung des Besitzes von Schemas hat wichtige Auswirkungen. Datenbankschemas bieten aufgrund der folgenden Bedingungen eine größere Kontrolle der Sicherheit von Datenbankobjekten:

• Berechtigungen für Schemas und in Schemas enthaltene sicherungsfähige Elemente können mit größerer Genauigkeit verwaltet werden, als dies in früheren Versionen der Fall war. Weitere Informationen finden Sie unter GRANT-Schemaberechtigungen (Transact-SQL) und GRANT (Objektberechtigungen) (Transact-SQL).
• Der Besitz von Schemas und sicherungsfähigen Elementen mit Schemabereich kann übertragen werden. Weitere Informationen finden Sie unter ALTER AUTHORIZATION (Transact-SQL).
• Objekte können zwischen Schemas verschoben werden. Weitere Informationen finden Sie unter ALTER SCHEMA (Transact-SQL).
• In einem einzelnen Schema können Objekte enthalten sein, die im Besitz mehrerer Datenbankbenutzer sind.
• Mehrere Datenbankbenutzer können ein einzelnes Standardschema gemeinsam nutzen.
• Jedes Schema kann im Besitz eines beliebigen Datenbankprinzipals sein. Dies schließt auch Rollen und Anwendungsrollen ein.
• Ein Datenbankbenutzer kann gelöscht werden, ohne dass Objekte im entsprechenden Schema gelöscht werden müssen.

Datenbankschemas bringen im Vergleich zu früheren Versionen weitere wichtige Änderungen an der Sicherheit mit sich:

• Mit Code, der für frühere Versionen von SQL Server geschrieben wurde, werden möglicherweise falsche Ergebnisse zurückgegeben, wenn im Code angenommen wird, dass Schemas und Datenbankbenutzer äquivalent sind.
• Für Katalogsichten, die in früheren Versionen von SQL Server erstellt wurden, werden möglicherweise falsche Ergebnisse zurückgegeben. Dazu zählt beispielsweise sysobjects.
• Besitzketten und Benutzerkontextwechsel verhalten sich jetzt möglicherweise anders, da Benutzer mehr als ein Schema besitzen können. Weitere Informationen zu Besitzketten finden Sie unter Besitzketten und Berechtigungshierarchie. Weitere Informationen zu Kontextwechseln finden Sie unter Kontextwechsel.
• In SQL Server 2000 befanden sich Datenbankobjekte im Besitz von Benutzern. Der vierteilige Verweis auf ein Datenbankobjekt lautete in SQL Server 2000 [DatabaseServer].[DatabaseName].[ObjectOwner].[DatabaseObject]. Seit SQL Server 2005 lautet der vierteilige Verweis auf ein Datenbankobjekt [DatabaseServer].[DatabaseName].[DatabaseSchema].[DatabaseObject].

Änderungen am Objektbesitz

Die Owner-Eigenschaft der folgenden Objekte verweist auf ein Schema statt auf einen Benutzer:

• CREATE TABLE
• ALTER TABLE
• CREATE VIEW
• ALTER VIEW
• CREATE INDEX
• ALTER INDEX
• CREATE FUNCTION
• ALTER FUNCTION
• DROP FUNCTION
• VIEW_TABLE_USAGE
• VIEW_COLUMN_USAGE
• TABLE_CONSTRAINTS
• REFERENTIAL_CONSTRAINTS
• KEY_COLUMN_USAGE
• CONSTRAINT_TABLE_USAGE
• CONSTRAINT_COLUMN_USAGE
• CHECK_CONSTRAINTS
• COLUMN_DOMAIN_USAGE
• COLUMNS
• DOMAIN_CONSTRAINTS
• ROUTINE_COLUMNS

Weitere Informationen dazu, von welchen Spalten Benutzermetadaten statt Schemametadaten zurückgegeben werden, finden Sie im untenstehenden Abschnitt "Schemakatalogsichten und -funktionen".

Systemtabellen durch Katalogsichten und Funktionen ersetzt

In SQL Server 2005 sind mehr als 250 neue Katalogsichten vorhanden, von denen einige die Datenbankbenutzer und Schemaobjekte betreffen, die die SQL Server 2000-Systemtabellen ersetzen. Es empfiehlt sich, mit den neuen Katalogsichten auf Metadaten zuzugreifen. Weitere Informationen finden Sie unter Katalogsichten (Transact-SQL).

In der folgenden Tabelle werden die Zuordnungen zwischen den SQL Server 2000-Systemtabellen und den entsprechenden SQL Server 2005-Katalogsichten veranschaulicht:

Standardschemas

Zum Auflösen der Namen von sicherungsfähigen Elementen, die nicht vollqualifiziert sind, wurde in SQL Server 2000 die Namensauflösung verwendet, um das Schema zu überprüfen, das sich im Besitz des aufrufenden Datenbankbenutzers befindet, und das Schema, das sich im Besitz von dbo befindet.

In SQL Server 2005 kann jedem Benutzer ein Standardschema zugewiesen werden. Das Standardschema kann mithilfe der Option DEFAULT_SCHEMA von CREATE USER oder ALTER USER festgelegt und geändert werden. Wenn DEFAULT_SCHEMA nicht definiert ist, wird in SQL Server 2005 davon ausgegangen, dass das dbo-Schema das Standardschema darstellt.

Hinweis:

Für Benutzer, die Verbindungen über eine Windows-authentifizierte Gruppe herstellen, steht keine Standardschemazuordnung zur Verfügung. Wenn ein solcher Benutzer ein Objekt erstellt, das nicht mit einem Schema qualifiziert wird, wird ein neues Schema erstellt, sein Name wird auf den Namen des aktuellen Benutzers festgelegt, und das Tabellenobjekt wird in diesem neuen, nach dem Benutzer benannten Namespace erstellt.

Mithilfe von neuen DDL-Anweisungen (Data Definition Language, Datendefinitionssprache) kann Komplexität für Systemmetadaten eingeführt werden, die in den alten Systemtabellen wie sysobjects nicht genau wiedergegeben werden. In diesem Beispiel sind die durch sysobjects zurückgegebene Benutzer-ID und der zurückgegebene Schemaname nicht synchron. Damit wird die Unterscheidung zwischen dem Benutzer und dem Schema widergespiegelt, die in SQL Server 2005 neu aufgenommen wurde.

USE tempdb
GO
CREATE LOGIN u1 WITH PASSWORD = 'Mdfjd$sakj943857l7sdfh##30'
CREATE USER u1 WITH DEFAULT_SCHEMA = u1
GO
GRANT CREATE TABLE TO u1 
GO
CREATE SCHEMA sch1
GO
CREATE SCHEMA u1 AUTHORIZATION u1
GO
EXECUTE AS USER = 'u1'
GO
CREATE TABLE t1(c1 int)
GO
REVERT
GO
SELECT user_name(uid) , * FROM sysobjects WHERE name = 't1'
GO

Vorsicht:
Sie müssen die neuen Katalogsichten in allen Datenbanken verwenden, in denen eine der folgenden DDL-Anweisungen verwendet wurde: CREATE/ALTER/DROP SCHEMA; CREATE/ALTER/DROP USER; CREATE/ALTER/DROP ROLE; CREATE/ALTER/DROP APPROLE; ALTER AUTHORIZATION.

Schemakatalogsichten und -funktionen

Seit SQL Server 2005 stellen Schemas explizite Entitäten dar, die in den Metadaten widergespiegelt werden. Als Ergebnis können Schemas nur einen Besitzer aufweisen, ein einzelner Benutzer kann jedoch ein oder mehrere Schemas besitzen. Diese komplexe Beziehung spiegelt sich in den SQL Server 2000-Systemtabellen nicht wider. In SQL Server 2005 werden neue Katalogsichten eingeführt, die die neuen Metadaten genau wiedergeben.

In der folgenden Tabelle werden die Katalogsichten, Metadaten und Funktionen für Schemas in SQL Server 2005 veranschaulicht:

Beispiele

A. Erstellen eines Schemas und Zuweisen des Besitzes zu einem Benutzer

Im folgenden Beispiel werden der AdventureWorks-Datenbank eine SQL Server-Anmeldung und ein Benutzer mit dem Namen Marjorie sowie ein neues Schema mit dem Namen Auditing hinzugefügt. Marjorie wird als Besitzer des Auditing-Schemas zugewiesen.

CREATE LOGIN Marjorie
    WITH PASSWORD = '8fdKJl3$nlNv3049jsKK';
USE AdventureWorks;
CREATE USER Marjorie FOR LOGIN Marjorie
GO
CREATE SCHEMA Auditing AUTHORIZATION Marjorie;
GO

B. Zuweisen von Berechtigungen für ein anderes Schema an einen Benutzer

Im folgenden Beispiel wird dem Benutzer Marjorie die SELECT-Berechtigung für das Purchasing-Schema in der AdventureWorks-Datenbank gewährt.

USE AdventureWorks;
GO
GRANT SELECT ON SCHEMA::Purchasing TO Marjorie;
GO

C. Ändern des Besitzes eines Schemas

Im folgenden Beispiel wird der neue Benutzer Jon in der AdventureWorks-Datenbank erstellt. Jon wird der Besitz des Auditing-Schemas in der AdventureWorks-Datenbank zugewiesen. Anschließend wird der Benutzer Marjorie aus der AdventureWorks-Datenbank entfernt.

USE AdventureWorks;
GO
/* Create a new user in the database */
CREATE LOGIN Jon
    WITH PASSWORD = '1fdKJl3$nlNv3049jsBB';
USE AdventureWorks;
CREATE USER Jon FOR LOGIN Jon
GO
ALTER AUTHORIZATION ON SCHEMA::Auditing TO Jon;
GO
/* Removes the user from the system */
DROP LOGIN Marjorie;
GO
DROP USER Marjorie;
GO

D. Anzeigen des Besitzes eines Schemas

Im folgenden Beispiel wird der Besitzer des Auditing-Schemas in der AdventureWorks-Datenbank angezeigt.

USE AdventureWorks;
GO
/* This method uses the INFORMATION_SCHEMA views */
SELECT * 
FROM INFORMATION_SCHEMA.SCHEMATA
WHERE SCHEMA_NAME = 'Auditing';
GO

/* This method uses the sys.schemas catalog and links
   the names of the database users and server logins */
SELECT s.name AS 'Schema Name'
, db.name AS 'Database User Name'
, svr.name AS 'SQL Server Login Name'
FROM sys.schemas s
/* Obtains the name of the database user */
   INNER JOIN sys.database_principals db
      ON s.principal_id = db.principal_id
/* Obtains the name of the server login */
      INNER JOIN sys.server_principals svr
         ON db.sid = svr.sid
WHERE s.name = 'Auditing'
ORDER BY s.name

Siehe auch

Konzepte

Berechtigungshierarchie
Prinzipale

Andere Ressourcen

CREATE SCHEMA (Transact-SQL)
ALTER SCHEMA (Transact-SQL)
ALTER AUTHORIZATION (Transact-SQL)
DROP SCHEMA (Transact-SQL)
sys.schemas (Transact-SQL)
CREATE USER (Transact-SQL)
ALTER USER (Transact-SQL)
Vornehmen von Schemaänderungen in Publikationsdatenbanken

Hilfe und Informationen

Informationsquellen für SQL Server 2005

Änderungsverlauf