listex01

LISTEX 4 - CE-240 Projeto de Sistema de BD

Aluna: LUCIANA SANTOS

Título: Implementação de um BD Modelo de Dados Relacional e sua Conversão para os Modelos de Dados Hierárquico, Rede e Orientado a Objetos:

1. – Objetivos do lab:

1) Implementar a Terceira Forma Normal (3ªFN) do seu Protótipo de Aplicativo de Banco de Dados (BD) utilizando um Modelo de Dados Relacional em um Sistema Gerenciador de Banco de Dados (SGBD) previamente escolhido e testar a sua funcionalidade, visando reduzir o desperdício de recursos nas futuras fases de integração e melhorar a eficiência operacional dos futuros Bancos de Dados Setoriais (BDS), Bancos de Dados Corporativo (BDC) e do Banco de Dados Holding (BDH); e

2) Pesquisar os Modelos de Dados Hierárquico, Rede e Orientado a Objetos, e Converter a 3ªFN do seu Protótipo de Aplicativo de BD no Modelo de Dados Relacional para os Modelos de Dados Hierárquico, Rede e Orientado a Objetos, visando identificar algumas das suas principais diferenças e características.

2. - Descrição dos Principais Passos realizados no Exercício:

1) Quanto à implementação do Modelo de Dados Relacional, cada aluno deverá:

(a) Implementar e testar a 3ªFN do Modelo de Dados Relacional do seu Protótipo de Aplicativo de BD no SGBD JDATASTORE da BORLAND;

RESOLUÇÃO:

Dada a 3ªFN do Modelo de Dados Relacional do Protótipo de Aplicativo de BD SIS_PAR abaixo:

SI-ALO
Num_localidade	loc_atendimento	loc_naoatendimento

SI-AGI
num_grupodeinteresse	num_parceiro

SI-AGE
num_grupodeexclusao	num_parceiro

SI_PAR
num_parceiro	num_localidade	end_parceiro	nome_parceiro

Utilizando a ferramenta JDATASTORE da BORLAND devidamente instalada e configurada no microcomputador, e utilizando o Tutorial do JDATASTORE das notas de aula do Professor (arquivo: Aula07.2bCes30Ce24004f(Tutorial_1-JDataStore)), o Protótipo de Aplicativo de BD citado foi implementado com o código fonte abaixo, em SQL (Structured Query Language).

create table SI_ALO (

num_localidade int not null,

loc_atendimento varchar (20),

loc_naoatendimento varchar (20),

primary key (num_localidade));

create table SI_AGI (

num_grupodeinteresse int not null,

num_parceiro int,

primary key (num_grupodeinteresse));

create table SI_AGE (

num_grupodeexclusao int not null,

num_parceiro int,

primary key (num_grupodeexclusao));

create table SI_PAR (

num_parceiro int not null,

num_localidade int,

end_parceiro varchar (20),

nome_parceiro varchar (20),

primary key (num_parceiro));

· Feito isso, foi realizada a inserção das chaves estrangeiras com o código fonte abaixo:

alter table SI_PAR add constraint fk1 foreign key (num_localidade) references SI_ALO(num_localidade);

· O próximo passo, com as relações já configuradas, foi a inserção da massa de dados, conforme código fonte abaixo:

insert into SI_ALO values(100, 'Bairro Norte', 'Bairro Centro-Sul'););

insert into SI_ALO values(200, 'Bairro Centro-Sul', 'Bairro Leste');

insert into SI_ALO values(300, 'Bairro Leste', 'Bairro Norte');

insert into SI_PAR values(1001, 100, 'R.Alpargatas, 37', 'Truck');

insert into SI_PAR values(1002, 200, 'Av. da Gloria, 3007', 'Transp');

insert into SI_PAR values(1003, 300, 'Tv. do Chao, 603', 'Joia');

insert into SI_AGE values(40, 1001);

insert into SI_AGE values(50, 1002);

insert into SI_AGE values(60, 1003);

insert into SI_AGI values(10, 1001);

insert into SI_AGI values(20, 1002);

insert into SI_AGI values(30, 1003);

· Obtendo-se como resultado a implementação do Aplicativo de BD como abaixo:

· As Entidades do Protótipo de Aplicativo de BD SIS_PAR ficam então, como segue:

SI_ALO
Num_localidade	loc_atendimento	loc_naoatendimento
100	Bairro Norte	Bairro Centro-Sul
200	Bairro Centro-Sul	Bairro Leste
300	Bairro Leste	Bairro Norte

SI_AGI
num_grupodeinteresse	num_parceiro
10	1001
200	1002
30	1003

SI_AGE
num_grupodeexclusao	num_parceiro
40	1001
50	1002
60	1003

SI_PAR
num_parceiro	num_localidade	end_parceiro	nome_parceiro
1001	100	R. Alpargatas, 37	Truck
1002	200	Av. da Gloria, 3007	Transp SA
1003	300	Tv. Do Chão, 603	Joia

(b) Utilizar a heurística das 5 mais ou menos 2 Entidades; Atributos; Tuplas; Formulários e Relatórios; ou Consultas (Queries) para implementar e testar o seu Protótipo de Aplicativo de BD, visando integrá-lo, mais tarde, aos demais Protótipos em desenvolvimento.

RESOLUÇÃO:

As Entidades SI_ALO, SI_AGE e SI_AGI e SI_PAR foram implementadas no Protótipo de Aplicativo de BD SIS_PAR seguindo a heurística dos 5 mais ou menos 2 Entidades; Atributos; Tuplas; Formulários e Relatórios e dispostas de forma a facilitar os futuros níveis de integração com outras fases dos Bancos de Dados Setoriais (BDS), Bancos de Dados Corporativo (BDC) e do Banco de Dados Holding (BDH) HALCS.

A Primeira Consulta deverá envolver uma relação e pelo menos um comando Select e um comando Project (ou equivalentes).

A Segunda Consulta deverá envolver duas relações e pelo menos um comando Select, um Project e um Join (ou equivalentes).

E a Terceira Consulta deverá envolver três relações e pelo menos um comando Select, um Project e um Join (ou equivalentes).

RESOLUÇÃO:

Após a aplicação da consulta SQL (Queries) dada pelo código fonte abaixo (usando comandos equivalentes a SELECT, Project e JOIN pois o dialeto do JDataStore não segue o padrão ANSI), obteve-se a implementação da consulta envolvendo somente uma relação / tabela:

select loc_atendimento

from SI_ALO

where SI_ALO.num_localidade = 100;

Devendo-se obter como reposta, após a aplicação dos filtros, a tabela abaixo:

Loc_atendimento

Bairro Norte

O que fica demonstrado na tela capturada exibida abaixo:

select loc_naoatendimento

from SI_ALO, SI_PAR

where SI_PAR.nome_parceiro = 'Truck'

and SI_PAR.num_localidade=SI_ALO.num_localidade;

Devendo-se obter como reposta, após a aplicação dos filtros, a tabela abaixo:

Loc_naoatendimento

Bairro Centro-Sul

O que fica demonstrado na tela capturada exibida abaixo:

Após a aplicação da consulta SQL (Queries) dada pelo código fonte abaixo (usando comandos equivalentes a SELECT, Project e JOIN, pois o dialeto do JDataStore não segue o padrão ANSI), obteve-se a implementação da consulta envolvendo três relações / tabelas:

select num_grupodeinteresse, num_grupodeexclusao

from SI_AGI, SI_AGE, SI_PAR

where SI_AGI.num_parceiro = SI_PAR.num_parceiro

and SI_AGE.num_parceiro= SI_PAR.num_parceiro

and SI_PAR.num_parceiro=1001;

Devendo-se obter como reposta, após a aplicação dos filtros, a tabela abaixo:

Num_grupodeinteresse	Num_grupodeexclusao
10	40

O que fica demonstrado na tela capturada exibida abaixo:

(d) Realizar testes de verificação no seu Protótipo de Aplicativo de BD na 3ªFN, por analogia com os exemplos desenvolvidos pelo Prof. em Sala de Aula, com o Aplicativo de BD de Peças, Fornecedores e Carregamentos;

RESOLUÇÃO:

Os exemplos em sala de aula sugerem testes de acesso a uma, duas e três tabelas / relações e acessos encadeados.

Acesso a uma Tabela:

Problema: Listar todas as informações do Parceiro ‘Joia’:

Utilizando o código fonte (em dialeto SQL JDataStore) abaixo:

select *

from SI_PAR

where SI_PAR.nome_parceiro='Joia';

Devendo-se obter como reposta, após a aplicação dos filtros, a tabela abaixo:

Num_parceeiro	Num_localidade	End_parceiro	Nome_parceiro
1003	300	Tv. Do Chão, 603	Joia

O que fica evidenciado na tela capturada exibida abaixo:

Acesso a duas Tabelas:

Problema: Listar o número do Grupo de Interesse do Parceiro Transp:

Utilizando o código fonte (em dialeto SQL JDataStore) abaixo:

select num_grupodeinteresse

from SI_PAR, SI_AGI

where SI_PAR.nome_parceiro='Transp'

and SI_PAR.num_parceiro=SI_AGI.num_parceiro;

Devendo-se obter como reposta, após a aplicação dos filtros, a tabela abaixo:

Nuum_grupodeinteresse

O que fica demonstrado na tela capturada exibida abaixo:

Acesso a três Tabelas:

Problema: Listar o Número do Grupo de Interesse que atende a Localidade 100.

Utilizando o código fonte (em dialeto SQL JDataStore) abaixo:

select num_grupodeinteresse

from SI_PAR, SI_AGI, SI_ALO

where SI_PAR.num_parceiro=SI_AGI.num_parceiro

and SI_PAR.num_localidade=SI_ALO.num_localidade

and SI_ALO.num_localidade=100;

Devendo-se obter como reposta, após a aplicação dos filtros, a tabela abaixo:

num_grupodeinteresse

O que fica demonstrado na tela capturada exibida abaixo:

Consultas Encadeadas:

Problema: Listar o Nome e o Endereço dos Parceiros que atendem as Localidades cujo Número do Grupo de Interesse for maior que a média dos Números dos Grupos de Interesse.

Utilizando o código fonte (em dialeto SQL JDataStore) abaixo:

select nome_parceiro, end_parceiro

from SI_PAR, SI_AGI

where SI_AGI.num_grupodeinteresse>(select AVG(num_grupodeinteresse)

from SI_AGI)

and SI_PAR.num_parceiro=SI_AGI.num_parceiro;

Devendo-se obter como reposta, após a aplicação dos filtros, a tabela abaixo:

Nome_parceiro	End_parceiro
Joia	Tv. do Chao, 603

O que fica demonstrado na tela capturada exibida abaixo:

(e) Apresentar a Versão 1.0 dos 4 (quatro) Componentes do Sistema de Dicionário de Dados do seu Aplicativo de BD;

RESOLUÇÃO:

1) Dicionário de Dados – DD:

Um DD deve conter a descrição dos objetos de um Aplicativo de BD;

SI_ALO – Refere-se à entidade “LOCALIDADE”,
Atributos: num_localidade, loc_atendmento, loc_naoatendimento;

SI_AGI – Refere-se à entidade “GRUPO DE INTERESSE”,
Atributos: num_grupodeeinteresse, num_parceiro;

SI_AGE – Refere-se à entidade “GRUPO DE EXCLUSÃO”
Atributos: num_grrupodeexclusao, num_parceiro;

SI_PAR – Refere-se à entidade “PARCEIROS”
Atributos: num_parceiro, nuum_localdade, end_parceiro e nome_parceceiro.

2) Diretório de Dados:

Um Diretório de Dados deve agregar ao Dicionário de Dados informações sobre relacionamentos entre Dados, Entidades e Usuários;

No BD de Gestão Administrativa – GAD existem três Aplicativos de Banco de Dados: SIS-ORC, SIS-PAR e SIS-CLI para gerenciar Orçamento, Parcerias e Clientes. Entende-se a necessidade de criação de um Aplicativo de BD SIS-PAR com as seguintes ENTIDADES:

A entidade de “LOCALIDADE” (SI-ALO) deve conter informações sobre a região onde será efetuado o Serviço de Transporte de cargas.

A entidade de “GRUPO DE INTERESSE” (SI_AGI) deve conter informações sobre os parceiros e as regiões onde os mesmos fornecem o Serviço de Transporte.

A entidade “GRUPO DE EXCLUSÃO” (SI_AGE) deve conter informações sobre os parceiros e as regiões onde os mesmos não fornecem o Serviço de Transporte.

A entidade “PARCEIROS” (SI_PAR) deve conter informações sobre os parceiros como endereço, nome, número e localidade;

4) Dicionário de Metadados:

O Modelo Entidade-Relacionamento, como é chamado o Dicionário de Metadados, , utilizado está descrito abaixo:

No contexto de Parcerias (Aplicativo SIS-PAR), devemos gerenciar o conjunto de PARCEIROS (fornecedores de Serviço de Entrega) subdividindo-os em dois Grupos dependendo das LOCALIDADES de origem e destino para o Serviço de Entrega.

O primeiro grupo é formado por parceiros que a ALC tem interesse em manter relacionamento comercial, pois se mantém compatibilidade entre a LOCALIDADE onde o PARCEIRO mantém Serviço e a LOCALIDADE da Entrega. Esse é o chamado GRUPO de INTERESSE.

Por outro lado, o grupo de parceiros em que a ALC não tem interesse em acionar para o fornecimento de Serviços (pois não há compatibilidade entre a LOCALIDADE onde o PARCEIRO mantém Serviço e a LOCALIDADE da Entrega) é definido como GRUPO de EXCLUSÃO.

(f) Elaborar e implementar, em Linguagem Natural, em Linguagem Estruturada de Consultas (Structured Query Language - SQL), pelo menos 03 (três) diferentes Consultas ao seu Aplicativo de BD, em níveis crescentes de complexidade (da mais simples para a mais complexa), utilizando os comandos Select; Project; Join; ou equivalentes;

RESOLUÇÃO:

Consulta com grau de dificuldade Simples:

Consulta: Qual o endereço do Parceiro Transp?

select end_parceiro

from SI_PAR

where SI_PAR.nome_parceiro='Transp';

Consulta com grau de dificuldade Média:

Consulta: Qual o local de atendimento e o número do Grupo de Interesse do Parceiro Truck ?

select loc_atendimento, num_grupodeinteresse

from SI_PAR, SI_AGI, SI_ALO

where SI_PAR.nome_parceiro='Truck'

and SI_ALO.num_localidade=SI_PAR.num_localidade

and SI_AGI.num_parceiro=SI_PAR.num_parceiro;

Consulta com grau de dificuldade Difícil:

Consulta: Qual o número do Grupo de Exclusão e os Nomes dos Parceiros para o Bairro ‘Centro-Sul’?

select num_grupodeexclusao, nome_parceiro

from SI_PAR, SI_AGE, SI_ALO

where SI_PAR.num_localidade=SI_ALO.num_localidade

and SI_ALO.loc_naoatendimento= 'Bairro Centro-Sul'

and SI_AGE.num_parceiro=SI_PAR.num_parceiro;

(e) Publicar os Resultados das 03 (três) Consultas ao seu Aplicativo de BD, copiados e colados em HTML na sua subhomepage.

RESOLUÇÃO:

Resultados Publicados no link LISTEX04.

Consulta com grau de dificuldade Simples:

Consulta com grau de dificuldade Média:

Consulta com grau de dificuldade Difícil:

2) Quanto a Pesquisa e Conversão do seu Aplicativo de BD Modelo de Dados Relacional na 3ªFN para os Modelos de Dados Hierárquico, Redes e Orientado a Objetos, cada aluno deverá:

(a) Pesquisar, Analisar e Estudar exemplos do Prof. Da Matéria, de artigos ou de livros, e por analogia, realizar a publicação, em HTML na sua subhomepage, das conversões do Modelo de Dados Relacional do seu Aplicativo de BD para os Modelos de Dados Hierárquico, Rede, e Orientado a Objetos; e

RESOLUÇÃO:

A pesquisa abaixo foi transcrita do livro-texto “Sistema de Banco de Dados” doa autores: Abraham Silberschatz, Henry .Korth e S. Sudarshan (3ª Edição – Makron Books)

Modelo de Dados de Rede:

É um Modelo Lógico com base em Registros. Os dados no Modelo em Rede são representados por um conjunto de Registros e as relações entre esses são representadas por links (ligações), as quais podem ser vistas pelos ponteiros. Os Registros são organizados no BD por um conjunto arbitrário de gráficos

Modelo de Dados Hierárquico:

Outro exemplo de Modelo Lógico com base em Registros. O Modelo Hierárquico é similar ao Modelo em Rede, pois os dados e suas relações são representados, respectivamente, por Registros e Links. A diferença é que no Modelo Hierárquico os Registros estão Organizados em Árvores em vez de gráficos arbitrários.

Modelo de Dados Orientado a Objetos:

É um Modelo Lógico com base em Objetos. Como o MER, o modelo Orientado a Objetos tem por base um conjunto de Objetos. Um objeto contém valores armazenados em variáveis instâncias dentro do objeto. Um objeto contém conjuntos de códigos que operam esse objeto. Esses conjuntos de códigos são chamados métodos.

Os objetos que contém os mesmos tipos de valores e os mesmos métodos são agrupados em classes. Uma classe pode ser vista como uma definição de tipos para objetos. Essa combinação compacta de dados e métodos abrangendo uma definição de tipo é similar ao tipo abstrato em uma linguagem de programação.

O único modo pelo qual um objeto pode ter acesso aos dados de outro objeto é por meio do método desse outro objeto. Essa ação é chamada “Enviar mensagem ao objeto”. Assim, a interface de métodos de um objeto define a parte externa “visível” de um objeto.A parte interna de um objeto - as instâncias variáveis e o código do método - não são visíveis externamente. O resultado são dois níveis de abstração de dados.

(b) Demonstrar a realização dos três processos de conversão do Aplicativo de BD, utilizando pelo menos 03 (três) Entidades, Classes ou Objetos, cada um contendo, no mínimo, 03 (três) Atributos; e

RESOLUÇÃO:

Vamos converter a seguinte tabela do Modelo Relacional conforme solicitado:

SI-ALO
Num_localidade	loc_atendimento	loc_naoatendimento

SI_PAR
num_parceiro	num_localidade	end_parceiro	nome_parceiro

Conversão para o Modelo de Dados de Rede:

Conversão para o Modelo de Dados Hierárquico:

Conversão para o Modelo de Dados Orientado a Objetos:

O Modelo Orientado a Objetos tem uma representação gráfica semelhante ao do MER. Há, no entanto, uma troca com o Nome da Entidade no Local do Nome da Classe/Objeto, e os Atributos da Entidade no Local dos Atributos da Classe/Objeto.

SI_PAR

num_parceiro

num_localidade

end_parceiro

nome_parceiro

SI_ALO

num_localidade

loc_atendimento

loc_naoatendimento

(c) Concluir que Modelo de Dados de BD é o mais adequado para o desenvolvimento do seu Aplicativo de BD, apresentando os principais resultados e justificativas.

RESOLUÇÃO

O Modelo Relacional difere dos modelos “Hierárquico” e “em Rede” por não usar nem ponteiros nem links. Ele relaciona os registros por valores próprios a eles. Como não é necessário o uso de ponteiros, há uma maior facilidade em sua utilização. Além disso, o uso do Modelo Relacional é mais comum, estando disponíveis diversas ferramentas CASE (Computer Aided Software Engeneering) e RAD (Rapid Application Development) disponíveis para implementação de Aplicativos de BD por esse Modelo.

Portanto, o Modelo de Dados Relacional será utilizado para implementação do Aplicativo de BD SIS_PAR.

3. - Principais Conclusões, Recomendações e Sugestões:

Recomenda-se utilizar um Sistema Gerenciador de Banco de Dados (SGBD) disponível, com um dialeto SQL parecido ao do padrão ANSI para Implementar e Testar o Protótipo de Aplicativo de Banco de Dados SIS_PAR com uma Modelagem Entidade - Relacionamento visando reduzir o desperdício de recursos nas futuras fases de integração e melhorar a eficiência operacional dos Bancos de Dados Setoriais (BDS), Bancos de Dados Corporativo (BDC) e do Banco de Dados Holding (BDH) HALCS;