Informationen zur Anwendung

Der Skriptcontent auf dieser Seite ist ausschließlich für Navigationszwecke vorgesehen und bewirkt keinerlei Änderung des Contents.

Die Anwendung hat die folgenden Zweck-, Struktur- und Benennungskonventionen.

Zweck der Anwendung

Die Anwendung ist für zwei Arten von Benutzern in einem Unternehmen bestimmt.

• Typische Benutzer (Manager von Mitarbeitern)

• Anwendungsadministratoren

Typische Benutzer können die folgenden Aufgaben ausführen:

• Mitarbeiter in einer bestimmten Abteilung abrufen

• Jobhistorie für einen bestimmten Mitarbeiter abrufen

• Allgemeine Informationen für einen bestimmten Mitarbeiter anzeigen (Name, Abteilung, Tätigkeit, Manager, Gehalt usw.)

• Gehalt eines bestimmten Mitarbeiters ändern

• Tätigkeit eines bestimmten Mitarbeiters ändern

Anwendungsadministratoren können die folgenden Aufgaben ausführen:

• ID, Titel oder Gehaltsbereich einer vorhandenen Tätigkeit ändern

• Neuen Job hinzufügen

• ID, Name oder Manager einer bestehenden Abteilung ändern

• Neue Abteilung hinzufügen

Struktur der Anwendung

Die Anwendung verwendet die folgenden Schemaobjekte und Schemas.

Schemaobjekte der Anwendung

Die Anwendung besteht aus den folgenden Schemaobjekten:

• Vier Tabellen, in denen Daten zu folgenden Themen gespeichert werden:

  • Jobs

  • Abteilungen

  • Mitarbeiter

  • Tätigkeitshistorie der Mitarbeiter

• Vier Editionsansichten, die sich auf die Tabellen beziehen, sodass Sie die fertige Anwendung bei Verwendung mit einer Editions-basierten Neudefinition (EBR) aktualisieren können

• Zwei Trigger, die Geschäftsregeln durchsetzen

• Zwei Sequenzen, die eindeutige Primärschlüssel für neue Abteilungen und neue Mitarbeiter generieren

• Zwei Pakete.

  • employees_pkg, die Anwendungsprogrammschnittstelle (API) für typische Benutzer

  • admin_pkg, die API für Anwendungsadministratoren

  Die typischen Benutzer und Anwendungsadministratoren greifen nur über ihre APIs auf die Anwendung zu. Daher können sie die Daten nur ändern, indem sie Packageunterprogramme aufrufen.

Siehe:

• "Informationen zu Oracle AI Database" für Informationen zu Schemaobjekten

• Oracle AI Database Development Guide für Informationen zu EBR

Schemas für die Anwendung

Aus Sicherheitsgründen verwendet die Anwendung die folgenden fünf Schemas (oder Benutzer), von denen jedes nur über die erforderlichen Berechtigungen verfügt.

• Das Schema app_data, das Eigentümer aller Schemaobjekte mit Ausnahme der Packages ist und dessen Tabellen mit Daten aus Tabellen im Beispielschema hr lädt.

  Die Entwickler, die Packages erstellen, funktionieren nie in diesem Schema. Daher können sie Anwendungsschemaobjekte nicht versehentlich ändern oder löschen.

• Das Schema app_code, das nur Eigentümer des Packages employees_pkg ist.

  Die Entwickler des Packages employees_pkg arbeiten in diesem Schema.

• Das Schema app_admin, das nur Eigentümer des Packages admin_pkg ist.

  Die Entwickler des Packages admin_pkg arbeiten in diesem Schema.

• Der Benutzer app_user, der typische Anwendungsbenutzer, der Eigentümer von nichts ist und nur das Package employees_pkg ausführen kann.

  Der Middle Tier-Anwendungsserver meldet sich als Benutzer app_user bei der Datenbank im Verbindungspool an. Wenn dieses Schema kompromittiert ist (z.B. durch einen SQL-Injection-Bug), kann der Angreifer nur das sehen und ändern, was die employees_pkg-Packageunterprogramme anzeigen und ändern. Der Angreifer kann keine Tabellen löschen, Berechtigungen eskalieren, Schemaobjekte erstellen oder ändern oder irgendetwas anderes.

• Der Benutzer app_admin_user, ein Anwendungsadministrator, der Eigentümer von nichts ist und nur die Packages admin_pkg und employees_pkg ausführen kann.

  Der Verbindungspool für dieses Schema ist sehr klein, und nur berechtigte Benutzer können darauf zugreifen. Wenn dieses Schema kompromittiert ist, kann der Angreifer nur sehen und ändern, welche admin_pkg- und employees_pkg-Packageunterprogramme es anzeigen und ändern.

Angenommen, die Anwendung hatte anstelle der Benutzer app_user und app_admin_user nur ein Schema, das Eigentümer von nichts war und sowohl die Packages employees_pkg als auch admin_pkg ausführen konnte. Der Connection Pool für dieses Schema muss groß genug für die typischen Benutzer und die Anwendungsadministratoren sein. Wenn ein SQL-Injection-Bug im employees_pkg-Package vorhanden war, konnte ein typischer Benutzer, der diesen Bug ausnutzte, auf das admin_pkg-Package zugreifen.

Angenommen, die Anwendung hatte anstelle der Schemas app_data, app_code und app_admin nur ein Schema, das Eigentümer aller Schemaobjekte war, einschließlich der Packages. Die Packages hätten dann alle Berechtigungen für die Tabellen, was unnötig und unerwünscht wäre.

Beispiel: Sie haben eine Audittrailtabelle, AUDIT_TRAIL. Sie möchten, dass die Entwickler des Packages employees_pkg in die Tabelle AUDIT_TRAIL schreiben, sie jedoch nicht lesen oder ändern können. Sie möchten, dass die Entwickler des Packages admin_pkg die Tabelle AUDIT_TRAIL lesen und in sie schreiben können, sie jedoch nicht ändern. Wenn die Packages AUDIT_TRAIL und employees_pkg und admin_pkg zu demselben Schema gehören, verfügen die Entwickler der beiden Packages über alle Berechtigungen für die Tabelle AUDIT_TRAIL. Wenn die Tabelle AUDIT_TRAIL jedoch zum Schema app_data gehört, das Package employees_pkg zum Schema app_code gehört und das Package admin_pkg zum Schema app_admin gehört, können Sie eine Verbindung zur Datenbank als Schema app_data herstellen und die folgenden Befehle ausführen:

GRANT INSERT ON AUDIT_TRAIL TO app_code;
GRANT INSERT, SELECT ON AUDIT_TRAIL TO app_admin;

Siehe:

• Informationen zu Oracle AI Database für Informationen zu Schemas
• Info zum Beispielschema HR für Informationen zum Beispielschema HR
• Empfohlene Sicherheitsverfahren

Benennungskonventionen in der Anwendung

Die Anwendung verwendet diese Benennungskonventionen.

Element	Name
Tabelle	Tabellen-Nr.
Editionsansicht für Tabelle#	Tabelle
Trigger für Editionierungsansicht der Tabelle	table_{a|b}event[_fer] wobei: einen AFTER-Trigger kennzeichnet. b identifiziert einen BEFORE-Trigger. fer identifiziert einen FOR EACH ROW Trigger. event gibt das Ereignis an, das den Trigger auslöst. Beispiel: i für INSERT, iu für INSERT oder UPDATE, d für DELETE.
PRIMARY KEY-Constraint in Tabelle#	table_pk
NOT NULL-Constraint für table#.column	table_column_not_null1
UNIQUE-Constraint für table#.column	table_column_unique1
CHECK-Constraint in table#.column	table_column_check1
REF-Constraint auf table1#.column in table2#.column	table1_to_table2_fk1
REF-Constraint auf table1#.column1 zu table2#.column2	table1_col1totable2_col2_fk12
Folge für Tabellenr.	table_sequence
Parametername	p_Name
Lokaler Variablennamen	l_Name

1. table, table1 und table2 sind abgekürzt mit emp für Mitarbeiter, dept für Abteilungen und job_hist für job_history. ↩ ↩² ↩³ ↩⁴ ↩⁵

2. col1 und col2 sind Abkürzungen der Spaltennamen column1 und column2. Ein Constraint-Name darf nicht mehr als 30 Zeichen enthalten. ↩