<\/p>\n
Die älteren SQL Server-Versionen haben einen Nachteil: Sie benötigen hier einen Benutzer, dem eine neu erstellte Datenbank gehört. Genauso gibt es auch für alle weiteren Objekte wie Tabellen, Sichten, gespeicherte Prozeduren und so weiter einen Besitzer – nämlich den Benutzer, der das Objekt erstellt hat. Meist legt man diese Elemente im Kontext eines Windows-Benutzers an, was zum Beispiel dazu führt, dass Sie diesen Benutzer nicht einfach löschen können, ohne zuvor alle Elemente dieses Benutzers an einen anderen Benutzer übertragen zu haben. Aus diesem Grund hat Microsoft mit SQL Server 2005 den Typ namens „Schema“ eingeführt. Diesem werden nun nicht nur neu erstellte Objekte zugeordnet, sondern Sie können auch mehrere Schemas pro Datenbank verwenden, um beispielsweise Elemente nach verschiedenen Gruppen zu sortieren.<\/b><\/p>\n
Schemas sind also grundsätzlich eine Art Namensraum für Datenbankobjekte wie Tabellen, Sichten, gespeicherte Prozeduren et cetera. Der Zweck ist dabei, wie oben bereits erwähnt, die direkte Zuordnung von Windows-Benutzern oder -Benutzergruppen als Besitzer der Datenbankobjekte zu unterbrechen, da sonst, wenn der Benutzer oder die Benutzergruppe entfernt werden soll, die Besitzer aller betroffenen Datenbankobjekte geändert werden müssten.<\/p>\n
Wenn Sie hingegen mit Schemas arbeiten, erhalten Sie eine Zwischenschicht. Es gibt zwar nun immer noch einen Besitzer des Schemas, das wiederum die Datenbankobjekte enthält, aber Sie brauchen nur noch den Besitzer des Schemas zu wechseln, wenn Sie den alten Besitzer in Form eines Benutzers oder einer Benutzergruppe nicht mehr verwenden können.<\/p>\n
Mit einem Schema können Sie die Objekte einer Datenbank nach dem fachlichen Zusammenhang gruppieren oder auch nach den gewünschten Berechtigungen. Damit können wir, um beim Beispiel der Suedsturm_SQL<\/b>-Datenbank zu bleiben, etwa für die beiden Benutzergruppen Management <\/b>und Bestellannahme <\/b>zwei geeignete Schemas erstellen und diesen die relevanten Datenbankobjekte zuordnen.<\/p>\nSchemas für die Sicherheit<\/h2>\n
Außerdem können Sie natürlich auch Schemas einrichten, um über diese dann die Berechtigungen an den verschiedenen Elementen der Datenbank zu definieren. Die fachliche Gruppierung und die Gruppierung der Elemente nach Sicherheits- beziehungsweise Berechtigungsaspekten schließt sich ja nicht aus. Wenn Sie etwa, wie soeben vorgeschlagen, ein Schema namens Management und eines namens Bestellannahme erstellen, könnten Sie alle Elemente, die nur von den Mitarbeitern der Bestellannahme benötigt werden, im Kontext eines Schemas namens Bestellannahme <\/b>speichern. Die Elemente, auf welche die Mitarbeiter der Bestellannahme keinen Zugriff haben sollen, aber das Management, erstellen Sie im Kontext eines Schemas namens Management<\/b>. Wenn ein Mitarbeiter des Managements nun Zugriff nicht nur auf die Elemente des Schemas Management <\/b>haben soll, sondern auch auf die Elemente des Schemas Bestellannahme<\/b>, weisen Sie einen Windows-Benutzer einfach den Windows-Benutzergruppen Management <\/b>und Bestellannahme <\/b>zu.<\/p>\nAnlegen eines Schemas<\/h2>\n
Wir legen nun in unserer Beispieldatenbank Suedsturm_SQL <\/b>zunächst ein neues Schema namens Bestellannahme <\/b>an. Dazu navigieren Sie im Objekt-Explorer des SQL Server Management Studios zunächst zu dieser Datenbank und dann zum Eintrag Sicherheit|Schemas<\/b>. Wenn Sie diesen Eintrag öffnen, erkennen Sie, dass es dort schon eine Reihe vorgefertigter Schemas gibt, zum Beispiel db_accessadmin<\/b>, db_datareader<\/b>, db_datawriter <\/b>und so weiter (siehe Bild 1). Einige dieser Schemas können Sie auch entfernen, wenn Sie verhindern wollen, dass diese versehentlich für Benutzer festgelegt werden.<\/p>\n
![\"Schemas](\"..\/fileadmin\/_temp_\/2019_02\/pic_1179_001.png\")
<\/p>\n
Bild 1: Schemas im Objekt-Explorer<\/span><\/b><\/p>\n Klicken Sie nun mit der rechten Maustaste auf den Eintrag Schemas<\/b>, erscheint ein Kontextmenü, das unter anderem den Befehl Neues Schema… <\/b>anbietet. Damit öffnen Sie nun den Dialog zum Anlegen eines neuen Schemas namens Schema – Neu<\/b>. Hier geben Sie im Bereich Allgemein <\/b>nun zunächst den Namen des Schemas ein, also Bestellannahme<\/b>, und als Schemabesitzer dbo<\/b> (siehe Bild 2). Das bedeutet, dass der Besitzer des Schemas identisch ist mit dem Besitzer der Datenbank.<\/p>\n Bild 2: Anlegen eines neuen Schemas<\/span><\/b><\/p>\n Danach wechseln Sie zum Bereich Berechtigungen<\/b>. Hier finden Sie die Schaltfläche Suchen…<\/b>, mit der Sie einen weiteren Dialog namens Benutzer oder Rollen auswählen öffnen. Dieser bietet wiederum eine Schaltfläche namens Durchsuchen… <\/b>an, mit der Sie den Dialog Nach Objekten suchen <\/b>öffnen können. Hier werden alle Anmeldungen aufgeführt, die für den aktuellen SQL Server angelegt wurden (siehe auch Beitrag Berechtigungen für Access-Objekte per SQL Server III: Anwenden<\/b>, www.access-im-unternehmen.de\/1185<\/b>).<\/p>\n Darunter finden Sie auch die Anmeldung [ Bild 3: Auswählen der Benutzer des Schemas<\/span><\/b><\/p>\n Danach finden Sie im Dialog Schema – Neu <\/b>den gewählten Datenbankbenutzer, also die Gruppe Bestellannahme<\/b>, in der Liste der Benutzer oder Rollen<\/b>.<\/p>\n Im Bereich darunter werden die expliziten Berechtigungen für diese Anmeldung angezeigt. Aktuell sind noch keine Berechtigungen markiert, aber das holen wir nun nach – dazu setzen Sie einen Haken in der Spalte Erteilen für die folgenden Berechtigungen:<\/p>\n Vielleicht fällt Ihnen in der Liste noch der Eintrag ändern <\/b>auf, dies bezieht sich aber nicht auf das ändern von Daten – hierzu verwenden wir die Berechtigung Aktualisieren<\/b> (siehe Bild 4).<\/p>\n <\/p>\n Bild 4: Festlegen der Berechtigungen für das Schema Bestellannahme<\/span><\/b><\/p>\n Wenn Sie nun auf OK <\/b>klicken, wird das neue Schema angelegt, das dann auch gleich in der Liste der Schemas im Objekt-Explorer erscheint. Die Benutzer der Windows-Gruppe Bestellannahme<\/b>, die über die Anmeldung dem Schema zugeordnet wurden, können nun auf die Elemente dieses Schemas zugreifen. Wenn ein Windows-Benutzer als neuer Benutzer zu dieser Windows-Benutzergruppe hinzugefügt wird, kann er ebenfalls auf die Elemente des Schemas zugreifen.<\/p>\n Andersherum greifen die Mitglieder der Windows-Benutzergruppe Bestellannahme <\/b>automatisch auf alle Tabellen, Sichten, gespeicherte Prozeduren und andere Elemente zu, die im Kontext des Schemas erstellt werden. Bisher allerdings gehören noch keine Elemente zu diesem Schema, was wir auch kurz ausprobieren können.<\/p>\n Wenn die Datenbank Suedsturm_SQL <\/b>die Benutzergruppe Bestellannahme <\/b>bereits enthielt, müssen Sie diese alle Berechtigungen an der Datenbank Suedsturm_SQL <\/b>entziehen, also nicht nur die Berechtigungen, die im Dialog Datenbankbenutzer für die Anmeldung Bestellannahme <\/b>festgelegt waren, sondern auch die Mitgliedschaften in anderen Schemas wie db_datareader <\/b>oder db_datawriter<\/b>.<\/p>\n Wenn Sie sich im Kontext eines der Benutzer der Windowsgruppe Bestellannahme <\/b>wie etwa Harry Klein <\/b>den SQL Server Management Studio starten anmelden, sollte für diesen Benutzer zu diesem Zeitpunkt noch nicht einmal eine der Tabellen der Datenbank Suedsturm_SQL <\/b>zu sehen sein. Dies sollte sich erst ändern, wenn Sie dem Schema eine Tabelle hinzufügen. Der wichtige Unterschied gegenüber dem bisherigen Hinzufügen einer Tabelle ist, dass wir nun statt dbo <\/b>als Objektbesitzer den Namen des Schemas angeben, hier also Bestellannahme<\/b>:<\/p>\n Anschließend fügen wir noch ein paar Datensätze zu der neuen Tabelle hinzu:<\/p>\n Wenn wir nun wieder im Kontext des Benutzers Harry Klein <\/b>beziehungsweise der Benutzergruppe Bestellannahme <\/b>auf die Tabellen der Datenbank zugreifen, sollte die neue Tabelle dort im Objekt-Explorer erscheinen. <\/p>\n Und genau das ist der Fall: Es erscheint genau diese eine Tabelle und wir können auch im Kontext dieses Benutzers über das Schema auf die Daten dieser Tabelle zugreifen (siehe Bild 5).<\/p>\n Bild 5: Zugriff auf die Daten des Schemas<\/span><\/b><\/p>\n Wenn Sie Tabelle über den Tabellenentwurf anlegen wollen, geben Sie den Namen des Schemas über die Eigenschaft Schema<\/b> des Entwurfs an (siehe Bild 6).<\/p>\n Bild 6: Angabe des Schemas im Tabellenentwurf<\/span><\/b><\/p>\n Wir können nun einmal den umgekehrten Test machen und uns als Benutzer der Gruppe Management <\/b>anmelden. In diesem Fall dürften wir keine Berechtigungen an der neu erstellten Tabelle besitzen.<\/p>\n Mit Ausnahme des gegenwärtigen Zustands natürlich, bei dem diese SQL Server-Anmeldung für die Datenbank Suedsturm_SQL <\/b>immer noch den beiden Schemas db_datareader <\/b>und db_datawriter <\/b>zugeordnet ist.<\/p>\n Wenn wir diese beiden Schemas für diese Anmeldung entfernen, haben die Mitglieder der Windows-Benutzergruppe Management <\/b>erst einmal gar keine Zugriffsrechte auf die Tabellen der Datenbank – weder auf diejenigen, die unter dbo <\/b>angelegt wurden als auf die mit dem Schema Bestellannahme<\/b>.<\/p>\n Um Tabellen dem Schema Bestellannahme <\/b>zuzuordnen, damit die Mitglieder der Windows-Benutzergruppe Bestellannahme <\/b>auf Tabellen wie etwa tblBestellungen<\/b>, tblKunden<\/b>, tblArtikel <\/b>oder tblBestelldetails <\/b>zugreifen können, ist jeweils ein einfacher T-SQL-Befehl nötig.<\/p>\n Für die vier genannten Tabellen führen Sie etwa die folgenden vier Anweisungen in einer neuen Abfrage für die Datenbank Suedsturm_SQL <\/b>aus (für einen Benutzer mit Admin-Rechten):<\/p>\n Danach erscheinen diese Tabellen dann auch in einer Instanz des SQL Server Management Studios, das im Kontext eines Benutzers der Gruppe Bestellannahme <\/b>geöffnet wurde (siehe Bild 7).<\/p>\n Bild 7: Neue Tabellen für die Benutzergruppe Bestellannahme<\/span><\/b><\/p>\n Nach dieser Aktion können Sie im SQL Server Management Studio für den Admin-Benutzer sehen, dass die Tabellen dbo.tblArtikel<\/b>, dbo.tblBestelldetails <\/b>et cetera nun nicht mehr vorhanden sind und etwa durch Bestellannahme.tblArtikel <\/b>ersetzt wurden (siehe Bild 8).<\/p>\n Bild 8: Die Tabelle dbo.tblArtikel ist nicht mehr da.<\/span><\/b><\/p>\n Auch eventuell bestehende Verknüpfungen etwa von einer Access-Anwendung aus können nun nicht mehr auf die Daten der Tabelle unter dem alten Namen dbo.tblArtikel <\/b>oder tblArtikel <\/b>zugreifen (siehe Bild 9).<\/p>\n Bild 9: Auch die Verknüpfung von Access aus findet die Tabelle nicht mehr.<\/span><\/b><\/p>\n Wenn Sie das von uns in der Beispieldatenbank bereitgestellte Formular frmTabellenVerknuepfen <\/b>verwenden, können Sie die Tabelle tblArtikel <\/b>ohne Probleme erneut verknüpfen (siehe Bild 10). Dort wird die Tabelle ohne Angabe des Schemas angezeigt, was man aber ändern könnte. Auch wird der Tabellenname ohne Angabe des Schemas im Navigationsbereich angezeigt. Auch dies könnte man theoretisch noch ändern, aber solange Sie nicht mehrere Tabellen gleichen Namens verknüpfen wollen, spielt das Fehlen dieser Funktion keine Rolle. Sollte dies tatsächlich einmal der Fall sein, können Sie auch den in Access eingebauten Dialog zum Verwalten der Verknüpfungen nutzen.<\/p>\n Bild 10: Neuverknüpfung mit der Tabelle tblArtikel<\/span><\/b><\/p>\n Grundsätzlich ist es möglich, wie hier per ODBC verknüpfte Tabellen in Access zu nutzen. Daher macht es auch Sinn, dem Benutzer für solche Fälle Berechtigungen an den Tabellen einer Datenbank zu geben. Dadurch kann der Benutzer allerdings auch direkt in den verknüpften Tabellen die enthaltenen Daten bearbeiten. Das ist unter Umständen ja nicht gewünscht – und kann dadurch unterbinden werden, dass Sie den Zugriff auf die Daten nur über gespeicherte Prozeduren gewähren. Das gelingt natürlich nur, wenn kein Zugriff mehr per ODBC notwendig ist.<\/p>\n In diesem Fall würden gespeicherte Prozeduren über den Einsatz von Pass-Through-Abfragen sowohl dafür sorgen, die gewünschten Daten für die Anzeige in Formularen, Berichten und Steuerelementen wie Kombinationsfeldern und Listenfeldern anzuzeigen als auch geänderte Daten in die zugrunde liegenden Tabellen zurückzuschreiben. Das ist alles ein wenig aufwendiger zu programmieren als der Zugriff auf eine per ODBC verknüpfte Tabelle, aber definitiv sicherer.<\/p>\n Wie Sie gespeicherte Prozeduren in Zusammenhang mit Schemas nutzen, wollen wir Ihnen am Beispiel der Benutzergruppe Management <\/b>(und dem gleich daraus abgeleiteten Schema) sowie einer auf der Tabelle tblMitarbeiter <\/b>basierenden gespeicherten Prozedur zeigen.<\/p>\n Bevor wir das Schema erstellen, stellen wir für die Anmeldung Wenn Sie diese änderung als Datenbankbesitzer durchgeführt haben und dann versuchen, im Kontext etwas des Benutzers Peter Gross <\/b>der Gruppe Management <\/b>auf die Tabellen, Sichten oder gespeicherte Prozeduren zuzugreifen, sollten Sie überall leere Listen vorfinden.<\/p>\n Als Erstes erstellen wir das Schema, in dessen Kontext wir die Elemente der Datenbank erstellen beziehungsweise umwandeln wollen, die nur für die Benutzergruppe Management<\/b> zugänglich sein sollen. Dazu erstellen wir zunächst ein neues Schema namens Management<\/b>.<\/p>\n Diesem fügen Sie wieder eine SQL Server-Anmeldung hinzu, und zwar Bild 11: SQL-Anmeldung für die Gruppe Management<\/span><\/b><\/p>\n Auch wenn wir nun im Kontext eines Benutzers der Gruppe Management <\/b>versuchen, die gespeicherten Prozeduren anzuzeigen, die ja nun, nachdem wir über das Schema die Ausführen<\/b>-Berechtigung für diese Gruppe definiert haben, wieder darauf zugreifen können sollten, gelingt das nicht. Kein Wunder – wir haben ein Detail vergessen: Es gibt noch keine gespeicherte Prozedur, die wir dem Schema Management <\/b>zugeordnet haben.<\/p>\n Also erstellen wir eine neue gespeicherte Prozedur, die alle Datensätze der Tabelle tblPersonal <\/b>zurückliefern soll. Diese legen wir mit dem folgenden Skript an:<\/p>\n Wichtig ist hier, dass wir wieder das Schema angeben, in dessen Kontext wir die gespeicherte Prozedur erstellen wollen, also Management<\/b>. Damit können wir die gespeicherte Prozedur dann auch erfolgreich ausführen (siehe Bild 12). Und danach folgt eine interessante Frage: Was geschieht mit dem Schema der Tabelle tblPersonal<\/b> Sie können diese auch dem Schema Management <\/b>zuweisen. Dann müssten Sie die gespeicherte Prozedur auch entsprechend ändern – und alle anderen Elemente, die auf diese Tabelle zugreifen.<\/p>\n Bild 12: Ausführen einer gespeicherten Prozedur im Kontext der Benutzergruppe Management<\/span><\/b><\/p>\n Ob Sie die Schemas verwenden oder nicht, bleibt Ihnen überlassen – das Berechtigungssystem funktioniert mit und ohne Schemas. Auch bleibt Ihnen überlassen, in welcher Art und Weise Sie das Schema gestalten. Wie immer gilt: Halten Sie es so einfach wie möglich.<\/p>\n Zusammenfassend noch einmal die Vergabe der Berechtigung vom Benutzer zum Datenbankobjekt: Der Windows-Benutzer gehört einer Windows-Benutzergruppe an. Die Windows-Benutzergruppe wird als Anmeldung am SQL Server angegeben. Die Anmeldung wird als Benutzer zur Datenbank hinzugefügt. Die Schemas legen Berechtigungen für die Benutzer fest. Die Berechtigungen der Schemas gelten für die in deren Kontext erstellten oder die ihnen zugewiesenen Elemente wie Tabellen, Sichten oder gespeicherte Prozeduren.<\/p>\n","protected":false},"excerpt":{"rendered":" Die älteren SQL Server-Versionen haben einen Nachteil: Sie benötigen hier einen Benutzer, dem eine neu erstellte Datenbank gehört. Genauso gibt es auch für alle weiteren Objekte wie Tabellen, Sichten, gespeicherte Prozeduren und so weiter einen Besitzer – nämlich den Benutzer, der das Objekt erstellt hat. Meist legt man diese Elemente im Kontext eines Windows-Benutzers an, was zum Beispiel dazu führt, dass Sie diesen Benutzer nicht einfach löschen können, ohne zuvor alle Elemente dieses Benutzers an einen anderen Benutzer übertragen zu haben. Aus diesem Grund hat Microsoft mit SQL Server 2005 den Typ namens „Schema“ eingeführt. Diesem werden nun nicht nur neu erstellte Objekte zugeordnet, sondern Sie können auch mehrere Schemas pro Datenbank verwenden, um beispielsweise Elemente nach verschiedenen Gruppen zu sortieren.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[66022019,662019,44000022],"tags":[],"class_list":["post-55001179","post","type-post","status-publish","format-standard","hentry","category-66022019","category-662019","category-SQL_Server_und_Co"],"yoast_head":"\n![\"Anlegen](\"..\/fileadmin\/_temp_\/2019_02\/pic_1179_002.png\")
<\/p>\n![\"Auswählen](\"..\/fileadmin\/_temp_\/2019_02\/pic_1179_003.png\")
<\/p>\n\n
![\"Festlegen](\"..\/fileadmin\/_temp_\/2019_02\/pic_1179_004.png\")
<\/p>\nObjekte zu Schema hinzufügen<\/h2>\n
CREATE TABLE Bestellannahme.tblTest\r\n(\r\n TestID int IDENTITY(1,1) PRIMARY KEY,\r\n Testfeld nvarchar(max)\r\n)<\/pre>\n
INSERT INTO Bestellannahme.tblTest(Testfeld)\r\nVALUES(''''Test1''''), (''''Test2''''), (''''Test3'''')<\/pre>\n![\"Zugriff](\"..\/fileadmin\/_temp_\/2019_02\/pic_1179_005.png\")
<\/p>\n![\"Angabe](\"..\/fileadmin\/_temp_\/2019_02\/pic_1179_006.png\")
<\/p>\nTabellen dem Schema Bestellannahme zuordnen<\/h2>\n
ALTER SCHEMA Bestellannahme TRANSFER dbo.tblArtikel;\r\nALTER SCHEMA Bestellannahme TRANSFER dbo.tblBestellungen;\r\nALTER SCHEMA Bestellannahme TRANSFER dbo.tblKunden;\r\nALTER SCHEMA Bestellannahme TRANSFER dbo.tblBestelldetails;<\/pre>\n
![\"Neue](\"..\/fileadmin\/_temp_\/2019_02\/pic_1179_007.png\")
<\/p>\n![\"Die](\"..\/fileadmin\/_temp_\/2019_02\/pic_1179_008.png\")
<\/p>\n![\"Auch](\"..\/fileadmin\/_temp_\/2019_02\/pic_1179_009.png\")
<\/p>\n![\"Neuverknüpfung](\"..\/fileadmin\/_temp_\/2019_02\/pic_1179_010.png\")
<\/p>\nSchemas und gespeicherte Prozeduren<\/h2>\n
Schema für das Management erstellen<\/h2>\n
![\"SQL-Anmeldung](\"..\/fileadmin\/_temp_\/2019_02\/pic_1179_011.png\")
<\/p>\nGespeicherte Prozedur erstellen<\/h2>\n
CREATE PROCEDURE Management.spPersonal \r\nAS\r\nSELECT * FROM dbo.tblPersonal<\/pre>\n
![\"Ausführen](\"..\/fileadmin\/_temp_\/2019_02\/pic_1179_012.png\")
<\/p>\nZusammenfassung und Ausblick<\/h2>\n