veja o trabalho

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 COMANDOS SQL ............................................................................................................................. 6
LISTA DE REDUÇÕES ....................................................................................................................................... 7
1
2
INTRODUÇÃO ............................................................................................................................................ 8
1.1
VISÃO GERAL ....................................................................................................................................... 8
1.2
OBJETIVOS .......................................................................................................................................... 10
1.2.1
Geral .............................................................................................................................................. 10
1.2.2
Específicos ..................................................................................................................................... 10
1.3
JUSTIFICATIVA .................................................................................................................................... 11
1.4
METODOLOGIA.................................................................................................................................... 11
1.5
ESTRUTURA DO TRABALHO................................................................................................................. 12
FUNDAMENTAÇÃO TEÓRICA ............................................................................................................ 14
2.1
ENGENHARIA REVERSA ....................................................................................................................... 14
2.1.1
Visão Geral .................................................................................................................................... 14
2.1.2
Engenharia Reversa de Arquivos .................................................................................................. 14
2.2
DEPENDÊNCIA FUNCIONAL ................................................................................................................. 16
2.2.1
Visão Geral .................................................................................................................................... 16
2.2.2
Chave Única e Primária ................................................................................................................ 17
2.2.3
Dependência Funcional Total ....................................................................................................... 19
2.2.4
Dependência Funcional Parcial .................................................................................................... 19
2.2.5
Dependência Funcional Transitiva ou Indireta ............................................................................. 20
2.2.6
Dependência Funcional Multivalorada ......................................................................................... 21
2.2.7
Dependência Funcional de Sub-Domínio ...................................................................................... 21
2.2.8
Anomalias de Alteração................................................................................................................. 22
2.3
O PROCESSO DE NORMALIZAÇÃO ....................................................................................................... 23
2
3
TRABALHOS RELACIONADOS ........................................................................................................... 29
3.1
A INDEPENDÊNCIA FUNCIONAL NA NORMALIZAÇÃO DE BANCOS DE DADOS RELACIONAIS ............... 29
3.2
ENGENHARIA REVERSA DE BANCOS DE DADOS RELACIONAIS: ALGORITMOS PARA EXTRAIR
RESTRIÇÕES DE CARDINALIDADE ...................................................................................................................... 31
4
5
3.3
EXTRAINDO O DIAGRAMA ER DE BANCOS DE DADOS LEGADOS ........................................................ 32
3.4
CONSIDERAÇÕES FINAIS ..................................................................................................................... 34
A FERRAMENTA ..................................................................................................................................... 35
4.1
FUNCIONAMENTO GERAL .................................................................................................................... 35
4.2
TECNOLOGIAS UTILIZADAS ................................................................................................................. 36
4.3
MÓDULOS ........................................................................................................................................... 37
4.3.1
Módulo de Importação .................................................................................................................. 37
4.3.2
Módulo de Pré-Processamento...................................................................................................... 40
4.3.3
Módulo de Eleição de Chave Primária ......................................................................................... 43
4.3.4
Módulo da 1FN.............................................................................................................................. 45
4.3.5
Módulo da 2FN.............................................................................................................................. 48
4.3.6
Módulo da 3FN.............................................................................................................................. 54
CONCLUSÃO ............................................................................................................................................ 57
3
LISTA DE TABELAS
TABELA 1: EXEMPLO DE DEPENDÊNCIA FUNCIONAL. ............................................................................................ 17
TABELA 2: EXEMPLO DE CHAVE PRIMÁRIA............................................................................................................ 18
TABELA 3: EXEMPLO DE DEPENDÊNCIA FUNCIONAL TOTAL. ................................................................................. 19
TABELA 4: EXEMPLO DE DEPENDÊNCIA FUNCIONAL PARCIAL. .............................................................................. 20
TABELA 5: EXEMPLO DE DEPENDÊNCIA FUNCIONAL TRANSITIVA OU INDIRETA. ................................................... 20
TABELA 6: EXEMPLO DE DEPENDÊNCIA FUNCIONAL MULTIVALORADA. ............................................................... 21
TABELA 7: EXEMPLO DE DEPENDÊNCIA FUNCIONAL DE SUB-DOMÍNIO. ................................................................ 22
TABELA 8: EXEMPLO DE ATRIBUTO MULTIVALORADO. .......................................................................................... 26
TABELA 9: ISOLAMENTO DOS DADOS DA UF. ......................................................................................................... 26
TABELA 10: EXEMPLO DE ELIMINAÇÃO DE ATRIBUTOS MULTIVALORADOS. ........................................................... 26
TABELA 11: EXEMPLO DE DEPENDÊNCIA FUNCIONAL PARCIAL. ............................................................................ 27
TABELA 12: RESULTADO DA APLICAÇÃO DA 2FN. ................................................................................................. 27
TABELA 13: RESULTADO DA APLICAÇÃO DA 2FN. ................................................................................................. 27
TABELA 14: EXEMPLO DE DEPENDÊNCIA FUNCIONAL TRANSITIVA OU INDIRETA. ................................................. 28
TABELA 15: RESULTADO DA APLICAÇÃO DA 3FN. ................................................................................................. 28
TABELA 16: RESULTADO DA APLICAÇÃO DA 3FN. ................................................................................................. 28
TABELA 17: RESULTADO DA APLICAÇÃO DA 3FN. ............................................. ERRO! INDICADOR NÃO DEFINIDO.
TABELA 18: EXEMPLO DE INDEPENDÊNCIA FUNCIONAL. ....................................................................................... 30
TABELA 19: NOTAÇÃO MER VS NOTAÇÃO MPC .................................................................................................. 32
TABELA 20: RESULTADO DA IMPORTAÇÃO DE UM ARQUIVO XML......................................................................... 39
TABELA 21: EXEMPLO DE CAMPO MULTIVALORADO. ............................................................................................. 46
TABELA 22: TRANSFORMAÇÃO DE CAMPO MULTIVALORADO EM NOVAS LINHAS. .................................................. 47
TABELA 23: TRANSFORMAÇÃO DE CAMPO MULTIVALORADO EM NOVAS COLUNAS. .............................................. 47
TABELA 24: TRANSFORMAÇÃO DE CAMPO MULTIVALORADO EM VALOR ÚNICO. ................................................... 47
TABELA 25: EXEMPLO GERAL DE DEPENDÊNCIA FUNCIONAL. ................................................................................ 51
TABELA 26: RESULTADO DA ANÁLISE DE RELACIONAMENTOS. .............................................................................. 52
TABELA 27: EXCEÇÕES DA DEPENDÊNCIA FUNCIONAL SIGLA NOME. ............................................................ 53
4
LISTA DE FIGURAS
FIGURA 1: ENGENHARIA REVERSA DE ARQUIVOS. ................................................................................................. 16
FIGURA 2: AS FORMAS NORMAIS E SUAS INTERDEPENDÊNCIAS. ............................................................................ 24
FIGURA 3: FUNCIONAMENTO GERAL DA FERRAMENTA. .......................................................................................... 35
FIGURA 4: EXEMPLO DE XML (CATÁLOGO DE CDS). ............................................................................................ 38
FIGURA 5: TELA DO MÓDULO DE IMPORTAÇÃO. ..................................................................................................... 40
FIGURA 6: TELA DO MÓDULO DE ANÁLISE PRELIMINAR......................................................................................... 42
FIGURA 7: TELA DO MÓDULO DE ELEIÇÃO DA CHAVE PRIMÁRIA. .......................................................................... 45
FIGURA 8: TELA DO MÓDULO DA 1FN. ................................................................................................................... 48
FIGURA 9: TELA DO MÓDULO DA 2FN. ................................................................................................................... 54
FIGURA 10: TELA DO MÓDULO DA 3FN. ................................................................................................................. 56
5
LISTA DE COMANDOS SQL
SQL 1: MENSURAÇÃO DO RELACIONAMENTO ENTRE DOIS CAMPOS. ...................................................................... 51
6
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
7
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, sendo 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. A aplicação desta
decomposição, embora utilize um mapeamento padrão entre tipos de dependências
funcionais e operações de decomposição de entidades, é de difícil automatização,
tendo em vista a alta dependência humana durante a identificação de dependências
funcionais válidas para o domínio de dados em questão.
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 esquema de dados já implementado em direção aos
conceitos do domínio que o geraram [2]. A engenharia reversa é uma funcionalidade
muito comum em ferramentas de modelagem de bancos de dados, como ERwin
(Computer Associates) [16], ER Studio (Embarcadero) [17], DB Designer
8
(fabFORCE) [18], Toad Data Modeler (Quest Software) [19], 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
esquema 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, esquemas de dados, ou até mesmo os dados. Mesmo assim,
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 são baixas,
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 visando diminuir 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
9
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;
• Oferecer uma etapa de pré-processamentos dos dados de entrada, para
que cada campo seja armazenado da melhor forma possível (literal,
numérico, etc.) e tenha uma nomenclatura mais inteligível;
• Auxiliar a definição da chave primária, que é pré-requisito da normalização;
• 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.
10
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, balanceado e 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
preciosismo 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 raramente gera bons resultados. Além disso, revela imaturidade da
empresa com relação a suas metodologias de desenvolvimento.
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 dados e conceitos relacionados;
• Levantamento do estado da arte na área;
• Implementação da ferramenta;
• Apresentação de um estudo de caso.
11
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 importação, pré-processamento, 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 – Este capítulo 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 – Este capítulo apresenta os conceitos
de engenharia reversa de arquivos e modelos relacionais, normalização de
tabelas, dependência funcional e formas normais;
• Capítulo 3: Trabalhos Relacionados – Este capítulo comenta artigos
relacionados ao trabalho e faz uma análise sobre o estado da arte em
normalização;
12
• Capítulo 4: A Ferramenta – Este capítulo descreve a arquitetura,
composição e funcionamento da ferramenta, passando pelos módulos de
importação, pré-processamento, eleição de chave primária, 1FN, 2FN e
3FN e resultados;
• Capítulo 5: Estudo de Caso – Este capítulo apresenta a normalização de
um arquivo de dados através da ferramenta, passo a passo, de forma mais
leve e menos formal, ressaltando os aspectos acadêmicos da mesma;
• Capítulo 6: Conclusões – Este capítulo apresenta as conclusões extraídas
do estudo de caso e do trabalho em geral. Ele aponta ainda aspectos do
trabalho e da ferramenta que não estavam dentro de escopo e que podem
ser incorporados em trabalhos futuros.
13
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
desenvolvida 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 freqüentemente as
manutenções e os melhoramentos mais caros que um projeto novo.
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
14
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 esquemas 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. 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 da
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.
15
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.
16
Tabela 1: Exemplo de Dependência Funcional.
DATA
13/09/2007
13/09/2007
14/09/2007
14/09/2007
15/09/2007
15/09/2007
TEMPERATURAS_MUNICIPIOS
BASE
TABELA
MUNICIPIOS FLORIANOPOLIS
MUNICIPIOS
SAO JOSE
MUNICIPIOS FLORIANOPOLIS
MUNICIPIOS
SAO JOSE
MUNICIPIOS FLORIANOPOLIS
MUNICIPIOS
SAO JOSE
REGISTROS
321654
425658
322654
426547
323547
428452
Analisando-se o relacionamento entre BASE e TABELA, verifica-se que cada
valor do atributo TABELA está relacionado com o mesmo valor do atributo BASE em
todos os registros. Pode-se afirmar, então, que TABELA determina BASE, ou que
TABELA BASE, pela notação formal. Pode-se dizer também que TABELA é o
determinante da dependência funcional. Se fosse inserido na Tabela 1, por exemplo,
um registro onde o valor “FLORIANOPOLIS”, do campo TABELA, aparece
relacionado com um valor diferente de “MUNICIPIOS”, no campo BASE, a
dependência funcional entre estes campos seria quebrada.
A relação entre os campos da dependência funcional e a chave primária
define o tipo de dependência funcional encontrada. Neste trabalho, os campos
sublinhados indicam a chave primária.
2.2.2 Chave Única e Primária
Cada conjunto de um ou mais atributos capaz de identificar unicamente uma
ocorrência de entidade em uma relação é chamado de chave única ou chave
candidata. As chaves podem ser simples, se constituídas de apenas um atributo, ou
compostas, se constituídas de mais de um atributo. A chave primária tende a ser
sempre o menor desses conjuntos e deve considerar não apenas as entidades
17
existentes (em uma relação populada ou amostra), mas todas as entidades que
possam vir a existir. A Tabela 2 esclarece este conceito:
Tabela 2: Exemplo de Chave Primária.
COORDENADAS_MUNICIPIOS
LATITUDE
LONGITUDE
MUNICIPIO
-27:35 (Sul)
-48:32 (Oeste)
FLORIANOPOLIS
-27:35 (Sul)
-48:37 (Oeste)
SAO JOSE
-30:01 (Sul)
-51:13 (Oeste)
PORTO ALEGRE
-31:19 (Sul)
-54:06 (Oeste)
BAGE
-29:46 (Sul)
-55:47 (Oeste)
ALEGRETE
Neste exemplo, são chaves candidatas LONGITUDE, MUNICIPIO, LATITUDE
+ LONGITUDE, LATITUDE + MUNICIPIO, LONGITUDE + MUNICIPIO e, por fim,
LATITUDE + LONGITUDE + MUNICIPIO. Note que LATITUDE não é chave
candidata porque já apresenta valores repetidos, e que as chaves candidatas
elencadas se limitam às tuplas do exemplo. À medida que esta tabela for populada,
a chave candidata LONGITUDE, por exemplo, será invalidada, pois o campo
LONGITUDE passará a apresentar valores duplicados também. Por isso, a chave
primária não pode ser qualquer chave candidata, escolhida aleatoriamente dentre as
disponíveis. É necessário escolher a chave candidata capaz de manter a identidade
de cada registro, independentemente do número de registros na tabela. Neste
exemplo, a chave primária escolhida foi LATITUDE + LONGITUDE, pois cada
combinação de valores desses dois campos sempre define apenas um valor para
MUNICIPIO, logo, nunca se repetirá.
Uma das principais funções da chave primária é garantir a integridade da
tabela, não permitindo a inserção de registros cujos campos que compõem a chave
primária apresentem valores já existentes.
18
2.2.3 Dependência Funcional Total
Quando um atributo depende funcionalmente de todos os atributos que
compõem a chave primária, além de não fazer parte da mesma, tem-se uma
dependência funcional total. A Tabela 3 a seguir esclarece este conceito.
Tabela 3: Exemplo de Dependência Funcional Total.
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
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.4 Dependência Funcional Parcial
Quando um atributo depende funcionalmente de apenas alguns dos atributos
que compõem a chave primária, ou seja, não é necessária a combinação de todos
os campos da chave primária para determinar um dado campo, tem-se uma
dependência funcional parcial. A Tabela 4 a seguir exemplifica este conceito.
19
Tabela 4: Exemplo de Dependência Funcional Parcial.
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)
Neste
exemplo,
LATITUDE,
LONGITUDE
MUNICIPIO
FLORIANOPOLIS
SAO JOSE
PORTO ALEGRE
BAGE
ALEGRETE
MUNICIPIO
é
válido,
dispensando ALTITUDE. Este tipo de relacionamento é classificado como
dependência funcional parcial, uma vez que MUNICIPIO depende funcionalmente
apenas de parte dos atributos que compõem 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.5 Dependência Funcional Transitiva ou Indireta
Este tipo de dependência ocorre quando a dependência funcional se realiza
entre atributos que não fazem parte da chave primária. A Tabela 5 a seguir
exemplifica este conceito.
Tabela 5: Exemplo de Dependência Funcional Transitiva ou Indireta.
REGIAO
SUL
SUL
SUL
SUL
UF
SC
SC
PR
PR
CEPS_MESORREGIOES
MESORREGIAO
GRANDE FLORIANOPOLIS
SERRANA
OESTE PARANAENSE
SUDOESTE PARANAENSE
Neste exemplo, MESORREGIAO
CEP
88036540
88625000
85864530
85601020
UF e UF REGIAO, logo,
MESORREGIAO REGIAO. Este tipo de relacionamento é classificado como
dependência funcional transitiva, ou indireta, uma vez que MESORREGIAO
20
consegue determinar, através da UF, a REGIAO. Observe que nenhum dos campos
envolvido é, ou compõe, a chave primária.
2.2.6 Dependência Funcional Multivalorada
Esta dependência ocorre quando um atributo A determina freqüentemente o
mesmo conjunto de valores em B, independentemente de fazerem parte de chave
primária ou não. A Tabela 6 a seguir exemplifica este conceito.
Tabela 6: Exemplo de Dependência Funcional Multivalorada.
MARCA
FORD
FORD
FORD
FIAT
FIAT
FIAT
FORD
FIAT
FIAT
FORD
FIAT
FORD
MODELOS
MODELO
ANO
FOCUS
1999
KA
2001
FOCUS
2002
PALIO
1998
UNO
2005
PALIO
2006
KA
1995
PALIO
2003
UNO
2001
FOCUS
2006
UNO
1993
KA
2007
QUILOMETRAGEM
95000
48000
45000
76000
13000
23000
89000
30000
65000
15000
78000
5600
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.7 Dependência Funcional de Sub-Domínio
Esta dependência ocorre quando A B não ocorre, mas existe pelo menos
um valor de A que sempre se relaciona com apenas um valor em B. Em outras
21
palavras, se trata de uma dependência funcional detectada em apenas alguns
valores dos campos. A Tabela 7 a seguir exemplifica este conceito.
Tabela 7: Exemplo de Dependência Funcional de Sub-Domínio.
PRODUTOS
NOME
MEDIDA UNIDADES
MARGARINA
250 gr
100
MARGARINA
500 gr
250
OLEO
1000 ml
150
REFRIGERANTE 250 ml
500
REFRIGERANTE 350 ml
100
REFRIGERANTE 1000 ml
1250
OLEO
900 ml
75
LEITE
1000 ml
400
Neste exemplo, NOME MEDIDA não ocorre, pois há valores de NOME que
se relacionam com mais de um valor de MEDIDA. No entanto, o valor “LEITE”, do
campo NOME, relaciona-se apenas com o valor “1000 ml”, no campo MEDIDA. Este
tipo de relacionamento é classificado como dependência funcional de subdomínio.
2.2.8 Anomalias de Alteração
A detecção de dependências funcionais não totais 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;
22
• 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 funcionais não totais, 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 ocupado pelos
mesmos e dos riscos de anomalias de alteração [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.
23
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 fato de os
dados estarem dentro de uma tabela relacional com uma chave primária já
indica certa conformidade com a 1FN. No entanto, campos cujos valores
são uma série de outros valores, separados por vírgula, tabulação ou outra
forma qualquer, são de mais difícil detecção, e geralmente representam
casos de campos multivalorados. Por isso, é preciso que se observe
algumas instâncias aleatórias dos dados para que se tenha certeza de que
não há campos multivalorados entre elas. 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;
24
• 2ª Forma Normal (2FN): Uma tabela está na 2FN se, e somente se, estiver
na 1FN e não apresentar 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 formas normais é muito mais rara na prática.
A Tabela LOCALIDADES a seguir (Tabela 8) 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 (Tabela 9) e MUNICIPIOS (Tabela 10). 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].
25
Tabela 8: Exemplo de atributo multivalorado.
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 9: Isolamento dos dados da UF.
ID
1
2
3
UFS
REGIAO
SUL
SUL
SUL
UF
SC
RS
PR
Tabela 10: Exemplo de eliminação de atributos multivalorados.
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
A Tabela ATUACOES (Tabela 11) apresenta um exemplo de dependência
funcional 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 (Tabela 13),
levando junto o atributo ID_ATOR, mantendo assim o relacionamento existente. A
tabela original ATUACOES (Tabela 11) é reconstruída (Tabela 12), agora sem o
atributo migrado.
26
Tabela 11: Exemplo de Dependência Funcional Parcial.
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 12: Resultado da aplicação da 2FN.
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 13: 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
A tabela VENCIMENTOS (Tabela 14) apresenta um exemplo de dependência
funcional provocada pelo atributo SALARIO, que depende funcionalmente do
atributo CATEGORIA. Neste caso, como o atributo CATEGORIA não faz parte da
chave, esta dependência funcional é 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 (Tabela 16), levando junto o
atributo CATEGORIA, mantendo assim o relacionamento existente. A tabela original
27
VENCIMENTOS (Tabela 14) é reconstruída (Tabela 15), agora sem o atributo
migrado.
Tabela 14: Exemplo de Dependência Funcional Transitiva ou Indireta.
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 15: Resultado da aplicação da 3FN.
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 16: Resultado da aplicação da 3FN.
CATEGORIAS
NOME
SALARIO
OPERADOR
600,00
SECRETARIA
450,00
ADMINISTRADOR 1000,00
28
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 eliminação das dependências funcionais não é
suficiente para evitar algumas formas básicas de redundância, resultando em
anomalias de alteração 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
29
de todos os valores entre dois atributos é válida, ou seja, não fere nenhuma restrição
semântica. A Tabela 17 esclarece este conceito.
Tabela 17: Exemplo de Independência Funcional.
CONTAS
CORRENTISTA
SALDO
JOAO
-50,00
GISELE
654,21
ANA
1684,32
GABRIEL
-320,15
CAROL
521,78
A Tabela 17 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 17, 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.
30
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
31
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 18
apresenta as diferenças entre as notações MER e MPC.
Tabela 18: Notação MER VS Notação MPC
Relacionamento
Aluno VS Matrícula
Banca VS
Professores
Aluno VS Email
Aluno VS Turma
Descrição
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
Notação
MER
MPC
1:1
[1:1]:[1:1]
n:m
[0:n]:[2:4]
1:n
[1:1]:[0:n]
n:m
[0:n]:[1:n]
A identificação e representação adequada das cardinalidades, apresentada
neste trabalho, deu origem ao módulo de análise preliminar da ferramenta proposta,
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
32
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.
33
Este trabalho deu origem ao módulo de eleição de chave primária de
ferramenta proposta, 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.
34
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 3 apresenta 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 serve de base para todo o resto do processo.
35
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 a 1FN, 2FN e, por fim,
a 3FN. 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.
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.
Esta última informação, em particular, é apresentada no intuito de evidenciar um dos
principais resultados da aplicação da normalização, que é justamente a redução no
tamanho dos dados.
As principais funcionalidades da ferramenta estão divididas em módulos e são
explicadas minuciosamente mais adiante.
4.2
Tecnologias Utilizadas
A plataforma da aplicação é toda desenvolvida em SQL, sendo 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.
Por definição, uma dependência funcional ocorre entre dois atributos se, e somente
se, for verdadeira para todos os registros da tabela [1]. Caso contrário, sua
36
existência não pode ser afirmada. Para que algoritmos baseados neste princípio
possam ser aplicados com segurança, sería necessária uma etapa de tratamento
dos dados, onde estes seriam limpos e padronizados, para que então pudessem ser
analisados pela ferramenta. Para evitar a dependência de uma etapa de tratamento,
foram desenvolvidos outros algoritmos, cuja saída não indica simplesmente se uma
determinada dependência funcional existe ou não, e sim a intensidade em que
ocorre, possibilitando a análise final por parte do projetista.
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, não sendo necessário que
o usuário conheça a formatação do arquivo. Basta utilizar a funcionalidade de prévisualização da importação, onde é possível observar uma amostra dos dados e
descobrir quais caracteres separam as linhas e colunas, informá-los à ferramenta e
solicitar a pré-visualização de como os dados ficariam após a importação. Desse
modo, o usuário pode testar diferentes separadores de linha e coluna até chegar a
37
um resultado que julgue satisfatório, procedendo então com a importação de fato.
Caso o usuário não tenha experiência com manipulação de dados, há recursos na
ferramenta para auxiliá-lo, descrevendo o processo de importação e fornecendo
exemplos de separadores de linha e coluna mais freqüentes.
Para arquivos XML, a ferramenta automaticamente efetua a transformação
das tags em linhas e colunas. A tag raiz é ignorada, sendo a tag imediatamente
descendente interpretada como um registro novo, e as demais tags descendentes
desta, incluindo seus respectivos atributos, são interpretadas como colunas. A Figura
4 apresenta um exemplo de XML.
<?xml version="1.0" encoding="ISO-8859-1"?>
<CATALOG>
<CD>
<TITLE>Empire Burlesque</TITLE>
<ARTIST>Bob Dylan</ARTIST>
<COMPANY>Columbia</COMPANY>
<PRICE>10.90</PRICE>
<YEAR>1985</YEAR>
</CD>
<CD>
<TITLE>Hide your heart</TITLE>
<ARTIST>Bonnie Tylor</ARTIST>
<COMPANY>CBS Records</COMPANY>
<PRICE>9.90</PRICE>
<YEAR>1988</YEAR>
</CD>
<CD>
<TITLE>Greatest Hits</TITLE>
<ARTIST>Dolly Parton</ARTIST>
<COMPANY>RCA</COMPANY>
<PRICE>9.90</PRICE>
<YEAR>1982</YEAR>
</CD>
</CATALOG>
Figura 4: Exemplo de XML (Catálogo de CDs).
38
No exemplo da Figura 4, a tag a ser ignorada é <CATALOG>, pois é a tag
raiz. A tag imediatamente descendente, <CD>, é tratada como o início de um
registro. As demais tags descendentes (<TITLE>, <ARTIST>, <COMPANY>,
<PRICE>, <YEAR>) são tratadas como as colunas que compõem o registro
corrente. A Tabela 19 mostra o resultado da importação do XML na Figura 4 para
uma tabela.
Tabela 19: Resultado da importação de um arquivo XML.
TITLE
Empire Burlesque
Hide your heart
Greatest Hits
ARTIST
Bob Dylan
Bonnie Tylor
Dolly Parton
COMPANY
Columbia
CBS Records
RCA
PRICE YEAR
10.90 1985
9.90
1988
9.90
1982
Inicialmente, os campos da tabela de destino são definidos como literais,
especificamente do tipo texto, uma vez que o tamanho e o tipo dos dados ainda são
desconhecidos neste passo. No módulo seguinte, de pré-processamento, estes
campos são analisados e definidos de forma mais adequada.
A Figura 5 apresenta a tela deste modulo, com a pré-visualização da
importação de dados em um domínio de ligações telefônicas. O arquivo texto que
contém os dados separa os campos com o caractere “;” (ponto e vírgula), e as linhas
pelos caracteres consecutivos “\r\n” (retorno de carro e linha nova).
39
Figura 5: Tela do módulo de Importação.
Após a importação, os nomes dos campos são carregados em uma tabela
auxiliar, que é utilizada na montagem dinâmica de vários comandos SQL utilizados
pela ferramenta.
À esquerda, o usuário pode navegar pelas tabelas normalizadas do projeto
corrente ou de projetos anteriores. O usuário não pode alterá-las diretamente, mas
pode ver uma amostra dos dados de cada uma delas.
4.3.2 Módulo de Pré-Processamento
Este módulo transforma os tipos dos campos da tabela, inicialmente do tipo
texto, para tipos mais adequados aos dados observados. O usuário define, para
cada campo, o novo tipo, dentre os tipos apresentados pela ferramenta, que são os
seguintes:
40
• Literal: Materializado como varchar(n), onde n é o tamanho do maior valor
do campo;
• Inteiro: Materializado como tinyint, smallint, mediumint, integeger ou bigint,
de acordo com o valor máximo do campo;
• Real: Materializado como float;
• Booleano: Materializado como boolean.
Para optar com mais segurança por um tipo diferente do sugerido, o usuário
pode observar uma amostra dos dados de cada campo, além de ser impedido de
escolher tipos cuja transformação possa causar perda de informação, como
transformar literais em inteiros, que resulta na anulação dos valores do campo.
Para sugerir o tipo mais adequado para cada campo, este módulo investiga os
dados armazenados em cada um deles, extraindo informações como tamanho
máximo e mínimo, valores distintos, além de verificar se é número inteiro ou real. As
regras de sugestão são as seguintes:
• Se tiver apenas 2 valores distintos, sugere Booleano;
• Se for número inteiro, sugere Inteiro;
• Se for número real, sugere Real;
• Caso contrário, sugere Literal.
Todos os testes estão encapsulados em uma stored procedure, cuja função é
inferir o tipo de um dado campo através das análises de seus valores, como recém
explicado. A maior parte desses comandos é montada dinamicamente, com base
nas informações coletadas ao fim da etapa de importação, uma vez que os campos
têm nomes desconhecidos.
41
Além do ajuste fino em cada campo, o usuário ainda pode excluir colunas e
linhas que apresentem dados irrelevantes, corrompidos, inválidos, ou outra
característica em particular que os façam descartáveis.
A Figura 6 apresenta a tela deste modulo durante a importação de um arquivo
de dados de ligações telefônicas. A primeira coluna contém os nomes dos campos
do arquivo, a segunda sugere um novo tipo para o campo, a terceira oferece a opção
de renomear o campo e a última oferece a opção de selecionar um tipo de dado
diferente do sugerido pela ferramenta. Na parte inferior da tela, os botões que
comandam o início da análise, a inspeção de valores, a exclusão de campos e a
aplicação dos ajustes efetuados.
Figura 6: Tela do módulo de Pré-Processamento.
42
4.3.3 Módulo de Eleição de Chave Primária
A aplicação das formas normais em uma tabela exige a existência de uma
chave primária. Ao contrário de um projeto top-down, onde se recorre ao domínio
dos dados de uma entidade para eleger sua chave primária, projetos bottom-up
precisam “descobrir” a chave primária de cada tabela através da análise dos próprios
dados. Este módulo auxilia o usuário nesta tarefa, analisando os dados e calculando
o potencial de cada campo, ou combinação de campos, para ser a chave primária, e
apresenta os resultados ao usuário.
Este potencial é obtido dividindo-se o número de valores distintos do campo
pelo número total de registros da tabela, variando de 0% a 100%. Em uma tabela
com 100 registros, por exemplo, um campo com 100 valores distintos tem um
potencial de 100%, uma vez que cada valor desse campo identifica unicamente cada
registro da tabela, podendo ser eleito como chave primária sem perda de
informação. Em contrapartida, um campo com 70 valores distintos tem potencial de
70%, o que significa que este campo tem valores duplicados, e não pode ser eleito
como chave primária sem perda de registros.
No caso de potenciais inferiores a 100%, ainda há que se considerar a
presença de erros no cadastro dos dados, que podem impedir a identificação da
chave primária. Para que o usuário tenha certeza de que o potencial de um dado
campo, ou de uma combinação de campos, não foi prejudicado por erros nos dados,
a ferramenta oferece uma amostra dos registros que se repetem, impedindo-o(s) de
alcançar um potencial de 100%. Esta funcionalidade é útil para detectar registros
integralmente duplicados, valores corrompidos, nulos, inválidos ou, ainda, explorar o
comportamento dos outros campos em relação ao campo em questão.
43
O módulo apresenta, inicialmente, uma lista com os potenciais dos conjuntos
formados por um ou dois campos. Teoricamente, apenas conjuntos com potencial
igual a 100% poderiam ser selecionados, uma vez que chaves primárias não
aceitam valores repetidos. No entanto, a ferramenta permite selecionar conjuntos
com potencial inferior a 100%, desde que o usuário aceite que a ferramenta descarte
todos os registros onde aquele conjunto se repete. Logo, quanto maior o potencial
apresentado por um conjunto de um ou mais campos, menor a perda de registros
após a eleição da chave primária.
Ao término da eleição, a ferramenta define o(s) campo(s) como chave
primária diretamente na tabela original. 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
nessa nova tabela, carrega os dados da tabela original ignorando os duplicados e,
ao término, informa quantos registros foram inseridos e ignorados.
É possível solicitar o cálculo do potencial para conjuntos de três ou mais
campos, se necessário. O usuário pode, ainda, rejeitar as chaves candidatas
apresentadas e optar por uma chave primária artificial. Nesta última opção, a
ferramenta adiciona à tabela um novo campo, chamado ID, do tipo inteiro, autoincremental, não nulo, e o elege como chave primária.
A Figura 7 apresenta a tela deste modulo.
44
Figura 7: Tela do módulo de Eleição da Chave Primária.
4.3.4 Módulo da 1FN
O módulo da 1FN auxilia o usuário na eliminação de anomalias nos dados
como campos multivalorados e tabelas aninhadas, para que a tabela fique em
conformidade com a 1FN. A ferramenta aplica uma varredura nos dados carregados,
a procura de valores não atômicos, isto é, que representem dois ou mais valores. A
busca tem como foco caracteres freqüentemente utilizados para separar valores em
arquivos de dados, como “,” (vírgula), “;” (ponto e vírgula), tabulação, “ ” (espaço), “|”
(pipe), ou outros caracteres de escolha do usuário. A tabela 20 apresenta um caso
de campo multivalorado.
45
Tabela 20: Exemplo de campo multivalorado.
ID
1
2
3
4
5
6
7
ENVIO DE MENSAGENS
TEXTO
DESTINO
STATUS
Olá
4898765432
OK|ENVIANDO
Pronto
4734245698
ERRO|ENVIANDO
Sistema OK
1134982345
SEM CRÉDITO
Consulta às 08:00 4133578900 RECUSADA|ENVIANDO
To saindo agora
6435465768
SEM OPERADORA
Vamos ao cinema? 5124358907
OK|ERRO|ENVIANDO
Vou me atrasar!
4827849506
EXPIRADA
LOG
03/10/2007
05/10/2007
05/10/2007
06/10/2007
09/10/2007
13/10/2007
17/10/2007
Na Tabela 20 o campo STATUS armazena uma série de valores, separados
por “|” (pipe), representando um histórico de todos os status pelos quais cada
mensagem passou. Este tipo de campo leva a uma análise de dependências
funcionais equivocada, comprometendo o resultado da normalização. Ao detectar um
campo multivalorado, o usuário tem as seguintes opções:
• Gerar um novo registro para cada valor aninhado, repetindo os demais
campos;
• Gerar novas colunas para cada valor aninhado (serão geradas tantas
colunas quantos forem os valores aninhados);
• Remover os valores aninhados excedentes, deixando apenas um
(arbitrariamente o primeiro);
• Ignorar o aninhamento, caso o campo não seja de fato multivalorado ou o
usuário o julgue irrelevante.
As tabelas 21, 22 e 23, a seguir, apresentam o resultado gerado para cada
uma das opções supracitadas.
46
Tabela 21: Transformação de campo multivalorado em novas linhas.
ID
1
1
2
2
3
4
4
5
6
6
6
7
ENVIO DE MENSAGENS
TEXTO
DESTINO
STATUS
Olá
4898765432
OK
Olá
4898765432
ENVIANDO
Pronto
4734245698
ERRO
Pronto
4734245698
ENVIANDO
Sistema OK
1134982345
SEM CRÉDITO
Consulta às 08:00 4133578900
RECUSADA
Consulta às 08:00 4133578900
ENVIANDO
To saindo agora
6435465768
SEM OPERADORA
Vamos ao cinema? 5124358907
OK
Vamos ao cinema? 5124358907
ERRO
Vamos ao cinema? 5124358907
ENVIANDO
Vou me atrasar!
4827849506
EXPIRADA
LOG
03/10/2007
03/10/2007
05/10/2007
05/10/2007
05/10/2007
06/10/2007
06/10/2007
09/10/2007
13/10/2007
13/10/2007
13/10/2007
17/10/2007
Tabela 22: Transformação de campo multivalorado em novas colunas.
ID
TEXTO
1
Olá
2
Pronto
3 Sistema OK
4 Consulta...
5 To saindo...
6 Vamos ao...
7
Vou me...
DESTINO
4898765432
4734245698
1134982345
4133578900
6435465768
5124358907
4827849506
STATUS1
OK
ERRO
S/ CRÉDITO
RECUSADA
S/ ROTA
OK
EXPIRADA
STATUS2 STATUS3
LOG
ENVIANDO
03/10/2007
ENVIANDO
05/10/2007
05/10/2007
ENVIANDO
06/10/2007
09/10/2007
ENVIANDO
ERRO
13/10/2007
17/10/2007
Tabela 23: Transformação de campo multivalorado em valor único.
ID
1
2
3
4
5
6
7
TEXTO
Olá
Pronto
Sistema OK
Consulta às 08:00
To saindo agora
Vamos ao cinema?
Vou me atrasar!
ENVIO DE MENSAGENS
DESTINO
STATUS
4898765432
OK
4734245698
ERRO
1134982345
SEM CRÉDITO
4133578900
RECUSADA
6435465768
SEM OPERADORA
5124358907
OK
4827849506
EXPIRADA
LOG
03/10/2007
05/10/2007
05/10/2007
06/10/2007
09/10/2007
13/10/2007
17/10/2007
A quarta opção simplesmente ignora o campo multivalorado, e o usuário é
informado a respeito das conseqüências decorrentes dessa escolha. A ausência de
campos multivalorados indica que a tabela está de acordo com a 1FN e, portanto,
47
em condições de ser submetida à aplicação da 2FN. A Figura 8 apresenta a tela
deste módulo.
Figura 8: Tela do módulo da 1FN.
Esta tela mostra a aplicação da 1FN sobre dados de teste. A primeira coluna
lista os campos, a segunda mostra a freqüência de aninhamentos detectada em
cada campo, a terceira mostra o caractere usado para separar os valores e a última
oferece a lista de ações possíveis para eliminar os aninhamentos.
4.3.5 Módulo da 2FN
O módulo da 2FN auxilia o usuário na aplicação desta forma normal,
detectando automaticamente as dependências funcionais parciais existentes nos
dados e guiando-o através da remoção de cada uma delas. Após a extração de cada
dependência funcional, as tabelas resultantes são apresentadas ao usuário,
48
situando-o no processo através de seu progresso. O módulo da 3FN só se torna
disponível quando não houver mais dependências funcionais parciais, o que significa
que a 2FN foi aplicada corretamente.
O escopo de uma dependência funcional, como explicado anteriormente,
compreende o conjunto formado por todos os registros de uma tabela, e não apenas
parte deles. Logo, para que A B exista, é necessário que todos os valores de A
consigam determinar seu valor em B, ou seja, uma dada dependência funcional não
possui um nível ou intensidade na qual ocorre. Ela simplesmente existe ou não.
No entanto, para evitar que erros nos dados possam prejudicar a identificação
de dependências funcionais, a ferramenta relaxa essas definições, associando um
nível a cada dependência funcional. Dessa forma, a ferramenta analisa o
relacionamento entre campos e registra a freqüência em que um determina o outro,
gerando um índice para o nível da dependência funcional entre eles. Esse indicador
varia de 0% a 100%, onde 0% indica que um campo não determina o outro em
nenhum de seus valores, e 100% indica que sempre determina, o que corresponde à
tradicional dependência funcional.
Para compreender melhor o funcionamento do mecanismo supracitado, tomese como exemplo uma tabela T(a,b,c,d,e), onde os campos sublinhados compõem a
chave
primária.
Dependências
funcionais
parciais
são
especializações
de
dependências funcionais, pois os campos determinantes fazem parte da chave
primária, e os campos dependentes são campos não chave.
Para gerar os possíveis determinantes, basta aplicar sucessivas combinações
simples entre os componentes da chave, incrementando, a cada iteração, o número
de colunas tomadas concomitantemente, até que a combinação gerada seja a
própria chave primária. Dessa forma, a primeira iteração gera a, b, c, a segunda gera
49
ab, ac, bc, e a terceira gera abc, que é a própria chave, sinalizando o fim das
iterações.
Quanto aos dependentes, basta tomá-los individualmente dos campos não
chave e os combinar com os grupos de determinantes gerados anteriormente. Neste
exemplo, as dependências funcionais a serem testadas são: a d, a e, b d, b
e, c d, c e, ab d, ab e, ac d, ac e, bc d, bc e. Não é
necessário testar se abc d ou abc e ocorrem, pois abc é a própria chave
primária, motivo pelo qual o algoritmo finaliza a geração de combinações no
momento em que o conjunto formado é a própria chave primária. O nível de cada
dependência funcional testada é armazenado em uma tabela auxiliar, que serve de
apoio à etapa de remoção de dependências funcionais.
Dependendo do número de campos e de registros na tabela, o tempo
necessário para efetuar esses testes pode se tornar proibitivo. Para reduzir este
efeito e otimizar o algoritmo, antes de testar cada dependência funcional pela análise
dos próprios dados, a ferramenta lança mão da teoria da cobertura canônica, e tenta
inferir o resultado do teste analisando as dependências funcionais encontradas até o
momento. Se o nível da dependência funcional a ser testada puder ser derivado dos
resultados já armazenados, esta é dispensada de ter seus dados analisados.
A Tabela 24 apresenta um exemplo de análise de dependência funcional,
onde ocorre NOME SIGLA. Na prática, significa que é possível deduzir o valor de
SIGLA para qualquer valor de NOME, com total segurança. O SQL 1 mostra o
comando capaz de detectar este tipo de relacionamento.
50
Tabela 24: Exemplo geral de dependência funcional.
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
select floor( sum( is_unique ) / count(*) * 100 )
from
(
select count( distinct SIGLA ) = 1 as is_unique
from SIGLAS
group by NOME
) as temp
SQL 1: Mensuração do relacionamento entre dois campos.
O select interno, também chamado subselect, pega cada um dos valores
distintos de NOME e verifica com quantos valores distintos de SIGLA ele se
relaciona, retornando 1 se for apenas um, ou 0, se forem mais de 1. O resultado é
uma tabela temporária de apenas uma coluna, de valores 0 e 1, com tantos registros
quanto forem os valores distintos de NOME. Neste exemplo, como todo valor de
NOME está relacionado com apenas um valor em SIGLA, o subselect gera uma
tabela temporária com 8 registros, todos com o valor 1.
O select externo soma todos os valores da tabela, cujo resultado equivale ao
número de valores iguais a 1, divide pelo número total de valores da tabela
temporária e multiplica por 100, para gerar o resultado em forma de porcentagem.
Neste exemplo, a soma dos registros é igual a 8, assim como o número de registros.
Logo, o resultado da divisão é 1, que multiplicado por 100 resulta em 100, indicando
51
que NOME SIGLA em 100% dos casos, ou seja, todos os valores de NOME se
relacionam com apenas um valor de SIGLA.
A aplicação do algoritmo em SQL 1, para verificar a relação SIGLA e NOME
(inversa), gera um resultado diferente. O subselect gerará uma tabela temporária
com 6 registros, uma vez que há 6 valores distintos para SIGLA, dos quais apenas 4
terão valor igual a 1, já que há mais de um valor de NOME para os outros 2, ficando
estes com o valor 0. Quando o select externo fizer a soma, o resultado será 4, que
dividido pelo número total de registros da tabela temporária, que é 6, resultará em
0,66. Após a multiplicação por 100 e a aplicação da função floor(), que arredonda
para baixo, o resultado será 66%, indicando que SIGLA NOME para 66% de seus
valores, não sendo possível inferir a dependência funcional entre esses dois campos
para toda tabela.
Após o término deste processo, a ferramenta apresenta a lista de
dependências funcionais testadas e seus respectivos níveis, calculados pelo
algoritmo em SQL 1. A Tabela 25 apresenta o resultado dessa análise.
Tabela 25: Resultado da análise de relacionamentos.
RELACIONAMENTOS
NOME SIGLA
SIGLA NOME
DEPENDÊNCIA FUNCIONAL
100%
66%
Em caso de dúvidas a respeito do nível de alguma dependência funcional, a
ferramenta oferece uma amostra dos registros onde a mesma foi ferida, para
descobrir se o nível aferido é reflexo de erros ou características naturais dos dados.
Ao analisar os registros onde SIGLA NOME não aconteceu, observa-se que os
valores de SIGLA “AC” e “CRF” têm relação com 2 valores em NOME, cada um.
Para “CRF”, os 2 valores de NOME significam a mesma coisa, sendo distintos entre
52
si apenas pela grafia. Variações dessa sorte são um exemplo clássico de anomalia
nos dados capaz de camuflar características importantes como uma dependência
funcional. No caso de “AC”, os 2 valores de NOME refletem possivelmente uma
característica natural dos dados, cabendo ao usuário descobrir a veracidade da
informação, ou qual dos valores é mais adequado ao domínio dos dados. A Tabela
26 apresenta as exceções da dependência funcional SIGLA NOME.
Tabela 26: Exceções da dependência funcional SIGLA NOME.
SIGLA
AC
CRF
EXCEÇÕES
NOME
ACRE
AUTORIDADES CERTIFICADORAS
CONSELHO REGIONAL DE FARMACIA
CONSELHO REG. DE FARMACIA
Neste ponto, o usuário remove as dependências funcionais de nível igual a
100% e analisa amostras das que tem nível inferior a 100%, decidindo pela remoção
em caso de erro. A cada dependência funcional removida, as tabelas resultantes são
apresentadas ao usuário. Após a remoção de todas as dependências funcionais, o
usuário adquire acesso ao módulo da 3FN. A Figura 9 apresenta a tela deste
módulo.
53
Figura 9: Tela do módulo da 2FN.
4.3.6 Módulo da 3FN
Semelhante ao módulo da 2FN, este módulo auxilia o usuário na aplicação da
3FN, exceto pelo fato de que a dependência funcional procurada é a indireta, isto é,
entre atributos que não fazem parte da chave primária.
A geração dos possíveis determinantes é efetuada da mesma forma descrita
no módulo da 2FN, com a diferença que os campos que formam tanto os
determinantes quanto os dependentes são escolhidos dentre os campos que não
fazem parte da chave primária. Na tabela T(a,b,c,d,e,f), a geração sucessiva de
combinações simples para formar os determinantes gera d, e, f, de, df, ef, def, e a
aplicação do mesmo processo para formar os dependentes gera d, e, f. Dessa
forma, as dependências funcionais a serem testadas, geradas pela combinação
entre os determinantes e os dependentes, são d d, e d, f d, de d, df d,
ef d, def d, d e, e e, f e, de e, df e, ef e, def e, d f, e 54
f, f f, de f, df f, ef f, def f. Não há necessidade de se testar
dependências
funcionais
onde
o
dependente
está
presente
também
no
determinante, motivo pelo qual é feita uma filtragem nas combinações geradas,
removendo todos os elementos nessas condições. Assim, após a aplicação desse
filtro, as dependências funcionais a serem testadas se resumem a e d, f d, ef
d, d e, f e, df e, d f, e f, de f.
No passo seguinte, a ferramenta percorre as dependências funcionais
geradas e vai medindo a freqüência em que ocorrem, utilizando o mesmo processo
aplicado pelo módulo da 2FN. Em seguida, o usuário remove as dependências
funcionais de nível igual a 100% e analisa amostras das que tem nível inferior a
100%, decidindo pela remoção das mesmas caso observe que a dependência
funcional não atingiu freqüência igual a 100% em virtude de erros nos dados. A cada
dependência funcional removida, as tabelas resultantes são apresentadas ao
usuário. Após a remoção de todas as dependências funcionais, o usuário adquire
acesso ao módulo de relatórios. A Figura 10 apresenta a tela deste módulo.
55
Figura 10: Tela do módulo da 3FN.
56
5
CONCLUSÃO
O processo de normalização de tabelas, em virtude da carga de
conhecimento teórico e intimidade com o domínio dos dados exigidos do projetista,
pode se tornar complexo e pouco eficiente, caso não se disponha de um profissional
adequadamente qualificado. Além disso, quando se parte de tabelas já populadas,
como no caso de projetos bottom-up de bancos de dados, há outros fatores
agravantes, como a qualidade dos dados, que pode impedir que dependências
funcionais sejam descobertas, comprometendo todo o andamento do projeto. O
mesmo problema ocorre quando se deseja normalizar documentos de dados
legados, como arquivos XML ou arquivos texto estruturados.
O objetivo deste trabalho foi desenvolver uma ferramenta de apoio a este
processo, capaz de reduzir o conhecimento necessário sobre normalização e
aproximar o usuário do domínio dos dados. A princípio, um algoritmo capaz de varrer
os dados em busca de dependências funcionais, utilizando uma abordagem
resistente a dados de má qualidade, seria suficiente. Contudo, a ferramenta
rapidamente se mostrou muito mais complexa que isso. Para otimizar o desempenho
das análises, é preciso um processamento preliminar dos dados, o que exigiu o
desenvolvimento de um módulo de pré-processamento. As regras que compõem a
normalização giram em torno de uma chave primária, que não pode ser definida
arbritariamente, no caso de uma tabela populada. Isto exigiu o desenvolvimento de
um módulo capaz de auxiliar o usuário a compor a chave primária da forma mais
adequada possível: o módulo de eleição da chave primária. Por obedecerem a uma
ordem de aplicação e estarem baseadas em um tipo específico de restrição a ser
descoberta e eliminada, as formas normais também foram separadas em módulos.
57
Ao término do processo, tornou-se evidente a necessidade de apresentar ao usuário
o resultado da normalização aplicada e os benefícios desta técnica, como a
diminuição no espaço ocupado pelos dados, que foi implementado em um último
módulo.
A principal contribuição deste trabalho está nos algoritmos capazes de
detectar dependências funcionais em tabelas, sem que erros nos dados das
mesmas comprometam o resultado da detecção. Esta ferramenta pode tornar mais
freqüênte o processo de normalização de tabelas, tendo em vista que grande parte
da teoria presente na literatura de banco de dados está embutida na ferramenta,
cabendo ao usuário apenas avaliar os cenários oferecidos pela ferramenta e decidir
a ação a ser tomada. No âmbito acadêmico, esta ferramenta pode ser empregada
em disciplinas de bancos de dados, especialmente aulas sobre normalização de
tabelas, oferecendo aos alunos uma visão mais prática e concreta sobre formas
normais e dependências funcionais. Através da execução da normalização completa
de um arquivo de dados, o aluno pode perceber os benefícios dessa técnica de
forma mais clara e objetiva.
Testes feitos com a ferramenta, utilizando arquivos de dados de diversos
domínios, geraram resultados similares à aplicação da técnica de forma tradicional.
No entanto, apesar de toda a automatização que a ferramenta oferece, algumas
etapas da normalização são de natureza altamente intelectual e dependem de um
projetista que tenha certa intimidade com o domínio dos dados.
A ferramenta desenvolvida durante o curso deste trabalho ainda se apresenta
de forma primitiva, podendo ser extendida para detectar dependências funcionais
mais complexas, como as que foram descritas no capítulo da fundamentação
teórica, cobrindo assim outras formas normais. Além disso, pode ser integrada a
58
ambientes de desenvolvimento de projetos e manipulação de bancos de dados, já
que estes não oferecem nenhuma solução para a etapa de normalização. Ainda que
desenvolvida em java, o que permite a utilização em qualquer plataforma, a
ferramenta pode se tornar ainda mais versátil com uma interface web, pela alta
disponibilidade que este ambiente oferece.
59
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
60
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.
[16] Computer Associates. ERWin. Disponível em: <http://www.ca.com>. Acesso em
14 out. 2007.
[17] Embarcadero . ER Studio. Disponível em: <http://www.embarcadero.com>.
Acesso em 14 out. 2007.
[18] fabFORCE . DB Designer. Disponível em: <http://fabforce.net>. Acesso em 14
out. 2007.
61
[19] Quest Software. Toad Data Modeler. Disponível em: <http://www.quest.com>.
Acesso em 14 out. 2007.
62