ADMINISTRAÇÃO DE DADOS: uma atividade imprescindível no processo de gestão de dados nas organizações

Transcrição

1 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 Atualmente verifica-se que o avanço tecnológico possibilitou às instituições gerar e armazenar grandes volumes de dados. 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. Neste cenário, este artigo tem o objetivo de mostrar a necessidade de se ter, nas organizações, uma área de administração de dados com processos, tarefas e padrões bem definidos. 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

2 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. Por outro lado, pode ser que a forma com que os ADs estruturarem os dados, em uma certa situação, interfira na performance do banco. Então, embora com atribuições distintas, os DBAs e ADs devem sempre alinhar suas atividades e colocar, um para o outro, os seus padrões para que o resultado final seja uma boa 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: 1. Suporte na especificação e dimensionamento do equipamento destinado à instalação do servidor do banco de dados; 2. Criação e administração do ambiente de banco de dados isto implica instalação da ferramenta, configuração da ferramenta, realização de atualizações, aplicação de service packs, abertura de chamados junto ao suporte, etc. Em resumo, garantia de que o banco esteja instalado, atualizado e configurado da melhor maneira possível; 3. Estabelecimento e atualização de critérios e padrões para instalação do programa cliente e suporte à equipe responsável por esta instalação; 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; 6. Monitoramento do banco de dados: monitoramento e tomada de providências, a partir deste monitoramento, que garantam um bom desempenho do banco e um bom aproveitamento do(s) hardware(s) envolvido(s), tais como reorganização de tabelas, novas configurações para atendimento a novas necessidades, etc. Os monitoramentos são vários: monitoramento do espaço em disco, de desempenho, de uso de CPU, de memória alocada, etc. 7. Garantia da segurança de dados: rotinas de backup e restore do banco; 8. Garantia da disponibilidade do banco: implantação de mecanismos para garantir a disponibilidade do banco de acordo com as necessidades das aplicações, como, por exemplo, instalação de um servidor standby que garanta a disponibilidade do banco em caso de problemas com o servidor principal, para atendimento de aplicações de alta disponibilidade; 9. Garantia da segurança de acesso: estabelecer, junto a outras equipes, a política de acesso aos vários bancos de dados 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; 12. Estabelecimento, atualização, formalização e comunicação de todos os padrões e regras necessários para o bom funcionamento do banco, principalmente aqueles que precisem ser seguidos/conhecidos pelas outras equipes que fazem interface com a equipe de DBAs. 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ção, documentar e divulgar este conhecimento é a principal atribuição dos administradores de dados. Mesmo porque, é preciso conhecer aquilo que será administrado. Em última instância, isto significa promover o conhecimento do contexto do negócio da instituição. Se alguém, na instituição, tiver dúvidas sobre a existência de um determinado dado nas bases de dados, ele deve questionar aos administradores de dados. Porém, conhecer não significa ter a resposta imediata significa ter a responsabilidade de produzir e promover acesso a este conhecimento. Então, pode ser que o AD não saiba sobre a existência do dado, mas ele deve pesquisar e fornecer a resposta. 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. A documentação dos dados é uma tarefa essencial da administração de dados, uma vez que dá suporte a várias outras tarefas. Entende-se, de uma forma resumida, por documentar os dados: Definir um padrão para se agrupar os objetos de uma aplicação ou módulo: por exemplo, o fato de se agrupar os objetos de uma mesma aplicação ou módulo em um esquema específico, no caso do Oracle, ou em um database específico, no caso do SQL Server, é uma maneira simples de dizer qual aplicação/módulo é responsável pelo objeto e/ou mantém o objeto. Isto parece óbvio, mas já presenciei situações em que os objetos de vários módulos foram criados dentro de um mesmo esquema Oracle e o resultado foi um esquema com um grande número de tabelas, sem documentação, para as quais não se sabia, na grande maioria, qual era a aplicação/módulo responsável; Definir, manter e divulgar um padrão para nomenclatura dos objetos da base de dados: esta, também, é uma tarefa sim- 350 PÓS EM REVISTA

3 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 exemplo, vivenciei um problema, no banco Oracle, que era descobrir qual sequence gerava o ID (identificador) de uma determinada tabela, pois não havia nada no nome da sequence que a vinculasse ao nome da tabela, nem ao menos havia documentação. Criamos, então, um padrão para o nome da sequence que era SQ<nome da tabela>. É uma medida simples, porém absolutamente eficaz; Dizer o que cada tabela contém; Dizer como cada tabela é mantida ou carregada - qual a aplicação, módulo ou processo é responsável por sua manutenção/ origem; ou, no caso de carga batch, dizer qual a origem dos dados, qual o processo responsável pela carga e qual a periodicidade desta carga. Dizer qual a taxa de crescimento da tabela, com base em um intervalo de tempo; dados; Dizer o que cada atributo contém; Elaborar, atualizar e publicar os modelos das bases de Dizer o que faz cada procedimento/função armazenados nas bases de dados. Cabe à administração de dados definir um processo que garanta a documentação dos objetos à medida que sejam criados/mantidos. Ainda assim, em muitas instituições, há bases de dados, de aplicações antigas, sem documentação. Neste caso, os ADs devem recorrer aos analistas que mantém estas aplicações para que estes revelem, às vezes através do próprio código, o significado dos dados existentes. Isto dependerá de muitas iniciativas do AD, pois normalmente são aplicações grandes, de disponibilidade de tempo e de boa vontade dos analistas das aplicações. 2) Projetar as bases de dados Independentemente do processo de desenvolvimento de software adotado pela instituição, caso o software envolva geração ou manutenção de dados, haverá sempre uma etapa que consiste na definição destes dados. Esta definição dos dados compreende várias tarefas e é apenas o início do ciclo de vida do dado que irá ser inserido no banco de dados da instituição. De acordo com Modelagem de Dados (2000, p.10): Devemos observar, então, que os dados precisam ser: modelados (identificados na sua composição e na sua semântica), resguardados (na integridade, segurança e documentação) e disponibilizados (para o acesso, atualização e simulação). Ainda, segundo Modelagem de dados (2000, p.10), A administração de dados participa apoiando os desenvolvedores de sistemas em tarefas de modelagem de dados e na elaboração da documentação, além de definir a segurança e a integridade dos mesmos. A etapa de modelagem de dados é particularmente importante, pois é nesta que se define a estrutura cada tabela necessária, cada atributo, tipo dos atributos, tamanho dos atributos, relacionamento entre as tabelas, etc., que os dados serão armazenados. Isto significa que toda a aplicação será desenvolvida com base nesta estrutura. Há todo um conhecimento sobre modelagem de dados que precisa ser dominado pelos profissionais envolvidos nesta etapa. Muitas vezes, por exemplo, a tarefa de modelagem dos 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 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. Daí a necessidade de se ter uma equipe responsável por validar esta modelagem e estabelecer, atualizar, e formalizar padrões e regras que garantam uma boa modelagem de dados para o ambiente em questão. Abaixo segue uma sugestão de processo a ser seguido na etapa de modelagem de dados: 1. Primeiramente, a equipe de negócio (requisitos) deve apresentar, à equipe de AD, o diagrama de contexto da aplicação. Neste momento, os ADs irão ter conhecimento dos dados 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 questão (esta integração com os dados da instituição é uma outra atividade da Administração de Dados que será detalhada adiante). 2. Num segundo momento, a equipe de negócio irá apresentar aos ADs o diagrama de dados. Este será validado, com base nas formas normais e nos padrões da instituição, para se chegar a um modelo teoricamente correto, sem redundâncias. 3. A partir do modelo do passo anterior, deverá ser feita uma análise da aplicação: analisar o volume de dados das tabelas; os tipos de acesso que serão feitos aos dados; o tempo de resposta necessário para os acessos, etc. A partir destas análises, várias avaliações podem ser feitas: necessidade de particionamento de tabelas; necessidade de criação de índices; neces- PÓS EM REVISTA l 351

4 sidade de alguma alteração no modelo de modo a garantir o melhor acesso ao dado, etc. Pode ser que, em alguns casos, haja necessidade de algum tipo de redundância de dados para, por exemplo, melhoria de performance; pode ser que, em alguns casos, seja necessário trazer dados de uma outra base e redundar estes dados na base em questão; etc. No caso de redundâncias, o importante é que essas sejam feitas com controle para que não resultem em divergências nos valores dos dados. 4. A partir do modelo final, devem-se verificar as adaptações necessárias no código por exemplo, no caso de particionamentos, 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. 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 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 para se pesquisar os dados, de modo a promover a integração. Na maioria dos casos, a integração é ignorada e a aplicação nasce como autônoma, com a persistência de todos os dados de que necessita, o que, muitas vezes, acarreta redundância desnecessária e/ou sem nenhum controle. Já testemunhei situações onde os desenvolvedores achavam que não deveriam mexer com os dados de determinados sistemas, mesmo sabendo que a base de dados destes sistemas continham e mantinham informações básicas da instituição, necessárias para a aplicação a ser desenvolvida. 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 iniciar a codificação da aplicação. Neste momento, os ADs irão executar várias atividades: Colocar os nomes de objetos na nomenclatura padrão; 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, constraints, índices, views, funções, procedures, etc.; Inserir, no banco de dados, caso este permita, ou em qualquer outro repositório, a documentação dos objetos; 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 desenvolvimento e criá-los no banco de dados de desenvolvimento; Conceder grant dos objetos e/ou roles para os usuários ; Criar sinônimos públicos e/ou privados; Fazer o modelo da base de dados e publicar este modelo. 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. 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 : 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- 352 PÓS EM REVISTA

5 volvimento e homologação, os ADs executariam; Pode-se dar uma proteção maior apenas para os bancos de produção, pré-produção e homologação: nestes bancos as instruções de DDL seriam executadas apenas por DBAs e/ ou ADs. Já, no banco de desenvolvimento, estas instruções poderiam ser executadas pelos desenvolvedores. Qualquer um dos cenários traz vantagens e desvantagens. Concentrar as instruções DDL nas mãos dos DBAs e ADs tem a desvantagem de tornar mais moroso o processo de desenvolvimento/homologação, uma vez que gera a necessidade de os desenvolvedores e analistas criarem uma solicitação de alteração para os ADs ou DBAs e esperar a solicitação ser atendida. Mas, por outro lado, esta opção tem como grande vantagem a garantia do cumprimento das etapas e atividades definidas para o processo de administração dos dados, o que resulta num banco de dados mais bem estruturado e documentado. Desta forma, muitos problemas são evitados antes da codificação da solução iniciar. Quando se libera as instruções DDL para os desenvolvedores, as regras e atividades da administração de dados devem ser claras e públicas, e os próprios desenvolvedores deverão conhecê-las e segui-las. A ação dos ADs deixa de ser preventiva para ser corretiva. A vantagem desta opção é um processo de desenvolvimento um pouco menos moroso. Porém, em minha opinião, as desvantagens desta opção são muitas: primeiramente, dependendo da estrutura da organização, tem-se um número grande de desenvolvedores, em alguns casos localizados 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. Além disso, há a questão tempo : após a aplicação ser desenvolvida sobre uma estrutura de dados inadequada, dificilmente haverá cronograma para que ela seja alterada para atender a uma outra estrutura. Então, não se consegue fazer uma correção completa. Quando muito, faz-se alguns reparos, nem sempre de uma maneira adequada. de muitos usuários. Para que esta equivalência seja feita, é desenvolvido um trabalho conjunto entre DBAs, ADs, analistas e desenvolvedores, que engloba as seguintes tarefas: Levantar as diferenças de estrutura entre os objetos do banco de produção e do outro banco envolvido. - Pelo fato de os bancos de desenvolvimento, homologação e pré-produção possuírem novos objetos, ou objetos alterados, que ainda não constam em produção, não se pode, simplesmente, sobrepor o outro banco com o de produção. Caso as operações de DDL sejam executadas apenas por DBAs e/ou ADs e caso haja uma boa ferramenta para registro e controle destas demandas, é possível que todas as alterações feitas após a última cópia de produção estejam armazenadas separadamente para serem replicadas na nova cópia. - Caso as operações de DDL sejam efetuadas pelos desenvolvedores ou sejam efetuadas apenas por ADs e/ou DBAs, porém não se tenha uma boa organização das solicitações atendidas, deve-se fazer um levantamento das diferenças entre o banco de produção e o outro banco em questão. Há ferramentas que fazem este levantamento, gerando as diferenças como instruções DDL e DML. Verificar, junto aos analistas e desenvolvedores, as diferenças que devem ser reaplicadas : esta é uma etapa de limpeza, para eliminar objetos desnecessários do banco em questão; Copiar o banco de produção em uma nova área de modo a criar um novo banco; Rodar rotinas para alterar os dados do novo banco, de modo a garantir o sigilo dos dados de produção; Aplicar as diferenças levantadas no passo acima. Disponibilizar o novo banco para uso. Obs: o banco de dados substituído é mantido, por algum tempo, como segurança, caso alguma estrutura e dado necessários não tenham sido levados. Porém, este banco não fica 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 Periodicamente, é necessário fazer com que os bancos de desenvolvimento, homologação e pré-produção fiquem com dados semelhantes ao banco de produção, para que os testes sejam feitos em cima de dados mais reais, com volumes reais, e para que sejam corrigidos dados inconsistentes destes bancos, principalmente o de desenvolvimento, que sofre operações DML 7) Levar as bases das aplicações para os bancos de homologação, pré-produção e produção À medida que os módulos ou aplicações vão passando pelas etapas de desenvolvimento, homologação, pré-produção e produção, a estrutura da base de dados destas aplicações tem que caminhar para os respectivos bancos. A primeira migração ocorre do banco de desenvolvimento para o banco de homologação, onde a aplicação passará por testes e, posteriormente, PÓS EM REVISTA l 353

6 será validada pelo usuário. Esta migração significa, em nível de banco de dados, passar para o banco de homologação tudo estrutura e dados, que o novo módulo ou iteração ou aplicação necessita. Isto significa que os ADs, juntamente com analistas e desenvolvedores, terão que mapear esta estrutura e dados para esta migração. Uma boa prática é os ADs desenvolverem um template para direcionar este mapeamento. A princípio, a tarefa parece simples. Porém, o novo módulo, além de seus objetos próprios (que podem estar separados em um esquema), pode provocar alterações em objetos de outros módulos ou inserir dados em objetos de outros módulos. Além disso, muitas aplicações utilizam frameworks, cujos dados também devem ser levados para novo banco. Tudo isto traz mais complexidade a esta tarefa de migração. Então, este template, a ser preenchido por ADs, analistas e desenvolvedores, é útil para organizar esta tarefa além de, uma vez efetuado e atualizado nesta fase de homologação, ficar pronto para as migrações para a pré-produção e para produção. 8) Inspecionar os dados Esta tarefa requer do administrador de dados um espírito investigativo. Os ADs, em suas várias pesquisas na base de dados para documentá-lo, ou para verificar se dados necessários para uma dada aplicação já existem na base de dados, ou para verificar algum erro detectado, ou por qualquer outro motivo, podem se deparar com dados incorretos ou indefinidos. Quando os dados estão incorretos, o AD tentará descobrir a origem do problema e, juntamente com os analistas que mantém as aplicações envolvidas, mapear a solução a ser adotada. Esta solução pode envolver apenas uma correção de dados, sem afetar a aplicação em si. Neste caso, os analistas construiriam o script para correção, este seria revisado pelos ADs e, posteriormente, seria executado nos diversos bancos. Em outros casos, a solução envolve correções na própria aplicação, para que a persistência dos dados seja feita corretamente, além da correção dos dados já persistidos com erro. Nestes casos, a área de Administração de Dados passa a ser demandante da área de soluções. 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, porém a base de dados apresenta outros valores persistidos, que diferem da documentação. Então, a princípio, não se sabe o que o valor significa. Os ADs, então, solicitam ao analista responsável pela aplicação a revelação do significado dos valores. Muitas vezes se descobre lacunas na aplicação e outras vezes se descobre que esta passou a persistir novos valores para o atributo, porém não houve atualização da documentação. O resultado, normalmente, além de correções na aplicação e documentação dos dados, é a criação de check constraints que apenas aceitam um conjunto definido de valores para o atributo. Isto evita o surgimento de novos valores que não estejam previstos no banco. A criação de check constraints pode se tornar um padrão estabelecido pela área de dados, quando não há uma tabela auxiliar que contenha a descrição dos valores. Na verdade, o objetivo da inspeção é zelar pela qualidade dos dados, e é um trabalho contínuo da administração de dados. É esta qualidade que traz segurança aos utilizadores do dado. Há ferramentas de qualidade de dados que auxiliam neste trabalho. 3. ESTUDO DE CASO Será descrito, aqui, um caso real de redundância descontrolada de dados. O cenário é a TI de uma empresa que havia desenvolvido e mantinha um grande sistema corporativo, originalmente construído na linguagem Natural e banco de dados DB2 e posteriormente migrado para o banco Oracle. Iremos chamar este primeiro sistema de S1. Num dado momento, foi contratada uma empresa para migrar parte deste S1 para a plataforma Web, com linguagem Java, para disponibilização de vários serviços na Internet. Chamaremos este novo sistema de S2. Como apenas parte do S1 seria migrada, os dois sistemas teriam que funcionar, e, em muitos casos, teriam que se comunicar, isto é: alguns dados inseridos e mantidos no S1 seriam tratados pelo S2 e vice-versa. Como não havia, na empresa, área de Administração de Dados, a empresa contratada era responsável por desenhar e criar todas as bases de dados. Uma determinada tabela auxiliar do S1, que chamaremos de TAB-S1, seria necessária também no S2. Entenda por auxiliar a tabela que contém dados importantes, cujos atributos chaves compõem os registros das tabelas com que a tabela auxiliar se relaciona. Havia as seguintes necessidades: Nem todos os atributos da TAB-S1 eram necessários para S2; Nem todos os registros da TAB-S1 eram necessários para o S2; Havia 10 atributos novos necessários apenas para o S PÓS EM REVISTA

7 Resolveram, então, criar uma tabela na base de dados do S2, que chamaremos de TAB-S2, com alguns atributos pertencentes à TAB-S1 e com atributos novos. Porém, pela dinâmica do negócio da empresa, os registros tratados pelas duas tabelas somente eram considerados válidos se inseridos na TAB-S1. Em outras palavras, todo registro da TAB-S2 teria que existir, primeiramente, na TAB-S1. A figura abaixo, representa o cenário descrito. Segundo relatos de analistas e funcionários que participaram desta etapa do projeto, a criação da TAB-S2 ocorreu devido a um certo sentimento de autonomia do novo sistema, que permeou todo o projeto : cria-se uma nova tabela para o novo sistema e não mexe com a tabela do sistema existente. Os atributos em verde eram os atributos comuns entre as duas tabelas e os atributos em azul, na TAB-S2, eram os atributos novos, necessários apenas para o S2. A criação de uma outra tabela poderia se justificar pelos seguintes motivos : Seria um tipo de especialização, uma vez que há atributos novos, que somente interessam ao SIS2; Apesar de haver redundância, uma vez que temos atributos que são os mesmos nas duas tabelas, esta poderia ser necessária caso o acesso à TAB-S1 fosse muito grande. Seria uma forma de não sobrecarregar a TAB-S1 com os acessos do S2. 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 dados. Estas medidas poderiam ser, em ordem decrescente de segurança, a nível de banco de dados, a nível de aplicação ou a nível de processo. A nível de banco de dados, estas medidas de controle seriam as seguintes: Primeiramente, as chaves das duas tabelas teriam que ser iguais, pois na verdade a tabela é uma só, que foi dividida devido ao desenho e necessidade das aplicações. Além disto, como as duas tabelas faziam relacionamentos com tabelas diferentes, as chaves estrangeiras, levadas para as tabelas relacionadas, deveriam ser iguais; A inserção de novos registros teria que ser feita, primeiramente, na TAB-S1. Na inserção do mesmo registro, na TAB- -S2, a aplicação localizaria, pela chave, o registro na TAB-S1 e os atributos comuns teriam os conteúdos trazidos, via TRIGGER, da TAB-S1. Desta forma, apenas os atributos novos da TAB-S2 poderiam ser alterados via aplicação. 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. Como a exclusão dos registros das tabelas é lógica, e a validade dos registros é controlada pela TAB-S1, a exclusão seguiria a mesma lógica da alteração: assim que se inserisse DATA-FIM na TAB-S1, esta data-fim seria levada, via TRIGGER, para a TAB-S2. Na TAB-S1, como o atributo CODIGO-COMPLETO é uma concatenação dos atributos CODIGO e DV, apenas estes últimos seriam inseridos pela aplicação. O CODIGO-COMPLE- TO também seria inserido via TRIGGER. Estas medidas garantiriam valores iguais para os atributos redundantes. Posteriormente, a instituição passou a ter uma área de Administração de Dados e foi demandado a esta área eliminar a PÓS EM REVISTA l 355

8 TAB-S2. Partindo do pressuposto que os registros equivalentes das duas tabelas teriam valores iguais nos atributos comuns, este trabalho seguiria o seguinte roteiro: Levar, para a TAB-S1, os atributos novos da TAB-S2 e popular estes atributos com os valores contidos na TAB-S2; Criar, na TAB-S1, uma chave única com o atributo CO- DIGO, para que a TAB-S1 pudesse se relacionar com as tabelas que se relacionavam com a TAB-S2, uma vez que este atributo era chave na TAB-S2; Eliminar o relacionamento entre outras tabelas da base com a TAB-S2 e criar, nestas outras tabelas, um relacionamento com a TAB-S1, através da chave única criada no passo anterior; Como segurança, criar uma tabela backup da TAB-S2, com mesma estrutura e dados, e atribuir-lhe o nome BKP-TAB- -S2; Eliminar a TAB-S2; 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: Registros que existiam na TAB-S2 e não existiam na TAB-S1; Divergência de valores de atributos comuns entre as duas tabelas; Registros com DATA-FIM na TAB-S2 que não estavam com DATA-FIM na TAB-S1. Atributo CODIGO-COMPLETO, da TAB-S1, não correspondia à 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 de documentos gerados para usuários externos. Teoricamente, os dados destas tabelas relacionadas teriam que permanecer fiéis aos documentos gerados que os continham. Além disso, caso estes documentos fossem reabertos, por alguma opção da aplicação, após a unificação, ocorreria um erro pelo fato de os dados gravados no documento (dados incorretos, originados da TAB-S2) não constarem na TAB-S1, que seria a única tabela. Então, a unificação ficou no aguardo de a aplicação ser alterada para que este problema fosse contornado. Este caso ilustra como erros na estrutura de dados podem originar problemas que, para serem resolvidos, demandam um grande esforço de manutenção e como é importante a atuação da administração de dados para agir de forma preventiva e zelar por esta estrutura. 4. CONCLUSÃO Diante de todo o exposto, o que podemos concluir, de uma forma genérica, é que, em qualquer instituição, de qualquer área, se é desejável certo nível de qualidade no serviço prestado, 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. Com os dados de uma instituição não é diferente. Não se pode pensar que profissionais, que estejam em outras funções dentro da TI, como desenvolvedores e DBAs, assumam para si a responsabilidade 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, 356 PÓS EM REVISTA

9 domínio, documentação, integração e qualidade dos dados da instituição. REFERÊNCIAS BARBIERI, Carlos. BI2 Business Intelligence Modelagem e Qualidade. Elsevier SERRA, Laércio. A Essência do Business Intelligence. Berkeley SENAC.Modelagem de dados. Senac Nacional TEOREY, Toby. Projeto e Modelagem de Bancos de Dados. Campus NOTAS DE RODAPÉ 1 Professor do Centro Universitário Newton Paiva (iremar.prof@uol.com.br). 2 Pós graduanda em Banco de dados e Business Intelligence no Centro Universitário Newton Paiva.(geannine.heron@hotmail.com). PÓS EM REVISTA l 357