Zones de problèmes potentiels dans les bases de données SQL multitables - fictives L'intégrité des données

L'intégrité des données peut faire l'objet de voies de fait de divers types. Certains de ces problèmes ne se posent que dans des bases de données SQL multitâches; d'autres peuvent se produire même dans des bases de données qui ne contiennent qu'une seule table. Vous voulez reconnaître et minimiser toutes ces menaces potentielles.

Données d'entrée incorrectes

Les documents source ou les fichiers de données que vous utilisez pour remplir votre base de données peuvent contenir des données incorrectes. Ces données peuvent être une version corrompue des données correctes, ou il se peut que ce ne soit pas les données que vous souhaitez. Une vérification de plage vous indique si les données ont une intégrité de domaine.

Ce type de vérification intercepte certains problèmes, mais pas tous. Par exemple, les valeurs de champ incorrectes qui se situent dans la plage acceptable, mais qui restent incorrectes, ne sont pas identifiées comme des problèmes.

Erreur de l'opérateur

Les données de votre source peuvent être correctes, mais l'opérateur de saisie risque de ne pas transcrire correctement les données. Ce type d'erreur peut entraîner les mêmes types de problèmes que de mauvaises données d'entrée. Certaines des solutions sont les mêmes, aussi. Les vérifications de portée aident, mais elles ne sont pas infaillibles. Une autre solution consiste à avoir un deuxième opérateur indépendamment valider toutes les données.

Cette approche est coûteuse car la validation indépendante nécessite deux fois plus de personnes et deux fois plus de temps. Mais dans certains cas où l'intégrité des données est critique, les efforts et les dépenses supplémentaires peuvent s'avérer utiles.

Panne mécanique

Si vous rencontrez une défaillance mécanique, telle qu'un crash du disque, les données de la table peuvent être détruites. De bonnes sauvegardes sont votre principale défense contre ce problème.

Malice

Envisagez la possibilité que quelqu'un veuille corrompre vos données. Votre première ligne de défense consiste à refuser l'accès à la base de données à quiconque ayant une intention malveillante et à restreindre les utilisateurs autorisés afin qu'ils puissent accéder uniquement aux données dont ils ont besoin. Votre deuxième défense est de maintenir les sauvegardes de données dans un endroit sûr. Réévaluer périodiquement les caractéristiques de sécurité de votre installation. Être un peu paranoïaque ne fait pas de mal.

Redondance des données

La redondance des données - les mêmes éléments de données surgissant à plusieurs endroits - est un gros problème avec le modèle de base de données hiérarchique, mais le problème peut également affecter les bases de données relationnelles. Non seulement cette redondance gaspille-t-elle de l'espace de stockage et ralentit le traitement, mais elle peut aussi conduire à une sérieuse corruption des données.

Si vous stockez le même élément de données dans deux tables différentes dans une base de données, l'élément de l'une de ces tables peut changer alors que l'élément correspondant dans l'autre table reste le même.Cette situation génère une divergence et vous ne pouvez pas déterminer la version correcte. C'est une bonne raison de minimiser la redondance des données.

Bien qu'une certaine quantité de redondance soit nécessaire pour que la clé primaire d'une table puisse servir de clé étrangère dans une autre, vous devriez essayer d'éviter la répétition de tous les éléments de données au-delà.

Une fois que vous avez éliminé la plupart des redondances d'une conception de base de données, vous pouvez constater que les performances sont désormais inacceptables. Les opérateurs utilisent souvent un peu de redondance pour accélérer le traitement.

Une pratique courante consiste à concevoir initialement une base de données avec peu de redondance et avec des degrés de normalisation élevés, puis, après avoir constaté que les applications importantes tournent lentement, ajouter sélectivement de la redondance et dénormaliser. Le mot clé ici est sélectivement.

La redondance que vous rajoutez doit avoir un but précis, et parce que vous êtes parfaitement conscient de la redondance et du danger qu'elle représente, vous prenez les mesures appropriées pour vous assurer que la redondance ne cause pas plus de problèmes que résout.

Lorsque vous dépassez la capacité de votre SGBD

Un système de base de données peut fonctionner correctement pendant des années et commencer à rencontrer des erreurs intermittentes qui deviennent de plus en plus graves. Cela peut indiquer que vous approchez l'une des limites de capacité du système. Il y a, après tout, des limites au nombre de lignes qu'une table peut avoir. Il existe également des limites sur les colonnes, les contraintes et diverses autres fonctionnalités de base de données.

Vérifiez la taille et le contenu actuels de votre base de données par rapport aux spécifications répertoriées dans la documentation de votre SGBD. Si vous êtes proche de la limite dans n'importe quelle zone, envisagez de passer à un système ayant une capacité supérieure. Vous pouvez également archiver des données anciennes qui ne sont plus actives, puis les supprimer de votre base de données.