Skip to main content
Skip table of contents

3.4. Rechte und Rollen in der OCT Datenbank

Diese Inhalte adressieren Benutzer mit grundlegenen Kenntnissen über SQL Server und Datenbankrollen.


OCT besitzt ein sehr gut dokumentiertes Datenbankmodell, diese besteht aus

  • dem Core Teil - in allen Datenbanken identisch enthalten

  • dem / den Modul Teile(n) - zusätzlichen Datenbankobjekten, welche OCT Module mitbringen

Alle OCT Datenbanken einer Version sind somit im Kern identisch, können aber mit zusätzlichen Datenbankobjekten von Modulen erweitert sein.

Alle Datenbankobjekte liegen in einem passenden Schema, das Schema “system” ist besonders geschützt.

Für den Betrieb von OCT sind zwei Datenbankrollen vorhanden

  • db_owner - das ist eine Standardrolle, welche alle Rechte in der Datenbank besitzt (aber nicht auf dem Datenbankserver (!), dort ist es der sysadmin)

  • pf_PlanningFactoryService - eine OCT spezfische Rolle, die alle operativen Prozesse in der Datenbank durchführen kann (der Name ist noch historisch bedingt und wird ab v6 angepasst)

Die Rolle pf_PlanningFactoryService ist Besitzer aller Schemas, außer dem Schema “system”. Die Objekte im Schema dbo besitzt die Rolle pf_PlanningFactoryService ebenfalls.

Die Applikation OCT erhält das Recht mit der Rolle pf_PlanningFactoryService in der Datenbank zu arbeiten. Die Rolle dbo wird nur von Personen genutzt, welche die Datenbank erstellen, updaten oder an Kundenwünsche anpassen. Die Applikation OCT arbeitet somit aus Sicherheitsgründen nur mit eingeschränkten Rechten in der Datenbank.

Für den Betrieb von OCT sind nie mehr als diese beiden Rollen notwendig und es gelten die Grundsätze:

  • Das Benutzerkonto der Applikation OCT sollte immer die Rolle pf_planningFactoryService erhalten um auf die Datenbank zuzugreifen (nicht die Rolle db_owner - funktioniert, ist aber unklug)

  • Ein Anwender von OCT benötigt NIE direkten Zugriff auf die Datenbank.

  • Ein Anwender von OCT benötigt somit NIE eine Datenbankrolle.

  • Ein Entwickler für OCT darf NIE neue Objekte im Schema system anlegen oder die dortigen ändern


1. Entwicklung von Applikationsobjekten für die OCT Datenbank

Ein Entwickler (ein Mitarbeiter von Saxess oder ein fortgeschrittener und geschulter Anwender) kann in der Datenbank Objekte anlegen, welche von der Applikation genutzt werden. Das sind typischerweise

  • Prozeduren, die Pivottabellen/Datagrids in einem Tab mit Daten beliefern

  • Prozeduren, die per Pipeline regelmäßig ausgeführt werden werden sollen

Diese Objekte werden vom Entwickler erstellt (er arbeitet mit der Rolle db_owner). OCT kann diese sofort, ohne spezielle Berechtigung verwenden, da die OCT zugeordnete Rolle pf_PlanningFactoryService alle Schemas besitzt (außer dem system Schema, von dem wir ja hier sowieso die Finger lassen). Der Entwickler sollte nie Objekte im Schema dbo erstellen.


2. Entwicklung von Datenbankobjekten für externe Verwendung

In der OCT Datenbank können Datenbankobjekte erstellt werden, die nicht (nur) von der Applikation OCT genutzt werden, sondern auch von dritten Applikationen. Das sind typischerweise

  • Prozeduren / Views / Tabellen die von Excel aus (z.B. als Pivotauswertung) genutzt werden sollen und Daten aus der OCT Datenbank holen

  • Prozeduren / Views / Tabellen die eine Controllingapplikation (z.B. Corporate Planner) nutzen soll, um Daten aus der OCT Datenbank zu holen

Diese Objekte werden vom Entwickler erstellt (er arbeitet mit der Rolle db_owner) und immer im Schema result angelegt. Diese werden für den externen User berechtigt. Damit dies funktioniert, benötigt man

  • einen Datenbankbenutzer für den externen User (damit er sich verbinden kann)

  • eine direkte Berechtigung oder die Zuordnung des Users zu einer Datenbankrolle

Der User darf keiner der beiden vorhandenen Rollen (db_owner / pf_PlanningFactoryService) zugeordnet werden, da diese viel zu umfangreiche Rechte gewähren. Es sollte ein eigene Datenbank Rolle mit Bezug zum Kundennamen angelegt werden, z.B. “Sardinenfabrik_ReportingUser”. Danach wird

  • dieser Role das Recht gegeben die geschaffenen Prozeduren etc. auszuführen (GRANT EXECUTE ON OBJECT :: result.spTollerReport TO Sardinenfabrik_ReportingUser)

  • die Datenbankbenutzer werden dieser Rolle zugeordnet (und keiner anderen weiter - die Rolle public hat er ohnehin immer schon unveränderlich)

Es braucht nicht für jede berechtigete Person ein Datenbankbenutzer angelegt werden, man kann auch eine Windows Gruppe anlegen, alle User dieser zuordnen und dann nur diese Windowsgruppe berechtigen.

Jeder User kann sich ab jetzt von Excel, PowerBI etc. zur Datenbank verbinden.


3. Interne Rechte beim externen Abruf umsetzen

Jeder OCT Benutzer hat in OCT gewisse Rechte, darf beispielsweise nur auf eine Factory zugreifen.

Werden die OCT Daten von extern ausgelesen, greifen diese einschränkenden Rechte nur, sofern sie im Datenbankobjekt implementiert wurden.

Die Prozedur oder der View müssen dafür die Tabelle system.trUserRights (definiert die Rechte pro User und Factory / Productline) per INNER JOIN mit den Abrufdaten verbinden und auf den Benutzernamen filtern.

Damit dieser JOIN möglich ist, muss der exteren Benutzer zum lesen dieser Tabelle berechtigt werden (GRANT SELECT ON system.trUserRights TO Sardinenfabrik_Reportinguser).


4. Sonstiges

In der OCT wird der aufmerksame Beobachter noch eine weitere Rolle pf_PlanningFactoryUser finden. Diese Rolle ist für einen früher intensiv genutzten Excel Client aus Kompatibilitätsgründen noch vorhanden, ab v6 wird diese entfallen. Diese Rolle sollte verwendet werden, da diese dem Benutzer zu viele Rechte gewährt.


5. Mehr dazu lernen

Um die Gründe für die hier genannten Regeln zu verstehen, sollten Sie sich in der SQL Server Literatur informieren über

  • Objektbesitz und Datenbankbesitz

  • Besitzketten

  • den Unterschied zwischen dem User “dbo” und der Rolle “db_owner”

  • den Unterschied zwischen einem User und einem Login

Dieses Buch sollten Sie lesen https://www.amazon.de/T-SQL-Fundamentals-Itzik-Ben-Gan/dp/150930200X, der Autor Itzik Ben-Gan ist der beste uns bekannte für präzise und sehr gut verständliche SQL Server Literatur. Danach schauen Sie dann mal auf diese https://www.sommarskog.se/ auf den ersten Blick unscheinbare Seite, dort finden Sie weitere tiefgründige Erklärungen, die gut verdaubar sind.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.