작성자: Margaret Li(Program Manager/데이터 액세스 그룹) 및 Frank Pellow(Program Manager/SQL Server 관계형 엔진) 요약
Microsoft?? SQL Server™ 7.0에는 파일 시스템의 데이터에 대한 텍스트 기반 쿼리는 물론 SQL Server 자체의 데이터에 대한 텍스트 기반 쿼리를 지원하는 기능이 있습니다.
이 문서에서는 이들 기능 가운데 SQL Server 테이블의 데이터에 대한 텍스트 기반 쿼리를 지원하는 기능에 대해 설명합니다. 먼저 전체 텍스트 검색의 개념에 대해 소개한 다음 전체 텍스트 검색 쿼리에 사용되는 형식 및 이런 쿼리를 통해 검색할 수 있는 정보 유형에 대해 소개합니다. 그리고 전체 텍스트 검색 시스템의 내부 설계 및 아키텍처의 기술적인 부분에 대해 깊이 있게 설명하고 SQL Server 엔터프라이즈 관리자를 통해 사용할 수 있는 저장 프로시저 및 그래픽 사용자 인터페이스를 통해 이 시스템을 관리하는 방법을 설명합니다.
이 문서는 SQL Server 7.0의 전체 텍스트 지원 기능에 대한 개요를 제공하고 이 기능을 제공하기 위해 다양한 하위 구성 요소들이 어떻게 상호 작용하는지 이해할 수 있도록 돕는 데 목적이 있습니다.
이 문서에서는 파일 시스템의 데이터에 대한 텍스트 기반 쿼리 지원에 대해 다루지 않습니다. 소개
현재, 디지털로 저장된 정보의 아주 많은 부분이 여전히 구조화되지 않은 데이터, 주로 텍스트의 형태로 존재하고 있습니다. 이런 텍스트 데이터의 대부분이 파일 시스템에 저장되어 있으며, 일부 회사들은 관계형 데이터베이스의 VARCHAR 및 TEXT 같은 문자 기반 열에 이들을 저장하여 관리하기 시작했습니다. 이는 이제 관계형 데이터베이스 사용자들에게 데이터베이스 자체의 텍스트 데이터를 효과적으로 검색하기 위한 메커니즘이 필요하다는 뜻입니다. Microsoft SQL Server 6.5 같은 전통적인 RDBMS는 전체 텍스트를 효과적으로 검색할 수 있도록 설계되지 않았습니다. 예를 들어, 패턴 일치를 기반으로 하는 몇몇 텍스트 검색 기능이 있긴 하지만 SQL Server 6.5는 서로 근접해 있는 단어나 구를 조회하는 근접 검색은 다루지 않습니다.
텍스트 기반 쿼리에는 크게 아래와 같은 두 가지 유형이 있습니다. 속성 검색 작성자, 주제, 종류, 단어 개수, 인쇄된 페이지 수 같은 속성을 추출하기 위해 문서에 필터를 적용합니다. 전체 텍스트 검색 문서에 나오는 모든 비노이즈 단어의 인덱스를 만든 다음 그 인덱스를 사용하여 언어 검색 및 근접 검색을 지원합니다.
텍스트 기반 쿼리를 관계형 데이터베이스에 통합하는 기능이 없어 고객들은 다른 공급 업체 제품을 사용하여 이러한 요구 사항을 해결해야 했습니다. 이러한 솔루션은 보통 브리지 또는 게이트웨이를 통해 데이터베이스에서 데이터를 얻고 전체 텍스트 인덱싱이 적용될 수 있도록 파일 시스템에 그 데이터를 파일로 저장합니다. 이는 사용자들에게 전체 텍스트 쿼리를 일반적인 구조적 관계형 쿼리와 원활하게 결합할 수 있는 방법을 제공하지 않습니다.
이제 일부 관계형 데이터베이스 제품은 동일한 쿼리에 관계형 검색 조건과 전체 텍스트 검색 조건을 원활하게 통합하여 지정하는 기능을 제공합니다. 이러한 쿼리를 어떻게 지정하는지 아래에서 확인할 수 있습니다. 일반 텍스트 문서 집합의 내용이 'doc_collection' 테이블의 DocText 열에 존재하고 이 테이블에 StorName, Size 및 DocAuthor 열도 있다고 가정하면 아래와 같은 쿼리를 실행할 수 있습니다.
SELECT Q.StorName, Q.Size, Q.DocAuthor, W.Citizenship FROM doc_collection as Q, writers as W WHERE CONTAINS(DocText, ' "SQL Server" NEAR() text') AND Q.DocAuthor = W.writer_name
이 문은 아래 정보를 얻기 위한 것입니다. "text"와 근접해 있는 "SQL Server"라는 구가 포함된 모든 문서의 이름, 크기 및 작성자 그리고 이는 작성자의 시민권 정보를 얻기 위해 'writers' 테이블과 조인됩니다.
지난 6개월 동안 Microsoft는 이러한 쿼리를 가능하게 할 프로젝트를 추진했습니다. 이 프로젝트의 목적은 사용자들이 관계형 데이터베이스 테이블의 일반 텍스트 데이터에 대해 초보적인 전체 텍스트 쿼리를 수행할 수 있도록 SQL Server 7.0 베타 3에 Microsoft의 텍스트 검색 기술을 적용하는 것입니다. 구문은 SQL 언어에 대한 자연 확장이 될 것입니다.
Microsoft는 SQL Server 데이터에 대해 전체 텍스트 검색을 수행할 수 있도록 Microsoft의 기존 기술들을 활용했습니다. Microsoft의 정보 검색 기술은 개발된 지 어느 정도 지났으며 이미 Index Server 2.0과 Site Server 3.0에 적용되었습니다. Microsoft는 Microsoft의 관계형 데이터베이스 고객들에게 전체 텍스트 검색 지원을 제공하기 위해 다양한 구성 요소를 이들 기술에 포함하고 SQL Server 7.0과 통합했습니다. 통합할 수 있었던 SQL Server 이외의 기술은 아래의 두 가지입니다. Microsoft 검색 서비스1 - 이 문서 전반에 걸쳐 "인덱스 엔진"과 "검색 엔진"이라는 두 용어로 사용되는 전체 텍스트 인덱싱 및 검색 서비스입니다. Index Server 2.0용 OLE DB 공급자의 파서 구성 요소 - 전체 텍스트 SQL 확장을 받아들여 이들을 검색 엔진이 처리할 수 있는 형태로 매핑합니다.
이 문서의 목적은 아래 세 가지입니다. 데이터베이스 데이터에 대한 전체 텍스트 검색을 지원하는 SQL 언어 확장에 대해 소개합니다. 데이터베이스 데이터에 대한 전체 텍스트 검색이 가능하도록 다양한 기술을 어떻게 결합했는지에 대해 설명합니다. 데이터베이스 데이터에 대한 전체 텍스트 검색을 지원하는 SQL Server의 새 관리 기능에 대해 소개합니다. 전체 텍스트 검색의 개념
특정 데이터베이스에 있는 일반 텍스트 데이터에 대한 전체 텍스트 검색 지원에는 크게 봐서 아래와 같은 네 가지 측면이 있습니다. 전체 텍스트 검색에 등록된 테이블 및 열의 정의를 관리합니다. 등록된 열의 데이터를 인덱싱합니다. 인덱싱 프로세스는 문자 스트림 전체를 스캔하고, 단어 경계를 구분하고(단어 구분이라고 함), 모든 노이즈 단어2를 제거한 다음 나머지 단어들로 전체 텍스트 인덱스를 채웁니다. 채워진 전체 텍스트 인덱스에 등록된 열에 대해 쿼리를 실행합니다. 등록된 열의 데이터가 변경되면 인덱스 엔진에 그 변경 사항을 전파하여 전체 텍스트 인덱스가 동기화되도록 합니다.
위에 나온 인덱싱, 쿼리 및 동기화 프로세스에 대한 설계 요구 사항의 기본 원칙은 전체 텍스트 검색에 등록된 모든 테이블에 전체 텍스트 고유 키 열 또는 단일 열 기본 키가 존재해야 한다는 것입니다. 전체 텍스트 인덱스에는 각 행에 대한 키 열 값과 함께 각 행에 있는 비노이즈 단어에 대한 항목이 포함됩니다.
전체 텍스트 쿼리를 처리할 때 검색 엔진은 검색 기준과 일치하는 행의 키 값들을 SQL Server에 반환합니다. 간단한 예를 살펴보면 프로세스의 내용을 쉽게 이해할 수 있습니다. 아래와 같은 열들이 있는 SciFi 테이블이 있다고 가정합니다. 기본 키 열은 Book_No 열입니다. Book_NoWriterTitleA025AsimovFoundation's EdgeA027AsimovFoundation and EmpireC011ClarkeChildhood's EndV109VerneMysterious Island
그리고 "Foundation"이라는 단어가 포함된 책 제목을 찾기 위해 전체 텍스트 검색 쿼리를 사용한다고 가정합니다. SQL Server 관계형 엔진이 전체 텍스트 검색 조건자를 발견하면 전체 텍스트 검색 구성 요소를 호출하여 텍스트 검색 필터 조건을 만족하는 Book_No의 값들을 검색합니다. 이 경우 A025 및 A027 값이 반환됩니다. 그런 다음 관계형 엔진은 이 정보를 자신이 직접 제어하는 다른 정보와 함께 사용하여 쿼리에 응답합니다.
"전통적인" 관계형 데이터베이스 인덱스와는 달리, 전체 텍스트 인덱스는 일반적으로 전체 텍스트 등록 열의 값이 업데이트될 때 또는 전체 텍스트 등록 테이블에 행이 추가되거나 삭제될 때 즉시 수정되지 않습니다. 대신, 전체 텍스트 인덱스는 보통 비동기 방식으로 다시 채워집니다. 그 이유는 다음 두 가지 때문입니다. 일반적으로 전통적 인덱스보다 전체 텍스트 인덱스를 업데이트하는 데 훨씬 많은 시간이 소요됩니다. 일반적으로 전체 텍스트 검색은 본래 퍼지 방식이므로 전통적 검색만큼 정밀하지 않아도 됩니다.
다시 채우기 프로세스가 진행될 때, 다시 인덱싱해야 하는 항목들을 확인하기 위해 고유 키 열 값들이 인덱스 엔진에 전달됩니다. 예를 들어, V109에 연결된 제목이 'Mystery Island'로 변경된 경우 이 새 값을 반영하기 위해 인덱스가 수정되어야 합니다.
전체 텍스트 관리 프로세스는 전체 텍스트 검색에 관련된 테이블 및 테이블의 열을 지정하는 것으로 시작합니다. 테이블과 열을 전체 텍스트 검색에 사용될 수 있도록 등록하기 위해 먼저 그래픽 사용자 인터페이스(GUI)와 마법사 또는 기본 제공 저장 프로시저가 사용됩니다. 그런 다음 전체 텍스트 인덱스를 채우기 위해 다시 GUI 또는 저장 프로시저를 통해 별도의 요청이 발급됩니다.
최종적으로는, 기본 바탕이 되는 인덱스 엔진이 실행되어 비동기 인덱스 채우기가 시작됩니다. 전체 텍스트 인덱싱은 어떤 중요한 단어가 사용되며 그 위치는 어디인지 추적하는 작업입니다. 예를 들어, 전체 텍스트 인덱스는 6이라는 'ProductID'를 가진 행에 대한 'DevTools' 테이블의 'Abstract' 열에 있는 단어 번호 423 및 982에 'Microsoft'라는 단어가 있다고 나타낼 수 있습니다. 이 인덱스 구조는 인덱스된 단어가 포함된 모든 항목에 대한 효과적인 검색 그리고 구 검색 및 근접 검색 같은 고급 검색 작업을 지원합니다. 구 검색의 예로는 white elephant를 찾는 것을 들 수 있습니다. 이 검색은 white 뒤에 elephant가 나오는 곳을 찾는 것입니다. 그리고 house 근처에 big이 나오는 곳을 찾는 것이 근접 검색입니다. 전체 텍스트 인덱스가 검색에 도움이 되지 않는 단어들 때문에 커지지 않도록 a, and, the 같은 노이즈 단어는 무시됩니다. 많은 언어에 대한 노이즈 단어 목록이 제공되며 지원되는 언어 집합이 계속 늘고 있습니다. 어떤 노이즈 단어 목록을 선택하느냐는 데이터베이스 서버의 언어 설정에 따라 달라집니다. 이러한 노이즈 단어 목록은 대부분의 일반적인 작업에는 충분하지만 특정 환경에 맞게 수정할 수 있습니다. 노이즈 단어 목록은 게시된 경로에 제공되며 관리자는 일반 텍스트 편집기를 사용하여 이러한 목록의 내용을 수정할 수 있습니다. 예를 들어, 첨단 컴퓨터 회사의 경우 'computer'라는 단어를 노이즈 단어 목록에 추가할 수 있을 것입니다.
Microsoft는 사용자들이 전체 텍스트 쿼리를 만들 수 있도록 Microsoft의 Transact-SQL 확장을 만들어야 했습니다. 그리고 Index Server 2.0용 Microsoft OLE DB 공급자 및 Site Server 3.0용 Microsoft OLE DB 공급자의 전체 텍스트 검색에 이미 지원되는 CONTAINS 및 FREETEXT 조건자 구문을 사용하여 이 문제를 해결할 수 있었습니다.
CONTAINS 조건자는 아래 항목을 검색하는 데 사용됩니다. 단어 또는 구 단어 또는 구의 접두사 다른 단어 또는 구에 인접한 단어 또는 구 다른 단어의 변화형(예: drive는 drives, drove, driving, driven의 기본형임) 할당된 가중치가 각기 다른 단어 또는 구 집합
FREETEXT 조건자는 단순한 형태의 자연어 쿼리입니다. 단어, 구 또는 문장을 포함한 모든 텍스트를 쿼리에 지정할 수 있습니다. 검색 엔진은 쿼리에 포함된 단어 자체가 아니라 그 의미를 반영하는 값을 찾습니다.
SQL Server 관계형 엔진은 CONTAINS 및 FREETEXT 조건자를 인식하고 조건자가 참조하는 열이 전체 텍스트 검색에 등록되어 있는지 확인하는 등 최소한의 구문 검사 및 의미 검사를 몇 가지 수행합니다. 쿼리 실행 중 전체 텍스트 조건자 및 다른 관련 정보가 전체 텍스트 쿼리 구성 요소에 전달됩니다. 좀더 상세한 구문 및 의미 확인이 이뤄진 후 검색 엔진이 호출되며 이 엔진이 전체 텍스트 검색 조건을 만족하는 테이블의 행들을 식별하는 고유 키 값 집합을 반환합니다.
현재 관리자들이 전체 텍스트 인덱스를 그 테이블 내의 데이터 변경 사항과 동기화하기 위해 사용할 수 있는 메커니즘은 아래 두 가지입니다. 언제든지 다시 채우기를 요청할 수 있습니다. 규칙적으로 다시 채우기가 수행되도록 설정할 수 있습니다.
이러한 작업에 GUI와 저장 프로시저 모두를 사용할 수 있습니다. 테이블에 TIMESTAMP 데이터 형식의 열이 있는 경우 증분 다시 채우기를 요청할 수 있습니다. 증분 다시 채우기란 마지막 다시 채우기 이후의 테이블 변경 사항만 다시 채우기에 참여하는 것을 말합니다. 테이블에 TIMESTAMP 형식의 열이 없는 경우 전체 다시 채우기만 가능합니다.
로그 활동을 기반으로 전체 텍스트 인덱스를 자동으로 업데이트하는 대신 사용할 수 있는 방법은 이후의 릴리스에 제공될 것입니다. 전체 텍스트 쿼리를 위한 Transact-SQL 확장
먼저, 이러한 확장이 Index Server 2.0의 전체 텍스트 검색에 지원되는 SQL과 일관된다는 것을 상기할 필요가 있습니다. 또한 전체 텍스트 검색을 위한 SQL 지원은 전체 텍스트 구문 확장을 위한 ISO SQL-3 기능적 방법론을 따릅니다.
Transact-SQL에 대한 기본 확장은 새로운 CONTAINS 및 FREETEXT 조건자로 구성됩니다. 이 조건자들은 특별한 전체 텍스트 쿼리 조건과 일치하는 열 값을 찾는 데 사용됩니다.
또한 새로운 ContainsTable() 및 FreetextTable() 행 집합 반환 함수가 지원됩니다. 두 개의 열이 있는 테이블을 반환하도록 FROM 절에 이 함수들을 지정할 수 있습니다. 이때 한 열은 지정된 전체 텍스트 쿼리 조건과 일치하는 행을 고유하게 식별하고 나머지 한 열은 행이 조건과 일치하는 정도를 나타내는 순위 값을 가집니다.
먼저 새 조건자들에 대해 살펴보겠습니다. 다른 제품들에 제공되는 비슷한 기능과의 일관성을 유지하기 위해 그리고 이러한 조건자를 더 폭넓게 확장할 수 있도록 Microsoft는 기능적 표시법을 사용하기로 결정했습니다. 상위 수준 구문은 아래와 같습니다.
·--CONTAINS--(열_참조--,전체 텍스트_검색_조건)--· +FREETEXT+
SQL Server 7.0에서 언어는 항상 해당 데이터가 포함된 데이터베이스의 로케일에 의해 결정됩니다. 이 두 조건자의 동작 스타일이 유연하기 때문에, 앞으로 제3의 매개 변수가 쿼리에 사용될 언어를 지정할 수 있도록 상위 기종과 호환되는 손쉬운 확장이 허용됩니다.
이 조건자들을 "문자 패밀리" 데이터 형식과 함께 사용할 수 있습니다. "문자 패밀리"란 CHAR, VARCHAR, TEXT, NCHAR, NVARCHAR 및 NTEXT를 말합니다. 현재, 보통 "이진 패밀리" 데이터 형식으로 정의된 열에 저장된 문서 형식은 인덱싱이나 쿼리가 불가능합니다. 이런 지원은 SQL Server 7.0 이후에 제공될 것입니다. CONTAINS 조건자
이 조건자는 전체 텍스트 등록 열의 값에 특정 단어 및 구가 포함되어 있는지 여부를 확인하는 데 사용됩니다. 현재 이런 조건자들은 기본 테이블만 참조할 수 있습니다.
구문은 아래와 같습니다.
·--CONTAINS--(---열_참조------------------------<; +-*----------+ <;--,--'--포함_조건--'--)-----------------· 포함_조건: ·--------단순어-------------------------------<; _ +--접두어------¦ ¦_ +--근접어---¦ ¦_ +--파생어--¦ ¦_ +--가중치어----+ ¦_ _ +--(--포함_조건--)--+ +----------------------------------------------+ v ¦<;--------------------------------------------------_ +----OR--------------단순어-------------+ +-AND-----¦ ¦+--접두어------¦ ¦+-AND NOT-+ ¦+--근접어---¦ ¦_ +--파생어--¦ ¦_ +--가중치어----+ ¦_ _ +-(-- 포함_조건-)-+
여기서 각 인수의 의미는 아래와 같습니다. 열_참조 또는 *검색할 열을 식별합니다. 열_참조전체 텍스트가 등록된 특정 열을 나타냅니다. * 전체 텍스트가 등록된 테이블의 모든 열을 나타냅니다.
단순어, 접두어, 근접어, 파생어 및 가중치어에 대해서는 밑에서 설명합니다.
AND, OR 및 NOT은 보통 사용되는 것처럼 사용됩니다. 아래를 참조하십시오.
단순어:
이는 검색되는 단어 또는 구와 정확하게 일치하는 값을 찾는 데 사용됩니다.
구문은 아래와 같습니다.
·----단어-------------------------------· _ _ +-"--구--"--+
여기서 각 인수의 의미는 아래와 같습니다.
단어 공백 또는 문장 부호가 없는 하나 이상의 문자를 나타냅니다.
구 단어 사이에 공백이 있는 여러 단어를 나타냅니다.
전체 텍스트 제품에 대한 표준을 따르기 위해 단어 또는 구에 포함된 문자를 검색할 때 항상 대/소문자가 구별됩니다.
WHERE 절의 CONTAINS 조건자 컨텍스트에 사용되는 단순어의 예를 들면 아래와 같습니다.
WHERE CONTAINS( context_col, 'hockey' ) WHERE CONTAINS( context_col, ' "ice hockey" ')
context_col 값이 각각 "This is a dissertation on the use of frozen meadow muffins as hockey pucks"와 "Dissertation on new ways of splitting the atom"인 행이 있다고 가정합니다. "this", "is", "a" 등은 모두 노이즈 단어이므로 전체 텍스트 인덱스에 저장되지 않습니다. 따라서 CONTAINS 조건자를 사용한 아래 쿼리는 그 아래 쿼리와 같습니다.
CONTAINS (context_col, '"this is a dissertation"')
CONTAINS (b_column, 'dissertation')
그리고 두 행 모두 일치하는 값으로 반환됩니다. 이는 첫째 쿼리를 처리하기 전에 쿼리에서 노이즈 단어인 "this", "is" 및 "a"가 제거되기 때문입니다. 용어 조합
다른 SQL 검색 조건과 마찬가지로, 개별적인 피연산자를 부울 연산자와 연결하여 더 복잡한 조건을 지정할 수 있습니다. 이 경우 지금 다루고 있는 모든 용어 유형이 피연산자가 될 수 있습니다. OR NOT 조합이 지원되지 않는다는 것과 첫째 용어 앞에 NOT을 지정할 수 없다는 점을 제외하면, 규칙은 개별 조건자를 조합하여 검색 조건을 만들 때 적용되는 규칙과 똑같습니다. 예를 들어, 연산자가 적용되는 기본 우선 순위를 변경하기 위해 괄호를 사용할 수 있습니다.
WHERE 절의 CONTAINS 조건자 안에 조합되는 단순어의 예를 들면 아래와 같습니다.
WHERE CONTAINS( context_col, 'hockey OR curling' ) WHERE CONTAINS( context_col, 'hockey AND NOT field') WHERE CONTAINS( context_col, ' ("ice hockey" OR curling) AND NOT Canada ' )
접두어:
이는 지정된 텍스트로 시작하는 단어 또는 구와 일치하는 값을 찾는 데 사용됩니다.
구문은 아래와 같습니다.
·----"--단어--*--"------------------------· _ _ +-"--구--*--"--+
접두어는 접두사가 일치하는 단어나 구를 검색하기 위해 뒤에 별표를 붙인 단순어로 이루어집니다. 별표(*) 앞에 나오는 문자로 시작되는 모든 텍스트가 일치하는 값으로 검색됩니다. 여기서 * 와일드카드 기호는 단어나 구에 포함된 루트 단어의 문자 중 0개, 1개 또는 그 이상의 문자를 일치시킨다는 점에서 LIKE 조건자의 % 기호와 약간 비슷합니다. 구의 경우 구에 포함된 각 단어가 접두사로 간주됩니다. 예를 들어, "local bus *" 용어와 일치하는 값은 "locality busy", "local bush" 및 "locale bust"가 될 수 있습니다.
WHERE 절의 CONTAINS 조건자 컨텍스트에 사용되는 접두어의 예를 들면 아래와 같습니다.
WHERE CONTAINS( context_col, ' "atom*" ' ) 'atom', 'atomic', 'atomism', 'atomy' 등의 단어가 포함된 context_col 값을 일치하는 값으로 검색합니다.
WHERE CONTAINS( abstract, ' "wine*" OR "vine*" ') 이 쿼리는 'wine'이나 'vine' 또는 'winery', 'wines', 'vineyard', 'vinegar' 같은 단어가 포함된 추상 값을 일치하는 값으로 검색합니다.
근접어:
이는 검색되는 단어나 구가 다른 단어나 구와 근접해 있어야 할 때 사용됩니다.
구문은 아래와 같습니다.
+----------------------------+ v ¦·---단순어_1------NEAR()----단순어_n-----· _ _ + ~ -----+_ _ +-접두어_1-+ +-접두어_n-+
검색되는 열에 둘 이상의 단어 또는 구가 있어야 한다는 점에서 근접어는 AND 연산자와 비슷합니다. 단어들이 서로 "더 가까이" 있을수록 일치 정도가 높아진다는 점에서는 AND와 다릅니다.
구문은 이후에 단어, 문장, 단락, 장 등의 근접 단위 규정을 지원하기 위해 확장할 수 있도록 되어 있습니다.
NEAR()와 ~는 같은 뜻입니다. 즉, 연산자의 왼쪽에 있는 단어 또는 구가 나머지 단어 또는 구와 "근접해" 있다는 뜻입니다. "근접"의 의미는 분명하지 않으며 이는 의도적인 것입니다. 서로 대략 50단어 이내에 존재하는 것을 근접한 상태로 생각할 수 있지만 그 알고리즘은 이보다 더 복잡합니다. 같은 문장 안의 단어들은 서로 한 단어씩 떨어져 있지만 문장, 단락 및 장 같은 단위 사이에는 이보다 큰 간격이 지정됩니다. 단어 또는 구가 아주 멀리 떨어져 있더라도 쿼리는 여전히 유효한 것으로 간주됩니다. 단지 행의 순위 값이 매우 낮을(0) 뿐입니다. 그러나 contains_condition이 오로지 NEAR() 근접 용어로만 이루어진 경우 SQL Server는 순위 값이 0인 행을 반환하지 않습니다.
아래 예제처럼 근접 일치를 연쇄적으로 연결할 수 있습니다.
a ~ b ~ c
이는 a는 b에 근접하고 b는 c에 근접해야 한다는 뜻입니다.
전체 텍스트 검색의 퍼지 특성 때문에 보통 위에서 설명한 순위 값을 살펴보는 것이 바람직합니다. ContainsTable() 행 집합 반환 함수를 사용하면 각 행의 순위 값을 반환하는 쿼리를 실행할 수 있습니다. 이 함수에 대해서는 뒤에서 설명합니다.
WHERE 절의 CONTAINS 조건자 컨텍스트에 사용되는 근접어의 예를 들면 아래와 같습니다.
WHERE CONTAINS( context_col, ' hockey ~ player ' ) 이 쿼리는 'player'라는 단어와 근접해 있는 'hockey'가 포함된 context_col 값을 일치하는 값으로 검색합니다.
WHERE CONTAINS( context_col, ' hockey ~ "play*" ') 이 쿼리는 'play'로 시작하는 단어와 근접해 있는 'hockey'가 포함된 context_col 값을 일치하는 값으로 검색합니다.
WHERE CONTAINS( context_col, ' "great*" ~ "Maurice Richard" ') 이 쿼리는 "Maurice Richard" 구와 근접해 있는 'great'로 시작하는 단어가 포함된 context_col 값을 일치하는 값으로 검색합니다.
파생어:
원래 단어의 변형을 포함하도록 검색되는 단어를 확장해야 할 때 언어 생성이 사용됩니다.
구문은 아래와 같습니다.
+--------------+ v ¦·--FORMSOF--(--INFLECTIONAL---,단순어---)--·
INFLECTIONAL은 명사의 단/복수형 또는 동사의 다양한 시제가 일치되는 값으로 검색된다는 뜻입니다. 한 용어가 단독 명사 및 단독 동사 형태 모두와 일치하지는 않을 것입니다. 다시 한번 강조하지만, 파생어, 사운덱스 및 동의어 같은 다른 언어 형태를 충분히 다룰 수 있도록 구문을 확장할 수 있습니다.
WHERE 절의 CONTAINS 조건자 컨텍스트에 사용되는 파생어의 예를 들면 아래와 같습니다.
WHERE CONTAINS(curriculum_vite, ' FORMSOF (INFLECTIONAL, skate) ' ) 이 쿼리는 'skate', 'skates', 'skated' 및 'skating' 같은 단어가 포함된 curriculum_vite 값을 일치하는 값으로 검색합니다.
가중치어:
이는 각각 선택적인 가중치가 부여된 단어 및 구 목록과 일치하는 행을 반환하는 쿼리에 사용됩니다. 목록의 한 요소와 일치하기만 하면 일치하는 값으로 간주됩니다.
구문은 아래와 같습니다.
·--ISABOUT-----------------------------------------<; +--,--------------------------------------+ v ¦<;--(----단순어------------------------------)-· +-접두어-----¦ +-WEIGHT-(-n.nnn-)-+ +-근접어--¦+-파생어-+
여기서 각 인수의 의미는 아래와 같습니다.
n.nnn은 0과 1 사이의 십진 상수를 나타냅니다.
ISABOUT 요소들 중 어느 하나와 일치하면 행이 반환됩니다.
백터의 각 구성 요소에 가중치를 선택적으로 할당할 수 있습니다. 가중치가 할당되면 쿼리와 일치하는 각 행에 할당되는 순위 값이 서로 다르게 측정됩니다.
WHERE 절의 CONTAINS 조건자 컨텍스트에 사용되는 가중치어의 예를 들면 아래와 같습니다.
WHERE CONTAINS( article, ' ISABOUT(hockey, puck, goalie) ' ) 이 쿼리는 'hockey', 'puck' 또는 'goalie'라는 단어 중 어느 하나라도 포함된 아티클 값을 일치하는 값으로 검색하며 더 일치하는 값은 두 개 이상의 단어가 포함된 아티클 값입니다.
WHERE CONTAINS( article, 'ISABOUT("Toronto Maple Leafs" WEIGHT(1.0), "Maple Leafs" WEIGHT(.5), Leafs WEIGHT(.2) ) ' ) 이 쿼리는 아티클이 구에 포함된 단어를 많이 가진 경우 아티클에 할당된 순위 값이 더 높은, Toronto Maple Leafs 하키 팀에 대한 정보를 가진 아티클 값을 일치하는 값으로 검색합니다. FREETEXT 조건자
FREETEXT는 전체 텍스트 등록 열의 값들이 조건자에 지정된 단어와 정확하게 일치하기보다 그 의미를 반영해야 하는지 여부를 결정하는 데 사용됩니다.
구문은 아래와 같습니다.
·--FREETEXT--(---열_참조------------------------<; +-*----------+ <;--,--'--자유 텍스트_문자열--'--)---------------------·
이는 지극히 단순한 형태의 자연어 쿼리입니다. 이 쿼리에서는 인덱스 엔진이 내부적으로 자유 텍스트_문자열을 여러 개의 검색 용어로 "구분하고" 단어의 어간을 만든 다음 각 용어에 약간의 발견적 가중치를 할당하고 일치하는 값을 찾습니다.
WHERE 절에 사용되는 FREETEXT 조건자의 예를 들면 아래와 같습니다.
WHERE FREETEXT(articles, ' Who have been the most valuable players for the Montreal Canadien? ' )
조건자 조합 및 조건자 사용:
CONTAINS와 FREETEXT는 SQL 조건자이기 때문에 SQL 조건자가 지원되는 모든 곳, 즉 모든 검색 조건에 이들을 사용할 수 있습니다. 특히, 폭넓은 검색 조건을 지정하기 위해 이 조건자들을 서로 조합하여 사용하거나 동등, LIKE, BETWEEN 같은 다른 조건자들과 조합하여 사용할 수 있습니다.
아래 쿼리의 WHERE 절에는 CONTAINS 조건자와 비교 조건자 모두가 사용됩니다. 이 쿼리는 'pubs' 데이터베이스의 'titles' 테이블에서 책값이 20달러 미만이고 'notes' 열에 그 책이 아이스하키에 관한 책이라는 것이 나타나 있는 모든 책의 제목과 출판 연도를 구합니다.
SELECT title, DatePart(year, pubdate) FROM pubs WHERE price >; 20.00 AND CONTAINS (notes, ' "ice hockey" ')
아래 쿼리는 하위 쿼리에서 CONTAINS를 사용합니다. 이 쿼리는 'titles' 테이블에서 Ontario Moonbeam의 UFO 근처에 위치한 출판사의 모든 책 제목을 구합니다. 출판사에 관한 이 정보는 'pub_info' 테이블의 'pr_info' 열에 있는 것으로 나타나며 이런 출판사는 하나뿐이라는 것도 나타납니다.
SELECT T.title, P.pub_name FROM publishers P, Titles T WHERE P.pub_id = T.pub_id AND P.pub_id = (SELECT pub_id FROM pub_info WHERE CONTAINS (pr_info, ' moonbeam AND ontario AND "flying saucer" ') )
ContainsTable() 행 집합 반환 함수:
ContainsTable() 함수는 각 행의 관련성 순위를 반환하는 "contains" 형식의 전체 텍스트 쿼리를 실행하는 데 사용됩니다.
구문은 아래와 같습니다.
·--CONTAINSTABLE--(--테이블_참조---,---열_참조------<; +-*----------+ <;--,--'--포함_조건--'--)-----------------·
여기서 각 인수의 의미는 아래와 같습니다.
테이블_참조 전체 텍스트 등록 테이블을 나타냅니다.
열_참조 전체 텍스트가 등록된 특정 열을 나타냅니다.
또는
* 전체 텍스트가 등록된 테이블_참조 테이블의 모든 열을 나타냅니다.
포함_조건 CONTAINS 조건자에서 설명한 것과 같습니다.
CONTAINS 조건자와 ContainsTable() 함수 모두 "contains" 형식의 전체 텍스트 쿼리에 사용되고 둘 모두 같은 SQL을 사용하여 전체 텍스트 검색 조건을 지정하지만, 이들의 사용 방식에는 아래와 같은 주된 차이점이 있습니다. CONTAINS()는 참/거짓 값을 반환하기 때문에 일반적으로 SELECT 문의 WHERE 절에 지정합니다.
ContainTable()은 0, 1 또는 그 이상의 행을 가진 테이블을 반환하기 때문에 항상 FROM 절에 지정해야 합니다.
CONTAINS()는 오로지 SQL Server가 결과 집합의 구성원 자격을 결정하기 위해 사용하는 선택 조건을 지정하는 데만 사용할 수 있습니다.ContainsTable() 역시 선택 조건을 지정하는 데 사용됩니다. 반환되는 테이블은 "전체 텍스트 키" 값이 포함된 KEY라는 열을 가집니다. 전체 텍스트가 등록된 각 테이블은 값의 고유성이 보장되는 열을 가지며 KEY 열에 반환되는 값들은 포함_조건에 지정된 선택 조건과 일치하는 행들의 "전체 텍스트 키" 값입니다. 또한, ContainsTable() 함수에 의해 만들어지는 테이블은 RANK라는 열을 가집니다. 이 열에는 선택 조건과의 일치 정도에 따라 반환되는 행들의 순위를 지정하는 데 사용할 수 있는 0에서 1000 사이의 값이 포함됩니다.
ContainsTable() 함수를 사용하는 쿼리는 CONTAINS 조건자를 사용하는 함수보다 복잡합니다. ContainsTable() 함수에 의해 반환될 수 있는 적절한 행들을 테이블_참조의 행들과 명시적으로 조인해야 하기 때문입니다. 이런 쿼리를 어떻게 작성할 수 있는지 설명하기 위해 "소개"에 나온 예제를 좀더 확장해 보겠습니다. 이 예제에서, 일부 문서의 내용이 'doc_collection'이라는 테이블의 DocText 열에 있으며 StorName, Size 및 DocAuthor 열도 이 테이블에 있습니다. 테이블의 고유 키 열은 DocNo입니다. 여기서는 높은 RANK 값을 가진 행들이 먼저 반환되도록 결과 집합의 행들을 정렬하려 합니다. 앞에 나온 예제의 확장은 굵게 표시되어 있습니다.
SELECT Q.StorName, Q.Size, Q.DocAuthor, W.Citizenship FROM doc_collection as Q, writers as W, ContainsTable(doc_collection, DocText, ' "SQL Server" NEAR() text' ) AS K WHERE Q.DocAuthor = W.writer_name AND K.[KEY] = Q.DocNo ORDER BY K.RANK DESC
테이블 하나만 관계되고 그룹은 관계되지 않는 쿼리에 ContainsTable() 함수를 간편하게 사용하려면 아래와 같은 고정 템플릿을 사용할 수 있습니다.
아래 예제는 위의 템플릿을 사용한 것입니다. 이 예제에서, 하키 선수들을 기리는 영예의 전당 명판에 새겨진 말들이 HockeyHall이라는 테이블의 PlaqueWording 열에 있으며 PlayerName, StartYear 및 LastYear 열도 이 테이블에 있습니다. 테이블의 고유 키 열은 PlaqueNo입니다. 여기서는 1900년대 초에 Kenora 팀에서 활약한 선수들의 PlayerName, PlaqueNo 및 RANK 값을 반환하고자 합니다. 순위가 높은 행이 먼저 반환되어야 합니다.
FreetextTable() 행 집합 반환 함수:
각 열의 관련성 순위를 반환하는 "자유 텍스트" 형식의 전체 텍스트 쿼리를 실행하는 데 사용됩니다.
구문은 아래와 같습니다.
·--FREETEXTTABLE--(-테이블_참조---,---열_참조-----<; +-*----------+ <;--,--'--자유 텍스트_문자열--'--)---------------------·
이 함수는 ContainsTable() 함수와 같은 방식으로 사용하며 검색 조건은 FREETEXT 조건자에 의해 지정되는 조건과 같습니다. 파일 시스템의 데이터에 대한 텍스트 기반 쿼리
이 내용은 다른 백서에서 다루는 주제입니다.
그러나 두 가지 기능 모두 존재한다는 것을 알아야 하므로 이 문서에서도 이 주제에 대해 소개합니다.
또한 파일 시스템 데이터만 대상으로 한 검색 기능이 이미 Index Server 2.0에 제공되고 있다는 것도 알아둘 필요가 있습니다. 이 기능은 SQL Server 7.0 분산 쿼리 프로세서에 의해 더욱 강화되었습니다. 이 프로세서와 Index Server 2.0용 Microsoft OLE DB 공급자를 사용하면 파일 시스템의 데이터에 대한 속성 검색 및 전체 텍스트 검색을 수행하고 그 결과를 데이터베이스의 데이터와 조인할 수 있습니다. 이 주제에 대한 자세한 설명은 해당 백서에서 제공합니다.
지금 이 문서에서는 파일 시스템의 데이터를 가져오기 위해 이 문서의 첫째 예제를 다시 사용하여 어떻게 이런 쿼리를 지정할 수 있는지에 대해서만 소개합니다. 아래 쿼리는 D 드라이브의 Microsoft Word 파일 중 "text"와 근접해 있는 "SQL Server"라는 구를 포함하고 있는 문서의 이름, 크기 및 작성자를 선택합니다.
그리고 작성자의 시민권 정보를 얻기 위해 이를 'writers' 테이블과 조인합니다.
SELECT Q.FileName, Q.Size, Q.DocAuthor, W.Citizenship FROM OpenQuery(MyLinkedServer, 'SELECT FileName, Size, DocAuthor from SCOPE('' "D:\" '') WHERE CONTAINS(''"SQL Server" NEAR() text'') AND FileName LIKE ''%.doc%'' ' ) as Q, writers as W WHERE Q.DocAuthor = W.writer_name
이 쿼리를 통해, 쿼리를 작성하는 사람들에게 데이터의 위치가 제공되어야 한다는 것을 분명히 알 수 있습니다. ISO SQL 표준화 기구는 데이터베이스 내부와 외부의 데이터에 액세스하는 유연한 쿼리를 만들 수 있도록 새로운 DATALINK 데이터 형식을 정의하는 작업을 하고 있습니다. 이 정의는 몇 가지 흥미로운 가능성을 제시합니다. 전체 텍스트 인덱싱 구성 요소 아키텍처:
구성 요소 아키텍처에는 쿼리 구성 요소와 인덱싱 구성 요소라는 두 가지 측면이 있습니다. 쿼리 구성 요소에 대해서는 다음 절에서 설명합니다.
인덱싱 구성 요소는 전체 텍스트 인덱스의 처음 채우기 및 그 이후의 인덱스 업데이트를 관리합니다.
인덱싱 프로세스에 관련된 단계들을 설명하기 전에 먼저 다양한 하위 구성 요소들을 소개하겠습니다. 그 다음 이러한 하위 구성 요소 간의 흐름에 대해 설명하겠습니다.
SQL Server 엔터프라이즈 관리자 사용자 인터페이스: 전체 텍스트 인덱싱 관리 유틸리티용 GUI입니다. 이 인터페이스는 현재의 SQL Server 엔터프라이즈 관리자 속성 시트를 확장한 형태에 새 마법사를 추가한 모습을 하고 있습니다. 이들은 전체 텍스트 인덱스 테이블을 처음으로 사용하거나 자주 사용하지 않는 관리자를 지원하기 위해 설계되었습니다. 물론, GUI는 이러한 테이블을 자주 이용하는 사용자들에게도 적합합니다. GUI는 사용자들이 전체 텍스트 인덱싱에 사용할 테이블을 선택할 수 있도록 하며 이 프로세스가 끝날 때까지 사용자들에게 각 단계를 안내합니다.
GUI는 전체 텍스트 인덱스에 대해 규칙적인 새로 고침 일정을 설정할 수 있도록 옵션을 제공합니다. 이 옵션은 SQL Server에 이미 존재하는 일정 설정 기능을 사용합니다. 또한 GUI를 사용하여 전체 텍스트 인덱스 테이블의 속성을 표시할 수도 있습니다. 이 사용자 인터페이스는 새로운 전체 텍스트 관리 시스템 저장 프로시저 집합 그리고 이미 제공되고 있는 SQL Server Agent Job Scheduler는 물론 SQL Server의 "property" 함수를 통해 사용할 수 있는 전체 텍스트 관련 속성 집합을 이용합니다.
전체 텍스트 관리 시스템 저장 프로시저: 이 시스템 저장 프로시저 집합은 아래 작업을 수행하는 데 사용됩니다. 전체 텍스트 카탈로그를 만듭니다. 전체 텍스트 카탈로그는 전체 텍스트 인덱스 집합을 저장하는 엔티티일 뿐입니다. 테이블 및 테이블 안의 선택된 열을 전체 텍스트 검색에 등록합니다. 전체 텍스트 카탈로그에 인덱스를 채울 것을 요청합니다. 위의 작업 중 원하는 작업을 실행 취소합니다.
전체 텍스트 인덱스를 실제로 작성하고 구성하는 능력은 GUI가 아니라 이러한 저장 프로시저에 존재합니다. SQL Server 엔터프라이즈 관리자를 사용하지 않고 이러한 저장 프로시저를 직접 사용할 수 있습니다. 숙련된 관리자라면 아마 이렇게 할 것입니다. 또한 저장 프로시저 호출을 스크립트 및 다른 저장 프로시저에 포함할 수도 있습니다.
일정 설정 저장 프로시저: "규칙적인" 작업의 일정 설정에 사용하는 sp_add_jobschedule 같은 저장 프로시저 집합을 전체 텍스트 카탈로그의 새로 고침 일정을 설정하는 데도 사용할 수 있습니다. .
전체 텍스트 인덱싱 구성 요소 아키텍처
시스템 테이블에 전체 텍스트 인덱스 추가: DatabaseProperty() 함수를 통해 사용할 수 있는 새로운 IsFulltextEnabled 속성을 제공하도록 'sysdatabases' 시스템 카탈로그가 확장되었습니다.
새로운 시스템 테이블 'sysfulltextcatalogs'가 이제 각 데이터베이스에 제공됩니다. 이 테이블에는 이 데이터베이스에 연결된 전체 텍스트 카탈로그에 대한 메타데이터가 있습니다. 특정 전체 텍스트 카탈로그는 단 하나의 데이터베이스에만 연결된다는 데 유의하십시오.
각 데이터베이스에 존재하는 'sysobjects', 'sysindexes' 및 'syscolumns' 테이블은 해당하는 전체 텍스트 인덱스 데이터베이스의 테이블 및 관련 열에 대한 정보가 채워지면서 커질 것입니다. 아래와 같은 정보가 이런 정보에 해당합니다. 'sysobjects'에 있는 사용자 테이블 행들의 'ftcatid' 열('sysfulltextcatalogs'에 있는 행을 가리킴) ObjectProperty() 함수를 통해 사용할 수 있는 TableHasActiveFulltextIndex 속성 전체 텍스트 고유 키 열의 열 ID이자 ObjectProperty() 함수를 통해 사용할 수 있는 TableFulltextIKeyColumn 속성 테이블과 연결된 전체 텍스트 카탈로그 ID이자 ObjectProperty() 함수를 통해 사용할 수 있는 TableFulltextCatalogId 속성 IndexProperty() 함수를 통해 사용할 수 있는 IsFulltextKey 속성 ColumnProperty() 함수를 통해 사용할 수 있는 IsFulltextIndexed 속성
Microsoft 검색 서비스3: 이는 Microsoft Windows NT?? 서비스로서 아래와 같은 두 가지 역할을 합니다. 인덱싱 지원은 주어진 테이블의 전체 텍스트 인덱스를 채우기 위한 요청을 수락하는 작업을 처리합니다. 쿼리 지원은 전체 텍스트 검색 쿼리를 처리합니다. 쿼리 지원에 대해서는 뒤에서 설명합니다.
Microsoft 검색 서비스는 로컬 시스템 계정 컨텍스트에서 동작합니다. 이 서비스는 SQL Server와 같은 컴퓨터에서 실행되어야 합니다.
인덱싱 지원: 전체 텍스트 인덱스 채우기에 대한 정보는 채우기 시작 시드 값의 형태로 제공됩니다. 이 값은 전체 텍스트를 인덱스해야 하는 테이블과 데이터베이스 모두를 고유하게 식별하는 값입니다. 채우기를 처리할 준비가 되면 서비스가 SQL Server Handler를 호출합니다.
SQL Server Handler: 이 하위 구성 요소는 인덱싱 지원에 연결되는 "드라이버"로서 SQL Server 데이터 저장소를 다루는 방법을 이해하도록 특별히 설계되었습니다.
SQL Server Handler는 항상 Microsoft 검색 서비스와 같은 프로세스에서 실행됩니다.
인덱스 엔진: 이 하위 구성 요소에는 각각의 식별 키를 가진 인덱스 가능한 텍스트 단위들이 문자열 형태로 제공됩니다. 이 엔진은 문자열 전체를 검색하여 단어 경계를 확인하고 노이즈 단어를 모두 제거한 다음 나머지 단어들로 전체 텍스트 인덱스를 채웁니다.
쿼리 지원: 쿼리 지원은 전체 텍스트 쿼리를 처리하는 데 사용되므로 여기서는 설명하지 않습니다.
전체 텍스트 카탈로그: 이 카탈로그는 전체 텍스트 인덱스가 있는 위치이며 Windows NT Administrator와 Microsoft 검색 서비스만 액세스할 수 있는 Windows NT 파일 시스템 디렉터리입니다. 전체 텍스트 인덱스는 이름으로 참조되는 전체 텍스트 카탈로그로 조직됩니다. 일반적으로, 전체 데이터베이스에 대한 전체 텍스트 인덱스 데이터는 하나의 전체 텍스트 카탈로그에 배치됩니다. 그러나 관리자는 데이터베이스에 대한 전체 텍스트 인덱스 데이터를 융통성 있게 둘 이상의 전체 텍스트 카탈로그 간에 분할할 수 있습니다. 이는 전체 텍스트를 인덱스하는 하나 이상의 테이블에 많은 행이 포함된 경우 특히 유용합니다. 하나의 전체 텍스트 카탈로그는 231-64K 행에 대한 인덱스 데이터만 저장할 수 있습니다.
SQL Server 7.0에는 백업 및 복구용 관계형 데이터베이스 데이터를 관련 인덱스와 함께 전체 텍스트 카탈로그에 결합할 수 있는 기능이 없습니다. 그러나 이들을 동기화할 수 있는 기능은 있습니다. 이 결합 기능은 이후의 릴리스에 제공될 것입니다.
전체 텍스트 인덱싱 관리 단계:
아래의 모든 단계는 관리자가 GUI 또는 저장 프로시저를 사용하여 직접 또는 일정에 따라 "시작"합니다. #0: 준비 단계에서는 먼저 전체 텍스트 검색에 데이터베이스를 사용할 수 있도록 한 다음 전체 텍스트 검색에 등록할 테이블과 열을 확인합니다. 이 정보는 SQL Server의 시스템 테이블에 저장됩니다. #1:전체 텍스트 프로세스를 수행할 수 있도록 테이블이 활성화되면 해당 테이블에 대한 채우기 시작 시드가 인덱싱 지원에 전송됩니다. #2:다음 단계에서는 테이블에 대한 전체 텍스트 인덱스의 처음 채우기를 요청합니다. 실제로, 채우기 단위는 전체 텍스트 카탈로그입니다. 따라서 둘 이상의 테이블이 전체 텍스트 카탈로그에 연결되어 있는 경우, 이 요청이 이뤄지면 해당 카탈로그에 연결된 모든 테이블에 대한 전체 텍스트 인덱스의 전체 채우기가 수행됩니다. #3:인덱싱을 요청하는 테이블 및 행에 대한 정보는 SQL Server에 존재합니다. 따라서 인덱싱 지원이 전체 텍스트 카탈로그에 대한 채우기 요청을 받으면 인덱스하도록 표시된 테이블 내 모든 열의 데이터를 얻기 위해 SQL Server를 콜백합니다. 이 데이터가 도착하면 인덱스 엔진으로 전달됩니다. 인덱스 엔진에서는 데이터가 단어로 분리되고 노이즈 단어가 제거되며 나머지 단어는 인덱스에 저장됩니다. #4:전체 텍스트 인덱스를 최신 상태로 유지할 수 있도록 전체 텍스트 카탈로그의 주기적 새로 고침 일정을 설정하기 위한 GUI가 제공됩니다. 이 GUI는 SQL Server Job Scheduler의 저장 프로시저를 사용합니다. 또한 GUI를 통해 또는 저장 프로시저를 직접 사용하여 언제든지 새로 고침을 요청할 수 있습니다. 테이블에 행 버전 확인(타임스탬프) 열이 있는 경우 다시 채우기를 더 효과적으로 처리할 수 있습니다. 테이블의 채우기 시작 시드가 구성되는 시점을 기준으로 데이터베이스에서 가장 큰 행 버전 값이 기억됩니다. 증분 채우기가 요청되면 SQL Server Handler가 데이터베이스에 연결한 다음 기억된 값보다 더 큰 행 버전 값을 가진 행들만 요청합니다. 행 버전 확인 열이 없는 전체 텍스트 인덱스 테이블이 카탈로그에 있는 경우, 증분 채우기가 진행되는 동안 그 테이블이 완전히 다시 채워집니다. 아래의 두 경우에는 테이블에 행 버전 확인 열이 있어도 전체 다시 채우기가 수행됩니다. 테이블의 스키마가 변경되었을 때 마지막 채우기 이후 테이블이 활성화되었을 때
행 버전 확인 열이 있는 테이블의 채우기가 수행됨에 따라 "기억된" 행 버전 값이 업데이트됩니다. 타임스탬프 열이 있는, 상대적으로 정적인 테이블에 대한 증분 다시 채우기가 전체 다시 채우기보다 빠르게 완료될 수 있기 때문에 사용자들은 더 짧은 간격으로 다시 채우기 일정을 설정할 수 있습니다. 특정 데이터베이스에 대해, 사용자들은 타임스탬프 열이 있는 테이블의 인덱스 데이터를 동일한 전체 텍스트 카탈로그에 있지 않은 테이블과 섞지 않도록 주의해야 합니다. 일반적으로 이 두 테이블 그룹의 다시 채우기 일정은 서로 달라야 하기 때문입니다. #n: 추가 테이블 및 열이 전체 텍스트 검색에 등록되고 이들에 대한 전체 텍스트 인덱스가 만들어집니다. 아마 전체 텍스트 검색 기능이 몇몇 테이블과 열에서 제거될 것이고 일부 전체 텍스트 카탈로그가 삭제될 것입니다.전체 텍스트 쿼리 구성 요소 아키텍처:
쿼리 구성 요소는 SQL Server로부터 전체 텍스트 조건자 또는 행 집합 반환 함수를 받아들이고 조건자의 일부를 내부 형식으로 변환한 다음 이를 Microsoft 검색 서비스로 보냅니다. 그러면 이 검색 서비스가 행 집합에 일치하는 값을 반환합니다. 그 다음 행 집합이 다시 SQL Server로 전달됩니다. SQL Server는 이 정보를 사용하여 쿼리 제출자에게 반환될 결과 집합을 만듭니다.
SQL 관계형 엔진은 ContainsTable() 및 FreetextTable() 행 집합 반환 함수뿐만 아니라 CONTAINS 및 FREETEXT 조건자도 받아들입니다. 분석이 진행되면 이 코드는 전체 텍스트 검색에 등록되지 않은 열을 쿼리하는 등 검색 조건을 검사합니다. 유효하다는 결과가 나오면 실행 시에 전체 텍스트_검색_조건 및 컨텍스트 정보가 전체 텍스트 공급자에 보내집니다. 마지막으로 전체 텍스트 공급자가 SQL Server에 행 집합을 반환합니다. 이 행 집합은 원래 쿼리에 지정되거나 암시된 모든 조인에 사용됩니다.
전체 텍스트 공급자는 전체 텍스트_검색_조건을 분석, 확인하고 전체 텍스트 검색 조건에 대한 적절한 내부 표현을 만든 다음 이를 검색 엔진에 전달합니다. 그 결과는 전체 텍스트_검색_조건을 만족하는 행 집합을 통해 관계형 엔진에 반환됩니다. 이 행 집합의 처리는 개념 상 OpenRowset() 및 OpenQuery() 행 집합 반환 함수 지원에 사용되는 코드와 비슷합니다.
Microsoft 검색 서비스: 이 서비스는 위에 나온 전체 텍스트 인덱싱 구성 요소 아키텍처에서 이미 설명했습니다.
검색 엔진: 이 엔진은 전체 텍스트 검색 쿼리를 처리하는 하위 구성 요소로서 인덱스의 어떤 항목이 선택 조건을 충족하는지 확인합니다. 그리고 선택 조건을 충족하는 각 항목에 대해 고유 키 열 값 및 순위 값을 반환합니다.
인덱싱 지원: 인덱싱 지원에 대해서는 위에 나온 전체 텍스트 인덱싱 구성 요소 아키텍처에서 이미 설명했습니다.
전체 텍스트 쿼리 구성 요소 아키텍처
전체 텍스트 쿼리 프로세스: #1:CONTAINS, FREETEXT, ContainsTable(), FreetextTable 같은 전체 텍스트 생성 방법 중 하나를 사용하는 쿼리가 SQL 관계형 엔진에 제출됩니다. #2:CONTAINS 또는 FREETEXT 조건자가 포함된 쿼리는, 나중에 전체 텍스트 공급자로부터 반환되는 행 집합이 조건자가 적용되는 테이블에 자동으로 조인되도록 다시 작성됩니다. 이 재작성은 이러한 조건자가 SQL Server를 순조롭게 확장할 수 있도록 하기 위해 사용되는 메커니즘입니다. CONTAINS 및 FREETEXT를 지정하는 사용자들은 내부적으로 진행되는 Microsoft 검색 서비스 호출에 대해 신경쓰거나 자세히 알지 않아도 됩니다. #3:전체 텍스트 공급자가 호출되어 아래와 같은 정보를 전달받습니다. 전체 텍스트_검색_조건 테이블의 전체 텍스트 인덱스가 존재하는 전체 텍스트 카탈로그의 이름 언어(예: 단어 구분)에 사용할 로케일 ID 데이터베이스, 테이블 및 열 ID
둘 이상의 전체 텍스트 생성 방법을 사용하는 쿼리인 경우 이러한 각 방법마다 전체 텍스트 공급자가 따로 호출됩니다. SQL 관계형 엔진 자체는 전체 텍스트_검색_조건의 내용을 확인하지 않습니다. 전체 텍스트 검색 조건은 전체 텍스트 공급자에 전달됩니다. 그러면 이 공급자는 검색 조건의 유효성을 검사한 다음 검색 조건의 적절한 내부 표현을 만듭니다. #4:쿼리 지원에 명령이 전달됩니다. #5:쿼리 지원이 전체 텍스트 검색 조건과 일치하는 행의 고유 키 열 값이 포함된 행 집합을 반환합니다. 각 행의 RANK 값도 반환됩니다. #6:행 집합이 SQL 관계형 엔진에 전달됩니다. ContainsTable() 또는 FreetextTable() 함수를 처리하는 경우 RANK 값이 반환되지만 그렇지 않은 경우 RANK 값이 필터링되어 반환되지 않습니다. #7:행 집합 값이 관계형 데이터베이스 자체에서 얻은 값과 함께 쿼리에 "연결되고" 사용자에게 결과 집합이 반환됩니다. 전체 텍스트 인덱스 관리현재의 전체 텍스트 인덱스는 "전통적인" SQL 인덱스와는 많이 다릅니다. 이런 차이점 때문에 이 절에서 설명하는 관리 작업이 필요합니다. 아래 표에 주된 차이점이 요약되어 있습니다. 전통적 SQL 인덱스전체 텍스트 인덱스인덱스가 데이터베이스에 저장되어 데이터베이스의 제어를 받습니다. 전체 인덱스는 파일 시스템에 저장되지만 데이터베이스를 통해 관리됩니다. 테이블마다 여러 인덱스가 있을 수 있습니다. 테이블마다 전체 텍스트 인덱스 정의가 하나만 있습니다. 데이터가 삽입되거나 업데이트되거나 삭제될 때 그 데이터를 기반으로 하는 인덱스가 자동으로 업데이트됩니다. 일정에 따라 또는 특정 요청을 통해 전체 텍스트 인덱스에 대한 채우기를 반드시 요청해야 합니다. 인덱스가 그룹화되지 않습니다. 같은 데이터베이스에 있는 하나 이상의 전체 텍스트 인덱스 그룹이 함께 모여 전체 텍스트 카탈로그를 이룹니다. SQL 문을 사용하여 인덱스를 만들고 삭제합니다. 전체 텍스트 인덱스는 직접 또는 GUI를 통해 저장 프로시저를 사용하여 만들고 관리하고 삭제합니다.
전체 텍스트 관리는 아래와 같은 몇 가지 수준에서 수행됩니다. 서버: Microsoft 검색 서비스가 인덱스 채우기를 초기화하고 준비하기 위해 필요로 하는 속성 같은 서버 차원의 특정 속성을 설정할 수 있습니다. 데이터베이스: 데이터베이스가 전체 텍스트 검색을 사용할 수 있도록 설정해야 합니다. 사용 설정된 데이터베이스에서 하나 이상의 전체 텍스트 카탈로그에 대한 메타데이터를 만들고 삭제할 수 있습니다. 전체 텍스트 카탈로그: 관리 기능을 사용하여 전체 텍스트 카탈로그를 채워야 합니다. 테이블: 테이블의 전체 텍스트 인덱스에 대한 메타데이터가 생성될 때 전체 텍스트 쿼리를 지원하도록 그 테이블을 등록해야 합니다. 등록된 테이블을 먼저 활성화해야만 그 다음 전체 텍스트 카탈로그 채우기에 그 테이블이 참가할 수 있습니다. 열: 전체 텍스트 쿼리를 지원하는 열을 등록된 비활성 테이블에 추가하거나 삭제할 수 있습니다.
이 모든 수준에는 속성, 상태, 크기(예: 전체 텍스트 카탈로그의 크기) 정보를 가져오는 기능이 있습니다. 앞에서 설명한 것처럼 이러한 기능은 GUI와 저장 프로시저라는 두 형태를 모두 취하며 어떤 방식을 사용하든 거의 모든 작업을 수행할 수 있습니다. 이 문서는 기술적인 부분에 중점을 두기 때문에 주로 저장 프로시저에 대해 설명하며 GUI 사용에 대해서는 몇 가지 예제만 제공합니다. 여기서는 "저장 프로시저"를 관리자와 SQL Server 간의 통신 수준을 나타내기 위한 용어로 사용했습니다. 실제로는 저장 프로시저와 스칼라 반환 속성 함수를 조합하여 사용합니다.
다음 시나리오는 "저장 프로시저 모드"에서 작업하는 관리자가 'pubs' 데이터베이스에 있는 선택된 테이블 및 열에 대해 전체 텍스트 검색을 수행하기 위해 취할 수 있는 단계를 정리한 것입니다. 각 단계에서 대괄호 안에 표시된 단어는 관리가 수행되는 수준을 나타냅니다. 사용할 수 있는 모든 것을 소개하는 대신 이러한 프로시저를 어떻게 사용할 수 있는지에 대해 이해할 수 있을 정도만 소개하겠습니다. [서버] Microsoft 검색 서비스가 실행되고 있는지 검사합니다. 이는 SQL Server 엔터프라이즈 관리자에서 전체 텍스트 검색 아이콘의 모양과 색을 보면 알 수 있습니다.
필요하면 아래와 같은 몇 가지 방법 중 하나를 사용하여 Microsoft 검색 서비스를 시작할 수 있습니다. SQL Server 엔터프라이즈 관리자에서 전체 텍스트 검색 개체의 상황에 맞는 메뉴를 사용합니다. SQL Server 외부의 서비스 제어 관리자를 사용합니다. 서비스 제어 관리자에서 이 서비스의 이름은 "Microsoft 검색 서비스"입니다. MS-DOS?? 프롬프트에서 "net start mssearch"를 입력합니다. SQL Server 서비스 관리자를 사용합니다.
또한 위의 모든 위치에서 전체 텍스트 서비스를 중지할 수도 있습니다.
여기서는 'pubs' 데이터베이스가 아직 사용 설정되지 않은 상태입니다.
[서버] pubs 데이터베이스가 전체 텍스트 프로세스를 위해 사용 설정되었는지 확인합니다. 아래 SQL 문을 사용할 수 있습니다.SELECT DatabaseProperty('pubs',
'IsFulltextEnabled' )
서비스가 사용 설정되었으면 1을 반환하고 그렇지 않으면 0을 반환합니다.
여기서는 서비스가 이미 시작된 상태입니다.
[서버] 아래의 SQL 문을 실행하여 pubs 데이터베이스에 연결합니다.USE pubs
[데이터베이스] 아래의 저장 프로시저를 호출하여 pubs를 전체 텍스트 검색에 사용할 수 있도록 합니다.sp_fulltext_database 'enable'
[전체 텍스트 카탈로그] PubsCatalog라는 전체 텍스트 카탈로그를 만들고 기본 디렉터리를 선택합니다. 아래의 저장 프로시저를 호출하여 이 작업을 수행합니다.sp_fulltext_catalog 'PubsCatalog', 'create'
이 프로시저는 데이터베이스의 시스템 테이블에 전체 텍스트 카탈로그에 대한 메타데이터를 만들고 파일 시스템에 빈 전체 텍스트 카탈로그를 만듭니다. 파일은 기본 루트 디렉터리에 만들어지며 필요하면 제3의 매개 변수를 사용하여 이 기본 디렉터리를 무시할 수 있습니다.
[테이블] 'authors', 'jobs', 'pub_info' 및 'titles' 테이블을 전체 텍스트 프로세스에 등록합니다. 이렇게 등록한 테이블은 전체 텍스트 고유 키 열을 가져야 하며 이 열의 값은 반드시 각 행에 대해 고유한 값을 가지게 됩니다. 이러한 모든 테이블이 단일 열을 구성하는 기본 키를 가지기 때문에 이들 모두 자격을 갖추게 됩니다.이런 테이블을 등록하려면 고유 키 열에 고유 값을 적용하는 인덱스 이름을 지정해야 합니다. 주어진 테이블에 대한 이 정보는 sp_help_index 저장 프로시저를 사용하여 얻을 수 있습니다. 여기서 다루고 있는 인덱스는 아래와 같습니다.
authors
UPKCL_auidind
jobs
PK_jobs_22AA996
pub_info
UPKCL_pubinfo
titles
UPKCL_titleind
이제 이 이름들을 알았기 때문에 아래와 같이 테이블마다 sp_fulltext_table 저장 프로시저를 한 번씩 호출하여 테이블을 등록할 수 있습니다.
sp_fulltext_table 'authors', 'create',
'PubsCatalog', 'UPKCL_auidind'
sp_fulltext_table 'jobs', 'create',
'PubsCatalog', 'PK_jobs_22AA996'
sp_fulltext_table 'pub_info', 'create',
'PubsCatalog', 'UPKCL_pubinfo'
sp_fulltext_table 'titles', 'create',
'PubsCatalog', 'UPKCL_titleind'
이렇게 프로시저를 호출하면 이 전체 텍스트 카탈로그와 이 테이블들에 대한 시스템 테이블의 메타데이터가 업데이트됩니다.
[열] 새로 등록된 각 테이블에 대해 등록할 열 이름을 지정합니다. 아래와 같이 각 열에 대해 sp_fulltext_column 저장 프로시저를 한 번씩 호출하여 이 작업을 수행합니다.sp_fulltext_column 'authors', 'address', 'add'
sp_fulltext_column 'jobs', 'job_desc', 'add'
sp_fulltext_column 'pub_info', 'pr_info', 'add'
sp_fulltext_column 'titles', 'type', 'add'
sp_fulltext_column 'titles', 'notes', 'add'
이렇게 프로시저를 호출하면 시스템 테이블의 메타데이터가 증가합니다.
그런데 'titles' 테이블에 대해 'titles' 열이 아닌 'type' 열을 등록하는 실수가 있었습니다. 이는 설명을 위해 의도적으로 한 실수입니다.
[테이블] 실제 전체 텍스트 인덱스를 만들려면 먼저 테이블을 활성 상태로 만들어야 합니다. 아래와 같이 각 테이블에 대해 sp_fulltext_table 저장 프로시저를 한 번씩 호출하여 이들 테이블에 대한 전체 텍스트 인덱스를 만들 수 있도록 활성화합니다.sp_fulltext_table 'authors', 'activate'
sp_fulltext_table 'jobs', 'activate'
sp_fulltext_table 'pub_info', 'activate'
sp_fulltext_table 'titles', 'activate'
이렇게 해도 실제로 전체 텍스트 인덱스가 만들어지지는 않습니다. 이 작업은 이들 테이블의 데이터가 다음 채우기에 포함되도록 전체 텍스트 카탈로그의 메타데이터에 테이블을 활성 상태로 등록하는 것일 뿐입니다.4
[전체 텍스트 카탈로그] 아래와 같이 sp_fulltext_catalog 저장 프로시저를 호출하여 PubsCatalog 전체 텍스트 카탈로그의 전체 채우기를 시작합니다.sp_fulltext_catalog 'PubsCatalog', 'start_full'
전체 텍스트 카탈로그의 채우기는 비동기 방식으로 수행됩니다. 이는 프로시저가 실행되고 프로시저 호출자에게 그 결과가 반환된 직후 전체 텍스트 인덱스가 생성되었을 가능성이 거의 없다는 뜻입니다.
[전체 텍스트 카탈로그] PubsCatalog 전체 텍스트 카탈로그의 채우기 진행 상황을 조사합니다. 문은 아래와 같습니다.SELECT FulltextCatalogProperty
( 'PubsCatalog', 'PopulateStatus' )
서비스가 전체 텍스트 카탈로그에 대해 동작하지 않고 그 결과 분명 종료된 경우 0을 반환하며 그렇지 않으면 채우기의 다양한 단계를 나타내는 1 이상의 숫자를 반환합니다.
[테스트] 관리가 적절하게 수행되었는지 확인하기 위해 몇몇 SQL 쿼리를 실행합니다. 예를 들어, 아래의 SQL 문을 실행합니다.SELECT P.pub_name, T.title, T.price
FROM publishers P, titles.T
WHERE P.pub_id = T.pub_id
AND P.country = 'England'
AND CONTAINS (T.notes,
'"case is altered" OR
"cat and custard pot" OR
"the monarch and the sphinx"
' )
[테스트] 아래의 SQL 쿼리를 실행합니다.SELECT title_id, title, pubdate
FROM titles
WHERE CONTAINS (T.title,
'classic ~ french ~ cooking')
'title' 열이 전체 텍스트 쿼리에 등록되지 않았기 때문에 오류가 발생합니다.
[열] 실수가 없는지 확인합니다. 문은 아래와 같습니다.SELECT ColumnProperty ( ObjectId('titles'),
'titles',
'IsFulltextIndexed' )
제목이 'books' 테이블에 대한 전체 텍스트 인덱스의 일부인 경우 1을 반환하며 그렇지 않은 경우 0을 반환합니다. 여기서는 0이 반환됩니다.
[테이블] 아래와 같이 저장 프로시저를 호출하여 'titles'에 대한 전체 텍스트 프로세스에 참가하는 열들을 나열합니다.sp_help_fulltext_columns 'titles'
이 쿼리가 실행되면 실수가 있었다는 것 그리고 전체 텍스트 인덱스 정의에 'title' 대신 'type'이 포함되었다는 것이 드러납니다.
[테이블] 전체 텍스트 인덱스에 'title' 열을 추가하고 'type' 열을 제거할 수 있도록 'titles' 테이블을 비활성화합니다. 아래와 같이 저장 프로시저를 호출하여 이 작업을 수행합니다.sp_fulltext_table 'titles', 'deactivate'
'titles' 테이블을 비활성화하면 열을 추가하거나 삭제할 수 있을 뿐만 아니라 테이블이 PubsCatalog 전체 텍스트 카탈로그의 채우기에 더 이상 참가하지 않습니다. 그러나 메타데이터는 남아 있으며 테이블을 다시 활성화할 수 있습니다. 'titles' 테이블에 대한 기존의 전체 텍스트 인덱스는 PubsCatalog의 다음 전체 채우기 때까지 그대로 유지되지만 SQL Server가 비활성 테이블에 대한 쿼리를 차단하기 때문에 사용되지는 않습니다.
[열] 'title' 테이블의 전체 텍스트 인덱스에 대한 메타데이터에 'title' 열을 추가하고 'type' 열은 제거합니다. 아래와 같이 각 열에 대해 sp_fulltext_column 저장 프로시저를 한 번씩 호출하여 이 작업을 수행합니다.sp_fulltext_column 'titles', 'type', 'drop'
sp_fulltext_column 'titles', 'title', 'add'
[테이블] 아래와 같이 저장 프로시저를 호출하여 'books' 테이블을 다시 활성화합니다.sp_fulltext_table 'titles', 'activate'
테이블은 다시 활성화되지만 인덱스는 다시 채워지지 않습니다. 이전 인덱스는 남아 있는 모든 전체 텍스트 등록 열에 대한 쿼리에 여전히 사용할 수 있습니다. 물론 새로운 전체 텍스트 등록 열에 대한 쿼리에는 사용할 수 없습니다. 다시 채우기에 앞서, * 검색(테이블의 모든 전체 텍스트 열)을 지정하는 쿼리에 대해 삭제된 열의 데이터가 일치하는 값으로 검색된다는 데 유의해야 합니다.
[전체 텍스트 카탈로그] 아래와 같이 저장 프로시저를 호출하여 PubsCatalog 전체 텍스트 카탈로그의 증분 채우기를 시작합니다.sp_fulltext_catalog 'PubsCatalog',
'start_incremental'
증분 채우기는 아래 조건을 충족하는 전체 텍스트 가능한 열의 데이터를 인덱싱하여 전체 텍스트 카탈로그를 새로 고칩니다.
아래와 같은 테이블에서 마지막 채우기 이후 업데이트되거나 삽입된 행의 데이터 TIMESTAMP 형식의 열이 있는 테이블
아래와 같은 테이블에 있는 모든 행의 데이터 TIMESTAMP 형식의 열이 없는 테이블 마지막 채우기 이후 전체 텍스트 프로세스에 사용할 수 있게 된 테이블 마지막 채우기 이후 어떤 방식으로든 스키마가 수정된 테이블 [테스트] PubsCatalog의 다시 채우기가 완료될 때까지 기다린 후 [테스트] 단계에서 실행한 쿼리를 다시 실행합니다. 이제 오류가 발생하지 않습니다.
지금부터는 그래픽 사용자 인터페이스에 대해 설명합니다. 그래픽 사용자 인터페이스는 매우 간단하고 간편하므로 여기서는 이들이 SQL Server 엔터프라이즈 관리자의 나머지 GUI와 어떻게 조화를 이루는지에 대해 중점적으로 살펴보겠습니다. 전체 텍스트 관리에 사용하는 주된 방법 다섯 가지를 소개하기 위해 다음에 나오는 화면 캡처들에 큰 숫자와 화살표를 넣었습니다. 이 문서의 다른 부분과는 달리 여기서는 작업 순서를 나타내기 위해 숫자를 사용하지 않습니다. 숫자는 참조일 뿐입니다.
A) SQL Server 엔터프라이즈 관리자의 콘솔 트리:
콘솔 트리에는 아래와 같은 두 개의 전체 텍스트 개체가 있습니다.
1 Full-Text Search: 이 개체를 마우스 오른쪽 단추로 누르면 전체 텍스트 검색 서비스를 시작하거나 중지하는 옵션 같은 여러 옵션이 있는 메뉴가 나타납니다.
2 Full-Text Catalogs: 이 개체를 선택하면 데이터베이스의 전체 텍스트 카탈로그 목록이 세부 정보 창에 표시됩니다(화면 E 참조). 이 개체를 마우스 오른쪽 단추로 누르면 전체 텍스트 카탈로그 새로 만들기 및 모든 데이터베이스의 전체 텍스트 카탈로그 다시 만들기 같은 작업 옵션이 있는 상황에 맞는 메뉴가 나타납니다.
B) SQL Server 엔터프라이즈 관리자의 Tools 메뉴:
여기서 중요한 옵션은 아래와 같습니다.
3 Full-Text Indexing: 이 옵션을 선택하면 전체 텍스트 인덱싱 마법사가 실행됩니다(화면 H 참조).
C) 일반적인 테이블의 상황에 맞는 메뉴:
4 Full-Text Index Table: 이 옵션에는 테이블에 대한 전체 텍스트 인덱스 규정을 정의하거나 수정하고 테이블에서 전체 텍스트 인덱싱을 제거하기 위해 전체 텍스트 인덱싱 마법사를 실행하는 데 사용할 수 있는 하위 옵션들이 있습니다.
D) 일반적인 테이블의 속성 시트 탭과 그 요소:
아래 탭이 새로 추가되었습니다.
5 Full-Text Indexing: 이 탭을 선택하면 속성 페이지가 선택됩니다. 위의 화면은 이러한 전형적인 페이지의 모습을 나타냅니다.
E) 전형적인 전체 텍스트 카탈로그의 카탈로그 창 및 상황에 맞는 메뉴 :
아래 단계들을 따르면 이 메뉴가 나타납니다. 화면 A에서 Full-Text Catalogs 개체를 선택하여 전체 텍스트 카탈로그 목록을 표시합니다. PubsCatalog 항목을 마우스 오른쪽 단추로 누르면 화면에 있는 상황에 맞는 메뉴가 나타납니다.
Properties 항목을 선택하면 화면 F가 나타납니다.
Schedules 항목을 선택하면 화면 G가 나타납니다.
F) 전형적인 전체 텍스트 카탈로그의 상태 속성 페이지:
이 속성 페이지 화면은 화면 E의 메뉴에서 Properties 옵션을 선택하면 나타납니다.
G) 전형적인 전체 텍스트 카탈로그의 일정 속성 페이지:
이 속성 페이지 화면은 화면 E에서 Schedules 탭을 선택하면 나타납니다.
H) 전체 텍스트 인덱싱 마법사:
이 마법사는 여러 위치에서 호출할 수 있습니다. 여기서는 화면 B에서 Full-Text Indexing 옵션을 선택하거나 화면 C에서 Full-Text Index Table 옵션 중 하나를 선택하여 호출하는 방법을 소개합니다. 전체 텍스트 인덱싱 마법사는 주어진 테이블에 대한 전체 텍스트 인덱스를 만들고 유지하는 데 필요한 모든 정보를 수집합니다.
테이블을 등록하고 활성화한다고 해도 해당 테이블에 대한 전체 텍스트 쿼리가 실행되지는 않습니다. 먼저 전체 텍스트 인덱스를 만들어야 하며 마법사가 이 작업을 시작하지는 않습니다. 따라서 하나 이상의 테이블을 등록한 후 그 테이블(들)의 전체 텍스트 카탈로그에 대해 전체 채우기를 시작하는 것이 일반적입니다. 이 작업은 화면 E의 Start Population 옵션을 선택하여 수행할 수 있습니다. 결론
Microsoft는 SQL Server 7.0에 이 기능을 제공할 수 있게 된 것을 매우 기쁘게 생각합니다. 지원되는 기능들은 초급 수준이지만 다양한 전체 텍스트 검색을 수행하는 데 매우 유용하게 사용할 수 있습니다.
이런 초급 수준에서도 데이터베이스 내외부의 데이터를 모두 포함할 수 있는 기능을 제공한다는 사실이 중요합니다. SQL Server 7.0 분산 쿼리 프로세서가 데이터베이스의 전체 텍스트 쿼리 결과를 파일 시스템의 Index Server 2.0에 대한 쿼리 결과와 조인할 수 있으므로 고급 기능도 사용할 수 있습니다. Microsoft는 Microsoft 정보 검색 기술을 SQL Server 7.0에 통합하는 과정에서 이미 몇몇 Microsoft 제품에 포함된 기술 및 텍스트 검색을 지원하는 다른 Microsoft 제품의 토대가 될 기술에 대한 탄탄한 기반이 마련되었다고 믿습니다.
구성 요소를 다시 사용한다는 Microsoft의 전략에 따라, 기본 바탕이 되는 인덱스 및 검색 엔진에 순조로운 업그레이드 기능이 제공되고 제품 간에 일관성이 유지되므로 고객들이 그 혜택을 받을 수 있습니다.
이 문서에 포함된 정보는 문서를 발행할 때 논의된 문제들에 대한 Microsoft Corporation의 당시 관점을 나타냅니다. Microsoft는 변화하는 시장 환경에 대처해야 하므로 이를 Microsoft 측의 책임으로 해석해서는 안 되며 발행일 이후 소개된 어떠한 정보에 대해서도 Microsoft는 그 정확성을 보장하지 않습니다.
이 설명서는 오직 정보를 제공하기 위한 것입니다. Microsoft는 이 설명서에서 어떠한 명시적이거나 묵시적인 보증도 하지 않습니다.
© 1998 Microsoft Corporation. All rights reserved. Microsoft, MS-DOS, SQL Server 및 Windows NT는 미국, 대한민국, 및/또는 기타 국가에서의 Microsoft Corporation의 등록 상표 또는 상표입니다. 여기에 인용된 다른 제품이나 회사 이름은 해당 소유자의 상표일 수 있습니다.
Microsoft Part Number: 098-80764
1 SQL Server 컨텍스트에서는 "전체 텍스트 검색"이라고도 합니다.
2 업계에서는 중지 단어라고도 합니다.
3 간단히 Microsoft 검색 또는 전체 텍스트 검색이라고도 합니다.
4 또한 전체 텍스트 서비스에 각 테이블에 대한 전체 텍스트 채우기 시작 시드를 정의합니다.
최종 수정일 : 2000.5.12
www.shop-dwg.co.kr 구인, 구직 소개
'전기' 카테고리의 다른 글
| [*]주울의 법칙? [펌] 주울열 및 직류, 교류의 크기 표시 (0) | 2011.06.12 |
|---|---|
| *]불평형 부하제한? 전압불평형에 대하여 (0) | 2011.06.12 |
| 전선을 말아놓으면 열이난다...? 지져분한 이어폰 깔끔히 정리하기// (0) | 2011.06.12 |
| 한류저항[CLR) 공식이 나온이유?(1) 한류(韓流)문화, 한류(韓流)열풍 (0) | 2011.06.12 |
| [***]기사공사 요점정리[통합한것] [사무자동화산업기사] 사무자동화 요점정리 (0) | 2011.06.12 |