ITA - Instituto
Tecnológico de Aeronáutica
IEC
– Divisão de Ciência da Computação
CE-240 - Projeto de Sistema de Bancos de Dados
Prof.
Dr. Adilson Marques da Cunha
Projeto Final
Claudia
Helena Ferreira Vignoli
Projeto de Sistemas de
Banco de Dados
Protótipo do Sistema
Aplicativo de Banco de Dados para a Gestão do Faturamento
inserida no contexto da Holding HITS – Holding Intelligent Transportation
System
SUMÁRIO
I - INTRODUÇÃO
1.1 Motivação
1.2. Contexto
1.3. Objetivos
1.4. Especificação de Requisitos
II - DESENVOLVIMENTO
2.1. Aplicativo de Banco de Dados
2.2. Banco de Dados Setoriais 1 e 2
2.3. Banco de Dados Corporativo
2.4. Simulação de Jogos de Empresa
III – CONCLUSÃO
E RECOMENDAÇÕES
I.
INTRODUÇÃO
1.1. Motivação
A
área de Engenharia da Informação é uma das vertentes mais fascinantes e da
Ciência da Computação. Sua aplicabilidade é extensa, o mercado para ela é
desafiador e continua em franco crescimento. Desta forma, perseguindo técnicas
mais apropriadas para solucionar os desafios encontrados, pela aplicabilidade
prática da questão, aliados à percepção de que no mercado é crescente a busca
por melhores soluções em termos de se evitar desperdícios, reduzir custos,
melhorar a eficiência, garantir a qualidade e segurança de seus sistemas,
caracterizaram a formação dos fatores motivadores para o desenvolvimento de
soluções para os trabalhos propostos.
No
Brasil, no campo de transporte rodoviário, a construção de novas estradas e
ampliação das existentes, deverá constituir-se em grande mercado. Empresas
privadas deverão participar desse processo, tanto na participação de em
construções, como na obtenção de concessão para a exploração de serviços de
controle e manutenção de rodovias. A administração de rodovias ganha
importância, uma vez que melhores soluções somente serão possíveis, quando
empresas puderem contar com uma infra-estrutura de gestão eficiente.
Assim, a empresa HITS – Holding Intelligent
Transportation System – apresentava como proposta, o efetivo controle do
tráfego em suas rodovias bem com o gerenciamento da mobilidade dessas rodovias.
Disposta
a participar desse contexto, escolheu-se o sistema de gestão do faturamento
pertencente ao módulo financeiro da gestão administrativa, para fins de aplicar
em seu desenvolvimento, as técnicas de pré-análise, análise, projeto,
implementação e testes, técnicas essas envolvidas no processo de
desenvolvimento de Projetos de Sistemas de Banco de Dados, bem como o de participar
dos processos de integração com Bancos de Dados Setoriais, dos processos de
integração com Banco de Dados Corporativos e no nível da Holding.
1.2. Contexto
O
mercado do transporte rodoviário, no Brasil, tem se expandido cada vez mais.
Com a crescente necessidade de otimização do uso de recursos e redução de
custos, buscou-se a implementação de tecnologias ITS, que são tecnologias de
informação e controle de tráfego, que buscam economizar tempo, aprimorar a
qualidade de vida, melhorar a produtividade, reduzir incidentes/acidentes de
tráfego, reduzir problemas de congestionamento e aumentar a capacidade das
vias.
A
empresa fictícia HITS - Holding Intelligent Transportation Systems, através da
implementação dessas tecnologias oferece serviços de transporte tais como:
fornecimento de Informações aos viajantes, gerenciamento de transporte público,
gerenciamento de transporte de cargas, controle de vias e tráfego e
gerenciamento de estacionamentos. Como parte integrante da HITS, há uma área
especializada em mobilidade rodoviária, responsável pelo controle das vias bem
como melhoramento do tráfego nas mesmas.
Dentro
de gestão da mobilidade rodoviária, existe uma sub-área chamada de "gestão
administrativa" que engloba diversos módulos, sendo um deles o controle
financeiro da empresa. Pertencente a esse módulo de controle financeiro,
existem outros processos financeiros distintos, a saber: gerência de contas a
pagar, contas a receber e faturamento. A gerência do faturamento não conta, no
presente momento, com um controle efetivo de títulos, o que tem interferido
negativamente na alta administração da empresa.
A
empresa precisa que sejam controlados e emitidos os títulos a
serem pagos em data determinada, pelos clientes, referentes aos serviços
prestados ou produtos adquiridos da HITS. Os
títulos são controlados e podem conter localizações bancárias
distintas, através das quais são selecionados na lista de pagamentos.
Cada
via do título, boleto ou fatura, é considerado um documento de
faturamento e possui uma numeração única. Documentos distintos de um
mesmo título podem conter diferentes datas de vencimento, valor e instruções de
juros e multas. O documento pode apresentar descontos de acordo
com o nível de conhecimento de cliente ou da fatura. Todo o controle é
realizado através da data base de pagamento, permitindo assim,
uma consulta eficaz nos dados históricos. As listas de faturamento
servem para prover uma visibilidade do faturamento da empresa.
1.3. Objetivos
1.3.1.
Definição do Problema
Dotar
a área de gestão Financeira da empresa HITS de um controle de seu faturamento,
de forma a proporcionar visibilidades apuradas da situação financeira da
empresa em relação aos pagamentos e recebimentos de títulos, visando a melhoria
da eficiência operacional e redução de
prejuízos monetários para a empresa.
1.3.2. Definição da Solução Escolhida
Desenvolver
um protótipo de aplicativo de Banco de Dados, em um prazo de seis meses, que permita
aos analistas da área financeira da empresa, visualizar a situação do
faturamento, o controle de documentos para pagamento de fornecedores e
recebimento de contas de clientes, inclusão de descontos e realização de
cálculos monetários sobre títulos, visando a melhoria da eficiência
operacional e redução de prejuízos monetários para a empresa.
1.3.3. Título
“Sistema
de Informações de Controle do Faturamento“ da empresa HITS (SI-FAT)
1.4. Especificação de Requisitos
O
protótipo de aplicativo de Banco de Dados SI-FAT, deverá ser capaz de prover:
1. Possibilitar a geração e emissão de
faturas.
2. Permitir a introdução de descontos
tanto ao nível de conhecimento quanto ao nível de fatura.
3. Permitir a visualização da freqüência
do faturamento.
4. Possibilitar a visualização da situação
da fatura.
5. Emitir a emissão de relatórios de
conferência
6. Calcular descontos e gastos com
produtos ou serviços consumidos.
7. Possibilitar o controle por tipo de
faturamento, sendo ele centralizado ou não.
8. Permitir a verificação antecipada do
valor mínimo para emissão da fatura.
9. Calcular taxas de juros e valores de
multas.
II.
DESENVOLVIMENTO
2.1. Aplicativo de Banco de Dados
2.1.1.
Justificativa de Utilização
O modelo de dados
escolhido pelo autor para utilização junto ao protótipo de aplicativo de banco
de dados proposto, foi o Modelo Relacional, pelos diversos motivos relatados a
seguir:
►Modelo utilizado por diversos setores no mercado atual;
►Modelo
flexível em definição de estrutura de dados;
►Modelo
de fácil implementação;
►Modelo
suportado ErWin e Interbase 6.0;
►Modelo
de fácil entendimento.
2.1.2.
Descrição dos principais componentes do Protótipo do seu Aplicativo de Banco
de Dados
Clique para visualizar: Dicionário de Dados do SIS-FAT
2.1.3.
Modelo Entidade-Relacionamento (MER)
2.1.4. A Evolução da 1aFN para a 2aFN e
3aFN
1FN:
Os atributos cliente,
produto, desconto, taxas, estão divididos de modo a atender o requisito atômico
desta forma normal.
FATURAMENTO {numero_fatura, codigo_faturamento,
numinscr_cliente,
nome_cliente, endereço_cliente, cidade_cliente, estado_cliente, cep_cliente,
tel_cliente, grupo_conhecimcliente,
limite_creditocliente, data_emissão, cod_produto, descri_produto, precounit_produto,
quantidade_produto, tipo_desconto, valor_desconto, descr_desconto, data_vencimento, data_recebimento,
valor, cod_banco,
nome_banco, agencia, nome_agencia, num_conta, tipo_faturamento, valormin_emissao,
frequencia_faturamento, taxa_juromes,
valor_juromora, valor_multa,
prazo_pagamento, instrucao} .
2FN:
A segunda forma normal foi
obtida eliminando-se os atributos que não se referiam à chave inteira, mas
somente a parte dela, e para tanto, precisou-se ajustar a dependência parcial
da chave, criando-se uma entidade que irá se referir ao Boleto ou a Fatura em
si, que foi chamada de TITULO, para
evitar futuros conflitos com a entidade FATURAMENTO, já pensando na fase de
Trigramação. Assim, também o nome da chave numero_fatura, foi
substituída por numero_titulo, e representa, portanto a mesma chave.
Note-se que, como exemplo, que o atributo valor, diz respeito ao valor do
TITULO, e somente a ele. Assim, o ajuste feito para duas entidades distintas,
elimina a dependência parcial da chave.
TITULO {numero_titulo, numinscr_cliente, nome_cliente, endereço_cliente, cidade_cliente,
estado_cliente, cep_cliente, tel_cliente,
grupo_conhecimcliente, limite_creditocliente,
data_emissão, cod_produto,
descri_produto, precounit_produto, quantidade_produto, tipo_desconto,
valor_desconto, descr_desconto, data_vencimento,
data_recebimento, valor_titulo, cod_banco,
nome_banco, agencia, nome_agencia, num_conta, taxa_juromes, valor_juromora,
valor_multa} .
FATURAMENTO
{codigo_faturamento, tipo_faturamento, valormin_emissao,
frequencia_faturamento, prazo_pagamento, instrucao}
.
3FN:
A terceira forma normal foi
obtida retirando-se os atributos não-chave que não dissesse respeito
diretamente à chave, criando-se para tanto outras entidades que pudessem
agrupá-las de maneira a atender os requisitos dessa forma. Assim, entidades
como CLIENTE, BANCO, PRODUTO, DESCONTO, precisaram ser criadas para permitir a
retirada de atributos do TITULO, que não se referiam diretamente a sua chave.
Da mesma forma, a entidade AGENCIA foi criada para atender ao requisito da 3FN
em relação ao BANCO.
CLIENTE {numinscr_cliente, nome_cliente, endereço_cliente,
cidade_cliente, estado_cliente, cep_cliente, tel_cliente,
grupo_conhecimcliente, limite_creditocliente}
.
BANCO {cod_banco,
nome_banco}
AGENCIA
{num_agencia, cod_banco, nome_agencia, num_conta}
DESCONTO
{tipo_desconto, valor_desconto, descr_desconto}
PRODUTO
{cod_produto, descri_produto, precounit_produto,
quantidade_produto}
FATURAMENTO
{cod_faturamento, tipo_faturamento, descricao_faturamento,
frequencia_faturamento, valormin_emissao, prazo_pagamento, instrucao}
.
TITULO
{numero_titulo, cod_faturamento, numinscr_cliente, tipo_desconto,
cod_produto, num_agencia , taxa_juromes, taxa_juromora, valor_multa,
data_emissao, data_vencimento, data_recebimento, valor_titulo, situacao_titulo} .
Trigramação
Aplicando-se as
técnicas de trigramação às tabelas obtidas na 3FN:
CLIENTE {cli_numinscr, cli_nome, cli_end, cli_cidade,
cli_estado, cli_cep, cli_fone,
cli_grpconhecim,
cli_limcred}
.
BANCO {ban_codigo, ban_nome}
AGENCIA
{age_num, ban_codigo, age_nome, age_numconta}
DESCONTO
{des_tipo, des_valor, des_descricao}
PRODUTO
{pro_codigo, pro_descricao, pro_precounit, pro_quantid}
FATURAMENTO {fat_codigo,
fat_tipo, fat_descricao, fat_frequencia, fat_valorminemissao, fat_prazopagto,
fat_instrucao}
TITULO
{tit_num, fat_codigo, cli_numinscr, des_tipo, pro_codigo,
age_num, tit_dataemissao , tit_juromes,tit_juromora, tit_valormulta,
tit_datavencim, tit_datarecebim, tit_valor, tit_situacao}.
2.1.5. A Implementação das Consultas 1,
2 e 3
As consultas ao Aplicativo de Banco de Dados Nível 0 –
Sistema de Informações de Controle do Faturamento (SI-FAT), foram realizadas
conforme apresentada a seguir.
2.1.7.1. Primeira
Consulta
1a. Consulta: Envolvendo uma relação do
SI-FAT: Relação dos títulos e o seu valor cuja situação de pagamento esteja
pendente.
2.1.7.2. Segunda
Consulta
2a. Consulta: Envolvendo duas relações do
SI-FAT: Relação dos nomes e telefone dos clientes cuja situação do título
esteja quitada.
2.1.7.3. Terceira
Consulta
3a. Consulta: Envolvendo três relações do
SI-FAT: Relação dos nomes dos clientes que adquiriam o produto `Ticket Pedágio’
e não efetuaram pagamento sendo que sua situação encontra-se pendente.
2.2.
Aplicativo de Banco de Dados Setoriais - Nivel 1 e 2
2.2.1. A extensão do Dicionário de Dados
para os elementos incorporados ao seu Protótipo
Para
as integrações dos Bancos de Dados Setoriais 1 e 2 foram adaptadas as entidades que eram comuns a todas os três
aplicativos. Assim, o aplicativo de Banco de Dados de Nível 1 – SIS-FIN, também
forma verificados os atributos afins e vários deles foram adaptados, As tabelas
cliente e fornecedor formaram uma só, pela verificação de vários atributos
afins, como nome, endereço, etc, sendo que um atributo de reconhecimento foi
criado, permitindo assim saber tratar-se de cadastro de um cliente ou de um
fornecedor. O SIS-FIN apresenta as seguintes entidades adaptadas dos três
aplicativos participantes:
|
TITULO |
BANCO |
|
TIPO_MOV |
AGENCIA |
|
MOVIMENTACAO |
SERVICO |
|
CLF_CLIFOR |
|
No Aplicativo de Banco
de Dados Setorial de Nível 2 – SIS-GAD, verificou-se que as tabelas fornecedor
e cliente deveria ser separadas, uma vez que os osutros aplicativos setoriais
trabalhavam de forma distina com elas de acordo com os seus requisitos. Também,
entidades afins foram aproveitadas, e atributos foram acrescentados de acordo
com essa adaptação realizada. As entidades, durante a integração de Nível 2,
formaram 65 tabelas.
2.2.2.
Aplicativo de Banco de Dados Setorial 1
A integração dos
Aplicativos de Banco de Dados: SI-FAT, SI-CAR e SI-CAP, resultou na formação do
Banco de Dados Setorial SIS-FIN – Sistema de Informações de Controle
Financeiro.
SI- CAP:
Sistema de Informações de Controle de Contas a Pagar
SI-CAR:
Sistema de Informações de Controle de Contas a Receber
SI-FAT:
Sistema de Informações de Controle do Faturamento
2.2.2.1. Sistema de Dicionário de Dados
(Nível 1)
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 Metadados. O Sistema de
Dicionário de Dados é comum aos Bancos de Dados Setoriais de Nível 1 e foi
resultado de sua integração.
Clique para visualizar: Sistema Dicionário de Dados de Nível 1
2.2.2.2.
Modelo Entidade-Relacionamento Setorial (Nìvel 1)
O
Modelo Entidade Relacionamento do Aplicativo de BD Setorial SIS-FIN foi
elaborado no software ErWin 4.0.
2.2.2.3.
Evolução da 1ª para a 3ª Forma Normal (Nível 1)
0 FN:
MOVIMENTACAO_FINANC {numero_movimentacao, descr_movimentacao, tipo_movimentacao,
cliente, data_emissao, valordesconto, situacao, valoremissao, valortaxas,
data_vencimento, valor_titulo, data_liquiidacao, banco,
frequencia_movimentacao, nome_fornecedor, servico}
1a.FN:
MOVIMENTACAO_FINANC {numero_titulo, codigo_movimentacao,
descr_movimentacao, tipo_movimentacao, numinscr_cliente, nome_cliente,
endereço_cliente, fone_cliente, data_emissao, valor_desconto, data_vencimento,
data_liquidacao, valor_titulo, cod_banco, nome_banco, nome_agencia, num_conta,
valor_emissao, frequencia_movimentacao, valor_taxas, instrucao cod_servico,
descr_servico, precounit_servico, quantidade_servico, codigo_fornecedor,
nome_fornecedor, end_fornecedor, fone_fornecedor, situacao_titulo}
2a.FN:
Separou-se
a entidade MOVIMENTACAO_FINANC em duas outras entidades, visando atender os
requisitos da 2a.FN. Assim, a entidade TITULO diz respeito ao
boleto ou título emitido para liquidação, possui agora um identificador numero_fatura,
a ele pertinentes. A MOVIMENTACAO passa a conter atributos como o tipo de
movimentação, o valor mínimo para emissão de títulos, sua freqüência, etc.
TITULO {numero_titulo,
codigo_movim, numinscr_cliente, nome_cliente, endereço_cliente,
fone_cliente, data_emissao,
valor_desconto, data_vencimento, data_liquidacao, valor_titulo, cod_banco,
nome_banco, nome_agencia, num_conta, valor_taxas, cod_servico, descr_servico,
precounit_servico, quantidade_servico, codigo_fornecedor, nome_fornecedor,
end_fornecedor, fone_fornecedor, situacao_titulo}
MOVIMENTACAO {codigo_movim, tipo_movimentacao, descr_movimentacao,
valor_emissao, frequencia_movimentacao, instrucao}.
3a.FN:
A 3a.Forma Norma é apresentada já aplicando-se às tabelas, as regras de
Trigramação.
As entidades Cliente e Fornecedor foram representadas em uma somente
(CLF_CLIFOR), por conter dados semelhantes. É possível saber tratar-se de
cliente ou fornecedor através do tipo de movimentação.
TITULO {tit_num, tit_descr, tit_dtemissao, tit_valor, tit_valortaxas,
tit_dtvencimento, tit_dtliquidacao, tit_situacao, tit_valordesconto,
clf_numinscr, ser_codigo, tip_movim, age_cod}
.
TIPO_MOV {tip_movim, tip_descrmovim}
MOVIMENTACAO {mov_cod, tit_num, mov_data,
mov_instrução, mov_valoremissao, mov_frequencia}
CLF_CLIFOR {clf_numinscr,
clf_nome, clf_end, clf_fone}
BANCO {ban_cod,
ban_descr}
AGENCIA {age_codigo,
ban_cod, age_descr, age_numconta}
SERVICO {ser_codigo, ser_descr,
ser_precounit, ser_qtd}
2.2.2.4.. Massa de Dados (Nível
1 e Nível 2)
As tabelas foram
criadas e os dados inseridos no SGBD Interbase 6.0. O
Script de criação das tabelas e seus relacionamentos para este 1o.
Nível de integração, bem como a Massa de Dados, foram feitas juntamente com as
do 2º Nível de Integração, e portanto seu código será o mesmo tanto para os
Níveis 1 e 2 - Banco de Dados Setoriais 1 e 2.
Clique para visualizar: Script de Criação das Tabelas do Banco de Dados Setoriais 1
e 2
2.2.2.5. Implementação da 4a.
Consulta
2.2.2.5.1. Quarta Consulta
4a. Consulta:
Envolvendo uma relação do seu Aplicativo de BD e duas relações de um Aplicativo
de BD diferente dentro do Aplicativo de BD Setorial.
Pretende-se retornar as movimentações
financeiras:
Dados a serem retornados: cliente ou fornecedor,
data, espécie, valor
Critérios: movimentações ocorridas no mês de maio
de 2003
Ordenação: Pagamentos, recebimentos e
faturamentos.
SELECT TIT.CLF_MUNISCR, CLF.CLF_NOME, MOV.MOV_DATA,
TIT.TIP_MOV, TIT.TIT_VALOR
FROM MOVIMENTACAO MOV,
CLF_CLIFOR CLF, TITULO TIT
WHERE CLF.CLF_NUMINSCR =
TIT.CLF_NUMINSCR
AND TIT.TIT_NUM = MOV.TIT_NUM
AND MOV.MOV_DATA BETWEEN
('01/05/2003') AND '31/05/2003')
2.2.3.
Aplicativo de Banco de Dados Setorial 2
Através da integração
dos Aplicativos de Banco de Dados Setoriais 1, formou-se o Aplicativo de Banco
de Dados Setorial de Nível 2 - SIS-GAD – Sistema de Informações de
Gestão Administrativa. Participaram desse processo de integração os seguintes
aplicativos de Banco de Dados Setoriais: SIS-FIN, SIS-CON, SIS-REC e SIS-FRO,
que por sua vez são resultantes dos sistemas conforme descritos a seguir e cuja
composição pode ser observada no quadro mais adiante.
SI-CAP:
Sistema de Informações de Controle de Contas a Pagar
SI-CAR: Sistema de
Informações de Controle de Contas a Receber
SI-FAT: Sistema de
Informações de Controle do Faturamento
SI-ORC: Sistema de Informação de Gerenciamento de Orçamento
SI-CTR: Sistema de Informação Gerenciador de Contratos
SI-OSV: Sistema de Informação de Controle de Ordem de Serviço
SI-GRH: Sistema de Informação para Gerência de
Informações de Recursos Humanos
SI-GRF: Sistema de Informação para Gerência Recursos Físicos
SI-LOA: Sistema de Informação para Gerência de Locais de Apoio
SI-TRE: Sistema de Informação para Gerência Recursos Terceirizados
SI-MFR: Sistema de Informação de Gerência de Manutenção de Frota
SI-GFR: Sistema de Informação de Controle e Gerência da Frota
SI-CFR: Sistema de Informação de Gerência de Custos com Frota
SI-PMC: Sistema de Informação de Planejamento de Custos e Manutenção de
Veículos
Quadro de formação do Sistema de Informação de Gestão
Administrativa:
2.2.3.1.. Dicionário de Dados (Nível 2)
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 Metadados. O Sistema de
Dicionário de Dados é comum aos Bancos de Dados Setoriais de Nível 1 e foi
resultado de sua integração.
Clique para visualizar: Sistema Dicionário de Dados de Nível 2
2.2.3.2. Modelo Entidade-Relacionamento Setorial
(Nível 2)
O
Modelo Entidade Relacionamento do Aplicativo de BD Setorial SIS-FIN foi
elaborado no software ErWin 4.0.
Clique
sobre a figura para ampliá-la:
2.2.3.3.
Tabelas na 3ª Forma Normal (Nível 2)
FORNECEDOR_RF (for_cnpj, for_nome, for_endereco,
for_contato, for_tipo)
CONTRATO (ctt_codigo, ctt_data, ctt_duracao, ctt_valor, ctt_descr)
CONTRATO_FORNECEDOR (ctt_codigo, for_cnpj, cof_observacao)
LOCAL_APOIO (loa_codigo, loa_nome, loa_cidade, loa_gerente)
RECURSO_FISICO (rcf_codigo, rcf_descricao, rcf_tipo, loa_codigo)
RF_COMPRADO (rcf_codigo, ctt_codigo, rfc_preco, rfc_quantidade)
ITEM_MANUTENCAO (itm_codigo, itm_kmtroca, itm_custo, itm_descricao)
ESPEC (esp_modelo, esp_marca, esp_dimensoes, esp_fabricante, esp_tipo,
esp_capacidade)
RECURSO_PERMANETE (rcf_codigo, rpe_patrimonio, rpe_utilidade)
VEICULO (rcf_codigo, vei_placa, vei_km_atual, vei_ano, vei_tipo, vei_chassis,
esp_modelo)
PLANEJAMENTO (pla_numero, pla_kmproximo, pla_quantidade, itm_codigo,
pla_kmanterior, rcf_codigo)
EQUIPAMENTO (rcf_codigo, equ_estado_conservacao, equ_observacao)
BANCO (ban_cod, ban_descr)
AGENCIA (age_cod, ban_cod, age_descr, age_numconta)
RH (rch_codigo, rch_nome, rch_endereco, rch_adm, rch_documentacao, loa_codigo,
rch_cargo)
FOLHA_PAGAMENTO (rch_codigo, fop_data, fop_salario, fop_hora_extra, fop_premio,
age_cod)
MERCADORIA (mer_cod, mer_descricao, mer_peso)
SOLICITACAO (sol_cod, sol descr, sol_cargesp, sol_descarga, sol_txurg, sol_km,
sol_pesodim)
CLIENTE (cli_cod, cli_nome, cli_end, cli_doc)
SOL_CLI (cli_cod, sol_cod, scl_data)
CONTRATO_CLIENTE (ctt_codigo, cli_cod, sol_cod)
MISSAO (mis_codigo, mis_tempo, mis_data_fim, mis_custo_km, mis_destino,
ctt_codigo, mer_cod)
ATENDIMENTO (atd_codigo, atd_data_inicio, atd_hora_fim, atd_hora_inicio,
atd_data_fim, atd_status, mis_codigo)
RF_ATENDIMENTO (atd_codigo, rcf_codigo, rfa_quantidade, rfa_data_saida,
rfa_data_chegada)
RH_ATENDIMENTO (atd_codigo, rch_codigo, rha_tarefa, rca_desempenho)
TIPO_QUALIFICACAO (tqu_codigo, tqu_area, tqu_nivel)
QUALIFICACAO (rch_codigo, tqu_codigo, qua_local, qua_periodo)
TREINAMENTO (ctt_codigo, tre_descricao, tre_pre_requisito, tre_validade,
tre_valor)
RH_TREINAMENTO (rch_codigo, ctt_codigo, rht_data)
ORDEM_SERVICO (ors_numero, ors_entrada, ors_execucao, mis_codigo,
ors_descricao)
RH_MISSAO (rch_codigo, ors_numero, rhm_tarefa, rhm_desempenho)
ALOCACAO_RF (rcf_codigo, ors_numero, alo_quantidade, alo_km_saida,
alo_km_chegada)
TIPOCUSTO (tip_codigo, tip_especie, tip_nome)
CUSTO (cto_codigo, tip_codigo, cto_quantidade, cto_data, cto_valor, rcf_codigo)
DOCUMENTO (doc_num, doc_ano_vigencia, doc_vencimento, doc_pagamento, doc_tipo,
rcf_codigo)
MANUTENCAO (ctt_codigo, man_grau, man_reparo, man_datafim, man_descricao,
man_valor, rcf_codigo)
MOVIMENTACAO (mov_cod, tit_num, mov_data, mov_instrucao, mov_valoremissao,
mov_frequencia)
MATERIAL_CONSUMO (rcf_codigo, mtc_quantidade, mtc_observacao)
2.2.3.4. Implementação de 4a
e 5a Consultas
2.2.3.4.1. Quinta Consulta
Pretende-se efetuar um balancete simples da
empresa:
Dados a serem retornados: resultado do mês de
maio de 2003, ou seja, o valor decorrente da somatória dos vencimentos menos a
somatória das despesas.
Também deve trazer o cliente para o qual a
empresa mais vendeu no mês e o fornecedor do qual esta mais comprou no período.
Critérios: movimentações ocorridas no mês de maio
de 2003
Ordenação: sem ordenação.
SELECT FAT.VALOR
FATURADO, PAG.VALOR GASTO
FROM (SELECT
SUM(TIT.TIT_VALOR) VALOR
FROM TITULO TIT,
MOVIMENTACAO MOV
WHERE MOV.TIT_NUM =
TIT.TIT_NUM
AND MOV.MOV_DATA BETWEEN
('01/05/2003') AND '31/05/2003')
AND TIT.TIP_MOV = 1) FAT,
(SELECT
SUM(TIT.TIT_VALOR) VALOR
FROM TITULO TIT,
MOVIMENTACAO MOV
WHERE MOV.TIT_NUM =
TIT.TIT_NUM
AND MOV.MOV_DATA BETWEEN
('01/05/2003') AND '31/05/2003')
AND TIT.TIP_MOV = 1) PAG
2.2.3.4.2. Sexta Consulta
Pretende-se efetuar uma pesquisa em torno dos
serviços realizados:
Dados a serem retornados: Valores totais dos
gastos com
1 - manutenções
efetuadas nos veículos
2 - compras de recursos
físicos
3 - efetivação das
missões
4 - treinamento de
recursos humanos
Critérios: movimentações ocorridas no mês de maio
de 2003 que estejam embasadas num contrato
Ordenação: manutenções, compras, missões e
treinamentos.
SELECT MAN.VALOR MANUTENCAO, CMP.VALOR
REC_FISICOS, TRN.VALOR TREINAMENTO, MIS.VALOR MISSOES
FROM (SELECT COUNT(TIT.TIT_VALOR) VALOR
FROM TITULO TIT,
CONTRATO CNT, MANUTENCAO MNT, MOVIMENTACAO MOV
WHERE TIT.CTT_NUM = CNT.CTT_NUM
AND MNT.CTT_NUM = CNT.CTT_NUM
AND MOV.TIT_NUM = TIT.TIT_NUM
AND MOV.MOV_DATA BETWEEN ('01/05/2003') AND '31/05/2003')) MAN,
(SELECT COUNT(TIT.TIT_VALOR) VALOR
FROM TITULO TIT,
CONTRATO CNT, COMPRA_RF CRF, MOVIMENTACAO MOV
WHERE TIT.CTT_NUM = CNT.CTT_NUM
AND CRF.CTT_NUM = CNT.CTT_NUM
AND MOV.TIT_NUM = TIT.TIT_NUM
AND MOV.MOV_DATA BETWEEN ('01/05/2003') AND '31/05/2003')) CMP,
(SELECT COUNT(TIT.TIT_VALOR) VALOR
FROM TITULO TIT,
CONTRATO CNT, TREINAMENTO TRE, MOVIMENTACAO MOV
WHERE TIT.CTT_NUM = CNT.CTT_NUM
AND TRE.CTT_NUM = CNT.CTT_NUM
AND MOV.TIT_NUM = TIT.TIT_NUM
AND MOV.MOV_DATA BETWEEN ('01/05/2003') AND '31/05/2003')) TRN,
(SELECT COUNT(TIT.TIT_VALOR) VALOR
FROM TITULO TIT,
CONTRATO CNT, MISSAO MSA, MOVIMENTACAO MOV
WHERE TIT.CTT_NUM = CNT.CTT_NUM
AND MSA.CTT_NUM = CNT.CTT_NUM
AND MOV.TIT_NUM =
TIT.TIT_NUM
AND MOV.MOV_DATA BETWEEN ('01/05/2003') AND '31/05/2003')) MIS
2.3.
Aplicativo de Banco de Dados Corporativo - Nível 3
Através da integração
dos Aplicativos de Banco de Dados Setoriais, formou-se o Aplicativo de Banco de
Dados Corporativo SIS-GMR – Sistema de Informações de Gestão
Administrativa. Participaram desse processo de integração os seguintes
aplicativos de Banco de Dados Setoriais: SIS-GAD, SIS-GQT e SIS-GEX, conforme
descrição a seguir:
SIS-GAD: Sistema de
Informação de Gestão Administrativa
SIS-GQT: sistema de
Informação de Gestão da Qualidade Total
SIS-GEX: Sistema de
Informação de Gestão de Missões
2.3.1. Sistema de
Dicionário de Dados (Nível 3)
O Dicionário de Dados e
o Diretório de Dados foram gerados automaticamente através do ERwin 4.0.
2.3.1.1. Dicionário
de Dados
Segurança e Privacidade:
Todos os operadores do sistema podem acessar as tabelas e
realizar atualizações. O Dicionário de Dados e o Diretório de Dados foi gerado
automaticamente através do ErWin 4.0
2.3.1.2. Dicionário
de Recurso de Dados
O protótipo do
aplicativo foi desenvolvido utilizando-se um computador Pentium 48 MB de RAM e
8 GB de HD, sendo seu Alias: DB-GMR
2.3.1.3. Dicionário
de Metadados
Para visualizar o MER
do SIS-GMR: Clique Aqui
Clique para visualizar: Sistema Dicionário de Dados de Nível 3
2.3.2. Modelo Entidade-Relacionamento Corporativo
(Nível 3)
O
Modelo Entidade Relacionamento do Aplicativo de BD Setorial SIS-FIN foi
elaborado no software ErWin 4.0.
Clique
para visualizar: Modelo Entidade-Relacionamento – Nível 3 – SIS-GMR
2.3.3.
Tabelas na 3a.Forma Normal do Banco de Dados Corporativo (Nível 3)
Na diversas reuniões com os integrantes e através de troca
de e-mails para atualização dos arquivos do ERWin, Interbase e massa de dados,
chegou-se a conclusão de que as entidades que formavam o elo de ligação entre
os sistemas foram RH, RECURSO_FISICO, e MISSAO. Várias tabelas deixaram de
existir, pois os dados nelas contidos podem agora ser encontrados em outras,
evitando redundâncias. As 85 entidades resultantes foram inseridas,
relacionadas e alimentadas no Interbase para possibilitar a realização das
consultas solicitada. A parttir da aplicação da
Técnica de Normalização, o BDC SIS-GMR está normalizado na 3 FN, e as 85
(oitenta e cinco) Entidades e correspondentes atributos são descritos a seguir:
ATENDIMENTO (atd_codigo,
ctt_codigo, atd_dpt, srv_codigo, atd_data, atd_situacao, cli_codigo,
rch_codigo)
SOLICITACAO (sol_cod, sol_descr, sol_cargesp, sol_descarga,
sol_txurg, sol_km, sol_pesodim)
SOL_CLI (cli_codigo, sol_cod, scl_data)
CONTRATO (ctt_codigo, ctt_data, ctt_duracao, ctt_valor,
ctt_descr)
CONTRATO_CLIENTE (ctt_codigo, sol_cod, cli_codigo, atd_codigo)
FASE (fas_id, fas_desc, fas_nome, cer_id, fas_rodovia,
fas_tempoestimado, fas_tempodescanso)
AREA (are_id, are_nome, are_velmax, are_status)
PONTO (pon_id, pon_nome, pon_coord_x, pon_coord_y, are_id)
LOCAL_APOIO (loa_codigo, loa_nome, loa_cidade, loa_gerente)
RH (rch_codigo, rch_nome, rch_endereco, rch_adm, loa_codigo,
rch_cargo, rch_cpf, rch_rg, rch_telefone)
PREFERENCIAL (pre_id, pre_descricao, pre_nome)
CLIENTE (cli_codigo, cli_nome, cli_rbc, cli_cidade, cli_telefone,
cli_email, cli_sen, cli_cpfcnpj, cli_endereco, cli_doc, pre_id)
SERVICO (srv_codigo, srv_tipo, srv_descricao, srv_valor)
CONTATO (ctt_codigo, ctt_nome, ctt_telefone, ctt_email)
MERCADORIA (mer_cod, mer_descricao, mer_peso)
ROTA (rot_id, rot_descricao, rot_nome)
MISSAO (mis_id, mis_inicio, mis_termino, rot_id, mer_cod,
ctt_codigo)
CTRC (ctr_num, mis_id, ctr_datahora, ctr_status, ctr_operador,
crt_vr_fatura, con_dta_previsto_entrega)
HISTORICO (his_id, his_assunto, his_mensagem, his_datahora,
his_tipo, mis_id, fun_id)
TRANSPORTE (tra_id, tra_datahora, tra_velmed, mis_id, pon_id)
CLIENTE (cli_cnpj, cli_nome, cli_endereco, cli_telefone, pon_id)
CARGA_VIAGEM (car_id, car_pos_veiculo, car_datahora_embarque,
car_datahora_desembarque, mis_id)
DEPOSITO (dep_id, dep_nome, dep_desc)
LOCAL_DEPOSITO (loc_id, loc_apto, dep_id)
LOTE (lot_id, lot_volume, lot_desc, loc_id, cli_cnpj,
car_id)
PRODUTO (pro_codigo, pro_nome, pro_unidade, pro_tipo)
QTDE_PROD (qtd_id, pro_codigo, qtd_qtde_prod, qtd_preco, lot_id)
PALETE (pal_codigo, pal_tipo, pal_comprimento_pes, pal_localizacao,
pal_capacidade_m3)
EXPEDICAO (exp_codigo, cli_cnpj, pal_codigo, exp_dt_prevista,
exp_dt_expedicao)
ITEM_EXPEDICAO (exp_codigo, ite_item, pro_codigo,
ite_qtde)
ESPEC (esp_modelo, esp_fabricante, esp_tipo, esp_capacidade,
mod_pontencia, mod_largura, mod_comprimento)
RECURSO_FISICO (rcf_codigo, rcf_descricao, rcf_tipo, loa_codigo)
RECURSO_PERMANETE (rcf_codigo, rpe_patrimonio, rpe_utilidade)
VEICULO (rcf_codigo, vei_placa, vei_km_atual, vei_ano, vei_tipo,
vei_chassis, esp_modelo, vei_cor)
PATIO (pat_codigo, pat_localizacao, pat_quantidade)
PRIORIDADE_DESCARGA (pri_des_cod, pri_des_grau,
pri_des_descricao)
PORTARIA (por_numero, pat_codigo, pri_des_cod,
por_entrada, por_saida, rcf_codigo)
PEDIDO (ped_cod, ped_und_orig, ped_dt_sai, ped_rota_merc,
ped_loc_vol, ped_dt_lib, rcf_codigo)
ITEM_PEDIDO (ped_cod, itm_cod, pro_codigo, itm_qtde,
itm_und_dest, itm_dt_cheg)
DEVOLUCAO (dev_numero, dev_data, dev_devolvedor, dev_recebedor)
ITEM_DEVOLUCAO (dev_numero, itd_item, pro_codigo,
itd_qtde, itd_obs)
RECEBIMENTO (rec_numero, rec_data, rec_fornecedor, rec_recebedor)
ITEM_RECEBIMENTO (rec_numero, itr_item, pro_codigo,
itr_qtde, itr_obs)
DESCARGA (dsc_codigo, dsc_data, dsc_responsavel, rcf_codigo)
ITEM_DESCARGA (dsc_codigo, idc_item, pro_codigo, idc_qtde,
idc_valor_unit)
PERDA (per_numero, per_data, pro_codigo, per_qtde, per_motivo)
DOACAO (doa_numero, doa_data, pro_codigo, doa_qtde, doa_motivo)
CARGA (crg_codigo, crg_data, crg_responsavel, rcf_codigo)
ITEM_CARGA (itc_item, crg_codigo, itc_qtde,
itc_valor_unit, pro_codigo)
AUDITORIA (aud_codigo, aud_danos, aud_atent, aud_atcol, aud_sin,
rch_codigo, aud_sat)
MARKETING (mar_id, mar_des, mar_nome)
CAMPANHA (cam_id, cam_mes, cam_nom, mar_id)
COTACAO (cot_id, cot_produto, cot_area_volume, cot_qtde_volume,
cot_vlr_frete, cot_peso_unit, cot_uf_origem, cot_uf_destino, mis_id)
FATOR (fat_codigo, fat_primario, fat_secundario)
OCORRENCIA (tra_id, oco_data, oco_hora, fat_codigo,
oco_descricao, fas_id)
INDENIZACAO (ind_codigo, oco_data, ind_tipo, oco_hora, ind_data,
tra_id)
MAR_CLI (pre_id, mar_id)
PAGAMENTO (pag_cod, pag_tipo, ind_codigo, pag_vlr)
FASROT (rot_id, fas_id, frt_sequencia)
FASPON (pon_id, fas_id, fpn_sequencia)
BANCO (ban_cod, ban_descr)
AGENCIA (age_cod, ban_cod, age_descr, age_numconta)
ORDEM_SERVICO (ors_numero, ors_entrada, ors_execucao, mis_id,
ors_descricao)
ALOCACAO_RF (rcf_codigo, ors_numero, alo_quantidade,
arf_km_saida, arf_km_chegada)
RH_MISSAO (rch_codigo, ors_numero, arh_tarefa,
rhm_desempenho)
ATENDIMENTO_URGENCIA (atd_codigo, atd_data_inicio, atd_hora_fim,
atd_hora_inicio, atd_data_fim, atd_status, mis_id)
FORNECEDOR_RF (for_cnpj, for_nome, for_endereco, for_contato,
for_tipo)
CONTRATO_FORNECEDOR (ctt_codigo, for_cnpj, cof_observacao)
RF_COMPRADO (rcf_codigo, ctt_codigo, rfc_preco,
rfc_quantidade)
TIPOCUSTO (tip_codigo, tip_especie, tip_nome, tip_ultimocusto,
tip_kmtroca)
MANUTENCAO (ctt_codigo, man_grau, man_reparo, man_datafim,
man_descricao, man_valor_total,
man_km, rcf_codigo)
CUSTO (ctt_codigo, tip_codigo, cto_quantidade,
cto_valor_unit)
DOCUMENTO (doc_num, doc_ano_vigencia, doc_vencimento,
doc_pagamento, doc_tipo, rcf_codigo)
EQUIPAMENTO (rcf_codigo, equ_estado_conservacao, equ_observacao)
FOLHA_PAGAMENTO (rch_codigo, fop_data, fop_salario,
fop_hora_extra, fop_premio, age_cod)
MATERIAL_CONSUMO (rcf_codigo, mtc_quantidade, mtc_observacao)
TITULO (tit_num, tit_descr, tit_dtemissao, tit_valor,
tit_valortaxas, tit_dtvencimento, tit_dtliquidacao, tit_situacao,
tit_valordesconto, ctt_codigo, age_cod)
MOVIMENTACAO (mov_cod, tit_num, mov_data, mov_instrucao, mov_valoremissao,
mov_frequencia, mov_tipo)
PLANEJAMENTO (pla_numero, pla_kmproximo, pla_quantidade,
rcf_codigo, tip_codigo)
TIPO_QUALIFICACAO (tqu_codigo, tqu_area, tqu_nivel)
QUALIFICACAO (rch_codigo, tqu_codigo, qua_local,
qua_periodo)
RF_ATENDIMENTO (atd_codigo, rcf_codigo, rfa_quantidade,
rfa_data_saida, rfa_data_chegada)
RH_ATENDIMENTO (atd_codigo, rch_codigo, rha_tarefa,
rca_desempenho)
TREINAMENTO (ctt_codigo, tre_descricao, tre_pre_requisito,
tre_validade, tre_valor)
RH_TREINAMENTO (rch_codigo, ctt_codigo, rht_data)
MOTORISTA (rch_codigo, mot_habilitacao, mot_nascimento,
mot_experiencia)
2.3.4 -Implementação e Inserção da Massa de Dados
Implementação da 3ª FN
do Modelo de Dados Relacional do Protótipo SIS-GMR no InterBase 6.0
A
seguir é apresentada figura referente à implementação das oitenta e cinco (85)
tabelas, relativas ao protótipo SIS-GMR, criadas no InterBase 6.0. Encontram-se
também disponíveis o script de criação das tabelas e a massa de dados inserida.
·
SQL - Clique para
visualizar: Script de Criação das Tabelas do NI3
·
SQL – Clique para
visualizar: Inserção da Massa de Dados do NI3
2.3.4. Implementação
das 7a. e 8a. Consultas (Nível 3)
2.3.4.1. Sétima
Consulta
Pretende-se selecionar
o número do título pago pelo serviço, código do contrato e a mensagem
contida no histórico relativos à missão que solicitou atendimento
de emergência no dia "12/05/01":
É importante perceber
que a tabela TITULO pertence originalmente ao aplicativo SIS-FAT.
SELECT TITULO.tit_num, MISSAO.ctt_codigo,
HISTORICO.his_mensagem
FROM ATENDIMENTO,
MISSAO, HISTORICO, TITULO
WHERE ATENDIMENTO.atd_data_inicio
= '12/05/01' and
MISSAO.mis_id = ATENDIMENTO.mis_id and
HISTORICO.mis_id = MISSAO.mis_id and
TITULO.ctt_codigo = MISSAO.ctt_codigo;
2.3.4.1. Oitava
Consulta
Pretende-se selecionar
o nome e telefone do cliente contratante da missão solicitou atendimento
de emergência no dia "12/05/01":
É importante salientar que a tabela CLIENTE
pertence originalmente ao Aplicativo SIS-FAT.
SELECT DISTINCT
(cli_nome), cli_telefone
FROM ATENDIMENTO,
MISSAO, HISTORICO, ATENDIMENTO_TELEFONICO, CLIENTE, CONTRATO_CLIENTE
WHERE
ATENDIMENTO.atd_data_inicio = '12/05/01' and
MISSAO.mis_id = ATENDIMENTO.mis_id and
MISSAO.ctt_codigo = CONTRATO_CLIENTE.ctt_codigo and
CONTRATO_CLIENTE.afn_codigo = ATENDIMENTO_TELEFONICO.afn_codigo and
CLIENTE.cli_codigo = ATENDIMENTO_TELEFONICO.cli_codigo;
2.4. Simulação de Jogos de Empresa
Banco de Dados Hoding:
Nível 4 – HITS – Holding Intelligent Transportation System
2.4.1. Integração
2.4.1.1.
Re-Contextualização
Um dos maiores desafios
encontrados pelos administradores de Empresas atuantes em transporte rodoviário
tem sido a busca por Soluções Tecnológicas de Apoio à Gestão de Tráfego e
Mobilidade Rodoviária. Organizações como a Holding Intelligent Transportation
System – HITS, necessitam de um controle mais eficiente para gerenciar
planejamento de missões da frota de veículos, coordenar a execução dessas e
controlar carga e descarga de produtos. Para isso as Empresas necessitam de um
sistema capaz de propiciar um gerenciamento de sua frota, permitindo planejar e
executar as missões de maneira mais eficiente.
Na atualidade, existe uma demanda pela otimização do processo
de roteamento de veículos de transporte rodoviário. Para tanto, faz-se
necessária uma logística adequada para realização do controle de rotas, procurando
soluções inteligentes que possibilitem uma roteirização ótima de seus veículos,
oferecendo aos usuários serviços de suporte de alta qualidade.
A Empresa HITS requer um mecanismo de armazenamento e
controle dos dados coletados no processo de automação de rodovias, buscando uma
melhor coordenação das ações por ela realizadas. Em face disso, a organização
deseja obter um sistema que gerencie toda a logística envolvida na supervisão
das estradas e no funcionamento das praças de pedágio, visando monitorar de
modo mais efetivo as atividades realizadas pelo seus recursos físicos e
humanos.
Dentro deste contexto, a administração da Empresa HITS
precisa contar com uma sistemática para auxiliar a gerência administrativa no
controle: a) dos contratos firmados entre Empresa e Cliente; b) da movimentação
financeira; e c) dos recursos envolvidos em suas missões, sejam estes físicos,
humanos ou locais de apoio.
Tais medidas trarão benefícios num âmbito supervisional
tornando possível identificar anomalias, reduzir a probabilidade de fraudes e
estimar previsões de investimentos orçamentários, garantindo assim padrões
internacionais de qualidade na prestação de serviços para Tráfego e Mobilidade
Rodoviária. Em vista disso, almeja-se, até o final do 1º semestre de 2003,
desenvolver um Protótipo de Banco de Dados com o objetivo de integrar de forma
inteligente os sistemas de transporte das empresas do setor rodoviário.
2.4.2.2.
Re-Objetivação
2.4.1.2.1.Re-Definição
do Problema
Efeitos
Adversos – (O que
está errado?)
Ea1 – ”Não é possível
planejar, de maneira eficiente, as missões de transporte rodoviário envolvendo
frotas de veículos e executá-las de maneira coordenada”;
Ea2 – “Não é possível
controlar os serviços de carga e descarga de produtos”;
Ea3 – “Não há uma logística
adequada que possibilite uma roteirização ótima de seus
veículos”.
Ea4 – “Não é possível
armazenar e controlar dados coletados no processo de automação de rodovias”.
Ea5 – “Não há um
planejamento financeiro, facilitando a procura por dados de movimentações
financeiras”;
Ea6 – “Não é possível gerenciar adequadamente os locais de apoio, e seus
atendimentos às chamadas de urgência”; e
Ea7 – “Não é possível gerenciar adequadamente, recursos físicos e humanos da
HITS e sua alocação às missões”.
Causas
– (Por que está errado?)
C1 – “Não há um controle
eficiente para gerenciar planejamento e execução de missões da frota de
veículos”;
C2 – “Não há uma
sistemática eficaz de controle de carga e descarga de produtos”;
C3 – “Não há um processo
de roteamento de veículos que possibilite uma roteirização ótima de seus
veículos”;
C4 – “Inexistência de um
sistema administrativo adequado para a gestão de contratos e de recursos
físicos, humanos e financeiros da empresa”;
C5 – “Não há um sistema para gerenciar adequadamente os locais de apoio e o
atendimento às chamadas de urgência”.
Tarefa
– (O que, onde e quando se deseja
realizar?)
“Dotar
setores afins da Empresa HITS, de um Sistema Aplicativo de Banco de Dados
adequado para o armazenamento e recuperação de informações, até o final do 1º
Semestre de 2003”.
Propósito
– (Para que deseja-se realizar tal
tarefa?)
“Visando
gerenciar de maneira mais eficiente o planejamento e execução de missões,
permitir maior eficiência no controle de carga e descarga de produtos, possibilitar
uma roteirização ótima de seus veículos, bem como permitir armazenamento e
controle dos dados coletados no processo de automação de rodovias, permitir um
gerenciamento administrativo de recursos físicos, humanos e financeiros mais
eficiente, garantir padrões internacionais de qualidade na prestação de
serviços, reduzir o desperdício de recursos envolvidos, o tempo de atendimento
às chamadas de urgência e gastos desnecessários com manutenção de recursos
físicos”.
2.4.1.2.2. Re-
Definição do Problema
O
problema consiste em “Dotar setores
afins da Empresa HITS, de um Sistema Aplicativo de Banco de Dados adequado ao
armazenamento e recuperação de informações, até o final do 1º Semestre de 2003,
visando gerenciar de maneira mais eficiente o planejamento e execução de
missões, permitir maior eficiência no controle de carga e descarga de produtos,
possibilitar uma roteirização ótima de seus veículos, bem como permitir
armazenamento e controle dos dados coletados no processo de automação de
rodovias, permitir um gerenciamento administrativo de recursos físicos, humanos
e financeiros mais eficiente, garantir padrões internacionais de qualidade na
prestação de serviços, reduzir o desperdício de recursos envolvidos, o tempo de
atendimento às chamadas de urgência e gastos desnecessários com manutenção de
recursos físicos”.
2.4.1.2.3. Re-Definição
da Solução
Identificação das Alternativas de
Soluções Possíveis – ASPs
Dentre as Alternativas de Soluções Possíveis
- ASP identificadas, destacam-se::
1.
ASP - I: Comprar um
aplicativo de banco de dados, desenvolvido por terceiros, que remova
parcialmente os efeitos ocasionados pelas causas descritas anteriormente;
2.
ASP - II: Encomendar, à
uma empresa do ramo, o desenvolvimento de um aplicativo de banco de dados, que
propicie às empresas de transporte rodoviário envolvendo frotas de veículos, um
melhor controle de transporte de cargas; e
3.
ASP - III:
Desenvolver um Sistema Aplicativo de Banco de Dados adequado ao armazenamento e
recuperação de informações, visando gerenciar de maneira mais eficiente o
planejamento e execução de missões, permitir maior eficiência no controle de
carga e descarga de produtos, possibilitar uma roteirização ótima de seus
veículos, bem como permitir armazenamento e controle dos dados coletados no processo
de automação de rodovias, permitir um gerenciamento administrativo de recursos
físicos, humanos e financeiros mais eficiente, garantir padrões internacionais
de qualidade na prestação de serviços, reduzir o desperdício de recursos
envolvidos, o tempo de atendimento às chamadas de urgência e gastos
desnecessários com manutenção de recursos físicos.
Análise de Adequabilidade
Praticabilidade e Aceitabilidade (APA)
Após uma análise dos fatores de adequabilidade,
praticabilidade e aceitabilidade, chega-se a seguinte conclusão:
1.
A ASP-I apresenta-se
como uma alternativa de solução parcialmente adequada, no entanto, impraticável
e inaceitável pois não atenderia as necessidades da empresa;
2.
A ASP-II
apresenta-se como uma alternativa de solução parcialmente praticável,
inadequada pois acarreta em custos muito altos, entretanto, inaceitável; e
3.
A ASP-III
é adequada, é praticável e aceitável.
Enunciado da Alternativa de Solução
Escolhida (ASE)
A alternativa de solução escolhida
consiste em “Desenvolver um Sistema Aplicativo de Banco de Dados adequado ao
armazenamento e recuperação de informações de interesse dos setores afins da
Empresa envolvendo frotas de veículos, visando gerenciar de maneira mais
eficiente o planejamento e execução de missões, permitir maior eficiência no
controle de carga e descarga de produtos, possibilitar uma roteirização ótima
de seus veículos, bem como permitir armazenamento e controle dos dados
coletados no processo de automação de rodovias, permitir um gerenciamento
administrativo de recursos físicos, humanos e financeiros mais eficiente,
garantir padrões internacionais de qualidade na prestação de serviços, reduzir
o desperdício de recursos envolvidos, o tempo de atendimento às chamadas de
urgência e gastos desnecessários com manutenção de recursos físicos”.
2.4.2.3.
Re-Intitulação
Re-Especificação
de Requisitos
2.4.2.3. Re-Intitulação
“SIStema de Aplicativo de Banco de Dados
da Empresa HITS – SIS-HITS”.
2.4.2.4.
Re-Especificação de Requisitos
O
Sistema de Aplicativo de Banco de Dados SIS-GMR
deverá ser capaz de propiciar:
·
Um planejamento mais eficiente e execução mais
coordenada das missões de transporte rodoviário envolvendo frotas de veículos;
·
Um melhor controle no sistema de entrada e saída
de veículos no pátio de estacionamento para carga e descarga de produtos;
·
Melhores condições para a realização de um
planejamento financeiro, facilitando a procura por dados de movimentações
financeiras;
·
Melhor controle na gerência de contratos firmados
entre empresa e cliente;
·
Qualidade nos serviços prestados ao cliente, como
consultas on-line, serviços de marketing e geração de relatórios estatísticos;
·
Melhor controle dos locais de apoio, seus
recursos e atendimentos às chamadas de urgência prestados;
·
Melhor controle de recursos físicos e humanos,
bem como sua alocação às missões; e
·
Melhor controle de reparos e manutenções nos
recursos físicos.
2.4.2 - Sistema de
Dicionário de dados (nível 4)
Clique para
visualizar: Sistema
de Dicionário de dados da HITS
2.4.2.Modelo E-R a partir
do Diagrama E-R
Clique para
visualizar: Modelo
Entidade-Relacionamento da HITS
2.4.3. Implementação
Clique para visualizar: Script de Criação das Tabelas e Inserção da Massa de Dados
2.4.4. Consultas
Para este 4º nível de integração, foram geradas a
9ª, 10ª e 11ª consultas, descritas a seguir.
2.4.4.1. Nona Consulta
Pretende-se selecionar os itens de uma
expedição cujo titulo pago
pelo cliente é o de número 5000.
SELECT
EXP_CODIGO, ITE_ITEM
FROM
TITULO, CONTRATO_CLIENTE, EXPEDICAO, ITEM_EXPEDICAO
WHERE
TITULO.tit_num =
'5000'
AND CONTRATO_CLIENTE.ctt_codigo = TITULO.ctt_codigo
AND EXPEDICAO.cli_codigo =
CONTRATO_CLIENTE.cli_codigo
AND EXPEDICAO.exp_codigo =
ITEM_EXPEDICAO.exp_codigo;
2.4.4.2. Décima
Consulta
SELECT
EXPEDICAO.exp_codigo
FROM
CONTRATO_CLIENTE, EXPEDICAO
WHERE
EXPEDICAO.cli_codigo =
CONTRATO_CLIENTE.cli_codigo
AND CONTRATO_CLIENTE = '15421';
UNION
SELECT MISSAO.mis_id
FROM
CONTRATO_CLIENTE, MISSAO
WHERE AND MISSAO.mis_id =
CONTRATO_CLIENTE.ctt_codigo
AND CONTRATO_CLIENTE = '15421';
2.4.4.1.
Décima-Primeira Consulta
Pretende-se selecionar
os lotes que estão relacionados a um cliente de código 15421.
SELECT LOTE.lot_id,LOTE.lot_desc,SOL_CLI.scl_data
FROM LOTE, CLIENTE,SOL_CLI
WHERE CLIENTE.cli_codigo = '1521'
AND LOTE.cli_codigo = CLIENTE.cli_codigo
AND SOL_CLI.cli_codigo = CLIENTE.cli_codigo
2.4.5. Objetos
2.4.5.1.View
CREATE VIEW MISSOES_ATIVAS AS
SELECT MISSAO.mis_codigo, MISSAO.mis_origem, MISSAO.mis_destino,
MERCADORIA.mer_descricao, MERCADORIA.mer_peso
FROM MISSAO, MERCADORIA
WHERE MISSAO.mis_data_fim is NULL AND
MISSAO.mer_cod =
MERCADORIA.mer_cod;
2.4.5.2. Trigger
CREATE TRIGGER
PLANEJAR_MANUTENCAO FOR CUSTO AFTER INSERT AS
DECLARE VARIABLE cod_rcf
INTEGER;
DECLARE VARIABLE km_troca
INTEGER;
DECLARE VARIABLE km_atual
INTEGER;
DECLARE VARIABLE cod_pla
INTEGER;
BEGIN
SELECT TIPOCUSTO.tip_kmtroca
FROM TIPOCUSTO
WHERE TIPOCUSTO.tip_codigo =
NEW.tip_codigo
INTO :km_troca;
IF (km_troca > 0) THEN
BEGIN
SELECT
MANUTENCAO.rcf_codigo, MANUTENCAO.man_km
FROM MANUTENCAO
WHERE
MANUTENCAO.ctt_codigo = NEW.ctt_codigo
INTO :cod_rcf,
:km_atual;
km_troca=km_troca+km_atual;
SELECT
MAX(pla_numero)
FROM PLANEJAMENTO INTO
:cod_pla;
IF (cod_pla is
null) THEN cod_pla=1; ELSE cod_pla=cod_pla+1;
INSERT INTO
PLANEJAMENTO VALUES (:cod_pla, :km_troca, NEW.quantidade, :cod_rcf,
NEW.tip_codigo);
END
END
2. 4.5.3. Stored Procedure
CREATE PROCEDURE INSERIR_MATERIAL_CONSUMO (descr
CHAR(18), tipo CHAR(18), local_apoio
CHAR(18), quant INTEGER, obs CHAR(18)) AS
DECLARE VARIABLE cod_loa
INTEGER;
DECLARE VARIABLE cod_rcf
INTEGER;
BEGIN
SELECT loa_codigo
FROM LOCAL_APOIO
WHERE loa_nome = :local_apoio
INTO :cod_loa;
IF (cod_loa is null) THEN
EXIT;
SELECT MAX(rcf_codigo)
FROM RECURSO_FISICO
INTO :cod_rcf;
IF (cod_rcf is null) THEN
cod_rcf=1; ELSE cod_rcf=cod_rcf+1;
INSERT INTO RECURSO_FISICO
values (:cod_rcf, :descr, :tipo, :cod_loa);
INSERT INTO MATERIAL_CONSUMO
values (:cod_rcf, :quant, :obs);
END
III.
CONCLUSÕES E RECOMENDAÇÕES
Através do
desenvolvimento desde o Protótipo de Aplicativo de Banco de Dados escolhido, os
Setoriais 1,2, corporativo até ao Banco de Dados da Holding, foi possível
exercitar diversas técnicas de Banco de Dados. Implementou-se as 3ªs FN dos
Aplicativos de Banco de Dados e
utilizou-se de ferramentas RAD – Rapid Application Development, como o
Interbase 6.0 e o ErWin 4.0. Percebeu-se, assim a importância de tais
ferramentas para auxiliar no desenvolvimento de Sistema de Banco de Dados, em
especial quando o tamanho e níveis de complexidade são bastante grandes. Foi
possível, então, adquirir experiência da aplicação de diversos níveis de
integração de Banco de Dados em uma empresa, e a percepção das complexidades
que lhe são peculiares, tanto no que se refere aos fatores técnicos quanto aos
de recursos humanos envolvidos. Além disso, todo o trabalho de Integração até o
nível da Holding, proporcionou a todos os integrantes dos grupos, a percepção
de que uma integração de Banco de Dados em tais níveis, só se faz possível através
da utilização de técnicas apropriadas para a viabilização de um trabalho de
grande porte. Aliado a isso, as funcionalidades dos Sistemas de Banco de Dados
foram testadas através de consultas SQL, com vistas a redução de desperdícios
de recursos na fase de integração e ao aprimoramento da eficiência operacional
dos Bancos de Dados.
Recomenda-se, portanto
o uso de tais ferramentas ou similares, juntamente com técnicas apropriadas de
Banco de Dados, para o Projeto de sistemas de Banco de Dados, uma vez que
aliadas, elas proporcionam maior rapidez e melhores resultados em seu
desenvolvimento, reduzindo erros e aumentando a produtividade.
REFERÊNCIAS BIBLIOGRÁFICAS
Notas de Aula da disciplina CE-240 - Projeto de Sistema de
Banco de Dados - Prof. Adilson Marques da Cunha;
DATE, C. J., “Introdução a Sistemas de Bancos de Dados”, 3 a
Ed., Editora Campus, RJ, 1986.