À propos de l'application

Le contenu du script de cette page est destiné uniquement à la navigation et ne modifie en rien le contenu.

L'application a les objectifs, la structure et les conventions d'appellation suivants.

Objet de l'application

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

• Utilisateurs typiques (gestionnaires d'employés)

• Administrateurs de l'application

Les utilisateurs typiques peuvent effectuer les tâches suivantes :

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

• Obtenir l'historique d'emploi d'un employé donné

• Afficher les informations générales pour un employé donné (nom, service, emploi, gestionnaire, salaire, etc.)

• Modifier le salaire d'un employé donné

• Modifier l'emploi d'un employé donné

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

• Modifier l'ID, le titre ou la fourchette de salaires d'un emploi existant

• Ajouter une nouvelle tâche

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

• Ajouter un nouveau service

Structure de l'application

L'application utilise les objets et schémas 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 suivantes :

  • Travaux

  • Services

  • Employés

  • Historique d'emploi des employés

• Quatre vues d'édition, qui couvrent les tableaux, 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 :

  • employee_pkg, l'interface du programme d'application (API) pour les utilisateurs typiques

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

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

Voir aussi :

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

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

Schémas pour l'application

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

• app_data possède tous les objets de schéma à l'exception des packages et charge ses tables avec les données des tables de l'exemple de schéma 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.

• app_code ne possède que le package employees_pkg

  Les développeurs de employees_pkg travaillent dans ce schéma.

• app_admin ne possède que le package admin_pkg

  Les développeurs de admin_pkg travaillent dans ce schéma.

• app_user, utilisateur typique de l'application, ne possède rien et ne peut exécuter que employees_pkg

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

• app_admin_user, un administrateur d'application, ne possède rien et ne peut exécuter que admin_pkg et employees_pkg

  La réserve de connexions de ce schéma est très petite et seuls les utilisateurs disposant de privilèges peuvent y accéder. Si ce schéma est compromis, l'attaquant ne peut voir et modifier que ce que les sous-programmes admin_pkg et employees_pkg lui permettent de voir et de modifier.

Supposons qu'au lieu d'app_user et d'app_admin_user, l'application n'avait qu'un seul schéma qui ne possédait rien et pouvait exécuter à la fois employees_pkg et admin_pkg. La réserve de connexions de ce schéma doit être suffisamment grande pour les utilisateurs standard et pour les administrateurs d'application. S'il y avait un bogue d'injection SQL dans employees_pkg, un utilisateur typique qui a exploité ce bogue pourrait accéder à admin_pkg.

Supposons qu'au lieu d'app_data, app_code et app_admin, l'application n'avait qu'un seul schéma qui possédait 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 piste de vérification, AUDIT_TRAIL. Vous voulez que les développeurs de employees_pkg puissent écrire dans AUDIT_TRAIL, mais pas le lire ou le modifier. Vous voulez que les développeurs de admin_pkg puissent lire AUDIT_TRAIL et y écrire, mais pas le modifier. Si AUDIT_TRAIL, employees_pkg et admin_pkg appartiennent au même schéma, les développeurs des deux packages disposent de tous les privilèges sur AUDIT_TRAIL. Toutefois, si AUDIT_TRAIL appartient à app_data, employees_pkg appartient à app_code et admin_pkg appartient à app_admin, vous pouvez vous connecter à la base de données en tant qu'app_data et effectuer les opérations suivantes :

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

Voir aussi :

• "À propos d'Oracle Database" pour plus d'informations sur les schémas

• "À propos de l'exemple de schéma HR" pour plus d'informations sur l'exemple de schéma HR

• " Pratiques de sécurité recommandées "

Conventions d'attribution de nom dans l'application

L'application utilise ces conventions d'attribution de nom.

Élément	Nom
Table	tableau#
Édition de la vue pour la table#	Table
Déclencher lors de l'édition de la table de vue	table_{a|b}événement[_fer] où : a identifie un déclencheur AFTER. b identifie un déclencheur AVANT. fer identifie un déclencheur FOR EACH ROW. L'événement 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#.colonne	table_column_not_null (Note de bas de page 1)
Contrainte UNIQUE sur la table#.colonne	table_column_unique (Note de bas de page 1)
Contrainte CHECK sur la table#.colonne	table_column_check (Note de bas de page 1)
Contrainte REF sur table1#.colonne à table2#.colonne	table1_to_table2_fk (note 1)
Contrainte REF sur table1#.column1 à table2#.column2	table1_col1àtable2_col2_fk (Note de bas de page 1) (Note de bas de page 2)
Séquence pour le n° table	table_sequence
Nom de paramètre	p_nom
Nom de variable locale	l_nom

Note de bas de page 1 : table, table1 et table2 sont abrégés en emp pour les employés, dept pour les services et job_hist pour job_history.

Note de bas de page 2 : col1 et col2 sont des abréviations des noms de colonne column1 et column2. Un nom de contrainte ne peut pas dépasser 30 caractères.