INSTITUTO TECNOLÓGICO DE AERONÁUTICA DIVISÃO DE CIÊNCIA DA COMPUTAÇÃO - IEC CE-240 PROJETO DE SISTEMAS DE BANCO DE DADOS

Transcrição

1 INSTITUTO TECNOLÓGICO DE AERONÁUTICA DIVISÃO DE CIÊNCIA DA COMPUTAÇÃO - IEC CE-240 PROJETO DE SISTEMAS DE BANCO DE DADOS Prof. Dr. Adilson Marques da Cunha Projeto Final Banco de Dados Holding no cenário de Jogos de Empresas Rainer Ferraz Passos Módulo GIH Setorial ATD-IH (normalizador) Versão 2 São José dos Campos - SP 01 de julho de 2009

2 Sumário I. INTRODUÇÃO Motivação Contexto Objetivo Especificação de Requisitos do Protótipo de Aplicativo de BD... 1 II. DESENVOLVIMENTO Aplicativo de BD - GIH Banco de Dados Setorial - IH Banco de Dados Corporativo - ATD Exercício de Simulação de Jogos de Empresa Cenário do Estudo de Caso Especificações de Requisitos Consultas a Serem Elaboradas Resultados Esperados Resultados Obtidos III. CONCLUSÕES e RECOMENDAÇÕES Conclusões Recomendações Anexo I Aplicação da Heurística do Objetivo Anexo II Dicionário de Dados do BD módulo GIH Anexo III Script para inserção de dados nas tabelas no módulo GIH Anexo IV Queries Operacionais Queries Táticas Queries Estratégicas Queries para o Banco Integrado da Holding ATMH... 29

3 Stored Procedure Trigger View Anexo V Dicionário de Dados Holding ATMH Referências... 48

4 I. INTRODUÇÃO Motivação Diante das crises energéticas, financeiras e sociais e dos conhecimentos atuais a respeito da baixa disponibilidade de meios para a crescente população, coletar dados, consumindo recursos financeiros, humanos, de maquinário ou mesmo naturais, mas deixar de aplicar técnicas adequadas que permitam armazenar ou recuperar esses dados e tampouco agregar-lhes valor, pode ser descrito simplesmente como desperdício. Assim, para o Sistema de Aquisição, Tratamento, Monitoramento e Difusão de Dados Hidrológicos (SisATMH), a necessidade de conhecer seus usuários e interesses é fruto da importância de alocar seus escassos recursos para que se meçam os parâmetros com maior utilidade para a sociedade. Por isso, desenvolver o tema de protótipo de banco de dados sobre usuários do sistema e seus interesses, reveste-se de relevância ao poder agregar as necessidades da Agência Nacional de Águas (ANA), com a possibilidade de aprender com a prática no curso da disciplina CE Contexto A Agência Nacional de Águas (ANA) tem como missão implementar e coordenar a gestão compartilhada e integrada dos recursos hídricos e regular o acesso à água, promovendo o seu uso sustentável em benefício da atual e das futuras gerações. Para cumprir sua missão, a ANA coleta e armazena séries históricas de dados hidrológicos que, após análise e correções, constituem os produtos do sistema a serem divulgados a pesquisadores do Brasil e de nações amigas, que são, em síntese os usuários do SisATMH. Em campo, os dados são coletados via PCDs (Pontos de Coletas de Dados). Cada PCD tem sensores para medir os parâmetros necessários, os quais devem atender aos interesses manifestados pelos diversos usuários cadastrados Objetivo Com o intuito de abordar as necessidades descritas no contexto, aplicou-se a Heurística do Objetivo[1], com a identificação das alternativas de solução possíveis e a escolha da alternativa mais adequada conforme detalhado no ANEXO I, método pelo qual identificaram-se o objetivo do aplicativo intitulado Gerenciamento de Interesses de Usuários de Produtos Hidrológicos GIH : Dotar a Aquisição e Tratamento de Dados (ATD) do Sistema de Aquisição, Tratamento, Monitoramento, e Difusão de Dados Hidrológicos (SisATMH), até o final do 1º período letivo de 2009, de um sistema de Banco de Dados que propicie a armazenagem e a recuperação dos interesses dos usuários do sistema, a fim de que o SisATMH aumente a eficiência do atendimento dos usuários, reduzindo a sub-utilização das estações de coleta e a difusão de dados ou informações não solicitados ou sem conformidade com seus requisitos Especificação de Requisitos do Protótipo de Aplicativo de BD O Aplicativo de Banco de Dados de Gerenciamento de Interesses de Usuários de Informações Hidrológicas deverá ser capaz de propiciar: 1) o registro dos usuários; 2) o registro dos interesses sobre dados hidrológicos manifestados; e 3) contagem de quantos usuários buscaram certo tipo de dado. 1

5 II. DESENVOLVIMENTO 2.1 Aplicativo de BD - GIH O modelo de dados utilizado para o protótipo de aplicativo de BD GIH citado foi o Modelo Relacional, pois nos modelos Hierárquico e Rede o usuário precisaria conhecer a estrutura física do banco de dados para realizar consultas, o que poderia limitar o acesso e manipulação de dados. Por outro lado, no modelo Relacional a estrutura lógica do banco de dados é desconectada do método de armazenamento físico permitindo que se trabalhe com uma visão de mais alto nível do banco de dados. Dessa forma esse modelo permite por este implementar as seguintes características: manipulação de mais de um registro por vez; acesso indexado aos registros; e maior facilidade para trabalhar com as relações e relacionamentos, principalmente para integrar com os demais protótipos setoriais. Já quanto ao modelo orientado a objeto, percebeu-se que o envolvimento com a geração de código para adequar mensagens e métodos não seria compensado com retorno a altura em algum incremento na capacidade de processamento ou de atualização, pois o uso desse modelo é especialmente aplicado a objetos complexos. Com não era o caso do protótipo em tela, não se justificaria o uso do modelo orientado a objetos. Assim, nesse modelo, os principais componentes do Aplicativo são: Entidade USUARIO Descrição Usuários que buscam acessar o sistema, preenchem um formulário que, após ter sido aprovado, é inserido na tabela USUARIO. O valor de USU_CODIGO vem de uma seqüência numérica. INTERESSE Define o produto em que o usuário está interessado. (inclusive periodicidade e período total) PRODUTO Tabela com produtos hidrológicos para consulta (destinada a servir de conexão com os demais setores, onde são armazenados os dados hidrológicos em si) Esses elementos são descritos com mais detalhes no dicionário de dados, em seus quatro componentes, constante do ANEXO II, e sintetizado no Modelo Entidade Relacionamento (MER) da figura 1 abaixo. Figura 1: Modelo Físico do Banco de Dados GIH (Gerenciamento de Informações Hidrológicas para usuários) na ListEx 4. 2

6 Basicamente, para se chegar a essa forma, foram seguidos os seguintes passos: 0FN INTERESSE {int_codigo, int_nome_usuario, int_status, int_data_entrada, int_duracao, int_periodicidade, int_descricao, int_posicao_geo} Uma tabela está na 1FN, quando todos os seus registros possuem o mesmo conjunto de atributos, e esses atributos são atômicos, isto é, são itens indivisíveis. Assim, a chave int_codigo seria seqüencial numérica por usuário, por exemplo, quando cada usuário precisasse declarar uma nova necessidade, o faria utilizando um formulário numerado a partir da numeração do último apresentado. Percebe-se que o int_código sozinho não seria capaz de identificar exatamente um determinado registro, assim seria necessário combinar chaves. Identifica-se a necessidade de saberse o código e o usuário. 1FN INTERESSE {int_codigo, int_codigo_usuário int_nome_usuario, int_status, int_data_entrada, int_duracao, int_periodicidade, int_descricao, int_posicao_geo,}. Conforme apresentado pelo Prof. Cunha nas aulas sobre o tema, uma Tabela ou Relação está na 2FN quando seus Atributos Não Chave contêm dados ou informações que se referem à Chave inteira e não somente a parte da Chave do Registro ou Tupla, ou se e somente se esses atributos não-chave forem totalmente dependentes da chave primária. Observando a 1FN, percebe-se que alguns atributos dependem do usuário e outros do interesse em tela. Dessa forma, percebe-se que a concentração no objeto principal do banco de dados, os interesses, conforme comentado na atividade de intitulação da ListEx 2, não precisa ser sinônimo de ser essa a única tabela do protótipo. Assim define-se uma tabela para os usuários em si e outra para seus interesses, para esse arranjo, fica ainda mais claro que é importante que o int_codigo passe a ser único para cada interesse, independente de usuário. 2FN - USUARIO {usu_codigo, usu_nome, usu_contato}. - INTERESSE {int_codigo, int_data_entrada, int_duracao, int_periodicidade, int_descricao, int_posicao_geo, int_status}. Dessa forma, na passagem da 1FN para a 2FN, evita-se anomalias como: - Ao inserir um novo usuário, era forçoso inserir um novo interesse, pois o campo chave int_codigo não poderia ficar vazio; - Ao atualizar-se, por exemplo, o meio de contato com o usuário seria necessário realizar a busca e alteração do atributo em vários registros na tabela; e - Caso fosse necessário excluir um usuário, perder-se-ia o registro dos interesses, que poderiam ser úteis num futuro, como, por exemplo, para avaliar estatisticamente se o projeto atendeu aos interesses, atendimento registrado em int_status. Para a relação ou tabela encontrar-se na 3FN, relações transitivas entre atributos não chave e atributos chave devem ser eliminadas. Isto chamou atenção ao fato de que int_descricao e int_posicao_geo, apesar de dependerem do int_codigo, na verdade o fazem transitando pelo fato de dependerem funcionalmente de algum dado específico, pois, na realidade, seriam a descrição e posição de um dado já disponível ou que ainda será coletado. Neste ponto, deparou-se com uma dificuldade, o projeto aborda a medição, armazenagem, agregação e difusão de vários tipos de dados sobre um domínio amplo, que é a Amazônia, ou seja, 3

7 os interesses podem ser muito variados e relacionados simultaneamente a vários dados ou informações. Seria possível os interesses definirem, até mesmo, alterações sobre como as informações são modeladas sobre os dados. (Por exemplo, um interesse cadastrado de um setor da própria ANA, poderia ser uma forma de padronizar cores e forma de um gráfico, unindo e sintetizando dados). É como se um tipo de interesse pudesse ser uma meta-informação. Dessa forma, ficou-se com a impressão de que a tabela INTERESSE teria que possuir muitos atributos, os de todos os dados e informações que o sistema completo propicia produzir. A dúvida levou a reparar que, se considerássemos cada tipo de dado uma parte ou um sub-interesse, a relação entre USUARIO e INTERESSE se tornaria de muitos para muitos, e, nessa hipótese, sugeria ser importante inserir uma nova entidade intermediária. O tempo consumido nesse impasse fez notar mais uma mudança na abordagem do objeto principal do banco de dados, os interesses. Percebeu-se que o verdadeiro objeto da relação entre os usuários e o sistema são os dados e informações coletados, produzidos e armazenados, ou seja, os produtos do sistemas de sistemas e que os interesses seriam declarações das relações desejadas pelos usuários. Assim criou-se a tabela PRODUTO, apresentando atributos indispensáveis à relação com os interesses dos usuários, mas evidentemente faltam muitos atributos próprios para os protótipos de outras divisões do Banco de Dados como um todo, e INTERESSE passa a ser uma forma de identificar e registrar declarações de relações desejadas pelos usuários. 3FN - USUARIO {usu_codigo, usu_nome,, usu_contato}. - INTERESSE {int_codigo, int_data_entrada, int_duracao, int_periodicidade, int_status}. - PRODUTO {pro_codigo, pro_descricao, pro_posicao_geo}. Agora percebe-se que o atributo pro_descricao dificilmente seria atômico bem seria interessante evitar uma futura relação de muitos produtos para muitos interesses. Assim, modificouse a 3FN para: 3FN (modificada) - USUARIO {usu_codigo, usu_nome, usu_contato}. - INTERESSE {int_codigo, int_data_entrada, int_duracao, int_periodicidade, int_status}. - PRODUTO {pro_codigo, pro_ponto_geo, pro_linha_geo}. - DADO {dad_codigo, dad_momento, dad_posicao_geo}. Inicialmente pode-se pensar nos dados como um subgrupo dos produtos, afinal o usuário pode estar interessado em um simples dado. Mas consideramos que qualquer dado, por mais simples, conforme as especificações do sistema, só deve se tornar disponível após passar por funcionalidades como classificação, validação, filtragem, etc. Dessa forma, na passagem da 2FN para a 3FN, percebe-se a correção de algumas anomalias: - int_descricao e int_posicao_geo deixaram de ter dependência transitiva; - Ao inserir um novo dado, obrigava-se a criação de um interesse, agora não mais; - Ao alterar-se um atributo de dado seria necessário realizar a busca e alteração do atributo em vários registros em interesse; e - Caso fosse necessário excluir um interesse, perder-se-ia o registro dos dados, ou seja, poderia inviabilizar pesquisas futuras. 4

8 Nesta etapa observou-se que a modelagem inicial contemplava entidades próprias de outros protótipos, com os quais consumiu-se bastante tempo imaginando a melhor forma de defini-los com seus atributos; Ao perceber-se esse fato, optou-se por concentrar na entidade própria do GIH, os interesses, remover os dados do modelo, fazendo os produtos assumirem os atributos originais dos dados que eram necessários às relações com os interesses e renormalizar o modelo apenas com as três entidades: usuários, interesses e produtos. Dessa forma atendeu-se também o fato, já considerado acima, de que qualquer dado, mesmo simples, só deve se tornar disponível após passar por funcionalidades como classificação, validação, filtragem, etc., bem como percebe-se praticamente uma regra de negócio de que o acesso aos produtos pode ser feito, por exemplo, por um web service, mas a criação dos produtos possíveis, se faz pelo atendimento de interesses manifestados por usuários. 3FN (final) - USUARIO {usu_codigo, usu_nome, usu_contato}. - INTERESSE {int_codigo, int_data_entrada, int_duracao, int_periodicidade, int_status}. - PRODUTO {pro_codigo, int_codigo, pro_temp, pro_niv_plu, pro_data, pro_localizacao }. Assim, atribuiu-se aos produtos alguns tipos de medidas de interesse e uma localização já utilizando os recursos de georreferenciamento disponíveis no ORACLE 11g. O sistema, assim definido, pôde ser testado com a seguinte massa de dados, cujo script de inserção encontra-se no ANEXO III. Figura 2: Dados carregados como exemplo para testar GIH na ListEx 4. De posse dessa massa de dados, foi possível proceder ao teste do BD pela aplicação de Queries Operacionais, cujas reproduções, agora na última versão do Banco de Dados Holding, encontram-se no ANEXO IV. 5

9 2.2 Banco de Dados Setorial - IH O aplicativo GIH foi integrado aos CEH e AFE formando, assim, o Banco de Dados Setorial IH (Informações Hidrológicas). Os quatro componentes da extensão do Dicionário de Dados do BDS Informações Hidrológicas encontram-se detalhados no documento publicado em e sintetizados no Entidade Relacionamento (MER) abaixo. Figura 3: Modelo Entidade Relacionamento do Banco de Dados Setorial IH na ListEx 5. Para chegar a 3ª Forma Normal do BDS IH, iniciou-se pela comparação das entidades dos módulos conforme tabela de descrição de entidades a seguir. Em seguida, bastou a organização de duas tabelas e suas chaves para a correção das anomalias, neste caso, envolvendo pessoas e organizações usuárias, bem como valores de registros hidrológicos armazenados, isso trouxe o aplicativo da 1ªFN para a 3ªFN. 6

10 A tabela USUARIO do GIH recebeu os atributos da tabela T_OPERADOR, a qual foi substituída, gerando T_USUARIO no GIH. A tabela PRODUTO do GIH na verdade é a tabela T_ESTATISTICA do AFE. Como esta tabela está relacionada às tabelas T_PCD, T_FILTRO, T_MEDIDOR e T_PERIODO, estas também foram incluídas no GIH. Finalmente, a tabela INTERESSE foi renomeada para T_INTERESSE e os atributos renomeados de acordo com as regras de nomenclatura. DESCRIÇÃO DA ENTIDADE PROTÓTIPO PROTÓTIPO PROTÓTIPO AFE CEH GIH Estatísticas dos dados armazenados. T_ESTATISTICA PRODUTO Dados efetivamente lidos em campo. T_SERIE_HISTORICA LEITURA Filtros mais comuns utilizados pelo usuário. T_FILTRO Parâmetros medidos. T_MEDIDOR Pessoas físicas que coletam dados (operadores). Pessoas físicas ou jurídicas que consultam dados (usuários). T_OPERADOR USUARIO Identificação e localização dos PCDs (Posto de Coleta de Dados). T_PCD PCD Classificação de elementos hidrológicos TIPO_ELEMENTO Dados dos interesses manifestados pelos usuários clientes, foco nos interesses futuros que demandem INTERESSE campanhas de medição Finalmente, após todo o processo, as tabelas e atributos foram renomeados e trigramados conforme o novo padrão assumido A massa de dados para teste do aplicativo GIH, dentro do setorial IH, na tabela T_USUARIO receberam as tuplas dos operadores que haviam na T_OPERADOR do AFE, bem como foram criados dados na tabelas do AFE que acabavam por definir os produtos anteriores do GIH. Esses dados são detalhados no arquivo: em De posse dessa massa de dados, foi possível proceder ao teste do BDS pela aplicação de Queries Táticas, cujas reproduções, agora na última versão do Banco de Dados Holding, encontram-se no ANEXO IV. 7

11 2.3 Banco de Dados Corporativo - ATD O aplicativo do Banco de Dados Setorial IH (Informações Hidrológicas) foi integrado ao Banco de Dados Setorial AM, gerando o Banco de Dados Corporativo ATD (Aquisição e Tratamento de Dados). Os quatro componentes da extensão do Dicionário de Dados do BDC ATD encontram-se e detalhados no documento 240/ListEX6_CHF_CE240_v01.pdf, e sintetizados no Modelo Entidade Relacionamento (MER) a seguir. Figura 4: Modelo Entidade Relacionamento do Banco de Dados Corporativo ATD na ListEx 6. 8

12 Para chegar à 3ª Forma Normal do BDC ATD, iniciou-se pela comparação das entidades dos módulos conforme realizado na integração setorial e foi necessária a organização de várias tabelas e suas chaves para a correção das anomalias, no entanto, sobre as tabelas específicas do módulo GIH, dentro do Setor IH, alteraram-se apenas seus pentagramas e trigramação de atributos, mantendo-se a 3ªFN. Isso foi possível porque a interação com o outro setor se deu basicamente pelo gerenciamento de PCD, que não eram foco do GIH. Dessa forma, a massa de dados para teste do aplicativo GIH, dentro do Corporativo ATD, sofreu pouca extensão, mais uma vez recebeu-se mais tuplas em USUARIO e foram criados dados nas tabelas do Módulo AFE e do Setorial AM, necessários para definir os produtos anteriores do GIH. Esses dados são detalhados no documento publicado em De posse dessa massa de dados, foi possível proceder ao teste do BD pela aplicação de Queries Estratégicas, cujas reproduções, agora na última versão do Banco de Dados Holding, encontram-se no ANEXO IV Banco de Dados Holding ATMH Já sobre a formulação do BD da Holding, resultante da integração das Corporações ATD e MDD, foram formuladas as queries requisitadas, as quais se encontram abordadas no ANEXO IV. Nesse mesmo anexo encontram-se também representadas a view, a trigger e a store procedure produzidas, já sobre o protótipo de Banco de Dados da empresa Holding resultante da integração das duas corporações. Neste ponto é cabível comentar maiores detalhes sobre a integração dos BD Corporativos. Atividade que, como as anteriores, também demandou envolvimento do grupo e utilização das descrições de casos de uso para facilitar o entendimento das capacidades e operacionalidades de cada módulo, no entanto, foi exatamente nesse critério de comunicação interna em que houve maior dificuldade, mostrando seu valor e importância. Ainda assim, a integração foi executada com sucesso, e sem supressão de nenhuma das tabelas do Setorial IH. Especificamente para o Setor em tela, apenas foram incluídos atributos, por constatar-se a equivalência com algumas dos outros grupos. Dessa forma, das 12 entidades referentes ao Setorial IH a normalização levou a criação de apenas uma nova tabela, alocada ao Corporativo MDD, e à definição de novas chaves nos relacionamentos. Nesse processo de integração e normalização, destacam-se os seguintes dentre os passos necessários: Incluir a tabela MDDTB_STATUS; Renomear o atributo PEH_PCD_STATUS de SIHTB_PCD_ELE para PEH_STA_ID; Criar chave FK_PEH_STA ligando PEH_PCD_STATUS a MDDTB_STATUS.STA_ID; Criar chave FK_EXC_PEH ligando MDDTB_EXCECAO. EXC_PEH_ID a SIHTB_PCD_ELE. PEH_ID; Criar índice único em NTF_ALE_ID, NTF_USU_CD_CODIGO; e Criar chave FK_NTF_USU ligando MDDTB_NOTIFICACAO. NTF_USU_CD_CODIGO a SIHTB_USUARIO. USU_CD_CODIGO. Esses passos destacados permitem observar que a integração variou em menos de 10% a quantidade de entidades do corporativo inicial. Ao final, esse processo levou à produção do BD Holding especificado em maiores detalhes em seu dicionário de dados constante do ANEXO V. 9

13 2.4 Exercício de Simulação de Jogos de Empresa Cenário do Estudo de Caso Dentro do cenário da região Amazônica do MERCOSUL, a ação de qualquer empresa voltada ao acompanhamento e gerenciamento dos recursos hídricos, se reveste de importância pelo cuidado com um produto que se torna mais escasso em todo o resto do Globo, a cada dia. Nesse contexto, a fusão de duas importantes corporações em uma só empresa Holding de Aquisição, Tratamento e Monitoramento de Dados Hidrológicos da Amazônia ATMH obriga a nova entidade a sofrer uma reengenharia, a qual define sua composição, inicialmente, em cinco setores, cujos valiosos bancos de dados serão objeto de integração na composição do Projeto de Sistema de Banco de Dados da própria Holding, o SisATMH. Assim a instituição caracteriza-se como um conjunto de Pequenas Empresas dentro da Empresa ATMH Dentre esses Setores, um destaca-se como de importância central do novo empreendimento: o Setor de Informações Hidrológicas (IH). Tratando-se do principal repositório dos dados coletados dos sensores, e suas informações derivadas, bem como do cadastro de usuários e seus interesses, os verdadeiros definidores sobre o que deve ser medido e coletado e, ainda, do cadastro dos elementos hidrológicos a serem acompanhados, o setor conta com três alunos envolvidos em seu desenvolvimento e implementação e é identificado pelo sugestivo Logotipo ilustrado a seguir: Figura 5: Logotipo do Setor IH Especificações de Requisitos Para armazenar e recuperar as informações nos 3 (três) diferentes níveis de decisão (Operacional, Tático e Estratégico), o setor contou com o desenvolvimento de três módulos de protótipos de BD, para cada um desses bancos, um dos Alunos empenhou-se em explorar, da melhor forma possível, os conhecimentos disseminados na Disciplina CE-240 e qualquer experiência anterior na Área. Dessa forma, os Protótipos do BD Corporativos que vêm sendo modelados na Disciplina, receberam o máximo de reusabilidade no Anteprojeto da Empresa ATMH, inserindo-se um mínimo de modificações possível (no máximo 10%) no Modelo de Dados da Holding vide ANEXO V - e mantendo-se as funcionalidades e capacidades de cada banco isolado, citadas ao item Especificação de Requisitos do Protótipo de Aplicativo de BD deste documento. Por outro lado as políticas definidas para a empresa ATMH indicam a necessidade de seu Banco de Dados ser capaz de propiciar armazenamento e recuperação de dados relevantes para a consecução dessas políticas. 10

14 Dessa forma, o setor da nova empresa herdou do setorial IH original a capacidade de propiciar correto armazenamento e recuperação de dados sobre os Elementos Hidrológicos e suas posições geográficas, dos dados coletados nesses elementos, também sobre as PCD (plataforma de coleta de dados) que realizaram essas coletas, sobre os filtros e estatísticas a serem aplicados aos dados, os interesses de usuários que levam à identificação da necessidade de coleta desses dados e sobre os usuários que manifestam esses interesses. No entanto, no contexto de jogos de empresa, identificou-se a necessidade de armazenar também dados que propiciassem a avaliação qualitativa das atividades da empresa, ou seja, seus projetos e dos recursos aplicados neles. Essa necessidade foi sintetizada nos seguintes itens, cujo armazenamento devem ser propiciados pelo sistema: - O controle de projetos e os respectivos recursos de hardware, software e peopleware alocados; - A avaliação do desempenho dos funcionários alocados aos projetos; e - A avaliação da qualidade percebida pelos clientes dos projetos Consultas a Serem Elaboradas A capacidade do BD SisATMH pode ser observada na execução das consultas que permitem testar os protótipos implementados, como as queries, view, trigger e stored procedures já relacionadas ao ANEXO IV, mas também poderiam ser elaboradas e testadas novas consultas com a implementação do controle e das avaliações citadas na seção anterior. Apesar de desejar-se realizá-lo, não foi possível implementá-la em conjunto com todo grupo da disciplina. No entanto a proposta foi modelada, criada e populada com dados para testes em separado, usando-se o próprio banco de dados final da Holding, de forma que foram criadas duas novas entidades (tabelas), o que seria menos que 10% do total de 36 entidades do BD da Holding: PROJETO: define os projetos que serão executados nas Simulações de Jogos de Empresas. Inicialmente, cada projeto será identificado por um nome. Em versões mais adiantadas outros atributos poderiam ser considerados: data do início, data do término, orçamento etc. PROJETO_AVALIACAO: associa cada projeto com os recursos de Hardware (representados pelas entidades PCD e SENSOR), Software (representados pela entidade SOFTWARE_PCD) e Peopleware (representados pela entidade USUARIO). Esta entidade contém o atributo NOTA que avalia os operadores (considerados funcionários do IH) e os pesquisadores (considerados clientes do IH). Com essas entidades, poderiam ser elaboradas as consultas a seguir, as quais, da mesma forma das constantes da última divisão do ANEXO IV, também foram testadas com atenção às Políticas assumidas pela Holding: Consulta em nível operacional Quais são os funcionários com melhor desempenho em 2009? select usu_nm as operador, count(*) as quantidade_projetos, avg(pra_nota) as nota from sihtb_usuario join sihtb_tipo_usuario on tpu_id = usu_tpu_id join sihtb_projeto_avaliacao on pra_usu_cd = usu_cd join sihtb_projeto on pro_id = pra_pro_id where tpu_ds like '%opera%' and pro_dt_inicio > to_timestamp('31/12/2008','dd/mm/yy') group by usu_nm order by nota desc; 11

15 operador quantidade_projetos nota Cacique Juruna 1 10 Maria Silva José Silva 1 1 Auxilia a atribuição de mérito ao ativo mais importante da empresa, seus Recursos Humanos ( os melhores funcionários e aqueles que mais se destacarem deverão ser sempre recompensados ). Consulta em nível tático Caso o cliente mais insatifeito de 2009 pedisse o dinheiro de volta, quanto teríamos que desembolsar para garantir "satisfação garantida ou seu dinheiro de volta"? select pra_nota,pro_orcamento from sihtb_projeto join sihtb_projeto_avaliacao on pra_pro_id = pro_id join sihtb_usuario on usu_cd = pra_usu_cd join sihtb_tipo_usuario on tpu_id = usu_tpu_id where tpu_ds like '%consulta%' and pro_dt_inicio > to_timestamp('31/12/2008','dd/mm/yy') order by pra_nota; pra_nota pro_orcamento Logo, ter-se-ia que devolver 1000 caso o cliente mais insatisfeito (nota 5.5) resolvesse pedir o dinheiro de volta (satisfação garantida). Consulta em nível estratégico Quantos PCDs (hardware) e funcionários (peopleware) estão alocados em cada projeto em 2009? select pro_id as Projeto, count(distinct peh_pcd_id) as PCDs, count(distinct peh_usu_cd) as Funcionarios from sihtb_projeto join sihtb_projeto_avaliacao on pra_pro_id = pro_id join sihtb_usuario on usu_cd = pra_usu_cd join sihtb_tipo_usuario on tpu_id = usu_tpu_id join sihtb_pcd_ele on peh_id = pra_peh_id where tpu_ds like '%opera%' and pro_dt_inicio > to_timestamp('31/12/2008','dd/mm/yy') group by pro_id; projeto PCDs Funcionarios

16 2.4.4 Resultados Esperados Com a implementação deste Projeto de Sistema de Banco de Dados na Empresa ATMH na América do Sul e no ITA, espera-se o seguinte: 1) Determinar, se é possível começar a modelar, pelo menos academicamente, na turma de Pós-Graduação do ITA de 2009, alguns Exercícios de Jogos de Empresa, utilizando-se, inicialmente, as Técnicas e as Tecnologias de BD disponíveis; 2) Determinar, se é possível começar a utilizar as Tecnologias de BD Corporativos Georreferenciados, Administrativos, Operacionais e de Infra-estrutura em Cenários de Jogos de Empresa; e finalmente, 3) Determinar, se é possível implementar e implantar, nos dias de hoje, academicamente, um Exercício de Jogos de Empresas como este, nesta Disciplina do Programa de Pós-Graduação do ITA. Espera-se ainda que os resultados a serem obtidos, a partir desta experiência acadêmica, venham a dar subsídios tanto para a melhoria do desenvolvimento dos Sistemas de Informação baseados nas Tecnologias de BD e de Redes de Computadores na Empresa Fictícia ATMH e no ITA, como para a vida profissional dos Alunos que se encontram realizando a Disciplina CE-240, neste 1º Semestre de Resultados Obtidos O resultados obtidos apontam para a plena possibilidade de se começar a modelar academicamente alguns Exercícios de Jogos de Empresa, com indicações de vantagens caso o cenário e os Jogos sejam descritos com antecedência maior que seis semanas do término da disciplina em pauta. Com essa antecedência, seriam mais facilmente identificadas as necessidades e vantagens, frente à política empresarial, da implementação das tabelas de avaliação qualitativa ora recomendadas, implementação que não foi possível realizar até nesta ocasião. Por outro lado, a utilização de Tecnologias de BD Corporativos Georreferenciados em Cenários de Jogos de Empresa não só pode ser usada, como praticamente já é feita durante as semanas finais da disciplina CE-240. Finalmente, observa-se, conforme referido ao primeiro parágrafo desta divisão, que o emprego do Exercício e Jogos de Empresas tem indicações de ser aplicável à disciplina CE-240 desde já, e que, observando-se a antecedência mínima de seu início em pelo menos seis semanas antes do término do período e a importância de disponibilidade de ambientes para execução das atividades, como reserva de horários em laboratório com rede de computadores, poder-se-ia implementar e implantar os referido jogos com maior completeza de métodos qualitativos. 13

17 III. CONCLUSÕES e RECOMENDAÇÕES 3.1 Conclusões Esses mesmos resultados obtidos apontam, também, para a satisfação da proposta sintetizada no objetivo constante da Introdução deste documento, ou seja, a implementação criada foi capaz de dotar o SisATMH de um sistema de Banco de Dados que propicia a armazenagem e a recuperação dos interesses dos seus usuários. Percebeu-se também que o sistema ora referenciado incluiu o registro dos usuários, o registro dos interesses sobre dados hidrológicos manifestados e a contagem de quantos usuários buscaram certo tipo de dado, atendendo aos requisitos enumerados também na introdução. Dessa forma, percebe-se que, considerando a total inexperiência do autor sobre o tema e respectivas técnicas, há plena possibilidade de produzir-se aprendizado utilizando técnicas apresentadas ao longo da abordagem de uma situação problema. Em resumo, é possível realizar o aprendizado baseado em problemas. 3.2 Recomendações Já para trabalhos futuros, o aprendizado de métricas, não só do tema do BD, mas também de marketing, indicarão as possibilidades de atributos qualitativos mais precisos, permitindo a avaliação do atendimento de requisitos e políticas de forma contínua e não apenas binária como foi realizado: atendeu ou não atendeu. No entanto, não houve tempo para realizar esse estudo neste semestre. Assim, recomenda-se que sejam criadas, em futuras edições da disciplina, situações que propiciem a implementação das tabelas referentes aos projetos da empresa, onde estariam as avaliações qualitativas dos produtos e funcionários da empresas envolvidos com os respectivos projetos, conforme comentado na seção de Jogos de Empresa, mas que não se pôde implementar nesta oportunidade. Dessa forma, uma vez que desejava-se realizar mais interações e verificações sobre a diferença de realizar-se esta atividade no ambiente de um Jogo de Empresas, recomenda-se que seja realizado, no futuro, a descrição do cenário e dos Jogos com antecedência maior, pelo menos seis semanas antes do término da disciplina, assim poderia haver pelo menos duas rodadas de atividades nesse ambiente de Jogos de Empresa. Nesse mesmo contexto, percebeu-se a importância da disponibilidade de ambientes para execução das atividades fora dos horários regulares das aulas, ou seja, reserva de horários em laboratório com rede de computadores. Assim, finalmente, sugere-se alterar, no futuro, a distribuição semanal de carga horária da disciplina de 3-0-6, conforme consta hoje, para 4-3-6, o que significaria quatro tempos em sala, três tempos em laboratório, com o ambiente supracitado, e os mesmos seis tempos de dedicação individual. Dessa forma aproximar-se-ia ao consumo real de tempo, mas, principalmente, atenderse-ia a maior necessidade de compartilhar aprendizado durante os Jogos de Empresa, como referido no item

18 Anexo I Aplicação da Heurística do Objetivo Definição do Problema, Definição da Solução e Definição do Título da proposta da temática para o protótipo de projeto de aplicativo de Banco de Dados. 1. Definição do Problema 1.1. Identificação do Problema Efeitos Adversos (O que está errado?) Inadequação dos planos de trabalho das estações de medição; Incompatibilidade entre os dados ou informações disponíveis e os de interesse dos usuários; e Os usuários não conseguem interpretar as representações gráficas dos elementos de interesse Causas (Porque está errado?) O Sistema de Banco de Dados atual não está dimensionado para armazenar e recuperar interesses dos usuários tais como periodicidade ou campanhas de medição; O Sistema de Banco de Dados atual não está dimensionado para armazenar e recuperar interesses dos usuários sobre quais tipos, ou categorias de dados ou informações, são os que devem ser disponibilizados para a difusão; e O Sistema de Banco de Dados atual não está dimensionado para armazenar e recuperar os requisitos referentes às representações gráficas dos elementos de interesse definidos pela ANA Tarefa (O que, quem, onde e quando se deseja realizar?) Dotar a Aquisição e Tratamento de Dados (ATD) do Sistema de Aquisição, Tratamento, Monitoramento, e Difusão de Dados Hidrológicos (SisATMH), até o final do 1º período letivo de 2009, de um sistema de Banco de Dados que propicie a armazenagem e a recuperação dos interesses dos usuários do sistema Propósito (Para que se deseja realizar tal tarefa?) A fim de que o SisATMH aumente a eficiência do atendimento dos usuários, reduzindo a sub-utilização das estações de coleta e a difusão de dados ou informações não solicitados ou sem conformidade com seus requisitos Enunciado do Problema (Objetivo + Finalidade) Dotar a Aquisição e Tratamento de Dados (ATD) do Sistema de Aquisição, Tratamento, Monitoramento, e Difusão de Dados Hidrológicos (SisATMH), até o final do 1º período letivo de 2009, de um sistema de Banco de Dados que propicie a armazenagem e a recuperação dos interesses e requisitos dos usuários do sistema, a fim de que o SisATMH aumente a eficiência do 15

19 atendimento dos usuários, reduzindo a sub-utilização das estações de coleta e a difusão de dados ou informações não solicitados ou sem conformidade com os requisitos de representação. 2. Definição da Solução 2.1. Alternativas de Soluções Possíveis: ASP1 - Manter a situação atual, com um Sistema de Banco de Dados incapaz de propiciar a armazenagem e a recuperação dos interesses e requisitos dos usuários; ASP2 - Comprar uma solução pronta visando atender às necessidades do SisATMH; e ASP3 - Desenvolver e implementar um Protótipo de Sistema de Banco de Dados, de acordo com os requisitos da ANA, que propicie a armazenagem e a recuperação dos interesses dos usuários Análise APA (Adequabilidade + Praticabilidade + Aceitabilidade) ASP1 A solução não atende nem uma parte da tarefa (não há nenhum quanto e nenhum o que da tarefa sendo integralmente atendido), dessa forma não cumpre o fator integridade e é, portanto, considerada Inadequada; ASP2 A solução supõe a pré-existência de um produto comercial que já tenha sido customizado para as necessidades do sistema específico, o que não é real, qualquer compra ainda exigiria o desenvolvimento do produto comprado. Dessa forma, a simples compra não atende o fator qualidade, sendo a solução Impraticável; e ASP3 A Solução Possível, considerando a disponibilidade do efetivo envolvido com o projeto e o emprego dos alunos de Pós-Graduação em sistema de aprendizado baseado em problema, atende aos fatores de uma análise APA, dessa forma é considerada Adequada, Praticável e Aceitável Alternativa de Solução Escolhida A alternativa de solução escolhida foi a ASP3. ASE - Desenvolver e implementar um Protótipo de Sistema de Banco de Dados, de acordo com os requisitos da ANA, que propicie a armazenagem e a recuperação dos interesses dos usuários. 3. Redefinição do Título Observando-se a própria análise da definição do problema, percebe-se que a funcionalidade necessária é propiciar armazenagem e recuperação, mas do que? Esse objeto-chave a ser manipulado não são os clientes em si, tampouco os dados ou informações hidrológicas apenas, mas sim os interesses dos clientes sobre o acesso e o agendamento da obtenção desses produtos hidrológicos e sua formatação. Sob essa perspectiva observa-se que as verdadeiras chaves são o gerenciamento e os interesses dos usuários dos produtos hidrológicos, dessa forma um novo título seria: TÍTULO - Sistema de Banco de Dados para Gerenciamento de Interesses de Usuários de Produtos Hidrológicos ( Gerenciamento de Interesses de Usuários de Produtos Hidrológicos GIH). 16

20 Anexo II Dicionário de Dados do BD módulo GIH Dicionário de Dados - No dicionário abaixo considerou-se: 1. A SEGURANÇA de todas as tabelas e todos os atributos é garantida por procedimentos de backup/restore bem como acesso restrito a técnicos devidamente autorizados e capacitados para realizar inserções, remoções e alterações dos dados. 2. A PRIVACIDADE das tabelas e atributos é garantida por procedimentos de acesso autorizado por senha a qual é gerada, distribuída, armazenada e verificada por procedimentos específicos que propiciam o nível de privacidade necessário. 3. A INTEGRIDADE dos atributos é garantida por relacionamentos de chave estrangeira, pela escolha do formato e do tamanho de cada atributo, pelo uso das diretivas NULL e NOT NULL bem como procedimentos de depuração realizados via stored procedures e/ou pela interface de entrada de dados. ITEM CONTEÚDO ESTRUTURA INTEGRIDADE SEGURANÇA Leitura: interna USUARIO Tabela com dados Escrita: interna Tabela com 4 atributos dos usuários Exclusão: interna USU_CODIGO Identificador de usuário INTEGER Primary key Não nulo USU_NOME Nome de usuário VARCHAR USU_CONTATO Contato principal de usuário VARCHAR USU_PAIS País de usuário VARCHAR INTERESSE INT_DATA_ENTRADA INT_DURACAO INT_PERIODICIDADE INT_STATUS INT_CODIGO PRODUTO Tabela com dados dos interesses de usuários Data de entrada do formulário de interesse (em GMT) Período de duração do interesse (em GMT) Freqüência de coleta do interesse Registro de atendimento do interesse Identificador do interesse Tabela com produtos hidrológicos para consulta Tabela com 5 atributos DATE VARCHAR VARCHAR VARCHAR Leitura: usuário Escrita: usuário Exclusão: interna INTEGER Primary key Não nulo Tabela com 5 atributos Leitura: usuário Escrita: interna Exclusão: interna PRO_CODIGO Identificador do produto INTEGER Primary key Não nulo PRO_LOCALIZACAO Posição e tipo de MDSYS.SDO_GEOMETRY 17