• Nenhum resultado encontrado

4 DEMONSTRAÇÃO DA VIABILIDADE DA

4.5 INTERPRETAÇÃO DE PERGUNTAS E RESULTADOS OBTIDOS

4.5.1 Pergunta com conceitos do domínio de C&T

A Figura 15 a seguir exibe a interface analítica em um navegador Web, onde a ontologia do domínio de C&T é graficamente ilustrada juntamente com as regiões de entrada da pergunta e de visualização dos resultados. Essa figura traz um exemplo de pergunta no contexto de C&T já com a sua respectiva resposta. Os passos até a obtenção do cubo OLAP a partir dessa pergunta são detalhados adiante. Esses passos são praticamente os mesmos para todas as subseções a seguir. Por conta disso, as seções posteriores dão ênfase nas particularidades da resolução de ambigüidades, uso de funções e aplicação de inferências.

Figura 15 - Ilustração do protótipo da interface analítica

A pergunta “Quantas pessoas por sexo têm formação em Sociologia?”, exibida na Figura 15, é um exemplo relativamente simples que não apresenta ambigüidades, conclusões de regras de inferência e nem funções. Isto é, apenas as propriedades de classes, as classes e seus respectivos relacionamentos da ontologia de domínio de C&T são envolvidos na pergunta.

Inicialmente, essa pergunta, após ser informada na interface analítica, deve passar pelo processo de análise léxica, sintática e semântica do Analisador Lingüístico. Por consulta aos dicionários e conceitos da ontologia do domínio de C&T, o Analisador Lingüístico determina a classificação de cada termo da pergunta, que neste caso seria: “Quantas” (stop-word de quantificação); “pessoas” (classe Pessoa); “por” (stop-word de projeção); “sexo” (propriedade da classe Pessoa); “têm” (token não reconhecido); “formação” (classe Formacao); “em” (token não reconhecido) e; “Sociologia” (instância da classe AreaConhecimento). Os tokens não reconhecidos (nesse exemplo, têm e em) não estão entre os termos do dicionário e hierarquias de classes, e dessa forma não possuem classificação definida.

Antes de localizar o melhor caminho com base no modelo da ontologia de domínio, o Reformulador neste exemplo deve substituir a instância “Sociologia” por sua classe direta “AreaConhecimento”. Já que a pergunta não possui termos classificados como conclusões de regras, não há reformulação baseada em regras de inferência. No entanto, para este exemplo ocorre a reformulação por sinônimos e hierarquias de classes. Como citado na seção 4.3.1, essa reformulação é efetuada pelo Motor de Busca por Similaridade que acumula o papel do módulo Reformulador.

Com isso, a pergunta reformulada que deve ser usada como entrada para a busca pelo Motor de Busca por Similaridade apresenta somente os termos: “Pessoa sexo tem Formacao em AreaConhecimento”. Observe que os termos classificados como stop- words foram ignorados no vetor de entrada para a busca. Os termos têm e em, mesmo sem classificação, são usados na busca, sendo que os caracteres especiais (acentos, hífens) são removidos.

Somente os caminhos que possuem o maior número de conceitos identificados a partir do vetor de entrada são retornados pelo Motor de Busca por Similaridade. Logo, o melhor caminho da ontologia do domínio de C&T é aquele representado neste exemplo na notação N3 por: (Pessoa temFormacao Formacao) (Formacao temArea AreaConhecimento). Note que os outros caminhos menores contidos nesse caminho, como aqueles formados por apenas um único vértice (Pessoa; Formacao ou AreaConhecimento) e aqueles formados pelas triplas; (Pessoa temFormacao Formacao) ou (Formacao temArea AreaConhecimento) não devem ser retornados na busca. Com isso, nesse caso um único caminho é obtido sem a necessidade de participação do tomador de decisão para a desambiguação de entidades e caminhos.

Com o melhor caminho definido, o conjunto de padrões e heurísticas comentados na Tabela 5 é aplicado pelo Tradutor OLAP. Assim, a partir dos elementos classificados e dos tipos de stop-words, a requisição OLAP gerada possui como medida: a classe Pessoa; como agrupamento: a propriedade sexo, e as classes Formacao e AreaConhecimento; e como filtro: o termo Sociologia, que é uma instância da classe AreaConhecimento. Os relacionamentos (temFormacao e temArea) são também traduzidos na requisição como os relacionamentos (junções) que interligam os conceitos do domínio. A partir da requisição OLAP, o Gerenciador de Consultas atua com o módulo Gerenciador de Ontologias para montar e aplicar a consulta com as dimensões ou tabelas de fato associadas aos conceitos identificados na pergunta (no caso, Pessoa, sexo, temFormacao, Formacao, temArea, AreaConhecimento). Para tal, as instâncias da Ontologia BI que mapeiam esses conceitos à estrutura do DW são recuperadas pelo Gerenciador de Ontologias. Após localizar essas instâncias, o Gerenciador de Ontologias informa ao Gerenciador de Consultas as dimensões, os atributos de dimensão, as tabelas de fato e como elas são interligadas para a criação da consulta SQL.

Como visto, as propriedades de classes são na maioria das vezes associadas aos atributos de dimensão na Ontologia BI. No entanto, somente uma propriedade (propriedade sexo da classe Pessoa) foi informada e reconhecida na pergunta. Como mencionado na seção 4.3.3, de acordo com a tradução do Tradutor OLAP, um atributo padrão deve ser definido como medida, agrupamento ou filtro para a classe. Assim, quando uma classe não possui qualquer propriedade explicitamente informada, o atributo configurado como padrão na Ontologia BI é aquele que deve ser utilizado na consulta.

Destarte, considerando a configuração da Ontologia BI e a pergunta deste exemplo, o atributo SEQ_ID_PESSOA da dimensão DI_PESSOA é utilizado como medida padrão e correspondente à classe Pessoa. Já a classe Formacao, que corresponde na Ontologia BI à dimensão DI_FORMACAO, possui como agrupamento o atributo DSC_NIVEL_FORMACAO. Por fim, a classe AreaConhecimento tem como agrupamento e também filtro o atributo NME_AREA_CONHEC da dimensão DI_AREA_CONHECIMENTO.

Para saber quais as junções que relacionam as dimensões DI_PESSOA, DI_FORMACAO e DI_AREA_CONHEC na consulta, o Gerenciador de Consultas utiliza os relacionamentos temFormacao e temArea obtidos do caminho identificado. Igualmente, o Gerenciador de Consultas obtém as informações da Ontologia BI por meio do

Gerenciador de Ontologias para produzir as junções entre as tabelas. Essas informações configuradas na Ontologia BI indicam quais os atributos das dimensões usados para realizar a junção e o tipo de junção (inner join, left join, etc.) Por fim, a consulta SQL resultante do Gerenciador de Consultas que responde a pergunta é apresentada no Quadro 5 a seguir. ! "#$% !& '( ) *+ *, " $% !&- . & ( /)!)( ) *+ *, " $-/ &) )&!(-0 ! ) *+1*, !(2- % -! "#$ 3& %& () ) * * (/ ) $% & () "# -- 4( - ) $% & ( /)!)( "

(- "#$ 3& %& ( /)!)( 5 " $ 3& %& ( /)!)( -- 4( - ) $% &) )&!(-0 ! / - ( "

(- " $ 3& %&) ) 5 " $ 3& %&) )&!(-0 ! 60 " $-/ &) )&!(-0 ! -

7 (! ( (8 )7, 7 + 7 , 7 + 7

8 (2 9: "#$% !& '(, " $% !&- . & ( /)!)(, " $-/ &) )&!(-0 ! ( % 9: "#$% !& '(, " $% !&- . & ( /)!)(, " $-/ &) )&!(-0 ! Quadro 5 - Consulta SQL gerada a partir da pergunta do domínio de C&T. O Gerenciador de Consultas, após executar a consulta SQL do Quadro 5 sobre o DW, disponibiliza o cubo OLAP com os cabeçalhos de coluna contendo as informações de classes e propriedades do domínio (veja a Figura 15). Conforme comentado na seção 4.4, observe que o valor Sociologia, usado como filtro na cláusula WHERE da consulta SQL, é colocado em caixa-alta, em caixa-baixa e na forma como é informado na pergunta. Por padrão, todos os agrupamentos são ordenados (cláusula ORDER BY) na resposta.