Acesso a Dados a partir de Ontologias Utilizando Mapeamentos Heterogêneos e Programação em Lógica

Tamanho: px
Começar a partir da página:

Download "Acesso a Dados a partir de Ontologias Utilizando Mapeamentos Heterogêneos e Programação em Lógica"

Transcrição

1 UNIVERSIDADE FEDERAL DO CEARÁ CENTRO DE CIÊNCIAS DEPARTAMENTO DE COMPUTAÇÃO MESTRADO EM CIÊNCIA DA COMPUTAÇÃO Dissertação de Mestrado Acesso a Dados a partir de Ontologias Utilizando Mapeamentos Heterogêneos e Programação em Lógica FERNANDA LÍGIA RODRIGUES LOPES FORTALEZA/CE Janeiro de 2011

2 I UNIVERSIDADE FEDERAL DO CEARÁ CENTRO DE CIÊNCIAS DEPARTAMENTO DE COMPUTAÇÃO MESTRADO EM CIÊNCIA DA COMPUTAÇÃO Acesso a Dados a partir de Ontologias Utilizando Mapeamentos Heterogêneos e Programação em Lógica Dissertação submetida à Coordenação do Curso de Pós- Graduação em Ciência da Computação da Universidade Federal do Ceará, como requisito parcial para a obtenção do grau de Mestre em Ciência da Computação. Orientadora: Profª. Drª. Bernadette Farias Lóscio FERNANDA LÍGIA RODRIGUES LOPES

3 II UNIVERSIDADE FEDERAL DO CEARÁ CENTRO DE CIÊNCIAS DEPARTAMENTO DE COMPUTAÇÃO MESTRADO EM CIÊNCIA DA COMPUTAÇÃO Acesso a Dados a partir de Ontologias Utilizando Mapeamentos Heterogêneos e Programação em Lógica Fernanda Lígia Rodrigues Lopes Orientadora: Profª. Drª. Bernadette Farias Lóscio Aprovada em / / BANCA EXAMINADORA Profª. Drª. Bernadette Farias Lóscio (Orientadora) Universidade Federal de Pernambuco - UFPE Profª. Drª. Maria Cláudia Reis Cavalcanti Instituto Militar de Engenharia IME Prof. Dr. José Ântonio Fernandes de Macêdo Universidade Federal do Ceará UFC Prof. Dr. João Fernando Lima Alcântara Universidade Federal do Ceará UFC

4 III AGRADECIMENTOS Muitas pessoas foram importantes para que eu pudesse chegar até aqui. A cada uma delas, eu gostaria de deixar registrado meu sincero agradecimento. Antes de tudo, agradeço a Deus, que me dá saúde e forças, o que me permite buscar o restante. Agradeço à minha família, que é o meu alicerce. Obrigada por apoiarem as minhas escolhas, acreditarem em mim e se orgulharem a cada nova vitória. À minha mãe, Elisabete, que está sempre ao meu lado, oferencedo seu amor, atenção e suporte nos momentos necessários. Sem ela, eu não seria nada do que sou hoje. Ao meu pai, Ribamar, por seu amor e preocupação. Aos meus irmãos, Amanda e Clébio, meus grandes amigos, pelo companherismo, pelas implicâncias e por compartilharem comigo tantos momentos importantes. A todos os demais familiares que sempre torcem por mim. À minha orientadora, professora Bernadette Farias Lóscio, com quem eu pude trabalhar e conviver durante estes anos. Agradeço por todo o aprendizado. Pela orientação presente, enorme paciência, dedicação, persistência, sugestões, incentivos, confiança e amizade. Com a professora Bernadette, eu aprendi muitas lições, tanto acadêmicas quanto sobre a postura de alguém que está sempre disposta a crescer, a lutar, a debater, a ouvir e a ensinar. Berna, muito obrigada por tudo! Eu tenho muito respeito pela pessoa e profissional que você é. Aos professores Maria Cláudia Cavalcanti, João Fernando Lima Alcântara e José Antônio Fernandes de Macêdo por terem aceitado o convite de participar da banca examinadora deste trabalho. Agradeço ainda à professora Damires Fernandes que, infelizmente, não pôde estar presente na banca, mas que sempre foi muito atenciosa com questões relacionadas a este trabalho. Ao professor João Fernando e ao Francicléber pelos esclarecimentos e troca de ideias sobre assuntos de lógica. À minha amiga Eveline Sacramento, que foi uma grande parceira durante a realização de boa parte deste mestrado. Agradeço por nossas discussões enriquecedoras, pelo trabalho duro, pelos conselhos e incentivos. Eles foram muito importantes para que eu pudesse seguir em frente. Desejo, de maneira muito sincera, que a sua jornada seja repleta de sucesso e realizações.

5 IV Aos meus queridos amigos (grupo RTL) Hélio, Danusa e Bia, que estiveram presentes em tantos momentos durante estes anos. Foi muito bom conviver com vocês! Agradeço particularmente ao Hélio, que foi um companheiro de trabalho em algumas questões de implementação. Aos amigos integrantes do grupo Arida, com os quais eu convivi, em algum momento: Fernando Lemos, Fernando Wagner, Ângela, Juliana, Bruno, Clayton, Lívia, Ticiana, Ticianne, Luiz Aires, João Carlos, Igo, André e Diego Victor. Aos meus amigos Viviane, Paulo de Tarso, Katarina, Illana, Adriana e Bibi que, apesar da distância, uma hora ou outra se fizeram presentes com a sua amizade e troca de experiências pessoais e profisisonais. A todos os professores e funcionários do MDCC que me ajudaram, de alguma forma, durante este caminho. Agradeço também ao secretário José Orley por sempre auxiliar nas pendências que surgiram. À Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES) e à Fundação Cearense de Apoio ao Desenvolvimento Científico e Tecnológico (Funcap) pelo auxílio financeiro que possibilitou a realização deste trabalho.

6 V O desenvolvimento da capacidade geral de pensamento e livre-arbítrio sempre deveria ser colocado em primeiro lugar, e não a aquisição de conhecimento especializado. Se uma pessoa domina o fundamental no seu campo de estudo e aprendeu a pensar e a trabalhar livremente, ela certamente encontrará o seu caminho e será mais capaz de adaptar-se ao progresso e às mudanças. (Albert Einstein) Se o conhecimento nos faz descobrir problemas, não é a ignorância que os resolverá. (Isaac Asimov)

7 VI RESUMO Em várias áreas, tais como Integração de Dados e Web Semântica, ontologias têm sido adotadas para descrever formalmente a semântica das fontes de dados, com o intuito de facilitar a descoberta e a recuperação de informações. Dentro desse contexto, o Acesso a Dados Baseado em Ontologias (Ontology-Based Data Access - OBDA) é um problema decorrente da necessidade de acessar tais fontes a partir das ontologias que representam seus modelos conceituais. Dentre as principais características do OBDA, destacamos a independência entre as ontologias e a camada de dados e a possibilidade de responder a consultas que sejam mais expressivas que às geralmente realizadas utilizando Lógica Descritiva. Neste trabalho, especificamos um ambiente de OBDA no qual este problema é dividido em uma série de passos que podem ser tratados de maneira independente. Dentre cada um destes passos especificados, nossa principal contribuição reside na definição e implementação de um processo para reescrita de consultas entre ontologias estruturalmente distintas. Em nossa abordagem de reescrita, manipulamos a consulta de entrada combinando a semântica e a expressividade da linguagem SPARQL com um método baseado em noções de Programação em Lógica, uma vez que utilizamos mapeamentos heterogêneos expressos através de regras. Além disso, tratamos aspectos referentes às diferenças estruturais entre as ontologias, possibilitamos que partes da consulta reescrita possam ser descartadas durante o processo, caso seja constatado que tais partes seriam desnecessárias, e permitimos que os resultados sejam reestruturados e apresentados conforme a ontologia alvo. Por fim, é válido destacar que, embora a solução apresentada tenha como foco duas ontologias, esta pode ser estendida para considerar aspectos específicos de distribuição.

8 VII ABSTRACT Ontologies have been used in different areas, including Data Integration and Semantic Web, to provide formal descriptions to data sources as well as to associate semantics to them and to make information easier to discover and to recover. In this context, oneo fthe most relevant issues is the Ontology-Based Data Access OBDA, which is the problem of accessing one or more data sources by means of a conceptual representation expressed in terms of an ontology. The independence between the ontology layer and the data layer, and the ability of answering more expressive queries than the ones defined using description logics are some of the main distinguished issues of the ODBA. In this work, we specify an environment for OBDA, which deals with this problem considering a set of independent tasks. Our main contribution concerns the definition and implementation of a query rewriting process between ontologies structurally heterogeneous. In the proposed query rewriting approach, we combine the semantics and expressiveness of SPARQL with logic programming and we adopt a rulebased formalism to represent mappings between ontologies. We also deal with some relevant questions, including: the structural heterogeneity, the prune of irrelevant parts of the rewritten query and the representation of query results according to the target ontology. It is important to note that, although in this work we discuss the use of the proposed solution considering just two ontologies, it can also be extended and applied for data distributions cenarios with multiple ontologies.

9 VIII SUMÁRIO CAPÍTULO 1 Introdução Motivação e Caracterização do Problema Objetivos e Contribuições da Dissertação Organização da Dissertação CAPÍTULO 2 Fundamentação Teórica Acesso a Dados Baseado em Ontologias Tradução entre Ontologias e Modelo de dados Relacional e XML Mapeamento entre Ontologias Reescrita de Consultas Abordagens para Reescrita de Consultas com Ontologias What to Ask to a Peer SomeRDF SemRef (Semantic Reformulation) Linking Data to Ontologies Reescrita de consultas SPARQL para Integração de Linked Data Reescrita de consultas SPARQL para mediação de consultas entre ontologias mapeadas Análise Comparativa dos Trabalhos Relacionados Conclusões CAPÍTULO 3 Um Ambiente para Acesso a Dados Baseado em Ontologias Descrição do Ambiente Considerações Iniciais Ambiente de Tempo de Projeto Ambiente de Tempo de Execução Caracterização dos Mapeamentos entre as Ontologias OWL Extralite Ontologias Utilizadas nos Exemplos Matching de Vocabulários Formalismo de Regras para Representação dos Mapeamentos Geração das Regras de Mapeamento Conclusões CAPÍTULO 4 Um Processo para Reescrita de Consultas entre Ontologias Visão Geral do Processo Normalização da Consulta Algumas Noções de Programação em Lógica Conversão de SPARQL para Regras Considerações Iniciais Geração da Árvore SPARQLD Reescrita da Consulta e Reestruturação dos Resultados Representação das Regras de Mapeamento O Algoritmo ReescritaSPARQLD Exemplo de Execução do ReescritaSPARQLD

10 IX Considerações Relevantes Geração da Consulta Local Passos para Geração da Consulta Conclusões CAPÍTULO 5 Aspectos de Implementação A Ferramenta SQuOL Arquitetura Funcionalidades Validação Experimental Objetivos e Critérios para Medições e Comparações Cenário de Avaliação Experimentos e Resultados dos Experimentos Algumas Considerações e Conclusões sobre os Experimentos Conclusões CAPÍTULO 6 Conclusões Trabalhos Futuros Apêndice A Conceitos sobre RDF e SPARQL Apêndice B Algoritmo de Unificação Apêndice C Modelo XML dos Mapeamentos Apêndice D Trechos Relevantes das Ontologias Utilizadas nos Testes Apêndice E Mapeamentos entre as as Ontologias Apêndice F Consultas Testadas Ontologias do Domínio de Vendas Apêndice G Consultas Testadas Ontologias do Domínio de Educação

11 X LISTA DE FIGURAS Figura 1.1.Um Framework Baseado em Ontologias para Integração de Dados Geográficos [Vidal et. al 2009] Figura 1.2.Reescrita de consultas entre duas ontologias Figura 2.3. Arquitetura de dois (a) e três (b) níveis para integração de dados com ontologias Figura 2.4. Ontologia de domínio O D Figura 2.5. Ontologias locais O L1 e O L Figura 2.6. Exemplo da arquitetura de um PDMS Figura 2.7. Processamento de uma consulta em um PDMS Figura 2.8. Abordagem para acesso a dados relacionais a partir de ontologias Figura 2.9. Exemplo dos Alinhamentos utilizados por Correndo et. al Figura 3.1. Cenários 1 e 2 para acesso a dados a partir de ontologias Figura 3.2. Arquitetura do mecanismo de OBDA proposto Figura 3.3. Trecho da ontologia de domínio de Vendas O Figura 3.4. Trecho da Ontologia da Amazon O Figura 3.5. Trecho da Ontologia do ebay O Figura 3.6. Conjunto de Regras de Mapeamento entre a ontologia alvo O 1, de Vendas, e a ontologia fonte O 2, da Amazon Figura 3.7. Conjunto de Regras de Mapeamento entre a ontologia alvo O 1, de Vendas, e a ontologia fonte O 3, do ebay Figura 4.1.Visão Geral do Processo de Reescrita Figura 4.2. Trecho de uma consulta SPARQL com sintaxe mista Figura 4.3. Representação algébrica da consulta apresentada na Figura Figura 4.4.Exemplo de um nó de uma árvore SPARQLD Figura 4.5. Algoritmo GeraRegraSPARQL Figura 4.6. Conjunto de regras correspondentes à consulta do Exemplo

12 XI Figura 4.7. Algoritmo constroisparqld Figura 4.8. Árvore SPARQLD de representação da consulta do Exemplo Figura 4.9. Representação das Regras de Mapeamento Figura Exemplo de regras de mapeamento empregadas na reescrita Figura Algoritmo ReescritaSPARQLD Figura Algoritmo Substituição, utilizado pelo ReescritaSPARQLD Figura Algoritmo CompatibilizaContexto, utilizado pelo ReescritaSPARQLD Figura Exemplo de execução do algoritmo ReescritaSPARQLD para a consulta do Exemplo Figura Exemplo de execução do algoritmo ReescritaSPARQLD para a consulta Q ilustrada Figura Algoritmo GeraGPSPARQL Figura Consulta SPARQL do Exemplo 4.1 reescrita Figura Retorno da consulta de forma tabular Figura Retorno da consulta como um conjunto de triplas Figura 5.1. Arquitetura geral da ferramenta SQuOL Figura 5.2. Exemplo de regras de mapeamento em um documento XML Figura 5.3. Funcionalidades da SQuOL Figura 5.4. Tela Principal da Ferramenta SQuOL Figura 5.5. Tela para manipulação dos mapeamentos Figura 5.6. Passos para geração do conjunto de referência dos valores de retorno da consulta Figura 5.7. Gráficos com os tempos de resposta das consultas SPARQL reescritas por PQ SQU e PQ BAS (ontologias do domínio de Vendas) Figura 5.8. Gráficos com os tempos de resposta das consultas SPARQL reescritas por PQ SQU e PQ BAS (ontologias do domínio de Educação)

13 XII LISTA DE TABELAS Tabela 2.1. Tradução entre os construtores do modelo relacional e de uma ontologia OWL Tabela 2.2. Resumo das abordagens para geração de ontologias a partir de bancos de dados relacionais Tabela 2.3. Tradução entre os construtores do modelo XML e de uma ontologia OWL Tabela 2.4. Resumo das abordagens para geração de ontologias a partir esquemas/dados XML Tabela 2.5. Representação das ontologias e dos mapeamentos no SomeRDF Tabela 2.6. Exemplo de um conjunto de correspondências e consultas utilizadas na abordagem SemRef Tabela 2.7. Resumo das Abordagens para Reescrita Relacionadas Tabela 3.1. Matching de Vocabulários entre a ontologia da Amazon O 2 e a ontologia de Tabela 3.2. Matching de Vocabulários entre a ontologia do ebay O 3 e a ontologia de Vendas O Tabela 4.1.Exemplo de Execução do Algoritmo ConstroiSPARQLD Tabela 4.2. Exemplo de execução do Algoritmo ReescritaSPARQLD (Folha 1) Tabela 4.3. Exemplo de execução do Algoritmo ReescritaSPARQLD (Folha 2) Tabela 4.4. Exemplo de execução do Algoritmo ReescritaSPARQLD (Folha 3) Tabela 4.5. Exemplo de execução do Algoritmo ReescritaSPARQLD (Q do Exemplo 2) Tabela 5.1. Resumo com os resultados sobre as consultas obtidas por PQ SQU e PQ BAS Tabela 5.2. Tempos de execução das consultas SPARQL reescritas por PQ SQU e PQ BAS (ontologias do domínio de Vendas) Tabela 5.3. Tempos de execução das treze últimas consultas SPARQL reescritas por PQ SQU e PQ BAS (ontologias do domínio de Educação)

14 13 CAPÍTULO 1 Introdução 1.1 Motivação e Caracterização do Problema Em várias áreas, tais como Integração de dados e Web Semântica, ontologias têm sido utilizadas para descrever formalmente a semântica das fontes de dados, com o intuito de facilitar a descoberta das fontes que provêem as informações desejadas [Klien 2008; Lutz 2006], bem como a recuperação apropriada de tais informações. Além disso, ontologias têm sido ainda adotadas para especificar o esquema de mediação em sistemas de integração de dados [Calvanese et al. 2008]. Nestes casos, em geral, as ontologias descrevem o domínio de interesse e/ou representam o modelo conceitual dos dados de uma aplicação, os quais podem estar disponíveis em diversos formatos, como por exemplo: (i) no modelo relacional, visto que SGBDs relacionais são tecnologias de armazenamento consagradas; (ii) no formato XML que, devido à sua flexibilidade, tornou-se um padrão para representação e troca de dados na web; (iii) no modelo RDF, para algumas aplicações da Web Semântica. Nesse contexto, a abstração a respeito dos detalhes estruturais de armazenamento e representação dos dados é possível através da criação de mapeamentos entre os elementos dos esquemas das fontes de dados e os conceitos nas ontologias. Uma vez estabelecidos estes mapeamentos, uma questão relevante consiste em determinar como utilizá-los, com o intuito de prover meios para que a informação disponível nas fontes de dados possa ser acessada a partir de sua representação semântica, ou seja, através das ontologias. Visando exemplificar um tipo de aplicação que lida com este problema, considere o cenário apresentado na Figura 1.1. Esta figura ilustra a arquitetura de três camadas [Wache et al. 2001; Sacramento et al. 2010b] de um framework para integração de dados baseado em ontologias [Vidal et al. 2009], onde: (i) a ontologia de domínio (OD), além de representar o esquema de mediação, fornece um vocabulário de referência com os termos básicos de um domínio; (ii) a ontologia de aplicação (OA) descreve a semântica da fonte de dados a qual está associada, considerando o vocabulário e a estrutura da OD. Dessa forma, temos que as OAs são normalizadas de acordo com a OD, representando, portanto, um subconjunto da OD; (iii) os mapeamentos de mediação especificam o relacionamento entre as

15 14 ontologias de aplicação (OAs) e a ontologia de domínio (OD); (iv) os mapeamentos locais são utilizados para relacionar cada OA à sua respectiva base de dados. Figura 1.1.Um Framework Baseado em Ontologias para Integração de Dados Geográficos [Vidal et. al 2009] Conforme abordado em [Sacramento et al.2010a], a utilização de uma arquitetura de três camadas facilita tanto a definição dos mapeamentos de mediação quanto o processo de reescrita de consultas para as várias fontes de dados. Nesta arquitetura, como as OAs correspondem a um subconjunto da OD, é possível definir mapeamentos homogêneos [Ghidini and Serafini 2006] no nível de mediação, enquanto os mapeamentos locais tornam-se mais complexos, uma vez que as ontologias de aplicação não refletem, necessariamente, a estrutura da fonte de dados. Com isso, tornase necessário lidar com diferentes estruturas entre os dois modelos, o que demanda a utilização de mapeamentos heterogêneos. É válido destacar que, neste trabalho, esta classificação sobre o tipo do mapeamento é determinada com respeito às entidades envolvidas neste. Isto significa que um mapeamento é heterogêneo [Ghidini and Serafini 2006] se ele associa entidades de naturezas distintas, como por exemplo, uma classe em uma ontologia a uma propriedade em outra ontologia. Caso contrário, ele pode ser considerado homogêneo. Em geral, mapeamentos homogêneos podem ser representados através de associações mais diretas entre os termos envolvidos. Ainda no cenário da Figura 1.1, é possível observar que os dados armazenados nas fontes devem ser acessados a partir de consultas realizadas sobre as ontologias. De maneira mais específica, consultas sobre as OAs devem ser reescritas em termos de suas respectivas fontes de dados, através da utilização de mapeamentos. Uma possível maneira de lidar com esta questão consiste no desenvolvimento de serviços que sejam

16 15 capazes de receber as consultas sobre as OAs e realizar todos os passos necessários para a correta execução desta consulta sobre as fontes, reestruturando os resultados conforme os conceitos e os relacionamentos expressos na ontologia sobre a qual a consulta foi submetida. De modo geral, o problema descrito pode ser encontrado em aplicações nas quais seja necessário acessar dados a partir de ontologias tidas como modelos conceituais. Cenários típicos para este tipo de aplicação são as áreas de Integração de Informações e a Web Semântica [Calvanese et al. 2009]. Segundo Calvanese [Calvanese et al. 2009; Poggi et al. 2008], este tipo de acesso pode ser denominado de Acesso a Dados baseado em Ontologias (Ontology-Based Data Access - OBDA) e tem como uma de suas principais características a independência entre as ontologias e a camada de dados. Além disso, um segundo aspecto fundamental em OBDA consiste na possibilidade de responder a consultas que sejam mais expressivas que às geralmente realizadas utilizando lógica descritiva. Como veremos posteriormente, estes dois aspectos são considerados na abordagem aqui apresentada. Em [Poggi et al. 2008; Calvanese et al. 2009], os autores aplicam a definição de OBDA para dados armazenados em SGBDs relacionais. Em nossa abordagem, nós adaptamos e estendemos este conceito, nos abstraindo de um modelo de dados específico, a fim de obter uma solução mais genérica e modular. Para isto, dividimos o problema em etapas que podem ser tratadas de maneira independente. Tais etapas são: (i) tradução sintática do esquema da fonte de dados para uma ontologia, gerando o que é chamado de ontologia local; (ii) criação dos mapeamentos entre a ontologia local e a ontologia de domínio; (iii) reescrita da consulta entre estas ontologias, o que facilita a posterior tradução desta consulta para a linguagem da respectiva base de dados. Observe que a etapa (i) é semelhante à idéia dos esquemas de exportação dos ambientes de integração de dados. Em particular, neste trabalho, focamos no problema (iii), propondo, implementando e validando um processo para resolvê-lo. Neste ponto, é importante salientar que, ao considerarmos tanto o esquema fonte quanto o esquema alvo como ontologias, apresentamos uma solução para a reescrita que não se aplica somente à OBDA. Tal solução é válida para outros cenários, nos quais seja necessário reescrever consultas entre ontologias. Como exemplo, podemos citar os sistemas baseados em ontologias que adotam arquiteturas peer-to-peer para integração de informações [Pires 2009; Adjiman et al. 2007].

17 16 Note que estamos lidando com um problema geral de reescrita de consultas entre ontologias, no qual, dada a natureza heterogênea dos cenários onde este problema aparece, não podemos esperar que as ontologias sejam semelhantes, isto é, apresentem estruturas homogêneas. Este problema é apresentado na Figura 1.2 e descrito a seguir. Considere uma ontologia alvo O T, uma ontologia fonte O S e um conjunto de mapeamentos M ST, estabelecidos entre estas ontologias. Considere ainda que O T é a visão fornecida aos usuários e aplicações, ou seja, é a ontologia a qual estes tem acesso. Seja Q T uma consulta formulada de acordo com O T. Para que Q T possa ser também executada sobre O S, é necessário reescrevê-la em uma nova consulta Q S, expressa em termos O S. Tal consulta reescrita é derivada a partir de um processo que explora o conjunto de mapeamentos M ST. É importante observar que a ontologia O T tanto pode representar apenas uma visão, como nos cenários de OBDA, quanto pode possuir instâncias. Figura 1.2.Reescrita de consultas entre duas ontologias Após a geração e execução da consulta Q S, há ainda a necessidade de retornar os dados na representação de O T, por um dos seguintes motivos: (i) como mencionado, O T é a visão fornecida aos usuários e aplicações; (ii) os resultados das consultas serão posteriormente unificados com as instâncias presentes em O T, caso estas existam, e/ou com instâncias oriundas de outras ontologias, que também devem estar de acordo com O T. 1.2 Objetivos e Contribuições da Dissertação Este trabalho tem como objetivo geral a especificação de um ambiente que possibilite que fontes de dados possam ser acessadas a partir de uma interface baseada em ontologias, considerando que ontologias e fontes de dados possuem estruturas e níveis de abstração distintos. Para isto, cada um dos pontos (i), (ii) e (iii) citados anteriormente foram abordados, com ênfase no ponto (iii), que consiste na principal contribuição desta

18 17 dissertação. Com relação ao ponto (i), realizamos um levantamento e análise dos trabalhos existentes, visando identificar aqueles mais propícios a serem utilizados no ambiente proposto. No que se refere ao aspecto (ii), ao considerarmos que as ontologias podem apresentar diferenças estruturais, houve a necessidade de representar a reestruturação de objetos, através da definição de mapeamentos heterogêneos entre as entidades de ambas as ontologias. Sendo assim, empregamos um método [Sacramento et al. 2010a] para geração destes mapeamentos, os quais são expressos através de um formalismo baseado em regras. No que tange ao ponto (iii), propomos, implementamos e validamos um processo para reescrita de consultas entre ontologias. É válido destacar que, embora a solução apresentada tenha como foco duas ontologias, esta pode ser estendida para considerar aspectos específicos de distribuição, conforme necessário. Portanto, temos que as principais contribuições desta dissertação são: Especificação de um ambiente para acesso a dados baseado em ontologias, tendo como núcleo um processo para reescrita de consultas entre duas ontologias. Para esta especificação, foram analisados trabalhos existentes que pudessem ser aplicados, bem como foram caracterizados os mapeamentos utilizados durante a reescrita. Definição de um processo para reescrita de consultas entre ontologias estruturalmente distintas. Em nossa abordagem de reescrita, propomos um modelo para representação de uma consulta SPARQL e apresentamos um algoritmo que, utilizando-se deste modelo, reescreve uma consulta definida sobre uma ontologia alvo em uma consulta sobre uma ontologia fonte. As principais características do processo de reescrita proposto residem nos seguintes aspectos: (i) manipulamos a consulta de entrada combinando a semântica e a expressividade dos construtores de SPARQL com um método baseado em noções de programação em lógica, adaptando estas noções para o nosso contexto; (ii) tratamos aspectos referentes às diferenças estruturais entre as ontologias, fazendo uso de mapeamentos heterogêneos e considerando a utilização de predicados de comparação (>, <, =, etc.) tanto nos mapeamentos, quanto nas consultas, sendo estes predicados analisados durante o processo de reescrita; (iii) possibilitamos que partes da consulta reescrita possam ser descartadas, caso seja constatado que tais partes seriam redundantes ou retornariam vazio; (iv) permitimos que os resultados sejam reestruturados e apresentados conforme a ontologia alvo, na qual a consulta foi submetida.

19 18 Desenvolvimento de um protótipo com funcionalidades para a definição da consulta, reescrita, apresentação dos resultados e manipulação dos mapeamentos. Este protótipo foi utilizado para a validação experimental. 1.3 Organização da Dissertação Esta dissertação está organizada da seguinte forma: O Capítulo 2 contém a fundamentação teórica, apresentando uma revisão sobre os tópicos relevantes para o desenvolvimento desta dissertação, bem como os principais trabalhos relacionados. O Capítulo 3 apresenta a especificação do ambiente para acesso a dados baseado em ontologias proposto neste trabalho. Dentro do contexto deste ambiente, é explanado o processo de geração e caracterização dos mapeamentos utilizados. O Capítulo 4 descreve a abordagem proposta para reescrita de consultas entre ontologias, detalhando cada uma de suas etapas. O Capítulo 5 apresenta o protótipo desenvolvido, discorrendo sobre suas principais funcionalidades, aspectos de implementação e resultados experimentais. Finalmente, o Capítulo 6 expõe as conclusões e perspectivas de trabalhos futuros.

20 19 CAPÍTULO 2 Fundamentação Teórica Neste capítulo, apresentamos os conceitos básicos utilizados nesta dissertação, assim como uma revisão bibliográfica acerca dos assuntos relacionados à nossa abordagem. Para isto, na Seção 2.1, é discutido o problema de Acesso a Dados Baseado em Ontologias, sendo levantadas questões relativas aos seguintes aspectos: (i) tradução entre ontologias e outros modelos de dados, (ii) mapeamento entre ontologias e (iii) reescrita de consultas. Em seguida, a Seção 2.2 discorre sobre as principais abordagens para reescrita de consultas com ontologias. Tais abordagens estão entre as mais próximas do nosso trabalho. Por fim, a Seção 2.3 apresenta uma análise comparativa entre os trabalhos relacionados, incluindo a nossa estratégia. 2.1 Acesso a Dados Baseado em Ontologias Acesso a Dados Baseado em Ontologias (Ontology-based Data Acess OBDA) consiste no problema de acessar uma ou mais fontes de dados existentes através de uma representação conceitual, de alto nível e formal destas fontes, expressa sob a forma de ontologias. Exemplos de cenários nos quais este problema aparece com freqüência são os Sistemas de Integração de Dados e a Web Semântica. Tendo em vista que o denominador comum em todas estas aplicações é o acesso a um conjunto de dados através de uma ontologia, esta nomenclatura foi adotada na literatura [Poggi et al. 2008] e, portanto, será utilizada neste trabalho. A seguir, apontamos os principais aspectos deste problema, visando caracterizá-lo. 1. As fontes de dados devem existir de maneira independente, significando que estas não foram necessariamente desenvolvidas de acordo com a(s) ontologia(s) com as quais estão associadas. Portanto, não podemos fazer suposições a respeito da estrutura de ambos os modelos. 2. Ontologias e fontes de dados (i) apresentam níveis de abstração e expressividade diferentes e (ii) são expressas sob formalismos distintos. Enquanto ontologias devem ser descritas através de alguma linguagem lógica (Lógica Descritiva, por exemplo), de modo a capturar as construções normalmente utilizadas em

21 20 modelagem conceitual, fontes de dados podem estar representadas segundo o modelo relacional, XML, etc. 3. Um serviço fundamental em OBDA diz respeito a responder a consultas submetidas sobre as ontologias, onde: (i) um conjunto de mapeamentos deve ser considerado; (ii) estas consultas devem ser mais complexas que às permitidas em pesquisas envolvendo DL. Isto porque DL pode ser utilizada para capturar classes e relacionamentos na ontologia. Entretanto, como linguagem de consulta, ela é bastante limitada, principalmente quanto à realização de projeção e junção [Calvanese et al. 2009]. Além disso, DL não possui a flexibilidade dos construtores presentes nas linguagens de consultas, como por exemplo, em SPARQL. Neste trabalho, nós estendemos e adaptamos a ideia apresentada em [Poggi et al. 2008], dividindo o problema de OBDA em atividades que podem ser tratadas de maneira independente. As seções subsequentes apresentam os principais conceitos e trabalhos existentes acerca das principais linhas de pesquisa relacionadas com nossa abordagem. Destacamos as seções voltadas para o problema de reescrita, que consiste no núcleo desta dissertação Tradução entre Ontologias e Modelo de dados Relacional e XML Descrever fontes de dados através de ontologias constitui um dos principais alicerces para a concretização da Web Semântica, dada a vasta quantidade de conteúdo legado existente. Além disso, tal tarefa é de extrema importância para aplicações de Acesso e Integração de Dados baseado em Ontologias. Assim, tendo em vista a relevância desta atividade, muito trabalho tem sido realizado neste sentido. Em geral, estes trabalhos focam no desenvolvimento de tradutores, nos quais os construtores de uma fonte de dados são mapeados para construtores ontológicos, utilizando-se de diversas técnicas que podem ser manuais ou automáticas. Nesta seção, apresentamos as principais características deste processo de tradução, bem como uma revisão bibliográfica dos trabalhos existentes, com o intuito de determinar aqueles que podem ser aplicados no ambiente proposto. Para isto, esta revisão bibliográfica está organizada da seguinte maneira: (i) Inicialmente, apresentamos os trabalhos que traduzem fontes de dados relacionais e XML para ontologias. Nesta categoria, estes podem ser subdivididos da seguinte forma: aqueles que somente exportam o esquema; os que exportam o esquema e os dados; aqueles que exportam o esquema e geram mapeamentos simples entre os

22 21 dois modelos. Note que estamos interessados em abordagens nas quais a ontologia local seja gerada de maneira automática e simplificada, uma vez que trataremos da complexidade do problema de reescrita entre as duas ontologias (local e domínio). (ii) A maioria dos trabalhos descritos em (i) lida apenas com o problema de tradução de modelos. No entanto, caso a ontologia não seja povoada com as instâncias do banco de dados (visão materializada), é necessário possibilitar que uma consulta SPARQL seja transformada em uma consulta SQL ou XQuery [Boag et al. 2007]. Para isso, expomos as principais abordagens para tradução entre estas linguagens de consulta, discorrendo sobre seus objetivos e como estas abordagens poderiam complementar os trabalhos vistos em (i). Ao final de cada subseção, apresentamos nossas conclusões a respeito dos trabalhos aptos a serem instanciados em nosso ambiente. Tradução entre Ontologias e o Modelo de Dados Relacional De maneira geral, em todos os trabalhos analisados, o processo de tradução segue o mapeamento de construtores ilustrado na Tabela 2.1. A seguir, serão exibidas as características específicas destes trabalhos, bem como uma tabela (Tabela 2.2) que sumariza tais características. Tabela 2.1. Tradução entre os construtores do modelo relacional e de uma ontologia OWL Construtor no Esquema Relacional Construtor na Ontologia (OWL) Relação 1 Classe Atributo não pertencente à chave estrangeira Propriedade de tipo de dado Atributo chave estrangeira Propriedade de objeto Chave primária Propriedade funcional ou inversa funcional Chave primária e estrangeira juntas Representada como herança Restrição de UNIQUE Funcional ou inversa funcional Restrição de NOT NULL Funcional ou cardinalidade mínima igual a 1 Astrova [Astrova and Kalja 2008] apresenta um protótipo para transformação automática de um esquema de banco de dados relacional em uma ontologia OWL Full, visando atualizar os dados para Web Semântica. Como entrada, a ferramenta recebe o SQL-DDL de geração do banco de dados e, então, os construtores SQL (incluindo as restrições) são mapeados para construtores em OWL, possibilitando a geração da 1 Relações que possuem somente chaves estrangeiras não são transformadas em classes, pois tais relações não expressam entidades, mas sim relacionamentos.

23 22 ontologia. Durante o processo, as instâncias do banco de dados são utilizadas para povoar a ontologia. Trinh [Trinh et al. 2006] propõe uma ferramenta, chamada RDB2ONT, que cria ontologias em OWL, representadas no modelo Relational.OWL. Este modelo é uma meta-ontologia que descreve os componentes de um esquema relacional. Por exemplo, nesta ontologia existem as classes Tabela, Coluna, Chave Primária, etc. Dessa forma, os construtores do esquema do banco de dados são representados como instâncias na ontologia Relational.OWL. O projeto DataMaster [Nyulas et al. 2007] é um plugin para o Protegé que possibilita a geração automática de uma ontologia a partir de um banco de dados relacional. O processo de geração é simples e direto, seguindo, basicamente, o mapeamento apresentado na Tabela 2.1. Além disso, as instâncias da base de dados são transformadas em instâncias na ontologia e o usuário pode selecionar quais construtores deseja traduzir. Em [Sonia and Khan 2008], é apresentada uma técnica para transformação de modelos relacionais em ontologias, através de uma extensão do trabalho de engenharia reversa proposto em [Alhajj 2003], o qual extrai um diagrama EER (entidaderelacionamento) a partir de um banco de dados legado. Já Cerbah [Cerbah 2008], procede com a transformação de acordo com a Tabela 2.1, mas considera ainda o conteúdo do banco de dados, caso o usuário deseje. Tal conteúdo é utilizado para gerar refinamentos nas hierarquias da ontologia obtida, incluindo informações adicionais. Finalmente, Lubyte [Lubyte and Tessaris 2009] propõe um processo para extração de ontologias a partir de esquemas relacionais, através da análise das restrições presentes no banco de dados. A partir desta análise, é aplicado um processo de engenharia reversa que permite a geração da ontologia e de um conjunto de mapeamentos que conectam esta ontologia com seu respectivo esquema relacional. Além disso, os autores demonstram formalmente que a ontologia extraída reflete adequadamente a fonte de dados, de modo que não há perda de informação e nenhuma informação extra é adicionada. Diante dos trabalhos analisados, e observando a Tabela 2.2, podemos fazer algumas comparações. Todas as abordagens, com exceção de [Sonia and Khan 2008] e [Lubyte and Tessaris 2009], povoam a ontologia diretamente com as instâncias do banco de dados. No caso de [Sonia and Khan 2008], a idéia é aplicar técnicas de

24 23 engenharia reversa na tentativa de resgatar o modelo conceitual original da fonte de dados e representá-lo através da ontologia gerada. Por este motivo, a única utilização das instâncias é no sentido de auxiliar na obtenção da cardinalidade dos relacionamentos. Por outro lado, Lubyte [Lubyte and Tessaris 2009] não materializa as instâncias na ontologia porque gera os respectivos mapeamentos simples entre esta e o esquema da fonte de dados. Alguns trabalhos estão mais focados em extrair ontologias com hierarquias mais refinadas [Cerbah 2008], enquanto outros podem ser eliminados devido à necessidade de dispor do script SQL de geração do banco de dados [Astrova and Kalja 2008] ou de representar a ontologia no modelo Relational.OWL [Trinh et al. 2006]. Dentre as abordagens, a única que extrai a ontologia, gera os respectivos mapeamentos e valida a transformação de maneira teórica, além da experimental, é [Lubyte and Tessaris 2009]. Com isso, temos a garantia de que não há perda de informação durante o processo de tradução de modelos. Portanto, apontamos tal trabalho como o mais apropriado e completo, desde que não se deseje povoar as ontologias com todas as instâncias da fonte de dados. Caso contrário, [Nyulas et al. 2007] e [Cerbah 2008] podem ser utilizados.

25 24 Tabela 2.2. Resumo das abordagens para geração de ontologias a partir de bancos de dados relacionais Abordagem Objetivo Entrada Nível de Automação Aspectos analisados do BD Relações e Restrições Dados atributos Povoamento da Ontologia Conexão da Ontologia com o BD Validação Astrova [Astrova and Kalja 2008] Migrar os dados para Web Semântica SQL-DDL Automático Sim Sim Não Direto com as instâncias do banco Não mantém conexão Experimental RDB2ONT [Trinh et al. 2006] Migrar os dados para Web Semântica e prover interoperabilidade entre aplicações com ontologias Esquema do BD Relacional Automático Sim Parcialmente Não Direto com as instâncias do banco Não mantém conexão Experimental DataMaster [Nyulas et al. 2007] Importar a estrutura de um BD relacional para uma ontologia OWL no ambiente Esquema do BD Relacional Automático Sim Parcialmente Não Direto com as instâncias do banco Não mantém conexão Experimental Protegé Sonia et al [Sonia and Khan 2008] Criação de ontologia local para um banco de dados Banco de dados Relacional Automático Sim Sim Somente para auxiliar na determinação da cardinalidade dos relacionamentos Não povoa Não mantém conexão Experimental Cerbah [Cerbah 2008] Gerar uma ontologia bem estruturadas a partir de um BD Banco de dados Relacional Automático ou Semi Automático Sim Parcialmente Sim, caso o usuário deseje Direto com as instâncias do banco Não mantém conexão Experimental Lubyte [Lubyte and Tessaris 2009] Extrair uma ontologia que reflita precisamente o esquema do banco de dados relacional Esquema do BD Relacional Automático Sim Sim Não Não povoa Geração de mapeamentos simples estilo GAV Teórica e Experimental

26 25 Tradução entre Ontologias e o Modelo de Dados XML O modelo XML, além de possuir mais construtores que o modelo relacional, permite uma maior flexibilidade para a utilização e combinação destes construtores. Dessa forma, os trabalhos para tradução de esquemas XML para ontologias apresentam um padrão de transformação um pouco mais heterogêneo que as abordagens vistas anteriormente. Em geral, tais trabalhos se diferenciam com relação aos casos mais complexos, que abrangem grupos de elementos, sequências ou elementos anônimos. A Tabela 2.3 expõe os principais construtores mapeados, seguida de uma breve explanação sobre abordagens analisadas. Em seguida, é apresentada a Tabela 2.4, que sumariza as principais características destas abordagens. Tabela 2.3. Tradução entre os construtores do modelo XML e de uma ontologia OWL XML Tipos Complexos (Complex Type) Grupo de Elementos (Group) Grupo de Atributos (Attribute Group) Extensão ou Restrição em Tipos Complexos (extension, restriction) Elemento (element) Atributo (attribute) Sequência (sequence) Construtor de elemento Opcional (choice) Número máximo de Ocorrências (maxoccurs) Número mínimo de Ocorrências (minoccurs) Classe Classe Classe Ontologia Subclasse da classe correspondente ao tipo base Propriedade de tipo de dados (elemento simples) ou propriedade de objeto (relacionando subelementos) Propriedade de tipo de dado Classe não nomeada - Interseção Classe não nomeada - União maxcard mincard Garcia [Garcia and Celma 2005] propõe uma estratégia, chamada de XSD2OWL, onde um esquema XML é transformado em uma ontologia OWL, seguindo os casos apresentados na Tabela 2.3. Embora o processo apresentado seja genérico, a aplicação desta transformação tem como foco a integração e a recuperação de metadados multimídia, como por exemplo, informações do framework MPEG-7 [Manjunath et al. 2002], que é baseado em esquemas XML. Neste trabalho, além da geração da ontologia, os autores executam a importação dos dados XML através de um processo chamado de XML2RDF, onde estes dados são armazenados em um repositório RDF (RDF Store), juntamente com as ontologias. Com isso, eles mostram que a tarefa de integração e recuperação é facilitada por meio do uso de motores de inferência e classificação sobre o repositório gerado.

27 26 Em [Bohring and Auer 2005], é apresentada uma abordagem na qual uma ontologia OWL é gerada a partir de um documento XML, não havendo a necessidade de dispor do esquema XML, caso este não exista. Os autores derivam o esquema a partir dos dados e, então, procedem com a transformação conforme a Tabela 2.3. Finalmente, ilustram como converter os dados XML para instâncias OWL utilizando a linguagem XSLT [Clark 1999]. Já o processo X2OWL [Ghawi and Cullot 2009] recebe como entrada um esquema XML e gera uma ontologia OWL de acordo com a Tabela 2.3, tratando alguns casos adicionais, tais como a existência de elementos locais anônimos e tipos complexos mistos (que possuem texto e subelementos). Além disso, os autores não importam as instâncias para uma ontologia ou um repositório RDF. Eles optam por gerar, durante a transformação, um documento de mapeamento que descreve as correspondências entre as entidades da fonte XML e da ontologia local resultante. Estas correspondências são descritas por meio de expressões de caminho (XPath [Clark 1999]). XS2OWL [Tsinaraki and Bikakis 2007] é um framework que também realiza a transformação de um esquema XML para uma ontologia OWL. Assim como [Ghawi and Cullot 2009], a ontologia gerada não é povoada com as instâncias do documento XML, mas são criados mapeamentos entre os dois modelos, sendo estes mapeamentos expressos em XPath. Este trabalho se diferencia dos demais por ser complementado por outros dois processos [Bikakis et al. 2009a], desenvolvidos pelos mesmos autores. O primeiro processo permite que os dados em RDF sejam transformados novamente em XML, caso seja necessário. Com isso, o trabalho possibilita a troca de informações entre aplicações que lidam com XML e RDF. Já o segundo processo, é responsável por gerar e manter mapeamentos entre os esquemas XML e as ontologias extraídas. Por fim, os autores propõem ainda um framework mais geral [Bikakis et al. 2009b], o qual permite que uma consulta sobre uma ontologia local seja realizada em SPARQL. Tal consulta é posteriormente traduzida para XQuery, utilizando os mapeamentos estabelecidos em XPath. A respeito destas abordagens que realizam a tradução entre XML e OWL, os dois primeiros trabalhos são úteis quando houver a necessidade de armazenar todas as instâncias na ontologia local. Observe que o método descrito em [Garcia and Celma 2005] deve ser utilizado para povoar um RDF Store com tais instâncias.

28 27 Tabela 2.4. Resumo das abordagens para geração de ontologias a partir esquemas/dados XML Abordagem Objetivo Entrada Saída Nível de Automação Povoamento da Ontologia Conexão da Ontologia com o BD Validação XSD2OWL e XML2RDF [Garcia and Celma 2005] Bohring [Bohring and Auer 2005] X2OWL [Ghawi and Cullot 2009] Framework XS2OWL [Tsinaraki and Bikakis 2007], complementado por [Bikakis et al. 2009a] Processo genérico aplicado ao domínio de metadados Multimídia, com intuito de facilitar a integração e recuperação destes metadados. Gerar a ontologia, com suas respectivas instâncias, quando não se dispõe do esquema XML da fonte de dados. Usa XSLT para importação dos dados em OWL. Trata casos adicionais, específicos para elementos anônimos e mistos. Além disso, o gera o arquivo de correspondências. Prover funcionalidades para o processo completo de interoperabilidade entre XML e RDF: geração da ontologia local em OWL, bem como dos mapeamentos simples; transformação de RDF para XML e acesso aos dados XML a partir de uma consulta SPARQL. Esquema XML. Dados XML, caso se deseje importá-los Dados XML. Esquema, somente se este existir. Esquema XML. Esquema XML. Ontologia OWL. Instâncias no repositório RDF. Ontologia OWL povoada com as instâncias do documento XML. Ontologia OWL. Documento com as Correspondências entre os esquemas. Ontologia OWL. Mapeamentos entre os esquemas / Documento XML do RDF. Automático Automático Automático ou Semi- Automático (refinamentos) Automático ou Semi- Automático (refinamentos) Importa e armazena os dados XML como dados RDF, em um RDF Store. Transforma os dados XML em instâncias da ontologia OWL gerada. Para isso, utiliza XSLT. Não povoa Não povoa Não mantém conexão Não mantém conexão Gera um documento com as correspondências (em XPath) entre as entidades da fonte XML e da ontologia gerada. Gera: (i) mapeamentos (em XPath) entre o esquema XML e a ontologia; (ii) documento para permitir a transformação RDF- XML. Experimental. Informações domínio de metadados Multimídia Experimental. Arquivos do Citeseer Ferramenta com um estudo de caso utilizado como exemplo Experimental com esquemas e documentos diversos

29 28 Os demais trabalhos, ao contrário, geram documentos com mapeamentos entre os modelos, ambos expressos em XPath. Neste caso, a vantagem de utilizar XS2OWL reside no fato deste ser um framework completo, com uma validação experimental bem desenvolvida, ao passo que X2OWL, embora trate de construtores XML bem específicos, apresenta apenas um estudo de caso simples como forma de validação. Tradução de SPARQL para SQL e XQuery A maioria dos trabalhos que tratam do problema de traduzir consultas SPARQL para SQL tem como principal objetivo contribuir com projetos que visam à construção de repositórios RDF (RDF Store) no topo de SGBDs Relacionais. Estes projetos almejam gerenciar, de maneira eficiente, grandes quantidades de triplas RDF. Para isso, propõem armazenar fisicamente tais triplas em bancos de dados relacionais (na forma de tabelas com três atributos: sujeito, predicado e objeto), com o intuito de tirar proveito dos benefícios vinculados à indexação, gerenciamento, desempenho, etc. Por outro lado, para que os dados RDF possam consultados na interface de um RDF Store, o qual recebe uma consulta em SPARQL, é necessário prover uma tradução eficiente de SPARQL para SQL. É valido salientar que esta aplicação voltada para repositórios RDF está relacionada aos dados que já se encontram disponíveis neste modelo. No entanto, devemos considerar também as informações que estão nativamente armazenadas em SGBDs relacionais. Diante disso, podemos citar como uma motivação geral destes trabalhos, a necessidade de se prover interoperabilidade entre aplicações que armazenam seus dados no modelo relacional com aquelas que recebem consultas em SPARQL. Dentre os principais trabalhos inseridos nesta categoria, Cyganiak [Cyganiak 2005] define uma álgebra relacional para SPARQL e descreve um conjunto de regras que estabelecem a equivalência entre esta álgebra e SQL. Li Ma [Ma et al. 2008] propõe um método que traduz uma consulta SPARQL em uma única consulta SQL aninhada. Neste método, cada padrão de nó é traduzido em uma subconsulta SQL. Além disso, os autores lidam com expressões de filtro, abordam questões de eficiência e fazem uma série de avaliações utilizando o SBGD DB2. Como limitações desta abordagem, podemos citar a falta de suporte a alguns operadores, como por exemplo, GRAPH, datasets nomeados e modificadores de solução. Chebotko [Chebotko et al. 2009] apresenta um algoritmo e demonstra que este preserva a semântica na tradução de SPARQL para SQL. Neste trabalho, os autores propõem que esta tradução seja baseada

30 29 no uso de templates SQL tanto para os padrões de tripla quanto para os operadores de junção, união, opção, filtro e seleção. Por fim, ainda desenvolvem simplificações que permitem a geração de consultas mais simples e eficientes. Já Elliot [Elliott et al. 2009] estende o trabalho apresentado em [Chebotko et al. 2009] mostrando que a geração de consultas muito aninhadas possui uma baixa escalabilidade para consultas que envolvem mais de 3 ou 4 padrões de triplas. Com isso, é proposto um método que implementa cada um dos operadores de SPARQL por meio do aumento de uma consulta SQL, e não somente através do aninhamento de consultas. Uma vez estabelecido este algoritmo, a tradução dos operadores não tratados em abordagens anteriores (GRAPH, datasets nomeados e modificadores de solução) é realizada. Os autores apresentam ainda uma série de resultados experimentais que validam a eficiência do método proposto. Note que, embora estas abordagens não traduzam a consulta utilizando mapeamentos entre esquemas, elas focam em associar cada um dos construtores de SPARQL com os elementos de SQL. Por este motivo, estes métodos podem ser empregados para tradução das consultas, podendo ser incorporado a eles, a utilização dos mapeamentos locais. No que se refere à tradução de SPARQL para XQuery, não há muitos trabalhos que foquem exatamente neste problema. Em geral, a maioria das abordagens se concentra na transformação de dados XML para RDF, e vice-versa, utilizando, para isso, uma combinação de tecnologias da Web Semântica com tecnologias XML. Na linha de pesquisa voltada para Serviços Web, por exemplo, o grupo do W3C que trabalha com Anotações Semânticas para WSDL (SAWSDL) [Farrell and Lausen 2007] utiliza XSLT para converter dados XML em RDF. Este processo é chamado de lifting, ao passo que a transformação inversa (lowering) é realizada através da utilização de SPARQL e XSLT. De maneira semelhante, outros grupos do W3C (GRDDL) [Connolly 2007] utilizam XSLT para extrair dados RDF de documentos XML. Por outro lado, há trabalhos que buscam permitir que dados XML e RDF possam ser consultados em paralelo. Para isto, Groppe [Groppe et al. 2008] propõe incorporar subconsultas SPARQL em XQuery/XSLT, enquanto Droop [Droop et al. 2008] inclui consultas XPath em SPARQL. Como é possível observar, a maioria das abordagens citadas utiliza a linguagem XSLT para transformar dados, ou ainda, recebe como entrada tipos específicos de consultas XQuery ou XPath, combinadas com construtores de SPARQL, visando

31 30 consultar documentos XML e RDF em paralelo, o que não se aplica à nossa proposta. Com isso, os dois trabalhos descritos a seguir se enquadram melhor em nosso ambiente. Em [Bikakis et al. 2009b], os autores, de posse da ontologia local gerada, descrevem um método que traduz uma consulta SPARQL em uma consulta XQuery sobre esta ontologia. Para isto, utilizam um conjunto de mapeamentos simples expressos em XPath. A grande vantagem deste trabalho é permitir a tradução entre as duas linguagens que são, atualmente, os padrões do W3C. Além disso, o fato de recebermos uma consulta SPARQL como entrada facilita a utilização deste método. Já Akhtar [Akhtar et al. 2008] apresenta a linguagem XSPARQL, a qual é resultado da fusão entre SPARQL e XQuery. Com isso, podemos facilmente mapear nossas consultas de SPARQL para XSPARQL, já que a segunda linguagem engloba a primeira, e executar estas consultas sobre uma fonte de dados XML. Um benefício adicional ao se utilizar XSPARQL consiste na possibilidade de obter a resposta da consulta diretamente em RDF. Como desvantagem, temos que tal linguagem não é um padrão do W3C, portanto, ainda não há uma consolidação desta, bem como uma vasta quantidade de documentação e APIs Mapeamento entre Ontologias Mapeamentos são asserções que indicam como dados estruturados de acordo com um esquema podem ser transformados em dados descritos por meio de outro esquema. Tais asserções são essenciais para diversos cenários de mediação, como por exemplo, integração de informações, transformação de dados (data exchange) e reescrita de consultas [Yu and Popa 2004]. Em geral, duas tarefas principais conduzem o processo de geração de mapeamentos [Euzenat and Shvaiko 2007, de Bruijn and Polleres 2004]: (i) Matching: consiste no processo de encontrar o conjunto de correspondências ou relacionamentos (alinhamento) entre os elementos de diferentes esquemas, neste caso específico, das ontologias. Para esta tarefa, uma série de abordagens tem sido propostas na literatura, as quais utilizam métodos léxicos (para comparação de strings), estruturais e semânticos, além dos baseados na análise de instâncias e interação com o usuário. Em [Euzenat and Shvaiko 2007] é possível encontrar uma revisão completa sobre os métodos e ferramentas existentes para matching de ontologias. (ii) Especificação do Mapeamento: uma vez obtido o alinhamento entre as ontologias, este deve ser expresso através de uma linguagem ou formalismo adequado, de modo que possa ser utilizado por uma determinada aplicação. Tal aplicação irá

32 31 definir o nível de complexidade do mapeamento, que pode variar desde simples associações até expressões lógicas complexas. Em [de Bruijn and Polleres 2004], os seguintes fatores são apontados como alguns dos determinantes para a escolha apropriada do tipo de representação a ser utilizada: (i) expressividade e estrutura das ontologias; (ii) grau de automação do processo de geração dos mapeamentos e (iii) nível de precisão dos mapeamentos. Além disso, em geral, mapeamentos podem ser classificados de acordo com as seguintes características: Direcionalidade: um mapeamento pode ser unidirecional (injetivo) ou bidirecional (bijetivo). Um mapeamento unidirecional especifica como os termos da ontologia alvo podem ser descritos utilizando os termos da ontologia fonte, de forma que esta associação não é facilmente reversível. Já os mapeamentos bidirecionais podem ser utilizados em ambos os sentidos. Heterogeneidade: mapeamentos homogêneos são aqueles que associam entidades de natureza semelhante, como por exemplo, classe com classe e propriedade com propriedade. Os mapeamentos heterogêneos, por outro lado, mapeiam entidades de natureza distinta, permitindo que uma informação representada como uma classe em uma ontologia possa ser descrita como uma propriedade em outra ontologia [Ghidini and Serafini 2006]. Mais especificamente, podemos definir a heterogeneidade de mapeamentos da seguinte forma: considere duas ontologias O T e O S e um mapeamento MST que relaciona os conceitos de ambas. Seja ainda C T e C S o conjunto de classes e PT e PS o conjunto de propriedades pertencentes ao vocabulário de O T e O S, respectivamente. Um mapeamento homogêneo relaciona elementos de C T apenas com elementos de C S, assim como P T com P S. Já um mapeamento heterogêneo associa elementos de C T e P T com elementos de ambos os conjuntos C S e P S, ou vice-versa. Em relação a estes fatores citados, os mapeamentos que adotamos neste trabalho apresentam as características descritas a seguir, conforme detalhado no Capítulo 3. (i) As ontologias são expressas em um dialeto de OWL e podem possuir diferenças estruturais entre si. (ii) O alinhamento entre as ontologias pode ser obtido através de qualquer operador de match existente. Uma vez gerado o alinhamento, este é representado através de um modelo, baseado em sêxtuplas, para especificação de matching. Finalmente, a partir deste modelo, é gerado um conjunto de regras de mapeamento. Todo este processo ocorre de maneira semi-automática, necessitando de intervenção do usuário somente para validação e refinamento das sêxtuplas. (iii) Consideramos que os mapeamentos obtidos são precisos, corretos e consistentes. No

33 32 que diz respeito à direcionalidade, classificamos tais mapeamentos como unidirecionais. Quanto à heterogeneidade, estes podem ser homogêneos ou heterogêneos Reescrita de Consultas A reescrita de consultas, na teoria de banco de dados, é uma abordagem para processamento de consultas, na qual, dada uma consulta e um conjunto de definições de visões, o objetivo consiste em reformular a consulta em uma nova expressão. Esta nova expressão, chamada de consulta reescrita, deve referir-se às informações presentes nas visões para fornecer uma resposta ao usuário [Calvanese et al. 2000]. O problema de reescrita de consultas é relevante para diversas aplicações, tais como otimização de consultas, data warehousing e integração de informações. Particularmente, nos ambientes de integração de informações, as visões são expressas, ou obtidas, a partir de um conjunto de mapeamentos estabelecidos entre os esquemas, com o intuito de ajustar uma consulta submetida sobre o esquema alvo de acordo com um ou mais esquemas fontes. Na literatura, é comum a utilização da nomenclatura reformulação de consultas para caracterizar atividades semelhantes, as quais abrangem, algumas vezes, a própria reescrita. No que tange às ontologias, estas se relacionam com o processo de reescrita através de duas maneiras principais: (i) Como artefatos semânticos de auxílio à reformulação das consultas. Neste sentido, alguns trabalhos utilizam as ontologias para atividades de expansão, relaxamento e enriquecimento das consultas, bem como para representação de informações sobre contexto e preferências do usuário. (ii) Como as próprias fontes de dados ou, ainda, representando estas fontes ou o esquema de mediação. Nestes casos, a consulta é submetida diretamente sobre a ontologia e a reescrita é realizada entre as ontologias, ou seja, é necessário lidar com o problema de reescrita de consultas entre ontologias. Para isto, alguns aspectos devem ser considerados, como por exemplo, as características dos construtores ontológicos e a sintaxe e semântica das linguagens para representação e consultas sobre ontologias. Neste trabalho, focaremos no caso (ii), propondo, implementando e validando uma abordagem para o problema de reescrita de consultas entre ontologias, considerando diferenças estruturais entre estas. As seções sebsequentes apresentam as principais características e cenários de aplicação deste problema.

34 33 Reescrita de Consultas na arquitetura de Mediadores A arquitetura de mediadores foi introduzida no trabalho apresentado em [Wiederhold 1992], onde um mediador é descrito como um módulo de software cujo objetivo é lidar com as heterogeneidades de representação em sistemas de informação distribuídos. Esta arquitetura tem sido adotada por diversos sistemas de integração de dados, com intuito de fornecer ao usuário uma interface uniforme para acesso e recuperação de informações em fontes de dados distribuídas, sem que este necessite saber detalhes sobre o armazenamento e a recuperação dos dados. Dessa forma, um sistema baseado na arquitetura de mediador é responsável por reformular, em tempo de execução, uma consulta do usuário submetida sobre o esquema de mediação, também chamado de esquema global, em várias subconsultas sobre as fontes de dados pertencentes ao sistema. Para este fim, são estabelecidos mapeamentos que especificam o relacionamento entre estas fontes de dados e o esquema global. A abordagem adotada para definição dos mapeamentos determina como o processo de reescrita de consultas será desenvolvido no sistema [Lenzerini 2002]. A abordagem GAV requer que o esquema global seja expresso em termos das fontes de dados, ou seja, cada elemento g do esquema de mediação é associado a uma visão q S sobre as fontes de dados. Esta abordagem facilita o processo de reescrita, de forma que uma consulta submetida sobre o esquema global é respondida por meio do desdobramento da consulta (unfolding), também chamado de expansão das visões [Bilke 2007]. Neste processo, as entidades do mediador presentes na consulta do usuário são substituídas por suas respectivas definições nos mapeamentos, resultando em uma consulta contendo somente termos dos esquemas das fontes. Na abordagem LAV, o conteúdo de cada fonte de dados é caracterizado em termos do esquema global, ou seja, cada elemento s pertencente a um dos esquemas fontes é associado a uma visão q G sobre o esquema de mediação. Esta abordagem favorece a manutenção e a extensão do sistema, mas torna o processo de reescrita mais custoso, uma vez que este não pode ser realizado através da estratégia de unfolding, como na GAV. Neste caso, o problema consiste em como responder a uma consulta definida sobre o esquema global utilizando somente visões que descrevem as fontes de dados. Por fim, podemos mencionar outras duas abordagens (GLAV [Madhavan and Halevy 2003] e BAV [Mcbrien and Poulovassilis 2007]), as quais combinam GAV e LAV, visando tirar proveito dos benefícios de ambas.

35 34 Dadas estas características fundamentais, os sistemas de integração de dados com mediadores evoluíram e passaram a adicionar ontologias em suas arquiteturas, com intuito de lidar com a heterogeneidade semântica. Na literatura, é possível identificar duas arquiteturas gerais para integração de dados baseada em ontologias [Wache et al. 2001]: arquitetura de dois níveis (Figura 2.3(a)) e arquitetura de três níveis (Figura 2.3(b)). Figura 2.1. Arquitetura de dois (a) e três (b) níveis para integração de dados com ontologias Em ambas as arquiteturas, há a existência de: (i) uma ontologia de domínio que, além de representar o esquema de mediação, fornece uma representação conceitual de um domínio, como suas respectivas restrições associadas; (ii) fontes de dados que encontram-se representadas através de ontologias locais; (iii) um conjunto de mapeamentos entre as ontologias. O que distingue estas arquiteturas é a introdução, na arquitetura de três níveis, das ontologias de aplicação. Tais ontologias representam um subconjunto da ontologia de domínio e são utilizadas para facilitar as tarefas de recuperação e integração das informações, uma vez que permitem a divisão dos mapeamentos em dois estágios: (i) mapeamentos homogêneos no nível de mediação e (ii) mapeamentos OL-AO, que podem ser mais complexos e heterogêneos. Os primeiros possibilitam que a resposta a uma consulta sobre várias fontes de dados seja efetuada por meio de simples uniões, enquanto os segundos lidam com o problema da reestruturação de informações, porém para uma fonte de dados apenas. Esta divisão favorece o processo de reescrita em ambientes de integração, principalmente quando as ontologias locais apresentam diferenças estruturais significativas. Para ilustrar esta situação, considere os trechos de três ontologias apresentados abaixo (Figuras 2.4 e 2.5). Seja ainda seguinte notação: Classe(x) representa um

36 35 conceito cujo nome é Classe e x corresponde à URI de uma determinada instância de Classe; propriedade(x,y) representa uma propriedade cujo domínio é uma instância com URI igual a x e o range é um valor literal y (ou uma URI). Figura 2.2. Ontologia de domínio O D Figura 2.3. Ontologias locais O L1 e O L2 Na arquitetura de duas camadas, não seria possível definir o seguinte mapeamento (estilo GAV) no nível de mediação: O D : Editora(x) O L1 : editora(x,y) O L2 : Editora(x). Isto porque tanto na ontologia de domínio O D quanto na ontologia O L2, Editora corresponde a uma classe, enquanto em O L1, refere-se a uma propriedade. Observe que x em O L1 não é uma instância de Editora, mas sim de Livro. Dessa forma, se dividirmos a definição do mapeamento da seguinte maneira, podemos estabelecer a associação desejada: O D : Editora(x) O A1 : Editora(x) O A2 : Editora(x) O A1 : Editora(f(y)) O L1 :editora(l,y), O L1 :Livro (y) O A2 : Editora(x) O L2 : Editora(x) Neste ponto, salientamos a idéia por trás do uso das OAs: possibilitar que as fontes de dados apresentem suas informações de acordo com a ontologia de domínio, de forma a facilitar o processo de reescrita para as várias fontes, bem como a unificação dos resultados. Note que a partir do momento em que se estabelecem os mapeamentos com reestruturação, este objetivo é satisfeito, o que indica que a base conceitual da arquitetura de três camadas apresentada em [Sacramento et al. 2010a] reside neste aspecto.

37 36 Neste cenário, a abordagem apresentada neste trabalho pode ser aplicada para reescrever consultas entre as ontologias de aplicação e as ontologias locais, conforme destacado na Figura 2.3. Reescritas de Consultas em Arquiteturas P2P Sistemas de Gerenciamento de Dados peer-to-peer (PDMS Peer Data Management System) surgiram como uma extensão natural dos sistemas de integração de dados baseados em mediadores. Os PDMS são considerados o resultado da união dos benefícios do paradigma P2P, tais como a perda de uma unidade centralizadora, com a semântica rica dos bancos de dados [Pires 2009]. Devido às características intrínsecas da arquitetura P2P, nestes sistemas não há a existência de um único esquema global. Ao invés disso, cada peer representa uma fonte de dados e fornece um esquema exportado, o qual corresponde aos dados a serem compartilhados com os demais peers do sistema. Além disso, os mapeamentos são estabelecidos entre estes esquemas exportados, com intuito de possibilitar a troca de informações e a reescrita de consultas. Os PDMS tem sido utilizados para troca de dados (data exchanging), resposta à consultas (query answering) e compartilhamento de informações em muitos domínios de aplicação, como por exemplo, na pesquisa científica e em sistemas educacionais [Green et al. 2007; Ng et al. 2003]. A Figura 2.6 ilustra um exemplo de PDMS. Nele, cinco fontes de dados (FD) estão conectadas, através de seus respectivos esquemas de exportação (EXP). As setas representam os mapeamentos estabelecidos entre tais esquemas. Neste sistema, cada nó desempenha ambos os papéis de cliente e servidor, significando que se um usuário submeter uma consulta baseada no esquema de um determinado peer, o resultado irá ainda conter dados de todos os outros peers relevantes para a resposta. Figura 2.4. Exemplo da arquitetura de um PDMS

38 37 Para obter esta resposta, o processamento da consulta, ilustrado na Figura 2.7, é desenvolvido conforme descrito a seguir. Seja Q uma consulta submetida sobre o peer P 1, de acordo com o esquema exportado EXP 1. A consulta Q é, inicialmente, reescrita para uma consulta Q sobre o(s) vizinho(s) imediato(s) de P 1, que neste caso, é o peer P 2. O conjunto de mapeamentos M 1-2 é utilizado durante este processo. Em seguida, Q é reescrita em outras duas consultas Q e Q, respectivamente, sobre os peers P 5 e P 4, considerando os mapeamentos M 2-5 e M 2-4. Finalmente, Q é reformulada de acordo com o esquema do peer P 3, utilizando o mapeamento M 5-3. Após as consultas serem executadas em cada um dos peers visitados, os resultados são enviados destes para o peer onde a consulta inicial foi submetida (P 1 ). Tal peer é responsável por integrar os resultados e apresentar a resposta ao usuário. Como é possível observar, a reescrita da consulta é desenvolvida múltiplas vezes, sempre entre um esquema alvo e um esquema fonte. Figura 2.5. Processamento de uma consulta em um PDMS É válido mencionar ainda que, em muitos casos, para responder a uma consulta submetida pelo usuário, é possível utilizar vários caminhos distintos entre os peers. Encontrar um bom caminho, o qual possibilite uma menor perda de informação e um menor custo computacional, é um desafio neste tipo de ambiente [Bilke 2007]. Além disso, por questões de escalabilidade, a distribuição da consulta pode ser restrita a um número limitado de peers. Uma vez que os PDMS também lidam com fontes de dados heterogêneas, ontologias podem ser utilizadas como um modelo de dados comum para descrever os esquemas de exportação. Com isso, é possível representar os peers através de uma notação conceitual uniforme, o que facilita a definição dos mapeamentos entre os esquemas e, consequentemente, melhora o processamento da consulta [Xiao and Cruz 2006]. Esta união dos conceitos relativos aos PDMS com as ontologias leva a geração dos Sistemas de Gerenciamento de Dados peer-to-peer baseado em Ontologias

39 38 (OPDMS), cujo principal objetivo é possibilitar a interoperabilidade semântica entre os peers. Nesse sentido, destacamos que a vinculação de ontologias de aplicação aos peers pode facilitar a interoperabilidade neste sistema, caso haja uma ontologia de domínio associada ao PDMS. Por fim, salientamos que além da topologia descrita nesta seção (sistema peerto-peer puro), há ainda outras topologias, dentre as quais, a super-peer. Nesta topologia, um peer especial, chamado de super-peer, atua como um servidor para outros peers, podendo desempenhar tarefas complexas, como por exemplo, responder a consultas e integrar dados. No caso específico de PDMS, um super-peer pode ser visto como um mediador para um grupo de diversos peers, podendo estar ligado a outros peers e superpeers do sistema. Reescrita de Consultas em Linked Data Nos últimos anos, um número crescente de fontes de dados no formato RDF tem sido publicadas na Web, principalmente devido aos esforços da comunidade envolvida no projeto Linked Data 2. O objetivo desta iniciativa consiste em delimitar um conjunto de melhores práticas para publicar e conectar dados estruturados na Web, com o intuito de criar uma Web de dados. Entre tais práticas, estão: (i) o uso de URIs para identificação dos recursos; (ii) a utilização de tecnologias, tais como RDF e SPARQL, para descrição e consulta a estes recursos, respectivamente; (iii) o reaproveitamento de URIs, de forma que seja possível estabelecer ligações entre os dados disponíveis, com a finalidade de navegar através destas ligações. Se, por um lado, a Web de dados ligados traz facilidades para acesso e navegação, o problema de heterogeneidade não é eliminado. Ao contrário, este problema é transferido do nível sintático para o semântico, em dois aspectos principais: (ii) Idealmente, uma única URI deveria identificar sempre o mesmo recurso. Entretanto, ainda não há uma maneira eficaz de controlar a adoção de URIs. Como consequência, quanto mais datasets são publicados na Web, maior é o problema de sobreposição de URIs, ou seja, diferentes URIs se referem a uma mesma entidade real. (ii) Assim como as URIs, a adoção de ontologias na Web Semântica não pode ser facilmente coordenada, uma vez que diferentes aplicações publicam seus dados utilizando diferentes ontologias. Para resolver o problema (i), alguns serviços de resolução de co-referência tem sido desenvolvidos e disponibilizados na Web. Um exemplo deste tipo de serviço é o 2

40 39 semeas 3, que recebe como entrada uma URI e retorna um conjunto de URIs que identificam o mesmo recurso em alguns datasets do Linked Data. No que diz respeito ao problema (ii), se faz necessária a realização de tarefas de mediação entre as ontologias adotadas. Tais tarefas incluem a geração de mapeamentos, a tradução de dados e a reescrita de consultas. É importante destacar que, dada a natureza do ambiente, não devemos esperar que uma estratégia de reescrita seja aplicada sobre toda a Web de dados, por questões de escalabilidade. Isto seria equivalente a tentar construir um ambiente de integração de dados para toda a Web. Conforme discutido em [Bizer et al. 2009], a maneira mais eficiente de se consultar a Web de Dados, de uma maneira mais global, seria utilizando serviços de rastreamento (crawling) e armazenamento (caching), através de motores de busca guiados por URIs. No entanto, a integração de um determinado conjunto de datasets, expressos em RDF, é possível através da reescrita de consultas utilizando a linguagem SPARQL. 2.2 Abordagens para Reescrita de Consultas com Ontologias Nesta seção, descrevemos, com maiores detalhes, alguns dos principais trabalhos que se relacionam ou se aproximam de nossa abordagem What to Ask to a Peer Em [Calvanese et al. 2004], Calvanese e seu grupo discutem que, nos últimos anos, questões relativas à cooperação, integração e coordenação em sistemas de informação tem sido trabalhadas em diversos contextos, incluindo integração de dados, Web Semântica e ambientes Peer-to-Peer. Segundo os autores, de uma maneira abstrata, todos estes sistemas são caracterizados por uma arquitetura constituída por vários nós autônomos (chamados de sites, fontes ou peers), os quais armazenam informações e estão ligados a outros nós por meio de mapeamentos. Nesta arquitetura, dois problemas básicos, comuns a todos estes sistemas, devem ser investigados: (i) como descobrir e expressar os mapeamentos entre os peers; (ii) como explorar estes mapeamentos, com o intuito de responder a consultas submetidas sobre um peer. No trabalho apresentado, os autores estudam o segundo problema. 3

41 40 Para isto, consideram um cenário simplificado, composto apenas por dois peers, chamados de peer local (P l ) e peer remoto (P r ), onde: As consultas são submetidas sobre o peer local. Há um conjunto de mapeamentos relacionando informações do peer remoto com informações do peer local Cada peer fornece um serviço de resposta à consulta sobre sua própria base de conhecimento. Uma base de conhecimento de um peer é definida como uma tupla da forma P = (K,V,M), onde: - K é uma base de conhecimento escrita em algum subconjunto da lógica de primeira ordem (LPO), com um alfabeto composto de constantes e um conjunto de relações (funções não são consideradas no trabalho). - V é o fragmento exportado de K. - M é um conjunto finito de assertivas de mapeamento da forma q r q l, onde q r e q l são duas consultas de mesma aridade, chamadas consulta de remota e local, respectivamente. Uma consulta q é aceita por um peer P se ela é expressa em termos do alfabeto de V A partir deste cenário, é descrito formalmente o problema What-to-Ask : dado dois peers P l e P r e uma consulta q sobre P l, encontre uma maneira de responder a esta consulta utilizando apenas o conjunto de mapeamentos entre P l e P r, bem como os serviços de resposta à consulta existentes em cada um destes peers. Definido o problema genérico, os autores o especializam para o caso onde a base de conhecimento dos peers é expressa através de uma linguagem básica para representação de ontologias. A linguagem utilizada é um subconjunto de LPO que captura os seguintes construtores: constantes (instâncias), predicados unários (classes), predicados binários (propriedades ou relacionamentos), tipagem de relacionamentos (domínio e range), participação obrigatória de um indivíduo de uma classe em um relacionamento (restrição de cardinalidade 0 e 1), funcionalidade de relacionamentos (propriedades funcionais) e subsunção entre classes. Os mapeamentos são representados da seguinte forma: q r {x C(x) ou q r {x 1, x 2 R(x 1,x 2 ), onde q r e q r são consultas sobre o fragmento exportado do peer remoto (P r,) e C e R são conceitos e relacionamentos, respectivamente, do peer local (P l ). Na terminologia de integração de dados, estes mapeamentos podem ser

42 41 considerados GAV, de forma que P l corresponderia ao esquema global e P r, ao conjunto de fontes de dados. Além disso, é assumido que para cada conceito C ou relacionamento R do peer local há, no máximo, uma assertiva de mapeamento que utiliza C (ou R). No que se refere às consultas aceitas, estas devem ser consultas conjuntivas constituídas por relações, variáveis e constantes que se refiram ao vocabulário do peer correspondente. Visando resolver o problema What to Ask para ontologias, é proposto um algoritmo chamado de computewta. Em suma, este algoritmo, primeiramente, reformula a consulta q do cliente em um conjunto Q de consultas conjuntivas, expressas sobre K l, utilizando informações contidas na base de conhecimento. Mais especificamente, as restrições de subsunção, tipagem e funcionalidade são utilizadas para expandir o conjunto Q. Em seguida, de acordo com o mapeamento M l, o algoritmo reescreve as consultas contidas em Q em um conjunto de consultas aceitas pelo peer remoto P r. Para este fim, para cada consulta q Q, ele realiza o casamento, entre os átomos de q com os átomos de M l, gerando uma consulta expressa em termos de K r. Finalmente, os autores demonstram formalmente que, utilizando a linguagem de ontologias descrita, aliada às condições apresentadas, é possível computar soluções para o problema What to Ask, ou seja, que o algoritmo computewta é correto e sempre termina. Por outro lado, eles ainda provam que nem sempre haverá solução para o problema, caso seja adicionada a subsunção entre relacionamentos (propriedades). Isto porque o uso deste construtor pode levar à geração de um número infinito de consultas reescritas sobre P r SomeRDF Em [Adjiman et al. 2007], os autores argumentam que a Web Semântica pode ser vista como um grande PDMS semântico, onde as ontologias que representam os dados, juntamente com os mapeamentos entre estas, constituem uma enorme rede P2P. Com isso, eles apresentam um PDMS desenvolvido para Web Semântica. Tal PDMS, nomeado de SomeRDF, é construído no topo da infra-estrutura SomeWhere [Adjiman et al. 2006], utilizando um modelo de dados baseado em RDF. SomeWhere é um PDMS onde cada peer é visto como um conjunto de cláusulas proposicionais. Dessa forma, o problema de responder a uma consulta (o que inclui a reescrita desta consulta) submetida sobre um peer do sistema é reduzido ao problema de encontrar as conseqüências (consequence finding) de uma certa fórmula, na teoria da lógica

43 42 proposicional, aplicado a um cenário distribuído. Neste caso, esta fórmula pode ser vista como a consulta expressa utilizando o vocabulário de um dado peer. No SomeRDF, tanto as ontologias quanto os mapeamentos são expressos através de um fragmento de RDFS, chamado de core-rdf, o qual permite a definição de (sub)classes, (sub)propriedades, bem como a descrição do domínio e do range das propriedades. O sistema descrito é constituído por um conjunto de: (i) ontologias, chamadas de ontologias dos peers; (ii) descrições dos conteúdos armazenados (storage descriptions) nos peers, isto é, as instâncias das ontologias; (iii) mapeamentos entre os peers. Um mapeamento é uma sentença de igualdade ou inclusão entre classes ou propriedades de dois peers distintos ou, ainda, uma sentença que define o domínio ou range de uma propriedade de um peer como sendo uma classe de outro peer (veja Tabela 2.5). Todos os construtores do sistema são representados na semântica da lógica de primeira ordem (LPO) sem considerar a presença de funções. A Tabela 2.5 ilustra a representação das ontologias, instâncias e mapeamentos. As consultas, também representadas em lógica de primeira ordem, são consultas conjuntivas que podem envolver o vocabulário de vários peers. Entretanto, a consulta submetida pelo usuário deve ser formulada em termos de um único peer. O processo de reescrita da consulta entre as ontologias é realizado através de um algoritmo, chamado de DeCA RDFS, através do qual os autores convertem o conhecimento expresso em LPO para a teoria proposicional e lidam com o problema de reescrita de maneira semelhante ao SomeWhere. Para este fim, o DeCA RDFS age como uma interface entre o usuário e o algoritmo DeCA (Decentralized Consequence finding Algorithm), utilizado no SomeWhere. Tabela 2.5. Representação das ontologias e dos mapeamentos no SomeRDF Elementos da Ontologia Construtor Notação em DL Notação em LPO Inclusão de classes C 1 C 2 x(c 1 (x) C 2 (x)) Inclusão de propriedades P 1 P 2 x y(p 1 (x,y) P 2 (x,y)) Tipo do domínio P C x y(p(x,y) C(x)) Tipo do range P - C x y(p(x,y) C(y)) Instância de uma classe C(a) Instância de uma propriedade P(a, b) Mapeamento entre as Ontologias Mapeamento entre O1 e O2 Notação em DL Notação em LPO Classe P 1 :C 1 P 2 :C 2 x(c1(x) C2(x)) Propriedade P 1 :P 1 P 2 :P 2 x y(p1(x,y) P2(x,y)) Domínio P 1 :P P 2 :C x y(c1(x) C2(x)) Range P 1 : P - P 2 :C x y(c1(x) C2(x))

44 43 A estratégia do DeCA RDFS é reescrever, de maneira independente, cada átomo da consulta do usuário utilizando o DeCA e, ao final, combinar todas as reescritas, com o intuito de gerar as reescritas conjuntivas da consulta do usuário. Na literatura [Goasdoué and Rousset 2004], é demonstrado que se o número máximo de reescritas conjuntivas de uma consulta é finito, então a resposta desta consulta pode ser obtida a partir da união dos resultados de suas reescritas. Diante disso, o algoritmo DeCA RDFS garante que o número máximo de reescritas conjuntivas da consulta do usuário, no que se refere às informações dos esquemas e dos mapeamentos, é gerado. Além disso, os autores ainda demonstram que o algoritmo é correto, completo e sempre termina SemRef (Semantic Reformulation) SemRef (Semantic Reformulation) [Fernandes 2009] é uma abordagem para reformulação de consultas, em ambientes dinâmicos e distribuídos, entre uma ontologia fonte e uma ontologia alvo. No trabalho, a autora argumenta que um problema comum neste tipo de ambiente diz respeito ao fato dos conceitos existentes em um peer fonte nem sempre terem uma correspondência exata no peer alvo. Como resultado, há a geração de um conjunto vazio de reformulações de algumas consultas e, possivelmente, a ausência de respostas ao usuário. Diante disso, dependo das preferências deste usuário, pode ser mais vantajoso produzir uma reformulação adaptada/enriquecida, que devolva respostas próximas ao resultado desejado, ao invés de não retornar resposta alguma. Para produzir estas consultas enriquecidas, além da equivalência ( ), as seguintes correspondências semânticas são utilizadas entre os conceitos das ontologias fonte e alvo: especialização ( ), generalização ( ), proximidade ( ), parte-de ( ), conjunto-de ( ) e disjunção ( ). Tais correspondências são obtidas a partir do matching entre as ontologias que representam os peers (que devem pertencer ao mesmo domínio de discurso) e uma ontologia de domínio, a qual deve conter a semântica do domínio da aplicação. Com relação a estas correspondências, um diferencial refere-se à utilização das relações de proximidade e disjunção. A primeira, quando o usuário habilita o uso de consultas aproximadas, permite que conceitos relacionados aos originalmente expressos na consulta possam ser utilizados durante o processo de expansão desta. Já a segunda, provê uma solução para a negação de um conceito, através da substituição deste por todos os conceitos disjuntos a ele.

45 44 Além disso, são apontadas como características fundamentais do método proposto, a consideração do contexto do usuário, da consulta e do ambiente. O contexto do usuário é obtido por meio de um conjunto de variáveis de enriquecimento, nas quais usuário pode definir os níveis de aproximação da consulta, caso este deseje a geração de consultas aproximadas, além das exatas. O contexto da consulta é identificado a partir da semântica e do modo de reformulação desta. O contexto do ambiente é adquirido com base na disponibilidade dos peers, considerando tanto o peer onde a consulta foi submetida quanto os vizinhos deste peer. O algoritmo SemRef recebe como entrada uma consulta Q, submetida sobre uma ontologia O 1, as ontologia O 1 e O 2, um conjunto de correspondências semânticas entre O 1 e O 2 (Co[O 1,O 2 ]) e o contexto informado pelo usuário (variáveis de enriquecimento e modo de reformulação da consulta). Com saída, o algoritmo produz uma ou duas consultas reformuladas (exata e/ou enriquecida). As ontologias utilizadas são representadas no subconjunto da Lógica Descritiva conhecido como L -DL [Baader et al. 2007]. Uma consulta submetida sobre uma ontologia O i é uma expressão da forma: Q = Q 1 Q 2... Q M, onde Q i = C 1 C 2... C N e cada conceito C i {C j, C j, R.C j, R.C j. Isto significa que as consultas são expressas na forma normal disjuntiva, isto é, correspondem à união (disjunção) de consultas conjuntivas. Já os mapeamentos são homogêneos e representados em DDL (Distrubuted Description Logic) [Ghidini and Serafini 2006]. A Tabela 2.6 ilustra um exemplo com um conjunto de correspondências Co 12 da ontologia O 1 para a ontologia O 2, bem como uma consulta Q submetida sobre O 1 e as respectivas consultas reescritas (exata e enriquecida) sobre O 2. Em suma, para cada conceito C j existente na consulta, o algoritmo busca as correspondências do tipo C j C ( representa a operação), adicionando o conceito C na consulta reformulada. Este processo é desempenhado respeitando as preferências do usuário. Por exemplo, se este não habilitou as variáveis de enriquecimento, então a única correspondência utilizada é a de equivalência, o que leva a geração somente de consultas exatas. Caso contrário, as demais correspondências são também utilizadas. O método proposto é validade através da construção de um protótipo (que recebe consultas em DL e SPARQL), o qual foi utilizado para realização de experimentos. Além disso, é apresentada uma demonstração formal simples acerca da corretude e da completude do algoritmo SemRef.

46 45 Tabela 2.6. Exemplo de um conjunto de correspondências e consultas utilizadas na abordagem SemRef Linking Data to Ontologies No trabalho apresentado em [Poggi et al. 2008; Calvanese et al. 2009], os autores conduzem um estudo teórico acerca do problema de OBDA, levantando questões sobre a complexidade computacional de Lógicas Descritivas, Modelagem Conceitual, entre outros. Além disso, é apresentada uma abordagem para resolver este problema, considerando: (i) que as ontologias estão expressas na linguagem DL-Lite A (um subconjunto de DL proposto pelos autores), a qual contém os principais construtores para modelagem conceitual (classes, relacionamentos, atributos, domínio, range, subsunção e funcionalidade); (ii) que os dados estão armazenados em SGBDs relacionais. Com isso, para lidar com a questão de acessar dados relacionais através de uma ontologia, é proposta uma solução para o problema de incompatibilidade de impedância (mismatch impedance), que surge devido à necessidade de se extrair objetos, que são as instâncias da ontologia, a partir de valores presentes na fonte de dados. A resposta a uma consulta submetida sobre a ontologia é obtida através da utilização um conjunto de mapeamentos, onde cada conceito ou relacionamento da ontologia é associado a uma consulta em SQL. Para a obtenção desta resposta, a consulta é reescrita e executada sobre a base de dados, através dos seguintes passos: (i) reformulação, (ii) desdobramento (unfolding) e (iii) execução. Estas atividades estão ilustradas na Figura 2.8 e ocorrem conforme descrito a seguir. Inicialmente, uma consulta Q, submetida sobre ontologia, é expandida de acordo com as restrições

47 46 presentes na própria ontologia, como por exemplo, restrições hierárquicas (subclasse, superclasse), de domínio, range e funcionalidade. Portanto, durante esta etapa, a consulta é reformulada levando em consideração somente os componentes do TBox. Como resultado, é gerada uma nova consulta Q, a qual representa a união das consultas conjuntivas obtidas durante a reformulação. No entanto, Q não é diretamente utilizada. Tal consulta serve como entrada para a próxima etapa, chamada de unfolding, onde Q é traduzida para uma nova consulta Q, em termos do esquema da fonte de dados, considerando o conjunto de mapeamentos entre a ontologia e esta fonte. Finalmente, na etapa de execução, Q é submetida sobre a base de dados relacional e seus resultados são retornados ao usuário. Figura 2.6. Abordagem para acesso a dados relacionais a partir de ontologias Para implementação das soluções propostas, os autores desenvolveram o sistema QuOnto, que permitem ao usuário especificar, manualmente, um conjunto de mapeamentos. Para tanto, o usuário deve escrever consultas SQL sobre a fonte de dados e associá-las com as entidades da ontologia. Além disso, o sistema ainda provê outras funcionalidades, dentre as quais: checagem da consistência de uma ontologia e recebimento de consultas conjuntivas que podem ser respondidas acessando uma fonte de dados externa, conforme descrito Reescrita de consultas SPARQL para Integração de Linked Data Correndo [Correndo et. al 2010] apresentam uma abordagem, parcialmente voltada para o contexto dos datasets do projeto Linked Data, que visa possibilitar a integração de dados RDF através da reescrita de consultas em SPARQL. O algoritmo proposto para a reescrita recebe como entrada uma consulta em SPARQL, uma ontologia fonte (dataset), que é a ontologia utilizada para formular a consulta, uma ontologia alvo

48 47 (dataset) e um conjunto de alinhamentos entre estas duas ontologias. Além disso, os autores consideram que um dataset pode ter mais de uma ontologia vinculada a ele. Os alinhamentos utilizados são representados por meio de uma quádrupla (chamada de OA Ontology Alignments) da forma OA = (SO, TO, TD, EA), onde: (i) SO é o conjunto de URIs da ontologia fonte; (ii) TO é conjunto de URIs da ontologia alvo; (iii) TD é o conjunto de URIs do dataset alvo; (iv) EA é o conjunto de Entidades de Alinhamento de um OA, ou seja, é o alinhamento entre os conceitos presentes nas duas ontologias (fonte e alvo). A Figura 2.9 ilustra um exemplo de uma quádrupla (OA). Em (a), são exibidos os três primeiros conjuntos, enquanto em (b), é possível visualizar uma parte do conjunto EA (o alinhamento da propriedade akt:has_autor ). (a) (b) Figura 2.7. Exemplo dos Alinhamentos utilizados por Correndo et. al. Uma entidade de alinhamento é definida como uma tripla EA = (LHS, RHS e FD), onde: (i) LHS (Left-Hand Side) é uma tripla RDF que não contém símbolos funcionais; (ii) RHS (Right-Hand Side) é uma conjunção de triplas, também sem símbolos funcionais; (iii) FD (Functional Dependencies) é um conjunto de atribuições, para termos presentes na consulta, utilizando funções. No trabalho apresentado, estas dependências funcionais são utilizadas para transformação de URIs, visando lidar com o problema de co-referência de entidade, no contexto da reescrita. Em resumo, isto significa que se, na consulta, houver uma URI representando uma instância, esta será transformada na URI correspondente a tal instância, no dataset alvo. Por exemplo, imagine que na consulta haja a seguinte tripla:?paper akt:has-author id:person A URI id:person é uma constante que identifica um determinado autor no dataset da universidade de Southampton. Se a consulta que contém esta tripla necessita ser reescrita para uma consulta sobre a fonte de dados

49 48 ReSIST 4, que contém informações sobre publicações acadêmicas, é preciso substituir a URI id:person pela identificação deste autor no repositório ReSIST. Para esta conversão, os autores utilizam as dependências funcionais (veja um exemplo na Figura 2.9 (b)), as quais fazem uma chamada ao serviço sameas, que retorna todas as URIs equivalentes, para alguns datasets existentes no Linked Data, à URI passada como entrada. De posse da nova URI, é possível substituí-la na consulta reescrita. Observe que os autores não tratam o problema de co-referência de entidade para realização da fusão dos dados obtidos como resposta, mas somente para a substituição de URIs relativas a instâncias presentes na consulta. Durante o processo de reescrita da consulta SPARQL, o padrão de grafo é extraído, de forma que os demais construtores não são considerados (nem mesmo o filtro). Em seguida, cada uma das triplas existentes no padrão é casada com o LHS das entidades de alinhamento (EA). Para cada casamento realizado, a tripla é substituída pelo RHS correspondente ao LHS com o qual a tripla casou. Tudo isso, considerando a ligação das variáveis existentes na consulta e a substituição das entidades presentes nas dependências funcionais descritas anteriormente. Ao final, é gerado um novo padrão de grafo a ser submetido sobre o dataset alvo. Para validação da abordagem, foi desenvolvido um sistema simples, no qual o usuário insere uma consulta SPARQL e seleciona o dataset alvo. A partir de então, é gerada uma consulta reescrita, que pode ser executada sobre o SPARQL endpoint pertencente a tal dataset. Embora os autores descrevam o formato dos alinhamentos da entrada, eles não indicam como o sistema pode ser utilizado ou alimentado com estes alinhamentos, bem como não exibem os resultados das consultas testadas. Eles apenas provêem uma base com alguns alinhamentos entre os datasets ECS e DBPedia 5 e entre o AKT e o KISTI Reescrita de consultas SPARQL para mediação de consultas entre ontologias mapeadas Assim como Correndo et. al (trabalho descrito anteriormente), Markis e seu grupo [Markis et. al 2010] propõem uma abordagem para reescrita de consultas SPARQL, através da utilização de um conjunto de mapeamentos entre as ontologias. Entretanto,

50 49 tal trabalho não foca em nenhuma questão específica relacionada aos datasets do Linked Data. A ideia é que a abordagem possa ser utilizada por um sistema baseado em mediadores para integração de dados RDF. Para descrever a estratégia adotada, os autores consideram que a ontologia fonte é a ontologia sobre a qual a consulta é formulada, de maneira que tal consulta deve ser reescrita em termos da ontologia alvo. Entre estas ontologias, há um conjunto de mapeamentos (entre entidades das ontologias fonte e alvo, respectivamente) que podem ser de três tipos: (i) classe e expressão com classe; (ii) propriedade de tipo de dado e expressão com propriedades de tipo de dado; (iii) propriedade de objeto e expressão com propriedades de objeto. Portanto, temos que todos os mapeamentos são homogêneos. Além disso, a relação estabelecida entre as entidades mapeadas pode ser de equivalência ( ) ou subsunção( / ). De posse destes mapeamentos, o processo de reescrita é baseado na reformulação do padrão de grafo da consulta. Nesta abordagem, os operadores presentes neste padrão de grafo (AND, UNION, OPTIONAL, FILTER) permanecem inalterados ao longo do processo, assim como todos os construtores presentes na expressão de FILTRO. Dessa forma, a parte mais importante da estratégia consiste na reescrita dos padrões de triplas que formam o padrão de grafo. Os autores dividem estes padrões de triplas em dois grupos, chamados de Padrões de Triplas de Dados e Padrões de Triplas de Esquema, respectivamente. O primeiro grupo se refere aos padrões que buscam instâncias na ontologia, como por exemplo, o padrão?x foaf:autor?y. Neste caso, a entidade da ontologia (foaf:autor) está presente no predicado, de forma que a resposta irá retornar instâncias da ontologia FOAF. Já o segundo grupo de padrões de triplas corresponde aos que procuram informações sobre o esquema da ontologia, como por exemplo, o padrão?x rdf:subclassof foaf:pessoa. Observe que, se submetido a um dataset, este padrão não retornará dados, mas sim todas as subclasses rdf:subclassof da classe Pessoa. Além disso, a entidade da ontologia (foaf:pessoa) se encontra presente no objeto e não no predicado. Uma vez que um padrão de tripla consiste de três partes (sujeito, predicado e objeto), o procedimento de reescrita é dividido em três etapas, na seguinte ordem, de acordo com o local onde a entidade do padrão de tripla aparece: entidade no predicado, entidade no sujeito e entidade no objeto. Em cada uma destas situações, esta entidade é

51 50 buscada nos mapeamentos e substituída pelo(s) conceito(s) corresponde(s) na ontologia alvo. Ao final do processo, a consulta está expressa em termos desta ontologia alvo. A validação da abordagem é feita de forma teórica, sendo demonstrado que a consulta reescrita preserva a semântica da consulta original. No que se refere à implementação, os autores não entram em detalhes a este respeito, não descrevem o sistema, nem realizam um estudo de caso ou experimentos. 2.3 Análise Comparativa dos Trabalhos Relacionados Antes de nos aprofundarmos na análise comparativa entre as abordagens que mais se aproximam da nossa, iremos discorrer sobre alguns trabalhos que se concentram em linhas de pesquisa semelhantes. Necib [Necib 2007] utiliza ontologias para reformular consultas SQL submetidas sobre uma base de dados relacional, visando fornecer resultados mais próximos à intenção do usuário. Para isso, uma consulta SQL recebida como entrada é transformada, por meio da adição (expansão) ou remoção de termos, em outra consulta SQL, que é submetida sobre a fonte de dados. Este processo de reformulação é guiado por um conjunto de mapeamentos pré-estabelecidos entre o banco de dados relacional e uma ontologia de domínio. Há ainda trabalhos que utilizam ontologias para prover a aproximação e/ou relaxamento de consultas [Stuckenschmidt et. al 2005; Fernandes 2009], expressas em DL, entre esquemas distintos. No que se refere aos trabalhos mais voltados para a comunidade da Web Semântica, a reescrita de consultas SPARQL tem sido desenvolvida com vários objetivos, dentre os quais, a otimização, a decomposição [Quilitz and Leser 2008] e a tradução de consultas, bem como a implementação de inferências com Lógica Descritiva. A otimização de consultas SPARQL foca em técnicas de reescrita [Schmidt et. al 2010; Groppe et. al 2009; Perez et. al 2009; Stocker e. al 2008; Bernstein et. al 2007] que minimizam a complexidade de avaliação da consulta sobre uma base de dados. Por outro lado, no campo de inferências com Lógica Descritiva, Jing et. al [Jing et. al 2009] propõem reescrever uma consulta SPARQL com o intuito de implementar um mecanismo de inferência sobre esta consulta. Isto porque SPARQL é uma linguagem que aplica o casamento de padrões de grafos, não possuindo, originalmente, nenhum mecanismo de inferência sobre seus construtores. No que tange à tradução de

52 51 consultas, alguns trabalhos executam a tradução de SPARQL para SQL e XQuery, conforme já discutido na Seção É importante destacar que todas estas abordagens citadas podem ser vistas como complementares à nossa, uma vez que possuem foco ou cenário de aplicação distintos. Dada esta visão geral, podemos nos concentrar na comparação entre os trabalhos descritos na seção anterior, os quais são mais próximos de nossa estratégia. Calvanese e seu grupo desenvolvem, em [Calvanese et al. 2004], um trabalho totalmente teórico, onde são apresentados resultados iniciais básicos importantes. Como este trabalho se baseia em um cenário abstrato, é normal que outras abordagens mais pontuais [Poggi et al. 2008; Calvanese et al. 2009] reaproveitem estes resultados, apresentando também outros resultados teóricos relevantes. A estratégia de reescrita do SomeRDF, por exemplo, possui algumas semelhanças com o trabalho de Calvanese e seu grupo. A diferença fica por conta das seguintes características: (i) os autores transformam a consulta expressa em LPO para a teoria da lógica proposicional, argumentando que sem a utilização de variáveis, é possível obter um melhor desempenho, já que ambos as abordagens não lidam com funções; (ii) o trabalho é voltado para a Web Semântica e resultados experimentais são apresentados. Já Fernandes [Fernandes 2009], por outro lado, busca desenvolver uma reformulação mais semântica, adicionando novos operadores nas correspondências e utilizando informações de contexto. A idéia é permitir que os usuários obtenham respostas aproximadas, além das exatas. Entretanto, embora adicione esta semântica, a autora lida apenas com consultas envolvendo classes. Tais consultas podem ser expressas em DL ou em SPARQL, através da utilização de templates, os quais mapeiam os elementos de DL para SPARQL. Com isso, a consulta não pode ser formulada de maneira livre, pois SPARQL possui mais possibilidades de construção que DL. É válido salientar ainda que a utilização de contexto e operadores de correspondências adicionais (além da igualdade e subsunção), não consiste no foco de nosso trabalho, pois não buscamos gerar consultas aproximadas. Portanto, neste ponto, o trabalho de Fernandes pode ser visto como complementar ao nosso, possuindo um direcionamento distinto. Em [Poggi et al. 2008; Calvanese et al. 2009], o trabalho apresenta muitos resultados teóricos aplicados à lógica descritiva DL-Lite A. Os autores também lidam com o problema de OBDA, considerando uma base de dados relacional. Como já

53 52 mencionado, na abordagem aqui apresentada, nós estendemos e adaptamos esta idéia. Assim, não tratamos o problema diretamente para fontes de dados relacionais, mas sim para uma representação destas fontes através de uma ontologia local, gerada automaticamente, com seus respectivos mapeamentos locais. Esta atividade é delegada para trabalhos existentes que tratem deste problema de maneira automática. Além disso, com os dois esquemas expressos como ontologias, é possível realizar as atividades de matching e mapeamento de maneira semi-automática. No trabalho de Poogi e Calvanese, os mapeamentos devem ser estabelecidos manualmente entre a ontologia e um esquema relacional. Um outro ponto distinto diz respeito à fase de reformulação da consulta. Tanto em [Calvanese et al. 2004] quanto em [Calvanese et al. 2009], os componentes terminológicos (TBox) da ontologia são utilizados para expandir a consulta, antes que os mapeamentos sejam utilizados. Já em nosso trabalho, a fase de expansão (considerando o relacionamento de subsunção) ocorre durante a geração dos mapeamentos. Optamos por esta estratégia pelos seguintes motivos: (i) não é preciso realizar a expansão cada vez que uma consulta é submetida sobre a ontologia; (ii) em alguns casos, nem toda a hierarquia necessita ser expandida, pois, conforme será apresentada no Capítulo 3, nem sempre haverá correspondência para todas as subclasses. Além disso, nas abordagens apresentadas nos trabalhos de Calvanese, a expansão considera outras restrições, além da subsunção. Como exemplo, podemos citar as restrições de domínio. Como ilustração, imagine que a seguinte consulta seja submetida sobre a ontologia: Q = Estudante(x). O sistema deve retornar todas as URIs correspondentes a estudantes. Suponha ainda que nome seja uma propriedade de tipo de dado cujo domínio é a classe ESTUDANTE. Para recuperar todos os estudantes, devemos adicionar na consulta original o construtor nome(x,y), de forma que Q = Estudante(x) nome(x,y). Note que esta adição é importante porque, em ontologias, pode existir uma instância nome( Fernanda ), ainda que a instância Estudante( ) não esteja explicitamente declarada. Para lidar com esta questão, consideramos, a despeito da reescrita, que cada ontologia possui um serviço de resposta à consulta sobre seu próprio vocabulário. Caso seja de interesse da aplicação, este serviço pode ser associado a um motor de inferência (Racer 7 ou Pellet 8, por exemplo). Esta associação já é oferecida por várias APIs que implementam a linguagem SPARQL. Agimos dessa maneira porque, se ontologia fonte não possuir instâncias, isto

54 53 é, representar apenas um reflexo de um esquema relacional ou XML, não há necessidade de proceder com esta expansão (exceto a subsunção). Isto porque os atributos estarão sempre associados aos elementos representados pelas classes (no modelo relacional, as tabelas, por exemplo). No que tange aos trabalhos comparados até aqui, observamos que nenhum deles recebe uma consulta SPARQL livre na entrada, embora alguns possibilitem o mapeamento de DL para SPARQL. Já as abordagens seguintes ([Correndo et. al 2010] e [Markis et. al 2010]) lidam diretamente com SPARQL. No entanto, Correndo et. al não tratam expressões de filtro, além de utilizarem apenas mapeamentos homogêneos, assim como Markis e sua equipe. Além disso, Markis não apresenta a implementação da ideia proposta, enquanto Correndo não discute aspectos teóricos, mostrando apenas um estudo de caso. De maneira geral, além das diferenças já citadas, podemos apontar as seguintes características como diferenciais de nossa abordagem: (i) Focamos no problema de reescrita de consultas entre ontologias que apresentam estruturas distintas. Dessa forma, fazemos uso de mapeamentos heterogêneos expressos em uma extensão de Datalog [Hull and Yoshikawa 1990]. Por outro lado, mostramos como realizar a reescrita utilizando tais mapeamentos, que podem ser obtidos de maneira semi-automática, ao contrário da maioria dos trabalhos citados (exceto [Fernandes 2009]). (ii) Nossos mapeamentos heterogêneos lidam com restrições, as quais são caracterizadas no Capítulo 3, em ambos os esquemas fonte e alvo. Além disso, consideramos a existência de predicados de comparação (>, <, =, etc.) tanto nos mapeamentos quanto nas consultas, sendo estes predicados analisados durante o processo de reescrita. Nenhum dos trabalhos analisados trata estes aspectos. (iii) A maioria dos trabalhos, exceto [Calvanese 2009], não considera a existência de funções nos mapeamentos. Por outro lado, para Calvanese, estas funções são utilizadas apenas para lidar com as diferenças existentes entre os dados de um SGBD relacional e as instâncias das ontologias. Nós utilizamos as funções para tratar algumas diferenças estruturais. (iv) Recebemos como entrada uma consulta na linguagem SPARQL e realizamos a reescrita combinando noções de programação em lógica com a semântica dos construtores desta linguagem. Durante o nosso processo, ainda possibilitamos que partes da consulta possam ser descartadas, caso seja constatado que tais partes

55 54 retornariam vazio. Por fim, possibilitamos que os resultados sejam apresentados conforme a ontologia alvo. É importante destacar que o método proposto foi implementado e validado, utilizando o protótipo desenvolvido. A Tabela 2.7 apresenta um resumo das principais características dos trabalhos relacionados, em comparação à nossa abordagem. 2.4 Conclusões Neste capítulo, apresentamos uma visão geral da fundamentação teórica desta dissertação, discutindo os principais assuntos relacionados à nossa abordagem. Para isso, descrevemos o problema de OBDA e, uma vez que propomos resolver este problema de maneira modular, ou seja, dividindo-o em atividades independentes, discorremos sobre as cada uma destas atividades. Apresentamos uma revisão bibliográfica acerca dos trabalhos existentes para a tradução dos modelos relacional e XML para ontologias, bem como das estratégias existentes para transformação de consultas SPARQL para SQL e XQuery. Destacamos ainda quais trabalhos seriam mais adequados ao nosso propósito. Em seguida, abordamos alguns conceitos sobre mapeamento entre ontologias. O problema de reescrita de consultas, que consiste no problema chave desta dissertação, também foi discutido. Exibimos os principais cenários de aplicação para reescrita, em particular, utilizando ontologias, e descrevemos as abordagens existentes que lidam com este problema. Discorremos, de maneira mais detalhada, sobre os trabalhos que possuem características mais próximas ao nosso e, por fim, realizamos uma análise comparativa entre estes trabalhos. O próximo capítulo apresenta o ambiente de OBDA utilizado, enquanto o Capítulo 4 descreve a estratégia de reescrita desenvolvida.

56 55 Tabela 2.7. Resumo das Abordagens para Reescrita Relacionadas Abordagem What to Ask a Peer [Calvanese et al. 2004] SomeRDF [Adjiman et al. 2007] SemRef [Fernandes 2009] Objetivo Definir formalmente o seguinte problema: dado duas ontologias, como responder a uma consulta submetida sobre uma ontologia alvo dado um conjunto de mapeamentos entre estas ontologias. Reescrita de consultas entre peers na Web Semântica Reformulação de consultas em ambientes dinâmicos e distribuídos e em OPDMS. Possibilita geração de consultas aproximadas, além das exatas. Modelo (Linguagem) de Representação das Ontologias Base de Conhecimento em Lógica de Primeira Ordem (LPO) Core-RDF OWL Linguagem de Consulta Consulta em LPO Consulta em LPO ALC - DL/ SPARQL Tipo de Mapeamento/ Correspondência Homogêneo/ Mapeamentos GAV expresso em um fragmento de LPO sem considerar funções e operações de comparação/ Relações de equivalência Homogêneo/Expresso em LPO sem considerar funções e operações de comparação/ Relações de equivalência, inclusão e disjunção Homogêneo/ Correspondências expressas em DDL, sem funções e operações de comparação/ Relações de equivalência, especialização, generalização, proximidade, disjunção e agregação (parte-de; conjunto-de) Método de Reescrita Reformula a consulta submetida sobre um peer alvo utilizando restrições (subsunção, tipagem e funcionalidade) da sua própria base de conhecimento. Em seguida, usa os mapeamentos para reescrever a consulta sobre o peer fonte. Transforma a consulta expressa em LPO para lógica proposicional e reduz a resposta à consulta ao problema de encontrar as conseqüências (consequence finding) de uma certa fórmula, na teoria da lógica proposicional, aplicado a um cenário distribuído. Utiliza o conjunto de correspondências, informações de contextuais, incluindo as preferências do usuário, para gerar consultas exatas e/ou aproximadas.

57 56 [ Poggi et al. 2008; Calvanese et al. 2009] Acesso a dados (OBDA) relacionais através de uma ontologia de domínio, utilizando serviços de inferência e reescrita de consultas. OWL (DL Lite A ) Consulta em LPO Homogêneo/ Mapeamentos GAV entre um conceito na ontologia e uma consulta em SQL, sem operações de comparação / Relações de equivalência Reformula a consulta submetida sobre a ontologia utilizando restrições da ontologia. Em seguida, usa os mapeamentos para reescrever a consulta sobre a base de dados relacional. [Correndo et. al 2010] Reescrita de consultas SPARQL aplicada aos Linked Data. RDF/OWL SPARQL Homogêneo/ Expresso em RDF, sem considerar funções ou operações de comparação/ Relações de equivalência Extrai o padrão de grafo da consulta SPARQL (sem considerar o operador de filtro) e reescreve cada padrão de tripla de acordo com os mapeamentos. [Markis et. al 2010] SQuOL Reescrita de consultas SPARQL entre duas ontologias. A idéia é aplicar a abordagem em sistemas baseados em mediadores para integração de dados RDF. Reescrita de consultas entre ontologias com estruturas distintas. Pode ser aplicada em OBDA e em cenários de integração. RDF/OWL RDF/OWL SPARQL SPARQL Homogêneo/ Expresso em DL, sem funções e com operações de comparação sobre a ontologia fonte/ Relações de equivalência e subsunção Heterogêneo/ Expresso em uma extensão de Datalog, com funções e operações de comparação sobre a ontologia fonte e alvo/ Relações de equivalência e subsunção entre classes Reescreve cada padrão de tripla considerando que estes podem ser padrões de tripla de dados ou de esquema. Utiliza um método que combina noções de programação em lógica com a semântica de SPARQL. Considera as funções, contexto nas regras e operadores de comparação durante a reescrita. Descarta algumas subconsultas que retornariam vazio.

58 57 CAPÍTULO 3 Um Ambiente para Acesso a Dados Baseado em Ontologias Este capítulo apresenta o ambiente para Acesso a Dados Baseado em Ontologias utilizado neste trabalho. Inicialmente, Na Seção 3.1, são discutidos alguns dos cenários através dos quais este tipo de acesso pode ser realizado. Em seguida, é apresentada a arquitetura do ambiente, com a descrição dos principais módulos deste. Na Seção 3.2, os mapeamentos utilizados neste trabalho são caracterizados, sendo descrito, caso a caso, o processo de geração destes mapeamentos. Além disso, tal seção exibe trechos de ontologias que serão utilizadas como ilustração, ao longo desta dissertação. 3.1 Descrição do Ambiente Considerações Iniciais O objetivo do ambiente para Acesso a Dados Baseado em Ontologias (Ontology-Based Data Access OBDA) apresentado neste trabalho é prover uma infraestrutura que possa ser utilizada por aplicações que necessitem interagir com fontes de dados por meio de consultas submetidas sobre ontologias. Ao se especificar um ambiente deste tipo, é necessário considerar que ontologias e fontes de dados, além de sintaticamente diferentes, possuem níveis de abstração e expressividade distintos. Além disso, as ontologias não devem necessariamente refletir a estrutura do esquema da fonte, mas sim representar de maneira adequada o domínio dos dados. Dessa forma, pode se tornar necessário lidar com estruturas distintas entre os dois modelos, o que demanda a utilização de mapeamentos mais complexos, isto é, mapeamentos que não podem ser expressos através de associações simples entre termos [An et al. 2005]. No ambiente de OBDA aqui apresentado, tais mapeamentos serão utilizados tanto durante o processo de reescrita das consultas quanto para a reestruturação dos resultados destas. Diante disso e visando levantar alguns pontos relevantes da abordagem adotada, inicialmente, discutiremos dois possíveis cenários, ilustrados nas Figuras 3.1(a) e 3.1(b),

59 58 para realizar acesso a fontes de dados a partir de ontologias. Tais cenários são compostos pelos seguintes elementos: uma ontologia de domínio (O D ), que representa a ontologia de referência utilizada para acessar a fonte de dados; o esquema da fonte de dados; uma ontologia local (O L ), que corresponde a uma tradução sintática do esquema da fonte para uma linguagem de representação de ontologias; e um conjunto de mapeamentos, os quais podem ser classificados como homogêneos ou heterogêneos. Consideramos que um mapeamento é simples se ele pode ser representado através de uma associação direta entre os termos envolvidos. Note que, em geral, mapeamentos heterogêneos não podem ser representados através de associações diretas. Finalmente, utilizamos o termo objeto para referenciar as instâncias de uma ontologia, ou seja, triplas da forma: (sujeito, predicado, objeto). (a) (b) Figura 3.1. Cenários 1 e 2 para acesso a dados a partir de ontologias Como pode ser observado na Figura 3.1, o problema de transitar entre o mundo das ontologias e do esquema fonte, reescrevendo consultas e reestruturando resultados, pode ser tratado sob duas perspectivas, representadas pelos Cenários 1 e 2. Dependendo da abordagem adotada, o ponto de maior dificuldade ao longo do processo irá variar, uma vez que tal ponto reside no local onde se encontram os mapeamentos mais complexos. Cenário 1: A ontologia de domínio O D é mapeada diretamente para o esquema da fonte de dados. Com isso, para reescrever uma consulta submetida sobre a O D em termos de uma consulta sobre esta fonte, é necessário tratar duas questões em um

Banco de Dados Aula 1 Introdução a Banco de Dados Introdução Sistema Gerenciador de Banco de Dados

Banco de Dados Aula 1 Introdução a Banco de Dados Introdução Sistema Gerenciador de Banco de Dados Banco de Dados Aula 1 Introdução a Banco de Dados Introdução Um Sistema Gerenciador de Banco de Dados (SGBD) é constituído por um conjunto de dados associados a um conjunto de programas para acesso a esses

Leia mais

Universidade Federal de Santa Maria Curso de Arquivologia. Disciplina de Banco de Dados Aplicados à Arquivística. Versao 1.

Universidade Federal de Santa Maria Curso de Arquivologia. Disciplina de Banco de Dados Aplicados à Arquivística. Versao 1. Universidade Federal de Santa Maria Curso de Arquivologia Disciplina de Banco de Dados Aplicados à Arquivística Prof. Andre Zanki Cordenonsi Versao 1.0 Março de 2008 Tópicos Abordados Conceitos sobre Banco

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação SOFT DISCIPLINA: Engenharia de software AULA NÚMERO: 08 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir conceitos relacionados a modelos e especificações. Nesta aula

Leia mais

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de

Leia mais

Semântica para Sharepoint. Busca semântica utilizando ontologias

Semântica para Sharepoint. Busca semântica utilizando ontologias Semântica para Sharepoint Busca semântica utilizando ontologias Índice 1 Introdução... 2 2 Arquitetura... 3 3 Componentes do Produto... 4 3.1 OntoBroker... 4 3.2 OntoStudio... 4 3.3 SemanticCore para SharePoint...

Leia mais

UNIVERSIDADE FEDERAL DE SANTA CATARINA GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA DATA MINING EM VÍDEOS

UNIVERSIDADE FEDERAL DE SANTA CATARINA GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA DATA MINING EM VÍDEOS UNIVERSIDADE FEDERAL DE SANTA CATARINA GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA DATA MINING EM VÍDEOS VINICIUS DA SILVEIRA SEGALIN FLORIANÓPOLIS OUTUBRO/2013 Sumário

Leia mais

Dado: Fatos conhecidos que podem ser registrados e têm um significado implícito. Banco de Dados:

Dado: Fatos conhecidos que podem ser registrados e têm um significado implícito. Banco de Dados: MC536 Introdução Sumário Conceitos preliminares Funcionalidades Características principais Usuários Vantagens do uso de BDs Tendências mais recentes em SGBDs Algumas desvantagens Modelos de dados Classificação

Leia mais

Para construção dos modelos físicos, será estudado o modelo Relacional como originalmente proposto por Codd.

Para construção dos modelos físicos, será estudado o modelo Relacional como originalmente proposto por Codd. Apresentação Este curso tem como objetivo, oferecer uma noção geral sobre a construção de sistemas de banco de dados. Para isto, é necessário estudar modelos para a construção de projetos lógicos de bancos

Leia mais

Pesquisa com Professores de Escolas e com Alunos da Graduação em Matemática

Pesquisa com Professores de Escolas e com Alunos da Graduação em Matemática Pesquisa com Professores de Escolas e com Alunos da Graduação em Matemática Rene Baltazar Introdução Serão abordados, neste trabalho, significados e características de Professor Pesquisador e as conseqüências,

Leia mais

Criação e publicação de um dataset de dados interligados das edições passadas do Simpósio Brasileiro de Banco de Dados

Criação e publicação de um dataset de dados interligados das edições passadas do Simpósio Brasileiro de Banco de Dados U NIVERSIDADE FEDERAL DE PERNAMBUCO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO CENTRO DE INFORMÁTICA 2 0 1 2. 2 Criação e publicação de um dataset de dados interligados das edições passadas do Simpósio Brasileiro

Leia mais

Orientação a Objetos

Orientação a Objetos 1. Domínio e Aplicação Orientação a Objetos Um domínio é composto pelas entidades, informações e processos relacionados a um determinado contexto. Uma aplicação pode ser desenvolvida para automatizar ou

Leia mais

Acesso a Dados a partir de Ontologias Utilizando Mapeamentos Heterogêneos e Programação em Lógica

Acesso a Dados a partir de Ontologias Utilizando Mapeamentos Heterogêneos e Programação em Lógica UNIVERSIDADE FEDERAL DO CEARÁ CENTRO DE CIÊNCIAS DEPARTAMENTO DE COMPUTAÇÃO MESTRADO EM CIÊNCIA DA COMPUTAÇÃO Dissertação de Mestrado Acesso a Dados a partir de Ontologias Utilizando Mapeamentos Heterogêneos

Leia mais

Hoje é inegável que a sobrevivência das organizações depende de dados precisos e atualizados.

Hoje é inegável que a sobrevivência das organizações depende de dados precisos e atualizados. BANCO DE DADOS Universidade do Estado de Santa Catarina Centro de Ciências Tecnológicas Departamento de Ciência da Computação Prof. Alexandre Veloso de Matos alexandre.matos@udesc.br INTRODUÇÃO Hoje é

Leia mais

04/08/2012 MODELAGEM DE DADOS. PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS. Aula 2. Prof. Rafael Dias Ribeiro. M.Sc.

04/08/2012 MODELAGEM DE DADOS. PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS. Aula 2. Prof. Rafael Dias Ribeiro. M.Sc. MODELAGEM DE DADOS PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS Aula 2 Prof. Rafael Dias Ribeiro. M.Sc. @ribeirord 1 Objetivos: Revisão sobre Banco de Dados e SGBDs Aprender as principais

Leia mais

PROJETO DE REDES www.projetoderedes.com.br

PROJETO DE REDES www.projetoderedes.com.br PROJETO DE REDES www.projetoderedes.com.br Centro Universitário de Volta Redonda - UniFOA Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro

Leia mais

)HUUDPHQWDV &RPSXWDFLRQDLV SDUD 6LPXODomR

)HUUDPHQWDV &RPSXWDFLRQDLV SDUD 6LPXODomR 6LPXODomR GH6LVWHPDV )HUUDPHQWDV &RPSXWDFLRQDLV SDUD 6LPXODomR #5,6. Simulador voltado para análise de risco financeiro 3RQWRV IRUWHV Fácil de usar. Funciona integrado a ferramentas já bastante conhecidas,

Leia mais

Conceitos de Banco de Dados

Conceitos de Banco de Dados Conceitos de Banco de Dados Autor: Luiz Antonio Junior 1 INTRODUÇÃO Objetivos Introduzir conceitos básicos de Modelo de dados Introduzir conceitos básicos de Banco de dados Capacitar o aluno a construir

Leia mais

Introdução Banco de Dados

Introdução Banco de Dados Introdução Banco de Dados Vitor Valerio de Souza Campos Adaptado de Vania Bogorny Por que estudar BD? Os Bancos de Dados fazem parte do nosso dia-a-dia: operação bancária reserva de hotel matrícula em

Leia mais

Conceitos básicos. Aplicações de banco de dados. Conceitos básicos (cont.) Dado: Um fato, alguma coisa sobre a qual uma inferência é baseada.

Conceitos básicos. Aplicações de banco de dados. Conceitos básicos (cont.) Dado: Um fato, alguma coisa sobre a qual uma inferência é baseada. Conceitos básicos Angélica Toffano Seidel Calazans E-mail: angelica_toffano@yahoo.com.br Conceitos introdutórios de Modelagem de dados Dado: Um fato, alguma coisa sobre a qual uma inferência é baseada.

Leia mais

Persistência e Banco de Dados em Jogos Digitais

Persistência e Banco de Dados em Jogos Digitais Persistência e Banco de Dados em Jogos Digitais Prof. Marcos Francisco Pereira da Silva Especialista em Engenharia de Software Jogos Digitais - Computação Gráfica 1 Agenda Vantagens de usar a abordagem

Leia mais

Roteiro 2 Conceitos Gerais

Roteiro 2 Conceitos Gerais Roteiro 2 Conceitos Gerais Objetivos: UC Projeto de Banco de Dados Explorar conceitos gerais de bancos de dados; o Arquitetura de bancos de dados: esquemas, categorias de modelos de dados, linguagens e

Leia mais

Introdução. Banco de dados. Por que usar BD? Por que estudar BD? Exemplo de um BD. Conceitos básicos

Introdução. Banco de dados. Por que usar BD? Por que estudar BD? Exemplo de um BD. Conceitos básicos Introdução Banco de Dados Por que usar BD? Vitor Valerio de Souza Campos Adaptado de Vania Bogorny 4 Por que estudar BD? Exemplo de um BD Os Bancos de Dados fazem parte do nosso dia-a-dia: operação bancária

Leia mais

Revisão de Banco de Dados

Revisão de Banco de Dados Revisão de Banco de Dados Fabiano Baldo 1 Sistema de Processamento de Arquivos Antes da concepção dos BDs o registro das informações eram feitos através de arquivos. Desvantagens: Redundância e Inconsistência

Leia mais

ADMINISTRAÇÃO DOS RECURSOS DE DADOS

ADMINISTRAÇÃO DOS RECURSOS DE DADOS Capítulo 7 ADMINISTRAÇÃO DOS RECURSOS DE DADOS 7.1 2003 by Prentice Hall OBJETIVOS Por que as empresas sentem dificuldades para descobrir que tipo de informação precisam ter em seus sistemas de informação?

Leia mais

Engenharia de Software: conceitos e aplicações. Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com

Engenharia de Software: conceitos e aplicações. Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com Engenharia de Software: conceitos e aplicações Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com 1 Objetivos da aula Apresentar os conceitos de Engenharia de Software e explicar a sua importância.

Leia mais

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Tópicos Motivação e Objetivos LP e SOA Processo ADESE

Leia mais

SISTEMA GERENCIADOR DE BANCO DE DADOS

SISTEMA GERENCIADOR DE BANCO DE DADOS BANCO DE DADOS Universidade do Estado de Santa Catarina Centro de Ciências Tecnológicas Departamento de Ciência da Computação Prof. Alexandre Veloso de Matos alexandre.matos@udesc.br SISTEMA GERENCIADOR

Leia mais

Banco de Dados Profa. Dra. Cristina Dutra de Aguiar Ciferri. Banco de Dados Processamento e Otimização de Consultas

Banco de Dados Profa. Dra. Cristina Dutra de Aguiar Ciferri. Banco de Dados Processamento e Otimização de Consultas Processamento e Otimização de Consultas Banco de Dados Motivação Consulta pode ter sua resposta computada por uma variedade de métodos (geralmente) Usuário (programador) sugere uma estratégia para achar

Leia mais

Estrutura do Trabalho: Fazer um resumo descrevendo o que será visto em cada capítulo do trabalho.

Estrutura do Trabalho: Fazer um resumo descrevendo o que será visto em cada capítulo do trabalho. UNIVERSIDADE ESTADUAL DE MARINGÁ A monografia é um texto escrito contendo o resultado da pesquisa realizada como trabalho de conclusão do curso de especialização. Os itens básicos a constarem da monografia

Leia mais

Programação com acesso a BD. Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br

Programação com acesso a BD. Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Programação com acesso a BD Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br 1 Introdução BD desempenha papel crítico em todas as áreas em que computadores são utilizados: Banco: Depositar ou retirar

Leia mais

Organizaçãoe Recuperação de Informação GSI521. Prof. Rodrigo Sanches Miani FACOM/UFU

Organizaçãoe Recuperação de Informação GSI521. Prof. Rodrigo Sanches Miani FACOM/UFU Organizaçãoe Recuperação de Informação GSI521 Prof. Rodrigo Sanches Miani FACOM/UFU Introdução Organização e Recuperação de Informação(GSI521) Tópicos Recuperação de informação (RI); Breve histórico; O

Leia mais

Definição do Trabalho da Disciplina. Este documento é muito importante: LEIAM ATÉ O FINAL!

Definição do Trabalho da Disciplina. Este documento é muito importante: LEIAM ATÉ O FINAL! Definição do Trabalho da Disciplina Este documento é muito importante: LEIAM ATÉ O FINAL! O trabalho final da disciplina consiste na implementação de um mecanismo de processamento distribuído de tarefas

Leia mais

Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br

Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Programação com acesso a BD Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br 1 Modelos de Dados, Esquemas e Instâncias 2 Modelos de Dados, Esquemas e Instâncias Modelo de dados: Conjunto de conceitos

Leia mais

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA INTRODUÇÃO O projeto de um banco de dados é realizado sob um processo sistemático denominado metodologia de projeto. O processo do

Leia mais

Sistemas de Informação I

Sistemas de Informação I + Sistemas de Informação I Dimensões de análise dos SI Ricardo de Sousa Britto rbritto@ufpi.edu.br + Introdução n Os sistemas de informação são combinações das formas de trabalho, informações, pessoas

Leia mais

Feature-Driven Development

Feature-Driven Development FDD Feature-Driven Development Descrição dos Processos Requisitos Concepção e Planejamento Mais forma que conteúdo Desenvolver um Modelo Abrangente Construir a Lista de Features Planejar por

Leia mais

Oficina. Praça das Três Caixas d Água Porto Velho - RO

Oficina. Praça das Três Caixas d Água Porto Velho - RO Oficina Praça das Três Caixas d Água Porto Velho - RO Oficina Ministrante: Marcel Leite Rios Apresentação Pessoal Marcel Leite Rios Prof. de Informática IFRO Graduado: Sistemas de Informação - ULBRA MBA

Leia mais

Manual SAGe Versão 1.2 (a partir da versão 12.08.01)

Manual SAGe Versão 1.2 (a partir da versão 12.08.01) Manual SAGe Versão 1.2 (a partir da versão 12.08.01) Submissão de Relatórios Científicos Sumário Introdução... 2 Elaboração do Relatório Científico... 3 Submissão do Relatório Científico... 14 Operação

Leia mais

CAPÍTULO 3 - TIPOS DE DADOS E IDENTIFICADORES

CAPÍTULO 3 - TIPOS DE DADOS E IDENTIFICADORES CAPÍTULO 3 - TIPOS DE DADOS E IDENTIFICADORES 3.1 - IDENTIFICADORES Os objetos que usamos no nosso algoritmo são uma representação simbólica de um valor de dado. Assim, quando executamos a seguinte instrução:

Leia mais

Roteiro. Modelo de Dados Relacional. Processo de Projeto de Banco de Dados. BCC321 - Banco de Dados I. Ementa. Posicionamento.

Roteiro. Modelo de Dados Relacional. Processo de Projeto de Banco de Dados. BCC321 - Banco de Dados I. Ementa. Posicionamento. Roteiro Modelo de Dados Relacional Posicionamento Luiz Henrique de Campos Merschmann Departamento de Computação Universidade Federal de Ouro Preto luizhenrique@iceb.ufop.br www.decom.ufop.br/luiz Introdução

Leia mais

Banco de Dados. Aula 1 - Prof. Bruno Moreno 16/08/2011

Banco de Dados. Aula 1 - Prof. Bruno Moreno 16/08/2011 Banco de Dados Aula 1 - Prof. Bruno Moreno 16/08/2011 Roteiro Apresentação do professor e disciplina Definição de Banco de Dados Sistema de BD vs Tradicional Principais características de BD Natureza autodescritiva

Leia mais

Programação Orientada a Objetos com PHP & MySQL Sistema Gerenciador de Banco de Dados: Introdução e configuração de bases de dados com Postgre e MySQL

Programação Orientada a Objetos com PHP & MySQL Sistema Gerenciador de Banco de Dados: Introdução e configuração de bases de dados com Postgre e MySQL Programação Orientada a Objetos com PHP & MySQL Sistema Gerenciador de Banco de Dados: Introdução e configuração de bases de dados com Postgre e MySQL Prof. MSc. Hugo Souza Iniciando nossas aulas sobre

Leia mais

Metodologia e Gerenciamento do Projeto na Fábrica de Software v.2

Metodologia e Gerenciamento do Projeto na Fábrica de Software v.2 .:: Universidade Estadual de Maringá Bacharelado em Informática Eng. de Software III :. Sistema de Gerenciamento de Eventos - Equipe 09 EPSI Event Programming System Interface Metodologia e Gerenciamento

Leia mais

Uso de taxonomias na gestão de conteúdo de portais corporativos.

Uso de taxonomias na gestão de conteúdo de portais corporativos. Gestão de Conteúdo web através de ontologias: conceitos e aplicações Fernando Silva Parreiras Contextualização O que? Uso de taxonomias na gestão de conteúdo de portais corporativos. Quem? Gerentes, consultores

Leia mais

Arquitetura de Banco de Dados

Arquitetura de Banco de Dados Arquitetura de Banco de Dados Daniela Barreiro Claro MAT A60 DCC/IM/UFBA Arquitetura de Banco de dados Final de 1972, ANSI/X3/SPARC estabeleceram o relatório final do STUDY GROUP Objetivos do Study Group

Leia mais

Ajuda ao SciEn-Produção 1. 1. O Artigo Científico da Pesquisa Experimental

Ajuda ao SciEn-Produção 1. 1. O Artigo Científico da Pesquisa Experimental Ajuda ao SciEn-Produção 1 Este texto de ajuda contém três partes: a parte 1 indica em linhas gerais o que deve ser esclarecido em cada uma das seções da estrutura de um artigo cientifico relatando uma

Leia mais

4 Implementação e Resultados Experimentais

4 Implementação e Resultados Experimentais 4 Implementação e Resultados Experimentais Com o objetivo de fazer a criação automática de visões materializadas, ou seja, prover uma solução on-the-fly para o problema de seleção de visões materializadas,

Leia mais

Microsoft Access: Criar consultas para um novo banco de dados. Vitor Valerio de Souza Campos

Microsoft Access: Criar consultas para um novo banco de dados. Vitor Valerio de Souza Campos Microsoft Access: Criar consultas para um novo banco de Vitor Valerio de Souza Campos Conteúdo do curso Visão geral: consultas são essenciais Lição: inclui sete seções Tarefas práticas sugeridas Teste.

Leia mais

Diferenças da versão 6.3 para a 6.4

Diferenças da versão 6.3 para a 6.4 Release Notes Diferenças da versão 6.3 para a 6.4 Melhorias Comuns ao Sistema Help O Help Online foi remodelado e agora é possível acessar os manuais de cada módulo diretamente do sistema. Mapeamento de

Leia mais

Aula 02 Modelagem de Dados. Banco de Dados. Aula 02 Modelagem de Dados. Superior /2011 Redes Computadores - Disciplina: Banco de Dados -

Aula 02 Modelagem de Dados. Banco de Dados. Aula 02 Modelagem de Dados. Superior /2011 Redes Computadores - Disciplina: Banco de Dados - Banco de Dados Aula 02 Modelagem de Dados Roteiro Definição Evolução Projeto de BD Abstração Esquema e Instância Definição É uma representação, normalmente gráfica, de estruturas de dados reais. Auxilia

Leia mais

Pós-Graduação em Gerenciamento de Projetos práticas do PMI

Pós-Graduação em Gerenciamento de Projetos práticas do PMI Pós-Graduação em Gerenciamento de Projetos práticas do PMI Planejamento do Gerenciamento das Comunicações (10) e das Partes Interessadas (13) PLANEJAMENTO 2 PLANEJAMENTO Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 ABRIL

Leia mais

04/08/2012 MODELAGEM DE DADOS. PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS. Aula 1. Prof. Rafael Dias Ribeiro. M.Sc.

04/08/2012 MODELAGEM DE DADOS. PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS. Aula 1. Prof. Rafael Dias Ribeiro. M.Sc. MODELAGEM DE DADOS PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS Aula 1 Prof. Rafael Dias Ribeiro. M.Sc. @ribeirord 1 Objetivos: Apresenta a diferença entre dado e informação e a importância

Leia mais

Engenharia de Domínio baseada na Reengenharia de Sistemas Legados

Engenharia de Domínio baseada na Reengenharia de Sistemas Legados 1021 X Salão de Iniciação Científica PUCRS Engenharia de Domínio baseada na Reengenharia de Sistemas Legados Cássia Zottis¹, Profa. Dra. Ana Paula Terra Bacelo 1 (orientadora) 1 Faculdade de Informática,

Leia mais

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES [Observação: O template a seguir é utilizado como roteiro para projeto de sistemas orientado

Leia mais

Gerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto

Gerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto Gerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com PMBoK Organização do Projeto Os projetos e o gerenciamento

Leia mais

Banco de Dados. Introdução. João Eduardo Ferreira Osvaldo Kotaro Takai. jef@ime.usp.br DCC-IME-USP

Banco de Dados. Introdução. João Eduardo Ferreira Osvaldo Kotaro Takai. jef@ime.usp.br DCC-IME-USP Banco de Dados Introdução João Eduardo Ferreira Osvaldo Kotaro Takai jef@ime.usp.br DCC-IME-USP Importância dos Bancos de Dados A competitividade das empresas depende de dados precisos e atualizados. Conforme

Leia mais

APLICATIVO WEB PARA O SETOR DE EXTENSÃO IFC VIDEIRA

APLICATIVO WEB PARA O SETOR DE EXTENSÃO IFC VIDEIRA APLICATIVO WEB PARA O SETOR DE EXTENSÃO IFC VIDEIRA Autores: Claudiléia Gaio BANDT; Tiago HEINECK; Patrick KOCHAN; Leila Lisiane ROSSI; Angela Maria Crotti da ROSA Identificação autores: Aluna do Curso

Leia mais

O que é a ciência de dados (data science). Discussão do conceito. Luís Borges Gouveia Universidade Fernando Pessoa Versão 1.

O que é a ciência de dados (data science). Discussão do conceito. Luís Borges Gouveia Universidade Fernando Pessoa Versão 1. O que é a ciência de dados (data science). Discussão do conceito Luís Borges Gouveia Universidade Fernando Pessoa Versão 1.3, Outubro, 2015 Nota prévia Esta apresentação tem por objetivo, proporcionar

Leia mais

3.1 Definições Uma classe é a descrição de um tipo de objeto.

3.1 Definições Uma classe é a descrição de um tipo de objeto. Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Classes Autoria:Aristófanes Corrêa Silva Adaptação:

Leia mais

1. CONCEITOS BÁSICOS DE BD, SBD E SGBD

1. CONCEITOS BÁSICOS DE BD, SBD E SGBD Introdução 1. CONCEITOS BÁSICOS DE BD, SBD E SGBD A importância da informação para a tomada de decisões nas organizações tem impulsionado o desenvolvimento dos sistemas de processamento de informações.

Leia mais

Bancos de Dados. Conceitos F undamentais em S is temas de B ancos de Dados e s uas Aplicações

Bancos de Dados. Conceitos F undamentais em S is temas de B ancos de Dados e s uas Aplicações Conceitos F undamentais em S is temas de B ancos de Dados e s uas Aplicações Tópicos Conceitos Básicos Bancos de Dados Sistemas de Bancos de Dados Sistemas de Gerenciamento de Bancos de Dados Abstração

Leia mais

SISTEMA DE GERENCIAMENTO DE PROJETOS - REDMINE MANUAL DE USO

SISTEMA DE GERENCIAMENTO DE PROJETOS - REDMINE MANUAL DE USO SISTEMA DE GERENCIAMENTO DE PROJETOS - REDMINE MANUAL DE USO AGOSTO DE 2013 SUMÁRIO STI/UFF - Sistema de Gerenciamento de Projetos do PDI SUMÁRIO... 2 1 Introdução... 3 1.1 O que é e qual a finalidade

Leia mais

Banco de Dados, Integração e Qualidade de Dados. Ceça Moraes cecafac@gmail.com

Banco de Dados, Integração e Qualidade de Dados. Ceça Moraes cecafac@gmail.com Banco de Dados, Integração e Qualidade de Dados Ceça Moraes cecafac@gmail.com Sobre a professora CeçaMoraes Doutora em Computação (UFPE) Áreas de atuação Desenvolvimento de Software e Banco de Dados Experiência

Leia mais

Metadados. 1. Introdução. 2. O que são Metadados? 3. O Valor dos Metadados

Metadados. 1. Introdução. 2. O que são Metadados? 3. O Valor dos Metadados 1. Introdução O governo é um dos maiores detentores de recursos da informação. Consequentemente, tem sido o responsável por assegurar que tais recursos estejam agregando valor para os cidadãos, as empresas,

Leia mais

Capítulo 11. Conceitos de Orientação a Objetos. Rui Rossi dos Santos Programação de Computadores em Java Editora NovaTerra

Capítulo 11. Conceitos de Orientação a Objetos. Rui Rossi dos Santos Programação de Computadores em Java Editora NovaTerra Capítulo 11 Conceitos de Orientação a Objetos Objetivos do Capítulo Introduzir os conceitos fundamentais da Programação Orientada a Objetos. Apresentar o significado dos objetos e das classes no contexto

Leia mais

Uma análise de ferramentas de modelagem e gerência de metadados aplicadas ao projeto de BI/DW-UFBA

Uma análise de ferramentas de modelagem e gerência de metadados aplicadas ao projeto de BI/DW-UFBA Universidade Federal da Bahia Instituto de Matemática Departamento de Ciência da Computação MATA67 Projeto Final II Uma análise de ferramentas de modelagem e gerência de metadados aplicadas ao projeto

Leia mais

Sistemas de Banco de Dados Aspectos Gerais de Banco de Dados

Sistemas de Banco de Dados Aspectos Gerais de Banco de Dados Sistemas de Banco de Dados Aspectos Gerais de Banco de Dados 1. Conceitos Básicos No contexto de sistemas de banco de dados as palavras dado e informação possuem o mesmo significado, representando uma

Leia mais

Os desafios do Bradesco nas redes sociais

Os desafios do Bradesco nas redes sociais Os desafios do Bradesco nas redes sociais Atual gerente de redes sociais do Bradesco, Marcelo Salgado, de 31 anos, começou sua carreira no banco como operador de telemarketing em 2000. Ele foi um dos responsáveis

Leia mais

LINGUAGEM DE BANCO DE DADOS

LINGUAGEM DE BANCO DE DADOS LINGUAGEM DE BANCO DE DADOS Gabriela Trevisan Bacharel em Sistemas de Informação Universidade Federal do Rio Grande Pós-Graduanda Formação Pedagógica de Professores (FAQI) Conceito de BD Um banco de dados

Leia mais

Modelo de Dados. Modelos Conceituais

Modelo de Dados. Modelos Conceituais Modelo de Dados Modelo para organização dos dados de um BD define um conjunto de conceitos para a representação de dados exemplos: entidade, tabela, atributo,... existem modelos para diferentes níveis

Leia mais

DATA WAREHOUSE. Introdução

DATA WAREHOUSE. Introdução DATA WAREHOUSE Introdução O grande crescimento do ambiente de negócios, médias e grandes empresas armazenam também um alto volume de informações, onde que juntamente com a tecnologia da informação, a correta

Leia mais

Banco de Dados I. Introdução. Fabricio Breve

Banco de Dados I. Introdução. Fabricio Breve Banco de Dados I Introdução Fabricio Breve Introdução SGBD (Sistema Gerenciador de Banco de Dados): coleção de dados interrelacionados e um conjunto de programas para acessar esses dados Coleção de dados

Leia mais

ACOMPANHAMENTO GERENCIAL SANKHYA

ACOMPANHAMENTO GERENCIAL SANKHYA MANUAL DE VISITA DE ACOMPANHAMENTO GERENCIAL SANKHYA Material exclusivo para uso interno. O QUE LEVA UMA EMPRESA OU GERENTE A INVESTIR EM UM ERP? Implantar um ERP exige tempo, dinheiro e envolve diversos

Leia mais

Disciplina de Banco de Dados Parte V

Disciplina de Banco de Dados Parte V Disciplina de Banco de Dados Parte V Prof. Elisa Maria Pivetta CAFW - UFSM Modelo de Dado Relacional O Modelo Relacional O Modelo ER é independente do SGDB portanto, deve ser o primeiro modelo gerado após

Leia mais

1 http://www.google.com

1 http://www.google.com 1 Introdução A computação em grade se caracteriza pelo uso de recursos computacionais distribuídos em várias redes. Os diversos nós contribuem com capacidade de processamento, armazenamento de dados ou

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 14 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 14 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 14 PROFª BRUNO CALEGARO Santa Maria, 01 de Novembro de 2013. Revisão aula passada Projeto de Arquitetura Decisões de projeto de Arquitetura

Leia mais

5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância

5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância 5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância O capítulo anterior apresentou uma discussão sobre a inclusão dos chamados learning services no processo

Leia mais

Banco de Dados I. Apresentação (mini-currículo) Conceitos. Disciplina Banco de Dados. Cont... Cont... Edson Thizon (edson@esucri.com.

Banco de Dados I. Apresentação (mini-currículo) Conceitos. Disciplina Banco de Dados. Cont... Cont... Edson Thizon (edson@esucri.com. Sistemas da Informação Banco de Dados I Edson Thizon (edson@esucri.com.br) 2008 Apresentação (mini-currículo) Formação Acadêmica Mestrando em Ciência da Computação (UFSC/ ) Créditos Concluídos. Bacharel

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

Leia mais

Guia de Especificação de Caso de Uso Metodologia CELEPAR

Guia de Especificação de Caso de Uso Metodologia CELEPAR Guia de Especificação de Caso de Uso Metodologia CELEPAR Agosto 2009 Sumário de Informações do Documento Documento: guiaespecificacaocasouso.odt Número de páginas: 10 Versão Data Mudanças Autor 1.0 09/10/2007

Leia mais

Análise e Projeto Orientados por Objetos

Análise e Projeto Orientados por Objetos Análise e Projeto Orientados por Objetos Aula 02 Análise e Projeto OO Edirlei Soares de Lima Análise A análise modela o problema e consiste das atividades necessárias para entender

Leia mais

CHECK - LIST - ISO 9001:2000

CHECK - LIST - ISO 9001:2000 REQUISITOS ISO 9001: 2000 SIM NÃO 1.2 APLICAÇÃO A organização identificou as exclusões de itens da norma no seu manual da qualidade? As exclusões são relacionadas somente aos requisitos da sessão 7 da

Leia mais

Microsoft Access: Criar relações para um novo banco de dados. Vitor Valerio de Souza Campos

Microsoft Access: Criar relações para um novo banco de dados. Vitor Valerio de Souza Campos Microsoft Access: Criar relações para um novo banco de Vitor Valerio de Souza Campos Conteúdo do curso Visão geral: relações são essenciais Lição: inclui oito seções Tarefas práticas sugeridas Teste Cartão

Leia mais

Noções de. Microsoft SQL Server. Microsoft SQL Server

Noções de. Microsoft SQL Server. Microsoft SQL Server Noções de 1 Considerações Iniciais Basicamente existem dois tipos de usuários do SQL Server: Implementadores Administradores 2 1 Implementadores Utilizam o SQL Server para criar e alterar base de dados

Leia mais

INSTITUTO FLORENCE DE ENSINO COORDENAÇÃO DE PÓS-GRADUAÇÃO CURSO DE PÓS-GRADUAÇÃO EM (TÍTULO DO PROJETO) Acadêmico: Orientador:

INSTITUTO FLORENCE DE ENSINO COORDENAÇÃO DE PÓS-GRADUAÇÃO CURSO DE PÓS-GRADUAÇÃO EM (TÍTULO DO PROJETO) Acadêmico: Orientador: INSTITUTO FLORENCE DE ENSINO COORDENAÇÃO DE PÓS-GRADUAÇÃO CURSO DE PÓS-GRADUAÇÃO EM (TÍTULO DO PROJETO) Acadêmico: Orientador: São Luis 2015 (TÍTULO DO PROJETO) (NOME DO ALUNO) Projeto de Pesquisa do Programa

Leia mais

DESENVOLVIMENTO DE UM SOFTWARE NA LINGUAGEM R PARA CÁLCULO DE TAMANHOS DE AMOSTRAS NA ÁREA DE SAÚDE

DESENVOLVIMENTO DE UM SOFTWARE NA LINGUAGEM R PARA CÁLCULO DE TAMANHOS DE AMOSTRAS NA ÁREA DE SAÚDE DESENVOLVIMENTO DE UM SOFTWARE NA LINGUAGEM R PARA CÁLCULO DE TAMANHOS DE AMOSTRAS NA ÁREA DE SAÚDE Mariane Alves Gomes da Silva Eliana Zandonade 1. INTRODUÇÃO Um aspecto fundamental de um levantamento

Leia mais

Modelo de Dados. Modelo para organização dos dados de um BD

Modelo de Dados. Modelo para organização dos dados de um BD Modelo de Dados Modelo para organização dos dados de um BD define um conjunto de conceitos para a representação de dados exemplos: entidade, tabela, atributo,... existem modelos para diferentes níveis

Leia mais

Programação Estruturada e Orientada a Objetos. Fundamentos Orientação a Objetos

Programação Estruturada e Orientada a Objetos. Fundamentos Orientação a Objetos Programação Estruturada e Orientada a Objetos Fundamentos Orientação a Objetos 2013 O que veremos hoje? Introdução aos fundamentos de Orientação a Objetos Transparências baseadas no material do Prof. Jailton

Leia mais

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia. 1 Introdução aos Sistemas de Informação 2002 Aula 4 - Desenvolvimento de software e seus paradigmas Paradigmas de Desenvolvimento de Software Pode-se considerar 3 tipos de paradigmas que norteiam a atividade

Leia mais

Disciplina: Unidade III: Prof.: E-mail: Período:

Disciplina: Unidade III: Prof.: E-mail: Período: Encontro 08 Disciplina: Sistemas de Banco de Dados Unidade III: Modelagem Lógico de Dados Prof.: Mario Filho E-mail: pro@mariofilho.com.br Período: 5º. SIG - ADM Relembrando... Necessidade de Dados Projeto

Leia mais

Uma ontologia para a representação do domínio de agricultura familiar na arquitetura AgroMobile. Roger Alves Prof. Me.

Uma ontologia para a representação do domínio de agricultura familiar na arquitetura AgroMobile. Roger Alves Prof. Me. Uma ontologia para a representação do domínio de agricultura familiar na arquitetura AgroMobile Roger Alves Prof. Me. Vinícius Maran O que é uma ontologia? Palavra vinda do grego, advinda da união entre

Leia mais

INTRODUÇÃO. Enfoque abstrato. Enfoque Intermediário

INTRODUÇÃO. Enfoque abstrato. Enfoque Intermediário BANCO DE DADOS Universidade do Estado de Santa Catarina Centro de Ciências Tecnológicas Departamento de Ciência da Computação Prof. Alexandre Veloso de Matos alexandre.matos@udesc.br INTRODUÇÃO Enfoque

Leia mais

Projeto de Sistemas I

Projeto de Sistemas I Instituto Federal de Educação, Ciência e Tecnologia de São Paulo Projeto de Sistemas I Professora: Kelly de Paula Cunha E-mail:kellypcsoares@ifsp.edu.br Requisitos: base para todo projeto, definindo o

Leia mais

Capítulo 09. Construindo o Modelo do Domínio

Capítulo 09. Construindo o Modelo do Domínio Capítulo 09 Construindo o Modelo do Domínio Mapa do Processo Apresentando o Modelo do Domínio Modelo domínio: Conjunto de classes em um sistema que serve para capturar o vocabulário do contexto do problema,

Leia mais

Faculdades Santa Cruz - Inove. Plano de Aula Base: Livro - Distributed Systems Professor: Jean Louis de Oliveira.

Faculdades Santa Cruz - Inove. Plano de Aula Base: Livro - Distributed Systems Professor: Jean Louis de Oliveira. Período letivo: 4 Semestre. Quinzena: 5ª. Faculdades Santa Cruz - Inove Plano de Aula Base: Livro - Distributed Systems Professor: Jean Louis de Oliveira. Unidade Curricular Sistemas Distribuídos Processos

Leia mais

Gestão da Informação e do Conhecimento

Gestão da Informação e do Conhecimento Gestão da Informação e do Conhecimento Aula 05 Aquisição da Informação Dalton Lopes Martins dmartins@gmail.com 2sem/2014 Aquisição da Informação PROCESSO 2 - A aquisição da informação envolve as seguintes

Leia mais