Les différentes catégories d’utilisateurs
En pratique il existe 5 catégories d’utilisateurs, qui utilisent différents outils en fonction de leur profil et du SGBD ciblé. Ceci est résumé dans le tableau suivant :
| Type d’utilisateur | profil | outil | ex Oracle | exemple MySQL |
| Utilisateur final | non informaticien | application client serveur ou web, ou progiciel, ou appli bureautique, outil d’aide à la décision | Excel, appli maison, Oarcle application, B.O | appli web |
| utilisateur final évolué | non infrmaticien éclairé | client QBE (Query by Example) | MS QUery | PHPMyAdmin |
| Développeur | Technicien ou ingénieur | Bloc note, environnement de developpement, Atelier de développement | TOAD, designer, webdb | textpad |
| Administrateur application | Utilisateur final hiérarchiquement privilégié | l’application elle même, via un accès privilégié | NA | NA |
| DBA | Technicien ou ingénieur | langage SQL, console d’admin texte, console graphique, console web | sqlplus, OEM CS ou web, TOAD, | PhpMyAdmin |
outre le moteur du SGBD lui même, les différents fournisseurs proposent toute une suite de logiciels connexes permettant ces intéractions, qui représente une part non négligeable de leur activité.
Les différentes catégories de base de données
La base de données, à l’instar d’un programme classique s’inscrit dans un cycle de vie, et diiférentes occurences de la base permettent de ‘coller’ aux différentes phases du projet.
On distingue principalement :
- la phase de conception, qui produira le modèle conceptuel et le modèle logique de la base
- la phase de développement, qui verra la création et l’évolution de la base de développement (Base n°1)
- les tests, avec une base de test ou de préproduction (Base n°2) qui permettra outre de tester les programmes de manière approfondie, de tester la montée en charge et les performances en terme de volume de données, et de concurrence d’accès
- la phase de production / exploitation et de maintenance, avec une base de production (Base n°3), initialisée avec des données réelles et dimensionnée de manière adéquate
Le DBA sera fréquemment amené à transférer des données d’une base à une autre :
- de la base de developpement à la base de Test, pour effectuer les dits tests. Un ensemble de données cohérentes (jeu d’essai) est alors nécessaire, ce qui n’est pas toujours facile à obtenir vu la complexité croissante des applications et peut nécessiter des outils spécifiques d’extraction de données
- de la base de test à la base de production, pour la mise en explotation réelle
- de la base de production vers la base de test ou de développement, pour être sûr d’avoir des données cohérentes et pertinentes (puisque réelles).
Ce dernier tranfert de données est VIVEMENT déconseillé, d’abord parce qu’il manipule des volumes de données inutiles (la totalité des données réelles) et ensuite car il offre d’importantes failles de sécurité, les systèmes de test et de développement étant par définition moins protégés que les systèmes en production…
note : le passage de la base de test à la base de production, nécesite de réinitialiser la base, avec les scripts SQL originaux (création et chargement initial). Le passage au serveur réel peut s’avérer délicat et contraignant (environnement matériel et logiciel différent)
