Trabalho BD

Prévia do material em texto

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE
CENTRO DE CIÊNCIAS EXATAS E DA TERRA
DEPARTAMENTO DE MATEMÁTICA E INFORMÁTICA APLICADA
DISCIPLINA: DIM0357 - BANCO DE DADOS
PROFESSOR: Michael Schuenck
Alunos: 
Leonardo Campos
Rafael Borja
Raphael Farias
Engenharia Reversa de Modelos Relacionais
�
1. O Processo de Engenharia Reversa
A Engenharia Reversa parte de um modelo de implementação e resulta em um modelo conceitual. Esta é uma forma de transformação entre modelos relacionais.
2. Motivações
No desenvolvimento de um sistema de banco de dados (ou um outro qualquer), tem-se como ponto de partida para implementação, modelagens da realidade tratada. Esses levantamentos preliminares (análise de domínio de negócio, especificação de casos de uso, modelagem conceitual da base de dados, etc) aliados a um documento de arquitetura de software servem de base para a construção e manutenção de um sistema.
No entanto, nem todos os softwares legados são bem documentados e por essa razão possuem um custo de manutenção (mudanças) extremamente elevado devido ao difícil entendimento por parte das equipes de desenvolvimento.
Aliado à documentação escassa e de má qualidade, muito desses softwares legados possuem uma modelagem (especialmente dos dados) inadequada, devido a equívocos no processo de desenvolvimento e/ou a uma evolução nos paradigmas de construção de software. Isto torna necessário o emprego de reengenharia, utilizado em casos de mudanças de regras de negócio, de demanda, mudanças de plataformas ou em casos de migração de sistema de SGBD. 
Neste contexto, entram em cena os processos de engenharia reversa, que especificamente no escopo deste trabalho, é empregado para obter-se, a partir de um modelo lógico existente (esquemas SQL, i.e.) um modelo conceitual.
3. Passos para o Processo de engenharia Reversa
Existe um conjunto de passos para a transformação de um modelo lógico de um banco de dados relacional para o modelo conceitual.
Os passos para esta transformação são os seguintes:
         Identificação da Construção ER correspondente a cada tabela;
         Definição de relacionamentos 1:n e 1:1;
         Definição de atributos;
         Definição de identificadores de entidades e relacionamentos.
 
4. Identificação da Construção ER correspondente a cada Tabela
Para cada tabela define-se qual a construção correspondente ao nível de modelo ER. Assim, uma tabela pode corresponder a uma entidade, um relacionamento n:n, ou uma entidade especializada.
Verifica-se que o fator determinante da construção ER que corresponde a uma tabela é a composição de sua chave primária. Conforme o tipo de chave classificam-se as tabelas:
I - Chave primária composta por mais de uma chave estrangeira: A tabela que possui uma chave primária de múltiplas chaves estrangeiras implementa um relacionamento n:n;
II - Toda a chave primária é uma chave estrangeira: A tabela cuja chave primária é toda ela estrangeira representa uma entidade que forma uma especialização da entidade correspondente à tabela referenciada pela chave estrangeira;
III - Demais casos: Quando a chave não for do tipo mencionado nos itens acima, a tabela representa uma entidade.
4.1. Identificação de relacionamentos 1:n ou 1:1
Toda a chave estrangeira que não faz parte de uma chave primária composta por múltiplas chaves estrangeiras, nem é toda ela uma chave primária, representa um relacionamento 1:n ou 1:1.
Para identificar o tipo de cardinalidade é necessário verificar o possível conteúdo do banco de dados. 
4.2. Definição de Atributos
Para cada coluna de uma tabela, que não seja chave estrangeira, é definido um atributo na entidade/relacionamento correspondente à tabela. Observe que colunas chave estrangeira não correspondem a atributos do diagrama ER, mas sim a relacionamentos, as quais já foram tratadas nas etapas anteriores.
4.3. Definição de Identificadores de entidades
A regra para definição dos identificadores é a seguinte:
         Coluna da chave primária que não é chave estrangeira: Toda a coluna que faz parte da chave primária e que não é chave estrangeira corresponde a um atributo identificador da entidade ou relacionamento;
         Coluna da chave primária que é chave estrangeira: Toda coluna que faz parte da chave primária que é chave estrangeira corresponde a um identificador externo da entidade.
5. Estudo de Caso
	Para exemplificar o processo de engenharia reversa de modelos relacionais apresentado anteriormente, vamos analisar o seguinte esquema de um banco de dados referente a um sistema acadêmico, implementado através das seguintes relações:
Aluno (IDALUNO, nome, endereco, cidade, dtNasc)
Professor (IDPROFESSOR, nome, endereco, titulacao, fkDepto)
Turma (IDTURMA, sala, fkProfessor, fkDisciplina)
Depto (IDDEPTO, nome, fkUniversidade, fkChefe)
AlunoTurma (FKALUNO, FKTURMA)
AlunoCurso (FKALUNO, FKCURSO)
Universidade (IDUNIVERSIDADE, nome, endereco, sigla)
TipoCurso (IDTIPOCURSO, nome)
Curso (IDCURSO, fkTipoCurso, fkDepto, fkCoordenador, qtdePeriodos)
Disciplina (IDDISCIPLINA, nome, fkDepto, cargaHoraria)
DisciplinaCurso (FKDISCIPLINA, FKCURSO)
Para efeito de legenda, os campos em maiúsculo representam chaves primárias e os campos cujo nome inicia-se com “fk” são chaves estrangeiras.
A primeira relação mostrada, Aluno, é mapeada simplesmente em uma entidade no diagrama ER (caso III descrito acima), pois não possui chave primária total ou parcialmente formada por chaves estrangeiras. 
Na tabela Professor ocorre que a chave estrangeira fkDepto torna-se um relacionamento para a entidade gerada pela tabela Depto no diagrama (conforme explicado no item 4.1). 
Por sua vez, Depto também se torna uma entidade e possui dois relacionamentos: um para a entidade Universidade e um outro para a entidade Professor, gerados por suas duas chaves estrangeiras: fkUniversidade e fkChefe, respectivamente (item 4.1).
As tabelas AlunoTurma, AlunoCurso e DisciplinaCurso têm suas chaves primárias formadas por chaves estrangeiras, gerando relacionamentos n:n no modelo conceitual (caso I).
Sistemas Legados
(esquemas)
RE-ENGENHARIA
Reversa
Re-implementação
Natal,18 de maio de 2005