You are on page 1of 17

Objectivo Geral................................ ................................ ................................ .....................

2V
Objectivos Específicos ................................ ................................ ................................ ...... 2V
Metodologia................................ ................................ ................................ .......................... 2V
INTRODUÇÃO ................................ ................................ ................................ .................... 3V
Full Text Search ................................ ................................ ................................ .................... 4V
Criação de Full Text Catalog ................................ ................................ ................................ . 4V
Criação de Full Text Index ................................ ................................ ................................ .... 5V
Change Tracking ................................ ................................ ................................ ............... 7V
Linguagem, separadores de palavras e derivativos................................ ................................ . 8V
Consulta de Full Text Data ................................ ................................ ................................ .... 9V
FREETEXT ................................ ................................ ................................ ...................... 9V
FREETEXTTABLE ................................ ................................ ................................ .......... 9V
CONTAINS ................................ ................................ ................................ .................... 10V
Thesaurus (Dicionário de sinônimos) ................................ ................................ .................. 13V
Stop Lists ................................ ................................ ................................ ............................ 14V
Preencher Full Text Indexes ................................ ................................ ................................ 14V
Conclusão ................................ ................................ ................................ ........................... 16V
Bibliografia ................................ ................................ ................................ ......................... 17V
V V
! VV 
V

O tempo de resposta aos pedidos efectuados às Base de Dados é uma das questões mais
preponderantes no que diz respeito a performance e desempenho destas, principalmente nas
consultas de pesquisa de textos simples e ficheiros de textos. Sendo assim, deve-se
implementar um mecanismo de busca mais rápido que faça consultas procurando por partes
de sequência de caracteres de uma forma rápida de forma a melhorar significativamente a
performance e posterior desempenho das Base de Dados.


 V V
Implementação da funcionalidade Full Text Search no Sistema de Base de Dados SQL
SERVER 2008.


 V V
V Criar de Catalogos para armazenamento de Full Text Index
V Criar de Full Text Index usando GUI (Graphical User Interface) e usando
Transactional SQL
V Implementação de novos conceitos de Indice Full para o Sistema de Gestão de Base
de dados Sql Server na sua versão de 2008.V

   V
Este tema tem vindo a sofrer mudanças positivas desde a sua idealização. Neste contexto este
trabalho de pesquisa baseou-se na metodologia de Análise e Documentos já existentes.

V V
R !V
Os índices mais usados em um bases de dados do SQL Server são em cluster e índices não-
clusterizados que são organizados em uma estrutura de árvore binária.

Neste trabalho de pesquisa, iremos fazer uma abordagem sobre o Full-Text Indexing
mostrando como projectar e criar, visando atender as necessidades de desempenho em
consultas de grandes quantidades de texto.

Isto inclui a capacidade de executar consultas complexas em dados de caracteres. Essas


consultas podem incluir a palavra ou frase a pesquisa, pesquisas de proximidade, jogos
flexionais e ranking Revelance (o quão perto estão as palavras).

V
Fu V V V

Full Text Search refere-se a uma funcionalidade do SQL Server que suporta consultas do tipo
Full Text sobre dados do tipo caracteres.
Este tipo de consultas pode incluir tanto palavras, frases como variações de palavras e frases.
Para o suporte de consultas do tipo Full Text Search, tem de se implementar Full Text
Indexing nas colunas definidas na consulta. As colunas podem ser de tipos de dados de
caracteres (tais como char e varchar) ou tipos de dados binários (varbinary ou image) ou
ainda XML (Extensible Markup Language). O Full Text Indexing é caracterizado pela
divisão em palavras ou tokens derivadas dos textos indexados. Por exemplo se o texto
indexado contém a frase ³Tabelas podem conter índices´, o Full Text Indexing teria quatro
palavras ou tokens: ³Tabelas´, ³podem´, ³conter´ e ³índices´. E porque listas de símbolos
podem ser facilmente pesquisadas, as consultas Full Text podem rapidamente localizar as
palavras necessárias.

Para implementação do Full Text Indexing pode-se seguir os seguintes passos:


1.V Criação de um Full Text Catalog se não existir;
2.V Criação do Full Text Index;
3.V Alteração das StopLists se necessário;
4.V Alteração da língua a ser usada para a lista de palavras.

  V VFu V V  V


O primeiro passo na construção de um Full Text Index é criar uma estrutura de
armazenamento. Ao contrário dos índices relacionais, Full Text Index tem uma única
estrutura interna que é mantida dentro de um formato de armazenamento separado chamado
catálogo de Full Text Index. Um Full Text Catalog disponibiliza um mecanismo para a
organização de Full Text Index. Cada catálogo pode conter zero ou mais índices, mas a cada
índice só pode estar associado apenas um catálogo. No SQL Server 2008 um Full Text
Catalog é uma conceptualização lógica que se refere a um agrupamento de Full Text Index.
A sintaxe genérica para a criação de um catálogo de Full Text Index é:
 VF""#V  "V<NomeDaBaseDeDados>

[ VFR"V2ilegroup]

[R V  ö irectório (rootpath)¶

[$R <Opções_do_Catálogo>]
[ V!F "]

[ R R iome_do_Propietário]

Onde:

<Opções_do_Catálogo>=:

$RV   RRR = {OFF|ON}

Os Full Text Catalog estão directamente associados a uma base de dados específica. A única
cláusula obrigatória é CREATE FULLTEXT CATALOG onde se especifica qual é o nome
pretendido para o catálogo. Pode-se ainda definir se o catálogo é padrão ou não, se sim todos
os Full Text Index que não forem atribuídos catálogos serão armazenados no catálogo padrão.
ACCENT_SENSITIVITY permite configurar se o mecanismo de Full Text considera
acentuação quando criado ou ao consultar um Full Text Index. Se alterar-se a opção de
ACCENT_SENSITIVITY, será necessário recriar todos os Full Text Index dentro do
catálogo.
A cláusula AS DEFAULT funciona da mesma forma a opção DEFAULT (padrão) para um
grupo de arquivos. Se não se especificar um nome de catálogo ao criar um Full Text Index, o
SQL Server cria o índice dentro do catálogo que está marcado como o Full Text Catalog
padrão.
A opção AUTHORIZATION (autorização) especifica o proprietário do Full Text Catalog. O
proprietário especificado deve ter permissão APROPRIAR no Full Text Catalog.

  V VFu V VR V


É importante referir que o SQL Server obriga que um Full Text Index esteja associado a um
catálogo, sendo assim, é importante que a criação de um Full Text Index seja feita em bases
de dados que contém um ou mais catálogos, caso contrário o Full Text Index será alocado no
catálogo padrão do sistema.
Um Full Text Index é definido ao nível de uma tabela, e apenas um índice pode ser atribuído
por cada tabela. Para uma tabela suportar um Full Text Index, um índice único (unique índex)
tem de ser definido na tabela. Além disso, o índice tem que ser definido em uma única coluna
não nula. Esta coluna é referenciada como o índice chave (key índice) na criação do Full Text
Index. Para uma melhor performance, o índice chave pode ser definido em uma coluna que
está configurada para dados do tipo inteiro. A chave primária da tabela (geralmente um ID) é
a melhor candidata para tal.
O uso mais comum de uma coluna VARBINARY (MAX) é armazenar documentos usando
os novos recursos FILESTREAM no SQL Server 2008. O mecanismo de Full Text pode
construir um índice directamente nos documentos criados, evitando assim processos
dispendiosos de conversão, o mecanismo precisa empregar assemblies especializados
projectados para os vários tipos de documentos que o usuário deseje armazenar. Ao processar
uma coluna VARBINARY (MAX), é preciso especificar uma coluna que designa o tipo de
documento para que o analisador de Full Text possa carregar o assembly apropriado. SQL
Server 2008 vem com 50 filtros que permitem o processamento de uma variedade de tipos de
documento como HTML (Hypertext Markup Language), Word, Microsoft Office PowerPoint
e Microsoft Office Excel.
O mecanismo de Full Text Indexing usa serviços auxiliares como separadores de palavras e
derivativo (stemmers) que são idiomas específicos para criar índices. A primeira tarefa de
construir um índice eficiente de dados não estruturados é construir uma lista de palavras
dentro dos dados que estão sendo indexados. Os separadores são assemblies que colocam
quebras entre palavras para criar uma lista de palavras a serem indexadas. Como verbos
podem ter várias formas, como o passado, presente e futuro do indicativo, derivativos
conjugam verbos para que as consultas realizadas possam localizar informações mesmo entre
várias palavras verbais.
A lista de palavras é filtrada através de uma lista de palavras comuns chamada stop words.
São especificados stop words para que o índice não fique cheio de grandes volumes de
palavras que não se iriam procurar normalmente. Por exemplo, a, are, an e the são
consideradas stop words para o idioma inglês.
A sintaxe genérica para a criação de um Full Text Index é:
  VFu  VR  on <iome aTabela>

[{(nome_da_coluna,

[" nome_do_tipo_de Coluna],

["   termo_da_língua]

} [..n]

)]

$ %VR  <PK_TablesPrimaryKey>

[ <catalog_filegroup_option>]

[V[ ) ] opções do with[,«n] [ ) ] ]


[;]

<    u>::=

{fulltext_catalog_name

| ( fulltext_catalog_name, FILEGROUP filegroup_name )

| ( FILEGROUP filegroup_name, fulltext_catalog_name )

| ( FILEGROUP filegroup_name )}

<>::=

{  $R V[ = ] { MANUAL | AUTO | OFF [, NO POPULATION ] }

| "R [ = ] { OFF | SYSTEM | stoplist_name }}

O parâmetro V" designa a coluna que contém o tipo de filtro que o motor de
Full Text Indexing utiliza quando processa uma coluna VARBINARY (MAX). O paramento
"   é opcional e é usado para especificar a língua dos dados a serem indexados. O
parâmetro $V R !# é a coluna única na tabela ou na indexed view, que identifica de
forma única as linhas.

  V &V
A opção CHANGE_TRACKING para um Full Text Index determina como o SQL Server faz
a manutenção dos índices quando a informação é alterada na base de dados. Quando a opção
MANUAL ou AUTO é especificada, o SQL Server actualizaVa lista de alterações na base de
dadosV para os dados indexados. Quando opção MANUAL é especificada, o utilizador é
responsávelVpor periodicamente sincronizar as alterações para o Full Text Index. Não mantém
a lista de alterações actualizada. Quando definida como AUTO, o SQL Server actualiza
automaticamente o Full Text Index sempre que os dados são modificados. Ao contrário de
um índice relacional, o preenchimento (populate) de um Full Text Index não é um processo
imediato porque os dados têm de ser enviados para o mecanismo de indexação, que, em
seguida, aplica-se a separadores de palavras, derivativo, arquivos de idioma, e Stop lists antes
de efectuar as alterações no índice. Quando CHANGE_TRACKING é especificado como
OFF, o SQL Server não mantém uma lista de alterações de dados subjacentes. Portanto, se
quisermos actualizar o índice para mostrar os dados actualmente na coluna indexada, deve-se
repovoar o índice completamente. Com CHANGE_TRACKING desactivado, também se
pode especificar a opção NO POPULATION, que permite-nos criar o Full Text Index sem
preencher após a criação inicial.

"u  'V   V V  V V  V


A especificação da linguagem é um componente fundamental na construção de um Full Text
Index eficaz. Embora pudéssemos usar simplesmente um separador de palavras único para
todos os dados, quando os dados se estendem por vários idiomas, podemos ter resultados
inesperados.
A especificação da linguagem é usada para controlar o separador de palavras específicas e
derivativos carregados pelo mecanismo de Full Text Indexing. O separador de palavras
seleccionadas e derivativos serão o mesmo para todo Full Text Index e não é possível alterar
dinamicamente com base em um tipo de coluna como se pode aplicar a uma coluna
VARBINARY. No entanto, não será preciso dividir dados de coluna com base em cada
idioma específico. Apesar de que palavras podem ser diferentes, pode-se agrupar várias
linguagens em um pequeno conjunto de famílias de línguas e cada separador de palavras tem
a capacidade de lidar com palavras que se estendem por um grupo restrito de línguas.
SQL Server 2008 vem com 50 separadores de palavras específicas de idioma ou derivativo.
Suporte também está incluído para que se possa registar e usar terceiros separadores e
derivativos dentro do SQL Server. Por exemplo, Turco, dinamarquês e polonês são
separadores de terceiros que são fornecidos com o SQL Server 2008.
Separador de palavras aloca e indexa limites de palavras num texto. O Full Text Index, em
seguida, agrupa cada símbolo para criar estatísticas de distribuição para pesquisa. Além disso,
os separadores reconhecem proximidade dentro do conjunto de dados e construir a
proximidade para as estatísticas de distribuição de Full Text. A capacidade de pesquisar com
base na proximidade da palavra é uma característica exclusiva dos Full Text Indexes que
permitem critérios de pesquisa compostos que levam em conta como palavras se relacionam
entre si.
O SQL Server usa derivativos para permitir que um Full Text Index pesquise em todas as
formas flexionadas de um termo de pesquisa, drive, drove, driven, and driving. Embora se
poderia empregar um separador de palavras alemãs para indexar o inglês, o derivativo alemão
não pode processar inglês.
u  V VFu V V!  V
O SQL Server fornece dois comandos para consultar Full Text Data:   R  e
F#. Há dois comandos adicionais que produzem um resultado com colunas
adicionais de informações:   R  (" e F# (".
A principal diferença entre os quatro comandos é que   R  e F# retornam
um valor booleano (verdadeiro ou falso) usado para restringir um conjunto de resultados, e
  R  (" e F# (" retornam um conjunto de resultados que
podem ser usados para estender a funcionalidade de consulta.
Com base na criação de símbolos do termo de pesquisa, estatísticas de distribuição são
retornadas para o optimizador, que une a parte do Full Text da consulta com a parte
relacional para construir um plano de consulta.

F#VV
As consultas FREETEXT são a forma mais básica das pesquisas Full Text. A sintaxe
genérica para a consulta FREETEXT é:
F# ( { column_name | (column_list) | * }

, 'freetext_string' [ , LANGUAGE language_term ] )

Um exemplo de uma consulta FREETEXT é:

" ProductDescriptionID, Description

F Production.ProductDescription

$ F#(Description,N'bike')

V

O parâmetro K i  permite especificar o separador de palavras e derivações que são


utilizadas para avaliar o argumento de entrada de pesquisa. Embora pode-se ter usado a
língua alemã para construir o índice de texto completo, pode-se especificar um parâmetro de
inglês para empregar um separador de palavras específicas inglês para a consulta.
V

F# ("V
Retorna um resultado com informações adicionais que classifica os resultados de acordo com
como a correspondência se aproxima do termo da pesquisa original.
É a sintaxe genérica para FREETEXTTABLE
F# (" (| , { 
| (
 |) | * }
, '2 | |
| '

[ ,"     
| ]

[ ,|


] )

A mesma consulta expressa com FREETEXTTABLE é a seguinte:

SELECT a.ProductDescriptionID, a.Description, b.*

FROM Production.ProductDescription a

INNER JOIN FREETEXTTABLE (Production.ProductDescription,

Description,N'bike') b ON a.ProductDescriptionID = b.[Key]

ORDER BY b.[Rank]

GO

  R VV
Para consultas que exigem uma maior flexibilidade, pode-se usar o predicado   R ,
que permite:
Pesquisar formas de palavras
âV Pesquisa por proximidade de palavra;
âV Fornecer ponderação relativa aos termos.

A sintaxe genérica para CONTAINS é:


  R V

( { 
| (
 |) | * }

, '<  |
 
  |  >'

[,"     
| ] )

<  |
 
  |  > ::=

{  
| > | <  2
| > | <   | 
| >

| <    |
| > | <  |
| > }

| { ( <  |
 
  |  > )

[ { < AND > | < AND NOT > | < OR > } ]

<  |
 
  |  > [ ... ] }
ƒVsimple_term VV

word VVphrase V

ƒVprefix term VV

Vword VVVphrase VV

ƒVgeneration_term VV


V VV VV 
 VVVƒVsimple_term VVn VV

ƒVproximity_term VV

VƒVsimple_term VVƒVprefix_term VV

VV
VVVV

VƒVsimple_term VVƒVprefix_term VVVVVV

ƒVweighted_term VV

  V VVVƒVsimple_term VVƒVprefix_term VVƒVgeneration_term V

VƒVproximity_term VV

V V Vweight_value VVVVn VV

Termos de pesquisa podem ser usados para qualquer correspondência exacta ou como
prefixos. A consulta a seguir retorna os produtos com uma correspondência exacta da palavra
µbike¶. Embora a consulta pareça ser quase exactamente o mesmo que a versão FREETEXT,
a consulta CONTAINS retorna menos duas linhas devido a correspondência exacta, como
segue:
SELECT ProductDescriptionID, Description

FROM Production.ProductDescription

WHERE CONTAINS (Description, N'bike')

GO

Se compararem-se os resultados anteriores à consulta FREETEXT, ver-se-á que cada retorna


o mesmo conjunto de linhas. Com CONTAINS, deve-se especificar explicitamente que
deseja-se executar uma pesquisa difusa, que inclui prefixos de palavra, mas FREETEXT
padroniza para uma pesquisa difusa.
Nos casos em que se deseja pesquisar em variantes de palavras, podem-se usar as opções
FORMSOF, INFLECTIONAL e dicionário de FULL TEXT. Por exemplo, pesquisando sobre
driven também pesquisa por drive, driving, drove, etc. O dicionário de FULL TEXT
(Thesaurus) produz sinónimos para o termo de pesquisa. Um exemplo de pesquisa em
variantes de palavras é o seguinte:
SELECT ProductDescriptionID, Description

FROM Production.ProductDescription

WHERE CONTAINS (Description, N' FORMSOF (INFLECTIONAL, ride) ')

GO

SELECT ProductDescriptionID, Description

FROM Production.ProductDescription

WHERE CONTAINS (Description, N' FORMSOF (THESAURUS, metal) ')

GO

Porque os Full Text Indexes são construídos contra dados não estruturados, o índice
armazena a proximidade de uma palavra para outra além disso para a indexação das palavras
encontradas dentro dos dados. Pesquisa de proximidade é realizada usando a palavra-chave
NEAR. Embora seja possível executar pesquisas de proximidade e pesquisas de proximidade
ponderada usando CONTAINS, esses tipos de pesquisas geralmente são executados usando
  R  ("Vpara usar o valor de classificação que é calculado.
A consulta a seguir retorna todas as linhas onde µbike¶ está perto de performance . O valor
de classificação é afectado pela distância entre as duas palavras:
SELECT a.ProductDescriptionID, a.Description, b.*

FROM Production.ProductDescription a INNER JOIN

  R  ("V(Production.ProductDescription, Description,

N 'bike   performance') b ON a.ProductDescriptionID = b.[Key]

ORDER BY b.[Rank]

GO

A consulta a seguir retorna as 10 linhas por posto de acordo com a média ponderada das
palavras per2ormance, com2ortable, smooth, sa2e, e competition:

SELECT a.ProductDescriptionID, a.Description, b.*

FROM Production.ProductDescription a INNER JOIN


CONTAINSTABLE (Production.ProductDescription, Description,

N'ISABOUT (performance WEIGHT (.8), comfortable WEIGHT (.6),

smooth WEIGHT (.2) , safe WEIGHT (.5), competition WEIGHT (.5))', 10)

b ON a.ProductDescriptionID = b.[Key]

ORDER BY b.[Rank] DESC

GO

  u uV)!* V V+ ,V


Pode-se usar um arquivo de dicionário de sinónimos (Thesaurus Files) para permitir consultas
de Full Text recuperar linhas que coincidam com o argumento de pesquisa juntamente com
sinónimos de um argumento de pesquisa. Um dicionário de sinónimos (Thesaurus Files) é um
idioma específico de um arquivo XML que é armazenado no directório FTDATA. Depois de
defini-lo, o SQL Server usa o dicionário de sinónimos automaticamente para consultas
FREETEXT e FREETEXTTABLE. O dicionário de sinónimos é usado apenas para consultas
CONTAINS e CONTAINSTABLE quando o usuário especifica a opção FORMSOF
THESAURUS.
Um dicionário de sinónimos pode conter conjuntos de expansão ou conjuntos de substituição.
Um conjunto de substituição define um termo ou termos que são substituídos dentro do
argumento de pesquisa prioritário para o separador de palavras derivar a lista de argumentos.
Um conjunto de expansão define um conjunto de termos que são usados para desenvolver um
argumento de pesquisa. Quando é utilizado um conjunto de expansão, uma correspondência
com qualquer termo dentro do conjunto de expansão faz com que o SQL Server recupere a
linha.
A estrutura básica de um arquivo de dicionário de sinónimos (Thesaurus File) é:

<XML ID="Microsoft Search Thesaurus">

<!-- Commented out

<thesaurus xmlns="x-schema:tsSchema.xml">

<diacritics_sensitive>0</diacritics_sensitive>

<expansion>

<sub>Internet Explorer</sub>

<sub>IE</sub>
<sub>IE5</sub>

</expansion>

<replacement>

<pat>NT5</pat>

<pat>W2K</pat>

<sub>Windows 2000</sub>

</replacement>

<expansion>

<sub>run</sub>

<sub>jog</sub>

</expansion>

</thesaurus>

-->

</XML>

Na configuração de DEACRITICS especifica se o dicionário de sinónimos é sensível a


acentuação.

V"VV
Listas de Paragem (Stoplists), conhecidas em versões anteriores do SQL Server como
ficheiros de palavras irrelevantes, são usadas para excluir palavras que se deseja incluir em
um Full Text Index.

  VFu V VR  V


Full Text Indexes podem ser preenchidos manualmente, por demanda, ou em uma agenda ou
automaticamente como dados abaixo das mudanças do índice. Pode-se parar, pausar ou
retomar o preenchimento de um índice para controlar a utilização do recurso ao fazer grandes
volumes de alterações em um Full Text Index.
As opções para preencher um Full Text Index são:

âV F"" reprocessa cada linha de dados subjacentes para reconstruir o Full Text Index
completamente;
âV R   " processa apenas as linhas que foram alteradas desde o último
preenchimento.
âV !  processa quaisquer alterações desde a última actualização do índice.
Requer que a opção CHANGE_TRACKING esteja habilitada para o índice e definida
como MANUAL.

Para iniciar o preenchimento de um índice de texto completo, executa-se a instrução ALTER


FULLTEXT INDEX.

V
 uV
Full Text Index responde de maneira espectacular nas consultas complicadas e é
suficientemente versátil para trabalhar em máquinas não tão potentes. A única precaução a
temer é quando dispomos de grande quantidade de registos. Deverá dispor de um tempo
inicial alto e talvez deva pensar em particionar suas tabelas horizontalmente para obter
excelentes resultados

wV Pode-se ter vários (na verdade, até 250) índices por tabela no SQL Server, porém só
pode ter apenas um Full-Text Index por tabela.
wV Existe apenas uma entrada para cada índice com sua respectiva linha de dados, no
Full-Text Index pode haver muitas entradas para cada linha, porque cada linha é
quebrada em palavras separadas.
wV Os índices no SQL Server são mantidos individualmente, enquanto que os Full-Text
Indexes são agrupadas em catálogos para facilitar de manutenção.

V V
(
  V
wV WALTERS, Robert E. et all. ccelerated SQK Server 2008, Apress, 2008
wV DAVIDSON, Louis, KLINE, Kevin. Pro SQK Server 2008 Relational atabase
esign and Implementation, Apress, 2008.
wV HOTEK, Mike, `icroso2t SQK Server 2008 ± Implementation and `aintenance,

You might also like