Você está na página 1de 9
ITA - Instituto Tecnol ógico de Aeronáutica IEC - Divisão de Ciência da Computação Curso

ITA - Instituto Tecnológico de Aeronáutica

IEC - Divisão de Ciência da Computação Curso de Pós-Graduação em Computação

Projeto de Sistema de Bancos de Dados

Prof. Dr. Adilson Marques da Cunha

(Listex 3)

por

Claudiney Calixto da Silva

ccalixto@comp.ita.br

São José dos Campos

2003

ÍNDICE

1 INTRODUÇÃO

3

1.1

TÍTULO

3

1.2

MOTIVAÇÃO

3

1.3

OBJETIVO

3

2 CONTEÚDO

3

2.1

NORMALIZAÇÃO

3

2.1.1 Forma não Normalizada – 0 FN

4

2.1.2 Primeira Forma Normal – 1 FN

4

2.1.3 Segunda Forma Normal – 2 FN

5

2.1.4 Terceira Forma Normal – 3 FN

5

2.2

TRIGRAMAÇÃO

6

2.3

MODELO CONCEITUAL (NOTAÇÃO ORACLE)

7

2.4

CRIAÇÃO DO PROTÓTIPO NO INTERBASE

7

2.5

INCLUSÃO DA MASSA DE DADOS

8

3 CONCLUSÃO

9

1 Introdução

1.1 Título

Aplicativo de Banco de Dados para Gerência da Execução de Missões da HITS -

1.2 Motivação

ABD-GEMH

Neste trabalho tem-se a oportunidade de praticar a técnica de normalização

de banco de dados, levando a Terceira Forma Normal – 3 FN o protótipo de

aplicativo de banco de dados do autor desta lista exercícios.

1.3 Objetivo

Desenvolver a Versão 1.0 de um Protótipo de Aplicativo de Banco de

Dados (BD) na Terceira Forma Normal (3FN) no contexto da sua temática já

definida na aula anterior, visando melhorar os tempos de acesso, em termos de

armazenamento e recuperação de Informações, e reduzir as anomalias de

atualizações e inconsistências.

2 Conteúdo

2.1 Normalização

Nessa etapa, será aplicada a Técnica de Normalização, para levar o

Protótipo de Aplicativo de Banco de Dados do autor desta Listex, da Forma não

Normalizada (0 FN) até a Terceira Formal Normal (3 FN).

A

cada

passo

serão

fornecidas

explicações

referentes

as

alterações

efetuadas no aplicativo, porém vale lembrar que, não cabe ao objetivo deste

documento detalhar o funcionamento das regras e técnicas utilizadas, para isso,

recomenda-se que sejam acessadas as notas de aula do curso “Projeto de

Sistema de Banco de Dados”, disponível no seguinte site:

http://www.comp.ita.br/~cunha/ensino/2003/ce240/index.html.

2.1.1

Forma não Normalizada – 0 FN

Na Tabela 1, estão representadas as primeiras entidades criadas no

Protótipo, vale lembrar que elas encontram-se não normalizadas, pois pode-se

notar que existem atributos não atômicos, isto é, que são divisíveis.

MISSAO {id_missao, id_ponto, veiculo, periodo, nome_ponto, coord_xy, area, velmax, status, datahora, velmed} HISTORICO {id_historico, id_missao, assunto, mensagem, datahora, funcionario, tipo}

Tabela 1 – Relações na 0 FN

2.1.2 Primeira Forma Normal – 1 FN

Na Tabela 2 é feita a representação das relações apresentadas na Tabela 1,

porém já normalizadas na 1 FN. Note que o atributo periodo da relação MISSAO

foi substituído por inicio e termino. E o atributo coord_xy, trocado por coord_x e

coord_y.

MISSAO {id_missao, id_ponto, veiculo, inicio, termino, nome_ponto, coord_x, coord_y, area, velmax, status, datahora, velmed} HISTORICO {id_historico, id_missao, assunto, mensagem, datahora, funcionario, tipo}

Tabela 2 – Relações na 1 FN

Obs.: O atributo periodo tinha a responsabilidade de armazenar as datas

de início e término de uma Missão, caracterizando-se dessa forma como um

atributo divisível, da mesma forma que o coord_xy.

2.1.3 Segunda Forma Normal – 2 FN

A 1 FN demonstrada na Tabela 2 apresenta uma anomalia de exclusão, pois

caso se deseje remover uma Missão específica, será preciso deletar várias tuplas,

já que cada possível ponto registrado na entidade trás informações referentes a

Missão.

Para eliminar tal anomalia foi aplicada a 2 FN, representada na Tabela 3,

note que para tal normalização foi-se necessário criar a relação PONTO, e

transferir a ela, os atributos que antes estavam contidos em MISSAO, que por sua

vez não eram dependentes da chave primária.

MISSAO {id_missao, veiculo, inicio, termino} PONTO {id_ponto, id_missao, nome, coord_x, coord_y, area, velmax, status, datahora, velmed} HISTORICO {id_historico, id_missao, assunto, mensagem, datahora, funcionario, tipo}

Tabela 3 – Relações na 2 FN

2.1.4 Terceira Forma Normal – 3 FN

Na 2 FN temos uma anomalia de atualização, onde caso se deseje alterar

um dado de determinada Área (area, velmax, status), contida na relação PONTO,

é preciso percorrer todos os registros da Entidade que se referem a mesma.

Para solucionar esta anomalia aplicou-se as relações na 3 FN, onde que

para se chegar a mesma foi preciso eliminar todas dependências transitivas, isto

é, quando um atributo, além de depender da chave primária, depende também de

um ou mais outros atributos da respectiva relação.

Para

isso,

foi-se

necessário

criar

as

demonstradas na Tabela 4.

relações

AREA

e

TRAJETO,

MISSAO {id_missao, veiculo, inicio, termino} HISTORICO {id_historico, id_missao, assunto, mensagem, datahora, funcionario, tipo} AREA {id_area, nome, velmax, status} PONTO {id_ponto, id_area, nome, coord_x, coord_y} TRAJETO {id_trajeto, id_ponto, id_missao, datahora, velmed}

Tabela 4 – Relações na 3 FN

2.2 Trigramação

A Tabela 5, demonstra o resultado final da Trigramação aplicada nas

relações obtidas após a normalização até a 3 FN. Vale lembrar que para a

aplicação desta técnica foi adotado as 3 primeiras letras do nome de cada

entidade.

MISSAO {mis_id, vei_id, mis_inicio, mis_termino} HISTORICO {his_id, mis_id, his_assunto, his_mensagem, his_datahora, his_tipo, fun_id} AREA {are_id, are_nome, are_velmax, are_status} PONTO {pon_id, are_id, pon_nome, pon_coord_x, pon_coord_y} TRAJETO {tra_id, pon_id, mis_id, tra_datahora, tra_velmed}

Tabela 5 – Relações devidamente Trigramadas

Obs.: Em MISSAO, o atributo vei_id simboliza uma referência para uma

possível relação denomiada VEICULO, assim como o fun_id em HISTORICO,

aponta para uma outra relação FUNCIONARIO. Vale lembrar que as relações

VEICULO e FUNCIONARIO não foram criadas neste protótipo por serem parte do

escopo

do

trabalho

de

outros

alunos,

integrados a este aplicativo.

que

no

decorrer

deste

curso

serão

2.3 Modelo Conceitual (Notação Oracle)

A Figura 1 faz a representação do Modelo Conceitual do Protótipo de

Aplicativo de Banco de Dados do autor dessa Lista, segundo a Notação Oracle.

MISSAO TRAJETO PONTO pertence passar por # * mis_id # * tra_id # * pon_id
MISSAO
TRAJETO
PONTO
pertence
passar por
#
* mis_id
# * tra_id
#
* pon_id
*
vei_id
possuir
*
tra_datahora
ser visitado
* pon_nome
o
mis_inicio
o
tra_velmed
* pon_coord_x
o
mis_termino
* pon_coord_y

ter

ser de

compor

ser composta

* pon_coord_y t e r ser de compor ser composta HISTORICO AREA # * his_id #

HISTORICO

AREA

# * his_id

#

*

are_id

o his_assunto

o

are_nome

* his_mensagem

o

are_velmax

* his_datahora

*

are_status

his_tipo * fun_id

*

Figura 1 – Modelo Conceitual (Notação Oracle)

2.4 Criação do Protótipo no Interbase

Por meio da Ferramenta ERWIN, foi-se gerada automaticamente as linhas

de código SQL (clique aqui para visualizá-las), cuja as mesmas foram utilizadas

para criação das Tabelas ou Entidades do Protótipo de Aplicativo de Banco de

Dados do autor dessa lista no Banco de Dados INTERBASE.

Vale lembrar que os códigos SQL foram gerados a partir de um Modelo

Conceitual, como o descrito na Seção 2.3, porém não faz parte do escopo desse

trabalho demonstrar a utilização das Ferramentas ERWIN e INTERBASE.

2.5

Inclusão da Massa de Dados

Para validação das Tabelas criadas no Interbase, foram incluídos alguns

registros nas mesmas, conforme demonstrado nas Figuras 1 e 2, onde a primeira

exibe as linhas SQL para inserção e a segunda o resultado.

exibe as linhas SQL para inserção e a segunda o resultado. Figura 2 - Interface para

Figura 2 - Interface para execução de SQL do Interbase

E como resultado temos:

para execução de SQL do Interbase E como resultado temos: Figura 3 – Interface representando os

Figura 3 – Interface representando os dados inseridos em MISSAO

Para as demais Tabelas, também foram incluídos registros a partir de linhas

SQL, para fazer o download das mesmas clique aqui.

3

Conclusão

Pôde-se chegar à conclusão com a execução dessa Listex, que a utilização

da Técnica de Normalização pode contribuir, por exemplo, para a diminuição de

anomalias e inconsistências e aumentar a velocidade no acesso aos dados

armazenados.