Veraltete Dokumentation: Administration des GTDS (DB in NT-Umgebung)

(Stand: Januar 2000)


Inhaltsübersicht

A. Installation der Datenbank
B. Einmalige Tätigkeiten als Benutzer System
C. Einmalige Tätigkeiten als Benutzer ops$tumsys
D. wiederholende Tätigkeiten als ops$tumsys (GTDS-Administrierung)
E. Einrichtung eines neuen Arbeitsplatzes für das graphische GTDS

Anhang 1: Rollenkonzeption
Anhang 2: Anwendung administration
Anhang 3: Kommentar
Anhang 4: GTDS-Schlüssel-Tabellen
Anhang 5: Sonstiges
Anhang 6: GTDS-Tabellen, die samt Inhalt im ops$tumsys-Schema vorliegen müssen
Anhang 7: Typisierung der GTDS-Tabellen (nach Verwaltung, Klassifikation und Sonstige)


A. Installation der Datenbank 1.)    Installation des Workgroup-Servers mit dem Oracle Installer

2.)    Einrichten eines SQLNET-Alias mit easy config. Dies kann i.d.R. auch zu einem späteren Zeitpunkt erfolgen. Es scheint so zu sein, daß wenn ein Oracle-Dienst vorhanden ist, Clientprogramme ohne Angabe einer Datenbankidentifkation beim Einloggen funktionieren.

3.)    Starten der Instanz mit svrmgr23 (connect internal/<passwd>@alias)´

4.)    Variation von Datenbankparmetern in init<alias>.ora (insbes. Shared_pool_size auf 3500000 und open_cursors auf 255 setzen [es ist möglich, daß noch kein Parameter open_cursor eingetragen ist])

5.)    Kontrolle der Parameter von svrmgr23 mit "show parameters" oder "select * from v$sgastat".


B. Einmalige Tätigkeiten als Benutzer System 1.) Anlegen des Benutzers ops$tumsys und seiner Privilegien (Rolle r_super, dba). Hierzu Ausführen folgender Statements aus SQL*Plus :

REM Anlegen Rolle r_super
create role r_super;

REM Fuellen von r_super
grant create session to r_super with admin option;
grant create public synonym, create role, create tablespace, alter tablespace, create user, drop user, alter user, create view
to r_super;

REM Anlegen des Benutzers ops$tumsys
create user ops$tumsys identified by abc ;

REM Rollenzuweisung für Benutzer ops$tumsys
grant resource to ops$tumsys;
grant imp_full_database to ops$tumsys;
grant r_super to ops$tumsys;

2.) Anlegen des Benutzers ops$beispiel und seiner Privilegien. Hierzu Ausführen folgender Statements aus SQL*Plus :

REM beispielbenutzer zu Demonstrations und uebezwecken sinnvoll
REM Anlegen des Benutzers beispiel
create user beispiel identified by beispiel;

REM Rollenzuweisung für Benutzer beispiel
grant create session , create view, resource to beispiel;

3.) Anlegen der Tablespaces gtds und Deklaration des Tablespaces gtds als Default-Tablespace derBenutzer ops$tumsys und beispiel mit folgenden SQL*Plus - Befehlen :

4.) Anlegen der GTDS-Tabellen für den Beispielbenutzer und Ops$Tumsys mittels eines aktuellen Importes aus dem Beispiel-Schema der Giessener ora7a Datenbank. Diese Dmp-Datei sollte unter Zuhilfename der MSDOS-Batchdatei import.bat und des Sql-Skriptes del_trigger.txt importiert und überarbeitet werden. Eine Beschreibung steht in der Datei importreadme.txt. Alle genannten Dateien befinden sich im Verzeichnis /gtds/admin/batch.


C. Einmalige Tätigkeiten als Benutzer ops$tumsys Anlegen der Rollen für die GTDS-Benutzer mit folgenden SQL*Plus-Befehlen.


D. Wiederholende Tätigkeiten als ops$tumsys (GTDS-Administrierung) Wiederholende Tätigkeiten werden in der Regel über die NT-Administrationsoberfläche (ntadmin.fmx) ausgeführt.

1.) Anlegen eines neuen Benutzers

Creierung des Benutzers und Zuweisung der unten genannten Rollen (nach Wunsch) über ntadmin.fmx.
Nach Angabe von Benutzernamen und Passwort erlaubt diese den Aufruf des Sql-Skriptes new_user.sql, die den Benutzer anlegt und die Systemtabelle benutzer belegt.

2.) Zuweisung der gewünschten Rollen an einen GTDS-Benutzer

Die Anwendung ntadmin.fmx erlaubt,
- die Festlegung, welche Rollen der Benutzer besitzen soll und
- die anschliessende Generierung und Ausführung eines entsprechenden Sql-Skriptes.

Die zur Verfügung stehenden Rollen sind in Anhang 1 aufgeführt.

Ein generiertes Sql-Skript kann beispielsweise folgendermaßen aussehen :

Eine Kontrolle der vorhandenen Benutzer und deren Privilegien und Objekte kann über die Formsanwendung privileg.fmb (zu starten als system) oder über eines der mit der Oracle-Datenbank mitgelieferten Verwaltungsprogrammen erfolgen. Letzeres wird aufgrund der umfassenderen Möglichkeiten empfohlen.
 

3.)     Neugeneration von Rollen und Public Synonymen

Die Anwendung ntadmin.fmx erlaubt die Neugeneration der Rollen

Eine Neugeneration ist nach Creieren von neuen Tabellen sinnvoll.


E. Einrichtung eines neuen Arbeitsplatzes für das graphische GTDS

Diese Tätigkeit ist nicht nur auf Umgebungen beschränkt, in denen die Datenbank unter NT läuft.


Anhang 1: Rollenkonzeption
 

Rollenname Beschreibung Inhalt
r_super Rolle mit sämtlichen Systemprivilegien für den Benutzer OPS$TUMSYS. Sie wird bei der Installation von SYSTEM angelegt und OPS$TUMSYS zugewiesen. 

("super" für "GTDS-Administrator")

grant create session, to r_tumsys with admin option;
r_normal_sys Rolle mit sämtlichen Systemprivilegien für die späteren normalen Benutzer. Sie wird nach Benutzeranlegung von OPS$TUMSYS dem Benutzer zugewiesen. Soll ein Benutzer vom Betrieb ausgeschlossen werden, so wird ihm diese Rolle einfach wieder weggenommen. 

("normal" für "normaler GTDS-Benutzer")

Create session to r_normal_sys 

grant create public synonym, drop public synonym, create role, drop role, create tablespace, alter tablespace, create user, drop user, alter user, drop table, create view, drop view to r_super;

r_normal_obj_s Rolle mit Objektprivilegien zum Lesen aller OPS$TUMSYS-Objekte (Tabellen, Views, Sequences). Wird vom Benutzer OPS$TUMSYS standardmäßig allen Benutzern zugewiesen. Diese Rolle existiert, da es Benutzer gibt, die ausschliesslich Leserechte auf Tabellen haben sollen. 

("s" für "select")

Bsp. grant select on ops$tumsys.tumor to r_normal_obj_s;
r_normal_obj_du_meist Rolle wie obige Rolle. Unterschied ist, daß keine verändernen Rechte auf die Tabellen benutzer, erteilt_zugriff, systemweite_parameter ...) enthalten sind. Welche die auszuschliessenden Tabellen sind, wird in einer speziellen Systemtabelle festgelegt. Durch diese Rolle ermöglichen von dokumentierenden Benutzern, die keine Veränderungsmöglichkeiten auf bestimmte Tabellen haben. (Neu Januar 2000) Weiterhin enthält diese Rolle die execute-grants für distributierte functions, procedures and packages. 

("d" für "delete", "u" für "update","meist" für "meisten (nicht alle) Tabellen")

Bsp. grant delete, update on ops$tumsys.tumor to r_normal_obj_du_alle;
r_normal_obj_du_klassi Rolle, die verändernden Zugriff auf Schluesseltabellen erlaubt (vgl. Bem2)  
r_normal_obj_du_verwalt Rolle, die verändernden Zugriff auf Verwaltungstabellen erlaubt (vgl. Bem2)  
r_normal_obj_du_sonst Rolle, die verändernden auf sonstige Tabellen erlaubt (Rolle aus Gründen der Flexibilität) (vgl. Bem2)  

Bemerkung 1: Durch diese Rollenkonzeption soll es möglich werden, die Vorteile des Rollenkonzept (einfaches Benutzermanagement) bei gleichzeitiger Erhaltung der folgenden Möglichkeiten

zu nutzen.

Bemerkung 2: Welche Tabellen als Klassifikations-, Verwaltungs- oder sonstige Tabellen eingestuft sind, ist in der Tabelle spezial_tabelle definiert. NT-Admin erlaubt die Pflege dieser Tabelle. Im Unterverzeichnis admin befindet sich ein dmp, der es ihnen erlaubt - falls die Tabelle nicht ordungsgerecht vorhanden sein sollte- die Tabelle (gefüllt) anzulegen.


Anhang 2: Anwendung administration Bildschirmkopie


Anhang 3: Kommentar zur Verwendung von "Rollen" Das Rollenkonzept ermöglicht eine praktikable Ausschöpfung des Rechtekonzeptes. Hierdurch wird sichergestellt, daß Benutzer nur erlaubte Aktionen durchführen. Hierdurch werden die Stabilität des gesamten Systems, aber auch Datenschutzaspekte sichergestellt. In Zukunft könnte eine Datenbankintegrierte Überwachung der Zugriffe auf Abteilungsniveau durch entsprechende Viewdefinitionen realisiert werden. Diese führen jedoch zu einem erhöhten Administrationsaufwand und belasten die Performance des Systems.


Anhang 4: GTDS-Schlüssel-Tabellen

Bem. Die Datei gtds/admin/batch/systabl.par enthält die aktuelle Liste der Tabellen, deren inhalt beim import mit übernommen werden muß. (Stand 14.01.2000)


Anhang 5: Sonstiges


 Anhang 6: GTDS-Tabellen, die samt Inhalt im ops$tumsys-Schema vorliegen müssen (bitte ständig nachpflegen...) histologie_schluessel,
lokalisation_schluessel,
operationsschluess,
opschluessel,
tnm_region,
tnm_level,
folge_komp_schluessel,
folge_art,
folge_unterkategorie,
icd,
pro,
histologie_lokalisation,
merkmal,
zielgebiet_schluessel,
lz,
t_kategorie,
n_kategorie,
m_kategorie,
who_nebenwirkung,
who_nebenwirkung_g,
klassifikation,
stadieneinteilung,
tumor_entitaet,
entitaet_beschreibung,
txt,
systemweite_parameter


Anhang 7: Typisierung der GTDS-Tabellen (nach Verwaltung, Klassifikation und Sonstige)

Typisierung der GTDS-Tabellen (Stand 14.1.2000)
=====================================

klassifikation
alle tabellen, die zentral in Giessen gepflegt werden

verwaltung
alle tabellen, in denen zugriffsrechte verwaltet werden

sonstige
alle pflegetabellen, deren bearbeitung spezieller anleitung bedarf
 

Bem. in der Verwaltungsoberfläche kann diese Einteilung gepflegt werden. Sie beeinflußt die Generierung der folgenden Rollen :
r_normal_obj_du_meist, r_normal_obj_du_klassi, r_normal_obj_du_verwalt und r_normal_obj_du_sonstige.