• Nenhum resultado encontrado

Aplicação de Técnicas para Modelagem de Data Warehouse em Banco de Dados Freeware: Integração de Dados de Sistemas Proprietários do SUS

N/A
N/A
Protected

Academic year: 2021

Share "Aplicação de Técnicas para Modelagem de Data Warehouse em Banco de Dados Freeware: Integração de Dados de Sistemas Proprietários do SUS"

Copied!
10
0
0

Texto

(1)

Aplicação de Técnicas para Modelagem de Data Warehouse

em Banco de Dados Freeware: Integração de Dados de

Sistemas Proprietários do SUS

Luiz Fernando Stopa Arcenio

Seção de Laboratório (FAED) - Universidade Federal da Grande Dourados (UFGD) Rod. Dourados/Itahum, km 12 – Dourados/MS

luizarcenio@ufgd.edu.br

Abstract: The need to improve the quality of the service to the patients of SUS

is of fundamental importance for the evaluation of his cost/benefit. But how to evaluate the systems of information is fragmented and proprietors. Being used of techniques for modelling of Data Warehouse was possible the modelling of a tool of research of data, using a free SGBD, allowing the integration of the sources of data, consolidating them, and allowing the access to all of the Municipal General office of Health. The databases freeware is many used in the municipal public institutions. The result evidenced the implementation easiness, the need and the fomentation of new solutions.

Keyword: Data Warehouse, Bussiness Inteligence, Cube.

Resumo: A necessidade de melhorar a qualidade do atendimento aos

pacientes do SUS é de fundamental importância para a avaliação de seu custo/benefício. Mas como avaliar se os sistemas de informações1 são

fragmentados e proprietários. Utilizando-se de técnicas para modelagem de Data Warehouse foi possível a modelagem de uma ferramenta de pesquisa de dados, utilizando um SGBD gratuito, permitindo a integração das fontes de dados, consolidando-os, e permitindo o acesso à todos da Secretaria Municipal de Saúde. Os bancos de dados freeware são muitos utilizados nas instituições públicas municipais. O resultado evidenciou a facilidade de implementação, a necessidade e o fomento de novas soluções.

Palavras-chave: Armazém de Dados, Inteligência Empresarial, Cubo.

1.

Introdução

A Secretaria Municipal de Saúde de Dourados/MS é uma organização pública municipal que presta serviços na área de saúde ao município de Dourados e é referência para mais trinta e três municípios pertencentes à macrorregião sul do estado de Mato Grosso do Sul.

Com a grande fragmentação das informações em diversos sistemas de informação, a coordenação da atenção básica não consegue avaliar a qualidade do

1 Sistemas de informação são um conjunto de componentes físicos, lógicos e humanos que são

(2)

atendimento e a resolutividade das unidades de saúde, o que prejudica a elaboração do planejamento. Esses sistemas de informação possuem um resumido número de relatórios gerenciais causando atrasos nos levantamentos das informações e tomada de decisões.

Neste contexto, pesquisou-se uma modelagem de um banco de dados que permita a integração de todos os dados dos diversos sistemas de informação existentes, permitindo, assim, o acompanhamento do desempenho das unidades de saúde. Segundo PNGC (2006), o conhecimento da estrutura de custos ajuda a gerenciar melhor os recursos e a racionalizar os insumos, pois permite ao gestor melhor planejamento das ações a médio e longo prazo.

Tendo em vista as tecnologias disponíveis para análise de dados, foram consultados alguns representantes de empresas de desenvolvimento que teriam um software de ambulatório e almoxarifado, integrado e com uma ferramenta de análise de dados. Neste levantamento, verificou-se que das oito empresas pesquisadas apenas duas tinham essa configuração, de modo que uma tinha apenas para análise do ambulatório. Dessa forma, percebe-se a carência e a necessidade de incentivo à pesquisa de novas tecnologias, e este é o foco deste estudo de caso.

2.

Metodologia

Como forma de instrumentalizar a implementação do data warehouse, este artigo é de natureza tecnológica, com objetivos de caráter exploratório, utilizando procedimentos de estudo de caso com embasamento em referencial bibliográfico e documental, para assim permitir melhor elucidação da forma técnica de como aliar necessidade com recurso tecnológico. Nesse sentido, busca-se a geração de conhecimento para a produção de novas práticas ou inovações tecnológicas, conforme Jung (2004).

O procedimento utilizado para este estudo de caso foi estudar a estrutura organizacional e tecnológica da secretaria. Com este conjunto de dados, foi possível elaborar uma ferramenta para melhorar as atividades metodológicas atualmente utilizadas, ou seja, ajudar na tomada de decisão no limite das despesas e atendimento das unidades de saúde. Esta ferramenta é composta de uma estrutura de armazenamento do tipo Data Warehouse, utilizando um banco de dados freeware.

Para que seja alcançado o objetivo, a metodologia da pesquisa foi dividida em quatro fases: primeira, levantamento dos problemas relacionados ao controle das despesas e da produção ambulatorial; segunda, levantamento das fontes de dados e implementação da base de dados; terceira, implementação das interfaces; e por último a disponibilização aos usuários para a alimentação dos dados e emissão/análise dos relatórios.

Nas seções seguintes, é apresentado o detalhamento das fases acima descritas para assim permitir um melhor acompanhamento de como decorreram o desenvolvimento do projeto e ao final os resultado obtidos.

(3)

3.

Levantamento dos problemas para controle das despesas e produção e as

suas fontes de dados

Atualmente, a Secretaria Municipal de Saúde, para tomar as decisões e elaborar o planejamento estratégico de suas atividades, baseia-se em levantamentos efetuados trimestralmente. Estes são feitos manualmente em planilhas do Microsoft Office Excell2,

com base nos dados retirados dos sistemas proprietários utilizados.

A entrada de dados no data warehouse pode ser oriunda de diversas fontes, que podem ser internas e externas à organização, ou seja, sistemas transacionais e documentos não tradicionais, como imagens, áudio e documentos. Dessa forma, as fontes de dados para o Data Warehouse se dividem nos sistemas proprietários utilizados e arquivos externos (.txt), sendo eles:

• Sistema Almox: fonte interna, utilizado para controlar a movimentação de materiais de expediente e hospitalar para os setores e unidades de saúde. Este sistema foi fornecido pela Secretaria de Estado de Saúde, mas sem atualização. Possui um total de 122 arquivos dbf;

• Sistema BPA: fonte interna, utilizado para digitação dos procedimentos efetuados nos atendimentos e que após a digitação os dados são exportados para o sistema SIA/SUS. Fornecido pelo Datasus, possui um total de 12 arquivos dbf, conforme BPA (2008); • Sistema SIA/SUS: fonte externa, utilizado para consolidar todas as produções das unidades de saúde em um único arquivo do município de nome FPAMMS??.TXT, em que o símbolo ?? é o mês de competência da informação. Fornecido pelo Datasus, possui um total de 197 arquivos dbf, segundo SIA/SUS (2006);

A busca pelas informações de forma ágil através da integração dos dados fisicamente distribuída é uma grande necessidade, pois permite a tomada de decisões de forma rápida e assim a melhoria da aplicação dos recursos financeiros. Muitas tecnologias permitem essa integração dos dados, entre elas existem as aplicações de BI,3 que têm por finalidade acumular, armazenar, analisar e fornecer acesso aos dados para a tomada de decisões, isto é, transformar dados em conhecimento, conforme Oliveira (2002). Ele também afirma que uma das ferramentas de BI é o data warehouse ou armazém de dados que serve para filtrar, integrar e disponibilizar os dados para serem analisados. E como o banco de dados do DW funciona em paralelo com os bancos de dados transacionais, não causa nestes alteração no seu desempenho.

Um data warehouse possui as seguintes características: armazena as informações por temas específicos, os dados são oriundos de diversos sistemas transacionais dispersos pela organização; e permite que os dados sejam analisados sob diversas perspectivas, como comprimento, largura e altura, ou seja, um cubo, conforme a Figura 1.

Uma das arquiteturas de DW pode ser a de três camadas. Essa arquitetura suporta um grande número de serviços integrados, na qual a interface, as funções de

2 Planilha eletrônica da Microsoft.

(4)

processamento e gerenciamento do banco de dados podem ser distribuídas através da arquitetura da informação.

Figura 1. Exemplo de um cubo OLAP

A arquitetura do Data Warehouse foi implementada em três camadas, demonstrando a origem dos dados armazenados, o armazenamento e o acesso pelos usuários, conforme a Figura 2:

Camada 1: Nesta camada ficaram os bancos de dados operacionais dos sistemas transacionais do Almoxarifado, BPA e arquivo de exportação do SIA/SUS, onde serão as fontes de dados para o data warehouse.

Camada 2: o data warehouse foi implementado sobre o Sistema Operacional Fedora Core 2 com o gerenciador de banco de dados Firebird 1.5.3.4870 (back end).

Camada 3: o aplicativo cliente foi construído em compilador Delphi, versão 7.0, com interface para a extração dos dados das fontes, configuração dos parâmetros do sistema, controle de usuário e além da emissão de relatórios/gráficos (front end), o qual permitiu fácil e rápido desenvolvimento.

Figura 2. Arquitetura de três camadas do data warehouse

O SGBD Firebird possui diversas características, mas as que se destacam são as seguintes: fácil instalação e manutenção; é um banco de dados leve; sem restrição quanto ao número de processadores, à memória RAM e plataforma; possui recursos de desenvolvimento: views, triggers, stored procedure e function; consumo de poucos recursos; possui versão embutida, e compatibilidade com o Padrão ANSI. Dentre estas e outras razões, o Firebird foi a opção para desenvolvimento do projeto, principalmente pela utilização das view como cubo OLAP.

(5)

4.

Levantamento dos dados e implementação da base de dados

Na implementação do data warehouse foi utilizado o Modelo de Prototipação que, segundo Pressman (1995), facilita principalmente pelo motivo de não se precisar experiência suficiente para determinar todos os requisitos para implementação do banco de dados e o próprio sistema de informação em si.

Assim, na modelagem do Data Warehouse foi utilizado a modelagem dimensional ou multidimensional. Este tipo de modelagem segue o modelo de Ralph Kimball chamado Star Schema (modelo estrela), mas será seguida uma variação do Star

Schema, chamado “snowflake” (floco de neve), pois emprega a normalização da base de

dados, para manter a integridade e reduzir os dados armazenados de forma redundante, e a de-normalização através das views a fim de obter melhor um desempenho com o agrupamento dos dados relacionados funcionalmente, de acordo com Gonçalves (2003).

Este modelo é representado por uma tabela central chamada tabelas de fatos e diversas outras tabelas chamadas tabelas de dimensões. As tabelas de fatos possuem grandes volumes de dados, que são as transações da organização, já as tabelas de dimensão guardam conteúdo textual que serve para definir uma dimensão como as restrições de uma consulta ou resposta, segundo Oliveira (2002).

Após a definição do conteúdo das etapas de modelagem do data warehouse: definir os fatos ou métricas, dimensões de negócio, granularidade das informações de cada dimensão e a hierarquia de agrupamento das informações, efetuou-se então a modelagem lógica do data warehouse das tabelas de dimensões e tabelas fato.

As dimensões implementadas no data warehouse ficaram especificadas como: Saída, Produção, e LancamentoDiverso. As dimensões de negócio que foram implementadas, conforme necessidades dos setores foram:

Tempo: a dimensão tempo é muito poderosa e importante em todo data warehouse corporativo. Como tal deve ser tratada de forma diferenciada em relação às outras dimensões, indica os períodos de tempo para a análise;

• UnidadeSaude: indica os locais para onde são dispensados os materiais utilizados e realizados os atendimentos aos usuários;

• Material: determina quais produtos e unidades de medida estão relacionadas com as métricas;

• Procedimento: especifica o tipo do procedimento executado com a produção lançada dos atendimentos;

• TipoLancamento: especifica o tipo do lançamento que foi efetuado no lançamento diverso.

As tabelas de dimensão possuem a função de reunir os atributos que serão utilizados para qualificar as consultas e cujo valor será utilizado para agrupar e sumarizar as métricas (ou fatos). As tabelas de fatos representam quais informações serão analisadas e as dimensões representam como elas serão analisadas, contendo as métricas.

A tabela Fato-Saída com as dimensões tempo, unidadesaude e material, representa a movimentação de saída dos materiais do almoxarifado para o solicitante em

(6)

um determinado período, conforme a Figura 3. Esta tabela é apresentada no sistema através da visão vw_saidamaterial, assim como as demais tabelas de fatos Produção e LancamentoDiverso também foram implementados, nas views vw_produção e vw_lancamentodiversos. FATO-SAÍDA SAIDANUMERO SITUACAOSAIDA QUANTIDADE VALORTOTAL DIA DIMENSÃO TEMPO UNIDADESAUDE DIMENSÃO UNIDADESAÚDE MATERIAL DIMENSÃO MATERIAL SUBDIMENSÃO UNIDADEMEDIDA UNIDADEMEDIDA MÊS ANO DEPARTAMENTO ITEM

Figura 3. Tabela Fato-Saida e suas dimensões

O povoamento do DW é efetuado através de ferramentas de extração, filtragem, transformação e migração dos dados, também chamadas de ETL4, em que a ferramenta de extração busca e limpa os dados dos sistemas transacionais para o DW. Já a ferramenta de transformação converte os dados para o padrão do DW e a ferramenta de filtragem faz os ajustes necessários no DW, conforme Oliveira (2002).

Uma das formas de acesso às informações armazenadas no DW é a utilização da tecnologia OLAP – On-line Analytical Processing5, através da manipulação multidimensional ao qual permite aos usuários analisar os dados de acordo com a visão do negócio.

5.

Interfaces de filtragem e importação de dados

Tendo a preocupação de se ter uma interface que ajude os usuários a desempenhar as tarefas de alimentação de dados até a extração de informações, o sistema foi dividido em áreas com funções específicas e cada qual com a uma interface intuitiva sobre a sua função. Na implementação da interface para a extração/alimentação dos dados, dividiu-se em:

• Dados do almoxarifado: nesta interface foram importados os dados do sistema do almoxarifado, e validando os registros inválidos. Foram importados os dados das tabelas de unidade de medida, material, departamento, unidade de saúde, saídas e devolução. Estes foram inseridos nas respectivas tabelas e visualizados na view vw_saidamaterial, contendo os campos: codcness, codunidalmox, nomeunidade, saidanumero, data, codmaterial, descmaterial, quantidade, valortotal, codunidmedida, unidademedida e sigla;

• Dados da fonte do BPA: nesta interface foi importada a tabela de procedimento utilizado no BPA, para que seja compatível com a importação do arquivo de lote do

4 Extract Transform Load - Extração Transformação Carga. 5 Processo Analítico em Tempo Real.

(7)

sistema SIA/SUS. Os dados importados foram armazenados na tabela de procedimento, contendo os campos: codproctabelasus e descricao;

• Dados do SIA/SUS: nesta interface foram importados os dados do arquivo de lote gerado pelo sistema contendo a produção ambulatorial que é enviada ao Ministério da Saúde, mas somente das unidades sob responsabilidade da secretaria de saúde. Foram importados e armazenados na tabela produção, sendo visualizado na view vw_producao, contendo os campos: codproctabelasus, descricao, ativprofissional, tipoatendimento, grupoatendimento, faixaetaria, data, quantidade, valor, codunidalmox, codcness e nomeunidade;

• Inserção dos dados de fontes insuficientes: serão lançados os dados que não podem ser extraídos do sistema de contabilidade, em decorrência do mesmo ser tratado no nível de secretarias e não nas subdivisões internas das mesmas. Os dados lançados foram armazenados na tabela lancamentodiversos e visualizado na view vw_lancamentodiversos, contendo os campos: codcness, codunidalmox, nomeunidade, codlancamento, lancdescricao, data, valor, codtipolancamento, desctipolanc e tipolancamento;

• Emissão de relatório/gráficos: local onde os usuários poderão gerar os relatórios e gráficos dos dados armazenados no data warehouse, através da montagem de SQL através da seleção de itens de configuração;

• Interface de controle de usuários: local em que os usuários serão cadastrados e disponibilizados acessos a determinadas áreas do sistema, de acordo com o nível de necessidade.

6.

Utilização pelos usuários

Com a disponibilização do protótipo aos usuários, os mesmos poderão efetuar testes. Com isso, pode-se verificar e anotar as correções e/ou sugestões, para que seja efetuada a correção e/ou verificada a possibilidade técnica para a implementação das sugestões enviadas.

Na avaliação da usabilidade, procurou-se padronizar as telas e relatórios do sistema, conforme segue: as telas foram implementadas com um padrão para entrada e saída de dados, contendo botões de controle, navigators e widget (menus); não há variação de cores; captura e tratamento de erros gerados, com apresentação de uma mensagem intuitiva; todas as telas possuem um mecanismo de fechamento, evitando assim o fechamento automático; movimentação facilitada com a tecla “enter” entre os campos; o sistema possui os termos em seus menus, botões, telas e relatórios com termos utilizados pelos setores e relacionados às ações aos quais estão definidos; todas as telas possuem algum mecanismo de saída ou cancelar a operação; todos os botões possuem teclas de atalhos; as telas que fazem acesso a diversas tabelas, utilizam combo

(8)

7.

Resultados

Através do desenvolvimento do projeto, percebeu-se naturalmente uma melhoria nas definições do escopo do data warehouse, além da ampliação da área de aplicabilidade dos dados armazenados.

Com a utilização do parque tecnológico atual, deu-se plena capacidade de desenvolvimento do projeto, visto que a técnica de criação das tabelas-fato e as dimensões serem plenamente compatíveis com o recurso de views (visões) no SGBD Firebird, igualmente ao cubo teoricamente referenciado. A utilização de views como cubo pode ser aplicada dentro do próprio banco de dados dos sistemas de informação de nível operacional, mas é recomendável que seja em banco de dados diferentes para evitar sobrecarga de processamento nos sistemas transacionais. Neste caso, criou-se uma nova base de dados com todos os dados importados e tratados, para então compartilhar o acesso.

Para fins de teste, foram alimentados dados no data warehouse do período de 15 de maio de 2009 a 15 de agosto de 2009, resultando no seguinte volume de dados principais: saída de material, 101.142 registros; lançamentos diversos, 498 registros; material, 1.719 registros; procedimentos, 3.736 registros; produção, 144.167 registros; e unidades de saúde, 107 registros.

Na fase de importação, ocorreram diversos problemas devido à falta de integridade referencial, referente registros que foram apagados na tabela movim.dbf ou hismov.dbf, sendo o mesmo mantido na tabela saida.dbf, os mesmos foram descartados na importação. Na tabela movim.dbf foram encontrados erros como: o campo movsit em branco, como são lançamentos de saída foi atribuído o valor 1 que representa a saída; o campo movvrtot em branco, foi efetuado o cálculo do valor total e atribuído; o campo movdtatu em branco foi atribuído o valor do campo movdata, que são respectivamente data de movimentação e atualização de saldo. Já na tabela hismov.dbf encontraram-se valores negativos e zero para o campo hisqtdmov, que representam estornos e requisições que foram não atendidas e fechadas.

Tiveram de ser descartados os dados das unidades que são credenciadas no SUS, mas que não fazem parte da estrutura física da secretaria de saúde, devido aos mesmos apenas executarem os serviços, mas não utilizarem material físico ou humano da secretaria, assim, não fazem parte dos dados que serão analisados.

Com base nos dados armazenados, puderam ser emitidos inicialmente os seguintes relatórios:

• Do almoxarifado: listagem de saídas por unidade, material dispensado e período; gráfico e listagem totalizado de saídas por período; visualizar uma requisição de material; listar os materiais cadastrados e listar as devoluções.

• Da produção: listagem da produção ambulatorial por unidade, procedimento, tipo, grupo, faixa etária, atividade profissional e período; gráfico e listagem do totalizado da produção por período.

• Dos lançamentos diversos: listagem dos lançamentos diversos por unidade, tipo de lançamento, débito ou crédito e período; gráfico e listagem totalizado de lançamentos por período e débito ou crédito.

(9)

• Unidade de saúde: gráfico e listagem de habitantes; listagem das unidades cadastradas. • Consolidado: simples por período contendo a unidade com total de crédito e débito, sendo os créditos a produção ambulatorial e débito as despesas dos lançamentos diversos somando com as saídas do almoxarifado; detalhado por período contendo a unidade com total de débito discriminado em saída do almoxarifado e lançamento diverso e crédito discriminado em produção ambulatorial e lançamento diverso.

• Representando a granularidade da informação, desenvolveram-se os relatórios de: o Produção: anual, contendo o ano e o total produzido; mensal, contendo o mês, ano e total produzido; diário, contendo dia, mês, ano e total produzido; por unidade, contendo dia, mês, ano, unidade e total produzido; por procedimento, contendo dia, mês, ano, unidade, procedimento e total produzido; e detalhado, contendo todos os dados de produção de um determinado dia. Sendo neste navegado na mesma ordem que foi apresentada, partindo do macro visão até o micro visão dos dados armazenados.

o Saída almoxarifado: anual, contendo o ano e o total dispensado; mensal, contendo o mês, ano e total dispensado; diário, contendo dia, mês, ano e total dispensado; por unidade, contendo dia, mês, ano, unidade e total dispensado; por material dispensado, contendo dia, mês, ano, unidade, material dispensado e total dispensado; e detalhado, contendo todos os dados de saída de um determinado dia. Sendo neste navegado na mesma ordem que foi apresentada, partindo do macro visão até o micro visão dos dados armazenados, conforme a Figura 4.

Figura 4. Gerador de consulta para o Cubo de Saída do Almoxarifado

Cabe ressaltar que o relatório que mais foi utilizado pelo setor de almoxarifado foi o consolidado de saída de material por unidade solicitante, já que no sistema proprietário não era possível ter essa informação, era necessária a impressão de todas as requisições e depois somá-las para ter a quantidade total de material que uma unidade utilizou em um período. Economizou-se nisso em média 50 folhas por unidade solicitante.

8.

Conclusões

Com base nos dados apresentados, é notório a importância de continuação do processo de aprimoramento do data warehouse, bem como efetivá-lo como ferramenta de gestão

(10)

empresarial, não apenas um somador/totalizador de dados, mas sim um gerador e disseminador de conhecimento para toda a secretaria, auxiliando assim a agilidade na tomada de decisões. Também foi importante a visualização da diferença entre os valores apurados pela produção ambulatorial e os valores dos materiais dispensados para as unidades de saúde, demonstrando a diferença entre o material gasto para efetuar os atendimentos ambulatoriais e as quantidades de procedimentos ambulatoriais realizados pelas unidades de saúde.

Analisando a utilização de views como cubo para a abstração dos dados, além de ser um item muito interessante, traz bastante facilidade na implementação, destacando a vantagem de reduzir o número de consultas SQL complexas, permitindo ainda isolar as pesquisas dos usuários aos dados, facilitando que os setores façam também consultas importantes sobre o setor, bem como para o gestor analisar o desempenho da secretaria como um todo.

Pensando no processo de evolução do projeto faz-se necessário uma forma de tornar independente a base de dados do data warehouse das outras fontes de dados, não na forma de um processo previamente montado e codificado dentro do código-fonte, ficando como sugestão o desenvolvimento de uma nova camada de ligação entre o data

warehouse e as fontes de dados, que de forma parametrizada permita ligações dinâmicas

entre tabelas e campos de bancos de dados diferentes, tornando a configuração do ambiente de integração independente da equipe desenvolvimento.

Referências

BPA – Boletim de Produção Ambulatorial. Disponível em: http://w3.datasus.gov.br/datasus/index.php?area=040104. Acesso em 10/07/2008. Gonçalves, Marcio. Extração de Dados para Data Warehouse. Rio de Janeiro/RJ: Axcell

Books, 2003.

Graeml, Alexandre Reis. Sistemas de Informação: o alinhamento da estratégia de TI com a estratégia corporativa. 2ª Edição. São Paulo/SP: Atlas, 2003.

Jung, Carlos Fernando. Metodologia para Pesquisa & Desenvolvimento – Aplicada a Novas Tecnologias, Produtos e Processos. Rio de Janeiro/RJ: Axcel Books do Brasil, 2004.

Oliveira, W. J. Data Warehouse. Florianópolis/SC: Editora Visual Books, 2002.

PNGC – Programa Nacional de Gestão de Custos. Disponível em: http://www.anvisa.gov.br/institucional/snvs/descentralizacao/programa_gestao_custo s.pdf. Acesso em 05/10/2008.

Pressman, Roger S. Engenharia de Software. São Paulo/SP: Pearson Education do Brasil, 1995.

SIA/SUS - Sistema de Informações Ambulatoriais do SUS. http://w3.datasus.gov.br/datasus/index.php?area=040102. Acesso em 10/07/2008. Souki, Gustavo Quiroga, Zambalde, André Luiz. Fundamentos de Administração e

Informática Lavras/MG: UFLA/FAEPE, 2003.

PROCEDIMENTO

DIMENSÃO PROCEDIMENTO

Referências

Documentos relacionados

seria usada para o parafuso M6, foram utilizadas as equações 14 e 15, referentes aos parafusos de 8 mm de diâmetro e folga entre parafuso e furo de 0,5 mm, que definem,

No entanto, os resultados apresentados pelo --linalol não foram semelhantes, em parte, aos do linalol racêmico, uma vez que este apresenta um efeito vasorelaxante em anéis de

Este presente artigo é o resultado de um estudo de caso que buscou apresentar o surgimento da atividade turística dentro da favela de Paraisópolis, uma

Esta pesquisa apresentou resultados relevantes, pois mostrou que a proposição de um modelo aplicacional de Ensino por Investigação usando a Fotografia Científica

Estes resultados apontam para melhor capacidade de estabelecimento inicial do siratro, apresentando maior velocidade de emergência e percentual de cobertura do solo até os 60

Entendendo, então, como posto acima, propõe-se, com este trabalho, primeiramente estudar a Lei de Busca e Apreensão para dá-la a conhecer da melhor forma, fazendo o mesmo com o

A variação do pH da fase móvel, utilizando uma coluna C8 e o fluxo de 1,2 mL/min, permitiu o ajuste do tempo de retenção do lupeol em aproximadamente 6,2 minutos contribuindo para

The aim of this paper was two-folds: (i) to make a revision and an update of the state of the art about the relationships between swimming biomechanics with