Dama DmBok (Traduzido)

Machine Translated by Google
DAMA-DMBOK
ÓRGÃO DE CONHECIMENTO DE GESTÃO DE DADOS
SEGUNDA EDIÇÃO
DAMA Internacional
Publicações de Técnicas
BASKING RIDGE, NOVA JERSEY
Dedicado à memória de
Patricia Cupoli, MLS, MBA, CCP, CDMP

(25 de maio de 1948 - 28 de julho de 2015)
por seu compromisso vitalício com a profissão de gerenciamento de dados

e suas contribuições para esta publicação.
Publicado por:
2 Lindsley Road
Basking Ridge, NJ 07920 EUA
https://www.TechnicsPub.com
Editor sénior: Deborah Henderson, CDMP

Editor: Susan Earley, CDMP
Editor de Produção: Laura Sebastian-Coleman, CDMP, IQCP
Pesquisador de Bibliografia: Elena Sykora, DGSP
Gerenciador de ferramentas de colaboração: Eva Smith, CDMP
Design da capa por Lorena Molinari
Todos os direitos reservados. Nenhuma parte deste livro pode ser reproduzida ou transmitida de qualquer forma ou por qualquer meio, eletrônico ou
mecânico, incluindo fotocópia, gravação ou por qualquer sistema de armazenamento e recuperação de informações, sem permissão por escrito do
editor, exceto pela inclusão de breves citações em Uma revisão.
O autor e a editora tomaram cuidado na preparação deste livro, mas não oferecem nenhuma garantia expressa ou implícita de qualquer tipo e não
assumem responsabilidade por erros ou omissões. Nenhuma responsabilidade é assumida por danos acidentais ou conseqüentes relacionados ou
decorrentes do uso das informações ou programas aqui contidos.
Todos os nomes comerciais e de produtos são marcas comerciais, marcas registradas ou marcas de serviço de suas respectivas empresas e são
propriedade de seus respectivos detentores e devem ser tratados como tal.
Segunda edição
Primeira impressão 2017
Direitos autorais © 2017 DAMA Internacional
ISBN, Impresso ed. 9781634622349

ISBN, PDF ed. 9781634622363
ISBN, servidor ed. 9781634622486
ISBN, Enterprise ed. 9781634622479
Número de controle da Biblioteca do Congresso: 2017941854

Conteúdo
Prefácio_______________________________________________________________ 15
Capítulo 1: Gerenciamento de Dados_____________________________________________ 17

1. Introdução ____________________________________________________________ 17
2. Conceitos Essenciais _____________________________________________________________ 18
2.1 Dados ______________________________________________________________________ 18
2.2 Dados e Informações ________________________________________________________ 20
2.3 Dados como um ativo organizacional 2.4 _______________________________________________ 20
Princípios de gerenciamento de dados 2.5__________________________________________________ 21
Desafios de gerenciamento de dados _________________________________________________ 23
2.6 Estratégia de Gerenciamento de Dados ___________________________________________________ 31
3. Estruturas de Gerenciamento de Dados ____________________________________________ 33
__________________________________________________________
3.1 Modelo de Alinhamento Estratégico 33
3.2 O Modelo de Informação de Amsterdã ____________________________________________ 34
3.3 A Estrutura DAMA-DMBOK _______________________________________________ 35
3.4 Pirâmide DMBOK (Aiken) _____________________________________________________ 39
3.5 Estrutura de gerenciamento de dados DAMA evoluída ___________________________________ 40
4. DAMA e o DMBOK _________________________________________________ 43
5. Trabalhos Citados / Recomendados ____________________________________________________ 46
Capítulo 2: Ética no manuseio de dados ____________________________________ 49

1. Introdução ____________________________________________________________ 49
2. Drivers de negócios ________________________________________________________ 51
3. Conceitos essenciais _____________________________________________________________ 52
3.1 Princípios éticos para dados __________________________________________________________ 52
3.2 Princípios por trás da lei de privacidade ____________________________________________ 53
de dados 3.3 Dados online em um contexto ____________________________________________________
ético 56
3.4 Riscos de práticas antiéticas de manipulação de dados ______________________________________ 56
____________________________________________
3.5 Estabelecendo uma cultura ética de dados 3.6 Ética e 60
governança de dados __________________________________________________ 64
4. Obras Citadas/Recomendadas ____________________________________________________ 65
Capítulo 3: Governança de Dados________________________________________ 67

1. Introdução ____________________________________________________________ 67
1.1 Direcionadores de Negócios ____________________________________________________________ 70
1.2 Objetivos e Princípios 1.3 _______________________________________________________________ 71
Conceitos Essenciais __________________________________________________________ 72
2. Atividades _____________________________________________________________________ 79
2.1 Definir Governança de Dados para a Organização ____________________________________ 79
2.2 Realizar Avaliação de Prontidão 79 _______________________________________________
2.3 Realizar Descoberta e Alinhamento de Negócios _____________________________________ 80
2.4 Desenvolver pontos de contato organizacionais ___________________________________________ 81
2.5 Desenvolver estratégia de governança de dados _____________________________________________ 82
2.6 Definir a estrutura operacional da DG 2.7 ___________________________________________ 82
Desenvolver metas, princípios e políticas 2.8 __________________________________________ 83
Subscrever projetos de gerenciamento de dados _______________________________________________ 84
2.9 Envolver a Gestão de Mudanças __________________________________________________ 85
1
2 • DMBOK2
2.10 Envolver-se no Gerenciamento de Problemas ________________________________________________ 86

2.11 Avaliar Requisitos de Conformidade Regulatória 2.12 ___________________________________ 87
Implementar Governança de Dados 2.13 Padrões e Procedimentos
_________________________________________________ 88
de Dados de Patrocinadores 2.14 Desenvolver um Glossário de
_____________________________________________ 88
Negócios 2.15 Coordenar com Grupos de Arquitetura 2.16 Avaliação
_________________________________________________ 90
de Ativos de Dados de Patrocinadores 2.17 Incorporar Governança
_______________________________________________ 90
de Dados ________________________________________________ 91
__________________________________________________________ 91
3. Ferramentas e Técnicas__________________________________________________________ 92
3.1 Presença Online / Sites 3.2 Glossário _________________________________________________ 92
Comercial 3.3 Ferramentas de___________________________________________________________
Fluxo de 92
Trabalho ____________________________________________________________ 93
3.4 Ferramentas de Gerenciamento de _________________________________________________ 93
Documentos 3.5 Scorecards de Governança de__________________________________________________
Dados 93
4. Diretrizes de Implementação 4.1 _______________________________________________ 93

93
Organização e Cultura 4.2 Ajuste e_____________________________________________________
____________________________________________________ 94
Comunicação 5. Métricas 6. Trabalhos
Citados / Recomendados
________________________________________________________________ 94
_____________________________________________ 95
Capítulo 4: Arquitetura de Dados_____________________________________________ 97

1. Introdução ___________________________________________________________ 97
1.1 Direcionadores de Negócios ____________________________________________________________ 99
1.2 Resultados e Práticas da Arquitetura de Dados 1.3 _____________________________________ 100
Conceitos Essenciais 2. Atividades
_______________________________________________________________ 101
_____________________________________________________________ 109
2.1 Estabelecer Prática de Arquitetura de Dados 2.2 __________________________________________ 110
Integrar com Arquitetura Corporativa 3. Ferramentas ________________________________________ 115
________________________________________________________________ 115
3.1 Ferramentas de Modelagem de Dados________________________________________________________ 115
_________________________________________________
3.2 Software de Gerenciamento de Ativos 115
3.3 Aplicações de Design Gráfico 4. Técnicas _______________________________________________ 115
___________________________________________________________ 116
4.1 Projeções do Ciclo de Vida _____________________________________________________________ 116
4.2 Clareza da Diagramação 5. _____________________________________________________________ 116
Diretrizes de Implementação ____________________________________________________ 117

5.1 Avaliação de Prontidão / Avaliação de Risco 5.2 ______________________________________ 118
Organização e Mudança Cultural ____________________________________________ 119
6. Governança da Arquitetura de Dados ___________________________________________ 119
6.1 Métricas ___________________________________________________________________ 120
7. Trabalhos Citados / Recomendados ____________________________________________ 120
Capítulo 5: Modelagem e Design de Dados_____________________________________ 123

1. Introdução __________________________________________________________ 123
1.1 Direcionadores de ___________________________________________________________ 125
Negócios 1.2 Objetivos e ________________________________________________________ 125
Princípios 1.3 Conceitos _______________________________________________________________ 126
Essenciais 2. Atividades 152
_____________________________________________________________
2.1 Plano para Modelagem de Dados _____________________________________________________________________ 152
CONTEÚDO • 3
2.2 Construir o Modelo de Dados _____________________________________________________________ 153

2.3 Revisar os Modelos de Dados _____________________________________________________ 158
2.4 Manter os Modelos de Dados _________________________________________________ 159
3. Ferramentas _________________________________________________________________ 159
3.1 Ferramentas de modelagem de ________________________________________________________ 159
_____________________________________________________________
dados 3.2 Ferramentas de linhagem 159
3.3 Ferramentas de criação de perfil ________________________________________________________ 160
de dados 3.4 Repositórios de metadados ______________________________________________________ 160
3.5 Padrões de modelo de dados ________________________________________________________ 160
3.6 Modelos de Dados da Indústria_____________________________________________________________ 160
4. Melhores Práticas __________________________________________________________ 161
4.1 Melhores Práticas em Convenções de Nomenclatura _______________________________________________ 161
4.2 Melhores Práticas em Projeto de Banco de Dados _____________________________________________ 161
5. Governança do Modelo de Dados _________________________________________________ 162
5.1 Modelo de Dados e Gerenciamento de Qualidade de Design ___________________________________ 162
5.2 Métricas de Modelagem de ______________________________________________________ 164
Dados 6. Trabalhos Citados / Recomendados _____________________________________________ 166
Capítulo 6: Armazenamento de dados e operações _____________________________ 169

1. Introdução ___________________________________________________________ 169
1.1 Direcionadores de Negócios ___________________________________________________________ 171
1.2 Objetivos e Princípios 1.3 ________________________________________________________ 171
Conceitos Essenciais 2. _______________________________________________________________ 172
Atividades ____________________________________________________________________ 193
2.1 Gerenciar Tecnologia de Banco de Dados ________________________________________________ 194
2.2 Gerenciar Bancos de Dados 3. _______________________________________________________________ 196
Ferramentas _________________________________________________________________ 209
3.1 Ferramentas de modelagem de dados ________________________________________________________ 209
3.2 Ferramentas de monitoramento de banco de __________________________________________________ 209
dados 3.3 Ferramentas de gerenciamento de banco de _________________________________________________ 209
__________________________________________________________
dados 3.4 Ferramentas de suporte ao desenvolvedor 209
4. Técnicas ____________________________________________________________ 210
4.1 Teste em Ambientes Inferiores _________________________________________________ 210
4.2 Padrões de nomenclatura física 4.3 __________________________________________________ 210
Uso de script para todas as alterações _________________________________________________ 210
5. Diretrizes de Implementação _______________________________________________ 210
6. Armazenamento de Dados e Governança de Operações ___________________________________ 212
6.1 Métricas ___________________________________________________________________ 212
6.2 Rastreamento de Ativos de Informação __________________________________________________ 213
6.3 Auditorias de Dados e Validação de Dados 213
____________________________________________________
7. Trabalhos Citados / Recomendados _____________________________________________ 214
Capítulo 7: Segurança de Dados__________________________________________ 217

1. Introdução ___________________________________________________________ 217
Conceitos Essenciais _______________________________________________________________ 223
4 • DMBOK2
2. Atividades _____________________________________________________________ 245

2.1 Identificar Requisitos de Segurança de Dados 2.2 __________________________________________ 245
Definir Política de Segurança de Dados 2.3__________________________________________________
Definir 247
Padrões de Segurança de Dados 3. Ferramentas
_______________________________________________ 248
________________________________________________________________ 256
3.1 Software antivírus/Software de segurança 3.2 HTTPS_____________________________________________ 256
___________________________________________________________________ 256
3.3 Tecnologia de Gerenciamento de Identidade ____________________________________________ 257
3.4 Software de Detecção e Prevenção de Intrusão ___________________________________ 257
3.5 Firewalls (Prevenção) ______________________________________________________ 3.6 Rastreamento de 257
Metadados _________________________________________________________ 257
3.7 Mascaramento/Criptografia de Dados ___________________________________________________ 258
4. Técnicas ___________________________________________________________ 258
4.1 Uso da Matriz CRUD ________________________________________________________ 258
4.2 Implantação Imediata de Patch de Segurança 4.3 ________________________________________ 258
Atributos de Segurança de Dados em Metadados 4.4__________________________________________ 258
Métricas ___________________________________________________________________ 259
4.5 Necessidades de segurança nos requisitos do _____________________________________________ 261
projeto 4.6 Pesquisa eficiente de dados criptografados
____________________________________________ 262
4.7 Sanitização de documentos ______________________________________________________ 262
5. Diretrizes de Implementação ____________________________________________________ 262
5.3 Visibilidade no direito de dados do usuário __________________________________________ 263
5.4 Segurança de dados em um mundo terceirizado_______________________________________________ 264
5.5 Segurança de dados em ambientes de nuvem __________________________________________ 265
6. Governança de segurança de dados_______________________________________________ 265
6.1 Segurança de Dados e Arquitetura Empresarial 7. _____________________________________ 265
Trabalhos Citados / Recomendados ____________________________________________ 266
Capítulo 8: Integração e Interoperabilidade de Dados______________________ 269

1. Introdução __________________________________________________________ 269
Atividades de Integração de Dados _______________________________________________ 286
2.1 Planejar e Analisar 2.2 __________________________________________________________
Projetar 286
Soluções de Integração de Dados 2.3 ____________________________________________ 289
Desenvolver Soluções de Integração de Dados ___________________________________________ 291
2.4 Implementar e Monitorar 3. Ferramentas
_____________________________________________________ 293
________________________________________________________________ 294
3.1 Mecanismo de Transformação de Dados/Ferramenta ________________________________________ 294
ETL 3.2 Servidor de Virtualização de Dados
_________________________________________________ 294
3.3 Enterprise Service Bus 3.4 ______________________________________________________ 294
Business Rules Engine ______________________________________________________ 295
3.5 Ferramentas de modelagem de dados e processos_____________________________________________ 295
3.6 Ferramenta de criação de perfil de dados 3.7
_______________________________________________________________ 295
Repositório de metadados 4. Técnicas
_____________________________________________________________ 296
___________________________________________________________ 296
CONTEÚDO • 5

6. Governança DII _______________________________________________________________ 297
6.1 Contratos de Compartilhamento de Dados ___________________________________________________ 298
6.2 DII e Linhagem de Dados _____________________________________________________________ 298
__________________________________________________________
6.3 Métricas de Integração de Dados 299
Capítulo 9: Gerenciamento de Documentos e Conteúdo_______________________ 303

1. Introdução ___________________________________________________________ 303
2. Atividades ____________________________________________________________________ 323
2.1 Plano para Gerenciamento do Ciclo de Vida _____________________________________________________ 323
2.2 Gerenciar o Ciclo de Vida 326 _____________________________________________________________
2.3 Publicar e entregar conteúdo _________________________________________________ 329
3. Ferramentas _________________________________________________________________ 330
3.1 Sistemas de gerenciamento de conteúdo corporativo 3.2 ______________________________________ 330
Ferramentas de colaboração ________________________________________________________ 333
3.3 Ferramentas Controladas de Vocabulário e _____________________________________ 333
Metadados 3.4 Formatos Padrão de Marcação e Troca______________________________________ 333
3.5 Tecnologia de Descoberta Eletrônica _____________________________________________________ 336
4. Técnicas 4.1 ____________________________________________________________ 336
Manual de Resposta a Litígios 4.2 Mapa________________________________________________ 336
de Dados de Resposta a Litígios ________________________________________________ 337
6. Governança de Documentos e Conteúdo _____________________________________________ 340
6.1 Estruturas de Governança da Informação 6.2 _______________________________________________ 340
Proliferação de Informação _________________________________________________ 342
6.3 Governança para Conteúdo de __________________________________________________ 342
Qualidade 6.4 Métricas
___________________________________________________________________ 343
Capítulo 10: Dados mestre e de referência _____________________________ 347

1. Introdução ___________________________________________________________ 347
2. Atividades ____________________________________________________________________ 370
2.1 Atividades de MDM ____________________________________________________________ 371
2.2 Atividades de Dados de Referência __________________________________________________________ 373
3. Ferramentas e Técnicas 4. _________________________________________________ 375
Diretrizes de Implementação 4.1 Aderir_______________________________________________ 375
à Arquitetura de Dados Mestres ___________________________________________ 376
4.2 Monitorar a movimentação de dados __________________________________________________________ 376
6 • DMBOK2
4.3 Gerenciar Alteração de Dados de Referência ______________________________________________ 376

4.4 Contratos de Compartilhamento de Dados ___________________________________________________ 377
5. Organização e Mudança Cultural ________________________________________ 378
6. Referência e Governança de Dados Mestres 378 ____________________________________
6.1 Métricas ___________________________________________________________________ 379
Capítulo 11: Data Warehousing e Business Intelligence_______________ 381

1. Introdução __________________________________________________________ 381
Atividades _____________________________________________________________ 394
2.1 Entender os Requisitos 2.2 Definir __________________________________________________ 394
e Manter a Arquitetura DW/BI 2.3 Desenvolver o Data ___________________________________ 395
Warehouse e os Data Marts 2.4 Preencher o Data Warehouse ___________________________________ 396
2.5 Implementar o Portfólio de Business Intelligence 2.6 Manter
________________________________________________ 397
os Produtos de Dados 3. Ferramentas __________________________________ 398
_____________________________________________________ 399
________________________________________________________________ 402
3.1 Repositório de Metadados _____________________________________________________________ 402
3.2 Ferramentas de Integração ______________________________________________________ 403
de Dados 3.3 Tipos de Ferramentas de Business ____________________________________________ 403
___________________________________________________________
Intelligence 4. Técnicas 4.1 Protótipos para Gerar
407
Requisitos 4.2 BI de Autoatendimento 4.3 ____________________________________________ 407
Auditoria de Dados que _____________________________________________________________
podem ser Consultados 408
_______________________________________________ 408
5.1 Avaliação de Prontidão / Avaliação de Risco 5.2 Roteiro______________________________________ 408
de Liberação 5.3 Gerenciamento de Configuração
__________________________________________________________ 409
__________________________________________________ 409
5.4 Organização e Mudança Cultural __________________________________________________ 410
6. Governança de DW/BI 6.1 _____________________________________________________
411
Habilitando a Aceitação de Negócios 6.2 _______________________________________________ 411
Satisfação do Cliente/Usuário 6.3 Acordos_________________________________________________ 412
de Nível de Serviço ___________________________________________________ 412
6.4 Estratégia de Relatório _______________________________________________________________ 412
6.5 Métricas ___________________________________________________________________ 413
Capítulo 12: Gerenciamento de Metadados ________________________________ 417

1. Introdução __________________________________________________________ 417
Atividades _____________________________________________________________ 434
2.1 Definir Estratégia de Metadados__________________________________________________________ 434
2.2 Compreender os Requisitos de Metadados 435 __________________________________________
2.3 Definir a Arquitetura de Metadados ________________________________________________ 436
CONTEÚDO • 7
2.4 Criar e Manter Metadados________________________________________________ 438

2.5 Consultar, relatar e analisar metadados __________________________________________ 440
3. Ferramentas _________________________________________________________________ 440
3.1 Ferramentas de gerenciamento de repositório de metadados _____________________________________________ 440
4. Técnicas ____________________________________________________________ 441

4.1 Linhagem de Dados e Análise de Impacto___________________________________________________ 441
4.2 Metadados para ingestão de Big Data _________________________________________________ 443
Mudança Organizacional e Cultural ___________________________________________ 445
6. Governança de Metadados _________________________________________________ 445
6.1 Controles de Processo ___________________________________________________________ 445
6.2 Documentação de Soluções de Metadados _______________________________________________ 446
6.3 Padrões e Diretrizes de Metadados ___________________________________________ 446
6.4 Métricas ___________________________________________________________________ 447
Capítulo 13: Qualidade de Dados _______________________________________________ 449

1. Introdução ___________________________________________________________ 449
2. Atividades ____________________________________________________________________ 473
2.1 Definir dados de alta qualidade __________________________________________________________ 473
2.2 Definir uma estratégia de qualidade de dados ________________________________________________ 2.3 474
uma avaliação inicial de qualidade de dados 2.5 Identificar e 474
Identificar dados críticos e regras de negócios 2.4 Realizar _____________________________________________
priorizar melhorias potenciais 2.6 Definir metas para melhoria _____________________________________
de qualidade de dados 2.7 Desenvolver e implantar 475
operações de qualidade de dados _________________________________ 476
____________________________________ 477
___________________________________ 477
3. Ferramentas _________________________________________________________________ 484
3.1 Ferramentas de criação de ________________________________________________________ 485
perfil de dados 3.2 Ferramentas de ________________________________________________________ 485
consulta de dados 3.3 Ferramentas de _____________________________________________________ 485
modelagem e ETL 3.4 Modelos de regras de _________________________________________________ 485
______________________________________________________
qualidade de dados 3.5 Repositórios de metadados 485
4. Técnicas ____________________________________________________________ 486

4.1 Ações Preventivas _______________________________________________________________ 486
4.2 Ações Corretivas 4.3 _______________________________________________________________ 486
Módulos de Verificação de Qualidade e Código de ________________________________________ 487
Auditoria 4.4 Métricas Eficazes de Qualidade________________________________________________
de Dados 487
4.5 Controle Estatístico de Processo _________________________________________________ 488
4.6 Análise da Causa Raiz 5. ________________________________________________________ 490
Diretrizes de Implementação _______________________________________________ 490

6. Qualidade de Dados e Governança de Dados 6.1 _______________________________________________ 493
Política de Qualidade de Dados 6.2 Métricas
_______________________________________________________________ 493
___________________________________________________________________ 494
8 • DMBOK2
Capítulo 14: Big Data e Ciência de Dados ______________________________ 497

1. Introdução __________________________________________________________ 497
1.2 Princípios ________________________________________________________________ 500
1.3 Conceitos Essenciais _______________________________________________________________ 500
2. Atividades _____________________________________________________________ 511
2.1 Definir a estratégia de Big Data e as necessidades de ___________________________________ 511
negócios 2.2 Escolher fontes de dados 2.3 Adquirir e ingerir
_____________________________________________________________ 512
fontes de dados____________________________________________________ 513
2.4 Desenvolver Hipóteses e Métodos de Dados 514 ________________________________________
2.5 Integrar/Alinhar Dados para Análise 2.6 ____________________________________________ 514
Explorar Dados Usando Modelos 2.7 __________________________________________________ 514
Implantar e Monitorar 3. Ferramentas
________________________________________________________ 516
________________________________________________________________ 517
3.1 Tecnologias e Arquitetura de Nada Compartilhado MPP 3.2 Bancos de _____________________________ 518
Dados Baseados em Arquivos Distribuídos _____________________________________________ 519
3.3 Algoritmos no banco de dados _____________________________________________________ 520
3.4 Soluções de Big Data Cloud 3.5 __________________________________________________________ 520
Computação Estatística e Linguagens Gráficas _________________________________ 520
3.6 Ferramentas de Visualização de Dados 520
__________________________________________________________
4. Técnicas ___________________________________________________________ 521
4.1 Modelagem Analítica __________________________________________________________ 521
4.2 Modelagem de Big Data _____________________________________________________________________ 522
5.1 Alinhamento da Estratégia _______________________________________________________________ 523
6. Governança de Big Data e Ciência de Dados _____________________________________ 525
6.1 Gerenciamento de Canais de Visualização __________________________________________ 525
6.2 Padrões de Ciência de Dados e Visualização ______________________________________ 525
6.3 Segurança de ____________________________________________________________________ 526
Dados 6.4 Metadados
_________________________________________________________________ 526
6.5 Qualidade de Dados ____________________________________________________________________ 527
6.6 Métricas ___________________________________________________________________ 527
Capítulo 15: Avaliação da Maturidade do Gerenciamento de Dados __________________ 531

1. Introdução __________________________________________________________ 531
1.2 Objetivos e Princípios ________________________________________________________ 534
1.3 Conceitos Essenciais 2._______________________________________________________________ 534
Atividades _____________________________________________________________ 539
2.1 Planejar as atividades de avaliação __________________________________________________ 540
2.2 Realizar a avaliação da maturidade 2.3 ________________________________________________ 542
Interpretar os resultados 2.4 Criar um
__________________________________________________________ 543
programa direcionado para melhorias 2.5 Reavaliar a maturidade __________________________________ 544
_______________________________________________________________ 545
CONTEÚDO • 9
3. Ferramentas _________________________________________________________________ 545

4. Técnicas ____________________________________________________________ 546
4.1 Selecionando uma Estrutura DMM 4.2 _________________________________________________ 546
Uso da Estrutura DAMA-DMBOK ____________________________________________________ 546
5. Diretrizes para um DMMA __________________________________________________ 547
Mudança Organizacional e Cultural ___________________________________________ 548
6. Governança da Gestão de Maturidade ________________________________________ 548
6.1 Supervisão do Processo DMMA __________________________________________________________ 548
6.2 Métricas ___________________________________________________________________ 548
Capítulo 16: Organização de Gerenciamento de Dados e Expectativas de Função _______ 551

1. Introdução ___________________________________________________________ 551
2. Compreender as normas organizacionais e culturais existentes 3. ________________________ 551
Construções organizacionais de gerenciamento de dados ________________________________ 553
3.1 Modelo Operacional Descentralizado 3.2 _______________________________________________ 553
_________________________________________________
Modelo Operacional de Rede 3.3 Modelo 554
Operacional Centralizado 3.4 Modelo _________________________________________________ 555
__________________________________________________________
Operacional Híbrido 3.5 Modelo Operacional 556
__________________________________________________
Federado 3.6 Identificando o Melhor Modelo 557
para uma Organização __________________________________ 557
3.7 Alternativas DMO e Considerações de Projeto ___________________________________ 558
4. Fatores Críticos de Sucesso __________________________________________________ 559
4.1 Patrocínio Executivo 4.2 Visão ______________________________________________________ 559
Clara _____________________________________________________________________ 559
4.3 Gerenciamento Proativo de Mudanças _______________________________________________ 559
4.4 Alinhamento de Liderança _____________________________________________________________________ 560
4.5 Comunicação ____________________________________________________________ 560
4.6 Engajamento das Partes Interessadas __________________________________________________________ 560
4.7 Orientação e Treinamento __________________________________________________________ 560
4.8 Medição de Adoção 4.9 Adesão _____________________________________________________ 561
aos Princípios Orientadores 4.10 Evolução, ____________________________________________________ 561
Não Revolução __________________________________________________ 561
5. Construa a Organização de Gerenciamento de Dados ___________________________________ 562
5.1 Identifique os participantes atuais do gerenciamento de dados _________________________________ 562
5.2 Identifique os participantes do comitê 5.3 Identifique e analise
____________________________________________________ 562
as partes interessadas 5.4 Envolva as partes interessadas
____________________________________________ 563
__________________________________________________________ 563
6. Interações entre o DMO e outros órgãos orientados a dados ________________ 564
6.1 O Diretor de Dados_____________________________________________________________ 564
6.2 Governança de Dados ___________________________________________________________ 565
6.3 Qualidade de _____________________________________________________________________ 566
Dados 6.4 Arquitetura Empresarial _____________________________________________________ 566
6.5 Gerenciando uma Organização Global ____________________________________________________ 567
7. Funções de gerenciamento de _________________________________________________ 568
dados 7.1 Funções organizacionais
_____________________________________________________________ 568
7.2 Funções individuais ___________________________________________________________ 568
10 • DMBOK2
Capítulo 17: Gerenciamento de Dados e Gerenciamento de Mudanças Organizacionais __ 573

1. Introdução __________________________________________________________ 573
2. Leis de Mudança ________________________________________________________ 574
_____________________________
3. Não Gerenciando uma Mudança: Gerenciando uma Transição 575
4. Os Oito Erros de Gerenciamento de Mudanças de Kotter _______________________________ 577
4.1 Erro nº 1: Permitir muita complacência 4.2 Erro nº 2: ____________________________________ 577
Falhar ao criar uma coalizão de orientação suficientemente poderosa 4.3 Erro nº 3: ________________ 578
_________________________________
Subestimar o poder da visão 4.4 Erro nº 4: Subcomunicar a visão por um fator de 10, 100 578
ou 1000 4.5 Erro nº 5: Permitir que obstáculos bloqueiem a visão 4.6 Erro nº 6: Falhar ao criar vitórias __________ 579
de curto prazo 4.7 Erro nº 7: Declarar a vitória cedo demais 4.8 Erro nº_______________________________
8: Negligenciar a ancoragem 580
firme das mudanças na cultura corporativa____________ 581 ___________________________________ 580
_______________________________________________ 581
5. Processo de Oito Estágios de Kotter para Grandes Mudanças ______________________________ 582

5.1 Estabelecendo um Senso de Urgência ______________________________________________ 583
5.2 A Coalizão Orientadora 5.3 _____________________________________________________________ 586
Desenvolvendo uma Visão e Estratégia _____________________________________________ 590
5.4 Comunicando a Visão da Mudança ____________________________________________ 594
6. A Fórmula para a Mudança _________________________________________________ 7. Difusão das 598

Inovações e Sustentação da Mudança _____________________________ 7.1 Os Desafios a serem 599
Superados à medida que as Inovações se Difundem 7.2 Elementos Chave na Difusão da Inovação 7.3 Os 601
___________________________
ou Rejeição de uma Inovação ou Mudança 601
____________________________________
Cinco Estágios da Adoção 7.4 Fatores que Afetam a Aceitação
_________________________________________________
______________ 8. Sustentando a Mudança _____________________________________________________ 601
603 602
8.1 Senso de Urgência/Insatisfação 8.2 ____________________________________________ 604

Enquadrando a Visão 8.3 A_______________________________________________________________
Coalizão 604
_____________________________________________________________
Orientadora 8.4 Vantagem Relativa e 605
Observabilidade 9. Comunicando o Valor do _______________________________________________ 605
Gerenciamento de Dados __________________________________ 605

9.1 Princípios de Comunicação 9.2 __________________________________________________ 605
Avaliação e Preparação do Público 9.3 O Elemento _______________________________________________ 606
Humano ________________________________________________________ 607
9.4 Plano de Comunicação _____________________________________________________________ 608
9.5 Continue Comunicando _____________________________________________________________ 609
10. Trabalhos Citados / Recomendados ___________________________________________ 609
Agradecimentos ___________________________________________________ 611
Índice______________________________________________________________ 615
Figuras
Figura 1 Princípios de Gerenciamento de Dados ____________________________________________________________ 22
Figura 2 Atividades-chave do ciclo de vida dos dados___________________________________________________________________ 29
Figura 3 Modelo de Alinhamento Estratégico (Henderson e Venkatraman) _____________________________________ 34
Figura 4 Modelo de Informações de Amsterdã (adaptado) __________________________________________________ 35
Figura 5 A Estrutura de Gerenciamento de Dados DAMA-DMBOK2 (A Roda DAMA) ___________________________ 36
Figura 6 DAMA Fatores Ambientais Hexágono __________________________________________________________ 36
Figura 7 Diagrama de Contexto da Área de Conhecimento ________________________________________________________ 37
Figura 8 Recurso de banco de dados adquirido ou construído __________________________________________________________ 40
Figura 9 Dependências da área funcional do DAMA _____________________________________________________ 41
Figura 10 Estrutura da Função de Gerenciamento de Dados DAMA _____________________________________________ 42
Figura 11 Roda DAMA evoluída ________________________________________________________________ 44
Figura 12 Diagrama de Contexto: Ética no Tratamento de Dados _________________________________________________ 50
64
Figura 13 Modelo de Risco Ético para Projetos de Amostragem __________________________________________________ 69
Figura 14 Diagrama de Contexto: Governança e Administração de Dados _________________________________________ 72
Figura 15 Governança de Dados e Gerenciamento de Dados __________________________________________________ 74
Figura 16 Partes da Organização de Governança de Dados 75 _____________________________________________________
Figura 17 Exemplos de Estrutura Operacional da DG Empresa ___________________________________________________
Figura 18 Pontos de contato organizacional do CDO________________________________________________________ 81
Figura 19 Um exemplo de uma estrutura operacional __________________________________________________ 83
_____________________________________________________________
Figura 20 Caminho de escalonamento de problemas de dados 86
Figura 21 Diagrama de Contexto: Arquitetura de Dados _____________________________________________________ 100
Figura 22 Estrutura Zachman Simplificada________________________________________________________ 103
Figura 23 Modelo de dados corporativos _____________________________________________________________________ 106
Figura 24 Exemplo de diagrama de modelos de área de assunto___________________________________________________ 107
Figura 25 Fluxo de Dados Representado em uma ________________________________________________________ 108
Figura 26 Exemplo de diagrama de fluxo de dadosMatriz 109
________________________________________________________________
Figura 27 As Dependências de Dados dos Recursos de Negócios____________________________________________ 112
Figura 28 Diagrama de Contexto: Modelagem e Design de Dados ____________________________________________________ 124
Figura 29 Entidades __________________________________________________________________________ 129
Figura 30 Relacionamentos______________________________________________________________________ 130
Figura 31 Símbolos de Cardinalidade_________________________________________________________________ 131
Figura 32 Relação Unária - Hierarquia ________________________________________________________ 131
Figura 33 Relacionamento Unário - Rede 132 _______________________________________________________________ 131
Figura 34 Relação Binária _________________________________________________________________
Figura 35 Relação Ternária________________________________________________________________ 132
Figura 36 Chaves Estrangeiras _________________________________________________________________________________ 133
Figura 37 Atributos ________________________________________________________________________ 133
Figura 38 Entidade Dependente e Independente _____________________________________________________ 134
Figura 39 Notação do IE _____________________________________________________________________________ 137
Figura 40 Notação de Eixo para Modelos Dimensionais _________________________________________________ 138
Figura 41 Modelo de classe UML ___________________________________________________________________ 140
Figura 42 Modelo ORM _____________________________________________________________________________ 141
Figura 43 Modelo FCO-IM _____________________________________________________________________ 142
Figura 44 Modelo de Cofre de Dados ___________________________________________________________________ 143
Figura 45 Modelo de âncora _____________________________________________________________________ 143
Figura 46 Modelo Conceitual Relacional __________________________________________________________ 145
Figura 47 Modelo Conceitual Dimensional ________________________________________________________ 146
Figura 48 Modelo de dados lógicos relacionais _______________________________________________________________ 146
Figura 49 Modelo de dados lógicos dimensionais _____________________________________________________________ 147
Figura 50 Modelo de dados físicos relacionais ________________________________________________________ 148
Figura 51 Modelo de Dados Físicos Dimensionais_____________________________________________________________ 149
Figura 52 Relacionamentos de Supertipo e Subtipo ___________________________________________________ 152
Figura 53 A modelagem é iterativa ________________________________________________________________ 153
11
12 • DMBOK2
Figura 54 Diagrama de contexto: armazenamento de dados e operações _____________________________________________170

Figura 55 Centralizado vs. Distribuído ___________________________________________________________________________175
Figura 56 Bancos de dados federados ________________________________________________________________176
Figura 57 Acoplamento ___________________________________________________________________________177
Figura 58 Teorema CAP ______________________________________________________________________
Desempenho do banco de dados _______________________________________________203 Figura 62 Fontes de
requisitos de segurança de dados ___________________________________________________218 Figura 63 Diagrama
de contexto: segurança de dados____________________________________________________________________2 19
Figura 64 Exemplo de DMZ _____________________________________________________________________________________231
Figura 65 Diagrama de exemplo de hierarquia de funções de segurança
________________________________________________251 Figura 66 Diagrama de contexto: integração de dados e
interoperabilidade ______________________________________271 Figura 67 Fluxo de processo ETL
_____________________________________________________________________274 Figura 68 Fluxo de processo
ELT ___________________________________________________________________ 275 Figura 69 Acoplamento de
aplicativos ________________________________________________________________282 Figura 70 Barramento de
serviço corporativo Contexto Diagrama: Documentos e Conteúdo ________________________________________________304
Figura 72 Hierarquia de Documentos baseada na ISO 9001-4.2 _____________________________________________________317
Figura 73 Modelo de Referência de Descoberta Eletrônica _____________________________________________________
____319 Figura 74 Modelo de Referência de Governança da Informação
_________________________________________________341 Figura 75 Diagrama de Contexto: Referência e Dados
Mestre ____________________________________________________348 Figura 76 Principais Etapas de Processamento
para MDM ____________________________________________________________________361 Figura 77 Exemplo de
Arquitetura de Compartilhamento de Dados Mestre ________________________________________________370 Figura
78 Processo de Solicitação de Alteração de Dados de Referência
_________________________________________________________________377 Figura 79 Diagrama de Contexto: DW/
BI __________________________________________________________382 Figura 80 A Fábrica de Informações
Corporativas _____________________________________________________________________388 Figura 81 Peças
de Xadrez do Data Warehouse da Kimball _________________________________________________________________390
Figura 82 DW/BI Conceitual e Arquitetura de Big Data ____________________________________________________391
Figura 83 Exemplo de Processo de Liberação _____________________________________________ ________________400
Figura 84 Diagrama de Contexto: Metadados___________________________________________________________________________419
Figura 85 Arquitetura de Metadados Centralizados _________________________________________________________________432
Figura 86 Arquitetura de Metadados Distribuídos ______________________________________________________433
Figura 87 Arquitetura de Metadados Híbridos_________________________________________________________________434
Figura 88 Exemplo de Metamodelo de Repositório de Metadados ________________________________________________437
Figura 89 Diagrama de Fluxo de Linhagem de Elementos de Dados de Amostra
__________________________________________________________442 Figura 901 Exemplo de Linhagem do Sistema
de Contexto Diagrama: Qualidade de dados _______________________________________________________________451
Figura 92 Relação entre dimensões de qualidade de dados ____________________________________________460
Figura 93 Um ciclo de gerenciamento de qualidade de dados com base no gráfico de Shewhart __
______________________________463 Figura 94 Barreiras ao gerenciamento de informações como um ativo de negócios
________________________________________467 Figura 95 Gráfico de controle de um processo em controle estatístico
_____________________________________________ 489 Figura 96 Abater triângulo de informações
___________________________________________________________________________498 Figura 97 Diagrama de
contexto: Big Data e ciência de dados _____________________________________________________499 Figura 98
Processo de ciência de dados ________________________________________________________________501 Figura
99 Desafios de armazenamento de dados ____________________________________________________________________503
Figura 100 Arquitetura conceitual de DW/BI e Big Data _____________________________________________504 Figura
101 Arquitetura baseada em serviços __________________________________________________________506 Figura
102 Arquitetura de dispositivo colunar ______________________________________________________519 Figura 103
Diagrama de contexto: gerenciamento de dados Avaliação de Maturidade ___________________________________533
Figura 104 Exemplo de Modelo de Maturidade de Gerenciamento de Dados
____________________________________________________535 Figura 105 Exemplo de uma Visualização de
Avaliação de Maturidade de Gerenciamento de Dados_____________________________ 537 Figura 106 Avaliar o Estado Atual para Criar um Mod
FIGURAS E TABELAS • 13
Figura 108 Modelo Operacional da Rede ___________________________________________________________ 554

Figura 109 Modelo Operacional Centralizado _______________________________________________________________ 555
Figura 110 Modelo Operacional Híbrido ____________________________________________________________ 556
Figura 111 Modelo Operacional Federado __________________________________________________________ 557
Figura 112 Mapa de Interesse das Partes Interessadas____________________________________________________________ 564
Figura 113 Fases de Transição das Pontes 576 __________________________________________________________
Figura 114 Processo de Oito Estágios de Kotter para Grandes Mudanças ____________________________________________ 583
Figura 115 Fontes de Complacência___________________________________________________________________ 585
Figura 116 A visão rompe com o status quo _____________________________________________________ 591
Figura 117 Contraste de Gestão/Liderança _____________________________________________________ 593
Figura 118 Everett Rogers Difusão de Inovações 600 _________________________________________________
Figura 119 As Etapas de Adoção ___________________________________________________________________ 602
Tabelas
Tabela 1 Princípios do GDPR _________________________________________________________________________________ 55 54
Tabela 2 Obrigações Estatutárias de Privacidade do Canadá _____________________________________________________
Tabela 3 Critérios do Programa de Privacidade dos Estados Unidos _____________________________________________________ 55
Tabela 4 Comitês / Órgãos Típicos de Governança de Dados _______________________________________________ 74
Tabela 5 Princípios para Contabilidade de Ativos de Dados _____________________________________________________________ 78
Tabela 6 Domínios de Arquitetura _________________________________________________________________ 101
Tabela 7 Categorias de Entidade Usadas Comumente ________________________________________________________ 127
Tabela 8 Entidade, Tipo de Entidade e Instância de Entidade 128 __________________________________________________________
Tabela 9 Esquemas e Notações de Modelagem ________________________________________________________ 136
Tabela 10 Esquema para Referência Cruzada do Banco de Dados_____________________________________________________ 137
Tabela 11 Modelo de Modelo de Dados Scorecard® _____________________________________________________________ 164

Tabela 12 ÁCIDO vs BASE ______________________________________________________________________ 180
Tabela 13 Tabela de Inventário de Regulamentação de Amostra ______________________________________________________ 246
Tabela 14 Exemplo de Grade de Atribuição de Funções _______________________________________________________________ 250
Tabela 15 Níveis de Controle para Documentos conforme ANSI-859 327 _____________________________________________
Tabela 16 Exemplos de Medidas de Auditoria _____________________________________________________________________ 329
Tabela 17 Lista de Referência Simples 353 ________________________________________________________________
Tabela 18 Lista de Referência Simples Expandida ________________________________________________________ 354
Tabela 19 Lista de Referências Cruzadas _________________________________________________________________ 354
Tabela 20 Lista de Referências em Vários Idiomas _______________________________________________________________ 354
Tabela 21 UNSPSC (Classificação Padrão Universal de Produtos e Serviços) ______________________________ 355
Tabela 22 NAICS (Sistema de Classificação da Indústria da América do Norte) _____________________________________________ 355
Tabela 23 Atributos de metadados de dados de referência crítica _______________________________________________ 357
Tabela 24 Dados de Origem como Recebidos pelo Sistema MDM_______________________________________________ 361
Tabela 25 Dados de entrada padronizados e enriquecidos _________________________________________________ 362
Tabela 26 Identificação do Candidato e Resolução de Identidade 389 ____________________________________________ 364
Tabela 27 Exemplo de Matriz de Barramento DW ____________________________________________________________________ 393
Tabela 28 Comparação da Técnica do CDC _________________________________________________________________
Tabela 29 Dimensões Comuns de Qualidade de Dados_____________________________________________________ 458
Tabela 30 Exemplos de Métricas DQ _________________________________________________________________ 481 480
Tabela 31 Técnicas de Monitoramento de Qualidade de Dados _____________________________________________________ 501
Tabela 32 Progressão do Analytics ________________________________________________________________
Tabela 33 Riscos e Mitigações Típicos para um DMMA _________________________________________________ 547
Tabela 34 Fases de Transição das Pontes____________________________________________________________ 575
Tabela 35 Cenários de Complacência _____________________________________________________________________ 578
Tabela 36 Declarando a Vitória Cedo demais Cenários 600 __________________________________________________________ 581
Tabela 37 Difusão de Categorias de Inovações Adaptadas à Gestão da Informação _________________________ 602
Tabela 38 Os Estágios de Adoção (Adaptado de Rogers, 1964) ________________________________________
Tabela 39 Elementos do Plano de Comunicação _______________________________________________________________ 608
Prefácio
D
A AMA International tem o prazer de lançar a segunda edição do Guia DAMA para o Gerenciamento de Dados
Corpo de Conhecimento (DAMA-DMBOK2). Desde a publicação da primeira edição em 2009,
desenvolvimentos ocorreram no campo da gestão de dados. A Governança de Dados se tornou um padrão
estrutura em muitas organizações, novas tecnologias permitiram a coleta e uso de 'Big Data' (dados semiestruturados e não estruturados em
uma ampla gama de formatos), e a importância da ética de dados cresceu junto com nossa capacidade de explorar e explorar a vasta
quantidade de dados e informações produzidos como parte de nossas vidas diárias.
Essas mudanças são emocionantes. Eles também impõem novas e crescentes demandas à nossa profissão. O DAMA respondeu a essas
mudanças reformulando o DAMA Data Management Framework (o DAMA Wheel), adicionando detalhes e esclarecimentos e expandindo o
escopo do DMBOK:
• Os diagramas de contexto para todas as Áreas de Conhecimento foram aprimorados e atualizados.
• A integração e interoperabilidade de dados foi adicionada como uma nova área de conhecimento para destacar sua importância
(Capítulo 8).
• A ética de dados foi chamada como um capítulo separado devido à crescente necessidade de uma abordagem ética
a todos os aspectos do gerenciamento de dados (Capítulo 2).
• O papel da governança foi descrito tanto como uma função (Capítulo 3) quanto em relação a cada
Área do Conhecimento.
• Uma abordagem semelhante foi adotada com a gestão de mudanças organizacionais, que é descrita no Capítulo
17 e incorporados aos capítulos da Área de Conhecimento.
• Novos capítulos sobre Big Data e Ciência de Dados (Capítulo 14) e Avaliação da Maturidade do Gerenciamento de Dados
(Capítulo 15) ajudam as organizações a entender para onde querem ir e fornecem as ferramentas para chegar lá.
• A segunda edição também inclui um conjunto recém-formulado de princípios de gerenciamento de dados para apoiar o
capacidade das organizações de gerenciar seus dados de forma eficaz e obter valor de seus ativos de dados (Capítulo 1).
Esperamos que o DMBOK2 sirva aos profissionais de gerenciamento de dados em todo o mundo como um valioso recurso e guia. No entanto,
também reconhecemos que é apenas um ponto de partida. O verdadeiro avanço virá à medida que aplicarmos e aprendermos com essas
ideias. A DAMA existe para permitir que os membros aprendam continuamente, compartilhando ideias, tendências, problemas,
e soluções.
Sue Geuens Laura Sebastian Coleman
Presidente Diretor de Publicações
DAMA Internacional DAMA Internacional
15
CAPÍTULO 1
Gestão de dados
1. Introdução
M
qualquer organização reconhece que seus dados são um ativo empresarial vital. Dados e informações podem dar
a eles insights sobre seus clientes, produtos e serviços. Pode ajudá-los a inovar e alcançar
metas estratégicas. Apesar desse reconhecimento, poucas organizações gerenciam ativamente os dados como um ativo do
qual podem obter valor contínuo (Evans e Price, 2012). Derivar valor dos dados não acontece no vácuo ou por acidente. Requer intenção,
planejamento, coordenação e comprometimento. Exige gestão e liderança.
Gerenciamento de dados é o desenvolvimento, execução e supervisão de planos, políticas, programas e práticas que entregam, controlam,
protegem e aumentam o valor dos ativos de dados e informações ao longo de seus ciclos de vida.
Um Data Management Professional é qualquer pessoa que trabalhe em qualquer aspecto do gerenciamento de dados (desde o gerenciamento
técnico de dados ao longo de seu ciclo de vida até a garantia de que os dados sejam utilizados e aproveitados adequadamente) para atender às
metas organizacionais estratégicas. Os profissionais de gerenciamento de dados desempenham várias funções, desde as altamente técnicas (por
exemplo, administradores de banco de dados, administradores de rede, programadores) até negócios estratégicos (por exemplo, administradores
de dados, estrategistas de dados, diretores de dados).
As atividades de gerenciamento de dados são abrangentes. Eles incluem tudo, desde a capacidade de tomar decisões consistentes sobre
como obter valor estratégico dos dados até a implantação técnica e o desempenho dos bancos de dados.
Assim, o gerenciamento de dados requer habilidades técnicas e não técnicas (ou seja, 'negócios'). A responsabilidade pelo gerenciamento
de dados deve ser compartilhada entre as funções de negócios e tecnologia da informação, e as pessoas em ambas as áreas devem
ser capaz de colaborar para garantir que uma organização tenha dados de alta qualidade que atendam às suas necessidades estratégicas.
Dados e informações não são apenas ativos no sentido de que as organizações investem neles para obter valor futuro. Dados e informações
também são vitais para as operações diárias da maioria das organizações. Eles têm sido chamados de 'moeda', 'sangue vital' e até mesmo
1 Seja ou não um
'novo petróleo' da economia da informação.
organização obtém valor de suas análises, ela não pode nem mesmo fazer negócios sem dados.
Para apoiar os profissionais de gestão de dados que realizam o trabalho, a DAMA International (The Data
Management Association) produziu este livro, a segunda edição do The DAMA Guide to the Data
1 Google 'dados como moeda', 'dados como sangue da vida' e 'o novo petróleo', para inúmeras referências.
17
18 • DMBOK2
Corpo de Conhecimento em Gestão (DMBOK2). Esta edição baseia-se na primeira, publicada em 2009, que forneceu conhecimento fundamental sobre o
qual construir à medida que a profissão avançava e amadurecia.
Este capítulo descreve um conjunto de princípios para gerenciamento de dados. Discute os desafios relacionados ao cumprimento desses princípios e
sugere abordagens para enfrentar esses desafios. O capítulo também descreve o DAMA Data Management Framework, que fornece o contexto para o
trabalho realizado por profissionais de gerenciamento de dados em várias áreas de conhecimento de gerenciamento de dados.
1.1 Direcionadores de Negócios
Informação e conhecimento são a chave para a vantagem competitiva. As organizações que possuem dados confiáveis e de alta qualidade sobre seus
clientes, produtos, serviços e operações podem tomar decisões melhores do que aquelas sem dados ou com dados não confiáveis. A falha em gerenciar
dados é semelhante à falha em gerenciar capital. Isso resulta em desperdício e oportunidade perdida. O principal impulsionador do gerenciamento de dados
é permitir que as organizações obtenham valor de seus ativos de dados, assim como o gerenciamento eficaz de ativos financeiros e físicos permite que as
organizações obtenham valor desses ativos.
1.2 Objetivos
Dentro de uma organização, as metas de gerenciamento de dados incluem:
• Compreender e apoiar as necessidades de informação da empresa e suas partes interessadas, incluindo
clientes, funcionários e parceiros de negócios
• Capturar, armazenar, proteger e garantir a integridade dos ativos de dados
• Garantir a qualidade dos dados e informações
• Garantir a privacidade e confidencialidade dos dados das partes interessadas
• Prevenir o acesso, manipulação ou uso não autorizado ou inadequado de dados e informações
• Garantir que os dados possam ser usados de forma eficaz para agregar valor à empresa
2. Conceitos Essenciais
2.1 Dados
Definições de dados de longa data enfatizam seu papel na representação de fatos sobre o mundo.2 Em relação à tecnologia da informação, os dados
também são entendidos como informações que foram armazenadas em formato digital (embora os dados sejam
2 O New Oxford American Dictionary define dados como “fatos e estatísticas coletados juntos para análise”. A American
Society for Quality (ASQ) define dados como “um conjunto de fatos coletados” e descreve dois tipos de dados numéricos:
medidos ou variáveis e contados ou atribuídos. A International Standards Organization (ISO) define dados como “reinterpretáveis
GESTÃO DE DADOS • 19
não se limitando a informações que foram digitalizadas e os princípios de gerenciamento de dados se aplicam a dados capturados em
papel, bem como em bancos de dados). Ainda assim, porque hoje podemos capturar tantas informações eletronicamente, chamamos
muitas coisas de 'dados' que não seriam chamadas de 'dados' em épocas anteriores - coisas como nomes, endereços, datas de
nascimento, o que se comeu no jantar no sábado, o mais livro recente comprado.
Tais fatos sobre pessoas individuais podem ser agregados, analisados e usados para obter lucro, melhorar a saúde ou influenciar
políticas públicas. Além disso, nossa capacidade tecnológica de medir uma ampla gama de eventos e atividades (desde as repercussões
do Big Bang até nossos próprios batimentos cardíacos) e de coletar, armazenar e analisar versões eletrônicas de coisas que antes não
eram consideradas dados (vídeos, fotos , gravações de som, documentos) está perto de superar nossa capacidade de sintetizar esses
3
dados em informações utilizáveis. Para aproveitar a variedade de dados
sem ser sobrecarregado por seu volume e velocidade requer práticas de gerenciamento de dados confiáveis e extensíveis.
A maioria das pessoas assume que, porque os dados representam fatos, são uma forma de verdade sobre o mundo e que os fatos se
encaixam. Mas os "fatos" nem sempre são simples ou diretos. Os dados são um meio de representação. Representa outras coisas além
de si mesmo (Chisholm, 2010). Os dados são tanto uma interpretação dos objetos que representam quanto um objeto que deve ser
interpretado (Sebastian-Coleman, 2013). Essa é outra maneira de dizer que precisamos de contexto para que os dados sejam
significativos. O contexto pode ser pensado como o sistema representacional dos dados; tal sistema inclui um vocabulário comum e um
conjunto de relacionamentos entre os componentes. Se conhecemos as convenções de tal sistema, então podemos interpretar os dados
dentro dele.4 Essas convenções são frequentemente documentadas em um tipo específico de dados conhecido como
Metadados.
No entanto, como as pessoas geralmente fazem escolhas diferentes sobre como representar conceitos, elas criam maneiras diferentes
de representar os mesmos conceitos. A partir dessas escolhas, os dados assumem diferentes formas. Pense na variedade de maneiras
que temos para representar as datas do calendário, um conceito sobre o qual existe uma definição consensual. Agora considere
conceitos mais complexos (como cliente ou produto), onde a granularidade e o nível de detalhe do que precisa ser representado nem
sempre são autoevidentes, e o processo de representação se torna mais complexo, assim como o processo de gerenciamento dessa
informação hora extra. (Consulte o Capítulo 10).
Mesmo dentro de uma única organização, muitas vezes existem várias maneiras de representar a mesma ideia. Daí a necessidade de
Arquitetura de Dados, modelagem, governança e administração, e gerenciamento de Metadados e Qualidade de Dados, que ajudam as
pessoas a entender e usar os dados. Em todas as organizações, o problema da multiplicidade se multiplica. Daí a necessidade de
padrões de dados no nível do setor que possam trazer mais consistência aos dados.
As organizações sempre precisaram gerenciar seus dados, mas as mudanças na tecnologia expandiram o escopo dessa necessidade
de gerenciamento, pois mudaram a compreensão das pessoas sobre o que são dados. Essas mudanças permitiram que as organizações
usem dados de novas maneiras para criar produtos, compartilhar informações, criar conhecimento e melhorar
representação da informação de forma formalizada adequada para comunicação, interpretação ou processamento” (ISO 11179).
Essa definição enfatiza a natureza eletrônica dos dados e assume, corretamente, que os dados requerem padrões porque são
gerenciados por meio de sistemas de tecnologia da informação. Dito isso, ele não aborda os desafios de formalizar dados de maneira
consistente, em sistemas diferentes. Nem explica bem o conceito de dados não estruturados.
3
http://ubm.io/2c4yPOJ (Acessado em 20016-12-04). http://bit.ly/1rOQkt1 (Acessado em 20016-12-04).
4 Para informações adicionais sobre a construção de dados ver: Kent, Data and Reality (2012) e Devlin, Business Unintelligence (2013).
20 • DMBOK2
sucesso organizacional. Mas o rápido crescimento da tecnologia e, com ela, a capacidade humana de produzir, capturar e extrair
significado dos dados intensificou a necessidade de gerenciar os dados de forma eficaz.
2.2 Dados e Informações
Muita tinta foi derramada sobre a relação entre dados e informações. Os dados têm sido chamados de “matéria-prima da informação” e
a informação tem sido chamada de “dados no contexto” . muito top). Embora a pirâmide possa ser útil para descrever por que os dados
precisam ser bem gerenciados, essa representação apresenta vários desafios para o gerenciamento de dados.
• Baseia-se na suposição de que os dados simplesmente existem. Mas os dados não existem simplesmente. Os dados têm que ser
criada.
• Ao descrever uma sequência linear de dados por meio de sabedoria, ele não reconhece que é preciso conhecimento para
criar dados em primeiro lugar.
• Isso implica que dados e informações são coisas separadas, quando na realidade os dois conceitos estão entrelaçados
com e dependentes uns dos outros. Os dados são uma forma de informação e a informação é uma forma de dados.
Dentro de uma organização, pode ser útil traçar uma linha entre informações e dados para fins de comunicação clara sobre os requisitos
e expectativas de diferentes usos por diferentes partes interessadas. (“Aqui está um relatório de vendas para o último trimestre
[informações]. É baseado em dados de nosso data warehouse [dados]. No próximo trimestre, esses resultados [dados] serão usados
para gerar nossas medidas de desempenho trimestre a trimestre [informações ]”). Reconhecer que dados e informações precisam ser
preparados para diferentes propósitos conduz a um princípio central de gerenciamento de dados: tanto os dados quanto as informações
precisam ser gerenciados. Ambos serão de maior qualidade se forem gerenciados em conjunto com os usos e os requisitos do cliente
em mente. Em todo o DMBOK, os termos serão usados de forma intercambiável.
2.3 Dados como um ativo organizacional
Um ativo é um recurso econômico, que pode ser possuído ou controlado, e que detém ou produz valor. Os ativos podem ser convertidos
em dinheiro. Os dados são amplamente reconhecidos como um ativo corporativo, embora a compreensão do que significa gerenciar
dados como um ativo ainda esteja evoluindo. No início da década de 1990, algumas organizações achavam questionável se o valor do
goodwill deveria receber um valor monetário. Agora, o 'valor do ágio' geralmente aparece como um item na Demonstração de Lucros e
Perdas (P&L). Da mesma forma, embora não seja universalmente adotada, a monetização de dados está se tornando cada vez mais
comum. Não demorará muito para que vejamos isso como uma característica dos P&Ls. (Consulte o Capítulo 3.)
As organizações de hoje confiam em seus ativos de dados para tomar decisões mais eficazes e operar com mais eficiência.
As empresas usam dados para entender seus clientes, criar novos produtos e serviços e melhorar a eficiência operacional cortando
custos e controlando riscos. Agências governamentais, instituições educacionais e organizações sem fins lucrativos
5 Ver Inglês, 1999 e DAMA, 2009.

as organizações também precisam de dados de alta qualidade para orientar suas atividades operacionais, táticas e estratégicas. À medida que as
organizações dependem cada vez mais dos dados, o valor dos ativos de dados pode ser estabelecido com mais clareza.
Muitas organizações se identificam como 'orientadas por dados'. As empresas que desejam permanecer competitivas devem parar de tomar
decisões com base em sentimentos ou instintos e, em vez disso, usar gatilhos de eventos e aplicar análises para obter insights acionáveis. Ser
orientado por dados inclui o reconhecimento de que os dados devem ser gerenciados de forma eficiente e com disciplina profissional, por meio de
uma parceria de liderança empresarial e conhecimento técnico.
Além disso, o ritmo dos negócios hoje significa que a mudança não é mais opcional; a disrupção digital é a norma. Para reagir a isso, as empresas
devem co-criar soluções de informações com profissionais de dados técnicos trabalhando ao lado de contrapartes da linha de negócios. Eles devem
planejar como obter e gerenciar os dados que eles sabem que precisam para apoiar a estratégia de negócios. Eles também devem se posicionar
para aproveitar as oportunidades de alavancar dados em
novos caminhos.
2.4 Princípios de Gerenciamento de Dados
O gerenciamento de dados compartilha características com outras formas de gerenciamento de ativos, como visto na Figura 1. Envolve saber quais
dados uma organização possui e o que pode ser realizado com eles e, em seguida, determinar a melhor forma de usar os ativos de dados para
atingir as metas organizacionais.
Como outros processos de gestão, deve equilibrar as necessidades estratégicas e operacionais. Esse equilíbrio pode ser mais bem alcançado
seguindo um conjunto de princípios que reconhecem características importantes do gerenciamento de dados e orientam a prática de gerenciamento
de dados.
• Os dados são um ativo com propriedades únicas: os dados são um ativo, mas diferem de outros ativos em importantes
maneiras que influenciam a forma como ele é gerenciado. A mais óbvia dessas propriedades é que os dados não são consumidos
quando é usado, assim como os ativos financeiros e físicos.
• O valor dos dados pode e deve ser expresso em termos econômicos: Chamar os dados de ativos implica que eles
tem valor. Embora existam técnicas para medir o valor qualitativo e quantitativo dos dados, não há
ainda padrões para fazê-lo. As organizações que desejam tomar melhores decisões sobre seus dados devem
desenvolver formas consistentes de quantificar esse valor. Eles também devem medir tanto os custos da baixa qualidade
dados e os benefícios de dados de alta qualidade.
• Gerenciar dados significa gerenciar a qualidade dos dados: garantir que os dados sejam adequados à finalidade é um
objetivo do gerenciamento de dados. Para gerenciar a qualidade, as organizações devem garantir que entendem as
requisitos de qualidade e medir dados em relação a esses requisitos.
• São necessários metadados para gerenciar dados: gerenciar qualquer ativo requer ter dados sobre esse ativo (número de
empregados, códigos de contabilidade, etc.). Os dados usados para gerenciar e usar dados são chamados de Metadados. Porque
dados não podem ser mantidos ou tocados, para entender o que é e como usá-lo requer definição e
conhecimento na forma de Metadados. Os metadados se originam de uma série de processos relacionados à criação de dados,
processamento e uso, incluindo arquitetura, modelagem, administração, governança, qualidade de dados
gerenciamento, desenvolvimento de sistemas, operações de TI e de negócios e análises.

22 • DMBOK2
DADOS
Dados são valiosos
GESTÃO
PRINCÍPIOS
• Os dados são um ativo com
propriedades únicas • O
O gerenciamento valor dos dados pode e deve ser
eficaz de dados requer expresso em termos econômicos
comprometimento da
liderança
Os requisitos de gerenciamento de dados são requisitos de negócios
• Gerenciar dados significa gerenciar a qualidade dos dados • É preciso

metadados para gerenciar dados • É preciso planejamento para gerenciar
dados • Os requisitos de gerenciamento de dados devem orientar as
decisões de Tecnologia da Informação
O gerenciamento de dados depende de diversas habilidades
• O gerenciamento de dados é multifuncional • O

gerenciamento de dados requer uma perspectiva corporativa
• O gerenciamento de dados deve levar em conta uma
variedade de perspectivas
O gerenciamento de dados é o gerenciamento do ciclo de vida
• Diferentes tipos de dados têm ciclo de vida diferente

características
• O gerenciamento de dados inclui o gerenciamento dos riscos

associados aos dados
Figura 1 Princípios de gerenciamento de dados
• É preciso planejamento para gerenciar dados: mesmo pequenas organizações podem ter cenários complexos de processos
técnicos e de negócios. Os dados são criados em muitos lugares e são movidos entre os locais para uso. Coordenar o trabalho e
manter os resultados finais alinhados requer planejamento de uma perspectiva arquitetônica e de processo.
• O gerenciamento de dados é multifuncional; requer uma variedade de habilidades e conhecimentos: uma única equipe não pode
gerenciar todos os dados de uma organização. O gerenciamento de dados requer habilidades técnicas e não técnicas e a capacidade de
colaborar.
• O gerenciamento de dados requer uma perspectiva corporativa: o gerenciamento de dados tem aplicativos locais, mas
deve ser aplicado em toda a empresa para ser o mais eficaz possível. Essa é uma das razões pelas quais o gerenciamento
de dados e a governança de dados estão interligados.
• O gerenciamento de dados deve levar em conta uma série de perspectivas: Os dados são fluidos. O gerenciamento de dados
deve evoluir constantemente para acompanhar as formas como os dados são criados e usados e os consumidores de dados que os utilizam.
GERENCIAMENTO DE DADOS • 23
• Gerenciamento de dados é gerenciamento de ciclo de vida: os dados têm um ciclo de vida e o gerenciamento de dados requer gerenciamento
seu ciclo de vida. Como os dados geram mais dados, o próprio ciclo de vida dos dados pode ser muito complexo. Dados
as práticas de gerenciamento precisam levar em conta o ciclo de vida dos dados.
• Diferentes tipos de dados têm diferentes características de ciclo de vida: E por esse motivo, eles têm diferentes
requisitos de gestão. As práticas de gerenciamento de dados precisam reconhecer essas diferenças e ser flexíveis
suficiente para atender a diferentes tipos de requisitos de ciclo de vida de dados.
• O gerenciamento de dados inclui o gerenciamento dos riscos associados aos dados: além de ser um ativo, os dados
também representa risco para uma organização. Os dados podem ser perdidos, roubados ou mal utilizados. As organizações devem considerar
as implicações éticas de seus usos de dados. Os riscos relacionados aos dados devem ser gerenciados como parte dos dados
ciclo da vida.
• Os requisitos de gerenciamento de dados devem orientar as decisões de Tecnologia da Informação: Dados e dados
estão profundamente interligadas com a tecnologia da informação e a tecnologia da informação
gestão. Gerenciar dados requer uma abordagem que garanta que a tecnologia sirva, em vez de impulsionar, um
necessidades de dados estratégicos da organização.
• O gerenciamento de dados eficaz requer comprometimento da liderança: o gerenciamento de dados envolve um complexo
conjunto de processos que, para serem eficazes, requerem coordenação, colaboração e comprometimento. Chegando la
requer não apenas habilidades de gestão, mas também a visão e o propósito que vêm de
Liderança.
2.5 Desafios de gerenciamento de dados
Como o gerenciamento de dados possui características distintas derivadas das propriedades dos próprios dados, também apresenta desafios em seguir esses
princípios. Os detalhes desses desafios são discutidos nas Seções 2.5.1 a 2.5.13.
Muitos desses desafios se referem a mais de um princípio.
2.5.1 Os dados diferem de outros ativos 6
Os ativos físicos podem ser apontados, tocados e movidos. Eles podem estar em apenas um lugar por vez. Os ativos financeiros devem ser contabilizados em um
balanço patrimonial. No entanto, os dados são diferentes. Os dados não são tangíveis. No entanto, é durável; ele não se desgasta, embora o valor dos dados
geralmente mude à medida que envelhecem. Os dados são fáceis de copiar e transportar. Mas não é fácil de reproduzir se for perdido ou destruído. Por não ser
consumido quando usado, pode até ser roubado sem sumir. Os dados são dinâmicos e podem ser usados para várias finalidades. Os mesmos dados podem até ser
usados por várias pessoas ao mesmo tempo – algo que é impossível com ativos físicos ou financeiros. Muitos usos de dados geram mais dados. A maioria das
organizações deve gerenciar volumes crescentes de dados e a relação entre conjuntos de dados.
6 Esta seção deriva de Redman, Thomas. Qualidade de dados para a era da informação (1996) pp. 41-42, 232-36; e Orientado a Dados
(2008), Capítulo Um, “As Propriedades Maravilhosas e Perigosas de Dados e Informações”.
24 • DMBOK2
Essas diferenças tornam difícil atribuir um valor monetário aos dados. Sem esse valor monetário, é difícil medir como os dados contribuem para o
sucesso organizacional. Essas diferenças também levantam outros problemas que afetam o gerenciamento de dados, como definir a propriedade dos
dados, inventariar a quantidade de dados que uma organização possui, proteger contra o uso indevido de dados, gerenciar riscos associados à
redundância de dados e definir e aplicar padrões de qualidade de dados.
Apesar dos desafios de medir o valor dos dados, a maioria das pessoas reconhece que os dados, de fato, têm valor. Os dados de uma organização
são exclusivos dela mesma. Se dados organizacionalmente exclusivos (como listas de clientes, inventários de produtos ou histórico de reclamações)
fossem perdidos ou destruídos, substituí-los seria impossível ou extremamente caro. Os dados também são o meio pelo qual uma organização se
conhece – é um meta-ativo que descreve outros ativos. Como tal, ele fornece a base para a percepção organizacional.
Dentro e entre organizações, dados e informações são essenciais para a condução dos negócios. A maioria das transações comerciais operacionais
envolve a troca de informações. A maioria das informações é trocada eletronicamente, criando uma trilha de dados. Essa trilha de dados pode servir a
propósitos além de marcar as trocas que ocorreram. Ele pode fornecer informações sobre como uma organização funciona.
Devido ao importante papel que os dados desempenham em qualquer organização, eles precisam ser gerenciados com cuidado.
2.5.2 Avaliação de Dados
O valor é a diferença entre o custo de uma coisa e o benefício derivado dessa coisa. Para alguns ativos, como ações, calcular o valor é fácil. É a
diferença entre o que o estoque custou quando foi comprado e o que foi vendido. Mas para dados, esses cálculos são mais complicados, porque nem
os custos nem os benefícios de

os dados são padronizados.
Como os dados de cada organização são únicos, uma abordagem para avaliação de dados precisa começar articulando categorias gerais de custo e
benefício que podem ser aplicadas de forma consistente dentro de uma organização. As categorias de amostra incluem 7 :
• Custo de obtenção e armazenamento de dados
• Custo de substituição de dados em caso de perda
• Impacto para a organização se os dados estiverem faltando
• Custo de mitigação de riscos e custo potencial de riscos associados a dados
• Custo de melhoria de dados
• Benefícios de dados de maior qualidade
• O que os concorrentes pagariam pelos dados

• Para que os dados podem ser vendidos
• Receita esperada de usos inovadores de dados
7 Enquanto o DMBOK2 se preparava para ser publicado, outro meio de valorização de dados estava nos noticiários: o ataque de ransomware
Wannacry (17 de maio de 2017) impactou mais de 100 mil organizações em 150 países. Os culpados usaram o software para manter os dados
como reféns até que as vítimas pagassem resgate para liberar seus dados. http://bit.ly/2tNoyQ7.
Um dos principais desafios para a avaliação de ativos de dados é que o valor dos dados é contextual (o que tem valor para uma organização pode não ter
valor para outra) e muitas vezes temporal (o que era valioso ontem pode não ser valioso hoje). Dito isto, dentro de uma organização, é provável que certos
tipos de dados sejam consistentemente valiosos ao longo do tempo. Tome informações confiáveis do cliente, por exemplo. As informações do cliente
podem até se tornar mais valiosas ao longo do tempo, à medida que mais dados se acumulam relacionados à atividade do cliente.
Em relação ao gerenciamento de dados, estabelecer formas de associar valor financeiro aos dados é fundamental, pois as organizações precisam entender
os ativos em termos financeiros para tomar decisões consistentes. A valorização dos dados torna-se a base da valorização das atividades de gerenciamento
de dados.8 O processo de avaliação de dados também pode ser usado como meio de gerenciamento de mudanças. Pedir aos profissionais de
gerenciamento de dados e às partes interessadas que eles apoiam que entendam o significado financeiro de seu trabalho pode ajudar uma organização a
transformar sua compreensão de seus próprios dados e, por meio disso, sua abordagem ao gerenciamento de dados.
2.5.3 Qualidade de Dados
Garantir que os dados sejam de alta qualidade é fundamental para o gerenciamento de dados. As organizações gerenciam seus dados porque querem
usá-los. Se eles não puderem confiar nele para atender às necessidades de negócios, o esforço para coletar, armazenar, proteger e permitir o acesso a
ele será desperdiçado. Para garantir que os dados atendam às necessidades de negócios, eles devem trabalhar com os consumidores de dados para
definir essas necessidades, incluindo características que tornam os dados de alta qualidade.
Em grande parte porque os dados estão tão intimamente associados à tecnologia da informação, o gerenciamento da Qualidade dos Dados tem sido
historicamente tratado como uma reflexão tardia. As equipes de TI geralmente desprezam os dados que os sistemas que criam deveriam armazenar.
Provavelmente foi um programador que primeiro observou 'lixo entrando, lixo saindo' – e que, sem dúvida, queria deixar para lá. Mas as pessoas que
querem usar os dados não podem se dar ao luxo de desprezar a qualidade.
Eles geralmente assumem que os dados são confiáveis e confiáveis, até que tenham um motivo para duvidar dessas coisas. Uma vez que eles perdem a
confiança, é difícil recuperá-la.
A maioria dos usos de dados envolve aprender com eles para aplicar esse aprendizado e criar valor. Os exemplos incluem entender os hábitos do cliente
para melhorar um produto ou serviço e avaliar o desempenho organizacional ou tendências de mercado para desenvolver uma melhor estratégia de
negócios, etc. Dados de baixa qualidade terão um impacto negativo sobre

essas decisões.
Tão importante quanto, dados de baixa qualidade são simplesmente caros para qualquer organização. As estimativas diferem, mas os especialistas acham
que as organizações gastam entre 10 e 30% da receita lidando com problemas de qualidade de dados. A IBM estimou que o custo de dados de baixa
qualidade nos EUA em 2016 foi de US$ 3,1 trilhões.9 Muitos dos custos de dados de baixa qualidade são ocultos, indiretos e, portanto, difíceis de medir.
Outras, como multas, são diretas e fáceis de calcular. Os custos vêm de:
• Sucata e retrabalho
• Soluções alternativas e processos de correção ocultos
8 Para estudos de caso e exemplos, consulte Aiken e Billings, Monetizing Data Management (2014).
9 Relatado em Redman, Thomas. “Dados ruins custam US$ 3 trilhões por ano.” Harvard Business Review. 22 de setembro de 2016.
https://hbr.org/2016/09/bad-data-costs-the-us-3-trillion-per-year.
26 • DMBOK2
• Ineficiências organizacionais ou baixa produtividade
• Conflito organizacional
• Baixa satisfação no trabalho

• Insatisfação do cliente
• Custos de oportunidade, incluindo incapacidade de inovar
• Custos ou multas de conformidade
• Custos de reputação
Os benefícios correspondentes de dados de alta qualidade incluem:
• Melhor experiência do cliente
• Maior produtividade
• Risco reduzido
• Capacidade de agir em oportunidades

• Aumento da receita
• Vantagem competitiva obtida a partir de insights sobre clientes, produtos, processos e oportunidades
Como esses custos e benefícios implicam, gerenciar a qualidade de dados não é uma tarefa única. A produção de dados de alta qualidade requer
planejamento, comprometimento e uma mentalidade que construa qualidade em processos e sistemas. Todas as funções de gerenciamento de
dados podem influenciar a Qualidade dos Dados, para o bem ou para o mal, portanto, todos devem considerá-la à medida que executam seu trabalho.
(Ver Capítulo 13).
2.5.4 Planejamento para melhores dados
Conforme declarado na introdução do capítulo, derivar valor dos dados não acontece por acaso. Requer planejamento de muitas formas. Começa
com o reconhecimento de que as organizações podem controlar como obtêm e criam dados. Se eles visualizarem os dados como um produto que
eles criaram, eles tomarão melhores decisões sobre eles ao longo de seu ciclo de vida. Essas decisões exigem pensamento sistêmico porque
envolvem:
• As formas como os dados conectam os processos de negócios que poderiam ser vistos como separados
• A relação entre os processos de negócios e a tecnologia que os suporta
• O design e a arquitetura dos sistemas e os dados que eles produzem e armazenam
• As maneiras pelas quais os dados podem ser usados para avançar na estratégia organizacional
Planejar dados melhores requer uma abordagem estratégica para arquitetura, modelagem e outras funções de design. Também depende da
colaboração estratégica entre a liderança de negócios e de TI. E, claro, depende da capacidade de execução eficaz em projetos individuais.
O desafio é que geralmente há pressões organizacionais, bem como pressões perenes de tempo e dinheiro, que atrapalham um melhor
planejamento. As organizações devem equilibrar metas de longo e curto prazo à medida que executam suas estratégias. Ter clareza sobre os
trade-offs leva a melhores decisões.

2.5.5 Metadados e Gerenciamento de Dados
As organizações exigem Metadados confiáveis para gerenciar dados como um ativo. Metadados nesse sentido devem ser entendidos de forma
abrangente. Inclui não apenas os Metadados comerciais, técnicos e operacionais descritos no Capítulo 12, mas também os Metadados
incorporados à Arquitetura de Dados, modelos de dados, requisitos de segurança de dados, padrões de integração de dados e processos
operacionais de dados. (Consulte os Capítulos 4 - 11.)
Os metadados descrevem quais dados uma organização possui, o que eles representam, como são classificados, de onde vieram, como se
movem dentro da organização, como evoluem com o uso, quem pode ou não usá-los e se são de alta qualidade. Os dados são abstratos.
Definições e outras descrições de contexto permitem que ele seja entendido. Eles tornam os dados, o ciclo de vida dos dados e os sistemas
complexos que contêm dados compreensíveis.
O desafio é que os metadados são uma forma de dados e precisam ser gerenciados como tal. As organizações que não gerenciam bem seus
dados geralmente não gerenciam seus Metadados. O gerenciamento de metadados geralmente fornece um ponto de partida para melhorias
no gerenciamento de dados em geral.
2.5.6 O gerenciamento de dados é multifuncional
O gerenciamento de dados é um processo complexo. Os dados são gerenciados em diferentes locais dentro de uma organização por equipes
que são responsáveis por diferentes fases do ciclo de vida dos dados. O gerenciamento de dados requer habilidades de design para planejar
sistemas, habilidades altamente técnicas para administrar hardware e construir software, habilidades de análise de dados para entender
questões e problemas, habilidades analíticas para interpretar dados, habilidades de linguagem para trazer consenso a definições e modelos,
bem como pensamento estratégico para ver oportunidades para servir os clientes e cumprir as metas.
O desafio é fazer com que as pessoas com essa variedade de habilidades e perspectivas reconheçam como as peças se encaixam para que
colaborem bem enquanto trabalham em direção a objetivos comuns.
2.5.7 Estabelecendo uma Perspectiva Empresarial
O gerenciamento de dados requer a compreensão do escopo e do alcance dos dados dentro de uma organização. Os dados são uma das
'horizontais' de uma organização. Ele se move em verticais, como vendas, marketing e operações... Ou pelo menos deveria. Os dados não
são exclusivos de uma organização; às vezes, é exclusivo de um departamento ou outra subparte de uma organização. Como os dados
geralmente são vistos simplesmente como um subproduto de processos operacionais (por exemplo, os registros de transações de vendas são
o subproduto do processo de vendas), nem sempre são planejados para além do imediato.
precisar.
Mesmo dentro de uma organização, os dados podem ser díspares. Os dados se originam em vários lugares dentro de uma organização.
Diferentes departamentos podem ter diferentes formas de representar o mesmo conceito (por exemplo, cliente, produto, fornecedor).
Como qualquer pessoa envolvida em um projeto de integração de dados ou Master Data Management pode testemunhar, diferenças sutis (ou
flagrantes) nas escolhas de representação apresentam desafios no gerenciamento de dados em uma organização. Ao mesmo tempo, as
partes interessadas assumem que os dados de uma organização devem ser coerentes, e um objetivo do gerenciamento de dados é ajustá-los
de maneira de bom senso para que possam ser usados por uma ampla variedade de consumidores de dados.
28 • DMBOK2
Uma razão pela qual a governança de dados se tornou cada vez mais importante é ajudar as organizações a tomar decisões sobre dados em
verticais. (Consulte o Capítulo 3.)
2.5.8 Contabilização de Outras Perspectivas
As organizações de hoje usam dados que criam internamente, bem como dados que adquirem de fontes externas.
Eles precisam levar em conta diferentes requisitos legais e de conformidade em todas as linhas nacionais e industriais. As pessoas que criam
dados geralmente esquecem que outra pessoa usará esses dados mais tarde. O conhecimento dos usos potenciais dos dados permite um melhor
planejamento do ciclo de vida dos dados e, com isso, dados de melhor qualidade. Os dados também podem ser mal utilizados.
A contabilização desse risco reduz a probabilidade de uso indevido.
2.5.9 O Ciclo de Vida dos Dados
Como outros ativos, os dados têm um ciclo de vida. Para gerenciar efetivamente os ativos de dados, as organizações precisam entender e
planejar o ciclo de vida dos dados. Dados bem gerenciados são gerenciados estrategicamente, com uma visão de como a organização usará
seus dados. Uma organização estratégica definirá não apenas seus requisitos de conteúdo de dados, mas também seus requisitos de
gerenciamento de dados. Isso inclui políticas e expectativas de uso, qualidade, controles e segurança; uma abordagem empresarial para
arquitetura e design; e uma abordagem sustentável para o desenvolvimento de infraestrutura e software.
O ciclo de vida dos dados é baseado no ciclo de vida do produto. Não deve ser confundido com o ciclo de vida de desenvolvimento de sistemas.
Conceitualmente, o ciclo de vida dos dados é fácil de descrever (veja a Figura 2). Inclui processos que criam ou obtêm dados, aqueles que os
movem, transformam e armazenam e permitem que sejam mantidos e compartilhados, e aqueles que os usam ou aplicam, bem como aqueles
que os descartam.10 Ao longo de seu ciclo de vida, os dados podem ser limpos, transformados, mesclados, aprimorados ou agregados. À medida
que os dados são usados ou aprimorados, novos dados geralmente são criados, portanto, o ciclo de vida tem iterações internas que não são
mostradas no diagrama. Os dados raramente são estáticos. O gerenciamento de dados envolve um conjunto de processos interconectados
alinhados ao ciclo de vida dos dados.
As especificidades do ciclo de vida dos dados dentro de uma determinada organização podem ser bastante complicadas, porque os dados não
apenas têm um ciclo de vida, mas também uma linhagem (ou seja, um caminho ao longo do qual se movem de seu ponto de origem até seu
ponto de uso, às vezes chamado de cadeia de dados). Compreender a linhagem de dados requer documentar a origem dos conjuntos de dados,
bem como seu movimento e transformação através dos sistemas onde são acessados e usados. Ciclo de vida e linhagem se cruzam e podem
ser entendidos em relação um ao outro. Quanto melhor uma organização entender o ciclo de vida e a linhagem de seus dados, melhor será sua
capacidade de gerenciar seus dados.
O foco do gerenciamento de dados no ciclo de vida dos dados tem várias implicações importantes:
• A criação e o uso são os pontos mais críticos no ciclo de vida dos dados: o gerenciamento de dados deve ser
executado com uma compreensão de como os dados são produzidos ou obtidos, bem como como os dados são usados. Isso custa
dinheiro para produzir dados. Os dados são valiosos apenas quando são consumidos ou aplicados. (Veja os Capítulos 5, 6, 8, 11,
e 14.)
10 Ver McGilvray (2008) e English (1999) para informações sobre o ciclo de vida do produto e dados.
Projeto & Crio /

Plano
Permitir Obtivermos
Armazenar /
Realçar Usar
Manter
Descarte de
Figura 2 Atividades-chave do ciclo de vida dos dados
• A qualidade dos dados deve ser gerenciada durante todo o ciclo de vida dos dados: o gerenciamento da qualidade dos dados é central para
gestão de dados. Dados de baixa qualidade representam custo e risco, em vez de valor. As organizações costumam encontrá-lo
desafiador gerenciar a qualidade dos dados porque, conforme descrito anteriormente, os dados geralmente são criados como um produto ou
processos operacionais e as organizações geralmente não definem padrões explícitos de qualidade. Porque
a qualidade da qualidade pode ser impactada por uma série de eventos do ciclo de vida, a qualidade deve ser planejada como parte
o ciclo de vida dos dados (consulte o Capítulo 13).
• A qualidade dos metadados deve ser gerenciada durante o ciclo de vida dos dados: como os metadados são uma forma de dados,
e como as organizações dependem dele para gerenciar outros dados, a qualidade dos metadados deve ser gerenciada da mesma forma
como a qualidade de outros dados (ver Capítulo 12).
• A segurança de dados deve ser gerenciada em todo o ciclo de vida dos dados: o gerenciamento de dados também inclui
garantindo que os dados estejam seguros e que os riscos associados aos dados sejam mitigados. Dados que requerem proteção
devem ser protegidos durante todo o seu ciclo de vida, desde a criação até o descarte (consulte o Capítulo 7 Segurança de dados).
• Os esforços de gerenciamento de dados devem se concentrar nos dados mais críticos: as organizações produzem muitos dados,
grande parte do qual nunca é realmente usado. Tentar gerenciar todos os dados não é possível.
O gerenciamento do ciclo de vida requer o foco nos dados mais críticos de uma organização e a minimização do ROT de dados
(Dados redundantes, obsoletos, triviais) (Aiken, 2014).
2.5.10 Diferentes tipos de dados
O gerenciamento de dados se torna mais complicado pelo fato de que existem diferentes tipos de dados que possuem diferentes requisitos de gerenciamento de ciclo
de vida. Qualquer sistema de gerenciamento precisa classificar os objetos que são gerenciados. Dados
30 • DMBOK2
podem ser classificados por tipo de dados (por exemplo, dados transacionais, dados de referência, dados mestre, metadados; alternativamente dados
de categoria, dados de recursos, dados de eventos, dados detalhados de transações) ou por conteúdo (por exemplo, domínios de dados, áreas de
assunto) ou por formato ou pelo nível de proteção que os dados exigem. Os dados também podem ser classificados por como e onde são
armazenados ou acessados. (Consulte os Capítulos 5 e 10.)
Como os diferentes tipos de dados têm diferentes requisitos, estão associados a diferentes riscos e desempenham diferentes papéis dentro de uma
organização, muitas das ferramentas de gerenciamento de dados estão focadas em aspectos de classificação e controle (Bryce, 2005). Por exemplo,
os dados mestres têm usos diferentes e, consequentemente, requisitos de gerenciamento diferentes dos dados transacionais. (Veja os Capítulos 9,
10, 12 e 14.)
2.5.11 Dados e Risco
Os dados não representam apenas valor, mas também risco. Dados de baixa qualidade (imprecisos, incompletos ou desatualizados) obviamente
representam risco porque suas informações não estão corretas. Mas os dados também são arriscados porque podem ser mal interpretados e mal
utilizados.
As organizações obtêm o máximo valor dos dados da mais alta qualidade – disponíveis, relevantes, completos, precisos, consistentes, oportunos,
utilizáveis, significativos e compreendidos. No entanto, para muitas decisões importantes, temos lacunas de informação – a diferença entre o que
sabemos e o que precisamos saber para tomar uma decisão eficaz. As lacunas de informação representam passivos corporativos com impactos
potencialmente profundos na eficácia e lucratividade operacional.
As organizações que reconhecem o valor de dados de alta qualidade podem tomar medidas concretas e proativas para melhorar a qualidade e a
usabilidade de dados e informações dentro de estruturas culturais regulatórias e éticas.
O aumento do papel da informação como um ativo organizacional em todos os setores levou a um maior foco por parte dos reguladores e legisladores
sobre os potenciais usos e abusos da informação. De Sarbanes-Oxley (com foco em controles sobre precisão e validade de dados de transações
financeiras da transação ao balanço) ao Solvência II
(com foco na linhagem de dados e qualidade dos dados que sustentam os modelos de risco e adequação de capital no setor de seguros), ao rápido
crescimento na última década dos regulamentos de privacidade de dados (abrangendo o processamento de dados sobre pessoas em uma ampla
gama de indústrias e jurisdições) , fica claro que, enquanto ainda aguardamos que a Contabilidade coloque a Informação no balanço como um ativo,
o ambiente regulatório espera cada vez mais vê-la no registro de riscos, com as devidas mitigações e controles sendo aplicados.
Da mesma forma, à medida que os consumidores se tornam mais conscientes de como seus dados são usados, eles esperam não apenas uma
operação mais suave e eficiente dos processos, mas também a proteção de suas informações e o respeito à sua privacidade. Isso significa que o
escopo de quem são nossos stakeholders estratégicos como profissionais de gerenciamento de dados geralmente pode ser mais amplo do que
poderia ter sido tradicionalmente. (Consulte os Capítulos 2 Ética no manuseio de dados e 7 Segurança de dados.)
Cada vez mais, o impacto do gerenciamento de informações no balanço patrimonial, infelizmente, surge com muita frequência quando esses riscos
não são gerenciados e os acionistas votam com suas carteiras de ações, os reguladores impõem multas ou restrições às operações e os clientes
votam com suas carteiras.

2.5.12 Gerenciamento e Tecnologia de Dados
Conforme observado na introdução do capítulo e em outros lugares, as atividades de gerenciamento de dados são abrangentes e
exigem habilidades técnicas e de negócios. Como quase todos os dados atuais são armazenados eletronicamente, as táticas de
gerenciamento de dados são fortemente influenciadas pela tecnologia. Desde o início, o conceito de gerenciamento de dados está
profundamente entrelaçado com o gerenciamento de tecnologia. Esse legado continua. Em muitas organizações, há uma tensão
contínua entre o desejo de construir uma nova tecnologia e o desejo de ter dados mais confiáveis – como se os dois fossem opostos um
ao outro em vez de necessários um ao outro.
O gerenciamento de dados bem-sucedido requer decisões sólidas sobre tecnologia, mas gerenciar tecnologia não é o mesmo que
gerenciar dados. As organizações precisam entender o impacto da tecnologia nos dados, a fim de evitar que a tentação tecnológica
conduza suas decisões sobre os dados. Em vez disso, os requisitos de dados alinhados à estratégia de negócios devem orientar as
decisões sobre tecnologia.
2.5.13 O gerenciamento eficaz de dados requer liderança e comprometimento
O Leader's Data Manifesto (2017) reconheceu que “as melhores oportunidades de uma organização para o crescimento orgânico estão
nos dados”. Embora a maioria das organizações reconheça seus dados como um ativo, eles estão longe de serem orientados por dados.
Muitos não sabem quais dados possuem ou quais dados são mais críticos para seus negócios. Eles confundem dados e tecnologia da
informação e administram mal ambos. Eles não abordam os dados estrategicamente. E eles subestimam o trabalho envolvido com o
gerenciamento de dados. Essas condições se somam aos desafios do gerenciamento de dados e apontam para um fator crítico para o
potencial de sucesso de uma organização: liderança comprometida e envolvimento de todos em todos os níveis da organização.11
Os desafios descritos aqui devem esclarecer este ponto: o gerenciamento de dados não é fácil nem simples. Mas, como poucas
organizações fazem isso bem, é uma fonte de oportunidades amplamente inexploradas. Tornar-se melhor nisso requer visão,
planejamento e vontade de mudar. (Consulte os Capítulos 15-17.)
A defesa do papel de Chief Data Officer (CDO) decorre do reconhecimento de que o gerenciamento de dados apresenta desafios únicos
e que o gerenciamento de dados bem-sucedido deve ser orientado aos negócios, e não à TI. Um CDO pode liderar iniciativas de
gerenciamento de dados e permitir que uma organização aproveite seus ativos de dados e obtenha vantagem competitiva deles. No
entanto, um CDO não apenas lidera iniciativas. Ele ou ela também deve liderar a mudança cultural que permite que uma organização
tenha uma abordagem mais estratégica para seus dados.
2.6 Estratégia de Gerenciamento de Dados
Uma estratégia é um conjunto de escolhas e decisões que, juntas, traçam um curso de ação de alto nível para atingir metas de alto
nível. No jogo de xadrez, uma estratégia é um conjunto sequenciado de movimentos para vencer por xeque-mate ou sobreviver por impasse.
Um plano estratégico é um curso de ação de alto nível para atingir metas de alto nível.
11 O texto completo do Manifesto de Dados do Líder pode ser encontrado em: http://bit.ly/2sQhcy7.
32 • DMBOK2
Uma estratégia de dados deve incluir planos de negócios para usar as informações para obter vantagem competitiva e apoiar os objetivos da
empresa. A estratégia de dados deve vir de uma compreensão das necessidades de dados inerentes à estratégia de negócios: quais dados a
organização precisa, como obterá os dados, como os gerenciará e garantirá sua confiabilidade ao longo do tempo e como
irá utilizá-lo.
Normalmente, uma estratégia de dados requer uma estratégia de programa de gerenciamento de dados de suporte – um plano para manter e
melhorar a qualidade dos dados, a integridade dos dados, o acesso e a segurança, ao mesmo tempo em que mitiga os riscos conhecidos e implícitos.
A estratégia também deve abordar desafios conhecidos relacionados ao gerenciamento de dados.
Em muitas organizações, a estratégia de gerenciamento de dados é de propriedade e mantida pelo CDO e promulgada por meio de uma equipe de
governança de dados, apoiada por um Conselho de Governança de Dados. Muitas vezes, o CDO elaborará uma estratégia inicial de dados e uma
estratégia de gerenciamento de dados antes mesmo da formação de um Conselho de Governança de Dados, a fim de obter o compromisso da alta
administração com o estabelecimento de administração e governança de dados.
Os componentes de uma estratégia de gerenciamento de dados devem incluir:
• Uma visão convincente para gerenciamento de dados
• Um caso de negócios resumido para gerenciamento de dados, com exemplos selecionados
• Princípios orientadores, valores e perspectivas de gestão
• A missão e os objetivos direcionais de longo prazo do gerenciamento de dados
• Medidas propostas de sucesso do gerenciamento de dados
• Objetivos do programa de gerenciamento de dados de curto prazo (12-24 meses) que são SMART (específicos, mensuráveis,
acionável, realista, com limite de tempo)
• Descrições de funções e organizações de gerenciamento de dados, juntamente com um resumo de suas responsabilidades
e direitos de decisão
• Descrições dos componentes e iniciativas do programa de Gerenciamento de Dados
• Um programa de trabalho priorizado com limites de escopo
• Um roteiro de implementação preliminar com projetos e itens de ação
Entregáveis do planejamento estratégico para gerenciamento de dados incluem:
• Uma Carta de Gerenciamento de Dados: visão geral, caso de negócios, objetivos, princípios orientadores, medidas de
sucesso, fatores críticos de sucesso, riscos reconhecidos, modelo operacional, etc.
• Uma Declaração de Escopo de Gerenciamento de Dados: Metas e objetivos para algum horizonte de planejamento (geralmente 3 anos)
e as funções, organizações e líderes individuais responsáveis por atingir esses objetivos.
• Um roteiro de implementação de gerenciamento de dados: identificando programas, projetos, tarefas específicos
atribuições e marcos de entrega (consulte o Capítulo 15).

A estratégia de gerenciamento de dados deve abordar todas as áreas de conhecimento do DAMA Data Management Framework relevantes
para a organização. (Consulte a Figura 5 Figura 5 A estrutura de gerenciamento de dados DAMA-DMBOK2 (A roda DAMA e as seções 3.3 e
4.)
3. Estruturas de gerenciamento de dados
O gerenciamento de dados envolve um conjunto de funções interdependentes, cada uma com seus próprios objetivos, atividades e
responsabilidades. Os profissionais de gerenciamento de dados precisam levar em conta os desafios inerentes à tentativa de obter valor de
um ativo corporativo abstrato, equilibrando objetivos estratégicos e operacionais, requisitos técnicos e de negócios específicos, demandas
de risco e conformidade e entendimentos conflitantes sobre o que os dados representam e se são de alta qualidade.
Há muito o que acompanhar, e é por isso que ajuda ter uma estrutura para entender o gerenciamento de dados de maneira abrangente e ver
as relações entre seus componentes. Como as funções dependem umas das outras e precisam estar alinhadas, em qualquer organização,
as pessoas responsáveis pelos diferentes aspectos do gerenciamento de dados precisam colaborar para que a organização obtenha valor
de seus dados.
As estruturas desenvolvidas em diferentes níveis de abstração fornecem uma variedade de perspectivas sobre como abordar o gerenciamento
de dados. Essas perspectivas fornecem insights que podem ser usados para esclarecer a estratégia, desenvolver roteiros, organizar equipes
e alinhar funções.
As ideias e conceitos apresentados no DMBOK2 serão aplicados de forma diferente nas organizações. A abordagem de uma organização
ao gerenciamento de dados depende de fatores-chave, como seu setor, a variedade de dados que usa, sua cultura, nível de maturidade,
estratégia, visão e os desafios específicos que está enfrentando. As estruturas descritas nesta seção fornecem algumas lentes através das
quais se pode ver o gerenciamento de dados e aplicar os conceitos apresentados no

DMBOK.
• Os dois primeiros, o Modelo de Alinhamento Estratégico e o Modelo de Informação de Amsterdã, mostram
relacionamentos que influenciam como uma organização gerencia os dados.
• O DAMA DMBOK Framework (A Roda DAMA, Hexágono e Diagrama de Contexto) descreve os dados
Áreas de Conhecimento de Gestão, conforme definido pela DAMA, e explica como sua representação visual dentro
o DMBOK.
• Os dois finalistas tomam a Roda DAMA como ponto de partida e reorganizam as peças para melhor
compreender e descrever as relações entre eles.
3.1 Modelo de Alinhamento Estratégico
O Modelo de Alinhamento Estratégico (Henderson e Venkatraman, 1999) abstrai os direcionadores fundamentais para qualquer abordagem
de gerenciamento de dados. Em seu centro está a relação entre dados e informações. A informação é mais frequentemente associada à
estratégia de negócios e ao uso operacional dos dados. Os dados estão associados a informações
34 • DMBOK2
tecnologia e processos que suportam o gerenciamento físico de sistemas que tornam os dados acessíveis para uso.
Ao redor desse conceito estão os quatro domínios fundamentais da escolha estratégica: estratégia de negócios, estratégia de tecnologia
da informação, infraestrutura e processos organizacionais e infraestrutura de tecnologia da informação e
processos.
O Modelo de Alinhamento Estratégico totalmente articulado é mais complexo do que o ilustrado na Figura 3. Cada um dos hexágonos
de canto tem suas próprias dimensões subjacentes. Por exemplo, tanto na estratégia de negócios quanto na de TI, é necessário levar
em conta o escopo, as competências e a governança. As operações devem levar em conta a infraestrutura, os processos e as habilidades.
As relações entre as peças ajudam uma organização a entender tanto o ajuste estratégico dos diferentes componentes quanto a
integração funcional das peças. Mesmo a representação de alto nível do modelo é útil para entender os fatores organizacionais que
influenciam as decisões sobre dados e gerenciamento de dados.
O negócio
ISTO
O negócio ISTO
Estratégia Estratégia
Em formação Dados
Organização
Em formação
E
Processo Sistemas
Figura 3 Modelo de Alinhamento Estratégico 12
3.2 O Modelo de Informação de Amsterdã
O Modelo de Informação de Amsterdã, assim como o Modelo de Alinhamento Estratégico, adota uma perspectiva estratégica de
alinhamento de negócios e TI (Abcouwer, Maes e Truijens, 1997),13 Conhecido como 9 células, ele reconhece uma camada intermediária
que se concentra na estrutura e nas táticas , incluindo planejamento e arquitetura. Além disso, reconhece a necessidade de comunicação
da informação (expressa como o pilar de governança da informação e qualidade de dados na Figura 4).
Os criadores das estruturas SAM e AIM descrevem em detalhes a relação entre os componentes, tanto de uma perspectiva horizontal
(Estratégia de Negócios/TI) quanto vertical (Estratégia de Negócios/Operações de Negócios).
12 Adaptado por Henderson e Venkatraman.
13 Veja também: Business IT Alignment Blog, The Amsterdam Information Model (AIM) 9-Cells (publicado em 2010-12-08). https://
businessitalignment.wordpress.com/tag/amsterdam-information-model/ Frameworks for IT Management, Capítulo 13.
Publicação Van Haren, 2006. http://bit.ly/2sq2Ow1.
Governança da Informação
O negócio ISTO
O negócio Em formação Estratégia de

TI e
Estratégia Estratégia & Estratégia &
Governança Governança Governança
Em formação ISTO
Organização
Táticas & Processos
Arquitetura Arquitetura Arquitetura
& Planejamento & Planejamento
Em formação Serviços de TI
O negócio
Operações Execução
Gestão &
& Usar Exploração
Qualidade dos dados
Figura 4 Modelo de Informações de Amsterdã 14
3.3 A Estrutura DAMA-DMBOK
O DAMA-DMBOK Framework aprofunda as Áreas de Conhecimento que compõem o escopo geral do gerenciamento de dados. Três
visuais descrevem a estrutura de gerenciamento de dados do DAMA:
• A Roda DAMA (Figura 5)

• O hexágono de Fatores Ambientais (Figura 6)
• O Diagrama de Contexto da Área de Conhecimento (Figura 7)
A Roda DAMA define as Áreas de Conhecimento de Gerenciamento de Dados. Ele coloca a governança de dados no centro das
atividades de gerenciamento de dados, uma vez que a governança é necessária para consistência e equilíbrio entre as funções. As
demais Áreas de Conhecimento (Arquitetura de Dados, Modelagem de Dados, etc.) são equilibradas em torno da Roda. Todos eles
são partes necessárias de uma função madura de gerenciamento de dados, mas podem ser implementados em momentos diferentes,
dependendo dos requisitos da organização. Essas Áreas de Conhecimento são o foco dos Capítulos 3 – 13 do DMBOK2.
(Veja a Figura 5.)
O hexágono Fatores Ambientais mostra a relação entre pessoas, processos e tecnologia e fornece uma chave para ler os diagramas
de contexto DMBOK. Ele coloca metas e princípios no centro, uma vez que fornecem orientação sobre como as pessoas devem
executar as atividades e usar efetivamente as ferramentas necessárias para o gerenciamento de dados bem-sucedido. (Veja a Figura
6.)
14 Adaptado de Maas.
36 • DMBOK2
Dados
Modelagem de dados
Arquitetura & Projeto
Armazenamento de dados
Qualidade dos dados
& Operações
Metadados
Dados Dados
Governança Segurança
Armazenamento de dados Integração de dados &

& O negócio Interoperabilidade
Inteligência
Referência Documento
& Mestre & Contente
Dados Gestão
Figura 5 A estrutura de gerenciamento de dados DAMA-DMBOK2 (a roda DAMA)
PESSOAS
Funções e
Responsabilidades
Entregáveis
Atividades
Metas &
Princípios
Técnicas
Ferramentas
Organização
& Cultura
PESSOAS
Figura 6 DAMA Fatores Ambientais Hexágono
Os diagramas de contexto da área de conhecimento (consulte a Figura 7) descrevem os detalhes das áreas de conhecimento,
incluindo detalhes relacionados a pessoas, processos e tecnologia. Eles são baseados no conceito de um diagrama SIPOC usado para
(Fornecedores, Entradas, Processos, Saídas e Consumidores). Os diagramas de contexto colocam as atividades no centro, pois
produzem as entregas que atendem aos requisitos das partes interessadas.
Cada diagrama de contexto começa com a definição e os objetivos da Área de Conhecimento. As atividades que orientam as metas
(centro) são classificadas em quatro fases: Planejar (P), Desenvolver (D), Operar (O) e Controlar (C). No lado esquerdo (fluindo para as
atividades) estão os Insumos e Fornecedores. No lado direito (fluindo das atividades) estão os Produtos e os Consumidores. Os
participantes estão listados abaixo das Atividades. Na parte inferior estão Ferramentas, Técnicas e Métricas que influenciam aspectos da
Área de Conhecimento.
As listas no diagrama de contexto são ilustrativas, não exaustivas. Os itens serão aplicados de forma diferente a diferentes organizações.
As listas de funções de alto nível incluem apenas as funções mais importantes. Cada organização pode adaptar este padrão para
suas próprias necessidades.
DIAGRAMA DE CONTEXTO GENÉRICO
Definição: Descrição de alto nível da área de conhecimento
Objetivos: Objetivos da Área de Conhecimento

1. Objetivo 1
2. Objetivo 2
O negócio
Motoristas
Entradas: Atividades: Entregáveis:

• Entregável 1
• Entrada 1
• Entregável 2
• Entrada 2 1. Atividade / Atividade de Planejamento
• Entregável 3
• Entrada 3 Grupo (P)
1. Subatividade
As entradas são 2. Subatividade As entregas são
geralmente saídas de outros 2. Controle de Atividade / Atividade geralmente entradas para outros
Áreas de Conhecimento Grupo (C) Áreas de Conhecimento
3. Atividade de Desenvolvimento /
Grupo de atividades (D)
4. Atividade / Atividade Operacional
Grupo (O)
Fornecedores: Consumidores:
Participantes: •
•
Fornecedor 1 Função 1 • Papel 1
•
Fornecedor 2 • Função 2 • Função 2
Técnico
Motoristas
Técnicas: • Ferramentas: Métricas:

Métodos e procedimentos para • • Resultados mensuráveis do
Tipos de pacotes de software para
executar atividades dar suporte a atividades processo
(P) Planejamento, (C) Controle, (D) Desenvolvimento, (O) Operações
Figura 7 Diagrama de Contexto da Área de Conhecimento

38 • DMBOK2
As partes componentes do diagrama de contexto incluem:
1. Definição: Esta seção define de forma concisa a Área de Conhecimento.
2. As metas descrevem o propósito da Área de Conhecimento e os princípios fundamentais que orientam o desempenho da
atividades dentro de cada Área de Conhecimento.
3. Atividades são as ações e tarefas necessárias para atingir os objetivos da Área de Conhecimento. Algumas atividades são descritas em termos de
subatividades, tarefas e etapas. As atividades são classificadas em quatro categorias: Planejar, Desenvolver, Operar e Controlar.
uma. (P) As atividades de planejamento definem o curso estratégico e tático para atingir as metas de gerenciamento de dados.
As atividades de planejamento ocorrem de forma recorrente.
b. (D) As atividades de desenvolvimento são organizadas em torno do ciclo de vida de desenvolvimento do sistema (SDLC)
(análise, projeto, construção, teste, preparação e implantação).
c. (C) As atividades de controle garantem a qualidade contínua dos dados e a integridade, confiabilidade e segurança dos sistemas por meio
dos quais os dados são acessados e usados.
d. (O) As Atividades Operacionais apoiam o uso, manutenção e aprimoramento de sistemas e processos
através do qual os dados são acessados e usados.
4. Insumos são as coisas tangíveis que cada Área de Conhecimento necessita para iniciar suas atividades. Muitas atividades
requerem as mesmas entradas. Por exemplo, muitos exigem conhecimento da Estratégia de Negócios como entrada.
5. As entregas são as saídas das atividades dentro da Área de Conhecimento, as coisas tangíveis que cada função é responsável por produzir. As
entregas podem ser fins em si mesmas ou insumos para outras atividades. Vários entregáveis primários são criados por várias funções.
6. Papéis e Responsabilidades descrevem como indivíduos e equipes contribuem para as atividades dentro da Área de Conhecimento. Os papéis
são descritos conceitualmente, com foco em grupos de papéis necessários na maioria das organizações. As funções para os indivíduos são
definidas em termos de competências e requisitos de qualificação. A Estrutura de Competências para a Era da Informação (SFIA) foi usada para
ajudar a alinhar os cargos. Muitos papéis serão cruzados

15 funcionais. (Consulte o Capítulo 16).
7. Os fornecedores são as pessoas responsáveis por fornecer ou possibilitar o acesso aos insumos para as atividades.
8. Consumidores aqueles que se beneficiam diretamente das entregas primárias criadas pelo gerenciamento de dados
Atividades.
9. Os participantes são as pessoas que executam, gerenciam o desempenho ou aprovam as atividades no
Área do Conhecimento.
15 http://bit.ly/2sTusD0.
10. Ferramentas são os aplicativos e outras tecnologias que viabilizam os objetivos da Área de Conhecimento.16
11. Técnicas são os métodos e procedimentos usados para realizar atividades e produzir entregáveis dentro de um
Área do Conhecimento. As técnicas incluem convenções comuns, recomendações de melhores práticas, padrões e
protocolos e, quando aplicável, abordagens alternativas emergentes.
12. Métricas são padrões para medição ou avaliação de desempenho, progresso, qualidade, eficiência ou
outro efeito. As seções de métricas identificam facetas mensuráveis do trabalho que é feito dentro de cada
Área do Conhecimento. As métricas também podem medir características mais abstratas, como melhoria ou valor.
Enquanto a Roda DAMA apresenta o conjunto de Áreas de Conhecimento em alto nível, o Hexágono reconhece os componentes da estrutura
das Áreas de Conhecimento e os Diagramas de Contexto apresentam o detalhe dentro de cada Área de Conhecimento.
Nenhuma das partes da estrutura existente de Gerenciamento de Dados DAMA descreve a relação entre as diferentes Áreas de Conhecimento.
Esforços para abordar essa questão resultaram em reformulações da Estrutura DAMA, que são descritas nas próximas duas seções.
3.4 Pirâmide DMBOK (Aiken)
Se perguntadas, muitas organizações diriam que querem tirar o máximo proveito de seus dados – elas estão se esforçando por aquela
pirâmide dourada de práticas avançadas (mineração de dados, análise, etc.). Mas essa pirâmide é apenas o topo de uma estrutura maior, um
pináculo sobre uma fundação. A maioria das organizações não tem o luxo de definir uma estratégia de gerenciamento de dados antes de
começar a gerenciar dados. Em vez disso, eles constroem essa capacidade, na maioria das vezes em condições menos do que ideais.
A estrutura de Peter Aiken usa as áreas funcionais do DMBOK para descrever a situação em que muitas organizações se encontram. Uma
organização pode usá-lo para definir um caminho a seguir para um estado em que tenha dados e processos confiáveis para apoiar as metas
estratégicas de negócios. Ao tentar atingir esse objetivo, muitas organizações passam por uma progressão lógica semelhante de etapas
(consulte a Figura 8):
• Fase 1: A organização adquire um aplicativo que inclui recursos de banco de dados. Isto significa o
organização tem um ponto de partida para modelagem/design de dados, armazenamento de dados e segurança de dados (por exemplo, deixe alguns
pessoas e manter os outros fora). Para que o sistema funcione dentro de seu ambiente e com seus dados
requer trabalho de integração e interoperabilidade.
• Fase 2: Assim que começarem a usar o aplicativo, encontrarão desafios com a qualidade de seus dados. Mas
obter dados de maior qualidade depende de Metadados confiáveis e Arquitetura de Dados consistente. Esses
fornecer clareza sobre como os dados de diferentes sistemas funcionam juntos.
• Fase 3: Práticas disciplinadas para gerenciamento de qualidade de dados, metadados e arquitetura exigem dados
Governança que fornece suporte estrutural para atividades de gerenciamento de dados. A Governança de Dados também permite
execução de iniciativas estratégicas, como Gestão de Documentos e Conteúdos, Dados de Referência
16 A DAMA International não endossa ferramentas ou fornecedores específicos.

40 • DMBOK2
Management, Master Data Management, Data Warehousing e Business Intelligence, que viabilizam totalmente as práticas
avançadas dentro da pirâmide dourada.
• Fase 4: A organização aproveita os benefícios de dados bem gerenciados e avança sua análise
capacidades.
Fase 4
Fase 3
Fase 1
Fase 2
Figura 8 Recurso de banco de dados adquirido ou construído 17
A pirâmide de Aiken se baseia na Roda DAMA, mas também a informa mostrando a relação entre as Áreas de Conhecimento. Eles não
são todos intercambiáveis; eles têm vários tipos de interdependências. A estrutura Pyramid tem dois drivers. Primeiro, a ideia de construir
sobre uma base, usando componentes que precisam estar nos lugares certos para apoiar uns aos outros. Em segundo lugar, a ideia um
tanto contraditória de que estes podem ser postos em prática de forma arbitrária
ordem.
3.5 Estrutura de gerenciamento de dados DAMA evoluída
A pirâmide de Aiken descreve como as organizações evoluem para melhores práticas de gerenciamento de dados. Outra maneira de
olhar para as Áreas de Conhecimento DAMA é explorar as dependências entre elas. Desenvolvida por Sue Geuens, a estrutura da Figura
9 reconhece que as funções de Business Intelligence e Analytic dependem de todas as outras funções de gerenciamento de dados. Eles
dependem diretamente de Master Data e soluções de data warehouse. Mas estes, por sua vez, dependem dos sistemas e aplicações de
alimentação. Qualidade de dados confiável, design de dados e práticas de interoperabilidade de dados são a base de sistemas e
aplicativos confiáveis. Além disso, a governança de dados, que dentro deste
17 Golden Pyramid figura copyright Data BluePrint, usado com permissão.

O modelo inclui gerenciamento de metadados, segurança de dados, arquitetura de dados e gerenciamento de dados de referência, fornece
uma base da qual todas as outras funções são dependentes.
INTELIGÊNCIA DE NEGÓCIOS / ANÁLISE
DADOS MESTRE ARMAZÉM DE DADOS
SISTEMAS / APLICAÇÃO
SAÍDAS
DEPENDÊNCIAS
INTEGRAÇÃO DE DADOS &

QUALIDADE DE DADOS PROJETO DE DADOS
INTEROPERABILIDADE
GESTÃO DE DADOS
DADOS DADOS REFERÊNCIA

METADADOS
SEGURANÇA ARQUITETURA DADOS
Figura 9 Dependências da área funcional do DAMA
Uma terceira alternativa ao DAMA Wheel é mostrada na Figura 10. Isso também se baseia em conceitos arquitetônicos para propor um
conjunto de relacionamentos entre as Áreas de Conhecimento do DAMA. Ele fornece detalhes adicionais sobre o conteúdo de algumas
Áreas de Conhecimento para esclarecer essas relações.
A estrutura começa com o objetivo orientador do gerenciamento de dados: permitir que as organizações obtenham valor de seus ativos de
dados como fazem com outros ativos. A obtenção de valor requer o gerenciamento do ciclo de vida, portanto, as funções de gerenciamento
de dados relacionadas ao ciclo de vida dos dados são representadas no centro do diagrama. Isso inclui planejar e projetar dados confiáveis
e de alta qualidade; estabelecer processos e funções através dos quais os dados podem ser habilitados para uso e também mantidos; e,
por fim, utilizar os dados em diversos tipos de análise e por meio desses processos, potencializando seu valor.
A seção de gerenciamento do ciclo de vida descreve o design de gerenciamento de dados e as funções operacionais (modelagem,
arquitetura, armazenamento e operações, etc.) que são necessárias para dar suporte aos usos tradicionais de dados (Business Intelligence,
gerenciamento de documentos e conteúdo). Ele também reconhece funções de gerenciamento de dados emergentes (armazenamento de Big Data)
42 • DMBOK2
que suportam usos emergentes de dados (Ciência de Dados, análise preditiva, etc.). Nos casos em que os dados são realmente gerenciados
como um ativo, as organizações podem obter valor direto de seus dados vendendo-os para outras organizações (monetização de dados).
FUNÇÕES DE GERENCIAMENTO DE DADOS
SUPERVISÃO: Governança de Dados
Estratégia Avaliação de dados Princípios e Ética Política Mordomia
Mudança de Cultura
GERENCIAMENTO DO CICLO DE VIDA
PLANO & USAR E MELHORAR ATIVAR E MANTER

PROJETO
Armazenamento de dados Dados O negócio Ciência de dados
& Operações Armazenagem Inteligência

Arquitetura
Dados Big Data Dados mestre Dados
Integração e Armazenar Uso Monetização

Dados
Interoperabilidade
Modelagem e
Documento
Projeto Referência
Dados mestre & Contente Preditivo
Dados
Gestão Gestão Análise
Gestão
ATIVIDADES FUNDAMENTAIS
Gerenciamento de risco de dados: segurança, privacidade, conformidade
Gerenciamento de metadados
Gerenciamento de qualidade de dados
Figura 10 Estrutura da Função de Gerenciamento de Dados DAMA
As organizações que se concentram apenas nas funções diretas do ciclo de vida não obterão tanto valor de seus dados quanto aquelas que
dão suporte ao ciclo de vida dos dados por meio de atividades fundamentais e de supervisão. Atividades fundamentais, como risco de dados
gerenciamento, metadados e gerenciamento de qualidade de dados, abrangem o ciclo de vida dos dados. Eles permitem melhores decisões de design e
facilitam o uso dos dados. Se eles forem bem executados, a manutenção dos dados será mais barata, os consumidores de dados terão mais confiança neles
e as oportunidades de usá-los se expandirão.
Para suportar com sucesso a produção e o uso de dados e garantir que as atividades fundamentais sejam executadas com disciplina, muitas organizações
estabelecem a supervisão na forma de governança de dados. Um programa de governança de dados permite que uma organização seja orientada por dados,
colocando em prática a estratégia e os princípios de suporte, políticas e práticas de administração que garantem que a organização reconheça e atue nas
oportunidades para obter valor de seus dados. Um programa de governança de dados também deve se envolver em atividades de gerenciamento de mudanças
organizacionais para educar a organização e incentivar comportamentos que permitam usos estratégicos de dados. Assim, a necessidade de mudança de
cultura abrange a amplitude das responsabilidades de governança de dados, especialmente à medida que uma organização amadurece suas práticas de
gerenciamento de dados.
O DAMA Data Management Framework também pode ser descrito como uma evolução do DAMA Wheel, com atividades principais cercadas por atividades
de ciclo de vida e uso, contidas nas restrições de governança. (Veja a Figura 11.)
As atividades principais, incluindo Gerenciamento de Metadados, Gerenciamento de Qualidade de Dados e definição de estrutura de dados (arquitetura) estão
no centro da estrutura.
As atividades de gerenciamento do ciclo de vida podem ser definidas a partir de uma perspectiva de planejamento (gerenciamento de riscos, modelagem,
design de dados, gerenciamento de dados de referência) e uma perspectiva de capacitação (gerenciamento de dados mestre, desenvolvimento de tecnologia
de dados, integração e interoperabilidade de dados, armazenamento de dados e armazenamento e operações de dados) .
Os usos emergem das atividades de gerenciamento do ciclo de vida: uso de dados mestres, gerenciamento de documentos e conteúdo, inteligência de
negócios, ciência de dados, análise preditiva, visualização de dados. Muitos deles criam mais dados aprimorando ou desenvolvendo insights sobre os dados
existentes. As oportunidades de monetização de dados podem ser identificadas como usos

De dados.
As atividades de governança de dados fornecem supervisão e contenção, por meio de estratégia, princípios, política e administração. Eles permitem a
consistência por meio da classificação e avaliação de dados.
A intenção de apresentar diferentes representações visuais do DAMA Data Management Framework é fornecer uma perspectiva adicional e abrir a discussão
sobre como aplicar os conceitos apresentados no DMBOK. À medida que a importância do gerenciamento de dados cresce, essas estruturas tornam-se
ferramentas de comunicação úteis tanto na comunidade de gerenciamento de dados quanto entre a comunidade de gerenciamento de dados e nossos
stakeholders.
4. DAMA e DMBOK
Embora o gerenciamento de dados apresente muitos desafios, poucos deles são novos. Desde pelo menos a década de 1980, as organizações reconheceram
que o gerenciamento de dados é fundamental para seu sucesso. À medida que nossa capacidade e desejo de criar e explorar dados aumentaram, também
aumentou a necessidade de práticas confiáveis de gerenciamento de dados.

44 • DMBOK2
Figura 11 Roda DAMA evoluída
A DAMA foi fundada para enfrentar esses desafios. O DMBOK, um livro de referência acessível e confiável para profissionais de gerenciamento
de dados, apoia a missão da DAMA ao:
• Fornecer uma estrutura funcional para a implementação de práticas de gerenciamento de dados corporativos;
incluindo princípios orientadores, práticas amplamente adotadas, métodos e técnicas, funções, papéis,
entregas e métricas.
• Estabelecer um vocabulário comum para conceitos de gerenciamento de dados e servir como base para o melhor
práticas para profissionais de gerenciamento de dados.

• Servindo como guia de referência fundamental para o CDMP (Certified Data Management Professional)
e outros exames de certificação.
O DMBOK está estruturado em torno das onze Áreas de Conhecimento do DAMA-DMBOK Data Management Framework (também conhecido como
DAMA Wheel, veja a Figura 5). Os Capítulos 3 a 13 são focados nas Áreas de Conhecimento.
Cada capítulo da Área de Conhecimento segue uma estrutura comum:
1. Introdução
o Drivers de Negócios
o Objetivos e Princípios o
Conceitos Essenciais
2. Atividades
3. Ferramentas
4. Técnicas 5.
Diretrizes de Implementação
6. Relação com Governança de Dados
7. Métricas
As Áreas de Conhecimento descrevem o escopo e o contexto de conjuntos de atividades de gerenciamento de dados. Embutidos nas Áreas de
Conhecimento estão os objetivos e princípios fundamentais do gerenciamento de dados. Como os dados se movem horizontalmente dentro das
organizações, as atividades da área de conhecimento se cruzam entre si e com outras funções organizacionais.
1. A Governança de Dados fornece orientação e supervisão para o gerenciamento de dados, estabelecendo um sistema de
direitos de decisão sobre os dados que respondem pelas necessidades da empresa. (Capítulo 3)
2. A Arquitetura de Dados define o plano de gerenciamento de ativos de dados, alinhando-se à estratégia organizacional para estabelecer
requisitos de dados estratégicos e designs para atender a esses requisitos. (Capítulo 4)
3. Modelagem e Design de Dados é o processo de descobrir, analisar, representar e comunicar
requisitos de dados em uma forma precisa chamada modelo de dados. (Capítulo 5)
4. Armazenamento de Dados e Operações inclui o projeto, implementação e suporte de dados armazenados para
maximizar seu valor. As operações fornecem suporte em todo o ciclo de vida dos dados, desde o planejamento até o descarte dos
dados. (Capítulo 6)
5. A segurança de dados garante que a privacidade e a confidencialidade dos dados sejam mantidas, que os dados não sejam violados e
que os dados sejam acessados adequadamente. (Capítulo 7)
6. Integração e Interoperabilidade de Dados inclui processos relacionados à movimentação e consolidação de
dados dentro e entre armazenamentos de dados, aplicativos e organizações. (Capítulo 8)
7. O gerenciamento de documentos e conteúdo inclui atividades de planejamento, implementação e controle usadas para
gerencie o ciclo de vida de dados e informações encontrados em uma variedade de mídias não estruturadas, especialmente documentos
necessários para dar suporte a requisitos de conformidade legal e regulatória. (Capítulo 9)

46 • DMBOK2
8. Dados mestres e de referência incluem reconciliação e manutenção contínuas de dados compartilhados essenciais para permitir o uso
consistente em todos os sistemas da versão mais precisa, oportuna e relevante da verdade sobre entidades comerciais essenciais.
(Capítulo 10)
9. Data Warehousing e Business Intelligence incluem o planejamento, implementação e controle
processos para gerenciar dados de suporte à decisão e permitir que os trabalhadores do conhecimento obtenham valor dos dados
por meio de análise e relatórios. (Capítulo 11)
10. Metadados incluem atividades de planejamento, implementação e controle para permitir o acesso a Metadados integrados de
alta qualidade, incluindo definições, modelos, fluxos de dados e outras informações críticas para entender os dados e os
sistemas pelos quais são criados, mantidos e acessados. (Capítulo 12)
11. A Qualidade dos Dados inclui o planejamento e implementação de técnicas de gestão da qualidade para medir,
avaliar e melhorar a adequação dos dados para uso dentro de uma organização. (Capítulo 13)
Além dos capítulos das Áreas de Conhecimento, o DAMA-DMBOK contém capítulos sobre os seguintes tópicos:
• A ética de manipulação de dados descreve o papel central que a ética de dados desempenha na tomada de decisões informadas, socialmente
decisões responsáveis sobre os dados e seus usos. A conscientização sobre a ética da coleta, análise e uso de dados deve orientar
todos os profissionais de gerenciamento de dados. (Capítulo 2)
• Big Data e Data Science descrevem as tecnologias e processos de negócios que surgem como nossa habilidade
para coletar e analisar grandes e diversos conjuntos de dados aumenta. (Capítulo 14.)
• A Avaliação de Maturidade de Gerenciamento de Dados descreve uma abordagem para avaliar e melhorar um
recursos de gerenciamento de dados da organização. (Capítulo 15)
• A Organização do Gerenciamento de Dados e as Expectativas de Função fornecem as melhores práticas e considerações para
organizar as equipes de gerenciamento de dados e possibilitar práticas de gerenciamento de dados bem-sucedidas. (Capítulo 16)
• Gerenciamento de Dados e Gerenciamento de Mudanças Organizacionais descreve como planejar e
passar com sucesso pelas mudanças culturais necessárias para incorporar práticas eficazes de gerenciamento de dados em uma
organização. (Capítulo 17)
Como uma determinada organização gerencia seus dados depende de suas metas, tamanho, recursos e complexidade, bem como sua percepção
de como os dados suportam sua estratégia geral. A maioria das empresas não realiza todas as atividades descritas em cada Área de Conhecimento.
No entanto, entender o contexto mais amplo do gerenciamento de dados permitirá que as organizações tomem melhores decisões sobre onde se
concentrar à medida que trabalham para melhorar as práticas dentro e entre essas áreas relacionadas.
funções.
5. Trabalhos Citados / Recomendados

Abcouwer, AW, Maes, R., Truijens, J.: “Contours of a Generic Model for Information Management.” Primavera
Working Paper 97-07, 1997. http://bit.ly/2rV5dLx.
Adelman, Sid, Larissa Moss e Majid Abai. Estratégia de Dados. Addison-Wesley Professional, 2005. Impressão.
Aiken, Peter e Billings, Juanita. Monetizando o Gerenciamento de Dados. Technics Publishing, LLC, 2014. Imprimir.
Aiken, Peter e Harbour, Todd. Estratégia de Dados e o Executivo de Dados Corporativos. Technics Publishing, LLC. 2017. Imprimir.
APRA (Autoridade de Regulação Prudencial Australiana). Guia Prático Prudencial CPG 234, Gerenciamento de Riscos de Segurança em Informação
e Tecnologia da Informação. Maio de 2013. http://bit.ly/2sAKe2y.
APRA (Autoridade de Regulação Prudencial Australiana). Guia de Práticas Prudenciais CPG 235, Gerenciando Riscos de Dados. Setembro de 2013.
http://bit.ly/2sVIFil.
Borek, Alexander et ai. Total Information Risk Management: Maximizando o Valor dos Dados e dos Ativos de Informação. Morgan Kaufmann, 2013.
Impresso.
Brackett, Michael. Design de recursos de dados: realidade além da ilusão. Technics Publishing, LLC. 2014. Imprimir.
BRICE, Tim. Benefícios de uma Taxonomia de Dados. Blogue 2005-07-11. http://bit.ly/2sTeU1U.
Chisholm, Malcolm e Roblyn-Lee, Diane. Definições em Gerenciamento de Dados: Um Guia para Metadados Semânticos Fundamentais.
Design Media, 2008. Impresso.
DEVLIN, Barry. Ignorância Empresarial. Technics Publishing, LLC. 2013. Imprimir.
Inglês, Larry. Melhorando o Data Warehouse e a Qualidade da Informação Empresarial: Métodos para Reduzir Custos e Aumentar Lucros. John Wiley
and Sons, 1999. Impresso.
Evans, Nina e Price, James. “Barreiras para a implantação eficaz de ativos de informação: uma perspectiva de gestão executiva”. Revista
Interdisciplinar de Informação, Conhecimento e Gestão Volume 7, 2012. Acessado em
http://bit.ly/2sVwvG4.
Fischer, Tony. O ativo de dados: como empresas inteligentes administram seus dados para o sucesso dos negócios. Wiley, 2009. Impresso. Wiley e
SAS Business Ser.
Henderson, JC, H Venkatraman, H. “Alavancando a tecnologia da informação para transformar as organizações”. Diário do Sistema IBM. Volume
38, Edição 2.3, 1999. [Reimpressão de 1993] http://bit.ly/2sV86Ay e http://bit.ly/1uW8jMQ.
Kent, William. Dados e realidade: uma perspectiva atemporal sobre a percepção e gerenciamento de informações em nosso mundo impreciso. 3d edição.
Technics Publications, LLC, 2012. Imprimir.
Kring, Kenneth L. Mapeamento de estratégia de negócios - o poder de saber como tudo se encaixa. Langdon Street Press (uma divisão do Hillcrest
Publishing Group, Inc.), 2009. Imprimir.
Olá, Steve. Data-ismo: a revolução que transforma a tomada de decisões, o comportamento do consumidor e quase tudo o mais.
HarperBusiness, 2015. Impresso.
Loshin, David. Gestão do Conhecimento Empresarial: A Abordagem de Qualidade de Dados. Morgan Kaufmann, 2001. Impresso.
Maes, R.: “Uma Estrutura Genérica para Gestão da Informação”. Documento de Trabalho PrimaVera 99-02, 1999.
McGilvray, Danette. Executando Projetos de Qualidade de Dados: Dez Passos para Dados de Qualidade e Informações Confiáveis. Morgan Kaufmann,
2008. Impresso.
McKnight, William. Gestão da Informação: Estratégias para Ganhar Vantagem Competitiva com Dados. Morgan Kaufmann, 2013. Impresso. Guias do
gerente experiente.
Moody, Daniel e Walsh, Peter. “Medindo o valor da informação: uma abordagem de avaliação de ativos”. Conferência Europeia sobre Sistemas de
Informação (ECIS), 1999. http://bit.ly/29JucLO.
Olson, Jack E. Qualidade de Dados: A Dimensão da Precisão. Morgan Kaufmann, 2003. Impresso.
Redman, Thomas. “Dados ruins custam US$ 3 trilhões por ano.” Harvard Business Review. 22 de setembro de 2016. Web.
48 • DMBOK2
Redman, Thomas. Orientado a dados: lucrando com seu ativo comercial mais importante. Harvard Business Review Press. 2008.
Imprimir.
Redman, Thomas. Qualidade de dados: o guia de campo. Imprensa Digital, 2001. Impressão.
Reid, Roger, Gareth Fraser-King e W. David Schwaderer. Ciclos de Vida de Dados: Gerenciando Dados para Vantagem Estratégica. Wiley, 2007. Impresso.
Rockley, Ann e Charles Cooper. Gerenciando o conteúdo corporativo: uma estratégia de conteúdo unificada. 2ª edição. Novos Cavaleiros, 2012. Imprimir.
Vozes que importam.
Sebastian-Coleman, Laura. Medindo a qualidade dos dados para melhoria contínua: uma estrutura de avaliação da qualidade dos dados.
Morgan Kaufmann, 2013. Impresso. A Série Morgan Kaufmann sobre Business Intelligence.
Simsão, Graeme. Modelagem de Dados: Teoria e Prática. Technics Publications, LLC, 2007. Imprimir.
Surdak, Christopher. Data Crush: como o maremoto da informação está gerando novas oportunidades de negócios. AMCOM, 2014.
Imprimir.
Waclawski, Janine. Desenvolvimento Organizacional: Uma Abordagem Baseada em Dados para Mudança Organizacional. Pfeiffer, 2001. Impresso.
Branco, Estevão. Mostre-me a prova: ferramentas e estratégias para fazer os dados funcionarem para os padrões estaduais do núcleo comum. 2ª edição.
Imprensa de Aprendizagem Avançada, 2011. Imprimir.
CAPÍTULO 2
Ética de manipulação de dados
1. Introdução
D
definida de forma simples, ética são princípios de comportamento baseados em ideias de certo e errado. Princípios éticos
muitas vezes se concentram em ideias como justiça, respeito, responsabilidade, integridade, qualidade, confiabilidade, transparência,
e confiança. A ética no tratamento de dados está preocupada com como adquirir, armazenar, gerenciar, usar e descartar
dados de forma alinhada com os princípios éticos. O manuseio de dados de maneira ética é necessário para o sucesso a longo prazo de qualquer
organização que queira obter valor de seus dados. O manuseio antiético de dados pode resultar na perda de reputação e de clientes, pois coloca
em risco as pessoas cujos dados são expostos. Em alguns casos, práticas antiéticas também são ilegais.18 Em última análise, para os profissionais
de gerenciamento de dados e as organizações para as quais trabalham, a ética dos dados é uma questão de responsabilidade social.
A ética do manuseio de dados é complexa, mas se concentra em vários conceitos principais:
• Impacto nas pessoas: porque os dados representam características dos indivíduos e são usados para tomar decisões
que afetam a vida das pessoas, é imperativo gerenciar sua qualidade e confiabilidade.
• Potencial de uso indevido: o uso indevido de dados pode afetar negativamente pessoas e organizações, portanto, há um
imperativo para evitar o uso indevido de dados.
• Valor econômico dos dados: Os dados têm valor econômico. A ética da propriedade dos dados deve determinar como isso
valor pode ser acessado e por quem.
As organizações protegem os dados com base principalmente em leis e requisitos regulatórios. No entanto, como os dados representam pessoas
(clientes, funcionários, pacientes, fornecedores, etc.), os profissionais de gerenciamento de dados devem reconhecer que existem razões éticas
(e legais) para proteger os dados e garantir que eles não sejam usados indevidamente. Mesmo os dados que não representam diretamente os
indivíduos ainda podem ser usados para tomar decisões que afetam a vida das pessoas.
Há um imperativo ético não apenas para proteger os dados, mas também para gerenciar sua qualidade. As pessoas que tomam decisões, bem
como aquelas afetadas pelas decisões, esperam que os dados sejam completos e precisos. Tanto do ponto de vista comercial quanto técnico, os
profissionais de gerenciamento de dados têm a responsabilidade ética de gerenciar dados de uma maneira que reduza o
18 HIPAA (Health Insurance Portability and Accountability Act) nos EUA, PIPEDA (Personal Information Protection and Electronic
Documents Act) no Canadá, o Regulamento Geral de Proteção de Dados da UE (GDPR) e outras leis de proteção de dados /
privacidade de informações descrevem obrigações em relação ao manuseio de dados de identificação pessoal (por exemplo, nome,
endereços, afiliação religiosa ou orientação sexual) e privacidade (acesso ou restrição a essas informações).
49
50 • DMBOK2
risco de que possa deturpar, ser mal utilizado ou mal compreendido. Essa responsabilidade se estende por todo o ciclo de vida dos dados,
desde a criação até a destruição de dados.
Ética de manipulação de dados
Definição: A ética no tratamento de dados se preocupa com a forma de adquirir, armazenar, gerenciar,
interpretar, analisar/aplicar e descartar dados de forma alinhada com os princípios éticos, incluindo a responsabilidade
da comunidade.
Metas:
1. Definir o tratamento ético dos dados na organização.

2. Educar a equipe sobre os riscos da organização de manuseio inadequado de dados.
3. Mudar/instilar a cultura e os comportamentos preferidos no manuseio de dados.
4. Monitorar o ambiente regulatório, medir, monitorar e ajustar as abordagens da organização para a ética em
dados.
O negócio
Motoristas
• Existente e 1. Revise as práticas de manipulação de dados • Práticas Atuais e
Preferido (P) Lacunas
• Tratamento de dados éticos

Ética Organizacional • 2. Identificar Princípios, Práticas e
Estratégia
Estratégia de Negócios e Fatores de risco (P) • Plano de comunicação
Metas 3. Criação e Tratamento Ético de Dados • Programa de Treinamento de Ética
• Organizacional Estratégia • Corporativo Ético

Declarações sobre dados
Estrutura 4. Abordar as lacunas das práticas (D)
• Conscientização da Ética
• Cultura de negócios 5. Comunicar e educar a equipe
Problemas de dados
• Regulamentos (D) • Incentivos alinhados, KPIs,

• Corporativo Existente 6. Monitorar e manter o alinhamento e alvos
Políticas (C) • Políticas Atualizadas
• Tratamento de dados éticos
Comunicando
Fornecedores: Participantes: • Consumidores:

• Executivos Órgãos de Governança de Dados •
Funcionários
• Administradores de dados • CDO / CIO • Executivos
• Dados Executivos • Executivos •
Reguladores
Comissários •
Coordenação de Administradores de Dados
• Executivos de TI •
Especialistas no assunto
• Provedores de dados • Gerentes de Mudanças
• • Serviços de DM
Reguladores
Técnico
Motoristas
Ferramentas: Métricas:
Técnicas:
•
• Plano de comunicação Wikis, Bases de Conhecimento, • Número de empregados
Lista de verificação Sites de intranet Treinado
• • •
Declaração de Ética Anual Microblogs, outros internos Incidentes de
Afirmações ferramentas de comunicação conformidade/não conformidade
•
Executivo corporativo
Envolvimento
Figura 12 Diagrama de Contexto: Ética no Tratamento de Dados

ÉTICA DE TRATAMENTO DE DADOS • 51
Infelizmente, muitas organizações não reconhecem e respondem às obrigações éticas inerentes ao gerenciamento de dados. Eles
podem adotar uma perspectiva técnica tradicional e professar não entender os dados; ou assumem que, se seguirem a letra da lei,
não correm riscos relacionados ao manuseio de dados. Esta é uma suposição perigosa.
O ambiente de dados está evoluindo rapidamente. As organizações estão usando dados de maneiras que não imaginariam alguns
anos atrás. Embora as leis codifiquem alguns princípios éticos, a legislação não consegue acompanhar os riscos associados à
evolução do ambiente de dados. As organizações devem reconhecer e responder à sua obrigação ética de proteger os dados que
lhes são confiados, promovendo e sustentando uma cultura que valorize o tratamento ético das informações.
2. Direcionadores de Negócios
Como as declarações de W. Edward Deming sobre qualidade, ética significa “fazer certo quando ninguém está olhando”. Uma
abordagem ética para o uso de dados está sendo cada vez mais reconhecida como uma vantagem competitiva de negócios (Hasselbalch e
Transberg, 2016). O manuseio ético de dados pode aumentar a confiabilidade de uma organização e os dados da organização e os
resultados do processo. Isso pode criar melhores relacionamentos entre a organização e seus stakeholders.
A criação de uma cultura ética envolve a introdução de governança adequada, incluindo a instituição de controles para garantir que
os resultados pretendidos e resultantes do processamento de dados sejam éticos e não violem a confiança ou infrinjam a dignidade
humana.
O manuseio de dados não acontece no vácuo, e clientes e partes interessadas esperam comportamento e resultados éticos das
empresas e seus processos de dados. Reduzir o risco de que os dados pelos quais a organização é responsável sejam usados
indevidamente por funcionários, clientes ou parceiros é a principal razão para uma organização cultivar princípios éticos para o
manuseio de dados. Há também uma responsabilidade ética de proteger dados de criminosos (ou seja, proteger contra hackers e
possíveis violações de dados. (Consulte o Capítulo 7.)
Diferentes modelos de propriedade de dados influenciam a ética do manuseio de dados. Por exemplo, a tecnologia melhorou a
capacidade das organizações de compartilhar dados entre si. Essa capacidade significa que as organizações precisam tomar
decisões éticas sobre sua responsabilidade de compartilhar dados que não pertencem a elas.
As funções emergentes de Chief Data Officer, Chief Risk Officer, Chief Privacy Officer e Chief Analytics Officer estão focadas no
controle de risco, estabelecendo práticas aceitáveis para o manuseio de dados. Mas a responsabilidade vai além das pessoas nessas
funções. O tratamento ético de dados exige o reconhecimento de toda a organização dos riscos associados ao uso indevido de
dados e o compromisso organizacional de lidar com dados com base em princípios que protegem os indivíduos e respeitam os
imperativos relacionados à propriedade dos dados.
52 • DMBOK2
3. Conceitos Essenciais
3.1 Princípios Éticos para Dados
Os princípios aceitos da bioética, que se concentram na preservação da dignidade humana, fornecem um bom ponto de partida geral para os
princípios da ética dos dados. Por exemplo, os Princípios de Belmont para pesquisa médica podem ser adaptados nas disciplinas de
Gerenciamento da Informação (US-HSS, 1979).
• Respeito pelas Pessoas: Este princípio reflete o requisito ético fundamental de que as pessoas sejam tratadas de
uma forma que respeite a sua dignidade e autonomia como indivíduos humanos. Também exige que, nos casos em que
as pessoas têm 'autonomia diminuída', deve-se tomar cuidado extra para proteger sua dignidade e seus direitos.
Quando consideramos os dados como um ativo, temos em mente que os dados também afetam, representam ou tocam as pessoas?
Os dados pessoais são diferentes de outros 'ativos' brutos, como petróleo ou carvão. O uso antiético de dados pessoais pode influenciar
diretamente as interações das pessoas, as oportunidades de emprego e o lugar na comunidade. Nós projetamos sistemas de informação de
uma forma que limita a autonomia ou a liberdade de escolha? Consideramos como o processamento de dados pode afetar pessoas com
deficiência mental ou física? Levamos em conta como eles acessarão e utilizarão os dados? O processamento de dados ocorre com base em
consentimento informado e válido?
• Beneficência: Este princípio tem dois elementos: primeiro, não prejudicar; segundo, maximizar os possíveis benefícios e
minimizar possíveis danos.
O princípio ético de 'não causar danos' tem uma longa história na ética médica, mas também tem aplicação clara no contexto de gerenciamento
de dados e informações. Os profissionais de dados e informações éticos devem identificar as partes interessadas e considerar os resultados do
processamento de dados e trabalhar para maximizar os benefícios e minimizar os riscos de danos causados pelos processos projetados. Um
processo é projetado de uma forma que assume um resultado de soma zero em vez de uma situação ganha-ganha? O processamento de dados
é desnecessariamente invasivo e existe uma maneira menos arriscada de atender aos requisitos da necessidade do negócio? O tratamento de
dados em questão carece de transparência de uma forma que pode ocultar possíveis danos às pessoas?
• Justiça: Este princípio considera o tratamento justo e equitativo das pessoas.
Algumas perguntas que podem ser feitas em relação a este princípio: As pessoas ou grupos de pessoas estão sendo tratados de forma desigual
em circunstâncias semelhantes? O resultado de um processo ou algoritmo resulta em efeitos que beneficiam ou prejudicam desproporcionalmente
um determinado grupo de pessoas? O aprendizado de máquina está sendo treinado usando conjuntos de dados que contêm dados que reforçam
inadvertidamente preconceitos culturais?
O Relatório Menlo do Departamento de Segurança Interna dos Estados Unidos adapta os Princípios Belmont à Pesquisa de Tecnologia da
Informação e Comunicação, acrescentando um quarto princípio: Respeito pela Lei e pelo Interesse Público (US DHS, 2012).
Em 2015, a Autoridade Europeia para a Proteção de Dados publicou um parecer sobre ética digital destacando as “implicações de engenharia,
filosóficas, legais e morais” dos desenvolvimentos no processamento de dados e Big Data. Isto
pediu um foco no processamento de dados que defenda a dignidade humana e estabeleceu quatro pilares necessários para um ecossistema
de informação que garanta o tratamento ético dos dados (EDPS, 2015):
• Regulamentação do processamento de dados orientada para o futuro e respeito aos direitos à privacidade e à proteção de dados
• Controladores responsáveis que determinam o processamento de informações pessoais
• Engenharia e design conscientes da privacidade de produtos e serviços de processamento de dados
• Indivíduos empoderados
Esses princípios mapeiam amplamente o princípio estabelecido no Relatório Belmont, com foco na promoção da dignidade e autonomia
humana. A AEPD afirma que a privacidade é um direito humano fundamental. Desafia os inovadores a ver a dignidade, a privacidade e a
autonomia como uma plataforma na qual um ambiente digital sustentável é moldado, em vez de um obstáculo ao desenvolvimento, e exige
transparência e comunicação com as partes interessadas.
A Governança de Dados é uma ferramenta vital para garantir que esses princípios sejam considerados ao decidir quem pode fazer o quê
com quais dados e em quais circunstâncias o processamento é apropriado ou necessário. Os impactos e riscos éticos do processamento de
dados em todas as partes interessadas devem ser considerados pelos profissionais e gerenciados de maneira semelhante à qualidade dos
dados.
3.2 Princípios por trás da Lei de Privacidade de Dados
A política pública e a lei tentam codificar o certo e o errado com base em princípios éticos. Mas eles não podem codificar todas as
circunstâncias. Por exemplo, as leis de privacidade na União Europeia, Canadá e Estados Unidos mostram diferentes abordagens para
codificar a ética de dados. Esses princípios também podem fornecer uma estrutura para a política organizacional.
A lei de privacidade não é nova. Privacidade e privacidade da informação como conceitos estão firmemente ligados ao imperativo ético de
respeitar os direitos humanos. Em 1890, os juristas americanos Samuel Warren e Louis Brandeis descreveram a privacidade e a privacidade
da informação como direitos humanos com proteções na lei comum que sustentam vários direitos na constituição dos EUA. Em 1973, foi
proposto um código de Fair Information Practice, e o conceito de privacidade da informação como um direito fundamental foi reafirmado no
US Privacy Act de 1974, que afirma que “o direito à privacidade é um direito pessoal e fundamental protegido pela Constituição dos Estados
Unidos".
Na sequência das violações dos direitos humanos durante a Segunda Guerra Mundial, a Convenção Europeia dos Direitos do Homem
(1950) estabeleceu tanto o direito geral à privacidade quanto o direito específico à privacidade da informação (ou o direito à proteção de
seus dados pessoais) como direitos humanos que são fundamentais para defender o direito à Dignidade Humana.
Em 1980, a Organização para Cooperação e Desenvolvimento Econômico (OCDE) estabeleceu Diretrizes e Princípios para Processamento
Justo de Informações que se tornaram a base para as leis de proteção de dados da União Européia.
Os oito princípios fundamentais da OCDE, os Padrões de Processamento de Informações Justas, destinam-se a garantir que os dados
pessoais sejam processados de uma maneira que respeite o direito dos indivíduos à privacidade. Eles incluem: limitações na coleta de
dados; uma expectativa de que os dados sejam de alta qualidade; a exigência de que, quando os dados são coletados, sejam feitos para
uma finalidade específica; limitações no uso de dados; salvaguardas de segurança; uma expectativa de abertura e transparência; o direito
de um indivíduo de contestar a exatidão dos dados relacionados a si mesmo; e responsabilidade para que as organizações sigam as
diretrizes.
54 • DMBOK2
Desde então, os princípios da OCDE foram substituídos pelos princípios subjacentes ao Regulamento Geral de Proteção de Dados da UE
(GDPR, 2016). Consulte a Tabela 1.
Tabela 1 Princípios do GDPR
Princípio GDPR Descrição do Princípio
Justiça, Legalidade, Os dados pessoais devem ser processados de forma lícita, justa e transparente em relação ao titular
Transparência dos dados.
Limitação de Propósito Os dados pessoais devem ser coletados para fins específicos, explícitos e legítimos, e não processados
de maneira incompatível com esses fins.
Minimização de dados Os dados pessoais devem ser adequados, relevantes e limitados ao necessário em relação às
finalidades para as quais são processados.
Precisão Os dados pessoais devem ser precisos e, quando necessário, mantidos atualizados. Devem ser tomadas
todas as medidas razoáveis para garantir que os dados pessoais inexatos, tendo em conta a finalidade
para a qual são tratados, sejam apagados ou retificados sem demora.
Limitação de armazenamento Os dados devem ser mantidos de uma forma que permita a identificação dos titulares dos dados
[indivíduos] por não mais do que o necessário para os fins para os quais os dados pessoais são processados.
Integridade e Os dados devem ser processados de maneira a garantir a segurança adequada dos dados pessoais,
Confidencialidade incluindo proteção contra processamento não autorizado ou ilegal e contra perda, destruição ou
dano acidental, usando recursos técnicos ou organizacionais apropriados.
medidas.
Responsabilidade Os Controladores de Dados serão responsáveis e poderão demonstrar conformidade com [estes
princípios].
Esses princípios são equilibrados e apoiam certos direitos qualificados que os indivíduos têm sobre seus dados, incluindo direitos de
acesso, retificação de dados imprecisos, portabilidade, direito de se opor ao processamento de dados pessoais que possam causar danos
ou sofrimento e apagamento. Quando o processamento de dados pessoais é feito com base no consentimento, esse consentimento deve
ser uma ação afirmativa que é dada livremente, específica, informada e inequívoca. O GDPR exige governança e documentação efetivas
para habilitar e demonstrar conformidade e exige privacidade por design.
A lei de privacidade canadense combina um regime abrangente de proteção de privacidade com auto-regulamentação do setor.
A PIPEDA (Lei de Proteção de Informações Pessoais e Documentos Eletrônicos) se aplica a todas as organizações que coletam, usam e
divulgam informações pessoais no decorrer de atividades comerciais. Ele estipula regras, com exceções, que as organizações devem
seguir no uso das informações pessoais dos consumidores. A Tabela 2 descreve as obrigações estatutárias baseadas no PIPEDA.19
No Canadá, o Federal Privacy Commissioner é o único responsável pelo tratamento de reclamações de privacidade contra organizações.
No entanto, eles cumprem um papel de ombudsman; suas decisões são apenas recomendações (não juridicamente vinculativas e sem
valor precedente, mesmo dentro do gabinete do comissário).
19 http://bit.ly/2tNM53c.
Tabela 2 Obrigações Estatutárias de Privacidade do Canadá
Princípio PIPEDA Descrição do Princípio

Uma organização é responsável pelas informações pessoais sob seu controle e deve designar um indivíduo para
Responsabilidade
ser responsável pela conformidade da organização com o princípio.
Uma organização deve identificar os propósitos para os quais as informações pessoais são coletadas antes ou no
Identificando
momento em que as informações são coletadas.
Finalidades
Consentimento
Uma organização deve obter o conhecimento e o consentimento do indivíduo para a coleta, uso ou divulgação de
informações pessoais, exceto quando inapropriado.
A recolha de informação pessoal deve limitar-se ao necessário para os fins identificados pela organização. As
Limitando
informações serão coletadas por meios justos e legais. As informações pessoais não devem ser usadas ou
Coleta, uso,
divulgadas para fins diferentes daqueles para os quais foram coletadas, exceto com o consentimento do indivíduo
Divulgação, e
Retenção ou conforme exigido por lei.
As informações pessoais serão retidas apenas pelo tempo necessário para o cumprimento desses propósitos.
As informações pessoais devem ser tão precisas, completas e atualizadas quanto necessário para os fins a que
Precisão
se destinam.
As informações pessoais devem ser protegidas por salvaguardas de segurança adequadas à sensibilidade das
proteções
informações.
Uma organização deve disponibilizar informações específicas sobre suas políticas e práticas relacionadas ao
Abertura
gerenciamento de suas informações pessoais para os indivíduos.
Acesso individual Mediante solicitação, um indivíduo deve ser informado da existência, uso e divulgação de suas informações
pessoais, e deve ter acesso a essas informações. Um indivíduo deve poder contestar a exatidão e integridade das
informações e alterá-las conforme apropriado.
Um indivíduo deve ser capaz de abordar um desafio relativo ao cumprimento dos princípios acima ao indivíduo
Observância
designado ou indivíduos responsáveis pelo cumprimento da organização.
Desafios
Em março de 2012, a Comissão Federal de Comércio dos EUA (FTC) emitiu um relatório recomendando que as organizações projetem e
implementem seus próprios programas de privacidade com base nas melhores práticas descritas no relatório (ou seja, Privacidade por Design)
(FTC 2012). O relatório reafirma o foco da FTC nos Princípios de Processamento Justo de Informações (ver Tabela 3).
Tabela 3 Critérios do Programa de Privacidade dos Estados Unidos
Princípio Descrição do Princípio
Perceber / Os coletores de dados devem divulgar suas práticas de informação antes de coletar informações pessoais dos
consumidores.
Conhecimento
Escolha / Os consumidores devem ter opções sobre se e como as informações pessoais coletadas deles podem ser usadas para fins
Consentimento
além daqueles para os quais as informações foram fornecidas.
Acesso / Os consumidores devem poder visualizar e contestar a exatidão e integridade dos dados coletados sobre eles.
Participação
Os coletores de dados devem tomar medidas razoáveis para garantir que as informações coletadas dos consumidores
Integridade /
sejam precisas e protegidas contra uso não autorizado.
Segurança
Aplicação O uso de um mecanismo confiável para impor sanções pelo descumprimento dessas práticas de informações
/ Reparação justas.
56 • DMBOK2
Esses princípios são desenvolvidos para incorporar os conceitos das Diretrizes de Processamento Justo de Informações da OCDE, incluindo
ênfase na minimização de dados (limitação razoável de coleta) e limitação de armazenamento (retenção de som), precisão e a exigência de que
as empresas forneçam segurança razoável para os dados do consumidor. Outros focos para práticas de informações justas incluem:
• Escolha simplificada do consumidor para reduzir a carga imposta aos consumidores
• A recomendação de manter um procedimento abrangente de gerenciamento de dados em todas as informações
ciclo da vida
• Opção Não rastrear
• Requisitos para consentimento expresso afirmativo
• Preocupações em relação aos recursos de coleta de dados de grandes provedores de plataformas; transparência e clareza
avisos e políticas de privacidade

• Acesso dos indivíduos aos dados
• Educar os consumidores sobre as práticas de privacidade de dados
• Privacidade por Design
Há uma tendência global de aumentar a proteção legislativa da privacidade das informações dos indivíduos, seguindo os padrões estabelecidos
pela legislação da UE. As leis em todo o mundo impõem diferentes tipos de restrições à movimentação de dados através das fronteiras
internacionais. Mesmo dentro de uma organização multinacional, haverá limites legais para compartilhar informações globalmente. Portanto, é
importante que as organizações tenham políticas e diretrizes que permitam que os funcionários sigam os requisitos legais, bem como usem os
dados dentro do apetite de risco da organização.
3.3 Dados Online em um Contexto Ético
Atualmente, estão surgindo dezenas de iniciativas e programas projetados para criar um conjunto codificado de princípios para informar
comportamentos éticos online nos Estados Unidos (Davis, 2012). Os tópicos incluem:
• Propriedade de dados: Os direitos de controlar os dados pessoais em relação a sites e dados de mídia social
corretores. Agregadores downstream de dados pessoais podem incorporar dados em perfis profundos que os indivíduos são
não tem conhecimento.
• O direito de ser esquecido: ter informações sobre um indivíduo ser apagadas da web, particularmente
para ajustar a reputação online. Este tópico faz parte das práticas de retenção de dados em geral.
• Identidade: Ter o direito de esperar uma identidade e uma identidade correta e optar por uma identidade privada.
• Liberdade de expressão online: Expressar suas opiniões versus bullying, incitação ao terror, 'trollagem' ou
insultante.
3.4 Riscos de práticas antiéticas de manipulação de dados
A maioria das pessoas que trabalha com dados sabe que é possível usar dados para deturpar fatos. O livro clássico How to Lie with Statistics de
Darrell Huff (1954) descreve uma série de maneiras pelas quais os dados podem ser usados para deturpar fatos
enquanto cria um verniz de factualidade. Os métodos incluem seleção criteriosa de dados, manipulação de escala e omissão de alguns
pontos de dados. Essas abordagens ainda estão em funcionamento hoje.
Uma maneira de entender as implicações do tratamento ético de dados é examinar as práticas que a maioria das pessoas concordaria serem
antiéticas. O tratamento ético de dados implica um dever positivo de lidar com os dados de acordo com princípios éticos, como a
confiabilidade. Garantir que os dados sejam confiáveis pode incluir a medição em relação às dimensões de qualidade de dados, como
precisão e pontualidade. Também inclui um nível básico de veracidade e transparência – não usar dados para mentir ou enganar e ser
transparente em relação às fontes, usos e intenções por trás do manuseio de dados de uma organização. Os cenários a seguir descrevem
práticas antiéticas de dados que violam esses princípios, entre outros.
3.4.1 Tempo
É possível mentir por omissão ou inclusão de determinados pontos de dados em um relatório ou atividade com base no tempo.
A manipulação do mercado de ações por meio de negociações de ações 'no final do dia' pode aumentar artificialmente o preço das ações no
fechamento do mercado, dando uma visão artificial do valor das ações. Isso é chamado de market timing e é ilegal.
A equipe de Business Intelligence pode ser a primeira a perceber anomalias. Na verdade, eles agora são vistos como jogadores valiosos nos
centros de negociação de ações do mundo recriando padrões de negociação em busca de tais problemas, além de analisar relatórios e
revisar e monitorar regras e alertas. A equipe ética de Business Intelligence pode precisar alertar as funções apropriadas de governança ou
gerenciamento para tais anomalias.
3.4.2 Visualizações enganosas
Tabelas e gráficos podem ser usados para apresentar dados de maneira enganosa. Por exemplo, mudar a escala pode fazer uma linha de
tendência parecer melhor ou pior. Deixar pontos de dados, comparar dois fatos sem esclarecer sua relação ou ignorar convenções visuais
aceitas (como que os números em um gráfico de pizza representando porcentagens devem somar 100 e apenas 100), também podem ser
usados para enganar as pessoas a interpretar visualizações de maneiras que não são suportadas pelos próprios dados.20
3.4.3 Definições pouco claras ou comparações inválidas
Uma agência de notícias dos EUA informou, com base em dados do US Census Bureau de 2011, que 108,6 milhões de pessoas nos EUA
estavam em bem-estar, mas apenas 101,7 milhões de pessoas tinham empregos em tempo integral, fazendo parecer que uma porcentagem
desproporcional da população geral estava em bem-estar.21 A Media Matters explicou a discrepância: O número de 108,6 milhões para o
número de “pessoas em bem-estar” vem de uma conta do Census Bureau...
20 Como Estatísticas (Website). Gráficos enganosos: exemplos da vida real. 24 de janeiro de 2014. http://bit.ly/1jRLgRH Veja
também io9 (Website). Os infográficos mais inúteis e enganosos da Internet. http://bit.ly/1YDgURl Veja http://bit.ly/2tNktve
Google “visualização de dados enganosa” para exemplos adicionais. Para contra-exemplos, ou seja, visuais com base ética, ver
Tufte (2001).
21 Em 2015, a população geral dos EUA é estimada em 321,4 milhões de pessoas. http://bit.ly/2iMlP58
58 • DMBOK2
programas, que incluem “qualquer pessoa que resida em um domicílio em que uma ou mais pessoas receberam benefícios” no quarto trimestre
de 2011, incluindo indivíduos que não receberam benefícios do governo. Por outro lado, o número de “pessoas com emprego a tempo inteiro”...
incluiu apenas os indivíduos que trabalhavam, e não os que residiam num agregado onde pelo menos uma pessoa trabalha.22
A coisa ética a fazer, ao apresentar informações, é fornecer um contexto que informe seu significado, como uma definição clara e inequívoca
da população que está sendo medida e o que significa estar “no bem-estar”. Quando o contexto necessário é deixado de fora, a superfície da
apresentação pode significar que os dados não suportam. Se esse efeito é obtido com a intenção de enganar ou simplesmente falta de jeito, é
um uso antiético de dados.
Também é simplesmente necessário, do ponto de vista ético, não fazer mau uso das estatísticas.
A 'suavização' estatística dos números ao longo de um período pode mudar completamente a percepção do número. 'Snooping de mineração
de dados' é um termo recentemente cunhado para um fenômeno em investigações estatísticas de mineração de dados em que correlações
exaustivas são realizadas em um conjunto de dados, essencialmente sobre o treinamento de um modelo estatístico. Por causa do
comportamento de 'significância estatística', é razoável esperar alguns resultados estatisticamente significativos que são realmente resultados
aleatórios. O destreinado pode ser enganado. Isso é comum nos setores financeiro e médico (Jensen, 2000; ma.utexas.edu, 2012).23
3.4.4 Viés
Viés refere-se a uma inclinação de perspectiva. No nível pessoal, o termo está associado a julgamentos ou preconceitos irracionais. Em
estatística, viés refere-se a desvios dos valores esperados. Eles geralmente são introduzidos por meio de erros sistemáticos na amostragem
ou na seleção de dados.24 O viés pode ser introduzido em diferentes pontos do ciclo de vida dos dados: quando os dados são coletados ou
criados, quando são selecionados para inclusão na análise, por meio dos métodos pelos quais são analisados , e na forma como os resultados
da análise são apresentados.
O princípio ético da justiça cria um dever positivo de estar ciente de possíveis vieses que possam influenciar a coleta, processamento, análise
ou interpretação de dados. Isso é particularmente importante no caso de processamento de dados em grande escala que pode afetar
desproporcionalmente grupos de pessoas que foram historicamente sujeitos a preconceito ou tratamento injusto. Usar dados sem abordar as
maneiras pelas quais o viés pode ser introduzido pode agravar o preconceito e reduzir a transparência no processo, dando aos resultados
resultantes o verniz de imparcialidade ou neutralidade quando não são neutros. Existem vários tipos de preconceito:
• Coleta de dados para resultado pré-definido: O analista é pressionado a coletar dados e produzir resultados em
para chegar a uma conclusão pré-definida, e não como um esforço para chegar a uma conclusão objetiva.
22http://mm4a.org/2spKToU O exemplo também demonstra visuais enganosos, pois no gráfico de barras, a barra de 108,6 milhões foi
mostrada como aproximadamente 5 vezes maior que a coluna de 101,7 milhões.
23 Veja também vários artigos de W. Edwards Deming em: http://bit.ly/2tNnlZh
24 http://bit.ly/2lOzJqU
• Uso tendencioso dos dados coletados: os dados podem ser coletados com viés limitado, mas um analista é pressionado a usá-los
para confirmar uma abordagem pré-determinada. Os dados podem até ser manipulados para esse fim (ou seja, alguns dados podem ser
descartado se não confirmar a abordagem).
• Palpite e pesquisa: o analista tem um palpite e quer satisfazer esse palpite, mas usa apenas os dados que
confirma o palpite e não leva em conta outras possibilidades de que os dados possam vir à tona.
• Metodologia de amostragem tendenciosa: A amostragem geralmente é uma parte necessária da coleta de dados. Mas o preconceito pode ser
introduzido pelo método usado para selecionar o conjunto de amostras. É virtualmente impossível para os seres humanos amostrar
sem qualquer tipo de preconceito. Para limitar o viés, use ferramentas estatísticas para selecionar amostras e estabelecer
tamanhos de amostra. A consciência do viés em conjuntos de dados usados para treinamento é particularmente importante.
• Contexto e Cultura: Os preconceitos são muitas vezes baseados na cultura ou no contexto, portanto, sair dessa cultura ou
contexto é necessário para um olhar neutro sobre a situação.
As questões de viés dependem de muitos fatores, como o tipo de processamento de dados em questão, as partes interessadas envolvidas, como os conjuntos de
dados são preenchidos, a necessidade de negócios a ser atendida e os resultados esperados do processo.
No entanto, nem sempre é possível ou mesmo desejável remover todos os preconceitos. O viés de negócios contra clientes pobres (clientes com os quais não se
busca mais negócios) é uma peça fundamental para muitos cenários construídos por analistas de negócios; eles são desmarcados das amostras ou ignorados na
análise. Nesse caso, os analistas devem documentar os critérios que usaram para definir a população que estão estudando. Em contraste, algoritmos preditivos que
determinam o 'risco criminal' de indivíduos ou policiamento preditivo enviando recursos para bairros específicos teriam um risco muito maior de violar princípios éticos
de justiça ou equidade, e deveriam ter maiores precauções para garantir transparência e responsabilidade algorítmica e para combater o preconceito em conjuntos de
dados treinando qualquer algoritmo preditivo.25
3.4.5 Transformando e Integrando Dados
A integração de dados apresenta desafios éticos porque os dados são alterados à medida que se movem de sistema para sistema. Se os dados não forem integrados
com cuidado, apresentam risco de manipulação de dados antiética ou até ilegal. Esses riscos éticos se cruzam com problemas fundamentais no gerenciamento de
dados, incluindo:
• Conhecimento limitado da origem e linhagem dos dados: se uma organização não souber de onde os dados vieram
e como ele mudou à medida que se moveu entre os sistemas, então a organização não pode provar que o
os dados representam o que eles afirmam representar.
• Dados de baixa qualidade: as organizações devem ter padrões claros e mensuráveis para a qualidade dos dados e devem
medir seus dados para confirmar que atendem aos padrões de qualidade. Sem essa confirmação, um
organização não pode garantir os dados e os consumidores de dados podem estar em risco ou colocar outros em risco quando
usar os dados.
25 Para exemplos de viés de aprendizado de máquina, consulte Brennan (2015) e os sites da Fundação Ford e ProPublica. Além do
viés, há o problema da opacidade. À medida que os algoritmos preditivos de máquinas de aprendizado se tornam mais complexos, é
difícil rastrear a lógica e a linhagem de suas decisões. Ver Lewis e Monett (2017). http://bit.ly/1Om41ap; http://bit.ly/2oYmNRu.
60 • DMBOK2
• Metadados não confiáveis: os consumidores de dados dependem de metadados confiáveis, incluindo definições consistentes de
elementos de dados individuais, documentação de origem dos dados e documentação de linhagem (por exemplo, regras de
quais dados são integrados). Sem Metadados confiáveis, os dados podem ser mal compreendidos e potencialmente mal utilizados.
Nos casos em que os dados podem se mover entre organizações e especialmente onde podem se mover além das fronteiras,
Os metadados devem incluir tags que indiquem sua proveniência, quem é o proprietário e se requer informações específicas
proteção.
• Nenhuma documentação do histórico de correção de dados: as organizações também devem ter informações auditáveis
relacionadas com as formas como os dados foram alterados. Mesmo que a intenção da correção de dados seja melhorar a
qualidade dos dados, isso pode ser ilegal. A correção de dados deve sempre seguir uma mudança formal e auditável
processo de controle.
3.4.6 Ofuscação / Redação de Dados
Ofuscar ou redigir dados é a prática de tornar as informações anônimas ou remover informações confidenciais.
Mas a ofuscação por si só pode não ser suficiente para proteger os dados se uma atividade downstream (análise ou combinação com outros conjuntos de
dados) puder expor os dados. Este risco está presente nos seguintes casos:
• Agregação de dados: ao agregar dados em algum conjunto de dimensões e remover dados de identificação,
um conjunto de dados ainda pode servir a um propósito analítico sem a preocupação de divulgar a identificação pessoal
informações (PII). Agregações em áreas geográficas são uma prática comum (ver Capítulos 7 e 14).
• Marcação de dados : A marcação de dados é usada para classificar a sensibilidade dos dados (secretos, confidenciais, pessoais, etc.) e para
controle de liberação para comunidades apropriadas, como o público ou fornecedores, ou mesmo fornecedores de determinados
países ou outras considerações da comunidade.
• Mascaramento de dados : O mascaramento de dados é uma prática em que apenas os dados enviados apropriados desbloquearão os processos.
Os operadores não podem ver quais podem ser os dados apropriados; eles simplesmente digitam as respostas dadas a eles, e
se essas respostas estiverem corretas, outras atividades serão permitidas. Processos de negócios usando mascaramento de dados
incluem call centers terceirizados ou subcontratados que devem ter acesso apenas parcial às informações.
O uso de conjuntos de dados extremamente grandes em análises de Data Science levanta preocupações práticas e não meramente teóricas sobre a eficácia
da anonimização. Dentro de grandes conjuntos de dados, é possível combinar dados de forma a permitir que os indivíduos sejam especificamente identificados,
mesmo que os conjuntos de dados de entrada tenham sido anonimizados. A primeira preocupação quando os dados chegam a um data lake é analisá-los em
busca de dados confidenciais e aplicar métodos de proteção aceitos. No entanto, estes por si só podem não oferecer proteção suficiente; é por isso que é
vital que as organizações tenham uma governança forte e um compromisso com o manuseio ético de dados. (Consulte o Capítulo 14.)
3.5 Estabelecendo uma Cultura Ética de Dados
Estabelecer uma cultura de manipulação ética de dados requer a compreensão das práticas existentes, a definição de comportamentos esperados, a
codificação destes em políticas e um código de ética, e o fornecimento de treinamento e supervisão para fazer cumprir as expectativas.
comportamentos. Assim como outras iniciativas relacionadas à governança de dados e à mudança de cultura, esse processo requer uma liderança forte.
O tratamento ético dos dados obviamente inclui o cumprimento da lei, mas também influencia a forma como os dados são analisados e interpretados,
bem como a forma como são aproveitados interna e externamente. Uma cultura organizacional que valoriza claramente o comportamento ético não terá
apenas códigos de conduta, mas também garantirá que haja controles claros de comunicação e governança para apoiar os funcionários com dúvidas e
caminhos de encaminhamento adequados para que, se os funcionários tomarem conhecimento de práticas antiéticas ou riscos éticos, são capazes de
destacar o problema ou interromper o processo sem medo de retaliação. Melhorar o comportamento ético de uma organização em relação aos dados
requer um processo formal de Gerenciamento de Mudanças Organizacionais (OCM). (Consulte o Capítulo 17.)
3.5.1 Revisar as Práticas de Manipulação de Dados do Estado Atual
O primeiro passo para a melhoria é entender o estado atual. O objetivo de revisar as práticas de manipulação de dados existentes é entender o grau em
que elas estão direta e explicitamente conectadas a direcionadores éticos e de conformidade. Essa revisão também deve identificar quão bem os
funcionários entendem as implicações éticas das práticas existentes na construção e preservação da confiança de clientes, parceiros e outras partes
interessadas. A entrega da revisão deve documentar os princípios éticos que fundamentam a coleta, o uso e a supervisão de dados da organização,
durante todo o ciclo de vida dos dados, incluindo atividades de compartilhamento de dados.
3.5.2 Identificar Princípios, Práticas e Fatores de Risco
O objetivo de formalizar práticas éticas em torno do manuseio de dados é reduzir o risco de que os dados possam ser mal utilizados e causar danos a
clientes, funcionários, fornecedores, outras partes interessadas ou à organização como um todo. Uma organização que tenta melhorar suas práticas deve
estar ciente dos princípios gerais, como a necessidade de proteger a privacidade dos indivíduos, bem como preocupações específicas do setor, como a
necessidade de proteger recursos financeiros ou

informações relacionadas à saúde.
A abordagem de uma organização à ética de dados deve estar alinhada com os requisitos de conformidade legal e regulatória. Por exemplo, as
organizações que atuam globalmente precisam ter um amplo conhecimento dos princípios éticos que fundamentam as leis dos países em que atuam,
bem como conhecimento específico dos acordos entre países. Além disso, a maioria das organizações tem riscos específicos, que podem estar
relacionados à sua pegada tecnológica, sua taxa de rotatividade de funcionários, os meios pelos quais coletam dados de clientes ou outros fatores.
Os princípios devem estar alinhados com os riscos (coisas ruins que podem acontecer se os princípios não forem seguidos) e práticas (as formas corretas
de fazer as coisas para que os riscos sejam evitados). As práticas devem ser apoiadas por controles, conforme ilustrado no exemplo a seguir:
• Princípio orientador: As pessoas têm direito à privacidade em relação às informações sobre sua saúde.
Portanto, os dados pessoais de saúde dos pacientes não devem ser acessados, exceto por pessoas autorizadas
para acessá-lo como parte do cuidado aos pacientes.

62 • DMBOK2
• Risco: Se houver amplo acesso aos dados pessoais de saúde dos pacientes, as informações sobre os indivíduos podem se tornar
de conhecimento público, comprometendo assim seu direito à privacidade.
• Prática: Apenas enfermeiros e médicos terão acesso aos dados pessoais de saúde dos pacientes e apenas para fins de prestação de
cuidados.
• Controle: Haverá uma revisão anual de todos os usuários dos sistemas que contêm saúde pessoal
informações dos pacientes para garantir que apenas as pessoas que precisam ter acesso tenham acesso.
3.5.3 Criar uma estratégia e roteiro de tratamento de dados éticos
Após uma revisão do estado atual e o desenvolvimento de um conjunto de princípios, uma organização pode formalizar uma estratégia para
melhorar suas práticas de manipulação de dados. Essa estratégia deve expressar tanto os princípios éticos quanto o comportamento esperado
em relação aos dados, expressos em declarações de valores e um código de comportamento ético. As peças componentes de tal estratégia
incluem:
• Declarações de valores : Declarações de valores descrevem em que a organização acredita. Os exemplos podem incluir verdade, justiça
ou justiça. Essas declarações fornecem uma estrutura para o manuseio ético de dados e tomada de decisões.
• Princípios éticos de manipulação de dados : Os princípios éticos de manipulação de dados descrevem como uma organização
aborda os desafios apresentados pelos dados; por exemplo, como respeitar o direito dos indivíduos à privacidade.
Princípios e comportamentos esperados podem ser resumidos em um código de ética e apoiados por uma política de ética. A
socialização do código e da política deve ser incluída no plano de treinamento e comunicação.
• Estrutura de conformidade: Uma estrutura de conformidade inclui fatores que orientam as obrigações organizacionais.
Os comportamentos éticos devem permitir que a organização atenda aos requisitos de conformidade. Os requisitos de
conformidade são influenciados por preocupações geográficas e setoriais.
• Avaliações de risco: As avaliações de risco identificam a probabilidade e as implicações de problemas específicos
surgindo dentro da organização. Eles devem ser usados para priorizar as ações relacionadas à mitigação, incluindo o cumprimento
dos princípios éticos pelos funcionários.
• Treinamento e comunicações: O treinamento deve incluir a revisão do código de ética. O funcionário deve assinar que está
familiarizado com o código e as implicações do tratamento antiético de dados. O treinamento precisa ser contínuo; por exemplo,
por meio de uma exigência de uma declaração anual de ética.
As comunicações devem chegar a todos os funcionários.
• Roteiro: O roteiro deve incluir um cronograma com atividades que podem ser aprovadas pela administração.
As atividades incluirão a execução do plano de treinamento e comunicação, identificação e correção de lacunas nas práticas
existentes, mitigação de riscos e planos de monitoramento. Desenvolva declarações detalhadas que reflitam a posição alvo da
organização sobre o manuseio apropriado de dados, inclua funções, responsabilidades e processos e referências a especialistas
para obter mais informações. O roteiro deve abranger todas as leis aplicáveis e fatores culturais.
• Abordagem para auditoria e monitoramento: As ideias éticas e o código de ética podem ser reforçados por meio de
Treinamento. Também é aconselhável monitorar atividades específicas para garantir que elas estejam sendo executadas em
cumprimento dos princípios éticos.
3.5.4 Adote um Modelo de Risco Ético Socialmente Responsável
Profissionais de dados envolvidos em Business Intelligence, analytics e Data Science são frequentemente responsáveis por dados que
descreve:
• Quem são as pessoas, incluindo seus países de origem e suas características raciais, étnicas e religiosas
• O que as pessoas fazem, incluindo atividades políticas, sociais e potencialmente criminosas
• Onde as pessoas moram, quanto dinheiro elas têm, o que compram, com quem conversam ou enviam mensagens de texto ou e-mail para
• Como as pessoas são tratadas, incluindo resultados da análise, como pontuação e rastreamento de preferências que
marque-os como privilegiados ou não para negócios futuros
Esses dados podem ser mal utilizados e contrariar os princípios subjacentes à ética dos dados: respeito pelas pessoas, beneficência e justiça.
A execução justa de atividades de BI, análise e ciência de dados requer uma perspectiva ética que olhe além dos limites da organização para a qual
as pessoas trabalham e leve em conta as implicações para a comunidade mais ampla. Uma perspectiva ética é necessária não apenas porque os
dados podem ser facilmente usados indevidamente, mas também porque as organizações têm a responsabilidade social de não prejudicar seus
dados.
Por exemplo, uma organização pode definir critérios para o que considera 'maus' clientes para parar de fazer negócios com esses indivíduos. Mas
se essa organização tiver o monopólio de um serviço essencial em uma determinada área geográfica, alguns desses indivíduos poderão ficar sem
esse serviço essencial e estarão em perigo devido à decisão da organização.
Projetos que usam dados pessoais devem ter uma abordagem disciplinada para o uso desses dados. Veja a Figura 13. Eles
deve contabilizar:
• Como eles selecionam suas populações para estudo (seta 1)
• Como os dados serão capturados (seta 2)
• Em quais atividades a análise se concentrará (seta 3)
• Como os resultados serão disponibilizados (seta 4)
Dentro de cada área de consideração, eles devem abordar possíveis riscos éticos, com foco particular em possíveis efeitos negativos para clientes
ou cidadãos.
Um modelo de risco pode ser usado para determinar se o projeto deve ser executado. Também influenciará como executar o projeto. Por exemplo,
os dados serão tornados anônimos, as informações privadas removidas do arquivo, a segurança dos arquivos reforçada ou confirmada e uma
revisão da lei de privacidade local e outras aplicáveis analisadas com o departamento jurídico.
A desistência de clientes pode não ser permitida por lei se a organização for um monopólio em uma jurisdição e os cidadãos não tiverem outras
opções de fornecedores, como energia ou água.

64 • DMBOK2
Como os projetos de análise de dados são complexos, as pessoas podem não ver os desafios éticos. As organizações precisam
identificar ativamente os riscos potenciais. Eles também precisam proteger os denunciantes que veem riscos e levantam preocupações.
O monitoramento automatizado não é proteção suficiente contra atividades antiéticas. As pessoas – os próprios analistas – precisam
refletir sobre possíveis vieses. As normas culturais e a ética no local de trabalho influenciam o comportamento corporativo – aprenda
e use o modelo de risco ético. A DAMA International incentiva os profissionais de dados a se posicionarem profissionalmente e
apresentarem a situação de risco a líderes empresariais que podem não ter reconhecido as implicações de usos específicos de
dados e essas implicações em seu trabalho.
Identificação
• Demografia necessária
• Método de seleção
1
Resultados Captura de comportamento
• • Conteúdo obrigatório
Privilégios concedidos ou
• Método de captura
negado Riscos éticos em • Atividades
• Engajamento adicional ou não
•
•
Remoção de relacionamento
Benefício ou sanção
4 uma amostragem
Projeto
2 • Sentimento
• Localização
• Data hora
• Confiança ou falta de confiança
• Conjuntos de dados de combinação
• Tratamento tendencioso
•
Revisão legal e ética
BI/Analytics/Ciência de dados
• Perspectivas de Perfil
• Atividades reais e previstas
Figura 13 Modelo de risco ético para projetos de amostragem
3.6 Ética e Governança de Dados
A supervisão do tratamento adequado de dados está sob a responsabilidade da governança de dados e da assessoria jurídica.
Juntos, eles são obrigados a manter-se atualizados sobre as mudanças legais e reduzir o risco de impropriedade ética, garantindo
que os funcionários estejam cientes de suas obrigações. A Governança de Dados deve definir padrões e políticas e supervisionar
as práticas de manipulação de dados. Os funcionários devem esperar um tratamento justo, proteção contra possíveis violações e
não interferência em suas vidas pessoais. A Governança de Dados tem um requisito específico de supervisão para revisar planos e
decisões propostos por estudos de BI, analytics e Data Science.
A certificação Certified Data Management Professional (CDMP) da DAMA International exige que o profissional de
gerenciamento de dados assine um código de ética formal, incluindo a obrigação de lidar com dados de forma ética
para o bem da sociedade, além da organização que os emprega.
4. Obras Citadas/Recomendadas
BLAN, André. Manipulação e Análise de Dados. Oxford University Press, 2015. Imprimir. Fundamentos da Ciência Biomédica.
Council for Big Data, Ethics and Society (site) http://bit.ly/2sYAGAq.
Davis, Kord. Ética do Big Data: Equilibrando Risco e Inovação. O'Reilly Media, 2012. Impresso.
Autoridade Europeia para a Proteção de Dados (EDPS). Parecer 4/2015 “Rumo a uma nova ética digital: dados, dignidade e tecnologia”.
http://bit.ly/2sTFVlI.
Comissão Federal de Comércio, EUA (FTC). Relatório da Federal Trade Commission Protegendo a privacidade do consumidor em uma era de
mudanças rápidas. Março de 2012. http://bit.ly/2rVgTxQ e http://bit.ly/1SHOpRB.
REGULAMENTO RGPD (UE) 2016/679 DO PARLAMENTO EUROPEU E DO CONSELHO, de 27 de abril de 2016, relativo à proteção das pessoas
singulares no que diz respeito ao tratamento de dados pessoais e à livre circulação desses dados, e que revoga a Diretiva 95/46/ CE (Regulamento
Geral de Proteção de Dados).
Hasselbalch, Gry e Pernille Tranberg. Ética de dados: a nova vantagem competitiva. Publicar. 2016.
Huff, Darrel. Como mentir com estatísticas. Norton, 1954. Impresso.
Jensen, David. “Data Snooping, Dredging and Fishing: The Dark Side of Data Mining A SIGKDD99 Panel Report.” Explorações SIGKDD. ACM
SIGKDD, Vol. 1, Edição 2. Janeiro de 2000. http://bit.ly/2tNThMK.
Johnson, Deborah G. Ética do Computador. 4ª edição. Pearson, 2009. Impresso.
Kaunert, C. e S. Leonard, eds. Segurança Europeia, Terrorismo e Inteligência: Enfrentando Novos Desafios de Segurança na Europa.
Palgrave Macmillan, 2013. Impresso. Estudos Palgrave na Política da União Europeia.
Kim, Jae Kwan e Jun Shao. Métodos Estatísticos para Tratamento de Dados Incompletos. Chapman e Hall/CRC, 2013. Chapman e
Textos Hall/CRC em Ciência Estatística.
Lago, Pedro. Um guia para lidar com dados usando o Hadoop: Uma exploração do Hadoop, Hive, Pig, Sqoop e Flume. Pedro Lago, 2015.
Lewis, Colin e Dagmar Monett. Caixas pretas de IA e aprendizado de máquina: a necessidade de transparência e responsabilidade. KD Nuggets (site),
abril de 2017. http://bit.ly/2q3jXLr.
Lipschultz, Jeremy Harris. Comunicação em Mídias Sociais: Conceitos, Práticas, Dados, Lei e Ética. Routledge, 2014. Impresso.
Mayfield, MI sobre como lidar com os dados. Plataforma de Publicação Independente CreateSpace, 2015. Imprimir.
Mazurczyk, Wojciech et ai. Ocultação da Informação em Redes de Comunicação: Fundamentos, Mecanismos e Aplicações.
Wiley-IEEE Press, 2016. Imprimir. Série IEEE Press sobre Segurança de Redes de Informação e Comunicação.
Naes, T. e E. Risvik eds. Análise Multivariada de Dados em Ciência Sensorial. Volume 16. Elsevier Science, 1996. Impresso. Manipulação de Dados
em Ciência e Tecnologia (Livro 16).
Olivieri, Alejandro C. et ai, eds. Fundamentos e Aplicações Analíticas da Calibração Multi-way. Volume 29. Elsevier, 2015. Impresso. Manipulação
de Dados em Ciência e Tecnologia (Livro 29).
66 • DMBOK2
ProPublica (site). “Viés de máquina: injustiça algorítmica e as fórmulas que influenciam cada vez mais nossas vidas.” Maio de 2016 http://bit.ly/
2oYmNRu.
Reitor, Foster e Tom Fawcett. Data Science for Business: O que você precisa saber sobre mineração de dados e pensamento analítico de dados.
O'Reilly Media, 2013. Impresso.
Quinn, Michael J. Ética para a Era da Informação. 6ª edição. Pearson, 2014. Impresso.
Richards, Lyn. Manipulando Dados Qualitativos: Um Guia Prático. 3 Pap/Psc ed. SAGE Publications Ltd, 2014. Imprimir.
Thomas, Liisa M. Thomas sobre violação de dados: um guia prático para lidar com notificações de violação de dados em todo o mundo. LegalWorks,
2015. Impresso.
Tufte, Edward R. A Exibição Visual da Informação Quantitativa. 2ª edição. Graphics Pr., 2001. Impressão.
Universidade do Texas em Austin, Departamento de Matemática (site). Erros comuns no uso de estatísticas.
http://bit.ly/2tsWthM. Rede.
Departamento de Saúde e Serviços Humanos dos EUA. O Relatório Belmont. 1979. http://bit.ly/2tNjb3u (US-HSS, 2012).
Departamento de Segurança Interna dos EUA. “Aplicando Princípios à Pesquisa de Tecnologia da Informação e Comunicação: Um Companheiro
do Relatório Menlo do Departamento de Segurança Interna”. 3 de janeiro de 2012. http://bit.ly/2rV2mSR (US-DHS, 1979).
Witten, Ian H., Eibe Frank e Mark A. Hall. Mineração de dados: ferramentas e técnicas práticas de aprendizado de máquina. 3ª edição. Morgan
Kaufmann, 2011. Print. Série Morgan Kaufmann em Sistemas de Gerenciamento de Dados.
CAPÍTULO 3
Gestão de dados
Dados
Modelagem de dados
Qualidade dos dados
& Operações
Dados Dados
Metadados

Inteligência
& Mestre & Contente
Dados Gestão
Estrutura de gerenciamento de dados DAMA-DMBOK2
Copyright © 2017 por DAMA International
1. Introdução
D
Governança da ata (DG) é definida como o exercício de autoridade e controle (planejamento, monitoramento e
aplicação) sobre o gerenciamento de ativos de dados. Todas as organizações tomam decisões sobre dados,
independentemente de terem uma função formal de Governança de Dados. Aqueles que estabelecem um programa formal de
Governança de Dados exercem autoridade e controle com maior intencionalidade (Seiner, 2014). Essas organizações são mais capazes de
aumentar o valor que obtêm de seus ativos de dados.
A função de Governança de Dados orienta todas as outras funções de gerenciamento de dados. O objetivo da Governança de Dados é
garantir que os dados sejam gerenciados adequadamente, de acordo com as políticas e melhores práticas (Ladley, 2012). Embora a motivação
geral do gerenciamento de dados seja garantir que uma organização obtenha valor de seus dados, a Governança de Dados se concentra em como
67
68 • DMBOK2
são tomadas decisões sobre dados e como se espera que as pessoas e os processos se comportem em relação aos dados. O escopo e o foco de um
programa específico de governança de dados dependerão das necessidades organizacionais, mas a maioria dos programas inclui:
• Estratégia: Definir, comunicar e conduzir a execução da Estratégia de Dados e Governança de Dados
Estratégia
• Política: Definir e aplicar políticas relacionadas ao gerenciamento de dados e metadados, acesso, uso, segurança,
e qualidade
• Padrões e qualidade: Definindo e aplicando padrões de qualidade de dados e arquitetura de dados
• Supervisão: Fornecer observação prática, auditoria e correção nas principais áreas de qualidade, política e dados
gestão (muitas vezes referido como mordomia)
• Conformidade: Garantir que a organização possa atender aos requisitos de conformidade regulatória relacionados a dados
• Gerenciamento de problemas: Identificando, definindo, escalando e resolvendo problemas relacionados à segurança de dados,
acesso, qualidade de dados, conformidade regulatória, propriedade de dados, política, padrões, terminologia ou dados
procedimentos de governança
• Projetos de gerenciamento de dados: Patrocinando esforços para melhorar as práticas de gerenciamento de dados
• Avaliação de ativos de dados: definindo padrões e processos para definir consistentemente o valor comercial dos dados
ativos
Para atingir esses objetivos, um programa de governança de dados desenvolverá políticas e procedimentos, cultivará práticas de administração de
dados em vários níveis dentro da organização e se envolverá em esforços de gerenciamento de mudanças organizacionais que comunicam ativamente
à organização os benefícios de uma governança de dados aprimorada e os comportamentos necessários para gerenciar com sucesso os dados como
um ativo.
Para a maioria das organizações, a adoção formal da Governança de Dados requer o apoio do gerenciamento de mudanças organizacionais (consulte
o Capítulo 17), bem como o patrocínio de um executivo de nível C, como Diretor de Riscos, Diretor Financeiro ou Diretor de Dados.
A capacidade de criar e compartilhar dados e informações transformou nossas interações pessoais e econômicas.
As condições dinâmicas do mercado e uma maior conscientização dos dados como um diferencial competitivo estão levando as organizações a realinhar
as responsabilidades de gerenciamento de dados. Esse tipo de mudança é claro nos setores financeiro, comércio eletrônico, governo e varejo. As
organizações se esforçam cada vez mais para se tornarem orientadas por dados – considerando proativamente os requisitos de dados como parte do
desenvolvimento de estratégias, planejamento de programas e implementação de tecnologia. No entanto, fazer isso muitas vezes envolve desafios
culturais significativos. Além disso, como a cultura pode inviabilizar qualquer estratégia, os esforços de governança de dados precisam incluir um
componente de mudança cultural – novamente, apoiado por uma liderança forte.
Para se beneficiar dos dados como um ativo corporativo, a cultura organizacional deve aprender a valorizar os dados e as atividades de gerenciamento
de dados. Mesmo com a melhor estratégia de dados, os planos de governança e gerenciamento de dados não serão bem-sucedidos, a menos que a
organização aceite e gerencie as mudanças. Para muitas organizações, a mudança cultural é um grande desafio. Um dos princípios fundamentais da
gestão da mudança é que a mudança organizacional requer mudança individual (Hiatt e

GOVERNANÇA DE DADOS • 6 9
Crease, 2012). Quando a governança de dados e o gerenciamento de dados exigem mudanças comportamentais significativas, o
gerenciamento formal de mudanças é necessário para o sucesso.
Governança e administração de dados

Definição: O exercício de autoridade, controle e tomada de decisão compartilhada (planejamento, monitoramento e
execução) sobre o gerenciamento de ativos de dados.
Objetivos: 1. Permitir que uma organização gerencie seus dados como um ativo.
2. Definir, aprovar, comunicar e implementar princípios, políticas, procedimentos, métricas, ferramentas e responsabilidades para
3. Monitore e oriente a conformidade com as políticas, o uso de dados e as atividades de gerenciamento.
O negócio
Motoristas
Entradas: Atividades: Entregáveis: •

• Negócios 1. Definir Governança de Dados para o Estratégia de Governança de
Estratégias e Objetivos Organização (P) Dados • Estratégia de Dados •
• Estratégias de TI e 1.Desenvolver Estratégia de Governança de Negócios / Governança de Dados
Dados 2. Realizar Avaliação de Prontidão 3. Roteiro de Estratégia
Objetivos • Gerenciamento Realizar Descoberta e Alinhamento de Negócios 4. • Princípios de Dados, Dados
de Dados e Dados Desenvolver Pontos de Contato Organizacionais 2. Políticas de Governança,
Definir a Estratégia de Governança de Dados (P) Processos
Estratégias •
1. Definir a Estrutura Operacional de Governança • Estrutura Operacional • Roteiro
Organização
de Dados e
Políticas e
Padrões • 2. Desenvolva Metas, Princípios e Políticas 3. Estratégia de Implementação
Cultura Empresarial Subscreva Projetos de Gerenciamento de Dados 4. • Plano de Operações • Glossário
Avaliação • Envolva o Gerenciamento de Mudanças 5. Envolva- de Negócios • Governança de

se no Gerenciamento de Problemas 6. Avalie os Dados
Maturidade dos Dados
Requisitos de Conformidade Regulatória Tabela de desempenho
Avaliação
3. Implementar Governança de Dados (O) • Site de Governança de Dados •
• Práticas de TI •
1. Padrões e Procedimentos de Dados do Patrocinador Plano de Comunicação • Valor de
Regulatório
2. Desenvolver um Glossário Comercial 3. Coordenar Dados Reconhecido • Gerenciamento
Requisitos
com os Grupos de Arquitetura 4. Valorizar Ativos de de Dados em Amadurecimento
Dados do Patrocinador 4. Incorporar Governança Práticas
de Dados (C,O)

• Executivos de negócios • Equipe de Conformidade • • Órgãos de Governança de Dados
Comitês Diretores • CIO •
• Administradores de CDO / Chief Data Executivos de DM • Gerentes
• Gerentes de Projeto • Equipe
dados • Proprietários de dados de Mudanças • Dados de Conformidade • DM
• Especialistas no assunto • Avaliadores Comissários Corporativos Comunidades de Interesse • Equipe DM
• Administradores Executivos de Dados Arquitetos •
de maturidade • Reguladores •
Arquitetos empresariais • Dados de Coordenação Gerenciamento de Projetos • Gestão de Negócios • Grupos de
Comissários Escritório
Arquitetura • Organizações Parceiras
• Órgãos
Administradores de Dados Corporativos • Auditoria de Governança
• Órgãos •
de Governança de
Dados • Profissionais de Dados
Técnico
Motoristas
Métricas: •
Técnicas: •
Ferramentas: • Conformidade com políticas de dados
Mensagens Concisas • Lista
de Contatos Sites • Ferramentas do Glossário de regulatórias e internas. • Valor •
Negócios • Ferramentas de Fluxo de Eficácia
• Logotipo
Trabalho • Ferramentas de Gerenciamento de
Documentos • Scorecards de Governança de Dados • Sustentabilidade
Figura 14 Diagrama de contexto: governança de dados e administração

70 • DMBOK2
O impulsionador mais comum para a governança de dados geralmente é a conformidade regulatória, especialmente para setores altamente regulamentados,
como serviços financeiros e saúde. Responder à evolução da legislação requer processos rigorosos de governança de dados. A explosão em análises
avançadas e ciência de dados criou um impulso adicional

força.
Embora a conformidade ou a análise possam impulsionar a governança, muitas organizações voltam à governança de dados por meio de um programa de
gerenciamento de informações orientado por outras necessidades de negócios, como Master Data Management (MDM), por grandes problemas de dados ou
ambos. Um cenário típico: uma empresa precisa de melhores dados do cliente, opta por desenvolver o MDM do cliente e, em seguida, percebe que o MDM
bem-sucedido requer governança de dados.
A governança de dados não é um fim em si mesma. Ele precisa se alinhar diretamente com a estratégia organizacional. Quanto mais claramente ajudar a
resolver problemas organizacionais, maior a probabilidade de as pessoas mudarem comportamentos e adotarem práticas de governança.
Os drivers para a governança de dados geralmente se concentram na redução de riscos ou na melhoria dos processos.
• Redução de Risco
o Gerenciamento geral de riscos: Supervisão dos riscos que os dados representam para finanças ou reputação, incluindo
resposta a questões legais (E-Discovery) e regulatórias.
o Segurança de dados: Proteção de ativos de dados por meio de controles de disponibilidade, usabilidade, integridade,
consistência, auditabilidade e segurança dos dados.
o Privacidade: Controle de informações privadas/confidenciais/de identificação pessoal (PII) por meio de política
e monitoramento de conformidade.
• Aprimoramento de Processos
o Conformidade regulatória: A capacidade de responder de forma eficiente e consistente às
requisitos.
o Melhoria da qualidade dos dados: A capacidade de contribuir para melhorar o desempenho dos negócios
tornando os dados mais confiáveis.
o Gestão de Metadados: Estabelecimento de um glossário de negócios para definir e localizar dados no
organização; garantindo que a ampla gama de outros Metadados seja gerenciada e disponibilizada ao
organização.
o Eficiência em projetos de desenvolvimento: melhorias SDLC para abordar questões e oportunidades em
gerenciamento de dados em toda a organização, incluindo gerenciamento de dívida técnica específica de dados
por meio da governança do ciclo de vida dos dados.
o Gestão de fornecedores: Controle de contratos que tratam de dados, como armazenamento em nuvem,
compra de dados, venda de dados como um produto e operações de terceirização de dados.
É essencial esclarecer os drivers de negócios específicos para a governança de dados dentro de uma organização e alinhá-los com a estratégia geral de
negócios. Concentrar-se na 'organização DG' muitas vezes afasta a liderança que percebe uma sobrecarga extra sem benefícios aparentes. A sensibilidade à
cultura organizacional é necessária para determinar a linguagem correta, o modelo operacional e as funções do programa. No momento da redação do
DMBOK2, o termo organização está sendo substituído por termos como modelo operacional ou estrutura operacional.
Embora as pessoas às vezes afirmem que é difícil entender o que é governança de dados, a governança em si é um conceito comum. Em vez de inventar
novas abordagens, os profissionais de gerenciamento de dados podem aplicar os conceitos e

princípios de outros tipos de governança para a governança de dados. Uma analogia comum é igualar a governança de dados à auditoria e à
contabilidade. Auditores e controladores definem as regras para o gerenciamento de ativos financeiros. Os profissionais de governança de dados
definem regras para gerenciar ativos de dados. Outras áreas cumprem essas regras.
A governança de dados não é uma coisa única. A governança de dados requer um programa contínuo focado em garantir que uma organização
obtenha valor de seus dados e reduza os riscos relacionados aos dados. Uma equipe de Governança de Dados pode ser uma organização virtual
ou uma organização de linha com responsabilidades específicas. Para serem eficazes, as funções e atividades dentro da governança de dados
precisam ser bem compreendidas. Eles devem ser construídos em torno de uma estrutura operacional que funcione bem na organização. Um
programa de governança de dados deve levar em consideração questões organizacionais e culturais distintas e os desafios e oportunidades
específicos de gerenciamento de dados dentro da organização. (Consulte os Capítulos 1 e 16.)
A governança de dados é separada da governança de TI. A governança de TI toma decisões sobre investimentos em TI, portfólio de aplicativos de
TI e portfólio de projetos de TI – em outras palavras, hardware, software e arquitetura técnica geral. A governança de TI alinha as estratégias e
investimentos de TI com as metas e estratégias da empresa. A estrutura COBIT (Control Objectives for Information and Related Technology)
fornece padrões para governança de TI, mas apenas uma pequena parte da estrutura COBIT aborda o gerenciamento de dados e informações.
Alguns tópicos críticos, como a conformidade com Sarbanes-Oxley (EUA), abrangem as preocupações de governança corporativa, governança de
TI e governança de dados. Em contraste, a Governança de Dados se concentra exclusivamente no gerenciamento de dados
ativos e de dados como um ativo.
1.2 Objetivos e Princípios
O objetivo da Governança de Dados é permitir que uma organização gerencie dados como um ativo. A DG fornece os princípios, políticas,
processos, estrutura, métricas e supervisão para gerenciar dados como um ativo e orientar as atividades de gerenciamento de dados em todos os
níveis. Para atingir esse objetivo geral, um programa de GD deve ser:
• Sustentável: O programa DG precisa ser 'pegajoso'. A DG não é um projeto com fim definido; é um
processo contínuo que requer comprometimento organizacional. A DG necessita de mudanças na forma como os dados são
gerenciados e usados. Isso nem sempre significa novas organizações massivas e convulsões. Isso significa
gerenciar a mudança de forma sustentável além da implementação inicial de qualquer governança de dados
componente. A governança de dados sustentável depende da liderança empresarial, patrocínio e propriedade.
• Incorporado: DG não é um processo complementar. As atividades da DG precisam ser incorporadas aos métodos de desenvolvimento
para software, uso de dados para análise, gerenciamento de dados mestre e gerenciamento de risco.
• Medido: GD bem feito tem impacto financeiro positivo, mas demonstrar esse impacto requer
entender o ponto de partida e planejar melhorias mensuráveis.
A implementação de um programa de GD requer compromisso com a mudança. Os princípios a seguir, desenvolvidos desde o início dos anos
2000, podem ajudar a estabelecer uma base sólida para a governança de dados.26
26 O Instituto de Governança de Dados. http://bit.ly/1ef0tnb.

72 • DMBOK2
• Liderança e estratégia: uma governança de dados bem-sucedida começa com uma liderança visionária e comprometida.
As atividades de gerenciamento de dados são guiadas por uma estratégia de dados que é conduzida pelos negócios da empresa
estratégia.
• Orientado aos negócios: Governança de dados é um programa de negócios e, como tal, deve reger as decisões de TI relacionadas
aos dados tanto quanto governa a interação de negócios com os dados.
• Responsabilidade compartilhada: em todas as áreas de conhecimento de gerenciamento de dados, a governança de dados é um
responsabilidade entre administradores de dados de negócios e profissionais de gerenciamento de dados técnicos.
• Multicamadas: a governança de dados ocorre nos níveis corporativo e local e, muitas vezes, nos níveis de
entre.
• Baseado em estrutura: como as atividades de governança de dados exigem coordenação entre áreas funcionais, o
O programa DG deve estabelecer uma estrutura operacional que defina responsabilidades e interações.
• Baseado em princípios: Os princípios orientadores são a base das atividades do GD e, especialmente, da política do GD.
Muitas vezes, as organizações desenvolvem políticas sem princípios formais – elas estão tentando resolver problemas particulares
problemas. Às vezes, os princípios podem sofrer engenharia reversa da política. No entanto, é melhor articular uma
conjunto básico de princípios e melhores práticas como parte do trabalho de políticas. A referência a princípios pode mitigar
resistência potencial. Princípios orientadores adicionais surgirão ao longo do tempo dentro de uma organização. Publicar
em um ambiente interno compartilhado junto com outros artefatos de governança de dados.
1.3 Conceitos Essenciais
Assim como um auditor controla os processos financeiros, mas na verdade não executa o gerenciamento financeiro, a governança de dados garante que
os dados sejam gerenciados adequadamente sem executar diretamente o gerenciamento de dados (consulte a Figura 15). A governança de dados
representa uma separação inerente de deveres entre supervisão e execução.
Dados,
Em formação, Gestão de dados
Gestão de dados
E Gerenciando dados
Garantir que os dados sejam gerenciados
Contente para atingir metas
Ciclos de vida
Supervisão Execução
Figura 15 Governança de Dados e Gerenciamento de Dados

1.3.1 Organização centrada em dados
Uma organização centrada em dados valoriza os dados como um ativo e gerencia os dados em todas as fases de seu ciclo de vida, incluindo
desenvolvimento de projetos e operações contínuas. Para se tornar centrada em dados, uma organização deve mudar a maneira como traduz a
estratégia em ação. Os dados não são mais tratados como um subproduto de processos e aplicativos. Garantir que os dados sejam de alta
qualidade é um objetivo dos processos de negócios. À medida que as organizações se esforçam para tomar decisões com base em insights
obtidos a partir de análises, o gerenciamento eficaz de dados se torna uma prioridade muito alta.
As pessoas tendem a confundir dados e tecnologia da informação. Para se tornarem centradas em dados, as organizações precisam pensar de
forma diferente e reconhecer que gerenciar dados é diferente de gerenciar TI. Essa mudança não é fácil. A cultura existente, com sua política
interna, ambiguidade sobre propriedade, concorrência orçamentária e sistemas legados, pode ser um grande obstáculo para estabelecer uma
visão corporativa de governança e gerenciamento de dados.
Embora cada organização precise desenvolver seus próprios princípios, aquelas que buscam obter mais valor de seus dados provavelmente
compartilharão o seguinte:
• Os dados devem ser gerenciados como um ativo corporativo
• As melhores práticas de gerenciamento de dados devem ser incentivadas em toda a organização
• A estratégia de dados corporativos deve estar diretamente alinhada com a estratégia geral de negócios
• Os processos de gerenciamento de dados devem ser continuamente aprimorados
1.3.2 Organização de Governança de Dados
A palavra central em governança é governar. A governança de dados pode ser entendida em termos de governança política. Inclui funções do tipo
legislativo (definindo políticas, padrões e a Arquitetura de Dados Corporativos), funções do tipo judicial (gerenciamento e encaminhamento de
problemas) e funções executivas (proteção e atendimento, responsabilidades administrativas). Para gerenciar melhor os riscos, a maioria das
organizações adota uma forma representativa de governança de dados, para que

todas as partes interessadas podem ser ouvidas.
Cada organização deve adotar um modelo de governança que apoie sua estratégia de negócios e tenha probabilidade de sucesso dentro de seu
próprio contexto cultural. As organizações também devem estar preparadas para evoluir esse modelo para enfrentar novos desafios.
Os modelos diferem em relação à sua estrutura organizacional, nível de formalidade e abordagem à tomada de decisão.
Alguns modelos são organizados centralmente, enquanto outros são distribuídos.
As organizações de governança de dados também podem ter várias camadas para abordar as preocupações em diferentes níveis dentro de uma
empresa – local, divisional e em toda a empresa. O trabalho de governança geralmente é dividido entre vários comitês, cada um com um propósito
e nível de supervisão diferente dos demais.
A Figura 16 representa um modelo genérico de governança de dados, com atividades em diferentes níveis dentro da organização (eixo vertical),
bem como a separação das responsabilidades de governança dentro das funções organizacionais e entre áreas técnicas (TI) e de negócios. A
Tabela 4 descreve os comitês típicos que podem ser estabelecidos dentro de uma estrutura operacional de governança de dados. Observe que
este não é um organograma. O diagrama explica como as diversas áreas trabalham em conjunto para realizar a GD, em linha com a já mencionada
tendência de desenfatizar o termo organização.

74 • DMBOK2
Visão Legislativa e Judicial Vista Executiva

Faça as coisas certas Faça as coisas certas
Diretor de Dados Diretor de Informações
ISTO
Programa
Orientação de Governança de Dados Organizações
Comitê Gestão
Gestão de dados
Executivos
Dados Dados
Dados Gabinete de Governança
Gestão Programa
Governança (DGO) Serviços Direção
Conselho Administrador-chefe de dados
Comitês
(SMS)
(DGC) Dados Executivos
Comissários Arquitetos de dados
Dados de coordenação Dados de coordenação

Comissários + Mordomos Projeto
Gestão
Analistas de dados Analistas de dados Escritório
Proprietários de dados Técnico

Administradores de
O negócio dados ou PMEs
Administradores de
Projetos
dados ou PMEs
Figura 16 Partes da Organização de Governança de Dados
Tabela 4 Comitês / Órgãos Típicos de Governança de Dados
Gestão de dados Descrição
Corpo
Gestão de dados A organização principal e de maior autoridade para governança de dados em uma organização, responsável
pela supervisão, suporte e financiamento das atividades de governança de dados. Consiste em um grupo
Comitê de direção
multifuncional de executivos seniores.
Normalmente libera financiamento para governança de dados e atividades patrocinadas por governança de dados
conforme recomendado pelo DGC e CDO. Este comitê pode, por sua vez, ter supervisão de fundos de nível
superior ou comitês de direção baseados em iniciativas.
Gestão de dados Gerencia iniciativas de governança de dados (por exemplo, desenvolvimento de políticas ou métricas), problemas
e escalações. Composto por executivo de acordo com o modelo operacional utilizado. Consulte a Figura 17.
Conselho (DGC)
Gestão de dados Foco contínuo em definições de dados de nível empresarial e padrões de gerenciamento de dados em todas
as áreas de conhecimento DAMA-DMBOK. Consiste em funções de coordenação que são rotuladas como
Escritório (DGO)
administradores ou guardiões de dados e proprietários de dados.
Comunidades de interesse focadas em uma ou mais áreas temáticas ou projetos específicos,

Administração de dados
Equipes colaborando ou consultando equipes de projeto sobre definições de dados e padrões de gerenciamento de
dados relacionados ao foco. Consiste em administradores de dados técnicos e de negócios e analistas de
dados.
Dados locais Grandes organizações podem ter conselhos de governança de dados divisionais ou departamentais
Governança trabalhando sob os auspícios de um Enterprise DGC. Organizações menores devem tentar evitar tal
Comitê complexidade.
1.3.3 Tipos de Modelo Operacional de Governança de Dados
Em um modelo centralizado, uma organização de Governança de Dados supervisiona todas as atividades em todas as áreas. Em
um modelo replicado, o mesmo modelo operacional e padrões de GD são adotados por cada unidade de negócio. Em um modelo
federado, uma organização de Governança de Dados coordena com várias Unidades de Negócios para manter definições e padrões
consistentes. (Consulte a Figura 17 e o Capítulo 16.)
Centralizado
Gestão de dados
Unidade de negócio
Região Região Região Região
Sujeito Sujeito Sujeito Sujeito Sujeito Sujeito

Área Área Área Área Área Área
UMA B C D E F
Replicado
Gestão de dados Gestão de dados Gestão de dados
Unidade de Negócios 1 Unidade de Negócios 2 Unidade de Negócios 3
Sujeito Sujeito Sujeito Sujeito Sujeito Sujeito Sujeito Sujeito Sujeito

Área Área Área Área Área Área Área Área Área
UMA B C UMA D E B E F
Federado
Gestão de dados
Unidade de Negócios 1 Unidade de Negócios 2 Unidade de Negócios 3
Sujeito Sujeito Sujeito Sujeito Sujeito Sujeito Sujeito Sujeito Sujeito

Área Área Área Área Área Área Área Área Área
UMA B C UMA D E B E F
Figura 17 Exemplos de Estrutura Operacional da DG Corporativa 27
1.3.4 Administração de Dados
Data Stewardship é o rótulo mais comum para descrever a responsabilidade e a responsabilidade pelos dados e processos que
garantem o controle e o uso efetivos dos ativos de dados. A administração pode ser formalizada por meio de cargos e
27 Adaptado de Ladley (2012).

76 • DMBOK2
descrições, ou pode ser uma função menos formal conduzida por pessoas que tentam ajudar uma organização a obter valor de seus dados. Muitas vezes, termos
como guardião ou administrador são sinônimos para aqueles que exercem funções semelhantes a mordomos.
O foco das atividades de administração difere de organização para organização, dependendo da estratégia organizacional, cultura, problemas que uma organização
está tentando resolver, seu nível de maturidade em gerenciamento de dados e a formalidade de seu programa de administração. No entanto, na maioria dos casos,
as atividades de administração de dados se concentrarão em alguns, se não todos, dos seguintes itens:
• Criação e gerenciamento de metadados principais: Definição e gerenciamento de terminologia de negócios, dados válidos
valores e outros metadados críticos. Os Stewards são frequentemente responsáveis pelos negócios de uma organização
Glossário, que se torna o sistema de registro de termos comerciais relacionados a dados.
• Documentação de regras e padrões: Definição/documentação de regras de negócios, padrões de dados e dados
regras de qualidade. As expectativas usadas para definir dados de alta qualidade são frequentemente formuladas em termos de regras enraizadas em
os processos de negócios que criam ou consomem dados. Os comissários ajudam a trazer à tona essas regras para garantir
que haja consenso sobre eles dentro da organização e que sejam usados de forma consistente.
• Gerenciando problemas de qualidade de dados: os administradores geralmente estão envolvidos na identificação e resolução de dados
questões relacionadas ou para facilitar o processo de resolução.
• Execução de atividades de governança de dados operacionais: Stewards são responsáveis por garantir que, dia a dia
dia e projeto a projeto, as políticas e iniciativas de governança de dados são cumpridas. Eles devem influenciar
decisões para garantir que os dados sejam gerenciados de forma a apoiar os objetivos gerais da organização.
1.3.5 Tipos de Administradores de Dados
Um mordomo é uma pessoa cujo trabalho é administrar a propriedade de outra pessoa. Os Data Stewards gerenciam os ativos de dados em nome de outros e no
melhor interesse da organização (McGilvray, 2008). Os administradores de dados representam os interesses de todas as partes interessadas e devem adotar uma
perspectiva corporativa para garantir que os dados corporativos sejam de alta qualidade e possam ser usados com eficiência. Os administradores de dados eficazes
são responsáveis pelas atividades de governança de dados e têm uma parte de seu tempo dedicada a essas atividades.
Dependendo da complexidade da organização e dos objetivos de seu programa de DG, os Data Stewards formalmente nomeados podem ser diferenciados por seu
lugar dentro de uma organização, pelo foco de seu trabalho ou por ambos. Por exemplo:
• Os Chief Data Stewards podem presidir os órgãos de governança de dados no lugar do CDO ou podem atuar como um CDO em um
organização de governança de dados virtual (baseada em comitê) ou distribuída. Podem também ser Executivos
Patrocinadores.
• Os Administradores Executivos de Dados são gerentes seniores que atuam em um Conselho de Governança de Dados.
• Os Administradores de Dados Corporativos supervisionam um domínio de dados em todas as funções de negócios.

• Os Administradores de Dados Corporativos são profissionais de negócios, especialistas no assunto mais frequentemente reconhecidos,
responsável por um subconjunto de dados. Eles trabalham com as partes interessadas para definir e controlar os dados.
• Um Proprietário de Dados é um Administrador de Dados de negócios, que tem autoridade de aprovação para decisões sobre dados dentro
seu domínio.
• Os Administradores de Dados Técnicos são profissionais de TI que operam em uma das Áreas de Conhecimento, como
Especialistas em integração de dados, administradores de banco de dados, especialistas em inteligência de negócios, qualidade de dados
Analistas ou Administradores de Metadados.
• Coordenar os Data Stewards liderar e representar as equipes de negócios e técnicos dos Data Stewards em
discussões entre as equipes e com os Data Stewards executivos. A coordenação dos Data Stewards é particularmente
importante em grandes organizações.
A primeira edição do DAMA-DMBOK afirmava que “os melhores Data Stewards são frequentemente encontrados, não feitos” (DAMA, 2009). Essa afirmação
reconhece que, na maioria das organizações, existem pessoas que administram os dados, mesmo na ausência de um programa formal de governança de
dados. Esses indivíduos já estão envolvidos em ajudar a organização a reduzir os riscos relacionados a dados e obter mais valor de seus dados. A
formalização de suas responsabilidades de administração reconhece o trabalho que estão fazendo e permite que tenham mais sucesso e contribuam mais.
Dito tudo isso, os Data Stewards podem ser 'feitos'; as pessoas podem ser treinadas para serem Data Stewards. E as pessoas que já estão administrando
dados podem desenvolver suas habilidades e conhecimentos para que se tornem melhores no trabalho de administração (Plotkin, 2014).
1.3.6 Políticas de Dados
As políticas de dados são diretivas que codificam princípios e intenções de gerenciamento em regras fundamentais que regem a criação, aquisição,
integridade, segurança, qualidade e uso de dados e informações.
As políticas de dados são globais. Eles suportam padrões de dados, bem como comportamentos esperados relacionados aos principais aspectos do
gerenciamento e uso de dados. As políticas de dados variam muito entre as organizações. As políticas de dados descrevem o 'o que' da governança de dados
(o que fazer e o que não fazer), enquanto os padrões e procedimentos descrevem 'como' fazer a governança de dados.
Deve haver relativamente poucas políticas de dados, e elas devem ser declaradas de forma breve e direta.
1.3.7 Avaliação de Ativos de Dados
A avaliação de ativos de dados é o processo de entender e calcular o valor econômico dos dados para uma organização.
Como dados, informações e até mesmo Business Intelligence são conceitos abstratos, as pessoas têm dificuldade em alinhá-los ao impacto econômico. A
chave para entender o valor de um item não fungível (como dados) é entender como ele é usado e o valor trazido pelo seu uso (Redman, 1996). Ao contrário
de muitos outros ativos (por exemplo, dinheiro, equipamento físico), os conjuntos de dados não são intercambiáveis (fungíveis). Os dados de clientes de uma
organização diferem dos de outra organização em aspectos importantes; não apenas os próprios clientes, mas os dados associados a eles (histórico de
compras, preferências, etc.) ser um diferencial competitivo.

78 • DMBOK2
A maioria das fases do ciclo de vida dos dados envolve custos (incluindo aquisição, armazenamento, administração e descarte de dados).
Os dados só trazem valor quando são usados. Quando usados, os dados também geram custos relacionados ao gerenciamento de riscos. Portanto,
o valor vem quando o benefício econômico do uso de dados supera os custos de aquisição e armazenamento, bem como o gerenciamento de riscos
relacionados ao uso.
Algumas outras maneiras de medir o valor incluem:
• Custo de substituição: O custo de substituição ou recuperação de dados perdidos em um desastre ou violação de dados, incluindo o
transações, domínios, catálogos, documentos e métricas dentro de uma organização.
• Valor de mercado: O valor como ativo comercial no momento de uma fusão ou aquisição.
• Oportunidades identificadas: o valor da renda que pode ser obtida com as oportunidades identificadas nos dados
(em Business Intelligence), usando os dados para transações ou vendendo os dados.
• Venda de dados: algumas organizações empacotam dados como um produto ou vendem insights obtidos com seus dados.
• Custo de risco: uma avaliação com base em possíveis penalidades, custos de remediação e despesas de litígio, derivadas
de risco legal ou regulatório de:
o Ausência de dados que devem estar presentes.
o A presença de dados que não deveriam estar presentes (por exemplo, dados inesperados encontrados durante
descoberta; dados que devem ser eliminados, mas não foram eliminados).
o Dados incorretos, causando danos aos clientes, finanças da empresa e reputação, além
aos custos acima.
o A redução do risco e do custo do risco é compensada pelos custos de intervenção operacional para melhorar e
certificar dados
Para descrever o conceito de valor do ativo de informação, pode-se traduzir Princípios Contábeis Geralmente Aceitos em Princípios de Informação
Geralmente Aceitos28 (ver Tabela 5).
Tabela 5 Princípios para Contabilidade de Ativos de Dados
Princípio Descrição
Uma organização deve identificar os indivíduos que são responsáveis por dados e conteúdo de todos os tipos.
Responsabilidade
Princípio
Dados e conteúdo de todos os tipos são ativos e possuem características de outros ativos. Eles devem ser
Princípio do Ativo
administrados, garantidos e contabilizados como outros ativos materiais ou financeiros.
A exatidão dos dados e do conteúdo está sujeita a auditoria periódica por um órgão independente.
Princípio de Auditoria
Se um risco for conhecido, ele deve ser relatado. Se um risco for possível, ele deve ser confirmado. Os riscos de dados
Due diligence
incluem riscos relacionados a práticas inadequadas de gerenciamento de dados.
Princípio
Dados e conteúdo são críticos para operações e gerenciamento de negócios contínuos e bem-sucedidos (ou seja,
Preocupação em andamento
eles não são vistos como meios temporários para alcançar resultados ou meramente como um negócio por produto).
Princípio
28 Adaptado de Ladley (2010). Consulte as págs. 108-09, Princípios de informação geralmente aceitos.
Princípio Descrição
Valorize os dados como um ativo em um nível que faça mais sentido ou seja o mais fácil de medir.
Nível de Avaliação
Princípio
Existe uma responsabilidade financeira relacionada a dados ou conteúdo com base no uso indevido regulatório
Princípio de Responsabilidade
e ético ou má gestão.
O significado, a precisão e o ciclo de vida dos dados e do conteúdo podem afetar a situação financeira da
Princípio da Qualidade
organização.
Existe risco associado a dados e conteúdo. Este risco deve ser formalmente reconhecido, seja como passivo ou
Princípio de Risco
por meio de custos incorridos para gerenciar e reduzir o risco inerente.
Há valor nos dados e no conteúdo, com base nas formas como são usados para atingir os
Princípio de Valor
objetivos de uma organização, sua comercialização intrínseca e/ou sua contribuição para a avaliação do
ágio (balanço) da organização. O valor da informação reflete sua contribuição para a organização
compensada pelo custo de manutenção e movimentação.
2. Atividades
2.1 Definir Governança de Dados para a Organização
Os esforços de governança de dados devem apoiar a estratégia e os objetivos de negócios. A estratégia e os objetivos de negócios de uma
organização informam tanto a estratégia de dados corporativos quanto como as atividades de governança de dados e gerenciamento de dados
precisam ser operacionalizadas na organização.
A governança de dados permite a responsabilidade compartilhada por decisões relacionadas a dados. As atividades de governança de dados
cruzam os limites organizacionais e do sistema para dar suporte a uma visão integrada dos dados. A governança de dados bem-sucedida requer
uma compreensão clara do que está sendo governado e quem está sendo governado, bem como quem está governando.
A governança de dados é mais eficaz quando é um esforço corporativo, em vez de isolada em uma área funcional específica.
Definir o escopo da governança de dados em uma empresa geralmente envolve definir o que significa empresa . A governança de dados, por
sua vez, governa essa empresa definida.
2.2 Realizar avaliação de prontidão
Avaliações que descrevem o estado atual das capacidades de gerenciamento de informações de uma organização, maturidade e eficácia são
cruciais para o planejamento de um programa de GD. Como podem ser usadas para medir a eficácia de um programa, as avaliações também
são valiosas na gestão e sustentação de um programa de GD.
As avaliações típicas incluem:

80 • DMBOK2
• Maturidade em gerenciamento de dados: Entenda o que a organização faz com os dados; medir seus dados atuais
capacidades e capacidades de gestão. O foco está nas impressões que o pessoal de negócios tem sobre como
bem a empresa gerencia os dados e usa os dados a seu favor, bem como em critérios objetivos, como uso
de ferramentas, níveis de relatórios, etc. (Ver Capítulo 15.)
• Capacidade de mudança: Como a GD exige mudança de comportamento, é importante medir a capacidade de
organização para mudar os comportamentos necessários para a adaptação da GD. Secundariamente, esta atividade ajudará a identificar
pontos de resistência potenciais. Frequentemente, a GD requer uma gestão formal de mudanças organizacionais. Ao avaliar o
capacidade de mudar, o processo de gerenciamento de mudanças avaliará a estrutura organizacional existente,
percepções de cultura e o próprio processo de gestão de mudanças (Hiatt e Creasey, 2012). (Consulte o Capítulo
17.)
• Prontidão colaborativa: Esta avaliação caracteriza a capacidade da organização de colaborar na
gerenciamento e uso de dados. Como a administração por definição atravessa áreas funcionais, é colaborativa na
natureza. Se uma organização não souber colaborar, a cultura será um obstáculo para a administração.
Nunca assuma que uma organização sabe como colaborar. Quando feito em conjunto com a capacidade de mudança
esta avaliação oferece uma visão sobre a capacidade cultural para a implementação da DG.
• Alinhamento de negócios: às vezes incluído na capacidade de mudança, uma avaliação de alinhamento de negócios
examina quão bem a organização alinha os usos de dados com a estratégia de negócios. Muitas vezes é surpreendente
descubra como as atividades relacionadas a dados podem ser ad hoc.
2.3 Realizar Descoberta e Alinhamento de Negócios
Um programa de GD deve contribuir para a organização identificando e entregando benefícios específicos (por exemplo, reduzir multas pagas aos
reguladores). A atividade de descoberta identificará e avaliará a eficácia das políticas e diretrizes existentes – quais riscos eles abordam, quais
comportamentos eles incentivam e quão bem eles foram implementados.
A descoberta também pode identificar oportunidades para a DG melhorar a utilidade dos dados e do conteúdo. Alinhamento de negócios
atribui benefícios comerciais aos elementos do programa DG.
A análise de qualidade de dados (DQ) faz parte da descoberta. A avaliação DQ fornecerá informações sobre problemas e obstáculos existentes, bem
como o impacto e os riscos associados a dados de baixa qualidade. A avaliação DQ pode identificar processos de negócios que estão em risco se
executados usando dados de baixa qualidade, bem como os benefícios financeiros e outros da criação de um programa de qualidade de dados como
parte dos esforços de governança de dados. (Consulte o Capítulo 13.)
A avaliação das práticas de gerenciamento de dados é outro aspecto fundamental do processo de descoberta de governança de dados. Por exemplo, isso
pode significar identificar usuários avançados para criar uma lista inicial de agentes em potencial para a atividade contínua do DG.
Derivar uma lista de requisitos de DG das atividades de descoberta e alinhamento. Por exemplo, se os riscos regulatórios gerarem uma preocupação
financeira para o negócio, especifique as atividades da DG que apoiam o gerenciamento de riscos. Esses requisitos orientarão a estratégia e as táticas da
DG.
2.4 Desenvolver pontos de contato organizacionais
Parte do alinhamento inclui o desenvolvimento de pontos de contato organizacionais para o trabalho de Governança de Dados. A Figura 18 ilustra
exemplos de pontos de contato que suportam o alinhamento e a coesão de uma abordagem de governança de dados corporativos e gerenciamento de
dados em áreas fora da autoridade direta do diretor de dados.
• Aquisição e Contratos: O CDO trabalha com a Gestão de Fornecedores/Parceiros ou Aquisição para
desenvolver e aplicar a linguagem contratual padrão em relação aos contratos de gerenciamento de dados. Estes podem incluir
Data-as-a-Service (DaaS) e aquisições relacionadas à nuvem, outros acordos de terceirização, terceiros
esforços de desenvolvimento ou acordos de aquisição/licenciamento de conteúdo e possivelmente aquisições de ferramentas de TI centradas em dados
e atualizações.
• Orçamento e Financiamento: Se o CDO não estiver diretamente no controle de todos os orçamentos relacionados à aquisição de dados, então o
escritório pode ser um ponto focal para evitar esforços duplicados e garantir a otimização dos dados adquiridos
ativos.
• Conformidade Regulatória: O CDO entende e trabalha dentro dos requisitos locais, nacionais e
ambientes regulatórios internacionais e como eles impactam a organização e seu gerenciamento de dados
Atividades. O monitoramento contínuo é realizado para identificar e rastrear impactos novos e potenciais e
requisitos.
• SDLC / estrutura de desenvolvimento: O programa de governança de dados identifica pontos de controle onde
políticas, processos e padrões corporativos podem ser desenvolvidos no desenvolvimento de sistemas ou aplicativos
ciclos de vida.
Os pontos de contato que o CDO influencia suportam a coesão da organização no gerenciamento de seus dados, aumentando assim sua agilidade no
uso de seus dados. Em essência, esta é uma visão de como a GD será percebida pela organização.
TODO
Orçamento & Compras

Financiamento & Contratos
DG
Políticas, Gerenciamento Regulatório
Procedimentos, e Observância
& Padrões
Supervisão
SDLC e Ativo EAI Qualidade dos dados

Controle Ágil Otimização Programas
Pontos
Figura 18 Pontos de contato organizacionais do CDO

82 • DMBOK2
2.5 Desenvolver Estratégia de Governança de Dados
Uma estratégia de governança de dados define o escopo e a abordagem dos esforços de governança. A estratégia da DG deve ser definida de
forma abrangente e articulada em relação à estratégia empresarial global, bem como à gestão de dados e às estratégias de TI. Deve ser
implementado iterativamente à medida que as peças são desenvolvidas e aprovadas. O conteúdo específico será adaptado a cada organização,
mas as entregas incluem:
• Carta: Identifica os direcionadores de negócios, visão, missão e princípios para governança de dados, incluindo
avaliação de prontidão, descoberta de processos internos e questões atuais ou critérios de sucesso
• Estrutura operacional e responsabilidades: define a estrutura e a responsabilidade pela governança de dados

Atividades
• Roteiro de implementação: Prazos para implantação de políticas e diretrizes, glossário de negócios,
arquitetura, avaliação de ativos, padrões e procedimentos, mudanças esperadas para negócios e tecnologia
processos e entregas para apoiar as atividades de auditoria e conformidade regulatória
• Plano para o sucesso operacional: Descrevendo um estado alvo de atividades de governança de dados sustentáveis
2.6 Definir o quadro operacional da DG
Embora seja fácil desenvolver uma definição básica de GD, criar um modelo operacional que uma organização adotará pode ser difícil. Considere
estas áreas ao construir o modelo operacional de uma organização:
• Valor dos dados para a organização: Se uma organização vende dados, obviamente a DG tem um grande negócio
impacto. As organizações que usam dados como uma mercadoria crucial (por exemplo, Facebook, Amazon) precisarão de um
modelo operacional que reflete o papel dos dados. Para organizações onde os dados são um lubrificante operacional, o
forma de DG será menos intensa.
• Modelo de negócios: Negócios descentralizados versus centralizados, locais versus internacionais, etc. são fatores que
influenciar como os negócios ocorrem e, portanto, como o modelo operacional da GD é definido. Links com específicos
A estratégia de TI, a arquitetura de dados e as funções de integração de aplicativos devem ser refletidas no objetivo
projeto da estrutura operacional (conforme Figura 16).
• Fatores culturais: como aceitação da disciplina e adaptabilidade à mudança. Algumas organizações irão
resistir à imposição de governança por políticas e princípios. A estratégia de governança precisará defender
um modelo operacional que se ajuste à cultura organizacional, enquanto ainda progride na mudança.
• Impacto da regulamentação: organizações altamente regulamentadas terão uma mentalidade e um modelo operacional diferentes
da DG do que os menos regulamentados. Pode haver links para o grupo de Gerenciamento de Risco ou Jurídico também.
As camadas de governança de dados geralmente fazem parte da solução. Isso significa determinar onde deve residir a responsabilidade pelas
atividades de administração, quem possui os dados, etc. O modelo operacional também define a interação entre a organização de governança e as
pessoas responsáveis por projetos ou iniciativas de gerenciamento de dados, o envolvimento de atividades de gerenciamento de mudanças para
introduzir esse novo programa e o modelo para resolução de gerenciamento de problemas

caminhos através da governança. A Figura 19 mostra um exemplo de uma estrutura operacional. O exemplo é ilustrativo.
Esse tipo de artefato deve ser customizado para atender às necessidades de uma organização específica.
Visão e Estratégia
Conselho Executivo (COO, CFO)
Supervisão
Escalação
Cadeiras giratórias Supervisão de Governança de Dados Corporativos Resolução
Supervisão do Programa
Desenvolvimento de políticas
Conselho de Governança de Dados (DGC) Alinhamento

Sequenciamento
Política Problemas
Operações de Governança de Dados (DGO)
Dados de domínio
Responsabilidade
Governança Consumidor Parceiro produtos
Ciclos de vida de dados
Dados
Fóruns ERP Análise Responsabilidade
Armazém
Figura 19 Um exemplo de uma estrutura operacional
2.7 Desenvolver Metas, Princípios e Políticas
O desenvolvimento de metas, princípios e políticas derivados da Estratégia de Governança de Dados guiará a organização para o estado futuro
desejado.
Metas, princípios e políticas são normalmente elaborados por profissionais de gerenciamento de dados, equipe de políticas de negócios ou uma
combinação deles, sob os auspícios da governança de dados. Em seguida, os administradores de dados e o gerenciamento os revisam e os
refinam. Em seguida, o Conselho de Governança de Dados (ou órgão similar) realiza a revisão final, revisão e adoção.
84 • DMBOK2
As políticas podem assumir diferentes formas, como nos exemplos a seguir:
• O Data Governance Office (DGO) certificará os dados para uso da organização.
• Os proprietários de empresas serão aprovados pelo Data Governance Office.
• Os proprietários de negócios designarão os Data Stewards de suas áreas de capacidade de negócios. Os administradores de dados
terá a responsabilidade diária de coordenar as atividades de governança de dados.
• Sempre que possível, relatórios padronizados e/ou painéis/scorecards serão disponibilizados para servir
a maioria das necessidades de negócios.
• Os Usuários Certificados terão acesso aos Dados Certificados para relatórios ad hoc/não padronizados.
• Todos os dados certificados serão avaliados regularmente para avaliar sua precisão, integridade, consistência,
acessibilidade, exclusividade, conformidade e eficiência.
As políticas de dados devem ser efetivamente comunicadas, monitoradas, aplicadas e reavaliadas periodicamente. O Data Governance Council pode
delegar essa autoridade ao Data Stewardship Steering Committee.
2.8 Subscrever Projetos de Gerenciamento de Dados
As iniciativas para melhorar os recursos de gerenciamento de dados fornecem benefícios para toda a empresa. Estes geralmente requerem patrocínio
multifuncional ou visibilidade do DGC. Eles podem ser difíceis de vender porque podem ser percebidos como obstáculos para 'simplesmente fazer as
coisas'. A chave para promovê-los é articular as maneiras pelas quais eles melhoram a eficiência e reduzem o risco. As organizações que desejam obter
mais valor de seus dados precisam priorizar o desenvolvimento ou a melhoria dos recursos de gerenciamento de dados.
O DGC ajuda a definir o caso de negócios e supervisiona o status do projeto e o progresso em projetos de melhoria de gerenciamento de dados. A DGC
coordena os seus esforços com um Project Management Office (PMO), onde existe. Os projetos de gerenciamento de dados podem ser considerados
parte do portfólio geral de projetos de TI.
O DGC também pode coordenar os esforços de melhoria do gerenciamento de dados com grandes programas com escopo em toda a empresa. Projetos
de Master Data Management, como Enterprise Resource Planning (ERP), Customer or Citizen Relationship Management (CRM), listas globais de peças,
são bons candidatos para esse tipo de coordenação.
A atividade de gerenciamento de dados em outros projetos deve ser acomodada pelo SDLC interno, entrega de serviços
29
gerenciamento, outros componentes da Biblioteca de Infraestrutura de Tecnologia da Informação (ITIL) e processos de PMO.
Todo projeto com um componente de dados significativo (e quase todo projeto os possui) deve capturar os requisitos de gerenciamento de dados no início
do SDLC (fases de planejamento e design). Isso inclui arquitetura, conformidade regulatória, identificação e análise do sistema de registro e inspeção e
correção de qualidade de dados. Também pode haver atividades de suporte ao gerenciamento de dados, incluindo testes de verificação de requisitos
usando bancos de teste padrão.
29 http://bit.ly/2spRr7e.
2.9 Envolver a Gestão de Mudanças
O Organizational Change Management (OCM) é o veículo para trazer mudanças nos sistemas e processos de uma organização. O Change Management
Institute postula que o gerenciamento de mudanças organizacionais é mais do que apenas o 'lado humano dos projetos'. Deve ser visto como a abordagem
que toda a organização usa para gerenciar bem a mudança. As organizações geralmente gerenciam as transições dos projetos, em vez da evolução da
organização (Anderson e Ackerson, 2012). Uma organização madura em seu gerenciamento de mudanças constrói uma visão organizacional clara, lidera
e monitora ativamente as mudanças desde o topo e projeta e gerencia esforços de mudança menores. Adapta as iniciativas de mudança com base no
feedback e colaboração de toda a organização (Change Management Institute, 2012). (Consulte o Capítulo 17.)
Para muitas organizações, a formalidade e a disciplina inerentes à GD diferem das práticas existentes. Adotá-los exige que as pessoas mudem seus
comportamentos e interações. Um programa formal de OCM, com o patrocinador executivo certo, é fundamental para impulsionar as mudanças
comportamentais necessárias para sustentar a GD. As organizações devem criar uma equipe responsável por:
• Planejamento: Planejar a gestão de mudanças, incluindo a realização de análise das partes interessadas, obtenção de patrocínio,
e estabelecer uma abordagem de comunicação para superar a resistência à mudança.
• Treinamento: Criação e execução de planos de treinamento para programas de governança de dados.
• Influenciando o desenvolvimento de sistemas: Engajando-se com o PMO para adicionar etapas de governança de dados ao SDLC.
• Implementação de políticas: comunicação de políticas de dados e o compromisso da organização com os dados
atividades de gestão.
• Comunicações: Aumentar a conscientização sobre o papel e as responsabilidades dos Administradores de Dados e outros dados
profissionais de governança, bem como os objetivos e expectativas para projetos de gerenciamento de dados.
As comunicações são vitais para o processo de gerenciamento de mudanças. Um programa de gerenciamento de mudanças que apoia
A Governança de Dados deve focar as comunicações em:
• Promover o valor dos ativos de dados: educar e informar os funcionários sobre o papel que os dados desempenham na realização
Objetivos organizacionais.
• Monitorar e atuar no feedback sobre as atividades de governança de dados: além de compartilhar
informações, os planos de comunicação devem obter feedback que possa orientar tanto o programa de GD quanto o
processo de gerenciamento de mudanças. Buscar e usar ativamente a contribuição das partes interessadas pode criar um compromisso com a
metas do programa, além de identificar sucessos e oportunidades de melhoria.
• Implementação de treinamento de gerenciamento de dados: treinamento em todos os níveis da organização aumenta a conscientização
das melhores práticas e processos de gerenciamento de dados.
• Medir os efeitos do gerenciamento de mudanças em cinco áreas principais:30
30 http://bit.ly/1qKvLyJ. Ver também Hiatt e Creasey (2012).

86 • DMBOK2
o Consciência da necessidade de mudança o
Desejo de participar e apoiar a mudança o Conhecimento
sobre como mudar o Capacidade de implementar novas
habilidades e comportamentos o Reforço para manter a mudança
no lugar
• Implementação de novas métricas e KPIs: os incentivos dos funcionários devem ser realinhados para apoiar os comportamentos
conectado às melhores práticas de gerenciamento de dados. Como a governança de dados corporativos requer cooperação multifuncional,
os incentivos devem incentivar atividades e colaboração entre unidades.
2.10 Envolver-se no Gerenciamento de Problemas
O gerenciamento de problemas é o processo para identificar, quantificar, priorizar e resolver problemas relacionados à governança de dados, incluindo:
• Autoridade: Perguntas sobre direitos e procedimentos de decisão
• Escalonamentos de gerenciamento de mudanças: problemas decorrentes do processo de gerenciamento de mudanças
• Conformidade: Problemas com o cumprimento dos requisitos de conformidade
• Conflitos: políticas, procedimentos, regras de negócios, nomes, definições, padrões, arquitetura, dados conflitantes
propriedades e interesses conflitantes das partes interessadas em dados e informações
• Conformidade: questão relacionada à conformidade com políticas, padrões, arquitetura e procedimentos
• Contratos: Negociação e revisão de acordos de compartilhamento de dados, compra e venda de dados e armazenamento em nuvem
• Segurança e identidade de dados: questões de privacidade e confidencialidade, incluindo investigações de violação
• Qualidade de dados: detecção e resolução de problemas de qualidade de dados, incluindo desastres ou violações de segurança
Muitos problemas podem ser resolvidos localmente em equipes de administração de dados. Os problemas que exigem comunicação e/ou escalonamento
devem ser registrados, podendo ser escalonados para as equipes de Data Stewardship, ou superior para o DGC, conforme mostrado na Figura 20.
Um Scorecard de Governança de Dados pode ser usado para identificar tendências relacionadas a problemas, como onde dentro da organização eles
ocorrem, quais são suas causas-raiz, etc. Problemas que não podem ser resolvidos pelo DGC devem ser escalados para governança corporativa e/ou
gerenciamento.
<5% Comitê Diretor de Governança de Dados Estratégico
<20% Conselho de Governança de Dados

Estratégico
80-85% dos Governança de Dados da Unidade de Negócios
conflitos resolvidos
a este nível Equipes de administração de dados
Tático e Operacional
Figura 20 Caminho de escalonamento de problemas de dados

A governança de dados requer mecanismos e procedimentos de controle para:
• Identificar, capturar, registrar, rastrear e atualizar problemas
• Atribuição e rastreamento de itens de ação
• Documentar os pontos de vista das partes interessadas e alternativas de resolução
• Determinar, documentar e comunicar resoluções de problemas
• Facilitar discussões objetivas e neutras onde todos os pontos de vista são ouvidos
• Escalando questões para níveis mais altos de autoridade
O gerenciamento de problemas de dados é muito importante. Ele cria credibilidade para a equipe de DG, tem efeitos diretos e positivos nos consumidores de
dados e alivia a carga das equipes de suporte à produção. A resolução de problemas também prova que os dados podem ser gerenciados e sua qualidade
melhorada. O gerenciamento de problemas bem-sucedido requer mecanismos de controle que demonstrem o esforço de trabalho e o impacto da resolução.
2.11 Avaliar os Requisitos de Conformidade Regulamentar
Toda empresa é afetada por regulamentações governamentais e do setor, incluindo regulamentações que determinam como os dados e as informações devem
ser gerenciados. Parte da função de governança de dados é monitorar e garantir a conformidade regulatória. A conformidade regulatória geralmente é o motivo
inicial para implementar a governança de dados. A governança de dados orienta a implementação de controles adequados para monitorar e documentar a
conformidade com os regulamentos relacionados a dados.
Várias regulamentações globais têm implicações significativas nas práticas de gerenciamento de dados. Por exemplo:
• Padrões de Contabilidade: O Conselho de Padrões de Contabilidade do Governo (GASB) e o Conselho Financeiro
As normas contábeis do Conselho de Normas Contábeis (FASB) também têm implicações significativas sobre como
ativos de informação são gerenciados (nos EUA).
• BCBS 239 (Comitê de Supervisão Bancária de Basileia) e Basileia II referem-se a Princípios para Risco Efetivo
Agregação de dados e relatórios de risco, um amplo conjunto de regulamentos para bancos. Desde 2006, as finanças
as instituições que fazem negócios nos países da União Europeia são obrigadas a relatar informações padrão
comprovando a liquidez.
• CPG 235: A Autoridade Australiana de Regulamentação Prudencial (APRA) fornece supervisão de bancos e
entidades seguradoras. Ela publica padrões e guias para auxiliar no cumprimento desses padrões. Entre estes está
CGP 235, um padrão para gerenciamento de risco de dados. Concentra-se em abordar as fontes de risco de dados e em
gerenciamento de dados ao longo de seu ciclo de vida.
• PCI-DSS: Padrões de Segurança de Dados da Indústria de Cartões de Pagamento (PCI-DSS).
• Solvência II: regulamentação da União Européia, similar a Basileia II, para o setor de seguros.
• Leis de privacidade: todas as leis locais, soberanas e internacionais se aplicam.
As organizações de governança de dados trabalham com outras lideranças comerciais e técnicas para avaliar as implicações das regulamentações. A organização
deve determinar, por exemplo,

88 • DMBOK2
• De que forma um regulamento é relevante para a organização?
• O que constitui conformidade? Quais políticas e procedimentos serão necessários para alcançar a conformidade?
• Quando a conformidade é exigida? Como e quando a conformidade é monitorada?
• A organização pode adotar padrões do setor para alcançar a conformidade?
• Como a conformidade é demonstrada?
• Qual é o risco e a penalidade por não conformidade?
• Como a não conformidade é identificada e relatada? Como a não conformidade é gerenciada e corrigida?
A DG monitora a resposta da organização aos requisitos regulamentares ou compromissos de auditoria envolvendo dados e práticas de dados (por
exemplo, certificando a qualidade dos dados em relatórios regulamentares). (Consulte o Capítulo 6.)
2.12 Implementar Governança de Dados
A governança de dados não pode ser implementada da noite para o dia. Requer planejamento – não apenas para levar em conta a mudança organizacional,
mas também simplesmente porque inclui muitas atividades complexas que precisam ser coordenadas. É melhor criar um roteiro de implementação que
ilustre os prazos e o relacionamento entre as diferentes atividades. Por exemplo, se o programa de DG estiver focado em melhorar a conformidade, as
prioridades podem ser orientadas por requisitos regulatórios específicos. Em uma organização de DG federada, a implementação em várias linhas de
negócios pode ocorrer em diferentes cronogramas, de acordo com seu nível de engajamento e maturidade, bem como de financiamento.
Algum trabalho de DG é fundamental. Outros trabalhos dependem disso. Este trabalho tem um lançamento inicial e cultivo contínuo.
As atividades prioritárias nos estágios iniciais incluem:
• Definir os procedimentos de governança de dados necessários para atender às metas de alta prioridade
• Estabelecer um glossário de negócios e documentar a terminologia e os padrões
• Coordenação com Arquitetura Corporativa e Arquitetura de Dados para apoiar uma melhor compreensão do
dados e sistemas
• Atribuir valor financeiro aos ativos de dados para permitir uma melhor tomada de decisão e aumentar a compreensão
o papel que os dados desempenham no sucesso organizacional
2.13 Padrões e Procedimentos de Dados do Patrocinador
Um padrão é definido como “algo que é muito bom e que é usado para fazer julgamentos sobre a qualidade de outras coisas” ou como “algo estabelecido
e estabelecido por autoridade como regra para a medida de quantidade, peso, extensão, valor, ou qualidade.”31 Os padrões ajudam a definir a qualidade
porque fornecem um meio de comparação. Eles também oferecem o potencial de simplificar os processos. Ao adotar um padrão, uma organização toma
uma decisão uma vez e a codifica em um
31 http://bit.ly/2sTfugb
conjunto de afirmações (o padrão). Ele não precisa tomar a mesma decisão novamente para cada projeto.
A aplicação de padrões deve promover resultados consistentes dos processos que os utilizam.
Infelizmente, criar ou adotar padrões é muitas vezes um processo politizado e esses objetivos se perdem. A maioria das organizações não tem muita prática no
desenvolvimento ou aplicação de dados ou padrões de governança de dados. Em alguns casos, eles não reconheceram o valor em fazê-lo e, portanto, não
dedicaram tempo para fazê-lo. Outras vezes eles simplesmente não sabem como. Consequentemente, os 'padrões' variam muito dentro e entre as organizações,
assim como as expectativas de conformidade. As normas DG devem ser obrigatórias.
Padrões de dados podem assumir diferentes formas dependendo do que descrevem: afirmações sobre como um campo deve ser preenchido, regras que regem
as relações entre campos, documentação detalhada de valores aceitáveis e inaceitáveis, formato etc. Eles geralmente são elaborados por profissionais de
gerenciamento de dados. Os padrões de dados devem ser revisados, aprovados e adotados pelo DGC ou por um grupo de trabalho delegado, como um Comitê
Diretor de Padrões de Dados. O nível de detalhe na documentação dos padrões de dados depende, em parte, da cultura organizacional. Lembre-se de que
documentar padrões de dados apresenta uma oportunidade de capturar detalhes e conhecimentos que, de outra forma, podem ser perdidos.
Recriar ou fazer engenharia reversa para acessar esse conhecimento é muito caro, comparado a documentá-lo antecipadamente.
Os padrões de dados devem ser efetivamente comunicados, monitorados e revisados e atualizados periodicamente. Mais importante ainda, deve haver um meio
para aplicá-los. Os dados podem ser medidos em relação aos padrões. As atividades de gerenciamento de dados podem ser auditadas quanto à conformidade
com os padrões pelo DGC ou pelo Data Standards Steering Committee em um cronograma definido ou como parte dos processos de aprovação do SDLC.
Os procedimentos de gerenciamento de dados são os métodos documentados, técnicas e etapas seguidas para realizar atividades específicas que produzem
determinados resultados e artefatos de suporte. Assim como as políticas e os padrões, os procedimentos variam muito entre as organizações. Como é o caso dos
padrões de dados, os documentos procedimentais capturam o conhecimento organizacional de forma explícita. A documentação de procedimentos geralmente é
elaborada por profissionais de gerenciamento de dados.
Exemplos de conceitos que podem ser padronizados nas Áreas de Conhecimento de Gerenciamento de Dados incluem:
• Arquitetura de dados: modelos de dados corporativos, padrões de ferramentas e convenções de nomenclatura de sistema
• Modelagem e Design de Dados: Procedimentos de gerenciamento de modelo de dados, convenções de nomenclatura de modelagem de dados,
padrões de definição, domínios padrão e abreviaturas padrão
• Armazenamento e Operações de Dados: Padrões de ferramentas, padrões para recuperação de banco de dados e continuidade de negócios,
desempenho de banco de dados, retenção de dados e aquisição de dados externos
• Segurança de dados: padrões de segurança de acesso a dados, procedimentos de monitoramento e auditoria, segurança de armazenamento
padrões e requisitos de treinamento
• Integração de dados: métodos e ferramentas padrão usados para integração e interoperabilidade de dados
• Documentos e Conteúdo: Padrões e procedimentos de gerenciamento de conteúdo, incluindo o uso de
taxonomias, suporte para descoberta legal, períodos de retenção de documentos e e-mails, assinaturas eletrônicas e
abordagens de distribuição de relatórios

90 • DMBOK2
• Dados mestre e de referência: procedimentos de controle de gerenciamento de dados de referência, sistemas de registro de dados,
asserções que estabelecem e obrigam o uso, padrões para a resolução da entidade
• Data Warehousing e Business Intelligence: Ferramenta padrão, padrões e procedimentos de processamento,
padrões de formatação de relatórios e visualizações, padrões para manipulação de Big Data
• Metadados: Metadados comerciais e técnicos padrão a serem capturados, procedimentos de integração de metadados e
uso
• Qualidade de dados: regras de qualidade de dados, metodologias de medição padrão, padrões de correção de dados e
procedimentos
• Big Data e Ciência de Dados: identificação da fonte de dados, autoridade, aquisição, sistema de registro, compartilhamento
e atualize
2.14 Desenvolva um Glossário de Negócios
Os Administradores de Dados são geralmente responsáveis pelo conteúdo do glossário comercial. Um glossário é necessário porque as pessoas usam as
palavras de maneira diferente. É particularmente importante ter definições claras para dados, porque os dados representam outras coisas além de si
mesmos (Chisholm, 2010). Além disso, muitas organizações desenvolvem seu próprio vocabulário interno. Um glossário é um meio de compartilhar esse
vocabulário dentro da organização. Desenvolver e documentar definições de dados padrão reduz a ambiguidade e melhora a comunicação. As definições
devem ser claras, rigorosas na redação e explicar quaisquer exceções, sinônimos ou variantes. Os aprovadores de terminologia devem incluir
representantes de grupos de usuários principais.
A Arquitetura de Dados geralmente pode fornecer definições de rascunho e quebras de tipo de modelos de área de assunto.
Os glossários de negócios têm os seguintes objetivos:
• Permitir um entendimento comum dos principais conceitos e terminologia de negócios
• Reduzir o risco de que os dados sejam mal utilizados devido ao entendimento inconsistente dos conceitos de negócios
• Melhorar o alinhamento entre os ativos de tecnologia (com suas convenções de nomenclatura técnica) e o
organização empresarial
• Maximize a capacidade de pesquisa e permita o acesso ao conhecimento institucional documentado
Um glossário de negócios não é meramente uma lista de termos e definições. Cada termo também será associado a outros Metadados valiosos: sinônimos,
métricas, linhagem, regras de negócios, administrador responsável pelo termo, etc.
2.15 Coordenar com Grupos de Arquitetura
O DGC patrocina e aprova artefatos de arquitetura de dados, como um modelo de dados corporativo orientado para negócios. O DGC pode nomear ou
interagir com um Enterprise Data Architecture Steering Committee ou Architecture Review Board (ARB) para supervisionar o programa e seus projetos
iterativos. O modelo de dados corporativos deve ser desenvolvido e

mantidos em conjunto por arquitetos de dados e administradores de dados trabalhando juntos em equipes de áreas temáticas. Dependendo da
organização, esse trabalho pode ser coordenado pelo Enterprise Data Architect ou pelo administrador. À medida que os requisitos de negócios evoluem,
as equipes de administração de dados devem propor mudanças e desenvolver extensões para a empresa
modelo de dados.
O modelo de dados corporativos deve ser revisado, aprovado e formalmente adotado pelo DGC. Esse modelo deve estar alinhado com as principais
estratégias de negócios, processos, organizações e sistemas. A estratégia de dados e a arquitetura de dados são fundamentais para a coordenação
entre 'Fazer as coisas direito' e 'Fazer as coisas certas' ao gerenciar ativos de dados.
2.16 Avaliação de Ativos de Dados do Patrocinador
Dados e informações são ativos porque têm ou podem criar valor. As práticas contábeis atuais consideram os dados um ativo intangível, assim como
software, documentação, conhecimento especializado, segredos comerciais e outras propriedades intelectuais. Dito isso, as organizações acham difícil
atribuir valor monetário aos dados. O DGC deve organizar o esforço e estabelecer padrões para fazê-lo.
Algumas organizações começam estimando o valor das perdas de negócios devido a informações inadequadas. Lacunas de informação
– a diferença entre quais informações são necessárias e quais estão disponíveis – representam passivos de negócios. O custo
de fechar ou prevenir lacunas pode ser usado para estimar o valor comercial dos dados ausentes. A partir daí, a organização pode desenvolver modelos
para estimar o valor da informação existente.
As estimativas de valor podem ser incorporadas a um roteiro de estratégia de dados que justificará casos de negócios para soluções de causa raiz para
problemas de qualidade, bem como para outras iniciativas de governança.
2.17 Incorporar Governança de Dados
Um objetivo da organização de governança de dados é incorporar em uma série de comportamentos de processos relacionados ao gerenciamento de
dados como um ativo. A operação contínua da DG requer planejamento. O plano de operações contém a lista de eventos necessários para implementar
e operar as atividades da DG. Ele descreve atividades, tempo e técnicas necessárias para sustentar
sucesso.
Sustentabilidade significa agir para garantir que os processos e o financiamento sejam implementados para permitir o desempenho contínuo do quadro
organizacional da DG. Central para esse requisito é que a organização aceite a governança de dados; que a função seja gerenciada, seus resultados
sejam monitorados e medidos, e os obstáculos que tantas vezes fazem com que os programas de GD falhem ou falhem sejam superados.
Para aprofundar o entendimento da organização sobre governança de dados em geral, sua aplicação localmente e aprender uns com os outros, crie
uma Comunidade de Interesse de Governança de Dados. Isso é particularmente útil nos primeiros anos de governança e provavelmente diminuirá à
medida que as operações do DG se tornarem maduras.

92 • DMBOK2
3. Ferramentas e Técnicas
A governança de dados é fundamentalmente sobre o comportamento organizacional. Este não é um problema que pode ser resolvido através da
tecnologia. No entanto, existem ferramentas que suportam todo o processo. Por exemplo, DG requer comunicação contínua. Um programa de GD deve
aproveitar os canais de comunicação existentes para comunicar mensagens-chave de maneira consistente e manter as partes interessadas informadas
sobre políticas, padrões e requisitos.
Além disso, um programa de GD deve gerenciar seu próprio trabalho e seus próprios dados de forma eficaz. As ferramentas ajudam não apenas nessas
tarefas, mas também nas métricas que as suportam. Antes de escolher uma ferramenta para uma função específica, como uma solução de glossário de
negócios, uma organização deve definir suas metas e requisitos gerais de governança com o objetivo de criar um conjunto de ferramentas. Por exemplo,
algumas soluções de glossário incluem componentes adicionais para gerenciamento de políticas e fluxo de trabalho. Se tal funcionalidade adicional for
desejada, os requisitos devem ser esclarecidos e testados antes que uma ferramenta seja adotada. Caso contrário, a organização terá várias ferramentas,
nenhuma das quais poderá atender às suas necessidades.
3.1 Presença Online / Sites
O programa de Governança de Dados deve ter presença online. Ele pode disponibilizar os principais documentos por meio de um site central ou de um
portal de colaboração. Os sites podem abrigar bibliotecas de documentação, dar acesso a recursos de pesquisa e ajudar a gerenciar um fluxo de trabalho
simples. Um site também pode ajudar a estabelecer uma marca para o programa por meio de logotipos e uma representação visual consistente. Um site
do programa DG deve incluir:
• A estratégia de Governança de Dados e a carta do programa, incluindo visão, benefícios, objetivos, princípios e
roteiro de implementação
• Políticas de dados e padrões de dados
• Descrições das funções e responsabilidades de administração de dados
• Anúncios de notícias do programa
• Links para fóruns para uma Comunidade de Interesse de Governança de Dados
• Links para mensagens executivas sobre tópicos de governança de dados
• Relatórios sobre medições de qualidade de dados

• Procedimentos para identificação e encaminhamento de problemas
• Links para solicitar serviços ou capturar problemas
• Documentos, apresentações e programas de treinamento com links para recursos online relacionados
• Informações de contato do programa de Governança de Dados
3.2 Glossário Comercial
Um Glossário Comercial é uma ferramenta central da DG. Ele abriga definições acordadas de termos de negócios e as relaciona com dados. Existem
muitas ferramentas de glossário de negócios disponíveis, algumas como parte de sistemas ERP maiores, ferramentas de integração de dados ou
ferramentas de gerenciamento de metadados e algumas como ferramentas independentes.

3.3 Ferramentas de fluxo de trabalho
Organizações maiores podem querer considerar uma ferramenta de fluxo de trabalho robusta para gerenciar processos, como a implementação de
novas políticas de governança de dados. Essas ferramentas conectam processos a documentos e podem ser úteis em políticas
administração e resolução de problemas.
3.4 Ferramentas de gerenciamento de documentos
Muitas vezes, uma ferramenta de gerenciamento de documentos é usada por equipes de governança para auxiliar no gerenciamento de políticas e
procedimentos.
3.5 Scorecards de Governança de Dados
A coleta de métricas para rastrear atividades de governança de dados e conformidade com políticas pode ser relatada ao Conselho de Governança de
Dados e aos Comitês de Direção de Governança de Dados em um scorecard automatizado.
4. Diretrizes de Implementação
Uma vez que o programa de governança de dados é definido, um plano operacional desenvolvido e um roteiro de implementação preparado com o
apoio de informações coletadas na avaliação de maturidade de dados (consulte o Capítulo 15), a organização pode começar a implementar processos
e políticas. A maioria das estratégias de implantação são incrementais, aplicando primeiro a DG a um grande esforço, como MDM, ou por uma região ou
divisão. Raramente o DG é implantado em toda a empresa como um primeiro

esforço.
4.1 Organização e Cultura
Conforme observado na Seção 2.9, a formalidade e a disciplina inerentes à governança de dados serão novas e diferentes para muitas organizações. A
governança de dados agrega valor ao trazer mudanças de comportamento. Pode haver resistência à mudança e uma curva de aprendizado ou adoção
de novos métodos de tomada de decisões e projetos de governança.
Programas de governança de dados eficazes e duradouros exigem uma mudança cultural no pensamento organizacional e no comportamento sobre
dados, bem como um programa contínuo de gerenciamento de mudanças para apoiar o novo pensamento, comportamentos, políticas e processos para
alcançar o estado futuro desejado de comportamento em torno dados. Não importa quão precisa ou exótica seja a estratégia de governança de dados,
ignorar a cultura diminuirá as chances de sucesso. O foco na gestão da mudança deve fazer parte da estratégia de implementação.
94 • DMBOK2
O alvo da mudança organizacional é a sustentabilidade. A sustentabilidade é uma qualidade de um processo que mede o quão fácil é
para o processo continuar agregando valor. Sustentar um programa de governança de dados requer planejamento para mudanças.
(Consulte o Capítulo 17.)
4.2 Ajuste e Comunicação
Os programas de Governança de Dados são implementados de forma incremental dentro do contexto de uma estratégia mais ampla
de negócios e gerenciamento de dados. O sucesso requer manter os objetivos mais amplos em mente ao colocar as peças no lugar. A
equipe do DG precisará ser flexível e ajustar sua abordagem à medida que as condições mudam. As ferramentas necessárias para
gerenciar e comunicar mudanças incluem:
• Mapa de estratégia de negócios/GD: Este mapa conecta a atividade de GD com as necessidades de negócios. Medindo periodicamente
e comunicar como a DG está ajudando o negócio é vital para obter apoio contínuo para o programa.
• Roteiro DG: O roteiro para DG não deve ser rígido. Deve ser adaptado às mudanças nos negócios
ambiente ou prioridades.
• Caso de negócios contínuo para DG: O caso de negócios deve ser ajustado periodicamente para refletir as mudanças
prioridades e realidades financeiras da organização.
• Métricas de GD: As métricas precisarão crescer e mudar à medida que o programa de GD amadurece.
5. Métricas
Para combater a resistência ou o desafio de uma longa curva de aprendizado, um programa de GD deve ser capaz de medir o
progresso e o sucesso por meio de métricas que demonstrem como os participantes do GD agregaram valor aos negócios e atingiram
os objetivos.
Para gerenciar as mudanças de comportamento necessárias, é importante medir o progresso da implementação da governança de
dados, a conformidade com os requisitos de governança de dados e o valor que a governança de dados está trazendo para a
organização. Métricas que reforçam o valor do GD e aquelas que verificam se a organização possui os recursos necessários para
apoiar o GD após sua implantação também são importantes para sustentar um programa de GD. As métricas de exemplo incluem:
• Valor
o Contribuições para os objetivos de negócios

o Redução de risco
o Maior eficiência nas operações

• Eficácia
o Alcance de metas e objetivos

o Os comissários de extensão estão usando as ferramentas relevantes
o Eficácia da comunicação
o Eficácia da educação/treinamento
o Velocidade de adoção da mudança
• Sustentabilidade
o Desempenho de políticas e processos (ou seja, estão funcionando adequadamente?)
o Conformidade com padrões e procedimentos (ou seja, os funcionários estão seguindo as orientações e mudando
comportamento conforme necessário?)

Anderson, Dean e Anderson, Linda Ackerson. Além da Gestão de Mudanças. Pfeiffer, 2012.
Avramov, Lucien e Maurizio Portolani. O Data Center Orientado por Políticas com ACI: Arquitetura, Conceitos e Metodologia.
Cisco Press, 2014. Imprimir. Tecnologia de Redes.
Axelos Global Best Practice (site da ITIL). http://bit.ly/1H6SwxC.
Brzezinski, Robert. HIPAA Privacidade e Conformidade de Segurança - Simplificado: Guia Prático para Profissionais de Saúde e Gerentes de
Prática. Plataforma de Publicação Independente CreateSpace, 2014. Imprimir.
Calder, Alan. Governança de TI: Implementando Frameworks e Padrões para a Governança Corporativa de TI. Publicação de Governança de TI, 2009.
Impresso.
Change Management Institute e Carbon Group. Modelo de Maturidade da Mudança Organizacional, 2012. http://bit.ly/1Q62tR1.
Instituto de Gestão de Mudanças (site). http://bit.ly/1Q62tR1.
Chisholm, Malcolm e Roblyn-Lee, Diane. Definições em Gerenciamento de Dados: Um Guia para Metadados Semânticos Fundamentais.
Design Media, 2008. Impresso.
Cokins, Gary et ai. CIO Best Practices: Habilitando Valor Estratégico com Tecnologia da Informação, 2ª ed. Wiley, 2010. Impresso.
De Haes, Steven e Wim Van Grembergen. Governança Corporativa de Tecnologia da Informação: Alcançando Alinhamento e Valor, Apresentando
COBIT 5. 2ª ed. Springer, 2015. Impresso. Gestão para Profissionais.
DiStefano, Robert S. A integridade dos dados de ativos é um negócio sério. Industrial Press, Inc., 2010. Imprimir.
Doan, AnHai, Alon Halevy e Zachary Ives. Princípios de Integração de Dados. Morgan Kaufmann, 2012. Impresso.
Fischer, Tony. O ativo de dados: como empresas inteligentes administram seus dados para o sucesso dos negócios. Wiley, 2009. Impresso.
Giordano, Anthony David. Executando a Governança da Informação: Um Guia Passo a Passo para Fazer a Governança da Informação funcionar.
IBM Press, 2014. Imprimir. Imprensa IBM.
Hiatt, Jeff e Creasey, Timothy. Gestão de Mudanças: O Lado das Pessoas da Mudança. Prosci, 2012.
Huwe, Ruth A. Métricas 2.0: Criando Scorecards para Equipes e Organizações de Trabalho de Alto Desempenho. Praeger, 2010. Impresso.
Ladley, John. Governança de dados: como projetar, implantar e sustentar um programa eficaz de governança de dados. Morgan
Kaufmann, 2012. Impresso. A Série Morgan Kaufmann sobre Business Intelligence.
Ladley, John. Fazendo o Enterprise Information Management (EIM) funcionar para os negócios: um guia para entender a informação como um ativo.
Morgan Kaufmann, 2010. Print.
Marz, Nathan e James Warren. Big Data: Princípios e melhores práticas de sistemas de dados em tempo real escaláveis. Manning Publicações,
2015. Impresso.
96 • DMBOK2
McGilvray, Danette. Executando Projetos de Qualidade de Dados: Dez Passos para Dados de Qualidade e Informações Confiáveis. Morgan Kaufmann,
2008. Impresso.
Osborne, Jason W. Melhores práticas em limpeza de dados: um guia completo para tudo o que você precisa fazer antes e depois de coletar seus
dados. SAGE Publications, Inc, 2013. Imprimir.
Plotkin, David. Administração de dados: um guia prático para gerenciamento de dados e governança de dados eficazes. Morgan Kaufmann,
2013. Impresso.
PROSCI (site). http://bit.ly/2tt1bf9.
Razavi, Behzad. Princípios de Projeto de Sistema de Conversão de Dados. Wiley-IEEE Press, 1994. Imprimir.
Redman, Thomas C. Data Driven: lucrando com seu ativo de negócios mais importante. Harvard Business Review Press, 2008.
Imprimir.
Reinke, Guido. A Matriz de Conformidade Regulatória: Regulação de Serviços Financeiros, Tecnologia da Informação e Comunicação e Assuntos
Geralmente Relacionados. GOLD RUSH Publishing, 2015. Impresso. Conformidade regulatória.
Seiner, Robert S. Governança de dados não invasiva. Technics Publications, LLC, 2014. Imprimir.
Selig, Gad. Implementando Governança de TI: Um Guia Prático de Melhores Práticas Globais em Gerenciamento de TI. Publicação Van
Haren, 2008. Impresso. Melhor prática.
Smallwood, Robert F. Governança da Informação: Conceitos, Estratégias e Melhores Práticas. Wiley, 2014. Impresso. Wiley CIO.
Soares, Sunil. Vendendo a Governança da Informação para o Negócio: Melhores Práticas por Setor e Função de Trabalho. Mc Press, 2011.
Imprimir.
Tarantino, António. O Manual de Governança, Risco e Conformidade: Tecnologia, Finanças, Meio Ambiente e Orientação e Melhores
Práticas Internacionais. Wiley, 2008. Impresso.
Instituto de Governança de Dados (site). http://bit.ly/1ef0tnb.
O Instituto KPI e Aurel Brudan, ed. O Dicionário de KPI de Governança, Conformidade e Risco: mais de 130 definições de indicadores-chave de
desempenho. Plataforma de Publicação Independente CreateSpace, 2015. Imprimir.
CAPÍTULO 4
Arquitetura de dados
Dados
Modelagem de dados
Qualidade dos dados
& Operações
Dados Dados
Metadados

& O negócio
Interoperabilidade
Inteligência
& Mestre & Contente
Dados Gestão

1. Introdução
arquitetura refere-se à arte e ciência de construir coisas (especialmente estruturas habitáveis) e ao

UMA resultados do processo de construção – os próprios edifícios. Em um sentido mais geral, a arquitetura
refere-se a um arranjo organizado de elementos componentes destinados a otimizar a função,
desempenho, viabilidade, custo e estética de uma estrutura ou sistema geral.
O termo arquitetura foi adotado para descrever várias facetas do projeto de sistemas de informação. A ISO/IEC
42010:2007 Engenharia de Sistemas e Software – Descrição da Arquitetura (2011) define arquitetura como “a
97
98 • DMBOK2
organização fundamental de um sistema, incorporada em seus componentes, suas relações entre si e com o meio ambiente, e os princípios que
governam seu projeto e evolução”. No entanto, dependendo do contexto, a palavra arquitetura pode se referir a uma descrição do estado atual
dos sistemas, os componentes de um conjunto de sistemas, a disciplina de projetar sistemas (prática de arquitetura), o projeto intencional de um
sistema ou um conjunto de sistemas. (estado futuro ou arquitetura proposta), os artefatos que descrevem um sistema (documentação da
arquitetura) ou a equipe que faz o trabalho de design (os Arquitetos ou a equipe de Arquitetura).
A prática de arquitetura é realizada em diferentes níveis dentro de uma organização (empresa, domínio, projeto, etc.) e com diferentes áreas de
foco (infraestrutura, aplicação e dados). Exatamente o que os arquitetos fazem pode ser confuso para pessoas que não são arquitetos e que
não reconhecem as distinções implícitas nesses níveis e áreas de foco. Uma razão pela qual os frameworks arquiteturais são valiosos é que
eles permitem que não-arquitetos entendam esses relacionamentos.
A disciplina de Arquitetura Corporativa abrange arquiteturas de domínio, incluindo negócios, dados, aplicativos e tecnologia. Práticas de
arquitetura corporativa bem gerenciadas ajudam as organizações a entender o estado atual de seus sistemas, promover mudanças desejáveis
em direção ao estado futuro, habilitar a conformidade regulatória e melhorar a eficácia. O gerenciamento eficaz de dados e dos sistemas nos
quais os dados são armazenados e usados é um objetivo comum da amplitude das disciplinas de arquitetura.
Neste capítulo, a Arquitetura de Dados será considerada a partir das seguintes perspectivas:
• Resultados da Arquitetura de Dados, tais modelos, definições e fluxos de dados em vários níveis, geralmente
referidos como artefatos de arquitetura de dados
• Atividades de Arquitetura de Dados, para formar, implantar e cumprir as intenções de Arquitetura de Dados
• Comportamento da Arquitetura de Dados, como colaborações, mentalidades e habilidades entre as várias funções que
afetam a arquitetura de dados da empresa
Juntos, esses três formam os componentes essenciais da Arquitetura de Dados.
A Arquitetura de Dados é fundamental para o gerenciamento de dados. Como a maioria das organizações possui mais dados do que as pessoas
individuais podem compreender, é necessário representar os dados organizacionais em diferentes níveis de abstração para que possam ser
entendidos e a administração possa tomar decisões sobre eles.
Os artefatos de arquitetura de dados incluem especificações usadas para descrever o estado existente, definir requisitos de dados, orientar a
integração de dados e controlar ativos de dados conforme apresentado em uma estratégia de dados. A Arquitetura de Dados de uma organização
é descrita por uma coleção integrada de documentos de projeto mestre em diferentes níveis de abstração, incluindo padrões que controlam como
os dados são coletados, armazenados, organizados, usados e removidos. Também é classificado por descrições de todos os contêineres e
caminhos que os dados percorrem pelos sistemas de uma organização.
O documento de projeto de arquitetura de dados mais detalhado é um modelo de dados corporativo formal, contendo nomes de dados, dados
abrangentes e definições de metadados, entidades e relacionamentos conceituais e lógicos e regras de negócios. Modelos de dados físicos
estão incluídos, mas como um produto de modelagem e design de dados, em vez de arquitetura de dados.
ARQUITETURA DE DADOS • 99
A Arquitetura de Dados é mais valiosa quando suporta totalmente as necessidades de toda a empresa. Dados Corporativos
A arquitetura permite padronização e integração de dados consistentes em toda a empresa.
Os artefatos que os arquitetos criam constituem metadados valiosos. Idealmente, os artefatos de arquitetura devem ser armazenados e
gerenciados em um repositório de artefatos de arquitetura corporativa.
Estamos no meio da terceira onda de digitalização do cliente final. Bancos e transações financeiras vieram em primeiro lugar; várias
interações de serviços digitais estavam na segunda onda; e a internet das coisas e a telemática impulsionam o terceiro. Indústrias
tradicionais, como automotiva, equipamentos de saúde e ferramentas, estão se tornando digitais neste
terceira onda.
Isso acontece em quase todos os setores. Os novos carros Volvo têm agora serviço de plantão 24 horas por dia, 7 dias por semana, não
apenas para assuntos relacionados ao veículo, mas também para localizar restaurantes e lojas. Pontes rolantes, carregadores de paletes
e equipamentos de anestesia estão coletando e enviando dados operacionais que permitem serviços de tempo de atividade. As ofertas
passaram de equipamentos de fornecimento para contratos de pagamento por uso ou de disponibilidade. Muitas dessas empresas têm
pouca ou nenhuma experiência nessas áreas, uma vez que antes eram atendidas por varejistas ou prestadores de serviços de pós-venda.
As organizações voltadas para o futuro devem incluir profissionais de gerenciamento de dados (por exemplo, Enterprise Data Architects ou
um Data Stewards estratégico) ao projetar novas ofertas de mercado, porque hoje em dia geralmente incluem hardware, software e serviços
que capturam dados, dependem de acesso a dados ou Ambas.
O objetivo da Arquitetura de Dados é ser uma ponte entre a estratégia de negócios e a execução da tecnologia. Como parte da Arquitetura
Corporativa, os Arquitetos de Dados:
• Preparar estrategicamente as organizações para evoluir rapidamente seus produtos, serviços e dados para levar
vantagem das oportunidades de negócios inerentes às tecnologias emergentes
• Traduzir as necessidades de negócios em dados e requisitos do sistema para que os processos tenham os dados consistentemente
eles exigem
• Gerenciar dados complexos e entrega de informações em toda a empresa
• Facilitar o alinhamento entre Negócios e TI
• Atuar como agentes de mudança, transformação e agilidade
Esses direcionadores de negócios devem influenciar as medidas do valor da Arquitetura de Dados.
Os arquitetos de dados criam e mantêm o conhecimento organizacional sobre os dados e os sistemas pelos quais eles se movem. Esse
conhecimento permite que uma organização gerencie seus dados como um ativo e aumente o valor que obtém de seus dados, identificando
oportunidades de uso de dados, redução de custos e mitigação de riscos.

100 • DMBOK2
1.2 Resultados e Práticas da Arquitetura de Dados
Os resultados da Arquitetura de Dados Primários incluem:
• Requisitos de armazenamento e processamento de dados
• Projetos de estruturas e planos que atendem aos requisitos de dados atuais e de longo prazo da empresa
Arquitetura de dados
Definição: Identificar as necessidades de dados da empresa (independentemente da estrutura) e projetar

e manter os planos mestres para atender a essas necessidades. Usando blueprints mestres para orientar a
integração de dados, controlar ativos de dados e alinhar investimentos em dados com a estratégia de
negócios.
Objetivos:
1. Identificar requisitos de armazenamento e processamento de dados.

2. Projete estruturas e planos para atender aos requisitos de dados atuais e de longo prazo da empresa.
3. Prepare estrategicamente as organizações para evoluir rapidamente seus produtos, serviços e dados para tirar proveito
de oportunidades de negócios inerentes às tecnologias emergentes.
O negócio
Motoristas

• Empreendimento 1. Estabeleça dados corporativos • Arquitetura de Dados
Arquitetura Arquitetura (P) Projeto
• O negócio 1. Avalie os dados existentes • Fluxos de dados
Arquitetura Especificações de arquitetura • Cadeias de valor de dados
• Padrões de TI e 2. Desenvolva um roteiro • Dados Corporativos
Metas 3. Gerenciar Empresa Modelo
• Estratégias de dados Requisitos dentro dos Projetos • Implementação
(D) Roteiro
2. Integrar com o Enterprise
Arquitetura (O)

• Empresa Arquitetos de Dados Corporativos • Base de dados
Arquitetos • Modeladores de Dados Administradores
• Administradores de dados • Desenvolvedores de software
• Assunto • Gerentes de projeto
Técnico
Especialistas • Equipes de Suporte
Motoristas
• Analistas de dados
Técnicas: Ferramentas: Métricas:

• • •
Revisões do ciclo de vida Ferramentas de modelagem de dados
Padrões de arquitetura
•
• Clareza de diagramação Software de gerenciamento de ativos taxas de conformidade
• •
Aplicações de design gráfico Tendências na implementação
• Métricas de valor de negócios
Figura 21 Diagrama de Contexto: Arquitetura de Dados

Os arquitetos procuram projetar de uma forma que agregue valor à organização. Esse valor vem por meio de uma base técnica ideal, eficiências
operacionais e de projeto e o aumento da capacidade da organização de usar seus dados. Para chegar lá, é necessário um bom projeto,
planejamento e a capacidade de garantir que os projetos e planos sejam executados de forma eficaz.
Para atingir esses objetivos, os Data Architects definem e mantêm especificações que:
• Definir o estado atual dos dados na organização
• Fornecer um vocabulário de negócios padrão para dados e componentes
• Alinhar a arquitetura de dados com a estratégia empresarial e arquitetura de negócios
• Expressar requisitos de dados estratégicos
• Delinear projetos integrados de alto nível para atender a esses requisitos
• Integrar com o roteiro geral da arquitetura corporativa
Uma prática geral de Arquitetura de Dados inclui:
• Usando artefatos de Arquitetura de Dados (planos mestres) para definir os requisitos de dados, orientar os dados
integração, controlar ativos de dados e alinhar investimentos em dados com a estratégia de negócios
• Colaborar, aprender e influenciar várias partes interessadas que estão envolvidas
melhorar o negócio ou o desenvolvimento de sistemas de TI
• Usando a Arquitetura de Dados para estabelecer a semântica de uma empresa, por meio de um vocabulário de negócios comum
1.3.1 Domínios de Arquitetura Corporativa
A Arquitetura de Dados opera no contexto de outros domínios de arquitetura, incluindo negócios, aplicativos e arquitetura técnica. A Tabela 6
descreve e compara esses domínios. Arquitetos de diferentes domínios devem abordar as direções e os requisitos de desenvolvimento de
forma colaborativa, pois cada domínio influencia e impõe restrições aos outros domínios. (Veja também a Figura 22.)
Tabela 6 Domínios de Arquitetura
Domínio Empreendimento Dados Corporativos Empreendimento Empreendimento
O negócio Arquitetura Formulários Tecnologia

Propósito Identificar como uma Para descrever como os Para descrever a Descrever a
empresa cria valor para dados devem ser estrutura e a tecnologia física
clientes e outras partes organizados e gerenciados funcionalidade dos necessária para permitir
interessadas aplicativos em uma que os sistemas
empresa funcionem e forneçam valor
102 • DMBOK2
Domínio Empreendimento Dados Corporativos Empreendimento Empreendimento
O negócio Arquitetura Formulários Tecnologia

Elementos Modelos de negócios, Modelos de dados, Sistemas de negócios, Plataformas técnicas,

processos, definições de dados, pacotes de software, redes, segurança,
capacidades, serviços, especificações de bancos de dados ferramentas de integração
eventos, estratégias, mapeamento de dados,
vocabulário fluxos de dados, dados estruturados
API
Dependências Estabelece requisitos Gerencia os dados criados Atua em dados Hospeda e executa a
para os outros domínios e exigidos pela arquitetura especificados de arquitetura do aplicativo
de negócios acordo com os
requisitos de negócios
Funções Arquitetos e analistas de Arquitetos e modeladores Arquitetos de Arquitetos de

negócios, administradores de dados, administradores aplicativos infraestrutura
de dados de negócios de dados
1.3.2 Estruturas de Arquitetura Empresarial
Uma estrutura de arquitetura é uma estrutura fundamental usada para desenvolver uma ampla gama de arquiteturas relacionadas.
As estruturas arquitetônicas fornecem maneiras de pensar e entender a arquitetura. Eles representam uma
'arquitetura para arquitetura' geral.
A IEEE Computer Society mantém um padrão para Enterprise Architecture Frameworks, ISO/IEC/IEEE 42010:2011, Sistemas e engenharia de
software — Descrição da arquitetura e uma tabela de comparação.32 Comum

frameworks e métodos incluem a Arquitetura de Dados como um dos domínios arquiteturais.
1.3.2.1 Zachman Framework para Arquitetura Empresarial
A estrutura de arquitetura corporativa mais conhecida, a Zachman Framework, foi desenvolvida por John A.
Zachman na década de 1980. (Veja a Figura 22.) Ele continuou a evoluir. Zachman reconheceu que na criação de edifícios, aviões, empresas,
cadeias de valor, projetos ou sistemas, existem muitos públicos, e cada um tem uma perspectiva diferente sobre arquitetura. Ele aplicou esse
conceito aos requisitos para diferentes tipos e níveis de arquitetura dentro de uma empresa.
O Zachman Framework é uma ontologia – a matriz 6x6 compreende o conjunto completo de modelos necessários para descrever uma empresa
e os relacionamentos entre eles. Não define como criar os modelos. Simplesmente

mostra quais modelos devem existir.
32http://bit.ly/2tNnD2j; http://bit.ly/2rVinIq.
o que Quão Onde Quem Quando Por que
Inventário Processo Distribuição Responsabilidade Cronometragem Motivação

Executivo Identificação Identificação Identificação Identificação Identificação Identificação Contexto do Escopo

O negócio O negócio
definição Definição Definição Definição Definição Definição
Gestão Conceitos
Arquiteto Representação Representação Representação Representação Representação Representação

Lógica do Sistema

Tecnologia
Engenheiro Especificação Especificação Especificação Especificação Especificação Especificação
Física
Inventário Processo Distribuição Responsabilidade Cronometragem Motivação Ferramenta
Técnico Configuração Configuração Configuração Configuração Configuração Configuração Componentes
Inventário Processo Distribuição Responsabilidade Cronometragem Motivação Operacional

Empreendimento Instanciações Instanciações Instanciações Instanciações Instanciações Instanciações Instâncias

Conjuntos Fluxos Redes atribuições Ciclos Intenções
Figura 22 Estrutura Zachman simplificada
As duas dimensões na estrutura matricial são as interrogativas de comunicação (ou seja, o que, como, onde, quem, quando, por que) como
colunas e as transformações de reificação (Identificação, Definição, Representação, Especificação, Configuração e Instanciação) como
linhas. As classificações do framework são representadas pelas células (a interseção entre as interrogativas e as transformações). Cada
célula no Zachman Framework representa um tipo único de artefato de design.
As interrogativas de comunicação são as perguntas fundamentais que podem ser feitas sobre qualquer entidade. Traduzidas para
arquitetura corporativa, as colunas podem ser entendidas da seguinte forma:
• O que (a coluna do inventário): Entidades usadas para construir a arquitetura
• Como (a coluna do processo): Atividades realizadas
• Onde (a coluna de distribuição): localização da empresa e localização da tecnologia
• Quem (a coluna de responsabilidade): Funções e organizações
• Quando (a coluna de tempo): Intervalos, eventos, ciclos e horários
• Por que (a coluna de motivação): Objetivos, estratégias e meios
As transformações de reificação representam os passos necessários para traduzir uma ideia abstrata em uma instância concreta (uma
instanciação). Eles são representados nas linhas: planejador, proprietário, designer, construtor, implementador e usuário.
Cada um tem uma perspectiva diferente sobre o processo geral e diferentes problemas para resolver. Essas perspectivas são representadas
como linhas. Por exemplo, cada perspectiva tem uma relação diferente com o O quê (inventário ou dados)
coluna:
• A perspectiva executiva (contexto de negócios): Listas de elementos de negócios que definem o escopo em
modelos de identificação.
• A perspectiva de gestão de negócios (conceitos de negócios): Esclarecimento dos relacionamentos
entre os conceitos de negócio definidos pelos Líderes Executivos como Proprietários nos modelos de definição.
104 • DMBOK2
• A perspectiva do arquiteto (lógica de negócios): Modelos lógicos do sistema detalhando os requisitos do sistema e
projeto irrestrito representado por Arquitetos como Designers em modelos de representação.
• A perspectiva do engenheiro (física de negócios): Modelos físicos otimizando o projeto para
implementação para uso específico sob as restrições de tecnologia, pessoas, custos e
prazos especificados por Engenheiros como Construtores em modelos de especificação.
• A perspectiva do técnico (montagens de componentes): Uma visão específica da tecnologia, fora de contexto
como os componentes são montados e operam configurados por técnicos como implementadores em
modelos de configuração.
• A perspectiva do usuário (classes de operações): instâncias de funcionamento reais usadas pelos Trabalhadores como
Participantes. Não há modelos nesta perspectiva.
Conforme observado anteriormente, cada célula no Zachman Framework representa um tipo único de artefato de design, definido pela interseção
de sua linha e coluna. Cada artefato representa como a perspectiva específica responde às questões fundamentais.
1.3.3 Arquitetura de Dados Corporativos
A Arquitetura de Dados Corporativos define termos e designs padrão para os elementos que são importantes para a organização. O projeto de
uma Arquitetura de Dados Corporativos inclui a representação dos dados de negócios como tal, incluindo a coleta, armazenamento, integração,
movimentação e distribuição de dados.
À medida que os dados fluem em uma organização por meio de feeds ou interfaces, eles são protegidos, integrados, armazenados, registrados,
catalogados, compartilhados, relatados, analisados e entregues às partes interessadas. Ao longo do caminho, os dados podem ser verificados,
aprimorados, vinculados, certificados, agregados, anonimizados e usados para análise até serem arquivados ou eliminados.
As descrições da Arquitetura de Dados Corporativos devem, portanto, incluir tanto Modelos de Dados Corporativos (por exemplo, estruturas de
dados e especificações de dados), quanto o Projeto de Fluxo de Dados:
• Modelo de Dados Corporativos (EDM): O EDM é um modelo holístico, de nível empresarial, independente de implementação
modelo de dados conceitual ou lógico que fornece uma visão comum e consistente dos dados em toda a empresa. Isto
é comum usar o termo para significar um modelo de dados simplificado de alto nível, mas isso é uma questão de
abstração para apresentação. Um EDM inclui as principais entidades de dados corporativos (ou seja, conceitos de negócios),
seus relacionamentos, regras de negócios orientadoras críticas e alguns atributos críticos. Ele estabelece a
base para todos os dados e projetos relacionados a dados. Qualquer modelo de dados em nível de projeto deve ser baseado no
EDM. O EDM deve ser revisado pelas partes interessadas, para que haja consenso de que ele efetivamente
representa o empreendimento.
• Design de fluxo de dados: define os requisitos e o plano mestre para armazenamento e processamento em
bancos de dados, aplicativos, plataformas e redes (os componentes). Esses fluxos de dados mapeiam o
movimentação de dados para processos de negócios, locais, funções de negócios e componentes técnicos.
Esses dois tipos de especificações precisam se encaixar bem. Como mencionado, ambos precisam ser refletidos no estado atual e no estado
alvo (perspectiva da arquitetura), e também no estado de transição (perspectiva do projeto).
1.3.3.1 Modelo de Dados Corporativos
Algumas organizações criam um EDM como um artefato independente. Em outras organizações, é entendido como composto de modelos de
dados de diferentes perspectivas e em diferentes níveis de detalhes, que descrevem consistentemente o entendimento de uma organização
sobre entidades de dados, atributos de dados e seus relacionamentos em toda a empresa. Um EDM inclui modelos de dados universais (modelos
conceituais e lógicos para toda a empresa) e modelos de dados específicos de aplicativos ou projetos, juntamente com definições, especificações,
mapeamentos e regras de negócios.
Adotar um modelo padrão do setor pode impulsionar o processo de desenvolvimento de um EDM. Esses modelos fornecem um guia e referências
úteis. No entanto, mesmo que uma organização comece com um modelo de dados adquirido, a produção de modelos de dados corporativos
exige um investimento significativo. O trabalho inclui definir e documentar o vocabulário de uma organização, regras de negócios e conhecimento
de negócios. Manter e enriquecer um EDM requer um compromisso contínuo de tempo e esforço.
Uma organização que reconhece a necessidade de um modelo de dados corporativo deve decidir quanto tempo e esforço pode dedicar à sua
construção e manutenção. Os EDMs podem ser construídos em diferentes níveis de detalhes, de modo que a disponibilidade de recursos
influenciará o escopo inicial. Com o tempo, conforme as necessidades da empresa demandam, o escopo e o nível de detalhes capturados em
um modelo de dados corporativos normalmente se expandem. Os modelos de dados corporativos mais bem-sucedidos são construídos de forma
incremental e iterativa, usando camadas. A Figura 23 mostra como os diferentes tipos de modelos estão relacionados e como os modelos
conceituais são, em última análise, vinculáveis aos modelos de dados de aplicativos físicos. Ele distingue:
• Uma visão geral conceitual sobre as áreas temáticas da empresa
• Visões de entidades e relacionamentos para cada área de assunto
• Visões lógicas detalhadas e parcialmente atribuídas dessas mesmas áreas de assunto
• Modelos lógicos e físicos específicos para um aplicativo ou projeto
Todos os níveis fazem parte do Modelo de Dados Corporativos e as ligações criam caminhos para rastrear uma entidade de cima para baixo
e entre modelos no mesmo nível.
• Vertical: Modelos em cada nível mapeiam para modelos em outros níveis. A linhagem do modelo é criada usando esses
mapas. Por exemplo, uma tabela ou arquivo MobileDevice em um modelo físico específico do projeto pode vincular a um
Entidade MobileDevice no modelo lógico específico do projeto, uma entidade MobileDevice no assunto Product
área no Modelo Lógico da Empresa, uma entidade conceitual do Produto no Modelo de Área de Assunto do Produto,
e para a entidade Produto no Modelo Conceitual Empresarial.
• Horizontal: Entidades e relacionamentos podem aparecer em vários modelos no mesmo nível; entidades em
modelos lógicos centrados em um tópico podem se relacionar a entidades em outros tópicos, marcados ou anotados como externos
para a área de assunto nas imagens do modelo. Uma entidade de peça do produto pode aparecer na área de assunto do produto
modelos e nas áreas Ordem de venda, Estoque e Marketing, relacionadas como links externos.
106 • DMBOK2
Um modelo de dados corporativos em todos os níveis é desenvolvido usando técnicas de modelagem de dados. (Consulte o Capítulo 5.)
Modelo de dados corporativos

1 diagrama:
12-20 áreas de
Modelo conceitual negócios significativas
com
relacionamentos
Sujeito Sujeito Sujeito Sujeito 1+ diagrama por
Área Área Área Área área de assunto:

mais de 50 entidades
Modelo Modelo Modelo Modelo significativas dentro
área de assunto com

relacionamentos
Para cada assunto

Área Lógica
Modelo:
Aumente os detalhes
Lógico Lógico Lógico Lógico
adicionando atributos e
Modelo Modelo Modelo Modelo
entidades e
relacionamentos
menos significativos
Limite o escopo ao
assunto e 1-step externo
LDM LDM LDM LDM LDM LDM LDM
relacionamentos
PDM PDM PDM PDM PDM PDM PDM Limitar o escopo
aos objetos físicos e
relacionamentos
Aplicação ou projeto específico sujeitos
Figura 23 Modelo de dados corporativos
A Figura 24 mostra três diagramas de Área de Assunto (exemplos simplificados), cada um contendo um Modelo de Dados Conceitual com um conjunto
de entidades. Os relacionamentos podem cruzar as fronteiras da Área de Assunto; cada entidade em um modelo de dados corporativos deve residir em
apenas uma área de assunto, mas pode estar relacionada a entidades em qualquer outra área de assunto.
Assim, o modelo conceitual de dados corporativos é construído pela combinação de modelos de Área de Assunto. O modelo de dados corporativos pode
ser construído usando uma abordagem de cima para baixo ou usando uma abordagem de baixo para cima. A abordagem de cima para baixo significa
começar com a formação das Áreas de Assunto e, em seguida, preenchê-las com modelos. Ao usar uma abordagem de baixo para cima, a estrutura da
área de assunto é baseada em modelos de dados existentes. Uma combinação de

abordagens geralmente são recomendadas; começando de baixo para cima usando modelos existentes e concluindo o modelo de dados
corporativos preenchendo os modelos delegando a modelagem da área de assunto aos projetos.
Comercial
Design de produto Assunto de vendas
Área de estudo Assunto da oferta Área
Área
Mercado
produtos Vendas
Grupo de produtos Oferta
Plataforma Ordem
Portfólio
Faixa de Ofertas Ocorre em

Usos
Vendas Vendas
Pertence a
produtos
Item Item do pedido
Design de produto
Lista de materiais Especifica
(BOM)
Pacote de vendas
Lista de materiais
(BOM)
produtos
Papel Vendas
Item do pedido
Detalhes
Papel
Configuração
Estrutura
Figura 24 Exemplo de diagrama de modelos de área de assunto
O discriminador da Área de Assunto (ou seja, os princípios que formam a estrutura da Área de Assunto) deve ser consistente em todo o modelo
de dados corporativos. Os princípios discriminadores de área de assunto usados com frequência incluem: usar regras de normalização, dividir
áreas de assunto de portfólios de sistemas (ou seja, financiamento), formar áreas de assunto a partir da estrutura de governança de dados e
propriedade de dados (organizacional), usando processos de nível superior (com base nas cadeias de valor de negócios ), ou usando recursos de
negócios (baseados em arquitetura corporativa). A estrutura da Área de Assunto geralmente é mais eficaz para o trabalho de Arquitetura de Dados
se for formada usando regras de normalização. O processo de normalização estabelecerá as principais entidades que carregam/constituem cada
Área de Assunto.
1.3.3.2 Projeto de Fluxo de Dados
Os fluxos de dados são um tipo de documentação de linhagem de dados que descreve como os dados se movem pelos processos e sistemas de
negócios. Os fluxos de dados de ponta a ponta ilustram a origem dos dados, onde são armazenados e usados e como são transformados à
medida que se movem dentro e entre diversos processos e sistemas. A análise de linhagem de dados pode ajudar a explicar o estado dos dados
em um determinado ponto do fluxo de dados.

108 • DMBOK2
Os fluxos de dados mapeiam e documentam relacionamentos entre dados e
• Aplicativos dentro de um processo de negócios

• Armazenamentos de dados ou bancos de dados em um ambiente
• Segmentos de rede (úteis para mapeamento de segurança)
• Funções de negócios, descrevendo quais funções têm a responsabilidade de criar, atualizar, usar e excluir
data (CRUD)
• Locais onde ocorrem diferenças locais
Os fluxos de dados podem ser documentados em diferentes níveis de detalhes: Área de Assunto, entidade de negócios ou até mesmo o
nível de atributo. Os sistemas podem ser representados por segmentos de rede, plataformas, conjuntos de aplicativos comuns ou
servidores individuais. Os fluxos de dados podem ser representados por matrizes bidimensionais (Figura 25) ou em diagramas de fluxo
de dados (Figura 26).
Processos de negócios
Preparação
Marketing
Fabricação Logística Faturamento
Desenvolvimento de produtos & Vendas industrial Gerenciamento de pedidos
produtos
Peça do produto
Fabricação
Plantar
Cliente
Item de vendas
Conjunto
Estrutura
Pedido de venda
Produção
Ordem
Individual
produtos
Envio
Clientes
Fatura
Crio Ler/usar
Figura 25 Fluxo de dados representado em uma matriz
Uma matriz fornece uma visão clara de quais dados os processos criam e usam. Os benefícios de mostrar os requisitos de dados em uma
matriz é que leva em consideração que os dados não fluem em apenas uma direção; as trocas de dados entre processos são muitos-para-
muitos de uma forma bastante complexa, onde qualquer dado pode aparecer em qualquer lugar.
Além disso, uma matriz pode ser usada para esclarecer as responsabilidades de aquisição de dados dos processos e as dependências
de dados entre os processos, o que, por sua vez, melhora a documentação do processo. Aqueles que preferem
trabalhar com recursos de negócios pode mostrar isso da mesma maneira – apenas trocando o eixo de processos por recursos.
Construir essas matrizes é uma prática de longa data na modelagem empresarial. A IBM introduziu essa prática em seu método
Business Systems Planning (BSP). James Martin mais tarde o popularizou em seu método de Planejamento de Sistemas de
Informação (ISP) durante a década de 1980.
O fluxo de dados na Figura 26 é um diagrama de fluxo de dados de alto nível tradicional que descreve o tipo de fluxo de dados
entre os sistemas. Esses diagramas podem ser descritos em vários formatos e níveis de detalhes.
Estatísticas de serviço e reparo

Devoluções de materiais
CRM
Dados do cliente Estatísticas

de serviço e reparo
Cliente
acordo
BOM de design de produto

Propriedades do produto Mercado de reposição
Sistema PDM Sistema de vendas
Sistema
BOM de design de produto

Sales BOM
Propriedades do produto
Conteúdo do pedido
Dados de origem
Fabricação Fabricação
Sistema de roteamento Planejamento Números de série
BOM de fabricação Sistema BOM de produto individual
Roteamento da linha de produção
Prazos de entrega
Figura 26 Exemplo de diagrama de fluxo de dados
2. Atividades
A arquitetura de dados e corporativa lida com a complexidade de dois pontos de vista:

110 • DMBOK2
• Orientado para a qualidade: Foco na melhoria da execução dentro dos ciclos de desenvolvimento de negócios e TI. A não ser que
se a arquitetura for gerenciada, a arquitetura se deteriorará. Os sistemas se tornarão gradualmente mais complexos
e inflexível, criando risco para uma organização. Entrega de dados não controlada, cópias de dados e interface
relacionamentos de 'espaguete' tornam as organizações menos eficientes e reduzem a confiança nos dados.
• Orientado para a inovação: Foco na transformação de negócios e TI para atender às novas expectativas e
oportunidades. Impulsionar a inovação com tecnologias disruptivas e usos de dados tornou-se um papel do
Arquiteto Empresarial moderno.
Esses dois drivers requerem abordagens separadas. A abordagem orientada para a qualidade alinha-se com o trabalho tradicional de
Arquitetura de Dados, onde as melhorias de qualidade arquitetural são realizadas de forma incremental. As tarefas de arquitetura são
distribuídas aos projetos, onde os arquitetos participam ou o projeto é executado por delegação. Normalmente, o arquiteto mantém toda a
arquitetura em mente e se concentra em metas de longo prazo diretamente conectadas à governança, padronização e desenvolvimento
estruturado. A abordagem orientada para a inovação pode ter uma perspectiva de curto prazo e usar lógica de negócios não comprovada e
tecnologias de ponta. Essa orientação geralmente exige que os arquitetos entrem em contato com pessoas dentro da organização com as
quais os profissionais de TI geralmente não interagem (por exemplo, representantes de desenvolvimento de produtos e designers de negócios).
2.1 Estabelecer Prática de Arquitetura de Dados
Idealmente, a Arquitetura de Dados deve ser parte integrante da arquitetura corporativa. Se não houver uma função de arquitetura corporativa,
uma equipe de arquitetura de dados ainda poderá ser estabelecida. Sob essas condições, uma organização deve adotar uma estrutura que
ajude a articular os objetivos e direcionadores da Arquitetura de Dados. Esses drivers influenciarão a abordagem, o escopo e as prioridades
no roteiro.
Escolha uma estrutura aplicável ao tipo de negócio (por exemplo, use uma estrutura governamental para uma organização governamental). As
visões e a taxonomia da estrutura devem ser úteis na comunicação com as várias partes interessadas. Isso é especialmente importante para
iniciativas de Arquitetura de Dados, pois abordam a terminologia de negócios e sistemas. A Arquitetura de Dados tem uma relação
inerentemente próxima com a arquitetura de negócios.
Uma prática de Arquitetura de Dados Corporativos geralmente inclui os seguintes fluxos de trabalho, executados em série ou em paralelo:
• Estratégia: Selecionar estruturas, abordagens de estado, desenvolver roteiro
• Aceitação e cultura: informar e motivar mudanças de comportamento
• Organização: Organize o trabalho de Arquitetura de Dados atribuindo responsabilidades e responsabilidades
• Métodos de trabalho: Definir as melhores práticas e realizar o trabalho de Arquitetura de Dados no desenvolvimento
projetos, em coordenação com a Arquitetura Empresarial
• Resultados: Produza artefatos de Arquitetura de Dados dentro de um roteiro geral

A Arquitetura de Dados Corporativos também influencia os limites do escopo dos projetos e versões do sistema:
• Definição dos requisitos de dados do projeto: os arquitetos de dados fornecem requisitos de dados corporativos para
projetos individuais.
• Revisão dos designs de dados do projeto: As revisões do design garantem que os dados conceituais, lógicos e físicos
os modelos são consistentes com a arquitetura e apoiam a estratégia organizacional de longo prazo.
• Determinar o impacto da linhagem de dados: Garante que as regras de negócios nos aplicativos ao longo do fluxo de dados
são consistentes e rastreáveis.
• Controle de replicação de dados: a replicação é uma maneira comum de melhorar o desempenho do aplicativo e tornar
dados mais prontamente disponíveis, mas também pode criar inconsistências nos dados. Arquitetura de dados
A governança garante que o controle de replicação suficiente (métodos e mecanismos) esteja em vigor para
alcançar a consistência necessária. (Nem todos os aplicativos precisam de consistência estrita.)
• Aplicação de padrões de arquitetura de dados: formulação e aplicação de padrões para a empresa
Ciclo de vida da Arquitetura de Dados. Padrões podem ser expressos como princípios e procedimentos, diretrizes e como
bem como projetos com expectativas de conformidade.
• Orientar a tecnologia de dados e as decisões de renovação: o Data Architect trabalha com os Enterprise Architects
para gerenciar versões de tecnologia de dados, patches e políticas que cada aplicativo usa, como um roteiro para dados
tecnologia.
2.1.1 Avaliar as especificações de arquitetura de dados existentes
Toda organização tem alguma forma de documentação para seus sistemas existentes. Identifique esses documentos e avalie-os quanto à
precisão, integridade e nível de detalhe. Se necessário, atualize-os para refletir o atual

Estado.
2.1.2 Desenvolver um roteiro
Se uma empresa fosse desenvolvida do zero (livre da dependência de processos existentes), uma arquitetura ideal seria baseada apenas nos
dados necessários para executar a empresa, as prioridades seriam definidas pela estratégia de negócios e as decisões poderiam ser tomadas
sem o peso do passado. Muito poucas organizações estão neste estado.
Mesmo em uma situação ideal, as dependências de dados surgiriam rapidamente e precisariam ser gerenciadas. Um roteiro fornece um meio
de gerenciar essas dependências e tomar decisões futuras. Um roteiro ajuda uma organização a ver as compensações e a formular um plano
pragmático, alinhado às necessidades e oportunidades de negócios, requisitos externos e recursos disponíveis.
Um roteiro para Arquitetura de Dados Corporativos descreve o caminho de desenvolvimento de 3 a 5 anos da arquitetura. Juntamente com os
requisitos de negócios, consideração das condições reais e avaliações técnicas, o roteiro

112 • DMBOK2
descreve como a arquitetura de destino se tornará realidade. O roteiro da Arquitetura de Dados Corporativos deve ser integrado
a um roteiro geral da arquitetura corporativa que inclui marcos de alto nível, recursos necessários e estimativas de custos,
divididos em fluxos de trabalho de capacidade de negócios. O roteiro deve ser guiado por uma avaliação da maturidade do
gerenciamento de dados. (Consulte o Capítulo 15.)
A maioria dos recursos de negócios requer dados como entrada; outros também produzem dados dos quais outros recursos de
negócios dependem. A arquitetura corporativa e a Arquitetura de Dados Corporativos podem ser formadas de forma coerente,
resolvendo esse fluxo de dados em uma cadeia de dependências entre os recursos de negócios.
Um roteiro orientado a dados de negócios começa com os recursos de negócios que são mais independentes (ou seja, têm
menos dependência de outras atividades) e termina com aqueles que são mais dependentes de outros. Lidar com cada
capacidade de negócios em sequência seguirá uma ordem geral de originação de dados de negócios. A Figura 27 mostra um
exemplo de cadeia de dependência, com a dependência mais baixa no topo. A Gestão de Produtos e a Gestão de Clientes não
dependem de mais nada e, portanto, constituem Dados Mestres. Os itens de maior dependência estão na parte inferior, onde o
Gerenciamento de Faturas do Cliente depende do Gerenciamento de Clientes e do Gerenciamento de Pedidos de Vendas, que
por sua vez depende de outros dois.
produtos
produtos Dados
Gestão
produtos
Dados
Peça do produto
Gestão
BOM
Detalhes
Cliente
BOM
Gestão
Detalhes Item de vendas
Dados
Item de vendas
Cliente
Gestão
Dados
Pedido de venda
Conjunto Gestão Cliente
Estrutura Dados
Gestão
Pedido de venda
Pedido de venda Dados
Dados
Conjunto Clientes
Estrutura Fatura
Dados
Gestão
Ordem de produção
Gestão
Figura 27 As dependências de dados dos recursos de negócios

Portanto, o roteiro idealmente aconselharia começar nos recursos de Gerenciamento de Produtos e Gerenciamento de Clientes e, em seguida,
resolver cada dependência em etapas de cima para baixo.
2.1.3 Gerenciar Requisitos Corporativos em Projetos
A arquitetura não deve ficar presa às limitações que prevalecem no momento em que é desenvolvida. Modelos de dados e outras especificações
que descrevem a arquitetura de dados de uma organização devem ser flexíveis o suficiente para acomodar requisitos futuros. Um modelo de
dados no nível de arquitetura deve ter uma visão global da empresa juntamente com definições claras que possam ser compreendidas em toda
a organização.
Os projetos de desenvolvimento implementam soluções para captura, armazenamento e distribuição de dados com base nos requisitos de
negócios e nos padrões estabelecidos pela Enterprise Data Architecture. Esse processo, por sua natureza, é realizado de forma incremental.
No nível do projeto, o processo de especificação de requisitos por meio de um modelo de dados começa com a revisão das necessidades de
negócios. Muitas vezes, essas necessidades serão específicas para os objetivos do projeto e não terão implicações para a empresa.
O processo ainda deve incluir o desenvolvimento de definições de termos e outras atividades que apoiem o uso dos dados.
É importante ressaltar que os arquitetos de dados devem ser capazes de entender os requisitos em relação à arquitetura geral.
Quando uma especificação de projeto é concluída, os arquitetos de dados devem determinar:
• Se as entidades de toda a empresa representadas na especificação estão em conformidade com os padrões acordados
• Quais entidades na especificação de requisitos devem ser incluídas nos Dados Corporativos gerais
Arquitetura
• Se as entidades e definições nesta especificação precisam ser generalizadas ou melhoradas para

lidar com tendências futuras
• Se novas arquiteturas de entrega de dados são indicadas ou se devem apontar os desenvolvedores no

direção de reutilização
As organizações geralmente esperam para resolver as preocupações da Arquitetura de Dados até que os projetos precisem projetar o
armazenamento e a integração de dados. No entanto, é preferível incluir essas considerações no início do planejamento e durante todo o ciclo
de vida do projeto.
As atividades relacionadas ao projeto Enterprise Data Architecture incluem:
• Definir escopo: Certifique-se de que o escopo e a interface estejam alinhados com o modelo de dados corporativos. Entender
a contribuição potencial do projeto para a Arquitetura de Dados Corporativos geral, com relação ao que o
projeto irá modelar e projetar e em termos de quais componentes existentes devem (ou podem) ser reutilizados. Dentro
aquelas áreas que devem ser projetadas, o projeto precisa determinar as dependências com as partes interessadas
fora do escopo do projeto, como processos a jusante. Os artefatos de dados que o projeto determina
114 • DMBOK2
para serem compartilháveis ou reutilizáveis precisam ser incorporados ao modelo de dados lógicos da empresa e aos
repositórios designados.
• Compreender os requisitos de negócios: Capturar requisitos relacionados a dados, como entidade, fonte(s),
disponibilidade, qualidade e pontos problemáticos e estimar o valor comercial de atender a esses requisitos.
• Design: Forme especificações de destino detalhadas, incluindo regras de negócios em uma perspectiva de ciclo de vida de dados.
Valide o resultado e, quando necessário, atenda às necessidades de modelos padronizados estendidos e aprimorados.
O modelo de dados lógicos corporativos e o repositório de arquitetura corporativa são bons lugares para os arquitetos de
dados do projeto procurarem e reutilizarem construções que podem ser compartilhadas em toda a empresa. Revise e use padrões
de tecnologia de dados.
• Implementar:
o Ao comprar, faça a engenharia reversa dos aplicativos adquiridos (Comercial Off the Shelf – COTS) e mapeie em relação
à estrutura de dados. Identifique e documente lacunas e diferenças em estruturas, definições e regras. Idealmente,
os fornecedores fornecerão modelos de dados para seus produtos; no entanto, muitos não, pois os consideram
proprietários. Se possível, negocie um modelo com definições detalhadas.
o Ao reutilizar dados, mapeie os modelos de dados do aplicativo em relação a estruturas de dados comuns e
processos existentes e novos para entender as operações CRUD. Impor o uso de sistema de registro ou outros
dados oficiais. Identifique e documente as lacunas.
o Ao construir, implemente o armazenamento de dados de acordo com a estrutura de dados. Integrar de acordo com
especificações padronizadas ou projetadas. (Consulte o Capítulo 8.)
O papel dos Enterprise Data Architects nos projetos depende da metodologia de desenvolvimento. O processo de construção de atividades
arquitetônicas em projetos também difere entre as metodologias.
• Métodos em cascata: entenda os requisitos e construa sistemas em fases sequenciais como parte de um projeto empresarial geral.
Este método inclui pedágios projetados para controlar a mudança. Geralmente não é problema incluir atividades de Arquitetura de
Dados em tais modelos. Certifique-se de incluir uma perspectiva empresarial.
• Métodos incrementais: Aprenda e construa em etapas graduais (ou seja, mini-cachoeiras). Esse método cria protótipos com base em
requisitos gerais vagos. A fase de iniciação é crucial; é melhor criar um design de dados abrangente nas primeiras iterações.
• Métodos ágeis e iterativos: Aprenda, construa e teste em pacotes de entrega discretos (chamados 'sprints') que são pequenos
o suficiente para que, se o trabalho precisar ser descartado, não se perca muito. Os métodos ágeis (Scrum, Desenvolvimento
Rápido e Processo Unificado) promovem a modelagem orientada a objetos que enfatiza o design da interface do usuário, o
design do software e o comportamento dos sistemas. Complete esses métodos com especificações para modelos de dados,
captura de dados, armazenamento de dados e distribuição de dados. A experiência do DevOps, uma abordagem ágil emergente
e popular, atesta o design de dados aprimorado e escolhas de design eficazes quando programadores e arquitetos de dados têm
uma forte relação de trabalho e ambos cumprem padrões e diretrizes.

2.2 Integrar com a Arquitetura Corporativa
O trabalho de desenvolvimento de especificações de Arquitetura de Dados Corporativos do nível de área de assunto para níveis mais detalhados e
em relação a outros domínios de arquitetura é normalmente realizado em projetos financiados. Os projetos financiados geralmente orientam as
prioridades da arquitetura. No entanto, as questões de arquitetura de dados em toda a empresa devem ser abordadas de forma proativa. De fato, a
Arquitetura de Dados pode influenciar o escopo dos projetos. É melhor, portanto, integrar questões de Arquitetura de Dados Corporativos com o
gerenciamento de portfólio de projetos. Isso permite a implementação do roteiro e contribui para melhores resultados do projeto.
Da mesma forma, os Enterprise Data Architects precisam ser incluídos no desenvolvimento de aplicativos corporativos e no planejamento de
integração. Aplique a visualização da Arquitetura de Dados no cenário do aplicativo de destino e o roteiro para esse cenário.
3. Ferramentas
3.1 Ferramentas de modelagem de dados
Ferramentas de modelagem de dados e repositórios de modelos são necessários para gerenciar o modelo de dados corporativos em todos os níveis.
A maioria das ferramentas de modelagem de dados inclui funções de rastreamento de linhagem e relacionamento, que permitem aos arquitetos
gerenciar ligações entre modelos criados para diferentes propósitos e em diferentes níveis de abstração. (Consulte o Capítulo 5.)
3.2 Software de Gestão de Ativos
O software de gerenciamento de ativos é usado para inventariar sistemas, descrever seu conteúdo e rastrear os relacionamentos entre eles. Entre
outras coisas, essas ferramentas permitem que uma organização garanta o cumprimento das obrigações contratuais relacionadas às licenças de
software e colete dados relacionados aos ativos que podem ser usados para minimizar custos e otimizar sua pegada de TI. Como compilam um
inventário de ativos de TI, essas ferramentas coletam e contêm Metadados valiosos sobre sistemas e os dados que eles contêm. Esses metadados
são muito úteis ao criar fluxos de dados ou pesquisar o estado atual.
3.3 Aplicativos de Design Gráfico
Os aplicativos de design gráfico são usados para criar diagramas de design arquitetônico, fluxos de dados, cadeias de valor de dados,
e outros artefatos arquitetônicos.
116 • DMBOK2
4. Técnicas
4.1 Projeções do Ciclo de Vida
Os projetos de arquitetura podem ser aspiracionais ou voltados para o futuro, implementados e ativos ou planos para aposentadoria.
O que eles representam deve ser claramente documentado. Por exemplo:
• Atual: Produtos atualmente suportados e usados • Período de
implantação: Produtos implantados para uso nos próximos 1-2 anos • Período estratégico: Produtos
que devem estar disponíveis para uso nos próximos 2 anos ou mais • Aposentadoria: Produtos que a organização
se aposentou ou pretende para se aposentar dentro de um ano • Preferencial: Produtos preferidos para uso pela maioria
dos aplicativos • Contenção: Produtos limitados ao uso por determinados aplicativos • Emergentes: Produtos sendo
pesquisados e testados para possível implantação futura • Revisados: Produtos que foram avaliados, os resultados da
avaliação e atualmente não estão em nenhum outro
status acima
Consulte o Capítulo 6 para obter mais informações sobre o gerenciamento de tecnologias de dados.
4.2 Clareza de diagramação
Modelos e diagramas apresentam informações com base em um conjunto estabelecido de convenções visuais. Estes precisam ser usados de forma
consistente ou serão mal interpretados e podem, de fato, estar incorretos. As características que minimizam as distrações e maximizam as informações
úteis incluem:
• Uma legenda clara e consistente: A legenda deve identificar todos os objetos e linhas e o que eles significam.
A legenda deve ser colocada no mesmo local em todos os diagramas.
• Uma correspondência entre todos os objetos de diagrama e a legenda: Nas legendas usadas como modelos, nem todos os objetos de
legenda podem aparecer no diagrama, mas todos os objetos de diagrama devem corresponder a um objeto de legenda.
• Uma direção de linha clara e consistente: todos os fluxos devem começar em um lado ou canto (geralmente à esquerda)
e flua para o lado ou canto oposto o máximo possível. Loops e círculos ocorrerão, então faça com que as linhas que vão para trás fluam para
fora e ao redor para ficarem claras.
• Um método consistente de exibição de linhas cruzadas: As linhas podem se cruzar desde que fique claro que o ponto de cruzamento não é
uma junção. Use saltos de linha para todas as linhas em uma direção. Não junte linhas a linhas. Minimize o número
de linhas que se cruzam.
• Atributos de objeto consistentes: Qualquer diferença em tamanhos, cores, espessura de linha, etc. deve significar
alguma coisa, caso contrário, as diferenças são uma distração.

• Simetria linear: Diagramas com objetos colocados em linhas e colunas são mais legíveis do que aqueles
com colocação aleatória. Embora raramente seja possível alinhar todos os objetos, alinhando pelo menos metade
(horizontal e/ou verticalmente) melhorará muito a legibilidade de qualquer diagrama.
Conforme declarado na introdução do capítulo, a Arquitetura de Dados trata de artefatos, atividades e comportamento. A implementação
da Arquitetura de Dados Corporativos é, portanto, sobre:
• Organização das equipes e fóruns de Arquitetura de Dados Corporativos
• Produzir as versões iniciais de artefatos de Arquitetura de Dados, como modelo de dados corporativos, fluxo de dados em toda
a empresa e roteiros
• Formar e estabelecer uma maneira de trabalhar arquitetura de dados em projetos de desenvolvimento
• Criar consciência em toda a organização do valor dos esforços de Arquitetura de Dados
Uma implementação de Arquitetura de Dados deve incluir pelo menos duas delas, pois elas se beneficiam de serem lançadas
simultaneamente, ou pelo menos como atividades paralelas. A implementação pode começar em uma parte da organização ou em um
domínio de dados, como dados de produtos ou dados de clientes. Depois de aprender e amadurecer, a implementação pode crescer mais.
Modelos de dados e outros artefatos de arquitetura de dados geralmente são capturados em projetos de desenvolvimento e, em seguida,
padronizados e gerenciados por arquitetos de dados. Portanto, os primeiros projetos terão porções maiores de trabalho de Arquitetura de
Dados antes que haja artefatos para reutilização. Esses projetos iniciais poderiam se beneficiar de um financiamento especial para
arquitetura.
O Enterprise Data Architect colabora com outros arquitetos de negócios e tecnologia que compartilham o objetivo comum de melhorar a
eficácia e a agilidade organizacional. Os direcionadores de negócios para a arquitetura corporativa geral também influenciam
significativamente a estratégia de implementação da Arquitetura de Dados Corporativos.
Estabelecer uma Arquitetura de Dados Corporativos em uma cultura orientada a soluções onde novas invenções são testadas usando
tecnologia disruptiva exigirá uma abordagem de implementação ágil. Isso pode incluir ter um modelo de área de assunto delineado em um
nível geral enquanto participa de um nível de detalhe em sprints ágeis. Assim, a Arquitetura de Dados Corporativos evoluirá de forma
incremental. No entanto, essa abordagem ágil precisa garantir que os arquitetos de dados estejam envolvidos desde o início nas iniciativas
de desenvolvimento, pois elas evoluem rapidamente em uma cultura inventiva.
Ter um driver de qualidade para arquitetura corporativa pode forçar algum trabalho inicial de Arquitetura de Dados em nível corporativo
para projetos de desenvolvimento planejados. Normalmente, a Arquitetura de Dados Corporativos começa com áreas de Dados Mestres
que precisam de melhorias e, uma vez estabelecidas e aceitas, se expande para incluir dados orientados a eventos de negócios (ou seja,
dados transacionais). Esta é a abordagem de implementação tradicional

118 • DMBOK2
onde os arquitetos de dados corporativos produzem blueprints e modelos para serem usados em todo o cenário do sistema e garantindo
a conformidade usando vários meios de governança.
5.1 Avaliação de Prontidão / Avaliação de Risco
Projetos de iniciação de arquitetura expõem mais riscos do que outros projetos, especialmente durante a primeira tentativa dentro da
organização. Os riscos mais significativos são:
• Falta de suporte gerencial: Qualquer reorganização da empresa durante a execução planejada do projeto afetará o processo
de arquitetura. Por exemplo, novos tomadores de decisão podem questionar o processo e ficar tentados a desistir de
oportunidades para os participantes continuarem seu trabalho na Arquitetura de Dados. É estabelecendo apoio entre a
gerência que um processo de arquitetura pode sobreviver à reorganização. Portanto, certifique-se de incluir no processo de
desenvolvimento da Arquitetura de Dados mais de um membro da alta administração, ou pelo menos da alta administração,
que entenda o
Benefícios da Arquitetura de Dados.
• Sem histórico comprovado de realização: Ter um patrocinador é essencial para o sucesso do esforço, assim como sua
confiança naqueles que executam a função de Arquitetura de Dados. Conte com a ajuda de um colega arquiteto sênior para
ajudar a realizar as etapas mais importantes.
• Patrocinador apreensivo: Se o patrocinador exigir que toda a comunicação passe por ele, pode ser uma indicação de que
essa pessoa não tem certeza de sua função, tem interesses diferentes dos objetivos do processo de Arquitetura de Dados
ou não tem certeza da capacidade do arquiteto de dados. Independentemente do motivo, o patrocinador deve permitir que
o gerente de projeto e o arquiteto de dados assumam os papéis principais no projeto. Tente estabelecer independência no
local de trabalho, juntamente com a confiança do patrocinador.
• Decisões executivas contraproducentes: Pode ser que, embora a administração entenda o valor de uma Arquitetura de
Dados bem organizada, não saiba como alcançá-la. Portanto, eles podem tomar decisões que contrariem os esforços do
arquiteto de dados. Isso não é um sinal de gerenciamento desleal, mas sim uma indicação de que o arquiteto de dados
precisa se comunicar com mais clareza ou frequência com o gerenciamento.
• Choque cultural: considere como a cultura de trabalho mudará entre aqueles que serão afetados por
a Arquitetura de Dados. Tente imaginar o quão fácil ou difícil será para os funcionários mudarem seu comportamento dentro
da organização.
• Líder de projeto inexperiente: Certifique-se de que o gerente de projeto tenha experiência com Arquitetura de Dados
Corporativos, especialmente se o projeto tiver um componente de dados pesado. Se este não for o caso, incentive o
patrocinador a mudar ou instruir o gerente do projeto (Edvinsson, 2013).
• Domínio de uma visão unidimensional: Às vezes, o(s) proprietário(s) de um aplicativo de negócios tende a ditar sua visão
sobre a Arquitetura de Dados geral de nível empresarial (por exemplo, os proprietários de um sistema ERP) em detrimento
de um - Vista equilibrada e com tudo incluído.

5.2 Organização e Mudança Cultural
A velocidade com que uma organização adota práticas arquitetônicas depende de quão adaptável é sua cultura. A natureza do trabalho de design
exige que os arquitetos colaborem com desenvolvedores e outros pensadores criativos em toda a organização. Muitas vezes, essas pessoas estão
acostumadas a trabalhar à sua maneira. Eles podem abraçar ou resistir à mudança necessária para adotar princípios e ferramentas de arquitetura
formal.
Organizações orientadas para resultados e estrategicamente alinhadas estão na melhor posição para adotar práticas de arquitetura.
Essas organizações geralmente são orientadas para metas, cientes dos desafios de clientes e parceiros e capazes de priorizar com base em objetivos
comuns.
A capacidade de uma organização adotar práticas de Arquitetura de Dados depende de vários fatores:
• Receptividade cultural à abordagem arquitetônica (desenvolver uma cultura favorável à arquitetura)
• Reconhecimento organizacional de dados como um ativo de negócios, não apenas uma preocupação de TI
• Capacidade organizacional de deixar de lado uma perspectiva local e adotar uma perspectiva empresarial em relação aos dados
• Capacidade organizacional de integrar entregas arquitetônicas na metodologia do projeto
• Nível de aceitação da governança formal de dados
• Capacidade de olhar holisticamente para a empresa, em vez de se concentrar apenas na entrega do projeto e na TI
resolvendo (Edvinsson, 2013)
6. Governança da Arquitetura de Dados
As atividades de Arquitetura de Dados suportam diretamente o alinhamento e o controle dos dados. Os arquitetos de dados geralmente atuam como
contatos comerciais para atividades de governança de dados. Portanto, a arquitetura de dados corporativos e a organização de governança de dados
precisam estar bem alinhadas. Idealmente, tanto um arquiteto de dados quanto um Data Steward devem ser atribuídos a cada área de assunto e até
mesmo a cada entidade dentro de uma área de assunto. Além disso, a supervisão do negócio deve estar alinhada à supervisão do processo. As áreas
de assunto de eventos de negócios devem estar alinhadas com a governança de processos de negócios, pois cada entidade de evento geralmente
corresponde a um processo de negócios. Governança de arquitetura de dados

atividades incluem:
• Supervisão de Projetos: Isso inclui garantir que os projetos estejam em conformidade com a Arquitetura de Dados necessária
atividades, usar e melhorar os ativos de arquitetura e implementar de acordo com

padrões.
• Gerenciamento de projetos arquitetônicos, ciclo de vida e ferramentas: Os projetos arquitetônicos devem ser definidos,
avaliados e mantidos. A Arquitetura de Dados Corporativos serve como um 'plano de zoneamento' para
integração. A arquitetura do estado futuro afeta os objetivos do projeto e influencia a prioridade do
projetos no portfólio de projetos.
• Definição de padrões: Definir as regras, diretrizes e especificações de como os dados são usados dentro do
organização.
• Criação de artefatos relacionados a dados: Artefatos que permitem a conformidade com as diretrizes de governança.
120 • DMBOK2
6.1 Métricas
As métricas de desempenho na Arquitetura de Dados Corporativos refletem os objetivos da arquitetura: conformidade da arquitetura, tendências de
implementação e valor comercial da Arquitetura de Dados. As métricas de arquitetura de dados geralmente são monitoradas anualmente como
parte da satisfação geral do cliente comercial com os projetos.
• A taxa de conformidade padrão de arquitetura mede o quanto os projetos estão em conformidade com as arquiteturas de dados
estabelecidas e o quanto os projetos aderem aos processos de envolvimento com a arquitetura corporativa.
As métricas que rastreiam as exceções do projeto também podem ser úteis como meio de entender os obstáculos à adoção.
• As tendências de implementação acompanham o grau em que a arquitetura corporativa melhorou a
capacidade da organização de implementar projetos, ao longo de pelo menos duas linhas:
o Usar/reutilizar/substituir/retirar medições: Determinar a proporção da nova arquitetura
artefatos versus artefatos reutilizados, substituídos ou retirados.
o Medições de eficiência de execução de projetos: medem os prazos de entrega dos projetos e seus
custos de recursos para melhorias de entrega com artefatos reutilizáveis e artefatos de orientação.
• As medições de valor comercial acompanham o progresso em direção aos efeitos e benefícios comerciais esperados.
o Melhorias na agilidade dos negócios: Medições que levam em conta os benefícios do ciclo de vida
melhorias ou alternativa, o custo do atraso.
o Qualidade do negócio: Medições de se os casos de negócio são cumpridos conforme pretendido;
medir se os projetos realmente entregam mudanças que levam a melhorias nos negócios com base em dados recém-criados
ou integrados. o Qualidade da operação do negócio: Medições de eficiência melhorada. Exemplos incluem
precisão aprimorada e reduzindo o tempo e as despesas de correção de erros devido a dados

erros.
o Melhorias no ambiente de negócios: Exemplos incluem taxa de retenção de clientes aprimorada relacionada à redução
de erros de dados e incidência reduzida de comentários de autoridades sobre relatórios enviados.

Ahlemann, Frederik, Eric Stettiner, Marcus Messerschmidt e Christine Legner, eds. Gestão Estratégica de Arquitetura Empresarial: Desafios, Melhores
Práticas e Desenvolvimentos Futuros. Springer, 2012. Impresso. Gestão para Profissionais.
Bernard, Scott A. Uma Introdução à Arquitetura Empresarial. 2ª edição. Authorhouse, 2005. Impresso.
Brackett, Michael H. Compartilhamento de dados usando uma arquitetura de dados comum. John Wiley and Sons, 1994. Impresso.
Carbono, Jane. Kit de ferramentas de arquitetura de TI. Prentice Hall, 2004. Impresso.
Cozinheiro, Melissa. Construindo Arquiteturas de Informação Corporativa: Reengenharia de Sistemas de Informação. Prentice Hall, 1996.
Imprimir.
Edvinsson, Hakan e Lottie Aderinne. Arquitetura corporativa simplificada usando a abordagem Ready, Set, Go para alcançar a
centralidade da informação. Publicações Técnicas, LCC, 2013. Impresso.
Gabinete Executivo do Presidente dos Estados Unidos. A Abordagem Comum para a Arquitetura Empresarial Federal.
whitehouse.gov, 2012. Web.
Fong, Joseph. Reengenharia e Integração de Sistemas de Informação. 2ª edição. Springer, 2006. Impresso.
Gane, Chris e Trish Sarson. Análise de Sistemas Estruturados: Ferramentas e Técnicas. Prentice Hall, 1979. Print.
Hagan, Paula J., ed. EABOK: Guia para o Corpo de Conhecimento (Evolutivo) da Arquitetura Empresarial. mitre.org MITRE
Corporation, 2004. Web.
Harrison, Raquel. TOGAF Versão 8.1.1 Enterprise Edition - Guia de Estudo. O Grupo Aberto. 2ª edição. Publicação Van Haren, 2007.
Impresso. TOGAF.
Hoberman, Steve, Donna Burbank e Chris Bradley. Modelagem de dados para o negócio: um manual para alinhar o negócio com a
TI usando modelos de dados de alto nível. Technics Publications, LLC, 2009. Imprimir. Leve com você guias.
HOBERMAN, Steve. Modelagem de dados simplificada: um guia prático para profissionais de negócios e tecnologia da informação. 2ª
edição. Technics Publications, LLC, 2009. Imprimir.
Hoogervorst, Jan AP Governança Corporativa e Engenharia Corporativa. Springer, 2009. Impresso. A Engenharia Empresarial
Ser.
ISO (site). http://bit.ly/2sTp2rA, http://bit.ly/2ri8Gqk.
Inmon, WH, John A. Zachman e Jonathan G. Geiger. Data Stores, Data Warehousing e o Zachman Framework: Gerenciando o
Conhecimento Corporativo. McGraw-Hill, 1997. Print.
Lankhorst, Marc. Arquitetura Empresarial no Trabalho: Modelagem, Comunicação e Análise. Springer, 2005. Impresso.
Martin, James e Joe Leben. Metodologias de Planejamento Estratégico da Informação, 2ª ed. Prentice Hall, 1989. Impresso.
Osterwalder, Alexander e Yves Pigneur. Geração de Modelo de Negócios: Um Manual para Visionários, Game Changers e Challengers.
Wiley, 2010. Impresso.
Perks, Cel e Tony Beveridge. Guia de Arquitetura de TI Corporativa. Springer, 2003. Impresso. Springer Computação Profissional.
Poole, John, Dan Chang, Douglas Tolbert e David Mellor. Metamodelo de Armazém Comum. Wiley, 2001. Impresso. OMG (Livro 17).
Radhakrishnan, Rakesh. Identidade e Segurança: Uma Arquitetura e Estrutura Comuns para SOA e Convergência de Rede.
texto futuro, 2007. Imprimir.
Ross, Jeanne W., Peter Weill e David Robertson. Arquitetura corporativa como estratégia: criando uma base para a execução de
negócios. Harvard Business School Press, 2006. Impresso.
Schekkerman, Jaap. Como sobreviver na selva das estruturas de arquitetura corporativa: criando ou escolhendo uma estrutura de
arquitetura corporativa. Trafford Publishing, 2006. Impresso.
Spewak, Steven e Steven C. Hill. Planejamento de arquitetura corporativa: desenvolvendo um modelo para dados, aplicativos e tecnologia.
2ª edição. Uma publicação Wiley-QED, 1993. Impresso.
Ulrich, William M. e Philip Newcomb. Transformação de Sistemas de Informação: Estudos de Caso de Modernização Orientada à
Arquitetura. Morgan Kaufmann, 2010. Print. A imprensa MK/OMG.
CAPÍTULO 5
Modelagem e Design de Dados
Dados
Modelagem de dados
Qualidade dos dados
& Operações
Dados Dados
Metadados

& O negócio
Interoperabilidade
Inteligência
& Mestre & Contente
Dados Gestão

1. Introdução
D
A modelagem de dados é o processo de descobrir, analisar e definir o escopo dos requisitos de dados e, em seguida,
representando e comunicando esses requisitos de dados em uma forma precisa chamada modelo de dados.
A modelagem de dados é um componente crítico do gerenciamento de dados. O processo de modelagem exige que as
organizações descubram e documentem como seus dados se encaixam. O próprio processo de modelagem projeta como os dados
se encaixam (Simsion, 2013). Os modelos de dados descrevem e permitem que uma organização entenda seus ativos de dados.
123
124 • DMBOK2
Existem vários esquemas diferentes usados para representar dados. Os seis esquemas mais usados são: Relacional, Dimensional,
Orientado a Objetos, Baseado em Fatos, Baseado em Tempo e NoSQL. Os modelos desses esquemas existem em três níveis
de detalhes: conceitual, lógico e físico. Cada modelo contém um conjunto de componentes.
Exemplos de componentes são entidades, relacionamentos, fatos, chaves e atributos. Uma vez que um modelo é construído, ele
precisa ser revisado e, uma vez aprovado, mantido.
Modelagem e Design de Dados
Definição: A modelagem de dados é o processo de descobrir, analisar e definir o escopo dos requisitos de
dados e, em seguida, representar e comunicar esses requisitos de dados em uma forma precisa chamada
modelo de dados. Esse processo é iterativo e pode incluir um modelo conceitual, lógico e físico.
Objetivo:
Confirmar e documentar uma compreensão de diferentes perspectivas, o que leva a aplicativos que se alinham mais de perto com os requisitos de negócios
atuais e futuros e cria uma base para concluir com sucesso iniciativas de amplo escopo, como gerenciamento de dados mestre e programas de governança de
dados.
O negócio
Motoristas

•
Modelos de dados existentes 1. Plano para Modelagem de Dados (P) • Dados Conceituais
e bancos de dados
2. Construa os Modelos de Dados (D) Modelo
• Padrões de dados •
•
1. Crie os dados conceituais Modelo de dados lógicos
Conjuntos de dados
Modelo •
• Modelo de dados físicos
Dados iniciais
2. Crie o modelo de dados lógicos
requisitos
• 3. Crie o modelo de dados físicos
Dados originais
requisitos 3. Revise os Modelos de Dados (C)
• Arquitetura de dados
4. Gerenciar os Modelos de Dados (O)
•
Taxonomia empresarial
Fornecedores: Participantes: Consumidores:

• Profissionais de negócios • •
Analistas de negócios Analistas de negócios
• • •
Analistas de negócios Modeladores de dados Modeladores de dados
• Arquitetos de dados • Administradores e desenvolvedores
• Base de dados
de banco de dados
Administradores e •
Desenvolvedores de software
• Administradores de dados
Desenvolvedores
• •
Especialistas no assunto Analistas de qualidade de dados
• Administradores de dados • Consumidores de dados
• Metadados Técnico
Administradores Motoristas
Ferramentas: Métricas:
Técnicas: •
• •
Ferramentas de modelagem de dados Validação do modelo de dados
Convenções de nomenclatura
•
• Ferramentas de linhagem medição
Projeto de banco de dados •
• Repositórios de metadados
Seleção do tipo de banco de dados •
Padrões de modelo de dados
•
Modelos de dados do setor
Figura 28 Diagrama de contexto: modelagem e design de dados

MODELAGEM E DESIGN DE DADOS • 125
Os modelos de dados compreendem e contêm Metadados essenciais para os consumidores de dados. Muitos desses metadados descobertos
durante o processo de modelagem de dados são essenciais para outras funções de gerenciamento de dados. Por exemplo, definições para
governança de dados e linhagem para armazenamento e análise de dados.
Este capítulo descreverá a finalidade dos modelos de dados, os conceitos essenciais e o vocabulário comum usados na modelagem de dados e
os objetivos e princípios da modelagem de dados. Ele usará um conjunto de exemplos de dados relacionados a
educação para ilustrar como os modelos de dados funcionam e para mostrar as diferenças entre eles.
Os modelos de dados são essenciais para o gerenciamento eficaz de dados. Elas:
• Forneça um vocabulário comum sobre dados
• Capturar e documentar conhecimento explícito sobre os dados e sistemas de uma organização
• Servir como uma ferramenta primária de comunicação durante os projetos
• Fornecer o ponto de partida para customização, integração ou até substituição de um aplicativo
O objetivo da modelagem de dados é confirmar e documentar a compreensão de diferentes perspectivas, o que leva a aplicativos que se alinham
mais de perto com os requisitos de negócios atuais e futuros e cria uma base para concluir com sucesso iniciativas de amplo escopo, como Master
Data Management e programas de governança de dados . A modelagem de dados adequada reduz os custos de suporte e aumenta as
oportunidades de reutilização para iniciativas futuras, reduzindo assim os custos de criação de novos aplicativos. Os modelos de dados são uma
forma importante de
Metadados.
Confirmar e documentar a compreensão de diferentes perspectivas facilita:
• Formalização: Um modelo de dados documenta uma definição concisa de estruturas e relacionamentos de dados. Isto
permite a avaliação de como os dados são afetados por regras de negócios implementadas, para estados atuais ou
estados alvo desejados. A definição formal impõe uma estrutura disciplinada aos dados que reduz a
possibilidade de ocorrência de anomalias de dados ao acessar e persistir dados. Ao ilustrar o
estruturas e relacionamentos nos dados, um modelo de dados torna os dados mais fáceis de consumir.
• Definição do escopo: Um modelo de dados pode ajudar a explicar os limites do contexto e implementação de dados
de pacotes de aplicativos adquiridos, projetos, iniciativas ou sistemas existentes.
• Retenção/documentação de conhecimento: Um modelo de dados pode preservar a memória corporativa em relação a um
sistema ou projeto, capturando o conhecimento de forma explícita. Serve como documentação para futuras
projetos para usar como a versão como está. Os modelos de dados nos ajudam a entender uma organização ou área de negócios,
um aplicativo existente ou o impacto de modificar uma estrutura de dados existente. O modelo de dados torna-se
um mapa reutilizável para ajudar profissionais de negócios, gerentes de projeto, analistas, modeladores e desenvolvedores
126 • DMBOK2
entender a estrutura de dados dentro do ambiente. Da mesma forma que o cartógrafo aprendeu e documentou uma paisagem
geográfica para outros usarem para navegação, o modelador permite que outros entendam uma paisagem de informação
(Hoberman, 2009).
Esta seção explicará os diferentes tipos de dados que podem ser modelados, os componentes dos modelos de dados, os tipos de
modelos de dados que podem ser desenvolvidos e as razões para escolher diferentes tipos em diferentes situações. Esse conjunto de
definições é extenso, em parte, porque a modelagem de dados em si trata do processo de definição. É importante compreender o
vocabulário que suporta a prática.
1.3.1 Modelagem de Dados e Modelos de Dados
A modelagem de dados é realizada com mais frequência no contexto de esforços de desenvolvimento e manutenção de sistemas,
conhecido como ciclo de vida de desenvolvimento de sistema (SDLC). A modelagem de dados também pode ser realizada para iniciativas
de escopo amplo (por exemplo, arquitetura de negócios e dados, gerenciamento de dados mestre e iniciativas de governança de dados)
em que o resultado final imediato não é um banco de dados, mas uma compreensão dos dados organizacionais.
Um modelo é uma representação de algo que existe ou um padrão para algo a ser feito. Um modelo pode conter um ou mais diagramas.
Os diagramas de modelo fazem uso de símbolos padrão que permitem entender o conteúdo.
Mapas, organogramas e plantas de construção são exemplos de modelos em uso todos os dias.
Um modelo de dados descreve os dados de uma organização como a organização os entende ou como a organização deseja que sejam.
Um modelo de dados contém um conjunto de símbolos com rótulos de texto que tentam representar visualmente os requisitos de dados
conforme comunicados ao modelador de dados, para um conjunto específico de dados que pode variar em tamanho de pequeno, para
um projeto, a grande, para uma organização. O modelo é uma forma de documentação para requisitos de dados e definições de dados
resultantes do processo de modelagem. Os modelos de dados são o principal meio usado para comunicar os requisitos de dados do
negócio para a TI e dentro da TI de analistas, modeladores e arquitetos para designers e desenvolvedores de banco de dados.
1.3.2 Tipos de dados que são modelados
Quatro tipos principais de dados podem ser modelados (Edvinsson, 2013). Os tipos de dados que estão sendo modelados em qualquer
organização refletem as prioridades da organização ou do projeto que requer um modelo de dados:
• Informações de categoria: Dados usados para classificar e atribuir tipos às coisas. Por exemplo, clientes
classificados por categorias de mercado ou setores de negócios; produtos classificados por cor, modelo, tamanho, etc.;
ordens classificadas por serem abertas ou fechadas.

• Informações de recursos: perfis básicos de recursos necessários conduzem processos operacionais, como
Produto, Cliente, Fornecedor, Instalação, Organização e Conta. Entre os profissionais de TI, recursos
entidades são às vezes chamadas de Dados de Referência.
• Informações de eventos de negócios: Dados criados enquanto os processos operacionais estão em andamento. Exemplos
incluem Pedidos de Clientes, Faturas de Fornecedores, Retiradas de Dinheiro e Reuniões de Negócios. Entre TI
profissionais, as entidades de eventos às vezes são chamadas de dados de negócios transacionais.
• Informações detalhadas sobre transações : informações detalhadas sobre transações geralmente são produzidas por meio de pontos de
sistemas de venda (em lojas ou online). Também é produzido por meio de sistemas de mídia social, outros
Interações na Internet (clickstream, etc.), e por sensores em máquinas, que podem ser partes de embarcações e
veículos, componentes industriais ou dispositivos pessoais (GPS, RFID, Wi-Fi, etc.). Esse tipo de detalhamento
informações podem ser agregadas, usadas para derivar outros dados e analisadas em busca de tendências, semelhante à forma como o
eventos de informações de negócios são usados. Este tipo de dados (grande volume e/ou mudança rápida) é
geralmente chamado de Big Data.
Esses tipos referem-se a 'dados em repouso'. Os dados em movimento também podem ser modelados, por exemplo, em esquemas para sistemas,
incluindo protocolos e esquemas para sistemas de mensagens e sistemas baseados em eventos.
1.3.3 Componentes do Modelo de Dados
Como será discutido posteriormente neste capítulo, diferentes tipos de modelos de dados representam dados por meio de diferentes convenções (consulte
a Seção 1.3.4). No entanto, a maioria dos modelos de dados contém os mesmos blocos de construção básicos: entidades, relacionamentos, atributos e
domínios.
1.3.3.1 Entidade
Fora da modelagem de dados, a definição de entidade é algo que existe separado de outras coisas. Dentro da modelagem de dados, uma entidade é
algo sobre o qual uma organização coleta informações. As entidades às vezes são chamadas de substantivos de uma organização. Uma entidade pode
ser pensada como a resposta a uma pergunta fundamental – quem, o quê, quando, onde, por que ou como – ou a uma combinação dessas perguntas
(ver Capítulo 4). A Tabela 7 define e dá exemplos de categorias de entidades comumente usadas (Hoberman, 2009).
Tabela 7 Categorias de entidade comumente usadas
Categoria Definição Exemplos
Quem Pessoa ou organização de interesse. Ou seja, quem é importante Funcionário, Paciente, Jogador, Suspeito,
para o negócio? Muitas vezes, um 'quem' está associado a uma Cliente, Fornecedor, Estudante,
generalização de parte ou a uma função como Cliente ou Fornecedor. Passageiro, Concorrente, Autor
Pessoas ou organizações podem ter várias funções ou ser incluídas em
várias partes.
128 • DMBOK2
Categoria Definição Exemplos
o que Produto ou serviço de interesse da empresa. Muitas vezes, refere- Produto, Serviço, Matéria Prima,
se ao que a organização faz ou qual serviço ela fornece. Ou seja, o Bem acabado, Curso, Canção,
que é importante para o negócio? Fotografia, livro
Atributos para categorias, tipos, etc. são muito importantes aqui.
Quando Calendário ou intervalo de tempo de interesse da empresa. Hora, data, mês, trimestre, ano,
Ou seja, quando o negócio está em operação? Calendário, Semestre, Período Fiscal,
Minuto, Hora de Partida
Onde Local de interesse do empreendimento. A localização pode se referir a Endereço de correspondência, distribuição
lugares reais, bem como a lugares eletrônicos. Ou seja, onde os Ponto, URL do site, endereço IP
negócios são conduzidos?
Por que Evento ou transação de interesse da empresa. Esses eventos Encomenda, Devolução, Reclamação,
mantêm o negócio à tona. Ou seja, por que o negócio está no Retirada, depósito, elogio,
negócio? Consulta, Comércio, Reivindicação
Quão Documentação do evento de interesse do empreendimento. Fatura, Contrato, Acordo,

Os documentos fornecem a evidência de que os eventos Conta, Ordem de Compra, Aceleração
ocorreram, como um pedido de compra registrando um evento de Bilhete, Guia de Embalagem, Comércio
pedido. Ou seja, como sabemos que um evento ocorreu? Confirmação
Medição Contagens, somas, etc. das outras categorias (o quê, onde) em ou ao longo de Vendas, contagem de itens, pagamentos,
pontos no tempo (quando). Equilíbrio
1.3.3.1.1 Aliases de Entidade
A entidade de termo genérico pode ter outros nomes. O mais comum é o tipo entidade, pois um tipo de algo está sendo representado (por
exemplo, Jane é do tipo Employee), portanto Jane é a entidade e Employee é o tipo de entidade.
No entanto, em uso generalizado hoje está usando o termo entidade para Funcionário e instância de entidade para Jane.
Tabela 8 Entidade, Tipo de Entidade e Instância de Entidade
Uso Entidade Tipo de Entidade Instância de Entidade
Uso comum Jane Empregado
Funcionário de uso recomendado Jane
As instâncias de entidade são as ocorrências ou valores de uma determinada entidade. A entidade Student pode ter várias instâncias de
aluno, com nomes Bob Jones, Joe Jackson, Jane Smith e assim por diante. A entidade Curso pode ter instâncias de Fundamentos de
Modelagem de Dados, Geologia Avançada e Literatura Inglesa no Século XVII .
Os aliases de entidade também podem variar com base no esquema. (Os esquemas serão discutidos na Seção 1.3.4.) Em esquemas
relacionais, o termo entidade é frequentemente usado, em esquemas dimensionais, os termos dimensão e tabela de fatos são frequentemente usados.
em esquemas orientados a objetos, os termos classe ou objeto são frequentemente usados, em esquemas baseados em tempo, os termos
hub, satélite e link são usados com frequência, e em esquemas NoSQL, termos como documento ou nó são usados.
Os aliases de entidade também podem variar com base no nível de detalhe. (Os três níveis de detalhe serão discutidos na Seção 1.3.5.)
Uma entidade no nível conceitual pode ser chamada de conceito ou termo, uma entidade no nível lógico é chamada de entidade (ou um
termo diferente dependendo do esquema) , e no nível físico os termos variam com base na tecnologia de banco de dados, sendo o termo
mais comum tabela.
1.3.3.1.2 Representação Gráfica de Entidades
Nos modelos de dados, as entidades geralmente são representadas como retângulos (ou retângulos com bordas arredondadas) com seus
nomes dentro, como na Figura 29, onde há três entidades: Aluno, Curso e Instrutor.
Aluna Curso Instrutor
Figura 29 Entidades
1.3.3.1.3 Definição de Entidades
As definições de entidade são contribuições essenciais para o valor comercial de qualquer modelo de dados. Eles são Metadados principais.
Definições de alta qualidade esclarecem o significado do vocabulário de negócios e fornecem rigor às regras de negócios que governam os
relacionamentos entre entidades. Eles auxiliam os profissionais de negócios e de TI na tomada de decisões inteligentes de negócios e
design de aplicativos. As definições de dados de alta qualidade exibem três características essenciais:
• Clareza: A definição deve ser de fácil leitura e compreensão. Frases simples e bem escritas sem
siglas obscuras ou termos ambíguos inexplicáveis, como às vezes ou normalmente.
• Exatidão: A definição é uma descrição precisa e correta da entidade. As definições devem ser
revisados por especialistas nas áreas de negócios relevantes para garantir que sejam precisos.
• Completude: Todas as partes da definição estão presentes. Por exemplo, ao definir um código, exemplos
dos valores de código estão incluídos. Ao definir um identificador, o escopo de exclusividade é incluído no
definição.
1.3.3.2 Relacionamento
Um relacionamento é uma associação entre entidades (Chen, 1976). Um relacionamento captura as interações de alto nível entre entidades
conceituais, as interações detalhadas entre entidades lógicas e as restrições entre entidades físicas.
130 • DMBOK2
1.3.3.2.1 Aliases de Relacionamento
A relação de termo genérico pode ter outros nomes. Os aliases de relacionamento podem variar de acordo com o esquema. Em esquemas relacionais
o termo relacionamento é frequentemente usado, esquemas dimensionais o termo caminho de navegação é frequentemente usado, e em esquemas
NoSQL são usados termos como borda ou link , por exemplo. Os aliases de relacionamento também podem variar com base no nível de detalhe. Um
relacionamento nos níveis conceitual e lógico é chamado de relacionamento, mas um relacionamento no nível físico pode ser chamado por outros
nomes, como restrição ou referência, dependendo da tecnologia do banco de dados.
1.3.3.2.2 Representação Gráfica de Relacionamentos
Os relacionamentos são mostrados como linhas no diagrama de modelagem de dados. Consulte a Figura 30 para obter um exemplo de Engenharia da
Informação.
Instrutor
Ensinar
Participar
Aluna Curso
Figura 30 Relacionamentos
Neste exemplo, a relação entre Aluno e Curso captura a regra de que um Aluno pode participar de Cursos. A relação entre o Instrutor e o Curso
captura a regra de que um Instrutor pode ministrar Cursos. Os símbolos na linha (chamados de cardinalidade) capturam as regras em uma sintaxe
precisa. (Isso será explicado na Seção 1.3.3.2.3.) Um relacionamento é representado por meio de chaves estrangeiras em um banco de dados
relacional e por métodos alternativos para bancos de dados NoSQL, como bordas ou links.
1.3.3.2.3 Cardinalidade do Relacionamento
Em um relacionamento entre duas entidades, a cardinalidade captura quantos de uma entidade (instâncias de entidade) participam do relacionamento
com quantos da outra entidade. A cardinalidade é representada pelos símbolos que aparecem em ambas as extremidades de uma linha de
relacionamento. As regras de dados são especificadas e aplicadas por meio da cardinalidade. Sem cardinalidade, o máximo que se pode dizer sobre
um relacionamento é que duas entidades estão conectadas de alguma forma.
Para cardinalidade, as escolhas são simples: zero, um ou muitos. Cada lado de um relacionamento pode ter qualquer combinação de zero, um ou
muitos ('muitos' meios podem ser mais do que 'um'). Especificar zero ou um nos permite capturar se uma instância de entidade é ou não necessária
em um relacionamento. Especificar um ou muitos nos permite capturar quantos de uma instância específica participam de um determinado
relacionamento.
Esses símbolos de cardinalidade são ilustrados no seguinte exemplo de engenharia da informação de Estudante e
Curso.
Participar
Aluna Curso
Figura 31 Símbolos de Cardinalidade
As regras de negócio são:
• Cada Aluno pode frequentar um ou vários Cursos.
• Cada Curso pode ser frequentado por um ou vários Alunos.
1.3.3.2.4 Aridade dos Relacionamentos
O número de entidades em um relacionamento é a 'aridade' do relacionamento. As mais comuns são as relações unárias, binárias e
ternárias.
1.3.3.2.4.1 Relação Unária (Recursiva)
Um relacionamento unário (também conhecido como recursivo ou autorreferenciado) envolve apenas uma entidade. Um relacionamento
recursivo um-para-muitos descreve uma hierarquia, enquanto um relacionamento muitos-para-muitos descreve uma rede ou gráfico.
Em uma hierarquia, uma instância de entidade tem no máximo um pai (ou entidade de nível superior). Na modelagem relacional, as
entidades filhas estão em muitos lados do relacionamento, com as entidades pai em um lado do relacionamento. Em uma rede, uma
instância de entidade pode ter mais de um pai.
Por exemplo, um Curso pode exigir pré-requisitos. Se, para fazer o Workshop de Biologia, é necessário primeiro concluir a Aula de
Biologia, a Aula de Biologia é o pré-requisito para o Workshop de Biologia. Nos seguintes modelos de dados relacionais, que usam
notação de engenharia da informação, pode-se modelar esse relacionamento recursivo como uma hierarquia ou rede:
Exigir como pré-requisito
Curso
Figura 32 Relacionamento Unário - Hierarquia
Exigir como pré-requisito
Curso
Figura 33 Relação Unária - Rede

132 • DMBOK2
Este primeiro exemplo (Figura 32) é uma hierarquia e o segundo (Figura 33) é uma rede. No primeiro exemplo, o Workshop de
Biologia requer primeiro a Aula de Biologia e a Aula de Química. Uma vez que a Aula de Biologia é escolhida como pré-requisito para
o Workshop de Biologia, a Aula de Biologia não pode ser o pré-requisito para nenhum outro curso. O segundo exemplo permite que a
Aula de Biologia seja pré-requisito para outros cursos como
Nós vamos.
1.3.3.2.4.2 Relação Binária
Uma aridade de dois também é conhecida como binária. Um relacionamento binário, o mais comum em um diagrama de modelo de
dados tradicional, envolve duas entidades. A Figura 34, um diagrama de classes UML, mostra que tanto Student quanto Course são
entidades que participam de um relacionamento binário.
Aluna -Participar -Seja atendido por Curso
* *
Figura 34 Relação Binária
1.3.3.2.4.3 Relacionamento Ternário
Uma aridade de três, conhecida como ternária, é um relacionamento que inclui três entidades. Um exemplo de modelagem baseada
em fatos (notação de função de objeto) aparece na Figura 35. Aqui , o Aluno pode se inscrever em um Curso específico em um
determinado Semestre.
Semestre
Aluna Curso
Figura 35 Relacionamento Ternário
1.3.3.2.5 Chave Estrangeira
Uma chave estrangeira é usada em esquemas de modelagem de dados relacionais físicos e, às vezes, lógicos para representar um
relacionamento. Uma chave estrangeira pode ser criada implicitamente quando um relacionamento é definido entre duas entidades,
dependendo da tecnologia de banco de dados ou da ferramenta de modelagem de dados, e se as duas entidades envolvidas têm
dependências mútuas.
No exemplo mostrado na Figura 36, Registro contém duas chaves estrangeiras, Número do Aluno do Aluno e Código do Curso do
Curso. As chaves estrangeiras aparecem na entidade no lado múltiplo do relacionamento, geralmente chamado de entidade filha.
Aluno e Curso são entidades pai e Registro é a entidade filha.
Aluna Cadastro
Número de estudante
Curso
Número do Aluno (FK)
Código do Curso (FK) Código do curso
Nome do Aluno Registro
Sobrenome do aluno data de registro Se registrou Nome do curso
Data de Nascimento do Aluno
Figura 36 Chaves Estrangeiras
1.3.3.3 Atributo
Um atributo é uma propriedade que identifica, descreve ou mede uma entidade. Os atributos podem ter domínios, que serão discutidos na Seção
1.3.3.4. O correspondente físico de um atributo em uma entidade é uma coluna, campo, tag ou nó em uma tabela, visão, documento, gráfico ou
arquivo.
1.3.3.3.1 Representação Gráfica de Atributos
Em modelos de dados, os atributos são geralmente descritos como uma lista dentro do retângulo da entidade, conforme mostrado na Figura 37,
onde os atributos da entidade Aluno incluem Número do Aluno, Nome do Aluno, Sobrenome do Aluno,
e Data de Nascimento do Aluno.
Aluna
Nome do Aluno
Sobrenome do aluno
Figura 37 Atributos
1.3.3.3.2 Identificadores
Um identificador (também chamado de chave) é um conjunto de um ou mais atributos que define exclusivamente uma instância de uma entidade.
Esta seção define os tipos de chaves por construção (simples, composta, composta, substituta) e função (candidata, primária, alternativa).
1.3.3.3.2.1 Chaves tipo Construção
Uma chave simples é um atributo que identifica exclusivamente uma instância de entidade. Os Códigos Universais de Produto (UPCs) e os
Números de Identificação do Veículo (VINs) são exemplos de chaves simples. Uma chave substituta também é um exemplo de chave simples.
Uma chave substituta é um identificador exclusivo para uma tabela. Muitas vezes um contador e sempre gerado pelo sistema sem inteligência,
uma chave substituta é um número inteiro cujo significado não está relacionado ao seu valor de face. (Em outras palavras, um Identificador de
mês de 1 não pode representar janeiro.) As chaves substitutas servem a funções técnicas e não devem ser visíveis para os usuários finais de um
banco de dados. Eles permanecem nos bastidores para ajudar a manter a exclusividade, permitir uma navegação mais eficiente entre as
estruturas e facilitar a integração entre os aplicativos.

134 • DMBOK2
Uma chave composta é um conjunto de dois ou mais atributos que juntos identificam exclusivamente uma instância de entidade. Exemplos
são o número de telefone dos EUA (código de área + câmbio + número local) e número do cartão de crédito (ID do emissor + ID da conta +
dígito verificador).
Uma chave composta contém uma chave composta e pelo menos uma outra chave simples ou composta ou atributo não chave. Um exemplo
é uma chave em uma tabela de fatos multidimensional, que pode conter várias chaves compostas, chaves simples e, opcionalmente, um
carimbo de data/hora de carregamento.
1.3.3.3.2.2 Teclas de tipo de função
Uma superchave é qualquer conjunto de atributos que identificam exclusivamente uma instância de entidade. Uma chave candidata é um
conjunto mínimo de um ou mais atributos (ou seja, uma chave simples ou composta) que identifica a instância da entidade à qual ela pertence.
Mínimo significa que nenhum subconjunto da chave candidata identifica exclusivamente a instância da entidade. Uma entidade pode ter
várias chaves candidatas. Exemplos de chaves candidatas para uma entidade de cliente são endereço de e-mail, número de telefone celular
e número da conta do cliente. As chaves candidatas podem ser chaves de negócios (às vezes chamadas de chaves naturais). Uma chave
de negócios é um ou mais atributos que um profissional de negócios usaria para recuperar uma única instância de entidade.
Chaves de negócios e chaves substitutas são mutuamente exclusivas.
Uma chave primária é a chave candidata escolhida para ser o identificador exclusivo de uma entidade. Mesmo que uma entidade possa
conter mais de uma chave candidata, apenas uma chave candidata pode servir como chave primária para uma entidade. Uma chave
alternativa é uma chave candidata que, embora única, não foi escolhida como chave primária. Uma chave alternativa ainda pode ser usada
para localizar instâncias de entidade específicas. Muitas vezes, a chave primária é uma chave substituta e as chaves alternativas são chaves
comerciais.
1.3.3.3.2.3 Identificando vs. Não Identificando Relacionamentos
Uma entidade independente é aquela em que a chave primária contém apenas atributos que pertencem a essa entidade. Uma entidade
dependente é aquela em que a chave primária contém pelo menos um atributo de outra entidade. Em esquemas relacionais, a maioria das
notações descreve entidades independentes no diagrama de modelagem de dados como retângulos e entidades dependentes como
retângulos com cantos arredondados.
No exemplo de aluno mostrado na Figura 38, Aluno e Curso são entidades independentes e Registro é uma entidade dependente.
Aluna Cadastro
Curso
Número do Aluno (FK)
Código do Curso (FK) Código do curso
Nome do Aluno Registro
Sobrenome do aluno data de registro Se registrou Nome do curso
Figura 38 Entidade Dependente e Independente

As entidades dependentes têm pelo menos um relacionamento de identificação. Um relacionamento de identificação é aquele em que a chave primária
do pai (a entidade em um lado do relacionamento) é migrada como uma chave estrangeira para a chave primária do filho, como pode ser visto com o
relacionamento de Aluno para Registro e de Curso para
Cadastro. Em relacionamentos não identificadores, a chave primária do pai é migrada como um atributo de chave estrangeira não primária para o filho.
1.3.3.4 Domínio
Na modelagem de dados, um domínio é o conjunto completo de valores possíveis aos quais um atributo pode ser atribuído. Um domínio pode ser
articulado de diferentes maneiras (ver pontos no final desta seção). Um domínio fornece um meio de padronizar as características dos atributos. Por
exemplo, o domínio Data, que contém todas as datas válidas possíveis, pode ser atribuído a qualquer atributo de data em um modelo de dados lógico ou
colunas/campos de data em um modelo de dados físico, como:
• Data de Contratação do Funcionário
• OrderEntryDate
• Data de envio da reivindicação
• Data de início do curso
Todos os valores dentro do domínio são valores válidos. Aqueles fora do domínio são chamados de valores inválidos. Um
atributo não deve conter valores fora de seu domínio atribuído. EmployeeGenderCode, por exemplo, pode ser limitado ao domínio feminino e masculino.
O domínio para EmployeeHireDate pode ser definido simplesmente como datas válidas. Sob essa regra, o domínio para EmployeeHireDate não inclui
30 de fevereiro de nenhum ano.
Pode-se restringir um domínio com regras adicionais, chamadas restrições. As regras podem estar relacionadas ao formato, à lógica ou a ambos. Por
exemplo, restringindo o domínio EmployeeHireDate a datas anteriores à data de hoje, eliminaria 10 de março de 2050 do domínio de valores válidos,
mesmo que seja uma data válida. EmployeeHireDate também pode ser restrito a dias em uma semana de trabalho típica (por exemplo, datas que caem
em uma segunda, terça, quarta, quinta ou sexta).
Os domínios podem ser definidos de diferentes maneiras.
• Tipo de Dados: Domínios que especificam os tipos padrão de dados que se pode ter em um atributo atribuído a
esse domínio. Por exemplo, Integer, Character(30) e Date são todos domínios de tipo de dados.
• Formato de dados: domínios que usam padrões, incluindo modelos e máscaras, como os encontrados em
códigos e números de telefone e limitações de caracteres (somente alfanuméricos, alfanuméricos com certos
caracteres especiais permitidos, etc.) para definir valores válidos.
• Lista: Domínios que contêm um conjunto finito de valores. Estes são familiares para muitas pessoas da funcionalidade
como listas suspensas. Por exemplo, o domínio de lista para OrderStatusCode pode restringir valores a apenas
{Aberto, Enviado, Fechado, Devolvido}.

136 • DMBOK2
• Faixa: Domínios que permitem todos os valores do mesmo tipo de dados que estão entre um ou mais valores mínimos
e/ou valores máximos. Alguns intervalos podem ser abertos. Por exemplo, OrderDeliveryDate deve ser
entre OrderDate e três meses no futuro.
• Baseado em regras: Domínios definidos pelas regras que os valores devem obedecer para serem válidos. Esses
incluem regras que comparam valores com valores calculados ou outros valores de atributo em uma relação ou conjunto. Por
Por exemplo, ItemPrice deve ser maior que ItemCost.
1.3.4 Esquemas de Modelagem de Dados
Os seis esquemas mais comuns usados para representar dados são: Relacional, Dimensional, Orientado a Objetos, Baseado em Fatos, Baseado
em Tempo e NoSQL. Cada esquema usa notações de diagramação específicas (consulte a Tabela 9).
Tabela 9 Esquemas e Notações de Modelagem
Esquema Amostras de Notações
Relacional Engenharia da Informação (IE)

Definição de Integração para Modelagem de Informações (IDEF1X)
Notação de Barker
Chen
Dimensional Dimensional
Orientado a Objeto Linguagem de modelagem unificada (UML)

Baseado em fatos Modelagem de função de objeto (ORM ou ORM2)
Modelagem Totalmente Orientada à Comunicação (FCO-IM)
Com base no tempo Cofre de dados
Modelagem de âncoras
NoSQL Documento
Coluna
Gráfico
Valor chave
Esta seção explicará brevemente cada um desses esquemas e notações. O uso de esquemas depende em parte do banco de dados que está
sendo construído, pois alguns são adequados a tecnologias específicas, conforme mostrado na Tabela 10.
Para o esquema relacional, todos os três níveis de modelos podem ser construídos para RDBMS, mas apenas modelos conceituais e lógicos
podem ser construídos para os outros tipos de banco de dados. Isso também é verdade para o esquema baseado em fatos. Para o esquema
dimensional, todos os três níveis de modelos podem ser construídos para bancos de dados RDBMS e MDBMS. O esquema orientado a objetos
funciona bem para RDBMS e bancos de dados de objetos.
O esquema baseado em tempo é uma técnica de modelagem de dados físicos principalmente para data warehouses em um ambiente RDBMS. O
esquema NoSQL é fortemente dependente da estrutura do banco de dados subjacente (documento, coluna, gráfico ou valor-chave) e, portanto, é
uma técnica de modelagem de dados física. A Tabela 10 ilustra vários pontos importantes, incluindo que, mesmo com um banco de dados não
tradicional, como um baseado em documentos, um CDM e LDM relacional podem ser construídos seguidos por um PDM de documentos.
Tabela 10 Esquema para Referência Cruzada do Banco de Dados
Esquema
Gráfico
Coluna
(RDBMS) Documento
chave
Valor
objetos
Bancos
dados
de
Multidimensional
(MDBMS)
Sistema
relacional
Banco
dados
de
Sistema
gestão
de
Gerenciamento
dados
banco
de
Relacional MDL MDL MDL MDL MDL MDL MDL

PDM
Dimensional MDL MDL
LDM LDM
PDM PDM
MDL Orientado a Objetos MDL
LDM LDM
PDM PDM
Baseado em fatos MDL MDL MDL MDL MDL MDL MDL
PDM
Com base no tempo PDM
NoSQL PDM PDM PDM PDM PDM
1.3.4.1 Relacional
Articulada pela primeira vez pelo Dr. Edward Codd em 1970, a teoria relacional fornece uma maneira sistemática de organizar
os dados para que eles reflitam seu significado (Codd, 1970). Essa abordagem teve o efeito adicional de reduzir a redundância
no armazenamento de dados. O insight de Codd foi que os dados poderiam ser gerenciados com mais eficiência em termos de
relações bidimensionais . O termo relação foi derivado da matemática (teoria dos conjuntos) na qual sua abordagem foi baseada.
Os objetivos de design para o modelo relacional são ter uma expressão exata dos dados de negócios e ter um fato em
um só lugar (a remoção da redundância). A modelagem relacional é ideal para o projeto de sistemas operacionais, que
requerem a inserção rápida de informações e seu armazenamento preciso (Hay, 2011).
Existem vários tipos diferentes de notação para expressar a associação entre entidades na modelagem relacional,
incluindo Engenharia da Informação (IE), Definição de Integração para Modelagem de Informação (IDEF1X), Notação
Barker e Notação Chen. A forma mais comum é a sintaxe do IE, com seus tridentes familiares ou 'pés de galinha' para
representar a cardinalidade. (Veja a Figura 39.)
Participar
Aluna Curso
Figura 39 Notação do IE
138 • DMBOK2
1.3.4.2 Dimensional
O conceito de modelagem dimensional partiu de um projeto de pesquisa conjunto realizado pela General Mills e Dartmouth College
na década de 1960.33 Nos modelos dimensionais, os dados são estruturados para otimizar a consulta e análise de grandes
quantidades de dados. Por outro lado, os sistemas operacionais que suportam o processamento de transações são otimizados
para o processamento rápido de transações individuais.
Modelos de dados dimensionais capturam questões de negócios focadas em um processo de negócios específico. O processo
que está sendo medido no modelo dimensional da Figura 40 é Admissões. As admissões podem ser visualizadas pela Zona
o aluno é de origem, nome da escola, semestre e se o aluno está recebendo ajuda financeira. A navegação pode ser feita da Zona
até a Região e País, do Semestre até o Ano, e do Nome da Escola até a Escola
Nível.
Geografia
País
Região
Zona
Calendário Escola
Admissões
Ano Semestre Nível do nome
Sim não
Ajuda financeira
Figura 40 Notação de Eixo para Modelos Dimensionais
A notação de diagramação usada para construir este modelo – a 'notação de eixo' – pode ser uma ferramenta de comunicação
muito eficaz com aqueles que preferem não ler a sintaxe tradicional de modelagem de dados.
Os modelos de dados conceituais relacionais e dimensionais podem ser baseados no mesmo processo de negócios (como neste
exemplo com Admissões). A diferença está no significado dos relacionamentos, onde no modelo relacional as linhas de
relacionamento capturam as regras de negócios e no modelo dimensional capturam os caminhos de navegação necessários para
responder às questões de negócios.
33 http://bit.ly/2tsSP7w.
1.3.4.2.1 Tabelas de Fatos
Dentro de um esquema dimensional, as linhas de uma tabela de fatos correspondem a medidas específicas e são numéricas,
como quantidades, quantidades ou contagens. Algumas medidas são resultados de algoritmos, caso em que
Os metadados são críticos para a compreensão e uso adequados. As tabelas de fatos ocupam mais espaço no banco de dados
(90% é uma regra prática razoável) e tendem a ter um grande número de linhas.
1.3.4.2.2 Tabelas de Dimensões
As tabelas de dimensão representam os objetos importantes do negócio e contêm principalmente descrições textuais.
As dimensões servem como fonte primária para restrições de 'consulta por' ou 'relatório por', atuando como pontos de entrada ou
links nas tabelas de fatos. As dimensões são tipicamente altamente desnormalizadas e normalmente representam cerca de 10% do
os dados totais.
As dimensões devem ter um identificador exclusivo para cada linha. As duas principais abordagens para identificar chaves para
tabelas de dimensão são chaves substitutas e chaves naturais.
As dimensões também têm atributos que mudam em taxas diferentes. As dimensões de alteração lenta (SCDs) gerenciam as
alterações com base na taxa e no tipo de alteração. Os três principais tipos de mudança são por vezes conhecidos por ORC.
• Substituir (Tipo 1): O novo valor substitui o valor antigo em vigor.
• Nova Linha (Tipo 2): Os novos valores são escritos em uma nova linha e a linha antiga é marcada como não
atual.
• Nova Coluna (Tipo 3): Várias instâncias de um valor são listadas em colunas na mesma linha e uma
novo valor significa escrever os valores na série um ponto abaixo para abrir espaço na frente para o novo
valor. O último valor é descartado.
1.3.4.2.3 Floco de neve
Snowflaking é o termo dado para normalizar a estrutura dimensional plana, de tabela única, em um esquema em estrela nas
respectivas estruturas hierárquicas ou de rede de componentes.
1.3.4.2.4 Grão
O termo grão significa o significado ou descrição de uma única linha de dados em uma tabela de fatos; este é o maior detalhe que
qualquer linha terá. Definir a granulação de uma tabela de fatos é uma das principais etapas do projeto dimensional. Por exemplo,
se um modelo dimensional está medindo o processo de matrícula do aluno, o grão pode ser aluno, dia,
e classe.
140 • DMBOK2
1.3.4.2.5 Dimensões Conformadas
Dimensões conformadas são construídas tendo em mente toda a organização e não apenas um projeto em particular; isso permite que essas
dimensões sejam compartilhadas entre modelos dimensionais, por conter terminologia e valores consistentes. Por exemplo, se o Calendário for
uma dimensão conformada, um modelo dimensional criado para contar alunos candidatos por Semestre conterá os mesmos valores e definição
de Semestre que um modelo dimensional criado para contar alunos graduados.
1.3.4.2.6 Fatos Conformados
Fatos conformados usam definições padronizadas de termos em mercados individuais. Diferentes usuários de negócios podem usar o mesmo
termo de maneiras diferentes. 'Adições de clientes' podem ser diferentes de 'adições brutas' ou 'adições ajustadas'. Os desenvolvedores
precisam estar bem cientes de coisas que podem ter o mesmo nome, mas na verdade representam conceitos diferentes nas organizações ou,
inversamente, coisas que têm nomes diferentes, mas na verdade são o mesmo conceito em todas as organizações.
1.3.4.3 Orientado a Objetos (UML)
A Unified Modeling Language (UML) é uma linguagem gráfica para software de modelagem. A UML tem uma variedade de notações das quais
uma (o modelo de classe) diz respeito a bancos de dados. O modelo de classe UML especifica classes (tipos de entidade) e seus tipos de
relacionamento (Blaha, 2013).
Nome da classe Aluna

Atributos Stdntno : inteiro
Sttdt: data
Prgm: texto
Operações ExpctGraddt: data
ActlGraddt: data
Figura 41 Modelo de classe UML
A Figura 41 ilustra as características de um modelo de classe UML:
• Um diagrama de Classes se assemelha a um diagrama ER, exceto que a seção Operações ou Métodos não está presente
em ER.
• Em ER, o equivalente mais próximo de Operações seria Stored Procedures.
• Os tipos de atributo (por exemplo, Data, Minutos) são expressos na linguagem de código do aplicativo implementável e
não na terminologia implementável do banco de dados físico.
• Os valores padrão podem ser mostrados opcionalmente na notação.
• O acesso aos dados é feito através da interface exposta da classe. O encapsulamento ou ocultação de dados é baseado em um
'efeito de localização'. Uma classe e as instâncias que ela mantém são expostas por meio de Operações.
A classe tem Operações ou Métodos (também chamado de “comportamento”). O comportamento de classe está apenas vagamente
conectado à lógica de negócios porque ainda precisa ser sequenciado e cronometrado. Em termos de ER, a tabela tem stored procedures/
triggers.
As operações de classe podem ser:
• Público: visível externamente
• Visível Internamente: Visível para Objetos Filhos

• Privado: Oculto
Em comparação, os modelos ER Physical oferecem apenas acesso público; todos os dados são igualmente expostos a processos,
consultas ou manipulações.
1.3.4.4 Modelagem Baseada em Fatos (FBM)
A Modelagem Baseada em Fatos, uma família de linguagens de modelagem conceitual, originou-se no final da década de 1970. Essas
linguagens são baseadas na análise da verbalização natural (frases plausíveis) que podem ocorrer no domínio empresarial.
As linguagens baseadas em fatos veem o mundo em termos de objetos, os fatos que relacionam ou caracterizam esses objetos e cada
papel que cada objeto desempenha em cada fato. Um sistema de restrição extenso e poderoso se baseia na verbalização automática
fluente e na verificação automática em relação aos exemplos concretos. Modelos baseados em fatos não usam atributos, reduzindo a
necessidade de julgamento intuitivo ou especializado, expressando os relacionamentos exatos entre objetos (entidades e valores). A mais
amplamente utilizada das variantes FBM é o Object Role Modeling (ORM), que foi formalizado como uma lógica de primeira ordem por
Terry Halpin em 1989.
1.3.4.4.1 Modelagem de Função de Objeto (ORM ou ORM2)
O Object-Role Modeling (ORM) é uma abordagem de engenharia orientada a modelos que começa com exemplos típicos de informações
ou consultas necessárias apresentadas em qualquer formulação externa familiar aos usuários e, em seguida, verbaliza esses exemplos
no nível conceitual, em termos de fatos simples expressos em uma linguagem natural controlada. Esta linguagem é uma versão restrita da
linguagem natural que não é ambígua, então a semântica é facilmente compreendida pelos humanos; também é formal, por isso pode ser
usado para mapear automaticamente as estruturas para níveis inferiores para implementação (Halpin, 2015).
A Figura 42 ilustra um modelo ORM.
Semestre
Aluna Curso
… em … matriculado em …
Figura 42 Modelo ORM

142 • DMBOK2
1.3.4.4.2 Modelagem Totalmente Orientada à Comunicação (FCO-IM)
O FCO-IM é semelhante em notação e abordagem ao ORM. Os números da Figura 43 são referências a verbalizações de fatos. Por exemplo, 2 pode se
referir a várias verbalizações, incluindo “Aluno 1234 tem o primeiro nome Bill”.
Semestre
Aluna 4 56 Curso
Comparecimento
2 3
Figura 43 Modelo FCO-IM
1.3.4.5 Baseado no Tempo
Padrões baseados em tempo são usados quando os valores dos dados devem ser associados em ordem cronológica e com tempo específico
valores.
1.3.4.5.1 Cofre de Dados
O Data Vault é um conjunto de tabelas normalizadas orientadas a detalhes, baseadas em tempo e vinculadas exclusivamente que suportam uma ou
mais áreas funcionais de negócios. É uma abordagem híbrida, abrangendo o melhor da raça entre a terceira forma normal (3NF, a ser discutida na Seção
1.3.6) e o esquema em estrela. Os Data Vaults são projetados especificamente para atender às necessidades dos data warehouses corporativos. Existem
três tipos de entidades: hubs, links e satélites. O design do Data Vault é focado nas áreas funcionais de negócios com o hub representando a chave
primária. Os links fornecem integração de transações entre os hubs. Os satélites fornecem o contexto da chave primária do hub (Linstedt, 2012).
Na Figura 44, Aluno e Curso são hubs, que representam os principais conceitos de uma disciplina. O atendimento é um link, que relaciona dois hubs
entre si. O contato do aluno, as características do aluno e a descrição do curso são satélites que fornecem informações descritivas sobre os
conceitos do hub e podem oferecer suporte a vários tipos de histórico.
A modelagem de âncora é uma técnica adequada para informações que mudam ao longo do tempo tanto na estrutura quanto no conteúdo. Ele fornece
notação gráfica usada para modelagem conceitual semelhante à modelagem de dados tradicional, com extensões para trabalhar com dados temporais.
A modelagem de âncoras tem quatro conceitos básicos de modelagem: âncoras, atributos, laços,
e nós. As âncoras modelam entidades e eventos, atributos modelam propriedades de âncoras, laços modelam os relacionamentos
entre âncoras e nós são usados para modelar propriedades compartilhadas, como estados.
Aluna Comparecimento Curso
Aluna Aluna Curso

Contato Características Descrição
Figura 44 Modelo de Cofre de Dados
1.3.4.5.2 Modelagem de Âncora
No modelo âncora da Figura 45, Aluno, Curso e Presença são âncoras, os losangos cinzas representam empates e os círculos
representam atributos.
Figura 45 Modelo de âncora
1.3.4.6 NoSQL
NoSQL é um nome para a categoria de bancos de dados construídos em tecnologia não relacional. Alguns acreditam que NoSQL
não é um bom nome para o que representa, pois é menos sobre como consultar o banco de dados (que é onde entra o SQL) e
mais sobre como os dados são armazenados (que é onde entram as estruturas relacionais).
Existem quatro tipos principais de bancos de dados NoSQL: documento, valor-chave, orientado a colunas e gráfico.
144 • DMBOK2
1.3.4.6.1 Documento
Em vez de pegar um assunto de negócios e dividi-lo em várias estruturas relacionais, os bancos de dados de documentos
frequentemente armazenam o assunto de negócios em uma estrutura chamada documento. Por exemplo, em vez de armazenar
informações de Aluno, Curso e Registro em três estruturas relacionais distintas, as propriedades de todos os três existirão em
um único documento chamado Registro.
1.3.4.6.2 Valor-chave
Os bancos de dados de valores-chave permitem que um aplicativo armazene seus dados em apenas duas colunas ('chave' e
'valor'), com o recurso de armazenar informações simples (por exemplo, datas, números, códigos) e complexas (texto não
formatado, vídeo, música, documentos, fotos) armazenados na coluna 'valor'.
1.3.4.6.3 Orientado por coluna
Dos quatro tipos de bancos de dados NoSQL, o orientado a colunas é o mais próximo do RDBMS. Ambos têm uma maneira
semelhante de ver os dados como linhas e valores. A diferença, porém, é que os RDBMSs trabalham com uma estrutura
predefinida e tipos de dados simples, como valores e datas, enquanto bancos de dados orientados a colunas, como Cassandra,
podem trabalhar com tipos de dados mais complexos, incluindo texto e imagens não formatados. Além disso, orientado a colunas
os bancos de dados armazenam cada coluna em sua própria estrutura.
1.3.4.6.4 Gráfico
Um banco de dados de grafos é projetado para dados cujas relações são bem representadas como um conjunto de nós com um
número indeterminado de conexões entre esses nós. Exemplos em que um banco de dados gráfico pode funcionar melhor são
as relações sociais (onde os nós são pessoas), links de transporte público (onde os nós podem ser estações de ônibus ou trem)
ou mapas de estradas (onde os nós podem ser cruzamentos de ruas ou saídas de rodovias). Muitas vezes, os requisitos levam a
percorrer o grafo para encontrar as rotas mais curtas, os vizinhos mais próximos, etc., os quais podem ser complexos e demorados
para navegar com um RDMBS tradicional. Os bancos de dados gráficos incluem Neo4J, Allegro e Virtuoso.
1.3.5 Níveis de Detalhe do Modelo de Dados
Em 1975, o Comitê de Requisitos e Planejamento de Padrões do American National Standards Institute (SPARC) publicou sua
abordagem de três esquemas para gerenciamento de banco de dados. Os três componentes principais eram:
• Conceitual: Isso incorpora a visão do 'mundo real' da empresa que está sendo modelada no banco de dados. Isto
representa o atual 'melhor modelo' ou 'forma de fazer negócios' para a empresa.
• Externo: Os vários usuários do sistema de gerenciamento de banco de dados operam em subconjuntos do total
modelo empresarial que são relevantes para suas necessidades específicas. Esses subconjuntos são representados como 'externos
esquemas'.
• Interno: A 'visão de máquina' dos dados é descrita pelo esquema interno. Este esquema descreve
a representação armazenada das informações da empresa (Hay, 2011).
Esses três níveis geralmente se traduzem nos níveis de detalhe conceitual, lógico e físico, respectivamente. Dentro dos projetos, a modelagem de
dados conceituais e a modelagem de dados lógicos fazem parte das atividades de planejamento e análise de requisitos, enquanto a modelagem de
dados físicos é uma atividade de projeto. Esta seção fornece uma visão geral da modelagem de dados conceitual, lógica e física. Além disso, cada
nível será ilustrado com exemplos de dois esquemas: relacional e dimensional.
1.3.5.1 Conceitual
Um modelo de dados conceitual captura os requisitos de dados de alto nível como uma coleção de conceitos relacionados. Ele contém apenas as
entidades de negócios básicas e críticas dentro de um determinado domínio e função, com uma descrição de cada entidade e os relacionamentos
entre as entidades.
Por exemplo, se fôssemos modelar o relacionamento entre alunos e uma escola, como um modelo de dados conceitual relacional usando a notação
do IE, poderia se parecer com a Figura 46.
Escola
Conter
Enviar
Aluna Inscrição
Figura 46 Modelo Conceitual Relacional
Cada Escola pode conter um ou vários Alunos, e cada Aluno deve vir de uma Escola. Além disso, cada Aluno pode enviar uma ou várias
Inscrições, e cada Inscrição deve ser enviada por um Aluno.
As linhas de relacionamento capturam regras de negócios em um modelo de dados relacional. Por exemplo, Bob, o aluno, pode frequentar a County
High School ou a Queens College, mas não pode cursar ambas ao se inscrever nessa universidade em particular. Além disso, um pedido deve ser
apresentado por um único aluno, não dois e não zero.
Lembre-se da Figura 40, que é reproduzida abaixo como Figura 47. Este modelo de dados conceitual dimensional usando a notação Axis, ilustra
conceitos relacionados à escola:

146 • DMBOK2
Geografia
País
Região
Zona
Calendário Escola
Admissões
Ano Semestre Nível do nome
Sim não
Ajuda financeira
Figura 47 Modelo Conceitual Dimensional
1.3.5.2 Lógico
Um modelo de dados lógico é uma representação detalhada de requisitos de dados, geralmente em suporte a um contexto de uso
específico, como requisitos de aplicativos. Os modelos de dados lógicos ainda são independentes de qualquer tecnologia ou restrições
de implementação específicas. Um modelo de dados lógico geralmente começa como uma extensão de um modelo de dados conceitual.
modelo.
Em um modelo de dados lógico relacional, o modelo de dados conceitual é estendido adicionando atributos. Os atributos são atribuídos
às entidades aplicando a técnica de normalização (consulte a Seção 1.3.6), conforme mostrado na Figura 48. Existe uma relação
muito forte entre cada atributo e a chave primária da entidade na qual ele reside. Por exemplo, o nome da escola tem uma forte
relação com o código da escola. Por exemplo, cada valor de um Código Escolar
traz de volta no máximo um valor de um nome de escola.
Escola
Código escolar
Nome da escola
Conter
Aluna
Inscrição
Código Escolar (FK)
Enviar Número do aplicativo
Nome do Aluno
Sobrenome do aluno Número do Aluno (FK)
Data de Nascimento do Aluno Data de envio do aplicativo
Figura 48 Modelo de dados lógicos relacionais

Um modelo de dados lógicos dimensionais é, em muitos casos, uma perspectiva totalmente atribuída do modelo de dados
conceituais dimensionais, conforme ilustrado na Figura 49. Enquanto o modelo de dados relacionais lógicos captura as regras
de negócios de um processo de negócios, o dimensional lógico captura as questões de negócios para determinar a integridade
e o desempenho de um processo de negócios.
Contagem de Admissões na Figura 49 é a medida que responde às perguntas de negócios relacionadas a Admissões. As
entidades que cercam as Admissões fornecem o contexto para visualizar a Contagem de Admissões em diferentes níveis de
granularidade, como por Semestre e Ano.
Figura 49 Modelo de dados lógicos dimensionais

148 • DMBOK2
1.3.5.3 Físico
Um modelo de dados físico (PDM) representa uma solução técnica detalhada, geralmente usando o modelo de dados lógico como
ponto de partida e depois adaptado para funcionar dentro de um conjunto de ferramentas de hardware, software e rede. Modelos
de dados físicos são construídos para uma tecnologia específica. DBMSs relacionais, por exemplo, devem ser projetados tendo em
mente os recursos específicos de um sistema de gerenciamento de banco de dados (por exemplo, IBM DB2, UDB, Oracle, Teradata,
Sybase, Microsoft SQL Server ou Microsoft Access).
A Figura 50 ilustra um modelo de dados físicos relacionais. Nesse modelo de dados, a Escola foi desnormalizada na entidade
Aluno para acomodar uma tecnologia específica. Talvez sempre que um Aluno for acessado, suas informações escolares também
sejam e, portanto, armazenar informações escolares com Aluno seja uma estrutura de melhor desempenho do que ter duas
estruturas separadas.
ALUNA
STUDENT_NUM
STUDENT_FIRST_NAM INSCRIÇÃO
STUDENT_LAST_NAM Enviar APPLICATION_NUM

STUDENT_BIRTH_DT
ESCOLA_CD STUDENT_NUM (FK)
SCHOOL_NAM APPLICATION_SUBMISSION_DT
Figura 50 Modelo de dados físicos relacionais
Como o modelo de dados físicos acomoda limitações de tecnologia, as estruturas geralmente são combinadas (desnormalizadas)
para melhorar o desempenho de recuperação, conforme mostrado neste exemplo com Student e School.
A Figura 51 ilustra um modelo de dados físico dimensional (geralmente um esquema em estrela, o que significa que há uma
estrutura para cada dimensão).
Semelhante ao modelo de dados físicos relacionais, essa estrutura foi modificada de sua contraparte lógica para trabalhar com uma
tecnologia específica para garantir que as questões de negócios possam ser respondidas com simplicidade e rapidez.
1.3.5.3.1 Canônico
Uma variante de um esquema físico é um modelo canônico, usado para dados em movimento entre sistemas. Este modelo descreve
a estrutura de dados sendo passados entre sistemas como pacotes ou mensagens. Ao enviar dados por meio de serviços da Web,
um Enterprise Service Bus (ESB) ou por meio de Enterprise Application Integration (EAI), o modelo canônico descreve qual estrutura
de dados o serviço de envio e quaisquer serviços de recebimento devem usar.
Essas estruturas devem ser projetadas para serem tão genéricas quanto possível para permitir a reutilização e simplificar os
requisitos de interface.
Essa estrutura só pode ser instanciada como um buffer ou estrutura de fila em um sistema de mensagens intermediário (middleware)
para manter o conteúdo da mensagem temporariamente.
Figura 51 Modelo de Dados Físicos Dimensionais
1.3.5.3.2 Visualizações
Uma visão é uma tabela virtual. As exibições fornecem um meio de examinar os dados de uma ou várias tabelas que contêm ou fazem referência aos atributos reais.
Uma exibição padrão executa o SQL para recuperar dados no momento em que um atributo na exibição é solicitado. Uma visualização instanciada (geralmente
chamada de 'materializada') é executada em um tempo predeterminado. As visualizações são usadas para simplificar consultas, controlar o acesso a dados e renomear
colunas, sem redundância e perda de integridade referencial devido à desnormalização.
1.3.5.3.3 Particionamento
Particionamento refere-se ao processo de dividir uma tabela. É realizado para facilitar o arquivamento e melhorar o desempenho da recuperação. O particionamento
pode ser vertical (separando grupos de colunas) ou horizontal (separando grupos de linhas).
• Dividir verticalmente: para reduzir conjuntos de consultas, crie tabelas de subconjuntos que contenham subconjuntos de colunas. Por
Por exemplo, divida uma tabela de clientes em duas com base no fato de os campos serem principalmente estáticos ou voláteis
(para melhorar o desempenho de carga/índice) ou com base no fato de os campos serem comuns ou incomuns
incluído nas consultas (para melhorar o desempenho da verificação da tabela).

150 • DMBOK2
• Divisão horizontal: para reduzir conjuntos de consultas, crie tabelas de subconjuntos usando o valor de uma coluna como
diferenciador. Por exemplo, crie tabelas de clientes regionais que contenham apenas clientes em um
região.
1.3.5.3.4 Desnormalização
A desnormalização é a transformação deliberada de entidades de modelo de dados lógicos normalizados em tabelas físicas com estruturas de dados
redundantes ou duplicadas. Em outras palavras, a desnormalização coloca intencionalmente um atributo em vários lugares. Há vários motivos para
desnormalizar dados. A primeira é melhorar o desempenho:
• Combinar dados de várias outras tabelas com antecedência para evitar junções caras em tempo de execução
• Criação de cópias de dados menores e pré-filtradas para reduzir cálculos dispendiosos de tempo de execução e/ou varreduras de tabela de
mesas grandes
• Pré-cálculo e armazenamento de cálculos de dados caros para evitar a competição de recursos do sistema em tempo de execução
A desnormalização também pode ser usada para reforçar a segurança do usuário, segregando dados em várias visualizações ou cópias de tabelas de
acordo com as necessidades de acesso.
Esse processo apresenta um risco de erros de dados devido à duplicação. Portanto, a desnormalização é frequentemente escolhida se estruturas
como visualizações e partições não conseguirem produzir um design físico eficiente. É uma boa prática implementar verificações de qualidade de
dados para garantir que as cópias dos atributos sejam armazenadas corretamente. Em geral, desnormalize apenas para melhorar o desempenho da
consulta do banco de dados ou para facilitar a aplicação da segurança do usuário.
Embora o termo desnormalização seja usado nesta seção, o processo não se aplica apenas aos modelos de dados relacionais. Por exemplo, pode-se
desnormalizar em um banco de dados de documentos, mas seria chamado de algo diferente – como incorporação.
Na modelagem de dados dimensionais, a desnormalização é chamada de colapso ou combinação. Se cada dimensão for recolhida em uma única
estrutura, o modelo de dados resultante será chamado de Star Schema (consulte a Figura 51). Se as dimensões não forem recolhidas, o modelo de
dados resultante será chamado de Snowflake (consulte a Figura 49).
1.3.6 Normalização
A normalização é o processo de aplicação de regras para organizar a complexidade do negócio em estruturas de dados estáveis. O objetivo básico da
normalização é manter cada atributo em apenas um local para eliminar a redundância e as inconsistências que podem resultar da redundância. O
processo requer uma compreensão profunda de cada atributo e do relacionamento de cada atributo com sua chave primária.
As regras de normalização classificam os atributos de acordo com as chaves primárias e estrangeiras. As regras de normalização são classificadas em
níveis, com cada nível aplicando granularidade e especificidade na busca das chaves primárias e estrangeiras corretas. Cada nível
compreende uma forma normal separada, e cada nível sucessivo não precisa incluir níveis anteriores.
Os níveis de normalização incluem:
• Primeira forma normal (1NF): Garante que cada entidade tenha uma chave primária válida e cada atributo depende
a chave primária; remove grupos repetidos e garante que cada atributo seja atômico (não multivalorado).
A 1NF inclui a resolução de relacionamentos muitos-para-muitos com uma entidade adicional frequentemente chamada de
entidade associativa.
• Segunda forma normal (2NF): Garante que cada entidade tenha a chave primária mínima e que cada atributo
depende da chave primária completa.
• Terceira forma normal (3NF): Garante que cada entidade não tenha chaves primárias ocultas e que cada atributo
não depende de nenhum atributo fora da chave (“a chave, a chave inteira e nada além da chave”).
• Forma normal Boyce / Codd (BCNF): Resolve sobreposição de chaves candidatas compostas. Um candidato
key é uma chave primária ou uma chave alternativa. 'Composto' significa mais de um (ou seja, dois ou mais
atributos nas chaves primárias ou alternativas de uma entidade) e 'sobreposição' significa que há negócios ocultos
regras entre as teclas.
• Quarta forma normal (4NF): Resolve todos os relacionamentos muitos-para-muitos-para-muitos (e além) em pares
até que eles não possam ser divididos em pedaços menores.
• Quinta forma normal (5NF): Resolve dependências entre entidades em pares básicos e todos se unem
dependências usam partes de chaves primárias.
O termo modelo normalizado geralmente significa que os dados estão na 3NF. Situações que requerem BCNF, 4NF e 5NF ocorrem
raramente.
1.3.7 Abstração
Abstração é a remoção de detalhes de forma a ampliar a aplicabilidade a uma ampla classe de situações, preservando as propriedades
importantes e a natureza essencial de conceitos ou assuntos. Um exemplo de abstração é a estrutura Party/Role , que pode ser usada
para capturar como pessoas e organizações desempenham determinados papéis (por exemplo, funcionário e cliente). Nem todos os
modeladores ou desenvolvedores se sentem confortáveis ou têm a capacidade de trabalhar com abstração. O modelador precisa pesar o
custo de desenvolver e manter uma estrutura abstrata versus a quantidade de retrabalho necessária se a estrutura não abstrata precisar
ser modificada no futuro (Giles 2011).
Abstração inclui generalização e especialização. A generalização agrupa os atributos e relacionamentos comuns das entidades em
entidades de supertipo , enquanto a especialização separa os atributos distintivos dentro de um
entidade em entidades de subtipo . Essa especialização geralmente é baseada em valores de atributo em uma instância de entidade.
Os subtipos também podem ser criados usando funções ou classificação para separar instâncias de uma entidade em grupos por função.
Um exemplo é Party, que pode ter subtipos de Individual e Organization.

152 • DMBOK2
O relacionamento de subtipagem implica que todas as propriedades do supertipo são herdadas pelo subtipo. No exemplo relacional mostrado na
Figura 52, Universidade e Ensino Médio são subtipos de Escola.
Escola
Conter
Universidade
Ensino médio
Aluna Enviar
Inscrição
Figura 52 Relacionamentos de supertipo e subtipo
A subtipagem reduz a redundância em um modelo de dados. Também facilita a comunicação de semelhanças entre o que de outra forma pareceria
ser entidades distintas e separadas.
2. Atividades
Esta seção cobrirá brevemente as etapas para construir modelos de dados conceituais, lógicos e físicos, bem como manter e revisar modelos de
dados. Tanto a engenharia direta quanto a engenharia reversa serão discutidas.
2.1 Plano para Modelagem de Dados
Um plano para modelagem de dados contém tarefas como avaliar os requisitos organizacionais, criar padrões e determinar o armazenamento do
modelo de dados.
As entregas do processo de modelagem de dados incluem:
• Diagrama: Um modelo de dados contém um ou mais diagramas. O diagrama é o visual que captura os requisitos de forma precisa.
Ele descreve um nível de detalhe (por exemplo, conceitual, lógico ou físico), um esquema (relacional, dimensional, orientado a
objetos, baseado em fatos, baseado em tempo ou NoSQL) e uma notação dentro desse esquema (por exemplo, informações
engenharia, linguagem de modelagem unificada, modelagem de função de objeto).
• Definições: As definições de entidades, atributos e relacionamentos são essenciais para manter o
precisão em um modelo de dados.
• Questões e questões pendentes: Frequentemente, o processo de modelagem de dados levanta questões e questões que podem não
ser abordadas durante a fase de modelagem de dados. Além disso, muitas vezes as pessoas ou grupos responsáveis por resolver
esses problemas ou responder a essas perguntas residem fora do grupo que constrói o modelo de dados. Portanto, muitas vezes é
entregue um documento que contém o conjunto atual de questões e questões pendentes. Um exemplo de uma questão pendente para
o modelo de estudante pode ser: “Se um

O aluno sai e depois retorna, eles recebem um número de aluno diferente ou mantêm seu número de aluno original?”
• Linhagem: Para modelos de dados físicos e às vezes lógicos, é importante conhecer a linhagem de dados, que
é, de onde os dados vêm. Muitas vezes a linhagem assume a forma de um mapeamento de origem/destino, onde se pode
capturar os atributos do sistema de origem e como eles preenchem os atributos do sistema de destino. A linhagem pode
também rastrear os componentes de modelagem de dados de conceitual para lógico para físico dentro do mesmo
esforço de modelagem. Há duas razões pelas quais a linhagem é importante para capturar durante a modelagem de dados.
Primeiro, o modelador de dados obterá uma compreensão muito forte dos requisitos de dados e, portanto,
na melhor posição para determinar os atributos de origem. Em segundo lugar, determinar os atributos de origem pode ser
uma ferramenta eficaz para validar a precisão do modelo e do mapeamento (ou seja, uma verificação da realidade).
2.2 Construir o Modelo de Dados
Para construir os modelos, os modeladores geralmente dependem muito de análises e trabalhos de modelagem anteriores. Eles podem
estudar modelos de dados e bancos de dados existentes, consultar padrões publicados e incorporar quaisquer requisitos de dados. Depois
de estudar essas entradas, eles começam a construir o modelo. A modelagem é um processo muito iterativo (Figura 53). Os modeladores
elaboram o modelo e, em seguida, retornam aos profissionais de negócios e analistas de negócios para esclarecer os termos e as regras
de negócios. Eles então atualizam o modelo e fazem mais perguntas (Hoberman, 2014).
Provocar
Faça mais perguntas Aumente a precisão
Documento
Figura 53 A modelagem é iterativa
2.2.1 Engenharia Avançada
A engenharia avançada é o processo de construção de uma nova aplicação começando com os requisitos. O MDL é concluído primeiro
para entender o escopo da iniciativa e a terminologia chave dentro desse escopo. Em seguida, o LDM é concluído para documentar a
solução de negócios, seguido pelo PDM para documentar a solução técnica.
2.2.1.1 Modelagem de Dados Conceituais
A criação do CDM envolve as seguintes etapas:

154 • DMBOK2
• Selecionar Esquema: Decida se o modelo de dados deve ser construído seguindo um esquema relacional, dimensional, baseado
em fatos ou NoSQL. Consulte a discussão anterior sobre esquema e quando escolher cada
esquema (ver Seção 1.3.4).
• Selecionar Notação: Depois que o esquema for selecionado, escolha a notação apropriada, como informações
engenharia ou modelagem de papéis de objetos. A escolha de uma notação depende dos padrões dentro de uma organização e
da familiaridade dos usuários de um determinado modelo com uma determinada notação.
• MDL inicial completo: O MDL inicial deve capturar o ponto de vista de um grupo de usuários. Não deve complicar o processo
tentando descobrir como seu ponto de vista se encaixa com outros departamentos ou com a organização como um todo.
o Colete os conceitos de nível mais alto (substantivos) que existem para a organização. Conceitos comuns são Tempo,
Geografia, Cliente/Membro/Cliente, Produto/Serviço e Transação. o Em seguida, colete as atividades (verbos)
que conectam esses conceitos. Os relacionamentos podem ir nos dois sentidos ou envolver mais de dois conceitos. Os
exemplos são: Os clientes têm várias localizações geográficas (casa, trabalho, etc.), as localizações geográficas
têm muitos clientes.
As transações ocorrem ao mesmo tempo, em uma Instalação, para um Cliente, vendendo um Produto.
• Incorporar terminologia empresarial: uma vez que o modelador de dados capturou a visão dos usuários no
caixas e linhas, o modelador de dados captura a perspectiva da empresa, garantindo a consistência com a terminologia e as regras
da empresa. Por exemplo, haveria algum trabalho de reconciliação envolvido se o modelo de dados conceitual do público tivesse
uma entidade chamada Cliente e a perspectiva corporativa chamasse esse mesmo conceito de Cliente.
• Obter aprovação: após a conclusão do modelo inicial, verifique se o modelo foi revisado para obter dados
as melhores práticas de modelagem, bem como sua capacidade de atender aos requisitos. Geralmente verificação de e-mail que
o modelo parece preciso será suficiente.
2.2.1.2 Modelagem de Dados Lógicos
Um modelo de dados lógicos (LDM) captura os requisitos de dados detalhados dentro do escopo de um CDM.
2.2.1.2.1 Analisar Requisitos de Informação
Para identificar os requisitos de informação, deve-se primeiro identificar as necessidades de informação do negócio, no contexto de um ou mais
processos de negócio. Como entrada, os processos de negócios requerem produtos de informação que são eles próprios a saída de outros
processos de negócios. Os nomes desses produtos de informação geralmente identificam um vocabulário de negócios essencial que serve
como base para a modelagem de dados. Independentemente de os processos ou dados serem modelados sequencialmente (em qualquer
ordem) ou simultaneamente, a análise e o design eficazes devem garantir uma visão relativamente equilibrada de dados (substantivos) e
processos (verbos), com igual ênfase no processo e na modelagem de dados.

A análise de requisitos inclui a elicitação, organização, documentação, revisão, refinamento, aprovação e controle de mudanças dos requisitos
de negócios. Alguns desses requisitos identificam as necessidades de negócios de dados e informações. Expressar especificações de
requisitos em palavras e diagramas.
A modelagem de dados lógicos é um meio importante de expressar os requisitos de dados de negócios. Para muitas pessoas, como diz o
velho ditado, 'uma imagem vale mais que mil palavras'. No entanto, algumas pessoas não se identificam facilmente com imagens; eles se
relacionam melhor com relatórios e tabelas criados por ferramentas de modelagem de dados.
Muitas organizações têm requisitos formais. O gerenciamento pode orientar a elaboração e o refinamento de declarações formais de requisitos,
como “O sistema deve…” Documentos escritos de especificação de requisitos de dados podem ser mantidos usando ferramentas de
gerenciamento de requisitos. As especificações reunidas através do conteúdo de qualquer documentação devem ser cuidadosamente
sincronizadas com os requisitos capturados com modelos de dados para facilitar a análise de impacto para que se possa responder a
perguntas como “Quais partes dos meus modelos de dados representam ou implementam o Requisito X?” ou "Por que esta entidade está
aqui?"
2.2.1.2.2 Analisar a Documentação Existente
Muitas vezes, pode ser um ótimo começo usar artefatos de dados pré-existentes, incluindo modelos de dados e bancos de dados já
construídos. Mesmo que os modelos de dados estejam desatualizados, as peças podem ser úteis para iniciar um novo modelo. Certifique-se no entanto,
que qualquer trabalho feito com base em artefatos existentes seja validado pelas PMEs quanto à precisão e atualização. As empresas
costumam usar aplicativos empacotados, como sistemas de planejamento de recursos empresariais (ERP), que possuem seus próprios
modelos de dados. A criação do LDM deve levar em consideração esses modelos de dados e usá-los, quando aplicável, ou mapeá-los para o
novo modelo de dados corporativos. Além disso, pode haver padrões úteis de modelagem de dados, como uma maneira padrão de modelar o
conceito Party Role. Vários modelos de dados do setor capturam como um setor genérico, como varejo ou manufatura, deve ser modelado.
Esses padrões ou modelos de dados do setor podem ser personalizados para funcionar para um projeto ou iniciativa específica.
2.2.1.2.3 Adicionar Entidades Associativas
Entidades associativas são usadas para descrever relacionamentos muitos-para-muitos (ou muitos-para-muitos-para-muitos, etc.). Uma
entidade associativa pega os atributos de identificação das entidades envolvidas no relacionamento e os coloca em uma nova entidade que
apenas descreve o relacionamento entre as entidades. Isso permite a adição de atributos para descrever esse relacionamento, como datas de
vigência e validade. As entidades associativas podem ter mais de dois pais. Entidades associativas podem se tornar nós em bancos de dados
de grafos. Na modelagem dimensional, as entidades associativas geralmente se tornam tabelas de fatos.
2.2.1.2.4 Adicionar Atributos
Adicione atributos às entidades conceituais. Um atributo em um modelo de dados lógico deve ser atômico. Deve conter um e apenas um dado
(fato) que não pode ser dividido em pedaços menores. Por exemplo, um conceito
156 • DMBOK2
O atributo chamado número de telefone se divide em vários atributos lógicos para código de tipo de telefone (residencial, escritório,
fax, celular etc.), código do país (1 para EUA e Canadá), código de área, prefixo, número de telefone base e ramal.
2.2.1.2.5 Atribuir Domínios
Os domínios, que foram discutidos na Seção 1.3.3.4, permitem consistência no formato e conjuntos de valores dentro e entre projetos.
O valor da mensalidade do aluno e o valor do salário do instrutor podem ser atribuídos ao valor
domínio, por exemplo, que será um domínio de moeda padrão.
2.2.1.2.6 Atribuir Chaves
Atributos atribuídos a entidades são atributos chave ou não chave. Um atributo de chave ajuda a identificar uma instância de entidade
exclusiva de todas as outras, totalmente (por si só) ou parcialmente (em combinação com outros elementos-chave).
Atributos não-chave descrevem a instância da entidade, mas não ajudam a identificá-la exclusivamente. Identifique as chaves
primárias e alternativas.
2.2.1.3 Modelagem de Dados Físicos
Os modelos de dados lógicos exigem modificações e adaptações para que o design resultante tenha um bom desempenho nos
aplicativos de armazenamento. Por exemplo, as alterações necessárias para acomodar o Microsoft Access seriam diferentes das
alterações necessárias para acomodar o Teradata. Daqui para frente, o termo tabela será usado para se referir a tabelas, arquivos e
esquemas; o termo coluna para se referir a colunas, campos e elementos; e o termo linha para se referir a linhas, registros ou
instâncias.
2.2.1.3.1 Resolver abstrações lógicas
Entidades de abstração lógica (supertipos e subtipos) tornam-se objetos separados no design do banco de dados físico usando um
dos dois métodos.
• Absorção de subtipo: os atributos de entidade de subtipo são incluídos como colunas anuláveis em uma tabela
representando a entidade supertipo.
• Partição de supertipo: os atributos da entidade de supertipo são incluídos em tabelas separadas criadas para cada
subtipo.
2.2.1.3.2 Adicionar Detalhes do Atributo
Adicione detalhes ao modelo físico, como o nome técnico de cada tabela e coluna (bancos de dados relacionais), ou arquivo e campo
(bancos de dados não relacionais), ou esquema e elemento (bancos de dados XML).
Defina o domínio físico, o tipo de dados físico e o comprimento de cada coluna ou campo. Adicione restrições apropriadas (por exemplo, nulidade e
valores padrão) para colunas ou campos, especialmente para restrições NOT NULL.
2.2.1.3.3 Adicionar Objetos de Dados de Referência
Pequenos conjuntos de valores de dados de referência no modelo de dados lógicos podem ser implementados em um modelo físico em três
maneiras comuns:
• Crie uma tabela de códigos separada correspondente: dependendo do modelo, elas podem ser incontroláveis
numerosos.
• Crie uma tabela de códigos compartilhados mestre: para modelos com um grande número de tabelas de códigos, isso pode ser recolhido
-los em uma tabela; no entanto, isso significa que uma alteração em uma lista de referência alterará todo o
tabela. Tome cuidado para evitar também colisões de valores de código.
• Incorpore regras ou códigos válidos na definição do objeto apropriado: crie uma restrição no
código de definição de objeto que incorpora a regra ou lista. Para listas de códigos que são usadas apenas como referência para um
outro objeto, esta pode ser uma boa solução.
2.2.1.3.4 Atribuir Chaves Substitutas
Atribua valores de chave exclusivos que não são visíveis para a empresa e não têm significado ou relação com os dados com os quais são correspondidos.
Esta é uma etapa opcional e depende principalmente se a chave natural é grande, composta e cujos atributos são valores atribuídos que podem mudar
ao longo do tempo.
Se uma chave substituta for designada para ser a chave primária de uma tabela, certifique-se de que haja uma chave alternativa na chave primária
original. Por exemplo, se no LDM a chave primária do Aluno for Nome do Aluno, Sobrenome do Aluno e Data de Nascimento do Aluno (ou seja, uma
chave primária composta), no PDM a chave primária do Aluno pode ser a chave substituta ID do Aluno. Nesse caso, deve haver uma chave alternativa
definida na chave primária original de Nome do Aluno, Sobrenome do Aluno e Data de Nascimento do Aluno.
2.2.1.3.5 Desnormalizar para Desempenho
Em algumas circunstâncias, desnormalizar ou adicionar redundância pode melhorar tanto o desempenho que supera o custo do armazenamento
duplicado e do processamento de sincronização. As estruturas dimensionais são as principais

meio de desnormalização.
2.2.1.3.6 Índice de Desempenho
Um índice é um caminho alternativo para acessar dados no banco de dados para otimizar o desempenho da consulta (recuperação de dados).
A indexação pode melhorar o desempenho da consulta em muitos casos. O administrador de banco de dados ou desenvolvedor de banco de dados deve
158 • DMBOK2
selecione e defina índices apropriados para tabelas de banco de dados. Os principais produtos RDBMS suportam muitos tipos de índices.
Os índices podem ser exclusivos ou não exclusivos, agrupados ou não agrupados, particionados ou não particionados, coluna única ou
várias colunas, árvore b ou bitmap ou hash. Sem um índice apropriado, o DBMS voltará a ler todas as linhas da tabela (varredura de tabela)
para recuperar quaisquer dados. Em mesas grandes, isso é muito caro. Tente criar índices em tabelas grandes para dar suporte às
consultas executadas com mais frequência, usando as colunas referenciadas com mais frequência, principalmente chaves (primárias,
alternativas e estrangeiras).
2.2.1.3.7 Partição para Desempenho
Grande consideração deve ser dada à estratégia de particionamento do modelo de dados geral (dimensional), especialmente quando os
fatos contêm muitas chaves dimensionais opcionais (esparsas). Idealmente, o particionamento em uma chave de data é recomendado;
quando isso não for possível, é necessário um estudo baseado em resultados de perfil e análise de carga de trabalho para propor e refinar
o modelo de particionamento subsequente.
2.2.1.3.8 Criar Visualizações
As exibições podem ser usadas para controlar o acesso a determinados elementos de dados ou para incorporar condições ou filtros
comuns de junção para padronizar objetos ou consultas comuns. As próprias visualizações devem ser orientadas por requisitos. Em muitos
casos, eles precisarão ser desenvolvidos por meio de um processo que espelhe o desenvolvimento do LDM e do PDM.
2.2.2 Engenharia Reversa
A engenharia reversa é o processo de documentar um banco de dados existente. O PDM é concluído primeiro para entender o projeto
técnico de um sistema existente, seguido por um LDM para documentar a solução de negócios que o sistema existente atende, seguido
pelo CDM para documentar o escopo e a terminologia chave dentro do sistema existente. A maioria das ferramentas de modelagem de
dados oferece suporte à engenharia reversa de uma variedade de bancos de dados; no entanto, a criação de um layout legível dos
elementos do modelo ainda requer um modelador. Existem vários layouts comuns (ortogonal, dimensional e hierárquico) que podem ser
selecionados para iniciar o processo, mas a organização contextual (agrupamento de entidades por área de assunto ou função) ainda é
em grande parte um processo manual.
2.3 Revise os Modelos de Dados
Assim como outras áreas de TI, os modelos exigem controle de qualidade. Práticas de melhoria contínua devem ser empregadas.
Técnicas como time-to-value, custos de suporte e validadores de qualidade do modelo de dados, como o Data Model Scorecard®
(Hoberman, 2009), podem ser usadas para avaliar a exatidão, integridade e consistência do modelo. Uma vez que o CDM, LDM e PDM
estão completos, eles se tornam ferramentas muito úteis para qualquer função que precise entender o modelo, desde analistas de negócios
até desenvolvedores.
2.4 Manter os Modelos de Dados
Uma vez que os modelos de dados são construídos, eles precisam ser mantidos atualizados. Atualizações no modelo de dados precisam ser feitas
quando os requisitos mudam e frequentemente quando os processos de negócios mudam. Dentro de um projeto específico, muitas vezes, quando
um nível de modelo precisa mudar, um nível superior correspondente de modelo precisa mudar. Por exemplo, se uma nova coluna for adicionada a
um modelo de dados físico, essa coluna frequentemente precisará ser adicionada como um atributo ao modelo de dados lógico correspondente.
Uma boa prática no final de cada iteração de desenvolvimento é fazer engenharia reversa do modelo de dados físicos mais recente e garantir que
ainda seja consistente com seu modelo de dados lógico correspondente. Muitas ferramentas de modelagem de dados ajudam a automatizar esse
processo de comparação física com lógica.
3. Ferramentas
Existem muitos tipos de ferramentas que podem ajudar os modeladores de dados a concluir seu trabalho, incluindo modelagem de dados, linhagem,
ferramentas de criação de perfil de dados e repositórios de metadados.
As ferramentas de modelagem de dados são softwares que automatizam muitas das tarefas que o modelador de dados executa. As ferramentas de
modelagem de dados de nível básico fornecem funcionalidade básica de desenho, incluindo um palete de modelagem de dados para que o usuário
possa criar facilmente entidades e relacionamentos. Essas ferramentas de nível básico também suportam a banda elástica, que é o redesenho
automático das linhas de relacionamento quando as entidades são movidas. Ferramentas de modelagem de dados mais sofisticadas suportam a
engenharia avançada de estruturas conceituais para lógicas, físicas e de banco de dados, permitindo a geração de linguagem de definição de dados
de banco de dados (DDL). A maioria também dará suporte à engenharia reversa do banco de dados até o modelo de dados conceitual. Essas
ferramentas mais sofisticadas geralmente suportam funcionalidades como validação de padrões de nomenclatura, corretores ortográficos, um local
para armazenar Metadados (por exemplo, definições e linhagem) e recursos de compartilhamento (como publicação na Web).
3.2 Ferramentas de Linhagem
Uma ferramenta de linhagem é um software que permite a captura e manutenção das estruturas de origem para cada atributo no modelo de dados.
Essas ferramentas permitem a análise de impacto; isto é, pode-se usá-los para ver se uma mudança em um sistema ou parte do sistema tem efeitos
em outro sistema. Por exemplo, o atributo Valor Bruto de Vendas pode ser originado de vários aplicativos e exigir um cálculo para preencher – as
ferramentas de linhagem armazenariam essas informações.
O Microsoft Excel® é uma ferramenta de linhagem usada com frequência. Embora fácil de usar e relativamente barato, o Excel não permite a
análise de impacto real e leva ao gerenciamento manual de Metadados. A linhagem também é frequentemente capturada em uma ferramenta de
modelagem de dados, repositório de metadados ou ferramenta de integração de dados. (Consulte os Capítulos 11 e 12.)
160 • DMBOK2
3.3 Ferramentas de Perfil de Dados
Uma ferramenta de criação de perfil de dados pode ajudar a explorar o conteúdo dos dados, validá-los em relação aos metadados existentes e
identificar lacunas/deficiências de qualidade de dados, bem como deficiências em artefatos de dados existentes, como modelos lógicos e físicos,
DDL e descrições de modelos. Por exemplo, se a empresa espera que um Funcionário possa ter apenas um cargo por vez, mas o sistema mostra
que os Funcionários têm mais de um cargo no mesmo período de tempo, isso será registrado como uma anomalia de dados. (Consulte os
Capítulos 8 e 13.)
3.4 Repositórios de Metadados
Um repositório de metadados é uma ferramenta de software que armazena informações descritivas sobre o modelo de dados, incluindo o diagrama
e o texto que o acompanha, como definições, juntamente com metadados importados de outras ferramentas e processos (desenvolvimento de
software e ferramentas BPM, catálogos de sistemas, etc.). O próprio repositório deve permitir a integração e troca de metadados. Ainda mais
importante do que armazenar os metadados é compartilhar os metadados.
Os repositórios de metadados devem ter uma maneira facilmente acessível para que as pessoas visualizem e naveguem pelo conteúdo do
repositório. As ferramentas de modelagem de dados geralmente incluem um repositório limitado. (Consulte o Capítulo 13.)
3.5 Padrões de Modelo de Dados
Padrões de modelo de dados são estruturas de modelagem reutilizáveis que podem ser aplicadas a uma ampla classe de situações. Existem
padrões de modelo de dados elementares, de montagem e de integração. Padrões elementares são os 'porcas e parafusos' da modelagem de
dados. Eles incluem maneiras de resolver relacionamentos muitos-para-muitos e construir hierarquias de auto-referência. Os padrões de montagem
representam os blocos de construção que abrangem os mundos de negócios e modeladores de dados.
Pessoas de negócios podem entendê-los – ativos, documentos, pessoas e organizações e afins. Igualmente importante, eles geralmente são o
assunto de padrões de modelo de dados publicados que podem fornecer ao modelador designs comprovados, robustos, extensíveis e
implementáveis. Os padrões de integração fornecem a estrutura para vincular os padrões de montagem de maneiras comuns (Giles, 2011).
3.6 Modelos de Dados da Indústria
Os modelos de dados do setor são modelos de dados pré-criados para um setor inteiro, como saúde, telecomunicações, seguros, bancos ou
manufatura. Esses modelos geralmente são amplos em escopo e muito detalhados. Alguns modelos de dados do setor contêm milhares de
entidades e atributos. Os modelos de dados do setor podem ser adquiridos por meio de fornecedores ou obtidos por meio de grupos do setor,
como ARTS (para varejo), SID (para comunicações) ou ACORD (para seguros).
Qualquer modelo de dados adquirido precisará ser personalizado para se adequar a uma organização, pois foi desenvolvido a partir das
necessidades de várias outras organizações. O nível de personalização necessário dependerá de quão próximo o modelo está das necessidades
de uma organização e de quão detalhadas são as partes mais importantes. Em alguns casos, pode ser um
referência para os esforços em andamento de uma organização para ajudar os modeladores a fazer modelos mais completos. Em outros, ele pode
simplesmente salvar o modelador de dados de algum esforço de entrada de dados para elementos comuns anotados.
4. Práticas recomendadas
4.1 Melhores Práticas em Convenções de Nomenclatura
O Registro de Metadados ISO 11179, um padrão internacional para representar Metadados em uma organização, contém várias seções relacionadas a
padrões de dados, incluindo atributos de nomenclatura e definições de escrita.
Os padrões de modelagem de dados e design de banco de dados servem como princípios orientadores para atender efetivamente às necessidades de dados
de negócios, estar em conformidade com a Arquitetura Corporativa e de Dados (consulte o Capítulo 4) e garantir a qualidade dos dados (consulte o Capítulo
14). Arquitetos de dados, analistas de dados e administradores de banco de dados devem desenvolver esses padrões em conjunto. Eles devem complementar
e não entrar em conflito com os padrões de TI relacionados.
Publique modelos de dados e padrões de nomenclatura de banco de dados para cada tipo de objeto de modelagem e objeto de banco de dados.
Os padrões de nomenclatura são particularmente importantes para entidades, tabelas, atributos, chaves, exibições e índices. Os nomes devem ser únicos e
tão descritivos quanto possível.
Os nomes lógicos devem ser significativos para os usuários de negócios, usando palavras completas o máximo possível e evitando todas as abreviações,
exceto as mais familiares. Os nomes físicos devem estar de acordo com o comprimento máximo permitido pelo DBMS, portanto, use abreviações quando
necessário. Enquanto os nomes lógicos usam espaços em branco como separadores entre palavras, os nomes físicos normalmente usam sublinhados como
separadores de palavras.
Os padrões de nomenclatura devem minimizar as alterações de nome nos ambientes. Os nomes não devem refletir seu ambiente específico, como teste,
controle de qualidade ou produção. Palavras de classe, que são os últimos termos em nomes de atributos como Quantidade, Nome e Código, podem ser
usadas para distinguir atributos de entidades e nomes de colunas de nomes de tabelas. Eles também podem mostrar quais atributos e colunas são
quantitativos em vez de qualitativos, o que pode ser importante ao analisar o conteúdo dessas colunas.
4.2 Melhores práticas em design de banco de dados
Ao projetar e construir o banco de dados, o DBA deve manter os seguintes princípios de design em mente (lembre-se da sigla PRISM):
• Desempenho e facilidade de uso: Garanta o acesso rápido e fácil aos dados por usuários aprovados de forma utilizável e
forma relevante para os negócios, maximizando o valor comercial de aplicativos e dados.

162 • DMBOK2
• Reutilização: A estrutura do banco de dados deve garantir que, quando apropriado, vários aplicativos possam
usar os dados e que os dados podem servir a vários propósitos (por exemplo, análise de negócios, qualidade
melhoria, planejamento estratégico, gestão de relacionamento com o cliente e melhoria de processos).
Evite acoplar um banco de dados, estrutura de dados ou objeto de dados a um único aplicativo.
• Integridade: Os dados devem sempre ter um significado e valor comercial válidos, independentemente do contexto, e
deve sempre refletir um estado válido do negócio. Aplicar restrições de integridade de dados o mais próximo possível dos dados
possível, e detectar e relatar imediatamente violações de restrições de integridade de dados.
• Segurança: dados verdadeiros e precisos devem estar sempre disponíveis imediatamente para usuários autorizados, mas apenas
aos usuários autorizados. As preocupações de privacidade de todas as partes interessadas, incluindo clientes, parceiros de negócios,
e reguladores governamentais, devem ser atendidos. Reforce a segurança dos dados, como a integridade dos dados, o mais próximo possível dos dados
possível e detectar e relatar imediatamente as violações de segurança.
• Manutenibilidade: execute todo o trabalho de dados a um custo que gere valor, garantindo que o custo de criação,
armazenar, manter, usar e descartar dados não excede seu valor para a organização. Garantir
a resposta mais rápida possível a mudanças nos processos de negócios e novos requisitos de negócios.
5. Governança do Modelo de Dados
5.1 Modelo de dados e gerenciamento de qualidade de design
Analistas e designers de dados atuam como intermediários entre os consumidores de informações (as pessoas com requisitos de negócios para
dados) e os produtores de dados que capturam os dados de forma utilizável. Os profissionais de dados devem equilibrar os requisitos de dados dos
consumidores de informações e os requisitos de aplicação dos produtores de dados.
Os profissionais de dados também devem equilibrar os interesses comerciais de curto e longo prazo. Os consumidores de informações precisam de
dados em tempo hábil para cumprir as obrigações comerciais de curto prazo e aproveitar as oportunidades de negócios atuais. As equipes de projeto
de desenvolvimento de sistemas devem atender às restrições de tempo e orçamento. No entanto, eles também devem atender aos interesses de
longo prazo de todas as partes interessadas, garantindo que os dados de uma organização residam em estruturas de dados seguras, recuperáveis,
compartilháveis e reutilizáveis, e que esses dados sejam tão corretos, oportunos, relevantes e utilizáveis quanto possível. possível. Portanto, modelos
de dados e projetos de banco de dados devem ter um equilíbrio razoável entre as necessidades de curto prazo e as necessidades de longo prazo
da empresa.
5.1.1 Desenvolver padrões de modelagem e design de dados
Conforme observado anteriormente (na Seção 4.1), os padrões de modelagem de dados e design de banco de dados fornecem princípios
orientadores para atender aos requisitos de dados de negócios, estar em conformidade com os padrões corporativos e de arquitetura de dados e
garantir a qualidade dos dados. Os padrões de modelagem de dados e design de banco de dados devem incluir o seguinte:
• Uma lista e descrição de modelagem de dados padrão e entregas de design de banco de dados
• Uma lista de nomes padrão, abreviações aceitáveis e regras de abreviação para palavras incomuns, que
aplicar a todos os objetos de modelo de dados
• Uma lista de formatos de nomenclatura padrão para todos os objetos de modelo de dados, incluindo atributo e classe de coluna
palavras
• Uma lista e descrição de métodos padrão para criar e manter essas entregas
• Uma lista e descrição de funções e responsabilidades de modelagem de dados e design de banco de dados
• Uma lista e descrição de todas as propriedades de metadados capturadas na modelagem de dados e design de banco de dados,
incluindo Metadados de negócios e Metadados técnicos. Por exemplo, as diretrizes podem definir o
expectativa de que o modelo de dados capture a linhagem para cada atributo.
• Expectativas e requisitos de qualidade de metadados (consulte o Capítulo 13)
• Diretrizes sobre como usar ferramentas de modelagem de dados
• Diretrizes para preparar e liderar revisões de projeto
• Diretrizes para versionamento de modelos de dados
• Práticas que são desencorajadas
5.1.2 Revisar o modelo de dados e a qualidade do design do banco de dados
As equipes de projeto devem realizar revisões de requisitos e revisões de design do modelo de dados conceitual, modelo de dados lógico e design de
banco de dados físico. A agenda para reuniões de revisão deve incluir itens para revisão do modelo inicial (se houver), as alterações feitas no modelo e
quaisquer outras opções que foram consideradas e rejeitadas, e quão bem o novo modelo está em conformidade com quaisquer padrões de modelagem
ou arquitetura em vigor.
Conduza revisões de design com um grupo de especialistas no assunto representando diferentes origens, habilidades, expectativas e opiniões. Pode exigir
mandato executivo para obter recursos especializados alocados para essas revisões.
Os participantes devem ser capazes de discutir diferentes pontos de vista e chegar ao consenso do grupo sem conflito pessoal, pois todos os participantes
compartilham o objetivo comum de promover o design mais prático, com melhor desempenho e mais utilizável. Presidir cada revisão de projeto com um
líder que facilita a reunião. O líder cria e segue uma agenda, garante que toda a documentação necessária esteja disponível e distribuída, solicita a opinião
de todos os participantes, mantém a ordem e mantém a reunião em andamento e resume as conclusões do consenso do grupo. Muitas revisões de design
também usam um escriba para capturar pontos de discussão.
Nas revisões em que não há aprovação, o modelador deve refazer o projeto para resolver os problemas. Se houver problemas que o modelador não possa
resolver sozinho, a palavra final deve ser dada pelo proprietário do sistema refletido pelo modelo.
5.1.3 Gerenciar Versão e Integração do Modelo de Dados
Modelos de dados e outras especificações de projeto exigem um controle cuidadoso de alterações, assim como as especificações de requisitos e outros
produtos SDLC. Observe cada alteração em um modelo de dados para preservar a linhagem de alterações ao longo do tempo. Se
164 • DMBOK2
uma mudança afeta o modelo de dados lógico, como um requisito de dados de negócios novo ou alterado, o analista de dados ou arquiteto
deve revisar e aprovar a mudança no modelo.
Cada mudança deve observar:
• Por que o projeto ou situação exigiu a mudança
• O que e como os objetos foram alterados, incluindo quais tabelas tiveram colunas adicionadas, modificadas ou
removido, etc
• Quando a mudança foi aprovada e quando a mudança foi feita no modelo (não necessariamente quando
a mudança foi implementada em um sistema)
• Quem fez a mudança
• Onde a mudança foi feita (em quais modelos)
Algumas ferramentas de modelagem de dados incluem repositórios que fornecem versão de modelo de dados e funcionalidade de integração.
Caso contrário, preserve os modelos de dados em exportações DDL ou arquivos XML, fazendo check-in e check-out deles em um sistema de
gerenciamento de código-fonte padrão, assim como o código do aplicativo.
5.2 Métricas de Modelagem de Dados
Existem várias maneiras de medir a qualidade de um modelo de dados e todas requerem um padrão para comparação. Um método que será
usado para fornecer um exemplo de validação do modelo de dados é o The Data Model Scorecard®, que fornece 11 métricas de qualidade do
modelo de dados: uma para cada uma das dez categorias que compõem o Scorecard e uma pontuação geral em todas as dez categorias
(Hoberman , 2015). A Tabela 11 contém o modelo Scorecard.
Tabela 11 Modelo de Modelo de Dados Scorecard®
# Categoria Total Modelo % Comentários
pontuação pontuação
1 Quão bem o modelo captura os requisitos? 15
2 Quão completo é o modelo? 15

3 Quão bem o modelo corresponde ao seu esquema? 10
4 Quão estruturalmente sólido é o modelo? 15
5 Quão bem o modelo alavanca estruturas genéricas? 10

6 Quão bem o modelo segue os padrões de nomenclatura? 5
7 Quão bem o modelo foi organizado para legibilidade? 5
8 Quão boas são as definições? 10
9 Quão consistente é o modelo com a empresa? 5

10 Quão bem os metadados correspondem aos dados? 10
PONTUAÇÃO TOTAL 100
A coluna de pontuação do modelo contém a avaliação do revisor de quão bem um modelo específico atendeu aos critérios de pontuação,
sendo a pontuação máxima o valor que aparece na coluna de pontuação total. Por exemplo, um revisor pode dar a um modelo uma pontuação
de 10 em “Quão bem o modelo captura os requisitos?” A coluna

apresenta a pontuação do modelo para a categoria dividida pela pontuação total da categoria. Por exemplo, receber 10 de 15 levaria a
66%. A coluna de comentários deve documentar informações que expliquem a pontuação com mais detalhes ou capturem os itens de
ação necessários para corrigir o modelo. A última linha contém a pontuação geral atribuída ao modelo, uma soma de cada uma das
colunas.
Segue uma breve descrição de cada categoria:
1. Quão bem o modelo captura os requisitos? Aqui garantimos que o modelo de dados representa os requisitos. Se houver um
requisito para capturar informações do pedido, nesta categoria verificamos o modelo para garantir que ele capture as
informações do pedido. Se houver um requisito para visualizar a Contagem de alunos por semestre e curso, nesta
categoria nos certificamos de que o modelo de dados suporta essa consulta.
2. Quão completo é o modelo? Aqui, completude significa duas coisas: completude de requisitos e completude de Metadados. A
integralidade dos requisitos significa que cada requisito solicitado aparece no modelo. Isso também significa que o modelo de
dados contém apenas o que está sendo solicitado e nada extra. É fácil adicionar estruturas ao modelo antecipando que elas
serão usadas em um futuro próximo; observamos essas seções do modelo durante a revisão. O projeto pode se tornar muito
difícil de entregar se o modelador incluir algo que nunca foi solicitado. Precisamos considerar o custo provável de incluir um
requisito futuro no caso de ele nunca acontecer. A integridade dos metadados significa que todas as informações descritivas
que cercam o modelo também estão presentes; por exemplo, se estivermos revisando um modelo de dados físico, esperamos
que a formatação e a nulidade apareçam no
modelo de dados.
3. Quão bem o modelo corresponde ao seu esquema? Aqui garantimos que o nível de detalhe do modelo
(conceitual, lógico ou físico) e o esquema (por exemplo, relacional, dimensional, NoSQL) do modelo que está sendo revisado
corresponde à definição desse tipo de modelo.
4. Quão estruturalmente sólido é o modelo? Aqui validamos as práticas de design empregadas para construir o modelo para
garantir que se possa construir um banco de dados a partir do modelo de dados. Isso inclui evitar problemas de design,
como ter dois atributos com o mesmo nome exato na mesma entidade ou ter um atributo nulo em uma chave primária.
5. Quão bem o modelo alavanca estruturas genéricas? Aqui confirmamos um uso adequado de
abstração. Passar do Local do Cliente para um Local mais genérico , por exemplo, permite que o projeto lide mais
facilmente com outros tipos de locais, como armazéns e centros de distribuição.
6. Até que ponto o modelo segue os padrões de nomenclatura? Aqui garantimos que padrões de nomenclatura corretos e
consistentes foram aplicados ao modelo de dados. Nós nos concentramos em nomear estrutura, termo e estilo padrão.
Estrutura significa que os blocos de construção adequados estão sendo usados para entidades, relacionamentos e atributos.
Por exemplo, um bloco de construção para um atributo seria o assunto do atributo, como 'Cliente' ou 'Produto'. Termo
significa que o nome próprio é dado ao atributo ou entidade. O termo também inclui ortografia e abreviatura adequadas.
Estilo significa que a aparência, como caixa alta ou caixa camel, é consistente com as práticas padrão.
166 • DMBOK2
7. Quão bem o modelo foi organizado para legibilidade? Aqui garantimos que o modelo de dados é fácil de
ler. Esta questão não é a mais importante das dez categorias. No entanto, se o seu modelo for difícil de
ler, você pode não abordar com precisão as categorias mais importantes no scorecard. Colocando pai
entidades acima de suas entidades filhas, exibindo entidades relacionadas juntas e minimizando a linha de relacionamento
comprimento todos melhoram a legibilidade do modelo.
8. Quão boas são as definições? Aqui garantimos que as definições sejam claras, completas e precisas.
9. Quão consistente é o modelo com a empresa? Aqui garantimos as estruturas no modelo de dados
são representados em um contexto amplo e consistente, de modo que um conjunto de terminologia e regras possa ser
falado na organização. As estruturas que aparecem em um modelo de dados devem ser consistentes em
terminologia e uso com estruturas que aparecem em modelos de dados relacionados e, idealmente, com o
modelo de dados corporativos (EDM), se houver.
10. Quão bem os metadados correspondem aos dados? Aqui confirmamos que o modelo e os dados reais
que serão armazenados dentro das estruturas resultantes são consistentes. A coluna
Customer_Last_Name realmente contém o sobrenome do cliente, por exemplo? A categoria Dados é
projetado para reduzir essas surpresas e ajudar a garantir que as estruturas do modelo correspondam aos dados
estruturas estarão segurando.
O scorecard fornece uma avaliação geral da qualidade do modelo e identifica áreas específicas para melhoria.

AMBLER, Scott. Técnicas de banco de dados ágil: estratégias eficazes para o desenvolvedor de software ágil. Wiley e Filhos, 2003.
Imprimir.
Avison, David e Christine Cuthbertson. Uma abordagem de gerenciamento para aplicativos de banco de dados. McGraw-Hill Publishing Co.,
2002. Imprimir. Sistemas de informação serv.
Blá, Michael. Manual de modelagem de banco de dados UML. Technics Publications, LLC, 2013. Imprimir.
Brackett, Michael H. Design de recursos de dados: realidade além da ilusão. Technics Publications, LLC, 2012. Imprimir.
Brackett, Michael H. Integração de recursos de dados: Entendendo e resolvendo um recurso de dados díspar. Technics Publications, LLC,
2012. Imprimir.
Brackett, Michael H. Simplexidade dos recursos de dados: como as organizações escolhem o sucesso ou o fracasso dos recursos de dados.
Bruce, Thomas A. Projetando Bancos de Dados de Qualidade com Modelos de Informação IDEF1X. Dorset House, 1991. Impresso.
Queimaduras, Larry. Construindo o banco de dados ágil: como construir um aplicativo de sucesso usando o Agile sem sacrificar o gerenciamento
de dados. Technics Publications, LLC, 2011. Imprimir.
Carlis, John e Joseph Maguire. Dominando a modelagem de dados - uma abordagem orientada ao usuário. Addison-Wesley Professional,
2000. Impressão.
Codd, Edward F. “Um modelo relacional de dados para grandes bancos de dados compartilhados”. Comunicações da ACM, 13, nº 6 (junho de 1970).
DAMA Internacional. O Dicionário DAMA de Gerenciamento de Dados. 2ª Edição: Mais de 2.000 Termos Definidos para Profissionais de TI e
Negócios. 2ª edição. Technics Publications, LLC, 2011. Imprimir.
Daust, Norman. Modelagem de Requisitos UML para Analistas de Negócios: Passos para Modelar o Sucesso. Technics Publications, LLC, 2012.
Imprimir.
Date, CJ Uma Introdução aos Sistemas de Banco de Dados. 8ª edição. Addison-Wesley, 2003. Imprimir.
Date, CJ e Hugh Darwen. Bases de Dados, Tipos e o Modelo Relacional. 3d edição. Addison Wesley, 2006. Imprimir.
Date, Chris J. O Dicionário de Banco de Dados Relacional: Um Glossário Abrangente de Termos e Conceitos Relacionais, com Exemplos
Ilustrativos. O'Reilly Media, 2006. Impresso.
Dorsey, Paulo. Modelagem de Dados Corporativos Usando UML. McGraw-Hill Osborne Media, 2009. Impresso.
Edvinsson, Håkan e Lottie Aderinne. Arquitetura corporativa simplificada: usando a abordagem Ready, Set, Go para alcançar a centralidade
da informação. Technics Publications, LLC, 2013. Imprimir.
Fleming, Candace C. e Barbara Von Halle. O Manual de Design de Banco de Dados Relacional. Addison Wesley, 1989. Impresso.
Giles, João. The Nimble Elephant: Entrega ágil de modelos de dados usando uma abordagem baseada em padrões. Technics Publications, LLC,
2012. Imprimir.
Dourado, Carlos. Modelagem de dados 152 segredos de sucesso - 152 perguntas mais frequentes sobre modelagem de dados - o que você
precisa saber. Editora Emereo, 2015. Impresso. Segredos do Sucesso.
Halpin, Terry, Ken Evans, Pat Hallock e Bill McLean. Modelagem de banco de dados com o Microsoft Visio for Enterprise Architects.
Morgan Kaufmann, 2003. Impresso. A série Morgan Kaufmann em sistemas de gerenciamento de dados.
Halpin, Terry. Modelagem da Informação e Bancos de Dados Relacionais. Morgan Kaufmann, 2001. Impresso. A série Morgan Kaufmann em
sistemas de gerenciamento de dados.
Halpin, Terry. Modelagem da Informação e Bancos de Dados Relacionais: Da Análise Conceitual ao Projeto Lógico. Morgan Kaufmann, 2001.
Impresso. A série Morgan Kaufmann em sistemas de gerenciamento de dados.
Harrington, Jan L. Design de banco de dados relacional claramente explicado. 2ª edição. Morgan Kaufmann, 2002. Impresso. A série Morgan
Kaufmann em sistemas de gerenciamento de dados.
Hay, David C. Padrões de Modelo de Dados: Um Mapa de Metadados. Morgan Kaufmann, 2006. Impresso. A série Morgan Kaufmann em
Hay, David C. Padrões de modelo empresarial: descrevendo o mundo (versão UML). Technics Publications, LLC, 2011. Imprimir.
Hay, David C. Análise de Requisitos de Visões de Negócios à Arquitetura. Prentice Hall, 2002. Impresso.
Hay, David C. UML e Modelagem de Dados: Uma Reconciliação. Technics Publications, LLC, 2011. Imprimir.
Hernandez, Michael J. Design de banco de dados para meros mortais: um guia prático para design de banco de dados relacional. 2ª edição.
Addison-Wesley Professional, 2003. Impressão.
Hoberman, Steve, Donna Burbank, Chris Bradley, et al. Modelagem de dados para o negócio: um manual para alinhar o negócio com a TI
usando modelos de dados de alto nível. Technics Publications, LLC, 2009. Imprimir. Leve com você guias.
HOBERMAN, Steve. Scorecard do modelo de dados. Technics Publications, LLC, 2015. Imprimir.
HOBERMAN, Steve. Modelagem de dados simplificada com ER/ Studio Data Architect. Technics Publications, LLC, 2013. Imprimir.
HOBERMAN, Steve. Modelagem de dados simplificada: um guia prático para profissionais de negócios e de TI. 2ª edição. Technics Publications,
LLC, 2009. Imprimir.
168 • DMBOK2
HOBERMAN, Steve. Manual de Treinamento Master Class em Modelagem de Dados. 7ª edição. Technics Publications, LLC, 2017. Imprimir.
HOBERMAN, Steve. O Workbench do Modelador de Dados. Ferramentas e Técnicas de Análise e Projeto. Wiley, 2001. Impresso.
Hoffer, Jeffrey A., Joey F. George e Joseph S. Valacich. Análise e Projeto de Sistemas Modernos. 7ª edição. Prentice Hall, 2013. Impresso.
IIBA e Kevin Brennan, ed. Um Guia para o Corpo de Conhecimento de Análise de Negócios (Guia BABOK). Instituto Internacional de Análise de
Negócios, 2009. Imprimir.
Kent, William. Dados e realidade: uma perspectiva atemporal sobre a percepção e gerenciamento de informações em nosso mundo impreciso. 3d
edição. Technics Publications, LLC, 2012. Imprimir.
Krogstie, John, Terry Halpin e Keng Siau, eds. Métodos e Metodologias de Modelagem da Informação: Tópicos Avançados em Pesquisa de Banco de
Dados. Idea Group Publishing, 2005. Impresso. Tópicos Avançados em Pesquisa de Banco de Dados.
Linstedt, Dan. Supercarregue seu data warehouse: regras de modelagem de dados inestimáveis para implementar seu cofre de dados.
Serviços Digitais Amazon. 2012. Livro de Arquitetura de Data Warehouse 1.
Müller, Roberto. J. Projeto de Banco de Dados para Smarties: Usando UML para Modelagem de Dados. Morgan Kaufmann, 1999. Impresso. A
série Morgan Kaufmann em sistemas de gerenciamento de dados.
Needham, Douglas. Gráficos de estrutura de dados: A estrutura de seus dados tem significado. Doug Needham Amazon Digital Services,
2015. Kindle.
Newton, Judith J. e Daniel Wahl, eds. Manual de Administração de Dados. Publicações Especiais do NIST, 1993. Impresso.
Pascal, Fabiano. Questões práticas em gerenciamento de banco de dados: uma referência para o praticante de pensamento. Addison-Wesley
Professional, 2000. Impressão.
Reingruber, Michael. C. e William W. Gregory. O Manual de Modelagem de Dados: Uma Abordagem de Boas Práticas para Construir Modelos de
Dados de Qualidade. Wiley, 1994. Impresso.
Riordan, Rebecca M. Projetando sistemas de banco de dados eficazes. Addison-Wesley Professional, 2005. Impressão.
Rob, Pedro e Carlos Coronel. Sistemas de Banco de Dados: Projeto, Implementação e Gerenciamento. 7ª edição. Cengage Learning, 2006. Imprimir.
Schmidt, Bob. Modelagem de Dados para Profissionais da Informação. Prentice Hall, 1998. Impresso.
Silverston, Len e Paul Agnew. O Data Model Resource Book, Volume 3: Padrões Universais para Modelagem de Dados. Wiley, 2008. Impresso.
Silverstone, Len. O livro de recursos do modelo de dados, volume 1: uma biblioteca de modelos de dados universais para todas as empresas. Rev.
ed. Wiley, 2001. Impresso.
Silverstone, Len. O livro de recursos do modelo de dados, volume 2: uma biblioteca de modelos de dados para setores específicos. Rev. ed.
Simsion, Graeme C. e Graham C. Witt. Fundamentos de Modelagem de Dados. 3ª edição. Morgan Kaufmann, 2004. Impresso.
Simsão, Graeme. Modelagem de Dados: Teoria e Prática. Technics Publications, LLC, 2007. Imprimir.
Teorey, Toby, et ai. Modelagem e Design de Banco de Dados: Design Lógico, 4ª ed. Morgan Kaufmann, 2010. Print. A série Morgan Kaufmann em
Thalheim, Bernhard. Modelagem Entidade-Relacionamento: Fundamentos da Tecnologia de Banco de Dados. Springer, 2000. Impresso.
Watson, Richard T. Gerenciamento de Dados: Bancos de Dados e Organizações. 5ª edição. Wiley, 2005. Impresso.
CAPÍTULO 6
Armazenamento de dados e operações
Dados
Modelagem de dados
Qualidade dos dados
& Operações
Dados Dados
Metadados

& O negócio
Interoperabilidade
Inteligência
& Mestre & Contente
Dados Gestão

1. Introdução
D
ata Storage and Operations inclui o design, implementação e suporte de dados armazenados, para
maximizar seu valor ao longo de seu ciclo de vida, desde a criação/aquisição até o descarte (consulte o Capítulo 1).
Armazenamento de dados e operações inclui duas subatividades:
• O suporte do banco de dados se concentra nas atividades relacionadas ao ciclo de vida dos dados, desde a implementação inicial de um
ambiente de banco de dados, por meio da obtenção, backup e limpeza de dados. Inclui também a garantia de
banco de dados funciona bem. O monitoramento e o ajuste são essenciais para o suporte ao banco de dados.
169
170 • DMBOK2
• O suporte à tecnologia de banco de dados inclui a definição de requisitos técnicos que atenderão
necessidades, definindo arquitetura técnica, instalando e administrando tecnologia e resolvendo problemas
relacionados à tecnologia.
Os administradores de banco de dados (DBAs) desempenham papéis importantes em ambos os aspectos de armazenamento de dados e
operações. A função do DBA é a função profissional de dados mais estabelecida e mais amplamente adotada, e as práticas de administração de
banco de dados são talvez as mais maduras de todas as práticas de gerenciamento de dados. DBAs também desempenham papéis dominantes
em operações de dados e segurança de dados. (Consulte o Capítulo 7.)
Armazenamento de dados e operações
Definição: O design, implementação e suporte de dados armazenados para maximizar seu valor.
Objetivos:
1. Gerenciar a disponibilidade de dados em todo o ciclo de vida dos dados.

2. Garanta a integridade dos ativos de dados.
3. Gerenciar o desempenho das transações de dados.
O negócio
Motoristas

• Arquitetura de dados •
1. Gerenciar a tecnologia de banco de dados Tecnologia de banco de dados
• Critério de avaliação
Requisitos de dados 1. Compreender a Tecnologia de Banco de Dados (P)
• Modelos de dados • Ambientes de banco de dados
2. Avaliar a Tecnologia de Banco de Dados (D)
• Nível de serviço •
3. Gerenciar e monitorar o banco de dados Migrado/Replicado/Versão
Contratos Tecnologia (O) Dados sionados
•
2. Gerenciar operações de banco de dados Continuidade de Negócios
1. Entenda os Requisitos (P) Planos
• Desempenho do banco de dados
2. Plano de Continuidade de Negócios (P)
3. Desenvolva Instâncias de Banco de Dados (D) SER
4. Gerenciar o desempenho do banco de dados (C,O)

5. Gerenciar conjuntos de dados de teste (O)
6. Gerenciar a migração de dados (O)

• Arquiteto de Dados Administrador de Banco de Dados • Modelador de Dados
• Modelador de Dados • Arquiteto de Dados • Desenvolvedor de software
• Desenvolvedor de software • Teste de aplicativos
• Teste de aplicativos Equipe
Equipe • A infraestrutura
Técnico Operações
Motoristas

• •
Implementação da mudança • Ferramentas de modelagem de dados Métricas de armazenamento de dados
Caminho • • Métricas de desempenho
Ferramentas de monitoramento de banco de dados
• •
Padrões de nomenclatura física Ferramentas de gerenciamento de banco de dados • Métricas de Operações
• •
Gerenciamento do ciclo de vida de dados • Ferramentas de suporte ao desenvolvedor Métricas de serviço
•
Uso de script para todos
Mudanças
Figura 54 Diagrama de contexto: armazenamento de dados e operações

ARMAZENAMENTO DE DADOS E OPERAÇÕES • 171
As empresas dependem de seus sistemas de informação para executar suas operações. As atividades de armazenamento e operações de dados são
cruciais para organizações que dependem de dados. A continuidade dos negócios é o principal impulsionador dessas atividades. Se um sistema ficar
indisponível, as operações da empresa podem ser prejudicadas ou interrompidas completamente. Uma infraestrutura de armazenamento de dados
confiável para operações de TI minimiza o risco de interrupção.
Os objetivos de armazenamento e operações de dados incluem:
• Gerenciando a disponibilidade de dados em todo o ciclo de vida dos dados
• Garantir a integridade dos ativos de dados
• Gerenciando o desempenho das transações de dados
Armazenamento de dados e operações representam um lado altamente técnico do gerenciamento de dados. DBAs e outros envolvidos neste trabalho
podem fazer melhor seu trabalho e ajudar no trabalho geral de gerenciamento de dados quando seguem estes princípios orientadores:
• Identificar e atuar em oportunidades de automação: automatizar processos de desenvolvimento de banco de dados,
desenvolver ferramentas e processos que encurtem cada ciclo de desenvolvimento, reduzam erros e retrabalhos e
minimizar o impacto na equipe de desenvolvimento. Dessa forma, os DBAs podem se adaptar a sistemas mais iterativos (ágeis)
abordagens para o desenvolvimento de aplicativos. Este trabalho de melhoria deve ser feito em colaboração com
modelagem de dados e arquitetura de dados.
• Construir com a reutilização em mente: Desenvolva e promova o uso de objetos de dados abstratos e reutilizáveis que
impedem que aplicativos sejam fortemente acoplados a esquemas de banco de dados (o chamado 'objeto-relacional
incompatibilidade de impedância'). Existem vários mecanismos para esse fim, incluindo visualizações de banco de dados, gatilhos,
funções e procedimentos armazenados, objetos de dados de aplicativos e camadas de acesso a dados, XML e XSLT,
Conjuntos de dados tipados ADO.NET e serviços da web. O DBA deve ser capaz de avaliar a melhor abordagem
virtualização de dados. O objetivo final é tornar o uso do banco de dados o mais rápido, fácil e indolor possível.
• Compreender e aplicar adequadamente as melhores práticas: DBAs devem promover padrões de banco de dados e
melhores práticas como requisitos, mas seja flexível o suficiente para desviar-se delas se houver motivos aceitáveis
para esses desvios. Os padrões de banco de dados nunca devem ser uma ameaça ao sucesso de um projeto.
• Conecte os padrões de banco de dados aos requisitos de suporte: por exemplo, o Contrato de Nível de Serviço
(SLA) pode refletir métodos recomendados pelo DBA e aceitos pelo desenvolvedor para garantir a integridade dos dados e
segurança de dados. O SLA deve refletir a transferência de responsabilidade dos DBAs para o desenvolvimento
equipe se a equipe de desenvolvimento codificará seus próprios procedimentos de atualização de banco de dados ou acesso a dados
camada. Isso impede uma abordagem "tudo ou nada" para os padrões.

172 • DMBOK2
• Definir expectativas para a função de DBA no trabalho do projeto: Garantir que a metodologia do projeto inclua
A integração do DBA na fase de definição do projeto pode ajudar em todo o SDLC. O DBA pode
entender as necessidades do projeto e dar suporte aos requisitos antecipadamente. Isso melhorará a comunicação por
esclarecer as expectativas da equipe do projeto do grupo de dados. Ter um primário dedicado e
DBA secundário durante a análise e o design esclarecem as expectativas sobre as tarefas, padrões e trabalho do DBA
esforço e prazos para o trabalho de desenvolvimento. As equipes também devem esclarecer as expectativas de suporte após
implementação.
1.3.1 Termos do Banco de Dados
A terminologia do banco de dados é específica e técnica. Ao trabalhar como DBA ou com DBAs, é importante entender as especificidades dessa
linguagem técnica:
• Banco de dados: Qualquer coleção de dados armazenados, independentemente da estrutura ou conteúdo. Alguns grandes bancos de dados referem-se
para instâncias e esquemas.
• Instância: Uma execução de software de banco de dados que controla o acesso a uma determinada área de armazenamento. Um
organização normalmente terá várias instâncias executando simultaneamente, usando diferentes áreas de
armazenar. Cada instância é independente de todas as outras instâncias.
• Esquema: Um subconjunto de objetos de banco de dados contidos no banco de dados ou em uma instância. Os esquemas são
usado para organizar objetos em partes mais gerenciáveis. Normalmente, um esquema tem um proprietário e um acesso
lista particular ao conteúdo do esquema. Usos comuns de esquemas são para isolar objetos contendo
dados confidenciais da base geral de usuários ou para isolar exibições somente leitura das tabelas subjacentes em
bancos de dados relacionais. Schema também pode ser usado para se referir a uma coleção de estruturas de banco de dados com
algo em comum.
• Nó: Um computador individual que hospeda processamento ou dados como parte de um banco de dados distribuído.
• A abstração do banco de dados significa que uma interface de aplicativo (API) comum é usada para chamar o banco de dados
funções, de modo que um aplicativo pode se conectar a vários bancos de dados diferentes sem o programador
ter que conhecer todas as chamadas de função para todos os bancos de dados possíveis. ODBC (Open Database Connectivity) é um
exemplo de uma API que permite a abstração de banco de dados. As vantagens incluem portabilidade; desvantagens
incluem a incapacidade de usar funções de banco de dados específicas que não são comuns em bancos de dados.
1.3.2 Gerenciamento do Ciclo de Vida de Dados
Os DBAs mantêm e garantem a precisão e consistência dos dados durante todo o seu ciclo de vida através do design, implementação e uso de
qualquer sistema que armazene, processe ou recupere dados. O DBA é o guardião de todas as alterações do banco de dados. Embora muitas partes
possam solicitar alterações, o DBA define as alterações precisas a serem feitas no banco de dados, implementa as alterações e controla as
alterações.
O gerenciamento do ciclo de vida dos dados inclui a implementação de políticas e procedimentos para aquisição, migração, retenção, expiração e
disposição de dados. É prudente preparar listas de verificação para garantir que todas as tarefas sejam executadas com alto nível de qualidade.
Os DBAs devem usar um processo controlado, documentado e auditável para mover as alterações do banco de dados do aplicativo para os
ambientes de Garantia de Qualidade ou Certificação (QA) e Produção. Uma solicitação de serviço ou solicitação de mudança aprovada pelo
gerente geralmente inicia o processo. O DBA deve ter um plano de retorno para reverter as mudanças em caso de problemas.
1.3.3 Administradores
A função de Administrador de Banco de Dados (DBA) é a função profissional de dados mais estabelecida e mais amplamente adotada. Os DBAs
desempenham as funções dominantes no Armazenamento e Operações de Dados e funções críticas na Segurança de Dados (consulte o Capítulo
7), o lado físico da modelagem de dados e o design do banco de dados (consulte o Capítulo 5). Os DBAs fornecem suporte para ambientes de
banco de dados de desenvolvimento, teste, controle de qualidade e uso especial.
Os DBAs não realizam exclusivamente todas as atividades de Armazenamento e Operações de Dados. Administradores de dados, arquitetos de
dados, administradores de rede, analistas de dados e analistas de segurança participam do planejamento de desempenho, retenção e recuperação.
Essas equipes também podem participar da obtenção e processamento de dados de

fontes.
Muitos DBAs se especializam como DBAs de Produção, Aplicação, Procedimental e Desenvolvimento. Algumas organizações também têm
Administradores de Armazenamento de Rede (NSA) que se especializam em dar suporte ao sistema de armazenamento de dados separadamente
dos aplicativos ou estruturas de armazenamento de dados.
Em algumas organizações, cada função especializada se reporta a uma organização diferente dentro da TI. Os DBAs de produção podem fazer
parte da infraestrutura de produção ou dos grupos de suporte de operações de aplicativos. DBAs de aplicativos, desenvolvimento e procedimentos
às vezes são integrados às organizações de desenvolvimento de aplicativos. As NSAs geralmente estão conectadas a organizações de
infraestrutura.
1.3.3.1 DBA de Produção
Os DBAs de produção assumem a responsabilidade principal pelo gerenciamento de operações de dados, incluindo:
• Garantir o desempenho e confiabilidade do banco de dados, por meio de ajuste de desempenho, monitoramento,
relatórios de erros e outras atividades
• Implementação de mecanismos de backup e recuperação para garantir que os dados possam ser recuperados se perdidos em qualquer
circunstância
• Implementação de mecanismos para clustering e failover do banco de dados, se dados de disponibilidade contínua de dados
é um requisito
• Execução de outras atividades de manutenção do banco de dados, como implementação de mecanismos para arquivamento de dados
174 • DMBOK2
Como parte do gerenciamento de operações de dados, os DBAs de produção criam os seguintes produtos:
• Um ambiente de banco de dados de produção, incluindo uma instância do DBMS (Database Management
System) no servidor de suporte, de tamanho e capacidade suficientes para garantir um desempenho adequado,
configurado para o nível apropriado de segurança, confiabilidade e disponibilidade. Sistema de banco de dados
A administração é responsável pelo ambiente DBMS.
• Mecanismos e processos para implementação controlada de mudanças em bancos de dados na produção

meio Ambiente
• Mecanismos para garantir a disponibilidade, integridade e recuperabilidade dos dados em resposta a todos
circunstâncias que podem resultar em perda ou corrupção de dados
• Mecanismos para detectar e relatar qualquer erro que ocorra no banco de dados, no SGBD ou nos dados
servidor
• Disponibilidade, recuperação e desempenho do banco de dados de acordo com os contratos de nível de serviço
• Mecanismos e processos para monitorar o desempenho do banco de dados à medida que as cargas de trabalho e os volumes de dados variam
1.3.3.2 Aplicativo DBA
Um DBA de aplicação é responsável por um ou mais bancos de dados em todos os ambientes (desenvolvimento/teste, controle de qualidade e produção),
ao contrário da administração de sistemas de banco de dados para qualquer um desses ambientes. Às vezes, os DBAs de aplicativos se reportam às
unidades organizacionais responsáveis pelo desenvolvimento e manutenção dos aplicativos suportados por seus bancos de dados. Há prós e contras na
contratação de DBAs de aplicativos.
Os DBAs de aplicativos são vistos como membros integrais de uma equipe de suporte de aplicativos. Ao se concentrar em um banco de dados específico,
eles podem fornecer um melhor serviço aos desenvolvedores de aplicativos. No entanto, os DBAs de aplicativos podem ficar facilmente isolados e perder
de vista as necessidades gerais de dados da organização e as práticas comuns de DBA.
Os DBAs de aplicativos colaboram de perto com analistas de dados, modeladores e arquitetos.
1.3.3.3 DBAs Processuais e de Desenvolvimento
DBAs procedurais lideram a revisão e administração de objetos de banco de dados procedurais. Um DBA procedural é especializado no desenvolvimento
e suporte de lógica procedural controlada e executada pelo DBMS: procedimentos armazenados, gatilhos e funções definidas pelo usuário (UDFs). O
DBA procedural garante que essa lógica processual seja planejada, implementada, testada e compartilhada (reutilizada).
Os DBAs de desenvolvimento se concentram nas atividades de design de dados, incluindo a criação e o gerenciamento de bancos de dados de uso
especial, como 'sandbox' ou áreas de exploração.
Em muitos casos, essas duas funções são combinadas em uma posição.

1.3.3.4 NSA
Os administradores de armazenamento de rede estão preocupados com o hardware e o software que suportam as matrizes de armazenamento de dados.
Vários sistemas de matriz de armazenamento de rede têm necessidades e requisitos de monitoramento diferentes do que um banco de dados simples
sistemas.
1.3.4 Tipos de Arquitetura de Banco de Dados
Um banco de dados pode ser classificado como centralizado ou distribuído. Um sistema centralizado gerencia um único banco de dados, enquanto um
sistema distribuído gerencia vários bancos de dados em vários sistemas. Os componentes de um sistema distribuído podem ser classificados dependendo
da autonomia dos sistemas componentes em dois tipos: federados (autônomos) ou não federados (não autônomos). A Figura 55 ilustra a diferença entre
centralizado e
distribuído.
Centralizado Distribuído, não Federado
Visualização do usuário Visualização do usuário
Local A Local A Local B Local C
Figura 55 Centralizado vs. Distribuído
1.3.4.1 Bancos de Dados Centralizados
Bancos de dados centralizados têm todos os dados em um sistema em um só lugar. Todos os usuários vêm a um sistema para acessar os dados. Para
determinados dados restritos, a centralização pode ser ideal, mas para dados que precisam estar amplamente disponíveis, bancos de dados centralizados
apresentam riscos. Por exemplo, se o sistema centralizado não estiver disponível, não há outras alternativas para acessar os dados.
1.3.4.2 Bancos de Dados Distribuídos
Os bancos de dados distribuídos possibilitam o acesso rápido aos dados em um grande número de nós. As tecnologias populares de banco de dados
distribuído são baseadas no uso de servidores de hardware comuns. Eles são projetados para escalar de servidores únicos para milhares de máquinas,
cada uma oferecendo computação e armazenamento locais. Em vez de depender de hardware para fornecer alta disponibilidade, o próprio software de
gerenciamento de banco de dados é projetado para replicar dados entre os servidores, fornecendo assim um serviço altamente disponível em um cluster
de computadores. Base de dados

176 • DMBOK2
o software de gerenciamento também é projetado para detectar e lidar com falhas. Embora qualquer computador possa falhar, é
improvável que o sistema geral falhe.
Alguns bancos de dados distribuídos implementam um paradigma computacional chamado MapReduce para melhorar ainda mais o
desempenho. No MapReduce, a solicitação de dados é dividida em vários pequenos fragmentos de trabalho, cada um dos quais pode
ser executado ou reexecutado em qualquer nó do cluster. Além disso, os dados são colocados nos nós de computação, fornecendo
largura de banda agregada muito alta em todo o cluster. Tanto o sistema de arquivos quanto o aplicativo são projetados para lidar
automaticamente com falhas de nó.
1.3.4.2.1 Bancos de Dados Federados
A Federação provisiona dados sem persistência adicional ou duplicação de dados de origem. Um sistema de banco de dados federado
mapeia vários sistemas de banco de dados autônomos em um único banco de dados federado. Os bancos de dados constituintes, às
vezes separados geograficamente, são interconectados por meio de uma rede de computadores. Eles permanecem autônomos, mas
participam de uma federação para permitir o compartilhamento parcial e controlado de seus dados. A federação fornece uma
alternativa para mesclar bancos de dados diferentes. Não há integração de dados real nos bancos de dados constituintes devido à
federação de dados; em vez disso, a interoperabilidade de dados gerencia a exibição dos bancos de dados federados como um objeto
grande (consulte o Capítulo 8). Em contraste, um sistema de banco de dados não federado é uma integração de SGBDs de
componentes que não são autônomos; eles são controlados, gerenciados e governados por um SGBD centralizado.
Os bancos de dados federados são melhores para projetos de integração heterogêneos e distribuídos, como integração de informações
corporativas, virtualização de dados, correspondência de esquema e gerenciamento de dados mestre.
As arquiteturas federadas diferem com base nos níveis de integração com os sistemas de banco de dados de componentes e na
extensão dos serviços oferecidos pela federação. Um FDBMS pode ser categorizado como fracamente ou fortemente acoplado.
Federado
Visualização do usuário
mapa mapa mapa
Local A Local B Local C
Figura 56 Bancos de dados federados

Sistemas fracamente acoplados requerem bancos de dados de componentes para construir seu próprio esquema federado. Um usuário
normalmente acessará outros sistemas de banco de dados de componentes usando uma linguagem de vários bancos de dados, mas isso
remove quaisquer níveis de transparência de localização, forçando o usuário a ter conhecimento direto do esquema federado. Um usuário
importa os dados necessários de outros bancos de dados de componentes e os integra aos seus próprios para formar um banco de dados federado.
esquema.
Sistemas fortemente acoplados consistem em sistemas de componentes que usam processos independentes para construir e publicar um
esquema federado integrado, conforme ilustrado na Figura 57. O mesmo esquema pode ser aplicado a todas as partes da federação, sem
replicação de dados.
Fortemente acoplado Fracamente acoplada
F F
mapa mapa mapa mapa
Local A Local B Local A Local B
Figura 57 Acoplamento
1.3.4.2.2 Banco de Dados Blockchain
Os bancos de dados Blockchain são um tipo de banco de dados federado usado para gerenciar transações financeiras com segurança. Eles
também podem ser usados para gerenciamento de contratos ou troca de informações de saúde. Existem dois tipos de estruturas: registros
individuais e blocos. Cada transação tem um registro. O banco de dados cria cadeias de grupos de transações (blocos) com limite de tempo
que também contêm informações do bloco anterior na cadeia. Os algoritmos de hash são
usado para criar informações sobre transações para armazenar em blocos enquanto o bloco é o final da cadeia. Uma vez por
novo bloco é criado, o hash do bloco antigo nunca deve ser alterado, o que significa que nenhuma transação contida nesse bloco pode ser
alterada. Qualquer alteração nas transações ou blocos (tamper) será aparente quando os valores de hash não corresponderem mais.
1.3.4.3 Virtualização / Plataformas em Nuvem
A virtualização (também chamada de 'computação em nuvem') fornece serviços de computação, software, acesso a dados e armazenamento
que não exigem conhecimento do usuário final sobre a localização física e a configuração do sistema que fornece o
178 • DMBOK2
Serviços). Paralelos são frequentemente traçados entre o conceito de computação em nuvem e a rede elétrica: os usuários finais consomem energia sem
precisar entender os dispositivos componentes ou a infraestrutura necessária para fornecer o serviço. No entanto, a virtualização pode ser local ou externa.
A computação em nuvem é uma evolução natural da ampla adoção de virtualização, arquiteturas orientadas a serviços e computação utilitária. Aqui estão
alguns métodos para implementar bancos de dados na nuvem:
• Imagem de máquina virtual: as plataformas de nuvem permitem que os usuários comprem instâncias de máquina virtual por um
tempo limitado. É possível executar um banco de dados nessas máquinas virtuais. Os usuários podem carregar sua própria imagem de
máquina com um banco de dados instalado ou usar imagens de máquina prontas que já incluem uma instalação otimizada de um banco
de dados.
• Banco de dados como serviço (DaaS): Algumas plataformas de nuvem oferecem opções para usar um banco de dados como serviço,
sem iniciar fisicamente uma instância de máquina virtual para o banco de dados. Nessa configuração, os proprietários de
aplicativos não precisam instalar e manter o banco de dados por conta própria. Em vez disso, o provedor de serviços de banco de dados é
responsável por instalar e manter o banco de dados, e os proprietários de aplicativos pagam de acordo com seu uso.
• Hospedagem gerenciada de banco de dados na nuvem: Aqui o banco de dados não é oferecido como um serviço; em vez disso, o
provedor de nuvem hospeda o banco de dados e o gerencia em nome do proprietário do aplicativo.
Os DBAs, em coordenação com os administradores de rede e sistema, precisam estabelecer uma abordagem sistemática de projeto integrado para incluir
padronização, consolidação, virtualização e automação de funções de backup e recuperação de dados, bem como a segurança dessas funções.
• Padronização/consolidação: A consolidação reduz o número de locais de armazenamento de dados e
organização possui, incluindo o número de armazenamentos de dados e processos em um data center. Com base na política de
governança de dados, os arquitetos de dados e os DBAs podem desenvolver os procedimentos padrão que incluem a identificação de dados
de missão crítica, duração da retenção de dados, procedimentos de criptografia de dados e políticas de replicação de dados.
• Virtualização de servidores: As tecnologias de virtualização permitem que equipamentos, como servidores de vários data centers, sejam
substituídos ou consolidados. A virtualização reduz as despesas operacionais e de capital e reduz o consumo de energia. As tecnologias de
virtualização também são usadas para criar desktops virtuais, que podem ser hospedados em data centers e alugados por assinatura. O
Gartner vê a virtualização como um catalisador para a modernização (Bittman, 2009). A virtualização fornece às operações de armazenamento
de dados muito mais flexibilidade no provisionamento de armazenamento em ambiente local ou em nuvem.
• Automação: A automação de dados envolve automatizar tarefas como provisionamento, configuração,
aplicação de patches, gerenciamento de versões e conformidade.
• Segurança: A segurança dos dados em sistemas virtuais precisa ser integrada à segurança existente de
infra-estruturas físicas (ver Capítulo 7).

1.3.5 Tipos de Processamento de Banco de Dados
Existem dois tipos básicos de processamento de banco de dados. ACID e BASE estão em extremidades opostas de um espectro, portanto,
os nomes coincidentes correspondentes às extremidades de um espectro de pH são úteis. O teorema CAP é usado para definir o quão
próximo um sistema distribuído pode corresponder tanto ao ACID quanto ao BASE.
1.3.5.1 ÁCIDO
A sigla ACID foi cunhada no início da década de 1980 como a restrição indispensável para alcançar a confiabilidade nas transações de banco
de dados. Por décadas, ele forneceu ao processamento de transações uma base confiável sobre a qual construir.34
• Atomicidade: Todas as operações são executadas, ou nenhuma delas é, de modo que, se uma parte da transação falhar,
então toda a transação falha.
• Consistência: A transação deve atender a todas as regras definidas pelo sistema em todos os momentos e deve anular metade
transações concluídas.
• Isolamento: Cada transação é independente em si mesma.
• Durabilidade: Uma vez concluída, a transação não pode ser desfeita.
As tecnologias ACID relacionais são as ferramentas dominantes no armazenamento de banco de dados relacional; a maioria usa SQL como
interface.
1.3.5.2 BASE
O aumento sem precedentes em volumes e variabilidade de dados, a necessidade de documentar e armazenar dados não estruturados, a
necessidade de cargas de trabalho de dados otimizadas para leitura e a subsequente necessidade de maior flexibilidade em dimensionamento,
design, processamento, custo e recuperação de desastres deram origem ao sistema diamétrico oposto de ACID, apropriadamente denominado
BASE:
• Basicamente Disponível: O sistema garante algum nível de disponibilidade aos dados mesmo quando há
falhas de nós. Os dados podem estar desatualizados, mas o sistema ainda dará e aceitará respostas.
• Soft State: Os dados estão em constante estado de fluxo; enquanto uma resposta pode ser dada, os dados não são
garantidamente atual.
• Consistência Eventual: Os dados eventualmente serão consistentes em todos os nós e em todos os bancos de dados,
mas nem todas as transações serão consistentes a cada momento.
34 Jim Gray estabeleceu o conceito. Haerder e Rueter (1983) cunharam o termo ACID.
180 • DMBOK2
Sistemas do tipo BASE são comuns em ambientes de Big Data. Grandes organizações online e empresas de mídia social geralmente usam
implementações BASE, pois a precisão imediata de todos os elementos de dados em todos os momentos não é necessária. A Tabela 12 resume as
diferenças entre ACID e BASE.
Tabela 12 ÁCIDO vs BASE
Item ÁCIDO BASE
Casting (estrutura de dados) O esquema deve existir Dinâmico

A estrutura da tabela existe Ajuste em tempo real
Dados de colunas digitados Armazenar dados diferentes
Consistência Forte consistência disponível Forte, Eventual ou Nenhum

Foco de Processamento Transacional Armazenamentos de valores-chave
Foco de Processamento Armazenamento de Lojas de colunas largas

História aplicativos de linha/coluna da década de 1970 Armazenamento não estruturado dos anos 2000
Escala Dependente do Produto Espalha dados automaticamente entre

servidores de commodities
Origem Mistura Código aberto
Transação Sim Possível
1.3.5.3 CAP
O Teorema CAP (ou Teorema de Brewer) foi desenvolvido em resposta a uma mudança para sistemas mais distribuídos (Brewer, 2000). O teorema
afirma que um sistema distribuído não pode cumprir todas as partes do ACID o tempo todo. Quanto maior o sistema, menor a conformidade. Um
sistema distribuído deve, em vez disso, negociar entre propriedades.
• Consistência: O sistema deve operar sempre conforme projetado e esperado.
• Disponibilidade: O sistema deve estar disponível quando solicitado e deve responder a cada solicitação.
• Tolerância de Partição: O sistema deve ser capaz de continuar as operações durante ocasiões de perda de dados ou
falha parcial do sistema.
O teorema CAP afirma que no máximo duas das três propriedades podem existir em qualquer sistema de dados compartilhados. Isso geralmente é
indicado com uma declaração 'escolha dois', ilustrada na Figura 58.
Teorema CAP Teorema CAP
"Escolhe dois" "Escolhe dois"
Tolerância de partição Tolerância de partição
Teorema CAP
"Escolhe dois"
Sem falhas do sistema
Figura 58 Teorema CAP

Um uso interessante desse teorema orienta o projeto da Arquitetura Lambda discutido no Capítulo 14. A Arquitetura Lambda usa dois caminhos para os
dados: um caminho de velocidade onde a disponibilidade e a tolerância de partição são mais importantes e um caminho de lote onde a consistência e a
disponibilidade são mais importantes.
1.3.6 Mídia de armazenamento de dados
Os dados podem ser armazenados em uma variedade de mídias, incluindo discos, memória volátil e unidades flash. Alguns sistemas podem combinar vários
tipos de armazenamento. As mais usadas são: Disk and Storage Area Networks (SAN), In Memory, Columnar Compression Solutions, Virtual Storage Area
Network VSAN, soluções de armazenamento baseadas em nuvem, identificação por radiofrequência (RFID), carteiras digitais, data centers e Private, Public,
e armazenamento em nuvem híbrida. (Consulte o Capítulo 14.)
1.3.6.1 Redes de disco e armazenamento (SAN)
O armazenamento em disco é um método muito estável de armazenamento de dados persistente. Vários tipos de disco podem existir no mesmo sistema.
Os dados podem ser armazenados de acordo com os padrões de uso, com os dados menos usados armazenados em discos de acesso mais lento, que
geralmente são mais baratos que os sistemas de disco de alto desempenho.
As matrizes de disco podem ser coletadas em redes de área de armazenamento (SAN). A movimentação de dados em uma SAN pode não exigir uma rede,
pois os dados podem ser movidos no backplane.
1.3.6.2 Na memória
Os bancos de dados na memória (IMDB) são carregados do armazenamento permanente para a memória volátil quando o sistema é ligado e todo o
processamento ocorre dentro do array de memória, proporcionando tempo de resposta mais rápido do que os sistemas baseados em disco. A maioria dos
bancos de dados na memória também possui recursos para definir e configurar a durabilidade em caso de imprevistos
desligar.
Se o aplicativo puder ser razoavelmente garantido para ajustar a maioria/todos os dados na memória, uma otimização significativa poderá ser disponibilizada
a partir de sistemas de banco de dados na memória. Esses IMDBs fornecem tempo de acesso aos dados mais previsível do que os mecanismos de
armazenamento em disco, mas exigem um investimento muito maior. Os IMDBs fornecem funcionalidade para processamento de análises em tempo real e
geralmente são reservados para isso devido ao investimento necessário.
1.3.6.3 Soluções de Compressão Colunar
Os bancos de dados baseados em colunas são projetados para lidar com conjuntos de dados nos quais os valores de dados são repetidos em grande parte.
Por exemplo, em uma tabela com 256 colunas, uma pesquisa por um valor que existe em uma linha recuperará todos os dados da linha (e será um pouco
vinculado ao disco). O armazenamento colunar reduz essa largura de banda de E/S armazenando dados de coluna
182 • DMBOK2
usando compressão – onde o estado (por exemplo) é armazenado como um ponteiro para uma tabela de estados, comprimindo
significativamente a tabela mestra.
1.3.6.4 Memória Flash
Avanços recentes no armazenamento de memória tornaram a memória flash ou unidades de estado sólido (SSDs) uma alternativa atraente
aos discos. A memória flash combina a velocidade de acesso do armazenamento baseado em memória com a persistência do
armazenamento baseado em disco.
1.3.7 Ambientes de Banco de Dados
Os bancos de dados são usados em uma variedade de ambientes durante o ciclo de vida de desenvolvimento de sistemas. Ao testar as
alterações, os DBAs devem estar envolvidos no design das estruturas de dados no ambiente de desenvolvimento. A equipe de DBA deve
implementar quaisquer alterações no ambiente de controle de qualidade e deve ser a única equipe que implementa alterações no ambiente
de produção. As mudanças de produção devem seguir estritamente os processos e procedimentos padrão.
Embora a maior parte da tecnologia de dados seja software executado em hardware de uso geral, ocasionalmente hardware especializado
é usado para dar suporte a requisitos exclusivos de gerenciamento de dados. Os tipos de hardware especializado incluem dispositivos de
dados – servidores criados especificamente para transformação e distribuição de dados. Esses servidores se integram à infraestrutura
existente diretamente como um plug-in ou perifericamente como uma conexão de rede.
1.3.7.1 Ambiente de Produção
O ambiente de produção é o ambiente técnico onde ocorrem todos os processos de negócios. A produção é de missão crítica – se esse
ambiente deixar de funcionar, os processos de negócios serão interrompidos, resultando em perdas nos resultados, bem como um impacto
negativo nos clientes que não conseguem acessar os serviços. Em uma emergência, ou para sistemas de serviço público, a perda
inesperada de função pode ser desastrosa.
O ambiente de produção é o ambiente 'real' de uma perspectiva de negócios. No entanto, para ter um ambiente de produção confiável,
outros ambientes de não produção devem existir e ser usados adequadamente. Por exemplo, ambientes de produção não devem ser
usados para desenvolvimento e teste, pois essas atividades colocam em risco os processos de produção e os dados.
1.3.7.2 Ambientes de Pré-produção
Os ambientes de pré-produção são usados para desenvolver e testar alterações antes que essas alterações sejam introduzidas no ambiente
de produção. Em ambientes de pré-produção, problemas com alterações podem ser detectados e resolvidos sem afetar os processos
normais de negócios. Para detectar possíveis problemas, a configuração dos ambientes de pré-produção deve ser muito semelhante ao
ambiente de produção.
Devido ao espaço e custo, geralmente não é possível replicar exatamente a produção nos ambientes de pré-produção. Quanto mais próximo no
caminho de desenvolvimento o ambiente de não produção estiver do ambiente de produção, mais próximo o ambiente de não produção precisará
corresponder ao ambiente de produção.
Qualquer desvio do equipamento e da configuração do sistema de produção pode criar problemas ou erros não relacionados à mudança,
complicando a pesquisa e a resolução do problema.
Tipos comuns de ambientes de pré-produção incluem desenvolvimento, teste, suporte e uso especial
ambientes.
1.3.7.2.1 Desenvolvimento
O ambiente de desenvolvimento geralmente é uma versão mais simples do ambiente de produção. Ele geralmente tem menos espaço em disco,
menos CPUs, menos RAM etc. Os desenvolvedores usam esse ambiente para criar e testar código para alterações em ambientes separados, que
são combinados no ambiente de controle de qualidade para testes de integração total.
O desenvolvimento pode ter muitas cópias de modelos de dados de produção, dependendo de como os projetos de desenvolvimento são
gerenciados. Organizações maiores podem dar aos desenvolvedores individuais seus próprios ambientes para gerenciar com todos os direitos
apropriados.
O ambiente de desenvolvimento deve ser o primeiro lugar onde todos os patches ou atualizações são aplicados para teste. Esse ambiente deve
ser isolado de e em hardware físico diferente dos ambientes de produção. Devido ao isolamento, os dados dos sistemas de produção podem
precisar ser copiados para os ambientes de desenvolvimento.
No entanto, em muitos setores, os dados de produção são protegidos por regulamentação. Não mova dados de ambientes de produção sem
primeiro determinar quais restrições existem para isso. (Consulte o Capítulo 7.)
1.3.7.2.2 Teste
O ambiente de teste é usado para executar testes de garantia de qualidade e aceitação do usuário e, em alguns casos, testes de estresse ou
desempenho. Para evitar que os resultados do teste sejam distorcidos devido a diferenças ambientais, o ambiente de teste idealmente também
tem o mesmo software e hardware que o ambiente de produção. Isso é especialmente importante para testes de desempenho. O teste pode ou
não ser conectado via rede aos sistemas de produção para ler os dados de produção. Os ambientes de teste nunca devem gravar em sistemas
de produção.
Os ambientes de teste atendem a muitos usos:
• Teste de Garantia de Qualidade (QA): Usado para testar a funcionalidade em relação aos requisitos.
• Teste de Integração: Usado para testar como um todo várias partes de um sistema que foi desenvolvido
ou atualizado de forma independente.
• Teste de aceitação do usuário (UAT): Usado para testar a funcionalidade do sistema da perspectiva do usuário.
Casos de uso são as entradas mais comuns para testes realizados neste ambiente.
• Teste de desempenho: usado para realizar testes de alto volume ou alta complexidade a qualquer momento, em vez de
ter que esperar por horas de folga ou afetar adversamente o horário de pico do sistema de produção.
184 • DMBOK2
1.3.7.2.3 Sandboxes ou Ambientes Experimentais
Um sandbox é um ambiente alternativo que permite conexões somente leitura para dados de produção e pode ser gerenciado pelos usuários.
Sandboxes são usadas para experimentar opções de desenvolvimento e testar hipóteses sobre dados ou mesclar dados de produção com
dados desenvolvidos pelo usuário ou dados suplementares obtidos de fontes externas.
Sandboxes são valiosas, por exemplo, ao realizar uma Prova de Conceito.
Um ambiente de sandbox pode ser um subconjunto do sistema de produção, isolado do processamento de produção, ou um ambiente
completamente separado. Os usuários do sandbox geralmente têm direitos CRUD sobre seu próprio espaço para que possam validar
rapidamente ideias e opções para alterações no sistema. Os DBAs geralmente têm pouco a ver com esses ambientes além de configurá-los,
conceder acesso e monitorar o uso. Se as áreas Sandbox estiverem situadas em sistemas de banco de dados de produção, elas devem ser
isoladas para evitar afetar adversamente as operações de produção. Esses ambientes nunca devem gravar de volta nos sistemas de produção.
Os ambientes de sandbox podem ser gerenciados por máquinas virtuais (VMs), a menos que os custos de licenciamento para instâncias
separadas se tornem proibitivos.
1.3.8 Organização do Banco de Dados
Os sistemas de armazenamento de dados fornecem uma maneira de encapsular as instruções necessárias para colocar dados em discos e
gerenciar o processamento, para que os desenvolvedores possam simplesmente usar instruções para manipular dados. Os bancos de dados
são organizados de três maneiras gerais: Hierárquica, Relacional e Não Relacional. Essas classes não são mutuamente exclusivas (veja a
Figura 59). Alguns sistemas de banco de dados podem ler e gravar dados organizados em estruturas relacionais e não relacionais.
Bancos de dados hierárquicos podem ser mapeados para tabelas relacionais. Arquivos simples com delimitadores de linha podem ser lidos
como tabelas com linhas e uma ou mais colunas podem ser definidas para descrever o conteúdo da linha.
NÃO
HIERARQUIA RELACIONAL RELACIONAL
(Esquema ativado (Esquema ativado
(Esquema de árvore)
Escreva) Ler)
Estrutura mais controlada Estrutura menos controlada
Figura 59 Espectro da Organização do Banco de Dados
1.3.8.1 Hierárquico
A organização hierárquica de banco de dados é o modelo de banco de dados mais antigo, usado nos primeiros SGBDs de mainframe, e é a
mais rígida das estruturas. Em bancos de dados hierárquicos, os dados são organizados em uma estrutura em forma de árvore com
relacionamentos pai/filho: cada pai pode ter muitos filhos, mas cada filho tem apenas um pai (também conhecido como relacionamento 1-
para-muitos). As árvores de diretórios são um exemplo de hierarquia. XML também usa um modelo hierárquico. Ele pode ser representado
como um banco de dados relacional, embora a estrutura real seja a de um caminho de passagem em árvore.
1.3.8.2 Relacional
As pessoas às vezes pensam que os bancos de dados relacionais são nomeados pela relação entre as tabelas. Este não é o caso.
Os bancos de dados relacionais são baseados na teoria dos conjuntos e na álgebra relacional, onde elementos de dados ou atributos
(colunas) são relacionados em tuplas (linhas). (Consulte o Capítulo 5.) Tabelas são conjuntos de relações com estrutura idêntica. As
operações de conjunto (como união, interseção e menos) são usadas para organizar e recuperar dados de bancos de dados relacionais,
na forma de Structured Query Language (SQL). Para gravar dados, a estrutura (esquema) deve ser conhecida antecipadamente (esquema
na gravação). Os bancos de dados relacionais são orientados a linhas.
O sistema de gerenciamento de banco de dados (DBMS) de um banco de dados relacional é chamado de RDBMS. Um banco de dados
relacional é a escolha predominante no armazenamento de dados que mudam constantemente. Variações em bancos de dados relacionais
incluem Multidimensional e Temporal.
1.3.8.2.1 Multidimensional
As tecnologias de banco de dados multidimensionais armazenam os dados em uma estrutura que permite a busca usando vários filtros
de elementos de dados simultaneamente. Esse tipo de estrutura é usado com mais frequência em Data Warehousing e Business
Intelligence. Alguns desses tipos de banco de dados são proprietários, embora a maioria dos bancos de dados grandes tenha a tecnologia
de cubo incorporada como objetos. O acesso aos dados usa uma variante do SQL chamada MDX ou Multidimensional eXpression.
1.3.8.2.2 Temporário
Um banco de dados temporal é um banco de dados relacional com suporte embutido para manipulação de dados envolvendo tempo. Os
aspectos temporais geralmente incluem tempo válido e tempo de transação. Esses atributos podem ser combinados para formar dados
bitemporais.
• O tempo válido é o prazo em que um fato é verdadeiro em relação à entidade que representa no mundo real.
• Tempo de transação é o período durante o qual um fato armazenado no banco de dados é considerado verdadeiro.
É possível ter outras linhas do tempo além do Tempo Válido e do Tempo de Transação, como Tempo de Decisão, no banco de dados.
Nesse caso, o banco de dados é chamado de banco de dados multitemporal em oposição a um banco de dados bitemporal.
Os bancos de dados temporais permitem que desenvolvedores de aplicativos e DBAs gerenciem dados atuais, propostos e históricos.
versões de dados no mesmo banco de dados.
186 • DMBOK2
1.3.8.3 Não relacional
Bancos de dados não relacionais podem armazenar dados como strings simples ou arquivos completos. Os dados nesses arquivos podem ser lidos de diferentes
maneiras, dependendo da necessidade (essa característica é chamada de 'esquema na leitura'). Bancos de dados não relacionais podem ser orientados a linhas,
mas isso não é obrigatório.
Um banco de dados não relacional fornece um mecanismo para armazenamento e recuperação de dados que emprega modelos de consistência menos restritos
do que bancos de dados relacionais tradicionais. As motivações para essa abordagem incluem simplicidade de design, dimensionamento horizontal e controle
mais preciso sobre a disponibilidade.
Bancos de dados não relacionais são geralmente chamados de NoSQL (que significa “Not Only SQL”). O principal fator de diferenciação é a própria estrutura de
armazenamento, onde a estrutura de dados não está mais vinculada a um design relacional tabular. Pode ser uma árvore, um gráfico, uma rede ou um pareamento
de valores-chave. A tag NoSQL enfatiza que algumas edições podem de fato suportar diretivas SQL convencionais. Esses bancos de dados geralmente são
armazenamentos de dados altamente otimizados destinados a operações simples de recuperação e anexação. O objetivo é melhorar o desempenho, especialmente
no que diz respeito à latência e à taxa de transferência. Bancos de dados NoSQL são cada vez mais usados em Big Data e aplicações web em tempo real.
1.3.8.3.1 Orientado por coluna
Os bancos de dados orientados a colunas são usados principalmente em aplicativos de Business Intelligence porque podem compactar dados redundantes. Por
exemplo, uma coluna de ID de estado tem apenas valores exclusivos, em vez de um valor para cada
milhões de linhas.
Existem compensações entre a organização orientada a colunas (não relacional) e orientada a linhas (geralmente relacional).
• A organização orientada por colunas é mais eficiente quando um agregado precisa ser calculado em muitos
linhas. Isso só vale para um subconjunto notavelmente menor de todas as colunas de dados, porque ler esse
um subconjunto menor de dados pode ser mais rápido do que ler todos os dados.
• A organização orientada por colunas é mais eficiente quando novos valores de uma coluna são fornecidos para todas as linhas
de uma só vez, porque os dados da coluna podem ser gravados de forma eficiente para substituir os dados da coluna antiga sem
tocando em quaisquer outras colunas das linhas.
• A organização orientada por linhas é mais eficiente quando são necessárias muitas colunas de uma única linha no
mesmo tempo, e quando o tamanho da linha é relativamente pequeno, pois a linha inteira pode ser recuperada com um único disco
procurar.
• A organização orientada por linha é mais eficiente ao escrever uma nova linha se todos os dados da linha forem fornecidos
ao mesmo tempo; a linha inteira pode ser gravada com uma única busca de disco.
• Na prática, os layouts de armazenamento orientados a linhas são adequados para processamento de transações online (OLTP)-
como cargas de trabalho, que são mais carregadas com transações interativas. Armazenamento orientado a colunas
os layouts são adequados para cargas de trabalho do tipo OLAP (Online Analytical Processing) (por exemplo, data
warehouses) que normalmente envolvem um número menor de consultas altamente complexas sobre todos os dados
(possivelmente terabytes).
1.3.8.3.2 Espacial
Um banco de dados espacial é otimizado para armazenar e consultar dados que representam objetos definidos em um espaço geométrico.
Bancos de dados espaciais suportam vários tipos primitivos (formas geométricas simples como caixa, retângulo, cubo, cilindro, etc.) e
geometrias compostas por coleções de pontos, linhas e formas.
Os sistemas de banco de dados espaciais usam índices para pesquisar valores rapidamente; a forma como a maioria dos bancos de dados indexam dados não
é ideal para consultas espaciais. Em vez disso, os bancos de dados espaciais usam um índice espacial para acelerar as operações do banco de dados.
Os bancos de dados espaciais podem executar uma ampla variedade de operações espaciais. De acordo com o padrão Open Geospatial
Consortium, um banco de dados espacial pode realizar uma ou mais das seguintes operações:
• Medidas Espaciais: Calcula o comprimento da linha, a área do polígono, a distância entre geometrias, etc.
• Funções Espaciais: Modifica recursos existentes para criar novos; por exemplo, fornecendo um buffer
em torno deles, feições de interseção, etc.
• Predicados Espaciais: Permite consultas de verdadeiro/falso sobre relacionamentos espaciais entre geometrias.
Os exemplos incluem "Dois polígonos se sobrepõem?" ou “Existe uma residência localizada dentro de uma milha da
área do aterro proposto?”
• Construtores de Geometria: Cria novas geometrias, geralmente especificando os vértices (pontos ou nós)
que definem a forma.
• Funções de observador: consultas que retornam informações específicas sobre um recurso, como a localização de
o centro de um círculo.
1.3.8.3.3 Objeto / Multimídia
Um banco de dados multimídia inclui um sistema de gerenciamento de armazenamento hierárquico para o gerenciamento eficiente de uma
hierarquia de mídia de armazenamento magnético e óptico. Ele também inclui uma coleção de classes de objetos, que representam a base do
sistema.
1.3.8.3.4 Banco de Dados de Arquivo Simples
Um banco de dados de arquivo simples descreve qualquer um dos vários meios para codificar um conjunto de dados como um único arquivo. Um arquivo
simples pode ser um arquivo de texto simples ou um arquivo binário. Estritamente, um banco de dados de arquivo simples consiste em nada além de dados e
contém registros que podem variar em tamanho e delimitadores. Mais amplamente, o termo refere-se a qualquer banco de dados que existe em um único arquivo no
188 • DMBOK2
forma de linhas e colunas, sem relacionamentos ou links entre registros e campos, exceto a estrutura. Arquivos de texto simples geralmente contêm um
registro por linha. Uma lista de nomes, endereços e números de telefone, escritos à mão em uma folha de papel, é um exemplo de banco de dados de
arquivo simples. Arquivos simples são usados não apenas como ferramentas de armazenamento de dados em sistemas DBMS, mas também como
ferramentas de transferência de dados. Os bancos de dados do Hadoop usam armazenamento de arquivos simples.
1.3.8.3.5 Par de chave-valor
Os bancos de dados de pares de valores-chave contêm conjuntos de dois itens: um identificador de chave e um valor. Existem alguns usos específicos
desses tipos de bancos de dados.
• Bancos de dados de documentos: bancos de dados orientados a documentos contêm coleções de arquivos, incluindo
estrutura e dados. A cada documento é atribuída uma chave. Bancos de dados orientados a documentos mais avançados também
pode armazenar atributos para o conteúdo do documento, como datas ou tags. Este tipo de banco de dados pode armazenar
documentos completos e incompletos. Bancos de dados de documentos podem usar XML ou JSON (Java Script
Notação de Objeto).
• Bancos de dados gráficos : os bancos de dados gráficos armazenam pares de valores-chave onde o foco está no relacionamento
entre os nós, em vez de nos próprios nós.
1.3.8.3.6 Triplestore
Uma entidade de dados composta de sujeito-predicado-objeto é conhecida como triplestore. Na terminologia Resource Description Framework (RDF), um
triplestore é composto por um assunto que denota um recurso, o predicado que expressa uma relação entre o assunto e o objeto e o próprio objeto. Um
triplestore é um banco de dados criado especificamente para o armazenamento e recuperação de triplos na forma de expressões sujeito-predicado-objeto.
Os triplestores podem ser amplamente classificados em três categorias: triplestores nativos, triplestores com suporte de RDBMS e triplestores NoSQL.
• Triplestores nativos são aqueles que são implementados do zero e exploram o modelo de dados RDF para
armazenar e acessar com eficiência os dados RDF.
• Os armazenamentos triplos com suporte de RDBMS são construídos adicionando uma camada específica de RDF a um RDBMS existente.
• NoSQL Triplestores estão sendo investigados como possíveis gerenciadores de armazenamento para RDF.
Os bancos de dados Triplestore são os melhores para gerenciamento de taxonomia e dicionário de sinônimos, integração de dados vinculados e portais de
conhecimento.
1.3.9 Bancos de Dados Especializados
Algumas situações especializadas requerem tipos especializados de bancos de dados que são gerenciados de forma diferente dos bancos de dados
relacionais tradicionais. Exemplos incluem:

• Os aplicativos de projeto e fabricação assistidos por computador (CAD / CAM) exigem um objeto
banco de dados, assim como a maioria dos aplicativos de tempo real incorporados.
• Os Sistemas de Informação Geográfica (SIG) fazem uso de bases de dados geoespaciais especializadas, que têm
pelo menos atualizações anuais de seus Dados de Referência. Alguns GIS especializados são usados para serviços públicos (eletricidade
rede, linhas de gás, etc.), para telecomunicações em gerenciamento de rede ou para navegação oceânica.
• Aplicativos de carrinho de compras encontrados na maioria dos sites de varejo online, usam bancos de dados XML para
armazenam inicialmente os dados do pedido do cliente e podem ser usados em tempo real por bancos de dados de mídia social para anúncios
colocação em outros sites.
Alguns desses dados são então copiados para um ou mais bancos de dados ou data warehouses OLTP (Online Transaction Processing) tradicionais. Além disso,
muitos aplicativos de fornecedores prontos para uso podem usar seus próprios bancos de dados proprietários. No mínimo, seus esquemas serão proprietários e
principalmente ocultos, mesmo que fiquem em cima de
SGBDs relacionais tradicionais.
1.3.10 Processos Comuns de Banco de Dados
Todos os bancos de dados, não importa o tipo, compartilham os seguintes processos de alguma forma.
1.3.10.1 Arquivamento
O arquivamento é o processo de mover dados de uma mídia de armazenamento imediatamente acessível para uma mídia com menor desempenho de recuperação.
Os arquivos podem ser restaurados no sistema de origem para uso de curto prazo. Os dados que não são ativamente necessários para dar suporte aos processos de
aplicativos devem ser movidos para um arquivo em disco, fita ou jukebox de CD/DVD menos caro. A restauração de um arquivo deve ser uma questão de simplesmente
copiar os dados do arquivo de volta para o sistema.
Os processos de arquivamento devem estar alinhados com a estratégia de particionamento para garantir disponibilidade e retenção ideais. Uma abordagem robusta
envolve:
• Criação de uma área de armazenamento secundária, preferencialmente em um servidor de banco de dados secundário
• Particionamento de tabelas de banco de dados existentes em blocos de arquivamento
• Replicar os dados que são necessários com menos frequência para o banco de dados separado
• Criação de backups em fita ou disco
• Criação de trabalhos de banco de dados que eliminam dados desnecessários periodicamente
É aconselhável agendar testes regulares de restauração de arquivos para evitar surpresas em caso de emergência.
Quando são feitas alterações na tecnologia ou estrutura de um sistema de produção, o arquivo também precisa ser avaliado para garantir que os dados movidos do
arquivo para o armazenamento atual sejam legíveis. Existem várias maneiras de lidar com arquivos fora de sincronia:
190 • DMBOK2
• Determine se ou quanto do arquivo deve ser preservado. O que não é necessário pode ser
considerado purgado.
• Para grandes mudanças na tecnologia, restaure os arquivos no sistema de origem antes da tecnologia
alterar, atualizar ou migrar para a nova tecnologia e rearquivar os dados usando a nova tecnologia.
• Para arquivos de alto valor onde as estruturas do banco de dados de origem mudam, restaure o arquivo, faça qualquer
alterações nas estruturas de dados e arquivar os dados com a nova estrutura.
• Para arquivos de acesso infrequente onde a tecnologia de origem ou estrutura muda, mantenha uma versão pequena
do sistema antigo rodando com acesso limitado, e extraia dos arquivos usando o sistema antigo como
precisava.
Arquivos que não podem ser recuperados com a tecnologia atual são inúteis, e manter máquinas antigas por perto para ler arquivos que não podem
ser lidos de outra forma não é eficiente ou econômico.
1.3.10.2 Projeções de Capacidade e Crescimento
Pense em um banco de dados como uma caixa, os dados como frutas e as despesas gerais (índices, etc.) como material de embalagem. A caixa tem
divisórias, e frutas e material de embalagem vão nas células:
• Primeiro, decida o tamanho da caixa que conterá todas as frutas e qualquer material de embalagem necessário - esse é o
Capacidade.
• Quanta fruta vai para a caixa e com que rapidez?
• Quanta fruta sai da caixa e com que rapidez?
Decida se a caixa permanecerá do mesmo tamanho ao longo do tempo ou deve ser expandida ao longo do tempo para conter mais frutas. Essa
projeção de quanto e com que rapidez a caixa deve se expandir para conter frutas e material de embalagem recebidos é a projeção de crescimento.
Se a caixa não puder expandir, a fruta deve ser retirada tão rápido quanto é colocada, e a projeção de crescimento é zero.
Quanto tempo a fruta deve ficar nas células? Se a fruta em uma célula ficar desidratada ao longo do tempo, ou por qualquer motivo não for tão útil,
essa fruta deve ser colocada em uma caixa separada para armazenamento de longo prazo (ou seja, arquivada)? Haverá necessidade de trazer essa
fruta desidratada de volta para a caixa principal? Mover a fruta para outra caixa com a capacidade de movê-la de volta para a primeira caixa é uma
parte importante do arquivamento. Isso permite que a caixa não precise ser expandida com tanta frequência ou tanto.
Se uma fruta ficar estagnada demais para ser usada, jogue-a fora (ou seja, limpe os dados).
1.3.10.3 Change Data Capture (CDC)
A captura de dados de alteração refere-se ao processo de detectar que os dados foram alterados e garantir que as informações relevantes para a
alteração sejam armazenadas adequadamente. Muitas vezes referido como replicação baseada em log, o CDC é um método não invasivo
maneira de replicar alterações de dados para um destino sem afetar a origem. Em um contexto de CDC simplificado, um sistema de computador
possui dados que podem ter sido alterados em relação a um momento anterior e um segundo sistema de computador precisa refletir a mesma
alteração. Em vez de enviar todo o banco de dados pela rede para refletir apenas algumas pequenas alterações, a ideia é apenas enviar o que
mudou (deltas), para que o sistema receptor possa fazer as atualizações apropriadas.
Existem dois métodos diferentes para detectar e coletar alterações: controle de versão de dados, que avalia colunas que identificam linhas que
foram alteradas (por exemplo, colunas de carimbo de data/hora da última atualização, colunas de número de versão, colunas de indicador de
status) ou lendo logs que documentam as mudanças e permitir que sejam replicadas em sistemas secundários.
1.3.10.4 Purga
É incorreto supor que todos os dados residirão para sempre no armazenamento primário. Eventualmente, os dados preencherão o espaço
disponível e o desempenho começará a diminuir. Nesse ponto, os dados precisarão ser arquivados, limpos ou ambos. Tão importante quanto isso,
alguns dados serão degradados em valor e não vale a pena mantê-los. A limpeza é o processo de remover completamente os dados da mídia de
armazenamento de modo que não possam ser recuperados. Um dos principais objetivos do gerenciamento de dados é que o custo de manutenção
dos dados não exceda seu valor para a organização. A limpeza de dados reduz custos e riscos. Os dados a serem eliminados são geralmente
considerados obsoletos e desnecessários, mesmo para fins regulatórios. Alguns dados podem se tornar uma responsabilidade se mantidos por
mais tempo do que o necessário. A purga reduz os riscos de uso indevido.
1.3.10.5 Replicação
A replicação de dados significa que os mesmos dados são armazenados em vários dispositivos de armazenamento. Em algumas situações, ter
bancos de dados duplicados é útil, como em um ambiente de alta disponibilidade em que a distribuição da carga de trabalho entre bancos de
dados idênticos em diferentes hardwares ou até mesmo data centers pode preservar a funcionalidade durante os horários de pico de uso ou
desastres.
A replicação pode ser ativa ou passiva:
• A replicação ativa é realizada recriando e armazenando os mesmos dados em cada réplica de cada
outra réplica.
• A replicação passiva envolve recriar e armazenar dados em uma única réplica primária e, em seguida,
transformando seu estado resultante em outras réplicas secundárias.
A replicação tem duas dimensões de dimensionamento:
• A escala de dados horizontal tem mais réplicas de dados.
• A escala de dados vertical tem réplicas de dados localizadas geograficamente mais distantes.
A replicação multimestre, em que as atualizações podem ser enviadas para qualquer nó de banco de dados e depois se propagarem para outros
servidores, geralmente é desejada, mas aumenta a complexidade e o custo.

192 • DMBOK2
A transparência de replicação ocorre quando os dados são replicados entre servidores de banco de dados para que as informações permaneçam
consistentes em todo o sistema de banco de dados e os usuários não possam dizer ou mesmo saber qual cópia de banco de dados está usando.
Os dois padrões de replicação primários são espelhamento e envio de logs (consulte a Figura 60).
• No espelhamento, as atualizações do banco de dados primário são replicadas imediatamente (relativamente falando) para o
banco de dados secundário, como parte de um processo de confirmação de duas fases.
• No envio de logs, um servidor secundário recebe e aplica cópias da transação do banco de dados primário
registros em intervalos regulares.
A escolha do método de replicação depende de quão críticos são os dados e quão importante é que o failover para o servidor secundário seja imediato. O
espelhamento geralmente é uma opção mais cara do que o envio de logs. Para um servidor secundário, o espelhamento é efetivo; o envio de logs pode
ser usado para atualizar servidores secundários adicionais.
Envio de Logs Espelhamento
Local A Local B Local A Local B

Log Log
crio Aplique
sincronizar
dados dados dados
Figura 60 Envio de Log vs. Espelhamento
1.3.10.6 Resiliência e Recuperação
A resiliência em bancos de dados é a medida de quão tolerante um sistema é a condições de erro. Se um sistema pode tolerar um alto nível de erros de
processamento e ainda funcionar conforme o esperado, ele é altamente resiliente. Se um aplicativo travar na primeira condição inesperada, esse sistema
não é resiliente. Se o banco de dados puder detectar e abortar ou se recuperar automaticamente de erros comuns de processamento (consulta
descontrolada, por exemplo), ele é considerado resiliente. Sempre há algumas condições que nenhum sistema pode detectar antecipadamente, como uma
falha de energia e
essas condições são consideradas desastres.
Três tipos de recuperação fornecem diretrizes sobre a rapidez com que a recuperação ocorre e no que ela se concentra:
• A recuperação imediata de alguns problemas às vezes pode ser resolvida por meio do design; por exemplo,
prever e resolver automaticamente problemas, como aqueles que podem ser causados por um failover para
sistema de backup.
• Recuperação crítica refere-se a um plano para restaurar o sistema o mais rápido possível para minimizar
atrasos ou paralisações de processos de negócios.
• A recuperação não crítica significa que a restauração da função pode ser adiada até que os sistemas mais
críticos foram restaurados.
Erros de processamento de dados incluem falhas de carregamento de dados, falhas de retorno de consulta e obstáculos à conclusão de ETL ou outros
processos. As formas comuns de aumentar a resiliência em sistemas de processamento de dados são interceptar e redirecionar dados que causam erros,
detectar e ignorar dados que causam erros e implementar sinalizadores no processamento de etapas concluídas para evitar o reprocessamento de dados
ou a repetição de etapas concluídas ao reiniciar um processo.
Cada sistema deve exigir um certo nível de resiliência (alto ou baixo). Alguns aplicativos podem exigir que qualquer erro interrompa todo o processamento
(baixa resiliência), enquanto outros podem exigir apenas que os erros sejam interceptados e redirecionados para revisão, se não totalmente ignorados.
Para dados extremamente críticos, o DBA precisará implementar um padrão de replicação no qual os dados sejam movidos para outra cópia do banco de
dados em um servidor remoto. No caso de falha do banco de dados, os aplicativos podem fazer "fail over" no banco de dados remoto e continuar o
processamento.
1.3.10.7 Retenção
A retenção de dados refere-se a quanto tempo os dados são mantidos disponíveis. O planejamento de retenção de dados deve fazer parte do design do
banco de dados físico. Os requisitos de retenção também afetam o planejamento de capacidade.
A segurança de dados também afeta os planos de retenção de dados, pois alguns dados precisam ser retidos por prazos específicos por motivos legais.
A não retenção de dados pelo período de tempo adequado pode ter consequências legais. Da mesma forma, também existem regulamentos relacionados
à eliminação de dados. Os dados podem se tornar um passivo se mantidos por mais tempo do que o especificado.
As organizações devem formular políticas de retenção com base em requisitos regulatórios e diretrizes de gerenciamento de risco. Essas políticas devem
orientar as especificações para limpeza e arquivamento de dados.
1.3.10.8 Fragmentação
O sharding é um processo em que pequenos pedaços do banco de dados são isolados e podem ser atualizados independentemente de outros shards,
de modo que a replicação é apenas uma cópia de arquivo. Como os fragmentos são pequenos, as atualizações/substituições podem ser ideais.
2. Atividades
As duas atividades principais em Operações e Armazenamento de Dados são Suporte à Tecnologia de Banco de Dados e Suporte a Operações de Banco
de Dados. O Suporte à Tecnologia de Banco de Dados é específico para selecionar e manter o software que
194 • DMBOK2
armazena e gerencia os dados. O suporte a operações de banco de dados é específico para os dados e processos que o software
gerencia.
2.1 Gerenciar Tecnologia de Banco de Dados
O gerenciamento da tecnologia de banco de dados deve seguir os mesmos princípios e padrões para o gerenciamento de qualquer tecnologia.
O principal modelo de referência para gerenciamento de tecnologia é a Information Technology Infrastructure Library (ITIL), um modelo de processo
de gerenciamento de tecnologia desenvolvido no Reino Unido. Os princípios ITIL se aplicam ao gerenciamento de tecnologia de dados.35
2.1.1 Compreender as características da tecnologia de banco de dados
É importante entender como a tecnologia funciona e como ela pode agregar valor no contexto de um determinado negócio. O DBA, juntamente com
o restante das equipes de serviços de dados, trabalha em estreita colaboração com os usuários e gerentes de negócios para entender as
necessidades de dados e informações do negócio. DBAs e Arquitetos de Banco de Dados combinam seu conhecimento das ferramentas disponíveis
com os requisitos de negócios para sugerir as melhores aplicações possíveis de tecnologia para atender às necessidades organizacionais.
Os profissionais de dados devem primeiro entender as características de uma tecnologia de banco de dados candidata antes de determinar qual
recomendar como solução. Por exemplo, tecnologias de banco de dados que não possuem recursos baseados em transações (por exemplo,
confirmação e reversão) não são adequadas para situações operacionais que dão suporte a processos de ponto de venda.
Não presuma que um único tipo de arquitetura de banco de dados ou DBMS funcione para todas as necessidades. A maioria das organizações tem
várias ferramentas de banco de dados instaladas para executar uma variedade de funções, desde ajuste de desempenho a backups, até o
gerenciamento do próprio banco de dados. Apenas alguns desses conjuntos de ferramentas têm padrões obrigatórios.
2.1.2 Avaliar a Tecnologia de Banco de Dados
A seleção de software de SGBD estratégico é particularmente importante. O software DBMS tem um grande impacto na integração de dados,
desempenho de aplicativos e produtividade dos negócios. Alguns dos fatores a serem considerados na hora de escolher
O software SGBD inclui:
• Arquitetura e complexidade do produto
• Limites de volume e velocidade, incluindo taxa de streaming
• Perfil do aplicativo, como processamento de transações, Business Intelligence e perfis pessoais
• Funcionalidade específica, como suporte para cálculo temporal
35 http://bit.ly/1gA4mpr.
• Plataforma de hardware e suporte ao sistema operacional
• Disponibilidade de ferramentas de software de suporte
• Referências de desempenho, incluindo estatísticas em tempo real
• Escalabilidade
• Requisitos de software, memória e armazenamento
• Resiliência, incluindo tratamento de erros e relatórios
Alguns fatores não estão diretamente relacionados à tecnologia em si, mas sim à organização compradora e aos fornecedores de ferramentas. Por
exemplo:
• Apetite organizacional por risco técnico
• Fornecimento disponível de profissionais técnicos treinados
• Custo de propriedade, como licenciamento, manutenção e recursos de computação
• Reputação do fornecedor
• Política de suporte ao fornecedor e cronograma de lançamento

• Referências de clientes
A despesa do produto, incluindo administração, licenciamento e suporte, não deve exceder o valor do produto para o negócio. Idealmente, a tecnologia
deve ser tão fácil de usar, automonitorada e autoadministrada quanto possível. Se não for, pode ser necessário trazer funcionários com experiência no
uso da ferramenta.
É uma boa ideia começar com um pequeno projeto piloto ou uma prova de conceito (POC), para ter uma boa ideia dos verdadeiros custos e benefícios
antes de prosseguir com uma implementação de produção completa.
2.1.3 Gerenciar e monitorar a tecnologia de banco de dados
Os DBAs geralmente servem como suporte técnico de Nível 2, trabalhando com help desks e suporte de fornecedores de tecnologia para entender,
analisar e resolver problemas de usuários. A chave para a compreensão e uso eficaz de qualquer tecnologia é o treinamento. As organizações devem
garantir que tenham planos e orçamentos de treinamento para todos os envolvidos
na implementação, suporte e uso de tecnologia de dados e banco de dados. Os planos de treinamento devem incluir níveis apropriados de treinamento
cruzado para melhor apoiar o desenvolvimento de aplicativos, especialmente o desenvolvimento ágil. Os DBAs devem ter conhecimento prático das
habilidades de desenvolvimento de aplicativos, como modelagem de dados, análise de casos de uso e acesso a dados de aplicativos.
O DBA será responsável por garantir que os bancos de dados tenham backups regulares e por realizar testes de recuperação.
No entanto, se os dados desses bancos de dados precisarem ser mesclados com outros dados existentes em um ou mais bancos de dados, pode
haver um desafio de integração de dados. Os DBAs não devem simplesmente mesclar dados. Em vez disso, eles devem trabalhar com outras partes
interessadas para garantir que os dados possam ser integrados de forma correta e eficaz.
Quando uma empresa requer uma nova tecnologia, os DBAs trabalharão com usuários de negócios e desenvolvedores de aplicativos para garantir o
uso mais eficaz da tecnologia, explorar novas aplicações da tecnologia e resolver quaisquer problemas ou questões que surjam de seu uso. Os DBAs
então implantam novos produtos de tecnologia em

196 • DMBOK2
ambientes de produção e produção. Eles precisarão criar e documentar processos e procedimentos para administrar o produto com o mínimo de esforço e despesa.
2.2 Gerenciar Bancos de Dados
O suporte de banco de dados, conforme fornecido por DBAs e Administradores de Armazenamento de Rede (NSAs), está no centro do gerenciamento de dados.
Os bancos de dados residem em áreas de armazenamento gerenciadas. O armazenamento gerenciado pode ser tão pequeno quanto uma unidade de disco em um
computador pessoal (gerenciado pelo sistema operacional) ou tão grande quanto matrizes RAID em uma rede de área de armazenamento ou SAN. A mídia de
backup também é um armazenamento gerenciado.
Os DBAs gerenciam vários aplicativos de armazenamento de dados atribuindo estruturas de armazenamento, mantendo bancos de dados físicos (incluindo modelos
de dados físicos e layouts físicos dos dados, como atribuições a arquivos específicos ou áreas de disco) e estabelecendo ambientes DBMS em servidores.
2.2.1 Compreender os Requisitos
2.2.1.1 Definir Requisitos de Armazenamento
DBAs estabelecem sistemas de armazenamento para aplicativos DBMS e sistemas de armazenamento de arquivos para suportar NoSQL. NSAs e DBAs juntos
desempenham um papel vital no estabelecimento de sistemas de armazenamento de arquivos. Os dados entram na mídia de armazenamento durante as operações
comerciais normais e, dependendo dos requisitos, podem permanecer permanente ou temporariamente. É importante planejar a adição de espaço adicional bem
antes de quando esse espaço for realmente necessário. Fazer qualquer tipo de manutenção em caso de emergência é um risco.
Todos os projetos devem ter uma estimativa inicial de capacidade para o primeiro ano de operação e uma projeção de crescimento para os próximos anos. A
capacidade e o crescimento devem ser estimados não apenas para o espaço que os próprios dados possuem, mas também para índices, logs e quaisquer imagens
redundantes, como espelhos.
Os requisitos de armazenamento de dados devem levar em conta a regulamentação relacionada à retenção de dados. Por motivos legais, as organizações são
obrigadas a reter alguns dados por períodos definidos (consulte o Capítulo 9). Em alguns casos, eles também podem ser obrigados a limpar os dados após um
período definido. É uma boa ideia discutir as necessidades de retenção de dados com os proprietários dos dados em tempo de design e chegar a um acordo sobre
como tratar os dados ao longo de seu ciclo de vida.
Os DBAs trabalharão com desenvolvedores de aplicativos e outras equipes de operações, incluindo administradores de servidor e armazenamento, para implementar
o plano de retenção de dados aprovado.
2.2.1.2 Identificar padrões de uso
Os bancos de dados têm padrões de uso previsíveis. Os tipos básicos de padrões incluem:
• Baseado em transações
• Grande conjunto de dados baseado em gravação ou recuperação
• Com base no tempo (mais pesado no final do mês, mais leve nos finais de semana, etc.),
• Baseado em localização (áreas mais densamente povoadas têm mais transações, etc.)
• Baseado em prioridade (alguns departamentos ou IDs de lote têm prioridade mais alta do que outros)
Alguns sistemas terão uma combinação desses padrões básicos. Os DBAs precisam ser capazes de prever fluxos e refluxos de padrões de uso e ter processos
implementados para lidar com picos (como governadores de consulta ou gerenciamento de prioridade), bem como para aproveitar vales (processos de atraso que
precisam de grandes quantidades de recursos até um vale padrão existe). Essas informações podem ser usadas para manter o desempenho do banco de dados.
2.2.1.3 Definir Requisitos de Acesso
O acesso a dados inclui atividades relacionadas ao armazenamento, recuperação ou atuação em dados armazenados em um banco de dados ou outro repositório.
Data Access é simplesmente a autorização para acessar diferentes arquivos de dados.
Existem várias linguagens, métodos e formatos padrão para acessar dados de bancos de dados e outros repositórios: SQL, ODBC, JDBC, XQJ, ADO.NET, XML, X
Query, X Path e Web Services para sistemas do tipo ACID. Os padrões de método de acesso do tipo BASE incluem C, C++, REST, XML e Java36. Alguns padrões
permitem a tradução de dados de não estruturados (como HTML ou arquivos de texto livre) para estruturados (como XML ou SOL).
Arquitetos de dados e DBAs podem ajudar as organizações a selecionar métodos e ferramentas apropriados necessários para dados
Acesso.
2.2.2 Plano de Continuidade de Negócios
As organizações precisam planejar a continuidade dos negócios em caso de desastre ou evento adverso que afete seus sistemas e sua capacidade de usar seus
dados. Os DBAs devem certificar-se de que existe um plano de recuperação para todos os bancos de dados e servidores de banco de dados, abrangendo cenários
que podem resultar em perda ou corrupção de dados, como:
• Perda do servidor de banco de dados físico
• Perda de um ou mais dispositivos de armazenamento em disco
• Perda de um banco de dados, incluindo o DBMS Master Database, banco de dados de armazenamento temporário, log de transações
segmento, etc
• Corrupção do índice do banco de dados ou páginas de dados
• Perda do banco de dados ou dos sistemas de arquivos do segmento de log
• Perda de arquivos de backup de banco de dados ou log de transações
36 http://bit.ly/1rWAUxS (acessado em 28/02/2016) tem uma lista de todos os métodos de acesso a dados para sistemas do tipo BASE.
198 • DMBOK2
Cada banco de dados deve ser avaliado quanto à criticidade para que sua restauração possa ser priorizada. Alguns bancos de dados
serão essenciais para as operações de negócios e precisarão ser restaurados imediatamente. Bancos de dados menos críticos não serão
restaurados até que os sistemas primários estejam funcionando. Ainda outros podem não precisar ser restaurados; por exemplo, se forem
apenas cópias que são atualizadas quando carregadas.
A gerência e o grupo de continuidade de negócios da organização, se houver, devem revisar e aprovar o plano de recuperação de dados.
O grupo DBA deve revisar regularmente os planos quanto à precisão e abrangência. Mantenha uma cópia do plano, juntamente com todo
o software necessário para instalar e configurar o SGBD, instruções e códigos de segurança (por exemplo, a senha do administrador) em
um local seguro e externo em caso de desastre.
Nenhum sistema pode ser recuperado de um desastre se os backups estiverem indisponíveis ou ilegíveis. Backups regulares são
essenciais para qualquer esforço de recuperação, mas se forem ilegíveis, são piores do que inúteis; o tempo de processamento para fazer
os backups ilegíveis terá sido desperdiçado, juntamente com a oportunidade de corrigir o problema que tornou os backups ilegíveis.
Mantenha todos os backups em um local seguro fora do local.
2.2.2.1 Fazer Backups
Faça backups dos bancos de dados e, se apropriado, dos logs de transações do banco de dados. O Acordo de Nível de Serviço (SLA) do
sistema deve especificar a frequência de backup. Equilibre a importância dos dados com o custo de protegê-los. Para bancos de dados
grandes, backups frequentes podem consumir grandes quantidades de armazenamento em disco e recursos do servidor. Além dos backups
incrementais, faça periodicamente um backup completo de cada banco de dados.
Além disso, os bancos de dados devem residir em uma área de armazenamento gerenciada, de preferência um array RAID em uma rede
de área de armazenamento ou SAN, com backup diário em mídia de armazenamento separada. Para bancos de dados OLTP, a frequência
dos backups do log de transações dependerá da frequência de atualização e da quantidade de dados envolvidos. Para bancos de dados
atualizados com frequência, despejos de log mais frequentes não apenas fornecerão maior proteção, mas também reduzirão o impacto dos
backups nos recursos e aplicativos do servidor.
Os arquivos de backup devem ser mantidos em um sistema de arquivos separado dos bancos de dados e devem ser copiados em algum
meio de armazenamento separado, conforme especificado no SLA. Armazene cópias dos backups diários em um local seguro fora do local.
A maioria dos DBMSs suporta hot backups do banco de dados – backups feitos enquanto os aplicativos estão em execução. Quando
algumas atualizações ocorrerem em trânsito, elas serão revertidas até a conclusão ou revertidas quando o backup for recarregado. A
alternativa é um backup a frio feito quando o banco de dados está off-line. No entanto, um backup a frio pode não ser uma opção viável se
os aplicativos precisarem estar continuamente disponíveis.
2.2.2.2 Recuperar Dados
A maioria dos softwares de backup inclui a opção de ler o backup no sistema. O DBA trabalha com a equipe de infraestrutura para remontar
a mídia que contém o backup e executar a restauração. Os utilitários específicos usados para executar a restauração dos dados dependem
do tipo de banco de dados.

Os dados nos bancos de dados do sistema de arquivos podem ser mais fáceis de restaurar do que os dos sistemas de gerenciamento de banco
de dados relacional, que podem ter informações de catálogo que precisam ser atualizadas durante a recuperação de dados, especialmente se
a recuperação for de logs em vez de um backup completo.
É fundamental testar periodicamente a recuperação de dados. Isso reduzirá as surpresas ruins durante um desastre ou emergência. As
execuções de prática podem ser executadas em cópias do sistema de não produção com infraestrutura e configuração idênticas ou, se o
sistema tiver um failover, no sistema secundário.
2.2.3 Desenvolver instâncias de banco de dados
Os DBAs são responsáveis pela criação de instâncias de banco de dados. As atividades relacionadas incluem:
• Instalando e atualizando o software DBMS: DBAs instalam novas versões do software DBMS e
aplicar patches de manutenção fornecidos pelo fornecedor do DBMS em todos os ambientes (desde o desenvolvimento até
produção) conforme indicado pelo fornecedor e examinado e priorizado por especialistas de DBA, segurança
especialistas e gestão. Esta é uma atividade crítica para garantir contra a vulnerabilidade a ataques, bem como
para garantir a integridade contínua dos dados em instalações centralizadas e descentralizadas.
• Manutenção de instalações de vários ambientes, incluindo diferentes versões de DBMS: DBAs podem
instalar e manter várias instâncias de software DBMS em sandbox, desenvolvimento, teste, usuário
teste de aceitação, teste de aceitação do sistema, garantia de qualidade, pré-produção, hot-fix, desastre
ambientes de recuperação e produção e gerenciar a migração das versões de software DBMS
por meio de ambientes relativos a versões e alterações de aplicativos e sistemas.
• Instalação e administração de tecnologia de dados relacionada: DBAs podem estar envolvidos na instalação de dados
software de integração e ferramentas de administração de dados de terceiros.
2.2.3.1 Gerenciar o Ambiente de Armazenamento Físico
O gerenciamento do ambiente de armazenamento precisa seguir o tradicional Software Configuration Management (SCM)
processos ou métodos da Information Technology Infrastructure Library (ITIL) para registrar modificações na configuração do banco de dados,
estruturas, restrições, permissões, limites, etc. Os DBAs precisam atualizar o modelo de dados físico para refletir as alterações nos objetos de
armazenamento como parte de uma configuração padrão processo de gestão.
Com desenvolvimento ágil e métodos de programação extremos, as atualizações do modelo de dados físico desempenham papéis importantes
na prevenção de erros de design ou desenvolvimento.
Os DBAs precisam aplicar o processo SCM para rastrear alterações e verificar se os bancos de dados nos ambientes de desenvolvimento,
teste e produção têm todos os aprimoramentos incluídos em cada versão – mesmo que as alterações sejam cosméticas ou apenas em uma
camada de dados virtualizada.
Os quatro procedimentos necessários para garantir um processo SCM sólido são identificação de configuração, controle de mudança de
configuração, contabilidade de status de configuração e auditorias de configuração.

200 • DMBOK2
• Durante o processo de identificação da configuração , os DBAs trabalharão com administradores de dados, arquitetos de dados e
modeladores de dados para identificar os atributos que definem cada aspecto de uma configuração para fins de usuário final. Esses
atributos são registrados na documentação de configuração e referenciados. Uma vez que um atributo é definido como linha de base,
é necessário um processo formal de controle de mudança de configuração para alterar o

atributo.
• O controle de mudança de configuração é um conjunto de processos e estágios de aprovação necessários para alterar um
atributos do item de configuração e para redefini-los.
• A contabilidade do status de configuração é a capacidade de registrar e relatar a linha de base da configuração
associado a cada item de configuração a qualquer momento.
• As auditorias de configuração ocorrem tanto na entrega quanto ao efetuar uma mudança. Existem dois tipos. Uma auditoria de
configuração física garante que um item de configuração seja instalado de acordo com os requisitos de sua documentação de
projeto detalhada, enquanto uma auditoria de configuração funcional garante que os atributos de desempenho de um item de
configuração sejam alcançados.
Para manter a integridade e a rastreabilidade dos dados durante todo o ciclo de vida dos dados, os DBAs comunicam as alterações nos atributos
físicos do banco de dados para modeladores, desenvolvedores e gerenciadores de metadados.
Os DBAs também devem manter métricas sobre volume de dados, projeções de capacidade e desempenho de consultas, bem como estatísticas
sobre objetos físicos, para identificar as necessidades de replicação de dados, volumes de migração de dados e pontos de verificação de recuperação
de dados. Bancos de dados maiores também terão particionamento de objetos, que deve ser monitorado e mantido ao longo do tempo para garantir
que o objeto mantenha a distribuição de dados desejada.
2.2.3.2 Gerenciar controles de acesso ao banco de dados
Os DBAs são responsáveis por gerenciar os controles que permitem o acesso aos dados. Os DBAs supervisionam as seguintes funções para
proteger os ativos de dados e a integridade dos dados:
• Ambiente controlado: DBAs trabalham com NSAs para gerenciar um ambiente controlado para ativos de dados;
isso inclui funções de rede e gerenciamento de permissões, monitoramento 24 horas por dia, 7 dias por semana e
monitoramento da integridade da rede, gerenciamento de firewall, gerenciamento de patches e integração do Microsoft Baseline
Security Analyzer (MBSA).
• Segurança física: A segurança física dos ativos de dados é gerenciada pelo monitoramento baseado no Simple Network Management
Protocol (SNMP), registro de auditoria de dados, gerenciamento de desastres e planejamento de backup de banco de dados. Os
DBAs configuram e monitoram esses protocolos. O monitoramento é especialmente importante para protocolos de segurança.
• Monitoramento: Os sistemas de banco de dados são disponibilizados pelo monitoramento contínuo de hardware e software de
servidores críticos.
• Controles: DBAs mantêm a segurança das informações por meio de controles de acesso, auditoria de banco de dados, intrusão
ferramentas de detecção e avaliação de vulnerabilidades.
Os conceitos e atividades envolvidos na configuração da segurança de dados são discutidos no Capítulo 7.
2.2.3.3 Criar contêineres de armazenamento
Todos os dados devem ser armazenados em uma unidade física e organizados para facilitar o carregamento, a pesquisa e a recuperação. Os próprios
contêineres de armazenamento podem conter objetos de armazenamento e cada nível deve ser mantido de acordo com o nível do objeto. Por exemplo,
bancos de dados relacionais têm esquemas que contêm tabelas e bancos de dados não relacionais têm sistemas de arquivos que contêm arquivos.
2.2.3.4 Implementar Modelos de Dados Físicos
Os DBAs são normalmente responsáveis por criar e gerenciar o ambiente físico completo de armazenamento de dados
com base no modelo de dados físico. O modelo de dados físico inclui objetos de armazenamento, objetos de indexação e quaisquer objetos de código
encapsulados necessários para impor regras de qualidade de dados, conectar objetos de banco de dados e obter desempenho de banco de dados.
Dependendo da organização, os modeladores de dados podem fornecer o modelo de dados e os DBAs implementam o layout físico do modelo de dados
no armazenamento. Em outras organizações, os DBAs podem pegar um esqueleto de um modelo físico e adicionar todos os detalhes de implementação
específicos do banco de dados, incluindo índices, restrições, partições ou clusters, estimativas de capacidade e detalhes de alocação de armazenamento.
Para estruturas de banco de dados de terceiros fornecidas como parte de um aplicativo, a maioria das ferramentas de modelagem de dados permite
engenharia reversa de bancos de dados do sistema Commercial Off the Shelf (COTS) ou Enterprise Resource Planning (ERP), desde que a ferramenta
de modelagem possa ler o catálogo de ferramentas de armazenamento . Estes podem ser usados para desenvolver um Modelo Físico.
DBAs ou modeladores de dados ainda precisarão revisar e potencialmente atualizar o modelo físico para restrições ou relacionamentos baseados em
aplicativos; nem todas as restrições e relacionamentos são instalados em catálogos de banco de dados, especialmente para aplicativos mais antigos em
que a abstração do banco de dados era desejada.
Modelos físicos bem mantidos são necessários quando os DBAs estão fornecendo dados como serviço.
2.2.3.5 Carregar Dados
Quando construídos pela primeira vez, os bancos de dados estão vazios. DBAs os preenchem. Se os dados a serem carregados foram exportados
usando um utilitário de banco de dados, pode não ser necessário usar uma ferramenta de integração de dados para carregá-los no novo banco de dados.
A maioria dos sistemas de banco de dados tem recursos de carregamento em massa, exigindo que os dados estejam em um formato que corresponda
ao objeto de banco de dados de destino ou tenham uma função de mapeamento simples para vincular dados na origem ao objeto de destino.
202 • DMBOK2
A maioria das organizações também obtém alguns dados de fontes externas de terceiros, como listas de clientes em potencial adquiridos de um
corretor de informações, informações postais e de endereço ou dados de produtos fornecidos por um fornecedor.
Os dados podem ser licenciados ou fornecidos como um serviço de dados abertos, gratuitamente; fornecido em vários formatos diferentes (CD,
DVD, EDI, XML, feeds RSS, arquivos de texto); ou fornecido mediante solicitação ou atualizado regularmente por meio de um serviço de assinatura.
Algumas aquisições exigem acordos legais. Os DBAs precisam estar cientes dessas restrições antes de carregar dados.
Os DBAs podem ser solicitados a lidar com esses tipos de cargas ou para criar o mapa de carga inicial. Limite a execução manual dessas cargas a
instalações ou outras situações pontuais, ou garanta que elas sejam automatizadas e programadas.
Uma abordagem gerenciada para aquisição de dados centraliza a responsabilidade pelos serviços de assinatura de dados com analistas de dados.
O analista de dados precisará documentar a fonte de dados externa no modelo de dados lógico e no dicionário de dados. Um desenvolvedor pode
projetar e criar scripts ou programas para ler os dados e carregá-los em um banco de dados.
O DBA será responsável por implementar os processos necessários para carregar os dados no banco de dados e/ou disponibilizá-los para a
aplicação.
2.2.3.6 Gerenciar Replicação de Dados
Os DBAs podem influenciar as decisões sobre o processo de replicação de dados aconselhando sobre:
• Replicação ativa ou passiva
• Controle de simultaneidade distribuído de sistemas de dados distribuídos
• Os métodos apropriados para identificar atualizações de dados por meio de carimbo de data/hora ou números de versão
no processo de controle de dados de alteração
Para pequenos sistemas ou objetos de dados, atualizações de dados completas podem satisfazer os requisitos de simultaneidade. Para objetos
maiores em que a maioria dos dados NÃO é alterada, mesclar as alterações no objeto de dados é mais eficiente do que copiar completamente
todos os dados para cada alteração. Para objetos grandes em que a maioria dos dados é alterada, ainda pode ser melhor fazer uma atualização do
que incorrer na sobrecarga de tantas atualizações.
2.2.4 Gerenciar o desempenho do banco de dados
O desempenho do Banco de Dados depende de duas facetas interdependentes: disponibilidade e velocidade. O desempenho inclui a garantia de
disponibilidade de espaço, otimização de consultas e outros fatores que permitem que um banco de dados retorne dados de maneira eficiente. O
desempenho não pode ser medido sem disponibilidade. Um banco de dados indisponível tem uma medida de desempenho zero. DBAs e NSAs
gerenciam o desempenho do banco de dados por:
• Configuração e ajuste dos parâmetros do sistema operacional e do aplicativo.
• Gerenciando a conectividade do banco de dados. NSAs e DBAs fornecem orientação técnica e suporte para TI e
usuários de negócios que exigem conectividade de banco de dados com base em políticas impostas por meio de padrões e
protocolos da organização.
• Trabalhar com programadores de sistema e administradores de rede para ajustar sistemas operacionais, redes,
e middleware de processamento de transações para trabalhar com o banco de dados.
• Dedicar armazenamento apropriado e permitir que o banco de dados funcione com dispositivos de armazenamento e armazenamento
softwares de gestão. O software de gerenciamento de armazenamento otimiza o uso de diferentes armazenamentos
tecnologias para armazenamento econômico de dados mais antigos e referenciados com menos frequência, migrando esses dados
para dispositivos de armazenamento mais baratos. Isso resulta em um tempo de recuperação mais rápido para os dados principais. DBAs funcionam
com administradores de armazenamento para configurar e monitorar procedimentos eficazes de gerenciamento de armazenamento.
• Fornecer estudos de crescimento volumétrico para dar suporte à aquisição de armazenamento e ao ciclo de vida geral de dados
atividades de gerenciamento de retenção, ajuste, arquivamento, backup, limpeza e recuperação de desastres.
• Trabalhar com administradores de sistema para fornecer cargas de trabalho operacionais e benchmarks de dados implantados
ativos que suportam gerenciamento de SLA, cálculos de cobrança retroativa, capacidade do servidor e rotação do ciclo de vida
dentro do horizonte de planejamento prescrito.
2.2.4.1 Definir níveis de serviço de desempenho do banco de dados
O desempenho do sistema, a disponibilidade de dados e as expectativas de recuperação e as expectativas para as equipes responderem a problemas geralmente
são governados por acordos de nível de serviço (SLAs) entre organizações de serviços de gerenciamento de dados de TI e proprietários de dados (Figura 61).
Nível de serviço Nível de serviço

Acordo Acordo
Performance do sistema Desempenho do banco de dados
Disponibilidade do sistema Disponibilidade do banco de dados
Recuperação do sistema
Proprietários de dados Dados de TI

DBA
Dados Gestão NSA
Comissários Serviços
Figura 61 SLAs para desempenho de sistema e banco de dados
Normalmente, um SLA identificará os prazos durante os quais se espera que o banco de dados esteja disponível para uso.
Muitas vezes, um SLA identificará um tempo de execução máximo permitido especificado para algumas transações de aplicativos (uma mistura de consultas e
atualizações complexas). Se o banco de dados não estiver disponível conforme acordado, ou se os tempos de execução do processo violarem o SLA, os proprietários
dos dados solicitarão ao DBA que identifique e corrija as causas do problema.

204 • DMBOK2
2.2.4.2 Gerenciar a disponibilidade do banco de dados
Disponibilidade é a porcentagem de tempo que um sistema ou banco de dados pode ser usado para trabalho produtivo. À medida que as
organizações aumentam o uso de dados, os requisitos de disponibilidade aumentam, assim como os riscos e os custos de dados
indisponíveis. Para atender a uma demanda maior, as janelas de manutenção estão diminuindo. Quatro fatores relacionados afetam a
disponibilidade:
• Gerenciabilidade: A capacidade de criar e manter um ambiente • Recuperabilidade:
A capacidade de restabelecer o serviço após a interrupção e corrigir erros causados por eventos imprevistos ou falhas de
componentes
• Confiabilidade: A capacidade de fornecer serviço em níveis especificados por um período determinado
• Facilidade de manutenção: A capacidade de identificar a existência de problemas, diagnosticar suas causas e reparar /
resolvê-los
Muitas coisas podem impedir que os bancos de dados estejam disponíveis, incluindo:
• Interrupções planejadas
o Para manutenção
o Para atualizações •
Interrupções não planejadas

o Perda do hardware do servidor
o Falha de hardware do disco
o Falha do sistema operacional

o Falha de software DBMS
o Perda do site do data center
o Falha de rede
• Problemas de aplicativo o
Problemas de segurança e autorização o
Problemas graves de desempenho o Falhas de
recuperação • Problemas de dados o Corrupção
de dados (devido a bugs, design ruim ou erro do usuário) o
Perda de objetos do banco de dados
o Perda de dados
o Falha na replicação de dados

• Erro humano
Os DBAs são responsáveis por fazer todo o possível para garantir que os bancos de dados permaneçam online e operacionais, incluindo:
• Executando utilitários de backup de banco de
dados • Executando utilitários de reorganização de
banco de dados • Executando utilitários de coleta de
estatísticas • Executando utilitários de verificação de
integridade • Automatizando a execução desses utilitários

• Explorando o clustering e o particionamento do tablespace
• Replicação de dados em bancos de dados espelhados para garantir alta disponibilidade
2.2.4.3 Gerenciar a execução do banco de dados
Os DBAs também estabelecem e monitoram a execução do banco de dados, o uso de logs de alteração de dados e a sincronização de ambientes
duplicados. Os tamanhos e locais de log exigem espaço e, em alguns casos, podem ser tratados como bancos de dados baseados em arquivo por
conta própria. Outros aplicativos que consomem logs também devem ser gerenciados para garantir o uso dos logs corretos no nível de log
necessário. Quanto mais detalhes são registrados, mais espaço e processamento são necessários, o que pode afetar negativamente o desempenho.
2.2.4.4 Manter os níveis de serviço de desempenho do banco de dados
Os DBAs otimizam o desempenho do banco de dados de forma proativa e reativa, monitorando o desempenho e respondendo a problemas com
rapidez e competência. A maioria dos SGBDs fornece a capacidade de monitoramento
desempenho, permitindo que os DBAs gerem relatórios de análise. A maioria dos sistemas operacionais de servidor tem recursos semelhantes de
monitoramento e relatório. Os DBAs devem executar relatórios de atividade e desempenho no DBMS e no servidor regularmente, inclusive durante
períodos de atividade intensa. Eles devem comparar esses relatórios com relatórios anteriores para identificar quaisquer tendências negativas e
salvá-los para ajudar a analisar os problemas ao longo do tempo.
2.2.4.4.1 Desempenho da Transação versus Desempenho do Lote
A movimentação de dados pode ocorrer em tempo real por meio de transações online. No entanto, muitas atividades de movimentação e
transformação de dados são realizadas por meio de programas em lote, que podem mover dados entre sistemas ou simplesmente realizar
operações em dados dentro de um sistema. Esses trabalhos em lote devem ser concluídos dentro das janelas especificadas na programação
operacional. DBAs e especialistas em integração de dados monitoram o desempenho de tarefas de dados em lote, observando tempos de
conclusão e erros excepcionais, determinando a causa raiz dos erros e resolvendo esses problemas.
2.2.4.4.2 Correção de Problemas
Quando ocorrerem problemas de desempenho, as equipes de DBA, NSA e Administração de Servidores devem usar as ferramentas de
monitoramento e administração do DBMS para ajudar a identificar a origem do problema. Os motivos comuns para o baixo desempenho do banco
de dados incluem:
• Alocação ou contenção de memória: um buffer ou cache para dados.
• Bloqueio e bloqueio: Em alguns casos, um processo em execução no banco de dados pode bloquear o banco de dados
recursos, como tabelas ou páginas de dados, e bloquear outro processo que precise deles. Se o problema
persistir, o DBA pode matar o processo de bloqueio. Em alguns casos, dois processos podem 'bloquear', com
206 • DMBOK2
cada processo bloqueando os recursos necessários pelo outro. A maioria dos DBMSs encerrará automaticamente um desses processos
após um intervalo de tempo. Esses tipos de problemas geralmente são resultado de uma codificação ruim, seja no banco de dados ou no
aplicativo.
• Estatísticas de banco de dados imprecisas: a maioria dos DBMSs relacionais possui um otimizador de consulta integrado, que se baseia em
estatísticas armazenadas sobre os dados e índices para tomar decisões sobre como executar uma determinada consulta com mais
eficiência. Essas estatísticas devem ser atualizadas com frequência, principalmente em bancos de dados ativos. Não fazer isso resultará
em consultas com desempenho insatisfatório.
• Codificação deficiente: Talvez a causa mais comum de desempenho insatisfatório do banco de dados seja SQL mal codificado.
Os codificadores de consulta precisam de um entendimento básico de como o otimizador de consulta SQL funciona. Eles devem codificar
SQL de uma maneira que tire o máximo proveito dos recursos do otimizador. Alguns sistemas permitem o encapsulamento de SQL
complexo em procedimentos armazenados, que podem ser pré-compilados e pré-otimizados, em vez de incorporados no código do
aplicativo ou em arquivos de script.
• Junções de tabelas complexas ineficientes: Use visualizações para pré-definir junções de tabelas complexas. Além disso, evite usar SQL
complexo (por exemplo, junções de tabela) em funções de banco de dados; ao contrário dos procedimentos armazenados, eles são opacos
para o otimizador de consulta.
• Indexação insuficiente: Codifique consultas complexas e consultas envolvendo tabelas grandes para usar índices construídos nas tabelas. Crie
os índices necessários para dar suporte a essas consultas. Tenha cuidado ao criar muitos índices em tabelas muito atualizadas, pois isso
retardará o processamento da atualização.
• Atividade do aplicativo: Idealmente, os aplicativos devem ser executados em um servidor separado do DBMS, de modo
que eles não estão competindo por recursos. Configure e ajuste os servidores de banco de dados para obter o máximo
desempenho. Além disso, os novos SGBDs permitem que objetos de aplicação, como classes Java e .NET, sejam encapsulados em objetos
de banco de dados e executados no SGBD. Tenha cuidado ao fazer uso desse recurso. Pode ser muito útil em certos casos, mas a execução
do código do aplicativo no servidor de banco de dados pode afetar a interoperabilidade, a arquitetura do aplicativo e o desempenho dos
processos do banco de dados.
• Servidores sobrecarregados: Para DBMSs que suportam vários bancos de dados e aplicativos, pode haver um ponto de ruptura em que
a adição de mais bancos de dados tenha um efeito adverso no desempenho dos bancos de dados existentes. Nesse caso, crie um
novo servidor de banco de dados. Além disso, realoque os bancos de dados que cresceram muito, ou que estão sendo usados com mais
intensidade do que antes, para um servidor diferente. Em alguns casos, resolva problemas com bancos de dados grandes arquivando
dados menos usados em outro local ou excluindo dados expirados ou obsoletos.
• Volatilidade do banco de dados: Em alguns casos, um grande número de inserções e exclusões de tabelas em um curto período pode
criar estatísticas de distribuição de banco de dados imprecisas. Nesses casos, desative a atualização das estatísticas do banco de dados
para essas tabelas, pois as estatísticas incorretas afetarão negativamente o otimizador de consulta.
• Consultas descontroladas: os usuários podem enviar involuntariamente consultas que usam a maioria dos recursos compartilhados
do sistema. Use classificações ou reguladores de consulta para eliminar ou pausar essas consultas até que possam ser avaliadas e
aprimoradas.
Depois que a causa do problema for identificada, o DBA tomará qualquer ação necessária para resolver o problema, incluindo trabalhar
com desenvolvedores de aplicativos para melhorar e otimizar o código do banco de dados e arquivar ou excluir dados que não são mais
ativamente necessários para os processos do aplicativo. Em casos excepcionais para bancos de dados do tipo OLTP, o DBA pode
considerar trabalhar com o modelador de dados para reestruturar a parte afetada do banco de dados. Faça isso somente depois que
outras medidas (por exemplo, a criação de exibições e índices e a reescrita do código SQL) tiverem sido tentadas, e somente após uma
consideração cuidadosa das possíveis consequências, como perda de integridade dos dados ou aumento da complexidade das consultas
SQL contra tabelas desnormalizadas.
Para relatórios somente leitura e bancos de dados analíticos, a desnormalização para desempenho e facilidade de acesso é a regra e
não a exceção e não representa ameaça ou risco.
2.2.4.5 Manter Ambientes Alternativos
Os bancos de dados não aparecem uma vez e permanecem inalterados. As regras de negócios mudam, os processos de negócios
mudam e a tecnologia muda. Os ambientes de desenvolvimento e teste permitem que as alterações sejam testadas antes de serem
trazidas para um ambiente de produção. Os DBAs podem fazer cópias inteiras ou de subconjuntos de estruturas e dados de banco de
dados em outros ambientes para permitir o desenvolvimento e teste de alterações do sistema. Existem vários tipos de alternativas
ambientes.
• Ambientes de desenvolvimento são usados para criar e testar mudanças que serão implementadas em
Produção. O desenvolvimento deve ser mantido para se assemelhar ao ambiente de produção, embora
com recursos reduzidos.
• Os ambientes de teste atendem a vários propósitos: controle de qualidade, teste de integração, UAT e teste de desempenho.
O ambiente de teste idealmente também tem o mesmo software e hardware da produção. Em particular,
ambientes usados para teste de desempenho não devem ser reduzidos em recursos.
• Sandboxes ou ambientes experimentais são usados para testar hipóteses e desenvolver novos usos de dados.
Os DBAs geralmente configuram, concedem acesso e monitoram o uso desses ambientes. Eles deviam
também garantir que os sandboxes sejam isolados e não afetem adversamente as operações de produção.
• Ambientes de produção alternativos são necessários para oferecer suporte a backups offline, failover e resiliência
sistemas de apoio. Esses sistemas devem ser idênticos aos sistemas de produção, embora o backup
(e recuperação) pode ser reduzido em capacidade de computação, pois é principalmente dedicado a E/S
Atividades.
2.2.5 Gerenciar conjuntos de dados de teste
O teste de software é trabalhoso e representa quase metade do custo do desenvolvimento do sistema. Testes eficientes requerem dados
de teste de alta qualidade, e esses dados devem ser gerenciados. A geração de dados de teste é uma etapa crítica no teste de software.
208 • DMBOK2
Dados de teste são dados que foram especificamente identificados para testar um sistema. O teste pode incluir a verificação de que um determinado conjunto de
entrada produz a saída esperada ou desafiar a capacidade de programação para responder a entradas incomuns, extremas, excepcionais ou inesperadas. Os dados
de teste podem ser completamente fabricados ou gerados usando valores sem sentido ou podem ser dados de amostra. Os dados de amostra podem ser um
subconjunto de dados de produção reais (por conteúdo ou estrutura) ou gerados a partir de dados de produção. Os dados de produção podem ser filtrados ou agregados
para criar vários conjuntos de dados de amostra, dependendo da necessidade. Nos casos em que os dados de produção contêm dados protegidos ou restritos, os
dados de amostra
deve ser mascarado.
Os dados de teste podem ser produzidos de forma focada ou sistemática (como normalmente é o caso em testes de funcionalidade) usando estatísticas ou filtros, ou
usando outras abordagens menos focadas (como normalmente é o caso em testes automatizados aleatórios de alto volume). Os dados de teste podem ser produzidos
pelo testador, por um programa ou função que auxilia o testador ou por uma cópia dos dados de produção que foram selecionados e selecionados para essa finalidade.
Os dados de teste podem ser registrados para reutilização de curto prazo, criados e gerenciados para dar suporte a testes de regressão ou usados uma vez e depois
removidos – embora na maioria das organizações, a limpeza após os projetos não inclua essa etapa. DBAs devem monitorar o projeto
dados de teste e certifique-se de que os dados de teste obsoletos sejam limpos regularmente para preservar a capacidade.
Nem sempre é possível produzir dados suficientes para alguns testes, principalmente testes de desempenho. A quantidade de dados de teste a serem gerados é
determinada ou limitada por considerações como tempo, custo e qualidade. Ele também é afetado pela regulamentação que limita o uso de dados de produção em um
ambiente de teste. (Consulte o Capítulo 7.)
2.2.6 Gerenciar a migração de dados
A migração de dados é o processo de transferência de dados entre tipos de armazenamento, formatos ou sistemas de computador, com o mínimo de alteração possível.
A alteração de dados durante a migração é discutida no Capítulo 8.
A migração de dados é uma consideração importante para qualquer implementação, atualização ou consolidação do sistema. Geralmente é realizado de forma
programática, sendo automatizado com base em regras. No entanto, as pessoas precisam garantir que as regras e os programas sejam executados corretamente. A
migração de dados ocorre por vários motivos, incluindo substituições ou atualizações de servidores ou equipamentos de armazenamento, consolidação de sites,
manutenção de servidores ou realocação de data centers. A maioria das implementações permite que isso seja feito de maneira não disruptiva, como simultaneamente
enquanto o host continua a executar E/S no disco lógico (ou LUN).
A granularidade do mapeamento determina a rapidez com que os metadados podem ser atualizados, quanta capacidade extra é necessária durante a migração e a
rapidez com que o local anterior é marcado como livre. A granularidade menor significa atualização mais rápida, menos espaço necessário e liberação mais rápida do
armazenamento antigo.
Muitas tarefas do dia a dia que um administrador de armazenamento precisa executar podem ser concluídas de forma simples e simultânea usando técnicas de
migração de dados:
• Mover dados de um dispositivo de armazenamento muito usado para um ambiente separado
• Mover dados para um dispositivo de armazenamento mais rápido conforme as necessidades exigem
• Implementação de uma política de Gerenciamento do Ciclo de Vida da Informação
• Migração de dados de dispositivos de armazenamento mais antigos (seja sucateado ou off-lease) para armazenamento offline ou em nuvem
A correção automática e manual de dados geralmente é realizada na migração para melhorar a qualidade dos dados, eliminar informações
redundantes ou obsoletas e atender aos requisitos do novo sistema. As fases de migração de dados (projeto, extração, correção, carregamento,
verificação) para aplicativos de complexidade moderada a alta geralmente são repetidas várias vezes antes que o novo sistema seja implantado.
3. Ferramentas
Além dos próprios sistemas de gerenciamento de banco de dados, os DBAs usam várias outras ferramentas para gerenciar bancos de dados. Por
exemplo, modelagem e outras ferramentas de desenvolvimento de aplicativos, interfaces que permitem aos usuários escrever e executar consultas,
avaliação de dados e ferramentas de modificação para melhoria da qualidade de dados e ferramentas de monitoramento de carga de desempenho.
As ferramentas de modelagem de dados automatizam muitas das tarefas que o modelador de dados executa. Algumas ferramentas de modelagem
de dados permitem a geração de linguagem de definição de dados de banco de dados (DDL). A maioria suporta engenharia reversa do banco de
dados em um modelo de dados. Ferramentas mais sofisticadas validam padrões de nomenclatura, verificam a ortografia, armazenam Metadados
como definições e linhagem e até permitem a publicação na web. (Consulte o Capítulo 5.)
3.2 Ferramentas de monitoramento de banco de dados
As ferramentas de monitoramento do banco de dados automatizam o monitoramento das principais métricas, como capacidade, disponibilidade,
desempenho do cache, estatísticas do usuário, etc., e alertam DBAs e NSAs sobre problemas no banco de dados. A maioria dessas ferramentas
pode monitorar simultaneamente vários tipos de banco de dados.
3.3 Ferramentas de gerenciamento de banco de dados
Os sistemas de banco de dados geralmente incluem ferramentas de gerenciamento. Além disso, vários pacotes de software de terceiros permitem
que os DBAs gerenciem vários bancos de dados. Esses aplicativos incluem funções para configuração, instalação de patches e atualizações,
backup e restauração, clonagem de banco de dados, gerenciamento de testes e rotinas de limpeza de dados.
3.4 Ferramentas de Suporte ao Desenvolvedor
As ferramentas de suporte ao desenvolvedor contêm uma interface visual para conectar e executar comandos em um banco de dados.
Alguns estão incluídos no software de gerenciamento de banco de dados. Outros incluem aplicativos de terceiros.
210 • DMBOK2
4. Técnicas
4.1 Teste em Ambientes Inferiores
Para atualizações e patches para sistemas operacionais, software de banco de dados, alterações de banco de dados e alterações de
código, instale e teste primeiro no ambiente de nível mais baixo – geralmente desenvolvimento. Uma vez testado no nível mais baixo,
instale nos próximos níveis mais altos e instale no ambiente de produção por último. Isso garante que os instaladores tenham experiência
com o upgrade ou patch e possam minimizar a interrupção nos ambientes de produção.
4.2 Padrões de Nomenclatura Física
A consistência na nomeação acelera a compreensão. Arquitetos de dados, desenvolvedores de banco de dados e DBAs podem usar
padrões de nomenclatura para definir Metadados ou criar regras para troca de documentos entre organizações.
A ISO/IEC 11179 – Registros de Metadados (MDR), aborda a semântica dos dados, a representação dos dados e o registro das
descrições desses dados. É através dessas descrições que uma compreensão precisa da semântica e uma descrição útil dos dados são
encontradas.
A seção significativa para bancos de dados físicos dentro desses padrões é a Parte 5 – Princípios de Nomenclatura e Identificação, que
descreve como formar convenções para nomenclatura de elementos de dados e seus componentes.
4.3 Uso de script para todas as alterações
É extremamente arriscado alterar dados diretamente em um banco de dados. No entanto, pode haver necessidade, como mudança
anual na estrutura do plano de contas, ou em fusões e aquisições, ou emergências, quando indicadas pela natureza 'one-off' do pedido
e/ou pela falta de de ferramentas apropriadas para essas circunstâncias.
É útil colocar as alterações a serem feitas nos arquivos de script de atualização e testá-los completamente em ambientes de não
produção antes de aplicar à produção.
Uma avaliação de risco e prontidão gira em torno de duas ideias centrais: risco de perda de dados e riscos relacionados a
prontidão tecnológica.
• Perda de dados: Os dados podem ser perdidos por meio de erros técnicos ou de procedimento, ou por intenção maliciosa.
As organizações precisam implementar estratégias para mitigar esses riscos. Os acordos de nível de serviço geralmente
especificar os requisitos gerais de proteção. Os SLAs precisam ser suportados por
procedimentos. A avaliação contínua é necessária para garantir que respostas técnicas robustas estejam em vigor para evitar
perda de dados por intenção maliciosa, pois as ameaças cibernéticas estão sempre evoluindo. A auditoria de SLA e as auditorias de dados são
recomendado para avaliar e planejar mitigações de risco.
• Prontidão tecnológica: tecnologias mais recentes, como NoSQL, Big Data, armazenamento triplo e FDMS
exigem habilidades e prontidão experiência em TI. Muitas organizações não possuem as habilidades necessárias para
aproveitar essas novas tecnologias. DBAs, engenheiros de sistemas e desenvolvedores de aplicativos, e
os usuários de negócios devem estar prontos para usar os benefícios deles no BI e em outros aplicativos.
DBAs muitas vezes não promovem efetivamente o valor de seu trabalho para a organização. Eles precisam reconhecer as preocupações
legítimas dos proprietários de dados e consumidores de dados, equilibrar as necessidades de dados de curto e longo prazo, educar outras
pessoas na organização sobre a importância das boas práticas de gerenciamento de dados e otimizar as práticas de desenvolvimento de
dados para garantir o máximo benefício ao organização e impacto mínimo nos consumidores de dados.
Ao considerar o trabalho de dados como um conjunto abstrato de princípios e práticas, e desconsiderar os elementos humanos envolvidos,
os DBAs correm o risco de propagar uma mentalidade de 'nós contra eles' e serem vistos como dogmáticos, impraticáveis, inúteis e
obstrucionistas.
Muitas desconexões – principalmente confrontos em quadros de referência – contribuem para esse problema. As organizações geralmente
consideram a tecnologia da informação em termos de aplicativos específicos, não de dados, e geralmente veem os dados de um ponto de
vista centrado em aplicativos. O valor de longo prazo para as organizações de dados seguros, reutilizáveis e de alta qualidade, como dados
como um recurso corporativo, não é tão facilmente reconhecido ou apreciado.
O desenvolvimento de aplicativos geralmente vê o gerenciamento de dados como um impedimento ao desenvolvimento de aplicativos, como
algo que faz com que os projetos de desenvolvimento demorem mais e custem mais sem fornecer benefícios adicionais.
Os DBAs demoraram a se adaptar às mudanças na tecnologia (por exemplo, XML, objetos e arquiteturas orientadas a serviços) e novos
métodos de desenvolvimento de aplicativos (por exemplo, Desenvolvimento Ágil, XP e Scrum). Os desenvolvedores, por outro lado, muitas
vezes não reconhecem como as boas práticas de gerenciamento de dados podem ajudá-los a atingir seus objetivos de longo prazo de
reutilização de objetos e aplicativos e uma verdadeira arquitetura de aplicativos orientada a serviços.
DBAs e outros profissionais de gerenciamento de dados podem ajudar a superar esses obstáculos organizacionais e culturais.
Eles podem promover uma abordagem mais útil e colaborativa para atender às necessidades de dados e informações da organização,
seguindo os princípios orientadores para identificar e agir em oportunidades de automação, construindo com a reutilização em mente,
aplicando as melhores práticas, conectando padrões de banco de dados para atender aos requisitos e definindo expectativas para DBAs no
trabalho do projeto. Além disso, devem:
• Comunique-se proativamente: os DBAs devem estar em estreita comunicação com as equipes de projeto, tanto durante
desenvolvimento e após a implementação, para detectar e resolver quaisquer problemas o mais cedo possível. Elas
212 • DMBOK2
deve revisar o código de acesso a dados, procedimentos armazenados, exibições e funções de banco de dados escritas por
equipes de desenvolvimento e ajudar a detectar quaisquer problemas com o design do banco de dados.
• Comunique-se com as pessoas em seu nível e em seus termos: É melhor conversar com pessoas de negócios em termos de necessidades
de negócios e ROI, e com desenvolvedores em termos de orientação a objetos, baixo acoplamento e facilidade de desenvolvimento.
• Mantenha o foco nos negócios: O objetivo do desenvolvimento de aplicativos é atender aos requisitos de negócios e
obter o valor máximo do projeto.
• Seja útil: Sempre dizer 'não' às pessoas as encoraja a ignorar os padrões e encontrar outro caminho.
Reconhecer que as pessoas precisam fazer o que precisam fazer e não ajudá-las a ter sucesso se torna mutuamente prejudicial.
• Aprenda continuamente: Avalie os contratempos encontrados durante um projeto para obter as lições aprendidas e aplique-as em projetos
futuros. Se surgirem problemas por ter feito coisas erradas, aponte-os mais tarde como razões para fazer as coisas certas.
Para resumir, entenda as partes interessadas e suas necessidades. Desenvolva padrões claros, concisos, práticos e focados nos negócios para fazer o
melhor trabalho possível da melhor maneira possível. Além disso, ensine e implemente esses padrões de uma maneira que forneça o máximo valor às
partes interessadas e ganhe seu respeito.
6. Armazenamento de Dados e Governança de Operações
6.1 Métricas
As métricas de armazenamento de dados podem incluir:
• Contagem de bancos de dados por tipo •
Estatísticas de transações agregadas • Métricas de
capacidade, como o Quantidade de armazenamento
usado o Número de contêineres de
armazenamento o Número de objetos de dados
em termos de bloco ou páginas confirmadas e não confirmadas o Dados em fila • Uso do serviço de armazenamento
• Solicitações feito em relação aos serviços de armazenamento • Melhorias no desempenho dos aplicativos que
usam um serviço
As métricas de desempenho podem ser usadas para medir:

• Frequência e quantidade de transações
• Desempenho da consulta
• Desempenho do serviço API (interface de programação de aplicativos)
As métricas operacionais podem consistir em:
• Estatísticas agregadas sobre o tempo de recuperação de dados
• Tamanho do backup
• Medição de qualidade de dados
• Disponibilidade
As métricas de serviço podem incluir
• Envio de problemas, resolução e contagem de escalonamento por tipo

• Tempo de resolução do problema
Os DBAs precisam discutir a necessidade de métricas com arquitetos de dados e equipes de qualidade de dados.
6.2 Rastreamento de Ativos de Informação
Parte da governança de armazenamento de dados inclui garantir que uma organização cumpra todos os contratos de licenciamento e requisitos
regulatórios. Acompanhe cuidadosamente e realize auditorias anuais de licença de software e custos anuais de suporte, bem como contratos de locação
de servidor e outros custos fixos. Estar fora de conformidade com os acordos de licenciamento representa sérios riscos financeiros e legais para uma
organização.
Os dados de auditoria podem ajudar a determinar o custo total de propriedade (TCO) para cada tipo de tecnologia e produto de tecnologia. Avalie
regularmente tecnologias e produtos que estão se tornando obsoletos, sem suporte, menos úteis ou muito caros.
6.3 Auditorias de Dados e Validação de Dados
Uma auditoria de dados é a avaliação de um conjunto de dados com base em critérios definidos. Normalmente, uma auditoria é realizada para investigar
preocupações específicas sobre um conjunto de dados e é projetada para determinar se os dados foram armazenados em conformidade com os
requisitos contratuais e metodológicos. A abordagem de auditoria de dados pode incluir uma lista de verificação abrangente e específica do projeto,
entregas necessárias e critérios de controle de qualidade.
A validação de dados é o processo de avaliação de dados armazenados em relação aos critérios de aceitação estabelecidos para determinar sua
qualidade e usabilidade. Os procedimentos de validação de dados dependem dos critérios estabelecidos pela equipe de qualidade de dados (se houver)
ou outros requisitos do consumidor de dados. DBAs suportam parte das auditorias e validação de dados por:
• Ajudar a desenvolver e revisar a abordagem
• Realização de triagem e revisão de dados preliminares

214 • DMBOK2
• Desenvolvimento de métodos de monitoramento de dados
• Aplicação de técnicas estatísticas, geoestatísticas e bioestatísticas para otimizar a análise de dados
• Apoiar a amostragem e análise
• Revisão de dados
• Fornecendo suporte para descoberta de dados
• Atuando como PMEs para questões relacionadas à administração de banco de dados

Amir, Obaid. Guia de migração de dados de armazenamento. 2012. Kindle.
Armistead, Leigh. Questões de Operações de Informação: Melhores Práticas. Potomac Books Inc., 2010. Impresso.
Axelos Global Best Practice (site da ITIL). http://bit.ly/1H6SwxC.
Bitman, Tom. “Virtualização com VMWare ou HyperV: o que você precisa saber.” Webinar do Gartner, 25 de novembro de 2009. http://gtnr.it/2rRl2aP, Web.
Cervejeiro, Eric. “Rumo a Sistemas Distribuídos Robustos”. PODC Keynote 2000. http://bit.ly/2sVsYYv Web.
Dunham, Jeff. Manual de ajuste de desempenho de banco de dados. McGraw-Hill, 1998. Print.
Dwivedi, Himanshu. Protegendo o armazenamento: um guia prático para segurança de SAN e NAS. Addison-Wesley Professional, 2005.
Imprimir.
EMC Education Services, ed. Armazenamento e gerenciamento de informações: armazenamento, gerenciamento e proteção de informações
digitais em ambientes clássicos, virtualizados e em nuvem. 2ª edição. Wiley, 2012. Impresso.
Finn, Aidan, et ai. Computação em Nuvem Privada da Microsoft. Sybex, 2013. Imprimir.
Finn, Aidan. Dominando a implantação do Hyper-V. Sybex. 2010. Imprimir.
Fitzsimmons, James A. e Mona J. Fitzsimmons. Gestão de Serviços: Operações, Estratégia, Tecnologia da Informação. 6ª edição. Irwin/McGraw-Hill, 2007.
Imprima com CDROM.
Gallagher, Simon, et ai. VMware Private Cloud Computing com vCloud Director. Sybex. 2013. Imprimir.
Haerder, T. e A Reuter. “Princípios de recuperação de banco de dados orientada a transações”. ACM Computing Surveys 15 (4) (1983). https://
web.stanford.edu/class/cs340v/papers/recovery.pdf Web.
Hitachi Data Systems Academy, Conceitos de armazenamento: armazenamento e gerenciamento de dados digitais. Volume 1. Academia HDS, Hitachi Data
Systems, 2012. Imprimir.
Hoffer, Jeffrey, Mary Prescott e Fred McFadden. Gerenciamento de banco de dados moderno. 7ª Edição. Prentice Hall, 2004. Impresso.
Khalil, Mostafá. Implementação de armazenamento no vSphere 5.0. VMware Press, 2012. Imprimir.
Kotwal, Nitin. Backup e replicação de armazenamento de dados: gerenciamento de dados eficaz para garantir desempenho ideal e continuidade de
negócios. Nitin Kotwal, 2015. Amazon Digital Services LLC.
Kroenke, DM Processamento de Banco de Dados: Fundamentos, Projeto e Implementação. 10ª Edição. Pearson Prentice Hall, 2005. Print.
Liebowitz, Matt et ai. Desempenho do VMware vSphere: projetando CPU, memória, armazenamento e rede para cargas de trabalho de alto desempenho. Sybex,
2014. Imprimir.
Matthews, Jeanna N. et ai. Executando o Xen: um guia prático para a arte da virtualização. Prentice Hall, 2008. Print.
Mattison, Rob. Noções básicas sobre sistemas de gerenciamento de banco de dados. 2ª Edição. McGraw-Hill, 1998. Print.
McNamara, Michael J. Armazenamento escalável: a próxima fronteira no gerenciamento de dados corporativos. Friesen Press, 2014. Kindle.
Mullins, Craig S. Administração de Banco de Dados: O Guia Completo de Práticas e Procedimentos. Addison-Wesley, 2002.
Imprimir.
Parsaye, Kamran e Mark Chignell. Ferramentas e Aplicativos Inteligentes de Banco de Dados: Acesso a Hiperinformação, Qualidade de Dados, Visualização,
Descoberta Automática. John Wiley and Sons, 1993. Impresso.
Pascal, Fabiano. Questões práticas em gerenciamento de banco de dados: uma referência para o praticante de pensamento. Addison-Wesley, 2000.
Imprimir.
PAULSEN, Karl. Tecnologias de armazenamento de mídia em movimento: aplicativos e fluxos de trabalho para plataformas de servidor de vídeo e mídia.
Imprensa Focal, 2011. Imprimir.
Piedad, Floyd e Michael Hawkins. Alta Disponibilidade: Design, Técnicas e Processos. Prentice Hall, 2001. Impresso.
Rob, Peter e Carlos Coronel. Sistemas de Banco de Dados: Projeto, Implementação e Gerenciamento. 7ª Edição. Curso de Tecnologia, 2006. Imprimir.
Sadalage, Pramod J., e Martin Fowler. NoSQL Distilled: Um breve guia para o mundo emergente da persistência poliglota.
Addison-Wesley, 2012. Imprimir. Profissional Addison-Wesley.
Santana, Gustavo A. Fundamentos de virtualização de data center: Noções básicas sobre técnicas e projetos para data centers altamente eficientes com Cisco
Nexus, UCS, MDS e muito mais. Cisco Press, 2013. Imprimir. Fundamentos.
Schulz, Greg. Redes de armazenamento de dados virtuais e em nuvem. Publicações Auerbach, 2011. Impresso.
Simitci, Huseyin. Análise de desempenho da rede de armazenamento. Wiley, 2003. Impresso.
Tran, Duc A. Armazenamento de dados para redes sociais: uma abordagem socialmente consciente. edição de 2013. Springer, 2012. Impresso. Springer
Briefs em Otimização.
Troppens, Ulf, et ai. Redes de armazenamento explicadas: Noções básicas e aplicação de Fibre Channel SAN, NAS, iSCSI, InfiniBand e FCoE. Wiley, 2009.
Impresso.
Departamento de Defesa dos EUA. Operações de Informação: Doutrina, Táticas, Técnicas e Procedimentos. 2011. Kindle.
VMware. VMware vCloud Architecture Toolkit (vCAT): orientação técnica e operacional para o sucesso da nuvem. VMware Press, 2013. Imprimir.
Wicker, Stephen B. Sistemas de Controle de Erros para Comunicação e Armazenamento Digital. Usado. Prentice-Hall, 1994. Print.
Zarra, Marcus S. Core Data: Data Storage and Management para iOS, OS X e iCloud. 2ª edição. Pragmatic Bookshelf, 2013.
Imprimir. Programadores Pragmáticos.
CAPÍTULO 7
Segurança de dados
Dados
Modelagem de dados
Qualidade dos dados
& Operações
Dados Dados
Metadados

& O negócio
Interoperabilidade
Inteligência
& Mestre & Contente
Dados Gestão
1. Introdução
D
ata Security inclui o planejamento, desenvolvimento e execução de políticas e procedimentos de segurança para
fornecer autenticação, autorização, acesso e auditoria adequados de ativos de dados e informações. o
as especificidades da segurança de dados (que dados precisam ser protegidos, por exemplo) diferem entre
indústrias e países. No entanto, o objetivo das práticas de segurança de dados é o mesmo: proteger os ativos de informações
em alinhamento com os regulamentos de privacidade e confidencialidade, acordos contratuais e requisitos de negócios.
Esses requisitos vêm de:
217
218 • DMBOK2
• Partes interessadas: As organizações devem reconhecer as necessidades de privacidade e confidencialidade de seus
partes interessadas, incluindo clientes, pacientes, estudantes, cidadãos, fornecedores ou parceiros de negócios. Todos em
uma organização deve ser um administrador responsável de dados sobre as partes interessadas.
• Regulamentos governamentais : regulamentos governamentais estão em vigor para proteger os interesses de alguns
partes interessadas. Os regulamentos têm objetivos diferentes. Alguns restringem o acesso à informação, enquanto outros garantem
abertura, transparência e responsabilidade.
• Preocupações comerciais proprietárias: Cada organização tem dados proprietários para proteger. O de uma organização
dados fornecem insights sobre seus clientes e, quando aproveitados de forma eficaz, podem fornecer uma vantagem competitiva
vantagem. Se dados confidenciais forem roubados ou violados, uma organização pode perder vantagem competitiva.
• Necessidades de acesso legítimo: Ao proteger os dados, as organizações também devem permitir o acesso legítimo.
Os processos de negócios exigem que indivíduos em determinadas funções possam acessar, usar e manter dados.
• Obrigações contratuais: acordos contratuais e de não divulgação também influenciam a segurança de dados
requisitos. Por exemplo, o PCI Standard, um acordo entre empresas de cartão de crédito e
empresas individuais, exige que certos tipos de dados sejam protegidos de maneiras definidas (por exemplo,
criptografia obrigatória para senhas de clientes).
Políticas e procedimentos de segurança de dados eficazes garantem que as pessoas certas possam usar e atualizar os dados da maneira correta e que
todo acesso e atualização inadequados sejam restritos (Ray, 2012) (consulte a Figura 62). Compreender e cumprir os interesses e necessidades de
privacidade e confidencialidade de todas as partes interessadas é o melhor interesse de todas as organizações. Todos os relacionamentos com clientes,
fornecedores e constituintes confiam e dependem do uso responsável

De dados.
• Privacidade e confidencialidade • Os regulamentos podem restringir

de informações de clientes acesso a informação
• Segredos comerciais • Ações para garantir a abertura
• Atividade do parceiro de negócios e responsabilidade
• Fusões e aquisições • Fornecimento de assunto
direitos de acesso
• E mais ,,,
PARTE INTERESSADA GOVERNO

PREOCUPAÇÕES REGULAMENTO
NECESSÁRIO LEGÍTIMO
O NEGÓCIO O NEGÓCIO
NECESSIDADES DE ACESSO PREOCUPAÇÕES
• A segurança dos dados deve ser • Segredos comerciais
apropriado • Pesquisa e outros IP
• A segurança dos dados não deve ser • Conhecimento do cliente

muito oneroso para impedir precisa
usuários de fazer seus • Parceiro de negócios

empregos relacionamentos e
• Princípio Cachinhos Dourados negócios iminentes
Figura 62 Fontes de Requisitos de Segurança de Dados

SEGURANÇA DE DADOS • 219
Segurança de dados
Definição: Definição, planejamento, desenvolvimento e execução de políticas e procedimentos de

segurança para fornecer autenticação, autorização, acesso e auditoria adequados de ativos de dados e informações.
Objetivos:
1. Permitir o acesso apropriado e impedir o acesso inadequado aos ativos de dados corporativos.
2. Compreender e cumprir todos os regulamentos e políticas relevantes para privacidade, proteção e
confidencialidade.
3. Garantir que as necessidades de privacidade e confidencialidade de todas as partes interessadas sejam cumpridas e auditadas.
O negócio
Motoristas

•
• Objetivos de negócios e 1. Identifique a segurança de dados relevantes Segurança de dados
arquitetura
estratégia Requisitos (P) •
• Regras de negócios e Políticas de segurança de dados
2. Definir a Política de Segurança de Dados (C) •
Privacidade de dados e
processos 3. Definir padrões de segurança de dados
padrões de confidencialidade
• Regulatório (D) •
Acesso de segurança de dados
requisitos • 4. Avalie os riscos de segurança atuais (P) controles
•
Empresa 5. Implementar Controles e Em conformidade com a regulamentação
visualizações de acesso a dados

Padrões de Procedimentos (O)
arquitetura • Segurança documentada
classificações
• Dados Corporativos • Autenticação e usuário
Modelo
histórico de acesso
•
Auditoria de segurança de dados
relatórios

• • Administradores de dados • Usuários empresariais
Comitê de Direção de TI
• • •
Arquitetos Corporativos Equipe de Segurança da Informação Auditores Regulatórios
• Governo • Auditores internos
• •
Órgãos Reguladores Analistas de Processos
Técnico
Motoristas

• •
• Uso de Matriz BRUTO Sistemas de controle de acesso Implementação de segurança
• • Software de proteção Métricas
Patch de segurança imediato
• •
Implantação Tecnologia de gerenciamento de identidade Métricas de conscientização de segurança
• • Detecção/Prevenção de Intrusão • Métricas de proteção de dados
Atributos de segurança de dados em
Metadados Programas •
Métricas de incidentes de segurança
• • • Dados confidenciais
Necessidades de segurança no projeto Acompanhamento de metadados
• Taxa de proliferação
Requisitos Mascaramento / Criptografia de Dados
• Higienização de Documentos
Figura 63 Diagrama de contexto: segurança de dados

220 • DMBOK2
A redução de riscos e o crescimento dos negócios são os principais impulsionadores das atividades de segurança de dados. Garantir que
os dados de uma organização estejam seguros reduz o risco e adiciona vantagem competitiva. A segurança em si é um ativo valioso.
Os riscos de segurança de dados estão associados à conformidade regulatória, responsabilidade fiduciária pela empresa e acionistas,
reputação e responsabilidade legal e moral de proteger as informações privadas e confidenciais de funcionários, parceiros de negócios e
clientes. As organizações podem ser multadas por descumprimento de regulamentos e obrigações contratuais. As violações de dados
podem causar perda de reputação e confiança do cliente. (Consulte o Capítulo
2.)
O crescimento dos negócios inclui atingir e sustentar as metas operacionais de negócios. Problemas de segurança de dados, violações e
restrições injustificadas no acesso dos funcionários aos dados podem afetar diretamente o sucesso operacional.
Os objetivos de mitigação de riscos e crescimento do negócio podem ser complementares e de apoio mútuo se forem integrados a uma
estratégia coerente de gerenciamento e proteção da informação.
1.1.1 Redução de Risco
À medida que as regulamentações de dados aumentam – geralmente em resposta a roubos e violações de dados – também aumentam os
requisitos de conformidade. As organizações de segurança geralmente têm a tarefa de gerenciar não apenas os requisitos de conformidade
de TI, mas também políticas, práticas, classificações de dados e regras de autorização de acesso em toda a organização.
Assim como em outros aspectos do gerenciamento de dados, é melhor abordar a segurança de dados como uma iniciativa empresarial.
Sem um esforço coordenado, as unidades de negócios encontrarão soluções diferentes para as necessidades de segurança, aumentando
o custo geral e reduzindo potencialmente a segurança devido à proteção inconsistente. Arquitetura ou processos de segurança ineficazes
podem custar às organizações por meio de violações e perda de produtividade. Uma estratégia de segurança operacional devidamente
financiada, orientada a sistemas e consistente em toda a empresa reduzirá esses riscos.
A segurança da informação começa classificando os dados de uma organização para identificar quais dados requerem proteção. O processo
geral inclui as seguintes etapas:
• Identifique e classifique ativos de dados confidenciais: dependendo do setor e da organização, pode haver
poucos ou muitos ativos e uma variedade de dados confidenciais (incluindo identificação pessoal, dados médicos, financeiros,
e mais).
• Localize dados confidenciais em toda a empresa: os requisitos de segurança podem ser diferentes, dependendo
onde os dados são armazenados. Uma quantidade significativa de dados confidenciais em um único local representa um alto risco devido à
os danos possíveis de uma única violação.
• Determinar como cada ativo precisa ser protegido: As medidas necessárias para garantir a segurança podem
variam entre os ativos, dependendo do conteúdo dos dados e do tipo de tecnologia.

• Identifique como essas informações interagem com os processos de negócios: A análise dos processos de negócios é
necessários para determinar que acesso é permitido e em que condições.
Além de classificar os dados em si, é necessário avaliar ameaças externas (como as de hackers e criminosos) e riscos internos (de
funcionários e processos). Muitos dados são perdidos ou expostos devido à ignorância de funcionários que não perceberam que as
informações eram altamente confidenciais ou que ignoraram as políticas de segurança.37 Os dados de vendas do cliente deixados em um
servidor da Web que foi invadido, o banco de dados de funcionários baixado no laptop de um contratado que é posteriormente roubado e
segredos comerciais deixados sem criptografia no computador de um executivo que desaparece, todos resultam de controles de segurança
ausentes ou não aplicados.
O impacto das violações de segurança em marcas bem estabelecidas nos últimos anos resultou em enormes perdas financeiras e uma queda
na confiança do cliente. Não apenas as ameaças externas da comunidade de hackers criminosos estão se tornando mais sofisticadas e
direcionadas, a quantidade de danos causados por ameaças externas e internas, intencionais ou não, também tem aumentado constantemente
ao longo dos anos (Kark, 2009).
Em um mundo de infraestrutura empresarial quase totalmente eletrônica, os sistemas de informação confiáveis tornaram-se um
diferencial empresarial.
1.1.2 Crescimento do Negócio
Globalmente, a tecnologia eletrônica é difundida no escritório, no mercado e em casa. Computadores desktop e laptop, smartphones, tablets
e outros dispositivos são elementos importantes da maioria das operações comerciais e governamentais. O crescimento explosivo do
comércio eletrônico mudou a forma como as organizações oferecem bens e serviços. Em suas vidas pessoais, os indivíduos se acostumaram
a realizar negócios on-line com fornecedores de mercadorias, agências médicas, serviços públicos, escritórios governamentais e instituições
financeiras. E-commerce confiável gera lucro
e crescimento. A qualidade do produto e do serviço relaciona-se com a segurança da informação de uma forma bastante direta: a segurança
da informação robusta permite transações e constrói a confiança do cliente.
1.1.3 Título como um Ativo
Uma abordagem para gerenciar dados confidenciais é por meio de metadados. As classificações de segurança e a sensibilidade regulatória
podem ser capturadas no nível do elemento de dados e do conjunto de dados. A tecnologia existe para marcar os dados para que os
metadados viajem com as informações à medida que fluem pela empresa. Desenvolver um repositório mestre de características de dados
significa que todas as partes da empresa podem saber exatamente qual o nível de proteção que as informações confidenciais exigem.
37 Uma pesquisa afirmou que “70% dos profissionais de TI acreditam que o uso de programas não autorizados resultou em até
metade dos incidentes de perda de dados de suas empresas. Essa crença era mais comum nos Estados Unidos (74%), Brasil (75%)
e Índia (79%).” Um relatório do grupo Ponomon e do Symantic Anti-Virus descobriu que “erros humanos e problemas de sistema
causaram dois terços das violações de dados em 2012. http://bit.ly/1dGChAz, http://symc.ly/1FzNo5l, http://bit.ly/2sQ68Ba, http://
bit.ly/2tNEkKY.
222 • DMBOK2
Se um padrão comum for aplicado, essa abordagem permite que vários departamentos, unidades de negócios e fornecedores usem os mesmos
metadados. Segurança padrão Os metadados podem otimizar a proteção de dados e orientar o uso comercial e os processos de suporte técnico, levando
a custos mais baixos. Essa camada de segurança da informação pode ajudar a evitar o acesso não autorizado e o uso indevido de ativos de dados.
Quando os dados confidenciais são identificados corretamente como tal, as organizações criam confiança com seus clientes e parceiros. Os próprios
metadados relacionados à segurança tornam-se um ativo estratégico, aumentando a qualidade das transações, relatórios e análises de negócios, reduzindo
o custo de proteção e os riscos associados que as informações perdidas ou roubadas causam.
1.2.1 Objetivos
Os objetivos das atividades de segurança de dados incluem:
• Habilitar o acesso apropriado e prevenir o acesso inadequado aos ativos de dados corporativos
• Permitindo a conformidade com regulamentos e políticas de privacidade, proteção e confidencialidade
• Garantir que os requisitos das partes interessadas para privacidade e confidencialidade sejam atendidos
1.2.2 Princípios
A segurança de dados em uma organização segue estes princípios orientadores:
• Colaboração: A segurança de dados é um esforço colaborativo envolvendo administradores de segurança de TI,
stewards/governança de dados, equipes de auditoria interna e externa e o departamento jurídico.
• Abordagem empresarial: os padrões e políticas de segurança de dados devem ser aplicados de forma consistente em todo o
toda a organização.
• Gerenciamento proativo: O sucesso no gerenciamento de segurança de dados depende de ser proativo e
dinâmico, engajando todas as partes interessadas, gerenciando mudanças e superando organizações ou culturas
gargalos, como a tradicional separação de responsabilidades entre segurança da informação,
tecnologia, administração de dados e partes interessadas nos negócios.
• Responsabilidade clara: As funções e responsabilidades devem ser claramente definidas, incluindo a 'cadeia de
custódia' para dados entre organizações e funções.
• Orientada por metadados: a classificação de segurança para elementos de dados é uma parte essencial das definições de dados.
• Reduza o risco reduzindo a exposição: Minimize a proliferação de dados confidenciais/confidenciais, especialmente para
ambientes de não produção.

A segurança da informação tem um vocabulário específico. O conhecimento de termos-chave permite uma articulação mais clara dos
requisitos de governança.
1.3.1 Vulnerabilidade
Uma vulnerabilidade é uma fraqueza ou defeito em um sistema que permite que ele seja atacado e comprometido com sucesso –
essencialmente um buraco nas defesas de uma organização. Algumas vulnerabilidades são chamadas de exploits.
Exemplos incluem computadores em rede com patches de segurança desatualizados, páginas da Web não protegidas com senhas
robustas, usuários não treinados para ignorar anexos de e-mail de remetentes desconhecidos ou software corporativo desprotegido
contra comandos técnicos que darão ao invasor o controle do sistema.
Em muitos casos, os ambientes de não produção são mais vulneráveis a ameaças do que os ambientes de produção.
Portanto, é fundamental manter os dados de produção fora de ambientes de não produção.
1.3.2 Ameaça
Uma ameaça é uma ação ofensiva em potencial que pode ser tomada contra uma organização. As ameaças podem ser internas ou
externas. Nem sempre são maliciosos. Um insider uniformizado pode realizar ações ofensivas contra a organização mesmo sem saber.
As ameaças podem estar relacionadas a vulnerabilidades específicas, que podem ser priorizadas para correção. Cada ameaça deve
corresponder a um recurso que previne a ameaça ou limita o dano que ela pode causar. A ocorrência de uma ameaça também é
chamada de superfície de ataque.
Exemplos de ameaças incluem anexos de e-mail infectados por vírus sendo enviados para a organização, processos que sobrecarregam
os servidores de rede e resultam na incapacidade de realizar transações comerciais (também chamadas de ataques de negação de
serviço) e exploração de vulnerabilidades conhecidas.
1.3.3 Risco
O termo risco refere-se tanto à possibilidade de perda quanto à coisa ou condição que representa a perda potencial. Risco
pode ser calculado para cada possível ameaça usando os seguintes fatores.
• Probabilidade de que a ameaça ocorra e sua provável frequência
• O tipo e a quantidade de dano criado que cada ocorrência pode causar, incluindo danos à reputação
• O efeito que o dano terá na receita ou nas operações comerciais
• O custo para reparar o dano após uma ocorrência
• O custo para prevenir a ameaça, inclusive pela correção de vulnerabilidades
• O objetivo ou intenção do provável atacante

224 • DMBOK2
Os riscos podem ser priorizados pela gravidade potencial dos danos à empresa ou pela probabilidade de ocorrência, com vulnerabilidades
facilmente exploradas criando uma maior probabilidade de ocorrência. Muitas vezes, uma lista de prioridades combina ambas as métricas. A
priorização do risco deve ser um processo formal entre as partes interessadas.
1.3.4 Classificações de Risco
As classificações de risco descrevem a sensibilidade dos dados e a probabilidade de serem procurados para fins maliciosos. As classificações
são usadas para determinar quem (ou seja, pessoas em quais funções) pode acessar os dados.
A classificação de segurança mais alta de qualquer dado dentro de um direito de usuário determina a classificação de segurança de toda a
agregação. Exemplos de classificações incluem:
• Dados de Risco Crítico (CRD): Informações pessoais agressivamente procuradas para uso não autorizado por ambos
partes internas e externas devido ao seu alto valor financeiro direto. O comprometimento do CRD não só
prejudicar os indivíduos, mas resultaria em danos financeiros para a empresa de penalidades significativas, custos para
reter clientes e funcionários, bem como prejudicar a marca e a reputação.
• Dados de alto risco (HRD): o HRD é ativamente procurado para uso não autorizado devido ao seu potencial direto
valor financeiro. O HRD fornece à empresa uma vantagem competitiva. Se comprometido, pode expor
a empresa a danos financeiros por perda de oportunidade. A perda de DRH pode causar desconfiança levando a
a perda de negócios e pode resultar em exposição legal, multas e penalidades regulatórias, bem como danos
à marca e à reputação.
• Dados de risco moderado (MRD): informações da empresa que têm pouco valor tangível para
partidos; no entanto, o uso não autorizado dessas informações não públicas provavelmente teria um efeito negativo
efeito na empresa.
1.3.5 Organização de Segurança de Dados
Dependendo do tamanho da empresa, a função geral de Segurança da Informação pode ser a principal responsabilidade de um grupo
dedicado de Segurança da Informação, geralmente dentro da área de Tecnologia da Informação (TI).
As empresas maiores geralmente têm um Chief Information Security Officer (CISO) que se reporta ao CIO ou ao CEO. Em organizações sem
pessoal dedicado à Segurança da Informação, a responsabilidade pela segurança dos dados recairá sobre os gerentes de dados. Em todos
os casos, os gerentes de dados precisam estar envolvidos nos esforços de segurança de dados.
Em grandes empresas, o pessoal de segurança da informação pode permitir que funções específicas de governança de dados e autorização
de usuários sejam guiadas pelos gerentes de negócios. Os exemplos incluem conceder autorizações de usuário e conformidade regulatória
de dados. A equipe dedicada de segurança da informação geralmente está mais preocupada com os aspectos técnicos da proteção da
informação, como o combate a softwares mal-intencionados e ataques ao sistema. No entanto, há amplo espaço para colaboração durante o
desenvolvimento ou um projeto de instalação.
Esta oportunidade de sinergia é muitas vezes perdida quando as duas entidades de governança, TI e Gerenciamento de Dados, não possuem
um processo organizado para compartilhar requisitos regulatórios e de segurança. Eles precisam de um procedimento padrão para informar
regulamentos de dados, ameaças de perda de dados e requisitos de proteção de dados, e fazê-lo no início de cada projeto de instalação ou
desenvolvimento de software.
A primeira etapa da Estrutura de Gerenciamento de Risco do NIST (National Institute of Standards and Technology), por exemplo, é categorizar
todas as informações corporativas.38 A criação de um modelo de dados corporativos é essencial para esse objetivo.
Sem visibilidade clara da localização de todas as informações confidenciais, é impossível criar um programa abrangente e eficaz de proteção de
dados.
Os gerentes de dados precisam estar ativamente engajados com desenvolvedores de tecnologia da informação e profissionais de segurança
cibernética para que os dados regulamentados possam ser identificados, os sistemas confidenciais possam ser protegidos adequadamente e os
controles de acesso do usuário possam ser projetados para impor confidencialidade, integridade e conformidade regulatória de dados. Quanto
maior a empresa, mais importante se torna a necessidade de trabalho em equipe e a confiança em um modelo de dados corporativo correto e
atualizado.
1.3.6 Processos de Segurança
Os requisitos e procedimentos de segurança de dados são categorizados em quatro grupos, conhecidos como os quatro As: Acesso, Auditoria,
Autenticação e Autorização. Recentemente, um E, Entitlement, foi incluído, para conformidade regulatória de dados eficaz. Classificação de
informações, direitos de acesso, grupos de funções, usuários e senhas são os meios para implementar a política e satisfazer os quatro As. O
Monitoramento de Segurança também é essencial para comprovar o sucesso dos demais processos. Tanto o monitoramento quanto a auditoria
podem ser feitos de forma contínua ou intermitente. As auditorias formais devem ser feitas por terceiros para serem consideradas válidas. O
terceiro pode ser interno ou externo.
1.3.6.1 Os Quatro As
• Acesso: Permitir que indivíduos com autorização acessem os sistemas em tempo hábil. Usado como verbo,
acesso significa conectar-se ativamente a um sistema de informação e trabalhar com os dados. Usado como um
substantivo, acesso indica que a pessoa tem uma autorização válida para os dados.
• Auditoria: revise as ações de segurança e a atividade do usuário para garantir a conformidade com os regulamentos e
conformidade com a política e os padrões da empresa. Profissionais de segurança da informação periodicamente
revise logs e documentos para validar a conformidade com regulamentos, políticas e padrões de segurança.
Os resultados dessas auditorias são publicados periodicamente.
• Autenticação: Valida o acesso dos usuários. Quando um usuário tenta fazer login em um sistema, o sistema precisa
verificar se a pessoa é quem afirma ser. As senhas são uma maneira de fazer isso. Mais
métodos de autenticação rigorosos incluem a pessoa que possui um token de segurança, respondendo a perguntas ou
enviando uma impressão digital. Todas as transmissões durante a autenticação são criptografadas para evitar o roubo do
autenticando informações.
38 Instituto Nacional de Padrões e Tecnologia (EUA) http://bit.ly/1eQYolG.

226 • DMBOK2
• Autorização: Conceda privilégios aos indivíduos para acessar visualizações específicas de dados, apropriadas à sua função.
Após a decisão de autorização, o Sistema de Controle de Acesso verifica cada vez que um usuário faz login para ver se
eles têm um token de autorização válido. Tecnicamente, trata-se de uma entrada em um campo de dados no
Active Directory indicando que a pessoa foi autorizada por alguém a acessar os dados. Isto
indica ainda que uma pessoa responsável tomou a decisão de conceder esta autorização porque o
usuário tem direito a isso em virtude de seu trabalho ou status corporativo.
• Direito: Um direito é a soma total de todos os elementos de dados que são expostos a um usuário por um
decisão de autorização de acesso único. Um gerente responsável deve decidir que uma pessoa tem 'direito' a
acessar essas informações antes que uma solicitação de autorização seja gerada. Um inventário de todos os dados
exposto por cada direito é necessário para determinar os requisitos regulamentares e de confidencialidade
para decisões de direitos.
1.3.6.2 Monitoramento
Os sistemas devem incluir controles de monitoramento que detectam eventos inesperados, incluindo possíveis violações de segurança.
Os sistemas que contêm informações confidenciais, como dados salariais ou financeiros, geralmente implementam monitoramento ativo
em tempo real que alerta o administrador de segurança sobre atividades suspeitas ou acesso inadequado.
Alguns sistemas de segurança interromperão ativamente atividades que não seguem perfis de acesso específicos. A conta ou atividade
permanece bloqueada até que a equipe de suporte de segurança avalie os detalhes.
Por outro lado, o monitoramento passivo rastreia as mudanças ao longo do tempo tirando instantâneos do sistema em intervalos regulares
e comparando tendências com um benchmark ou outros critérios. O sistema envia relatórios aos administradores de dados ou ao
administrador de segurança responsável pelos dados. Enquanto o monitoramento ativo é um mecanismo de detecção, o monitoramento
passivo é um mecanismo de avaliação.
1.3.7 Integridade dos Dados
Em segurança, a integridade dos dados é o estado de integridade – protegido contra alteração, exclusão ou adição imprópria.
Por exemplo, nos EUA, as regulamentações Sarbanes-Oxley se preocupam principalmente com a proteção da integridade das informações
financeiras, identificando regras sobre como as informações financeiras podem ser criadas e editadas.
1.3.8 Criptografia
A criptografia é o processo de tradução de texto simples em códigos complexos para ocultar informações privilegiadas, verificar a
transmissão completa ou verificar a identidade do remetente. Os dados criptografados não podem ser lidos sem a chave ou algoritmo de
descriptografia, que geralmente é armazenado separadamente e não pode ser calculado com base em outros elementos de dados no
mesmo conjunto de dados. Existem quatro métodos principais de criptografia – hash, simétrico, chave privada e chave pública – com níveis
variados de complexidade e estrutura de chave.

1.3.8.1 Hash
A criptografia de hash usa algoritmos para converter dados em uma representação matemática. Os algoritmos exatos usados e a ordem de aplicação
devem ser conhecidos para reverter o processo de criptografia e revelar os dados originais.
Às vezes, o hashing é usado como verificação da integridade ou identidade da transmissão. Algoritmos de hash comuns são Message Digest 5 (MD5) e
Secure Hashing Algorithm (SHA).
1.3.8.2 Chave privada
A criptografia de chave privada usa uma chave para criptografar os dados. Tanto o remetente quanto o destinatário devem ter a chave para ler os dados
originais. Os dados podem ser criptografados um caractere por vez (como em um fluxo) ou em blocos. Algoritmos comuns de chave privada incluem Data
Encryption Standard (DES), Triple DES (3DES), Advanced Encryption Standard (AES) e International Data Encryption Algorithm (IDEA). Cyphers Twofish
e Serpent também são considerados seguros. O uso de DES simples é imprudente, pois é suscetível a muitos ataques fáceis.
1.3.8.3 Chave pública
Na criptografia de chave pública, o remetente e o destinatário têm chaves diferentes. O remetente usa uma chave pública que está disponível gratuitamente
e o destinatário usa uma chave privada para revelar os dados originais. Esse tipo de criptografia é útil quando muitas fontes de dados precisam enviar
informações protegidas para apenas alguns destinatários, como ao enviar dados para câmaras de compensação. Os métodos de chave pública incluem
troca de chave Rivest-Shamir-Adelman (RSA) e acordo de chave Diffie Hellman. PGP (Pretty Good Privacy) é um aplicativo de criptografia de chave
pública disponível gratuitamente.
1.3.9 Ofuscação ou Mascaramento
Os dados podem ficar menos disponíveis por ofuscação (tornando obscuros ou obscuros) ou mascaramento, que remove, embaralha ou altera a aparência
dos dados, sem perder o significado dos dados ou as relações que os dados têm com outros conjuntos de dados, como como relacionamentos de chave
estrangeira com outros objetos ou sistemas. Os valores dentro dos atributos podem mudar, mas os novos valores ainda são válidos para esses atributos.
A ofuscação é útil ao exibir informações confidenciais em telas para referência ou criar conjuntos de dados de teste a partir de dados de produção que
estejam em conformidade com a lógica do aplicativo esperada.
O mascaramento de dados é um tipo de segurança centrada em dados. Existem dois tipos de mascaramento de dados, persistente e dinâmico.
O mascaramento persistente pode ser executado em andamento ou no local.
1.3.9.1 Mascaramento de Dados Persistentes
O mascaramento de dados persistente altera os dados de forma permanente e irreversível. Esse tipo de mascaramento normalmente não é usado em
ambientes de produção, mas sim entre um ambiente de produção e desenvolvimento ou teste

228 • DMBOK2
ambientes. O mascaramento persistente altera os dados, mas os dados ainda devem ser viáveis para uso em processos de teste, aplicativos, relatórios
etc.
• O mascaramento persistente em andamento ocorre quando os dados são mascarados ou ofuscados enquanto estão em movimento
entre o ambiente de origem (normalmente produção) e destino (normalmente não-produção). O mascaramento em voo é muito seguro
quando executado corretamente, pois não deixa um arquivo intermediário ou banco de dados com dados desmascarados. Outro benefício
é que ele pode ser executado novamente se problemas forem encontrados no meio do mascaramento.
• O mascaramento persistente in-loco é usado quando a origem e o destino são os mesmos. Os dados desmascarados são lidos da origem,
mascarados e usados para substituir os dados desmascarados. O mascaramento in-loco pressupõe que os dados confidenciais estão em
um local onde não deveriam existir e o risco precisa ser mitigado ou que há uma cópia extra dos dados em um local seguro para mascarar
antes de movê-los para o local não seguro . Existem riscos nesse processo. Se o processo de mascaramento falhar no meio do
mascaramento, pode ser difícil restaurar os dados para um formato utilizável. Essa técnica tem alguns usos de nicho, mas, em geral, o
mascaramento em voo atenderá com mais segurança às necessidades do projeto.
1.3.9.2 Mascaramento de Dados Dinâmicos
O mascaramento de dados dinâmico altera a aparência dos dados para o usuário final ou sistema sem alterar os dados subjacentes. Isso pode ser
extremamente útil quando os usuários precisam acessar alguns dados de produção confidenciais, mas não todos. Por exemplo, em um banco de dados,
o número do seguro social é armazenado como 123456789, mas para o funcionário da central de atendimento que precisa verificar com quem está
falando, os dados aparecem como ***-**-6789.
1.3.9.3 Métodos de mascaramento
Existem vários métodos para mascarar ou ofuscar dados.
• Substituição: Substitua caracteres ou valores inteiros por aqueles em uma pesquisa ou como um padrão padrão. Por
Por exemplo, os primeiros nomes podem ser substituídos por valores aleatórios de uma lista.
• Embaralhamento: Troque elementos de dados do mesmo tipo em um registro ou troque elementos de dados de um atributo
entre as linhas. Por exemplo, misturar nomes de fornecedores entre faturas de fornecedores de forma que o fornecedor original
seja substituído por um fornecedor válido diferente em uma fatura.
• Variação temporal: Mova datas +/– um número de dias – pequeno o suficiente para preservar tendências, mas
significativo o suficiente para torná-los não identificáveis.
• Variação de valor: Aplique um fator aleatório +/– uma porcentagem, novamente pequeno o suficiente para preservar tendências, mas
significativo o suficiente para não ser identificável.
• Anulação ou exclusão: remova dados que não deveriam estar presentes em um sistema de teste.
• Randomização: Substitua parte ou todos os elementos de dados por caracteres aleatórios ou uma série de
único caractere.
• Criptografia: converte um fluxo de caracteres reconhecivelmente significativo em um caractere irreconhecível
stream por meio de um código cifrado. Uma versão extrema de ofuscação no local.
• Máscara de expressão: altera todos os valores para o resultado de uma expressão. Por exemplo, um simples
expressão apenas codificaria todos os valores em um grande campo de banco de dados de formato livre (que poderia potencialmente
contêm dados confidenciais) para 'Este é um campo de comentário'.
• Mascaramento de chave: Designe que o resultado do algoritmo/processo de mascaramento deve ser único e
repetível porque está sendo usado para mascarar um campo chave do banco de dados (ou similar). Este tipo de mascaramento é
extremamente importante para os testes manterem a integridade em toda a organização.
1.3.10 Termos de Segurança de Rede
A segurança de dados inclui dados em repouso e dados em movimento. Os dados em movimento requerem uma rede para se mover entre os sistemas.
Não é mais suficiente para uma organização confiar totalmente no firewall para protegê-lo contra software malicioso, email envenenado ou ataques de
engenharia social. Cada máquina na rede precisa ter uma linha de defesa, e os servidores web precisam de proteção sofisticada, pois estão
continuamente expostos a todo o

mundo na Internet.
1.3.10.1 Porta dos fundos
Um backdoor refere-se a uma entrada ignorada ou oculta em um sistema ou aplicativo de computador. Ele permite que usuários não autorizados
ignorem o requisito de senha para obter acesso. Os backdoors são frequentemente criados por desenvolvedores para fins de manutenção. Qualquer
backdoor é um risco de segurança. Outros backdoors são implementados pelos criadores de pacotes de software comercial.
As senhas padrão deixadas inalteradas ao instalar qualquer sistema de software ou pacote de página da Web são um backdoor e, sem dúvida, serão
conhecidas pelos hackers. Qualquer backdoor é um risco de segurança.
1.3.10.2 Bot ou Zumbi
Um bot (abreviação de robô) ou Zombie é uma estação de trabalho que foi invadida por um hacker malicioso usando um Trojan, um vírus, um Phish ou
o download de um arquivo infectado. Controlados remotamente, os bots são usados para executar tarefas maliciosas, como enviar grandes quantidades
de spam, atacar empresas legítimas com obstrução de rede

230 • DMBOK2
Pacotes de Internet, realização de transferências ilegais de dinheiro e hospedagem de sites fraudulentos. Um Bot-Net é uma rede de
computadores robôs (máquinas infectadas).39
Foi estimado em 2012 que globalmente 17% de todos os computadores (aproximadamente 187 milhões de 1,1 bilhão de computadores)
40
não possuem proteção antivírus. Nos EUA naquele ano, 19,32% dos usuários navegaram desprotegidos. UMA
41
grande porcentagem deles são zumbis. As estimativas são de que dois bilhões de computadores estejam em operação a partir de 2016.
Considerando que computadores desktop e laptops estão sendo eclipsados em número por smartphones, tablets, wearables e outros
dispositivos, muitos dos quais são usados para transações comerciais, os riscos de exposição de dados só aumentarão.42
1.3.10.3 Cookie
Um cookie é um pequeno arquivo de dados que um site instala no disco rígido de um computador, para identificar visitantes que retornam
e perfilar suas preferências. Os cookies são usados para comércio na Internet. No entanto, eles também são controversos, pois levantam
questões de privacidade porque o spyware às vezes os usa.
1.3.10.4 Firewall
Um firewall é um software e/ou hardware que filtra o tráfego de rede para proteger um computador individual ou uma rede inteira contra
tentativas não autorizadas de acessar ou atacar o sistema. Um firewall pode verificar as comunicações de entrada e de saída em busca
de informações restritas ou regulamentadas e impedir que elas passem sem permissão (Prevenção de perda de dados). Alguns firewalls
também restringem o acesso a sites externos específicos.
1.3.10.5 Perímetro
Um perímetro é o limite entre os ambientes de uma organização e os sistemas externos. Normalmente, um firewall estará instalado entre
todos os ambientes internos e externos.
39 http://bit.ly/1FrKWR8, http://bit.ly/2rQQuWJ.
40 http://tcrn.ch/2rRnsGr (17% globalmente não possuem AV), http://bit.ly/2rUE2R4, http://bit.ly/2sPLBN4, http://ubm.io/1157kyO

(Windows 8 falta de AV).
41 http://bit.ly/2tNLO0i (número de 2016 chega a 2 bilhões.), http://bit.ly/2rCzDCV, http://bit.ly/2tNpwfg.
42 A Cisco Corporation estimou que “até 2018, haverá 8,2 bilhões de dispositivos portáteis ou pessoais prontos para dispositivos móveis
e 2 bilhões de conexões máquina a máquina (por exemplo, sistemas GPS em carros, sistemas de rastreamento de ativos nos setores de
transporte e manufatura ou aplicações médicas). tornando os registros dos pacientes e o estado de saúde mais prontamente disponíveis.)”
http://bit.ly/Msevdw ( números futuros de computadores e dispositivos).
1.3.10.6 DMZ
Abreviação de zona desmilitarizada, uma DMZ é uma área na borda ou perímetro de uma organização, com um firewall
entre ela e a organização. Um ambiente DMZ sempre terá um firewall entre ele e a internet (veja a Figura 64). Os ambientes
DMZ são usados para transmitir ou armazenar temporariamente dados que se movem entre organizações.
DMZ interno
Sistemas
Figura 64 Exemplo de DMZ
1.3.10.7 Conta de superusuário
Uma conta de superusuário é uma conta que possui acesso de administrador ou root a um sistema para ser usado apenas
em caso de emergência. As credenciais para essas contas são altamente seguras, liberadas apenas em caso de emergência
com documentação e aprovações apropriadas e expiram em pouco tempo. Por exemplo, a equipe designada para o controle
de produção pode exigir autorizações de acesso a vários sistemas grandes, mas essas autorizações devem ser rigidamente
controladas por hora, ID do usuário, local ou outro requisito para evitar abusos.
1.3.10.8 Registrador de Chaves
Key Loggers são um tipo de software de ataque que registra todas as teclas que uma pessoa digita em seu teclado e as
envia para outro lugar na Internet. Assim, todas as senhas, memorandos, fórmulas, documentos e endereços da Web são
capturados. Muitas vezes, um site infectado ou download de software malicioso instala um keylogger. Alguns tipos de
downloads de documentos também permitem que isso aconteça.
1.3.10.9 Teste de penetração
A configuração de uma rede e site seguros é incompleta sem testá-lo para ter certeza de que ele realmente é seguro. No
teste de penetração (às vezes chamado de 'penn test'), um hacker ético, seja da própria organização ou contratado de uma
empresa de segurança externa, tenta invadir o sistema de fora, como faria um hacker malicioso, para identificar
vulnerabilidades do sistema . As vulnerabilidades encontradas por meio de testes de penetração podem ser corrigidas antes
do lançamento do aplicativo.
232 • DMBOK2
Algumas pessoas são ameaçadas por auditorias de hackers éticos porque acreditam que essas auditorias resultarão apenas em acusações. A realidade
é que no conflito veloz entre segurança empresarial e hacking criminoso, todos os softwares adquiridos e desenvolvidos internamente contêm
vulnerabilidades potenciais que não eram conhecidas no momento de sua criação. Assim, todas as implementações de software devem ser desafiadas
periodicamente. Encontrar vulnerabilidades é um procedimento contínuo e nenhuma culpa deve ser aplicada – apenas patches de segurança.
Como prova da necessidade de mitigação contínua de vulnerabilidades de software, observe um fluxo constante de patches de segurança que chegam
de fornecedores de software. Esse processo contínuo de atualização de patches de segurança é um sinal de diligência e suporte profissional ao cliente
desses fornecedores. Muitos desses patches são o resultado de hackers éticos realizados em nome dos fornecedores.
1.3.10.10 Rede Privada Virtual (VPN)
As conexões VPN usam a Internet não segura para criar um caminho seguro ou 'túnel' no ambiente de uma organização. O túnel é altamente
criptografado. Ele permite a comunicação entre os usuários e a rede interna usando vários elementos de autenticação para conectar-se a um firewall
no perímetro do ambiente de uma organização. Em seguida, ele criptografa fortemente todos os dados transmitidos.
1.3.11 Tipos de Segurança de Dados
A segurança de dados envolve não apenas impedir o acesso inadequado, mas também permitir o acesso adequado aos dados.
O acesso a dados confidenciais deve ser controlado por meio da concessão de permissões (opt-in). Sem permissão, um usuário não deve ter permissão
para ver dados ou realizar ações no sistema. O 'menor privilégio' é um importante princípio de segurança. Um usuário, processo ou programa deve ter
permissão para acessar apenas as informações permitidas por seu propósito legítimo.
1.3.11.1 Segurança da Instalação
A segurança das instalações é a primeira linha de defesa contra maus atores. As instalações devem ter, no mínimo, um data center bloqueado com
acesso restrito a funcionários autorizados. As ameaças sociais à segurança (ver Seção 1.3.15) reconhecem os humanos como o ponto mais fraco na
segurança das instalações. Garanta que os funcionários tenham as ferramentas e o treinamento para proteger os dados nas instalações.
1.3.11.2 Segurança do Dispositivo
Dispositivos móveis, incluindo laptops, tablets e smartphones, são inerentemente inseguros, pois podem ser perdidos, roubados e atacados física e
eletronicamente por hackers criminosos. Eles geralmente contêm e-mails corporativos,

planilhas, endereços e documentos que, se expostos, podem prejudicar a organização, seus funcionários ou
seus clientes.
Com a explosão de dispositivos e mídias portáteis, um plano para gerenciar a segurança desses dispositivos (de propriedade da empresa e
pessoais) deve fazer parte da arquitetura de segurança estratégica geral de qualquer empresa. Este plano
deve incluir ferramentas de software e hardware.
Os padrões de segurança do dispositivo incluem:
• Políticas de acesso relacionadas a conexões usando dispositivos móveis
• Armazenamento de dados em dispositivos portáteis, como laptops, DVDs, CDs ou unidades USB
• Limpeza de dados e descarte de dispositivos em conformidade com as políticas de gerenciamento de registros
• Instalação de software antimalware e criptografia
• Conscientização das vulnerabilidades de segurança
1.3.11.3 Segurança de credenciais
Cada usuário recebe credenciais para usar ao obter acesso a um sistema. A maioria das credenciais é uma combinação de uma ID de usuário e
uma senha. Há um espectro de como as credenciais são usadas nos sistemas dentro de um ambiente, dependendo da sensibilidade dos dados
do sistema e dos recursos do sistema para vincular-se a repositórios de credenciais.
1.3.11.3.1 Sistemas de Gerenciamento de Identidade
Tradicionalmente, os usuários têm contas e senhas diferentes para cada recurso individual, plataforma, sistema de aplicativo ou estação de
trabalho. Essa abordagem exige que os usuários gerenciem várias senhas e contas.
Organizações com diretórios de usuários corporativos podem ter um mecanismo de sincronização estabelecido entre os recursos heterogêneos
para facilitar o gerenciamento de senhas de usuários. Nesses casos, o usuário é solicitado a digitar a senha apenas uma vez, geralmente ao
efetuar login na estação de trabalho, após o que toda autenticação e autorização são executadas por meio de uma referência ao diretório de
usuários corporativos. Um sistema de gerenciamento de identidade que implementa esse recurso é conhecido como 'login único' e é ideal do
ponto de vista do usuário.
1.3.11.3.2 Padrões de ID de usuário para sistemas de e-mail
Os IDs de usuário devem ser exclusivos no domínio de e-mail. A maioria das empresas usa algum nome ou inicial e sobrenome completo ou
parcial como e-mail ou ID de rede, com um número para diferenciar colisões. Os nomes são geralmente
conhecidos e são mais úteis por motivos de contato comercial.
E-mail ou IDs de rede contendo números de identificação de funcionários do sistema são desencorajados, pois essas informações geralmente
não estão disponíveis fora da organização e fornecem dados que devem estar seguros dentro dos sistemas.
234 • DMBOK2
1.3.11.3.3 Padrões de Senha
As senhas são a primeira linha de defesa na proteção do acesso aos dados. Cada conta de usuário deve ter uma senha definida pelo usuário
(proprietário da conta) com um nível suficiente de complexidade de senha definido nos padrões de segurança, comumente chamados de senhas
'fortes'.
Ao criar uma nova conta de usuário, a senha temporária gerada deve ser configurada para expirar imediatamente após o primeiro uso e o usuário
deve escolher uma nova senha para acesso posterior. Não permita senhas em branco.
A maioria dos especialistas em segurança recomenda exigir que os usuários alterem suas senhas a cada 45 a 180 dias, dependendo da natureza do
sistema, do tipo de dados e da sensibilidade da empresa. No entanto, alterar as senhas com muita frequência apresenta riscos, pois geralmente faz
com que os funcionários anotem suas novas senhas.
1.3.11.3.4 Identificação de múltiplos fatores
Alguns sistemas requerem procedimentos de identificação adicionais. Isso pode incluir uma chamada de retorno para o dispositivo móvel do usuário
que contém um código, o uso de um item de hardware que deve ser usado para login ou um fator biométrico, como impressão digital, reconhecimento
facial ou digitalização de retina. A identificação de dois fatores torna muito mais difícil invadir uma conta ou fazer login no dispositivo de um usuário.
Todos os usuários com autorização para informações altamente confidenciais devem usar a identificação de dois fatores para fazer login na rede.
1.3.11.4 Segurança das Comunicações Eletrônicas
Os usuários devem ser treinados para evitar o envio de suas informações pessoais ou qualquer informação restrita ou confidencial da empresa por e-
mail ou aplicativos de comunicação direta. Esses métodos inseguros de comunicação podem ser lidos ou interceptados por fontes externas. Depois
que um usuário envia um e-mail, ele não controla mais as informações nele contidas. Ele pode ser encaminhado a outras pessoas sem o conhecimento
ou consentimento do remetente.
A mídia social também se aplica aqui. Blogs, portais, wikis, fóruns e outras mídias sociais da Internet ou Intranet devem
ser considerado inseguro e não deve conter informações confidenciais ou restritas.
1.3.12 Tipos de Restrições de Segurança de Dados
Dois conceitos orientam as restrições de segurança: o nível de confidencialidade dos dados e a regulamentação relacionada aos dados.
• Nível de confidencialidade: Confidencial significa secreto ou privado. As organizações determinam quais tipos de
os dados não devem ser conhecidos fora da organização, ou mesmo dentro de certas partes da organização.
As informações confidenciais são compartilhadas apenas com base na 'necessidade de saber'. Os níveis de confidencialidade dependem
que precisa saber certos tipos de informação.
• Regulamentação: as categorias regulatórias são atribuídas com base em regras externas, como leis, tratados, costumes
acordos e regulamentações do setor. As informações regulamentares são compartilhadas em uma base de 'permissão para saber'.
As maneiras pelas quais os dados podem ser compartilhados são regidas pelos detalhes do regulamento.
A principal diferença entre restrições confidenciais e regulatórias é onde a restrição se origina: as restrições de confidencialidade se originam
internamente, enquanto as restrições regulatórias são definidas externamente.
Outra diferença é que qualquer conjunto de dados, como um documento ou uma exibição de banco de dados, pode ter apenas um nível de
confidencialidade. Esse nível é estabelecido com base no item mais sensível (e mais classificado) no conjunto de dados. As categorizações
regulatórias, no entanto, são aditivas. Um único conjunto de dados pode ter dados restritos com base em várias categorias regulatórias. Para
garantir a conformidade regulatória, aplique todas as ações necessárias para cada categoria, juntamente com os requisitos de confidencialidade.
Quando aplicado ao direito do usuário (a agregação dos elementos de dados específicos aos quais uma autorização do usuário fornece
acesso), todas as políticas de proteção devem ser seguidas, independentemente de terem sido originadas interna ou externamente.
1.3.12.1 Dados Confidenciais
Os requisitos de confidencialidade variam de alto (poucas pessoas têm acesso, por exemplo, a dados sobre remuneração de funcionários) a
baixo (todos têm acesso a catálogos de produtos). Um esquema de classificação típico
pode incluir dois ou mais dos cinco níveis de classificação de confidencialidade listados aqui:
• Para o público em geral: Informações disponíveis para qualquer pessoa, incluindo o público.
• Apenas para uso interno: Informações limitadas a funcionários ou membros, mas com risco mínimo se compartilhadas. Por
somente para uso interno; pode ser mostrado ou discutido, mas não copiado, fora da organização.
• Confidencial: Informações que não podem ser compartilhadas fora da organização sem um
acordo de confidencialidade ou similar em vigor. As informações confidenciais do cliente não podem ser compartilhadas com
outros clientes.
• Confidencial restrito: Informações limitadas a indivíduos que desempenhem determinadas funções com a 'necessidade de
conhecer.' Confidencial restrito pode exigir que os indivíduos se qualifiquem por meio de autorização.
• Confidencial registrado: Informações tão confidenciais que qualquer pessoa que acesse as informações deve assinar
um acordo legal para acessar os dados e assumir a responsabilidade por seu sigilo.
O nível de confidencialidade não implica em detalhes sobre restrições devido a requisitos regulatórios. Por exemplo, não informa ao gerente de
dados que os dados não podem ser expostos fora de seu país de origem ou que alguns funcionários estão proibidos de ver determinadas
informações com base em regulamentações como HIPAA.

236 • DMBOK2
1.3.12.2 Dados Regulamentados
Certos tipos de informações são regulamentados por leis externas, padrões do setor ou contratos que influenciam como os dados podem ser
usados, bem como quem pode acessá-los e para quais finalidades. Como há muitos regulamentos sobrepostos, é mais fácil coletá-los por área de
assunto em algumas categorias ou famílias regulatórias para informar melhor os gerentes de dados sobre os requisitos regulatórios.
Cada empresa, é claro, deve desenvolver categorias regulatórias que atendam às suas próprias necessidades de conformidade. Além disso, é
importante que esse processo e as categorias sejam o mais simples possível para permitir uma capacidade de proteção acionável. Quando as
ações de proteção da categoria são semelhantes, elas devem ser combinadas em um regulamento 'família'.
Cada categoria regulatória deve incluir ações de proteção auditáveis. Esta não é uma ferramenta organizacional, mas uma
método de execução.
Como diferentes setores são afetados por diferentes tipos de regulamentações, a organização precisa desenvolver agrupamentos regulatórios que
atendam às suas necessidades operacionais. Por exemplo, as empresas que não fazem negócios fora de sua terra natal podem não precisar
incorporar regulamentos relativos às exportações.
No entanto, como todas as nações têm alguma mistura de leis de privacidade de dados pessoais, e os clientes provavelmente vêm de qualquer
lugar do mundo, pode ser sensato e mais fácil reunir todos os regulamentos de privacidade de dados de clientes em uma única família regulatória
e cumprir os requisitos para todas as nações. Isso garante a conformidade em todos os lugares e oferece um único padrão a ser aplicado.
Um exemplo do possível detalhe de conformidade regulatória é aquele que proíbe por lei um único tipo de elemento de dados no banco de dados
de viajar para fora das fronteiras físicas da nação de origem. Várias regulamentações, tanto nacionais quanto internacionais, têm isso como requisito.
Um número ideal de categorias de ação regulatória é nove ou menos. Seguem exemplos de categorias regulatórias.
1.3.12.2.1 Amostra de Famílias Reguladoras
Certos regulamentos governamentais especificam elementos de dados por nome e exigem que eles sejam protegidos de maneiras específicas.
Cada elemento não precisa de uma categoria diferente; em vez disso, use uma única família de ações para proteger todos os campos de dados
especificamente direcionados. Alguns dados do PCI podem ser incluídos nessas categorias mesmo que seja uma obrigação contratual e não uma
regulamentação governamental. As obrigações contratuais do PCI são geralmente uniformes em todo o mundo.
• Informações de Identificação Pessoal (PII): Também conhecidas como Informações Pessoais Privadas (PPI),
inclui qualquer informação que possa identificar pessoalmente o indivíduo (individualmente ou em conjunto), como
nome, endereço, números de telefone, agenda, número de identificação do governo, números de conta, idade, raça,
religião, etnia, data de nascimento, nomes de familiares ou amigos, informações sobre emprego (RH
dados) e, em muitos casos, remuneração. Ações de proteção altamente semelhantes satisfarão a privacidade da UE
Diretivas, lei de privacidade canadense (PIPEDA), PIP Act 2003 no Japão, padrões PCI, US FTC
requisitos, GLB, padrões FTC e a maioria das Leis de Violação de Segurança de Informações.
• Dados Financeiros Sensíveis: Todas as informações financeiras, incluindo o que pode ser denominado dados de 'acionistas'
ou 'privilegiados', incluindo todas as informações financeiras atuais que ainda não foram divulgadas publicamente. Também
inclui quaisquer planos de negócios futuros não tornados públicos, fusões, aquisições ou cisões planejadas, relatórios não
públicos de problemas significativos da empresa, mudanças inesperadas na alta administração, vendas abrangentes, pedidos
e dados de cobrança. Tudo isso pode ser capturado dentro dessa categoria e protegido pelas mesmas políticas. Nos EUA,
isso é coberto pelas Leis de Negociação com Informações Privilegiadas, SOX (Sarbanes-Oxley Act) ou GLBA (Gramm-Leach-
Bliley/Lei de Modernização de Serviços Financeiros). Observação: a lei Sarbanes-Oxley restringe e gerencia quem pode
alterar os dados financeiros, garantindo assim a integridade dos dados, enquanto as leis de insider Trading afetam todos
aqueles que podem ver os dados financeiros.
• Dados medicamente sensíveis/Informações de saúde pessoal (PHI): Todas as informações sobre a saúde de uma pessoa
ou tratamentos médicos. Nos EUA, isso é coberto pela HIPAA (Health Information Portability and Accountability Act). Outras
nações também têm leis restritivas em relação à proteção de informações pessoais e médicas. À medida que eles estão
evoluindo, certifique-se de que o Conselho Corporativo esteja ciente da necessidade de seguir os requisitos legais em um
país em que a organização faz negócios ou tem clientes.
• Registros Educacionais: Todas as informações sobre a educação de uma pessoa. Nos EUA, isso é coberto por
FERPA (Lei de Privacidade e Direitos Educacionais da Família).
1.3.12.2.2 Regulamentação baseada em contrato ou indústria
Alguns setores têm padrões específicos sobre como registrar, reter e criptografar informações. Alguns também não permitem a exclusão,
edição ou distribuição para locais proibidos. Por exemplo, regulamentações para produtos farmacêuticos, outras substâncias perigosas,
alimentos, cosméticos e tecnologia avançada impedem a transmissão ou armazenamento de certas informações fora do país de origem
ou exigem que os dados sejam criptografados durante o transporte.
• Padrão de segurança de dados do setor de cartões de pagamento (PCI-DSS): PCI-DSS é o padrão de segurança de
dados do setor mais conhecido. Ele aborda qualquer informação que possa identificar um indivíduo com uma conta em
uma organização financeira, como nome, número do cartão de crédito (qualquer número no cartão), número da conta
bancária ou data de vencimento da conta. A maioria desses campos de dados é regulamentada por leis e políticas.
Quaisquer dados com essa classificação em sua definição de Metadados automaticamente devem ser cuidadosamente
revisados pelos administradores de dados quando incluídos em qualquer banco de dados, aplicativo, relatório, painel ou visualização do usuário.
• Vantagem competitiva ou segredos comerciais: Empresas que utilizam métodos proprietários, misturas,
fórmulas, fontes, designs, ferramentas, receitas ou técnicas operacionais para obter uma vantagem competitiva podem ser
protegidos por regulamentos do setor e/ou leis de propriedade intelectual.
• Restrições contratuais: Em seus contratos com fornecedores e parceiros, uma organização pode estipular
como informações específicas podem ou não ser usadas e quais informações podem e não podem ser compartilhadas. Por
exemplo, registros ambientais, relatórios de materiais perigosos, números de lote, tempos de cozimento, pontos de origem,
senhas de clientes, números de contas e determinados números de identidade nacional de cidadãos não americanos.
Empresas técnicas específicas podem precisar incluir determinados produtos ou ingredientes restritos nesta categoria.
238 • DMBOK2
1.3.13 Riscos de Segurança do Sistema
A primeira etapa para identificar o risco é identificar onde os dados confidenciais são armazenados e quais proteções são necessárias para
esses dados. Também é necessário identificar os riscos inerentes aos sistemas. Os riscos de segurança do sistema incluem elementos que
podem comprometer uma rede ou banco de dados. Essas ameaças permitem que funcionários legítimos façam uso indevido de informações,
intencionalmente ou acidentalmente, e permitem o sucesso de hackers mal-intencionados.
1.3.13.1 Abuso de Privilégio Excessivo
Ao conceder acesso aos dados, o princípio do privilégio mínimo deve ser aplicado. Um usuário, processo ou programa deve ter permissão para
acessar apenas as informações permitidas por seu propósito legítimo. O risco é que usuários com privilégios que excedam os requisitos de sua
função de trabalho possam abusar desses privilégios para fins maliciosos ou acidentalmente. Os usuários podem receber mais acesso do que
deveriam (privilégios excessivos) simplesmente porque é um desafio gerenciar os direitos dos usuários. O DBA pode não ter tempo ou
metadados para definir e atualizar mecanismos de controle de privilégio de acesso granular para cada direito de usuário. Como resultado,
muitos usuários recebem privilégios de acesso padrão genéricos que excedem em muito os requisitos de trabalho específicos. Essa falta de
supervisão dos direitos do usuário é uma das razões pelas quais muitas regulamentações de dados especificam a segurança do gerenciamento
de dados.
A solução para privilégios excessivos é o controle de acesso em nível de consulta, um mecanismo que restringe os privilégios do banco de
dados a operações e dados SQL mínimos. A granularidade do controle de acesso a dados deve se estender além da tabela para linhas e
colunas específicas dentro de uma tabela. O controle de acesso em nível de consulta é útil para detectar abuso excessivo de privilégios por
funcionários mal-intencionados.
A maioria das implementações de software de banco de dados integra algum nível de controle de acesso em nível de consulta (gatilhos,
segurança em nível de linha, segurança de tabela, exibições), mas a natureza manual desses recursos 'internos' os torna impraticáveis para
todas as implantações, exceto as mais limitadas. O processo de definir manualmente uma política de controle de acesso em nível de consulta
para todos os usuários nas linhas, colunas e operações do banco de dados é demorado. Para piorar a situação, à medida que as funções do
usuário mudam ao longo do tempo, as políticas de consulta devem ser atualizadas para refletir essas novas funções. A maioria dos
administradores de banco de dados teria dificuldade em definir uma política de consulta útil para um punhado de usuários em um único
momento, muito menos para centenas de usuários ao longo do tempo. Como resultado, em um grande número de organizações, geralmente
são necessárias ferramentas automatizadas para tornar funcional o controle de acesso em nível de consulta real.
1.3.13.2 Abuso de Privilégio Legítimo
Os usuários podem abusar dos privilégios legítimos do banco de dados para fins não autorizados. Considere um profissional de saúde inclinado
ao crime com privilégios para visualizar registros individuais de pacientes por meio de um aplicativo da Web personalizado.
A estrutura dos aplicativos da Web corporativos normalmente limita os usuários a visualizar o histórico de saúde de um paciente individual,
onde vários registros não podem ser visualizados simultaneamente e cópias eletrônicas não são permitidas.
No entanto, o trabalhador pode contornar essas limitações conectando-se ao banco de dados usando uma alternativa
sistema como MS-Excel. Usando o MS-Excel e suas credenciais de login legítimas, o funcionário pode recuperar e salvar todos os
registros do paciente.
Há dois riscos a serem considerados: abuso intencional e não intencional. O abuso intencional ocorre quando um funcionário usa de
forma deliberada os dados organizacionais. Por exemplo, um trabalhador errante que deseja trocar registros de pacientes por dinheiro
ou por danos intencionais, como liberar (ou ameaçar divulgar) informações confidenciais publicamente.
O abuso não intencional é um risco mais comum: o funcionário diligente que recupera e armazena grandes quantidades de informações
do paciente em uma máquina de trabalho para o que considera fins de trabalho legítimos. Uma vez que os dados existam em uma
máquina de endpoint, eles se tornam vulneráveis a roubo e perda de laptop.
A solução parcial para o abuso de privilégios legítimos é o controle de acesso ao banco de dados que não se aplica apenas a consultas
específicas, mas também impõe políticas para máquinas de ponto final usando hora do dia, monitoramento de local e quantidade de
informações baixadas, e reduz a capacidade de qualquer usuário tenha acesso ilimitado a todos os registros que contenham informações
confidenciais, a menos que seja especificamente exigido por seu trabalho e aprovado por seu supervisor. Por exemplo, embora possa
ser necessário que um agente de campo acesse os registros pessoais de seu cliente, ele pode não ter permissão para fazer download
de todo o banco de dados do cliente em seu laptop apenas para 'economizar tempo'.
1.3.13.3 Elevação de privilégios não autorizada
Os invasores podem aproveitar as vulnerabilidades do software da plataforma de banco de dados para converter os privilégios de
acesso de um usuário comum para os de um administrador. Vulnerabilidades podem ocorrer em procedimentos armazenados, funções
internas, implementações de protocolo e até instruções SQL. Por exemplo, um desenvolvedor de software em uma instituição financeira
pode aproveitar uma função vulnerável para obter o privilégio administrativo do banco de dados. Com privilégio administrativo, o
desenvolvedor infrator pode desativar mecanismos de auditoria, criar contas falsas, transferir fundos ou encerrar contas.
Evite explorações de elevação de privilégios com uma combinação de sistemas tradicionais de prevenção de intrusões (IPS) e prevenção
de intrusões de controle de acesso em nível de consulta. Esses sistemas inspecionam o tráfego do banco de dados para identificar
padrões que correspondam a vulnerabilidades conhecidas. Por exemplo, se uma determinada função for vulnerável a um ataque, um
IPS pode bloquear todo o acesso ao procedimento ou bloquear esses procedimentos permitindo ataques incorporados.
Combine o IPS com indicadores alternativos de ataque, como controle de acesso a consultas, para melhorar a precisão na identificação
de ataques. O IPS pode detectar se uma solicitação de banco de dados acessa uma função vulnerável, enquanto o controle de acesso
de consulta detecta se a solicitação corresponde ao comportamento normal do usuário. Se uma única solicitação indica acesso a uma
função vulnerável e comportamento incomum, é quase certo que um ataque está ocorrendo.
1.3.13.4 Conta de Serviço ou Abuso de Conta Compartilhada
O uso de contas de serviço (IDs de lote) e contas compartilhadas (IDs genéricos) aumenta o risco de violações de segurança de dados
e complica a capacidade de rastrear a violação até sua origem. Algumas organizações aumentam ainda mais seus
240 • DMBOK2
risco quando configuram sistemas de monitoramento para ignorar quaisquer alertas relacionados a essas contas. Os gerentes de segurança da
informação devem considerar a adoção de ferramentas para gerenciar contas de serviço com segurança.
1.3.13.4.1 Contas de serviço
As contas de serviço são convenientes porque podem personalizar o acesso aprimorado para os processos que as utilizam.
No entanto, se forem usados para outros fins, não poderão ser rastreados para um determinado usuário ou administrador. A menos que tenham
acesso a chaves de descriptografia, as contas de serviço não ameaçam os dados criptografados. Isso pode ser especialmente importante para
dados mantidos em servidores que armazenam documentos legais, informações médicas, segredos comerciais ou planejamento executivo
confidencial.
Restrinja o uso de contas de serviço a tarefas ou comandos específicos em sistemas específicos e exija documentação e aprovação para distribuir
as credenciais. Considere atribuir uma nova senha toda vez que ocorrer uma distribuição, usando processos como os implementados para contas
de superusuário.
1.3.13.4.2 Contas Compartilhadas
As contas compartilhadas são criadas quando um aplicativo não consegue lidar com o número de contas de usuário necessárias ou quando a
adição de usuários específicos exige um grande esforço ou incorre em custos de licenciamento adicionais. Para contas compartilhadas, as
credenciais são fornecidas a vários usuários e a senha raramente é alterada devido ao esforço de notificar todos os usuários. Como eles fornecem
acesso essencialmente não governado, qualquer uso de contas compartilhadas deve ser cuidadosamente avaliado. Eles nunca devem ser usados
por padrão.
1.3.13.5 Ataques de intrusão de plataforma
As atualizações de software e a proteção contra intrusões de ativos de banco de dados requerem uma combinação de atualizações regulares de
software (patches) e a implementação de um sistema de prevenção de intrusões (IPS) dedicado. Um IPS é geralmente, mas nem sempre,
implementado juntamente com um Sistema de Detecção de Intrusão (IDS). O objetivo é evitar a grande maioria das tentativas de intrusão na rede
e responder rapidamente a qualquer intrusão que tenha conseguido passar por um sistema de prevenção. A forma mais primitiva de proteção
contra intrusões é um firewall, mas com usuários móveis, acesso à web e equipamentos de computação móvel como parte da maioria dos
ambientes corporativos, um firewall simples, embora ainda necessário, não é mais suficiente.
As atualizações fornecidas pelo fornecedor reduzem as vulnerabilidades encontradas nas plataformas de banco de dados ao longo do tempo.
Infelizmente, as atualizações de software geralmente são implementadas pelas empresas de acordo com ciclos de manutenção periódicos, e não
o mais rápido possível após a disponibilização dos patches. Entre os ciclos de atualização, os bancos de dados não são protegidos. Além disso,
problemas de compatibilidade às vezes impedem totalmente as atualizações de software. Para resolver esses problemas, implemente
IPS.
1.3.13.6 Vulnerabilidade de injeção de SQL
Em um ataque de injeção de SQL, um criminoso insere (ou 'injeta') instruções de banco de dados não autorizadas em um canal de dados SQL
vulnerável, como procedimentos armazenados e espaços de entrada de aplicativos da Web. Essas instruções SQL injetadas são passadas para
o banco de dados, onde geralmente são executadas como comandos legítimos. Usando injeção de SQL, os invasores podem obter acesso
irrestrito a um banco de dados inteiro.
As injeções SQL também são usadas para atacar o SGBD, passando comandos SQL como parâmetro de uma função ou procedimento
armazenado. Por exemplo, um componente que fornece funcionalidade de backup geralmente é executado com alto privilégio; chamar uma
função vulnerável de injeção de SQL nesse componente específico pode permitir que um usuário comum aumente seus privilégios, torne-se um
DBA e assuma o banco de dados.
Reduza esse risco higienizando todas as entradas antes de passá-las de volta ao servidor.
1.3.13.7 Senhas padrão
É uma prática antiga na indústria de software criar contas padrão durante a instalação de pacotes de software. Alguns são usados na própria
instalação. Outros fornecem aos usuários um meio de testar o

software fora da caixa.
As senhas padrão fazem parte de muitos pacotes de demonstração. A instalação de software de terceiros cria outros. Por exemplo, um pacote de
CRM pode criar várias contas no banco de dados de back-end, para instalação, teste e administração e para usuários regulares. O SAP cria vários
usuários de banco de dados padrão no momento da instalação. A indústria de SGBD também se engaja nessa prática.
Os invasores estão constantemente procurando uma maneira fácil de roubar dados confidenciais. Reduza as ameaças a dados confidenciais
criando as combinações necessárias de nome de usuário e senha e garantindo que nenhuma senha padrão seja deixada no DBMS. A eliminação
das senhas padrão é uma importante etapa de segurança após cada implementação.
1.3.13.8 Abuso de dados de backup
Os backups são feitos para reduzir os riscos associados à perda de dados, mas os backups também representam um risco de segurança. A
notícia oferece muitas histórias sobre mídia de backup perdida. Criptografe todos os backups de banco de dados. A criptografia evita a perda de
um backup em mídia tangível ou em trânsito eletrônico. Gerencie com segurança as chaves de descriptografia de backup. As chaves devem estar
disponíveis fora do local para serem úteis na recuperação de desastres.
1.3.14 Hacking / Hacker
O termo hacking veio de uma época em que o objetivo era encontrar maneiras inteligentes de realizar alguma tarefa no computador. Um hacker é
uma pessoa que encontra operações e caminhos desconhecidos em sistemas de computador complexos. Hackers podem ser bons ou ruins.
242 • DMBOK2
Um hacker ético ou 'White Hat' trabalha para melhorar um sistema. ('White Hat' refere-se a filmes de faroeste americanos em que o
herói sempre usava um chapéu branco.) Sem hackers éticos, as vulnerabilidades do sistema que poderiam ser corrigidas seriam
descobertas apenas por acidente. A correção sistemática (atualização) de computadores para aumentar a segurança resulta de
hackers éticos.
Um hacker malicioso é alguém que intencionalmente viola ou 'hackeia' um sistema de computador para roubar informações
confidenciais ou causar danos. Hackers maliciosos geralmente procuram informações financeiras ou pessoais para roubar dinheiro
ou identidades. Eles tentam adivinhar senhas simples e procuram encontrar pontos fracos e backdoors não documentados em
sistemas existentes. Eles às vezes são chamados de 'hackers de chapéu preto'.
(Nos mesmos westerns americanos em que os heróis usavam chapéus brancos, os vilões usavam chapéus pretos.)
1.3.15 Ameaças Sociais à Segurança / Phishing
As ameaças sociais à segurança geralmente envolvem comunicações diretas (pessoalmente, por telefone ou pela Internet)
destinadas a induzir as pessoas que têm acesso a dados protegidos a fornecer essas informações (ou acesso às informações) a
pessoas que as usarão para fins criminosos. ou fins maliciosos.
A engenharia social refere-se a como hackers maliciosos tentam enganar as pessoas para que lhes forneçam informações ou
acesso. Os hackers usam qualquer informação que obtêm para convencer outros funcionários de que têm solicitações legítimas.
Às vezes, os hackers entrarão em contato com várias pessoas em sequência, coletando informações úteis em cada etapa para
ganhar a confiança do próximo funcionário superior.
Phishing refere-se a um telefonema, mensagem instantânea ou e-mail destinado a atrair os destinatários para fornecer informações
valiosas ou privadas sem perceber que estão fazendo isso. Muitas vezes, essas chamadas ou mensagens parecem ser de uma
fonte legítima. Por exemplo, às vezes eles são enquadrados como argumentos de vendas para descontos ou taxas de juros
reduzidas. Mas eles pedem informações pessoais, como nomes, senhas, números de seguro social ou informações de cartão de
crédito. Para reduzir a suspeita, essas mensagens geralmente solicitam que o destinatário 'atualize' ou 'confirme' as informações.
Mensagens instantâneas e e-mails de phishing também podem direcionar os usuários a sites falsos para induzi-los a fornecer
informações pessoais. De perigo especial são os e-mails falsos especificamente direcionados a executivos seniores pelo nome. Isso
é chamado de 'Spear-phishing para baleias'. Além de telefonar e falsificar, sabe-se que os hackers vão fisicamente a sites de destino
e falam diretamente com funcionários, às vezes usando disfarces ou se passando por fornecedores, para obter acesso a informações
confidenciais.43
1.3.16 Malware
Malware refere-se a qualquer software malicioso criado para danificar, alterar ou acessar indevidamente um computador ou rede.
Vírus de computador, worms, spyware, keyloggers e adware são exemplos de malware. Qualquer software instalado sem autorização
pode ser considerado malware, se por nenhum outro motivo que ocupe
43 O relatório do FBI sobre hackers russos durante as eleições presidenciais dos EUA em 2016 descreve como essas técnicas foram
usadas nesse caso. http://bit.ly/2iKStXO.
espaço em disco e possivelmente ciclos de processamento que o proprietário do sistema não autorizou. O malware pode assumir muitas
formas, dependendo de sua finalidade (replicação, destruição, roubo de informações ou processamento ou monitoramento de
comportamento).
1.3.16.1 Adware
Adware é uma forma de spyware que entra em um computador a partir de um download da Internet. O adware monitora o uso de um
computador, como quais sites são visitados. O adware também pode inserir objetos e barras de ferramentas no navegador do usuário.
O adware não é ilegal, mas é usado para desenvolver perfis completos de navegação e hábitos de compra do usuário para vender a
outras empresas de marketing. Também pode ser facilmente aproveitado por software malicioso para roubo de identidade.
1.3.16.2 Spyware
Spyware refere-se a qualquer programa de software que entra em um computador sem consentimento, a fim de rastrear a atividade
online. Esses programas tendem a pegar carona em outros programas de software. Quando um usuário baixa e instala software gratuito
de um site na Internet, o spyware também pode ser instalado, geralmente sem o conhecimento do usuário.
Diferentes formas de spyware rastreiam diferentes tipos de atividade. Alguns programas monitoram quais sites são visitados, enquanto
outros gravam as teclas digitadas pelo usuário para roubar informações pessoais, como números de cartão de crédito, informações de
contas bancárias e senhas.
Muitos sites legítimos, incluindo mecanismos de pesquisa, instalam spyware de rastreamento, que é uma forma de Adware.
1.3.16.3 Cavalo de Tróia
O cavalo de Tróia era uma grande 'estátua de presente' de madeira de um cavalo que os gregos deram ao povo de Tróia, que rapidamente
o trouxe para dentro das muralhas da cidade. Infelizmente para eles, escondeu soldados gregos, que, uma vez dentro de Tróia, escaparam
e atacaram a cidade.
Em termos de segurança informática, um cavalo de Tróia refere-se a um programa malicioso que entra num sistema informático disfarçado
ou incorporado em software legítimo. Uma vez instalado, um cavalo de Tróia excluirá arquivos, acessará informações pessoais, instalará
malware, reconfigurará o computador, instalará um keylogger ou até permitirá que hackers usem o computador como arma (Bot ou
Zombie) contra outros computadores em uma rede.
1.3.16.4 Vírus
Um vírus é um programa que se anexa a um arquivo executável ou aplicativo vulnerável e fornece uma carga útil que varia de irritante a
extremamente destrutiva. Um vírus de arquivo é executado quando um arquivo infectado é aberto. Um vírus sempre precisa acompanhar
outro programa. A abertura de programas baixados e infectados pode liberar um vírus.

244 • DMBOK2
1.3.16.5 Minhoca
Um worm de computador é um programa criado para se reproduzir e se espalhar por uma rede por si só. Um computador infectado por worms enviará
um fluxo contínuo de mensagens infectadas. Um worm pode executar várias atividades maliciosas diferentes, embora a função principal seja prejudicar
as redes consumindo grandes quantidades de largura de banda, potencialmente desligando a rede.
1.3.16.6 Fontes de malware
1.3.16.6.1 Mensagens Instantâneas (IM)
O IM permite que os usuários retransmitam mensagens entre si em tempo real. As mensagens instantâneas também estão se tornando uma nova
ameaça à segurança da rede. Como muitos sistemas de mensagens instantâneas demoram a adicionar recursos de segurança, os hackers mal-
intencionados descobriram que as mensagens instantâneas são um meio útil de espalhar vírus, spyware, golpes de phishing e uma grande variedade
de worms. Normalmente, essas ameaças se infiltram nos sistemas por meio de anexos e mensagens contaminados.
1.3.16.6.2 Sites de Redes Sociais
Sites de redes sociais, como Facebook, Twitter, Vimeo, Google+, LinkedIn, Xanga, Instagram, Pinterest ou MySpace, onde os usuários constroem perfis
online e compartilham informações pessoais, opiniões, fotografias, entradas de blogs e outras informações, tornaram-se alvos de predadores online,
spammers e ladrões de identidade.
Além de representar uma ameaça de pessoas mal-intencionadas, esses sites apresentam riscos de funcionários que podem postar informações
confidenciais da empresa ou conhecimento 'privilegiado' que podem afetar o preço das ações de uma organização pública. Informe os usuários sobre
os perigos e a realidade de que tudo o que eles postarem se tornará permanente na Internet. Mesmo que removam os dados posteriormente, muitos
terão feito cópias. Algumas empresas bloqueiam esses

sites em seu firewall.
1.3.16.6.3 Spam
Spam refere-se a mensagens de e-mail comerciais não solicitadas enviadas em massa, geralmente para dezenas de milhões de usuários na esperança
de que alguns possam responder. Uma taxa de retorno de 1% pode render milhões de dólares. A maioria dos sistemas de roteamento de e-mail tem
armadilhas para filtrar padrões conhecidos de mensagens de spam para reduzir o tráfego interno. Esses padrões de exclusão incluem:
• Domínios conhecidos pela transmissão de spam

• CC: ou BCC: contagem de endereços acima de certos limites
• O corpo do e-mail tem apenas uma imagem como hiperlink
• Cadeias de texto ou palavras específicas

Responder a uma mensagem de spam confirmará ao remetente que ele alcançou um endereço de e-mail legítimo e aumentará o
spam futuro, pois listas de e-mails válidos podem ser vendidas a outros remetentes de spam.
As mensagens de spam também podem ser hoaxes da Internet ou incluir anexos de malware, com nomes e extensões de anexo,
texto de mensagem e imagens dando a aparência de uma comunicação legítima. Uma maneira de detectar e-mails de spam é
passar o ponteiro sobre qualquer hiperlink, que mostrará o link real que não tem nada em comum com a empresa mostrada no
texto. Outra maneira é a falta de uma maneira de cancelar a inscrição. Nos EUA, os e-mails de publicidade são obrigados a listar
um link de cancelamento de assinatura para interromper outros e-mails.
2. Atividades
Não há uma maneira prescrita de implementar a segurança de dados para atender a todos os requisitos necessários de privacidade
e confidencialidade. Os regulamentos se concentram nos fins da segurança, não nos meios para alcançá-la. As organizações
devem projetar seus próprios controles de segurança, demonstrar que os controles atendem ou excedem os requisitos das leis ou
regulamentos, documentar a implementação desses controles e monitorá-los e medi-los ao longo do tempo. Como em outras Áreas
de Conhecimento, as atividades incluem a identificação de requisitos, avaliação do ambiente atual quanto a lacunas ou riscos,
implementação de ferramentas e processos de segurança e auditoria de medidas de segurança de dados para garantir que sejam
eficaz.
2.1 Identificar os requisitos de segurança de dados
É importante distinguir entre requisitos de negócios, restrições regulatórias externas e as regras impostas por produtos de software
aplicativo. Embora os sistemas de aplicativos sirvam como veículos para impor regras e procedimentos de negócios, é comum que
esses sistemas tenham seus próprios requisitos de segurança de dados além daqueles exigidos para processos de negócios.
Esses requisitos estão se tornando mais comuns com sistemas empacotados e prontos para uso. É necessário, no entanto, ver
que eles suportam os padrões de segurança de dados organizacionais como
Nós vamos.
2.1.1 Requisitos de Negócios
A implementação da segurança de dados em uma empresa começa com uma compreensão completa dos requisitos de negócios.
As necessidades de negócios de uma empresa, sua missão, estratégia e tamanho, e o setor ao qual ela pertence definem o grau
de rigidez necessário para a segurança dos dados. Por exemplo, as empresas financeiras e de valores mobiliários nos Estados
Unidos são altamente regulamentadas e obrigadas a manter padrões rigorosos de segurança de dados. Por outro lado, uma
empresa de varejo de pequena escala pode optar por não ter o mesmo tipo de função de segurança de dados que um grande
varejista, mesmo que ambos tenham atividades comerciais principais semelhantes.
246 • DMBOK2
Analise regras e processos de negócios para identificar pontos de contato de segurança. Cada evento no fluxo de trabalho de negócios
pode ter seus próprios requisitos de segurança. Matrizes de relacionamento de dados para processo e dados para função são ferramentas
úteis para mapear essas necessidades e orientar a definição de grupos de funções de segurança de dados, parâmetros e permissões.
Planeje abordar metas de curto e longo prazo para alcançar uma função de segurança de dados equilibrada e eficaz.
2.1.2 Requisitos Regulamentares
O ambiente global e em rápida mudança de hoje exige que as organizações cumpram um conjunto crescente de leis e regulamentos. As
questões éticas e legais que as organizações enfrentam na Era da Informação estão levando os governos a estabelecer novas leis e
padrões. Todos eles impuseram controles de segurança rígidos no gerenciamento de informações.
Crie um inventário central de todos os regulamentos de dados relevantes e a área de assunto de dados afetada por cada regulamento.
Adicione links para as políticas de segurança correspondentes desenvolvidas para conformidade com esses regulamentos (consulte a
Tabela 13) e os controles implementados. Regulamentos, políticas, ações necessárias e dados afetados mudarão ao longo do tempo,
portanto, esse inventário deve estar em um formato simples de gerenciar e manter.
Tabela 13 Tabela de Inventário de Regulamentação de Amostra
Regulamento Área de Assunto Afetada Política de Segurança Links Controles Implementados
Exemplos de leis que influenciam a segurança de dados incluem:
• NÓS
o Lei Sarbanes-Oxley de 2002
o Lei de Tecnologia da Informação em Saúde para Saúde Econômica e Clínica (HITECH), promulgada como
parte da Lei Americana de Recuperação e Reinvestimento de 2009
o Lei de Portabilidade e Responsabilidade do Seguro Saúde de 1996 (HIPAA) Regulamentos de Segurança
o Gramm-Leach-Bliley I e II
o Leis da SEC e Lei de Responsabilidade de Segurança da Informação Corporativa
o Homeland Security Act e USA Patriot Act
o Lei Federal de Gerenciamento de Segurança da Informação (FISMA)
o Califórnia: SB 1386, Lei de Informações sobre Violação de Segurança da Califórnia

• UE
o Diretiva de Proteção de Dados (UE DPD 95/46/) AB 1901, Roubo de arquivos eletrônicos ou bancos de dados
• Canadá
o Projeto de lei canadense 198
• Austrália
o A Lei CLERP da Austrália
Os regulamentos que afetam a segurança de dados incluem:

• Padrão de Segurança de Dados da Indústria de Cartões de Pagamento (PCI DSS), na forma de um acordo contratual para
todas as empresas que trabalham com cartões de crédito
• UE: O Acordo de Basileia II, que impõe controles de informações para todas as instituições financeiras que
negócios em seus países relacionados
• EUA: Padrões FTC para Salvaguardar as Informações do Cliente
A conformidade com as políticas da empresa ou restrições regulatórias geralmente exigirá ajustes nos processos de negócios. Por exemplo, a
necessidade de autorizar o acesso a informações de saúde (elementos de dados regulamentados) a vários grupos exclusivos de usuários, a
fim de acomodar a HIPAA.
2.2 Definir a Política de Segurança de Dados
As organizações devem criar políticas de segurança de dados com base nos requisitos de negócios e regulatórios. Uma política é uma
declaração de um curso de ação selecionado e uma descrição de alto nível do comportamento desejado para atingir um conjunto de metas.
As políticas de segurança de dados descrevem comportamentos determinados como sendo do melhor interesse de uma organização que
deseja proteger seus dados. Para que as políticas tenham um impacto mensurável, elas devem ser auditáveis e auditadas.
As políticas corporativas geralmente têm implicações legais. Um tribunal pode considerar uma política instituída para apoiar um requisito
regulamentar legal como parte intrínseca do esforço da organização para cumprir esse requisito legal.
O não cumprimento de uma política corporativa pode ter ramificações legais negativas após uma violação de dados.
Definir a política de segurança requer colaboração entre administradores de segurança de TI, arquitetos de segurança, comitês de governança
de dados, administradores de dados, equipes de auditoria interna e externa e o departamento jurídico. Os Administradores de Dados também
devem colaborar com todos os Diretores de Privacidade (supervisores da Sarbanes-Oxley, Diretores da HIPAA etc.) e gerentes de negócios
com experiência em dados para desenvolver Metadados de categoria regulatória e aplicar classificações de segurança adequadas de forma
consistente. Todas as ações de conformidade com a regulamentação de dados devem ser coordenadas para reduzir custos, confusão de
instruções de trabalho e batalhas desnecessárias.
2.2.1 Conteúdo da Política de Segurança
Diferentes níveis de política são necessários para controlar o comportamento relacionado à segurança corporativa. Por exemplo:
• Política de segurança corporativa: políticas globais para acesso de funcionários a instalações e outros ativos, e-mail
padrões e políticas, níveis de acesso de segurança com base na posição ou título e relatórios de violação de segurança
políticas
• Política de segurança de TI: padrões de estruturas de diretório, políticas de senha e gerenciamento de identidade
estrutura
• Política de segurança de dados: categorias para aplicativos individuais, funções de banco de dados, grupos de usuários e
sensibilidade da informação
248 • DMBOK2
Comumente, a Política de Segurança de TI e a Política de Segurança de Dados fazem parte de uma política de segurança combinada. A
preferência, no entanto, deve ser separá-los. As políticas de segurança de dados são de natureza mais granular, específicas para o conteúdo
e exigem controles e procedimentos diferentes. O Conselho de Governança de Dados deve revisar e aprovar a Política de Segurança de
Dados. O Executivo de Gerenciamento de Dados possui e mantém a política.
Os funcionários precisam entender e seguir as políticas de segurança. Desenvolva políticas de segurança para que os processos necessários
e as razões por trás deles sejam claramente definidos e alcançáveis. A conformidade deve ser mais fácil do que a não conformidade. As
políticas precisam proteger e proteger os dados sem sufocar o acesso do usuário.
As políticas de segurança devem estar em um formato facilmente acessível pelos fornecedores, consumidores e outras partes interessadas.
Eles devem estar disponíveis e mantidos na intranet da empresa ou em um portal de colaboração similar.
As políticas, procedimentos e atividades de segurança de dados devem ser reavaliados periodicamente para alcançar o melhor equilíbrio
possível entre os requisitos de segurança de dados de todas as partes interessadas.
2.3 Definir padrões de segurança de dados
As políticas fornecem diretrizes para o comportamento. Eles não descrevem todas as contingências possíveis. As normas complementam
as políticas e fornecem detalhes adicionais sobre como atender à intenção das políticas. Por exemplo, uma política pode declarar que as
senhas devem seguir as diretrizes para senhas fortes; os padrões para senhas fortes seriam detalhados separadamente; e a política seria
aplicada por meio de tecnologia que impede a criação de senhas se elas não atenderem aos padrões para senhas fortes.
2.3.1 Definir os níveis de confidencialidade dos dados
A classificação de confidencialidade é uma característica importante de Metadados, orientando como os usuários recebem privilégios de
acesso. Cada organização deve criar ou adotar um esquema de classificação que atenda aos seus requisitos de negócios. Qualquer método
de classificação deve ser claro e fácil de aplicar. Ele conterá uma variedade de níveis, do menos ao mais confidencial (por exemplo, de
“para uso geral” a “confidencial registrado”). (Consulte a Seção 1.3.12.1.)
2.3.2 Definir Categorias Regulatórias de Dados
Um número crescente de violações de dados altamente divulgadas, nas quais informações pessoais confidenciais foram comprometidas,
resultou na introdução de leis específicas de dados. Incidentes de dados com foco financeiro estimularam governos em todo o mundo a
implementar regulamentações adicionais.
Isso criou uma nova classe de dados, que pode ser chamada de 'Informações Regulamentadas'. Os requisitos regulamentares são uma
extensão da segurança da informação. São necessárias medidas adicionais para gerir eficazmente os requisitos regulamentares. A consulta
com o conselho corporativo geralmente é útil para determinar quais ações certas regulamentações
exigir da empresa. Muitas vezes as regulamentações implicam um objetivo, e cabe à corporação determinar os meios para atingir esse
objetivo de proteção da informação. As ações que podem ser auditadas fornecem prova legal de conformidade.
Uma maneira útil de lidar com os regulamentos específicos de dados é analisar e agrupar regulamentos semelhantes em categorias, como
foi feito ao agrupar vários riscos em algumas classificações de segurança.
Com mais de uma centena de portarias específicas de dados diferentes em todo o mundo, seria inútil desenvolver uma categoria diferente
para cada regulamentação. A maioria das regulamentações de dados, impostas como são por entidades legais separadas, buscam fazer a
mesma coisa. Por exemplo, as obrigações contratuais de proteção de dados confidenciais de clientes são notavelmente semelhantes às
regulamentações governamentais dos EUA, Japão e Canadá para proteção de Informações de Identificação Pessoal e semelhantes para
conformidade com os requisitos de privacidade da UE. Esse padrão é fácil de ver quando as ações de conformidade auditáveis para cada
regulamento são listadas e comparadas. Assim, todos eles podem ser gerenciados adequadamente usando a mesma categoria de ação de
proteção.
Um princípio fundamental tanto para a classificação de segurança quanto para a categorização regulatória é que a maioria das informações
pode ser agregada para que tenha maior ou menor sensibilidade. Os desenvolvedores precisam saber como as agregações afetam a
classificação geral de segurança e as categorias regulatórias. Quando um desenvolvedor de um painel, relatório ou exibição de banco de
dados sabe que alguns dos dados necessários podem ser pessoais ou internos ou relacionados à vantagem competitiva, o sistema pode
ser projetado para eliminar aspectos disso do direito ou, se os dados devem permanecer no direito do usuário, para fazer cumprir todos os
requisitos de segurança e regulamentares no momento do usuário

autorização.
Os resultados deste trabalho de classificação serão um conjunto formalmente aprovado de classificações de segurança e categorias
regulatórias e um processo para capturar esses Metadados em um repositório central para que os funcionários, tanto de negócios quanto
técnicos, conheçam a sensibilidade se as informações que estão manipulando, transmitindo, e autorizando
2.3.3 Definir funções de segurança
O controle de acesso aos dados pode ser organizado em nível individual ou de grupo, dependendo da necessidade. Dito isso, conceder
privilégios de acesso e atualização a contas de usuários individuais envolve um grande esforço redundante. Organizações menores podem
achar aceitável gerenciar o acesso a dados no nível individual. No entanto, organizações maiores se beneficiarão muito do controle de
acesso baseado em função, concedendo permissões a grupos de função e, portanto, a cada membro do grupo.
Os grupos de função permitem que os administradores de segurança definam privilégios por função e concedam esses privilégios ao
inscrever usuários no grupo de função apropriado. Embora seja tecnicamente possível inscrever um usuário em mais de um grupo, essa
prática pode dificultar a compreensão dos privilégios concedidos a um usuário específico. Sempre que possível, tente atribuir cada usuário
a apenas um grupo de funções. Isso pode exigir a criação de diferentes visualizações de usuário de determinados direitos de dados para
cumprir os regulamentos.
A consistência de dados no gerenciamento de usuários e funções é um desafio. As informações do usuário, como nome, cargo e ID do
funcionário, devem ser armazenadas de forma redundante em vários locais. Essas ilhas de dados geralmente entram em conflito, representando
250 • DMBOK2
múltiplas versões da 'verdade'. Para evitar problemas de integridade de dados, gerencie os dados de identidade do usuário e a associação ao grupo de
funções de forma centralizada. Este é um requisito para a qualidade dos dados usados para controle de acesso eficaz. Os administradores de segurança
criam, modificam e excluem contas de usuários e grupos de funções. As alterações feitas na taxonomia e na associação do grupo devem receber a
aprovação apropriada. As mudanças devem ser rastreadas por meio de um gerenciamento de mudanças
sistema.
A aplicação de medidas de segurança de dados de forma inconsistente ou inadequada dentro de uma organização pode levar à insatisfação dos
funcionários e a um risco significativo para a organização. A segurança baseada em função depende de funções claramente definidas e atribuídas de
forma consistente.
Existem duas maneiras de definir e organizar funções: como uma grade (a partir dos dados) ou em uma hierarquia (a partir do usuário).
2.3.3.1 Grade de Atribuição de Funções
Uma grade pode ser útil para mapear funções de acesso para dados, com base na confidencialidade dos dados, regulamentos e funções do usuário. A
função de usuário público pode ter acesso a todos os dados classificados para o público geral e não está sujeito a nenhuma regulamentação. Uma função
de Marketing pode ter acesso a algumas informações de PII para uso no desenvolvimento de campanhas, mas não a quaisquer dados restritos ou dados
confidenciais do cliente. A Tabela 14 mostra um exemplo muito simplificado.
Tabela 14 Exemplo de grade de atribuição de função
Nível de confidencialidade
Audiência Geral Confidencial do cliente Confidencial restrito
Não regulamentado Função de usuário público Função de gerente de clientes Função de acesso restrito
PII Função de marketing Função de marketing do cliente Função de RH
PCI Função Financeira Função Financeira do Cliente Função financeira restrita
2.3.3.2 Hierarquia de Atribuição de Funções
Construir definições de grupo no nível de grupo de trabalho ou unidade de negócios. Organize essas funções em uma hierarquia, para que as funções
filhas restrinjam ainda mais os privilégios das funções pai. A manutenção contínua dessas hierarquias é uma operação complexa que requer sistemas de
relatórios capazes de detalhar granularmente os privilégios de usuários individuais. Um exemplo de hierarquia de função de segurança é mostrado na
Figura 65.
2.3.4 Avaliar os riscos de segurança atuais
Os riscos de segurança incluem elementos que podem comprometer uma rede e/ou banco de dados. A primeira etapa para identificar o risco é identificar
onde os dados confidenciais são armazenados e quais proteções são necessárias para esses dados. Avalie cada sistema para o seguinte:
• A sensibilidade dos dados armazenados ou em trânsito
• Os requisitos para proteger esses dados e
• As atuais proteções de segurança em vigor
Unidade de Trabalho A Unidade de Trabalho A
(CSR MGR) (A/R MGR)

* CRIO * CRIO
* LER * LER
* ATUALIZAR * ATUALIZAR
* APAGAR
Unidade de Trabalho A Unidade de Trabalho B Unidade de Trabalho C
(RSC) (A/R) (FINANÇA)

* CRIO * LER * LER
* LER * ATUALIZAR
* ATUALIZAR
Usuário A Usuário B Usuário C Usuário D
Figura 65 Diagrama de exemplo de hierarquia de função de segurança
Documente as descobertas, pois elas criam uma linha de base para avaliações futuras. Essa documentação também pode ser um requisito
para conformidade com a privacidade, como na União Europeia. As lacunas devem ser corrigidas por meio de processos de segurança
aprimorados suportados pela tecnologia. O impacto das melhorias deve ser medido e monitorado para garantir que os riscos sejam mitigados.
Em organizações maiores, hackers de chapéu branco podem ser contratados para avaliar vulnerabilidades. Um exercício de chapéu branco
pode ser usado como prova da impenetrabilidade de uma organização, que pode ser usada em publicidade para reputação no mercado.
2.3.5 Implementar Controles e Procedimentos
A implementação e administração da política de segurança de dados é principalmente de responsabilidade dos administradores de segurança,
em coordenação com os administradores de dados e equipes técnicas. Por exemplo, a segurança do banco de dados geralmente é uma
responsabilidade do DBA.
As organizações devem implementar controles adequados para atender aos requisitos da política de segurança. Os controles e procedimentos
devem (no mínimo) cobrir:
• Como os usuários ganham e perdem acesso a sistemas e/ou aplicativos
• Como os usuários são atribuídos e removidos das funções
• Como os níveis de privilégio são monitorados
• Como as solicitações de alterações de acesso são tratadas e monitoradas
• Como os dados são classificados de acordo com a confidencialidade e os regulamentos aplicáveis

• Como as violações de dados são tratadas uma vez detectadas
252 • DMBOK2
Documente os requisitos para permitir autorizações de usuário originais para que a desautorização possa ocorrer quando essas condições não se
aplicarem mais.
Por exemplo, uma política para 'manter privilégios de usuário apropriados' pode ter um objetivo de controle de 'Revisar direitos e privilégios do DBA
e do usuário mensalmente'. O procedimento da organização para satisfazer este controle pode ser implementar e manter processos para:
• Valide as permissões atribuídas em um sistema de gerenciamento de alterações usado para rastrear todos os usuários
solicitações de permissão
• Exigir um processo de aprovação de fluxo de trabalho ou formulário em papel assinado para registrar e documentar cada alteração
solicitar
• Incluir um procedimento para eliminar autorizações para pessoas cujo status de trabalho ou departamento não mais
qualifica-os a ter certos direitos de acesso
Algum nível de gerenciamento deve solicitar, rastrear e aprovar formalmente todas as autorizações iniciais e alterações subsequentes nas
autorizações de usuários e grupos
2.3.5.1 Atribuir Níveis de Confidencialidade
Os Administradores de Dados são responsáveis por avaliar e determinar o nível de confidencialidade apropriado para os dados com base no
esquema de classificação da organização.
A classificação de documentos e relatórios deve ser baseada no mais alto nível de confidencialidade para qualquer informação encontrada no
documento. (Consulte o Capítulo 9.) Rotule cada página ou tela com a classificação no cabeçalho ou rodapé. Os produtos de informação
classificados como menos confidenciais (por exemplo, “Para o público geral”) não precisam de rótulos. Suponha que quaisquer produtos não
rotulados sejam para o público geral.
Os autores de documentos e designers de produtos de informação são responsáveis por avaliar, classificar corretamente e rotular o nível de
confidencialidade apropriado para cada documento, bem como para cada banco de dados, incluindo tabelas relacionais, colunas e visualizações de
direitos de usuário.
Em organizações maiores, grande parte da classificação de segurança e do esforço de proteção será de responsabilidade de uma organização
dedicada à segurança da informação. Embora a Segurança da Informação fique feliz em ter os Administradores de Dados trabalhando com essas
classificações, eles geralmente assumem a responsabilidade pela fiscalização e pela proteção física da rede.
2.3.5.2 Atribuir Categorias Regulamentares
As organizações devem criar ou adotar uma abordagem de classificação para garantir que possam atender às demandas de conformidade
regulatória. (Consulte a Seção 3.3.) Este esquema de classificação fornece uma base para responder a auditorias internas e externas. Uma vez que
esteja no lugar, as informações precisam ser avaliadas e classificadas dentro do esquema. A equipe de segurança pode não estar familiarizada com
esse conceito, pois não trabalha com dados individuais

regulamentos, mas com sistemas de infra-estrutura. Eles precisarão ter requisitos documentados para proteção de dados relacionados a essas categorias,
definindo as ações que podem implementar.
2.3.5.3 Gerenciar e manter a segurança dos dados
Uma vez que todos os requisitos, políticas e procedimentos estejam em vigor, a principal tarefa é garantir que não ocorram violações de segurança e, se
ocorrerem, detectá-las o mais rápido possível. O monitoramento contínuo dos sistemas e a auditoria da execução dos procedimentos de segurança são
cruciais para preservar a segurança dos dados.
2.3.5.3.1 Disponibilidade de dados de controle/segurança centrada em dados
O controle da disponibilidade de dados requer o gerenciamento dos direitos do usuário e das estruturas (mascaramento de dados, criação de visualizações,
etc.) que controlam tecnicamente o acesso com base nos direitos. Alguns bancos de dados são melhores que outros no fornecimento de estruturas e
processos para proteger os dados armazenados. (Consulte a Seção 3.7.)
Os gerentes de conformidade de segurança podem ter a responsabilidade direta de projetar perfis de direitos de usuário que permitem que os negócios
funcionem sem problemas, ao mesmo tempo em que seguem as restrições relevantes.
Definir direitos e conceder autorizações requer um inventário de dados, análise cuidadosa das necessidades de dados e documentação dos dados expostos
em cada direito de usuário. Muitas vezes, informações altamente confidenciais são misturadas com informações não confidenciais. Um modelo de dados
corporativos é essencial para identificar e localizar dados confidenciais.
(Consulte a Seção 1.1.1.)
O mascaramento de dados pode proteger os dados mesmo que sejam expostos inadvertidamente. Certos regulamentos de dados exigem criptografia, uma
versão extrema do mascaramento no local. A autorização para as chaves de descriptografia pode fazer parte do processo de autorização do usuário. Os
usuários autorizados a acessar as chaves de descriptografia podem ver os dados não criptografados, enquanto outros apenas veem
caracteres aleatórios.
As exibições de banco de dados relacional podem ser usadas para impor níveis de segurança de dados. As exibições podem restringir o acesso a determinadas
linhas com base em valores de dados ou restringir o acesso a determinadas colunas, limitando o acesso a campos confidenciais ou regulamentados.
2.3.5.3.2 Monitorar Autenticação do Usuário e Comportamento de Acesso
O relatório sobre o acesso é um requisito básico para auditorias de conformidade. O monitoramento de autenticação e comportamento de acesso fornece
informações sobre quem está conectando e acessando ativos de informações. O monitoramento também ajuda a detectar transações incomuns, imprevistas
ou suspeitas que exigem investigação. Dessa forma, ele compensa as lacunas no planejamento, design e implementação de segurança de dados.
Decidir o que precisa de monitoramento, por quanto tempo e quais ações tomar no caso de um alerta requer uma análise cuidadosa orientada por requisitos
de negócios e regulatórios. O monitoramento envolve uma ampla gama de atividades. Pode ser específico para determinados conjuntos de dados, usuários
ou funções. Ele pode ser usado para validar a integridade dos dados, configurações ou
254 • DMBOK2
Metadados. Pode ser implementado dentro de um sistema ou através de sistemas heterogêneos dependentes. Ele pode se concentrar em privilégios específicos, como
a capacidade de baixar grandes conjuntos de dados ou acessar dados fora do horário comercial.
O monitoramento pode ser automatizado ou executado manualmente ou executado por meio de uma combinação de automação e supervisão. O monitoramento
automatizado impõe sobrecarga nos sistemas subjacentes e pode afetar o desempenho do sistema. Instantâneos periódicos de atividade podem ser úteis para entender
tendências e comparar com critérios padrões. Mudanças de configuração iterativas podem ser necessárias para atingir os parâmetros ideais para o monitoramento
adequado.
A gravação automatizada de transações de banco de dados confidenciais ou incomuns deve fazer parte de qualquer implantação de banco de dados.
A falta de monitoramento automatizado representa sérios riscos:
• Risco regulatório: Organizações com mecanismos de auditoria de banco de dados fracos descobrirão cada vez mais que
estão em desacordo com os requisitos regulamentares do governo. Sarbanes-Oxley (SOX) nos serviços financeiros
setor e o Healthcare Information Portability and Accountability Act (HIPAA) no setor de saúde
setor são apenas dois exemplos de regulamentação do governo dos EUA com requisitos claros de auditoria de banco de dados.
• Risco de detecção e recuperação: os mecanismos de auditoria representam a última linha de defesa. Se um atacante
contorna outras defesas, os dados de auditoria podem identificar a existência de uma violação após o fato. Dados de auditoria
também pode ser usado para vincular uma violação a um usuário específico ou como um guia para reparar o sistema.
• Risco de funções administrativas e de auditoria: Usuários com acesso administrativo ao servidor de banco de dados –
se esse acesso foi obtido de forma legítima ou maliciosa - pode desativar a auditoria para ocultar
atividade. Os deveres de auditoria devem, idealmente, ser separados dos administradores de banco de dados e do banco de dados
equipe de suporte da plataforma do servidor.
• Risco de dependência de ferramentas de auditoria nativas inadequadas: as plataformas de software de banco de dados geralmente tentam integrar
capacidades básicas de auditoria, mas muitas vezes sofrem de múltiplas fraquezas que limitam ou impedem
implantação. Quando os usuários acessam o banco de dados por meio de aplicativos Web (como SAP, Oracle E-Business
Suite ou PeopleSoft), os mecanismos de auditoria nativos não têm conhecimento de identidades de usuários específicos e todos
a atividade do usuário está associada ao nome da conta do aplicativo Web. Portanto, quando os logs de auditoria nativos
revelar transações fraudulentas de banco de dados, não há link para o usuário responsável.
Para mitigar os riscos, implemente um dispositivo de auditoria baseado em rede, que pode resolver a maioria dos pontos fracos associados às ferramentas de auditoria
nativas, mas que não realiza auditorias regulares por auditores treinados. Este tipo de aparelho tem as seguintes vantagens:
• Alto desempenho: os dispositivos de auditoria baseados em rede podem operar na velocidade da linha com pouco impacto
desempenho do banco de dados.
• Separação de funções: os dispositivos de auditoria baseados em rede devem operar independentemente do banco de dados
administradores, permitindo separar as funções de auditoria das funções administrativas, conforme apropriado.
• O rastreamento granular de transações oferece suporte à detecção avançada de fraudes, análise forense e recuperação. Histórico
incluir detalhes como nome do aplicativo de origem, texto de consulta completo, atributos de resposta de consulta,
SO, hora e nome de origem.
2.3.5.4 Gerenciar a conformidade da política de segurança
O gerenciamento da conformidade da política de segurança inclui atividades contínuas para garantir que as políticas sejam seguidas e os controles sejam
mantidos de forma eficaz. A gestão também inclui fornecer recomendações para atender a novos requisitos.
Em muitos casos, os Data Stewards atuarão em conjunto com a Segurança da Informação e o Conselho Corporativo para que as políticas operacionais e
os controles técnicos estejam alinhados.
2.3.5.4.1 Gerenciar Conformidade Regulatória
O gerenciamento da conformidade regulatória inclui:
• Medir a conformidade com os padrões e procedimentos de autorização
• Garantir que todos os requisitos de dados sejam mensuráveis e, portanto, auditáveis (ou seja, afirmações como “ser
cuidado” não são mensuráveis)
• Garantir que os dados regulamentados em armazenamento e em movimento sejam protegidos usando ferramentas e processos padrão
• Usando procedimentos de escalação e mecanismos de notificação quando possíveis problemas de não conformidade são
descoberto, e no caso de uma violação de conformidade regulatória
Os controles de conformidade exigem trilhas de auditoria. Por exemplo, se a política declarar que os usuários devem fazer o treinamento antes de acessar
determinados dados, a organização deve ser capaz de provar que um determinado usuário fez o treinamento. Sem uma trilha de auditoria, não há
evidência de conformidade. Os controles devem ser projetados para garantir que sejam auditáveis.
2.3.5.4.2 Auditoria de Segurança de Dados e Atividades de Conformidade
As auditorias internas das atividades para garantir que as políticas de segurança de dados e conformidade regulatória sejam seguidas devem ser
realizadas de forma regular e consistente. Os próprios controles de conformidade devem ser revistos quando novas regulamentações de dados forem
promulgadas, quando as regulamentações existentes forem alteradas e periodicamente para garantir a utilidade. Auditores internos ou externos podem
realizar auditorias. Em todos os casos, os auditores devem ser independentes dos dados e/ou processos envolvidos na auditoria para evitar qualquer
conflito de interesses e garantir a integridade da atividade de auditoria e

resultados.
A auditoria não é uma missão de busca de falhas. O objetivo da auditoria é fornecer à administração e ao conselho de governança de dados avaliações
objetivas e imparciais e recomendações racionais e práticas.
Declarações de política de segurança de dados, documentos de padrões, guias de implementação, solicitações de mudança, logs de monitoramento de
acesso, saídas de relatórios e outros registros (eletrônicos ou impressos) formam a entrada para uma auditoria. Além de examinar as evidências
existentes, as auditorias geralmente incluem a realização de testes e verificações, como:

256 • DMBOK2
• Analisar políticas e padrões para garantir que os controles de conformidade sejam definidos com clareza e cumpram
requisitos regulamentares
• Analisar os procedimentos de implementação e práticas de autorização do usuário para garantir a conformidade com
metas regulatórias, políticas, padrões e resultados desejados
• Avaliar se os padrões e procedimentos de autorização são adequados e alinhados com
requisitos de tecnologia
• Avaliar procedimentos de encaminhamento e mecanismos de notificação a serem executados quando possíveis problemas
de não conformidade forem descobertos ou em caso de violação de conformidade regulatória
• Revisão de contratos, acordos de compartilhamento de dados e obrigações de conformidade regulatória de terceirizados
e fornecedores externos, que garantem que os parceiros de negócios cumpram suas obrigações e que a organização
cumpre suas obrigações legais para proteger dados regulamentados
• Avaliar a maturidade das práticas de segurança dentro da organização e reportar à alta administração
gestão e outras partes interessadas sobre o 'Estado de Conformidade Regulamentar'
• Recomendar mudanças na política de conformidade regulatória e melhorias de conformidade operacional
A auditoria de segurança de dados não substitui o gerenciamento de segurança de dados. É um processo de apoio que avalia objetivamente
se a gestão está atingindo as metas.
3. Ferramentas
As ferramentas usadas para gerenciar a segurança da informação dependem, em grande parte, do tamanho da organização, da arquitetura
de rede e das políticas e padrões usados por uma organização de segurança.
3.1 Software antivírus/software de segurança
O software antivírus protege os computadores contra vírus encontrados na Web. Novos vírus e outros malwares aparecem todos os dias,
por isso é importante atualizar o software de segurança regularmente.
3.2 HTTPS
Se um endereço da Web começar com https://, isso indica que o site está equipado com uma camada de segurança criptografada.
Normalmente, os usuários devem fornecer uma senha ou outro meio de autenticação para acessar o site. Fazer pagamentos online ou
acessar informações classificadas usa essa proteção de criptografia. Treine os usuários para procurar isso no
Endereço de URL quando estão realizando operações confidenciais pela Internet ou até mesmo dentro da empresa.
Sem criptografia, as pessoas no mesmo segmento de rede podem ler as informações de texto simples.
3.3 Tecnologia de Gerenciamento de Identidade
A tecnologia de gerenciamento de identidade armazena credenciais atribuídas e as compartilha com sistemas mediante solicitação, como
quando um usuário faz login em um sistema. Alguns aplicativos gerenciam seu próprio repositório de credenciais, embora seja mais
conveniente para os usuários que a maioria ou todos os aplicativos usem um repositório central de credenciais. Existem protocolos para
gerenciar credenciais: Lightweight Directory Access Protocol (LDAP) é um deles.
Algumas empresas escolhem e fornecem um produto 'Password Safe' aprovado pela empresa que cria um arquivo de senha criptografado
no computador de cada usuário. Os usuários só precisam aprender uma senha longa para abrir o programa e podem armazenar todas as
suas senhas com segurança no arquivo criptografado. Um sistema de logon único também pode realizar isso
Função.
3.4 Software de Detecção e Prevenção de Intrusão
Ferramentas que podem detectar incursões e negar acesso dinamicamente são necessárias para quando hackers penetrarem em firewalls
ou outras medidas de segurança.
Um Sistema de Detecção de Intrusão (IDS) notificará as pessoas apropriadas quando ocorrer um incidente inadequado.
O IDS deve estar conectado de maneira ideal a um Sistema de Prevenção de Intrusão (IPS) que responde automaticamente a ataques
conhecidos e combinações ilógicas de comandos do usuário. A detecção geralmente é realizada pela análise de padrões dentro da
organização. O conhecimento dos padrões esperados permite a detecção de eventos fora do comum.
Quando estes ocorrem, o sistema pode enviar alertas.
3.5 Firewalls (Prevenção)
Firewalls seguros e sofisticados, com capacidade para permitir a transmissão de dados em velocidade máxima enquanto ainda executam
análises detalhadas de pacotes, devem ser colocados no gateway corporativo. Para servidores Web expostos à Internet, uma estrutura de
firewall mais complexa é recomendada, pois muitos ataques de hackers mal-intencionados exploram tráfego aparentemente legítimo que é
intencionalmente malformado para explorar vulnerabilidades de banco de dados e servidor Web.
3.6 Rastreamento de Metadados
As ferramentas que rastreiam metadados podem ajudar uma organização a rastrear o movimento de dados confidenciais. Essas ferramentas
criam o risco de que agentes externos possam detectar informações internas de metadados associados a documentos. A identificação de
informações confidenciais usando Metadados fornece a melhor maneira de garantir que os dados sejam protegidos adequadamente. Desde
258 • DMBOK2
o maior número de incidentes de perda de dados resulta da falta de proteção de dados confidenciais devido ao desconhecimento de sua
sensibilidade, a documentação de metadados ofusca completamente qualquer risco hipotético que possa ocorrer se os metadados forem
expostos de alguma forma do repositório de metadados. Esse risco se torna mais insignificante, pois é trivial para um hacker experiente
localizar dados confidenciais desprotegidos na rede. As pessoas que provavelmente desconhecem a necessidade de proteger dados
confidenciais parecem ser funcionários e gerentes.
3.7 Mascaramento/Criptografia de Dados
As ferramentas que realizam mascaramento ou criptografia são úteis para restringir o movimento de dados confidenciais. (Consulte a Seção
1.3.9.)
4. Técnicas
As técnicas para gerenciar a segurança da informação dependem do tamanho da organização, da arquitetura da rede, do tipo de dados que
devem ser protegidos e das políticas e padrões usados por uma organização de segurança.
4.1 Uso da Matriz CRUD
Criar e usar matrizes de relacionamento de dados para processo e dados para função (CRUD–Criar, Ler, Atualizar, Excluir) ajuda a mapear
as necessidades de acesso a dados e orientar a definição de grupos de funções de segurança de dados, parâmetros e permissões.
Algumas versões adicionam um E para Execute para tornar CRUDE.
4.2 Implantação imediata do patch de segurança
Um processo para instalar patches de segurança o mais rápido possível em todas as máquinas deve estar em vigor. Um hacker mal-
intencionado precisa apenas de acesso root a uma máquina para realizar seu ataque com sucesso na rede. Os usuários não devem poder
atrasar esta atualização.
4.3 Atributos de Segurança de Dados em Metadados
Um repositório de Metadados é essencial para garantir a integridade e o uso consistente de um Modelo de Dados Corporativos em todos os
processos de negócios. Os metadados devem incluir classificações regulatórias e de segurança para os dados. (Consulte a Seção 1.1.3.)
Ter metadados de segurança em vigor protege uma organização de funcionários que podem não reconhecer os dados como confidenciais.
Quando os Administradores de Dados aplicam categorias regulatórias e de confidencialidade, as informações da categoria devem ser
documentadas no repositório de metadados e, se a tecnologia permitir, marcadas nos dados. (Consulte as Seções 3.3.1 e
3.3.2.) Essas classificações podem ser usadas para definir e gerenciar direitos e autorizações de usuários, bem como para informar as equipes de
desenvolvimento sobre riscos relacionados a dados confidenciais.
4.4 Métricas
É essencial medir os processos de proteção da informação para garantir que eles estejam funcionando conforme necessário.
As métricas também possibilitam a melhoria desses processos. Algumas métricas medem o progresso dos processos: o número de auditorias
realizadas, os sistemas de segurança instalados, os incidentes relatados e a quantidade de dados não examinados nos sistemas. Métricas mais
sofisticadas se concentrarão em descobertas de auditorias ou no movimento da organização ao longo de um modelo de maturidade.
Em organizações maiores com equipe de segurança da informação existente, um número significativo dessas métricas pode já existir. É útil reutilizar
as métricas existentes como parte de um processo geral de medição de gerenciamento de ameaças e evitar a duplicação de esforços. Crie uma
linha de base (leitura inicial) de cada métrica para mostrar o progresso

hora extra.
Embora um grande número de atividades e condições de segurança possam ser medidos e rastreados, concentre-se em métricas acionáveis.
Algumas métricas-chave em grupos organizados são mais fáceis de gerenciar do que páginas de indicadores aparentemente não relacionados. As
ações de melhoria podem incluir treinamento de conscientização sobre políticas regulatórias de dados e conformidade
ações.
Muitas organizações enfrentam desafios semelhantes de segurança de dados. As listas a seguir podem ajudar na seleção de
Métricas.
4.4.1 Métricas de Implementação de Segurança
Essas métricas gerais de segurança podem ser enquadradas como porcentagens de valor positivo:
• Porcentagem de computadores corporativos com os patches de segurança mais recentes instalados
• Porcentagem de computadores com software antimalware atualizado instalado e em execução
• Porcentagem de novos contratados que tiveram verificações de antecedentes bem-sucedidas
• Porcentagem de funcionários com pontuação superior a 80% no questionário anual de práticas de segurança
• Porcentagem de unidades de negócios para as quais uma análise formal de avaliação de risco foi concluída
• Porcentagem de processos de negócios testados com sucesso para recuperação de desastres em caso de incêndio,
terremoto, tempestade, inundação, explosão ou outro desastre
• Porcentagem de constatações de auditoria que foram resolvidas com sucesso
As tendências podem ser rastreadas em métricas enquadradas como listas ou estatísticas:
• Métricas de desempenho de todos os sistemas de segurança
• Investigações de antecedentes e resultados
• Planejamento de contingência e status do plano de continuidade de negócios

260 • DMBOK2
• Incidentes e investigações criminais • Exames de
due diligence para conformidade e número de descobertas que precisam ser abordadas • Análise de gerenciamento de risco
informacional realizada e número daqueles que resultam em ações acionáveis
mudanças
• Implicações e resultados de auditoria de política, como verificações de política de mesa limpa, realizadas pelo turno da noite
agentes de segurança durante as
rondas • Estatísticas de operações de segurança, segurança física e proteção de instalações •
Número de padrões de segurança documentados e acessíveis (também conhecidos como políticas)
• A motivação das partes relevantes para cumprir as políticas de segurança também pode ser medida • Conduta comercial
e análise de risco de reputação, incluindo treinamento de funcionários • Higiene empresarial e potencial de risco interno
com base em tipos específicos de dados, como financeiros, médicos,
segredos comerciais e informações privilegiadas
• Indicadores de confiança e influência entre gerentes e funcionários como indicação de como os dados
esforços e políticas de segurança da informação são percebidos
Selecione e mantenha um número razoável de métricas acionáveis em categorias apropriadas ao longo do tempo para garantir a conformidade,
identificar problemas antes que se tornem crises e indicar à alta administração a determinação de proteger informações corporativas valiosas.
4.4.2 Métricas de conscientização de segurança
Considere estas áreas gerais para selecionar as métricas apropriadas:
• As descobertas da avaliação de risco fornecem dados qualitativos que precisam ser devolvidos aos negócios apropriados
unidades para torná-los mais conscientes de sua responsabilidade.
• Eventos e perfis de risco identificam exposições não gerenciadas que precisam de correção. Determinar a ausência
ou grau de melhoria mensurável na exposição ao risco ou conformidade com a política através da realização de testes de
acompanhamento da iniciativa de conscientização para ver como as mensagens foram transmitidas.
• Pesquisas formais de feedback e entrevistas identificam o nível de conscientização sobre segurança. Além disso, meça o número de
funcionários que concluíram com êxito o treinamento de conscientização de segurança nas populações-alvo.
• Post mortems de incidentes, lições aprendidas e entrevistas com vítimas fornecem uma rica fonte de informações sobre lacunas na
conscientização sobre segurança. As medidas podem incluir quanta vulnerabilidade foi mitigada.
• As auditorias de eficácia de patches envolvem máquinas específicas que trabalham com
informações para avaliar a eficácia do patch de segurança. (Um sistema de correção automatizado é recomendado sempre que
possível.)
4.4.3 Métricas de Proteção de Dados
Os requisitos ditarão quais deles são pertinentes a uma organização:
• Classificação de criticidade de tipos de dados específicos e sistemas de informação que, se inoperantes,
têm um impacto profundo na empresa.
• Expectativa de perda anual de acidentes, hacks, roubos ou desastres relacionados à perda de dados, comprometimento ou
corrupção.
• Risco de perda de dados específicos relacionados a certas categorias de informações regulamentadas e remediação
classificação de prioridade.
• Mapeamento de risco de dados para processos de negócios específicos. Riscos associados a dispositivos de ponto de venda
seriam incluídos no perfil de risco do sistema de pagamentos financeiros.
• Avaliações de ameaças realizadas com base na probabilidade de um ataque contra determinados dados valiosos
recursos e os meios pelos quais viajam.
• Avaliações de vulnerabilidade de partes específicas do processo de negócios onde informações confidenciais podem
ser exposto, acidentalmente ou intencionalmente.
Lista auditável de locais onde dados confidenciais são propagados em toda a organização.
4.4.4 Métricas de Incidentes de Segurança
• Tentativas de intrusão detectadas e prevenidas
• Retorno do investimento para custos de segurança usando economias de invasões evitadas
4.4.5 Proliferação de Dados Confidenciais
O número de cópias de dados confidenciais deve ser medido para reduzir essa proliferação. Quanto mais locais os dados confidenciais
forem armazenados, maior será o risco de violação.
4.5 Necessidades de Segurança nos Requisitos do Projeto
Todo projeto que envolve dados deve abordar a segurança do sistema e dos dados. Identifique dados detalhados e requisitos de segurança
de aplicativos na fase de análise. A identificação antecipada orienta o projeto e evita a necessidade de modernizar os processos de
segurança. Se as equipes de implementação entenderem os requisitos de proteção de dados desde o início, elas poderão incorporar a
conformidade à arquitetura básica do sistema. Essas informações também podem ser usadas para selecionar os pacotes de software
adquiridos/fornecedor apropriados.
262 • DMBOK2
4.6 Pesquisa eficiente de dados criptografados
A pesquisa de dados criptografados obviamente inclui a necessidade de descriptografar os dados. Uma maneira de reduzir a quantidade de dados
que precisam de descriptografia é criptografar os critérios de pesquisa (como uma string) usando o mesmo método de criptografia usado para os
dados e, em seguida, buscar correspondências. A quantidade de dados correspondentes aos critérios de pesquisa criptografados será muito menor
e, portanto, menos custosa (e arriscada) para descriptografar. Em seguida, pesquise usando texto não criptografado no conjunto de resultados para obter
fósforos.
4.7 Higienização de Documentos
A sanitização de documentos é o processo de limpeza de metadados, como histórico de alterações rastreadas, de documentos antes do
compartilhamento. A sanitização reduz o risco de compartilhar informações confidenciais que podem ser incorporadas aos comentários. Em contratos
especialmente, o acesso a essas informações pode afetar negativamente as negociações.
A implementação de práticas de segurança de dados depende da cultura corporativa, da natureza dos riscos, da sensibilidade dos dados que a
empresa gerencia e dos tipos de sistemas implantados. Os componentes do sistema de implementação devem ser guiados por um plano estratégico
de segurança e arquitetura de suporte.
Manter os dados seguros está profundamente conectado à cultura corporativa. As organizações geralmente acabam reagindo a crises, em vez de
gerenciar proativamente a responsabilidade e garantir a auditabilidade. Embora a segurança de dados perfeita seja quase impossível, a melhor
maneira de evitar violações de segurança de dados é conscientizar e compreender os requisitos, políticas e procedimentos de segurança. As
organizações podem aumentar a conformidade por meio de:
• Treinamento: Promoção de padrões por meio de treinamento em iniciativas de segurança em todos os níveis da
organização. Acompanhar treinamentos com mecanismos de avaliação como testes online focados em melhorar
conscientização dos funcionários. Esse treinamento e teste devem ser obrigatórios e um pré-requisito para o funcionário
avaliação de desempenho.
• Políticas consistentes: Definição de políticas de segurança de dados e políticas de conformidade regulatória para
grupos de trabalho e departamentos que complementam e se alinham com as políticas corporativas. Adotando um 'ato
a mentalidade local ajuda a envolver as pessoas mais ativamente.
• Meça os benefícios da segurança: vincule os benefícios da segurança de dados às iniciativas organizacionais.
As organizações devem incluir métricas objetivas para atividades de segurança de dados em seu balanced scorecard
medições e avaliações de projetos.

SEGURANÇA DE DADOS • 2 63
• Definir requisitos de segurança para fornecedores: incluir requisitos de segurança de dados no nível de serviço
acordos e obrigações contratuais de terceirização. Os acordos de SLA devem incluir toda a proteção de dados
ações.
• Crie um senso de urgência: enfatize os requisitos legais, contratuais e regulatórios para criar um senso
de urgência e um quadro interno para a gestão da segurança dos dados.
• Comunicações contínuas: Apoiar um programa contínuo de treinamento de segurança de funcionários informando
trabalhadores de práticas de computação seguras e ameaças atuais. Um programa contínuo comunica que a segurança
a computação é importante o suficiente para que a administração a suporte.
As organizações precisam desenvolver políticas de dados que permitam atingir suas metas enquanto protegem informações confidenciais
e regulamentadas contra uso indevido ou exposição não autorizada. Eles devem levar em conta os interesses de todas as partes
interessadas, pois equilibram riscos com facilidade de acesso. Muitas vezes, a arquitetura técnica deve acomodar a
Arquitetura de dados para equilibrar essas necessidades para criar um ambiente eletrônico eficaz e seguro. Na maioria
organizações, o comportamento da administração e dos funcionários precisará mudar se quiserem proteger seus dados com sucesso.
Em muitas empresas maiores, o grupo de segurança da informação existente terá em vigor políticas, proteções, ferramentas de segurança,
sistemas de controle de acesso e dispositivos e sistemas de proteção de informações. Deve haver uma compreensão e apreciação claras
onde esses elementos complementam o trabalho realizado pelos administradores de dados e administradores de dados. Os Administradores
de Dados são geralmente responsáveis pela categorização de dados. As equipes de segurança da informação auxiliam no cumprimento
da conformidade e estabelecem procedimentos operacionais com base em políticas de proteção de dados e categorização de segurança
e regulamentação.
A implementação de medidas de segurança de dados sem levar em conta as expectativas de clientes e funcionários pode resultar em
insatisfação do funcionário, insatisfação do cliente e risco organizacional. Para promover a conformidade, as medidas de segurança de
dados devem levar em conta o ponto de vista daqueles que trabalharão com os dados e sistemas.
Medidas de segurança técnica bem planejadas e abrangentes devem facilitar o acesso seguro para
partes interessadas.
5.3 Visibilidade da titularidade de dados do usuário
Cada titularidade de dados do usuário, que é a soma total de todos os dados disponibilizados por uma única autorização, deve ser revisada
durante a implementação do sistema para determinar se contém alguma informação regulamentada. Saber quem pode ver quais dados
requer gerenciamento de Metadados que descreva a confidencialidade e classificações regulatórias dos dados, bem como o gerenciamento
dos próprios direitos e autorizações.
A classificação da sensibilidade regulatória deve ser uma parte padrão do processo de definição de dados.
264 • DMBOK2
5.4 Segurança de dados em um mundo terceirizado
Qualquer coisa pode ser terceirizada, exceto responsabilidade.
A terceirização de operações de TI introduz desafios e responsabilidades adicionais de segurança de dados. A terceirização aumenta o número
de pessoas que compartilham a responsabilidade pelos dados além das fronteiras organizacionais e geográficas. Funções e responsabilidades
anteriormente informais devem ser explicitamente definidas como obrigações contratuais.
Os contratos de terceirização devem especificar as responsabilidades e expectativas de cada função.
Qualquer forma de terceirização aumenta o risco para a organização, incluindo alguma perda de controle sobre o ambiente técnico e as pessoas
que trabalham com os dados da organização. As medidas e processos de segurança de dados devem
veja o risco do fornecedor terceirizado como um risco externo e interno.
A maturidade da terceirização de TI permitiu que as organizações repensassem os serviços terceirizados. Surgiu um amplo consenso de que a
arquitetura e a propriedade de TI, que inclui a arquitetura de segurança de dados, deve ser uma função de origem. Em outras palavras, a
organização interna possui e gerencia a arquitetura corporativa e de segurança. O parceiro terceirizado pode assumir a responsabilidade pela
implementação da arquitetura.
Transferir o controle, mas não a responsabilidade, requer mecanismos de controle e gerenciamento de risco mais rígidos. Alguns
esses mecanismos incluem:
• Acordos de Nível de Serviço
• Disposições de responsabilidade limitada no contrato de terceirização
• Cláusulas de direito de auditoria no contrato
• Consequências claramente definidas para a violação de obrigações contratuais
• Relatórios frequentes de segurança de dados do fornecedor de serviços
• Monitoramento independente da atividade do sistema do fornecedor
• Auditoria de segurança de dados frequente e completa

• Comunicação constante com o fornecedor de serviços
• Conscientização das diferenças legais na lei contratual se o fornecedor estiver localizado em outro país e um
surge a disputa
Em um ambiente terceirizado, é fundamental rastrear a linhagem, ou fluxo, de dados entre sistemas e indivíduos para manter uma 'cadeia de
custódia'. As organizações de terceirização se beneficiam especialmente do desenvolvimento de matrizes CRUD (Criar, Ler, Atualizar e Excluir)
que mapeiam responsabilidades de dados em processos de negócios, aplicativos, funções e organizações, rastreando a transformação,
linhagem e cadeia de custódia dos dados. Além disso, a capacidade de executar decisões de negócios ou funcionalidade do aplicativo, como
aprovação de cheques ou pedidos, deve ser incluída como parte da matriz.
As matrizes RACI (Responsável, Responsável, Consultado e Informado) também ajudam a esclarecer as funções, a separação de funções e as
responsabilidades de diferentes funções, incluindo suas obrigações de segurança de dados.
A matriz RACI pode fazer parte dos acordos contratuais e políticas de segurança de dados. A definição de matrizes de responsabilidade como
o RACI estabelecerá responsabilidade e propriedade claras entre as partes envolvidas no contrato de terceirização, levando ao suporte das
políticas gerais de segurança de dados e sua implementação.

Na terceirização de operações de tecnologia da informação, a responsabilidade pela manutenção dos dados ainda é da organização. É
fundamental ter mecanismos de conformidade adequados e ter expectativas realistas das partes que celebram os contratos de
terceirização.
5.5 Segurança de dados em ambientes de nuvem
O rápido surgimento da computação na web e da interação business-to-business e business-to-consumer fez com que os limites dos
dados se estendessem além das quatro paredes da organização. Os recentes avanços na computação em nuvem estenderam as
fronteiras um passo adiante. A nomenclatura 'como serviço' agora é comum em todas as pilhas de tecnologia e negócios. 'Dados como
serviço', 'Software como serviço', 'Plataforma como serviço' são termos comumente usados hoje. A computação em nuvem, ou seja, ter
recursos distribuídos pela internet para processar dados e informações, está complementando o provisionamento 'X-as-a-Service'.
As políticas de segurança de dados precisam levar em conta a distribuição de dados entre os diferentes modelos de serviço. Isso inclui
a necessidade de aproveitar os padrões de segurança de dados externos.
A responsabilidade compartilhada, definindo a cadeia de custódia de dados e definindo direitos de propriedade e custódia, é
especialmente importante na computação em nuvem. As considerações de infraestrutura (por exemplo, quem é responsável pelo firewall
quando o provedor de nuvem entrega o software pela web? Quem é responsável pelos direitos de acesso nos servidores?) têm impactos
diretos no gerenciamento de segurança de dados e nas políticas de dados.
O ajuste fino ou até mesmo a criação de uma nova política de gerenciamento de segurança de dados voltada para a computação em
nuvem é necessária para organizações de todos os portes. Mesmo que uma organização não tenha implementado recursos diretamente
na nuvem, os parceiros de negócios podem. Em um mundo de dados conectado, ter um parceiro de negócios usando computação em
nuvem significa colocar os dados da organização na nuvem. Os mesmos princípios de segurança de proliferação de dados se aplicam a
dados de produção sensíveis/confidenciais.
A arquitetura interna de datacenter em nuvem, incluindo máquinas virtuais, embora potencialmente mais seguras, deve seguir a mesma
política de segurança do restante da empresa.
6. Governança de Segurança de Dados
Proteger os sistemas corporativos e os dados que eles armazenam requer cooperação entre as partes interessadas de TI e de negócios.
Políticas e procedimentos fortes e claros são a base da governança de segurança.
6.1 Segurança de Dados e Arquitetura Empresarial
A Arquitetura Corporativa define os ativos e componentes de informações de uma empresa, seus inter-relacionamentos e regras de
negócios relacionadas à transformação, princípios e diretrizes. A arquitetura de segurança de dados é a

266 • DMBOK2
componente da arquitetura corporativa que descreve como a segurança de dados é implementada dentro da empresa para atender
às regras de negócios e regulamentos externos. A arquitetura influencia:
• Ferramentas usadas para gerenciar a segurança de dados
• Padrões e mecanismos de criptografia de dados

• Diretrizes de acesso a fornecedores e contratados externos
• Protocolos de transmissão de dados pela internet
• Documentos necessários
• Padrões de acesso remoto
• Procedimentos de comunicação de incidentes de violação de segurança
A arquitetura de segurança é particularmente importante para a integração de dados entre:
• Sistemas internos e unidades de negócios

• Uma organização e seus parceiros de negócios externos
• Uma organização e agências reguladoras
Por exemplo, um padrão de arquitetura de um mecanismo de integração orientado a serviços entre partes internas e externas exigiria
uma implementação de segurança de dados diferente do tradicional intercâmbio eletrônico de dados (EDI).
arquitetura de integração.
Para uma grande empresa, a função de ligação formal entre essas disciplinas é essencial para proteger as informações contra uso
indevido, roubo, exposição e perda. Cada parte deve estar ciente dos elementos que dizem respeito às outras, para que possam falar
uma linguagem comum e trabalhar em direção a objetivos compartilhados.

Andressa, Jasão. Os Fundamentos da Segurança da Informação: Entendendo os Fundamentos da InfoSec na Teoria e na Prática.
Syngress, 2011. Impresso.
Calder, Alan e Steve Watkins. Governança de TI: um guia internacional para segurança de dados e ISO27001/ ISO27002. 5ª edição.
Kogan Page, 2012. Impresso.
Fuster, Glória González. O surgimento da proteção de dados pessoais como um direito fundamental da UE. Springer, 2014.
Imprimir. Série/Questões de Direito, Governança e Tecnologia em Privacidade e Proteção de Dados.
Harkins, Malcom. Gerenciando Riscos e Segurança da Informação: Proteger para Habilitar (Voz do Especialista em Tecnologia da Informação).
Apress, 2012. Kindle.
Hayden, Lance. Métricas de segurança de TI: uma estrutura prática para medir a segurança e proteger os dados. McGraw-Hill Osborne Media,
2010. Impresso.
Kark, Khalid. “Construindo um caso de negócios para segurança da informação”. Mundo de computador. 2009-08-10 http://bit.ly/2rCu7QQ Web.
Kennedy, Gwen e Leighton Peter Prabhu. Privacidade de Dados: Um Guia Prático. Interstice Consulting LLP, 2014. Kindle.
Serviços Digitais Amazon.
Murdoch, Don GSE. Blue Team Handbook: Incident Response Edition: Um guia de campo condensado para o Cyber Security Incident
Responder. 2ª edição. Plataforma de Publicação Independente CreateSpace, 2014. Imprimir.
Instituto Nacional de Padrões e Tecnologia (site do Departamento de Comércio dos EUA) http://bit.ly/1eQYolG.
Rao, Umesh Hodeghatta e Umesha Nayak. O Manual InfoSec: Uma Introdução à Segurança da Informação. Apress, 2014. Kindle. Serviços
Digitais Amazon.
Ray, Dewey E. O manual de fusões e aquisições do profissional de TI. Diligência Cognitiva, 2012.
Schlesinger, David. The Hidden Corporation: Um romance de segurança de gerenciamento de dados. Technics Publications, LLC, 2011. Imprimir.
Singer, PW e Allan Friedman. Segurança cibernética e guerra cibernética: o que todos precisam saber®. Oxford University Press, 2014.
Impresso. O que todos precisam saber.
Watts, João. Certified Information Privacy Professional Study Guide: Passe no Exame de Certificação da IAPP com facilidade! Plataforma de
Publicação Independente CreateSpace, 2014. Imprimir.
Williams, Branden R., Anton Chuvakin Ph.D. Conformidade com PCI: entenda e implemente a conformidade efetiva com o padrão de
segurança de dados PCI. 4ª edição. Syngress, 2014. Impresso.
CAPÍTULO 8
Integração e interoperabilidade de dados
Dados
Modelagem de dados
Qualidade dos dados
& Operações
Dados Dados
Metadados

& O negócio
Interoperabilidade
Inteligência
& Mestre & Contente
Dados Gestão

1. Introdução
D
ata Integração e Interoperabilidade (DII) descreve os processos relacionados à movimentação e
consolidação de dados dentro e entre armazenamentos de dados, aplicativos e organizações. Integração
consolida dados em formas consistentes, físicas ou virtuais. A interoperabilidade de dados é a capacidade de vários sistemas
se comunicarem. As soluções DII permitem funções básicas de gerenciamento de dados das quais a maioria das organizações depende:
• Migração e conversão de dados

• Consolidação de dados em hubs ou marts
269
270 • DMBOK2
• Integração de pacotes de fornecedores no portfólio de aplicativos de uma organização
• Compartilhamento de dados entre aplicativos e entre organizações
• Distribuindo dados entre armazenamentos de dados e data centers
• Arquivamento de dados
• Gerenciando interfaces de dados
• Obtenção e ingestão de dados externos
• Integração de dados estruturados e não estruturados
• Fornecendo inteligência operacional e suporte à decisão de gestão
O DII depende dessas outras áreas de gerenciamento de dados:
• Governança de Dados: Para governar as regras de transformação e estruturas de mensagens
• Arquitetura de Dados: Para projetar soluções
• Segurança de Dados: Para garantir que as soluções protejam adequadamente a segurança dos dados, sejam eles
persistente, virtual ou em movimento entre aplicativos e organizações
• Metadados: Para rastrear o inventário técnico de dados (persistente, virtual e em movimento), o negócio
significado dos dados, as regras de negócios para transformar os dados e o histórico operacional e
linhagem dos dados
• Armazenamento e Operações de Dados: Para gerenciar a instanciação física das soluções
• Modelagem e Design de Dados: Para projetar as estruturas de dados, incluindo persistência física em
bancos de dados, estruturas de dados virtuais e mensagens que passam informações entre aplicativos e
organizações
A integração e a interoperabilidade de dados são críticas para Data Warehousing e Business Intelligence, bem como para Reference Data e
Master Data Management, porque todos eles se concentram na transformação e integração de dados de sistemas de origem para hubs de dados
consolidados e de hubs para sistemas de destino onde pode ser entregue aos consumidores de dados, tanto de sistema quanto humanos.
A integração e interoperabilidade de dados é central para a área emergente de gerenciamento de Big Data. O Big Data busca integrar vários tipos
de dados, incluindo dados estruturados e armazenados em bancos de dados, dados de texto não estruturados em documentos ou arquivos, outros
tipos de dados não estruturados, como dados de áudio, vídeo e streaming. Esses dados integrados podem ser extraídos, usados para desenvolver
modelos preditivos e implantados em atividades de inteligência operacional.
A necessidade de gerenciar a movimentação de dados com eficiência é o principal fator para o DII. Como a maioria das organizações tem
centenas ou milhares de bancos de dados e armazenamentos, o gerenciamento dos processos de movimentação de dados entre os
armazenamentos de dados dentro da organização e de e para outras organizações tornou-se uma responsabilidade central de todas as
organizações de tecnologia da informação. Se não for gerenciado adequadamente, o processo de movimentação de dados pode sobrecarregar
os recursos e capacidades de TI e diminuir os requisitos de suporte de aplicativos tradicionais e gerenciamento de dados

áreas.
INTEGRAÇÃO DE DADOS E INTEROPERABILIDADE • 271
O advento de organizações que compram aplicativos de fornecedores de software, em vez de desenvolver aplicativos
personalizados, amplificou a necessidade de integração e interoperabilidade de dados corporativos. Cada aplicativo adquirido vem
com seu próprio conjunto de armazenamentos de dados mestres, armazenamentos de dados de transações e armazenamentos
de dados de relatórios que devem ser integrados a outros armazenamentos de dados da organização. Mesmo os sistemas
Enterprise Resource Planning (ERP) que executam as funções comuns da organização raramente, ou nunca, abrangem todos os
armazenamentos de dados da organização. Eles também precisam ter seus dados integrados a outros dados organizacionais.
Integração e interoperabilidade de dados

Definição: Gerenciando o movimento e a consolidação de dados dentro e entre aplicativos e
organizações
Metas:
1. Forneça dados com segurança, com conformidade regulatória, no formato e prazo necessários.
2. Menor custo e complexidade de gerenciamento de soluções desenvolvendo modelos e interfaces compartilhados.
3. Identifique eventos significativos e acione alertas e ações automaticamente.
4. Apoiar os esforços de inteligência de negócios, análise, gerenciamento de dados mestre e eficiência operacional.
O negócio
Motoristas

• Objetivos de negócios e 1. Planejar e Analisar (P)
• Arquitetura DII
Estratégias 1. Definir integração de dados e ciclo de vida
• Troca de dados
• Necessidades de dados e requisitos 2.
Especificações
Execute a descoberta de dados
Padrões • Acesso de dados
3. Linhagem de Dados do Documento
• Regulatório, 4. Dados do perfil Contratos
Observância, & • Serviços de dados
5. Examinar a conformidade com as regras de negócios
Segurança 2. Projetar Soluções DII (P) • Evento Complexo

Requisitos 1. Componentes da solução de design Em processamento
• Dados, Processo, 2. Mapear origens para destinos Limites e

3. Orquestração de Dados de Projeto Alertas
Aplicação, e
3. Desenvolver soluções DII (D)
Técnico
1. Desenvolver serviços de dados
Arquiteturas 2. Desenvolva a orquestração de fluxo de dados
• Semântica de dados 3. Desenvolver abordagem de migração de dados
• Dados de origem 4. Desenvolva Processamento de Eventos Complexos
5. Manter Metadados DII
4. Implementar e Monitorar (O)

• Produtores de dados • Arquitetos de dados • Consumidores de informação
• •
Comitê de Direção de TI Analistas de negócios e dados • Trabalhadores de conhecimento
• Executivos e • Modeladores de dados •
Gerentes e Executivos
• Administradores de dados
Gerentes
• •
Especialistas no assunto ETL, Serviço, Desenvolvedores de Interface
•
Gerentes de Projetos e Programas
Técnico
Motoristas

• •
Integração Hub e Spoke Mecanismo de transformação de dados Volumes de dados e velocidade
• Extrair carga de transformação • Servidor de virtualização de dados de entrega
• •
(ELT) Barramento de serviço empresarial Latência de dados
• • • Tempo de comercialização para
Aplicativo corporativo Ferramentas de modelagem de dados e processos
• Melhorias
Integração (EAI) Ferramenta de criação de perfil de dados
• Arquitetura Orientada a Serviços • • Custos de solução e
Repositório de Metadados
(SOA) Complexidade
• Integração Hub e Spoke • Valor entregue
Figura 66 Diagrama de contexto: integração de dados e interoperabilidade

272 • DMBOK2
A necessidade de gerenciar a complexidade e os custos associados à complexidade são motivos para arquitetar a integração de dados de uma
perspectiva corporativa. Um projeto corporativo de integração de dados é comprovadamente mais eficiente e econômico do que soluções distribuídas
ou ponto a ponto. O desenvolvimento de soluções ponto a ponto entre aplicativos pode resultar em milhares a milhões de interfaces e pode
sobrecarregar rapidamente os recursos até mesmo da organização de suporte de TI mais eficaz e eficiente.
Os hubs de dados, como data warehouses e soluções Master Data, ajudam a aliviar esse problema, consolidando os dados necessários para muitos
aplicativos e fornecendo a esses aplicativos exibições consistentes dos dados.
Da mesma forma, a complexidade do gerenciamento de dados operacionais e transacionais que precisam ser compartilhados em toda a organização
pode ser bastante simplificada usando técnicas de integração de dados corporativos, como integração hub-and-spoke e modelos de mensagens
canônicas.
Outro driver de negócios é gerenciar o custo de suporte. A movimentação de dados usando várias tecnologias, cada uma exigindo habilidades
específicas de desenvolvimento e manutenção, pode aumentar os custos de suporte. As implementações de ferramentas padrão podem reduzir os
custos de suporte e pessoal e melhorar a eficiência dos esforços de solução de problemas.
Reduzir a complexidade do gerenciamento de interface pode diminuir o custo de manutenção de interface e permitir que os recursos de suporte
sejam implantados com mais eficiência em outras prioridades organizacionais.
O DII também suporta a capacidade de uma organização de cumprir os padrões e regulamentos de manipulação de dados. Os sistemas DII de
nível empresarial permitem a reutilização de código para implementar regras de conformidade e simplificar a verificação de conformidade.
A implementação de práticas e soluções de Integração e Interoperabilidade de Dados visa:
• Disponibilize os dados no formato e prazo necessários para os consumidores de dados, tanto humanos quanto de sistema
• Consolide os dados física e virtualmente em hubs de dados
• Menor custo e complexidade de gerenciamento de soluções desenvolvendo modelos e interfaces compartilhados
• Identifique eventos significativos (oportunidades e ameaças) e acione automaticamente alertas e ações
• Suporte aos esforços de Business Intelligence, analytics, Master Data Management e eficiência operacional
Ao implementar o DII, uma organização deve seguir estes princípios:
• Adote uma perspectiva corporativa no design para garantir extensibilidade futura, mas implemente por meio de
e entrega incremental
• Equilibre as necessidades de dados locais com as necessidades de dados corporativos, incluindo suporte e manutenção.
• Garantir a responsabilidade comercial pelo projeto e atividade de integração e interoperabilidade de dados. O negócio
especialistas devem estar envolvidos no projeto e modificação das regras de transformação de dados, tanto persistentes quanto
e virtuais.
1.3.1 Extrair, Transformar e Carregar
Central para todas as áreas de Integração e Interoperabilidade de Dados é o processo básico de Extrair, Transformar e Carregar (ETL). Seja executado
fisicamente ou virtualmente, em lote ou em tempo real, essas são as etapas essenciais na movimentação de dados entre aplicativos e organizações.
Dependendo dos requisitos de integração de dados, o ETL pode ser executado como um evento programado periodicamente (lote) ou sempre que dados
novos ou atualizados estiverem disponíveis (em tempo real ou orientado a eventos). O processamento de dados operacionais tende a ser em tempo real
ou quase em tempo real, enquanto os dados necessários para análise ou geração de relatórios geralmente são agendados em trabalhos em lote.
Os requisitos de integração de dados também determinam se os dados extraídos e transformados são fisicamente armazenados em estruturas de teste. A
preparação física permite uma trilha de auditoria das etapas que ocorreram com os dados e possíveis reinícios do processo a partir de um ponto
intermediário. No entanto, as estruturas de teste ocupam espaço em disco e levam tempo para gravar e ler. As necessidades de integração de dados que
exigem latência muito baixa geralmente não incluem a preparação física dos resultados intermediários da integração de dados.
1.3.1.1 Extrato
O processo de extração inclui selecionar os dados necessários e extraí-los de sua fonte. Os dados extraídos são então encenados, em um armazenamento
de dados físico no disco ou na memória. Se fisicamente preparado em disco, o armazenamento de dados de preparo pode ser colocado no mesmo local
com o armazenamento de dados de origem ou com o armazenamento de dados de destino, ou ambos.
Idealmente, se esse processo for executado em um sistema operacional, ele é projetado para usar o mínimo de recursos possível, a fim de evitar afetar
negativamente os processos operacionais. O processamento em lote fora do horário de pico é uma opção para extrações que incluem processamento
complexo para realizar a seleção ou identificar dados alterados a serem extraídos.
1.3.1.2 Transformar
O processo de transformação torna os dados selecionados compatíveis com a estrutura do armazenamento de dados de destino.
A transformação inclui casos em que os dados são removidos da origem quando são movidos para o destino, em que os dados são copiados para vários
destinos e em que os dados são usados para disparar eventos, mas não são persistidos.
Exemplos de transformação podem incluir
• Alterações de formato: Conversão do formato técnico dos dados; por exemplo, de EBCDIC para ASCII
formato
• Mudanças na estrutura : Mudanças na estrutura dos dados; por exemplo, de desnormalizado para
registros normalizados
274 • DMBOK2
• Conversão semântica: Conversão de valores de dados para manter uma representação semântica consistente. Por
Por exemplo, os códigos de gênero de origem podem incluir 0, 1, 2 e 3, enquanto os códigos de gênero de destino podem ser
representado como DESCONHECIDO, FEMININO, MASCULINO ou NÃO FORNECIDO.
• Deduping: Garantir que, se as regras exigirem valores ou registros de chave exclusivos, um meio de verificar o
alvo, e detectar e remover linhas duplicadas, está incluído
• Reordenação: alterando a ordem dos elementos de dados ou registros para se adequar a um padrão definido
A transformação pode ser realizada em lote ou em tempo real, armazenando fisicamente o resultado em uma área de teste ou armazenando
virtualmente os dados transformados na memória até que estejam prontos para serem movidos para a etapa de carregamento. Os dados
resultantes do estágio de transformação devem estar prontos para serem integrados aos dados na estrutura de destino.
1.3.1.3 Carga
A etapa de carregamento do ETL está armazenando fisicamente ou apresentando o resultado das transformações no sistema de destino.
Dependendo das transformações realizadas, da finalidade do sistema de destino e do uso pretendido, os dados podem precisar de processamento
adicional para serem integrados a outros dados, ou podem estar em uma forma final, prontos para serem apresentados
consumidores.
Pesquisas
Mapeamentos
Extrair Transformar Carregar
Processo Processo Processo
Fonte
Encenação Alvo
Banco de dados Banco de dados Banco de dados
Figura 67 Fluxo do Processo ETL
1.3.1.4 ELT
Se o sistema de destino tiver mais capacidade de transformação do que a origem ou um sistema de aplicativo intermediário, a ordem dos processos
pode ser alterada para ELT – Extrair, Carregar e Transformar. ELT permite
transformações ocorram após o carregamento no sistema de destino, geralmente como parte do processo. O ELT permite que os dados de
origem sejam instanciados no sistema de destino como dados brutos, o que pode ser útil para outros processos. Isso é comum em
ambientes de Big Data em que o ELT carrega o data lake. (Consulte o Capítulo 14.)
Pesquisas
Mapeamentos
Extrair Carregar Transformar

Processo Processo Processo
Fonte
Alvo
Banco de dados Banco de dados
Figura 68 Fluxo do Processo ELT
1.3.1.5 Mapeamento
Um sinônimo de transformação, um mapeamento é tanto o processo de desenvolvimento da matriz de pesquisa das estruturas de origem
até as estruturas de destino e o resultado desse processo. Um mapeamento define as origens a serem extraídas, as regras para identificar
dados para extração, destinos a serem carregados, regras para identificar linhas de destino para atualização (se houver) e quaisquer regras
de transformação ou cálculos a serem aplicados. Muitas ferramentas de integração de dados oferecem visualizações de mapeamentos que
permitem aos desenvolvedores usar interfaces gráficas para criar código de transformação.
1.3.2 Latência
A latência é a diferença de tempo entre quando os dados são gerados no sistema de origem e quando os dados estão disponíveis para uso
no sistema de destino. Diferentes abordagens ao processamento de dados resultam em diferentes graus de latência de dados. A latência
pode ser alta (lote) ou baixa (orientada a eventos) a muito baixa (síncrona em tempo real).
1.3.2.1 Lote
A maioria dos dados se move entre aplicativos e organizações em grupos ou arquivos, seja por solicitação de um consumidor de dados
humano ou automaticamente em uma programação periódica. Esse tipo de interação é chamado de lote ou ETL.
276 • DMBOK2
A movimentação de dados no modo de lote representará o conjunto completo de dados em um determinado momento, como saldos de contas no final de um
período, ou dados que alteraram valores desde a última vez que os dados foram enviados, como alterações de endereço que foram feitas em um dia. O conjunto
de dados alterados é chamado de delta e os dados de um ponto no tempo são chamados de instantâneo.
Com soluções de integração de dados em lote, geralmente há um atraso significativo entre quando os dados são alterados na origem e quando são atualizados no
destino, resultando em alta latência. O processamento em lote é muito útil para processar volumes muito altos de dados em uma janela de tempo curta. Ele tende
a ser usado para soluções de integração de dados de data warehouse, mesmo quando soluções de baixa latência estão disponíveis.
Para obter um processamento rápido e menor latência, algumas soluções de integração de dados usam processamento em microlote que agenda o processamento
em lote para ser executado em uma frequência muito maior do que a diária, como a cada cinco minutos.
A integração de dados em lote é usada para conversões, migrações e arquivamento de dados, bem como para extrair e carregar data warehouses e data marts.
Existem riscos associados ao tempo de processamento em lote. Para minimizar problemas com atualizações de aplicativos, agende a movimentação de dados
entre aplicativos no final do processamento lógico para o dia útil ou após o processamento especial dos dados à noite. Para evitar conjuntos de dados incompletos,
os trabalhos que movem dados para um data warehouse devem ser agendados com base no agendamento de relatórios diário, semanal ou mensal.
1.3.2.2 Alterar captura de dados
Change Data Capture é um método de redução de largura de banda filtrando para incluir apenas os dados que foram alterados dentro de um período de tempo
definido. A captura de dados de alteração monitora um conjunto de dados quanto a alterações (inserções, alterações, exclusões) e, em seguida, passa essas
alterações (os deltas) para outros conjuntos de dados, aplicativos e organizações que consomem os dados.
Os dados também podem ser marcados com identificadores como sinalizadores ou carimbos de data/hora como parte do processo. A captura de dados de
alteração pode ser baseada em dados ou em log. (Consulte o Capítulo 6.)
Existem três técnicas para captura de dados de alteração baseada em dados.
• O sistema de origem preenche elementos de dados específicos, como carimbos de data/hora dentro de um intervalo ou códigos ou
sinalizadores, que servem como indicadores de modificação. O processo de extração usa regras para identificar as linhas a serem extraídas.
• Os processos do sistema de origem são adicionados a uma lista simples de objetos e identificadores ao alterar dados, o que
é então usado para controlar a seleção de dados para extração.
• O sistema de origem processa dados de cópia que foram alterados em um objeto separado como parte do
transação, que é então usada para o processamento de extração. Este objeto não precisa estar dentro do
Sistema de gerenciamento de banco de dados.
Esses tipos de extração usam recursos integrados ao aplicativo de origem, que podem consumir muitos recursos e exigir a capacidade de modificar o aplicativo de
origem.
Em capturas de dados de alterações baseadas em log, os logs de atividade de dados criados pelo sistema de gerenciamento de banco de dados
são copiados e processados, procurando alterações específicas que são traduzidas e aplicadas a um banco de dados de destino. Traduções
complexas podem ser difíceis, mas estruturas intermediárias semelhantes ao objeto de origem podem ser usadas como forma de preparar as
alterações para processamento posterior.
1.3.2.3 Quase em tempo real e orientado a eventos
A maioria das soluções de integração de dados que não são executadas em lotes usa uma solução quase em tempo real ou orientada a eventos.
Os dados são processados em conjuntos menores espalhados ao longo do dia em uma programação definida ou os dados são processados quando
ocorre um evento, como uma atualização de dados. O processamento quase em tempo real tem uma latência menor do que o processamento em
lote e geralmente uma carga do sistema menor, pois o trabalho é distribuído ao longo do tempo, mas geralmente é mais lento do que uma solução
de integração de dados sincronizada. As soluções de integração de dados quase em tempo real geralmente são implementadas usando uma empresa
ônibus de serviço.
As informações de estado e as dependências do processo devem ser monitoradas pelo processo de carregamento do aplicativo de destino. Os
dados que chegam ao destino podem não estar disponíveis na ordem exata em que o destino precisa para criar os dados de destino corretos. Por
exemplo, processar dados mestre ou dados dimensionais antes de dados transacionais que usam esse mestre
Dados.
1.3.2.4 Assíncrono
Em um fluxo de dados assíncrono, o sistema que fornece dados não espera que o sistema receptor confirme a atualização antes de continuar o
processamento. Assíncrono implica que tanto o sistema de envio quanto o de recebimento podem ficar off-line por algum período sem que o outro
sistema também esteja off-line.
A integração de dados assíncrona não impede que o aplicativo de origem continue seu processamento nem faz com que o aplicativo de origem fique
indisponível se algum dos aplicativos de destino estiver indisponível. Como as atualizações de dados feitas nos aplicativos em uma configuração
assíncrona não são imediatas, a integração é chamada de tempo quase real. O atraso entre as atualizações feitas na origem e retransmitidas para
conjuntos de dados de destino em um ambiente quase em tempo real geralmente é medido em segundos ou minutos.
1.3.2.5 Tempo real, síncrono
Há situações em que nenhum atraso de tempo ou outras diferenças entre os dados de origem e de destino são aceitáveis.
Quando os dados em um conjunto de dados devem ser mantidos perfeitamente sincronizados com os dados em outro conjunto de dados, uma
solução síncrona em tempo real deve ser usada.
Em uma solução de integração síncrona, um processo em execução aguarda a confirmação de outros aplicativos ou processos antes de executar
sua próxima atividade ou transação. Isso significa que a solução pode processar menos transações porque precisa gastar tempo aguardando a
confirmação da sincronização de dados. Caso existam

278 • DMBOK2
dos aplicativos que precisam da atualização não estiverem disponíveis, a transação não poderá ser concluída no aplicativo principal.
Essa situação mantém os dados sincronizados, mas tem o potencial de tornar aplicativos estratégicos dependentes de aplicativos menos
críticos.
As soluções que usam esse tipo de arquitetura existem em um continuum com base em quanta diferença entre conjuntos de dados
pode ser possível e quanto vale essa solução. Os conjuntos de dados podem ser mantidos em sincronia por meio de recursos de banco
de dados, como confirmações de duas fases, que garantem que todas as atualizações em uma transação comercial sejam todas bem-
sucedidas ou que nenhuma seja feita. Por exemplo, as instituições financeiras usam soluções de confirmação de duas fases para
garantir que as tabelas de transações financeiras sejam absolutamente sincronizadas com as tabelas de saldo financeiro. A maioria das
programações não usa commit de duas fases. Existe uma possibilidade muito pequena de que, se um aplicativo for interrompido
inesperadamente, um conjunto de dados possa ser atualizado, mas não outro.
As soluções síncronas em tempo real exigem menos gerenciamento de estado do que as soluções assíncronas porque a ordem em que
as transações são processadas é claramente gerenciada pelos aplicativos de atualização. No entanto, eles também podem levar ao
bloqueio e atrasar outras transações.
1.3.2.6 Baixa Latência ou Streaming
Enormes avanços foram feitos no desenvolvimento de soluções de integração de dados extremamente rápidas. Essas soluções exigem
um grande investimento em hardware e software. Os custos extras de soluções de baixa latência são justificados se uma organização
exigir movimentação de dados extremamente rápida em grandes distâncias. 'Streaming data' flui de sistemas de computador em uma
base contínua em tempo real imediatamente à medida que os eventos ocorrem. Os fluxos de dados capturam eventos como a compra
de bens ou títulos financeiros, comentários de mídia social e leituras de sensores que monitoram a localização, temperatura, uso ou
outros valores.
As soluções de integração de dados de baixa latência são projetadas para minimizar o tempo de resposta a eventos. Eles podem incluir
o uso de soluções de hardware como disco de estado sólido ou soluções de software como bancos de dados na memória para que o
processo não precise desacelerar para ler ou gravar no disco tradicional. Os processos de leitura e gravação em unidades de disco
tradicionais são milhares de vezes mais lentos do que o processamento de dados na memória ou em unidades de disco de estado sólido.
As soluções assíncronas geralmente são usadas em soluções de baixa latência para que as transações não precisem aguardar a
confirmação de processos subsequentes antes de processar o próximo dado.
O multiprocessamento massivo, ou processamento simultâneo, também é uma configuração comum em soluções de baixa latência para
que o processamento de dados recebidos possa ser distribuído por vários processadores simultaneamente, e não congestionado por
um único ou pequeno número de processadores.
1.3.3 Replicação
Para fornecer melhor tempo de resposta para usuários localizados em todo o mundo, alguns aplicativos mantêm cópias exatas de
conjuntos de dados em vários locais físicos. As soluções de replicação minimizam o impacto de desempenho de análises e consultas no
ambiente operacional transacional primário.

Essa solução deve sincronizar as cópias do conjunto de dados distribuídos fisicamente. A maioria dos sistemas de gerenciamento de banco de
dados possui utilitários de replicação para fazer esse trabalho. Esses utilitários funcionam melhor quando todos os conjuntos de dados são mantidos
na mesma tecnologia de sistema de gerenciamento de banco de dados. As soluções de replicação geralmente monitoram o log de alterações no
conjunto de dados, não o próprio conjunto de dados. Eles minimizam o impacto em qualquer aplicativo operacional porque não competem com os
aplicativos pelo acesso ao conjunto de dados. Somente os dados do log de alterações passam entre as cópias replicadas. As soluções de replicação
padrão são quase em tempo real; há um pequeno atraso entre uma alteração em uma cópia do conjunto de dados e outra.
Como os benefícios das soluções de replicação — efeito mínimo no conjunto de dados de origem e quantidade mínima de dados transmitidos —
são muito desejáveis, a replicação é usada em muitas soluções de integração de dados, mesmo naquelas que não incluem distribuição física de
longa distância. Os utilitários de gerenciamento de banco de dados não requerem programação extensa, portanto, tendem a haver poucos bugs de
programação.
Os utilitários de replicação funcionam de maneira ideal quando os conjuntos de dados de origem e destino são cópias exatas um do outro. As
diferenças entre a origem e o destino apresentam riscos à sincronização. Se o alvo final não for uma cópia exata da fonte, é necessário manter uma
área de preparação para abrigar uma cópia exata das fontes. Isso requer uso de disco extra e possivelmente tecnologia de banco de dados extra.
As soluções de replicação de dados não são ideais se ocorrerem alterações nos dados em vários locais de cópia. Se for possível que a mesma
parte dos dados seja alterada em dois sites diferentes, existe o risco de os dados ficarem dessincronizados ou um dos sites pode ter suas alterações
substituídas sem aviso prévio. (Consulte o Capítulo 6.)
1.3.4 Arquivamento
Os dados usados com pouca frequência ou não usados ativamente podem ser movidos para uma estrutura ou armazenamento de dados alternativo
solução menos onerosa para a organização. As funções ETL podem ser usadas para transportar e possivelmente transformar os dados de
arquivamento nas estruturas de dados no ambiente de arquivamento. Use archives para armazenar dados de aplicativos que estão sendo retirados,
bem como dados de sistemas operacionais de produção que não são usados há muito tempo, para melhorar a eficiência operacional.
É fundamental monitorar a tecnologia de arquivamento para garantir que os dados ainda estejam acessíveis quando a tecnologia mudar.
Ter um arquivo em uma estrutura ou formato antigo ilegível por tecnologia mais recente pode ser um risco, especialmente para dados que ainda
são exigidos por lei. (Consulte o Capítulo 9.)
1.3.5 Formato de mensagem corporativa/ modelo canônico
Um modelo de dados canônico é um modelo comum usado por uma organização ou grupo de troca de dados que padroniza o formato no qual os
dados serão compartilhados. Em um padrão de design de interação de dados hub-and-spoke, todos os sistemas que desejam fornecer ou receber
dados interagem apenas com um hub central de informações. Os dados são transformados de ou para um sistema de envio ou recebimento com
base em um formato de mensagem comum ou corporativo para a organização (um modelo canônico). (Consulte o Capítulo 5.) O uso de um modelo
canônico limita o número de transformações de dados necessárias para qualquer

280 • DMBOK2
sistema ou organização trocando dados. Cada sistema precisa transformar dados apenas para e do modelo canônico central, em vez de para
o formato da multiplicidade de sistemas com os quais ele pode querer trocar dados.
Embora desenvolver e concordar com um formato de mensagem compartilhada seja uma tarefa importante, ter um modelo canônico pode
reduzir significativamente a complexidade da interoperabilidade de dados em uma empresa e, portanto, reduzir bastante o custo de suporte.
A criação e o gerenciamento do modelo de dados canônico comum para todas as interações de dados é um item complexo de sobrecarga
necessária na implementação de uma solução de integração de dados corporativos usando um modelo de interação hub-and-spoke. É
justificável no suporte ao gerenciamento das interações de dados entre mais de três sistemas e crítico para o gerenciamento de interações
de dados em ambientes de mais de 100 sistemas aplicativos.
1.3.6 Modelos de Interação
Os modelos de interação descrevem maneiras de fazer conexões entre sistemas para transferir dados.
1.3.6.1 Ponto a ponto
A grande maioria das interações entre sistemas que compartilham dados o fazem 'ponto a ponto'; eles passam dados diretamente um para o
outro. Este modelo faz sentido no contexto de um pequeno conjunto de sistemas. No entanto, torna-se rapidamente ineficiente e aumenta o
risco organizacional quando muitos sistemas exigem os mesmos dados das mesmas fontes.
• Impactos no processamento: se os sistemas de origem estiverem operacionais, a carga de trabalho do fornecimento de dados
pode afetar o processamento.
• Gerenciando interfaces: o número de interfaces necessárias em um modelo de interação ponto a ponto
aproxima o número de sistemas ao quadrado (s2 ). Uma vez construídas, essas interfaces precisam ser
mantida e apoiada. A carga de trabalho para gerenciar e suportar interfaces entre os sistemas pode
rapidamente se tornam maiores do que o suporte aos próprios sistemas.
• Potencial de inconsistência: problemas de design surgem quando vários sistemas exigem diferentes versões ou
formatos dos dados. O uso de múltiplas interfaces para obter dados levará a inconsistências nos dados
enviados para sistemas a jusante.
1.3.6.2 Hub-and-spoke
O modelo hub-and-spoke, uma alternativa ao ponto a ponto, consolida dados compartilhados (fisicamente ou virtualmente) em um hub de
dados central que muitos aplicativos podem usar. Todos os sistemas que desejam trocar dados o fazem por meio de um sistema central
comum de controle de dados, em vez de diretamente entre si (ponto a ponto). Data Warehouses, Data Marts, Operational Data Stores e hubs
de Master Data Management são os exemplos mais conhecidos de hubs de dados.

Os hubs fornecem visualizações consistentes dos dados com impacto limitado no desempenho dos sistemas de origem. Os hubs de dados
minimizam até mesmo o número de sistemas e extrações que devem acessar as fontes de dados, minimizando assim o impacto nos recursos do
sistema de origem. Adicionar novos sistemas ao portfólio requer apenas a construção de interfaces para o hub de dados. A interação hub-and-
spoke é mais eficiente e pode ser justificada pelo custo, mesmo que o número de sistemas envolvidos seja relativamente pequeno, mas torna-se
crítico para gerenciar um portfólio de sistemas na casa das centenas

ou milhares.
Os Enterprise Service Buses (ESB) são a solução de integração de dados para compartilhamento de dados quase em tempo real entre vários
sistemas, onde o hub é um conceito virtual do formato padrão ou do modelo canônico para compartilhamento de dados na organização.
Hub-and-spoke pode nem sempre ser a melhor solução. Alguma latência do modelo hub-and-spoke é inaceitável ou o desempenho é insuficiente.
O próprio hub cria sobrecarga em uma arquitetura hub-and-spoke. Uma solução ponto a ponto não exigiria o hub. No entanto, os benefícios do
hub superam as desvantagens da sobrecarga assim que três ou mais sistemas estão envolvidos no compartilhamento de dados. O uso do
padrão de design hub-and-spoke para o intercâmbio de dados pode reduzir drasticamente a proliferação de soluções de integração e
transformação de dados e, assim, simplificar drasticamente o suporte organizacional necessário.
1.3.6.3 Publicar - Assinar
Um modelo de publicação e assinatura envolve sistemas que enviam dados (publish) e outros sistemas que recebem dados (subscribe). Os
sistemas que fornecem dados são listados em um catálogo de serviços de dados e os sistemas que procuram consumir dados assinam esses
serviços. Quando os dados são publicados, os dados são enviados automaticamente para os assinantes.
Quando vários consumidores de dados desejam um determinado conjunto de dados ou dados em um determinado formato, desenvolver esse
conjunto de dados centralmente e disponibilizá-lo a todos que precisam garante que todos os constituintes recebam um conjunto de dados
consistente em tempo hábil.
1.3.7 Conceitos de Arquitetura DII
1.3.7.1 Acoplamento de Aplicação
O acoplamento descreve o grau em que dois sistemas estão entrelaçados. Dois sistemas fortemente acoplados geralmente têm uma interface
síncrona, onde um sistema aguarda uma resposta do outro. O acoplamento estreito representa uma operação mais arriscada: se um sistema não
estiver disponível, ambos estarão efetivamente indisponíveis, e o plano de continuidade de negócios para ambos deve ser o mesmo. (Consulte o
Capítulo 6.)
Sempre que possível, o acoplamento fraco é um design de interface preferido, onde os dados são passados entre sistemas sem esperar por uma
resposta e um sistema pode estar indisponível sem fazer com que o outro fique indisponível. Solto
282 • DMBOK2
o acoplamento pode ser implementado usando várias técnicas com serviços, APIs ou filas de mensagens. Figura 69
ilustra um possível projeto de acoplamento solto.
Processo A Processo B
Acoplamento apertado
API Serviço API
Processo A Processo B
Acoplamento solto
Figura 69 Acoplamento de Aplicação
A Arquitetura Orientada a Serviços usando um Enterprise Service Bus é um exemplo de um padrão de design de interação de dados
fracamente acoplado.
Onde os sistemas são fracamente acoplados, a substituição de sistemas no inventário de aplicativos pode teoricamente ser realizada sem
reescrever os sistemas com os quais eles interagem, pois os pontos de interação são bem definidos.
definiram.
1.3.7.2 Orquestração e Controles de Processo
Orquestração é o termo usado para descrever como vários processos são organizados e executados em um sistema. Todos os sistemas
que tratam mensagens ou pacotes de dados devem ser capazes de gerenciar a ordem de execução desses processos, a fim de preservar
a consistência e a continuidade.
Controles de processo são os componentes que garantem que o envio, entrega, extração e carregamento de dados sejam precisos e
completos. Um aspecto muitas vezes esquecido da arquitetura básica de movimentação de dados, os controles incluem:
• Registros de atividades do banco de dados
• Registros de trabalhos em lote
• Alertas
• Registros de exceção
• Gráficos de dependência de trabalho com opções de correção, respostas padrão
• Informações do 'relógio' do trabalho, como o horário dos trabalhos dependentes, a duração esperada dos trabalhos e o
tempo de janela de computação (disponível)

1.3.7.3 Integração de aplicativos empresariais (EAI)
Em um modelo de integração de aplicativos corporativos (EAI), os módulos de software interagem uns com os outros apenas por meio de chamadas
de interface bem definidas (interfaces de programação de aplicativos – APIs). Os armazenamentos de dados são atualizados apenas por seus
próprios módulos de software e outros softwares não podem acessar os dados em um aplicativo, mas apenas acessar por meio das APIs definidas.
O EAI é construído em conceitos orientados a objetos, que enfatizam a reutilização e a capacidade de substituir qualquer módulo sem impacto em
nenhum outro.
1.3.7.4 Barramento de Serviço Empresarial (ESB)
Um Enterprise Service Bus é um sistema que atua como intermediário entre sistemas, passando mensagens entre eles. Os aplicativos podem enviar
e receber mensagens ou arquivos usando o ESB e são encapsulados de outros processos existentes no ESB. Um exemplo de acoplamento fraco, o
ESB atua como o serviço entre as aplicações. (Veja a Figura 70.)
Processo
Aplicação 1 Orquestração Aplicação 2
Gerente
Barramento de serviço empresarial
Aplicação n Serviço n Serviço 1
Figura 70 Barramento de Serviço Corporativo
1.3.7.5 Arquitetura Orientada a Serviços (SOA)
A maioria das estratégias de integração de dados corporativos maduras utiliza a ideia de arquitetura orientada a serviços (SOA), onde a funcionalidade
de fornecer dados ou atualizar dados (ou outros serviços de dados) pode ser fornecida por meio de chamadas de serviço bem definidas entre
aplicativos. Com essa abordagem, os aplicativos não precisam ter interação direta ou conhecimento do funcionamento interno de outros aplicativos.
A SOA permite a independência de aplicativos e a capacidade de uma organização substituir sistemas sem precisar fazer alterações significativas
nos sistemas que fazem interface com eles.

284 • DMBOK2
O objetivo da arquitetura orientada a serviços é ter uma interação bem definida entre os módulos de software autocontidos. Cada módulo executa
funções (também conhecido como fornece serviços) para outros módulos de software ou para consumidores humanos. O conceito-chave é que
a arquitetura SOA fornece serviços independentes: o serviço não tem conhecimento prévio do aplicativo de chamada e a implementação do
serviço é uma caixa preta para o aplicativo de chamada. Uma arquitetura orientada a serviços pode ser implementada com várias tecnologias,
incluindo serviços da web, mensagens, APIs RESTful, etc. Os serviços geralmente são implementados como APIs (interfaces de programação
de aplicativos) que estão disponíveis para serem chamadas por sistemas de aplicativos (ou consumidores humanos). Um registro de API bem
definido descreve quais opções estão disponíveis, parâmetros que precisam ser fornecidos e informações resultantes que são fornecidas.
Os serviços de dados, que podem incluir a adição, exclusão, atualização e recuperação de dados, são especificados em um catálogo de serviços
disponíveis. Para atingir as metas corporativas de escalabilidade (suportar integrações entre todos os aplicativos da empresa sem usar
quantidades excessivas de recursos para isso) e reutilização (ter serviços que são aproveitados por todos os solicitantes de dados de um tipo),
um modelo de governança forte deve ser estabelecido em torno do design e registro de serviços e APIs. Antes de desenvolver novos serviços de
dados, é necessário garantir que já não exista nenhum serviço que possa fornecer os dados solicitados. Além disso, novos serviços precisam ser
projetados para atender a requisitos amplos, de modo que não sejam limitados à necessidade imediata, mas possam ser reutilizados.
1.3.7.6 Processamento de Eventos Complexos (CEP)
O processamento de eventos é um método de rastreamento e análise (processamento) de fluxos de informações (dados) sobre coisas que
acontecem (eventos) e derivar uma conclusão a partir deles. O processamento de eventos complexos (CEP) combina dados de várias fontes
para identificar eventos significativos (como oportunidades ou ameaças) para prever comportamento ou atividade e acionar automaticamente
uma resposta em tempo real, como sugerir um produto para um consumidor comprar.
As regras são definidas para orientar o processamento e o roteamento de eventos.
As organizações podem usar o processamento de eventos complexos para prever comportamento ou atividade e acionar automaticamente uma
resposta em tempo real. Eventos como leads de vendas, cliques na web, pedidos ou chamadas de atendimento ao cliente podem ocorrer nas
várias camadas de uma organização. Alternativamente, eles podem incluir notícias, mensagens de texto, postagens de mídia social, feeds do
mercado de ações, boletins de trânsito, boletins meteorológicos ou outros tipos de dados. Um evento também pode ser definido como uma
mudança de estado, quando uma medição excede um limite predefinido de tempo, temperatura ou outro valor.
O CEP apresenta alguns desafios de dados. Em muitos casos, a taxa na qual os eventos ocorrem torna impraticável recuperar os dados
adicionais necessários para interpretar o evento conforme ele ocorre. O processamento eficiente normalmente exige o pré-posicionamento de
alguns dados na memória do mecanismo CEP.
O suporte ao processamento de eventos complexos requer um ambiente que possa integrar grandes quantidades de dados de vários tipos.
Devido ao volume e variedade de dados geralmente envolvidos na criação de previsões, o processamento de eventos complexos geralmente
está vinculado ao Big Data. Muitas vezes, requer o uso de tecnologias que suportam requisitos de latência ultrabaixa, como processamento de
dados de streaming em tempo real e bancos de dados na memória. (Consulte o Capítulo 14.)
1.3.7.7 Federação e virtualização de dados
Quando os dados existem em armazenamentos de dados díspares, eles podem ser reunidos de outras maneiras além da integração física.
A Federação de Dados fornece acesso a uma combinação de armazenamentos de dados individuais, independentemente da estrutura. A
virtualização de dados permite que bancos de dados distribuídos, bem como vários armazenamentos de dados heterogêneos, sejam acessados e
visualizados como um único banco de dados. (Consulte o Capítulo 6.)
1.3.7.8 Dados como Serviço (DaaS)
Software-as-a-service (SaaS) é um modelo de entrega e licenciamento. Um aplicativo é licenciado para fornecer serviços, mas o software e os
dados estão localizados em um datacenter controlado pelo fornecedor do software, e não no datacenter da organização de licenciamento. Existem
conceitos semelhantes para fornecer várias camadas de infraestrutura de computação como serviço (TI como serviço, plataforma como serviço,
banco de dados como serviço).
Uma definição de Data-as-a-Service (DaaS) são dados licenciados de um fornecedor e fornecidos sob demanda, em vez de armazenados e
mantidos no data center da organização de licenciamento. Um exemplo comum inclui informações sobre os títulos vendidos em bolsa de valores e
preços associados (atuais e históricos).
Embora o Data-as-a-Service certamente se preste a fornecedores que vendem dados para partes interessadas em um setor, o conceito de 'serviço'
também é usado dentro de uma organização para fornecer dados corporativos ou serviços de dados para várias funções e sistemas operacionais.
As organizações de serviços fornecem um catálogo de serviços disponíveis, níveis de serviço e cronogramas de preços.
1.3.7.9 Integração baseada em nuvem
A integração baseada em nuvem (também conhecida como plataforma de integração como serviço ou IPaaS) é uma forma de integração de
sistemas fornecida como um serviço em nuvem que aborda dados, processos, arquitetura orientada a serviços (SOA) e casos de uso de integração
de aplicativos.
Antes do surgimento da computação em nuvem, a integração podia ser categorizada como interna ou business to business (B2B). Os requisitos de
integração interna são atendidos por meio de uma plataforma de middleware local e normalmente usam um barramento de serviço (ESB) para
gerenciar a troca de dados entre sistemas. A integração business-to-business é atendida por meio de gateways EDI (intercâmbio eletrônico de
dados) ou redes de valor agregado (VAN) ou mercados.
O advento dos aplicativos SaaS criou um novo tipo de demanda para integração de dados localizados fora do data center de uma organização,
atendidos por meio de integração baseada em nuvem. Desde seu surgimento, muitos desses serviços também desenvolveram a capacidade de
integrar aplicativos locais, bem como funcionar como gateways EDI.
As soluções de integração baseadas em nuvem geralmente são executadas como aplicativos SaaS nos data centers dos fornecedores e não nas
organizações que possuem os dados que estão sendo integrados. A integração baseada em nuvem envolve a interação com os dados do aplicativo
SaaS a serem integrados usando os serviços de interação SOA. (Consulte o Capítulo 6.)
286 • DMBOK2
1.3.8 Padrões de Troca de Dados
Os Padrões de Troca de Dados são regras formais para a estrutura de elementos de dados. A ISO (International Standards
Organization) desenvolveu padrões de troca de dados, assim como muitos setores. Uma especificação de troca de dados é um
modelo comum usado por uma organização ou grupo de troca de dados que padroniza o formato no qual os dados serão
compartilhados. Um padrão de troca define uma estrutura para transformações de dados necessárias para qualquer sistema ou
organização que troca dados. Os dados precisam ser mapeados para a especificação de troca.
Embora desenvolver e concordar com um formato de mensagem compartilhada seja uma tarefa importante, ter um formato de
troca ou layout de dados acordado entre sistemas pode simplificar significativamente a interoperabilidade de dados em uma
empresa, reduzindo o custo de suporte e permitindo uma melhor compreensão dos dados.
O National Information Exchange Model (NIEM) foi desenvolvido para trocar documentos e transações entre organizações
governamentais nos Estados Unidos. A intenção é que o emissor e o receptor da informação compartilhem um entendimento
comum e inequívoco do significado daquela informação. A conformidade com o NIEM garante que um conjunto básico de
informações seja bem compreendido e tenha o mesmo significado consistente em várias comunidades, permitindo assim a
interoperabilidade.
O NIEM usa Extensible Markup Language (XML) para definições de esquema e representação de elementos, o que permite que a
estrutura e o significado dos dados sejam definidos por meio de regras de sintaxe XML simples, mas cuidadosamente definidas.
2. Atividades de Integração de Dados
A integração e interoperabilidade de dados envolve obter dados onde são necessários, quando são necessários e na forma em
que são necessários. As atividades de integração de dados seguem um ciclo de vida de desenvolvimento. Eles começam com o
planejamento e passam pelo design, desenvolvimento, teste e implementação. Uma vez implementados, os sistemas integrados
devem ser gerenciados, monitorados e aprimorados.
2.1 Planejar e Analisar
2.1.1 Definir integração de dados e requisitos de ciclo de vida
Definir os requisitos de integração de dados envolve entender os objetivos de negócios da organização, bem como os dados
necessários e as iniciativas de tecnologia propostas para atender a esses objetivos. Também é necessário reunir quaisquer leis ou
regulamentos relevantes sobre os dados a serem usados. Algumas atividades podem precisar ser restritas devido ao conteúdo dos
dados, e saber com antecedência evitará problemas mais tarde. Os requisitos também devem levar em conta a política
organizacional sobre retenção de dados e outras partes do ciclo de vida dos dados. Muitas vezes, os requisitos para retenção de
dados diferem por domínio e tipo de dados.
Os requisitos de integração de dados e ciclo de vida geralmente são definidos por analistas de negócios, administradores de dados e
arquitetos em várias funções, incluindo TI, que desejam obter dados em um determinado local, em um determinado formato e integrados
a outros dados. Os requisitos determinarão o tipo de modelo de interação DII, que então determina a tecnologia e os serviços necessários
para atender aos requisitos.
O processo de definição de requisitos cria e revela Metadados valiosos. Esses metadados devem ser gerenciados durante todo o ciclo
de vida dos dados, desde a descoberta até as operações. Quanto mais completos e precisos forem os Metadados de uma organização,
melhor será sua capacidade de gerenciar os riscos e custos da integração de dados.
2.1.2 Realizar Descoberta de Dados
A descoberta de dados deve ser realizada antes do projeto. O objetivo da descoberta de dados é identificar fontes potenciais de dados
para o esforço de integração de dados. A descoberta identificará onde os dados podem ser adquiridos e onde podem ser integrados. O
processo combina uma pesquisa técnica, usando ferramentas que escaneiam os Metadados e/ou conteúdos reais nos conjuntos de
dados de uma organização, com expertise no assunto (ou seja, entrevistando pessoas que trabalham com os dados de interesse).
A descoberta também inclui avaliação de alto nível da qualidade dos dados, para determinar se os dados são adequados para o
propósitos da iniciativa de integração. Essa avaliação requer não apenas revisar a documentação existente, entrevistar especialistas no
assunto, mas também verificar as informações coletadas em relação aos dados reais por meio de perfis de dados ou outras análises.
(Consulte a Seção 2.1.4.) Em quase todos os casos, haverá discrepâncias entre o que se acredita sobre um conjunto de dados e o que
realmente é verdade.
A descoberta de dados produz ou adiciona a um inventário de dados organizacionais. Esse inventário deve ser mantido em um repositório
de metadados. Garanta que esse inventário seja mantido como parte padrão dos esforços de integração: adicione ou remova
armazenamentos de dados, alterações na estrutura de documentos.
A maioria das organizações precisa integrar dados de seus sistemas internos. No entanto, as soluções de integração de dados também
podem envolver a aquisição de dados de fora da organização. Há uma quantidade vasta e crescente de informações valiosas disponíveis
gratuitamente ou de fornecedores de dados. Dados de fontes externas podem ser extremamente valiosos quando integrados com dados
de dentro de uma organização. No entanto, adquirir e integrar dados externos exige planejamento.
2.1.3 Linhagem de Dados do Documento
O processo de descoberta de dados também descobrirá informações sobre como os dados fluem por uma organização. Essas
informações podem ser usadas para documentar a linhagem de dados de alto nível: como os dados em análise são adquiridos ou criados
pela organização, para onde são movidos e alterados dentro da organização e como os dados são usados pela organização para análise,
tomada de decisão. fazer ou desencadear eventos. A linhagem detalhada pode incluir as regras de acordo com as quais os dados são
alterados e a frequência das alterações.

288 • DMBOK2
A análise da linhagem pode identificar as atualizações necessárias à documentação dos sistemas em uso. ETL com código personalizado e outros objetos de
manipulação de dados legados devem ser documentados para garantir que a organização possa analisar o impacto de quaisquer alterações no fluxo de dados.
O processo de análise também pode identificar oportunidades de melhorias no fluxo de dados existente. Por exemplo, descobrir que o código pode ser atualizado
para uma simples chamada para uma função em uma ferramenta ou pode ser descartado como não mais relevante. Às vezes, uma ferramenta antiga está
realizando uma transformação que é desfeita posteriormente no processo. Encontrar e remover essas ineficiências pode ajudar muito no sucesso do projeto e
na capacidade geral de uma organização de usar seus dados.
2.1.4 Dados do Perfil
Compreender o conteúdo e a estrutura dos dados é essencial para uma integração bem-sucedida dos dados. A criação de perfis de dados contribui para esse
fim. A estrutura e o conteúdo de dados reais sempre diferem do que é assumido. Às vezes as diferenças são pequenas; outras vezes são grandes o suficiente
para inviabilizar um esforço de integração. A criação de perfil pode ajudar as equipes de integração a descobrir essas diferenças e usar esse conhecimento para
tomar melhores decisões sobre fornecimento e design. Se o perfil de dados for ignorado, as informações que devem influenciar o design não serão descobertas
até testes ou operações.
O perfil básico envolve a análise de:
• Formato de dados conforme definido nas estruturas de dados e inferido a partir dos dados reais
• Preenchimento de dados, incluindo os níveis de dados nulos, em branco ou padrão
• Valores de dados e quão próximos eles correspondem a um conjunto definido de valores válidos
• Padrões e relacionamentos internos ao conjunto de dados, como campos relacionados e regras de cardinalidade
• Relacionamentos com outros conjuntos de dados
É necessário um perfil mais extenso dos conjuntos de dados de origem e destino em potencial para entender como os dados atendem aos requisitos da iniciativa
de integração de dados específica. Crie o perfil das origens e dos destinos para entender como transformar os dados para atender aos requisitos.
Um objetivo da criação de perfil é avaliar a qualidade dos dados. Avaliar a adequação dos dados para um uso específico requer a documentação das regras de
negócios e a medição de quão bem os dados atendem a essas regras de negócios. A avaliação da precisão requer a comparação com um conjunto definitivo de
dados que foi determinado como correto. Esses conjuntos de dados nem sempre estão disponíveis, portanto, a precisão da medição pode não ser possível,
especialmente como parte de um esforço de criação de perfil.
Assim como na descoberta de dados de alto nível, a criação de perfil de dados inclui a verificação de suposições sobre os dados em relação aos dados reais.
Capture resultados de perfis de dados em um repositório de Metadados para uso em projetos posteriores e use o que é aprendido com o processo para melhorar
a precisão dos Metadados existentes (Olson, 2003). (Consulte o Capítulo 13.)
O requisito de perfil de dados deve ser equilibrado com os regulamentos de segurança e privacidade de uma organização. (Consulte o Capítulo 7.)
2.1.5 Coletar Regras de Negócios
As regras de negócios são um subconjunto crítico de requisitos. Uma regra de negócios é uma declaração que define ou restringe um aspecto do
processamento de negócios. As regras de negócios destinam-se a afirmar a estrutura de negócios ou a controlar ou influenciar o comportamento do negócio.
As regras de negócios se enquadram em uma das quatro categorias: definições de termos de negócios, fatos que relacionam termos entre si, restrições ou
asserções de ação e derivações.
Use regras de negócios para dar suporte à integração e interoperabilidade de dados em vários pontos, para:
• Avaliar dados em conjuntos de dados de origem e destino em potencial
• Direcionar o fluxo de dados na organização
• Monitorar os dados operacionais da organização
• Direcione quando acionar eventos e alertas automaticamente
Para o Master Data Management, as regras de negócios incluem regras de correspondência, regras de mesclagem, regras de sobrevivência e regras de
confiança. Para arquivamento de dados, armazenamento de dados e outras situações em que um armazenamento de dados está em uso, as regras de negócios
também incluem regras de retenção de dados.
A coleta de regras de negócios também é chamada de coleta de regras ou mineração de regras de negócios. O analista de negócios ou administrador de
dados pode extrair as regras da documentação existente (como casos de uso, especificações ou código do sistema) ou também pode organizar workshops
e entrevistas com especialistas no assunto (SMEs), ou ambos.
2.2 Projetar soluções de integração de dados
2.2.1 Arquitetura de Integração de Dados de Projeto
As soluções de integração de dados devem ser especificadas tanto no nível da empresa quanto no nível da solução individual (consulte o Capítulo 4). Ao
estabelecer padrões empresariais, a organização economiza tempo na implementação de soluções individuais, pois as avaliações e negociações foram
realizadas antes da necessidade. Uma abordagem corporativa economiza dinheiro no custo de licenças por meio de descontos para grupos e nos custos de
operação de um conjunto consistente e menos complexo de soluções. Os recursos operacionais que suportam e fazem backup uns dos outros podem fazer
parte de um pool compartilhado.
Projete uma solução para atender aos requisitos, reutilizando o máximo de integração de dados e
Componentes de interoperabilidade possível. Uma arquitetura de solução indica as técnicas e tecnologias que serão utilizadas. Incluirá um inventário das
estruturas de dados envolvidas (tanto persistentes quanto transitivas, existentes e necessárias), uma indicação da orquestração e frequência do fluxo de
dados, preocupações regulatórias e de segurança e remediação e preocupações operacionais em torno de backup e recuperação, disponibilidade e arquivo
de dados e
retenção.
290 • DMBOK2
2.2.1.1 Selecione o Modelo de Interação
Determine qual modelo de interação ou combinação atenderá aos requisitos – hub-and-spoke, ponto a ponto ou publicação-assinatura. Se os
requisitos corresponderem a um padrão de interação existente já implementado, reutilize o sistema existente o máximo possível, para reduzir
os esforços de desenvolvimento.
2.2.1.2 Serviços de Dados de Projeto ou Padrões de Troca
Crie ou reutilize fluxos de integração existentes para mover os dados. Esses serviços de dados devem ser complementares a serviços de
dados semelhantes existentes, mas tome cuidado para não criar vários serviços quase idênticos, pois a solução de problemas e o suporte se
tornam cada vez mais difíceis se os serviços proliferarem. Se um fluxo de dados existente puder ser modificado para dar suporte a várias
necessidades, talvez valha a pena fazer essa alteração em vez de criar um novo serviço.
Qualquer projeto de especificação de troca de dados deve começar com padrões da indústria ou outros padrões de troca já existentes. Quando
possível, faça qualquer alteração nos padrões existentes de forma genérica o suficiente para ser útil a outros sistemas; ter padrões de troca
específicos que se relacionam apenas a uma troca tem os mesmos problemas que ponto a ponto
conexões.
2.2.2 Modelos de Hubs de Dados, Interfaces, Mensagens e Serviços de Dados
As estruturas de dados necessárias na integração e interoperabilidade de dados incluem aquelas nas quais os dados persistem, como hubs
de gerenciamento de dados mestre, data warehouses e marts e armazenamentos de dados operacionais, e aquelas que são transitórias e
usadas apenas para mover ou transformar dados, como interfaces, layouts de mensagens e modelos canônicos. Ambos os tipos devem ser
modelados. (Consulte o Capítulo 5.)
2.2.3 Mapear fontes de dados para destinos
Quase todas as soluções de integração de dados incluem a transformação de dados de estruturas de origem para destino. O mapeamento de
origens para destinos envolve especificar as regras para transformar dados de um local e formato para outro.
Para cada atributo mapeado, uma especificação de mapeamento
• Indica o formato técnico da origem e destino
• Especifica as transformações necessárias para todos os pontos intermediários entre a origem e o destino
• Descreve como cada atributo em um armazenamento de dados de destino final ou intermediário será preenchido
• Descreve se os valores dos dados precisam ser transformados; por exemplo, procurando o valor de origem em
uma tabela que indica o valor alvo apropriado
• Descreve quais cálculos são necessários

A transformação pode ser realizada em uma programação em lote ou acionada pela ocorrência de um evento em tempo real. Pode ser realizado
através da persistência física do formato alvo ou através da apresentação virtual dos dados no formato alvo.
2.2.4 Orquestração de Dados de Projeto
O fluxo de dados em uma solução de integração de dados deve ser projetado e documentado. A orquestração de dados é o padrão de fluxos de
dados do início ao fim, incluindo etapas intermediárias, necessárias para concluir a transformação
e/ou transação.
A orquestração de integração de dados em lote indicará a frequência da movimentação e transformação de dados. A integração de dados em lote
geralmente é codificada em um agendador que aciona o início em um determinado horário, periodicidade ou quando ocorre um evento. A
programação pode incluir várias etapas com dependências.
A orquestração de integração de dados em tempo real geralmente é acionada por um evento, como dados novos ou atualizados. A orquestração
de integração de dados em tempo real geralmente é mais complexa e implementada em várias ferramentas. Pode não ser
linear por natureza.
2.3 Desenvolver soluções de integração de dados
2.3.1 Desenvolver serviços de dados
Desenvolva serviços para acessar, transformar e entregar dados conforme especificado, combinando com o modelo de interação selecionado.
Ferramentas ou conjuntos de fornecedores são usados com mais frequência para implementar soluções de integração de dados, como
transformação de dados, gerenciamento de dados mestres, armazenamento de dados etc. O uso de ferramentas consistentes ou conjuntos de
fornecedores padrão em toda a organização para esses vários propósitos pode simplificar o suporte operacional e reduzir os custos operacionais
habilitando soluções de suporte compartilhadas.
2.3.2 Desenvolver fluxos de dados
Os fluxos de dados de integração ou ETL geralmente serão desenvolvidos dentro de ferramentas especializadas para gerenciar esses fluxos de
forma proprietária. Os fluxos de dados em lote serão desenvolvidos em um agendador (geralmente o agendador padrão corporativo) que gerenciará
a ordem, a frequência e a dependência da execução das peças de integração de dados que foram desenvolvidas.
Os requisitos de interoperabilidade podem incluir o desenvolvimento de mapeamentos ou pontos de coordenação entre armazenamentos de dados.
Algumas organizações usam um ESB para assinar dados criados ou alterados na organização e outros aplicativos para publicar alterações nos
dados. O barramento de serviço corporativo sondará os aplicativos constantemente para ver se eles têm algum dado para publicar e entregar a eles
dados novos ou alterados para os quais eles se inscreveram.

292 • DMBOK2
O desenvolvimento de fluxos de integração de dados em tempo real envolve o monitoramento de eventos que devem acionar a execução de serviços
para adquirir, transformar ou publicar dados. Isso geralmente é implementado em uma ou várias tecnologias proprietárias e é melhor implementado com
uma solução que pode gerenciar a operação entre tecnologias.
2.3.3 Desenvolver abordagem de migração de dados
Os dados precisam ser movidos quando novos aplicativos são implementados ou quando os aplicativos são retirados ou mesclados.
Esse processo envolve a transformação dos dados para o formato do aplicativo receptor. Quase todos os projetos de desenvolvimento de aplicativos
envolvem alguma migração de dados, mesmo que tudo o que esteja envolvido seja o preenchimento de Dados de Referência. A migração não é um
processo único, pois precisa ser executado para as fases de teste, bem como para a implementação final.
Os projetos de migração de dados são frequentemente subestimados ou subprojetados, porque os programadores são instruídos a simplesmente mover
os dados; eles não se envolvem nas atividades de análise e design necessárias para a integração de dados.
Quando os dados são migrados sem uma análise adequada, eles geralmente parecem diferentes dos dados recebidos por meio do processamento
normal. Ou os dados migrados podem não funcionar com o aplicativo conforme previsto. Os dados de perfil de aplicativos operacionais principais
geralmente destacarão os dados que foram migrados de uma ou mais gerações de sistemas operacionais anteriores e não atendem aos padrões dos
dados que entram no conjunto de dados por meio do código do aplicativo atual. (Consulte o Capítulo 6.)
2.3.4 Desenvolver uma abordagem de publicação
Os sistemas em que dados críticos são criados ou mantidos precisam disponibilizar esses dados para outros sistemas da organização. Dados novos ou
alterados devem ser enviados por aplicativos de produção de dados para outros sistemas (especialmente hubs de dados e barramentos de dados
corporativos) no momento da alteração de dados (orientada a eventos) ou em um período periódico.

cronograma.
A melhor prática é definir definições de mensagens comuns (modelo canônico) para os vários tipos de dados na organização e permitir que os
consumidores de dados (aplicativos ou indivíduos) que tenham autoridade de acesso apropriada se inscrevam para receber notificação de quaisquer
alterações nos dados de interesse.
2.3.5 Desenvolver fluxos de processamento de eventos complexos
O desenvolvimento de soluções complexas de processamento de eventos requer:
• Preparação dos dados históricos sobre um indivíduo, organização, produto ou mercado e pré
população dos modelos preditivos
• Processamento do fluxo de dados em tempo real para preencher totalmente o modelo preditivo e identificar
eventos (oportunidades ou ameaças)
• Executando a ação acionada em resposta à previsão

A preparação e o pré-processamento dos dados históricos necessários no modelo preditivo podem ser realizados em processos batch
noturnos ou quase em tempo real. Normalmente, alguns dos modelos preditivos podem ser preenchidos antes do evento desencadeador,
como identificar quais produtos geralmente são comprados juntos na preparação para sugerir um item adicional para compra.
Alguns fluxos de processamento acionam uma resposta a cada evento no fluxo em tempo real, como adicionar um item a um carrinho de
compras; outros fluxos de processamento tentam identificar eventos particularmente significativos que desencadeiam uma ação, como
uma tentativa suspeita de cobrança fraudulenta em um cartão de crédito.
A resposta à identificação de um evento significativo pode ser tão simples quanto o envio de um aviso ou tão complexa quanto o envio
automático de forças armadas.
2.3.6 Manter Metadados DII
Conforme observado anteriormente (consulte a Seção 2.1), uma organização criará e descobrirá Metadados valiosos durante o processo
de desenvolvimento de soluções DII. Esses metadados devem ser gerenciados e mantidos para garantir a compreensão adequada dos
dados no sistema e para evitar a necessidade de redescobri-los para soluções futuras. Metadados confiáveis melhoram a capacidade de
uma organização de gerenciar riscos, reduzir custos e obter mais valor de seus dados.
Documente as estruturas de dados de todos os sistemas envolvidos na integração de dados como origem, destino ou preparação. Inclua
definições de negócios e definições técnicas (estrutura, formato, tamanho), bem como a transformação de dados entre os armazenamentos
de dados persistentes. Quer os metadados de integração de dados sejam armazenados em documentos ou em um repositório de
metadados, eles não devem ser alterados sem um processo de revisão e aprovação de negócios e técnicos
A maioria dos fornecedores de ferramentas ETL empacota seus repositórios de metadados com funcionalidades adicionais que permitem
a supervisão de governança e administração. Se o repositório de Metadados for utilizado como uma ferramenta operacional, pode até
incluir Metadados operacionais sobre quando os dados foram copiados e transformados entre sistemas.
De particular importância para as soluções DII é o registro SOA, que fornece acesso controlado a um catálogo em evolução de informações
sobre os serviços disponíveis para acessar e usar os dados e funcionalidades em um aplicativo.
2.4 Implementar e Monitorar
Ative os serviços de dados que foram desenvolvidos e testados. O processamento de dados em tempo real requer monitoramento em
tempo real para problemas. Estabeleça parâmetros que indiquem possíveis problemas com o processamento, bem como a notificação
direta de problemas. O monitoramento automatizado e humano para problemas deve ser estabelecido, especialmente à medida que a
complexidade e o risco das respostas acionadas aumentam. Há casos, por exemplo, em que problemas com algoritmos automatizados
de negociação de títulos financeiros desencadearam ações que afetaram mercados inteiros ou organizações falidas.
294 • DMBOK2
Os recursos de interação de dados devem ser monitorados e atendidos no mesmo nível de serviço que o aplicativo de destino ou consumidor de
dados mais exigente.
3. Ferramentas
3.1 Mecanismo de Transformação de Dados/Ferramenta ETL
Um mecanismo de transformação de dados (ou ferramenta ETL) é a principal ferramenta na caixa de ferramentas de integração de dados, central
para todos os programas de integração de dados corporativos. Essas ferramentas geralmente suportam a operação, bem como o design dos dados
atividades de transformação.
Existem ferramentas extremamente sofisticadas para desenvolver e executar ETL, seja em lote ou em tempo real, física ou virtualmente. Para
soluções ponto a ponto de uso único, o processamento de integração de dados é frequentemente implementado por meio de codificação
personalizada. As soluções de nível empresarial geralmente exigem o uso de ferramentas para realizar esse processamento de maneira padrão
em toda a organização.
As considerações básicas na seleção de um mecanismo de transformação de dados devem incluir se é necessário lidar com a funcionalidade em
lote e em tempo real, e se os dados não estruturados e estruturados precisam ser acomodados, pois existem as ferramentas mais maduras para o
processamento orientado a lote de apenas dados estruturados.
3.2 Servidor de virtualização de dados
Os mecanismos de transformação de dados geralmente realizam extração, transformação e carregamento físico dos dados; no entanto, os
servidores de virtualização de dados realizam extração, transformação e integração de dados virtualmente. Os servidores de virtualização de dados
podem combinar dados estruturados e não estruturados. Um data warehouse é frequentemente uma entrada para um servidor de virtualização de
dados, mas um servidor de virtualização de dados não substitui o data warehouse nas informações corporativas
arquitetura.
3.3 Barramento de Serviço Empresarial
Um barramento de serviço corporativo (ESB) refere-se a um modelo de arquitetura de software e a um tipo de middleware orientado a mensagens
usado para implementar mensagens quase em tempo real entre armazenamentos de dados heterogêneos, aplicativos e servidores que residem
na mesma organização. A maioria das soluções internas de integração de dados que precisam ser executadas com mais frequência do que
diariamente usam essa arquitetura e essa tecnologia. Mais comumente, um ESB é usado em formato assíncrono para permitir o fluxo livre de
dados. Um ESB também pode ser usado de forma síncrona em

situações.
O barramento de serviço corporativo implementa filas de mensagens de entrada e saída em cada um dos sistemas que participam
do intercâmbio de mensagens com um adaptador ou agente instalado em cada ambiente. O processador central para o ESB
geralmente é implementado em um servidor separado dos outros sistemas participantes. O processador mantém o controle de quais
sistemas têm interesse em quais tipos de mensagens. O processador central pesquisa continuamente cada sistema participante
para mensagens de saída e deposita mensagens de entrada na fila de mensagens para tipos de mensagens assinadas e mensagens
que foram endereçadas diretamente a esse sistema.
sistema.
Esse modelo é chamado de 'quase em tempo real' porque os dados podem levar alguns minutos para ir do sistema de envio ao
sistema de recebimento. Este é um modelo fracamente acoplado e o sistema de envio de dados não aguardará a confirmação de
recebimento e atualização do sistema de recebimento antes de continuar o processamento.
3.4 Mecanismo de Regras de Negócios
Muitas soluções de integração de dados dependem de regras de negócios. Uma forma importante de Metadados, essas regras
podem ser usadas na integração básica e em soluções que incorporam processamento de eventos complexos para permitir que
uma organização responda a eventos quase em tempo real. Um mecanismo de regras de negócios que permite que usuários não
técnicos gerenciem regras de negócios implementadas por software é uma ferramenta muito valiosa que possibilitará a evolução da
solução a um custo menor, pois um mecanismo de regras de negócios pode suportar alterações em modelos preditivos sem
alterações no código técnico. Por exemplo, modelos que preveem o que um cliente pode querer comprar podem ser definidos como
regras de negócios em vez de mudanças de código.
3.5 Ferramentas de modelagem de dados e processos
As ferramentas de modelagem de dados devem ser usadas para projetar não apenas o destino, mas também as estruturas de
dados intermediárias necessárias nas soluções de integração de dados. A estrutura das mensagens ou fluxos de dados que passam
entre sistemas e organizações, e geralmente não são persistentes, deve, no entanto, ser modelada. O fluxo de dados entre sistemas
e organizações também deve ser projetado, assim como processos de eventos complexos.
3.6 Ferramenta de Perfil de Dados
A criação de perfil de dados envolve a análise estatística do conteúdo do conjunto de dados para entender o formato, integridade,
consistência, validade e estrutura dos dados. Toda integração de dados e desenvolvimento de interoperabilidade deve incluir uma
avaliação detalhada de possíveis fontes e alvos de dados para determinar se os dados reais atendem às necessidades da solução
proposta. Como a maioria dos projetos de integração envolve uma quantidade significativa de dados, o meio mais eficiente de
realizar essa análise é usar uma ferramenta de criação de perfil de dados. (Consulte a Seção 2.1.4 e o Capítulo 13.)
296 • DMBOK2
3.7 Repositório de Metadados
Um repositório de metadados contém informações sobre os dados em uma organização, incluindo estrutura de dados, conteúdo e regras
de negócios para gerenciar os dados. Durante os projetos de integração de dados, um ou mais repositórios de metadados podem ser
usados para documentar a estrutura técnica e o significado comercial dos dados que estão sendo originados, transformados e direcionados.
Normalmente, as regras de transformação de dados, linhagem e processamento usadas pelas ferramentas de integração de dados também
são armazenadas em um repositório de Metadados, assim como as instruções para processos agendados, como gatilhos e frequência.
Cada ferramenta geralmente tem seu próprio repositório de metadados. Conjuntos de ferramentas do mesmo fornecedor podem compartilhar
um repositório de metadados. Um repositório de Metadados pode ser designado como ponto central para consolidar os dados das diversas
ferramentas operacionais. (Consulte o Capítulo 12.)
4. Técnicas
Várias das técnicas importantes para projetar soluções de integração de dados são descritas nos Conceitos essenciais deste capítulo. Os
objetivos básicos são manter os aplicativos acoplados livremente, limitar o número de interfaces desenvolvidas e que requerem
gerenciamento usando uma abordagem hub-and-spoke e criar interfaces padrão (ou canônicas).
Todas as organizações já possuem alguma forma de DII – portanto, a avaliação de prontidão/risco deve ser em torno da implementação da
ferramenta de integração corporativa ou do aprimoramento de recursos para permitir a interoperabilidade.
A implementação de soluções de integração de dados corporativos geralmente é justificada pelo custo com base na implementação entre
muitos sistemas. Projete uma solução de integração de dados corporativos para dar suporte à movimentação de dados entre muitos
aplicativos e organizações, e não apenas a primeira a ser implementada.
Muitas organizações gastam seu tempo retrabalhando soluções existentes em vez de agregar valor. Concentre-se na implementação de
soluções de integração de dados onde não existe integração limitada ou nenhuma atualmente, em vez de substituir as soluções de
integração de dados de trabalho por uma solução corporativa comum em toda a organização.
Certos projetos de dados podem justificar uma solução de integração de dados focada apenas em um aplicativo específico, como um
data warehouse ou um hub de gerenciamento de dados mestre. Nesses casos, qualquer uso adicional da solução de integração de
dados agrega valor ao investimento, pois o primeiro uso do sistema já atingiu a justificativa.
As equipes de suporte de aplicativos preferem gerenciar as soluções de integração de dados localmente. Eles perceberão que o custo
de fazer isso é menor do que alavancar uma solução corporativa. Os fornecedores de software que dão suporte a essas equipes
também preferem aproveitar as ferramentas de integração de dados que vendem. Portanto, é necessário patrocinar a implementação
de um programa de integração de dados corporativos de um nível que tenha autoridade suficiente sobre o design da solução e a compra
de tecnologia, como a arquitetura corporativa de TI. Além disso, pode ser necessário incentivar a participação de sistemas de aplicativos
por meio de incentivos positivos, como o financiamento centralizado da tecnologia de integração de dados, e por meio de incentivos
negativos, como a recusa em aprovar a implementação de novas tecnologias alternativas de integração de dados.
Projetos de desenvolvimento que implementam novas tecnologias de integração de dados frequentemente se concentram na tecnologia
e perdem o foco nos objetivos de negócios. É necessário garantir que a implementação da solução de integração de dados mantenha o
foco nos objetivos e requisitos de negócios, incluindo certificar-se de que alguns participantes em cada projeto sejam orientados a
negócios ou aplicativos, e não apenas especialistas em ferramentas de integração de dados.
As organizações devem determinar se a responsabilidade pelo gerenciamento das implementações de integração de dados é
centralizada ou se reside nas equipes de aplicativos descentralizadas. As equipes locais entendem os dados em seus aplicativos. As
equipes centrais podem desenvolver um conhecimento profundo de ferramentas e tecnologias. Muitas organizações desenvolvem um
Centro de Excelência especializado no projeto e implantação das soluções de integração de dados corporativos.
As equipes locais e centrais colaboram para desenvolver soluções conectando um aplicativo a uma solução de integração de dados
corporativos. A equipe local deve assumir a responsabilidade principal de gerenciar a solução e resolver quaisquer problemas, escalando
para o Centro de Excelência, se necessário.
As soluções de integração de dados são frequentemente percebidas como puramente técnicas; no entanto, para entregar valor com
sucesso, eles devem ser desenvolvidos com base em profundo conhecimento do negócio. As atividades de análise e modelagem de
dados devem ser realizadas por recursos orientados ao negócio. O desenvolvimento de um modelo de mensagem canônico, ou padrão
consistente de como os dados são compartilhados na organização, requer um grande comprometimento de recursos que deve envolver
recursos de modelagem de negócios, bem como recursos técnicos. Revise todo o design e as alterações de mapeamento de
transformação de dados com especialistas no assunto de negócios em cada sistema envolvido.
6. Governança DII
As decisões sobre o design de mensagens de dados, modelos de dados e regras de transformação de dados têm um impacto direto na
capacidade de uma organização de usar seus dados. Essas decisões devem ser orientadas para os negócios. Enquanto existem muitos
298 • DMBOK2
considerações técnicas na implementação de regras de negócios, uma abordagem puramente técnica para DII pode levar a erros nos
mapeamentos e transformações de dados à medida que os dados entram, entram e saem de uma organização.
As partes interessadas do negócio são responsáveis por definir as regras de como os dados devem ser modelados e transformados.
As partes interessadas de negócios devem aprovar as alterações em qualquer uma dessas regras de negócios. As regras devem ser
capturadas como Metadados e consolidadas para análise entre empresas. Identificar e verificar os modelos preditivos e definir quais ações
devem ser acionadas automaticamente pelas previsões também são funções de negócios.
Sem a confiança de que a integração ou o design interoperável funcionará conforme prometido, de maneira segura e confiável, não pode
haver valor comercial efetivo. No DII, o cenário dos controles de governança para apoiar a confiança pode ser complexo e detalhado. Uma
abordagem é determinar quais eventos acionam revisões de governança (exceções ou eventos críticos). Mapeie cada gatilho para revisões
que envolvam os órgãos de governança. Os acionadores de eventos podem fazer parte do Ciclo de Vida de Desenvolvimento do Sistema
(SDLC) nos Stage Gates ao passar de uma fase para outra ou como parte de User Stories. Por exemplo, as listas de verificação de
conformidade do projeto de arquitetura podem incluir perguntas como: Se possível, você está usando o ESB e as ferramentas? Houve uma
busca por serviços reutilizáveis?
Os controles podem vir de rotinas de gerenciamento orientadas por governança, como revisões obrigatórias de modelos, auditoria de
metadados, distribuição de entregas e aprovações necessárias para alterações nas regras de transformação.
Nos Contratos de Nível de Serviço e nos planos de Continuidade de Negócios/Recuperação de Desastres, as soluções de integração de
dados operacionais em tempo real devem ser incluídas na mesma camada de backup e recuperação do sistema mais crítico ao qual fornecem
dados.
As políticas precisam ser estabelecidas para garantir que a organização se beneficie de uma abordagem corporativa para DII. Por exemplo,
as políticas podem ser implementadas para garantir que os princípios SOA sejam seguidos, que novos serviços sejam criados somente após
uma revisão dos serviços existentes e que todos os dados que fluem entre os sistemas passem pela empresa
ônibus de serviço.
6.1 Contratos de Compartilhamento de Dados
Antes do desenvolvimento de interfaces ou do fornecimento de dados eletronicamente, desenvolva um acordo de compartilhamento de dados
ou memorando de entendimento (MOU) que estipula as responsabilidades e o uso aceitável dos dados a serem trocados, aprovado pelos
administradores de dados comerciais dos dados em questão. Os acordos de compartilhamento de dados devem especificar o uso e acesso
antecipado aos dados, restrições de uso, bem como os níveis de serviço esperados, incluindo tempos de funcionamento do sistema e tempos
de resposta necessários. Esses acordos são especialmente críticos para setores regulamentados ou quando informações pessoais ou
seguras estão envolvidas.
6.2 DII e Linhagem de Dados
A linhagem de dados é útil para o desenvolvimento de soluções DII. Muitas vezes, também é necessário que os consumidores de dados
usem dados, mas está se tornando ainda mais importante à medida que os dados são integrados entre as organizações. Governança é
necessários para garantir que o conhecimento das origens e movimentação dos dados seja documentado. Os acordos de compartilhamento de dados
podem estipular limitações ao uso de dados e, para cumpri-las, é necessário saber para onde os dados se movem e persistem. Existem padrões de
conformidade emergentes (por exemplo, o regulamento Solvência II na Europa) que exigem que as organizações sejam capazes de descrever a
origem de seus dados e como eles foram alterados à medida que passaram por vários sistemas.
Além disso, as informações de linhagem de dados são necessárias ao fazer alterações nos fluxos de dados. Essas informações devem ser
gerenciadas como parte crítica dos Metadados da solução. A linhagem de dados para frente e para trás (ou seja, onde os dados foram usados e de
onde eles vieram) é fundamental como parte da análise de impacto necessária ao fazer alterações nas estruturas de dados, fluxos de dados ou
processamento de dados.
6.3 Métricas de Integração de Dados
Para medir a escala e os benefícios da implementação de soluções de integração de dados, inclua métricas de disponibilidade, volume, velocidade,
custo e uso:
• Disponibilidade de dados
o Disponibilidade dos dados solicitados
• Volumes de dados e velocidade
o Volumes de dados transportados e transformados
o Volumes de dados analisados
o Velocidade de transmissão
o Latência entre atualização de dados e disponibilidade
o Latência entre o evento e a ação acionada
o Tempo para disponibilidade de novas fontes de dados
• Custos e Complexidade da Solução
o Custo de desenvolvimento e gerenciamento de soluções
o Facilidade de aquisição de novos dados
o Complexidade de soluções e operações
o Número de sistemas usando soluções de integração de dados

Aiken, P. e Allen, DM XML em Gerenciamento de Dados. Morgan Kaufmann, 2004. Impresso.
Bahga, Arshdeep e Vijay Madisetti. Computação em Nuvem: Uma Abordagem Prática. Plataforma de Publicação Independente CreateSpace,
2013. Imprimir.
Bobak, Angelo R. Conectando os Dados: Técnicas de Integração de Dados para Construir um Armazenamento de Dados Operacionais (ODS).
300 • DMBOK2
Brackett, Michael. Integração de recursos de dados: Entendendo e resolvendo um recurso de dados diferente. Technics Publications, LLC,
2012. Imprimir.
Carstensen, Jared, Bernard Golden e JP Morgenthal. Computação em Nuvem - Avaliando os Riscos. Publicação de Governança de TI, 2012. Imprimir.
Di Martino, Beniamino, Giuseppina Cretella, and Antonio Esposito. Portabilidade e interoperabilidade na nuvem: problemas e tendências atuais.
Springer, 2015. Impresso. SpringerBriefs em Ciência da Computação.
Doan, AnHai, Alon Halevy e Zachary Ives. Princípios de Integração de Dados. Morgan Kaufmann, 2012. Impresso.
Erl, Thomas, Ricardo Puttini e Zaigham Mahmood. Computação em Nuvem: Conceitos, Tecnologia e Arquitetura. Prentice Hall, 2013. Impresso. A
Prentice Hall Service Technology Ser. de Thomas Erl.
Ferguson, M. Maximizando o valor comercial da virtualização de dados. Enterprise Data World, 2012. Web. http://bit.ly/2sVAsui.
Giordano, Anthony David. Data Integration Blueprint e Modelagem: Técnicas para uma Arquitetura Escalável e Sustentável. IBM Press,
2011. Imprimir.
Haley, Barba. Melhores práticas de computação em nuvem para gerenciar e medir processos para computação sob demanda, aplicativos e
data centers na nuvem com SLAs. Emereo Publishing, 2008. Impresso.
Hohpe, Gregor e Bobby Woolf. Padrões de integração empresarial: projetando, construindo e implantando soluções de mensagens. Addison-
Wesley Professional, 2003. Impressão.
Inmon, W. Construindo o Data Warehouse. 4ª edição. Wiley, 2005. Impresso.
Inmon, W., Claudia Imhoff, and Ryan Sousa. A Fábrica de Informações Corporativas. 2ª edição. Wiley 2001, Impresso.
Jamsa, Kris. Computação em nuvem: SaaS, PaaS, IaaS, virtualização, modelos de negócios, dispositivos móveis, segurança e muito mais. Jones e
Bartlett Learning, 2012. Imprimir.
Kavis, Michael J. Arquitetando a Nuvem: Decisões de Design para Modelos de Serviço de Computação em Nuvem (SaaS, PaaS e IaaS).
Wiley, 2014. Impresso. Wiley CIO.
Kimball, Ralph e Margy Ross. O Data Warehouse Toolkit: O Guia Completo para Modelagem Dimensional. 2ª edição.
Linthicum, David S. Computação em nuvem e convergência SOA em sua empresa: um guia passo a passo. Addison-Wesley Professional, 2009.
Impresso.
Linthicum, David S. Integração de aplicativos corporativos. Addison-Wesley Professional, 1999. Print.
Linthicum, David S. Integração de aplicativos de próxima geração: de informações simples a serviços da Web. Addison-Wesley Professional, 2003.
Impressão.
Loshin, David. Gerenciamento de dados mestre. Morgan Kaufmann, 2009. Impresso.
MAJKIC, Zoran. Teoria de Integração de Big Data: Teoria e Métodos de Mapeamento de Banco de Dados, Linguagens de Programação e
Semântica. Springer, 2014. Impresso. Textos em Ciência da Computação.
Mather, Tim, Subra Kumaraswamy e Shahed Latif. Segurança e privacidade na nuvem: uma perspectiva corporativa sobre riscos e conformidade.
O'Reilly Media, 2009. Impresso. Teoria na prática.
Reis, Jorge. Arquiteturas de aplicativos em nuvem: construindo aplicativos e infraestrutura na nuvem. O'Reilly Media, 2009. Impresso. Teoria na
Prática (O'Reilly).
Reeves, abril. Gerenciando Dados em Movimento: Técnicas e Tecnologias de Boas Práticas de Integração de Dados. Morgan Kaufmann, 2013.
Impresso. A Série Morgan Kaufmann sobre Business Intelligence.
ROTON, João. Computação em nuvem explicada: manual de implementação para empresas. Imprensa recursiva, 2009. Impressão.
Sarkar, Pushpack. Dados como um serviço: uma estrutura para fornecer serviços de dados corporativos reutilizáveis. Wiley-IEEE Computer Society
Pr, 2015. Imprimir.
SERES, Jonathan. Integração de dados 200 segredos de sucesso - 200 perguntas mais frequentes sobre integração de dados - o que você precisa
saber. Publicação Emereo, 2014. Kindle.
Sherman, Rick. Guia de Business Intelligence: Da Integração de Dados à Análise. Morgan Kaufmann, 2014. Impresso.
Departamento de Comércio dos EUA. Diretrizes sobre Segurança e Privacidade em Computação em Nuvem Pública. Plataforma de Publicação
Independente CreateSpace, 2014. Imprimir.
Van der Lans, Rick. Virtualização de Dados para Sistemas de Business Intelligence: Revolucionando a Integração de Dados para Data
Warehouses. Morgan Kaufmann, 2012. Impresso. A Série Morgan Kaufmann sobre Business Intelligence.
Zhao, Liang, Sherif Sakr, Anna Liu e Athman Bouguettaya. Gerenciamento de dados em nuvem. Springer; 2014. Imprimir.
CAPÍTULO 9
Gestão de Documentos e Conteúdos
Dados
Modelagem de dados
Qualidade dos dados
& Operações
Dados Dados
Metadados

& O negócio
Interoperabilidade
Inteligência
& Mestre & Contente
Dados Gestão

1. Introdução
D
Ocument and Content Management envolve o controle da captura, armazenamento, acesso e uso de dados e
informações armazenadas fora dos bancos de dados relacionais.44 Seu foco é manter a integridade e
permitindo o acesso a documentos e outras informações não estruturadas ou semiestruturadas que o tornam
44 Os tipos de dados não estruturados evoluíram desde o início dos anos 2000, à medida que a capacidade de capturar e armazenar
informações digitais cresceu. O conceito de dados não estruturados continua a se referir a dados que não são predefinidos por meio de um
modelo de dados, seja relacional ou não.
303
304 • DMBOK2
aproximadamente equivalente ao gerenciamento de operações de dados para bancos de dados relacionais. No entanto, também
tem drivers estratégicos. Em muitas organizações, os dados não estruturados têm uma relação direta com os dados estruturados.
As decisões de gestão sobre esse conteúdo devem ser aplicadas de forma consistente. Além disso, assim como outros tipos de
dados, espera-se que documentos e conteúdo não estruturado sejam seguros e de alta qualidade. Garantir a segurança e a
qualidade requer governança, arquitetura confiável e metadados bem gerenciados.
Gestão de Documentos e Conteúdos

Definição: Atividades de planejamento, implementação e controle para gerenciamento do ciclo de vida de dados e
informações encontrados em qualquer forma ou meio.
Objetivos:
1. Cumprir as obrigações legais e as expectativas dos clientes em relação à gestão de Registros.

2. Assegurar o armazenamento, recuperação e uso eficaz e eficiente de Documentos e Conteúdo.
3. Assegurar capacidades de integração entre Conteúdo estruturado e não estruturado.
O negócio
Motoristas

• Estratégia de negócio 1. Plano de Gerenciamento do Ciclo de Vida (P) • Conteúdo e
• 1. Plano para Gerenciamento de Registros Registros
Estratégia de TI
• 2. Desenvolva uma estratégia de conteúdo
Retenção legal Gestão
2. Crie políticas de manipulação de conteúdo, incluindo a
requisitos abordagem de descoberta eletrônica
Estratégia
• Arquivo de texto •
3. Definir Arquitetura da Informação (D) Política e
• Formato eletrônico 4. Gerenciar o Ciclo de Vida (O) procedimento
Arquivo 1. Capturar e Gerenciar Registros e • Repositório de Conteúdo
• Conteúdo (O)
arquivo de papel impresso • Registro gerenciado em
2. Reter, descartar e arquivar registros
• Mídia social muitos formatos de mídia
e Conteúdo (O)
fluxo • Trilha de auditoria e registro
5. Publicar e entregar conteúdo (O)

• • Administrador de dados • Usuário empresarial
Equipe jurídica
• Equipe de negócios • • usuário de TI
Profissional de gerenciamento de dados
• equipe de TI •
Equipe de gerenciamento de registros • Regulamentação do governo
•
Parte externa • Equipe de gerenciamento de conteúdo agência
• Equipe de auditoria
• Equipe de desenvolvimento web
• Bibliotecários • Cliente externo
Técnico
Motoristas

• • •
Marcação de metadados Software de produtividade de escritório Métrica de auditoria de conformidade
• • • Retorno do investimento
Marcação e troca de dados Gerenciamento de conteúdo corporativo
formato •
sistema Métrica de uso
• • •
Mapeamento de dados Vocabulário/metadados controlados KPI de gerenciamento de registros
• ferramenta
•
Storyboard KPI de descoberta eletrônica
•
Infográficos • Wiki de gerenciamento de conhecimento • Métrica do programa ECM
• Ferramenta de mídia visual • Métrica operacional de ECM
• Mídia social
•
Tecnologia de descoberta eletrônica
Figura 71 Diagrama de Contexto: Documentos e Conteúdo

GESTÃO DE DOCUMENTOS E CONTEÚDOS • 305
Os principais impulsionadores de negócios para gerenciamento de documentos e conteúdo incluem conformidade regulatória, capacidade de
responder a solicitações de litígio e descoberta eletrônica e requisitos de continuidade de negócios. Um bom gerenciamento de registros também
pode ajudar as organizações a se tornarem mais eficientes. Sites bem organizados e pesquisáveis que resultam do gerenciamento eficaz de
ontologias e outras estruturas que facilitam a busca ajudam a melhorar a satisfação de clientes e funcionários.
Leis e regulamentos exigem que as organizações mantenham registros de certos tipos de atividades. A maioria das organizações também
possui políticas, padrões e práticas recomendadas para manutenção de registros. Os registros incluem documentos em papel e informações
armazenadas eletronicamente (ESI). Um bom gerenciamento de registros é necessário para a continuidade dos negócios. Também permite que
uma organização responda em caso de litígio.
E-discovery é o processo de encontrar registros eletrônicos que possam servir como evidência em uma ação legal. À medida que a tecnologia
para criar, armazenar e usar dados se desenvolveu, o volume de ESI aumentou exponencialmente.
Alguns desses dados, sem dúvida, acabarão em litígios ou solicitações regulatórias.
A capacidade de uma organização de responder a uma solicitação de descoberta eletrônica depende de quão proativamente ela gerenciou
registros como e-mail, bate-papos, sites e documentos eletrônicos, bem como dados brutos de aplicativos e metadados.
Big Data tornou-se um impulsionador para e-discovery mais eficiente, retenção de registros e informações sólidas
governança.
O ganho de eficiência é um impulsionador para melhorar o gerenciamento de documentos. Os avanços tecnológicos no gerenciamento de
documentos estão ajudando as organizações a otimizar processos, gerenciar fluxos de trabalho, eliminar tarefas manuais repetitivas e permitir
a colaboração. Essas tecnologias têm os benefícios adicionais de permitir que as pessoas localizem, acessem e compartilhem documentos
mais rapidamente. Eles também podem impedir que os documentos sejam perdidos. Isso é muito importante para a descoberta eletrônica. O
dinheiro também é economizado ao liberar espaço no armário de arquivos e reduzir os custos de manuseio de documentos.
Os objetivos da implementação das melhores práticas em torno do Gerenciamento de Documentos e Conteúdos incluem:
• Garantir a recuperação e uso eficaz e eficiente de dados e informações em formatos não estruturados
• Garantir recursos de integração entre dados estruturados e não estruturados
• Cumprimento das obrigações legais e expectativas do cliente
A gestão de documentos e conteúdos segue estes princípios orientadores:
• Todos em uma organização têm um papel a desempenhar na proteção do futuro da organização. Todos devem
criar, usar, recuperar e descartar registros de acordo com as políticas e procedimentos estabelecidos.
306 • DMBOK2
• Os especialistas no manuseio de registros e conteúdo devem estar totalmente engajados na política e no planejamento.
As práticas regulatórias e recomendadas podem variar significativamente com base no setor industrial e na jurisdição legal.
Mesmo que os profissionais de gerenciamento de registros não estejam disponíveis para a organização, todos podem ser treinados para
entender os desafios, as melhores práticas e os problemas. Uma vez treinados, os administradores de negócios e outros podem colaborar
em uma abordagem eficaz para o gerenciamento de registros.
Em 2009, a ARMA International, uma associação profissional sem fins lucrativos para gerenciamento de registros e informações, publicou
um conjunto de Princípios de Manutenção de Registros Geralmente Aceitáveis® (GARP)45 que descreve como os registros comerciais
devem ser mantidos. Ele também fornece uma estrutura de manutenção de registros e governança de informações com métricas associadas.
A primeira frase de cada princípio é indicada abaixo. Maiores explicações podem ser encontradas no
Site da ARMA.
• Princípio de Responsabilidade: Uma organização deve designar um executivo sênior para
indivíduos, adotar políticas e processos para orientar a equipe e garantir a auditabilidade do programa.
• Princípio da Integridade: Um programa de governança da informação deve ser construído para que os registros e
informações geradas ou gerenciadas por ou para a organização têm uma garantia razoável e adequada
de autenticidade e confiabilidade.
• Princípio de Proteção: Um programa de governança da informação deve ser construído para garantir um
nível razoável de proteção a informações pessoais ou que de outra forma requeiram proteção.
• Princípio de Conformidade: Um programa de governança da informação deve ser construído para cumprir
leis aplicáveis e outras autoridades vinculantes, bem como as políticas da organização.
• Princípio de Disponibilidade: Uma organização deve manter suas informações de uma maneira que garanta
recuperação oportuna, eficiente e precisa de suas informações.
• Princípio de Retenção: Uma organização deve reter suas informações por um tempo apropriado, tomando
em conta todos os requisitos operacionais, legais, regulamentares e fiscais, e os de todos os

autoridades.
• Princípio de Disposição: Uma organização deve fornecer disposição segura e apropriada de
informações de acordo com suas políticas e leis aplicáveis, regulamentos e outras

autoridades.
• Princípio da Transparência: Uma organização deve documentar suas políticas, processos e atividades,
incluindo seu programa de governança da informação, de uma maneira que esteja disponível e compreendida pela equipe
e as partes interessadas apropriadas.
45 ARMA International, Princípios de manutenção de registros geralmente aceitos pela ARMA®, http://bit.ly/2tNF1E4.
1.3.1 Conteúdo
Um documento é para conteúdo o que um balde é para água: um recipiente. Conteúdo refere-se aos dados e informações
dentro do arquivo, documento ou site. O conteúdo geralmente é gerenciado com base nos conceitos representados pelos documentos, bem como
no tipo ou status dos documentos. O conteúdo também tem um ciclo de vida. Em sua forma completa, algum conteúdo se torna uma questão de
registro para uma organização. Os registros oficiais são tratados de forma diferente de outros
contente.
1.3.1.1 Gerenciamento de Conteúdo
O gerenciamento de conteúdo inclui os processos, técnicas e tecnologias para organizar, categorizar e estruturar recursos de informação para que
possam ser armazenados, publicados e reutilizados de várias maneiras.
O ciclo de vida do conteúdo pode ser ativo, com mudanças diárias por meio de processos controlados de criação e modificação; ou pode ser mais
estático com apenas pequenas alterações ocasionais. O conteúdo pode ser gerenciado formalmente (estritamente armazenado, gerenciado,
auditado, retido ou descartado) ou informalmente por meio de atualizações ad hoc.
O gerenciamento de conteúdo é particularmente importante em sites e portais, mas as técnicas de indexação com base em palavras-chave e
organização com base em taxonomias podem ser aplicadas em plataformas tecnológicas. Quando o escopo do gerenciamento de conteúdo inclui
toda a empresa, ele é chamado de Enterprise Content Management (ECM).
1.3.1.2 Metadados de Conteúdo
Metadados são essenciais para gerenciar dados não estruturados, tanto o que é tradicionalmente considerado como conteúdo e documentos
quanto o que agora entendemos como 'Big Data'. Sem Metadados, não é possível inventariar e organizar o conteúdo. Metadados para conteúdo de
dados não estruturados são baseados em:
• Formato: Muitas vezes o formato dos dados determina o método para acessar os dados (como índice eletrônico
para dados eletrônicos não estruturados).
• Capacidade de pesquisa: se as ferramentas de pesquisa já existem para uso com dados não estruturados relacionados.
• Autodocumentação: Se os Metadados são autodocumentados (como em sistemas de arquivos). Nesse caso,
o desenvolvimento é mínimo, pois a ferramenta existente é simplesmente adotada.
• Padrões existentes: se os métodos e padrões existentes podem ser adotados ou adaptados (como na biblioteca
catálogos).
• Assuntos de conteúdo: as coisas que as pessoas provavelmente estarão procurando.

308 • DMBOK2
• Requisitos: Necessidade de rigor e detalhes na recuperação (como no setor farmacêutico ou nuclear
indústria46). Portanto, metadados detalhados em nível de conteúdo podem ser necessários, e uma ferramenta capaz de
a marcação de conteúdo pode ser necessária.
Geralmente, a manutenção de Metadados para dados não estruturados torna-se a manutenção de uma referência cruzada entre vários padrões
locais e o conjunto oficial de Metadados da empresa. Os gerentes de registros e os profissionais de metadados reconhecem que existem métodos
incorporados de longo prazo em toda a organização para documentos, registros e outros conteúdos que devem ser retidos por muitos anos, mas
que esses métodos geralmente são caros para reorganizar. Em algumas organizações, uma equipe centralizada mantém padrões de referência
cruzada entre índices de gerenciamento de registros, taxonomias e até mesmo tesauros variantes.
1.3.1.3 Modelagem de Conteúdo
A modelagem de conteúdo é o processo de conversão de conceitos de conteúdo lógico em tipos de conteúdo, atributos e tipos de dados com
relacionamentos. Um atributo descreve algo específico e distinguível sobre o conteúdo ao qual se relaciona. Um tipo de dados restringe o tipo de
dados que o atributo pode conter, permitindo validação e processamento.
As técnicas de gerenciamento de metadados e modelagem de dados são usadas no desenvolvimento de um modelo de conteúdo.
Existem dois níveis de modelagem de conteúdo. A primeira é no nível do produto de informação, que cria uma entrega real como um site. A
segunda está no nível do componente, que detalha ainda mais os elementos que compõem o modelo do produto de informação. O nível de
detalhe no modelo depende da granularidade desejada para reutilização e

estrutura.
Os modelos de conteúdo suportam a estratégia de conteúdo orientando a criação de conteúdo e promovendo a reutilização. Eles suportam
conteúdo adaptável, que não tem formato e é independente do dispositivo. Os modelos tornam-se as especificações para o conteúdo
implementado em estruturas como definição de esquema XML (XSDs), formulários ou folhas de estilo.
1.3.1.4 Métodos de Entrega de Conteúdo
O conteúdo precisa ser modular, estruturado, reutilizável e independente de dispositivo e plataforma. Os métodos de entrega incluem páginas da
web, aplicativos impressos e móveis, bem como eBooks com vídeo e áudio interativos. A conversão de conteúdo em XML no início do fluxo de
trabalho oferece suporte à reutilização em diferentes canais de mídia.
Os sistemas de entrega de conteúdo são 'push', 'pull' ou interativos.
• Push: em um sistema de entrega push, os usuários escolhem o tipo de conteúdo entregue a eles em um
horário determinado. A distribuição envolve uma parte criando o conteúdo publicado em muitos lugares.
46 Essas indústrias são responsáveis por fornecer evidências de como certos tipos de materiais são manuseados. Os
fabricantes de farmácias, por exemplo, devem manter registros detalhados de como um composto surgiu e foi testado e
manuseado, antes de poder ser usado pelas pessoas.
Really Simple Syndication (RSS) é um exemplo de um mecanismo de entrega de conteúdo push. Ele distribui conteúdo (ou seja, um
feed) para distribuir notícias e outros conteúdos da web mediante solicitação.
• Pull: Em um sistema de entrega pull, os usuários extraem o conteúdo pela Internet. Um exemplo de sistema puxado
é quando os compradores visitam lojas de varejo online.
• Interativo: métodos de entrega de conteúdo interativo, como ponto de venda eletrônico de terceiros (EPOS)
aplicativos ou sites voltados para o cliente (por exemplo, para inscrição), precisam trocar grandes volumes de dados em tempo real
dados entre aplicativos corporativos. As opções para compartilhar dados entre aplicativos incluem Enterprise
Integração de Aplicativos (EAI), Captura de Dados Alterados, Integração de Dados e EII. (Consulte o Capítulo 8.)
1.3.2 Vocabulários Controlados
Um vocabulário controlado é uma lista definida de termos explicitamente permitidos usados para indexar, categorizar, marcar, classificar e recuperar
conteúdo por meio de navegação e pesquisa. Um vocabulário controlado é necessário para organizar sistematicamente documentos, registros e
conteúdo. Os vocabulários variam em complexidade de listas simples ou listas de escolha, anéis de sinônimos ou listas de autoridade, taxonomias e,
as mais complexas, tesauros e ontologias. Um exemplo de vocabulário controlado é o Dublin Core, usado para catalogar publicações.
Políticas definidas controlam quem adiciona termos ao vocabulário (por exemplo, um taxonomista ou indexador ou bibliotecário).
Os bibliotecários são particularmente treinados na teoria e no desenvolvimento de vocabulários controlados. Os usuários da lista só podem aplicar
termos da lista para sua área de assunto de escopo. (Consulte o Capítulo 10.)
Idealmente, os vocabulários controlados devem estar alinhados com os nomes e definições das entidades em um modelo de dados conceitual
corporativo. Uma abordagem de baixo para cima para coletar termos e conceitos é compilá-los em uma folksonomia, que é uma coleção de termos e
conceitos obtidos por meio de marcação social.
Os vocabulários controlados constituem um tipo de Dados de Referência. Como outros Dados de Referência, seus valores e definições precisam ser
gerenciados para serem completos e atualizados. Eles também podem ser considerados metadados, pois ajudam a explicar e apoiar o uso de outros
dados. Eles são descritos neste capítulo porque o Gerenciamento de Documentos e Conteúdos são casos de uso primários para vocabulários
controlados.
1.3.2.1 Gerenciamento de Vocabulário
Como os vocabulários evoluem com o tempo, eles exigem gerenciamento. ANSI/NISO Z39.19-2005 é um padrão americano, que fornece diretrizes
para a construção, formato e gerenciamento de vocabulários controlados monolíngues, descreve o gerenciamento de vocabulário como uma forma de
“melhorar a eficácia dos sistemas de armazenamento e recuperação de informações, navegação na web sistemas e outros ambientes que buscam
identificar e
310 • DMBOK2
localizar o conteúdo desejado por meio de algum tipo de descrição usando a linguagem. O objetivo principal do controle de vocabulário é
alcançar consistência na descrição de objetos de conteúdo e facilitar a recuperação.”47
O gerenciamento de vocabulário é a função de definir, fornecer, importar e manter qualquer dado
vocabulário. Questões-chave para permitir que o gerenciamento de vocabulário se concentre em usos, consumidores, padrões e
manutenção:
• Que conceitos de informação este vocabulário apoiará?
• Quem é o público para este vocabulário? Que processos eles suportam? Que papéis eles desempenham?
• Por que o vocabulário é necessário? Ele suportará um aplicativo, gerenciamento de conteúdo ou análise?
• Qual órgão decisório é responsável por designar termos preferenciais?
• Que vocabulários existentes os diferentes grupos usam para classificar esta informação? Onde eles estão
localizado? Como eles foram criados? Quem são seus especialistas no assunto? Existe alguma segurança ou
preocupações de privacidade para qualquer um deles?
• Existe um padrão existente que possa atender a essa necessidade? Existem preocupações de usar um padrão externo
vs. interno? Com que frequência o padrão é atualizado e qual é o grau de mudança de cada atualização?
Os padrões são acessíveis em um formato fácil de importar/manter, de maneira econômica?
Os resultados desta avaliação permitirão a integração dos dados. Eles também ajudarão a estabelecer padrões internos, incluindo vocabulário
preferencial associado por meio de funções de gerenciamento de relacionamento de prazo e prazo.
Se esse tipo de avaliação não for feito, vocabulários preferenciais ainda seriam definidos em uma organização, exceto que seriam feitos em
silos, projeto por projeto, levando a um maior custo de integração e maiores chances de problemas de qualidade de dados. (Consulte o Capítulo
13.)
1.3.2.2 Exibições de Vocabulário e Vocabulário Microcontrolado
Uma visão de vocabulário é um subconjunto de um vocabulário controlado, cobrindo uma gama limitada de tópicos dentro do domínio do
vocabulário controlado. Visões de vocabulário são necessárias quando o objetivo é usar um vocabulário padrão contendo um grande número
de termos, mas nem todos os termos são relevantes para alguns consumidores da informação. Por exemplo, uma exibição que contém apenas
termos relevantes para uma Unidade de Negócios de Marketing não conteria termos relevantes apenas para Finanças.
As visualizações de vocabulário aumentam a usabilidade da informação, limitando o conteúdo ao que é apropriado para os usuários.
Construa uma visualização de vocabulário de termos de vocabulário preferidos manualmente ou por meio de regras de negócios que atuam em
dados de termos de vocabulário preferidos ou Metadados. Defina regras para quais termos são incluídos em cada visualização de vocabulário.
47 http://bit.ly/2sTaI2h.
Um vocabulário microcontrolado é uma visão de vocabulário contendo termos altamente especializados não presentes no vocabulário geral.
Um exemplo de vocabulário microcontrolado é um dicionário médico com subconjuntos para disciplinas médicas. Tais termos devem mapear
a estrutura hierárquica do amplo vocabulário controlado. Um vocabulário microcontrolado é internamente consistente no que diz respeito às
relações entre os termos.
Vocabulários microcontrolados são necessários quando o objetivo é aproveitar um vocabulário padrão, mas o conteúdo não é suficiente e há
a necessidade de gerenciar acréscimos/extensões para um grupo específico de consumidores de informação. A construção de um vocabulário
microcontrolado começa com as mesmas etapas de uma visualização de vocabulário, mas também inclui a adição ou associação de termos
preferenciais adicionais que são diferenciados dos termos preferenciais pré-existentes, indicando uma fonte diferente.
1.3.2.3 Prazos e Listas de Escolha
Listas de termos são apenas isso: listas. Eles não descrevem as relações entre os termos. Listas de seleção, listas suspensas da web e
listas de opções de menu em sistemas de informação usam listas de termos. Eles fornecem pouca ou nenhuma orientação ao usuário, mas
ajudam a controlar a ambiguidade, reduzindo o domínio dos valores.
As listas de seleção geralmente são enterradas em aplicativos. O software de gerenciamento de conteúdo pode ajudar a transformar listas de
opções e vocabulários controlados em listas de opções pesquisáveis na página inicial. Essas listas de seleção são gerenciadas como facetas
taxonomias dentro do software.
1.3.2.4 Gestão de Prazos
O padrão ANSI/NISO Z39.19-2005 define um termo como “Uma ou mais palavras que designam um conceito”.48 Assim como os vocabulários,
os termos individuais também requerem gerenciamento. O Gerenciamento de Termos inclui especificar como os termos são definidos e
classificados inicialmente e como essas informações são mantidas quando começam a ser usadas em diferentes sistemas. Os termos devem
ser gerenciados por meio de processos de governança. Os administradores podem precisar arbitrar para garantir que o feedback das partes
interessadas seja considerado antes que os termos sejam alterados. Z39.19 define um termo preferido como um de dois ou mais sinônimos
ou variantes lexicais selecionados como um termo para inclusão em um vocabulário controlado.
O gerenciamento de termos inclui o estabelecimento de relacionamentos entre termos dentro de um vocabulário controlado. Existem três
tipos de relacionamentos:
• Relação de termos equivalentes: Uma relação entre termos em um vocabulário controlado que
leva a um ou mais termos a serem usados em vez do termo a partir do qual a referência cruzada é feita. Isto é
o mapeamento de termos mais comumente usado em funções de TI, indicando um termo ou valor de um sistema ou
vocabulário é o mesmo que outro, então as tecnologias de integração podem realizar seu mapeamento e
estandardização.
48 http://bit.ly/2sTaI2h.
312 • DMBOK2
• Relacionamento hierárquico: Um relacionamento entre termos em um vocabulário controlado que
descreve relacionamentos mais amplos (gerais) a mais estreitos (específicos) ou todo-parte.
• Relação de termos relacionados: um termo que está associado de forma associativa, mas não hierarquicamente, a outro termo em
um vocabulário controlado.
1.3.2.5 Anéis de Sinônimos e Listas de Autoridade
Um anel de sinônimos é um conjunto de termos com significado aproximadamente equivalente. Um anel de sinônimos permite que os
usuários que pesquisam em um dos termos acessem o conteúdo relacionado a qualquer um dos termos. O desenvolvimento manual de anéis
de sinônimos é para recuperação, não para indexação. Eles oferecem controle de sinônimos e tratam sinônimos e termos quase sinônimos
igualmente. O uso ocorre onde o ambiente de indexação possui um vocabulário não controlado ou onde não há indexação. Os mecanismos
de pesquisa e os diferentes registros de metadados têm anéis de sinônimos (consulte o Capítulo 13.) Eles podem ser difíceis de implementar
em interfaces de usuário.
Uma lista de autoridade é um vocabulário controlado de termos descritivos projetados para facilitar a recuperação de informações dentro de
um domínio ou escopo específico. O tratamento do termo não é igual, pois está dentro de um anel de sinônimos; em vez disso, um termo é
preferido e os outros são variantes. Um arquivo de autoridade faz referência cruzada de sinônimos e variantes para cada termo para orientar
o usuário de um termo não preferencial para um termo preferencial. A lista pode ou não conter definições desses termos. As listas de
autoridade devem ter gerentes designados. Podem ter estrutura. Um exemplo são os cabeçalhos de assunto da Biblioteca do Congresso dos
EUA. (Consulte a Seção 1.3.2.1.)
1.3.2.6 Taxonomias
Taxonomia é um termo genérico que se refere a qualquer classificação ou vocabulário controlado. O exemplo mais conhecido de taxonomia
é o sistema de classificação para todos os seres vivos desenvolvido pelo biólogo sueco Linnaeus.
No gerenciamento de conteúdo, uma taxonomia é uma estrutura de nomenclatura que contém um vocabulário controlado usado para delinear
tópicos e permitir sistemas de navegação e pesquisa. As taxonomias ajudam a reduzir a ambiguidade e a controlar os sinônimos.
Uma taxonomia hierárquica pode conter diferentes tipos de relacionamentos pai/filho úteis para indexadores e pesquisadores. Tais taxonomias
são usadas para criar interfaces do tipo drill-down.
As taxonomias podem ter diferentes estruturas:
• Uma taxonomia plana não possui relacionamentos entre o conjunto de categorias controladas. Todas as categorias são
igual. Isso é semelhante a uma lista; por exemplo, uma lista de países.
• Uma taxonomia hierárquica é uma estrutura em árvore onde os nós são relacionados por uma regra. Uma hierarquia tem pelo menos
dois níveis e é bidirecional. Subir na hierarquia expande a categoria; descer refina
a categoria. Um exemplo é a geografia, do continente ao endereço.

• Uma polihierarquia é uma estrutura em forma de árvore com mais de uma regra de relação de nós. Nós filhos podem ter
vários pais. Esses pais também podem compartilhar avós. Assim, os caminhos de travessia podem ser
complicado e deve-se tomar cuidado para evitar possíveis travessias inválidas: subir na árvore a partir de um nó que
refere-se ao pai, mas não a um dos avós. Estruturas de polihierarquia complicadas podem ser
melhor servido com uma taxonomia de facetas.
• Uma taxonomia de faceta se parece com uma estrela onde cada nó está associado ao nó central. As facetas são
atributos do objeto no centro. Um exemplo é Metadados, onde cada atributo (criador, título,
direitos de acesso, palavras-chave, versão, etc.) é uma faceta de um objeto de conteúdo.
• Uma taxonomia de rede usa estruturas hierárquicas e de facetas. Quaisquer dois nós na taxonomia de rede
estabelecer vínculos com base em suas associações. Um exemplo é um mecanismo de recomendação (…se você gostou
isso, você também pode gostar disso…). Outro exemplo é um dicionário de sinônimos.
Com a quantidade de dados sendo gerados, mesmo com as taxonomias mais bem definidas, são necessárias regras automatizadas de sinalização,
correção e roteamento. Se as taxonomias não forem mantidas, elas serão subutilizadas ou produzirão resultados incorretos. Isso cria o risco de que
entidades e funcionários regidos pelos regulamentos aplicáveis estejam fora de conformidade. Por exemplo, em uma taxonomia financeira, o termo
preferido pode ser 'Pós-emprego'. O conteúdo pode vir de sistemas que o classificam como 'Pós-emprego', 'Pós-emprego' ou até mesmo pós-
aposentadoria. Para dar suporte a esses casos, devem ser definidos anéis de sinônimos apropriados e relacionamentos de termos relacionados (US
GAAP, 2008).
As organizações desenvolvem suas próprias taxonomias para formalizar o pensamento coletivo sobre tópicos específicos de seu trabalho.
As taxonomias são particularmente importantes para apresentar e encontrar informações em sites, pois muitos mecanismos de pesquisa dependem
de correspondências exatas de palavras e só podem encontrar itens marcados ou usando as mesmas palavras da mesma maneira.
1.3.2.7 Esquemas de Classificação e Marcação
Esquemas de classificação são códigos que representam vocabulário controlado. Esses esquemas geralmente são hierárquicos e podem ter palavras
associadas a eles, como o Sistema Decimal de Dewey e a Classificação da Biblioteca do Congresso dos EUA (classes principais e subclasses). Uma
taxonomia baseada em números, o Dewey Decimal System também é uma expressão multilíngue para codificação de assunto, pois os números
podem ser 'decodificados' em qualquer idioma.
Folksonomias são esquemas de classificação para termos e nomes de conteúdo online obtidos por meio de marcação social.
Usuários e grupos individuais os usam para anotar e categorizar conteúdo digital. Eles normalmente não têm estruturas hierárquicas ou termos
preferenciais. As folksonomies geralmente não são consideradas autoritárias ou aplicadas à indexação de documentos porque os especialistas não
as compilam. No entanto, por refletirem diretamente o vocabulário dos usuários, oferecem o potencial de melhorar a recuperação de informações. Os
termos de folkonomia podem ser vinculados a

vocabulários controlados.
314 • DMBOK2
1.3.2.8 Tesouros
Um tesauro é um tipo de vocabulário controlado usado para recuperação de conteúdo. Ele combina características de listas de sinônimos e taxonomias.
Um tesauro fornece informações sobre cada termo e sua relação com outros termos.
Os relacionamentos são hierárquicos (pai/filho ou amplo/mais restrito), associativo ('ver também') ou equivalente (sinônimo ou usado/usado de). Os
sinônimos devem ser aceitavelmente equivalentes em todos os cenários de contexto. Um tesauro também pode incluir definições, citações, etc.
Thesauri pode ser usado para organizar conteúdo não estruturado, descobrir relacionamentos entre conteúdo de diferentes mídias, melhorar a navegação
no site e otimizar a pesquisa. Quando um usuário insere um termo, um sistema pode usar um tesauro não exposto (um não disponível diretamente para
o usuário) para direcionar automaticamente a pesquisa para um termo semelhante.
Alternativamente, o sistema pode sugerir termos relacionados com os quais um usuário pode continuar a pesquisa.
Os padrões que fornecem orientação sobre a criação de tesauros incluem ISO 25964 e ANSI/NISO Z39.19. 10.2.2.1.5 Ontologias.
1.3.2.9 Ontologia
Uma ontologia é um tipo de taxonomia que representa um conjunto de conceitos e seus relacionamentos dentro de um domínio.
Ontologias fornecem a representação primária do conhecimento na Web Semântica e são usadas na troca de informações entre aplicações da Web
Semântica.49
Linguagens de ontologias como Resource Description Framework Schema (RDFS) são usadas para desenvolver ontologias codificando o conhecimento
sobre domínios específicos. Eles podem incluir regras de raciocínio para apoiar o processamento desse conhecimento. OWL (Web Ontology Language),
uma extensão do RDFS, é uma sintaxe formal para definir ontologias.
Ontologias descrevem classes (conceitos), indivíduos (instâncias), atributos, relações e eventos. Uma ontologia pode ser uma coleção de taxonomias e
tesauros de vocabulário comum para representação de conhecimento e troca de informações. As ontologias geralmente se relacionam a uma hierarquia
taxonômica de classes e definições com a relação de subsunção, como decompor o comportamento inteligente em muitos módulos de comportamento
mais simples e depois em camadas.
Existem duas diferenças principais entre uma taxonomia (como um modelo de dados) e uma ontologia:
• Uma taxonomia fornece classificações de conteúdo de dados para uma determinada área de conceito. Um modelo de dados especificamente
chama a entidade à qual um atributo pertence e o valor válido para esse atributo. Em uma ontologia, porém,
conceitos de entidade, atributo e conteúdo podem ser completamente misturados. As diferenças são identificadas por meio de
Metadados ou outros relacionamentos.
49 Web Semântica, também conhecida como Linked Data Web ou Web 3.0, um aprimoramento da Web atual onde o significado (ou seja,
semântica) é processável por máquina. Ter uma máquina (computador) entendendo mais torna mais fácil encontrar, compartilhar e
combinar dados/informações com mais facilidade.
• Em uma taxonomia ou modelo de dados, o que é definido é o que é conhecido – e nada mais. Isso é referido
como uma suposição de mundo fechado. Em uma ontologia, as relações possíveis são inferidas com base na natureza do
relacionamentos existentes, então algo que não é explicitamente declarado pode ser verdadeiro. Isto é referido como o
suposição de mundo aberto.
Enquanto a gestão da taxonomia evoluiu no âmbito das Biblioteconomias, hoje a arte e a ciência da gestão da taxonomia e da ontologia se enquadram
no espaço da gestão semântica. (Consulte o Capítulo 10.)
Como o processo de modelagem de ontologias é algo subjetivo, é importante evitar armadilhas comuns que causam ambiguidade e confusão:
• Falha em distinguir entre um relacionamento de instância e um relacionamento de subclasse
• Modelagem de eventos como relações
• Falta de clareza e singularidade dos termos
• Funções de modelagem como classes

• Falha na reutilização
• Mistura de semântica de linguagem de modelagem e conceitos
• O uso de uma ferramenta independente de plataforma baseada na web (por exemplo, OOPS!) para validação de ontologia ajuda com
diagnóstico e reparo de armadilhas
1.3.3 Documentos e Registros
Documentos são objetos eletrônicos ou em papel que contêm instruções para tarefas, requisitos de como e quando executar uma tarefa ou função e
logs de execução de tarefas e decisões. Os documentos podem comunicar e compartilhar informações e conhecimentos. Exemplos de documentos
incluem procedimentos, protocolos, métodos e especificações.
Apenas um subconjunto de documentos será designado como registros. Os registros fornecem evidências de que as ações foram tomadas e as
decisões foram tomadas de acordo com os procedimentos; eles podem servir como evidência das atividades de negócios da organização e da
conformidade regulatória. As pessoas costumam criar registros, mas instrumentos e equipamentos de monitoramento também podem fornecer dados
para gerar registros automaticamente.
1.3.3.1 Gerenciamento de Documentos
O gerenciamento de documentos abrange os processos, técnicas e tecnologias para controlar e organizar documentos e registros ao longo de seu
ciclo de vida. Inclui armazenamento, inventário e controle, para documentos eletrônicos e em papel. Mais de 90% dos documentos criados hoje são
eletrônicos. Embora os documentos sem papel estejam se tornando mais amplamente utilizados, o mundo ainda está cheio de documentos históricos
em papel.
Em geral, o gerenciamento de documentos diz respeito a arquivos, com pouca atenção ao conteúdo do arquivo. O conteúdo das informações em um
arquivo pode orientar como gerenciar esse arquivo, mas o gerenciamento de documentos trata o arquivo como uma entidade única.
316 • DMBOK2
As pressões de mercado e regulatórias colocam o foco nos cronogramas de retenção de registros, localização, transporte e destruição. Por exemplo,
alguns dados sobre indivíduos não podem cruzar fronteiras internacionais.
Regulamentos e estatutos, como a Lei Sarbanes-Oxley dos EUA e as Emendas de Descoberta Eletrônica às Regras Federais de Processo Civil e o
Projeto de Lei 198 do Canadá, agora são preocupações de executivos de conformidade corporativa que pressionam pela padronização das práticas
de gerenciamento de registros em suas organizações. Gerenciando o ciclo de vida de

documentos e registros incluem:
• Inventário: Identificação de documentos/registros existentes e recém-criados.
• Política: Criação, aprovação e aplicação de políticas de documentos/registros, incluindo um documento/
política de retenção de registros.

• Classificação de documentos/registros.
• Armazenamento: Armazenamento de curto e longo prazo de documentos/registros físicos e eletrônicos.
• Recuperação e Circulação: Permitindo o acesso e circulação de documentos/registros de acordo
com políticas, padrões de segurança e controle e requisitos legais.
• Preservação e Descarte: Arquivamento e destruição de documentos/registros de acordo com
necessidades organizacionais, estatutos e regulamentos.
Os profissionais de gerenciamento de dados são partes interessadas nas decisões sobre classificação e retenção de documentos. Eles devem oferecer
suporte à consistência entre os dados estruturados básicos e os dados não estruturados específicos. Por exemplo, se os relatórios de saída finalizados
forem considerados documentação histórica apropriada, os dados estruturados em um OLTP ou ambiente de armazenamento podem ser dispensados
de armazenar os dados de base do relatório.
Os documentos são frequentemente desenvolvidos dentro de uma hierarquia com alguns documentos mais detalhados do que outros. A Figura 72,
baseada no texto do Pacote de Introdução e Suporte da ISO 9000: Orientação sobre os Requisitos de Documentação da ISO 9001, Cláusula 4.2,
descreve um paradigma centrado na documentação, apropriado para o governo ou as forças armadas. A ISO 9001 descreve os componentes mínimos
de um sistema básico de gestão da qualidade.
As entidades comerciais podem ter hierarquias ou fluxos de documentos diferentes para apoiar as práticas de negócios.
1.3.3.2 Gerenciamento de Registros
O gerenciamento de documentos inclui o gerenciamento de registros. O gerenciamento de registros tem requisitos especiais.50 O gerenciamento de
registros inclui todo o ciclo de vida: desde a criação ou recebimento do registro, passando pelo processamento, distribuição, organização e recuperação,
até o descarte. Os registros podem ser físicos (por exemplo, documentos, memorandos, contratos, relatórios ou microfichas); eletrônico (por exemplo,
conteúdo de e-mail, anexos e mensagens instantâneas); conteúdo em um site; documentos em todos os tipos de mídia e hardware; e dados capturados
em bancos de dados de todos os tipos. Registros híbridos, como cartões de abertura (registro de papel com uma janela de microficha embutida com
detalhes ou material de apoio),
50 A norma ISO 15489 define gerenciamento de registros como “o campo de gerenciamento responsável pelo controle
eficiente e sistemático da criação, recebimento, manutenção, uso e disposição de registros, incluindo os processos
para capturar e manter evidências e informações sobre atividades de negócios e transações na forma de registros”.
http://bit.ly/2sVG8EW.
combinar formatos. Um Registro Vital é um registro necessário para retomar as operações de uma organização no caso de um
desastre.
Governo
Leis e
Regulamentos
Qual é a lei?
Quem impõe o
legislação?
Quando? Como? Onde?
Que regras e detalhes regulatórios
são necessários para
implementar as leis?
Políticas e padrões
O que está para acontecer? Onde?

Por que importante?
Quem é responsável?
Processos e Procedimentos
O que precisa ser feito?

Como fazer isso
Instruções de trabalho
O que fazer
Quem fará a tarefa?
Etapas detalhadas específicas para uma tarefa
Vinculado a um procedimento
Outros Documentos que Expressam Evidência de Conformidade

(Registros)
Pode incluir arquivos completos, formulários, tags, rótulos
Figura 72 Hierarquia de documentos baseada na ISO 9001-4.2
Registros confiáveis são importantes não apenas para manutenção de registros, mas também para conformidade regulatória. Ter
assinaturas no registro contribui para a integridade de um registro. Outras ações de integridade incluem a verificação do evento (ou seja,
testemunhar em tempo real) e verificar novamente as informações após o evento.
Registros bem elaborados possuem características como:
• Conteúdo: O conteúdo deve ser preciso, completo e verdadeiro.
• Contexto: Informações descritivas (Metadados) sobre o criador do registro, data de criação ou
relação com outros registros deve ser coletada, estruturada e mantida com o registro no momento
de criação do registro.
• Pontualidade: Um registro deve ser criado imediatamente após a ocorrência do evento, ação ou decisão.
• Permanência: Uma vez designados como registros, os registros não podem ser alterados pela duração legal de
sua existência.
318 • DMBOK2
• Estrutura: A aparência e a disposição do conteúdo de um registro devem ser claras. Eles deveriam ser
registrados nos formulários ou modelos corretos. O conteúdo deve ser legível, a terminologia deve ser usada
consistentemente.
Muitos registros existem em formatos eletrônicos e em papel. O Gerenciamento de Registros exige que a organização saiba qual cópia
(eletrônica ou em papel) é a 'cópia do registro' oficial para cumprir as obrigações de manutenção de registros. Uma vez determinada a
cópia do registro, a outra cópia pode ser destruída com segurança.
1.3.3.3 Gestão de Ativos Digitais
O Digital Asset Management (DAM) é um processo semelhante ao gerenciamento de documentos que se concentra no armazenamento,
rastreamento e uso de documentos de mídia avançada, como vídeo, logotipos, fotografias etc.
1.3.4 Mapa de Dados
Um mapa de dados é um inventário de todas as fontes de dados, aplicativos e ambientes de TI do ESI que inclui os proprietários dos
aplicativos, responsáveis, localizações geográficas relevantes e tipos de dados.
1.3.5 Descoberta eletrônica
Descoberta é um termo legal que se refere à fase pré-julgamento de uma ação judicial em que ambas as partes solicitam informações
uma da outra para encontrar fatos para o caso e ver quão fortes são os argumentos de cada lado. As Regras Federais de Processo Civil
dos EUA (FRCP) regem a descoberta de provas em ações judiciais e outros casos civis desde 1938. Durante décadas, as regras de
descoberta em papel foram aplicadas à descoberta eletrônica. Em 2006, as emendas ao FRCP acomodaram a prática de descoberta e
os requisitos da ESI no processo de litígio.
Outras regulamentações globais têm requisitos específicos para a capacidade de uma organização produzir provas eletrônicas. Exemplos
incluem a Lei de Suborno do Reino Unido, Lei Dodd-Frank, Lei de Conformidade Fiscal de Contas Estrangeiras (FATCA), Lei de Práticas
de Corrupção no Exterior, Regulamentos e Regras de Proteção de Dados da UE, regulamentos antitruste globais, regulamentos
específicos do setor e regras processuais de tribunais locais.
Os documentos eletrônicos geralmente têm Metadados (que podem não estar disponíveis para documentos em papel) que desempenham
um papel importante na evidência. Os requisitos legais vêm dos principais processos legais, como descoberta eletrônica, bem como
práticas de retenção de dados e registros, processo de notificação de retenção legal (LHN) e práticas de disposição legalmente
defensáveis. A LHN inclui identificar informações que podem ser solicitadas em um processo legal, bloquear esses dados ou documentos
para evitar edição ou exclusão e notificar todas as partes em uma organização de que os dados ou documentos em questão estão
sujeitos a uma retenção legal.
A Figura 73 mostra um Modelo de Referência de Descoberta Eletrônica de alto nível desenvolvido pela EDRM, uma organização de
padrões e diretrizes para descoberta eletrônica. Esta estrutura fornece uma abordagem para e-discovery que é útil para
pessoas envolvidas na identificação de como e onde os dados internos relevantes são armazenados, quais políticas de retenção se aplicam,
quais dados não estão acessíveis e quais ferramentas estão disponíveis para auxiliar no processo de identificação.
Figura 73 Modelo de Referência de Descoberta Eletrônica 51
O modelo EDRM pressupõe que a governança de dados ou informações está em vigor. O modelo inclui oito fases de descoberta que
podem ser iterativas. À medida que a descoberta eletrônica progride, o volume de dados e informações detectáveis é bastante reduzido,
pois sua relevância aumenta bastante.
A primeira fase, Identificação, tem duas subfases: Avaliação Inicial de Caso e Avaliação Inicial de Dados (não representada no diagrama).
Na Avaliação de Caso Inicial, o próprio caso legal é avaliado em busca de informações pertinentes, chamadas de informações descritivas
ou Metadados (por exemplo, palavras-chave, intervalos de datas, etc.). Na Early Data Assessment, são avaliados os tipos e a localização
dos dados relevantes para o caso. A avaliação de dados deve identificar políticas relacionadas à retenção ou destruição de dados relevantes
para que o ESI possa ser preservado. As entrevistas devem ser realizadas com o pessoal de gerenciamento de registros, guardiões de
dados ou proprietários de dados e pessoal de tecnologia da informação para obter informações pertinentes. Além disso, o pessoal envolvido
precisa entender o histórico do caso, a retenção legal e seu papel no litígio.
As próximas fases do modelo são a Preservação e Coleta. A preservação garante que os dados identificados como potencialmente
relevantes sejam colocados em retenção legal para que não sejam destruídos. A coleta inclui a aquisição e transferência de dados
identificados da empresa para seus advogados de forma legalmente defensável.

maneiras.
Durante a fase de processamento, os dados são desduplicados, pesquisados e analisados para determinar quais itens de dados avançarão
para a fase de revisão. Na fase de Revisão, são identificados os documentos a serem apresentados em resposta à solicitação. A revisão
também identifica documentos privilegiados que serão retidos. Grande parte da seleção depende dos Metadados associados aos
documentos. O processamento ocorre após a fase de Revisão porque aborda
51 EDRM (edrm.net). O conteúdo postado em EDRM.net está licenciado sob uma Licença Creative Commons Atribuição 3.0 Não Adaptada.
320 • DMBOK2
análise de conteúdo para entender as circunstâncias, fatos e provas potenciais em litígio ou investigação e para aprimorar os processos
de busca e revisão.
Processamento e Revisão dependem da análise, mas a Análise é considerada uma fase separada com foco no conteúdo. O objetivo da
análise de conteúdo é compreender as circunstâncias, os fatos e as possíveis provas em litígio ou investigação, a fim de formular uma
estratégia de resposta à situação jurídica.
Na fase de Produção, os dados e as informações são entregues ao advogado oponente, com base nas especificações acordadas. As
fontes originais de informação podem ser arquivos, planilhas, e-mail, bancos de dados, desenhos, fotografias, dados de aplicativos
proprietários, dados de sites, correio de voz e muito mais. O ESI pode ser coletado, processado e enviado para uma variedade de
formatos. A produção nativa mantém o formato original dos arquivos.
A produção quase nativa altera o formato original por meio de extração e conversão. O ESI pode ser produzido em formato de imagem
ou quase papel. Dados em campo são metadados e outras informações extraídas de arquivos nativos quando o ESI é processado e
produzido em um arquivo delimitado por texto ou arquivo de carregamento XML. A linhagem dos materiais fornecidos durante a fase de
Produção é importante, pois ninguém quer ser acusado de alterar dados ou informações fornecidas.
A exibição do ESI em depoimentos, audiências e julgamentos faz parte da fase de Apresentação. As exposições do ESI podem ser
apresentadas em papel, quase papel, formatos quase nativos e nativos para apoiar ou refutar elementos do caso. Eles podem ser usados
para obter mais informações, validar fatos ou posições existentes ou persuadir um público.
1.3.6 Arquitetura da Informação
Arquitetura da Informação é o processo de criação de estrutura para um corpo de informação ou conteúdo. Inclui os seguintes
componentes:
• Vocabulários controlados
• Taxonomias e ontologias
• Mapas de navegação
• Mapas de metadados
• Especificações da funcionalidade de pesquisa

• Casos de uso
• Fluxos de usuários
A arquitetura da informação e a estratégia de conteúdo juntos descrevem o 'o quê' – qual conteúdo será gerenciado em um sistema. As
fases de design descrevem 'como' a estratégia de gerenciamento de conteúdo será implementada.
Para um documento ou sistema de gerenciamento de conteúdo, a arquitetura de informação identifica os links e relacionamentos entre
documentos e conteúdo, especifica os requisitos e atributos do documento e define a estrutura do conteúdo em um documento ou
sistema de gerenciamento de conteúdo. A arquitetura da informação é fundamental para o desenvolvimento de sites eficazes. Um
storyboard fornece um plano para um projeto da web. Ele serve como um esboço da abordagem de design, define os elementos que
precisam estar em cada página da web e mostra a navegação e

fluxo de informações de como as páginas devem funcionar juntas. Isso permite o desenvolvimento dos modelos de navegação, menus e outros
componentes necessários para o gerenciamento e uso do site.
1.3.7 Motor de busca
Um mecanismo de pesquisa é um software que pesquisa informações com base em termos e recupera sites que contêm esses termos em seu conteúdo.
Um exemplo é o Google. A funcionalidade de pesquisa requer vários componentes: software de mecanismo de pesquisa adequado, software spider que
percorre a Web e armazena os Uniform Resource Locators (URLs)
do conteúdo que encontra, indexação das palavras-chave e texto encontrados e regras de classificação.
1.3.8 Modelo Semântico
A modelagem semântica é um tipo de modelagem de conhecimento que descreve uma rede de conceitos (ideias ou tópicos de interesse) e seus
relacionamentos. Incorporados aos sistemas de informação, os modelos semânticos permitem que os usuários façam perguntas sobre a informação de
forma não técnica. Por exemplo, um modelo semântico pode mapear tabelas e visualizações de banco de dados para conceitos significativos para usuários
de negócios.
Os modelos semânticos contêm objetos semânticos e associações. Objetos semânticos são coisas representadas no modelo.
Eles podem ter atributos com cardinalidade e domínios e identificadores. Suas estruturas podem ser simples, compostas, compostas, híbridas, de
associação, pai/subtipo ou arquétipo/versão. As ligações representam associações ou classes de associação em UML. Esses modelos ajudam a identificar
padrões e tendências e a descobrir relações entre informações que, de outra forma, poderiam parecer díspares. Ao fazer isso, eles ajudam a permitir a
integração de dados em diferentes domínios de conhecimento ou áreas de conhecimento. Ontologias e vocabulários controlados são fundamentais para
a modelagem semântica.
A integração de dados usa ontologias de várias maneiras diferentes. Uma única ontologia poderia ser o modelo de referência. Se houver várias fontes de
dados, cada fonte de dados individual é modelada usando uma ontologia e posteriormente mapeada para as outras ontologias. A abordagem híbrida usa
várias ontologias que se integram a um vocabulário geral comum.
1.3.9 Pesquisa Semântica
A pesquisa semântica se concentra no significado e no contexto, em vez de palavras-chave predeterminadas. Um mecanismo de pesquisa semântica
pode usar inteligência artificial para identificar correspondências de consulta com base em palavras e seu contexto. Esse mecanismo de pesquisa pode
analisar por localização, intenção, variações de palavras, sinônimos e correspondência de conceitos.
Os requisitos para a pesquisa semântica envolvem descobrir o que os usuários desejam, o que significa pensar como os usuários. Se os usuários quiserem
que os mecanismos de pesquisa funcionem como linguagem natural, provavelmente eles desejarão que o conteúdo da Web se comporte dessa maneira.
O desafio para as organizações de marketing é incorporar associações e palavras-chave que sejam relevantes
para seus usuários, bem como para suas marcas.
322 • DMBOK2
O conteúdo da Web otimizado para semântica incorpora palavras-chave naturais, em vez de depender da inserção rígida de palavras-
chave. Os tipos de palavras-chave semânticas incluem: Palavras-chave principais que contêm variações; palavras-chave temáticas para
termos conceitualmente relacionados; e originar palavras-chave que antecipam o que as pessoas podem perguntar. O conteúdo pode ser
otimizado ainda mais por meio da relevância e 'compartilhamento' do conteúdo e do compartilhamento de conteúdo por meio da integração
de mídia social.
Os usuários de Business Intelligence (BI) e ferramentas de análise geralmente têm requisitos de pesquisa semântica. As ferramentas de BI
precisam ser flexíveis para que os usuários de negócios possam encontrar as informações de que precisam para análises, relatórios e
painéis. Os usuários de Big Data têm uma necessidade semelhante de encontrar um significado comum em dados de formatos diferentes.
1.3.10 Dados Não Estruturados
Estima-se que até 80% de todos os dados armazenados sejam mantidos fora dos bancos de dados relacionais. este
os dados não estruturados não possuem um modelo de dados que permita aos usuários entender seu conteúdo ou como ele está
organizado; ele não é marcado ou estruturado em linhas e colunas. O termo não estruturado é um pouco enganoso, pois geralmente há
estrutura em documentos, gráficos e outros formatos, por exemplo, capítulos ou cabeçalhos. Alguns se referem a dados armazenados fora
de bancos de dados relacionais como dados não tabulares ou semiestruturados . Nenhum termo único descreve adequadamente o vasto
volume e formato diversificado de informações eletrônicas que são criadas e armazenadas nos
mundo.
Os dados não estruturados são encontrados em vários formatos eletrônicos: documentos de processamento de texto, correio eletrônico,
mídias sociais, chats, arquivos simples, planilhas, arquivos XML, mensagens transacionais, relatórios, gráficos, imagens digitais, microfichas,
gravações de vídeo e gravações de áudio. Uma enorme quantidade de dados não estruturados também existe em arquivos em papel.
Os princípios fundamentais do gerenciamento de dados se aplicam a dados estruturados e não estruturados. Dados não estruturados são
um ativo corporativo valioso. Armazenamento, integridade, segurança, qualidade de conteúdo, acesso e uso eficaz orientam o gerenciamento
de dados não estruturados. Dados não estruturados requerem governança de dados, arquitetura, segurança Metadados e qualidade de
dados.
Dados não estruturados e semiestruturados tornaram-se mais importantes para data warehousing e Business Intelligence. Os data
warehouses e seus modelos de dados podem incluir índices estruturados para ajudar os usuários a encontrar e analisar dados não
estruturados. Alguns bancos de dados incluem a capacidade de lidar com URLs para dados não estruturados que funcionam como hiperlinks
quando recuperados da tabela do banco de dados. Dados não estruturados em data lakes são descritos no Capítulo 14.
1.3.11 Fluxo de Trabalho
O desenvolvimento de conteúdo deve ser gerenciado por meio de um fluxo de trabalho que garanta que o conteúdo seja criado dentro do
cronograma e receba as aprovações adequadas. Os componentes do fluxo de trabalho podem incluir a criação, processamento, roteamento,
regras, administração, segurança, assinatura eletrônica, prazo, escalação (se ocorrerem problemas), relatórios e entrega. Isto
deve ser automatizado através do uso de um sistema de gerenciamento de conteúdo (CMS) ou um sistema autônomo, em vez de
processos manuais.
Um CMS tem o benefício adicional de fornecer controle de versão. Quando o conteúdo é verificado em um CMS, ele recebe um
carimbo de data/hora, um número de versão e marcado com o nome da pessoa que fez as atualizações.
O fluxo de trabalho precisa ser repetível, idealmente contendo etapas de processo comuns em uma variedade de conteúdo. Um
conjunto de fluxos de trabalho e modelos pode ser necessário se houver diferenças significativas entre os tipos de conteúdo.
O alinhamento das partes interessadas e pontos de distribuição (incluindo tecnologia) é importante. Os prazos precisam ser refinados
para melhorar os fluxos de trabalho, caso contrário, você pode descobrir rapidamente que seus fluxos de trabalho estão desatualizados
ou há confusão sobre qual parte interessada é responsável por qual peça.
2. Atividades
2.1 Plano para Gerenciamento do Ciclo de Vida
A prática de gerenciamento de documentos envolve o planejamento do ciclo de vida de um documento, desde sua criação ou
recebimento, passando por sua distribuição, armazenamento, recuperação, arquivamento e potencial destruição. O planejamento
inclui o desenvolvimento de sistemas de classificação/indexação e taxonomias que permitem o armazenamento e recuperação de documentos.
É importante ressaltar que o planejamento do ciclo de vida requer a criação de políticas específicas para registros.
Primeiro, identifique a unidade organizacional responsável pela gestão dos documentos e registros. Essa unidade coordena o acesso
e distribuição interna e externamente e integra as melhores práticas e fluxos de processos com outros departamentos da organização.
Também desenvolve um plano geral de gerenciamento de documentos que inclui um plano de continuidade de negócios para
documentos e registros vitais. A unidade garante que segue políticas de retenção alinhadas aos padrões da empresa e
regulamentações governamentais. Ele garante que os registros necessários para necessidades de longo prazo sejam arquivados
adequadamente e que outros sejam destruídos adequadamente no final de seu ciclo de vida de acordo com os requisitos
organizacionais, estatutos e regulamentos.
2.1.1 Plano de Gerenciamento de Registros
O gerenciamento de registros começa com uma definição clara do que constitui um registro. A equipe que define os registros para
uma área funcional deve incluir PMEs dessa área junto com pessoas que entendam os sistemas que permitem o gerenciamento dos
registros.
O gerenciamento de registros eletrônicos requer decisões sobre onde armazenar registros ativos e atuais e como arquivar registros
mais antigos. Apesar do uso generalizado da mídia eletrônica, os registros em papel não vão desaparecer no curto prazo. Uma
abordagem de gerenciamento de registros deve levar em conta registros em papel e dados não estruturados, bem como registros
eletrônicos estruturados.
324 • DMBOK2
2.1.2 Desenvolva uma Estratégia de Conteúdo
O planejamento do gerenciamento de conteúdo deve apoiar diretamente a abordagem da organização para fornecer conteúdo relevante e útil de
maneira eficiente e abrangente. Um plano deve levar em conta os direcionadores de conteúdo (os motivos pelos quais o conteúdo é necessário), a
criação e a entrega de conteúdo. Os requisitos de conteúdo devem orientar as decisões de tecnologia, como a seleção de um sistema de
gerenciamento de conteúdo.
Uma estratégia de conteúdo deve começar com um inventário do estado atual e uma avaliação de lacunas. A estratégia define como o conteúdo
será priorizado, organizado e acessado. A avaliação geralmente revela maneiras de otimizar a produção, o fluxo de trabalho e os processos de
aprovação para a criação de conteúdo. Uma estratégia de conteúdo unificada enfatiza o design de componentes de conteúdo modulares para
reutilização, em vez de criar conteúdo independente.
Permitir que as pessoas encontrem diferentes tipos de conteúdo por meio da categorização de metadados e da otimização de mecanismos de
pesquisa (SEO) é fundamental para qualquer estratégia de conteúdo. Forneça recomendações sobre criação, publicação e governança de conteúdo.
Políticas, padrões e diretrizes que se aplicam ao conteúdo e seu ciclo de vida são úteis para sustentar e evoluir a estratégia de conteúdo de uma
organização.
2.1.3 Criar Políticas de Tratamento de Conteúdo
As políticas codificam os requisitos descrevendo princípios, direção e diretrizes para ação. Eles ajudam os funcionários a entender e cumprir os
requisitos para gerenciamento de documentos e registros.
A maioria dos programas de gerenciamento de documentos possui políticas relacionadas a:
• Escopo e conformidade com auditorias
• Identificação e proteção de registros vitais
• Objetivo e cronograma para retenção de registros (também conhecido como cronograma de retenção)
• Como responder a ordens de retenção de informação (ordem de protecção especial); são requisitos para
reter informações para uma ação judicial, mesmo que os cronogramas de retenção tenham expirado
• Requisitos para armazenamento de registros no local e fora do local

• Uso e manutenção de disco rígido e unidades de rede compartilhadas
• Gerenciamento de e-mail, abordado da perspectiva do gerenciamento de conteúdo
• Métodos de destruição adequados para registros (por exemplo, com fornecedores pré-aprovados e recibo de destruição
certificados)
2.1.3.1 Políticas de Mídia Social
Além desses tópicos padrão, muitas organizações estão desenvolvendo políticas para responder às novas mídias. Por exemplo, uma organização
precisa definir se o conteúdo de mídia social postado no Facebook, Twitter, LinkedIn, salas de bate-papo, blogs, wikis ou fóruns online constitui um
registro, especialmente se os funcionários postarem durante a condução dos negócios usando contas organizacionais.
2.1.3.2 Políticas de Acesso ao Dispositivo
Como o pêndulo está mudando para a TI orientada pelo usuário com BYOD (traga seus próprios dispositivos), BYOA (traga seus próprios aplicativos) e
WYOD (use seus próprios dispositivos), as funções de gerenciamento de conteúdo e registros precisam trabalhar com esses cenários para garantir
conformidade, segurança e privacidade.
As políticas devem distinguir entre conteúdo informal (por exemplo, Dropbox ou Evernote) e conteúdo formal (por exemplo, contratos e acordos), a fim de
controlar o conteúdo formal. As políticas também podem fornecer orientação sobre

conteúdo informal.
2.1.3.3 Manipulando Dados Sensíveis
As organizações são legalmente obrigadas a proteger a privacidade, identificando e protegendo dados confidenciais. Segurança de Dados e/ou Governança
de Dados geralmente estabelecem os esquemas de confidencialidade e identificam quais ativos são confidenciais ou restritos. As pessoas que produzem
ou montam conteúdo devem aplicar essas classificações. Documentos, páginas da web e outros componentes de conteúdo devem ser marcados como
confidenciais com base em políticas e requisitos legais.
Uma vez marcados, os dados confidenciais são mascarados ou excluídos quando apropriado. (Consulte o Capítulo 7.)
2.1.3.4 Respondendo ao Litígio
As organizações devem se preparar para a possibilidade de solicitações de litígio por meio da descoberta eletrônica proativa. (Espere pelo melhor; prepare-
se para o pior.) Eles devem criar e gerenciar um inventário de suas fontes de dados e os riscos associados a cada uma. Ao identificar as fontes de dados
que podem ter informações relevantes, eles podem responder em tempo hábil a um aviso de retenção de litígio e evitar a perda de dados. As tecnologias
apropriadas devem ser implantadas para automatizar os processos de descoberta eletrônica.
2.1.4 Definir a Arquitetura de Informação de Conteúdo
Muitos sistemas de informação, como a web semântica, mecanismos de busca, mineração social na web, conformidade de registros e gerenciamento de
risco, sistemas de informações geográficas (GIS) e aplicativos de Business Intelligence contêm dados estruturados e não estruturados, documentos, texto,
imagens etc. apresentar suas necessidades de uma forma compreensível pelo mecanismo de recuperação do sistema para obter informações desses
sistemas. Da mesma forma, o inventário de documentos e dados estruturados e não estruturados precisa ser descrito/indexado em um formato que permita
que o mecanismo de recuperação identifique rapidamente os dados e informações correspondentes correspondentes. As consultas do usuário podem ser
imperfeitas, pois recuperam informações relevantes e irrelevantes ou não recuperam todas as informações relevantes.
em formação.
As pesquisas usam indexação baseada em conteúdo ou metadados. Os projetos de indexação analisam as opções de decisão para os principais aspectos
ou atributos dos índices com base nas necessidades e preferências dos usuários. Eles também analisam o gerenciamento de vocabulário e a sintaxe para
combinar termos individuais em títulos ou instruções de pesquisa.

326 • DMBOK2
Os profissionais de gerenciamento de dados podem se envolver com vocabulários e termos controlados no manuseio de Dados de Referência
(consulte a Seção 1.3.2.1) e Metadados para dados e conteúdo não estruturados. (Ver Capítulo 12.) Eles devem garantir que haja coordenação
com os esforços para construir vocabulários controlados, índices, esquemas de classificação
para recuperação de informações, modelagem de dados e esforços de metadados executados como parte de projetos e aplicativos de
2.2 Gerenciar o ciclo de vida
2.2.1 Capturar Registros e Conteúdo
Capturar conteúdo é o primeiro passo para gerenciá-lo. O conteúdo eletrônico muitas vezes já está em um formato para ser armazenado em
repositórios eletrônicos. Para reduzir o risco de perder ou danificar registros, o conteúdo em papel precisa ser digitalizado e carregado no sistema
corporativo, indexado e armazenado no repositório. Use assinaturas eletrônicas, se possível.
Quando o conteúdo é capturado, ele deve ser marcado (indexado) com Metadados apropriados, como (no mínimo) um identificador de documento
ou imagem, os dados e a hora da captura, o título e o(s) autor(es). Os metadados são necessários para a recuperação da informação, bem como
para a compreensão do contexto do conteúdo. Fluxos de trabalho automatizados e tecnologias de reconhecimento podem ajudar no processo de
captura e ingestão, fornecendo trilhas de auditoria.
Algumas plataformas de mídia social oferecem a capacidade de capturar registros. Salvar o conteúdo de mídia social em um repositório o torna
disponível para revisão, meta marcação e classificação e gerenciamento como registros. Os rastreadores da Web podem capturar versões de
sites. Ferramentas de captura da Web, interfaces de programação de aplicativos (APIs) e feeds RSS podem capturar conteúdo ou ferramentas
de exportação de mídia social. Os registros de mídia social também podem ser capturados manualmente ou por meio de fluxos de trabalho
automatizados e predefinidos.
2.2.2 Gerenciar Versionamento e Controle
O padrão ANSI 859 tem três níveis de controle de dados, com base na criticidade dos dados e no dano percebido que ocorreria se os dados
fossem corrompidos ou indisponíveis: formal, revisão e custódia:
• O controle formal requer o início formal da mudança, avaliação completa do impacto, decisão por um
autoridade de mudança e contabilidade completa do status de implementação e validação para as partes interessadas
• O controle de revisão é menos formal, notificando as partes interessadas e incrementando as versões quando uma mudança é
requeridos
• O controle de custódia é o menos formal, exigindo apenas armazenamento seguro e um meio de recuperação
A Tabela 15 mostra uma lista de amostra de ativos de dados e possíveis níveis de controle.
Tabela 15 Níveis de Controle para Documentos por ANSI-859
Recurso de dados Formal Revisão Custódia

Listas de itens de ação x
Agendas x
Constatações de auditoria x x
Orçamentos x
DD 250 x
Proposta Final x
Dados e relatórios financeiros x x x
Dados de Recursos Humanos x
Atas da reunião x
Avisos de reunião e listas de presença x x
Planos de projeto (incluindo gerenciamento de dados e planos de x
gerenciamento de configuração)
Proposta (em andamento) x
Horários x
Declarações de Trabalho x
Estudos comerciais x
Material de treinamento x x
Papéis de trabalho x
O ANSI 859 recomenda levar em consideração os seguintes critérios ao determinar qual nível de controle se aplica
para um ativo de dados:
• Custo de fornecimento e atualização do ativo
• Impacto do projeto, se as mudanças tiverem consequências significativas de custo ou cronograma
• Outras consequências da mudança na empresa ou projeto

• Necessidade de reutilizar o ativo ou versões anteriores do ativo
• Manutenção de um histórico de mudanças (quando exigido pela empresa ou pelo projeto)
2.2.3 Backup e Recuperação
O sistema de gerenciamento de documentos/registros precisa ser incluído nas atividades gerais de backup e recuperação corporativas da
organização, incluindo continuidade de negócios e planejamento de recuperação de desastres. Um programa de registros vitais fornece à
organização acesso aos registros necessários para conduzir seus negócios durante um desastre e retomar os negócios normais
posteriormente. Os registros vitais devem ser identificados e os planos para sua proteção e recuperação devem ser desenvolvidos e
mantidos. Um gerente de registros deve estar envolvido no planejamento de mitigação de riscos e continuidade de negócios, para garantir
que essas atividades sejam responsáveis pela segurança de registros vitais.
Os desastres podem incluir falta de energia, erro humano, falha de rede e hardware, mau funcionamento de software, ataque malicioso, bem
como desastres naturais. Um Plano de Continuidade de Negócios (ou Plano de Recuperação de Desastres) contém políticas escritas,
procedimentos e informações destinadas a mitigar o impacto de ameaças aos dados de uma organização, incluindo documentos, e recuperá-
los o mais rápido possível, com o mínimo de interrupção, em caso de

um desastre.
328 • DMBOK2
2.2.4 Gerenciar Retenção e Descarte
O gerenciamento eficaz de documentos/registros requer políticas e procedimentos claros, especialmente em relação à retenção e descarte
de registros. Uma política de retenção e disposição definirá os prazos durante os quais os documentos de valor operacional, legal, fiscal ou
histórico devem ser mantidos. Ele define quando documentos inativos podem ser transferidos para uma instalação de armazenamento
secundário, como armazenamento externo. A política especifica os processos de conformidade e os métodos e cronogramas para a disposição
dos documentos. Os requisitos legais e regulamentares devem ser considerados ao configurar os cronogramas de retenção.
Os gerentes de registros ou proprietários de ativos de informações fornecem supervisão para garantir que as equipes considerem os requisitos
de privacidade e proteção de dados e tomem medidas para impedir o roubo de identidade.
A retenção de documentos apresenta considerações de software. O acesso a registros eletrônicos pode exigir versões específicas de software
e sistemas operacionais. Mudanças tecnológicas tão simples quanto a instalação de um novo software podem
tornar os documentos ilegíveis ou inacessíveis.
As informações que não agregam valor devem ser retiradas do acervo da organização e descartadas para evitar o desperdício de espaço
físico e eletrônico, bem como o custo associado à sua manutenção. Também há risco associado à retenção de registros após os prazos
legalmente exigidos. Esta informação permanece detectável para litígios.
Ainda assim, muitas organizações não priorizam a remoção de informações sem valor agregado porque:
• As políticas não são adequadas
• As informações sem valor agregado de uma pessoa são as informações valiosas de outra
• Incapacidade de prever futuras possíveis necessidades de atuais recursos físicos e/ou eletrônicos sem valor agregado
registros
• Não há buy-in para Gerenciamento de Registros
• Incapacidade de decidir quais registros excluir
• Custo percebido de tomar uma decisão e remover registros físicos e eletrônicos
• O espaço eletrônico é barato. Comprar mais espaço quando necessário é mais fácil do que arquivar e remover
processos
2.2.5 Documentos/ Registros de Auditoria
O gerenciamento de documentos/registros requer auditorias periódicas para garantir que as informações corretas cheguem às pessoas certas
no momento certo para a tomada de decisões ou realização de atividades operacionais. A Tabela 16 contém exemplos de medidas de
auditoria.
Tabela 16 Exemplos de Medidas de Auditoria
Gestão de Documentos/Registros Amostra de Medida de Auditoria
Componente
Inventário Cada local no inventário é identificado exclusivamente.
Armazenar As áreas de armazenamento de documentos/registros físicos têm espaço adequado para
acomodar o crescimento.
Confiabilidade e precisão Verificações pontuais são executadas para confirmar que os documentos / registros são um
reflexo adequado do que foi criado ou recebido.
Esquemas de Classificação e Indexação Metadados e planos de arquivos de documentos são bem descritos.
Acesso e recuperação Os usuários finais encontram e recuperam informações críticas com facilidade.
Processos de retenção O cronograma de retenção é estruturado de forma lógica por departamento, funções funcionais ou principais da
organização.
Métodos de Disposição Os documentos/registros são descartados conforme recomendado.
Segurança e Confidencialidade Quebras de confidencialidade de documentos/registros e perda de documentos/registros são
registrados como incidentes de segurança e gerenciados adequadamente.
Compreensão organizacional de O treinamento apropriado é fornecido às partes interessadas e ao pessoal quanto às
gerenciamento de documentos / registros funções e responsabilidades relacionadas ao gerenciamento de documentos/registros.
Uma auditoria geralmente envolve as seguintes etapas:
• Definir direcionadores organizacionais e identificar as partes interessadas que compõem o 'porquê' do documento /
gerenciamento de registros
• Coleta de dados sobre o processo (o 'como'), uma vez determinado o que examinar/medir e o que
ferramentas para usar (como padrões, benchmarks, pesquisas de entrevista)
• Relatando os resultados
• Desenvolvimento de um plano de ação das próximas etapas e prazos
2.3 Publicar e entregar conteúdo
2.3.1 Fornecer Acesso, Pesquisa e Recuperação
Uma vez que o conteúdo tenha sido descrito por Metadados / marcação de palavras-chave e classificado dentro da arquitetura de conteúdo de
informação apropriada, ele está disponível para recuperação e uso. A tecnologia do portal que mantém perfis de usuários pode ajudá-los a encontrar
dados não estruturados. Os mecanismos de pesquisa podem retornar conteúdo com base em palavras-chave. Algumas organizações têm profissionais
que recuperam informações por meio de ferramentas internas de busca.
2.3.2 Entregar por meio de canais aceitáveis
Há uma mudança nas expectativas de entrega, pois os usuários de conteúdo agora desejam consumir ou usar conteúdo em um dispositivo de sua
escolha. Muitas organizações ainda estão criando conteúdo em algo como o MS Word e movendo-o para HTML, ou entregando conteúdo para uma
determinada plataforma, uma determinada resolução de tela ou um determinado tamanho na tela. Se

330 • DMBOK2
outro canal de entrega é desejado, este conteúdo tem que ser preparado para aquele canal (por exemplo, impresso). Existe a possibilidade
de que qualquer conteúdo alterado precise ser trazido de volta ao formato original.
Quando os dados estruturados de bancos de dados são formatados em HTML, torna-se difícil recuperar os dados estruturados originais,
pois separar os dados da formatação nem sempre é simples.
3. Ferramentas
3.1 Sistemas de gerenciamento de conteúdo corporativo
Um ECM pode consistir em uma plataforma de componentes principais ou um conjunto de aplicativos que podem ser integrados totalmente
ou usados separadamente. Esses componentes, discutidos abaixo, podem ser internos ou externos à empresa na nuvem.
Os relatórios podem ser entregues por meio de várias ferramentas, incluindo impressoras, e-mail, sites, portais e mensagens, bem como por
meio de uma interface de sistema de gerenciamento de documentos. Dependendo da ferramenta, os usuários podem pesquisar por drill
down, visualização, download/check-in e check-out e imprimir relatórios sob demanda. A capacidade de adicionar, alterar ou excluir relatórios
organizados em pastas facilita o gerenciamento de relatórios. A retenção de relatórios pode ser definida para eliminação automática ou
arquivamento em outras mídias, como disco, CD-ROM, COLD (Saída do Computador para Disco Laser), etc. Os relatórios também podem
ser retidos no armazenamento em nuvem. Conforme observado, a retenção de conteúdo em formatos ilegíveis e desatualizados representa
um risco para a organização. (Consulte os Capítulos 6 e 8 e a Seção 3.1.8.)
As fronteiras entre gerenciamento de documentos e gerenciamento de conteúdo estão se esvaindo à medida que os processos e funções
de negócios se entrelaçam, e os fornecedores tentam ampliar os mercados para seus produtos.
3.1.1 Gerenciamento de Documentos
Um sistema de gerenciamento de documentos é um aplicativo usado para rastrear e armazenar documentos eletrônicos e imagens
eletrônicas de documentos em papel. Sistemas de biblioteca de documentos, sistemas de correio eletrônico e sistemas de gerenciamento
de imagens são sistemas especializados de gerenciamento de documentos. Os sistemas de gerenciamento de documentos geralmente
fornecem armazenamento, controle de versão, segurança, gerenciamento de metadados, indexação de conteúdo e recursos de recuperação.
Os recursos estendidos de alguns sistemas podem incluir exibições de metadados de documentos.
Os documentos são criados em um sistema de gerenciamento de documentos ou capturados por meio de scanners ou software OCR.
Esses documentos eletrônicos devem ser indexados por meio de palavras-chave ou texto durante o processo de captura para que os
documentos possam ser encontrados. Metadados, como o nome do criador e as datas em que o documento foi criado, revisado, armazenado,
normalmente são armazenados para cada documento. Os documentos podem ser categorizados para recuperação usando um identificador
de documento exclusivo ou especificando termos de pesquisa parciais envolvendo o identificador do documento e/ou partes dos Metadados
esperados. Os metadados podem ser extraídos do documento automaticamente ou adicionados pelo usuário.
Os registros bibliográficos de documentos são dados estruturados descritivos, normalmente em Catalogação legível por máquina
(MARC) que são armazenados em bancos de dados de bibliotecas localmente e disponibilizados por meio de catálogos compartilhados em todo o mundo,
conforme a privacidade e as permissões permitem.
Alguns sistemas possuem recursos avançados, como suporte a documentos compostos e replicação de conteúdo. O software de processamento de texto
cria o documento composto e integra elementos não textuais, como planilhas, vídeos, áudio e outros tipos de multimídia. Além disso, um documento
composto pode ser uma coleção organizada de interfaces de usuário para formar uma visão única e integrada.
O armazenamento de documentos inclui funções para gerenciar documentos. Um repositório de documentos permite recursos de check-in e check-out,
controle de versão, colaboração, comparação, arquivamento, estado(s) de status, migração de uma mídia de armazenamento para outra e disposição. Ele
pode oferecer algum acesso e gerenciamento de versão de documentos externos ao seu próprio repositório (por exemplo, em um compartilhamento de
arquivos ou ambiente de nuvem).
Alguns sistemas de gerenciamento de documentos possuem um módulo que pode suportar diferentes tipos de fluxos de trabalho, como:
• Fluxos de trabalho manuais que indicam para onde o usuário envia o documento
• Fluxo de trabalho baseado em regras, onde são criadas regras que ditam o fluxo do documento dentro de um
organização
• Regras dinâmicas que permitem diferentes fluxos de trabalho com base no conteúdo
Os sistemas de gerenciamento de documentos possuem um módulo de gerenciamento de direitos onde o administrador concede acesso com base no tipo
de documento e nas credenciais do usuário. As organizações podem determinar que certos tipos de documentos requerem procedimentos adicionais de
segurança ou controle. Restrições de segurança, incluindo restrições de privacidade e confidencialidade, se aplicam durante a criação e gerenciamento do
documento, bem como durante a entrega. Uma assinatura eletrônica garante a identidade do remetente do documento e a autenticidade da mensagem,
entre outras coisas.
Alguns sistemas se concentram mais no controle e segurança de dados e informações do que em seu acesso, uso ou recuperação, principalmente nos
setores de inteligência, militar e pesquisa científica. Setores altamente competitivos ou altamente regulamentados, como os setores farmacêutico e
financeiro, também implementam segurança e controle extensivos

medidas.
3.1.1.1 Gestão de Ativos Digitais
Como a funcionalidade necessária é semelhante, muitos sistemas de gerenciamento de documentos incluem gerenciamento de ativos digitais. Este é o
gerenciamento de ativos digitais, como áudio, vídeo, música e fotografias digitais.
As tarefas envolvem catalogação, armazenamento e recuperação de ativos digitais.
3.1.1.2 Processamento de Imagem
Um sistema de processamento de imagens captura, transforma e gerencia imagens de papel e documentos eletrônicos. A capacidade de captura usa
tecnologias como digitalização, reconhecimento de caracteres óptico e de inteligência ou processamento de formulários. Os usuários podem indexar ou
inserir Metadados no sistema e salvar a imagem digitalizada em um repositório.

332 • DMBOK2
As tecnologias de reconhecimento incluem o reconhecimento óptico de caracteres (OCR), que é a conversão mecânica ou eletrônica de texto
digitalizado (digitalizado) impresso ou manuscrito em um formato que pode ser reconhecido por software de computador. O reconhecimento
inteligente de caracteres (ICR) é um sistema de OCR mais avançado que pode lidar com caligrafia impressa e cursiva. Ambos são importantes
para converter grandes quantidades de formulários ou dados não estruturados em um CMS

formato.
O processamento de formulários é a captura de formulários impressos por meio de tecnologias de digitalização ou reconhecimento. Os
formulários enviados por meio de um site podem ser capturados desde que o sistema reconheça o layout, a estrutura, a lógica e o conteúdo.
Além das imagens de documentos, outras imagens digitalizadas como fotografias digitais, infográficos, imagens de dados espaciais ou não
espaciais podem ser armazenadas em repositórios. Alguns sistemas ECM são capazes de ingerir diversos tipos de documentos e imagens
digitalizadas, como informações COLD, arquivos .wav e .wmv (áudio), mensagens XML e HL7 de saúde em um repositório integrado.
As imagens geralmente são criadas usando software de computador ou câmeras, em vez de em papel. Os formatos de arquivo binário
incluem tipos de vetor e raster (bitmap), bem como o formato MS Word .DOC. Imagens vetoriais usam fórmulas matemáticas em vez de
blocos coloridos individuais e são muito boas para criar gráficos que frequentemente requerem redimensionamento. Os formatos de arquivo
incluem .EPS, .AI ou .PDF. As imagens raster usam um número fixo de pixels coloridos para formar uma imagem completa e não podem ser
redimensionadas facilmente sem comprometer sua resolução. Exemplos de arquivos raster incluem .JPEG, .GIF, .PNG ou .TIFF.
3.1.1.3 Sistema de Gerenciamento de Registros
Um sistema de gerenciamento de registros pode oferecer recursos como automação de retenção e descarte, suporte a descoberta eletrônica
e arquivamento de longo prazo para cumprir os requisitos legais e regulatórios. Deve apoiar um programa de registros vitais para reter
registros críticos de negócios. Este tipo de sistema pode ser integrado com um sistema de gestão de documentos.
3.1.2 Sistema de Gerenciamento de Conteúdo
Um sistema de gerenciamento de conteúdo é usado para coletar, organizar, indexar e recuperar conteúdo, armazenando-o como componentes
ou documentos inteiros, mantendo links entre os componentes. Um CMS também pode fornecer controles para revisar o conteúdo dos
documentos. Enquanto um sistema de gerenciamento de documentos pode fornecer funcionalidade de gerenciamento de conteúdo sobre os
documentos sob seu controle, um sistema de gerenciamento de conteúdo é essencialmente independente de onde e como os documentos
são armazenados.
Os sistemas de gerenciamento de conteúdo gerenciam o conteúdo ao longo de seu ciclo de vida. Por exemplo, um sistema de gerenciamento
de conteúdo da Web controla o conteúdo do site por meio de ferramentas de autoria, colaboração e gerenciamento com base no repositório
principal. Ele pode conter criação de conteúdo amigável, fluxo de trabalho e gerenciamento de mudanças e funções de implantação para
lidar com aplicativos de intranet, Internet e extranet. As funções de entrega podem incluir resposta
design e recursos adaptáveis para dar suporte a uma variedade de dispositivos clientes. Componentes adicionais podem incluir pesquisa,
composição de documentos, assinatura eletrônica, análise de conteúdo e aplicativos móveis.
3.1.3 Fluxo de Trabalho de Conteúdo e Documento
As ferramentas de fluxo de trabalho suportam processos de negócios, roteiam conteúdo e documentos, atribuem tarefas de trabalho, rastreiam
status e criam trilhas de auditoria. Um fluxo de trabalho fornece revisão e aprovação de conteúdo antes de ser publicado.
3.2 Ferramentas de Colaboração
As ferramentas de colaboração em equipe permitem a coleta, armazenamento, fluxo de trabalho e gerenciamento de documentos pertinentes às
atividades da equipe. As redes sociais permitem que indivíduos e equipes compartilhem documentos e conteúdo dentro da equipe e entrem em
contato com um grupo externo para obter informações usando blogs, wikis, RSS e marcação.
3.3 Ferramentas Controladas de Vocabulário e Metadados
As ferramentas que ajudam a desenvolver ou gerenciar vocabulários controlados e Metadados vão desde software de produtividade de escritório,
repositórios de Metadados e ferramentas de BI até sistemas de gerenciamento de conteúdo e documentos. Por exemplo:
• Modelos de dados usados como guias para os dados em uma organização
• Sistemas de gerenciamento de documentos e software de produtividade de escritório
• Repositórios, glossários ou diretórios de metadados

• Taxonomias e esquemas de referência cruzada entre taxonomias
• Índices para coleções (por exemplo, produto específico, mercado ou instalação), sistemas de arquivos, pesquisas de opinião,
arquivos, locais ou participações externas
• Motores de busca
• Ferramentas de BI que incorporam dados não estruturados
• Thesauri empresarial e departamental
• Bibliotecas de relatórios publicados, conteúdos e bibliografias e catálogos
3.4 Formatos Padrão de Marcação e Troca
Os aplicativos de computador não podem processar dados/conteúdos não estruturados diretamente. Os formatos padrão de marcação e troca
facilitam o compartilhamento de dados entre sistemas de informação e a Internet.

334 • DMBOK2
3.4.1 XML
Extensible Markup Language (XML) fornece uma linguagem para representar dados e informações estruturados e não estruturados. XML usa Metadados para
descrever o conteúdo, estrutura e regras de negócios de qualquer documento ou
base de dados.
XML requer a tradução da estrutura dos dados em uma estrutura de documento para troca de dados. XML identifica elementos de dados para identificar o significado
dos dados. Aninhamento simples e referências fornecem os relacionamentos entre
elementos de dados.
Os namespaces XML fornecem um método para evitar um conflito de nomes quando dois documentos diferentes usam os mesmos nomes de elementos. Os métodos
mais antigos de marcação incluem HTML e SGML, para citar alguns.
A necessidade de gerenciamento de conteúdo compatível com XML cresceu por vários motivos:
• XML fornece a capacidade de integrar dados estruturados em bancos de dados relacionais com dados não estruturados
dados. Dados não estruturados podem ser armazenados em um DBMS BLOB relacional (binary large object) ou em XML
arquivos.
• XML pode integrar dados estruturados com dados não estruturados em documentos, relatórios, e-mail, imagens,
arquivos gráficos, de áudio e de vídeo. A modelagem de dados deve levar em conta a geração de dados não estruturados.
relatórios de dados estruturados e incluí-los na criação de fluxos de trabalho de correção de erros, backup,
recuperação e arquivamento.
• O XML também pode criar portais corporativos ou corporativos (Business-to-Business [B2B], Business-to-Customer [B2C]), que fornecem aos
usuários um único ponto de acesso a uma variedade de conteúdo.
• XML fornece identificação e rotulagem de dados/conteúdos não estruturados para que os aplicativos de computador
pode entendê-los e processá-los. Dessa forma, os dados estruturados são anexados ao conteúdo não estruturado. Um
A especificação Extensible Markup Interface (XMI) consiste em regras para gerar o documento XML
contendo os metadados reais e, portanto, é uma 'estrutura' para XML.
3.4.2 JSON
JSON (JavaScript Object Notation) é um formato padrão aberto e leve para intercâmbio de dados. Seu formato de texto é independente do idioma e fácil de analisar,
mas usa convenções da família C de idiomas. JSON tem duas estruturas: uma coleção de pares de nome/valor não ordenados conhecidos como objetos e uma lista
ordenada de valores realizada como uma matriz. Ele está emergindo como o formato preferido em bancos de dados NoSQL centrados na web.
Uma alternativa ao XML, o JSON é usado para transmitir dados entre um servidor e um aplicativo da web. JSON é uma maneira semelhante, porém mais compacta,
de representar, transmitir e interpretar dados do que XML. O conteúdo XML ou JSON pode ser retornado ao usar a tecnologia REST.
3.4.3 RDF e Especificações W3C Relacionadas
Resource Description Framework (RDF), uma estrutura comum usada para descrever informações sobre qualquer recurso da Web, é um
modelo padrão para intercâmbio de dados na Web. Os recursos RDF são salvos em um triplestore, que é um banco de dados usado para
armazenar e recuperar consultas semânticas usando SPARQL.
RDF faz declarações sobre um recurso na forma de expressões sujeito (recurso)-predicado (nome da propriedade)-objeto (valor da
propriedade) ou triplos. Normalmente, o sujeito-predicado-objeto é descrito por um URI (Uniform Resource Identifier), mas o sujeito e o
objeto podem ser nós em branco e o objeto pode ser um literal (valores nulos e strings nulas não são suportados). Um URI nomeia o
relacionamento entre recursos, bem como duas extremidades do link ou triplo. A forma mais comum de URI é uma URL (localizador
uniforme de recursos). Isso permite que dados estruturados e semiestruturados sejam compartilhados entre aplicativos.
A Web Semântica precisa de acesso a dados e relacionamentos entre conjuntos de dados. A coleção de conjuntos de dados inter-
relacionados também é conhecida como Dados Vinculados. Os URIs fornecem uma maneira genérica de identificar qualquer entidade que
exista. HTML fornece um meio para estruturar e vincular documentos na Web. O RDF fornece um modelo de dados genérico baseado em
gráficos para vincular dados que descrevem coisas.
RDF usa XML como sua sintaxe de codificação. Ele vê Metadados como dados (por exemplo, autor, data de criação, etc.). Os recursos
descritos do RDF permitem a associação de significados semânticos aos recursos. O RDFS (RDF Schema) fornece um vocabulário de
modelagem de dados para dados RDF e é uma extensão do vocabulário RDF básico.
SKOS (Simple Knowledge Organization System) é um vocabulário RDF (ou seja, uma aplicação do modelo de dados RDF para capturar
dados descritos como uma hierarquia de conceitos). Qualquer tipo de classificação, taxonomia ou tesauro pode ser representado no SKOS.
OWL (W3C Web Ontology Language) é uma extensão de vocabulário do RDF. É uma linguagem de marcação semântica para publicação
e compartilhamento de documentos OWL (ontologias) na Web. É usado quando as informações contidas em documentos precisam ser
processadas por aplicativos e não por humanos. Tanto o RDF quanto o OWL são padrões da Web Semântica que fornecem uma estrutura
para compartilhamento e reutilização de dados, além de permitir a integração e interoperabilidade de dados na Web.
O RDF pode ajudar com a característica de 'variedade' do Big Data. Se os dados estiverem acessíveis usando o modelo de triplos RDF, os
dados de diferentes origens podem ser misturados e a linguagem de consulta SPARQL usada para localizar conexões e padrões sem
predefinir um esquema. Conforme descrito pelo W3C, “o RDF possui recursos que facilitam a mesclagem de dados, mesmo que os
esquemas subjacentes sejam diferentes, e suporta especificamente a evolução dos esquemas ao longo do tempo sem exigir que todos os
consumidores de dados sejam alterados” . e formatos e, em seguida, reduza ou substitua os conjuntos de dados (conhecido como fusão de
dados) por meio do alinhamento semântico. (Consulte o Capítulo
14.)
52 W3C, “Resource Description Framework (RDF)”, http://bit.ly/1k9btZQ.

336 • DMBOK2
3.4.4 Schema.org
Rotular o conteúdo com marcação semântica (por exemplo, conforme definido pelo Schema.org de código aberto) torna mais fácil para os
mecanismos de pesquisa semântica indexar o conteúdo e para os rastreadores da Web corresponderem o conteúdo a uma consulta de pesquisa.
Schema.org fornece uma coleção de vocabulários ou esquemas compartilhados para marcação na página para que os principais mecanismos
de pesquisa possam entendê-los. Ele se concentra no significado das palavras nas páginas da web, bem como nos termos e palavras-chave.
Snippets são o texto que aparece em cada resultado de pesquisa. Rich snippets são informações detalhadas sobre pesquisas específicas
(por exemplo, classificações de estrelas douradas no link). Para criar rich snippets, o conteúdo das páginas da Web precisa ser formatado
adequadamente com dados estruturados como Microdata (um conjunto de tags introduzido com HTML5) e vocabulários compartilhados do
Schema.org.
A coleção de vocabulário Schema.org também pode ser usada para interoperabilidade de dados estruturados (por exemplo, com JSON).
3.5 Tecnologia de descoberta eletrônica
A descoberta eletrônica geralmente envolve a revisão de grandes volumes de documentos. As tecnologias de descoberta eletrônica oferecem
muitos recursos e técnicas, como avaliação inicial de casos, coleta, identificação, preservação, processamento, reconhecimento óptico de
caracteres (OCR), seleção, análise de similaridade e análise de encadeamento de e-mail. A revisão assistida por tecnologia (TAR) é um fluxo
de trabalho ou processo em que uma equipe pode revisar documentos selecionados e marcá-los como relevantes ou não. Essas decisões se
tornam entradas para o mecanismo de codificação preditivo que revisa e classifica os documentos restantes de acordo com a relevância. O
suporte para governança de informações também pode ser um recurso.
4. Técnicas
4.1 Manual de Resposta a Litígios
A descoberta eletrônica começa no início de uma ação judicial. No entanto, uma organização pode planejar a resposta a litígios por meio do
desenvolvimento de um manual contendo objetivos, métricas e responsabilidades antes do início de um grande projeto de descoberta.
O manual define o ambiente de destino para e-discovery e avalia se existem lacunas entre os ambientes atual e de destino. Ele documenta os
processos de negócios para o ciclo de vida das atividades de e-discovery e identifica as funções e responsabilidades da equipe de e-discovery.
Um manual também pode permitir que uma organização identifique riscos e previna proativamente situações que possam resultar em litígios.
Para compilar um manual,

• Estabelecer um inventário de políticas e procedimentos para departamentos específicos (Jurídico, Registros
Gestão, TI).
• Elaborar políticas para tópicos, como retenções de litígios, retenção de documentos, arquivamento e backups.
• Avaliar os recursos da ferramenta de TI, como indexação, pesquisa e coleta de e-discovery, segregação de dados e
ferramentas de proteção, bem como as fontes/sistemas ESI não estruturados.
• Identificar e analisar questões jurídicas pertinentes.
• Desenvolver um plano de comunicação e treinamento para treinar os funcionários sobre o que é esperado.
• Identifique os materiais que podem ser preparados com antecedência para serem adaptados a um caso legal.
• Analise os serviços do fornecedor caso sejam necessários serviços externos.
• Desenvolva processos sobre como lidar com uma notificação e mantenha o manual atualizado.
4.2 Mapa de Dados de Resposta a Litígios
A descoberta eletrônica geralmente tem um prazo limitado (por exemplo, 90 dias). Fornecer aos advogados um mapa de dados do ambiente de TI e
ESI disponível pode permitir que uma organização responda com mais eficácia. Um mapa de dados é um catálogo de sistemas de informação.
Descreve os sistemas e seus usos, as informações que contêm, políticas de retenção e outras características. Os catálogos geralmente identificam
sistemas de registro, aplicativos de origem, arquivos, cópias de recuperação de desastres ou backups e mídia usada para cada um. Um mapa de
dados deve ser abrangente, contendo todos os sistemas. Como o e-mail costuma ser objeto de escrutínio em litígios, o mapa também deve descrever
como o e-mail é armazenado, processado e consumido. Mapear processos de negócios para a lista de sistemas e documentar funções e privilégios de
usuários permitirá a avaliação e documentação dos fluxos de informações.
O processo de criação do mapa de dados demonstrará o valor da criação de Metadados como parte do processo de gerenciamento de documentos.
Os metadados são críticos para a pesquisa. Também fornece contexto aos documentos ESI e permite que casos, transcrições, compromissos, etc.
sejam associados a documentos comprovativos.
Um mapa de dados de descoberta eletrônica deve indicar quais registros são facilmente acessíveis e quais não são. Existem diferentes regras de e-
discovery para essas duas categorias. Os dados inacessíveis precisam ser identificados e as razões pelas quais eles são inacessíveis precisam ser
documentadas. Para responder adequadamente a litígios, uma organização deve ter um inventário de registros em armazenamento externo, incluindo
armazenamento em nuvem externo.
Muitas vezes, já existem inventários de sistemas. Por exemplo, eles podem ser mantidos por Data Architecture, Metadata Management ou IT Asset
Management. As funções legais e/ou de gerenciamento de registros devem determinar se podem ser estendidas para fins de descoberta eletrônica.
A implementação do ECM é um esforço de longo prazo que pode ser percebido como caro. Como acontece com qualquer esforço em toda a empresa,
requer a adesão de uma ampla gama de partes interessadas e o apoio financeiro de um comitê executivo para financiamento. Com um projeto grande,
existe o risco de ser vítima de cortes orçamentários, oscilações de negócios, gerenciamento

338 • DMBOK2
mudanças ou inércia. Para minimizar os riscos, assegure-se de que o conteúdo, e não a tecnologia, conduza as decisões para a
implementação do ECM. Configure o fluxo de trabalho em torno das necessidades organizacionais para mostrar valor.
O objetivo de uma avaliação de prontidão de ECM é identificar áreas onde é necessário melhorar o gerenciamento de conteúdo e determinar
o quão bem adaptada a organização está para mudar seus processos para atender a essas necessidades. Um modelo de Avaliação de
Maturidade de Gerenciamento de Dados pode ajudar nesse processo. (Consulte o Capítulo 15.)
Alguns fatores críticos de sucesso de ECM são semelhantes aos de projetos de TI (por exemplo, suporte executivo, envolvimento de
usuários, treinamento de usuários, gerenciamento de mudanças, cultura corporativa e comunicação). Fatores críticos de sucesso específicos
de ECM incluem auditoria de conteúdo e classificação para conteúdo existente, arquitetura de informações apropriada, suporte ao ciclo de
vida do conteúdo, definições de tags de metadados apropriadas e a capacidade de personalizar funções em uma solução de ECM. Como
as soluções de ECM envolvem complexidade técnica e de processo, a organização precisa garantir que tenha os recursos adequados para
dar suporte ao processo.
Podem surgir riscos com implementações de ECM devido ao tamanho do projeto, complexidade na integração com outros aplicativos de
software, problemas organizacionais e de processo e o esforço necessário para migrar o conteúdo. A falta de treinamento para os membros
da equipe principal e a equipe interna pode levar a um uso desigual. Outros riscos incluem a falha na implementação de políticas, processos
e procedimentos ou falta de comunicação com as partes interessadas.
5.1.1 Maturidade da Gestão de Registros
Os Princípios de Manutenção de Registros Geralmente Aceitos da ARMA® (consulte a seção 1.2) podem orientar a avaliação de uma
organização de suas políticas e práticas para Gerenciamento de Registros. Juntamente com o GARP, a ARMA International possui um
Modelo de Maturidade de Governança da Informação que pode ajudar a avaliar o programa e as práticas de manutenção de registros de
uma organização.53 Este Modelo de Maturidade descreve as características do ambiente de governança da informação e manutenção de
registros em cinco níveis de maturidade para cada um dos oito princípios do GARP:
• Sub-Padrão de Nível 1: as preocupações de governança de informações e manutenção de registros não são abordadas ou apenas
minimamente
• Nível 2 Em Desenvolvimento: Desenvolvendo o reconhecimento de que a governança da informação e a manutenção de registros podem
ter impacto na organização
• Nível 3 Essencial: Requisitos mínimos que devem ser atendidos para atender aos requisitos legais e regulamentares
requisitos
• Nível 4 Proativo: Um programa proativo de governança de informações foi estabelecido com foco em
melhoria continua
53 ARMA International, Information Governance Maturity Model, http://bit.ly/2sPWGOe.

• Nível 5 Transformacional: A governança da informação é integrada à infraestrutura corporativa e
processos de negócios
Vários padrões podem ser aplicados para avaliações técnicas de sistemas e aplicativos de gerenciamento de registros.
Por exemplo,
• Padrão de Critérios de Design de Aplicativos de Software de Gerenciamento de Registros Eletrônicos DoD 5015.2
• ISO 16175, Princípios e Requisitos Funcionais para Registros em Ambientes de Escritório Eletrônicos
• Os Requisitos do Modelo para a Gestão de Registros Eletrônicos (MoReq2)
• A especificação de Serviços de Gerenciamento de Registros (RMS) do Grupo de Gerenciamento de Objetos (OMG)
As lacunas e riscos identificados nas avaliações de prontidão do gerenciamento de registros devem ser analisados quanto ao seu impacto
potencial na organização. As empresas estão sujeitas a leis que exigem manutenção e destruição segura de registros. Se uma organização
não inventariar seus registros, ela já está em risco, pois não pode saber se os registros foram roubados ou destruídos. Uma organização
pode gastar muito tempo e dinheiro tentando encontrar registros se não tiver um programa funcional de retenção de registros. A falta de
cumprimento dos requisitos legais e regulamentares pode levar a multas caras. A falha em identificar e proteger registros vitais pode
colocar uma empresa fora do negócio.
5.1.2 Avaliação de descoberta eletrônica
Uma avaliação de prontidão deve examinar e identificar oportunidades de melhoria para o programa de resposta a litígios. Um programa
maduro especificará funções e responsabilidades claras, protocolos de preservação, metodologias de coleta de dados e processos de
divulgação. Tanto o programa quanto os processos resultantes devem ser documentados, defensáveis e auditáveis.
O programa precisa entender o ciclo de vida das informações da organização e desenvolver um mapa de dados ESI para fontes de dados
(consulte a Seção 2.1.3.4). Como a preservação de dados é um requisito legal crítico, as políticas de retenção de dados devem ser
revisadas e avaliadas proativamente em antecipação a litígios. Deve haver um plano para trabalhar com a TI para implementar rapidamente
retenções de litígio conforme necessário.
Os riscos de não ter definido uma resposta proativa ao litígio devem ser avaliados e quantificados. Às vezes, as organizações respondem
apenas se houver um litígio antecipado e, em seguida, há uma luta para encontrar documentos e informações relevantes para análise.
Muito provavelmente, esse tipo de organização especifica demais a quantidade de dados a serem mantidos (ou seja, tudo) ou não possui
políticas de exclusão de dados em vigor. Não ter um cronograma de retenção de dados e informações pode levar a responsabilidades
legais se registros não removidos mais antigos forem necessários para descoberta eletrônica, mas
não disponível.
As pessoas podem ser um desafio maior do que a tecnologia. Pode haver problemas em adaptar as práticas de gestão nas atividades
diárias e fazer com que as pessoas usem ECM. Em alguns casos, o ECM pode levar a mais tarefas; por exemplo, digitalizando documentos
em papel e definindo Metadados necessários.

340 • DMBOK2
Muitas vezes as organizações gerenciam as informações, inclusive os registros, de forma departamental, criando silos de informações que
dificultam o compartilhamento e o gerenciamento adequado dos dados. Uma abordagem corporativa holística ao gerenciamento de
conteúdo e registros pode eliminar a percepção dos usuários de que precisam armazenar cópias do conteúdo. A solução ideal é um
repositório único, gerenciado de forma centralizada e segura, com políticas e processos claramente definidos aplicados em toda a
empresa. O treinamento e a comunicação sobre os processos, políticas e ferramentas são essenciais para o sucesso de um programa de
gerenciamento de registros ou ECM.
Privacidade, proteção de dados, confidencialidade, propriedade intelectual, criptografia, uso ético e identidade são questões importantes
com as quais os profissionais de gerenciamento de documentos e conteúdo devem lidar em cooperação com outros funcionários, gerência
e reguladores. Uma organização centralizada geralmente lida com processos para melhorar o acesso às informações, controlar o
crescimento de materiais que ocupam espaço no escritório, reduzir custos operacionais, minimizar riscos de litígios, proteger informações
vitais e apoiar uma melhor tomada de decisões.
Tanto o gerenciamento de conteúdo quanto de registros precisam ser elevados organizacionalmente e não vistos como funções de baixo
nível ou de baixa prioridade. Em indústrias fortemente regulamentadas, a função de Gerenciamento de Registros e Informações (RIM)
precisa estar estreitamente alinhada com a função jurídica corporativa junto com a função de e-discovery. Se a organização tiver objetivos
para melhorar a eficiência operacional gerenciando melhor as informações, a RIM deve estar alinhada ao marketing ou a um grupo de
suporte operacional. Se a organização vê a RIM como parte de TI, a função RIM deve se reportar diretamente ao CIO ou CDO. Muitas
vezes, a função RIM é encontrada no programa ECM ou no programa Enterprise Information Management (EIM).
6. Governança de Documentos e Conteúdo
6.1 Estruturas de Governança da Informação
Documentos, registros e outros conteúdos não estruturados representam risco para uma organização. Gerenciar esse risco e obter valor
dessas informações exigem governança. Os drivers incluem:
• Conformidade legal e regulatória
• Disposição defensável de registros
• Preparação proativa para e-discovery
• Segurança de informações confidenciais
• Gestão de áreas de risco como e-mail e Big Data
Princípios de programas bem-sucedidos de Governança da Informação estão surgindo. Um conjunto de princípios são os princípios ARMA
GARP® (consulte a Seção 1.2). Outros princípios incluem:
• Atribuir patrocínio executivo para responsabilidade
• Educar os funcionários sobre as responsabilidades de governança da informação
• Classifique as informações sob o código de registro correto ou categoria de taxonomia

• Garantir a autenticidade e integridade das informações

• Determinar que o registro oficial é eletrônico, a menos que especificado de forma diferente
• Desenvolver políticas para alinhamento de sistemas de negócios e terceiros à governança da informação
padrões
• Armazenar, gerenciar, tornar acessível, monitorar e auditar repositórios e sistemas corporativos aprovados para
registros e conteúdo
• Proteja informações confidenciais ou de identificação pessoal

• Controlar o crescimento desnecessário de informações
• Descarte as informações quando atingirem o fim de seu ciclo de vida
• Atender às solicitações de informações (por exemplo, descoberta, intimação, etc.)
• Melhorar continuamente
O Modelo de Referência de Governança da Informação (IGRM) (Figura 74) mostra a relação da Governança da Informação com
outras funções organizacionais. O anel externo inclui as partes interessadas que implementam políticas, padrões, processos,
ferramentas e infraestrutura para gerenciar informações. O centro mostra um diagrama de ciclo de vida com cada componente do
ciclo de vida dentro da cor ou cores das partes interessadas que executam esse componente. O IGRM complementa o GARP® da
ARMA.
Figura 74 Modelo de Referência de Governança da Informação 54
54 EDRM (edrm.net). O conteúdo postado em EDRM.net está licenciado sob uma Licença Creative Commons Atribuição 3.0 Não Adaptada.
342 • DMBOK2
O patrocínio de alguém próximo ou dentro da suíte 'C' é um requisito crítico para a formação e sustentabilidade do programa de Governança
da Informação. É estabelecido um Conselho de Informação de nível sênior multifuncional ou Comitê de Direção que se reúne regularmente.
O Conselho é responsável por uma estratégia de Governança da Informação corporativa, procedimentos operacionais, orientação sobre
tecnologia e padrões, comunicações e treinamento, monitoramento e financiamento. As políticas de Governança da Informação são escritas
para as áreas das partes interessadas e, em seguida, a tecnologia ideal é aplicada para aplicação.
6.2 Proliferação de Informações
Geralmente, os dados não estruturados crescem muito mais rápido do que os dados estruturados. Isso aumenta o desafio da governança.
Os dados não estruturados não estão necessariamente vinculados a uma função ou departamento de negócios. Sua propriedade pode ser
difícil de determinar. Também pode ser difícil classificar o conteúdo de dados não estruturados, pois a finalidade comercial do conteúdo nem
sempre pode ser inferida do sistema. Dados não estruturados não gerenciados, sem metadados necessários, representam risco. Pode ser
mal interpretado e, se o conteúdo não for conhecido, pode ser mal tratado ou apresentar problemas de privacidade. (Consulte o Capítulo 14.)
6.3 Governança para Conteúdo de Qualidade
O gerenciamento de dados não estruturados requer uma parceria eficaz entre administradores de dados e outros profissionais de
gerenciamento de dados e gerentes de registros. Por exemplo, administradores de dados de negócios podem ajudar a definir portais da
Web, taxonomias corporativas, índices de mecanismos de pesquisa e problemas de gerenciamento de conteúdo.
A governança de documentos e conteúdo concentra-se em políticas relacionadas à retenção, assinaturas eletrônicas, formatos de relatórios
e distribuição de relatórios. As políticas implicarão ou declararão expectativas sobre a qualidade. Informações precisas, completas e
atualizadas ajudarão na tomada de decisões. Informações de alta qualidade melhoram a vantagem competitiva e aumentam a eficácia
organizacional. Definir conteúdo de qualidade requer entender o contexto de sua produção e uso.
• Produtores: Quem cria o conteúdo e por que eles o criam?
• Consumidores: Quem usa as informações e para que finalidades?
• Tempo: Quando a informação é necessária? Com que frequência ele precisa ser atualizado ou acessado?
• Formato: O consumidor precisa do conteúdo em um formato específico para atingir seus objetivos? Existem
formatos inaceitáveis?
• Entrega: Como as informações serão entregues? Como os consumidores acessarão as informações? Como vai
segurança seja aplicada para prevenir o acesso inapropriado ao conteúdo eletrônico?

6.4 Métricas
Os Indicadores Chave de Desempenho (KPIs) são medidas quantitativas e qualitativas usadas para analisar o desempenho organizacional em
relação aos seus objetivos. Os KPIs podem ser desenvolvidos nos níveis estratégico e operacional. Alguns KPIs podem ser apropriados para ambos
os níveis, especialmente se medirem funções ou riscos do ciclo de vida.
6.4.1 Gerenciamento de Registros
No nível estratégico, os KPIs podem ser desenvolvidos dentro dessas áreas de conformidade de gerenciamento de registros com requisitos
regulatórios (por exemplo, tempo necessário para atender aos requisitos) e/ou governança (por exemplo, conformidade com políticas). No nível
operacional, os KPIs podem ser desenvolvidos dentro dessas áreas de recursos de gerenciamento de registros (por exemplo, custos operacionais e
de capital), treinamento (por exemplo, número de aulas ministradas, número de funcionários treinados e em que nível), prestação de serviços diários
de gerenciamento de registros e operações (por exemplo, porcentagem de atendimento aos SLAs do usuário) e/ou integração de funções de
gerenciamento de registros com outros sistemas de negócios (por exemplo, porcentagem de integração).
Os critérios para medir o sucesso da implementação de um sistema de gerenciamento de registros podem incluir os seguintes
porcentagens:
• Porcentagem do total de documentos e e-mail por usuário identificado como registros corporativos
• Percentual dos registros corporativos identificados declarados como tal e colocados sob controle de registros
• Porcentagem do total de registros armazenados que têm as regras de retenção adequadas aplicadas
Essas porcentagens podem ser comparadas para determinar as porcentagens de práticas recomendadas.
Às vezes, medir o sucesso da implementação do gerenciamento de registros é uma simples questão orçamentária. Uma determinação financeira
examina em que ponto a implantação de um sistema de gerenciamento de registros eletrônicos se torna menos dispendiosa do que adquirir mais
espaço para armazenar registros em papel.
As categorias de princípios GARP da ARMA e o modelo de maturidade podem orientar a definição de KPIs. A plataforma de software de avaliação
de governança de informações da ARMA pode identificar riscos de conformidade relacionados a informações e desenvolver métricas para maturidade
do programa de governança em áreas como registros eletrônicos e descoberta eletrônica (por exemplo, retenções de litígios).
6.4.2 Descoberta eletrônica
Um KPI comum de e-discovery é a redução de custos. Outro KPI é a eficiência obtida na coleta de informações antecipadamente de forma bastante
reativa (por exemplo, tempo médio em dias para responder às solicitações de e-discovery). A rapidez com que uma organização pode implementar
um processo de notificação de retenção legal (LHN) é o terceiro tipo de KPI.
A medição da descoberta eletrônica é fundamental para uma melhor taxa de vitórias em litígios. O modelo EDRM pode orientar o desenvolvimento
de KPIs com base no que é exigido por cada fase. A ERDM também publica um Modelo de Métricas para e-
344 • DMBOK2
métricas de descoberta.55 Os elementos primários de Volume, Tempo e Custo estão no centro, cercados pelos sete aspectos do trabalho de descoberta
eletrônica (atividades, custodiantes, sistemas, mídia, status, formato e controle de qualidade) que afetam o
resultado dos elementos centrais.
6.4.3 ECM
Os KPIs devem ser desenvolvidos para medir os benefícios tangíveis e intangíveis do ECM. Os benefícios tangíveis incluem maior produtividade, redução de
custos, melhor qualidade das informações e melhor conformidade. Os benefícios intangíveis incluem colaboração aprimorada e simplificação de rotinas de
trabalho e fluxo de trabalho.
À medida que o ECM está sendo estabelecido, os KPIs se concentrarão no programa e nas métricas operacionais. As métricas do programa incluem o número
de projetos de ECM, adoção e níveis de satisfação do usuário. As métricas operacionais incluem os KPIs típicos do tipo de sistema, como a quantidade de
tempo de inatividade, número de usuários etc.
Métricas específicas de ECM, como utilização de armazenamento (por exemplo, comparação de quantidade usada com implementação de ECM versus
quantidade usada antes de ECM) e desempenho de recuperação de pesquisa também podem ser usadas como KPIs. A recuperação da informação é medida
pela precisão e pela recuperação. Precisão é a proporção dos documentos recuperados que são realmente relevantes. Recall é uma proporção de todos os
documentos relevantes que são realmente recuperados.
Com o tempo, os KPIs relacionados ao valor das soluções de negócios podem ser desenvolvidos.
• Os KPIs financeiros podem incluir o custo do sistema ECM, custos reduzidos relacionados ao armazenamento físico e
redução percentual nos custos operacionais.
• Os KPIs do cliente podem incluir a porcentagem de incidentes resolvidos no primeiro contato e o número de clientes
reclamações.
• KPIs que representam processos de negócios internos mais eficazes e produtivos podem incluir porcentagem de
papelada reduzida, porcentagem de redução de erros usando workflow e automação de processos.
• Os KPIs de treinamento podem incluir o número de sessões de treinamento para gerenciamento e não gerenciamento.
• Os KPIs de mitigação de risco podem incluir redução de custos de descoberta e número de trilhas de auditoria de rastreamento e
solicitações de descoberta.

Boico, Bob. Bíblia de gerenciamento de conteúdo. 2ª edição. Wiley, 2004. Impresso.
55 Modelo de Métricas EDRM, http://bit.ly/2rURq7R.

Diamante, Davi. Metadados para gerenciamento de conteúdo: projetando taxonomia, metadados, política e fluxo de trabalho para tornar os sistemas de
conteúdo digital melhores para os usuários. CreateSpace, 2016. Imprimir.
Hedden, Heather. O Taxonomista Acidental. Information Today, Inc., 2010. Imprimir.
Lambe, Patrick. Organizando o Conhecimento: Taxonomias, Conhecimento e Eficácia Organizacional. Editora Chandos, 2007. Impresso. Gestão do
Conhecimento Chandos.
Liu, Bing. Mineração de dados da Web: explorando hiperlinks, conteúdo e dados de uso. 2ª edição. Springer, 2011. Impresso. Sistemas e aplicativos
centrados em dados.
NICHOLS, Kevin. Estratégia de conteúdo empresarial: um guia de projeto. XML Press, 2015. Impresso.
Leia, Judith e Mary Lea Ginn. Gerenciamento de Registros. 9ª edição. Cengage Learning, 2015. Imprimir. Sistemas e Procedimentos Avançados de
Escritório.
Rockley, Ann e Charles Cooper. Gerenciando o conteúdo corporativo: uma estratégia de conteúdo unificada. 2ª edição. Novos Cavaleiros, 2012.
Imprimir. Vozes que importam.
Smallwood, Robert F. Governança da Informação: Conceitos, Estratégias e Melhores Práticas. Wiley, 2014. Impresso. Wiley CIO.
Projeto de Taxonomia de Demonstrações Financeiras em US GAAP. Taxonomias XBRL US GAAP. v1.0 Guia Técnico Número do Documento: SECOFM-
USGAAPT-TechnicalGuide. Versão 1.0. 28 de abril de 2008 http://bit.ly/2rRauZt.
CAPÍTULO 1 0
Dados mestre e de referência
Dados
Modelagem de dados
Qualidade dos dados
& Operações
Dados Dados
Metadados

& O negócio
Interoperabilidade
Inteligência
& Mestre & Contente
Dados Gestão

1. Introdução
Em qualquer organização, determinados dados são necessários em todas as áreas de negócios, processos e sistemas. O geral
EUorganização e seus clientes se beneficiam se esses dados forem compartilhados e todas as unidades de negócios puderem acessar os mesmos
listas de clientes, códigos de localização geográfica, listas de unidades de negócios, opções de entrega, listas de peças, códigos de centros de
custos contábeis, códigos de impostos governamentais e outros dados usados para administrar os negócios. As pessoas que usam dados geralmente
supõem que existe um nível de consistência em toda a organização, até que vejam dados díspares.
347
348 • DMBOK2
Na maioria das organizações, os sistemas e os dados evoluem de forma mais orgânica do que os profissionais de gerenciamento de
dados gostariam. Particularmente em grandes organizações, vários projetos e iniciativas, fusões e aquisições e outras atividades de
negócios resultam em vários sistemas executando essencialmente as mesmas funções, isolados uns dos outros.
Essas condições inevitavelmente levam a inconsistências na estrutura de dados e valores de dados entre sistemas. Essa variabilidade
aumenta os custos e os riscos. Ambos podem ser reduzidos através do gerenciamento de Master Data e
Data de referência.
Dados mestre e de referência

Definição: Gerenciar dados compartilhados para atender às metas organizacionais, reduzir os riscos associados à
redundância de dados, garantir maior qualidade e reduzir os custos de integração de dados.
Metas:
1. Permita o compartilhamento de ativos de informações entre domínios de negócios e aplicativos dentro de uma organização.
2. Fornecer fonte oficial de dados mestre e de referência reconciliados e com avaliação de qualidade.
3. Menor custo e complexidade por meio do uso de padrões, modelos de dados comuns e padrões de integração.
O negócio
Motoristas

• Direcionadores de Negócios 1. Identificar Drivers e Requisitos (P) • Mestre e
• Cross funcional 1. Validar Definições de Dados (C) Data de referência
2. Avaliar e avaliar as fontes de dados (P)
Requisitos Requisitos •
3. Definir a abordagem arquitetônica (D)
• Padrões industriais Modelos de Dados e
4. Dados do Modelo (D)
• Glossário de Dados 5. Definir administração e manutenção Padrões de Integração
• Dados adquiridos • Referência confiável
Processos (C)
e/ou Dados Abertos 6. Estabelecer Políticas de Governança (C) e dados mestre
e conjuntos de códigos 7. Implemente o Compartilhamento/Integração de Dados • Dados reutilizáveis
Serviços (D,O)
• Regras do negócio Serviços
1. Adquira fontes de dados para compartilhamento
2. Publicar referência e dados mestre

• Analistas de Dados • Analistas de dados mestres
• Administradores de dados • Modeladores de Dados • Integradores de dados
•
Desenvolvedores de aplicativos • Administradores de dados • Arquitetos de Dados
• Provedores de dados
•
• Integradores de dados • Usuários de aplicativos
Analistas de negócios • Arquitetos de Dados
• • Inscrição
Sistemas de Infraestrutura
• Analistas de Qualidade de Dados Desenvolvedores
Analistas
• Arquitetos de Soluções
Técnico
Motoristas

Condições de uso • Ferramentas de modelagem de dados •
Qualidade de dados e
acordos • Repositórios de Metadados Observância
• •
Atividade de alteração de dados
Cruz chave de negócios • Ferramentas de Perfil e Qualidade de Dados
•
referências • Ferramentas de Integração de Dados Consumo de dados e
Serviços
• Análise de Log de Processamento • Plataformas de aplicativos MDM •
Disponibilidade de Compartilhamento de Dados
• Compartilhamento/Integração de Dados •
Cobertura do Administrador de Dados
Arquitetura •
Volume de compartilhamento de dados
e Utilização
Figura 75 Diagrama de contexto: referência e dados mestre

REFERÊNCIA E DADOS PRINCIPAIS • 349
Os drivers mais comuns para iniciar um programa de gerenciamento de dados mestres são:
• Atender aos requisitos de dados organizacionais: várias áreas dentro de uma organização precisam de acesso ao
mesmos conjuntos de dados, com a confiança de que os conjuntos de dados são completos, atuais e consistentes. Dados mestre
muitas vezes formam a base desses conjuntos de dados (por exemplo, determinar se uma análise inclui todos os clientes
depende de ter uma definição consistentemente aplicada de um cliente).
• Gerenciando a qualidade dos dados: inconsistências de dados, problemas de qualidade e lacunas levam a decisões incorretas ou
oportunidades perdidas; O Master Data Management reduz esses riscos, permitindo uma
representação das entidades críticas para a organização.
• Gerenciando os custos de integração de dados: O custo de integração de novas fontes de dados em um já
ambiente complexo são maiores na ausência de dados mestre, o que reduz a variação de quão crítico
entidades são definidas e identificadas.
• Redução de risco: Master Data pode permitir a simplificação da arquitetura de compartilhamento de dados para reduzir custos e
risco associado a um ambiente complexo.
Os drivers para gerenciar dados de referência são semelhantes. Dados de referência gerenciados centralmente permitem que as organizações
para:
• Atenda aos requisitos de dados para várias iniciativas e reduza os riscos e custos da integração de dados
através do uso de Dados de Referência consistentes
• Gerenciar a qualidade dos Dados de Referência
Embora as iniciativas organizacionais orientadas por dados se concentrem em dados transacionais (aumento de vendas ou participação de
mercado, redução de custos, demonstração de conformidade), a capacidade de alavancar esses dados transacionais depende muito da
disponibilidade e qualidade dos dados mestre e de referência. Melhorar a disponibilidade e a qualidade dos dados mestre e de referência tem
um impacto dramático na qualidade geral dos dados e na confiança dos negócios nos dados.
Esses processos trazem benefícios adicionais para uma organização, incluindo a simplificação do cenário de TI, eficiência e produtividade
aprimoradas e, com isso, o potencial de melhorar a experiência do cliente.
Os objetivos de um programa de Referência e Gerenciamento de Dados Mestres incluem:
• Garantir que a organização tenha dados mestre e de referência completos, consistentes, atuais e confiáveis
em todos os processos organizacionais
• Permitir que dados mestre e de referência sejam compartilhados entre funções e aplicativos corporativos
350 • DMBOK2
• Reduzir o custo e reduzir a complexidade do uso e integração de dados por meio de padrões, modelos de dados comuns e
padrões de integração
O gerenciamento de dados mestre e de referência seguem estes princípios orientadores:
• Dados compartilhados: os dados mestre e de referência devem ser gerenciados para que possam ser compartilhados em todo o
organização.
• Propriedade: Os dados mestre e de referência pertencem à organização, não a um aplicativo ou departamento específico. Por serem
amplamente compartilhados, exigem um alto nível de administração.
• Qualidade: Referência e Gerenciamento de Dados Mestres exigem monitoramento contínuo da Qualidade dos Dados e
governança.
• Stewardship: os Business Data Stewards são responsáveis por controlar e garantir a qualidade de
Data de referência.
• Mudança Controlada:
o Em um determinado ponto do tempo, os valores de dados mestres devem representar os melhores
compreensão do que é preciso e atual. As regras de correspondência que alteram os valores devem ser aplicadas
com cautela e supervisão. Qualquer identificador mesclado ou dividido deve ser reversível. o As alterações nos
valores dos Dados de Referência devem seguir um processo definido; mudanças devem ser
aprovados e comunicados antes de serem implementados.
• Autoridade: os valores dos Dados Mestres devem ser replicados apenas a partir do sistema de registro. Um sistema de
referência pode ser necessário para permitir o compartilhamento de dados mestres em uma organização.
1.3.1 Diferenças entre dados mestre e de referência
Diferentes tipos de dados desempenham papéis diferentes dentro de uma organização. Eles também têm diferentes requisitos de gerenciamento.
Muitas vezes é feita uma distinção entre dados de transação e dados mestre, bem como entre dados mestre e dados de referência. Malcolm
Chisholm propôs uma taxonomia de dados de seis camadas que inclui metadados, dados de referência, dados de estrutura empresarial, dados
de estrutura de transação, dados de atividade de transação e dados de auditoria de transação (Chisholm, 2008; Talburt e Zhou, 2015). Dentro
dessa taxonomia, ele define Dados Mestres como uma agregação de Dados de Referência, dados de estrutura empresarial e dados de estrutura
de transação:
• Dados de referência, por exemplo, tabelas de código e descrição, são dados usados exclusivamente para caracterizar
outros dados em uma organização, ou apenas para relacionar dados em um banco de dados a informações além dos
limites da organização.
DADOS DE REFERÊNCIA E MESTRES • 351
• Dados de estrutura empresarial, por exemplo, um plano de contas, permite relatar a atividade de negócios por
responsabilidade empresarial.
• Dados de estrutura de transação, por exemplo, identificadores de cliente, descrevem as coisas que devem estar presentes
para que uma transação ocorra: produtos, clientes, fornecedores.
A definição de Chisholm distingue Dados Mestres de dados de atividade de transações que registram detalhes sobre transações e de dados de
auditoria de transações que descrevem o estado das transações, bem como de Metadados,
que descreve outros dados (Chisholm, 2008). A este respeito, a definição de Chisholm é semelhante à definição do Dicionário DAMA: Dados
mestres são “os dados que fornecem o contexto para os dados da atividade de negócios na forma de conceitos comuns e abstratos relacionados
à atividade. Inclui os detalhes (definições e identificadores) de objetos internos e externos envolvidos nas transações comerciais, como clientes,
produtos, funcionários, fornecedores e domínios controlados (valores de código)” (DAMA, 2009).
Muitas pessoas entendem que Dados Mestres incluem dados de estrutura de transação e dados de estrutura corporativa.
A definição de dados mestre de David Loshin alinha-se amplamente com esses tipos. Ele descreve os objetos Master Data como objetos de
negócios principais usados em diferentes aplicativos em uma organização, juntamente com seus Metadados, atributos, definições, funções,
conexões e taxonomias associados. Os objetos Master Data representam as 'coisas' que mais importam para uma organização – aquelas que
são registradas em transações, relatadas, medidas, analisadas (Loshin, 2008).
Dados mestres exigem a identificação e/ou desenvolvimento de uma versão confiável da verdade para cada instância de entidades conceituais,
como produto, local, conta, pessoa ou organização, e a manutenção da validade dessa versão.
O principal desafio com Master Data é a resolução de entidade (também chamada de gerenciamento de identidade), o processo de discernir e
gerenciar associações entre dados de diferentes sistemas e processos. As instâncias de entidade representadas por linhas de dados mestres
serão representadas de forma diferente nos sistemas. O Master Data Management trabalha para resolver essas diferenças a fim de identificar
consistentemente instâncias de entidades individuais (ou seja, clientes específicos, produtos etc.) em diferentes contextos. Esse processo
também deve ser gerenciado ao longo do tempo, para que os identificadores dessas instâncias de entidade de dados mestres permaneçam
consistentes.56
Dados de referência e dados mestre compartilham propósitos conceitualmente semelhantes. Ambos fornecem contexto crítico para a criação e
uso de dados transacionais. (Dados de referência também fornecem contexto para dados mestres.) Eles permitem que os dados sejam
compreendidos de forma significativa. É importante ressaltar que ambos são recursos compartilhados que devem ser gerenciados no nível
corporativo. Ter várias instâncias dos mesmos Dados de Referência é ineficiente e inevitavelmente leva à inconsistência entre elas. A
inconsistência leva à ambiguidade, e a ambiguidade introduz riscos para uma organização. Um programa de Dados de Referência ou
Gerenciamento de Dados Mestres bem-sucedido envolve toda a gama de funções de gerenciamento de dados (Governança de Dados,
Qualidade de Dados, Gerenciamento de Metadados, Integração de Dados, etc.).
Os Dados de Referência também possuem características que os distinguem de outros tipos de Dados Mestres (por exemplo, dados de estrutura
empresarial e transacional). É menos volátil. Conjuntos de dados de referência são geralmente menos complexos e menores do que
56 John Talburt e Yinle Zhou (2015) descrevem o processo de duas etapas em ER: primeiro, determinar se dois registros se referem à
mesma entidade, depois mesclar e reconciliar os dados nos registros para criar um registro mestre. Eles se referem ao Gerenciamento de
Informações de Identidade de Entidade (EIIM) como o processo de garantir que “uma entidade sob gerenciamento no sistema MDM seja
rotulada consistentemente com o mesmo identificador exclusivo de processo para processo”.
352 • DMBOK2
conjuntos de dados transacionais ou mestres. Eles têm menos colunas e menos linhas. Os desafios de resolução de entidades não fazem parte do Reference
Data Management.
O foco do gerenciamento de dados difere entre Dados de Referência e Dados Mestres:
• O Gerenciamento de Dados Mestres (MDM) envolve o controle sobre os valores e identificadores dos Dados Mestres que permitem
uso consistente, em todos os sistemas, dos dados mais precisos e oportunos sobre entidades comerciais essenciais.
Os objetivos do MDM incluem garantir a disponibilidade de valores precisos e atuais, reduzindo os riscos
associados a identificadores ambíguos (aqueles identificados com mais de uma instância de uma entidade e
aqueles que se referem a mais de uma entidade).
• Reference Data Management (RDM) envolve controle sobre valores de domínio definidos e seus
definições. O objetivo do RDM é garantir que a organização tenha acesso a um conjunto completo de informações precisas e
valores atuais para cada conceito representado.
Um desafio do Reference Data Management é a propriedade ou responsabilidade pela definição e manutenção. Alguns Dados de Referência se originam
fora das organizações que os utilizam. Alguns cruzam os limites organizacionais internos e podem não pertencer a um único departamento. Outros Dados
de Referência podem ser criados e mantidos dentro de um departamento, mas têm valor potencial em outras partes da organização. Determinar a
responsabilidade pela obtenção de dados e gerenciamento de atualizações faz parte do RDM. A falta de responsabilidade introduz riscos, pois diferenças
nos Dados de Referência podem causar mal-entendidos no contexto dos dados (como quando duas unidades de negócios têm valores diferentes para
classificar o mesmo conceito).
Como os dados mestre e de referência fornecem contexto para transações, eles moldam os dados de transação que entram em uma organização durante
as operações (por exemplo, em sistemas CRM e ERP). Eles também enquadram a análise realizada em Dados de Transação.
1.3.2 Dados de Referência
Como observado, Dados de Referência são quaisquer dados usados para caracterizar ou classificar outros dados, ou para relacionar dados a informações
externas a uma organização (Chisholm, 2001). Os Dados de Referência mais básicos consistem em códigos e descrições, mas alguns Dados de Referência
podem ser mais complexos e incorporar mapeamentos e hierarquias.
Dados de referência existem em praticamente todos os armazenamentos de dados. As classificações e categorias podem incluir status ou tipos (por
exemplo, Status do pedido: Novo, Em andamento, Fechado, Cancelado). As informações externas podem incluir informações geográficas ou de padrões
(por exemplo, Código do país: DE, US, TR).
Os Dados de Referência podem ser armazenados de diferentes maneiras para atender às diferentes necessidades. Por exemplo, integração de dados (por
exemplo, mapeamentos de dados para padronização ou verificações de qualidade de dados) ou outra funcionalidade do aplicativo (por exemplo, anéis de
sinônimos para permitir pesquisa e descoberta). Ele também pode ter considerações de interface de usuário específicas do dispositivo (por exemplo, vários
idiomas). Técnicas de armazenamento comuns usam:
• Tabelas de código em bancos de dados relacionais, vinculadas por meio de chaves estrangeiras a outras tabelas para manter o referencial
funções de integridade dentro do sistema de gerenciamento de banco de dados

• Sistemas de gerenciamento de dados de referência que mantêm entidades de negócios, permitidas, de estado futuro ou
valores obsoletos e regras de mapeamento de termos para dar suporte ao uso mais amplo de aplicativos e integração de dados
• Metadados específicos de atributo de objeto para especificar valores permitidos com foco na API ou na interface do usuário
Acesso
O Reference Data Management envolve o controle e a manutenção de valores de domínio definidos, definições e relacionamentos dentro e entre
valores de domínio. O objetivo do Reference Data Management é garantir que os valores sejam consistentes e atuais em diferentes funções e que
os dados sejam acessíveis à organização. Assim como outros dados, os Dados de Referência requerem Metadados. Um atributo de metadados
importante para dados de referência inclui sua origem.
Por exemplo, o órgão regulador para Dados de Referência padrão do setor.
1.3.2.1 Estrutura de Dados de Referência
Dependendo da granularidade e complexidade do que os Dados de Referência representam, eles podem ser estruturados como uma lista simples,
uma referência cruzada ou uma taxonomia. A capacidade de usar e manter Dados de Referência deve ser considerada ao estruturá-los em um
banco de dados ou um sistema de Gerenciamento de Dados de Referência.
1.3.2.1.1 Listas
A forma mais simples de Dados de Referência combina um valor de código com uma descrição em uma lista, como na Tabela 17. O valor de
código é o identificador primário, o valor de referência de forma abreviada que aparece em outros contextos. A descrição indica o que o código
representa. A descrição pode ser exibida no lugar do código em telas, páginas, listas suspensas e relatórios. Observe que, neste exemplo, o valor
do código para Reino Unido é GB de acordo com os padrões internacionais, e não Reino Unido, embora Reino Unido seja uma forma abreviada
comum usada em muitas formas de comunicação. Equilíbrio entre conformidade com padrões e usabilidade ao definir os requisitos de Dados de
Referência.
Tabela 17 Lista de Referência Simples
Valor do código Descrição

NÓS Estados Unidos da América
GB Reino Unido (Grã-Bretanha)
Dependendo do conteúdo e da complexidade dos Dados de Referência, atributos adicionais podem ser necessários para definir o significado do
código. As definições fornecem informações que o rótulo por si só não fornece. As definições raramente aparecem em relatórios ou listas
suspensas. No entanto, eles aparecem em locais como funções de Ajuda para aplicativos, que orientam o uso apropriado de códigos no contexto.
As listas, como qualquer dado de referência, devem atender aos requisitos dos consumidores de dados, incluindo os requisitos para o nível
apropriado de detalhes. Se uma lista de valores destina-se a dar suporte à classificação de dados por usuários casuais, uma lista altamente
detalhada provavelmente causará problemas de qualidade de dados e desafios de adoção. Da mesma forma, uma lista de valores muito genérica
impediria os trabalhadores do conhecimento de capturar um nível suficiente de detalhes. Para acomodar tal
354 • DMBOK2
Em alguns casos, é melhor manter listas distintas relacionadas ao invés de tentar ter uma única lista que seja o padrão para todas as
comunidades de usuários. A Tabela 18 fornece um exemplo relacionado a códigos de status para tickets de suporte técnico. Sem as
informações fornecidas pela definição, o status do ticket seria ambíguo para qualquer pessoa não familiarizada com o sistema.
Essa diferenciação é especialmente necessária para classificações que direcionam métricas de desempenho ou outras análises de
Business Intelligence.
Tabela 18 Lista de Referência Simples Expandida
Código Descrição 1 Definição

Novo Indica um ticket recém-criado sem um recurso atribuído
2 Atribuído Indica um ticket que tem um recurso nomeado atribuído
3 Trabalho em andamento Indica que o recurso atribuído começou a trabalhar no ticket
4 Resolvido Indica que a solicitação é considerada atendida pelo recurso atribuído
5 Cancelado Indica que a solicitação foi cancelada com base na interação do solicitante
6 Pendente Indica que a solicitação não pode prosseguir sem informações adicionais
7 Realizada Indica que a solicitação foi atendida e verificada pelo solicitante
1.3.2.1.2 Listas de Referências Cruzadas
Diferentes aplicativos podem usar conjuntos de códigos diferentes para representar o mesmo conceito. Esses conjuntos de códigos podem
estar em granularidades diferentes ou na mesma granularidade com valores diferentes. Os conjuntos de dados de referência cruzada
traduzem os valores dos códigos. A Tabela 19 apresenta uma referência cruzada do Código do Estado dos EUA (um exemplo de várias
representações no mesmo nível de grão). Os Códigos de Estado do Serviço Postal dos EUA são códigos alfa de dois caracteres. FIPS usa
um numérico para expressar o mesmo conceito. O Código de Estado ISO também inclui uma referência ao país.
Tabela 19 Lista de Referências Cruzadas
USPS Estado ISO FIPS Estado Estado Nome do Estado Formal
Estado Código Numérico Abreviação Nome
Código Código do Estado
ESTE EUA-CA 06 Califórnia Califórnia Estado da Califórnia

isto EUA-KY 21 Este. Kentucky Comunidade do Kentucky
WI EUA-WI 55 Já. Estado de Wisconsin
Os requisitos de idioma podem afetar a estrutura de dados de referência. As listas em vários idiomas são uma instância específica de uma
lista de referência cruzada. Embora as listas de códigos forneçam um formato padrão legível por máquina, os glossários específicos do
idioma fornecem conteúdo utilizável. A Tabela 20 fornece um exemplo do padrão ISO 3166. Existem diferentes maneiras de lidar com listas
de vários idiomas, dependendo de quantos idiomas e conjuntos de caracteres estão envolvidos. As listas não precisam ser normalizadas
para serem eficazes. A estrutura desnormalizada torna um pouco mais fácil de compreender os relacionamentos.
Tabela 20 Lista de Referências em Vários Idiomas
ISO 3166-1 Alfa 2 Nome inglês Nome local Nome local Francês …
Código do país Alfabeto local Nome
CN China Zhong Guo China China China

1.3.2.1.3 Taxonomias
Estruturas de Dados de Referência Taxonômicas capturam informações em diferentes níveis de especificidade. Por exemplo, um CEP dos EUA pode
ser uma categoria significativa em si e existe em uma cidade, um condado e um estado. Esses relacionamentos podem ser expressos na tabela de
referência e vários níveis de análise podem ser feitos usando ZIP

código como um driver.
As taxonomias permitem a classificação de conteúdo e a navegação multifacetada para dar suporte ao Business Intelligence.
Os Dados de Referência Taxonômica podem ser armazenados em um relacionamento recursivo. As ferramentas de gerenciamento de taxonomia
também mantêm informações hierárquicas. A Tabela 21 e a Tabela 22 mostram exemplos de duas taxonomias hierárquicas comuns. Em ambos os
casos, a hierarquia inclui um código, uma descrição e uma referência a um código pai que classifica os códigos individuais. Por exemplo, na Tabela
21, Plantas florais (10161600) é um código pai para Rosas, Poinsétias e Orquídeas. Na Tabela 22, Comércio de Varejo (440.000) é o pai de Lojas de
Alimentos e Bebidas (445.000), que é o pai de Lojas de Alimentos Especiais (445.200).
Tabela 21 UNSPSC (Classificação Padrão Universal de Produtos e Serviços) 57
Valor do código Descrição Código pai

10161600 Plantas florais 10160000
10161601 Plantas de rosas 10161600
10161602 Plantas de poinsétias 10161600
10161603 Plantas de orquídeas 10161600
10161700 Cortar flores 10160000
10161705 Cortar rosas 10161700
Tabela 22 NAICS (Sistema de Classificação da Indústria da América do Norte) 58
Código Valor Descrição Código pai

440000 445000 Comercio de varejo 440000
445200 445210 Lojas de alimentos e bebidas 440000
445220 445290 Lojas de comida especializada 445000
445291 445292 Mercados de carne 445200
Mercados de Peixes e Frutos do Mar 445200
Outras Lojas de Alimentos Especiais 445200

Lojas de Panificação 445290
Lojas de Confeitaria e Nozes 445290
1.3.2.1.4 Ontologias
Algumas organizações incluem ontologias usadas para gerenciar o conteúdo do site como parte dos Dados de Referência. Eles se encaixam nessa
categoria na medida em que são usados para caracterizar outros dados ou para relacionar dados organizacionais a informações além do
57
http://bit.ly/2sAMU06.
58
http://bit.ly/1mWACqg.
356 • DMBOK2
os limites da organização. Ontologias também podem ser entendidas como uma forma de Metadados. Ontologias e outras taxonomias
complexas precisam ser gerenciadas de maneira semelhante à forma como os Dados de Referência são gerenciados. Os valores
precisam ser completos, atuais e claramente definidos. As práticas recomendadas para manter ontologias são semelhantes às do
Gerenciamento de dados de referência. Um dos principais casos de uso para ontologias é o gerenciamento de conteúdo. Eles são
descritos com mais detalhes no Capítulo 9.
1.3.2.2 Dados de referência proprietários ou internos
Muitas organizações criam Dados de Referência para dar suporte a processos e aplicativos internos. Muitas vezes, esses dados de
referência proprietários geralmente crescem organicamente ao longo do tempo. Parte do RDM inclui gerenciar esses conjuntos de
dados e, idealmente, criar consistência entre eles, onde essa consistência atende à organização. Por exemplo, se diferentes unidades
de negócios usarem termos diferentes para descrever o status de uma conta, será difícil para qualquer pessoa na organização
determinar o número total de clientes atendidos em um determinado momento. Ao ajudar a gerenciar conjuntos de dados de
referência internos, os administradores de dados devem equilibrar a necessidade de ter palavras comuns para o mesmo
informação e a necessidade de flexibilidade onde os processos diferem uns dos outros.
1.3.2.3 Dados de Referência do Setor
Dados de referência do setor é um termo amplo para descrever conjuntos de dados criados e mantidos por associações do setor ou
órgãos governamentais, em vez de organizações individuais, a fim de fornecer um padrão comum para codificar conceitos
importantes. Essa codificação leva a uma maneira comum de entender os dados e é um pré-requisito para o compartilhamento e a
interoperabilidade de dados. Por exemplo, os códigos da Classificação Internacional de Doenças (CID) fornecem uma maneira
comum de classificar condições de saúde (diagnósticos) e tratamentos (procedimentos) e, assim, ter uma abordagem consistente
para prestar cuidados de saúde e compreender os resultados. Se cada médico e hospital criasse seu próprio conjunto de códigos
para doenças, seria praticamente impossível entender as tendências e
padrões.
Os Dados de Referência do Setor são produzidos e mantidos fora das organizações que os utilizam, mas são necessários para
entender as transações dentro dessas organizações. Pode ser necessário para dar suporte a esforços específicos de gerenciamento
de qualidade de dados (por exemplo, diretórios de negócios de terceiros), cálculos de negócios (por exemplo, taxas de câmbio) ou
aumento de dados de negócios (por exemplo, dados de marketing). Esses conjuntos de dados variam muito, dependendo do setor e
do conjunto de códigos individual. (Consulte o Capítulo 10.)
1.3.2.4 Dados Geográficos ou Geoestatísticos
A referência geográfica ou geoestatística permite a classificação ou análise com base na geografia. Por exemplo, os relatórios do
censo descrevem a densidade populacional e as mudanças demográficas que apoiam o planejamento e a pesquisa de mercado. O
histórico climático mapeado para uma classificação geográfica estrita pode apoiar o gerenciamento de estoque e o planejamento
promocional.
1.3.2.5 Dados de Referência Computacional
Muitas atividades de negócios dependem do acesso a cálculos comuns e consistentes. Por exemplo, os cálculos de câmbio dependem de tabelas
gerenciadas de valores de câmbio com registro de data e hora. Os Dados de Referência Computacional diferem de outros tipos devido à frequência com
que mudam. Muitas organizações compram esse tipo de dados de terceiros que garantem que sejam completos e precisos. A tentativa de manter esses
dados internamente provavelmente será repleta de problemas de latência.
1.3.2.6 Metadados do Conjunto de Dados de Referência Padrão
Dados de referência, como outros dados, podem mudar ao longo do tempo. Dada a sua prevalência em qualquer organização, é importante manter os
principais metadados sobre conjuntos de dados de referência para garantir que sua linhagem e moeda sejam compreendidas e mantidas. A Tabela 23
fornece exemplos desses Metadados.
Tabela 23 Atributos de metadados de dados de referência crítica
Conjunto de dados de referência Descrição
Informação chave
Nome formal Oficial, especialmente se for o nome externo do conjunto de dados de referência (por exemplo, lista
de códigos de país ISO 3166-1991)
Nome interno Nome associado ao conjunto de dados dentro da organização (por exemplo, Códigos de país – ISO)
Provedor de dados A parte que fornece e mantém o conjunto de dados de referência. Isso pode ser externo (ISO),
interno (um departamento específico) ou externo – estendido (obtido de uma parte externa, mas
depois estendido e modificado internamente).
Origem do conjunto de dados do provedor de dados Descrição de onde os conjuntos de dados do provedor de dados podem ser obtidos. Este é
provavelmente um Identificador de Recurso Universal (URI) dentro ou fora da rede corporativa.
Versão mais recente do provedor de dados Se disponível e mantido, descreve a versão mais recente do conjunto de dados do provedor
Número de dados externo em que as informações podem ser adicionadas ou substituídas da versão na
organização
Data da última versão do provedor de dados Se disponível e mantido, descreve quando a lista padrão foi
Ultima atualização
Número da versão interna Número da versão do conjunto de dados de referência atual ou número da versão da última
atualização que foi aplicada ao conjunto de dados

Reconciliação de versão interna Data em que o conjunto de dados foi atualizado pela última vez com base na fonte externa
Encontro
Versão interna Data da última atualização Data em que o conjunto de dados foi alterado pela última vez. Isso não significa reconciliação com
uma versão externa.
1.3.3 Dados Mestres
Dados mestres são dados sobre as entidades comerciais (por exemplo, funcionários, clientes, produtos, estruturas financeiras, ativos e locais) que fornecem
contexto para transações e análises comerciais. Uma entidade é um objeto do mundo real (pessoa, organização, lugar ou coisa). As entidades são
representadas por instâncias de entidades, na forma de dados/registros.

358 • DMBOK2
Os Dados Mestres devem representar os dados oficiais e mais precisos disponíveis sobre as principais entidades de negócios. Quando
bem gerenciados, os valores Master Data são confiáveis e podem ser usados com segurança.
Regras de negócios normalmente ditam o formato e os intervalos permitidos de valores de dados mestre. Organizacional comum
Dados mestres incluem dados sobre:
• Partes, compostas por indivíduos e organizações, e seus papéis, como clientes, cidadãos, pacientes,
vendedores, fornecedores, agentes, parceiros de negócios, concorrentes, funcionários ou estudantes
• Produtos e Serviços, internos e externos
• Estruturas financeiras, como contratos, contas do razão geral, centros de custo ou centros de lucro
• Locais, como endereços e coordenadas GPS
1.3.3.1 Sistema de Registro, Sistema de Referência
Quando existem versões potencialmente diferentes da 'verdade', é necessário distingui-las. Para isso, é preciso saber de onde os dados se
originam ou são acessados e quais dados foram preparados para usos específicos. Um Sistema de Registro é um sistema autoritário onde
os dados são criados/capturados e/ou mantidos por meio de um conjunto definido de regras e expectativas (por exemplo, um sistema ERP
pode ser o Sistema de Registro para clientes de venda).
Um Sistema de Referência é um sistema autoritário onde os consumidores de dados podem obter dados confiáveis para apoiar transações
e análises, mesmo que a informação não tenha origem no sistema de referência. Aplicativos MDM, Data Sharing Hubs e Data Warehouses
geralmente servem como sistemas de referência.
1.3.3.2 Fonte Confiável, Golden Record
Uma fonte confiável é reconhecida como a 'melhor versão da verdade' com base em uma combinação de regras automatizadas e
administração manual de conteúdo de dados. Uma fonte confiável também pode ser chamada de Single View, 360° View. Qualquer sistema
MDM deve ser gerenciado para que seja uma fonte confiável. Dentro de uma fonte confiável, os registros que representam os dados mais
precisos sobre instâncias de entidade podem ser chamados de Golden Records.
O termo Golden Record pode ser enganoso. A Tech Target define um Golden Record como “a 'versão única da verdade', onde 'verdade' é
entendida como a referência à qual os usuários de dados podem recorrer quando desejam garantir que tenham a versão correta de uma
informação. O registro dourado engloba todos os dados em cada sistema de registro (SOR) dentro de uma organização específica.”59
No entanto, as duas partes desta definição colocam o conceito em questão, pois os dados em diferentes sistemas podem não se alinhar
em 'uma única versão da verdade'.
Dentro de qualquer esforço de dados mestre, a fusão/resolução de dados de várias fontes em um 'Golden Record' não significa que é
sempre uma representação 100% completa e 100% precisa de todas as entidades dentro do
59 http://bit.ly/2rRJI3b.
organização (especialmente em organizações que possuem vários SORs fornecendo dados para o ambiente Master Data).
Prometer que os dados são 'Golden' quando não são pode minar a confiança dos consumidores de dados.
É por isso que alguns preferem o termo Fonte Confiável para se referir à “melhor versão que temos” dos Dados Mestres.
Isso coloca a ênfase em como os dados são definidos e gerenciados para obter a melhor versão. Também ajuda os diferentes
consumidores de dados a ver os componentes da 'versão única' que são importantes para eles. As áreas Financeira e Atuarial
muitas vezes têm uma perspectiva diferente de 'versão única' do Cliente do que a área de Marketing.
A Fonte Confiável fornece várias perspectivas de entidades de negócios conforme identificadas e definidas por Dados
Comissários.
1.3.3.3 Gerenciamento de dados mestre
Conforme descrito na introdução do capítulo, o Master Data Management envolve o controle sobre os valores e identificadores
de Master Data que permitem o uso consistente, em todos os sistemas, dos dados mais precisos e oportunos sobre entidades
comerciais essenciais. Os objetivos incluem garantir a disponibilidade de valores precisos e atuais, reduzindo o risco de
identificadores ambíguos.
O Gartner define o Gerenciamento de Dados Mestres como “uma disciplina habilitada para tecnologia na qual negócios e TI
trabalham juntos para garantir a uniformidade, precisão, administração, consistência semântica e responsabilidade dos ativos de
Dados Mestres compartilhados da empresa. Dados mestres são o conjunto consistente e uniforme de identificadores e atributos
estendidos que descrevem as principais entidades da empresa, incluindo clientes, prospects, cidadãos, fornecedores, sites,
hierarquias e plano de contas.”60
A definição do Gartner enfatiza que o MDM é uma disciplina, composta por pessoas, processos e tecnologia. Não é uma solução
de aplicação específica. Infelizmente, o acrônimo MDM (Master Data Management) é frequentemente usado para se referir a
sistemas ou produtos usados para gerenciar Dados Mestres. gerenciada para atender às necessidades organizacionais.
A avaliação dos requisitos de MDM de uma organização inclui identificar:
• Quais funções, organizações, lugares e coisas são referenciadas repetidamente

• Quais dados são usados para descrever pessoas, organizações, lugares e coisas
• Como os dados são definidos e estruturados, incluindo a granularidade dos dados
• Onde os dados são criados/originados, armazenados, disponibilizados e acessados
• Como os dados mudam à medida que se movem pelos sistemas dentro da organização
• Quem usa os dados e para quais finalidades
• Quais critérios são usados para entender a qualidade e confiabilidade dos dados e suas fontes
60
http://gtnr.it/2rQOT33.
61 Observe que, em todo o DAMA-DMBOK, o MDM refere-se ao processo geral de gerenciamento de dados mestres, e não apenas às
ferramentas usadas para gerenciar esses dados.
360 • DMBOK2
O gerenciamento de dados mestres é um desafio. Ele ilustra um desafio fundamental com dados: as pessoas escolhem maneiras diferentes de representar
conceitos semelhantes e a reconciliação entre essas representações nem sempre é direta; tão importante quanto, as informações mudam ao longo do tempo
e contabilizar sistematicamente essas mudanças requer planejamento, conhecimento de dados e habilidades técnicas. Resumindo, dá trabalho.
Qualquer organização que tenha reconhecido a necessidade de MDM provavelmente já possui um cenário de sistema complexo, com várias maneiras de
capturar e armazenar referências a entidades do mundo real. Por causa do crescimento orgânico ao longo do tempo ou de fusões e aquisições, os sistemas
que forneceram entrada para o processo de MDM podem ter definições diferentes das próprias entidades e muito provavelmente têm padrões diferentes para
Qualidade de Dados.
Devido a essa complexidade, é melhor abordar o Master Data Management um domínio de dados por vez. Comece pequeno, com um punhado de atributos,
e construa com o tempo.
O planejamento do Master Data Management inclui várias etapas básicas. Dentro de um domínio:
• Identificar fontes candidatas que fornecerão uma visão abrangente das entidades de dados mestres
• Desenvolva regras para combinar e mesclar com precisão instâncias de entidade
• Estabelecer uma abordagem para identificar e restaurar dados combinados e mesclados inadequadamente
• Estabelecer uma abordagem para distribuir dados confiáveis para sistemas em toda a empresa
A execução do processo, no entanto, não é tão simples quanto essas etapas implicam, pois o MDM é um processo de gerenciamento do ciclo de vida. As
atividades críticas para o ciclo de vida incluem:
• Estabelecer o contexto de entidades de dados mestres, incluindo definições de atributos associados e o
condições de seu uso. Esse processo requer governança.
• Identificar várias instâncias da mesma entidade representada dentro e entre fontes de dados; prédio
e manutenção de identificadores e referências cruzadas para permitir a integração de informações.
• Reconciliar e consolidar dados entre fontes para fornecer um registro mestre ou a melhor versão do
verdade. Os registros consolidados fornecem uma visão mesclada das informações entre os sistemas e procuram abordar
inconsistências de nomenclatura de atributos e valores de dados.
• Identificar instâncias combinadas ou mescladas incorretamente e garantir que elas sejam resolvidas e corretamente
associados a identificadores.
• Provisionamento de acesso a dados confiáveis entre aplicativos, seja por meio de leituras diretas, serviços de dados ou
por feeds de replicação para armazenamentos de dados transacionais, de armazenamento ou analíticos.
• Reforçar o uso de valores de Master Data dentro da organização. Esse processo também requer governança
e gerenciamento de mudanças para garantir uma perspectiva corporativa compartilhada.
1.3.3.4 Etapas de processamento de chave de gerenciamento de dados mestre
As principais etapas de processamento para MDM são ilustradas na Figura 76. Elas incluem gerenciamento de modelo de dados; aquisição de dados;
validação, padronização e enriquecimento de dados; resolução da entidade; e mordomia e partilha.
Em um ambiente MDM abrangente, o modelo de dados lógicos será instanciado fisicamente em várias plataformas. Ele orienta a implementação da solução
MDM, fornecendo a base dos serviços de integração de dados. Isto

deve orientar como os aplicativos são configurados para aproveitar os recursos de reconciliação de dados e verificação de qualidade
de dados.
Modelo de dados Dados Data de validade,

Entidade Compartilhamento de dados e
Gestão Aquisição Padronização e Resolução Mordomia

Enriquecimento
Figura 76 Principais etapas de processamento para MDM
1.3.3.4.1 Gerenciamento do Modelo de Dados
O trabalho de dados mestres traz à tona a importância de definições de dados lógicos claros e consistentes. O modelo deve ajudar a
organização a superar a 'fala do sistema'. Os termos e definições usados em um sistema de origem podem fazer sentido dentro dos
limites desse sistema, mas nem sempre fazem sentido no nível corporativo. Para Dados Mestres, os termos e definições usados em
nível empresarial devem estar no contexto dos negócios conduzidos em toda a organização e não necessariamente dependentes dos
valores de dados contribuintes do sistema de origem.
Para atributos que compõem os dados mestre, a granularidade da definição e os valores de dados associados também devem fazer
sentido em toda a organização. Os sistemas de origem podem apresentar o nome de atributo idêntico, mas os valores dos dados estão
em contextos completamente diferentes no nível da empresa. Da mesma forma, os sistemas de origem podem apresentar atributos
com nomes diferentes que no nível da empresa se unem a um único atributo e os valores dos dados estão no contexto apropriado. Às
vezes, vários atributos são apresentados de uma única fonte e seus respectivos valores de dados são usados para derivar um único
valor de dados para um atributo definido no nível corporativo.
1.3.3.4.2 Aquisição de Dados
Mesmo dentro de uma determinada fonte, os dados que representam a mesma instância de entidade podem parecer diferentes,
conforme ilustrado na Tabela 24, onde há inconsistências na forma como nomes, endereços e números de telefone são apresentados.
Este exemplo será referenciado novamente mais adiante no capítulo.
Tabela 24 Dados de origem recebidos pelo sistema MDM
Código de origem Nome Endereço Telefone

123 John Smith 123 Principal, Dataland, SQ 98765
234 J. Smith 123 Principal, Dataland, DA 2345678900
345 Jane Smith 123 Principal, Dataland, DA 234-567-8900
362 • DMBOK2
Planejar, avaliar e incorporar novas fontes de dados à solução Master Data Management deve ser um processo confiável e repetível. As atividades
de aquisição de dados envolvem:
• Receber e responder a novas solicitações de aquisição de fonte de dados
• Realização de avaliações de qualidade de dados rápidas, ad-hoc, de correspondência e de alto nível usando limpeza de dados e dados
ferramentas de perfil
• Avaliar e comunicar a complexidade da integração de dados aos solicitantes para ajudá-los com suas
análise de custo-benefício
• Aquisição piloto de dados e seu impacto nas regras da partida
• Finalizando as métricas de qualidade de dados para a nova fonte de dados
• Determinar quem será responsável por monitorar e manter a qualidade dos dados de uma nova fonte
• Completar a integração no ambiente geral de gerenciamento de dados
1.3.3.4.3 Validação, Padronização e Enriquecimento de Dados
Para habilitar a resolução da entidade, os dados devem ser o mais consistentes possível. Isso implica, no mínimo, reduzir a variação de formato e
conciliar valores. Dados de entrada consistentes reduzem a chance ou erros na associação de registros. Os processos de preparação incluem:
• Validação: Identificar dados comprovadamente errôneos ou provavelmente incorretos ou inadimplentes (por exemplo,
remoção de endereços de e-mail claramente falsos)
• Padronização: Garantir que o conteúdo de dados esteja em conformidade com os valores de Dados de Referência padrão (por exemplo, país
códigos), formatos (por exemplo, números de telefone) ou campos (por exemplo, endereços)
• Enriquecimento: Adição de atributos que podem melhorar os serviços de resolução de entidades (por exemplo, Dunn e Bradstreet
Número DUNS e Número DUNS final para registros de empresas relacionadas, Acxiom ou Experian
IDs de consumidor para registros individuais)
A Tabela 25 ilustra os resultados do processo de limpeza e padronização no exemplo da Tabela 24.
Os endereços que tinham formatos diferentes agora são reconhecidamente os mesmos. Os números de telefone incluem formatação padrão.
Tabela 25 Dados de entrada padronizados e enriquecidos
Código de origem Nome Endereço (limpo) Telefone (Limpo)

123 John Smith 123 Principal, Dataland, SQ 98765
234 J. Smith 123 Principal, Dataland, SQ 98765 +1 234 567 8900
345 Jane Smith 123 Principal, Dataland, SQ 98765 +1 234 567 8900
1.3.3.4.4 Resolução de Entidade e Gerenciamento de Identificador
A resolução de entidade é o processo de determinar se duas referências a objetos do mundo real se referem ao mesmo objeto ou a objetos
diferentes (Talburt, 2011). A resolução da entidade é um processo de tomada de decisão. Modelos para
DADOS DE REFERÊNCIA E PRINCIPAIS • 363
a execução do processo difere com base na abordagem que eles adotam para determinar a semelhança entre duas referências.
Embora a resolução sempre ocorra entre pares de referências, o processo pode ser sistematicamente estendido para incluir grandes
conjuntos de dados. A resolução da entidade é fundamental para o MDM, pois o processo de correspondência e mesclagem de registros
permite a construção do conjunto de dados mestre.
A resolução de entidade inclui um conjunto de atividades (extração de referência, preparação de referência, resolução de referência,
gerenciamento de identidade, análise de relacionamento) que permitem que a identidade de instâncias de entidade e o relacionamento entre
instâncias de entidade sejam gerenciados ao longo do tempo. Dentro do processo de resolução de referência, duas referências podem ser
identificadas como representando a mesma entidade, através do processo de determinação de equivalência. Essas referências podem então
ser vinculadas por meio de um valor (um identificador global) que indica que elas são equivalentes (Talburt, 2011).
1.3.3.4.4.1 Correspondência
A correspondência, ou identificação de candidatos, é o processo de identificação de como diferentes registros podem se relacionar a uma
única entidade. Os riscos com este processo são:
• Falsos positivos: Duas referências que não representam a mesma entidade são vinculadas a um único identificador.
Isso resulta em um identificador que se refere a mais de uma instância de entidade do mundo real.
• Falsos negativos: Duas referências representam a mesma entidade, mas não estão vinculadas a uma única
identificador. Isso resulta em vários identificadores que se referem à mesma entidade do mundo real quando cada instância
espera-se que tenha um identificador único.
Ambas as situações são tratadas por meio de um processo chamado análise de similaridade ou correspondência, no qual o grau de
similaridade entre quaisquer dois registros é pontuado, muitas vezes com base na correspondência aproximada ponderada entre os valores
de atributos correspondentes. Se a pontuação estiver acima de um limite especificado, os dois registros serão considerados como
representando a mesma entidade (uma correspondência). Através da análise de similaridade, pequenas variações nos dados podem ser
reconhecidas e os valores dos dados podem ser consolidados. Duas abordagens básicas, que podem ser usadas juntas, são determinísticas
e probabilísticas:
• Algoritmos determinísticos , como análise e padronização, dependem de padrões e regras definidos para
atribuir pesos e pontuações para determinar a similaridade. Algoritmos determinísticos são previsíveis em
que os padrões correspondidos e as regras aplicadas sempre produzirão os mesmos resultados. Esse tipo de
a correspondência funciona fora da caixa com desempenho relativamente bom, mas é tão bom quanto o
situações previstas pelas pessoas que desenvolveram as regras.
• Algoritmos probabilísticos dependem de técnicas estatísticas para avaliar a probabilidade de que qualquer par de
registros representa a mesma entidade. Isso depende da capacidade de coletar amostras de dados para fins de treinamento
observando os resultados esperados para um subconjunto dos registros e ajustando o matcher para auto-ajustar
baseado em analise estatistica. Esses matchers não dependem de regras, então os resultados podem ser
não determinístico. No entanto, como as probabilidades podem ser refinadas com base na experiência,
os matchers são capazes de melhorar sua precisão de correspondência à medida que mais dados são analisados.
364 • DMBOK2
1.3.3.4.4.2 Resolução de Identidade
Algumas correspondências ocorrem com grande confiança, com base em correspondências de dados exatas em vários campos. Outras
correspondências são sugeridas com menos confiança devido a valores conflitantes. Por exemplo:
• Se dois registros compartilharem o mesmo sobrenome, nome, data de nascimento e número de seguro social, mas o
endereço difere, é seguro assumir que se referem à mesma pessoa que mudou sua correspondência
Morada?
• Se dois registros compartilharem o mesmo número de seguro social, endereço e nome, mas o sobrenome
difere, é seguro assumir que eles se referem à mesma pessoa que mudou seu sobrenome? Será que o
probabilidade de ser aumentada ou diminuída com base no sexo e na idade?
• Como esses exemplos mudam se o número do seguro social for desconhecido para um registro? Quais os outros
identificadores são úteis para determinar a probabilidade de uma correspondência? Quanta confiança é necessária para o
organização para afirmar uma correspondência?
A Tabela 26 ilustra a conclusão do processo para os registros de amostra na Tabela 24 e na Tabela 25. Aqui, as duas segundas instâncias de
entidade (ID da fonte 234 e 345) são determinadas para representar a mesma pessoa (Jane Smith), enquanto a primeira (Fonte ID 123) é
identificado como representando uma pessoa diferente (John Smith).
Tabela 26 Identificação do Candidato e Resolução de Identidade
Fonte Nome Endereço (limpo) Telefone ID do candidato ID do partido

EU IRIA
(Limpo)
123 John Smith 123 Main, Dataland, SQ 98765 J. Smith XYZ 1
234 123 Main, Dataland, SQ 98765 +1 234 567 8900 XYZ, ABC 2
345 Jane Smith 123 Main, Dataland, SQ 98765 +1 234 567 8900 ABC 2
Apesar dos melhores esforços, as decisões de jogo às vezes se mostram incorretas. É essencial manter a história
de correspondências para que as correspondências possam ser desfeitas quando descobertas como incorretas. As métricas de taxa de correspondência permitem
organizações monitorem o impacto e a eficácia de suas regras de inferência correspondentes. O reprocessamento de regras de correspondência pode
ajudar a identificar melhores candidatos de correspondência à medida que novas informações são recebidas pelo processo de resolução da entidade.
1.3.3.4.4.3 Correspondência de fluxos de trabalho/ tipos de reconciliação
As regras de correspondência para diferentes cenários exigem fluxos de trabalho diferentes:
• As regras de correspondência de identificação duplicada se concentram em um conjunto específico de elementos de dados que identificam exclusivamente um
entidade e identificar oportunidades de mesclagem sem realizar ações automáticas. Os Administradores de Dados Corporativos podem
analisar essas ocorrências e decidir agir caso a caso.
• As regras de link de correspondência identificam e fazem referência cruzada de registros que parecem estar relacionados a um registro mestre sem
atualizar o conteúdo do registro de referência cruzada. As regras de link de correspondência são mais fáceis de implementar e muito
mais fácil de reverter.
• As regras de mesclagem de correspondência correspondem a registros e mesclam os dados desses registros em um único, unificado e
registro reconciliado e abrangente. Se as regras se aplicarem a todas as fontes de dados, crie um único, exclusivo e
e registro abrangente em cada armazenamento de dados. No mínimo, use dados confiáveis de um armazenamento de dados para
complementar dados em outros armazenamentos de dados, substituindo valores ausentes ou valores considerados imprecisos.
As regras de mesclagem de correspondência são complexas e buscam fornecer a versão unificada e reconciliada das informações em vários registros e
fontes de dados. A complexidade se deve à necessidade de identificar qual campo de qual fonte pode ser confiável com base em uma série de regras. A
introdução de cada nova fonte pode alterar essas regras ao longo do tempo.
Os desafios com as regras de mesclagem de correspondência incluem a complexidade operacional de reconciliar os dados e o custo de reverter a
operação se houver uma mesclagem falsa.
Match-link é uma operação mais simples, pois atua no registro de referência cruzada e não nos atributos individuais do registro de dados mestre mesclado,
embora possa ser mais difícil apresentar informações abrangentes de vários registros.
Reavalie periodicamente as regras de combinação de correspondência e link de correspondência, pois os níveis de confiança mudam com o tempo. Muitos
mecanismos de correspondência de dados fornecem correlações estatísticas de valores de dados para ajudar a estabelecer níveis de confiança. (Consulte
o Capítulo 13.)
1.3.3.4.4.4 Gerenciamento de ID de dados mestre
O gerenciamento de dados mestre envolve o gerenciamento de identificadores. Há dois tipos de identificadores que precisam ser gerenciados nas fontes
de dados em um ambiente MDM: IDs globais e informações de referência cruzada (x-Ref).
Um ID Global é o identificador exclusivo atribuído e mantido pela solução MDM anexado aos registros reconciliados. Sua finalidade é identificar
exclusivamente a instância da entidade. No exemplo da Tabela 26, quando vários registros foram determinados para representar a mesma instância de
entidade, o valor 'ABC' foi atribuído a ambos como um ID candidato. Os registros foram resolvidos para o ID de parte único de '2'.
Os IDs globais devem ser gerados por apenas uma solução autorizada, independentemente de qual tecnologia esteja realizando as atividades de
integração de dados mestres, para evitar qualquer risco de valores duplicados. Os IDs globais podem ser números ou GUIDs (identificadores exclusivos
globais), desde que a exclusividade possa ser mantida. A principal complexidade que precisa ser tratada para a geração do Global ID é como manter o ID
global correto (para realizar atualizações de dados downstream apropriadas) devido a uma unmerge-remerge. X-Ref Management é o gerenciamento do
relacionamento entre os IDs de origem e o ID Global. O gerenciamento de X-Ref deve incluir recursos para manter o histórico de tais mapeamentos para
oferecer suporte a métricas de taxa de correspondência e expor serviços de pesquisa para permitir a integração de dados.
1.3.3.4.4.5 Gestão de Afiliação
O Affiliation Management está estabelecendo e mantendo relacionamentos entre registros de dados mestres de entidades que possuem relacionamentos
do mundo real. Exemplos incluem afiliações de propriedade (por exemplo, a Empresa X é uma subsidiária da Empresa Y, uma relação pai-filho) ou outras
associações (por exemplo, a Pessoa XYZ trabalha na Empresa X).

366 • DMBOK2
O design de arquitetura de dados de uma solução de MDM deve decidir se deve alavancar relacionamentos pai-filho, relacionamentos de afiliação
ou ambos para uma determinada entidade.
• Os relacionamentos de afiliação oferecem a maior flexibilidade por meio da lógica de programação. As relações
type pode ser usado para expor esses dados em uma hierarquia pai-filho. Muitas soluções a jusante, como
ferramentas de relatórios ou navegação de contas gostariam de ver uma visão hierárquica das informações.
• Os relacionamentos Pai-Filho requerem menos lógica de programação, pois a estrutura de navegação está implícita.
No entanto, se o relacionamento mudar e não houver uma estrutura de afiliação disponível, isso pode
influenciam a qualidade dos dados e as dimensões de Business Intelligence.
1.3.3.4.5 Compartilhamento e administração de dados
Embora grande parte do trabalho do Master Data Management possa ser automatizado por meio de ferramentas que permitem o processamento
de um grande número de registros, ele ainda requer administração para resolver situações em que os dados são correspondidos incorretamente.
Idealmente, as lições aprendidas com o processo de administração podem ser usadas para melhorar os algoritmos de correspondência e reduzir
as instâncias de trabalho manual. (Consulte os Capítulos 3 e 8.)
1.3.3.5 Dados Mestre da Parte
Dados mestres do partido incluem dados sobre indivíduos, organizações e as funções que desempenham nas relações comerciais. No ambiente
comercial, as partes incluem clientes, funcionários, fornecedores, parceiros e concorrentes. No setor público, os partidos geralmente são cidadãos.
A aplicação da lei concentra-se em suspeitos, testemunhas e vítimas. Organizações sem fins lucrativos se concentram em membros e doadores.
Enquanto na área da saúde, o foco está nos pacientes e provedores; na educação, é nos alunos e professores.
Os sistemas CRM (Customer Relationship Management) gerenciam dados mestres sobre os clientes. O objetivo do CRM é fornecer informações
completas e precisas sobre cada cliente.
Um aspecto essencial do CRM é identificar dados duplicados, redundantes ou conflitantes de diferentes sistemas e determinar se os dados
representam um ou mais clientes. O CRM deve ser capaz de resolver valores conflitantes, reconciliar diferenças e representar com precisão o
conhecimento atual do cliente. Esse processo requer regras robustas, bem como conhecimento da estrutura, granularidade, linhagem e qualidade
dos dados
fontes.
Os sistemas MDM especializados executam funções semelhantes para indivíduos, organizações e suas funções, funcionários e fornecedores.
Independentemente do setor ou do foco, o gerenciamento de dados mestre da festa de negócios apresenta desafios únicos:
• A complexidade dos papéis e relacionamentos desempenhados por indivíduos e organizações
• Dificuldades na identificação única

• O número de fontes de dados e as diferenças entre elas
• Os múltiplos canais de comunicação móvel e social

• A importância dos dados
• As expectativas de como os clientes querem ser engajados
Dados mestres são particularmente desafiadores para partes que desempenham várias funções em uma organização (por exemplo, um funcionário que
também é cliente) e utilizam diferentes pontos de contato ou métodos de engajamento (por exemplo, interação via aplicativo de dispositivo móvel
vinculado a um site de mídia social) .
1.3.3.6 Dados Mestres Financeiros
Dados mestre financeiros incluem dados sobre unidades de negócios, centros de custo, centros de lucro, contas do razão geral, orçamentos, projeções
e projetos. Normalmente, um sistema ERP (Enterprise Resource Planning) serve como o hub central para dados mestre financeiros (plano de contas),
com detalhes do projeto e transações criadas e mantidas em um ou mais aplicativos spoke. Isso é especialmente comum em organizações com
funções de back-office.
As soluções de dados mestres financeiros não apenas criam, mantêm e compartilham informações; muitos também podem simular como as alterações
nos dados financeiros existentes podem afetar os resultados financeiros da organização. As simulações de dados mestres financeiros geralmente fazem
parte dos módulos de relatório, análise e planejamento de Business Intelligence, bem como orçamentos e projetos mais diretos. Por meio desses
aplicativos, versões de estruturas financeiras podem ser modeladas para entender os possíveis impactos financeiros. Uma vez tomada a decisão, as
mudanças estruturais acordadas podem ser disseminadas a todos os sistemas apropriados.
1.3.3.7 Dados Mestres Legais
Os Dados Mestres Jurídicos incluem dados sobre contratos, regulamentos e outros assuntos legais. O Legal Master Data permite a análise de contratos
de diferentes entidades que fornecem os mesmos produtos ou serviços, para permitir uma melhor negociação ou combinar contratos em Master
Agreements.
1.3.3.8 Dados mestre do produto
Os dados mestre do produto podem se concentrar em produtos e serviços internos de uma organização ou em produtos e serviços de todo o setor
(incluindo concorrentes). Diferentes tipos de soluções de dados mestres de produtos suportam diferentes
funções empresariais.
• O Product Lifecycle Management (PLM) se concentra no gerenciamento do ciclo de vida de um produto ou serviço
desde a concepção, passando pelo desenvolvimento, fabricação, venda/entrega, serviço e descarte.
As organizações implementam sistemas PLM para reduzir o tempo de lançamento no mercado. Em indústrias com produtos longos
ciclos de desenvolvimento (até 8 a 12 anos na indústria farmacêutica), os sistemas PLM permitem
organizações para rastrear custos de processos cruzados e acordos legais à medida que os conceitos de produtos evoluem a partir de ideias
a produtos potenciais sob nomes diferentes e acordos de licenciamento potencialmente diferentes.

368 • DMBOK2
• O Product Data Management (PDM) suporta funções de engenharia e manufatura capturando e permitindo o compartilhamento seguro de informações
do produto, como documentos de projeto (por exemplo, desenhos CAD), receitas (instruções de fabricação), procedimentos operacionais padrão e
listas de materiais. A funcionalidade PDM pode ser habilitada por meio de sistemas especializados ou aplicativos ERP.
• Os dados do produto nos sistemas Enterprise Resource Planning (ERP) se concentram em SKUs para dar suporte ao pedido
entrada até o nível de estoque, onde as unidades individuais podem ser identificadas por meio de uma variedade de técnicas.
• Dados de produtos em Sistemas de Execução de Manufatura (MES) com foco em estoque bruto, semi-acabado
bens e produtos acabados, onde os produtos acabados se ligam aos produtos que podem ser armazenados e encomendados através do sistema ERP.
Esses dados também são importantes em toda a cadeia de suprimentos e nos sistemas de logística.
• Os dados do produto em um sistema CRM (Customer Relationship Management) que oferece suporte a interações de marketing, vendas e
suporte podem incluir família de produtos e marcas, associação de representantes de vendas e gerenciamento de território do cliente, bem como
campanhas de marketing.
Muitos produtos mestres estão intimamente ligados aos sistemas de Gerenciamento de Dados de Referência.
1.3.3.9 Dados mestre de localização
Dados mestre de localização fornecem a capacidade de rastrear e compartilhar informações geográficas e criar relacionamentos ou territórios hierárquicos com base
em informações geográficas. A distinção entre dados de referência e dados mestre
borrões para dados de localização. Aqui está a diferença:
• Dados de referência de local geralmente incluem dados geopolíticos, como países, estados ou províncias, condados, cidades ou vilas, códigos postais
e coordenadas de posicionamento geográfico, como latitude, longitude e altitude. Esses dados raramente mudam e as mudanças são tratadas por
organizações externas.
Os Dados de Referência de Local também podem incluir regiões geográficas e territórios de vendas conforme definido pela organização.
• Dados mestre de localização incluem endereços de partes comerciais e localização de partes comerciais, bem como
endereços de instalações para locais de propriedade da organização. À medida que as organizações crescem ou contraem, esses endereços
mudam com mais frequência do que outros Dados de Referência de Local.
Diferentes indústrias exigem dados especializados em ciências da terra (dados geográficos sobre falhas sísmicas, planícies de inundação, solo, precipitação anual e
áreas de risco climático severo) e dados sociológicos relacionados (população, etnia, renda e risco de terrorismo), geralmente fornecidos por fontes externas.
1.3.3.10 Dados mestre da indústria - Diretórios de referência
Diretórios de referência são listagens autorizadas de entidades de dados mestres (empresas, pessoas, produtos etc.) que as organizações podem comprar e usar
como base de suas transações. Enquanto os diretórios de referência são criados por
organizações externas, uma versão gerenciada e reconciliada das informações é mantida no
sistemas próprios.
Exemplos de diretórios de referência licenciados incluem o Diretório de empresas da Dun and Bradstreet (D&B) de sedes de empresas em todo o mundo,
subsidiárias e filiais, e o American Medical

Banco de dados de prescritores da associação.
Os diretórios de referência permitem o uso de dados mestres por:
• Fornecer um ponto de partida para combinar e vincular novos registros. Por exemplo, em um ambiente com
cinco fontes de dados, cada fonte pode ser comparada com o diretório (5 pontos de comparação) vs.
entre si (10 pontos de comparação).
• Fornecer elementos de dados adicionais que podem não estar tão facilmente disponíveis no momento da criação do registro
(por exemplo, para um médico, isso pode incluir o status de licença médica; para uma empresa, isso pode incluir seis
dígito classificação da indústria NAICS).
À medida que os registros de uma organização correspondem e se reconciliam com os diretórios de referência, o registro confiável se desviará do
diretório de referência com rastreabilidade para outros registros de origem, atributos contribuintes e transformação
as regras.
1.3.4 Arquitetura de Compartilhamento de Dados
Existem várias abordagens arquitetônicas básicas para referência e integração de dados mestres. Cada área de assunto de Dados Mestres provavelmente
terá seu próprio sistema de registro. Por exemplo, o sistema de recursos humanos geralmente serve como sistema de registro de dados de funcionários.
Um sistema de CRM pode servir como sistema de registro de dados de clientes, enquanto um sistema de ERP pode servir como sistema de registro de
dados financeiros e de produtos.
O modelo de arquitetura de hub de compartilhamento de dados mostrado na Figura 77 representa uma arquitetura hub-and-spoke para Master Data. O
hub Master Data pode lidar com interações com itens falados, como sistemas de origem, aplicativos de negócios e armazenamentos de dados,
minimizando o número de pontos de integração. Um hub de dados local pode estender e dimensionar o hub de dados mestre. (Consulte o Capítulo 8.)
Cada uma das três abordagens básicas para implementar um ambiente de hub de dados mestres tem prós e contras:
• Um Registro é um índice que aponta para Dados Mestres nos diversos sistemas de registro. Os sistemas de
registro gerenciar dados mestre local para seus aplicativos. O acesso aos dados mestre vem do mestre
índice. Um registro é relativamente fácil de implementar porque requer poucas mudanças nos sistemas de
registro. Mas, muitas vezes, são necessárias consultas complexas para reunir dados mestres de vários sistemas.
Além disso, várias regras de negócios precisam ser implementadas para lidar com diferenças semânticas entre
sistemas em vários lugares.
• Em um Hub de Transação, os aplicativos fazem interface com o hub para acessar e atualizar os Dados Mestres. o
Os Dados Mestres existem no Transaction Hub e não em outros aplicativos. A Transação
Hub é o sistema de registro de Dados Mestres. Os Hubs de Transação permitem uma melhor governança e fornecem uma
370 • DMBOK2
fonte consistente de dados mestre. No entanto, é caro remover a funcionalidade de atualização de dados mestres dos
sistemas de registro existentes. As regras de negócio são implementadas em um único sistema: o Hub.
• Uma abordagem consolidada é um híbrido de Registry e Transaction Hub. Os sistemas de registro gerenciam
Dados mestres locais para suas aplicações. Os Dados Mestres são consolidados em um repositório comum e
disponibilizados a partir de um hub de compartilhamento de dados, o sistema de referência para Master Data. Isso elimina a
precisam acessar diretamente dos sistemas de registro. A abordagem Consolidada fornece uma empresa
vista com impacto limitado nos sistemas de registro. No entanto, envolve a replicação de dados e haverá
latência entre o hub e os sistemas de registro.
Mestre Externo
ODS Parceiros
DW
(local)
Externo
LZ Parceiros
Ambiente B2B
Aplicativo
Dados mestre
Aplicativo
SUD MDS
Central de Compartilhamento
Aplicativo
(opcional)
Dados locais
SUD
Central de Compartilhamento
Mestre Operacional
ODS Banco de dados
Aplicativo
Dados
DW
Aplicativo
DW Armazém
Aplicativo
MDS (empreendimento)
Inscrição
Aplicativo Solução
Pousar
LZ Zona
Centro de dados mestre
Meio Ambiente
Data Mart
Mestre
Nuvem
Meio Ambiente
Figura 77 Exemplo de arquitetura de compartilhamento de dados mestre
2. Atividades
Conforme enfatizado na Seção 1.3.1, os dados mestre e os dados de referência compartilham certas características (são recursos
compartilhados que fornecem contexto e significado para outros dados e devem ser gerenciados no nível da empresa), mas também
diferem de maneiras importantes (conjuntos de dados de referência são menores, menos voláteis, não requerem correspondência,
mesclagem e vinculação, etc.). A seção de atividades descreverá primeiro as atividades associadas ao MDM e, em seguida,
descrever aqueles relacionados aos Dados de Referência.
2.1 Atividades de MDM
2.1.1 Definir Drivers e Requisitos de MDM
Cada organização tem diferentes drivers e obstáculos de MDM, influenciados pelo número e tipo de sistemas, sua idade, os
processos de negócios que eles suportam e como os dados são usados para transações e análises. Os drivers geralmente
incluem oportunidades para melhorar o atendimento ao cliente e/ou a eficiência operacional, bem como reduzir os riscos
relacionados à privacidade e conformidade. Os obstáculos incluem diferenças no significado e na estrutura dos dados entre os
sistemas. Isso geralmente está ligado a barreiras culturais – algumas unidades de negócios podem não querer incorrer nos
custos de mudar seus processos, mesmo que a mudança seja apresentada como boa para a empresa como um todo.
É relativamente fácil definir requisitos para dados mestres em um aplicativo. É mais difícil definir requisitos padrão entre
aplicativos. A maioria das organizações desejará abordar uma área de assunto de Dados Mestres, ou mesmo uma entidade, por
vez. Priorize os esforços de Master Data com base no custo/benefício das melhorias propostas e na complexidade relativa da
área de assunto de Master Data. Comece com a categoria mais simples para aprender com o processo.
2.1.2 Avaliar e avaliar as fontes de dados
Os dados em aplicativos existentes formam a base de um esforço de gerenciamento de dados mestre. É importante entender a
estrutura e o conteúdo desses dados e os processos pelos quais eles são coletados ou criados. Um resultado de um esforço de
MDM pode ser melhorias nos metadados gerados por meio do esforço para avaliar a qualidade dos dados existentes. Um objetivo
da avaliação é entender quão completos são os dados em relação aos atributos que compõem os Dados Mestres. Esse processo
inclui esclarecer as definições e a granularidade desses atributos.
Problemas semânticos surgirão em algum momento ao definir e descrever atributos. Os Data Stewards precisarão colaborar com
as áreas de negócios na reconciliação e acordo sobre a nomenclatura de atributos e definições de nível empresarial. (Consulte
os Capítulos 3 e 13.)
A outra parte da avaliação das fontes é entender a qualidade dos dados. Os problemas de qualidade de dados complicarão um
projeto de dados mestres, portanto, o processo de avaliação deve incluir o tratamento das causas-raiz dos problemas de dados.
Nunca assuma que os dados serão de alta qualidade – é mais seguro supor que não são de alta qualidade. Sempre avalie sua
qualidade e adequação para um ambiente de Master Data.
O maior desafio, como observado, será a disparidade entre as fontes. Os dados podem ser de alta qualidade em qualquer fonte,
mas ainda não se encaixam com dados de outras fontes, devido a diferenças estruturais e diferenças nos valores pelos quais
atributos semelhantes são representados. As iniciativas de dados mestres oferecem a oportunidade de definir e implementar
padrões em aplicativos nos quais os dados são criados ou coletados.
Para algumas entidades de dados mestres, como cliente, cliente ou fornecedor, é possível adquirir dados padronizados (como
Diretórios de referência) para habilitar o esforço de MDM. Vários fornecedores têm serviços que fornecem dados limpos
relacionados a pessoas individuais ou entidades comerciais ou profissões (por exemplo, profissionais de saúde),
372 • DMBOK2
que podem ser comparados aos dados internos de uma organização para melhorar as informações de contato, endereços e nomes
(consulte o Capítulo 10). Além de avaliar a qualidade dos dados existentes, também é necessário entender a tecnologia que suporta a
coleta de insumos para um esforço de MDM. A tecnologia existente influenciará a abordagem arquitetônica do MDM.
2.1.3 Definir abordagem arquitetônica
A abordagem arquitetônica do MDM depende da estratégia de negócios, das plataformas das fontes de dados existentes e dos próprios
dados, principalmente sua linhagem e volatilidade, e as implicações de alta ou baixa latência. A arquitetura deve levar em conta o
consumo de dados e os modelos de compartilhamento. As ferramentas para manutenção dependem dos requisitos de negócios e das
opções de arquitetura. O ferramental ajuda a definir e depende da abordagem de administração

e manutenção.
O número de sistemas de origem a serem integrados à solução Master Data e as plataformas desses sistemas precisam ser
considerados ao determinar a abordagem de integração. O tamanho e a distribuição geográfica de uma organização também
influenciarão a abordagem de integração. Pequenas organizações podem efetivamente utilizar um hub de transações, enquanto uma
organização global com vários sistemas tem maior probabilidade de utilizar um registro. Uma organização com unidades de negócios
'isoladas' e vários sistemas de origem pode decidir que uma abordagem consolidada é o caminho correto a seguir. Especialistas em
domínio de negócios, arquitetos de dados e arquitetos corporativos devem fornecer uma perspectiva sobre a abordagem.
A arquitetura do hub de compartilhamento de dados é particularmente útil quando não há um sistema claro de registro de dados mestre.
Nesse caso, vários sistemas fornecem dados. Novos dados ou atualizações de um sistema podem ser reconciliados com dados já
fornecidos por outro sistema. O hub de compartilhamento de dados torna-se a fonte do conteúdo de dados mestre para data warehouses
ou marts, reduzindo a complexidade das extrações e o tempo de processamento para transformação, correção e reconciliação de
dados. Obviamente, os data warehouses devem refletir as alterações feitas no hub de compartilhamento de dados para fins históricos,
enquanto o próprio hub de compartilhamento de dados pode precisar refletir apenas o estado atual.
2.1.4 Dados Mestre do Modelo
Master Data Management é um processo de integração de dados. Para alcançar resultados consistentes e gerenciar a integração de
novas fontes à medida que uma organização se expande, é necessário modelar os dados dentro das áreas temáticas. Um modelo lógico
ou canônico pode ser definido nas áreas de assunto dentro do hub de compartilhamento de dados. Isso permitiria o estabelecimento de
definições de nível empresarial de entidades e atributos da área de assunto. (Consulte os Capítulos 5 e 8.)
2.1.5 Definir processos de administração e manutenção
As soluções técnicas podem fazer um trabalho notável combinando, mesclando e gerenciando identificadores para registros mestres.
No entanto, o processo também requer administração, não apenas para tratar de registros que não estejam no processo, mas também
para remediar e melhorar os processos que os fazem cair em primeiro lugar. Os projetos de MDM devem
contabilizar os recursos necessários para dar suporte à qualidade contínua dos Dados Mestres. Há uma necessidade de analisar registros, fornecer
feedback aos sistemas de origem e fornecer entradas que possam ser usadas para ajustar e melhorar os algoritmos que orientam a solução de MDM.
2.1.6 Estabelecer Políticas de Governança para Reforçar o Uso de Dados Mestres
O lançamento inicial de um esforço de dados mestres é desafiador e exige muito foco. Os benefícios reais (eficiência operacional, maior qualidade,
melhor atendimento ao cliente) surgem quando as pessoas e os sistemas começam a usar os Dados Mestres.
O esforço geral deve incluir um roteiro para que os sistemas adotem valores mestres e identificadores como entrada para os processos. Estabeleça
laços fechados unidirecionais entre os sistemas para manter a consistência dos valores entre
sistemas.
2.2 Atividades de Dados de Referência
2.2.1 Definir Drivers e Requisitos
Os principais impulsionadores do Reference Data Management são a eficiência operacional e a maior qualidade dos dados.
Gerenciar dados de referência centralmente é mais econômico do que ter várias unidades de negócios mantendo seus próprios conjuntos de dados.
Também reduz o risco de inconsistência entre os sistemas. Dito isso, alguns conjuntos de dados de referência são mais importantes que outros;
conjuntos de dados de referência complexos exigem mais trabalho para configurar e manter do que os simples. Os conjuntos de dados de referência
mais importantes devem orientar os requisitos de um sistema de gerenciamento de dados de referência. Uma vez que tal sistema esteja implementado,
novos conjuntos de Dados de Referência podem ser configurados como parte dos projetos.
Os conjuntos de dados de referência existentes devem ser mantidos com base em um cronograma publicado.
2.2.2 Avaliar Fontes de Dados
A maioria dos conjuntos de dados de referência padrão do setor pode ser obtida das organizações que os criam e mantêm. Algumas organizações
fornecem esses dados gratuitamente. Outros cobram uma taxa. Os intermediários também empacotam e vendem Dados de Referência, geralmente
com recursos de valor agregado. Dependendo do número e do tipo de conjuntos de dados de referência necessários para uma organização, pode ser
melhor comprar de um fornecedor, especialmente se esse fornecedor garantir a entrega de atualizações em um cronograma definido e realizar o
controle básico de qualidade dos dados.
A maioria das organizações também conta com Dados de Referência que são criados e mantidos internamente. Determinar a fonte de dados de
referência internos ou locais costuma ser mais desafiador do que fazer isso para dados de referência padrão do setor. Como é o caso dos Dados
Mestres, as fontes internas dos Dados de Referência devem ser identificadas,
comparados e avaliados. Os proprietários dos dados existentes devem entender os benefícios do gerenciamento central e concordar em apoiar os
processos para administrar os dados para o bem da empresa.

374 • DMBOK2
2.2.3 Definir abordagem arquitetônica
Antes de comprar ou construir uma ferramenta para gerenciar Dados de Referência, é fundamental levar em conta os requisitos e
os desafios colocados pelos Dados de Referência a serem gerenciados. Por exemplo, a volatilidade dos dados (a maioria dos Dados
de Referência é relativamente estática, mas alguns são bastante voláteis), a frequência das atualizações e os modelos de consumo.
Determine se é necessário manter dados históricos sobre alterações nos valores ou nas definições dos valores.
Se a organização comprar dados de um fornecedor, considere o método de entrega e integração.
A abordagem arquitetural precisa reconhecer que, invariavelmente, alguns Dados de Referência precisarão ser atualizados
manualmente. Certifique-se de que a interface para atualizações seja direta e possa ser configurada para impor regras básicas de
entrada de dados, como garantir que os relacionamentos pai/filho sejam mantidos em Dados de referência que incluam hierarquias.
A ferramenta RDM deve permitir que os Stewards façam atualizações ad hoc sem a necessidade de suporte técnico e deve incluir
fluxos de trabalho para garantir que as aprovações e notificações sejam automatizadas. Os Data Stewards devem agendar
atualizações conhecidas para alinhar com a publicação de novos códigos. Os consumidores de dados devem ser informados de
todas as alterações. Nos casos em que os dados de referência direcionam a lógica de programação, o impacto potencial das
alterações deve ser avaliado e contabilizado antes que as alterações sejam introduzidas.
2.2.4 Conjuntos de dados de referência do modelo
Muitas pessoas pensam em Dados de Referência como simples códigos e descrições. No entanto, muitos dados de referência são
mais complicados do que isso. Por exemplo, um conjunto de dados de CEP geralmente incluirá informações sobre estado e
município, bem como outros atributos geopolíticos. Para fins de permitir o uso a longo prazo e estabelecer Metadados precisos, bem
como para o próprio processo de manutenção, é importante criar modelos de dados de conjuntos de dados de referência. Os
modelos ajudam os consumidores de dados a entender os relacionamentos dentro do conjunto de dados de referência e podem ser
usados para estabelecer regras de qualidade de dados.
2.2.5 Definir processos de administração e manutenção
Os Dados de Referência exigem administração para garantir que os valores sejam completos e atuais e que as definições sejam
claras e compreensíveis. Em alguns casos, os stewards serão diretamente responsáveis pela manutenção prática dos Dados de
Referência; em outros casos, podem facilitar o processo. Por exemplo, se várias unidades de negócios diferentes exigirem Dados
de Referência para apoiar o mesmo conceito, um administrador pode facilitar discussões que definam valores comuns em
uma faixa de pedestres.
Como parte do processo de administração, é útil capturar Metadados básicos sobre cada conjunto de Dados de Referência. Isso
pode incluir: nome do administrador, organização de origem, frequência esperada de atualizações, cronograma para atualizações,
processos usando os Dados de Referência, se as versões históricas dos dados precisam ser retidas e muito mais (consulte
Seção 1.3.2.6). Documentar quais processos usam Dados de Referência permitirá uma comunicação mais eficaz em relação às
alterações nos dados.
Muitas ferramentas de gerenciamento de dados de referência incluem fluxos de trabalho para gerenciar a revisão e aprovação de alterações nos dados de
referência. Esses fluxos de trabalho dependem da identificação de quem dentro de uma organização é responsável
para conteúdo de dados de referência.
2.2.6 Estabelecer Políticas de Governança de Dados de Referência
Uma organização só obtém valor de um repositório de Dados de Referência gerenciado centralmente se as pessoas realmente usarem os dados desse
repositório. É importante ter políticas em vigor que governem a qualidade e obriguem o uso de Dados de Referência desse repositório, seja diretamente por
meio da publicação desse repositório ou indiretamente de um sistema de referência preenchido com dados do repositório central.
3. Ferramentas e Técnicas
O MDM requer ferramentas projetadas especificamente para habilitar o gerenciamento de identidades. O Master Data Management pode ser implementado
por meio de ferramentas de integração de dados, ferramentas de correção de dados, armazenamentos de dados operacionais (ODS), hubs de
compartilhamento de dados (DSH) ou aplicativos MDM especializados. Vários fornecedores oferecem soluções que podem abranger uma ou mais áreas de
assunto de Dados Mestres. Outros fornecedores promovem o uso de seus produtos de software de integração de dados e serviços de implementação para
criar soluções personalizadas de dados mestre.
Soluções empacotadas para produtos, contas e terceiros, bem como serviços de verificação de qualidade de dados empacotados, podem impulsionar grandes
programas. A incorporação de tais serviços pode permitir que as organizações usem as melhores soluções, ao mesmo tempo em que as integram à sua
arquitetura geral de negócios para atender a necessidades específicas.
Master e Reference Data Management são formas de integração de dados. Os princípios de implementação que se aplicam à integração e interoperabilidade
de dados se aplicam ao MDM e ao RDM. (Consulte o Capítulo 8.)
Os recursos de MDM e RDM não podem ser implementados da noite para o dia. As soluções exigem conhecimento técnico e comercial especializado. As
organizações devem esperar implementar soluções de Referência e Dados Mestres de forma incremental por meio de uma série de projetos definidos em um
roteiro de implementação, priorizados com base nas necessidades de negócios e guiados por uma arquitetura geral.
Observe que os programas de MDM falharão sem a governança adequada. Os profissionais de governança de dados devem entender os desafios do MDM e
do RDM e avaliar a maturidade da organização e a capacidade de enfrentá-los. (Consulte o Capítulo 15.)

376 • DMBOK2
4.1 Aderir à Arquitetura de Dados Mestres
Estabelecer e seguir a arquitetura de referência adequada é fundamental para gerenciar e compartilhar dados mestres em uma organização.
A abordagem de integração deve levar em consideração a estrutura organizacional do negócio, o número de sistemas distintos de registro, a
implementação de governança de dados, a importância do acesso e a latência dos valores dos dados e o número de sistemas e aplicativos
consumidores.
4.2 Monitorar a movimentação de dados
Os processos de integração de dados para dados mestre e de referência devem ser projetados para garantir a extração e distribuição de
dados em tempo hábil em toda a organização. À medida que os dados fluem em um ambiente de compartilhamento de dados mestre ou de
referência, o fluxo de dados deve ser monitorado para:
• Mostrar como os dados são compartilhados e usados em toda a organização
• Identificar a linhagem de dados de/para sistemas e aplicativos administrativos
• Auxiliar na análise da causa raiz dos problemas
• Mostrar a eficácia das técnicas de integração de ingestão e consumo de dados
• Denote a latência dos valores de dados dos sistemas de origem por meio do consumo
• Determinar a validade das regras de negócios e transformações executadas nos componentes de integração
4.3 Gerenciar Alteração de Dados de Referência
Como os Dados de Referência são um recurso compartilhado, eles não podem ser alterados arbitrariamente. A chave para o gerenciamento
de dados de referência bem-sucedido é a disposição organizacional de abrir mão do controle local dos dados compartilhados. Para sustentar
esse suporte, forneça canais para receber e responder a solicitações de alterações nos Dados de Referência. O Conselho de Governança
de Dados deve garantir que as políticas e procedimentos sejam implementados para lidar com as mudanças nos dados
em ambientes de referência e dados mestre.
As alterações nos dados de referência precisarão ser gerenciadas. Pequenas alterações podem afetar algumas linhas de dados. Por
exemplo, quando a União Soviética invadiu estados independentes, o termo União Soviética foi preterido e novos códigos foram adicionados.
No setor de saúde, os códigos de procedimentos e diagnósticos são atualizados anualmente para levar em conta o refinamento dos códigos
existentes, a obsolescência dos códigos e a introdução de novos códigos. As principais revisões nos dados de referência afetam a estrutura
de dados. Por exemplo, os Códigos de Diagnóstico da CID-10 são estruturados de maneiras muito diferentes da CID-9. O ICD10 tem um
formato diferente. Existem valores diferentes para os mesmos conceitos. Mais importante, a CID-10 tem princípios adicionais de organização.
Os códigos ICD10 têm uma granularidade diferente e são muito mais específicos, de modo que mais informações são transmitidas em um
único código. Consequentemente, há muito mais deles (em 2015, havia 68.000 códigos CID-10, em comparação com 13.000 CID-9s).62
62 http://bit.ly/1SSpds9 (acessado em 13/08/16).

O uso obrigatório dos códigos da CID-10 nos EUA em 2015 exigiu um planejamento significativo. As empresas de saúde precisavam fazer alterações no
sistema, bem como ajustes nos relatórios impactados para levar em conta o novo padrão.
Os tipos de alterações incluem:
• Alterações no nível da linha para conjuntos de dados de referência externos
• Alterações estruturais em conjuntos de dados de referência externos
• Mudanças no nível da linha para conjuntos de dados de referência internos
• Alterações estruturais nos conjuntos de dados de referência internos
• Criação de novos conjuntos de dados de referência
As mudanças podem ser planejadas/agendadas ou ad hoc. Mudanças planejadas, como atualizações mensais ou anuais de códigos padrão do setor, exigem
menos governança do que atualizações ad hoc. O processo de solicitação de novos conjuntos de dados de referência deve levar em conta os usos potenciais
além daqueles do solicitante original.
As solicitações de mudança devem seguir um processo definido, conforme ilustrado na Figura 78. Quando as solicitações são recebidas, as partes interessadas
devem ser notificadas para que os impactos possam ser avaliados. Se as mudanças precisarem de aprovação, discussões devem ser realizadas para obter
essa aprovação. As alterações devem ser comunicadas.
Receber Atualizar e
Identificar Decida e
Identificar
Mudar Informar
Parte interessada Impacto Comunicar
Solicitar (Se aplicável)
Figura 78 Processo de solicitação de alteração de dados de referência
4.4 Contratos de Compartilhamento de Dados
O compartilhamento e o uso de dados mestre e de referência em uma organização requer colaboração entre várias partes internas à organização e, às vezes,
com partes externas a ela. Para garantir o acesso e uso adequados, estabeleça acordos de compartilhamento que estipulem quais dados podem ser
compartilhados e em quais condições. Ter esses acordos em vigor ajudará quando surgirem problemas relacionados à disponibilidade de dados ou à qualidade
dos dados trazidos para o ambiente de compartilhamento de dados. Esse esforço deve ser impulsionado pelo programa de Governança de Dados. Pode
envolver Arquitetos de Dados, Provedores de Dados, Administradores de Dados, Desenvolvedores de Aplicativos, Analistas de Negócios, bem como Diretores
de Conformidade/Privacidade e Diretores de Segurança.
Os responsáveis pelo ambiente de compartilhamento de dados têm a obrigação de fornecer dados de alta qualidade aos consumidores de dados a jusante.
Para cumprir essa responsabilidade, eles dependem de sistemas upstream. SLAs e métricas devem ser estabelecidas para medir a disponibilidade e qualidade
dos dados compartilhados. Os processos devem ser implementados para abordar as causas-raiz dos problemas com a qualidade ou disponibilidade dos
dados. Uma abordagem padrão para comunicações deve ser implementada para manter todas as partes afetadas informadas sobre a existência de problemas
e o status dos esforços de remediação. (Consulte o Capítulo 8.)

378 • DMBOK2
5. Organização e Mudança Cultural
O gerenciamento de dados mestre e de referência exige que as pessoas abandonem o controle de alguns de seus dados e processos para criar
recursos compartilhados. Nem sempre é fácil fazer isso. Embora os profissionais de gerenciamento de dados possam ver que os dados
gerenciados localmente são arriscados, as pessoas que os gerenciam localmente precisam realizar seu trabalho e podem perceber que os
esforços de MDM ou RDM adicionam complicações aos seus processos.
Felizmente, a maioria das pessoas reconhece que esses esforços fazem sentido fundamental. É melhor ter uma visão precisa e completa de um
único cliente do que ter várias visualizações parciais.
Melhorar a disponibilidade e a qualidade dos Dados Mestres e de referência exigirá, sem dúvida, mudanças nos procedimentos e práticas
tradicionais. As soluções devem ser definidas e implementadas com base na prontidão organizacional atual e nas necessidades futuras vinculadas
à missão e visão da organização.
Talvez a mudança cultural mais desafiadora seja central para a governança: determinar quais indivíduos são responsáveis por quais decisões –
administradores de dados de negócios, arquitetos, gerentes e executivos – e quais decisões as equipes de administração de dados, comitês de
direção de programas e o Conselho de governança de dados devem tomar de forma colaborativa .
6. Referência e Governança de Dados Mestres
Por serem recursos compartilhados, os Dados mestre e de referência exigem governança e administração. Nem todas as inconsistências de
dados podem ser resolvidas por meio da automação. Alguns exigem que as pessoas falem umas com as outras. Sem governança, as soluções
de referência e dados mestre serão apenas utilitários de integração de dados adicionais, incapazes de fornecer todo o seu potencial.
Os processos de governança determinarão:
• As fontes de dados a serem integradas
• As regras de qualidade de dados a serem aplicadas

• As regras de condições de uso a serem seguidas
• As atividades a serem monitoradas e a frequência do monitoramento
• Os níveis de prioridade e resposta dos esforços de gestão de dados
• Como a informação deve ser representada para atender às necessidades das partes interessadas
• Portões de aprovação padrão, expectativas na implantação de RDM e MDM
Os processos de governança também reúnem as partes interessadas legais e de conformidade com os consumidores de informações para
garantir que os riscos organizacionais sejam mitigados por meio da definição e incorporação de políticas de privacidade, segurança e retenção.
Como um processo contínuo, a governança de dados deve ter a capacidade de revisar, receber e considerar novos requisitos e alterações nas
regras existentes, ao mesmo tempo em que disponibiliza princípios, regras e diretrizes para aqueles que usam dados mestre e de referência.
6.1 Métricas
Certas métricas podem ser vinculadas à qualidade de dados mestre e de referência e aos processos que dão suporte a esses esforços:
• Qualidade e conformidade dos dados: os painéis DQ podem descrever a qualidade dos dados mestre e de referência.
Essas métricas devem denotar a confiança (como uma porcentagem) de uma entidade de área de assunto ou atributo
associado e sua adequação à finalidade para uso em toda a organização.
• Atividade de alteração de dados: auditar a linhagem de dados confiáveis é fundamental para melhorar a qualidade dos dados em
um ambiente de compartilhamento de dados. As métricas devem denotar a taxa de alteração dos valores dos dados. Essas
métricas fornecerão informações aos sistemas que fornecem dados ao ambiente de compartilhamento e podem ser usadas para
ajustar algoritmos em processos de MDM.
• Ingestão e consumo de dados: os dados são fornecidos por sistemas upstream e usados por downstream
sistemas e processos. Essas métricas devem denotar e rastrear quais sistemas estão contribuindo com dados e quais áreas de
negócios estão assinando dados do ambiente de compartilhamento.
• Acordos de Nível de Serviço: SLAs devem ser estabelecidos e comunicados aos colaboradores e
assinantes para garantir o uso e a adoção do ambiente de compartilhamento de dados. O nível de adesão aos SLAs pode
fornecer informações sobre os processos de suporte e os problemas técnicos e de dados que podem tornar o aplicativo MDM
mais lento.
• Cobertura do administrador de dados: essas métricas devem observar o nome ou grupo responsável pelo conteúdo dos dados
e com que frequência a cobertura é avaliada. Eles podem ser usados para identificar lacunas no suporte.
• Custo Total de Propriedade: Existem vários fatores dessa métrica e diferentes formas de representá-la.
Do ponto de vista da solução, os custos podem incluir infraestrutura de ambiente, licenças de software, equipe de suporte,
taxas de consultoria, treinamento etc. A eficácia dessa métrica é amplamente baseada em sua aplicação consistente em toda a
organização.
• Volume e uso de compartilhamento de dados: os volumes de ingestão e consumo de dados precisam ser rastreados para
determinar a eficácia do ambiente de compartilhamento de dados. Essas métricas devem denotar o volume e a velocidade dos
dados definidos, ingeridos e inscritos no ambiente de compartilhamento de dados.

Abbas, junho. Estruturas para Organizar o Conhecimento: Explorando Taxonomias, Ontologias e Outros Esquemas. Neal-Schuman
Publishers, 2010. Impresso.
380 • DMBOK2
Abernethy, Kenneth e J. Thomas Allen. Explorando o domínio digital: uma introdução aos computadores e à fluência da informação. 2ª ed., 2004.
Impresso.
Allen Mark e Dalton Cervo. Gerenciamento de dados mestre de vários domínios: MDM avançado e governança de dados na prática.
Morgan Kaufmann, 2015. Impresso.
Feijão, James. XML para arquitetos de dados: projetando para reutilização e integração. Morgan Kaufmann, 2003. Impresso. A série Morgan
Kaufmann em sistemas de gerenciamento de dados.
Berson, Alex e Larry Dubov. Gerenciamento de dados mestre e integração de dados do cliente para uma empresa global.
McGraw-Hill, 2007. Impresso.
Brackett, Michael. Compartilhamento de dados usando uma arquitetura de dados comum. Wiley, 1994. Impresso. Computação Profissional Wiley.
Cassell, Kay Ann e Uma Hiremath. Serviços de referência e informação: uma introdução. 3d edição. ALA Neal-Schuman, 2012. Impresso.
Cervo, Dalton e Mark Allen. Master Data Management na Prática: Alcançando o True Customer MDM. Wiley, 2011. Impresso.
Chisholm, Malcom. “O que são dados mestres?” BeyeNetwork, 6 de fevereiro de 2008. http://bit.ly/2spTYOA Web.
Chisholm, Malcom. Gerenciando dados de referência em bancos de dados corporativos: vinculando dados corporativos ao mundo mais amplo.
Morgan Kaufmann, 2000. Print. A série Morgan Kaufmann em sistemas de gerenciamento de dados.
Dreibelbis, Allen, et ai. Enterprise Master Data Management: Uma Abordagem SOA para Gerenciar Informações Centrais. IBM Press, 2008.
Imprimir.
Dyche, Jill e Evan Levy. Integração de dados do cliente: alcançando uma única versão da verdade. John Wiley e Filhos, 2006.
Imprimir.
EFFINGHAM, Nikk. Uma Introdução à Ontologia. Polity, 2013. Impresso.
Finkelstein, Clive. Arquitetura Corporativa para Integração: Métodos e Técnicas de Entrega Rápida. Artech House Print on Demand, 2006. Print.
Biblioteca de Comunicações Móveis Artech House.
Forte, Eric J., et ai. Fundamentos da informação governamental: mineração, descoberta, avaliação e uso de recursos governamentais. Neal-
Schuman Publishers, 2011. Impresso.
Hadzic, Fedja, Henry Tan, Tharam S. Dillon. Mineração de Dados com Estruturas Complexas. Springer, 2013. Impresso. Estudos em Inteligência
Computacional.
Lambe, Patrick. Organizando o Conhecimento: Taxonomias, Conhecimento e Eficácia Organizacional. Editora Chandos, 2007. Impresso. Gestão
do Conhecimento Chandos.
Loshin, David. Gestão do Conhecimento Empresarial: A Abordagem de Qualidade de Dados. Morgan Kaufmann, 2001. Impresso. A série
Morgan Kaufmann em sistemas de gerenciamento de dados.
Loshin, David. Gerenciamento de dados mestre. Morgan Kaufmann, 2008. Impresso. A imprensa MK/OMG.
Menzies, Tim, et ai. Compartilhando Dados e Modelos em Engenharia de Software. Morgan Kaufmann, 2014. Impresso.
Millett, Scott e Nick Tune. Padrões, Princípios e Práticas de Design Dirigido por Domínio. Wrox, 2015. Impresso.
Stewart, Darin L. Construindo Taxonomias Empresariais. Mokita Press, 2011. Impresso.
Talburt, John e Yinle Zhou. Ciclo de Vida do Gerenciamento de Informações da Entidade para Big Data. Morgan Kauffman, 2015. Impresso.
Talburt, John. Resolução da Entidade e Qualidade da Informação. Morgan Kaufmann, 2011. Print.
CAPÍTULO 1 1
Data Warehousing e Business Intelligence
Dados
Modelagem de dados
Qualidade dos dados
& Operações
Dados Dados
Metadados

Inteligência
& Mestre & Contente
Dados Gestão

1. Introdução
T
O conceito de Data Warehouse surgiu na década de 1980, quando a tecnologia permitiu que as organizações
integrar dados de uma variedade de fontes em um modelo de dados comum. Dados integrados prometidos para fornecer
insights sobre processos operacionais e abrem novas possibilidades para alavancar dados para tomar decisões e criar
valor organizacional. Tão importante quanto, os data warehouses eram vistos como um meio de reduzir a proliferação de sistemas
de suporte à decisão (DSS), a maioria dos quais se baseava nos mesmos dados corporativos principais. o
381
382 • DMBOK2
O conceito de armazém corporativo prometia uma maneira de reduzir a redundância de dados, melhorar a consistência das
informações e permitir que uma empresa usasse seus dados para tomar melhores decisões.
Data Warehousing e Business Intelligence
Definição: Processos de planejamento, implementação e controle para fornecer dados de suporte à decisão e apoiar
os trabalhadores do conhecimento envolvidos em relatórios, consultas e análises.
Metas:
1. Construir e manter o ambiente técnico e os processos técnicos e de negócios necessários para entregar
dados integrados em suporte a funções operacionais, requisitos de conformidade e inteligência de negócios
Atividades.
2. Apoiar e permitir uma análise de negócios eficaz e tomada de decisões por trabalhadores do conhecimento.
O negócio
Motoristas
Entradas: Atividades: Entregáveis primários:

• • DW e BI
Requisitos de negócio 1. Entenda os Requisitos (P)
• 2. Definir e manter o DW e BI Arquitetura
Escalabilidade, Operacional,
A infraestrutura & • Produtos de dados
Arquitetura (P)
•
Requisitos de suporte 3. Desenvolver o Data Warehouse e Processo Populacional
•
Qualidade de dados, segurança • Atividades de Governança
Data Marts (D)
e Acesso •
4. Preencha o Data Warehouse (D) Dicionário de linhagem
Requisitos •
Aprendizagem e Adoção
• 5. Implemente o Business Intelligence
Estratégia de TI Plano
• Políticas de TI relacionadas e Carteira (D) • Plano de lançamento
Padrões 6. Manter Produtos de Dados (O) •
Suporte à produção
• Feeds de dados internos
Processo
• Mestre e Referência •
Carregar atividades de ajuste
Dados •
• Monitoramento de atividades de BI
Indústria e Externa
Dados

• Executivo de negócios • Em formação
• Patrocinadores e Proprietário do Produto
• Consumidores
• Órgão de Governança Arquitetos e Analistas
• • Clientes
Arquitetura Empresarial • Especialistas em DW/BI (Plataforma de BI, Dados
• Produtores de Dados Armazenamento, Gerenciamento de Informações) • Gerentes e
• Em formação • Executivos
Gerenciamento de projetos
Consumidores • Mudar a gestão
•
Técnico
Motoristas

•
• Protótipos para Dirigir • Repositórios de Metadados Métricas de uso
• Satisfação do Cliente/Usuário
Requisitos • Ferramentas de Integração de Dados
•
• BI de autoatendimento Cobertura da área de assunto %s
• Aplicativos analíticos •
Resposta/Desempenho
• Dados de auditoria que podem ser consultados
Métricas
Figura 79 Diagrama de contexto: DW/BI

ARMAZENAMENTO DE DADOS E INTELIGÊNCIA DE NEGÓCIOS • 383
Os data warehouses começaram a ser construídos a sério na década de 1990. Desde então (e especialmente com a co-evolução do Business
Intelligence como principal impulsionador da tomada de decisões de negócios), os data warehouses tornaram-se 'mainstream'. A maioria das
empresas possui data warehouses e o warehousing é o núcleo reconhecido do gerenciamento de dados corporativos.63 Embora bem estabelecido,
o data warehouse continua a evoluir. À medida que novas formas de dados são criadas com velocidade crescente, surgem novos conceitos, como
data lakes, que influenciarão o futuro do data warehouse. Consulte os Capítulos 8 e 15.
O principal fator para o armazenamento de dados é dar suporte a funções operacionais, requisitos de conformidade e atividades de Business
Intelligence (BI) (embora nem todas as atividades de BI dependam de dados de armazenamento). Cada vez mais, as organizações estão sendo
solicitadas a fornecer dados como evidência de que cumpriram os requisitos regulatórios.
Por conterem dados históricos, os armazéns costumam ser os meios para responder a essas solicitações. No entanto, o suporte de Business
Intelligence continua a ser o principal motivo para um warehouse. O BI promete insights sobre a organização, seus clientes e seus produtos. Uma
organização que atua com base no conhecimento adquirido com BI pode melhorar a eficiência operacional e a vantagem competitiva. À medida
que mais dados se tornam disponíveis em uma velocidade maior, o BI evolui de avaliação retrospectiva para análise preditiva.
As organizações implementam data warehouses para:
• Apoiar a atividade de Business Intelligence
• Permitir análise de negócios e tomada de decisões eficazes
• Encontre maneiras de inovar com base em insights de seus dados
A implementação de um Data Warehouse deve seguir estes princípios orientadores:
• Concentre-se nas metas de negócios: certifique-se de que o DW atenda às prioridades organizacionais e resolva os negócios
problemas.
• Comece com o objetivo em mente: deixe a prioridade de negócios e o escopo da entrega de dados finais no espaço de BI
conduzir a criação do conteúdo DW.
• Pensar e projetar globalmente; agir e construir localmente: Deixe a visão final guiar a arquitetura, mas construa e
entregar de forma incremental, por meio de projetos ou sprints focados que permitem um retorno mais imediato
investimento.
63 http://bit.ly/2sVPIYr.
384 • DMBOK2
• Resuma e otimize por último, não primeiro: construa com base nos dados atômicos. Agregar e resumir para atender
requisitos e garantir o desempenho, não para substituir o detalhe.
• Promover transparência e autoatendimento: quanto mais contexto (metadados de todos os tipos) for fornecido, mais
consumidores de dados mais capazes serão para obter valor dos dados. Manter as partes interessadas informadas sobre o
dados e os processos pelos quais eles são integrados.
• Crie metadados com o warehouse: fundamental para o sucesso do DW é a capacidade de explicar os dados. Por
Por exemplo, ser capaz de responder a perguntas básicas como “Por que essa soma é X?” “Como isso foi calculado?”
e “De onde vieram os dados?” Os metadados devem ser capturados como parte do ciclo de desenvolvimento
e geridos como parte das operações em curso.
• Colabore: colabore com outras iniciativas de dados, especialmente aquelas para Governança de Dados, Data
Qualidade e Metadados.
• Um tamanho não serve para todos: use as ferramentas e os produtos certos para cada grupo de consumidores de dados.
1.3.1 Inteligência de Negócios
O termo Business Intelligence (BI) tem dois significados. Em primeiro lugar, refere-se a um tipo de análise de dados que visa compreender as
atividades e oportunidades organizacionais. Os resultados de tal análise são usados para melhorar o sucesso organizacional. Quando as
pessoas dizem que os dados são a chave para a vantagem competitiva, elas estão articulando a promessa inerente à atividade de Business
Intelligence: que se uma organização fizer as perguntas certas de seus próprios dados, ela pode obter insights sobre seus produtos, serviços
e clientes que permitem para tomar melhores decisões sobre como cumprir seus objetivos estratégicos. Em segundo lugar, Business
Intelligence refere-se a um conjunto de tecnologias que suportam este tipo de análise de dados. Uma evolução das ferramentas de suporte a
decisões, as ferramentas de BI permitem consultas, mineração de dados, análise estatística, relatórios, modelagem de cenários, visualização
de dados e painéis. Eles são usados para tudo, desde orçamentos a análises avançadas.
1.3.2 Armazém de Dados
Um Data Warehouse (DW) é uma combinação de dois componentes principais: Um banco de dados integrado de suporte à decisão e os
programas de software relacionados usados para coletar, limpar, transformar e armazenar dados de uma variedade de fontes operacionais e
externas. Para dar suporte a requisitos históricos, analíticos e de BI, um data warehouse também pode incluir data marts dependentes, que
são cópias de subconjuntos de dados do warehouse. Em seu contexto mais amplo, um data warehouse inclui quaisquer armazenamentos ou
extrações de dados usados para dar suporte à entrega de dados para fins de BI.
Um Enterprise Data Warehouse (EDW) é um data warehouse centralizado projetado para atender às necessidades de BI de toda a
organização. Um EDW adere a um modelo de dados corporativos para garantir a consistência das atividades de suporte à decisão em toda
a empresa.
1.3.3 Armazenamento de Dados
Data Warehousing descreve os processos operacionais de extração, limpeza, transformação, controle e carregamento que mantêm os
dados em um data warehouse. O processo de armazenamento de dados se concentra em habilitar um contexto de negócios integrado e
histórico em dados operacionais, aplicando regras de negócios e mantendo relacionamentos de dados de negócios apropriados. O
armazenamento de dados também inclui processos que interagem com repositórios de metadados.
Tradicionalmente, o data warehousing se concentra em dados estruturados: elementos em campos definidos, seja em arquivos ou tabelas,
conforme documentado em modelos de dados. Com os recentes avanços em tecnologia, o espaço de BI e DW agora abrange dados
semiestruturados e não estruturados. Dados semiestruturados, definidos como elementos eletrônicos organizados como entidades
semânticas sem afinidade de atributo obrigatória, são anteriores ao XML, mas não ao HTML; uma transferência EDI poderia servir como
exemplo. Dados não estruturados referem-se a dados que não são predefinidos por meio de um modelo de dados. Porque dados não estruturados
existe em uma variedade de formatos e abrange itens como e-mail, texto em formato livre, documentos comerciais, vídeos, fotos e páginas
da Web, para citar alguns, definir uma construção de armazenamento viável que sustente cargas de trabalho analíticas dentro da
governança de armazenamento tem sido um desafio ainda a ser superado.
1.3.4 Abordagens para Data Warehousing
Grande parte da conversa sobre o que constitui um data warehouse foi conduzida por dois influentes líderes de pensamento – Bill Inmon e
Ralph Kimball – que têm abordagens diferentes para modelar e desenvolver warehouses. Inmon define um data warehouse como “uma
coleção de dados orientada por assunto, integrada, variável no tempo e não volátil em apoio ao processo de tomada de decisão da
administração”.64 Um modelo relacional normalizado é usado para armazenar e gerenciar dados. Kimball define um warehouse como “uma
cópia de dados de transação especificamente estruturados para consulta e análise”. A abordagem de Kimball exige um modelo dimensional.
Enquanto Inmon e Kimball defendem abordagens diferentes para a construção de armazéns, suas definições reconhecem
ideias centrais semelhantes:
• Armazéns armazenam dados de outros sistemas
• O ato de armazenamento inclui organizar os dados de forma a aumentar seu valor
• Armazéns tornam os dados acessíveis e utilizáveis para análise
• As organizações constroem armazéns porque precisam disponibilizar dados confiáveis e integrados para
partes interessadas autorizadas
• Os dados do armazém servem a muitos propósitos, desde suporte de fluxo de trabalho até gerenciamento operacional para
análise preditiva
64 http://bit.ly/1FtgeIL, último acesso em 27/02/2016.

386 • DMBOK2
1.3.5 Fábrica de Informações Corporativas (Inmon)
A Fábrica de Informações Corporativas (CIF) de Bill Inmon é um dos dois principais padrões para armazenamento de dados. As partes componentes
da definição de data warehouse da Inmon, “uma coleção orientada por assunto, integrada, variante no tempo e não volátil de dados históricos
resumidos e detalhados”, descrevem os conceitos que suportam o CIF e apontam para as diferenças entre armazéns e sistemas operacionais.
• Orientado ao assunto: O data warehouse é organizado com base nas principais entidades de negócios, em vez de
com foco em um funcional ou aplicativo.
• Integrado: Os dados no warehouse são unificados e coesos. As mesmas estruturas de chave, codificação e
decodificação de estruturas, definições de dados, convenções de nomenclatura são aplicadas de forma consistente em todo o
warehouse. Como os dados são integrados, os dados do Warehouse não são simplesmente uma cópia dos dados operacionais.
Em vez disso, o warehouse torna-se um sistema de registro dos dados.
• Variante de tempo: O data warehouse armazena os dados como existem em um ponto definido no tempo. Registros no DW são como
instantâneos. Cada um reflete o estado dos dados em um momento. Isso significa que a consulta de dados com base em um período
de tempo específico sempre produzirá o mesmo resultado, independentemente de quando a consulta

é submetido.
• Não volátil: No DW, os registros normalmente não são atualizados como nos sistemas operacionais. Em vez disso, novos dados são
anexados aos dados existentes. Um conjunto de registros pode representar diferentes estados do mesmo
transação.
• Dados agregados e detalhados: Os dados no DW incluem detalhes de transações de nível atômico, bem como
como dados resumidos. Os sistemas operacionais raramente agregam dados. Quando os armazéns foram estabelecidos
pela primeira vez, as considerações de custo e espaço levaram à necessidade de resumir os dados. Os dados resumidos podem ser
persistentes (armazenados em uma tabela) ou não persistentes (renderizados em uma exibição) em ambientes DW contemporâneos.
O fator decisivo para persistir os dados geralmente é o desempenho.
• Histórico: O foco dos sistemas operacionais são os dados atuais. Os armazéns também contêm dados históricos. Muitas vezes eles
abrigam grandes quantidades dele.
Inmon, Claudia Imhoff e Ryan Sousa descrevem o armazenamento de dados no contexto da Fábrica de Informação Corporativa (CIF). Consulte a
Figura 80. Os componentes CIF incluem:
• Aplicativos: Os aplicativos realizam processos operacionais. Os dados detalhados dos aplicativos são trazidos para o data warehouse
e os armazenamentos de dados operacionais (ODS) onde podem ser analisados.
• Área de preparo: um banco de dados que fica entre os bancos de dados de origem operacional e o destino
bancos de dados. A área de preparação de dados é onde ocorre o esforço de extração, transformação e carregamento. Não é
usado por usuários finais. A maioria dos dados na área de teste de dados é transitória, embora normalmente haja uma quantidade
relativamente pequena de dados persistentes.
• Integração e transformação: Na camada de integração, os dados de fontes distintas são transformados para que possam ser integrados
à representação/modelo corporativo padrão no DW e ODS.

• Armazenamento de Dados Operacionais (ODS): Um ODS é um banco de dados integrado de dados operacionais. Ele pode ser obtido diretamente
de aplicativos ou de outros bancos de dados. Os ODS geralmente contêm dados atuais ou de curto prazo (30-90 dias), enquanto um DW
também contém dados históricos (geralmente vários anos de dados). Os dados nos ODS's são voláteis, enquanto os dados do warehouse são
estáveis. Nem todas as organizações usam ODS. Eles evoluíram para atender à necessidade de dados de baixa latência. Um ODS pode servir
como fonte primária para um data warehouse; pode
também ser usado para auditar um data warehouse.
• Data marts: Data marts fornecem dados preparados para análise. Esses dados geralmente são um subconjunto de dados de armazenamento
projetados para dar suporte a tipos específicos de análise ou a um grupo específico de consumidores de dados. Por exemplo, os marts
podem agregar dados para dar suporte a análises mais rápidas. A modelagem dimensional (usando técnicas de desnormalização) é
frequentemente usada para projetar data marts orientados ao usuário.
• Operational Data Mart (OpDM): Um OpDM é um data mart focado no suporte a decisões táticas. Ele é obtido diretamente de um ODS, em vez
de um DW. Compartilha características do ODS: contém
dados atuais ou de curto prazo. Seu conteúdo é volátil.
• Data Warehouse: O DW fornece um único ponto de integração para suporte de dados corporativos
tomada de decisão gerencial e análise e planejamento estratégicos. Os dados fluem para um DW dos sistemas de aplicativos e ODS e fluem
para os data marts, geralmente em apenas uma direção. Os dados que precisam de correção são rejeitados, corrigidos em sua origem e,
idealmente, realimentados pelo sistema.
• Relatórios operacionais: Os relatórios são gerados a partir dos armazenamentos de dados.
• Dados de referência, mestre e externos: Além dos dados transacionais de aplicativos, o CIF também inclui dados necessários para entender
as transações, como dados mestre e de referência. O acesso a dados comuns simplifica a integração no DW. Enquanto os aplicativos
consomem dados mestre e de referência atuais, o DW também requer valores históricos e os prazos durante os quais eles foram válidos
(consulte o Capítulo 10).
A Figura 80 mostra o movimento dentro do CIF, desde a coleta e criação de dados por meio de aplicativos (à esquerda) até a criação de informações por
meio de marts e análise (à direita). O movimento da esquerda para a direita inclui outras alterações. Por exemplo, • O propósito muda da execução das
funções operacionais para a análise • Os usuários finais dos sistemas passam de trabalhadores da linha de frente para tomadores de decisão • O uso do
sistema passa de operações fixas para usos ad hoc • Os requisitos de tempo de resposta são relaxados (decisões estratégicas levam mais tempo do
que as operações diárias) • Muito mais dados estão envolvidos em cada operação, consulta ou processo
Os dados em DW e marts diferem daqueles em aplicativos: • Os dados são
organizados por assunto em vez de função • Os dados são dados integrados
em vez de 'silos' • Os dados são variantes no tempo versus apenas valores
atuais • Os dados têm maior latência no DW do que em aplicativos •
Significativamente mais dados históricos estão disponíveis em DW do que
em aplicativos
388 • DMBOK2
Histórico
Data de referência
Data de referência
Formulários Data Marts

Aplicativo
DM DM DM Análise*
Aplicativo Exploratório
DW Análise*
Aplicativo
no DM Operacional
Análise
Aplicativo
ODS
Relatórios operacionais Relatórios Operacionais

(por aplicativo) (integrados)
Figura 80 A Fábrica de Informações Corporativas
1.3.6 DW Dimensional (Kimball)
O Dimensional Data Warehouse de Kimball é o outro padrão primário para o desenvolvimento de DW. Kimball define um data warehouse
simplesmente como “uma cópia de dados de transação especificamente estruturados para consulta e análise” (Kimball, 2002). A 'cópia' não
é exata, no entanto. Os dados do warehouse são armazenados em um modelo de dados dimensional. O modelo dimensional é projetado
para permitir que os consumidores de dados compreendam e usem os dados, ao mesmo tempo em que permite o desempenho da
consulta.65 Ele não é normalizado da mesma forma que um modelo de relacionamento de entidade.
Frequentemente chamados de Star Schema, os modelos dimensionais são compostos de fatos, que contêm dados quantitativos sobre
processos de negócios (por exemplo, números de vendas) e dimensões, que armazenam atributos descritivos relacionados a dados de fatos
e permitem que os consumidores de dados respondam perguntas sobre os fatos (por exemplo, , quantas unidades do produto X foram
vendidas neste trimestre?) Uma tabela de fatos une-se a muitas tabelas de dimensão e, quando vista como um diagrama, aparece como uma estrela.
(Consulte o Capítulo 5.) Várias tabelas de fatos compartilharão as dimensões comuns, ou conformadas, por meio de um 'barramento',
semelhante a um barramento em um computador .

dimensões conformadas.
A matriz de barramento DW mostra a interseção de processos de negócios que geram dados de fatos e áreas de assunto de dados que
representam dimensões. Existem oportunidades para dimensões conformadas onde vários processos usam os mesmos dados. A Tabela 27
é uma matriz de barramento de amostra. Neste exemplo, os processos de negócios para Vendas, Estoque e Pedidos
65 http://bit.ly/1udtNC8.
66 O termo ônibus veio da formação em engenharia elétrica de Kimball, onde um ônibus era algo que fornece energia comum a vários
componentes elétricos.
todos requerem dados de Data e Produto. Vendas e Estoque exigem dados da Loja, enquanto Estoque e Pedidos exigem dados do
Fornecedor. Data, Produto, Loja e Fornecedor são todos candidatos a dimensões conformadas. Em contraste, o Warehouse não é
compartilhado; ele é usado apenas pelo Inventário.
Tabela 27 Exemplo de matriz de barramento DW
Áreas de Assunto
Processos de negócios Data Armazém do Fornecedor da Loja do Produto
Vendas X X X
Inventário X X X X X
Pedidos X X X
Candidato a Dimensão Conformada Sim Sim Sim Sim Não
A matriz de barramento DW empresarial pode ser usada para representar os requisitos de conteúdo de dados de longo prazo para o sistema
DW/BI, independentemente da tecnologia. Essa ferramenta permite que uma organização alcance os esforços de desenvolvimento gerenciáveis.
Cada implementação cria um incremento da arquitetura geral. Em algum momento, existem esquemas dimensionais suficientes para
cumprir a promessa de um ambiente integrado de data warehouse empresarial.
A Figura 81 representa a visualização de peças de xadrez do data warehouse de Kimball da arquitetura DW/BI. Observe que o Data
Warehouse de Kimball é mais expansivo que o de Inmon. O DW engloba todos os componentes nas áreas de preparação de dados e
apresentação de dados.
• Sistemas de origem operacional: Aplicações operacionais/transacionais da Empresa. Estes criam
os dados que estão integrados no ODS e DW. Este componente é equivalente ao aplicativo
sistemas no diagrama CIF.
• Área de teste de dados: o teste de Kimball inclui o conjunto de processos necessários para integrar e transformar
dados para apresentação. Pode ser comparado a uma combinação de integração, transformação e
componentes DW. O foco de Kimball está na entrega final eficiente dos dados analíticos, um escopo menor
do que o gerenciamento corporativo de dados da Inmon. O DW corporativo da Kimball pode se encaixar na arquitetura de
a área de armazenamento de dados.
• Área de apresentação de dados: Semelhante aos Data Marts do CIF. A principal diferença arquitetônica é
um paradigma integrador de um 'barramento DW', como dimensões compartilhadas ou conformadas unificando as múltiplas
data marts.
• Ferramentas de acesso a dados: a abordagem da Kimball se concentra nos requisitos de dados dos usuários finais. Essas necessidades impulsionam o
adoção de ferramentas apropriadas de acesso a dados.
1.3.7 Componentes da Arquitetura DW
O ambiente de data warehouse inclui uma coleção de componentes de arquitetura que precisam ser organizados para atender às
necessidades da empresa. A Figura 82 descreve os componentes de arquitetura do DW/BI e do Ambiente de Big Data discutidos nesta
seção. A evolução do Big Data mudou o cenário DW/BI, adicionando outro caminho pelo qual os dados podem ser trazidos para uma
empresa.
390 • DMBOK2
Preparação de dados Dados Acesso de dados

Área Apresentação Ferramentas
Área
Operacional
Fonte
Sistemas
SERVIÇOS:
ÿ Limpar
ÿ Combinar
PARA ISSO
Extrair ÿ Padronizar Carregar
Data Mart #1 Acesso
ÿ Conforme DÚVIDAS
Dimensões
Dimens
Confor Extrair
DWBUS
Extrair
SEM DÚVIDAS
BANCO DE DADOS:
ÿ Arquivos
Carregar
Planos ÿ Tabelas Relacionais

ÿ Conjuntos de dados XML Carregar
Data Mart #2
Acesso
RELATÓRIO
ESCRITORAS
ANALÍTICO
Acesso FORMULÁRIOS
MODELOS:
EM PROCESSAMENTO:
DataMart #N ÿ Previsão
Extrair ÿ Ordenação Carregar Acesso
ÿ Sequenciamento ÿ Pontuação
ÿ Mineração de Dados
Figura 81 Peças de xadrez do data warehouse de Kimball 67
A Figura 82 também descreve aspectos do ciclo de vida dos dados. Os dados são movidos dos sistemas de origem para uma área
de preparação onde podem ser limpos e enriquecidos à medida que são integrados e armazenados no DW e/ou em um ODS. A
partir do DW, ele pode ser acessado via marts ou cubos e usado para vários tipos de relatórios. O Big Data passa por um processo
semelhante, mas com uma diferença significativa: enquanto a maioria dos armazéns integra os dados antes de colocá-los nas
tabelas, as soluções de Big Data ingerem os dados antes de integrá-los. Big Data BI pode incluir análise preditiva e mineração de
dados, bem como formas mais tradicionais de relatórios. (Consulte o Capítulo 14.)
1.3.7.1 Sistemas de Origem
Os Sistemas de Origem, no lado esquerdo da Figura 82, incluem os sistemas operacionais e dados externos a serem trazidos para
o ambiente DW/BI. Isso normalmente inclui sistemas operacionais, como aplicativos de CRM, contabilidade e recursos humanos,
bem como sistemas operacionais que diferem de acordo com o setor. Dados de fornecedores e fontes externas também podem ser
incluídos, assim como DaaS, conteúdo da web e quaisquer resultados de computação de Big Data.
1.3.7.2 Integração de Dados
A integração de dados abrange Extração, Transformação e Carregamento (ETL), virtualização de dados e outras técnicas de
obtenção de dados em um formato e local comuns. Em um ambiente SOA, as camadas de serviços de dados fazem parte desse
componente. Na Figura 82, todas as setas representam processos de integração de dados. (Consulte o Capítulo 8.)
67 Adaptado de Kimball e Ross (2002). Usado com permissão.

DW/BI Conceitual e Arquitetura de Big Data
Fontes Armazém de dados COM UM
Inscrição Domínio de dados

Operacional Intervenção de qualidade de dados
Comunicando Enriquecimento e Aumento
Dependente
Área de preparo Relatório operacional
Armazenamentos de dados
& Análises
Limpar
Geoespacial e
Operacional ODS
Integrar Análise Demográfica
Sistemas Enriquecer Armazém Central
atuação
Padronizar
Data Mart Gestão
Orientado ao assunto
Não volátil
Visualização de dados
DaaS Tempo variável
Referência &
atômico
Big Data Dados mestre
MDM Data histórica Mineração de dados e texto
Resultados Conformado Cubos
Dimensões Não estruturado
Big Data Análise

E-mail
Multimídia
© DATALEADERS.ORG
Análise preditiva
Sensores Avalie
IoT Ingerir Integrar Explorar
Rede Social
Data Lake Modelo
Web DaaS Aprendizado de máquina
DW
Figura 82 DW/BI conceitual e arquitetura de Big Data
1.3.7.3 Áreas de Armazenamento de Dados
O armazém dispõe de um conjunto de zonas de armazenamento:
• Área de preparo: uma área de preparo é um armazenamento de dados intermediário entre uma fonte de dados original e o
repositório de dados centralizado. Os dados são encenados para que possam ser transformados, integrados e preparados para
carregamento para o armazém.
• Dimensões em conformidade com os dados mestre e de referência: os dados mestre e de referência podem ser armazenados em
repositórios separados. O data warehouse alimenta novos dados mestres e é alimentado por dimensão conformada
conteúdo dos repositórios separados.
• Armazém Central: Uma vez transformados e preparados, os dados DW geralmente persistem na central ou
camada atômica. Esta camada mantém todos os dados atômicos históricos, bem como a última instância do lote
corre. A estrutura de dados desta área é desenvolvida e influenciada com base nas necessidades de desempenho e uso
padrões. Vários elementos de design são trazidos para suportar:
o A relação entre a chave de negócios e as chaves substitutas para desempenho
o Criação de índices e chaves estrangeiras para suportar dimensões
o Técnicas de Change Data Capture (CDC) que são usadas para detectar, manter e armazenar o histórico
392 • DMBOK2
• Armazenamento de Dados Operacionais (ODS): O ODS é uma versão de um armazenamento central persistente que suporta
latências e, portanto, uso operacional. Como o ODS contém uma janela de tempo de dados e não o
histórico, ele pode ser atualizado muito mais rapidamente do que um armazém. Às vezes, os fluxos em tempo real são
instantâneos em intervalos predefinidos no ODS para permitir relatórios e análises integrados. Sobre
tempo, com a crescente frequência de atualizações impulsionadas pelas necessidades de negócios e tecnologia e
técnicas para integrar dados em tempo real no DW, muitas instalações fundiram seus ODS no
arquitetura DW ou Data Mart existente.
• Data marts: um data mart é um tipo de armazenamento de dados frequentemente usado para suportar camadas de apresentação dos dados
ambiente de armazém. Também é usado para apresentar um subconjunto departamental ou funcional do DW
para relatórios integrados, consultas e análises de informações históricas. O data mart é orientado para um
área de assunto específica, um único departamento ou um único processo de negócios. Também pode constituir a base de uma
armazém virtualizado onde os marts combinados compreendem a entidade de armazém resultante. Dados
processos de integração atualizarão, atualizarão ou expandirão o conteúdo dos vários marts do
camada de persistência.
• Cubos: Três abordagens clássicas de implementação suportam o Processamento Analítico Online (OLAP). Seus
nomes estão relacionados a tipos de banco de dados subjacentes, como Relacional, Multidimensional e Híbrido.
1.3.8 Tipos de Processamento de Carga
O armazenamento de dados envolve dois tipos principais de processos de integração de dados: cargas históricas e atualizações contínuas.
Os dados históricos geralmente são carregados apenas uma vez ou algumas vezes durante a resolução de problemas de dados e nunca mais.
As atualizações contínuas são agendadas e executadas de forma consistente para manter os dados no warehouse atualizados.
1.3.8.1 Dados Históricos
Uma vantagem de um data warehouse é que ele pode capturar o histórico detalhado dos dados que armazena. Existem diferentes métodos para capturar
esse detalhe. Uma organização que deseja capturar o histórico deve projetar com base nos requisitos. Ser capaz de reproduzir instantâneos point-in-time
requer uma abordagem diferente do que simplesmente apresentar o estado atual.
O data warehouse Inmon sugere que todos os dados sejam armazenados em uma única camada de data warehouse. Essa camada armazenará dados
de nível atômico limpos, padronizados e governados. Uma camada comum de integração e transformação facilita a reutilização nas implementações de
entrega. Um modelo de dados corporativos é necessário para o sucesso. Uma vez validado, esse armazenamento único está disponível para diferentes
consumidores de dados por meio de um data mart estruturado em estrela.
O data warehouse Kimball sugere que o data warehouse é composto por uma combinação de data marts departamentais contendo dados limpos,
padronizados e governados. Os data marts armazenarão o histórico no nível atômico. Dimensões e fatos conformados fornecerão informações de nível
empresarial.
DATA WAREHOUSING E INTELIGÊNCIA DE NEGÓCIOS • 393
Outra abordagem, o Data Vault, também limpa e padroniza como parte do processo de preparação. O histórico é armazenado em uma estrutura atômica
normalizada, substituto dimensional, chaves primárias e alternativas são definidas. Garantir que o relacionamento de negócios e chave substituta
permaneça intacto se torna a função secundária do cofre – esse é o histórico do data mart. Os fatos persistiram aqui como estruturas atômicas. O cofre
fica então disponível para uma variedade de consumidores de dados por meio de data marts. Ao reter o histórico dentro do cofre, é possível recarregar
os fatos quando os incrementos posteriores introduzem alterações de granulação. É possível virtualizar a camada de apresentação, facilitando a entrega
incremental ágil e o desenvolvimento colaborativo com a comunidade empresarial. Um processo de materialização final pode implementar um data mart
em estrela mais tradicional para consumo do usuário final de produção.
1.3.8.2 Captura de Dados de Alteração de Lote
Os Data Warehouses geralmente são carregados diariamente e atendidos por uma janela de lote noturna. O processo de carregamento pode acomodar
uma variedade de detecção de alterações, pois cada sistema de origem pode exigir diferentes capturas de alterações
técnicas.
As técnicas de log de banco de dados são prováveis candidatas para aplicativos desenvolvidos internamente, pois é improvável que os aplicativos
adquiridos pelo fornecedor tolerem modificações com gatilhos ou sobrecarga adicional. Cargas com carimbo de hora ou tabela de log são as mais
comuns. As cargas completas ocorrem ao lidar com sistemas legados construídos sem recursos de registro de data e hora nativos (sim, existem
aplicativos sem bancos de dados) ou quando certas condições de recuperação em lote se aplicam.
A Tabela 28 resume a diferença entre as técnicas de captura de dados de alterações, incluindo sua relativa complexidade e velocidade. A coluna de
sobreposição identifica se pode haver duplicação de dados entre as alterações do sistema de origem e o ambiente de destino. Quando a Sobreposição
for 'Sim', esses dados alterados podem já estar presentes. Quando o indicador Excluir é definido como 'Sim', o Método de alteração de dados rastreará
todas as exclusões que ocorreram no sistema de origem - útil para dimensões expiradas que não estão mais em uso. Quando as exclusões não são
rastreadas pelo sistema de origem, esforços adicionais são necessários para determinar quando elas ocorrem. (Consulte o Capítulo 8.)
Tabela 28 Comparação da Técnica do CDC
Método Complexidade do Requisito do Sistema de Origem Facto Dimensão Exclusões de sobreposição

Carregar Carregar
Data As alterações no sistema de origem são

carimbada marcadas com a data e hora do sistema. Baixo Velozes Velozes Sim Não
Carga Delta
Tabela de registro As alterações do sistema de origem
Carga Delta são capturadas e armazenadas em tabelas Nominal Nominal Médio Sim Sim
Base de dados de log O banco de dados captura as alterações
Transação no log de transações Alto Nominal Nominal Não Sim
Registro
Mensagem As alterações do sistema de origem

Delta são publicadas como mensagens [quase] Extremo Lento Lento Não Sim
em tempo real
Full Load Sem indicador de mudança, tabelas extraídas
na íntegra e comparadas para identificar a Simples Lento Nominal Sim Sim
mudança
394 • DMBOK2
1.3.8.3 Quase em tempo real e em tempo real
Com o início do BI Operacional (ou Análise Operacional) pressionando por menor latência e mais integração de dados em tempo real ou quase em tempo real no
data warehouse, surgiram novas abordagens de arquitetura para lidar com a inclusão de dados voláteis. Por exemplo, uma aplicação comum de BI operacional é
o provisionamento automatizado de dados de máquinas bancárias. Ao realizar uma transação bancária, os saldos históricos e os novos saldos resultantes de
ações bancárias imediatas precisam ser apresentados ao cliente bancário em tempo real. Dois conceitos-chave de design necessários para o provisionamento de
dados quase em tempo real são o isolamento de alterações e as alternativas ao processamento em lote.
O impacto das alterações de novos dados voláteis deve ser isolado da maior parte dos dados históricos e não voláteis do DW. As abordagens arquitetônicas
típicas para isolamento incluem uma combinação de partições de construção e o uso de consultas de união para as diferentes partições. As alternativas ao
processamento em lote lidam com os requisitos de latência cada vez mais curtos para disponibilidade de dados no DW. Existem três tipos principais: feeds trickle,
mensagens e streaming, que diferem de acordo com o local onde os dados são acumulados enquanto aguardam para serem processados. (Consulte o Capítulo
8.)
• Feeds de gotejamento (acumulação de fonte): em vez de executar uma programação noturna, os feeds de gotejamento são executados
carregamentos de lote em uma programação mais frequente (por exemplo, de hora em hora, a cada 5 minutos) ou quando um limite é atingido
(por exemplo, 300 transações, 1G de dados). Isso permite que algum processamento aconteça durante o dia, mas não tão
intensamente como com um processo de lote noturno dedicado. É necessário cuidado para garantir que, se um lote de alimentação de gotejamento
leva mais tempo para ser concluído do que o tempo entre os feeds, o próximo feed é atrasado para que os dados ainda sejam
carregado na ordem correta.
• Mensagens (acumulação de barramento): A interação de mensagens em tempo real ou quase em tempo real é útil quando
pacotes de dados extremamente pequenos (mensagens, eventos ou transações) são publicados em um barramento
ocorrer. Os sistemas de destino se inscrevem no barramento e processam incrementalmente os pacotes no warehouse
como necessário. Os sistemas de origem e os sistemas de destino são independentes um do outro. Dados como serviço (DaaS)
freqüentemente usa este método.
• Streaming (acumulação de destino): em vez de esperar em uma programação ou limite baseado na origem, um destino
o sistema coleta dados à medida que são recebidos em uma área de buffer ou fila e os processa em ordem. O resultado
interação ou algum agregado pode aparecer mais tarde como um feed adicional para o armazém.
2. Atividades
2.1 Compreender os Requisitos
Desenvolver um data warehouse é diferente de desenvolver um sistema operacional. Os sistemas operacionais dependem de requisitos precisos e específicos.
Os data warehouses reúnem dados que serão usados de várias maneiras diferentes. Além disso, o uso evoluirá ao longo do tempo à medida que os usuários
analisam e exploram os dados. Tome tempo nas fases iniciais

para fazer perguntas relacionadas a recursos e fontes de dados para dar suporte a esses recursos. Esse tempo de projeto compensa em
custos de retrabalho reduzidos posteriormente, quando o processamento de dados está sendo testado usando as fontes de dados reais.
Ao coletar requisitos para projetos de DW/BI, comece com as metas e a estratégia de negócios. Identificar e definir o escopo das áreas de
negócios e, em seguida, identificar e entrevistar as pessoas de negócios apropriadas. Pergunte o que eles fazem e por quê. Capture perguntas
específicas que eles estão fazendo agora e aquelas que eles desejam fazer sobre os dados. Documente como eles distinguem e categorizam
aspectos importantes da informação. Sempre que possível, defina e capture as principais métricas e cálculos de desempenho. Eles podem
descobrir regras de negócios que fornecem a base para a automação das expectativas de qualidade de dados.
Catalogue os requisitos e priorize-os entre os necessários para a entrada em operação da produção e a adoção do armazém e os que podem
esperar. Procure itens simples e valiosos para impulsionar a produtividade da versão inicial do projeto. A redação dos requisitos do projeto DW/
BI deve enquadrar todo o contexto das áreas de negócios e/ou processos que estão no escopo.
2.2 Definir e manter a arquitetura DW/BI
A arquitetura DW/BI deve descrever de onde os dados vêm, para onde vão, quando vão, por que e como vão para um warehouse. O 'como'
inclui os detalhes de hardware e software e a estrutura de organização para reunir todas as atividades. Os requisitos técnicos devem incluir
necessidades de desempenho, disponibilidade e tempo. (Consulte os Capítulos 4 e 8.)
2.2.1 Definir a Arquitetura Técnica DW/ BI
As melhores arquiteturas de DW/BI projetarão um mecanismo para conectar de volta a relatórios de nível transacional e operacional em um
DW atômico. Esse mecanismo protegerá o DW de ter que carregar todos os detalhes transacionais. Um exemplo é fornecer um mecanismo de
visualização para os principais relatórios operacionais ou formulários baseados em uma chave transacional, como o número da fatura. Os
clientes sempre desejarão todos os detalhes disponíveis, mas alguns dos dados operacionais, como campos de descrição longos, têm valor
apenas no contexto do relatório original e não fornecem valor analítico.
Uma arquitetura conceitual é um ponto de partida. Muitas atividades são necessárias para alinhar corretamente os requisitos não funcionais às
necessidades do negócio. A prototipagem pode rapidamente provar ou refutar pontos-chave antes de assumir compromissos caros com
tecnologias ou arquiteturas. Além disso, capacitar a comunidade empresarial com programas de conhecimento e adoção defendidos por meio
de uma equipe de gerenciamento de mudanças sancionada ajudará na transição e no sucesso operacional contínuo.
Uma extensão natural desse processo de transformação é a manutenção, ou pelo menos a validação, com o modelo de dados corporativos.
Como o foco está em quais estruturas de dados estão em uso por quais áreas organizacionais, verifique a implantação física em relação ao
modelo lógico. Faça quaisquer atualizações se surgirem omissões ou erros.

396 • DMBOK2
2.2.2 Definir processos de gerenciamento de DW/ BI
Aborde a gestão da produção com um processo de manutenção coordenado e integrado, entregando lançamentos regulares para a comunidade
empresarial.
É crucial estabelecer um plano de liberação padrão (consulte a Seção 2.6). Idealmente, a equipe de projeto do warehouse deve gerenciar cada
atualização do produto de dados implantado como uma versão de software que fornece funcionalidades adicionais.
Estabelecer um cronograma para lançamentos permite um plano anual de demanda e recursos e um cronograma de entrega padrão. Use a
versão interna para ajustar esse cronograma padronizado, as expectativas e estimativas de recursos
folhas derivadas para ele.
O estabelecimento de um processo de liberação funcional garante que o gerenciamento entenda que este é um processo proativo centrado
em produtos de dados e não um produto instalado endereçado por meio de resolução reativa de problemas. É fundamental trabalhar de forma
pró-ativa e colaborativa em uma equipe multifuncional para aumentar e aprimorar continuamente os recursos – os sistemas de suporte reativos
reduzem a adoção.
2.3 Desenvolver o Data Warehouse e Data Marts
Normalmente, os projetos DW/BI têm três faixas de desenvolvimento simultâneas:
• Dados: Os dados necessários para apoiar a análise que o negócio deseja fazer. Esta faixa envolve
identificar as melhores fontes para os dados e projetar regras para como os dados são corrigidos,
transformados, integrados, armazenados e disponibilizados para uso pelos aplicativos. Esta etapa também inclui
decidir como lidar com dados que não atendem às expectativas.
• Tecnologia: Os sistemas e processos de back-end que suportam o armazenamento e movimentação de dados.
A integração com o empreendimento existente é fundamental, pois o armazém não é uma ilha em si.
As Arquiteturas Empresariais, especificamente as especialidades de Tecnologia e Aplicativos, geralmente gerenciam esse

acompanhar.
• Ferramentas de Business Intelligence: o conjunto de aplicativos necessários para que os consumidores de dados obtenham
insights de produtos de dados implantados.
2.3.1 Mapear origens para destinos
O mapeamento de origem para destino estabelece regras de transformação para entidades e elementos de dados de origens individuais para
um sistema de destino. Esse mapeamento também documenta a linhagem de cada elemento de dados disponível no ambiente de BI de volta
para sua(s) respectiva(s) fonte(s).
A parte mais difícil de qualquer esforço de mapeamento é determinar links válidos ou equivalências entre elementos de dados em vários
sistemas. Considere o esforço para consolidar dados em um DW de vários faturamentos ou pedidos

sistemas de gestão. As chances são de que tabelas e campos que contêm dados equivalentes não tenham o mesmo
nomes ou estruturas.
Uma taxonomia sólida é necessária para mapear elementos de dados em diferentes sistemas para uma estrutura consistente no DW.
Na maioria das vezes, essa taxonomia é o modelo de dados lógico. O processo de mapeamento também deve abordar se os dados em diferentes
estruturas devem ser anexados, alterados ou inseridos.
2.3.2 Corrigir e Transformar Dados
As atividades de correção ou limpeza de dados impõem padrões e corrigem e aprimoram os valores de domínio de elementos de dados individuais.
A correção é particularmente necessária para carregamentos iniciais em que um histórico significativo está envolvido. Para reduzir a complexidade
do sistema de destino, os sistemas de origem devem ser responsáveis pelos dados

remediação e correção.
Desenvolva estratégias para linhas de dados que são carregadas, mas consideradas incorretas. Uma política para excluir registros antigos pode
causar alguns estragos com tabelas relacionadas e chaves substitutas, expirar uma linha e carregar os novos dados como uma linha
completamente nova pode ser uma opção melhor.
Uma estratégia de carregamento otimista pode incluir a criação de entradas de dimensão para acomodar dados de fatos. Esse processo deve
levar em conta como atualizar e expirar essas entradas. As estratégias de carregamento pessimistas devem incluir uma área de reciclagem para
dados de fatos que não podem ser associados às chaves de dimensão correspondentes. Essas entradas exigem notificações, alertas e relatórios
apropriados para garantir que sejam rastreadas e recarregadas posteriormente. Os trabalhos de fato devem considerar primeiro o carregamento
de entradas recicladas e, em seguida, o processamento do conteúdo recém-chegado.
A transformação de dados concentra-se em atividades que implementam regras de negócios dentro de um sistema técnico. A transformação de
dados é essencial para a integração de dados. Definir as regras corretas para integrar os dados geralmente requer o envolvimento direto dos
Data Stewards e outras PMEs. As regras devem ser documentadas para que possam ser governadas. As ferramentas de integração de dados
executam essas tarefas. (Consulte o Capítulo 8.)
2.4 Preencher o Data Warehouse
A maior parte do trabalho em qualquer esforço de DW/BI é a preparação e o processamento dos dados. As decisões e princípios de design para
quais detalhes de dados o DW contém são uma prioridade de design fundamental para a arquitetura DW/BI.
A publicação de regras claras sobre quais dados estarão disponíveis apenas por meio de relatórios operacionais (como em não-DW) é
crítico para o sucesso dos esforços de DW/BI.
Os principais fatores a serem considerados ao definir uma abordagem de população são a latência necessária, disponibilidade de fontes, janelas
de lote ou intervalos de upload, bancos de dados de destino, aspectos dimensionais e consistência de prazo do data warehouse e data mart. A
abordagem também deve abordar o processamento de qualidade de dados, tempo para realizar transformações e dimensões de chegada tardia
e rejeições de dados.
398 • DMBOK2
Outro aspecto para definir uma abordagem de população gira em torno do processo de captura de dados de alterações – detectar
alterações no sistema de origem, integrar essas alterações e alinhar as alterações ao longo do tempo. Vários bancos de dados agora
fornecem a funcionalidade de captura de log na qual as ferramentas de integração de dados podem operar diretamente, de modo que o
banco de dados informa ao usuário o que mudou. Os processos de script podem ser escritos ou gerados onde esta função não está
disponível. Várias técnicas estão disponíveis para as equipes de design e construção para integração e alinhamento de latência em feeds
heterogêneos.
O primeiro incremento abre caminho para o desenvolvimento de capacidades adicionais e integração de novas unidades de negócios.
Muitas novas tecnologias, processos e habilidades são necessárias, bem como um planejamento cuidadoso e atenção aos detalhes.
Os incrementos downstream devem ser construídos sobre esse elemento fundamental, portanto, mais investimentos são recomendados
para sustentar dados de alta qualidade, arquitetura técnica e transição para produção. Crie processos para facilitar e automatizar a
identificação oportuna de erros de dados com a integração do fluxo de trabalho do usuário final.
2.5 Implementar o Portfólio de Business Intelligence
Implementar o Portfólio de BI é identificar as ferramentas certas para as comunidades de usuários certas dentro ou entre as unidades de
negócios. Encontre semelhanças por meio do alinhamento de processos de negócios comuns, análise de desempenho, estilos de
gerenciamento e requisitos.
2.5.1 Agrupar usuários de acordo com as necessidades
Ao definir os grupos de usuários-alvo, há um espectro de necessidades de BI. Primeiro, conheça os grupos de usuários e depois combine
a ferramenta com os grupos de usuários da empresa. Em uma extremidade do espectro estão os desenvolvedores de TI preocupados com
a extração de dados, que se concentram em funcionalidades avançadas. Por outro lado, os consumidores de informação podem querer
acesso rápido a relatórios previamente desenvolvidos e executados. Esses consumidores podem querer algum grau de interatividade,
como detalhar, filtrar, classificar, ou podem apenas querer ver um relatório estático.
Os usuários podem mudar de uma classe para outra à medida que suas habilidades aumentam ou executam funções diferentes. Um
gerente da cadeia de suprimentos, por exemplo, pode querer visualizar um relatório estático sobre finanças, mas um relatório altamente
interativo para análise de estoque. Um analista financeiro e um gerente de linha responsável pelas despesas podem ser usuários avançados
ao analisar as despesas totais, mas ficam satisfeitos com um relatório estático de uma conta telefônica. Executivos e gerentes usarão uma
combinação de relatórios fixos, painéis e scorecards. Os gerentes e usuários avançados tendem a querer detalhar esses relatórios e cortar
os dados para identificar as causas-raiz dos problemas. Os clientes externos podem usar qualquer uma dessas ferramentas como parte de
sua experiência.
2.5.2 Combinar as ferramentas com os requisitos do usuário
O mercado oferece uma variedade impressionante de ferramentas de relatórios e análises. Os principais fornecedores de BI oferecem
recursos clássicos de relatórios perfeitos para pixels que antes eram o domínio dos relatórios de aplicativos. Muitos fornecedores de aplicativos
oferecem análises incorporadas com conteúdo padrão obtido de cubos pré-preenchidos ou tabelas agregadas.
A virtualização confundiu as linhas entre fontes de dados locais e dados externos comprados ou abertos e, em alguns casos,
fornece integração centrada em relatórios controlados pelo usuário sob demanda. Em outras palavras, é prudente que as empresas
usem infraestrutura e mecanismos de entrega comuns. Isso inclui a web, e-mail e aplicativos para a entrega de todos os tipos de
informações e relatórios, dos quais DW/BI é um subconjunto.
Muitos fornecedores estão agora combinando ferramentas de BI relacionadas, por meio de fusões e aquisições ou novos
desenvolvimentos líquidos, e oferecendo suítes de BI. As suítes são a principal opção no nível da Arquitetura Corporativa, mas
como a maioria das organizações já comprou ferramentas individuais ou adotou ferramentas de código aberto, é provável que
surjam questões sobre substituição versus coexistência. Lembre-se de que toda ferramenta de BI tem um preço, exigindo recursos
do sistema, suporte, treinamento e integração arquitetônica.
2.6 Manter produtos de dados
Um warehouse implementado e suas ferramentas de BI voltadas para o cliente são um produto de dados. Aprimoramentos
(extensões, aumentos ou modificações) em uma plataforma DW existente devem ser implementados de forma incremental.
Manter o escopo para um incremento e executar um caminho crítico para os principais itens de trabalho pode ser um desafio em
um ambiente de trabalho dinâmico. Defina prioridades com parceiros de negócios e concentre o trabalho em melhorias obrigatórias.
2.6.1 Gerenciamento de Liberação
O Gerenciamento de Liberação é fundamental para um processo de desenvolvimento incremental que aumenta novos recursos,
aprimora a implantação de produção e garante o fornecimento de manutenção regular em todos os ativos implantados. Esse
processo manterá o armazém atualizado, limpo e operando da melhor maneira possível. No entanto, esse processo requer o
mesmo alinhamento entre TI e Negócios que entre o modelo de Data Warehouse e os recursos de BI. É um esforço de melhoria
contínua.
A Figura 83 ilustra um exemplo de processo de liberação, com base em uma programação trimestral. Ao longo do ano, há três
versões voltadas para negócios e uma versão baseada em tecnologia (para atender aos requisitos internos do warehouse).
O processo deve permitir o desenvolvimento incremental do armazém e o gerenciamento do backlog de requisitos.
2.6.2 Gerenciar o ciclo de vida de desenvolvimento de produtos de dados
Enquanto os consumidores de dados estão usando o DW existente, a equipe de DW está se preparando para a próxima iteração,
com o entendimento de que nem todos os itens irão para produção. Alinhe as iterações às liberações com uma lista de trabalho de
pedidos pendentes priorizada pelas unidades de negócios. Cada iteração estenderá um incremento existente ou adicionará novas
funcionalidades integrando uma unidade de negócios. As versões alinharão a funcionalidade à unidade de negócios, enquanto a
iteração alinhará a funcionalidade à própria configuração gerenciada pelo gerente de produto.
400 • DMBOK2
• 3 releases trimestrais para negócios

Liberação Comercial +1 Liberação Comercial +2 Liberação Comercial +3
unidades cada uma fornecendo
Entrega incremental Entrega incremental Entrega incremental
capacidades incrementais
Período trimestral Período trimestral Período trimestral
• Escopo de trabalho gerenciado com
Requisitos Congelados Requisitos Congelados Requisitos Congelados Lista de MoSCoW
Priorização de Trabalho Priorização de Trabalho Priorização de Trabalho
• Tempo gerenciado com TimeBoxes
(Moscou) (Moscou) (Moscou)
DEVO
Deve
Poderia
4º Lançamento é um
Entrega Interna
BICC
Análise Versão Interna 0

Priorização de Trabalho Não vai De-escopo
Período trimestral
0.1 Produtos de colheita
0.2 Atualizar estimativas

0,3 Lições Aprendidas
0.4 Gestão do Conhecimento
0.5 Atualização de Software/Hardware
BICC 0.6 Treinamento / Educação

0.7 Endereçamento das soluções alternativas
Implementação
Mitigar
Priorização
Trabalhar
Por aí
Publicar
BICC
Defeito
Limitações
(Curso de Trabalho)
Plano de Liberação +4,5,6 => Da Entrada de Trabalho

triada em relação à Lista MoSCoW da Liberação 1,2,3
0.1 Atualização de Entregas do Método
Defeitos conhecidos
0.2 Atualização da Calculadora de Esforço de Trabalho
Mitigar
0.3 Atualização das melhores práticas
0.4 Atualização de Conscientização
0.5 Atualização do Horizonte de Capacidade de Software /

Hardware
0.6 Atualização de Certificação de Recursos
0.7 Atualização de Alinhamento Tático para Estratégico
Figura 83 Exemplo de processo de liberação
Os itens que os negócios acreditam estarem prontos e viáveis para investigação adicional podem ser revisados, ajustados se
necessário e, em seguida, promovidos para um ambiente piloto ou sandbox, onde os usuários de negócios investigam novas
abordagens, experimentam novas técnicas ou desenvolvem novos modelos ou algoritmos de aprendizado. Esta área pode ter
menos governança e supervisão do que outras áreas voltadas para os negócios, mas alguma forma de priorização de sandbox é
necessário.
Semelhante à garantia de qualidade tradicional ou ambiente de teste, examine os itens na área piloto para se adequar ao
mundo da produção. O desempenho dos itens piloto determina seus próximos passos. Tome cuidado para não promover
cegamente e sem levar em conta a qualidade dos dados downstream ou questões de governança. A vida útil na produção é
apenas uma medida existencial: deve ser da mais alta qualidade prática para estar em produção.
Os itens aprovados no piloto e considerados prontos para produção por representantes de negócios e de TI podem ser promovidos
para produção como novos produtos de dados. Isso completa uma iteração.
Os itens que não passarem no piloto podem ser rejeitados inteiramente ou devolvidos ao desenvolvimento para ajustes. Talvez seja
necessário suporte adicional da equipe DW neste momento para avançar o item na próxima iteração da promoção.
2.6.3 Monitorar e Ajustar os Processos de Carga
Monitore o processamento de carga em todo o sistema quanto a gargalos e dependências. Empregue técnicas de ajuste de banco de
dados onde e quando necessário, incluindo particionamento, backup ajustado e estratégias de recuperação. O arquivamento é um
assunto difícil no armazenamento de dados.
Os usuários geralmente consideram o data warehouse como um arquivamento ativo devido aos longos históricos que são construídos
e não estão dispostos, principalmente se as fontes On Line Analytical Processing (OLAP) tiverem descartado registros, para ver o data
warehouse se engajar no arquivamento. (Consulte o Capítulo 6.)
2.6.4 Monitorar e ajustar a atividade e o desempenho de BI
Uma prática recomendada para monitoramento e ajuste de BI é definir e exibir um conjunto de métricas de satisfação voltadas para o
cliente. O tempo médio de resposta à consulta e o número de usuários por dia, semana ou mês são exemplos de métricas úteis. Além
das medidas estatísticas disponíveis nos sistemas, é útil pesquisar regularmente os clientes de DW/BI.
A revisão regular das estatísticas e padrões de uso é essencial. Relatórios que fornecem frequência e uso de recursos de dados,
consultas e relatórios permitem um aprimoramento prudente. Ajustar a atividade de BI é análogo ao princípio de perfis de aplicativos
para saber onde estão os gargalos e onde aplicar os esforços de otimização. A criação de índices e agregações é mais eficaz quando
feita de acordo com padrões e estatísticas de uso.
Ganhos de desempenho enormes podem vir de soluções simples, como postar os resultados diários completos em um relatório que é
executado centenas ou milhares de vezes por dia.
Transparência e visibilidade são os princípios-chave que devem impulsionar o monitoramento de DW/BI. Quanto mais se puder expor
os detalhes das atividades de DW/BI, mais os consumidores de dados podem ver e entender o que está acontecendo (e ter confiança
no BI), e menos suporte direto ao cliente final será necessário. Fornecer um painel que exponha o status de alto nível das atividades
de entrega de dados, com capacidade de detalhamento, é uma prática recomendada que permite a extração de informações sob
demanda tanto pela equipe de suporte quanto pelos clientes.
A adição de medidas de qualidade de dados aumentará o valor desse painel onde o desempenho é mais do que apenas velocidade e
tempo. Use mapas de calor para visualizar a carga de trabalho na infraestrutura, taxa de transferência de dados e conformidade com
os níveis do contrato operacional.

402 • DMBOK2
3. Ferramentas
Escolher o conjunto inicial de ferramentas pode ser um processo longo. Inclui a tentativa de satisfazer requisitos de curto prazo,
especificações não funcionais e os requisitos de próxima geração ainda a serem criados. Conjuntos de ferramentas de critérios de
decisão, ferramentas de implementação de processos e ofertas de serviços profissionais podem facilitar e agilizar essa atividade. É
fundamental avaliar não apenas as posições convencionais de construção ou compra, mas também a opção de aluguel provisionada
como Software-as-a-Service. O aluguel de ferramentas SaaS e a experiência associada são avaliados em relação ao custo de
construção do zero ou implantação de produtos adquiridos de fornecedores. Considere também a atualização contínua e os custos
potenciais de substituição. O alinhamento a um OLA (Acordo de Nível Operacional) definido pode reduzir os custos previstos e fornecer
informações para definir taxas e penalidades convincentes para violações de prazos.
3.1 Repositório de Metadados
As grandes organizações geralmente se encontram com muitas ferramentas de diferentes fornecedores, cada uma implantada
potencialmente em diferentes versões. A chave para esse esforço é a capacidade de unir Metadados de várias fontes.
Automatizar e integrar a população deste repositório pode ser alcançado com uma variedade de técnicas. (Consulte o Capítulo 13.)
3.1.1 Dicionário de Dados / Glossário
Um dicionário de dados é necessário para suportar o uso de um DW. O dicionário descreve os dados em termos comerciais e inclui
outras informações necessárias para usar os dados (por exemplo, tipos de dados, detalhes de estrutura, restrições de segurança).
Muitas vezes, o conteúdo do dicionário de dados vem diretamente do modelo de dados lógico. Planeje Metadados de alta qualidade
garantindo que os modeladores adotem uma abordagem disciplinada para gerenciar definições como parte da modelagem
processo.
Em algumas organizações, os usuários de negócios participam ativamente do desenvolvimento do dicionário de dados fornecendo,
definindo e, em seguida, administrando correções nas definições dos elementos de dados da área de assunto. Abrace essa atividade
por meio de uma ferramenta de colaboração, monitore as atividades por meio de um Centro de Excelência e garanta que o conteúdo
criado por meio dessa atividade seja retido no modelo lógico. Garantir a concordância entre o conteúdo voltado para os negócios e o
modelo de dados físico voltado para o técnico reduzirá o risco de erros e retrabalho. (Consulte o Capítulo 13.)
3.1.2 Dados e Linhagem do Modelo de Dados
Muitas ferramentas de integração de dados oferecem análise de linhagem que considera tanto o código de população desenvolvido
quanto o modelo de dados físicos e o banco de dados. Alguns oferecem interfaces web para monitorar e atualizar definições e outros
metadados. A linhagem de dados documentada serve a muitos propósitos:
• Investigação das causas-raiz dos problemas de dados
• Análise de impacto para alterações do sistema ou problemas de dados
• Capacidade de determinar a confiabilidade dos dados, com base em sua origem
Procure implementar uma ferramenta integrada de impacto e linhagem que possa entender todas as partes móveis envolvidas no processo de
carregamento, bem como relatórios e análises do usuário final. Os relatórios de análise de impacto descreverão quais componentes são afetados por
uma possível mudança, agilizando e simplificando as tarefas de estimativa e manutenção.
Muitos processos, relacionamentos e terminologias de negócios importantes são capturados e explicados durante o desenvolvimento do modelo de
dados. O modelo de dados lógico contém muitas dessas informações, que geralmente são perdidas ou ignoradas durante o desenvolvimento ou
implantação de produção. É fundamental garantir que essas informações não sejam descartadas e que os modelos lógicos e físicos sejam atualizados
após a implantação e estejam sincronizados.
3.2 Ferramentas de Integração de Dados
As ferramentas de integração de dados são usadas para preencher um data warehouse. Além de fazer o trabalho de integração de dados, eles
permitem o agendamento de tarefas de forma a levar em conta a entrega de dados complexos de várias fontes. Ao selecionar uma ferramenta,
considere também estes recursos que permitem o gerenciamento do sistema:
• Auditoria de processos, controle, reinício e agendamento
• A capacidade de extrair seletivamente elementos de dados em tempo de execução e passar essa extração para um downstream
sistema para fins de auditoria
• Controlar quais operações podem ou não ser executadas e reiniciar uma execução com falha ou abortada (consulte o Capítulo
8)
Uma variedade de ferramentas de integração de dados também oferece recursos de integração com o portfólio de BI, suportando importação e
exportação de mensagens de fluxo de trabalho, e-mail ou até mesmo camadas semânticas. A integração do fluxo de trabalho pode impulsionar os
processos de identificação, resolução e escalação de defeitos de qualidade de dados. O envio de mensagens por e-mail ou o processamento de
alertas a partir de e-mail é uma prática comum, especialmente para dispositivos móveis. Além disso, a capacidade de provisionar um destino de dados
como uma camada semântica pode ser um candidato à virtualização de dados para implementações ágeis.
3.3 Tipos de Ferramentas de Business Intelligence
A maturidade do mercado de BI e uma ampla gama de ferramentas de BI disponíveis tornam raro que as empresas construam suas próprias
ferramentas de BI.68 O objetivo desta seção é apresentar os tipos de ferramentas disponíveis no mercado de BI e fornecer uma visão geral de suas
principais características com informações para ajudar a combinar as ferramentas com as
68
O material nesta seção é principalmente de “The Business Intelligence Market” por Cindi Howson, BIScorecard®,
http://bit.ly/2tNirv5; usado com permissão, com pequenas alterações e adições.
404 • DMBOK2
capacidades no nível do cliente. As ferramentas de BI estão evoluindo rapidamente, permitindo uma transição de relatórios padronizados conduzidos
por TI para exploração de dados de autoatendimento e orientada para negócios.69
• O relatório operacional é a aplicação de ferramentas de BI para analisar tendências de negócios, tanto de curto prazo
(mês a mês) e de longo prazo (ano a ano). Os relatórios operacionais também podem ajudar a descobrir
tendências e padrões. Use o BI Tático para dar suporte a decisões de negócios de curto prazo.
• Gestão de desempenho de negócios (BPM) inclui a avaliação formal de métricas alinhadas com
Objetivos organizacionais. Essa avaliação geralmente acontece no nível executivo. Use o BI estratégico para
apoiar metas e objetivos corporativos de longo prazo.
• A análise descritiva de autoatendimento fornece BI para as linhas de frente dos negócios, onde a análise
capacidades orientam as decisões operacionais. A análise operacional combina aplicativos de BI com
funções e processos, para orientar as decisões quase em tempo real. O requisito de baixa latência (próximo
captura de dados em tempo real e entrega de dados) conduzirá a abordagem arquitetônica para análise operacional
soluções. Arquitetura Orientada a Serviços (SOA) e Big Data tornam-se necessários para dar suporte operacional
totalmente analítica (ver Capítulos 8 e 15).
3.3.1 Relatório Operacional
O Relatório Operacional envolve usuários de negócios gerando relatórios diretamente de sistemas transacionais, aplicativos operacionais ou um data
warehouse. Isso geralmente é uma funcionalidade do aplicativo. Muitas vezes, as áreas de negócios começarão a usar um DW para relatórios
operacionais, especialmente se a governança de DW/BI for ruim ou se o DW contiver dados adicionais que aprimoram os dados operacionais e de
transação. Muitas vezes, os relatórios aparecem como consultas ad-hoc, quando na verdade são relatórios simples ou são usados para iniciar o fluxo
de trabalho. Do ponto de vista do gerenciamento de dados, a chave é entender se os dados necessários para esse relatório existem no próprio aplicativo
ou se exigem aprimoramentos de dados do DW ou armazenamento de dados operacionais.
As ferramentas de exploração de dados e relatórios, às vezes chamadas de ferramentas de consulta ad-hoc, permitem que os usuários criem seus
próprios relatórios ou criem saídas para uso por outros. Eles estão menos preocupados com o layout preciso porque não estão tentando gerar uma
fatura ou algo semelhante. No entanto, eles querem incluir gráficos e tabelas de forma rápida e intuitiva. Muitas vezes, os relatórios criados pelos
usuários empresariais tornam-se relatórios padrão, não usados exclusivamente para questões comerciais ad hoc.
As necessidades dos relatórios de operações de negócios geralmente são diferentes das necessidades de consulta e relatórios de negócios. Com
consultas e relatórios de negócios, a fonte de dados geralmente é um data warehouse ou data mart (embora nem sempre). Enquanto a TI desenvolve
relatórios de produção, usuários avançados e usuários de negócios ad hoc desenvolvem seus próprios relatórios com ferramentas de consulta de
negócios. Use relatórios gerados com ferramentas de consulta de negócios individualmente, por departamento ou em toda a empresa.
69 Dataversity se refere a essa tendência como a “democratização das tecnologias de dados”. Ver Ghosh, Paramita. “Um estudo
comparativo de tendências de mercado de inteligência de negócios e análise”. Dataversidade. 17 de janeiro de 2017. http://bit.ly/
2sTgXTJ (acessado em 22-01-2017).
Os relatórios de produção ultrapassam os limites do DW/BI e frequentemente consultam os sistemas transacionais para produzir
itens operacionais, como faturas ou extratos bancários. Os desenvolvedores de relatórios de produção tendem a ser o pessoal de TI.
As ferramentas tradicionais de BI abrangem alguns métodos de visualização de dados, como tabelas, gráficos de pizza, gráficos de
linhas, gráficos de área, gráficos de barras, histogramas, caixa pronta para uso (candlestick) como exemplos. As visualizações de
dados podem ser entregues em um formato estático, como um relatório publicado, ou um formato online mais interativo; e alguns
suportam a interação do usuário final, onde os recursos de perfuração ou filtragem facilitam a análise de dados na visualização.
Outros permitem que a visualização seja alterada pelo usuário sob demanda. (Consulte o Capítulo 14.)
3.3.2 Gestão de Desempenho de Negócios
A gestão de desempenho é um conjunto de processos e aplicativos organizacionais integrados projetados para otimizar a execução
da estratégia de negócios; aplicações incluem orçamento, planejamento e consolidação financeira. Houve várias aquisições
importantes neste segmento, pois fornecedores de ERP e fornecedores de BI veem grandes oportunidades de crescimento aqui e
acreditam que BI e Gestão de Desempenho estão convergindo. A frequência com que os clientes compram BI e gerenciamento de
desempenho do mesmo fornecedor depende dos recursos do produto.
De um modo geral, a tecnologia de Gestão de Desempenho permite que os processos ajudem a atingir as metas organizacionais.
A medição e um ciclo de feedback com reforço positivo são elementos-chave. No espaço de BI, isso assumiu a forma de muitos
aplicativos empresariais estratégicos, como orçamento, previsão ou planejamento de recursos.
Outra especialização se formou nessa área: a criação de scorecards orientados por painéis para interação do usuário.
Dashboards, como os encontrados em automóveis, fornecem o resumo necessário ou agregam informações ao usuário final com as
atualizações mais recentes (Eckerson, 2005).
3.3.3 Aplicativos analíticos operacionais
Henry Morris da IDC cunhou o termo Analytic Applications na década de 1990, esclarecendo como elas são diferentes das
ferramentas gerais de OLAP e BI (Morris, 1999). Os aplicativos analíticos incluem a lógica e os processos para extrair dados de
sistemas de origem conhecidos, como sistemas ERP de fornecedores, um modelo de dados para o data mart e relatórios e painéis
pré-criados. Eles fornecem às empresas uma solução pré-construída para otimizar uma área funcional (gestão de pessoas, por
exemplo) ou vertical do setor (análise de varejo, por exemplo). Diferentes tipos de aplicativos analíticos incluem aplicativos de
clientes, financeiros, de cadeia de suprimentos, manufatura e recursos humanos.
3.3.3.1 Análise Multidimensional – OLAP
O Processamento Analítico Online (OLAP) refere-se a uma abordagem para fornecer desempenho rápido para consultas analíticas
multidimensionais. O termo OLAP originou-se, em parte, para fazer uma clara distinção de OLTP, Online Transactional Processing.
A saída típica de consultas OLAP está em um formato de matriz. As dimensões formam as linhas e colunas da matriz, e os fatores,
ou medidas, são os valores dentro da matriz.
406 • DMBOK2
Conceitualmente, isso ilustra como um cubo. A análise multidimensional com cubos é particularmente útil onde há maneiras bem conhecidas
de os analistas desejarem examinar resumos de dados.
Uma aplicação tradicional é a análise financeira, na qual os analistas desejam percorrer repetidamente hierarquias conhecidas para analisar
dados; por exemplo, data (como Ano, Trimestre, Mês, Semana, Dia), organização (como Região, País, Unidade de Negócios, Departamento)
e hierarquia do produto (como Categoria de Produto, Linha de Produto, Produto).
Muitas ferramentas hoje incorporam cubos OLAP em seu espaço de software e algumas até automatizam e integram perfeitamente o
processo de definição e preenchimento. Isso significa que qualquer usuário em qualquer processo de negócios pode dividir seus dados.
Alinhe esse recurso com os usuários avançados nas comunidades da área de assunto e entregue-o por meio de um canal de autoatendimento,
capacitando esses usuários selecionados a analisar seus dados à sua maneira.
Normalmente, as ferramentas OLAP têm um componente de servidor e um componente voltado para o cliente do usuário final instalado na
área de trabalho ou disponível na web. Alguns componentes da área de trabalho são acessíveis a partir de uma planilha que aparece como
um menu incorporado ou item de função. A arquitetura selecionada (ROLAP, MOLAP, HOLAP) guiará os esforços de desenvolvimento, mas
comum a todos será a definição da estrutura do cubo, necessidades agregadas, aumento de metadados e análise de dados esparsos.
Estruturar o cubo para fornecer os requisitos funcionais desejados pode exigir a divisão de dimensões maiores em cubos separados para
acomodar requisitos de armazenamento, população ou cálculo. Use níveis de agregação para garantir que o cálculo e a recuperação das
fórmulas desejadas ocorram dentro dos tempos de resposta acordados. O aumento de hierarquias do usuário final permite atender aos
requisitos de agregação, cálculo ou população. Além disso, a escassez de dados do cubo pode exigir a adição ou remoção de estruturas
agregadas ou refinar as necessidades de materialização na camada de dados do warehouse que o provisiona.
O provisionamento de segurança baseada em função ou texto multilíngue no cubo pode exigir dimensões extras, funções adicionais, cálculos
ou, às vezes, a criação de estruturas de cubo separadas. Encontrar um equilíbrio entre flexibilidade do usuário final, desempenho e cargas
de trabalho do servidor significa que alguma negociação é esperada. A negociação geralmente ocorre durante os processos de carregamento
e pode exigir alterações de hierarquia, alterações de estrutura agregada ou objetos de dados materializados de armazém adicionais. Encontre
o equilíbrio certo entre contagem de cubos, carga de trabalho do servidor e flexibilidade fornecida, para que a atualização ocorra em tempo
hábil e os cubos forneçam consultas confiáveis e consistentes sem altos custos de armazenamento ou utilização do servidor.
O valor das ferramentas e cubos de Processamento Analítico On Line (OLAP) é a redução da chance de confusão e interpretação errônea,
alinhando o conteúdo dos dados com o modelo mental do analista. O analista pode navegar pelo banco de dados e filtrar um determinado
subconjunto de dados, alterando a orientação dos dados e definindo cálculos analíticos. Slice-and-dice é o processo de navegação iniciado
pelo usuário chamando para exibições de página de forma interativa, através da especificação de fatias por meio de rotações e drill down/
up. As operações OLAP comuns incluem slice and dice, drill down, drill up, roll up e pivot.
• Fatia: Uma fatia é um subconjunto de uma matriz multidimensional correspondente a um único valor para um ou mais
membros das dimensões que não estão no subconjunto.
• Dados: A operação de dados é uma fatia em mais de duas dimensões de um cubo de dados, ou mais de duas
fatias consecutivas.
• Drill down/up: Drill down ou up é uma técnica analítica específica pela qual o usuário navega
entre os níveis de dados, desde o mais resumido (para cima) até o mais detalhado (para baixo).
• Roll-up: Um roll-up envolve o cálculo de todos os relacionamentos de dados para uma ou mais dimensões. Façam
isso, defina uma relação ou fórmula computacional.
• Pivô: Um pivô altera a orientação dimensional de um relatório ou exibição de página.
Três abordagens de implementação clássicas dão suporte ao processamento analítico online.
• Processamento Analítico Online Relacional (ROLAP): ROLAP suporta OLAP usando técnicas
que implementam a multidimensionalidade nas tabelas bidimensionais de gerenciamento de banco de dados relacional
sistemas (RDBMS). As junções de esquema em estrela são uma técnica comum de design de banco de dados usada no ROLAP
ambientes.
• Processamento analítico online multidimensional (MOLAP): MOLAP suporta OLAP usando
tecnologia de banco de dados multidimensional proprietária e especializada.
• Processamento analítico online híbrido (HOLAP): Isso é simplesmente uma combinação de ROLAP e
MOLAP. As implementações de HOLAP permitem que parte dos dados seja armazenada em formato MOLAP e outra
parte dos dados a serem armazenados no ROLAP. As implementações variam no controle que um projetista tem para variar o
mistura de particionamento.
4. Técnicas
4.1 Protótipos para conduzir os requisitos
Priorize rapidamente os requisitos antes que as atividades de implementação comecem, criando um conjunto de dados de demonstração
e aplicando etapas de descoberta em um esforço conjunto de protótipo. Os avanços nas tecnologias de virtualização de dados podem
aliviar algumas das dores de implementação tradicionais por meio de técnicas de prototipagem colaborativa.
A criação de perfil dos dados contribui para a prototipagem e ajuda a reduzir o risco associado a dados inesperados. O DW é
frequentemente o primeiro lugar onde a dor de dados de baixa qualidade em sistemas de origem ou funções de entrada de dados se torna
aparente. A criação de perfis também revela diferenças entre as fontes que podem apresentar obstáculos à integração de dados.
Os dados podem ser de alta qualidade dentro de suas fontes, mas como as fontes diferem, o processo de integração de dados se torna
mais complicado.
A avaliação do estado dos dados de origem leva a estimativas iniciais mais precisas para viabilidade e escopo do esforço. A avaliação
também é importante para definir as expectativas adequadas. Planeje colaborar com a(s) equipe(s) de Qualidade de Dados e Governança
de Dados e aproveitar a experiência de outras PMEs para entender discrepâncias e riscos de dados. (Consulte os Capítulos 11 e 13.)
408 • DMBOK2
4.2 BI de autoatendimento
O autoatendimento é um canal de entrega fundamental dentro do portfólio de BI. Isso normalmente afunila a atividade do usuário em um
portal governado onde, dependendo dos privilégios do usuário, uma variedade de funcionalidades é fornecida, desde mensagens, alertas,
visualização de relatórios de produção programados, interação com relatórios analíticos, desenvolvimento de relatórios ad hoc e, claro, painel
de controle e cartão de pontuação. Os relatórios podem ser enviados para o portal em horários padrão, para serem recuperados pelos
usuários quando quiserem. Os usuários também podem extrair dados executando relatórios de dentro do portal. Esses portais compartilham
conteúdo além das fronteiras organizacionais.
Estender a ferramenta de colaboração para a comunidade de usuários também pode fornecer dicas e truques de autoatendimento, um
comunicado integrado sobre status de carregamento, desempenho geral e progresso de lançamento, bem como fóruns de diálogo. Mediar o
conteúdo do fórum por meio do canal de suporte e, em seguida, facilitar as sessões do grupo de usuários por meio
o canal de manutenção.
As ferramentas de visualização e análise estatística permitem a exploração e descoberta rápidas de dados. Algumas ferramentas permitem
a construção centrada nos negócios de painéis como objetos que podem ser rapidamente compartilhados, revisados e revitalizados.
Outrora domínio apenas da TI e dos desenvolvedores, muitas técnicas de modelagem, cálculo e visualização de dados agora podem ser
empregadas pela comunidade empresarial. Isso oferece um grau de distribuição de carga de trabalho e os esforços de integração podem ser
prototipados de forma viável por meio de canais de negócios e, em seguida, materializados e otimizados pela TI.
4.3 Dados de auditoria que podem ser consultados
Para manter a linhagem, todas as estruturas e processos devem ter a capacidade de criar e armazenar informações de auditoria em uma
granularidade útil para rastreamento e relatórios. Permitir que os usuários consultem esses dados de auditoria permite que os usuários
verifiquem por si mesmos a condição e a chegada dos dados, o que aumenta a confiança do usuário. As informações de auditoria também
permitem uma solução de problemas mais detalhada quando surgem problemas de dados.
Uma arquitetura estável que possa ser dimensionada para atender a requisitos futuros é fundamental para o sucesso de um data warehouse.
Uma equipe de suporte à produção capaz de lidar com o carregamento diário, análise e feedback do usuário final é obrigatória. Além disso,
para sustentar o sucesso, assegure-se de que as equipes do armazém e da unidade de negócios estejam alinhadas.
Pode haver uma lacuna entre quando uma organização adota um novo empreendimento e quando ela tem a capacidade de sustentar esse
empreendimento. Projetos bem-sucedidos começam com uma lista de verificação de pré-requisitos. Todos os projetos de TI devem ter
suporte de negócios, estar alinhados com a estratégia e ter uma abordagem de arquitetura definida. Além disso, um DW deve:
• Defina a sensibilidade dos dados e as restrições de segurança
• Realize a seleção da ferramenta
• Recursos seguros
• Crie um processo de ingestão para avaliar e receber dados de origem
Identifique e faça um inventário de elementos de dados confidenciais ou restritos no warehouse. Esses dados precisarão ser mascarados ou
ofuscados para impedir o acesso de pessoal não autorizado. Restrições adicionais podem ser aplicadas ao considerar a terceirização para
atividades de implementação ou manutenção.
Considere as restrições de segurança antes de selecionar ferramentas e atribuir recursos. Garantir que os processos de governança de dados
para revisão e aprovação tenham sido seguidos. Os projetos de DW/BI correm o risco de reorientação ou cancelamento total devido a esses
fatores abrangentes.
5.2 Roteiro de lançamento
Por exigirem um grande esforço de desenvolvimento, os armazéns são construídos de forma incremental. Seja qual for o método escolhido
para implementar, seja em cascata, iterativo ou ágil, ele deve levar em conta o estado final desejado. É por isso que um roteiro é uma
ferramenta de planejamento valiosa. O método combinado com os processos de manutenção pode ser flexível e adaptável para equilibrar as
pressões da entrega do projeto individual com os objetivos gerais de dados reutilizáveis e

a infraestrutura.
Sugere-se uma abordagem incremental aproveitando a matriz de barramento DW como ferramenta de comunicação e marketing.
Use prioridades determinadas pelo negócio vinculadas por métricas de exposição para determinar quanto rigor e sobrecarga devem ser
aplicados a cada incremento; uma pequena entrega de fonte única pode permitir o relaxamento das regras, especialmente quando a exposição
limitada é sentida, caso esses problemas sejam percebidos pela organização.
Cada incremento modificará os recursos existentes ou adicionará novos recursos normalmente alinhados com uma unidade de negócios recém-
integrada. Aplique um processo consistente de necessidades e habilidades para determinar a próxima unidade de negócios a ser integrada.
Mantenha uma lista de pedidos pendentes ou de itens de trabalho para identificar recursos pendentes e as prioridades voltadas para os
negócios. Determine quaisquer dependências técnicas que exijam entrega em um pedido diferente. Em seguida, empacote esse trabalho em
uma versão de software. Cada versão pode ser entregue em um ritmo acordado: trimestralmente, mensalmente, semanalmente ou até mais
rápido, quando apropriado. Gerencie os lançamentos com os parceiros de negócios montando um roteiro: uma listagem de lançamentos por
data por capacidades.
5.3 Gerenciamento de configuração
O gerenciamento de configuração se alinha com o roteiro de lançamento e fornece a costura e os scripts de back office necessários para
automatizar o desenvolvimento, o teste e o transporte para a produção. Ele também marca o modelo pelo lançamento no nível do banco de
dados e vincula a base de código a essa marca de maneira automatizada para que manualmente
410 • DMBOK2
programas codificados e gerados e o conteúdo da camada semântica são harmonizados em todo o ambiente e são versionados
controlada.
Começar e manter um foco de negócios consistente durante todo o ciclo de vida do DW/BI é essencial para o sucesso.
Observar a cadeia de valor da empresa é uma boa maneira de entender o contexto do negócio. Os processos de negócios específicos na
cadeia de valor de uma empresa fornecem um contexto natural orientado aos negócios para enquadrar as áreas de análise.
Mais importante ainda, alinhe os projetos com as necessidades reais de negócios e avalie o suporte de negócios necessário, considerando
estes fatores críticos de sucesso:
• Patrocínio de negócios: Existe um patrocínio executivo apropriado, ou seja, um patrocinador identificado e engajado
comitê diretivo e financiamento proporcional? Projetos DW/BI exigem forte patrocínio executivo.
• Objetivos e escopo de negócios: Existe uma necessidade, propósito e escopo de negócios claramente identificados para o
esforço?
• Recursos empresariais: Existe um compromisso da gestão empresarial com a disponibilidade e
contratação dos especialistas apropriados no assunto do negócio? A falta de compromisso é comum
ponto de falha e uma razão suficiente para interromper um projeto de DW/BI até que o compromisso seja confirmado.
• Prontidão de negócios: O parceiro de negócios está preparado para uma entrega incremental de longo prazo? Eles têm
comprometeram-se a estabelecer centros de excelência para sustentar o produto em lançamentos futuros?
Quão amplo é o conhecimento médio ou lacuna de habilidades dentro da comunidade-alvo e isso pode ser cruzado
dentro de um único incremento?
• Alinhamento de visão: quão bem a Estratégia de TI suporta a Visão de Negócios? É fundamental garantir
que os requisitos funcionais desejados correspondem às capacidades de negócios que são ou podem ser sustentadas em
o roteiro de TI imediato. Quaisquer desvios significativos ou lacunas materiais no alinhamento de capacidades podem
travar ou parar um programa DW/BI.
5.4.1 Equipe Dedicada
Muitas organizações têm uma equipe dedicada para gerenciar as operações contínuas do ambiente de produção.
(Ver Capítulo 6). Um conjunto separado de mãos operando o produto de dados entregue é benéfico para a otimização da carga de
trabalho, pois esse grupo tem tarefas repetidas em um ciclo de calendário e pode ser usado para qualquer item de escalonamento,
enquanto o canal de manutenção verá picos de carga de trabalho alinhados a entregas específicas.
Um grupo de suporte de front office interage com a equipe de manutenção para promover relacionamentos entre departamentos e garantir
que as atividades críticas sejam abordadas nas próximas versões. Ele notifica a equipe de quaisquer deficiências a serem
abordado. Uma equipe de suporte de back office nas operações garantirá que a configuração de produção seja executada conforme
necessário. Eles escalarão alertas e relatarão o status da taxa de transferência.
6. Governança DW/BI
Os setores altamente regulamentados e que precisam de relatórios centrados em conformidade se beneficiarão muito de um data warehouse
bem governado. Fundamental para o suporte contínuo e vital para o planejamento de liberação é garantir que as atividades de governança
sejam concluídas e abordadas durante a implementação. Mais e mais organizações estão estendendo seu Ciclo de Vida de Desenvolvimento
de Software com entregas específicas destinadas a atender às necessidades de governança.
Os processos de governança de armazém devem estar alinhados com o gerenciamento de riscos. Eles devem ser orientados para os
negócios, uma vez que diferentes tipos de negócios têm necessidades diferentes (por exemplo, empresas de marketing e publicidade usarão
seus dados de forma diferente das instituições financeiras). Os processos de governança devem mitigar o risco, não reduzir
execução.
As funções mais críticas são aquelas que governam a área de descoberta ou refinamento operada pelo negócio e aquelas que garantem a
qualidade impecável dentro do próprio armazém. Como a área de refinamento lidera todos os limites da iniciativa, procedimentos de
handshaking e bom funcionamento são necessários para instanciar, operar, transferir e descartar os dados nessas áreas. O arquivamento de
dados e os horizontes de tempo são elementos-chave nos acordos de limite, pois ajudam a evitar a expansão. O monitoramento desses
ambientes e agendamentos para determinar os prazos de longevidade estão incluídos nas sessões do grupo de usuários, bem como nas
reuniões de gerenciamento. Carregar dados no warehouse significa atribuir tempo, recursos e esforços de programação para ver dados
corrigidos, confiáveis e de alta qualidade chegarem à comunidade de usuários finais, em tempo hábil, é claro.
Considere eventos únicos ou de uso limitado como parte do ciclo de vida e talvez reduza-os na própria área piloto ou em uma área 'sandbox'
controlada pelo usuário. Os processos de análise em tempo real podem alimentar os resultados agregados alinhados ao tempo de volta ao
data warehouse por meio de um processo automatizado. A política é definida para os procedimentos decretados no ambiente de tempo real,
e a governança se aplica à intermediação dos resultados no warehouse para consumo organizacional.
Aplique a discriminação de dados a itens conhecidos ou catalogados gerenciados por meio de uma matriz de mitigação de exposição a riscos.
Esses itens com uma exposição considerada alta e baixa mitigação ou detecção precoce difícil garantem funções de governança para reduzir
o risco associado. Dependendo da sensibilidade dos dados examinados, um espaço de trabalho separado para o pessoal local selecionado
também pode ser necessário. Uma revisão completa com a segurança corporativa e o pessoal jurídico durante a formação da política cria uma
rede de segurança final.
6.1 Habilitando a Aceitação Comercial
Um fator-chave de sucesso é a aceitação dos dados pelos negócios, incluindo a compreensão dos dados, a qualidade verificável e uma
linhagem demonstrável. A aprovação da Empresa nos dados deve fazer parte do Teste de Aceitação do Usuário. Realize testes aleatórios
estruturados dos dados na ferramenta de BI em relação aos dados na origem

412 • DMBOK2
sistemas durante o carregamento inicial e após alguns ciclos de carregamento de atualização, para atender aos critérios de aprovação. Atender
a esses requisitos é fundamental para cada implementação de DW/BI. Considere, de antemão, alguns subcomponentes de arquitetura
criticamente importantes, juntamente com suas atividades de suporte:
• Modelo de Dados Conceituais: Quais informações são essenciais para a organização? Quais são os principais negócios
conceitos e como eles se relacionam?
• Ciclo de feedback de qualidade de dados: como os problemas de dados são identificados e corrigidos? Como são os donos do
sistemas nos quais os problemas se originam informados sobre os problemas e responsabilizados por corrigi-los?
Qual é o processo de correção para problemas causados pelos processos de integração de dados do DW?
• Metadados de ponta a ponta: como a arquitetura suporta o fluxo integrado de metadados de ponta a ponta?
Em particular, o acesso ao significado e ao contexto é projetado na arquitetura? Como os consumidores de dados
responder a perguntas básicas como "O que este relatório significa?" ou "O que essa métrica significa?"
• Linhagem de dados verificável de ponta a ponta: os itens expostos aos usuários de negócios são rastreáveis até a origem ?
sistemas de forma automatizada e mantida? Existe um sistema de registro identificado para todos os dados?
6.2 Satisfação do Cliente/Usuário
As percepções da qualidade dos dados conduzirão à satisfação do cliente, mas a satisfação também depende de outros fatores, como a
compreensão dos dados pelos consumidores de dados e a capacidade de resposta da equipe de operações aos problemas identificados.
Coletar, entender e agir de acordo com o feedback do cliente pode ser facilitado por meio de reuniões agendadas regularmente com
representantes de usuários. Essa interação também pode ajudar a equipe do warehouse a compartilhar informações sobre o roteiro de
lançamento e entender como os consumidores de dados estão usando o warehouse.
6.3 Acordos de Nível de Serviço
As expectativas comerciais e técnicas para os ambientes devem ser especificadas nos Acordos de Nível de Serviço (SLAs). Muitas vezes, os
requisitos de tempo de resposta, retenção de dados e disponibilidade diferem muito entre as classes de necessidades de negócios e seus
respectivos sistemas de suporte (por exemplo, ODS versus DW versus data mart).
6.4 Estratégia de Relatório
Certifique-se de que existe uma estratégia de geração de relatórios dentro e em todo o Portfólio de BI. Uma estratégia de relatórios inclui
padrões, processos, diretrizes, melhores práticas e procedimentos. Isso garantirá que os usuários tenham informações claras, precisas e
oportunas. A estratégia de relatórios deve abordar
• Acesso de segurança para garantir que apenas usuários autorizados tenham acesso a elementos de dados confidenciais
• Mecanismos de acesso para descrever como os usuários desejam interagir, relatar, examinar ou visualizar seus dados
• Tipo de comunidade de usuários e ferramenta apropriada para consumi-lo com
• Natureza do resumo dos relatórios, detalhado, exceção, bem como frequência, tempo, distribuição e
formatos de armazenamento
• Uso potencial de recursos de visualização para fornecer saída gráfica
• Trade-offs entre pontualidade e desempenho
Os relatórios padrão devem ser avaliados periodicamente para garantir que ainda forneçam valor, pois apenas a execução de relatórios
incorre em custos de armazenamento e processamento. Os processos de implementação e manutenção e as atividades de gerenciamento
são críticos. Alinhar as ferramentas de relatórios apropriadas à comunidade empresarial é um fator crítico de sucesso. Dependendo do
tamanho e da natureza da organização, provavelmente há muitas ferramentas de relatórios diferentes usadas em diversos processos.
Garantir que o público seja capaz de fazer o melhor uso das ferramentas de relatórios; usuários mais sofisticados terão demandas cada
vez mais complexas. Mantenha uma matriz de decisão com base nessas demandas para determinar atualizações ou seleção de
ferramentas futuras.
O monitoramento e o controle da governança da fonte de dados também são vitais. Garantir que os níveis apropriados de dados sejam
provisionados com segurança para o pessoal autorizado e que os dados de assinatura estejam acessíveis de acordo com o acordado
níveis.
Um Centro de Excelência pode fornecer treinamento, conjuntos de inicialização, práticas recomendadas de design, dicas e truques de
fonte de dados e outras soluções ou artefatos pontuais para ajudar a capacitar os usuários de negócios para um modelo de autoatendimento.
Além do gerenciamento de conhecimento, esse centro pode fornecer comunicações oportunas entre as comunidades de desenvolvedores,
designers, analistas e usuários assinantes.
6.5 Métricas
6.5.1 Métricas de Uso
As métricas de uso do DW normalmente incluem o número de usuários registrados, bem como usuários conectados ou usuários conectados
simultaneamente. Essas métricas mostram quantas pessoas na organização estão usando o data warehouse.
Quantas contas de usuário são licenciadas para cada ferramenta é um ótimo começo, especialmente para os auditores. No entanto,
quantas consultas realmente se conectam a essa ferramenta é uma medida melhor, e quantas consultas (ou equivalentes de consulta) são
enviadas por uma comunidade de usuários por período de tempo é uma medida técnica ainda melhor, especialmente para planejamento
de capacidade. Permitir várias métricas de análise, como usuários de auditoria, capacidade de consulta do usuário gerada e consumo
usuários.
6.5.2 Porcentagens de Cobertura da Área de Assunto
As porcentagens de cobertura da área de assunto medem quanto do warehouse (de uma perspectiva de topologia de dados) está sendo
acessado por cada departamento. Eles também destacam quais dados são compartilhados entre departamentos e quais não são, mas
poderiam ser.
414 • DMBOK2
O mapeamento de fontes operacionais para destinos é outra extensão natural, que reforça e valida a linhagem e os metadados já coletados e
pode fornecer análise de penetração para quais sistemas de origem estão em uso analítico por quais departamentos. Isso pode ajudar a
concentrar os esforços de ajuste nessas consultas analíticas de alto impacto, mitigando quaisquer alterações em objetos de origem muito
usados.
6.5.3 Métricas de Resposta e Desempenho
A maioria das ferramentas de consulta mede o tempo de resposta. Recupere as métricas de resposta ou desempenho das ferramentas. Esses
dados informarão métricas sobre o número e o tipo de usuários.
Colete os tempos de carregamento para cada produto de dados em formato bruto dos processos de preenchimento. Eles também devem ser
expressos como uma porcentagem do suporte esperado: portanto, um mart que deve ser atualizado diariamente e carregado em uma janela
de quatro horas tem 100% de suporte quando é carregado em quatro horas. Aplique esse processo também a quaisquer extrações geradas
para processamento downstream.
A maioria das ferramentas retém, em um log ou repositório, registros de consulta, atualização de dados e tempos de extração de dados para
os objetos fornecidos aos usuários. Divida esses dados em objetos programados e executados e expresse como contagens brutas tentadas e
bem-sucedidas. Objetos altamente populares ou consultas com desempenho insatisfatório provavelmente precisam de atenção antes que as
métricas de satisfação sofram. Isso pode orientar a análise de defeitos, planejamento de manutenção, bem como planejamento de capacidade
se um grupo de objetos estiver falhando regularmente. A correção pode variar dependendo da ferramenta, mas às vezes criar ou eliminar um
índice pode resultar em grandes melhorias. (Consulte o Capítulo 6.)
Um seguimento natural para isso é a validação e ajuste dos níveis de serviço. Ajuste os itens que falharam consistentemente na próxima
versão, ou na ausência de financiamento necessário, o nível de suporte deve ser reduzido.

Adamson, Christopher. Dominando Agregados de Data Warehouse: Soluções para Desempenho de Esquema Star. John Wiley e
Filhos, 2006. Impresso.
Adelman, Sid e Larissa T. Moss. Gerenciamento de Projetos de Data Warehouse. Addison-Wesley Professional, 2000. Impressão.
Adelman, Sid, et ai. Situações impossíveis de data warehouse: soluções dos especialistas. Addison-Wesley, 2002. Imprimir.
AGGARWAL, Charu. Mineração de dados: o livro didático. Springer, 2015. Impresso.
Bier, Mike. Inteligência de Negócios para a Empresa. IBM Press, 2003. Imprimir.
Bier, Mike. A Nova Era da Inteligência Empresarial Empresarial: Usando Analytics para Alcançar uma Vantagem Competitiva Global.
IBM Press, 2010. Imprimir. Imprensa IBM.
Brown, Meta S. Mineração de Dados para Leigos. Para Leigos, 2014. Imprimir. Para Leigos.
Chorianpoulos, Antonios. CRM eficaz usando análise preditiva. Wiley, 2016. Impresso.
Delmater, Rhonda e Monte Hancock Jr. Mineração de dados explicada; Um guia do gerente para inteligência de negócios centrada no cliente. Imprensa
Digital, 2001. Impressão.
Dyche, Jill. E-Data: Transformando Dados em Informações Com Data Warehousing. Addison-Wesley, 2000. Print.
Eckerson, Wayne W. Painéis de desempenho: Medindo, monitorando e gerenciando seus negócios. Wiley, 2005. Impresso.
Han, Jiawei, Micheline Cumber e Jian Pei. Mineração de Dados: Conceitos e Técnicas. 3ª edição. Morgan Kaufmann, 2011.
Imprimir. O Morgan Kaufmann Ser em Sistemas de Gerenciamento de Dados.
Hastie, Trevor, Robert Tibshirani e Jerome Friedman. Os Elementos da Aprendizagem Estatística: Mineração de Dados, Inferência e Previsão. 2ª edição.
Springer, 2011. Impresso. Série Springer em Estatística.
Hill, Thomas e Paul Lewicki. Estatística: Métodos e Aplicações. Statsoft, Inc., 2005. Imprimir.
Howson, Cindi. Business Intelligence de sucesso: desbloqueie o valor do BI e do Big Data. 2ª edição. Mcgraw-Hill Osborne Media, 2013. Impresso.
Imhoff, Claudia, Lisa Loftis e Jonathan G. Geiger. Construindo a Empresa Centrada no Cliente: Técnicas de Data Warehousing para Apoio ao
Gerenciamento do Relacionamento com o Cliente. John Wiley and Sons, 2001. Imprimir.
Imhoff, Claudia, Nicholas Galemmo, and Jonathan G. Geiger. Dominando o Projeto de Data Warehouse: Técnicas Relacionais e Dimensionais.
John Wiley and Sons, 2003. Imprimir.
Inmon, WH, Claudia Imhoff, and Ryan Sousa. A Fábrica de Informações Corporativas. 2ª edição. John Wiley e Filhos, 2000.
Imprimir.
Inmon, WH e Krish Krishnan. Construindo o Data Warehouse Não Estruturado. Technics Publications, LLC., 2011. Impresso.
Josey, André. TOGAF Versão 9.1 Enterprise Edition: Uma Introdução. O Grupo Aberto, 2011. Kindle. Livro Branco do Grupo Aberto.
Kaplan, Robert S e David P. Norton. O Balanced Scorecard: Traduzindo Estratégia em Ação. Harvard Business Review Press, 1996. Kindle.
Kimball, Ralph e Margy Ross. O Kit de Ferramentas do Data Warehouse: O Guia Definitivo para Modelagem Dimensional. 3d edição.
Kimball, Ralph, et ai. O Kit de Ferramentas do Ciclo de Vida do Data Warehouse. 2ª edição. Wiley, 2008. Impresso.
Kimball, Ralph. O Data Warehouse ETL Toolkit: Técnicas Práticas para Extrair, Limpar, Conformar e Entregar Dados. Amazon Digital Services, Inc.,
2007. Kindle.
Linoff, Gordon S. e Michael JA Berry. Técnicas de mineração de dados: para marketing, vendas e gerenciamento de relacionamento com o cliente. 3ª
edição. Wiley, 2011. Impresso.
Linstedt, Dan. O Documento Oficial de Padrões do Data Vault (Versão 1.0) (Arquitetura de Data Warehouse). Amazon Digital Services, Inc., 2012. Kindle.
LOUKIDES, Mike. O que é Ciência de Dados? O'Reilly Media, 2012. Kindle.
Lublinsky, Boris, Kevin T. Smith e Alexey Yakubovich. Soluções Profissionais Hadoop. Wrox, 2013. Impresso.
Malik, Shadan. Enterprise Dashboards: Design e melhores práticas para TI. Wiley, 2005. Impresso.
MORIS, Henrique. “Aplicativos analíticos e gerenciamento de desempenho de negócios”. Revista DM Review, março de 1999. http://bit.ly/2rRrP4x.
Moss, Larissa T., e Shaku Atre. Roteiro de Business Intelligence: O Ciclo de Vida Completo do Projeto para Aplicativos de Suporte à Decisão. Addison-
Wesley Professional, 2003. Impressão.
416 • DMBOK2
Poniah, Paulraj. Fundamentos de armazenamento de dados: um guia abrangente para profissionais de TI. Wiley-Interscience, 2001.
Imprimir.
Reitor, Foster e Tom Fawcett. Data Science for Business: O que você precisa saber sobre mineração de dados e pensamento analítico de
dados. O'Reilly Media, 2013. Impresso.
Reeves, Laura L. Um Guia do Gerente para Data Warehousing. Wiley, 2009. Impresso.
Russell, Matthew A. Mineração da Web Social: Mineração de Dados Facebook, Twitter, LinkedIn, Google+, GitHub e muito mais. 2ª edição.
O'Reilly Media, 2013. Impresso.
Silverston, Len e Paul Agnew. O Livro de Recursos de Modelo de Dados Volume 3: Padrões Universais para Modelagem de Dados. Wiley,
2008. Impresso.
Simão, Alan. Inteligência empresarial moderna e gerenciamento de dados: um roteiro para diretores, gerentes e arquitetos de TI. Morgan
Kaufmann, 2014. Impresso.
Thomsen, Erik. Soluções OLAP: Construindo Sistemas de Informação Multidimensionais. 2ª edição. Wiley, 2002. Impresso.
Vitt, Elizabeth, Michael Luckevich e Stacia Misner. Inteligência de Negócios. Microsoft Press, 2008. Imprimir. Referência do
desenvolvedor.
WAGmob. Big Data e Hadoop. WAGmob, 2013. Kindle.
Wremble, Robert e Christian Koncilia. Data Warehouses e Olap: Conceitos, Arquiteturas e Soluções. IGI Global, 2006. Impresso.
CAPÍTULO 1 2
Dados
Modelagem de dados
Qualidade dos dados
& Operações
Metadados
Dados Dados

Inteligência
& Mestre & Contente
Dados Gestão
1. Introdução
T
A definição mais comum de Metadados, “dados sobre dados”, é enganosamente simples. O tipo de
as informações que podem ser classificadas como Metadados são amplas. Os metadados incluem informações sobre
processos técnicos e de negócios, regras e restrições de dados e estruturas de dados lógicos e físicos. Ele descreve
os dados em si (por exemplo, bancos de dados, elementos de dados, modelos de dados), os conceitos que os dados
representam (por exemplo, processos de negócios, sistemas de aplicativos, código de software, infraestrutura de tecnologia) e
as conexões (relacionamentos) entre os dados e os conceitos. Metadados ajudam uma organização a entender seus dados, seus sistemas,
417
418 • DMBOK2
e seus fluxos de trabalho. Ele permite a avaliação da qualidade dos dados e é parte integrante do gerenciamento de bancos de dados e outros aplicativos.
Contribui para a capacidade de processar, manter, integrar, proteger, auditar e controlar outros dados.
Para entender o papel vital dos metadados no gerenciamento de dados, imagine uma grande biblioteca, com centenas de milhares de livros e revistas,
mas nenhum catálogo de fichas. Sem um catálogo de fichas, os leitores podem nem saber como começar a procurar um livro específico ou mesmo um
tópico específico. O catálogo de fichas não apenas fornece as informações necessárias (quais livros e materiais a biblioteca possui e onde eles estão
arquivados), mas também permite que os usuários encontrem materiais usando diferentes pontos de partida (área de assunto, autor ou título). Sem o
catálogo, encontrar um livro específico seria difícil, senão impossível. Uma organização sem metadados é como uma biblioteca sem um catálogo de fichas.
Os metadados são essenciais para o gerenciamento de dados, bem como para o uso de dados (consulte várias referências a Metadados em todo o
DAMA-DMBOK). Todas as grandes organizações produzem e usam muitos dados. Em uma organização, diferentes indivíduos terão diferentes níveis de
conhecimento de dados, mas nenhum indivíduo saberá tudo sobre os dados.
Essas informações devem ser documentadas ou a organização corre o risco de perder um conhecimento valioso sobre si mesma.
Os metadados fornecem o principal meio de capturar e gerenciar o conhecimento organizacional sobre os dados.
No entanto, o gerenciamento de metadados não é apenas um desafio de gerenciamento de conhecimento; é também uma necessidade de gerenciamento
de risco. Os metadados são necessários para garantir que uma organização possa identificar dados privados ou confidenciais e que possa gerenciar o
ciclo de vida dos dados para seu próprio benefício e para atender aos requisitos de conformidade e minimizar os riscos
exposição.
Sem Metadados confiáveis, uma organização não sabe quais dados possui, o que os dados representam, de onde se originam, como se movem pelos
sistemas, quem tem acesso a eles ou o que significa que os dados sejam de alta qualidade. Sem metadados, uma organização não pode gerenciar seus
dados como um ativo. De fato, sem Metadados, uma organização pode não ser capaz de gerenciar seus dados.
À medida que a tecnologia evoluiu, a velocidade com que os dados são gerados também aumentou. Os metadados técnicos tornaram-se parte integrante
da maneira como os dados são movidos e integrados. O Padrão de Registro de Metadados da ISO, ISO/IEC 11179, destina-se a permitir a troca de
dados orientada por metadados em um ambiente heterogêneo, com base em definições exatas de dados. Metadados presentes em XML e outros
formatos permitem o uso dos dados. Outros tipos de marcação de metadados permitem que os dados sejam trocados, mantendo os significantes de
propriedade, requisitos de segurança, etc. (Consulte o Capítulo 8.)
Assim como outros dados, os metadados requerem gerenciamento. À medida que a capacidade das organizações de coletar e armazenar dados
aumenta, o papel dos metadados no gerenciamento de dados cresce em importância. Para ser orientada por dados, uma organização
deve ser orientado por metadados.
GERENCIAMENTO DE METADADOS • 419
Definição: Atividades de planejamento, implementação e controle para permitir o acesso a metadados integrados de
alta qualidade
Objetivos:
1. Fornecer compreensão organizacional dos termos e uso do negócio.

2. Colete e integre metadados de diversas fontes.
3. Forneça uma maneira padrão de acessar metadados.
4. Garantir a qualidade e segurança dos metadados.
O negócio
Motoristas

• O negócio •
1. Defina a Estratégia de Metadados (P) Estratégia de metadados
• Padrões de metadados
Requisitos 2. Entenda os requisitos de metadados
• Problemas de metadados • Arquitetura de metadados
(P)
• Arquitetura de dados • Metamodelo
1. Requisitos do usuário comercial
• Metadados de negócios • Metadados unificados
2. Requisitos Técnicos do Usuário
• Metadados técnicos • Armazenamentos de metadados
3. Defina a Arquitetura de Metadados (P)
• Metadados do Processo •
1. Criar MetaModelo (D) Linhagem de dados
• •
Metadados Operacionais 2. Aplicar Padrões de Metadados (C) Análise de Impacto
• Gestão de dados 3. Gerenciar Armazenamentos de Metadados (C) • Análise de Dependência
Metadados • Controle de metadados
4. Criar e manter metadados (O)
1. Integrar Metadados (O) Processo
2. Distribuir e entregar metadados (O)

5. Consultar, relatar e analisar metadados
(O) Consumidores:
Fornecedores: Participantes: •
• Administradores de Dados •
Dados comerciais Desenvolvedores de aplicativos
Comissários • Analista
Gerentes de projeto
• Arquitetos de Dados • Integradores de dados
• Gerenciadores de Dados •
• Usuários empresariais
• Gestão de dados Analistas de negócios
• Trabalhadores de conhecimento
Corpos • Analistas de Sistemas • Clientes &
• Modeladores de Dados
Colaboradores
• Base de dados • Cientistas de Dados
Administradores Técnico • Jornalistas de dados
Motoristas

Linhagem de Dados e Impacto • Repositório de Metadados
• Cobertura de Metadados
Tabela de desempenho
Análise Ferramentas de gerenciamento
• Metadados para Big Data • Repositórios de Metadados em outros • Repositório de Metadados

Ingerir Ferramentas Contribuição
• Relatórios de uso de metadados
• Qualidade de Metadados
Tabela de desempenho
Figura 84 Diagrama de Contexto: Metadados

420 • DMBOK2
Os dados não podem ser gerenciados sem metadados. Além disso, os próprios metadados devem ser gerenciados. Metadados confiáveis
e bem gerenciados ajudam a:
• Aumente a confiança nos dados fornecendo contexto e permitindo a medição da qualidade dos dados
• Aumente o valor das informações estratégicas (por exemplo, dados mestres) permitindo vários usos
• Melhore a eficiência operacional identificando dados e processos redundantes

• Prevenir o uso de dados desatualizados ou incorretos
• Reduza o tempo de pesquisa orientada a dados
• Melhore a comunicação entre consumidores de dados e profissionais de TI
• Criar uma análise de impacto precisa, reduzindo assim o risco de falha do projeto
• Melhore o tempo de colocação no mercado reduzindo o tempo do ciclo de vida do desenvolvimento do sistema
• Reduza os custos de treinamento e diminua o impacto da rotatividade de pessoal por meio de documentação completa de dados
contexto, história e origem
• Suporte à conformidade regulatória
Os metadados ajudam a representar informações de forma consistente, simplificando os recursos de fluxo de trabalho e protegendo
informações confidenciais, principalmente quando a conformidade regulatória é necessária.
As organizações obtêm mais valor de seus ativos de dados se seus dados forem de alta qualidade. Os dados de qualidade dependem da
governança. Por explicar os dados e os processos que permitem que as organizações funcionem, os metadados são essenciais para a
governança de dados. Se os metadados são um guia para os dados em uma organização, eles devem ser bem gerenciados.
Metadados mal gerenciados levam a:
• Dados redundantes e processos de gerenciamento de dados
• Dicionários, repositórios e outros armazenamentos de metadados replicados e redundantes

• Definições inconsistentes de elementos de dados e riscos associados ao uso indevido de dados
• Fontes e versões de metadados concorrentes e conflitantes que reduzem a confiança dos dados
consumidores
• Dúvida sobre a confiabilidade de metadados e dados
O gerenciamento de metadados bem executado permite uma compreensão consistente dos recursos de dados e um desenvolvimento
organizacional mais eficiente.
Os objetivos do gerenciamento de metadados incluem:
• Documentar e gerenciar o conhecimento organizacional da terminologia de negócios relacionada a dados para
garantir que as pessoas entendam o conteúdo dos dados e possam usar os dados de forma consistente
• Colete e integre metadados de diversas fontes para garantir que as pessoas entendam semelhanças e
diferenças entre dados de diferentes partes da organização

• Garantir a qualidade, consistência, moeda e segurança dos Metadados • Fornecer
formas padrão para tornar os Metadados acessíveis aos consumidores de Metadados (pessoas, sistemas e
processos)
• Estabelecer ou impor o uso de padrões técnicos de metadados para permitir a troca de dados
A implementação de uma solução de Metadados bem-sucedida segue estes princípios orientadores:
• Comprometimento organizacional: Comprometimento organizacional seguro (apoio da alta administração e
financiamento) ao gerenciamento de metadados como parte de uma estratégia geral para gerenciar dados como um ativo corporativo.
• Estratégia: Desenvolva uma estratégia de Metadados que explique como os Metadados serão criados, mantidos, integrados e
acessados. A estratégia deve direcionar os requisitos, que devem ser definidos antes da avaliação, compra e instalação dos
produtos de gerenciamento de metadados. A estratégia de Metadados deve estar alinhada com as prioridades de negócios.
• Perspectiva corporativa: Adote uma perspectiva corporativa para garantir extensibilidade futura, mas implemente
por meio de entrega iterativa e incremental para agregar valor.
• Socialização: Comunicar a necessidade de Metadados e a finalidade de cada tipo de Metadados;
a socialização do valor dos Metadados incentivará o uso comercial e, o mais importante, a contribuição do conhecimento empresarial.
• Acesso: Certifique-se de que os membros da equipe saibam como acessar e usar metadados.
• Qualidade: Reconheça que os Metadados são frequentemente produzidos por meio de processos existentes (modelagem de dados, SDLC,
definição de processos de negócios) e responsabilize os proprietários dos processos pela qualidade dos Metadados.
• Auditoria: Defina, aplique e audite padrões para Metadados para simplificar a integração e permitir o uso.
• Melhoria: Criar um mecanismo de feedback para que os consumidores possam informar o Metadata Management
equipe de Metadados incorreta ou desatualizada.
1.3.1 Metadados vs. Dados
Conforme declarado na introdução do capítulo, Metadados são um tipo de dado e devem ser gerenciados como tal. Uma questão que algumas
organizações enfrentam é onde traçar a linha entre dados que não são Metadados e dados que são Metadados. Conceitualmente, essa linha está
relacionada ao nível de abstração representado pelos dados. Por exemplo, ao relatar a divulgação da vigilância da Administração de Segurança
Nacional dos EUA sobre o uso do telefone de pessoas nos EUA, os números de telefone e os horários das chamadas eram rotineiramente chamados
de 'Metadados', o que implica que o 'real'

422 • DMBOK2
os dados compreendiam apenas o conteúdo das conversas telefônicas. O senso comum reconhece que os números de telefone e a duração das chamadas
telefônicas também são apenas dados simples.70
Uma regra prática pode ser que os metadados de uma pessoa sejam os dados de outra. Mesmo algo que pareça Metadados (por exemplo, uma lista de nomes
de colunas) pode ser apenas dados simples – se, por exemplo, esses dados foram a entrada para uma análise destinada a compreender o conteúdo de dados
em diferentes organizações.
Para gerenciar seus Metadados, as organizações não devem se preocupar com as distinções filosóficas. Em vez disso, eles devem definir os requisitos de
Metadados focados no que eles precisam de Metadados (para criar novos dados, entender os dados existentes, permitir a movimentação entre sistemas,
acessar dados, compartilhar dados) e dados de origem para atender a esses requisitos.
1.3.2 Tipos de Metadados
Os metadados geralmente são categorizados em três tipos: comercial, técnico e operacional. Essas categorias permitem que as pessoas entendam a gama de
informações que se enquadram no guarda-chuva geral dos Metadados, bem como as funções por meio das quais os Metadados são produzidos. Dito isso, as
categorias também podem levar a confusão, especialmente se as pessoas ficarem presas em perguntas sobre a qual categoria um conjunto de metadados
pertence ou quem deve usá-lo. É melhor pensar nessas categorias em relação à origem dos metadados, em vez de como eles são usados. Em relação ao uso,
as distinções entre os tipos de Metadados não são rígidas. Uso da equipe técnica e operacional
Metadados de 'negócios' e vice-versa.
Fora da tecnologia da informação, por exemplo, em biblioteconomia ou ciência da informação, os metadados são descritos usando um conjunto diferente de
categorias:
• Metadados descritivos (por exemplo, título, autor e assunto) descrevem um recurso e permitem a identificação
e recuperação.
• Metadados Estruturais descrevem relacionamentos dentro e entre recursos e suas partes componentes
(por exemplo, número de páginas, número de capítulos).
• Metadados administrativos (por exemplo, números de versão, datas de arquivamento) são usados para gerenciar recursos em seus
ciclo da vida.
Essas categorias podem informar o processo de definição dos requisitos de metadados.
1.3.2.1 Metadados de Negócios
Os Metadados de Negócios se concentram principalmente no conteúdo e na condição dos dados e incluem detalhes relacionados à governança de dados.
Metadados de Negócios incluem os nomes não técnicos e definições de conceitos, áreas de assunto, entidades e atributos; tipos de dados de atributo e outras
propriedades de atributo; descrições de intervalo; cálculos;
70 Cole, Davi. “Matamos pessoas com base em metadados.” Revisão de livros de Nova York. 10 de maio de 2014. http://bit.ly/2sV1ulS.
algoritmos e regras de negócio; valores de domínio válidos e suas definições. Exemplos de Metadados de Negócios
incluir:
• Definições e descrições de conjuntos de dados, tabelas e colunas • Regras de
negócios, regras de transformação, cálculos e derivações

• Modelos de dados
• Regras de qualidade de dados e resultados de medição •
Cronogramas pelos quais os dados são atualizados •
Procedência e linhagem de dados

• Padrões de dados
• Designações do sistema de registro para elementos de dados

• Restrições de valor válidas
• Informações de contato das partes interessadas (por exemplo, proprietários de dados, administradores de
dados) • Nível de segurança/privacidade dos dados
• Problemas conhecidos com dados
• Notas de uso de dados
1.3.2.2 Metadados Técnicos
Os metadados técnicos fornecem informações sobre os detalhes técnicos dos dados, os sistemas que armazenam dados e os processos que
os movem dentro e entre sistemas. Exemplos de metadados técnicos incluem:
• Tabela de banco de dados física e nomes de coluna •
Propriedades de coluna • Propriedades de objeto de banco
de dados • Permissões de acesso • Regras de CRUD (criar,
substituir, atualizar e excluir) de dados • Modelos de dados
físicos, incluindo nomes de tabelas de dados, chaves e índices •
Relacionamentos documentados entre os dados modelos e os ativos físicos • Detalhes do
trabalho ETL
• Definições de esquema de formato de arquivo
• Documentação de mapeamento de origem para destino
• Documentação de linhagem de dados, incluindo informações de impacto de alterações upstream e downstream • Nomes
e descrições de programas e aplicativos • Programações e dependências de tarefas do ciclo de atualização de conteúdo •
Regras de recuperação e backup • Direitos de acesso a dados, grupos, funções
1.3.2.3 Metadados Operacionais
Metadados Operacionais descrevem detalhes do processamento e acesso de dados. Por exemplo:

424 • DMBOK2
• Logs de execução de tarefas para programas em lote
• Histórico de extratos e resultados

• Anomalias de cronograma
• Resultados de auditoria, balanço, medições de controle
• Registros de erros
• Relatórios e padrões de acesso a consultas, frequência e tempo de execução
• Plano e execução de manutenção de patches e versão, nível de patch atual
• Provisões de backup, retenção, data de criação, recuperação de desastres
• Requisitos e disposições do SLA
• Padrões volumétricos e de uso
• Regras de arquivamento e retenção de dados, arquivos relacionados
• Critérios de purga
• Regras e acordos de compartilhamento de dados
• Funções e responsabilidades técnicas, contatos
1.3.3 Padrão de Registro de Metadados ISO / IEC 11179
O Padrão de Registro de Metadados da ISO, ISO/IEC 11179, fornece uma estrutura para definir um registro de metadados. Ele foi projetado para
permitir a troca de dados orientada por metadados, com base em definições exatas de dados, começando com elementos de dados. A norma está
estruturada em várias partes:
• Parte 1: Estrutura para a Geração e Padronização de Elementos de Dados
• Parte 3: Atributos Básicos de Elementos de Dados
• Parte 4: Regras e Diretrizes para a Formulação de Definições de Dados
• Parte 5: Princípios de nomenclatura e identificação para elementos de dados
• Parte 6: Registro de Elementos de Dados
1.3.4 Metadados para Dados Não Estruturados
Por sua natureza, todos os dados têm alguma estrutura, embora nem todos sejam formalmente estruturados nas linhas, colunas e registros
familiares dos bancos de dados relacionais. Quaisquer dados que não estejam em um banco de dados ou arquivo de dados, incluindo documentos
ou outras mídias, são considerados dados não estruturados. (Consulte os Capítulos 9 e 14.)
Os metadados são tão essenciais para o gerenciamento de dados não estruturados quanto para o gerenciamento de dados estruturados – talvez
até mais. Pense novamente na analogia do catálogo de fichas da introdução do capítulo. Livros e revistas em uma biblioteca são bons exemplos
de dados não estruturados. O principal uso dos Metadados em um catálogo de fichas é encontrar os materiais que se procura, qualquer que seja o
formato.
Metadados para dados não estruturados incluem Metadados descritivos, como informações de catálogo e palavras-chave de tesauros; Metadados
estruturais como tags, estruturas de campo, formato; Metadados administrativos, como fontes, cronogramas de atualização, direitos de acesso e
informações de navegação; Metadados bibliográficos, como catálogo de biblioteca

entradas; Metadados de manutenção de registros, como políticas de retenção; e preservação Metadados, como armazenamento, condição de
arquivamento e regras de conservação. (Consulte o Capítulo 9.)
Embora a maioria das afirmações sobre metadados para dados não estruturados esteja ligada a preocupações tradicionais de gerenciamento
de conteúdo, novas práticas estão surgindo em torno do gerenciamento de dados não estruturados em data lakes. As organizações que
desejam aproveitar os data lakes, usando plataformas de Big Data, como o Hadoop, estão descobrindo que devem catalogar os dados
ingeridos para permitir o acesso posterior. A maioria implementa processos para coletar metadados como parte da ingestão de dados. Um
conjunto mínimo de atributos de metadados precisa ser coletado sobre cada objeto ingerido no data lake (por exemplo, nome, formato, origem,
versão, data de recebimento etc.). Isso produz um catálogo de conteúdo do data lake.
1.3.5 Fontes de Metadados
Como deve ficar claro pelos tipos de Metadados, os Metadados podem ser coletados de muitas fontes diferentes.
Além disso, se os metadados de aplicativos e bancos de dados forem bem gerenciados, eles podem ser simplesmente coletados e integrados.
No entanto, a maioria das organizações não gerencia bem os metadados no nível do aplicativo, porque os metadados geralmente são criados
como um subproduto do processamento do aplicativo e não como um produto final (ou seja, não são criados com o consumo em mente). Tal
como acontece com outras formas de dados, há muito trabalho na preparação de metadados antes que possam ser integrados.
A maioria dos Metadados operacionais é gerada à medida que os dados são processados. A chave para usar esses Metadados é coletá-los
de forma utilizável e garantir que os responsáveis por interpretá-los tenham as ferramentas necessárias para fazê-lo. Lembre-se de que
interpretar dados em locais como logs de erros em si requer Metadados que descrevam os logs.
Da mesma forma, uma grande parte dos Metadados técnicos pode ser coletada de objetos de banco de dados.
É possível fazer engenharia reversa do conhecimento sobre dados de sistemas existentes e coletar Metadados de negócios de dicionários de
dados, modelos e documentação de processos existentes (Loshin, 2001; Aiken, 1995), mas há riscos em fazê-lo. O maior risco é não saber
quanto cuidado foi tomado para desenvolver e refinar as definições em primeiro lugar. Se as definições forem subdesenvolvidas ou ambíguas,
elas não fornecerão aos consumidores de dados as informações de que precisam para entender os dados que estão usando.
É melhor ser intencional sobre o desenvolvimento de definições do que simplesmente aceitar as existentes. O desenvolvimento de definições
leva tempo e o conjunto de habilidades certo (por exemplo, habilidades de escrita e facilitação). É por isso que o desenvolvimento de
Metadados de negócios requer administração. (Consulte o Capítulo 3.)
Muitos dos Metadados técnicos necessários para gerenciar bancos de dados e os Metadados de negócios necessários para usar os dados
podem ser coletados e desenvolvidos como parte do trabalho do projeto. Por exemplo, o processo de modelagem de dados requer discussões
sobre o significado dos elementos de dados e a relação entre eles. O conhecimento compartilhado durante essas discussões deve ser
capturado e preparado para uso em Dicionários de Dados, Glossários de Negócios e outros repositórios. Os próprios modelos de dados
incluem detalhes importantes sobre as características físicas dos dados.
O tempo deve ser alocado para garantir que os artefatos do projeto contenham Metadados de alta qualidade alinhados aos padrões
corporativos.
426 • DMBOK2
Metadados de negócios bem definidos são reutilizáveis de projeto para projeto e podem conduzir a uma compreensão consistente de como os
conceitos de negócios são representados em diferentes conjuntos de dados. Como parte do desenvolvimento intencional de Metadados para que
possam ser reutilizados, uma organização também pode planejar a integração de Metadados. Por exemplo, ele pode desenvolver um inventário de
sistemas e todos os metadados relacionados a um determinado sistema podem ser marcados com o mesmo sistema
identificador.
A criação de metadados por si só raramente funciona bem. A maioria das organizações não financia esse tipo de esforço e, mesmo quando o
fazem, é improvável que implementem processos de manutenção. Nesse aspecto, como em outros, os Metadados são como outros dados: devem
ser criados como produto de um processo bem definido, utilizando ferramentas que darão suporte à sua qualidade geral. Os administradores e
outros profissionais de gerenciamento de dados devem garantir que haja processos implementados para manter os metadados relacionados a
esses processos. Por exemplo, se uma organização coleta Metadados críticos de seus modelos de dados, ela deve garantir que haja um processo
de gerenciamento de mudanças em vigor para manter os modelos atualizados.
Para dar uma ideia da amplitude dos Metadados em qualquer organização, uma variedade de fontes é descrita aqui, em ordem alfabética em vez
de prioridade.
1.3.5.1 Repositórios de Metadados de Aplicativos
Um repositório de Metadados refere-se às tabelas físicas nas quais os Metadados são armazenados. Muitas vezes, eles são incorporados a
ferramentas de modelagem, ferramentas de BI e outros aplicativos. À medida que uma organização amadurece, ela desejará integrar Metadados
de repositórios nesses aplicativos para permitir que os consumidores de dados examinem toda a variedade de informações.
1.3.5.2 Glossário Comercial
A finalidade de um glossário de negócios é documentar e armazenar os conceitos e terminologia de negócios de uma organização, definições e
os relacionamentos entre esses termos.
Em muitas organizações, o glossário de negócios é apenas uma planilha. No entanto, à medida que as organizações amadurecem, elas geralmente
compram ou criam glossários que contêm informações robustas e a capacidade de gerenciá-las ao longo do tempo. Como acontece com todos os
sistemas orientados a dados, os glossários de negócios devem ser arquitetados para considerar hardware, software, banco de dados, processos
e recursos humanos com diferentes funções e responsabilidades. O aplicativo de glossário de negócios é estruturado para atender aos requisitos
funcionais dos três públicos principais:
• Usuários de negócios: analistas de dados, analistas de pesquisa, gerência e equipe executiva usam o negócio
glossário para entender a terminologia e os dados.
• Data Stewards: Data Steward usa o glossário de negócios para gerenciar o ciclo de vida dos termos e
definições e aprimorar o conhecimento empresarial associando ativos de dados a termos do glossário; por
por exemplo, vinculando termos a métricas de negócios, relatórios, análise de qualidade de dados ou componentes de tecnologia.
Os administradores de dados levantam problemas de terminologia e uso e ajudam a resolver diferenças em toda a organização.
• Usuários técnicos : Os usuários técnicos usam o glossário de negócios para fazer arquitetura, design de sistemas e
decisões de desenvolvimento e para realizar análises de impacto.
O glossário comercial deve capturar atributos de termos comerciais, como:
• Nome do termo, definição, sigla ou abreviatura e quaisquer sinônimos
• Unidade de negócios e ou aplicativo responsável por gerenciar os dados associados à terminologia
• Nome da pessoa que identifica o termo e data de atualização
• Associação de categorização ou taxonomia para o termo (associação funcional de negócios)
• Definições conflitantes que precisam de resolução, natureza do problema, cronograma de ação
• Mal-entendidos comuns em termos
• Algoritmos que suportam definições
• Linhagem
• Fonte oficial ou autorizada para os dados que suportam o termo
Toda implementação de glossário de negócios deve ter um conjunto básico de relatórios para dar suporte aos processos de governança.
Recomenda-se que as organizações não 'imprimam o glossário' porque o conteúdo do glossário não é estático. Os administradores de dados são
geralmente responsáveis pelo desenvolvimento, uso, operações e relatórios do glossário. O relatório inclui o rastreamento de novos termos e
definições que ainda não foram revisados, aqueles com status pendente e aqueles que não possuem definições ou outros atributos. (Consulte a
Seção 6.4.)
A facilidade de uso e a funcionalidade podem variar muito. Quanto mais simples e fácil a pesquisa do glossário de negócios, maior a probabilidade
de o conteúdo do glossário ser usado. No entanto, a característica mais importante de um glossário é que ele contém
conteúdo robusto.
1.3.5.3 Ferramentas de Business Intelligence (BI)
As ferramentas de Business Intelligence produzem vários tipos de Metadados relevantes para o design de Business Intelligence, incluindo
informações gerais, classes, objetos, itens derivados e calculados, filtros, relatórios, campos de relatório, layout de relatório, usuários de relatórios,
frequência de distribuição de relatórios e canais de distribuição de relatórios.
1.3.5.4 Ferramentas de Gerenciamento de Configuração
As ferramentas ou bancos de dados de gerenciamento de configuração (CMDB) fornecem a capacidade de gerenciar e manter Metadados
especificamente relacionados aos ativos de TI, os relacionamentos entre eles e os detalhes contratuais do ativo. Cada ativo no banco de dados
CMDB é chamado de item de configuração (CI). Os metadados padrão são coletados e gerenciados para cada tipo de IC. Muitas organizações
integram o CMDB com os processos de gerenciamento de alterações para identificar os ativos ou aplicativos relacionados afetados por uma
alteração em um ativo específico. Os repositórios fornecem mecanismos para vincular os ativos no repositório de metadados aos detalhes reais da
implementação física no CMDB para fornecer uma visão completa dos dados e das plataformas.
428 • DMBOK2
1.3.5.5 Dicionários de dados
Um dicionário de dados define a estrutura e o conteúdo dos conjuntos de dados, geralmente para um único banco de dados, aplicativo ou armazém. O dicionário
pode ser usado para gerenciar os nomes, descrições, estrutura, características, requisitos de armazenamento, valores padrão, relacionamentos, exclusividade
e outros atributos de cada elemento de dados em um modelo. Ele também deve conter definições de tabela ou arquivo. Dicionários de dados são incorporados
em ferramentas de banco de dados para a criação,
operação, manipulação dos dados neles contidos. Para disponibilizar esses Metadados aos consumidores de dados, eles devem ser extraídos do banco de
dados ou das ferramentas de modelagem. Os dicionários de dados também podem descrever em terminologia de negócios quais elementos de dados estão
disponíveis para a comunidade, provisionados sob quais restrições de segurança e aplicados em quais processos de negócios. O tempo pode ser economizado
ao definir, publicar e manter uma camada semântica para relatórios e análises, aproveitando o conteúdo diretamente do modelo lógico. No entanto, conforme
observado anteriormente, as definições existentes devem ser usadas com cautela, especialmente em uma organização com baixo nível de maturidade em
relação ao gerenciamento de metadados.
Muitos processos de negócios, relacionamentos e terminologias importantes são explicados durante o desenvolvimento do modelo de dados. Essas informações,
capturadas no modelo de dados lógicos, geralmente são perdidas quando as estruturas físicas são implantadas na produção. Um dicionário de dados pode
ajudar a garantir que essas informações não sejam totalmente perdidas para a organização e que os modelos lógicos e físicos sejam mantidos de acordo após
a implantação da produção.
1.3.5.6 Ferramentas de Integração de Dados
Muitas ferramentas de integração de dados são usadas para executáveis para mover dados de um sistema para outro ou entre vários módulos dentro do mesmo
sistema. Muitas dessas ferramentas geram arquivos transitórios, que podem conter cópias ou cópias derivadas dos dados. Essas ferramentas são capazes de
carregar dados de várias fontes e, em seguida, operar nos dados carregados, por meio de agrupamento, correção, reformatação, junção, filtragem ou outras
operações e, em seguida, gerar dados de saída, que são distribuídos para os locais de destino. Eles documentam a linhagem como dados conforme ela se
move entre os sistemas. Qualquer solução de Metadados bem-sucedida deve ser capaz de usar os Metadados de linhagem à medida que se movem pelas
ferramentas de integração e expô-los como uma linhagem holística das fontes reais
aos destinos finais.
As ferramentas de integração de dados fornecem interfaces de aplicativo (API) para permitir que repositórios de metadados externos extraiam as informações
de linhagem e os metadados de arquivos temporários. Depois que o repositório de metadados coleta as informações, algumas ferramentas podem gerar um
diagrama de linhagem holístico para qualquer elemento de dados. As ferramentas de integração de dados também fornecem metadados sobre a execução de
vários trabalhos de integração de dados, incluindo a última execução bem-sucedida, duração e status do trabalho. Alguns repositórios de metadados podem
extrair as estatísticas de tempo de execução de integração de dados e os metadados e expô-los juntamente com os elementos de dados. (Consulte os Capítulos
6 e 8.)
1.3.5.7 Gerenciamento de Banco de Dados e Catálogos do Sistema
Os catálogos de banco de dados são uma fonte importante de metadados. Eles descrevem o conteúdo dos bancos de dados, juntamente com informações de
dimensionamento, versões de software, status de implantação, tempo de atividade da rede, tempo de atividade da infraestrutura, disponibilidade,
e muitos outros atributos de Metadados operacionais. A forma mais comum de banco de dados é relacional. Os bancos de dados relacionais gerenciam os dados como
um conjunto de tabelas e colunas, onde uma tabela contém uma ou mais colunas, índices, restrições, exibições e procedimentos. Uma solução de Metadados deve ser
capaz de se conectar a vários bancos de dados e conjuntos de dados e ler todos os Metadados expostos pelo banco de dados. Algumas das ferramentas do repositório
de Metadados podem integrar os Metadados expostos das ferramentas de gerenciamento do sistema para fornecer uma visão mais holística sobre os ativos físicos
capturados.
1.3.5.8 Ferramentas de Gerenciamento de Mapeamento de Dados
As ferramentas de gerenciamento de mapeamento são usadas durante a fase de análise e design de um projeto para transformar requisitos em especificações de
mapeamento, que podem ser consumidas diretamente por uma ferramenta de integração de dados ou usadas pelos desenvolvedores para gerar código de integração
de dados. A documentação de mapeamento também é frequentemente mantida em documentos do Excel em toda a empresa. Os fornecedores agora estão considerando
repositórios centralizados para as especificações de mapeamento com recursos para realizar controle de versão e análise de alterações entre versões. Muitas
ferramentas de mapeamento integram-se com ferramentas de integração de dados para automatizar a geração dos programas de integração de dados e a maioria pode
trocar dados com outros repositórios de Metadados e Dados de Referência. (Consulte o Capítulo 8.)
1.3.5.9 Ferramentas de Qualidade de Dados
As ferramentas de qualidade de dados avaliam a qualidade dos dados por meio de regras de validação. A maioria dessas ferramentas oferece a capacidade de trocar
as pontuações de qualidade e padrões de perfis com outros repositórios de metadados, permitindo que o repositório de metadados anexe as pontuações de qualidade
aos ativos físicos relevantes.
1.3.5.10 Diretórios e Catálogos
Enquanto dicionários e glossários de dados contêm informações detalhadas sobre terminologia, tabelas e campos, um diretório ou catálogo contém informações sobre
sistemas, fontes e locais de dados em uma organização.
Um diretório de Metadados é particularmente útil para desenvolvedores e superusuários de dados, como equipes de administração de dados e analistas de dados, para
entender o escopo dos dados na empresa, seja para pesquisar problemas ou encontrar informações sobre o fornecimento de novos aplicativos.
1.3.5.11 Ferramentas de mensagens de eventos
As ferramentas de mensagens de eventos movem dados entre diversos sistemas. Para fazer isso, eles exigem muitos metadados. Eles também geram Metadados que
descrevem esse movimento. Essas ferramentas incluem interfaces gráficas através das quais gerenciam a lógica de movimentação de dados. Eles podem exportar os
detalhes de implementação de interfaces, lógica de movimento e estatísticas de processamento para outros repositórios de metadados.
430 • DMBOK2
1.3.5.12 Ferramentas e Repositórios de Modelagem
As ferramentas de modelagem de dados são usadas para construir vários tipos de modelos de dados: conceituais, lógicos e físicos.
Essas ferramentas produzem Metadados relevantes para o design do aplicativo ou modelo de sistema, como áreas de assunto, entidades
lógicas, atributos lógicos, relacionamentos de entidade e atributo, supertipos e subtipos, tabelas, colunas, índices, chaves primárias e
estrangeiras, restrições de integridade e outros tipos de atribuição dos modelos. Os repositórios de metadados podem ingerir os modelos
criados por essas ferramentas e integrar os metadados importados ao repositório. As ferramentas de modelagem geralmente são a fonte
do conteúdo do dicionário de dados.
1.3.5.13 Repositórios de Dados de Referência
Dados de referência documentam os valores de negócios e as descrições dos vários tipos de dados enumerados (domínios) e seu uso
contextual em um sistema. As ferramentas usadas para gerenciar Dados de Referência também são capazes de gerenciar
relacionamentos entre os vários valores codificados dentro do mesmo domínio ou entre domínios. Esses conjuntos de ferramentas
normalmente fornecem recursos para enviar os Dados de Referência coletados para um repositório de Metadados, que por sua vez
fornecerá mecanismos para associar os Dados de Referência ao glossário de negócios e aos locais onde são implementados fisicamente,
como colunas ou campos.
1.3.5.14 Registros de Serviço
Um registro de serviço gerencia e armazena as informações técnicas sobre serviços e pontos de extremidade de serviço de uma
perspectiva de arquitetura orientada a serviços (SOA). Por exemplo, definições, interfaces, operações, entradas e
parâmetros de saída, políticas, versões e cenários de uso de amostra. Alguns dos metadados mais importantes relacionados aos
serviços incluem versão do serviço, local do serviço, data center, disponibilidade, data de implantação, porta de serviço, endereço IP,
porta de estatísticas, tempo limite de conexão e tempo limite de nova tentativa de conexão. Os registros de serviço podem ser
consultados para satisfazer várias necessidades, como exibir uma lista de todos os serviços disponíveis, serviços com uma versão
específica, serviços obsoletos ou detalhes sobre um serviço específico. Os serviços também podem ser revisados para potencial
reutilização. As informações contidas nesses repositórios fornecem fatos importantes sobre quais dados existem e como eles se movem
entre vários sistemas ou aplicativos. Metadados em repositórios de serviço podem ser extraídos e incorporados com Metadados
coletados de outras ferramentas para fornecer uma visão completa de como os dados estão se movendo entre os vários sistemas.
1.3.5.15 Outros Armazenamentos de Metadados
Outros armazenamentos de metadados incluem listas especializadas, como registros de eventos, listas ou interfaces de origem,
conjuntos de códigos, léxicos, esquema espacial e temporal, referência espacial e distribuição de conjuntos de dados geográficos
digitais, repositórios de repositórios e regras de negócios.

GESTÃO DE METADADOS • 431
1.3.6 Tipos de Arquitetura de Metadados
Como outras formas de dados, os metadados têm um ciclo de vida. Conceitualmente, todas as soluções de gerenciamento de metadados incluem
camadas de arquitetura que correspondem a pontos no ciclo de vida de metadados:
• Criação e fornecimento de metadados
• Armazenamento de metadados em um ou mais repositórios
• Integração de metadados
• Entrega de metadados
• Uso de metadados
• Controle e gerenciamento de metadados
Diferentes abordagens arquitetônicas podem ser usadas para fornecer, armazenar, integrar, manter e tornar os metadados
acessíveis aos consumidores.
1.3.6.1 Arquitetura de Metadados Centralizados
Uma arquitetura centralizada consiste em um único repositório de Metadados que contém cópias de Metadados de várias fontes. Organizações com
recursos de TI limitados ou que buscam automatizar o máximo possível podem optar por evitar essa opção de arquitetura. As organizações que buscam
um alto grau de consistência no repositório de metadados comum podem se beneficiar de uma arquitetura centralizada.
As vantagens de um repositório centralizado incluem:
• Alta disponibilidade, pois é independente dos sistemas de origem
• Recuperação rápida de metadados, pois o repositório e a consulta residem juntos
• Estruturas de banco de dados resolvidas não afetadas pela natureza proprietária de terceiros ou comerciais
sistemas
• Os metadados extraídos podem ser transformados, personalizados ou aprimorados com metadados adicionais que podem
não residem no sistema de origem, melhorando a qualidade
Algumas limitações da abordagem centralizada incluem:
• Processos complexos são necessários para garantir que as alterações nos metadados de origem sejam rapidamente replicadas em
o repositório
• A manutenção de um repositório centralizado pode ser cara
• A extração pode exigir módulos personalizados ou middleware

• A validação e manutenção de código personalizado pode aumentar as demandas tanto da equipe interna de TI quanto
os fornecedores de software
A Figura 85 mostra como os Metadados são coletados em um repositório de Metadados autônomo com seu próprio repositório de Metadados interno. O
armazenamento interno é preenchido por meio de uma importação agendada (setas) dos Metadados das diversas ferramentas. Por sua vez, o repositório
centralizado expõe um portal para os usuários finais enviarem suas consultas. O portal de metadados passa a solicitação para o repositório de metadados
centralizado. O repositório centralizado cumprirá as

432 • DMBOK2
solicitação dos Metadados coletados. Nesse tipo de implementação, a capacidade de passar a solicitação do usuário para várias ferramentas diretamente
não é suportada. A pesquisa global nos Metadados coletados das várias ferramentas é possível devido à coleta de vários Metadados no repositório
centralizado.
Portal de metadados
REPOSITÓRIO DE METADADOS DA EMPRESA
Ferramentas de BI
Modelagem Ferramentas ETL Serviços SGBD Referência Dados Mensagens Ferramentas de
Ferramentas
Repositório Ferramentas Dados Qualidade Ferramentas configuração
Ferramentas
Figura 85 Arquitetura de Metadados Centralizados
1.3.6.2 Arquitetura de Metadados Distribuídos
Uma arquitetura completamente distribuída mantém um único ponto de acesso. O mecanismo de recuperação de metadados responde às solicitações do
usuário recuperando dados dos sistemas de origem em tempo real; não há repositório persistente. Nessa arquitetura, o ambiente de gerenciamento de
metadados mantém os catálogos do sistema de origem necessários e as informações de pesquisa necessárias para processar consultas e pesquisas de
usuários com eficiência. Um agente de solicitação de objeto comum ou protocolo de middleware semelhante acessa esses sistemas de origem.
As vantagens da arquitetura de metadados distribuídos incluem:
• Os metadados são sempre tão atuais e válidos quanto possível porque são recuperados de sua fonte
• As consultas são distribuídas, possivelmente melhorando o tempo de resposta e processo
• As solicitações de metadados de sistemas proprietários são limitadas ao processamento de consultas, em vez de exigir um
compreensão detalhada de estruturas de dados proprietárias, minimizando assim a implementação e
esforço de manutenção necessário
• O desenvolvimento de processamento automatizado de consultas de metadados é provavelmente mais simples, exigindo o mínimo de manual
intervenção
• O processamento em lote é reduzido, sem replicação de metadados ou processos de sincronização
As arquiteturas distribuídas também têm limitações:
• Não há capacidade de suportar entradas de Metadados definidas pelo usuário ou inseridas manualmente, pois não há repositório em
qual colocar esses acréscimos
• Padronização de apresentação de Metadados de diversos sistemas
• Os recursos de consulta são diretamente afetados pela disponibilidade dos sistemas de origem participantes
• A qualidade dos metadados depende exclusivamente dos sistemas de origem participantes

Portal de metadados
Ferramentas de BI
Modelagem Ferramentas ETL Serviços SGBD Referência Dados Mensagens Ferramentas de
Ferramentas
Repositório Ferramentas Dados Qualidade Ferramentas configuração
Ferramentas
Figura 86 Arquitetura de metadados distribuídos
A Figura 86 ilustra uma arquitetura de Metadados distribuída. Não há repositório de repositório de metadados centralizado e o portal
passa as solicitações dos usuários para a ferramenta apropriada para execução. Como não há armazenamento centralizado para os
Metadados a serem coletados das várias ferramentas, cada solicitação deve ser delegada às fontes; portanto, não existe capacidade
para uma pesquisa global nas várias fontes de Metadados.
1.3.6.3 Arquitetura de Metadados Híbridos
Uma arquitetura híbrida combina características de arquiteturas centralizadas e distribuídas. Os metadados ainda são movidos
diretamente dos sistemas de origem para um repositório centralizado. No entanto, o design do repositório considera apenas os Metadados
adicionados pelo usuário, os itens padronizados críticos e as adições de fontes manuais.
A arquitetura se beneficia da recuperação quase em tempo real de Metadados de sua origem e Metadados aprimorados
para atender às necessidades do usuário de forma mais eficaz, quando necessário. A abordagem híbrida reduz o esforço de intervenção
manual de TI e funcionalidade de acesso com código personalizado a sistemas proprietários. Os Metadados são tão atuais e válidos
quanto possível no momento do uso, com base nas prioridades e requisitos do usuário. A arquitetura híbrida não melhora a disponibilidade
do sistema.
A disponibilidade dos sistemas de origem é uma limitação, pois a natureza distribuída dos sistemas back-end trata do processamento de
consultas. A sobrecarga adicional é necessária para vincular esses resultados iniciais com o aumento de metadados no repositório
central antes de apresentar o conjunto de resultados ao usuário final.
Muitas organizações podem se beneficiar de uma arquitetura híbrida, incluindo aquelas que têm Metadados operacionais que mudam
rapidamente, aquelas que precisam de Metadados consistentes e uniformes e aquelas que experimentam um crescimento substancial
em Metadados e fontes de Metadados. Organizações com Metadados mais estáticos e perfis de crescimento de Metadados menores
podem não ver o potencial máximo dessa alternativa de arquitetura.
1.3.6.4 Arquitetura de Metadados Bidirecional
Outra abordagem arquitetônica avançada é a arquitetura de Metadados bidirecional, que permite que os Metadados sejam alterados em
qualquer parte da arquitetura (fonte, integração de dados, interface do usuário) e, em seguida, o feedback é coordenado do repositório
(broker) para sua fonte original.

434 • DMBOK2
Vários desafios são aparentes nesta abordagem. O design força o repositório de Metadados a conter a versão mais recente da fonte
de Metadados e também o força a gerenciar as alterações na fonte. As mudanças devem ser aprisionadas sistematicamente e depois
resolvidas. Conjuntos adicionais de interfaces de processo para vincular o repositório à(s) fonte(s) de metadados devem ser criados e
mantidos.
Portal de metadados
REPOSITÓRIO DE METADADOS DA EMPRESA
COM UM
Modelagem ETL Serviços SGBD Referência Dados Mensagens Configura
Metadados Metadados Metadados Metadados Metadados Metadados Metadados ção
Qualidade
Metadados Metadados
Ferramentas de BI
Modelagem Ferramentas ETL Serviços SGBD Referência Dados Mensagens Ferramentas
Ferramentas
Repositório Ferramentas Dados Qualidade Ferramentas de configuração
Ferramentas
Figura 87 Arquitetura de Metadados Híbridos
A Figura 87 ilustra como Metadados comuns de diferentes fontes são coletados em um repositório de Metadados centralizado.
Os usuários enviam suas consultas ao portal de Metadados, que passa a solicitação para um repositório centralizado. O repositório
centralizado tentará atender à solicitação do usuário a partir dos Metadados comuns coletados inicialmente das várias fontes. À medida
que a solicitação se torna mais específica ou o usuário precisa de metadados mais detalhados, o repositório centralizado delega à fonte
específica para pesquisar os detalhes específicos. A pesquisa global nas várias ferramentas está disponível devido aos Metadados
comuns coletados no repositório centralizado.
2. Atividades
2.1 Definir Estratégia de Metadados
Uma estratégia de Metadados descreve como uma organização pretende gerenciar seus Metadados e como ela passará do estado
atual para as práticas do estado futuro. Uma estratégia de Metadados deve fornecer uma estrutura para que as equipes de
desenvolvimento melhorem o gerenciamento de Metadados. O desenvolvimento de requisitos de metadados ajudará a esclarecer os
direcionadores da estratégia e identificar possíveis obstáculos para implementá-la.

A estratégia inclui a definição da futura arquitetura de Metadados da empresa estatal da organização e as fases de implementação necessárias para
atender aos objetivos estratégicos. As etapas incluem:
• Iniciar o planejamento da estratégia de Metadados: O objetivo da iniciação e planejamento é permitir que os Metadados
equipe de estratégia para definir suas metas de curto e longo prazo. O planejamento inclui a elaboração de uma carta, escopo e
objetivos alinhados com os esforços gerais de governança e estabelecendo um plano de comunicação para apoiar
o esforço. Os principais interessados devem estar envolvidos no planejamento.
• Conduzir entrevistas com as principais partes interessadas: As entrevistas com as partes interessadas comerciais e técnicas fornecem uma
base de conhecimento para a estratégia de Metadados.
• Avaliar as fontes de metadados e a arquitetura de informações existentes: a avaliação determina o
grau de dificuldade em resolver os problemas de Metadados e sistemas identificados nas entrevistas e
revisão de documentação. Durante esta fase, conduza entrevistas detalhadas com a equipe de TI chave e revise
documentação das arquiteturas do sistema, modelos de dados, etc.
• Desenvolver a arquitetura de Metadados do futuro: refinar e confirmar a visão de futuro e desenvolver o longo
arquitetura de destino de longo prazo para o ambiente de Metadados gerenciados neste estágio. Esta fase deve levar em conta
para componentes estratégicos, como estrutura organizacional, alinhamento com governança de dados e
administração, arquitetura de metadados gerenciada, arquitetura de entrega de metadados, arquitetura técnica,
e arquitetura de segurança.
• Desenvolva um plano de implementação em fases: valide, integre e priorize as descobertas do
entrevistas e análises de dados. Documente a estratégia de Metadados e defina uma implementação em fases
abordagem para passar do ambiente de Metadados gerenciado existente para o futuro.
A estratégia evoluirá com o tempo, à medida que os requisitos de metadados, a arquitetura e o ciclo de vida dos metadados forem
melhor compreendido.
2.2 Compreender os requisitos de metadados
Os requisitos de metadados começam com o conteúdo: quais metadados são necessários e em que nível. Por exemplo, nomes físicos e lógicos
precisam ser capturados para colunas e tabelas. O conteúdo de metadados é amplo e os requisitos virão de consumidores de dados comerciais e
técnicos. (Consulte a Seção 1.3.2.)
Há também muitos requisitos focados em funcionalidade associados a uma solução abrangente de Metadados:
• Volatilidade: com que frequência os atributos e conjuntos de metadados serão atualizados
• Sincronização: Tempo de atualizações em relação às alterações de origem
• Histórico: se as versões históricas dos metadados precisam ser retidas
• Direitos de acesso: quem pode acessar os metadados e como eles acessam, juntamente com a interface do usuário específica
funcionalidade de acesso
436 • DMBOK2
• Estrutura: como os metadados serão modelados para armazenamento
• Integração: O grau de integração de Metadados de diferentes fontes; regras de integração
• Manutenção: Processos e regras para atualização de Metadados (registro e encaminhamento para aprovação)
• Gestão: Funções e responsabilidades para gerenciar Metadados
• Qualidade: requisitos de qualidade de metadados
• Segurança: Alguns Metadados não podem ser expostos porque revelarão a existência de
dados
2.3 Definir a Arquitetura de Metadados
Um sistema de Gerenciamento de Metadados deve ser capaz de extrair Metadados de várias fontes. Projete a arquitetura para ser capaz
de varrer as várias fontes de Metadados e atualizar periodicamente o repositório.
O sistema deve suportar as atualizações manuais de Metadados, solicitações, pesquisas e pesquisas de Metadados por vários grupos
de usuários.
Um ambiente de Metadados gerenciados deve isolar o usuário final das várias e díspares fontes de Metadados.
A arquitetura deve fornecer um único ponto de acesso para o repositório de metadados. O ponto de acesso deve fornecer todos os
recursos de Metadados relacionados de forma transparente ao usuário. Os usuários devem poder acessar Metadados sem estar cientes
dos diferentes ambientes das fontes de dados. Em soluções de análise e Big Data, a interface pode ter funções amplamente definidas
pelo usuário (UDF) para se basear em vários conjuntos de dados, e a exposição de metadados ao usuário final é inerente a essas
personalizações. Com menos dependência de UDF em soluções, os usuários finais estarão coletando, inspecionando e usando conjuntos
de dados de forma mais direta e vários metadados de suporte geralmente são mais expostos.
O design da arquitetura depende dos requisitos específicos da organização. Três abordagens arquitetônicas técnicas para construir um
repositório de Metadados comum imitam as abordagens para projetar data warehouses: centralizado, distribuído e híbrido (consulte a
Seção 1.3.6). Todas essas abordagens levam em consideração a implementação do repositório e como os mecanismos de atualização
operam.
2.3.1 Criar MetaModelo
Crie um modelo de dados para o repositório de metadados, ou metamodelo, como uma das primeiras etapas de design após a conclusão
da estratégia de metadados e a compreensão dos requisitos de negócios. Diferentes níveis de metamodelo podem ser desenvolvidos
conforme necessário; um modelo conceitual de alto nível, que explica as relações entre os sistemas, e um metamodelo de nível inferior
que detalha as atribuições, para descrever os elementos e processos de um modelo. Além de ser uma ferramenta de planejamento e um
meio de articulação de requisitos, o metamodelo é em si um valioso

fonte de metadados.
A Figura 88 descreve um metamodelo de repositório de metadados de amostra. As caixas representam as principais entidades de alto nível,
que contêm os dados.
Metadados de Negócios de Arquitetura
O negócio
Sistema
Glossário
Dados lógicos Dados físicos
Modelo de dados Banco de dados Glossário

Inscrição
Termos
Arquivo/Tabela
Codificado
Entidade
Domínio
Atributo Campo/Coluna Conjuntos de códigos Valor do código Valor do negócio
Metadados técnicos
Figura 88 Exemplo de Metamodelo de Repositório de Metadados
2.3.2 Aplicar Padrões de Metadados
A solução de Metadados deve aderir aos padrões internos e externos acordados conforme identificado na estratégia de Metadados. Os metadados
devem ser monitorados quanto à conformidade pelas atividades de governança. Os padrões internos de metadados da organização incluem
convenções de nomenclatura, atribuições personalizadas, segurança, visibilidade e documentação de processamento. Os padrões de metadados
externos da organização incluem os formatos de troca de dados e o design de interfaces de programação de aplicativos.
2.3.3 Gerenciar Armazenamentos de Metadados
Implemente atividades de controle para gerenciar o ambiente de Metadados. O controle de repositórios é o controle de movimentação de Metadados
e atualizações de repositório realizadas pelo especialista em Metadados. Essas atividades são de natureza administrativa e envolvem o monitoramento
e a resposta a relatórios, avisos, logs de tarefas e a resolução de vários problemas no ambiente de repositório implementado. Muitas atividades de
controle são padrão para operações de dados e manutenção de interface. As atividades de controle devem ter supervisão de governança de dados.
As atividades de controle incluem:
• Agendamento e monitoramento de trabalhos
• Carregar análise estatística
• Backup, recuperação, arquivamento, limpeza

438 • DMBOK2
• Modificações de configuração • Ajuste
de desempenho • Análise de estatísticas
de consulta • Geração de consultas e
relatórios • Gerenciamento de segurança
• As atividades de controle de qualidade
incluem: • Garantia de qualidade, controle de
qualidade • Frequência de atualização de dados
– conjuntos de correspondência a prazos • Relatórios de metadados ausentes
• Relatório de metadados antigos • Metadados As atividades de gerenciamento
incluem: • Carregamento, digitalização, importação e marcação de ativos •
Mapeamento e movimentação de origem • Controle de versão •
Gerenciamento da interface do usuário • Vinculação de conjuntos de dados
Manutenção de metadados – para provisionamento NOSQL • Vinculação de
dados à aquisição de dados internos – links personalizados e Metadados de
trabalho • Licenciamento para fontes e feeds de dados externos • Metadados
de aprimoramento de dados, por exemplo, Link para GIS • E treinamento, incluindo: •
Educação e treinamento de usuários e administradores de dados • Geração e análise de métricas
de gerenciamento • Treinamento sobre as atividades de controle e consulta e relatórios
2.4 Criar e manter metadados
Conforme descrito na Seção 1.3.5, os metadados são criados por meio de vários processos e armazenados em vários locais dentro de uma
organização. Para serem de alta qualidade, os Metadados devem ser gerenciados como um produto. Bons metadados não são criados por
acaso. Exige planejamento. (Consulte o Capítulo 13.)
Vários princípios gerais de gerenciamento de metadados descrevem os meios para gerenciar metadados para qualidade:
• Responsabilidade: Reconheça que os Metadados são frequentemente produzidos por meio de processos existentes (modelagem de
dados, SDLC, definição de processos de negócios) e responsabilize os proprietários dos processos pela qualidade dos Metadados.
• Padrões: Defina, aplique e audite padrões para Metadados para simplificar a integração e permitir o uso.
• Melhoria: Criar um mecanismo de feedback para que os consumidores possam informar o Metadata Management
equipe de metadados incorretos ou desatualizados.
Como outros dados, os metadados podem ser perfilados e inspecionados quanto à qualidade. Sua manutenção deve ser programada ou
concluída como parte auditável do trabalho do projeto.

2.4.1 Integrar Metadados
Os processos de integração reúnem e consolidam Metadados de toda a empresa, incluindo Metadados de dados adquiridos fora da empresa. O repositório de
Metadados deve integrar Metadados técnicos extraídos com Metadados relevantes de negócios, processos e administração. Os metadados podem ser extraídos
usando adaptadores, scanners, aplicativos de ponte ou acessando diretamente os metadados em um armazenamento de dados de origem. Os adaptadores
estão disponíveis com muitas ferramentas de software de terceiros, bem como com ferramentas de integração de metadados. Em alguns casos, os adaptadores
serão desenvolvidos utilizando as API's da ferramenta.
Surgem desafios na integração que exigirão governança. A integração de conjuntos de dados internos, dados externos como estatísticas governamentais e
dados provenientes de formulários não eletrônicos, como white papers, artigos em revistas ou relatórios, pode levantar inúmeras questões sobre qualidade e
semântica.
Realize a varredura do repositório em duas abordagens distintas.
• Interface proprietária: em um processo de varredura e carregamento de etapa única, um scanner coleta os metadados de um
sistema de origem e, em seguida, chama diretamente o componente carregador específico do formato para carregar os metadados no
repositório. Nesse processo, não há saída de arquivo específico de formato e a coleta e carregamento de
Os metadados ocorrem em uma única etapa.
• Interface semi-proprietária: em um processo de duas etapas, um scanner coleta os metadados de uma fonte
sistema e o gera em um arquivo de dados de formato específico. O scanner produz apenas um arquivo de dados que o
repositório receptor precisa ser capaz de ler e carregar apropriadamente. A interface é mais aberta
arquitetura, pois o arquivo é legível por vários métodos.
Um processo de digitalização usa e produz vários tipos de arquivos durante o processo.
• Arquivo de controle: contendo a estrutura de origem do modelo de dados
• Arquivo de reutilização: contendo as regras para gerenciamento de reutilização de cargas de processo
• Arquivos de log: Produzidos durante cada fase do processo, um para cada varredura ou extração e um para cada
ciclo de carga
• Arquivos temporários e de backup: Use durante o processo ou para rastreabilidade
Use uma área de teste de metadados não persistente para armazenar arquivos temporários e de backup. A área de teste oferece suporte a processos de
reversão e recuperação e fornece uma trilha de auditoria provisória para auxiliar os gerentes de repositório ao investigar a origem de metadados ou problemas
de qualidade. A área de preparação pode assumir a forma de um diretório de arquivos ou um
base de dados.
As ferramentas de integração de dados usadas para armazenamento de dados e aplicativos de Business Intelligence são frequentemente usadas de forma
eficaz em processos de integração de metadados. (Consulte o Capítulo 8.)
2.4.2 Distribuir e entregar metadados
Os metadados são entregues aos consumidores de dados e a aplicativos ou ferramentas que exigem feeds de metadados. Entrega
mecanismos incluem:
440 • DMBOK2
• Sites de intranet de metadados para navegação, pesquisa, consulta, geração de relatórios e análise
• Relatórios, glossários e outros documentos
• Armazéns de dados, data marts e ferramentas de BI (Business Intelligence)
• Ferramentas de modelagem e desenvolvimento de software
• Mensagens e transações
• Serviços da Web e Interfaces de Programação de Aplicativos (APIs)
• Soluções de interface de organização externa (por exemplo, soluções de cadeia de suprimentos)
A solução de Metadados geralmente é vinculada a uma solução de Business Intelligence, para que tanto o escopo quanto a moeda dos Metadados
sejam sincronizados com o conteúdo de BI. Um link fornece um meio de integração na entrega de BI ao usuário final. Da mesma forma, algumas
soluções de CRM (Customer Relationship Management) ou outras soluções de ERP (Enterprise Resource Planning) podem exigir integração de
metadados na camada de entrega do aplicativo.
Metadados são trocados com organizações externas usando arquivos (planos, XML ou JSON estruturados) ou por meio da web
Serviços.
2.5 Consultar, relatar e analisar metadados
Os metadados orientam o uso de ativos de dados. Use Metadados em Business Intelligence (relatórios e análises), decisões de negócios
(operacionais, táticas, estratégicas) e em semântica de negócios (o que eles dizem, o que eles significam – linguagem de negócios'). Um repositório
de metadados deve ter um aplicativo front-end que suporte a funcionalidade de pesquisa e recuperação necessária para toda essa orientação e
gerenciamento de ativos de dados. A interface fornecida para usuários de negócios pode ter um conjunto diferente de requisitos funcionais do que
para usuários técnicos e desenvolvedores. Alguns relatórios facilitam o desenvolvimento futuro, como análise de impacto de alterações ou resolução
de problemas de definições variadas para projetos de data warehouse e Business Intelligence, como relatórios de linhagem de dados.
3. Ferramentas
A principal ferramenta usada para gerenciar Metadados é o repositório de Metadados. Isso incluirá uma camada de integração e, muitas vezes, uma
interface para atualizações manuais. Ferramentas que produzem e usam Metadados tornam-se fontes de Metadados que podem ser integradas em
um repositório de Metadados.
3.1 Ferramentas de gerenciamento de repositório de metadados
As ferramentas de gerenciamento de metadados fornecem recursos para gerenciar metadados em um local centralizado (repositório). Os metadados
podem ser inseridos manualmente ou extraídos de várias outras fontes por meio de conectores especializados. Os repositórios de metadados
também fornecem recursos para trocar metadados com outros sistemas.

As ferramentas de gerenciamento de metadados e os próprios repositórios também são uma fonte de Metadados, especialmente em um
modelo de arquitetura de Metadados híbrido ou em implementações de grandes empresas. As ferramentas de gerenciamento de
Metadados permitem a troca dos Metadados coletados com outros repositórios de Metadados, permitindo a coleta de vários e diversos
Metadados de diferentes fontes em um repositório centralizado, ou possibilitando o enriquecimento e padronização dos diversos
Metadados à medida que se movem entre os repositórios.
4. Técnicas
4.1 Linhagem de Dados e Análise de Impacto
Um dos principais benefícios de descobrir e documentar Metadados sobre os ativos físicos é fornecer informações sobre como os dados
são transformados à medida que se movem entre os sistemas. Muitas ferramentas de metadados carregam informações sobre o que
está acontecendo com os dados em seus ambientes e fornecem recursos para visualizar a linhagem em toda a extensão dos sistemas
ou aplicativos com os quais fazem interface. A versão atual da linhagem baseada no código de programação é chamada de 'Como
Linhagem Implementada'. Em contraste, a linhagem descrita nos documentos de especificação de mapeamento é chamada de 'Como
Linhagem Projetada'.
As limitações de uma construção de linhagem são baseadas na cobertura do sistema de gerenciamento de metadados. Repositórios de
metadados específicos de função ou ferramentas de visualização de dados têm informações sobre a linhagem de dados dentro do
escopo dos ambientes com os quais interagem, mas não fornecem visibilidade do que está acontecendo com os dados
fora de seus ambientes.
Os sistemas de gerenciamento de metadados importam a linhagem 'Como implementado' das várias ferramentas que podem fornecer
esse detalhe de linhagem e, em seguida, aumentam a linhagem de dados com o 'Como projetado' dos locais onde os detalhes reais da
implementação não podem ser extraídos. O processo de conectar as peças da linhagem de dados conhecido como costura. Isso resulta
em uma visualização holística dos dados à medida que se movem de seus locais originais (fonte oficial ou sistema de registro) até
chegarem ao seu destino final.
A Figura 89 mostra uma linhagem de elementos de dados de amostra. Ao ler isso, o elemento de dados de negócios 'Total Backorder',
que é fisicamente implementado como coluna zz_total, depende de 3 outros elementos de dados: 'Units Cost in Cents' fisicamente
implementado como 'yy_unit_cost', 'Tax in Ship to State' implementado em 'yy_tax' e 'Back Order Quantity' implementados em 'yy_qty'.
Embora um gráfico de linhagem, como na Figura 89, descreva o que está acontecendo com um determinado elemento de dados, nem
todos os usuários de negócios o entenderão. Níveis mais altos de linhagem (por exemplo, 'Linhagem do Sistema') resumem o movimento
no nível do sistema ou do aplicativo. Muitas ferramentas de visualização fornecem recursos de zoom-in/zoom-out, para mostrar a linhagem
do elemento de dados no contexto da linhagem do sistema. Por exemplo, a Figura 90 mostra uma linhagem de sistema de amostra,
onde, de relance, a movimentação geral de dados é compreendida e visualizada em um sistema ou em um nível de aplicativo.
442 • DMBOK2
*)Informações restritas
*)Atualizado semanalmente
*)Inclui pedidos cancelados *)Somente
pedidos nos EUA, para o exterior, consulte..
*) Steward : John Doe *) A
Custo unitário em centavos
moeda é dólares americanos
yy_unt_cost
Histórico de pedidos Pedido ativo Total de pedidos

Enviar para o Imposto no Estado de
zz_ord_tran_hist xx_cur_ord estado yy_state_cd Envio yy_tax pendentes zz_total
Pedido pendente
Quantidade
aa_qty
Figura 89 Diagrama de fluxo de linhagem do elemento de dados de amostra
Sistema 1 Sistema 3
Armazém
Sistema 2 Sistema 4
Figura 90 Diagrama de fluxo de linhagem do sistema de amostra
À medida que o número de elementos de dados em um sistema cresce, a descoberta da linhagem se torna complexa e difícil de
gerenciar. Para atingir com sucesso as metas de negócios, uma estratégia para descobrir e importar ativos para o repositório de
metadados requer planejamento e design. A descoberta de linhagem bem-sucedida precisa levar em conta ambos
foco comercial e técnico:
GESTÃO DE METADADOS • 443
• Foco nos negócios: Limite a descoberta da linhagem aos elementos de dados priorizados pela empresa. Comece a partir do
locais de destino e rastreie até os sistemas de origem de onde os dados específicos se originam. Ao limitar o
ativos digitalizados para aqueles que movem, transferem ou atualizam os elementos de dados selecionados, essa abordagem
permitir que os consumidores de dados de negócios entendam o que está acontecendo com o elemento de dados específico à medida que ele
move-se através de sistemas. Se acoplado a medições de qualidade de dados, a linhagem pode ser usada para identificar
onde o design do sistema afeta negativamente a qualidade dos dados.
• Foco técnico: comece nos sistemas de origem e identifique todos os consumidores imediatos, depois identifique todos
os consumidores subsequentes do primeiro conjunto identificados e continue repetindo essas etapas até que todos os sistemas sejam
identificado. Os usuários de tecnologia se beneficiam mais da estratégia de descoberta do sistema para ajudar a responder
as várias perguntas sobre os dados. Essa abordagem permitirá que os usuários de tecnologia e negócios
responder a perguntas sobre a descoberta de elementos de dados em toda a empresa, como “Onde está a segurança social?
número?" ou gerar relatórios de impacto como "Quais sistemas são afetados se a largura de uma coluna específica
Mudou?" Essa estratégia pode, no entanto, ser complexa de gerenciar.
Muitas ferramentas de integração de dados oferecem análise de linhagem que considera não apenas o código populacional desenvolvido, mas também o modelo
de dados e o banco de dados físico. Alguns oferecem interfaces web voltadas para usuários de negócios para monitorar e atualizar as definições. Estes começam a
parecer glossários de negócios.
A linhagem documentada ajuda o pessoal técnico e de negócios a usar os dados. Sem ele, muito tempo é desperdiçado na investigação de anomalias, possíveis
impactos de mudanças ou resultados desconhecidos. Procure implementar uma ferramenta integrada de impacto e linhagem que possa entender todas as partes
móveis envolvidas no processo de carregamento, bem como relatórios e análises do usuário final. Os relatórios de impacto descrevem quais componentes são
afetados por uma possível mudança, acelerando e simplificando as tarefas de estimativa e manutenção.
4.2 Metadados para ingestão de Big Data
Muitos profissionais de gerenciamento de dados estão familiarizados e confortáveis com armazenamentos de dados estruturados, onde cada item pode ser
claramente identificado e marcado. Hoje em dia, porém, muitos dados vêm em formatos menos estruturados. Algumas fontes não estruturadas serão internas à
organização e algumas serão externas. Em ambos os casos, não há mais a necessidade de trazer fisicamente os dados para um local. Por meio das novas
tecnologias, o programa irá para os dados em vez de mover os dados para o programa, reduzindo a quantidade de movimentação de dados e acelerando a execução
do processo. No entanto, o gerenciamento de dados bem-sucedido em um data lake depende do gerenciamento
Metadados.
As tags de metadados devem ser aplicadas aos dados após a ingestão. Os metadados podem ser usados para identificar o conteúdo de dados disponível para
acesso no data lake. Muitos mecanismos de ingestão perfilam dados à medida que são ingeridos. A criação de perfil de dados pode identificar domínios de dados,
relacionamentos e problemas de qualidade de dados. Ele também pode habilitar a marcação. Na ingestão, as tags de metadados podem ser adicionadas para
identificar dados confidenciais ou privados (como informações de identificação pessoal – PPI), por exemplo. Os cientistas de dados podem adicionar confiança,
identificadores textuais e códigos que representam clusters de comportamento. (Consulte o Capítulo 14.)
444 • DMBOK2
Implemente um ambiente de Metadados gerenciados em etapas incrementais para minimizar os riscos para a organização e facilitar a
aceitação. Implemente repositórios de metadados usando uma plataforma de banco de dados relacional aberta. Isso permite o
desenvolvimento e implementação de vários controles e interfaces que podem não ser previstos no início de um projeto de
desenvolvimento de repositório.
O conteúdo do repositório deve ser genérico em design, não apenas refletindo os designs de banco de dados do sistema de origem.
Projete o conteúdo em alinhamento com os especialistas da área de assunto da empresa e com base em um modelo abrangente de
Metadados. O planejamento deve levar em conta a integração de metadados para que os consumidores de dados possam ver em
diferentes fontes de dados. A capacidade de fazer isso será um dos recursos mais valiosos do repositório. Ele deve abrigar versões
atuais, planejadas e históricas dos metadados.
Muitas vezes, a primeira implementação é um piloto para provar conceitos e aprender sobre como gerenciar o ambiente de metadados.
A integração de projetos de Metadados na metodologia de desenvolvimento de TI é necessária. Haverá variações dependendo da
arquitetura e dos tipos de armazenamento.
Ter uma estratégia sólida de Metadados ajuda todos a tomar decisões mais eficazes. Em primeiro lugar, as pessoas devem estar
cientes dos riscos de não gerenciar Metadados. Avalie o grau em que a falta de metadados de alta qualidade pode resultar em:
• Erros de julgamento devido a suposições incorretas, incompletas ou inválidas ou falta de conhecimento sobre o
contexto dos dados
• Exposição de dados confidenciais, que podem colocar clientes ou funcionários em risco ou afetar a credibilidade de
o negócio e levar a despesas legais
• Risco de que o pequeno conjunto de PMEs que conhecem os dados saia e leve seu conhecimento com eles
O risco é reduzido quando uma organização adota uma estratégia sólida de Metadados. A prontidão organizacional é abordada por
uma avaliação formal da maturidade atual nas atividades de Metadados. A avaliação deve incluir os elementos críticos de dados de
negócios, glossários de metadados disponíveis, linhagem, perfis de dados e processos de qualidade de dados, maturidade de MDM
(Master Data Management) e outros aspectos. Os resultados da avaliação, alinhados com as prioridades de negócios, fornecerão a
base para uma abordagem estratégica para a melhoria das práticas de Gerenciamento de Metadados. Uma avaliação formal também
fornece a base para um caso de negócios, patrocínio e financiamento.
A estratégia de metadados pode fazer parte de uma estratégia geral de governança de dados ou pode ser a primeira etapa na
implementação de uma governança de dados eficaz. Uma avaliação de Metadados deve ser conduzida por meio de inspeção objetiva
dos Metadados existentes, juntamente com entrevistas com as principais partes interessadas. Os resultados de uma avaliação de risco
incluem uma estratégia e um roteiro.

5.2 Mudança Organizacional e Cultural
Como outros esforços de gerenciamento de dados, as iniciativas de metadados geralmente encontram resistência cultural. Mudar de um
ambiente de Metadados não gerenciado para um gerenciado exige trabalho e disciplina. Não é fácil de fazer, mesmo que a maioria das
pessoas reconheça o valor de Metadados confiáveis. A prontidão organizacional é uma grande preocupação, assim como os métodos de
governança e controle.
O gerenciamento de metadados é uma prioridade baixa em muitas organizações. Um conjunto essencial de Metadados precisa de coordenação
e comprometimento em uma organização. Podem ser estruturas de dados de identificação de funcionários, números de apólices de seguro,
números de identificação de veículos ou especificações de produtos que, se alterados, exigiriam grandes revisões de muitos sistemas
corporativos. Procure aquele bom exemplo em que o controle trará benefícios imediatos de qualidade para os dados da empresa. Construa o
argumento a partir de exemplos concretos relevantes para os negócios.
A implementação de uma estratégia de governança de dados corporativos precisa de suporte e envolvimento da alta administração. Requer
que a equipe de negócios e tecnologia seja capaz de trabalhar em conjunto de uma maneira multifuncional.
6. Governança de Metadados
As organizações devem determinar seus requisitos específicos para o gerenciamento do ciclo de vida de metadados e estabelecer processos
de governança para habilitar esses requisitos. Recomenda-se que funções e responsabilidades formais sejam atribuídas a recursos dedicados,
especialmente em áreas grandes ou críticas de negócios. Os próprios processos de governança de metadados dependem de Metadados
confiáveis, de modo que a equipe encarregada de gerenciar Metadados pode testar princípios nos Metadados que eles criam e usam.
6.1 Controles de Processo
A equipe de governança de dados deve ser responsável por definir os padrões e gerenciar mudanças de status para Metadados – geralmente
com fluxo de trabalho ou software de colaboração – e pode ser responsável por atividades promocionais e desenvolvimento de treinamento
ou treinamento real em toda a organização.
A governança de metadados mais madura exigirá que os termos e definições de negócios progridam por meio de várias mudanças de status
ou portas de governança; por exemplo, de um mandato candidato a aprovado, publicado e a um ponto final no ciclo de vida de substituído ou
aposentado. A equipe de governança também pode gerenciar associações de termos de negócios, como termos relacionados, bem como a
categorização e agrupamento dos termos.
A integração da estratégia de Metadados no SDLC é necessária para garantir que os Metadados alterados sejam coletados quando forem
alterados. Isso ajuda a garantir que os metadados permaneçam atualizados.

446 • DMBOK2
6.2 Documentação de Soluções de Metadados
Um catálogo mestre de Metadados incluirá as origens e destinos atualmente no escopo. Este é um recurso para usuários de TI e de negócios e pode
ser publicado para a comunidade de usuários como um guia para 'o que é onde' e para definir as expectativas sobre o que eles encontrarão:
• Status de implementação de metadados
• Origem e armazenamento de metadados de destino
• Agendar informações para atualizações
• Retenção e versões mantidas

• Conteúdo
• Declarações ou avisos de qualidade (por exemplo, valores ausentes)
• Sistema de registro e outros status da fonte de dados (por exemplo, cobertura do histórico de conteúdo de dados, aposentadoria ou
substituindo as bandeiras)
• Ferramentas, arquiteturas e pessoas envolvidas
• Informações confidenciais e estratégia de remoção ou mascaramento para a fonte
No gerenciamento de documentos e conteúdo, os mapas de dados mostram informações semelhantes. As visualizações do cenário geral dos
sistemas de integração de metadados também são mantidas como parte da documentação de metadados. (Consulte o Capítulo 9.)
6.3 Padrões e Diretrizes de Metadados
Padrões de metadados são essenciais na troca de dados com parceiros comerciais operacionais. As empresas percebem o valor do compartilhamento
de informações com clientes, fornecedores, parceiros e órgãos reguladores. A necessidade de compartilhar metadados comuns para suportar o uso
ideal de informações compartilhadas gerou muitos

padrões.
Adote padrões de metadados baseados no setor e sensíveis ao setor no início do ciclo de planejamento. Use os padrões para avaliar as tecnologias
de gerenciamento de metadados. Muitos fornecedores líderes oferecem suporte a vários padrões, e alguns podem ajudar na personalização de
padrões baseados no setor e sensíveis ao setor.
Os fornecedores de ferramentas fornecem suporte a XML e JSON ou REST para trocar dados para seus produtos de gerenciamento de dados.
Eles usam a mesma estratégia para unir suas ferramentas em conjuntos de soluções. Tecnologias, incluindo integração de dados, bancos de dados
relacionais e multidimensionais, gerenciamento de requisitos, relatórios de Business Intelligence, modelagem de dados e regras de negócios,
oferecem recursos de importação e exportação de dados e metadados usando XML. Os fornecedores mantêm seus esquemas XML proprietários e
definições de tipo de documento (DTD) ou, mais comumente, as definições de esquema XML (XSD). Estes são acessados através de interfaces
proprietárias. O desenvolvimento personalizado é necessário para integrar essas ferramentas em um ambiente de gerenciamento de metadados.
As diretrizes incluem modelos e exemplos associados e treinamento sobre entradas e atualizações esperadas, incluindo regras como 'não definir um
termo usando o termo' e declarações de integridade. Diferentes modelos são

desenvolvidos para diferentes tipos de Metadados e são conduzidos em parte pela solução de Metadados selecionada. O monitoramento
contínuo das diretrizes para eficácia e atualizações necessárias é uma responsabilidade da governança.
Os padrões ISO para Metadados fornecem orientação para desenvolvedores de ferramentas, mas é improvável que sejam uma preocupação
para organizações que implementam usando ferramentas comerciais, pois as ferramentas devem atender aos padrões. Independentemente
disso, pode ser útil ter uma boa compreensão desses padrões e suas repercussões.
6.4 Métricas
É difícil medir o impacto dos Metadados sem primeiro medir o impacto da falta de Metadados. Como parte da avaliação de risco, obtenha
métricas sobre a quantidade de tempo que os consumidores de dados gastam procurando informações, a fim de mostrar melhorias após a
implementação da solução de metadados. A eficácia da implementação de Metadados também pode ser medida em termos da completude
dos próprios Metadados, das rotinas de gerenciamento a ele associadas e do uso de Metadados. As métricas sugeridas em ambientes de
metadados incluem:
• Completude do repositório de metadados: compare a cobertura ideal dos metadados corporativos (todos os artefatos
e todas as instâncias dentro do escopo) para a cobertura real. Referencie a estratégia para definições de escopo.
• Maturidade de Gerenciamento de Metadados: Métricas desenvolvidas para julgar a maturidade de Metadados do
empresa, com base na abordagem Capability Maturity Model (CMM-DMM) para avaliação de maturidade.
• Representação de Steward: Compromisso organizacional com Metadados, conforme avaliado pela nomeação de
administradores, cobertura em toda a empresa para administração e documentação das funções no trabalho
descrições.
• Uso de metadados: a aceitação do usuário no uso do repositório de metadados pode ser medida pelo login do repositório
conta. A referência a metadados por usuários na prática de negócios é uma medida mais difícil de rastrear.
Medidas anedóticas em pesquisas qualitativas podem ser necessárias para capturar essa medida.
• Actividade do Glossário Empresarial: Utilização, actualização, resolução de definições, cobertura.
• Conformidade de dados do serviço Master Data: Mostra a reutilização de dados em soluções SOA. Metadados no
serviços de dados auxilia os desenvolvedores a decidir quando um novo desenvolvimento pode usar um serviço existente.
• Qualidade da documentação de metadados: Avalie a qualidade da documentação de metadados por meio de ambos
métodos automáticos e manuais. Os métodos automáticos incluem a execução de lógica de colisão em duas fontes,
medindo o quanto eles correspondem e a tendência ao longo do tempo. Outra métrica mediria a
porcentagem de atributos que têm definições, tendendo ao longo do tempo. Os métodos manuais incluem aleatório ou
pesquisa completa, com base nas definições de qualidade da empresa. As medidas de qualidade indicam a
integridade, confiabilidade, moeda, etc., dos Metadados no repositório.
• Disponibilidade do repositório de metadados: Uptime, tempo de processamento (lote e consulta).

448 • DMBOK2

AIKEN, Pedro. Engenharia Reversa de Dados: Matando o Dragão Legado. 1995.
Foreman, John W. Data Smart: Usando Data Science para Transformar Informação em Insight. Wiley, 2013. Impresso.
Loshin, David. Gestão do Conhecimento Empresarial: A Abordagem de Qualidade de Dados. Morgan Kaufmann, 2001.
Marco, Davi. Construindo e Gerenciando o Repositório de Metadados: Um Guia Completo do Ciclo de Vida. Wiley, 2000. Impresso.
Milton, Nicholas Ross. Aquisição de conhecimento na prática: um guia passo a passo. Springer, 2007. Impresso. Engenharia de Decisão.
Park, Jung-ran, ed. Melhores Práticas e Diretrizes de Metadados: Implementação Atual e Tendências Futuras. Routledge, 2014.
Imprimir.
Pomerantz, Jeffrey. Metadados. The MIT Press, 2015. Imprimir. O MIT Press Essential Knowledge ser.
Schneier, Bruce. Dados e Golias: as batalhas ocultas para coletar seus dados e controlar seu mundo. WW Norton e
Empresa, 2015. Impresso.
Tannenbaum, Adriana. Implementando um Repositório Corporativo: Os Modelos Encontram a Realidade. Wiley, 1994. Impresso.
Computação Profissional Wiley.
Diretor, Pete. Glossário de Big Data. O'Reilly Media, 2011. Impresso.
Zeng, Márcia Lei e Jian Qin. Metadados. 2ª edição. ASA Neal-Schuman, 2015. Print.
CAPÍTULO 1 3
Qualidade dos dados
Dados
Modelagem de dados
Qualidade dos dados
& Operações
Dados Dados
Metadados

& O negócio
Interoperabilidade
Inteligência
& Mestre & Contente
Dados Gestão

1. Introdução
gerenciamento eficaz de dados envolve um conjunto de processos complexos e inter-relacionados que permitem que uma organização
E usar seus dados para atingir objetivos estratégicos. O gerenciamento de dados inclui a capacidade de projetar dados para
aplicativos, armazená-los e acessá-los com segurança, compartilhá-los adequadamente, aprender com eles e garantir que atendam às
necessidades de negócios. Uma suposição subjacente às afirmações sobre o valor dos dados é que os dados em si são confiáveis e confiáveis.
Em outras palavras, que é de alta qualidade.
449
450 • DMBOK2
No entanto, muitos fatores podem minar essa suposição, contribuindo para dados de baixa qualidade: falta de compreensão sobre os efeitos
de dados de baixa qualidade no sucesso organizacional, planejamento ruim, design de sistema 'isolado', processos de desenvolvimento
inconsistentes, documentação incompleta, falta de padrões, ou falta de governança. Muitas organizações não conseguem definir o que torna
os dados adequados à finalidade.
Todas as disciplinas de gerenciamento de dados contribuem para a qualidade dos dados, e dados de alta qualidade que dão suporte à
organização devem ser o objetivo de todas as disciplinas de gerenciamento de dados. Como decisões ou ações desinformadas de qualquer
pessoa que interage com os dados podem resultar em dados de baixa qualidade, a produção de dados de alta qualidade requer compromisso
e coordenação multifuncional. Organizações e equipes devem estar cientes disso e devem planejar dados de alta qualidade, executando
processos e projetos de maneira que levem em conta o risco relacionado a condições inesperadas ou inaceitáveis nos dados.
Como nenhuma organização possui processos de negócios perfeitos, processos técnicos perfeitos ou práticas perfeitas de gerenciamento
de dados, todas as organizações enfrentam problemas relacionados à qualidade de seus dados. As organizações que gerenciam
formalmente a qualidade dos dados têm menos problemas do que aquelas que deixam a qualidade dos dados ao acaso.
O gerenciamento formal de qualidade de dados é semelhante ao gerenciamento contínuo de qualidade para outros produtos. Inclui o
gerenciamento de dados ao longo de seu ciclo de vida, definindo padrões, agregando qualidade aos processos que criam, transformam e
armazenam dados e medindo dados em relação aos padrões. Gerenciar dados até esse nível geralmente requer uma equipe do programa
Data Quality. A equipe do programa Data Quality é responsável por engajar profissionais de gerenciamento de dados técnicos e de negócios
e conduzir o trabalho de aplicação de técnicas de gerenciamento de qualidade aos dados para garantir que os dados sejam adequados
para consumo para diversas finalidades. A equipe provavelmente estará envolvida com uma série de projetos por meio dos quais eles
podem estabelecer processos e melhores práticas, ao mesmo tempo em que abordam as questões de alta prioridade.
problemas de dados.
Como o gerenciamento da qualidade dos dados envolve o gerenciamento do ciclo de vida dos dados, um programa de qualidade de dados
também terá responsabilidades operacionais relacionadas ao uso de dados. Por exemplo, relatar os níveis de qualidade dos dados e
participar da análise, quantificação e priorização de problemas de dados. A equipe também é responsável por trabalhar com aqueles que
precisam de dados para realizar seus trabalhos para garantir que os dados atendam às suas necessidades e trabalhar com aqueles que
criam, atualizam ou excluem dados no decorrer de seus trabalhos para garantir que estejam lidando adequadamente com os dados. A
qualidade dos dados depende de todos que interagem com os dados, não apenas dos profissionais de gerenciamento de dados.
Como é o caso da Governança de Dados e do gerenciamento de dados como um todo, o Data Quality Management é um programa, não
um projeto. Incluirá trabalho de projeto e manutenção, juntamente com um compromisso com comunicações e treinamento. Mais importante
ainda, o sucesso a longo prazo do programa de melhoria da qualidade de dados depende de fazer com que uma organização mude sua
cultura e adote uma mentalidade de qualidade. Conforme declarado no Manifesto de Dados do Líder: uma mudança fundamental e
duradoura requer liderança comprometida e envolvimento de pessoas em todos os níveis de uma organização. As pessoas que usam dados
para fazer seu trabalho – o que na maioria das organizações é uma porcentagem muito grande de funcionários – precisam impulsionar a
mudança. Uma das mudanças mais importantes para se concentrar é como suas organizações gerenciam e melhoram a qualidade de seus
dados.71
71 Para o texto completo do Manifesto de Dados do Líder, consulte http://bit.ly/2sQhcy7.

QUALIDADE DE DADOS • 451
Gerenciamento de qualidade de dados
Definição: O planejamento, implementação e controle das atividades que aplicam técnicas de gestão da qualidade aos dados, a fim de garantir que estejam aptos
ao consumo e atendam às necessidades dos consumidores de dados.
Objetivos:
1. Desenvolver uma abordagem governada para tornar os dados adequados à finalidade com base nos requisitos dos consumidores de dados.
2. Defina padrões, requisitos e especificações para controles de qualidade de dados como parte do ciclo de vida dos dados.
3. Definir e implementar processos para medir, monitorar e relatar os níveis de qualidade dos dados.
4. Identificar e defender oportunidades para melhorar a qualidade dos dados, por meio de melhorias de processos e sistemas.
O negócio
Motoristas

• Políticas de dados e 1. Definir dados de alta qualidade (P) •
Estratégia de qualidade de dados e
Padrões 2. Defina uma Estratégia de Qualidade de Dados (P) estrutura
• 3. Definir Escopo da Avaliação Inicial (P) •
Qualidade dos dados Programa de qualidade de dados
1. Identifique dados críticos
Expectativas organização
2. Identificar regras e padrões existentes •
• O negócio Análises de dados
4. Realizar Avaliação Inicial de Qualidade de Dados (P)
Perfil
Requisitos 1. Identifique e priorize problemas • Baseado em recomendações
• Regras do negócio 2. Realizar análise de causa raiz dos problemas
• 5. Identifique e priorize melhorias na análise de causa raiz de
Requisitos de dados
problemas
• Metadados de negócios 1. Priorize as ações com base no impacto nos negócios
2. Desenvolver ações preventivas e corretivas • Procedimentos DQM
• Metadados técnicos •
3. Confirme as ações planejadas Relatórios de qualidade de dados
• Fontes de dados e •
6. Desenvolver e implantar a qualidade dos dados Governança de qualidade de dados
Operações (D) Relatórios
• •
Linhagem de dados 1. Desenvolver procedimentos operacionais de qualidade de dados Nível de serviço de qualidade de dados
2. Corrigir Defeitos de Qualidade de Dados Contratos
3. Medir e monitorar a qualidade dos dados • Políticas de DQ e
4. Relatório sobre os níveis de qualidade de dados e descobertas Diretrizes
Fornecedores: Participantes: • CDO

Consumidores:
• • Consumidores de dados comerciais
Gestão de negócios
• • • Administradores de dados
Especialistas no assunto Analistas de qualidade de dados
• Arquitetos de dados • Administradores de dados • Profissionais de dados
• Modeladores de dados • Proprietários de dados • Profissionais de TI
• • •
Especialistas em sistemas Analistas de dados Trabalhadores de conhecimento
• Administradores de dados • Administradores de banco de dados • Órgãos de Governança de Dados
• • Profissionais de dados •
Analistas de processos de negócios Organizações parceiras
• Centros de Excelência
• Gerentes de DQ
•
Operações de TI
•
Arquitetos de Integração de Dados
• Equipe de Conformidade
Técnico
Motoristas
Ferramentas:
Métricas:
Técnicas:
• • Governança e
• Mecanismos de criação de perfil, ferramentas de consulta
Verificação pontual usando vários
• Métricas de conformidade
Subconjuntos Modelos de regras de qualidade de dados
•
• • Medição de qualidade de dados
Tags e notas para marcar dados Verificação de Qualidade e Código de Auditoria
Resultados
Problemas Módulos
• • Tendências de melhoria
Análise de causa raiz
• •
Controle Estatístico de Processo Métricas de gerenciamento de problemas
Figura 91 Diagrama de contexto: qualidade de dados

452 • DMBOK2
Os drivers de negócios para estabelecer um programa formal de gerenciamento de qualidade de dados incluem:
• Aumentar o valor dos dados organizacionais e as oportunidades de usá-los
• Redução de riscos e custos associados a dados de baixa qualidade
• Melhorar a eficiência e produtividade organizacional
• Proteger e melhorar a reputação da organização
As organizações que desejam obter valor de seus dados reconhecem que dados de alta qualidade são mais valiosos do que dados de baixa qualidade.
Dados de baixa qualidade são carregados de risco (ver Capítulo 1). Pode prejudicar a reputação de uma organização, resultando em multas, perda de
receita, perda de clientes e exposição negativa na mídia. Os requisitos regulamentares geralmente exigem dados de alta qualidade. Além disso, muitos
custos diretos estão associados a dados de baixa qualidade. Por exemplo,
• Incapacidade de faturar corretamente
• Aumento das chamadas de atendimento ao cliente e diminuição da capacidade de resolvê-las
• Perda de receita devido a oportunidades de negócios perdidas
• Atraso de integração durante fusões e aquisições
• Maior exposição a fraudes
• Perda devido a más decisões de negócios impulsionadas por dados incorretos
• Perda de negócios devido à falta de boa situação de crédito
Ainda assim, dados de alta qualidade não são um fim em si. É um meio para o sucesso organizacional. Dados confiáveis não apenas atenuam os riscos
e reduzem os custos, mas também melhoram a eficiência. Os funcionários podem responder a perguntas de forma mais rápida e consistente, quando
estão trabalhando com dados confiáveis. Eles gastam menos tempo tentando descobrir se os dados estão corretos e mais tempo usando os dados para
obter insights, tomar decisões e atender clientes.
Os programas de qualidade de dados se concentram nestes objetivos gerais:
• Desenvolver uma abordagem governada para tornar os dados adequados à finalidade com base nos requisitos dos consumidores de dados
• Definir padrões e especificações para controles de qualidade de dados como parte do ciclo de vida dos dados
• Definir e implementar processos para medir, monitorar e relatar os níveis de qualidade dos dados
• Identificar e defender oportunidades para melhorar a qualidade dos dados, por meio de mudanças nos
processos e sistemas e se engajar em atividades que melhoram de forma mensurável a qualidade dos dados com base em
requisitos do consumidor de dados
Os programas de qualidade de dados devem ser guiados pelos seguintes princípios:
• Criticidade: Um programa de qualidade de dados deve se concentrar nos dados mais críticos para a empresa e seus
clientes. As prioridades de melhoria devem ser baseadas na criticidade dos dados e no nível de
risco se os dados não estiverem corretos.
• Gerenciamento do ciclo de vida: A qualidade dos dados deve ser gerenciada em todo o ciclo de vida dos dados, desde
criação ou aquisição por meio de descarte. Isso inclui o gerenciamento de dados conforme eles se movem dentro e entre sistemas
(ou seja, cada link na cadeia de dados deve garantir que a saída de dados seja de alta qualidade).
• Prevenção: O foco de um programa de Qualidade de Dados deve ser a prevenção de erros de dados e condições que reduzam a
usabilidade dos dados; não deve se concentrar em simplesmente corrigir registros.
• Remediação da causa raiz: Melhorar a qualidade dos dados vai além da correção de erros. Os problemas com a qualidade dos
dados devem ser entendidos e tratados em suas causas-raiz, e não apenas em seus sintomas. Como essas causas geralmente
estão relacionadas ao projeto do processo ou do sistema, melhorar a qualidade dos dados geralmente requer mudanças nos
processos e nos sistemas que os suportam.
• Governança: As atividades de Governança de Dados devem apoiar o desenvolvimento de dados e dados de alta qualidade
As atividades do programa de qualidade devem apoiar e sustentar um ambiente de dados governado.
• Orientado por padrões: todas as partes interessadas no ciclo de vida dos dados têm requisitos de qualidade de dados. Na medida do
possível, esses requisitos devem ser definidos na forma de padrões e expectativas mensuráveis em relação aos quais a qualidade
dos dados pode ser medida.
• Medição objetiva e transparência: Os níveis de qualidade dos dados precisam ser medidos de forma objetiva e consistente. As
medições e a metodologia de medição devem ser compartilhadas com as partes interessadas, uma vez que são os árbitros da
qualidade.
• Incorporado em processos de negócios: os proprietários de processos de negócios são responsáveis pela qualidade dos
dados produzidos por meio de seus processos. Eles devem impor padrões de qualidade de dados em seus processos.
• Reforçado sistematicamente: Os proprietários do sistema devem aplicar sistematicamente os requisitos de qualidade de dados.
• Conectado aos níveis de serviço: relatórios de qualidade de dados e gerenciamento de problemas devem ser incorporados
em Acordos de Nível de Serviço (SLA).
1.3.1 Qualidade de Dados
O termo qualidade de dados refere-se tanto às características associadas a dados de alta qualidade quanto aos processos usados para medir
ou melhorar a qualidade dos dados. Esses usos duplos podem ser confusos, por isso ajuda a separá-los e esclarecer o que constitui dados de
alta qualidade.72
72 No DAMA-DMBOK2, tentamos evitar o uso das palavras qualidade de dados sem esclarecer seu contexto. Por exemplo, referindo-se a
dados de alta qualidade ou dados de baixa qualidade e a esforços de trabalho de qualidade de dados ou atividades de qualidade de dados.
454 • DMBOK2
Os dados são de alta qualidade na medida em que atendem às expectativas e necessidades dos consumidores de dados. Ou seja, se os
dados estão aptos para os fins a que pretendem aplicá-los. É de baixa qualidade se não for adequado para esses fins.
A qualidade dos dados depende, portanto, do contexto e das necessidades do consumidor de dados.
Um dos desafios na gestão da qualidade dos dados é que as expectativas relacionadas à qualidade nem sempre são conhecidas. Os
clientes podem não articulá-los. Muitas vezes, as pessoas que gerenciam os dados nem perguntam sobre esses requisitos. No entanto, para
que os dados sejam confiáveis e confiáveis, os profissionais de gerenciamento de dados precisam entender melhor os requisitos de qualidade
de seus clientes e como medi-los. Isso precisa ser uma discussão contínua, pois os requisitos mudam ao longo do tempo, à medida que as
necessidades de negócios e as forças externas evoluem.
1.3.2 Dados Críticos
A maioria das organizações tem muitos dados, nem todos de igual importância. Um princípio do Data Quality Management é concentrar os
esforços de melhoria nos dados mais importantes para a organização e seus clientes. Isso dá ao programa escopo e foco e permite que ele
tenha um impacto direto e mensurável na

necessidades de negócios.
Embora os fatores específicos de criticidade sejam diferentes de acordo com o setor, existem características comuns entre as organizações.
Os dados podem ser avaliados com base se são exigidos por:
• Relatórios regulamentares
• Relatório financeiro
• Política empresarial
• Operações em andamento
• Estratégia de negócios, especialmente esforços de diferenciação competitiva
Dados mestres são críticos por definição. Conjuntos de dados ou elementos de dados individuais podem ser avaliados quanto à criticidade
com base nos processos que os consomem, na natureza dos relatórios em que aparecem ou no risco financeiro, regulatório ou de reputação
para a organização se algo der errado com os dados. 73
1.3.3 Dimensões de Qualidade de Dados
Uma dimensão de qualidade de dados é um recurso ou característica mensurável dos dados. O termo dimensão é usado para fazer a
conexão com as dimensões na medição de objetos físicos (por exemplo, comprimento, largura, altura). As dimensões de qualidade de dados
fornecem um vocabulário para definir os requisitos de qualidade de dados. A partir daí, eles podem ser usados para definir os resultados da
avaliação inicial da qualidade dos dados, bem como a medição contínua. Para medir a qualidade dos dados, uma organização precisa
estabelecer características que sejam importantes para os processos de negócios (que vale a pena medir) e mensuráveis. As dimensões
fornecem uma base para regras mensuráveis, que devem estar diretamente conectadas a riscos potenciais em processos críticos.
73 Ver Jugulum (2014), Capítulos 6 e 7 para uma abordagem de racionalização de dados críticos.
Por exemplo, se os dados no campo de endereço de e-mail do cliente estiverem incompletos, não poderemos enviar informações do
produto aos nossos clientes por e-mail e perderemos vendas em potencial. Portanto, mediremos a porcentagem de clientes para os
quais temos endereços de e-mail utilizáveis e melhoraremos nossos processos até que
ter um endereço de e-mail utilizável para pelo menos 98% de nossos clientes.
Muitos pensadores líderes em qualidade de dados publicaram conjuntos de dimensões.74 As três mais influentes são descritas aqui
porque fornecem informações sobre como pensar sobre o que significa ter dados de alta qualidade, bem como sobre como a
qualidade dos dados pode ser medida.
A estrutura de Strong-Wang (1996) concentra-se nas percepções de dados dos consumidores de dados. Ele descreve 15 dimensões
em quatro categorias gerais de qualidade de dados:
• DQ Intrínseco
o Precisão
o Objetividade
o Credibilidade
o Reputação
• DQ contextual
o Valor agregado
o Relevância
o Pontualidade
o Completude
o Quantidade adequada de dados
• DQ Representacional
o Interpretabilidade
o Facilidade de compreensão
o Consistência representacional
o Representação concisa
• DQ de acessibilidade
o Acessibilidade
o Segurança de acesso
Em Data Quality for the Information Age (1996), Thomas Redman formulou um conjunto de dimensões de qualidade de dados
enraizadas na estrutura de dados.75 Redman define um item de dados como um “triplo representável”: um valor do domínio de um
atributo dentro de uma entidade. As dimensões podem ser associadas a qualquer uma das partes componentes dos dados – o
modelo (entidades e atributos), bem como os valores. Redman inclui a dimensão de representação, que ele define como um conjunto
de regras para registrar itens de dados. Dentro dessas três categorias gerais (modelo de dados, valores de dados, representação),
ele descreve mais de duas dúzias de dimensões. Eles incluem o seguinte:
74 Além dos exemplos detalhados aqui e vários artigos acadêmicos sobre este tópico, veja Loshin (2001), Olson (2003), McGilvray
(2008) e Sebastian-Coleman (2013) para discussões detalhadas sobre dimensões de qualidade de dados. Ver Myers (2013) para
uma comparação de dimensões.
75 Redman expandiu e revisou seu conjunto de dimensões em Data Quality: The Field Guide (2001).
456 • DMBOK2
Modelo de dados:
• Contente:
o Relevância dos dados
o A capacidade de obter os valores o

Clareza das definições
• Nível de detalhe:
o Atributo granularidade
o Precisão de domínios de atributos
• Composição: o
Naturalidade: A ideia de que cada atributo deve ter uma contrapartida simples no mundo real e que
cada atributo deve conter um único fato sobre a entidade o Capacidade de identificação: Cada
entidade deve ser distinguível de todas as outras o Homogeneidade o Redundância mínima necessária
• Consistência: o Consistência semântica dos componentes do modelo o Consistência da estrutura
dos atributos entre os tipos de entidade • Reação à mudança:
o Robustez
o Flexibilidade
Valores de dados:
• Precisão •
Integralidade •
Moeda • Consistência
Representação:
• Adequação •
Interpretabilidade •
Portabilidade •
Precisão de formato •
Flexibilidade de formato
• Capacidade de representar valores
nulos • Uso eficiente de armazenamento
• Instâncias físicas de dados de acordo com seus formatos
Redman reconhece que a consistência de entidades, valores e representação pode ser entendida em termos de
restrições. Diferentes tipos de consistência estão sujeitos a diferentes tipos de restrições.
Em Improving Data Warehouse and Business Information Quality (1999), Larry English apresenta um conjunto abrangente de dimensões
divididas em duas grandes categorias: inerentes e pragmáticas.76 As características inerentes são independentes do uso de dados. As
características pragmáticas estão associadas à apresentação dos dados e são dinâmicas; seu valor (qualidade) pode mudar dependendo do
uso dos dados.
• Características de qualidade inerentes

o Conformidade de definição
o Completude de valores
o Validade ou conformidade com a regra de negócios
o Precisão para uma fonte substituta
o Precisão à realidade
o Precisão
o Não duplicação
o Equivalência de dados redundantes ou distribuídos
o Simultaneidade de dados redundantes ou distribuídos
• Características de qualidade pragmáticas
o Acessibilidade
o Pontualidade
o Clareza contextual
o Usabilidade
o Integridade da derivação
o Correção ou completude dos fatos
Em 2013, a DAMA UK produziu um white paper descrevendo seis dimensões principais da qualidade de dados:
• Completude: A proporção de dados armazenados em relação ao potencial de 100%.
• Exclusividade: Nenhuma instância de entidade (coisa) será registrada mais de uma vez com base em como essa coisa é
identificado.
• Tempestividade: O grau em que os dados representam a realidade a partir do momento necessário.
• Validade: Os dados são válidos se estiverem de acordo com a sintaxe (formato, tipo, intervalo) de sua definição.
• Precisão: O grau em que os dados descrevem corretamente o objeto ou evento do 'mundo real' que está sendo
descrito.
• Consistência: A ausência de diferença, ao comparar duas ou mais representações de uma coisa
contra uma definição.
O white paper da DAMA UK também descreve outras características que têm impacto na qualidade. Embora o white paper não chame essas
dimensões, elas funcionam de maneira semelhante ao DQ contextual e representacional de Strong e Wang e às características pragmáticas
de English.
• Usabilidade: Os dados são compreensíveis, simples, relevantes, acessíveis, sustentáveis e no nível certo
de precisão?
76 English expandiu e revisou suas dimensões em Information Quality Applied (2009).

458 • DMBOK2
• Problemas de tempo (além da própria pontualidade): É estável, mas responde a solicitações de mudança legítimas?
• Flexibilidade: Os dados são comparáveis e compatíveis com outros dados? Tem agrupamentos úteis e
classificações? Pode ser reaproveitado? É fácil de manipular?
• Confiança: Os processos de Governança de Dados, Proteção de Dados e Segurança de Dados estão em vigor? O que é
reputação dos dados, e é verificado ou verificável?
• Valor: Existe uma boa relação custo/benefício para os dados? Está sendo usado de forma otimizada? Isso põe em perigo
segurança ou privacidade das pessoas, ou as responsabilidades legais da empresa? Apoia ou contradiz
a imagem corporativa ou a mensagem corporativa?
Embora não haja um conjunto único e acordado de dimensões de qualidade de dados, essas formulações contêm ideias comuns.
As dimensões incluem algumas características que podem ser medidas objetivamente (completude, validade, conformidade de formato) e
outras que dependem fortemente do contexto ou da interpretação subjetiva (usabilidade, confiabilidade, reputação). Quaisquer que sejam os
nomes usados, as dimensões se concentram em se há dados suficientes (completude), se estão corretos (precisão, validade), quão bem eles
se encaixam (consistência, integridade, singularidade), se estão atualizados (atualidade ), acessível, utilizável e seguro. A Tabela 29 contém
definições de um conjunto de dimensões de qualidade de dados, sobre as quais há concordância geral e descreve abordagens para medi-las.
Tabela 29 Dimensões comuns de qualidade de dados
Dimensão de Descrição
Qualidade
Precisão Precisão refere-se ao grau em que os dados representam corretamente as entidades da 'vida real'. A precisão é difícil de
medir, a menos que uma organização possa reproduzir a coleta de dados ou confirmar manualmente a precisão dos registros.
A maioria das medidas de precisão depende da comparação com uma fonte de dados que foi verificada como precisa, como
um sistema de registro ou dados de uma fonte confiável (por exemplo, dados de referência de Dun and Bradstreet).
Completude A completude refere-se à presença de todos os dados necessários. A completude pode ser medida no nível do conjunto de dados,
registro ou coluna. O conjunto de dados contém todos os registros esperados? Os registros estão preenchidos corretamente?
(Registros com status diferentes podem ter expectativas diferentes de completude.) As colunas/atributos são preenchidos
no nível esperado? (Algumas colunas são obrigatórias. As colunas opcionais são preenchidas apenas sob condições
específicas.) Atribua regras de integridade a um conjunto de dados com vários níveis de restrição: atributos obrigatórios que
exigem um valor, elementos de dados com valores condicionais e opcionais e valores de atributo inaplicáveis. As medições
do nível do conjunto de dados podem exigir comparação com uma fonte de registro ou podem ser baseadas em níveis
históricos da população.
Consistência A consistência pode se referir a garantir que os valores de dados sejam representados de forma consistente em um
conjunto de dados e entre conjuntos de dados e associados de forma consistente entre conjuntos de dados. Também pode
se referir ao tamanho e composição de conjuntos de dados entre sistemas ou ao longo do tempo. A consistência pode ser
definida entre um conjunto de valores de atributo e outro conjunto de atributos dentro do mesmo registro (consistência em
nível de registro), entre um conjunto de valores de atributo e outro conjunto de atributos em diferentes registros (consistência
entre registros) ou entre um conjunto de valores de atributo e o mesmo atributo definido dentro do mesmo registro em
diferentes pontos no tempo (consistência temporal). A consistência também pode ser usada para se referir à consistência do
formato. Tome cuidado para não confundir consistência com precisão ou correção.
As características que se espera que sejam consistentes dentro e entre conjuntos de dados podem ser usadas como
base para a padronização de dados. A padronização de dados refere-se ao condicionamento dos dados de entrada para
garantir que os dados atendam às regras de conteúdo e formato. A padronização de dados permite uma correspondência
mais eficaz e facilita a saída consistente. Encapsule restrições de consistência como um conjunto de regras que especificam
relacionamentos consistentes entre valores de atributos, seja em um registro ou mensagem, ou em todos os valores de um
único atributo (como um intervalo ou lista de valores válidos). Por exemplo, pode-se esperar que o número de transações por
dia não exceda 105% do número médio de transações em execução nos 30 dias anteriores.
Dimensão de Descrição
Qualidade
Integridade A integridade dos dados (ou coerência) inclui ideias associadas à integridade, precisão e consistência. Em dados,
integridade geralmente se refere à integridade referencial (consistência entre objetos de dados por meio de uma chave
de referência contida em ambos os objetos) ou consistência interna dentro de um conjunto de dados, de modo que não haja
lacunas ou partes ausentes. Conjuntos de dados sem integridade são vistos como corrompidos ou têm perda de dados.
Conjuntos de dados sem integridade referencial têm 'órfãos' – chaves de referência inválidas ou 'duplicados' – linhas idênticas
que podem afetar negativamente as funções de agregação. O nível de registros órfãos pode ser medido como uma contagem
bruta ou como uma porcentagem do conjunto de dados.
Razoabilidade A razoabilidade pergunta se um padrão de dados atende às expectativas. Por exemplo, se uma distribuição de vendas em uma área
geográfica faz sentido com base no que se sabe sobre os clientes dessa área. A medição da razoabilidade pode assumir
diferentes formas. Por exemplo, a razoabilidade pode ser baseada na comparação com dados de referência ou instâncias
anteriores de um conjunto de dados semelhante (por exemplo, vendas do trimestre anterior). Algumas ideias sobre razoabilidade
podem ser percebidas como subjetivas. Se for esse o caso, trabalhe com os consumidores de dados para articular a base de
suas expectativas de dados para formular comparações objetivas. Uma vez que as medidas de referência de razoabilidade
são estabelecidas, elas podem ser usadas para comparar objetivamente novas instâncias do mesmo conjunto de dados para
detectar mudanças. (Consulte a Seção 4.5.)
Pontualidade O conceito de pontualidade dos dados refere-se a várias características dos dados. As medidas de pontualidade precisam
ser entendidas em termos de volatilidade esperada – com que frequência os dados provavelmente mudarão e por quais
razões. A moeda dos dados é a medida de se os valores dos dados são a versão mais atualizada das informações. Dados
relativamente estáticos, por exemplo, alguns valores de Dados de Referência, como códigos de país, podem permanecer
atuais por um longo período. Os dados voláteis permanecem atuais por um curto período. Alguns dados, por exemplo, preços
de ações em páginas financeiras da web, muitas vezes serão mostrados com a data atual, para que os consumidores de
dados entendam o risco de que os dados tenham mudado desde que foram registrados. Durante o dia, enquanto os mercados
estiverem abertos, esses dados serão atualizados com frequência. Assim que os mercados fecharem, os dados permanecerão
inalterados, mas ainda serão atuais, já que o próprio mercado está inativo. A latência mede o tempo entre a criação dos dados
e a disponibilização para uso. Por exemplo, o processamento em lote noturno pode fornecer uma latência de 1 dia às 8h para
dados inseridos no sistema durante o dia anterior, mas apenas uma hora para dados gerados durante o processamento em
lote. (Consulte o Capítulo 8.)
Singularidade / A exclusividade afirma que nenhuma entidade existe mais de uma vez no conjunto de dados. Afirmar a exclusividade das
Desduplicação entidades dentro de um conjunto de dados implica que um valor de chave esteja relacionado a cada entidade única e somente
a essa entidade específica dentro do conjunto de dados. Meça a exclusividade testando a estrutura de chave. (Consulte o
Capítulo 5.)
Validade A validade refere-se a se os valores dos dados são consistentes com um domínio de valores definido. Um domínio de valores
pode ser um conjunto definido de valores válidos (como em uma tabela de referência), um intervalo de valores ou um valor que
pode ser determinado por meio de regras. O tipo de dados, formato e precisão dos valores esperados devem ser considerados
na definição do domínio. Os dados também podem ser válidos apenas por um período de tempo específico, por exemplo,
dados gerados a partir de RFID (ID de radiofrequência) ou alguns conjuntos de dados científicos. Valide os dados comparando-
os com as restrições de domínio. Lembre-se de que os dados podem ser válidos (ou seja, podem atender aos requisitos de
domínio) e ainda não serem precisos ou corretamente associados a registros específicos.
A Figura 92 alinha dimensões de qualidade de dados e conceitos associados a essas dimensões. As setas indicam sobreposições significativas
entre os conceitos e também demonstram que não há concordância em um conjunto específico. Por exemplo, a dimensão de precisão está
associada a 'concorda com o mundo real' e 'corresponde à fonte acordada' e também aos conceitos associados à validade, como 'derivação
correta'.
460 • DMBOK2
Dimensão Conceitos
Concorda com o mundo real
PRECISÃO
Corresponder à fonte acordada
Linha preenchida
Coluna preenchida
INTEGRIDADE
Tabela preenchida
Esquema preenchido
Equivalência de dados redundantes ou distribuídos
CONSISTÊNCIA
Consistência lógica
Simultaneidade de Dados Distribuídos
MOEDA Atual com o mundo
ID exclusivo da entidade
INTEGRIDADE DE DADOS Cardinalidade
Integridade Referencial de Dados
Precisão dos valores de dados
PRECISÃO
Dados suficientes para concluir uma determinada tarefa
Adesão aos controles

PRIVACIDADE
Consistência dentro da Tarefa Operacional
RAZOABILIDADE
Considerado como verdadeiro e credível
Expectativa de Disponibilidade
OPORTUNIDADE
Flutuador Manual e Eletrônico
Exclusividade do elemento com conjunto de dados
Exclusividade da entidade com conjunto de dados

SINGULARIDADE
Redundância Controlada
Controle de valores válidos
Derivação Correta
VALIDADE
Valores em conformidade com as regras de negócios
Os valores estão em conformidade com outras especificações de tipo de dados
Facilidade de obtenção de dados
Controle de acesso
ACESSIBILIDADE
Retenção
Figura 92 Relação entre dimensões de qualidade de dados 77
77 Adaptado de Myers (2013), usado com permissão.

1.3.4 Qualidade de Dados e Metadados
Os metadados são essenciais para gerenciar a qualidade dos dados. A qualidade dos dados é baseada em quão bem eles atendem aos
requisitos dos consumidores de dados. Os metadados definem o que os dados representam. Ter um processo robusto pelo qual os dados
são definidos suporta a capacidade de uma organização de formalizar e documentar os padrões e requisitos pelos quais a qualidade dos
dados pode ser medida. A qualidade dos dados é sobre atender às expectativas. Os metadados são um meio primário de esclarecer as
expectativas.
Metadados bem gerenciados também podem apoiar o esforço para melhorar a qualidade dos dados. Um repositório de metadados pode
armazenar resultados de medições de qualidade de dados para que sejam compartilhados em toda a organização e a equipe de qualidade
de dados possa trabalhar para chegar a um consenso sobre prioridades e fatores de melhoria. (Consulte o Capítulo 12.)
1.3.5 Padrão ISO de Qualidade de Dados
O ISO 8000, o padrão internacional para qualidade de dados, está sendo desenvolvido para permitir a troca de dados complexos em um
formato neutro para aplicativos. Na introdução ao padrão, a ISO afirma: “A capacidade de criar, coletar, armazenar, manter, transferir,
processar e apresentar dados para apoiar os processos de negócios de maneira oportuna e econômica requer tanto uma compreensão
das características dos dados que determinar sua qualidade e a capacidade de medir, gerenciar e relatar a qualidade dos dados”.
A ISO 8000 define características que podem ser testadas por qualquer organização na cadeia de fornecimento de dados para determinar
objetivamente a conformidade dos dados com a ISO 8000.78
A primeira parte publicada da ISO 8000 (parte 110, publicada em 2008) focou na sintaxe, codificação semântica e conformidade com
a especificação de dados de Dados Mestres. Outras peças projetadas para o padrão incluem parte 100 - Introdução, parte 120 -
Proveniência, parte 130 - Precisão e parte 140 - Completude.79
A ISO define dados de qualidade como “dados portáteis que atendem aos requisitos estabelecidos”.80 O padrão de qualidade de dados
está relacionado ao trabalho geral da ISO na portabilidade e preservação de dados. Os dados são considerados 'portáteis' se puderem
ser separados de um aplicativo de software. Os dados que só podem ser usados ou lidos usando um aplicativo de software licenciado
específico estão sujeitos aos termos da licença de software. Uma organização pode não conseguir usar os dados que criou
a menos que esses dados possam ser separados do software que foi usado para criá-los.
Para atender aos requisitos declarados, é necessário que esses requisitos sejam definidos de maneira clara e inequívoca. A ISO 8000 é
suportada pela ISO 22745, um padrão para definir e trocar dados mestres. A ISO 22745 define como as declarações de requisitos de
dados devem ser construídas, fornece exemplos em XML e define um formato para
78 http://bit.ly/2ttdiZJ.
79 http://bit.ly/2sANGdi.
80 http://bit.ly/2rV1oWC.
462 • DMBOK2
a troca de dados codificados.81 A ISO 22745 cria dados portáteis rotulando os dados usando um Dicionário Técnico Aberto compatível com ISO
22745, como o Dicionário Técnico Aberto ECCMA (eOTD).
A intenção da ISO 8000 é ajudar as organizações a definir o que é e o que não é dados de qualidade, permitir que solicitem dados de qualidade
usando convenções padrão e verifiquem se receberam dados de qualidade usando esses mesmos padrões. Quando os padrões são seguidos, os
requisitos podem ser confirmados por meio de um programa de computador.
ISO 8000 - Parte 61 O modelo de referência do processo de gerenciamento de qualidade de dados e informações está em desenvolvimento.82
Este padrão descreverá a estrutura e a organização do gerenciamento de qualidade de dados, incluindo:
• Planejamento de Qualidade de Dados
• Controle de Qualidade de Dados
• Garantia de qualidade de dados
• Melhoria da qualidade dos dados
1.3.6 Ciclo de Vida da Melhoria da Qualidade dos Dados
A maioria das abordagens para melhorar a qualidade dos dados é baseada nas técnicas de melhoria da qualidade na
fabricação de produtos físicos.83 Nesse paradigma, os dados são entendidos como o produto de um conjunto de processos. Na sua forma mais
simples, um processo é definido como uma série de etapas que transformam entradas em saídas. Um processo que cria dados pode consistir em uma
etapa (coleta de dados) ou várias etapas: coleta de dados, integração em um data warehouse, agregação em um data mart, etc. Em qualquer etapa,
os dados podem ser afetados negativamente. Eles podem ser coletados incorretamente, descartados ou duplicados entre sistemas, alinhados ou
agregados incorretamente, etc. Melhorar a qualidade dos dados requer a capacidade de avaliar a relação entre entradas e saídas, a fim de garantir
que as entradas atendam aos requisitos do processo e que as saídas estejam em conformidade às expectativas. Como as saídas de um processo se
tornam entradas para outros processos, os requisitos devem ser definidos ao longo de toda a cadeia de dados.
Uma abordagem geral para a melhoria da qualidade de dados, mostrada na Figura 93, é uma versão do ciclo Shewhart/Deming.
84
Baseado no método científico, o ciclo de Shewhart/Deming é um modelo de resolução de problemas conhecido como
'A planta faz o ato de verificação'. A melhoria vem através de um conjunto definido de etapas. A condição dos dados deve ser medida em relação aos
padrões e, se não atender aos padrões, a(s) causa(s) raiz da discrepância dos padrões deve(m) ser identificada(s) e corrigida(s). As causas-raiz
podem ser encontradas em qualquer uma das etapas do processo, técnicas ou não técnicas. Uma vez corrigidos, os dados devem ser monitorados
para garantir que continuem a atender aos requisitos.
81 http://bit.ly/2rUZyoz.
82 http://bit.ly/2sVik3Q.
83
Veja Wang (1998), Inglês (1999), Redman (2001), Loshin (2001) e McGilvray (2008). Ver Pierce (2004) para uma visão
geral da literatura relacionada ao conceito de dados como produto.
84
Veja American Society for Quality: http://bit.ly/1lelyBK Plan-Do-Check-Act foi originado por Walter Shewhart e popularizado
por W. Edwards Deming. 6 Sigma's Measure, Analyze, Improve, Control (DMAIC) é uma variação deste ciclo.
PLANO FAZ
AJA VERIFICA
Figura 93 O Gráfico de Shewhart
Para um determinado conjunto de dados, um ciclo de gerenciamento de qualidade de dados começa identificando os dados que não atendem aos
requisitos dos consumidores de dados e os problemas de dados que são obstáculos para a realização dos objetivos de negócios. Os dados precisam
ser avaliados em relação às principais dimensões de qualidade e requisitos de negócios conhecidos. Causas raiz dos problemas
precisarão ser identificados para que as partes interessadas possam compreender os custos de remediação e os riscos de não
remediando os problemas. Esse trabalho geralmente é feito em conjunto com os Data Stewards e outras partes interessadas.
No estágio de planejamento , a equipe de qualidade de dados avalia o escopo, o impacto e a prioridade dos problemas conhecidos e avalia
alternativas para resolvê-los. Esse plano deve ser baseado em uma base sólida de análise das causas-raiz dos problemas. A partir do conhecimento
das causas e do impacto dos problemas, pode-se entender o custo/benefício, determinar a prioridade e formular um plano básico para abordá-los.
No estágio Do , a equipe DQ lidera os esforços para abordar as causas-raiz dos problemas e planejar o monitoramento contínuo dos dados. Para
causas raiz baseadas em processos não técnicos, a equipe de DQ pode trabalhar com proprietários de processos para implementar mudanças. Para
causas raiz que exigem alterações técnicas, a equipe de DQ deve trabalhar com equipes técnicas para garantir que os requisitos sejam implementados
corretamente e que as alterações técnicas não introduzam erros.
O estágio de verificação envolve o monitoramento ativo da qualidade dos dados medidos em relação aos requisitos. Desde que os dados atendam
aos limites definidos de qualidade, não são necessárias ações adicionais. Os processos serão considerados sob controle e atendendo aos requisitos
do negócio. No entanto, se os dados ficarem abaixo dos limites de qualidade aceitáveis, ações adicionais devem ser tomadas para trazê-los a níveis
aceitáveis.
O estágio Act é para atividades para abordar e resolver problemas emergentes de qualidade de dados. O ciclo recomeça, à medida que as causas
dos problemas são avaliadas e as soluções propostas. A melhoria contínua é alcançada iniciando um novo ciclo. Novos ciclos começam como:
• As medições existentes ficam abaixo dos limites
• Novos conjuntos de dados estão sob investigação
• Surgem novos requisitos de qualidade de dados para conjuntos de dados existentes
• Mudanças nas regras, padrões ou expectativas de negócios

464 • DMBOK2
O custo de obter dados corretos na primeira vez é mais barato do que os custos de obter dados errados e corrigi-los mais tarde.
Construir qualidade nos processos de gerenciamento de dados desde o início custa menos do que modernizá-los.
Manter dados de alta qualidade durante todo o ciclo de vida dos dados é menos arriscado do que tentar melhorar a qualidade em um processo
existente. Também cria um impacto muito menor na organização. Estabelecer critérios de qualidade de dados no início de um processo ou
construção de sistema é um sinal de uma Organização de Gerenciamento de Dados madura. Fazer isso exige governança e disciplina, bem como
colaboração multifuncional.
1.3.7 Tipos de Regras de Negócios de Qualidade de Dados
As regras de negócios descrevem como os negócios devem operar internamente, a fim de serem bem-sucedidos e compatíveis com o mundo
exterior. As regras de negócios de qualidade de dados descrevem como os dados devem existir para serem úteis e utilizáveis em uma organização.
Essas regras podem ser alinhadas com dimensões de qualidade e usadas para descrever os requisitos de qualidade de dados. Por exemplo, uma
regra comercial de que todos os campos de código de estado devem estar em conformidade com as abreviações de estado dos EUA pode ser
imposta por listas de seleção de entrada de dados e pesquisas de integração de dados. O nível de válido ou inválido
registros podem então ser medidos.
Regras de negócios são comumente implementadas em software ou usando modelos de documentos para entrada de dados. Alguns tipos comuns
de regras de negócios simples são:
• Conformidade de definição: Confirme se o mesmo entendimento das definições de dados é implementado
e usado adequadamente em processos em toda a organização. A confirmação inclui acordo algorítmico
em campos calculados, incluindo a qualquer momento, ou restrições locais, e interdependência de rollup e status
as regras.
• Presença de valor e integridade de registro: regras que definem as condições sob as quais valores ausentes
são aceitáveis ou inaceitáveis.
• Conformidade de formato: um ou mais padrões especificam valores atribuídos a um elemento de dados, como
padrões para formatação de números de telefone.
• Associação de domínio de valor: especifique que o valor atribuído de um elemento de dados está incluído naqueles
enumerados em um domínio de valor de dados definido, como códigos postais dos Estados Unidos de 2 caracteres para um
campo ESTADO.
• Conformidade de intervalo: um valor atribuído a um elemento de dados deve estar dentro de um valor numérico, lexicográfico,
ou intervalo de tempo, como maior que 0 e menor que 100 para um intervalo numérico.
• Conformidade do mapeamento: Indicando que o valor atribuído a um elemento de dados deve corresponder a um
selecionado de um domínio de valor que mapeia para outro(s) domínio(s) de valor correspondente equivalente(s). o
O domínio de dados STATE novamente fornece um bom exemplo, pois os valores de estado podem ser representados usando
diferentes domínios de valor (códigos postais do USPS, códigos FIPS de 2 dígitos, nomes completos) e esses tipos de regras
valide que 'AL' e '01' mapeiam para 'Alabama'.

• Regras de consistência: asserções condicionais que se referem à manutenção de um relacionamento entre dois (ou
mais) atributos com base nos valores reais desses atributos. Por exemplo, validação de endereço onde
códigos postais correspondem a determinados Estados ou Províncias.
• Verificação de precisão: compare um valor de dados com um valor correspondente em um sistema de registro ou
outra fonte verificada (por exemplo, dados de marketing adquiridos de um fornecedor) para verificar se os valores correspondem.
• Verificação de exclusividade: regras que especificam quais entidades devem ter uma representação única e
se existe um e apenas um registro para cada objeto do mundo real representado.
• Validação de pontualidade: Regras que indicam as características associadas às expectativas de
acessibilidade e disponibilidade de dados.
Outros tipos de regras podem envolver funções de agregação aplicadas a conjuntos de instâncias de dados (consulte a Seção 4.5).
Exemplos de verificações de agregação incluem:
• Validar a razoabilidade do número de registros em um arquivo. Isso requer manter estatísticas ao longo do tempo para
gerar tendências.
• Validar a razoabilidade de um valor médio calculado a partir de um conjunto de transações. Isto exige
estabelecendo limites para comparação, e pode ser baseado em estatísticas ao longo do tempo.
• Valide a variação esperada na contagem de transações em um período de tempo especificado. Isto exige
manter estatísticas ao longo do tempo e usá-las para estabelecer limites.
1.3.8 Causas comuns de problemas de qualidade de dados
Problemas de qualidade de dados podem surgir em qualquer ponto do ciclo de vida dos dados, desde a criação até o descarte. Ao investigar as
causas-raiz, os analistas devem procurar possíveis culpados, como problemas com entrada de dados, processamento de dados, design do
sistema e intervenção manual em processos automatizados. Muitos problemas terão múltiplas causas e fatores contribuintes (especialmente se
as pessoas criaram maneiras de contorná-los). Essas causas de problemas também implicam em maneiras de evitar problemas: por meio de
melhorias no design de interface, teste de regras de qualidade de dados como parte do processamento, foco na qualidade de dados no design
do sistema e controles rigorosos sobre intervenção manual em processos automatizados.
1.3.8.1 Problemas Causados pela Falta de Liderança
Muitas pessoas assumem que a maioria dos problemas de qualidade de dados é causada por erros de entrada de dados. Uma compreensão
mais sofisticada reconhece que lacunas ou má execução de processos técnicos e de negócios causam muito mais problemas do que erros de
digitação. No entanto, o senso comum diz e as pesquisas indicam que muitos problemas de qualidade de dados são causados pela falta de
compromisso organizacional com dados de alta qualidade, que decorre da falta de liderança, tanto na forma de governança quanto na gestão.
466 • DMBOK2
Toda organização possui informações e ativos de dados que são valiosos para suas operações. De fato, as operações de cada organização dependem da
capacidade de compartilhar informações. Apesar disso, poucas organizações gerenciam esses ativos com rigor. Na maioria das organizações, a disparidade
de dados (diferenças na estrutura de dados, formato e uso de valores) é um problema maior do que apenas erros simples; pode ser um grande obstáculo
para a integração de dados. Uma das razões pelas quais os programas de administração de dados se concentram na definição de termos e na consolidação
da linguagem em torno dos dados é porque esse é o ponto de partida para obter dados mais consistentes.
Muitos programas de governança e ativos de informações são orientados exclusivamente pela conformidade, e não pelo valor potencial a ser derivado dos
dados como ativos. A falta de reconhecimento por parte da liderança significa uma falta de compromisso dentro de uma organização para gerenciar os
dados como um ativo, incluindo o gerenciamento de sua qualidade (Evans e
Preço, 2012). (Veja a Figura 94.)
As barreiras para o gerenciamento eficaz da qualidade dos dados incluem:85
• Falta de conscientização por parte da liderança e da equipe
• Falta de governança empresarial
• Falta de liderança e gestão
• Dificuldade na justificativa de melhorias
• Instrumentos inadequados ou ineficazes para medir valor
Essas barreiras têm efeitos negativos na experiência do cliente, produtividade, moral, eficácia organizacional, receita e vantagem competitiva. Eles
aumentam os custos de administração da organização e também introduzem riscos. (Consulte o Capítulo 11.)
1.3.8.2 Problemas causados por processos de entrada de dados
• Problemas de interface de entrada de dados: interfaces de entrada de dados mal projetadas podem contribuir para a qualidade dos dados
questões. Se uma interface de entrada de dados não tiver edições ou controles para evitar que dados incorretos sejam colocados
nos processadores de dados do sistema provavelmente tomarão atalhos, como pular campos não obrigatórios e
falha ao atualizar os campos padrão.
• Posicionamento de entrada de lista: Mesmo recursos simples de interfaces de entrada de dados, como a ordem de valores dentro
uma lista suspensa, pode contribuir para erros de entrada de dados.
• Sobrecarga de campo: algumas organizações reutilizam os campos ao longo do tempo para diferentes propósitos de negócios, em vez de
do que fazer alterações no modelo de dados e na interface do usuário. Essa prática resulta em resultados inconsistentes e
população confusa dos campos.
• Problemas de treinamento: a falta de conhecimento do processo pode levar à entrada incorreta de dados, mesmo se houver controles e edições
Estão no lugar. Se os processadores de dados não estiverem cientes do impacto de dados incorretos ou se forem incentivados a
velocidade, em vez de precisão, é provável que eles façam escolhas com base em drivers que não sejam a qualidade do
os dados.
85 Adaptado do Manifesto de Dados do Líder. https://dataleaders.org/.

Falta de negócios Dificuldade em

Governança Justificação
Os mercados não exigem

Falta de responsabilidade
eles fazem isso
Falta de propriedade O custo de gerenciamento de ativos de

informação não é compreendido
Não está claro quem é

O valor dos dados depende do
responsável pelo que
contexto e é difícil de definir
Cliente
Falta medição para Os benefícios são difíceis de obter
Experiência
guiar ação
Os Business Cases não criam um

Organização
senso de urgência Alacridade
Não receita
Falta de Educação Em formação

terciária Ativos não Competitivo
Conhecimento
Vantagem
• Executivo Meio-dia Devidamente
• Praticante educação
Gerenciou
Produtividade
para o trabalho Não sei como colocar a
informação para trabalhar
As ferramentas de gestão da Custos
informação não são compreendidas
Falta a capacidade de fazer o trabalho
Deixar de investir em qualidade, agregando Risco
A linguagem é imprecisa
custos e complicando esforços para usar dados • Continuidade
Cultura inadequada (por exemplo, intuição Software visto como uma panacéia/ • Observância
valorizada sobre os “fatos”, informação não confusão sobre TI versus dados • Descoberta
valorizada como ativo)
• Segurança
Estrutura inadequada (por exemplo, silos impedem Os princípios contábeis não
o compartilhamento) permitem a capitalização de ativos
Confuso sobre “quem faz o quê” de informação
Falta liderança pró-ativa.

Falta: Falta o equivalente ao GAAP
• Visão
• Estratégia
• Política
• Princípios Orientadores
Falta de
• Sistema de gestão Inapropriado ou
Liderança e
ineficaz
Gestão
Instrumentos
© 2017 dataleaders.org
Usado com permissão
Barreiras que retardam/impedem/

impedem que as empresas gerenciem
suas informações como um ativo de negócios
Causas raiz mais comumente observadas
Danette McGilvray/James Price/Tom Redman
Outubro de 2016
Trabalho baseado na pesquisa da Dra. Nina Evans e James Price, veja

“Barriers to the Effective Deployment of Information Assets” em
www.dataleaders.org
Figura 94 Barreiras ao gerenciamento de informações como um ativo de negócios 86
• Mudanças nos processos de negócios: Os processos de negócios mudam com o tempo e, com essas mudanças, novos
regras de negócios e requisitos de qualidade de dados são introduzidos. No entanto, as mudanças nas regras de negócios não são
sempre incorporados aos sistemas de maneira oportuna ou abrangente. Ocorrerão erros de dados se um
interface não é atualizada para acomodar requisitos novos ou alterados. Além disso, os dados provavelmente
ser impactado, a menos que as mudanças nas regras de negócios sejam propagadas por todo o sistema.
86 Diagrama desenvolvido por Danette McGilvray, James Price e Tom Redman. Usado com permissão. https://dataleaders.org/.
468 • DMBOK2
• Execução inconsistente de processos de negócios: Os dados criados por meio de processos executados de forma
inconsistente provavelmente serão inconsistentes. A execução inconsistente pode ser devido a problemas de
treinamento ou documentação, bem como a mudanças nos requisitos.
1.3.8.3 Problemas causados por funções de processamento de dados
• Suposições incorretas sobre fontes de dados: problemas de produção podem ocorrer devido a erros ou alterações,
documentação do sistema inadequada ou obsoleta, ou transferência de conhecimento inadequada (por exemplo, quando as PMEs
saem sem documentar seu conhecimento). As atividades de consolidação de sistemas, como aquelas associadas a fusões e
aquisições, geralmente são baseadas em conhecimento limitado sobre o relacionamento entre sistemas. Quando vários sistemas
de origem e feeds de dados precisam ser integrados, sempre há o risco de que os detalhes sejam perdidos, especialmente com
níveis variados de conhecimento de origem disponíveis e limitados

Linhas do tempo.
• Regras de negócios obsoletas: com o tempo, as regras de negócios mudam. Devem ser revistos periodicamente e
Atualizada. Se houver medição automatizada de regras, o processo técnico de medição de regras também deve ser atualizado. Se
não for atualizado, os problemas podem não ser identificados ou falsos positivos serão produzidos (ou ambos).
• Estruturas de dados alteradas: os sistemas de origem podem alterar as estruturas sem informar a jusante
consumidores (tanto humanos quanto de sistema) ou sem fornecer tempo suficiente para contabilizar as mudanças.
Isso pode resultar em valores inválidos ou outras condições que impedem a movimentação e o carregamento de dados, ou em
alterações mais sutis que podem não ser detectadas imediatamente.
1.3.8.4 Problemas causados pelo design do sistema
• Falha ao impor integridade referencial: A integridade referencial é necessária para garantir dados de alta qualidade em um aplicativo
ou nível de sistema. Se a integridade referencial não for aplicada ou se a validação for desativada (por exemplo, para melhorar os
tempos de resposta), vários problemas de qualidade de dados podem surgir:
o Dados duplicados que quebram as regras de exclusividade
o Linhas órfãs, que podem ser incluídas em alguns relatórios e excluídas de outros, levando a vários valores para o mesmo
cálculo
o Incapacidade de atualizar devido a requisitos de integridade referencial restaurados ou alterados o Dados
imprecisos devido a dados ausentes sendo atribuídos a valores padrão
• Falha ao impor restrições de exclusividade: várias cópias de instâncias de dados em uma tabela ou arquivo
espera-se que contenha instâncias únicas. Se não houver verificações suficientes para exclusividade de instâncias ou se as
restrições exclusivas estiverem desativadas no banco de dados para melhorar o desempenho, os resultados da agregação de dados
pode ser exagerada.
• Imprecisões e lacunas de codificação: se o mapeamento ou layout de dados estiver incorreto ou as regras de processamento
os dados não forem precisos, os dados processados terão problemas de qualidade de dados, variando de dados incorretos
cálculos para dados atribuídos ou vinculados a campos, chaves ou relacionamentos impróprios.
• Imprecisões do modelo de dados: se as suposições no modelo de dados não forem suportadas pelos dados reais,
haverá problemas de qualidade de dados que variam de perda de dados devido a comprimentos de campo serem excedidos pelo
dados reais, a dados atribuídos a IDs ou chaves impróprias.
• Sobrecarga de campo: reutilização de campos ao longo do tempo para diferentes finalidades, em vez de alterar os dados
modelo ou código pode resultar em conjuntos confusos de valores, significado pouco claro e, potencialmente,
problemas, como teclas atribuídas incorretamente.
• Incompatibilidades de dados temporais: na ausência de um dicionário de dados consolidado, vários sistemas podem
implementar formatos de data ou horários diferentes, que por sua vez levam a incompatibilidade de dados e perda de dados quando
a sincronização de dados ocorre entre diferentes sistemas de origem.
• Gerenciamento de dados mestre fraco: o gerenciamento de dados mestre imaturo pode levar à escolha
fontes não confiáveis de dados, o que pode causar problemas de qualidade de dados que são muito difíceis de encontrar até que o
suposição de que a fonte de dados é precisa é refutada.
• Duplicação de dados: a duplicação desnecessária de dados geralmente é resultado de um mau gerenciamento de dados. Há
dois tipos principais de problemas de duplicação indesejáveis:
o Fonte única – várias instâncias locais: por exemplo, instâncias do mesmo cliente em
várias tabelas (semelhantes ou idênticas) no mesmo banco de dados. Saber qual é a instância
mais preciso para uso pode ser difícil sem conhecimento específico do sistema.
o Fontes múltiplas – Instância única: instâncias de dados com múltiplas fontes autorizadas ou
sistemas de registro. Por exemplo, instâncias de cliente único provenientes de vários pontos de venda
sistemas. Ao processar esses dados para uso, pode haver áreas de armazenamento temporário duplicadas.
As regras de mesclagem determinam qual fonte tem prioridade sobre outras ao processar em permanente
áreas de dados de produção.
1.3.8.5 Problemas causados pela correção de problemas
Os patches de dados manuais são alterações feitas diretamente nos dados do banco de dados, não por meio das regras de negócios nas interfaces
ou no processamento do aplicativo. Esses são scripts ou comandos manuais geralmente criados às pressas e usados para 'consertar' dados em uma
emergência, como injeção intencional de dados incorretos, lapso de segurança, fraude interna ou fonte externa para interrupção de negócios.
Como qualquer código não testado, eles têm um alto risco de causar mais erros por meio de consequências não intencionais, alterando mais dados
do que o necessário ou não propagando o patch para todos os dados históricos afetados pelo problema original. A maioria desses patches também
altera os dados no local, em vez de preservar o estado anterior e adicionar

linhas corrigidas.
470 • DMBOK2
Essas alterações geralmente NÃO podem ser desfeitas sem uma restauração completa do backup, pois há apenas o log do banco de dados para mostrar
as alterações. Portanto, esses atalhos são fortemente desencorajados – eles são oportunidades para violações de segurança e interrupção de negócios
por mais tempo do que uma correção adequada poderia causar. Todas as mudanças devem passar por um processo de gerenciamento de mudanças
governado.
1.3.9 Perfil de Dados
A criação de perfil de dados é uma forma de análise de dados usada para inspecionar dados e avaliar a qualidade. O perfil de dados usa técnicas
estatísticas para descobrir a verdadeira estrutura, conteúdo e qualidade de uma coleção de dados (Olson, 2003). Um mecanismo de criação de perfil
produz estatísticas que os analistas podem usar para identificar padrões no conteúdo e na estrutura dos dados. Por exemplo:
• Contagens de nulos: identifica a existência de nulos e permite a inspeção se eles são permitidos ou não
• Valor máx./mín.: identifica valores discrepantes, como negativos
• Comprimento máx./mín.: Identifica valores discrepantes ou inválidos para campos com requisitos de comprimento específicos
• Distribuição de frequência de valores para colunas individuais: permite a avaliação da razoabilidade (por exemplo,
distribuição de códigos de país para transações, inspeção de valores que ocorrem com frequência ou não,
bem como a porcentagem dos registros preenchidos com valores padrão)
• Tipo e formato de dados: Identifica o nível de não conformidade com os requisitos de formato, bem como
identificação de formatos inesperados (por exemplo, número de casas decimais, espaços incorporados, valores de amostra)
A criação de perfil também inclui análise de coluna cruzada, que pode identificar colunas sobrepostas ou duplicadas e expor dependências de valores
incorporados. A análise entre tabelas explora conjuntos de valores sobrepostos e ajuda a identificar relacionamentos de chave estrangeira. A maioria das
ferramentas de perfil de dados permite detalhar os dados analisados para investigação adicional.
Os resultados do mecanismo de criação de perfil devem ser avaliados por um analista para determinar se os dados estão em conformidade com as
regras e outros requisitos. Um bom analista pode usar os resultados de criação de perfil para confirmar relacionamentos conhecidos e descobrir
características e padrões ocultos dentro e entre conjuntos de dados, incluindo regras de negócios e restrições de validade. A criação de perfil geralmente
é usada como parte da descoberta de dados para projetos (especialmente projetos de integração de dados; consulte o Capítulo 8) ou para avaliar o
estado atual dos dados que devem ser aprimorados. Os resultados do perfil de dados podem ser usados para identificar oportunidades para melhorar a
qualidade dos dados e dos metadados (Olson, 2003; Maydanchik, 2007).
Embora a criação de perfil seja uma maneira eficaz de entender os dados, é apenas o primeiro passo para a melhoria da qualidade dos dados. Ele
permite que as organizações identifiquem problemas potenciais. A solução de problemas requer outras formas de análise, incluindo análise de processos
de negócios, análise de linhagem de dados e análise de dados mais profunda que pode ajudar a isolar a raiz
causas dos problemas.
1.3.10 Qualidade de Dados e Processamento de Dados
Embora o foco dos esforços de melhoria da qualidade dos dados seja frequentemente a prevenção de erros, a qualidade dos dados também pode ser
melhorada por meio de algumas formas de processamento de dados. (Consulte o Capítulo 8.)
1.3.10.1 Limpeza de dados
A limpeza ou depuração de dados transforma os dados para torná-los compatíveis com os padrões de dados e as regras de domínio. A limpeza
inclui detectar e corrigir erros de dados para trazer a qualidade dos dados a um nível aceitável.
Custa dinheiro e apresenta risco para corrigir continuamente os dados por meio de limpeza. Idealmente, a necessidade de limpeza de dados deve
diminuir com o tempo, à medida que as causas principais dos problemas de dados são resolvidas. A necessidade de limpeza de dados pode ser
abordada por:
• Implementação de controles para evitar erros de entrada de dados
• Corrigindo os dados no sistema de origem
• Melhorar os processos de negócios que criam os dados
Em algumas situações, a correção contínua pode ser necessária, pois o reprocessamento dos dados em um sistema intermediário é mais barato do
que qualquer outra alternativa.
1.3.10.2 Aprimoramento de Dados
Aprimoramento ou enriquecimento de dados é o processo de adicionar atributos a um conjunto de dados para aumentar sua qualidade e usabilidade.
Alguns aprimoramentos são obtidos pela integração de conjuntos de dados internos a uma organização. Os dados externos também podem ser
adquiridos para aprimorar os dados organizacionais (consulte o Capítulo 10). Exemplos de aprimoramento de dados incluem:
• Carimbos de data/hora: Uma maneira de melhorar os dados é documentar a hora e a data em que os itens de dados são
criado, modificado ou retirado, o que pode ajudar a rastrear eventos de dados históricos. Se forem detectados problemas com
os dados, os carimbos de data/hora podem ser muito valiosos na análise de causa raiz, porque permitem que os analistas isolem
o prazo da questão.
• Dados de auditoria: a auditoria pode documentar a linhagem de dados, o que é importante para o rastreamento histórico, bem como
validação.
• Vocabulários de referência: terminologia, ontologias e glossários específicos de negócios aprimoram
compreensão e controle, trazendo contexto de negócios personalizado.
• Informações contextuais: Adicionando contexto, como localização, ambiente ou métodos de acesso e
marcação de dados para revisão e análise.
• Informações geográficas: as informações geográficas podem ser aprimoradas por meio da padronização de endereços
e geocodificação, que inclui codificação regional, município, mapeamento de bairro, latitude/
pares de longitude ou outros tipos de dados baseados em localização.
• Informações demográficas: os dados do cliente podem ser aprimorados por meio de informações demográficas, como
como idade, estado civil, sexo, renda ou codificação étnica. Os dados da entidade comercial podem ser associados a
receita anual, número de funcionários, tamanho do espaço ocupado, etc.

472 • DMBOK2
• Informações psicográficas: Dados usados para segmentar as populações-alvo por comportamentos específicos,
hábitos ou preferências, como preferências de produtos e marcas, associações a organizações, lazer
atividades, estilo de transporte pendulares, preferências de horário de compras, etc.
• Informações de avaliação: Use esse tipo de aprimoramento para avaliação de ativos, estoque e venda.
1.3.10.3 Análise e formatação de dados
Análise de dados é o processo de análise de dados usando regras pré-determinadas para definir seu conteúdo ou valor. A análise de dados
permite que o analista de dados defina conjuntos de padrões que alimentam um mecanismo de regras usado para distinguir entre valores
de dados válidos e inválidos. A correspondência de padrões específicos desencadeia ações.
A análise de dados atribui características aos valores de dados que aparecem em uma instância de dados e essas características ajudam
a determinar fontes potenciais para benefícios adicionais. Por exemplo, se um atributo chamado 'nome' puder ser determinado como tendo
valores pertencentes a 'nome da empresa' incorporados a ele, o valor dos dados será identificado como o nome de uma empresa em vez
do nome de uma pessoa. Use a mesma abordagem para qualquer situação em que os valores de dados se organizem em hierarquias
semânticas, como subpeças, peças e montagens.
Muitos problemas de qualidade de dados envolvem situações em que a variação nos valores de dados que representam conceitos
semelhantes introduz ambiguidade. Extrair e reorganizar os componentes separados (comumente chamados de 'tokens') podem ser
extraídos e reorganizados em uma representação padrão para criar um padrão válido. Quando um padrão inválido é reconhecido, o
aplicativo pode tentar transformar o valor inválido em um que atenda às regras. Execute a padronização mapeando dados de algum padrão
de origem em uma representação de destino correspondente.
Por exemplo, considere as diferentes maneiras pelas quais os números de telefone esperados para estar em conformidade com um plano
de numeração são formatados. Enquanto alguns têm dígitos, alguns têm caracteres alfabéticos e todos usam caracteres especiais
diferentes para separação. As pessoas podem reconhecer cada um como um número de telefone. No entanto, para determinar se esses
números são precisos (talvez comparando-os com um diretório mestre de clientes) ou para investigar se existem números duplicados
quando deveria haver apenas um para cada fornecedor, os valores devem ser analisados em seus segmentos de componentes (código de
área , câmbio e número de linha) e depois transformado em um formato padrão.
Outro bom exemplo é o nome de um cliente, pois os nomes podem ser representados em milhares de formas diferentes. Uma boa
ferramenta de padronização será capaz de analisar os diferentes componentes de um nome de cliente, como nome próprio, nome do meio,
sobrenome, iniciais, títulos, designações de geração e, em seguida, reorganizar esses componentes em uma representação canônica que
outros serviços de dados serão capaz de manipular.
A capacidade humana de reconhecer padrões familiares contribui para a capacidade de caracterizar valores de dados variantes pertencentes
à mesma classe abstrata de valores; as pessoas reconhecem diferentes tipos de números de telefone porque estão em conformidade com
os padrões usados com frequência. Um analista descreve os padrões de formato que representam um objeto de dados, como Nome da
Pessoa, Descrição do Produto e assim por diante. Uma ferramenta de qualidade de dados analisa os valores de dados que estão em
conformidade com qualquer um desses padrões e até os transforma em um único formulário padronizado que simplificará os processos de
avaliação, análise de similaridade e correção. A análise baseada em padrões pode automatizar o reconhecimento e a padronização
subsequente de componentes de valor significativos.

1.3.10.4 Transformação e Padronização de Dados
Durante o processamento normal, as regras de dados acionam e transformam os dados em um formato legível pela arquitetura de destino. No entanto, legível
nem sempre significa aceitável. As regras são criadas diretamente em um fluxo de integração de dados ou dependem de tecnologias alternativas incorporadas
ou acessíveis a partir de uma ferramenta.
A transformação de dados baseia-se nesses tipos de técnicas de padronização. Guie transformações baseadas em regras mapeando valores de dados em
seus formatos e padrões originais em uma representação de destino. Os componentes analisados de um padrão estão sujeitos a rearranjos, correções ou
quaisquer alterações conforme indicado pelas regras na base de conhecimento. Na verdade, a padronização é um caso especial de transformação,
empregando regras que capturam contexto, linguística e expressões idiomáticas reconhecidas como comuns ao longo do tempo, por meio de análises
repetidas pelo analista de regras ou fornecedor de ferramentas. (Consulte o Capítulo 3.)
2. Atividades
2.1 Definir dados de alta qualidade
Muitas pessoas reconhecem dados de baixa qualidade quando os veem. Menos são capazes de definir o que significam dados de alta qualidade.
Alternativamente, eles o definem em termos muito gerais: “Os dados precisam estar certos”. “Precisamos de dados precisos.” Dados de alta qualidade são
adequados para os propósitos dos consumidores de dados. Antes de lançar um programa de qualidade de dados, é benéfico entender as necessidades de
negócios, definir termos, identificar pontos problemáticos organizacionais e começar a construir consenso sobre os direcionadores e prioridades para a
melhoria da qualidade dos dados. Faça um conjunto de perguntas para entender o estado atual e avaliar a prontidão organizacional para a melhoria da
qualidade dos dados:
• O que as partes interessadas querem dizer com 'dados de alta qualidade'?
• Qual é o impacto de dados de baixa qualidade nas operações e estratégias de negócios?
• Como os dados de maior qualidade possibilitarão a estratégia de negócios?
• Quais prioridades impulsionam a necessidade de melhoria da qualidade dos dados?
• Qual é a tolerância para dados de baixa qualidade?
• Que governança existe para apoiar a melhoria da qualidade dos dados?
• Que estruturas de governança adicionais serão necessárias?
Obter uma visão abrangente do estado atual da qualidade dos dados em uma organização requer abordar a questão de diferentes perspectivas:
• Uma compreensão da estratégia e objetivos de negócios
• Entrevistas com as partes interessadas para identificar pontos problemáticos, riscos e impulsionadores de negócios
• Avaliação direta de dados, por meio de perfis e outras formas de análise
• Documentação de dependências de dados em processos de negócios
• Documentação de arquitetura técnica e suporte de sistemas para processos de negócios

474 • DMBOK2
Esse tipo de avaliação pode revelar um número significativo de oportunidades. Estes precisam ser priorizados com base no benefício potencial para
a organização. Usando a contribuição das partes interessadas, incluindo administradores de dados e PMEs de negócios e técnicas, a equipe de
qualidade de dados deve definir o significado de qualidade de dados e propor prioridades do programa.
2.2 Definir uma estratégia de qualidade de dados
Melhorar a qualidade dos dados requer uma estratégia que leve em conta o trabalho que precisa ser feito e a forma como as pessoas irão executá-
lo. As prioridades de qualidade de dados devem estar alinhadas com a estratégia de negócios. Adotar ou desenvolver uma estrutura e metodologia
ajudará a orientar a estratégia e as táticas, ao mesmo tempo em que fornecerá um meio de medir o progresso e os impactos. Um framework deve
incluir métodos para:
• Compreenda e priorize as necessidades de negócios
• Identifique os dados críticos para atender às necessidades de negócios
• Definir regras de negócios e padrões de qualidade de dados com base nos requisitos de negócios
• Avaliar dados em relação às expectativas
• Compartilhe descobertas e obtenha feedback das partes interessadas
• Priorize e gerencie problemas
• Identificar e priorizar oportunidades de melhoria
• Medir, monitorar e relatar a qualidade dos dados
• Gerenciar Metadados produzidos por meio de processos de qualidade de dados
• Integrar controles de qualidade de dados em processos técnicos e de negócios
Uma estrutura também deve explicar como organizar a qualidade dos dados e como aproveitar as ferramentas de qualidade dos dados.
Conforme observado na introdução do capítulo, melhorar a qualidade dos dados exige que uma equipe do programa de qualidade dos dados envolva
a equipe técnica e de negócios e defina um programa de trabalho que aborde questões críticas, defina as melhores práticas e implemente processos
operacionais que apoiem o gerenciamento contínuo da qualidade dos dados . Muitas vezes, essa equipe fará parte da Organização de Gerenciamento
de Dados. Os analistas de DQ precisarão trabalhar em estreita colaboração com os Data Stewards em todos os níveis. Eles também devem
influenciar a política, incluindo a política sobre processos de negócios e desenvolvimento de sistemas. No entanto, essa equipe não será capaz de
resolver todos os desafios de qualidade de dados de uma organização.
O trabalho de DQ e o compromisso com dados de alta qualidade precisam ser incorporados às práticas organizacionais. A Estratégia DQ deve levar
em conta como estender as melhores práticas. (Consulte o Capítulo 17.)
2.3 Identificar Dados Críticos e Regras de Negócios
Nem todos os dados têm a mesma importância. Os esforços de gerenciamento de qualidade de dados devem se concentrar primeiro nos dados mais
importantes da organização: dados que, se fossem de maior qualidade, forneceriam maior valor para a organização e seus clientes. Os dados podem
ser priorizados com base em fatores como requisitos regulatórios, valor financeiro e impacto direto nos clientes. Muitas vezes, os esforços de
melhoria da qualidade de dados começam com dados mestres, que estão, por definição, entre os dados mais importantes em qualquer organização.
O resultado da análise de importância é uma lista classificada de dados, que a equipe de Data Quality pode usar para concentrar seus esforços de
trabalho.
Tendo identificado os dados críticos, os analistas de qualidade de dados precisam identificar regras de negócios que descrevam ou impliquem expectativas
sobre as características de qualidade dos dados. Muitas vezes as próprias regras não são explicitamente documentadas.
Eles podem precisar de engenharia reversa por meio da análise de processos de negócios existentes, fluxos de trabalho, regulamentos, políticas, padrões,
edições de sistema, código de software, gatilhos e procedimentos, atribuição e uso de código de status e bom senso. Por exemplo, se uma empresa de marketing
deseja direcionar esforços para pessoas em um grupo demográfico específico, os índices potenciais de qualidade de dados podem ser o nível e a razoabilidade
da população em campos demográficos como data de nascimento, idade, sexo e renda familiar.
A maioria das regras de negócios está associada à forma como os dados são coletados ou criados, mas a medição da qualidade dos dados se concentra em
saber se os dados são adequados para uso. Os dois (criação de dados e uso de dados) estão relacionados. As pessoas querem usar dados por causa do que
eles representam e por que foram criados. Por exemplo, entender o desempenho de vendas de uma organização durante um trimestre específico ou ao longo
do tempo depende de ter dados confiáveis sobre o processo de vendas (número e tipo de unidades vendidas, volume vendido para clientes existentes versus
novos clientes etc.).
Não é possível conhecer todas as maneiras pelas quais os dados podem ser usados, mas é possível entender o processo e as regras pelas quais os dados
foram criados ou coletados. As medidas que descrevem se os dados são adequados para uso devem ser desenvolvidas em relação aos usos conhecidos e
regras mensuráveis com base nas dimensões da qualidade dos dados: integridade, conformidade, validade, integridade etc. que fornecem a base para métricas
significativas. As dimensões da qualidade permitem que os analistas caracterizem tanto as regras (o campo X é obrigatório e deve ser preenchido) quanto as
constatações (por exemplo, o campo não é preenchido em 3% dos registros; os dados estão apenas 97% completos).
No nível do campo ou da coluna, as regras podem ser diretas. As regras de completude refletem se um campo é obrigatório ou opcional e, se for opcional, as
condições sob as quais ele deve ser preenchido. As regras de validade dependem de estipular o domínio dos valores válidos e, em alguns casos, o relacionamento
entre os campos. Por exemplo, um CEP dos EUA precisa ser válido, por si só, e associado corretamente a um código de estado dos EUA. As regras também
devem ser definidas no nível do conjunto de dados. Por exemplo, cada cliente deve ter um endereço de correspondência válido.
Definir regras de qualidade de dados é um desafio porque a maioria das pessoas não está acostumada a pensar em dados em termos de regras. Pode ser
necessário chegar às regras indiretamente, perguntando aos stakeholders sobre os requisitos de entrada e saída de um processo de negócios. Também ajuda
perguntar sobre pontos problemáticos, o que acontece quando os dados estão ausentes ou incorretos, como eles identificam problemas, como reconhecem
dados incorretos etc. Lembre-se de que não é necessário conhecer todas as regras para avaliar os dados. A descoberta e o refinamento das regras é um
processo contínuo. Uma das melhores maneiras de chegar às regras é compartilhar os resultados das avaliações. Esses resultados geralmente dão aos
stakeholders uma nova perspectiva sobre os dados a partir dos quais eles podem articular regras que lhes dizem o que eles precisam saber sobre o
dados.
2.4 Realizar uma avaliação inicial da qualidade dos dados
Uma vez que as necessidades de negócios mais críticas e os dados que as suportam tenham sido identificados, a parte mais importante da avaliação de
qualidade de dados é realmente examinar esses dados, consultá-los para entender o conteúdo e os relacionamentos dos dados e comparar os dados reais com
as regras e expectativas. Na primeira vez que isso for feito, os analistas descobrirão muitas coisas: relacionamentos e dependências não documentados nos
dados, regras implícitas,

476 • DMBOK2
dados, dados contraditórios, etc., bem como dados que realmente estão em conformidade com as regras. Com a ajuda de administradores de dados,
outras PMEs e consumidores de dados, os analistas de DQ precisarão classificar e priorizar as descobertas.
O objetivo de uma avaliação inicial da qualidade dos dados é aprender sobre os dados para definir um plano acionável para melhoria. Geralmente, é melhor
começar com um esforço pequeno e focado – uma prova básica de conceito – para demonstrar como funciona o processo de melhoria. As etapas incluem:
• Definir os objetivos da avaliação; estes irão conduzir o trabalho
• Identificar os dados a serem avaliados; O foco deve estar em um pequeno conjunto de dados, até mesmo um único elemento de dados, ou um
problema específico de qualidade de dados
• Identifique os usos dos dados e os consumidores dos dados
• Identificar riscos conhecidos com os dados a serem avaliados, incluindo o impacto potencial de problemas de dados em
processos organizacionais
• Inspecione os dados com base em regras conhecidas e propostas
• Documentar níveis de não conformidade e tipos de problemas
• Realizar análises adicionais e aprofundadas com base nas descobertas iniciais para
o Quantificar descobertas
o Priorize problemas com base no impacto nos negócios
o Desenvolver hipóteses sobre as causas-raiz dos problemas de dados
• Reúna-se com administradores de dados, PMEs e consumidores de dados para confirmar problemas e prioridades
• Use as descobertas como base para o planejamento
o Remediação de problemas, idealmente em suas causas raiz
o Controles e melhorias de processos para evitar que problemas se repitam
o Controles e relatórios contínuos
2.5 Identificar e priorizar melhorias potenciais
Tendo provado que o processo de melhoria pode funcionar, o próximo objetivo é aplicá-lo estrategicamente. Fazer isso requer identificar e priorizar
melhorias potenciais. A identificação pode ser realizada por perfis de dados em grande escala de conjuntos de dados maiores para entender a amplitude
dos problemas existentes. Também pode ser realizado por outros meios, como entrevistar as partes interessadas sobre os problemas de dados que os
afetam e acompanhar a análise do impacto comercial desses problemas. Em última análise, a priorização requer uma combinação de análise de dados
e discussão com as partes interessadas.
As etapas para realizar um perfil e uma análise de dados completos são essencialmente as mesmas de uma avaliação em pequena escala: definir metas,
entender os usos e riscos dos dados, medir em relação às regras, documentar e confirmar as descobertas com as PMEs, usar essas informações para
priorizar a correção e esforços de melhoria. No entanto, às vezes existem obstáculos técnicos para a criação de perfis em grande escala. E o esforço
precisará ser coordenado por uma equipe de analistas e os resultados gerais precisarão ser resumidos e compreendidos para que um plano de ação eficaz
seja implementado. Esforços de criação de perfil em grande escala, como aqueles em escala menor, ainda devem se concentrar nos dados mais críticos.
A criação de perfil de dados é apenas o primeiro passo na análise de problemas de qualidade de dados. Ele ajuda a identificar problemas, mas não
identifica as causas-raiz, nem determina o impacto dos problemas nos processos de negócios. Determinar o impacto requer entrada
das partes interessadas ao longo da cadeia de dados. Ao planejar a criação de perfis em grande escala, certifique-se de que o tempo seja alocado
para compartilhar resultados, priorizar problemas e determinar quais problemas exigem uma análise aprofundada.
2.6 Definir Objetivos para Melhoria da Qualidade dos Dados
O conhecimento obtido por meio das avaliações preliminares forma a base para as metas específicas do programa Data Quality. A melhoria pode
assumir diferentes formas, desde a simples remediação (por exemplo, correção de erros nos registros) até a remediação das causas-raiz. Os
planos de remediação e melhoria devem levar em conta acertos rápidos – problemas que podem ser resolvidos imediatamente a baixo custo – e
mudanças estratégicas de longo prazo. O foco estratégico de tais planos deve ser abordar as causas básicas dos problemas e estabelecer
mecanismos para prevenir problemas em primeiro lugar.
Esteja ciente de que muitas coisas podem atrapalhar os esforços de melhoria: restrições do sistema, idade dos dados, trabalho de projeto em
andamento que usa dados questionáveis, complexidade geral do cenário de dados, resistência cultural à mudança. Para evitar que essas restrições
atrapalhem o programa, defina metas específicas e alcançáveis com base na quantificação consistente do valor comercial das melhorias na
qualidade dos dados.
Por exemplo, uma meta pode ser melhorar a integridade dos dados do cliente de 90% para 95% com base em melhorias de processo e edições do
sistema. Obviamente, mostrar melhorias envolverá a comparação de medições iniciais e resultados aprimorados. Mas o valor vem com os
benefícios da melhoria: menos reclamações de clientes, menos tempo gasto corrigindo erros, etc. Meça essas coisas para explicar o valor do
trabalho de melhoria. Ninguém se preocupa com os níveis de integridade do campo, a menos que haja um impacto nos negócios. Deve haver um
retorno positivo sobre o investimento para melhorias nos dados. Quando problemas são encontrados, determine o ROI das correções com base
em:
• A criticidade (classificação de importância) dos dados afetados

• Quantidade de dados afetados
• A idade dos dados
• Número e tipo de processos de negócios impactados pelo problema
• Número de clientes, clientes, fornecedores ou funcionários afetados pelo problema

• Riscos associados ao problema
• Custos de remediar as causas-raiz
• Custos de possíveis soluções alternativas
Ao avaliar problemas, especialmente aqueles em que as causas-raiz são identificadas e mudanças técnicas são necessárias, sempre busque
oportunidades para evitar que os problemas se repitam. Prevenir problemas geralmente custa menos do que corrigi-los – às vezes ordens de
magnitude menos. (Consulte o Capítulo 11.)
2.7 Desenvolver e implantar operações de qualidade de dados
Muitos programas de qualidade de dados são iniciados por meio de um conjunto de projetos de melhoria identificados por meio de resultados da
avaliação de qualidade de dados. Para sustentar a qualidade dos dados, um programa de DQ deve implementar um plano que permita à equipe
gerenciar regras e padrões de qualidade de dados, monitorar a conformidade contínua dos dados com as regras, identificar e gerenciar problemas
de qualidade de dados e relatar os níveis de qualidade. Em apoio a essas atividades, analistas de DQ e Data
478 • DMBOK2
Os administradores também estarão envolvidos em atividades como documentar padrões de dados e regras de negócios e estabelecer requisitos
de qualidade de dados para fornecedores.
2.7.1 Gerenciar Regras de Qualidade de Dados
O processo de criação de perfil e análise de dados ajudará uma organização a descobrir (ou fazer engenharia reversa) regras de negócios e
qualidade de dados. À medida que a prática de qualidade de dados amadurece, a captura de tais regras deve ser incorporada ao processo de
desenvolvimento e aprimoramento do sistema. A definição antecipada de regras irá:
• Defina expectativas claras para características de qualidade de dados
• Fornecer requisitos para edições e controles do sistema que impeçam a introdução de problemas de dados
• Fornecer requisitos de qualidade de dados para fornecedores e outras partes externas
• Criar a base para medição e relatórios contínuos de qualidade de dados
Em suma, as regras e padrões de qualidade de dados são uma forma crítica de Metadados. Para serem eficazes, eles precisam ser gerenciados
como metadados. As regras devem ser:
• Documentado de forma consistente: Estabeleça padrões e modelos para documentar regras para que tenham
um formato e significado consistentes.
• Definido em termos de dimensões de qualidade de dados: dimensões de qualidade ajudam as pessoas a entender o que é
sendo medido. A aplicação consistente de dimensões ajudará na medição e na emissão
processos Gerenciais.
• Vinculado ao impacto nos negócios: embora as dimensões de qualidade de dados permitam a compreensão de problemas comuns,
elas não são uma meta em si mesmas. Padrões e regras devem estar conectados diretamente ao seu impacto no sucesso
organizacional. As medições que não estão vinculadas aos processos de negócios não devem ser
ocupado.
• Apoiado pela análise de dados: os analistas de qualidade de dados não devem adivinhar as regras. As regras devem ser testadas
contra dados reais. Em muitos casos, as regras mostrarão que há problemas com os dados. Mas a análise também pode mostrar
que as próprias regras não são completas.
• Confirmado pelas PMEs: O objetivo das regras é descrever a aparência dos dados. Muitas vezes, leva
conhecimento dos processos organizacionais para confirmar que as regras descrevem corretamente os dados. Esse
conhecimento vem quando especialistas no assunto confirmam ou explicam os resultados da análise de dados.
• Acessível a todos os consumidores de dados: Todos os consumidores de dados devem ter acesso a regras documentadas. Tal
o acesso permite que eles compreendam melhor os dados. Também ajuda a garantir que as regras estejam corretas e completas.
Garantir que os consumidores tenham meios para fazer perguntas e fornecer feedback sobre as regras.
2.7.2 Medir e monitorar a qualidade dos dados
Os procedimentos operacionais do Data Quality Management dependem da capacidade de medir e monitorar a qualidade dos
dados. Há duas razões igualmente importantes para implementar medições de qualidade de dados operacionais:
• Para informar os consumidores de dados sobre os níveis de qualidade
• Para gerenciar o risco de que a mudança possa ser introduzida por meio de mudanças nos processos de negócios ou técnicos
Algumas medidas servem para ambos os propósitos. As medições devem ser desenvolvidas com base nas descobertas da avaliação
de dados e análise de causa raiz. As medições destinadas a informar os consumidores de dados se concentrarão em elementos e
relacionamentos de dados críticos que, se não forem sólidos, afetarão diretamente os processos de negócios. As medições
relacionadas ao gerenciamento de risco devem se concentrar em relacionamentos que deram errado no passado e podem dar
errado no futuro. Por exemplo, se os dados forem derivados com base em um conjunto de regras de ETL e essas regras puderem
ser afetadas por alterações nos processos de negócios, medidas devem ser implementadas para detectar alterações nos dados.
O conhecimento de problemas passados deve ser aplicado para gerenciar riscos. Por exemplo, se vários problemas de dados
estiverem associados a derivações complexas, todas as derivações devem ser avaliadas – mesmo aquelas que não foram
associadas a problemas de dados. Na maioria dos casos, vale a pena implementar medições que monitorem funções
semelhantes às que tiveram problemas.
Os resultados da medição podem ser descritos em dois níveis: o detalhe relacionado à execução de regras individuais e
resultados gerais agregados das regras. Cada regra deve ter um índice padrão, alvo ou limite para comparação. Essa função
geralmente reflete a porcentagem de dados corretos ou a porcentagem de exceções, dependendo da fórmula usada. Por
exemplo:
()- ( )ÿ
ÿ()=
()
( )ÿ
ÿ()=
()
R representa a regra que está sendo testada. Por exemplo, 10.000 testes de uma regra de negócios (r) encontraram 560
exceções. Neste exemplo, o resultado ValidDQ seria 9440/10.000 = 94,4% e o resultado Invalid DQ seria 560/10.000 =
5,6%.
Organizar as métricas e resultados conforme mostrado na Tabela 30 pode ajudar a estruturar medidas, métricas e indicadores
em todo o relatório, revelar possíveis rollups e aprimorar as comunicações. O relatório pode ser mais formalizado e vinculado
a projetos que irão remediar os problemas. Os relatórios filtrados são úteis para administradores de dados que procuram
tendências e contribuições. A Tabela 30 fornece exemplos de regras construídas dessa maneira. Quando aplicável, os
resultados das regras são expressos em porcentagens positivas (a parte dos dados que está em conformidade com as regras
e expectativas) e porcentagens negativas (a parte dos dados que não está em conformidade com a regra).
As regras de qualidade de dados fornecem a base para o gerenciamento operacional da qualidade de dados. As regras podem ser integradas
em serviços de aplicativos ou serviços de dados que complementam o ciclo de vida dos dados, seja por meio de ferramentas de qualidade
de dados Commercial Off The Shelf (COTS), mecanismos de regras e ferramentas de relatórios para monitoramento e relatórios ou aplicativos
desenvolvidos sob medida.

480 • DMBOK2
Tabela 30 Exemplos de Métricas DQ
Dimensão e A medida Métricas Status
Regra de negócios Indicador

Completude Conte o número de Divida o número obtido de registros em que os Inaceitável:
Regra de Negócios 1: registros onde os dados dados são preenchidos pelo número total de Abaixo de 80%
A população do campo são preenchidos, compare registros na tabela ou banco de dados e multiplique povoado
é obrigatória com o número total de por 100 para obter a porcentagem concluída Acima de 20%
registros não preenchido
Exemplo 1: Contagem preenchida: Medida positiva: Exemplo de
O código postal deve 700.000 700.000/1.000.000*100 = 70% preenchido resultado:
ser preenchido na tabela Contagem não preenchida: Medida negativa: Inaceitável

de endereços 300.000 300.000/1.000.000 *100 = 30% não preenchido
Contagem total: 1.000.000
Singularidade Contar o número de Divida o número de registros duplicados pelo número Inaceitável:
Regra de Negócios 2: registros duplicados total de registros na tabela ou banco de dados e Acima de 0%
Deve haver apenas identificados; relatório sobre a multiplique por 100
um registro por instância porcentagem de registros que
de entidade em uma representam duplicatas
tabela
Exemplo 2: Contagem de duplicatas: 10.000/1.000.000*100 = 1,0% dos códigos postais Exemplo de

Deve haver uma e 1.000 estão presentes em mais de um atual resultado:
apenas uma linha Contagem total: 1.000.000 fileira Inaceitável

atual por código postal
no
Lista mestra de
códigos postais
Pontualidade Contar o número de Divida o número de transações incompletas Inaceitável:
Regra de Negócios 3: registros que não chegam a pelo número total de tentativas de transações Abaixo de 99%
Os registros tempo de um serviço de dados em um período de tempo e multiplique por 100 concluído no
devem chegar para que as transações prazo
dentro de um comerciais sejam concluídas Acima de 1% não
prazo programado concluído a tempo
Exemplo 3: Contagem de transações Positivo: Exemplo

O registro do incompletas: 2000 (1.000.000 – 2000) / 1.000.000*100 = 99,8% dos Resultado:
mercado de ações Contagem de tentativas registros de transações chegaram dentro do Aceitável
deve chegar dentro de transações: 1.000.000 prazo definido
de 5 minutos após a Negativo:
transação 2000/1.000.000*100 = 0,20% das
transações não chegaram dentro do prazo definido
Divida o número de registros que atendem à condição
Validade Contar o número de pelo número total de registros Inaceitável:

Regra de Negócios 4: registros onde a regra é Abaixo de
Se o campo X = valor 1, do 100% de
então o campo Y deve = adesão à regra
valor 1-prime
Exemplo 4: Contagem de registros em Positivo: Exemplo
Somente pedidos que status para envio = 999.000/1.000.000*100 = 99,9% dos registros Resultado:
enviados devem ser Enviado e status para estão em conformidade com a regra Inaceitável
faturados cobrança = Cobrado: 999.000 Negativo:
Contagem de registros totais: (1.000.000-999.000) / 1.000.000 *100 = 0,10% não
1.000.000 está em conformidade com a regra
Fornecer monitoramento contínuo, incorporando processos de controle e medição no fluxo de processamento de informações. O monitoramento
automatizado da conformidade com as regras de qualidade de dados pode ser feito in-stream ou por meio de um processo em lote. As medições podem
ser feitas em três níveis de granularidade: o valor do elemento de dados, a instância ou registro de dados ou o conjunto de dados. A Tabela 31 descreve
técnicas para coletar medições de qualidade de dados. As medições in-stream podem ser feitas durante a criação de dados ou entrega de dados entre
os estágios de processamento. As consultas em lote podem ser executadas em coleções de instâncias de dados montadas em um conjunto de dados,
geralmente em armazenamento persistente. As medições do conjunto de dados geralmente não podem ser feitas in-stream, pois a medição pode
precisar de todo o conjunto.
A incorporação dos resultados dos processos de controle e medição nos procedimentos operacionais e nas estruturas de relatórios permite o
monitoramento contínuo dos níveis de qualidade dos dados para feedback e melhoria das atividades de geração/coleta de dados.
Tabela 31 Técnicas de Monitoramento de Qualidade de Dados
Granularidade Tratamento em fluxo (fluxo em processo) Tratamento em lote

Elemento de dados Editar cheques no aplicativo Consultas diretas
Serviços de validação de elementos de dados Ferramenta de análise ou perfil de dados
Aplicações especialmente programadas
Registro de dados Editar cheques no aplicativo Consultas diretas
Serviços de validação de registro de dados Ferramenta de análise ou perfil de dados
Aplicações especialmente programadas
Conjunto de dados Inspeção inserida entre etapas de processamento Consultas diretas
Ferramenta de análise ou perfil de dados
2.7.3 Desenvolver procedimentos operacionais para gerenciar problemas de dados
Quaisquer que sejam as ferramentas usadas para monitorar a qualidade dos dados, quando os resultados são avaliados pelos membros da equipe de
qualidade de dados, eles precisam responder às descobertas de maneira oportuna e eficaz. A equipe deve projetar e implementar procedimentos
operacionais detalhados para:
• Diagnosticar problemas: O objetivo é revisar os sintomas do incidente de qualidade de dados, rastrear o
linhagem dos dados em questão, identificar o problema e onde ele se originou e identificar a raiz potencial
causas do problema. O procedimento deve descrever como a equipe de operações de qualidade de dados:
o Revisar os problemas de dados no contexto dos fluxos de processamento de informações apropriados e
isolar o local no processo onde a falha é introduzida
o Avaliar se houve alguma mudança ambiental que causaria erros de entrada
no sistema
o Avaliar se há ou não outros problemas de processo que contribuíram para a qualidade dos dados
incidente
o Determinar se há problemas com dados externos que afetaram a qualidade dos dados
NOTA: O trabalho de análise de causa raiz requer contribuições de PMEs técnicas e de negócios. Embora a equipe DQ possa liderar
e facilitar esse tipo de esforço de trabalho, o sucesso requer

colaboração
482 • DMBOK2
• Formulação de opções de remediação: com base no diagnóstico, avalie alternativas para abordar
o problema. Estes podem incluir:
o Abordar causas não técnicas, como falta de treinamento, falta de apoio da liderança,
responsabilidade e propriedade pouco claras, etc.
o Modificação dos sistemas para eliminar as causas técnicas
o Desenvolvimento de controles para evitar o problema
o Introdução de inspeção e monitoramento adicionais
o Correção direta de dados incorretos
o Não tomar nenhuma ação com base no custo e impacto da correção versus o valor dos dados
correção
• Resolvendo problemas: Tendo identificado as opções para resolver o problema, a equipe de qualidade de dados deve conferir
com os proprietários dos dados da empresa para determinar a melhor maneira de resolver o problema. Esses procedimentos devem
detalhar como os analistas:
o Avaliar os custos relativos e méritos das alternativas
o Recomendar uma das alternativas planejadas
o Fornecer um plano para desenvolver e implementar a resolução
o Implementar a resolução
As decisões tomadas durante o processo de gerenciamento de problemas devem ser rastreadas em um sistema de rastreamento de incidentes.
Quando os dados desse sistema são bem gerenciados, eles podem fornecer informações valiosas sobre as causas e os custos dos problemas de
dados. Inclua uma descrição do problema e as causas-raiz, opções para remediação e a decisão sobre como
para resolver o problema.
O sistema de rastreamento de incidentes coletará dados de desempenho relacionados à resolução de problemas, atribuições de trabalho, volume
de problemas, frequência de ocorrência, bem como o tempo para responder, diagnosticar, planejar uma solução e resolver problemas. Essas
métricas podem fornecer informações valiosas sobre a eficácia do fluxo de trabalho atual, bem como sistemas e utilização de recursos, e são
importantes pontos de dados de gerenciamento que podem impulsionar a melhoria operacional contínua para controle de qualidade de dados.
Os dados de rastreamento de incidentes também ajudam os consumidores de dados. As decisões baseadas em dados corrigidos devem ser
tomadas com o conhecimento de que foram alterados, por que foram alterados e como foram alterados. Essa é uma razão pela qual é importante
registrar os métodos de modificação e a justificativa para eles. Disponibilize esta documentação para consumidores de dados e desenvolvedores
que pesquisam alterações de código. Embora as alterações possam ser óbvias para as pessoas que as implementam, o histórico de alterações
será perdido para futuros consumidores de dados, a menos que seja documentado. O rastreamento de incidentes de qualidade de dados exige
que a equipe seja treinada sobre como os problemas devem ser classificados, registrados e rastreados. Para dar suporte ao rastreamento eficaz:
• Padronizar problemas e atividades de qualidade de dados: uma vez que os termos usados para descrever problemas de dados podem variar
entre as linhas de negócios, é importante definir um vocabulário padrão para os conceitos usados. Fazendo isso
simplificará a classificação e os relatórios. A padronização também facilita a medição do volume
de questões e atividades, identificar padrões e interdependências entre sistemas e participantes, e

relatório sobre o impacto geral das atividades de qualidade de dados. A classificação de um problema pode mudar à medida que a investigação
se aprofunda e as causas principais são expostas.
• Fornecer um processo de atribuição para questões de dados: Os procedimentos operacionais direcionam os analistas para
atribuir incidentes de qualidade de dados a indivíduos para diagnóstico e fornecer alternativas para resolução.
Conduza o processo de atribuição dentro do sistema de rastreamento de incidentes, sugerindo aos indivíduos com
áreas específicas de especialização.
• Gerenciar procedimentos de escalonamento de problemas: O tratamento de problemas de qualidade de dados requer um sistema bem definido de
escalação com base no impacto, duração ou urgência de um problema. Especifique a sequência de escalonamento
dentro do Acordo de Nível de Serviço de qualidade de dados. O sistema de rastreamento de incidentes implementará o
procedimentos de escalonamento, o que ajuda a agilizar o manuseio e a resolução eficientes de problemas de dados.
• Gerenciar o fluxo de trabalho de resolução de qualidade de dados: O SLA de qualidade de dados especifica objetivos para monitoramento,
controle e resolução, todos os quais definem uma coleção de fluxos de trabalho operacionais. O rastreamento de incidentes
o sistema pode oferecer suporte ao gerenciamento de fluxo de trabalho para acompanhar o progresso com diagnóstico e resolução de problemas.
2.7.4 Estabelecer Acordos de Nível de Serviço de Qualidade de Dados
Um Acordo de Nível de Serviço (SLA) de qualidade de dados especifica as expectativas de uma organização para resposta e correção para problemas de
qualidade de dados em cada sistema. As inspeções de qualidade de dados programadas no SLA ajudam a identificar problemas a serem corrigidos e, com o
tempo, reduzem o número de problemas. Ao permitir o isolamento e a análise da causa raiz das falhas de dados, há uma expectativa de que os procedimentos
operacionais forneçam um esquema para remediação das causas raiz dentro de um prazo acordado. Ter a inspeção e o monitoramento de qualidade de
dados implementados aumenta a probabilidade de detecção e correção de um problema de qualidade de dados antes que um impacto significativo nos
negócios possa ocorrer. O controle de qualidade de dados operacional definido em um SLA de qualidade de dados inclui:
• Elementos de dados cobertos pelo contrato
• Impactos nos negócios associados a falhas de dados
• Dimensões de qualidade de dados associadas a cada elemento de dados
• Expectativas de qualidade para cada elemento de dados para cada uma das dimensões identificadas em cada aplicativo
ou sistema na cadeia de valor de dados
• Métodos para medir contra essas expectativas
• Limite de aceitabilidade para cada medição
• Comissário(s) deve(m) ser notificado(s) caso o limite de aceitabilidade não seja atingido
• Cronogramas e prazos para resolução esperada ou remediação do problema
• Estratégia de escalonamento e possíveis recompensas e penalidades
O SLA de qualidade de dados também define as funções e responsabilidades associadas ao desempenho dos procedimentos operacionais de qualidade de
dados. Os procedimentos de qualidade de dados operacionais fornecem relatórios em conformidade com as regras de negócios definidas, além de monitorar
o desempenho da equipe na reação a incidentes de qualidade de dados. Os administradores de dados e a equipe operacional de qualidade de dados, embora
mantenham o nível de serviço de qualidade de dados, devem considerar suas restrições de SLA de qualidade de dados e conectar a qualidade de dados a
planos de desempenho individuais.

484 • DMBOK2
Quando os problemas não são tratados dentro dos tempos de resolução especificados, deve existir um processo de escalação para comunicar a não
observância do nível de serviço na cadeia de gerenciamento e governança. O SLA de qualidade de dados estabelece os limites de tempo para a
geração de notificações, os nomes daqueles nessa cadeia de gerenciamento e quando o escalonamento precisa ocorrer. Dado o conjunto de regras
de qualidade de dados, métodos para medir a conformidade, os limites de aceitabilidade definidos pelos clientes de negócios e os acordos de nível
de serviço, a equipe de qualidade de dados pode monitorar a conformidade dos dados com as expectativas de negócios, bem como a qualidade dos
dados. A equipe de qualidade atua nos procedimentos associados a erros de dados.
Os relatórios de SLA podem ser programados de acordo com os requisitos operacionais e de negócios. Um foco particular será na análise de
tendências de relatórios em casos focados em recompensas e penalidades periódicas se tais conceitos forem incorporados
a estrutura de SLA.
2.7.5 Desenvolver relatórios de qualidade de dados
O trabalho de avaliar a qualidade dos dados e gerenciar os problemas de dados não beneficiará a organização, a menos que as informações sejam
compartilhadas por meio de relatórios para que os consumidores de dados entendam a condição dos dados. Comunicando
deve focar em:
• Scorecard de qualidade de dados, que fornece uma visão de alto nível das pontuações associadas a várias métricas,
reportado a diferentes níveis da organização dentro dos limites estabelecidos
• Tendências de qualidade de dados, que mostram ao longo do tempo como a qualidade dos dados é medida e se a tendência é
Para cima ou para baixo
• Métricas de SLA, como se a equipe de qualidade de dados operacionais diagnostica e responde à qualidade dos dados
incidentes em tempo hábil
• Gerenciamento de problemas de qualidade de dados, que monitora o status de problemas e resoluções
• Conformidade da equipe de Data Quality com as políticas de governança
• Conformidade das equipes de TI e negócios às políticas de Qualidade de Dados
• Efeitos positivos de projetos de melhoria
Os relatórios devem estar alinhados às métricas do SLA de qualidade de dados o máximo possível, para que os objetivos da equipe estejam alinhados
com os de seus clientes. O programa de Qualidade de Dados também deve relatar os efeitos positivos dos projetos de melhoria. É melhor fazer isso
em termos de negócios para lembrar continuamente a organização do

efeito que os dados têm sobre os clientes.
3. Ferramentas
As ferramentas devem ser selecionadas e as arquiteturas de ferramentas devem ser definidas na fase de planejamento do programa corporativo de
qualidade de dados. As ferramentas fornecem um kit inicial de conjunto de regras parcial, mas as organizações precisam criar e inserir suas próprias
regras e ações específicas de contexto em qualquer ferramenta.

3.1 Ferramentas de Perfil de Dados
As ferramentas de perfil de dados produzem estatísticas de alto nível que permitem aos analistas identificar padrões nos dados e realizar a avaliação
inicial das características de qualidade. Algumas ferramentas podem ser usadas para realizar o monitoramento contínuo dos dados.
As ferramentas de criação de perfil são particularmente importantes para os esforços de descoberta de dados porque permitem a avaliação de
grandes conjuntos de dados. As ferramentas de criação de perfil aumentadas com recursos de visualização de dados ajudarão no processo de
descoberta. (Consulte os Capítulos 5 e 8 e a Seção 1.3.9.)
3.2 Ferramentas de consulta de dados
O perfil de dados é apenas o primeiro passo na análise de dados. Ajuda a identificar possíveis problemas. Os membros da equipe de qualidade de
dados também precisam consultar os dados mais profundamente para responder a perguntas levantadas pelos resultados de criação de perfil e
encontrar padrões que forneçam insights sobre as causas principais dos problemas de dados. Por exemplo, consultar para descobrir e quantificar
outros aspectos da qualidade dos dados, como exclusividade e integridade.
3.3 Ferramentas de modelagem e ETL
As ferramentas usadas para modelar dados e criar processos ETL têm impacto direto na qualidade dos dados. Se usadas com os dados em mente,
essas ferramentas podem permitir dados de maior qualidade. Se forem usados sem o conhecimento dos dados, podem ter efeitos prejudiciais. Os
membros da equipe DQ devem trabalhar com as equipes de desenvolvimento para garantir que os riscos de qualidade de dados sejam abordados e
que a organização aproveite ao máximo as maneiras pelas quais a modelagem e o processamento de dados eficazes podem permitir dados de maior
qualidade. (Veja os Capítulos 5, 8 e 11.)
3.4 Modelos de Regras de Qualidade de Dados
Os modelos de regras permitem que o analista capture as expectativas de dados. Os modelos também ajudam a preencher a lacuna de comunicação
entre as equipes de negócios e técnicas. A formulação consistente de regras facilita a tradução das necessidades de negócios em código, seja esse
código incorporado em um mecanismo de regras, no componente analisador de dados de uma ferramenta de criação de perfil de dados ou em uma
ferramenta de integração de dados. Um modelo pode ter várias seções, uma para cada tipo de regra de negócios a ser implementada.
3.5 Repositórios de Metadados
Conforme observado na Seção 1.3.4, definir a qualidade dos dados requer Metadados e as definições de dados de alta qualidade são um tipo valioso
de Metadados. As equipes de DQ devem trabalhar em estreita colaboração com as equipes que gerenciam metadados para garantir que os requisitos
de qualidade de dados, regras, resultados de medição e documentação de problemas sejam disponibilizados aos dados
consumidores.
486 • DMBOK2
4. Técnicas
4.1 Ações Preventivas
A melhor maneira de criar dados de alta qualidade é evitar que dados de baixa qualidade entrem em uma organização.
As ações preventivas impedem a ocorrência de erros conhecidos. Inspecionar os dados depois que estiverem em produção não melhorará sua qualidade. As
abordagens incluem:
• Estabeleça controles de entrada de dados: crie regras de entrada de dados que impeçam que dados inválidos ou imprecisos
entrando em um sistema.
• Treinar produtores de dados: Garantir que a equipe em sistemas upstream entendam o impacto de seus dados na
usuários a jusante. Dê incentivos ou avaliações de base na precisão e integridade dos dados, em vez de
apenas velocidade.
• Defina e aplique regras: crie um 'firewall de dados', que tenha uma tabela com toda a qualidade dos dados de negócios
regras usadas para verificar se a qualidade dos dados é boa, antes de ser usado em uma aplicação como tal
armazém. Um firewall de dados pode inspecionar o nível de qualidade dos dados processados por um aplicativo e, se
o nível de qualidade está abaixo dos níveis aceitáveis, os analistas podem ser informados sobre o problema.
• Exija dados de alta qualidade de fornecedores de dados: examine os processos de um provedor de dados externo para
verifique suas estruturas, definições e fonte(s) de dados e proveniência de dados. Fazer isso permite
avaliação de quão bem seus dados serão integrados e ajuda a evitar o uso de dados não autorizados ou
dados adquiridos sem permissão do proprietário.
• Implementar Governança e Administração de Dados: Garantir que as funções e responsabilidades sejam definidas de forma que
descrever e aplicar regras de engajamento, direitos de decisão e responsabilidades para
gestão de ativos de dados e informações (McGilvray, 2008). Trabalhar com administradores de dados para revisar o
processo e mecanismos para gerar, enviar e receber dados.
• Instituir controle formal de mudanças: Garantir que todas as mudanças nos dados armazenados sejam definidas e testadas antes de serem
implementado. Impedir alterações diretamente nos dados fora do processamento normal, estabelecendo gating
processos.
4.2 Ações Corretivas
As ações corretivas são implementadas após a ocorrência e a detecção de um problema. Os problemas de qualidade de dados devem ser tratados
sistemicamente e em suas causas-raiz para minimizar os custos e riscos das ações corretivas. 'Resolva o problema onde ele acontece' é a melhor prática em
Data Quality Management. Isso geralmente significa que as ações corretivas devem incluir a prevenção da recorrência das causas dos problemas de qualidade.
Execute a correção de dados de três maneiras gerais:

• Correção automatizada: As técnicas de correção automatizadas incluem padronização baseada em regras,
normalização e correção. Os valores modificados são obtidos ou gerados e confirmados sem
Intervenção manual. Um exemplo é a correção automática de endereços, que envia endereços de entrega para
um padronizador de endereços que conforma e corrige endereços de entrega usando regras, análise,
padronização e tabelas de referência. A correção automatizada requer um ambiente com
padrões, regras comumente aceitas e padrões de erro conhecidos. A quantidade de correção automatizada
pode ser reduzido ao longo do tempo se esse ambiente for bem gerenciado e os dados corrigidos forem compartilhados com
sistemas a montante.
• Correção direcionada manualmente: use ferramentas automatizadas para remediar e corrigir dados, mas requer manual
revise antes de confirmar as correções no armazenamento persistente. Aplicar correção de nome e endereço,
resolução de identidade e correções baseadas em padrões automaticamente e usar algum mecanismo de pontuação para
propor um nível de confiança na correção. Correções com pontuações acima de um determinado nível de
confiança pode ser comprometida sem revisão, mas correções com pontuações abaixo do nível de
confiança são apresentados ao administrador de dados para revisão e aprovação. Confirmar todos os aprovados
correções e revisar aquelas não aprovadas para entender se deve ajustar o valor subjacente aplicado
as regras. Ambientes em que conjuntos de dados confidenciais exigem supervisão humana (por exemplo, MDM) são bons
exemplos de onde a correção manual pode ser adequada.
• Correção manual: Às vezes, a correção manual é a única opção na ausência de ferramentas ou
automação ou se for determinado que a mudança é melhor tratada por meio de supervisão humana. Manual
correções são melhor feitas por meio de uma interface com controles e edições, que fornecem uma trilha de auditoria para
mudanças. A alternativa de fazer as correções e comprometer os registros atualizados diretamente no
ambientes de produção é extremamente arriscado. Evite usar este método.
4.3 Módulos de Verificação de Qualidade e Código de Auditoria
Crie módulos de código compartilháveis, vinculáveis e reutilizáveis que executam verificações repetidas de qualidade de dados e processos de
auditoria que os desenvolvedores podem obter de uma biblioteca. Se o módulo precisar ser alterado, todo o código vinculado a esse módulo será
atualizado. Esses módulos simplificam o processo de manutenção. Blocos de código bem projetados podem evitar muitos problemas de qualidade
de dados. Tão importante quanto, eles garantem que os processos sejam executados de forma consistente. Onde as leis ou políticas obrigam a
relatar resultados de qualidade específicos, a linhagem de resultados geralmente precisa ser descrita.
Os módulos de verificação de qualidade podem fornecer isso. Para dados que tenham alguma dimensão de qualidade questionável e que sejam
altamente classificados, qualifique as informações nos ambientes compartilhados com notas de qualidade e classificações de confiança.
4.4 Métricas eficazes de qualidade de dados
Um componente crítico do gerenciamento da qualidade dos dados é desenvolver métricas que informem os consumidores de dados sobre as
características de qualidade que são importantes para o uso dos dados. Muitas coisas podem ser medidas, mas nem todas valem o tempo e o
esforço. Ao desenvolver métricas, os analistas de DQ devem levar em conta estas características:

488 • DMBOK2
• Mensurabilidade: Uma métrica de qualidade de dados deve ser mensurável - precisa ser algo que possa ser
contado. Por exemplo, a relevância dos dados não é mensurável, a menos que critérios claros sejam definidos para o que torna
os dados relevantes. Até mesmo a integridade dos dados precisa ser definida objetivamente para ser medida.
Os resultados esperados devem ser quantificáveis dentro de um intervalo discreto.
• Relevância para os negócios: embora muitas coisas sejam mensuráveis, nem todas se traduzem em métricas úteis.
As medições precisam ser relevantes para os consumidores de dados. O valor da métrica é limitado se não puder ser
relacionados a algum aspecto das operações ou desempenho do negócio. Cada métrica de qualidade de dados deve se
correlacionar com a influência dos dados nas principais expectativas de negócios.
• Aceitabilidade: As dimensões de qualidade de dados enquadram os requisitos de negócios para qualidade de dados.
A quantificação ao longo da dimensão identificada fornece evidências concretas dos níveis de qualidade dos dados. Determine se
os dados atendem às expectativas de negócios com base nos limites de aceitabilidade especificados. Se a pontuação for igual ou
superior ao limite, a qualidade dos dados atende às expectativas de negócios. Se a pontuação estiver abaixo do limite, não.
• Responsabilidade / Administração: As métricas devem ser compreendidas e aprovadas pelas principais partes interessadas (por
exemplo, proprietários de negócios e administradores de dados). Eles são notificados quando a medição da métrica mostra que a
qualidade não atende às expectativas. O proprietário dos dados da empresa é responsável, enquanto um administrador de dados
toma as medidas corretivas apropriadas.
• Controlabilidade: Uma métrica deve refletir um aspecto controlável do negócio. Em outras palavras, se o
métrica estiver fora do intervalo, ela deve desencadear uma ação para melhorar os dados. Se não houver como responder, a
métrica provavelmente não será útil.
• Tendências: As métricas permitem que uma organização meça a melhoria da qualidade dos dados ao longo do tempo. O rastreamento
ajuda os membros da equipe de qualidade de dados a monitorar as atividades dentro do escopo de um SLA de qualidade de dados
e um acordo de compartilhamento de dados e demonstrar a eficácia das atividades de melhoria. Uma vez que um processo de
informação esteja estável, técnicas de controle de processo estatístico podem ser aplicadas para detectar mudanças na previsibilidade
dos resultados de medição e nos processos técnicos e de negócios sobre os quais ele fornece informações.
4.5 Controle Estatístico de Processo
O Controle Estatístico de Processo (CEP) é um método para gerenciar processos analisando medições de variação nas entradas, saídas ou
etapas do processo. A técnica foi desenvolvida no setor manufatureiro na década de 1920 e tem sido aplicada em outras indústrias, em
metodologias de melhoria como Six Sigma e em Data Quality Management . . O CEP é baseado na suposição de que quando um processo com
entradas consistentes é executado de forma consistente, ele produzirá saídas consistentes. Ele usa medidas de tendência central (como os valores
se agrupam em torno de um valor central, como uma média,
87 Ver Redman (1996 e 2001), Loshin (2000), Sebastian-Coleman (2013) e Jugulum (2014).
mediana, ou moda) e de variabilidade em torno de um valor central (por exemplo, faixa, variância, desvio padrão), para estabelecer
tolerâncias para variação dentro de um processo.
A principal ferramenta usada para CEP é o gráfico de controle (Figura 95), que é um gráfico de série temporal que inclui uma linha central
para a média (a medida de tendência central) e descreve os limites de controle superior e inferior calculados (variabilidade em torno de um
valor central ). Em um processo estável, resultados de medição fora dos limites de controle indicam uma causa especial.
Exemplo de dados de um processo estável (sob controle)
0,21 UCL=0,21061
0,20
0,19 ÿx=0,1885
0,18
0,17
LCL=0,16639
0,16
TGT_TBL_ETL_DT
Figura 95 Gráfico de Controle de um Processo em Controle Estatístico
O SPC mede a previsibilidade dos resultados do processo identificando a variação dentro de um processo. Os processos têm variação de
dois tipos: Causas Comuns que são inerentes ao processo e Causas Especiais que são imprevisíveis ou intermitentes. Quando as únicas
fontes de variação são causas comuns, diz-se que um sistema está sob controle (estatístico) e uma faixa de variação normal pode ser
estabelecida. Esta é a linha de base contra a qual a mudança

pode ser detectado.
A aplicação do CEP à medição da qualidade de dados é baseada na suposição de trabalho de que, como um produto fabricado, os dados
são o produto de um processo. Às vezes, o processo que cria os dados é muito simples (por exemplo, uma pessoa preenche um formulário).
Outras vezes, os processos são bastante complexos: um conjunto de algoritmos agrega dados de reclamações médicas para acompanhar
tendências relacionadas à eficácia de determinados protocolos clínicos. Se tal processo tiver entradas consistentes e for executado
consistentemente, ele produzirá resultados consistentes toda vez que for executado. No entanto, se as entradas ou a execução mudarem,
as saídas também mudarão. Cada um desses componentes pode ser medido. As medições podem ser usadas para detectar causas
especiais. O conhecimento das causas especiais pode ser usado para mitigar os riscos associados à coleta ou processamento de dados.
O SPC é usado para controle, detecção e melhoria. O primeiro passo é medir o processo para identificar e eliminar as causas especiais.
Esta atividade estabelece o estado de controle do processo. O próximo é colocar no lugar

490 • DMBOK2
medições para detectar variações inesperadas assim que for detectável. A detecção precoce de problemas simplifica a investigação de
suas causas-raiz. As medições do processo também podem ser usadas para reduzir os efeitos indesejados de causas comuns de variação,
permitindo maior eficiência.
4.6 Análise de causa raiz
A causa raiz de um problema é um fator que, se eliminado, removeria o próprio problema. A análise de causa raiz é um processo de
compreensão dos fatores que contribuem para os problemas e as formas como eles contribuem. Seu objetivo é identificar condições
subjacentes que, se eliminadas, significariam que os problemas desapareceriam.
Um exemplo de gerenciamento de dados pode esclarecer a definição. Digamos que um processo de dados executado a cada mês exija
como entrada um arquivo de informações do cliente. A medição dos dados mostra que em abril, julho, outubro e janeiro, a qualidade dos
dados diminui. A verificação do prazo de entrega mostra que em março, junho, setembro e dezembro, o arquivo é entregue no dia 30 do
mês, enquanto em outros momentos é entregue no dia 25. Uma análise mais aprofundada mostra que a equipe responsável pela entrega
do arquivo também é responsável pelo fechamento dos processos financeiros trimestrais. Esses processos têm precedência sobre outros
trabalhos e os arquivos são entregues com atraso nesses meses, impactando na qualidade. A causa raiz do problema de qualidade de
dados acaba sendo um atraso no processo causado por uma prioridade concorrente. Isso pode ser resolvido agendando a entrega de
arquivos e garantindo que

os recursos podem entregar dentro do cronograma.
Técnicas comuns para análise de causa raiz incluem análise de Pareto (a regra 80/20), análise de diagrama de espinha de peixe,
rastreamento, análise de processo e os Cinco Porquês (McGilvray, 2008).
Melhorar a qualidade dos dados dentro de uma organização não é uma tarefa fácil – mesmo quando os esforços de melhoria da qualidade
dos dados são lançados dentro de um programa de governança de dados e com o apoio da alta administração. Uma discussão acadêmica
clássica é se é melhor implementar um programa de qualidade de dados de cima para baixo ou de baixo para cima.
Normalmente, uma abordagem híbrida funciona melhor – de cima para baixo para patrocínio, consistência e recursos, mas de baixo para
cima para descobrir o que está realmente quebrado e alcançar sucessos incrementais.
Melhorar a qualidade dos dados requer mudanças na forma como as pessoas pensam e se comportam em relação aos dados. A mudança
cultural é um desafio. Requer planejamento, treinamento e reforço. (Consulte o Capítulo 17.) Embora as especificidades da mudança
cultural sejam diferentes de organização para organização, a maioria das implementações de programas de qualidade de dados precisa planejar
por:
• Métricas sobre o valor dos dados e o custo de dados de baixa qualidade: uma maneira de aumentar a
a consciência da necessidade de Data Quality Management é por meio de métricas que descrevem o valor dos dados
e o retorno do investimento das melhorias. Essas métricas (que diferem da qualidade dos dados
pontuações) fornecem a base para melhorar o financiamento e mudar o comportamento dos funcionários e
gestão. (Consulte o Capítulo 11.)

• Modelo operacional para interações de TI/Negócios: os empresários sabem quais são os dados importantes e o que eles significam.
Os custodiantes de dados de TI entendem onde e como os dados são armazenados e, portanto, estão bem posicionados para traduzir
as definições de qualidade de dados em consultas ou códigos que identificam registros específicos que não estão em conformidade.
• Mudanças na forma como os projetos são executados: a supervisão do projeto deve garantir que o financiamento do projeto inclua
etapas relacionadas à qualidade dos dados (por exemplo, perfil e avaliação, definição de expectativas de qualidade, remediação
de problemas de dados, prevenção e correção, construção de controles e medições). É prudente garantir que os problemas sejam
identificados antecipadamente e criar expectativas de qualidade de dados antecipadamente nos projetos.
• Mudanças nos processos de negócios: A melhoria da qualidade dos dados depende da melhoria dos processos pelos quais os dados
são produzidos. A equipe de qualidade de dados precisa ser capaz de avaliar e recomendar alterações em processos não técnicos
(assim como técnicos) que afetam a qualidade dos dados.
• Financiamento para projetos de remediação e melhoria: Algumas organizações não planejam
remediando dados, mesmo quando eles estão cientes de problemas de qualidade de dados. Os dados não se corrigirão
sozinhos. Os custos e benefícios dos projetos de remediação e melhoria devem ser documentados para que o trabalho de
melhoria dos dados possa ser priorizado.
• Financiamento para operações de qualidade de dados: Sustentar a qualidade dos dados requer operações contínuas para
monitorar a qualidade dos dados, relatar as descobertas e continuar a gerenciar os problemas à medida que são descobertos.
A maioria das organizações que dependem de dados tem muitas oportunidades de melhoria. O quão formal e bem suportado um programa de
qualidade de dados será depende de quão madura é a organização do ponto de vista do gerenciamento de dados. (Consulte o Capítulo 15.) A
prontidão organizacional para adotar práticas de qualidade de dados pode ser avaliada considerando as seguintes características:
• Compromisso da gerência com o gerenciamento de dados como um ativo estratégico: como parte da solicitação de suporte para
um programa de qualidade de dados, é importante determinar até que ponto a alta administração entende o papel que os dados
desempenham na organização. Até que ponto a alta administração reconhece o valor dos dados para os objetivos estratégicos? Que
riscos eles associam a dados de baixa qualidade? Qual o nível de conhecimento deles sobre os benefícios da governança de dados?
Quão otimista sobre a capacidade de mudar a cultura para apoiar a melhoria da qualidade?
• O entendimento atual da organização sobre a qualidade de seus dados: Antes da maioria das organizações
iniciar sua jornada de melhoria de qualidade, eles geralmente entendem os obstáculos e pontos problemáticos que significam
dados de baixa qualidade. Adquirir conhecimento destes é importante. Por meio deles, dados de baixa qualidade podem estar
diretamente associados a efeitos negativos, incluindo custos diretos e indiretos, na organização.
Uma compreensão dos pontos problemáticos também ajuda a identificar e priorizar projetos de melhoria.
• O estado real dos dados: encontrar uma maneira objetiva de descrever a condição dos dados que está causando
pontos problemáticos é o primeiro passo para melhorar os dados. Os dados podem ser medidos e descritos por meio de
492 • DMBOK2
perfil e análise, bem como através da quantificação de problemas conhecidos e pontos problemáticos. Se a equipe DQ não
souber o estado real dos dados, será difícil priorizar e agir nas oportunidades de melhoria.
• Riscos associados à criação, processamento ou uso de dados: identificar o que pode dar errado com os dados
e o dano potencial a uma organização por dados de baixa qualidade fornece a base para mitigar
riscos. Se a organização não reconhecer esses riscos, pode ser um desafio obter suporte para o
Programa de Qualidade de Dados.
• Prontidão cultural e técnica para monitoramento de qualidade de dados escalável: A qualidade dos dados pode ser
impactado negativamente pelos processos de negócios e técnicos. Melhorar a qualidade dos dados depende de
cooperação entre as equipes de negócios e de TI. Se o relacionamento entre as equipes de negócios e de TI não for
colaborativo, então será difícil progredir.
Os resultados de uma avaliação de prontidão ajudarão a determinar por onde começar e com que rapidez proceder. Os resultados também
podem fornecer a base para as metas do programa de mapeamento de estradas. Se houver um forte apoio para a melhoria da qualidade dos
dados e a organização conhecer seus próprios dados, talvez seja possível lançar um programa estratégico completo. Se a organização não
conhece o estado real de seus dados, pode ser necessário se concentrar na construção desse conhecimento antes de desenvolver uma
estratégia completa.
A qualidade dos dados não será aprimorada por meio de uma coleção de ferramentas e conceitos, mas por meio de uma mentalidade que
ajude os funcionários e stakeholders a agir sempre pensando na qualidade dos dados e no que o negócio e seus clientes precisam. Fazer
com que uma organização seja consciente sobre a qualidade dos dados geralmente requer uma mudança cultural significativa. Tal mudança
requer visão e liderança. (Consulte o Capítulo 17.)
O primeiro passo é promover a conscientização sobre o papel e a importância dos dados para a organização. Todos os funcionários devem
agir com responsabilidade e levantar questões de qualidade de dados, solicitar dados de boa qualidade como consumidores e fornecer
informações de qualidade a outras pessoas. Cada pessoa que toca nos dados pode afetar a qualidade desses dados. A qualidade dos dados
não é apenas responsabilidade de uma equipe de DQ ou grupo de TI.
Assim como os funcionários precisam entender o custo para adquirir um novo cliente ou manter um cliente existente, eles também precisam
conhecer os custos organizacionais de dados de baixa qualidade, bem como as condições que fazem com que os dados sejam de baixa
qualidade. Por exemplo, se os dados do cliente estiverem incompletos, um cliente pode receber o produto errado, gerando custos diretos e
indiretos para uma organização. O cliente não apenas devolverá o produto, mas também poderá ligar e reclamar, usando o horário da central
de atendimento, com o potencial de danos à reputação da organização. Se os dados do cliente estiverem incompletos porque a organização
não estabeleceu requisitos claros, todos que usam esses dados têm interesse em esclarecer os requisitos e seguir os padrões.
Em última análise, os funcionários precisam pensar e agir de maneira diferente se quiserem produzir dados de melhor qualidade e gerenciá-
los de maneira a garantir a qualidade. Isso requer treinamento e reforço. O treinamento deve focar em:
• Causas comuns de problemas de dados

• Relacionamentos dentro do ecossistema de dados da organização e por que melhorar a qualidade dos dados requer um
abordagem empresarial
• Consequências de dados de baixa qualidade
• Necessidade de melhoria contínua (por que a melhoria não é uma coisa única)
• Tornando-se 'linguagem de dados', prestes a articular o impacto dos dados na estratégia e sucesso organizacional,
relatórios regulatórios, satisfação do cliente
O treinamento também deve incluir uma introdução a quaisquer mudanças de processo, com afirmações sobre como as mudanças melhoram a
qualidade dos dados.
6. Qualidade de Dados e Governança de Dados
Um programa de qualidade de dados é mais eficaz quando faz parte de um programa de governança de dados. Muitas vezes, os problemas de
qualidade de dados são a razão para estabelecer a governança de dados em toda a empresa (consulte o Capítulo 3). A incorporação de esforços de
qualidade de dados no esforço geral de governança permite que a equipe do programa de qualidade de dados trabalhe com uma variedade de partes
interessadas e facilitadores:
• Pessoal de risco e segurança que pode ajudar a identificar vulnerabilidades organizacionais relacionadas a dados
• Engenharia de processos de negócios e equipe de treinamento que pode ajudar as equipes a implementar melhorias de processos
• Administradores de dados comerciais e operacionais e proprietários de dados que podem identificar dados críticos, definir
padrões e expectativas de qualidade, e priorizar a correção de problemas de dados
Uma Organização de Governança pode acelerar o trabalho de um programa de Qualidade de Dados ao:
• Definir prioridades
• Identificar e coordenar o acesso àqueles que devem estar envolvidos em várias atividades relacionadas à qualidade de dados
decisões e atividades
• Desenvolvimento e manutenção de padrões de qualidade de dados
• Relatar medições relevantes de qualidade de dados em toda a empresa
• Fornecer orientação que facilite o envolvimento da equipe
• Estabelecimento de mecanismos de comunicação para compartilhamento de conhecimento
• Desenvolver e aplicar políticas de qualidade e conformidade de dados
• Monitoramento e relatórios de desempenho
• Compartilhamento dos resultados da inspeção de qualidade de dados para conscientizar, identificar oportunidades de melhorias,
e construir consenso para melhorias
• Resolver variações e conflitos; fornecendo direção
6.1 Política de Qualidade de Dados
Os esforços de qualidade de dados devem ser apoiados e devem apoiar políticas de governança de dados. Por exemplo, as políticas de governança
podem autorizar auditorias periódicas de qualidade e obrigar a conformidade com padrões e melhores
494 • DMBOK2
práticas. Todas as áreas de conhecimento de gerenciamento de dados exigem algum nível de política, mas as políticas de qualidade de dados são
particularmente importantes, pois geralmente abordam requisitos regulatórios. Cada política deve incluir:
• Objetivo, escopo e aplicabilidade da política
• Definições de termos
• Responsabilidades do programa de Qualidade de Dados •
Responsabilidades de outras partes interessadas • Relatórios •
Implementação da política, incluindo links para risco, medidas
preventivas, conformidade, dados
proteção e segurança de dados
6.2 Métricas
Grande parte do trabalho de uma equipe de qualidade de dados se concentrará em medir e relatar a qualidade. As categorias de alto nível de métricas de
qualidade de dados incluem:
• Retorno do investimento: declarações sobre o custo dos esforços de melhoria versus os benefícios de dados aprimorados
qualidade
• Níveis de qualidade: Medições do número e porcentagem de erros ou violações de requisitos
dentro de um conjunto de dados ou entre conjuntos de dados
• Tendências de qualidade de dados: melhoria da qualidade ao longo do tempo (ou seja, uma tendência) em relação a limites e metas, ou
incidentes de qualidade por período
• Métricas de gerenciamento de problemas de dados:
o Contagens de problemas por dimensões de qualidade de dados o
Problemas por função de negócios e seus status (resolvidos, pendentes, escalados) o Problema por prioridade e
gravidade
o Tempo para resolver problemas
• Conformidade com os níveis de serviço: Unidades organizacionais envolvidas e equipe responsável, projeto
intervenções para avaliações de qualidade de dados, conformidade geral do processo
• Implementação do plano de qualidade de dados: como está e roteiro para expansão

Batini, Carlo e Mônica Scannapieco. Qualidade de Dados: Conceitos, Metodologias e Técnicas. Springer, 2006. Impresso.
Brackett, Michael H. Qualidade de recursos de dados: transformando maus hábitos em boas práticas. Addison-Wesley, 2000. Imprimir.
Deming, W. Edwards. Fora da Crise. The MIT Press, 2000. Imprimir.

Inglês, Larry. Melhorando o Data Warehouse e a Qualidade da Informação Empresarial: Métodos para Reduzir Custos e Aumentar Lucros. John Wiley
and Sons, 1999. Impresso.
Inglês, Larry. Qualidade da Informação Aplicada: Melhores Práticas para Melhorar Informações, Processos e Sistemas de Negócios.
Wiley Publishing, 2009. Impresso.
Evans, Nina e Price, James. “Barreiras para a implantação eficaz de ativos de informação: uma perspectiva de gestão executiva”. Revista
Interdisciplinar de Informação, Conhecimento e Gestão Volume 7, 2012. Acesso em http://bit.ly/2sVwvG4.
Fisher, Craig, Eitel Lauría, Shobha Chengalur-Smith e Richard Wang. Introdução à Qualidade da Informação. MIT
Publicações do Programa de Qualidade da Informação, 2006. Impresso. Avanços na Qualidade da Informação Book Ser.
Gottesdiner, Ellen. Requisitos por Colaboração: Workshops para Definição de Necessidades. Addison-Wesley Professional, 2002.
Imprimir.
Hass, Kathleen B. e Rosemary Hossenlopp. Desenterrando requisitos de negócios: ferramentas e técnicas de elicitação.
Management Concepts, Inc, 2007. Imprimir. Biblioteca Essencial de Análise de Negócios.
Huang, Kuan-Tsae, Yang W. Lee e Richard Y. Wang. Informação e Conhecimento de Qualidade. Prentice Hall, 1999. Impresso.
Jugulum, Rajesh. Competindo com dados de alta qualidade. Wiley, 2014. Impresso.
Lee, Yang W., Leo L. Pipino, James D. Funk e Richard Y. Wang. Jornada para a Qualidade de Dados. The MIT Press, 2006. Imprimir.
Loshin, David. Gestão do Conhecimento Empresarial: A Abordagem de Qualidade de Dados. Morgan Kaufmann, 2001. Impresso.
Loshin, David. Gerenciamento de dados mestre. Morgan Kaufmann, 2009. Impresso.
Maydanchik, Arcádia. Avaliação da qualidade dos dados. Technics Publications, LLC, 2007 Print.
McCallum, Ethan. Manual de dados ruins: Limpando os dados para que você possa voltar ao trabalho. 1ª Edição. O'Reilly, 2012.
McGilvray, Danette. Executando Projetos de Qualidade de Dados: Dez Passos para Dados de Qualidade e Informações Confiáveis. Morgan
Myers, Dan. “The Value of Using the Dimensions of Data Quality”, Information Management, agosto de 2013. http://bit.ly/2tsMYiA.
Olson, Jack E. Qualidade de Dados: A Dimensão da Precisão. Morgan Kaufmann, 2003. Impresso.
Redman, Thomas. Qualidade de dados: o guia de campo. Imprensa Digital, 2001. Impressão.
Robertson, Suzanne e James Robertson. Dominando o Processo de Requisitos: Acertar os Requisitos. 3ª edição.
Addison-Wesley Professional, 2012. Imprimir.
Sebastian-Coleman, Laura. Medindo a qualidade dos dados para melhoria contínua: uma estrutura de avaliação da qualidade dos dados.
Morgan Kaufmann, 2013. Impresso. A Série Morgan Kaufmann sobre Business Intelligence.
Tavares, Rossano. Qualidade de Dados em Gerenciamento de Clientes (CRM) e Tecnologia da Informação [Data Quality in Management of Customers
and Information Technology]. São Paulo: Catálise. 2006. Print.
Witt, Graham. Escrevendo Regras de Negócios Eficazes: Um Método Prático. Morgan Kaufmann, 2012. Impresso.
CAPÍTULO 1 4
Big Data e Ciência de Dados
1. Introdução
desde o início dos anos 2000, os termos Big Data e Data Science têm, infelizmente, sido cogitados como
S chavões. Os conceitos e suas implicações são mal compreendidos – ou, pelo menos, há
consenso sobre o seu significado. Até o significado de 'Grande' é relativo. Dito isso, tanto o Big Data quanto a Data
Science estão conectados a mudanças tecnológicas significativas que permitiram às pessoas gerar, armazenar e analisar
quantidades cada vez maiores de dados. Mais importante, as pessoas podem usar esses dados para prever e influenciar o
comportamento, bem como para obter informações sobre uma série de assuntos importantes, como práticas de saúde, gestão de
recursos naturais e desenvolvimento econômico.
Big Data não se refere apenas ao volume de dados, mas também à sua variedade (estruturados e não estruturados, documentos,
arquivos, áudio, vídeo, dados de streaming, etc.), e à velocidade com que são produzidos (velocidade). As pessoas que extraem e
desenvolvem modelos e análises preditivos, de aprendizado de máquina e prescritivos a partir deles e implantam resultados para
análise por partes interessadas são chamados de Cientistas de Dados.
Data Science existe há muito tempo; costumava ser chamado de 'estatísticas aplicadas'. Mas a capacidade de explorar padrões de
dados evoluiu rapidamente no século XXI com o advento do Big Data e das tecnologias que o suportam. O Business Intelligence
tradicional fornece relatórios de 'espelho retrovisor' – análise de dados estruturados para descrever tendências passadas. Em
alguns casos, os padrões de BI são usados para prever o comportamento futuro, mas não com alta confiança. Até recentemente, a
análise aprofundada de enormes conjuntos de dados era limitada pela tecnologia. As análises se basearam na amostragem ou em
outros meios de abstração para aproximar os padrões. À medida que a capacidade de coletar e analisar grandes conjuntos de
dados cresceu, os Cientistas de Dados integraram métodos de matemática, estatística, ciência da computação, processamento de
sinais, modelagem de probabilidade, reconhecimento de padrões, aprendizado de máquina, modelagem de incerteza e visualização
de dados para obter insights e prever comportamentos com base em conjuntos de Big Data. Em suma, a Data Science encontrou
novas maneiras de analisar e obter valor dos dados.
À medida que o Big Data foi trazido para os ambientes de armazenamento de dados e Business Intelligence, as técnicas de Data
Science são usadas para fornecer uma visão prospectiva ('pára-brisa') da organização. Os recursos preditivos, em tempo real e
baseados em modelos, usando diferentes tipos de fontes de dados, oferecem às organizações uma visão melhor sobre para onde
estão indo. (Veja a Figura 96.)
497
498 • DMBOK2
Abater
Em formação
Dados não tratados DADOS
Triângulo
Dados com contexto básico

EM FORMAÇÃO
(metadados associativos)
Inteligência de negócios
Armazenamento de Detalhamento
Dados com negócios CONHECIMENTO Visualizações de dados
Passado
Contexto ou função Relatório de exceção
Entendendo a pergunta - ENTENDIMENTO

Contexto de negócios, função e
informações relacionadas Presente
DADOS INTELIGENTES
Fonte confiável para
Decisões de negócios Futuro da ciência de dados
BIG DATA Análise preditiva
Análise Prescritiva
Data Science:
Aprendizado de máquina
Encontrando padrões/clusters
nas informações; fornecendo
insights onde não se saberia procurar
Figura 96 Triângulo de Informação de Abatimento
Para tirar proveito do Big Data, no entanto, é preciso mudar a forma como os dados são gerenciados. A maioria dos data warehouses
é baseada em modelos relacionais. O Big Data geralmente não é organizado em um modelo relacional. A maioria dos data
warehousing depende do conceito de ETL (Extrair, Transformar e Carregar). Soluções de Big Data, como data lakes, dependem do
conceito de ELT – carregar e depois transformar. Tão importante quanto, a velocidade e o volume de dados apresentam desafios que
exigem abordagens diferentes para aspectos críticos do gerenciamento de dados, como integração, gerenciamento de metadados e
avaliação de qualidade de dados.
O maior impulsionador de negócios para o desenvolvimento de capacidades organizacionais em torno de Big Data e Data Science é
o desejo de encontrar e atuar em oportunidades de negócios que podem ser descobertas por meio de conjuntos de dados gerados
por meio de uma gama diversificada de processos. O Big Data pode estimular a inovação, disponibilizando mais e maiores conjuntos
de dados para exploração. Esses dados podem ser usados para definir modelos preditivos que antecipam as necessidades do cliente
e permitem a apresentação personalizada de produtos e serviços. A Ciência de Dados pode melhorar as operações. Algoritmos de
aprendizado de máquina podem automatizar atividades complexas e demoradas, melhorando assim a eficiência organizacional, reduzindo
custos e mitigar riscos.
BIG DATA E CIÊNCIA DE DADOS • 499
Big Data e Ciência de Dados

Definição: A coleta (Big Data) e análise (Ciência de Dados, Analytics e Visualização) de muitos tipos diferentes de
dados para encontrar respostas e insights para perguntas que não são conhecidas no início da análise.
Objetivos: 1. Descobrir as relações entre os dados e o negócio.

2. Apoiar a integração iterativa de fonte(s) de dados na empresa.
3. Descobrir e analisar novos fatores que possam afetar o negócio.
4. Publique dados usando técnicas de visualização de maneira apropriada, confiável e ética.
O negócio
Motoristas

•
• Estratégia de negócio 1. Definir Estratégia e Negócios de Big Data Estratégia de Big Data e
& Objetivos Necessidades (P) Padrões
•
• Construir/Comprar/Alugar 2. Escolha Fontes de Dados (P) Plano de fornecimento de dados
Árvore de decisão 3. Adquirir e ingerir fontes de dados (D) • Dados adquiridos

• 4. Desenvolva Hipóteses e Métodos (D) Fontes
Padrões de TI
•
• Fontes de dados 5. Integrar/Alinhar Dados para Análise (D) Análise de dados inicial e
6. Explorar dados usando modelos (D) hipóteses
•
7. Implantar e monitorar (O) Informações de dados e
descobertas
• Plano de Aprimoramento

• • • Parceiros de negócios
Plataforma de Big Data Arquitetos de plataforma de big data
Arquitetos • • Executivos de negócios
Arquitetos de ingestão
• Cientistas de dados • Dados da PME • Executivos de TI
• Produtores de dados • Cientistas de dados
• •
Fornecedores de dados Líder de Design Analítico
• Consumidores de informação • Gerentes de DM
•
Especialistas em metadados
Técnico
Motoristas

• • Soluções baseadas em arquivos distribuídos •
Mashups de dados Métricas de uso de dados
•
Aprendizado de máquina • Compressão Colunar • Resposta e desempenho
Técnicas • Arquiteturas de nada compartilhado MPP Métricas
• •
• Avançado Supervisionado Computação em memória e Carregamento e digitalização de dados
Aprendendo Bancos de dados Métricas
• •
Algoritmos no banco de dados Aprendizados e histórias
• Conjuntos de ferramentas de visualização de dados
Figura 97 Diagrama de Contexto: Big Data e Ciência de Dados

500 • DMBOK2
1.2 Princípios
A promessa do Big Data – que fornecerá um tipo diferente de insight – depende da capacidade de gerenciar o Big Data. De muitas maneiras,
devido à grande variação de fontes e formatos, o gerenciamento de Big Data exigirá mais disciplina do que o gerenciamento de dados relacionais.
Os princípios relacionados ao gerenciamento de Big Data ainda não foram totalmente formados, mas um é muito claro: as organizações devem
gerenciar cuidadosamente os metadados relacionados às fontes de Big Data para ter um inventário preciso dos arquivos de dados, suas origens
e seu valor.
1.3.1 Ciência de Dados
Conforme observado na introdução do capítulo, o Data Science mescla mineração de dados, análise estatística e aprendizado de máquina com
recursos de integração e modelagem de dados para criar modelos preditivos que exploram padrões de conteúdo de dados. O desenvolvimento de
modelos preditivos às vezes é chamado de Data Science porque o analista de dados, ou cientista de dados, usa o método científico para
desenvolver e avaliar um modelo.
O cientista de dados desenvolve uma hipótese sobre o comportamento que pode ser observado nos dados antes de uma determinada ação. Por
exemplo, a compra de um tipo de item geralmente é seguida pela compra de outro tipo de item (a compra de uma casa geralmente é seguida pela
compra de móveis). Em seguida, o cientista de dados analisa grandes quantidades de dados históricos para determinar com que frequência a
hipótese foi verdadeira no passado e para verificar estatisticamente a provável precisão do modelo. Se uma hipótese for válida com frequência
suficiente e se o comportamento que ela prevê for útil, então o modelo pode se tornar a base para um processo de inteligência operacional para
prever o comportamento futuro, mesmo possivelmente em tempo real, como anúncios de venda sugestivos.
O desenvolvimento de soluções de Data Science envolve a inclusão iterativa de fontes de dados em modelos que desenvolvem insights. A Ciência
de Dados depende de:
• Fontes de dados ricas: Dados com potencial para mostrar padrões invisíveis em organizações ou
comportamento do consumidor
• Alinhamento e análise de informações: técnicas para entender o conteúdo dos dados e combinar conjuntos de dados para
hipotetizar e testar padrões significativos
• Entrega de informações: executando modelos e algoritmos matemáticos em relação aos dados e produzindo
visualizações e outras saídas para obter informações sobre o comportamento
• Apresentação de descobertas e insights de dados: Análise e apresentação de descobertas para que os insights possam
ser compartilhado
A Tabela 32 compara o papel do DW/BI tradicional com a análise preditiva e prescritiva que pode ser alcançada por meio de técnicas de Data
Science.
Tabela 32 Progressão do Analytics
DW / BI tradicional Ciência de dados
Retrospectiva Preditivo Prescritivo
Descritiva Entendimento Previsão
Com base na história: Baseado em cenários:

Com base em modelos preditivos:
O que aconteceu? O que devemos fazer para que as
O que é provável que aconteça?
Por que aconteceu? coisas aconteçam?
1.3.2 O Processo de Ciência de Dados
A Figura 98 ilustra as fases iterativas do processo de Data Science. As saídas de cada etapa tornam-se as entradas para a próxima. (Consulte
a Seção 2.)
1. Defina Grande
Estratégia de Dados
e Necessidades
de Negócios
7. Implantar 2. Escolha
& Dados
Monitor
Fontes)
6. Explorar 3. Adquirir e
Dados usando Ingerir fontes
modelos
de dados
4. Desenvolver
5. Integrar /
Hipóteses e
Alinhar dados
métodos de ciência
para análise
de dados
Figura 98 Processo de Ciência de Dados
O processo de Data Science segue o método científico de refinar o conhecimento fazendo observações, formulando e testando hipóteses,
observando resultados e formulando teorias gerais que explicam resultados.
Dentro da Data Science, esse processo assume a forma de observação de dados e criação e avaliação de modelos de comportamento:
• Defina a estratégia de Big Data e as necessidades de negócios: defina os requisitos que identificam os resultados desejados
com benefícios tangíveis mensuráveis.
• Escolha fontes de dados: identifique lacunas na base de ativos de dados atual e encontre fontes de dados para preenchê-las
lacunas.
502 • DMBOK2
• Adquira e ingira fontes de dados: obtenha conjuntos de dados e integre-os.
• Desenvolver hipóteses e métodos de Data Science: Explorar fontes de dados por meio de criação de perfil, visualização, mineração,
etc.; refinar os requisitos. Defina entradas de algoritmo de modelo, tipos ou hipóteses de modelo e métodos de análise (ou seja,
agrupamentos de dados encontrados por agrupamento, etc.).
• Integrar e alinhar dados para análise: a viabilidade do modelo depende em parte da qualidade da fonte
dados. Aproveite fontes confiáveis e confiáveis. Aplique técnicas apropriadas de integração e limpeza de dados para
aumentar a qualidade e a utilidade dos conjuntos de dados provisionados.
• Explore dados usando modelos: aplique análise estatística e algoritmos de aprendizado de máquina em relação ao
dados integrados. Valide, treine e, com o tempo, evolua o modelo. O treinamento envolve execuções repetidas do modelo em relação
a dados reais para verificar suposições e fazer ajustes, como identificar valores discrepantes.
Através deste processo, os requisitos serão refinados. As métricas iniciais de viabilidade orientam a evolução do modelo. Novas
hipóteses podem ser introduzidas que exigem conjuntos de dados adicionais e os resultados dessa exploração moldarão a
modelagem e as saídas futuras (mesmo alterando os requisitos).
• Implantar e monitorar: Os modelos que produzem informações úteis podem ser implantados na produção para monitoramento contínuo de
valor e eficácia. Muitas vezes, os projetos de Data Science se transformam em projetos de data warehousing, onde processos de
desenvolvimento mais vigorosos são implementados (ETL, DQ, Master Data, etc.).
1.3.3 Big Data
Os primeiros esforços para definir o significado de Big Data caracterizaram-no em termos dos Três V's: Volume, Velocidade, Variedade (Laney, 2001).
À medida que mais organizações começam a aproveitar o potencial do Big Data, a lista de Vs se expandiu:
• Volume: Refere-se à quantidade de dados. Big Data geralmente tem milhares de entidades ou elementos em bilhões
de registros.
• Velocidade: Refere-se à velocidade com que os dados são capturados, gerados ou compartilhados. O Big Data é frequentemente
gerados e também podem ser distribuídos e até analisados em tempo real.
• Variedade / Variabilidade: Refere-se às formas em que os dados são capturados ou entregues. Big Data requer armazenamento de
vários formatos; a estrutura de dados geralmente é inconsistente dentro ou entre conjuntos de dados.
• Viscosidade: Refere-se a quão difícil é usar ou integrar os dados.
• Volatilidade: Refere-se à frequência com que as alterações de dados ocorrem e, portanto, por quanto tempo os dados são úteis.
• Veracidade: Refere-se à confiabilidade dos dados.
Os volumes de Big Data são excepcionalmente grandes (superiores a 100 Terabyte e muitas vezes na faixa de Petabyte e Exabyte). Em soluções
analíticas e de armazenamento, volumes muito grandes de dados representam desafios para carregamento, modelagem, limpeza e análise de dados.
Esses desafios geralmente são resolvidos usando processamento massivamente paralelo ou

processamento paralelo e soluções de dados distribuídos. No entanto, eles têm implicações muito mais amplas. O tamanho dos conjuntos
de dados requer mudanças na maneira geral como os dados são armazenados e acessados, bem como na forma como os dados são
entendidos (por exemplo, muito do nosso modo atual de pensar sobre os dados é baseado em estruturas de banco de dados relacionais),
bem como como os dados são gerenciados (Adams, 2009). A Figura 99 apresenta um resumo visual da variedade de dados que se
tornaram disponíveis por meio de tecnologias de Big Data e as implicações nas opções de armazenamento de dados.
Exabyte Internet das Coisas

Sites sociais
Sensores/Scanners
Áudio vídeo
Petabytes Web 2.0 Arquivos de registro
Móvel
Marketing
comércio eletrônico
Registros da Web
Blogs/Wikis
Terabyte EDW/BW GPS
Colaboração
Publicidade
Gigabyte Clientes
Produtos Textos/Imagens
Velocidade Variedade Veracidade
Armazenar EDW/BW Web 2.0 Internet das Coisas
Figura 99 Desafios de armazenamento de dados 88
1.3.4 Componentes da Arquitetura de Big Data
A seleção, instalação e configuração de um ambiente de Big Data e Data Science requerem conhecimento especializado. As arquiteturas
de ponta a ponta devem ser desenvolvidas e racionalizadas em relação às ferramentas de exploração de dados existentes e novas
aquisições.
A Figura 100 descreve o DW/BI e a Arquitetura de Big Data. (Detalhes sobre os componentes DW/BI são descritos no Capítulo 11.) A
maior diferença entre DW/BI e processamento de Big Data é que em um data warehouse tradicional, os dados são integrados à medida
que são trazidos para o warehouse (extrair, TRANSFORMAR, carregar) ; enquanto em um ambiente de Big Data, os dados são ingeridos
e carregados antes de serem integrados (extrair, LOAD, transformar). Em alguns casos, os dados podem não ser integrados, no sentido
tradicional. Em vez de ser integrado na preparação para uso, geralmente é integrado por meio de usos específicos (por exemplo, o
processo de construção de modelos preditivos impulsiona a integração de conjuntos de dados específicos).
88 Originado e usado com permissão de Robert Abate / EMC Corporation.

504 • DMBOK2
DW/BI Conceitual e Arquitetura de Big Data
Fontes Armazém de dados COM UM
Inscrição Domínio de dados

Operacional Intervenção de qualidade de dados
Comunicando Enriquecimento e Aumento
Dependente
Área de preparo Relatório operacional
& Análises
Limpar
Geoespacial e
Operacional ODS
Integrar Análise Demográfica
Sistemas Enriquecer Armazém Central
atuação
Padronizar
Data Mart Gestão
Orientado ao assunto
Não volátil
Visualização de dados
DaaS Tempo variável
Referência &
atômico
Big Data Dados mestre
MDM Data histórica Mineração de dados e texto
Resultados Conformado Cubos
Dimensões Não estruturado
Big Data Análise

E-mail
Multimídia
© DATALEADERS.ORG
Análise preditiva
Sensores Avalie
IoT Ingerir Integrar Explorar
Rede Social
Data Lake Modelo
Web DaaS Aprendizado de máquina
DW
Figura 100 DW/BI Conceitual e Arquitetura de Big Data
A diferença entre ETL e ELT tem implicações significativas em como os dados são gerenciados. Por exemplo, o processo de
integração não depende necessariamente ou produz um modelo de dados corporativos. O risco é que muito conhecimento
sobre os dados possa ser perdido se os processos de ingestão e uso forem executados de forma ad hoc. Existe a necessidade
de coletar e gerenciar Metadados relacionados a esses processos, para que eles sejam entendidos e aproveitados
ao longo do tempo.
As seções a seguir descreverão as fontes de Big Data e a construção do Data Lake. As atividades (Ingerir, Integrar, Explorar,
Avaliar Modelo) são exploradas na seção Atividades.
1.3.5 Fontes de Big Data
Como grande parte da atividade humana é executada eletronicamente, grandes quantidades de dados estão se acumulando
todos os dias à medida que nos movemos pelo mundo, interagimos uns com os outros e realizamos negócios. O Big Data é
produzido por e-mail, mídias sociais, pedidos online e até videogames online. Os dados são gerados não apenas por
telefones e dispositivos de ponto de venda, mas também por sistemas de vigilância, sensores em sistemas de transporte,
sistemas de monitoramento médico, sistemas de monitoramento industrial e de serviços públicos, satélites e equipamentos
militares. Por exemplo, um voo de uma companhia aérea pode gerar um terabyte de dados. Dispositivos que interagem
diretamente com a Internet geram grande parte do Big Data. As conexões entre dispositivos e a Internet às vezes são
chamadas de Internet das Coisas (IoT).
1.3.6 Data Lake
Um data lake é um ambiente onde uma grande quantidade de dados de vários tipos e estruturas podem ser ingeridos, armazenados, avaliados e analisados.
Os data lakes podem servir a muitos propósitos. Por exemplo, fornecer
• Um ambiente para cientistas de dados minerar e analisar dados
• Uma área de armazenamento central para dados brutos, com transformação mínima, se houver
• Armazenamento alternativo para dados históricos detalhados do data warehouse
• Um arquivo online para registros
• Um ambiente para ingerir dados de streaming com identificação automatizada de padrões
Um data lake pode ser implementado como uma configuração complexa de ferramentas de manipulação de dados, incluindo Hadoop ou outros sistemas de
armazenamento de dados, serviços de cluster, transformação de dados e integração de dados. Esses manipuladores facilitaram o software de facilitação
analítica e de infraestrutura cruzada para reunir a configuração.
O risco de um data lake é que ele pode se tornar rapidamente um pântano de dados – confuso, sujo e inconsistente. Para estabelecer um inventário do que
está em um data lake, é fundamental gerenciar os metadados à medida que os dados são ingeridos. Para entender como os dados em um data lake estão
associados ou conectados, arquitetos de dados ou engenheiros de dados geralmente usam chaves exclusivas ou outras técnicas (modelos semânticos,
modelos de dados etc.) as informações armazenadas no data lake. (Consulte o Capítulo 9.)
1.3.7 Arquitetura Baseada em Serviços
A arquitetura baseada em serviços (SBA) está surgindo como uma maneira de fornecer dados imediatos (se não completamente precisos ou completos), bem
como atualizar um conjunto de dados históricos completo e preciso, usando a mesma fonte (Abate, Aiken, Burke, 1997). . A arquitetura SBA é semelhante às
arquiteturas DW que enviam dados diretamente para um ODS para acesso imediato, bem como para o DW para acumulação histórica. As arquiteturas SBA
têm três
componentes, uma camada de lote, uma camada de velocidade e uma camada de serviço. (Veja a Figura 101.)
• Camada de lote: um data lake serve como camada de lote, contendo dados recentes e históricos
• Camada de velocidade: contém apenas dados em tempo real
• Camada de serviço: fornece uma interface para juntar dados das camadas de lote e velocidade
Os dados são carregados nas camadas de lote e de velocidade. Todos os cálculos analíticos são realizados em dados nas camadas de lote e velocidade, o
que provavelmente requer implementação em dois sistemas separados. As organizações lidam com problemas de sincronização por meio de compensações
entre integridade, latência e complexidade de exibições mescladas definidas na camada de serviço. A avaliação de custo/benefício é necessária para
determinar se a redução da latência ou a melhoria da integridade dos dados vale o custo e a complexidade associados.
A camada de lote é frequentemente chamada de componente de estrutura ao longo do tempo (aqui cada transação é uma inserção), enquanto na camada de
velocidade (frequentemente chamada de Armazenamento de Dados Operacionais ou ODS), todas as transações são atualizações (ou apenas inserções). se
necessário). Dessa forma, a arquitetura evita problemas de sincronização enquanto cria simultaneamente um estado atual e uma camada de histórico. Essa
arquitetura geralmente fornece seus dados por meio de um

506 • DMBOK2
serviço ou camada de serviços de dados que abstrai os dados utilizando Metadados. Essa camada de serviços determina de onde os dados devem
ser 'servidos' e fornece adequadamente os dados solicitados.
Camada de velocidade
Em tempo real, sem histórico
Fonte Camada de veiculação

Dados Visualização mesclada
Camada de Lote
Totalmente processado
história
Figura 101 Arquitetura baseada em serviços
1.3.8 Aprendizado de Máquina
O Machine Learning explora a construção e o estudo de algoritmos de aprendizado. Ele pode ser visto como uma união de métodos de aprendizado
não supervisionados, mais comumente chamados de mineração de dados, e métodos de aprendizado supervisionado profundamente enraizados na
teoria matemática, especificamente estatística, combinatória e otimização. Um terceiro ramo está se formando agora chamado aprendizado por
reforço, onde o desempenho de metas é conquistado, mas não especificamente reconhecido pelo professor – dirigir um veículo, por exemplo. A
programação de máquinas para aprender rapidamente com as consultas e se adaptar a conjuntos de dados em mudança levou a um campo
completamente novo dentro do Big Data, conhecido como aprendizado de máquina . a
resultados.
O Machine Learning explora a construção e o estudo de algoritmos de aprendizado. Esses algoritmos se dividem em três
tipos:
• Aprendizagem supervisionada: Baseada em regras generalizadas; por exemplo, separando SPAM de não SPAM
o email
• Aprendizado não supervisionado: com base na identificação de padrões ocultos (ou seja, mineração de dados)
• Aprendizado por reforço: Com base na conquista de um objetivo (por exemplo, vencer um oponente no xadrez)
A modelagem estatística e o aprendizado de máquina foram empregados para automatizar projetos de pesquisa e desenvolvimento caros, realizando
várias tentativas e erros em um vasto conjunto de dados, repetindo as tentativas com os resultados coletados, analisados e os erros corrigidos. Essa
abordagem pode reduzir drasticamente o tempo de resposta e
89 Consulte a tabela periódica de recursos de aprendizado de máquina em http://bit.ly/1DpTrHC para obter um guia interativo das diferentes
plataformas disponíveis para o desenvolvedor, cientista e profissional de aprendizado de máquina.
orientar as iniciativas organizacionais com insights baseados em processos repetíveis de baixo custo. Por exemplo, o CIVDDD usa
aprendizado de máquina e técnicas complexas de visualização de dados científicos para ajudar agências governamentais e forças de paz
a enfrentar o desafio de lidar com as massas de informações relacionadas a ameaças.90
Enquanto explora os dados de novas maneiras, o aprendizado de máquina tem implicações éticas, especialmente no que diz respeito ao
princípio da transparência. As evidências mostram que as redes neurais de aprendizado profundo (DLNN) funcionam. Eles aprendem coisas.
No entanto, nem sempre é claro como eles aprendem. À medida que os algoritmos que conduzem esses processos se tornam mais
complexos, eles também se tornam mais opacos, funcionando como 'caixas pretas'. Como respondem por um maior número de variáveis e
como essas variáveis são mais abstratas, os algoritmos testam os limites da capacidade humana de interpretar a máquina (Davenport,
2017). A necessidade de transparência – a capacidade de ver como as decisões são tomadas – provavelmente aumentará à medida que
essa funcionalidade evoluir e for usada em uma variedade maior de situações. (Consulte o Capítulo
2.)
1.3.9 Análise de Sentimentos
O monitoramento de mídia e a análise de texto são métodos automatizados para recuperar informações de grandes dados não estruturados
ou semiestruturados, como dados de transações, mídias sociais, blogs e sites de notícias na web. Isso é usado para entender o que as
pessoas dizem e sentem sobre marcas, produtos ou serviços ou outros tipos de tópicos. Usando o Processamento de Linguagem Natural
(NLP) ou analisando frases ou sentenças, a análise semântica pode detectar sentimentos e também revelar mudanças no sentimento para
prever possíveis cenários.
Considere o caso de procurar palavras-chave em uma postagem. Se as palavras bom ou ótimo estiverem presentes, isso pode ser uma
resposta positiva, versus ver péssimo ou ruim pode ser um sinal de que isso pode ser uma resposta negativa.
Categorizando os dados em tipos de respostas, fica exposto o 'sentimento' de toda a comunidade ou postagem (mídias sociais como
Twitter, blogs, etc.). Dito isto, o sentimento não é facilmente adquirido, pois as palavras por si só não contam toda a história (ou seja, eu
tive um grande problema com o atendimento ao cliente). O sentimento deve interpretar as palavras no contexto. Isso requer uma
compreensão do significado da postagem – essa interpretação geralmente requer trabalho usando funções de PNL encontradas em
sistemas como o Watson da IBM.
1.3.10 Mineração de Dados e Texto
A mineração de dados é um tipo particular de análise que revela padrões nos dados usando vários algoritmos. Começou como um
desdobramento do Machine Learning, um subcampo da Inteligência Artificial. A teoria é um subconjunto de análise estatística conhecido
como aprendizado não supervisionado, onde os algoritmos são aplicados a um conjunto de dados sem conhecimento ou intenção do
resultado desejado. Enquanto as ferramentas padrão de consulta e relatório fazem perguntas específicas, as ferramentas de mineração de
dados ajudam a descobrir relacionamentos desconhecidos, revelando padrões. A mineração de dados é uma atividade fundamental durante
a fase de exploração, pois facilita a identificação rápida dos elementos de dados estudados, identifica novos relacionamentos anteriormente
desconhecidos, pouco claros ou não classificados e fornece estrutura para a classificação dos elementos de dados estudados.
90
CIVDDD, o Center for Innovation in Information and Data-Driven Design, é uma bolsa de pesquisa em análise e visualização de big
data para desenvolver técnicas de descoberta, design e visualização de dados de próxima geração para novas ferramentas
computacionais, estratégias de representação e interfaces.
508 • DMBOK2
A mineração de texto analisa documentos com análise de texto e técnicas de mineração de dados para classificar o conteúdo automaticamente em
ontologias orientadas por fluxo de trabalho e direcionadas a PMEs. Assim, a mídia de texto eletrônico pode ser analisada sem reestruturação ou
reformatação. Ontologias podem ser vinculadas a mecanismos de pesquisa, permitindo consultas habilitadas para a Web nesses documentos.
A mineração de dados e texto usa uma variedade de técnicas, incluindo:
• Criação de perfis: A criação de perfis tenta caracterizar o comportamento típico de um indivíduo, grupo ou população.
A criação de perfil é usada para estabelecer normas comportamentais para aplicativos de detecção de anomalias, como fraude
detecção e monitoramento de intrusões em sistemas de computador. Os resultados do perfil são entradas para muitos
componentes de aprendizagem não supervisionados.
• Redução de dados : a redução de dados substitui um grande conjunto de dados por um conjunto menor de dados que contém muito
das informações importantes no conjunto maior. O conjunto de dados menor pode ser mais fácil de analisar ou processar.
• Associação: Associação é um processo de aprendizado não supervisionado para encontrar relações entre
elementos baseados em transações que os envolvem. Exemplos de associação incluem: Conjunto de itens frequentes
mineração, descoberta de regras e análise baseada no mercado. Os sistemas de recomendação na internet usam este
processo também.
• Agrupamento: Agrupamento de elementos do grupo em um estudo por suas características compartilhadas. Cliente
segmentação é um exemplo de agrupamento.
• Mapas auto -organizados: Os mapas auto-organizados são um método de análise de cluster de rede neural.
Às vezes chamados de Mapas de Kohonen, ou mapas topologicamente ordenados, eles visam reduzir a
dimensionalidade no espaço de avaliação, preservando as relações de distância e proximidade tanto
possível, semelhante ao dimensionamento multidimensional. Reduzir a dimensionalidade é como remover um
variável da equação sem violar o resultado. Isso facilita a resolução e visualização.
1.3.11 Análise Preditiva
A Análise Preditiva é o subcampo do aprendizado supervisionado em que os usuários tentam modelar elementos de dados e prever resultados
futuros por meio da avaliação de estimativas de probabilidade. Enraizada profundamente na matemática, especificamente nas estatísticas, a análise
preditiva compartilha muitos componentes com o aprendizado não supervisionado, com a diferença prescrita para a medição de um resultado
preditivo desejado.
Predictive Analytics é o desenvolvimento de modelos de probabilidade baseados em variáveis, incluindo dados históricos, relacionados a possíveis
eventos (compras, mudanças de preço, etc.). Ao receber outras informações, o modelo desencadeia uma reação da organização. O fator
desencadeante pode ser um evento, como um cliente adicionando um produto a uma cesta de compras on-line, ou pode ser dados em um fluxo de
dados, como um feed de notícias ou dados de sensores de utilidade, ou um volume aumentado de solicitações de serviço . O fator desencadeante
pode ser um evento externo. As notícias divulgadas sobre uma empresa são um grande preditor de uma mudança no preço das ações. A previsão
do movimento das ações deve incluir o monitoramento de notícias e determinar se as notícias sobre uma empresa provavelmente serão boas ou
ruins para o preço das ações.

Frequentemente, o fator desencadeante é o acúmulo de um grande volume de dados em tempo real, como um número extremamente alto
de negócios ou solicitações de atendimento ou volatilidade do ambiente. O monitoramento de um fluxo de eventos de dados inclui a
construção incremental nos modelos preenchidos até que um limite seja atingido conforme definido no modelo.
A quantidade de tempo que um modelo preditivo fornece entre a previsão e o evento previsto é frequentemente muito pequena (segundos
ou menos de um segundo). O investimento em soluções de tecnologia de latência muito baixa, como bancos de dados de memória, redes
de alta velocidade e até mesmo proximidade física da fonte dos dados, otimiza a capacidade de uma organização de reagir à previsão.
A forma mais simples de modelo preditivo é a previsão. Existem muitas técnicas para tendência ou previsão com base na análise de
regressão e se beneficiam da suavização. A maneira mais simples de suavizar os dados é por meio de uma média móvel, ou mesmo uma
média móvel ponderada. Técnicas mais avançadas podem ser úteis, como a média móvel exponencial, que introduz um fator de
suavização a ser aplicado. Minimizar o erro residual dos mínimos quadrados pode ser um ponto de partida, mas várias execuções são
necessárias para determinar e otimizar o fator de suavização.
Existem modelos de suavização exponencial dupla e tripla para abordar os componentes de tendência e sazonalidade.
1.3.12 Análise Prescritiva
A análise prescritiva leva a análise preditiva um passo adiante para definir ações que afetarão os resultados, em vez de apenas prever os
resultados das ações que ocorreram. A análise prescritiva antecipa o que acontecerá, quando acontecerá e implica por que acontecerá.
Como a análise prescritiva pode mostrar as implicações de várias decisões, ela pode sugerir como aproveitar uma oportunidade ou evitar
um risco.
A análise prescritiva pode receber continuamente novos dados para re-prever e re-prescrever. Este processo pode melhorar a precisão
da previsão e resultar em melhores prescrições.
1.3.13 Análise de Dados Não Estruturados
A análise de dados não estruturados combina mineração de texto, associação, agrupamento e outras técnicas de aprendizado não
supervisionado para codificar grandes conjuntos de dados. Técnicas de aprendizado supervisionado também podem ser aplicadas para
fornecer orientação, supervisão e orientação no processo de codificação, alavancando a intervenção humana para resolver a ambiguidade quando
necessário.
A análise de dados não estruturados está se tornando mais importante à medida que mais dados não estruturados são gerados. Algumas
análises são impossíveis sem a capacidade de incorporar dados não estruturados em modelos analíticos. No entanto, dados não
estruturados são difíceis de analisar sem alguma forma de isolar os elementos de interesse de elementos estranhos.
A digitalização e a marcação são uma maneira de adicionar 'ganchos' a dados não estruturados que permitem filtrar e vincular dados
estruturados relacionados. No entanto, saber quais tags gerar com base em quais condições é difícil. É um processo iterativo, desde
quando as condições de tag propostas são identificadas, as tags são atribuídas à medida que os dados são ingeridos, então a análise usa
essas tags para validar a condição da tag e analisar os dados marcados, o que leva a condições de tag potencialmente alteradas ou mais
Tag.
510 • DMBOK2
1.3.14 Análise Operacional
O conceito de análise operacional (também conhecido como BI operacional ou análise de streaming) surgiu da integração da análise
em tempo real nas operações. A análise operacional inclui atividades como segmentação de usuários, análise de sentimentos,
geocodificação e outras técnicas aplicadas a conjuntos de dados para análise de campanhas de marketing, penetração de vendas,
adoção de produtos, otimização de ativos e gerenciamento de riscos.
A análise operacional envolve rastrear e integrar fluxos de informações em tempo real, derivar conclusões com base em modelos
preditivos de comportamento e acionar respostas e alertas automáticos. Projetar o modelo, os gatilhos e as respostas necessárias
para uma análise bem-sucedida exige mais análise dos próprios dados. Uma solução de análise operacional inclui a preparação de
dados históricos para pré-preenchimento dos modelos de comportamento. Por exemplo, em um modelo de produto de varejo,
preencher uma análise de cesta de compras que identifica produtos frequentemente comprados juntos. Na previsão do comportamento
dos mercados financeiros, as informações históricas de preços e a taxa de variação histórica dos preços são usadas regularmente. Os
cálculos de pré-população geralmente são realizados com antecedência para permitir respostas oportunas aos eventos desencadeantes.
Uma vez que os modelos preditivos tenham sido considerados úteis e econômicos, soluções que integram dados históricos e atuais
(incluindo dados em tempo real e streaming, estruturados e não estruturados) são implementadas para preencher os modelos
preditivos e desencadear ações com base nas previsões. A solução deve garantir que os fluxos de dados em tempo real usando as
regras do modelo sejam processados corretamente e que as respostas automatizadas a eventos significativos nos dados sejam
geradas corretamente.
1.3.15 Visualização de Dados 91
A visualização é o processo de interpretar conceitos, ideias e fatos usando imagens ou representações gráficas. A visualização de
dados facilita a compreensão dos dados subjacentes, apresentando-os em um resumo visual, como um gráfico. As visualizações de
dados condensam e encapsulam dados de características, tornando-os mais fáceis de ver. Ao fazer isso, eles podem apresentar
oportunidades, identificar riscos ou destacar mensagens.
As visualizações de dados podem ser entregues em um formato estático, como um relatório publicado, ou um formato online mais
interativo; e alguns suportam a interação do usuário final, onde os recursos de perfuração ou filtragem facilitam a análise de dados na
visualização. Outros permitem que a visualização seja alterada pelo usuário sob demanda por meio de exibições inovadoras, como
mapas de dados e paisagens móveis de dados ao longo do tempo.
A visualização tem sido fundamental para a análise de dados. As ferramentas tradicionais de BI incluem opções de visualização como
tabelas, gráficos de pizza, gráficos de linhas, gráficos de área, gráficos de barras, histogramas e caixas prontas para uso (castiçais).
Para atender à crescente necessidade de entender os dados, o número de ferramentas de visualização aumentou e as técnicas foram
aprimoradas.
91 A visualização de dados é um campo em evolução. Os princípios aplicados na visualização de dados são baseados em princípios de
design. Ver Tufte, 2001 e McCandless 2012. Existem vários recursos baseados na web com exemplos e contra-exemplos. Consulte a
Tabela Periódica de Métodos de Visualização em Visual Literacy.Org http://bit.ly/IX1bvI.
À medida que a análise de dados amadurece, visualizar dados de novas maneiras oferecerá vantagens estratégicas. Ver novos padrões nos
dados pode resultar em novas oportunidades de negócios. À medida que a visualização de dados continua a evoluir, as organizações terão que
aumentar suas equipes de Business Intelligence para competir em um mundo cada vez mais orientado por dados. Os departamentos analíticos
de negócios buscarão especialistas em dados com habilidades de visualização, incluindo cientistas de dados, artistas de dados e especialistas
em visão de dados, além de arquitetos de informações e modeladores de dados tradicionais, especialmente devido aos riscos associados à
visualização enganosa. (Consulte o Capítulo 2.)
1.3.16 Mashups de dados
Os mashups combinam dados e serviços para criar visualizações para insights ou análises. Muitas ferramentas de virtualização permitem
mashups por meio de funcionalidades que relacionam fontes de dados por elementos de dados comuns, originalmente usados para relacionar
um nome ou texto descritivo a um código armazenado. Essa técnica de mashup de apresentação ao cliente é ideal durante as fases de
descoberta ou exploração, pois oferece benefícios imediatos. Essa técnica pode ser prontamente aplicada à web, onde os mashups de dados
seguros permitem o compartilhamento de informações pessoais ou confidenciais entre fornecedores ou provedores. Isso pode ser combinado
com algoritmos de aprendizado de inteligência artificial para expor serviços baseados na Internet com interfaces de linguagem natural.
2. Atividades
2.1 Definir Estratégia de Big Data e Necessidades de Negócios
A estratégia de Big Data de uma organização precisa estar alinhada e apoiar sua estratégia geral de negócios e requisitos de negócios e fazer
parte de sua estratégia de dados. Uma estratégia de Big Data deve incluir critérios para avaliar:
• Quais problemas a organização está tentando resolver. Para que ele precisa de análise: enquanto um
A vantagem da Ciência de Dados é que ela pode fornecer uma nova perspectiva sobre uma organização, a organização
ainda precisa ter um ponto de partida. Uma organização pode determinar que os dados devem ser usados para
compreender o negócio ou o ambiente de negócios; provar ideias sobre o valor de novos produtos;
explorar algo que é desconhecido; ou inventar uma nova maneira de fazer negócios. É importante
estabelecer um processo de gating para avaliar essas iniciativas em várias fases durante a implementação. o
o valor e a viabilidade das iniciativas precisam ser avaliados em vários momentos.
• Quais fontes de dados usar ou adquirir: fontes internas podem ser fáceis de usar, mas também podem ser limitadas em
alcance. Fontes externas podem ser úteis, mas estão fora do controle operacional (gerenciadas por outros ou não
controlado por qualquer pessoa, como no caso das redes sociais). Muitos fornecedores estão competindo neste espaço e
muitas vezes existem várias fontes para os elementos ou conjuntos de dados desejados. Adquirindo dados que se integram com
itens de ingestão existentes podem reduzir os custos gerais de investimento.

512 • DMBOK2
• A pontualidade e o escopo dos dados a serem fornecidos: Muitos elementos podem ser fornecidos em tempo real
feeds, instantâneos em um ponto no tempo, ou mesmo integrados e resumidos. Dados de baixa latência são ideais, mas
muitas vezes vem à custa dos recursos de aprendizado de máquina – há uma enorme diferença entre
algoritmos computacionais direcionados a dados em repouso versus streaming. Não minimize o nível de
integração necessária para uso downstream.
• O impacto e relação com outras estruturas de dados: pode ser necessário haver estrutura ou conteúdo
alterações em outras estruturas de dados para torná-los adequados para integração com conjuntos de Big Data.
• Influências em dados modelados existentes: incluindo estender o conhecimento sobre clientes, produtos e
abordagens de marketing.
A estratégia orientará o escopo e o tempo do roteiro de capacidade de Big Data de uma organização.
2.2 Escolha as fontes de dados
Como em qualquer projeto de desenvolvimento, a escolha de fontes de dados para o trabalho de Data Science deve ser orientada pelo
problemas que a organização está tentando resolver. A diferença com o desenvolvimento de Big Data / Data Science é que a gama de fontes de
dados é mais ampla. Não é limitado pelo formato e pode incluir dados externos e internos a uma organização. A capacidade de incorporar esses
dados em uma solução também traz riscos. A qualidade e a confiabilidade dos dados precisam ser avaliadas e um plano para uso ao longo do
tempo precisa ser implementado. Os ambientes de Big Data possibilitam a ingestão rápida de muitos dados, mas para usar esses dados e
gerenciá-los ao longo do tempo, ainda é necessário conhecer fatos básicos:
• Sua origem
• Seu formato
• O que os elementos de dados representam

• Como ele se conecta a outros dados
• Com que frequência será atualizado
À medida que mais dados se tornam disponíveis (como US Census Bureau Statistics, dados demográficos de compras, dados de satélites
meteorológicos, conjuntos de dados de pesquisa), os dados precisam ser avaliados quanto ao valor e à confiabilidade. Revise as fontes de dados
disponíveis e os processos que criam essas fontes e gerencie o plano para novas fontes.
• Dados fundamentais: considere componentes de dados fundamentais, como POS (Point of Sale) em um
análise.
• Granularidade: Idealmente, obtenha dados em sua forma mais granular (não agregada). Dessa forma pode ser
agregados para uma série de propósitos.
• Consistência: Se possível, selecione os dados que aparecerão de forma adequada e consistente em
visualizações ou reconhecer limitações.
• Confiabilidade: Escolha fontes de dados que sejam significativas e confiáveis ao longo do tempo. Use confiável e autoritário
fontes.
• Inspecione/crie o perfil de novas fontes: teste as alterações antes de adicionar novos conjuntos de dados. Material inesperado ou
mudanças significativas nos resultados de visualização podem ocorrer com a inclusão de novas fontes de dados.
Os riscos associados às fontes de dados incluem preocupações com a privacidade. A capacidade de ingerir e integrar rapidamente dados de
uma variedade de fontes em escala oferece às comunidades a capacidade de recombinar conjuntos de dados que, de outra forma, eram
protegidos. Da mesma forma, a análise publicada pode descrever, por meio de resumo, agregado ou estado modelado, um subconjunto do
público que o torna subitamente identificável; este é um efeito colateral da capacidade de realizar computação em massa em populações
muito grandes, mas publicar em um local ou região muito específica. Por exemplo, quando dados demográficos calculados em nível nacional
ou de país rapidamente se tornam não identificáveis, mas não quando publicados após a filtragem de um código postal ou nível de domicílio.92
Os critérios usados para selecionar ou filtrar dados também representam um risco. Esses critérios devem ser gerenciados objetivamente para
evitar vieses ou distorções. A filtragem pode ter um impacto material na visualização. A discrição é necessária ao remover valores discrepantes,
restringir conjuntos de dados a um domínio limitado ou descartar elementos esparsos. É prática comum focar os dados provisionados para
enfatizar os resultados do isolamento, mas isso deve ser feito de forma objetiva e uniforme.93 (Consulte o Capítulo 2.)
2.3 Adquirir e ingerir fontes de dados
Uma vez que as fontes são identificadas, elas precisam ser encontradas, às vezes compradas e ingeridas (carregadas) no ambiente de Big
Data. Durante esse processo, capture Metadados críticos sobre a fonte, como sua origem, tamanho, moeda e conhecimento adicional sobre
o conteúdo. Muitos mecanismos de ingestão perfilam os dados à medida que são ingeridos, fornecendo aos analistas pelo menos Metadados
parciais. Uma vez que os dados estejam em um data lake, eles podem ser avaliados quanto à adequação para vários esforços de análise.
Como a construção de modelos de Data Science é um processo iterativo, a ingestão de dados também é.
Identifique de forma iterativa as lacunas na base de ativos de dados atual e integre essas fontes. Explore essas fontes de dados usando
criação de perfil, visualização, mineração ou outros métodos de Data Science para definir entradas de algoritmo de modelo ou hipóteses de
modelo.
Antes de integrar os dados, avalie sua qualidade. A avaliação pode ser uma consulta tão simples para descobrir quantos campos contêm
valores nulos ou tão complexa quanto a execução de um conjunto de ferramentas de qualidade de dados ou utilitário de análise de dados em
relação aos dados para criar perfil, classificar e identificar relacionamentos entre elementos de dados. Essa avaliação fornece informações
sobre se os dados fornecem uma amostra válida a partir da qual trabalhar e, em caso afirmativo, como os dados podem ser armazenados e
acessados (dispersos por unidades de processamento lógico [MPP], federados, distribuídos por chave etc.). Esse trabalho envolve PMEs
(geralmente os próprios cientistas de dados) e engenheiros de plataforma.
O processo de avaliação fornece informações valiosas sobre como os dados podem ser integrados a outros conjuntos de dados, como dados
mestres ou dados históricos do warehouse. Ele também fornece informações que podem ser usadas em conjuntos de treinamento de modelo
e atividades de validação.
92 Ver Martin Fowler, Datensparsamkeit. Blog, 12 de dezembro de 2013. Fowler questiona a suposição de que devemos
sempre capturar o máximo de dados possível. Ele ressalta que a abordagem “capture tudo” traz riscos à privacidade. Em
seu lugar, ele apresenta a ideia de minimização de dados ou esparsidade de dados (do termo alemão Datensparsamkeit)
http://bit.ly/1f9Nq8K.
93 Para obter mais informações sobre o impacto do viés, que pode afetar profundamente a interpretação dos resultados científicos, consulte o
seguintes sites: INFORMS é a principal associação internacional para profissionais de Pesquisa Operacional e Analytics.
http://bit.ly/2sANQRW, Statistical Society of Canada: http://bit.ly/2oz2o5H e American Statistical Association: http://bit.ly/
1rjAmHX.
514 • DMBOK2
2.4 Desenvolver hipóteses e métodos de dados
Data Science trata da construção de conjuntos de respostas que podem encontrar significado ou insights nos dados. O desenvolvimento de
soluções de Data Science envolve a construção de modelos estatísticos que encontram correlações e tendências dentro e entre elementos de
dados e conjuntos de dados. Haverá várias respostas para uma pergunta com base nas entradas de um modelo. Por exemplo, deve-se escolher
uma taxa de retorno para calcular o valor futuro de uma carteira financeira. Os modelos geralmente têm mais de uma variável, portanto, a
melhor prática é encontrar resultados determinísticos – ou, em outras palavras, usar as melhores estimativas quanto aos valores a serem
esperados. No entanto, os melhores palpites devem ser educados. Cada modelo funcionará dependendo do método de análise escolhido. Deve
ser testado para uma série de resultados, mesmo os que parecem menos prováveis.
Os modelos dependem tanto da qualidade dos dados de entrada quanto da solidez do próprio modelo. Os modelos de dados geralmente podem
fornecer informações sobre como correlacionar as informações encontradas. Um exemplo disso é usar o agrupamento K-Means para determinar
o número de agrupamentos de dados a serem analisados posteriormente. (Consulte o Capítulo 13.)
2.5 Integrar/Alinhar Dados para Análise
Preparar os dados para análise envolve entender o que está nos dados, encontrar links entre dados de várias fontes e alinhar dados comuns
para uso.
Em muitos casos, juntar fontes de dados é mais uma arte do que uma ciência. Por exemplo, considere um conjunto de dados baseado em
atualizações diárias e outro baseado em atualizações mensais. Os dados diários, para serem alinhados, teriam que ser agregados para que
houvesse um padrão de alinhamento que pudesse ser utilizado na investigação de Data Science.
Um método é usar um modelo comum que integre os dados usando uma chave comum. Outra maneira é varrer e juntar dados usando índices
dentro dos mecanismos de banco de dados para similaridade e algoritmos e métodos de vinculação de registros.
Muitas vezes, os dados são inspecionados durante as fases iniciais para entender como os dados podem ser analisados. O agrupamento ajuda
a determinar o agrupamento das saídas de dados. Outros métodos podem encontrar correlações que serão usadas para construir o modelo
para exibir os resultados. Considere o uso de técnicas durante as fases iniciais que ajudarão a entender como o modelo mostrará os resultados
depois de publicado.
A maioria das soluções requer a integração de dados mestre e dados de referência para interpretar os resultados da análise. (Consulte o
Capítulo 10.)
2.6 Explorar dados usando modelos
2.6.1 Preencher Modelo Preditivo
A configuração de modelos preditivos inclui o preenchimento prévio do modelo com informações históricas relativas ao cliente, mercado,
produtos ou outros fatores incluídos no modelo que não sejam o fator desencadeante. Os cálculos pré-população geralmente são realizados
com antecedência para permitir a resposta mais rápida aos eventos desencadeantes. Por
Por exemplo, o histórico de compras do cliente seria necessário para pré-preencher um modelo de recomendação de cesta de mercado de
varejo. Na previsão do comportamento dos mercados de varejo, as informações históricas de preços e alterações de preços são combinadas
com informações de clientes, demográficas e meteorológicas.
2.6.2 Treinar o Modelo
Execute o modelo em relação aos dados para 'treinar' o modelo. O treinamento inclui execuções repetidas do modelo em relação aos dados
para verificar suposições. O treinamento resultará em mudanças no modelo. O treino exige equilíbrio.
Evite o ajuste excessivo treinando contra uma dobra de dados limitada.
A validação do modelo deve ser concluída antes da transição para a produção. Aborde quaisquer desequilíbrios populacionais ou vieses de
dados com compensações de modelo que são treinadas e validadas; isso pode ser ajustado na produção à medida que o deslocamento
inicial é ajustado gradualmente por meio de interações reais da população. A otimização da combinação de recursos pode ser realizada com
co-seleção Bayesiana, inversão de classificador ou indução de regras. Os modelos também podem ser combinados para aprendizado de
conjunto em que o modelo preditor é construído combinando os pontos fortes coletados de modelos mais simples.
A identificação de outliers ou anomalias (objetos de dados que não atendem ao comportamento geral exibido pelos elementos estudados) é
fundamental para a avaliação do modelo. Para conjuntos de dados mais voláteis, aplique um teste de variação com base na média e no
desvio padrão. Ambos os testes podem ser prontamente aplicados em resultados perfilados. Pode ser que os outliers sejam o alvo do
exercício, ao invés de encontrar e validar tendências na maioria dos dados.
Para análise preditiva, use um fluxo de dados em tempo real para concluir a população do modelo preditivo e acionar uma resposta, que
pode ser um alerta ou um evento. O fluxo de dados pode exigir foco especial no projeto e desenvolvimento de uma capacidade de
processamento de latência extremamente baixa. Em alguns modelos, a diferença de valor das previsões entre frações de segundo é extrema
e as soluções podem exigir tecnologia inovadora com limitações de velocidade da luz.
Os modelos podem usar muitas funções e técnicas estatísticas disponíveis em bibliotecas de código aberto, uma das quais é 'R.' O Projeto
R para Computação Estatística é um ambiente de software livre para computação estatística; ele contém muitas funções como chamadas
de serviço.94 As funções personalizadas podem ser desenvolvidas aproveitando a linguagem de script e compartilhadas entre ferramentas,
plataformas e organizações.
Uma vez que o design da solução tenha sido criado e o desenvolvimento e a operação estimados, a organização pode decidir se
desenvolverá a solução para prever o comportamento. As soluções de análise operacional em tempo real geralmente exigem quantidades
substanciais de nova arquitetura e desenvolvimento e podem não ser rentáveis.
2.6.3 Avaliar Modelo
Uma vez que os dados são colocados em uma plataforma e prontos para análise, o Data Science começa. O modelo é construído, avaliado
em relação aos conjuntos de treinamento e validado. Refinamentos aos requisitos de negócios são
94 Para mais informações, visite o site do R-Project: http://bit.ly/19WExR5.

516 • DMBOK2
esperado neste momento e as métricas de viabilidade iniciais podem orientar os esforços de gerenciamento para processamento ou descarte
adicional. É inteiramente possível que testar uma nova hipótese exija conjuntos de dados adicionais.
Os cientistas de dados executam consultas e algoritmos nos dados para ver se algum insight se torna aparente. Muitas vezes, várias funções
matemáticas diferentes serão executadas para ver se algum insight é encontrado (clusters nos dados, padrões que começam a surgir entre os
períodos dos elementos de dados, etc.). Durante esse período, os cientistas de dados geralmente se baseiam em insights encontrados em lotes
iterativos. A partir deles, podem ser desenvolvidos modelos que exibem a correlação entre elementos de dados e insights.
Há um componente ético na prática de Data Science e ele precisa ser aplicado na avaliação de modelos.
Os modelos podem ter resultados inesperados ou refletir involuntariamente as suposições e preconceitos das pessoas que os criam. O treinamento
ético deve ser exigido para todos os profissionais de inteligência artificial (IA). Idealmente, o currículo de todos os alunos que aprendem IA, ciência
da computação ou ciência de dados deve incluir tópicos de ética e segurança. No entanto, a ética por si só não é suficiente. A ética pode ajudar os
profissionais a entender suas responsabilidades com todas as partes interessadas, mas o treinamento ético precisa ser aumentado com a
capacidade técnica de colocar boas intenções em prática, tomando precauções técnicas à medida que um sistema é construído e testado (Executive
Office, 2016). (Consulte o Capítulo 2.)
2.6.4 Criar visualizações de dados
A visualização de dados baseada no modelo deve atender às necessidades específicas relacionadas ao propósito do modelo. Cada visualização
deve responder a uma pergunta ou fornecer uma visão. Estabeleça a finalidade e os parâmetros para a visualização: um status de ponto no tempo,
tendências versus exceções, relações entre partes móveis, diferenças geográficas ou algum outro ponto.
Selecione o visual apropriado para cumprir esse propósito. Certifique-se de que a visualização se dirige a um público; ajuste o layout e a
complexidade para destacar e simplificar adequadamente. Nem todos os públicos estão prontos para um gráfico interativo complexo. Suporta
visualizações com texto explicativo.
As visualizações devem contar uma história. A 'contação de histórias' de dados pode vincular novas questões ao contexto da exploração de dados.
As histórias de dados devem ser suportadas por visualizações de dados relacionadas para ter o melhor efeito.
2.7 Implantar e Monitorar
Um modelo que atenda às necessidades de negócios de maneira viável pode ser implantado na produção para monitoramento contínuo.
Tais modelos exigirão refinamento e manutenção. Várias técnicas de modelagem estão disponíveis para implementação. Os modelos podem servir
processos em lote, bem como mensagens de integração em tempo real. Eles também podem ser incorporados ao software de análise como entrada
em sistemas de gerenciamento de decisões, análise histórica ou painéis de gerenciamento de desempenho.

2.7.1 Expor insights e descobertas
A apresentação de descobertas e insights de dados, geralmente por meio de visualização de dados, é a etapa final de uma investigação de Data
Science. Insights devem ser conectados a itens de ação para que a organização se beneficie do
Trabalho de Ciência de Dados.
Novos relacionamentos podem ser explorados por meio de técnicas de visualização de dados. À medida que um modelo é usado, mudanças nos
dados e relacionamentos subjacentes podem surgir, contando uma nova história sobre os dados.
2.7.2 Iterar com Fontes de Dados Adicionais
A apresentação de descobertas e insights de dados geralmente gera perguntas que iniciam um novo processo de pesquisa.
A Ciência de Dados é iterativa, portanto, o desenvolvimento de Big Data é iterativo para apoiá-lo. Esse processo de aprendizado de um conjunto
específico de fontes de dados geralmente leva à necessidade de fontes de dados diferentes ou adicionais para apoiar as conclusões encontradas
e adicionar insights ao(s) modelo(s) existente(s).
3. Ferramentas
Avanços na tecnologia (Lei de Moore, a proliferação de dispositivos portáteis, IOT, para citar alguns) criaram a indústria de Big Data e Data Science.
Para entender a indústria, é preciso entender seus drivers.
Esta seção explicará as ferramentas e tecnologias que permitiram o surgimento da Big Data Science.
O advento do Massively Parallel Processing (MPP) foi um dos primeiros capacitadores para Big Data e Data Science
uma vez que forneceu os meios para analisar grandes volumes de informação em períodos de tempo relativamente curtos. Encontrar a agulha no
palheiro da informação ou usar máquinas para arar toneladas de terra para encontrar as pepitas de ouro é o que estamos fazendo hoje. Essa
tendência vai continuar.
Outros avanços que mudaram a maneira como analisamos dados e informações incluem:
• Análise avançada no banco de dados
• Análise de dados não estruturados (Hadoop, MapReduce)
• Integração de resultados analíticos com sistemas operacionais
• Visualizações de dados em várias mídias e dispositivos
• Vinculando informações estruturadas e não estruturadas usando semântica
• Novas fontes de dados usando IOT
• Recursos avançados de visualização
• Recursos de enriquecimento de dados
• Tecnologias de colaboração e conjuntos de ferramentas
Os data warehouses, data marts e armazenamentos de dados operacionais (ODS) existentes estão sendo ampliados para transportar a carga de
trabalho de Big Data. As tecnologias NoSQL permitem armazenamento e consulta de dados não estruturados e semiestruturados.
518 • DMBOK2
O acesso a dados não estruturados costumava ocorrer em grande parte por meio de uma interface de consulta em lote que resultava em
execução agendada lenta e tempos de resposta insatisfatórios. Vários bancos de dados NoSQL já estão disponíveis com designs que abordam
limitações específicas nesse processo de aquisição. Bancos de dados distribuídos escaláveis fornecem automaticamente recursos de
fragmentação (a capacidade de escalar entre servidores nativamente) para execução de consultas paralelas. É claro que, como em qualquer
outro banco de dados, a definição estrutural e o mapeamento para conjuntos de dados não estruturados permanecem em grande parte processos manuais.
Os recursos imediatos de consulta, relatório e análise podem ser satisfeitos com tecnologias de memória de Big Data que permitem que os
usuários finais construam consultas semelhantes a SQL para acessar dados não estruturados. Existem também adaptadores para SQL para
algumas ferramentas que transmitirão um processo NoSQL e retornarão uma consulta compatível com SQL – com limitações e ressalvas. As
tecnologias de adaptador podem permitir que as ferramentas existentes sejam usadas para consulta de dados não estruturados.
Conjuntos de ferramentas de critérios de decisão, ferramentas de implementação de processos e ofertas de serviços profissionais podem
facilitar e agilizar o processo de escolha de um conjunto inicial de ferramentas. Assim como na aquisição de ferramentas de BI, é fundamental
avaliar todas as opções: construir, comprar ou alugar (provisionado como software como serviço). Conforme observado no Capítulo 11, as
ferramentas de fornecimento de nuvem e a experiência associada devem ser ponderadas em relação ao custo de construir do zero ou implantar
produtos adquiridos de fornecedores. A atualização contínua e os custos potenciais de substituição também devem ser considerados.
O alinhamento com um conjunto de OLA pode cobrir os custos previstos e fornecer informações para definir taxas e penalidades atraentes
por violações de prazo.
3.1 Tecnologias e Arquitetura sem Compartilhamento MPP
Processamento Massivamente Paralelo (MPP) As tecnologias de banco de dados sem compartilhamento se tornaram a plataforma padrão para
análise orientada para a ciência de dados de conjuntos de Big Data. Nos bancos de dados MPP, os dados são particionados (distribuídos
logicamente) em vários servidores de processamento (nós computacionais), com cada servidor tendo sua própria memória dedicada para
processar os dados localmente. A comunicação entre os servidores de processamento geralmente é controlada por um host mestre e ocorre
por meio de uma interconexão de rede. Não há compartilhamento de disco ou contenção de memória, daí o nome 'nada compartilhado'.
O MPP evoluiu porque os paradigmas de computação tradicionais (índices, conjuntos de dados distribuídos etc.) não forneciam tempos de
resposta aceitáveis em tabelas massivas. Mesmo a mais poderosa das plataformas de computação (computador Cray) levaria muitas horas ou
até dias para computar um algoritmo complexo em uma tabela de trilhões de linhas.
Considere agora uma série de servidores de hardware comuns, todos alinhados e controlados por meio de um host. Cada uma recebe parte da
consulta para ser executada nessa tabela de trilhões de linhas segmentada ou distribuída. Se houver, por exemplo, 1.000 servidores de
processamento, a consulta muda de acessar um trilhão de linhas em uma tabela para acessar 1.000 bilhões de tabelas de linhas. Esse tipo de
arquitetura de computação é linearmente escalável, o que aumenta o apelo para cientistas de dados e usuários de Big Data que exigem uma
plataforma escalável para incorporar o crescimento.
Essa tecnologia também permitiu funções analíticas no banco de dados – a capacidade de executar funções analíticas (como K-means
Clustering, Regression, etc.) no nível do processador. A distribuição da carga de trabalho para o nível do processador acelera bastante as
consultas analíticas – alimentando assim a inovação em Data Science.
Um sistema que distribui dados automaticamente e paraleliza cargas de trabalho de consulta em todo o hardware disponível (localizado) é a
solução ideal para análise de Big Data.

BIG DATA E CIÊNCIA DE DADOS • 51 9
SQL
MapReduce
Mestre
Servidores
Interconexão
Ônibus
Segmento
Servidores
Externo
Fontes
Figura 102 Arquitetura de Aparelho Colunar 95
Os volumes de dados estão crescendo rapidamente. As empresas podem aumentar a capacidade e o desempenho de seus sistemas ao
longo do tempo adicionando novos nós. O MPP facilita a expansão do paralelismo de centenas ou milhares de núcleos em um conjunto
cada vez maior de máquinas. Uma arquitetura massivamente paralela e sem compartilhamento usa totalmente cada núcleo, com
escalabilidade linear e maior desempenho de processamento em grandes conjuntos de dados.
3.2 Bancos de dados baseados em arquivos distribuídos
As tecnologias de soluções baseadas em arquivos distribuídos, como o Hadoop de código aberto, são uma maneira barata de armazenar
grandes quantidades de dados em diferentes formatos. O Hadoop armazena arquivos de qualquer tipo – estruturados, semiestruturados e
não estruturados. Usando uma configuração semelhante ao MPP Shared-nothing (uma base MPP para armazenamento de arquivos), ele
compartilha arquivos entre servidores de processamento. É ideal para armazenar dados com segurança (já que são feitas muitas cópias),
mas tem desafios ao tentar permitir o acesso aos dados por meio de mecanismo estruturado ou analítico (como SQL).
Devido ao seu custo relativamente baixo, o Hadoop tornou-se a zona de destino preferida de muitas organizações. A partir do Hadoop, os
dados podem ser movidos para bancos de dados MPP Shared-nothing para que algoritmos sejam executados neles. Algumas organizações
executam consultas complexas de ciência de dados no Hadoop e não se preocupam com os tempos de resposta na ordem de horas e dias
(em vez de minutos para a arquitetura anterior).
A linguagem usada em soluções baseadas em arquivo é chamada MapReduce. Essa linguagem tem três etapas principais:
• Mapa: Identifique e obtenha os dados a serem analisados
• Shuffle: Combine os dados de acordo com os padrões analíticos desejados
95 Fonte da imagem: “Greenplum Database 4.0: Critical Mass Innovation”, White Paper, agosto de 2010.
520 • DMBOK2
• Reduzir: Remova a duplicação ou realize a agregação para reduzir o tamanho dos dados resultantes
definir apenas o que é necessário
Essas etapas podem ser combinadas em muitas ferramentas diferentes de maneiras diferentes, tanto em sequência quanto em paralelo, para fazer
manipulações complexas.
3.3 Algoritmos no banco de dados
Um algoritmo no banco de dados usa o princípio de que cada um dos processadores em uma plataforma MPP Shared-nothing pode executar
consultas independentemente, de modo que uma nova forma de processamento analítico pode ser realizada fornecendo funções matemáticas e
estatísticas no nível do nó de computação. Bibliotecas de código aberto de algoritmos de banco de dados escaláveis para aprendizado de máquina,
estatísticas e outras tarefas analíticas foram projetadas para execução dentro e fora do núcleo e para o paralelismo sem compartilhamento oferecido
pelos modernos mecanismos de banco de dados paralelos, garantindo que o cálculo é feito próximo aos dados. Ao aproximar a computação dos
dados, o tempo de computação é drasticamente reduzido para algoritmos complexos (como agrupamento K-means, regressão logística ou linear,
teste U de Mann-Whitney, gradiente conjugado, análise de coorte etc.).
3.4 Soluções em Nuvem de Big Data
Existem fornecedores que fornecem armazenamento em nuvem e integração para Big Data, incluindo recursos analíticos.
Com base em padrões definidos, os clientes carregam seus dados em um ambiente em nuvem. O fornecedor aprimora os dados, seja como
conjuntos de dados abertos ou fornecidos por outras organizações. O cliente pode fazer análises e Data Science usando o conjunto de dados
combinado. Um aplicativo usa ofertas de varejo como assunto para os dados, combina-os com dados geográficos e de vendas e oferece milhas
aéreas para clientes que concordam em ter seus dados usados dessa maneira.
3.5 Computação Estatística e Linguagens Gráficas
R é uma linguagem de script de código aberto e ambiente para computação estatística e gráficos. Ele fornece uma ampla variedade de técnicas
estatísticas, como modelagem linear e não linear, testes estatísticos clássicos, análise de séries temporais, classificação e agrupamento. Por ser
uma linguagem de script, os modelos desenvolvidos em R podem ser implementados em uma variedade de ambientes, plataformas diferentes e
desenvolvimento colaborativo em vários limites geográficos e organizacionais. O ambiente R também pode produzir gráficos com qualidade de
publicação, incluindo símbolos matemáticos e fórmulas, sob o controle do usuário final.
3.6 Ferramentas de Visualização de Dados
As ferramentas tradicionais de visualização de dados têm um componente de dados e um componente gráfico. As ferramentas avançadas de
visualização e descoberta usam a arquitetura na memória para permitir que os usuários interajam com os dados. Padrões em um grande conjunto de dados
pode ser difícil de reconhecer em uma exibição de números. Um padrão visual pode ser captado rapidamente quando milhares de pontos de
dados são carregados em um display sofisticado.
Gráficos de informação ou infográficos são representações gráficas estilizadas para interação e compreensão efetivas. O marketing os adotou
para fornecer apelo visual às apresentações. Jornalistas, blogueiros e professores acharam os infográficos úteis para análise de tendências,
apresentação e distribuição. Métodos de visualização de informações como gráficos de radar, gráficos de coordenadas paralelas, gráficos de
tags, mapas de calor e mapas de dados agora são suportados por muitos conjuntos de ferramentas. Isso permite que os usuários identifiquem
rapidamente as mudanças nos dados ao longo do tempo, obtenham insights sobre itens relacionados e entendam as possíveis relações de
causa e efeito antes que os impactos ocorram. Essas ferramentas têm vários benefícios
sobre as ferramentas de visualização tradicionais:
• Tipos sofisticados de análise e visualização, como pequenos múltiplos, linhas de ignição, mapas de calor,
histogramas, gráficos em cascata e gráficos de marcadores
• Aderência integrada às melhores práticas de visualização
• Interatividade permitindo descoberta visual
4. Técnicas
4.1 Modelagem Analítica
Várias ferramentas de código aberto estão disponíveis para desenvolvimento, bem como processamento de dados em nuvem para modelagem
desenvolvimento, para processo de desenvolvimento visual, para web scraping e para otimização de programação linear. Para compartilhar e
executar modelos por outros aplicativos, procure ferramentas que suportem a linguagem de marcação de modelo preditivo (PMML), um formato
de arquivo baseado em XML.
O acesso em tempo real pode resolver muitos problemas de latência do processamento em lote. O Apache Mahout é um projeto de código
aberto destinado a criar uma biblioteca de aprendizado de máquina. A Mahout está posicionada para automatizar a exploração de Big Data por
meio de mineração de recomendações, classificação de documentos e agrupamento de itens. Esse ramo de esforços de desenvolvimento ignora
as técnicas tradicionais de acesso a dados MapReduce de consulta em lote. Aproveitando uma interface de API diretamente no HDFS da
camada de armazenamento, uma variedade de técnicas de acesso a dados pode ser fornecida, como SQL, streaming de conteúdo, aprendizado
de máquina e bibliotecas gráficas para visualização de dados.
Os modelos analíticos estão associados a diferentes profundidades de análise:
• A modelagem descritiva resume ou representa as estruturas de dados de forma compacta. este
A abordagem nem sempre valida uma hipótese causal ou prediz resultados. No entanto, ele usa
algoritmos para definir ou refinar relacionamentos entre variáveis de uma maneira que possa fornecer entrada para tais
análise.
• A modelagem explicativa é a aplicação de modelos estatísticos aos dados para testar hipóteses causais
sobre construções teóricas. Embora use técnicas semelhantes à mineração de dados e análise preditiva,
522 • DMBOK2
sua finalidade é diferente. Não prevê resultados; procura combinar os resultados do modelo apenas com
dados.
A chave para a análise preditiva é aprender pelo exemplo por meio do treinamento do modelo. O desempenho de um método de aprendizagem relaciona suas
habilidades preditivas em dados de testes independentes. A avaliação orienta a escolha do aprendizado e mede a qualidade do modelo escolhido. A seleção do
modelo estima o desempenho onde a avaliação avalia o erro de generalização em novos dados.
Evite overfitting – uma situação que ocorre quando o modelo é treinado em relação a conjuntos de dados não representativos, é excessivamente complexo em
relação a seus dados ou descreve ruído em vez do(s) relacionamento(s) subjacente(s). Use técnicas adicionais, como validação K-fold para indicar quando o
treinamento não está mais resultando em uma melhor generalização.
O erro de treinamento diminui consistentemente com a complexidade do modelo e pode cair para zero. Portanto, não é uma estimativa útil do erro de teste.
Divida aleatoriamente o conjunto de dados em três partes para formar conjuntos de treinamento, teste e validação. O conjunto de treinamento é usado para
ajustar o modelo, o conjunto de validação é usado para prever o erro de seleção e o conjunto de teste é usado para avaliar o erro de generalização do modelo
final.
Reutilizar o mesmo conjunto de teste repetidamente pode subestimar o verdadeiro erro de teste. Idealmente, execute a validação cruzada dividindo aleatoriamente
o conjunto de dados em um conjunto de K-folds ou grupos de validação cruzada. Realize o treinamento em todos, exceto um, conjunto de dados com base em
variáveis preditoras fortemente correlacionadas. Teste o modelo na peça restante e determine o erro de generalização com base em todas as K-folds. Vários
testes estatísticos podem ser aplicados e realizados para avaliar numericamente a validade do modelo contextual.
4.2 Modelagem de Big Data
A modelagem de Big Data é um desafio técnico, mas fundamental para uma organização que deseja descrever e controlar seus dados. Os princípios tradicionais
da Arquitetura de Dados Corporativos se aplicam; os dados precisam ser integrados, especificados e gerenciados.
O principal motivador para modelar fisicamente um data warehouse é habilitar o preenchimento de dados para desempenho de consulta.
Este driver não está em jogo para Big Data. Isso não é desculpa para abandonar o processo de modelagem ou entregá-lo a um desenvolvedor. O valor da
modelagem dos dados é que ela permite que as pessoas entendam o conteúdo dos dados. Aplique técnicas comprovadas de modelagem de dados enquanto
contabiliza a variedade de fontes. Desenvolva o modelo de área de assunto, pelo menos de forma resumida, para que possa ser relacionado a entidades
contextuais apropriadas e colocado no roteiro geral, assim como qualquer outro tipo de dado. O desafio é fazer uma imagem compreensível e útil desses grandes
conjuntos de dados e por um custo justificável.
Entenda como os dados são vinculados entre os conjuntos de dados. Para dados de granularidade diferente, evite combinações que contem elementos de dados
ou valores mais de uma vez; por exemplo, não combine conjuntos atômicos e agregados.
Muitos dos princípios gerais de gerenciamento de dados de armazém se aplicam ao gerenciamento de Big Data: garantir que as fontes de
dados sejam confiáveis, ter metadados suficientes para permitir o uso de dados, gerenciar a qualidade dos dados, descobrir como integrar
dados de diferentes fontes e garantir que os dados estão seguros e protegidos. (Consulte os Capítulos 6, 7 e 8.) As diferenças na
implementação de um ambiente de Big Data estão ligadas a um conjunto de incógnitas: como os dados serão usados, quais dados serão
valiosos, por quanto tempo eles precisam ser retidos.
A velocidade dos dados pode levar as pessoas a pensar que não têm tempo para implementar controles. Esta é uma suposição perigosa.
Com conjuntos de dados maiores, gerenciar a ingestão e o inventário de dados em um lago é fundamental para evitar que ele se torne um
pântano.
A ingestão pode nem sempre exigir propriedade organizacional ou compromisso com o conjunto de dados que está sendo estudado.
Considere alugar uma plataforma de Big Data por períodos finitos para explorar dados de interesse. A exploração pode determinar
rapidamente quais áreas mostram valor potencial. Faça isso antes de ingerir no data lake organizacional, armazenamento de dados ou área
de preparação de dados; uma vez pousado, pode ser difícil removê-lo.
5.1 Alinhamento da Estratégia
Qualquer programa de Big Data / Data Science deve estar estrategicamente alinhado com os objetivos organizacionais.
Estabelecer uma estratégia de Big Data impulsiona atividades relacionadas à comunidade de usuários, segurança de dados, gerenciamento
de metadados, incluindo linhagem e gerenciamento de qualidade de dados.
A estratégia deve documentar objetivos, abordagem e princípios de governança. A capacidade de aproveitar o Big Data requer a construção
de habilidades e capacidades organizacionais. Use o gerenciamento de recursos para alinhar as iniciativas de negócios e de TI e projetar
um roteiro. As entregas da estratégia devem levar em conta o gerenciamento:
• Ciclo de vida da informação

• Metadados
• Qualidade dos dados
• Aquisição de dados
• Acesso e segurança de dados
• Gestão de dados
• Dados privados
• Aprendizado e adoção
• Operações
Como em qualquer projeto de desenvolvimento, a implementação de uma iniciativa de Big Data ou Data Science deve estar alinhada às
necessidades reais do negócio. Avalie a prontidão organizacional em relação aos fatores críticos de sucesso:
524 • DMBOK2
• Relevância para os negócios: quão bem as iniciativas de Big Data / Data Science e seus casos de uso correspondentes se alinham com
os negócios da empresa? Para ter sucesso, eles devem aplicar fortemente uma função de negócios
ou processo.
• Prontidão de negócios: O parceiro de negócios está preparado para uma entrega incremental de longo prazo? Eles se comprometeram a
estabelecer centros de excelência para sustentar o produto em lançamentos futuros?
Quão ampla é a lacuna média de conhecimento ou habilidade dentro da comunidade-alvo e isso pode ser cruzado em um único
incremento?
• Viabilidade econômica: A solução proposta considerou conservadoramente o tangível e o intangível
benefícios? A avaliação dos custos de propriedade levou em conta a opção de comprar ou alugar itens versus construir do zero? •
Protótipo: A solução proposta pode ser prototipada para um subconjunto da comunidade de usuários finais por um período de tempo
finito para demonstrar o valor proposto? Implementações de big bang podem causar grandes impactos em dólares e um campo de provas pode
mitigar esses riscos de entrega.
Provavelmente, as decisões mais desafiadoras serão em relação à aquisição de dados, desenvolvimento de plataforma e recursos.
• Existem muitas fontes para armazenamentos de dados digitais e nem todas precisam ser de propriedade e operação internas. Alguns
podem ser adquiridos, enquanto outros podem ser alugados.
• Várias ferramentas e técnicas estão no mercado; corresponder às necessidades gerais será um desafio. • Proteger a equipe com
habilidades específicas em tempo hábil e reter os melhores talentos durante uma implementação pode exigir a consideração de alternativas,
incluindo serviços profissionais, fornecimento de nuvem ou colaboração.
• O tempo para desenvolver talentos internos pode exceder a janela de entrega.
As pessoas de negócios devem estar totalmente engajadas para obter os benefícios da análise avançada. Um programa de comunicação e educação
é necessário para afetar isso. Um Centro de Excelência pode fornecer treinamento, conjuntos de inicialização, práticas recomendadas de design,
dicas e truques de fonte de dados e outras soluções ou artefatos pontuais para ajudar a capacitar os usuários de negócios para um modelo de
autoatendimento. Além do gerenciamento do conhecimento, esse centro pode fornecer comunicações oportunas entre as comunidades de
desenvolvedores, designers, analistas e consumidores de dados.
Assim como no DW/BI, uma implementação de Big Data reunirá várias funções interfuncionais importantes, incluindo:
• Arquiteto de plataforma de Big Data: Hardware, sistemas operacionais, sistemas de arquivos e serviços. • Ingestion
Architect: Análise de dados, sistemas de registro, modelagem de dados e mapeamento de dados. Fornece ou
suporta mapeamento de fontes para o cluster Hadoop para consulta e análise. • Especialista em
Metadados: Interfaces de Metadados, Arquitetura de Metadados e Conteúdos. • Líder de design analítico:
design analítico do usuário final, implementação de orientação de melhores práticas em conjuntos de ferramentas relacionados e
facilitação do conjunto de resultados do usuário final.

• Cientista de Dados: Fornece consultoria de arquitetura e design de modelo com base no conhecimento teórico de
estatísticas e computabilidade, entrega de ferramentas apropriadas e aplicação técnica para
requisitos.
6. Governança de Big Data e Ciência de Dados
Big Data, como outros dados, requer governança. Os processos de fornecimento, análise de origem, ingestão, enriquecimento e publicação
exigem controles comerciais e técnicos, abordando questões como:
• Sourcing: Qual fonte, quando fonte, qual é a melhor fonte de dados para um estudo específico
• Compartilhamento: Quais acordos e contratos de compartilhamento de dados celebrar, termos e condições tanto dentro
e fora da organização
• Metadados: O que os dados significam no lado da fonte, como interpretar os resultados no lado da saída
• Enriquecimento: se deve enriquecer os dados, como enriquecer os dados e os benefícios de enriquecer os dados
• Acesso: O que publicar, para quem, como e quando
Uma visão corporativa dos dados deve orientar as decisões sobre o manuseio de dados.
6.1 Gerenciamento de Canais de Visualização
Um fator crítico de sucesso na implementação de uma abordagem de Data Science é o alinhamento das ferramentas de visualização adequadas
à comunidade de usuários. Dependendo do tamanho e da natureza da organização, provavelmente há muitas ferramentas de visualização
diferentes sendo aplicadas em uma variedade de processos. Certifique-se de que os usuários entendam a complexidade relativa das ferramentas
de visualização. Usuários sofisticados terão demandas cada vez mais complexas.
A coordenação entre as equipes de arquitetura corporativa, gerenciamento de portfólio e manutenção será necessária para controlar os canais
de visualização dentro e em todo o portfólio. Esteja ciente de que a alteração de provedores de dados ou critérios de seleção provavelmente
terá impactos a jusante nos elementos disponíveis para visualização, o que pode afetar a eficácia das ferramentas.
6.2 Padrões de Ciência de Dados e Visualização
É uma prática recomendada estabelecer uma comunidade que defina e publique padrões e diretrizes de visualização e revise artefatos dentro
de um método de entrega especificado; isso é particularmente vital para conteúdo voltado para clientes e regulamentações. Os padrões podem
incluir:
• Padrões de ferramentas por paradigma analítico, comunidade de usuários, área de assunto
• Solicitações de novos dados
• Padrão de processo de conjunto de dados

526 • DMBOK2
• Processos para apresentação neutra e especializada para evitar resultados tendenciosos e para garantir que todos os elementos
incluídos foram feitos de maneira justa e consistente, incluindo:

o Inclusão e exclusão de dados
o Suposições nos modelos
o Validade estatística dos resultados
o Validade da interpretação dos resultados
o Métodos apropriados aplicados
6.3 Segurança de Dados
Ter um processo confiável para proteger os dados é em si um ativo organizacional. Políticas de manuseio e proteção de Big Data devem ser
estabelecidas e monitoradas. Essas políticas devem explicar como evitar o uso indevido de dados pessoais e protegê-los durante todo o seu
ciclo de vida.
Forneça com segurança níveis apropriados de dados para pessoal autorizado e torne os dados de assinatura acessíveis de acordo com os
níveis acordados. Alinhar serviços às comunidades de usuários para que serviços especiais possam ser criados para fornecer dados privados
para as comunidades que têm permissão para ingeri-los e mascarar os dados para outras. Muitas vezes, as organizações criam políticas de
acesso a informações que não devem ser violadas (como nenhum acesso por nome, endereço ou número de telefone). Para proteger
informações altamente confidenciais (número de segurança social, números de cartão de crédito, etc.), os dados serão armazenados usando
técnicas de criptografia que ofuscam as informações. A criptografia pode ser escolhida que, por exemplo, tenha o mesmo 'conteúdo' quando
criptografada, para que os padrões possam ser expostos sem conhecer os valores reais.
A recombinação mede a capacidade de reconstituir dados confidenciais ou privados. Esse recurso deve ser gerenciado como parte da prática
de segurança de Big Data. Os resultados da análise podem violar a privacidade, mesmo que os elementos de dados reais só possam ser
inferidos. Compreender os resultados no nível de Gerenciamento de Metadados é fundamental para evitar essa e outras possíveis violações
de segurança. Isso requer conhecimento do consumo pretendido ou da análise a ser realizada e por qual função. Algumas pessoas de
confiança dentro da organização terão a capacidade de ler esses dados quando necessário, mas não todos, e certamente não para uma
análise profunda. (Consulte os Capítulos 2 e 7.)
6.4 Metadados
Como parte de uma iniciativa de Big Data, uma organização reunirá conjuntos de dados que foram criados usando diferentes abordagens e
padrões. A integração desses dados é um desafio. Os metadados relacionados a esses conjuntos de dados são essenciais para seu uso bem-
sucedido. Os metadados precisam ser cuidadosamente gerenciados como parte da ingestão de dados, ou o data lake rapidamente se tornará
um pântano de dados. A comunidade de usuários deve ter ferramentas que lhes permitam criar uma lista mestra de conjuntos de dados com
Metadados que caracterize a estrutura, conteúdo e qualidade dos dados, incluindo a origem e linhagem dos dados e a definição e usos
pretendidos de entidades e dados elementos. Os metadados técnicos podem ser coletados de uma variedade de ferramentas de Big Data,
incluindo camadas de armazenamento de dados, integração de dados, MDM e

até mesmo os sistemas de arquivos de origem. A consideração de feeds em tempo real versus dados em repouso versus elementos de dados
computacionais é necessária para completar a linhagem do lado da origem.
6.5 Qualidade de Dados
A qualidade dos dados é uma medida de desvio de um resultado esperado: quanto menor a diferença, melhor os dados atendem às expectativas
e maior a qualidade. Em um ambiente de engenharia, os padrões de qualidade devem ser fáceis de definir (embora a prática mostre que não
são ou que muitas organizações não dedicam tempo para defini-los). Algumas pessoas levantaram a questão de saber se a qualidade dos dados
é importante para o Big Data. O bom senso diz que sim. Para que a análise seja confiável, os dados subjacentes devem ser confiáveis. Em
projetos de Big Data, pode parecer muito difícil determinar a qualidade dos dados, mas é preciso fazer um esforço para avaliar a qualidade para
ter confiança na análise. Isso pode ser feito por meio de uma avaliação inicial, necessária para a compreensão dos dados, e por meio dela, a
identificação de medições para instâncias subsequentes do conjunto de dados. A avaliação da qualidade dos dados produzirá Metadados
valiosos que serão a entrada necessária para qualquer esforço de integração de dados.
Considere que as organizações de Big Data mais maduras verificam as fontes de entrada de dados usando conjuntos de ferramentas de
qualidade de dados para entender as informações contidas. A maioria dos conjuntos de ferramentas de qualidade de dados avançados oferece
funcionalidades que permitem que uma organização teste suposições e construa conhecimento sobre seus dados. Por exemplo:
• Descoberta: onde as informações residem no conjunto de dados
• Classificação: Que tipos de informações estão presentes com base em padrões padronizados
• Perfil: como os dados são preenchidos e estruturados
• Mapeamento: Quais outros conjuntos de dados podem corresponder a esses valores
Assim como no DW/BI, é tentador colocar a avaliação da qualidade dos dados em último lugar. Sem ele, porém, pode ser difícil saber o que o
Big Data representa ou como fazer conexões entre conjuntos de dados. A integração será necessária, e a probabilidade de que os feeds de
dados sejam provisionados com estruturas e elementos idênticos é quase zero.
Isso significa, por exemplo, que códigos e outros dados de vinculação em potencial provavelmente variarão de provedor de dados para provedor
de dados. Sem avaliação inicial, tais condições passarão despercebidas até que seja expressa uma necessidade analítica que tente fundir ou
combinar esses provedores.
6.6 Métricas
As métricas são vitais para qualquer processo de gerenciamento; eles não apenas quantificam a atividade, mas podem definir a variação
entre o que se observa e o que se deseja.
6.6.1 Métricas de Uso Técnico
Muitas das ferramentas de Big Data oferecem recursos de relatórios de administrador perspicazes que interagem diretamente com o conteúdo
consultado pela comunidade de usuários. A análise de uso técnico procura pontos de acesso de dados (mais frequentemente
528 • DMBOK2
dados acessados) para gerenciar a distribuição de dados e preservar o desempenho. As taxas de crescimento também contribuem para o
planejamento de capacidade.
6.6.2 Métricas de Carregamento e Digitalização
As métricas de carregamento e varredura definem a taxa de ingestão e a interação com a comunidade de usuários. À medida que cada nova fonte
de dados é adquirida, espera-se que as métricas de carregamento aumentem e, em seguida, nivelem à medida que essa fonte é totalmente ingerida.
Os feeds em tempo real podem ser atendidos por meio de consultas de serviço, mas também podem aparecer à medida que extrações programadas são
processadas; para esses feeds, espere um aumento constante no carregamento de dados.
As camadas do aplicativo provavelmente forneceriam as melhores métricas de uso de dados dos logs de execução. Monitore o consumo ou acesso
por meio de Metadados disponíveis, que podem orientar a análise de uso mostrando os planos de execução de consultas que ocorreram com mais
frequência.
As métricas de varredura devem ser combinadas com qualquer processamento de consulta que possa ocorrer fora do próprio processamento
analítico. As ferramentas administrativas devem ser capazes de fornecer esse nível de relatório, bem como o serviço geral
saúde.
6.6.3 Aprendizados e Histórias
Para mostrar valor, o programa Big Data / Data Science deve medir resultados tangíveis que justifiquem o custo de desenvolvimento de soluções e
gerenciamento de mudanças de processos. As métricas podem incluir a quantificação dos benefícios, prevenção ou prevenção de custos, bem
como o período de tempo entre o início e os benefícios realizados. Comum

as medidas incluem
• Contagens e precisão de modelos e padrões desenvolvidos
• Realização de receita de oportunidades identificadas
• Redução de custos ao evitar ameaças identificadas
Às vezes, os resultados da análise contam histórias que podem levar ao redirecionamento, revitalização e novas oportunidades da organização.
Uma medida pode ser uma contagem de novos projetos e iniciativas geradas pelo marketing
e altos executivos.

Abate, Robert, Peter Aiken e Joseph Burke. Integrando aplicativos corporativos utilizando uma arquitetura baseada em serviços.
John Wiley and Sons, 1997. Impresso.
Artur, Lisa. Marketing de Big Data: Envolva seus clientes de forma mais eficaz e gere valor. Wiley, 2013. Impresso.
Barlow, Mike. Análise de Big Data em Tempo Real: Arquitetura Emergente. O'Reilly Media, 2013. Kindle.
Davenport, Thomas H. “Além da Caixa Preta em Análise e Cognitivo.” DataInformed (site), 27 de fevereiro de 2017. http://bit.ly/2sq8uG0 Web.
Davenport, Thomas H. Big Data no Trabalho: Dissipando os Mitos, Descobrindo as Oportunidades. Harvard Business Review Press, 2014. Imprimir.
EMC Education Services, ed. Data Science e Big Data Analytics: Descobrindo, Analisando, Visualizando e Apresentando Dados. Wiley, 2015. Impresso.
Gabinete Executivo do Presidente, Comitê de Tecnologia do Conselho Nacional de Ciência e Tecnologia. Preparando-se para o Futuro da Inteligência
Artificial. Outubro de 2016. http://bit.ly/2j3XA4k.
Inmon, WH e Dan Linstedt. Arquitetura de dados: uma cartilha para o cientista de dados: Big Data, Data Warehouse e Data Vault. 1ª Edição. Morgan
Kaufmann, 2014.
Jacobs, Adão. “Patologias do Big Data”. AMCQUEU, Volume 7, Edição 6. 6 de julho de 2009. http://bit.ly/1vOqd80. Rede
Janssens, Jeroen. Ciência de dados na linha de comando: enfrentando o futuro com ferramentas testadas pelo tempo. O'Reilly Media, 2014.
Imprimir.
Cozinha, Rob. A Revolução dos Dados: Big Data, Dados Abertos, Infraestruturas de Dados e Suas Consequências. SAGE Publications Ltd,
2014. Imprimir.
Krishnan, Kris. Data Warehousing na Era do Big Data. Morgan Kaufmann, 2013. Impresso. A Série Morgan Kaufmann sobre Business Intelligence.
Lago, Peter e Robert Drake. Gestão de Sistemas de Informação na Era do Big Data. Springer, 2015. Impresso. Processamento Avançado de
Informação e Conhecimento.
Lago, Pedro. Um guia para lidar com dados usando o Hadoop: Uma exploração do Hadoop, Hive, Pig, Sqoop e Flume. Peter Lake, 2015. Kindle.
Processamento Avançado de Informação e Conhecimento.
Laney, Doug. “Gerenciamento de Dados 3D: Controlando Volume, Velocidade e Variedade de Dados.” O Grupo Meta [Gartner]. 6 de fevereiro de
2001. http://gtnr.it/1bKflKH.
Loshin, David. Big Data Analytics: Do Planejamento Estratégico à Integração Empresarial com Ferramentas, Técnicas, NoSQL e Gráfico. Morgan Kaufmann,
2013. Impresso.
Lublinsky, Boris, Kevin T. Smith, Alexey Yakubovich. Soluções Profissionais Hadoop. Wrox, 2013. Impresso.
Luís, James. Arquitetura Empresarial Pragmática: Estratégias para Transformar Sistemas de Informação na Era do Big Data.
Morgan Kaufmann, 2014. Impresso.
Marz, Nathan e James Warren. Big Data: Princípios e melhores práticas de sistemas de dados em tempo real escaláveis. Manning Publicações,
2014. Impresso.
McCandless, David. A informação é bonita. Collins, 2012.
Reitor, Foster e Tom Fawcett. Data Science for Business: O que você precisa saber sobre mineração de dados e pensamento analítico de dados. O'Reilly
Media, 2013. Impresso.
Salminen, Joni and Valtteri Kaartemo, eds. Big Data: Definições, Lógicas de Negócios e Melhores Práticas para Aplicar em Seu Negócio. Amazon
Digital Services, Inc., 2014. Kindle. Livros para Gestores Livro 2.
Sathi, Arvind. Big Data Analytics: Tecnologias disruptivas para mudar o jogo. Mc Press, 2013. Imprimir.
Sawant, Nitin e Himanshu Shah. Perguntas e respostas sobre arquitetura de aplicativos de Big Data: um problema - abordagem de solução. Apress, 2013.
Imprimir. Voz do especialista em Big Data.
Slovic, Scott, Paul Slovic, eds. Números e nervos: informação, emoção e significado em um mundo de dados. Oregon State University Press, 2015.
Impresso.
530 • DMBOK2
Starbird, Michael. Significado dos Dados: Estatísticas Esclarecidas (Os Grandes Cursos, Partes 1 e 2). A Companhia de Ensino, 2006.
Imprimir.
Tufte, Edward R. A Exibição Visual da Informação Quantitativa. 2ª edição. Graphics Pr., 2001. Impressão.
van der Lans, Rick. Virtualização de Dados para Sistemas de Business Intelligence: Revolucionando a Integração de Dados para Data
Warehouses. Morgan Kaufmann, 2012. Impresso. A Série Morgan Kaufmann sobre Business Intelligence.
van Rijmenam, Mark. Pense maior: desenvolvendo uma estratégia de Big Data bem-sucedida para o seu negócio. AMACOM, 2014. Impresso.
CAPÍTULO 1 5
Avaliação da maturidade do gerenciamento de dados
1. Introdução
C
Apability Maturity Assessment (CMA) é uma abordagem para melhoria de processos baseada em uma estrutura –
um Capability Maturity Model (CMM) – que descreve como as características de um processo evoluem a partir de um anúncio
hoc para o ideal. O conceito CMA surgiu dos esforços do Departamento de Defesa dos Estados Unidos para estabelecer
critérios pelos quais avaliar os contratantes de software. Em meados da década de 1980, o Capability Maturity Model for Software foi
publicado pelo Software Engineering Institute da Carnegie-Mellon University. Embora aplicado pela primeira vez ao desenvolvimento de
software, os CMMs foram desenvolvidos para uma variedade de outros campos, incluindo dados
gestão.
Os modelos de maturidade são definidos em termos de uma progressão através de níveis que descrevem as características do processo.
Quando uma organização obtém uma compreensão das características do processo, ela pode avaliar seu nível de maturidade e colocar
em prática um plano para melhorar suas capacidades. Também pode medir a melhoria e comparar-se com concorrentes ou parceiros,
guiado pelos níveis do modelo. A cada novo nível, a execução do processo se torna mais consistente, previsível e confiável. Os
processos melhoram à medida que assumem características dos níveis. A progressão acontece em uma ordem definida. Nenhum nível
pode ser pulado. Os níveis geralmente incluem: 96
• Nível 0: Ausência de capacidade
• Nível 1: Inicial ou Ad Hoc: O sucesso depende da competência dos indivíduos
• Nível 2: Repetível: a disciplina mínima do processo está em vigor

• Nível 3: Definido: Os padrões são definidos e usados
• Nível 4: Gerenciado: Os processos são quantificados e controlados
• Nível 5: Otimizado: as metas de melhoria do processo são quantificadas
Dentro de cada nível, os critérios são descritos nas características do processo. Por exemplo, um modelo de maturidade pode incluir
critérios relacionados a como os processos são executados, incluindo o nível de automação desses processos. Ele pode se concentrar
em políticas e controles, bem como detalhes do processo.
96Adaptado de Select Business Solutions, “Qual é o Modelo de Maturidade de Capacidade?” http://bit.ly/IFMJI8 (Acessado em 2016-
11-10).
531
532 • DMBOK2
Essa avaliação ajuda a identificar o que está funcionando bem, o que não está funcionando bem e onde uma organização tem lacunas.
Com base nas descobertas, a organização pode desenvolver um roteiro para atingir:
• Oportunidades de melhoria de alto valor relacionadas a processos, métodos, recursos e automação
• Recursos que se alinham com a estratégia de negócios
• Processos de governança para avaliação periódica do progresso organizacional com base nas características do
modelo
A Data Management Maturity Assessment (DMMA) pode ser usada para avaliar o gerenciamento de dados em geral, ou pode ser
usada para focar em uma única área de conhecimento ou até mesmo em um único processo. Seja qual for o foco, um DMMA pode
ajudar a preencher a lacuna entre as perspectivas de negócios e de TI sobre a integridade e a eficácia das práticas de gerenciamento
de dados. Um DMMA fornece uma linguagem comum para descrever como é o progresso nas Áreas de Conhecimento de
Gerenciamento de Dados e oferece um caminho para a melhoria baseado em estágios, que pode ser adaptado às prioridades
estratégicas de uma organização.97 Assim, pode ser usado para definir e medir objetivos organizacionais, bem como comparar sua
organização com outras organizações ou benchmarks do setor.
Antes de iniciar qualquer DMMA, uma organização deve estabelecer um entendimento básico de suas capacidades, ativos, objetivos e
prioridades do estado atual. Um certo nível de maturidade organizacional é necessário para conduzir a avaliação em primeiro lugar,
bem como para responder efetivamente aos resultados da avaliação, estabelecendo metas, estabelecendo um roteiro e monitorando o
progresso.
As organizações realizam avaliações de maturidade de capacidade por vários motivos:
• Regulamentação: A supervisão regulatória requer níveis mínimos de maturidade no gerenciamento de dados.
• Governança de Dados: A função de governança de dados requer uma avaliação de maturidade para planejamento e
fins de conformidade.
• Prontidão organizacional para melhoria de processos: Uma organização reconhece a necessidade de melhorar
suas práticas e começa avaliando seu estado atual. Por exemplo, compromete-se a gerir
Master Data e precisa avaliar sua prontidão para implantar processos e ferramentas de MDM.
• Mudança organizacional: uma mudança organizacional, como uma fusão, apresenta gerenciamento de dados
desafios. Um DMMA fornece subsídios para o planejamento para enfrentar esses desafios.
• Nova tecnologia: os avanços na tecnologia oferecem novas maneiras de gerenciar e usar dados. o
organização quer entender a probabilidade de adoção bem-sucedida.
• Problemas de gerenciamento de dados: há necessidade de resolver problemas de qualidade de dados ou outro gerenciamento de dados
desafios e a organização deseja basear seu estado atual para tomar melhores decisões
sobre como implementar a mudança.
97 http://bit.ly/1Vev9xx 18 de julho de 2015.

AVALIAÇÃO DA MATURIDADE DO GERENCIAMENTO DE DADOS • 533
Avaliação da maturidade do gerenciamento de dados
Definição: Um método para classificar as práticas de manipulação de dados dentro de uma organização para
caracterizar o estado atual do gerenciamento de dados e seu impacto na organização
Metas:
1. Descobrir e avaliar de forma abrangente as atividades críticas de gerenciamento de dados em uma organização.
2. Educar as partes interessadas sobre conceitos, princípios e práticas de gerenciamento de dados, bem como identificar
seus papéis e responsabilidades em um contexto mais amplo como criadores e gerentes de dados.
3. Estabelecer ou aprimorar um programa sustentável de gerenciamento de dados em toda a empresa em apoio a operações
e objetivos estratégicos.
O negócio
Motoristas
Atividades: Entregáveis:
Entradas:
• •
Estratégia de negócio & 1. Planejar as Atividades de Avaliação (P) Classificações e classificações
Metas •
1. Estabelecer Escopo e Abordagem Linha de base de vencimento
• Cultura e risco 2. Planejar as comunicações • Avaliação de prontidão
tolerância • Avaliação de risco
2. Realizar Avaliação de Maturidade (C)
• 1. Reúna informações •
Maturidade Capacidade de pessoal
Estruturas e 2. Realize a avaliação • Investimento e
DAMA-DMBOK 3. Interpretar os resultados opções de resultados
• 3. Desenvolva Recomendações (D) • Recomendações
Políticas, processos,
padrões, modelos 4. Criar Programa Direcionado para Melhorias • Roteiro
operacionais •
(P) Briefings Executivos
• Referências 5. Reavalie o vencimento (C)

• Executivos • CDO/CIO • Executivos
• Administradores de dados • •
Gestão de negócios Auditoria / Conformidade
• Executivos DM • Executivos de DM e Órgãos de Governança de Dados •
Reguladores
• • Escritório de Governança de Dados • Administradores de dados
• • • Gestão de dados
Funcionários Avaliadores de Maturidade
• Corpos
Funcionários
•
Organizacional
Grupo de Eficácia
Técnico
Motoristas

• • • DMMA Local e Total
Gestão de dados Maturidade do Gerenciamento de Dados
Estruturas de maturidade Estruturas Classificações
Seleção • Plano de Comunicação • Utilização de recursos

• Ferramentas de colaboração •
• Envolvimento da Comunidade Exposição ao risco
• DMBOK DIREITO • Gestão do Conhecimento e • Gestão de Gastos
• •
Comparativos de mercado existentes Repositórios de Metadados Entradas para DMMA
• •
Ferramentas de criação de perfil de dados Taxa de variação
Figura 103 Diagrama de Contexto: Avaliação da Maturidade do Gerenciamento de Dados

534 • DMBOK2
O objetivo principal de uma avaliação da capacidade de gerenciamento de dados é avaliar o estado atual das atividades críticas de gerenciamento
de dados para planejar melhorias. A avaliação coloca a organização na escala de maturidade, esclarecendo pontos fortes e fracos específicos.
Ajuda a organização a identificar, priorizar e implementar oportunidades de melhoria.
Ao atingir seu objetivo principal, um DMMA pode ter um impacto positivo na cultura. Isso ajuda:
• Educar as partes interessadas sobre conceitos, princípios e práticas de gerenciamento de dados
• Esclarecer os papéis e responsabilidades das partes interessadas em relação aos dados organizacionais
• Destaque a necessidade de gerenciar dados como um ativo crítico
• Ampliar o reconhecimento das atividades de gerenciamento de dados em toda a organização
• Contribuir para melhorar a colaboração necessária para uma governança de dados eficaz
Com base nos resultados da avaliação, uma organização pode aprimorar seu programa de gerenciamento de dados para que ele apoie a direção
operacional e estratégica da organização. Normalmente, os programas de gerenciamento de dados se desenvolvem em silos organizacionais.
Eles raramente começam com uma visão corporativa dos dados. Um DMMA pode equipar a organização para desenvolver uma visão coesa que
apoie a estratégia organizacional geral. Um DMMA permite à organização esclarecer prioridades, cristalizar objetivos e desenvolver um plano
integrado de melhoria.
1.3.1 Níveis e Características de Avaliação
Os CMMs geralmente definem cinco ou seis níveis de maturidade, cada um com suas próprias características que vão de inexistente ou ad hoc
a otimizada ou de alto desempenho. Consulte a Figura 104 para uma visualização de amostra.
Veja a seguir um resumo genérico dos estados macro da maturidade do gerenciamento de dados. Uma avaliação detalhada incluiria critérios
para subcategorias como estratégia, política, padrões, definição de papéis, etc. dentro de cada uma das Áreas de Conhecimento.
• Nível 0: Sem capacidade: Sem práticas organizadas de gerenciamento de dados ou processos empresariais formais para
gerenciamento de dados. Muito poucas organizações existem no Nível 0. Este nível é reconhecido em um nível de maturidade
modelo para fins de definição.
• Nível 1 Inicial / Ad Hoc: Gerenciamento de dados de uso geral usando um conjunto de ferramentas limitado, com pouco ou nenhum
governança. O manuseio de dados depende muito de alguns especialistas. Papéis e responsabilidades são definidos
dentro dos silos. Cada proprietário de dados recebe, gera e envia dados de forma autônoma. Controles, se existirem,
são aplicados de forma inconsistente. As soluções para gerenciamento de dados são limitadas. Os problemas de qualidade de dados são generalizados
mas não abordado. Os suportes de infraestrutura estão no nível da unidade de negócios.

• Altamente previsível
processos
• Risco reduzido
• Planejamento e governança
•Bem entendido
centralizados
•Dados vistos como um •Gestão de riscos relacionados métricas para gerenciar
organizacional a dados qualidade de dados e

Facilitador • Métricas de desempenho qualidade de processo
• Emergentes • Processos e ferramentas de gerenciamento de
governança escaláveis; redução dados • Mensurável
• Pouco ou nenhum
•Introdução de um
em processos manuais
governança conjunto de ferramentas consistente
Os resultados do processo, melhorias na qualidade
• Conjunto de ferramentas limitado
• Alguns papéis e
Nível 5
•Funções definidas nos incluindo a qualidade dos dos dados
processos definidos dados, são mais Otimizado
silos
• Crescente conscientização sobre previsível Nível 4
• Controles aplicados de
o impacto dos problemas de
forma inconsistente, se for
qualidade de dados Gerenciou
o caso Nível 3
• Problemas de qualidade de
Definiram
dados não abordados Nível 2
Repetivel
Nível 1
Inicial / Ad Hoc
Figura 104 Exemplo de modelo de maturidade de gerenciamento de dados
Os critérios de avaliação podem incluir a presença de quaisquer controles de processo, como registro de problemas de qualidade de dados.
• Nível 2 Repetível: Surgimento de ferramentas consistentes e definição de funções para apoiar a execução do processo. Dentro
Nível 2, a organização começa a usar ferramentas centralizadas e a fornecer mais supervisão dos dados
gestão. Os papéis são definidos e os processos não dependem apenas de especialistas específicos. Há
consciência organizacional de questões e conceitos de qualidade de dados. Conceitos de dados mestre e de referência
começam a ser reconhecidos.
Os critérios de avaliação podem incluir a definição formal de funções em artefatos como descrições de cargos, a existência de documentação de
processos e a capacidade de alavancar conjuntos de ferramentas.
• Nível 3 Definido: Capacidade emergente de gerenciamento de dados. O nível 3 vê a introdução e
institucionalização de processos de gerenciamento de dados escaláveis e uma visão do DM como um
Facilitador. As características incluem a replicação de dados em uma organização com alguns controles em
lugar e um aumento geral na qualidade geral dos dados, juntamente com a definição de políticas coordenadas e
gestão. Uma definição de processo mais formal leva a uma redução significativa na intervenção manual.
Isso, juntamente com um processo de design centralizado, significa que os resultados do processo são mais previsíveis.
Os critérios de avaliação podem incluir a existência de políticas de gerenciamento de dados, o uso de processos escaláveis e a consistência de
modelos de dados e controles do sistema.
• Nível 4 Gerenciado: O conhecimento institucional adquirido com o crescimento nos Níveis 1-3 permite que a organização
prever resultados ao abordar novos projetos e tarefas e começar a gerenciar riscos relacionados a
dados. O gerenciamento de dados inclui métricas de desempenho. As características do Nível 4 incluem
ferramentas para gerenciamento de dados do desktop à infraestrutura, juntamente com um
função de planejamento e governança. Expressões desse nível são um aumento mensurável na qualidade dos dados
e recursos de toda a organização, como auditorias de dados de ponta a ponta.

536 • DMBOK2
Os critérios de avaliação podem incluir métricas relacionadas ao sucesso do projeto, métricas operacionais para sistemas e métricas de qualidade
de dados.
• Nível 5: Otimização: Quando as práticas de gerenciamento de dados são otimizadas, elas são altamente previsíveis,
devido à automação de processos e gerenciamento de mudanças tecnológicas. Organizações neste nível de maturidade
foco na melhoria contínua. No Nível 5, as ferramentas permitem uma visualização dos dados entre os processos. o
a proliferação de dados é controlada para evitar duplicações desnecessárias. Métricas bem compreendidas são usadas para
gerenciar e medir a qualidade dos dados e processos.
Os critérios de avaliação podem incluir artefatos de gerenciamento de mudanças e métricas de melhoria de processos.
1.3.2 Critérios de Avaliação
Cada nível de capacidade terá critérios de avaliação específicos relacionados aos processos que estão sendo avaliados. Por exemplo, se a
maturidade da função de modelagem de dados estiver sendo avaliada, o nível 1 pode perguntar se existe uma prática de modelagem de dados e
a quantos sistemas ela se estende; o nível 2 pode perguntar se uma abordagem para modelagem de dados corporativos foi definida; o nível 3
perguntará até que ponto a abordagem foi implementada; o nível 4 perguntará se os padrões de modelagem foram efetivamente aplicados; e o
nível 5 perguntará sobre os processos implementados para melhorar as práticas de modelagem. (Consulte o Capítulo 5.)
Em qualquer nível, os critérios de avaliação serão avaliados em uma escala, como 1 – Não iniciado, 2 – Em processo, 3 – Funcional, 4 – Efetivo,
mostrando o progresso nesse nível e o movimento para o próximo nível. As pontuações podem ser combinadas ou exibidas visualmente para
permitir a compreensão da variação entre o estado atual e o desejado.
Ao avaliar usando um modelo que pode ser mapeado para uma Área de Conhecimento de Gerenciamento de Dados DAMA-DMBOK, os critérios
podem ser formulados com base nas categorias do Diagrama de Contexto:
• Atividade: Até que ponto a atividade ou processo está implementado? São definidos critérios para eficácia e
execução eficiente? Quão bem definida e executada é a atividade? São saídas de melhores práticas
produzido?
• Ferramentas: Até que ponto a atividade é automatizada e suportada por um conjunto comum de ferramentas? É ferramenta
treinamento fornecido dentro de funções e responsabilidades específicas? As ferramentas estão disponíveis quando e onde
precisava? Eles estão configurados de forma ideal para fornecer os resultados mais eficazes e eficientes? Para quê
Até que ponto o planejamento de tecnologia de longo prazo está em vigor para acomodar as capacidades do estado futuro?
• Padrões: Até que ponto a atividade é apoiada por um conjunto comum de padrões? Quão bem
documentados são os padrões? Os padrões são aplicados e apoiados pela governança e mudança
gestão?
• Pessoas e recursos: Até que ponto a organização dispõe de pessoal para realizar a atividade? o que
habilidades específicas, treinamento e conhecimento são necessários para executar a atividade? Quão bem são os papéis e
responsabilidades definidas?
A Figura 105 ilustra uma maneira de apresentar um resumo visual das descobertas de um DMMA. Para cada uma das capacidades
(Governança, Arquitetura, etc.), o anel externo da tela mostra o nível de capacidade que a organização determinou que precisa para
competir com sucesso. O anel interno exibe o nível de capacidade determinado por meio da avaliação. As áreas onde a distância entre
os dois anéis é maior representam os maiores riscos para a organização. Esse relatório pode ajudar a definir prioridades. Também pode
ser usado para medir o progresso ao longo do tempo.
Tabela de Avaliação do DMM

Classificação desejada Rank atual
Governança
5
DQ Arquitetura
4
Metadados Modelagem
2
DW&BI Armazenamento e operações
P&MD Segurança
D&C DII
Figura 105 Exemplo de uma visualização de avaliação de maturidade de gerenciamento de dados
1.3.3 Estruturas DMMA existentes 98
Uma estrutura de avaliação de maturidade de gerenciamento de dados é segmentada em tópicos de gerenciamento de dados discretos.
O foco e o conteúdo da estrutura variam dependendo se têm um foco geral ou específico do setor.
No entanto, a maioria aborda assuntos que podem ser mapeados para as Áreas de Conhecimento DAMA-DMBOK. Os exemplos abaixo
destinam-se a ilustrar a variedade de Modelos de Maturidade de Capacidade que foram desenvolvidos no espaço de gerenciamento de
dados. Muitos fornecedores desenvolveram seus próprios modelos. As organizações devem avaliar vários modelos antes de escolher
um fornecedor ou antes de desenvolver sua própria estrutura.
98 Para informações adicionais e revisão de CMMs de gerenciamento de dados existentes, consulte: Alan McSweeney, Review of Data Management
Maturity Models, SlideShare.net, publicado em 23/10/2013. http://bit.ly/2spTCY9. Jeff Gorball, Introdução aos modelos de maturidade de gerenciamento
de dados, SlideShare.net, publicado em 01/08/2016. McSweeney inclui o DAMA-DMBOK como um de seus modelos de maturidade, embora o DMBOK
não esteja estruturado como tal.
538 • DMBOK2
1.3.3.1 Modelo de Maturidade de Gerenciamento de Dados CMMI (DMM)
O CMMI (Capability Maturity Model Institute) desenvolveu o CMMI-DMM (Data Management Maturity
Modelo) que fornece critérios de avaliação para as seguintes áreas de gerenciamento de dados:
• Estratégia de Gerenciamento de Dados

• Gestão de dados
• Qualidade de dados
• Plataforma e Arquitetura
• Operações de Dados
• Processos de Apoio
Dentro de cada um desses processos, o modelo identifica subprocessos para avaliação. Por exemplo, a seção de qualidade de dados é
responsável pela estratégia de qualidade de dados e avaliação de qualidade de dados, criação de perfil e limpeza. O modelo também leva em
conta a relação entre as áreas de gerenciamento de dados. Por exemplo, a necessidade de alinhamento das partes interessadas e a relação
entre os processos de negócios e o Data Quality Management.99
1.3.3.2 Conselho EDM DCAM100
O Enterprise Data Management Council, uma organização de defesa da indústria para serviços financeiros com sede nos Estados Unidos,
desenvolveu o DCAM (Data Management Capability Assessment Model). Resultado de um esforço orientado por membros para obter consenso
sobre as melhores práticas de gerenciamento de dados, o DCAM descreve 37 recursos e 115 subcapacidades associados ao desenvolvimento
de um programa de gerenciamento de dados sustentável. A pontuação foca no nível de engajamento dos stakeholders, formalidade do processo
e existência de artefatos que demonstram a conquista das capacidades.
1.3.3.3 Modelo de Maturidade do IBM Data Governance Council 101
O Modelo de Maturidade do Conselho de Governança de Dados da IBM foi baseado em informações de um conselho de 55 organizações.
Os membros do conselho colaboraram para definir um conjunto comum de comportamentos observáveis e desejados que as organizações
podem usar para avaliar e projetar seus próprios programas de governança de dados. O objetivo do modelo é ajudar as organizações a construir
consistência e controle de qualidade na governança por meio de tecnologias de negócios comprovadas, métodos colaborativos e melhores
práticas. O modelo está organizado em quatro categorias principais:
• Resultados: gerenciamento de risco de dados e conformidade, criação de valor
• Facilitadores: estrutura organizacional e conscientização, política, administração
99
http://bit.ly/1Vev9xx acessado em 18/07/2015.
100 http://bit.ly/2sqaSga acessado em 2015-07-18.
101 https://ibm.co/2sRfBIn (acessado em 2016-12-04).

• Disciplinas principais: Gerenciamento de qualidade de dados, gerenciamento do ciclo de vida da informação, segurança da informação
e privacidade
• Disciplinas de Apoio: Arquitetura de Dados, classificação e Metadados, informações de auditoria, registro
e relatórios
O modelo IBM é apresentado tanto como um Maturity Framework quanto como um conjunto de questões de avaliação com respostas construídas
para indicar níveis de maturidade.
1.3.3.4 Modelo de Maturidade de Governança de Dados de Stanford 102
O Modelo de Maturidade de Governança de Dados de Stanford foi desenvolvido para uso pela Universidade; não se destinava a ser um padrão da
indústria. Mesmo assim, serve como um exemplo sólido de um modelo que fornece orientação e padrão de medição. O modelo se concentra na
governança de dados, não no gerenciamento de dados, mas fornece uma base para a avaliação geral do gerenciamento de dados. O modelo
diferencia entre componentes fundamentais (conscientização, formalização, metadados) e de projeto (administração de dados, qualidade de dados,
dados mestres). Dentro de cada um, ele articula impulsionadores para pessoas, políticas e capacidades. Em seguida, articula características de
cada nível de maturidade. Ele também fornece medições qualitativas e quantitativas para cada nível.
1.3.3.5 Modelo de Maturidade de Gerenciamento de Informações Corporativas do Gartner
O Gartner publicou um modelo de maturidade de EIM, que estabelece critérios para avaliar visão, estratégia, métricas, governança, funções e
responsabilidades, ciclo de vida e infraestrutura.
2. Atividades
As avaliações de maturidade de gerenciamento de dados exigem planejamento. Para garantir resultados práticos e acionáveis, reserve tempo
dentro do plano para preparação de materiais e avaliação de resultados. As avaliações devem ser realizadas em um prazo curto e definido. O
objetivo da avaliação é expor os pontos fortes atuais e as oportunidades de melhoria – não para resolver problemas.
As avaliações são conduzidas solicitando conhecimento de participantes de negócios, gerenciamento de dados e tecnologia da informação. O
objetivo é chegar a uma visão consensual das atuais capacidades do Estado, apoiada por evidências. A evidência pode vir do exame de artefatos
(como se existem backups de banco de dados), por meio de entrevistas (verificando que alguém está realizando o sistema de avaliação de registros
para reutilização) ou ambos.
102 http://stanford.io/2sBR5bZ (acessado em 2016-12-04) e http://stanford.io/2rVPyM2 (acessado em 2016-12-04).

540 • DMBOK2
As avaliações podem e devem ser dimensionadas para atender às necessidades da organização. No entanto, altere com cuidado. Os
modelos podem perder o rigor ou a rastreabilidade à intenção original se encurtados ou editados. Mantenha a integridade do modelo
intacta ao personalizar.
2.1 Planejar Atividades de Avaliação
O planejamento de uma avaliação inclui a definição da abordagem geral e a comunicação com as partes interessadas antes e durante
a avaliação para garantir que estejam engajadas. A avaliação em si inclui coletar e avaliar insumos e comunicar resultados,
recomendações e planos de ação.
2.1.1 Definir Objetivos
Qualquer organização que decida que deve avaliar seu nível de maturidade em gerenciamento de dados já está engajada no esforço
de melhorar suas práticas. Na maioria dos casos, tal organização terá identificado os motivadores para a avaliação. Esses direcionadores
devem ser esclarecidos na forma de objetivos que descrevam o foco e influenciem o escopo da avaliação. Os objetivos da avaliação
devem ser claramente compreendidos pelos executivos e pelas linhas de negócios, que podem ajudar a garantir o alinhamento com o
direcionamento estratégico da organização.
Os objetivos de avaliação também fornecem critérios para avaliar qual modelo de avaliação adotar, quais áreas de negócios priorizar
para avaliação e quem deve fornecer entrada direta ao processo.
2.1.2 Escolha uma Estrutura
Conforme descrito na Seção 1.3.3, as estruturas existentes se concentram em diferentes aspectos do gerenciamento de dados. Revise
essas estruturas no contexto das suposições sobre o estado atual e os objetivos de avaliação para escolher uma que informará a
organização de maneira significativa. As áreas de foco do modelo de avaliação podem ser personalizadas com base no foco ou escopo
organizacional.
A escolha da estrutura influencia a forma como a avaliação é conduzida. A equipe que trabalha nele deve ter experiência no modelo e
na metodologia de que depende.
2.1.3 Definir Escopo Organizacional
A maioria dos DMM Frameworks é projetada para ser aplicada a uma empresa inteira. No entanto, um escopo de toda a empresa pode
ser impraticável. Para uma primeira avaliação, geralmente é melhor definir um escopo gerenciável, como uma única área de negócios
ou programa. As áreas escolhidas representam um subconjunto significativo da organização e os participantes devem ser capazes de
influenciar os principais processos de negócios que afetam os ativos de dados dentro do escopo. Como parte de uma abordagem faseada,
AVALIAÇÃO DA MATURIDADE DA GESTÃO DE DADOS • 541
a avaliação pode ser repetida para outras partes da organização. Existem trade-offs entre o local e a empresa
Assessments:
• Avaliações localizadas podem aprofundar os detalhes. Eles também podem ser feitos mais rapidamente
porque o escopo está contido. Para fazer uma avaliação localizada, selecione uma função altamente regulamentada,
como relatórios financeiros dentro de uma empresa pública. As entradas, papéis, ferramentas e consumidores podem ser
fora das funções que estão sendo avaliadas, o que pode complicar o escopo e a execução do
avaliação. Avaliações localizadas bem planejadas muitas vezes podem ser agregadas e ponderadas para formar um
avaliação empresarial, uma vez que muitos ativos de dados são compartilhados.
• As avaliações corporativas concentram-se nas partes amplas e às vezes desconectadas de uma organização. Um
a avaliação da empresa pode ser criada a partir de DMMAs localizados ou pode ser uma empresa separada. Por
Por exemplo, uma organização pode avaliar diferentes funções (pesquisa e desenvolvimento, fabricação,
e financiamento) com base nos mesmos critérios. As entradas, funções, ferramentas e consumidores são tipicamente
pan-corporativos e multiníveis.
2.1.4 Definir Abordagem de Interação
Ao conduzir um DMMA, uma organização deve seguir as recomendações para o modelo selecionado. As atividades de coleta de
informações podem incluir workshops, entrevistas, pesquisas e revisões de artefatos. Empregue métodos que funcionem bem dentro da
cultura organizacional, minimize o comprometimento de tempo dos participantes e permita que a avaliação seja concluída rapidamente
para que as ações da avaliação possam ser definidas enquanto o processo está fresco na mente dos participantes.
Em todos os casos, as respostas precisarão ser formalizadas fazendo com que os participantes classifiquem os critérios de avaliação.
Em muitos casos, a avaliação também incluirá inspeção e avaliação reais de artefatos e outras evidências.
Se houver atrasos na conclusão da avaliação, as partes interessadas provavelmente perderão o entusiasmo pelo programa de
gerenciamento de dados e o ímpeto de contribuir para uma mudança positiva. É aconselhável evitar análises detalhadas e abrangentes
e enfatizar o julgamento sólido com base na experiência dos líderes de avaliação. Os DMM Frameworks fornecem os critérios de
medição e um caminho incorporado para a melhoria. Eles permitem a síntese de uma visão completa do atual programa de
Gerenciamento de Dados e suas partes.
2.1.5 Planejar Comunicações
As comunicações contribuem para o sucesso geral da avaliação e dos itens de ação resultantes dela.
A comunicação será dirigida aos participantes e outras partes interessadas. As descobertas podem impactar o trabalho das pessoas,
por meio de mudanças na metodologia e no alinhamento organizacional, por isso é importante comunicar claramente sobre o propósito,
o processo e as expectativas específicas para indivíduos e grupos. Certifique-se de que os participantes compreendam o modelo de
avaliação, bem como a forma como os resultados serão usados.

542 • DMBOK2
Antes do início da avaliação, as partes interessadas devem ser informadas sobre as expectativas para a avaliação.
As comunicações devem descrever:
• O objetivo do DMMA
• Como será conduzido
• Qual pode ser o envolvimento deles

• O cronograma de atividades de avaliação
Durante qualquer atividade da avaliação (por exemplo, uma reunião de grupo focal), certifique-se de que haja uma agenda clara, incluindo um
plano para responder a quaisquer perguntas de acompanhamento. Lembre continuamente os participantes das metas e objetivos.
Sempre agradeça aos participantes e descreva os próximos passos.
Determine se a abordagem planejada provavelmente será bem-sucedida em todo o escopo de negócios visado, incluindo fatores como
resistência/cooperação, possíveis preocupações legais internas sobre exposição a inspeção externa se forem encontradas lacunas
preocupantes ou possíveis preocupações de recursos humanos.
O plano de comunicação deve incluir um cronograma para relatar as descobertas e recomendações em todos os níveis, incluindo relatórios
gerais e briefings executivos.
2.2 Realizar Avaliação de Maturidade
2.2.1 Reunir Informações
O próximo passo é reunir as entradas apropriadas para a avaliação, com base no modelo de interação. No mínimo, as informações coletadas
incluirão classificações formais dos critérios de avaliação. Também pode incluir informações de entrevistas e grupos focais, análise de sistema
e documentação de projeto, investigação de dados, sequências de e-mail, manuais de procedimentos, padrões, políticas, repositórios de
arquivos, fluxos de trabalho de aprovação, vários produtos de trabalho, repositórios de metadados, arquiteturas de referência de dados e
integração, modelos , e formulários.
2.2.2 Realizar a Avaliação
As atribuições gerais de classificação e interpretação são tipicamente multifásicas. Os participantes terão opiniões diferentes gerando
classificações diferentes nos tópicos de avaliação. Discussão e racionalização serão necessárias para conciliar as classificações. A entrada é
fornecida pelos participantes e depois refinada por meio de revisões de artefatos ou exame pela equipe de avaliação. O objetivo é chegar a
uma visão consensual do estado atual. Essa visão deve ser apoiada por evidências (ou seja, prova de prática demonstrada por comportamento
e artefatos). Se as partes interessadas não tiverem consenso sobre o estado atual, é difícil chegar a um consenso sobre como melhorar a
organização.
O refinamento geralmente funciona da seguinte forma:

• Analise os resultados em relação ao método de classificação e atribua uma classificação preliminar a cada produto de trabalho ou
atividade.
• Documente as evidências de apoio.
• Reveja com os participantes para chegar a um consenso sobre uma classificação final para cada área. Se apropriado, use
modificadores de peso com base na importância de cada critério.
• Documente a interpretação da classificação usando as declarações de critérios do modelo e comentários do avaliador.
• Desenvolva visualizações para ilustrar os resultados da avaliação.
2.3 Interpretar Resultados
A interpretação dos resultados consiste em identificar oportunidades de melhoria alinhadas à estratégia organizacional e recomendar ações
necessárias para aproveitar essas oportunidades. Em outras palavras, a interpretação define os próximos passos em direção a um estado alvo.
Quando a avaliação estiver concluída, as organizações precisam planejar o estado-alvo que desejam alcançar no gerenciamento de dados. A
quantidade de tempo e esforço necessários para atingir a meta desejada varia, dependendo do ponto de partida, da cultura da organização e dos
fatores de mudança.
Ao apresentar os resultados da avaliação, comece com o significado das classificações para a organização. As classificações podem ser
expressas em relação a direcionadores organizacionais e culturais, bem como metas de negócios, como satisfação do cliente ou aumento de
vendas. Ilustre a ligação entre os recursos atuais da organização e os processos e estratégias de negócios que eles suportam, e os benefícios
de melhorar esses recursos movendo-se para o estado de destino.
2.3.1 Relatório de Resultados da Avaliação
O relatório de avaliação deve incluir:
• Impulsionadores de negócios para a avaliação
• Resultados gerais da avaliação
• Classificações por tópico com lacunas indicadas
• Uma abordagem recomendada para fechar lacunas
• Pontos fortes da organização observados
• Riscos para progredir
• Opções de investimento e resultados
• Governança e métricas para medir o progresso
• Análise de recursos e potencial utilização futura
• Artefatos que podem ser usados ou reutilizados dentro da organização
O relatório de avaliação é um insumo para o aprimoramento do programa de Gerenciamento de Dados, seja como um todo ou por Área de
Conhecimento de Gerenciamento de Dados. A partir dele, a organização pode desenvolver ou avançar sua gestão de dados
544 • DMBOK2
estratégia. A estratégia deve incluir iniciativas que promovam os objetivos de negócios por meio de uma melhor governança de processos e
padrões.
2.3.2 Desenvolver briefings executivos
A equipe de avaliação deve preparar briefings executivos que resumam as descobertas – pontos fortes, lacunas e recomendações – que os
executivos usarão como entrada para decisões sobre metas, iniciativas e cronogramas. A equipe deve adaptar as mensagens para
esclarecer os prováveis impactos e benefícios para cada grupo executivo.
Muitas vezes, os executivos desejam mirar mais alto do que as recomendações da avaliação. Em outras palavras, eles querem pular níveis
no modelo de maturidade. A meta de um nível mais alto de maturidade deve ser refletida na análise de impacto das recomendações. Há um
custo para esse tipo de aceleração, e os custos devem ser equilibrados com os benefícios.
2.4 Criar um programa direcionado para melhorias
O DMMA deve ter um impacto direto na estratégia de dados e governança de TI, bem como no programa e estratégia de gerenciamento de
dados. As recomendações do DMMA devem ser acionáveis. Eles devem descrever as capacidades que a organização requer. Ao fazer
isso, uma avaliação pode ser uma ferramenta poderosa para os líderes de TI e de negócios definirem prioridades organizacionais e
alocarem recursos.
2.4.1 Identificar ações e criar um roteiro
As classificações do DMMA destacam itens para atenção da administração. Inicialmente, é provável que uma classificação seja usada como
uma métrica independente para determinar quão bem uma organização está realizando uma atividade específica. No entanto, as
classificações podem ser rapidamente operacionalizadas em medidas contínuas, especialmente para atividades em que a mudança é
desejada (por exemplo, “A meta é o nível 'n' porque precisamos ou queremos ser capazes de fazer algo 'z'”). Se o modelo de avaliação for
usado para medição contínua, seus critérios não apenas orientam a organização para níveis mais altos de maturidade, mas também mantêm
a atenção organizacional nos esforços de melhoria.
Os resultados da avaliação do DMM devem ser detalhados e abrangentes o suficiente para dar suporte a um programa de aprimoramento
de gerenciamento de dados de vários anos, incluindo iniciativas que desenvolverão a capacidade de gerenciamento de dados à medida que
a organização adotar as melhores práticas. Como a mudança ocorre em grande parte nas organizações por meio de projetos, novos projetos
devem ser influenciados a adotar melhores práticas. O roteiro ou plano de referência deve conter:
• Atividades sequenciadas para efetuar melhorias em funções específicas de gerenciamento de dados
• Um cronograma para implementar atividades de melhoria
• Melhorias esperadas nas classificações DMMA uma vez que as atividades tenham sido implementadas
• Atividades de supervisão, incluindo o amadurecimento dessa supervisão ao longo do cronograma

O roteiro fornecerá metas e um ritmo de mudança dentro dos fluxos de trabalho priorizados e acompanhado por uma abordagem para medir o
progresso.
2.5 Reavaliar Maturidade
As reavaliações devem ser realizadas em intervalos regulares. Fazem parte do ciclo de melhoria contínua:
• Estabeleça uma classificação de linha de base através da primeira avaliação
• Definir parâmetros de reavaliação, incluindo escopo organizacional
• Repita a avaliação do DMM conforme necessário em um cronograma publicado

• Acompanhe as tendências em relação à linha de base inicial
• Desenvolver recomendações com base nas descobertas da reavaliação
A reavaliação também pode revigorar ou reorientar o esforço. O progresso mensurável ajuda a manter o compromisso e o entusiasmo em toda a
organização. Mudanças nos marcos regulatórios, políticas internas ou externas, ou inovações que possam mudar a abordagem de governança e
estratégias são motivos adicionais para reavaliar periodicamente.
3. Ferramentas
• Data Management Maturity Framework: A principal ferramenta usada em uma avaliação de maturidade é a
própria estrutura do DMM.
• Plano de Comunicação: Um plano de comunicação inclui um modelo de engajamento para as partes interessadas, o
tipo de informação a ser compartilhada e o cronograma para compartilhamento de informações.
• Ferramentas de colaboração: As ferramentas de colaboração permitem que os resultados da avaliação sejam compartilhados. Além disso,
evidências de práticas de gerenciamento de dados podem ser encontradas em e-mail, modelos preenchidos e revisão
documentos criados por meio de processos padrão para design colaborativo, operações, rastreamento de incidentes,
revisões e aprovações.
• Gestão do Conhecimento e Repositórios de Metadados: Padrões de dados, políticas, métodos, agendas,
atas de reuniões ou decisões e artefatos de negócios e técnicos que servem como prova de prática
podem ser gerenciados nesses repositórios. Em alguns CMMs, a falta de tais repositórios é um indicador de
menor maturidade na organização. Os repositórios de metadados podem existir em várias construções, que podem
não seja óbvio para os participantes. Por exemplo, alguns aplicativos de Business Intelligence dependem
completamente em Metadados para compilar suas visualizações e relatórios, sem se referir a eles como um
repositório distinto.
546 • DMBOK2
4. Técnicas
Muitas técnicas relacionadas à execução de um DMMA são definidas pela metodologia do framework DMM escolhido. Técnicas que são
mais gerais são descritas aqui.
4.1 Selecionando uma estrutura DMM
Os critérios a seguir devem ser considerados ao selecionar uma estrutura DMM.
• Acessibilidade: As práticas são expressas em termos não técnicos que transmitem a essência funcional do
atividade.
• Abrangência: A estrutura aborda um amplo escopo de atividades de gerenciamento de dados e
inclui o envolvimento dos negócios, não apenas os processos de TI.
• Extensível e flexível: O modelo é estruturado para permitir o aprimoramento de disciplinas específicas do setor ou
adicionais e pode ser usado no todo ou em parte, dependendo das necessidades da organização.
• Caminho de progresso futuro integrado: Embora as prioridades específicas sejam diferentes de organização para
organização, a estrutura do DMM descreve um caminho lógico a seguir em cada uma das funções que descreve. •
Independente do setor versus específico do setor: algumas organizações se beneficiarão de uma abordagem específica do
setor, outras de uma estrutura mais genérica. Qualquer estrutura de DMM também deve aderir às práticas recomendadas
de gerenciamento de dados que cruzam as verticais.
• Nível de abstração ou detalhe: As práticas e os critérios de avaliação são expressos com um nível de detalhe suficiente para
garantir que possam ser relacionados à organização e ao trabalho que ela realiza.
• Não prescritivo: A estrutura descreve o que precisa ser realizado, não como deve ser
realizado.
• Organizado por tópico: A estrutura coloca as atividades de gerenciamento de dados em seu contexto apropriado,
permitindo que cada um seja avaliado separadamente, reconhecendo as dependências.
• Repetível: A estrutura pode ser interpretada de forma consistente, suportando resultados repetíveis para comparação
uma organização contra outras em seu setor e acompanhar o progresso ao longo do tempo.
• Apoiado por uma organização neutra e independente: O modelo deve ser neutro em relação ao fornecedor para evitar
conflitos de interesse e amplamente disponível para garantir uma ampla representação das melhores práticas.
• Tecnologia neutra: o foco do modelo deve ser nas práticas, e não nas ferramentas. • Suporte de
treinamento incluído: O modelo é apoiado por treinamento abrangente para permitir
profissionais para dominar o framework e otimizar seu uso.
4.2 Uso da Estrutura DAMA-DMBOK
O DAMA-DMBOK pode ser usado para preparar ou estabelecer critérios para um DMMA. Os proprietários de execução verão uma
ligação direta entre as funções segmentadas (as Áreas de Conhecimento) e as tarefas correspondentes (atividades).
As áreas de conhecimento, atividades e entregas (produtos de trabalho) do DMBOK podem ser configuradas para uma estrutura específica do
DMM com base nas áreas medidas, suas atividades de suporte, relevância e tempo disponível. Essa abordagem rápida de lista de verificação pode
ser usada para determinar áreas que precisam de uma análise mais profunda, representar lacunas ou apontar pontos críticos para correção.
O DMBOK oferece uma vantagem adicional como ferramenta de planejamento de avaliação: há uma grande comunidade de profissionais do
conhecimento usando o DMBOK como guia em vários setores, criando uma comunidade de prática em torno de seu uso.
5. Diretrizes para um DMMA
Antes de realizar uma avaliação de maturidade, é útil identificar riscos potenciais e algumas estratégias de mitigação de riscos. A Tabela 33 resume
os riscos e as abordagens de mitigação.
Tabela 33 Riscos e Mitigações Típicos para um DMMA
Risco Mitigação
Falta de adesão organizacional Socialize os conceitos relacionados à avaliação.
Estabeleça declarações de benefícios antes de realizar a avaliação. Compartilhe artigos e histórias
de sucesso. Envolva um patrocinador executivo para defender o esforço e revisar os resultados.
Falta de experiência em DMMA Use recursos de terceiros ou especialistas. Exigir transferência de conhecimento e treinamento
Falta de tempo ou experiência como parte do trabalho.
interna
Falta de planejamento ou
padrões de comunicação
Falta de 'Data Speak' na organização; Relacione o DMMA a problemas ou cenários de negócios específicos.
As conversas sobre dados rapidamente Endereço no plano de comunicação. O DMMA educará todos os participantes,
se transformam em discussões sobre independentemente de sua formação e experiência técnica. Oriente os participantes para
sistemas conceitos-chave anteriores ao DMMA.
Ativos incompletos ou Sinalize 'a partir de' ou equilibre o rating de acordo. Por exemplo, dê um -1 para tudo que está
desatualizados para análise desatualizado há mais de 1 ano.
Foco estreito Reduza a profundidade da investigação para um DMMA simples e vá para outras áreas para uma
avaliação rápida para estabelecer classificações para uma linha de base comparativa posterior.
Conduza o primeiro DMMA como piloto e, em seguida, aplique as lições aprendidas para abordar
um escopo mais amplo. Apresentar o foco no escopo da avaliação proposta no contexto das Áreas
de Conhecimento DAMA-DMBOK. Ilustre o que está sendo deixado de fora do escopo e discuta a
necessidade de incluir.
Equipe ou sistemas inacessíveis Reduzir o escopo horizontal do DMMA, concentrando-se apenas nas Áreas de Conhecimento e
funcionários disponíveis
Surgem surpresas, como Adicione flexibilidade ao fluxo de trabalho de avaliação e foco.
mudanças na regulamentação
548 • DMBOK2
5.2 Mudança Organizacional e Cultural
O estabelecimento ou aprimoramento de um programa de gerenciamento de dados inclui mudanças nos processos, métodos e ferramentas.
Com essas mudanças, a cultura também deve mudar. A transformação organizacional e cultural começa com o reconhecimento de que as coisas
podem ser melhores. As funções de medição normalmente introduzem mudanças significativas. O DMMA localiza a organização em uma escala de
maturidade e fornece um roteiro para melhoria. Ao fazê-lo, pode apontar uma organização para a frente através da mudança. Os resultados do DMMA
devem fazer parte de uma discussão maior dentro de uma organização. Quando apoiados adequadamente por uma governança de dados eficaz, os
resultados do DMMA podem unir diferentes perspectivas, resultar em uma visão compartilhada e acelerar o progresso de uma organização. (Consulte
o Capítulo 17.)
6. Governança da Gestão de Maturidade
Normalmente, um DMMA faz parte de um conjunto geral de atividades de governança de dados, cada uma com um ciclo de vida. O ciclo de vida de
um DMMA consiste no planejamento inicial e avaliação inicial, seguido de recomendações, plano de ação e reavaliação periódica. O próprio ciclo de
vida deve ser governado.
6.1 Supervisão do Processo DMMA
A supervisão do processo DMMA pertence à equipe de Governança de Dados. Se a Governança de Dados formal não estiver em vigor, o padrão de
supervisão será o comitê de direção ou a camada de gerenciamento que iniciou o DMMA. O processo deve ter um patrocinador executivo, idealmente
o CDO, para garantir que as melhorias nas atividades de gerenciamento de dados sejam mapeadas diretamente para os objetivos do negócio.
A amplitude e profundidade da supervisão dependem do escopo do DMMA. Cada função envolvida no processo tem voz na execução, método,
resultados e roteiros provenientes da avaliação geral. Cada área de gerenciamento de dados e função da organização envolvida terá uma visão
independente, mas também terá uma linguagem comum por meio da estrutura do DMM.
6.2 Métricas
Além de ser um componente central de qualquer estratégia de melhoria, as métricas são uma ferramenta fundamental de comunicação.
As métricas iniciais do DMMA são as classificações que representam o estado atual do gerenciamento de dados. Estes podem ser reavaliados
periodicamente para mostrar tendências de melhoria. Cada organização deve desenvolver métricas adaptadas ao seu roteiro de estado de destino.
As métricas de amostra podem incluir:
• Classificações do DMMA: as classificações do DMMA apresentam um instantâneo do nível de capacidade da organização. As classificações
pode ser acompanhado por uma descrição, talvez uma ponderação personalizada para a classificação em uma avaliação
ou área de tópico específica e um estado de destino recomendado.

• Taxas de utilização de recursos: exemplos poderosos de métricas que ajudam a expressar o custo dos dados
gestão na forma de contagem. Um exemplo desse tipo de métrica é: “Cada recurso na organização gasta 10% de seu
tempo agregando dados manualmente”.
• A exposição ao risco ou a capacidade de responder a cenários de risco expressa as capacidades de uma organização
em relação às suas classificações DMMA. Por exemplo, se uma organização quisesse iniciar um novo negócio que exigisse
um alto nível de automação, mas seu modelo operacional atual é baseado no gerenciamento manual de dados (Nível 1),
ela correria o risco de não entregar.
• O gerenciamento de gastos expressa como o custo do gerenciamento de dados é alocado em uma organização
e identifica os impactos desse custo na sustentabilidade e no valor. Essas métricas se sobrepõem às métricas de
governança de dados.
o Sustentabilidade da gestão de dados o
Alcance das metas e objetivos da iniciativa

o Eficácia da comunicação
o Eficácia da educação e treinamento o Velocidade
de adoção da mudança o Valor do gerenciamento de
dados o Contribuições para os objetivos de negócios
o Reduções de riscos
o Maior eficiência nas operações
• As entradas para o DMMA são importantes para gerenciar, pois falam da abrangência da cobertura, nível de investigação e
detalhes do escopo relevante para a interpretação dos resultados da pontuação. As entradas principais podem incluir o
seguinte: contagem, cobertura, disponibilidade, número de sistemas, volumes de dados, equipes envolvidas, etc.
• Taxa de Mudança A taxa na qual uma organização está melhorando sua capacidade. Uma linha de base é estabelecida
através do DMMA. A reavaliação periódica é usada para melhorar a tendência.

Afflerbach, Peter. Leituras Essenciais sobre Avaliação. Associação Internacional de Leitura, 2010. Imprimir.
Baskarada, Sasa. IQM-CMM: Modelo de Maturidade da Capacidade de Gestão da Qualidade da Informação. Vereg+Teubner Verlag, 2009.
impressão. Excelente trabalho sobre qualidade da informação.
Boutros, Tristan e Tim Purdie. O Manual de Melhoria de Processos: Um Plano para Gerenciar Mudanças e Aumentar o Desempenho Organizacional.
McGraw-Hill Education, 2013. Imprimir.
Instituto CMMI (site). http://bit.ly/1Vev9xx.
Crawford, J. Kent. Modelo de Maturidade em Gerenciamento de Projetos. 3ª edição. Publicações Auerbach, 2014. Impresso. Pesquisa de
soluções PM.
550 • DMBOK2
Conselho de Gestão de Dados Empresariais (site).
Freund, Jack e Jack Jones. Medindo e Gerenciando o Risco da Informação: Uma Abordagem JUSTA. Butterworth-Heinemann, 2014. Print.
Ghavami, Peter PhD. Governança de Big Data: Princípios modernos de gerenciamento de dados para Hadoop, NoSQL e Big Data Analytics.
Plataforma de Publicação Independente CreateSpace, 2015. Imprimir.
Honeyset, Sarah. Capacidade Limitada - A Fase de Avaliação. Amazon Digital Services LLC., 2013. Social Insecurity Book 3.
Conselho de Governança de Dados da IBM. https://ibm.co/2sUKing.
Jeff Gorball, Introdução aos modelos de maturidade de gerenciamento de dados. SlideShare.net, 2016-08-01. http://bit.ly/2tsIOqR.
Marchewka, Jack T. Gerenciamento de Projetos de Tecnologia da Informação: Fornecendo Valor Organizacional Mensurável. 5ª edição.
McSweeney, Alan. Revisão dos Modelos de Maturidade da Gestão de Dados. SlideShare.net, 23/10/2013. http://bit.ly/2spTCY9.
Persse, James R. Implementando o Modelo de Maturidade de Capacidade. Wiley, 2001.Print.
Saaksvuori, Antti. Estrutura de avaliação da maturidade do gerenciamento de produtos. Sirrus Publishing Ltd., 2015. Impresso.
Selecione Soluções de Negócios. “O que é o Modelo de Maturidade de Capacidade?” http://bit.ly/IFMJI8 (Acessado em 2016-11-10).
Universidade de Stanford. Modelo de maturidade de governança de dados de Stanford. http://stanford.io/2ttOMrF.
Editora Van Haren. Estrutura de maturidade de capacidade de TI IT-CMF. Van Haren Pub, 2015. Impresso.
CAPÍTULO 1 6
Organização e função de gerenciamento de dados

Expectativas
1. Introdução
T
O cenário de dados está evoluindo rapidamente e, com ele, as organizações precisam evoluir as formas como gerenciam
e governar os dados. A maioria das organizações hoje se depara com um volume crescente de dados capturados
através de uma ampla gama de processos em uma variedade de formatos. O aumento no volume e na variedade adiciona
complexidade ao gerenciamento de dados. Ao mesmo tempo, os consumidores de dados agora exigem acesso rápido e fácil aos dados.
Eles querem ser capazes de entender os dados e usá-los para abordar questões críticas de negócios em tempo hábil.
As organizações de gerenciamento de dados e governança de dados devem ser flexíveis o suficiente para trabalhar com eficiência
nesse ambiente em evolução. Para fazer isso, eles precisam esclarecer questões básicas sobre propriedade, colaboração,
responsabilidade e tomada de decisão.
Esta seção descreverá um conjunto de princípios que devem ser considerados ao montar uma organização de gerenciamento de
dados ou governança de dados. Refere-se tanto à governança de dados quanto ao gerenciamento de dados porque a governança de
dados fornece a orientação e o contexto de negócios para as atividades executadas pela Organização de Gerenciamento de Dados.
Não existe uma estrutura organizacional perfeita para nenhum dos dois. Embora os princípios comuns devam ser aplicados à
organização em torno da governança de dados e do gerenciamento de dados, muitos detalhes dependerão dos direcionadores do
setor da empresa e da cultura corporativa da própria empresa.
2. Compreender a Organização Existente e as Normas Culturais
Conscientização, propriedade e responsabilidade são as chaves para ativar e engajar as pessoas em iniciativas, políticas e processos
de gerenciamento de dados. Antes de definir qualquer nova organização ou tentar melhorar uma existente, é importante entender o
estado atual dos componentes, relacionados à cultura, ao modelo operacional existente e às pessoas. Consulte a Figura 106. Por
exemplo:
• O papel dos dados na organização: Quais processos-chave são orientados por dados? Como são os requisitos de dados
definido e compreendido? Quão bem reconhecido é o papel que os dados desempenham na estratégia organizacional?
551
552 • DMBOK2
Operativo
• Como as decisões são tomadas?
Modelo
• Proprietário do Gerenciamento de Dados
• Quem os faz?
• Proprietário da Governança de Dados
• Como os comitês são usados? • Centralizado
• Descentralizado • Especialistas no assunto
• Quem gerencia atualmente
• Liderança
dados? • Híbrido/Federado
Cultura Pessoas
Figura 106 Avaliar o estado atual para criar um modelo operacional
• Normas culturais sobre dados: Existem potenciais obstáculos culturais para implementar ou melhorar
estruturas de gestão e governança?
• Práticas de gerenciamento e governança de dados: como e por quem é o trabalho relacionado a dados
executado? Como e por quem são tomadas as decisões sobre os dados?
• Como o trabalho é organizado e executado: Por exemplo, qual é a relação entre foco no projeto e
execução operacional? Quais estruturas de comitês estão em vigor que podem apoiar o gerenciamento de dados
esforço?
• Como as relações de subordinação são organizadas: Por exemplo, a organização é centralizada ou
descentralizado, hierárquico ou plano?
• Níveis de habilidade: Qual é o nível de conhecimento de dados e conhecimento de gerenciamento de dados de PMEs e outros
partes interessadas, da equipe de linha aos executivos?
Depois de formar uma imagem do estado atual, avalie o nível de satisfação com o estado atual para obter informações sobre as necessidades e
prioridades de gerenciamento de dados da organização. Por exemplo:
• A organização tem as informações de que precisa para tomar decisões de negócios sólidas e oportunas?
• A organização confia em seus relatórios de receita?
• Pode acompanhar os indicadores chave de desempenho organizacional?
• A organização está em conformidade com todas as leis relativas ao gerenciamento de dados?
A maioria das organizações que buscam melhorar seu gerenciamento de dados ou práticas de governança estão no meio da escala de maturidade
de capacidade (ou seja, não são nem 0 nem 5 na escala CMM). (Consulte o Capítulo 15.) Para criar uma Organização de Gerenciamento de Dados
relevante, é importante entender e acomodar a cultura da empresa e as normas organizacionais existentes. Se a Organização de Gerenciamento
de Dados não estiver alinhada com a tomada de decisão existente e as construções do comitê, será um desafio sustentá-la ao longo do tempo.
Portanto, faz sentido evoluir essas organizações, em vez de impor mudanças radicais.
Uma organização de gerenciamento de dados deve se alinhar com a hierarquia organizacional e os recursos de uma empresa.
Encontrar as pessoas certas requer uma compreensão do papel funcional e político dos dados
ORGANIZAÇÃO DE GERENCIAMENTO DE DADOS E EXPECTATIVAS DE FUNÇÃO • 553
gestão dentro de uma organização. O objetivo deve ser a participação multifuncional das várias partes interessadas do negócio. Para realizar
isso:
• Identificar os funcionários que atualmente desempenham funções de gerenciamento de dados; reconhecê-los e envolvê-los primeiro.
Contrate recursos adicionais apenas à medida que as necessidades de gerenciamento e governança de dados crescem.
• Examinar os métodos que a organização está usando para gerenciar dados e determinar como os processos podem ser
melhorou. Determine quanta mudança provavelmente será necessária para melhorar as práticas de gerenciamento de dados.
• Mapear os tipos de mudanças que precisam ocorrer de uma perspectiva organizacional para melhor atender
requisitos.
3. Construções Organizacionais de Gerenciamento de Dados
Uma etapa crítica no projeto da Organização de Gerenciamento de Dados é identificar o modelo operacional mais adequado para a
organização. O modelo operacional é uma estrutura que articula funções, responsabilidades e processos de tomada de decisão. Ele
descreve como as pessoas e funções irão colaborar.
Um modelo operacional confiável ajuda a criar responsabilidade, garantindo que as funções certas dentro da organização sejam
representadas. Facilita a comunicação e fornece um processo para resolver problemas. Embora forme a base para a estrutura organizacional,
o modelo operacional não é um organograma – não se trata de colocar nomes em caixas, mas de descrever o relacionamento entre os
componentes da organização.
Esta seção apresentará uma visão geral de alto nível dos prós e contras dos modelos operacionais descentralizados, de rede, híbridos,
federados e centralizados.
3.1 Modelo Operacional Descentralizado
Em um modelo descentralizado, as responsabilidades de gerenciamento de dados são distribuídas em diferentes linhas de negócios e TI
(consulte a Figura 107). A colaboração é baseada em comitês; não existe um único dono. Muitos programas de gerenciamento de dados
começam como esforços de base para unificar as práticas de gerenciamento de dados em uma organização e, portanto,
têm uma estrutura descentralizada.
Os benefícios desse modelo incluem sua estrutura relativamente plana e seu alinhamento do gerenciamento de dados às linhas de negócios
ou TI. Esse alinhamento geralmente significa que há uma compreensão clara dos requisitos de dados. Também é relativamente fácil de
implementar ou melhorar.
As desvantagens incluem o desafio de ter muitos participantes envolvidos com os órgãos de governança e na tomada de decisões.
Geralmente é mais difícil implementar decisões colaborativas do que editais centralizados.
Os modelos descentralizados são geralmente menos formais e, por isso, podem ser mais difíceis de sustentar ao longo do tempo. Para
serem bem-sucedidos, eles precisam ter maneiras de impor a consistência das práticas. Isso pode ser difícil de coordenar. Muitas vezes
também é difícil definir a propriedade dos dados com um modelo descentralizado.

554 • DMBOK2
LOB/BU
Comitê Diretor de Gerenciamento de Dados
Grupo de Gerenciamento de Dados LOB/BU
Dados Inscrição O negócio Dados

Comissários Arquitetos Analistas Analistas
Figura 107 Modelo Operacional Descentralizado
3.2 Modelo Operacional da Rede
A informalidade descentralizada pode se tornar mais formal por meio de uma série documentada de conexões e
responsabilidades por meio de uma matriz RACI (Responsible, Accountable, Consultad, and Informed). Isso é
chamado de modelo em rede porque opera como uma série de conexões conhecidas entre pessoas e papéis e
pode ser diagramado como uma 'rede'. (Veja a Figura 108.)
DADOS
GESTÃO
ESCRITÓRIO
Figura 108 Modelo Operacional da Rede

Os benefícios de um modelo de rede são semelhantes aos de um modelo descentralizado (estrutura plana, alinhamento,
configuração rápida). A adição de um RACI ajuda a criar responsabilidade sem afetar os organogramas. A desvantagem
adicional é a necessidade de manter e fazer cumprir as expectativas relacionadas ao RACI.
3.3 Modelo Operacional Centralizado
O modelo operacional de gerenciamento de dados mais formal e maduro é o centralizado (veja a Figura 109). Aqui tudo é
propriedade da Organização de Gerenciamento de Dados. Os envolvidos em governar e gerenciar dados se reportam
diretamente a um líder de gerenciamento de dados que é responsável por Governança, Administração, Gerenciamento de
Metadados, Gerenciamento de Qualidade de Dados, Gerenciamento de Dados Mestres e de Referência, Arquitetura de Dados,
Análise de Negócios, etc.
Executivo Direção
Patrocinador
Comitê
Dados
Gestão
Conduzir
Suporte de negócios Suporte técnico

O negócio Dados Dados Técnico
Análise Gestão Arquitetura Análise de dados
Grupo Grupo Grupo Grupo
Ônibus / LOBs
Figura 109 Modelo Operacional Centralizado
O benefício de um modelo centralizado é que ele estabelece uma posição executiva formal para gerenciamento de dados ou
governança de dados. Há uma pessoa no topo. A tomada de decisão é mais fácil porque a responsabilidade é clara. Dentro da
organização, os dados podem ser gerenciados por tipo ou área de assunto. A desvantagem é que a implementação de um
modelo centralizado geralmente requer uma mudança organizacional significativa. Há também o risco de que a separação
formal da função de gerenciamento de dados a afaste para os principais processos de negócios e possa resultar na perda de
conhecimento ao longo do tempo.
Um modelo centralizado geralmente requer uma nova organização. Surge a pergunta: onde a Organização de Gerenciamento
de Dados se encaixa na empresa como um todo? Quem o lidera e a quem o líder se reporta? Isto
556 • DMBOK2
está se tornando mais comum para uma organização de gerenciamento de dados não se reportar ao CIO devido ao desejo de manter uma
perspectiva de negócios, em vez de TI, sobre os dados. Essas organizações também costumam fazer parte de uma equipe de serviços ou
operações compartilhadas ou parte da organização do Chief Data Officer. (Consulte a Seção 6.1.)
3.4 Modelo Operacional Híbrido
Como o próprio nome indica, o modelo operacional híbrido abrange os benefícios dos modelos descentralizado e centralizado (veja a Figura
110). Em um modelo híbrido, um Centro de Excelência de gerenciamento de dados centralizado trabalha com grupos de unidades de
negócios descentralizados, geralmente por meio de um comitê executivo que representa as principais linhas de negócios e um conjunto de
grupos de trabalho táticos que abordam problemas específicos.
Organização de gerenciamento de dados
Comitê de direção
Centro de Gerenciamento de Dados de

Excelência
Equipes da Unidade de Negócios de Gerenciamento de Dados
Partes Interessadas de Negócios Capacitação de TI
Gerenciamento de dados da BU
Figura 110 Modelo Operacional Híbrido
Nesse modelo, alguns papéis permanecem descentralizados. Por exemplo, os Arquitetos de Dados podem permanecer em um grupo de
Arquitetura Corporativa; linhas de negócios podem ter suas próprias equipes de qualidade de dados. Quais funções são centralizadas e
quais permanecem descentralizadas podem variar muito, dependendo em grande parte da cultura organizacional.
O principal benefício de um modelo híbrido é que ele estabelece a direção apropriada do topo da organização. Existe um executivo
responsável pela gestão de dados e/ou governança. As equipes das Unidades de Negócios têm ampla responsabilidade e podem se alinhar
às prioridades de negócios para fornecer maior foco. Eles se beneficiam do suporte de um Centro de Excelência de gerenciamento de
dados dedicado que pode ajudar a focar em desafios específicos.
Os desafios incluem configurar a organização, já que isso geralmente requer um número adicional de funcionários para a equipe de um
Centro de Excelência. As equipes das Unidades de Negócios podem ter prioridades diferentes, e elas precisarão ser gerenciadas de uma
perspectiva empresarial. Além disso, às vezes há conflitos entre as prioridades da organização central e as das organizações
descentralizadas.
3.5 Modelo Operacional Federado
Uma variação do modelo operacional híbrido, o modelo federado fornece camadas adicionais de centralização/descentralização,
muitas vezes necessárias em grandes empresas globais. Imagine uma organização de gerenciamento de dados corporativo com
vários modelos híbridos de gerenciamento de dados delineados com base na divisão ou região. (Veja a Figura 111.)
Organização de gerenciamento de dados
Direção de gerenciamento de informações corporativas

Comitê
Gerenciamento de dados corporativos

Centro de Excelência
Grupos de gerenciamento de dados
Dados divisionais Dados divisionais Dados divisionais

Gestão Gestão Gestão
Grupo Grupo Grupo
O negócio O negócio O negócio

Partes interessadas Partes interessadas Partes interessadas
Capacitação de TI Capacitação de TI
Capacitação de TI
Figura 111 Modelo Operacional Federado
Um modelo federado fornece uma estratégia centralizada com execução descentralizada. Portanto, para grandes empresas,
pode ser o único modelo que pode funcionar. Um executivo de gerenciamento de dados responsável por toda a organização
administra o Centro de Excelência empresarial. É claro que diferentes linhas de negócios são capacitadas para atender aos
requisitos com base em suas necessidades e prioridades. A federação permite que a organização priorize com base em entidades
de dados específicas, desafios divisionais ou prioridades regionais.
A principal desvantagem é a complexidade. Existem muitas camadas e é preciso haver um equilíbrio entre autonomia para as
linhas de negócios e as necessidades da empresa. Esse equilíbrio pode afetar as prioridades da empresa.
3.6 Identificando o Melhor Modelo para uma Organização
O modelo operacional é um ponto de partida para melhorar as práticas de gerenciamento e governança de dados.
Apresentá-lo requer uma compreensão de como ele pode impactar a organização atual e como provavelmente
558 • DMBOK2
precisam evoluir com o tempo. Uma vez que o modelo operacional servirá como a estrutura através da qual as políticas e processos serão
definidos, aprovados e executados, é fundamental identificar o melhor ajuste para uma organização.
Avalie se a estrutura organizacional atual é centralizada, descentralizada ou uma combinação, hierárquica ou relativamente plana. Caracterize
como as divisões ou regiões são independentes. Eles operam quase auto-suficientemente? Seus requisitos e objetivos são muito diferentes
uns dos outros? Mais importante ainda, tente determinar como as decisões são tomadas (por exemplo, democraticamente ou por decreto),
bem como como elas são implementadas.
As respostas devem fornecer um ponto de partida para entender a localização da organização no espectro entre
descentralizado e centralizado.
3.7 Alternativas DMO e Considerações de Projeto
A maioria das organizações começa com um modelo descentralizado antes de passar para uma organização formal de gerenciamento de
dados (DMO). À medida que uma organização vê o impacto das melhorias na qualidade dos dados, ela pode começar a formalizar a
responsabilidade por meio de uma matriz RACI de gerenciamento de dados e evoluir para um modelo de rede. Com o tempo, as sinergias
entre as funções distribuídas se tornarão mais óbvias e serão identificadas economias de escala que atrairão algumas funções e pessoas para
grupos organizados. Eventualmente, isso pode se transformar em um híbrido ou federado

modelo.
Algumas organizações não podem se dar ao luxo de passar por esse processo de maturidade. Eles são forçados a amadurecer rapidamente
com base em um choque de mercado ou novas regulamentações governamentais. Nesse caso, é importante abordar proativamente o
desconforto associado à mudança organizacional para que ela seja bem-sucedida e sustentável. (Consulte o Capítulo 17.)
Seja qual for o modelo escolhido, lembre-se de que simplicidade e usabilidade são essenciais para aceitação e sustentabilidade. Se o modelo
operacional se adequar à cultura de uma empresa, o gerenciamento de dados e a governança adequada podem ser incorporados às operações
e alinhados à estratégia. Lembre-se dessas dicas quando
construção de um modelo operacional:
• Determine o ponto de partida avaliando o estado atual
• Vincular o modelo operacional à estrutura organizacional

• Leve em consideração:
o Complexidade Organizacional + Maturidade
o Complexidade do Domínio + Maturidade
o Escalabilidade
• Obtenha patrocínio executivo - uma obrigação para um modelo sustentável
• Garantir que qualquer fórum de liderança (comitê de direção, conselho consultivo, conselho) seja uma tomada de decisão
corpo
• Considerar programas piloto e ondas de implementação
• Concentre-se em domínios de dados de alto valor e alto impacto
• Use o que já existe
• Nunca adote uma abordagem de tamanho único

4. Fatores Críticos de Sucesso
Dez fatores demonstraram consistentemente desempenhar um papel fundamental no sucesso de um gerenciamento de dados eficaz
Organizações, independentemente de sua estrutura:
1. Patrocínio executivo
2. Visão clara
3. Gerenciamento proativo de mudanças
4. Alinhamento da liderança
5. Comunicação
6. Engajamento das partes interessadas
7. Orientação e treinamento
8. Medição de adoção
9. Aderência aos princípios orientadores

10. Evolução não revolução
4.1 Patrocínio Executivo
Ter o patrocinador executivo certo garante que as partes interessadas afetadas por um programa de gerenciamento de dados recebam a
orientação necessária para fazer a transição de forma eficiente e eficaz por meio das mudanças necessárias para reunir a nova organização
focada em dados e sustentá-la a longo prazo. O patrocinador executivo deve entender e acreditar na iniciativa. Ele ou ela deve ser capaz de
engajar efetivamente outros líderes em apoio às mudanças.
4.2 Visão Clara
Uma visão clara para a Organização de Gerenciamento de Dados, juntamente com um plano para conduzi-la, é fundamental para o sucesso.
Os líderes organizacionais devem garantir que todas as partes interessadas afetadas pelo gerenciamento de dados – internos e externos –
entendam e internalizem o que é gerenciamento de dados, por que é importante e como seu trabalho afetará e será afetado por ele.
4.3 Gerenciamento Proativo de Mudanças
Gerenciar a mudança associada à criação de uma Organização de Gerenciamento de Dados requer planejamento, gerenciamento e
sustentação da mudança. A aplicação do gerenciamento de mudanças organizacionais ao estabelecimento de uma organização de
gerenciamento de dados aborda os desafios das pessoas e aumenta a probabilidade de que a organização de gerenciamento de dados
desejada seja sustentável ao longo do tempo. (Consulte o Capítulo 17.)

560 • DMBOK2
4.4 Alinhamento de Liderança
O alinhamento da liderança garante que haja acordo – e suporte unificado – para a necessidade de um programa de gerenciamento de
dados e que haja acordo sobre como o sucesso será definido. O alinhamento da liderança inclui o alinhamento entre os objetivos dos
líderes e os resultados e valor do gerenciamento de dados e
alinhamento de propósitos entre os líderes.
Se os líderes não estiverem alinhados uns com os outros, eles acabarão enviando mensagens confusas que podem levar à resistência
e, eventualmente, inviabilizar a mudança. Portanto, é fundamental avaliar – e reavaliar regularmente – os líderes em todos os níveis
para identificar desconexões e tomar medidas para resolvê-las rapidamente.
4.5 Comunicação
A comunicação deve começar cedo e continuar aberta e frequentemente. A organização deve garantir que as partes interessadas
tenham uma compreensão clara do que é gerenciamento de dados e por que é importante para a empresa, o que está mudando e quais
mudanças de comportamento são necessárias. As pessoas não podem melhorar a maneira como gerenciam os dados se não souberem
o que devem fazer de forma diferente. Criar uma história em torno da iniciativa de gerenciamento de dados e construir mensagens-chave
em torno dela ajuda esses processos.
As mensagens devem ser consistentes, ressaltando a importância do gerenciamento de dados. Além disso, eles devem ser customizados
de acordo com o grupo de stakeholders. Por exemplo, o nível de educação ou quantidade de treinamento necessário para diferentes
grupos em relação ao gerenciamento de dados pode variar. As mensagens devem ser repetidas conforme necessário e continuamente
testadas ao longo do tempo para garantir que sejam efetivamente divulgadas e que a conscientização e a compreensão estejam sendo
construídas.
4.6 Engajamento das Partes Interessadas
Indivíduos, bem como grupos, afetados por uma iniciativa de gerenciamento de dados reagirão de maneira diferente ao novo programa
e seu papel dentro dele. A forma como a organização engaja esses stakeholders – como eles se comunicam, respondem e os envolvem
– terá um impacto significativo no sucesso da iniciativa.
Uma análise das partes interessadas ajuda a organização a entender melhor as pessoas afetadas pelas mudanças no gerenciamento
de dados. Ao coletar essas informações e mapear as partes interessadas de acordo com o nível de influência dentro da organização e
o nível de interesse (ou efeito devido) na implementação do gerenciamento de dados, a organização pode determinar a melhor
abordagem para engajar diferentes partes interessadas no processo de mudança. (Consulte a Seção 5.3.)
4.7 Orientação e Treinamento
A educação é essencial para fazer o gerenciamento de dados acontecer, embora grupos diferentes exijam tipos diferentes
e níveis de ensino.
Os líderes precisarão de orientação para os aspectos mais amplos do gerenciamento de dados e do valor para a empresa. Administradores
de dados, proprietários e guardiões (ou seja, aqueles que estão na linha de frente da mudança) exigirão um conhecimento profundo da
iniciativa de gerenciamento de dados. O treinamento focado permitirá que eles desempenhem suas funções de forma eficaz. Isso significa
treinamento em novas políticas, processos, técnicas, procedimentos e até ferramentas.
4.8 Medição de Adoção
É importante construir métricas em torno do progresso e adoção das diretrizes de gerenciamento de dados e planejar saber se o roteiro de
gerenciamento de dados está funcionando e que continuará funcionando. Plano para medir:
• Adoção
• Quantidade de melhoria, ou o delta de um estado anterior
• Os aspectos facilitadores do gerenciamento de dados - quão bem o gerenciamento de dados influencia as soluções com
resultados mensuráveis?
• Processos e projetos aprimorados
• Melhor identificação e reação ao risco
• O aspecto de inovação do gerenciamento de dados - quão bem o gerenciamento de dados muda fundamentalmente
como os negócios são conduzidos?
• Análise confiável
O aspecto facilitador do gerenciamento de dados pode se concentrar na melhoria de processos centrados em dados, como fechamento do
mês, identificação de risco e eficiência da execução do projeto. O aspecto de inovação do gerenciamento de dados pode se concentrar na
melhoria na tomada de decisões e na análise por meio de dados aprimorados e confiáveis.
4.9 Adesão aos Princípios Orientadores
Um princípio orientador é uma declaração que articula valores organizacionais compartilhados, fundamenta a visão e a missão estratégicas e
serve como base para a tomada de decisão integrada. Os princípios orientadores constituem as regras, restrições, critérios prioritários e
comportamentos pelos quais uma organização cumpre em suas atividades diárias no longo prazo. Independentemente de haver um modelo
operacional descentralizado ou centralizado, ou algo intermediário, é fundamental estabelecer e concordar com princípios orientadores para
que todos os participantes se comportem de maneira sincronizada. Os princípios orientadores servem como pontos de referência a partir dos
quais todas as decisões serão tomadas. Estabelecê-los é um primeiro passo importante na criação de um programa de gerenciamento de
dados que conduza efetivamente as mudanças de comportamento.
4.10 Evolução Não Revolução
Em todos os aspectos do gerenciamento de dados, a filosofia de 'evolução, não revolução' ajuda a minimizar grandes mudanças ou projetos
de alto risco em grande escala. É importante estabelecer uma organização que evolua e amadureça ao longo do tempo.
Melhorar incrementalmente a maneira como os dados são gerenciados e priorizados pelos objetivos de negócios garantirá que
562 • DMBOK2
novas políticas e processos são adotados e a mudança de comportamento é sustentada. A mudança incremental também é muito mais
fácil de justificar, por isso é mais fácil obter o apoio e a adesão das partes interessadas e envolver esses participantes críticos.
5. Construa a Organização de Gerenciamento de Dados
5.1 Identifique os participantes atuais do gerenciamento de dados
Ao implementar o modelo operacional, comece com equipes já engajadas em atividades de gerenciamento de dados. Isso minimizará
o efeito na organização e ajudará a garantir que o foco da equipe seja os dados, não o RH ou a política.
Comece revisando as atividades de gerenciamento de dados existentes, como quem cria e gerencia dados, quem mede a qualidade
dos dados ou mesmo quem tem 'dados' em seu cargo. Faça uma pesquisa na organização para descobrir quem já pode estar cumprindo
as funções e responsabilidades necessárias. Esses indivíduos podem ter títulos diferentes. Eles são provavelmente parte de uma
organização distribuída e não necessariamente reconhecidos pela empresa. Depois de compilar uma lista de 'pessoas de dados',
identifique as lacunas. Quais funções e conjuntos de habilidades adicionais são necessários para executar a estratégia de dados? Em
muitos casos, pessoas em outras partes da organização têm conjuntos de habilidades transferíveis e análogos. Lembre-se, as pessoas
que já estão na organização trazem conhecimento e experiência valiosos para um esforço de gerenciamento de dados.
Depois que um inventário estiver concluído e as pessoas forem atribuídas às funções, revise sua remuneração e alinhe-a com as
expectativas do gerenciamento de dados. Provavelmente, o departamento de Recursos Humanos se envolverá para validar os títulos,
funções, remuneração e objetivos de desempenho. Assegure-se de que as funções sejam atribuídas às pessoas certas no nível certo
dentro da organização, para que, quando estiverem envolvidas na tomada de decisões, tenham credibilidade para tomar decisões que
sejam válidas.
5.2 Identifique os participantes do comitê
Independentemente do modelo operacional escolhido por uma organização, algum trabalho de governança precisará ser feito por um
Comitê Gestor de Governança de Dados e por grupos de trabalho. É importante colocar as pessoas certas no Comitê Diretor e usar
bem seu tempo. Mantenha-os bem informados e focados nas maneiras pelas quais o gerenciamento de dados aprimorado os ajudará a
alcançar os objetivos de negócios, incluindo metas estratégicas.
Muitas organizações estão relutantes em iniciar mais um comitê, já que existem muitos já existentes. Muitas vezes, é mais fácil
aproveitar os comitês existentes para avançar nos tópicos de gerenciamento de dados do que iniciar um novo. Mas siga este caminho
com cautela. O principal risco de usar um comitê existente é que o gerenciamento de dados pode não receber a atenção necessária,
especialmente nos estágios iniciais. O processo de contratação de um comitê de direção sênior ou de um grupo de trabalho mais tático
requer a realização de uma análise das partes interessadas e, por meio disso, a identificação de patrocinadores executivos.
5.3 Identificar e Analisar as Partes Interessadas
Uma parte interessada é qualquer pessoa ou grupo que possa influenciar ou ser afetado pelo programa de Gerenciamento de Dados.
As partes interessadas podem ser internas ou externas à organização. Eles incluem PMEs individuais, líderes seniores, equipes de
funcionários, comitês, clientes, agências governamentais ou reguladoras, corretores, agentes, fornecedores, etc.
As partes interessadas internas podem vir de TI, operações, conformidade, jurídico, RH, finanças ou outras linhas de negócios.
As partes interessadas externas podem ser influentes e é importante que suas necessidades sejam consideradas pela Organização de
Gerenciamento de Dados.
Uma análise das partes interessadas pode ajudar a organização a determinar a melhor abordagem para envolver os participantes no
processo de gerenciamento de dados e alavancar suas funções dentro do modelo operacional. O insight obtido com a análise também
é útil para determinar a melhor forma de alocar o tempo e outros recursos limitados. Quanto mais cedo essa análise for realizada,
melhor, pois quanto mais a organização for capaz de antecipar as reações à mudança, mais poderá planejar para elas. Uma análise
das partes interessadas ajudará a responder perguntas como:
• Quem será afetado pelo gerenciamento de dados?
• Como os papéis e responsabilidades mudarão?
• Como os afetados podem responder às mudanças?
• Que problemas e preocupações as pessoas terão?
A análise resultará em uma lista de partes interessadas, suas metas e prioridades e por que essas metas são importantes para elas.
Descubra quais ações são necessárias para as partes interessadas com base na análise. Preste atenção especial ao que precisa ser
feito para trazer as partes interessadas críticas, aquelas que podem fazer ou quebrar o sucesso do gerenciamento de dados de uma
organização, especialmente suas prioridades iniciais. Considerar:
• Quem controla os recursos críticos
• Quem pode bloquear iniciativas de gerenciamento de dados, direta ou indiretamente

• Quem poderia influenciar outros constituintes críticos
• Como as partes interessadas apoiam as próximas mudanças
A Figura 112 fornece um mapa simples para ajudar a priorizar as partes interessadas com base em sua influência, seu nível de
interesse no programa ou o grau de impacto do programa sobre elas.
5.4 Envolver as Partes Interessadas
Depois de identificar as partes interessadas e um bom patrocinador executivo, ou uma pequena lista para escolher, é importante
articular claramente por que cada uma das partes interessadas deve ser envolvida. Eles podem não aproveitar a chance. A pessoa ou
equipe que conduz o esforço de gerenciamento de dados deve articular as razões pelas quais cada parte interessada é necessária
para o sucesso do programa. Isso significa entender seus objetivos pessoais e profissionais e ser capaz de vincular a saída dos
processos de gerenciamento de dados aos seus objetivos, para que eles possam ver uma conexão direta.
Sem uma compreensão dessa conexão direta, eles podem estar dispostos a ajudar a curto prazo, mas não fornecerão suporte ou
assistência a longo prazo.

564 • DMBOK2
Conheça seus
Jogador-chave
Precisa
Priorização
do
Partes interessadas
Mais baixo mostrar

Prioridade Consideração
Interesse das Partes Interessadas
Figura 112 Mapa de Interesse das Partes Interessadas
6. Interações entre o DMO e outros órgãos orientados a dados
Uma vez que o modelo operacional é estabelecido e os participantes são identificados, é hora de mover as pessoas para as funções recém-
autorizadas. Operacionalizar a organização significa estabelecer os comitês e engajar os stakeholders. Em um modelo centralizado, a maior
parte da atividade de gerenciamento de dados será controlada dentro de uma organização. No entanto, com um modelo descentralizado ou
de rede, a Organização de Gerenciamento de Dados precisará trabalhar com outros grupos que tenham um impacto significativo na maneira
como os dados são gerenciados. Esses grupos são normalmente:
• Organização do Diretor de Dados

• Órgãos de Governança de Dados
• Qualidade de dados
• Arquitetura Empresarial
6.1 O Diretor de Dados

Embora a maioria das empresas reconheça em algum nível que os dados são um ativo corporativo valioso, apenas algumas nomearam um
Chief Data Officer (CDO) para ajudar a preencher a lacuna entre tecnologia e negócios e evangelizar uma estratégia de gerenciamento de
dados em toda a empresa em um nível sênior. Esse papel está aumentando, no entanto, com o Gartner estimando que metade de todas as
empresas regulamentadas empregará um CDO até 2017 (Gartner, 2015).

Embora os requisitos e funções de um CDO sejam específicos para a cultura, estrutura organizacional e necessidades de
negócios de cada empresa, muitos CDOs tendem a ser parte estrategista de negócios, consultor, administrador de qualidade de
dados e embaixador geral do gerenciamento de dados.
Em 2014, a Dataversity publicou uma pesquisa delineando mandatos comuns para um CDO.103 Estes incluem:
• Estabelecer uma estratégia de dados organizacionais

• Alinhar requisitos centrados em dados com recursos de negócios e TI disponíveis
• Estabelecer padrões, políticas e procedimentos de governança de dados
• Fornecer consultoria (e talvez serviços) à empresa para iniciativas dependentes de dados, como negócios
análise, Big Data, qualidade de dados e tecnologias de dados
• Evangelizando a importância de bons princípios de gestão de informações para internos e externos
partes interessadas do negócio
• Supervisão do uso de dados em análises e Business Intelligence
As descobertas da Dataversity também destacaram a mudança de foco em diferentes setores.
Independentemente do setor, é comum que uma organização de gerenciamento de dados relate por meio do CDO. Em um
modelo operacional mais descentralizado, o CDO é responsável pela estratégia de dados, mas os recursos que estão em TI,
operações ou outras linhas de negócios executam essa estratégia. Alguns DMOs são estabelecidos inicialmente com o CDO
apenas determinando a estratégia e, com o tempo, outros aspectos de gerenciamento de dados, governança e análise são
dobrado sob o guarda-chuva do CDO à medida que eficiências e economias de escala são identificadas.
6.2 Governança de Dados
A Governança de Dados é a estrutura organizadora para estabelecer a estratégia, os objetivos e a política para o gerenciamento
eficaz de dados corporativos. Consiste nos processos, políticas, organização e tecnologias necessárias para gerenciar e garantir
a disponibilidade, usabilidade, integridade, consistência, auditabilidade e segurança dos dados. Como um Programa de
Governança de Dados consiste no interfuncionamento de estratégia, padrões, políticas e comunicação sobre dados, ele tem uma
relação sinérgica com o gerenciamento de dados. A governança fornece uma estrutura para o gerenciamento de dados para
engajar e alinhar com as prioridades de negócios e as partes interessadas.
Dentro de um modelo centralizado, o Data Governance Office pode se reportar à Organização de Gerenciamento de Dados ou
vice-versa. Quando um programa de gerenciamento de dados está focado no estabelecimento de políticas e diretrizes necessárias
para gerenciar dados como um ativo, o Data Governance Office pode atuar como líder, e a Data Management Organization
reporta (ou é matriz) ao Data Governance Office. Isso ocorre muitas vezes em ambientes altamente regulamentados, onde a
ênfase está na política e na responsabilidade.
Mesmo em um modelo muito descentralizado, deve haver uma estreita parceria entre o Data Governance Office, que cria as
diretrizes e políticas de como os dados devem ser gerenciados, e a Data Management Organization que os implementa. John
Ladley esclarece sucintamente essa relação: governança de dados é sobre
103 http://bit.ly/2sTf3Cy.
566 • DMBOK2
'Fazer as coisas certas' e gerenciamento de dados é sobre 'Fazer as coisas certas' (Ladley, 2012). Eles são dois lados da equação necessários
para produzir dados valiosos. Dessa forma, a governança de dados fornece as ordens de marcha para o gerenciamento de dados.
Mais importante, é preciso haver uma compreensão dessa sinergia e um acordo sobre funções, responsabilidades e responsabilidades que
apoiem as diretrizes de governança de dados e as eficiências do gerenciamento de dados.
Os participantes de um Grupo de Trabalho de Governança de Dados podem ser provenientes de uma Organização de Gerenciamento de
Dados, e uma Organização de Gerenciamento de Dados pode usar o mandato e a 'cobertura aérea' fornecida pela supervisão de governança.
6.3 Qualidade de Dados
O Data Quality Management é um recurso chave de uma prática e organização de gerenciamento de dados. Muitas organizações de
gerenciamento de dados começam com foco na qualidade dos dados porque há um desejo de medir e melhorar a qualidade dos dados em
toda a organização. É possível abordar a Qualidade de Dados dentro de uma linha de negócios, ou mesmo dentro de um aplicativo, sem ter
que envolver outros grupos ou gerenciar complexidades multifuncionais. No entanto, à medida que uma prática de qualidade de dados
amadurece, a organização se beneficiará de uma abordagem unificada para qualidade de dados; por exemplo, estabelecendo um Centro de
Excelência. A meta muda para melhorar a qualidade dos dados compartilhados entre as linhas de negócios ou aplicativos, geralmente com foco
no gerenciamento de dados mestres.
É comum que uma organização de gerenciamento de dados se desenvolva organicamente a partir de uma iniciativa de qualidade de dados,
pois o investimento na melhoria da qualidade dos dados agrega valor em toda a empresa e os esforços associados à melhoria da qualidade se
expandem para outras disciplinas, como Master, Reference e Metadata Management.
Um programa de qualidade de dados pode evoluir para modelos operacionais semelhantes a um programa abrangente de gerenciamento de
dados, embora seja raro que as funções de qualidade de dados se tornem completamente centralizadas em qualquer empresa de porte, porque
na maioria das vezes há aspectos de qualidade de dados que são executados em uma linha -de negócios ou nível de aplicativo. Como um
programa de qualidade de dados pode ser descentralizado, em rede ou híbrido (usando uma abordagem de centro de excelência), alinhe o
modelo operacional de qualidade de dados ao da organização geral de gerenciamento de dados, a fim de usar partes interessadas,
relacionamentos, responsabilidades, padrões consistentes , processos e

mesmo ferramentas.
6.4 Arquitetura Empresarial
Um grupo de Arquitetura Corporativa projeta e documenta os projetos principais de uma organização para articular e otimizar como atingir seus
objetivos estratégicos. As disciplinas dentro de uma prática de Arquitetura Corporativa

incluir:
• Arquitetura de Tecnologia
• Arquitetura de aplicativos
• Arquitetura de Informação (ou Dados)

• Arquitetura de Negócios
A Arquitetura de Dados é um recurso chave de uma Organização de Gerenciamento de Dados eficaz. Portanto, os Arquitetos de Dados podem
se sentar em qualquer grupo, com uma linha pontilhada para o outro grupo.
Quando os Arquitetos de Dados fazem parte de uma Organização de Gerenciamento de Dados, normalmente eles interagem com o restante
de seus pares de arquitetura por meio de Comitês de Revisão de Arquitetura (ARB), comitês que revisam e orientam sobre como os padrões
de arquitetura são implementados ou afetados por projetos e programas. Um ARB pode aprovar ou reprovar novos projetos e sistemas com
base em seu nível de aderência aos padrões de arquitetura.
Quando uma organização não tem Arquitetos de Dados, o Gerenciamento de Dados pode interagir com a organização de Arquitetura de
algumas maneiras:
• Por meio da governança de dados: uma vez que tanto o gerenciamento de dados quanto a arquitetura corporativa participam de um
O programa de Governança de Dados, o grupo de trabalho de governança e a estrutura do comitê podem fornecer uma
plataforma para alinhar metas, expectativas, padrões e atividades.
• Através do ARB: À medida que os projetos de gerenciamento de dados são levados ao ARB, o grupo de Arquitetura
forneceria orientação, feedback e aprovações.
• Ad-hoc: Se não houver comitês formais, o líder de gerenciamento de dados deve se reunir periodicamente
com o líder de arquitetura para garantir que haja conhecimento e compreensão compartilhados de projetos e
processos que afetam a outra parte. Com o tempo, a dificuldade de gerenciar esse processo ad hoc
provavelmente levará ao desenvolvimento de um papel formal ou comitê para facilitar discussões e decisões.
Se houvesse arquitetos de dados, eles representariam a arquitetura nas discussões de governança e liderariam
as discussões no ARB.
6.5 Gerenciando uma Organização Global
As empresas globais enfrentam desafios complexos de gerenciamento de dados com base no volume e variedade de leis e regulamentações
específicas de cada país, especialmente aquelas relacionadas à privacidade e segurança de certos tipos de dados. Adicione essas questões
aos desafios de gerenciamento típicos de uma organização global (força de trabalho distribuída, sistemas, fusos horários e idiomas), e a tarefa
de gerenciar dados de maneira eficiente e eficaz pode parecer um exercício interminável de pastoreio de gatos.
As organizações globais precisam prestar atenção especial a:
• Aderindo aos padrões
• Sincronizando processos
• Alinhamento de responsabilidade
• Treinamento e comunicação
• Monitoramento e medição eficaz
• Desenvolvimento de economias de escala
• Reduzindo a duplicação de esforços

568 • DMBOK2
À medida que os programas e organizações de gerenciamento de dados se tornam mais globais, os modelos em rede ou federados tornam-se mais
atraentes onde as responsabilidades podem ser alinhadas, os padrões podem ser seguidos e os
variações ainda podem ser acomodadas.
7. Funções de gerenciamento de dados
As funções de gerenciamento de dados podem ser definidas no nível funcional ou individual. Os nomes das funções serão diferentes entre as
organizações e algumas organizações terão maior ou menor necessidade de algumas das funções.
Todas as funções de TI podem ser mapeadas para pontos no ciclo de vida dos dados, para que todos tenham impacto no gerenciamento de dados,
seja diretamente (como um arquiteto de dados que projeta um data warehouse) ou indiretamente (como um desenvolvedor da Web que programa um
site). Da mesma forma, muitas funções de negócios criam, acessam ou manipulam dados. Algumas funções, como Analista de Qualidade de Dados,
exigem uma combinação de habilidades técnicas e conhecimento de negócios. As funções e papéis descritos abaixo concentram-se naqueles que são
direcionados engajados no gerenciamento de dados.
7.1 Funções Organizacionais
As organizações de gerenciamento de dados de TI fornecem uma variedade de serviços, desde dados, aplicativos e arquitetura técnica até
administração de banco de dados. Uma organização de serviços de gerenciamento de dados centralizada está focada exclusivamente no gerenciamento
de dados. Essa equipe pode incluir um Executivo de DM, outros Gerentes de DM, Arquitetos de Dados, Analistas de Dados, Analistas de Qualidade de
Dados, Administradores de Banco de Dados, Administradores de Segurança de Dados, Especialistas em Metadados, Modeladores de Dados,
Administradores de Dados, Arquitetos de Data Warehouse, Arquitetos de Integração de Dados e Analistas de Business Intelligence .
Uma abordagem federada de serviços de gerenciamento de dados incluirá um conjunto de unidades de TI, cada uma focada em uma faceta do
gerenciamento de dados. Especialmente em grandes organizações, as funções de TI geralmente são descentralizadas. Por exemplo, cada função de
negócios pode ter sua própria equipe de desenvolvedores de software. Uma abordagem híbrida também é adotada. Por exemplo, enquanto cada
função de negócios pode ter seus próprios desenvolvedores, a função DBA pode ser centralizada.
As funções de negócios focadas no gerenciamento de dados são mais frequentemente associadas às equipes de Governança de Dados ou
Gerenciamento de Informações Corporativas. Por exemplo, os Administradores de Dados geralmente fazem parte de uma Organização de Governança de Dados.
Tal organização facilitará os órgãos de Governança de Dados, como o Conselho de Governança de Dados.
7.2 Funções Individuais
As funções individuais podem ser definidas em negócios ou TI. Algumas são funções híbridas que exigem conhecimento de sistemas e processos de
negócios.
7.2.1 Funções Executivas
Os executivos de gerenciamento de dados podem estar no lado comercial ou tecnológico da casa. Chief Information Officer e Chief Technology
Officer são funções bem estabelecidas em TI. O conceito de Chief Data Officer no lado dos negócios ganhou muita credibilidade na última
década e muitas organizações contrataram CDOs.
7.2.2 Funções Empresariais
As funções de negócios se concentram principalmente nas funções de governança de dados, especialmente na administração. Os administradores de dados são geralmente
especialistas reconhecidos no assunto que são responsáveis por Metadados e qualidade de dados de entidades de negócios, áreas de
assunto ou bancos de dados. Stewards desempenham papéis diferentes, dependendo das prioridades organizacionais. O foco inicial da
administração geralmente é definir termos de negócios e valores válidos para suas áreas de assunto. Em muitas organizações, os Stewards
também definem e mantêm requisitos de qualidade de dados e regras de negócios para atributos de dados atribuídos, ajudam a identificar e
resolver problemas de dados e fornecem informações sobre padrões, políticas e procedimentos de dados.
Stewards podem funcionar na empresa, unidade de negócios ou nível funcional. Seu papel pode ser formal ('administrador de dados' faz parte
do título) ou informal (eles administram dados, mas têm outro cargo).
Além dos Data Stewards, os Business Process Analysts e os Process Architects contribuem para garantir que os modelos de processos de
negócios e os processos reais que criam dados sejam sólidos e suportem usos downstream.
Outros trabalhadores do conhecimento baseados em negócios, como analistas de negócios consumidores de dados e informações que
agregam valor aos dados para a organização, contribuem para o gerenciamento geral dos dados.
7.2.3 Funções de TI
As funções de TI incluem diferentes tipos de arquitetos, desenvolvedores em diferentes níveis, administradores de banco de dados e uma
variedade de funções de suporte.
• Arquiteto de Dados: Analista sênior responsável pela arquitetura de dados e integração de dados. Arquitetos de dados
pode funcionar no nível corporativo ou em um nível funcional. Arquitetos de dados podem se especializar em dados
armazenamento, data marts e seus processos de integração associados.
• Modelador de Dados: Responsável por capturar e modelar requisitos de dados, definições de dados, negócios
regras, requisitos de qualidade de dados e modelos de dados lógicos e físicos.
• Administrador de Modelo de Dados: Responsável pelo controle de versão do modelo de dados e controle de mudanças.
• Administrador de Banco de Dados: Responsável pelo design, implementação e suporte de dados estruturados
ativos e o desempenho da tecnologia que torna os dados acessíveis.
• Administrador de Segurança de Dados: Responsável por garantir o acesso controlado aos dados que requerem diferentes
níveis de proteção.
570 • DMBOK2
• Arquiteto de Integração de Dados: Um desenvolvedor sênior de integração de dados responsável por projetar tecnologia
para integrar e melhorar a qualidade dos ativos de dados corporativos.
• Especialista em Integração de Dados: Um designer de software ou desenvolvedor responsável pela implementação de sistemas
para integrar (replicar, extrair, transformar, carregar) ativos de dados em lote ou quase em tempo real.
• Analytics / Report Developer: Um desenvolvedor de software responsável pela criação de relatórios e análises
soluções de aplicação.
• Arquiteto de Aplicativos: Desenvolvedor sênior responsável pela integração de sistemas de aplicativos.
• Arquiteto Técnico: Engenheiro técnico sênior responsável por coordenar e integrar a TI
infraestrutura e o portfólio de tecnologia de TI.
• Engenheiro Técnico: Analista técnico sênior responsável por pesquisar, implementar, administrar e dar suporte a uma
parte da infraestrutura de tecnologia da informação.
• Administrador de Help Desk: Responsável por lidar, rastrear e resolver problemas relacionados ao uso de
informações, sistemas de informação ou a infraestrutura de TI.
• Auditor de TI: Um auditor interno ou externo de responsabilidades de TI, incluindo qualidade de dados e dados
segurança.
7.2.4 Papéis Híbridos
As funções híbridas exigem uma combinação de conhecimento técnico e de negócios. Dependendo da organização, as pessoas nessas funções
podem reportar por meio da TI ou do lado comercial.
• Analista de Qualidade de Dados: Responsável por determinar a adequação dos dados para uso e monitorar a condição contínua
dos dados; contribui para a análise da causa raiz de problemas de dados e ajuda a organização a identificar processos de
negócios e melhorias técnicas que contribuem para maior qualidade

dados.
• Especialista em Metadados: Responsável pela integração, controle e entrega de Metadados, incluindo administração de
repositórios de Metadados.
• Arquiteto de Business Intelligence: Analista sênior de Business Intelligence responsável pelo design do ambiente do usuário de Business
Intelligence.
• Analista/Administrador de Business Intelligence: Responsável por dar suporte ao uso efetivo de dados de Business Intelligence por
profissionais de negócios.
• Gerente de Programa de Business Intelligence: Coordena os requisitos e iniciativas de BI em toda a corporação e os integra em
um programa e roteiro coeso e priorizado.


Aiken, Peter e Juanita Billings. Monetizando o gerenciamento de dados: encontrando o valor no ativo mais importante da sua organização. Technics
Publications, LLC, 2013. Imprimir.
Aiken, Peter e Michael M. Gorman. O caso para o diretor de dados: reformulando o C-Suite para alavancar seu ativo mais valioso. Morgan
Anderson, Carlos. Criando uma organização orientada a dados. O'Reilly Media, 2015. Impresso.
Artur, Lisa. Marketing de Big Data: Envolva seus clientes de forma mais eficaz e gere valor. Wiley, 2013. Impresso.
Blokdijk, Geraldo. Análise das Partes Interessadas - Passos Simples para Vencer, Insights e Oportunidades para Maximizar o Sucesso. Publicação
completa, 2015. Imprimir.
Borek, Alexander et ai. Total Information Risk Management: Maximizando o Valor dos Dados e dos Ativos de Informação. Morgan Kaufmann, 2013.
Impresso.
Brestoff, Nelson E. e William H. Inmon. Prevenindo Litígios: Um Sistema de Alerta Precoce para Obter Grande Valor do Big Data. Imprensa
especializada em negócios, 2015. Imprimir.
Collier, Ken W. Agile Analytics: Uma Abordagem Orientada a Valor para Business Intelligence e Data Warehousing. Addison Wesley
Professional, 2011. Imprimir. Desenvolvimento Ágil de Software Ser.
Dean, Jared. Big Data, Mineração de Dados e Aprendizado de Máquina: Criação de Valor para Líderes e Profissionais de Negócios. Wiley, 2014.
Impresso. Wiley e SAS Business Ser.
Dietrich, Brenda L., Emily C. Plachy e Maureen F. Norton. Analytics em toda a empresa: como a IBM obtém valor comercial a partir de Big Data e
Analytics. IBM Press, 2014. Imprimir.
Freeman, R. Edward. Gestão Estratégica: Uma Abordagem das Partes Interessadas. Cambridge University Press, 2010. Impresso.
Gartner, Tom McCall, colaborador. “Compreendendo o papel do diretor de dados.” 18 de fevereiro de 2015. http://gtnr.it/1RIDKa6.
Gemignani, Zach, et ai. Fluência de dados: capacitando sua organização com comunicação de dados eficaz. Wiley, 2014.
Imprimir.
Gibbons, Paulo. A ciência da mudança organizacional bem-sucedida: como os líderes definem a estratégia, mudam o comportamento e criam uma
cultura ágil. Pearson FT Press, 2015. Imprimir.
Harrison, Michael I. Diagnosticando Organizações: Métodos, Modelos e Processos. 3ª edição. SAGE Publicações, Inc, 2004.
Imprimir. Métodos de Pesquisa Social Aplicada (Livro 8).
Harvard Business Review, John P. Kotter et al. 10 leituras obrigatórias da HBR sobre gerenciamento de mudanças. Harvard Business Review
Press, 2011. Imprimir. 10 leituras obrigatórias da HBR.
Hatch, Mary Jo e Ann L. Cunliffe. Teoria da organização: perspectivas modernas, simbólicas e pós-modernas. 3ª edição.
Oxford University Press, 2013. Impresso.
Hiatt, Jeffrey e Timothy Creasey. Gestão de Mudanças: O Lado das Pessoas da Mudança. Publicações do Centro de Aprendizagem Prosci, 2012.
Impresso.
Hillard, Roberto. Negócios orientados por informações: como gerenciar dados e informações para obter o máximo de vantagem. Wiley, 2010.
Impresso.
Hoverstadt, Patrick. A Organização Fractal: Criando organizações sustentáveis com o modelo de sistema viável. Wiley, 2009. Impresso.
Howson, Cindi. Business Intelligence de sucesso: desbloqueie o valor do BI e do Big Data. 2ª edição. Mcgraw-Hill Osborne Media, 2013.
Impresso.
572 • DMBOK2
Kates, Amy e Jay R. Galbraith. Projetando sua organização: usando o modelo STAR para resolver 5 desafios críticos de projeto. Jossey-Bass,
2007. Impresso.
Kesler, Gregory e Amy Kates. Fazendo a ponte entre o design e o desempenho da organização: cinco maneiras de ativar um modelo de
operação global. Jossey-Bass, 2015. Impresso.
Pequeno, Jasão. Lean Change Management: Práticas inovadoras para gerenciar a mudança organizacional. Happy Melly Express, 2014. Impressão.
Laboratório Nacional de Energias Renováveis. Livro de Recursos de Metodologias de Análise de Partes Interessadas. BiblioGov, 2012. Impresso.
Prokscha, Susanne. Guia Prático de Gerenciamento de Dados Clínicos. 2ª edição. CRC Press, 2006. Imprimir.
Schmarzo, Bill. MBA Big Data: Conduzindo Estratégias de Negócios com Ciência de Dados. Wiley, 2015. Impresso.
Soares, Sunil. O Manual do Diretor de Dados para Governança de Dados. Mc Press, 2015. Imprimir.
Stubbs, Evan. O valor da análise de negócios: identificando o caminho para a lucratividade. Wiley, 2011. Impresso.
Tompkins, Jonathan R. Teoria da Organização e Gestão Pública. Editora Wadsworth, 2004. Impresso.
Tsoukas, Haridimos e Christian Knudsen, eds. The Oxford Handbook of Organization Theory: Perspectivas Metateóricas. Oxford University
Press, 2005. Impresso. Manuais Oxford.
Verhoef, Peter C., Edwin Kooge e Natasha Walk. Criando valor com Big Data Analytics: tomando decisões de marketing mais inteligentes. Routledge,
2016. Imprimir.
Willows, David e Brian Bedrick, eds. Gerenciamento de dados eficaz para escolas. John Catt Educational Ltd, 2012. Imprimir.
Escolas Internacionais Eficazes Ser.
CAPÍTULO 1 7
Gerenciamento de Dados e Organizacional

Mudar a gestão
1. Introdução
F
ou na maioria das organizações, melhorar as práticas de gerenciamento de dados requer mudar a forma como as pessoas trabalham
juntos e como eles entendem o papel dos dados em suas organizações, bem como a maneira como eles usam os dados
e implantar tecnologia para apoiar os processos organizacionais. Práticas de gerenciamento de dados bem-sucedidas
requerem, entre outros fatores:
• Aprender a gerenciar horizontalmente, alinhando responsabilidades ao longo da cadeia de valor da informação
• Mudando o foco da responsabilidade vertical (silo) para a administração compartilhada de informações
• Evoluir a qualidade da informação de uma preocupação de negócios de nicho ou o trabalho do departamento de TI para um núcleo
valor da organização
• Mudar o pensamento sobre a qualidade da informação de 'limpeza de dados e scorecards' para um
capacidade organizacional fundamental
• Implementação de processos para medir o custo do mau gerenciamento de dados e o valor dos dados disciplinados
gestão
Esse nível de mudança não é alcançado por meio da tecnologia, embora o uso apropriado de ferramentas de software possa dar suporte à
entrega. Em vez disso, é alcançado através de uma abordagem cuidadosa e estruturada para a gestão da mudança
na organização. A mudança será necessária em todos os níveis. É fundamental gerenciar e coordenar a mudança para evitar iniciativas sem
saída, perda de confiança e danos à credibilidade da função de gerenciamento de informações e de sua liderança.
Os profissionais de gerenciamento de dados que entendem o gerenciamento formal de mudanças terão mais sucesso em trazer mudanças
que ajudarão suas organizações a obter mais valor de seus dados. Para isso, é importante entender:
• Por que a mudança falha
• Os gatilhos para uma mudança efetiva
• As barreiras à mudança
• Como as pessoas experimentam a mudança
573
574 • DMBOK2
2. Leis de Mudança
Especialistas em gerenciamento de mudanças organizacionais reconhecem um conjunto de 'Leis de Mudança' fundamentais que descrevem
por que a mudança não é fácil. Reconhecê-los no início do processo de mudança permite o sucesso.
• As organizações não mudam, as pessoas mudam: A mudança não acontece porque uma nova organização é anunciada ou um
novo sistema é implementado. Ocorre quando as pessoas se comportam de maneira diferente porque reconhecem o valor de
fazê-lo. O processo de melhorar as práticas de gerenciamento de dados e implementar a governança formal de dados terá
efeitos de longo alcance em uma organização. As pessoas serão solicitadas a mudar a forma como trabalham com dados e
como interagem umas com as outras em atividades envolvendo

dados.
• As pessoas não resistem à mudança. Eles resistem à mudança: os indivíduos não adotarão a mudança se a virem como
arbitrária ou ditatorial. Eles são mais propensos a mudar se estiverem envolvidos na definição da mudança e se entenderem a
visão que impulsiona a mudança, bem como quando e como a mudança ocorrerá. Parte do gerenciamento de mudanças para
iniciativas de dados envolve trabalhar com equipes para construir uma compreensão organizacional do valor das melhores
práticas de gerenciamento de dados.
• As coisas são do jeito que são porque ficaram assim: pode haver boas razões históricas para
as coisas sendo do jeito que são. Em algum momento no passado, alguém definiu os requisitos de negócios, definiu o
processo, projetou os sistemas, escreveu a política ou definiu o modelo de negócios que agora requer mudanças.
Compreender as origens das práticas atuais de gerenciamento de dados ajudará a organização a evitar erros do passado. Se
os membros da equipe tiverem voz na mudança, é mais provável que entendam novas iniciativas como melhorias.
• A menos que haja pressão para mudar, as coisas provavelmente permanecerão as mesmas: Se você deseja uma melhoria,
algo deve ser feito de forma diferente. Como Einstein disse: “Você não pode resolver um problema com o nível de pensamento
que o criou em primeiro lugar”.
• A mudança seria fácil se não fosse por todas as pessoas: A 'tecnologia' da mudança geralmente é fácil. o
desafio vem em lidar com a variação natural que surge nas pessoas.
A mudança requer Agentes de Mudança, pessoas que prestam atenção às pessoas e não apenas aos sistemas. Os Agentes de Mudanças
ouvem ativamente os funcionários, clientes e outras partes interessadas para detectar problemas antes que eles surjam e executar a
mudança com mais facilidade.
Em última análise, a mudança requer uma VISÃO clara dos Objetivos de Mudança, comunicados de forma vívida e regular às partes
interessadas para obter engajamento, adesão, apoio e (importante) apoio contínuo quando surgirem desafios.
GESTÃO DE DADOS E GESTÃO DE MUDANÇA ORGANIZACIONAL • 575
3. Não Gerenciando uma Mudança: Gerenciando uma Transição
O especialista em gerenciamento de mudanças William Bridges enfatiza a centralidade da transição no processo de gerenciamento
de mudanças. Ele define transição como o processo psicológico pelo qual as pessoas passam para chegar a um acordo com a nova
situação. Enquanto muitas pessoas pensam na mudança apenas em termos de um novo começo, Bridges afirma que a mudança
envolve passar por três fases distintas, começando com o fim do estado existente. Os finais são difíceis porque as pessoas precisam
abandonar as condições existentes. As pessoas então entram na Zona Neutra, na qual o estado existente ainda não terminou e o
novo estado ainda não começou. A mudança é concluída quando o novo estado é estabelecido (consulte a Tabela 34). Dessas três,
a Zona Neutra é a menos previsível e a mais confusa, pois é uma mistura do antigo e do novo. Se as pessoas na organização não
transitarem pela Zona Neutra, então a organização corre o risco de voltar aos velhos hábitos e não conseguir sustentar a mudança.
Bridges sustenta que a maior razão pela qual as mudanças organizacionais falham é que as pessoas que conduzem a mudança
raramente pensam em finais e, portanto, não gerenciam o impacto dos finais nas pessoas. Ele afirma: “A maioria das organizações
tenta começar com um começo, em vez de terminar com ele. Eles não prestam atenção aos finais. Eles não reconhecem a existência
da zona neutra e então se perguntam por que as pessoas têm tanta dificuldade com a mudança” (Bridges, 2009).
Ao experimentar uma mudança, todos os indivíduos passam por todas as três fases, mas em velocidades diferentes. A progressão
depende de fatores como experiência passada, estilo pessoal preferido, grau de envolvimento em reconhecer o problema e
desenvolver possíveis soluções, e até que ponto eles se sentem empurrados para uma mudança em vez de avançar voluntariamente.
Tabela 34 Fases de Transição das Pontes
Fase de Transição Descrição

O fim • Quando reconhecemos que há coisas que precisamos deixar de lado.
• Quando reconhecemos que perdemos algo.
• Exemplo: Mudar de emprego - mesmo quando um indivíduo opta por mudar de emprego,
ainda há perdas, como perder amigos de trabalho próximos.
A Zona Neutra
• Quando o antigo caminho terminou, mas o novo ainda não chegou.
• Quando tudo está em fluxo e parece que ninguém sabe o que deveria ser
fazendo.
• Quando as coisas estão confusas e desordenadas.

• Exemplo: Mudança de casa. Os primeiros dias ou mesmo meses após
mudança, a nova casa ainda não está em casa e as coisas estão provavelmente em
tumulto.
O novo começo • Quando a nova maneira parece confortável, certa e a única maneira.
• Exemplo: Ter um bebê. Depois de alguns meses na zona neutra de turbulência,
você chega a um estágio em que não consegue imaginar a vida sem seu novo bebê.
Bridges enfatiza que enquanto a primeira tarefa do Change Manager é entender o Destino (ou
VISÃO) e como chegar lá, o objetivo final do gerenciamento de transição é convencer as pessoas de que elas precisam
576 • DMBOK2
para iniciar a viagem. Ao gerenciar mudanças e transições, o papel do Agente de Mudanças, e de qualquer gerente ou líder no
processo, é ajudar as pessoas a reconhecerem que o processo e as etapas de uma transição são perfeitamente
natural.
O novo começo
Alteração de incorporação
Valores de recongelamento
A Zona Neutra
Final
Perder
Deixando ir
Descongelando o
O status quo
Tempo
Figura 113 Fases de Transição das Pontes
A lista de verificação a seguir para gerenciar a transição resume os pontos-chave que os gerentes devem estar cientes, pois ajudam
na transição das pessoas.
• O fim
o Ajude todos a entender os problemas atuais e por que a mudança é necessária. o Identifique quem
provavelmente perderá o quê. Lembre-se que a perda de amigos e o trabalho próximo
colegas é tão importante para alguns quanto a perda de status e poder é para outros. o As
perdas são subjetivas. As coisas pelas quais uma pessoa sofre podem não significar nada para outra. Aceite a
importância das perdas subjetivas. Não discuta com os outros sobre como eles percebem a perda e não
se surpreenda com as reações de outras pessoas à perda. o Espere e aceite os sinais de luto e reconheça
as perdas de forma aberta e solidária. o Definir o que acabou e o que não é. As pessoas devem fazer a pausa
em algum momento e tentar
apegar-se aos velhos hábitos prolonga as dificuldades.
o Trate o passado com respeito. As pessoas provavelmente trabalharam arduamente em condições que podem
ter sido muito difíceis. Reconheça isso e mostre que o trabalho é valorizado.
o Mostrar como terminar algo garante que as coisas que importam para as pessoas continuem e
melhorou.
o Dê informações às pessoas. Então faça isso de novo e de novo e de novo de várias maneiras – escrito
informações para ir embora e ler, bem como a oportunidade de conversar e fazer perguntas.
o Use a análise das partes interessadas para mapear a melhor forma de abordar diferentes indivíduos –
entender como suas perspectivas podem precisar ser engajadas para iniciar a mudança e quais podem ser os
prováveis pontos de resistência.
• A Zona Neutra
o Reconheça isso como uma fase difícil (mistura de velho e novo), mas que todos devem passar por isso. o Envolver as
pessoas e trabalhar em conjunto; dê-lhes tempo e espaço para experimentar e testar

Novas ideias.
o Ajude as pessoas a sentirem que ainda são valorizadas. o
Elogie as pessoas com boas ideias, mesmo que nem todas as boas ideias funcionem como esperado. O plano, fazer,
O modelo Study, Act (PDSA) incentiva a experimentar as coisas e aprender com cada ciclo.
o Dar informações às pessoas; fazê-lo de novo e de novo e de novo de várias maneiras. o Fornecer
feedback sobre os resultados das ideias que estão sendo testadas e as decisões tomadas.
• O novo começo
o Não force um começo antes do tempo. o Assegure-se
de que as pessoas saibam qual é o seu papel no novo sistema. o Certifique-se de que
as políticas, procedimentos e prioridades sejam claros; não envie mensagens confusas. o Planeje celebrar o novo
começo e dê o crédito àqueles que fizeram a mudança. o Dar informações às pessoas; fazê-lo de novo e de novo de
várias maneiras.
4. Os Oito Erros de Gerenciamento de Mudanças de Kotter
Em Leading Change, John P. Kotter, um dos pesquisadores mais respeitados na área de Gerenciamento de Mudanças, descreve oito razões
pelas quais as organizações não executam mudanças. Eles fornecem uma perspectiva sobre questões que geralmente surgem no contexto de
gerenciamento de informações e dados.
4.1 Erro nº 1: Permitindo muita complacência
De acordo com Kotter, o maior erro que as pessoas cometem ao tentar mudar as organizações é avançar sem primeiro estabelecer um senso
de urgência suficientemente alto entre seus pares e superiores. (Isso está relacionado à necessidade de aumentar a insatisfação com o status
quo identificado na fórmula de Gleicher; consulte a Seção 6.) A análise de Kotter fornece indicadores valiosos para os Gerentes de Mudança
que procuram evitar os erros dos outros. Agentes de mudança

muitas vezes:
• Superestimar sua capacidade de forçar grandes mudanças na organização • Subestimar
o quão difícil pode ser tirar as pessoas de suas zonas de conforto • Não ver como suas ações e
abordagens podem reforçar o status quo ao aumentar a defensividade

578 • DMBOK2
• Apresse-se onde os anjos temem pisar - iniciando atividades de mudança sem comunicação suficiente de
que mudança é necessária ou por que a mudança é necessária (a Visão)
• Confundir urgência com ansiedade, que por sua vez leva ao medo e resistência à medida que as partes interessadas recuam (muitas vezes
literalmente) em seus silos
Embora seja tentador pensar que, diante de uma crise organizacional, a complacência não seria um problema, muitas vezes acontece o oposto.
As partes interessadas geralmente se apegam ao status quo diante de muitas demandas (muitas vezes conflitantes) de mudança (que geralmente
são processadas como 'se tudo é importante, então nada é importante').
4.1.1 Exemplos no Contexto da Gestão da Informação
A Tabela 35 descreve exemplos de como a complacência pode se manifestar em um contexto de gerenciamento de informações:
Tabela 35 Cenários de Complacência
Cenário de exemplo Como isso pode se manifestar

Resposta a uma mudança regulatória “Estamos bem. Não fomos multados de acordo com as regras atuais.”
Resposta à Mudança nos Negócios “Há anos que apoiamos os negócios com sucesso. Nós ficaremos bem.”
Resposta à mudança tecnológica “Essa nova tecnologia não foi comprovada. Nossos sistemas atuais são estáveis e sabemos como contornar os
problemas.”
Resposta a problemas ou erros “Podemos designar uma equipe de solução de problemas para isso e corrigir os problemas.
Deve haver algumas pessoas disponíveis em [Insira o nome do Departamento ou Equipe aqui].”
4.2 Erro nº 2: Falha ao criar uma coalizão de orientação suficientemente poderosa
Kotter identifica que uma grande mudança é quase impossível sem o apoio ativo do chefe da organização e sem uma coalizão de outros líderes se
unindo para orientar a mudança. O envolvimento da liderança é especialmente importante nos esforços de governança de dados, pois eles exigem
mudanças comportamentais significativas.
Sem o compromisso dos principais líderes, o interesse próprio de curto prazo superará o argumento dos benefícios de longo prazo de uma melhor
governança.
Uma Coalizão Orientadora é uma equipe poderosa e entusiasmada de voluntários de toda a organização que ajuda a colocar novas estratégias
em prática e transformar a organização. Um desafio fundamental no desenvolvimento de uma Coalizão Orientadora é identificar quem precisa estar
envolvido. (Consulte a Seção 5.2.)
4.3 Erro nº 3: subestimando o poder da visão
A urgência e uma equipe de orientação forte são inúteis sem uma visão clara e sensata da mudança. A visão fornece o contexto do esforço de
mudança. Ajuda as pessoas a entender o significado de qualquer componente individual.
Uma visão bem definida e comunicada pode ajudar a impulsionar o nível de energia necessário para implementar adequadamente o
mudança. Sem uma declaração pública de visão para orientar a tomada de decisões, cada escolha corre o risco de se tornar um
debate e qualquer ação pode inviabilizar a iniciativa de mudança ou prejudicá-la.
Visão não é a mesma coisa que planejamento ou gerenciamento de programas. A visão não é o plano do projeto ou o termo de
abertura do projeto ou uma análise detalhada de todos os componentes da mudança.
Uma visão é uma declaração clara e convincente de onde a mudança está levando.
Comunicar a visão significa conectar-se com as pessoas. Para iniciativas de gerenciamento de dados, a visão deve articular os
desafios com as práticas de gerenciamento de dados existentes, os benefícios da melhoria e o caminho para chegar a um estado
futuro melhor.
4.3.1 Exemplo em Gestão da Informação
Com muita frequência, na gestão da informação, a visão de um projeto específico é apresentada como a implementação de uma
nova tecnologia. A tecnologia, embora importante, não é a mudança e nem a visão. O que a organização pode fazer com a tecnologia
constitui a visão.
Por exemplo, declarar: “Iremos implementar um novo conjunto integrado de relatórios e análises financeiras baseado em [insira o
nome da tecnologia aqui] até o final do primeiro trimestre” é uma meta louvável e mensurável. No entanto, faz pouco para comunicar
uma declaração clara e convincente de onde a mudança levará.
Por outro lado, afirmando: “Vamos melhorar a precisão e pontualidade dos relatórios financeiros e torná-los mais acessíveis a todos
os stakeholders. A compreensão aprimorada de como os dados entram e saem de nossos processos de relatórios apoiará a confiança
em nossos números, economizará tempo e reduzirá o estresse desnecessário durante os processos de final de período. Daremos
nosso primeiro passo para conseguir isso implementando o [System X] até o final do primeiro trimestre” esclarece o que será feito e
por que está sendo feito. Se você puder apontar os benefícios da mudança para a organização, você construirá apoio para a mudança.
4.4 Erro nº 4: sob comunicação da visão por um fator de 10, 100 ou 1000
Mesmo que todos concordem que a situação atual é insatisfatória, as pessoas ainda não mudarão a menos que percebam os
benefícios da mudança como uma melhoria significativa em relação ao status quo.
A comunicação consistente e eficaz da visão, seguida de ação, é fundamental para o sucesso do gerenciamento de mudanças.
Kotter aconselha que a comunicação vem em palavras e ações. A congruência entre os dois é fundamental para o sucesso. Nada
mata um esforço de mudança tão rápido quanto uma situação em que as pessoas recebem a mensagem: 'Faça o que eu digo, não
o que eu faço'.
580 • DMBOK2
4.5 Erro nº 5: Permitindo que os obstáculos bloqueiem a visão
Novas iniciativas falham quando as pessoas se sentem impotentes por enormes obstáculos em seu caminho, mesmo quando abraçam
totalmente a necessidade e a direção da mudança proposta. Como parte de sua transformação, a organização deve identificar e responder
a diferentes tipos de obstáculos:
• Psicológico: Os obstáculos que existem na cabeça das pessoas devem ser abordados com base em suas causas. Fazer
eles decorrem do medo, falta de conhecimento ou alguma outra causa?
• Estruturais: Obstáculos devido a estruturas organizacionais, como categorias de trabalho restritas ou desempenho
sistemas de avaliação que forçam as pessoas a escolher entre a Visão e seu próprio interesse devem ser
abordados como parte do processo de gerenciamento de mudanças. O gerenciamento de mudanças deve abordar estruturas
incentivos e desincentivos à mudança.
• Resistência ativa: Que obstáculos existem devido a pessoas que se recusam a se adaptar ao novo conjunto de
circunstâncias e que fazem exigências que são inconsistentes com a Transformação? Se os membros-chave
da organização fazem os ruídos certos sobre a visão de mudança, mas não conseguem alterar seus comportamentos ou
recompensar os comportamentos exigidos ou continuar a operar de forma incompatível, a execução da visão

vai vacilar e pode falhar.
Kotter convoca “pessoas inteligentes” nas organizações para enfrentar esses obstáculos. Se não o fizerem, outros se sentirão impotentes e
a mudança será prejudicada.
4.6 Erro nº 6: Falha ao criar vitórias de curto prazo
A verdadeira mudança leva tempo. Qualquer pessoa que já embarcou em um regime de condicionamento físico ou um plano de perda de
peso sabe que o segredo para continuar é ter metas regulares de marcos que mantenham o impulso e a motivação marcando o progresso.
Qualquer coisa que envolva um compromisso de longo prazo e investimento de esforço e recursos requer algum elemento de feedback
inicial e regular do sucesso.
Esforços de mudança complexos exigem metas de curto prazo em apoio a objetivos de longo prazo. Atingir esses objetivos permite que a
equipe celebre e mantenha o ímpeto. O principal é criar a vitória a curto prazo, em vez de apenas esperar por ela. Em transformações bem-
sucedidas, os gerentes estabelecem ativamente metas iniciais, atingem essas metas e recompensam a equipe. Sem esforços sistemáticos
para garantir o sucesso, a mudança provavelmente falhará.
Em um contexto de gerenciamento de informações, as vitórias e metas de curto prazo geralmente surgem da resolução de um problema
identificado. Por exemplo, se o desenvolvimento de um Glossário de Negócios for um produto-chave de uma iniciativa de governança de
dados, uma vitória de curto prazo pode vir da solução de um problema relacionado à compreensão inconsistente dos dados (ou seja, duas
áreas de negócios relatam resultados de KPI diferentes porque usaram regras diferentes em seus cálculos).
Identificar o problema, resolvê-lo e vincular a solução à visão geral de longo prazo para a mudança permite que a equipe celebre essa meta e demonstre
a visão em ação. Ele também fornece valiosos colaterais para a comunicação sobre a visão e ajuda a reforçar a mensagem de mudança.
4.7 Erro nº 7: Declarando vitória cedo demais
Com muita frequência, em projetos de Mudança, especialmente aqueles que se estendem por vários anos, há a tentação de declarar sucesso na primeira
grande melhoria de desempenho. Vitórias rápidas e vitórias iniciais são ferramentas poderosas para manter o ritmo e o moral. No entanto, qualquer
sugestão de que o trabalho está feito geralmente é um erro. Até que as mudanças sejam incorporadas à cultura da organização, novas abordagens são
frágeis e velhos hábitos e práticas podem se reafirmar. Kotter sugere que mudar uma empresa inteira pode levar entre três e dez anos.
4.7.1 Exemplo no Contexto da Gestão da Informação
O exemplo clássico da síndrome de 'Missão Cumprida' é o cenário em que a implementação de uma tecnologia é vista como o caminho para melhorar a
gestão da informação ou resolver um problema com a qualidade ou confiabilidade dos dados. Uma vez que a tecnologia tenha sido implantada, pode ser
difícil manter o projeto em direção ao objetivo, principalmente se a visão geral tiver sido mal definida. A Tabela 36 captura vários exemplos relacionados às
consequências de declarar vitória cedo demais.
Tabela 36 Cenários de declaração de vitória cedo demais
Cenário de exemplo Como isso pode se manifestar

Abordando a qualidade dos dados “Compramos uma ferramenta de qualidade de dados. Isso está corrigido agora.”
• Ninguém na organização está revisando ou agindo na qualidade dos dados
relatórios
Confundir entrega de capacidade com “Implementamos a pilha de relatórios para o Regulamento X. Agora estamos em conformidade
implementação e operação com a legislação.”
• Mudanças nos requisitos regulamentares
• Ninguém está revisando ou agindo em questões identificadas no relatório

Migração de dados “Todos os dados no Sistema X estão agora no Sistema Y.”
• As contagens de registros correspondem, mas os dados no Sistema Y estão incompletos ou
truncado devido a falhas no processo de migração. Manual

intervenções necessárias
4.8 Erro nº 8: Negligenciar Ancorar Mudanças Firmemente na Cultura Corporativa
As organizações não mudam, as pessoas mudam. Até que novos comportamentos sejam incorporados às normas sociais e valores compartilhados de
uma organização, eles estarão sujeitos à decadência e degradação assim que o foco do esforço de mudança for removido. Kotter é claro: você ignora a
cultura por sua conta e risco ao se envolver em qualquer atividade de mudança.

582 • DMBOK2
As duas chaves para ancorar a mudança na cultura da organização são:
• Mostrar conscientemente às pessoas como comportamentos e atitudes específicos influenciaram o desempenho.
• Dedicar tempo suficiente para incorporar a mudança de abordagem na próxima geração de gestão.
Esse risco destaca a importância dos fatores humanos na mudança geral que pode ser implementada para trazer melhorias na execução da
governança de dados, gerenciamento e uso de metadados ou práticas de qualidade de dados (para citar apenas três).
Por exemplo, uma organização pode ter introduzido um requisito de marcação de metadados em toda a documentação para dar suporte a
processos automatizados de classificação e arquivamento em seu sistema de gerenciamento de conteúdo. Os funcionários começam a
cumprir nas primeiras semanas, mas com o passar do tempo, eles voltam aos velhos hábitos e não marcam corretamente os documentos,
levando a um acúmulo maciço de registros não classificados que precisam ser revisados manualmente para alinhá-los aos requisitos do
solução de tecnologia.
Isso destaca o simples fato de que as melhorias no Gerenciamento da Informação são entregues por meio de uma combinação de processos,
pessoas e tecnologia. Muitas vezes, esse componente intermediário é perdido, levando a uma entrega abaixo do ideal e retrocedendo no
progresso feito. É importante, ao introduzir novas tecnologias ou novos processos, considerar como as pessoas levarão a mudança adiante
e sustentarão os ganhos.
5. Processo de Oito Estágios de Kotter para Grandes Mudanças
Além dos Oito Erros do Gerenciamento de Mudanças, Kotter reconhece um conjunto de obstáculos comuns à mudança:
• Culturas voltadas para dentro
• Burocracia paralisante
• Política paroquial
• Baixos níveis de confiança
• Falta de trabalho em equipe
• Arrogância
• Falta ou falha de liderança

• Medo do desconhecido
Para combatê-los, ele propõe um modelo de oito etapas para grandes mudanças. O modelo de Kotter fornece uma estrutura dentro da qual
cada uma dessas questões pode ser abordada de forma a apoiar mudanças sustentáveis de longo prazo. Cada passo está associado a um
dos erros fundamentais que minam os esforços de transformação.
As primeiras quatro etapas do modelo suavizam posições de status quo arraigadas. Como diz Kotter, esse esforço só é necessário porque a
mudança não é fácil.

Os próximos três passos (5 a 7) introduzem novas práticas e formas de trabalhar. A última etapa bloqueia as mudanças no lugar
e fornece a plataforma para ganhos e melhorias futuras.
Kotter informa que não há atalhos para seguir essas etapas. Todos os esforços de mudança bem-sucedidos devem passar por
todas as oito etapas. Concentrar-se nos passos 5, 6 e 7 é tentador. No entanto, isso não fornece uma base sólida para sustentar
a mudança (sem visão, sem Coalizão Orientadora, sem insatisfação com o status quo). Da mesma forma, é importante reforçar
cada etapa à medida que você avança no processo, usando ganhos rápidos para reforçar a visão e a comunicação e destacar
os problemas com o status quo.
1-Estabelecer um senso de 5-Empoderamento de base ampla

Urgência Ação
2-Criação da Coalizão Orientadora 6-Criando Vitórias de Curto Prazo
3-Desenvolvendo uma Visão e uma 7-Consolidação de Ganhos e

Estratégia Produzindo mais mudanças
4-Comunicando a Mudança 8-Ancoragem de Novas Abordagens na

Visão Cultura
Figura 114 Processo de Oito Estágios de Kotter para Grandes Mudanças
5.1 Estabelecendo um senso de urgência
As pessoas encontrarão mil maneiras de impedir a cooperação de algo que acham desnecessário. Um senso de urgência claro
e convincente é necessário para motivar uma massa crítica suficiente de pessoas para apoiar um esforço de mudança. Ganhar
a cooperação e a colaboração requer uma convocação.
O oposto de urgência é complacência. Quando a complacência é alta, é difícil, se não impossível, reunir um grupo suficientemente
poderoso para criar a visão de mudança e orientar o esforço de mudança. Em casos raros, os indivíduos podem fazer algum
progresso em face da complacência, mas isso é quase inevitavelmente insustentável.
No contexto da gestão da informação, vários fatores podem criar um senso de urgência:
• Mudanças regulatórias
• Ameaças à segurança das informações
• Riscos para a continuidade dos negócios
• Mudanças na estratégia de negócios

• Fusões e aquisições
• Auditoria regulatória ou ameaças de litígio
• Mudanças na tecnologia
• Mudanças na capacidade dos concorrentes no mercado
• Comentários da mídia sobre questões de gerenciamento de informações de uma organização ou indústria
584 • DMBOK2
5.1.1 Fontes de Complacência
Kotter identifica nove razões pelas quais organizações e pessoas podem ser complacentes. (Veja a Figura 115)
• Na ausência de uma crise visível, é difícil criar um senso de urgência. • As armadilhas do sucesso
podem abafar a urgência de algumas situações. • Medir a equipe em relação aos padrões de baixo
desempenho ou padrões que não se comparam aos externos
benchmarks ou tendências internas de longo prazo.
• Objetivos funcionais excessivamente estreitos, com diferentes métricas de desempenho para diferentes unidades funcionais, podem
levar a uma situação em que ninguém é responsável quando o desempenho organizacional geral é ruim ou sofre.
• Se os sistemas internos de planejamento e controle são (ou podem ser) manipulados ou manipulados para facilitar para todos
para alcançar seus objetivos, é fácil ser complacente.
• Se a única fonte de feedback de desempenho for dos sistemas internos defeituosos, não há verificação de sanidade
da justeza da complacência.
• Onde os problemas são identificados ou onde o feedback externo sobre o desempenho é coletado, ele é frequentemente atacado como
prejudicial ao moral, prejudicial aos outros ou suscetível de causar uma discussão. Em vez de tomar a informação como uma
entrada para uma avaliação do desempenho da organização, a cultura é 'matar o mensageiro'.
• Por razões psicológicas muito simples, as pessoas não aceitam coisas que não querem ouvir. Quando
a evidência de um grande problema aparece, as pessoas muitas vezes ignoram a informação ou a reinterpretam de uma forma
menos dolorosa.
• Mesmo em organizações onde os primeiros oito desafios não são significativos, existe o risco de que 'feliz
conversa" da alta administração ou de figuras de alto escalão da organização pode criar uma sensação injustificada de segurança
e sucesso. Muitas vezes essa 'conversa feliz' é o resultado de uma história de sucessos passados. O sucesso passado pode dar
às pessoas um ego e criar uma cultura arrogante. Ambos os fatores podem manter o senso de urgência baixo e dificultar a mudança.
Uma boa regra em qualquer iniciativa de mudança é nunca subestimar o poder das forças que podem reforçar a complacência e promover o
status quo. O desafio da complacência deve ser enfrentado. Uma organização não pode tomar decisões importantes sem abordar os problemas
reais.
5.1.2 Aumentando o Nível de Urgência
Aumentar o nível de urgência requer a remoção das fontes de complacência ou a redução de seu impacto.
Criar um forte senso de urgência exige que os líderes tomem ações ousadas ou mesmo arriscadas. Vale lembrar como Deming aconselhou a
administração a instituir a liderança como parte de seus 14 Pontos de Transformação.104
104 Em Out of the Crisis (1982), W. Edwards Deming publicou seus 14 Points for Management Transformation.
http://bit.ly/1KJ3JIS.
Ausência de uma crise

importante e visível
Muitos
visíveis
Capacidade humana de negação
Recursos
de problemas,
especialmente quando ocupado
ou estressado
Baixos
Muito ''Feliz
padrões de
Conversa'' (Grupo de Pensamento) desempenho geral
interno
''Matando o
medição
Mensageiro''
-Baixa Sinceridade/Baixa focando no desempenho
Confronto errado
medidas
Culturas
Falta de Organizacional
Estruturas que
feedback de
desempenho de focam os funcionários
em objetivos funcionais
fontes externas
estreitos
Complacência
Figura 115 Fontes de Complacência
Negrito significa fazer algo que pode causar dor a curto prazo, não apenas algo que fica bem em um email de marketing. Em
outras palavras, requer a adoção da nova filosofia (tomar emprestado novamente de Deming).
Movimentos ousados o suficiente para reduzir a complacência tendem a causar conflitos e ansiedade de curto prazo. No entanto,
se o conflito e a ansiedade puderem ser canalizados para a visão de mudança, o líder poderá capitalizar o desconforto de curto
prazo para construir os objetivos de longo prazo.
Movimentos ousados são difíceis na ausência de uma liderança apoiada e solidária. Gerentes seniores cautelosos, incapazes de
aumentar o senso de urgência, reduzirão a capacidade de mudança de uma organização.
5.1.3 Usando a Crise com Cuidado
Uma maneira de aumentar os níveis de urgência é se agarrar a uma crise visível. Às vezes é dito que grandes mudanças não são
possíveis até que a própria sobrevivência econômica da organização esteja em risco. No entanto, não é necessariamente que o
586 • DMBOK2
a mudança vem mesmo assim. Uma crise econômica ou financeira em uma organização muitas vezes pode resultar em recursos escassos,
mas necessários, sendo difíceis de encontrar para apoiar a visão de mudança.
É possível criar uma crise percebida bombardeando a organização com informações sobre problemas, problemas potenciais, oportunidades
potenciais ou estabelecendo metas ambiciosas que romperam o status quo. Kotter sugere que muitas vezes é mais fácil criar um problema
que (coincidentemente) você tem o plano de resolver.
5.1.4 O Papel dos Gerentes de Nível Médio e Inferior
Dependendo da escala da meta para a mudança (por exemplo, um departamento ou unidade de negócios versus uma organização inteira),
os principais participantes serão os gerentes responsáveis por essa unidade. Eles precisarão ser capazes de reduzir a complacência nas
equipes sob seu controle direto. Se tiverem autonomia suficiente, poderão fazer isso independentemente do ritmo de mudança no resto da
organização.
Se não houver autonomia suficiente, então um esforço de mudança em uma pequena unidade pode ser condenado desde o início, à medida
que as forças externas de inércia entram em ação. Muitas vezes, os executivos seniores precisam reduzir essas forças. No entanto, meio ou
os gerentes de nível inferior podem conduzir esse tipo de mudança se agirem de maneira estratégica. Por exemplo, se eles usarem a análise
para mostrar claramente o impacto de não fazer a mudança necessária em um projeto estratégico importante. Isso é particularmente eficaz
quando o debate pode ser difundido direcionando-o para um grupo externo, como uma consultoria externa, que pode ter ajudado na análise.
5.1.5 Quanta urgência é suficiente?
Um senso de urgência sobre um problema leva as pessoas a concluir que o status quo é inaceitável. Para sustentar a transformação a longo
prazo, é necessário o apoio de uma massa crítica de gestores. Kotter sugere 75%.
No entanto, criar muita urgência pode ser contraproducente. Demasiada urgência pode resultar em visões concorrentes de mudança ou
causar um foco no 'combate a incêndios'.
Um senso de urgência suficientemente convincente ajudará a iniciar o processo de mudança e dar-lhe impulso.
Urgência suficiente também ajudará a obter o nível certo de liderança na Coalizão Orientadora. Em última análise, o senso de urgência
precisa ser forte o suficiente para evitar que a complacência se reafirme depois que os sucessos iniciais forem alcançados. Uma abordagem
chave é explorar a 'voz do cliente' e falar com clientes externos, fornecedores, acionistas ou outras partes interessadas sobre sua perspectiva
sobre o nível de urgência que está sendo

criada.
5.2 A Coalizão Orientadora
Nenhuma pessoa tem todas as respostas ou todos os insights necessários para criar uma visão, ou tem a variedade e a variação certas de
conexões para apoiar a comunicação eficaz de uma visão. Para uma mudança bem-sucedida, dois
cenários devem ser evitados:
• O CEO Solitário / Campeão Solitário
• O Comitê de Baixa Credibilidade
O cenário do CEO Solitário coloca o sucesso ou fracasso do esforço de mudança nas mãos de uma pessoa. O ritmo de mudança na maioria
das organizações nos dias de hoje é tal que uma pessoa não pode gerenciar tudo. O ritmo de tomada de decisão e comunicação diminui, a
menos que as decisões sejam tomadas sem uma avaliação completa do
questões. Qualquer uma das opções é uma receita para o fracasso.
O Comitê de Baixa Credibilidade surge quando um campeão capaz recebe uma 'força-tarefa' com representantes de vários departamentos
funcionais (e talvez alguns consultores externos). O que falta à força-tarefa é representação suficiente (se houver) de pessoas em um nível
sênior na hierarquia executiva. Se for visto como “importante, mas não tão importante” (mais uma vez, por causa da falta de comprometimento
dos altos escalões), as pessoas não se sentem motivadas a ter uma verdadeira compreensão da situação. Inevitavelmente, a força-tarefa falha.
É essencial criar uma Coalizão Orientadora adequada que tenha o compromisso de gestão necessário para apoiar a urgência da necessidade
de mudança. Além disso, a equipe precisa apoiar a tomada de decisão eficaz – o que exige altos níveis de confiança dentro da equipe. Uma
Coalizão Orientadora que trabalha em equipe pode processar mais informações mais rapidamente. Também acelera a implementação de ideias
porque os tomadores de decisão com poder são verdadeiramente informados e comprometidos com as principais decisões.
Uma Coalizão de Orientação eficaz tem quatro características principais:
• Poder de Posição: Há jogadores-chave suficientes a bordo, especialmente gerentes de linha principais, para que aqueles que
são deixados de fora não podem bloquear facilmente o progresso?
• Expertise: Os pontos de vista relevantes são adequadamente representados para que informações informadas e inteligentes
decisões serão tomadas?
• Credibilidade: São suficientes pessoas com boa reputação na organização na equipe para que seja
levado a serio?
• Liderança: A equipe tem líderes comprovados suficientes para conduzir o processo de mudança?
A liderança é uma preocupação fundamental. Deve haver um bom equilíbrio entre as habilidades de gerenciamento e liderança na Coalizão
Orientadora. A gerência mantém todo o processo sob controle. A liderança impulsiona a mudança. Um
sem o outro não se alcançará um resultado sustentável.
As principais questões que surgem no contexto da construção de sua Coalizão Orientadora incluem:
De quantas pessoas preciso para me ajudar a definir e orientar essa mudança?
A resposta para isso é um “depende” dolorosamente do tipo consultor, mas o tamanho da coalizão está relacionado ao tamanho do grupo geral
que está sendo influenciado. Um equilíbrio precisa ser alcançado entre ter um grupo que é muito grande e ter um grupo que deixa os principais
interessados se sentindo deixados 'fora da tenda'.
Quem deve ser envolvido ou convidado a se juntar à Coalizão de Orientação?
A Coalizão Orientadora difere de um projeto formal ou comitê de direção de programa, pois precisa fornecer uma plataforma de influência em
toda a organização. Como tal, a coalizão precisa incluir representantes de

588 • DMBOK2
diferentes comunidades interessadas. No entanto, também não é um fórum geral de coleta de requisitos das partes interessadas.
Busque perspectivas de pessoas que possam ser impactadas na cadeia de valor da informação da organização.
Um atributo-chave dos membros da Coalizão Orientadora é sua capacidade de influenciar seus pares, seja por meio de autoridade
formal na hierarquia ou por meio de seu status e experiência na organização.
O comportamento é fundamental na Coalizão Orientadora.
Na formulação da Coalizão Orientadora, os líderes de mudança precisam evitar comportamentos que enfraqueçam a eficácia, a função
e o alcance da equipe. Por exemplo, evite:
• Opositores: Opositores podem dificultar o diálogo positivo e aberto necessário para que a Coalizão Orientadora
desenvolver ideias criativas, refinar, implementar e evoluir a visão de mudança e identificar oportunidades
para o crescimento.
• Distração: os membros da equipe da Coalizão Orientadora precisam estar focados na atividade de mudança. Desfocado
os indivíduos podem tirar a equipe do curso, levando a atrasos ou ao fracasso em capitalizar as vitórias iniciais.
• Egoísmo: Os esforços da Coalizão Orientadora movem a organização como um todo e afetam a todos.
Não se deve permitir que agendas ocultas atrapalhem os esforços da equipe.
5.2.1 A Importância da Liderança Eficaz na Coalizão
Há uma diferença entre gestão e liderança. Uma Coalizão Orientadora com bons gerentes, mas sem líderes, não terá sucesso. A falta
de liderança pode ser resolvida contratando de fora, promovendo líderes internos e incentivando a equipe a enfrentar o desafio de
liderar.
Ao montar sua coalizão, você precisa ter cuidado com o que Kotter chama de 'egos', 'cobras' e 'jogadores relutantes'. 'Egos' são
indivíduos que enchem a sala e não permitem que outros contribuam. 'Cobras' são pessoas que criam e espalham desconfiança e
desconfiança. 'Jogadores relutantes' são (geralmente) figuras seniores que veem uma necessidade moderada da mudança, mas não
entendem totalmente a urgência.
Qualquer um desses tipos de personalidade pode sequestrar ou minar o esforço de mudança. Esforços devem ser feitos para mantê-
los fora da equipe ou gerenciá-los de perto para mantê-los na mensagem.
No contexto de uma iniciativa de mudança de gerenciamento de informações, a Coalizão Orientadora pode ajudar a organização a
identificar oportunidades para vincular iniciativas em diferentes áreas que estão engajadas em diferentes aspectos da mesma mudança
geral.
Por exemplo, em resposta a uma exigência regulatória, o conselho interno de uma empresa pode ter começado a desenvolver um
mapa de fluxos de dados e processos na organização. Ao mesmo tempo, uma iniciativa de armazenamento de dados pode ter
começado a mapear a linhagem de dados para verificação da precisão e qualidade dos relatórios.
Um líder de mudança de governança de dados pode reunir o chefe jurídico e o chefe de relatórios em sua Coalizão de Orientação para melhorar a
documentação e o controle dos processos de informações no contexto da governança de dados. Isso, por sua vez, pode exigir informações das
equipes de linha de frente usando e criando dados para entender os impactos de quaisquer alterações propostas.
Em última análise, uma boa compreensão da cadeia de valor da informação ajudará a identificar potenciais candidatos a serem incluídos na Coalizão
Orientadora.
5.2.3 Construindo uma Equipe Eficaz
Uma equipe eficaz é baseada em duas bases simples: confiança e um objetivo comum. A falta de confiança é muitas vezes causada pela falta de
comunicação e outros fatores, como rivalidade equivocada. A clássica divisão 'Negócios vs. TI' é um bom exemplo de onde a confiança falha. Para
construir confiança, envolva-se em atividades de construção de equipe que criem e promovam compreensão, respeito e carinho mútuos. Ao alcançar
esse entendimento mútuo, porém, deve-se tomar cuidado para evitar o “pensamento de grupo”.
5.2.4 Pensamento em Grupo de Combate
'Group Think' é um efeito psicológico que surge em grupos altamente coerentes e coesos, particularmente aqueles que estão isolados de fontes de
informação que podem contradizer suas opiniões, ou aqueles que são dominados por um líder que encoraja as pessoas a concordarem com sua
posição em vez de abrir a discussão.
No Group Think, todos concordam com uma proposta, mesmo quando têm reservas quanto a isso. O Group Think provavelmente está operando se:
• Ninguém levanta objeções

• Nenhuma alternativa é oferecida
• Diferentes perspectivas são rapidamente descartadas e morrem para sempre
• As informações que podem desafiar o pensamento não são ativamente procuradas
Para prevenir o Pensamento de Grupo é importante:
• Incentive todos os participantes a seguir o método científico de coleta de dados para ajudar a entender o
natureza e causas de um problema
• Desenvolva uma lista de critérios para avaliar todas as decisões
• Aprenda a trabalhar em conjunto com eficiência para que o Pensamento em Grupo não seja o atalho para fazer as coisas mais rapidamente
• Incentive o brainstorming
• Os líderes devem falar por último
• Procure ativamente conhecimento externo e entrada em reuniões
• Assim que uma solução for identificada, faça com que a equipe desenvolva não apenas um plano, mas também um 'Plano B' (que
força-os a repensar suposições no plano original)

590 • DMBOK2
O Pensamento de Grupo pode surgir em vários contextos. Uma área potencial é a tradicional 'divisão de negócios versus TI', na qual diferentes
partes da organização são resistentes às mudanças propostas pelo outro. Outro cenário potencial é onde o objetivo da organização é se
tornar orientado a dados com foco em análises e coleta de dados, o que pode resultar em privacidade, segurança ou questões éticas em
relação ao tratamento de informações sendo descontado ou priorizado no plano de trabalho geral.
Há muitas razões para aplicar a disciplina de governança de dados nas organizações. Uma função-chave é garantir clareza sobre os modelos
e métodos a serem aplicados. Essa clareza permitirá que questões como a divisão de negócios/TI ou o equilíbrio de prioridades concorrentes
sejam abordadas de forma adequada e consistente.
5.2.6 Objetivos Comuns
Se cada membro da Coalizão Orientadora estiver puxando em uma direção diferente, a confiança será quebrada.
Os objetivos típicos que unem as pessoas são o compromisso com a excelência ou o desejo de ver a organização atuar no mais alto nível
possível em uma determinada área. Esses objetivos não devem ser confundidos com a visão de mudança, mas devem ser complementares
a ela.
5.3 Desenvolvendo uma Visão e Estratégia
Um erro comum nos esforços de gerenciamento de mudanças é confiar no decreto autoritário ou no microgerenciamento
para movimentar a mudança. Nenhuma das abordagens é eficaz se a situação de mudança for complexa.
Se o objetivo é a mudança de comportamento, a menos que o chefe seja muito poderoso, as abordagens autoritárias do decreto funcionam
mal, mesmo em situações simples. Sem "o poder dos reis" por trás disso, é improvável que um decreto autoritário rompa todas as forças de
resistência. Os Agentes de Mudança tendem a ser ignorados, minados ou contornados.
Quase inevitavelmente, algum resistente à mudança vai chamar o blefe do Agente de Mudança para testar a autoridade e influência por trás
do processo de mudança.
O microgerenciamento tenta contornar essa fraqueza definindo em detalhes específicos o que os funcionários devem fazer e, em seguida,
monitorando a conformidade. Isso pode superar algumas das barreiras à mudança, mas, com o tempo, levará cada vez mais tempo, já que a
gerência precisa gastar mais tempo detalhando as práticas e métodos de trabalho para os novos comportamentos alterados à medida que o
nível de complexidade associado à mudança aumenta.
A única abordagem que permite consistentemente aos Agentes de Mudança romper o status quo é basear a mudança em uma visão clara e
convincente que forneça impulso.

Autoritário
Decreto Visão de microgerenciamento
Forças que sustentam o status quo
Figura 116 A visão rompe com o status quo
5.3.1 Por que a Visão é Essencial
Uma visão é uma imagem do futuro com algum comentário implícito ou explícito sobre por que as pessoas devem se esforçar
para criar esse futuro. Uma boa visão compartilha três propósitos importantes: Esclarecimento, motivação e alinhamento.
• Esclarecimento: Uma boa visão esclarece a direção da mudança e simplifica uma série de decisões mais detalhadas,
definindo parâmetros-chave. Uma visão eficaz (e suporte a estratégias de backup) ajuda a resolver problemas que
surgem de divergências sobre direção ou confusão sobre a motivação ou os impulsionadores da mudança. Debates
intermináveis podem ser evitados com uma simples pergunta: a ação planejada está alinhada com a visão? Da mesma
forma, a visão pode ajudar a limpar a desordem, permitindo que a equipe concentre os esforços em projetos prioritários
que estão contribuindo para o esforço de transformação.
• Motivação: Uma visão clara motiva as pessoas a dar passos na direção certa, mesmo que os passos iniciais sejam
pessoalmente dolorosos. Isso é particularmente verdadeiro em organizações onde as pessoas estão sendo forçadas
a sair de suas zonas de conforto regularmente. Quando o futuro é deprimente e desmoralizante, a visão correta pode
dar às pessoas uma causa atraente pela qual lutar.
• Alinhamento: Uma visão convincente ajuda a alinhar os indivíduos e coordenar as ações de

pessoas de forma eficiente. A alternativa é ter uma enxurrada de diretrizes detalhadas ou reuniões intermináveis.
A experiência mostra que, sem um senso compartilhado de direção, pessoas interdependentes podem acabar em
ciclos de conflito constante e reuniões ininterruptas.
592 • DMBOK2
5.3.2 A Natureza de uma Visão Eficaz
Uma visão pode ser mundana e simples. Não precisa ser grandioso ou abrangente. É um elemento do sistema de ferramentas e
processos de mudança; esse sistema também inclui estratégias, planos, orçamentos e muito mais. No entanto, uma visão é um fator
muito importante porque exige que as equipes se concentrem em melhorias tangíveis.
Uma visão eficaz tem várias características principais:
• Imaginável: transmite uma imagem de como será o futuro.
• Desejável: Atrai os interesses de longo prazo de funcionários, clientes, acionistas e outros

• Viável: Compreende metas realistas e alcançáveis.
• Focado: É claro o suficiente para fornecer orientação na tomada de decisões.
• Flexível: é geral o suficiente para permitir que os indivíduos tomem a iniciativa e para permitir alternativas
planos e respostas quando as condições ou restrições mudam.
• Comunicável: É fácil compartilhar e comunicar em cinco minutos ou menos.
O teste chave para a eficácia de uma visão é quão fácil é imaginá-la e ser desejável. Uma boa visão pode exigir sacrifícios, mas deve
manter no escopo os interesses de longo prazo das pessoas envolvidas. Visões que não se concentram a longo prazo nos benefícios
para as pessoas acabam sendo desafiadas. Da mesma forma, a visão deve estar enraizada na realidade do mercado de produtos ou
serviços. Na maioria dos mercados, a realidade é que o cliente final precisa ser considerado constantemente.
As principais perguntas a serem feitas são:
• Se isso se tornasse real, como afetaria os clientes (internos e externos)?
• Se isso se tornasse real, como afetaria os acionistas? Isso os deixará mais felizes? Será que vai entregar
valor de longo prazo para eles?
• Se isso se tornasse real, como afetaria os funcionários? O local de trabalho seria melhor, mais feliz, menos
estressado, mais gratificante? Seremos capazes de nos tornar um lugar melhor para trabalhar?
Outro teste importante é a viabilidade estratégica da visão. Uma visão viável é mais do que um desejo. Pode aumentar os recursos e as
capacidades, mas as pessoas reconhecem que isso pode ser alcançado. Viável não significa fácil, no entanto. A visão deve ser
desafiadora o suficiente para forçar um repensar fundamental. Independentemente de quais metas de expansão são definidas, a
organização deve fundamentar essa visão em uma compreensão racional das tendências do mercado e da capacidade da organização.
A visão deve ser focada o suficiente para orientar as pessoas, mas não tão rígida a ponto de algemar os funcionários a modos de
comportamento cada vez mais irracionais. Muitas vezes, a melhor abordagem é visar a simplicidade da visão e, ao mesmo tempo,
incorporar ganchos específicos suficientes para que a visão ainda seja uma pedra angular valiosa e um ponto de referência para a
tomada de decisões:
É nosso objetivo nos tornarmos líderes mundiais em nossa indústria dentro de 5 anos. Nesse contexto, liderança significa gerenciar
informações de forma mais eficaz para gerar maiores receitas, mais lucros e um local mais gratificante para o nosso pessoal trabalhar.
Alcançar essa ambição exigirá uma base sólida de confiança em nossa capacidade de fazer
decisões, clareza em nossas comunicações internas e externas, uma melhor compreensão do cenário de informações em que operamos
e investimentos racionais em ferramentas e tecnologias apropriadas para apoiar uma cultura e um ethos orientados por dados. Essa
cultura será confiável e admirada por acionistas, clientes, funcionários,

e comunidades.
5.3.3 Criando a Visão Eficaz

Kotter aconselha que criar uma visão eficaz é um processo iterativo que deve ter vários elementos claros para serem
bem sucedido.
• Primeiro rascunho: Um único indivíduo faz uma declaração inicial refletindo seus sonhos e as necessidades do
Mercado.
• Papel da Coalizão Orientadora: A Coalizão Orientadora retrabalha o primeiro rascunho para se adequar à estratégia mais ampla
perspectiva.
• Importância do trabalho em equipe: O processo de grupo nunca funciona bem sem trabalho em equipe. Encorajar as pessoas
para participar e contribuir.
• Papel da cabeça e do coração: tanto o pensamento analítico quanto o 'sonho de céu azul' são necessários ao longo
a atividade.
• Bagunça do processo: Este não será um procedimento simples; haverá muito debate,
refazer e mudar. Se não houver, algo está errado com a visão ou a equipe.
• Prazo: A atividade não é um acordo de uma reunião. Pode levar semanas, meses ou até mais. Idealmente,
a visão deve estar em constante evolução.
• Produto final: Uma direção para o futuro que é desejável, viável, focada, flexível e pode ser
transmitida em cinco minutos ou menos.
Visão
Uma imagem sensata e
atraente do futuro
Estratégias
Uma lógica de como a visão
pode ser conseguida
Planos
Etapas e cronogramas específicos
para implementar estratégias
Orçamentos
Planos convertidos em financeiros
projeções e metas
Figura 117 Contraste de Gestão/Liderança

594 • DMBOK2
5.4 Comunicando a Visão da Mudança
Uma visão só tem poder quando os envolvidos na atividade de mudança têm um entendimento comum de seus objetivos e direção, uma
visão comum sobre o futuro desejado. Problemas que comumente surgem com a comunicação do
visão incluem:
• Falha na comunicação, ou comunicação suficiente.
• Má comunicação: Redação pesada ou pesada que esconde o senso de urgência; como resultado,
as pessoas não ouvem com atenção.
• Não se comunicar o suficiente: os gerentes são treinados para se comunicar de cima a baixo. Os líderes precisam
comunicar para fora e em círculos mais amplos. Essa gama de comunicação exige que os líderes
ter uma noção clara do problema e como ele pode ser resolvido.
Outro desafio é lidar com as questões que dizem respeito à visão, dos stakeholders, da Coalizão Orientadora e da própria equipe que
está implementando a mudança. Muitas vezes, a Coalizão de Orientação gasta muito tempo elaborando essas perguntas e preparando
respostas para elas apenas para despejá-las na organização em um clique rápido (uma página de perguntas frequentes, notas para um
briefing). A sobrecarga de informações resultante obscurece a visão, cria pânico e resistência de curto prazo.
Dado que, na organização média, a mensagem de mudança será responsável por não muito mais do que meio por cento do total de
comunicação que vai para um funcionário, é claro que simplesmente descartar informações não será eficaz. A mensagem precisa ser
comunicada de uma forma que aumente sua eficácia e amplifique

a comunicação.
Kotter identifica sete elementos-chave na comunicação eficaz da visão:
• Mantenha a simplicidade: retire o jargão, o vocabulário interno e as frases complexas.
• Use metáfora, analogia e exemplo: uma imagem verbal (ou mesmo gráfica) pode valer uma
mil palavras.
• Use vários fóruns: a mensagem precisa ser comunicável em vários fóruns diferentes
do discurso do elevador ao memorando de transmissão, de uma pequena reunião a um briefing geral.
• Repetir, repetir, repetir: as ideias devem ser ouvidas muitas vezes antes de serem internalizadas e
Entendido.
• Liderar pelo exemplo: O comportamento de pessoas importantes precisa ser consistente com a visão. Inconsistente
comportamento supera todas as outras formas de comunicação.
• Explique as aparentes inconsistências: pontas soltas e desconexões não resolvidas prejudicam a credibilidade
de toda comunicação.
• Dar e receber: A comunicação bidirecional é sempre mais poderosa do que a comunicação unidirecional.
Em um contexto de gerenciamento de informações, a falha em definir ou comunicar uma visão clara e convincente para uma mudança
pode muitas vezes ser vista em iniciativas em que uma nova tecnologia ou capacidade está sendo lançada impulsionada por um
foco na implantação de tecnologia. Na ausência de uma compreensão ou apreciação dos benefícios potenciais de manipulação de
informações da nova tecnologia ou métodos, pode haver resistência por parte dos stakeholders em adotar novas formas de trabalho.
Por exemplo, se uma organização estiver implementando processos de gerenciamento de conteúdo e documentos orientados por
metadados, as partes interessadas do negócio podem não se envolver com o esforço inicial de entender ou aplicar a marcação de
metadados ou a classificação de registros se não houver uma visão claramente comunicada de como isso será um benefício para a
organização e para eles. Sem isso, a iniciativa de outra forma valiosa pode ficar atolada com níveis de adoção e conformidade inferiores
aos necessários.
5.4.2 Mantendo Simples
É difícil se conectar emocionalmente com uma linguagem que não é natural, densamente escrita ou difícil de entender.
Esses exemplos ilustram os problemas de comunicação que podem surgir quando a visão não é mantida simples. O exemplo abaixo
ilustra este ponto.
Nosso objetivo é reduzir nosso parâmetro médio de 'tempo de reparo' para que seja comprovadamente menor do que todos os principais
concorrentes em nossos mercados geográficos e demográficos-alvo. Na mesma linha, temos como alvo os tempos de ciclo de
desenvolvimento de novos produtos, tempos de processamento de pedidos e outros vetores de processo relacionados ao cliente para
mudança.
Tradução: “Vamos nos tornar mais rápidos do que qualquer um em nosso setor em atender às necessidades dos clientes.”
Quando a visão é articulada de forma simples, é mais fácil para as equipes, stakeholders e clientes entenderem a mudança proposta,
como ela pode afetá-los e seu papel nela. Isso, por sua vez, os ajuda a comunicá-lo mais facilmente aos seus pares.
5.4.3 Use muitos fóruns diferentes
A comunicação da visão costuma ser mais eficaz quando são utilizados diferentes canais. Existem várias razões para isso, desde o fato
de que alguns canais podem estar sobrecarregados com informações ou com 'bagagem' de iniciativas de mudança anteriores, até o fato
de que pessoas diferentes interpretam e processam as informações de forma diferente. Se as pessoas estão sendo atingidas com a
mesma mensagem por meio de canais diferentes, aumenta a probabilidade de que a mensagem seja ouvida, internalizada e posta em
prática. Relacionada a essa abordagem 'multicanal/multiformato' está a necessidade de continuar repetindo a visão e comunicando o
progresso.
5.4.4 Repetição, Repetição, Repetição
Em muitos aspectos, a visão de mudança e as mensagens de mudança são como a água em um rio que encontra uma pedra que deve
ser superada. A água não rompe a barragem imediatamente (a menos que tenha muita força por trás,
596 • DMBOK2
nesse caso, tende a fazê-lo de forma destrutiva), mas com o tempo, através da erosão iterativa, a água desgasta o
pedra para que ela possa fluir em torno dela.
Da mesma forma, as iniciativas de mudança precisam aplicar recontagens iterativas da visão de mudança em diferentes fóruns e formatos para
gerar uma mudança que seja 'pegajosa'. Qual desses cenários seria mais eficaz?
• A gerência sênior enviou uma mensagem de vídeo para todos os funcionários e um anúncio de queda de correio de voz para informar
todos na mudança. Os detalhes sobre a execução seguirão os gerentes de linha. A intranet carrega
três artigos nos próximos seis meses sobre a Visão, e há uma sessão de briefing na reunião trimestral
conferência de gestão (entregue no final do dia). O plano inclui seis instâncias de
comunicação sem detalhamento.
• A alta administração se compromete a encontrar quatro oportunidades por dia para ter uma conversa de mudança e amarrá-la
de volta ao 'Big Picture'. Eles, por sua vez, encarregam seus subordinados diretos de encontrar quatro chances e com
encarregando seus subordinados diretos de encontrar quatro chances. Então, quando Frank está reunido com Desenvolvimento de Produto, ele
pede que eles revisem seus planos no contexto da Grande Visão. Quando Maria está apresentando um status
atualização, ela o vincula à contribuição para a Visão. Quando Garry está apresentando resultados internos negativos
constatações da auditoria, ele explica o impacto em termos da Visão. Em cada nível de gestão, por
gerente existem inúmeras oportunidades de comunicação por ano onde a visão pode ser
referenciado. (Isso também é conhecido como “Adotar a Nova Filosofia” e “Instituir Liderança”,
que são pontos-chave nos 14 Pontos para Transformação na Gestão da Qualidade de W. Edwards Deming.)
5.4.5 Andando na conversa
Não há substituto para a liderança pelo exemplo. Torna os valores e os aspectos culturais da mudança desejada tangíveis de uma forma que
nenhuma quantidade de palavras pode fazer. Se, por nenhuma outra razão, os gerentes seniores falarem engendrarem o desenvolvimento de
histórias sobre a visão e desencadearem discussões sobre a visão, essa é uma ferramenta excepcionalmente poderosa. O corolário é que dizer
uma coisa às pessoas e fazer o oposto envia uma mensagem clara de que a visão não é tão importante e pode ser ignorada quando o empurrão
chega. Nada prejudica mais a visão e os esforços de mudança do que um membro sênior da Coalizão Orientadora agindo de forma incongruente
com a
visão.
No contexto de gerenciamento de informações, a falha em 'Walk the Talk' pode ser tão simples quanto um gerente sênior enviar arquivos
contendo informações pessoais sobre clientes por um canal de e-mail não seguro ou não criptografado em violação da política de segurança da
informação, mas não recebendo nenhuma sanção.
Também pode ser tão simples quanto a equipe liderando uma iniciativa de governança da informação aplicando os princípios e o rigor que eles
estão pedindo ao resto da organização para adotar em suas próprias atividades, manuseio de informações, relatórios e respostas a problemas e
erros.
Considere o impacto na implementação de um projeto de gerenciamento de Metadados se a equipe aplicasse padrões e práticas
de Metadados aos seus próprios registros internos do projeto. Se nada mais, isso os ajudaria a entender os aspectos práticos da
mudança, mas também os forneceria uma boa demonstração para outros dos benefícios de registros e informações devidamente
rotulados e classificados.
5.4.7 Explicando Inconsistências
Às vezes, a inconsistência é inevitável. Pode ser que, por razões táticas ou operacionais, ou simplesmente para fazer as coisas
se moverem dentro do sistema geral da organização, um Agente de Mudança possa precisar tomar uma ação que observe a
divergência com a visão declarada. Quando isso acontece, deve ser manuseado e tratado com cuidado para garantir que a visão
seja sustentada, mesmo que uma 'rota cênica' esteja sendo tomada. Exemplos de inconsistências que podem surgir podem
incluir o uso de consultores externos quando a organização está buscando reduzir custos ou quadro de funcionários. “Por que a
organização está trazendo esses ternos caros quando estamos racionando papel de impressora?” as pessoas podem perguntar.
Há duas maneiras de lidar com a aparente inconsistência. Um deles é garantido para matar sua visão. O outro lhe dá uma
chance de lutar para manter as coisas nos trilhos.
A primeira opção é ignorar a pergunta ou reagir defensivamente e atirar no mensageiro. Invariavelmente, isso acaba em uma
descida embaraçosa onde a inconsistência é removida, e nem sempre de uma maneira que seja benéfica para os objetivos de
longo prazo da mudança. A segunda opção é se envolver com a questão e explicar a razão da inconsistência. A explicação deve
ser simples, clara e honesta. Por exemplo, uma organização que traz consultores pode responder assim:
Entendemos que parece estranho gastar dinheiro com consultores quando estamos cortando custos em qualquer outro lugar
para alcançar nossa visão de ser enxuto, mesquinho e lucrativo de forma sustentável. No entanto, para tornar as economias
sustentáveis, precisamos romper com velhos hábitos de pensamento e aprender novas habilidades. Isso exige que invistamos
em conhecimento. E onde não temos esse conhecimento internamente, devemos comprá-lo no curto prazo e usar essa
oportunidade para construir o conhecimento internamente para o futuro. Cada consultor é designado para um projeto específico.
E cada equipe de projeto foi incumbida de aprender o máximo possível sobre sua nova função, acompanhando os consultores e
usando-os para treinamento formal. Dessa forma, garantiremos que teremos melhorias sustentáveis no futuro.
A chave é ser explícito sobre a inconsistência e explícito sobre por que a inconsistência é válida e por quanto tempo ela existirá
se for apenas uma inconsistência transitória.
Explicar as inconsistências é um bom exemplo da importância dos modelos de governança de dados que criam protocolos
acordados para a tomada de decisões e promovem o reconhecimento formal e o controle de exceções a
as regras.
598 • DMBOK2
Por exemplo, se um padrão de governança exigir que nenhum teste seja feito com dados de produção ao vivo, mas um projeto exigir
isso para verificar algoritmos de correspondência de dados ou para provar a eficácia das rotinas de limpeza de dados, deve haver
uma explicação clara e explícita dessa variação do padrão esperado. Isso é alcançado por meio de controles de governança
apropriados. Onde esse projeto executa testes usando dados ao vivo sem ter as aprovações apropriadas e avaliações de risco em
vigor, então deve haver uma sanção (“walk the talk”) ou a base para a não aplicação da sanção deve ser explicada de forma
igualmente clara e explícita.
5.4.9 Ouvir e ser ouvido
Stephen Covey aconselha as pessoas que querem ser altamente eficazes a “Procurar primeiro entender, depois ser entendido”. Em
outras palavras, ouça para que você seja ouvido (Covey, 2013).
Frequentemente, a equipe de liderança não entende bem a visão ou encontra uma barreira ou gargalo que poderia ter sido evitado
se estivesse mais bem informado. Essa falta de informação leva a erros caros e enfraquece a adesão e o compromisso com a Visão.
As conversas bidirecionais são um método essencial para identificar e responder às preocupações que as pessoas têm sobre uma
mudança ou sobre uma visão de mudança. A Voz do Cliente é tão importante para a definição e desenvolvimento da visão quanto
para qualquer métrica de qualidade nos próprios dados. E se cada conversa for vista como uma oportunidade para discutir a visão e
dar feedbacks ilícitos então, sem ter que amarrar formalmente as pessoas em reuniões, é possível ter milhares de horas de discussão
e evoluir a visão e como executá-la de forma eficaz .
5.4.10 Exemplo no Contexto de Gestão da Informação
Em um contexto de gerenciamento de informações, a comunicação bidirecional é melhor ilustrada por um cenário em que a visão da
função de TI é que todos os dados necessários às principais partes interessadas do negócio estão disponíveis de maneira oportuna
e apropriada, mas as partes interessadas estão constantemente expressando frustração com atrasos em obter
informações de que necessitam para realizar seus trabalhos e, portanto, desenvolveram uma indústria artesanal em relatórios
baseados em planilhas e data marts.
Uma visão para melhorar o gerenciamento de informações e a capacidade de governança que não identifica e aborda a lacuna na
percepção entre a visão da função de TI do ambiente de informações e a percepção das partes interessadas do negócio sobre seu
ambiente de informações inevitavelmente vacilará e deixará de obter uma visão ampla. suporte baseado necessário para garantir que
uma mudança efetiva e sustentável seja entregue.
6. A Fórmula da Mudança
Um dos métodos mais famosos para descrever a 'receita' necessária para uma mudança efetiva, a Fórmula Gleicher, descreve os
fatores que precisam estar em vigor para superar a resistência à mudança na organização.
=(××)>
De acordo com a Fórmula de Gleicher, a Mudança (C) ocorre quando o nível de insatisfação com o status quo (D) é combinado com uma
visão de uma alternativa melhor (V) e alguns primeiros passos acionáveis para chegar lá (F) e o produto de o três é atraente o suficiente
para superar a resistência (R) na organização.
Influenciar qualquer uma das quatro variáveis na fórmula de Gleicher aumenta a eficácia e o sucesso do esforço de mudança. No entanto,
como em qualquer máquina complexa, é importante estar ciente dos riscos inerentes ao apertar botões e puxar alavancas:
• O aumento da insatisfação dentro da organização com a forma como as coisas estão funcionando é uma ferramenta poderosa
e precisa ser manuseado com cuidado para não aumentar a Resistência.
• Desenvolver uma visão do futuro exigirá uma visão concreta e vívida do que as pessoas farão
diferentemente, o que as pessoas vão parar de fazer, ou o que vão começar a fazer que não estão fazendo agora.
Certifique-se de que as pessoas possam apreciar as novas habilidades, atitudes ou métodos de trabalho que serão necessários.
Apresente-os de uma forma que não afaste as pessoas ou crie barreiras políticas à mudança,
levando as pessoas a defender o status quo.
• Ao descrever os primeiros passos para a mudança, certifique-se de que eles sejam alcançáveis e vincule-os explicitamente a
a visão.
• Aja para reduzir a resistência e evitar aumentar a resistência à mudança. Para ser franco: evite alienar
pessoas. Isso requer uma boa compreensão das partes interessadas.
7. Difusão de Inovações e Mudança Sustentada

Em última análise, o treinamento e a educação devem ser implementados para fornecer uma qualidade de informação sustentável e uma
mudança no gerenciamento de dados em uma organização. A implementação da mudança requer a compreensão de como as novas
ideias se espalham pela organização. Esse aspecto da mudança é conhecido como Difusão de Inovações.
Difusão de Inovações é uma teoria que busca explicar como, por que e em que velocidade novas ideias e tecnologias se espalham pelas
culturas. Formulado em 1962 por Everett Rogers, está relacionado ao conceito da cultura pop do Idea Virus (http://bit.ly/2tNwUHD)
popularizado por Seth Godin. A Difusão de Inovações tem sido aplicada de forma consistente em uma ampla gama de campos, desde
prescrição médica até mudanças nos métodos de criação de fazendas, até a adoção de eletrônicos de consumo.
A teoria da Difusão de Inovações afirma que as mudanças são iniciadas por uma porcentagem muito pequena (2,5%) da população total,
os Inovadores, que tendem (no contexto da sociedade examinada) a ser jovens, de alta classe social e financeiramente seguro o
suficiente para absorver perdas em más escolhas. Eles têm contato com inovadores tecnológicos e uma alta tolerância ao risco. Estes
são seguidos por mais 13,5% da população, Early Adopters, que compartilham características com Inovadores, mas são menos tolerantes
ao risco. Early Adopters entendem como fazer a escolha certa pode ajudá-los a manter um papel central na sociedade como pessoas a
serem respeitadas. A mudança é adotada em seguida pelos maiores segmentos da população, as maiorias precoces e tardias,
600 • DMBOK2
que representam 68% no total. Os retardatários são os últimos a adotar qualquer inovação específica. (Consulte a Figura 118 e a Tabela
37.)
100
75
50
25
Inovadores Cedo Tarde

Retardatários
2,5% Maioria
Primeiros usuários Maioria 16%
13,5% 34% 34%
Figura 118 Everett Rogers Difusão de Inovações
Tabela 37 Difusão de Categorias de Inovações Adaptadas à Gestão da Informação105
Adotante
Definição (Perspectiva da Gestão da Informação)
Categoria
Inovadores Os inovadores são os primeiros indivíduos a identificar uma maneira melhor de resolver problemas com a
qualidade da informação. Eles assumem riscos tentando desenvolver perfis de dados, construir scorecards provisórios e
começam a colocar os sintomas experimentados pela empresa na linguagem do Gerenciamento da Informação. Muitas
vezes, esses inovadores usarão seus próprios recursos para obter informações e desenvolver habilidades sobre as melhores práticas.
Early Adopters Os Early Adopters são a segunda categoria de indivíduos que mais rapidamente adota uma inovação. Esses indivíduos têm o
maior grau de liderança de opinião entre as outras categorias de adotantes. Eles são percebidos como gerentes 'visionários' (ou
gerentes experientes, ou gerentes responsáveis por áreas emergentes de estratégia de negócios) que perceberam que os
problemas de qualidade da informação são uma barreira para seu sucesso. Muitas vezes, eles pegam carona no trabalho
inicial dos Inovadores para desenvolver seu caso de negócios e começar a formalizar as práticas de informação.
Early Majority A Early Majority leva muito mais tempo do que os Early Adopters para adotar uma inovação. Cedo
A maioria tende a ser mais lenta no processo de adoção, tem status social acima da média, contato com early adopters e
raramente ocupa posições de liderança de opinião em um sistema. Eles podem estar nas áreas do 'núcleo tradicional' da
organização, onde o impacto de dados de baixa qualidade é mascarado como o 'custo do negócio'.
Maioria tardia Indivíduos na maioria tardia abordam uma inovação com um alto grau de ceticismo e depois que a maioria da sociedade adotou a
inovação. A maioria tardia normalmente tem status social abaixo da média, muito pouca lucidez financeira, em contato com
outros na maioria tardia e na maioria inicial, muito pouca liderança de opinião.
Em termos de Gestão da Informação, essas podem ser áreas da organização onde orçamentos apertados podem
combinar com ceticismo sobre as mudanças propostas para gerar resistência.
Retardatários Os retardatários são os últimos a adotar uma inovação. Os indivíduos nesta categoria mostram pouca ou nenhuma
liderança de opinião. Eles são tipicamente avessos a agentes de mudança e tendem a ter idade avançada. Retardatários
tendem a se concentrar em 'tradições'. Em Gerenciamento da Informação, esses termos geralmente são as pessoas ou áreas
do negócio que resistem porque a 'coisa nova' significa ter que fazer a 'coisa antiga' de forma diferente ou não fazer nada.
105 © 2014 Daragh O'Brien. Usado com permissão.

7.1 Os desafios a serem superados à medida que as inovações se espalham
Existem duas áreas-chave de desafio com a disseminação de inovações por toda a organização. A primeira é ultrapassar o estágio de adoção
inicial. Isso requer um gerenciamento cuidadoso da mudança para garantir que os Early Adopters possam identificar um nível suficiente de
insatisfação com o status quo que farão e persistir com a mudança.
Este passo é necessário para alcançar o 'Ponto de Virada' onde a inovação é adotada por um número suficiente de pessoas para começar
para se tornar mainstream.
O segundo ponto-chave do desafio é quando a inovação sai do estágio de Maioria Tardia para o estágio de Retardatários. A equipe precisa
aceitar que não pode necessariamente converter 100% da população para a nova maneira de fazer as coisas. Uma certa porcentagem do
grupo pode continuar resistindo à mudança e a organização precisará decidir o que fazer com esse elemento do grupo.
7.2 Elementos-chave na difusão da inovação
Quatro elementos-chave precisam ser considerados ao analisar como uma inovação se espalha por uma organização:
• Inovação: Uma ideia, prática ou objeto que é percebido como novo por um indivíduo ou outra unidade de
adoção
• Canais de comunicação: os meios pelos quais as mensagens são transmitidas de um indivíduo para outro
• Tempo: A velocidade com que a inovação é adotada pelos membros do sistema social
• Sistema social: O conjunto de unidades inter-relacionadas que estão engajadas na solução conjunta de problemas para realizar um
objetivo comum
No contexto do gerenciamento de informações, uma inovação pode ser algo tão simples quanto a ideia do papel de um administrador de
dados e a necessidade de que os administradores trabalhem de forma multifuncional em problemas de dados comuns, em vez do pensamento
tradicional de 'silo'.
O processo pelo qual essa inovação é comunicada e os canais pelos quais ela é comunicada de forma mais eficaz são os canais de
comunicação que devem ser considerados e gerenciados.
Por fim, a ideia do Sistema Social como um conjunto de unidades inter-relacionadas que estão engajadas em uma joint venture. Isso é uma
reminiscência do sistema descrito por W. Edwards Deming, que deve ser otimizado como um todo, em vez de peça por peça isoladamente.
Uma inovação que não se espalha para fora de uma única unidade de negócios ou equipe não é uma mudança bem difundida.
7.3 Os Cinco Estágios da Adoção
A adoção de qualquer mudança tende a seguir um ciclo de cinco etapas. Começa com os indivíduos tomando consciência da inovação
(Conhecimento), sendo persuadidos quanto ao valor da inovação e sua relevância para eles (Persuasão) e chegando ao ponto de tomar uma
decisão sobre sua relação com a inovação. Se eles não

602 • DMBOK2
rejeitam a inovação, eles então movem Implementar e finalmente Confirmar a adoção da inovação. (Consulte a Tabela 38 e a
Figura 119.)
É claro que, como uma ideia sempre pode ser rejeitada em vez de adotada, o ponto de inflexão da massa crítica dos primeiros
adeptos e da maioria inicial é importante.
Tabela 38 Os estágios de adoção (adaptado de Rogers, 1964)
Palco Definição
Conhecimento No estágio de conhecimento, o indivíduo é exposto pela primeira vez a uma inovação, mas carece de
informações sobre a inovação. Durante esta fase, o indivíduo ainda não foi inspirado a encontrar mais
informações sobre a inovação.
Persuasão No estágio de persuasão, o indivíduo está interessado na inovação e busca ativamente
informações sobre a inovação.
Decisão Na fase de Decisão o indivíduo pesa as vantagens e desvantagens de usar a inovação e decide se a
adota ou rejeita. Rogers observa que a natureza individualista desse estágio o torna o estágio mais difícil
sobre o qual adquirir evidências empíricas.
Implementação No estágio de Implementação o indivíduo emprega a inovação e determina sua
utilidade ou busca mais informações sobre ele.
Confirmação No estágio de Confirmação, o indivíduo finaliza sua decisão de continuar usando a inovação e
pode acabar usando-a em todo o seu potencial.
Conhecimento Persuasão Decisão
Figura 119 As Etapas de Adoção
7.4 Fatores que Afetam a Aceitação ou Rejeição de uma Inovação ou Mudança
As pessoas fazem escolhas amplamente racionais ao aceitar ou rejeitar uma inovação ou mudança. A chave para isso é se a
inovação oferece alguma vantagem relativa sobre a maneira anterior de fazer as coisas.
Considere o smartphone moderno. Apresentava uma clara vantagem sobre os smartphones anteriores porque era fácil de usar,
elegante de se ver e possui uma loja de aplicativos onde as capacidades do produto podiam ser estendidas rapidamente e
facilmente. Da mesma forma, a implementação de ferramentas, tecnologias e técnicas de gerenciamento de dados tem vantagens
relativas sobre a redigitação manual de dados, codificação sob medida ou atividades manuais de pesquisa e descoberta de dados
com uso intensivo de recursos.
Por exemplo, em muitas organizações, pode haver resistência a alterações simples de gerenciamento de documentos e conteúdo,
como marcar arquivos com metadados para fornecer contexto. No entanto, o uso desses metadados, por sua vez, oferece uma
vantagem relativa em termos de suporte a controles de segurança, agendamentos de retenção e tarefas simples, como pesquisa e
recuperação de informações. Vincular o incômodo da marcação ao tempo economizado na busca de informações ou no tratamento de
problemas em que as informações são compartilhadas ou divulgadas sem autorização pode ajudar a demonstrar essa vantagem
relativa.
Uma vez que os indivíduos vejam que uma melhoria é proposta, eles perguntarão se a melhoria é compatível com sua vida, sua
maneira de trabalhar, etc. ., significava que era compatível com o estilo de vida e formas de trabalho de seus usuários-alvo.
Para entender a compatibilidade, um consumidor irá (consciente ou inconscientemente) considerar vários fatores. Por exemplo, a
complexidade ou simplicidade da mudança. Se a inovação for muito difícil de usar, é menos provável que seja adotada. Mais uma vez,
a evolução das plataformas de smartphones e tablets está repleta de tentativas fracassadas que não atingiram o objetivo de uma
interface de usuário simples. Os que assim o fizeram redefiniram a expectativa do mercado e inspiraram interfaces semelhantes em
outros dispositivos.
A testabilidade refere-se a quão fácil é para o consumidor experimentar a nova ferramenta ou tecnologia. Daí ofertas freemium para
ferramentas. Quanto mais fácil for 'chutar os pneus', mais provável é que o usuário adote a nova ferramenta ou inovação. A importância
disso é que ajuda a estabelecer a compreensão da vantagem relativa, a compatibilidade com o estilo de vida e a cultura da organização
e a simplicidade da mudança. Como um conjunto de primeiros passos para uma visão de mudança, a prototipagem iterativa e
'experimentá-la' com as partes interessadas é essencial e pode ajudar a consolidar a Coalizão Orientadora, bem como garantir que os
adotantes iniciais estejam a bordo.
Observabilidade é a extensão em que a inovação é visível. Tornar a inovação visível impulsionará a comunicação sobre ela por meio
de redes formais e pessoais. Isso pode desencadear reações negativas, bem como reações positivas. Planeje como lidar com o
feedback negativo. A experiência de ver pessoas usando uma nova tecnologia ou trabalhando com informações de uma maneira
específica (por exemplo, visualização de números tradicionalmente "secos") pode influenciar a melhor forma de comunicar a experiência.
8. Sustentando a Mudança
Começar a mudança requer uma visão clara e convincente e primeiros passos claros e imediatos, um senso de urgência ou insatisfação
com o status quo, uma Coalizão Orientadora e um plano para evitar as armadilhas e armadilhas em que os Agentes de Mudança
podem cair quando começam sua mudar de jornada.
604 • DMBOK2
No entanto, um problema comum em iniciativas de gerenciamento de informações (por exemplo, programas de Governança de Dados) é que
elas são iniciadas em resposta a um direcionador específico ou a um sintoma específico de capacidade abaixo do ideal na organização. À
medida que o sintoma é abordado, a sensação de insatisfação e urgência diminui. Torna-se mais difícil manter o apoio político ou financeiro,
principalmente ao competir com outros projetos.
Está fora do escopo deste trabalho fornecer análises detalhadas ou ferramentas sobre como essas questões complexas podem ser
abordadas. No entanto, no contexto de um Corpo de Conhecimento, é apropriado consultar os princípios de gerenciamento de mudanças
descritos neste capítulo para fornecer algumas informações sobre como as soluções podem ser encontradas.
8.1 Senso de Urgência/Insatisfação
É importante manter o senso de urgência. O corolário disso é estar atento às áreas emergentes de insatisfação na organização e como a
mudança na gestão da informação pode ajudar a apoiar a melhoria.
Por exemplo, o escopo de uma iniciativa de governança de dados que foi implementada para dar suporte a um requisito regulatório de
privacidade de dados pode ser ampliado para abordar questões de qualidade da informação em relação a dados pessoais. Isso pode estar
relacionado ao escopo principal da iniciativa, pois a maioria das regulamentações de privacidade de dados tem um componente de qualidade
de dados e fornece o direito de acesso a dados a indivíduos, portanto, existe o risco de exposição de dados de baixa qualidade. No entanto,
ele abre a visão do programa de governança de dados para incluir métodos e práticas de qualidade da informação que podem ser
implementados como uma 'segunda onda' uma vez que os principais controles de governança de privacidade de dados estejam em vigor.
8.2 Enquadrando a Visão
Um erro comum é confundir o escopo do projeto com a visão da mudança. Muitos projetos podem ser necessários para alcançar a visão. É
importante que a visão seja definida de uma forma que permita uma ação ampla e não crie um beco sem saída para os líderes de mudança,
uma vez que os projetos iniciais de 'frutos fáceis' sejam entregues.
Há uma diferença entre uma visão que diz:
Implementaremos uma estrutura de governança estruturada para dados pessoais para garantir a conformidade com as regras de privacidade
de dados da UE.
e um que diz:
Vamos liderar nosso setor em abordagens e métodos repetíveis e escaláveis para gerenciar nossos ativos de informações críticas para
garantir lucros, reduzir riscos, melhorar a qualidade do serviço e equilibrar nossas obrigações éticas como administradores de informações
pessoais.
A primeira é, mais ou menos, um objetivo. O segundo fornece direção para a organização.

8.3 A Coalizão Orientadora
Restringir a participação da Coalizão Orientadora às partes interessadas mais imediatamente afetadas restringirá a eficácia da mudança.
Assim como a visão, é importante não confundir os grupos de direção do projeto que estão supervisionando a entrega de entregas
específicas com a coalizão que está orientando e desenvolvendo a visão de mudança na organização.
8.4 Vantagem Relativa e Observabilidade
Embora a aplicação ou o foco específico de uma iniciativa de mudança possa ser limitado, na maioria dos casos os princípios, práticas
e ferramentas aplicadas podem ser transferíveis para outras iniciativas. Ser capaz de demonstrar como a abordagem e os métodos
podem dar uma vantagem relativa a outras iniciativas na organização pode ajudar a estender a Coalizão Orientadora e identificar novas
áreas de urgência ou insatisfação que a iniciativa de mudança pode apoiar.
Por exemplo, em uma empresa de serviços públicos, métodos e ferramentas de criação de perfil de qualidade de dados e cartão de
pontuação que são implementados para uma visão única da implementação do cliente podem ser diretamente transferíveis para um
programa de conformidade de faturamento regulatório. A vinculação dos dois resultaria em um Enterprise Data Quality Scorecard e
iniciativas de remediação e governança de dados associadas, especialmente quando abordagens abaixo do ideal, como limpeza manual
de dados, podem ser a opção padrão para dados de cobrança.
9. Comunicando o valor do gerenciamento de dados
Ajudar uma organização a entender a importância do gerenciamento de dados geralmente requer um plano formal de gerenciamento
de mudanças organizacionais, conforme descrito neste capítulo. Esse plano ajuda a organização a reconhecer o valor de seus dados e
a contribuição das práticas de gerenciamento de dados para esse valor. Uma vez estabelecido um programa de gerenciamento de
dados, no entanto, também é necessário cultivar o suporte contínuo. A comunicação contínua promove a compreensão e sustenta o
apoio. Se as comunicações forem estruturadas como um canal de duas vias, um plano de comunicação pode ajudar a fortalecer as
parcerias, permitindo que as partes interessadas compartilhem preocupações e ideias. Esse tipo de esforço de comunicação requer
planejamento.
9.1 Princípios de Comunicação
O objetivo de qualquer comunicação é enviar uma mensagem a um receptor. Ao planejar as comunicações, é preciso levar em conta a
mensagem, a mídia usada para transmiti-la e os públicos a que se destina. Para sustentar essa estrutura básica, alguns princípios
gerais se aplicam a qualquer plano formal de comunicação, independentemente do tema. Estes são muito importantes ao comunicar
sobre gerenciamento de dados porque muitas pessoas não entendem a importância do gerenciamento de dados para o sucesso
organizacional. Um plano geral de comunicação e

cada comunicação individual deve:
606 • DMBOK2
• Tenha um objetivo claro e um resultado desejado
• Consistem em mensagens-chave para apoiar o resultado desejado

• Ser adaptado ao público/partes interessadas
• Ser veiculado por meio de mídia apropriada ao público/partes interessadas
Embora as comunicações possam ser sobre vários tópicos, os objetivos gerais da comunicação se resumem a:
• Informando
• Educar
• Definir metas ou uma visão
• Definir uma solução para um problema
• Promovendo a mudança
• Ação de influência ou motivação
• Obtendo feedback
• Gerando suporte
Mais importante ainda, para se comunicar com clareza, é necessário ter mensagens substantivas para compartilhar com as pessoas. As
comunicações gerais sobre gerenciamento de dados serão mais bem-sucedidas se a equipe de gerenciamento de dados entender o estado
atual das práticas de gerenciamento de dados e tiver uma visão e uma declaração de missão que conecte a melhoria nas práticas de
gerenciamento de dados diretamente aos objetivos estratégicos da organização. Gestão de dados

comunicações devem se esforçar para:
• Transmitir o valor tangível e intangível das iniciativas de gerenciamento de dados
• Descrever como os recursos de gerenciamento de dados contribuem para a estratégia e os resultados de negócios
• Compartilhe exemplos concretos de como o gerenciamento de dados reduz custos, apoia o crescimento da receita, reduz
risco, ou melhora a qualidade da decisão
• Educar as pessoas sobre os conceitos fundamentais de gerenciamento de dados para aumentar a base de conhecimento sobre
gerenciamento de dados dentro da organização
9.2 Avaliação e Preparação do Público
O planejamento das comunicações deve incluir uma análise das partes interessadas para ajudar a identificar os públicos para as
comunicações que serão desenvolvidas. Com base nos resultados da análise, o conteúdo pode ser adaptado para ser relevante, significativo
e no nível apropriado, com base nas necessidades das partes interessadas. Por exemplo, se o objetivo do plano de comunicação é obter
patrocínio para uma iniciativa, direcione as comunicações para os maiores influenciadores possíveis, geralmente executivos que desejam
saber o benefício final de qualquer programa que financiem.
As táticas para persuadir as pessoas a agirem nas comunicações incluem várias maneiras de fazer com que as pessoas vejam como seus
interesses se alinham com os objetivos do programa.

• Resolver problemas: as mensagens devem descrever como o esforço de gerenciamento de dados ajudará a resolver problemas
pertinentes às necessidades das partes interessadas que estão sendo atendidas. Por exemplo, os contribuintes individuais têm
necessidades diferentes dos executivos. A TI tem necessidades diferentes daquelas das pessoas de negócios.
• Aborde os pontos problemáticos: diferentes partes interessadas terão pontos problemáticos diferentes. Contabilizando essas dores
pontos nos materiais de comunicação ajudarão o público a entender o valor do que está sendo
proposto. Por exemplo, uma parte interessada em conformidade estará interessada em como um Data Management
programa reduzirá o risco. Uma parte interessada em marketing estará interessada em como o programa os ajuda
gerar novas oportunidades.
• Apresentar as mudanças como melhorias: na maioria dos casos, a introdução de práticas de gerenciamento de dados requer
que as pessoas mudam a forma como trabalham. As comunicações precisam motivar as pessoas a desejarem a proposta
mudanças. Em outras palavras, eles precisam reconhecer as mudanças como melhorias das quais
beneficiar.
• Ter uma visão de sucesso: Descrever como será viver no estado futuro permite que as partes interessadas
para entender como o programa os afeta. Compartilhar a aparência e a sensação do sucesso pode ajudar o
público entenda os benefícios do programa Data Management.
• Evite jargão: o jargão de gerenciamento de dados e a ênfase em aspectos técnicos transformarão algumas pessoas
desligar e diminuir a mensagem.
• Compartilhe histórias e exemplos: analogias e histórias são formas eficazes de descrever e ajudar as pessoas
lembre-se dos propósitos do programa de Gerenciamento de Dados.
• Reconheça o medo como motivação: Algumas pessoas são motivadas pelo medo. Compartilhando as consequências de não
gerenciar dados (por exemplo, multas, penalidades) é uma forma de indicar o valor de gerenciar bem os dados. Exemplos de
como a falta de práticas de gerenciamento de dados afetou negativamente uma unidade de negócios irá repercutir.
A entrega eficaz de comunicações envolve o monitoramento das reações dos ouvintes à mensagem. Se uma determinada tática não estiver funcionando,
adapte-se e tente um ângulo diferente.
9.3 O Elemento Humano
Os fatos, exemplos e histórias compartilhados sobre um programa de gerenciamento de dados não são as únicas coisas que influenciarão as percepções
das partes interessadas sobre seu valor. As pessoas são influenciadas por seus colegas e líderes. Por esta razão, a comunicação deve usar a análise
das partes interessadas para descobrir onde os grupos têm interesses e necessidades semelhantes. À medida que o suporte se amplia para o esforço de
gerenciamento de dados, os apoiadores podem ajudar a compartilhar a mensagem com seus pares e liderança.
608 • DMBOK2
9.4 Plano de Comunicação
Um plano de comunicação reúne elementos de planejamento. Um bom plano serve como um roteiro para orientar o trabalho em direção aos
objetivos. O plano de comunicação deve incluir os elementos listados na Tabela 39.
Tabela 39 Elementos do Plano de Comunicação
Descrição do elemento
Mensagem A informação que precisa ser transmitida.
Meta / Objetivo O resultado desejado de transmitir uma mensagem ou conjunto de mensagens (ou seja, por que a mensagem precisa
ser transmitida).
Público Grupo ou indivíduo visado pela comunicação. O plano terá objetivos diferentes para diferentes públicos.
Estilo Tanto o nível de formalidade quanto o nível de detalhe nas mensagens devem ser adaptados ao público. Os
executivos precisam de menos detalhes do que as equipes responsáveis pela implementação dos projetos.
O estilo também é influenciado pela cultura organizacional.
Canal, Método, O meio e o formato pelo qual a mensagem será transmitida (por exemplo, página da web, blog, e-mail, reuniões
Médio individuais, apresentações em pequenos ou grandes grupos, almoço e sessões de aprendizado, workshops, etc.)
Diferentes mídias têm efeitos diferentes .
Cronometragem A forma como uma mensagem é recebida pode ser influenciada pelo momento em que é recebida. Os funcionários
são mais propensos a ler um e-mail que sai na segunda-feira de manhã do que um que sai na tarde de sexta-feira.
Se o objetivo de uma comunicação é obter apoio antecipado a um ciclo orçamentário, ela deve ser cronometrada
em relação ao ciclo orçamentário.
As informações sobre mudanças iminentes nos processos devem ser compartilhadas em tempo hábil e antes
da ocorrência de uma mudança.
Frequência A maioria das mensagens precisa ser repetida para garantir que todas as partes interessadas as ouçam. O
plano de comunicação deve agendar o compartilhamento de mensagens para que a repetição seja útil para
transmitir a mensagem e não se torne um aborrecimento. Além disso, as comunicações contínuas (por exemplo,
um boletim informativo) devem ser publicadas com base em um cronograma acordado.
Materiais O plano de comunicação deve identificar quaisquer materiais que precisem ser criados para executar o plano.
Por exemplo, versões curtas e longas de apresentação e outras comunicações escritas, discursos de elevador,
resumos executivos e materiais de marketing como pôsteres, canecas e outros meios de branding visual.
Comunicadores O plano de comunicação deve identificar a pessoa ou pessoas que farão as comunicações. Muitas
vezes, a pessoa que entrega a mensagem tem uma profunda influência sobre o público-alvo. Se o patrocinador
de gerenciamento de dados ou outro executivo entregar uma mensagem, as partes interessadas terão uma
resposta diferente do que se um gerente de nível inferior a entregasse.
Decisões sobre quem comunicará quais mensagens para quais partes interessadas devem ser baseadas nos
objetivos da mensagem.
Esperado O plano de comunicação deve prever como os diferentes grupos de partes interessadas e, às vezes,
Resposta como as partes interessadas individuais responderão às comunicações. Este trabalho pode ser realizado
antecipando perguntas ou objeções e formulando respostas. Pensar nas possíveis respostas é uma boa maneira
de esclarecer as metas e criar mensagens robustas para apoiá-las.
Métricas O plano de comunicação deve incluir medidas de sua própria eficácia. O objetivo é garantir que as pessoas
tenham entendido e estejam dispostas e sejam capazes de agir de acordo com as mensagens do plano. Isso
pode ser feito por meio de pesquisas, entrevistas, grupos focais e outros mecanismos de feedback. Mudanças de
comportamento são o teste final do sucesso de um plano de comunicação.
Orçamento e O plano de comunicação deve levar em conta quais recursos são necessários para realizar as metas dentro de
Plano de recursos um determinado orçamento.
9.5 Continue Comunicando
Um programa de gerenciamento de dados é um esforço contínuo, não um projeto único. Os esforços de comunicação que apoiam o programa precisam ser
medidos e sustentados para o sucesso contínuo.
Novos funcionários são contratados e funcionários existentes mudam de função. À medida que as mudanças acontecem, os planos de comunicação precisam
ser atualizados. As necessidades das partes interessadas mudam ao longo do tempo à medida que os programas de gerenciamento de dados amadurecem.
É necessário tempo para que as pessoas absorvam as mensagens, e ouvir as mensagens várias vezes ajuda as partes interessadas a reter esse conhecimento.
Os métodos de comunicação e mensagens também precisarão ser adaptados ao longo do tempo à medida que a compreensão cresce.
A competição por financiamento nunca acaba. Um objetivo de um plano de comunicação é lembrar as partes interessadas do valor e dos benefícios do
programa de gerenciamento de dados. Mostrar o progresso e celebrar os sucessos é vital para obter apoio contínuo para o esforço.
O planejamento eficaz e a comunicação contínua demonstrarão o impacto que as práticas de gerenciamento de dados tiveram na organização ao longo do
tempo. Com o tempo, o conhecimento da importância dos dados muda a maneira de pensar da organização sobre os dados. Uma comunicação bem-sucedida
fornece uma melhor compreensão de que o gerenciamento de dados pode gerar valor comercial a partir de ativos de informação e ter um impacto duradouro
na organização.

Ackerman Anderson, Linda e Dean Anderson. O roteiro do líder de mudança e além do gerenciamento de mudanças. Conjunto de dois livros. 2ª
edição. Pfeiffer, 2010. Impresso.
Ackerman Anderson, Linda, Dean Anderson. Além do gerenciamento de mudanças: como alcançar resultados inovadores por meio da liderança de
mudanças conscientes. 2ª edição. Pfeiffer, 2010. Impresso.
Ackerman Anderson, Linda, Dean Anderson. O roteiro do líder de mudança: como navegar pela transformação da sua organização. 2ª edição.
Pfeiffer, 2010. Impresso.
Barksdale, Susan e Teri Lund. 10 Passos para um Planejamento Estratégico de Sucesso. ASTD, 2006. Impresso. 10 Passos.
Becker, Ethan F. e Jon Wortmann. Dominando a comunicação no trabalho: como liderar, gerenciar e influenciar. McGraw Hill, 2009. Impresso.
BEVAN, Ricardo. Changemaking: Táticas e recursos para gerenciar a mudança organizacional. Plataforma de Publicação Independente
CreateSpace, 2011. Imprimir.
Limites, Andy. O efeito bola de neve: técnicas de comunicação para torná-lo imparável. Capstone, 2013. Impresso.
Pontes, Guilherme. Gerenciando transições: aproveitando ao máximo a mudança. Da Capo Lifelong Books, 2009. Impresso.
Center for Creative Leadership (CCL), Talula Cartwright e David Baldwin. Comunicando sua visão. Pfeiffer, 2007.
Imprimir.
Contreras, Melissa. Habilidades de pessoas para negócios: habilidades sociais vencedoras que colocam você à frente da concorrência. Plataforma de
Publicação Independente CreateSpace, 2013. Imprimir.
Covey, Stephen R. Franklin Guia de Estilo de Covey: Para Negócios e Comunicação Técnica. 5ª edição. FT Press, 2012.Imprimir.
610 • DMBOK2
Covey, Stephen R. Os 7 Hábitos das Pessoas Altamente Eficazes: Lições Poderosas em Mudança Pessoal. Simon e Schuster, 2013. Imprimir.
FRANKLIN, Melanie. Gerenciamento ágil de mudanças: uma estrutura prática para planejamento e implementação de mudanças bem-
sucedidas. Kogan Page, 2014. Impresso.
Garcia, Hélio Fred. Poder da Comunicação: O: Habilidades para Construir Confiança, Inspirar Lealdade e Liderar Efetivamente. FT Press, 2012. Imprimir.
Godin, Seth e Malcolm Gladwell. Liberando o Ideavirus. Hachette Books, 2001.
Imprensa da Escola de Negócios de Harvard. Comunicação Empresarial. Harvard Business Review Press, 2003. Imprimir. Fundamentos de Negócios
de Harvard.
10 leituras obrigatórias da HBR sobre gerenciamento de mudanças. Harvard Business Review Press, 2011. Imprimir.
Hiatt, Jeffrey e Timothy Creasey. Gestão de Mudanças: O Lado das Pessoas da Mudança. Publicações do Centro de Aprendizagem Prosci,
2012. Impresso.
Holman, Peggy, Tom Devane, Steven Cady. The Change Handbook: O recurso definitivo sobre os melhores métodos de hoje para envolver sistemas
inteiros. 2ª edição. Editores Berrett-Koehler, 2007. Impresso.
Hood, J H. Como fazer o livro de Comunicação Interpessoal: Melhore seus Relacionamentos. Vol. 3. WordCraft Global Pty Limited, 2013. Impressão.
Livros “Como fazer”.
Jones, Fil. Estratégia de Comunicação. Ashgate, 2008. Impresso.
Kotter, John P. Mudança líder. Harvard Business Review Press, 2012. Imprimir.
Locker, Kitty e Stephen Kaczmarek. Comunicação Empresarial: Construindo Competências Críticas. 5ª edição. McGraw-Hill/Irwin, 2010. Print.
LUECKE, Ricardo. Gerenciando Mudanças e Transições. Harvard Business Review Press, 2003. Imprimir. Fundamentos de Negócios de Harvard.
Rogers, Everett M. Difusão de inovações. 5ª Ed. Imprensa Livre, 2003. Imprimir.

Reconhecimentos
D
Desenvolver a segunda edição do DAMA-DMBOK tem sido um trabalho de amor para muitas pessoas. o
os trabalhos começaram no final de 2011 com a primeira revisão do Framework Paper, lançado em 2012. O DAMA
O Comitê Editorial do DMBOK dedicou muitas horas para produzir o rascunho do DMBOK2. Eles incluem:
Patricia Cupoli (DAMA Philadelphia) foi a editora-chefe da maior parte deste trabalho, encontrando autores e ajudando-os a
desenvolver seus capítulos. Infelizmente, Pat faleceu no verão de 2015, enquanto ainda estava envolvido no projeto.
Deborah Henderson (IRMAC – afiliada do Toronto DAMA), Diretora de Programa dos produtos DAMA-DMBOK desde o início em
2005, foi uma patrocinadora dedicada do projeto e trabalhou para garantir sua conclusão após o falecimento de Pat.
Susan Earley (DAMA Chicago), que elaborou a estrutura DAMA-DMBOK2, foi a editora principal do rascunho do DMBOK2. Ela
editou e organizou o conteúdo e incorporou os extensos comentários públicos da DAMA
Membros.
Eva Smith (DAMA Seattle), Gerente de Ferramenta de Colaboração, cuidou da logística, inclusive permitindo que os membros da
DAMA acessem e comentem os capítulos.
Elena Sykora (afiliada do IRMAC – Toronto DAMA), Bibliographer Researcher, compilou a bibliografia abrangente do DMBOK2.
O Comitê Editorial também agradeceu o apoio especial de Sanjay Shirude, Cathy Nolan, Emarie Pope e
Steve Hobermann.
Laura Sebastian-Coleman (DAMA New England), Diretora de Publicações da DAMA e Editora de Produção, deu forma, poliu e
finalizou o manuscrito para publicação. Nesse esforço, ela foi orientada por um comitê consultivo que incluía Peter Aiken, Chris
Bradley, Jan Henderyckx, Mike Jennings, Daragh O Brien e eu, com muita ajuda de Lisa Olinda. Agradecimentos especiais também
vão para Danette McGilvray.
DMBOK2 não teria sido possível sem os principais autores contribuintes que deram substância à visão definida no Framework.
Todos os colaboradores são voluntários que compartilharam não apenas seus conhecimentos, mas também seu tempo.
Eles são creditados por suas contribuições abaixo. Os muitos membros do DAMA que forneceram feedback sobre os capítulos
também estão listados.
A DAMA International, a DAMA International Foundation e o DAMA Chapter Presidents' Council patrocinaram o projeto DMBOK.
Sua visão, percepção, paciência e apoio contínuo permitiram que este projeto fosse bem-sucedido.
Por fim, queremos reconhecer as famílias de todos os voluntários deste projeto, que doaram seu tempo pessoal para concluir este
trabalho.
Sue Geuens, Presidente, DAMA Internacional
611
612 • DMBOK2
Contribuintes principais
# Capítulo Contribuintes principais
1 Comitê Consultivo Editorial, editores DMBOK,

Introdução: Gerenciamento de dados
Chris Bradley, Ken Kring
2 Ética de manipulação de dados
3 Governança e administração de dados John Ladley, Mark Cowan, Sanjay Shirude

4 Arquitetura de dados Håkan Edvinsson
5 Modelagem e Design de Dados Steve Hoberman
6 Armazenamento de dados e operações Sanjay Shirude

7 Segurança de dados David Schlesinger, CISSP
8 Integração e interoperabilidade de dados Abril Reeve
9 Documentos e Conteúdo Pat Cupoli
10 Dados mestre e de referência Gene Boomer, Mehmet Orun
11 Martin Sykora, Krish Krishnan, John Ladley, Lisa

Data Warehouse e Business Intelligence
Nelson
12 Metadados Saad Yacu
13 Qualidade dos dados Rossano Tavares
14 Big Data e Ciência de Dados Robert Abate, Martin Sykora

15 Avaliação da maturidade do gerenciamento de dados Mark CowanDeborah Henderson
16 Organizações e funções de gerenciamento de dados Kelle O'Neal
Gerenciamento de dados e mudança organizacional Micheline Casey, Andrea Thomsen, Daragh O

17
Gestão Brien
Bibliografia Elena Sykora
Revisores e Comentaristas
As seguintes pessoas forneceram feedback valioso em vários estágios do DMBOK2:
Khalid Abu Shamleh Mike Beauchamp Susan Burke

Gerard Adams Chan Beauvais William Burkett
James Adman Glen Bellomy Vença Burtscher
Afsaneh Afkari Estação Benton Cavaleiro Ismael
Zaher Alhaj Leon Bernal Peter Campbell

Shahid Ali Luciana Bicalho Betty (Elizabeth) Carpenito
Suhail Ahmad Aman Ullah Pawel Bober Hazbleydi Cervera
Navegador Christiana Boehmer Indrajit Chatterjee
Samuel Kofi Annan Stewart Bond Bavani Chaudhary
Ivan Arroyo Gene Boomer Denise Cook
Nicola Askham Taher Borsadwala Nigel Corbin
Juan Azcurra Antonio Braga James Dawson
Richard Back Ciaran Breen Elisio Henrique de Souza
Carlos Barbieri Le Roy Broughton Patrick Terceiro
Ian Batty Paul Brown telhas desai

Steve Beaton Donna Burbank Swapnil Deshmukh
AGRADECIMENTOS • 613
Cíntia Dionísio Nicholene Kieviets Susana Navarro

Shaun Dookhoo Jon King Gautham Nayak
Janani Dumbleton Ricardo Rei Erkka Niemi
Lee Edwards Bruno Kinoshita Andy O'Hara
Jane Estrada Yasushi Kiyama Katherine O'Keefe
Adriano Evangelidis Daniel Koger Hirofumi Onozawa

William Evans Katarina Kolich Mehmet Orun
Mario Faria Onishi Koshi Matt Osborne
Gary Flye Edwin Landal Mark Ouska

Michael Fraser Teresa Lau Pamela Owens
Carolyn Frey Tom LaVerdure Shailesh Paliwal
Alex Friedgan Richard Leacton Mikhail Parfentev
Lowell Fryman Michael Lee Melanie Parker

Shu Fulai Martha Lemoine John Partyka
Ketan Gadre Melody Lewin Bill Penney
Oscar Galindo Chen Liu André Pérez
Alexandre Gameiro Manoel Francisco Dutra Lopes Jr. Aparna Phal
Jay Gardner Daniel Lopes Jocelyn Sedes
Johnny Gay Karen Lopez Mark Segall
Sue Geuens Adam Lynton Ichibori Seiji
Gupta leva Colin Macguire Brian Phillippi
Gabrielle Harrison Michael MacIntyre R. Taeza Pittman
Kazuo Hashimoto Kenneth MacKinnon Edward Pok
Andy Hazelwood Colin Maguire Emarie Pope

Muizz Hassan Zeljko Marcan David Quan
David Hay Satoshi Matsumoto K Rajeswar Rao
Clifford Heath George McGeachie Abril Reeve
Jan Henderyckx Danette McGilvray R. Todd Reis
Trevor Hodges Raymond McGirt Scott Raul Ruggia-Frick
Mark Horseman McLeod Scott Sammons
Joseph Howard Melanie Meca Pushpak Sarkar

Monica Howat Ben Meek John Schmidt
Bill Huennekens Steve Mepham Nadine Schramm
Mark Humphries Klaus Meyer Toshiya Seki

Marido Zoey Josep Antoni Mira Palácios Rajamanickam Senthil Kumar
Toru Ichikura Toru Miyaji ninho do xá
Thomas Ihsle Ademilson Monteiro Gaurav Sharma
Gordon irlandês Danielle Monteiro Vijay Sharma
Fusahide Subbaiah Muthu Krishnan Stephen Sherry
Seokhee Jeon Mukundhan Muthukrishnan Jenny Shi
Jarred Jimmerson Robert Myers Satoshi Shimada
Christopher Johnson Dean Myshrall Sandeep Shinagar

Wayne Johnson Krisztian Nagy Boris Shuster
Se-Kei Jordan Kazuhiro Narita Vitaly Shusterov
George Kalathoor Mohamad Nasser Abi Sivasubramanian
614 • DMBOK2
Alicia Slaughter Akira Takahashi Roy Verharen

Eva Smith Steve Thomas Karel Vetrovsky
Tenny Soman Noriko Watanabe Gregg Withers
José Antonio Soriano Guzmán Joseph Weaver Michael Wityk
Donald Soulsby Cristina Weeden Marcin Wizgird
Eric Stahl Alexandre Titov Benjamin Wright-Jones
Jerry Stembridge Steven Tolkien Teresa Wylie
James Stevens Tom Toshimitsu Hitoshi Yachida
Jan Stobbe João Paulo Torres Saad Yacu
Santosh Subramaniam David Twaddell Hiroshi Yagishita
Motofusa Sugaya Thijs van der Feltz Harishbabu Yelisetty
Venkat Sunkara Elize van der Linde Taisei Yoshimura
Alan Sweeney Peter van Nederpelt
Martin Sykora Amigo Pedro
Índice
Categoria de abstração, 165 Estratégia de big data, 511-12

Abuso Hackers Black Hat, 242
Intencional, 239 Bancos de dados Blockchain, 177
Não intencional, 239 Bot, 229
Acesso, 249 Brandeis, Louis, 53
Controles de acesso, 200 Teorema de Brewer, 180
Acesso a dados, 238 Pontes, Guilherme, 575-76
ÁCIDO, 179 Fases de Transição de Bridges, 575
Risco de Deveres Administrativos e de Auditoria, 254 Traga seus próprios dispositivos (BYOD), 325
Adware, 243 Alinhamento de negócios, 80
Gerenciamento de afiliação, 365 Viés de negócios, 59
Aiken, Pedro, 39 Grupo de continuidade de negócios, 198
pirâmide de Aiken, 40 Plano de Continuidade de Negócios, 197, 281, 327
Instituto Nacional Americano de Padrões, 144 Administrador de dados de negócios, 77, 342
Modelo de Informações de Amsterdã, The, 34-35, 35 Glossário de negócios, 90, 92, 427, 580
Modelo analítico, 521-22 Crescimento do negócio, 220
Padrão ANSI 859, 326 Inteligência de negócios, 57, 63, 384
Software antivírus, 256 Carteira para, 398
Apache Mahout, 521 Autoatendimento, 408
Acoplamento de aplicação, 281 Ferramentas para, 403
Aplicativo DBA, 174 Inteligência de negócios e funções analíticas, 40

Requisitos de segurança do aplicativo, 261 Metadados de negócios, 422–23
Arquitetos, 101 Gestão de desempenho de negócios, 405
Diagramas de projeto arquitetônico, 115 Regras de negócios, 289
Arquitetura, 97 Dados críticos e, 474-75
Projetos de arquitetura, 116 Integração de dados e, 295
Estrutura de arquitetura, 102 Vocabulário de negócios, 154
Projetos de iniciação à arquitetura, 118 BYOA. Consulte Traga seus próprios aplicativos
Processo de arquivamento, 189, 279 BYOD. Consulte Traga seus próprios dispositivos (BYOD)
Princípios ARMA GARP®, 340, 343 C, 71
ARMA Internacional, 306 CAD/CAM. Consulte Projeto e fabricação assistidos por
Avaliações, 79-80 computador Canada Bill 198, 49, 316 Canadian Privacy law
Ativo, 20 (PIPEDA), 54–55, 236 Candidate Identification, 363 Canonical
Software de gerenciamento de ativos, 115 data model, 279–80 CAP Theorem, 180 Capacity and growth
Rastreamento de ativos, 213 projects, 190 CDMP, 65 CDO Pontos de contato organizacionais,
Fluxo de dados assíncrono, 277 81 bancos de dados centralizados, 175 Change Capacity to, 80
Decreto autoritário, 590 Checklist para gerenciamento, 576–77 Leis de, 574 Sustaining,
Lista de autoridades, 312 603 Change management, 573 Change agent, 574, 577, 590, 597
Atividades de backup e recuperação, 327 Change data, 190 Change data capture, 276 Comunicação de
Arquivos de backup, 198 gerenciamento de mudanças e, 590 Complacência e, 577 Erros
Software de backup, 198 de, 577–78, 582 Transição e, 575–77 Visão para, 578 Change
BASE, 179 Management Institute, 85
Acordo de Basileia II, 247
Captura de dados de alteração de lote, 393
Integração de dados em lote, 276, 291
Interação em lote, 275-76
Princípios de Belmont, 52
Tendência
Processamento de dados e, 58-59

Tipos de, 58-59
Arquitetura de metadados bidirecional, 433
Big data, 497–99, 502–4
Armazenamento em nuvem e, 520
Princípios de, 500
Fontes de, 504
Ferramentas para, 517-18
Modelagem de Big Data, 522
615
616 • DMBOK2
Gerentes de mudança, 575, 577 Visão Fábrica de Informações Corporativas (CIF), 386–88, 388
de mudança, 604 Tabelas e gráficos, Categoria de correção, 165
57 Diretor de dados, 81 Diretor de Covey, Stephen, 598
informação, 32 Chisholm, Malcolm, Dados críticos, 474-75
350, 351 Palavras de classe, 161 Dados de Risco Crítico (CRD), 224
Esquemas de classificação, 313 Conjuntos de dados de referência cruzada, 354
Computação em nuvem, 177, 265 CRUD, 258

Armazenamento em nuvem, 520 Mudança cultural, 119
Integração baseada em nuvem, 285 Gerenciamento de relacionamento com o cliente (CRM), 84, 366, 368
CobiT. Consulte Objetivos de controle DAMA Data Management Function Framework, 35–39, 42
para informações e tecnologia relacionada. Dependências da Área Funcional DAMA, 41
DAMA Internacional, 64
Gerenciamento de dados certificado da DAMA International
Prontidão colaborativa, 80 coleção, Certificação Profissional (CDMP), 65
319 arquitetura de dispositivo colunar, Áreas de Conhecimento DAMA, 40
519 bancos de dados baseados em coluna, 181 Roda DAMA, A, 35, 40, 43, 44
bancos de dados orientados a coluna, 186–87 missão da DAMA, 44
comercial da prateleira (COTS), 479 interrogativos de DAMA-DMBOK, 35–39, 43–46
comunicação, 103 plano de comunicação, 605–6, 608 Dados
vantagem competitiva, 18, 237 Complacência, 578, Análise, 514

584 Categoria de integridade, 165 Soluções de Como ativo, 17, 20, 23, 52
processamento de eventos complexos (CEP), 284, Aceitação comercial de, 411-12
292 Atividades de conformidade, 255–56 Projeto e Crítico, 454
fabricação assistidos por computador, 189 worm de Abordagem ética para, 20
computador, 244 Classificação de confidencialidade, 248 Restrições de Princípios éticos de, 52-53
dados de confidencialidade, 235 Configuração gerenciamento, 409 Valor monetário de, 24
Ferramentas de gerenciamento de configuração, 427 Categoria de Propriedade de, 56
consistência, 166 Captura de conteúdo, 326 Definição de, 307 Ciclo de Riscos e, 28, 30
vida de, 307 Canais de entrega de conteúdo, 330 Métodos de entrega de Sensível, 217-20
conteúdo, 308 Políticas de manuseio de conteúdo, 324 Arquitetura de Recipientes de armazenamento para, 201
informações de conteúdo, 325 Ciclo de vida de conteúdo, 307 Tipos de, 29
Gerenciamento de conteúdo , 307, 324 Software de gerenciamento de Compreensão de, 18-20
conteúdo, 311 Content Management System (CMS), 323, 330, 332 Valor de, 24-25
Metadados de conteúdo, 307–8 Modelo de conteúdoi ng, 308 Diagrama Acesso a dados, 197
de contexto, 36 Big data e ciência de dados, 499 Componentes de, Controle de acesso a dados, 249
37–39 Arquitetura de dados, 100 Governança e administração de Aquisição de dados, 361-62
dados, 69 Modelagem de dados, 124 Qualidade de dados, 451 Administração de dados, 170
Segurança de dados, 219 Data warehouse/inteligência de negócios, 382 Agregação de dados, 60
Definido , 37 Documentos e conteúdo, 304 Área de conhecimento, 37 Ferramentas de análise de dados, 485
Metadados, 419 Referência e dados mestre, 348 Dados e arquitetura empresarial, 109
Relação de dados e informações, 20, 33
Arquitetos de dados, 101, 567
Arquitetura de dados, 45, 98, 110
Gols de, 99
Diretrizes de implementação e, 117-18
Artefatos de arquitetura de dados, 90
Governança da arquitetura de dados, 119
Dados como serviço (DaaS), 285
Ativo de dados, 91
Avaliação de ativos de dados, 77-79
Atributo de dados, 155
Auditorias de dados, 213
Disponibilidade de dados, 227

Captura de dados
Mudança, 276
Categoria de dados, 166
Limpeza de dados, 471
Consistência de dados, 249
Consumidores de dados, 399
Dicionário de dados, 402, 429
Descoberta de dados, 287
Restrições contratuais, 237 Aprimoramento de dados, 471-72
Atividade de controle, 38 Projeto de especificação de troca de dados, 290
Objetivos de controle para informação e tecnologia relacionada, 71 Padrões de Troca de Dados, 286
Vocabulário controlado, 309, 311, 313, 333 Federação de Dados, 285
Coordenando o administrador de dados, 77 Fluxos de dados, 107–9
ÍNDICE • 617
Diagrama, 108 Atividades de gerenciamento de dados

Integração, 291 Controle, 38
Governança de dados, 45, 53, 64, 67, 73 Desenvolvimento, 38
Gols de, 71-72 Operacional, 38
Princípios orientadores para, 71, 73, 305, 421 Planejamento, 38
Implementação de, 88 Estrutura de gerenciamento de dados, 33
Gerenciamento de problemas, 86 Roteiro de implementação de gerenciamento de dados, 32
Gerenciamento de problemas para, 85 Maturidade de gerenciamento de dados, 80
Cultura organizacional e, 93 Plano de gerenciamento de dados, 605
Organizações e, 79 Práticas de gerenciamento de dados, 89, 573
Procedimentos para, 87 Avaliação de, 80
Avaliações de prontidão e, 79-80 Procedimentos de gerenciamento de dados
Conformidade regulatória e, 70-71 Componentes, 89
Ferramentas e técnicas para, 92 Profissionais de gerenciamento de dados, 17.573
Governança de dados e gerenciamento de dados, 72 Programa de gerenciamento de dados, 609
Comunidade de Interesse de Governança de Dados, 91 Recursos humanos e, 607
Conselho de governança de dados, 32, 83, 84, 86, 90, 91, 93, 248 Carta do programa de gerenciamento de dados, 32
Estrutura operacional de governança de dados, 83 Declaração de escopo de gerenciamento de dados, 32
Partes da organização de governança de dados, 74 Estratégia de gerenciamento de dados, 31-33, 94
Organizações de governança de dados, 73, 91 Componentes de, 32
Programa de governança de dados, 43 Entregas de, 32
Diretrizes de implementação para, 93 Mapa de dados, 318, 337
Medição e, 94 Marcação de dados, 60
Scorecard de governança de dados, 93 Data marts, 392
Padrões de governança de dados, 88-90 Mashups de dados, 511
Comitês Diretores de Governança de Dados, 93 Métodos de mascaramento de dados, 60, 227, 228, 253
Estratégia de governança de dados, 31, 82 Migração de dados, 208–9, 292
Equipe de governança de dados, 445 Mineração de dados, 507-8
Manipulação de dados Espionagem de mineração de dados, 58
Estado atual e, 61 Modelo de dados
Estratégias de melhoria e, 62 Integração em, 164

Redução de risco e, 61-62 Versionamento de, 164
Ética no manuseio de dados, 49, 51 Gerenciamento de modelo de dados, 360
Informações de dados, 500, 517 Repositórios de modelo de dados, 115
Integração de dados, 59–60, 299 Modelador de dados, 160
Tempo quase real, 277 Modelagem de dados, 45, 123-26
Perfil e, 288 Gols de, 125
Síncrono, 277-78 Padrões para, 161, 162
Integração e interoperabilidade de dados (DII), 45, 269–71, 272, Ferramentas de modelagem de dados, 115, 209, 295, 430, 485
286 Modelos de dados
Atividades de integração de dados, 286-89 Avaliação de, 515

Processos de integração de dados, 372, 376, 392–94 Movimento de dados, 272
Soluções de integração de dados Padrões de nomenclatura de dados, 161
Regras de negócios e, 295 Operações de dados e atividades de armazenamento, 193-96
Projeto de, 289 Orquestração de dados, 291
Fontes de mapeamento e, 290 Processo de análise de dados, 472
Ferramentas de integração de dados, 402–3, 403, 428 Patches de dados, 469
Integridade de dados, 226 Política de dados, 77, 83
Caminho de escalonamento de problemas de dados, 86 Leis de privacidade de dados, 53–56
Lago de dados, 505 Erros de processamento de dados, 193
Ciclo de vida dos dados, 28–29, 41, 287 Produtor de dados, 162
Principais atividades do ciclo de vida dos dados, 29 Aplicativos de produção de dados, 292
Linhagem de dados, 264, 287, 298 Ciclo de vida de desenvolvimento de produtos de dados, 400–401
Requisitos de carregamento de dados, 201 Profissionais de dados, 63, 162
Perda de dados, 211 Processos de criação de perfil de dados, 288, 470, 476
Gerenciamento de dados, 17, 30–31, 67 Ferramentas de perfil de dados, 295, 485
Desafios de, 20 Qualidade dos dados, 25–26, 46, 449–52, 453–54
Consumidores para, 38 Gols de, 452-53
Qualidade dos dados e, 25 Padrões ISO para, 461-62
Perspectiva empresarial e, 27 Medição de, 479-81
Gols de, 18 Processos de relatório em, 484
Iniciativas e, 84 Estatísticas sobre, 25
Entradas e, 38 Projeto do sistema e, 468
Metadados e, 417-19 Análise de qualidade de dados, 80
Participantes em, 38 Avaliação da qualidade dos dados, 475
Hardware especializado para, 182 Regras de negócios de qualidade de dados, 25–26
618 • DMBOK2
Dimensão de qualidade de dados, 454–60 Equipe para, 86, 91
Metas de qualidade de dados, 477 Armazenamento de dados e operações, 45

Melhoria da qualidade dos dados Áreas de armazenamento de dados, 391-92
Mudança cultural e, 492-93 Ambiente de armazenamento de dados, 201

Diretrizes de implementação para, 490-91 Objetivos de armazenamento de dados, 171, 181
Avaliação de risco e, 491 Governança de armazenamento de dados, 213
Ciclo de vida da melhoria da qualidade dos dados, 462–64 Métricas de armazenamento de dados, 212
Problemas de qualidade de dados Sistemas de armazenamento de dados, 184-89

Causas de, 465-70 Estratégia de dados, 32
Ações corretivas e, 486-87 Componentes de, 32
Entrada de dados e, 466 Propriedade de, 32
Processamento de dados e, 468 Estruturas de dados, 290
Liderança e, 465-67 Requisitos de tecnologia de dados, 194

Patches de dados manuais e, 469 Transformação de dados, 397, 473
Procedimentos operacionais para, 481-83 Motor de transformação de dados, 294
Ações preventivas e, 486 Validação de dados, 213, 362
Métricas de qualidade de dados, 494 Avaliação de dados, 24-25
Política de qualidade de dados, 493-94 Cofre de dados, 393
Governança do programa de qualidade de dados, 493 Virtualização de dados, 285
Estratégia de qualidade de dados, 474 Servidores de virtualização de dados, 294
Plano de recuperação de dados, 197 Visualização de dados, 510–11, 516, 520
Software de recuperação de dados, 198 Armazém de dados, 381-83, 384
Regulamentos de dados, 220, 248 Abordagens para, 385

Correção de dados, 60, 397 Captura de dados de alteração em lote para, 393
Processo de replicação de dados, 191, 202 Fatores críticos de sucesso para, 523
Plano de retenção de dados, 193, 286 Faixas de desenvolvimento para, 396

Riscos de dados, 70 Gols de, 383
Modelos de regras de dados, 485 Governança em, 411
Escala de dados, 191 Dados históricos e, 392-93

Ciência de dados, 497-502, 514 População de, 397
Ferramentas de ciência de dados, 517–18 Requisitos de, 394
Segurança de dados, 45, 193, 217–20 Armazenamento de dados, 46, 385
Declaração de Direitos, 252 Fatores críticos de sucesso, 410
Requisitos de negócios, 217-20, 245 Banco de dados, 172

Gols de, 222 Hierárquico, 184
Monitoramento de, 226, 253-55 Multidimensional, 185
Terceirização, 264 Temporário, 185

Senha para, 234 Tipos de, 175
Requisitos regulamentares para, 246 Abstração de banco de dados, 172
Requisitos para, 225 Controle de acesso ao banco de dados, 200

Avaliação de risco e, 262-63 Administrador de banco de dados (DBA), 170, 173, 194, 195, 196, 201,
Declaração de Direitos de Segurança de Dados, 252 211-12
Governança de segurança de dados, 265 Banco de dados como serviço (DaaS), 178
Gerenciamento de segurança de dados Disponibilidade do banco de dados
Quatro As de, 225 Fatores que afetam, 204

Princípios orientadores para, 222 Fatores de perda de, 204
Política de segurança de dados, 247–48, 251 Critérios online para, 204
Práticas de segurança de dados, 262 Backup de banco de dados, 198

Requisitos de segurança de dados, 218 Catálogos de banco de dados, 428
Restrições de segurança de dados, 234–37 Execução do banco de dados, 205
Riscos de segurança de dados, 220 Técnicas de log de banco de dados, 393

Padrões de segurança de dados, 245, 248 Gerenciamento de banco de dados
Vocabulário de segurança de dados, 229–32 Mudança organizacional e, 211-12

Serviços de dados, 291 Sistema de gerenciamento de banco de dados (DBMS), 185
Acordos de compartilhamento de dados, 298, 377 Tecnologia de gerenciamento de banco de dados
Governança da fonte de dados, 413 Convenções de nomenclatura e, 210
Fontes de dados, 512-13 Arquivos de script e, 210
Avaliação de, 370-72 Software para, 194
Ingestão, 512-13 Ferramentas, 209
Padronização de dados, 473 Ferramentas de gerenciamento de banco de dados, 209
Comitê Diretor de Padrões de Dados, 89 Ferramentas de monitoramento de banco de dados, 209
Administradores de dados, 76–77, 90, 247, 252, 255, 263, 356, 371 Espectro de Organização de Banco de Dados, 184
Coordenação, 77 Desempenho do banco de dados
Executivo, 76 Monitoramento para melhorar, 205
Administração de dados, 75 Ajustando para melhorar, 173
Comitê para, 86 Processos de banco de dados
ÍNDICE • 619
Arquivamento, 189 Bancos de dados distribuídos, 175

Projeções de capacidade e crescimento de, 190 Tecnologias de soluções baseadas em arquivos distribuídos, 519–20 DMBOK
Alterar dados dentro de, 190 Pyramid, 39–40 Documento/registro, 315 Auditoria de, 329 Gerenciamento de,
Purga, 191 328 Retenção de, 328 Conhecimento de documentos e conteúdo, 305–6
Replicação de, 191 Gerenciamento de documentos e conteúdo, 45, 303 Conformidade
Resiliência de, 192 regulatória e, 304–5 Sistema de biblioteca de documentos, 330
Retenção de, 193 Gerenciamento de documentos, 305, 315–17, 323, 331 Sistema de
Fragmentação de, 193 gerenciamento de documentos, 330 Ferramenta de gerenciamento de
Processamento de banco de dados, 179 documentos, 93 Repositório de documentos, 331 Sanitização de documentos,
Sistemas de armazenamento de banco de dados, 196 262 Drill down, 407 Dublin Core, 309 métricas de uso de DW, 413
Suporte de banco de dados, 169, 196 arquitetura DW/BI, 395 método de mascaramento de dados dinâmicos, 228
Tarefas de administração de sistemas de banco de dados, 199 ECM. Consulte Avaliação de prontidão para ECM dos Sistemas de
Tecnologia de banco de dados Gerenciamento de Conteúdo Corporativo, 338 E-discovery, 305, 336 Key
Gerenciando, 194-96 Performance Indicators (KPIs) e, 343–44 E-discovery assessment, 339 EDM.
Monitoramento de, 195 Consulte Modelo de Dados Corporativos EDRM. Consulte Modelo de
Apoio de, 170 Referência de Descoberta Eletrônica (EDRM)
Bancos de dados
Ambientes alternativos para, 207 Centralizado,

175 Baseado em coluna, 181 Orientado a coluna,
186–87 Carregamento de dados e, 201 Ambiente
de desenvolvimento e, 182 Distribuído, 175
Arquivo simples, 187 Par chave-valor, 188
Multimídia, 187 Não relacional, 186 Objeto/Multimídia,
187 Processos de, 189–93 Relacional, 185 Espacial,
187 Especializado, 188 Triplestore, 188 Tipos de,
184–89 Padrões de uso de, 196 Processo de banco
de dados, 189–93 Organização centrada em dados,
73 DBA. Consulte Administrador de banco de dados
Sistemas de suporte à decisão (DSS), 381 Senhas Intercâmbio eletrônico de dados (EDI), 266 Electronic
padrão, 241 Categoria de definições, 166 Deming, Discovery Reference Model (EDRM), 318 Documentos eletrônicos, 318
W. Edward, 51 Desnormalização, 150 Revisão de Aplicativos de ponto de venda eletrônico (EPOS), 309 Registros eletrônicos,
projeto, 163 Destino (VISION), 575 Risco de 305, 323 Tecnologia eletrônica e crescimento de negócios, 221 ELT. Consulte
detecção e recuperação, 254 Ferramentas de Fluxo de processo ELT Extract-Load-Transform, 275 Encryption, 226, 227,
suporte ao desenvolvedor, 209 Desenvolvedores, 241, 258, 262 English, Larry, 457 Enrichment, 362 Enterprise application
183 Atividade de desenvolvimento, 38 DBAs de integration model (EAI), 283 Enterprise architecture framework, 102–4
desenvolvimento, 174 Ambiente de desenvolvimento, Enterprise architecture, 98 , 109, 110, 265 Enterprise asset, 17 Enterprise
182, 183 Políticas de acesso a dispositivos, 325 Dewey Content Management (ECM), 307 Cultural change and, 339 Guidelines for,
Decimal System, 313 Dice, 406 Diffie-Hellman Key 337 Key Performance Indicators (KPIs) e, 344 Enterprise data architecture,
Agreement, 227 Diffusion of Innovations theory, 599 119–23 Enterprise data architecture administration Committee, 90 Conselho
Digital asset management (DAM), 318, 331 Governança de governança de dados corporativos, 74 Modelo de dados corporativos, 90,
DII, 297–98 soluções DII, 293 Dimensional data 105–7, 106 Armazenamento de dados corporativos, 385 Ferramenta de
warehouse, 388–90 Directory, 428, 429, 430 Disaster integração corporativa, 296–97 Formato de mensagem corporativa, 279
Recovery Plan, 327 Disasters, 192 Discovery, 80, 287, Perspectiva corporativa e gerenciamento de dados, 27 Planejamento de
318–20 Disk storage, 181 recursos empresariais (ERP), 84, 201, 271, 368 Barramento de serviço
empresarial (ESB), 281, 283, 294 Padrões empresariais, 289 Resolução
de entidade, 362 Hexágono de fatores ambientais, 35, 36 Relação de
termos equivalentes, 311 ERP. Consulte Planejamento de recursos
empresariais Manuseio ético de dados, 49, 51, 60–61, 61–62, 62, 64
Gerenciamento ético de dados, 49, 57 Modelo de risco ético, 64 Riscos éticos,
59
620 • DMBOK2
Ética, 49 Hierarchical Storage Management System, 187 Taxonomia

fluxos de dados ETL, 291 hierárquica, 312 High Risk Data (HRD), 224 Historical data,
fluxo de processo ETL, 274 392–93 HOLAP. Consulte Processamento analítico online
processos ETL, 485 Acordo híbrido Hot backups, padrão de dados 198 Hub-and-spoke,
de Basileia II da UE, 247 Diretivas modelo de interação 279 Hub-and-spoke, 280–81 processamento
de privacidade da UE, 236 analítico online híbrido, 407 Identity, 56 Identity management
Convenção Europeia de Direitos Humanos, 53 Supervisor technology, 257 Identity Resolution, 364 IM. Consulte Mensagens
Europeu de Proteção de Dados, 52 Método de instantâneas (IM)
processamento de eventos, 284, 292 Evento- integração
de dados orientada, 277 Everett Rogers Diffusion of
Innovations, 600 Privilégios excessivos, 238 Administradores
de dados executivos, 76 Interface de marcação extensível,
334 Linguagem de marcação extensível, 334 Dados
externos, 202 Extrair-Carregar-Transformar (ELT), 274 Tecnologia de processamento de imagem, 331–
Processo de extração, o, 273 Extract-Transform-Load (ETL), 32 Imhoff, Claudia, 386 Explicação de
205, 273, 275 Taxonomias facetadas, 311, 313 Family inconsistências, 597–98 Algoritmo no banco de
Educational Rights and Privacy Act, 237 FASB. Veja dados, 520 Indexação, 157 Dados de
Financial Accounting Standards Board Integração rápida de referência do setor, 356 Regulamentos baseados
dados, 278 Regras Federais de Processo Civil, 316 Comissão no setor, 237 Pesquisa de tecnologia da informação
Federal de Comércio, 55 Arquiteturas Federadas, 176 Dados e comunicação, 52 Relacionamento de informações
de Disposições da Federação, 176 FERPA. Veja Family e dados, 20 Arquitetura de informação, 320 Ativo
Educational Rights and Privacy Act Financial Accounting Standards de informação, 30 Rastreamento de ativo de informação, 213 Consumidor de
Board, 87 Ativos financeiros, 23 Dados mestre financeiros, 367 informação, 162 Arquitetura de conteúdo de informação, 329 Conselho de
Dados financeiros sensíveis, 237 Firewalls, 230, 257 Memória Informação, 342 Economia de informação, 17 Lacunas de informação, 30, 91
Flash, 182 Bancos de dados de arquivos simples, 187 Folksonomias, Governança de informação, 340–42 Modelo de Maturidade de Governança de
309, 313 Estruturas. Consulte Estruturas de gerenciamento de Informação (IGMM) , 338 Modelo de Referência de Governança da Informação
dados Liberdade de expressão, 56 GASB. Ver Conselho de Normas (IGRM), 341 Iniciativa de mudança de gerenciamento de informações, 588
de Contabilidade Governamentais (EUA) Contexto de gerenciamento de informações, 596 Disciplinas de gerenciamento
de informações, 52 Mudança de qualidade da informação, 599 Segurança da
informação Classificação de dados e, 220 Técnicas de gerenciamento, 258–
59 Ferramentas usadas em, 256–58 Vocabulário para, 223–24
Regulamento geral de proteção de dados, 54

Princípios de manutenção de registros geralmente aceitos, 338
Classificação geográfica, 356 Sistemas de informações geográficas
(GIS), 325 Dados de referência geoestatística, 356 Geuens, Sue,
40 Fórmula de Gleicher, 577 Glossário, 90 Godin, Seth, 599 Registro Segurança da Informação e Conselho Corporativo, 255
de ouro , 358–59 Goodwill, 20 Governança. Veja também Equipe de segurança da informação, 224–25
Governança de Dados Government Accounting Standards Board Método de Planejamento de Sistemas de Informação (ISP), 109
(US), 87 Aplicativos de design gráfico, 115 Group Think, 589 Tecnologia da informação e gerenciamento de dados, 30–31
Princípios orientadores Governança de dados, 71, 73, 305, 421 Biblioteca de infraestrutura de tecnologia da informação (ITIL), 194, 199
Gerenciamento de segurança de dados, 222 Hacking/Hacker, 241 Bancos de dados na memória (IMDB), 181
Hadoop, 519 Algoritmos de hash, 177 Criptografia de hash, 227 Inmon, Bill, 385
Health Information Protection and Portability Act (US), 49 Healthcare Inovação, 601
Information Portability and Accountability Act (HIPAA), 254 Organização Mensagens instantâneas (IM), 244
de banco de dados hierárquico, 184 Relacionamento hierárquico, 312 Sistema baseado em nuvem de integração, 285
Teste de integração, 183
Abuso intencional, 239
Interação, 280-81, 290
Hub-and-spoke, 280–81 ponto
a ponto, 280
Publicar e assinar, 281
Requisitos de integração interna, 285
Sistema de detecção de intrusão (IDS), 240, 257
Sistema de prevenção de intrusão (IPS), 239, 240, 257
Ilhas de dados, 249
ISO 15489, 316
ISO 8000, 461
Código do Estado ISO, 354
ÍNDICE • 621
Gerenciamento de problemas, 86– Categorização e, 324

87 governança de TI, 71 ITIL. Conteúdo, 307–8 Qualidade
Consulte Biblioteca de infraestrutura de tecnologia da informação (ITIL) de dados e, 461 Riscos de
JSON. Consulte Notação de objeto JavaScript (JSON) dados e, 418 Definição de,
Princípio ético de justiça/equidade, 58 troca 417 Mecanismos de entrega
de chaves, 227 indicadores chave de para, 439 Diretório de, 429 Análise de
desempenho (KPIs), 343 valor-chave, 144 banco impacto de, 441–43 Importância de,
de dados de pares de valores-chave, 188 Kimball, 417–19 Integração de, 439 Gerenciado
Ralph, 388 agrupamento K-Means, 514 ambiente para, 436 Gerenciamento
conhecimento, 18 Kohonen M, 508 Kotter , John de, 308 Repositório para, 426, 440
P., 578, 581, 582, 584, 586, 593 Projeto de Modelo de repositório para, 437 Escopo
arquitetura lambda, 181 Latência, 275 Leis de de, 434 Fontes de, 425–26 Tipos de,
mudança, 574 Manifesto de dados do líder, O, 31, 422–24 Não confiáveis, 60 Dados não
450 Liderança, 588 Alinhamento de liderança, 560 Dados estruturados e, 307, 424–25 Usos de,
mestres jurídicos, 367 Abuso de privilégios de banco de 440 Arquitetura de metadados, 431,
dados legítimos, 238–39 Conformidade de contratos de 433 Centralizado, 431 Distribuído, 432
licenciamento, 213 Gerenciamento de ciclo de vida, 41, Ambiente de metadados, 444
323 Lista, 353–54 Manual de litígios, 336 Processos de Governança de metadados, 445
carregamento, 274, 401 Dados mestre de localização, Iniciativas de metadados, 445 Alavancagem
368 Envio de log versus espelhamento, 192 Nomes de de metadados, 420 Sistema de gerenciamento
dados lógicos, 161 Cenário de CEO solitário, 587 de metadados, 436 Ferramentas de gerenciamento
Sistemas de acoplamento fraco, 177 Loshin, David, 351 de metadados, 440 Registros de metadados
Comitê de baixa credibilidade, 587 Aprendizado de (MDR), 210 Padrão de registro de metadados,
máquina, 506–7, 507 Catálogo legível por máquina, 331 424 Repositório de metadados, 402 Metamodelo
Hacker malicioso, 242 Malware, 242 Hospedagem de de repositório de metadados, 437 Modelo de
banco de dados gerenciada, 178 Ciclo de vida de repositório de metadados, 258, 296, 436–37
gerenciamento, 316 Gerentes, 586 Ferramentas de Requisitos de metadados, 435–36 Padrões de
gerenciamento de mapeamento, 429 Processo de metadados, 437, 446 Armazenamentos de
mapeamento, 275 MapQuest, 189 MapReduce, 176 metadados, 430 Estratégia de metadados, 434
MARC. Consulte Tempo de mercado do catálogo legível Fases, 435 Avaliação de risco e 444 Metadados
por máquina, 57 Martin, James, 109 Mashups, 511 tags, 443 Metadados, 447 M etrics, 94, 259
Processamento paralelo em massa (MPP), 517, 518–19 Proteção de dados, 261 Segurança, 259–60
Dados mestre, 347–48, 357 Conscientização sobre segurança, 260
Vocabulário microcontrolado, 311 Microgerenciamento,
590 Visualizações enganosas, 57 Síndrome de missão
cumprida, 581 Modelos e diagramas Clareza de, 116–17
Dados de risco moderado (MRD ), 224 MOLAP. Consulte
Autenticação de monitoramento de processamento
analítico online multidimensional, 253 Morris, Henry,
405 Tecnologias de banco de dados multidimensional,
185 Multidimensional eXpression, 185 Processamento
analítico online multidimensional, 407 Replicação
multimestre, 191 Banco de dados multimídia, 187 Banco
de dados multitemporal, 185 Nacional Modelo de
troca de informações (NIEM), 286 Modelo quase em
tempo real, 295 Dados quase em tempo real, 394
Administradores de armazenamento de rede (NSAs), 196
Drivers de negócios e, 349

Política de governança e, 373
Gerenciamento de ID de dados mestre,
365 Integração de dados mestre, 369
Gerenciamento de dados mestre (MDM), 70, 359–61, 370–71, 372 Objetivos
de, 349–50 Ferramentas e técnicas de, 375 Arquitetura de
compartilhamento de dados mestre, 370, 376 Correspondência.
Consulte Identificação do candidato Fluxos de trabalho correspondentes,
364 Monitoramento de mídia, 507 Dados médicos sensíveis, 237 Menlo
Report, 52 Interação de mensagens, 394 Metadados, 19, 27, 46, 221, 417
622 • DMBOK2
Taxonomia de rede, 313 PIPEDA. Veja Proteção de Informações Pessoais e Eletrônicas

Dispositivo de auditoria baseado em rede, 254 Ato de Documentação
Zona neutra, 575 NIST estrutura de Pivot, 407 Atividade de
gerenciamento de risco, 225 Nó, 172 Banco de planejamento, 38 PMO.
dados não relacional, 186 NoSQL, 124, 129, 130, Consulte POC do escritório de gerenciamento de
136, 137, 143, 144, 152, 154, 165, 188, 196, 334 projetos. Veja Prova de conceito Modelo de
Nulidade, 165 Ofuscação de dados, 60, 227, 228 Objeto para processamento interação ponto a ponto, 280 Políticas e
de dados pessoais, 54 Observabilidade, 603 OCM. Consulte manipulação de conteúdo, 324 Política de
Gerenciamento de mudanças organizacionais (OMC) segurança de dados, 247 Governança política, 73
Polihierarquia, 313 Portabilidade, 54
Algoritmos preditivos, 59 Análise preditiva, 508–
9, 515 Linguagem de marcação de modelo
preditivo (PMML), 521 modelos preditivos, 514
Software OCR, 330 ambientes de pré-produção, 182 análises
ODBC. Consulte OLAP de Conectividade de Banco prescritivas, 509 preservação, 319 PRISM, 161
de Dados Aberto. Consulte OLTP de processamento lei de privacidade canadense, 54–55 criptografia de chave privada,
analítico online. Consulte Processamento de transações online (OLTP) 227 privilégios banco de dados legítimo, 238–39 não autorizado,
Processamento analítico online, 405 Dados 239 DBAs procedurais , 174 Controles de processo, 282 Dados do
online Usos éticos de, 56 Liberdade de produto em sistemas de execução de fabricação (MES), 368
expressão online, 56 Processamento Gerenciamento de dados do produto (PDM), 368 Gerenciamento
de transações online (OLTP), 189 Ontologia, do ciclo de vida do produto (PLM), 367 DBA de produção, 173, 174
102, 314, 355 Conectividade de banco de dados aberto, Ambiente de produção, 182 Escritório de gerenciamento de
172 Padrão do Open Geospatial Consortium, 187 projetos, 84 Prova de conceito, 195 Dados de referência
Estrutura operacional, 71 Atividade operacional , 38 proprietários, 356 Políticas e leis públicas, 53 Criptografia de chave
Análises operacionais, 510 Armazenamento de dados pública, 227 Modelo de publicação e assinatura, 281 Purga, 191
operacionais (ODS), 392 Metadados operacionais, 423 Certificação de garantia de qualidade, 173 Teste de garantia
Relatórios operacionais, 387, 395, 404 Dados de de qualidade (QA), 183 Qual ity data Alta, 473–74 Métricas
orquestração, 291 Processo de orquestração, 282 para, 487–88 Dados de auditoria que podem ser consultados, 408
Mudança cultural da organização e, 119 Centrado em Controle de acesso em nível de consulta, 238 RACI. Consulte
dados, 73 Organização para co-econômico operação e Responsável, Responsável, Consultado e Informado
desenvolvimento (OCDE), 53 Comportamento
organizacional, 92 Gerenciamento de mudança
organizacional (OCM), 85–86 Organizações e mudança
cultural, 263, 297 Terceirização e segurança de dados,
264 OWL. Consulte W3C Web Ontology Language
Ownership of data, 56 Party master data, 366–67
Password, 234, 257 Payment Card Industry Data Security Standard (PCI-
DSS), 87,
237, 247
obrigações contratuais PCI, 236 PCI-DSS.
Consulte Padrão de segurança de dados do setor de cartões de pagamento (PCI-
DSS) RDBMS. Consulte Sistema de gerenciamento de banco de dados
Métricas de desempenho, 119–23 relacional (RDBMS)
Testes de desempenho, 183 Perímetro, RDF. Consulte Estrutura de descrição de recursos (RDF)
230 Método de mascaramento de Categoria de legibilidade, 166
dados persistente, 227 Dados pessoais, 54 Avaliação de prontidão, 210 Really
Informações pessoais de saúde (PHI), 237 Simple Syndication (RSS), 309 Dados em tempo
Proteção de informações pessoais e eletrônica real, 394 Fluxos de integração de dados em tempo
real, 292 Solução de processamento de dados em
Lei de Documentação, 49 tempo real, 293 Sincronização de dados em tempo
Informações pessoais privadas (PPI), 236 real, 277–78 Qualidade de registro, 342 Registro
PGP (Privacidade Muito Boa), 227 sistema de, 358 registros, 315 gerenciamento de
Phishing, 242 registros, 305, 317–18, 323, 332 documentos
Ativos físicos, 23 eletrônicos e, 318 indicadores-chave de desempenho
Nomes de dados físicos, 161 (KPIs) e, 343
Listas de escolha, 311
ÍNDICE • 623
Modelo de maturidade para, 338-39 SAN. Consulte Storage area network

Princípios de, 306 Sandbox, 184 Sarbanes-Oxley Act, 30,
Tipos de recuperação, 192 49, 71, 254, 316 Scaling. Consulte Data scaling
Redigindo dados, 60 Scanning repositories, 439 Schema, 172 Schema.org,
Dados mestre e de referência, 46 336 Scheme category, 165 Search engine optimization
Dados de referência, 351, 350-57 (SEO), 321, 324 Security Breach of Information Acts,
Mudança e, 376-77 236 Security compliance managers, 253 Securitymetrics,
Geoestatística, 356 259–60 Security patches, 258 Conformidade com a
Indústria, 356 política de segurança, 255–56 Dados de restrições de
Ontologias e, 355 segurança, 234–37 Avaliação de riscos de segurança, 250
Proprietário, 356 Mapas auto-organizados, 508 Modelagem semântica, 321
Padrão, 357 Pesquisa semântica, 321 Dados semiestruturados, 322
Estrutura, 353 Dados confidenciais, 221–22, 325 Sentimento análise,
Taxonomias em, 355 507 equipes de administração de servidor, 205 virtualização
Gerenciamento de dados de referência, 430 de servidor, 178 contas de serviço, 239–40 acordos de
Conjuntos de dados de referência nível de serviço (SLAs), 203, 412, 483–84 registro de
Avaliação de, 373 serviço, 430 arquitetura baseada em serviços (SBA), 505–
Governança e, 375 Diretórios 6 processo de fragmentação, 193 Contas compartilhadas,
de referência, 368 Dados 240 Tecnologias de banco de dados sem compartilhamento,
regulados, 236 Informações 518 Ciclo Shewhart/Deming, 462 Sistema de organização
reguladas, 248 Classificação de conhecimento simples (SKOS), 335 Regulamentos de
regulatória, 252 Conformidade uma única família, 236–37 SKOS. Consulte SLAs de
regulatória, 87 Governança de dados sistema de organização de conhecimento simples.
e, 70 Perguntas sobre, 87 Consulte Acordos de nível de serviço Slice-and-dice, 406
Requisitos regulatórios e segurança SMART, 32 Smartphone, 602 Engenharia social, 242
de dados, 246 Risco regulatório, 254 Transformações de Políticas de mídia social, 324 Sites de redes sociais, 244 Sistema
reificação , 103 Relacionamento de termos relacionados, 312 social, 601 Ameaças sociais, 242 Software como serviço (SaaS),
Banco de dados relacional, 185 Sistema de gerenciamento de 285 Configuração de software gerenciamento (SCM), 199 processo
banco de dados relacional (RDBMS), 185 OLAP relacional, de teste de software, 207 unidades de estado sólido (SSDs), 182
407 Vantagem relativa, 602 Gerenciamento de versão, 399 Solvência II, 30, 87 mapeamento de origem para destino, 396
Remediação, 397 Replicação, 191 Padrões de replicação Envio de log, Sousa, Ryan, 386 Spam, 244–45 banco de dados espacial, 187
192 Espelhamento, 192 Processo de replicação, 202 Esquema de banco de dados especializado, 188 Hardware especializado, 182
replicação, 193 Soluções de replicação, 278–79 Estratégias de relatórios, Spyware, 243 Ataque de injeção de SQL, 241 Estágios de adoção,
412–13 Verificação de repositório, 439 Análise de requisitos, 155 601–2 Análise de partes interessadas e planejamento de comunicação,
Resiliência, 192 Estrutura de descrição de recursos (RDF), 335 Esquema 606 Padrão, 88 Linguagens de marcação padrão, 333–34 Dados de
de estrutura de descrição de recursos (RDFS), 314 Responsável, referência padrão, 357 Padronização, 362 Categoria de padrões, 165
Responsável, Consultado , e Informado, 264 Recuperar métricas de Padrões , segurança de dados, 245, 248 esquema em estrela, 388
resposta ou desempenho, 414–17 Direito de ser esquecido, 56 Risco,
223–24 Avaliação de risco nt, 210 Classificações de risco, 224 Modelo
de risco, 63 Risco de dependência de ferramentas nativas inadequadas
de auditoria, 254 Redução de risco e segurança de dados e, 220 Rivest-
Shamir-Adelman (RSA), 227 Roteiro, 111–13, 409 Rogers, Everett, 599
ROLAP. Consulte Processamento analítico online relacional Grade de
atribuição de função, 250 Hierarquia de atribuição de função, 250 Roll up,
407 Análise de causa raiz, 490 aplicativos SaaS. Consulte também Dados
como Serviço (SaaS)
624 • DMBOK2
"suavização" estatística, 58 Banco de dados triplestore, 188

Controle estatístico de processo, 488-90 cavalo de Tróia, 243
Mordomia, 366, 372, 374 Fonte confiável, 358–59
Rede de área de armazenamento (SAN), 181, 196 Elevação de privilégio não autorizado, 239
Gerenciamento do ambiente de armazenamento, 199–200 Localizadores uniformes de recursos (URLs), 321
Soluções de armazenamento, 279 Abuso não intencional, 239
Modelo de alinhamento estratégico, 33-35 Dados não estruturados, 322
Plano estratégico, 31 Governança e, 342
Estratégia, 31 Gerenciamento de, 342
Transmissão, 394 Metadados para, 307 Análise
Estrutura Strong-Wang, 455 de dados não estruturados, 509 Urgência,
Categoria de estrutura, 165 583, 584 Regras Federais de Processo
Linguagem de consulta estruturada (SQL), 185 Civil dos EUA (FRCP), 318 Requisitos da FTC dos EUA, 236
Cobertura da área de assunto e data warehouse, 413 Classificação da Biblioteca do Congresso dos EUA, 313 Códigos
Discriminador de área de assunto, 107 de Estado do Serviço Postal dos EUA , 354 Lei de Privacidade dos
Modelo de área de assunto, 107 EUA, 53 Teste de aceitação do usuário (UAT), 183 Direitos de
Governança de dados de sustentabilidade e, 91, 94 dados do usuário, 263 Computação de utilitários, 178 Validação,
Distribuição, 308 362 Valor dos dados, 17 Imagem de máquina virtual, 178 Máquinas
Anel sinônimo, 312 virtuais (VMs), 184 Virtualização, 177–78 Vírus . controlado, 311
Banco de dados do sistema, 201 Gerenciamento de vocabulário. Consulte também Vocabulário
Ciclo de vida de desenvolvimento do sistema (SDLC), 126, 298 controlado Visualização de vocabulário, 310–11 Vulnerabilidade,
Sistema de registro, 358 223 W3C Web Ontology Language (OWL), 335 Warren, Samuel,
Riscos de segurança do sistema, 238 53 Use seus próprios dispositivos (WYOD), 325 Endereço da Web,
Taxonomia, 312, 355, 397 256 Sites, 92 Hacker de chapéu branco, 242 Desenvolvimento de
Faceta, 313 conteúdo de fluxo de trabalho e, 322 Ferramentas de fluxo de
Facetado, 311 trabalho, 93, 333 Worm, computador, 244 WYOD. Consulte Use
Hierárquico, 312 seus próprios dispositivos (WYOD)
Rede, 313
TCO, 213
Ferramentas de colaboração em equipe, 333
Equipe, construindo um, 589

Metadados técnicos, 423
Prontidão tecnológica, 210
Banco de dados temporal, 185
Gestão de mandato, 311-12
Termos, 311
Dados de teste, 208
Ambiente de teste, 183
Mineração de texto, 507-8
Os quatro As do gerenciamento de segurança de dados, 225
O Regulamento Geral de Proteção de Dados da UE, (GDPR),
54
Dados de terceiros, 202

Ameaças, 223, 242 Sistemas
fortemente acoplados, 177 Tempo, 57
Custo total de propriedade (TCO), 213
Segredos comerciais, 237 Backup de log de
transações, 198 Dump, 198 Processo de
transformação, 273 Gerenciamento de transição.
Consulte também Transição de XMI. Consulte XML de interface de marcação
gerenciamento de mudanças, lista de extensível. Consulte Bancos de dados XML de
verificação para gerenciamento, 576–77 feeds linguagem de marcação extensível, 189 Zachman
de gotejamento, 394 Framework, 102, 103, 104 Zachman, John A., 102

Dama DmBok (Traduzido)

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Dama DmBok (Traduzido)

Enviado por

Direitos autorais:

Formatos disponíveis

Machine Translated by Google

Machine Translated by Google

Patricia Cupoli, MLS, MBA, CCP, CDMP

por seu compromisso vitalício com a profissão de gerenciamento de dados

Editor sénior: Deborah Henderson, CDMP

Design da capa por Lorena Molinari

Primeira impressão 2017

Direitos autorais © 2017 DAMA Internacional

ISBN, Impresso ed. 9781634622349

Número de controle da Biblioteca do Congresso: 2017941854

Capítulo 1: Gerenciamento de Dados_____________________________________________ 17

Capítulo 2: Ética no manuseio de dados ____________________________________ 49

4. Obras Citadas/Recomendadas ____________________________________________________ 65

Capítulo 3: Governança de Dados________________________________________ 67

2.10 Envolver-se no Gerenciamento de Problemas ________________________________________________ 86

4. Diretrizes de Implementação 4.1 _______________________________________________ 93

Capítulo 4: Arquitetura de Dados_____________________________________________ 97

Diretrizes de Implementação ____________________________________________________ 117

7. Trabalhos Citados / Recomendados ____________________________________________ 120

Capítulo 5: Modelagem e Design de Dados_____________________________________ 123

2.2 Construir o Modelo de Dados _____________________________________________________________ 153

Dados 6. Trabalhos Citados / Recomendados _____________________________________________ 166

Capítulo 6: Armazenamento de dados e operações _____________________________ 169

Capítulo 7: Segurança de Dados__________________________________________ 217

2. Atividades _____________________________________________________________ 245

Capítulo 8: Integração e Interoperabilidade de Dados______________________ 269

5. Diretrizes de Implementação _______________________________________________ 296

Capítulo 9: Gerenciamento de Documentos e Conteúdo_______________________ 303

Capítulo 10: Dados mestre e de referência _____________________________ 347

4.3 Gerenciar Alteração de Dados de Referência ______________________________________________ 376

Capítulo 11: Data Warehousing e Business Intelligence_______________ 381

Capítulo 12: Gerenciamento de Metadados ________________________________ 417

2.4 Criar e Manter Metadados________________________________________________ 438

4. Técnicas ____________________________________________________________ 441

7. Trabalhos Citados / Recomendados _____________________________________________ 448

Capítulo 13: Qualidade de Dados _______________________________________________ 449

4. Técnicas ____________________________________________________________ 486

Diretrizes de Implementação _______________________________________________ 490

7. Trabalhos Citados / Recomendados ____________________________________________ 494

Capítulo 14: Big Data e Ciência de Dados ______________________________ 497

7. Trabalhos Citados / Recomendados ____________________________________________ 528

Capítulo 15: Avaliação da Maturidade do Gerenciamento de Dados __________________ 531

3. Ferramentas _________________________________________________________________ 545

Capítulo 16: Organização de Gerenciamento de Dados e Expectativas de Função _______ 551

Capítulo 17: Gerenciamento de Dados e Gerenciamento de Mudanças Organizacionais __ 573

5. Processo de Oito Estágios de Kotter para Grandes Mudanças ______________________________ 582

6. A Fórmula para a Mudança _________________________________________________ 7. Difusão das 598

8.1 Senso de Urgência/Insatisfação 8.2 ____________________________________________ 604

Gerenciamento de Dados __________________________________ 605

Agradecimentos ___________________________________________________ 611

Figura 54 Diagrama de contexto: armazenamento de dados e operações _____________________________________________170

Figura 108 Modelo Operacional da Rede ___________________________________________________________ 554

Tabela 11 Modelo de Modelo de Dados Scorecard® _____________________________________________________________ 164

Corpo de Conhecimento (DAMA-DMBOK2). Desde a publicação da primeira edição em 2009,

desenvolvimentos ocorreram no campo da gestão de dados. A Governança de Dados se tornou um padrão

quantidade de dados e informações produzidos como parte de nossas vidas diárias.

• Os diagramas de contexto para todas as Áreas de Conhecimento foram aprimorados e atualizados.

a todos os aspectos do gerenciamento de dados (Capítulo 2).

17 e incorporados aos capítulos da Área de Conhecimento.

Sue Geuens Laura Sebastian Coleman

Presidente Diretor de Publicações

DAMA Internacional DAMA Internacional

planejamento, coordenação e comprometimento. Exige gestão e liderança.

de dados, estrategistas de dados, diretores de dados).