Instituto Tecnológico de Aeronáutica – ITA
EDUARDO MENA BARRETO ALONSO São José dos Campos, 05 de Maio de 2011
CE-240 - Projeto de Sistemas de Bancos de Dados Prof. Dr. Adilson Marques da Cunha
1. INTRODUÇÃO 1.1. Objetivo
1) Implementar a Terceira Forma Normal (3ªFN) do Protótipo de Aplicativo de Banco de Dados (BD) para a Unidade de Polícia Pacificadora 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) Aplicar 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, visando identificar algumas das suas principais diferenças e características.
1.2. Motivação
Elaborar e implementar consultas em Linguagem natural e estruturada dentro do contexto da temática escolhida pelo autor, envolvendo 1, 2, 3 ou mais
relações, em níveis crescentes de complexidade ensinado na disciplina CE240, visando melhorar o tempo de acesso, em termos de armazenamento e
recuperação de Informações.
2. DESCRIÇÃO DOS PRINCIPAIS PROCEDIMENTOS REALIZADOS PELO ALUNO
2.1. Implementação do Modelo de Dados Relacional
O Aplicativo de Banco de Dados, já desenvolvido conceitualmente na listEx 3 verão 2 desta disciplina, será implementado no banco de dados ORACLE SQL Developer, sendo utilizado o software ERWIN para implementar sua
modelagem conforme mostrado a seguir:
2.1.1. Implementar e Testar a 3ªFN do Modelo de Dados do Aplicativo de BD
Nesta atividade foram criadas as tabelas do aplicativo Unidade de Polícia Pacificadora e seus respectivos atributos utilizando o software ERWIN conforme apresentado na Figura 1.e Figura 2.
Figura 1 - Implementação do modelo do aplicativo PO_UPP para geração de tabelas.
Figura 2 – Criação das tabelas do aplicativo PO_UPP utilizando o software Oracle SQL Developer.
2.1.2. Inserção de Tuplas e Testes de Verificação
As inserções nas tuplas e seus testes foram executados por meio de comandos na linguagem SQL conforme apresentado a seguir:
Tabela PO_UPP
cod_PO_UPP nom_PO_UPP lat_PO_UPP lon_PO_UPP und_participante 1 ALEMAO 22°42’44’’S 43°11’17’’O POLICIA CIVIL 2 BOREL 22°56’18’’S 43°15’16’’O POLICIA MILITAR
3 PAVAO 22°58’51’’S 43°11’41’’O POLICIA
MILITAR,EXERCITO Tabela MONITORAR
cod_monitoramento nom_monitoramento cmo_critico
1 AR CONDICIONADO 1000 2 ILUMINACAO 500 3 TEMPERATURA 20 Tabela DES_LOCAL cod_local nom_local 1 RECEPCAO 2 SALA 1 3 SALA 2 Tabela CONSUMO
cod_po_upp cod_local cod_monitorar dat_monitorar val_consu mo alm_consu mo 1 1 1 17052011 750 CONSUMO NORMAL 2 1 1 17052011 900 CONSUMO NORMAL 3 1 1 17052011 1100 CONSUMO ACIMA DO NORMAL
PRIMEIRA CONSULTA Linguagem Natural
Listar o nome do monitoramento com consumo crítico igual a 500 Linguagem Estruturada Select nom_monitoramento From MONITORAR where; cmo_critico = 500; Resultado Esperado: ILUMINACAO SEGUNDA CONSULTA Linguagem Natural
Listar o nome do local onde o consumo ultrapasse o limite critico. Linguagem Estruturada
Select nom_local
From LOCAL, CONSUMO where;val_consumo >1000; Resultado Esperado: RECEPCAO
TERCEIRA CONSULTA Linguagem Natural
Listar o valor do consumo no dia 11052011 as 1135 da sala 2 da PO_UPP do ALEMAO.
Linguagem Estruturada Select val_consumo
From CONSUMO,LOCAL,PO_UPP
where;cod_pó_upp = 1, cod_local =3 and dat_monitoramento=11052011,and hor_ monitoramento = 1135;
Resultado Esperado: 750
QUARTA CONSULTA Linguagem Natural
Listar o valor do consumo da PO_UPP localizada na latitude 225618 e longitude 431516 na recepção no dia 11052011 as 1155.
Linguagem Estruturada Select val_monitoramento From PO_UPP CONSUMO
where;lat_po_upp = 225618, and log_po_upp = 431516, cod_local = 1, and dat_po_upp = 11052011, and hor_po_upp = 1155;
Resultado Esperado: 1100
2.2. Sistema de Dicionarização de Dados
O sistema de dicionário de dados é composto por Dicionário de Dados, Diretório de Dados, Dicionário de Recursos de Dados e Dicionário de Meta Dados. Esses componentes estão
descritos a seguir:
2.2.1. Dicionário de Dados
Descrição Física das Entidades e de seus Ambientes Associados Entidade PO_UPP
Objetivo: Definir o nome, a localização e os participantes (policia,exercito,etc..)das po_upp
Atributos Tipo de Dados Permite Nulo Chave Primaria Chave Estrangeira
Cod_po_upp INTEGER NÃO SIM NÃO
Nom_po_upp VARCHAR(20) NÃO NÃO NÃO
Lat_po_upp VARCHAR(20) NÃO NÃO NÃO
Lon_po_upp VARCHAR(20) NÃO NÃO NÃO
Und_participante VARCHAR(40) NÃO NÃO NÃO
Entidade MONITORAR
Objetivo: Definir o que será monitorado
Atributos Tipo de Dados Permite Nulo Chave Primaria Chave Estrangeira
Cod_monitorar INTEGER NÃO SIM NÃO
Nom_monitorar VARCHAR(20) NÃO NÃO NÃO
Entidade DES_LOCAL
Objetivo: Definir os locais onde serão realizados monitoramento
Atributos Tipo de Dados Permite Nulo Chave Primaria Chave Estrangeira
Cod_local INTEGER NÃO SIM NÃO
Nom_local VARCHAR(20) NÃO NÃO NÃO
Entidade CONSUMO
Objetivo: Monitorar o consumo das po_upp
Atributos Tipo de Dados Permite Nulo Chave Primaria Chave Estrangeira
Cod_po_upp INTEGER NÃO SIM NÃO
cod_monitorar INTEGER NÃO SIM NÃO
Cod_local INTEGER NÃO SIM NÃO
Dat_consumo DATE NÃO NÃO NÃO
Val_consumo INTEGER NÃO NÃO NÃO
Alm_consumo VARCHAR(20) NÃO NÃO NÃO
2.2.2. Diretório de Dados
O Diretório de Dados é a descrição de Processos Associados às Entidades Peopleware:
Administradores de Bancos de Dados (DBAs): podem criar, remover ou alterar tabelas, atributos, índices, funções e procedimentos visando melhorar o desempenho do sistema e/ou adequar os dados a novas regras de negócio. Desenvolvedores: desenvolvem novos sistemas ou melhoram os sistemas já existentes que fazem a interface entre usuários finais e o banco de dados. Software:
Formulários ou documentos de entrada (captar dados ou informações); Transações ou documentos de processamento (associa a ocorrência de um único dado a um ou mais eventos, essas entidades são normalmente
associadas a processamento);
Relatórios ou documentos de saída (agregar dados ou informações).
2.2.3.Dicionário de Recursos de Dados
Descrição Física das Entidades e de seus Ambientes Associados. Agrega ao diretório de dados as descrições físicas da estrutura do Aplicativo de Banco de Dados e as descrições do ambiente de processamento.
Localização
LOCALIZAÇÃO Servidor FCMF- LABTEC – ITA (CE 240)
SBDG Servidor FCMF- LABTEC – ITA (CE 240)
SW PARA MANIPULAR DADOS Oracle SQL Developer
SISTEMA OPERACIONAL WINDOWS XP PROFISSIONAL
2.2.4.Dicionário de Meta Dados
Descrição Conceitual das Entidades num Nível Alto de Abstração
2.3. Conversões
Com a existência dos bancos de dados relacional hierárquico, orientado a objetos e de rede, essa sessão tem por objetivo apresentar a representação do aplicativo de banco de dados para a Unidade de Polícia Pacificadora nestes três bancos e identificar, conforme suas características, qual deles melhor atende as necessidades do aplicativo.
2.3.1. Modelo Hierárquico
No Modelo de Dados Hierárquico, os registros são organizados como coleções de árvores. 2.3.2. Modelo de Rede MONITORAR #* cod_monitorar # nom_monitorar 0 cmo_critico PO-UPP #* cod_po-upp # nom_po-upp # lat_po-upp # lon_po-upp 0 und_po-upp DES_LOCAL #* cod_local # nom_local CONSUMO #* cod_consumo #* cod_po-upp #* cod_local #* cod_monitorar # dat_ monitorar # val_consumo 0 alm_ consumo Seleciona o que monitorar Seleciona o local a ser monitorado Realiza o monitoramento
O Modelo de Dados de Rede difere do Modelo de Dados Relacional à medida que os dados são apresentados por uma coleção de registros e os
relacionamentos entre dados são representados por meio de links, enquanto no Modelo Relacional, os dados e os relacionamentos entre dados são
representados por meio de uma coleção de tabelas. 2.3.3. Modelo Orientado a Objeto
Os Modelos de Dados Orientados a Objetos correspondem a uma organização de sistemas como uma coleção de objetos que integram estruturas de dados e seus comportamentos. Além disso, diversos conceitos, princípios e
mecanismos que os diferenciam dos demais. 2.3.4. Definição de Qual Modelo Utilizar
Conforme as características de cada banco de dados e as necessidades deste aplicativo de banco de dados, conclui-se que o banco mais adequado a se utilizar é o banco de dados relacional, pois os outros não atende com completeza e em algumas situações tornaram-se complexos.
3. CONCLUSÃO
Este trabalho teve por objetivo implementar a Terceira Forma Normal (3ªFN) do Protótipo de Projeto de Aplicativo de BD para a Unidade de Polícia Pacificadora (UPP) do Projeto Acadêmico para um Sistema Smart Grids utilizando um
Modelo de Dados Relacional em um Sistema Gerenciador de Banco de Dados (SGBD), sendo testando a sua funcionalidade, visando futuras fases de
integração em Bancos de Dados Setoriais (BDS), Bancos de Dados Corporativo (BDC) e do Banco de Dados Holding (BDH).
Para isso, foi utilizado o aplicativo Oracle SQL Developer, onde foi aplicado alguns comandos de SQL para criação e manipulação dos dados aprendidos em aula, envolvendo 1, 2, 3 ou mais relações, em níveis crescentes de complexidade, o qual foi possível notar agilidade no tempo de acesso, em termos de armazenamento e recuperação de Informações.
Logo em seguida, foi apresentado os Modelos de Dados Hierárquico, Rede e Orientado a Objetos a partir de um modelo de Dados Relacional na 3ªFN com a finalidade de identificar algumas das suas principais diferenças e
características e assim analisar qual modelo se adéqua ao protótipo de aplicativo de BD do projeto.
