Visão
Talvez nenhum outro tópico de discussão no desenvolvimento de banco de dados, modelagem e gestão de círculos chama mais atenção, e muitas vezes acalorado debate, de que a integridade dos dados. É surpreendente que, apesar da distância que chegamos na compreensão, prática e Tecnologia, tantos gurus de banco de dados (Celko, Codd, Date, Riordan, et al.) variam tão amplamente em suas respectivas filosofias. Como resultado, administradores e desenvolvedores geralmente lidam com modelagem de integridade e, portanto, programação de integridade pelo assento de suas calças. Mesmo o SQL Server Books Online define a integridade dos dados em seu glossário de uma forma mais confusa do que um morcego em plena luz do dia.
este livro certamente não é o fórum para uma discussão sobre integridade de dados, e isso é até onde eu quero me aventurar em discutir a teoria do banco de dados relacional. Mas sem explorar alguns conceitos e aceitar a única definição viável de integridade de dados, você não se beneficiará de todas as ferramentas e novos recursos que o SQL Server 2005 suporta em relação à modelagem e programação de integridade de dados.A integridade dos dados definitivamente não é uma prática, uma disciplina, que garante que os dados armazenados em um banco de dados estejam corretos, apenas isso é crível ou plausível. Não há nenhuma maneira entre esta vida e a seguir que SQL Server 2005, ou qualquer outro RDBMS, pode garantir que os dados em um banco de dados está correto. Saia do seu vocabulário agora. O SQL Server 2005 não tem como saber e, assim, garantir que meu código de área não seja 209, mas sim 299, ou que meu sobrenome seja Shapiro e não Schapiro. Eu já ouvi falar de uma garota chamada Jeffrey. Você precisa começar a pensar, modelar e programar o SQL Server em termos de plausibilidade de dados, não em termos de Dados estar certo ou errado.
somente se você aceitar essa definição, poderá usar as ferramentas e técnicas suportadas pelo SQL Server 2005 para garantir a integridade de seus dados e, portanto, seu valor como um ativo para sua empresa. E depois de começar a se concentrar na integridade em termos escalares e não na correção em termos absolutos, você terá muito mais fé nos dados em seu banco de dados e poderá pagar a confiança e o respeito que merece. Afinal, dados que não são plausíveis ou verossímeis é uma responsabilidade
Como discutido no Capítulo 1, o erro humano causou a minha esposa dor extrema quando, após a mudança de companhias de seguro médico, ela foi negada a cobertura de algum tempo, porque o último nome de seu médico, em vez de Shapiro, foi introduzido o cônjuge último nome do campo, Para a minha esposa, a integridade de dados problema, portanto, tornou-se um risco de vida um. Para a seguradora médica, a questão quase explodiu em um problema de responsabilidade.
o que faria ou poderia causar um sobrenome, ou sobrenome, estar incorreto?
-
a esposa atende pelo nome de solteira.
-
um cônjuge fornece erroneamente um pseudônimo.
-
o casal acabou de se divorciar, mas concordou em manter a cobertura.
-
uma criança é coberta por um padrasto, mas ainda atende pelo sobrenome de seu pai biológico.
-
O primeiro nome é inserido no campo sobrenome.
-
o sobrenome é digitado incorretamente (Shapiro se torna Ahaoeuei com apenas alguns deslizamentos do dedo).
-
a caligrafia no formulário de inscrição é ruim ou o sobrenome é omitido e a pessoa de entrada de dados faz uma suposição errada.
esta lista pode Continuar e continuar. E tenho certeza que você poderia criar dezenas de cenários que também criariam dados questionáveis, não apenas em valores de sobrenome, mas também em muitos outros lugares. Números, por exemplo, apresentam oportunidades incríveis para inserir dados problemáticos em um banco de dados.
mas isso é uma questão de integridade? Se aceitarmos que programamos o DBMS para garantir que os dados sejam o mais críveis possível, então é. Se tentarmos garantir que os dados estão corretos, então não é. Qualquer valor pode de fato estar correto quando se supõe estar errado, e pode de fato estar errado quando se supõe estar correto. A única coisa que você pode fazer para ajudar a garantir que os dados sejam críveis é ajudar a garantir que eles sejam críveis quando foram inseridos no banco de dados.
o melhor que posso pensar em fazer na camada de dados para ajudar a garantir que um valor, como o sobrenome do cônjuge, seja crível é forçar o cliente a voltar e verificar os dados antes que possam ser inseridos ou comparar os dados com valores conhecidos. É possível até mesmo encaminhar o registro de volta ao cliente e solicitá-lo para ser inserido por outro usuário, possivelmente um supervisor que levaria a verificação de fatos para o próximo nível. Pedir aos internautas que preencham formulários de inscrição pela Internet é uma boa ideia porque corta a pessoa de entrada de dados do meio, a trilha de papel e o atraso e coloca o ônus de garantir a plausibilidade dos dados no cliente, que tem maior probabilidade de garantir que suas informações possam ser confiáveis.Recentemente, assisti a uma história horrível na CNN sobre um farmacêutico americano que deu a uma criança uma overdose fatal de uma droga contrária ao que havia sido corretamente prescrito pelo pediatra. A desculpa era erro humano, falha do supervisor em Verificar Novamente as prescrições, preenchendo centenas de prescrições por dia por que, em nome do céu, hoje em dia, os farmacêuticos ainda estão usando máquinas de escrever e processadores de texto para fornecer instruções sobre dosagem e administração de drogas perigosas? Um banco de dados deveria ter sido usado para verificar se a dosagem não excedeu os níveis de segurança do medicamento prescrito. Nenhum programa de computador verificou a dosagem e, portanto, uma mãe enviou seu filho para a cama e ele nunca acordou. Agora, sempre que compramos drogas, verificamos o rótulo e nos perguntamos “podemos confiar nossas vidas a esses dados?Obviamente, o assunto do erro humano está além do escopo deste livro, além de discutir que meios possíveis podemos ter de impedir que os seres humanos insiram dados questionáveis em um banco de dados. Joe Celko abordou o assunto em seu maravilhoso livro, dados de Joe Celko & bancos de dados: conceitos na prática (Nova York: Morgan Kaufmann, 1999). Em uma seção intitulada “modelos Versus realidade”, ele fala sobre erros em modelos, descrevendo os níveis de erro Tipo I e tipo II. Um erro do tipo I está aceitando como falso algo que é verdadeiro, e um erro do tipo II está aceitando como verdadeiro algo que é falso.
concordo sem equívoco que o assunto dos erros nos modelos é muito importante para as pessoas do banco de dados entenderem. Gerações de pessoas foram eliminadas por causa desse problema. A África Subsaariana, onde passei minha infância, será exterminada por causa da AIDS. Isso poderia ter sido evitado, mas a população ainda acredita, em geral, que a AIDS não é transmitida sexualmente e que a publicidade é apenas “propaganda Ocidental.”A fraude é de fato autoperpetuante ou autorrealizável, porque milhões de africanos ainda fazem sexo desprotegido.Sim, podemos usar truques de programação sofisticados e recursos do sistema, como gatilhos e procedimentos armazenados, para diminuir a probabilidade de dados implausíveis; podemos até construir uma verificação de integridade humana mais avançada nos aplicativos clientes. Como podemos evitar problemas como o que acabamos de descrever e ainda programar o SQL Server 2005 com a maior sabedoria possível? Para chegar a uma solução possível, vamos primeiro explorar os recursos e funções de garantia de integridade do SQL Server 2005. Após essa discussão, podemos corrigir o problema de integridade do sobrenome e oferecer à minha seguradora médica algumas idéias antes de serem processadas.