1. Plano Geral de Governança de Dados
Esse documento visa definir um planejamento com o foco de atuação para a total
efetividade das melhorias necessárias, visando amplamente a reestruturação adequada
no STI­UFF, a partir do formato existente da área de dados (Banco de Dados Oracle,
MySQL) assim como seu cenário futuro (Oracle, mysql, NoSQL, Big Data, etc). A figura 1
representa o Modelo de Governança que está sendo aplicado à área de dados do STI.
Figura 1. Representação da Estrutura de Governança de Dados.
Cada uma das áreas envolvidas na Figura 1, representa de forma específica uma
área de concentração e suas competências relacionadas. Governança de Dados é
responsável por instituir e aplicar as políticas de trabalho definidas, assim como
implementar estratégias adequadas, sobretudo quanto à visão institucional das
informações e dados. Serviços é a área de atuação referente ao trabalho administrativo e
operacional das informações e dados, principalmente quanto aos servicos e sistemas de
apoio à instituição. Inovação é a área que visa concentrar esforços de forma contínua à
pesquisa, objetivando à melhoria, desde que estas sejam consideradas necessárias em
nível de governança e serviços.Visando definir cada um dos pontos principais
demostrados na Figura 1, cada um destes serão descritos nos itens a seguir.

2. 1. Governança de Dados
Segundo o DAMA­DMBOK Functional Framework, Governança de dados (GD) tem a
definição: “The exercise of authority, control and shared decision­making (planning,
monitoring and enforcement) over the management of data assets.”. A partir desta
definição, pode­se compreender que GD possui em essência uma abordagem de
planejamento, partindo de um contexto em alto nível até o controle estabelecido e
necessário quanto à gestão de dados. Adaptando esse conceito ao nosso cenário de
trabalho, tem­se uma representação conforme a Figura 1.
Figura 1. Modelo de Governança de Dados.
● Política de Governança de Dados ­ Essa área terá como objetivos a definição,
aprovação e comunicação das decisões quanto às estratégias, políticas, padrões,
métricas, arquitetura e procedimentos no que tange aos dados da instituição.
● Manutenibilidade ­ Todo o cenário de dados em uso, deve ser condicionado de
forma cíclica a manter­se íntegro, fidedigno e funcional, quanto ao Plano Geral de
Governança de Dados e às políticas de uso, gestão e acesso de dados.
● Integração (MDM) ­ Atualmente existe um modelo de dados, pertencente à
aplicação do IDUFF que além de ser o modelo de dados da aplicação, também
possui a finalidade de unidade informacional dos dados da instituição, onde vários
serviços obtém informações institucionais a partir deste, representando de forma
rudimentar um tipo de gerenciamento de dados mestres (MDM). Sobretudo,
conforme houverem avanços na implantação do Plano Geral de Governança de
Dados, esse cenário secundário de unidade informacional que o modelo de dados

3. do IDUFF também possui, deverá ser consolidado, e até mesmo transcrito ao
formato MDM, visando principalmente coerência com o padrão definido conforme
o DAMA­DMBOK.
● Estratégia e Utilização ­ Deverão ser implementadas estratégias que atendam às
necessidades da instituição e que forneçam um cenário adequado de utilização
em tudo que refere­se ao parque de dados da instituição. O Plano Geral de
Governança de Dados visa inteiramente atender o cenário do parque de dados.
● Gestão dos Bancos de Dados e Repositórios ­ Os dirétórios que possuem
informações e dados importantes, como por exemplo, um repositório onde estejam
armazenadas todas as dissertações de mestrado e teses de doutorado da
instituição é um exemplo fiel de diretório que necessite de uma gestão de
repositório. Já na perspectiva purista de banco de dados, a gestão dos bancos de
dados deve­se principalmente manter um elo funcional e estrutural quanto ao
modelo de dados, estratégia de backup/restore e até mesmo acesso.
● Situação atual ­ Existem aplicações que obtém dados de bancos de dados
MySQL e Oracle, distribuídos em ambientes Ubuntu e RedHat, com versões
diversas.
Conforme uma unidade organizacional, a Governança de dados tem o nível de tomada de
decisões, visando trazer pontos até então isolados no contexto de dados à tona de forma
geral, para que quando necessário, aplicação e uso dos dados sejam revistos e até
repenssados da melhor maneira, levando em consideração competências envolvidas e
necessidades a serem atendidas.
2. Serviços
O quê o setor/área de dados deve prover? A resposta dessa pergunta traz consigo a
atuação de maior visibilidade da área de Governança de Dados: os serviços. Tudo que é
provido pela área de dados, buscando atender ao cliente e àrea de Desenvolvimento de
Sistemas, são essencialmente da natureza de serviços. A figura 2 representa claramente
os pontos centrais dos serviços fornecidos.

4.
Figura 3. Modelo de Serviços.
● Usuários (Conceito LDAP)
○ Remoção
○ Criação
○ Grupos
○ Desativação
○ Perfil (cotas de utilização e manuseio).
● Acesso
○ Liberação
○ Remoção
● BD (Gestão de repositório)
○ Instância
○ Esquema
● ETL (Extraction Transformation Load);
● Suporte ao desenvolvimento
○ Arquitetura
○ Tuning
○ Modelagem
○ Capacitação
○ Design
● Gestão de Operação
○ Carga/JOBs

5. As áreas descritas, representando os pontos centrais de serviço, trazem puramente uma
nomenclatura específica, quanto à competência. Mais detalhes serão trazidos aqui
conforme às áreas de atuação forem sendo definidas.
3. Inovação
A condição de melhoria contínua e a busca pela excelência constante ná área de dados
da instituição é o que movimentará positivamente o nosso “universo moderno de dados”:
a inovação. A figura abaixo mostra o estado atual quanto à modernização que está sendo
idealizado atualmente.
Figura 4. Modelo de Inovação
● In Memory: Armazenamento eficiente e em larga escala (Ex.: MapReduce);
● NoSQL;
● Mensageria (AMQP);
● Data Lake (Pentaho, Hadoop, Kafka);
● Estrutura híbrida de BD (Relacional, Distribuído, NoSQL);
● GraphBD (Maria, Cassandra);
● MDM (Master Data Management);
● Cenário OLDAP.
Nessa área de inovação, à medida com que forem sendo trabalhadas as novas
tecnologias em demanda, a relação estrutural já definida no Plano Geral de Governança
de Dados e amparada sob as Políticas de Governança de Dados devem se manter para

6. que, mesmo na busca de inovação, o que foi essencialmente discutido e definido
mantenha­se coerente tanto ao que já existe em legado como para o novo.
4. Plano de Geral de Governança de Dados
No que tange os pontos focais descritos acima e seus respectivos items, o plano geral
deve atender as áreas mencionadas conforme as etapas a seguir, de forma cronológica,
iniciado em agosto/2014 e estimado até dezembro/2016, com pontos de entrega a cada
etapa concluída, da seguinte forma:
1. Inventário
a. Levantamento físico (Todos os BDs fisicamente)
b. Levantamento lógico (Todos os BDs logicamente)
c. Automação do inventário
d. Definição de criticidade dos ambientes
e. Instalação dos BDs*
f. Relatório final de inventário
2. Backup e Restore
a. Levantamento da situação atual
b. Melhoria da Política de backup e restore
c. Definir as informações de controle
d. Definir relatório das informações de controle
e. Iniciar migração dos bancos críticos*
f. Efetuar a migração completa de todos os bancos
3. Monitoração e Acompanhamento
a. Definição de monitoramento
b. Aplicação de monitoramento
4. Padronização
a. Definir padrão
b. Migração dos bancos críticos (+críticos)
c. Migração dos bancos não­críticos (­críticos)
5. Segurança
a. Definir política de segurança (LDAP em uso)
b. Migração dos usuários
6. Alta disponibilidade
a. Estudo das licensas (SW + HW)
b. Aquisição das licensas (SW + HW)
c. Implantação de replicação (STI ­ HUAP)

7. Apêndice A: Gerenciamento de Dados Mestre (MDM)
Esse apêndice apresenta de forma detalhada as fases de atuação do gerenciamento de
dados mestres. Dados mestre são dados que possuem grande valor (dados mais
importantes e/ou principais dados utilizados pela maioria “ou todos” serviços) para a
instituição. Com isso, o gerenciamento desses dados deve ser feito de maneira
adequada, principalmente para evitar inconsistência dos mesmos. Casos comuns de
inconsistências em dados mestres, tem haver basicamente com a replicação desses
dados, destinados a atender vários serviços ou aplicativos. Com isso, promove­se a
existência de um número de representações de fontes de dados mais específica ao
serviço ou aplicativo e menos à fonte origem, deixando assim tais dados inconsistentes,
onde de fato, tais informações deveriam referenciar uma única fonte de dados. Como
parte da estratégia de MDM, os três pilares do gerenciamento de dados precisam ser
investigados quanto a origem, ao gerenciamento e ao consumo dos dados. Não é
possível ter uma estratégia MDM robusta, em nível de empresa, se quaisquer um desses
aspectos for ignorado. No intuito de promover um direcionamento no tratamento
adequado desses dados, segue abaixo uma listagem obtida em
http://msdn.microsoft.com/pt­br/library/bb190163.aspx:
1. Identificar as fontes de dados mestre. 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. Identificar os produtores e os consumidores dos dados mestre. Quais
aplicativos produzem os dados mestre identificados na primeira etapa e ­ em geral
mais difícil de determinar ­ quais aplicativos usam os dados mestre. Dependendo
da abordagem usada na manutenção dos dados mestre, 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. Coletar e analisar os metadados sobre os dados mestre. Para todas as fontes
identificadas na primeira etapa, quais são as entidades e os atributos dos dados e
o que significam? Incluem­se o nome do atributo, o tipo de dados, os valores
aceitos, as restrições, os valores padrão, as dependências e o proprietário da

8. definição e da manutenção 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 significativo.
4. Indicar os administradores dos dados. Deverão ser indivíduos com
conhecimento dos atuais dados­fonte e capazes de determinar como transformar a
fonte no formato de dados mestre. Em geral, os administradores deverão ser
indicados pelos proprietários de cada fonte de dados mestre, arquitetos
responsáveis pelos sistemas MDM e representantes dos usuários dos dados
mestre no negócio.
5. Implementar um programa de governança dos dados e um conselho para a
governança dos dados. Este grupo deve ter o conhecimento e a autoridade para
tomar decisões sobre como os dados mestre devem ser mantidos, o que contêm,
por quanto tempo serão mantidos e como as alterações serão autorizadas e
auditadas. Centenas de decisões devem ser tomadas no decorrer de um projeto
de dados mestre e, se não houver um organismo e um processo para a tomada de
decisões, bem definidos, o projeto poderá falhar porque a política impede uma
tomada de decisão efetiva.
6. Desenvolver o modelo de dados mestre. Decidir qual a aparência dos registros
mestre: quais atributos estão incluídos, de que porte e tipo são os dados, quais
valores são aceitos, etc. Esta etapa deve incluir, também, o mapeamento entre o
modelo de dados mestre e as atuais fontes de dados. Normalmente, esta é a
etapa mais importante e a mais difícil do processo. Se você tentar contentar a
todos, incluindo todos os atributos­fonte na entidade mestre, acabará, quase
sempre, com dados mestre muito complexos e complicados para serem úteis. Por
exemplo, se não conseguir decidir se o peso deve ser apresentado em libras ou
quilos, uma alternativa poderia ser incluir ambos (WeightLb e WeightKg). Ainda
que esta alternativa satisfaça a todos, você estará desperdiçando megabytes de
armazenamento com números que podem ser calculados em microssegundos e,

9. também, correndo o risco de criar dados inconsistentes (WeightLb = 5 e WeightKg
= 5). Embora este seja um exemplo bastante trivial, uma questão maior seria
manter vários números de itens para o mesmo produto. Como em qualquer esforço
de comissão, haverá brigas e negociações que resultarão em decisões de
qualidade inferior. É importante definir, antecipadamente, o processo de decisão,
as prioridades e o tomador de decisão final, para garantir a execução do processo
sem sobressaltos.
7. Escolher um conjunto de ferramentas. Será preciso comprar ou construir
ferramentas para criar as listas mestre limpando, transformando e mesclando os
dados­fonte. Além disso, será preciso uma infra­estrutura para usar e manter a
lista mestre. Mais adiante, neste artigo, estas funções são abordadas em detalhes.
Você poderá usar um único conjunto de ferramentas, de um mesmo fornecedor,
para todas essas funções, ou talvez queira adotar uma abordagem de
best­of­breed (a melhor ferramenta para cada função). Em geral, as técnicas para
limpar e mesclar dados são diferentes, para diferentes tipos de dados; assim, não
há muitas ferramentas que atendam a todo espectro dos dados mestre. As duas
principais categorias são as ferramentas que integram os dados do cliente (CDI)
para criação do mestre de clientes e as ferramentas de gerenciamento de
informações de produto (PIM) para criação do mestre de produtos. Algumas
ferramentas executarão as duas tarefas mas, em geral, são melhores em uma das
tarefas, apenas. 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 e hierarquias. 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. Por exemplo, se
uma ferramenta para mesclagem combinar dois registros de John Smith em
Boston e se você decidir que realmente existem duas pessoas diferentes com
esse nome, nessa cidade, você precisará saber como eram os registros antes de
serem mesclados, para conseguir desfazer essa ação.
8. Projetar a infra­estrutura. Depois de os dados mestre estarem limpos e
consistentes, você precisará colocá­los à disposição de seus aplicativos e

10. providenciar processos para a sua administração e manutenção. Esta etapa é
uma questão bastante grande e, por isso, dedico uma seção inteira ao assunto,
mais adiante neste documento. Depois que esta infra­estrutura estiver
implementada, você terá vários aplicativos que dependerão de sua
disponibilidade; assim, confiabilidade e escalabilidade são considerações
importantes a serem incluídas no seu projeto. Na maioria dos casos, você mesmo
terá de implementar partes significativas da infra­estrutura, porque ela será
projetada para adequar­se à infra­estrutura, às plataformas e aos aplicativos
atuais.
9. Gerar e testar os dados mestre. É nesta etapa que você usará as ferramentas
desenvolvidas ou compradas para mesclar os dados­fonte na lista de dados
mestre. Em geral, este é um processo iterativo que exige explorar regras e
configurações para chegar na correspondência correta. Este processo também
exige grande volume de inspeção manual para confirmar se os resultados estão
corretos e se atendem aos requisitos estabelecidos para o projeto. Nenhuma
ferramenta conseguirá a correspondência correta, todas as vezes; assim, será
preciso ponderar as conseqüências entre correspondências falsas vs
correspondências perdidas, para determinar como configurar essas ferramentas.
Correspondências falsas podem levar à insatisfação do cliente, se as faturas
estiverem imprecisas ou se a pessoa errada for presa. Se houver grande volume
de correspondências perdidas os dados mestre terão menor utilidade, e você não
obterá os benefícios esperados do investimento em MDM.
10. Modificar os sistemas de produção e de consumo. Dependendo de como a
sua implementação MDM estiver projetada, talvez seja preciso modificar os
sistemas que produzem, mantêm ou consomem dados mestre para trabalhar com
a nova fonte de dados mestre. Se os dados mestre são usados em um sistema
independente dos sistemas­fonte ­ um data warehouse, por exemplo ­ os
sistemas­fonte talvez não tenham de ser modificados. Entretanto, se os
sistemas­fonte forem usar os dados mestre, mudanças serão provavelmente
necessárias. Os sistemas­fonte terão de acessar novos dados mestre ou estes
terão de estar sincronizados com os sistemas­fonte, para que estes últimos

11. tenham uma cópia dos dados mestre limpos para uso. Se não for possível alterar
um ou mais sistemas­fonte, este talvez não consiga usar os dados mestre ou estes
últimos terão de estar integrados ao banco de dados do sistema­fonte por meio de
processos externos, como gatilhos e comandos SQL. Os sistemas­fonte que
geram novos registros devem ser modificados para procurar conjuntos de registros
mestre existentes, antes de criar novos registros ou de atualizar os registros
mestre existentes. Este procedimento confirma que a qualidade dos dados
gerados na fonte é boa e, assim, o MDM poderá funcionar de modo mais eficiente
e o próprio aplicativo gerenciará a qualidade dos dados. O MDM deve ser
aproveitado não apenas como um sistema de registros, mas também como um
aplicativo que possibilita a manipulação de dados, de modo mais eficiente e
limpo, em todos os aplicativos da empresa. Como parte da estratégia de MDM, os
três pilares do gerenciamento de dados precisam ser investigados quanto a
origem, ao gerenciamento e ao consumo dos dados. Não é possível ter uma
estratégia MDM robusta, em nível de empresa, se qualquer um desses aspectos
for ignorado.
11. Implementar os processos de manutenção. Como declaramos anteriormente,
qualquer implementação de MDM deve incorporar ferramentas, processos e
pessoas para manter a qualidade dos dados. Todos os dados devem ter um
administrador, que será responsável por garantir a qualidade dos dados mestre.
Em geral, o administrador dos dados será uma pessoa que trabalha no negócio,
com conhecimento dos dados, que possa reconhecer dados incorretos e que
tenha conhecimento e autoridade para corrigir as falhas. A infraestrutura do MDM
deverá incluir ferramentas que ajudem o administrador dos dados no
reconhecimento das falhas, simplificando as correções. Uma boa ferramenta para
a administração dos dados deve indicar as correspondências questionáveis
realizadas: clientes com nomes diferentes e números de cliente que têm o mesmo
endereço, por exemplo. O administrador talvez também queira revisar os itens
acrescentados como novos, porque os critérios de correspondência estavam
próximos, mas abaixo do padrão. É importante que o administrador de dados
consulte o histórico das alterações feitas nos dados pelos sistemas MDM para
isolar a fonte de erros e para desfazer alterações incorretas. A manutenção

12. também inclui os processos para “arrastar” as mudanças e as adições para o
sistema MDM, e para distribuir os dados limpos nos lugares certos.