Você está na página 1de 43

UNIVERSIDADE FEDERAL DE SANTA CATARINA CENTRO TECNOLGICO DEPARTAMENTO DE INFORMTICA E ESTATSTICA CURSO DE SISTEMAS DE INFORMAO

Uma Ferramenta de Apoio Normalizao de Tabelas Baseada na Anlise dos Dados

Aluno: Michel Leite de vila Orientador: Ronaldo Santos Mello

Florianpolis, SC Junho de 2007

SUMRIO

LISTA DE TABELAS

LISTA DE FIGURAS

LISTA DE REDUES SGBD ER MER MRP XML n DF Sistema de Gerenciamento de Bancos de Dados Entidade-Relacionamento Modelo Entidade-Relacionamento Modelo Restrio de Participao Extended Markup Language No normalizada Dependncia Funcional

1 1.1

INTRODUO Viso Geral A normalizao de tabelas foi proposta por Edgar Frank Codd, em 1970,

juntamente com o prprio modelo de dados relacional, como uma tcnica para eliminar redundncias de informaes e evitar anomalias causadas pela insero, atualizao e remoo de registros [1]. A aplicao desta tcnica no trivial, exigindo conhecimento sobre formas normais e dependncias funcionais, alm da teoria de bancos de dados relacionais. O sucesso da normalizao depende, tambm, da intimidade do projetista com o domnio dos dados. O cerne da normalizao reside na identificao de dependncias funcionais, que so relacionamentos especiais entre entidades e atributos, e sero explicadas em detalhes no captulo 2. Uma vez identificadas, as dependncias funcionais so eliminadas sistematicamente, de acordo com sua classificao, atravs da decomposio das entidades em entidades mais simples. Essa decomposio um simples mapeamento padro entre tipos de dependncias funcionais e operaes de decomposio de entidades, de tal sorte que a automatizao total desta tarefa s no possvel em virtude da alta dependncia humana durante a identificao de dependncias funcionais. A normalizao parte fundamental da engenharia reversa de arquivos de dados, conhecida tambm como projeto de banco de dados bottom-up, onde, em linhas gerais, parte-se de um modelo j implementado em direo 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 so 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 lgico e, por fim, gerar o modelo conceitual. A automatizao que estas ferramentas oferecem, no entanto, no cobre a etapa de normalizao, cuja aplicao continua a cargo do projetista [3]. No mbito acadmico, h poucos artigos que abordam a descoberta de dependncias funcionais utilizando anlises sobre as informaes disponveis, como o cdigo da aplicao, 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 automatizao partem de uma srie de informaes 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 normalizao ainda uma tarefa

predominantemente manual, onde o conhecimento do projetista tem total impacto sobre a qualidade dos esquemas lgico e conceitual resultantes. Para atenuar tal impacto, este trabalho prope uma ferramenta para apoiar a etapa de normalizao de tabelas, com foco no auxilio descoberta de dependncias funcionais, diminuindo a necessidade de conhecimento terico e do domnio 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 informaes para apoiar a aplicao de cada passo da normalizao, solicitando a interveno do usurio apenas quando as informaes extradas no so capazes de decidir por uma decomposio com segurana. Em cada passo, so apresentadas as regras que compem cada forma normal, utilizando exemplos com

os prprios dados de entrada. O resultado do processo um conjunto de tabelas normalizadas. 1.2 Objetivos 1.2.1 Geral Desenvolver uma ferramenta de apoio normalizao de tabelas com base na anlise de uma fonte de dados, de modo a diminuir o impacto do conhecimento do projetista sobre o resultado da normalizao. 1.2.2 Especficos 1. Oferecer suporte importao de dados contidos em arquivos de texto ou XML; 2. Apresentar caractersticas gerais dos dados carregados, como tipo (literal ou numrico), tamanho mximo e mnimo, valores distintos, etc., atravs de uma anlise preliminar; 3. Aplicar as formas normais, solicitando a concordncia do usurio em cada passo; 4. Informar ao usurio os conceitos envolvidos em cada decomposio efetuada; 5. 6. Apresentar relatrio com as tabelas resultantes; Apresentar a diferena entre o espao alocado pelos dados antes e depois da normalizao.

1.3

Justificativa A normalizao, em projetos de bancos de dados, pode ser vista como uma

etapa de garantia de conformidade e qualidade, onde as tabelas so analisadas e submetidas a um grande conjunto de alteraes sistemticas at alcanar certo nvel de otimizao, estipulado pelo prprio projetista. As propostas para automatizar esta etapa dependem da disponibilidade de modelos e descries a respeito da estrutura dos dados, que nem sempre esto disponveis. Alm disso, necessrio conhecer o domnio dos dados para aplicar uma normalizao adequada, o que pode levar muito tempo, dependendo do domnio. A combinao destes fatores faz com que esta etapa seja encarada como um luxo acadmico, pelo tempo que consome, e enfadonha, pela carga de conhecimento terico que requer. Como resultado, a normalizao freqentemente ignorada, deixando a qualidade do projeto fortemente dependente da experincia do projetista, o que nem sempre gera bons resultados. 1.4 Metodologia Para que os objetivos, h pouco expostos, sejam alcanados, este trabalho segue as etapas abaixo elencadas: Estudo sobre a normalizao de tabelas e conceitos relacionados; Levantamento do estado da arte na rea; Implementao da ferramenta;

Apresentao de um estudo de caso. Na primeira etapa, so apresentadas as teorias sobre as quais a normalizao se apia, com exemplos descritivos e ilustrativos para auxiliar a compreenso dos mesmos. A segunda etapa consiste em uma pesquisa sobre trabalhos relacionados a alguma forma de suporte automatizado ao processo de normalizao, com o intuito de se determinar o avano tecnolgico na rea e incorporar conceitos teis ao trabalho. A terceira etapa refere-se implementao da ferramenta, que consiste na definio dos algoritmos para determinao de chave primria, descoberta de relacionamentos, migrao de atributos para novas tabelas e desenvolvimento da interface grfica. Na quarta etapa, feito um estudo de caso onde um arquivo de dados normalizado manualmente e atravs da ferramenta, sendo os resultados analisados. 1.5 Estrutura Do Trabalho Este trabalho est dividido da seguinte forma: Captulo 1: Introduo Contextualiza a normalizao de tabelas e apresenta o trabalho de forma geral, comentando sobre seus objetivos gerais e especficos, justificativa, metodologia e organizao; Captulo 2: Fundamentao Terica Apresenta os conceitos de engenharia reversa de arquivos e modelos relacionais, normalizao de tabelas, dependncia funcional, formas normais;

Captulo 3: Trabalhos Relacionados Comenta artigos relacionados ao trabalho e faz uma anlise sobre o estado da arte em normalizao; Captulo 4: A Ferramenta Descreve a arquitetura proposta para a ferramenta: os mdulos de importao, anlise preliminar, ajuste, eleio de chave primria, anlise de dependncias funcionais e anlise de resultados; Captulo 5: Estudo de Caso Executa a normalizao de um arquivo tanto atravs da ferramenta quanto manualmente, apresentando um estudo comparativo dos resultados ao final; Captulo 6: Concluses Apresenta as concluses extradas do estudo de caso e do trabalho, em geral. Aponta ainda aspectos do trabalho e da ferramenta que no estavam dentro de escopo e que podem ser incorporados em trabalhos futuros; Bibliografia Registra as fontes de informao consultadas para a confeco deste trabalho.

2 2.1

FUNDAMENTAO TERICA Engenharia Reversa 2.1.1 Viso Geral Em linhas gerais, pode-se definir a engenharia reversa como um processo de

abstrao, 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 lgicos de conjuntos de dados no relacionais, num processo denominado engenharia reversa de arquivos. Este processo composto por vrias tarefas, sendo seguido por outro processo, chamado de engenharia reversa de modelos relacionais, cujo objetivo gerar modelos conceituais a partir de modelos lgicos. H muitas outras aplicaes para a engenharia reversa, mas no so abordadas neste trabalho por estarem fora do escopo do mesmo. 2.1.2 Engenharia Reversa de Arquivos Grande parte dos sistemas de informao utilizados ainda hoje foi desenvolvido no decorrer dos ltimos 20 anos, em linguagens de terceira gerao como COBOL e Basic, utilizando bancos de dados pr-relacionais como IMS ou ADABAS, sendo conhecidos como sistemas legados [2]. Estes sistemas raramente apresentam documentao e, quando existe, pobre, tornando as manutenes e melhoramentos mais caros que um projeto novo, em alguns casos. O modelo conceitual vital para que pessoas que no conhecem o sistema tenham condies de assimilar seu funcionamento e participar de discusses a respeito de alteraes e melhorias do mesmo. O processo de migrao de bancos

de dados legados para tecnologias mais atuais, como bancos de dados relacionais e no-convencionais, tambm 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: Converso da descrio de arquivos em tabelas relacionais n: Converte a descrio de cada arquivo existente para um esquema relacional no normalizado, ou simplesmente n. Neste passo inicial, obtm-se a independncia dos tipos de arquivo importados, j que so todos transformados em uma estrutura tabular; Normalizao: Reagrupa as informaes para eliminar redundncias e evitar anomalias ocasionadas pela atualizao de registros. Esta tcnica detalhada mais adiante; Integrao de esquemas: Gera o esquema relacional completo atravs integrao dos esquemas relacionais normalizados de cada arquivo. Como a integrao de normalizados no gera, necessariamente, um esquema integrado j normalizado, esta etapa conta ainda com um passo de eliminao de redundncias entre as tabelas; Extrao do esquema Entidade-Relacionamento (ER): Por fim, o esquema ER extrado, aplicando-se a engenharia reversa de modelos relacionais sobre o conjunto de esquemas relacionais integrados. Esta etapa tambm detalhada mais adiante. A figura 1 oferece uma viso geral destas etapas.

Figura 1: Engenharia Reversa de Arquivos

2.2

Dependncia Funcional 2.2.1 Viso 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 Dependncia 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, ento, que UF_SIGLA determina UF_NOME, ou que UF_SIGLA UF_NOME, utilizando-se a notao formal. 2.2.2 Dependncia Funcional Total Quando um atributo que no faz parte da chave primria depende funcionalmente de todos os atributos que fazem parte da chave, tem-se uma dependncia funcional total. 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 2: Exemplo de Dependncia Funcional Total.

Neste exemplo, LATITUDE, LONGITUDE MUNICIPIO vlido. Este tipo de relacionamento classificado como dependncia funcional total, uma vez que MUNICIPIO depende funcionalmente de todos os atributos que compe a chave. 2.2.3 Dependncia Funcional Parcial Quando um atributo que no faz parte da chave primria depende funcionalmente de apenas alguns dos atributos que fazem parte da chave primria, tem-se de uma dependncia funcional parcial. 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 3: Exemplo de Dependncia Funcional Parcial.

Neste exemplo, LATITUDE, LONGITUDE MUNICIPIO vlido. Este tipo de relacionamento classificado como dependncia funcional parcial, uma vez que MUNICIPIO depende funcionalmente apenas de parte dos atributos que compe a chave primria, ou seja, a dependncia funcional existente no seria afetada se o atributo ALTITUDE fosse removido da tabela, ou simplesmente deixasse de fazer parte da chave primria. 2.2.4 Dependncia Funcional Transitiva ou Indireta Esta dependncia ocorre quando a dependncia funcional se realiza entre atributos que no fazem parte da chave primria. O exemplo abaixo esclarece este conceito: TEMPERATURAS_MESORREGIOES UF MESORREGIAO SC GRANDE FLORIANOPOLIS SC SERRANA PR OESTE PARANAENSE PR SUDOESTE PARANAENSE

REGIAO SUL SUL SUL SUL

TEMPERATURA 26 25 5 12

Tabela 4: Exemplo de Dependncia Funcional Transitiva ou Indireta.

Neste

exemplo, MESORREGIAO

UF e

UF

REGIAO, logo,

MESORREGIAO REGIAO. Este tipo de relacionamento classificado como

dependncia funcional transitiva, ou indireta, uma vez que MESORREGIAO consegue determinar, atravs da UF, a REGIAO. 2.2.5 Dependncia Funcional Multivalorada Esta dependncia ocorre quando um atributo A determina freqentemente 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 Dependncia Funcional Multivalorada.

Neste exemplo, MARCA MODELO, ou MARCA multidetermina MODELO, porque para cada valor de MARCA existe um conjunto fixo de valores possveis para MODELO, observados em todos os registros. Este tipo de relacionamento classificado como dependncia funcional multivalorada. 2.2.6 Dependncia Funcional de Sub-Domnio Esta dependncia ocorre quando A B no 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 Dependncia Funcional de Sub-Domnio.

Neste exemplo, embora NOME MEDIDA no ocorra, existe pelo menos um valor para NOME que se relaciona com apenas um valor em MEDIDA. Este tipo de relacionamento classificado como dependncia funcional de subdomnio. 2.2.7 Anomalias de Alterao A deteco de dependncias funcionais indica que a tabela possui redundncia e, conseqentemente, est sujeita a anomalias de insero, atualizao e remoo. As anomalias so as seguintes: Anomalias de insero: Ocorrem quando um registro inserido em uma tabela sem que todos os seus atributos tenham sido determinados. No exemplo da Tabela 4, a insero de um novo municpio vinculado a uma UF e regio implicaria a atribuio de uma temperatura nula. Uma alternativa seria inserir o novo municpio apenas quando sua temperatura estiver disponvel tambm. De qualquer forma, no o comportamento adequado; Anomalias de alterao: 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 necessrio efetuar a

alterao em todas as ocorrncias daquela sigla, exigindo a varredura completa da tabela. Caso esta alterao seja efetuada apenas em parte de suas ocorrncias, a tabela fica inconsistente, retornando siglas distintas para a mesma UF; Anomalias de remoo: Ocorrem quando a remoo de algum atributo causa a perda de outras informaes relacionadas. Ainda no exemplo acima, a remoo de um municpio implicaria a perda da unidade federativa e sua sigla. Para evitar as anomalias supracitadas, necessrio detectar e eliminar as dependncias, ou seja, decompor a tabela em outras tabelas que no possuam mais redundncia. 2.3 O Processo de Normalizao A normalizao um processo composto por algumas regras, chamadas formas normais, cujo objetivo principal eliminar a redundncia nos dados armazenados em tabelas, resultando na diminuio do espao e dos riscos de inconsistncias em atualizaes de dados [4]. Quando um atributo alterado em uma tabela que no est totalmente normalizada, necessrio alter-lo em todas as linhas em que ele ocorre, haja vista a sua repetio. Tal operao poderia ser executada apenas uma vez, caso este atributo estivesse normalizado. As principais formas normais encontradas na literatura so mostradas na Figura 2.

Figura 2: As Formas Normais e suas interdependncias.

As formas normais mantm uma relao entre si de tal sorte que a 2FN, a exemplo, se apia sobre a 1FN, ou ento que implica a 1FN, a 3FN implica a 2FN, e assim sucessivamente. As regras das trs primeiras formas normais so as seguintes: 1 Forma Normal (1FN) - Para que uma tabela obedea 1FN, no deve possuir atributos multivalorados, to pouco tabelas aninhadas. O simples fato dos dados estarem dentro de uma tabela relacional com uma chave primria j garante a conformidade com a 1FN. Algumas tcnicas so propostas para decompor uma estrutura aninhada em uma tabela na 1FN, como por exemplo, a gerao de uma tabela para cada nvel de aninhamento, ou a gerao 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 no houver dependncias funcionais parciais; 3 Forma Normal (3FN) - Uma tabela est na 3FN se, e somente se, estiver na 2FN e todo atributo no-chave depende funcionalmente diretamente da chave primria, ou seja, no h dependncias entre atributos no chave.

As demais formas normais esto fora do escopo deste trabalho, porque exigem anlises mais complexas de dependncias funcionais, cujo tempo de processamento pode no justificar o benefcio, em tabelas com muitos registros. Alm disso, a ocorrncia destas formais normais muito mais rara na prtica. A Tabela LOCALIDADES apresenta um exemplo de atributo multivalorado no campo MUNICIPIOS, que no permitido segundo a 1FN. Aps a aplicao da 1FN, a tabela LOCALIDADES decomposta em duas novas tabelas: UFS e MUNICIPIOS. Todos os atributos originais de LOCALIDADES so 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 no se perca o relacionamento entre UF e MUNICIPIOS, o atributo ID_UF migra tambm para MUNICIPIOS, preservando uma propriedade fundamental da normalizao: a capacidade de se desfazer todas as decomposies 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.

ID 1 2 3

UFS 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 eliminao 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 compem a chave primria, 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. ATUACOES NOME BRAD PITT JULIA ROBERTS NATALIE PORTMAN ANTONIO BANDERAS LUCY LIU CLAIRE FORLANI

ID_FILME 1 1 2 3 4 5

ID_ATOR 1 2 3 4 5 6

PERSONAGEM RUSTY RYAN TESS OCEAN ALICE CARLOS RUEDA ALEX MUNDAY SUSAN PARRISH

Tabela 10: Exemplo de Dependncia 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 aplicao 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 aplicao 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 no faz parte da chave, esta DF denominada INDIRETA ou TRANSITIVA, ou seja, ocorre apenas entre atributos no-chave. Para obedecer 3FN, o atributo SALARIO migrado para a nova tabela CATEGORIAS, levando junto o atributo CATEGORIA, mantendo assim o relacionamento existente. VENCIMENTOS NOME CATEGORIA JOAO OPERAO MARCOS OPERAO ANA SECRETARIA JULIA SECRETARIA VITOR ADMINISTRAO ANGELA ADMINISTRAO

ID_FUNCIONARIO 1 1 2 3 4 5

SALARIO 600,00 600,00 450,00 450,00 1000,00 1000,00

Tabela 13: Exemplo de Dependncia Funcional Transitiva ou Indireta.

FUNCIONARIOS ID_FUNCIONARIO NOME CATEGORIA 1 JOAO OPERAO 1 MARCOS OPERAO 2 ANA SECRETARIA 3 JULIA SECRETARIA 4 VITOR ADMINISTRAO 5 ANGELA ADMINISTRAO
Tabela 14: Resultado da aplicao da 3FN.

CATEGORIAS NOME SALARIO OPERADOR 600,00 SECRETARIA 450,00 ADMINISTRADOR 1000,00


Tabela 15: Resultado da aplicao da 3FN.

TRABALHOS RELACIONADOS Os trabalhos que mais se aproximam do trabalho aqui proposto esto

relacionados com a automatizao 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 fsicos, esquemas, anlise de dependncias funcionais, cdigo fonte da aplicao, SQL e os prprios dados. No entanto, no h abordagem que se proponha a normalizar um conjunto de dados utilizando apenas a anlise dos mesmos e dispensando o conhecimento sobre o seu domnio. Isto se deve, em parte, porque a normalizao apenas uma etapa do processo de engenharia reversa e raramente abordada fora deste escopo. 3.1 A Independncia Funcional na Normalizao de Bancos de Dados Relacionais. Este trabalho aponta deficincias na definio das formas normais baseadas em dependncias funcionais e apresenta uma abordagem complementar ao processo tradicional de normalizao, introduzindo o conceito de independncia funcional, melhorando sensivelmente o resultado da normalizao [9]. Segundo o trabalho, a observncia das dependncias funcionais no suficiente para eliminar algumas formas bsicas de redundncia, resultando em anomalias nos dados mesmo em altos nveis de normalizao. Para eliminar anomalias causadas pelas dependncias funcionais de subdomnio, o artigo introduz o conceito de independncia funcional, que acontece quando a combinao de todos os valores entre dois atributos vlida, ou seja, no fere nenhuma restrio semntica. 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 Independncia Funcional.

A Tabela 16 apresenta dois campos funcionalmente independentes, ou CORRENTISTA >< SALDO, pela notao formal, porque no h restries para as combinaes de valores que os campos podem assumir. O exemplo de independncia funcional, dado na Tabela 16, s vlido quando acrescido de informaes externas, como o fato de que um correntista pode ter qualquer valor em seu saldo. No entanto, regras simples de negcio podem invalidar o exemplo, como considerar que correntistas com menos de um ano de conta tm limite mximo de R$ 200,00. Por esse motivo, as independncias funcionais no so determinadas pela combinao exaustiva dos atributos, mas pela consulta semntica dos mesmos, tornando-as altamente dependentes do domnio dos dados. Por fim, o trabalho utiliza o conceito de independncia funcional para definir a Forma Normal da Independncia 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 ausncia de redundncias causadas por dependncias funcionais de subdomnio e outras formas de relacionamento entre atributos. A FNBC exige que todos os atributos funcionalmente determinantes faam parte da chave primria. Esta proposta contribuiu para este trabalho com a teoria de independncia funcional e a forma normal FINF.

3.2

Engenharia Reversa de Bancos de Dados Relacionais: Algoritmos para Extrair Restries de Cardinalidade. Este trabalho trata da extrao de cardinalidades via comandos SQL, gerados

dinamicamente sobre um dicionrio 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 integrao de ferramentas comerciais que oferecem engenharia reversa de bancos de dados. A motivao est na complexidade do processo de engenharia reversa, cujas abordagens exigem a satisfao de uma srie extensa e complexa de requisitos, impedindo a automatizao, bem como na falta de abordagens que utilizem os prprios dados para dar mais consistncia ao esquema extrado. A anlise dos dados armazenados em um banco ou fonte de dados traz informaes muito mais realistas a respeito das entidades ali persistidas do que o cdigo fonte da aplicao e a descrio dos dados sozinhos. Todavia, as ferramentas que oferecem engenharia reversa ignoram os dados, tomando como entrada apenas dicionrios de dados ou descries do esquema relacional. Incluir a anlise dos dados no processo, como prope o trabalho, possibilita a identificao precisa das cardinalidades existentes entre as entidades. A preciso desta informao que separa processos de engenharia reversa em bem ou mal sucedidos. Quando as definies de entidades incluem as chaves primrias e estrangeiras no nvel relacional, a ferramenta efetua a engenharia reversa automaticamente. Caso contrrio, o usurio deve indicar manualmente os campos-

alvo a serem analisados pela ferramenta e refazer o processo at obter um resultado que julgue satisfatrio. O trabalho analisa as diferenas entre os modelos baseados em restries de cardinalidades (MER), como o ER, e os modelos baseados em restries de pertinncia (MPC), como MERISE, ECR, ERC+, OMT e ODMG. A Tabela 17 apresenta as diferenas entre as notaes MER e MPC. Notao MER MPC 1:1 n:m 1:n n:m [1:1]:[1:1] [0:n]:[2:4] [1:1]:[0:n] [0:n]:[1:n]

Relacionamento Aluno VS Matrcula Banca VS Professores Aluno VS Email Aluno VS Turma

Descrio Um aluno tem apenas uma matrcula, e uma matrcula 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
Tabela 17: Notao MER VS Notao MPC

A identificao e representao adequada das cardinalidades, apresentada neste trabalho, deu origem ao mdulo de anlise preliminar, haja vista a importncia que essa informao tem para o processo de normalizao. 3.3 Extraindo o Diagrama ER de Bancos de Dados Legados. Este trabalho prope um processo de extrao de um diagrama ER de um banco de dados no relacional, com pouca informao sobre os campos e nenhuma informao sobre as chaves, analisando os prprios dados armazenados e telas de formulrio do sistema que alimenta o banco [10]. A motivao reside na presuno

de disponibilidade de todas essas informaes para se iniciar um processo de engenharia reversa, o que raramente acontece. Ao final, um estudo de caso apresentado. A semntica dos dados descoberta atravs do preenchimento dos formulrios do sistema e anlise do posterior armazenamento das informaes de entrada no banco de dados. Para automatizar o procedimento de anlise e extrao, so criadas tabelas no SQL Server para armazenar informaes sobre formulrios, campos de formulrios, tabelas e campos de tabelas do sistema. As chaves so inferidas pela anlise de arquivos de ndices ou, para tabelas sem arquivo de ndices, a eleio de chaves feita atravs da anlise direta dos dados da tabela a procura de campos, ou combinaes de campos, cujos valores no se repitam. Em seguida, todas as tabelas so percorridas para se descobrir quais delas fazem referncia s chaves primrias definidas na etapa anterior, descobrindo assim as chaves estrangeiras. As cardinalidades entre as chaves primrias e estrangeiras so obtidas pela contagem do nmero de valores distintos de cada chave estrangeira para uma chave primria. Grande parte das pesquisas nesta rea de extrao de esquemas conceituais de dados baseia-se na utilizao do esquema relacional como entrada principal. No entanto, a manuteno de um banco de dados depende do conhecimento que se tem sobre suas caractersticas. A semntica de seus atributos vital para a compreenso do funcionamento do sistema, e geralmente pobre ou at mesmo inexistente, justificando abordagens como esta, que utilizam a anlise dos formulrios do sistema para ajudar na reconstruo de esquemas ER.

Este trabalho deu origem ao mdulo de eleio de chave primria, que prrequisito da normalizao. 3.4 Consideraes Finais Estes trabalhos contriburam para o amadurecimento geral da ferramenta, alm dos conceitos especificados na anlise de cada um. No entanto, este trabalho se diferencia das abordagens apresentadas ao propor uma ferramenta de apoio normalizao que utiliza apenas os dados como entrada, dos quais extrai as informaes necessrias para efetuar grande parte da normalizao

automaticamente. Outro aspecto a disponibilizao de uma interface com o usurio dotada de recursos para apresentar a teoria envolvida em todo o processo de normalizao, distribuindo-a em mdulos e passos.

A FERRAMENTA A ferramenta proposta neste trabalho tem por objetivo apoiar o processo de

normalizao de tabelas at a 3FN, reduzindo a necessidade de conhecimento terico a respeito da normalizao e conhecimento sobre o domnio dos dados, alm de explicar a teoria envolvida em cada parte do processo. A figura abaixo oferece uma viso 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 so importados para uma nica tabela relacional no normalizada, que servir de base para todo o resto do processo. A aplicao das formas normais exige a existncia de uma chave primria. Para auxiliar o usurio na definio dessa chave, a ferramenta analisa os dados e calcula o potencial que cada campo tem para exercer essa funo. Em seguida,

apresenta uma lista de campos de maior potencial, com os quais o usurio deve compor a chave primria. Definida a chave primria, o usurio pode ento aplicar as formas normais. Nesta etapa, a tabela sofre a aplicao de cada uma das formas normais em passos separados, nos quais a ferramenta identifica, classifica e remove cada dependncia funcional encontrada, alm de apresentar a teoria relacionada a cada uma delas #detalhes no mdulo#. Ao trmino do processo, so apresentadas as tabelas resultantes da normalizao, juntamente com relatrios sobre tempos de execuo de cada tarefa e a diferena entre o espao utilizado pelos dados antes e depois da normalizao. As principais funcionalidades da ferramenta esto divididas em mdulos, e sero explicadas minuciosamente mais adiante. 4.2 Tecnologias Utilizadas A plataforma da aplicao toda em SQL ANSI, constituda de tabelas responsveis por manter os dados resultantes das anlises e stored procedures que encapsulam os algoritmos de cada tarefa utilizada pela ferramenta. A padronizao 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 acadmico e, principalmente, oferecer suporte execuo dinmica de SQL. A interface grfica foi desenvolvida utilizando-se a verso 5.5.1 do Netbeans, uma IDE para a linguagem Java.

4.3

Mdulos 4.3.1 Mdulo de Importao Este mdulo extrai os dados de um arquivo de texto ou XML e insere em uma

tabela. Para arquivos de texto, o usurio define os critrios (caracteres) que sero utilizados para quebrar os registros em linhas e colunas. Para arquivos XML, o mecanismo de importao ainda no foi definido. Os campos da tabela de destino so definidos como literais, uma vez que no 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 prottipo da tela deste modulo.

Figura 4: Mdulo de Importao.

4.3.2 Mdulo de Anlise Preliminar Este mdulo explora cada campo da tabela, extraindo as informaes que sero utilizadas pelos mdulos seguintes, e est dividido da seguinte forma: Bsica: Extrai o nmero de valores distintos, nmero mnimo e mximo de caracteres, e classifica o campo em numrico ou literal; Avanada: Aplica as estatsticas selecionadas pelo usurio, como valor mximo, mnimo, mdia e desvio padro, alm de estatsticas definidas pelo prprio usurio; Armazenamento: Calcula o espao (total e mdio por registro) ocupado pelos dados. As anlises so feitas atravs de consultas aos prprios dados, utilizando comandos em SQL. A maior parte desses comandos montada dinamicamente, com base no dicionrio de dados do MySQL. As informaes coletadas so armazenadas em tabelas auxiliares, que so utilizadas durante todo o resto do processo. A figura 7 apresenta o prottipo da tela deste modulo.

Figura 5: Mdulo de Anlise Preliminar

4.3.3 Mdulo de Ajuste Utiliza as informaes extradas durante a anlise preliminar para redefinir os tipos dos campos da tabela, que foram definidos genericamente como literais, quando da importao. Permite tambm a remoo de registros indesejados, revelados pela anlise preliminar. 4.3.4 Mdulo de Eleio de Chave Primria Utilizando as informaes coletadas pelo mdulo de anlise preliminar, calcula o potencial que cada campo tem para ser a chave primria. Este potencial obtido dividindo-se o nmero de valores distintos do campo pelo nmero 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 usurio possa eleger a chave primria. A priori, apenas campos com potencial igual a 100% poderiam ser selecionados, uma vez que chaves primrias no aceitam valores repetidos. No entanto, possvel selecionar campos com potencial inferior a 100%, desde que o usurio 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 aps a eleio da chave primria. possvel solicitar o clculo do potencial para combinaes de campos, permitindo a definio de chaves primrias compostas. O usurio ainda pode rejeitar os candidatos apresentados e optar por uma chave primria artificial. Nesta ltima opo, a ferramenta define o campo ID, gerado quando da importao dos dados, como chave primria. Ao trmino da eleio, a ferramenta define o(s) campo(s) como chave primria diretamente na tabela atual. Se o usurio optar por campo(s) de potencial inferior a 100%, a ferramenta cria uma tabela secundria, define a chave primria, carrega os dados da tabela original e, ao trmino, informa quantos registros foram inseridos e ignorados. Ainda no h prottipo de tela para este mdulo. 4.3.5 Mdulo de Normalizao Observa os relacionamentos entre os dados e apresenta ao usurio as informaes coletadas, guiando-o atravs de aplicao de cada uma das formas normais. A anlise dos relacionamentos feita atravs da execuo de comandos

SQL sobre os prprios dados, capazes de detectar a existncia de DFs entre os campos da tabela. A Tabela 15 apresenta um exemplo geral de DF, onde ocorre NOME SIGLA. Na prtica, 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
Tabela 18: Exemplo geral de DF.

SIGLA AC AC CRF CRF GLP GNV IR RAIS

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 : Mensurao do relacionamento entre dois campos

O primeiro comando recupera o nmero de valores distintos do campo NOME, que 8, e armazena na varivel @distinct_NOME. O segundo comando tambm recupera o nmero de valores distintos do campo NOME, mas com a condio de se relacionar com apenas um valor de SIGLA em todos os registros, que 8 tambm, e divide pela varivel @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, no sendo possvel inferir a DF entre essas duas variveis com segurana. Este processo de mensurao aplicado ao conjunto de arranjos simples entre os campos da tabela, tomados dois a dois, e os resultados so armazenados. O nmero de combinaes possveis pode ser calculado por n! / (n-2)!, onde n o nmero de campos da tabela. Aps o trmino 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 anlise de relacionamentos. RELACIONAMENTOS NOME SIGLA SIGLA NOME DF 100% 66%

Tabela 19: Resultado da anlise de relacionamentos.

Para evitar que a deteco de dependncias funcionais seja prejudicada por valores nulos, corrompidos, ou at mesmo invlidos, a ferramenta oferece a opo de inspecionar os relacionamentos atravs da visualizao de amostras dos registros. Para freqncias iguais a 100%, a ferramenta automaticamente infere a existncia de uma DF, e para as freqncias inferiores, mostra alguns dos registros onde a possvel DF foi ferida. Desse modo, o usurio sabe se a deteco de DFs foi prejudicada por erros nos dados, e tem a opo de corrigi-los.

Para cada DF aceita pelo usurio, a ferramenta efetua a decomposio correspondente e apresenta as tabelas derivadas.

Uma caracterstica particular desta ferramenta so os algoritmos para descoberta de dependncias 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 normalizao de arquivos de forma individual, no oferecendo suporte integrao dos modelos gerados a partir de cada arquivo. A interface com o usurio disponibilizada apenas para possibilitar a utilizao destes algoritmos no meio acadmico, pois se espera que esta ferramenta tenha utilidade no ensino de Normalizao em disciplinas de Banco de Dados. Este mdulo s se torna acessvel aps a definio da chave primria, que pr-requisito para a normalizao.

ATIVIDADES FUTURAS Definir a metodologia de importao para arquivos XML; Definir o mdulo de normalizao; Definir o mdulo de Relatrios; Finalizar a implementao 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 edio. Srie Livros Didticos Instituto de Informtica da UFRGS, nmero 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 edio. 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 modeltoward 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. Introduo a Sistemas de Bancos de Dados. 8a edio. 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.