Bergson Lopes Rêgo - Gestão e Governança de Dados_ Promovendo dados como ativo de valor nas empresas-BRASPORT (2013)

Prévia do material em texto

Copyright© 2013 por Brasport Livros e Multimídia Ltda.
Todos os direitos reservados. Nenhuma parte deste livro poderá ser reproduzida, sob
qualquer meio, especialmente em fotocópia (xerox), sem a permissão, por escrito, da
Editora.
Editor: Sergio Martins de Oliveira
Diretora Editorial: Rosa Maria Oliveira de Queiroz
Assistente de Produção: Marina dos Anjos Martins de Oliveira
Revisão de Texto: Maria Inês Galvão
Editoração Eletrônica: SBNigri Artes e Textos Ltda.
Capa: Trama Criações
Produçao de e-pub: SBNigri Artes e Textos Ltda.
 
Técnica e muita atenção foram empregadas na produção deste livro. Porém, erros de
digitação e/ou impressão podem ocorrer. Qualquer dúvida, inclusive de conceito,
solicitamos enviar mensagem para brasport@brasport.com.br, para que nossa equipe,
juntamente com o autor, possa esclarecer. A Brasport e o(s) autor(es) não assumem
qualquer responsabilidade por eventuais danos ou perdas a pessoas ou bens,
originados do uso deste livro.
 
ISBN Digital: 978-85-7452-629-4
 
BRASPORT Livros e Multimídia Ltda.
Rua Pardal Mallet, 23 – Tijuca
20270-280 Rio de Janeiro-RJ
Tels. Fax: (21) 2568.1415/2568.1507
 
e-mails:
marketing@brasport.com.br
vendas@brasport.com.br
editorial@brasport.com.br
mailto:brasport@brasport.com.br
mailto:marketing@brasport.com.br
mailto:vendas@brasport.com.br
mailto:editorial@brasport.com.br
 
site: www.brasport.com.br
 
Filial
Av. Paulista, 807 – conj. 915
01311-100 – São Paulo-SP
Tel. Fax (11): 3287.1752
e-mail: �lialsp@brasport.com.br
http://www.brasport.com.br/
mailto:filialsp@brasport.com.br
Ao meu filho Breno, meu orgulho, melhor amigo e
pessoa mais importante da minha vida.
A minha esposa Emanuella, pelo apoio e incentivo
sempre presente.
Aos meus pais, Manoel e Joana D’arc, por me
passarem os valores éticos e de respeito ao próximo.
Agradecimentos
Este trabalho não seria possível sem a participação de vários pro�ssionais
que direta ou indiretamente in�uenciaram na construção dos textos deste
livro, dentre os quais agradeço:
 
À equipe da editora Brasport, que acreditou na importância deste
trabalho para as comunidades de Gestão de Dados e Gestão de
Negócios no Brasil.
À DAMA® – Data Management International, pelo apoio e pelas
permissões dadas a este projeto.
Aos atuais dirigentes do capítulo DAMA® Brasil: Hermann Dagys,
Eduardo Godoy, Osvaldo Alvarenga e Evandro Lima, por
disseminarem a Gestão e Governança de Dados em âmbito nacional e
internacional, e, em especial, a Rossano Tavares, atual presidente deste
capítulo.
À IAIDQ (International Association for Information and Data Quality),
por disseminar a Qualidade de Dados nas organizações e, em especial,
a Rogério Carosi, principal voluntário da IAIDQ na América Latina,
pelas informações sobre esta instituição.
À associação QIBRAS® (Qualidade da Informação Brasil), por
disseminar a Qualidade de Dados nas organizações brasileiras e
também pelas informações sobre a instituição, mencionada no capítulo
13 deste livro.
Ao Aurélio Vinícius Roscoe Vieira, por ter me dado a oportunidade de
começar a atuar na área de Administração de Dados há vinte anos no
Arsenal de Marinha do Rio de Janeiro – AMRJ. Sem esta oportunidade,
certamente este livro não existiria.
Aos colegas do time de trabalho atual e demais colegas que já atuaram
diretamente comigo. As lições aprendidas, experiências e convívio
foram fundamentais para construção deste livro.
A todos os alunos que já frequentaram os meus treinamentos de Gestão
de Dados. Suas experiências, dúvidas e questionamentos também
foram fundamentais para estabelecer o conteúdo deste livro.
A toda a comunidade de Gestão de Dados, por fazer as coisas
acontecerem e também por fazer a diferença em nossa sociedade.
Por �m, aos críticos do meu trabalho – a�nal, as críticas, sejam elas
construtivas ou não, são fundamentais para o desenvolvimento do ser
humano como pessoa e pro�ssional.
Sobre o Autor
Bergson Lopes Rêgo é o principal idealizador e multiplicador da �loso�a
da “Gestão de Dados Moderna” no Brasil e presta regularmente
treinamentos e palestras sobre o tema.
Conduziu e participou de projetos para implantação de áreas de
Administração e Gestão de Dados em empresas de grande porte nos
segmentos: Energia, Óleo & Gás, Governo, Financeiro, Seguros, Construção
Civil e Indústria.
Possui experiência de vinte anos na área de Tecnologia da Informação. No
decorrer da carreira já ocupou várias funções, entre elas: Desenvolvedor,
Analista de Sistemas, Administrador de Dados, Gerente de Projetos, Líder
de Equipe e Consultor. Nos últimos treze anos tem atuado diretamente em
atividades relacionadas à Gestão e Governança de Dados.
Em 2001, fundou a Blensson & Blonsson Consultoria, empresa voltada à
prestação de serviços de consultoria e treinamentos ligados à área de Gestão
de Dados. Já treinou pro�ssionais das mais diversas áreas e segmentos de
atuação no Brasil.
Desde 2011, é um voluntário ativo junto ao chapter Brasil da DAMA® –
Data Management Association International, exercendo a função de Diretor
de Estudos Técnicos, sendo um dos responsáveis pela revisão técnica da
tradução do guia DAMA-DMBOK® para a língua portuguesa.
Nos últimos anos também tem se dedicado à publicação de artigos técnicos
e conteúdo sobre Gestão e Governança de Dados. Bergson já publicou
dezenas de artigos distribuídos nos canais: TI Inside e DevMedia.
É certi�cado PMP (Project Management Professional) pelo PMI (Project
Management Institute), principal organização mundial responsável pelo
desenvolvimento de práticas e pro�ssionais em Gerenciamento de Projetos.
Graduado em Informática pela FACHA, possui MBA em Gerência
Estratégica da Informação e também em Gerência de Projetos (Master in
Project Management), ambos pela Universidade Federal do Rio de Janeiro
(UFRJ).
Para entrar em contato com o autor, utilize os seguintes endereços:
Website: www.bergsonlopes.com.br
Email: contato@bergsonlopes.com.br
Skype: bergson.lopes
Twitter: BergsonL
LinkedIn: http://www.linkedin.com/in/bergsonlopes
http://www.bergsonlopes.com.br/
mailto:contato@bergsonlopes.com.br
http://www.linkedin.com/in/bergsonlopes
Nota do Autor
Escrever um livro que tem por objetivo introduzir uma disciplina que
ainda se encontra em estágios iniciais de adoção no Brasil não é uma tarefa
fácil.
Os países mais maduros no uso da disciplina de Gestão de Dados possuem
dezenas de publicações especializadas sobre o assunto. Já aqui no Brasil, a
carência de publicações nacionais dedicadas exclusivamente ao assunto é
notória.
Certamente, esta é umas das principais razões que contribuem para o
atraso no desenvolvimento desta disciplina no nosso país. A constatação
deste atraso foi a principal razão que me convenceu da necessidade de
escrever este livro.
O conteúdo deste livro é introdutório e tem como principal propósito levar
aos leitores os principais conceitos e propostas da Gestão de Dados que
podem ser aplicados de forma imediata nas empresas brasileiras. A Gestão
de Dados se propõe a fornecer subsídios para que as empresas realmente
utilizem os dados e as informações como ativos de valor estratégico.
Boa parte do conteúdo deste livro fará referência ao guia DAMA-
DMBOK®1 publicado pela DAMA®2 (Data Management International).
Entretanto, o livro não aprofundará o conteúdo de todas as funções vigentes
no guia e também não pretende ser uma simples cópia de conteúdo.
Recomendo a leitura do livro de forma sequencial desde a sua introdução,
onde é passado um breve histórico da utilização da Gestão de Dados no
Brasil.
Logo após, os capítulos iniciais do livro levam ao leitor conceitos básicos
sobre a Gestão de Dados, suas principais características, conceitos,
de�nições, papéis e uma visão geral do principal documento de referência
em Gestão de Dados – o guia DAMA-DMBOK®.
A parte intermediária do livro é dedicada aos estudos das principais
funções em Gestão de Dados, entre elas: Modelagem de Dados, Governança
de Dados, Arquitetura de Dados, Gestão de Dados Mestres e Dados de
Referência eseniores das empresas não costumam patrocinar iniciativas de
Gestão de Dados sem uma previsão detalhada do valor que será investido e também do retorno
�nanceiro sobre este investimento.
Levar adiante tais iniciativas sem esses números, ou então com o retorno �nanceiro menor do que
o gasto previsto, signi�ca que serão prontamente descartadas.
Na visão dos executivos, se o mentor não sabe estimar e nem calcular o retorno da iniciativa, ele
também não merece crédito e con�ança para levá-la adiante. Portanto, evite se basear apenas em
valores intangíveis, sem um ROI estimado. Contudo, chegar a este número mágico sobre o ROI não
é uma tarefa simples.
O levantamento do custo dos problemas ocorridos com a má gestão e a qualidade dos dados
(multas e sanções recebidas ultimamente, por exemplo) é um bom início para se chegar a este valor,
porém cuidado com a venda da iniciativa, pois a implantação da Gestão de Dados não resolverá
instantaneamente todos esses problemas.
Também deve ser levado em conta se a empresa precisa fornecer dados e informações para
agências reguladoras ou se é auditada para veri�cação de conformidades em relação a controles
internos e governança (Basileia, Sarbanes-Oxley, etc.). Nesses casos, a aderência a esses requisitos é
mandatória, devendo ser calculado o impacto (em custo) da não aderência a tais requisitos e
critérios.
Alinhadas a esses custos e características, as informações dos cases aplicados em empresas
similares no mercado também costumam sensibilizar os executivos.
Somente após a veri�cação dos valores tangíveis é que devemos mencionar e, até de certa forma, se
possível, estimar os valores intangíveis. Somados os valores, deve-se submeter a iniciativa para
aprovação.
Atualmente, os recursos tanto �nanceiros como de pessoas nas empresas estão cada vez mais
escassos – em muitos casos, iniciativas com bons retornos são colocadas na �la de espera por falta
de recursos ou então por razões de alinhamento com a estratégia empresarial vigente. Portanto,
atenção com as características a seguir:
Ter um planejamento onde o custo da iniciativa é menor que o retorno também não signi�ca
que esta será aprovada.
Igualdade de custo: caso a empresa perca cem milhões de reais em dez anos devido à má
gestão e à qualidade dos dados manipulados, porém gaste os mesmos cem milhões ou mais no
decorrer dos dez anos seguintes para reverter esse cenário, não haverá retorno �nanceiro
algum nessa iniciativa. Ou seja, provavelmente a iniciativa não será levada adiante.
Além disso, vale ressaltar que os benefícios não são atingidos em sua totalidade logo após a
implantação da Gestão de Dados nas empresas, e sua curva (planejada) deve ser considerada na
avaliação do investimento. A �gura a seguir mostra um exemplo de custos do projeto e custos
operacionais da implantação da Gestão de Dados em uma empresa.
Apesar dos benefícios começarem a aparecer durante a implantação do projeto, eles só foram
atingidos totalmente depois de alguns anos após a sua conclusão.
Figura 2.3 – Exemplo de custos do projeto x custos operacionais e benefícios obtidos com a Gestão de Dados
Apesar de a maioria dos benefícios ser diferente em cada empresa, alguns poucos ainda são
comuns à maioria. Seguem os principais ganhos que normalmente são obtidos em todas as
organizações que começam a adotar a Gestão de Dados em seu cotidiano. Muitos deles são
intangíveis.
Mudança de cultura. Dados e informações passam a ser reconhecidos como um importante
ativo estratégico nas empresas.
Melhor alinhamento entre as áreas de TI e de negócio. Este alinhamento é uma premissa
fundamental para o bom funcionamento da Gestão de Dados. Com isso, outras áreas como,
por exemplo, de mapeamento de processos e de desenvolvimento de sistemas podem se
bene�ciar de um alinhamento já iniciado.
A gestão das operações de captura, armazenamento, proteção, planejamento, controle e
garantia da qualidade dos ativos de dados são centralizadas em uma única disciplina: a
Gestão de Dados. Com a centralização das operações, os custos tendem a cair, pois os recursos
são mais bem aproveitados e a ocorrência de retrabalho diminui.
Criação da cultura do uso de indicadores de processo, qualidade e desempenho de dados e
informações. Esta cultura é importante para manter a Gestão de Dados alinhada à estratégia
da empresa.
Conhecimento de dados e informações utilizados através da adoção de um vocabulário
único sobre as de�nições dos dados que circulam na empresa. Dessa forma, há uma melhor
disseminação do conhecimento entre as pessoas – passagem do capital intelectual para o capital
estrutural.
Entendimento das principais necessidades de dados e informações da empresa, fornecendo
um importante subsídio para estabelecer o planejamento para absorção, criação e/ou
transformação de novos dados e informações para a empresa. Dessa forma, a empresa tem
condições de de�nir o que realmente é importante em relação à utilização de dados e
informações e estabelecer prioridades em relação às futuras implementações e mudanças.
Redução no tempo e no custo de desenvolvimento de novos sistemas e aplicações. Esta
redução é obtida devido à adoção de arquiteturas de dados mais estáveis e processos que
envolvem a criação e alteração de modelos de dados.
Redução dos riscos e falhas no desenvolvimento dos sistemas e aplicações.
Eliminação ou redução drástica na quantidade de informações redundantes, contribuindo
para reduzir os esforços em manter íntegras as informações que antes eram redundantes.
Estabelecimento de mecanismos formais de segurança, acesso e disponibilização de dados e
informações a quem realmente necessita. Tudo isso de forma rápida e segura.
Reutilização de dados corporativos e/ou compartilhados, através do gerenciamento dos
dados mestres e dados de referência, contribuindo dessa forma para a melhoria da
qualidade dos dados e também reduzindo os esforços, tempos e custos das aplicações.
Melhoria na qualidade e con�abilidade dos dados e informações através do uso de dados
cada vez mais claros, precisos, íntegros, integrados, pertinentes e oportunos.
Os dados manipulados nas empresas passam a ser realmente governados. Ou seja, o
exercício de autoridade e controle (planejamento, monitoramento e execução) sobre a gestão de
ativos de dados é real. Isso é fundamental para a empresa se adaptar a regulamentações
externas como a lei Sarbanes-Oxley e Basileia.
Aumento da produtividade das pessoas que utilizam os dados e as informações.
2.5. Gestão de Dados ou Administração de Dados – Qual o termo
correto?
Quando a disciplina Administração de Dados começou a ser adotada no Brasil, e durante muito
tempo após sua implementação, uma dúvida comum entre as pessoas era a diferenciação entre os
papéis do AD (Administrador de Dados) e do DBA (Administrador de Banco de Dados). Com a
evolução da maturidade e a adoção da Administração de Dados nas empresas essa dúvida começou
a deixar de existir. Mesmo assim, algumas empresas ainda insistem em adotar um papel único para a
atuação dos dois per�s, mesmo sendo totalmente diferentes.
A principal dúvida na área de dados se refere atualmente à utilização de dois conceitos:
Administração de Dados e Gestão de Dados. A�nal, qual o termo correto?
Gestão de Dados é um conceito mais recente e também mais amplo do que Administração de
Dados. Apesar de a matéria-prima ser a mesma, o dado, e ambas estarem ligadas à qualidade de
dados e informações, na prática a Gestão de Dados difere da Administração de Dados
principalmente porque a Gestão de Dados tem uma proposta de atuação mais abrangente,
incorporando atividades que antes não eram previstas pelas áreas de Administração de Dados.
De forma geral, a Administração de Dados foca especi�camente no controle, na qualidade e no
gerenciamento das estruturas dos metadados da organização. Geralmente esses metadados estão
representados em modelos de dados. Basicamente, os processos de Administração de Dados podem
ser resumidos em:
Manter modelos de dados armazenados em repositórios, disponibilizando-osaos interessados
quando necessário.
Modelar ou apoiar a construção e/ou alteração dos modelos de dados.
Homologar os modelos de dados produzidos por analistas e/ou outros Administradores de
Dados.
Implementar as estruturas de dados nos bancos de dados após a homologação dos modelos de
dados produzidos.
Disseminar conceitos existentes nos modelos de dados mantidos pela equipe.
Processos internos para a própria equipe de Administração de Dados, como criar mnemônicos
e auditar repositório de modelos de dados.
Infelizmente, o modelo de trabalho de Administração de Dados adotado por muitas empresas
brasileiras ainda é baseado em uma única “receita de bolo” implantada com o apoio de poucas
consultorias no mercado, geralmente com seus processos ligados a uma ferramenta de Modelagem
de Dados especí�ca. Outras empresas possuem seus modelos de trabalho baseados nas publicações
americanas da década de 90, tais como “Data Administration Standards & Techniques” e “Manual
For Data Administration”.
Com raras exceções, onde a área de Administração de Dados está localizada dentro da área de
negócio da empresa, geralmente a área de TI é a responsável por executar as funções de
Administração de Dados. Nesses casos, nem sempre a interação entre a TI, representada pela área de
Administração de Dados, e a área de negócios da empresa é feita ou pelo menos incentivada.
A pouca �exibilização em seus processos e o distanciamento das novas tecnologias e da área de
negócio corroboraram para o declínio da Administração de Dados nas organizações.
Apesar de extremamente importante e fundamental para manter uma organização mínima sobre o
acervo dos dados e metadados, o escopo de atuação da Administração de Dados não vem dando
mais o retorno desejado pelas organizações. En�m, já passou da hora da Administração de Dados se
reinventar. O termo “Administração de Dados” está em desuso e atualmente seu nome pode gerar
inclusive ojeriza em algumas empresas. Esta frase pode parecer um pouco forte, mas, se �zermos
uma análise criteriosa do problema, fatalmente chegaremos à mesma conclusão: a Administração de
Dados gere os metadados e não os dados das organizações.
Já a Gestão de Dados se propõe a gerir não somente os metadados (e seus modelos de dados) da
organização, como também fazer a gestão completa dos dados, incluindo todo o seu ciclo de vida e
funções antes ignoradas ou não tão bem atendidas pela Administração de Dados, tais como
governança dos dados, armazenamento, integração, gestão dos dados mestres e de referência,
segurança, qualidade dos dados e Gestão de Dados não estruturados. Em suma, a Gestão de Dados
chegou para administrar os metadados e também os dados das empresas.
Outra diferença trivial é a responsabilidade pela gestão dos recursos de dados. A Gestão de Dados
é compartilhada entre pro�ssionais de Gestão de Dados da TI e os Gestores de Dados de Negócio,
que representam os interesses coletivos dos produtores de dados e dos consumidores de informação.
O gerenciamento dessas funções é apoiado pelo guia DAMA-DMBOK®, guia de boas práticas
coordenadas com funções integradas para o gerenciamento de dados, metadados e ativos de
informação nas organizações.
Conforme já mencionado neste livro, a versão atual do guia DAMA-DMBOK® abrange o
gerenciamento de dez funções integradas: Governança de Dados, Arquitetura de Dados,
desenvolvimento dos dados, operações de banco de dados, segurança de dados, dados mestres e de
referência, data warehousing e business intelligence, documentação e conteúdo, metadados e
Qualidade de Dados. Algumas das funções relacionadas nunca entraram no escopo da
Administração de Dados.
Aliado a isso, novas �loso�as de trabalho como a Gestão de Dados Moderna, caracterizada por
uma forma de trabalho mais ágil e proativa focada na conduta comportamental dos pro�ssionais
envolvidos nas funções de Gestão de Dados, ajudam a ter uma visão mais abrangente da empresa,
não focada somente em bancos de dados e tecnologia.
Todos esses instrumentos ajudam a apagar a imagem desgastada da Administração de Dados do
passado e reconhecer a Gestão de Dados como importante meio para gerenciar os ativos de dados e
informações das organizações.
2.6. Mitos sobre a Gestão de Dados
Com o passar do tempo, as áreas e os pro�ssionais de Administração de Dados serão extintos?
Não. A tendência natural é evoluir para trabalhar com escopos de atuação mais abrangentes e
alinhados às estratégias das áreas de negócio das empresas. Este processo de evolução já ocorreu nos
países mais desenvolvidos na área de dados e já está acontecendo em algumas empresas brasileiras.
É a migração da Administração de Dados para a Gestão de Dados.
Já os pro�ssionais de Administração de Dados devem estar atentos a esta mudança. A Gestão de
Dados trouxe à tona a necessidade de novos per�s, ligados à área de negócio das empresas. O
pro�ssional de Gestão de Dados deverá ser versátil, capaz de assimilar rapidamente a adoção de
novos conceitos e tecnologias. Se o Administrador de Dados �car limitado à antiga forma de
trabalho, focada somente nas atividades de modelagem e avaliações de modelos de dados,
certamente ele encontrará di�culdades de alocação em um futuro bem próximo.
A Gestão de Dados deve obrigatoriamente ser adotada em toda a empresa? Todas as áreas devem ser
contempladas?
A melhor prática recomendada é a adoção da Gestão de Dados em toda a empresa. Entretanto, ela
pode ser adotada em contextos locais (áreas do negócio ou de projetos especí�cos), sem uma
aplicação na organização como um todo.
Vale ressaltar que, neste caso, o benefício para o negócio da empresa será menor, pois uma das
principais vantagens da Gestão de Dados é estabelecer um tratamento único e corporativo sobre os
dados manipulados na empresa.
Quando implantamos a Gestão de Dados na empresa devemos implantar todas as funções
recomendadas pelo guia DAMA-DMBOK®?
Não. O guia é uma coletânea de boas práticas. Dependendo das características das empresas,
algumas práticas podem não ser necessárias, outras podem ser adotadas parcialmente, adaptadas ou
adotadas integralmente. Além disso, pode-se estabelecer uma cadeia de prioridades onde as funções
e atividades mais prioritárias são adotadas de forma incremental.
Implementar a Gestão de Dados em toda a empresa de uma única vez não é uma prática
recomendada. A experiência me mostrou que as iniciativas implantadas em partes e testadas através
de adoções “piloto” foram as iniciativas com maiores índices de sucesso. Portanto, mesmo que a
empresa adote a Gestão de Dados como um todo, durante um bom tempo a adoção da disciplina
não será total e sim parcial, devido a uma estratégia de implantação mais coerente com a realidade
das empresas.
Gestão de Dados e Administração de Dados podem conviver juntas?
Sim. Inclusive algumas empresas têm usado este formato em fases iniciais de adoção da Gestão de
Dados, porém deve-se ter em mente que a Administração de Dados é um subconjunto da Gestão de
Dados e, como tal, deve seguir as mesmas diretrizes e estar alinhada com os mesmos objetivos da
Gestão de Dados.
Relembrando: a Administração de Dados geralmente está ligada às atividades de modelagem,
homologação e guarda dos modelos de dados.
3. Papéis Envolvidos na Gestão de Dados
“O único lugar onde o sucesso vem antes do trabalho é no dicionário.”
Albert Einstein
3.1. Tipos de papéis envolvidos
Até pouco tempo atrás, “Administrador de Dados – AD” e “Administrador de Banco de Dados –
DBA” eram os principais e mais conhecidos papéis ligados às atividades de gerenciamento dos dados
nas organizações.
Embora importante, o papel do AD não era mais su�ciente para fazer o alinhamento entre a
tecnologia e as necessidades dos negócios nas empresas. Com o ressurgimento da Gestão de Dados
nas organizações, onde o dado é considerado um dos principais ativos empresariais, novos papéis
surgiram no mercado com o propósito de fazer um melhor alinhamento entre a TI, responsável por
custodiar os dados das empresas, e a área de negócio, realproprietária dos dados que circulam nas
empresas. Atualmente podemos classi�car esses novos papéis em três grupos distintos:
Papéis ligados ao negócio.
Papéis estratégicos.
Papéis técnicos ou de tecnologia.
Este livro abordará os principais papéis que, de forma geral, são adotados nas organizações
brasileiras. Vale ressaltar que, dependendo das características de cada empresa, não haverá espaço
para adoção de alguns papéis, ou até mesmo os papéis relacionados não serão totalmente su�cientes.
O próprio guia DAMA-DMBOK® estabelece uma gama de mais de vinte papéis de atuação em
Gestão de Dados. Além disso, dependendo das características das pessoas e das empresas, uma
mesma pessoa pode atuar em mais de um papel, se necessário.
A �gura a seguir relaciona os tipos e papéis de Gestão de Dados que serão descritos neste livro.
Figura 3.1 – Papéis da Gestão de Dados abordados no livro
3.2. Papéis ligados ao negócio
Todos os papéis deste grupo possuem uma forte atuação dentro da área de negócio nas empresas.
À exceção do Gestor da Informação, todos os demais papéis são relativamente novos e buscam
suprir duas carências que foram fundamentais no passado para levar algumas áreas de
Administração de Dados ao desuso:
A falta de interação com a área de negócio.
A de�nição dos responsáveis diretos pelos dados levando em consideração as reais
necessidades do negócio.
Como a maioria dos papéis é relativamente nova nas empresas, o número de pro�ssionais
quali�cados para exercer as funções disponíveis no mercado ainda é pequeno. Com isso, as
empresas têm buscado formar os pro�ssionais dentro de seus próprios quadros.
Mesmo assim ainda existem algumas dúvidas sobre quais são os requisitos básicos necessários para
selecionar e/ou treinar pro�ssionais para atuarem nesses papéis. De forma geral, devem atender aos
seguintes requisitos:
Formação superior, preferencialmente em áreas ligadas ao negócio da empresa em que o
pro�ssional de Gestão de Dados irá atuar.
Experiência (vivência) anterior nas áreas de negócio onde irá atuar.
Fortes conhecimentos em Gestão Estratégica e Governança de Dados.
Possuir forte visão estratégica.
Conhecimentos avançados em Qualidade.
Conhecimentos de ferramentas de gestão.
Habilidade na comunicação verbal e escrita.
Negociação e gestão de con�itos.
Além dos requisitos básicos, outros são necessários de acordo com os papéis que serão
desempenhados. A relação dos demais requisitos será mencionada adiante, logo após o
detalhamento das principais atividades executadas por cada papel.
3.2.1. Gestor de Dados de Negócio
Também conhecido como Data Steward, o Gestor de Dados de Negócio é o pro�ssional ligado à
área de negócio da empresa. Trabalha e atua como o principal curador dos dados, representando os
interesses da área de negócio em que atua.
O per�l desejado é de uma pessoa especialista na área de negócio onde atua. O pro�ssional
também deve ter conhecimentos avançados em Gestão e Governança de Dados para poder interagir
com os pro�ssionais desta disciplina e com os Gestores da Informação e demais pro�ssionais de
negócio.
Além disso, deve ter pleno domínio sobre a captura de requisitos de informação, regras de negócio
e modelagem conceitual de dados. Entre suas principais tarefas podemos destacar:
Participar dos comitês de Gestão e Governança de Dados que envolvem sua área.
Identi�car e de�nir necessidades de informações locais e corporativas representando os
interesses dos produtores e consumidores de dados da área de negócios.
Propor modelos conceituais de dados respeitando as regras e os padrões da Arquitetura
Corporativa de Dados da empresa.
Garantir a validade e a relevância dos modelos conceituais de dados sob sua responsabilidade.
Ajudar executivos a identi�car e apontar os Gestores das Informações.
Manter valores e signi�cados dos dados de referência.
Identi�car e atuar na resolução de problemas com os dados.
De�nir critérios de qualidade dos dados.
Certi�car-se de que os recursos de dados estão de acordo com as necessidades do negócio,
garantindo a qualidade dos dados e metadados.
Atuar como ponto focal (referência) de negócio perante os demais pro�ssionais de Gestão de
Dados.
3.2.1.1. Principais características para atuar neste papel
Além das características gerais dos papéis de negócio, também são requisitos importantes para
atuar como Gestor de Dados de Negócio:
Conhecimento aprofundado das áreas onde irá atuar.
Conhecimentos avançados em Gestão de Dados. As Certi�cações em Gestão de Dados ajudam
a atestar esses conhecimentos.
Persistência.
Domínio em modelagem conceitual.
Conhecimento de Gerenciamento de Projetos.
Conhecimento de Segurança da Informação.
3.2.2. Coordenadores e gerentes das equipes de Gestão de Dados de Negócio
De forma geral, são pro�ssionais seniores, com conhecimento avançado no ramo de negócio onde
atuam. No passado já atuaram como Administradores de Dados (AD) ou especialistas.
Além de serem os gestores das pessoas, também trabalham como facilitadores para que as suas
equipes consigam cumprir os objetivos estabelecidos. Entre suas principais tarefas podemos
destacar:
Participar de um ou mais comitês de Gestão e Governança de Dados.
Planejar, alocar, distribuir e controlar as tarefas dos membros da equipe.
Administrar os recursos humanos da equipe.
Remover empecilhos que afetem a qualidade e/ou produtividade da equipe.
Liderar projetos sob a responsabilidade da equipe.
3.2.2.1. Principais características para atuar neste papel
Além das características gerais dos papéis de negócio, também são requisitos importantes para
atuar como Coordenador ou Gerente das equipes de Gestão de Dados de Negócio:
Experiência em gestão de equipes multidisciplinares.
Conhecimentos avançados de Gestão de Dados.
Conhecimentos avançados de Gerenciamento de Projetos.
Conhecimentos gerais de Tecnologia.
Visão estratégica.
3.2.3. Gestor da Informação
Pro�ssional de negócio que representa a área proprietária da informação. Na prática, é o “dono”
dos dados. Este pro�ssional está ligado a uma ou mais áreas da empresa. Não costuma possuir per�l
técnico e suas atividades em relação aos dados são apoiadas pelo Gestor de Dados de Negócio.
Apesar de já ser um papel conhecido, de forma geral o Gestor da Informação não era um papel
formalizado antes da adoção da Gestão de Dados nas empresas. Mapeava-se e de�nia-se um gestor
para cada informação e pronto. Não havia uma preocupação em de�nir dentro de uma metodologia
o seu papel, a sua importância, abrangência de atuação e responsabilidades. Entre suas principais
tarefas podemos destacar:
Autorizar o acesso e compartilhamento dos dados e metadados sob sua responsabilidade.
Tomar decisão em relação à correção das inconsistências dos dados sob sua responsabilidade.
Com o apoio do Gestor de Dados de Negócio, de�nir prioridades em relação à aquisição e
utilização de novos dados.
Envolver o Gestor de Dados de Negócio nas atividades que envolvam algum tipo de decisão
acerca do uso dos dados que estão sob sua responsabilidade.
3.2.3.1. Principais características para atuar neste papel
Além das características gerais dos papéis de negócio, também são requisitos importantes para
atuar como Gestor da Informação:
Conhecimento aprofundado da área onde atua.
Conhecimentos de Segurança da Informação.
Comprometimento.
Responsabilidade.
Ser reconhecido de fato como pro�ssional de fácil acesso e disponibilidade.
3.3. Papéis estratégicos
Os papéis deste grupo são novos e aos poucos vêm sendo adotados pelas organizações que estão
em processo de implementação da disciplina Gestão de Dados. Seus principais objetivos são
promover a intermediação entre TI e o negócio e resolver con�itos entre estas áreas nos patamares
táticos e estratégicos.
Como os papéis são novos nas empresas, ainda existem algumas dúvidas sobre quais são os
requisitos básicos necessários para selecionar e/ou treinar pro�ssionais para atuarem nestes papéis.
De forma geral, os pro�ssionais que atuam nestes papéis devem atenderaos seguintes requisitos:
Formação superior, preferencialmente em áreas ligadas ao negócio da empresa ou tecnologia.
Experiência (vivência) anterior em pelo menos umas das áreas onde atuará como mediador.
Fortes conhecimentos em Gestão Estratégica e Governança de Dados.
Possuir forte visão estratégica.
Conhecimentos de ferramentas de gestão.
Habilidade na comunicação verbal e escrita.
Negociação e gestão de con�itos.
Outros requisitos são necessários de acordo com os papéis que serão desempenhados. A relação
dos demais requisitos será mencionada à frente, logo após o detalhamento das principais atividades
executadas por cada papel.
3.3.1. Executivo de Gestão de Dados
O executivo de Gestão de Dados, também conhecido como CDO (Chief Data Officer), atua nos
níveis de direção das organizações e geralmente se reporta ao Presidente ou Vice-Presidente das
organizações. É o responsável direto por gerenciar todas as funções de gestão e Governança de
Dados nas empresas.
Além de atuar nos níveis mais altos da empresa, este papel também tem forte atuação política. Um
bom CDO deve estar familiarizado com este tipo de atuação, para que, com sua in�uência, consiga
quebrar paradigmas e possíveis resistências que as equipes de dados possam enfrentar dentro da
empresa.
O CDO é o principal responsável por, entre outras coisas, fornecer apoio constante às equipes de
Gestão de Dados, de�nir as prioridades estratégicas para a empresa no que tange à utilização dos
dados e informações, identi�car novas oportunidades de negócios relativos aos dados e aperfeiçoar a
geração de receita por meio da utilização dos dados.
Além disso, é o principal responsável pela representação e promoção dos dados como um ativo
estratégico de negócios na esfera executiva da empresa.
Entre suas principais tarefas podemos destacar:
Participar como membro ativo do conselho de Gestão e Governança de Dados, sendo um dos
principais facilitadores deste grupo.
De�nir e acompanhar o andamento da estratégia de Gestão e Governança de Dados adotada na
empresa.
Homologar e aprovar, apoiado por pro�ssionais da área, a metodologia de Gestão e
Governança de Dados da empresa.
Homologar e aprovar, apoiado por pro�ssionais da área, a Arquitetura de Dados adotada pela
empresa.
Representar as equipes de Gestão e Governança de Dados na empresa.
Representar a empresa perante as agências reguladoras e demais entidades externas em
assuntos referentes a dados e informações da empresa.
Patrocinar os projetos de melhoria sob a responsabilidade das equipes de Gestão e Governança
de Dados.
3.3.1.1. Principais características para atuar neste papel
Além das características gerais dos papéis estratégicos, também são requisitos importantes para
atuar como Executivo de Gestão de Dados:
Experiência em gestão de equipes multidisciplinares.
Noções de contabilidade gerencial e custos.
Domínio dos conceitos de arquitetura empresarial.
3.3.2. Gestor Estratégico de Dados
Pro�ssional sênior com profundos conhecimentos de Gestão de Dados e também da área de
negócio da empresa. É a principal referência em Gestão de Dados na organização. É uma espécie de
“Super Data Steward”. Este per�l é fundamental quando a empresa possui áreas de negócio
diferentes e os Gestores de Dados de Negócio não possuem o conhecimento comum de todos os
negócios. Nesses casos, o Gestor Estratégico de Dados também atua como um centralizador de
conhecimento.
O Gestor Estratégico de Dados pode ser alocado tanto no lado da TI quanto no lado do negócio,
porém, não deverá esquecer que sua principal missão, onde estiver situado, é promover o correto
alinhamento das áreas de TI e negócio sob a ótica dos dados utilizados pela empresa. Além disso, é o
principal responsável por propor soluções corporativas, orientar e treinar os demais pro�ssionais de
Gestão de Dados (técnicos e de negócio).
Também atua como consultor apoiando as ações dos Coordenadores/Gerentes e o CDO da
empresa. Entre suas principais tarefas podemos destacar:
Elaborar e, quando necessário, propor mudanças na metodologia de Gestão e Governança de
Dados adotada pela empresa.
Manter a Arquitetura de Dados corporativa da empresa e propor mudanças quando necessário.
Prover de�nições padrões para o vocabulário de Gestão e Governança de Dados, papéis e
outras terminologias adotadas na empresa.
De�nir, analisar e monitorar os indicadores de qualidade das estruturas de dados da
organização.
Propor ações em função dos indicadores analisados.
Participar dos Comitês de Gestão de Dados.
Construir consenso na visão geral sobre a aplicação da Gestão de Dados e disseminar pela
organização os benefícios da Gestão e Governança de Dados.
3.3.2.1. Principais características para atuar neste papel
Além das características gerais dos papéis estratégicos, também são requisitos importantes para
atuar como Gestor Estratégico de Dados:
Conhecimento aprofundado das áreas onde irá atuar.
Conhecimentos avançados de Gestão de Dados. As certi�cações em Gestão de Dados ajudam a
atestar esses conhecimentos.
Sólida experiência em Gestão de Dados. Não há sentido algum em haver Gestores Estratégicos
de Dados juniores nas empresas.
Experiência no uso de ferramentas de qualidade.
Conhecimento avançado de Gerenciamento de Projetos.
Domínio de Modelagem de Dados.
Persistência.
Boa didática.
3.4. Papéis técnicos
De forma geral, grande parte das atividades descritas nos papéis a seguir já era efetuada pelos
papéis AD (Administrador de Dados) e DBA (Administrador de Banco de Dados) na antiga área de
Administração de Dados, ou seja, não há novidade alguma.
Para manter um melhor alinhamento da proposta de atuação e evolução da área de Gestão de
Dados, o papel AD passou a ser denominado “Gestor Técnico de Dados”. Já a adoção do per�l
“Arquiteto de Integração” tornou-se mais evidente após a chegada do paradigma SOA6 pelas
empresas.
Vale ressaltar que, mesmo distantes do negócio, os papéis técnicos da Gestão de Dados são
fundamentais para manter os objetivos desta disciplina nas empresas.
Os papéis técnicos estão situados em geral dentro de TI, mais próximos das pessoas que
desenvolvem as soluções de tecnologia na empresa.
Os papéis técnicos requerem especializações especí�cas dentro de cada área de atuação, porém,
dependendo da forma de atuação da Gestão de Dados na empresa e de similaridades entre alguns
papéis, uma mesma pessoa pode desempenhar mais de um papel dentro de uma equipe de Gestão
Técnica de Dados.
Ao contrário dos papéis estratégicos e de negócio, os papéis técnicos não são tão novos assim.
Contudo, as empresas devem estar atentas aos requisitos básicos para os pro�ssionais atuarem
nesses papéis. Entre eles podemos destacar:
Formação superior, preferencialmente ligada às áreas de TI.
Noções de Modelagem de Dados. O modelo de dados ainda é o principal artefato ligado à
gestão técnica de dados. Não há sentido contratar pro�ssionais para atuar nesta área que não
conheçam as técnicas e os propósitos da Modelagem de Dados.
Experiência anterior em outros papéis ligados à TI.
Fortes conhecimentos de Gestão e Governança de Dados.
Outros requisitos são necessários de acordo com o papel que será desempenhado. A relação dos
outros requisitos será mencionada à frente, logo após o detalhamento das principais atividades
executadas por cada papel.
3.4.1. Coordenadores e gerentes das equipes de Gestão Técnica de Dados
De forma geral, são pro�ssionais seniores com conhecimento técnico em Gestão de Dados. No
passado já atuaram como Administradores de Dados (AD) ou Administradores de Banco de Dados
(DBA).
Além de serem os gestores das pessoas, também trabalham como facilitadores para que as suas
equipes consigam cumprir os objetivos estabelecidos. Entre suas principais tarefas podemos
destacar:
Participar em um ou mais comitês de Gestão de Dados.
Planejar, alocar, distribuir e controlar as tarefas dos membros da equipe.
Administrar os recursos humanos da equipe.
Remover empecilhos que afetem a qualidade e/ou produtividade da equipe.Liderar projetos sob a responsabilidade da equipe.
3.4.1.1. Principais características para atuar neste papel
Além das características gerais dos papéis técnicos, também são requisitos importantes para atuar
como Coordenador ou Gerente das equipes de Gestão Técnica de Dados:
Experiência em gestão de equipes multidisciplinares.
Conhecimentos avançados de Gestão de Dados.
Conhecimentos avançados de Gerenciamento de Projetos.
Conhecimentos gerais de Tecnologia.
Visão estratégica.
3.4.2. Gestor Técnico de Dados
Este per�l vem a ser uma evolução do antigo “Administrador de Dados – AD”. É o principal
responsável pela qualidade das estruturas dos metadados da organização.
Possui conhecimento avançado de técnicas de Modelagem de Dados, utilização de ferramentas de
modelagem, repositório de metadados e demais funções de Gestão de Dados, entre elas:
Governança de Dados, Qualidade de Dados, Gestão de Dados mestres e referência, integração de
dados e segurança da informação. Entre suas principais tarefas podemos destacar:
Acompanhar e orientar as equipes de desenvolvimento durante a Modelagem de Dados
(conceitual lógica e física).
Avaliar os modelos de dados produzidos pelas equipes de desenvolvimento.
Apoiar na busca e utilização de informações corporativas e compartilhadas.
Disseminar os conceitos das entidades representadas nos modelos de dados.
Manter atualizado os repositórios de modelos de dados e metadados.
Propor mudanças na Arquitetura de Dados da empresa.
Realizar estudos sobre a análise de impacto das alterações propostas nos modelos de dados
compartilhados.
Emitir relatórios técnicos e pareceres sobre o uso dos metadados nos âmbitos conceitual e
lógico.
Apoiar os demais pro�ssionais da empresa nas atividades referentes à Qualidade de Dados e
Gestão de Dados mestres e de referência.
Promover no âmbito técnico a importância da Gestão de Dados.
Envolver os demais pro�ssionais (DBA, Arquiteto de Dados) quando necessário.
Apoiar os Gestores Estratégicos de Dados na elaboração e alteração de:
Vocabulário e Glossário Corporativo da empresa.
Metodologia de Gestão e Governança de Dados.
Demais documentos relativos à Gestão de Dados.
3.4.2.1. Principais características para atuar neste papel
Além das características gerais dos papéis técnicos, também são requisitos importantes para atuar
como Gestor Técnico de Dados:
Conhecimentos avançados em Gestão de Dados.
Habilidade no levantamento e na compreensão de requisitos.
Conhecimentos de mapeamento de processos.
Conhecimentos avançados de técnicas de análise e Modelagem de Dados.
Conhecimento intermediário de banco de dados (teoria e uso dos principais objetos).
Habilidades avançadas no uso de ferramentas de Gestão de Dados (ferramentas de modelagem,
repositório de metadados e ativos de TI, ferramentas de Qualidade de Dados, ferramentas
MDM7).
Conhecimento de técnicas de integração de dados.
Habilidades avançadas em comunicação e negociação.
Boa comunicação escrita.
Persistência.
Boa didática.
3.4.3. Administrador dos Repositórios de Metadados
Pro�ssional de TI especialista em repositórios de modelos de dados e metadados. É responsável
direto pela custódia dos metadados e modelos de dados armazenados nessas ferramentas. Entre suas
principais tarefas podemos destacar:
Incluir, excluir e alterar os metadados técnicos e de negócio nos repositórios de metadados
utilizados na organização.
Disponibilizar os metadados armazenados nos repositórios.
Conceder ou excluir acesso aos metadados armazenados nos repositórios.
Orientar os demais pro�ssionais de Gestão de Dados na utilização dos repositórios de
metadados da empresa.
Ser o ponto focal entre a área de Gestão de Dados e os fabricantes de soluções para
armazenamento de modelos de dados e metadados.
3.4.3.1. Principais características para atuar neste papel
Além das características gerais dos papéis técnicos, também são requisitos importantes para atuar
como Administrador de Repositório de Metadados:
Conhecimentos avançados na utilização e administração de repositórios de metadados.
Conhecimento intermediário em banco de dados (teoria e uso dos principais objetos).
Domínio da linguagem SQL.
3.4.4. Projetista de Dados
Pro�ssional especialista em Modelagem de Dados, sendo o principal responsável por construir,
ajustar e re�nar o modelo de dados conforme a técnica de desenvolvimento adotada. Além disso,
trabalha em parceria com o Arquiteto de Integração de Dados para de�nir e representar os
mecanismos de integração que serão utilizados no projeto. Entre suas principais tarefas podemos
destacar:
Criação e alteração dos modelos lógico e físico de dados.
Armazenar modelos de dados propostos nos repositórios.
Encaminhar os modelos de dados criados e/ou alterados para avaliação dos Gestores Técnicos
de Dados.
Envolver os Gestores de Dados (técnicos e de negócio) na construção e validação dos modelos
de dados e mecanismos de consumo de dados especi�cados.
Fazer engenharias reversas para criação de modelos de dados de sistemas legados.
3.4.4.1. Principais características para atuar neste papel
Além das características gerais dos papéis técnicos, também são requisitos importantes para atuar
como Projetista de Dados:
Habilidade no levantamento e na compreensão de requisitos.
Conhecimentos avançados de técnicas de análise e Modelagem de Dados.
Conhecimento intermediário de banco de dados (teoria e uso dos principais objetos).
Conhecimento de tecnologia de integração de dados.
Habilidade na utilização de ferramentas CASE8 e/ou ferramentas de Modelagem de Dados.
Conhecimento de técnicas de integração de dados.
Habilidades avançadas em comunicação e negociação.
3.4.5. Administrador de Banco de Dados (DBA)
Pro�ssional de TI com per�l bastante técnico. Especialista em sowares de gerenciamento de
bancos de dados.
Geralmente este per�l é dividido em dois: DBA de aplicação e DBA de infraestrutura, também
conhecido como DBA de produção.
O primeiro é responsável por elaborar e/ou validar o projeto físico das aplicações e apoiar os
analistas e desenvolvedores nas manipulações dos dados mantidos nos SGBDs.
Já o segundo é responsável por manter e administrar o projeto físico de�nido e monitorar os
ambientes de dados mantidos pela empresa. Segue relação das principais atividades dos dois papéis.
3.4.5.1. DBA de Aplicação
Elaborar o projeto físico de dados.
Apoiar os analistas e desenvolvedores nas manipulações de dados mantidos nos SGBDs.
Suporte na construção e otimização de código (SQL).
Suporte na utilização e manipulação dos SGBDs.
Criação de estruturas nos SGBDs.
Tuning de aplicações nos ambientes de desenvolvimento e testes.
3.4.5.1.1. Principais características para atuar como DBA de Aplicação
Além das características gerais dos papéis técnicos, também são requisitos importantes para atuar
como DBA de Aplicação:
Conhecimentos avançados de administração de banco de dados.
Conhecimentos avançados em banco de dados (teoria, conceitos, arquitetura de SGBD e
utilização dos objetos).
Conhecimentos avançados em SQL e tuning de queries e stored procedures.
Conhecimentos de Modelagem de Dados.
Habilidade no uso de ferramentas de Modelagem de Dados.
Didática.
3.4.5.2. DBA de Infraestrutura
Criação de usuários e permissões de acesso no SGBD.
Administração e monitoração de servidores de banco de dados.
Manter a organização física do SGBD.
Backup e recovery de dados.
Instalação, con�guração, manutenção e suporte ao uso do SGBD.
Tuning de aplicações nos ambientes de homologação e produção.
3.4.5.2.1. Principais características para atuar como DBA de Infraestrutura
Além das características gerais dos papéis técnicos, também são requisitos importantes para atuar
como DBA de Infraestrutura:
Conhecimentos avançados de Administração de Banco de Dados.
Conhecimentos avançados de performance tuning.
Vivência em ambientes de pressão extrema.
3.4.6. Arquiteto de Integração de Dados
Pro�ssional sênior responsável por projetar os mecanismos para integraçãodos dados. Possui
conhecimentos avançados de SOA, ferramentas ETL9 e mecanismos de integração por meio de
SGBDs. Entre suas principais tarefas podemos destacar:
Emissão de pareceres indicando a melhor forma de integração dos dados.
Manter atualizado o catálogo de serviços de integração de dados.
Apoio na especi�cação de mecanismos de integração tais como: serviços, especi�cações ETL,
database links e demais mecanismos de integração via SGBD.
Apoiar os desenvolvedores de serviço na construção dos dispositivos de integração de dados.
3.4.6.1. Principais características para atuar neste papel
Além das características gerais dos papéis técnicos, também são requisitos importantes para atuar
como Arquiteto de Integração de Dados:
Conhecimentos avançados de mecanismos de integração de dados.
Conhecimentos avançados de utilização de repositórios de ativos de informação.
Boa comunicação escrita.
4. Estabelecendo a Gestão de
Dados nas Empresas
“O novo sempre despertou perplexidade e resistência.”
Sigmund Freud
4.1. Contextualização
Vimos no capítulo anterior que os papéis e per�s atuantes na Gestão de Dados são muitos. Porém,
como devemos estruturar e organizar esses papéis? As formas de estruturar a Gestão de Dados
variam muito em cada empresa. O objetivo deste capítulo é apresentar as formas mais usuais que são
adotadas no mercado para estruturar uma ou várias equipes de Gestão de Dados nas empresas.
4.2. Equipes de Gestão de Dados
As equipes de Gestão de Dados são formadas por um grupo de pro�ssionais da área que atuam em
um ou mais papéis e estão subordinados a uma estrutura organizacional dentro de uma empresa.
Possuem como principal responsabilidade trabalhar em conjunto com outras pessoas e demais
equipes a �m de atingir os objetivos táticos e estratégicos de�nidos para a disciplina de Gestão de
Dados nas empresas.
Também executam as tarefas estabelecidas na metodologia de Gestão de Dados vigente, alimentam
os indicadores de desempenho adotados e atuam de forma proativa com o propósito de elevar a
maturidade e a utilização da Gestão de Dados na empresa.
4.3. Onde estabelecer a Gestão de Dados?
De forma geral, a maioria das organizações ainda estabelece suas equipes de Gestão de Dados
dentro da própria área de TI.
Já outras pessoas defendem que as equipes de Gestão de Dados deveriam estar localizadas fora da
TI, preferencialmente no patamar estratégico da empresa, de modo que todos os funcionários
chamassem as mesmas coisas pelos mesmos nomes, relacionando todos os conceitos aos seus nomes
corretos.
Qual das duas abordagens é a ideal? A princípio, na minha visão, nenhuma das duas.
Equipes de Gestão de Dados subordinadas ao departamento de TI têm sua atuação muito limitada
às necessidades de tecnologia das empresas, sem, muitas das vezes, considerar as reais necessidades
do negócio.
Nesses casos, as soluções não são tão abrangentes, pois a área não possui uma visão global de todo
o negócio da empresa, e sim uma visão de requisições de clientes para atender dentro do seu
portfólio.
Além disso, é bastante comum haver con�itos técnicos entre Gestores de Dados e pro�ssionais
ligados ao desenvolvimento/manutenção de sistemas devido às soluções não tão completas e/ou
corretas que estão sendo apresentadas por causa das pressões decorrentes dos prazos e custos das
entregas. En�m, muito possivelmente, em um curto período de tempo, caso não adotassem posturas
de atendimento ágeis e proativas, as equipes de Gestão de Dados perderiam muito prestígio e seriam
encaradas por muitos como mais um “overhead” corporativo.
Equipes de Gestão de Dados estabelecidas fora do departamento de TI, preferencialmente nos
níveis mais altos dentro da hierarquia da empresa, possuem uma visão de negócio muito mais
abrangente e também aderente às reais necessidades das empresas, porém, de forma geral, faltam
condições e conhecimento técnico para acompanhar as implementações tecnológicas, geralmente
conduzidas pela área de TI.
Inicialmente, a área teria um bom prestígio, porém, no decorrer do tempo, quando as iniciativas
começarem a ser implementadas de forma diferente do planejado, inevitavelmente a área também
perderá muito prestígio e terá a sua existência questionada.
Uma terceira abordagem, mais aderente às necessidades atuais do mercado e alinhadas com os
princípios da Gestão de Dados, sugere a adoção de um modelo de atuação híbrido no qual a função
Gestão de Dados seria compartilhada entre as áreas de negócio e TI.
Para isso, a TI contaria com um quadro quali�cado de Gestores Técnicos de Dados e demais
pro�ssionais de tecnologia, e as áreas de negócio contariam com a �gura dos Gestores de Dados de
Negócio, também conhecidos como Data Stewards.
Este modelo pode ainda ser complementado com estruturas formais de apoio à Gestão de Dados,
tais como: Conselho de Governança de Dados, Comitês de Gestão de Dados e Escritórios de Gestão
de Dados. Essas estruturas �cariam responsáveis por fornecer subsídios e ajustar o alinhamento
constante entre as áreas de TI e negócio.
4.4. Cenários de distribuição das equipes de Gestão de Dados
Dependendo do porte e das características de cada empresa, a responsabilidade pela execução das
atividades da Gestão de Dados pode ser distribuída em várias equipes ou centralizada em uma única
equipe. Os cenários a seguir mostram as formas mais usuais de distribuição das responsabilidades
pelas atividades entre as equipes, suas vantagens e desvantagens.
Equipes distribuídas geogra�camente, porém subordinadas a uma mesma estrutura organizacional
e atuando de forma uniforme, serão consideradas neste livro como uma equipe única. Ou seja, a
distância física entre as equipes não impede uma possível centralização.
Vale ressaltar que, independentemente da forma como estão estruturadas, é fundamental
promover o alinhamento entre o segmento técnico (Gestão Técnica de Dados) e o segmento de
negócio (Gestão de Dados de Negócio). Sem isto, fatalmente, os resultados da Gestão de Dados
serão comprometidos.
4.4.1. Cenário 1 – Equipe centralizada
Este é o cenário mais comum encontrado na maioria das empresas, principalmente nas que já
possuíam uma área de Administração de Dados estabelecida e resolveram ampliar o escopo de
atuação sem grandes mudanças. Neste caso, geralmente a equipe é única e está situada dentro da
área de TI.
Todos os pro�ssionais que atuam na Gestão de Dados continuam a ser alocados dentro de uma
única equipe. A gestão desses pro�ssionais é executada por um gerente ou um coordenador que
também pode atuar no papel de Gestor Estratégico de Dados.
De forma geral, os pro�ssionais que atuam neste papel são divididos em frentes especí�cas para
atenderem a diferentes áreas de negócios da empresa. É extremamente recomendado que esses
pro�ssionais passem boa parte do expediente dentro das áreas de negócio, próximos aos clientes, a
�m de entender o “modus operandi” e representar as necessidades e os interesses das áreas de
negócio por eles atendidas.
Além disso, com o propósito de disseminar o conhecimento global a respeito das áreas de negócio
da empresa, também é recomendada a adoção de um rodízio entre as áreas atendidas por cada
Gestor de Dados de Negócio, para que, com o tempo, todos os pro�ssionais deste per�l amadureçam
uma visão de negócios completa de todos os segmentos da empresa.
Alguns papéis podem estar dentro de uma equipe de Gestão de Dados ou não. Os projetistas de
dados, em algumas empresas, são considerados membros de uma equipe de Gestão de Dados; já em
outras empresas isso não acontece. O mesmo ocorre com os DBAs. É comum haver separações entre
DBAs de aplicação, geralmente alocados em equipes de Gestão de Dados, e DBAs de Infra,
geralmente alocados em equipes de Suporte e Infraestrutura.
A �gura a seguir mostra um exemplo de uma equipe de Gestão de Dados estabelecida de forma
centralizada.
Figura 4.1 – Cenário típico de uma estrutura centralizada de Gestão de Dados
Neste cenário, as estruturas de apoio à equipe são opcionais. Quando existentes,são representadas
na pirâmide da �gura anterior, através do Conselho de Gestão de Dados. Essas estruturas são
responsáveis pelo relacionamento estratégico com a área de negócios.
Vale ressaltar que, conforme dito anteriormente, em alguns casos essas estruturas de apoio não são
adotadas, pois, além deste cenário ser uma forma inicial de estruturação, todos os pro�ssionais de
Gestão de Dados estão alocados em um único lugar. Neste caso todo o relacionamento com as áreas
de negócio (estratégico, tático e operacional) pode ser feito via equipe de Gestão de Dados.
Os cenários tratados neste livro possuirão vantagens e desvantagens. Em particular, as principais
vantagens do cenário de uma equipe de Gestão de Dados centralizada são:
Melhor gerenciamento e aproveitamento dos recursos humanos.
Custo reduzido, pois os gastos estarão concentrados em apenas uma equipe.
Mudança de cultura mais gradual, pois grande parte das empresas que resolvem adotar este
cenário já possuía uma área de Administração de Dados estabelecida.
Implantação da Gestão de Dados facilitada, pois as adoções em áreas de negócio podem ser
feitas de forma gradual, através de projetos piloto.
Garantia de processos de trabalho executados de forma única e centralizada.
Entre as desvantagens podemos citar:
O peso das decisões estará concentrado em um único lugar. Se a área de Gestão de Dados
estiver localizada dentro da TI, as decisões tenderão a levar em conta as pressões por prazos,
custos, entregas e disponibilidades de recursos da TI, deixando de lado algumas necessidades
prioritárias das áreas de negócio. Se a área estiver localizada fora da TI, algumas decisões
poderão ser tomadas sem levar em conta a capacidade de atendimento e a carteira de entregas
da área de TI.
A área de negócio pode não dar o apoio necessário à adoção da Gestão de Dados, tornando
difícil o alinhamento entre a TI e o negócio.
4.4.2. Cenário 2 – Gestão de Dados distribuída em duas equipes (Negócio e TI)
Este cenário pode ser considerado uma evolução do cenário anterior e é caracterizado pela divisão
de responsabilidades em duas equipes. A equipe de Gestão Técnica de Dados está subordinada à
área de TI e a equipe de Gestão de Dados de Negócio está subordinada a uma área de negócio da
empresa, preferencialmente ligada à estratégia/alta administração.
Os Comitês de Gestão e Governança de Dados e o Conselho de Gestão e Governança de Dados,
opcionais no cenário anterior, passam a ser fundamentais para promover alinhamento e harmonia
entre as duas equipes.
A forma de trabalho dos papéis não sofre nenhuma mudança radical em relação à forma de
atuação centralizada, porém é importante frisar que uma simples divisão de responsabilidades entre
duas áreas (equipes) impulsiona um melhor alinhamento entre a TI e o negócio, pois cada equipe
passa a concentrar seus esforços naquilo em que realmente é especialista.
Neste cenário, surge a possibilidade de existir um pro�ssional dedicado a promover a Gestão de
Dados nos escalões mais altos da empresa, o Executivo de Gestão de Dados (CDO). Este pro�ssional
atua nos níveis mais altos da empresa fornecendo a chancela e o apoio necessários para reconhecer a
Gestão de Dados como uma importante disciplina estratégica na empresa.
Em relação aos dados, o CDO junto com o Conselho de Governança de Dados será responsável
pelo relacionamento estratégico com as áreas de negócio da empresa. A equipe de Gestão de Dados
de Negócio será responsável por manter um relacionamento tático com as áreas de negócio. Já a
equipe de Gestão Técnica de Dados continuará a manter relacionamentos nos níveis tático e
operacional.
A �gura a seguir mostra um exemplo da Gestão de Dados dividida em duas equipes: uma ligada à
tecnologia e outra ligada ao negócio.
Figura 4.2 – Cenário típico de estrutura dividida em duas equipes: técnica e de negócio
Apesar de estar alocado na equipe de Gestão de Dados de Negócio na �gura anterior, o Gestor
Estratégico de Dados também pode estar alocado na equipe de Gestão Técnica de Dados ou então
fora das duas equipes, como uma espécie de consultor externo, inclusive apoiando o CDO da
empresa. A atuação do Gestor Estratégico de Dados é fundamental quando a Gestão de Dados é
compartilhada, pois este pro�ssional será o principal responsável por propor ações de cunho
corporativo para a Gestão de Dados na empresa.
4.4.2.1. Estruturação das duas equipes em um organograma
Dependendo da estruturação do organograma, as equipes podem ser subordinadas diretamente ao
CDO ou então serem gerenciadas em forma de matriz, onde o CDO de�niria as principais diretrizes
e as equipes atenderiam, ou seja, neste caso, o CDO atuaria como o principal cliente das duas
equipes.
As �guras que virão a seguir demonstrarão dois casos comuns de estruturação da Gestão de Dados
em um organograma onde a atuação da Gestão de Dados é compartilhada. Vale ressaltar que os
exemplos a seguir são meramente didáticos e não representam a estrutura organizacional de uma
empresa real.
Exemplo 1: Gestão de Dados estabelecida em dois departamentos diferentes, com gerência
indireta do CDO em cada equipe.
Figura 4.3 – Exemplo de organograma com gerência indireta do CDO nas equipes
Neste exemplo, cada área possui um gerente (ou coordenador) funcional responsável pela gestão
dos recursos humanos formados pelos pools de gestores de dados (técnicos ou de negócios). Este
gerente é subordinado à outra estrutura dentro do organograma e deve atender aos objetivos
de�nidos pela sua estrutura superior, porém o CDO exerce forte in�uência na gestão dessas equipes.
Na prática, esses pro�ssionais possuem dois chefes.
Exemplo 2: Gestão de Dados estabelecida em uma única estrutura, com gerência direta do CDO
nas equipes.
Figura 4.4 – Exemplo de estrutura com gerenciamento direto do CDO nas equipes de Gestão de Dados
Neste exemplo, a gestão dos recursos é facilitada, pois a estrutura de trabalho segue uma hierarquia
única. Vale destacar que, neste caso, apesar de ter uma estrutura para Gestão Técnica de Dados
especí�ca, esta não é subordinada à TI.
Resumo da ópera: nesta forma de estruturação, a equipe de Gestão Técnica de Dados não sofre as
pressões costumeiras das áreas de desenvolvimento de sistemas, dando aos pro�ssionais da área
mais liberdade para emissão de laudos ou pareceres. Além disso, a aproximação com a equipe de
Gestão de Dados de Negócio traz diversos benefícios, entre eles: melhor agilidade em resolver
problemas que envolvem o negócio, comunicação direta e alinhamento constante entre a TI e o
negócio. Para muitos este é o principal ganho dessa forma de estruturação.
4.4.2.2. Vantagens e desvantagens de trabalhar com duas equipes
Voltando ao cenário da distribuição da Gestão de Dados em duas equipes, quais são suas vantagens
e desvantagens?
Entre as principais vantagens de adotar a Gestão de Dados compartilhada entre duas equipes
podemos citar:
Melhor alinhamento entre a TI e o negócio.
Melhoria no nível de maturidade do gerenciamento de dados e informações devido à utilização
de estruturas de apoio como Comitês de Gestão de Dados e Conselho de Governança de
Dados.
A Gestão de Dados reconhecida nos escalões mais altos da empresa devido à atuação do
Executivo de Gestão de Dados (CDO).
As principais desvantagens são:
O custo de implantação da Gestão de Dados será um pouco maior do que uma iniciativa
centralizada.
Necessidade de estruturas de apoio para promover a perfeita harmonia entre as duas equipes.
A metodologia e a forma de trabalho devem estar bem de�nidas e alinhadas, sob o risco de
haver sobreposição em algumas atividades.
4.4.3. Cenário 3 – Gestão de Dados distribuída em várias equipes de negócio e uma
única equipe de TI
Menos usual que os cenários anteriores, a responsabilidade pela execução das atividades da Gestão
de Dados é compartilhada entre várias equipes de Gestão de Dados de Negócio, com o apoio de
uma equipe de Gestão Técnica de Dados centralizada.
Neste cenário, as questões con�itantes entre as equipes de Gestão de Dadosde Negócio nem
sempre são decididas pelos Comitês de Gestão de Dados. É comum escalar as decisões para o
Conselho de Governança de Dados.
Nem todas as áreas de Negócio possuem equipes de Gestão de Dados de Negócio dedicadas.
Nesses casos, essas áreas são atendidas por uma equipe genérica de Gestores de Dados de Negócio
mantida sob a área de TI ou então pela equipe de Gestão Técnica de Dados.
Em relação ao organograma, as equipes de Gestão de Dados de Negócio podem estar espalhadas
em várias áreas dentro da empresa. Este fator pode ser preocupante, pois a forma de atuação de cada
uma dessas equipes poderá não ser uniforme.
A �gura a seguir mostra um exemplo de como a Gestão de Dados pode ser adotada através de
várias equipes de Gestão de Dados de Negócio e uma equipe de Gestão Técnica de Dados.
Figura 4.5 – Gestão de Dados distribuída por várias equipes de negócio e uma equipe técnica
As principais vantagens de adotar este cenário de distribuição de equipes são as seguintes:
Melhor entendimento das áreas de negócio, pois os Gestores de Dados de Negócio atuarão
diretamente nessas áreas.
Facilidade na adoção do papel do Gestor de Dados de Negócio.
Entre as principais desvantagens podemos citar:
Apesar de haver um melhor entendimento especí�co das áreas de negócio, a visão corporativa
do negócio da empresa �cará comprometida, pois provavelmente não haverá mais o
revezamento entre as áreas de atuação dos Gestores de Dados de Negócio em algumas áreas.
Comunicação custosa. Toda e qualquer comunicação sobre o assunto Gestão de Dados
Corporativa deverá ser levada a vários canais.
Riscos das equipes não atuarem de forma constante.
Sobrecarga no trabalho da equipe de Gestão Técnica de Dados, pois em algumas situações esta
equipe também poderá atuar no atendimento de outras áreas executando atividades de Gestão
de Dados de Negócio. Além disso, provavelmente os planejamentos das equipes de Gestão de
Dados de Negócio não ocorrerão no mesmo tempo, deixando a equipe técnica vulnerável às
mudanças repentinas e não planejadas.
O custo de implantação da Gestão de Dados será um pouco maior do que uma iniciativa
centralizada.
4.4.4. Cenário 4 – Gestão de Dados distribuída em uma equipe de Gestão de Dados
de Negócio e várias equipes de Gestão Técnica de Dados especializadas
Neste cenário a responsabilidade pelas atividades da Gestão de Dados é compartilhada entre uma
equipe única de Gestão de Dados de Negócio e várias equipes de Gestão Técnica de Dados.
As equipes técnicas são divididas por especialidades e estão subordinadas a uma ou mais
estruturas organizacionais dentro da área de TI da empresa.
Apesar de concentrar recursos especialistas em cada equipe técnica, este cenário requer
preocupações adicionais:
A primeira preocupação consiste em não permitir o crescimento desorganizado dessas equipes.
Veremos mais à frente um exemplo de como um crescimento desorganizado de equipes pode
prejudicar a atuação da Gestão de Dados.
Outra preocupação que se deve ter em mente é uma possível demora no atendimento das
tarefas pelas equipes de Gestão Técnica de Dados, pois, de forma geral, várias equipes poderão
estar envolvidas em processos comuns. Portanto, é imprescindível de�nir SLAs10 curtos e
promover um alinhamento constante entre as equipes. Se este trabalho for realizado com
proeza, esta abordagem poderá mudar a tendência de demora e se transformar em uma das
formas mais rápidas de atendimento.
Pelo fato das equipes técnicas estarem divididas, o Gestor Estratégico de Dados geralmente é
alocado na equipe de negócio ou então atua como um consultor independente, sem estar ligado
diretamente a uma equipe.
Em relação ao organograma, geralmente as equipes de Gestão Técnica de Dados estão
subordinadas à estrutura organizacional da TI.
A �gura a seguir mostra um exemplo de como a Gestão de Dados pode ser adotada através de uma
equipe única de Gestão de Dados de Negócio e várias equipes técnicas de Gestão de Dados.
Figura 4.6 – Gestão de Dados centralizada em uma equipe de Gestão de Dados de Negócio e várias equipes
técnicas de Gestão de Dados
As principais vantagens de adotar este cenário de distribuição de equipes são as seguintes:
O alinhamento entre a TI e o negócio continua, porém com maiores interações entre as equipes
técnicas.
Não há sobrecarga nos papéis.
Atividades da Gestão Técnica de Dados executadas por pro�ssionais especialistas.
As principais desvantagens são:
Comunicação custosa. Toda e qualquer comunicação sobre o assunto Gestão de Dados, no
âmbito técnico, deverá ser levada a vários canais.
Necessidade de estruturas de apoio para promover a perfeita harmonia entre as duas equipes.
Maior número de recursos técnicos para conduzir as atividades de Gestão Técnica de Dados.
O custo de implantação da Gestão de Dados será um pouco maior do que uma iniciativa
centralizada.
4.4.5. Cenário 5 – Gestão de Dados distribuída em várias equipes técnicas e
equipes de negócio
Apesar de não parecer usual, este cenário pode ser encontrado em algumas empresas,
principalmente naquelas que possuem uma estrutura organizacional muito grande, onde equipes de
Gestão de Dados foram criadas sem um planejamento corporativo, através de várias iniciativas
isoladas entre diferentes áreas para gerir os dados.
O esforço para manter organizadas as equipes de Gestão de Dados é muito maior do que nos
outros cenários, pois o número de equipes e a forma de interação entre elas são muito maiores.
Para funcionar bem, a Governança de Dados deve estar muito bem de�nida e estruturada. A
responsabilidade por manter esta governança deve ser dada a uma equipe estabelecida em um nível
mais alto do que as demais no organograma, além de possuir uma boa visibilidade e patrocínio
forte. Neste caso, o CDO pode ser o responsável por esta equipe.
A �gura a seguir demonstra um exemplo de interações entre as equipes da Gestão de Dados de
uma mesma empresa: 
Figura 4.7 – Gestão de Dados distribuída entre várias equipes Técnicas e de Negócio
Ao estruturar este tipo de abordagem, deve-se tomar o cuidado de não criar equipes iguais, que
executem as mesmas atividades e tenham o mesmo propósito. A�nal, como mostra a imagem
anterior, mesmo com equipes diferentes as interfaces são muitas e a comunicação e o alinhamento
são muito custosos.
Sem este cuidado, fatalmente as atividades da Gestão de Dados serão feitas por várias equipes, de
forma repetida ou sobreposta. Sem uma forma de trabalho padrão, com atendimento lento e
precário, algumas vezes com con�itos e interesses políticos entre as equipes, levando cada vez mais
adiante a possibilidade de criar mais equipes para executar os trabalhos que são feitos pelas equipes
atuais de forma não integrada. É o fenômeno da multiplicação das equipes de Gestão de Dados.
Apesar de não ser comum, isto pode ocorrer em empresas onde as iniciativas a respeito da Gestão
de Dados não vieram de cima, mas de baixo, onde técnicos de diversas áreas inicializaram este
trabalho sem um patrocínio formal da alta gerência da empresa.
A �gura a seguir mostra um exemplo deste fenômeno.
Figura 4.8 – Multiplicação das equipes de Gestão de Dados
Empresas com tais características devem rever a forma de atuação da Gestão de Dados e propor
uma estratégia de reformulação compatível com os cenários apresentados neste capítulo. Vale
ressaltar que qualquer descuido em relação ao cenário 5 acarretará neste tipo de fenômeno.
Ainda sobre o cenário 5, a única vantagem desta abordagem é a execução das atividades da Gestão
de Dados feitas por especialistas tanto da área técnica quanto da área de negócio.
Já as desvantagens são várias. Podemos citar:
Risco de crescimento desorganizado.
Falta de identidade organizacional para a disciplina Gestão de Dados.
Comunicação custosa.
Mau dimensionamento e aproveitamento dos recursos humanos.
Se existirem equipes com os mesmos objetivos, haverá sobreposição de tarefas.
Falta de alinhamento entre TI e o negócio.
Escopo de atuação limitado.
Estabelecimento de feudos: “meusdados”, “minhas aplicações”, “meus pro�ssionais”.
4.5. Qual o melhor cenário para adotar a Gestão de Dados em
minha empresa?
Eleger a melhor abordagem dentre as apresentadas anteriormente, sem levar em conta as
características e particularidades de cada empresa, não parece ser uma atitude correta. Cada
empresa possui uma realidade. Questões como a cultura da empresa, patrocínio, disponibilidade e
verba disponível para implantar a Gestão de Dados in�uenciam diretamente na escolha de uma
abordagem.
Convém, no entanto, ter atenção em certos fatores críticos que caracterizam uma área de Gestão de
Dados bem-sucedida. São eles:
Constituir-se em unidade(s) autônoma(s) com recursos dedicados integralmente e centro de
custo.
Possuir autoridade institucional su�ciente para agir com independência, segurança e e�cácia
na busca dos seus objetivos.
Supervisionar a adoção, por todos os setores, incluindo a TI, de modelos, normas e regras de
Gestão de Dados corporativos, decorrentes das estratégias organizacionais aprovadas.
Ter o apoio sustentado e explícito da Alta Administração da empresa, no mínimo, até que atinja
a fase de consolidação e maturação da área.
5. Visão Geral do Guia
DAMA-DMBOK®
“Os costumes são uma das fontes da moral.”
Henri Bergson
5.1. O que é o Guia DAMA-DMBOK®?
O Guia DAMA-DMBOK® é um conjunto de boas práticas de Gestão de Dados reunidas em um
documento estruturado em forma de um framework. O conteúdo do guia foi elaborado com a
contribuição de mais de 120 pro�ssionais que atuam na área de Gestão de Dados no mundo.
Por se tratar de um guia de boas práticas, o documento faz referência a diversas fontes de
informação e conteúdo especializado em cada uma das dez funções de Gestão de Dados propostas
no documento. As referências especializadas costumam ser citadas no �m de cada capítulo.
O guia já começou a ser adotado em algumas empresas brasileiras. No mercado internacional o
documento já é uma referência consagrada, sendo adotado por milhares de organizações que
faturam e/ou administram bilhões de dólares.
Entre seus principais objetivos podemos citar:
Transmitir aos leitores a importância da Gestão de Dados.
Construir consenso para uma visão generalista aplicada no mercado para as dez funções de
Gestão de Dados previstas no guia atual.
Fornecer de�nições padrão para os termos da Gestão de Dados, conceitos, entregáveis, papéis e
responsabilidades dos envolvidos na adoção da disciplina Gestão de Dados.
De�nir as premissas que orientam a adoção da Gestão de Dados nas empresas.
Apresentar um visão independente de fornecedores, com técnicas e métodos que podem ser
amplamente adotados oferecendo alternativas de abordagem, promovendo assim a real
discussão nas aquisições e implementações da Gestão de Dados.
Servir como instrumento orientador a respeito do escopo e fronteiras de atuação da Gestão de
Dados.
Fornecer base para avaliar a e�cácia e maturidade da adoção da Gestão de Dados nas empresas.
Atuar como referência aos leitores com os recursos adicionais para aprimorar o uso da
disciplina de Gestão de Dados.
Apoiar os pro�ssionais de Gestão de Dados na preparação para os exames de certi�cação em
Gestão de Dados.
Vale ressaltar que o guia DAMA-DMBOK® é um documento genérico que pode ser adotado por
qualquer empresa, independentemente de área de atuação, porte e cultura. Quando adotado,
devemos ter em mente as seguintes considerações:
O conteúdo do guia é bastante amplo. Não é um livro didático e muito menos se propõe a ser
um livro técnico especí�co sobre Administração de Dados ou Qualidade de Dados.
O conteúdo do guia está em constante evolução, e toda a comunidade mundial de pro�ssionais
de Gestão de Dados pode contribuir para o seu enriquecimento.
A edição em português do guia DAMA-DMBOK® é uma tradução da versão original em inglês.
Como toda empresa possui as suas particularidades, nem todas as boas práticas precisam ser
adotadas em sua totalidade. Portanto, quando utilizado, o guia deve ser analisado e adaptado à
realidade de cada organização.
Não há uma ordem preestabelecida de execução das funções de Gestão de Dados previstas no
guia. Por esta razão as funções são representadas por uma espécie de “roda” no framework do
DAMA-DMBOK®.
A adoção do guia pode ser feita em partes, geralmente divididas por funções. Entretanto, vale a
pena levar em consideração a analogia feita no capítulo 2 deste livro, onde a função
“Arquitetura de Dados” é considerada o alicerce da casa, base necessária para o sustento de
qualquer iniciativa de Gestão de Dados, e a função “Governança de Dados” é considerada o
telhado da casa, dando a proteção e o reconhecimento necessários ao funcionamento das
demais funções.
Por �m, tudo isso nos leva a concluir que o guia DAMA-DMBOK® é uma excelente referência
técnica e não uma receita de bolo.
5.2. Framework
A leitura e entendimento do guia através de seu framework são bastante simples. O framework está
estruturado em duas visões principais, sendo elas:
Funções da Gestão de Dados.
Elementos ambientais da Gestão de Dados.
5.2.1. Funções de Gestão de Dados
As funções de Gestão de Dados representam os principais segmentos de atuação da disciplina
agrupados por atividades comuns e/ou próprias de cada agrupamento.
Além de facilitar o entendimento e a distribuição das atividades em comum, a divisão da disciplina
“Gestão de Dados” em funções é importante, pois algumas das funções propostas requerem
pro�ssionais e/ou equipes com per�s especí�cos.
Vale ressaltar que algumas das funções já eram atendidas, mesmo que parcialmente, pelas antigas
equipes de Administração de Dados nas empresas brasileiras.
A �gura a seguir mostra as dez funções de Gestão de Dados previstas na versão atual do guia
DAMA-DMBOK®. A função Governança de Dados está localizada no centro da �gura para
demonstrar que exerce importante in�uência em todas as demais funções.
Figura 5.1 – Funções da Gestão de Dados segundo o guia DAMA-DMBOK®
Podemos caracterizar as funções de Gestão de Dados da seguinte forma:
Governança de Dados: o guia DAMA-DMBOK® de�ne esta função como “o exercício de
autoridade e controle (planejamento, monitoramento e engajamento) sobre o gerenciamento de
ativos de dados”. Esta função é responsável por promover o reconhecimento da disciplina
Gestão de Dados na empresa e também por controlar a gestão dos ativos de dados em alto nível
em toda a organização. A Governança de Dados é considerada uma função estratégica e se
relaciona diretamente com todas as demais funções de Gestão de Dados do guia DAMA-
DMBOK®, por isso está representada no centro do framework.
Gestão da Arquitetura de Dados: o guia DAMA-DMBOK de�ne esta função como “de�nição
dos dados necessários da organização e o desenho do diagrama mestre para atingir essas
necessidades”. Esta função é responsável por de�nir em âmbito corporativo os dados
necessários para a empresa e também por manter o controle dos modelos corporativos e
demais artefatos da Arquitetura de Dados corporativa alinhados à arquitetura empresarial da
organização.
Desenvolvimento de Dados: o guia DAMA-DMBOK® de�ne esta função como “projetar,
implementar e manter soluções para atender às necessidades de dados da organização”. Esta
função é responsável por gerir todo o ciclo de vida de criação das estruturas de dados que serão
utilizadas nas aplicações. Engloba as atividades de levantamento dos dados, modelagem dos
dados, ajustes, avaliação dos modelos de dados, implementação física e manutenção das bases
de dados relacionadas com os componentes das soluções adotadas. O termo “Desenvolvimento
de Dados” soa um pouco estranho aqui no Brasil. Segundo o dra da nova versão do DAMA-
DMBOK® disponibilizado pela DAMA International em seu website, esta função será
renomeada na próxima versão do guia para “Modelagem de Dados e Projeto”.
Gestão de Operações e Dados: o guia DAMA-DMBOK® de�ne esta função como “planejar,
controlar e suportar ativos de dados estruturados atravessando o ciclo de vida dos dados, desde
a criaçãoe aquisição até o arquivamento e a eliminação”. Esta função é responsável por gerir os
dados (conteúdo) estruturados, geralmente armazenados em sistemas gerenciadores de banco
de dados, em todo o ciclo de vida do dado, respeitando as diretrizes estabelecidas nas outras
funções de Gestão de Dados. Ou seja, é o controle do ativo do dado armazenado desde o seu
planejamento e criação no ciclo de desenvolvimento de sistemas até a aquisição, o
arquivamento e o expurgo no ciclo de vida dos dados.
Gestão da Segurança de Dados: o guia DAMA-DMBOK® de�ne esta função como “planejar,
desenvolver e executar procedimentos e políticas de segurança para prover autenticação,
autorização, acesso e auditoria dos dados e informações”.
Gestão de Dados Mestres e Referência: o guia DAMA-DMBOK® de�ne esta função como
responsável por planejar, de�nir arquitetura, implementar e controlar o uso dos dados mestres
e de referência da empresa, mantendo a sua consistência e exatidão. Esta função trouxe à
comunidade de Gestão de Dados o conceito de “registros dourados”, tradução do termo
“golden records”, que são os dados mais precisos e completos possíveis para o uso
compartilhado e consistente entre as aplicações.
Gestão de Data Warehousing e Business Intelligence: o guia DAMA-DMBOK® de�ne esta
função como responsável por “planejar, implementar e controlar processos para prover dados
de suporte para decisão e suportar trabalhadores do conhecimento engajados em análises,
queries e reporte”.
Gestão da Documentação e Conteúdo: o guia DAMA-DMBOK® de�ne esta função como
“planejar, implementar e controlar atividades para armazenar, proteger e permitir o acesso aos
dados dentro de arquivos eletrônicos e registros físicos (incluindo texto, grá�cos, imagens,
áudio e vídeo).” Esta função é responsável por gerir os dados (conteúdo) não estruturados,
geralmente armazenados em arquivos diversos. Por se tratar de dados não estruturados, ou
seja, não armazenados em bancos de dados tradicionais, aparentemente os per�s mais técnicos
atuantes em Gestão de Dados não consideram relevante a preocupação em gerir esses dados,
porém devemos ter em mente que atualmente a maioria dos dados das empresas é armazenada
em formas não estruturadas, e cada vez mais as soluções de ECM (Enterprise Content Manager)
estão sendo adotadas para armazenar esses tipos de dados.
Gestão de Metadados: o guia DAMA-DMBOK® de�ne esta função como “planejar,
implementar e controlar atividades para permitir o fácil acesso a metadados integrados de alta
qualidade”. Esta função permite o gerenciamento dos metadados representados em modelos de
dados, bancos de dados, repositórios e demais ferramentas de gestão de metadados. Além
disso, provê, quando necessário, o devido acesso aos metadados da empresa aos envolvidos.
Gestão da Qualidade de Dados: o guia DAMA-DMBOK® de�ne esta função como
“planejamento e implementação das atividades que aplicam técnicas de gestão de Qualidade de
Dados para medir, avaliar, otimizar e garantir dados adequados para o uso”.
Podemos considerar as funções do DAMA-DMBOK® como o principal conceito do framework.
Algumas dessas funções possuem atividades que já eram executadas parcialmente ou
integralmente pelas antigas equipes de Administração de Dados nas empresas, principalmente a
função “Desenvolvimento de Dados”.
5.2.2. Elementos ambientais
Os elementos ambientais representam as variáveis que geram grande in�uência na seleção, no
escopo e na forma de adoção da disciplina Gestão de Dados em cada empresa.
Os elementos ambientais podem ser divididos em duas classes: elementos básicos, caracterizados
por ocorrências de elementos em todas as funções de Gestão de Dados, e elementos de apoio,
caracterizados por ocorrências que nem sempre são encontradas em todas as funções de Gestão de
Dados.
A �gura a seguir mostra os elementos ambientais previstos na versão atual do guia DAMA-
DMBOK®.
Figura 5.2 – Elementos ambientais do DAMA-DMBOK®. Fonte: Guia DAMA-DMBOK®
Os elementos ambientais previstos na versão atual do guia DAMA-DMBOK® são: Elementos
básicos:
Metas e Princípios: fornecem foco, objetivos e propósitos de cada função de Gestão de Dados,
além de de�nirem os princípios básicos de cada função de Gestão de Dados. Representam o
propósito de cada função seguindo seus princípios básicos.
Atividades: conjunto de ações necessárias para atingir as metas de cada função de Gestão de
Dados. Em algumas funções as atividades podem ser agrupadas. Vale ressaltar que o guia não
de�ne os processos e nem o detalhamento dos �uxogramas de cada atividade. Elas representam
os passos necessários que devem ser feitos em cada função de Gestão de Dados. As atividades
são executadas em fases especí�cas: Planejamento, Controle, Desenvolvimento e Operação.
Além disso, as atividades podem ser decompostas em tarefas menores e etapas. As relações de
todas as atividades do guia DAMA-DMBOK®, bem como suas fases de execução, estão
disponíveis no Anexo deste livro.
Entregas Primárias: são os entregáveis gerados a partir da execução das atividades previstas
em cada função de Gestão de Dados. Representam o que é gerado a partir do trabalho
executado nas atividades.
Papéis e Responsabilidades: papéis envolvidos na produção dos entregáveis de cada função de
Gestão de Dados. Representam quem é responsável por cada atividade e entrega de artefatos
previstos em cada função de Gestão de Dados.
Elementos de apoio:
Tecnologia: são ferramentas, padrões, protocolos e critérios de seleção de produtos adotados.
Vale ressaltar que o guia não menciona vendedores ou produtos em seu conteúdo.
Práticas e Técnicas: são métodos e procedimentos comuns utilizados para executar as
atividades e produzir os entregáveis.
Organização e Cultura: são as particularidades de cada ramo de atuação de negócio e/ou
empresa. Entre essas questões, o guia prevê os seguintes itens:
Métricas.
Fatores críticos do sucesso.
Relatórios de estruturas.
Estratégias.
Questões �nanceiras.
Trabalho em equipe e dinâmica de grupo.
Filoso�a da empresa.
Valores e crenças, etc.
5.3. Junção das funções de Gestão de Dados com os elementos
ambientais
A junção das funções de Gestão de Dados com os elementos ambientais gera uma matriz de duas
dimensões. Esta matriz é importante, pois mostra uma visão estática de como cada elemento
ambiental é tratado em cada função de Gestão de Dados.
O preenchimento da tabela é bastante útil para de�nir o escopo e a estratégia de implementação
e/ou adoção do guia DAMA-DMBOK® nas empresas.
Conforme mencionado anteriormente, o guia não é uma receita de bolo – portanto, a tabela é um
importante instrumento a ser utilizado em um trabalho de implantação do guia DAMA-DMBOK®.
A tabela a seguir mostra este quadro.
Funções de
Gestão de Dados
Metas e
Princípios Atividades Entregas
Primárias
Papéis e
Responsabilidades Tecnologia
Práticas
e
Técnicas
Organização
e Cultura
Governança de
Dados
Gestão da
Arquitetura de
Dados
Desenvolvimento
dos Dados
Gestão das
Operações de
Dados
Gestão da
Segurança dos
Dados
Gestão de Dados
Mestres e de
Referência
Gestão de Data
Warehousing e
Business
Intelligence
Gestão da
Documentação e
Conteúdo
Gestão dos
Metadados
Gestão da
Qualidade dos
Dados
Tabela 5.1 – Visão do framework DAMA-DMBOK®
Parte 2
Funções da Gestão de Dados
6. Governança de Dados
“A necessidade é a mãe da inovação.”
Platão
6.1. Governança de Dados – Conceitos
Tal como a disciplina Gestão de Dados, existem várias de�nições para a
função “Governança de Dados”. Particularmente, pre�ro adotar as seguintes:
“Governança de Dados é o exercício de autoridade e controle (planejamento,
monitoramento e engajamento) sobre o gerenciamento de ativos de dados.
A função de Governança de Dados guia como todas as outras funções da
Gestão de Dados são realizadas. Governança de Dados é de alto nível, ou
seja, é gestão estratégica de dados na esfera executiva.”1
“Governança de Dados é o exercício de tomada de decisão e autoridade
para as questões relacionadas a dados.”2.
Em suma, a funçãoQualidade de Dados.
Após o detalhamento das principais funções de Gestão de Dados, os
leitores também terão a oportunidade de conhecer a �loso�a da Gestão de
Dados Moderna nos capítulos �nais do livro.
Esta �loso�a é focada na conduta comportamental dos pro�ssionais que
atuam na área e prega o entendimento de que os principais ativos da
empresa são três: Pessoas, Dados e Recursos Financeiros.
Por �m, o livro é encerrado em um capítulo dedicado à carreira do Gestor
de Dados. Neste capítulo, o leitor terá acesso às principais informações deste
mercado de trabalho, organizações que atuam na área de Gestão e
Governança de Dados, bem como informações úteis sobre as certi�cações
pro�ssionais desta área.
Boa leitura a todos!
Bergson Lopes Rego, PMP
Prefácio
Gestão de Dados e Governança de Dados são assuntos novos e ainda
pouco explorados. Entretanto, gradativamente as organizações têm
percebido que a adoção das melhores práticas em Gestão e Governança de
Dados, além de proporcionar redução de custos, aumento da segurança da
informação, tomada de decisões com informações assertivas, gera também
diferencial competitivo. Todos nós sabemos que as organizações são criadas
para a eternidade, esta é a vontade de seus criadores, porém muitas não
conseguem passar do primeiro ano de vida. Nos dias de hoje, qualquer
empresa que queira ser eterna necessita colocar na sua agenda a Gestão e a
Governança de Dados. Assim como o sangue é essencial para o corpo
humano, dados são fundamentais para as organizações. Dados são os �uidos
que lubri�cam todas as relações e ações executadas nas organizações e estão
presentes nas atividades executadas pelas áreas, em processos e também nos
projetos. Sendo assim, dados merecem ser respeitados e tratados como
ativos-chave para a manutenção operacional e estratégica das organizações.
Como bem disse Tom Peters, “As organizações que não entenderem a
enorme importância da Gestão de Dados e informações como ativos
tangíveis na nova economia não vão sobreviver”. Entretanto, não basta
entender, as organizações precisam ser proativas e adotar um conjunto de
melhores práticas que possibilitem aos stakeholders (partes interessadas) ter
a segurança necessária quando o assunto for dados.
Também é conhecimento geral de que dado é a base para a informação e
que informação, por sua vez, é a base para o conhecimento. Isso exige
também que as organizações adotem práticas associadas à gestão do
conhecimento. O trabalho da Gestão e Governança de Dados pode ser
árduo e complexo, mas os ganhos proporcionados são inestimáveis.
Para que as organizações e os seus pro�ssionais possam mudar os seus
valores e passem a considerar os dados como ativos, é necessário que muitas
publicações sejam disponibilizadas para os formadores de opinião, mas com
um conteúdo direcionado para os decisores, pois estes, em última instância,
acabam tomando decisões com grande probabilidade de erros e também
com grande margem de riscos. Portanto, as publicações precisam ter apelo
su�ciente para que decisores e in�uenciadores sejam motivados a colocar
em prática a Gestão e Governança de Dados.
O livro publicado pelo Bergson Lopes é inédito no Brasil e certamente é
uma publicação que vai ser fundamental neste momento tão importante
para as organizações. O livro agora disponível, resultado de um árduo
trabalho empreendido pelo autor, passa a ser, igualmente ao DAMA-
DMBOK®, uma referência para todos os pro�ssionais de todos os tipos de
organizações.
Desejo uma ótima leitura!
Rossano Soares Tavares
Presidente do capítulo brasileiro da Data Management Association –
DAMA® Brasil
Sumário
Capa
Créditos
Dedicatória
Agradecimentos
Sobre o Autor
Nota do Autor
Prefácio
Introdução
Parte 1
1. Conceitos Básicos
1.1. Dado, informação, conhecimento e sabedoria
1.2. Ciclo de vida dos dados
1.3. Características de qualidade desejadas para os dados e
metadados
1.4. Big Data
1.4.1. Como caracterizar o Big Data?
1.4.2. Volume
file:///C:/Users/annes/AppData/Local/Temp/calibre_8vuhhzq3/6q40jaju_pdf_out/OEBPS/Text/cover.html
1.4.3. Velocidade
1.4.4. Variedade
1.4.5. Veracidade
1.4.6. Valor
1.5. Considerações �nais sobre Big Data
2. Gestão de Dados
2.1. Gestão de Dados – De�nições
2.2. Princípios que orientam a Gestão de Dados
2.3. Principais funções que compõem a disciplina Gestão de
Dados
2.4. Principais ganhos na adoção da Gestão de Dados
2.5. Gestão de Dados ou Administração de Dados – Qual o termo
correto?
2.6. Mitos sobre a Gestão de Dados
3. Papéis Envolvidos na Gestão de Dados
3.1. Tipos de papéis envolvidos
3.2. Papéis ligados ao negócio
3.2.1. Gestor de Dados de Negócio
3.2.1.1. Principais características para atuar neste papel
3.2.2. Coordenadores e gerentes das equipes de Gestão de
Dados de Negócio
3.2.2.1. Principais características para atuar neste papel
3.2.3. Gestor da Informação
3.2.3.1. Principais características para atuar neste papel
3.3. Papéis estratégicos
3.3.1. Executivo de Gestão de Dados
3.3.1.1. Principais características para atuar neste papel
3.3.2. Gestor Estratégico de Dados
3.3.2.1. Principais características para atuar neste papel
3.4. Papéis técnicos
3.4.1. Coordenadores e gerentes das equipes de Gestão
Técnica de Dados
3.4.1.1. Principais características para atuar neste papel
3.4.2. Gestor Técnico de Dados
3.4.2.1. Principais características para atuar neste papel
3.4.3. Administrador dos Repositórios de Metadados
3.4.3.1. Principais características para atuar neste papel
3.4.4. Projetista de Dados
3.4.4.1. Principais características para atuar neste papel
3.4.5. Administrador de Banco de Dados (DBA)
3.4.5.1. DBA de Aplicação
3.4.5.1.1. Principais características para atuar como DBA
de Aplicação
3.4.5.2. DBA de Infraestrutura
3.4.5.2.1. Principais características para atuar como DBA
de Infraestrutura
3.4.6. Arquiteto de Integração de Dados
3.4.6.1. Principais características para atuar neste papel
4. Estabelecendo a Gestão de Dados nas Empresas
4.1. Contextualização
4.2. Equipes de Gestão de Dados
4.3. Onde estabelecer a Gestão de Dados?
4.4. Cenários de distribuição das equipes de Gestão de Dados
4.4.1. Cenário 1 – Equipe centralizada
4.4.2. Cenário 2 – Gestão de Dados distribuída em duas
equipes (Negócio e TI)
4.4.2.1. Estruturação das duas equipes em um
organograma
4.4.2.2. Vantagens e desvantagens de trabalhar com duas
equipes
4.4.3. Cenário 3 – Gestão de Dados distribuída em várias
equipes de negócio e uma única equipe de TI
4.4.4. Cenário 4 – Gestão de Dados distribuída em uma equipe
de Gestão de Dados de Negócio e várias equipes de Gestão
Técnica de Dados especializadas
4.4.5. Cenário 5 – Gestão de Dados distribuída em várias
equipes técnicas e equipes de negócio
4.5. Qual o melhor cenário para adotar a Gestão de Dados em
minha empresa?
5. Visão Geral do Guia DAMA-DMBOK®
5.1. O que é o Guia DAMA-DMBOK®?
5.2. Framework
5.2.1. Funções de Gestão de Dados
5.2.2. Elementos ambientais
5.3. Junção das funções de Gestão de Dados com os elementos
ambientais
Parte 2
6. Governança de Dados
6.1. Governança de Dados – Conceitos
6.2. Razões para implantar a Governança de Dados
6.3. Princípios da Governança de Dados
6.4. Componentes da Governança de Dados
6.4.1. Pessoas
6.4.2. Processos
6.4.3. Tecnologia
6.5. Documentos da Governança de Dados
6.5.1. Estratégia de Dados
6.5.2. Política de Dados
6.5.3. Normas e padrões
6.5.4. Procedimentos
6.6. Estruturas formais de apoio à Gestão de Dados
6.6.1. Escritório de Gestão de Dados
6.6.2. Comitês de Gestão de Dados
6.6.3. Conselho de Governança de Dados
6.7. Dicas para implantar um programa de Governança de Dados
6.8. Atividades necessárias para manter um programa de
Governança de Dados segundo o DAMA-DMBOK®
7. Modelagem de Dados
7.1. Modelagem de Dados – Principais conceitos
7.2. Modelo Conceitual de Dados
7.2.1. Entidades
7.2.2. Relacionamentos
7.2.2.1. Grau dos relacionamentos
7.2.2.2. Cardinalidade
7.2.2.3. Tipos de relacionamentos
7.2.3. Atributos
7.2.4. Mecanismos avançados de abstração em um Modelo
ConceitualGovernança de Dados é responsável por gerir os
princípios de organização e controle de dados e informações. Esta gestão
envolve interface com diversas outras funções e estabelece políticas e
diretrizes corporativas para governar os dados, além de atribuir papéis e
responsabilidades.
Atualmente, o escopo de atuação da Governança de Dados é muito amplo.
Engana-se quem acha que a Governança de Dados atua somente no patamar
das normas e dos padrões ou ainda através de controles e permissões de
acesso a dados e informações. A Governança de Dados também atua com
uma visão mais apurada sobre os dados estratégicos da empresa, de�nindo-
os e analisando os processos que produzem e se abastecem desses dados.
A Governança de Dados é responsável por alinhar tecnologia, processos e
pessoas para de�nir os papéis, as responsabilidades e os processos
necessários para gerir os dados estratégicos da empresa. A �gura a seguir
demonstra esse alinhamento.
Figura 6.1 – Alinhamento entre pessoas, processos e tecnologia
Questões como: “Quais são os dados existentes? Quais são os dados
estratégicos? Quais dados são necessários? Quem possui acesso aos
seguintes dados? Quem é o Gestor de um determinado dado? O que
signi�ca este conceito? Quando este dado foi criado? Quando poderá ser
descartado? Onde está este dado? Onde é utilizado este dado? Como é
criado este dado? Como consigo acessar este dado? Quanto custa a gestão
deste dado?” são facilmente respondidas quando a empresa possui um
programa de Governança de Dados estabelecido.
Não é por acaso que a função está centralizada na �gura central do guia
DAMA-DMBOK®, fazendo interface com todas as demais funções,
in�uenciando direta ou indiretamente as atividades e os papéis envolvidos
na Gestão dos Dados.
Dentro da função “Governança de Dados” encontramos alguns papéis já
de�nidos. A �gura a seguir demonstra uma visão de papéis clássicos dentro
de qualquer iniciativa em Governança de Dados.
Figura 6.2 – Papéis clássicos em Governança de Dados
Os Gestores das Informações são as pessoas que representam as áreas
proprietárias das informações. Entende-se como área proprietária a
estrutura organizacional que origina ou adquire as informações. Somente os
gestores das informações podem de�nir questões sobre o uso dos dados, tais
como: classi�cação da segurança das informações, de�nição das permissões
e acessos às informações e opções de descarte.
Os Mantenedores, também conhecidos como custodiantes, são as
organizações responsáveis pela guarda e disponibilização das informações
conforme diretrizes estabelecidas pelos Gestores das Informações. Os
custodiantes não devem de�nir ou tomar decisões em relação às questões
sobre o uso dos dados que são de responsabilidade dos Gestores das
Informações. Entre os mantenedores conhecidos, podemos destacar a área
de TI ou empresas especializadas em guarda de informações, sejam elas
armazenadas na nuvem (cloud) ou não.
Os Criadores de Dados e Informações registram as informações dentro
das aplicações que armazenam os dados. Algumas aplicações também atuam
como criadores dos dados, onde, através de interfaces especí�cas, incluem
ou alteram os dados armazenados. Geralmente possuem acessos de criação,
edição e consulta às informações.
Os Consumidores dos Dados e informações são pessoas ou aplicações que
utilizam os dados armazenados para execução de algum propósito. Os
consumidores dos dados podem ser diretos, com acesso direto às
informações solicitadas (ex.: consulta online a uma aplicação) ou então
indiretos, onde o acesso à informação é obtido através de outras pessoas ou
aplicações.
O Staff da Gestão de Dados, formado por Gestores Técnicos de Dados,
Gestores Estratégicos de Dados e Gestores de Dados de Negócio, é
responsável por de�nir, orientar, executar, acompanhar e avaliar os
mecanismos de controle estabelecidos nos processos de Governança de
Dados.
Governança de Dados é considerada uma das mais importantes funções de
Gestão de Dados. Atualmente existem diversas fontes com frameworks e
modelos de maturidade disponíveis no mercado. Entre as principais fontes
podemos destacar o guia DAMA-DMBOK®, os frameworks do Data
Governance Institute e da IBM, além do modelo de maturidade proposto por
Tony Fisher, da Data�ux.
6.2. Razões para implantar a Governança de
Dados
As razões são muitas. Dependendo das particularidades de cada empresa,
cada razão pode ter um peso especí�co. Entre as razões mais comuns
podemos citar:
Ter subsídios para obter informações corretas, de fácil acesso e ágeis
para tomadas de decisões e inovações. Este é o desejo de todo executivo
de alto escalão.
Estabelecer a imagem de uma empresa sólida e con�ável. A�nal, na
mente do público, se a empresa é sólida, certamente os dados são
sadios e con�áveis.
Ter conhecimento completo dos dados do negócio da empresa e
disseminar todo este conhecimento para o restante da empresa
conforme política vigente.
Evitar prejuízos decorrentes da baixa qualidade dos dados. Dado de
baixa qualidade no mínimo gera retrabalho, aumentando os custos e
desperdiçando o tempo. Em casos mais graves, as empresas podem
perder grandes somas de dinheiro devido a decisões baseadas em
dados incorretos, ações na justiça ou multas e penalidades aplicadas
pelo setor público.
Redução nos custos de operações com os dados. Dados governados
requerem processos de criação, disponibilização e utilização de�nidos.
Em qualquer disciplina, quando temos as regras do jogo de�nidas e
aplicadas, a tendência natural é redução dos custos e ganho na
produtividade. A Governança de Dados é a função responsável por
de�nir essas regras.
Tornar a empresa apta para seguir novas regulamentações.
Dependendo do ramo de atuação, é comum haver exigências a respeito
dos controles internos da empresa. A lei Sarbanes-Oxley e o acordo de
Basileia são exemplos de regulamentações aplicadas em setores
especí�cos para garantir uma melhor governança, não só dos dados,
mas de toda a empresa.
Diminuir os custos do desenvolvimento das aplicações através da
diminuição do retrabalho, da eliminação de silos redundantes e da
disseminação dos processos de Gestão de Dados vigentes.
Evitar fraudes devido à ausência de processos formais de controle ou
existência de processos de Gestão de Dados mal de�nidos ou
executados.
6.3. Princípios da Governança de Dados
Quando falamos em Governança de Dados, devemos ter em mente alguns
princípios básicos que regulamentam essa função e devem ser adotados em
qualquer iniciativa de implantação ou uso desta função. Os princípios são:
Governança de Dados é Gestão de Dados Estratégica. Governança de
Dados é Gestão de Dados de�nida e aplicada nos altos níveis da
empresa pelos executivos. Em suma, Governança de Dados é a tomada
de decisões a respeito de Gestão de Dados pela alta administração.
Tentar emplacar alguma iniciativa de Governança de Dados sem prever
esta premissa é assinar a sentença de morte do programa. Iniciativas de
Governança de Dados não devem começar nem ser somente aplicadas
nos níveis táticos e operacionais das empresas.
Governança de Dados requer patrocínio. Este patrocínio deve ser
constante em todo o programa. Claro que nas fases iniciais o patrocínio
se torna mais evidente por questões de estratégia de implantação e
divulgação do programa, porém sempre deverá existir no decorrer do
programa, sob pena das novas iniciativas não serem totalmente
adotadas devido a diversos fatores, desde os culturais (como resistência
a mudanças) até os �nanceiros, cuja falta impacta o andamento e a
conclusão das iniciativas. Vale ressaltar também que no decorrer do
programa os patrocínios podem mudar. Como veremos mais adiante,
as iniciativas de um programa serão gerenciadas por Comitês de
Governança e priorizadas pelo Conselho de Governança de Dados.
Cada uma das iniciativas poderá ter um ou mais patrocinadores
especí�cos.
Governança de Dados é um governo. A Governança de Dados
funciona de forma semelhante a um governo. Se �zermos uma
analogia, poderemos entender que:
A Governançade Dados Legislativa pode ser entendida como a de�nição de
normas, políticas, procedimentos e padrões que devem ser adotados pela
Gestão de Dados Executiva.
A Governança de Dados Executiva administra as políticas, a arquitetura e os
serviços de�nidos.
Já a Governança de Dados Judiciária é responsável por gerir as questões de
con�ito ora existentes em todos os níveis onde a Governança de Dados é
adotada.
Governança de Dados é um programa. A Governança de Dados não
pode simplesmente ser adotada através de um projeto. Segundo a
de�nição, um projeto é um esforço temporário empreendido para criar
um produto, serviço ou resultado exclusivo. Os projetos são exclusivos
(únicos), possuem tempo e orçamentos limitados.
Mesmo após um projeto inicial de implantação, para adotar a Governança
de Dados de forma efetiva, vários projetos serão necessários no decorrer do
tempo. As necessidades desses projetos serão de�nidas nas reuniões
periódicas do Conselho de Governança de Dados. Vale destacar que um dos
objetivos da Gestão de Dados Estratégica é a melhoria contínua da
qualidade dos dados e também dos processos de gestão adotados para esses
propósitos. Portanto, enquanto houver uma Governança de Dados efetiva,
haverá também projetos de melhoria, voltados à obtenção da excelência no
uso dos dados da empresa.
6.4. Componentes da Governança de Dados
Pessoas, processos e tecnologia são os três componentes comuns em todos
os programas de Governança de Dados. Esses componentes devem atuar de
forma integrada com o propósito de efetivar a política e a estratégia de
dados de�nidas para o programa de Governança de Dados. A �gura a seguir
demonstra os componentes da Governança de Dados.
Figura 6.3 – Componentes da Governança de Dados
6.4.1. Pessoas
As pessoas são os recursos humanos envolvidos direta ou indiretamente
nas atividades de Governança de Dados. São elas que executam ou são
responsáveis pelas ações da Governança de Dados. São representadas pelos
pro�ssionais de negócio (Executivos, pro�ssionais de Gestão de Dados
ligados ao Negócio, gestores e usuários das informações) e também pelos
pro�ssionais de tecnologia (gerentes, gestores de dados ligados à TI e demais
técnicos).
O Programa de Governança de Dados deve prever, de forma constante, a
conscientização e a capacitação das pessoas nos objetivos do programa, nos
processos executados e também nas ferramentas utilizadas nas atividades.
6.4.2. Processos
Os processos de�nem a forma de trabalho e as “regras do jogo” da
Governança de Dados na empresa.
Um processo de�ne quem está fazendo o quê, quando e como, a �m de
atingir certo objetivo. Em Governança de Dados, os processos são divididos
em duas grandes frentes. A primeira representa os processos da área de
negócios, que são aplicados quando os dados entram ou mudam de status
no seu ciclo de vida. Aqui a existência de uma Arquitetura de Dados que
contemple a execução desses processos é fundamental para o sucesso de
qualquer programa de governança.
A segunda frente representa os processos da própria área de Gestão de
Dados, que são adotados de forma comum em todas as atividades
necessárias para garantir a governança dos dados, independentemente das
áreas onde os dados são (ou serão) utilizados. Esses processos devem
compor a metodologia de Gestão de Dados vigente.
A existência de processos mapeados e homologados em ambas as frentes é
um requisito obrigatório para a adoção da Governança de Dados nas
empresas.
6.4.3. Tecnologia
Já a tecnologia é formada pelo hardware, com servidores e demais
mecanismos de infraestrutura hospedando as soluções de soware e demais
ferramentas que apoiam a execução dos processos mapeados e executados
pelas pessoas. Entre os principais sowares e ferramentas podemos citar:
SGBDs, ferramentas de Modelagem de Dados, repositórios de modelos de
dados, repositórios de metadados, ferramentas de MDM3, ferramentas de
Qualidade de Dados e ferramentas customizadas para apoiar as atividades.
6.5. Documentos da Governança de Dados
Os documentos da Governança de Dados fazem parte da metodologia de
Gestão de Dados das empresas. De forma geral, eles são elaborados pelo staff
de pro�ssionais da Gestão de Dados e validados e aprovados pelos
executivos seniores das empresas.
Os documentos circulam em vários níveis da empresa. Os documentos de
alto nível estabelecem os objetivos e as diretrizes no patamar da estratégia de
dados. Já os procedimentos e roteiros orientam as atividades rotineiras de
controle da Governança de Dados.
6.5.1. Estratégia de Dados
Quando estabelecemos um programa de Governança de Dados, devemos
ter em mente quais são os objetivos, as principais premissas e as direções
que devem ser seguidas para traçar planos de ação de alto nível que
permitam atingir as metas estratégicas acerca dos dados. Vale ressaltar que
as metas estratégicas devem estar aderentes às estratégias do negócio.
Essas informações são geralmente de�nidas em um documento de alto
nível que representa a Estratégia de Dados da empresa.
A Estratégia de Dados é o principal documento que formaliza e reconhece
as atividades de Gestão e Governança de Dados na empresa. Através dela
conseguimos dar reconhecimento formal às atividades e também
institucionalizar áreas e organizações de apoio que irão atuar na Gestão dos
Dados da empresa. Também é importante destacar no documento o
reconhecimento do dado como um importante ativo da empresa.
A criação e guarda deste documento é feita pelo Conselho de Governança
de Dados. Sua divulgação deve ser ampla. A Estratégia de Dados é um
documento que deve circular em todos os níveis da empresa, desde a
presidência e os conselhos até o chão de fábrica.
De forma geral, os componentes comuns de uma estratégia de dados são os
seguintes:
Missão e visão para a Gestão de Dados na empresa.
Contribuição da Gestão de Dados à estratégia da empresa.
Princípios orientadores, valores e crenças referentes à Gestão de Dados.
Institucionalização, objetivos e metas do programa de Governança de
Dados.
Descrição das organizações de apoio à Gestão e Governança de Dados,
bem como suas responsabilidades.
Descrição dos papéis atuantes na Gestão de Dados, bem como suas
responsabilidades.
Outros componentes podem ser incluídos na Estratégia de Dados: caso de
negócios, medidas de sucesso, indicadores de desempenho estratégico,
iniciativas de Gestão de Dados, etc. Conforme dito antes, não existe uma
receita de bolo especí�ca em Gestão e Governança de Dados. Cabe a cada
empresa avaliar e implementar o que achar de melhor em sua Estratégia de
Dados.
6.5.2. Política de Dados
As políticas de dados são regras gerais e fundamentais que devem ser
adotadas pelos pro�ssionais envolvidos com os dados, desde o seu projeto,
criação, utilização, até o descarte.
As políticas de dados são elaboradas por pro�ssionais de Gestão de Dados,
tanto da área técnica quanto de negócio. Ao contrário da estratégia de
dados, que é escrita em um documento único, as políticas de dados podem
ser escritas em vários documentos, geralmente divididas nas funções de
Gestão de Dados adotadas pela empresa. Exemplos:
Política para Arquitetura de Dados.
Política para Modelagem de Dados.
Política para Integração de Dados.
Ao contrário da Estratégia de Dados, a Política de Dados é escrita por
pro�ssionais de Gestão de Dados. Seu conteúdo é resultante do trabalho de
algum Comitê de Gestão de Dados. É extremamente recomendável que as
políticas sejam validadas pelo Conselho de Gestão e Governança de Dados.
Quanto à visibilidade dos documentos, ao contrário da Estratégia de
Dados, as políticas de dados não precisam ser conhecidas por todos os
integrantes de uma empresa. Geralmente a divulgação e o acesso aos per�s
que estarão envolvidos nas atividades de Gestão de Dados são su�cientes.
6.5.3. Normas e padrões
Normas e padrões são documentos que regulamentam a criação de
artefatos resultantes das atividades previstas dentro dos processos de Gestão
de Dados. Esses documentos têm caráter normativo, ou seja, o cumprimentodo que está escrito no documento deve ser respeitado.
Como características principais, normas e padrões descrevem o que fazer e
o que não fazer. São diferentes dos procedimentos e roteiros que descrevem
como fazer.
Entre exemplos de Normas e Padrões comuns podemos destacar:
Padrão de nomenclatura de objetos de banco de dados.
Padrão de nomenclatura para Modelagem de Dados.
Padrão para solicitação de acesso a dados corporativos.
Norma para segurança da informação.
Algumas pessoas costumam perguntar quando se usa uma norma e
quando se usa um padrão – além disso, qual a diferença entre eles?
Em Gestão de Dados, não existe uma de�nição padrão para cada tipo de
documento. De forma geral, costumo adotar o seguinte critério:
se o conteúdo é comum no mercado e existe algum documento de
referência escrito por alguma entidade o�cial técnica ou regulamentar
(exemplo: ISO, ABNT, etc.); e
se boa parte do conteúdo do documento será utilizada, classi�co o
documento como norma. Se o documento é interno, adaptado às
características da empresa, classi�co o documento como padrão.
Algumas pessoas costumam discordar do critério citado e alegar que
norma é algo obrigatório e o padrão não, pois este representaria uma prática
recomendada e de ampla aceitação no mercado, mas não tornada
obrigatória.
Eu discordo deste argumento, pois a justi�cativa dada para um padrão é
mais bem de�nida para outro tipo de documento: a boa prática. No meu
ponto de vista, um padrão também é obrigatório, pois estabelece um
formato, gabarito ou forma que algo deve seguir. Sem esta obrigatoriedade o
padrão cai em desuso.
6.5.4. Procedimentos
Ao contrário de normas e padrões que são documentos normativos, os
procedimentos ou roteiros têm como principal característica orientar as
pessoas na execução de algo para atingir algum propósito, seja ele uma
simples requisição, produção de um artefato ou operação de manipulação
dos dados. Na prática, os procedimentos são uma espécie de “receita de
bolo”. Entre exemplos de procedimentos e roteiros podemos citar:
Roteiro para solicitar tarefas à equipe de Gestão de Dados.
Roteiro para carregar metadados no repositório de metadados.
Procedimento para efetuar engenharia reversa em bancos de dados.
Procedimento para solicitar acesso a bases de dados.
6.6. Estruturas formais de apoio à Gestão de
Dados
As estruturas formais são grupos de apoio formados por pro�ssionais que
atuam ou têm alguma interação com a disciplina de Gestão de Dados. De
forma geral, fornecem suporte às demais equipes de Gestão de Dados e
atuam em processos decisórios, como é o caso dos integrantes do Conselho
de Governança de Dados. Sua atuação abrange desde o nível operacional e
tático até a passagem pelo nível estratégico, onde o Conselho de Governança
de Dados de�ne as principais diretrizes de gestão e governança que serão
adotadas por toda a empresa.
As estruturas são formalmente constituídas e geralmente possuem
lideranças que respondem pelos passos e pelas decisões das estruturas.
Dependendo da maturidade da empresa, elas podem ser adotadas em
conjunto, como no caso das empresas mais maduras em Gestão de Dados,
ou então isoladas, onde apenas uma ou duas estruturas são adotadas na
empresa.
Vale ressaltar que, ao adotar pelo menos uma das estruturas formais de
apoio, a empresa já possui um nível razoável de maturidade.
A �gura a seguir mostra como as estruturas formais de apoio à Gestão de
Dados podem ser adotadas nas empresas.
Figura 6.4 – Estruturas de apoio à Governança de Dados
6.6.1. Escritório de Gestão de Dados
Dependendo do tamanho da empresa e do volume de solicitações aos
pro�ssionais de Gestão de Dados, pode se tornar necessária a criação de um
Escritório de Gestão de Dados.
Este escritório pode ser composto por Gestores Técnicos de Dados e
Gestores Estratégicos de Dados, que atuam como facilitadores e prestam
suporte às atividades e à tomada de decisão dos gestores de dados de
negócio em todos os níveis.
Um dos objetivos principais deste escritório é oferecer suporte em tempo
integral para os gestores de dados de negócio, gestores técnicos de dados e
também, quando necessário, aos gestores das informações.
Este suporte pode ser dado tanto no nível operacional, oferecendo mão de
obra especializada para execução das tarefas que costumam ser “braçais” e
“repetitivas”, como no nível tático, onde os Gestores Estratégicos de Dados e
Gestores de Dados Seniores (técnicos e de negócios) oferecem suporte tático
na utilização da disciplina.
Todas as atividades executadas pelo escritório, sejam elas operacionais e/ou
táticas, são importantes subsídios para alimentar os indicadores dos
processos e fontes de informação precisas para tomada de ações em um
nível maior.
A tabela a seguir demonstra alguns exemplos de atividades executadas por
Escritórios de Gestão e Governança de Dados.
Atividade Tipo
Alimentar indicadores de utilização e qualidade dos dados e estruturas
de dados Operacional
Avaliar modelos de dados Operacional
Disponibilizar conceitos de entidades Operacional
Efetuar treinamento em Gestão de Dados Operacional
Implementar modelos homologados em ambientes de banco de dados Operacional
Prestar suporte na utilização da metodologia de Gestão de Dados
vigente Operacional
Disponibilizar relatórios sobre o uso de entidades corporativas Operacional
Prestar suporte em atividades de consultas a banco de dados Operacional
Solicitar permissão de acesso aos Gestores de Informação Operacional
Disponibilizar modelos de dados Operacional
Efetuar análise de impacto dos dados em relação às mudanças Operacional
Apoiar a de�nição de conceitos corporativos Tática
Avaliar indicadores de utilização e qualidade dos dados e estruturas de
dados Tática
Avaliar metodologia de Gestão de Dados vigente Tática
Identi�car e planejar necessidades de capacitação em Gestão de Dados Tática
Identi�car fontes de informações redundantes Tática
De�nir/Reavaliar o processo de Governança de Dados Tática
Monitorar as atividades executadas pelo escritório Tática
Identi�car e propor Gestores de Informação Tática
Tabela 6.1 – Relação das atividades que podem ser prestadas por um Escritório de
Gestão e Governança de Dados
Em alguns casos, as empresas optam por ter dois escritórios: um voltado às
tarefas operacionais e outro de mais alto nível, atuando no nível tático.
A de�nição do escopo das tarefas atendidas pelo Escritório de Gestão de
Dados varia a cada empresa. Por exemplo, um Gestor Técnico de Dados
pode atuar de forma mais ampla dentro de uma equipe de Gestão de Dados,
orientando a Modelagem de Dados e apoiando os analistas na busca de
informações compartilhadas, enquanto outro Gestor Técnico de Dados atua
exclusivamente dentro do Escritório de Gestão e Governança de Dados
avaliando os modelos de dados produzidos com o apoio do primeiro Gestor
Técnico de Dados. Enquanto isso, o Gestor Estratégico de Dados propõe
ações de melhoria em cima dos resultados coletados neste tipo de tarefa.
O Escritório de Governança de Dados geralmente se reporta ao Executivo
de Gestão de Dados (CDO).
6.6.2. Comitês de Gestão de Dados
Os Comitês de Gestão de Dados atuam no nível tático da empresa e são
responsáveis por tratar novas iniciativas ou ações de melhoria propostas
pelo Conselho de Gestão e Governança de Dados.
Os comitês podem ser vários e tratam de assuntos especí�cos ligados à
disciplina de Gestão de Dados. Esses assuntos podem estar ligados ao uso de
tecnologia, ao negócio ou a ambos; portanto, não há uma fórmula mágica
para estabelecer quem são as pessoas indicadas a participar de cada comitê.
A participação do Gestor Estratégico de Dados é requerida na maioria dos
comitês, porém isto não é uma regra.
Os comitês funcionam como uma estrutura de projetos, ou seja, são
temporários, se destinam a atingir objetivos claros e de�nidos e são
conduzidos por pessoas dentro de parâmetros prede�nidos de tempo, custo
e recursos envolvidos.
A periodicidade dos encontros dos comitês é mais frequente, sendo
geralmentesemanais ou quinzenais. Ao �m de cada encontro o cronograma
das ações do comitê é revisto e podem ser de�nidas novas tarefas, que
deverão ser atendidas pelos membros dos comitês. Os resultados são
acompanhados pelo Conselho de Gestão e Governança de Dados.
Se o Gerente do Comitê de Gestão de Dados identi�car que o assunto
tratado no âmbito do comitê é repetitivo e contínuo, ele deve imediatamente
sugerir a sua dissolução e encaminhar o trabalho para uma equipe de
atendimento dedicada ou uma comissão gestora.
A tabela a seguir mostra alguns exemplos de Comitês de Gestão de Dados.
Nome do
comitê Objetivos/Duração estimada Participantes Gerente
do comitê
Dados
Mestres de
RH
Objetivo: implantar a função de
Gerenciamento de Dados
Mestres na área de RH da
empresa. O escopo do trabalho
envolve: a) Adoção da
metodologia de MDM vigente.
b) De�nição dos Dados Mestres
de RH.
c) Adequação dos Dados
Mestres de RH à arquitetura de
MDM existente.
d) Utilização dos dados de
referência existentes.
e) Adoção do processo de
governança.
Gestor de Dados de
Negócio (RH) Gestor
Estratégico de Dados
Representante da equipe
de Gestão Técnica de
Dados Gestor de Dados
de Negócio (Financeiro)
Representante da
Infraestrutura
Representante do Cliente
(RH)
Gestor de
Dados de
Negócio
(RH)
f ) Criação e acompanhamento
de indicadores de qualidade e
utilização.
Duração estimada do comitê:
doze meses.
Qualidade
na
Modelagem
de Dados
Objetivo: elevar o grau de
qualidade dos modelos de
dados produzidos pelos
Gestores de Dados de Negócio e
Projetistas de Dados.
Duração estimada do comitê:
seis meses.
Gestor Estratégico de
Dados Gestores de Dados
de Negócio Gestores
Técnicos de Dados
Projetista de Dados
Gestor
Estratégico
de Dados
Integração
da empresa
XPTO
Objetivos: integrar os dados da
empresa XPTO, recém-adquirida,
com os demais dados mestres e
de referência da holding. O
escopo da integração envolve: a)
Utilização dos Dados Mestres e
de referência das áreas de RH e
�nanceiro, utilizados na holding
pela empresa XPTO.
b) Estudo do impacto para
adoção.
c) Adoção de metodologia de
Gestão e Governança de Dados
vigente pela empresa XPTO.
d) Criação de uma Arquitetura
de Dados aderente à arquitetura
utilizada na holding.
Obs.: o trabalho do comitê
acarretará na alteração dos
sistemas em desenvolvimento.
Duração estimada do comitê:
dezoito meses
Executivo da Gestão de
Dados Gerente da equipe
de Gestão Técnica de
Dados Gestores de Dados
de Negócio Gestores
Técnicos de Dados Gestor
Estratégico de Dados
Gerente da
equipe de
Gestão
Técnica de
Dados
Tabela 6.2 – Exemplos de relações de Comitês de Gestão de Dados vigentes em
uma empresa
6.6.3. Conselho de Governança de Dados
Este conselho é a maior autoridade em Gestão e Governança de Dados na
empresa. É formado pelo Executivo de Gestão de Dados (CDO) e também
por executivos da alta administração da empresa (gerentes seniores e
diretores).
O objetivo deste conselho é chancelar as decisões, estratégias e diretrizes de
Gestão e Governança de Dados dentro do âmbito estratégico da empresa.
Os assuntos tratados neste conselho estabelecem todas as diretrizes que
devem ser adotadas em relação à Gestão e Governança de Dados em toda a
empresa.
É recomendado que o comitê seja presidido por um executivo com alto
prestígio e poder na empresa, preferencialmente o Presidente ou Vice-
Presidente. Cabe ao Executivo de Gestão de Dados (CDO) atuar como um
importante facilitador neste conselho, assessorando a direção do Comitê.
Uma das cadeiras deste comitê também deve ser reservada para um
integrante da área de TI. As demais cadeiras deste comitê são destinadas aos
executivos das áreas de negócio da empresa.
Em alguns casos, a direção do conselho pode ser feita pelo CDO ou então
pelo representante da área de TI, porém deve-se ter em mente que este tipo
de abordagem irá requerer um esforço adicional para manter as áreas de
negócio alinhadas aos propósitos da gestão estratégica de dados.
O termo “Governança” deve compor obrigatoriamente o nome do comitê.
A Governança de Dados é considerada uma função estratégica, de alto nível,
tratada na esfera executiva das empresas; portanto, nada mais adequado do
que utilizar este termo na nomenclatura do comitê.
Um Conselho de Governança de Dados atua em forma de encontros
periódicos. Recomenda-se uma periodicidade mínima de dois meses entre
cada encontro. Além dos integrantes �xos do conselho, as reuniões podem
contar com convidados especiais que fornecem subsídios para tomadas de
decisões que são discutidas em cada encontro.
O resumo de cada encontro, as decisões e as ações propostas são
divulgados para todos os envolvidos.
Em casos especiais, o Conselho de Governança de Dados também pode
delegar responsabilidades para um ou mais Comitês de Gestão de Dados em
caso de sobrecarga nos assuntos que são tratados.
A �gura a seguir mostra um exemplo da composição das cadeiras
(membros ativos) de um conselho de Gestão e Governança de Dados.
Figura 6.5 – Membros atuantes em uma reunião do Conselho de Governança de
Dados
6.7. Dicas para implantar um programa de
Governança de Dados
Seguem algumas dicas úteis na implantação de um programa de
Governança de Dados.
Entenda todas as referências sobre Governança de Dados e utilize o que há
de melhor nelas.
Sem dúvida alguma, o guia DAMA-DMBOK® possui um dos mais
completos frameworks sobre o assunto Governança de Dados, entretanto,
outras referências devem ser levadas em consideração na hora de desenhar o
modelo de governança que será adotado no programa.
O framework do Data Governance Institute utiliza uma abordagem não tão
completa, mas possui um visual simples do que deve ser feito em um
programa de Governança de Dados.
O processo uni�cado de Governança de Dados da IBM fornece um passo a
passo simples para implantação inicial de um programa de Governança de
Dados.
En�m, nenhuma referência deve ser adotada como uma única receita de
bolo. Cabe a cada empresa avaliar as características de cada escola/referência
e adotar o que mais se adequa à realidade da empresa.
Obtenha um patrocinador forte
Esta dica é fundamental para implantação de qualquer atividade
estratégica dentro de uma empresa. O CDO terá um papel importante na
adoção de um programa de Governança de Dados, porém, sozinho, atuando
como patrocinador único, fatalmente não conseguirá o apoio das demais
áreas executivas. O patrocinador ideal para uma iniciativa como esta deveria
vir da própria direção da empresa (presidente ou vice) ou então do conselho
administrativo. Patrocinadores com peso político e de poder inferior ao
CDO devem ser descartados.
Entender que a Governança de Dados é um programa e não um mero
projeto
A adoção da Governança de Dados nas empresas tem as características de
continuidade e evolução ininterrupta. O andamento dos processos deve ser
constantemente analisado e melhorado através de projetos visando à
melhoria contínua da governança.
Se encararmos a governança como um simples projeto perderemos essa
visão, tornando o uso da Governança de Dados limitada a características e
requisitos do seu projeto de implantação, sem evoluir durante o tempo.
Utilize a Arquitetura de Dados como um dos principais instrumentos de
apoio às atividades de Governança de Dados
Não existe um programa de Governança de Dados e�caz sem uma
Arquitetura de Dados Corporativos já de�nidos. Os modelos de dados
representados na Arquitetura de Dados são úteis à Governança de Dados
para:
Identi�car os principais metadados corporativos.
Identi�car os Gestores das Informações.
Identi�car os dados críticos da empresa.
Identi�car os níveis de segurança dos dados corporativos.
Delimitar fronteiras.
Servir de base para de�nição dos escopos dos projetos de Governança
de Dados.
Fornecer uma visão única sobre o acervo dos dados.
Estabeleça no mínimo um Conselho de Governança de Dados e um Comitê
de Gestão de Dados
Os integrantes do Conselho de Governança de Dados atuam nos mais altos
níveis estratégicos da empresa. Decisões a respeito dosdados estratégicos
devem ser tomadas aqui, neste canal. Um dado corporativo e estratégico �ui
dentro de várias áreas da empresa. Estando todos os representantes dessas
áreas reunidos em um comitê, a decisão é tomada de forma consensual e
rápida. Sem o Conselho, a decisão seria demorada, nem sempre consensual
e, além disso, corre-se o risco do processo decisório �car perdido dentro da
burocracia da empresa.
Já um Comitê de Gestão de Dados tem como principal objetivo tratar de
iniciativas especí�cas sobre a Gestão de Dados, geralmente implementadas
através de projetos. Se um programa de Governança de Dados é contínuo,
com iniciativas sendo implantadas no decorrer do tempo, não há sentido em
não haver no mínimo um Comitê de Gestão de Dados vigente.
Implemente a Governança de Dados através de passos sequenciais e em
etapas
A implementação deve ser feita de forma gradual. A abordagem de
implantação em projetos-piloto, divididos por áreas de negócio, costuma ser
uma boa estratégia. Quanto aos passos para implantação, não existe uma
fórmula especí�ca. A IBM, através do seu Data Governance Framework,
criado por Sunil Soares, estabelece quatorze passos sequenciais que podem
ser adotados para implantar um programa de Governança de Dados:
1. De�nir os problemas do negócio.
2. Obter patrocinador executivo.
3. Realizar avaliação da maturidade.
4. Desenvolver roteiros.
5. Estabelecer modelo de dados da organização.
6. Desenvolver Dicionário de Dados.
7. Entender os dados.
8. Criar repositórios de metadados.
9. De�nir métricas.
10. Gerir dados mestres incluindo: governar dados mestres, gerenciar
qualidade dos dados e implementar MDM.
11. Governar dados analíticos.
12. Gerenciar segurança e privacidade.
13. Gerenciar ciclo de vida da informação.
14. Medir resultados.
Vale ressaltar que os passos 10, 11, 12 e 13 são opcionais.
6.8. Atividades necessárias para manter um
programa de Governança de Dados segundo o
DAMA-DMBOK®
Já vimos neste capítulo que um programa de Governança de Dados é
contínuo e envolve vários papéis e atividades. O Guia DAMA-DMBOK®
estabelece uma série de atividades divididas em dois grupos: Planejamento
da Gestão de Dados e Controle da Gestão de Dados. As de�nições e os
conceitos passados durante esse capítulo são fundamentais para o
entendimento das tarefas indicadas pelo guia.
Entre as tarefas do Planejamento da Gestão de Dados, o guia indica:
Entender as necessidades estratégicas de dados da organização: ou
seja, para onde a empresa caminha e quais dados são necessários para
prosseguir nessa jornada.
Desenvolver e manter a estratégia de dados: criar documento de alto
nível alinhado à estratégia da empresa para institucionalizar a
Governança de Dados na empresa.
Estabelecer os papéis dos pro�ssionais e das organizações de dados:
é a formalização dos papéis dos Gestores de Dados, do Executivo de
Dados, dos Gestores da Informação e das estruturas que fornecem
apoio às atividades de Governança de Dados, como as equipes de
Gestão de Dados, Conselho e Comitês de Gestão de Dados.
Identi�car e apontar os gestores dos dados: signi�ca selecionar os
Gestores de Dados de Negócio que atuarão em cada segmento.
Estabelecer organizações de Gestão e Governança de Dados (áreas
de apoio): é a implementação das estruturas de apoio e dos papéis
estabelecidos anteriormente. Aqui novos papéis e estruturas começam
a atuar efetivamente.
Desenvolver e aprovar políticas, padrões e procedimentos de dados
(documentos da Governança de Dados): é o desenvolvimento de toda
a metodologia que suportará os processos de Gestão e Governança de
Dados.
Rever e aprovar a Arquitetura de Dados: é a análise da Arquitetura de
Dados atual e, se necessário, a criação de planos de ação para
estabelecer uma Arquitetura de Dados alinhada à estratégia da
empresa.
Planejar e patrocinar projetos e serviços de Gestão de Dados: é a
identi�cação, de�nição, priorização e o planejamento dos projetos
necessários à implantação de uma Governança de Dados efetiva.
Estimar o valor dos ativos de dados e custos associados: é a valoração
dos custos positivos (ligados ao reuso, à mudança de cultura, etc.) e
negativos (ligados aos riscos da imagem e reputação) dos dados
estratégicos da empresa.
Já entre as tarefas do Controle da Gestão de Dados, o guia indica:
Supervisionar equipes e organizações pro�ssionais de dados: através
da atuação do Executivo de Gestão de Dados, pessoas (gerentes e
coordenadores de dados) e estruturas que apoiam a Gerência
Estratégica de Dados.
Coordenar atividades de Governança de Dados: através dos
pro�ssionais que atuam em posição de liderança em suas funções.
Gerenciar e resolver questões relacionadas aos dados: geralmente
através das reuniões do Conselho de Governança de Dados ou Comitês
de Gestão e Governança de Dados.
Monitorar e forçar o cumprimento dos regulatórios: através de
veri�cações pontuais.
Monitorar e forçar a conformidade com as políticas, os padrões e as
arquiteturas de dados: através de veri�cações rotineiras executadas
pelos pro�ssionais de Gestão de Dados.
Supervisionar projetos e serviços de Gestão de Dados: através dos
pro�ssionais de Gestão de Dados, com o apoio da metodologia de
Gestão e Governança de Dados vigente.
Comunicar e promover o valor dos ativos de dados: através dos
pro�ssionais de Gestão de Dados em workshops, canais de divulgação e
no contato diário em suas atividades.
7. Modelagem de Dados
“A obediência ao dever é uma resistência a si mesmo.”
Henri Bergson
7.1. Modelagem de Dados – Principais conceitos
Podemos de�nir Modelagem de Dados como um processo onde, através
do levantamento dos requisitos de informação e regras de negócio,
aplicando técnicas e mecanismos de abstração, construímos artefatos
(modelos de dados) com uma visão estática das aplicações nas quais os
dados serão armazenados.
Os modelos de dados são artefatos que representam de forma estática a
captura dos requisitos de informação e as regras de negócio através das
entidades (ou classes), atributos, relacionamentos e demais regras
representadas em formas grá�cas e textuais.
Atualmente a Modelagem de Dados não é encarada como uma função
especí�ca dentro da versão atual do guia DAMA-DMBOK®. No guia, a
Modelagem de Dados está inclusa na função “Desenvolvimento dos Dados”,
junto com outras atividades focadas em dados dentro do ciclo de vida do
desenvolvimento de aplicações, tais como: levantamento e análise dos
requisitos, implementação dos modelos de dados nos SGBDs e
disponibilização de dados armazenados nos SGBDs.
Entretanto, segundo os dras da próxima versão do DMBOK®, a função
“Desenvolvimento de Dados” será extinta e será criada uma nova função
denominada Modelagem e Projeto de Banco de Dados. Ou seja, em um
futuro próximo haverá uma função especí�ca para Modelagem e Projeto de
Banco de Dados no guia DAMA-DMBOK®.
Além disso, as funções de implementação dos modelos estarão na nova
função “Armazenamento dos Dados”, e as formas de consumo dos dados
armazenados serão detalhadas na função “Integração de Dados”.
Esta mudança será muito positiva. A�nal, este artefato é tido como um dos
principais da Gestão de Dados. Atualmente, considero a Modelagem de
Dados uma das principais funções, mesmo que ainda não o�cializada, da
Gestão de Dados.
Os modelos de dados são utilizados em várias funções da Gestão de Dados.
Como exemplo, podemos citar as funções:
Arquitetura de Dados: onde os modelos de dados corporativos são
representados, fornecendo informações das principais entidades de
negócio corporativas da empresa.
Governança de Dados: os modelos de dados exercem um importante
papel nesta função. Através deles podemos identi�car quais gestores
das informações, pessoas ou aplicações têm acesso aos dados
representados em cada modelo.
Modelagem de Dados: função especí�ca para análise, especi�cação e
implementação dos modelos de dados. É nesta função que os modelos
de dados são criados.
Integração das informações: os mecanismos de integração de
informação podem ser representadosnos modelos de dados. Várias
ferramentas para Modelagem de Dados fornecem recursos para criação
de propriedades especí�cas, onde as informações sobre os mecanismos
de integração utilizados podem ser representadas facilmente.
Gestão de Metadados: boa parte dos metadados das empresas é
representada através dos modelos de dados das aplicações. A gestão de
todos esses modelos, incluindo a sua guarda e disponibilidade, é feita
através da função Gestão de Metadados.
As técnicas de construção e representações acerca dos modelos de dados
são muitas. Este livro irá trabalhar com as formas mais tradicionais de
modelagem relacional adotadas pelo mercado.
Os modelos de dados são criados e ajustados dentro de várias fases do ciclo
de vida do sistema. Para cada fase são recomendados modelos com
diferentes graus de abstração, representação e detalhamento. Esta
abordagem resulta em uma divisão onde três tipos de modelos são adotados.
São eles:
Modelo Conceitual de Dados.
Modelo Lógico de Dados.
Modelo Físico de Dados.
Os próximos itens detalharão as técnicas e os conceitos básicos para a
construção desses modelos.
7.2. Modelo Conceitual de Dados
Um Modelo Conceitual de Dados é de alto nível. Sua principal �nalidade é
capturar os requisitos de informação e regras de negócio sob o ponto de
vista do negócio. Ou seja, é um modelo que não sofre interferência de
fatores tecnológicos e de projeto em sua construção. É um modelo não
tecnológico e não implementável.
É o primeiro modelo que deve ser desenvolvido, já na fase de levantamento
de requisitos, preferencialmente pelo Gestor de Dados de Negócio ou outro
pro�ssional acompanhado de sua supervisão/orientação.
Entre os componentes de um modelo conceitual, podemos relacionar:
Entidades.
Atributos.
Relacionamentos.
Regras de Negócio.
As formas de representação dos componentes mudam nas diversas
notações utilizadas no mercado (Peter Chen, James Martin, IDEF1X,
Merise, etc.). Este livro adotará uma adaptação da notação do Peter Chen na
representação dos modelos conceituais de dados.
Também vale a pena destacar o crescimento de modelos conceituais
desenvolvidos seguindo a representação da UML4. Neste caso, é utilizado o
diagrama de classes com a representação das classes de negócio.
7.2.1. Entidades
Formam um conjunto de coisas com conceitos comuns onde desejamos
armazenar os dados. Entidades podem ser pessoas, lugares, organizações e
objetos físicos e tangíveis.
As entidades são representadas através de um retângulo com o seu nome
escrito em seu centro. Conforme �gura a seguir, as entidades são
classi�cadas em dois tipos: forte e fraca.
Figura 7.1 – Notação de entidade forte x entidade fraca
As entidades fortes possuem um alto grau de independência de existência
de identi�cação. Outras entidades podem depender dela para serem
identi�cadas. Podemos tomar como exemplo a entidade “BANCO”, cuja
existência não depende de nenhuma outra entidade para ser identi�cada.
As entidades fracas possuem dependência de existência e/ou identi�cação.
São sempre ligadas a outras tabelas através de relacionamentos. Podemos
tomar como exemplo a entidade “AGÊNCIA”, cuja existência e identi�cação
estão vinculadas a outra entidade forte – no caso, o “BANCO”.
7.2.2. Relacionamentos
Relacionamentos são associações entre entidades com um signi�cado
especí�co dentro do mundo real. Os objetos do mundo real não ocorrem de
forma isolada; eles se associam ou se vinculam.
Um relacionamento é representado através de um losango e, tal como as
entidades, é classi�cado em forte ou fraco. Tal como as entidades, os
relacionamentos também possuem nome e devem expressar o real
signi�cado dentro do contexto modelado. A �gura a seguir mostra como os
relacionamentos são representados em um Modelo Conceitual de Dados.
Figura 7.2 – Notação de relacionamento forte e relacionamento fraco
Na �gura anterior, “DEPENDENTE” é uma entidade fraca em relação ao
“EMPREGADO”. Sempre que esta relação existir de forma fraca, o
relacionamento também será fraco; por esta razão o losango desta relação
está representado com uma linha dupla. Já na relação entre “EMPREGADO”
e “CARGO” não há dependência de existência ou identi�cação, pois um
“CARGO” não depende de um “EMPREGADO” para existir e ser
identi�cado, e vice-versa.
Quando tratamos de relacionamentos, devemos ter em mente três
conceitos importantes que in�uenciam diretamente na modelagem e no
entendimento de um modelo conceitual. Os conceitos são o grau, a
cardinalidade e o tipo do relacionamento.
7.2.2.1. Grau dos relacionamentos
O grau de um relacionamento corresponde ao número de entidades
envolvidas na mesma relação. O grau de um relacionamento pode ser:
Binário: onde duas entidades participam de um relacionamento. Este é
o grau utilizado na maioria dos relacionamentos.
Ternário: onde três entidades participam de um relacionamento.
N-ário: Onde quatro ou mais entidades participam de um
relacionamento.
Muito se discute sobre o uso e a aplicabilidade de relacionamentos com
grau maior que dois (ternários e “n-ários”) em modelos de dados. Alguns
autores sugerem inclusive que esses relacionamentos não sejam adotados.
A �gura a seguir mostra exemplos comuns de graus de relacionamentos.
Figura 7.3 – Grau dos relacionamentos em modelos conceituais
7.2.2.2. Cardinalidade
Cardinalidade representa a quantidade de vezes que um elemento de um
conjunto de entidades pode, em um determinado instante, estar associado,
em um dado relacionamento, a outros elementos de outras entidades.
A cardinalidade de uma relação é de�nida em cada um dos sentidos do
relacionamento por um conjunto (x,y) onde x representa a cardinalidade
mínima e y representa a cardinalidade máxima.
A cardinalidade mínima é responsável por orientar a obrigatoriedade
(opcionalidade) do relacionamento. Já a cardinalidade máxima é
responsável por de�nir a quantidade máxima de vezes que um elemento
pode estar associado no relacionamento.
Até agora, por �ns didáticos, a cardinalidade não estava sendo
representada nos exemplos deste livro, mas vale a pena destacar que seu uso
é obrigatório, pois as cardinalidades re�etem regras que obrigatoriamente
devem ser representadas em um Modelo Conceitual de Dados.
A �gura a seguir mostra um exemplo de uso das cardinalidades em um
relacionamento dentro de um Modelo Conceitual de Dados.
Figura 7.4 – Exemplo do uso de cardinalidade nos relacionamentos
No exemplo acima, um “EMPREGADO” trabalha em uma e somente uma
“EMPRESA” e em uma “EMPRESA” trabalham nenhum ou vários
“EMPREGADOS”. Ou seja, dentro do contexto que foi modelado, é
impossível existir um “EMPREGADO” sem uma “EMPRESA” associada,
porém é totalmente viável criar uma “EMPRESA” e não associar
inicialmente algum “EMPREGADO”.
7.2.2.3. Tipos de relacionamentos
O simples fato de associar duas entidades através de um relacionamento
com suas cardinalidades às vezes não é su�ciente para representar todas as
regras de negócio existentes dentro dessas relações. Para isso podemos usar
mecanismos de representação um pouco mais detalhados. Sob esta ótica,
podemos ainda classi�car os relacionamentos em três tipos:
Relacionamentos independentes.
Relacionamentos contingentes.
Relacionamentos mutuamente exclusivos.
Relacionamentos independentes
Tipo de relacionamento presente na maioria das relações. Não há
necessidade de interpretação simultânea de outro relacionamento. Ou seja,
não depende de ninguém para existir ou in�uenciar o seu comportamento.
Relacionamentos contingentes
Estabelecem associações simultâneas entre os elementos envolvidos. Ou
seja, mais de um relacionamento deve ocorrer em um mesmo instante.
Sua representação é recomendada, pois envolve regras de negócio
especí�cas que, se não mapeadas neste momento, fatalmente serão
esquecidas mais adiante no decorrer do projeto.
A �gura a seguir mostra um exemplo de relacionamento contingente.
Figura 7.5 – Exemplo de relacionamento contingente
No exemplo anterior é impossível alocar empregados em um projeto sem
um gerentede�nido e também não é possível de�nir um gerente para um
projeto sem existir empregados alocados no projeto. Ou seja, os dois
relacionamentos devem ocorrer no mesmo instante.
Relacionamentos mutuamente exclusivos
Neste caso, se um relacionamento ocorre, os outros não deverão ocorrer
em relação a um determinado objeto.
Sua representação é recomendada, pois envolve regras de negócio
especí�cas que, se não mapeadas neste momento, fatalmente serão
esquecidas mais adiante no decorrer do projeto.
A �gura a seguir mostra um exemplo de relacionamento mutuamente
exclusivo.
Figura 7.6 – Exemplo de relacionamento mutuamente exclusivo
O exemplo anterior re�ete uma obra gerida por uma “EMPRESA
PRIVADA” ou por uma “UNIDADE FEDERATIVA” ou por um
“MUNICÍPIO”. Ou seja, três tipos de entidades podem gerir uma obra,
porém somente uma é a entidade gestora.
7.2.3. Atributos
Os atributos são informações que caracterizam as entidades e os
relacionamentos. Um atributo pode identi�car, descrever, quali�car,
quanti�car ou registrar o estado/situação/ocorrência de uma entidade.
No modelo conceitual são representados através de um “pirulito” colocado
junto às entidades.
Os atributos podem ser classi�cados em quatro tipos:
Atributo identi�cador: representado através de uma bola cheia na
extremidade do atributo. Atributos identi�cadores compõem a
identi�cação única de uma ocorrência em uma entidade. Vale ressaltar
que uma entidade e/ou relacionamento pode possuir mais de um
atributo identi�cador, desde que, em conjunto, componham a
identi�cação única.
Atributo não identi�cador: representado através de uma bola vazia na
extremidade do atributo. Corresponde à maioria das ocorrências de
uma entidade. Além disso, atributos não identi�cados podem ser
opcionais, ou seja, em algumas instâncias de entidade, alguns atributos
poderão conter valores nulos.
Atributos multivalorados: representados através de uma �or ou
asterisco na extremidade do atributo. Atributos multivalorados são
utilizados para representar mais de uma ocorrência de valor de um
atributo dentro de uma mesma instância de uma entidade. Exemplo:
geralmente uma pessoa possui mais de um número de telefone. Como
o objetivo do modelo conceitual é capturar a essência do negócio sem
levar em conta aspectos de implementação, este tipo de abordagem é
utilizado para representar todas essas instâncias em um único atributo,
porém deve-se ter em mente que este tipo de abordagem não deve ser
utilizado a partir da modelagem lógica de dados, onde entrarão em
cena os conceitos de normalização.
Atributos compostos: representados através de uma oval com vários
nós na extremidade do atributo. Atributos compostos são utilizados
para representar mais de um tipo de informação (quali�cação) em um
atributo. Tal como o atributo multivalorado, seu uso é recomendado
somente no Modelo Conceitual de Dados.
A �gura a seguir mostra os tipos de atributos utilizados em um Modelo
Conceitual de Dados.
Figura 7.7 – Notações utilizadas em atributos
O exemplo anterior representa atributos comuns aos alunos de qualquer
instituição: o número da matrícula é um atributo identi�cador e o nome do
aluno é um atributo não identi�cador. Já o atributo telefones é
multivalorado, pois representa os diversos telefones que um aluno possui.
Endereço é considerado um atributo composto, pois é formado pela
composição de UF, Cidade e Logradouro.
7.2.4. Mecanismos avançados de abstração em um Modelo
Conceitual de Dados
Os mecanismos avançados de abstração são excelentes recursos para
melhorar o entendimento e a representação dos modelos de dados. Alguns
mecanismos como o autorrelacionamento já são bastante utilizados pelos
técnicos que produzem os modelos de dados; outros recursos, nem tanto
(como a repetição), e por vezes geram problemas no futuro por falta de uma
representação adequada. Os tópicos a seguir irão detalhar e mostrar
exemplos de como esses mecanismos são utilizados.
7.2.4.1. Repetição
Existem situações em que uma mesma instância de uma entidade pode
selecionar outra mesma instância de outra entidade várias vezes.
A repetição permite representar as regras de negócio que expressam a
quantidade de instâncias que pode ser estabelecida entre os mesmos
elementos das entidades participantes de um relacionamento.
Quando trabalhamos com o mecanismo de repetição, é obrigatória a
existência de um atributo identi�cador no relacionamento onde ocorre a
repetição.
A repetição é representada no modelo através de um número que indica
quantas vezes uma mesma instância de uma entidade pode se relacionar
com outra instância mais de uma vez em outra entidade. Se o número de
vezes for inde�nido utiliza-se a letra “N”.
A �gura a seguir mostra um exemplo de uso do mecanismo da repetição.
Figura 7.8 – Exemplo do uso da repetição em um Modelo Conceitual de Dados
No exemplo anterior temos a representação de um relacionamento onde
são registrados os cartões (amarelo ou vermelho) recebidos pelos jogadores
de futebol em uma partida. Conforme regra vigente, um jogador não pode
receber dois cartões amarelos em uma mesma partida. Se isto acontecer, o
segundo cartão amarelo é convertido em vermelho e ele é automaticamente
expulso da partida. O número 2 colocado em cima do relacionamento
“punição” representa esta regra.
7.2.4.2. Autorrelacionamento
O autorrelacionamento, também conhecido como relacionamento
recursivo, representa a associação entre elementos pertencentes à mesma
entidade.
Em um autorrelacionamento temos sempre dois papéis formados pelos
elementos de uma entidade. A representação desses papéis é obrigatória e
fundamental para o entendimento do modelo. Pre�ro utilizar um
substantivo para nomear o relacionamento e verbos ou expressões verbais
para nomear os papéis.
Utilizamos um autorrelacionamento quando:
Desejamos representar estruturas hierárquicas dentro da mesma
entidade. Este tipo de representação sempre utilizará uma
cardinalidade (0,1) x (0,N). A �gura a seguir mostra um exemplo de
utilização de um autorrelacionamento com essas características.
Figura 7.9 – Exemplo do uso de um autorrelacionamento para representar uma
hierarquia
Conforme exemplo da �gura anterior, conseguimos montar uma estrutura
de rede hierárquica de empregados dentro de uma empresa.
Desejamos representar estruturas similares a composições com a
mesma entidade. Este tipo de representação sempre utilizará uma
cardinalidade (0,N) x (0,N). A �gura a seguir mostra um exemplo de
utilização de um autorrelacionamento com essas características.
Figura 7.10 – Exemplo de um autorrelacionamento para representar uma
composição
Conforme exemplo da �gura anterior, conseguimos montar uma estrutura
que forma uma composição de materiais. O relacionamento “composição”
será responsável por armazenar essas informações. Para ilustrar esta relação
com exemplos reais, podemos imaginar que a entidade “MATERIAL”
armazena todos os itens materiais de um carro. O relacionamento
“composição” será responsável por montar a composição desses materiais.
No caso de um carro, existirão várias instâncias de materiais dentro da
entidade “MATERIAL”, inclusive o material “motor”. O “motor”, por sua vez,
é formado por vários materiais de menor porte e diversas quantidades. Por
esta razão foi colocado o atributo “Quantidade” dentro do relacionamento.
7.2.4.3. Generalização e especialização
Existem situações onde precisamos representar entidades comuns com um
maior ou menor grau de propriedades em cada uma, sempre mantendo uma
visão hierárquica entre essas entidades. Dependendo da situação, podemos
utilizar a generalização ou a especialização.
A generalização consiste em criar um conceito superior para as entidades
existentes mantendo uma relação de hierarquia de entidade entre a nova
entidade (entidade pai) e as entidades já existentes (entidades �lhas). A
�gura a seguir demonstra um exemplo de uso do mecanismo de
generalização.
Figura 7.11 – Uso da generalização em um Modelo Conceitual de Dados
Já a especialização consiste em criar novosconceitos (entidades �lhas)
para uma entidade já existente, mantendo uma relação de hierarquia das
novas entidades com a entidade pai (já existente). A �gura a seguir
demonstra um exemplo de uso do mecanismo de especialização.
Figura 7.12 – Uso da especialização em um Modelo Conceitual de Dados
Quando trabalhamos com mecanismos de generalização/especialização
utilizamos regras de negócio que representam condições envolvendo
especialização. A essas condições damos o nome de cobertura.
A cobertura é representada do lado da seta que indica a
especialização/generalização por um par de valores (X,Y) onde X representa
o conteúdo e Y representa a cobertura.
O valor de conteúdo pode ser representado pelas letras T e P, onde: T =
Conteúdo Total (toda instância de um elemento “E” deve pertencer
também a uma instância em uma entidade �lha especializada).
P = Conteúdo Parcial (pode existir uma instância do elemento “E” que
não pertença às entidades especializadas).
O valor de cobertura pode ser representado pelas letras E e S, onde: E =
Cobertura Exclusiva (toda instância do elemento “E” pode existir no
máximo em uma instância nas entidades especializadas).
S = Cobertura Sobreposição (toda instância do elemento “E” pode existir
em várias instâncias das entidades especializadas).
7.2.4.4. Agregação
A agregação é um mecanismo de abstração onde criamos um novo
conceito a partir dos componentes de uma relação. Usamos a agregação
quando sentimos a necessidade de associar um relacionamento ao outro. A
�gura a seguir mostra um exemplo de uso de uma agregação.
Figura 7. 13 – Exemplo do uso da agregação em um Modelo Conceitual de Dados
No exemplo anterior, foi necessário criar um conceito mais abrangente
para poder representar o consumo de um cliente hospedado em um quarto.
Vale ressaltar que, quando utilizamos a agregação, as relações são
dependentes. Ou seja, a associação da entidade agregada com a outra
entidade só ocorre após a existência do fato (relação) da entidade agregada.
No caso, o cliente só poderá consumir serviços após estar hospedado em um
quarto.
7.3. Modelo Lógico de Dados
Um Modelo Lógico de Dados (MLD) é considerado um modelo de dados
implementável. Tal como o Modelo Conceitual de Dados, o modelo lógico
utiliza elementos estruturais: entidades, relacionamentos e atributos; porém
com um grau maior de complexidade devido às restrições de integridade e
regras de normalização. Ao contrário do modelo conceitual que tem como
principal objetivo representar o contexto do negócio, o Modelo Lógico de
Dados já procura estabelecer soluções de implementação em bancos de
dados – claro que respeitando os requisitos de informação e as regras de
negócio representadas no modelo conceitual.
Recomenda-se que o Modelo Lógico de Dados seja criado a partir do
mapeamento do Modelo Conceitual de Dados. A partir daí começa-se um
trabalho de re�namento para projetar o melhor modelo implementável. Um
Modelo Lógico de Dados também pode ser construído a partir do zero,
porém toda a questão da participação do cliente no início da modelagem e a
captura do ambiente de negócios poderão ser comprometidas.
Existem situações, principalmente nos projetos de soware que utilizam o
paradigma da orientação a objeto (OO), onde o Modelo Lógico de Dados
não é utilizado. A justi�cativa para esse “esquecimento” é o fato dos projetos
OO não trabalharem com os conceitos de bancos de dados relacionais. Na
verdade, em OO modelam-se classes e não entidades.
Além disso, em OO não existe o conceito de normalização. Nesses casos,
recomenda-se que o modelo conceitual, representado com as classes de
negócio, evolua em seu grau de detalhamento no decorrer do projeto. Esse
diagrama de classes, um pouco mais detalhado, poderia suprir parcialmente
a necessidade do modelo lógico.
Mais adiante, quando for feito o mapeamento do modelo OO para o
modelo físico (relacional) de dados, as técnicas utilizadas em um modelo
lógico deverão ser aplicadas neste modelo físico, obtido e re�nado através
do mapeamento objeto x relacional.
O per�l recomendado para construir modelos lógicos é técnico. O papel
do projetista de dados é o mais adequado para efetuar a construção do
modelo lógico. O gestor técnico de dados também deve estar envolvido no
processo de construção apoiando (dando suporte) a modelagem e validando
os modelos produzidos pelos projetistas.
Tal como o modelo conceitual, o Modelo Lógico de Dados possui diversas
notações utilizadas no mercado. Neste livro utilizaremos a notação da
Engenharia da Informação, também conhecida como notação do James
Martin ou “pés de galinha”.
7.3.1. Conceitos básicos em Modelagem Lógica de Dados
A �gura a seguir demonstra um exemplo onde podemos visualizar
entidades dependentes e independentes, relacionamentos identi�cados e
não identi�cados, além de chaves primárias, chaves candidatas e chaves
estrangeiras. As seções a seguir falarão sobre os principais conceitos e
elementos básicos de um Modelo Lógico de Dados.
Figura 7. 14 – Exemplo da notação de um Modelo Lógico de Dados
7.3.1.1. Entidade independente
Conceito similar à entidade forte do Modelo Conceitual de Dados. No
Modelo Lógico de Dados a entidade independente é representada por um
retângulo com os seus cantos retos (90°). Diferentemente do Modelo
Conceitual de Dados, o nome da entidade é representado do lado de fora, no
canto superior esquerdo.
7.3.1.2. Entidade dependente
Conceito similar à entidade fraca do Modelo Conceitual de Dados. No
Modelo Lógico de Dados a entidade dependente é representada por um
retângulo com os seus cantos arredondados. Diferentementemente do
Modelo Conceitual de Dados, o nome da entidade é representado do lado de
fora, no canto superior esquerdo.
7.3.1.3. Relacionamento identi�cado
Relacionamento formado por uma entidade dependente. Ou seja, a chave
primária da entidade pai (independente) ajuda a compor a chave primária
da entidade �lha (dependente). O relacionamento é feito através de uma
linha uniforme sem cortes e/ou interrupções.
7.3.1.4. Relacionamento não identi�cado
Relacionamento onde a chave primária da entidade origem não faz parte
da composição da chave primária da entidade destino. O relacionamento é
expresso através de uma linha tracejada entre as duas entidades. Um
relacionamento não identi�cado poderá ser também um relacionamento
opcional. Nos relacionamentos opcionais o conteúdo (valor) do atributo da
entidade origem não é carregado na entidade destino.
7.3.1.5. Chave primária
Uma chave primária é um atributo ou conjunto de atributos cujos valores
distinguem e/ou identi�cam uma ocorrência dentro de uma entidade. Uma
entidade possui apenas uma chave primária. A chave primária também é
conhecida como “primary key” ou simplesmente “PK”.
7.3.1.6. Chave candidata
Uma chave candidata é um atributo ou conjunto de atributos que são
possíveis chaves primárias dentro de uma entidade. Toda chave primária é
uma chave candidata, porém nem toda chave candidata é uma chave
primária. Uma chave candidata gera uma chave primária ou uma chave
alternativa.
7.3.1.7. Chave alternativa
A chave alternativa é uma chave candidata que não foi escolhida como
chave primária. A chave alternativa também é conhecida como “alternate
key” ou simplesmente “AK”.
7.3.1.8. Chave estrangeira
Uma chave estrangeira representa um atributo, ou combinações de
atributos, cujos valores aparecem necessariamente na chave primária de
outra entidade que se relaciona com esta, onde encontramos a chave
estrangeira. A chave estrangeira serve, portanto, para implementar
relacionamentos entre entidades dentro de um ambiente relacional. A chave
estrangeira também é conhecida como “foreign key” ou simplesmente “FK”.
7.3.1.9. Restrições de integridade
Restrições de integridade são mecanismos usados para garantir a exatidão
e a consistência dos dados em um banco de dados relacional. Entre os
mecanismos mais comuns encontramos:
Restrições de chave: onde cada entidade do Modelo Lógico de Dados
deve conter uma chave primária ou umde seus atributos de formação;
não podem conter valores nulos.
Restrições de integridade referencial: onde a chave estrangeira tem
que apontar para um registro existente, ou então deve ter um valor
nulo caso o relacionamento possua uma cardinalidade mínima igual a
zero.
Restrições de conteúdo: onde um determinado atributo deve
obrigatoriamente possuir um valor ou não. É o que de�nimos de
atributo nulo ou não nulo.
Restrições de domínio: onde o valor de cada atributo deve ser um
valor atômico, dentro de um domínio especi�cado para aquele atributo.
É o que utilizamos mais à frente no modelo físico com as check
constraints e check tables.
Restrições de integridade semântica: estão ligadas a regras de negócio
especí�cas. Mais à frente podem ser implementadas via triggers, stored
procedures ou mecanismos programados na aplicação.
7.3.2. Normalização
A normalização de dados são vários passos seguidos no projeto de um
banco de dados, que permitem um armazenamento consistente e um
e�ciente acesso aos dados em bancos de dados relacionais. Esses passos
reduzem a redundância de dados e as chances dos dados se tornarem
inconsistentes.
A normalização deve ser feita e/ou aplicada no Modelo Lógico de Dados,
porém, caso não seja viável construir um Modelo Lógico de Dados, como
por exemplo em um projeto OO, deve-se aplicar esta técnica na transição do
projeto OO para o modelo relacional.
A técnica de normalização prevê a existência de seis regras, chamadas de
formas normais, sendo elas: a primeira (1FN), segunda (2FN), terceira
(3FN), quarta (4FN), quinta (5FN) e forma normal Boyce Codd.
Quando falamos em normalização, podemos a�rmar que uma relação está
normalizada se ela está na terceira forma normal (3FN). Por esta razão o
livro detalhará apenas as três primeiras formas normais.
7.3.2.1. As formas normais
Para aplicar a normalização de dados é necessário considerar a sequência
das formas normais, isto é, para aplicar a segunda forma normal, por
exemplo, é necessário que seja aplicada a primeira forma normal. Assim,
para aplicar a terceira forma normal é necessário que já tenha sido feita a
normalização na segunda forma normal.
7.3.2.2. Primeira forma normal (1FN)
A de�nição clássica da primeira forma normal menciona que uma
entidade está na 1FN se, e somente se, possuir uma chave primária e não
possuir atributos compostos ou multivalorados.
Mas, a�nal, o que é isso? Vejamos o exemplo a seguir com as instâncias de
dados de uma entidade CLIENTE.
Entidade CLIENTE:
COD-CLIENTE NOME-CLIENTE TELEFONE
123 João das Couves (21) 8888-8888, (21) 2222-2222
Fulano de Tal (11)1234-5678, (11) 99999-0000
126 Sicrano da Silva
127 Beltrano (21) 3333-3333
128 Bergson Lopes (21)1111-1111
Tabela 7. 1 – Instâncias de dados de uma entidade desnormalizada
Como podemos observar, a entidade não possui uma chave primária
de�nida. O ideal seria a de�nição do atributo COD-CLIENTE como PK5,
porém existem ocorrências nulas para este atributo. Além disso, a entidade
também possui um atributo multivalorado (telefone) que suporta mais de
uma ocorrência de valor.
Da forma como está apresentada, não podemos relacionar esta entidade a
nenhuma outra, pois não há uma simples PK para fazer essa ligação e
também não podemos fazer um trabalho de pesquisa mais apurado em cima
das informações do telefone.
Para resolver esses problemas devemos normalizar esta entidade. A �gura e
a tabela a seguir mostram a modelagem e as instâncias de dados do modelo
já respeitando as regras da primeira forma normal (1FN).
Figura 7.15 – Exemplo de uma relação na 1FN
COD-
CLIENTE (PK)
NOME-
CLIENTE
1 João das
Couves
2 Fulano de
COD-CLIENTE
(PK e FK)
NR-SEQ-
TELEFONE
(PK)
NR-
DDD
NR-
TELEFONE
1 1 21 8888-8888
1 2 21 2222-2222
Tal
3 Sicrano da
Silva
4 Beltrano
5 Bergson
Lopes
2 1 11 1234-5678
2 2 11 99999-
0000
4 1 21 3333-3333
5 1 21 1111-1111
Tabela 7.2 – Instâncias de dados em uma relação na 1FN
Para normalizar a entidade, foi necessário de�nir uma chave primária para
a entidade CLIENTE e criar uma nova entidade TELEFONE para
armazenar os atributos que eram compostos e multivalorados na solução
inicial.
7.3.2.3. Segunda forma normal (2FN)
A de�nição clássica da segunda forma normal menciona que uma relação
está na 2FN se, e somente se, estiver na 1FN e cada atributo não chave for
dependente da chave primária inteira, isto é, cada atributo não chave não
poderá ser dependente de apenas parte da chave.
As anomalias da segunda forma normal ocorrem somente em entidades
com chaves primárias compostas com dois ou mais atributos, pois não há
dependência parcial em entidades com uma chave primária formada apenas
por um atributo.
Vejamos o exemplo a seguir com as instâncias de dados de uma entidade
APLICACAO_FUNDO.
COD-CLIENTE
(PK e FK)
COD-FUNDO
(PK) QT-COTAS-APLICADAS NOME-FUNDO
1 F1 3000 Fundo Especial
2 F1 2340 Fundo Especial
3 F2 17 Fundo Popular
Tabela 7.3 – Instâncias de dados em uma entidade desnormalizada
Como podemos observar, a entidade possui uma chave composta formada
pelas colunas do código do cliente e código do fundo. Ao analisar os
atributos não chave (quantidade de cotas aplicadas e nome do fundo),
podemos perceber que o atributo da quantidade de cotas depende da
totalidade da chave, a�nal o objetivo desta entidade é armazenar a
quantidade de cotas aplicadas em um fundo por determinados clientes. Já o
atributo do nome do fundo não depende da totalidade da chave primária,
mas apenas do atributo do código do fundo (parte da PK), ou seja, a relação
está desnormalizada e este atributo não deve estar aqui.
Para resolver o problema devemos normalizar esta entidade. A �gura a
seguir mostra a modelagem adequada, visando remover a anomalia da 2FN
mencionada.
Figura 7.16 – Exemplo de uma relação respeitando as regras da 2FN
7.3.2.4. Terceira forma normal (3FN)
A de�nição clássica da terceira forma normal menciona que uma relação
está na 3FN se estiver na 2FN e se cada atributo não chave não possuir
dependência transitiva em relação aos demais atributos da entidade. A
dependência transitiva ocorre em casos onde um atributo não é dependente
da chave primária, mas de outro atributo da entidade.
Quando isto ocorre, dizemos que a entidade (ou relação) não está na
terceira forma normal. A �gura a seguir mostra um exemplo de violação da
3FN.
Figura 7.17 – Exemplo de violação da 3FN
Podemos observar na �gura anterior que a coluna do nome do cargo não
depende do atributo da chave primária da entidade, mas do atributo do
código do cargo. Ou seja, ocorreu uma dependência transitiva, ocasionando
a violação da 3FN.
Para resolver este problema devemos normalizar esta entidade. A �gura a
seguir mostra a modelagem adequada, visando remover a anomalia da 3FN
mencionada.
Figura 7.18 – Exemplo de relação respeitando as regras da 3FN
A simples criação da entidade CARGO e a transferência de seus atributos
para a nova entidade foi su�ciente para normalizar esta relação.
Após a aplicação das regras de normalização, algumas entidades acabam
sendo divididas em duas ou mais entidades, o que no �nal gera um número
maior de entidades do que existia originalmente. Este processo resulta na
simpli�cação dos atributos de uma entidade, além de colaborar
signi�cativamente para a estabilidade do modelo de dados, reduzindo
consideravelmente as necessidades de manutenção.
7.4. Modelo Físico de Dados
Um Modelo Físico de Dados (MFD) é considerado um modelo de dados
implementado (ou em vias de ser implementado). As características do
projeto deste modelo estão ligadas diretamente ao SGBD (Sistema
Gerenciador de Banco de Dados) que será utilizado para implementar as
estruturas de dados deste modelo. Os três principais bancos relacionais do
mercado possuem tipos de dados e alguns mecanismos diferentes entre si.
Essas diferenças in�uenciam a construção do Modelo Físico de Dados.
Tal como os demais modelos, o Modelo Físico de Dados utiliza elementos
estruturais. Os principais elementos estruturais do modelo físico são:
tabelas, colunase constraints. Esses elementos são objetos físicos que existem
nos bancos de dados.
De forma geral, recomenda-se que o Modelo Físico de Dados seja criado a
partir do mapeamento do Modelo Lógico de Dados ou então através do
mapeamento do modelo OO (classes) para o modelo relacional, aplicando
as regras de normalização descritas no modelo lógico.
O per�l recomendado para construir modelos físicos é técnico. O papel do
projetista de dados é o mais adequado para efetuar a construção do modelo
físico, junto com o apoio do DBA. O gestor técnico de dados também pode
estar envolvido no processo de construção apoiando (dando suporte) a
modelagem e validando os modelos produzidos pelos projetistas.
Vale ressaltar que o modelo físico também é um artefato e, como tal, deve
ser projetado e avaliado antes de ser implementado nos ambientes de banco
de dados.
A �gura a seguir demonstra um exemplo de Modelo Físico de Dados.
Repare que o modelo é praticamente o mesmo das soluções dadas nas seções
de normalização. A diferença aqui está nos tipos de dados que foram
incluídos no modelo.
Figura 7.19 – Exemplo de um Modelo Físico de Dados
7.4.1. O Modelo Físico de Dados e as desnormalizações
No caso da imagem anterior, não foi necessária nenhuma alteração muito
signi�cante no modelo, ou seja, o modelo permaneceu normalizado –
entretanto, dependendo da situação, algum tipo de desnormalização pode
ser necessário.
As desnormalizações devem ser utilizadas com cautela em projetos de
bancos de dados relacionais. Durante minha experiência cheguei à
conclusão de que as pessoas procuram desnormalizar as relações em um
modelo de dados para:
Facilitar o trabalho da lógica da programação.
Resolver problemas de desempenho.
A primeira opção é uma justi�cativa totalmente inválida e, infelizmente,
ainda é muito utilizada por analistas que não querem perder tempo
escrevendo soluções de código mais trabalhadas, principalmente na
montagem de queries (SQL). Cabe ao Gestor Técnico de Dados identi�car
que uma possível desnormalização está sendo proposta somente por essa
razão e não permitir o seu uso. Já a segunda opção (performance) pode ser
válida, porém, nem sempre um analista ou um Gestor Técnico de Dados
possui conhecimentos para tomar esse tipo de decisão. De forma geral, cabe
ao DBA avaliar se a desnormalização é necessária ou não. O DBA é o
pro�ssional mais indicado para tomar esse tipo de decisão.
7.4.2. Elementos estruturais de um Modelo Físico de Dados
Os itens a seguir demonstram os principais elementos estruturais básicos
de um Modelo Físico de Dados:
Tabelas: são estruturas para o armazenamento de dados, formadas por
um conjunto de dados dispostos em um número �nito de colunas e
ilimitado de linhas. A tabela é um dos principais elementos de um
Modelo Físico de Dados. Uma tabela é similar a uma entidade do
modelo lógico.
Colunas: são unidades básicas de armazenamento de dados em um
registro dentro de uma tabela. Uma coluna é similar a um atributo do
modelo lógico.
Sequences: são objetos que geram números sequenciais dentro do
SGBD Oracle. São excelentes em termos de performance, já que
armazenam um range de números no cache e também porque tiram do
desenvolvedor a responsabilidade de gerenciar a geração de números
sequenciais em casos de múltiplos acessos.
Sinônimos: são utilizados para fornecer um nome alternativo para
uma tabela ou visão presente no mesmo ou em outro esquema.
Índices: recurso físico que visa otimizar a recuperação de uma
informação, via um método de acesso. Seu objetivo principal está
relacionado com a performance da aplicação.
Constraints: as restrições de integridade ou constraints são mecanismos
utilizados para garantir a integridade dos dados nos bancos de dados
relacionais. São elas: check, not null, unique, primary key e foreign key.
Views: são visões parciais de tabelas. Permitem dar uma visão
personalizada aos usuários. Além disso, oferecem melhor segurança na
disponibilização dos dados.
Stored procedures: são “programas” com conjuntos de comandos SQL.
Geralmente permitem manipulação procedural dos dados recuperados
pelos comandos SQL. As stored procedures são compiladas e mantidas
no próprio banco de dados.
Triggers: são gatilhos, pequenos códigos dentro do banco de dados,
disparados automaticamente por eventos de atualização de bancos de
dados. Geralmente são utilizados para obrigar o cumprimento de
regras de integridade e de negócio que não são atendidas com os
mecanismos mais simples.
7.5. Documentação de um modelo de dados
Até o momento, neste capítulo, já debatemos os principais tipos de
modelos de dados. Iniciamos com o modelo conceitual, passamos pelo
modelo lógico e terminamos com o modelo físico. Em todos os casos, foram
passados os seus conceitos especí�cos de modelagem e as suas principais
características. Entretanto, a assimilação desses conceitos é su�ciente para
entender profundamente qualquer modelo de dados que venhamos a olhar
daqui para frente? Acredito que não.
A representação grá�ca e a denominação dos elementos que compõem um
modelo de dados, de forma geral, não são su�cientes para traduzir todos os
conceitos envolvidos e que são necessários para caracterizá-los, interpretá-
los, de�ni-los e compreendê-los de forma evidente, tanto para o responsável
por sua criação quanto para qualquer leigo em relação ao ambiente
modelado que se interesse em conhecê-lo.
Para alcançar tal propósito, faz-se necessário tomar medidas que evitem
ambiguidade nas interpretações desses elementos e permitam esclarecê-los
por completo. A dicionarização dos elementos dos modelos é um
instrumento essencial que possibilita dotá-los de informações que atendam
a tais requisitos.
A dicionarização dos elementos é considerada parte fundamental do
processo de modelagem, já que, por seu intermédio, além dos benefícios
citados em relação à leitura do modelo, abrem-se possibilidades de
disseminação do conhecimento relativo aos negócios corporativos
representados pelos diagramas de negócio e modelos de dados. Além disso,
tal prática permite que se realizem levantamentos de similaridades entre
objetos de modelos diversos, possibilitando a sua reutilização.
As seções seguintes demonstrarão as melhores práticas para a
documentação dos modelos de dados.
7.5.1. Boas práticas para dar nomes aos elementos
As seguintes práticas podem ser adotadas na nomeação de entidades,
atributos e relacionamentos para facilitar o entendimento de um modelo de
dados.
Todo e qualquer objeto (entidade ou atributo) deve ser nomeado através de
uma identi�cação unívoca. Seguem dicas de como nomear esses objetos:
O nome do objeto deve representar o negócio de forma a não haver
dúvidas quanto a sua especi�cação.
O objeto deve ser nomeado com o seu real signi�cado dentro da
organização, com uma visão corporativa, não somente dentro do
cenário do sistema no qual está sendo modelado.
O nome do objeto deve ser quali�cado para que o seu signi�cado seja
claro e absoluto. Devemos evitar a utilização de nomes muito genéricos
para a denominação de um objeto. Exemplo: uma entidade
denominada como “ESPECIALIDADE” possui signi�cados diferentes
dependendo da sua área de aplicação. Se utilizarmos nomes mais
quali�cados como “ESPECIALIDADE_MEDICA” e
“ESPECIALIDADE_FORNECEDOR” não teríamos duas entidades
com o mesmo nome, porém com signi�cados diferentes.
Todo objeto deve ser nomeado quanto ao número no singular, tendo
em vista que o signi�cado de seu nome quali�ca uma única ocorrência
de objeto conceitual por vez.
Sempre que possível opte por um gênero default (masculino ou
feminino) para �ns de padronização.
Nomes ou siglas departamentais de uma organização devem ser
evitados sempre que possível, à exceção de siglas ou abreviaturas já
consagradas no meio corporativo.
Evite o uso de preposições, artigos e conjunções irrelevantes para o
signi�cado do objeto. Exemplo: “TIPO_DE_CLIENTE” (não usual) –
“TIPO_CLIENTE” (usual).
Evite utilizar algarismos na nomeação do objeto. Exemplo:
“DT_2_CHAMADA” (não usual) – “DT_SEGUNDA_CHAMADA”de Dados
7.2.4.1. Repetição
7.2.4.2. Autorrelacionamento
7.2.4.3. Generalização e especialização
7.2.4.4. Agregação
7.3. Modelo Lógico de Dados
7.3.1. Conceitos básicos em Modelagem Lógica de Dados
7.3.1.1. Entidade independente
7.3.1.2. Entidade dependente
7.3.1.3. Relacionamento identi�cado
7.3.1.4. Relacionamento não identi�cado
7.3.1.5. Chave primária
7.3.1.6. Chave candidata
7.3.1.7. Chave alternativa
7.3.1.8. Chave estrangeira
7.3.1.9. Restrições de integridade
7.3.2. Normalização
7.3.2.1. As formas normais
7.3.2.2. Primeira forma normal (1FN)
7.3.2.3. Segunda forma normal (2FN)
7.3.2.4. Terceira forma normal (3FN)
7.4. Modelo Físico de Dados
7.4.1. O Modelo Físico de Dados e as desnormalizações
7.4.2. Elementos estruturais de um Modelo Físico de Dados
7.5. Documentação de um modelo de dados
7.5.1. Boas práticas para dar nomes aos elementos
7.5.2. Boas práticas para conceituar (de�nir) elementos
7.5.2.1. O que evitar na de�nição de entidades e atributos?
7.5.2.2. Exemplos de boas de�nições
7.6. Qualidade dos modelos de dados
7.6.1. Processos de qualidade para modelos de dados
7.6.2. Critérios de qualidade aplicados em modelos de dados
7.6.2.1. Completeza ou completude
7.6.2.2. Conceituação
7.6.2.3.Integridade
7.6.2.4. Flexibilidade
7.6.2.5. Integração
7.6.2.6. Legibilidade
7.6.2.7. Padronização
7.6.2.8. Aspectos físicos e de performance
7.7. Considerações �nais sobre Modelagem de Dados
8. Arquitetura de Dados
8.1. O que é uma Arquitetura de Dados?
8.2. Atividades necessárias para criar e manter uma Arquitetura de
Dados
8.3. Arquitetura de Dados não é apenas uma coleção de modelos
de dados e bancos de dados
8.3.1. Cadeia de Valor e macroprocessos
8.3.2. Glossário de termos corporativos
8.4. Modelos de dados e Arquitetura de Dados
8.5. Modelos de dados compartilhados
8.6. Modelos de dados corporativos
8.6.1. Como diferenciar modelos corporativos dos modelos
compartilhados
8.6.2. Abordagens para construção de modelos corporativos
8.6.2.1. Abordagem Top Down
8.6.2.2. Abordagem Bottom Up
8.6.2.3. Abordagem Híbrida
8.7. Tipos de modelos de dados corporativos segundo o DAMA-
DMBOK®
8.7.1. Modelo de Área de Interesse
8.7.2. Modelos conceituais de dados
8.7.3. Modelos lógicos de dados
8.8. Integração dos dados corporativos
8.8.1. Integração via troca de arquivos
8.8.2. Integração via ETL
8.8.3. Integração via Database Links ou Linked Servers
8.8.4. Replicação de dados e Oracle Golden Gate
8.8.5. Integração via serviços
9. Gestão de Dados Mestres e Referência
9.1. Contextualização
9.2. Dados mestres
9.3. Dados de referência
9.4. Dados transacionais
9.5. Gerenciamento de dados mestres e referência
9.6. Estilos de arquiteturas de dados mestres
9.6.1. Pré-MDM
9.6.2. Consolidação
9.6.3. Registro
9.6.4. Coexistência
9.6.5. Coexistência só de leitura
9.6.6. Transacional
9.7. Passos para implantar o MDM
10. Qualidade de Dados
10.1. O que é Qualidade de Dados?
10.2. Dados de baixa qualidade – Dados sujos
10.3. Processo de Qualidade de Dados (conteúdo)
10.3.1. Promover a Qualidade dos Dados
10.3.2. De�nir requisitos e questões da qualidade
10.3.3. Per�lar dados – Data pro�ling
10.3.4. Analisar dados
10.3.5. Limpar e corrigir dados – Data cleansing
10.3.6. Garantia da Qualidade dos Dados e Metadados
10.4. Considerações �nais sobre a Qualidade de Dados
Parte 3
11. Gestão de Dados Moderna
11.1. Visão geral da Gestão de Dados Moderna
11.2. Estrutura da Gestão de Dados
11.2.1. Corpo Técnico
11.2.2. Ferramentas
11.2.3. Metodologia
11.2.4. Qualidade
11.2.5. Alinhamento estratégico
11.2.6. Governança de Dados
11.3. Conduta
11.3.1. Adaptação
11.3.2. Agilidade
11.3.3. Bom senso
11.3.4. Comprometimento
11.3.5. Didática
11.3.6. Objetividade
11.3.7. Proatividade
11.3.8. Racionalidade
11.4. Pilares das organizações
11.4.1. Dados e metadados
11.4.2. Pessoas
11.4.3. Recursos �nanceiros
12. Boas Práticas da Gestão de Dados Moderna
12.1. As quatorze boas práticas de Gestão de Dados Moderna
12.2. Manter um time de destaque
12.3. Atuar no início dos projetos
12.4. Ser ágil nos atendimentos
12.5. Utilizar princípios e ferramentas da qualidade
12.5.1. Ciclo PDCA aplicado na Gestão de Dados Moderna
12.5.2. Diagrama de Pareto
12.5.3. Diagrama de causa e efeito
12.5.4. Grá�cos de controle
12.5.5. Listas de veri�cações (checklists)
12.6. Trabalhar com indicadores de gestão
12.7. Repassar os custos aos clientes
12.8. Nunca acomodar
12.9. Utilizar metodologia adequada
12.9.1. Diretrizes básicas para a construção de uma
Metodologia de Gestão de Dados
12.9.2. Características consideradas na criação de uma
Metodologia de Gestão de Dados
12.10. Utilizar ferramentas de apoio
12.11. Utilizar modelos de dados
12.12. Investir na capacitação dos clientes
12.13. Entender que o sucesso depende de todos
12.14. Divulgar a área de Gestão de Dados
12.15. Ter bom senso
13. Desenvolvimento Pro�ssional
13.1. O mercado de trabalho em Gestão de Dados
13.2. Organizações que atuam na área de Gestão de Dados
13.2.1. DAMA® – Data Management International
13.2.2. IAIDQ – International Association for Information and
Data Quality
13.2.3. DGI – Data Governance Institute
13.2.4. QIBRAS®
13.2.5. TDWI – The Data Warehouse Institute
13.3. Certi�cações: luxo ou necessidade?
13.4. Benefícios de uma certi�cação
13.5. Principais certi�cações do mercado para a área de Gestão de
Dados
13.5.1. DAMA-CDMP®
13.5.1.1. Requisitos para a certi�cação
13.5.1.2. Processo de certi�cação
13.5.2. IAIDQ-IQCP
13.5.2.1. Requisitos para a certi�cação
13.5.2.2. Processo de certi�cação
Anexos
I. Governança de Dados
II. Gestão da Arquitetura de Dados
III. Desenvolvimento dos Dados
IV. Gestão de Operações e Database
V. Gestão da Segurança de Dados
VI. Gestão de Dados Mestres e Referência
VII. Gestão de Data Warehousing e Business Intelligence
VIII. Gestão de Documentação e Conteúdo
IX. Gestão de Metadados
X. Gestão da Qualidade de Dados
Notas
Introdução
“Pensar consiste, ordinariamente, em ir dos conceitos às coisas,
e não das coisas aos conceitos.”
Henry Bergson (em Introdução à Metafísica)
“Os dados são o ativo mais importante das empresas”. Quando comecei a
trabalhar como Administrador de Dados, esta já era uma das frases mais
ditas pelos pro�ssionais das áreas de dados. Já se passaram mais de vinte
anos e, atualmente, ainda escuto quase que diariamente a mesma frase, às
vezes dita de forma diferente, mas com o mesmo propósito de valorizar os
dados como importantes ativos nas empresas.
Sem dúvida alguma, o jargão é nobre e adequado. Atualmente, há um
consenso geral nas empresas de que nenhuma organização é e�caz sem o
apoio de dados e informações de qualidade.
Grandes gurus internacionais das áreas de administração e negócios
costumam mencionar em seus artigos a importância de ter dados con�áveis
e a necessidade de gerenciá-los de forma e�caz para as empresas obterem
vantagens em relação aos seus concorrentes.
Apesar da importância reconhecida em possuir dados e informações de
qualidade, a situação dos dados nas empresas brasileiras não evoluiu muito
nesse tempo. Aliás, tenho a ligeira impressão de que a qualidade dos dados
piorou nos últimos anos, principalmente nas empresas que não possuem
pro�ssionais dedicados a zelar pela gestão e qualidade dos dados de forma
integral.
Mas a�nal, se há mais de vinte anos o dado já era considerado um ativo
importante pelos pro�ssionais que atuam nas áreas de dados, e várias
organizações reconhecem a sua importância, por que, na minha percepção,
a qualidade dos dados diminuiu? Nada foi feito para melhorar esse cenário?
Nada de novo surgiu com o propósito de melhorar a gestão e qualidade dos
dados?
Na verdade, durante esse tempo, várias ferramentas e soluções surgiram no
mercado com o propósito de apoiar as áreas de tecnologia da informação
em gerir melhor os dados que ela custodia. De início, algumas soluções
conseguiram atingir os seus propósitos, porém, atualmente, por mais que as
áreas de tecnologia da informação tenham evoluído com a adoção dessas
novas ferramentas e soluções,(usual).
Regras para nomeação de relacionamentos:
A estrutura de identi�cação nominal para relacionamentos deve ser
composta de um verbo ou locução verbal que de�na a relação existente
entre os objetos, preferencialmente conjugada na terceira pessoa do
singular do presente do indicativo.
Havendo necessidade de nomear o relacionamento nos dois sentidos,
utilize a voz passiva do verbo que de�ne a ação para um dos sentidos,
ou outro verbo que seja equivalente, conjugado na terceira pessoa do
singular do presente do indicativo.
Dê preferência a verbos de ligação (ser, estar, permanecer, etc.),
evitando verbos como existir, ter e possuir. Esteja sempre atento ao
sentido e à semântica do relacionamento, para que expresse
corretamente a regra de negócio.
Os autorrelacionamentos devem ser nomeados obrigatoriamente nos
dois sentidos. Geralmente, relacionamentos do tipo “um para muitos”
possuem a �nalidade de representar estruturas do tipo “hierarquia” (pai
x �lho, por exemplo). Já os autorrelacionamentos do tipo “muitos para
muitos” geralmente possuem um sentido de “composição”,
“constituição”.
7.5.2. Boas práticas para conceituar (definir) elementos
Todo e qualquer objeto deve ser conceituado através de uma de�nição
unívoca ou declaração de propósitos que esteja em conformidade com um
conjunto de regras prede�nidas. Seguem dicas de como conceituar esses
objetos:
A de�nição deve explanar o que o objeto é (conceito) em sua essência e
com relação ao escopo em análise. Não se deve simplesmente copiar o
que está no dicionário ou qualquer outro texto descritivo que
referencie o conceito fora do contexto do negócio.
A de�nição do objeto deve ser clara, completa e objetiva, propiciando a
compreensão consistente do objeto e do seu valor para o negócio. Em
outras palavras, o que o objeto está fazendo no modelo do negócio?
Deve ser escrita em linguagem não técnica e usando preferencialmente
a língua portuguesa. Quando inevitável, termos e expressões em
idioma estrangeiro devem ser acompanhados das respectivas
traduções.
A de�nição do objeto deve ser elaborada com base na terminologia do
negócio, mas sempre buscando ser compreensível para o leitor leigo ou
não especializado.
A de�nição deve considerar o objeto e seus possíveis papéis no
negócio. Cada papel deve ser descrito obedecendo aos requisitos
estabelecidos anteriormente.
Mesmo sendo o objeto referenciado a múltiplas funções, processos,
áreas da organização e visões particulares dos sistemas, ainda assim
deverá possuir o seu conceito sempre estável. Caso haja de�nições
particulares, que restrinjam ou ampliem o conceito de�nido, devem
estar explicitadas em especializações ou generalizações que descrevam
cada uma dessas visões, deixando claro a qual delas pertence.
Todo objeto com características de classi�cação ou agrupamento (tipo,
classi�cação, grupo, etc.) opera segundo (em função de) uma ou mais
propriedades do objeto que está sendo classi�cado/agrupado. Sua
de�nição, portanto, deve explicitar a(s) propriedade(s) em que se
baseia a classi�cação.
Para atributos, sua de�nição deve de�nir que característica(s) confere à
entidade.
A de�nição do atributo deve deixar claro o papel (ou papéis) que
representa como quali�cador da entidade.
A de�nição do atributo deve conter exemplos para clari�cação do
conceito. Quando aplicável, especialmente no caso de indicadores, a
de�nição deve explicitar o domínio discreto que o atributo pode conter.
Exemplo: para o atributo IN_TIPO_PESSOA, poderíamos ter as
ocorrências “F” para Pessoa Física e “J” para Pessoa Jurídica.
7.5.2.1. O que evitar na de�nição de entidades e atributos?
De�nição tautológica. Uma de�nição não deve conter o nome do
objeto antes que este tenha sido previamente de�nido. Por exemplo, se,
ao de�nir a entidade “Cliente”, a descrevermos como sendo: “todo
cliente que...”, estamos dizendo o que um cliente faz e não o que um
cliente é (seu conceito). Melhor seria algo como: “pessoa física ou
jurídica que adquiriu...”.
De�nição com termos desnecessários. Por exemplo, a expressão
“trata-se do conjunto de informações sobre toda e qualquer...” aplica-se
à de�nição de toda e qualquer entidade e não apenas à entidade
especí�ca. Por não acrescentar signi�cado relevante, torna-se
desnecessária, já que, por de�nição, todo elemento de um conjunto de
objetos compartilha todas as propriedades do conjunto. Da mesma
forma, deve-se evitar o uso de expressões como “Esta entidade tem a
�nalidade de...” ou “Esta entidade foi criada devido........”.
Frases muito longas. Em benefício da facilidade de compreensão, uma
de�nição não deve usar períodos de texto muito longos. Um parágrafo
composto de frases curtas, mas objetivas, pode aumentar
signi�cativamente a clareza da de�nição.
Formas de utilização e acesso. Descrição de onde, quando, como e por
quem o objeto é utilizado. Isto se aplica mais a matrizes de processos x
dados.
De�nições com o caráter exclusivamente físico. Referenciar o objeto
como um meio de armazenamento, como por exemplo: tabela,
repositório, etc.
7.5.2.2. Exemplos de boas de�nições
BOLETO_COBRANCA: guia de pagamento representativo de um
valor a receber emitido a um sacado para a quitação de um bem ou
serviço. O boleto de cobrança deve ser quitado na rede bancária.
Atributos da entidade:
NR_COBRANCA: identi�cador numérico automaticamente atribuído à
correspondência eletrônica dirigida a uma empresa, informando-a do evento de
cobrança.
DT_VENCIMENTO: dia, mês e ano limites para que o pagamento do valor
cobrado seja efetivado pelo devedor.
VL_COBRANCA: importância cobrada mensalmente à organização a título de
prestação de serviços. Este valor é reajustado semestralmente.
DT_PAGAMENTO: dia, mês e ano em que foi efetuada a quitação de uma
cobrança.
VL_MULTA_ATRASO: importância cobrada uma única vez ao devedor
inadimplente, a título punitivo, pela quebra de expectativa de receita por parte
do credor. Esta importância é �xada contratualmente, podendo ser um
percentual do valor originalmente cobrado ou uma quantia �xa.
CONTRATO_CONCESSAO: documento que o�cializa um acordo
entre duas ou mais partes (pessoas) que se sujeitam a cumprir as
obrigações estabelecidas em um contrato judicial devido à utilização de
bens públicos, ou de exploração de recursos naturais (jazidas, energia
hidráulica) pertencentes à União.
ESPECIALIDADE_MEDICA: classi�cação dada pela OMS
(Organização Mundial de Saúde) para distinguir ramos e
especializações em que um referenciado possa ter condições de atuar.
Em casos especí�cos, uma especialidade pode ser dividida em várias
subespecialidades. Exemplos: Cardiologia, Cardiologia Pediátrica,
Cirurgia Cardiovascular, Clínica Geral, Ortopedia, Pediatria, etc.
7.6. Qualidade dos modelos de dados
Os modelos de dados podem ser considerados os principais metadados de
uma organização e devem ser criados antes dos dados entrarem
efetivamente no ambiente produtivo, portanto nada mais adequado do que
estabelecer processos para a veri�cação da qualidade deste importante
artefato. A�nal, sem metadados de qualidade não teremos dados de
qualidade!
A qualidade dos modelos de dados é atingida através de processos que
visam planejar, estabelecer, atender e monitorar os critérios de qualidade
estabelecidos para esses modelos.
7.6.1. Processos de qualidade para modelos de dados
Um conjunto de processos para qualidade dos modelos de dados pode ser
visualizado na �gura a seguir.
Figura 7.20 – Processos para qualidade da Modelagem de Dados
Uma boa prática é estabelecer esses processos levando em conta o ciclo
PDCA de qualidade, onde:
O planejamento (P) da modelagem estabelece a identi�cação das
entidades corporativas, mapeadas na Arquitetura de Dados da
organização, e também das demais necessidades de informação que
serão contempladas na modelagem. Essas informações são capturadas e
discutidas nas reuniões prévias de planejamento da modelagem.
A construção (D) do modelo de dados é feita com o apoio da equipe de
Gestão de Dados (ou pela própria equipe). O analista responsávelpelo
projeto constrói e altera o modelo de acordo com as diretrizes passadas
pelos gestores de dados em reuniões prévias do planejamento.
A checagem ou avaliação (C) do modelo de dados é executada pelo
Gestor de Dados de acordo com os critérios de qualidade prede�nidos
na metodologia e registra os dados da avaliação em uma base de
registro de dados das avaliações.
As ações corretivas (A) visam estabelecer a melhoria contínua e podem
ser tomadas tanto para o produto (modelo) quanto para o processo
(modelagem). Exemplo: se o modelo (produto) for reprovado, o
analista corrige os erros apontados no laudo de avaliação (ação para
correção do produto). Com o apoio das ferramentas de qualidade, o
Gestor Estratégico de Dados sugere ações após análise dos registros das
avaliações efetuadas em todos os modelos de dados em um
determinado período (ação para melhoria do processo).
De forma geral, esses processos estão ligados às funções de Modelagem de
Dados e também à gestão dos metadados da empresa e devem ser de�nidos
levando em conta as características do uso dessas funções na empresa.
Vale ressaltar que a veri�cação da qualidade dos modelos de dados deve
ser executada através de um processo de avaliação formal dedicado a
confrontar o cumprimento dos requisitos de qualidade dos modelos
estabelecidos na metodologia de Gestão de Dados da empresa. Ao
estabelecer este processo, devemos levar em consideração alguns fatores,
entre eles:
Sozinha, a avaliação de modelo de dados não garante a qualidade do
artefato. Ela apenas identi�ca anomalias encontradas no processo de
construção do modelo. Para ter uma qualidade completa é necessária a
adoção de processos dedicados à garantia da qualidade desses modelos.
Se a própria área de Gestão de Dados é responsável pela criação do
modelo de dados, devem ser estabelecidas formas de incluir uma
avaliação feita por uma pessoa diferente da que construiu o modelo.
A avaliação de modelos de dados deve ser uma atividade formal.
Portanto, deve ser prevista a elaboração de laudos técnicos que irão
registrar observações, ressalvas e possíveis erros encontrados durante a
veri�cação da modelagem.
Este processo não pode ser subjetivo, portanto os critérios de qualidade
dos dados devem ser bem estabelecidos e divulgados para todos os
envolvidos.
Crie uma lista de veri�cação para orientar os gestores de dados na
veri�cação da qualidade dos modelos. É simples e o conhecimento é
disseminado para todos.
7.6.2. Critérios de qualidade aplicados em modelos de dados
Os critérios de qualidade dos modelos de dados estabelecem parâmetros
para veri�cação formal dos modelos e servem como uma espécie de guia
para a obtenção da qualidade dos modelos. Entre os critérios mais comuns
adotados no mercado, podemos destacar os seguintes.
7.6.2.1. Completeza ou completude
Critério dedicado ao atendimento aos requisitos de informação e regras de
negócio dispostos nas especi�cações dos sistemas e documentação de apoio.
Todas as funcionalidades especi�cadas nos requisitos de informação e regras
de negócio devem estar contidas no modelo de dados e corretas em relação
ao negócio. Caso o modelo de dados esteja sendo construído de acordo com
processos de desenvolvimento iterativos, a regra é aplicada no conjunto de
requisitos e regras dispostos até a iteração presente.
Este critério pode ser veri�cado nos três níveis de abstração da Modelagem
de Dados (conceitual, lógico e físico). Entre os erros mais comuns
encontrados na veri�cação deste critério estão: estruturas de dados
modeladas incoerentes com as especi�cações funcionais e requisitos de
informação não contemplados no modelo de dados.
7.6.2.2. Conceituação
Critério dedicado a veri�car se as descrições dos objetos do modelo de
dados estão claras, objetivas, sem ambiguidades e de acordo com os
requisitos funcionais da aplicação. As de�nições devem estar
disponibilizadas nos principais componentes dos modelos de dados, como
entidades, atributos e relacionamentos.
Este critério pode ser veri�cado nos três níveis de abstração da Modelagem
de Dados (conceitual, lógico e físico). Vale ressaltar que as de�nições dos
diferentes níveis de abstração dos modelos não precisam ser iguais, porém
devem estar coerentes entre si.
Entre os erros mais comuns encontrados na veri�cação deste critério estão:
objetos sem de�nição, ausência de clareza nas de�nições e de�nições
tautológicas de objetos.
7.6.2.3.Integridade
Critério dedicado a veri�car se o modelo de dados está aderente à técnica
de modelagem adotada no projeto e não possui problemas estruturais que
levem a gerar dados inconsistentes. Para aplicações que utilizam modelos de
dados relacionais, as relações devem estar no mínimo na terceira forma
normal e não possuir elementos redundantes.
Este critério pode ser veri�cado tanto no modelo lógico quanto no modelo
físico. A veri�cação no modelo conceitual não é indicada, pois o propósito
deste modelo é capturar a realidade sob o ponto de vista do negócio, sem o
auxílio de mecanismos de tecnologia.
Entre os erros mais comuns encontrados na veri�cação deste critério estão:
redundância de dados, violação das formas normais e desrespeito às boas
práticas de Modelagem de Dados.
7.6.2.4. Flexibilidade
O modelo de dados deve ser projetado com uma �exibilidade adequada
para suportar mudanças na realidade do negócio sem alterações expressivas
na estrutura do modelo atual.
A �exibilização do modelo de dados deve ser ajustada a cada caso. De
forma geral, modelos muito �exíveis necessitam de mecanismos adicionais
para o controle da integridade das informações na construção das
aplicações. Por outro lado, modelos pouco �exíveis aparentemente requerem
menor trabalho nas implementações, porém costumam exigir maiores
esforços nas manutenções, sejam elas evolutivas ou corretivas.
Este critério pode ser veri�cado tanto no modelo lógico quanto no modelo
físico.
Entre os erros mais comuns encontrados na veri�cação deste critério estão:
utilização de domínios não estáveis como colunas, utilização desnecessária
de metamodelos e chaves primárias associadas a colunas onde a empresa
não tem o controle da regra de formação dos dados – por exemplo, número
do CPF (atributo mantido pela Receita Federal e não pela empresa).
7.6.2.5. Integração
Quando necessário, o modelo de dados deve suportar o uso de dados
corporativos, armazenados nas bases de dados integradas da empresa. De
forma geral, toda informação já existente no ambiente corporativo de uma
empresa deve ser reutilizada seguindo as diretrizes de acesso aos dados
corporativos previstos na Arquitetura de Dados da empresa. A�nal, se um
dado já existe, por que criá-lo de forma repetitiva e consumir mais esforços
de armazenamento e controle de redundância?
Este critério pode ser veri�cado tanto no modelo lógico quanto no Modelo
Físico de Dados. Geralmente o modelo lógico indica qual a origem do dado
que será reutilizado, enquanto o modelo físico indica como o dado será
consumido (serviços, acessos nativos, etc.).
O erro comum na veri�cação deste requisito é ter objetos redundantes
criados nos modelos de dados.
7.6.2.6. Legibilidade
Critério que veri�ca se o modelo de dados possui um fácil entendimento,
está legível, limpo e não poluído. Todas as informações necessárias à
compreensão do modelo devem estar disponíveis de forma clara no seu
desenho e/ou dicionário de dados. Quando necessário, o modelo deverá ser
dividido em áreas especí�cas de interesse, também conhecidas como subject
areas.
Este critério pode ser veri�cado nos três níveis de abstração da Modelagem
de Dados (conceitual, lógico e físico).
Entre os erros mais comuns encontrados na veri�cação deste critério
podemos destacar: modelos extensos sem uso de “subject areas”,
relacionamentos mal dispostos gra�camente, informações de domínios não
informadas ou incompletas nas de�nições dos atributos.
7.6.2.7. Padronização
Modelos de dados requerem a criação de padrões de nomenclatura. Sem
eles, cada pessoa construirá um modelo de dados ao seu bem entender.Este
critério estabelece que o modelo de dados deve respeitar a nomenclatura
estabelecida no padrão vigente na empresa; além da utilização correta dos
demais padrões, processos e ferramentas adotados na empresa.
Este critério pode ser veri�cado nos três níveis de abstração da Modelagem
de Dados (conceitual, lógico e físico).
7.6.2.8. Aspectos físicos e de performance
Os elementos estruturais representados no Modelo Físico de Dados devem
ser utilizados de maneira correta e retratar exatamente o conteúdo da
estrutura do ambiente que o modelo se propõe a representar (modelo
sincronizado com a base de dados). Os elementos do Modelo Físico de
Dados não devem prejudicar a performance do sistema e nem devem
contribuir para um eventual desperdício do espaço de armazenamento em
disco no SGBD. Este critério é veri�cado somente no Modelo Físico de
Dados.
Entre os erros mais comuns encontrados na veri�cação deste critério
podemos destacar: índices criados de forma desorganizada, informações do
volume de registros das tabelas não informadas na ferramenta CASE e
desnormalizações desnecessárias.
7.7. Considerações finais sobre Modelagem de
Dados
A Modelagem de Dados continua sendo uma das mais importantes
funções da Gestão de Dados. Seu principal artefato, o modelo de dados, é
utilizado em várias funções da Gestão de Dados e também serve como
principal entrada e saída de vários processos dentro da Gestão de Dados.
Um bom trabalho de modelagem não envolve apenas o levantamento de
informações e a diagramação de um modelo feita por um analista ou
projetista de dados para atender às necessidades pontuais de um
determinado projeto.
Um bom trabalho de modelagem envolve a participação de vários
pro�ssionais em diversas fases dentro do ciclo de vida de desenvolvimento
de sistemas. Um modelo de dados não deve ser visto apenas como um
instrumento para registrar a documentação das estruturas de dados de uma
aplicação, mas o resultado de um trabalho de levantamento e análise,
levando em conta uma visão mais ampla, corporativa, sobre o uso das
estruturas de dados projetadas, a �m de sempre buscar a reutilização de
conceitos já mapeados e conhecidos na empresa.
Quanto ao processo de modelagem, algumas dicas são fundamentais para
manter este bom trabalho:
Estabeleça um processo padrão para levantamento de requisitos e
Modelagem de Dados.
Estabeleça pontos de controle para validação/homologação formal dos
modelos de dados produzidos. De preferência, utilize laudos para
registrar as observações pertinentes.
Sempre inicie o trabalho com um modelo conceitual.
Consulte a Arquitetura de Dados existente na empresa durante a
construção do modelo conceitual.
Valide o modelo conceitual com as pessoas das áreas de negócio.
O acesso aos modelos conceituais deve ser disponibilizado para todos
que possuem algum envolvimento com os dados. A�nal, os modelos
conceituais são importantes meios de divulgação do conhecimento do
negócio da empresa.
Já a disponibilização dos modelos físicos deve ser evitada devido a
problemas de segurança de dados no desenvolvimento de sistemas.
Derive o modelo conceitual para o modelo lógico e/ou modelo físico.
Mantenha uma rastreabilidade entre esses modelos.
Armazene os modelos em repositórios.
Estabeleça reuniões para discutir as regras ou transformações feitas
durante as construções dos modelos.
Entenda que as aplicações e os processos podem ser modi�cados com
certa frequência nas empresas, já os dados não. Portanto, tente criar
soluções de modelagem �exíveis.
8. Arquitetura de Dados
“Sempre somos capazes de dar algo mais; mesmo nas pedras
germinam as flores.”
Henri Bergson
8.1. O que é uma Arquitetura de Dados?
Podemos de�nir a Arquitetura de Dados como o conjunto de componentes
de dados e suas relações dentro de uma empresa. Os componentes desta
arquitetura são muitos e possuem diferentes níveis de abstração – desde o
conceitual, onde são representados os modelos conceituais de dados, até o
armazenamento físico, onde são representados os servidores de banco de
dados.
A Arquitetura de Dados descreve como os dados são processados,
armazenados e utilizados pelas aplicações que criam, consultam e
manipulam os dados. A Arquitetura de Dados fornece os critérios para as
operações com os dados, possibilitando que sejam projetados e também
controlados os �uxos de dados das aplicações.
Quando esta arquitetura é formada por elementos que são utilizados em
várias áreas de negócio ou várias aplicações distintas, chamamos este
conjunto de Arquitetura Corporativa de Dados.
A Arquitetura Corporativa de Dados é um componente da Arquitetura
Empresarial de uma empresa. Serve como um importante subsídio para
alinhar os dados e processos de negócios com a estratégia da empresa.
A Arquitetura Corporativa de Dados inclui cinco grandes categorias de
visualização:
Estratégia empresarial: representada pelas informações do âmbito
estratégico da empresa, tais como: visão, missão, objetivos estratégicos,
Cadeia de Valor e macroprocessos. Essas informações não são criadas
pela Gestão de Dados, porém toda Arquitetura Corporativa de Dados
deve estar alinhada com essas informações.
Glossário corporativo: disponibiliza informações dos termos
corporativos do negócio e dos termos comuns em Gestão de Dados.
Modelos corporativos: representação dos modelos corporativos em
camadas.
Arquitetura de integração: relação dos mecanismos homologados de
integração, padrões para consumos dos dados corporativos e catálogo
de ativos de integração.
Arquitetura de infraestrutura: relação da política de uso dos
ambientes de banco de dados, servidores e esquemas onde estão
armazenados os dados corporativos.
A �gura a seguir demonstra essas cinco grandes categorias e suas
proximidades em relação ao negócio e à tecnologia.
Figura 8.1 – Categorias de visualização de uma Arquitetura de Dados
Quando completa, uma Arquitetura de Dados traz vários benefícios para
uma empresa.
Melhor compreensão da estratégia da empresa e alinhamento das
soluções de dados com a estratégia atual.
Identi�cação clara dos requisitos de dados estratégicos.
Fornecer um vocabulário padrão de termos comuns ao negócio.
Melhor entendimento dos dados corporativos e suas relações, obtidas
através da leitura dos modelos de dados corporativos.
De�nir projetos integrados para atender aos requisitos estratégicos.
Reutilização de dados já existentes para consumo das demais
aplicações.
Estabelecimento de formas padrão para consumo dos dados
corporativos.
Inventário dos dados corporativos.
As estratégias de construção e diagramação de uma arquitetura são várias.
Cabe a cada empresa, através de seus pro�ssionais de Gestão de Dados,
escolher a melhor estratégia. Entre elas:
Uma arquitetura única de modelo corporativo com as visões
conceituais ou lógicas em uma única representação. Geralmente este
tipo de abordagem é adotado por empresas com um conjunto pequeno
de ativos de dados corporativos. Não há preocupação em manter na
arquitetura os componentes de dados não corporativos.
Uma arquitetura de modelos corporativos divididos em camadas
interligadas (conceitual, lógica e física), formadas por elementos de
dados corporativos. Este é o tipo de abordagem mais usual nas
empresas. A representação do mapeamento entre as camadas é
obrigatória para manter a rastreabilidade entre os elementos. Tal como
a abordagem anterior, não há uma preocupação em manter na
arquitetura componentes de dados não corporativos.
Uma arquitetura corporativa adotando uma das duas abordagens
anteriores mais arquiteturas especí�cas, de dados não corporativos,
formadas por elementos de dados compartilhados ou dados especí�cos
de determinadas áreas ou aplicações. Este tipo de abordagem é o mais
custoso, tanto para criar quanto para manter atualizadas as
arquiteturas. Por estas razões é a abordagem menos adotada nas
empresas.
A �gura a seguir demonstra um exemplo de como pode ser representada
uma Arquitetura de Dados.
Figura 8.2 – Exemplo de uma Arquitetura Corporativa de DadosO exemplo dado na �gura anterior ilustra uma arquitetura única que
engloba visões conceituais, lógicas e físicas. Os componentes adotados nesta
arquitetura são: modelos de dados (conceitual, lógico e físico), Cadeia de
Valor da empresa, processos, gestores dos dados e dos processos, aplicações
que criam e/ou utilizam os dados, arquitetura de referência para consumo
dos dados, detalhamento dos servidores e schemas e gerência de conteúdo
dos dados não armazenados em bancos de dados.
Dependendo das necessidades da empresa e da abordagem adotada na
construção da arquitetura, outros componentes podem ser representados,
como por exemplo: arquitetura de metadados, arquitetura para Data
Warehousing e Business Intelligence.
Vale ressaltar que a Arquitetura de Dados deve representar a evolução e/ou
relação entre os seus componentes e responder questões comuns sobre os
dados corporativos. Exemplo: dada uma entidade de um modelo conceitual
corporativo, quais as respostas para:
O signi�cado desta entidade dentro do contexto do negócio?
Qual caminho foi tomado até a sua implementação?
Onde estão persistidos os dados dessa entidade?
Quais aplicações acessam os dados dessa entidade?
Quais as formas de disponibilização desses dados?
Quem é o gestor desses dados?
8.2. Atividades necessárias para criar e manter
uma Arquitetura de Dados
Manter uma Arquitetura de Dados não é algo trivial. Envolve a
colaboração dos pro�ssionais de Gestão de Dados de TI e também dos
pro�ssionais de dados da área de negócios. A gestão desta arquitetura
envolve atividades que devem estar perfeitamente alinhadas entre esses
pro�ssionais. A de�nição desses papéis e responsabilidades é obrigatória e
geralmente é uma incumbência da função “Governança de Dados”.
Segundo o guia DAMA-DMBOK®, as atividades necessárias para gerir uma
Arquitetura de Dados são as seguintes:
Entender as necessidades de informação da empresa.
Desenvolver e manter o modelo corporativo de dados.
Analisar e alinhar o Modelo Conceitual de Dados com outros modelos
de negócios.
De�nir e manter uma arquitetura de tecnologia de dados.
De�nir e manter uma arquitetura de integração de dados.
De�nir e manter uma arquitetura de Data Warehousing e de Business
Intelligence.
De�nir e manter uma taxonomia e padrões de nomes (namespaces) de
dados para a empresa.
De�nir e manter uma arquitetura de metadados.
Além das atividades previstas no guia DAMA-DMBOK®, também
considero importantes as seguintes atividades:
Análise da Cadeia de Valor da empresa e processos de alto nível. Esta
atividade é fundamental para compreender a visão estratégica dos
processos de negócio da empresa. A partir deste ponto os gestores de
dados têm melhores condições de entender as necessidades de
informação. Os modelos conceituais de dados devem estar alinhados
com a visão estratégica e a visão dos processos. Sem isso, corre-se o
risco de criar uma arquitetura pouco �exível e não aderente à estratégia
da empresa.
Projetar e manter o desenho da Arquitetura de Dados com as
interligações de seus elementos. Este trabalho é fundamental para
representar uma visão estática de todos os elementos de dados
previstos na arquitetura.
Auditar o conteúdo da Arquitetura de Dados vigente. Esta atividade
visa checar se o que está representado na Arquitetura de Dados está
atualizado e vem sendo cumprido.
8.3. Arquitetura de Dados não é apenas uma
coleção de modelos de dados e bancos de dados
A Arquitetura de Dados é muito mais do que apenas modelos de dados e
bancos de dados. Ela é extremamente útil para manter o alinhamento dos
dados com a estratégia da empresa através da análise da Cadeia de Valor e
seus macroprocessos. Além disso, a Arquitetura de Dados ajuda a
estabelecer a semântica de uma empresa, utilizando um vocabulário comum
de termos de negócio, minimizando as barreiras de entendimento dos
negócios.
As seções a seguir detalham esses dois importantes componentes de uma
Arquitetura de Dados.
8.3.1. Cadeia de Valor e macroprocessos
A Cadeia de Valor é o modelo que descreve a empresa como um conjunto
de macroprocessos que são executados de forma integrada para agregar
valor às partes interessadas.
A Cadeia de Valor especi�ca as principais funções que agregam valor à
companhia, sem necessariamente explicitar todas as interfaces entre elas.
A partir da Cadeia de Valor, as funções são desdobradas em
macroprocessos. Idealmente, cada macroprocesso visa atingir um ou mais
objetivos, que devem estar alinhados com o modelo de objetivos estratégicos
da organização.
A Cadeia de Valor pode ser aplicada em qualquer organização. Para efeitos
didáticos, vamos aplicar o conceito de Cadeia de Valor em uma área de
Administração de Dados de uma empresa, no exemplo que será dado na
�gura a seguir.
Figura 8.3 – Exemplo de Cadeia de Valor
A Cadeia de Valor do exemplo está dividida em três grandes conceitos. A
parte superior, formada pelo macroprocesso Gerir Metodologia e Processos,
pode ser considerada a parte estratégica da cadeia. A parte central é formada
pelos macroprocessos ligados à Modelagem de Dados. Esta camada é
considerada a parte central da Cadeia de Valor e representa os principais
macroprocessos executados pela área. Já a parte inferior é formada pelos
macroprocessos de apoio que são utilizados para prestar suporte aos
macroprocessos centrais.
Os macroprocessos são decompostos em processos menores; no caso do
exemplo aplicado sobre a Cadeia de Valor do livro, podemos encontrar o
seguinte desdobramento: Macroprocesso: “Gerir Metodologia e
Processos”
Processos:
Revisar documento da metodologia.
Alterar documento da metodologia.
Acompanhar indicadores de processos de trabalho.
Revisar processo de trabalho.
Divulgar alteração em documento da metodologia.
Capacitar envolvidos nos processos e metodologia.
Macroprocesso: “Garantir Qualidade dos Modelos de Dados”
Processos:
Acompanhar levantamento de requisitos.
Efetuar consultoria em modelagem.
Efetuar reunião de acompanhamento sobre qualidade da modelagem.
Macroprocesso: “Elaborar Modelo de Dados”
Processos:
Consultar metadados existentes.
Elaborar modelos de dados.
Encaminhar modelos de dados para avaliação.
Macroprocesso: “Controlar Qualidade dos Modelos de Dados”
Processos:
Avaliar modelos de dados.
Alimentar indicadores de qualidade das avaliações.
Macroprocesso: “Disponibilizar Informações Compartilhadas”
Processos:
Consultar metadados no repositório.
De�nir forma de compartilhamento.
Compartilhar entidade corporativa em modelo de dados.
Macroprocesso: “Gerir Modelos no Repositório”
Processos:
Disponibilizar modelo de dados.
Gravar modelo de dados no repositório.
Efetuar operação de complete x compare.
Efetuar engenharia reversa.
Administrar usuários do repositório.
Macroprocesso: “Implementar Modelo de Dados”
Processos:
Implementar modelo de dados.
Versionar script.
Todos os processos mencionados utilizam e/ou fazem referências a
entidades de dados. As entidades corporativas são representadas em
modelos de dados corporativos da Arquitetura de Dados da empresa. O
trabalho de construção da Cadeia de Valor, bem como o desdobramento dos
seus macroprocessos, geralmente não é feito pelo staff da Gestão de Dados, e
sim por pro�ssionais especialistas em mapeamento e desenho de processos.
Contudo, esses artefatos devem obrigatoriamente ser representados na
Arquitetura de Dados da empresa, pois representam uma visão de alto nível
da organização.
Na criação dos modelos de dados corporativos tanto a Cadeia de Valor
quanto os objetivos estratégicos da empresa (missão, visão, objetivos, etc.)
são levados em conta na especi�cação das entidades corporativas que irão
compor esses modelos.
8.3.2. Glossário de termos corporativos
Os glossários corporativos podem ser divididos em dois artefatos distintos:
o glossário de termos de Gestão de Dados e o glossário de termos de
negócio. O primeiro estabelece um vocabulário sobre os termos comuns de
Gestão de Dados que são utilizados na empresa. Apesar de simples, estedocumento é extremamente útil para nivelar o entendimento de conceitos
que, a princípio, parecem ser de domínio de todos, porém, na prática, é
comum encontrar pessoas, principalmente com pouca experiência em
Gestão de Dados, utilizando conceitos errados com de�nições erradas.
Neste glossário encontramos de�nições que devem ser disseminadas para
todo o público envolvido com Gestão de Dados na empresa. Aqui
encontraremos as de�nições para os principais termos de Gestão de Dados.
A tabela a seguir demonstra exemplos de termos de Gestão de Dados que
geralmente são incluídos em um glossário.
Termo De�nição
AD Sigla de Administrador de Dados.
Atributo
Informação que representa uma propriedade de uma entidade e/ou
relacionamento. Os atributos são utilizados nos projetos conceitual e
lógico de dados.
Base de Dados
Compartilhada Base de dados que é acessada por mais de uma aplicação.
Base de Dados
Corporativa
Base de dados compartilhada formada por informações oriundas de
dados de referência e dados mestres. Mantida por uma área
corporativa, a base de dados é acessada por várias áreas da
organização, e suas informações possuem um alto grau de
reutilização.
Cardinalidade
Quantidade de ocorrências em que uma entidade ou tabela participa
de forma mínima (cardinalidade mínima) e forma máxima
(cardinalidade máxima) de um relacionamento.
Coluna Unidade básica de armazenamento de dados em um registro dentro
de uma tabela.
Dado Mestre
Dado processado por uma área de negócio ligada às atividades
centrais da companhia e compartilhado para as demais áreas de
negócio da organização. Um dado mestre está ligado diretamente ao
negócio central da empresa. Exemplos de dados mestres: cliente,
fornecedor, material, etc.
Dado de
Referência
Dado processado por qualquer área de negócio ou importado de
fontes externas à organização. Um dado de referência não faz parte do
negócio central da empresa e é acessado por várias aplicações na
companhia. Exemplos de dados de referência: unidade federativa,
unidade de medida.
Entidade
Objetos que têm existência própria e podem ser identi�cados
distintamente quando consideramos o escopo de requisitos e regras
de negócio a serem modelados. Uma entidade é descrita por seus
atributos.
Tabela Componente de armazenamento de dados, formado por um conjunto
de dados dispostos em número �nito de colunas e número ilimitado
de linhas.
Tabela 8.1 – Exemplos de termos inclusos em um glossário de termos de Gestão de
Dados
Já o glossário corporativo de termos de negócio fornece de�nições padrão
para os conceitos de negócio corporativos da empresa. Cada termo está
ligado diretamente a uma entidade ou atributo(s) de uma entidade
modelada nas camadas de modelos de dados da Arquitetura de Dados
corporativa da empresa.
É recomendado que a inclusão de cada termo no glossário e sua de�nição
sejam feitas após uma rigorosa análise do grupo responsável por manter o
glossário. Geralmente este grupo é formado por uma comissão permanente
de pro�ssionais de negócio ou então, em casos iniciais de implantação do
glossário, por um comitê de Gestão de Dados. Esta análise leva em conta a
aderência do termo em relação ao negócio (de forma corporativa), além da
coerência da de�nição proposta à estrutura representada em um modelo da
arquitetura corporativa. Todo termo incluso no glossário deve ser
representado em um modelo existente, sob forma de atributo ou entidade,
na arquitetura corporativa vigente.
Por �m, a divulgação deste glossário deve ser ampla e de fácil acesso a
todos os colaboradores da empresa.
8.4. Modelos de dados e Arquitetura de Dados
Modelos de dados representam uma visão única e estática dos dados, ou
seja, na prática temos uma espécie de visão similar a uma planta baixa de
um imóvel. Quando uma empresa decide implementar uma Arquitetura de
Dados, precisamos ter em mente que não podemos começar com algo muito
ambicioso, abrangendo todos os dados da empresa.
Uma boa prática é começar com a criação de uma Arquitetura Corporativa
de Dados, onde somente os dados corporativos serão incluídos. A
visualização de quem entra (é corporativo) ou não na arquitetura só é
possível de ser feita através da leitura dos modelos de dados. Portanto, o
modelo de dados é o principal elemento de uma arquitetura e sua
representação é obrigatória.
Os critérios para diferenciar um dado corporativo de um dado
compartilhado e também de um dado de transação comum serão
conhecidos mais adiante.
8.5. Modelos de dados compartilhados
Modelos de dados formados por entidades que são reutilizadas na
organização. Nem todo modelo compartilhado é um modelo corporativo,
porém todo modelo corporativo é um modelo compartilhado.
8.6. Modelos de dados corporativos
Uma de�nição simples e comum que pode ser aplicada a modelos de dados
corporativos é a seguinte: “modelo ou grupo de modelos formados pelos
principais conceitos de negócio da empresa. Os modelos corporativos
possuem vários níveis de abstração”.
Vale lembrar que modelos de dados corporativos possuem características
compartilhadas, porém nem sempre os modelos compartilhados são
modelos corporativos.
Modelos de dados corporativos são formados por entidades corporativas.
Uma entidade corporativa é utilizada por várias áreas dentro de uma
empresa. FUNCIONARIO e UNIDADE_FEDERATIVA são exemplos
clássicos de entidades de dados corporativos. Os dados da primeira entidade
são geralmente criados dentro dos departamentos de RH da empresa e
depois disponibilizados para aplicações de diversas áreas. Já os dados da
segunda entidade geralmente são adquiridos de fontes externas (CEP, IBGE)
e depois de adquiridos também são disponibilizados para várias áreas da
empresa.
Apesar dos dados não serem criados na empresa, a
UNIDADE_FEDERATIVA pertence a um conceito de “LOCALIZAÇÃO”
que in�uencia diretamente em conceitos de negócio de diferentes áreas da
empresa Já uma entidade compartilhada é utilizada por mais de uma
aplicação, porém limitada a uma ou poucas áreas da empresa. A entidade
FATURA é um exemplo clássico de uma entidade compartilhada.
Geralmente os dados dessa entidade são criados dentro da área �nanceira da
empresa e depois são disponibilizados para algumas aplicações da própria
área �nanceira. Ou seja, o dado não circulou por várias áreas da empresa.
Um modelo de dados corporativo requer investimentos signi�cativos na
de�nição e documentação de um vocabulário comum, regras de negócios e
conhecimento do negócio que atenda a toda a empresa.
Sua criação, manutenção e enriquecimento exigem investimentos
contínuos de tempo e esforço, mesmo quando se começa com a aquisição de
um modelo de dados externo ou legado.
8.6.1. Como diferenciar modelos corporativos dos modelos
compartilhados
Uma das principais dúvidas em termos de Arquitetura de Dados
corporativa é identi�car o que é corporativo e o que é compartilhado. Os
itens a seguir ajudam a esclarecer essas dúvidas.
Modelos corporativos possuem alto nível de abstração (conceitual ou
lógica).
Modelos corporativos possuem um escopo mais amplo, onde uma
mesma entidade é utilizada por várias áreas de negócio.
Modelos corporativos não fazem mapeamento direto para o SGBD.
Eles são representados em uma Arquitetura de Dados corporativa.
Modelos compartilhados possuem um nível mais próximo à
implementação (modelos lógicos ou físicos).
Modelos compartilhados possuem um escopo mais especí�co.
Geralmente as entidades são utilizadas em uma única área de negócio
ou no máximo em duas.
Modelos compartilhados podem fazer mapeamento direto para o
SGBD.
8.6.2. Abordagens para construção de modelos corporativos
Entre as abordagens de construção dos modelos corporativos, as mais
comuns são: Top Down, Bottom Up e Híbrida. A �gura a seguir demonstra
as abordagens de construção deste modelo.
Figura 8.4 – Abordagens para construção de modelos de dados corporativos
8.6.2.1. Abordagem Top Down
Entidades mapeadas e modeladas a partir de macroconceitos, Cadeia de
Valor e processos da empresa. Geralmente a iniciativa conta como apoio das
altas gerências, tanto de negócio, quanto de TI. Sequência normal das
atividades: mapeamento dos macroconceitos e processos, modelagem
conceitual, modelagem lógica (se houver), modelagem física e
implementação. A abordagem Top Down é considerada o ciclo de vida ideal
para construção dos modelos de dados corporativos.
8.6.2.2. Abordagem Bottom Up
Entidades mapeadas e modeladas a partir dos modelos físicos de dados
existentes. Geralmente esta iniciativa é feita pelos técnicos da área de TI. O
propósito do trabalho é tentar “arrumar a casa” com os objetos já existentes.
Sequência normal das atividades: engenharia reversa das bases de dados,
documentação do Modelo Físico de Dados, modelagem lógica (se houver) e
modelagem conceitual (de acordo com os conceitos obtidos das bases
físicas).
8.6.2.3. Abordagem Híbrida
O trabalho geralmente é iniciado a partir das necessidades levantadas pela
própria área de TI. A construção do modelo leva em conta tanto os objetos
físicos existentes (obtidos através de engenharia reversa) como os modelos
de processo (mapeados) e a Cadeia de Valor da empresa.
8.7. Tipos de modelos de dados corporativos
segundo o DAMA-DMBOK®
O guia DAMA-DMBOK® estabelece algumas diretrizes para tratar os
modelos corporativos dentro de uma Arquitetura de Dados. A principal é
estabelecer uma cadeia no estilo Top Down de modelos corporativos,
separados em camadas, a partir da visão de um modelo único, com uma
visão bem genérica, sendo desmembrado depois em mais duas camadas:
uma com modelos conceituais integrados e outra mais detalhada com
modelos lógicos de dados. A �gura a seguir mostra o exemplo dos tipos de
modelos de dados sugeridos pelo guia DAMA-DMBOK® dentro de uma
Arquitetura de Dados.
Figura 8.5-Camada de modelos corporativos segundo o DAMA-DMBOK®
8.7.1. Modelo de Área de Interesse
O Modelo de Área de Interesse, também conhecido como modelo de
Subject Area, representa a cadeia mais alta dentro dos modelos de dados
corporativos da Arquitetura de Dados da empresa.
O Modelo de Áreas de Interesse é único e representa a lista de grandes
áreas temáticas que, coletivamente, expressam o escopo essencial de uma
empresa. Geralmente o modelo é composto de doze a vinte conceitos
corporativos. Não há uma notação especí�ca para representar este tipo de
modelo.
As �guras a seguir demonstram dois exemplos de representação de um
modelo de Subject Area. O primeiro agrupa conceitos maiores dentro de
uma hierarquia. A segunda mostra os conceitos temáticos em uma espécie
de mapa mental.
Figura 8.6 – Exemplo de Modelo de Área de Interesse
Figura 8.7 – Exemplo de Modelo de Área de Interesse (mapa mental)
A seleção e a nomeação das áreas de interesse essenciais da organização
são criticamente importantes para o sucesso de todo o desenvolvimento dos
demais modelos de dados corporativos, portanto, apesar de aparentar ser
simples, este modelo deve ser elaborado e revisado com bastante critério,
pois, depois da cadeia de modelos ser estabelecida, as alterações neste nível
desdobrarão diversas modi�cações em cadeia.
As áreas de interesse orientam as interações e organizam o escopo e a
prioridade do desenvolvimento dos demais modelos. O Modelo de Área de
Interesse é “correto” quando é aceito por todos os stakeholders da empresa.
Além disso, é útil em um sentido prático na empresa para a construção de
diversas iniciativas, como, por exemplo: Governança de Dados, gestão
estratégica de dados e Modelagem de Dados corporativa.
Geralmente os modelos de área de interesse são construídos pelos gestores
estratégicos de dados, apoiados pelos gestores de dados de negócio.
8.7.2. Modelos conceituais de dados
Segundo arquitetura proposta pela guia DAMA-DMBOK®, cada área de
interesse deve ser mais bem detalhada por um ou mais modelos conceituais
de dados, integrados na mesma área ou integrados a áreas diferentes.
O guia recomenda que esta camada, formada por modelos conceituais,
tenha um número estimado de 150 a trezentas entidades de negócio
representadas em seus modelos conceituais.
Nesta camada, os modelos conceituais não precisam ter um grau de
detalhamento dos atributos e demais mecanismos de abstração muito
aprofundados – o próprio guia DAMA-DMBOK® recomenda que, nesta
camada, os modelos conceituais não possuam atributos. Esta diretriz é útil
para não poluir a visão global da arquitetura. Entretanto, os atributos e
demais mecanismos devem ser representados nos modelos conceituais das
aplicações que originam esses dados. Vale ressaltar que ambos os modelos
devem existir na empresa (modelos da arquitetura e modelos das
aplicações).
A �gura a seguir mostra um exemplo de dois modelos conceituais
corporativos integrados.
Figura 8.8 – Exemplo de modelos conceituais integrados em uma arquitetura
Na �gura anterior, podemos observar a existência de dois modelos
conceituais integrados dentro de uma mesma área de interesse. Há uma
integração do modelo de localização geográ�ca com o modelo do
endereçamento postal, pois uma localidade pode possuir um CEP exclusivo.
Já o modelo de endereçamento postal necessita das informações do modelo
de localização geográ�ca, pois tanto a entidade BAIRRO quanto a entidade
LOGRADOURO necessitam de informações provenientes do modelo de
localização geográ�ca.
Vale ressaltar que, conforme sugerido pelo DAMA-DMBOK®, os atributos
das entidades não estão disponíveis. Entretanto, vale ressaltar que as
de�nições das entidades devem estar disponíveis a todos os interessados.
Essas de�nições devem estar disponíveis no dicionário de dados de cada
modelo e/ou em um glossário corporativo de conceitos.
Geralmente os modelos conceituais de dados corporativos são construídos
em conjunto pelos gestores de dados de negócio e gestores de dados
estratégicos. Os gestores de dados de negócio são especialistas nos assuntos,
porém carecem de uma visão mais completa. Esta visão é passada pelo
gestor estratégico de dados.
Apesar de não participarem diretamente na construção desses modelos, os
gestores técnicos de dados devem ter acesso a esses modelos para efetuar
consultas e identi�car possíveis situações de reuso.
8.7.3. Modelos lógicos de dados
Os modelos lógicos de dados corporativos adicionam uma camada de
detalhe mais abaixo da camada dos modelos conceituais. Os modelos
lógicos continuam a re�etir o negócio da empresa, tal como os modelos
conceituais, e são neutros e independentes de qualquer necessidade
especí�ca de um projeto ou aplicação.
Em relação ao grau de detalhamento, os modelos lógicos possuem
atributos, porém nem todos são representados. Nesta camada são
representados apenas os principais atributos que identi�cam
particularidades fundamentais e/ou corporativas das entidades dos modelos.
Geralmente os modelos lógicos corporativos são construídos pelos gestores
técnicos de dados a partir dos modelos conceituais corporativos existentes.
8.8. Integração dos dados corporativos
A Arquitetura de Dados de uma empresa também deve relacionar as
possíveis formas de consumo dos dados corporativos representados em sua
arquitetura. De forma geral, as formas são muitas e é impossível a�rmar qual
o melhor mecanismo de uso para consumir os dados em qualquer situação e
em qualquer empresa.
Variáveis como infraestrutura de hardware da empresa, conhecimento
sobre uma determinada tecnologia, características externas do ambiente,
complexidade das aplicações, custo das operações, tempo e pessoal
disponível são alguns dos fatores que in�uenciam diretamente na escolha de
uma solução de integração.
É importante frisar que nunca uma empresa deverá optar por uma única
solução de integração. Quando trabalhamos com soluções de integração de
dados vale o ditado de Nelson Rodrigues: “toda unanimidade é burra!”. As
seções a seguir mostram as principais formas de integração dos dados.
8.8.1. Integração via troca de arquivos
A troca de arquivos é a forma mais primitiva de compartilhar dados
corporativos. Com a evolução da tecnologia, seu uso está praticamente em
extinção, porém aindaé utilizada em alguns casos extremos onde há
limitação para o consumo de informações devido à ausência de uma rede
interna ou móvel. A �gura a seguir demonstra um exemplo de consumo de
dados através da troca de arquivos.
Figura 8.9 – Integração via troca de arquivos
A simplicidade de implementação desta solução é a sua principal
vantagem. Entre as desvantagens podemos citar:
Não é uma solução adequada para interfaces que dependam fortemente
de dados atuais (processamento online).
A solução requer gastos adicionais com armazenamento dos dados. O
dispositivo de armazenagem geralmente é uma área de disco da rede
corporativa.
Di�culdade na monitoração da interface.
Redundância dos dados, pois a mesma informação estará armazenada
em mais de um lugar.
Dependência de outros métodos ou ferramentas para agendar a
geração dos arquivos.
8.8.2. Integração via ETL
Atualmente, o consumo de dados corporativos via ETL é uma das formas
mais usuais de consumo dos dados corporativos. ETL signi�ca Extract,
Transform and Load (extrair, transformar e ler). Ou seja, o dado é extraído
de uma origem, logo após é transformado através de regras de
transformação (ou não) e carregado em uma tabela destino, em local
diferente de onde ele foi extraído.
A integração via ETL é utilizada quando os dados corporativos estão
armazenados em um servidor de banco de dados diferente do servidor onde
a aplicação destino irá consumir os dados corporativos ou há necessidade de
transformar os dados corporativos em outro formato diferente do que ele é
armazenado.
Quando o ETL é utilizado, temos uma replicação da informação
corporativa, portanto, sempre que esta solução for adotada, devem ser
previstos mecanismos de controle para garantir a integridade do dado
compartilhado. A informação replicada no banco de dados de destino não
permite privilégios de escrita na tabela onde foi feita a cópia. O acesso é
dado somente para leitura. A �gura a seguir demonstra um exemplo de
consumo de dados através da troca de dados via ETL.
Figura 8.10 – Exemplo de integração de dados via ETL
No exemplo anterior os dados de CLIENTE estão armazenados em uma
base de dados corporativa. Uma aplicação qualquer, armazenada em outro
servidor, precisa consumir os dados referentes aos códigos e nomes dos
clientes. Para transferir os dados de cliente para este outro servidor, optou-se
por utilizar o ETL como estratégia de integração de dados. Foi criada uma
tabela para receber os dados solicitados. Repare que nem todas as
informações de CLIENTE foram levadas para a réplica, e sim somente as
necessárias.
O acesso da aplicação à tabela de réplica é feito somente para leitura, ou
seja, não há risco de incluir na tabela de réplica algum dado de cliente em
local diferente do estabelecido para este dado corporativo. En�m, há uma
redundância, mas ela é controlada.
Entre as vantagens desta forma de integração podemos citar:
Solução ideal para manipular grandes volumes de dados.
Solução ideal para cargas de dados históricos.
Já entre as desvantagens podemos citar:
O processo ETL geralmente roda durante a noite, quando não há muito
processamento dos dados pelas aplicações. Com isso, existe um atraso
de um dia em relação à atualização dos dados.
Redundância.
Processo de extração dos dados custoso.
Gastos adicionais com armazenamento.
Dependência de ferramentas e pessoal especializado.
8.8.3. Integração via Database Links ou Linked Servers
Database Link (Oracle) ou Linked Server (SQL Server) são objetos criados
em esquemas de bancos de dados que possibilitam o acesso a objetos em
outros servidores de banco de dados, sejam eles do mesmo produto ou não.
Esse tipo de sistema é conhecido como Sistema de Banco de Dados
Distribuídos e pode ser considerado homogêneo (quando acessa outros
bancos de dados do mesmo fornecedor) ou heterogêneo (quando acessa
outros tipos de bancos de dados).
A �gura a seguir demonstra um exemplo de consumo de dados através do
uso dessas ferramentas.
Figura 8.11 – Exemplo de uso de Database Link ou Linked Server No exemplo
anterior a aplicação acessa os dados do esquema corporativo através do link
estabelecido. Por questões de segurança, é recomendado que o link aponte para visões
no servidor de origem, ao invés de apontar para tabelas.
Entre as vantagens podemos citar que esse tipo de solução é simples e já é
adotada por algumas empresas há algum tempo no mercado. Além disso, é
totalmente independente de outras soluções.
Já as desvantagens estão ligadas a:
Performance, principalmente se os esquemas corporativos possuírem
muitas aplicações penduradas nesse tipo de solução.
Administração custosa.
Difícil governança.
8.8.4. Replicação de dados e Oracle Golden Gate
Sob o ponto de vista das aplicações que consomem as informações
corporativas, a replicação de dados sempre foi uma das formas mais
desejadas de consumo de dados pelas equipes de desenvolvimento, mas
geralmente as tentativas esbarravam nas infraestruturas ou em Arquiteturas
de Dados das empresas que não permitiam este tipo de solução, devido às
questões de redundância e governança. Para manter as replicações sob
controle eram necessários esforços hercúleos dessas equipes. Entretanto,
recentemente a Oracle lançou um produto no mercado que promete acabar
com todos esses esforços.
O Oracle Golden Gate resolve um problema presente no dia a dia das
empresas: integrar dados de bases heterogêneas em tempo real e a um custo
efetivo. Essa solução possibilita a replicação online de dados em ambientes
heterogêneos, o que, além de gerar maior agilidade para seu negócio, reduz
o custo total de propriedade de TI, já que permite a manutenção do
ambiente legado na sua base atual, eliminando custos e esforços de
migração.
O Golden Gate trabalha com diversos ambientes e em inúmeras
arquiteturas (replicação unidirecional, bidirecional, peer-to-peer,
transmissão, consolidação e cascateamento de dados) e é �exível para
atender de forma efetiva e com alto desempenho às necessidades dos
negócios. A �gura a seguir demonstra um exemplo da solução Oracle
Golden Gate.
Figura 8.12 – Exemplo de uso do Oracle Golden Gate
As principais vantagens desta solução são:
Possibilidade de trabalhar com dados atualizados em tempo real.
Excelente performance.
Fácil governança.
Já entre as desvantagens podemos citar:
Solução limitada a uma tecnologia (Oracle).
Dados replicados (apesar de ser uma redundância controlada).
A solução ainda é nova no mercado. Poucas empresas a utilizam.
8.8.5. Integração via serviços
O grande uso de serviços e de seus padrões de suporte à integração de
negócios levou a grandes avanços na integração de dados e aplicações. O uso
de serviços não é nenhuma novidade, porém seu uso voltou à tona devido
ao novo paradigma de adoção da arquitetura SOA.
A arquitetura orientada a serviços (SOA) apresenta-se mais �exível e capaz
de suportar serviços independentes de plataforma e protocolo em um
ambiente. “Serviços”, do ponto de vista de SOA, são módulos de negócio ou
funcionalidades das aplicações que possuem interfaces expostas e que são
invocados via mensagens. Por exemplo, em um sistema de seguros teríamos
os seguintes serviços: serviço de nomes e endereços, serviço de abertura de
sinistro, serviço de consulta de apólices, etc.
Um serviço deve possuir uma interface bem de�nida e funcionar de forma
independente do estado de outros serviços, exceto nos casos de serviços
compostos (composite services).
A comunicação entre o sistema cliente e aquele que disponibiliza o serviço
é normalmente realizada através de web services. Frequentemente esses
serviços são conectados através de um “barramento de serviços”, que
disponibiliza interfaces, ou contratos, acessíveis através de web services.
A arquitetura SOA provê facilidades de integração com diferentes
tecnologias, aumentando a produtividade de equipes de desenvolvimento e
diminuindo o tempo de entrega das soluções que acessam os dados na
empresa.
Segundo o Gartner, SOA é uma abordagem arquitetural corporativa quepermite a criação de serviços de negócio interoperáveis que podem
facilmente ser reutilizados e compartilhados entre aplicações e empresas.
A �gura a seguir demonstra um exemplo de consumo de dados através de
serviços.
Figura 8.13 – Exemplo de dados corporativos consumidos via serviços
A �gura anterior representa dois esquemas corporativos que
disponibilizam dados através de serviços. O primeiro esquema armazena
dados corporativos de clientes. A �gura ilustra três aplicações que
consomem os dados dos clientes através de um serviço denominado “Busca
Cliente”. Já o segundo esquema armazena dados corporativos de localidades.
As aplicações D, E e F consomem os dados corporativos de localidades
através do serviço “Busca UF”.
A disponibilização de dados via serviços possui várias vantagens:
Modularidade.
Interoperabilidade (independência de plataformas).
Reutilização.
Flexibilidade.
Segregação de equipes (paralelismo nas ações).
Ideal para processamento online (síncrono).
Fraco acoplamento (nenhum código é fornecido para o aplicativo
consumidor).
Já entre as desvantagens podemos citar:
Desempenho.
Limitações na manutenção de interfaces.
Não é adequado para grandes volumes de dados.
Chamadas de serviços não devem ser colocadas dentro de loops.
Na carona da implantação da arquitetura SOA nas empresas, o uso de
serviços para consumir dados corporativos vem sendo adotado como
principal diretriz para integração dos dados. Em alguns casos, há certo
exagero em de�nir o uso de serviços como a única forma de consumo desses
dados.
Conforme mencionado antes, não há uma forma única e ideal para
consumir dados corporativos. Todas as soluções possuem vantagens e
desvantagens que devem ser levadas em conta conforme as necessidades de
consumo dos dados.
9. Gestão de Dados Mestres
e Referência
“A vida é um caminho de sombras e luzes. O importante é que
se saiba vitalizar as sombras e aproveitar a luz.”
Henri Bergson
9.1. Contextualização
Em qualquer empresa existem conceitos comumente reconhecidos que são
o foco dos processos de negócio, tais como clientes, produtos, fornecedores,
vendedores e funcionários.
Os dados desses conceitos são considerados mestres e constituem os
principais dados de uma empresa. De forma geral, esses dados são
categorizados por outros dados, considerados dados de referência.
Quando a empresa não possui uma gestão efetiva desses conceitos,
representados sob a ótica dos dados, cada vez mais são criados silos de
dados, gerando um número crescente de disparidades de conceitos e valores
nas aplicações da empresa e apresentando duplicações e representações
redundantes, muitas vezes diferentes, sobre os mesmos conceitos.
A Gestão de Dados Mestres e Referência (MDM – Master Data
Management) procura eliminar essas disparidades e fornecer mecanismos
para eliminar a cultura “feudal” sobre o uso dos dados. Um dos mais
importantes princípios do MDM é que o dado não é de uso exclusivo de
uma determinada área e sim de toda a empresa. A �gura a seguir mostra um
exemplo típico de uma empresa que não possui uma Gestão de Dados
Mestres e Referência efetivamente implantada.
Figura 9.1-Exemplo típico de empresa que não possui MDM implantado
Conforme podemos observar, os mesmos problemas decorrentes da má
gestão dos dados, vistos anteriormente nos capítulos iniciais do livro,
ocorrem quando não existe uma gestão efetiva sobre os dados mestres e de
referência de uma empresa. Olhando sob este ponto de vista, podemos
concluir que a gestão dos dados mestres e de referência é um subconjunto da
Gestão de Dados aplicado nos principais dados da empresa. Mas, a�nal, o
que são dados mestres e dados de referência?
9.2. Dados mestres
Dados mestres são dados sobre as entidades de negócio que provêm um
contexto para as transações de negócio. Entre exemplos de dados mestres
podemos citar: clientes, fornecedores, funcionários, produtos, contratos,
imóveis, contas, etc.
Os dados mestres são considerados dados críticos para o negócio, tendem
a ser mais estáveis que os dados de transação e são utilizados por mais de
uma área de negócio. Exemplo: um cliente pode estar envolvido em vários
processos de negócio, tais como campanhas de marketing, sistemas de
vendas, faturamento e cobrança.
Os dados mestres são classi�cados em três grandes grupos: pessoas, coisas
e locais. A �gura a seguir demonstra um exemplo de classi�cação de dados
mestres.
Figura 9.2 – Classi�cação dos dados mestres
Diferentemente dos dados de referência, dados mestres usualmente não
são limitados a valores de domínios prede�nidos. Entretanto, regras de
negócio podem in�uenciar no formato e nos intervalos permitidos para os
valores dos dados mestres.
Os dados mestres são encontrados tanto no patamar operacional quanto
no estratégico, apoiando os processos de tomada de decisão da empresa. Em
sistemas transacionais, os dados mestres estão quase sempre envolvidos com
dados de transações. Um cliente compra um produto. Um fornecedor vende
um item e um parceiro entrega uma caixa de materiais em um local.
Os dados mestres são os dados autorizáveis disponíveis mais precisos sobre
as entidades chave do negócio. São utilizados para estabelecer um contexto
para os dados das transações.
Esta relação entre dados mestres e dados transacionais pode ser
considerada, de forma geral, como uma relação “verbo/substantivo”. Os
dados transacionais capturam os verbos, como vender, entregar, comprar; já
os dados mestres são os substantivos.
9.3. Dados de referência
Dados de referência são utilizados para categorizar (agrupar ou classi�car)
outros dados, principalmente os dados mestres. Os dados de referência
podem ser de origem externa ou interna à corporação. São armazenados em
tabelas constituídas por códigos e suas descrições. Entre alguns exemplos
podemos citar: cargos, unidades federativas, municípios, moedas, unidades
de medida, etc.
Os dados de referência não representam um papel primário nas transações
que são processadas pelas aplicações da empresa. Entretanto, eles conectam
os dados da empresa às informações mantidas por outras aplicações e até
mesmo por outras empresas ou organizações. Como exemplo, as tabelas de
municípios e Unidades da Federação mantidas pelo IBGE.
Ainda está em dúvida sobre como identi�car dados mestres e dados de
referência? A tabela a seguir compara dados mestres e dados de referência
sob alguns aspectos:
Dados mestres Dados de referência
Muitas linhas por tabela Poucas linhas por tabela
Muitas colunas por tabela Poucas colunas por tabela
Poucas tabelas na base de dados Muitas tabelas na base de dados
Sofre alterações mais rapidamente Sofre alterações mais lentamente
Altamente compartilhados dentro
da empresa
Ainda mais compartilhados dentro da empresa e
entre empresas
Tabela 9.1 – Características de Dados Mestres e Referência
9.4. Dados transacionais
É a categoria que abrange os dados oriundos das atividades do negócio, tais
como: informações sobre ordens de compra, faturas e demonstrações
�nanceiras. São informações registradas como fatos nos modelos
multidimensionais ou transações nos modelos entidade-relacionamento.
Os dados transacionais são aqueles que alimentam e impulsionam os
indicadores de negócio da empresa. Dependem inteiramente dos dados
mestres para serem contextualizados. O modelo de dados representado na
�gura a seguir demonstra exemplos de dados transacionais, além dos dados
mestres e dados de referência.
Figura 9.3 – Exemplos de dados mestres, dados de referência e dados
transacionais.
Os dados transacionais não são compartilhados e pertencem a uma ou
poucas áreas. No exemplo dado na �gura anterior, FATURA, ITEM
FATURA e PARCELA FATURA são entidades típicas da área �nanceira,
tendo o escopo de atuação limitado a aplicações desta área.
9.5. Gerenciamento de dados mestres e
referência
Já vimos que dados mestres e dados de referência fornecem contexto para
os dados transacionais de uma empresa. A gestão desses dados tem como
objetivo manter estruturas destinadas a criare manter uma autoridade
con�ável, sustentável, precisa e segura dos ambientes de dados que
representam uma visão única, verdadeira e abrangente dos dados mestres e
dados de referência. A esta visão damos o nome de “Registro Dourado” ou
“Golden Record”.
Para isso, torna-se necessária a criação de processos, onde as áreas de
negócio e de TI colaboram para harmonizar, limpar, publicar e proteger os
dados comuns que devem ser compartilhados por toda a empresa.
A gestão de dados mestres e referência (MDM – Master Data
Management) compreende um conjunto de processos, ferramentas e
tecnologia que consistentemente de�ne e gerencia os dados mestres e dados
de referência em toda a organização, garantindo coerência, controle na
manutenção e condições de utilização desses dados.
Um programa de MDM busca apoiar as necessidades de negócios da
organização ao fornecer acesso a visões consistentes dos dados mestres e
dados de referência. Este programa governa métodos, ferramentas e serviços
para:
Avaliar a utilização de dados, coleções de valores de dados válidos e
regras de negócios explícitas e implícitas comumente usadas nas
aplicações da empresa.
Identi�car dados utilizados em diversas aplicações, cuja centralização é
relevante para o sucesso dos negócios.
Instanciar um modelo padrão para integração e gerenciamento dos
dados.
Coletar dados de fontes candidatas, avaliar o quanto as diferentes
instâncias de dados referem-se a uma mesma entidade do mundo real e
criar uma visão única e consolidada de cada uma delas (registro
dourado).
Prover métodos para acesso transparente à visão uni�cada dos dados
para novas aplicações e também para aplicações legadas.
Instituir a Gestão de Dados de Negócio, políticas de gerenciamento,
procedimentos para a organização e linhas de negócio, assegurando
uma alta qualidade dos dados mestres e dados de referência.
O MDM (Master Data Management) ajuda a eliminar os esforços para
manter os dados com qualidade, eliminando perguntas como:
“Quais dados estão certos?”
“Qual a origem correta dos dados?”
“Quais aplicações utilizam esse dado?”
“Que de�nição de vendas será utilizada hoje?”
A eliminação de dúvidas básicas sobre os dados e a geração e a
disseminação de dados corretos e de qualidade corroboram para melhorar o
processo decisório. Outros benefícios podem ser obtidos com a adoção do
MDM:
Conhecimento abrangente dos domínios relativos aos nomes dos
dados.
Relatórios com maior grau de qualidade.
Gerenciamento de riscos mais apurados devido à maior con�ança nos
ativos de dados.
Melhoria nas operações de manipulação dos dados e redução de custos.
Melhoria da análise e do planejamento de custos (orçamento).
Aderência às exigências regulatórias.
Visão integrada dos dados.
Simpli�cação do desenvolvimento de aplicações com a nova
arquitetura de MDM.
A produtividade e a qualidade dos dados dentro de um ambiente
empresarial melhoram signi�cativamente com a presença de uma
Arquitetura de Dados efetivamente integrada. A con�ança na utilização dos
dados, resultante dos processos de MDM, deixa os trabalhos mais fáceis e
produtivos.
Quando as empresas têm dados mestres corporativos, a necessidade de
“visões departamentais da verdade” se reduz à medida que as fontes
corporativas amadurecem. Desta forma, as empresas podem começar a
desfazer a rede de interfaces “spaghetti-ware”.
Em assuntos referentes às funções de Gestão de Dados, costumo dizer que
uma imagem vale mais do que mil palavras. A �gura a seguir mostra dois
cenários típicos: o primeiro, antes da implantação de um MDM, e o
segundo, após a implantação do MDM, seguindo uma abordagem de
implementação conhecida como consolidação.
Figura 9.4 – Exemplo de utilização “antes e depois” de um programa de MDM
Antes da implantação do MDM, podemos observar que os dados �uem
sem nenhuma organização através de silos de dados, possivelmente
redundantes e não integrados. Após a implantação do MDM temos um
visual mais limpo sobre a distribuição e o consumo desses dados. O
barramento de serviços foi sinalizado como opcional, pois uma empresa
pode ou não adotar uma estratégia de distribuição dos dados via serviços.
Da forma como foi representada, a �gura abrange as duas opções.
Vale ressaltar que existem outras formas de arquiteturas de implementação
para utilização do MDM além da consolidação, utilizada na �gura anterior.
Essas formas serão mais bem detalhadas agora.
9.6. Estilos de arquiteturas de dados mestres
9.6.1. Pré-MDM
Embora pareça o contrário, Pré-MDM não é um estilo de arquitetura de
MDM. Representa um estágio em que as aplicações não estão integradas do
ponto de vista de uma gestão de dados mestres. Nele o grau de maturidade
em MDM é nulo e representa, de forma esquemática, o próprio problema
que um sistema de MDM busca resolver.
As aplicações do usuário têm como objetivo principal apoiar as atividades
necessárias aos processos de negócio da empresa. Este apoio é materializado
através da execução automatizada de transações. Do ponto de vista dos
dados e da sua persistência, as transações são relacionamentos com atributos
dos dados representados pelos dados mestres.
Os dados que participam das transações pertencem ao escopo particular
de uma aplicação e geralmente não são compartilhados (exceto quando são
replicados). A �gura a seguir demonstra um exemplo desse estágio.
Figura 9.5 – Estilo de implementação pré-MDM
A existência de um silo representa a falta da necessidade de
compartilhamento das transações que são propriedades de uma aplicação.
Mas para uma transação se realizar ela deve encontrar elementos prévios
sob os quais atua: os dados mestres e dados de referência. Estes podem
também ser propriedade de um determinado silo e não precisam se
submeter a um compartilhamento. Entretanto, existem dados mestres e
dados de referência que aparecem em aplicações de silos diversos com
estrutura, semântica e conteúdo iguais ou similares.
Esses dados, altamente compartilhados, estão associados a nomes e
conceitos críticos do negócio e atravessam um grande número de aplicações.
Esse compartilhamento conceitual não é governado do ponto de vista físico
do conteúdo de dados. Com isso, problemas típicos de qualidade dos dados,
tais como inconsistências e duplicação, começam a aparecer tanto no
ambiente de operações cotidianas do negócio como nas operações onde o
dado tem um peso estratégico.
Os silos de dados representam assim um atraso diante da necessidade de
integrar uma corporação.
9.6.2. Consolidação
A consolidação é formada por um repositório que armazena os dados
mestres e de referência que são importados via batch das várias fontes de
dados da empresa. Na consolidação, os dados são submetidos a processos de
transformação e Qualidade de Dados, de forma a prover os registros
dourados.
O sucesso da consolidação dos dados depende muito do número de fontes
de dados que alimenta o repositório de dados mestres e também da
necessidade da visão única dos dados. Os critérios de sobrevivência e
descarte dos dados duplicados, a padronização e o enriquecimento
contribuem para os resultados mais �dedignos nos ambientes de dados.
Uma solução de arquitetura puramente de consolidação, embora dando
uma maior qualidade aos dados mestres e dados de referência, não reverte
totalmente em uma maior qualidade no ambiente das fontes dos dados. O
saneamento dos geradores de erros reside nas aplicações e em seus silos de
dados.
A consolidação possui uma forte similaridade com os ODS (Operational
Data Store), já que um ODS é também um ponto de agregação e área de
staging para os sistemas de Data Warehousing. A distinção reside na
capacidade oferecida por um sistema de MDM que está além do
armazenamento e do gerenciamento fornecidos por um ODS.
Um ODS não oferece as facilidades de acesso, governança e serviços de
Gestão de Dados de negócio para gerenciar os dados mestres e apoiar os
gestores de dados de negócio na investigação e resolução de problemas
potenciais de Qualidade de Dados.
A principal vantagem da consolidaçãoé que este estilo de arquitetura é
uma fase “natural” para as fases iniciais de um programa de MDM. O foco
desta arquitetura são tanto as aplicações analíticas como as aplicações
operacionais.
Entre as desvantagens, a principal é o fato das soluções não oferecerem os
dados mais atuais, devido ao intervalo para transformação, sincronização e
qualidade dos dados. Geralmente este intervalo é de um dia. Ou seja, os
dados re�etem a realidade do dia anterior.
Outra desvantagem a ser considerada é o fato de que novas informações
devem constar nos sistemas fontes. Se for necessária a criação de um novo
atributo, por exemplo, o sistema fonte deverá ser alterado. A �gura a seguir
demonstra um exemplo do estilo de arquitetura da consolidação.
Figura 9.6 – Exemplo de arquitetura MDM – Consolidação
9.6.3. Registro
Registro é um estilo de arquitetura útil para fornecer uma fonte única de
leitura dos dados mestres, sem a necessidade de redundância de todos os
atributos desses dados. Este estilo contém um mínimo de informações
necessárias para identi�car exclusivamente os registros dos dados mestres.
Porém, fornece referências cruzadas para informações detalhadas, que são
geridas dentro de outros sistemas e bancos de dados.
O registro é capaz apenas de limpar e combinar informações de
identi�cação e assume que os sistemas de origem são capazes de gerenciar
adequadamente a qualidade dos seus próprios dados. Esta arquitetura
permite buscar dados de um mesmo conceito que são armazenados em
fontes diferentes de dados.
As consultas aos dados mestres são montadas de forma dinâmica. As
referências cruzadas são úteis para indicar em que bases locais os demais
atributos estão localizados. É feita, então, a recuperação dos demais
atributos a partir das referências. As consultas podem ser feitas tanto na
camada de banco de dados ou através de uma arquitetura de serviços. A
�gura a seguir demonstra um exemplo do estilo de arquitetura de registro.
Figura 9.7 – Exemplo de arquitetura – Registro
Esta arquitetura possui a vantagem de manter a maioria dos dados nos
sistemas fontes e não há intervalo mínimo de tempo para a consulta dos
dados. Ou seja, o dado consultado é real (atualizado).
Este estilo é adequado para uma rápida implementação em razão dos
dados continuarem nas bases locais e mantidos por elas. As aplicações locais
também não precisam ser modi�cadas para se tornarem sensíveis ao novo
ambiente de dados mestres. No caso de aquisições e fusões, este estilo
permite uma rápida integração dos dados sem que haja necessidade de
muitos acordos sobre os metadados (que são necessários cada vez mais nos
estilos seguintes).
Alguns problemas ocorrem com este estilo de implementação. Um dos
principais é que um tratamento mais poderoso da Qualidade de Dados não
é possível devido aos atributos localizados nas bases locais. Neste caso, o
máximo permitido é um trabalho nos atributos mínimos de identi�cação
que estão no repositório MDM.
Este estilo de implementação é mais sensível à disponibilidade e
performance dos sistemas fontes. Requer também uma forte prática de
governança distribuída, já que envolve consultas de outras aplicações e suas
bases de dados. Qualquer modi�cação nas fontes deve ser cuidadosamente
coordenada para evitar erros nas consultas subsequentes.
9.6.4. Coexistência
O estilo coexistência compõe-se de dados mestres que estão espalhados em
várias bases de dados de sistemas fontes e replicados no hub MDM. Os
dados mestres são consolidados e submetidos a processos de melhoria da
qualidade dos dados no repositório central do hub MDM da mesma forma
que no estilo consolidação. Os dados mestres, agora com qualidade, são
alimentados de volta para as bases fontes através de processos de
sincronização.
Este estilo participa de um sistema distribuído e serve de fonte certi�cada
para outras aplicações e sistemas. Como os dados mestres residem também
no repositório do hub MDM, a Qualidade de Dados pode ser tratada de
forma completa. Um ciclo de sincronização atendendo às restrições do
negócio resolve os con�itos, parte de forma automática e parte de forma
manual, através dos gestores de dados de negócio, enquanto mantém os
dados dentro de uma janela de tempo para a realização da consolidação.
Vale ressaltar que deve ser previsto um cuidado especial na sincronização
dos dados mestres para evitar atualizações cíclicas.
A coexistência proporciona um conjunto completo de dados mestres sem
fazer grandes alterações no ambiente existente. Além disso, a vantagem de
prover um conjunto completo de capacidades ao MDM favorece este estilo,
embora o fato de haver vários pontos onde os dados podem ser alterados
di�culte a manutenção da consistência.
Outra di�culdade encontrada é na implementação do sincronismo
bidirecional, em função da complexidade em fazer mapeamentos e outras
operações, inclusive com o uso de ferramentas de integração que lidam com
várias fontes de dados. A �gura a seguir demonstra um exemplo do estilo de
arquitetura de coexistência.
Figura 9.8 – Exemplo de Arquitetura MDM – Coexistência
9.6.5. Coexistência só de leitura
Este é um estilo de transição entre o modelo de coexistência e o
transacional. Muitas das características, pontos positivos e negativos são
similares ao estilo de coexistência. A retirada da capacidade das aplicações
de modi�carem os dados facilita a sincronização, que agora é unidirecional,
em direção às fontes.
Tanto as fontes de dados quanto o sistema de MDM podem sofrer leitura,
porém a atualização só ocorre no repositório central. A principal vantagem
desta arquitetura é que a implementação do sincronismo unidirecional é
mais simples do que o sincronismo bidirecional.
A �gura a seguir demonstra um exemplo do estilo de arquitetura de
coexistência (somente leitura).
Figura 9.9 – Exemplo de Arquitetura MDM – Coexistência (somente leitura)
9.6.6. Transacional
A arquitetura transacional é um estilo de implementação centralizada.
Todas as operações de criação, atualização e exclusão dos dados são
centralizadas exclusivamente no hub MDM.
A arquitetura transacional tem seu nome derivado do fato de que nesta
arquitetura o hub MDM se integra com a camada operacional de dados e
esta depende fortemente do hub MDM para efetuar suas transações. Um
requisito de robustez e disponibilidade, além dos de qualidade dos dados,
emerge imediatamente desse fato. O estilo de implementação num hub
MDM transacional centraliza um conjunto completo de dados mestres de
vários domínios.
A coleção completa de dados mestres de uma empresa �ca armazenada em
uma única fonte de dados (hub MDM), exceto os atributos não
compartilhados. Embora seja uma arquitetura aparentemente mais simples,
seu uso é mais complexo e custoso; porém, de forma geral, traz benefícios
pela maior facilidade de governança.
A �gura a seguir demonstra um exemplo do estilo de arquitetura
transacional.
Figura 9.10 – Exemplo de Arquitetura MDM – Transacional
9.7. Passos para implantar o MDM
Até o momento, já tomamos conhecimento dos principais conceitos sobre
dados mestres, dados de referência, a gestão desses dados, além das
abordagens de arquitetura que contemplam o MDM. Mas como é possível
implantar um MDM nas empresas? Quais passos comuns são necessários?
Os tópicos que se seguem fornecem uma visão geral de como pode ser feita
a implantação da Gestão de Dados mestres e dados de referência em uma
empresa.
1. Identi�car as fontes de dados mestres: esta etapa é, usualmente, um
exercício bastante revelador. Algumas empresas descobrem que
possuem dúzias de bancos de dados com dados de clientes cuja
existência o departamento de TI desconhecia.
2. Identi�car os produtores e os consumidores dos dados mestres:
Quais aplicativos utilizam os dados mestres? Dependendo da
abordagem utilizada na manutenção desses dados, esta etapa talvez não
seja necessária. Por exemplo, se todas as alterações forem detectadas e
tratadas no nível do banco de dados, provavelmente não terá
importância saber de onde vêm essas alterações.
3. Coletardeparamo-nos com um ambiente de negócios
dinâmico e multidisciplinar, que evoluiu muitas vezes mais, ou seja, as áreas
de tecnologia da informação estão muito mais bem preparadas do que no
passado, porém esse aumento da capacidade tecnológica é cada vez menor
se comparado com a evolução e dinamicidade dos ambientes de negócios
nas empresas.
Então o que podemos fazer? Temos de nos acomodar? Claro que não. Na
verdade, precisamos de mecanismos de gestão que reduzam essa diferença
entre a tecnologia e a agitação do ambiente de negócios.
Em relação ao uso dos dados e das informações, a área de Administração
de Dados tentou atuar no passado para reduzir essas diferenças, porém
vimos que muitas empresas não obtiveram o sucesso esperado,
principalmente em conseguir tratar e disseminar os dados efetivamente
como ativos em todas as organizações. Mas, a�nal, por que a área de
Administração de Dados do passado não conseguiu ser tão e�ciente quanto
o esperado?
Se observarmos com atenção o histórico da adoção e uso das áreas de
Administração e Gestão de Dados nas empresas brasileiras nas últimas
décadas, conseguiremos alcançar algumas respostas para as perguntas
elencadas nos primeiros parágrafos desta introdução.
No decorrer de cada década, os cenários de atuação das áreas de
Administração e Gestão de Dados mudaram radicalmente. Durante esse
tempo, erros dos mais diversos tipos foram cometidos. Um dos propósitos
deste livro é elencar esses erros e oferecer aos leitores alternativas para não
repeti-los em implantações futuras.
A �gura a seguir ilustra algumas particularidades, além do resumo da
atuação das áreas de Administração e Gestão de Dados em cada década,
desde o início da utilização do conceito “Administração de Dados” até os
dias atuais, onde o termo “Gestão de Dados” ganha mais força. A década de
2010 é tratada como uma época de redescoberta, onde a área de Gestão de
Dados reconhece os erros passados e, através da compreensão deles, busca
ressurgir nas empresas de forma mais ampla, simples e aderente às
necessidades e evoluções do negócio.
Figura 1 – Histórico da Gestão de Dados no Brasil – Visão do autor
Se olharmos com atenção a �gura anterior, iremos observar que as
mudanças dos cenários e de tecnologia foram bastante amplas. Os
comentários da linha do tempo a seguir detalharão o que ocorreu de
importante em cada uma das décadas.
Primeiro estágio – Boom! O conceito AD surge no mercado (anos 80) –
Os bancos de dados relacionais começaram a ser adotados nas empresas
ainda na plataforma alta (mainframes), em substituição aos sistemas de
arquivos e bancos de dados em rede e bancos de dados hierárquicos. Para
suportar as atividades decorrentes do uso dos SGBDRs1, consolidou-se no
mercado brasileiro o papel do DBA (Administrador de Banco de Dados).
Em um primeiro instante, o DBA geralmente acumulava as atividades de
administração do banco de dados e também, quando existentes, as
atividades de apoio e Modelagem de Dados. O volume de utilização e o grau
de complexidade das soluções que envolviam o uso de SGBDRs nessa época
não eram muito grandes, pois muitas aplicações e sistemas ainda eram
desenvolvidos e/ou mantidos com as tecnologias anteriores aos SGBDRs.
Em pouco tempo, veri�cou-se no mercado que o per�l DBA não era
su�ciente para suportar todas as tarefas relativas ao uso dos bancos de dados
nas organizações. Faltava um per�l mais genérico, ligado ao entendimento
dos requisitos de negócio e técnicas de análise. Surgia então o papel do AD –
Administrador de Dados.
Apesar de estarem diretamente ligados à mesma matéria-prima, o dado,
DBAs e ADs são per�s totalmente diferentes. O primeiro é mais focado em
questões físicas, ligadas ao armazenamento e desempenho das consultas
com os dados, preocupações necessárias para gerir toda a infraestrutura e
assegurar boa disponibilidade e desempenho dos dados. Já o segundo é um
per�l mais genérico, não tão técnico, ideal para traduzir requisitos de
informação e regras de negócio em modelos de dados.
No �m da década de 80, algumas grandes empresas saíram na frente e
criaram suas sessões/departamentos de Administração de Dados, todas
dentro da área de Informática.
A função AD era nova e, consequentemente, na época, não havia
pro�ssionais prontos no mercado. De forma geral, os pro�ssionais eram
selecionados e treinados dentro das próprias empresas. Na montagem das
equipes de Administração de Dados, geralmente eram escolhidos os
voluntários com grande experiência em análise de sistemas (pro�ssionais
sêniores) e conhecimento genérico das áreas de negócios da empresa.
Segundo estágio – Administração de Dados consolidada (anos 90) – A
adoção dos SGBDRs aumentou consideravelmente nas empresas devido ao
movimento de downsizing adotado por elas. O downsizing tinha o propósito
de migrar os sistemas e as aplicações da plataforma alta (mainframes) para a
plataforma baixa (micros).
Nessa década, o discurso dos dados como ativos importantes das
organizações já soava como algo inovador e poderoso, no sentido de obter
apoio nas altas esferas dos departamentos de Informática/TI. O termo
“Administração de Dados” de�nitivamente tinha entrado na moda. Várias
empresas criaram áreas de Administração de Dados baseadas no modelo de
trabalho de organizações que foram pioneiras no uso da AD no �m da
década de 80.
O surgimento das primeiras ferramentas de modelagem no mercado,
aliado à consolidação de sistemas gerenciadores de bancos de dados para
plataforma baixa, facilitou a implantação da área de Administração de
Dados.
O modelo de trabalho da Administração de Dados, nessa época, era
formado principalmente pela tríade dos grupos de atividades: Modelagem
de Dados, Administração de Banco de Dados e Gestão de Modelos de
Dados. A quase totalidade das áreas de AD implantadas era subordinada aos
departamentos de Informática/TI. Além disso, em muitas empresas, a
função não era considerada estratégica, mas sim tática.
Por outro lado, a partir dessa época, começamos a vivenciar com rapidez a
evolução das tecnologias. Na própria década de 90 foram adotadas
mudanças radicais em relação à forma de desenvolver soware. Sistemas
eram projetados/especi�cados segundo os paradigmas da análise
estruturada, logo depois, a análise essencial e, já no �nal desta década, a
orientação a objetos (UML2) começou a ser adotada com maior ênfase. O
modelo de Administração de Dados herdado da época anterior começava a
não conseguir acompanhar o ritmo que era imposto pela evolução
tecnológica.
Terceiro estágio – Declínio da AD (anos 2000) – Esta época foi marcada
pelo declínio da Administração de Dados nas empresas. O ritmo da
evolução tecnológica, que já era forte na década passada, aumentou ainda
mais nesta década, porém o ritmo de capacitação dos Administradores de
Dados não era o mesmo. Era bastante comum, na época, encontrar
pro�ssionais de Administração de Dados que não sabiam, por exemplo,
conceitos de orientação a objeto e formas de consumo dos dados além das
tradicionais consultas de dados via SQL.
Na expectativa de reduzir seus custos sem perder e�ciência operacional, as
empresas começaram a intensi�car o movimento de terceirização de pessoal,
já iniciado na década passada, das suas gerências e departamentos de TI.
Vários departamentos foram extintos, dando lugar a contratos de prestação
de serviços especí�cos ou simples contratos de alocação de mão de obra,
onde, na prática, vários pro�ssionais eram demitidos e voltavam às suas
empresas de origem como consultores externos. Ao contrário do que era
imaginado na época, este movimento resultou em um expressivo aumento
dos postos de trabalho. Em muitos casos, a gestão do pessoal �cava por
conta das consultorias, que, apesar de estarem preocupadas com a e�ciência
da prestação de seus serviços, também estavam preocupadas com o seu
próprio faturamento. En�m, a quantidade de Administradores de Dados
formados e quali�cados no mercado era insu�ciente para suprir todas as
demandas e vagas necessárias.
Com isso, as consultorias começarame analisar os metadados dos dados mestres: para todas as
fontes identi�cadas na primeira etapa, quais são as entidades e os
atributos dos dados e o que eles signi�cam? Geralmente incluem-se os
nomes dos atributos, os tipos de dados, os valores aceitos, as restrições,
os valores padrão, as dependências e os proprietários das de�nições e
manutenções dos dados. O proprietário é o mais importante e, quase
sempre, o mais difícil de determinar. Se houver um repositório
carregado com todos os metadados, esta etapa será de fácil execução.
Se, entretanto, for preciso começar com base nas tabelas do banco de
dados e no código-fonte, esta etapa poderá representar um esforço
bastante signi�cativo.
4. Indicar os gestores de dados de negócio: deverão ser pessoas com
profundos conhecimentos sobre os dados atuais e também capazes de
determinar como transformar as fontes para os formatos de dados
mestres. Os gestores de dados de negócio deverão ser indicados pelos
proprietários de cada fonte de dados mestres.
5. Implementar um programa de governança dos dados para os dados
mestres: a governança dos dados é fundamental para manter e obter
conhecimento e autoridade para tomar decisões sobre como os dados
mestres devem ser mantidos, por quanto tempo serão gerenciados e
como as alterações serão autorizadas e auditadas.
6. De�nir a arquitetura de MDM: este passo deve ser dado antes da
construção do modelo de dados mestres. Dependendo da arquitetura
adotada, haverá in�uência na construção dos modelos físicos do
MDM.
7. Desenvolver o modelo de dados mestres: este passo de�ne quais
informações dos dados mestres serão incluídos, de que porte e tipo são
os dados, quais valores são aceitos, quais os relacionamentos entre os
dados mestres e dados de referência, etc. Esta etapa deve incluir
também o mapeamento entre o modelo de dados mestres e as atuais
fontes de dados. Normalmente esta é a etapa mais importante e a mais
difícil do processo.
8. Escolher um conjunto de ferramentas: geralmente será preciso
comprar ou construir ferramentas para gerir os dados mestres:
limpando, transformando e mesclando os dados-fonte. Além disso, será
preciso uma sólida infraestrutura para utilizar e manter esses dados.
Pode ser utilizado um único conjunto de ferramentas, de um mesmo
fornecedor, para todas essas funções, ou talvez adotar outra abordagem
tipo: “melhor ferramenta para cada função”. O conjunto de ferramentas
deve ter ainda suporte para localização e reparo de problemas com a
qualidade dos dados e também manutenção de versões. O controle de
versões é um recurso crítico, pois entender o histórico de um registro
de dados mestre é vital para a manutenção de sua qualidade e precisão
no decorrer do tempo.
9. Projetar a infraestrutura: depois dos dados mestres estarem limpos e
consistentes, será necessário colocá-los à disposição de seus aplicativos
e providenciar processos para a sua administração e manutenção.
10. Gerar e testar os dados mestres: é nesta etapa que serão utilizadas as
ferramentas desenvolvidas ou compradas para gerir os dados mestres.
Em geral, este é um processo iterativo que exige explorar regras e
con�gurações para chegar a correspondências corretas. Este processo
também exige grande volume de veri�cações manuais para con�rmar
se os resultados estão corretos e também se atendem aos requisitos
estabelecidos.
11. Modi�car os sistemas de produção e de consumo: dependendo de
como a implementação do MDM estiver projetada, provavelmente será
preciso modi�car os sistemas que produzem, mantêm ou consomem os
dados mestres para trabalharem com as novas fontes de dados.
12. Implementar os processos de manutenção dos dados mestres:
qualquer implementação de MDM deve incorporar ferramentas,
processos e pessoas para manter a qualidade dos dados. Todos os dados
mestres devem ter um gestor, que será responsável por garantir a sua
qualidade. Em geral, o gestor de dados de negócio é uma pessoa que
trabalha dentro do negócio, com conhecimento dos dados, que tem
condições de reconhecer dados incorretos e tem conhecimento e
autoridade para corrigir as falhas.
10. Qualidade de Dados
“A qualidade é a quantidade de amanhã.”
Henri Bergson
10.1. O que é Qualidade de Dados?
Podemos a�rmar que os dados possuem qualidade quando eles satisfazem
os requerimentos para os quais foram criados. Isso implica que a Qualidade
de Dados é sempre de�nida sobre a visão de negócio da empresa.
A conquista desta qualidade é realizada através dos processos de Qualidade
de Dados que buscam garantir que os dados armazenados sejam corretos,
precisos, consistentes, completos, integrados, aderentes às regras de negócio
e aderentes aos domínios estabelecidos.
Tal como a Governança de Dados, a Qualidade de Dados também envolve
esforços integrados através de pessoas, processos e tecnologia com o
propósito de gerar valor para a organização a partir dos dados armazenados.
Conforme �gura a seguir, a Qualidade de Dados pode ser dividida em três
grandes grupos. São eles:
Qualidade dos metadados.
Qualidade do conteúdo dos dados.
Qualidade dos processos de Gestão de Dados.
Figura 10.1 – Grupos de Qualidade de Dados
A qualidade dos metadados é executada quando os gestores de dados
(técnicos e de negócio) atuam nos processos onde os metadados são criados,
veri�cados e manipulados. Muitos desses processos ocorrem antes das
estruturas de dados serem promovidas para o ambiente de dados em
produção. Entre os processos mais comuns podemos destacar: processos
ligados à Modelagem de Dados e avaliações da qualidade dos modelos de
dados.
Apesar de conceitualmente ser diferente, a qualidade dos metadados
in�uencia diretamente a qualidade dos dados (conteúdo).
A qualidade do conteúdo é aplicada em cima dos dados que são utilizados
já no ambiente de produção ou estão próximos a serem promovidos, através
de técnicas especí�cas que buscam identi�car e corrigir os dados de baixa
qualidade.
A qualidade dos processos monitora todos os processos de Gestão de
Dados, e não somente os processos de Qualidade de Dados, e busca a
tomada de ações de melhoria contínua em cima das métricas e dos
indicadores dos processos controlados.
De forma equivocada, a Qualidade de Dados por muitos ainda é
considerada uma função não proativa, contemplada apenas pela qualidade
do conteúdo dos dados e dedicada somente à identi�cação dos dados sujos e
suas correções. Entretanto, a Qualidade de Dados não se resume apenas à
veri�cação e à correção desses dados, mas também ao planejamento, à
garantia e às ações de melhoria contínua que podem ser aplicadas em seus
processos. Deming, um dos principais papas da qualidade, já dizia: “A
qualidade é planejada e não inspecionada”.
Para poder exempli�car esta a�rmação, também atuamos na Qualidade de
Dados quando:
Utilizamos uma Arquitetura de Dados e de�nimos as prioridades das
ações em cima das entidades de dados representadas nesta arquitetura.
Esta ação permite um planejamento e�caz não só da qualidade, mas de
todas as demais necessidades desses dados.
Atuamos de forma proativa na orientação e construção dos modelos de
dados e demais metadados da empresa. Esta ação permite uma melhor
garantia da qualidade na construção desses artefatos.
Atuamos na veri�cação dos modelos de dados e demais metadados
produzidos na empresa. Esta ação permite um melhor controle sobre as
estruturas de dados antes destas entrarem no ambiente produtivo.
A�nal, sem metadados de qualidade, o que poderemos esperar dos
dados armazenados nessas estruturas?
Promovemos campanhas direcionadas sobre Qualidade de Dados,
tanto dentro do ambiente de TI quanto dentro do ambiente de negócio.
A�nal, não adianta uma empresa possuir estruturas de dados de
excelência e processos de Qualidade de Dados bem estruturados se as
pessoas que criam os dados nas aplicações não entendem a importância
de ter dados corretos e reais e incluem dados sujos dentro das bases de
dados da empresa.
O conteúdo deste capítulo é dedicado à qualidade do conteúdo dos dados,
mas vale destacar que a qualidadedos metadados, representados pelos
modelos de dados, foi abordada no capítulo de Modelagem de Dados.
10.2. Dados de baixa qualidade – Dados sujos
As consequências do uso de dados de baixa qualidade podem ser
observadas no nosso cotidiano, porém, muitas vezes, não temos o
entendimento necessário para saber as reais causas. Por exemplo, o atraso ou
a entrega em um endereço incorreto de uma correspondência de cobrança é
muitas vezes atribuído ao serviço de entrega, mas outras causas podem ser a
razão do problema: erros de digitação no cadastro, erros de sistema, erros na
carga e/ou transformação dos dados, entre outros.
Dados sujos geram uma série de problemas, desde pequenos
inconvenientes até grandes perdas �nanceiras, devido a cálculos de dados
sem qualidade, gerando grandes prejuízos e também multas e processos
judiciais decorrentes do uso de dados sem qualidade.
De forma geral, as principais causas da qualidade ruim de dados dividem-
se em quatro grandes grupos: Grupo 1 – Aspectos técnicos:
Erros cometidos em todas as etapas de um processo de armazenagem
dos dados. Desde a concepção, passando pela implantação, até o seu
efetivo uso.
Falta de processos e ferramentas para aferir e tratar a qualidade dos
dados.
Grupo 2 – Aspectos humanos:
Erros não intencionais na entrada de dados.
Falta de entendimento.
Pouco treinamento.
Entrada de dados incorreta feita de forma intencional ou maliciosa.
Processos de análises, coleta de dados e resolução de problemas
precariamente de�nidos ou inexistentes.
Entrada de dados em múltiplos níveis.
Grupo 3 – Fatores Organizacionais:
Integração de base de dados em fusões e aquisições de empresas.
Desintegração de bases de dados.
Dispersão de bases dados ao longo de diferentes departamentos ou
empresas de um grupo.
Falta de conscientização sobre a importância da qualidade dos dados.
Base de dados legadas sem controle.
Grupo 4 – Negligência Corporativa:
Desconhecimento do valor em melhorar a Qualidade de Dados até que
os problemas são descobertos.
Não há percepção de que uma melhor Qualidade de Dados é
necessária.
Medo de demonstrar as fraquezas existentes em TI e expor a empresa.
Falta de uma visão clara de quem é o responsável e quem se bene�cia
com a qualidade dos dados.
Falta de disseminação do conhecimento, de treinamento e participação
do corpo técnico e gerencial no assunto.
10.3. Processo de Qualidade de Dados
(conteúdo)
Atualmente existem vários processos e soluções de Qualidade de Dados
propostos por diversas empresas fabricantes de soluções de Data Quality e
também propostos por autores de respeito.
O macroprocesso abordado neste livro procura demonstrar uma forma
simples de estabelecer a Qualidade de Dados com o foco no conteúdo dos
dados, através de atividades comuns identi�cadas na maioria dos processos
existentes. Vale ressaltar que, dependendo das características
organizacionais de uma empresa, o macroprocesso proposto a seguir pode
ser incrementado com mais atividades e/ou processos. Entretanto, os seis
processos mencionados no macroprocesso a seguir são considerados
obrigatórios. Os processos podem ser renomeados ou até mesmo divididos
em mais processos, porém a essência de suas atividades deve ser mantida, ou
seja, não devem ser ignorados em nenhuma implantação de Qualidade de
Dados nas empresas.
O macroprocesso proposto neste livro é representado na �gura a seguir.
Figura 10.2 – Processos de Qualidade de Dados
O macroprocesso se caracteriza pela sequência de cinco processos
fundamentais: Promover a Qualidade dos Dados, De�nir Requisitos e
Questões da Qualidade, Per�lar Dados, Analisar Dados e Limpar e Corrigir
Dados. Todos os cinco processos são acompanhados através de um processo
dedicado à Garantia da Qualidade dos Dados e Modelos de Dados.
Os processos de qualidade dos modelos de dados também não devem ser
esquecidos – por esta razão foram representados na �gura. A qualidade dos
modelos de dados já foi abordada em capítulos anteriores. Neste capítulo
trataremos da qualidade do conteúdo dos dados.
10.3.1. Promover a Qualidade dos Dados
São os processos dedicados a promover a importância da Qualidade de
Dados nas empresas. Esta promoção geralmente é feita através da
capacitação e conscientização dos envolvidos através de palestras, workshops
e treinamentos focados em qualidade. Outra forma comum de efetivar a
promoção é através da divulgação de exemplos de qualidade baixa de dados
que podem gerar efeitos negativos para a empresa. Se possível, deve-se
evidenciar problemas reais que comprometam os negócios, questões de
regulamentação e até mesmo a imagem da empresa.
Esta fase é fundamental para angariar novos patrocinadores e aliados para
a dura jornada que virá nos processos seguintes.
Os envolvidos devem tomar ciência nesta fase de que nem sempre o
problema da qualidade baixa de dados é proporcionado e/ou gerido pela
própria TI da empresa. Os gestores de dados devem conscientizar os
envolvidos em um dos principais princípios da Gestão de Dados, que é a
responsabilidade compartilhada pelos dados.
Muitos projetos de Qualidade de Dados não seguem adiante devido à
di�culdade em se levantar o retorno sobre o investimento da iniciativa. Este
retorno só é possível mensurar com certa precisão se os dados de má
qualidade (dados sujos) e os problemas decorrentes ao seu uso já são
conhecidos.
De qualquer forma, se não é possível obter os dados reais sobre a baixa
qualidade dos dados, provavelmente a empresa ainda não adquiriu uma
ferramenta para apoiar os processos de Qualidade de Dados. Uma boa
alternativa neste caso é escolher e segregar um pequeno conjunto de dados,
corporativos, aparentemente com baixa qualidade, e avaliá-los com o apoio
de uma ferramenta em um processo de prova de conceitos (POC). É
bastante comum os fornecedores oferecerem recursos temporários e
limitados para testar suas ferramentas antes de uma possível compra.
10.3.2. Definir requisitos e questões da qualidade
Processo que de�ne os requisitos de Qualidade de Dados que irão
possibilitar avaliações padrão e geração dos indicadores sobre a qualidade
dos dados. Os requisitos de qualidade são determinados levando em conta
as necessidades da empresa.
O DAMA-DMBOK® estabelece alguns requisitos comuns para a qualidade
dos dados. São eles:
Acurácia: determina se as entidades da vida real estão representadas
corretamente nos dados.
Completude: determina se os dados estão completos de acordo com as
informações exigidas na execução dos processos de negócio.
Consistência: determina se os dados estão íntegros e coerentes. A
veri�cação é feita através do cruzamento entre duas ou mais fontes de
dados.
Atualidade: determina o quanto os dados estão atualizados e
representam verdadeiramente o estado atual das informações.
Precisão: determina se os dados representam o grau de precisão
necessário, como casas decimais, por exemplo.
Privacidade: indica que o dado ou metadado é conhecido e está
disponível, no momento necessário, para quem tem o devido acesso.
Envolve conceitos de governança e segurança dos dados e informações.
Razoabilidade: considera como relevante a consistência de
expectativas dentro de um contexto operacional. Exemplo: número
estimado de transações por dia dentro dos limites estabelecidos.
Integridade referencial: indica que o dado atende a todas as restrições
de integridade necessárias para que possa ser considerado um dado
con�ável. As restrições de integridade permitem a representação das
regras de negócio, que, se não forem respeitadas, irão prejudicar a
con�abilidade dos dados.
Unicidade: indica que o dado é único e exclusivo dentro da empresa.
Não há repetição de conteúdo e conceitos. Ou seja, não existem outros
dados iguais. Quando esta dimensão é violada, ocorre a redundância.
Validade: garante que todos os valores de dados estão em
conformidade com os atributos associados aos elementos de dados:
tipo, precisão, padrão de formato, valores prede�nidos, entre outros.
Os requisitos de qualidade podem possuir várias dimensões,que variam de
acordo com fontes e autores. Outras dimensões bastante comuns e
mencionadas por outros autores são:
Aderência ao negócio: indica que o dado ou metadado está aderente
em sua totalidade (por completo) aos requisitos de informação e regras
de negócio da empresa.
Con�abilidade: indica que o dado é atual, correto (sem erros) e pode
ser utilizado sem afetar negativamente qualquer tipo de uso. Não
existem erros de transformação, disponibilização e até mesmo de
digitação.
Manutenibilidade: indica baixo esforço na manutenção dos dados
quando há uma solicitação de mudança que irá afetar os dados.
Metadados especi�cados em modelos de dados de forma �exível
costumam ter baixo custo de manutenção – em alguns casos,
dependendo da mudança, o esforço é feito somente nas aplicações, sem
necessidade de alteração no modelo de dados ou dados das aplicações.
Performance: indica que o tempo de resposta e acesso aos dados são
satisfatórios para os requisitos de uso.
Legibilidade: fácil entendimento, compreensão e utilização dos dados,
gerando outros dados de qualidade.
A seleção dos requisitos de qualidade são fundamentais para de�nir as
questões que serão aplicadas nos processos de Qualidade de Dados.
As de�nições das questões representam quais críticas deverão ser
levantadas nos dados armazenados. De forma geral, é feita uma lista padrão
com as questões relacionadas que podem ser aplicadas tanto no conteúdo
quanto na estrutura dos dados. Na de�nição dessas questões, podemos
atribuir pesos aos impactos que elas causam. Algumas questões são mais
críticas que as outras, e por esta razão devemos estabelecer pesos e medir os
impactos da má qualidade dos dados.
Entre as críticas mais comuns, podemos encontrar: erros no formato,
constantes, dados inconsistentes, inconsistência de tipo de dado, regras de
nulos inconsistentes, chaves inválidas, valores inválidos, valores não
preenchidos, �lhos órfãos, valores fora da faixa, exceções de padrões,
constantes potenciais, valores potenciais, duplicatas potenciais, inválidos
potenciais, valores potenciais redundantes, campos não usados e regras para
exceções.
10.3.3. Perfilar dados – Data profiling
O processo de Per�lar Dados, também conhecido como Data Profiling, faz
uso de técnicas analíticas sobre os dados com o propósito de desenvolver o
conhecimento sobre seu conteúdo, estrutura e qualidade. Em suma, esta
per�lagem é uma espécie de exame (diagnóstico) a respeito da qualidade
dos dados existentes.
Vale ressaltar que este é um processo dedicado a desenvolver informações
sobre os dados, ao invés de informações a partir dos dados. Os exemplos a
seguir ajudam a entender essas diferenças: Exemplos de informações
SOBRE os dados (Data Profiling):
30% das entradas de dados na coluna CD_FORNECEDOR estão
marcadas com o caractere “espaço”.
A faixa de valores do campo PRECO_UNITARIO_SERVICO vai de
100,99 a 4599,99.
Existem 140 linhas contendo PEDIDOS sem linhas contendo os seus
DETALHES.
Exemplos de informações A PARTIR dos dados: (NÃO é Data Profiling):
As lojas do Rio de Janeiro vendem mais itens congelados do que as
lojas das demais regiões.
O valor médio das vendas cresceu 6% este ano.
10% dos clientes que compraram produtos no ano passado não
compraram produtos este ano.
Durante o processo de Data Profiling, algumas etapas complementares são
executadas, como: coleta da documentação a respeito dos dados, avaliação
dos dados e. por �m, a comparação dos dados com a documentação. Neste
ponto é comum ocorrerem questões onde o gestor técnico de dados apontou
a necessidade de cuidados adicionais para garantir a integridade dos dados,
porém esses cuidados não foram feitos, apenas representados através de
observações e/ou ressalvas nos modelos de dados.
10.3.4. Analisar dados
Esta fase é concentrada na avaliação dos dados através das métricas e
também das principais regras de negócio que podem acarretar em possíveis
quebras de conformidade. As prioridades estabelecidas na etapa de de�nição
dos requisitos de dados podem ser revistas neste ponto, levando-se em conta
o volume de dados incorretos encontrados durante a execução da per�lagem
dos dados.
As métricas devem representar medidas de�nidas com clareza, através de
elementos quanti�cáveis e associados aos objetivos do negócio, com
determinações claras sobre como medir e analisar os dados, estabelecer as
faixas de valores aceitáveis, além de estabelecer planos de ação, quando
aplicável.
As regras de negócio devem ser observadas na sua qualidade para garantir
sua aderência aos processos de negócio ou, até mesmo, em situações pouco
comuns, para identi�car novas regras, não previstas na aplicação, porém já
contempladas nos dados.
Dependendo do volume de dados de baixa qualidade, a análise dos dados
também pode servir de instrumento para de�nir prioridades na sua
correção.
10.3.5. Limpar e corrigir dados – Data cleansing
Também conhecido como Data Cleansing, este é um processo de
atualização e correção dos dados, garantindo a consistência das
informações. Através de ferramentas e aplicação de regras, os dados são
corrigidos.
O Data Cleansing caracteriza-se por estimar os problemas e aplicar as
regras para sua correção. Limpar dados resolve problemas momentâneos,
fazendo com que as informações errôneas sejam corrigidas, porém não evita
a recorrência de novos problemas.
Caberá à equipe de Qualidade de Dados o tratamento para que novas
ocorrências para os mesmos problemas não voltem a surgir. Este fato reforça
a tese de que a Qualidade de Dados deve fazer parte da cultura da empresa e
ser tratada como um processo contínuo e não como um projeto sob o risco
dos mesmos problemas voltarem novamente nas próximas rodadas do
processo.
A correção dos dados pode ser feita de forma manual ou de forma
automática. A forma automática é feita com o apoio de ferramentas e utiliza
técnicas de limpeza e transformação dos dados. Entre as mais conhecidas
estão a deduplicação e as regras de padronização de conteúdo.
A deduplicação é a técnica que identi�ca registros duplicados em uma base
de dados. Esses registros podem ser eliminados ou apenas marcados para
controle e futura eliminação. A deduplicação prevê a utilização de diversas
variáveis que acabam compondo as chaves primárias ou secundárias para
identi�cação dos registros.
Já as regras de padronização são formadas através da análise sintática e da
análise de referência normalizando campos padronizáveis. Um bom
exemplo é um padronizador de endereços que corrige os endereços de um
grupo de dados. Vale ressaltar que ambientes com padrões bem de�nidos
aceitam regras e padrões de erros conhecidos com mais facilidade.
Já a correção manual é indicada para pequenos volumes de dados e
geralmente é feita pelos próprios gestores de dados de negócio, que
inspecionam os registros inválidos e determinam os valores corretos para
fazer as correções e aplicar a atualização dos registros.
10.3.6. Garantia da Qualidade dos Dados e Metadados
A Garantia da Qualidade dos Dados e Metadados é executada através dos
registros diários das atividades, onde os valores e métricas são
transformados em indicadores e logo após são submetidos a avaliações
periódicas a �m de obter melhorias nos seus processos.
Entre os indicadores mais comuns desses processos podemos destacar os
indicadores referentes à qualidade dos modelos de dados, ao reuso dos
dados e metadados, ao índice de chamados de correção de dados (via
usuários das aplicações) e ao índice de identi�cação e correção dos dados.
Cabe aos gestores de dados (técnicos e de negócio) fazer a pré-avaliação
desses indicadores, propondo ações que serão sugeridas nas reuniões de
análise crítica. Muitas dessas ações são obtidas através da aplicação das
ferramentas comuns de qualidade do processo, tais como: diagramas de
Pareto, diagramas de causa e efeito, histogramas, �uxogramas, grá�cos de
controle, etc.
As reuniões de análise crítica são periódicas, muitas vezes estabelecidas em
um comitê ou comissão para tratar especi�camente da qualidadedos dados
e metadados. Ao �m de cada reunião, são estabelecidas ações para a
melhoria dos processos.
Este é o conceito da melhoria contínua: monitorar a qualidade dos dados e
tomar ações para aprimorar os processos de negócio, os processos de Gestão
de Dados e a qualidade dos dados.
10.4. Considerações finais sobre a Qualidade de
Dados
Qualidade de Dados ainda é uma função pouco praticada nas empresas
brasileiras. Muitas pessoas ainda confundem Qualidade de Dados com
processos de veri�cação e correção dos dados e metadados, entretanto, a
Qualidade de Dados possui um conceito muito mais amplo, iniciando pelas
atividades de planejamento e tendo todas as fases registradas e monitoradas
com o propósito de estabelecer uma melhoria contínua tanto dos processos
quanto da qualidade dos dados.
Entre os principais conceitos e boas práticas que foram mencionados neste
capítulo, podemos destacar:
A qualidade dos dados engloba três grandes conceitos: a qualidade dos
metadados, a qualidade dos dados e a qualidade dos processos de
Gestão de Dados.
Qualidade de Dados não é somente inspeção; ela engloba outras fases,
como o planejamento e a melhoria contínua.
A Qualidade de Dados deve ser encarada como um processo constante
dentro de uma empresa, e não como um simples projeto.
Dados de má qualidade são considerados “dados sujos” e causam danos
ao negócio e à reputação das empresas.
Os requisitos de qualidade são muitos e variam a cada fonte/autor.
Cabe a cada empresa de�nir os seus requisitos levando em conta suas
características e o retorno para o negócio.
O mesmo vale para os processos de Qualidade de Dados. Devem ser
estabelecidos de acordo com as características das empresas. De
qualquer forma, existem processos comuns que são adotados em
qualquer programa de Qualidade de Dados. São eles: Promover a
Qualidade dos Dados, De�nir Requisitos e Questões da Qualidade,
Per�lar Dados, Analisar Dados, Limpar e Corrigir dados e Garantia da
Qualidade dos Dados e Metadados.
As correções devem ser aplicadas nas fontes originais sempre que
possível.
Parte 3
Gestão de Dados Moderna
11. Gestão de Dados Moderna
“Pense como um homem de ação e atue como um homem de
pensamento.”
Henri Bergson
11.1. Visão geral da Gestão de Dados Moderna
A Gestão de Dados Moderna não é um framework e nem uma
metodologia. Ela é apenas uma �loso�a de trabalho mais proativa, focada na
conduta comportamental dos pro�ssionais que atuam na área.
Tal como as premissas de responsabilidade compartilhada entre as áreas de
TI e negócio, a Gestão de Dados Moderna também sugere a busca de uma
visão mais abrangente das áreas de negócio das empresas pelos pro�ssionais
de Gestão de Dados. Essa visão não seria mais focada somente em bancos de
dados e tecnologia da informação, e sim no alinhamento da tecnologia ao
negócio.
Seu surgimento se fez necessário principalmente para acompanhar as
novas tendências tecnológicas que envolvem a manipulação e o uso dos
dados e também novas características de trabalho, tais como:
Distribuição do trabalho em várias frentes, onde algumas equipes estão
distribuídas em diferentes localizações geográ�cas. Em alguns casos,
até em países diferentes.
Métodos de desenvolvimento ágil de aplicações, onde o tempo de
resposta às solicitações deve ser muito rápido.
O envolvimento e o comprometimento das equipes de Gestão de Dados
com os objetivos e as metas das demais equipes envolvidas são fundamentais
para ambas manterem uma boa harmonia e consequentemente atuarem
juntas na busca de propósitos em comum, tais como: participação mais
efetiva dos clientes nos projetos, desenvolvimento da equipe, agilidade nas
respostas às solicitações/mudanças e melhoria contínua.
Desta forma, as equipes de Gestão de Dados conseguem acompanhar a
adoção de novos paradigmas e tecnologias que vêm surgindo ultimamente e
também acompanhar as necessidades de mudanças nos requisitos e nas
regras de negócios adotadas pelas empresas.
Conforme �gura a seguir, a Gestão de Dados Moderna é formada por um
quadro com três grandes conceitos: Estrutura da Gestão de Dados, Pilares
das Organizações e Conduta.
Figura 11.1 – Visão geral da Gestão de Dados Moderna
A Estrutura da Gestão de Dados é composta por conceitos bastante
comuns nas organizações que possuem equipes de Gestão de Dados em
atividade, inclusive as equipes de Administração de Dados tradicionais. Os
conceitos são tão comuns que podem ser considerados pré-requisitos para a
adoção de uma área de Gestão de Dados em qualquer empresa.
11.2. Estrutura da Gestão de Dados
A estrutura central da Gestão de Dados Moderna é formada pela região
dos retângulos centrais: o corpo técnico e as ferramentas.
Áreas formadas somente por este conjunto de atuação são conhecidas
como áreas de Administração de Dados ou Gestão de Dados Tradicional.
Grande parte dos produtos gerados e/ou manipulados pelas equipes de
Gestão de Dados está concentrada nesta região.
A parte central deste conjunto demonstra que, em maior ou menor nível
de maturidade, as áreas de Gestão de Dados têm seus principais focos
voltados para a qualidade e a governança dos metadados, possuem
metodologias de�nidas, estão (ou pretendem estar) alinhadas com os
objetivos estratégicos das organizações, além de terem iniciativas ou
domínio completo da governança dos dados e metadados de suas
organizações. A este conjunto de práticas, localizadas na parte central do
quadro, chamamos de Estrutura Central da Gestão de Dados.
As principais diferenças entre a antiga Administração de Dados e a Gestão
de Dados Moderna são muitas, porém se baseiam apenas em mudanças de
atitude e visão dos pro�ssionais. Na verdade, o que difere a Gestão de Dados
Moderna da Gestão de Dados Tradicional são os conceitos da Conduta e
Pilares das Organizações.
Os retângulos centrais (Metodologia, Alinhamento Estratégico, Qualidade
e Governança de Dados) correspondem aos grupos de processos,
documentos e diretrizes que são seguidos pelo corpo técnico de
pro�ssionais, com o apoio de ferramentas.
11.2.1. Corpo Técnico
O Corpo Técnico de pro�ssionais corresponde às pessoas envolvidas nas
atividades de Gestão de Dados. Incluem-se aqui as pessoas lotadas em
equipes de Gestão de Dados, tais como: gestores de dados (técnicos e de
negócio), gestores estratégicos de dados, administradores de repositórios de
metadados e DBAs, responsáveis por planejar e executar as práticas
estabelecidas na estrutura central do quadro, além de pessoas de outras
equipes que possuem alguma relação (mesmo que indireta) com as
atividades. Por exemplo: pro�ssionais de infraestrutura, pro�ssionais das
equipes de desenvolvimento, gerentes, coordenadores, etc.
Vale ressaltar que a capacitação e a experiência do Corpo Técnico são
fundamentais para o sucesso desta �loso�a.
11.2.2. Ferramentas
As ferramentas correspondem aos sowares e às soluções de hardware
utilizados para apoiar todas as atividades executadas pela área de Gestão de
Dados.
Entre os grupos de ferramentas mais utilizados podemos destacar: sistemas
gerenciadores de banco de dados, ferramentas de modelagem, repositórios
de modelos de dados, repositórios de metadados, ferramentas de Qualidade
de Dados, ferramentas para Gestão de Dados mestres e dados de referência,
ferramentas para ETL, repositórios de ativos, além de ferramentas
customizadas para apoiar os processos e indicadores utilizados pelas equipes
de Gestão de Dados.
O trabalho de estruturação da Gestão de Dados nas empresas não deve ser
feito exclusivamente em função das ferramentas adotadas. O ideal é
estruturar a forma de trabalho e depois selecionar ferramentas que melhor
se adequem à forma de trabalho de�nida.
11.2.3. Metodologia
Metodologia é um conjunto de documentos que orientam os pro�ssionais
envolvidos com as funções e atividades preconizadas pela disciplina de
Gestão de Dados na empresa.
A metodologia descreve as regras do jogo de�nidas nas atividades de
Governança de Dados. Além disso, recomenda-se que a metodologia tenha
caráter normativo (o que fazer?O que entregar?) e também voltado à
orientação dos envolvidos (como fazer? Como entregar?).
Entre os documentos de uma metodologia, geralmente encontramos:
documentação institucional, processos e seus detalhamentos, padrões, boas
práticas, templates de laudos e relatórios, ferramentas de qualidade,
documentação de apoio e ferramentas de comunicação.
11.2.4. Qualidade
Qualidade corresponde à execução dos métodos de controle e garantia
utilizados para manter as estruturas de dados e o conteúdo dos dados
aderentes aos graus de qualidade preestabelecidos. Esses critérios são
encontrados na metodologia de Gestão de Dados vigente.
Este retângulo abrange tanto a qualidade dos metadados (estruturas de
dados) quanto a qualidade dos dados (conteúdo) e, dependendo da
maturidade da empresa, a qualidade do processo de Gestão de Dados
(planejamento, ação, controle e melhoria contínua).
11.2.5. Alinhamento estratégico
Corresponde à ligação entre planejamento estratégico de negócio e
planejamento estratégico de TI. Corresponde ao grau no qual a missão, os
objetivos e planos re�etem e são suportados pela missão, pelos objetivos e
pelos planos de negócio e vice-versa. Seria, no caso, a clássica relação entre
as fases de elaboração e implementação da estratégia corporativa.
A adoção do alinhamento estratégico entre a Gestão de Dados e as áreas de
negócio e TI permite que cada integrante da força de trabalho da Gestão de
Dados saiba exatamente qual é o seu papel dentro da empresa e em que
direção cada uma de suas ações deve ser guiada, para que os objetivos
individuais representem e ajudem na conquista dos objetivos
organizacionais.
11.2.6. Governança de Dados
Desde o passado, a Governança de Dados sempre foi um objetivo a ser
plenamente alcançado. Já nos tempos da antiga Administração de Dados, de
uma forma ou outra, já havia a preocupação em ter as respostas para as
seguintes perguntas:
Qual a política adotada pela empresa sobre o uso dos dados e
informações?
Quais são as responsabilidades e os papéis envolvidos no uso dos dados
e informações?
Quais os processos utilizados para gerir dados e informações? Quais os
padrões e procedimentos utilizados?
Quem são os gestores das informações?
Quem são as pessoas que avaliaram e atestaram a qualidade dos dados
e metadados?
Quem tem direito a consumir quais informações?
Quem construiu os mecanismos de guarda?
Existem projetos estruturantes para melhorar a gestão dos dados?
Quando a empresa possui uma Gestão de Dados formalizada e atuante,
grande parte das questões é respondida, mesmo que eventualmente de
forma super�cial. A clareza e o conteúdo das respostas re�ete diretamente a
maturidade em Gestão de Dados da empresa.
11.3. Conduta
Conduta é a postura adotada por todos os integrantes da equipe de Gestão
de Dados. Equipes de Gestão de Dados que funcionam nos moldes
tradicionais costumam não dar tanta ênfase em todos os aspectos
comportamentais tidos como fundamentais pela Gestão de Dados Moderna
para conquistar e manter parceiros, adaptar-se às necessidades dos clientes,
diminuir o retrabalho dos envolvidos e melhorar a qualidade dos dados e
metadados da organização.
A Gestão de Dados Moderna entende que uma conduta bem
trabalhada/incentivada resulta em um quadro de pessoas mais produtivas
que gostam do que fazem, trabalham efetivamente como equipes e estão
focadas em objetivos. Portanto, não necessitam de gerenciamentos e
controles agressivos. Na prática, são equipes que todo gestor quer.
A Gestão de Dados Moderna prega oito aspectos ligados diretamente à
conduta pessoal que devem ser adotados pelos pro�ssionais. São eles:
Adaptabilidade, Agilidade, Bom Senso, Comprometimento, Didática,
Objetividade, Proatividade e Racionalidade.
O livro abordará as características dos oito aspectos, mas não detalhará
como atingir cada uma delas, e sim as de�nições de cada um dos aspectos.
11.3.1. Adaptação
Adaptação é uma característica comportamental do ser humano que
expressa a facilidade de se adaptar às novas tecnologias, ao ambiente, à
cultura e a demais mudanças que ocorrem nas empresas.
Toda adaptação estabelece o equilíbrio entre o organismo e o ambiente. A
noção de equilíbrio tem um signi�cado fundamental, tanto do ponto de
vista afetivo quanto do intelectual. Na adaptação, tal equilíbrio se dá entre
dois polos: a assimilação (relativa ao organismo, que conserva sua forma) e a
acomodação (relativa à situação exterior em função da qual o organismo se
modi�ca). Essas duas noções têm um signi�cado tanto mental quanto
biológico. Há sempre uma tensão entre assimilação e acomodação.
Pro�ssionais que se destacam nesta característica comportamental têm
total domínio do equilíbrio.
Na prática, pro�ssionais de fácil adaptação são menos sensíveis a quebras
de paradigmas, costumam perder pouco tempo nas adaptações e geralmente
participam como facilitadores nos processos de mudança. Além disso, não
contaminam a equipe reclamando de tudo e de todos.
11.3.2. Agilidade
Agilidade é a capacidade de dar respostas rápidas às solicitações com
atitude, foco na entrega, trabalho em equipe e melhoria contínua. Ser ágil
não signi�ca atender com uma resposta negativa e sim atender rápido,
dentro dos processos vigentes, com o propósito de entregar algo que foi
solicitado, dentro das direções e premissas das equipes, sempre visando
melhorar o processo atual de trabalho.
Atualmente esta habilidade é fundamental, principalmente quando as
equipes de Gestão de Dados estão envolvidas em desenvolvimento ágil de
aplicações.
Dentro das empresas não há mais espaço para demoras excessivas na
conclusão de trabalhos simples ou até mesmo condutas negativas, como
segurar a conclusão de algum trabalho para mostrar que está trabalhando. A
conduta deve ser outra – terminar logo o trabalho para poder �car livre para
assumir outra atividade.
Cabe aos coordenadores e/ou gerentes das equipes monitorar o andamento
das solicitações atendidas pelas suas equipes e, quando necessário, ajustar os
desvios que possam ocorrer no dia a dia.
11.3.3. Bom senso
Bom senso é uma habilidade utilizada na argumentação que é estritamente
ligada às noções de sabedoria e de razoabilidade.
O bom senso de�ne a capacidade média que uma pessoa possui, ou deveria
possuir, de adequar regras e costumes a determinadas realidades e assim
poder fazer bons julgamentos e escolhas.
Pode, assim, ser de�nido como a forma de “�losofar” espontânea do
homem comum, também chamada de “�loso�a de vida”, que supõe certa
capacidade de organização e independência de quem analisa a experiência
de vida cotidiana.
O bom senso está muito ligado à ideia de sensatez, sendo uma capacidade
intuitiva de distinguir a melhor conduta em situações especí�cas que, muitas
vezes, são difíceis de serem analisadas mais longamente.
O bom senso é a característica de conduta mais difícil de conseguir em
todos os casos, pois, geralmente, a linha entre um senso muito rígido e um
senso sem rigor é muito tênue.
11.3.4. Comprometimento
Comprometimento pode parecer algo simples de se entender em um
primeiro momento, mas será que nós entendemos realmente o que é estar
comprometido?
O comprometimento é o resultado de duas características pessoais: a
motivação e o engajamento.
A motivação é decorrente de fatores internos do ser humano, do seu estilo
de vida, de seus valores e crenças, objetivos e necessidades – ou seja, é
pessoal. O papel da empresa é fazer com que o colaborador desenvolva esta
motivação em sua rotina de trabalho.
O engajamento é o entusiasmo, a satisfação pelo trabalho. É fazer com que
a pessoa se sinta envolvida com a organização. Ela deve perceber que seu
trabalho interfere diretamente em toda a cadeia de negócio da organização,
gerando frutos e retorno direto. Não é apenas fazer o próprio trabalho bem
feito, mas contribuir para que o todo faça da melhor maneira possível.
Comprometimento é a junção dessas duas características e pode ser
classi�cado em dois tipos: o curto e o longo.
O comprometimento curto é essencialmenteuma promessa pontual,
como: “vou terminar esse modelo de dados até o �nal do dia” ou “vou
descobrir a origem dessa informação até amanhã”. Já o comprometimento
longo é quando uma pessoa ou equipe está comprometida com algo de uma
forma mais emocional ou ideológica, como: “estou comprometido com a
�loso�a da área” ou “estou comprometido com a equipe”.
Pessoas que não possuem nenhum dos dois comprometimentos são
aquelas que apenas fazem o que deve ser feito para se verem livres da tarefa e
irem embora. Geralmente são pessoas que não gostam do que fazem ou
estão desmotivadas por algum motivo.
11.3.5. Didática
Didática signi�ca “habilidade em ensinar”. Envolve métodos e técnicas na
orientação da aprendizagem. É o modo pelo qual um docente coloca em
prática a passagem de conhecimento de uma pessoa a outra.
A metodologia de Gestão de Dados vigente, bem como outros aspectos
mais técnicos que envolvam algum conhecimento técnico, pode não ser
conhecida por todos os envolvidos. Por esta razão, a didática é um
importante aspecto a ser trabalhado/conquistado pelas equipes de Gestão de
Dados.
De todos os aspectos de conduta elencados pela Gestão de Dados
Moderna, a didática é o menos pessoal, ou seja, é o aspecto que menos
depende de fatores motivacionais. De forma geral, com o tempo, as pessoas
evoluem em suas habilidades de didática. Raros são os casos onde a pessoa
tem sua capacidade didática diminuída.
A didática está ligada diretamente à comunicação. Se bem trabalhada gera
ganhos enormes, como a diminuição do retrabalho.
A didática não envolve apenas o uso da fala. Também envolve o uso de
recursos de apoio, como slides, �guras, grá�cos, etc. Pessoas com alguma
de�ciência em expressar seus conhecimentos através da fala devem utilizar
recursos de apoio para facilitar a transmissão de conhecimento.
11.3.6. Objetividade
Objetividade é uma característica bastante importante, pois envolve
diretamente a compreensão das pessoas e também o tempo de resposta às
ações dos membros de uma equipe de Gestão de Dados. Quanto mais
objetiva e direta, mais clara e rápida é a resposta ou a resolução de um
problema.
Objetividade consiste em fazer algo ou expressar de maneira simples, sem
metáforas, ambiguidades, ideias implícitas ou ações desnecessárias durante o
processo de execução.
Em algumas situações, a falta de objetividade do pro�ssional interfere no
andamento das atividades dos gestores de dados. Pessoas assim costumam
ser mais subjetivas (não transparentes) em suas ações, ocasionando por
vezes con�itos com os demais pro�ssionais envolvidos.
Pro�ssionais com pouca experiência às vezes também têm di�culdades
para serem objetivos, principalmente quando precisam passar mensagens de
algo que não está conforme. Demoram muito mais para explicar o cenário
em volta do problema do que passar o próprio problema, as causas,
consequências e também as formas de correção.
11.3.7. Proatividade
A proatividade é uma característica que está ligada diretamente à
antecipação de escolhas e ações frente às situações previstas. O pre�xo “pro”
signi�ca antecipação, algo que acontece antes.
Proatividade também pode ser de�nida como um conjunto de
comportamentos “extra papel”, em que a pessoa busca espontaneamente por
mudanças no seu ambiente de trabalho, solucionando e antecipando-se aos
problemas, visando metas de longo prazo que bene�ciam a organização.
Entre as principais características da proatividade podemos destacar:
Busca ativa por oportunidades de mudanças.
Planejamento e execução de ideias.
Enfrentamento de obstáculos.
Pessoas proativas estão sempre se antecipando aos acontecimentos,
fazendo até mesmo alguma espécie de previsão para poderem atuar através
de determinadas formas planejadas.
11.3.8. Racionalidade
Racionalidade é tomar suas atitudes através de pensamentos baseados na
razão. Razão é a capacidade da mente humana que permite chegar a
conclusões a partir de suposições ou premissas.
A razão permite identi�car e operar conceitos em abstração, resolver
problemas, encontrar coerência ou contradição entre eles e, assim, descartar
ou formar novos conceitos, de uma forma ordenada e orientada para
objetivos. Inclui raciocinar, apreender, compreender, ponderar e julgar. Por
vezes, razão é usada como sinônimo de inteligência.
A razão é uma característica extremamente oposta à cultura do “fazer sem
pensar” que muitas vezes, infelizmente, é adotada por algumas equipes.
A Gestão de Dados Moderna entende que o Gestor de Dados deve ser uma
pessoa extremamente racional, não movida a pressões externas ou outros
tipos de emoções que podem in�uenciar negativamente as ações e decisões.
A razão é uma importante característica pessoal que possibilita a construção
de soluções simples e duradouras.
11.4. Pilares das organizações
Os pilares das organizações representam os ativos mais importantes das
empresas sob a ótica da Gestão de Dados Moderna: dados e metadados,
pessoas e recursos materiais.
Este conceito difere da Gestão de Dados tradicional, onde somente os
dados constituem o ativo mais importante das organizações.
11.4.1. Dados e metadados
Dados e metadados de qualidade são fundamentais para tomar decisões
ágeis, precisas e corretas de forma rápida e com baixos custos, trazendo
vantagens competitivas para a empresa em relação aos seus concorrentes.
Os dados e metadados também são fundamentais para estruturar empresas
para novas fusões e aquisições, além de atender aos requisitos
regulamentares que porventura uma empresa pode ser submetida, tais como
adequações a Basileia, lei Sarbanes-Oxley, instruções normativas, leis sobre
privacidade de informações, etc.
Pensar que somente os dados constituem o ativo mais importante das
organizações e que empresas existem somente para “gerir dados” é uma
�loso�a ultrapassada. Um dos erros da antiga Administração de Dados foi
pensar justamente que somente os dados eram os ativos mais importantes
das empresas. Não levaram em conta os demais ativos que são tão
importantes quanto.
11.4.2. Pessoas
Pessoas são o ativo que fazem as coisas acontecerem dentro das empresas.
Sem elas nada é pensado, nada é feito, nada é criado. Portanto, não existe
empresa de sucesso sem uma gestão de pessoas e�caz.
Pessoas devem ser respeitadas, reconhecidas e motivadas tanto dentro das
equipes de Gestão de Dados quanto fora. Conforme dito anteriormente, as
pessoas são responsáveis por todos os trabalhos dentro de qualquer
empresa, sejam eles os mais simples, operacionais, táticos ou estratégicos.
Além disso, elas geram e mantêm a cultura da empresa. Portanto, quanto
mais se sentirem valorizadas e entenderem as regras e os objetivos da
empresa, melhor será o desempenho e a abertura para a quebra de
paradigmas.
11.4.3. Recursos financeiros
Recursos �nanceiros são utilizados para estabelecer limites, regras e
prioridades sobre operações e investimentos das empresas.
Empresas existem para algum propósito – na maioria das vezes, ligado a
retornos �nanceiros ou prestação de serviços à sociedade. Questões como
retorno sobre o investimento das iniciativas, custos das operações, margens
de lucro e caixa disponível in�uenciam diretamente a utilização da Gestão
de Dados nas empresas. Empresas similares com culturas e expectativas
diferentes em relação ao ativo “recursos �nanceiros” possuem equipes de
Gestão de Dados totalmente diferentes em propósitos, porte, forma de
atuação e maturidade.
As equipes de Gestão de Dados devem estar conscientes de que elas
existem para apoiar a empresa na obtenção de seus propósitos. Para tal,
recursos �nanceiros para fomentar os projetos de investimentos e pessoas
são fundamentais. Contudo, algumas equipes de Gestão de Dados ainda
confundem os seus próprios objetivos com os objetivos estratégicos da
empresa para a qual a área presta apoio.
12. Boas Práticas da Gestão de
Dados Moderna
“O riso é a mecânica aplicada no ser vivo.”
Henri Bergson
12.1. As quatorze boas práticas de Gestão de
Dados Moderna
Para que a Gestão de Dados Moderna consiga atingir seusobjetivos, torna-
se necessária a adoção de um conjunto mínimo de boas práticas que
norteiam a �loso�a da Gestão de Dados Moderna.
As práticas são genéricas e estão ligadas a características pessoais,
mencionadas no framework da Gestão de Dados Moderna, e a estilos de
gerenciamento. Vale ressaltar que boa parte do conjunto de boas práticas
também pode ser adotada em outras disciplinas.
Quando comecei a escrever artigos sobre as boas práticas da Gestão de
Dados Moderna, elas eram inicialmente dez. Agora, na terceira versão do
framework da Gestão de Dados Moderna, já são quatorze.
A �gura a seguir, em formato de mapa mental, relaciona as quatorze boas
práticas da Gestão de Dados Moderna. Cada prática será detalhada mais
adiante.
Figura 12.1 – Boas práticas da Gestão de Dados Moderna
Vale a pena destacar que as práticas devem ser adotadas em sua totalidade.
O simples esquecimento de uma ou mais práticas pode comprometer a
e�cácia da Gestão de Dados Moderna.
Além disso, é importante frisar que não existe uma ordem prede�nida de
aplicação das práticas, ou seja, podem ser aplicadas simultaneamente ou
não.
12.2. Manter um time de destaque
O sucesso ou fracasso de um time está diretamente ligado ao
comprometimento, à competência e à experiência dos membros da equipe.
Pro�ssionais de destaque rendem três ou quatro vezes mais que pro�ssionais
medianos. Além disso, pro�ssionais de destaque não expõem a credibilidade
da equipe, pois estão comprometidos com os objetivos da área, já passaram
por diversas situações críticas anteriores e estão tecnicamente capacitados
para utilizar e orientar seus clientes nas melhores práticas da Gestão de
Dados. Infelizmente algumas empresas não enxergam isso e ainda preferem
montar equipes com a base de sua pirâmide formada por pro�ssionais com
baixa quali�cação e experiência.
Esta abordagem funcionava muito bem no passado, onde se tinha a
oportunidade de formar pro�ssionais durante o andamento dos projetos,
pois estes eram longos, seguiam o modelo cascata e o escopo da atuação da
área de Gestão de Dados não era tão abrangente. Além disso, a interação
entre as pessoas não era muito grande. Vale ressaltar que não sou contra a
contratação de pro�ssionais juniores, porém este tipo de per�l não pode ser
utilizado como base da pirâmide de uma equipe de Gestão de Dados.
Mesmo assim, devemos ter em mente que uma simples passagem de
informação equivocada, ou falta de �rmeza no parecer de questões mais
críticas, põe em dúvida a capacidade do pro�ssional e também da área de
Gestão de Dados junto aos seus stakeholders. De forma geral, as
consequências desta prática são: aumento desnecessário de recursos na
equipe, baixa produtividade, comunicação falha, baixo nivelamento de
recursos e descrédito da equipe.
A continuidade desta prática nos dias atuais é muito perigosa, pois os
pro�ssionais de Gestão de Dados interagem com várias pessoas e seus
papéis não estão mais limitados às funções de DBA ou Administrador de
Dados. Novos papéis, como Gestor de Dados de Negócio e Gestor
Estratégico de Dados, começam a surgir nas organizações mais maduras.
Independentemente dos papéis, a prática de ter equipes pouco quali�cadas
deve ser abolida, sob pena dos pro�ssionais da área de Gestão de Dados
terem suas capacidades técnicas e comportamentais questionadas.
Mas, a�nal, o que é um pro�ssional de Gestão de Dados de destaque?
Conforme �gura a seguir, um Gestor de Dados de destaque deve possuir
habilidades que podem ser divididas em quatro grupos principais: 
Figura 12.2 – Habilidades necessárias para um Gestor de Dados
Conhecimento do Negócio: ao conhecer em profundidade as áreas de
negócio, o pro�ssional de Gestão de Dados é capaz de identi�car
rapidamente as necessidades dos clientes, mesmo quando elas não são
claramente articuladas. Além disso, o pro�ssional de Gestão de Dados
deve ser capaz de propor soluções que podem não ter ocorrido aos
clientes e avaliar imediatamente os impactos daquilo que está sendo
pedido em outros processos de negócio da organização.
Habilidades Comportamentais: muitas dessas habilidades são
utilizadas nos conceitos da Gestão de Dados Moderna. De forma geral,
o pro�ssional de Gestão de Dados precisa ser capaz de se relacionar
bem com pessoas de diferentes formações, estilos e mentalidades,
especialmente na medida em que é sua função estar envolvido em
“fazer a ligação” entre as áreas de negócio e TI. Ou seja, precisa lidar
com pessoas de estilos muito diferentes. Precisa saber ouvir, ser capaz
de compreender a comunicação não verbal, distinguir necessidades de
desejos, negociar e assumir compromissos. Além disso, precisa ter
pensamento sistêmico, de modo a prever as interações entre o que está
sendo proposto e as demais necessidades da organização.
Habilidades Técnicas: são habilidades ligadas ao conhecimento das
tecnologias utilizadas nas atividades de Gestão de Dados, tais como:
Modelagem de Dados, operações em banco de dados, análise e projeto
de sistemas, lógica, tecnologia para integração de informações e
utilização de ferramentas. Muitos pro�ssionais tendem a focar somente
neste tipo de habilidade e esquecem as demais. Para trabalhar com
Gestão de Dados não basta apenas ser um bom técnico.
Habilidades em Gestão de Dados: são habilidades ligadas ao
conhecimento das funções de gerenciamento de dados. O
gerenciamento destas funções é apoiado pelo DAMA-DMBOK®,
framework coordenado de funções para o gerenciamento de dados,
metadados e ativos de informação nas organizações.
Algumas habilidades técnicas e as habilidades em Gestão de Dados podem
ser mensuradas por certi�cações internacionais. As certi�cações sérias são
um bom instrumento para avaliar os conhecimentos técnicos e as
habilidades dos pro�ssionais.
Vale ressaltar que, apesar de ajudar, a certi�cação por si só não assegura
que o pro�ssional possua o melhor per�l para trabalhar em uma empresa. O
conhecimento do negócio e as habilidades comportamentais também são
fundamentais para formar um pro�ssional de destaque.
Montar um time de destaque não é uma tarefa fácil. É comum encontrar
colegas que passam por di�culdades na hora de contratar pessoas. O
mercado de Gestão de Dados está ressurgindo de forma acelerada, porém a
quantidade de pro�ssionais quali�cados não está acompanhando este
crescimento. Portanto, depois de montado, não devemos medir esforços
para manter a harmonia e a evolução do time. A�nal, relembrando as
premissas da Gestão de Dados Moderna, as pessoas também são ativos
importantes das organizações.
12.3. Atuar no início dos projetos
Atuar no início dos projetos signi�ca atuar de forma proativa, com o
propósito de identi�car e/ou mitigar os principais riscos e também eliminar
as principais anomalias dos projetos. O grau de incerteza dos projetos nas
fases iniciais é muito maior do que nas fases mais próximas do seu
encerramento. Logo, quando o assunto é riscos, sabemos que quanto
maiores forem os níveis de incerteza, maiores serão os riscos e suas
probabilidades. Se a área de Gestão de Dados tiver uma atuação mais
intensa nesta fase, antevendo problemas referentes ao uso dos dados e
informações, certamente ajudará a reduzir a incidência de anomalias e a
diminuir o custo do retrabalho.
Vale ressaltar que a prática de atuar no início dos projetos não se resume
apenas à atuação de Administradores de Dados ou Gestores Técnicos de
Dados nas orientações sobre Modelagem de Dados e/ou avaliações de
modelos de dados. A abrangência desta prática é bem mais ampla e pode ser
aplicada em todas as funções previstas no guia DAMA-DMBOK®. Podemos
citar como exemplos:
Gerenciamento da Arquitetura de Dados: de�nições preliminares da
arquitetura empresarial e também da Arquitetura de Dados
corporativa.
Desenvolvimento de Dados: orientações e avaliações preliminares nos
modelos de dados produzidos pelas equipes de
desenvolvimento/projeto.
Gerência de Operações e Banco de Dados: de�nição de rotinas mais
proativas das operações de infraestrutura e administração de banco de
dados.
Gerenciamentode Dados Mestres e Dados de Referência: apoio na
identi�cação, reutilização e governança dos dados mestres e de
referência das organizações.
Gerenciamento da Qualidade de Dados: a Gestão de Dados Moderna
prega que a qualidade não é controlada, e sim planejada. Além disso,
Qualidade de Dados não é um projeto, mas um programa. A
conscientização das pessoas é fundamental para o sucesso. Portanto, a
participação da área de Gestão de Dados no planejamento da qualidade
dos dados é fundamental. Um bom planejamento interfere diretamente
na qualidade dos dados criados na organização, reduzindo a incidência
de futuras limpezas e correções.
A área de Gestão de Dados deve atuar em todas as fases do ciclo de vida de
desenvolvimento de soware e também do ciclo de vida dos dados. Vale
ressaltar que quanto maior o esforço nas fases iniciais destes ciclos, menor o
esforço nas fases �nais e de controle.
12.4. Ser ágil nos atendimentos
Um dos principais fatores de resistência à implantação de áreas de Gestão
de Dados nas empresas é o fator tempo. Partes envolvidas diretamente no
processo, como as equipes de desenvolvimento/projetos, costumam alegar
que os projetos podem atrasar devido ao tempo gasto nas atividades
executadas pela equipe de Gestão de Dados, sem levar em conta a qualidade
agregada ao produto �nal que essas atividades podem gerar.
Além disso, várias empresas estão adotando métodos de desenvolvimento
ágil na construção de soware, como Scrum e Kanban, o que aumenta ainda
mais a necessidade de agilidade nos atendimentos, sob pena da equipe de
Gestão de Dados não suportar o ritmo demandado das partes interessadas e
não conseguir demonstrar o seu real valor.
De�nir um Acordo de Nível de Serviço, também conhecido como SLA
(Service Level Agreement), curto e objetivo que abranja todas as atividades
executadas pela área é fundamental para que a Gestão de Dados não seja
encarada como algo extremamente burocrático e ine�caz, ou seja, uma área
que está dentro dos processos apenas para atrapalhar, sem agregar nenhum
valor.
Quanto menor o tempo de atendimento da tarefa, menor será a resistência,
porém é importante destacar que o SLA deve ser cumprido, acompanhado e
seus resultados divulgados periodicamente a todos os envolvidos. De nada
adianta uma empresa utilizar um SLA muito curto se ela não tem
capacidade de atender à maioria dos prazos estipulados.
Mas como de�nir as atividades e os tempos médios para o SLA? Não existe
uma receita de bolo especí�ca para estabelecer um SLA. A quantidade de
pessoas, a experiência da equipe, a capacitação técnica dos envolvidos, o
ferramental utilizado, as características do negócio e os aspectos culturais
in�uenciam diretamente no tempo médio de atendimento de cada atividade.
Um SLA adotado em uma empresa nem sempre será o SLA ideal de outra
empresa.
Mesmo assim, algumas boas práticas podem ser utilizadas na de�nição
deste SLA:
O SLA deve ser divulgado para todos os envolvidos. Divulgar o SLA
apenas para a equipe de Gestão de Dados não faz nenhum sentido.
O SLA deve ser aplicado dentro do horário de trabalho padrão da
empresa. Exemplo: das 08:00h às 17:00h.
Os tempos de atendimento devem ser dados em horas úteis.
As tarefas mais usuais devem ser classi�cadas por
tamanho/complexidade. Exemplo: quantidade de entidades/tabelas,
modelo novo x alteração pontual em modelo, etc.
As classi�cações dos tempos de atendimento devem ser simples e
facilmente compreendidas por todos. Fórmulas matemáticas que
envolvem a contagem de vários tipos de objetos (entidades, atributos,
relacionamentos, domínios, etc.) são mais precisas quando o produto
está no �m e o solicitante sabe exatamente o que ele quer (o que é raro),
porém são extremamente complicadas para quem está solicitando o
serviço. Durante o planejamento prazos calculados desta forma são
inviáveis e até mesmo imprecisos.
Para tarefas de difícil estimativa genérica, deve-se estabelecer um prazo
para dar a estimativa �nal. Exemplo: prazo de x dias para efetuar tuning
em base de dados.
O SLA deve possuir uma meta de cumprimento e também uma meta
desa�adora. Exemplo: meta de atendimento de 90% das solicitações
dentro do prazo e meta desa�adora de 95%.
Os valores cumpridos também devem ser divulgados. A�nal, se o SLA
é curto e a equipe de Gestão de Dados atende à meta de atendimento
estabelecida, não há razão para gargalos.
A tabela a seguir mostra um exemplo de SLA que pode ser adotado como
exemplo em uma equipe de Gestão de Dados.
Atividade Grandeza Esforço
(em horas)
Tempo
(em
horas)
Homologar novo modelo de dados
Pequeno 8h 16h
Médio 12h 20h
Grande 16h 36h
Homologar alterações em modelos de Pequeno 4h 8h
dados Médio 8h 16h
Grande 12h 20h
Implementar novo modelo de dados em
SGBD (por ambiente) NA 4h 8h
Implementar alterações em modelos de
dados no SGBD (por ambiente)
Sem
manipulação dos
dados
4h 8h
Com
manipulação dos
dados
12h 16h
Disponibilizar modelos de dados NA 2h 4h
Efetuar complete x compare entre modelo
e ambientes de SGBD NA 2h 4h
Efetuar engenharia reversa NA 2h 4h
Orçar estimativa de tuning NA 8h 16h
Efetuar consultoria em Modelagem de
Dados NA 2h 16h
Identi�car gestor de informação NA 8h 24h
Realizar análise de impacto de conceitos NA 4h 12h
Homologar termo corporativo NA 8h 16h
Orçar estimativa de consultoria em
Qualidade de Dados NA 8h 24h
Corrigir dado mestre NA 2h 16h
Carregar metadados no repositório NA 2h 8h
Homologar alteração em arquitetura
corporativa NA 8h 24h
Tabela 12.1 – Exemplo de SLA ágil
12.5. Utilizar princípios e ferramentas da
qualidade
Muitas organizações que possuem equipe de Gestão de Dados constituída
focam grande parte de seus esforços nas atividades de homologação de
modelos de dados. Porém, com o passar do tempo, a equipe começa a
perceber que os esforços não são su�cientes para obter uma melhora
signi�cativa nos modelos submetidos à avaliação e nos dados que são
manipulados pela organização. Em alguns casos há a impressão de que a
qualidade piorou.
Mesmo com o trabalho de controle dos modelos de dados produzidos, por
que a qualidade dos dados e das estruturas dos dados não evoluiu? As razões
podem mudar de acordo com o cenário de cada empresa, mas vou listar a
seguir os seis equívocos mais comuns cometidos pelas organizações:
Acreditar que a atividade de avaliação de modelos de dados é su�ciente
para atingir um bom nível de qualidade, concentrando a maioria dos
esforços da equipe neste tipo de atividade.
Não compreender que a qualidade é compartilhada por todos, desde o
analista que projeta o modelo de dados até as pessoas que fornecem as
informações a serem incluídas nos bancos de dados.
Não investir na conscientização da importância do “fazer correto” e
“fazer de uma única vez” para todas as pessoas envolvidas nos
processos, deixando de mostrar a importância dos dados íntegros e
precisos para a organização.
Dar um peso menor na qualidade em relação a outros critérios dos
projetos, como, por exemplo, tempo e custo.
Não utilizar o ciclo PDCA nos processos de Gestão de Dados.
Não possuir uma base de registros históricos, contendo dados
fundamentais sobre o andamento dos processos, qualidade das
estruturas de dados, volumes de correções, etc.
Os equívocos abordados anteriormente são comuns em áreas que não
adotam a �loso�a da Gestão de Dados Moderna.
A Gestão de Dados Moderna sugere que os princípios e as ferramentas da
qualidade são importantes instrumentos para elevar o grau de qualidade dos
dados e metadados da empresa, além de elevar o nível de maturidade em
Gestão de Dados por toda a empresa. Entre os principais princípios
podemos destacar:
O foco da qualidade é o cliente: no caso da Gestão de Dados, são
todas as pessoas que criam, manipulam, utilizam ou são de alguma
forma afetadas pelo conteúdo dos dados.
A qualidade é planejada e não inspecionada: o foco da qualidade
deve ser na prevenção e não na inspeção (controle). A inspeção deve
ser utilizada para provar que o processo funciona (porque as boas
práticas de qualidade vêmsendo utilizadas) e não simplesmente como
um modo de rejeitar as falhas nos dados e metadados.
Envolvimento das pessoas: quando as pessoas são envolvidas nos
processos, elas compreendem sua importância e seu papel na empresa,
aceitando que são responsáveis pelos problemas e pelas soluções. Elas
são motivadas a identi�car os obstáculos e a avaliá-los, a aperfeiçoar
seu conhecimento e experiência e a compartilhá-los, discutindo os
problemas abertamente.
Melhoria contínua: é não se contentar e se acomodar com os níveis
alcançados em processos otimizados. Conforme estabelecido nas
normas da família ISO 9000, o objetivo da melhoria contínua da
qualidade é aumentar a probabilidade de melhorar a satisfação dos
clientes e das demais partes interessadas.
12.5.1. Ciclo PDCA aplicado na Gestão de Dados Moderna
O PDCA é um ciclo de desenvolvimento que tem foco na melhoria
contínua. Ele é aplicado para atingir resultados dentro dos processos e pode
ser utilizado em qualquer organização, independentemente da área de
atuação. No caso especí�co da Gestão de Dados, ele pode ser aplicado
praticamente em todos os processos.
Conforme �gura a seguir, o ciclo começa pelo planejamento (P – Plan).
Em seguida as ações planejadas são executadas (D – Do), checa-se se o que
foi feito estava de acordo com o planejado, constantemente e repetidamente
(C – Check), e toma-se uma ação para eliminar ou ao menos mitigar os
problemas encontrados nos produtos ou na execução do processo (A – Act).
Figura 12.3 – Ciclo PDCA
Se aplicarmos o PDCA nos processos de construção e avaliação de
modelos de dados, teremos o seguinte cenário.
P (Plan): identi�cação das entidades corporativas, mapeadas na
Arquitetura de Dados da organização, e das demais necessidades de
informação que serão contempladas na modelagem. Durante esta
identi�cação é obrigatória a participação de pessoas com visão
corporativa dos dados da organização. Geralmente este papel é feito
pelo Gestor Estratégico de Dados.
D (Do): construção do modelo de dados com apoio da equipe de
Gestão de Dados. O analista responsável pelo projeto constrói e altera o
modelo de acordo com as diretrizes passadas pelos gestores de dados
em reuniões prévias.
C (Check): avaliação do modelo de dados construído e registro dos
dados da avaliação. O gestor de dados avalia o modelo de dados de
acordo com os critérios prede�nidos em sua metodologia e registra os
dados da avaliação.
A (Act): tomada de ações corretivas no produto ou no processo. Se o
modelo for reprovado, o analista corrige os erros apontados no laudo
de avaliação (ação para correção do produto). Com o apoio das
ferramentas de qualidade, o gestor estratégico de dados sugere ações
após análise dos registros das avaliações efetuadas em um determinado
período (ação para os novos produtos e também melhoria do
processo).
Este exemplo deixa claro que a qualidade não é “controlada”, e sim
“planejada”. Equipes que trabalham de forma mais reativa costumam dar
ênfase somente nas fases de controle, esquecendo que a qualidade é obtida
através de um ciclo completo de melhoria contínua.
Vale ressaltar que o PDCA também pode ser aplicado em outros processos,
como os de Data Quality. Infelizmente ainda é muito comum encontrar
organizações que investem em programas de Data Quality voltados somente
para atividades operacionais de correção dos dados, ignorando trabalhos
mais simples e com maior retorno de resultado, como a conscientização dos
envolvidos na criação e manipulação dos dados.
12.5.2. Diagrama de Pareto
O diagrama de Pareto é um grá�co de barras que ordena as frequências das
ocorrências, da maior para a menor, permitindo a priorização dos
problemas, procurando levar a cabo o princípio de Pareto (regra dos 80 –
20). Este princípio estabelece que 80% das consequências ou ocorrências
totais advêm de 20% das causas.
Sua maior utilidade é permitir uma fácil visualização e identi�cação das
causas ou problemas mais importantes, possibilitando a concentração de
esforços sobre eles.
Se tomarmos como exemplo os processos de construção e avaliação de
modelos de dados e �zermos um grá�co agrupando os erros encontrados
nas avaliações desses modelos agrupados por tipos de erros, teremos algo
semelhante ao grá�co a seguir.
Figura 12.4 – Exemplo de utilização de um diagrama de Pareto
Olhando a �gura anterior, rapidamente chegamos à conclusão de que as
maiores incidências de erros são encontradas nos critérios “Integridade” e
“Integração”. De posse desta informação, cabe ao gestor estratégico de dados
tomar ações que diminuam a incidência de erros nesses dois critérios.
12.5.3. Diagrama de causa e efeito
O Diagrama de Ishikawa, também conhecido como diagrama “causa e
efeito” ou “espinha de peixe”, é uma ferramenta grá�ca utilizada para
estruturar hierarquicamente as causas potenciais de determinado problema,
bem como seus efeitos sobre a qualidade dos produtos (no caso, os dados
e/ou as estruturas de dados).
A análise do diagrama é feita a partir de uma lista de�nida de possíveis
causas. As mais prováveis são identi�cadas e selecionadas para uma melhor
análise. Ao examinar cada causa, o usuário deve observar fatos que
mudaram, como, por exemplo, desvios de norma ou de padrões. Deve-se
lembrar também que o objetivo deste trabalho é mapear formas de eliminar
as causas e não apenas mapear os sintomas dos problemas.
A �gura a seguir mostra um exemplo de aplicação do diagrama de causa e
efeito. O problema ilustrado continua sendo a qualidade dos modelos de
dados que são submetidos a avaliações pela equipe de Gestão de Dados.
Figura 12.5-Exemplo de um diagrama de causa e efeito
Segundo a �gura anterior, a empresa mapeou seis grupos de causas
principais: capacitação, metodologia, ferramentas, comunicação, cultura e
projetos. A �gura exempli�cou o detalhamento dos dois primeiros grupos.
No grupo referente à capacitação, as causas identi�cadas sugerem ações
para promover treinamentos em Modelagem de Dados e levantamento de
requisitos para os pro�ssionais da empresa, divulgação dos padrões
existentes (muito provavelmente através de ações junto ao grupo
comunicação) e de�nição dos melhores per�s para trabalharem na
produção dos modelos de dados. Este último tem uma relação muito forte
com o grupo metodologia.
Por �m, o grupo metodologia nos mostrou causas que sugerem ações no
sentido de revisar os padrões existentes e produzir roteiros ou guias de boas
práticas para melhorar o embasamento técnico dos pro�ssionais que
produzem esses modelos.
12.5.4. Gráficos de controle
Esses grá�cos são importantes ferramentas de qualidade utilizadas no
controle estatístico do processo. São utilizados para registrar as medidas das
amostras em intervalos regulares.
Os grá�cos de controle tornam perceptíveis as variações anormais das
medidas dentro de um processo e acompanham tendências e
comportamentos. Sua simplicidade permite que, com uma rápida consulta,
seja fácil perceber quando um processo está fugindo do controle. Com isso,
as áreas de Gestão de Dados ganham agilidade nas ações para identi�cação e
resolução dos problemas. Para que o processo seja considerado sob controle,
os dados registrados devem se enquadrar dentro de uma curva normal.
A �gura a seguir demonstra um exemplo de grá�co de controle.
Figura 12.6 – Exemplo de um grá�co de controle
A média estabelecida é representada por uma linha sólida entre os limites
superior e inferior. No caso da �gura anterior, o valor é 0,4.
Os níveis de desvio aceitáveis, também conhecidos como limites
admissíveis, em relação ao valor médio são representados por linhas
tracejadas. No caso da �gura anterior, varia de 0 a 0,8. O uso dos limites
admissíveis é recomendado, pois se espera que todo o processo possua
alguma variação.
Caso exista algum registro fora dos limites superior e inferior, considera-se
o processo fora de controle. No caso da �gura anterior, o processo saiu de
controle em três medições consecutivas. O exemplo deixa claro que, após
constatar que o processo saiu de controle, açõesde melhoria foram tomadas
com sucesso, pois logo após o processo retornou aos limites estabelecidos.
Muito provavelmente as ações foram de�nidas através das análises do
diagrama de Pareto e do diagrama de causa e efeito.
12.5.5. Listas de verificações (checklists)
As listas de veri�cações, também conhecidas como checklists, são a base
para o desenvolvimento do trabalho e a garantia de que ele será realizado
seguindo os passos certos. Elas podem ser utilizadas como um roteiro
sequencial para construção de um trabalho ou então como um passo a passo
para avaliar algo que foi produzido, como, por exemplo, modelos de dados,
cargas de dados, manipulações de dados, concessão de acesso a dados, etc.
É importante lembrar que, por mais experiente que seja o pro�ssional, ele
pode esquecer coisas importantes, pois sua memória é limitada. Desta
forma, as listas de veri�cações ajudam as pessoas a lembrar o que deve ser
feito e garantir que foi feito conforme previsto. Quanto mais simples, mais
e�cazes são as listas.
12.6. Trabalhar com indicadores de gestão
Indicadores são medidas, geralmente estatísticas, utilizadas para traduzir
quantitativamente um conceito e fornecer informações sobre determinados
aspectos objetivando a formulação, o monitoramento e a avaliação dos
processos existentes ou então apenas para �ns de pesquisa.
O registro das atividades executadas pelas equipes de Gestão de Dados e o
acompanhamento através de seus indicadores são vitais para o
monitoramento das atividades.
Os indicadores devem ser adotados conforme as necessidades da empresa.
Além disso, devem ser mensuráveis e obtidos de forma simples através dos
registros das atividades. Em Gestão de Dados os indicadores podem ser
divididos em quatro grandes grupos:
Indicadores de qualidade.
Indicadores de reuso.
Indicadores de tempo.
Indicadores de custo.
Os indicadores de qualidade podem re�etir os valores ou índices de
qualidade dos dados, metadados e também do processo. Entre os
indicadores de qualidade mais usuais podemos destacar: Qualidade dos
dados:
Índices de correções (através de chamados).
Erros em transformações de dados.
Erros em validações automáticas (na entrada de dados).
Erros encontrados a partir da aplicação de regras.
Qualidade dos metadados:
Erros encontrados nas avaliações de modelos de dados (por tipo de
erro, por equipe, etc.).
Índices de erros nas avaliações.
Índices de retrabalho.
Índices de consultorias prévias em modelagem.
Qualidade do processo:
Solicitações incorretas.
Solicitações incompletas.
Pesquisa de satisfação – Atendimento da equipe.
A �gura a seguir demonstra um exemplo de indicador de qualidade dos
metadados.
Figura 12.7 – Exemplo de indicador aplicado em avaliações de modelos de dados
No exemplo anterior, podemos observar um indicador que representa a
ocorrência de erros por tipo nas avaliações de modelos de dados. O grá�co
demonstra valores acumulados no ano. Este indicador é útil para entender
como anda a qualidade das construções e alterações dos modelos de dados
e, a partir daí, buscar soluções que levem a diminuir a incidência de erros
encontrados.
Os indicadores de reuso nos fornecem uma visão do quanto os dados são
reaproveitados na empresa. A reutilização dos dados pode ser transformada
em valor monetário, pois uma entidade de dados reutilizada representa
economia no tempo e no custo do desenvolvimento de aplicações, além de
diminuir o custo de armazenamento dos dados e o número de ativos de TI.
Entre os indicadores de reuso mais comuns podemos destacar:
Entidades de negócio compartilhadas.
Entidades de negócio não compartilhadas.
Técnicas de integração de dados utilizadas.
As tabelas a seguir demonstram exemplos de indicadores de reuso:
Entidade
Quantidade de
aplicações
compartilhadas
Quantidade de
aplicações da
empresa
Percentual
de reuso
LOCALIDADE 80 120 66%
UNIDADE_FEDERATIVA 87 120 73%
FUNCIONARIO 78 120 65%
DEPARTAMENTO 70 120 58%
CLIENTE 30 120 25%
FORNECEDOR 20 120 17%
PRODUTO 18 120 15%
Tabela 12.2 – Exemplo de indicador de reuso – Entidades
Técnica de
integração
utilizada
Quantidade de
aplicações que utilizam
esta técnica
Quantidade de
aplicações da
empresa
Percentual de uso
da técnica de
integração
ETL
(Replicação
controlada)
34 120 28%
Oracle Golden
Gate 30 120 25%
Database Link 6 120 5%
Web services 83 120 69%
Acesso direto
(sinônimos) 36 120 30%
Outros 4 120 3%
Tabela 12. 3 – Exemplo de indicador de reuso – Forma de disponibilização dos
dados
Os indicadores de tempo nos fornecem uma visão do tempo de
atendimento das atividades das equipes de Gestão de Dados e comparam se
os tempos atuais estão dentro do SLA previsto para cada atividade. Entre os
indicadores de tempo mais comuns podemos destacar:
Percentual de tarefas (ou tipos de tarefas) atendidas dentro do tempo
do SLA.
Tempo médio de atendimento por tarefa (ou tipo de tarefa).
Os indicadores de custo nos fornecem uma visão do quanto é gasto nos
atendimentos das atividades das equipes de Gestão de Dados e comparam se
o custo de cada atendimento está aderente ao custo (esforço) do SLA
previsto para cada atividade. Entre os indicadores de tempo mais comuns
podemos destacar:
Percentual de tarefas (ou tipo de tarefas) atendidas dentro do custo do
SLA.
Custo de tarefas de retrabalho.
HH1 lançado em projetos.
Custo médio por tarefa (ou tipo de tarefas).
Tanto os indicadores de tempo como os indicadores de custo são
importantes instrumentos para acompanhar o andamento das equipes de
Gestão de Dados. O tempo costuma ser um importante fator de resistência à
adoção da Gestão de Dados nas empresas. Entretanto, se existe um SLA
de�nido por tipo de atividade e as tarefas vêm sendo atendidas dentro do
prazo estabelecido, não haverá motivos para fomentar esta resistência.
Já o custo pode gerar uma falsa impressão de que a atuação das equipes de
Gestão de Dados gera despesa excessiva para a empresa. Porém, se a
empresa possui parâmetros de custos de�nidos para cada tipo de atividade e
as tarefas atendidas pelas equipes de Gestão de Dados são cobradas dos
projetos solicitantes, não haverá motivos para encarar as equipes de Gestão
de Dados como overheads corporativos, pois a maioria dos custos das
equipes será distribuída nos projetos onde as equipes interagiram. A
próxima boa prática detalhará mais esta questão.
12.7. Repassar os custos aos clientes
Áreas consideradas de apoio ou ligadas à qualidade possuem centros de
custos próprios. Todas as despesas são contabilizadas nesses centros de
custos, sem repassar um centavo qualquer aos demais centros de custo das
áreas para as quais a equipe de Gestão de Dados prestou algum tipo de
trabalho. Esta regra é aplicada principalmente no custo da mão de obra dos
pro�ssionais das equipes e nas licenças dos sowares utilizados pelos
membros das equipes de Gestão de Dados.
Esta prática acaba por tornar a área um overhead corporativo muito caro,
pois, dependendo das especializações, do grau de detalhamento das
atividades e da grandeza das equipes, o custo pode assumir valores muito
altos. Como o retorno das iniciativas de Gestão de Dados ainda é muito
intangível, fatalmente a existência das equipes será questionada.
Empresas não existem somente para gerir os seus dados. Gerir dados é
uma forma de melhorar a con�abilidade e a qualidade dos dados para que as
empresas tenham subsídios na hora de tomar decisões. Esses dados não são
exibidos de forma bruta, ou seja, os dados são visualizados e trabalhados a
partir de aplicações e ferramentas especí�cas (sowares ou sistemas) para
cada área, e não diretamente nos bancos de dados onde estão armazenados.
Portanto, todo o custo referente aos trabalhos operacionais da Gestão de
Dados (necessários para manter esses dados com qualidade) deve ser
repassado às áreas de negócio proprietárias dessas aplicações. A distribuição
desses custos permitirá uma visão mais real sobre os gastos de cada área
especí�ca.
Para os projetos de dados corporativos, onde um mesmo dado é utilizado
por mais dea contratar pro�ssionais fora do
per�l ideal de um Administrador de Dados. Logicamente, esse movimento
não surtiu um bom resultado, pois, além de contratar mal, a rotatividade e a
perda de conhecimento eram muito grandes. Em um curto espaço de
tempo, a função começou a ser desprestigiada no mercado. A segunda
metade desta década �cou marcada pelo êxodo de pro�ssionais quali�cados
na função de Administrador de Dados. Alguns se aposentaram, outros
abandonaram a função e foram tentar a vida em outras funções mais
prestigiadas na época. Com poucos pro�ssionais disponíveis, algumas
empresas tentavam fundir novamente as atividades do AD (Administrador
de Dados) com as atividades do DBA (Administrador de Banco de Dados),
piorando ainda mais o cenário e ocasionando, mais uma vez, o problema de
identidade da função, aparentemente já resolvido na década passada.
Além disso, as pressões por entregas de soware cada vez mais curtas e a
um custo menor também colaboravam para desenvolver várias fontes de
informações não íntegras e redundantes. Geralmente sem fôlego, as equipes
de Administração de Dados já não conseguiam administrar toda essa
desordem.
Os esforços dos quadros da Administração de Dados nas empresas não
eram mais su�cientes para acompanhar o ritmo das solicitações e integrar
de forma planejada as informações que eram demandadas.
No meio de todo esse caos, os sistemas ERPs3 começaram a ser
implantados nas empresas com a promessa de integrar todos os dados e
processos. A princípio, os ERPs solucionariam todos os problemas de
informações redundantes e de quebra ainda diminuiriam o número de
aplicações desenvolvidas e utilizadas pelas áreas de negócio das empresas.
Junto com os ERPs, soluções de CRM4 também eram adotadas com o
propósito de melhorar o gerenciamento das informações de clientes e as
soluções de Business Intelligence para apoiar a tomada de decisões
estratégicas. De forma geral, por estarem sobrecarregadas ou até mesmo
buscando a própria sobrevivência, as equipes de Administração de Dados
não se envolviam com esses tipos de soluções. En�m, o cenário para o �m
da Administração de Dados já estava montado.
Quarto estágio – A Redescoberta da Gestão de Dados (a partir de 2010)
– O tempo passou e as empresas começaram a observar que as promessas de
integração dos dados propostas pelos pacotes ERP das grandes empresas de
TI não foram completamente atingidas. Além disso, vários projetos de
Business Intelligence fracassaram não por falta de recursos, patrocínio ou
questões de capacidade técnica dos times de projeto, mas pela má qualidade
dos dados que eram manipulados no ambiente produtivo.
Ao contrário do que era imaginado na década anterior, em muitas
empresas a adoção dos ERPs não extinguiu o problema de armazenar os
mesmos dados em diversos lugares diferentes – na verdade, a redundância
dos dados ainda persiste em muitas empresas que adotaram esta estratégia.
Na grande maioria das vezes, essas redundâncias não são conhecidas e
também não são controladas. Nesses casos, a única certeza existente sobre os
dados é que há o problema de redundância, porém as formas de resolução
ainda não são totalmente conhecidas.
Com o crescimento desorganizado das empresas motivado por fusões,
aquisições e reestruturações, cada vez mais as áreas de TI �cam distantes das
áreas de negócio nas empresas. Em muitos casos, o conhecimento do
negócio está na cabeça dos analistas funcionais das soluções ERP. Vale
ressaltar que esses pro�ssionais são especializados em processos e não em
dados.
En�m, agora, além de ter dados redundantes e não con�áveis, as empresas
convivem com o problema de não conhecer o acervo de dados existentes.
Este fato ocasiona inúmeros problemas; um dos principais é o fato de a
empresa não ter os dados necessários para uma melhor gestão dos seus
próprios negócios. A falta de alinhamento entre a TI e o negócio está
evidente.
Além disso, o volume de dados processados atualmente é muito maior do
que nas décadas passadas. Grandes players do mercado começam a trabalhar
com o conceito de “Big Data”, onde algumas dezenas de petabytes de dados
são processadas a cada dia.
O movimento contínuo de redução de custos das empresas, alinhado à
necessidade de tomadas de decisões cada vez mais rápidas e consistentes,
trouxe desta vez, de forma mais contundente, a importância do
reconhecimento dos dados como ativo estratégico de qualquer organização.
Contudo, o modelo de trabalho das áreas de Administração de Dados do
passado já não é mais su�ciente para conseguir resolver todos esses
problemas. Na verdade, o problema agora é muito maior: além dos
problemas já apontados, os dados também não são conhecidos e também
não são governados.
Neste cenário, surge a Gestão de Dados com o propósito de ser uma
função mais abrangente que a antiga Administração de Dados, pois esta
última não se limita a atuar na administração/gestão dos metadados dentro
do ciclo de desenvolvimento dos sistemas, e sim em todo o ciclo de vida dos
dados, garantindo uma melhor gestão dos dados e metadados que circulam
nas empresas.
Um dos grandes diferenciais, tido como uma premissa fundamental da
Gestão de Dados, é o reconhecimento de que a responsabilidade pela gestão
dos recursos de dados e informações deve ser compartilhada entre a área de
TI e as demais áreas de negócio das empresas. A falta deste alinhamento
pode ser considerada uma das principais causas para o insucesso.
A �gura a seguir representa o compartilhamento dessa responsabilidade.
Esta premissa será mencionada várias vezes no livro. Seu entendimento e
sua aceitação são fundamentais para o sucesso da adoção da Gestão de
Dados nas empresas.
Figura 2 – Responsabilidade Compartilhada pela Gestão de Dados
A adoção da Gestão de Dados no Brasil ainda é bastante recente, porém a
função já é adotada há mais de uma década nos Estados Unidos e no
Canadá. Algumas empresas no Brasil já começaram com iniciativas para
adotar esta disciplina e os resultados têm sido bastante satisfatórios.
A Gestão de Dados propicia às empresas a possibilidade de realmente
utilizarem informações íntegras, de qualidade e de fácil acesso, formando
um alicerce para que tomem decisões baseadas em dados reais e con�áveis.
Pessoas mal informadas podem correr o risco de ver a Gestão de Dados
como mais um modismo proposto pelos gurus da administração, porém elas
estão enganadas, pois no fundo a Gestão de Dados não propõe nada
revolucionário e novo. Sua proposta é estabelecer uma gestão com
responsabilidades compartilhadas como forma de quebrar paradigmas nas
empresas que estavam acostumadas a destinar pouco tempo para planejar e
sempre ter recursos su�cientes para refazer ou consertar as aplicações que
armazenam e consomem os seus dados.
Parte 1
Conceitos Básicos sobre Gestão de Dados
1. Conceitos Básicos
“O olho vê somente o que a mente está preparada para compreender.”
Henri Bergson
1.1. Dado, informação, conhecimento e sabedoria
Dado, informação, conhecimento e sabedoria constituem a cadeia de evolução de dados e
informações. Quando falamos sobre “dados”, na verdade estamos nos referindo à base da matéria-
prima necessária para conseguir o que todas as empresas desejam: utilizar o conhecimento das
informações para tomar decisões ágeis e corretas.
O amadurecimento de dados e informações é representado através de sua cadeia de evolução. Esta
cadeia estabelece um conceito de maturidade de uso dividido em quatro estágios, sequenciais,
necessários à conquista deste propósito. Como em qualquer estágio, os esforços para alcançar o
amadurecimento devem ser feitos primeiramente nos níveis iniciais e somente depois nos próximos
níveis. Neste caso especí�co, os dados devem ser tratados e reconhecidos primeiro – por esta razão o
nome da disciplina é Gestão de Dados, e não Gestão das Informações ou Gestão do Conhecimento.
A cadeia de evolução de dados e informações representa a transformação gradual e progressiva
sobre o uso de dados e informações no ambiente empresarial. Também serve comouma área, recomenda-se o rateio dos custos pelas áreas que
utilizam esses dados.
Com o repasse dos custos “operacionais”, as equipes de Gestão de Dados
�cariam responsáveis pelos custos referentes às iniciativas de melhoria e
investimento da área de Gestão de Dados. Apesar das melhorias re�etirem
em um futuro próximo no trabalho operacional que é executado, o repasse
desses custos, em um primeiro momento, é muito mais difícil, pois
geralmente essas iniciativas vêm das equipes de Gestão de Dados e não das
demais áreas.
12.8. Nunca acomodar
Um dos principais erros cometidos é parar de buscar a evolução contínua
da adoção da Gestão de Dados na empresa quando a curva de benefícios
alcançados ultrapassa a curva de resistências. A �gura a seguir mostra um
grá�co que acompanha o processo de implantação e evolução da adoção da
Gestão de Dados em uma empresa.
Figura 12.8 – Exemplo de zona de acomodação na implantação da Gestão de
Dados
Podemos observar que a Gestão de Dados foi considerada implantada
quando a diferença de graus entre as curvas diminuiu. O grau dos benefícios
se igualou ao grau de resistência. A partir deste ponto, a diferença entre as
curvas volta a aumentar, porém o grau de benefícios é bem maior que o grau
da resistência, tornando a Gestão de Dados muito mais madura na empresa.
A prática “não acomodar” indica justamente o que foi representado no
grá�co anterior: o aumento dos benefícios da Gestão de Dados e a
diminuição das resistências através do conceito da busca pela melhoria
contínua. Entre as ações mais comuns desta boa prática podemos citar:
Análise e avaliação da situação existente para identi�car áreas para
melhoria.
Estabelecimento dos objetivos para melhoria.
Pesquisa de possíveis soluções para atingir os objetivos.
Avaliação e seleção dessas soluções.
Implementação da solução escolhida.
Medição, veri�cação, análise e avaliação dos resultados da
implementação para determinar se os objetivos foram atendidos.
Apesar de o grá�co mostrar uma constatação simples, várias empresas
optam por não evoluir mais a maturidade da Gestão de Dados assim que a
área é considerada implantada, permanecendo na “zona de acomodação”
por bastante tempo – até ter a sua existência questionada.
12.9. Utilizar metodologia adequada
O termo “metodologia” não tem uma de�nição bem estabelecida, mas �ca
claro o seu objetivo: dar instrumentos para obtenção de métodos e metas.
Adotaremos a seguinte de�nição para uma Metodologia de Gestão de
Dados neste livro: conjunto de documentos que orientam os pro�ssionais
envolvidos com as funções e atividades preconizadas pela disciplina de
Gestão de Dados nas organizações. Entre estes documentos encontramos:
documentação institucional, processos e seus detalhamentos, padrões,
ferramentas de qualidade, documentação de apoio e ferramentas de
comunicação.
Figura 12.9 – Componentes de uma Metodologia de Gestão de Dados
A �gura anterior mostra uma visão mais abrangente dos documentos que
podem ser utilizados em uma Metodologia de Gestão de Dados.
12.9.1. Diretrizes básicas para a construção de uma
Metodologia de Gestão de Dados
As dicas a seguir podem ser aplicadas em qualquer cenário. São
consideradas por mim diretrizes básicas para a adoção de uma Metodologia
de Gestão de Dados. São elas:
A metodologia deve ser abrangente e com adaptações aos diversos
tipos de sistemas da organização, ou seja, deverá prever o
desenvolvimento de sistemas transacionais, sistemas de Business
Intelligence e apoio à decisão, aquisição de dados externos, sistemas
onde os dados não são armazenados em banco de dados, etc.
A metodologia deve ser regulamentadora – deve de�nir o que precisa
ser feito usando padrões e diretrizes.
Os documentos da metodologia devem estar integrados entre si e aos
demais processos de trabalho da organização. Os detalhamentos dos
�uxos de trabalho podem ser feitos através de procedimentos de
trabalho.
A metodologia deve ser orientadora – deve explicar como produzir
mais e melhor, através de boas práticas, manuais e orientações em
geral.
O grau de rigidez e detalhamento da Metodologia de Gestão de Dados
deve ser similar aos graus das outras metodologias adotadas na
empresa.
A metodologia deve ser conhecida por todos. De preferência, deverá
ser mantida e divulgada através de um portal especí�co e/ou soluções
similares.
Guias de corpo de conhecimento consagrados, como o DAMA-
DMBOK® (representado na �gura a seguir), são uma ótima referência
para de�nir e orientar o escopo e o conteúdo da metodologia. Vale
ressaltar que os guias devem ser adotados e customizados de acordo
com as características de cada empresa.
Figura 12.10 – Funções do DAMA-DMBOK®2
Mesmo adotando todas as dicas relacionadas, não saberemos se a
Metodologia de Gestão de Dados estará adequada para a empresa ou se
teremos problemas de percurso durante e após sua adoção. As dicas ajudam,
porém não são su�cientes para garantir o sucesso desta jornada. A
compreensão das características particulares de cada empresa é considerada
fundamental para o sucesso deste trabalho. Em resumo, o que é bom para
uma empresa pode não ser bom para outra.
Durante minha experiência pro�ssional, tive a oportunidade de observar
os cenários de várias empresas, de ambos os portes e de diversos segmentos.
Em todas onde participei de alguma forma na de�nição e/ou alteração da
Metodologia de Gestão de Dados, pude constatar uma única resposta
correta que pôde ser aplicada nos questionamentos mais genéricos, tais
como: “que metodologia adotar?”, “como adotar?” e “quando adotar?”. A
resposta correta, mas não tão esclarecedora para todos esses
questionamentos, sempre foi uma só: “depende, cada caso é um caso”.
Várias áreas de Gestão de Dados tiveram sua existência questionada
simplesmente por adotar o modelo de metodologia igual ao de outras
empresas de sua área de atuação. Provavelmente essas empresas não levaram
em consideração seus próprios cenários e expectativas e, consequentemente,
escolheram uma alternativa de resposta incorreta. A�nal, qual seria a
metodologia adequada para a minha empresa?
12.9.2. Características consideradas na criação de uma
Metodologia de Gestão de Dados
Metodologia adequada não é aquela utilizada por empresa A ou B, muito
menos um conjunto de processos empurrados “goela abaixo” por fornecedor
X ou Y. Uma Metodologia de Gestão de Dados adequada leva sempre em
conta a análise de cinco características particulares de cada empresa:
aspectos organizacionais, cultura, corpo técnico, visão de futuro e
recursos �nanceiros. A �gura a seguir mostra o encadeamento entre as
cinco características: 
Figura 12.11 – Características que devem ser consideradas na elaboração de uma
metodologia
Os aspectos organizacionais correspondem ao posicionamento e à forma
de atuação da área de Gestão de Dados na organização. Para fazer uma
análise deste aspecto, várias perguntas devem ser levadas em consideração:
Qual é o segmento de atuação da organização? Qual é o seu porte? A
organização é pública ou privada?
A área de Gestão de Dados existe (ou será prevista) no organograma da
organização?
Se sim, qual o posicionamento da área de Gestão de Dados no
organograma? Quais seriam os seus clientes?
Em que nível gerencial a Gestão de Dados está situada? A quem a área
está subordinada?
A maioria dos dados que trafegam na empresa é criada dentro da
própria empresa ou é adquirida no mercado?
As aplicações que criam e manipulam os dados que trafegam na
empresa são desenvolvidas dentro ou fora da empresa?
De forma geral, área de Gestão de Dados que não está ligada diretamente
ao departamento de TI costuma ter mais autonomia para suas ações, porém
�ca distanciada de onde os dados são projetados (TI).
Área de Gestão de Dados ligada diretamente ao departamento de TI
costuma ter menos autonomia nas ações e sofre pressões elevadas para
diminuir os parâmetros de qualidade, principalmente se estiver dentro do
departamento de desenvolvimento – contudo, �ca mais perto de onde os
dados são projetados.modelo para
descobrir em que nível dessa cadeia as informações de mais alto valor estratégico são utilizadas,
possibilitando, desta forma, estabelecer ações para melhorar o nível da maturidade de dados e
informações da empresa.
Os dados são a base de todo o processo para geração da sabedoria empresarial e o primeiro nível
de estágio a ser atingido. Eles representam fatos através de um conjunto de caracteres primitivos e
isolados, geralmente representados através de textos, números, imagens, sons ou vídeos. Os dados
não possuem qualquer signi�cado relevante dentro de um contexto de negócio (dado sem contexto).
Os metadados representam os signi�cados dos dados. Estes signi�cados correspondem tanto ao
conteúdo técnico do dado, obtido através das informações sobre estrutura, formato, tamanho e
restrições (metadados técnicos), como a informações sobre de�nições, conceitos, relevância e regras
de negócio dos dados envolvidos (metadados de negócio).
Outra de�nição bastante comum e mais simples encontrada na literatura sobre metadados é o
famoso clichê: “dados sobre os dados”. De forma geral, os metadados ainda são criados e mantidos
pela área de TI. O gerenciamento dos metadados contribui diretamente para a melhoria da
qualidade das informações e para o amadurecimento da cadeia de evolução dos dados.
As informações correspondem aos dados processados com algum signi�cado e são geradas e
obtidas nos sistemas de processamento de transação e sistemas de apoio à decisão, reduzindo a
incerteza sobre alguma coisa, estado ou evento. Quando os metadados são utilizados para leitura e
interpretação dos dados, a cadeia de evolução do dado já mudou de estágio, ou seja, já está no nível
da informação.
O conhecimento corresponde ao processamento das informações com signi�cados, premissas,
padrões de comportamento, tendências e valores agregados através de conjuntos de regras de
manipulação e características dessas informações. São o subsídio para soluções de problemas e
tomadas de decisão. Atualmente, é impossível imaginar a evolução para este estágio da cadeia sem
os sistemas de apoio à decisão e as aplicações de inteligência analítica.
A sabedoria é a utilização do conhecimento com e�cácia e e�ciência. Do que adianta possuir o
“conhecimento” se não utilizamos este ativo corretamente? Apesar das aplicações de inteligência
analítica já serem uma realidade dentro do mercado, fornecendo condições para a empresa atingir o
estágio anterior, muitas organizações que possuem estes subsídios desejam a “sabedoria”, mas não a
conseguem. Parte deste fracasso está na con�abilidade dos dados, que não foram bem geridos no
decorrer da evolução da cadeia. Outra parte está na falta de habilidade dos pro�ssionais em extrair
as informações e utilizá-las de forma vantajosa.
Algumas referências sobre Gestão de Dados, incluindo o guia DAMA-DMBOK®, não descrevem e
também não reconhecem a sabedoria como o último estágio desta cadeia, justamente pelo fato dela
depender em grande parte da competência humana para atingir este estágio. Por outro lado,
empresas inovadoras, já adaptadas às novas realidades e tendências do mercado como o “Big Data” e
o papel do “Cientista de Dados”, já reconhecem e buscam atuar neste último nível da cadeia de
evolução dos dados.
A �gura a seguir mostra a cadeia de evolução do dado e um exemplo didático de sua utilização.
Figura 1.1 – Cadeia de Evolução dos Dados e Informações
Tomemos como base uma aplicação �nanceira onde uma instituição deseja manter informações
sobre a saúde �nanceira de seus clientes. Ao acompanharmos a evolução demonstrada na �gura
anterior, veremos que:
1. O dado (–15000) é um número qualquer sem signi�cado algum.
2. Ao consultar seu metadado, descobrimos que esta informação corresponde a um saldo
negativo de R$ 15.000,00. Apesar de o exemplo mencionar algo com grau de di�culdade
bastante simples, grande parte das empresas ainda está situada neste estágio da cadeia de
evolução do dado.
3. De acordo com os critérios de crédito da instituição (histórico, renda, comprometimento,
garantias, reservas �nanceiras, produtos adquiridos, etc.), chegamos à conclusão de que o
cliente está endividado. Qualquer descuido ou acontecimento negativo na vida do cliente
proporcionará uma possível inadimplência. Esse tipo de conhecimento é obtido através de
aplicações com inteligência incorporada nas soluções. O conhecimento interfere diretamente
na política de crédito adotada por esta e outras instituições.
4. Para eliminar as dívidas e, consequentemente, manter o cliente consumindo mais produtos
�nanceiros da instituição, a empresa deve utilizar a sabedoria para não apenas propor soluções
que ajudem ao cliente, mas que também agreguem valor às suas vendas e a mantenham em
posição de destaque no mercado.
Para isso é fundamental conhecimento não só sobre os dados do cliente, mas também informações
gerais sobre o conjunto de demais clientes acerca de: comportamento e renda, tendências de
consumo, análises criteriosas dos riscos, cenário econômico nacional e mundial, entre outras
informações que servirão de subsídios para que pessoas, sistemas especialistas, ferramentas
estatísticas, ou ambos, utilizem o conhecimento dessas informações para tomar decisões cada vez
mais ágeis e corretas. Vale ressaltar, que o nível “sabedoria” é desejado pela maioria das empresas,
porém poucas se encontram nesse estágio de maturidade e uso.
Conforme mencionado anteriormente, um per�l emergente no mercado, o “Cientista de Dados”,
tem como principal responsabilidade analisar grandes volumes de dados com o propósito de
descobrir novas tendências e novos conjuntos de informações e combinações que agreguem valor às
empresas.
Com o apoio de novas ferramentas e algoritmos, novas informações são descobertas pelos
Cientistas de Dados. O conjunto destas novas informações e tendências forma uma enorme
vantagem competitiva da empresa em relação aos seus demais concorrentes, pois a inovação é
incluída como algo permanente em suas ações, tornando a organização reconhecida no mercado
pela originalidade e rapidez na tomada de decisões.
1.2. Ciclo de vida dos dados
Todo e qualquer ativo possui um ciclo de vida. Se tomarmos como exemplo as pessoas, um dos
ativos mais importantes das organizações, nós poderemos observar o seguinte ciclo de vida dentro
de uma empresa: pessoas tomam conhecimento das vagas disponíveis, se candidatam a essas vagas,
são selecionadas, admitidas, treinadas, desenvolvem competências, podem ser promovidas, cedidas,
transferidas, afastadas, licenciadas, colocadas em disponibilidade e, por �m, encerram o seu ciclo
pedindo desligamento, sendo demitidas ou então aposentadas.
Com os dados não é diferente: tal como as pessoas e os demais ativos, possuem um ciclo de vida
que precisa ser gerenciado. Segundo o guia DAMA-DMBOK®, no curso da sua vida o dado pode ser:
extraído, exportado, importado, migrado, validado, editado, atualizado, limpo, transformado,
convertido, integrado, segregado, agregado, referenciado, revisado, relatado, analisado, garimpado,
salvo, recuperado, arquivado e restaurado antes de eventualmente ser eliminado.
Na verdade, o ciclo de vida do dado possui uma relação muito forte com o ciclo de vida do
desenvolvimento de sistemas, pois, geralmente, são iniciados no mesmo momento.
Atualmente grande parte dos pro�ssionais de TI ainda tem uma visão equivocada de que o ciclo de
vida dos dados é igual ao ciclo de vida do desenvolvimento de sistemas. Ou seja, após as entregas
das aplicações, o dado seria incluído pelo usuário nas aplicações entregues e a partir daí o ciclo seria
encerrado, porém o ciclo de vida dos dados não termina aqui.
Esta visão é equivocada, pois, depois de entregues, os dados começam a mudar de status e passam
a ser efetivamente utilizados. Somente a partir daí começam a agregar valor ao negócio. En�m, o
ciclo de vida do dado é mais mutável e duradouro, sendo mantido após o encerramento do ciclo de
desenvolvimento de sistemas. Vale ressaltar que sistemas e aplicações sãoalterados e às vezes
desativados, porém os dados geralmente não sofrem desgastes.
A falta de integração entre a TI e o negócio corroborou para manter esta visão equivocada dos dois
ciclos.
De forma geral, o ciclo de vida do desenvolvimento de sistemas descreve as etapas de um projeto
de construção ou manutenção de um sistema/aplicação que irá fornecer subsídios para
operar/utilizar os dados, enquanto o ciclo de vida dos dados descreve os processos executados para
gerenciar os ativos de dados.
A �gura a seguir descreve a relação entre os dois ciclos: 
Figura 1.2 – Ciclo de vida do dado x ciclo de vida do desenvolvimento de aplicações Todos os estágios dos dois
ciclos de vida possuem custos e riscos associados. Entretanto, o retorno sobre o investimento da criação do dado só
é obtido após a sua real utilização no ambiente produtivo.
A gestão dos ativos de dados, através de seu ciclo de vida, não é algo exclusivo dos dados
estruturados, geralmente armazenados em bancos de dados ou arquivos planos.
Ela também ocorre com os dados não estruturados, armazenados em planilhas, imagens, sons e
áudio. Estima-se que 80% dos dados das organizações estejam armazenados em formas não
estruturadas. Muitos desses dados são volumosos e requerem atenção especial na sua gestão.
1.3. Características de qualidade desejadas para os dados e
metadados
O simples fato de gerir e governar dados não é su�ciente para garantir o sucesso e o retorno
�nanceiro. Informações que geram resultado são obtidas através de dados de qualidade.
As publicações que tratam da função “Qualidade de Dados” são muitas, porém não há um
consenso entre os vários autores sobre quais são as dimensões de qualidade desejadas para os dados.
Alguns autores preferem citar um número reduzido de dimensões que na verdade agrupam um
conjunto de dimensões menores; já outros preferem citar várias dimensões especializadas divididas
em tipos.
O guia DAMA-DMBOK® prevê onze dimensões de Qualidade de Dados que devem ser atingidas
para considerar um dado de qualidade. As dimensões recomendadas pelo guia são: acuracidade,
completude, consistência, valor corrente, precisão, privacidade, razoabilidade, integridade
referencial, em tempo adequado, unicidade e validade.
Vale ressaltar que, através de suas dimensões, todas as publicações e guias criam conceitos macro
de qualidade dos dados que são muito semelhantes entre si.
Neste livro iremos adotar uma abordagem mais simples, com poucas dimensões, porém não só
orientada aos dados, mas também aos metadados, visto que a qualidade dos dados começa a partir
do seu planejamento e especi�cação, fases onde os metadados são criados e implementados.
Seguem as dimensões de qualidade dos dados e metadados adotados neste livro:
Aderência ao negócio: indica que o dado ou metadado está aderente em sua totalidade (por
completo) aos requisitos de informação e regras de negócio da empresa.
Unicidade: indica que o dado ou metadado é único e exclusivo dentro da empresa. Não há
repetição de conteúdo e conceitos. Ou seja, não existem outros dados ou metadados iguais
dentro da empresa. Quando esta dimensão é violada, ocorre a redundância.
Integridade: indica que o dado atende a todas as restrições de integridade necessárias para que
possa ser considerado um dado con�ável. As restrições de integridade permitem a
representação das regras de negócio, que, se não forem respeitadas, irão prejudicar a
con�abilidade dos dados. As restrições de integridade são de�nidas nos metadados.
Con�abilidade: indica que o dado é atual, correto (sem erros) e pode ser utilizado sem afetar
negativamente qualquer tipo de uso. Não existem erros de transformação, disponibilização e
até mesmo de digitação.
Manutenibilidade: indica baixo esforço na manutenção dos dados e metadados quando há
uma solicitação de mudança que irá afetá-los. Metadados especi�cados em modelos de dados
de forma �exível costumam ter baixo custo de manutenção – em alguns casos, dependendo da
mudança, o esforço é feito somente nas aplicações, sem necessidade de alteração no modelo de
dados ou dados das aplicações.
Performance: indica que o tempo de resposta e acesso aos dados é satisfatório para os
requisitos de uso.
Legibilidade: fácil entendimento, compreensão e utilização dos dados e metadados. Modelos
de dados com nomes adequados acarretam em metadados legíveis, facilitando a construção das
aplicações que irão gerar as informações e, consequentemente, gerando dados de qualidade.
Disponibilidade: indica que o dado ou metadado é conhecido e está disponível, no momento
necessário, para quem tem o devido acesso. Envolve conceitos de governança e segurança dos
dados e informações.
1.4. Big Data
Nos últimos anos, grandes fabricantes de soluções de TI têm debatido com uma frequência muito
alta a respeito do termo “Big Data”. Vários artigos e reportagens têm sido publicados ultimamente.
Muitos desses artigos foram patrocinados por grandes empresas de soluções de TI. A grande
maioria delas já possui produtos e soluções de consultoria à disposição em seus portfólios.
As de�nições sobre “Big Data” têm sido aprimoradas com o tempo e, no decorrer do tempo, alguns
mitos são extintos e outros novos são criados.
Um dos primeiros mitos que ainda persiste no mercado é o fato de que “Big Data” só se aplica a
dados não estruturados. Outro mito, ou percepção geral, é de que a maioria das empresas ainda não
está preparada ou não possui necessidades de trabalhar com este conceito.
Mas a�nal o que é “Big Data”? De forma geral, quando falamos de “Big Data” estamos nos
referindo ao crescimento exponencial dos dados, à utilização e ao armazenamento de dados em
grandes volumes que desa�am os métodos convencionais de análise e gestão dos dados. Ou seja, é
um volume enorme de dados que, por vezes, dependendo das características dos dados e das
empresas, devem ser armazenados e processados por mecanismos diferentes do que estávamos
habituados.
Vale destacar que os dados podem estar armazenados em formas estruturadas ou não.
Atualmente nossa sociedade gera dezenas de petabytes de informações por dia dos mais variados
tipos, entre elas:
Informações comuns, como cadastros de clientes, fornecedores, funcionários, produtos,
marketing e vendas.
Informações sobre dados manipulados nos sistemas das empresas, tais como movimentações
bancárias, transações de venda e compra de conteúdo, produtos e serviços.
Dados das mídias sociais como Facebook, LinkedIn e Instagram.
Dados de sensores e monitoramentos temporais.
Dados oriundos de satélites e aplicações geoespaciais.
Dados em formato multimídia, como imagens, sons e vídeos.
Um único arquivo de vídeo ou imagem é in�nitamente maior em bytes do que uma página simples
de texto. Capturar, manusear e analisar este imenso volume de dados é um grande desa�o. Adicione
a isso o �uxo constante de novos dados em mudança e os desa�os se tornam maiores. Entretanto,
com esses desa�os vêm grandes recompensas para as empresas que são capazes de explorar os dados
de forma mais e�caz do que seus concorrentes. Agora as empresas não se contentam apenas em
saber apenas o que foi vendido, consumido, comprado. A concorrência e a dinâmica dos negócios
trazem cada vez mais a necessidade de entender o comportamento, as tendências, as previsões e as
incertezas acerca dos dados dos clientes, fornecedores, parceiros e demais envolvidos em suas
cadeias.
Um dos exemplos clássicos e mais ilustrativos do uso do “Big Data” é o da empresa americana
Target, que investiu no rastreamento das intenções de consumo de seus clientes. Certa vez, o pai de
uma adolescente entrou furioso em uma loja da rede nos Estados Unidos, reclamou com o gerente
que sua �lha adolescente tinha recebido pelos correios cupons promocionais de produtos para
gestantes e que a empresa estava estimulando a sua �lha a pensar em engravidar. Imediatamente o
gerente da loja pediu desculpas, porém, ao retornar ao cliente uma semana depois, o gerente da loja
foi comunicado pelo próprio pai da adolescente que aTarget estava correta e sua �lha adolescente já
estava grávida. Ele apenas não sabia ainda da novidade naquela ocasião. Outras histórias como essa
são comuns quando falamos sobre “Big Data”, porém sempre me lembro das seguintes questões: a
privacidade da cliente foi respeitada? Mesmo com a informação correta, a empresa poderia sofrer
alguma sanção legal? Em alguns casos, o excesso de informação não pode ser uma “desvantagem”
competitiva em vez de ser uma vantagem? Muitas das respostas para essas questões ainda não são
unânimes. Para tanto, o mercado tem investido na formação de pro�ssionais dedicados a terem
essas respostas. Matemáticos, estatísticos e advogados têm atuado em conjunto para
proporcionarem as respostas mais unânimes possíveis.
As tecnologias que sustentam “Big Data” podem ser analisadas sob duas visões: a primeira
envolvida com as análises de dados de negócio, geralmente em ambientes de dados analíticos; a
segunda com as tecnologias de infraestrutura, que armazenam e processam os petabytes1 de dados.
Neste aspecto, destacam-se os bancos de dados NoSQL2. “Big Data” é a comprovação prática de que
o enorme volume de dados gerados diariamente excede a capacidade das tecnologias atuais,
geralmente baseadas em bancos de dados relacionais.
Devemos ter em mente que “Big Data” envolve uma grande mudança na forma de trabalho das
empresas e não somente uma pequena mudança na adoção de novas ferramentas ou tecnologias. As
mudanças são amplas e envolvem aspectos legais, de privacidade e principalmente de Governança
de Dados. Neste ponto, a adoção da Gestão de Dados é um importante instrumento para preparar as
empresas para o fenômeno “Big Data”.
1.4.1. Como caracterizar o Big Data?
Atualmente, os desa�os do “Big Data” podem ser resumidos em cinco palavras ou dimensões,
todas com as mesmas iniciais, mais conhecidas como as cinco dimensões “V” do “Big Data”. São
elas: volume, velocidade, variedade, veracidade e valor.
Vale ressaltar que as de�nições sobre “Big Data” vêm sendo aprimoradas com o decorrer do tempo.
Quando iniciei o desenvolvimento do projeto deste livro, o mercado entendia como desa�os apenas
três dimensões (volume, velocidade e variedade). Atualmente já são cinco. Portanto, não se assuste
se, ao ler este livro, outros autores estiverem falando de uma ou duas dimensões a mais na de�nição
deste conceito.
A imagem a seguir demonstra todas as cinco dimensões atuais do “Big Data”.
Figura 1.3 – Dimensões atuais do “Big Data”
1.4.2. Volume
O volume é o primeiro desa�o que as organizações enfrentam ao lidar com o “Big Data”.
Corresponde à quantidade de dados armazenados, representados através do tamanho e da
quantidade de registros/informações que um banco de dados possui. Quanto maior o volume,
maiores os esforços na gestão dos dados.
1.4.3. Velocidade
A velocidade é o desa�o de lidar com o tempo rápido de resposta com que os novos dados são
criados e os dados existentes, modi�cados. Esses dados devem estar disponíveis imediatamente para
operações de pesquisa e análise dos dados. São os dados em ação.
1.4.4. Variedade
A variedade consiste nas implementações de dados que requerem tratamento de vários formatos e
tipos, incluindo dados estruturados e não estruturados. Os bancos de dados devem ser capazes de
analisar todos estes tipos de dados e fundi-los para produzir resultados de pesquisa e análise que
não poderiam ser alcançados anteriormente. São os dados em múltiplas formas e representações.
1.4.5. Veracidade
A veracidade consiste no grau de incerteza e inconsistência dos dados devido às ambiguidades, à
baixa qualidade e à completeza dos dados. Representa a con�abilidade dos dados.
1.4.6. Valor
O valor corresponde ao retorno, �nanceiro ou não, que um determinado conjunto de dados
fornece à empresa. Atualmente, boa parte dos dados considerados “Big Data” são redundantes,
incompletos ou simplesmente não agregam valor ao negócio da empresa. Se a empresa consegue
valorar os seus conjuntos de dados, ela consegue focar os esforços na gestão dos dados que dão
maior retorno a ela. “Big Data” só faz sentido se o valor da análise dos dados compensar o custo de
sua coleta, armazenamento e processamento.
1.5. Considerações finais sobre Big Data
“Big Data” promete ser uma realidade nas empresas brasileiras. Seu potencial ainda não é
totalmente reconhecido, porém já vemos sinais claros desta importância quando lemos diversos
artigos de empresas e organizações internacionais sobre a adoção do “Big Data”.
No Brasil, muito tem se falado sobre o assunto, principalmente os vendedores de soluções, porém
os casos reais de utilização ainda são poucos. Estima-se que esta onda de crescimento chegue
rapidamente no Brasil, porém tanto as empresas quanto os pro�ssionais ainda não estão totalmente
preparados para utilizar o melhor da tecnologia.
A promessa de crescimento da tecnologia do “Big Data” e a falta de preparo dos pro�ssionais não
são exclusividade do Brasil. O Gartner prevê que, até 2015, a procura por recursos humanos
relacionados com o assunto “Big Data” levará à criação de 4,4 milhões de empregos em todo o
mundo, porém apenas um terço dos postos de trabalho será preenchido.
2. Gestão de Dados
“Um ser inteligente traz consigo os meios necessários para superar-se a si mesmo.”
Henri Bergson
2.1. Gestão de Dados – Definições
A Gestão de Dados (Data Management) é também conhecida no mercado por diversos termos:
Gestão da Informação (Information Management – IM).
Gestão da Informação Empresarial (Enterprise Information Management – EIM).
Gestão dos Dados Empresariais (Enterprise Data Management – EDM).
Como os termos são diversos, as de�nições também variam. Particularmente, pre�ro utilizar as
duas de�nições a seguir: “Gestão de Dados é a disciplina responsável por de�nir, planejar,
implantar e executar estratégias, procedimentos e práticas necessárias para gerenciar de forma
efetiva os recursos de dados e informações das organizações, incluindo planos para sua
de�nição, padronização, organização, proteção e utilização.”3
“Gestão de Dados é a função na organização que cuida do planejamento, controle e entrega dos
ativos de dados e de informação. Esta função inclui: as disciplinas do desenvolvimento, execução e
supervisão de planos, políticas, programas, projetos, processos, práticas e procedimentos que
controlam, protegem, distribuem e aperfeiçoam o valor dos ativos de dados e informações.”4
Em suma, a disciplina Gestão de Dados é responsável por zelar da melhor forma possível, através
de seus pro�ssionais de tecnologia e também de negócios, os dados e metadados das organizações,
fazendo com que sejam aderentes às necessidades do negócio, únicos, íntegros, con�áveis,
manuteníveis, conhecidos, performáticos, legíveis e disponíveis a quem realmente precisa ter o
acesso.
Os dados �uem através da infraestrutura da TI e seus sistemas de gerenciamento e processamento
de informações. Os pro�ssionais da área de negócios consomem, alimentam e identi�cam novas
necessidades de informações. Portanto, nada mais apropriado que a responsabilidade por essa
gestão ser compartilhada entre a TI e o negócio.
Apoiada por organizações internacionais voltadas para o desenvolvimento dos assuntos ligados à
Gestão de Dados, tais como o Data Governance Institute e a DAMA® – Data Management
International, aos poucos a Gestão de Dados vem surgindo no mercado brasileiro de forma muito
mais abrangente, englobando funções anteriormente esquecidas ou mal gerenciadas pelas
organizações.
O escopo de atuação da disciplina “Gestão de Dados” e a escala de sua implementação nas
empresas variam amplamente de acordo com o tamanho, os meios e a experiência das organizações.
Por outro lado, a principal intenção da adoção da Gestão de Dados nas empresas geralmente é a
mesma: fornecer mecanismos para utilizar o conhecimento das informações para tomar decisões
ágeis e corretas.
A Gestão de Dados é importante para as organizações independentemente do seu tamanho, área
de atuação e �nalidade.
2.2. Princípiosque orientam a Gestão de Dados
O guia DAMA-DMBOK® estabelece cinco princípios básicos que orientam a adoção da Gestão de
Dados nas organizações. O conjunto desses princípios estabelece uma �loso�a de trabalho que deve
sempre ser levada em consideração pelos pro�ssionais que atuam nesta área.
Os princípios estabelecidos pelo guia DAMA-DMBOK® são os seguintes:
Dados e informações são ativos valiosos das organizações.
Como todo ativo, os dados devem ser gerenciados, assegurando qualidade adequada,
segurança, integridade, proteção, disponibilidade, compreensão e uso efetivo.
A responsabilidade da Gestão de Dados é compartilhada entre os Gestores de Dados de
Negócio e os pro�ssionais de Gestão de Dados de Tecnologia.
Gestão de Dados é uma disciplina de negócios e um conjunto de funções relacionadas.
Gestão de Dados é uma pro�ssão emergente e em amadurecimento.
2.3. Principais funções que compõem a disciplina Gestão de
Dados
As funções de Gestão de Dados são especialidades de trabalho especí�cas ligadas de forma
integrada com o propósito de efetivar por completo o gerenciamento de dados e informações.
A versão atual do guia DAMA-DMBOK® estabelece dez funções primárias:
Governança de Dados: função que representa o exercício da autoridade e o controle de
estratégias, políticas, regras, procedimentos, papéis e atividades envolvidos com os ativos de
dados. A Governança de Dados é considerada a função central do framework e in�uencia todas
as demais funções do guia DAMA-DMBOK®.
Gestão da Arquitetura de Dados: função responsável por de�nir as necessidades de dados
(geralmente corporativos) da empresa. A função também é responsável por criar e manter a
Arquitetura Corporativa de Dados de acordo com os objetivos estratégicos da empresa.
Gestão do Desenvolvimento dos Dados: função que representa as atividades de dados dentro
do ciclo de desenvolvimento de sistemas, tais como: Modelagem de Dados (incluindo as
avaliações em modelos de dados), análise de requisitos de dados, projeto de banco de dados,
implantação e manutenção dos bancos de dados.
Gestão de Operação de Dados: função responsável por manter armazenados os dados ao
longo do seu ciclo de vida após a criação das estruturas para este propósito. O ciclo se inicia na
criação e/ou aquisição dos dados e vai até o arquivamento �nal ou a sua eliminação.
Gestão da Segurança dos Dados: função responsável por de�nir e manter as políticas de
segurança e procedimentos a �m de prover a adequada autenticação, utilização, acesso e
auditoria de dados.
Gestão de Dados Mestres e Dados de Referência: função responsável por de�nir e controlar
atividades para garantir a consistência e disponibilização de visões únicas dos dados mestres e
de referência da empresa.
Gestão de Data Warehousing e Business Intelligence: função responsável por de�nir e
controlar processos para prover dados de suporte à decisão, geralmente disponibilizados em
aplicações analíticas.
Gestão da Documentação e Conteúdo: função dedicada a planejar, implementar e controlar
atividades para armazenar, proteger e acessar os dados não estruturados da empresa.
Gestão de Metadados: função responsável por gerir e armazenar os metadados da empresa,
além de viabilizar formas de acesso.
Gestão da Qualidade dos Dados: função dedicada à gestão das atividades para aplicação de
técnicas de Qualidade de Dados com o propósito de medir, avaliar, melhorar e garantir a
qualidade dos dados da empresa.
A próxima versão do guia DAMA-DMBOK® já prevê a inclusão de mais uma função em seu
framework. Trata-se da função de Integração de Dados. Além disso, outras funções serão
renomeadas para manter um melhor alinhamento com as atividades e os conceitos adotados pelo
mercado, como o caso da função “Gestão do Desenvolvimento dos Dados”, que será renomeada para
“Modelagem de Dados e Projeto”, e também a função “Gestão de Operação de Dados”, que será
renomeada para “Armazenamento de Dados”.
A �gura a seguir demonstra as novas funções da próxima versão do guia DAMA-DMBOK®.
Segundo a DAMA International, a previsão da divulgação completa da nova versão do guia é o
segundo quadrimestre de 20135.
Figura 2.1 – Novas funções do Guia DAMA-DMBOK® – Versão 2
A função Integração dos Dados é nova, por esta razão está representada na �gura com fundos
claros. Já as funções Modelagem de Dados e Projeto e Armazenamento dos Dados terão seus nomes
e escopo alterados.
Além das funções do DAMA-DMBOK® mencionadas na �gura, também considero importantes
outros conceitos que serão considerados como função de Gestão de Dados neste livro:
Qualidade do Processo da Gestão de Dados: por trás de todo o esforço envolvendo a Gestão e
a Governança de Dados existem processos de trabalho para suportar tais atividades. O
monitoramento desses processos, com o intuito de ter uma melhoria contínua na Gestão dos
Dados, é fundamental para garantir a existência da disciplina na empresa, identi�car e resolver
possíveis problemas, elevar a maturidade e reconhecer a área como um importante
instrumento de apoio à estratégia da empresa.
Comunicação: a comunicação está entre os principais motivos de sucesso ou fracasso nas
iniciativas. Ela não serve apenas para divulgarmos e coletarmos informações. Serve também
para veri�carmos se algo �cou claro e foi entendido pelo receptor da informação. Para isso,
existem técnicas e boas práticas que, em conjunto, ajudam a melhorar a comunicação na
empresa, tornando-se um fator de sucesso nas iniciativas de Gestão de Dados.
Desenvolvimento Pro�ssional: a disciplina propõe novos per�s que, até então, eram
desconhecidos no mercado de trabalho brasileiro. A capacitação contínua, através de
conhecimentos adquiridos em artigos, eventos, congressos, cursos, certi�cações e a�ns, é
fundamental para amadurecer a pro�ssão do Gestor de Dados no Brasil.
Todos esses conceitos estão inclusos no guia DAMA-DMBOK®, porém, para �ns didáticos, serão
tratados como funções neste livro.
A �gura a seguir mostra o conjunto de funções que serão mencionadas no conteúdo deste livro.
Figura 2.2 – Funções de Gestão de Dados na visão do autor
Esta �gura representa uma casa onde a base é um alicerce dedicado à função de Arquitetura de
Dados. Uma boa Arquitetura de Dados é a base necessária para o sustento de qualquer iniciativa de
Gestão de Dados, pois aqui estarão representadas as principais entidades que serão compartilhadas
entre as áreas de negócio. Tudo isto alinhado à estratégia, à Cadeia de Valor e aos macroprocessos
adotados pela empresa.
Já o telhado desta casa é representado pela Governança de Dados. Esta função estabelece as “regras
do jogo” e dá a proteção e o reconhecimento necessários ao funcionamento das demais funções.
As funções coloridas em caixas mais claras são cobertas pela versão atual do guia DAMA-
DMBOK®. Já as funções coloridas com as caixas mais escuras são abordadas nas boas práticas da
Gestão de Dados Moderna. Conforme mencionado anteriormente, a função “Integração de Dados”
(não colorida) será incluída na nova versão do guia DAMA-DMBOK®.
Todas essas funções serão discutidas mais adiante, sendo que algumas terão capítulos especí�cos e
outras não.
As funções Governança de Dados, Arquitetura de Dados, Modelagem de Dados, Gestão de Dados
Mestres e Qualidade de Dados estão contidas no guia DAMA-DMBOK® e serão mais bem
detalhadas em capítulos especí�cos.
As funções Qualidade do Processo e Comunicação serão detalhadas dentro do conteúdo dos
capítulos sobre a Gestão de Dados Moderna. Já o Desenvolvimento Pro�ssional será tratado no
último capítulo.
2.4. Principais ganhos na adoção da Gestão de Dados
Os ganhos são muitos, alguns intangíveis, variam a cada empresa e, provavelmente, se mencionasse
todos os ganhos possíveis, eles renderiam o espaço de vários capítulos deste livro.
O levantamento desses ganhos de acordo com a realidade de cada empresa e a sua transformação
em valores monetários é importante, pois a partir desta análise as atividades podem ser iniciadas ou
não.
De forma geral, os executivos