Le plus important et le premier garant d'une base de donnée tient dans l'uniformité des données en question.
La base de données va servir à faire des requêtes, des extractions... il est donc primordial que les données soient uniformes dans un même champ. Par exemple, Londres et London ne sont qu'une ville mais deux données, une requête basée sur la ville en reportera 2, une autre basée sur Londres va exclure London... Les résultats seront techniquement justes mais analytiquement faux...
La gestion et le bon fonctionnement d'une base de données dépend donc de la validité et de l'uniformité des données entrantes.
Le mieux est donc d'avoir des masques de saisie avec des champs obligatoires afin que les utilisateurs ne fassent pas d'omissions et des critères de saisie (numérique seulement, alphanumérique, alphabétique, etc...). Quand cela est possible, la saisie assistée (choix dans une liste) évitera les erreurs et garantira l'intégrité des données, sinon des contôles de cohérence peuvent s'appliquer (renvoi vers une base existante, la donnée saisie existe t-elle dans les données autorisées?).
Les derniers points importants tiennent:
- dans les mises à jour, afin de ne pas dupliquer de données déjà importées dans la base ;
- dans la gestion des données modifiables (correction/changement) ou variables (exemple: table de taux de change, ou poids des articles référencés...) car si des requêtes effectuent des calculs, les résultats seront faux et/ou variables... (il est donc toujours important de recouper les résultats...) surtout si il y a une notion historique des données...
Il convient donc d'identifier qui alimente les bases annexes sur laquelle la base de données principale peut s'appuyer et de vérifier les droits de modification des utilisateurs.
Ensuite c'est la structure des requêtes qui doit être cohérente, quitte à améliorer le masque de saisie des données. Le fait de savoir quel résultat on veut obtenir aide beaucoup à avoir des données qualitatives.
Bon courage, car selon l'utilisation cela peut être passionnant comme un vrai casse tête. La qualité des données stockées est donc essentielle.
2006-10-05 07:20:45
·
answer #1
·
answered by Lautari 5
·
2⤊
0⤋
Dans un premier temps, beaucoup de saisie et de retrouver ses données au moment opportun
2006-10-05 13:46:32
·
answer #2
·
answered by buddha050566 3
·
0⤊
0⤋
concernant la GESTION d'une base de donnée?
il y a un problème de vocabulaire, on ne gère pas une base de données (ou très peu). on gère un hopital ou un video-club à l'aide d'une base de données, là oui.
La base de données est donc juste un outil pour servir un autre métier. Ce qu'on peut faire avec au lieu de la gérer, c'est :
- 1 : La concevoir
- 2 : L'administrer
- 3 : l'utiliser
- 1 : Pour la concevoir, c'est le travail de l'analyste-programmeur ou de l'ingénieur architecte de base de donnée.
Il doit définir le contenu en suivant des règles (formes normales) des usages (méthode Merise), et des techniques (Modele conceptuel de données - MCD). on peut être formé à ce métier en 1 à 5 ans. ces derniers temps, les concepteurs ne sont plus recrutés en dessous de bac+5 (dommage pour moi).
son travail sera de définir les données elles-même et surtout les liaisons qui existent entre elles. on défini égalament des règles d'intégrité et des contraintes. ces définitions peuvent être faites à l'aide du langage SQL ou de triggers (déclencheur) rédigés en PL-SQL. les triggers sont un mécanisme puissant permettant de déclencher une action interne au serveur lors de chaque ajout, modification ou suppression. cette action peut se contenter de tester l'intégrité ou déclencher en cascade d'autres mises à jour (cummuls, optimisations)
- 2 : l'administrateur est plutot un profil bac+2 avec persque les mêmes connaissances que le concepteur (SQL, triggers) mais son travail va être de faire vivre la base au quotidien. créer des comptes utilisateurs, donner des permissions, organiser les sauvegardes, vérifier l'espace disque et planifier le stockage, réorganiser, compacter. il pourra aussi faire de petites requêtes ou des tests d'intégrité (inutile si le concepteur a bien fait son boulot)
- 3 : il ne reste à l'utilisateur que très peu de responsabilités. si le travail a été bien fait en amont par le concepteur et l'administrateur, l'utilisateur n'a plus qu'a alimenter cette base en respectant des règle de saisie qu'on lui aura donné. il pourra ensuite éditer des rapports et autres statistiques avec des outils clients fais sur mesure ou même avec excell.
voila le topo...
2006-10-05 17:23:19
·
answer #3
·
answered by Ramis V 7
·
0⤊
1⤋