universidade federal de santa catarina

UNIVERSIDADE FEDERAL DE SANTA CATARINA
CENTRO TECNOLÓGICO
DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA
CURSO DE SISTEMAS DE INFORMAÇÃO
Uma Ferramenta de Apoio à Normalização de Tabelas Baseada na Análise dos
Dados
Aluno: Michel Leite de Ávila
Orientador: Ronaldo Santos Mello
Florianópolis, SC
Junho de 2007
SUMÁRIO
LISTA DE TABELAS ........................................................................................................................................... 4
LISTA DE FIGURAS ........................................................................................................................................... 5
LISTA DE REDUÇÕES ....................................................................................................................................... 6
1
2
INTRODUÇÃO ............................................................................................................................................ 7
1.1
VISÃO GERAL ....................................................................................................................................... 7
1.2
OBJETIVOS ............................................................................................................................................ 9
1.2.1
Geral ................................................................................................................................................ 9
1.2.2
Específicos ....................................................................................................................................... 9
1.3
JUSTIFICATIVA .................................................................................................................................... 10
1.4
METODOLOGIA.................................................................................................................................... 10
1.5
ESTRUTURA DO TRABALHO ................................................................................................................ 11
FUNDAMENTAÇÃO TEÓRICA ............................................................................................................ 13
2.1
2.1.1
Visão Geral .................................................................................................................................... 13
2.1.2
Engenharia Reversa de Arquivos .................................................................................................. 13
2.2
DEPENDÊNCIA FUNCIONAL ................................................................................................................. 15
2.2.1
Visão Geral .................................................................................................................................... 15
2.2.2
Dependência Funcional Total ....................................................................................................... 16
2.2.3
Dependência Funcional Parcial .................................................................................................... 16
2.2.4
Dependência Funcional Transitiva ou Indireta ............................................................................. 17
2.2.5
Dependência Funcional Multivalorada ......................................................................................... 18
2.2.6
Dependência Funcional de Sub-Domínio ...................................................................................... 18
2.2.7
Anomalias de Alteração ................................................................................................................. 19
2.3
3
ENGENHARIA REVERSA....................................................................................................................... 13
O PROCESSO DE NORMALIZAÇÃO ....................................................................................................... 20
TRABALHOS RELACIONADOS ........................................................................................................... 26
3.1
A INDEPENDÊNCIA FUNCIONAL NA NORMALIZAÇÃO DE BANCOS DE DADOS RELACIONAIS. .............. 26
3.2
ENGENHARIA REVERSA DE BANCOS DE DADOS RELACIONAIS: ALGORITMOS PARA EXTRAIR
RESTRIÇÕES DE CARDINALIDADE. ..................................................................................................................... 28
4
5
3.3
EXTRAINDO O DIAGRAMA ER DE BANCOS DE DADOS LEGADOS. ....................................................... 29
3.4
CONSIDERAÇÕES FINAIS ..................................................................................................................... 31
A FERRAMENTA ..................................................................................................................................... 32
4.1
FUNCIONAMENTO GERAL.................................................................................................................... 32
4.2
TECNOLOGIAS UTILIZADAS ................................................................................................................. 33
4.3
MÓDULOS ........................................................................................................................................... 34
4.3.1
Módulo de Importação .................................................................................................................. 34
4.3.2
Módulo de Análise Preliminar....................................................................................................... 35
4.3.3
Módulo de Ajuste ........................................................................................................................... 36
4.3.4
Módulo de Eleição de Chave Primária ......................................................................................... 36
4.3.5
Módulo de Normalização .............................................................................................................. 37
ATIVIDADES FUTURAS......................................................................................................................... 41
LISTA DE TABELAS
TABELA 1: EXEMPLO DE DEPENDÊNCIA FUNCIONAL. ............................................................................................ 15
TABELA 2: EXEMPLO DE DEPENDÊNCIA FUNCIONAL TOTAL. ................................................................................. 16
TABELA 3: EXEMPLO DE DEPENDÊNCIA FUNCIONAL PARCIAL............................................................................... 17
TABELA 4: EXEMPLO DE DEPENDÊNCIA FUNCIONAL TRANSITIVA OU INDIRETA. ................................................... 17
TABELA 5: EXEMPLO DE DEPENDÊNCIA FUNCIONAL MULTIVALORADA. ............................................................... 18
TABELA 6: EXEMPLO DE DEPENDÊNCIA FUNCIONAL DE SUB-DOMÍNIO. ................................................................ 19
TABELA 7: EXEMPLO DE ATRIBUTO MULTIVALORADO. .......................................................................................... 22
TABELA 8: ISOLAMENTO DOS DADOS DA UF. ......................................................................................................... 22
TABELA 9: EXEMPLO DE ELIMINAÇÃO DE ATRIBUTOS MULTIVALORADOS. ............................................................. 23
TABELA 10: EXEMPLO DE DEPENDÊNCIA FUNCIONAL PARCIAL. ............................................................................ 23
TABELA 11: RESULTADO DA APLICAÇÃO DA 2FN. ................................................................................................. 23
TABELA 12: RESULTADO DA APLICAÇÃO DA 2FN. ................................................................................................. 24
TABELA 13: EXEMPLO DE DEPENDÊNCIA FUNCIONAL TRANSITIVA OU INDIRETA. ................................................. 24
TABELA 14: RESULTADO DA APLICAÇÃO DA 3FN. ................................................................................................. 24
TABELA 15: RESULTADO DA APLICAÇÃO DA 3FN. ................................................................................................. 25
TABELA 16: EXEMPLO DE INDEPENDÊNCIA FUNCIONAL. ....................................................................................... 27
TABELA 17: NOTAÇÃO MER VS NOTAÇÃO MPC .................................................................................................. 29
TABELA 18: EXEMPLO GERAL DE DF. .................................................................................................................... 38
TABELA 19: RESULTADO DA ANÁLISE DE RELACIONAMENTOS. .............................................................................. 39
LISTA DE FIGURAS
FIGURA 1: ENGENHARIA REVERSA DE ARQUIVOS .................................................................................................. 15
FIGURA 2: AS FORMAS NORMAIS E SUAS INTERDEPENDÊNCIAS. ............................................................................ 21
FIGURA 3: FUNCIONAMENTO GERAL DA FERRAMENTA. .......................................................................................... 32
FIGURA 4: MÓDULO DE IMPORTAÇÃO. ................................................................................................................... 34
FIGURA 5: MÓDULO DE ANÁLISE PRELIMINAR ....................................................................................................... 36
LISTA DE REDUÇÕES
SGBD
Sistema de Gerenciamento de Bancos de Dados
ER
Entidade-Relacionamento
MER
Modelo Entidade-Relacionamento
MRP
Modelo Restrição de Participação
XML
Extended Markup Language
ñn
Não normalizada
DF
Dependência Funcional
1
INTRODUÇÃO
1.1
Visão Geral
A normalização de tabelas foi proposta por Edgar Frank Codd, em 1970,
juntamente com o próprio modelo de dados relacional, como uma técnica para
eliminar redundâncias de informações e evitar anomalias causadas pela inserção,
atualização e remoção de registros [1]. A aplicação desta técnica não é trivial,
exigindo conhecimento sobre formas normais e dependências funcionais, além da
teoria de bancos de dados relacionais. O sucesso da normalização depende,
também, da intimidade do projetista com o domínio dos dados.
O cerne da normalização reside na identificação de dependências funcionais,
que são relacionamentos especiais entre entidades e atributos, e serão explicadas
em detalhes no capítulo 2. Uma vez identificadas, as dependências funcionais são
eliminadas sistematicamente, de acordo com sua classificação, através da
decomposição das entidades em entidades mais simples. Essa decomposição é um
simples mapeamento padrão entre tipos de dependências funcionais e operações de
decomposição de entidades, de tal sorte que a automatização total desta tarefa só
não é possível em virtude da alta dependência humana durante a identificação de
dependências funcionais.
A normalização é parte fundamental da engenharia reversa de arquivos de
dados, conhecida também como projeto de banco de dados bottom-up, onde, em
linhas gerais, parte-se de um modelo já implementado em direção aos conceitos que
o geraram [2]. A engenharia reversa é uma funcionalidade muito comum em
ferramentas de modelagem de bancos de dados, como ERwin (Computer
Associates), ER Studio (Embarcadero), DB Designer (fabFORCE), Toad Data
Modeler (Quest Software), entre outras. Essas ferramentas são capazes de
automatizar grande parte do processo de transporte dos dados de seus arquivos
originais para o banco de dados de destino, gerar o modelo lógico e, por fim, gerar o
modelo conceitual. A automatização que estas ferramentas oferecem, no entanto,
não cobre a etapa de normalização, cuja aplicação continua a cargo do projetista [3].
No âmbito acadêmico, há poucos artigos que abordam a descoberta de
dependências funcionais utilizando análises sobre as informações disponíveis, como
o código da aplicação, modelos de dados, ou até mesmo os dados, e quando o
fazem, é dentro do contexto da engenharia reversa [5, 6, 7,8]. As propostas para
automatização partem de uma série de informações a respeito dos dados originais,
cuja disponibilidade e qualidade geralmente é baixa, principalmente para arquivos de
sistemas legados, o que compromete os seus resultados.
Percebe-se,
assim,
que
a
normalização
ainda
é
uma
tarefa
predominantemente manual, onde o conhecimento do projetista tem total impacto
sobre a qualidade dos esquemas lógico e conceitual resultantes.
Para atenuar tal impacto, este trabalho propõe uma ferramenta para apoiar a
etapa de normalização de tabelas, com foco no auxilio à descoberta de
dependências funcionais, diminuindo a necessidade de conhecimento teórico e do
domínio dos dados por parte do projetista. A ferramenta transporta os dados de um
arquivo de texto ou XML para uma tabela, analisa os dados e monta uma base de
informações para apoiar a aplicação de cada passo da normalização, solicitando a
intervenção do usuário apenas quando as informações extraídas não são capazes
de decidir por uma decomposição com segurança. Em cada passo, são
apresentadas as regras que compõem cada forma normal, utilizando exemplos com
os próprios dados de entrada. O resultado do processo é um conjunto de tabelas
normalizadas.
1.2
Objetivos
1.2.1 Geral
Desenvolver uma ferramenta de apoio à normalização de tabelas com base
na análise de uma fonte de dados, de modo a diminuir o impacto do conhecimento
do projetista sobre o resultado da normalização.
1.2.2 Específicos
 Oferecer suporte à importação de dados contidos em arquivos de texto ou
XML;
 Apresentar características gerais dos dados carregados, como tipo (literal
ou numérico), tamanho máximo e mínimo, valores distintos, etc., através de
uma análise preliminar;
 Aplicar as formas normais, solicitando a concordância do usuário em cada
passo;
 Informar ao usuário os conceitos envolvidos em cada decomposição
efetuada;
 Apresentar relatório com as tabelas resultantes;
 Apresentar a diferença entre o espaço alocado pelos dados antes e depois
da normalização.
1.3
Justificativa
A normalização, em projetos de bancos de dados, pode ser vista como uma
etapa de garantia de conformidade e qualidade, onde as tabelas são analisadas e
submetidas a um grande conjunto de alterações sistemáticas até alcançar certo nível
de otimização, estipulado pelo próprio projetista.
As propostas para automatizar esta etapa dependem da disponibilidade de
modelos e descrições a respeito da estrutura dos dados, que nem sempre estão
disponíveis. Além disso, é necessário conhecer o domínio dos dados para aplicar
uma normalização adequada, o que pode levar muito tempo, dependendo do
domínio.
A combinação destes fatores faz com que esta etapa seja encarada como um
luxo acadêmico, pelo tempo que consome, e enfadonha, pela carga de
conhecimento teórico que requer. Como resultado, a normalização é freqüentemente
ignorada, deixando a qualidade do projeto fortemente dependente da experiência do
projetista, o que nem sempre gera bons resultados.
1.4
Metodologia
Para que os objetivos, há pouco expostos, sejam alcançados, este trabalho
segue as etapas abaixo elencadas:
 Estudo sobre a normalização de tabelas e conceitos relacionados;
 Levantamento do estado da arte na área;
 Implementação da ferramenta;
 Apresentação de um estudo de caso.
Na primeira etapa, são apresentadas as teorias sobre as quais a
normalização se apóia, com exemplos descritivos e ilustrativos para auxiliar a
compreensão dos mesmos.
A segunda etapa consiste em uma pesquisa sobre trabalhos relacionados a
alguma forma de suporte automatizado ao processo de normalização, com o intuito
de se determinar o avanço tecnológico na área e incorporar conceitos úteis ao
trabalho.
A terceira etapa refere-se à implementação da ferramenta, que consiste na
definição dos algoritmos para determinação de chave primária, descoberta de
relacionamentos, migração de atributos para novas tabelas e desenvolvimento da
interface gráfica.
Na quarta etapa, é feito um estudo de caso onde um arquivo de dados é
normalizado manualmente e através da ferramenta, sendo os resultados analisados.
1.5
Estrutura Do Trabalho
Este trabalho está dividido da seguinte forma:
 Capítulo 1: Introdução – Contextualiza a normalização de tabelas e
apresenta o trabalho de forma geral, comentando sobre seus objetivos
gerais e específicos, justificativa, metodologia e organização;
 Capítulo 2: Fundamentação Teórica – Apresenta os conceitos de
engenharia reversa de arquivos e modelos relacionais, normalização de
tabelas, dependência funcional, formas normais;
 Capítulo 3: Trabalhos Relacionados – Comenta artigos relacionados ao
trabalho e faz uma análise sobre o estado da arte em normalização;
 Capítulo 4: A Ferramenta – Descreve a arquitetura proposta para a
ferramenta: os módulos de importação, análise preliminar, ajuste, eleição
de chave primária, análise de dependências funcionais e análise de
resultados;
 Capítulo 5: Estudo de Caso – Executa a normalização de um arquivo tanto
através da ferramenta quanto manualmente, apresentando um estudo
comparativo dos resultados ao final;
 Capítulo 6: Conclusões – Apresenta as conclusões extraídas do estudo de
caso e do trabalho, em geral. Aponta ainda aspectos do trabalho e da
ferramenta que não estavam dentro de escopo e que podem ser
incorporados em trabalhos futuros;
 Bibliografia – Registra as fontes de informação consultadas para a
confecção deste trabalho.
2
FUNDAMENTAÇÃO TEÓRICA
2.1
Engenharia Reversa
2.1.1 Visão Geral
Em linhas gerais, pode-se definir a engenharia reversa como um processo de
abstração, cujo objetivo é obter um modelo conceitual a partir de um modelo
implementado [2]. No escopo de bancos de dados, a engenharia reversa é utilizada
inicialmente para extrair modelos lógicos de conjuntos de dados não relacionais,
num processo denominado “engenharia reversa de arquivos”. Este processo é
composto por várias tarefas, sendo seguido por outro processo, chamado de
“engenharia reversa de modelos relacionais”, cujo objetivo é gerar modelos
conceituais a partir de modelos lógicos. Há muitas outras aplicações para a
engenharia reversa, mas não são abordadas neste trabalho por estarem fora do
escopo do mesmo.
2.1.2 Engenharia Reversa de Arquivos
Grande parte dos sistemas de informação utilizados ainda hoje foi
desenvolvido no decorrer dos últimos 20 anos, em linguagens de terceira geração
como COBOL e Basic, utilizando bancos de dados pré-relacionais como IMS ou
ADABAS, sendo conhecidos como “sistemas legados” [2]. Estes sistemas raramente
apresentam documentação e, quando existe, é pobre, tornando as manutenções e
melhoramentos mais caros que um projeto novo, em alguns casos.
O modelo conceitual é vital para que pessoas que não conhecem o sistema
tenham condições de assimilar seu funcionamento e participar de discussões a
respeito de alterações e melhorias do mesmo. O processo de migração de bancos
de dados legados para tecnologias mais atuais, como bancos de dados relacionais e
não-convencionais, também é prejudicado pela falta de modelos conceituais,
fazendo com que os dados tenham que ser modelados praticamente do zero.
Em geral, a engenharia reversa de arquivos pode ser dividida nas seguintes
etapas:
Conversão da descrição de arquivos em tabelas relacionais ñn: Converte a
descrição de cada arquivo existente para um esquema relacional não normalizado,
ou simplesmente ñn. Neste passo inicial, obtém-se a independência dos tipos de
arquivo importados, já que são todos transformados em uma estrutura tabular;
Normalização: Reagrupa as informações para eliminar redundâncias e evitar
anomalias ocasionadas pela atualização de registros. Esta técnica é detalhada mais
adiante;
Integração de esquemas: Gera o esquema relacional completo através
integração dos esquemas relacionais normalizados de cada arquivo. Como a
integração de normalizados não gera, necessariamente, um esquema integrado já
normalizado, esta etapa conta ainda com um passo de eliminação de redundâncias
entre as tabelas;
Extração do esquema Entidade-Relacionamento (ER): Por fim, o esquema ER
é extraído, aplicando-se a engenharia reversa de modelos relacionais sobre o
conjunto de esquemas relacionais integrados. Esta etapa também é detalhada mais
adiante. A figura 1 oferece uma visão geral destas etapas.
Figura 1: Engenharia Reversa de Arquivos
2.2
Dependência Funcional
2.2.1 Visão Geral
Diz-se que um atributo A determina um atributo B, ou que B depende
funcionalmente de A, quando, para cada valor de A, o valor de B é sempre o mesmo,
para todos os registros da tabela [4]. A tabela 1 exemplifica esse conceito.
TEMPERATURAS_MUNICIPIOS
UF_NOME
UF_SIGLA
MUNICIPIO
SANTA CATARINA
SC
FLORIANOPOLIS
SANTA CATARINA
SC
SAO JOSE
RIO GRANDE DO SUL
RS
BAGE
RIO GRANDE DO SUL
RS
ALEGRETE
Tabela 1: Exemplo de Dependência Funcional.
TEMPERATURA
26
25
5
12
Analisando-se o relacionamento entre UF_NOME e UF_SIGLA, verifica-se
que cada valor de UF_SIGLA está relacionado com o mesmo valor de UF_NOME
em todos os registros. Pode-se afirmar, então, que UF_SIGLA determina UF_NOME,
ou que UF_SIGLA  UF_NOME, utilizando-se a notação formal.
2.2.2 Dependência Funcional Total
Quando um atributo que não faz parte da chave primária depende
funcionalmente de todos os atributos que fazem parte da chave, tem-se uma
dependência funcional total. O exemplo abaixo esclarece este conceito:
LATITUDE
-27:35 (Sul)
-27:35 (Sul)
-30:01 (Sul)
-31:19 (Sul)
-29:46 (Sul)
COORDENADAS_MUNICIPIOS
LONGITUDE
ALTITUDE
-48:32 (Oeste)
3 Metros
-48:37 (Oeste)
8 Metros
-51:13 (Oeste)
3 Metros
-54:06 (Oeste)
212 Metros
-55:47 (Oeste)
102 Metros
MUNICIPIO
FLORIANOPOLIS
SAO JOSE
PORTO ALEGRE
BAGE
ALEGRETE
Tabela 2: Exemplo de Dependência Funcional Total.
Neste exemplo, LATITUDE, LONGITUDE  MUNICIPIO é válido. Este tipo de
relacionamento é classificado como dependência funcional total, uma vez que
MUNICIPIO depende funcionalmente de todos os atributos que compõe a chave.
2.2.3 Dependência Funcional Parcial
Quando um atributo que não faz parte da chave primária depende
funcionalmente de apenas alguns dos atributos que fazem parte da chave primária,
tem-se de uma dependência funcional parcial. O exemplo abaixo esclarece este
conceito:
COORDENADAS_MUNICIPIOS
LONGITUDE
ALTITUDE
-48:32 (Oeste)
3 Metros
-48:37 (Oeste)
8 Metros
-51:13 (Oeste)
3 Metros
-54:06 (Oeste)
212 Metros
-55:47 (Oeste)
102 Metros
LATITUDE
-27:35 (Sul)
-27:35 (Sul)
-30:01 (Sul)
-31:19 (Sul)
-29:46 (Sul)
MUNICIPIO
FLORIANOPOLIS
SAO JOSE
PORTO ALEGRE
BAGE
ALEGRETE
Tabela 3: Exemplo de Dependência Funcional Parcial.
Neste exemplo, LATITUDE, LONGITUDE  MUNICIPIO é válido. Este tipo de
relacionamento é classificado como dependência funcional parcial, uma vez que
MUNICIPIO depende funcionalmente apenas de parte dos atributos que compõe a
chave primária, ou seja, a dependência funcional existente não seria afetada se o
atributo ALTITUDE fosse removido da tabela, ou simplesmente deixasse de fazer
parte da chave primária.
2.2.4 Dependência Funcional Transitiva ou Indireta
Esta dependência ocorre quando a dependência funcional se realiza entre
atributos que não fazem parte da chave primária. O exemplo abaixo esclarece este
conceito:
REGIAO
SUL
SUL
SUL
SUL
TEMPERATURAS_MESORREGIOES
UF
MESORREGIAO
SC
GRANDE FLORIANOPOLIS
SC
SERRANA
PR
OESTE PARANAENSE
PR
SUDOESTE PARANAENSE
TEMPERATURA
26
25
5
12
Tabela 4: Exemplo de Dependência Funcional Transitiva ou Indireta.
Neste exemplo,
MESORREGIAO  UF e UF  REGIAO, logo,
MESORREGIAO  REGIAO. Este tipo de relacionamento é classificado como
dependência funcional transitiva, ou indireta, uma vez que MESORREGIAO
consegue determinar, através da UF, a REGIAO.
2.2.5 Dependência Funcional Multivalorada
Esta dependência ocorre quando um atributo A determina freqüentemente o
mesmo conjunto de valores em B. O exemplo abaixo esclarece este conceito:
MODELOS
MARCA
MODELO
FORD
FOCUS
FORD
KA
FORD
FOCUS
FIAT
PALIO
FIAT
UNO
FIAT
PALIO
FORD
KA
FIAT
PALIO
FIAT
UNO
FORD
FOCUS
FIAT
UNO
FORD
KA
Tabela 5: Exemplo de Dependência Funcional Multivalorada.
Neste exemplo, MARCA  MODELO, ou MARCA multidetermina
MODELO, porque para cada valor de MARCA existe um conjunto fixo de valores
possíveis para MODELO, observados em todos os registros. Este tipo de
relacionamento é classificado como dependência funcional multivalorada.
2.2.6 Dependência Funcional de Sub-Domínio
Esta dependência ocorre quando A  B não ocorre, e existe pelo menos um
valor de A que sempre se relaciona com apenas um valor em B. O exemplo abaixo
esclarece este conceito:
PRODUTOS
NOME
MEDIDA
MARGARINA
250 Gr
MARGARINA
500 Gr
OLEO
1000ml
REFRIGERANTE
250ml
REFRIGERANTE
350ml
REFRIGERANTE 1000ml
OLEO
900ml
LEITE
1000ml
Tabela 6: Exemplo de Dependência Funcional de Sub-Domínio.
Neste exemplo, embora NOME  MEDIDA não ocorra, existe pelo menos um
valor para NOME que se relaciona com apenas um valor em MEDIDA. Este tipo de
relacionamento é classificado como dependência funcional de subdomínio.
2.2.7 Anomalias de Alteração
A detecção de dependências funcionais indica que a tabela possui
redundância e, conseqüentemente, está sujeita a anomalias de inserção, atualização
e remoção. As anomalias são as seguintes:
 Anomalias de inserção: Ocorrem quando um registro é inserido em uma
tabela sem que todos os seus atributos tenham sido determinados. No
exemplo da Tabela 4, a inserção de um novo município vinculado a uma UF
e região implicaria a atribuição de uma temperatura nula. Uma alternativa
seria inserir o novo município apenas quando sua temperatura estiver
disponível também. De qualquer forma, não é o comportamento adequado;
 Anomalias de alteração: Ocorrem quando um atributo é modificado apenas
em alguns registros em que ocorre. No exemplo acima, caso a sigla de
alguma das unidades federativas fosse alterada, seria necessário efetuar a
alteração em todas as ocorrências daquela sigla, exigindo a varredura
completa da tabela. Caso esta alteração seja efetuada apenas em parte de
suas ocorrências, a tabela fica inconsistente, retornando siglas distintas
para a mesma UF;
 Anomalias de remoção: Ocorrem quando a remoção de algum atributo
causa a perda de outras informações relacionadas. Ainda no exemplo
acima, a remoção de um município implicaria a perda da unidade federativa
e sua sigla.
Para evitar as anomalias supracitadas, é necessário detectar e eliminar as
dependências, ou seja, decompor a tabela em outras tabelas que não possuam mais
redundância.
2.3
O Processo de Normalização
A normalização é um processo composto por algumas regras, chamadas
formas normais, cujo objetivo principal é eliminar a redundância nos dados
armazenados em tabelas, resultando na diminuição do espaço e dos riscos de
inconsistências em atualizações de dados [4]. Quando um atributo é alterado em
uma tabela que não está totalmente normalizada, é necessário alterá-lo em todas as
linhas em que ele ocorre, haja vista a sua repetição. Tal operação poderia ser
executada apenas uma vez, caso este atributo estivesse normalizado.
As principais formas normais encontradas na literatura são mostradas na
Figura 2.
Figura 2: As Formas Normais e suas interdependências.
As formas normais mantêm uma relação entre si de tal sorte que a 2FN, a
exemplo, se “apóia” sobre a 1FN, ou então que implica a 1FN, a 3FN implica a 2FN,
e assim sucessivamente. As regras das três primeiras formas normais são as
seguintes:
 1ª Forma Normal (1FN) - Para que uma tabela obedeça à 1FN, não deve
possuir atributos multivalorados, tão pouco tabelas aninhadas. O simples
fato dos dados estarem dentro de uma tabela relacional com uma chave
primária já garante a conformidade com a 1FN. Algumas técnicas são
propostas para decompor uma estrutura aninhada em uma tabela na 1FN,
como por exemplo, a geração de uma tabela para cada nível de
aninhamento, ou a geração de uma tabela única para todos os dados;
 2ª Forma Normal (2FN) - Uma tabela está na 2FN se, e somente se, estiver
na 1FN e não houver dependências funcionais parciais;
 3ª Forma Normal (3FN) - Uma tabela está na 3FN se, e somente se, estiver
na 2FN e todo atributo não-chave depende funcionalmente diretamente da
chave primária, ou seja, não há dependências entre atributos não chave.
As demais formas normais estão fora do escopo deste trabalho, porque
exigem análises mais complexas de dependências funcionais, cujo tempo de
processamento pode não justificar o benefício, em tabelas com muitos registros.
Além disso, a ocorrência destas formais normais é muito mais rara na prática.
A Tabela LOCALIDADES apresenta um exemplo de atributo multivalorado no
campo MUNICIPIOS, que não é permitido segundo a 1FN. Após a aplicação da 1FN,
a tabela LOCALIDADES é decomposta em duas novas tabelas: UFS e
MUNICIPIOS. Todos os atributos originais de LOCALIDADES são migrados para
UFS, exceto o atributo multivalorado MUNICIPIOS, que, para entrar em
conformidade com a 1FN, deve ter um registro para cada valor, motivo pelo qual é
acomodado na tabela MUNICIPIOS. Para que não se perca o relacionamento entre
UF e MUNICIPIOS, o atributo ID_UF migra também para MUNICIPIOS, preservando
uma propriedade fundamental da normalização: a capacidade de se desfazer todas
as decomposições efetuadas, gerando a tabela original novamente [4].
LOCALIDADES
ID
1
2
3
REGIAO
SUL
SUL
SUL
UF
SC
RS
PR
MUNICIPIOS
FLORIANOPOLIS, SAO JOSE, CRICIUMA
BAGE, ALEGRETE, CANDIOTA
ATALAIA, MARINGA, SARANDI
Tabela 7: Exemplo de atributo multivalorado.
UFS
ID
1
2
3
REGIAO
SUL
SUL
SUL
UF
SC
RS
PR
Tabela 8: Isolamento dos dados da UF.
ID
1
2
3
4
5
6
7
8
9
MUNICIPIOS
MUNICIPIO
FLORIANOPOLIS
SAO JOSE
CRICIUMA
CANDIOTA
ALEGRETE
BAGE
SARANDI
MARINGA
ATALAIA
ID_UF
1
1
1
2
2
2
3
3
3
Tabela 9: Exemplo de eliminação de atributos multivalorados.
A Tabela ATUACOES apresenta um exemplo de DF Parcial, provocada pelo
atributo NOME, que depende funcionalmente de apenas um dos atributos que
compõem a chave primária, ID_ATOR. Para obedecer à 2FN, o atributo NOME é
migrado para uma nova tabela ATORES, levando junto o atributo ID_ATOR,
mantendo assim o relacionamento existente.
ID_FILME
1
1
2
3
4
5
ID_ATOR
1
2
3
4
5
6
ATUACOES
NOME
BRAD PITT
JULIA ROBERTS
NATALIE PORTMAN
ANTONIO BANDERAS
LUCY LIU
CLAIRE FORLANI
PERSONAGEM
RUSTY RYAN
TESS OCEAN
ALICE
CARLOS RUEDA
ALEX MUNDAY
SUSAN PARRISH
Tabela 10: Exemplo de Dependência Funcional Parcial.
ID_FILME
1
1
2
3
4
5
ATUACOES
ID_ATOR
PERSONAGEM
1
RUSTY RYAN
2
TESS OCEAN
3
ALICE
4
CARLOS RUEDA
5
ALEX MUNDAY
6
SUSAN PARRISH
Tabela 11: Resultado da aplicação da 2FN.
ID_ATOR
1
2
3
4
5
6
ATORES
NOME
BRAD PITT
JULIA ROBERTS
NATALIE PORTMAN
ANTONIO BANDERAS
LUCY LIU
CLAIRE FORLANI
Tabela 12: Resultado da aplicação da 2FN.
A Figura 5 apresenta um exemplo de DF provocada pelo atributo SALARIO,
que depende funcionalmente do atributo CATEGORIA. Neste caso, como o atributo
CATEGORIA não faz parte da chave, esta DF é denominada INDIRETA ou
TRANSITIVA, ou seja, ocorre apenas entre atributos não-chave. Para obedecer à
3FN, o atributo SALARIO é migrado para a nova tabela CATEGORIAS, levando junto
o atributo CATEGORIA, mantendo assim o relacionamento existente.
ID_FUNCIONARIO
1
1
2
3
4
5
VENCIMENTOS
NOME
CATEGORIA
JOAO
OPERAÇÃO
MARCOS
OPERAÇÃO
ANA
SECRETARIA
JULIA
SECRETARIA
VITOR
ADMINISTRAÇÃO
ANGELA
ADMINISTRAÇÃO
SALARIO
600,00
600,00
450,00
450,00
1000,00
1000,00
Tabela 13: Exemplo de Dependência Funcional Transitiva ou Indireta.
FUNCIONARIOS
ID_FUNCIONARIO
NOME
CATEGORIA
1
JOAO
OPERAÇÃO
1
MARCOS
OPERAÇÃO
2
ANA
SECRETARIA
3
JULIA
SECRETARIA
4
VITOR
ADMINISTRAÇÃO
5
ANGELA
ADMINISTRAÇÃO
Tabela 14: Resultado da aplicação da 3FN.
CATEGORIAS
NOME
SALARIO
OPERADOR
600,00
SECRETARIA
450,00
ADMINISTRADOR 1000,00
Tabela 15: Resultado da aplicação da 3FN.
3
TRABALHOS RELACIONADOS
Os trabalhos que mais se aproximam do trabalho aqui proposto estão
relacionados com a automatização da engenharia reversa de bancos de dados, cujo
objetivo é, em linhas gerais, obter um esquema conceitual a partir de um esquema
implementado [1]. Os processos propostos utilizam documentos físicos, esquemas,
análise de dependências funcionais, código fonte da aplicação, SQL e os próprios
dados. No entanto, não há abordagem que se proponha a normalizar um conjunto de
dados utilizando apenas a análise dos mesmos e dispensando o conhecimento
sobre o seu domínio. Isto se deve, em parte, porque a normalização é apenas uma
etapa do processo de engenharia reversa e raramente é abordada fora deste
escopo.
3.1
A Independência Funcional na Normalização de Bancos de Dados
Relacionais.
Este trabalho aponta deficiências na definição das formas normais baseadas
em dependências funcionais e apresenta uma abordagem complementar ao
processo tradicional de normalização, introduzindo o conceito de independência
funcional, melhorando sensivelmente o resultado da normalização [9].
Segundo o trabalho, a observância das dependências funcionais não é
suficiente para eliminar algumas formas básicas de redundância, resultando em
anomalias nos dados mesmo em altos níveis de normalização. Para eliminar
anomalias causadas pelas dependências funcionais de subdomínio, o artigo introduz
o conceito de independência funcional, que acontece quando a combinação de
todos os valores entre dois atributos é válida, ou seja, não fere nenhuma restrição
semântica. O exemplo abaixo esclarece este conceito:
CONTAS
CORRENTISTA
SALDO
JOAO
-50,00
GISELE
654,21
ANA
1684,32
GABRIEL
-320,15
CAROL
521,78
Tabela 16: Exemplo de Independência Funcional.
A Tabela 16 apresenta dois campos funcionalmente independentes, ou
CORRENTISTA >< SALDO, pela notação formal, porque não há restrições para as
combinações de valores que os campos podem assumir. O exemplo de
independência funcional, dado na Tabela 16, só é válido quando acrescido de
informações externas, como o fato de que um correntista pode ter qualquer valor em
seu saldo. No entanto, regras simples de negócio podem invalidar o exemplo, como
considerar que correntistas com menos de um ano de conta têm limite máximo de
R$ 200,00. Por esse motivo, as independências funcionais não são determinadas
pela combinação exaustiva dos atributos, mas pela consulta à semântica dos
mesmos, tornando-as altamente dependentes do domínio dos dados.
Por fim, o trabalho utiliza o conceito de independência funcional para definir a
Forma Normal da Independência Funcional (FINF). Uma tabela está na FINF se, e
somente se, estiver na FNBC e, em todos os pares de atributos “X” e “Y”, for
verificado que X  Y ou Y  X ou X >< Y, o que implica a ausência de
redundâncias causadas por dependências funcionais de subdomínio e outras formas
de relacionamento entre atributos. A FNBC exige que todos os atributos
funcionalmente determinantes façam parte da chave primária.
Esta proposta contribuiu para este trabalho com a teoria de independência
funcional e a forma normal FINF.
3.2
Engenharia Reversa de Bancos de Dados Relacionais: Algoritmos para
Extrair Restrições de Cardinalidade.
Este trabalho trata da extração de cardinalidades via comandos SQL, gerados
dinamicamente sobre um dicionário de dados, para otimizar a engenharia reversa de
bancos de dados [3]. Os resultados podem ser aplicados para esquemas ER,
MERISE, ECR, ERC+, OMT e ODMG, ou ainda na integração de ferramentas
comerciais que oferecem engenharia reversa de bancos de dados.
A motivação está na complexidade do processo de engenharia reversa, cujas
abordagens exigem a satisfação de uma série extensa e complexa de requisitos,
impedindo a automatização, bem como na falta de abordagens que utilizem os
próprios dados para dar mais consistência ao esquema extraído.
A análise dos dados armazenados em um banco ou fonte de dados traz
informações muito mais realistas a respeito das entidades ali persistidas do que o
código fonte da aplicação e a descrição dos dados sozinhos. Todavia, as
ferramentas que oferecem engenharia reversa ignoram os dados, tomando como
entrada apenas dicionários de dados ou descrições do esquema relacional.
Incluir a análise dos dados no processo, como propõe o trabalho, possibilita a
identificação precisa das cardinalidades existentes entre as entidades. A precisão
desta informação é que separa processos de engenharia reversa em bem ou mal
sucedidos.
Quando as definições de entidades incluem as chaves primárias e
estrangeiras no nível relacional, a ferramenta efetua a engenharia reversa
automaticamente. Caso contrário, o usuário deve indicar manualmente os camposalvo a serem analisados pela ferramenta e refazer o processo até obter um resultado
que julgue satisfatório.
O trabalho analisa as diferenças entre os modelos baseados em restrições de
cardinalidades (MER), como o ER, e os modelos baseados em restrições de
pertinência (MPC), como MERISE, ECR, ERC+, OMT e ODMG. A Tabela 17
apresenta as diferenças entre as notações MER e MPC.
Relacionamento
Aluno VS Matrícula
Banca VS
Professores
Aluno VS Email
Aluno VS Turma
Descrição
Notação
MER
MPC
Um aluno tem apenas uma matrícula,
e uma matrícula identifica apenas um
aluno
Uma banca pode ter de dois a quatro
professores, e um professor pode
fazer parte de zero ou mais bancas
Um aluno pode ter zero ou mais
emails, e um email pertence a
apenas um aluno
Um aluno pode estar alocado a uma
ou mais turmas, e uma turma pode
conter zero ou mais alunos
1:1
[1:1]:[1:1]
n:m
[0:n]:[2:4]
1:n
[1:1]:[0:n]
n:m
[0:n]:[1:n]
Tabela 17: Notação MER VS Notação MPC
A identificação e representação adequada das cardinalidades, apresentada
neste trabalho, deu origem ao módulo de análise preliminar, haja vista a importância
que essa informação tem para o processo de normalização.
3.3
Extraindo o Diagrama ER de Bancos de Dados Legados.
Este trabalho propõe um processo de extração de um diagrama ER de um
banco de dados não relacional, com pouca informação sobre os campos e nenhuma
informação sobre as chaves, analisando os próprios dados armazenados e telas de
formulário do sistema que alimenta o banco [10]. A motivação reside na presunção
de disponibilidade de todas essas informações para se iniciar um processo de
engenharia reversa, o que raramente acontece. Ao final, um estudo de caso é
apresentado.
A semântica dos dados é descoberta através do preenchimento dos
formulários do sistema e análise do posterior armazenamento das informações de
entrada no banco de dados. Para automatizar o procedimento de análise e extração,
são criadas tabelas no SQL Server para armazenar informações sobre formulários,
campos de formulários, tabelas e campos de tabelas do sistema.
As chaves são inferidas pela análise de arquivos de índices ou, 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 definidas na etapa anterior,
descobrindo assim as chaves estrangeiras.
As cardinalidades entre as chaves primárias e estrangeiras são obtidas pela
contagem do número de valores distintos de cada chave estrangeira para uma chave
primária.
Grande parte das pesquisas nesta área de extração de esquemas conceituais
de dados baseia-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, justificando abordagens como esta, que utilizam a análise dos
formulários do sistema para ajudar na reconstrução de esquemas ER.
Este trabalho deu origem ao módulo de eleição de chave primária, que é prérequisito da normalização.
3.4
Considerações Finais
Estes trabalhos contribuíram para o amadurecimento geral da ferramenta,
além dos conceitos especificados na análise de cada um. No entanto, este trabalho
se diferencia das abordagens apresentadas ao propor uma ferramenta de apoio à
normalização que utiliza apenas os dados como entrada, dos quais extrai as
informações
necessárias
para
efetuar
grande
parte
da
normalização
automaticamente.
Outro aspecto é a disponibilização de uma interface com o usuário dotada de
recursos para apresentar a teoria envolvida em todo o processo de normalização,
distribuindo-a em módulos e passos.
4
A FERRAMENTA
A ferramenta proposta neste trabalho tem por objetivo apoiar o processo de
normalização de tabelas até a 3FN, reduzindo a necessidade de conhecimento
teórico a respeito da normalização e conhecimento sobre o domínio dos dados, além
de explicar a teoria envolvida em cada parte do processo. A figura abaixo oferece
uma visão geral do funcionamento da ferramenta.
Figura 3: Funcionamento geral da ferramenta.
4.1
Funcionamento Geral
A entrada da ferramenta é um arquivo de dados em texto ou XML. Os dados
contidos neste arquivo são importados para uma única tabela relacional não
normalizada, que servirá de base para todo o resto do processo.
A aplicação das formas normais exige a existência de uma chave primária.
Para auxiliar o usuário na definição dessa chave, a ferramenta analisa os dados e
calcula o potencial que cada campo tem para exercer essa função. Em seguida,
apresenta uma lista de campos de maior potencial, com os quais o usuário deve
compor a chave primária.
Definida a chave primária, o usuário pode então aplicar as formas normais.
Nesta etapa, a tabela sofre a aplicação de cada uma das formas normais em passos
separados, nos quais a ferramenta identifica, classifica e remove cada dependência
funcional encontrada, além de apresentar a teoria relacionada a cada uma delas
#detalhes no módulo#.
Ao término do processo, são apresentadas as tabelas resultantes da
normalização, juntamente com relatórios sobre tempos de execução de cada tarefa e
a diferença entre o espaço utilizado pelos dados antes e depois da normalização.
As principais funcionalidades da ferramenta estão divididas em módulos, e
serão explicadas minuciosamente mais adiante.
4.2
Tecnologias Utilizadas
A plataforma da aplicação é toda em SQL ANSI, constituída de tabelas
responsáveis por manter os dados resultantes das análises e stored procedures que
encapsulam os algoritmos de cada tarefa utilizada pela ferramenta. A padronização
do SQL permite que os algoritmos sejam incorporados a qualquer outro SGBD
Relacional com suporte a stored procedures e capacidade de montar e executar
comandos SQL dinamicamente.
O sistema gerenciador de bancos de dados escolhido foi o MySQL 5.1, por
ser gratuito, muito utilizado no meio acadêmico e, principalmente, oferecer suporte à
execução dinâmica de SQL. A interface gráfica foi desenvolvida utilizando-se a
versão 5.5.1 do Netbeans, uma IDE para a linguagem Java.
4.3
Módulos
4.3.1 Módulo de Importação
Este módulo extrai os dados de um arquivo de texto ou XML e insere em uma
tabela. Para arquivos de texto, o usuário define os critérios (caracteres) que serão
utilizados para quebrar os registros em linhas e colunas. Para arquivos XML, o
mecanismo de importação ainda não foi definido. Os campos da tabela de destino
são definidos como literais, uma vez que não se conhece a natureza dos dados, a
priori. Um campo com nome ID, de tipo inteiro e auto-incremental, é adicionado à
tabela, para identificar unicamente cada registro. A figura 6 apresenta o protótipo da
tela deste modulo.
Figura 4: Módulo de Importação.
4.3.2 Módulo de Análise Preliminar
Este módulo explora cada campo da tabela, extraindo as informações que
serão utilizadas pelos módulos seguintes, e está dividido da seguinte forma:
 Básica: Extrai o número de valores distintos, número mínimo e máximo de
caracteres, e classifica o campo em numérico ou literal;
 Avançada: Aplica as estatísticas selecionadas pelo usuário, como valor
máximo, mínimo, média e desvio padrão, além de estatísticas definidas
pelo próprio usuário;
 Armazenamento: Calcula o espaço (total e médio por registro) ocupado
pelos dados.
As análises são feitas através de consultas aos próprios dados, utilizando
comandos em SQL. A maior parte desses comandos é montada dinamicamente,
com base no dicionário de dados do MySQL. As informações coletadas são
armazenadas em tabelas auxiliares, que são utilizadas durante todo o resto do
processo. A figura 7 apresenta o protótipo da tela deste modulo.
Figura 5: Módulo de Análise Preliminar
4.3.3 Módulo de Ajuste
Utiliza as informações extraídas durante a análise preliminar para redefinir os
tipos dos campos da tabela, que foram definidos genericamente como literais,
quando da importação. Permite também a remoção de registros indesejados,
revelados pela análise preliminar.
4.3.4 Módulo de Eleição de Chave Primária
Utilizando as informações coletadas pelo módulo de análise preliminar, calcula
o potencial que cada campo tem para ser a chave primária. Este potencial é obtido
dividindo-se o número de valores distintos do campo pelo número total de registros
da tabela, e varia de 0% a 100%.
Em seguida, uma lista com todos os campos, e seus respectivos potenciais, é
apresentada, para que o usuário possa eleger a chave primária.
A priori, apenas campos com potencial igual a 100% poderiam ser
selecionados, uma vez que chaves primárias não aceitam valores repetidos. No
entanto, é possível selecionar campos com potencial inferior a 100%, desde que o
usuário aceite que a ferramenta descarte todos os registros onde o valor do campo
selecionado se repete. Logo, quanto maior o potencial, menor a perda de registros
após a eleição da chave primária.
É possível solicitar o cálculo do potencial para combinações de campos,
permitindo a definição de chaves primárias compostas. O usuário ainda pode rejeitar
os candidatos apresentados e optar por uma chave primária artificial. Nesta última
opção, a ferramenta define o campo ID, gerado quando da importação dos dados,
como chave primária.
Ao término da eleição, a ferramenta define o(s) campo(s) como chave
primária diretamente na tabela atual. Se o usuário optar por campo(s) de potencial
inferior a 100%, a ferramenta cria uma tabela secundária, define a chave primária,
carrega os dados da tabela original e, ao término, informa quantos registros foram
inseridos e ignorados.
Ainda não há protótipo de tela para este módulo.
4.3.5 Módulo de Normalização
Observa os relacionamentos entre os dados e apresenta ao usuário as
informações coletadas, guiando-o através de aplicação de cada uma das formas
normais. A análise dos relacionamentos é feita através da execução de comandos
SQL sobre os próprios dados, capazes de detectar a existência de DFs entre os
campos da tabela.
A Tabela 15 apresenta um exemplo geral de DF, onde ocorre NOME 
SIGLA. Na prática, significa que cada valor de NOME tem apenas um valor
correspondente em SIGLA para todos os registros da tabela. O SQL 1 mostra o
comando capaz de detectar este tipo de relacionamento.
SIGLAS
NOME
ACRE
AUTORIDADES CERTIFICADORAS
CONSELHO REGIONAL DE FARMACIA
CONSELHO REG. DE FARMACIA
GAS LIQUEFEITO PETROLEO
GAS NATURAL VEICULAR
IMPOSTO DE RENDA
RELACAO ANUAL DE INFORMACOES SOCIAIS
SIGLA
AC
AC
CRF
CRF
GLP
GNV
IR
RAIS
Tabela 18: Exemplo geral de DF.
select count( distinct NOME )
into @distinct_NOME
from SIGLAS
;
select count(*) / @distinct_NOME * 100
from
(
select NOME
from SIGLAS
group by SIGLA
having count( distinct SIGLA ) = 1
) as temp
;
SQL 1 : Mensuração do relacionamento entre dois campos
O primeiro comando recupera o número de valores distintos do campo
NOME, que é 8, e armazena na variável @distinct_NOME. O segundo comando
também recupera o número de valores distintos do campo NOME, mas com a
condição de se relacionar com apenas um valor de SIGLA em todos os registros,
que é 8 também, e divide pela variável @distinct_NOME. O resultado, que neste
exemplo é 1, é multiplicado por 100 para converter em porcentagem. Um resultado
de 100% indica que NOME  SIGLA, ou seja, todos os valores de NOME se
relacionam com apenas um valor de SIGLA.
O resultado do algoritmo em SQL 1 para SIGLA e NOME tem um resultado
diferente. Há 6 valores distintos para SIGLA, dos quais 4 se relacionam com apenas
um valor de NOME, fazendo com que o resultado seja 66%. Este resultado indica
que SIGLA  NOME para 66% de seus valores, não sendo possível inferir a DF
entre essas duas variáveis com segurança.
Este processo de mensuração é aplicado ao conjunto de arranjos simples
entre os campos da tabela, tomados dois a dois, e os resultados são armazenados.
O número de combinações possíveis pode ser calculado por n! / (n-2)!, onde “n” é o
número de campos da tabela. Após o término deste processo, a ferramenta
apresenta a lista de todas as duplas de campos analisadas e o valor calculado pelo
algoritmo do SQL 1. A Tabela 16 apresenta o resultado dessa análise de
relacionamentos.
RELACIONAMENTOS
NOME  SIGLA
SIGLA  NOME
DF
100%
66%
Tabela 19: Resultado da análise de relacionamentos.
Para evitar que a detecção de dependências funcionais seja prejudicada por
valores nulos, corrompidos, ou até mesmo inválidos, a ferramenta oferece a opção
de inspecionar os relacionamentos através da visualização de amostras dos
registros.
Para freqüências iguais a 100%, a ferramenta automaticamente infere a
existência de uma DF, e para as freqüências inferiores, mostra alguns dos registros
onde a possível DF foi ferida. Desse modo, o usuário sabe se a detecção de DFs foi
prejudicada por erros nos dados, e tem a opção de corrigi-los.
Para cada DF aceita pelo usuário, a ferramenta efetua a decomposição
correspondente e apresenta as tabelas derivadas.
Uma característica particular desta ferramenta são os algoritmos para
descoberta de dependências funcionais, que foram desenvolvidos na forma de
stored procedures e podem ser incorporados a qualquer banco de dados que tenha
esta funcionalidade. Seu escopo é limitado à normalização de arquivos de forma
individual, não oferecendo suporte à integração dos modelos gerados a partir de
cada arquivo. A interface com o usuário é disponibilizada apenas para possibilitar a
utilização destes algoritmos no meio acadêmico, pois se espera que esta ferramenta
tenha utilidade no ensino de Normalização em disciplinas de Banco de Dados.
Este módulo só se torna acessível após a definição da chave primária, que é
pré-requisito para a normalização.
5
ATIVIDADES FUTURAS
 Definir a metodologia de importação para arquivos XML;
 Definir o módulo de normalização;
 Definir o módulo de Relatórios;
 Finalizar a implementação da ferramenta.
BIBLIOGRAFIA
[1]
Codd, E. F. 1970. A relational model of data for large shared data banks.
Commun.
ACM
13,
6
(Jun.
1970),
377-387.
DOI=http://doi.acm.org/10.1145/362384.362685.
[2]
Heuser, C.A. Projeto de Banco de Dados. 5a edição. Série Livros Didáticos –
Instituto de Informática da UFRGS, número 4. Editora Sagra-Luzzatto, 2004.
[3]
Soutou, C. 1998. Relational database reverse engineering: algorithms to extract
cardinality constraints. Data Knowl. Eng. 28, 2 (Nov. 1998), 161-207.
DOI=http://dx.doi.org/10.1016/S0169-023X(98)00017-2
[4]
Korth, H. F.; Sudarshan, S; Silberschatz, A. Sistema de Banco de Dados. 5a
edição. Editora Campus, 2006.
[5]
D. Bitton, J. Millman, S. Torgersen, A feasibility and performance study of
dependency inference. In: Proc. 5th Int. Conf. on Data Engineering (Feb. 1989)
pp. 635-641.
[6]
M. Castellanos, F. Saltor, Extraction of data dependencies. In: Report LSI-93-2R, University of Catalonia, Barcelona (1993).
[7]
M. Castellanos, A methodology for semantically enriching interoperable
databases. In: Proc. llth British National Conf. on Databases (1993) pp. 58-75.
[8]
R. Chiang, T. Barron, V.C. Storey, Performance evaluation of reverse
engineering relational databases into extended entity-relationship models. In:
Proc. 12th Int. Conf. on Entity-Relationship Approach (1993) pp. 402-413.
[9]
Chen, T. X., Liu, S. S., Meyer, M. D., and Gotterbarn, D. 2007. An introduction to
functional independency in relational database normalization. In Proceedings of
the 45th Annual Southeast Regional Conference (Winston-Salem, North
Carolina, March 23 - 24, 2007). ACM-SE 45. ACM Press, New York, NY, 221225. DOI= http://doi.acm.org/10.1145/1233341.1233381.
[10] Yeh, D. and Li, Y. 2005. Extracting Entity Relationship Diagram from a TableBased Legacy Database. In Proceedings of the Ninth European Conference on
Software Maintenance and Reengineering (March 21 - 23, 2005). CSMR. IEEE
Computer
Society,
Washington,
DC,
72-79.
DOI=
http://dx.doi.org/10.1109/CSMR.2005.31.
[11] Chen, P. P. 1976. The entity-relationship model—toward a unified view of data.
ACM
Trans.
Database
Syst.
1,
1
(Mar.
1976),
9-36.
DOI=
http://doi.acm.org/10.1145/320434.320440.
[12] Ramakrishnan, R., Gehrke, J. Database Management Systems.3th ed. McGraw
Hill. 2003.
[13] Date, C. J. Introdução a Sistemas de Bancos de Dados. 8a edição. Editora
Campus, 2004.
[14] S. Jarzabek, Tan Poh Keam, "Design of a generic reverse engineering assistant
tool," wcre, p. 61, Second Working Conference on Reverse Engineering, 1995.
[15] Antonija Mitrovic, "NORMIT: A Web-Enabled Tutor for Database Normalization,"
icce, p. 1276, 2002 International Conference on Computers in Education
(ICCE'02), 2002.