Descripción general
Quizás ningún otro tema de discusión en los círculos de desarrollo, modelado y administración de bases de datos atrae más atención, y a menudo debate acalorado, que el de la integridad de datos. Es sorprendente que, a pesar de la distancia que hemos recorrido en comprensión, práctica y tecnología, tantos gurús de bases de datos (Celko, Codd, Date, Riordan, et al.) varían mucho en sus respectivas filosofías. Como resultado, los administradores y desarrolladores a menudo manejan el modelado de integridad y, por lo tanto, la programación de integridad por el asiento de sus pantalones. Incluso SQL Server Books Online define la integridad de los datos en su glosario de una manera más confusa que un murciélago a plena luz del día.
Este libro ciertamente no es el foro para una discusión de la integridad de los datos, y esto es lo más lejos que quiero aventurarme a discutir la teoría de bases de datos relacionales. Pero sin explorar algunos conceptos y aceptar la única definición factible de integridad de datos, no se beneficiará de todas las herramientas y nuevas características que admite SQL Server 2005 con respecto al modelado y la programación de integridad de datos.
La integridad de los datos definitivamente no es una práctica, una disciplina, que garantice que los datos almacenados en una base de datos sean correctos, solo que sean creíbles o plausibles. No hay manera entre esta vida y el más allá de que SQL Server 2005, o cualquier otro RDBMS, pueda garantizar que los datos en una base de datos sean correctos. Sal de tu vocabulario ahora. SQL Server 2005 no tiene forma de saber y así asegurar que mi código de área no es 209 sino 299, o que mi apellido es Shapiro y no Schapiro. Incluso he oído hablar de una chica llamada Jeffrey. Debe comenzar a pensar, modelar y programar SQL Server en términos de plausibilidad de los datos, no en términos de que los datos sean correctos o incorrectos.
Solo si acepta esta definición podrá utilizar las herramientas y técnicas compatibles con SQL Server 2005 para garantizar la integridad de sus datos y, por lo tanto, su valor como activo para su empresa. Y después de comenzar a enfocarse en la integridad en términos escalares y no en la corrección en términos absolutos, tendrá mucha más fe en los datos de su base de datos, y podrá brindarle la confianza y el respeto que se merece. Después de todo, los datos que no son plausibles o creíbles son una responsabilidad
Como mencioné en el Capítulo 1, el error humano causó un dolor extremo a mi esposa cuando, después de cambiar de compañía de seguros médicos, se le negó la cobertura durante algún tiempo porque el apellido de su médico, en lugar de Shapiro, se ingresó en el campo del apellido del cónyuge, a mi esposa, el problema de integridad de los datos se convirtió en un problema que amenazaba la vida. Para la compañía de seguros médicos, el problema casi explotó en un problema de responsabilidad civil.
¿Qué causaría o podría causar que un apellido o apellido sea incorrecto?
-
La esposa usa su apellido de soltera.
-
Un cónyuge erróneamente proporciona un seudónimo.
-
La pareja se acaba de divorciar, pero accedió a mantener la cobertura.
-
Un niño está cubierto por un padrastro, pero todavía sigue por el apellido de su padre biológico.
-
El nombre se introduce en el campo apellido.
-
El apellido se escribe incorrectamente (Shapiro se convierte en Ahaoeuei con solo unos pocos resbalones del dedo).
-
La escritura a mano en el formulario de solicitud es deficiente, o el apellido se omite y la persona que ingresa los datos hace una suposición incorrecta.
Esta lista podría seguir y seguir. Y estoy seguro de que se le podrían ocurrir docenas de escenarios que también crearían datos cuestionables, no solo en los valores de los apellidos, sino también en muchos otros lugares. Los números, por ejemplo, presentan oportunidades increíbles para ingresar datos problemáticos en una base de datos.
¿Pero es esto una cuestión de integridad? Si aceptamos que programemos el DBMS para asegurarnos de que los datos sean lo más creíbles posible, entonces lo es. Si tratamos de asegurarnos de que los datos son correctos, entonces no lo es. De hecho, cualquier valor puede ser correcto cuando se supone que es incorrecto, y de hecho puede ser incorrecto cuando se supone que es correcto. Lo único que puede hacer para ayudar a garantizar que los datos sean creíbles es ayudar a asegurarse de que eran creíbles cuando se ingresaron en la base de datos.
Lo mejor que se me ocurre hacer en el nivel de datos para ayudar a garantizar que un valor, como el apellido del cónyuge, sea creíble, es forzar al cliente a regresar y verificar los datos antes de que se puedan ingresar, o comparar los datos con valores conocidos. Es posible incluso remitir el registro al cliente y solicitar que lo ingrese otro usuario, posiblemente un supervisor que llevaría la verificación de datos al siguiente nivel. Pedir a los internautas que rellenen formularios de solicitud a través de Internet es una buena idea porque elimina a la persona de entrada de datos intermedia, el rastro de papel y el retraso, y pone la responsabilidad de garantizar la verosimilitud de los datos en el cliente, que es más probable que se asegure de que se pueda confiar en su información.
Recientemente vi una historia horrible en CNN sobre un farmacéutico estadounidense que le dio a un niño una sobredosis fatal de un medicamento contrario a lo que había sido recetado correctamente por el pediatra. La excusa fue un error humano, el fracaso del supervisor de verificar dos veces las recetas, llenando cientos de recetas al día, ¿Por qué, en nombre del cielo, en esta época, los farmacéuticos siguen usando máquinas de escribir y procesadores de texto para proporcionar instrucciones sobre la dosificación y administración de drogas peligrosas? Se debería haber utilizado una base de datos para verificar que la dosis no excediera los niveles de seguridad para el medicamento recetado. Ningún programa de computadora comprobó la dosis, así que una madre envió a su hijo a la cama y él nunca se despertó. Ahora, cada vez que compramos medicamentos, revisamos la etiqueta y nos preguntamos: «¿podemos confiar nuestras vidas en estos datos?»
Obviamente, el tema del error humano está más allá del alcance de este libro, aparte de discutir qué medios posibles podríamos tener para evitar que los humanos ingresen datos cuestionables en una base de datos. Joe Celko abordó el tema en su maravilloso libro, Joe Celko’s Data & Databases: Concepts in Practice (Nueva York: Morgan Kaufmann, 1999). En una sección titulada «Modelos versus Realidad», habla de los errores en los modelos, describiendo los niveles de error de Tipo I y Tipo II. Un error de tipo I es aceptar como falso algo que es verdadero, y un error de Tipo II es aceptar como verdadero algo que es falso.
Estoy de acuerdo sin equívocos en que el tema de los errores en los modelos es muy importante para que la gente de la base de datos lo entienda. Generaciones de personas han sido aniquiladas a causa de este problema. El África subsahariana, donde pasé mi infancia, va a desaparecer a causa del SIDA. Esto podría haberse evitado, pero la población de allí todavía cree, en general, que el SIDA no se transmite sexualmente y que la publicidad es solo «propaganda occidental».»De hecho, el fraude se perpetúa a sí mismo o se cumple a sí mismo, porque millones de africanos todavía tienen relaciones sexuales sin protección.
Sí, podemos usar trucos de programación sofisticados y funciones del sistema, como disparadores y procedimientos almacenados, para disminuir la probabilidad de datos inverosímiles; incluso podemos crear comprobaciones de integridad humana más avanzadas en las aplicaciones cliente. ¿Cómo podemos evitar problemas como el que acabamos de describir y seguir programando SQL Server 2005 lo más sabiamente posible? Para llegar a una posible solución, primero exploremos las características y funciones de garantía de integridad de SQL Server 2005. Después de esta discusión, podemos corregir el problema de integridad del apellido y ofrecer a mi compañía de seguros médicos algunas ideas antes de que sean demandados.