Aperçu
Peut-être qu’aucun autre sujet de discussion dans les cercles de développement, de modélisation et de gestion de bases de données n’attire plus l’attention, et suscite souvent des débats houleux, que celui de l’intégrité des données. Il est étonnant que, malgré la distance que nous avons parcourue dans la compréhension, la pratique et la technologie, tant de gourous de la base de données (Celko, Codd, Date, Riordan et al.) varient tellement dans leurs philosophies respectives. En conséquence, les administrateurs et les développeurs gèrent souvent la modélisation de l’intégrité et donc la programmation de l’intégrité par le siège de leur pantalon. Même SQL Server Books Online définit l’intégrité des données dans son glossaire d’une manière plus confuse qu’une chauve-souris en plein jour.
Ce livre n’est certainement pas le forum pour une discussion sur l’intégrité des données, et c’est à peu près aussi loin que je veux m’aventurer à discuter de la théorie des bases de données relationnelles. Mais sans explorer certains concepts et accepter la seule définition possible de l’intégrité des données, vous ne bénéficierez pas de tous les outils et nouvelles fonctionnalités pris en charge par SQL Server 2005 en ce qui concerne la modélisation et la programmation de l’intégrité des données.
L’intégrité des données n’est certainement pas une pratique, une discipline, qui garantit que les données stockées dans une base de données sont correctes, seulement si elles sont crédibles ou plausibles. Il n’y a aucun moyen entre cette vie et l’au-delà que SQL Server 2005, ou tout autre SGBDR, puisse garantir que les données d’une base de données sont correctes. Corrigez votre vocabulaire maintenant. SQL Server 2005 n’a aucun moyen de savoir et de s’assurer ainsi que mon indicatif régional n’est pas 209 mais plutôt 299, ou que mon nom de famille est Shapiro et non Schapiro. J’ai même entendu parler d’une fille nommée Jeffrey. Vous devez commencer à penser, à modéliser et à programmer SQL Server en termes de plausibilité des données, et non en termes de données correctes ou erronées.
Ce n’est que si vous acceptez cette définition que vous pourrez utiliser les outils et techniques supportés par SQL Server 2005 pour garantir l’intégrité de vos données, et donc leur valeur en tant qu’actif pour votre entreprise. Et après avoir commencé à vous concentrer sur l’intégrité en termes scalaires et non sur l’exactitude en termes absolus, vous aurez beaucoup plus confiance dans les données de votre base de données, et vous pourrez lui accorder la confiance et le respect qu’elle mérite. Après tout, les données qui ne sont pas plausibles ou crédibles sont une responsabilité
Comme je l’ai discuté au chapitre 1, une erreur humaine a causé un chagrin extrême à ma femme lorsque, après avoir changé de compagnie d’assurance médicale, elle s’est vu refuser la couverture pendant un certain temps parce que le nom de famille de son médecin, au lieu de Shapiro, était entré dans le champ nom de famille du conjoint, À ma femme, le problème d’intégrité des données est donc devenu un problème mortel. Pour la compagnie d’assurance médicale, le problème a presque explosé en un problème de responsabilité.
Qu’est-ce qui pourrait ou pourrait faire en sorte qu’un nom de famille, ou un nom de famille, soit incorrect?
-
La femme porte son nom de jeune fille.
-
Un conjoint fournit par erreur un pseudonyme.
-
Le couple vient de divorcer mais a accepté de maintenir la couverture.
-
Un enfant est couvert par un beau-père mais porte toujours le nom de famille de son père biologique.
-
Le prénom est entré dans le champ nom de famille.
-
Le nom de famille est mal tapé (Shapiro devient Ahaoeuei en quelques glissements de doigt).
-
L’écriture manuscrite sur le formulaire de demande est médiocre ou le nom de famille est omis et la personne chargée de la saisie des données fait une fausse hypothèse.
Cette liste pourrait continuer encore et encore. Et je suis sûr que vous pourriez proposer des dizaines de scénarios qui créeraient également des données douteuses, non seulement dans les valeurs du nom de famille, mais aussi dans de nombreux autres endroits. Les chiffres, par exemple, offrent des possibilités incroyables d’entrer des données problématiques dans une base de données.
Mais est-ce une question d’intégrité? Si nous acceptons que nous programmons le SGBD pour nous assurer que les données sont aussi crédibles que possible, alors c’est le cas. Si nous essayons de nous assurer que les données sont correctes, ce n’est pas le cas. Toute valeur peut en fait être correcte lorsqu’elle est supposée fausse, et elle peut en fait être fausse lorsqu’elle est supposée correcte. La seule chose que vous pouvez faire pour vous assurer que les données sont crédibles est de vous assurer qu’elles étaient crédibles lorsqu’elles ont été entrées dans la base de données.
Le mieux que je puisse penser faire au niveau des données pour m’assurer qu’une valeur, telle que le nom de famille du conjoint, est crédible est de forcer le client à revenir en arrière et à vérifier les données avant de pouvoir les saisir, ou de comparer les données avec des valeurs connues. Il est même possible de renvoyer l’enregistrement au client et de demander qu’il soit saisi par un autre utilisateur, éventuellement un superviseur qui ferait passer la vérification des faits au niveau supérieur. Demander aux internautes de remplir des formulaires de demande sur Internet est une bonne idée, car cela élimine la personne intermédiaire dans la saisie des données, la piste papier et les délais, et il incombe au client de s’assurer de la plausibilité des données, qui est plus susceptible de s’assurer que ses informations peuvent être fiables.
J’ai récemment regardé une histoire horrible sur CNN au sujet d’un pharmacien américain qui a donné à un enfant une surdose mortelle d’un médicament contrairement à ce qui avait été correctement prescrit par le pédiatre. L’excuse était l’erreur humaine, l’incapacité du superviseur à vérifier les ordonnances, à remplir des centaines d’ordonnances par jour Pourquoi, au nom du ciel, de nos jours, les pharmaciens utilisent-ils encore des machines à écrire et des traitements de texte pour fournir des instructions sur la posologie et l’administration de médicaments dangereux? Une base de données aurait dû être utilisée pour vérifier que la posologie ne dépassait pas les niveaux de sécurité du médicament prescrit. Aucun programme informatique n’a vérifié le dosage, et donc une mère a envoyé son enfant au lit et il ne s’est jamais réveillé. Maintenant, chaque fois que nous achetons des médicaments, nous vérifions l’étiquette et nous nous demandons « pouvons-nous faire confiance à ces données? »
De toute évidence, le sujet de l’erreur humaine dépasse le cadre de ce livre, si ce n’est pour discuter des moyens possibles que nous pourrions avoir d’empêcher les humains d’entrer des données douteuses dans une base de données. Joe Celko a abordé le sujet dans son merveilleux livre, Joe Celko’s Data & Databases: Concepts in Practice (New York: Morgan Kaufmann, 1999). Dans une section intitulée « Modèles contre réalité », il parle des erreurs dans les modèles, décrivant les niveaux d’erreur de type I et de type II. Une erreur de type I accepte comme faux quelque chose qui est vrai, et une erreur de type II accepte comme vrai quelque chose qui est faux.
Je suis d’accord sans équivoque sur le fait que le sujet des erreurs dans les modèles est très important à comprendre pour les personnes de la base de données. Des générations de personnes ont été anéanties à cause de ce problème. L’Afrique subsaharienne, où j’ai passé mon enfance, va être anéantie à cause du SIDA. Cela aurait pu être évité, mais la population y croit toujours, dans l’ensemble, que le SIDA n’est pas transmis sexuellement et que la publicité n’est que de la « propagande occidentale ». »La fraude s’auto-perpétue ou s’auto-réalise, car des millions d’Africains ont encore des relations sexuelles non protégées.
Oui, nous pouvons utiliser des astuces de programmation sophistiquées et des fonctionnalités système telles que des déclencheurs et des procédures stockées pour réduire la probabilité de données invraisemblables; nous pouvons même intégrer des contrôles d’intégrité humaine plus avancés dans les applications clientes. Comment pouvons-nous éviter des problèmes comme celui qui vient d’être décrit et programmer SQL Server 2005 aussi judicieusement que possible? Pour trouver une solution possible, explorons d’abord les fonctionnalités et fonctions d’assurance de l’intégrité de SQL Server 2005. Après cette discussion, nous pouvons résoudre le problème d’intégrité du nom de famille et proposer à ma compagnie d’assurance médicale des idées avant qu’elle ne soit poursuivie en justice.