Lista de Exercícios 5 (ListEx 5)

CE-240 Projeto de Sistema de BD

Prof. Dr. Adilson Marques da Cunha

Título: Integração de Aplicativos de BD num Banco de Dados

Setorial (BDS) e sua Implementação

 

1. - Objetivos:

 

1) Integrar Aplicativos de BD nos Bancos de Dados Setoriais – BDS ou Subject Databases das Empresas ALC e HALS escolhidas como Estudo de Caso, visando a melhorar as suas eficiências setoriais e a reduzir os seus desperdícios de recursos; e

2) Implementar a integração de Aplicativos de BD nos Bancos de Dados Setoriais - BDS ou Subject Databases das Empresas ALC e HALS, visando testar as funcionalidades de suas integrações setoriais debaixo de um SGBD previamente escolhido, e verificar a melhoria das suas eficiências setoriais e a redução dos desperdícios de seus recursos.

 

2. – Descrição dos principais passos:

 

O Normalizador deverá exercer, sempre que forem necessárias, as funções de organizar, padronizar, documentar, normalizar, renormalizar e manter atualizados: os Modelos Conceituais ou Modelos Entidades Relacionamentos (MER); os Modelos de Dados Setoriais - MDS ou Subject Data Model – SDM; e as suas cardinalidades, mantendo o número de atributos por Entidade menor ou igual a sete. Exceções só poderão ser abertas com a autorização do Professor;

 

ü      PRIMEIRA FORMA NORMAL (1FN)

 

Diz-se, por definição, que uma Relação está na 1FN, quando todos os seus registros possuem o mesmo conjunto de atributos, e esses atributos são atômicos, isto é, são itens indivisíveis.

 

CLIENTE {cli_id, cli_nome, cli_endereco, cli_site, cli_telefone, cli_dtcadastro, cli_numsol, cli_soldata, cli_soldescricao, cli_solprazo}

 

PEDIDO{ped_id, ped_dat, cli_id, cli_nome, ped_endereco, ped_datentrega, ped_endentrega, ped_vlr, ped_cidentrega, ped_ufentrega}

ITEM_PEDIDO {ped_id, serv_id, carga_id, serv_nome, carga_nome, ped_cidorigem, ped_ciddestino, ped_vlr, cidorigem_id, ciddestino_id}

 

EXCLUSAO_GRUPO {exc_id, par_id, cid_id, par_nome, par_endereco}

 

INCLUSAO_GRUPO {inc_id, par_id, cid_id, par_nome, par_endereco}

 

CIDADE {cid_id, uf_id, cid_nome}

 

Algumas tuplas agora se constituem de mais de um atributo chave, sendo necessária a combinação de todos para identificar o registro.

 

Diz-se então que estas tuplas encontram-se na primeira forma normal (1FN), mas ainda contém algumas características funcionais que podem ocasionar dificuldades na utilização.

 

Estas tuplas na 1FN contém Anomalias de Atualização e de Inclusão. Por exemplo, se quisermos atualizar as cidades de atendimento ou não de determinado parceiro, nós deveremos que atualizá-lo em várias tuplas, correndo o risco de gerar inconsistência no BD. Ao mesmo tempo, se quisermos inserir determinado cliente (novo), deveremos inseri-lo no BD, em diversos momentos gerando re-trabalho.

 

ü      SEGUNDA FORMA NORMAL (2FN)

 

Por definição, a Segunda Forma Normal (2FN) requer que todos os atributos não chave devem conter informações, que se referem à chave inteira, e não somente à parte do registro.

 

CLIENTE {cli_id, cli_nome, cli_endereco, cli_site, cli_telefone, cli_dtcadastro}

 

SOLICITACAO {cli_id, sol_num, sol_data, sol_descricao, sol_prazo}

 

CONTATO {con_id, con_nome, con_telefone, con_email, con_dep, car_id, con_cargo, cli_id}

 

ORDEM_SERVICO {os_id, orc_id, orc_valor, cli_id, cli_endereco, os_origem,  os_destino, os_dataentrega}

 

PEDIDO{ped_id, ped_dataentrega, cli_id, cli_nome, ped_endereco, ped_endentrega, ped_vlr, cidentrega, ufentrega}

ITEM_PEDIDO {ped_id, serv_id, car_id, cidorigem, ciddestino, ped_vlr}

SERVICO {serv_id, serv_nome}

CARGA {car_id, car_nome}

PARCEIRO {par_id, par_telefone, par_contato, par_endereco, par_nome, cid_id}

 

EXCLUSAO_GRUPO {exc_id, par_id, cid_id, par_nome, par_endereco}

 

INCLUSAO_GRUPO {inc_id, par_id, cid_id, par_nome, par_endereco}

 

CIDADE {cid_id, uf_id, cid_nome}

 

 

Ainda, as mesmas anomalias de atualização, inclusão e exclusão podem ser encontradas na 2FN por haver duplicação de informações em diversas partes do BD, como é o caso de par_nome, par_endereco e cli_endereco.

 

ü      TERCEIRA FORMA NORMAL (3FN)

 

Por definição, a Terceira Forma Normal (3FN) refere-se ao agrupamento de Relações requeridas na 2FN, com cada atributo não chave referindo-se diretamente a chave.

 

 

CLIENTE {cli_id, cli_nome, cli_endereco, cli_site, cli_telefone, cli_cidade, cli_dtcadastro}

 

CONTATO {con_id, con_nome, con_telefone, con_email, dep_id, car_id, cli_id}

 

CARGO {car_id, car_descr}

 

DEPTO {dep_id, dep_descr}

 

SOLICITACAO {sol_id, cli_id, sol_data, sol_descr, sol_prazo}

 

ORDEM_SERVICO {or_id, ite_id, par_id}

 

PEDIDO {ped_id, cli_id, ped_dataped, ped_endereco, ped_valor, ped_status, ped_nf}

 

ITEM_PEDIDO {ite_id, ser_id, car_id, fre_id, ped_id, ite_valor, ite_mobra, ite_gastosindiretos}

 

CARGA {car_id, car_nome}

 

SERVICO {ser_id, ser_nome}

 

FRETE {fre_id, fre_valor, cid_idorigem, cid_iddestino}

 

PARCEIRO {par_id, par_telefone, par_contato, par_endereco, par_nome}

 

EXCLUSAO_GRUPO {exc_id, par_id, cid_id}

 

INCLUSAO_GRUPO {inc_id, par_id, cid_id}

 

CIDADE {cid_id, uf_id, cid_nome}

 

UF {uf_id, uf_sigla}

 

 

MER – MODELO ENTIDADE RELACIONAMENTO

 

DICIONARIZAÇÃO (Rafael Segura)

 

Dicionário de Dados

Diretório de Recursos de dados 

Diretório de Dados

Diretório de Metadados

 

INTEGRAÇÃO (Oiram Santos)

 

MANUAIS (Eliane Ramos)

 

PLANOS DE EMERGÊNCIA (Eliane Ramos)

 

 

Quanto a Implementação da integração de Aplicativos de BD nos Bancos de Dados Setoriais - BDS ou Subject Databases da ALC e da HALS – Cada integrante de um BDS deverá:

(a) Checar as implementações realizadas pelos demais integrantes do seu grupo na Lista de Exercícios anterior (ListEx 4), verificando e testando se as 03 (três) consultas (queries) desenvolvidas, envolvendo 1, 2 e 3 relações dos Aplicativos de Banco de Dados são aceitáveis para o seu BDS.

 

1ª CONSULTA – Aceitável

A Primeira Consulta deverá ser considerada como aceitável, se envolver uma relação e pelo menos um comando Select e um Project (ou equivalentes).

Foi realizado o seguinte comando em SQL:

 

SELECT ped_endereco

from PEDIDO

 

Obtivemos o resultado a seguir:

 

 

2ª CONSULTA - Aceitável

A Segunda Consulta deverá ser considerada como aceitável, se envolver duas relações e pelo menos um Select, um Project e um Join (ou equivalentes).

Foi realizado o seguinte comando em SQL:

 

select ped_valor

from PEDIDO, CLIENTE

where CLIENTE.cli_nome='Shell';

 

Obtivemos o resultado a seguir:

 

 

3ª CONSULTA - Aceitável

E a Terceira Consulta deverá ser considerada como aceitável, se envolver três relações e pelo menos um Select, um Project e um Join (ou equivalentes).

Foi realizado o seguinte comando em SQL:

 

select DISTINCT ped_id

from PEDIDO, FRETE, ITEM_PEDIDO

where FRETE.fre_valor>1500 and ite_valor>1500;

 

 

Obtivemos o resultado a seguir:

 

 

(b) Implementar 03 (três) consultas (queries) adicionais como parte do seu Aplicativo de Banco de Dados, devidamente integrado no seu BDS.

 

4ª CONSULTA - Aceitável

A Quarta Consulta, deverá ser formulada e implementada no nível de decisão tático, envolvendo, simultaneamente, pelo menos 01 (uma) relação do seu Aplicativo de Banco de Dados e 02 (duas) relações de um Aplicativo de Banco de Dados diferente, mas que esteja debaixo do seu Banco de Dados Setorial (BDS) de Nível 1 ou Subject Database Level 1.

Foi realizado o seguinte comando em SQL:

 

SELECT par_nome

from PARCEIRO, ITEM_PEDIDO,PEDIDO

where ped_valor>500 and ite_valor>1000;

 

Obtivemos o resultado a seguir:

 

 

 

5ª CONSULTA - Aceitável

A Quinta Consulta, deverá ser também formulada e implementada no nível de decisão tático, envolvendo, simultaneamente uma relação do seu Aplicativo de Banco de Dados e 02 (duas) relações de 02 (dois) Aplicativos de Banco de Dados diferentes, que estejam debaixo do seu Banco de Dados Setorial (BDS) de Nível 1 ou Subject Database Level 1.

Foi realizado o seguinte comando em SQL:

 

select DISTINCT par_nome

from ORDEM_SERVICO, PARCEIRO, ITEM_PEDIDO

where ITEM_PEDIDO.ite_valor>5000;

 

Obtivemos o resultado a seguir:

 

A Sexta Consulta, deverá ser também formulada e implementada no nível de decisão tático, envolvendo, simultaneamente uma relação do seu Aplicativo de Banco de Dados e 02 (duas) relações de 02 (dois) Aplicativos de Banco de Dados diferentes, que estejam debaixo do seu Banco de Dados Setorial BDS de Nível 2 ou Subject Database Level 2.

Para realizar esta consulta, tivemos que integrar os grupos GAD, GAR e GFI, atualizando o MER, criando novas tabelas e relacionamentos. Em seguida, fizemos a população das tabelas e a realização da consulta.

Foi realizado o seguinte comando em SQL:

 

select est_id

from INCLUSAO_GRUPO, ARMAZEM, ESTOQUE

where INCLUSAO_GRUPO.loc_id_origem = ARMAZEM.loc_id;

 

Obtivemos o resultado a seguir:

 

3. – Conclusões:

 

Durante a integração dos Aplicativos de Banco de Dados, constatamos algumas anomalias que foram eliminadas, retirando-se ou acrescendando-se relações e/ou atributos nos Aplicativos, evitando, desta forma, eventuais inconsistências.

 

Para a integração dos aplicativos, utilizamos as ferramentas Interbase e ErWin que fornecerem facilidades para a execução da tarefa.