UNIVERSIDADE FEDERAL DE SANTA CATARINA

Transcrição

1 UNIVERSIDADE FEDERAL DE SANTA CATARINA USO DE TECNOLOGIAS SEMÂNTICAS EM GOVERNANÇA DE TI MURILO SOARES LAGHI RODRIGO DANIEL LENGLER Florianópolis - SC 2011 / 1

2 UNIVERSIDADE FEDERAL DE SANTA CATARINA DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA CURSO DE SISTEMAS DE INFORMAÇÃO USO DE TECNOLOGIAS SEMÂNTICAS EM GOVERNANÇA DE TI AUTORES: MURILO SOARES LAGHI RODRIGO DANIEL LENGLER ORIENTADOR: ROBERTO CARLOS DOS SANTOS PACHECO CO-ORIENTADOR: MARCOS HENRIQUE DOS SANTOS Florianópolis - SC 2011 / 1

3 Murilo Soares Laghi Rodrigo Daniel Lengler USO DE TECNOLOGIAS SEMÂNTICAS EM GOVERNANÇA DE TI Este trabalho de graduação foi julgado adequado para obtenção do grau de Bacharel em Sistemas de Informação e aprovado em sua forma final pelo curso de Sistemas de Informação da Universidade Federal de Santa Catarina. Prof. Dr. Roberto Carlos dos Santos Pacheco Orientador Marcos Henrrique dos Santos Coorientador Prof. Dr. José Leomar Todesco Banca Examinadora

4 Não há vento favorável para aquele que não sabe para onde vai (Sêneca)

5 DEDICATÓRIA Dedicamos este trabalho aos nossos pais, pois sempre colocaram nossos estudos em primeiro lugar.

6 RESUMO O presente trabalho estende um modelo ontológico (OntoITIL), elaborado para apoio em Governança de TI, através da descrição de processos, apoiado nas boas práticas do ITIL. Utilizou-se de frameworks de manipulação de ontologias, raciocinadores autônomos e bancos de dados em testes de desempenho para mostrar a viabilidade da utilização deste modelo no contexto organizacional. Os experimentos realizados sobre o protótipo implementado no âmbito deste trabalho, demonstram que com as tecnologias corretas, é viável e benéfica a utilização de modelos semânticos no apoio a tomada de decisão. Palavras chave: Ontologias, ITIL, Governança em TI, Web Semântica

7 ABSTRACT The present paper extends an ontological model (OntoITIL), designed to support IT governance through the description of processes, supported by best practices of ITIL. It uses frameworks for ontologies manipulation, autonomous reasoners and databases in performance tests to show the feasibility of using this model within an organizational context. The experiments on the prototype implemented in this study show that with the right technologies, it is feasible and beneficial the use of semantic models to support decision making. Keywords: Ontologies, ITIL, IT Governance, Semantic Web

8 SUMÁRIO LISTA DE FIGURAS LISTA DE QUADROS LISTA DE TABELAS LISTA DE GRÁFICOS LISTA DE SIGLAS E ABREVIATURAS INTRODUÇÃO O problema Motivação Objetivos Objetivo Geral Objetivos Específicos Delimitação de escopo FUNDAMENTAÇÃO TEÓRICA Processos de Negócio Governança de TI ITIL Ontologias OntoITIL Reasoners... 25

9 2.6.1 Pellet PelletDB Owlgres Jena SDB SPARQL Bancos de dados PostgreSQL Oracle Oracle Database Semantic Technologies Considerações finais sobre o capítulo EXTENSÃO DA ONTOITIL Criação das propriedades de custo Criação do Centro de custos Avaliação da Extensão EXPERIMENTOS DE DESEMPENHO Frameworks e Bibliotecas utilizadas Estrutura das tabelas nos bancos de dados Estrutura de tabelas do Jena SDB Estrutura de tabelas do Oracle Semantic Technologies... 49

10 4.3 Execução dos testes I Testes em lote sobre a massa de dados M Teste 1 Seleção de pessoas (Person) Teste 2 Seleção de CIs Teste 3 Seleção de instâncias de um determinado software Testes sobre o modelo fictício Acme Teste 4 Busca de pessoas envolvidas no processo de Incident Handling Teste de carga com Bases M2 a M Teste de carga com Bases M20 a M Teste 1 Seleção de pessoas (Person) Teste 2 Seleção de CIs Teste 2 Execução de Testes II Testes com o reasoner interno do Oracle Semantic Teste de desempenho em carregamento, criação de entailment e consulta com Oracle Semantic Technologies Teste de desempenho em carregamento, atualização de entailment e consulta com Oracle Semantic Technologies Comparação entre os resultados dos testes e Teste com outra linguagem Análise geral dos resultados... 88

11 5 CONCLUSÃO Trabalhos Futuros REFERÊNCIAS Apendice A - Artigo Apendice B Códigos Fonte

12 LISTA DE FIGURAS Figura 1 - Performance do Pellet em ontologias comumente usadas de complexidade e expressividade variável. Os tempos são mostrados em segundos. Retirado de [16] Figura 2 - Resultados dos casos de teste na suíte DL de benchmark. Retirado de [16].. 29 Figura 3 - Amarração das ontologias CMDB e Process pela ITGov, formando a OntoITIL. Retirado de [13] Figura 4 Arquitetura do PelletDB. Retirado de [28] Figura 5 - OntoITIL com alterações realizadas Figura 6 Montante gasto com colaboradores Figura 7 - Custo mensal de cada CI Figura 8 - Custo mensal total dos CIs Figura 9 - Movimentação entre Centros de Custo Figura 10 - Teste de desempenho sobre bases de dados M1 a M10 por Santos [13] Figura 11 Retirado de [25]... 76

13 LISTA DE QUADROS Quadro 1 - Exemplo de consulta SPARQL Quadro 2 - Consulta do montante gasto com colaboradores Quadro 3 - Consulta do custo mensal de cada CI Quadro 4 - Consulta do custo mensal de todos os CIs Quadro 5 - Consulta de movimentações entre Centros de Custos da organização Quadro 6 - Consulta selecionando todas as instâncias de pessoas do banco M Quadro 7 Seleção de instâncias de CI da base M Quadro 8 Consulta em SPARQL para seleção de instâncias de random_software_master_copy_ Quadro 9 Consulta de todas as pessoas envolvidas no processo de Incident Handling 62 Quadro 10- Consulta SQL + SPARQL, no Oracle, de seleção de instâncias de Person Quadro 11 - Consulta SQL + SPARQL, no Oracle, de contagem de instâncias de Person Quadro 12 - Consulta SQL + SPARQL, no Oracle, de seleção de instâncias de CI Quadro 13 - Consulta SQL + SPARQL, no Oracle, de contagem de instâncias de CI Quadro 14 - Exemplo de código PHP para consulta sobre SQL+SPARQL no Oracle... 87

14 LISTA DE TABELAS Tabela 1 - Bases de dados para testes Tabela 2 Resultados obtidos nos testes de seleção de pessoas (Person) Tabela 3 - Resultados obtidos nos testes de seleção de CIs Tabela 4 - Resultados obtidos nos testes de seleção de instâncias de random_software_master_copy_ Tabela 5 - Resultados obtidos nos testes de seleção de pessoas envolvidas no processo de Incident Handling Tabela 6 Tempos de resposta para consulta SPARQL de seleção de instâncias de Person Tabela 7- Resultados da execução da query de seleção de Person nas diferentes combinações de ferramentas Tabela 8 Tempos obtidos com diferentes combinações de ferramentas sobre consulta de CIs em diferentes conjuntos de dados (M20 a M100 ) Tabela 9 Tempos obtidos para carregamento sequencial de conjuntos de dados de M_X01 a M_X10 e consultas SQL + SPARQL no Oracle Tabela 10 - Tempos obtidos para carregamento sequencial de conjuntos de dados de M_X01 a M_X20 e consultas SQL + SPARQL no Oracle... 83

15 LISTA DE GRÁFICOS Gráfico 1 - Tempos de consultas para diferentes combinações de ferramentas em uma sequência de massas de dados Gráfico 2 - Tempos de consultas para diferentes combinações de ferramentas em uma sequência de massas de dados Filtro Gráfico 3 - Tempos de consultas para diferentes combinações de ferramentas em uma sequencia de massas de dados - Filtro Gráfico 4 Tempo de resposta para execução de consulta SPARQL com combinações de ferramentas Gráfico 5 - Tempo de resposta para execução de consulta SPARQL com combinações de ferramentas Filtrado Gráfico 6 - Tempos de carga dos dados e criação de entailment para diferentes conjuntos de dados Gráfico 7 - Tempos de execução das consultas 1 a Gráfico 8- Tempo de carga e de atualização de index para cada conjunto de dados Gráfico 9 - Tempos de execução das consultas 1 a 4 no teste Gráfico 10 - Tempos de execução das consultas 1 a 4 no teste Filtrado Gráfico 11 - Comparativo entre o indicador de Triplas por Segundo dos modelos dos testes e

16 LISTA DE SIGLAS E ABREVIATURAS API BSC CMM CC CIO CI CMDB COBIT DML Application Programming Interface Balanced Scorecard Capability Maturity Model Centro de Custo Chief Information Officer Configuration Item Configuration Management Database Control Objectives for Information and related Technology Data Manipulation Language DL Descriptive Logic [30] DIG DL Implementation Group EL Existencial quantification [30] ITGOV ITIL NASA OWL OWL-DL OWL-Full PMI Information Technology Governance Information Technology Infraestucture Library National Aeronautics and Space Administration Ontology Web Language Ontology Web Language Descriptive Logic Ontology Web Language Full Project Management Institute QL Query Language [30] RDBMS RDF RDFS Relational Database Management System Resource Description Framework Resource Description Framework Schema RL Rule Language [30]

17 SGBD Sistema de Gerenciamento de Banco de Dados SGBDOR Sistema de Gerenciamento de Banco de Dados Objeto Relacional SPARQL SPARQL- DL SQL TI UML URI W3C SPARQL Protocol And RDF Query Language SPARQL Protocol And RDF Query Language Descriptive Logic Sructured Query Language Tecnologia da Informação Unified Modeling Language Uniform Resource Identifier Word Wide Web Consortium

18 1. INTRODUÇÃO A governança de TI é uma área contida dentro da governança corporativa. Tem ganhado atenção crescente, devido ao seu alto potencial de reversão de investimentos em maiores lucros, ou prejuízos pela falta deles. Ainda nos fatores motivadores para se fazer governança de TI, estão as necessidades de compliance e segurança da informação [21]. Com as necessidades de respostas cada vez mais rápidas às demandas que surgem, as organizações tem buscado ferramentas computacionais que auxiliem no controle das suas atividades e processos, que possam responder de maneira dinâmica a indagações dos gestores e que exercem papel de grande importância na governança de TI. Algumas das ferramentas atuais permitem a modelagem e controle dos processos, algumas associadas a modelos e frameworks de boas práticas como Cobit e ITIL, outras não. No entanto, ao se optar pelas ferramentas proprietárias (ou que utilizam modelos proprietários), as organizações limitam a capacidade de troca entre aplicações, devido aos formatos fechados, ou termos de contrato. Frente a este contexto, Marcos Santos [13] propôs um modelo ontológico, chamado de OntoITIL, que permite a utilização da grande expressividade das ontologias (além de seu formato ser aberto, facilitando a troca de dados e informações entre diferentes softwares e ambientes), combinado com boas práticas do ITIL. Somado a isso, com o auxílio de reasoners (raciocinadores de inferência) como o Pellet e o reasoner interno do Jena e a linguagem de consulta SPARQL, é possível fazer consultas que respondam perguntas estratégicas com alto grau de abstração, sem a necessidade de excessivos joins. 14

19 Tal modelo se mostrou eficaz na representação dos processos de uma organização e na capacidade de resposta a perguntas de cunho estratégico, porém ainda pouco eficiente para resposta de consultas de inferência (através das ferramentas testadas) para grandes organizações. 1.1 O problema No cenário atual, é possível encontrar ferramentas que modelem processos baseadas em modelos ou frameworks de melhores práticas. Porém, ao se escolher uma ferramenta fechada, a organização se prende a formatos e contratos proprietários, que na maioria das vezes, não estão aptos a trocas com outras ferramentas. Com este cenário em vista, Santos[13] propôs um modelo ontológico, que segundo ele, tinha a ideia de fazer uso de artefatos e ferramentas da Web Semânticas definidas pela W3C dentre elas as ontologias na forma de arquivos OWL e persistidas em banco de dados na modelagem dos processos do ITIL. Assim fornecendo uma abordagem alternativa, as quais qualidades como descentralização, especificação aberta, escalabilidade, adaptabilidade e flexibilidade podem ser distinguidas. A ideia deste trabalho é aperfeiçoar a ontologia OntoITIL (Ontologia criada por Santos [13]) acrescentando itens não previstos em sua versão atual, como por exemplo custo, paralelismo de servidores, para aumentar sua expressividade. A partir da extensão da ontologia, a ideia principal é verificar a viabilidade da utilização da mesma no contexto das organizações, especialmente de grande porte, com as ferramentas disponíveis atualmente. Uma vez que durante a criação da OntoITIL as ferramentas da época não davam conta de tarefas pesadas, como inferências complexas, a 15

20 verificação do estado de maturidade destas ferramentas (assim como o teste de outras ainda não verificadas), pode possibilitar a utilização prática do modelo proposto. Assim torna-se possível o alinhamento dos processos através da ontologia e o uso de raciocinadores para fazer inferências, respondendo perguntas (consultas de alto nível) que auxiliam na tomada de decisão (como por exemplo: Quais processos de negócio serão afetados com o desligamento de um determinado servidor da meia noite a uma da manhã?, ou: Qual o custo se desligarmos este seguimento de rede da meia noite a uma da manhã no domingo? [13]) e implantação de processos, dentre outros. 1.2 Motivação Com a competitividade existente entre as organizações, e a velocidade com que as coisas evoluem, organizações que conseguem ser flexíveis e se adaptar a novidades e a mudanças de estratégia, tem um diferencial importante. O tempo necessário para atualização de um sistema de médio porte é grande, principalmente no quesito estrutura dos dados. Somado com a busca crescente das organizações por tecnologias que auxiliem na tomada de decisão, na implementação, controle, otimização e qualidade de processos, aumenta a demanda por ferramentas que possam responder com alto desempenho e alto nível de abstração às perguntas dos gestores. Neste cenário, a TI e a governança de TI tem-se mostrado áreas nas quais bons investimentos podem trazer bons retornos [13]. A partir dos resultados do trabalho de Santos [13], constatou-se a viabilidade do modelo proposto por ele, que busca descrever processos através de uma ontologia baseada nas regras da W3C, juntamente com o framework de boas práticas ITIL. No entanto, para as ferramentas testadas durante a pesquisa feita por ele, o resultado obtido foi que 16

21 ainda era inviável a utilização para organizações de grande porte, devido as limitações das ferramentas, principalmente quanto ao desempenho. A motivação deste trabalho é viabilizar a representação de processos de organizações reais com maior fidelidade, possibilitando inferências com alto grau de abstração e flexibilidade em cenários de grande mudança. 1.3 Objetivos Objetivo Geral Mostrar a viabilidade do uso de modelos semânticos para construção de sistemas de apoio à Governança Corporativa a partir do aperfeiçoamento da ontologia OntoITIL[13] sob a perspectiva atual da tecnologia Objetivos Específicos Os objetivos específicos deste trabalho são: 1. Pesquisar, e testar ferramentas de manipulação de bases de dados semânticos. 2. Realizar testes de desempenho sobre as ferramentas pesquisadas com diferentes volumes de dados, e analisar os resultados. 3. Aperfeiçoar o modelo ontológico de definição de processo de negócio proposto por Santos [13], adicionando suporte a custos. 4. Mostrar a viabilidade e a vantagem do uso de ferramentas da Web Semântica para o apoio da governança corporativa em organizações. 17

22 1.4 Delimitação de escopo O presente trabalho não pretende explorar todas as ferramentas existentes, e nem mesmo chegar perto disso. Foram selecionadas algumas ferramentas, das quais algumas foram previamente utilizadas no trabalho de Santos [13]. Assim propõe-se avaliar o quanto amadureceram e se as versões lançadas até este momento evoluíram a ponto de atenderem as necessidades de desempenho exigidas no contexto das organizações, além de um comparativo com novas ferramentas pesquisadas. As ferramentas previamente selecionadas são Jena, Jena Semantic Adapter, Pellet, PelletDB, com os bancos de dados PostgreSQL, Oracle e Oracle com Semantic Technologies. Existem no mercado diversos outros raciocinadores de inferência, como pode ser visto na seção 2.5, que não serão testados. Existem também diversos outros SGBDs que não entrarão no escopo do trabalho. Não serão feitos testes exaustivos, apenas testes suficientes para uma avaliação da maturidade das ferramentas no contexto proposto. 18

23 2 FUNDAMENTAÇÃO TEÓRICA 2.1 Processos de Negócio Designam-se processos de negócio, ou processos organizacionais, ao conjunto de atividades organizadas, através da qual uma organização deve ser estruturada, com o objetivo de produzir valor (output) para os seus clientes. [1] O processo de negócio é uma série de atividades que ocorrem dentro de uma empresa que levam a um fim específico. Na maioria das vezes, o processo de negócio se concentra em atender as necessidades do cliente e entregar um bem ou serviço que irá atender a essa necessidade. Em muitos casos, o processo de negócio é na verdade um conjunto de processos inter-relacionados que funcionam em uma sequência lógica para alcançar o objetivo final. [2] A diferença entre Processo de Negócio e Função de Negócio é que a primeira é transacional (horizontal), á que perpassam diversas barreiras funcionais dentro da organização (ex.: adquirir bem, alienar bem, contratar funcionário), enquanto a segunda é vertical (ex.: contabilidade, vendas, logística).[1] 2.2 Governança de TI Governança de TI é um braço da Governança Corporativa, e sua premissa mais importante é o alinhamento entre as diretrizes e objetivos estratégicas da organização com as ações de TI. [3] Segundo João R. Peres, professor da FGV: 19

24 Governança de TI é um conjunto de práticas, padrões e relacionamentos estruturados, assumidos por executivos, gestores, técnicos e usuários de TI de uma organização, com a finalidade de garantir controles efetivos, ampliar os processos de segurança, minimizar os riscos, ampliar o desempenho, otimizar a aplicação de recursos, reduzir os custos, suportar as melhores decisões e consequentemente alinhar TI aos negócios. Outra definição que se encaixa em Governança de TI é de considerá-la como a Gestão da Gestão, demonstrando seu papel principal que é de auxiliar o CIO (Governante de TI) a avaliar os rumos a serem tomados para o alcance dos objetivos da organização, onde um direcionamento errado pode levar a empresa ao fracasso em pouco tempo. [3] Existem várias metodologias que dão suporte a governança de TI, CobiT (Control Objectives for Information and Related Technology), ITIL (Information Technology Infrastructure Library), PMI (Project Management Institute), CMM (Capability Maturity Model for software ) e BSC ( Balanced Scorecard). 2.3 ITIL Segundo a página oficial do mesmo [27], ITIL (Information Technology Infrastructure Library) pode ser definido como: ITIL is the most widely adopted approach for IT Service Management in the world. It provides a practical, no-nonsense framework for identifying, planning, delivering and supporting IT services to the business. Em tradução livre: 20

25 ITIL é a abordagem mais amplamente adotada para gerenciamento de serviços em TI no mundo. Provê um framework pratico, não absurdo, para identificação, planejamento, entrega e suporte aos serviços de TI para negócios O ITIL é um trabalho de compilação de melhores práticas propostas desde a década de 80, desenvolvido pelo (OGC) Office of Government Commerce, uma instituição do Reino Unido [13]. Busca promover a gestão com foco no cliente e na qualidade dos serviços de tecnologia da informação (TI), endereçando estruturas de processos para a gestão de uma organização de TI apresentando um conjunto abrangente de processos e procedimentos gerenciais, organizados em disciplinas, com os quais uma organização pode fazer sua gestão tática e operacional em vista de alcançar o alinhamento estratégico com os negócios [35]. volumes: O ITIL v3, publicado em maio de 2007, possui 26 processos, agrupados em cinco Estratégia do serviço (Service Strategy) Projeto de serviço ou Desenho de serviço(service Design) Transição do serviço (Service Transition) Operação do serviço (Service Operation) Melhoria contínua do serviço (Continual Service Improvement) 21

26 2.4 Ontologias Existem várias definições para ontologias, as mais famosas são: Uma ontologia define um domínio, ou, mais formalmente, especifica uma conceitualização acerca dele [Gruber 95] Uma ontologia é uma especificação explícita e formal de uma conceitualização compartilhada. [Studer et al 98] Segundo a Wikipédia (acesso em 28/02/2011 às 14:00), uma ontologia é um modelo de dados que representa um conjunto de conceitos dentro de um domínio. Essas ontologias são construídas a partir de conjuntos de triplas constituídas de Sujeito- Predicado-Objeto, que segundo Berners-Lee et al (2001), são parecidas com uma sentença linguística elementar constituída de sujeito, verbo e objeto. Vale lembrar que existem diferentes graus de genericidade [Gómez-Perez 99], são eles, em ordem decrescente de genericidade: Ontologias de representação, definidas de forma declarativa. Ontologias gerais (mais referenciadas na literatura), que trazem definições abstratas necessárias para a compreensão de aspectos do mundo, como tempo, processos, papéis, espaço, seres, coisas, etc. Ontologias centrais, também conhecidas como genéricas de domínio, que trazem conceitos mais genéricos e abstratos de uma determinada área de estudo. Ontologias de domínio, que tratam de um domínio mais especifico de uma área genérica citada acima. 22

27 Ontologias de aplicação, que são elaboradas buscando a solução de um problema específico de um domínio, referenciando termos de ontologias de domínio, citadas acima. Ontologias podem tanto ser desenvolvidas do zero como serem extensão ou adaptação de uma outra ontologia existente, através de reuso. Há também a possibilidade de realizar tradução de uma ontologia, o que permite a comunicação entre agentes em formalismos diferentes. Existem servidores online de ontologias, capazes de armazenar milhares de classes e instâncias, assim mantendo uma integridade do conhecimento compartilhado entre diferentes grupos de pesquisa e empresas. Existem alguns princípios a serem seguidos para manter a qualidade de uma ontologia [Gruber 93]. São eles: Clareza, legibilidade, coerência, extensibilidade, mínima codificação e mínimo compromisso ontológico. 2.5 OntoITIL OntoITIL é um modelo ontológico criado por Santos [13], que junta duas siglas Ontology (Onto) e Information Technology Infrastructure Library (ITIL). A OntoITIL foi criada com o objetivo de auxiliar no desenvolvimento de um projeto, que dispunha dos artefatos da Web Semântica para apoiar na implantação dos processos de negócios e de gerência de configuração do ITIL. Para tanto, foi necessária a cria- 23

28 ção de três ontologias, CMDB (Configuration Management Database), para definições dos itens de configuração do ITIL, Process, para definição de processos e ITGov, para amarração das duas ontologias. Figura 1 - Amarração das ontologias CMDB e Process pela ITGov, formando a OntoITIL. Retirado de [13] O conjunto final é chamado de OntoITIL e utilizando-se de reasoners de inferência, foi possível responder a consultas estratégicas como que permitem, por exemplo, conseguir avaliar o impacto de problemas em itens de configuração (software, hardware, etc.) nos processos de negócio. 24

29 2.6 Reasoners Um reasoner (raciocinador) é um componente essencial para trabalhar com ontologias OWL. Na verdade, praticamente todas as consultas de uma ontologia OWL são feitas utilizando um raciocinador. Isso ocorre porque o conhecimento em uma ontologia pode não estar explícito. Para isso, um raciocinador é necessário. Ele deduz o conhecimento implícito, para que os resultados da consulta sejam corretos. [5] Um raciocinador semântico, ou motor de regras, ou simplesmente um raciocinador, é um software capaz de inferir as consequências lógicas em um conjunto de regras (uma ontologia por exemplo). Alguns exemplos de raciocinadores são [6]: De licença proprietária: Bossam Dlog OWLIM RacerPro SHER OntoBroker Livres: CWM 25

30 Drools FaCT FaCT++ Hoolet Jena KAON2 Pellet Prova SweetRules HermiT Pellet Pellet é o raciocinador escolhido para os testes iniciais de viabilidade da ontologia em simulações de cenários do mundo real. Sua definição mais básica é: "Pellet is an open-source Java based OWL DL reasoner. It can be used in conjunction with both Jena and OWL API libraries and also provides a DIG interface" [15] Em tradução livre: "Pellet é um raciocinador de OWL DL de código aberto baseado em Java. Pode ser utilizado em conjunto com Jena e APIs OWL e também provê uma interface DIG". Além dos conjuntos padrões de serviços de inferência (consistência, satisfatibilidade, classificação e realização), e além dos sugeridos pela W3C (consistência, entailment e resposta a consultas conjuntivas), foram introduzidos diversos serviços não pa- 26

31 drões na implementação do Pellet, os quais acredita-se serem indispensáveis para o uso prático, como por exemplo serviços para explicar e depurar ontologias. [16] Sua cobertura abrange tudo de OWL-DL, incluindo propriedades inversas e transitivas, restrições de cardinalidade, raciocínio de tipos de dados incluindo schemas XML simples definidos pelo usuário, classes enumeradas (também chamadas de nominais) e afirmações de instâncias. Apesar de ser um raciocinador de Lógica de Descrição (DL), ele foi feito para trabalhar com OWL desde o começo. Além disso, ele contém diversas heurísticas que possibilitam determinar se um documento OWL-Full pode ser transformado em um documento OWL-DL. As heurísticas implementadas tentam adivinhar o tipo correto para um recurso não tipado. Como exemplo, um recurso não tipado usado na posição de predicato, é inferido como sendo uma propriedade. [16] Uma avaliação de performance do Pellet para tarefas de verificação de consistência, classificação, realização e resposta a consultas conjuntivas foi realizada. Foi utilizada a seguinte configuração: Pentium Centrino 1.6GHz com 1.5 GB de memória ram, com o máximo de memória alocada para o Java definido em 256MB para cada experimento. Todos os tempos apresentados foram computados como a média de 10 rodadas independentes. [16] 27

32 Figura 2 - Performance do Pellet em ontologias comumente usadas de complexidade e expressividade variável. Os tempos são mostrados em segundos. Retirado de [16] Na figura 1, estão listados os tempos para carregamento, verificação de consistência, classificação e realização para ontologias já conhecidas,de diferentes fontes e projetos, como do guia OWL, da NASA, etc. [16] Na figura 2 estão os resultados do tempo de classificação de diferentes raciocinadores DL (de Lógica de Descrição), para algumas ontologias incluídas nos conjunto de teste padrão de benchmark. Nestes testes, o Pellet (versão 1.3) é comparado com outros dois raciocinadores, o FaCT e o RacerPro [16] 28

33 Figura 3 - Resultados dos casos de teste na suíte DL de benchmark. Retirado de [16] Como resultado, tem-se que o Pellet não é tão eficiente como o RacerPro ou o FaCT++ para a classificação, mas tem uma performance bastante aceitável. A maior diferença é vista em casos que não são muito significantes para aplicações. Ainda assim, para a ontologia médica Galen, o Pellet ainda é 9 vezes mais rápido que o FaCT++. [16] Por fim, em um teste de performance para resposta de consultas, onde só foram utilizados o Pellet e o RacerPro, pois o Fact++ não provê suporte para raciocinar sobre instâncias, o Pellet se mostrou muito superior ao RacerPro, na verificação de consistência, além do fato de que o RacerPro não conseguiu completar um dos testes, enquanto o Pellet levou 22 segundos. [16] Estes experimentos permitiram concluir que o Pellet não é tão eficiente quanto o FaCT++ ou o RacerPro na maioria das tarefas. No entanto, sua performance ainda é competitiva para aplicações do mundo real, além de possibilitar ver que o Pellet raciocina 29

34 bem em cima de um grande número de instâncias. [16] Constatando os resultados destes testes, pode-se entender o porque de ser uma ferramenta tão largamente utilizada, indo de projetos puramente acadêmicos a projetos de porte industrial. Pellet atualmente está na versão e seu download pode feito em [22] PelletDB Segundo a página do software [32] o Pellet DB é o primeiro e único reasoner OWL 2 para Oracle 11G R2, provendo raciocínio correto e escalável sobre OWL. Desenvolvido a partir do Pellet 2.0 e do Oracle Semantic Technologies, o PelletDB provê uma solução integrada para raciocínio OWL2. Ele é otimizado para o sistema RDF, OWL e SPARQL do Oracle. Na página do reasoner [32] não há referência ao valor da licença, a qual é disponibilizada por um período grátis para teste de 30 dias, porém em trocas de com os desenvolvedores, o valor da licença informado foi de $ (dez mil dólares). Ao questionar os responsáveis pela área de vendas do projeto sobre licenças acadêmicas para projetos de estudo como o presente trabalho, foi informado da não existência das mesmas, mas da possibilidade de reinstalar a licença por mais 30 dias realizando um novo download, e se necessário, entrar novamente em contato para que analisassem o caso. Para utilização do PelletDB é necessário ter instalado o Oracle Database 11g Release 2 na versão Enterprise Edition (utilizada neste projeto) ou superior, com Oracle Spatial e Oracle Partitioning ativados, além da instalação do pacote Oracle Semantic Technologies, Jena Adaptor para Banco de dados Oracle 11g Release2, Jena e JDK 1.5 (neste projeto foi utilizada JDK 1.6, sem problemas de compatibilidade). 30

35 Figura 4 Arquitetura do PelletDB. Retirado de [28] PelletDB apresenta diversas otimizações em relação ao Pellet comum. Um exemplo é a carga de dados (do banco para memória) que o Pellet faz de bancos de dados relacionais através da interface do Jena, em que são executadas diversas consultas. Com o PelletDB, essa carga dos dados é otimizada, de forma que é possível carregar todo o schema da ontologia LUBM [29] (por exemplo), em apenas 3 segundos [28]. Através do PelletDB, é possível salvar as inferências no Oracle, de maneira não trivial, se configurado para tal. Inferências como toda classe é uma subclasse dela mesma não são salvas, para não reduzir a eficiência da busca, com dados desnecessários. Além disso, é possível trazer para memória apenas o schema do modelo semântico, computar as inferências, salvá-las no banco e depois disso fazer consultas pelas inferências salvas. [28] [30] Por fim, PelletDB cobre toda a expressividade das linguagens OWL 1 e 2, passando por todas as famílias de linguagens descritas em [31] (DL, EL, QL e RL). 31

36 2.6.3 Owlgres Owlgres é um raciocinador DL-Lite escalável, open source, escrito para PostgreSQL. Ele visa tanto consultas eficientes sobre uma base escalável e persistente como raciocínio automático para arquivos RDF e OWL. Atualmente, o Owlgres implementa três tipos de otimização: a simplificação da consulta, otimização seletiva e a formulação de um conjunto de queries para uma simples query SQL UNION [20]. Descrevendo um pouco cada uma das otimizações realizadas temos: Simplificação: é feita durante o processo de reformulação e é aplicada a query inicial. O objetivo desta simplificação é eliminar coisas desnecessárias, como redundâncias [20]. Otimização Seletiva: é baseada no conceito de seletividade, definido por Piatesky- Shapiro e Connell como fração de tuplas que satisfazem a condição. No owlgres, estão particularmente interessados em saber qual query tem seletividade zero. Se uma parte de um conjunto de querys tem seletividade zero, então todo o conjunto terá também seletividade zero [20]. Por fim, a última otimização (transformação de um conjunto de queries em uma única query com union), tem ao menos duas vantagens. Primeiro, uma query única, evita multiplas conexões no banco de dados, evitando assim sobrecarga. Segundo, é explorado o otimizador nativo, provendo uma query complexa que pode ser otimizada pelo RDBMS (Sistema Gerenciador de Banco de dados Relacional, do Inglês, Relacional Database Management System) [20]. A última versão que se tem informação, inclusive no site ( é a versão 0.1 (alpha), datada de 7 de maio de

37 2.6.4 Jena O projeto Jena é definido como: Jena is a Java framework for building Semantic Web applications. It provides a programmatic environment for RDF, RDFS and OWL, SPARQL and includes a rule-based inference engine [17] Em tradução livre: Jena é um framework Java para criação de aplicações para a Web Semântica. Ele provê um ambiente de programação para RDF, RDFS e OWL, SPARQL e inclui um mecanismo de inferência baseado em regras Dentro do Jena existe uma API para RDF, uma API para OWL, um mecanismo de inferência (raciocinador) além da possibilidade de se utilizar armazenamento em memória ou persistente. Suas APIs para RDF e para OWL permitem a manipulação de ontologias, através da manipulação de sentenças, sendo tratada como um conjunto de triplas e através da manipulação de recursos, tratada como um conjunto de recursos e propriedades. [18] O Jena trata as ontologias como grafos, contendo classes para a representação de grafos, recursos, propriedades e literais. Os grafos são chamados de modelos e são representados pela interface Model. Para a criação de um grafo, é necessária a criação de um modelo vazio, através da classe ModelFactory. A partir do objeto criado pela classe ModelFactory, criam-se os recursos (no caso de utilização do armazenamento em memória), que serão manipulados para o preenchimento de propriedades. [19] 33

38 Jena atualmente se encontra na versão e é mantido pela HP SDB SDB é um componente de Jena. Ele provê um armazenamento escalável e query em conjunto de dados RDF usando bases de dados SQL convencionais em aplicações standalone, J2EE e outros frameworks. As ferramentas de base de dados para carregamento, segurança, cluster, backup e administração podem ser usadas para gerenciar instalações, através de código escrito em Java ou linha de comando. O SDB é designado especificamente para suportar SPARQL [23]. 2.7 SPARQL SPARQL é uma linguagem de consultas a bases RDF e é uma recomendação W3C. Seu uso permite a construção de consultas através de diversas fontes de dados, sejam os dados nativos RDF ou visualizados como RDF através de um middleware [12]. Dentre suas variantes, encontra-se o SPARQL-DL, cuja expressividade é voltada aos blocos de OWL-DL [13]. na África? [14]: Abaixo segue um exemplo de consulta, que retorna quais as capitais dos países PREFIX abc: < SELECT?capital?country WHERE {?x abc:cityname?capital ; abc:iscapitalof?y.?y abc:countryname?country ; abc:isincontinent abc:africa. } 34 Quadro 1 - Exemplo de consulta SPARQL

39 Na primeira linha é definido o prefixo, para evitar a utilização de URIs longas dentro das cláusulas que seguem. Neste exemplo é definido apenas um prefixo, mas pode-se definir mais de um, de acordo com a necessidade, bastando colocá-lo em uma nova linha. A segunda linha contém a instrução SELECT, com que define a projeção das variáveis seguintes [13]. As quatro linhas dentro das chaves que seguem a instrução WHE- RE são as cláusulas de consulta, definidas por quatro padrões de triplas. O mecanismo de busca irá buscar apenas triplas que satisfaçam os quatro padrões [14] Bancos de dados Bancos de dados são mecanismos utilizados para o armazenamento de dados. Para o presente trabalho, os bancos de dados serão utilizados juntamente com os raciocinadores (ver seção 2.5) para realizar consultas nas instâncias da ontologia, de modo a não precisar carregar tudo em memória. Os SGBDs (Sistema de Gerenciamento de Banco de Dados) escolhidos para testes são o PostgreSQL e o Oracle. 35

40 PostgreSQL O PostgreSQL é um Sistema Gerenciador de Banco de Dados Objeto Relacional (SGBDOR), open-source, coordenado pelo PostgreSQL Global Development Group. Além de doações, o projeto PostgreSQL se sustenta pelo patrocínio de diversas empresas, entre as quais se destacam: Fujitsu, Hub.Org, NTT Group, Red Hat, Skype, SRA e Sun Microsystems. Hoje o PostgreSQL conta com recursos avançados, como consultas complexas, chaves estrangeiras, integridade transacional, controle de concorrência e multi-versão, suporte ao modelo híbrido objeto-relacional, gatilhos, linguagem procedural, indexação por texto e estrutura para guardar dados georeferenciados (PostGIS). Sua primeira versão protótipo é de Sua versão mais recente é a Oracle O Oracle é um Sistema Gerenciador de Banco de Dados (SGBD) proprietário, líder de mercado, que surgiu no fim dos anos 70. Encontra-se hoje na versão 11g e é comercializada em várias edições que variam entre Enterpreise Edition (Cuja licença pode chegar a mais de 47 mil dólares por processador [11]), Standard Edition, Standard Editon One, Express Edition, Personal Edition e a Oracle Database Lite, destinada a rodar em dispositivos móveis. No Brasil, existem dezenas de grandes empresas que utilizam Oracle, muitas com histórias de sucesso cadastradas no próprio site [11], entre elas estão Petrobras, Ipiranga, TAM, TV Globo, Abril, Claro, Itautec, Mundial e Vale. 36

41 O Oracle compete com outros SGBDs de licença comercial, como o Microsoft SQL Server e o IBM DB2, e também com alguns SGBDs open-source como o PostgreSQL, Firebird e o MySQL, o qual agora pertence a Oracle Corporation, pois a mesma recentemente adiquiriu a Sun Microsystems, dona do MySQL Oracle Database Semantic Technologies Oracle Database Semantic Technologies faz parte do Oracle Spatial 11g, encontrado na versão Enterprise do Oracle. Ele provê uma capacidade de gerenciamento não encontrada em nenhum armazenador de tripla, comercial ou não [24] O ferramental provido pela tecnologia semântica do Oracle inclui uma série de itens que vão desde segurança de acesso a triplas, formas de gerenciamento até integração com ferramentas de terceiros. Não cabe no presente trabalho entrar em detalhes sobre todas essas features, mas é importante destacar pelo menos três delas, além da possibilidade de armazenamento, carga e operações DML sobre as triplas. Em primeiro lugar, o mecanismo de inferência nativo. Com ele é possível fazer inferências escaláveis, usando os principais subconjuntos de OWL. É possível utilizar as principais regras de RDF e RDFS, assim como definir regras próprias de entailment. Se configurado para tal, ao se atualizar um modelo semântico, o entailment (índices de regras), é automaticamente atualizado através de inferências incrementais, que tornam essa atualização muito eficiente. Por fim, é possível fazer diferentes configurações de acordo com a especificação da máquina para que se obtenha melhor desempenho, como por exemplo, para utilização de paralelismo em máquinas multi-core. Em segundo lugar, as consultas por dados semânticos no banco de dados. É possível a utilização de comandos inseridos dentro de uma consulta SQL, para busca de da- 37

42 dos nos modelos semânticos, através da função SEM_MATCH. Com ela, é possível fazer consultas com a linguagem SPARQL, suportando a maioria dos requerimentos da W3C. E por último, uma feature que também merece destaque é a indexação semântica de documentos. Através do uso de ferramentas de terceiros de extração e anotação de documentos não estruturados (armazenados em bancos de dados relacionais), são localizados dados significativos e armazenados em documentos indexados semanticamente. Depois desta extração, é possível fazer consultas aos mesmos, através de operadores especiais utilizados dentro do SQL como SEM_CONTAINS Considerações finais sobre o capítulo Como já mostrado, a Governança de TI apoia a governança corporativa, alinhando os objetivos da organização com as ações realizadas em relação à TI. Uma das metodologias de Governança de TI é o ITIL, que compila melhores práticas de governança. O uso de sistemas de informação no apoio a gestão estratégica destas organizações tem se tornado fundamental frente às necessidades estratégicas de tomada de decisão. A medida que crescem as organizações, cresce a complexidade de gerência das mesmas. Na construção destes sistemas, o uso de tecnologias semânticas pode ser um diferencial. Neste cenário, ontologias podem ser utilizadas para definição de conceitos, de processos e de todo um conjunto de recursos da organização, e.g. OntoITIL. Estes conceitos podem ser armazenados através de triplas em bancos de dados e com a utilização de raciocinadores, pode ser realizada pesquisa com inferência, assim trazendo informações de cunho operacional a estratégico, auxiliando na tomada de decisões. 38

43 3 EXTENSÃO DA ONTOITIL Com o objetivo de adicionar um suporte para governança corporativa, julgou-se necessário estender a OntoITIL, adicionando a capacidade da mesma entender custos. Assim, torna-se possível fazer consultas de inferências sobre a base de dados corporativa, visualizando facilmente dados relativos às questões financeiras, obtendo como resultados informações de grande valor para tomada de decisão. Todas as modificações foram feitas na ontologia ITGov, mantendo as ontologias a qual ela estende (CMDB e Process) sem alterações. Abaixo uma figura similar a Figura 1, porém atualizada com a extensão realizada. 39

44 Figura 5 - OntoITIL com alterações realizadas 3.1 Criação das propriedades de custo Em contabilidade existem diferentes tipos de custos. Para este trabalho, foram identificados como necessários para o que se pretendia, utilizar-se de 3 custos principais. Custo de reposição: Inicialmente pensou-se para este item, fazer utilização de custo patrimonial, porém, identificando a necessidade em governança, optou-se por custo de reposição. Um custo 40

45 patrimonial não englobaria diversas informações, as quais são na realidade, o objetivo do modelo. Além disso, um custo patrimonial não traria uma boa impressão quando apontado para uma pessoa, por não ter uma semântica adequada. Sendo assim, foi criada na ontologia ITGov, uma data property chamada has_replacement_cost a qual foi atribuída a classe CI (Configuration Item) da ontologia CMDB, estendida pela ontologia ITGov. Todo item de configuração (que engloba tanto objetos físicos, pessoas, softwares e serviços), tem um custo de reposição. Pode ser usado tanto para obter o custo de reposição de um servidor que venha a apresentar defeito (resultando na soma dos custos de compra do novo aparelho, somado ao custo do serviço de troca, da configuração do mesmo, etc.), até o custo de um colaborador que venha a deixar a equipe (englobando custos de seleção de um novo colaborador, mais o custo de treinamento dessa nova pessoa para o cargo, etc.). Utilizando novamente os dois exemplos acima, caso utilizado custo patrimonial, para o primeiro caso, ao tentar verificar o impacto da perda deste servidor, teríamos apenas o custo do servidor em si, mas não os outros custos como da troca do mesmo, a configuração, etc. Não se aproximando da realidade pretendida. Para o caso do colaborador, seria impossível precificar o valor de uma pessoa, pois se trata de uma vida e não de um objeto, além de trazer a impressão de a pessoa ser propriedade da empresa. Custo Mensal Foi criada também na ontologia ITGov, uma data property chamada has_monthly_cost, também atribuída a classe CI da ontologia CMDB. Esta propriedade define outro tipo de custo, o custo mensal fixo de um CI. 41

46 Voltando aos exemplos citados para o custo acima, no caso do Servidor, teríamos neste campo o valor da soma dos seus custos mensais, como gasto de energia elétrica, refrigeração, alocação física do equipamento, manutenção, custo com licenças de softwares do servidor, etc. No caso de um Colaborador, temos o salário do mesmo, benefícios como VA, VT, seguro, plano de saúde, alocação de espaço físico, etc. Custo de Transação É o custo correspondente a realização de uma transação/transformação/processo. Para solução deste custo, foi criada na ontologia ITGov, uma data property chamada has_value, atribuída a classe Data_container da ontologia Process, a qual a ontologia ITGov estende. Somado a isso, foi inserida também outra propriedade chamada de has_datetime, que armazena a data da realização deste processo, o que torna possível a filtragem nas pesquisas realizadas posteriormente sobre a o modelo semântico. Com as três informações acima, faz-se possível responder perguntas estratégicas com eficiência e eficácia. Estas mesmas perguntas demandariam um tempo e conhecimento profundo para se responder com outros modelos de dados (como modelos relacionais), por serem de alta complexidade. Outros valores podem ser obtidos a partir de consultas realizadas sobre os três custos criados, como por exemplo, o lucro: basta selecionar o valor do insumo após o processo e subtrair o valor do custo da transação do mesmo. 42

47 3.2 Criação do Centro de custos "Em princípio, centros de custos são departamentos de área de produção diferenciados segundo a função de cada um no processo produtivo. Por vezes, essa diferenciação está mais ligada ao fator econômico, em vista da maior ou menor uniformidade de custos incorridos nas várias funções, do que sob o ponto de vista tecnológico, pois este está mais ligado à natureza das fases de processo." Retirado de [33] Com esta ideia, e apoiado pela governança corporativa, decidiu-se criar uma nova classe na ontologia ITGov, chamada de Cost_center. Com esta classe foi possível criar centros de custo. Um CC (centro de custo) possui uma data property chamada has_name, que informa o nome deste CC, além de uma object property chamada has_parent, que liga um CC a outro CC, criando assim uma hierarquia de centros de custo. Além disso, foram criadas outras duas object properties ligando a classe Data_container da ontologia Process à classe Cost_center da ontologia ITGov, são elas has_input_cost_center e has_output_cost_center. Essas duas propriedades definem qual o CC de entrada e qual o CC de saída de uma transação, inferindo assim a qual CC será creditado e a qual CC será debitado o valor que se encontra na data property has_value, da classe Data_container. Com isso é possível mapear todas as transações e os custos envolvidos. 43

48 3.3 Avaliação da Extensão As extensões feitas permitem vislumbrar parte do contexto financeiro da organização, que não era possível na versão anterior da ontologia. Com o intuito de comprovar a aplicação prática deste novo modelo, foram elaboradas algumas questões que se assemelhariam ao cotidiano de um gestor no momento de uma tomada de decisão. Foram feitas algumas alterações na ontologia Acme (mais detalhes sobre ela em 4.3.1), adicionando as novas propriedades de custo a alguns colaboradores, servidores e criando dois centros de custo. Alguns exemplos de perguntas que poderiam ser respondidas estão listadas a seguir: a) Qual o montante total gasto mensalmente com colaboradores? Traduzindo em um consulta simples no quadro abaixo: SELECT SUM(y) as Total_Person FROM TABLE( SEM_MATCH( '{?x rdf:type :Person.?x itgov:has_monthly_cost?y}', SEM_Models('ONTOITIL'), SEM_Rulebases('OWLPRIME'), SEM_ALIASES( SEM_ALIAS('',' SEM_ALIAS('itgov',' ') ), null) ) Quadro 2 - Consulta do montante gasto com colaboradores 44

49 E a resposta obtida é mostrada na Figura 6: Figura 6 Montante gasto com colaboradores b) Qual o custo mensal de cada CI (vale lembrar que CI compreende todos os itens de configuração, desde pessoas até espaço físico)? SELECT x as CI, y as Custo_CI FROM TABLE(SEM_MATCH( '{?x rdf:type :CI.?x itgov:has_monthly_cost?y}', SEM_Models('ONTOITIL'), SEM_Rulebases('OWLPRIME'), SEM_ALIASES(SEM_ALIAS('',' SEM_ALIAS('itgov',' ), null)) Quadro 3 - Consulta do custo mensal de cada CI Obtendo-se o retorno mostrado na Figura 7: Figura 7 - Custo mensal de cada CI 45

50 c) Qual o custo mensal total de todos os CIs? SELECT SUM(y) as Total_CIs FROM TABLE(SEM_MATCH( '{?x rdf:type :CI.?x itgov:has_monthly_cost?y}', SEM_Models('ONTOITIL'), SEM_Rulebases('OWLPRIME'), SEM_ALIASES(SEM_ALIAS('',' SEM_ALIAS('itgov',' ), null)) Quadro 4 - Consulta do custo mensal de todos os CIs Cuja resposta obtida está na Figura 8: Figura 8 - Custo mensal total dos CIs d) Quais as movimentações de custos entre os Centros de Custo da organização e qual o valor das mesmas? SELECT x as DATA_CONTAINER, y as INPUT_COST_CENTER, z as OUTPUT_COST_CENTER, w as VALOR_MOVIMENTADO FROM TABLE(SEM_MATCH( '{?x itgov:has_input_cost_center?ic.?ic itgov:has_name?y.?x itgov:has_output_cost_center?oc.?oc itgov:has_name?z.?x itgov:has_value?w}', SEM_Models('ONTOITIL'), SEM_Rulebases('OWLPRIME'), 46

51 SEM_ALIASES(SEM_ALIAS('',' SEM_ALIAS('itgov',' ), null)) Quadro 5 - Consulta de movimentações entre Centros de Custos da organização Cujo retorno é apresentado na Figura 9: Figura 9 - Movimentação entre Centros de Custo Além destas questões, outras mais pontuais, poderiam ser feitas, envolvendo a busca por datas ou intervalos de tempo específicos, possibilitando limitar as respostas no tempo. Com o atributo has_datetime fica fácil criar relatórios organizados historicamente, fazer análises no tempo, avaliar atrasos, etc. 4 EXPERIMENTOS DE DESEMPENHO 4.1 Frameworks e Bibliotecas utilizadas Para execução de testes de desempenho, foram utilizadas diferentes combinações de frameworks, reasoners, bancos de dados e bibliotecas Java. Em alguns casos, foi necessário utilizar versões que não correspondiam ao último lançamento por questões de compatibilidade. Apenas para exemplificar: foi necessário utilizar a versão da API ARQ (que faz parte do Jena), nos testes executados com PelletDB, pois as versões e utilizadas nos testes com Jena Adapter + Oracle Semantic e Jena + Pellet + Ora- 47

52 cle/postgres respectivamente, não foram compatíveis. Abaixo estão listadas as combinações usadas e entre parêntesis, a sigla utilizada ao longo deste documento para referenciá-las. Jena + Postgres (JP): Jena 2.6.3, PostgreSQL 9.0 Jena + Oracle (JO): Jena 2.6.3, Oracle 11g R2 Jena + Pellet + Postgres (JPP): Jena 2.6.3, Pellet 2.2.2, PostgreSQL 9.0 Jena + Pellet + Oracle (JPO): Jena 2.6.3, Pellet 2.2.2, Oracle 11g R2 Jena Adapter + Oracle Semantic (JOS): Jena 2.6.4, Jena Adapter for Oracle Database 11g R2, Oracle 11g R2 com Semantic Technologies. Jena Adapter + Pellet + Oracle Semantic (JAPOS): Jena 2.6.4, Jena Adapter for Oracle Database 11g R2, Pellet 2.2.2, Oracle 11g R2 com Semantic Technologies Jena Adapter + PelletDB + Oracle Semantic (JPDBOS): Jena 2.6.2, PelletDB 1.0, Oracle 11g R2 com Semantic Technologies Para a codificação e execução dos testes, foi utilizada a IDE Eclipse versão Helios Service Release 2 juntamente com JavaSE Estrutura das tabelas nos bancos de dados O carregamento dos arquivos owl que continham as definições das ontologias (regras e instâncias) para os bancos foi feito através do Jena e Jena Adapter. A criação das tabelas no banco é feita automaticamente pelo Jena. 48

53 4.2.1 Estrutura de tabelas do Jena SDB A estrutura de tabelas criada pelo SDB é a evolução da estrutura que era criada pelo antigo RDB Maker do Jena (em versões mais antigas). São criadas quatro tabelas, das quais uma serve para armazenamento de triplas e outra para armazenamento das declarações. Para utilização através da interface provida pelo Jena, o esquema criado funciona bem, atendendo a solicitações de maneira bastante eficiente e de com um alto nível de abstração, uma vez que pode-se utilizar SPARQL para busca de dados. No entanto, para integração com outras aplicações que não façam uso do Jena, um entendimento do seu núcleo pode ser necessário, uma vez que não há comandos em SPARQL disponíveis para utilização diretamente no banco (apenas pela interface provida pelo Jena) Estrutura de tabelas do Oracle Semantic Technologies Diferentemente do SDB, ao se utilizar o Jena Adapter para carregamento dos dados, é criado um modelo semântico no Oracle, através de chamadas a procedures da API Semântica do mesmo. A estrutura que é criada conta com duas tabelas no schema do usuário, além de algumas views para utilização do DBA (no usuário do MDSYS, que é o usuário para DBA). Uma das tabelas criadas é a tabela de namespaces, que armazena todos os prefixos e respectivos namespaces encontrados nas ontologias. A outra tabela é a tabela de triplas, que tem apenas uma coluna, do tipo sdo_rdf_triple_s, que armazena triplas RDF. 49

54 Para utilização com Jena e Pellet (através da interface do Jena), o simples carregamento do modelo no banco (que já faz a criação do modelo caso não exista) é suficiente. Porém, a criação de regras semânticas não é feita automaticamente pelo Jena. Sendo assim, para consultas de inferência utilizando o reasoner interno do Oracle é necessária a criação do entailment (índices de regras) manualmente. No que diz respeito à criação das tabelas no banco, é fácil criar um modelo semântico através de comandos SQL (por chamada de procedures da API semântica). A inserção de triplas através de SQL é simples, no entanto para a carga de massas de dado se torna inviável. Não foi estudada a forma de carga de lotes provida pelas APIs do Oracle, de forma que não é possível fazer afirmações acerca da mesma. A principal vantagem encontrada na utilização dos modelos semânticos do Oracle, é que se pode facilmente fazer integração com outras aplicações sem a necessidade da utilização do Jena como interface. 4.3 Execução dos testes I Para realização dos testes alguns padrões foram seguidos para manter a consistência dos testes realizados, principalmente a igualdade nos testes realizados com diferentes combinações de ferramentas. Quanto à marcação de tempo de consulta: foi utilizada, em todos os testes uma mesma classe de controle, (Timers), provida pela API do Pellet e PelletDB. O início do cronómetro (chamada da função start) deu-se logo antes da criação da consulta a partir do modelo semântico testado (objetos de consulta), e o fim do cronómetro (chamada da função stop) logo após a execução da mesma. Desta forma, não foi contado o tempo ne- 50

55 cessário para impressão do resultado, tempo este, que não apresenta mudanças significativas entre os diferentes modelos semânticos testados. A precisão utilizada pela classe Timers nos testes foi de milissegundos. Quanto à máquina que executou os testes: Todos os testes foram executados em uma mesma máquina, preparada exclusivamente para execução dos mesmos, mantendo assim a consistência das comparações realizadas, um Core 2 Duo, T7500, 2.20GHz com 2GB de DDR e Sistema operacional Windows XP. Uma série de massas de dados foi importada e adaptada dos testes executados por Santos [13], como os itens de M1 a M10 da tabela abaixo. Foram criadas, utilizando M10 como base, outras bases para testes com mais indivíduos e testes de carga, itens M20 a M100. Abaixo na Tabela 1 mais informação sobre cada uma das bases, que serão referenciadas posteriormente nos testes e gráficos deste trabalho. Nome da Base Indivíduos Usuários Triplas Estruturas Disjuntas M M M M M M M

56 M M M M M M M M M M M M Tabela 1 - Bases de dados para testes O modelo testado permite responder uma ampla gama de perguntas estratégicas como por exemplo: Quais os envolvidos no processo X?, Se o servidor y parar, quais itens de configuração serão impactados?, Qual o custo mensal de todos os itens de configuração envolvidos no processo z?, Quais os elementos de processo que irão parar caso determinado elemento pare?. Para os testes realizados foram utilizadas algumas consultas simples porem especificas para realização destes testes, exemplificando alguns casos. Algumas incluindo necessidade de capacidade de inferência do raciocinador, outras não. Algumas com resultados esperados com poucas linhas, outras com milhares de linhas. 52

57 4.3.1 Testes em lote sobre a massa de dados M10 A massa de dados M10 foi a maior base testada por Santos [13] em seu trabalho. Os testes deste capítulo foram executados em cima desta base de dados, contendo indivíduos, 4500 pessoas e triplas. Com a evolução da tecnologia e as novas ferramentas disponíveis nesta data, optou-se por iniciar os testes de carga com esta base a fim de estabelecer um comparativo inicial. Neste teste foram realizados testes em lote, simulando uma única conexão seguida de uma repetição de 10 (dez) execuções de uma mesma consulta SPARQL. Durante a realização de alguns pré-testes, foi observado que a execução da primeira consulta sempre era muito superior às demais Desta maneira as tabelas geradas para análise foram adaptadas para conseguir mostrar os resultados dos testes de maneira mais clara, apresentando além do tempo de execução da primeira query, o maior tempo, o segundo maior tempo, o menor tempo e a média entre os 10 tempos obtidos. A estrutura da tabela para estes testes é dividida em linhas e colunas. Nas colunas estão as combinações de ferramentas utilizadas no teste e nas linhas os valores obtidos para cada uma delas. As linhas estão divididas em: Numero de testes em lote: É o número de execuções repetidas da mesma consulta SPARQL dentro de uma mesma conexão. Tempo da primeira resposta (ms): É o tempo levado, cronometrado em milissegundos, que inicia antes da criação da consulta SPARQL e finaliza após a chamada do método de execução da mesma no modelo testado. Maior tempo (ms): Representa o maior valor de tempo, em milissegundos, cronometrado na execução de uma consulta dentro do lote citado acima. 53

58 Segundo maior tempo (ms): Representa o segundo maior valor de tempo, em milissegundos, cronometrado na execução de uma consulta dentro do lote citado. Este valor é importante para mostrar a variação dos resultados com exceção do maior, normalmente bem superior aos demais. Menor tempo (ms): Representa o menor valor de tempo, em milissegundos, cronometrado na execução de uma consulta dentro do lote. Tempo médio (ms): Representa a média dos tempos de um lote de execuções. É calculado somando todos os tempos obtidos neste lote e dividindo pelo número de testes executados neste lote, gerando uma média simples. Quantidade de linhas retornadas: Representa a quantidade de registros retornados da consulta executada. Inferência: Informa se a combinação de ferramentas testada é capaz de raciocinar e realizar inferência sobre a massa de dados através das regras de entailment do modelo Teste 1 Seleção de pessoas (Person) Neste teste, foi solicitada a execução de uma consulta SPARQL que seleciona todas as pessoas do modelo, ou seja, todas instâncias de Person. Todas as 4500 instâncias buscadas eram diretamente instâncias de Person não sendo necessária a utilização de inferência para o resultado ser válido, pois mesmo sem ela, a resposta seria a mesma. PREFIX rdf: < PREFIX process: < PREFIX cmdb: < 54

59 Jena + Postgres Jena + Oracle Jena + Pellet + Postgres Jena + Pellet + Oracle Jena Adapter + Oracle Semantic Jena Adapter + Pellet + Oracle Semantic Jena Adapter + PelletDB + Oracle Semantic PREFIX itgov: < PREFIX acme: < SELECT?x WHERE {?x a cmdb:person. } Quadro 6 - Consulta selecionando todas as instâncias de pessoas do banco M10 Executando a consulta do Quadro 6 com as diferentes combinações de ferramentas, e seguindo a estrutura proposta pelo teste, foi possível gerar uma tabela com os dados a serem analisados. Numero de testes em lote Tempo da primeira resposta (ms) Maior tempo (ms) Segundo maior tempo (ms) Menor tempo (ms) Tempo médio (ms) Quantidade de linhas retornadas

60 Inferência Não Não Sim Sim Não Sim Sim Tabela 2 Resultados obtidos nos testes de seleção de pessoas (Person) Como resultado, um padrão já percebido em pré-testes foi confirmado: o tempo da primeira consulta sempre foi muito superior às demais. Isso se deve ao cache do banco de dados, pois a série de consultas foi executada em apenas uma conexão. Todas as combinações trouxeram as 4500 instâncias. Para este teste, quatro dos resultados obtidos foram considerados satisfatórios (células destacadas em verde), conseguindo cumprir em um tempo inferior a 1 segundo Teste 2 Seleção de CIs Neste teste, foi solicitada a execução de uma consulta SPARQL que seleciona todos os CIs da base. Para este resultado ser satisfatório, além do baixo tempo de execução, a ferramenta deveria ser capaz de realizar inferência, pois na base testada existiam diversas instâncias de subclasses de CI, que também deveriam ser retornadas por também serem CIs. PREFIX rdf: < PREFIX process: < PREFIX cmdb: < PREFIX itgov: < PREFIX acme: < SELECT?x WHERE {?x a cmdb:ci. } Quadro 7 Seleção de instâncias de CI da base M10 56

61 Jena + Postgres Jena + Oracle Jena + Pellet + Postgres Jena + Pellet + Oracle Jena Adapter + Oracle Semantic Jena Adapter + Pellet + Oracle Semantic Jena Adapter + PelletDB + Oracle Semantic Executando a consulta do Quadro 7 com as diferentes combinações de ferramentas, foi gerada a Tabela 3. Observa-se, destacando-se a coluna com fundo vermelho, que algumas das ferramentas não conseguiram responder com sucesso a consulta por não realizarem inferência sobre os dados. A célula destacada em verde evidencia o melhor desempenho. Numero de testes em lote Tempo da primeira resposta (ms) Maior tempo (ms) Segundo maior tempo (ms) Menor tempo (ms) Tempo médio (ms) Quantidade de linhas retornadas Inferência Não Não Sim Sim Não Sim Sim Tabela 3 - Resultados obtidos nos testes de seleção de CIs 57

62 Observando a Tabela 3, pode-se perceber que as três combinações de ferramentas utilizadas sem a inferência realizada pelo Pellet não trouxeram o número de linhas esperado, pois não havia instâncias diretas de CIs na base testada. Por este motivo, tais combinações foram descartadas. Analisando as demais, fica muito visível que com PelletDB o tempo de execução é mais de 300 vezes menor do que o segundo melhor resultado válido obtido. Além disso, é mais de 2700 vezes menor do que o terceiro resultado válido e mais de 5900 vezes menor do que o quarto resultado válido, uma diferença muito significativa. Um ponto que merece destaque, é que o teste com JPO foi muito mais lento do que o mesmo teste realizado com JPP. Ambos foram realizados com as mesmas linhas de código, apenas alterando a conexão da aplicação entre os dois bancos de dados, igualmente populados seguindo uma mesma estrutura. Mesmo assim, por algum motivo, o tempo de resposta utilizando Oracle foi quase nove vezes maior. Outro fato curioso é que no teste da última coluna (JPDBOS), obteve-se um tempo de execução menor do que algumas das ferramentas que não fazem inferência, possivelmente devido a forma como o PelletDB indexa as triplas Teste 3 Seleção de instâncias de um determinado software Neste teste foram buscadas as instâncias de todos os objetos que tenham a relação is_instance_of de CMDB, com um determinado Software, neste caso random_software_master_copy_29070, como pode ser observado no Quadro 8. 58

63 Jena + Postgres Jena + Oracle Jena + Pellet + Postgres Jena + Pellet + Oracle Jena Adapter + Oracle Semantic Jena Adapter + Pellet + Oracle Semantic Jena Adapter+ PelletDB + Oracle Semantic PREFIX rdf: < PREFIX process: < PREFIX cmdb: < PREFIX itgov: < PREFIX acme: < SELECT?x WHERE { }?x cmdb:is_instance_of cmdb:random_software_master_copy_ Quadro 8 Consulta em SPARQL para seleção de instâncias de random_software_master_copy_29070 Para os testes em cima dos reasoners (Pellet, PelletDB e OWLPrime do Oracle este último não incluído na Tabela 4), foram encontrados não somente as instâncias diretamente ligadas a random_software_master_copy_29070, que são 15, mas também outras ligadas indiretamente através das propriedades de entailment da ontologia. Numero de testes em lote Tempo da primeira resposta (ms) Maior tempo (ms)

64 Segundo maior tempo (ms) Menor tempo (ms) Tempo médio (ms) Quantidade de linhas retornadas Inferência Não Não Sim Sim Não Sim Sim Tabela 4 - Resultados obtidos nos testes de seleção de instâncias de random_software_master_copy_29070 A Tabela 4 foi o resultado obtido com a execução do mesmo teste com as diferentes combinações de ferramentas propostas. A variação na quantidade de linhas retornadas foi muito grande, devido ao fato de o Jena não fazer inferência, e portanto não trazer objetos que não estejam diretamente ligados a random_software_master_copy_29070 através da relação de CMDB is_instance_of. No que diz respeito a performance, destaca-se em verde a célula da velocidade de resposta do PelletDB, que se mantém com um tempo de resposta muito pequeno (125ms), mesmo para uma consulta que traz respostas através do entailment da ontologia, e não apenas pelas ligações diretas das triplas. Por outro lado, a utilização de JPO e JAPOS, mostrou-se muito lenta. No caso do JPO, este tipo de consulta já começa a se tornar inviável para obtenção de respostas rápidas, uma vez que levou cerca de 12 minutos para trazer a resposta. No caso de JPO, a consulta levou quase 1 minuto, um tempo que ainda pode ser considerado aceitável dependendo do contexto em que está inserido. Por fim, a combinação que mais surpreendeu foi JPP, que trouxe as respostas em menos de meio minuto, a metade do tempo levado por JPO, superando-o. 60

65 4.3.2 Testes sobre o modelo fictício Acme Com finalidade de testes de inferência com dados que sejam de fácil entendimento por humanos, foi utilizado o modelo de uma empresa fictícia chamado de Acme Corp., utilizado anteriormente por Santos [13][13], no qual é modelada uma empresa com apenas dois processos. Não foram feitas alterações sobre o modelo, portanto para consulta de maiores detalhes sobre sua estrutura, pode-se consultar [13] Teste 4 Busca de pessoas envolvidas no processo de Incident Handling O teste de busca de envolvidos no processo de Incident Handling é a repetição de um teste executado previamente no ato da concepção da OntoITIL em [13], para avaliação da consistência da ontologia e da capacidade de inferência que a mesma oferecia para o reasoner utilizado. A consulta, (Quadro 9), busca todas as pessoas envolvidas direta ou indiretamente no processo de Incident Handling, pois busca todos os processos relacionados a Incident Handling e todas as pessoas das quais estes processos são dependentes. PREFIX rdf: < PREFIX process: < PREFIX cmdb: < PREFIX itgov: < PREFIX acme: < 61

66 Jena + Postgres Jena + Oracle Jena + Pellet + Postgres Jena + Pellet + Oracle Jena Adapter + Oracle Semantic Jena Adapter + Pellet + Oracle Semantic Jena Adapter + PelletDB + Oracle Semantic SELECT?x WHERE {?x a cmdb:person.?y cmdb:is_dependent_of?x.?y process:is_aggregated_by acme:incident_handling. } Quadro 9 Consulta de todas as pessoas envolvidas no processo de Incident Handling Como esperado, nos testes feitos sem a utilização de um reasoner, nenhum resultado foi retornado. Já com a utilização de inferência, foram trazidas todas as pessoas envolvidas, algumas inclusive mais de uma vez, pelo fato de estarem envolvidas em mais de um processo que se liga com Incident Handling. Numero de testes em lote Tempo da primeira resposta (ms) Maior tempo (ms) Segundo maior tempo (ms)

67 Menor tempo (ms) Tempo médio (ms) Quantidade de linhas retornadas Inferência Não Não Sim Sim Não Sim Sim Tabela 5 - Resultados obtidos nos testes de seleção de pessoas envolvidas no processo de Incident Handling A Tabela 5 mostra os resultados de desempenho obtidos. Todas as combinações tiveram um tempo de resposta bom, sendo a mais lenta a JAPOS. Novamente o JPP surpreende, se mostrando apenas inferior ao JPDBOS, que mais uma vez fica com destaque pelo melhor tempo. É interessante ressaltar que apesar de fazer as inferências utilizando as regras de entailment, o JPDBOS ainda supera os tempos das combinações JP, JO e JAOS, que não utilizam estas regras, chegando a quase metade do tempo de uma delas Teste de carga com Bases M2 a M10 Com o objetivo de verificar o comportamento das diferentes combinações de ferramentas, optou-se pela realização de um teste utilizando uma mesma consulta SPARQL com todos os modelos em uma sequencia de conjuntos de dados que foi sendo trocada por outra de tamanho superior, iniciando em M2 e finalizando em M10. A consulta utilizada foi a mesma utilizada em testes anteriores, a qual seleciona todas as instâncias de pessoas (Person) do modelo, disponível no Quadro 6. 63

68 Quantidade de linhas a ser retornada pela pesquisa Jena + Postgres Jena + Oracle Jena + Pellet + Postgres Jena + Pellet + Oracle JenaAdapt + Oracle Sem JenaAdapt + Pellet + Oracle Sem JenaAdapt + PelletDB + Oracle Sem A Tabela 6, mostrada logo abaixo, apresenta os resultados obtidos. Destacadas em cinza as colunas cuja combinação de ferramentas não realiza inferência sobre os dados. Tempos em Milissegundos (ms) por combinação utilizada M M M M M M M M M Tabela 6 Tempos de resposta para consulta SPARQL de seleção de instâncias de Person 64

69 Tempo em Milisegundos Observa-se que das ferramentas que realizam inferência, os tempos obtidos com JPDBOS, foram muito menores do que os demais que realizam inferência e inclusive muitas vezes menores até do que algoritmos que não realizam inferência. Comparando JPP e JPO, temos uma grande diferença, diferença esta já encontrada em outros testes. Apesar de a combinação JPP ter tempos muito superiores a combinação JPDBOS, pelos tempos encontrados, ainda é viável sua utilização caso necessária uma ferramenta com inferência open source. Abaixo, estão plotadas no Gráfico 1 os valores obtidos na Tabela 6. Observa-se a linearidade da combinação JAPOS M2 M3 M4 M5 M6 M7 M8 M9 M10 Massa de dados utilizada Jena + Postgres Jena + Pellet + Postgres JenaAdapt + Oracle Sem PelletDB Jena + Oracle Jena + Pellet + Oracle JenaAdapt + Pellet + Oracle Sem Gráfico 1 - Tempos de consultas para diferentes combinações de ferramentas em uma sequência de massas de dados 65

70 Tempo em Milissegundos Como os valores são bem distintos, o Gráfico 1 ficou com uma variação muito grande e algumas das combinações não foram facilmente vistas. Para melhorar a visualização, foram filtrados os resultados das ferramentas JAPOS e JPO, gerando o Gráfico 2 abaixo. Nele fica visível a curva de crescimento da ferramenta JPP, que como já comentado, apesar de ser bem superior as demais, não chegou a superar 25 segundos (25000 milissegundos) M2 M3 M4 M5 M6 M7 M8 M9 M10 Massa de dados utilizada Jena + Postgres Jena + Oracle Jena + Pellet + Postgres JenaAdapt + Oracle Sem PelletDB Gráfico 2 - Tempos de consultas para diferentes combinações de ferramentas em uma sequência de massas de dados Filtro 1 Novamente, para aumentar a precisão da visualização, o Gráfico 2 foi filtrado, removendo a combinação JPP, gerando o Gráfico 3 abaixo. 66

71 Tempo em Milissegundos M2 M3 M4 M5 M6 M7 M8 M9 M10 Massa de dados utilizada Jena + Postgres Jena + Oracle JenaAdapt + Oracle Sem PelletDB Gráfico 3 - Tempos de consultas para diferentes combinações de ferramentas em uma sequencia de massas de dados - Filtro 2 Apesar de no Gráfico 3 os comportamentos das diferentes combinações serem semelhantes, apenas PelletDB realizou inferência sobre os dados, que apesar de não essencial para responder a esta consulta específica, poderia ser indispensável para outras, como já visto em outros testes. Para os testes acima, as ferramentas testadas se mantiveram dentro da faixa 50 ~ 250 milissegundos. Em uma comparação com os resultados obtidos por Santos [13], exemplificados na Figura 10 abaixo extraída de seu trabalho, observa-se que em testes com as mesmas bases de dados (eixo X variando de 1 a 10) a combinação Jena + Pellet + Postgres utilizada por ele (linha cinza escuro da Figura 10), pode ser comparada com a mesma combi- 67

72 nação disponível no Gráfico 2 acima. Enquanto nos testes realizados por Santos [13], esta combinação levou em M4 cerca de 30 segundos para responder a consulta, com as novas versões das mesmas ferramentas, o tempo caiu para cerca de 9 segundos e com um bases maiores, não houve estouro de memória do Java, como ocorreram nos testes realizados por ele. Observa-se também uma melhoria no desempenho da combinação Jena + Postgres, também testada por ele e disponível no gráfico abaixo (linha cinza claro da Figura 10). Figura 10 - Teste de desempenho sobre bases de dados M1 a M10 por Santos [13] Teste de carga com Bases M20 a M100 Buscando realizar testes com bases ainda maiores, optou-se pela realização de testes com as bases M20 a M

73 java heap. mui to lento. java heap. java heap. muito lento Qtd Results Jena + Postgres Jena + Oracle Jena + Pellet + Postgres Jena + Pellet + Oracle JenaAdapt + Oracle Sem JenaAdapt + Pellet + Oracle Sem JenaAdapt + PelletDB +OracleSem Teste 1 Seleção de pessoas (Person) Os resultados abaixo foram obtidos utilizando a mesma consulta SPARQL já utilizada em outro experimento, disponível no Quadro 6 na página 55, que seleciona todas as instâncias de Person do modelo. M M M M M M M M M Tabela 7- Resultados da execução da query de seleção de Person nas diferentes combinações de ferramentas. As colunas das ferramentas representadas pela cor cinza, novamente indicam que as ferramentas não realizam inferência e as colunas de cor verde, indicam as combi- 69

74 nações de ferramentas que realizam inferência. Neste teste observam-se novos casos aparecendo nos resultados. O primeiro foi a desistência da realização de testes com algumas combinações após um determinado tamanho do conjunto de dados, devido a extrema demora para realização dos testes, que chegava a levar cerca de 25 minutos, e por isso tornou-se automaticamente descartada da continuação dos testes, como a combinação JPO. Outro caso ocorrido nestes testes foi o aparecimento do erro Java Heap, que se trata da falha do teste devido ao aparecimento da exceção java.lang.outofmemoryerror: Java heap space, que significa estouro de memória do Java. No caso da combinação JPDBOS, a partir de M50, até era possível realizar a execução da consulta com sucesso e obter um tempo similar aos anteriores, mas no momento de iterar sobre os resultados (seja para apresentação em tela, ou para contagem), ocorria o erro de memória, independentemente do número de resultados. Foi efetuada uma configuração na ferramenta Eclipse para aumentar o espaço de memória possível de ser alocado pelo Java, porém sem sucesso nos testes, mantendo o problema na hora da iteração sobre o resultado. Abaixo, no Gráfico 4, foram plotados os tempos obtidos. Observa-se a grande diferença no resultado de algumas ferramentas. 70

75 Tempo em Milisegundos M20 M30 M40 M50 M60 M70 M80 M90 M100 Massa de dados utilizada Jena + Postgres Jena + Pellet + Postgres JenaAdapt + Oracle Sem PelletDB Jena + Oracle Jena + Pellet + Oracle JenaAdapt + Pellet + Oracle Sem Gráfico 4 Tempo de resposta para execução de consulta SPARQL com combinações de ferramentas. Como em testes anteriores, foi optado pela realização de um filtro sobre os dados, facilitando a visualização de outros conjuntos que são praticamente ocultados devido a grande variação existente no eixo Y. Aplicando este filtro obteve-se o Erro! Fonte de referência não encontrada. abaixo. 71

76 Tempo em Milisegundos M20 M30 M40 M50 M60 M70 M80 M90 M100 Massa de dados utilizada Jena + Postgres Jena + Oracle JenaAdapt + Oracle Sem PelletDB Gráfico 5 - Tempo de resposta para execução de consulta SPARQL com combinações de ferramentas Filtrado 2. Observa-se que a linha da combinação JPDBOS é interrompida em M40, devido ao Java Heap, porém comparando com as outras combinações de ferramentas que realizam inferência, seus resultados foram extremamente satisfatórios Teste 2 Seleção de CIs Com o objetivo de confrontar os resultados anteriores com um teste similar, porém com necessidade de inferência, optou-se pela realização do mesmo teste com outra consulta SPARQL, disponível no Quadro 7, a qual solicita todas as instâncias de CI. Na Tabela 8 abaixo, os resultados obtidos. Observa-se em vermelho as colunas das combinações de ferramentas que não realizaram inferência e por isso foram desconsideradas do teste. 72

77 não responde o solicitado não responde o solicitado java heap muito lento não responde o solicitado java heap java heap muito lento Qtd Results Jena + Postgres Jena + Oracle Jena + Pellet + Postgres Jena + Pellet + Oracle JenaAdapt + Oracle Sem JenaAdapt + Pellet + Oracle Sem JenaAdapt + PelletDB + OracleSem Novamente ocorreram os erros de Java heap a partir de um determinado volume de dados (M40). M * 93* * M M M M M M M M *Tempo de resposta apenas para constar, pois como a combinação não realiza inferência, não conseguiu responder a consulta SPARQL com a quantidade de resultados esperados. Tabela 8 Tempos obtidos com diferentes combinações de ferramentas sobre consulta de CIs em diferentes conjuntos de dados (M20 a M100 ) 73

78 Na Tabela 8 pode ser observada a grande diferença nos tempos com a combinação JPDBOS, e a repetição dos problemas já observados no teste anterior, como o estouro de memória do Java, o que ocorreu no mesmo ponto (M50). 4.4 Teste 2 Execução de Testes II Analisando o tempo para o carregamento de grandes massas de dados como a M100 e a intenção de realizar testes com bases maiores ainda, foi criada uma nova estrutura de base de dados para otimizar este carregamento. Trata-se de um sistema de carregamento dividido em lotes. Os lotes são as massas de dados, armazenados em arquivos owl. A primeira massa de dados, nomeada de M_X01 é composta de uma estrutura de dados similar a M10, contendo as mesmas triplas e a definição da ontologia. As demais iniciam em M_X02, sendo os dois últimos algarismos variando indefinidamente até onde julgar-se necessário. A diferença entre a primeira massa de dados e as demais, é que apenas a primeira possui as definições da ontologia (definição de classes, relacionamentos, propriedades, enfim, as regras de entailment). Assim, o carregamento da base ocorre da seguinte forma: primeiramente é carregada a ontologia M_X01, e após isso, podem ser carregada as demais na sequência sem limpar o banco de dados, como era feito anteriormente antes do carregamento de qualquer novo conjunto. Comparando, ao carregar M_X01 temos M10, ao carregar M_X02, temos M20, e assim sucessivamente. Foram criados inicialmente os arquivos de M_X01 a M_X10, simulando M10 a M100, e após sucesso com os testes que serão descritos posteriormente, foram criados os arquivos M_X11 a M_X20. 74

79 Com todos os carregamentos na sequência, em M_X13 teríamos mais de um milhão de triplas, chegando a M_X20 com instâncias de Person, instâncias de CI e triplas. Seguindo uma sequência lógica, com um carregamento de M_X01 até M_X20, teríamos o equivalente a carregar M200 do modelo anterior Testes com o reasoner interno do Oracle Semantic Depois de observados os problemas na execução de testes com bases de dados maiores que M40 utilizando as diferentes combinações de ferramentas propostas, optouse por realizar um estudo mais a fundo sobre a execução de consultas SQL no Oracle, diretamente em cima da base de dados, utilizando o motor de inferência do próprio SGBD. Através da chamada de funções dentro de comandos SQL, é possível fazer consultas no modelo semântico de forma bastante parecida com SPARQL, apenas com algumas adaptações. A Figura 11 mostra como é feita uma consulta SQL, adicionando SPARQL a mesma, com as devidas correspondências. 75

80 Figura 11 Retirado de [25] Importante ressaltar que para a utilização do mecanismo de inferência interno do Oracle, é necessário que o modelo tenha seus índices de regras sempre atualizados. Para tanto, na primeira carga do modelo, deve-se criar os índices através da API semântica do Oracle, com o comando SEM_APIS.CREATE_ENTAILMENT e sempre que houver triplas alteradas, deve-se chamar esta função novamente. Nos parâmetros de criação do entailment, deve ser passada a opção de atualização incremental dos índices, para possibilitar inferências incrementais sem a necessidade de recriação dos índices a cada alteração ou adição de triplas. 76