ADMINISTRAÇÃO DE DADOS: uma atividade imprescindível
no processo de gestão de dados nas organizações
IREMAR NUNES DE LIMA 1
GEANNINE ELAUDIENE HERONVILLE ALVES 2
RESUMO: Este artigo analisa a importância da área de administração de dados nas corporações, através da descrição de suas principais atividades, da
diferenciação entre suas atividades e as atividades dos administradores de banco de dados. É apresentado também, um caso que exemplifica a atuação do
administrador de dados.
PALAVRAS-CHAVE: Banco de Dados, Administração de Dados
1. INTRODUÇÃO
Neste cenário, este artigo tem o objetivo de mostrar a ne-
Atualmente verifica-se que o avanço tecnológico possibilitou
cessidade de se ter, nas organizações, uma área de administra-
às instituições gerar e armazenar grandes volumes de dados.
ção de dados com processos, tarefas e padrões bem definidos.
Porém, a análise destes dados e a extração de informações relevantes e estratégicas, a partir deles, não é algo tão freqüente.
Neste contexto, as instituições investem em novas tecnologias,
ferramentas e infra-estrutura para realizar o tratamento destes
dados. Porém, muitas vezes, deixa-se de investir na base de
todo este processo que é a qualidade dos dados captados e/ou
mantidos nos sistemas corporativos e que serão utilizados numa
etapa posterior de análise e tratamento. Carlos Barbieri (2011),
em suas reflexões para escrever o livro BI2- Business Inteligence
-Modelagem e Qualidade, ponderou “... o porquê da qualidade
de dados não ter ainda alcançado um patamar de importância
corporativa semelhante à qualidade dos processos”.
O problema nasce, muitas vezes, no fato de as instituições
não possuírem, no processo de desenvolvimento e manutenção de software, etapas e tarefas formais e bem definidas sobre
administração de dados e, principalmente, não possuírem uma
equipe dedicada, responsável pela definição, atualização e execução destas etapas e tarefas dentro da instituição.
A consequência disto é o risco de se ter um arsenal de infra-estrutura e ferramentas para armazenar, processar e tratar os
dados, porém estes dados não terem a qualidade necessária.
E, esta falta de qualidade, no momento de sua utilização, por
exemplo, na etapa de tratamento, implica, muitas vezes, em um
esforço enorme de correção, reprocessamento e de um grande
retrabalho na manutenção de sistemas corporativos. Isto representa um enorme custo para a instituição. Porém este custo não
é óbvio e por conseqüência, não é contabilizado de uma forma
específica, uma vez que as citadas ações de correção, etc. são
dissolvidas na rotina de trabalho.
2. AS ATRIBUIÇÕES DE UM ADMINISTRADOR DE DADOS
Muitas instituições não possuem uma equipe de administração de dados (ADs) por não conhecer suas atribuições e por ,
muitas vezes, confundi-las com as da equipe de administradores de banco de dados (DBAs) e com as da equipe de analistas
e desenvolvedores de sistemas. Em conseqüência disto, muitas
tarefas importantes deixam de ser executas ou são executadas
sem o cuidado necessário.
Vamos, a princípio, diferenciar a tarefas dos ADs das tarefas
dos DBAs : os DBAs são responsáveis pelo bom funcionamento
do(s) software(s) de banco de dados adotado(s) pela instituição.
A grosso modo, eles são responsáveis por manter o banco disponível, atualizado, bem configurado, seguro, sem erros e com
o melhor tempo de resposta possível para o ambiente em questão. Já os ADs são responsáveis pelo banco de dados no seu
aspecto lógico. Também, a grosso modo, eles são responsáveis
por zelar para que os dados estejam estruturados no banco
de dados da melhor maneira possível, considerando o ambiente
em questão, e com a qualidade necessária.
Por exemplo, não se perguntaria, para um AD, qual é a memória alocada para uma determinada instância do banco de dados ou não se cobraria do AD o fato de o banco de dados estar
fora do ar. Por outro lado, não se perguntaria, para um DBA,
como determinado dado está estruturado dentro do banco de
dados ou em que esquema se encontra determinado dado. Porém, há muita interseção no trabalho destes dois profissionais,
tanto na rotina diária quanto na definição da melhor maneira
PÓS EM REVISTA l 349
de trabalhar.
A forma como o banco é configurado e os padrões colocados pela equipe de DBAs para funcionamento do banco irá interferir no trabalho dos ADs. Por exemplo, no caso do Oracle, se for
posto com padrão, pelos DBAs, que apenas haja Data Base Link
em casos excepcionais, isto irá interferir no trabalho dos ADs.
e executar as ações necessárias para garantir o cumprimento
desta política; controlar usuários e privilégios de usuários; etc.
10. Suporte à equipe de ADs na manutenção das estruturas
de dados;
11. Suporte à equipe de desenvolvedores para melhoria da
performance das aplicações;
Por outro lado, pode ser que a forma com que os ADs estrutura-
12. Estabelecimento, atualização, formalização e comunica-
rem os dados, em uma certa situação, interfira na performance
ção de todos os padrões e regras necessários para o bom fun-
do banco. Então, embora com atribuições distintas, os DBAs e
cionamento do banco, principalmente aqueles que precisem ser
ADs devem sempre alinhar suas atividades e colocar, um para o
seguidos/conhecidos pelas outras equipes que fazem interface
outro, os seus padrões para que o resultado final seja uma boa
com a equipe de DBAs.
utilização do banco de dados, em todos os seus aspectos, uma
vez que é isto que importa para o usuário final.
De uma forma resumida, as principais atribuições dos DBAs
são:
De uma forma geral as atribuições do Administrador de Dados são :
1) Conhecer e documentar os dados e objetos
Buscar o conhecimento dos dados armazenados na institui-
1. Suporte na especificação e dimensionamento do equipamento destinado à instalação do servidor do banco de dados;
ção, documentar e divulgar este conhecimento é a principal atribuição dos administradores de dados. Mesmo porque, é preciso
2. Criação e administração do ambiente de banco de dados
conhecer aquilo que será administrado. Em última instância, isto
– isto implica instalação da ferramenta, configuração da ferra-
significa promover o conhecimento do contexto do negócio da
menta, realização de atualizações, aplicação de service packs,
instituição. Se alguém, na instituição, tiver dúvidas sobre a exis-
abertura de chamados junto ao suporte, etc. Em resumo, garan-
tência de um determinado dado nas bases de dados, ele deve
tia de que o banco esteja instalado, atualizado e configurado da
questionar aos administradores de dados. Porém, conhecer não
melhor maneira possível;
significa ter a resposta imediata – significa ter a responsabilida-
3. Estabelecimento e atualização de critérios e padrões para
de de produzir e promover acesso a este conhecimento. Então,
instalação do programa cliente e suporte à equipe responsável
pode ser que o AD não saiba sobre a existência do dado, mas
por esta instalação;
ele deve pesquisar e fornecer a resposta.
4. Avaliação da necessidade de upgrade da aplicação;
5. Planejamento, junto a outras equipes, das paradas necessárias do banco para manutenções corretivas e preventivas;
Para a geração e manutenção deste conhecimento – conhecimento dos dados da instituição, os administradores têm, como
tarefa contínua, a documentação das bases de dados.
6. Monitoramento do banco de dados: monitoramento e to-
A documentação dos dados é uma tarefa essencial da ad-
mada de providências, a partir deste monitoramento, que garan-
ministração de dados, uma vez que dá suporte a várias outras
tam um bom desempenho do banco e um bom aproveitamento
tarefas. Entende-se, de uma forma resumida, por documentar
do(s) hardware(s) envolvido(s), tais como reorganização de ta-
os dados:
belas, novas configurações para atendimento a novas necessi-
l
Definir um padrão para se agrupar os objetos de uma
dades, etc. Os monitoramentos são vários: monitoramento do
aplicação ou módulo: por exemplo, o fato de se agrupar os ob-
espaço em disco, de desempenho, de uso de CPU, de memória
jetos de uma mesma aplicação ou módulo em um esquema
alocada, etc.
específico, no caso do Oracle, ou em um database específico,
7. Garantia da segurança de dados: rotinas de backup e
restore do banco;
no caso do SQL Server , é uma maneira simples de dizer qual
aplicação/módulo é responsável pelo objeto e/ou mantém o ob-
8. Garantia da disponibilidade do banco: implantação de
jeto. Isto parece óbvio, mas já presenciei situações em que os
mecanismos para garantir a disponibilidade do banco de acor-
objetos de vários módulos foram criados dentro de um mesmo
do com as necessidades das aplicações, como, por exemplo,
esquema Oracle e o resultado foi um esquema com um grande
instalação de um servidor “standby” que garanta a disponibili-
número de tabelas, sem documentação, para as quais não se
dade do banco em caso de problemas com o servidor principal,
sabia, na grande maioria, qual era a aplicação/módulo respon-
para atendimento de aplicações de alta disponibilidade;
sável;
9. Garantia da segurança de acesso: estabelecer, junto a
l Definir, manter e divulgar um padrão para nomenclatura
outras equipes, a política de acesso aos vários bancos de dados
dos objetos da base de dados: esta, também, é uma tarefa sim-
350 | PÓS EM REVISTA
ples e importante, uma vez que um nome de objeto, que siga um
bom padrão, já fala muito sobre o objeto. Para citar como exem-
Ainda, segundo Modelagem de dados (2000, p.10), “A ad-
plo, vivenciei um problema, no banco Oracle, que era descobrir
ministração de dados participa apoiando os desenvolvedores
qual sequence gerava o ID (identificador) de uma determinada
de sistemas em tarefas de modelagem de dados e na elabora-
tabela, pois não havia nada no nome da sequence que a vincu-
ção da documentação, além de definir a segurança e a integri-
lasse ao nome da tabela, nem ao menos havia documentação.
dade dos mesmos”.
Criamos, então, um padrão para o nome da sequence que era
A etapa de modelagem de dados é particularmente impor-
SQ<nome da tabela>. É uma medida simples, porém absolu-
tante, pois é nesta que se define a estrutura – cada tabela neces-
tamente eficaz;
sária, cada atributo, tipo dos atributos, tamanho dos atributos,
l Dizer o que cada tabela contém;
l
Dizer como cada tabela é mantida ou carregada - qual
a aplicação, módulo ou processo é responsável por sua manu-
relacionamento entre as tabelas, etc., que os dados serão armazenados. Isto significa que toda a aplicação será desenvolvida
com base nesta estrutura.
tenção/ origem; ou, no caso de carga batch, dizer qual a origem
Há todo um conhecimento sobre modelagem de dados
dos dados, qual o processo responsável pela carga e qual a
que precisa ser dominado pelos profissionais envolvidos nesta
periodicidade desta carga.
etapa. Muitas vezes, por exemplo, a tarefa de modelagem dos
l
Dizer qual a taxa de crescimento da tabela, com base
em um intervalo de tempo;
l Dizer o que cada atributo contém;
l
Elaborar, atualizar e publicar os modelos das bases de
dados;
l
dados fica confiada aos analistas ou desenvolvedores de sistemas. Realmente, muitos destes profissionais, na sua formação,
passaram por disciplinas de modelagem de dados. Porém, sua
experiência maior está no desenvolvimento, suas técnicas e seu
foco está na entrega da solução. Então, muitas vezes, a tarefa
Dizer o que faz cada procedimento/função armazena-
dos nas bases de dados.
de definir e estruturar os dados, da melhor forma possível, dentro do ambiente em questão, não se torna tão prioritário.
Cabe à administração de dados definir um processo que
Daí a necessidade de se ter uma equipe responsável por
garanta a documentação dos objetos à medida que sejam cria-
validar esta modelagem e estabelecer, atualizar, e formalizar pa-
dos/mantidos. Ainda assim, em muitas instituições, há bases de
drões e regras que garantam uma boa modelagem de dados
dados, de aplicações antigas, sem documentação. Neste caso,
para o ambiente em questão.
os ADs devem recorrer aos analistas que mantém estas aplicações para que estes revelem, às vezes através do próprio códi-
Abaixo segue uma sugestão de processo a ser seguido na
etapa de modelagem de dados:
go, o significado dos dados existentes. Isto dependerá de mui-
1. Primeiramente, a equipe de negócio (requisitos) deve
tas iniciativas do AD, pois normalmente são aplicações grandes,
apresentar, à equipe de AD, o diagrama de contexto da aplica-
de disponibilidade de tempo e de boa vontade dos analistas das
ção. Neste momento, os ADs irão ter conhecimento dos dados
aplicações.
necessários e irão revelar os dados já existentes nas bases de
dados da instituição, que serão utilizados pela aplicação em
2) Projetar as bases de dados
questão (esta integração com os dados da instituição é uma
Independentemente do processo de desenvolvimento de
outra atividade da Administração de Dados que será detalhada
software adotado pela instituição, caso o software envolva ge-
adiante).
ração ou manutenção de dados, haverá sempre uma etapa que
2. Num segundo momento, a equipe de negócio irá apre-
consiste na definição destes dados. Esta definição dos dados
sentar aos ADs o diagrama de dados. Este será validado, com
compreende várias tarefas e é apenas o início do ciclo de vida
base nas formas normais e nos padrões da instituição, para se
do dado que irá ser inserido no banco de dados da instituição.
chegar a um modelo teoricamente correto, sem redundâncias.
De acordo com Modelagem de Dados (2000, p.10):
3. A partir do modelo do passo anterior, deverá ser feita uma
Devemos observar, então, que os dados precisam ser:
análise da aplicação: analisar o volume de dados das tabelas;
modelados (identificados na sua composição e na sua
os tipos de acesso que serão feitos aos dados; o tempo de res-
semântica), resguardados (na integridade, segurança
posta necessário para os acessos, etc. A partir destas análises,
e documentação) e disponibilizados (para o acesso,
várias avaliações podem ser feitas: necessidade de particiona-
atualização e simulação).
mento de tabelas; necessidade de criação de índices; necesPÓS EM REVISTA l 351
sidade de alguma alteração no modelo de modo a garantir o
para se pesquisar os dados, de modo a promover a integração.
melhor acesso ao dado, etc. Pode ser que, em alguns casos,
Na maioria dos casos, a integração é ignorada e a aplicação
haja necessidade de algum tipo de redundância de dados para,
nasce como autônoma, com a persistência de todos os dados
por exemplo, melhoria de performance; pode ser que, em al-
de que necessita, o que , muitas vezes, acarreta redundância
guns casos, seja necessário trazer dados de uma outra base e
desnecessária e/ou sem nenhum controle. Já testemunhei si-
redundar estes dados na base em questão; etc. No caso de re-
tuações onde os desenvolvedores achavam que não deveriam
dundâncias, o importante é que essas sejam feitas com controle
“mexer” com os dados de determinados sistemas, mesmo sa-
para que não resultem em divergências nos valores dos dados.
bendo que a base de dados destes sistemas continham e man-
4. A partir do modelo final, devem-se verificar as adaptações
tinham informações básicas da instituição, necessárias para a
necessárias no código – por exemplo, no caso de particiona-
aplicação a ser desenvolvida.
mentos, dependendo do tipo adotado, deve-se fazer referência,
nas sentenças SQL, ao atributo considerado para particionar.
5. Quando o modelo estiver na versão final, a equipe de negócio deverá entregar, à equipe de ADs, toda documentação
exigida.
4) Criar as bases das aplicações nos bancos de desenvolvimento
Quando se chega à versão final do modelo de dados, parte-se para a criação dos objetos e preparação do banco de dados
de desenvolvimento, para que os desenvolvedores possam ini-
3) Integrar os dados
Além da teoria e das boas práticas, há outra tarefa que permeia a projeto das bases de dados que é o conhecimento dos
dados já existentes na instituição. Os dados corporativos e/ou
os dados de outros sistemas podem ser necessários para a modelagem do sistema em questão. Então, é essencial que o profissional de dados, envolvido na modelagem, conheça os dados
da instituição, ou tenha a responsabilidade de pesquisá-los para
dar suporte à modelagem , para que haja integração entre os
sistemas e para que não ocorra problemas clássicos como, por
exemplo, redundância desnecessária de dados, praticada sem
nenhum controle.
O conhecimento dos dados corporativos é uma tarefa que
exige, dos profissionais de dados, constante pesquisa e documentação. Serra (2002, p.135), na sua abordagem sobre arquitetura de dados, define da seguinte maneira o papel do arquiteto de dados, que seria o profissional que lida com o dado :
Ele se ocupa de trabalhar os dados como um recurso
estratégico da organização, representando-os independentemente dos processos das diferentes unidades que
ciar a codificação da aplicação.
Neste momento, os ADs irão executar várias atividades:
l Colocar os nomes de objetos na nomenclatura padrão;
l
Criar o esquema, as roles (caso o banco de dados e a
organização trabalhe com roles) e as tablespaces;
Criar os objetos: tabelas, sequences, triggers, cons-
l
traints, índices, views, funções, procedures, etc.;
l
Inserir, no banco de dados, caso este permita, ou em
qualquer outro repositório, a documentação dos objetos;
l Conceder grant dos objetos para as roles, caso o banco
de dados e a organização opere com roles;
Verificar quais usuários irão participar do desenvolvi-
l
mento e criá-los no banco de dados de desenvolvimento;
l Conceder grant dos objetos e/ou roles para os usuários ;
l Criar sinônimos públicos e/ou privados;
l
Fazer o modelo da base de dados e publicar este mo-
delo. Para esta tarefa, o ideal é utilizar uma ferramenta case,
integrada com o banco de dados, que tenha o recurso de engenharia direta e reversa, para que fique fácil a atualização dos
modelos.
os utilizam, respeitando as múltiplas visões derivadas do
mesmo dado, permitindo seu compartilhamento, considerando as características dos níveis de informação
necessários: operacional – tático – estratégico e
disponibilizando estruturas de dados de forma organizada; propiciando com isso a construção da base
para sistemas de informação flexíveis e integrados.
Esta é uma tarefa delicada de se deixar a cargo de desenvolvedores e analistas: muitas vezes não há documentação dos
dados das aplicações existentes e não há tempo no cronograma
352 | PÓS EM REVISTA
5) Executar, nos bancos de desenvolvimento / homologação, as
instruções DDL
Fica a cargo de a organização definir quem poderá executar
instruções DDL nos bancos de dados. Pode haver vários cenários :
l
Apenas os ADs e DBAs poderem executar instruções
DDL nas bases de dados. Pode haver, também, um cenário
mais restrito: no banco de produção e pré-produção, apenas os
DBAs executarem estas instruções. Já, nos bancos de desen-
volvimento e homologação, os ADs executariam;
de muitos usuários.
Pode-se dar uma proteção maior apenas para os ban-
Para que esta “equivalência” seja feita, é desenvolvido um
cos de produção, pré-produção e homologação: nestes bancos
trabalho conjunto entre DBAs, ADs, analistas e desenvolvedo-
as instruções de DDL seriam executadas apenas por DBAs e/
res, que engloba as seguintes tarefas:
l
ou ADs . Já, no banco de desenvolvimento, estas instruções
poderiam ser executadas pelos desenvolvedores.
l
Levantar as diferenças de estrutura entre os objetos do
banco de produção e do outro banco envolvido.
Qualquer um dos cenários traz vantagens e desvantagens.
- Pelo fato de os bancos de desenvolvimento, homo-
Concentrar as instruções DDL nas mãos dos DBAs e ADs
logação e pré-produção possuírem novos objetos, ou
tem a desvantagem de tornar mais moroso o processo de de-
objetos alterados, que ainda não constam em produção,
senvolvimento/homologação, uma vez que gera a necessidade
não se pode, simplesmente, “sobrepor” o outro banco
de os desenvolvedores e analistas criarem uma solicitação de
com o de produção. Caso as operações de DDL sejam
alteração para os ADs ou DBAs e esperar a solicitação ser aten-
executadas apenas por DBAs e/ou ADs e caso haja uma
dida. Mas, por outro lado, esta opção tem como grande vanta-
boa ferramenta para registro e controle destas deman-
gem a garantia do cumprimento das etapas e atividades defini-
das, é possível que todas as alterações feitas após a
das para o processo de administração dos dados, o que resulta
última cópia de produção estejam armazenadas separa-
num banco de dados mais bem estruturado e documentado.
damente para serem replicadas na nova cópia.
Desta forma, muitos problemas são evitados antes da codifica-
- Caso as operações de DDL sejam efetuadas pelos de-
ção da solução iniciar.
senvolvedores ou sejam efetuadas apenas por ADs e/ou
Quando se libera as instruções DDL para os desenvolvedo-
DBAs, porém não se tenha uma boa organização das
res, as regras e atividades da administração de dados devem
solicitações atendidas, deve-se fazer um levantamen-
ser claras e públicas, e os próprios desenvolvedores deverão
to das diferenças entre o banco de produção e o ou-
conhecê-las e segui-las. A ação dos ADs deixa de ser preventi-
tro banco em questão . Há ferramentas que fazem este
va para ser corretiva. A vantagem desta opção é um processo
levantamento, gerando as diferenças como instruções
de desenvolvimento um pouco menos moroso. Porém, em mi-
DDL e DML.
nha opinião, as desvantagens desta opção são muitas: primei-
l Verificar, junto aos analistas e desenvolvedores, as dife-
ramente, dependendo da estrutura da organização, tem-se um
renças que devem ser reaplicadas : esta é uma etapa de limpe-
número grande de desenvolvedores, em alguns casos localiza-
za, para eliminar objetos desnecessários do banco em questão;
dos em fábricas de software, e a rotatividade destes também é
grande. Todos estes fatores aumentam a possibilidade destes
desenvolvedores não conhecerem as regras para os dados e/
ou, apesar de conhecerem, não dar a elas a devida importância.
l
Copiar o banco de produção em uma nova área de
modo a criar um novo banco;
l
Rodar rotinas para alterar os dados do novo banco, de
modo a garantir o sigilo dos dados de produção;
Além disso, há a questão “tempo”: após a aplicação ser desen-
l Aplicar as diferenças levantadas no passo acima.
volvida sobre uma estrutura de dados inadequada, dificilmente
l Disponibilizar o novo banco para uso.
haverá cronograma para que ela seja alterada para atender a
Obs: o banco de dados substituído é mantido, por algum
uma outra estrutura. Então, não se consegue fazer uma correção
tempo, como segurança, caso alguma estrutura e dado neces-
completa. Quando muito, faz-se alguns reparos, nem sempre de
sários não tenham sido levados. Porém, este banco não fica
uma maneira adequada.
acessível aos usuários. Apenas aos DBAs e ADs.
6) Executar, juntamente com os DBAs, réplica de dados do banco
de produção para os bancos de homologação/desenvolvimento
7) Levar as bases das aplicações para os bancos de homologação,
pré-produção e produção
Periodicamente, é necessário fazer com que os bancos de
À medida que os módulos ou aplicações vão passando pe-
desenvolvimento, homologação e pré-produção fiquem com
las etapas de desenvolvimento, homologação, pré-produção e
dados semelhantes ao banco de produção, para que os testes
produção, a estrutura da base de dados destas aplicações tem
sejam feitos em cima de dados mais reais, com volumes reais, e
que caminhar para os respectivos bancos. A primeira migração
para que sejam corrigidos dados inconsistentes destes bancos,
ocorre do banco de desenvolvimento para o banco de homolo-
principalmente o de desenvolvimento, que sofre operações DML
gação, onde a aplicação passará por testes e, posteriormente,
PÓS EM REVISTA l 353
será validada pelo usuário. Esta migração significa, em nível de
lista responsável pela aplicação a revelação do significado
banco de dados, passar para o banco de homologação tudo –
dos valores. Muitas vezes se descobre lacunas na aplicação
estrutura e dados, que o novo módulo ou iteração ou aplicação
e outras vezes se descobre que esta passou a persistir no-
necessita. Isto significa que os ADs, juntamente com analistas e
vos valores para o atributo, porém não houve atualização da
desenvolvedores, terão que mapear esta estrutura e dados para
documentação. O resultado, normalmente, além de correções
esta migração. Uma boa prática é os ADs desenvolverem um
na aplicação e documentação dos dados, é a criação de che-
template para direcionar este mapeamento. A princípio, a tarefa
ck constraints que apenas aceitam um conjunto definido de
parece simples. Porém, o novo módulo, além de seus objetos
valores para o atributo. Isto evita o surgimento de novos valo-
próprios (que podem estar separados em um esquema), pode
res que não estejam previstos no banco. A criação de check
provocar alterações em objetos de outros módulos ou inserir
constraints pode se tornar um padrão estabelecido pela área
dados em objetos de outros módulos. Além disso, muitas apli-
de dados, quando não há uma tabela auxiliar que contenha a
cações utilizam frameworks , cujos dados também devem ser
descrição dos valores.
levados para novo banco. Tudo isto traz mais complexidade a
Na verdade, o objetivo da inspeção é zelar pela qualida-
esta tarefa de migração. Então, este template, a ser preenchido
de dos dados, e é um trabalho contínuo da administração de
por ADs, analistas e desenvolvedores, é útil para organizar esta
dados. É esta qualidade que traz segurança aos utilizadores
tarefa além de, uma vez efetuado e atualizado nesta fase de ho-
do dado. Há ferramentas de qualidade de dados que auxiliam
mologação, ficar pronto para as migrações para a pré-produção
neste trabalho.
e para produção.
3. ESTUDO DE CASO
8) Inspecionar os dados
Será descrito, aqui, um caso real de redundância descon-
Esta tarefa requer do administrador de dados um espírito
trolada de dados. O cenário é a TI de uma empresa que havia
investigativo. Os ADs, em suas várias pesquisas na base de da-
desenvolvido e mantinha um grande sistema corporativo, origi-
dos para documentá-lo, ou para verificar se dados necessários
nalmente construído na linguagem Natural e banco de dados
para uma dada aplicação já existem na base de dados, ou para
DB2 e posteriormente migrado para o banco Oracle. Iremos cha-
verificar algum erro detectado , ou por qualquer outro motivo,
mar este primeiro sistema de S1.
podem se deparar com dados incorretos ou indefinidos.
Num dado momento, foi contratada uma empresa para
Quando os dados estão incorretos, o AD tentará descobrir
migrar parte deste S1 para a plataforma Web, com linguagem
a origem do problema e, juntamente com os analistas que man-
Java, para disponibilização de vários serviços na Internet. Cha-
tém as aplicações envolvidas, mapear a solução a ser adotada.
maremos este novo sistema de S2. Como apenas parte do S1
Esta solução pode envolver apenas uma correção de da-
seria migrada, os dois sistemas teriam que funcionar, e, em
dos, sem afetar a aplicação em si. Neste caso, os analistas
muitos casos, teriam que se comunicar, isto é: alguns dados
construiriam o script para correção, este seria revisado pelos
inseridos e mantidos no S1 seriam tratados pelo S2 e vice-versa.
ADs e, posteriormente, seria executado nos diversos bancos.
Como não havia, na empresa, área de Administração de Dados,
Em outros casos, a solução envolve correções na própria
aplicação, para que a persistência dos dados seja feita corre-
a empresa contratada era responsável por desenhar e criar todas as bases de dados.
tamente, além da correção dos dados já persistidos com erro.
Uma determinada tabela auxiliar do S1, que chamaremos
Nestes casos, a área de Administração de Dados passa a ser
de TAB-S1, seria necessária também no S2. Entenda por auxiliar
demandante da área de soluções.
a tabela que contém dados importantes, cujos atributos chaves
E o que seriam os dados indefinidos ? No dicionário, indefinido significa que não se pode explicar, incerto, vago,
indeciso, indistinto. Tudo que um dado não pode ser. Segue
um exemplo prático: muitas vezes nos deparamos com atributos flags, cuja documentação indica os possíveis valores,
compõem os registros das tabelas com que a tabela auxiliar se
relaciona.
Havia as seguintes necessidades:
l
Nem todos os atributos da TAB-S1 eram necessários
para S2;
porém a base de dados apresenta outros valores persistidos,
l
que diferem da documentação. Então, a princípio, não se
para o S2;
sabe o que o valor significa. Os ADs, então, solicitam ao ana354 | PÓS EM REVISTA
Nem todos os registros da TAB-S1 eram necessários
Havia 10 atributos novos necessários apenas para o S2.
Resolveram, então, criar uma tabela na base de dados
tabelas somente eram considerados válidos se inseridos na
do S2, que chamaremos de TAB-S2, com alguns atributos per-
TAB-S1. Em outras palavras, todo registro da TAB-S2 teria que
tencentes à TAB-S1 e com atributos novos. Porém, pela dinâ-
existir, primeiramente, na TAB-S1. A figura abaixo, representa o
mica do negócio da empresa, os registros tratados pelas duas
cenário descrito.
l
Segundo relatos de analistas e funcionários que participa-
devido ao desenho e necessidade das aplicações. Além disto,
ram desta etapa do projeto, a criação da TAB-S2 ocorreu devi-
como as duas tabelas faziam relacionamentos com tabelas dife-
do a um certo sentimento de autonomia do novo sistema, que
rentes, as chaves estrangeiras, levadas para as tabelas relacio-
permeou todo o projeto : cria-se uma nova tabela para o novo
nadas, deveriam ser iguais;
sistema e não “mexe” com a tabela do sistema existente.
l A inserção de novos registros teria que ser feita, primei-
Os atributos em verde eram os atributos comuns entre as
ramente, na TAB-S1. Na inserção do mesmo registro, na TAB-
duas tabelas e os atributos em azul, na TAB-S2, eram os atribu-
-S2, a aplicação localizaria, pela chave, o registro na TAB-S1 e
tos novos, necessários apenas para o S2.
os atributos comuns teriam os conteúdos trazidos, via TRIGGER,
A criação de uma outra tabela poderia se justificar pelos seguintes motivos :
l Seria um tipo de especialização, uma vez que há atributos novos, que somente interessam ao SIS2;
l
Apesar de haver redundância , uma vez que temos atri-
butos que são os mesmos nas duas tabelas, esta poderia ser ne-
da TAB-S1. Desta forma, apenas os atributos novos da TAB-S2
poderiam ser alterados via aplicação.
l
Na alteração de registros, os atributos comuns seriam
alterados apenas na TAB-S1 e os novos conteúdos seriam levados, via TRIGGER, para a TAB-S2.
l
Como a exclusão dos registros das tabelas é lógica, e
cessária caso o acesso à TAB-S1 fosse muito grande. Seria uma
a validade dos registros é controlada pela TAB-S1, a exclusão
forma de não sobrecarregar a TAB-S1 com os acessos do S2.
seguiria a mesma lógica da alteração: assim que se inserisse
Porém, várias medidas teriam que ser sido tomadas para
que os atributos comuns entre as duas tabelas continuassem
iguais e se mantivesse, assim, a exatidão e integridade dos da-
DATA-FIM na TAB-S1, esta data-fim seria levada, via TRIGGER,
para a TAB-S2.
l
Na TAB-S1, como o atributo CODIGO-COMPLETO é
dos. Estas medidas poderiam ser, em ordem decrescente de
uma concatenação dos atributos CODIGO e DV, apenas estes
segurança, a nível de banco de dados, a nível de aplicação ou
últimos seriam inseridos pela aplicação. O CODIGO-COMPLE-
a nível de processo.
TO também seria inserido via TRIGGER.
A nível de banco de dados, estas medidas de controle seriam as seguintes:
Estas medidas garantiriam valores iguais para os atributos redundantes.
Primeiramente, as chaves das duas tabelas teriam que
Posteriormente, a instituição passou a ter uma área de Ad-
ser iguais, pois na verdade a tabela é uma só, que foi dividida
ministração de Dados e foi demandado a esta área eliminar a
l
PÓS EM REVISTA l 355
TAB-S2. Partindo do pressuposto que os registros equivalentes
de documentos gerados para usuários externos. Teoricamente,
das duas tabelas teriam valores iguais nos atributos comuns,
os dados destas tabelas relacionadas teriam que permanecer
este trabalho seguiria o seguinte roteiro:
fiéis aos documentos gerados que os continham. Além disso,
l
Levar, para a TAB-S1, os atributos novos da TAB-S2
e popular estes atributos com os valores contidos na TAB-S2;
caso estes documentos fossem reabertos, por alguma opção
da aplicação, após a unificação, ocorreria um erro pelo fato de
Criar, na TAB-S1, uma chave única com o atributo CO-
os dados gravados no documento (dados incorretos, originados
DIGO, para que a TAB-S1 pudesse se relacionar com as tabelas
da TAB-S2) não constarem na TAB-S1, que seria a única tabela.
que se relacionavam com a TAB-S2, uma vez que este atributo
Então, a unificação ficou no aguardo de a aplicação ser alte-
l
era chave na TAB-S2;
rada para que este problema fosse contornado. Este caso ilustra
Eliminar o relacionamento entre outras tabelas da base
como erros na estrutura de dados podem originar problemas
com a TAB-S2 e criar, nestas outras tabelas, um relacionamento
que, para serem resolvidos, demandam um grande esforço de
com a TAB-S1, através da chave única criada no passo anterior;
manutenção e como é importante a atuação da administração
Como segurança, criar uma tabela backup da TAB-S2,
de dados para agir de forma preventiva e zelar por esta estrutura.
l
l
com mesma estrutura e dados, e atribuir-lhe o nome BKP-TAB-S2;
l Eliminar a TAB-S2;
l
Criar uma view com o nome TAB-S2 (mesmo nome da
tabela eliminada), cujos atributos retornados teriam os mesmos
nomes dos atributos da TAB-S2 e cujos dados seriam buscados
da TAB-S1. Desta forma, o código da aplicação S2 não precisaria ser alterado.
No início do trabalho foi constatado que as medidas de controle citadas acima, além de não terem sido tomadas a nível de
banco de dados, também não foram tomadas a nível de aplicação e nem a nível de processo. Foram encontrados, então,
vários tipos de problemas:
l
do, ou no produto gerado, é essencial se ter OBJETIVOS, isto é,
qual o nível de qualidade que se deseja alcançar, PROCESSOS,
o mais formalizados possível (formalizado e não engessado) e
EQUIPE RESPONSÁVEL por manter e executar estes processos.
Não se pode ser ingênuo a ponto de acreditar que todas
as pessoas envolvidas buscarão, por iniciativa própria, sem
nenhum direcionamento, os mesmos padrões de qualidade.
Divergência de valores de atributos comuns entre as
tro da TI, como desenvolvedores e DBAs, assumam para si a
Registros com DATA-FIM na TAB-S2 que não estavam
com DATA-FIM na TAB-S1.
l
área, se é desejável certo nível de qualidade no serviço presta-
Com os dados de uma instituição não é diferente. Não se pode
duas tabelas;
l
Diante de todo o exposto, o que podemos concluir, de uma
forma genérica, é que, em qualquer instituição, de qualquer
Registros que existiam na TAB-S2 e não existiam na
TAB-S1;
l
4. CONCLUSÃO
Atributo CODIGO-COMPLETO, da TAB-S1, não corres-
pondia à concatenação dos atributos CODIGO+DV, da mesma
tabela.
Várias pesquisas foram feitas nas bases de dados para se
decidir a melhor maneira de corrigir as divergências e várias
medidas foram tomadas. Porém, a unificação ficou com uma
pendência: devido à divergência de valores de atributos que
eram comuns entre as duas tabelas, foram investigados quais
eram os valores corretos, pois após a unificação, somente existiria uma tabela. Os valores corretos estavam na TAB-S1. Então, aparentemente, nestes casos, não havia correção a fazer,
pois somente existiriam dados da TAB-S1. Porém, ao se relacionar com outras tabelas, a TAB-S2, que continha os dados
incorretos, levou estes dados para estas outras tabelas, que não
poderiam sofrer modificação automática, por já fazerem parte
356 | PÓS EM REVISTA
pensar que profissionais, que estejam em outras funções denresponsabilidade pela estrutura e qualidade de dados em toda
sua amplitude.
Não se pode pensar, também, que o fato de se ter uma ótima infraestrutura e ótimas ferramentas - banco de dados, ferramentas de Business Inteligence e outras vão garantir a qualidade dos dados. É preciso ter processos e pessoas que estejam
imbuídas destas responsabilidades . É imprescindível se ter uma
área de Administração de Dados que irá fazer a ponte dos outros profissionais de Tecnologia da Informação com os bancos
de dados. É claro que o tamanho desta área e o grau de complexidade de seus processos dependerão do porte da empresa
e dos níveis de controle e qualidade que se deseja alcançar.
O importante é que a área exista formalmente e seja estruturada e dimensionada para conseguir atuar de forma significativa, dentro dos objetivos e diretrizes da instituição. Deste
modo, a área irá adquirir a confiança e a parceria do restante
dos profissionais, seus processos irão amadurecer de uma forma contínua e tudo isto se traduzirá em organização, controle,
domínio, documentação, integração e qualidade dos dados da
instituição.
REFERÊNCIAS
BARBIERI, Carlos. BI2 – Business Intelligence – Modelagem e Qualidade. Elsevier. 2011.
SERRA, Laércio. A Essência do Business Intelligence. Berkeley.
2002.
SENAC.Modelagem de dados. Senac Nacional.2000.
TEOREY, Toby. Projeto e Modelagem de Bancos de Dados. Campus.2007.
NOTAS DE RODAPÉ
1
Professor do Centro Universitário Newton Paiva ([email protected]).
Pós graduanda em Banco de dados e Business Intelligence no Centro
Universitário Newton Paiva.([email protected]).
2
PÓS EM REVISTA l 357