Listex 5 v1 integração.

(1)

MINISTÉRIO DA AERONÁUTICA

DEPARTAMENTO DE PESQUISAS E DESENVOLVIMENTO

CENTRO TÉCNICO AEROESPACIAL

Instituto Tecnológico de Aeronáutica

Programa de Pós-Graduação em

Engenharia Eletrônica e Computação - Informática

CE-240

Projeto de Sistemas de Bancos de Dados

Professor Doutor Adilson Marques da Cunha

Listex 5 - Anexo I - Integração

Roberto Mellado Pepato

Auxiliares:

Robson Luis Monteiro Junior

Eduardo Mena Barreto

Alexander Silva

(2)

Índice

Anexo I - Integração ... 3 Re-Contextualização ... 3 Identificação do Problema ... 3 Enunciando do Problema ... 4 Definição da Solução ... 4 Soluções Possíveis ... 4 Análise APA ... 4 Redefinição do Título ... 6

Integração dos aplicativos de banco de dados em um banco de dados setorial. ... 6

Etapa 1 - Integração entre ADB-ILU-PO e ADB-UPP-PO ... 7

Etapa 2 - Integração entre ADB-EQU-PO e ADB-ADM-PO ... 8

Etapa 3 - Integração entre ADB-ILU-PO e ADB-ADM-PO ... 10

Etapa 4 - Integração entre ADB-ILU-PO e ADB-EQU-PO ... 11

(3)

Anexo I - Integração

Re-Contextualização

Uma rede inteligente de distribuição de energia (Smart Grid) é uma ferramenta que tem como objetivo a melhora continua do monitoramento, controle e qualidade da energia fornecida a fim de reduzir o desperdício na distribuição de energia. Uma das grandes vantagens e características de uma rede inteligente é permitir que os consumidores de energia também possam vender energia sobressalente de suas propriedades ajudando na redução de custos no investimento de infra-estruturas para geração de energia. O departamento de polícia possui hoje quatro aplicativos de bancos de dados distintos com foco em gerenciamento de equipamentos, iluminação pública, unidades de polícia pacificadora e administração do departamento de polícia. A integração entre esses quatro aplicativos de banco de dados é desejada para que seja possível a realização de consultas táticas do departamento de polícia.

Identificação do Problema

Ea(s) (Efeitos Adversos) - O que está errado?

O departamento de policia carece de uma visão integrada de seus dados de consumo e oferta energética. Atualmente, as visões de consumo e oferta energética do departamento de polícia estão dividas de forma setorial propiciando uma visão operacional e não integrada e impossibilitando consultas em níveis táticos.

C(s) (Causas) - Por que está errado?

Hoje o departamento de policia possui as visões de consumo e oferta de energia de forma setorial, implementadas em aplicativos de bancos de dados distintos, permitindo apenas consultas operacionais.

T (Tarefa)– O que, onde e quando se deseja realizar?

O que? – Integrar os quatro aplicativos de banco de dados de gerenciamento de consumo e oferta de energia do departamento de polícia em um único aplicativo de banco de dados, contendo as informações necessárias à operação e gerenciamento do mesmo, de forma integrada.

Quem, onde, em que âmbito? – Na disciplina CE-240 no Instituto Tecnológico de Aeronáutica; Quando? – Até o dia 23/05/2011;

(4)

P (Propósito) - Para que se deseja realizar a Tarefa?

Para propiciar a visão tática sobre consumo e oferta de energia elétrica do departamento de polícia, visando a diminuição do desperdício de energia elétrica.

Enunciando do Problema

Integrar quatro aplicativos de banco de dados do departamento de polícia, do projeto acadêmico sobre Smart Grid da disciplina CE-240 no Instituto Tecnológico de Aeronáutica em um único aplicativo de banco de dados do departamento de polícia, até o dia 23/05/2011 que propicie o armazenamento e consulta de informações sobre gerenciamento de equipamentos, iluminação pública, unidades de polícia pacificadora e administração do departamento de polícia.

Definição da Solução

Nessa etapa do projeto foram identificadas as alternativas de solução possíveis (ASPs), Análise de Adequabilidade, Praticabilidade e Aceitabilidade (APA).

Soluções Possíveis

ASP1: Não desenvolver a integração dos aplicativos de banco de dados;

ASP2: Realizar a integração de dois aplicativos de bancos de dados operacionais atualmente

implementados, de maneira manual, até o final de 2011;

ASP3: Integrar os aplicativos de banco de dados de consumo e oferta de energia do

departamento de polícia, até o dia 23/05/2011, propiciando o armazenamento e consulta de informações sobre gerenciamento de equipamentos, iluminação pública, unidades de polícia pacificadora e administração do departamento de polícia.

Análise APA

Adequabilidade – A solução ASP1 não pode ser de nenhuma forma adequada porque não

cumpre nenhuma necessidade, assim não cumpre o a analise de afinidade com a solução. As demais soluções possíveis foram consideradas adequadas.

(5)

A princípio a analise da adequabilidade foi satisfatória, porem agora é necessária analisar os quatro fatores da adequabilidade:

Afinidade - A ASP2 e ASP3 apresentaram resultados satisfatórios, pois são da mesma

natureza da Tarefa proposta anteriormente;

Integridade – Somente a ASP3 apresentou resultado satisfatório nessa analise, pois ela

atende de maneira totalmente satisfatória os requisitos do problema especificado;

Âmbito – Somente a ASP3 apresentou resultado satisfatório nessa analise, pois ela

atende de maneira totalmente satisfatória onde o problema será resolvido. A ASP2 teria de ser integrada considerando os quatro aplicativos de banco de dados atualmente existentes.

Oportunidade – Somente a ASP3 apresentou resultado satisfatória nesta análise, pois

as tarefas poderão ser executadas dentro do período de execução proposto.

Praticabilidade – A solução ASP3 foi considerada praticável pois automatiza toda a integração

dos aplicativos de bancos de dados de controle de consumo e oferta de energia do departamento de polícia atualmente existentes, propiciando a criação de um conjunto de visões táticas sobre o gerenciamento de equipamentos, iluminação pública, unidades de polícia pacificadora e administração do departamento de polícia, de maneira integrada.

Após realizar a analise dos quatro fatores da analise da adequabilidade, foram analisados 3 fatores da analise da praticabilidade, sendo eles, disponibilidade, qualidade e ambiente.

Disponibilidade – A ASP3 foi considerada satisfatória, pois os recursos necessários

para execução da tarefa se encontram disponíveis, em quantidade e qualidade suficiente;

Qualidade – A ASP3 apresentou resultado satisfatório nessa analise, pois os meios de

implantação da solução são considerados suficientes e adequados para a execução da tarefa;

Ambiente – A ASP3 apresentou resultado satisfatório nessa analise, a condição do

ambiente apresenta resultado satisfatório.

Aceitabilidade – Após analise da adequabilidade e praticabilidade das ASPs, a APS3 foi

considerada adequada e totalmente praticável, por isso foi aprovada.

Após as analises de adequabilidade e praticabilidade, foi realizada a analise da aceitabilidade das soluções propostas, respondendo três perguntas:

(6)

Os Resultados Obtidos compensam os Custos?

A pergunta foi respondida positivamente somente para a ASP3, pois o custo de implementação da integração dos aplicativos de banco de dados se paga depois de pouco tempo da implantação.

Os Resultados Obtidos compensam os Riscos Assumidos?

A pergunta foi respondida positivamente a ASP3, pois se trata de um projeto acadêmico, onde o risco é baixo.

A Alternativa de Solução Convém?

A pergunta foi respondida positivamente para a ASP3, pois o problema é resolvido dentro das restrições de tempo e custo propostas pelo projeto.

Portando a ASP3 foi à solução proposta escolhida como a mais adequada.

Redefinição do Título

Observando-se a própria análise da definição e solução do problema, percebe-se que existe a necessidade de uma visão integrada dos aplicativos de banco de dados atualmente existentes no departamento de polícia, para gerenciamento de consumo e oferta de energia elétrica. Assim o titulo proposto para este projeto a ser considerado é: “Aplicativo de Banco de Dados para o

Gerenciamento de Recursos Energéticos do Departamento de Policia” (ABD-GRE-DPO)

Integração dos aplicativos de banco de dados em um banco de dados

setorial.

Foram analisados os quatro aplicativos de banco de dados que compõe o banco de dados setorial da polícia.

Tento como partida o aplicativo de banco de dados da iluminação da polícia (ADB-ILU-PO) e o aplicativo de banco de equipamentos da polícia (ADB-EQU-(ADB-ILU-PO) foram constatados que os aplicativos de banco de dados da unidade de policia pacificadora (ADB-UPP-PO) e de administração da polícia (ADB-ADM-PO) continham entidades em comum, conforme abaixo:

(7)

Etapa 1 - Integração entre ADB-ILU-PO e ADB-UPP-PO

O ADB-ILU-PO e ADB-UPP-PO continham a entidade LOCAL em comum, isso permitiu que as duas entidades pudessem ser integradas, conforme descrito abaixo.

ADB-ILU-PO - LOCAL -> { loc_identificador, loc_identificacao, loc_area, loc_restricao} ADB-UPP-PO - LOCAL -> { cod_local, nom_local}

Foi identificado que o atributo nom_local é idêntico ao loc_identificacao, sendo assim a entidade local se tornou:

LOCAL -> { loc_identificador, loc_identificacao, loc_area, loc_restricao}

A entidade MONITORAR do ADB-UPP-PO e a MONITORAMENTO do ADB-ILU-PO possuem a mesma funcionalidade, então os atributos da entidade MONITORAR foram integrados a entidade MONITORAMENTO e a entidade MONITORAR deixou de existir, conforme descrição abaixo:

ADB-ILU-PO - MONITORAMENTO -> { mon_identificador, equ_identificador, mon_estado, mon_data_ocorrencia, mon_mensagem }

ADB-UPP-PO - MONITORAR -> { cod_monitoramento, nom_monitoramento, cmo_critico }

Foi identificado que o atributo nom_monitoramento não estava presente e que cmo_critico também., assim a entidade se tornou foi trigramada novamente e se tornou.

nom_monitoramento -> nom_identificacao cmo_critico -> mon_consumo_critico

MONITORAMENTO -> {mon_identificador, nom_identificacao, mon_consumo_critico, equ_identificador, mon_estado, mon_data_ocorrencia, mon_mensagem }

Entendemos que uma unidade de policia pacificadora também é uma delegacia de polícia e a entidade LOCAL que anteriormente estavam presentes nos dois ABD’s, a entidade

(8)

PO_UPP presente na no UPP-PO foi integrada e relacionada à entidade LOCAL em ADB-ILU-PO, se tornando a entidade DEPARTAMENTO_POLICIA:

ADB-UPP-PO - PO_UPP -> DEPARTAMENTO_POLICIA

DEPARTAMENTO_POLICIA -> { cod_po_upp, nom_po_upp, lat_po_upp, lon_po_upp,

und_participante}

A entidade CONSUMO presente no ABD-UPP-PO, tem a mesma função que a MONITORAMENTE, sendo assim foi integrada:

ADB-ILU-PO - MONITORAMENTO -> {mon_identificador, nom_identificacao, mon_consumo_critico, equ_identificador, mon_estado, mon_data_ocorrencia, mon_mensagem } ADB-UPP-PO - CONSUMO -> {dat_monitoramento, hor_monitoramento, val_consumo, alm_consumo}

Valores correlatos entre as entidades:

dat_monitoramento e hor_monitoramento -> mon_data_ocorrencia

Após a trigramação:

MONITORAMENTO -> {mon_identificador, nom_identificacao, mon_consumo_critico, equ_identificador, mon_estado, mon_data_ocorrencia, mon_mensagem, mon_consumo }

Dessa forma a o ADB-UPP-PO foi totalmente integrado ao ADB-ILU-PO na etapa 1, porem as tabelas não estão normalizadas, etapa essa que será realizada posteriormente.

Etapa 2 - Integração entre ADB-EQU-PO e ADB-ADM-PO

O ADB-EQU-PO e o ADB-ADM-PO possuem 3 entidades em comum, permitindo uma integração fácil e coerente, as entidades EQUIPAMENTO e FABRICANTE estão presente nos dois ABD’s e foram integradas, conforme descrito abaixo:

(9)

ADB-EQU-PO - FABRICANTE -> { Fab_codigo, Fab_nome, Fab_telefone, Fab_endereco } ADB-ADM-PO – FABRICANTE -> { num_fab, mon_fab, end_fab, tel_fab}

Atributos correlatos:

Fab_nome -> nom_fab Fab_telefone -> end_fab Fab_endereco -> tel_fab

Resultado:

FABRICANTE -> { Fab_codigo, Fab_nome, Fab_telefone, Fab_endereco }

ADB-EQU-PO - EQUIPAMENTO -> { Eqp_codigo, Fab_codigo, Teq_codigo, dpp_codigo, Eop_codigo, Mdd_codigo, Eqp_descricao, Eqp_tensao_de_operacao, Eqp_modelo, Eqp_tomada_abnt }

ADB-ADM-PO – EQUIPAMENTO -> { num_equip, num_fab, tipo_equip, mod_equip, poten_equip } Atributos correlatos: Fab_codigo -> num_fab Teq_codigo -> tipo_equip Eqp_tensao_de_operacao -> poten_equip Eqp_modelo -> mod_equip Resultado:

EQUIPAMENTO -> { Eqp_codigo, Fab_codigo, Teq_codigo, dpp_codigo, Eop_codigo,

Mdd_codigo, Eqp_descricao, Eqp_tensao_de_operacao, Eqp_modelo }

A entidade DATALOGGER presente no ADM-PO e MEDIDOR presente no ADB-EQU-PO têm a mesma função, por isso foram integradas na entidade MEDIDOR e a entidade DATALOGGER foi eliminada.

(10)

ADB-EQU-PO - MEDIDOR -> { Mdd_codigo, Eop_codigo, Mdd_local_instalacao, Mdd_descricao, Mdd_tensao_de_rede}

ADB-ADM-PO – DATALOGGER -> { num_logger, lat_logger, lon_logger, depart_pol, consu_md}

Mdd_local_instalacao -> lat_logger, lon_logger Mdd_tensao_de_rede -> consu_md

Resultado:

MEDIDOR -> { Mdd_codigo, Eop_codigo, Mdd_local_instalacao, Mdd_descricao, Mdd_tensao_de_rede, Mdd_departamento_policia, Mdd_circuito }

Etapa 3 - Integração entre ADB-ILU-PO e ADB-ADM-PO

Após a conclusão da Etapa 2, foi constando que a entidade TOMADA estava presente em ambos ABD’s, por isso foram integradas, dessa forma a entidade ADB-ADM-PO foi totalmente integrado ao novo modelo que está sendo formado, conforme resultado abaixo:

ADB-ILU-PO - TOMADA -> { tom_identificador, cor_identificador, tom_voltagem, tom_norma_abnt }

ADB-ADM-PO – TOMADA -> { num_tom, num_equip, local_tom, tensao_tom, tempo_uso}

tom_voltagem -> tensao_tom

O atributo num_equip foi eliminado porque a também tomada já faz referencia a entidade EQUIPAMENTO.

(11)

TOMADA -> { tom_identificador, cor_identificador, tom_voltagem, tom_norma_abnt, tmo_tempo_uso }

Etapa 4 - Integração entre ADB-ILU-PO e ADB-EQU-PO

Após a 3 etapas, dois modelos foram formados, faltando a integração entre ILU-PO e ADB-EQU-PO. Dessa forma foi identificado que o ADB-ILU-PO e o ADB-EQU-PO possuíam as tabelas EQUIPAMENTO e TIPOEQUIPAMENTO em comuns, elas foram integradas com seus atributos, conforme descrição abaixo.

Entidade gerada através da integração na etapa 2:

Mdd_codigo, Eqp_descricao, Eqp_tensao_de_operacao, Eqp_modelo }

ADB-ILU-PO – EQUIPAMENTO -> { equ_identificador, tom_identificador, teq_identificador, equ_voltagem, equ_tomada_abnt, equ_localixacao_geografica}

equ_identificador -> Eqp_codigo teq_identificador -> Teq_codigo

equ_voltagem -> Eqp_tensao_de_operacao equ_voltagem -> Eqp_tensao_de_operacao

Mdd_codigo, Eqp_descricao, Eqp_tensao_de_operacao, Eqp_modelo, Eqp_tomada_abnt, Eqp_localixacao_geografica }

Resultado final da integração

Após a integração dos quatro aplicativos de banco de dados, foi formado o seguinte modelo, cabe notar que o modelo não está normalizado:

(12)

LOCAL -> { loc_identificador, loc_identificacao, loc_area, loc_restricao}

DEPARTAMENTO_POLICIA -> { cod_po_upp, nom_po_upp, lat_po_upp, lon_po_upp,

und_participante}

MONITORAMENTO -> {mon_identificador, nom_identificacao, mon_consumo_critico, equ_identificador, mon_estado, mon_data_ocorrencia, mon_mensagem, mon_consumo }

FABRICANTE -> { Fab_codigo, Fab_nome, Fab_telefone, Fab_endereco }

MEDIDOR -> { Mdd_codigo, Eop_codigo, Mdd_local_instalacao, Mdd_descricao, Mdd_tensao_de_rede, Mdd_departamento_policia, Mdd_circuito }

MEDICAO {mdc_codigo, Mdd_codigo, mdc_data_ocorrencia, mdc_demanda_total, mdc_tensao_rede}

TOMADA -> { tom_identificador, cor_identificador, tom_voltagem, tom_norma_abnt, tmo_tempo_uso }

Mdd_codigo, Eqp_descricao, Eqp_tensao_de_operacao, Eqp_modelo, Eqp_tomada_abnt, Eqp_localixacao_geografica }

CORREDOR {cor_identificador, loc_identificador, cor_identificacao, cor_metragem, cor_quantidade_portas}

TIPOEQUIPAMENTO {Teq_codigo, Teq_abreviacao, Teq_descricao}

ESTADO_OPERACAO {Eop_codigo, Eop_abreviacao, Eop_descricao}Tabela 1 - Criação da