CENTRO UNIVERSITÁRIO VILA VELHA CURSO DE SISTEMAS DE INFORMAÇÃO
DANIEL DUENK NEPOMUCENO
Sistema Integrador de Banco de Dados
Monografia do Trabalho de Conclusão do Curso de Graduação em Sistemas de Informação apresentado ao Centro Universitário Vila Velha, como requisito parcial para obtenção do título de Bacharel em Sistemas de Informação sob orientação do prof. Cristiano Biancardi.
Vila Velha/ES 2007
DANIEL DUENK NEPOMUCENO
Sistema Integrador de Banco de Dados
Monografia do Trabalho de Conclusão do Curso de Graduação em Sistemas de Informação apresentado ao Centro Universitário Vila Velha, como requisito parcial para obtenção do título de Bacharel em Sistemas de Informação.
Aprovado em , de de 2007.
COMISSÃO EXAMINADORA
_______________________________________ Professor Cristiano Biancardi
Mestre em Informática Orientador
_______________________________________ Professora Susiléa Abreu dos Santos Lima Mestre em Informática
_______________________________________ Professora Claudinete Vicente Borges Ferreira Mestre em Informática
RESUMO
Este trabalho propõe o desenvolvimento de um sistema integrador de banco de dados heterogêneos e distribuídos. O objetivo principal do sistema é prover ao usuário uma ferramenta centralizada para consultas, ou seja, o usuário poderá efetuar consultas em diversas fontes de dados heterogêneas e distribuídas de forma transparente, como se estivesse trabalhando num sistema de banco de dados local e centralizado. Para a integração das fontes de dados, foram utilizadas as técnicas de integração de esquemas, gerência de metadados e re-escrita de consultas. O sistema foi projetado e desenvolvido adotando o paradigma orientado a objetos. A documentação da análise e do projeto foi feita utilizando a linguagem UML.
Palavras-chave: Sistemas de informação; integração de banco de dados;
LISTA DE FIGURAS
Figura 2.1 – Modelo de Ciclo de Vida em Cascata ... 21
Figura 2.2 – Passos típicos do processo de execução de uma consulta de alto nível ... 26
Figura 2.3 – Integração de esquemas ... 34
Figura 2.4 – Camada intermediária – Middleware ... 35
Figura 3.1 – O CoDIMS com seus Componentes Básicos ... 38
Figura 3.2 – Processamento de Consulta ... 40
Figura 3.3 – Atual Fluxo de Informação ... 44
Figura 3.4 – Divisão em Camadas ...45
Figura 3.5 – Diagrama de Classes contendo os Wrappers ... 46
Figura 4.1 – Arquitetura do Sistema Integrador ... 51
Figura 4.2 – Processamento da Consulta no Sistema Integrador ... 54
Figura 4.3 – Diagrama de Casos de Uso – Camada de Aplicação ... 56
Figura 4.4 – Diagrama de Casos de Uso – Camada de Integração... 56
Figura 6.1 – Diagrama de Classes – Camada de Aplicação ... 71
Figura 6.2 – Diagrama de Classes – Camada de Integração... 74
Figura 6.3 – Diagrama de Seqüência (Análise) – Cadastrar Usuário ... 77
Figura 6.4 – Diagrama de Seqüência (Análise) – Consultar Usuário ... 77
Figura 6.5 – Diagrama de Seqüência (Análise) – Alterar Usuário ... 78
Figura 6.6 – Diagrama de Seqüência (Análise) – Remover Usuário ... 78
Figura 6.7 – Diagrama de Seqüência (Análise) – Submeter Consulta... 79
Figura 6.8 – Diagrama de Seqüência (Análise) – Cadastrar Fonte de Dados ... 80
Figura 6.9 – Diagrama de Seqüência (Análise) – Consultar Fonte de Dados ... 80
Figura 6.10 – Diagrama de Seqüência (Análise) – Alterar Fonte de Dados... 81
Figura 6.11 – Diagrama de Seqüência (Análise) – Remover Fonte de Dados ... 81
Figura 6.12 – Diagrama de Seqüência (Análise) – Cadastrar Metadados ... 82
Figura 6.13 – Diagrama de Seqüência (Análise) – Consultar Metadados ... 82
Figura 6.14 – Diagrama de Seqüência (Análise) – Alterar Metadados ... 83
Figura 6.15 – Diagrama de Seqüência (Análise) – Remover Metadados ... 83
Figura 6.17 – Diagrama de Seqüência (Análise) – Consultar Mapeamento ... 84
Figura 6.18: Diagrama de Seqüência (Análise) – Alterar Mapeamento ... 85
Figura 6.19: Diagrama de Seqüência (Análise) – Remover Mapeamento ... 85
Figura 7.1: Pacotes ... 86
Figura 7.2: Divisão em 4 camadas... 87
Figura 7.3: Diagrama de Classes – Camada de Aplicação (DP)... 88
Figura 7.4: Diagrama de Classes – Camada de Aplicação (IU)... 89
Figura 7.5: Diagrama de Classes – Camada de Aplicação (GT)... 90
Figura 7.6: Diagrama de Classes – Camada de Aplicação (GD)... 90
Figura 7.7: Diagrama de Seqüência (Projeto) – Cadastrar Usuário... 91
Figura 7.8: Diagrama de Seqüência (Projeto) – Consultar Usuário... 91
Figura 7.9: Diagrama de Seqüência (Projeto) – Alterar Usuário... 92
Figura 7.10: Diagrama de Seqüência (Projeto) – Remover Usuário... 92
Figura 7.11: Diagrama de Seqüência (Projeto) – Submeter Consulta... 93
Figura 7.12: Diagrama de Classes – Camada de Integração (DP)... 94
Figura 7.13: Diagrama de Classes – Camada de Integração (IU)... 95
Figura 7.14: Diagrama de Classes – Camada de Integração (GT)... 96
Figura 7.15: Diagrama de Classes – Camada de Integração (GD)... 97
Figura 7.16: Diagrama de Seqüência (Projeto) – Cadastrar Fonte de Dados... 98
Figura 7.17: Diagrama de Seqüência (Projeto) – Consultar Fonte de Dados... 98
Figura 7.18: Diagrama de Seqüência (Projeto) – Alterar Fonte de Dados... 99
Figura 7.19: Diagrama de Seqüência (Projeto) – Remover Fonte de Dados... 99
Figura 7.20: Diagrama de Seqüência (Projeto) - Cadastrar Metadados (Global).100 Figura 7.21: Diagrama de Seqüência (Projeto) - Consultar Metadados (Global).100 Figura 7.22: Diagrama de Seqüência (Projeto) – Alterar Metadados (Global)...101
Figura 7.23: Diagrama de Seqüência (Projeto) – Remover Metadados (Global).101 Figura 7.24: Diagrama de Seqüência (Projeto) – Cadastrar Metadados (Local)..102
Figura 7.25: Diagrama de Seqüência (Projeto) – Consultar Metadados (Local)..102
Figura 7.26: Diagrama de Seqüência (Projeto) – Alterar Metadados (Local)...103
Figura 7.27: Diagrama de Seqüência (Projeto) – Remover Metadados (Local)...103
Figura 7.29: Diagrama de Seqüência (Projeto) – Consultar Mapeamento...104
Figura 7.30: Diagrama de Seqüência (Projeto) – Alterar Mapeamento...105
Figura 7.31: Diagrama de Seqüência (Projeto) – Remover Mapeamento...105
Figura 7.32: Diagrama de Seqüência (Projeto) – Efetuar Consulta...106
Figura 7.33: Diagrama de Navegação...107
Figura 7.34: Interface padronizada...107
Figura 7.35: Modelo Relacional...109
Figura 7.36: Diagrama de Classes – Pacote Configuração...111
Figura 7.37: Diagrama de Classes – Pacote Persistência...111
Figura 7.38: Diagrama de Componentes...112
Figura 7.39: Diagrama de Implantação...112
Figura 9.1: Janela Login...119
Figura 9.2: Janela Principal...120
Figura 9.3: Janela Cadastro de Usuários...121
Figura 9.4: Janela Cadastro de Fonte de Dados: Ambulatório...121
Figura 9.5: Janela Cadastro de Fonte de Dados: Enfermaria...122
Figura 9.6: Janela Cadastro de Metadados: Ambulatório...122
Figura 9.7: Janela Cadastro de Metadados: Enfermaria...123
Figura 9.8: Janela Cadastro de Metadados: Esquema Global...124
Figura 9.9: Janela Cadastro de Mapeamentos: Ambulatório...124
Figura 9.10: Janela Cadastro de Mapeamentos: Enfermaria...125
Figura 9.11: Janela Efetuar Consulta...126
LISTA DE TABELAS
Tabela 3.1 – Metadados de Exportação do Sistema Placas ... 47
Tabela 3.2 – Metadados de Exportação do Sistema Bobinas ... 47
Tabela 3.3 – Metadados Global ... 48
Tabela 4.1 – Problemas, causas e possíveis soluções ... 50
Tabela 5.1 – Equipamento utilizado na primeira proposta ... 64
Tabela 5.2 – Valor do investimento em hardware da primeira proposta ... 65
Tabela 5.3 – Valor do investimento em software da primeira proposta ... 65
Tabela 5.4 – Valor do investimento com mão-de-obra da primeira proposta ... 65
Tabela 5.5 – Benefícios da primeira proposta ... 66
Tabela 5.6 – Custo total da primeira proposta ... 66
Tabela 5.7 – Equipamento utilizado na segunda proposta ... 67
Tabela 5.8 – Valor do investimento em hardware da segunda proposta ... 68
Tabela 5.9 – Valor do investimento em software da segunda proposta ... 68
Tabela 5.10 – Valor do investimento com mão-de-obra da segunda proposta .... 69
Tabela 5.11 – Benefícios da segunda proposta ... 69
Tabela 7.1 – Dicionário de Dados – Aplicação – Domínio do Problema ... 72
Tabela 7.2 – Dicionário de Dados – Integração – Domínio do Problema ... 75
Tabela 7.3 – Dicionário de Dados – Modelo Relacional ...109
Tabela 8.1 – Controles de segurança ...114
Tabela 9.1 – Esquema Ambulatório ...118
Tabela 9.2 – Esquema Enfermaria ...118
SUMÁRIO 1. INTRODUÇÃO ... 13 1.1 CONTEXTO... 13 1.2 MOTIVAÇÃO ... 13 1.3 JUSTIFICATIVA ... 14 1.4 OBJETIVOS ... 15 1.4.1 Objetivos Gerais ... 15 1.4.2 Objetivos Específicos ...15 1.5 METODOLOGIA ... 15 1.6 ORGANIZAÇÃO DO TRABALHO...16 2. CONCEITOS ... 18 2.1 DESENVOLVIMENTO DE SOFTWARE ... 18
2.1.1 Processo de Desenvolvimento de Software ... 18
2.1.2 Modelo de Ciclo de Vida em Cascata ... 21
2.1.3 Paradigma OO (Orientação a Objetos) ... 22
2.1.4 UML ... 23
2.2 BANCO DE DADOS ... 25
2.2.1 Processamento e Otimização de Consultas ... 25
2.2.2 Tradução de Consultas SQL para Álgebra Relacional ... 27
2.2.3 Sistemas Distribuídos ... 28
2.3 INTEGRAÇÃO DE BANCO DE DADOS ...32
2.3.1 Integração de Esquemas ... 33
2.3.2 Conflitos de Esquema ... 34
2.3.3 Middleware de Integração de Dados ... 35
2.3.4 Wrapper ... 36
3. TRABALHOS RELACIONADOS ... 37
3.1 CoDIMS ... 37
3.1.1 Visão Geral ... 37
3.2 SISTEMA DE ACOMPANHAMENTO DE MATERIAL PRIORITÁRIO DA CST ... 43 3.2.1 Visão Geral ... 43 3.2.2 Camadas ...45 3.2.3 Wrappers ... 46 3.2.4 Integração de Esquemas ... 46 3.2.5 Utilização do sistema ... 49 4. LEVANTAMENTO DE REQUISITOS ... 50 4.1 VISÃO GERAL ... 50
4.2 PROBLEMAS, CAUSAS E POSSÍVEIS SOLUÇÕES ... 50
4.3 DESCRIÇÃO ... 51
4.3.1 Camada de Aplicação ... 52
4.3.2 Camada de Integração ... 52
4.4 METODOLOGIA DE DESENVOLVIMENTO DO SISTEMA ... 55
4.5 ATORES ... 55
4.6 CASOS DE USO ...55
4.6.1 Diagrama ... 55
4.6.2 Descrição dos Casos de Uso ... 56
4.6.3 Descrição detalhada dos Casos de Uso... 57
5. PROPOSTAS TECNOLÓGICAS ... 64
5.1 PRIMEIRA PROPOSTA ... 64
5.1.1 Especificação do Hardware ... 64
5.1.2 Especificação de Software ... 65
5.1.3 Valor do investimento ... 65
5.1.4 Mão-de-obra para desenvolvimento do projeto ... 65
5.1.5 Benefícios ... 66
5.1.6 Custo Total ...66
5.1.7 Prazo de Retorno ... 67
5.2.1 Especificação do Hardware ... 67
5.2.2 Especificação do Software ... 68
5.2.3 Valor do investimento ... 68
5.2.4 Mão-de-obra para desenvolvimento do projeto ... 69
5.2.5 Benefícios ... 69 5.2.6 Custo Total ...69 5.2.7 Prazo de Retorno ... 70 5.3 PROPOSTA ESCOLHIDA ... 70 6. ESPECIFICAÇÃO DA ANÁLISE ... 71 6.1 DIAGRAMA DE CLASSES ... 71 6.1.1 Camada de Aplicação ... 71 6.1.2 Camada de Integração ... 74 6.2 DIAGRAMAS DE SEQÜÊNCIA ... 77 6.2.1 Camada de Aplicação ... 77 6.2.2 Camada de Integração... 80 7. ESPECIFICAÇÃO DO PROJETO ... 86 7.1 ESPECIFICAÇÕES GERAIS ... 86 7.2 DIVISÃO EM PACOTES ... 86 7.3 CAMADA DE APLICAÇÃO ... 88 7.3.1 Diagrama de Classes ...88 7.3.2 Diagramas de Seqüência ... 91 7.4 CAMADA DE INTEGRAÇÃO ... 94 7.4.1 Diagrama de Classes...94 7.4.2 Diagramas de Seqüência ... 98 7.5 DIAGRAMA DE NAVEGAÇÃO ...107 7.6 PADRÕES DE INTERFACE ...107 7.7 MODELO RELACIONAL ...109 7.8 PACOTES UTILITÁRIOS...111 7.9 DIAGRAMA DE COMPONENTES ...112
7.10 DIAGRAMA DE IMPLANTAÇÃO ...112
8. PROJETO DE SEGURANÇA ...113
8.1 AMEAÇAS ...113
8.2 CONTROLES ...114
8.2.1 Descrição dos Controles ...115
9. ESTUDO DE CASO ... 117
9.1 DESCRIÇÃO DO AMBIENTE ...117
9.2 PROBLEMA...117
9.3 EFETUANDO A INTEGRAÇÃO COM O SISTEMA INTEGRADOR...119
10. CONCLUSÃO, CONTRIBUIÇÕES E TRABALHOS FUTUROS...129
1. INTRODUÇÃO
1.1 Contexto
A época atual, denominada comumente como “A Era da Informação”, tem como uma de suas características principais o aumento expressivo dos chamados Sistemas de Informação. Os avanços da tecnologia, dos processos de desenvolvimento de software e a facilidade de comunicação pela Internet contribuíram para a criação de um ambiente propício ao desenvolvimento maciço de novas aplicações.
Como conseqüência, tem-se o aumento considerável na quantidade de informações disponíveis pelo mundo. Contudo, esse crescimento tem sido desorganizado, criando sistemas com bases de dados autônomas, heterogêneas e distribuídas. Autônomas por independerem de outros sistemas para serem utilizadas; cada sistema tem o controle total sobre sua fonte de dados, geralmente não provendo acesso para aplicações externas. Heterogêneas no que se refere às estruturas com as quais foram desenvolvidas, podendo a heterogeneidade ser semântica ou estrutural; semântica no que diz respeito a forma com que os dados do mundo real foram representados na aplicação, por exemplo: uma determinada fonte de dados pode representar o endereço do cliente com três campos, “logradouro”, “numero” e “bairro”, ao passo que outra aplicação pode utilizar uma fonte de dados que represente o mesmo endereço com apenas um campo, genericamente denominado “endereco”; heterogeneidade estrutural se refere ao paradigma utilizado na criação da base dados, podendo ser modelada na forma “relacional”, “orientada a objetos”, e etc.
1.2 Motivação
No contexto acima apresentado, surge o problema da integração de dados, pois em diversas situações, grandes sistemas necessitam capturar e processar informações de outros sistemas, que não são padronizados. Muitas vezes essa integração é feita de modo manual, tendo como responsabilidade do usuário a
localização, consulta, combinação e integração dessas bases, o que gera alto custo e demanda elevada de re-trabalho.
Para solucionar esse problema, a comunidade científica tem se empenhado na pesquisa para o desenvolvimento de ferramentas de software que visem à integração automática de bases de dados heterogêneas, ou que pelo menos auxiliem nesse processo.
Por ser uma área de pesquisa nova, o mercado ainda carece de sistemas eficientes para integração de dados. Os produtos disponíveis atualmente com essa função geralmente são ou muitos específicos, para atenderem um número muito limitado de aplicações, ou são genéricos ao extremo, com o intuito de atender ao máximo os sistemas existentes. (BIANCARDI, 2005)
1.3 Justificativa
Como benefícios da utilização de um sistema integrador, podemos destacar as seguintes vantagens: (MOTRO, 1981):
Os usuários têm uma visão única dos dados integrados.
Possibilidade de integrar diversas fontes de dados sem a necessidade de mudanças nas plataformas tecnológicas existentes.
Realizar o cruzamento de dados para extrair informações relevantes e consequentemente usá-las para tomadas de decisões. Isso amplia visão da empresa para informar, analisar, otimizar e planejar.
Permitem acessar as bases de dados e gerar relatórios específicos do negócio.
A padronização promove melhorias de qualidade dos dados estatísticos disponíveis.
1.4 Objetivos
1.4.1 Objetivos Gerais
O objetivo deste trabalho é desenvolver um sistema que faça a integração de bancos de dados heterogêneos e distribuídos, modelados no paradigma relacional.
1.4.2 Objetivos específicos
Desenvolver um sistema de integração de banco de dados que empregue as seguintes técnicas:
Integração de esquemas;
Gerência de metadados;
Re-escrita de consultas.
A arquitetura do sistema deverá ser composta por duas camadas: Aplicação e Integração. A camada de aplicação será responsável pelo cadastro de usuários, construtores de consultas e ferramentas de visualização de resultados. A camada de integração, como o próprio nome diz, terá por função integrar efetivamente as fontes de dados, utilizando as técnicas descritas anteriormente.
1.5 Metodologia
Para desenvolvimento deste trabalho, precisou-se antes fazer um estudo sobre Banco de Dados, Processamento de Consultas e demais assuntos relacionados à integração de dados. Depois são apresentados trabalhos relacionados à integração de dados.
Por fim, o trabalho traz a especificação de análise e projeto do sistema integrador de banco de dados e a implementação de um protótipo.
1.6 Organização do Trabalho
Este trabalho se encontra organizado da seguinte forma:
O capítulo 2 contém os conceitos fundamentais necessários para compreensão do funcionamento de um Sistema Integrador de Banco de Dados, são eles: processamento e otimização de consultas, banco de dados distribuídos e sistemas de integração de banco de dados. Além desses assuntos, esse capítulo aborda temas relativos ao processo de desenvolvimento de software, como paradigmas de programação, modelos de ciclo de vida, UML etc. que serão utilizados no desenvolvimento do sistema integrador.
No capítulo 3 são apresentadas algumas soluções para o problema de integração de dados. O Sistema de Acompanhamento de Material Prioritário da CST, que integra banco de dados específicos presentes na CST, e o CoDIMS, uma solução ainda em desenvolvimento que busca a integração automática para quaisquer modelos de banco de dados.
O capítulo 4 apresenta o Levantamento dos Requisitos do sistema. São descritas as funcionalidades do sistema, seus casos de usos, atores e etc.
No capítulo 5 serão descritas duas propostas de soluções tecnológicas para o desenvolvimento do sistema.
No capítulo 6 é descrita a especificação da Análise do Sistema Integrador. Na análise são modelados os requisitos em diversos diagramas, como diagrama de classes, seqüência, etc.
O capítulo 7 contém toda a especificação do Projeto do sistema, abordando soluções tecnológicas e a modelagem detalhada do sistema para posterior implementação.
O capítulo 8 contém o Projeto de Segurança, com as práticas necessárias a fim de garantir que o sistema opere de forma segura. São abordadas as principais ameaças ao sistema, formas de controle, etc.
O capítulo 9 apresenta um estudo de caso. Nesse estudo, é descrito um ambiente em que a integração de dados se torna necessária, e explica de maneira prática todo o processo de integração efetuado pelo sistema. Tendo em vista que o estudo de caso irá mostrar todas as funcionalidades do sistema, bem como descrever todos os procedimentos operacionais a serem adotados, neste trabalho não será apresentado um capítulo específico para descrição de um Manual do Usuário. O próprio estudo de caso contempla o conteúdo de um manual.
O capítulo 10 contém a conclusão do trabalho, bem como relação de projetos futuros.
2 CONCEITOS
2.1 Desenvolvimento de Software
Este tópico apresenta ao leitor uma descrição dos principais conceitos relativos ao processo de desenvolvimento de software.
2.1.1 Processo de Desenvolvimento de Software
O processo de desenvolvimento de software pode ser compreendido como um conjunto de atividades relacionadas que têm como finalidade definir, desenvolver, testar e manter um produto de software (BEZERRA, 2003). Os objetivos mais importantes desse processo são: definir quais atividades serão executadas;
quando, como e por quem essas atividades serão executadas; prover mecanismos
de controle e acompanhamento do projeto e padronizar a forma de desenvolvimento do software dentro das organizações.
Abaixo são listadas as atividades típicas no processo de desenvolvimento: (BOOCH, 2006) 1. Levantamento de requisitos 2. Análise de requisitos 3. Projeto 4. Implementação 5. Testes 6. Implantação Levantamento de Requisitos
O objetivo principal do levantamento de requisitos é extrair e compreender quais são as reais necessidades do cliente, estas geralmente denominadas como
requisitos. É definido “o que” o sistema deverá ser capaz de fazer, sem ainda se
clientes tenham uma visão clara e homogênea do problema a ser resolvido, a fim de garantir a definição precisa dos requisitos.
Os requisitos são classificados em funcionais e não-funcionais. Requisitos funcionais representam as funcionalidades explícitas do sistema. Não-funcionais são aqueles que representam características subjetivas que o sistema deve possuir, como confiabilidade, compatibilidade, desempenho, portabilidade, segurança, usabilidade, suporte, aspectos legais, etc.
O produto gerado nesta fase é o documento de requisitos, em que são listados os requisitos do sistema.
Análise de requisitos
Também conhecida como Especificação de Requisitos, essa fase compreende o estudo detalhado dos requisitos levantados na fase anterior. A partir deste estudo, são gerados modelos demonstrando como será o funcionamento do sistema. Vale ressaltar que soluções tecnológicas, tais como produtos de hardware, linguagens de programação e etc. ainda não são abordadas nesta fase.
O produto gerado nessa fase é o documento de especificação da análise, podendo conter, dentre outros artefatos, diagrama de classes / pacotes, dicionários de dados, etc.
Projeto
Nas fases anteriores buscou-se compreender “o que” o sistema irá fazer; já na fase de projeto é necessário definir “como” o sistema irá atender aos requisitos levantados na análise, utilizando os recursos tecnológicos disponíveis.
Em geral, esta fase é dividida em outras duas fases: projeto arquitetural (ou projeto de alto nível) e projeto detalhado. A primeira aborda a organização e estrutura dos módulos no contexto geral do produto enquanto que a segunda
refina o projeto de alto nível para identificar os detalhes individuais de cada módulo.
Todas as questões relativas aos recursos tecnológicos necessários para a construção do sistema devem ser abordadas nesta fase, tais como: linguagem de programação, modelo de banco de dados, estrutura de redes, hardware a ser utilizado, etc.
Implementação
Nesta fase, é feita a codificação do sistema, ou seja, o projeto é traduzido numa forma passível de execução pela máquina. Além da codificação propriamente dita, o desenvolvedor poderá fazer uso de bibliotecas e componentes pré-existentes para agilizar o processo.
Testes
Após a implementação, é necessário testar o sistema para serem descobertos tantos defeitos quanto possível, antes de entregar o produto de software ao cliente. Esta fase consiste numa série de atividades de verificação e validação do
software a fim de descobrir e corrigir erros, garantido assim a entrega de um
produto confiável e de qualidade.
Uma estratégia amplamente utilizada para se testar o sistema se faz dividindo essa fase em três etapas:
Teste de unidade: são testadas as unidades do sistema, visando a identificar erros de lógica e de implementação;
Teste de integração: tem como objetivo testar as interfaces dos módulos, para que possam ser encontrados erros relativos à integração;
Teste de sistema: tem como função principal testar o sistema como um todo, analisando se todos os requisitos foram atendidos.
Implantação
Após ser validado na fase de teste, o sistema é empacotado, distribuído e instalado no ambiente do usuário. Nesta etapa são escritos manuais do sistema, os arquivos são carregados, os dados são importados e há o treinamento dos usuários para utilização do sistema. Pode ocorrer também nesta fase a migração de sistemas e dados preexistentes.
O encadeamento específico dessas atividades para a construção de um software é denominado Modelo de Ciclo de Vida. Atualmente existem diversos modelos, não sendo possível definir qual é o melhor, pois para cada tipo de aplicação pode existir um modelo mais adequado.
O sistema proposto neste trabalho será desenvolvido adotando o Modelo de Ciclo de Vida em Cascata, descrito logo a seguir.
2.1.2 Modelo de Ciclo de Vida em Cascata
O modelo em cascata foi proposto por W.W. Royce em 1970 e tem como principal característica ser um modelo de desenvolvimento de software seqüencial e estático (MATOS, 2002). Todo o processo de desenvolvimento é realizado em etapas bem definidas e pré-determinadas, sendo que cada etapa é pré-requisito para outra.
Devido à adoção de um fluxo de atividades seqüencial, este modelo apresenta os seguintes problemas (BEZERRA, 2003):
Projetos reais dificilmente seguem o fluxo seqüencial proposto por este modelo. Normalmente atividades distintas são executas de maneira simultânea;
Este modelo parte do pressuposto que todos os requisitos podem ser levantados de maneira precisa na fase inicial do processo. Isto na realidade dificilmente acontece; muitas vezes o cliente não descreve de maneira clara a sua real necessidade ou mesmo decide alterar os requisitos no decorrer do projeto. Essa questão é crítica, pois se um determinado requisito não estiver corretamente definido, tal falha será propagada por todas as fases subseqüentes, e só será detectada ao final do processo, quando será entregue o sistema para o cliente.
A escolha do modelo em cascata para a construção deste trabalho é devida pelo fato que todas as etapas de desenvolvimento do sistema serão realizadas em seqüência e não haverá interação com outros usuários.
2.1.3 Paradigma OO (Orientação a Objetos)
Programação Orientada a Objetos (POO) é um paradigma de programação de computadores em que se utilizam classes e objetos, criados a partir de modelos, para representar e processar dados usando programas de computadores. (SANTOS, 2003).
Modelos são representações simplificadas de artefatos do mundo real, como objetos, pessoas, tarefas, processos, conceitos, idéias etc. que são usados comumente por pessoas em seu dia-a-dia e são independentes do uso de computadores.
No POO, os objetos podem ser definidos como coisas concretas ou abstratas, tais como um carro, uma reserva de passagem aérea, uma organização, uma planta de engenharia, um componente de uma planta de engenharia, dentro outros. Do ponto de vista da modelagem de sistemas, um objeto é uma entidade que incorpora uma abstração relevante no contexto de uma aplicação. Um objeto possui um estado (informação), exibe um comportamento bem definido, expresso por um número de operações para examinar ou alterar seu estado, e tem identidade única. Uma classe descreve um conjunto de objetos com as mesmas propriedades (atributos), o mesmo comportamento (operações), os mesmos relacionamentos com outros objetos e a mesma semântica. Objetos que se comportam da maneira especificada pela classe são ditos instâncias dessa classe.
Abaixo segue uma lista de benefícios do uso deste paradigma:
Capacidade de enfrentar novos domínios de aplicação;
Melhoria da interação entre analistas e especialistas;
Aumento da consistência interna dos resultados da análise;
Uso de uma representação básica consistente para análise e projeto;
Alterabilidade e legibilidade;
Apoio à reutilização.
2.1.4 UML
A UML (Linguagem de Modelagem Unificada) é uma linguagem visual criada com o propósito de permitir especificações, visualizações e documentação de artefatos do sistema. É uma ferramenta ideal para conceber, compreender, testar, validar, arquitetar (lógica e fisicamente) e ainda identificar todos os possíveis comportamentos do sistema, especialmente os sistemas orientados a objeto. (MATOS, 2003).
Ela foi criada pela RATIONAL Software e atualmente é um padrão universal no ramo de engenharia de software.
A seguir são relacionados os principais conceitos e diagramas da UML que serão utilizados neste trabalho: (BEZERRA, 2003)
Ator: Identifica qualquer elemento que possua uma responsabilidade, ou seja, que é responsável pela execução de um determinado conjunto de tarefas (representadas por casos de uso).
Caso de Uso: Refere-se a alguma responsabilidade do sistema.
Diagrama de Casos de Uso: Mostra um conjunto de casos de uso e atores e seus respectivos relacionamentos.
Diagrama de Classes: Exibe um conjunto de classes, interfaces e colaborações, bem como seus relacionamentos.
Diagrama de Seqüência: Consiste num diagrama de interação cuja ênfase está na ordem temporal das mensagens. Mensagem é a ação de ativar um método que outro objeto implementa.
Diagrama de Pacotes: Mostra a decomposição do próprio modelo em unidades organizacionais e suas dependências.
Diagrama de Transição de Estados: Mostra todos os estados possíveis de um objeto, os eventos que mudam seu estado, as condições que devem ser satisfeitas antes que uma transição ocorra e as ações durante a vida do objeto.
Diagrama de Componentes: Exibe a organização dos componentes do sistema. Componente é uma parte física do sistema, como o código fonte, biblioteca, tabela de banco de dados etc.
Diagrama de Implantação: Mostra as relações físicas entre componentes de software e hardware no sistema.
2.2 Banco de Dados
Neste tópico serão listados os conceitos relativos ao funcionamento dos Sistemas Gerenciadores de Banco de Dados, como processamento e otimização de consultas, tradução de consultas SQL e banco de dados distribuídos.
2.2.1 Processamento e Otimização de Consultas
Os processamentos de consultas podem ser definidos como uma gama de atividades que têm como objetivo principal extrair dados de um determinado banco de dados. Dentre essas atividades, destacam-se: tradução de uma consulta escrita em linguagem de alto nível para uma expressão que pode ser executada no nível físico do sistema de arquivos, otimização, tradução e validação de consultas. (SILBERCHATZ, 1999)
Toda consulta escrita numa linguagem de alto nível, como SQL, antes de ser executada deve primeiramente passar por uma análise léxica e sintática, e por fim validada. A análise léxica identifica os itens léxicos da linguagem utilizada, como palavras-chave, nomes de atributos, operadores, nomes de relacionamentos, dentro outros; já a análise sintática verifica se a consulta foi escrita conforme as regras sintáticas (regras gramaticais) da linguagem. Posteriormente a consulta deve ser validada, verificando se todos os nomes de atributos possuem significado semântico no esquema do banco de dados a ser consultado.
Após a validação é criada uma representação interna da consulta, geralmente como uma árvore chamada árvore de consulta. A consulta pode ser também representada graficamente como um grafo de consulta. O SGBD, utilizando a árvore de consulta, deve planejar uma estratégia de execução para recuperação do resultado a partir dos arquivos no banco de dados. Esse processo de planejamento de estratégia de execução é chamado de otimização de consultas. O termo “otimização” se refere à busca de uma estratégia razoavelmente eficiente, e não necessariamente a uma consulta ótima, pois esta poderia consumir alto
ANÁLISE LÉXICA, ANÁLISE SINTÁTICA E VALIDAÇÃO OTIMIZADOR DE CONSULTA GERADOR DE CÓDIGO DE CONSULTA PROCESSADOR EM TEMPO DE EXECUÇÃO DO BANCO DE DADOS
O código pode ser:
- Executado diretamente (modo interpretado) - Armazenado e executado posteriormente sempre que necessário (modo compilado) A figura abaixo mostra os passos típicos do processo de execução de uma
consulta de alto nível:
Consulta em linguagem de alto nível
Forma intermediária de consulta
Plano de execução
Código para executar a consulta
Resultado da Consulta
Figura 2.2: Passos típicos do processo de execução de uma consulta de alto nível
O componente otimizador de consultas tem como função elaborar um plano de execução, e o componente gerador de código deve gerar o código para executar
esse plano. O módulo processador em tempo de execução do banco de dados tem o objetivo de executar o código da consulta, quer seja no modo compilado, ou no modo interpretado.
O componente otimizador de consultas será objeto de um trabalho futuro para complementação do sistema integrador.
2.2.2 Tradução de Consultas SQL para Álgebra Relacional
A escolha neste tópico da linguagem SQL para descrição de uma tradução de consulta tem como base o fato de que atualmente essa é a linguagem de consulta mais utilizada nos sistemas de banco de dados comerciais.
Uma consulta escrita em SQL, para ser executada, deve primeiramente ser traduzida em uma expressão equivalente à álgebra relacional estendida. Esta consulta é representada por uma árvore de consulta. Posteriormente a consulta é otimizada. (ELMASRI, 2005).
No processo de tradução, as consultas SQL são decompostas em blocos de
consultas. Estes blocos possuem a estrutura básica “SELECT / FROM /
WHERE”, podendo também incluir cláusulas como “GROUP BY” e “HAVING”. Deste modo, se houver consultas aninhadas dentro de uma consulta, estas serão decompostas em blocos separados.
Considere o seguinte esquema: ALUNOS(matricula, nome, idade, sexo). Abaixo segue uma consulta que mostra todas as alunas mais novas do que o aluno com a menor idade:
SELECT nome FROM ALUNOS
WHERE idade < (SELECT MIN(idade)
FROM ALUNOS WHERE sexo=”M”);
Acima, pode-se observar que a consulta inclui uma subconsulta aninhada, deste modo ela poderia ser divida em dois blocos, interno e externo. O bloco interno seria
(SELECT MIN(idade) FROM ALUNOS WHERE sexo=”M”);
e o bloco externo seria
SELECT nome FROM ALUNOS WHERE idade < c
onde c representaria uma constante que armazena o valor do bloco interno. Nesse exemplo os blocos seriam traduzidos para as seguintes expressões da álgebra relacional:
Bloco interno: MIN idade (σ sexo=”M”(ALUNOS))
Bloco externo: nome(σidade<c)
Após traduzidos, os blocos seriam então separadamente otimizados pelo componente otimizador de consultas.
Para complementação do sistema integrador, outro trabalho futuro é a implementação de um componente responsável pela análise de uma consulta escrita em SQL e a tradução dela para a forma de representação interna utilizada pelo sistema.
2.2.3 Sistemas Distribuídos
Num sistema de banco de dados distribuídos, os bancos de dados são armazenados em diversos computadores, estes comunicados por variados meios como redes de alta velocidade, linhas telefônicas, wireless, dentre outros. (SILBERCHATZ, 1995). Eles não compartilham recursos de hardware, como memória principal, discos e processador.
Os computadores em um sistema de banco de dados distribuído podem variar, quanto ao tamanho e funções, desde estações de trabalho até sistemas de grande porte (mainframe). Eles são denominados como sites ou nós, dependendo do contexto no qual são inseridos.
Segundo (DATE, 2004) este sistema pode ser definido como uma coleção de sites em que:
Cada site é ele próprio um site completo do sistema de banco de dados, mas
Os sites concordaram em atuar juntos, de modo que um usuário em qualquer site pode ter acesso a dados em qualquer lugar da rede, exatamente como se os dados estivessem armazenados no site do próprio usuário.
Na verdade, um banco de dados distribuído “é uma espécie de banco de dados
virtual, cujas partes componentes são fisicamente armazenadas em vários bancos de dados ‘reais’ distintos em vários sites distintos”. (DATE, 2004).
O usuário deverá operar este sistema como se estivesse trabalhando num sistema de banco de dados não distribuídos. Deve-se abstrair do usuário todo o processo de integração desses bancos de dados. Para isso um sistema de banco de dados distribuído deverá atender aos seguintes objetivos:
1. Autonomia local
2. Não dependência de um site central 3. Operação contínua
4. Independência de localização 5. Independência de fragmentação 6. Independência de replicação
7. Processamento de consultas distribuído 8. Gerenciamento de transações distribuído 9. Independência de hardware
10. Independência do sistema operacional 11. Independência da rede
12. Independência do SGBD
Exemplo Ilustrativo:
Considere o sistema de um banco que consiste em quatro agências em quatro cidades diferentes. Cada agência possui seu próprio computador, com um banco de dados abrangendo todas as contas referentes àquela agência.
Cada uma dessas instalações é, assim, um site. Há também um único site que mantém informações sobre todas as agências do banco. Cada agência mantém (entre outras) uma relação conta(Esquema_conta), em que:
Esquema_conta = (nome_agencia, numero_conta, saldo)
O site que mantém informações sobre as quatro agências possui a relação
agencia(Esquema_agencia), em que:
Esquema_agencia = (nome_agencia, cidade_agencia, fundos)
Há outras relações nos diversos sites: neste exemplo elas são ignoradas.
Para ilustrar a diferença entre os dois tipos de transações, consideramos a transação de adicionar 50 reais à conta 1643.001.177 localizada na agência Glória. Se uma transação foi iniciada na agência Glória, ela é então considerada local; caso contrário, será considerada global. Uma transação para transferir 50 reais da conta 1643.001.177 para a conta 0173.001.305, a qual está localizada na agência Vila Velha, é uma transação global, uma vez que contas em sites diferentes sofrem acessos como resultado de sua execução.
Segundo (SILBERSCHATZ, 1999) o que faz dessa configuração um sistema de banco de dados distribuídos são os seguintes aspectos:
Os vários sites estão disponíveis entre si;
Os sites compartilham um esquema global comum, embora algumas relações possam estar armazenadas em alguns sites;
Cada site proporciona um ambiente para execução tanto de transações locais quanto de transações globais;
Cada site roda o mesmo software para o gerenciamento do banco de dados. Caso haja sistemas gerenciadores de banco de dados diferentes rodando nos sites, ou divergências nos esquemas locais, torna-se difícil o gerenciamento de transações globais. Tais sistemas são chamados de sistemas de banco de dados
múltiplos (multidatabase) ou sistemas de banco de dados distribuídos heterogêneos.
Vantagens e Desvantagens:
Como vantagens na utilização de sistemas de banco de dados distribuídos, destacamos as seguintes: (SILBERSCHATZ, 1999)
Compartilhamento de dados. A maior vantagem de um sistema de banco de dados distribuído é criar um ambiente em que os usuários de um site podem ter acesso a dados residentes em outros sites.
Autonomia. Cada site pode manter certo nível de controle sobre os dados que estão armazenados localmente. Em sistemas centralizados, o administrador de banco de dados central é quem gerencia o banco de dados. Em sistemas de bancos de dados distribuídos há um administrador geral responsável pelo banco como um todo. Uma parte dessa responsabilidade é delegada ao administrador local de cada site.
Disponibilidade. Se um site sai do ar em um sistema distribuído, os demais sites podem continuar em operação. Particularmente, se os itens de dados são replicados em diversos sites, uma transação que precise de um item de dado em particular pode encontrar tal item presente em diversos sites. Assim, a queda de um site não implica, necessariamente, a queda do sistema.
Como principal desvantagem, tem-se o aumento da complexidade na coordenação entre o sites. Esse aumento de complexidade se dá por diversas formas: (SILBERSCHATZ, 1999)
Custo de desenvolvimento de software. É mais difícil implementar sistemas de bancos de dados distribuídos, portanto o custo é mais alto.
Maior possibilidade de bugs. Como os sites que constituem o sistema distribuído operam em paralelo, torna-se difícil garantir a precisão dos algoritmos, especialmente durante a ocorrência e recuperação de falha em parte do sistema.
Aumento do processamento e overhead. A troca de mensagens e processamento adicional necessários à coordenação entre sites são uma forma de overhead que não ocorre nos sistemas centralizados.
2.3 Integração de Banco de Dados
Muitas aplicações necessitam fazer uso de informações que estão armazenadas em diversas fontes de dados. Essas fontes podem se diferenciar quanto à tecnologia utilizada e a representação interna de seus dados. Para proporcionar interoperabilidade entre esses sistemas heterogêneos, deve-se estabelecer uma visão global e uniforme para os dados e serviços (KALINICHENKO, 1999).
Algumas vantagens de se utilizar um sistema integrador (MOTRO, 1981):
Os usuários têm uma visão única dos dados integrados.
Possibilidade de integrar diversas fontes de dados sem a necessidade de mudanças nas plataformas tecnológicas existentes.
Realizar o cruzamento de dados para extrair informações relevantes e consequentemente usá-las para tomadas de decisões. Isso amplia visão da empresa para informar, analisar, otimizar e planejar.
Permitem acessar a base de dados e gerar relatórios específicos do negócio.
A padronização promove melhorias de qualidade dos dados disponíveis.
Uma abordagem para integração dessas bases é a utilização de três camadas semelhantes as do ambientes cliente/servidor (BARBOSA, 2001): uma camada correspondente ao sistema integrador, outra camada representando as fontes de dados e uma camada intermediária que tem o papel de integrar as fontes de dados. Esta última camada é geralmente citada como mediador, e tem a finalidade de fundir informações de fonte de dados heterogêneos, removendo e resolvendo inconsistências (PAPAKONSTANTINOU, 1996). Em suma, a camada intermediária funciona como um middleware de integração de dados.
2.3.1 Integração de Esquemas
Quando esquemas de fontes de dados heterogêneas são comparados, os esquemas locais apresentarão conflitos, que surgem devido a representações não coordenadas de objetos do mundo real. Esses conflitos devem ser tratados durante a integração dos esquemas (HEPNER, 1995). No processo de integração, todos os esquemas dos bancos de dados devem estar descritos em um mesmo modelo, denominado Modelo de Dados Comum (MDC) (BARBOSA, 2001).
Num sistema de integração de dados, os esquemas podem ser distribuídos em quatro níveis, conforme mostrado no diagrama seguinte:
Figura 2.3 Integração de esquemas (BARBOSA, 2001)
O esquema conceitual de cada fonte de dados é denominado esquema local. O
esquema de exportação consiste no esquema local transformado no MDC. O esquema global, descrito no MDC, é o resultado da integração de todos os
esquemas de exportação. A partir do esquema global, podem ser definidas visões para grupos de usuários específicos, que correspondem ao esquema externo.
2.3.2 Conflitos de Esquema
Os conflitos de esquema podem ser divididos em dois grupos (BARBOSA, 2001):
a) Conflito de nome:
Homônimos: ocorre quando o mesmo nome é usado por diferentes conceitos. Por exemplo, o termo “mídia” em uma biblioteca pode significar revistas e jornais e em outra apenas vídeo.
Sinônimos: ocorre quando o mesmo conceito é descrito por diferentes nomes. Por exemplo, uma biblioteca usa o termo “referências” enquanto outra usa “bibliografia”.
b) Conflito estrutural: ocorre quando o mesmo conceito é representado por
diferentes estruturas ou diferentes comportamentos. Por exemplo, em uma biblioteca, o número de vezes que um livro foi emprestado é dado por um atributo do livro, enquanto que em outra biblioteca ele deve ser calculado por um método, quando necessário.
2.3.3 Middleware de Integração de Dados
Middleware pode ser definido como um componente de software que tem a função
de interligar processos clientes a processos servidores, disponibilizando um conjunto de serviços e visando a reduzir a complexidade do desenvolvimento e da execução de uma aplicação (BIANCARDI, 2001). Também pode ser visto como uma ferramenta que “libera os desenvolvedores de se envolver com detalhes de
cada fonte” (LINTHICUM, 1997), sendo uma camada que existe entre a aplicação
cliente e as complexidades da rede, do sistema operacional e dos possíveis servidores de recursos, em particular os servidores de dados.
Figura 2.4 - Camada intermediária - Middleware.
Middleware para integração de dados fornece informações integradas, sem que
seja necessário fazer a integração das fontes de dados. Isso significa que essas fontes não precisam sofrer quaisquer tipos de alterações, elas apenas devem prover acesso para consultas à camada middleware, e esta fica responsável para fazer a integração das informações capturadas. O middleware de integração deve
possuir mecanismos de acesso, processamento, homogeneização e integração das informações das fontes de dados, permitindo assim que o usuário manipule o sistema de forma transparente, ou seja, não será preciso conhecer detalhes de cada banco de dados, tampouco será necessária a interação direta com essas bases.
2.3.4 Wrapper
A principal função do Wrapper é encapsular uma determinada fonte de dados para que ela possa ser manipulada de maneira mais conveniente (BARBOSA, 2001). Através de seu uso uma fonte de dados é transformada numa forma mais estruturada. Os wrappers também podem representar uma interface simplificada, para adicionar funcionalidade ou para expor alguma das interfaces internas de uma fonte de dados.
Segundo (WELLS, 1996), os wrappers são classificados em classes, conforme a sua funcionalidade. Dentre elas, destacamos as seguintes:
Genérica: que se refere às operações de acordo com o tipo da fonte de dados;
Fonte-específica: que se refere às operações de acordo com o conteúdo da fonte de dados;
Estrutura de controle: que se refere ao modo em que as requisições e as respostas são passadas;
Relatório de erros: que pode ser retornado ao componente que o chamou. Para a seleção de um tipo de wrapper a ser utilizado, é necessário analisar as características das fontes de dados, como arquitetura interna, funções, documentação etc.
3 TRABALHOS RELACIONADOS
Neste capítulo são apresentadas duas soluções para o problema de integração de dados. O Sistema de Acompanhamento de Material Prioritário da CST, que integra banco de dados específicos presentes na CST, e o CoDIMS, uma solução ainda em desenvolvimento que busca a integração automática para quaisquer modelos de banco de dados.
3.1 CoDIMS
3.1.1 Visão Geral
O CoDIMS
(
Configurable Data Integration Middleware System) pode ser definidocomo um ambiente flexível e configurável para o desenvolvimento de sistemas de integração de banco de dados distribuídos e heterogêneos. (BARBOSA, 2001). Este projeto foi proposto pelo professor da UFES Álvaro César P. Barbosa em sua tese de doutorado. O detalhamento e a implementação dos componentes do CoDIMS tem sido realizado por diversos acadêmicos e profissionais da área da computação.
Os componentes básicos do CoDIMS são Controle, Acesso aos Dados, Gerência de Metadados e Processamento de Consultas; estes devem existir em todas configurações. Além deles, diversos outros componentes podem ser incluídos.
Figura 3.1: O CoDIMS com seus Componentes Básicos (SILVESTRE, 2005)
A seguir segue uma breve descrição do funcionamento de cada componente do CoDIMS.
3.1.2 Componentes Componente Controle
Este componente é a essência do CoDIMS, pois é ele que provê todos os mecanismos necessários para implementação das configurações física e lógica do ambiente.
Seguem abaixo as principais funções deste componente:
Registrar a configuração do sistema, através da qual são definidas as configurações física e lógica;
Garantir a consistência da configuração, verificando se todos os serviços a serem solicitados por um componente bem como aqueles definidos no
workflow foram oferecidos por outro componente;
Escalonar e gerenciar os serviços a serem executados pelo sistema, quando for submetida uma requisição pelo usuário;
Repassar as mensagens recebidas de outros componentes para o componente destino;
Receber os comandos submetidos pela aplicação cliente, através de uma API.
Componente Gerência de Metadados
Esse componente tem como função principal armazenar, gerenciar e viabilizar o acesso aos metadados do sistema integrador. (BARBOSA, 2001)
Metadados, de uma maneira simples, podem ser definidos como “dados sobre dados”. Eles descrevem de uma forma concisa as informações sobre a estrutura dos dados armazenados no sistema, contendo informações como a organização e a estruturação dos dados, o tipo de cada item de dados, a função que
determinado conjunto de dados exerce no sistema, dentre outras. (SILVESTRE, 2005).
No CoDIMS os metadados são divididos em quatro níveis:
Metadados das Fontes de Dados
Metadados de Exportação
Metadados Global
Metadados Externos
O Componente Gerência de Metadados tem relação íntima com o componente Re-escritor de consultas, pois é através dele que o re-escritor obterá as informações sobre a estrutura de cada fonte de dados, estas que servem como fontes necessárias para criação de consultas específicas para cada banco de dados.
Componente Processamento de Consultas
O componente Processamento de Consultas é o responsável por transformar uma consulta escrita numa linguagem de alto nível em uma estratégia eficiente de execução. Esse processo deve levar em consideração as características de cada fonte de dados, pois a heterogeneidade e a descentralização desses bancos influenciam de forma crítica no desempenho das consultas.
Para que haja uma melhor gerência do processo, as consultas de entrada do sistema geralmente são decompostas em sub-consultas de menor complexidade.
Por efetuarem tarefas específicas, os serviços de processamentos de consultas são divididos em quatro módulos: analisador, re-escritor, otimizador e processador.
Analisador
O componente analisador tem por função verificar a consulta global submetida, analisando os aspectos sintáticos e léxicos da consulta, utilizando para isso as informações contidas nos metadados. Caso haja algum erro na análise da consulta, a mesma é rejeitada e uma mensagem de erro é retornada para a aplicação com seu devido motivo de rejeição. Podemos citar como possíveis motivos de rejeição de uma consulta erros de sintaxe, de semântica ou de tipos incorretos.
Re-escritor
Utilizando o grafo de consulta global e as informações contidas nos metadados globais e dos metadados de exportação das fontes de dados envolvidas na consulta, este componente re-escreve a consulta submetida, agrupando as informações que devem ser fornecidas para cada fonte de dados.
O processo de re-escrita consiste na transformação da consulta global em uma árvore de operação em que cada nó folha representa uma fonte de dados. O nó raiz representa o resultado da consulta e os outros nós não folhas representam os resultados intermediários.
O Re-escritor agrupa as sub-consultas por fonte de dados de forma que uma, e apenas uma sub-consulta, seja enviada a cada fonte de dados para cada consulta global submetida.
Otimizador
Tendo como base o grafo gerado pelo re-escritor, o componente otimizador produz um plano de execução otimizado para a consulta. Para se encontrar um plano de execução ótimo o otimizador faz uma gama de permutações com os operadores da árvore de operação, gerando assim diversos outros planos de execução (GOMES, 2005). O papel fundamental do componente é encontrar uma estratégia que seja ótima.
Encontrar um plano de execução que seja de fato ótimo pode não ser tão fácil dependendo da complexidade da consulta e da quantidade de fonte de dados envolvidas na consulta. Neste caso, cabe ao otimizador escolher uma boa estratégia ou, na pior das hipóteses, evitar as péssimas estratégias.
O processo de seleção das estratégias tem como base as estimativas dos custos de execução das ordenações previamente definidas como candidatas. Os planos de execução são equivalentes, no sentido de fornecerem os mesmos resultados para consulta, porém eles diferem na ordem de execução das operações, de forma que os custos despendidos podem variar. O objetivo fundamental do otimizador é escolher a estratégia que possua o menor custo.
O modelo de seleção baseada em estimativa de custo requer da aplicação um bom conhecimento acerca do ambiente, como: comunicação e estatísticas sobre os dados das fontes de dados, tamanho estimado dos resultados intermediários, etc.
O plano de execução otimizado para a consulta é denominado árvore de execução. Ele servirá de entrada para o componente processador, descrito no próximo tópico.
Processador
O componente processador tem como objetivos principais enviar as sub-consultas existentes no plano de execução para o componente Acesso aos Dados, receber os resultados dessas sub-consultas, realizar a integração destes resultados e por fim fornecer à aplicação cliente o resultado final da consulta.
O Sistema Integrador, tema deste trabalho, pode ser considerado uma versão enxuta do CoDIMS. Devido a grande quantidade de componentes e recursos propostos, e a alta complexidade de seu funcionamento, o CoDIMS tem sido
objeto de pesquisa de muitos profissionais da computação e há um grande esforço para conseguir de fato implementá-lo.
Dessa forma, buscou-se neste trabalho desenvolver um sistema de integração de dados simples, porém funcional, que implementasse apenas as funcionalidades essenciais; dentre elas destacamos a gerência de metadados, re-escrita de consultas e mecanismo de acesso aos dados (wrappers).
3.2 Sistema de Acompanhamento de Material Prioritário da CST
3.2.1 Visão Geral
Este sistema de integração de banco de dados foi proposto para integrar duas fontes de dados presentes na Companhia Siderúrgica de Tubarão (CST). Trata-se de um sistema que centraliza consultas de materiais considerados como prioridade de processamento (CAMPIOTO, 2007).
Na CST, material prioritário corresponde a todo material com data limite de processamento vencido. Atualmente, a empresa possui dois sistemas de acompanhamento de material: Sistema de Placas e Sistema de Bobinas, cada um com seu respectivo banco de dados.
O desenvolvimento de um sistema para integração desses bancos de dados tornou-se necessário pois havendo a necessidade de se consultar o material que compõe uma carteira de pedido, não há como obter do sistema estes dados dispostos de uma forma centralizada. Para consulta de um material prioritário do tipo bobina, deve-se acessar o Sistema de Bobinas, e para consulta de material prioritário do tipo placa, deve-se acessar o Sistema de Placas. Desta forma, caso se deseje consultar todo material prioritário, independente do tipo, faz-se necessária a integração manual dos resultados obtidos nas consultas dos dois sistemas.
O processo atual do tratamento das informações desses sistemas é mostrado no esquema a seguir. Como será observado, a integração das fontes de dados é realizada manualmente utilizando ferramentas como planilhas eletrônicas.
3.2.2 Camadas
O sistema é divido em duas camadas: Camada de Aplicação e Camada
Middleware. A camada middleware tem como função acessar a camada que
engloba as fontes de dados.
3.2.3 Wrappers
Para acesso às fontes de dados são definidos dois wrappers: WrapperBobina e WrapperPlaca, conforme mostrado no diagrama de classes abaixo:
Figura 3.5: Diagrama de Classes contendo os Wrappers (CAMPIOTO, 2007)
3.2.4 Integração de Esquemas
Para integração de esquemas são utilizados dois tipos de metadados: Metadados Global e Metadados de Exportação.
Metadados de Exportação:
Tabela 3.1: Metadados de Exportação do Sistema Placas
Tabela Atributo Tipo
Placa no_contr char(7)
no_item char(2) cd_cloct char(6) nm_cloct char(14) cd_vtran char(2) modal char(10) dt_prccs_limt_cndng date dt_prccs_limt_hsm date no_slab char(12)
Tabela 3.2: Metadados de Exportação do Sistema Bobinas
Tabela Atributo Tipo
Bobina no_contr char(7)
no_item char(2) cd_cloct char(6) nm_cloct char(14) cd_vtran char(2) modal char(10) dt_prccs_limt_divdl date dt_prccs_limt_hspl date dt_prccs_limt_shopp_judge date dt_deliv_reply date dt_deliv_order date no_coil char(12) no_slab char(12)
Metadados Global:
Tabela 3.3: Metadados Global
Tabela Global Atributo Global Tabela-Exportação Tipo
Placa-Glob no_contr Placa String
no_item Placa String
cd_cloct Placa String
nm_cloct Placa String
cd_vtran Placa String
modal Placa String
dt_prccs_limt_cndng Placa String
dt_prccs_limt_hsm Placa String
no_slab Placa String
Bobina-Glob no_contr Bobina String
no_item Bobina String
cd_cloct Bobina String
nm_cloct Bobina String
cd_vtran Bobina String
modal Bobina String
dt_prccs_limt_divdl Bobina String
dt_prccs_limt_hspl Bobina String
dt_prccs_limt_shopp_judge Bobina String
dt_deliv_reply Bobina String
dt_deliv_order Bobina String
no_coil Bobina String
3.2.5 Utilização do sistema
Para efetuar a consulta do material prioritário, o sistema possui uma consulta global pré-definida. Essa consulta é construída com base na linguagem SQL.
Select no_contr, no_item, no_coil, no_slab, cd_cloct, nm_cloct, cd_vtran, modal,
dt_prccs_limt_cndng, dt_prcss_limt_hsm, dt_prccs_limt_divdl, dt_prcss_limt_hspl, dt_prccs_limt_shopp_judge, dt_deliv_reply, dt_deliv_order
From Placa_Glob P, Bobina_Glob B
Where P.pedido = B.pedido and P.item = B.item and P.no_slab = B.no_slab
Este sistema tem como função atender de forma simples uma necessidade específica de integração de fontes de dados na CST. O Sistema Integrador, proposto neste trabalho, da mesma maneira propõe a integração de banco de dados de forma simples, contudo buscou-se construí-lo de maneira que ele pudesse integrar quaisquer tipos de fontes de dados heterogêneas e distribuídas, desde que sejam construídas utilizando o modelo relacional. Assim, o sistema integrador pode ser considerado uma versão aperfeiçoada do sistema anteriormente estudado.
4. LEVANTAMENTO DE REQUISITOS
4.1 Visão Geral
O Sistema Integrador de Banco de Dados tem como principal objetivo prover acesso a diversas fontes de dados heterogêneas e distribuídas de forma transparente aos usuários. Essa transparência significa que os usuários manipulariam várias bases de dados como se estivessem manipulando apenas uma.
Para que isso seja possível, é preciso que seja criado um sistema que funcione como uma camada (middleware) entre a aplicação que está sendo manipulada pelo usuário e as fontes de dados envolvidas.
A manipulação das bases de dados consiste de forma geral em realizar consultas do tipo “seleção” nos bancos de dados integrados. O sistema não provê opções de consultas do tipo “atualização”, “adição” e “remoção”, pois estas são de responsabilidade dos mantenedores de cada fonte de dados.
4.2 Problemas, causas e possíveis soluções
A tabela abaixo apresenta os principais problemas levantados, suas causas e possíveis soluções, no que se refere à manipulação de bancos de dados distribuídos e heterogêneos.
Tabela 4.1: Problemas, causas e possíveis soluções
PROBLEMAS LEVANTADOS CAUSAS POSSÍVES SOLUÇÕES
Esforço excessivo na integração manual de informações.
Dados armazenados em diversas fontes de dados heterogêneas e distribuídas, o que obriga o usuário a
manipular separadamente cada fonte de dados para
Criar processo informatizado que realize o acesso e a integração das fontes de dados de forma automática e transparente ao usuário.
PROBLEMAS LEVANTADOS CAUSAS POSSÍVES SOLUÇÕES continuação
posteriormente integrar as informações levantadas. Demasiado desperdício de
tempo e materiais de escritório (papel, toner, etc.)
Dificuldade na integração das informações, que leva os usuários a integrarem
manualmente as informações por meio de planilhas ou mesmo por materiais impressos.
Automatizar o processo de integração dos bancos de dados, poupando esforço do usuário e minimizando gastos desnecessários.
Dificuldade em gerar relatórios gerenciais a partir de bancos de dados heterogêneos.
Informações dispersas e não padronizadas nas fontes de dados
Prover ferramenta que faça o levantamento dessas
informações de forma automatizada.
4.3 Descrição
A arquitetura do sistema será divida em duas camadas, conforme mostrado no esquema abaixo:
4.3.1 Camada de Aplicação
Esta camada implementará as funcionalidades de cadastro de usuários, construtor de consultas e visualizador de resultados.
O cadastro de usuários tem por função gerenciar os dados dos usuários que utilizarão o sistema. Os usuários são classificados em “administrador” e “usuário”, sendo suas responsabilidades descritas mais detalhadamente na seção que trata sobre os atores do sistema.
O construtor de consultas oferece aos usuários uma interface amigável para montagem de consultas. Isso retira do usuário a obrigação do conhecimento de uma linguagem de consulta, como a SQL. As consultas serão montadas sobre um esquema global, originado da integração dos esquemas locais, dando a impressão ao usuário que ele está operando num sistema local e centralizado.
Os resultados das consultas efetuadas no sistema serão manipulados por um componente denominado visualizador de resultados, que proporcionará ao usuário optar pela visualização do resultado em diversas formas, como relatórios, planilhas, arquivos em formato .pdf, texto etc.
4.3.2 Camada de Integração
Esta camada é composta pelos componentes que efetivamente realizam a integração das fontes de dados. Ela é responsável por implementar as técnicas de integração propostas para o sistema, são elas: gerência de metadados, integração de esquemas e re-escrita de consultas.
Gerência de Metadados
Para gerenciar os metadados, o sistema integrador utilizará dois tipos de esquemas:
Esquema global: Possui todas as informações (metadados) de todas as tabelas globais e seus respectivos campos. Esse esquema global dá a impressão ao usuário que ele está manipulando apenas um banco de dados centralizado. Todas as consultas do usuário são efetuadas sobre esse esquema.
Esquema local: Armazena os metadados das tabelas e campos de cada fonte de dados.
Integração de Esquemas
A integração do esquema global com os esquemas locais será realizada por um componente específico denominado mapeamento.
Re-escrita de consultas
Refere-se ao processo de re-escrita de uma consulta montada sobre um esquema global em diversas subconsultas, cada uma gerada sobre um esquema local que será executada em uma fonte de dados específica. No sistema integrador, haverá um componente específico responsável por esta tarefa.
Outro componente importante utilizado no sistema é o wrapper. Ele será responsável por acessar uma determinada fonte de dados, submeter uma consulta, capturar e devolver o resultado da consulta para o sistema integrador.
A seguir é mostrado um esquema de como é feito o processamento de uma consulta no Sistema Integrador.
