Overview
Forse nessun altro argomento di discussione nei circoli di sviluppo, modellazione e gestione di database attira più attenzione, e spesso acceso dibattito, di quello dell’integrità dei dati. È sorprendente che, nonostante la distanza che abbiamo raggiunto nella comprensione, nella pratica e nella tecnologia, così tanti guru del database (Celko, Codd, Date, Riordan, et al.) variano così ampiamente nelle loro rispettive filosofie. Di conseguenza, amministratori e sviluppatori spesso gestiscono la modellazione dell’integrità e quindi la programmazione dell’integrità dalla sede dei loro pantaloni. Anche SQL Server Books Online definisce l’integrità dei dati nel suo glossario in un modo più confuso di un pipistrello in pieno giorno.
Questo libro non è certamente il forum per una discussione sull’integrità dei dati, e questo è quanto voglio avventurarmi nel discutere della teoria dei database relazionali. Ma senza esplorare alcuni concetti e accettare l’unica definizione fattibile di integrità dei dati, non beneficerete di tutti gli strumenti e le nuove funzionalità supportate da SQL Server 2005 per quanto riguarda la modellazione e la programmazione dell’integrità dei dati.
L’integrità dei dati non è sicuramente una pratica, una disciplina, che garantisce che i dati memorizzati in un database siano corretti, solo che è credibile o plausibile. Non c’è modo tra questa vita e l’aldilà che SQL Server 2005, o qualsiasi altro RDBMS, possa garantire che i dati in un database siano corretti. Ottenere corretto dal tuo vocab ora. SQL Server 2005 non ha modo di sapere e quindi garantire che il mio prefisso non sia 209 ma piuttosto 299, o che il mio cognome sia Shapiro e non Schapiro. Ho persino sentito parlare di una ragazza di nome Jeffrey. È necessario iniziare a pensare, modellare e programmare SQL Server in termini di plausibilità dei dati, non in termini di dati giusti o sbagliati.
Solo se accetti questa definizione sarai in grado di utilizzare gli strumenti e le tecniche supportate da SQL Server 2005 per garantire l’integrità dei tuoi dati e quindi il loro valore come risorsa per la tua azienda. E dopo aver iniziato a concentrarti sull’integrità in termini scalari e non sulla correttezza in termini assoluti, avrai molta più fiducia nei dati nel tuo database, e sarai in grado di permetterti la fiducia e il rispetto che merita. Dopo tutto, i dati che non è plausibile, o credibile è una responsabilità
Come ho discusso nel Capitolo 1, l’errore umano causato mia moglie estremo dolore quando, dopo cambiando medico, imprese di assicurazione, lei è stata negata la copertura per un certo tempo perché il cognome del suo medico, invece di Shapiro, è stato inserito nella coniuge cognome del campo, A mia moglie, l’integrità dei dati problema, quindi, è diventato un pericolo di vita uno. Per la compagnia di assicurazione medica, il problema è quasi esploso in un problema di responsabilità.
Cosa potrebbe o potrebbe causare un cognome, o cognome, non corretto?
-
La moglie va sotto il suo nome da nubile.
-
Un coniuge fornisce erroneamente uno pseudonimo.
-
La coppia ha appena divorziato, ma ha accettato di mantenere la copertura.
-
Un bambino è coperto da un patrigno, ma va ancora sotto il cognome del suo padre biologico.
-
Il nome viene inserito nel campo cognome.
-
Il cognome viene digitato in modo errato (Shapiro diventa Ahaoeuei con pochi scivoloni del dito).
-
La grafia sul modulo di domanda è scarsa o il cognome viene omesso e la persona che inserisce i dati fa un’ipotesi sbagliata.
Questa lista potrebbe andare avanti e avanti. E sono sicuro che potresti inventare dozzine di scenari che creerebbero anche dati discutibili, non solo nei valori del cognome ma anche in molti altri luoghi. I numeri, ad esempio, presentano incredibili opportunità di inserire dati problematici in un database.
Ma è una questione di integrità? Se accettiamo di programmare il DBMS per garantire che i dati siano il più credibili possibile, allora lo è. Se cerchiamo di garantire che i dati siano corretti, allora non lo è. Qualsiasi valore può infatti essere corretto quando si presume che sia sbagliato, e può infatti essere sbagliato quando si presume che sia corretto. L’unica cosa che puoi fare per aiutare a garantire che i dati siano credibili è quello di contribuire a garantire che fosse credibile quando è stato inserito nel database.
Il meglio che posso pensare di fare al livello dei dati per aiutare a garantire che un valore, come il cognome del coniuge, sia credibile è costringere il cliente a tornare indietro e controllare i dati prima che possano essere inseriti, o confrontare i dati con valori noti. È anche possibile rimandare il record al client e richiederlo per essere inserito da un altro utente, possibilmente un supervisore che avrebbe preso il fact checking al livello successivo. Chiedere ai navigatori Web di compilare i moduli di domanda su Internet è una buona idea perché taglia fuori la persona di inserimento dati centrale, la traccia cartacea e il ritardo e pone l’onere di garantire la plausibilità dei dati sul cliente, che è più propenso a garantire che le sue informazioni possano essere invocate.
Recentemente ho visto una storia terrificante sulla CNN su un farmacista americano che ha dato a un bambino un sovradosaggio fatale di un farmaco contrariamente a quanto era stato correttamente prescritto dal pediatra. La scusa era l’errore umano, il fallimento del supervisore nel ricontrollare le prescrizioni, riempire centinaia di prescrizioni al giorno Perché, in nome del cielo, in questo giorno ed età, i farmacisti usano ancora macchine da scrivere e word processor per fornire istruzioni sul dosaggio e la somministrazione di farmaci pericolosi? Un database avrebbe dovuto essere utilizzato per verificare che il dosaggio non superasse in modo sicuro i livelli per il farmaco prescritto. Nessun programma per computer controllava il dosaggio, e così una madre mandò il suo bambino a letto e non si svegliò mai. Ora, ogni volta che compriamo farmaci, controlliamo l’etichetta e ci chiediamo ” possiamo fidarci delle nostre vite a questi dati?”
Ovviamente, il tema dell’errore umano va oltre lo scopo di questo libro, oltre a discutere quali possibili mezzi potremmo avere per impedire agli esseri umani di inserire dati discutibili in un database. Joe Celko ha toccato l’argomento nel suo meraviglioso libro, Joe Celko’s Data & Databases: Concepts in Practice (New York: Morgan Kaufmann, 1999). In una sezione intitolata “Modelli contro realtà”, parla degli errori nei modelli, descrivendo i livelli di errore di tipo I e di tipo II. Un errore di tipo I sta accettando come falso qualcosa che è vero, e un errore di tipo II sta accettando come vero qualcosa che è falso.
Sono d’accordo senza equivoci sul fatto che l’argomento degli errori nei modelli è molto importante per le persone del database da capire. Generazioni di persone sono state spazzate via a causa di questo problema. L’Africa subsahariana, dove ho trascorso la mia infanzia, sarà spazzata via a causa dell’AIDS. Questo avrebbe potuto essere evitato, ma la popolazione crede ancora, in generale, che l “AIDS non si trasmette sessualmente e che la pubblicità è solo” propaganda occidentale.”La frode è in realtà auto-perpetuante o auto-appagante, perché milioni di africani hanno ancora rapporti sessuali non protetti.
Sì, possiamo usare trucchi di programmazione fantasiosi e funzionalità di sistema come trigger e stored procedure per ridurre la probabilità di dati non plausibili; possiamo persino costruire controlli di integrità umana più avanzati nelle applicazioni client. Come possiamo evitare problemi come quello appena descritto e ancora programmare SQL Server 2005 nel modo più saggio possibile? Per arrivare a una possibile soluzione, esploriamo innanzitutto le funzionalità e le funzioni di integrity assurance di SQL Server 2005. Dopo questa discussione, possiamo rimediare al problema dell’integrità del cognome e offrire alla mia compagnia di assicurazione medica alcune idee prima che vengano citate in giudizio.