Monografia Gestão da Qualidade de Dados

Prévia do material em texto

See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/338843861
Gestão da Qualidade de Dados - Monografia de MBA em Gestão de Tecnologia da
Informação
Technical Report · October 2006
DOI: 10.13140/RG.2.2.10476.31365
CITATIONS
0
READS
58
1 author:
Some of the authors of this publication are also working on these related projects:
Improving the Quality of Information at Banco Central do Brasil View project
Marcelo Valentim Silva
Banco Central do Brasil
2 PUBLICATIONS   0 CITATIONS   
SEE PROFILE
All content following this page was uploaded by Marcelo Valentim Silva on 27 January 2020.
The user has requested enhancement of the downloaded file.
https://www.researchgate.net/publication/338843861_Gestao_da_Qualidade_de_Dados_-_Monografia_de_MBA_em_Gestao_de_Tecnologia_da_Informacao?enrichId=rgreq-94709a1ab53c9abee032a74fcdd31c96-XXX&enrichSource=Y292ZXJQYWdlOzMzODg0Mzg2MTtBUzo4NTIwNjA4MTU3NTczMTRAMTU4MDE1ODUzNzQ1MA%3D%3D&el=1_x_2&_esc=publicationCoverPdf
https://www.researchgate.net/publication/338843861_Gestao_da_Qualidade_de_Dados_-_Monografia_de_MBA_em_Gestao_de_Tecnologia_da_Informacao?enrichId=rgreq-94709a1ab53c9abee032a74fcdd31c96-XXX&enrichSource=Y292ZXJQYWdlOzMzODg0Mzg2MTtBUzo4NTIwNjA4MTU3NTczMTRAMTU4MDE1ODUzNzQ1MA%3D%3D&el=1_x_3&_esc=publicationCoverPdf
https://www.researchgate.net/project/Improving-the-Quality-of-Information-at-Banco-Central-do-Brasil?enrichId=rgreq-94709a1ab53c9abee032a74fcdd31c96-XXX&enrichSource=Y292ZXJQYWdlOzMzODg0Mzg2MTtBUzo4NTIwNjA4MTU3NTczMTRAMTU4MDE1ODUzNzQ1MA%3D%3D&el=1_x_9&_esc=publicationCoverPdf
https://www.researchgate.net/?enrichId=rgreq-94709a1ab53c9abee032a74fcdd31c96-XXX&enrichSource=Y292ZXJQYWdlOzMzODg0Mzg2MTtBUzo4NTIwNjA4MTU3NTczMTRAMTU4MDE1ODUzNzQ1MA%3D%3D&el=1_x_1&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Marcelo_Silva18?enrichId=rgreq-94709a1ab53c9abee032a74fcdd31c96-XXX&enrichSource=Y292ZXJQYWdlOzMzODg0Mzg2MTtBUzo4NTIwNjA4MTU3NTczMTRAMTU4MDE1ODUzNzQ1MA%3D%3D&el=1_x_4&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Marcelo_Silva18?enrichId=rgreq-94709a1ab53c9abee032a74fcdd31c96-XXX&enrichSource=Y292ZXJQYWdlOzMzODg0Mzg2MTtBUzo4NTIwNjA4MTU3NTczMTRAMTU4MDE1ODUzNzQ1MA%3D%3D&el=1_x_5&_esc=publicationCoverPdf
https://www.researchgate.net/institution/Banco_Central_do_Brasil?enrichId=rgreq-94709a1ab53c9abee032a74fcdd31c96-XXX&enrichSource=Y292ZXJQYWdlOzMzODg0Mzg2MTtBUzo4NTIwNjA4MTU3NTczMTRAMTU4MDE1ODUzNzQ1MA%3D%3D&el=1_x_6&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Marcelo_Silva18?enrichId=rgreq-94709a1ab53c9abee032a74fcdd31c96-XXX&enrichSource=Y292ZXJQYWdlOzMzODg0Mzg2MTtBUzo4NTIwNjA4MTU3NTczMTRAMTU4MDE1ODUzNzQ1MA%3D%3D&el=1_x_7&_esc=publicationCoverPdf
https://www.researchgate.net/profile/Marcelo_Silva18?enrichId=rgreq-94709a1ab53c9abee032a74fcdd31c96-XXX&enrichSource=Y292ZXJQYWdlOzMzODg0Mzg2MTtBUzo4NTIwNjA4MTU3NTczMTRAMTU4MDE1ODUzNzQ1MA%3D%3D&el=1_x_10&_esc=publicationCoverPdf
 
 
 
Universidade Federal de Pernambuco 
Centro de Informática 
Especialização em Gestão da Tecnologia da Informação 
 
 
 
 
Gestão da Qualidade de Dados 
 
 
 
 
 
 
Orientando: Marcelo Valentim Silva 
 
Orientador: Fernando da Fonseca de Souza 
 
 
 
 
 
 
 
Brasília, outubro de 2006 
Gestão da Qualidade de Dados 
 ii
Agradecimentos 
Eu gostaria de agradecer às sugestões dadas pelo Orientador Fernando da Fonseca 
de Souza e pela professora Flávia Barros; à compreensão dada pela minha linda esposa 
Maria e minhas lindas filhas Karime e a pequenina Ana Clara. Também não posso 
esquecer de agradecer ao enorme apoio fornecido pelo meu pai, que ao ler meu trabalho 
certamente fez melhorar em muito o conteúdo. Gostaria também de agradecer à minha mãe 
por sempre me incentivar a estudar bastante e a meus irmãos por sempre me apoiarem. 
 
Gestão da Qualidade de Dados 
 iii
Resumo 
Esta monografia exibe uma metodologia completa de Gestão da Qualidade de 
Dados, no contexto de Gestão de Conhecimento, contendo: conceitos de Qualidade de 
Dados; a importância negativa da baixa qualidade de dados; um programa de melhoria da 
Qualidade de Dados; a importância de um endosso do nível superior da organização; as 
etapas necessárias para um treinamento em Qualidade de Dados; uma política de 
responsabilidade dos dados; análises econômicas da baixa Qualidade de Dados e a 
implementação de um programa de melhoria da Qualidade de Dados. Ainda como parte da 
Metodologia descrita, esta monografia exibe as dimensões de Qualidade de Dados, o 
Controle Estatístico de Processo e informações sobre Domínios, Mapeamentos e Dados de 
Referência da Organização. 
Além desta metodologia, a monografia exibe a situação atual da área de Qualidade 
de Dados na organização, considerando as diretrizes estratégicas do Banco Central, onde 
uma delas é a de Qualidade das Informações. Descreve ainda os Departamentos envolvidos 
com esta área na organização, e entra em detalhe no Departamento onde o autor desta 
monografia trabalha. Exibe sua divisão e setor de Administração de Dados, além de um 
resumo do Ambiente Computacional de todo o Banco Central, e ferramentas utilizadas 
pelo autor no seu dia a dia. Entre estas ferramentas está o Dicionário de Dados 
Multiplataforma que serve como base para a parte prática desta monografia. 
Em seguida a monografia exibe uma proposta de atividade de Gestão da Qualidade 
de Dados, focada na obtenção de tabelas de dados de referência e, por fim, os resultados 
obtidos. Entre os resultados obtidos estão alguns grupos de tabelas com significado 
semelhante, que aparecem em dezenas de sistemas distintos, e que permitirão uma futura 
consolidação destas tabelas em poucas tabelas de domínio, ou melhor, dados de referência 
corporativos, o que aumentará a Qualidade de Dados no Banco Central do Brasil. 
Palavras-chaves: Qualidade de Dados, Qualidade da Informação, Gestão de 
Conhecimento, Domínio, e Dados de Referência. 
Gestão da Qualidade de Dados 
 iv
Abstract 
This dissertation presents a complete methodology of Data Quality Management, in 
the context of Knowledge Management, including: concepts of Data Quality; the trouble 
with of Low Data Quality; a Data Quality improvement program; the importance of senior-
level endorsement; the necessary steps of a Data Quality Training; a Data Ownership 
Policy; Economic analysis of Low Data Quality and the implementation of a Data Quality 
improvement program. 
The methodology also presents Data Quality dimensions, Statistical Process 
Control and information about Domains, Mappings and Enterprise Reference Data. 
Besides this methodology, the dissertation exhibits the present day situation of the 
Data Quality area in the Central Bank of Brazil, considering the strategic policies of the 
enterprise, including one titled “Information Quality”. It also describes the departments 
that are responsible for this area in the enterprise, and gets deep in detail on the department 
where the author of the dissertation works. It presents his division and sector, besides an 
overview of the Computational Environment of the entire Central Bank, as well as, tools 
used by the author on his daily activities. Among these tools is the Multiplatform Data 
Dictionary, which serves as basis for the practical part of this dissertation. 
The next steps of the dissertation present a proposal of an activity of Data Quality 
Management, focused on obtaining reference data tables and, at the end, the results. 
 Amongst the obtained results are some groups of tables with similar meaning, that 
appear on dozens of distinct systems, and that will allow a future consolidation of these 
tables on some domain tables, or even better, on enterprise reference data, which will 
improve the amount of Data Quality in the Central Bank of Brazil. 
Keywords: Data Quality, Information Quality, Knowledge Management, Domain, 
and Reference Data. 
Gestão da Qualidadede Dados 
 v
Sumário 
LISTA DE FIGURAS VIII 
CAPÍTULO 1 INTRODUÇÃO 1 
1.1 MOTIVAÇÃO 1 
1.2 OBJETIVO 1 
1.3 TRABALHO REALIZADO 1 
1.4 ORGANIZAÇÃO DO DOCUMENTO 2 
CAPÍTULO 2 GESTÃO DE CONHECIMENTO E QUALIDADE DE DADOS 4 
2.1 PORQUE A QUALIDADE DE DADOS É FUNDAMENTAL PARA GESTÃO DE 
CONHECIMENTO 5 
2.2 RAZÕES PARA SE PREOCUPAR COM A QUALIDADE DE DADOS 6 
2.2.1 QUALIDADE BAIXA DE DADOS PODE CAUSAR PROBLEMAS OPERACIONAIS 6 
2.2.2 QUALIDADE BAIXA DE DADOS PREJUDICA A TOMADA DE DECISÕES 7 
2.2.3 ALTA QUALIDADE DE DADOS INCENTIVA O USO DE DATA WAREHOUSES (DW) 8 
2.2.4 DADOS RUINS CAUSAM INSATISFAÇÕES NOS CLIENTES 8 
2.2.5 DADOS RUINS RESTRINGEM PROJETOS DE MIGRAÇÃO DE DADOS 8 
2.3 PROPRIETÁRIOS DAS INFORMAÇÕES 9 
2.4 QUALIDADE DE DADOS 10 
2.5 PROGRAMA DE MELHORIA DA QUALIDADE DE DADOS 12 
2.5.1 ENDOSSO DO NÍVEL SUPERIOR DA ORGANIZAÇÃO 12 
2.5.2 TREINAMENTO EM QUALIDADE DE DADOS 14 
2.5.3 POLÍTICA DE RESPONSABILIDADE DOS DADOS 15 
2.5.4 ANÁLISE DO IMPACTO ECONÔMICO RELACIONADO À QUALIDADE BAIXA DE DADOS 15 
2.5.5 AVALIAÇÃO DO ESTADO ATUAL E ANÁLISE DE REQUISITOS 15 
2.5.6 SELEÇÃO DE UM PROJETO 16 
Gestão da Qualidade de Dados 
 vi
2.5.7 IMPLEMENTAÇÃO E IMPLANTAÇÃO DA MELHORIA 17 
2.6 QUALIDADE DE DADOS E OPERAÇÕES 17 
2.7 QUALIDADE DE DADOS E BANCOS DE DADOS 17 
2.7.1 BANCOS DE DADOS LEGADOS 19 
2.8 QUALIDADE DE DADOS E DATA WAREHOUSE 20 
2.8.1 CERTIFICAÇÃO DE DATA WAREHOUSE 20 
2.9 QUALIDADE DE DADOS E DATA MINING 22 
2.10 QUALIDADE DE DADOS E INTERCÂMBIO ELETRÔNICO DE DADOS 22 
2.10.1 XML 23 
2.11 DIMENSÕES DE QUALIDADE DE DADOS 23 
2.11.1 DIMENSÕES DE QUALIDADE DE DADOS REFERENTES A VALORES DE DADOS 24 
2.11.2 DIMENSÕES DE QUALIDADE DE DADOS REFERENTES A DOMÍNIOS DE DADOS 27 
2.12 CONTROLE ESTATÍSTICO DE PROCESSO E O CICLO DE MELHORIA 28 
2.12.1 O PRINCÍPIO DE PARETO 29 
2.12.2 GRÁFICO DE CONTROLE 30 
2.12.3 OS OBJETIVOS DO CONTROLE ESTATÍSTICO DE PROCESSO 32 
2.13 DOMÍNIOS, MAPEAMENTOS E DADOS DE REFERÊNCIA DA ORGANIZAÇÃO 35 
2.13.1 DOMÍNIOS 35 
2.13.2 TIPOS DE DOMÍNIOS 36 
2.13.3 GESTÃO DE CONHECIMENTO E CATÁLOGO DE DOMÍNIOS 37 
2.13.4 MAPEAMENTOS 37 
2.13.5 DOMÍNIOS E MAPEAMENTOS COMO DADOS DE REFERÊNCIA 38 
2.13.6 MODELO DE PUBLICAÇÃO E ASSINATURA DE DADOS DE REFERÊNCIA 38 
2.13.7 DADOS DE REFERÊNCIA E GERENTES DE DADOS (DATA STEWARDS) 39 
2.13.8 CONCORDÂNCIA DE USO 40 
2.13.9 PUBLICAÇÃO DOS DADOS DE REFERÊNCIA 40 
CAPÍTULO 3 QUALIDADE DE DADOS NO BANCO CENTRAL DO BRASIL 41 
3.1 DIRETRIZES DO BANCO CENTRAL DO BRASIL 41 
3.2 DESIG (DEPARTAMENTO DE SUPERVISÃO INDIRETA E GESTÃO DA INFORMAÇÃO) 42 
3.3 DEINF (DEPARTAMENTO DE TECNOLOGIA DA INFORMAÇÃO) 43 
Gestão da Qualidade de Dados 
 vii
3.3.1 DINAM (DIVISÃO DE INTELIGÊNCIA DE NEGÓCIO E ADMINISTRAÇÃO DE DADOS) 44 
3.3.2 SUDAD (SUBDIVISÃO DE ADMINISTRAÇÃO E MODELAGEM DE DADOS) 44 
3.3.3 AMBIENTE COMPUTACIONAL DO BANCO CENTRAL DO BRASIL 45 
3.3.4 DDM (DICIONÁRIO DE DADOS MULTIPLATAFORMA) 45 
3.3.5 CONSULTAS AO DDM 46 
3.3.6 FERRAMENTA DE WORKFLOW DE PEDIDOS DE ALTERAÇÃO DE MODELOS 50 
3.3.7 DOCUMENTOS CRIADOS PELA ADMINISTRAÇÃO DE DADOS 52 
3.3.8 QUALIDADE DE DADOS NA DINAM 55 
CAPÍTULO 4 APLICAÇÃO DE QUALIDADE DE DADOS NO BACEN 57 
4.1 EXTRAÇÃO DE DADOS DO REPOSITÓRIO DO DICIONÁRIO DE DADOS 
MULTIPLATAFORMA (DDM) 58 
4.2 CORREÇÃO DA BASE NO MICROSOFT ACCESS 59 
4.2.1 CORREÇÃO DE USERVIEWS 61 
4.2.2 CORREÇÃO DE TABELAS ADABAS 63 
4.2.3 CORREÇÃO DE TABELAS RELACIONAIS – AMBIENTE DE PRODUÇÃO DB2/SQL SERVER66 
4.2.4 CORREÇÃO DE TABELAS RELACIONAIS – AMBIENTE DE LEGADO NO SQL SERVER 68 
4.2.5 SITUAÇÃO APÓS AS CORREÇÕES 69 
4.2.6 OBTENÇÃO DE TABELAS DE DADOS DE REFERÊNCIA 70 
4.2.7 OBTENÇÃO DE GRUPOS DE DADOS DE REFERÊNCIA 71 
CAPÍTULO 5 CONCLUSÃO E TRABALHOS FUTUROS 73 
REFERÊNCIA BIBLIOGRÁFICA 75 
APÊNDICES 76 
Gestão da Qualidade de Dados 
 viii 
Lista de Figuras 
FIGURA 2.1 - NOMES SIMILARES DE CIDADES ____________________________________ 7 
FIGURA 2.2 - EXEMPLO DE PROCESSO_________________________________________ 30 
FIGURA 2.3 - EXEMPLO DE DADOS ESTATÍSTICOS IN [LOSHIN, 2001] _________________ 33 
FIGURA 3.1 - ORGANOGRAMA DO DEPARTAMENTO DE SUPERVISÃO INDIRETA E GESTÃO DA 
INFORMAÇÃO (DESIG) ________________________________________________ 42 
FIGURA 3.2 - ORGANOGRAMA DO DEPARTAMENTO DE TECNOLOGIA DA INFORMAÇÃO 
(DEINF)____________________________________________________________ 43 
FIGURA 3.3 - DDM (DICIONÁRIO DE DADOS MULTIPLATAFORMA) __________________ 45 
FIGURA 3.4 - VISÃO DO DESENVOLVEDOR DE APLICAÇÕES ________________________ 46 
FIGURA 3.5 - LISTAGEM DE BASES ADABAS ____________________________________ 46 
FIGURA 3.6 - LISTAGEM DOS OBJETOS DA BASE ADM ____________________________ 47 
FIGURA 3.7 - LISTAGEM DE BASES RELACIONAIS________________________________ 48 
FIGURA 3.8 - PESQUISA NO REPOSITÓRIO DE METADADOS POR PALAVRA CHAVE________ 49 
FIGURA 3.9 - FERRAMENTA RATIONAL CLEAR QUEST ____________________________ 50 
FIGURA 3.10 - EXEMPLO DE PEDIDO NO CLEAR QUEST ___________________________ 51 
FIGURA 3.11 - NOMENCLATURA DE OBJETOS DB2_______________________________ 52 
FIGURA 3.12 - LEGENDA DA NOMENCLATURA DE OBJETOS DB2____________________ 53 
FIGURA 3.13 - TIPOS DE COLUNA ____________________________________________ 53 
FIGURA 3.14 – EXEMPLOS DE COMENTÁRIOS ACEITOS ___________________________ 54 
FIGURA 3.15 - VERIFICADOR SINTÁTICO ______________________________________ 54 
FIGURA 4.1 - ALGUNS SISTEMAS EXISTENTES NO REPOSITÓRIO DO DDM______________ 59 
FIGURA 4.2 - DISTRIBUIÇÃO DE TABELAS DUPLICADAS ___________________________ 60 
FIGURA 4.3 - USERVIEWS COM SISTEMAS ESPERADOS INEXISTENTES _________________ 62 
FIGURA 4.4 - LISTAGEM DE ALGUMAS USERVIEWS COM NOMES DE SISTEMAS INCORRETOS 62 
FIGURA 4.5 - LISTAGEM DE USERVIEWS FORA DO PADRÃO USSS999R _______________ 63 
Gestão da Qualidade de Dados 
 ix
FIGURA 4.6 - LISTAGEM DE ALGUMAS TABELAS QUE CONTINUARAM SEM DEFINIÇÃO DE 
SISTEMA ___________________________________________________________ 64 
FIGURA 4.7 - ALGUMAS TABELAS QUE SEGUEM A REGRA “SISTEMA_DESCRIÇÃO_DA_TABELA”65 
FIGURA 4.8 - LISTAGEM DE 2 TABELAS DE DW CORRETAS SEGUIDAS DE TABELAS COM 
FORMATO INCORRETO _________________________________________________ 65 
FIGURA 4.9 - ALGUMAS TABELAS DW QUE SEGUEM O PADRÃO SSSTB_ABC_ ________ 66 
FIGURA 4.10 - SISTEMAS ANTIGOS DO AMBIENTE DE PRODUÇÂO QUE NÃO SEGUEM 
PADRÃO COM “_” ____________________________________________________ 67 
FIGURA 4.11 - ALGUMAS TABELAS DE PRODUÇÃO COM PREFIXO CORRETO__________ 67 
FIGURA 4.12 - ALGUMAS TABELAS DE HISTÓRICO NA PRODUÇÃO_________________ 68 
FIGURA 4.13 - LISTA DE TABELAS DO LEGADO SQL SERVER FORA DO PADRÃO______ 69 
FIGURA 4.14 - DISTRIBUIÇÃO DE TABELAS QUE NÃO MUDARAM DE NOME _____________ 69 
FIGURA 4.15 - LISTAGEM DE TABELAS QUE APARECEM MAIS DE 6 VEZES______________ 70 
FIGURA 4.16 - LISTAGEM DE TABELAS DO GRUPO DE DADOS DE REFERÊNCIA CADASTRO 71 
FIGURA 4.17 - LISTAGEM DE TABELAS AGRUPADAS POR SEMELHANÇA DE NOMES _______ 72 
 
 
Gestão da Qualidade de Dados 
 1
Capítulo 1 Introdução 
1.1 Motivação 
Existem duas motivações prioritárias nesta monografia. A motivação inicial deste 
trabalho de pesquisa é a melhoria na Qualidade dos Dados existentes nos ambientes 
computacionais do Banco Central do Brasil, pois existem várias ocorrências de baixa 
qualidade de dados, principalmente devido à maioria dos dados ter sua origem em 
ambiente de Mainframe, onde a integridade de dados não recebe a prioridade apropriada. 
Outra motivação importante é a proveniente de uma diretriz estratégica do Banco 
Central do Brasil relativa à Qualidade das Informações, detalhada como: “garantia de 
qualidade dos dados e das informações, inclusive com a integração de sistemas, de forma a 
permitir a melhoria do atendimento ao público, o aperfeiçoamento do desempenho 
gerencial e a redução dos custos e do tempo dos procedimentos”. 
1.2 Objetivo 
Desenvolver e aplicar uma metodologia de Gestão da Qualidade de Dados incluídaem um processo maior de Gestão de Conhecimento da organização, focalizado nos 
conjuntos de dados existentes nos ambientes computacionais do Banco Central do Brasil. 
1.3 Trabalho Realizado 
Esta monografia exibe uma metodologia completa de Gestão da Qualidade de 
Dados, a situação atual da área de Qualidade de Dados no Banco Central do Brasil, uma 
proposta prática de atividade de Gestão da Qualidade de Dados focada na obtenção de 
tabelas de dados de referência e os resultados obtidos. Entre eles estão alguns grupos de 
tabelas com significado semelhante, que aparecem em dezenas de sistemas distintos, e que 
permitirão uma futura consolidação destas tabelas em poucas tabelas de domínio, ou 
melhor, dados de referência corporativos, o que aumentará a Qualidade de Dados no Banco 
Central do Brasil. 
Gestão da Qualidade de Dados 
 2
1.4 Organização do Documento 
Além desta introdução, esta monografia conta com mais cinco capítulos, descritos a 
seguir. 
Capítulo 2 – Gestão de Conhecimento e Qualidade de Dados: Esse capítulo 
apresenta o problema da Baixa Qualidade de Dados existente em praticamente todos os 
ambientes computacionais, e exibe uma metodologia completa de Gestão de Conhecimento 
com ênfase na Qualidade de Dados. Exibe conceitos de Qualidade de Dados; um programa 
de melhoria da Qualidade de Dados; a importância de um endosso do nível superior da 
organização; as etapas necessárias para um treinamento em Qualidade de Dados; uma 
Política de Responsabilidade dos Dados, pois dados que não tenham responsáveis 
definidos não têm como obter qualidade; análises econômicas da baixa Qualidade de 
Dados e a implementação do programa de melhoria da Qualidade de Dados. 
Neste capitulo são também exibidas as relações entre Qualidade de Dados e várias 
áreas, como Operações, Bancos de Dados, Data Warehouse, Data Mining e Intercambio 
Eletrônico de Dados (mais conhecido na atualidade como padrão XML). 
Ainda como parte da Metodologia descrita, este capítulo exibe as dimensões de 
Qualidade de Dados, o Controle Estatístico de Processo e informações sobre Domínios, 
Mapeamentos e Dados de Referência da Organização. 
Capítulo 3 – Qualidade de Dados no Banco Central do Brasil: Esse Capítulo 
apresenta a situação atual da área de Qualidade de Dados na organização, considerando as 
diretrizes estratégicas do Banco Central, onde uma delas é a de Qualidade das 
Informações. Descreve ainda os Departamentos envolvidos com esta área na organização, 
e entra em detalhe no Departamento onde o autor desta monografia trabalha. Exibe sua 
divisão e setor de Administração de Dados, além de um resumo do Ambiente 
Computacional de todo o Banco Central e ferramentas utilizadas pelo autor no seu dia a 
dia. Entra estas ferramentas está o Dicionário de Dados Multiplataforma que serve como 
base para a parte prática desta monografia, exibida nos capítulos posteriores. 
Gestão da Qualidade de Dados 
 3
Este capítulo ainda exibe alguns procedimentos realizados no setor de 
Administração de Dados relativos explicitamente à Gestão de Qualidade de Dados. 
Capítulo 4 – Aplicação de Qualidade de Dados no Bacen: Nesse capítulo surge 
a definição da atividade proposta assim como os procedimentos efetuados e os resultados 
obtidos. 
Capítulo 5 – Conclusão e Trabalhos Futuros: Esse capítulo conclui a monografia 
com um breve resumo das principais contribuições, incluindo a descrição dos principais 
grupos de Dados de Referência obtidos, apontando algumas limitações, além das 
possibilidades de trabalhos futuros. 
 
 
 
Capítulo 2 Gestão de Conhecimento e Qualidade de 
Dados 
Este capítulo descreve em detalhes uma metodologia baseada em (Loshin, 2001). 
Nos últimos 30 anos, avanços na tecnologia de banco de dados fizeram surgir 
grandes bases de dados legadas controladas por software legado. O paradigma de 
programação existente na época colocava regras de negócio e políticas de validação de 
dados dentro do próprio código da aplicação. E, para complicar, a maioria das aplicações 
legadas era e ainda é mantida por pessoas que não desenvolveram o código, ou seja, não 
tem experiência nem no projeto nem na implementação dos sistemas originais. O caso do 
bug do ano 2000, que envolvia a correção de todos os campos de datas que poderiam estar 
com apenas 2 dígitos para o ano, foi um exemplo bastante comum e trabalhoso. O Banco 
Central do Brasil ainda possui grande quantidade de dados em bases legadas Adabas sendo 
gerenciadas por processos em linguagem legada Natural que estão em processo de 
migração para bases em DB2 a serem manipulados por aplicações em linguagem Java. 
A coleção de dados de uma organização é um recurso de negócio valioso que ainda 
é em grande parte pouco aproveitado. A tecnologia evoluiu para distribuir as bases de 
dados e junto com este processo surgiu uma metodologia que tenta integrar os assuntos 
técnicos, organizacionais e comportamentais associados ao conhecimento organizacional. 
Esta metodologia é referida como “Gestão de Conhecimento”. 
O Gartner Group define Gestão de Conhecimento como “uma disciplina que 
promove uma visão integrada de identificação, gerencia e compartilhamento de todos os 
bens de informação de uma organização. Estes bens de informação podem incluir bases de 
dados, documentos, políticas e procedimentos assim como competências não articuladas 
Gestão da Qualidade de Dados 
 5
previamente e experiências próprias dos funcionários”1. Enquanto a Gestão de 
Conhecimento inclui várias disciplinas como Gestão de Documentos, ou e-mails, o foco 
deste trabalho é nos conhecimentos embutidos nos conjuntos de dados que podem ser 
expressados por um conjunto de regras de negócio. 
Quando as regras de negócio não são documentadas, existem grandes chances de 
que os significados ou implicações destas regras serão perdidos em um curto período de 
tempo. O conhecimento é perdido quando os funcionários deixam a organização ou 
mudam de posição internamente ou quando os gerentes têm muito controle sobre a 
informação e falham na comunicação interna. Quando as regras de negócio são perdidas, a 
oportunidade para se tirar proveito dos recursos de informação também é perdida. 
2.1 Porque a qualidade de dados é fundamental para Gestão de 
Conhecimento 
A oportunidade para se tirar proveito dos recursos de dados e informações só pode 
ocorrer se houver um entendimento da estrutura e conhecimento das coleções de 
informações. Para tanto deve existir um método formal para a coleta, documentação e 
validação de regras de negócio. A metodologia descrita neste trabalho tenta garantir que a 
qualidade da informação que está presente no sistema satisfaça ou ultrapasse as 
expectativas pré-definidas. Para garantir essa qualidade é necessário um processo de 
descrição de requisitos de informação seguido por um processo de validação destes 
requisitos. 
Atualmente, está sendo bastante praticada a transferência de dados transacionais 
para um ambiente de processamento analítico, como Data Warehouse (DW), que serve 
como ferramenta muito útil para gestão de conhecimento quando utilizada corretamente. 
Um grande componente do processo de DW é a extração e transformação de dados de 
sistemas fonte ou legados para o ambiente de DW. Este processo de extração é um ponto 
 
1 http: //cestec1.mty.itesm.mx~laava/sdsites/cursos/pqg_base/definicion1.htm 
Gestão da Qualidade de Dados 
 6
importante onde as regras de negócio podem ser tanto descobertas como usadas para 
garantir a qualidade de dados de toda a organização. 
Devido a um crescente reconhecimento da qualidade de dados como uma 
responsabilidade organizacional, está surgindo a necessidade de uma Gestão da Qualidade 
de Dados. De acordo com o Gartner Group em Hill(1988), “É crítico, para as organizações, 
desenvolver um programa de qualidade de dados e garantir que este seja conduzido. Um 
pontochave neste esforço é identificar gerentes dos dados (“data stewards”) nas áreas fins, 
onde a responsabilidade pelos dados esteja claramente definida... As organizações podem 
minimizar as inconsistências de dados através de um melhor entendimento dos parâmetros 
que governam o significado e a movimentação dos dados.” 
O uso de gestão da qualidade de dados como uma ferramenta para gestão de 
conhecimento, segundo as definições acima, é o objetivo principal deste trabalho. 
2.2 Razões para se preocupar com a Qualidade de Dados 
O problema da qualidade de dados existe em organizações de todas as áreas. Dados 
ruins representam custos e reduzem a produtividade. O tempo que é gasto diagnosticando e 
corrigindo dados errados é um tempo que não é gasto produtivamente. Isto sem contar 
quando os dados nem são corrigidos. Uma qualidade baixa de dados pode, inclusive, 
reduzir a satisfação por parte dos clientes. Por exemplo, clientes expostos a relatórios 
incorretos são menos propensos a confiar na organização que produz estes relatórios. 
Finalmente, decisões estratégicas baseadas em informações não confiáveis podem resultar 
em decisões incorretas e possivelmente catastróficas. 
2.2.1 Qualidade baixa de dados pode causar problemas operacionais 
Quando um produto desenvolvido em uma cadeia de manufatura não segue os 
padrões requeridos em um estágio específico, ele deve ser descartado ou corrigido antes 
que continue na linha de manufatura. O mesmo deve ocorrer com a informação. Quando 
um registro de dado é considerado como incorreto, este registro precisa ser apagado ou 
corrigido durante o processamento. Em algumas vezes esta ação significa o atraso de todo 
o fluxo de processamento, apesar de que o mais provável é que os registros sejam deixados 
Gestão da Qualidade de Dados 
 7
de lado e o fluxo siga em frente, deixando os registros incorretos para serem lidados 
posteriormente. 
Quando o nível da qualidade de dados decresce, as ações de correção se tornam 
mais freqüentes. Isto faz com que mais funcionários sejam alocados nas correções, o que 
acaba causando um problema operacional. 
Outra ocorrência de problemas em sistemas devido a dados ruins são os acessos a 
bases de dados com balanceamento de carga, baseados na distribuição de dados em um 
atributo que pode levar a um balanceamento totalmente incorreto se metade dos registros 
referenciados tiver um campo de índice com conteúdo vazio. 
2.2.2 Qualidade baixa de dados prejudica a tomada de decisões 
Informações podem ser usadas para processamento operacional ou analítico. Se os 
dados forem usados para processamento analítico ou suporte de decisões, a qualidade dos 
dados pode afetar as análises. Se a gerência superior confia em resultados das análises, eles 
podem confiar em conclusões tomadas a partir de suposições incorretas. Se estes gerentes 
estiverem cientes da baixa qualidade dos dados eles podem optar por adiar a tomada de 
decisão até que melhores informações sejam coletadas. 
Eis um exemplo: Após a integração de duas bases provenientes de sistemas 
distintos, podem existir os seguintes valores, exibidos na Figura 2.1. 
Cidade Valor 
Total por 
cidade 
SP 500 
São Paulo 2000 
S. Paulo 800 
Sao Paulo 200 3500 
RJ 300 
Rio de Janeiro 2100 2400 
Figura 2.1 - Nomes similares de cidades 
Observe que, se for analisado o valor individual associado diretamente à cidade, o 
item Rio de Janeiro, com 2100 é o item de maior valor. Se a gerência superior precisar 
Gestão da Qualidade de Dados 
 8
fazer o investimento na cidade com o maior valor ela pode vir a escolher esta cidade, o que 
é uma decisão incorreta, pois o total de São Paulo, com quatro nomes diferentes soma 
3500. Em qualquer situação onde houver algum tipo de ranking torna-se necessária uma 
limpeza detalhada dos valores possíveis para que algo parecido não ocorra. 
2.2.3 Alta qualidade de dados incentiva o uso de Data Warehouses (DW) 
Se a informação, proveniente na maioria das vezes de bases legadas, for de 
qualidade baixa e estiver sendo utilizada em Data Warehouses, provavelmente uma grande 
quantidade de tempo será gasta na procura e remoção dos erros. Como muitos DW são 
recarregados com curta periodicidade (como por exemplo, carga total diária) e se o tempo 
necessário para corrigir os dados for maior do que o tempo de recarga, a base se torna 
rapidamente desatualizada e, portanto, pouco útil para os fins desejados. 
O estágio de carga de dados é a melhor oportunidade para se incluir validação e 
padronização da qualidade de dados, pois bons dados no DW aumentam o interesse geral 
pelo seu uso. 
2.2.4 Dados ruins causam insatisfações nos clientes 
Quando os clientes descobrem erros diretamente nos relatórios, pode parecer que a 
organização não tem como corrigir estes erros de forma proativa. Esta conclusão pode 
surgir porque são os próprios clientes que descobriram os erros. Isto pode causar graves 
danos para a imagem da organização. 
2.2.5 Dados ruins restringem Projetos de Migração de Dados 
O componente mais frustrante nos projetos de migração de dados legados para 
plataformas distribuídas é a dificuldade de obtenção das informações corretas sobre os 
dados e os sistemas que estão sendo migrados. Usualmente, isto é devido à tendência dos 
desenvolvedores de programarem primeiro e documentarem depois (se documentarem). E, 
conforme os sistemas evoluem no tempo, estes são modificados, corrigidos ou melhorados, 
mas normalmente sem que seja feita a atualização na documentação. O Banco Central do 
Brasil está passando por um período de grande quantidade de migrações de dados de 
sistemas legados. 
Gestão da Qualidade de Dados 
 9
2.3 Proprietários das informações 
Em uma metodologia de gestão da qualidade de dados é necessário saber quem são 
os proprietários das informações nas organizações. Neste trabalho, tais proprietários serão 
chamados daqui para frente de responsáveis pelas informações. 
Sem uma distribuição de responsabilidade, é quase impossível medir a qualidade 
dos dados, quanto menos efetuar melhorias nestes. Para detalhar melhor estas 
responsabilidades, devem ser analisados os papéis ou atores que podem existir: 
1. Fornecedor - Fornece dados que geram informação ao sistema; 
2. Adquirente - Aceita dados de fornecedores externos para inserção na organização; 
3. Criador - Internamente à organização, dados podem ser criados e encaminhados a 
outro estágio de processamento; 
4. Processador - Qualquer agente que aceita entradas e gera saídas, trazendo 
possivelmente algum efeito adicional; 
5. Empacotador - Adiciona, agrega e sumariza informação para confecção de 
determinados relatórios; 
6. Agente de entrega - Entrega informação empacotada para um consumidor de dados 
conhecido; 
7. Consumidor de dados - Usuário final da informação processada; 
8. Gerente intermediário - Pessoa responsável por garantir que os atores estão 
realizando corretamente suas funções; 
9. Gerente superior - Responsável pela operação global da organização; e 
10. Decisor - Gerente superior responsável por tomadas de decisão estratégicas e 
táticas. 
Na essência, a responsabilidade pelos dados significa o controle da informação 
como um bem organizacional. Este controle inclui não somente a habilidade para acessar, 
criar, modificar, empacotar, obter benefícios e remover dados, mas também o direito de: 
- Designar privilégios de acessos a outras pessoas; 
Gestão da Qualidade de Dados 
 10
- Gerenciar a inserção de dados, criando métricas associadas aos estes e 
procedimentos de ETL (Extração, Transformação e Carga dos Dados); 
- Gerenciar as regras de negócio, estejam elas no código da aplicação, 
abstraídas em um formato de regras ou simplesmente documentadas 
separadamente da implementação; 
- Gerenciar os metadados, o que inclui as definições de dados, seus nomes, 
tipos, domínios, restrições, tabelas, relacionamentos, usuários, direitosde 
acesso, entre outros; 
- Garantir que sejam seguidos padrões corporativos de nomenclatura; 
- Gerenciar dados fornecidos por terceiros; e 
- Manter a qualidade da informação definindo expectativas, métricas de 
qualidade e fornecendo relatórios de conformidade de qualidade de dados. 
Isto também inclui definir políticas de qualidade de dados para todos os 
dados que passam pelo sistema e qualquer processo de limpeza de dados e 
padronização. 
2.4 Qualidade de dados 
Existem várias visões da Qualidade de Dados. Para o gerente responsável pela 
distribuição de correspondência, qualidade de dados significa endereços de entrega sem 
erros (SP = S.Paulo) e “deduplicados” (eliminados de duplicações). Para o gerente de 
contas, qualidade de dados significa agregação correta da atividade dos clientes (RJ e Rio 
são a mesma cidade). Para a indústria médica, qualidade de dados pode significar uma 
habilidade refinada para conectar registros de pacientes. Claramente, cada definição é 
orientada para a visão individual do que é “bom” e do que não é. Isto leva à conclusão de 
que não existe uma definição única e simples. Em vez disto, qualidade de dados deve ser 
definida em termos de como cada consumidor deseja usar os dados. 
No sentido mais geral, pode-se usar uma definição qualitativa de qualidade de 
dados e refinar esta definição conforme o caso. Em essência, define-se qualidade de dados 
Gestão da Qualidade de Dados 
 11
em termos de adequação ao uso (fitness), ou seja, o nível de qualidade de dados 
determinado pelos consumidores de dados para satisfazer ou exceder as expectativas. Na 
prática, isto significa identificar objetivos de qualidade de dados associados a um conjunto 
de dados e então medir este conjunto de dados em conformidade com estes objetivos. 
Duas técnicas comuns para a melhoria da Qualidade de Dados são: 
- Limpeza estática de dados de nomes e endereços; e 
- Produtos que conectam registros de dados baseados em campos específicos 
de dados. 
Entretanto, deve ficar bem claro que o uso de ferramentas para a execução destas 
técnicas não significa a solução para o problema da qualidade de dados. Em vez disto, a 
melhor forma para se lidar com a qualidade de dados em uma organização é definir um 
conjunto de expectativas sobre os dados, fazer medições em relação a estas expectativas e 
melhorar continuamente até que as expectativas sejam satisfeitas. 
O que se provou difícil até agora é que, devido ao fato de que os conjuntos de 
dados de cada caso são diferentes, não existem formas bem definidas de se descrever as 
expectativas de qualidade de dados. Neste trabalho será avaliada esta necessidade com o 
desenvolvimento de ferramentas necessárias para, determinar se existe um problema de 
qualidade de dados, medir o custo da qualidade baixa de dados, avaliar o estado atual dos 
dados da organização e desenvolver regras de qualidade de dados que possam ser usadas 
para medição. 
Para refinar a definição de adequação ao uso, a primeira área a ser focada é a 
limitação da ruindade dos dados. Isto pode ser referido como “minimização de defeitos”, 
onde um defeito é qualquer situação onde os valores dos dados não são acessíveis ou não 
correspondem com exatidão a uma referência estabelecida. 
Gestão da Qualidade de Dados 
 12
Eis abaixo uma lista dos tipos de defeitos que devem ser evitados: 
- Inacessibilidade; 
- Inexatidão; 
- Informação não atualizada; 
- Informação redundante não gerenciável; 
- Inconsistência com outras fontes; 
- Dados incompletos; e 
- Dados incompreensíveis. 
Por outro lado, é desejável que a informação tenha características de um ambiente 
de alta qualidade. Eis uma lista das características desejáveis: 
- A informação existe no tempo certo (ex. Existia em Janeiro e Março de um mesmo 
ano, mas não em Fevereiro do mesmo ano, quando deveria existir); 
- O modelo de dados completa e exatamente modela o equivalente no mundo real; 
- A informação é apresentada em uma forma fácil de entender; 
- O nível apropriado de detalhe é mantido; e 
- A informação capturada tem significado em um contexto apropriado. 
2.5 Programa de melhoria da qualidade de dados 
Em cada processo de melhoria existem etapas que precisam ser consideradas para 
se atingir uma melhoria demonstrável e mensurável. Eis abaixo as etapas: 
2.5.1 Endosso do nível superior da organização 
Um projeto de melhoria da qualidade de dados não pode ter sucesso se não tiver o 
endosso da gerência de nível superior. Infelizmente, obter tal apoio pode ser muito mais 
difícil do que se imagina. Existem várias razões interessantes para tanto: 
Síndrome “Não é minha culpa” 
Ninguém quer admitir que possam existir erros em seu trabalho. Qualidade baixa 
de dados implica que existem erros em algum lugar do sistema. Isto é especialmente 
verdadeiro em lugares em que os funcionários são recompensados por um trabalho bem 
Gestão da Qualidade de Dados 
 13
feito. Raramente os funcionários admitem seus próprios erros ou chamam a atenção de 
seus subordinados. 
“As novas roupas do Imperador” 
As pessoas normalmente assumem que as ações de uma pessoa numa posição de 
autoridade superior são naturalmente corretas e apropriadas e que seria tolice desafiar o 
status quo. Neste caso, tentar encontrar e corrigir problemas de qualidade de dados pode 
até ser um risco à segurança do emprego. 
Negação de Responsabilidade 
A resposta natural quando uma grande falha ocorre é apontar na direção de outra 
pessoa. Poucos têm a capacidade de aceitar que a existência de qualidade baixa de dados 
possa ser devido a sua própria responsabilidade e então a responsabilidade sobre a 
qualidade de dados fica passando de escrivaninha em escrivaninha, nunca parando em 
lugar algum. 
Falta de entendimento 
Geralmente qualidade de dados é confundida com “limpeza de dados”, 
“deduplicação” ou padronização de nomes e endereços. Enquanto todos estes itens são 
partes integrantes de um programa de qualidade de dados, uma rodada periódica de 
limpeza de dados não substitui um programa de gestão de conhecimento, integrado com 
uma melhoria contínua da qualidade de dados. 
Sensação de trabalho sujo 
Infelizmente existe uma sensação de que procurar problemas e limpar “bagunças” 
de dados constitui-se num trabalho sujo e inglório. Assim sendo, o envolvimento em 
atividades de qualidade de dados pode ser visto como uma “ação sem futuro na 
organização”. 
Falta de reconhecimento 
Existe sempre alguma expectativa (por consumidores de dados) de que as coisas 
deveriam ser corretas. Para tanto se espera que as coisas sejam feitas da forma correta. Os 
funcionários que se esforçam para garantir que tudo pareça correto são vistos como apenas 
Gestão da Qualidade de Dados 
 14
fazendo seu trabalho e não são reconhecidos por estarem executando uma tarefa 
extremamente importante de gestão de conhecimento. 
Para que se evitem as conotações negativas associadas com a qualidade de dados, 
os gerentes superiores precisam se dar conta que um conjunto integrado de soluções de 
qualidade de dados pode adicionar valor à organização. Isto pode ser obtido através de 
certo número de etapas, incluindo um treinamento em gestão de conhecimento e qualidade 
de dados, seguido pela criação e endosso de uma política de responsabilidade de dados, 
junto com uma análise que demonstre o impacto econômico da qualidade baixa de dados e 
o valor econômico da mensurável alta qualidade de dados. 
2.5.2 Treinamento em qualidade de dados 
O treinamento em qualidade de dados inicia-se com o entendimento dos princípios 
do que significa a qualidade no contexto da informação. Um programa de treinamento em 
qualidade de dados deveria incorporar visões gerais e discussões sobre os seguintes 
conceitos: 
• Criação, uso e armazenamento da informação; 
• Responsabilidade dos dados; 
• Conceitos de qualidade e do ciclo de melhoria da qualidade; 
• Impacto econômicoda qualidade de dados; 
• Dimensões de qualidade de dados; 
• Aspectos de domínio de dados de referência; 
• Regras de qualidade de dados e de negócios; 
• Métricas para medir e avaliar qualidade de dados; 
• Metadados; 
• Análise de requisitos de Qualidade de Dados; 
• Limpeza de dados e padronização; 
• Detecção de erros, correção e análise de causas usando regras de qualidade de 
dados; e 
• Melhoria dos dados. 
Gestão da Qualidade de Dados 
 15
2.5.3 Política de responsabilidade dos dados 
Esta política governa as responsabilidades sobre as coleções de informação 
existentes na organização. Sem esta política, não há como gerenciar os dados, então, antes 
que os próximos passos sejam executados, os gerentes superiores precisam estabelecer, 
aprovar e publicar uma política de responsabilidade de dados, assim como definir e 
incorporar os procedimentos para cobrança das exigências desta política. 
2.5.4 Análise do impacto econômico relacionado à qualidade baixa de dados 
Após ter a política e os procedimentos de cobrança definidos pela organização, o 
próximo passo será identificar as áreas que têm a maior necessidade de melhoria. Na 
análise do impacto econômico relacionado à qualidade baixa de dados, descrita neste 
artigo, é fornecido um mecanismo que caracteriza o impacto real da qualidade de dados, 
tanto dentro como fora da organização. Eis as etapas deste mecanismo: 
• Procurar por sinais de problemas de qualidade de dados; 
• Mapear o fluxo de informação dentro, através e fora da organização; 
• Caracterizar os impactos da qualidade baixa de dados em estágios específicos da 
cadeia de informação; 
• Medir o custo do impacto da qualidade baixa de dados; e 
• Construir o scorecard da qualidade de dados. 
O scorecard da qualidade de dados é uma ferramenta usada para focalizar nos 
locais da cadeia de informações onde existem problemas de qualidade de dados que têm o 
maior impacto na organização. Este scorecard pode ser usado como entrada para o 
próximo passo, a avaliação do estado atual. 
2.5.5 Avaliação do estado atual e análise de requisitos 
Encontrar locais de maior impacto é uma coisa, mas descobrir como lidar com eles 
é outra. Antes que se possa corrigir um problema precisa-se saber sua importância relativa. 
É aí que entra a avaliação do estado atual. 
Em cada local de impacto são selecionadas algumas das dimensões de qualidade de 
dados (descritas posteriormente) e são medidos os níveis de qualidade de dados. Estes 
Gestão da Qualidade de Dados 
 16
níveis são correlacionados com os graus de impacto econômico determinados pela análise 
de scorecard. Então, são usadas as avaliações do estado atual para descobrir quais áreas de 
qualidade de dados possuem o maior impacto econômico, para que seja determinada uma 
medida básica da qualidade de dados total da organização. 
Os dados acima, junto com o grau de impacto, permitem determinar o que precisa 
ser corrigido e os níveis necessários para demonstrar melhoria. Isto tudo é determinado 
durante o estágio de análise de requisitos. Este estágio irá fornecer níveis de qualidade de 
dados que devem ser atingidos a fim de minimizar os problemas descobertos durante a 
análise de impacto econômico e a avaliação do estado atual. 
2.5.6 Seleção de um projeto 
Com o scorecard de qualidade de dados, a avaliação do estado atual e a análise de 
requisitos, existem dados suficientes para que seja selecionado um projeto para melhoria. 
Com o apoio da gerência superior, é formada uma equipe que recebe um objetivo 
especifico: elevar o nível de qualidade de dados para o nível determinado durante a análise 
de requisitos. 
É importante selecionar um projeto único para execução. Infelizmente, muitos 
projetos de melhoria de qualidade de dados estão sujeitos a insucessos porque o escopo é 
muito grande. Pode ser impossível demonstrar sucesso se não houver um foco específico. 
Deve ser lembrado que o sucesso total do programa é determinado por pequenos sucessos 
em pequenas etapas. A seleção de um projeto pequeno, mas de alta prioridade para 
melhoria, e a execução com sucesso deste projeto, permite obter os seguintes objetivos: 
• Fornecimento de uma melhoria mensurável (tanto em forma de métricas como em 
benefício econômico) da qualidade de informação da organização; 
• Obtenção de uma sensação positiva dentro da organização, o que acaba propiciando 
mais apoio do nível superior e um consenso geral; e 
• Abertura da possibilidade de projetos adicionais de melhoria. 
Gestão da Qualidade de Dados 
 17
2.5.7 Implementação e Implantação da melhoria 
A implementação da melhoria é o ponto crítico do problema da qualidade de dados. 
A equipe de melhoria precisa ser capaz de executar os seguintes passos: 
• Arquitetar a solução – Significa determinar quais etapas reais precisam ser 
executadas para lidar com o problema da qualidade de dados; 
• Implementar a solução – Incorpora a aquisição de uma plataforma de 
desenvolvimento, acesso ao ambiente onde a solução é necessária e acesso aos 
recursos necessários para executar a implementação; e 
• Implantar a solução – Significa ser capaz de integrar a solução com os sistemas em 
produção e mover a nova solução para o ambiente de produção. 
2.6 Qualidade de dados e Operações 
As operações de negócio da organização são definidas por um conjunto de regras 
que são executadas no dia a dia. Quando o negócio depende do fluxo correto das 
informações, existe um aspecto da qualidade de dados que interage com a especificação 
operacional. 
Em essência, em qualquer negócio que lida com informações, as regras de negócio 
são regras de qualidade de dados. Isto significa que a qualidade de dados é parte integrante 
de qualquer especificação operacional. As organizações que reconhecem isto desde o início 
podem aperfeiçoar as operações ao adotar técnicas de qualidade de dados no processo. Esta 
ação acaba prevenindo a inserção de dados ruins no fluxo de negócio, eliminando a 
necessidade de detectar e corrigir estes dados. Assim, uma operação “ciente de qualidade 
de dados” pode ser executada com custo menor e com maior eficácia do que operações 
tradicionais. 
2.7 Qualidade de dados e Bancos de Dados 
As pessoas são afetadas diariamente por dados provenientes de bancos de dados, 
seja devido a correspondências de empresas de marketing direto, contas de luz e cartões de 
crédito, fornecedores de seguro ou mesmo impostos, multas de trânsito ou até vídeos 
alugados. 
Gestão da Qualidade de Dados 
 18
E não raramente se deparam com erros em dados, como envelopes de uma empresa 
que são enviados em mais de uma via para o endereço, mas com algumas letras diferentes 
no nome da pessoa ou no endereço. Existem casos conhecidos de pessoas que já chegam a 
receber a mesma correspondência em várias vias diferentes, todas objetivando a assinatura 
de uma revista. E estas correspondências, alem de causar gastos desnecessários para quem 
envia, causam irritação para os usuários, que recebem várias cópias do mesmo documento 
e em alguns casos por vários meses seguidos... 
Como exemplos podem ser descritas correspondências endereçadas a João A Silva; 
João Silva; Sr. J. A. Silva; Silva Joao, nos endereços Rua Pedro Gusmão, 115; Rua Dr. 
Pedro Gusmão, 115; R. Pedro Gusmao n.115; P. Gusmão, 115; etc... Ou seja, todas as 
correspondências são para a mesma pessoa no mesmo endereço, mas por diferença de 
alguns caracteres podem ser enviadas várias cópias para um mesmo cliente. 
Apesar de que estes erros possam ter ocorrido devido a problemas computacionais, 
o mais comum é que tenham sido devido a erros humanos de cadastramento dos dados. 
Existe um forte reconhecimento da importância da qualidade de dados no mundo de 
banco de dados. Os bancos de dados são de fato projetados com certas salva-guardas para 
proporcionar qualidade de dados, apesar de que estas sejam freqüentemente esquecidas na 
prática. Processos comotestes embutidos de nulos, dependência funcional, normalização 
de dados e integridade referencial são todos testemunhos da importância que deram os 
fornecedores de SGDB (Sistemas de Gerenciamento de Banco de Dados) para incluir 
algum grau de validação de dados dentro do sistema de gerência de banco de dados. 
Bancos de dados são criados para representar um modelo do mundo real, e sua 
qualidade pode ser medida pela conformidade com as entidades do mundo real. Na medida 
em que o banco de dados se consolida, o mundo real tende a divergir do que é representado 
no banco. 
Existem algumas áreas de qualidade de dados associadas a sistemas de bancos de 
dados, como: 
Gestão da Qualidade de Dados 
 19
• Aplicações de limpeza estática, que examinam os dados e tentam colocá-los em 
alguma forma canônica; 
• Padronização que pode ser aplicada a dados de nomes e endereços; 
• “Deduplicação”, que é um processo para remoção de dados duplicados de um 
banco de dados; e 
• Qualidade de dados baseada em regras, que pode ser usada para direcionar a 
inserção de informações em um banco de dados. Se existem dependências entre 
valores de certos atributos, estas regras podem ser adotadas para direcionar o 
processo de coleta de informação. Como exemplo, um formulário de informações 
médicas que só requisita dados sobre gravidez se o paciente for do sexo feminino. 
2.7.1 Bancos de dados legados 
Além dos problemas já descritos anteriormente (pessoas que não desenvolveram os 
sistemas e que fazem a manutenção destes, regras de negócio embutidas no código ou 
mesmo no próprio dado), existem outros como: 
• Em alguns sistemas de execução de mainframes, o job scheduler precisa saber 
exatamente quais são as dependências de execução de jobs de tal forma que possa 
criar uma programação (schedule) de execução. Isto foi definido, pois se achava 
que um job precisava iniciar apenas depois do fim de outro, mas com o tempo 
descobriu-se que um job podia iniciar depois do início do outro. Esta descoberta, 
junto com uma nova tecnologia associada à locking (bloqueio) permitiu a remoção 
da dependência e uma programação mais eficiente; e 
• Mesmo com o avanço da tecnologia, os sistemas legados desenvolvidos antes da 
introdução de sistemas de bancos de dados relacionais continuaram limitados pela 
sua plataforma de implementação. Isto pode ter duas conseqüências: (1) Muitas 
coisas que podem ser implementadas facilmente com a tecnologia de hoje são 
impossíveis na tecnologia antiga, o que pode ser um argumento para o projeto de 
renovação do banco de dados, e (2) Artifícios que foram feitos em sistemas antigos 
para lidar com deficiências de implementação, se tornaram códigos gigantes, o que 
Gestão da Qualidade de Dados 
 20
impossibilita a melhoria do sistema na implementação atual. Quem fez os artifícios 
se mudou para outros locais de trabalho e estes segredos se perderam. 
2.8 Qualidade de dados e Data Warehouse 
Normalmente se diz que a maioria do trabalho realizado na implementação de um 
Data Warehouse (DW) está nas fases de extração de dados, limpeza e transformação. 
Entretanto, muitos projetos de DW falham porque não foi dada a atenção devida no 
entendimento dos requisitos de qualidade de dados ou na validação e garantia de qualidade 
das informações importadas no warehouse. 
Muitas organizações relatam que até 70% do seu esforço vai no suporte da limpeza 
de dados e processo de transformação. 
A garantia de que dados de alta qualidade entrem no DW diminui a possibilidade 
de tomadas de decisões estratégicas incorretas. O que distingue a metodologia apresentada 
aqui da metodologia tradicional é que a nova filosofia considera a idéia de construir 
qualidade de dados na etapa de projeto de DW. Em vez de confiar em ferramentas de 
limpeza de dados que estaticamente limpam os dados, esta metodologia presume a 
validação de itens de dados na inserção no banco. 
É necessário trabalhar diretamente com os consumidores de dados para entender, 
identificar e abstrair requisitos de qualidade de dados, determinar as regras de qualidade de 
dados e integrar ferramentas para testar e validar itens de dados no momento da inserção. 
Os métodos descritos neste artigo permitem ao usuário integrar uma avaliação na cadeia de 
informação para medir e validar a qualidade de dados. Ao mesmo tempo, isto irá fornecer 
feedback para a identificação das causas dos problemas de qualidade de dados. 
2.8.1 Certificação de Data Warehouse 
Uma forma de dar nota à confiabilidade das informações armazenadas em um Data 
Warehouse é a sua certificação. Um DW será considerado pronto para uso quando os 
dados inseridos estiverem de acordo com um conjunto de expectativas de qualidade de 
dados embutidas em um conjunto de regras. Dadas estas regras, serão associadas notas à 
qualidade dos dados importados no DW. Eis as etapas para esta Certificação: 
Gestão da Qualidade de Dados 
 21
1. Definição do conjunto de regras que qualificarão os dados; 
2. Importação das regras de qualidade de dados na ferramenta (engine) de regras (esta 
ferramenta pode ser uma ferramenta de ETL – Extração, Transformação e Carga, 
adaptada com as regras); 
3. Cada regra terá um limite (threshold) de validade associado, como, por exemplo, 
um percentual, baseado nas expectativas de qualidade dos usuários; 
4. Inserção dos registros na ferramenta de regras, onde quaisquer regras relevantes 
serão testadas; 
5. Se nenhuma regra falhar, o registro é considerado válido e é inserido com sucesso 
no DW; 
6. Se alguma regra falhar, o registro incorpora as informações de quais regras foram 
violadas e posteriormente é enviado para um sistema de reconciliação. O registro 
que violou alguma regra também pode ser passado para o DW, mas precisa ser 
marcado como não tendo sido aprovado pelas expectativas dos usuários, e esta 
informação pode ser usada para análise de desempenho. A contagem de falhas e 
sucessos é mantida para cada regra; 
7. Após o dado ser importado, o valor de validade de cada regra é computado como a 
razão dos registros válidos pelo total de registros. É gerado um relatório de 
certificação de qualidade de dados delineando todas as percentagens de validade. 
Se todas as percentagens de validade excederem os limites associados, o DW é 
certificado em conformidade com os requisitos de qualidade de dados dos usuários. 
Do contrário, o DW não é certificado e até que as percentagens possam ser trazidas 
ao nível de conformidade, não se pode dizer que o DW segue os requisitos de 
qualidade de dados; 
8. Para qualificar o DW após uma certificação considerada falha, os valores de saída 
dos registros no sistema de reconciliação precisam ser analisados para descobrir a 
causa das falhas. Estas análises e correções são partes de um fluxo de negócio que 
confia no mesmo conjunto de regras de qualidade de dados usado para validação. 
Depois da reconciliação, o dado é submetido novamente através da ferramenta de 
regras e o relatório de validade é gerado mais uma vez. As informações das causas 
Gestão da Qualidade de Dados 
 22
dos erros são utilizadas para retornar às fontes de problemas nos dados legados e 
corrigir aqueles dados ruins na fonte, levando gradualmente à certificação; e 
9. A certificação de DW e Data Marts é um processo contínuo, e o relatório de 
certificação precisa ser alinhado com as formas que os registros de dados são 
inseridos no DW. Por exemplo, se um Data Mart é completamente recarregado 
com uma periodicidade regular, o processo de certificação pode ser inserido como 
um componente do processo de recarga. Alternativamente, se um DW é 
recarregado incrementalmente, os resultados da ferramenta de certificação precisam 
ser persistentes. 
2.9 Qualidade de dados e Data Mining 
Data Mining ou Mineração de Dados, também denominado Descoberta de 
Conhecimento (Knowledge Discovery), é o processo de procura por padrões ou anomalias 
emgrandes conjuntos de dados. Data Mining é basicamente um conjunto de algoritmos 
criados para descobrir conhecimento embutido nos dados. Isto inclui árvores de decisão, 
redes neurais, algoritmos genéticos e descoberta de regras de associação, junto com outras 
técnicas estatísticas e de correlação. 
Data Mining é especialmente valioso quando usado junto com processos de 
qualidade de dados porque pode funcionar tanto como um consumidor quanto como um 
produtor de regras de qualidade de dados. Técnicas de qualidade de dados precisam ser 
usadas para preparar os dados para o processo de descoberta de conhecimento. Em troca, o 
Data Mining pode expor regras de qualidade de dados que podem ser usadas para outras 
descobertas de conhecimento. 
2.10 Qualidade de dados e Intercâmbio Eletrônico de Dados 
Intercâmbio Eletrônico de Dados (Electronic Data Interchange – EDI) é o termo 
usado para qualquer formato padronizado de representação de informação de negócio para 
os propósitos de comunicação eletrônica. É usado para eliminar o processamento manual 
na execução de operações de rotina como ordens de compra, ordens de produtos, notas de 
Gestão da Qualidade de Dados 
 23
envio, entre outras. Isto aumenta a eficiência e o volume transmitido, baixando o custo por 
transação. 
O EDI usa padrões para formatação e transmissão de informação que são 
independentes da plataforma de hardware. Por definição, é uma atividade baseada em 
qualidade de dados, devido às regras de validação utilizadas. 
2.10.1 XML 
Um bom exemplo de Intercâmbio Eletrônico de Dados pode ser visto no padrão 
XML (Extensible Markup Language), que é tanto um framework de definições de 
estruturas (para a definição de padrões de dados) como um conjunto bem definido de 
regras para validação baseado em padrões definidos. 
A sintaxe de XML impõe uma estrutura na forma de um documento através do uso 
de tags para markup, que são basicamente diretivas de metadados que descrevem os dados 
em um documento. 
Um documento XML pode ser bem formado (well formed) se seguir a sintaxe do 
XML e pode ser considerado válido se for bem formado, se existir uma DTD (declaração 
do tipo do documento) e se o documento obedecer às regras especificadas na DTD. 
Apesar das noções de bem formado e válido, deve ser observado que não existe a 
noção da validação do conteúdo (apenas da estrutura do conteúdo). Como exemplo, 
considere uma aplicação de seguros onde o formato do XML especifica que qualquer 
comunicação precisa incluir o nome do seguro, o tipo de seguro e a quantidade 
comercializada. Mas, se uma mensagem vier com um nome inválido do seguro, a 
comunicação ainda pode ocorrer, o que irá causar uma falha no processamento. A estrutura 
da mensagem estava válida, mas o conteúdo não. São nestes casos que uma gestão da 
qualidade de dados pode ajudar. 
2.11 Dimensões de Qualidade de Dados 
Para realmente melhorar a Qualidade de Dados, é necessário achar uma forma de 
medi-la, e a primeira etapa na medição de algo é definir o que se trata. Para definir isto 
cabe listar algumas dimensões de Qualidade de Dados. 
Gestão da Qualidade de Dados 
 24
O conceito de dimensões de Qualidade de Dados foi explorado por Richard Wang e 
o Grupo de Gestão da Qualidade de Dados Total do Massachussets Institute of Technology 
(MIT), de Cambridge, MA, EUA (Huang, 1999 apud Loshin, 2001). Este estudo se baseou 
nas técnicas de Gestão da Qualidade Total de Juran (Juran, 1999 apud Loshin, 2001). 
Estas dimensões podem ser usadas para identificar requisitos de qualidade de dados 
dos usuários, para delinear os requisitos de características de qualidade de dados de um 
produto, para medir os níveis de qualidade de dados e para identificar os pontos fracos e 
oportunidades para melhoria de qualidade de dados. 
As dimensões podem ser agrupadas em categorias, distinguindo, por exemplo, 
aspectos de modelos de dados de aspectos de apresentação de dados. As categorias 
existentes na metodologia de (Loshin, 2001) são: 
Modelos de dados; 
- Valores de dados; 
- Domínios de Informação; 
- Apresentação de dados; e 
- Política de Informação. 
O escopo deste trabalho se restringe às categorias de Valores de dados e Domínios 
de Informação. 
2.11.1 Dimensões de Qualidade de Dados referentes a Valores de Dados 
Quando a maioria das pessoas pensa em qualidade de dados, pensa normalmente 
nas dimensões de qualidade de valores de dados. Em ambientes onde os dados não estão 
apenas sendo servidos aos clientes, mas também sendo utilizados como valores de entrada 
para ferramentas de Data Mining ou Data Warehouse, é importante fornecer altos níveis de 
qualidade de dados para os valores de dados. Confiar em dados ruins para propósitos de 
tomada de decisão leva a decisões estratégicas incorretas e conclusões tomadas a partir de 
regras derivadas de dados incorretos podem ter efeitos desastrosos. 
Seguem abaixo as dimensões de Qualidade de Dados referentes a Valores de 
Dados. 
Gestão da Qualidade de Dados 
 25
Exatidão dos valores dos dados 
A exatidão dos valores dos dados se refere ao grau em que os valores dos dados 
conferem com uma fonte identificada de informação correta. Existem diferentes fontes 
possíveis de informação correta: um banco de dados confiável; um conjunto similar que 
confirme os valores de dados provenientes de outra tabela; valores computados 
dinamicamente; o resultado de um fluxo manual ou mesmo clientes irritados. 
Como exemplo de erro de exatidão, pode-se considerar um caso em que houve erro 
na digitação do endereço de um cliente, que tem um prazo fixo para fazer um pagamento. 
Se a correspondência com o carnê de pagamento chegar depois da data prevista para o 
pagamento, o cliente pode ficar muito irritado e nunca mais comprar naquele 
estabelecimento, pois terá que arcar com multas e juros injustos. 
Valores nulos 
Um valor nulo é um valor que está faltando. Entretanto, um valor que está faltando 
pode fornecer mais informação do que se poderia pensar, pois podem existir inúmeras 
razões para esta falta de informação. Um valor nulo pode significar um valor não 
disponível no momento da coleta, um atributo que não é aplicável naquele contexto (por 
exemplo, sexo para uma pessoa jurídica), ou mesmo um valor que não existe no domínio 
utilizado e que corretamente classifique esta entidade. 
Apesar dos bancos de dados fornecerem uma representação default para o valor 
nulo, existem circunstâncias quando uma representação específica para o valor nulo é 
necessária. Mesmo assim deve-se tomar cuidado com valores incorretos, como o uso de 
99/99/99 para uma data nula. 
Gestão da Qualidade de Dados 
 26
Completude 
Completude se refere à expectativa de que alguns atributos possuam valores 
definidos em um conjunto de dados. Existem três níveis de completude: 
1. Atributos mandatórios que requerem um valor obrigatório; 
2. Atributos opcionais, que podem ou não ter um valor; e 
3. Atributos não aplicáveis (como a data de falecimento para uma pessoa viva), onde 
não tem sentido existir um valor. 
Completude pode ser analisada em um único atributo ou pode ser dependente de 
valores de outros atributos dentro do registro. Também pode ser discutido completude com 
respeito a um único atributo em relação a todos os registros ou em relação a um registro. 
Consistência 
Consistência pode ser curiosamente simples ou perigosamente complexa. Na sua 
forma mais básica, ela se refere a valores de dados em um conjunto de dados sendo 
consistentes com valores em outro conjunto de dados. 
Como exemplo, pode-se expressar uma restrição de consistência para todos os 
valores de um atributo de código CEP indicando que cada valor precisa estar de acordo 
com a definição estrutural dos Correios. Uma segunda restrição de consistência pode 
declarar que, em cada registro, o CEP precisa estar consistente com o valor do atributo 
cidade, validado em uma tabela de lookup. Umaterceira restrição de consistência pode 
especificar que, se o código CEP representa uma área dentro de uma região geográfica, a 
conta de um usuário, que mora neste CEP, precisa estar associada a um vendedor cujo 
território inclui aquela região geográfica. 
A primeira restrição de consistência é aplicada a um único atributo. A segunda é 
aplicada à relação entre dois atributos dentro do mesmo registro. Já a terceira aplica-se a 
valores em diferentes tabelas. As restrições de consistência podem ser complexas (como a 
terceira restrição acima) e freqüentemente refletem regras de negócio inerentes às 
aplicações que usam os dados. 
Gestão da Qualidade de Dados 
 27
Atualidade 
Atualidade se refere ao grau no qual a informação é atual de acordo com o mundo 
que ela modela. Ela pode medir o quanto atual a informação é e se é correta mesmo apesar 
de mudanças relacionadas ao tempo. 
Eis algumas situações em que esta dimensão é útil: O ideal é que os endereços das 
pessoas estejam sempre atualizados, mas como a sociedade está em contínua mudança, fica 
difícil manter os endereços atualizados. Outro exemplo é o preço de um produto que pode 
estar publicado em uma página da web com um valor antigo e que precisa ser atualizado 
para a venda não ocorrer com o valor errado. 
2.11.2 Dimensões de Qualidade de Dados referentes a Domínios de Dados 
Um domínio de dados é uma coleção de valores que está relacionada de alguma 
forma, e representa uma autoridade reconhecida de fonte de dados também chamada de 
referência de dados, assim como os dicionários e enciclopédias são referências 
bibliográficas. Domínios de dados podem ser descritivos, o que significa que o conjunto de 
valores pode ser derivado usando uma descrição aplicada a um conjunto maior de valores, 
ou enumerados, quando todos os valores são explicitamente listados. 
Existe um mapeamento entre dois domínios quando se expressa uma relação que 
associa qualquer valor selecionado no primeiro domínio com um ou mais valores no 
segundo domínio. Assim como com os domínios, os mapeamentos podem ser descritivos 
ou enumerados. 
Um exemplo de um domínio descritivo é a definição de formato para os números 
de CPF. Um exemplo de domínio enumerado é a lista de estados brasileiros. 
Domínios e mapeamentos são muito comuns em bancos de dados. É através da 
descoberta e análise de domínios, que tabelas desnormalizadas podem ser normalizadas, e 
muitas regras, tanto de qualidade de dados como de negócio, podem ser expressas em 
termos de relações entre domínios e mapeamentos. Seguem abaixo as dimensões 
associadas com domínios de dados. 
Gestão da Qualidade de Dados 
 28
Concordância Corporativa de uso 
A noção de abstrair informações em domínios de dados implica que existem 
usuários suficientes do mesmo conjunto de dados de tal forma que faça sentido gerenciar 
este conjunto de dados separadamente como um recurso em vez de ter grupos separados 
gerenciando suas próprias versões. A dimensão de Concordância Corporativa de Uso mede 
o grau em que diferentes departamentos da organização concordam em usar o domínio de 
dados corporativo em vez de confiar em seu próprio conjunto de dados. 
Como exemplo, uma Concordância de Uso que pode ser feita é em relação à tabela 
de códigos CEP que pode estar em um domínio corporativo e ser utilizada pelos diferentes 
departamentos de uma organização. 
Grau de responsabilidade 
Outra dimensão de qualidade de dados é o grau ao qual a responsabilidade foi 
alocada em relação ao domínio de informação. Como um domínio de dados representa uma 
coleção de valores de dados que é reconhecida como uma fonte confiável de dados, é 
aconselhável que seja apontado um responsável para a manutenção deste domínio. O grau 
de responsabilidade deve aumentar conforme o grau de Concordância de Uso dentro da 
organização aumenta. 
Ubiqüidade 
Conforme a organização amadurece em relação à qualidade de dados, a 
Concordância de Uso vai aumentar de um número pequeno de precursores (“early 
adopters”) para gradualmente conter mais e mais departamentos da organização. 
Ubiqüidade mede a quantidade de departamentos diferentes que usam dados de referência 
compartilhados. 
2.12 Controle Estatístico de Processo e o Ciclo de Melhoria 
Neste item pode-se ver como usar as dimensões definidas anteriormente e 
especificamente quantificar os níveis de qualidade de dados. São relacionadas ferramentas 
usadas para iniciar as medições e determinar em grosso modo o grau de conformidade para 
os padrões de qualidade de dados. 
Gestão da Qualidade de Dados 
 29
No inicio da década de 1920, Walter Shewhart dos Laboratórios Bell realizou um 
número de estudos de amostragem que levaram ao desenvolvimento da ferramenta de 
qualidade conhecida como Controle Estatístico de Processo (Statistical Process Control ou 
SPC). Ao avaliar a ocorrência de falhas, defeitos e erros no processo de manufatura, ele 
descobriu que, assim como na natureza, existem vários tipos de variações que podem 
ocorrer num processo de manufatura. Ele determinou que, estudando os diferentes tipos de 
variação (isto é, as variações que geram produtos não usáveis) e avaliando as razões entre 
elas, a ocorrência de baixa qualidade pode ser identificada e o processo que causa estas 
irregularidades pode ser melhorado. 
Estas noções não se aplicam apenas à manufatura de produtos, e sim também à 
qualidade de dados. Vê-se a seguir como o Controle Estatístico de Processo pode ser usado 
como uma forma de fornecer um contexto para um ciclo contínuo de melhoria de qualidade 
de dados. SPC é um processo de realização de medições durante o processo de manufatura 
para controlar a qualidade e detectar variações em qualidade enquanto os itens estão sendo 
produzidos, em vez de encontrar os defeitos durante inspeção após a produção. 
2.12.1 O Princípio de Pareto 
Em qualquer sistema com causas e efeitos, a maioria dos efeitos é causada por uma 
pequena percentagem das causas. Este conceito, denominado “O Princípio de Pareto”, foi 
integrado na prática como a “regra 80-20” – 80 por cento dos efeitos são causados por 20 
por cento das causas. 
Este princípio tem uma aplicação interessante se for usada a análise de Pareto para 
determinar que aspectos de um sistema (neste caso, qualidade de dados) serão 
incorporados no processo de Controle Estatístico de Processo. Outro corolário interessante 
ao Princípio de Pareto é que assim que os problemas grandes estejam resolvidos, existe 
uma oportunidade menor de melhorias subseqüentes. Em outras palavras, após ter atacado 
e conquistado os primeiros três ou quatro problemas, não é provável atingir melhorias 
significativas atacando os problemas adicionais. Isto é muito interessante, pois significa 
que se pode limitar a quantidade do esforço a ser utilizado para melhorar o que for 
desejado. 
Gestão da Qualidade de Dados 
 30
Como exemplo pode-se analisar a seguinte situação. Um processo qualquer tem 
seis funções, que totalizam 100 por cento do tempo de execução (também de 100 
segundos, para facilitar a análise) conforme a Figura 2.2 a seguir: 
Função Total em Segundos 
A 54 
B 26 
C 8 
D 6 
E 4 
F 2 
Figura 2.2 - Exemplo de processo 
Conseguindo aumentar a velocidade de execução da função A com um fator de 2, 
reduz-se a execução da aplicação em 27 segundos (metade do tempo da função), baixando 
o tempo total para 73 segundos. Uma melhoria seguinte da função B também com um 
fator de 2 resultaria em uma melhoria de 13 segundos, baixando o tempo total para 60 
segundos. Se for feito o mesmo com a função C, o tempo total baixaria apenas mais 4 
segundos, para 56 segundos. A mesma ação na função D baixaria o tempo total apenas 
mais 3 segundos, para 53 segundos. Como pode ser visto, a mesma quantidade de esforço 
gasta nas melhorias resulta em um beneficio que diminui rapidamente. 
2.12.2 Gráfico de Controle 
Uma ferramenta utilizada no ControleEstatístico de Processo é o Gráfico de 
Controle (Control Chart), que exibe se o processo de informação está sob controle. 
Basicamente um Gráfico de Controle representa os valores de uma série temporal dentro 
dos limites de controle inferior e superior. Uma linha central exibe o comportamento 
esperado médio do sistema. 
Gestão da Qualidade de Dados 
 31
Para construir um Gráfico de Controle, devem ser seguidas as seguintes etapas: 
1. Selecionar uma ou mais dimensões de qualidade de dados para análise. Usar a 
análise de Pareto discutida anteriormente para determinar as variáveis ou atributos 
que têm maior importância no contexto geral e que significam a maior parte do 
problema (os 20% que significam 80%); 
2. Para descobrir a fonte de problemas específicos é preciso garantir a escolha correta 
das variáveis. Por exemplo, se a dimensão a ser analisada é a Atualidade dos 
Dados, considere a variável como número atrasado da unidade temporal (minutos, 
horas ou mesmo meses) em vez de momento do registro. O valor do atraso é muito 
mais significativo para uma análise de diagnóstico de problemas; 
3. Determine o instante correto dentro do fluxo de informações para colocar o 
instrumento de medição. Esta escolha deve considerar o seguinte: 
• Deve ser cedo suficiente no fluxo de processamento de informações de tal 
forma que a detecção e correção do problema naquele ponto possam prevenir 
erros durante o resto do fluxo; 
• Deve ser num instante que seja facilmente acessível e modificável, de tal 
forma que não afete o resto do fluxo; e 
• Não deve ser num instante em que a simples observação da amostra altere os 
dados que estão sendo observados; 
4. Decida o tipo de gráfico de controle a ser usado: 
• Um gráfico de variáveis mede características mensuráveis individuais e irá 
fornecer muitas informações sobre cada item sendo produzido; e 
• Um gráfico de atributos mede a percentagem ou o número de itens que variam 
além do esperado, e fornecerá informações resumidas sobre todo o processo, 
focando nos efeitos acumulados em vez dos efeitos individuais; 
5. Escolha a linha de centro e os limites de controle. A linha de centro pode tanto ser: 
• A média das medidas anteriores; 
• A média dos dados que ainda não foram medidas ou coletadas; ou 
• Um padrão predefinido esperado. 
Gestão da Qualidade de Dados 
 32
O limite superior de controle é definido como três desvios padrão acima da linha 
de centro e o limite inferior de controle é definido como três desvios padrão 
abaixo da linha de centro; 
6. Escolha uma amostra. Esta amostra pode consistir em medições individuais de 
valores de dados ou medição de uma coleção de valores de dados para o propósito 
de trabalhar com o resumo. É importante que a amostra seja tomada em um ponto 
do processo que tenha um efeito significativo para a análise; 
7. Escolha um método de coleção e histórico (logging) dos dados de amostra. Isto 
pode variar entre “requisitar pessoas para ler instrumentos e gravar as respostas” a 
ter um mecanismo integrado de medição e histórico dos resultados da amostra; e 
8. Desenhe o gráfico e calcule a linha de centro e os limites de controle baseados nos 
dados existentes. 
2.12.3 Os objetivos do Controle Estatístico de Processo 
Os objetivos do Controle Estatístico de Processo são: a estabilidade e a 
previsibilidade. 
Para melhor análise, podem ser considerados os dados exibidos na Figura 2.3, a 
seguir. 
 
Gestão da Qualidade de Dados 
 33
 
Dias 
Número de 
registros 
processados 
Número 
de 
registros 
com erro 
Taxa dos 
erros 
1 10000 300 0,03 
2 10000 600 0,06 
3 10000 532 0,0532 
4 10000 476 0,0476 
5 10000 620 0,062 
6 10000 546 0,0546 
7 10000 665 0,0665 
8 10000 331 0,0331 
9 10000 337 0,0337 
10 10000 328 0,0328 
11 10000 345 0,0345 
12 10000 358 0,0358 
13 10000 403 0,0403 
14 10000 341 0,0341 
15 10000 347 0,0347 
16 10000 395 0,0395 
17 10000 342 0,0342 
18 10000 334 0,0334 
19 10000 346 0,0346 
20 10000 347 0,0347 
21 10000 378 0,0378 
22 10000 365 0,0365 
23 10000 351 0,0351 
24 10000 432 0,0432 
 
O gráfico de controle abaixo se refere aos 
dados à esquerda, e exibe, os dias no eixo X e as 
taxas dos erros no eixo Y. Alem disto exibe 
também o limite superior de controle, a linha de 
centro e o limite inferior de controle. Observe 
que os registros entre os dias 2 e 7 estavam 
acima do limite superior de controle. 
 
0
0,01
0,02
0,03
0,04
0,05
0,06
0,07
1 3 5 7 9 11 13 15 17 19 21 23
 
Figura 2.3 - Exemplo de dados estatísticos in [Loshin, 2001] 
Estabilidade 
Quando existe um grande número de pontos de dados fora dos limites de controle 
(como no início do fluxo exibido acima), isto significa que o processo está muito instável. 
É função do especialista de qualidade analisar os resultados deste processo para determinar 
se a instabilidade é devido a causas comuns ou especiais. Quando são identificadas causas 
especiais, pode-se gradualmente melhorar o processo, fazendo-o mais estável. Se forem 
Gestão da Qualidade de Dados 
 34
considerados apenas os dados após o dia 7 no fluxo acima, podem-se refazer os limites de 
controle e observar que o processo ficou estável. 
Previsibilidade 
Com a correção dos erros, a tendência é que os pontos fiquem mais perto uns dos 
outros, diminuindo também o desvio padrão. Como os limites de controle são funções do 
desvio padrão, eles também se aproximarão da linha de controle. Este é um tipo de 
estabilidade diferente, que foca na diminuição da banda dentro da qual são esperados os 
erros. Este tipo de estabilidade implica numa previsibilidade dos valores de erros futuros. 
Se nos últimos 30 dias existiram menos de 10 erros por dia, pode-se esperar que amanhã 
também existam menos do que 10 erros. 
A noção de previsibilidade é um benefício significativo do Controle Estatístico de 
Processo. Sabendo que o sistema chegou a um grau de previsibilidade, pode-se não só 
prever os comportamentos futuros, mas também confirmar que atividades anômalas são 
devidas a causas especiais. 
Assumindo ter traduzido as expectativas de qualidade de dados em um conjunto de 
regras de qualidade de dados, podem-se usar estas regras para validar os registros de dados. 
Se houver um histórico do número de vezes que um registro tem erro devido a um teste 
específico, pode-se usar este histórico para desenhar um gráfico diário para cada regra 
específica. 
No fim do período de medição, pode-se construir um gráfico de controle que 
consolide os dados de cada regra de qualidade de dados. Devido ao fato de que cada regra 
descreve um aspecto específico dos requisitos de qualidade de dados dos usuários, o 
problema de identificar uma causa especial se reduz a determinar qual das regras de 
qualidade de dados foi responsável pelo comportamento anômalo. Isto fornece um ponto 
inicial para o processo de análise das causas. 
Gestão da Qualidade de Dados 
 35
2.13 Domínios, Mapeamentos e Dados de Referência da 
Organização 
Devido ao fato de que cada tipo de dados é designado para cada atributo de dado 
em uma tabela de banco de dados, cada atributo destes possui valores de um conjunto de 
valores específicos. Atributos de tipos de dados inteiros só recebem valores específicos de 
números inteiros. O mesmo ocorre para qualquer outro tipo de dado, ou mesmo para 
informações existentes em uma mensagem transmitida: o valor em cada campo da 
mensagem deve ser o tipo esperado para aquele campo. 
Cada valor segue regras estruturais (ou sintáticas) assim como algumas regras 
explícitas conotativas (ou semânticas) que governam se estes valores são corretos ou 
válidos. De qualquer jeito, são conjuntos de restrições que definem os valores dos 
atributos. 
As regras sintáticas satisfazem restrições na forma do valor. Um campo que tem um 
tipo de dado inteiro não pode receber dados alfabéticos. As regras semânticas são 
restrições adicionais no conjunto