UNIVERSIDADE FEDERAL DE SANTA CATARINA CENTRO: TECNOLÓGICO DEPARTAMENTO: INFORMÁTICA E ESTATÍSTICA DISCIPLINA: PROJETOS I ALUNOS: MICHEL LEITE DE ÁVILA RESUMO DE ARTIGO NOME: Extracting Entity Relationship Diagram from a Table-based Legacy Database ANO: 2005 AUTOR: Dowming Yeh, Yuwen Li INSTITUIÇÃO: National Kaohsiung Normal University LINK: www.inf.ufsc.br/~mlavila/EntityRelationship.pdf Índice ÍNDICE ......................................................................................................................................... 2 TEMA PRINCIPAL DO ARTIGO ............................................................................................. 3 RESUMO ...................................................................................................................................... 4 A ENGENHARIA REVERSA DE BANCOS DE DADOS ...................................................................... 4 O CASO DE ESTUDO .................................................................................................................... 5 PREPARAÇÃO DO PROJETO ......................................................................................................... 5 EXTRAÇÃO DA ESTRUTURA DOS DADOS ..................................................................................... 5 EXTRAÇÃO DAS CHAVES............................................................................................................. 6 EXTRAÇÃO DAS RESTRIÇÕES ...................................................................................................... 6 CONCEITUALIZAÇÃO DA ESTRUTURA DOS DADOS ...................................................................... 7 TRABALHOS RELACIONADOS ..................................................................................................... 7 CONCLUSÕES ............................................................................................................................ 9 Tema principal do artigo O artigo propõe um processo de extração de um ER de um banco de dados com pouca informação sobre os campos, e nenhuma informações sobre as chaves, já que pesquisas recentes sobre engenharia reversa de bancos de dados presumem a disponibilidade de informações completas sobre os atributos e chaves primárias e estrangeiras do esquema. Este processo se utiliza das próprias tabelas do banco de dados e de telas de formulários do sistema. Resumo A Engenharia Reversa de Bancos de Dados O processo de engenharia reversa de bancos de dados concentra seus esforços na construção de um modelo ER, que representa os relacionamentos entre as entidades persistidas. No entanto, a descoberta de alguns desses relacionamentos exige conhecimento a respeito do domínio do sistema, bem como a análise de seu código fonte. Costuma-se dividir o processo de engenharia reversa de bancos de dados, doravante ERBD, nos passos abaixo descritos: Preparação do projeto: Coleta e organização de todo o conjunto de dados do banco; Nome, domínio e tamanho dos campos; Chaves primárias e estrangeiras; Restrições na estrutura dos dados; Extração da estrutura dos dados: Extração do esquema do banco de dados; DDL, se disponível, é de grande valia; Análise dos dados; Formulários do sistema; Código fonte; Conceitualização da estrutura dos dados: Transformação do esquema lógico dos dados em conceitual, representado por um ER; Conceitualização básica: Extração dos conceitos relevantes do esquema; Normalização conceitual: Reestruturação do esquema conceitual em uma forma mais simples e inteligível. O caso de estudo O sistema alvo foi desenvolvido em dBase III, cuja documentação inadequada e desatualizada impede a construção de um novo modelo relacional completo. Os dados originais são carregados no SQL Server, possibilitando a análise através de comandos SQL. Os atributos são comparados com os formulários do sistema, ou decompostos, no intuito de extrair informações semânticas a respeito dos mesmos, o que é seguido pela determinação de chaves primárias, estrangeiras e outras formas de restrição. Finalmente, é gerado um esquema ER inicial, sobre o qual será aplicado conhecimento sobre o domínio do sistema, originando a estrutura conceitual completa. Preparação do Projeto A comparação entre formulários e atributos ajuda a compreender o significado destes. No entanto, nem todos os atributos estão representados nos formulários do sistema. Neste processo, dados são inseridos através do sistema que os armazena em seu banco de dados legado. Posteriormente este banco legado é carregado no SQL Server para análise. Para automatizar o procedimento de extração, são criadas quatro tabelas no SQL Server para armazenar informações sobre formulários, campos de formulários, tabelas, e campos de tabelas do sistema legado. Extração da estrutura dos dados Neste passo, os campos dos formulários são comparados com os campos das tabelas, no intuito de se descobrir o significado dos atributos do banco legado. Como os campos dos formulários e os campos das tabelas estão disponíveis nas tabelas criadas durante a etapa de preparação do projeto, esta comparação é feita automaticamente, via SQL. Como nem todos os campos dos formulários têm relação direta com campos das tabelas, uma verificação mais minuciosa é necessária. Nestes casos, verifica-se se o conteúdo de um determinado campo do formulário está dentro de algum dos campos da tabela, ao invés de comparar os conteúdos integralmente. O exemplo dado é do campo do formulário relativo a uma senha, que não foi encontrada em nenhum campo das tabelas pela comparação integral do conteúdo. Após a busca, descobriu-se um campo nas tabelas cujo conteúdo continha a senha, dentre outras informações concatenadas. Assim como existem campos de formulários que não são persistidos diretamente em um campo de tabela, há campos nas tabelas que não recebem seus conteúdos diretamente de formulários. Nestes casos, descobrir a origem destes atributos requer a análise dos próprios dados e do código fonte. Extração das chaves A construção dos relacionamentos entre as entidades representadas nos dados das tabelas requer a descoberta das chaves primárias e estrangeiras. Sistemas dBase mantém os índices em arquivos separados, sendo a análise destes o início do processo de eleição das chaves primárias e estrangeiras. Arquivos de índice sem valores duplicados são definidos como chaves candidatas. Em caso de mais de uma chave candidata, será escolhida a que envolver o menor número de atributos. Para tabelas sem arquivo de índices, a eleição de chaves é feita através da análise direta dos dados da tabela a procura de campos, ou combinações de campos, cujos valores não se repitam. Em seguida, todas as tabelas são percorridas para se descobrir quais delas fazem referência às chaves primárias há pouco definidas, definindo assim as chaves estrangeiras. Extração das restrições O primeiro objetivo na etapa de extração das restrições é a identificação das cardinalidades entre as chaves primárias e estrangeiras. Se o valor de uma chave primária "A" se relaciona apenas com um valor da chave estrangeira "B", então diz-se que "A" e "B" têm uma cardinalidade um-para-um (1..1). Se o valor da chave primária "A" se relacionar com mais de um valor da chave estrangeira "B", então diz-se que "A" e "B" têm uma cardinalidade um-para-muitos (1..*). Conceitualização da estrutura dos dados Ao decorrer de um projeto de banco de dados, é comum a divisão de uma entidade em várias tabelas. Atributos multi-valorados, por exemplo, são separados de suas entidades para formar outra tabela, num processo chamado divisão vertical. O mesmo ocorre quando entidades são especializadas ou generalizadas em hierarquias, gerando tabelas diferentes. Esta última é chamada divisão horizontal. Relacionamentos cuja cardinalidade é muitos-para-muitos são transformados diretamente em tabelas, enquanto que relacionamentos cuja cardinalidade é um-para-um ou um-para-muitos são representados nas próprias tabelas das entidades relacionadas, via chaves estrangeiras. A pista para fundir tabelas divididas verticalmente é a chave primária, que é a mesma da entidade original. Após identificadas as tabelas com chaves primárias iguais, a decisão por fusão ou não exige conhecimento sobre o domínio dos dados. A pista para fundir tabelas divididas horizontalmente são as similaridades entre tabelas no que diz respeito a seus atributos e chave primária. Entidades generalizadas ou especializadas geralmente dão origem a tabelas com a mesma chave primária, vários atributos iguais e alguns atributos particulares a cada tabela. Elencadas as tabelas similares, verifica-se se estas foram divididas de acordo com alguma hierarquia. O passo final no processo de conceitualização da estrutura dos dados consiste na identificação de relacionamentos não descobertos nos passos anteriores. Relacionamentos muitos-para-muitos são transformados em tabelas cuja chave primária é composta pelas chaves primárias de cada entidade relacionada. Logo, tabelas cuja chave primária é composta por chaves estrangeiras de outras tabelas podem estar representando relacionamentos escondidos. Trabalhos Relacionados Grande parte das pesquisas na área baseiam-se na utilização do esquema relacional como entrada principal. No entanto, a manutenção de um banco de dados depende do conhecimento que se tem sobre suas características. A semântica de seus atributos é vital para a compreensão do funcionamento do sistema, e geralmente é pobre ou até mesmo inexistente. Tal fato justifica abordagens novas que utilizam a análise dos formulários do sistema para ajudar na reconstrução de esquemas ER. O trabalho de Alhajj aborda a ERBD pela extração do esquema ER do esquema relacional, através de algoritmos que investigam características do banco de dados legado para descobrir chaves candidatas e estrangeiras para todas as tabelas. Nessa abordagem, o sistema pode utilizar informações fornecidas pelo usuário, caso este as possua, ou trabalhar com o mínimo de envolvimento do usuário. No entanto, novas abordagens como a citada acima ainda requerem o esquema relacional como entrada, ou então que as tabelas estejam na terceira forma normal. A abordagem apresentada neste artigo não apresenta tais limitações. Conclusões Este artigo propôs uma abordagem à ERBD capaz de extrair um esquema ER de um banco de dados legado, não relacional, e baseado em tabelas cujas chaves primárias não estão declaradas explicitamente. Primeiramente os formulários do sistema foram analisados, ao que se seguiu uma inserção de dados organizados no sistema legado. Após, estes dados foram carregados em um SGBD relacional e submetidos a comandos SQL que automatizaram a maior parte do trabalho de análise. A semântica dos atributos é determinada pela comparação entre formulários e tabelas, análise dos dados e do código fonte, seguida pela identificação de chaves primárias e estrangeiras, e restrições de cardinalidade. Na fase de conceitualização, entidades são determinadas através da fusão de tabelas. Finalmente, são identificados relacionamentos, e o esquema ER é reconstruído.