A propos de l'application

Le contenu du script de cette page a pour seul objectif la navigation et n'altère en rien le contenu.

L'application possède les conventions de finalité, de structure et de dénomination suivantes.

Rôle de l'application

L'application est destinée à deux types d'utilisateurs dans une entreprise.

• Utilisateurs standard (responsables des employés)

• Administrateurs d'application

Les utilisateurs standard peuvent effectuer les tâches suivantes :

• Obtenir les employés d'un service donné

• Obtenir l'historique de l'emploi pour un employé donné

• Afficher les informations générales d'un employé donné (nom, service, fonction, responsable, salaire, etc.)

• Modifier le salaire d'un employé donné

• Modifier le poste d'un employé donné

Les administrateurs d'application peuvent effectuer les tâches suivantes :

• Modifier le code, l'intitulé ou la fourchette de salaires d'un emploi existant

• Ajouter un nouveau travail

• Modifier l'ID, le nom ou le responsable d'un service existant

• Ajouter un nouveau service

Structure de l'application

L'application utilise les schémas et objets de schéma suivants.

Objets de schéma de l'application

L'application est composée des objets de schéma suivants :

• Quatre tables qui stockent les données relatives aux éléments suivants :

  • jobs

  • Departments

  • Employés

  • Historique des emplois des employés

• Quatre vues d'édition, qui couvrent les tables, vous permettant d'utiliser la redéfinition basée sur l'édition (EBR) pour mettre à niveau l'application terminée lorsqu'elle est utilisée

• Deux déclencheurs qui appliquent des règles métier

• Deux séquences qui génèrent des clés primaires uniques pour les nouveaux services et les nouveaux employés

• Deux packages.

  • employees_pkg, l'interface de programme d'application (API) pour les utilisateurs standard

  • admin_pkg, l'API pour les administrateurs d'application

  Les utilisateurs standard et les administrateurs d'application accèdent à l'application uniquement via ses API. Par conséquent, ils ne peuvent modifier les données qu'en appelant des sous-programmes de package.

Voir aussi :

• "A propos d'Oracle AI Database" pour plus d'informations sur les objets de schéma

• Guide de développement Oracle AI Database pour plus d'informations sur EBR

Schémas de l'application

Pour des raisons de sécurité, l'application utilise les cinq schémas (ou utilisateurs) suivants, dont chacun dispose uniquement des privilèges dont il a besoin.

• Schéma app_data, propriétaire de tous les objets de schéma à l'exception des packages, et charge ses tables avec les données des tables du schéma échantillon hr.

  Les développeurs qui créent les packages ne fonctionnent jamais dans ce schéma. Par conséquent, ils ne peuvent pas modifier ou supprimer accidentellement des objets de schéma d'application.

• Schéma app_code, qui possède uniquement le package employees_pkg.

  Les développeurs du package employees_pkg travaillent dans ce schéma.

• Schéma app_admin, qui possède uniquement le package admin_pkg.

  Les développeurs du package admin_pkg travaillent dans ce schéma.

• L'utilisateur app_user, l'utilisateur d'application standard, qui ne possède rien et peut uniquement exécuter le package employees_pkg.

  Le serveur d'applications de niveau intermédiaire se connecte à la base de données du pool de connexions en tant qu'utilisateur app_user. Si ce schéma est compromis (par exemple, par un bug d'injection SQL), l'attaquant ne peut voir et modifier que ce que les sous-programmes du package employees_pkg lui permettent de voir et de changer. L'attaquant ne peut pas supprimer des tables, escalader des privilèges, créer ou modifier des objets de schéma, ou autre chose.

• L'utilisateur app_admin_user, un administrateur d'application, qui ne possède rien et peut uniquement exécuter les packages admin_pkg et employees_pkg.

  Le pool de connexions de ce schéma est très petit et seuls les utilisateurs privilégiés peuvent y accéder. Si ce schéma est compromis, l'attaquant ne peut voir et modifier que les sous-programmes de package admin_pkg et employees_pkg qui le permettent.

Supposons qu'au lieu des utilisateurs app_user et app_admin_user, l'application ne possédait qu'un seul schéma qui ne possédait rien et pouvait exécuter les packages employees_pkg et admin_pkg. Le pool de connexions pour ce schéma doit être suffisamment volumineux pour les utilisateurs standard et les administrateurs d'application. S'il y avait un bogue d'injection SQL dans le package employees_pkg, un utilisateur standard qui a exploité ce bogue pouvait accéder au package admin_pkg.

Supposons qu'à la place des schémas app_data, app_code et app_admin, l'application n'avait qu'un seul schéma propriétaire de tous les objets de schéma, y compris les packages. Les packages auraient alors tous les privilèges sur les tables, ce qui serait à la fois inutile et indésirable.

Par exemple, supposons que vous disposiez d'une table de trace d'audit, AUDIT_TRAIL. Vous voulez que les développeurs du package employees_pkg puissent écrire dans la table AUDIT_TRAIL, mais pas la lire ni la modifier. Vous voulez que les développeurs du package admin_pkg puissent lire la table AUDIT_TRAIL et y écrire, mais pas la modifier. Si la table AUDIT_TRAIL et les packages employees_pkg et admin_pkg appartiennent au même schéma, les développeurs des deux packages disposent de tous les privilèges sur la table AUDIT_TRAIL. Toutefois, si la table AUDIT_TRAIL appartient au schéma app_data, que le package employees_pkg appartient au schéma app_code et que le package admin_pkg appartient au schéma app_admin, vous pouvez vous connecter à la base de données en tant que schéma app_data et exécuter les commandes suivantes :

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

Voir aussi :

• A propos d'Oracle AI Database pour plus d'informations sur les schémas
• A propos du schéma échantillon HR pour plus d'informations sur le schéma échantillon HR
• Pratiques de sécurité recommandées

Conventions de dénomination dans l'application

L'application utilise ces conventions de dénomination.

Elément	Nom
Table	table#
Vue Editioning pour la table#	tableau
Déclencheur sur la table de la vue de modification	table_{a|b}event[_fer] où : a identifie un déclencheur AFTER. b identifie un déclencheur AVANT. fer identifie un déclencheur FOR EACH ROW. event identifie l'événement qui déclenche le déclencheur. Par exemple : i pour INSERT, iu pour INSERT ou UPDATE, d pour DELETE.
Contrainte de clé primaire dans la table#	table_pk
Contrainte NOT NULL sur la table#.column	table_column_not_null1
Contrainte UNIQUE sur table#.column	table_column_unique1
Contrainte CHECK sur la table#.column	table_column_check1
Contrainte REF sur la table1#.column à table2#.column	table1_to_table2_fk1
Contrainte REF sur table1#.column1 à table2#.column2	table1_col1verstable2_col2_fk1 2
Séquence pour le numéro de table	séquence_table
Nom de paramètre	p_nom
Nom de la variable locale	l_nom

1. table, table1 et table2 sont abrégés en emp pour les employés, dept pour les départements et job_hist pour job_history. ↩ ↩² ↩³ ↩⁴ ↩⁵

2. col1 et col2 sont des abréviations des noms de colonne column1 et column2. Un nom de contrainte ne peut pas contenir plus de 30 caractères. ↩