Процесор запитів Microsoft SQL Server. Частина 3, Інші СУБД, Бази даних, статті

3. Розподілені та гетерогенні запити.

3.1 Універсальний доступ до даних



Розглянемо типову СУБД з позицій способу зберігання інформації і набору сервісів для її обробки та вибірки. Ніхто не заважає нам написати СОМ-сервер, що інкапсулює основні сервіси з доступу та обробки даних, причому не обов'язково реляційних, а, наприклад, ієрархічних, таких як електронна пошта, служба каталогів і т.д., або взагалі неструктурованих. Як усередині нього ці служби будуть реалізовані – Особиста справа СОМ-сервера, оскільки ніхто, крім самих даних, не знає, як їх краще всього обробляти. Єдиною вимогою до нього буде підтримка стандартних інтерфейсів, свого роду зобов'язання об'єкта забезпечувати декларований набір методів з описаними параметрами і типами значень, що повертаються. Це необхідно, щоб клієнтське додаток з допомогою однакових методів могло одночасно працювати з різними типами даних, не вимагаючи переробки. Такий набір стандартних інтерфейсів був розроблений і отримав назву OLE DB ([7]). Наш СОМ-сервер в цій ситуації буде називатися OLE DB-провайдером. Відштовхуючись від звичних аналогій, провайдер можна уподібнити драйверу ODBC. Однак необхідно мати на увазі відмінності на прикладному і системному рівні. Перше – технологія OLE DB націлена на забезпечення доступу до даних будь-якої природи, а не обов'язково реляційних. По друге, ODBC – це набір Сшних функцій. Якщо ми пишемо програму, скажімо, на VB і хочемо замість RDO (Remote Data Objects – тонка обгортка над ODBC для додання більш дружнього інтерфейсу) використовувати ODBC в чистому вигляді, жодних проблем немає. Зробимо declare відповідних функцій – і вперед. OLE DB, як уже згадувалося, є сукупність інтерфейсів, побудованих відповідно до СОМ, тому вони принципово не досяжні з Automation-мов програмування. Для того, щоб функціональність OLE DB була доступна з ASP, Visual Basic (VBScript, VBA), Visual FoxPro та ін, була написана IDispatch-обгортка навколо OLE DB, що отримала назву ADO (ActiveX Data Objects). У ADO 1.5 була включена служба віддаленого доступу (RDS), що дозволяє розташовувати об'єкти на проміжному шарі між клієнтом і сервером. RDS підтримує прикладні протоколи HTTP і DCOM, тобто в якості сервера додатків може використовуватися Internet Information Server (IIS) або Microsoft Transaction Server (MTS). Компоненти ADO 2.0, що входять до складу Visual Studio 6, доповнені можливостями асинхронної обробки подій, локального кешу на клієнті, ієрархічної безлічі записів (з допомогою провайдера MSDataShape) та елементами управління для підтримки ADODB.Recordset. Ще одна відмінність полягає в тому, що ODBC-драйвер для джерела, що не підтримує SQL (наприклад, текстовий файл), повинен нести в собі еквівалент SQL-машини, навіть якщо клієнтові не потрібно ніякої іншої функціональності, крім простого безлічі записів. Нульовий рівень OLE DB передбачає лише найзагальніші базові можливості. Для їх розширення застосовуються сервісні компоненти, які можуть реалізовувати, наприклад, процесор запитів, механізм підтримки курсорів і т.д. Так, механізм курсорів приймає rowset, який нульової рівень поставляє в строго послідовному вигляді і доповнює його можливостями прокрутки в обох напрямках. Нульовий рівень і сервісні компоненти під управлінням SCM (Service Control Manager) утворюють перший рівень. Таким чином, архітектура OLE DB включає провайдера, споживача і шар сервісних компонент між ними.


За досить короткий термін різними фірмами були написані OLE DB-провайдери для більшості поширених серверів баз даних, настільних СУБД, ODBC, Active Directory, Index Server і ін Цей список продовжує поповнюватися (див., наприклад, http://www.microsoft.com/data/oledb/products/product.htm ). Багато хто з них разом з прикладами їх використання поширюються разом з Data Access SDK 2.0 (http://www.microsoft.com/data/download.htm ). Там же можна знайти інструментарій для написання власного OLE DB-провайдера за допомогою Visual C + +, Visual J + +, Visual Basic і т.д. (OLE DB Simple Provider Toolkit). Всі вони входять до OLE DB SDK 1.5. Розширення OLE DB for OLAP використовується як засіб доступу до багатовимірної інформації, наприклад, до Microsoft OLAP Services, що входять до складу SQL Server 7.0. Більше того, OLE DB є "Рідним" інтерфейсом SQL Server 7.0, тобто тим інтерфейсом, за допомогою якого процесор запитів спілкується з механізмом зберігання. DB-Library підтримується шляхом емуляції через OLE DB, але розвиватися, мабуть, надалі вже не буде. Механізм зберігання SQL Server 7.0 представляється для процесора запитів просто джерелом даних, одним з багатьох OLE DB-досяжних, не більше того. Якщо ми запустимо sp_linkedservers, то побачимо, що наш власний сервер розглядається процесором запитів як ще один приєднаний сервер. На момент написання цих рядків в SQL Server 7.0 підтримувалися наступні зовнішні джерела: ODBC, MS Access і ISAM, AS/400 і VSAM, Oracle 7.3 та вище, MS Index Server, OLE DB for OLAP і, власне, OLE DB-провайдер для SQL Server 7.0 (в ранніх документах, присвячених тематиці універсального доступу, може значитися як Luxor). Тут необхідно зазначити, що провайдер до SQL Server 7.0 можна використовувати у версіях 6.х, попередньо запустивши на них скрипт instcat.sql, що знаходиться в mssql7install. Цей скрипт, очевидно, не потрібно запускати, якщо ви плануєте здійснювати зв'язок з попередніми версіями через OLE DB поверх ODBC.


3.2 Робота із зовнішніми джерелами в SQL Server 7.0



У SQL Server 7.0 існують два основних способи роботи з віддаленим джерелом: через прілінкованний сервер (linked server) і через ім'я, дане по ходу справи (ad hoc name). Прілінкованний сервер є обумовлений заздалегідь віртуальний сервер, опис якого включає в себе інформацію про OLE DB-провайдера даного джерела і властивості з'єднання, що вказують провайдеру, де знаходиться джерело. Прілінкованние сервера є одиницями адміністрування зовнішніх джерел даних. Вони можуть визначатися як in-process (виконуються в процесі SQL Server) або out-of-process (як самостійні exe-модулі). Сервер in-process працює, очевидно, швидше, однак його доцільно вибирати для перевірених провайдерів. Незважаючи на стандартний характер більшості властивостей сполуки, кожен провайдер має можливість прийому додаткових значущих параметрів (наприклад, для геопросторових даних). Ці параметри також прописуються в прілінкованном сервері і називаються атрибутами.


Припустимо, в різних доменах у нас знаходяться два сервера: alexeysh_desk версії 7.0 та alexeysh_lapt версії 6.5. Якщо між доменами не встановлені довірчі відносини, то named pipes, за замовчуванням є основним прикладним протоколом взаємодії, слід замінити на, скажімо, TCP / IP Sockets. Для цього за допомогою Client Network Utility слід додати alexeysh_lapt в список серверів і вказати, що конкретно для нього ми вибираємо мережеву бібліотеку TCP / IP. З'єднаємося з alexeysh_lapt і запустимо скрипт instcat.sql, який додасть нові типи і системні таблиці в SQL Server 6.5. Тепер ми можемо визначити його як прілінкованний сервер стосовно alexeysh_desk. На з'єднанні з alexeysh_desk виконаємо наступний скрипт:
sp_addlinkedserver @ server = N "./020920111200005468.html", @ srvproduct = "SQL Server"


Параметрами процедури служать: @ server – ім'я, під яким джерело буде значитися в списку прілінкованних серверів і через яке ми будемо до нього звертатися (N перед ім'ям означає формат Unicode); @ srvproduct – Назва продукту: наприклад, якщо це SQL Server, то @ srvproduct = "SQL Server"; якщо Oracle, то "Oracle". Для Jet і ODBC це порожній рядок. Вказівка ​​@ srvproduct в явному вигляді позбавляє нас в даному випадку від необхідності введення інших параметрів. Аналогічні дії могли б бути виконані, наприклад, так:

 sp_addlinkedserver @ server = "MySQL65", @ srvproduct = "", @ provider = "SQLOLEDB",

@datasrc=”http://easy-code.com.ua/img/020920111200005468.html”, @catalog=”pubs”


До інших параметрів належать: @ provider – кодове позначення провайдера (SQLOLEDB – SQL Server, MSDASQL – ODBC, MSDAORA – Oracle, Microsoft.Jet.OLEDB.3.51, Microsoft.Jet. OLEDB.4.0 – Access, MSIDXS – Index Server і т.д.); @ datasrc – ім'я джерела даних (для SQL Server це серверне ім'я лінкуемого сервера, для Access – ім'я. Mdb-файл із зазначенням повного шляху, для ODBC – DSN і т.д.). Ім'я джерела даних може бути також задано серед переданих провайдеру властивостей. Наприклад, замість @ datasrc = "./020920111200005468.html", ми могли б передати його через параметр @ provstr:
sp_addlinkedserver @ server = N "MySQL65", @ srvproduct = "", @ provider = "SQLOLEDB", @ provstr = "server = alexeysh_lapt;", @ catalog = "pubs"


Точно так само в разі ODBC ми можемо передати DSN або рядок з'єднання (для так званого DSNless source). Зокрема, з'єднання з alexeysh_lapt може йти не безпосередньо через провайдера для SQL Server, а через провайдера для ODBC і ODBC-драйвер для SQL Server. Розглянемо приклади. За допомогою ODBC заведемо системний DSN на ім'я ааа для драйвера SQL Server і сервера alexeysh_lapt. Протестуємо його і переконаємося в роботі з'єднання. Тоді alexeysh_lapt може бути прілінкован як

      sp_addlinkedserver @server=”MySQL65ODBC”, 

@ Srvproduct = "", @ provider = "MSDASQL", @ datasrc = "./020920111200005469.html"

або те ж саме без створення DSN:

sp_addlinkedserver @server=”MySQL65ODBC”,

@ Srvproduct = "", @ provider = "MSDASQL", @ provstr = "driver = {SQL Server};

server=alexeysh_lapt;uid=sa;pwd=;

database=pubs”


У загальному випадку в @ provstr обмовляється специфічна для провайдера інформація, унікально ідентифікує джерело даних. Параметр @ catalog Відповідне властивості DBPROP_INIT_CATALOG при ініціалізації OLE DB-провайдера. Для SQL Server – це активна база даних. Більш докладний опис параметрів процедури sp_addlinkedserver можна знайти в документації по Transact-SQL.


Коли прілінкованний сервер бере участь у розподіленому запиті, локальний SQL Server повинен залогінитись на нього під якийсь авторизує інформацією, наприклад, від імені чинного користувача. Відображення локальних логінів на віддалені здійснюється за допомогою процедури sp_addlinkedsrvlogin. Приклади:
sp_addlinkedsrvlogin @ rmtsrvname = "MySQL65", @ useself = "true" – всі користувачі alexeysh_desk будуть ходити на alexeysh_lapt під їх власними іменами і паролями на alexeysh_desk, тобто перетворення відсутня (@useself=”true”) .


sp_addlinkedsrvlogin @ rmtsrvname = "MySQL65", @ useself = "false", @ locallogin = NULL, @ rmtuser = "sa", @ rmtpassword = "" – все логіни alexeysh_desk (@ locallogin = NULL) будуть авторізовиваться на alexeysh_lapt як sa з порожнім паролем. Якщо в @ rmtpassword вказати який-небудь лівий пароль, то при спробі звернутися до MySQL65 буде видане повідомлення login failed. При аутентифікації користувачів SQL Server засобами Windows NT сервер alexeysh_desk спробує прикинутися для alexeysh_lapt NTвим користувачем. Здатність SQL Server 7.0 емулювати аутентифицирующей інформацію користувачів Windows NT носить назву делегування та доступна тільки коли і локальний, і прілінкованний сервер працюють під NT 5.0.


Зворотна операція (видалення відображення локального логіну) виконується за допомогою sp_droplinkedsrvlogin. Sp_dropserver @ server = "MySQL65", @ droplogins = "droplogins" видаляє сервер зі списку прілінкованних з одночасним видаленням відображених на нього користувачів.


Проілюструємо розподілені запити на прикладі. Як об'єкт експерименту виберемо модельну базу даних pubs, встановлюються разом з SQL Server. Експортуємо таблицю titles в Excel. До складу SQL Server 7.0 включені служби перетворення даних (Data Transformation Services), основним призначенням яких є отримання даних з операційних джерел, їх очищення, уніфікація, перевірка на несуперечність і проміжне агрегування перед зануренням їх у сховище. У середовищі Microsoft Datawarehousing Framework, що забезпечує життєвий цикл сховища, DTS управляють потоками даних і метаданих між MS SQL Server та багатовимірним кубом OLAP Server, але в принципі вони можуть працювати з будь-якими OLE DB-джерелами. Основною адміністративною одиницею DTS служить пакет (package). По своїй ідеології пакет DTS споріднений завданням (job) SQL Agent (колишній SQL Executive). Він складається з кроків, логіка виконання яких може галузиться в залежності від результату роботи попередніх кроків. Крок відповідає елементарної операції DTS, наприклад, створення таблиці, копіювання даних і т.д. Як кроків можуть використовуватися оператори SQL, ActiveX-скрипти, виконувані файли (. Exe), насоси даних (data pumps) або якісь власні дії відповідно до інтерфейсом IDTSCustomStep. Самі пакети зберігаються в MS Repository, SQL Server або у вигляді persistent СОМ-об'єктів. Оскільки нам потрібно просто перекачати дані з SQL Server в інший формат, найпростіше вдатися до DTS Wizard (контекстне меню таблиці в SQL Enterprise Manager -> task -> Export from SQL). Аналогічно, перенесемо таблицю sales в попередньо підготовлену базу даних fox_sales в Visual FoxPro 6.0, а таблицю stores – в базу access_stores в MS Access 97. Що у нас ще є? Текстовий файл. Давайте експортуємо таблицю publishers в publishers.txt. Нижче наведено файл schema.ini для текстового драйвера ODBC.

[publishers.txt]

ColNameHeader=False

Format=FixedLength

MaxScanRows=25

CharacterSet=OEM

Col1=PUB_ID Char Width 4

Col2=PUB_NAME Char Width 40

Col3=CITY Char Width 20

Col4=STATE Char Width 2

Col5=COUNTRY Char Width 30


Створимо прілінкованние сервера для кожного з перелічених джерел. Таблицю Excel можна приєднувати як через OLE DB-провайдера для ODBC:

 if exists (select srvname from master.dbo.sysservers where srvname = "MyExcel97")

exec sp_dropserver @ server = "MyExcel97", @ droplogins = "droplogins"

go

exec sp_addlinkedserver @ server = "MyExcel97", @ srvproduct = "", @ provider = "MSDASQL.1",

@ Provstr = "Driver = {Microsoft Excel Driver (*. xls )};",catalog =" d: empHetQueries itles.xls "


(Вказівка ​​@ catalog в явному вигляді, як ми пам'ятаємо, не є обов'язковим і може бути передано у властивостях провайдера:


@ Provstr = "Driver = {Microsoft Excel Driver (*. xls)}; DBQ = D: TEMPHetQueries itles.XLS;"),


так і через OLE DB-провайдера для Jet:

exec sp_addlinkedserver 

@server=”MyExcel97″,

@ Srvproduct = "Jet 4.0", @ provider = "Microsoft.Jet.OLEDB.4.0",

@ Datasrc = "./020920111200005832.html", @ location = NULL, @ provstr = "Excel 5.0;"


У разі прілінковкі через Jet, потрібно задати відображення користувача:

 exec sp_addlinkedsrvlogin "MyExcel97", false, sa, "Admin", NULL

З текстовим файлом і таблицею FoxPro з'єднаємося з допомогою провайдера для ODBC:

exec sp_addlinkedserver

@server=”MyText”, @srvproduct=””, @provider=”MSDASQL.1″,

@provstr=”Driver={Microsoft Text Driver (*.txt; *.csv)};

DefaultDir=D:TEMPHetQueries”

exec sp_addlinkedserver

@server=”MyVFP6″, @srvproduct=””, @provider=”MSDASQL.1″,

@provstr=”Driver={Microsoft Visual FoxPro Driver};

UID =; PWD =; SourceDB = D: TEMPHetQueriesfox_sales.dbc; SourceType = DBC; Exclusive = No;

BackgroundFetch=Yes;Collate=Machine;”


а з базою даних в Access – через провайдера для Jet:

exec sp_addlinkedserver 

@server=”MyAccess97″,

@ Srvproduct = "Access 97", @ provider = "Microsoft.Jet.OLEDB.4.0",

@datasrc=”http://easy-code.com.ua/img/020920111200005833.html”


У разі ODBC перед нами скрізь приклад з'єднання без створення DSN, коли вся необхідна інформація (назва драйвера, місце розташування файлу) тут же передається провайдеру. Якщо вид рядка @ provstr для будь-якого ODBC-драйвера заздалегідь невідомий, його легко з'ясувати експериментально, тимчасово створивши відповідний DSN і подивившись, які властивості передаються провайдеру при DSN-з'єднанні. Припустимо, ми не знаємо, як повинна виглядати @ provstr для ODBC-драйвера для Excel. Створимо на таблицю Excel DSN на ім'я ааа. Наступний код

Dim cnn As New ADODB.Connection

cnn.Provider = “MSDASQL”

cnn.Open (“DSN=aaa”)

Debug.Print cnn.ConnectionString

cnn.Close


дасть нам рядок з'єднання

 Provider = MSDASQL.1; Connect Timeout = 15; Extended Properties = "DSN = aaa;

DBQ = D: TEMPHetQueries itles.XLS; DefaultDir = D: TEMPHetQueries;

DriverId = 790; FIL = excel 5.0; MaxBufferSize = 512; PageTimeout = 5; "; Locale Identifier = 1049


У ній слід звернути увагу на Extended Properties. Замість DSN = aaa потрібно поставити Driver ={…}, в фігурних дужках ставиться назва ODBC-драйвера точно в такому вигляді, як воно значиться в ODBC Data Source Administrator, закладка Drivers.


Механізм розпізнавання імен SQL Server 7.0 підтримує назви, що складаються з 4-х частин: <ім'я прілінкованного сервера>. <Каталог>. <Схема>. <Ім'я об'єкта>, наприклад, MySQL65.pubs.dbo. authors. Деякі провайдери не вимагають обов'язкової присутності всіх частин або мають для них значення за замовчуванням, такі частини можуть опускатися. Наприклад, якщо ми прілінковивают Excel через провайдера для ODBC, то ім'я аркуша (Sheet) titles може виглядати так: MyExcel97. [d: empHetQueries titles] .. [titles], якщо ж через провайдера для Jet, то його може мати вигляд MyExcel97 … [titles]. На ім'я прілінкованного сервера SQL Server на основі інформації, прописаної в системні таблиці за його (прілінкованного сервера) створення, ідентифікує провайдера і відсилає йому залишилися три частини імені. Цих відомостей провайдеру повинно бути достатньо, щоб однозначно визначити об'єкт в джерелі.


Запити до прілінкованним серверів можуть бути двох типів: з використанням імені з 4-х частин, або наскрізні (passthrough). Як приклад з іменами з 4-х частин перетворимо по ситуації запит на Ліст.1.1.2

 select a.au_fname, a.au_lname, t.title, p.pub_name, s.qty, st.stor_name from authors a

inner join MySQL65.pubs.dbo.titleauthor ta on a.au_id = ta.au_id

inner join MyExcel97 … [titles] t on ta.title_id = t.title_id

inner join MyText. [D: TEMPHetQueries] .. [publishers.txt] p on t.pub_id = p.pub_id

inner join MyVFP6. [fox_sales] .. [sales] s on s.title_id = t.title_id

inner join MyAccess97 … [stores] st on s.stor_id = st.stor_id


Можна його виконати і переконатися, що результат буде в точності таким же, як і у його прототипу на Ліст.1.1.2, де всі дані зберігалися на локальному сервері.


Наскрізні запити створюються за допомогою функції OpenQuery (). Першим аргументом цієї функції виступає ім'я прілінкованного сервера, другим – власне текст запиту: select * from OpenQuery (Monarch, "select FileName from scope ("" c: Program Files "")"). Запит всередині OpenQuery () не перевіряється і не аналізується SQL Server "ом, а безпосередньо передається прілінкованному джерела так, як є. Відсутність передобробки дозволяє заощадити час, але вимагає акуратності при складанні запиту. Приклад: запити

 select * from OpenQuery (MyExcel97, "select * from titles where type =" "business" "") і

select * from OpenQuery (MyExcel97, "select * from titles") where type = "business"


дають один і той же результат, однак у другому запиті перевірку умови фільтрації виконує SQL Server, а в першому – OLE DB-провайдер. Перший запит слід визнати більш ефективним, оскільки в цьому випадку пересилати доводиться меншу кількість даних.


Третій варіант побудови розподіленого запиту (ad hoc name) дозволяє взагалі обійтися без прілінкованного заздалегідь сервера. Виклик функції OpenRowset підміняє звернення до таблиці. У параметрах повинна бути зазначена інформація, що дозволяє встановити з'єднання з віддаленим джерелом, і сама таблиця у вигляді <каталог>. <схема>. <об'єкт>, або запит. Приклад:

 select * from OpenRowset ("MSDASQL", "Driver = {Microsoft Excel Driver (*. xls)};

DBQ = D: TEMPHetQueries itles.XLS; "," select * from titles where type = "" business "" ")


При спільній роботі з даними, що відносяться як до SQL Server, так і до віддалених джерел слід мати на увазі, що зовнішні дані завжди доступні на читання. Підтримка операцій оновлення зовнішніх даних залежить від рівня їх обслуговує провайдера. Над вхідними в той самий запит даними, що належать SQL Server, можливі будь-які допустимі операції. Отже, зовнішні дані завжди можуть бути використані для створення уявлень і статичних курсорів. Оновлення зовнішніх даних через подання або keyset-курсорів визначається можливостями провайдера. Динамічні курсори і оператори DDL над зовнішніми даними не підтримуються. Конвертація даних здійснюється шляхом приведення до найближчого відповідного типу, визначеному в стандартах OLE DB. Сортування виконується відповідно до порядку, заданим на локальному SQL Server. Участь зовнішніх даних у транзакціях залежить від того, реалізовані чи в провайдер інтерфейси підтримки транзакцій. Наприклад, якщо провайдер підтримує інтерфейс ITransactionLocal, але не підтримує ITransactionJoin, дані віддаленого джерела можна включати в локальні транзакції, але вони не зможуть успадковувати контекст зовнішньої транзакції і, отже, не будуть брати участь в розподілених транзакцій ([7]). Підтримка провайдером інтерфейсу IDBSchemaRowset дозволяє SQL Server "у одержувати інформацію про метадані. Для цього можна використовувати системні збережені процедури sp_catalogs, sp_tables_ex, sp_columns_ex, sp_table_privileges, sp_column_privileges, sp_primarykeys, sp_foreignkeys, sp_indexes та ін Якщо провайдер надає інформацію про наявні індексах, процесор запитів SQL Server зможе точніше оцінити розподілений запит і оптимізувати його виконання. У плані запиту

 select st.stor_name, st.city, s.ord_num, s.qty from stores st, 

MyOracle .. klm.sales s where s.stor_id = st.stor_id and s.qty> 50

—————-

/-Merge Join(Inner Join,

MANY-TO-MANY MERGE:(s.stor_id)= (Expr1002)

ESIDUAL:(s.stor_id=Convert(st.stor_id)))

/-Remote Query(SELECT `s`. `Ord_num` AS Col1007, `s`. `Qty` AS Col1008, `s`. `Stor_id`

AS Col1006 FROM `sales` s WHERE `s`. `Qty`> (50) ORDER BY `s`. `Stor_id` ASC)

/-Sort(ORDER BY: (Expr1002 asc))

/-Compute Scalar(Expr1002=Convert(st.stor_id))

/-Clustered Index Scan (pubs.. Stores.UPK_storeid AS st)


виділеним шрифтом зображений підзапит, який насправді SQL Server відсилає на сервер Oracle. Крок Merge Join отримує від провайдера Oracle відфільтровані по qty і відсортовані по stor_id результати запиту. Якби таблиця sales перебувала, скажімо, у вигляді текстового файлу, то в плані замість Remote Query стояло б сканування всієї вилученої таблиці (виконується провайдером) з наступними кроками фільтрації та сортування (виконується процесором запитів SQL Server).


3.3 Повнотекстовий пошук



Одним з приватних прикладів застосування технології універсального доступу може служити можливість повнотекстового пошуку в SQL Server 7.0. Повнотекстовий провайдер (full-text provider) являє собою проміжна ланка, за допомогою якого клієнтську програму взаємодіє зі службою повнотекстового пошуку (Microsoft Search Service). Служба повнотекстового пошуку встановлюється як комопонент SQL Server 7.0 стандартної (Standard) і коропоратівной (Enterprise) редакції і функціонує як сервіс Windows NT. Настільна (Windows 9x) редакція SQL Server здатна використовувати повнотекстовий пошук подібно клієнтам SQL Server, що встановив з'єднання з сервером стандартної або корпоративної редакції. Служба повнотекстового пошуку створює каталоги і повнотекстові індекси. Кожен запис індексу містить покажчик на запис таблиці, слова, асоційовані з цим записом за вирахуванням незначущих (noisy words), інформацію про стать, якій вони належать, і місце їх знаходження в цьому полі. Як покажчика запису використовується первинний ключ (primary key) або кандидат (candidate). На таблицю можна створити не більше, ніж один повнотекстовий індекс. Кожен індекс перебуває у своєму каталозі. База даних може мати кілька індексних каталогів, але кожен каталог повинен відповідати тільки одній базі даних. Повнотекстові індекси не допускаються над виставами, а також системними або тимчасовими таблицями. Можливі два способи наповнення повнотекстових індексів – Full Population (застосовується при початковому створенні індексу, або при істотній зміні змісту індексованих полів) і Incremental Population. Останній доступний для таблиць, що мають поле timestamp. Зміна змісту індексованих полів не тягне за собою негайної поправки повнотекстового індексу, оскільки останні досить об'ємні і при їх постійної модифікації відбувалася б помітна затримка. Замість цього можна оформити Incremental Population як завдання (job), що виконується з деякою періодичністю за допомогою SQL Agent. Каталог є мінімальної одиницею поновлення повнотекстових індексів. Крім того, до функцій служби повнотекстового пошуку входить обробка спеціальних конструктів у запитах (предикати CONTAINS і FREETEXT), за допомогою яких здійснюється пошук окремих слів і фраз, облік відстані між словами (NEAR), розпізнавання словоформ (FORMSOF) і зважування за значимістю (ISABOUT). Як приклад створимо таблицю з полем pgh типу text, в кожен запис якої покладемо окремий абзац цієї статті. Це можна зробити за допомогою макросу:

Sub Macro1()

Dim cnn As Object

Set cnn = CreateObject(“ADODB. Connection”)

Dim rst As Object

Set rst = CreateObject(“ADODB.Recordset”)

With cnn

. Open "Provider = SQLOLEDB; Data Source = alexeysh_desk; User ID = sa; Password =;

Initial Catalog=pubs”

. Execute "CREATE TABLE MySQLPaper (id int IDENTITY (1, 1) CONSTRAINT

[PK_MySQLPaper] PRIMARY KEY NONCLUSTERED (id) ON [PRIMARY], pgh ntext, ts timestamp)

ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]”

For Each pgh In ActiveDocument.Paragraphs

.Execute “insert into mysqlpaper (ts) values (default)”

rst.Open "select pgh from MySQLPaper where id = @ @ identity", cnn, 1, 3, -1

rst.Fields(0) = pgh

rst.Update

rst.Close

Next

.Close

End With

End Sub


Таблиця готова. Асоціюємо список незначущих слів (noisy words) з ​​файлом noise.dat:

 sp_configure “Language neutral full-text”, 1 

go

reconfigure

go


Робимо поточну базу даних доступною для повнотекстового пошуку:
exec sp_fulltext_database @action=”enable”


Створюємо новий повнотекстовий каталог SQLPaper по заданому шляху:
exec sp_fulltext_catalog @ ftcat = "SQLPaper", @ action = "create", @ path = "d: mssql7b3_datFTData"


Створюємо метадані повнотекстового індексу і вказуємо, що ідентифікація записів у таблиці MySQLPaper повинна відбуватися за ключем PK_MySQLPaper:
exec sp_fulltext_table @ tabname = "MySQLPaper", @ action = "create", @ ftcat = "SQLPaper", @ keyname = "PK_MySQLPaper"


Додаємо поле pgh як одне з тих, за яким буде відбуватися повнотекстовий пошук (індекс поки неактивний):

 exec sp_fulltext_column @ tabname = "MySQLPaper", @ colname = "pgh", @ action = "add"

Реєструємо таблицю в каталозі повнотекстового пошуку файлової системи:
exec sp_fulltext_table @ tabname = "MySQLPaper", @ action = "activate"


Всі перераховані вище дії інтерактивно зручніше виконувати за допомогою програми-майстри повнотекстових індексів, яка створює каталог і структуру індексу. Нам залишається лише наповнити індекси в даному каталозі:
exec sp_fulltext_catalog @ ftcat = "SQLPaper", @ action = "start_full"


Після чого до таблиці можна звертатися із запитами типу:
select id, pgh from MySQLPaper where contains (pgh, "" полнотекст * "near" пошук "")


З плану виконання випливає, що процесор запитів SQL Server перевіряє, чи визначено на поле pgh повнотекстовий індекс і перетворює оператор SQL в послідовність дій над безліччю записів. Зазвичай ці дії через OLE DB-провайдера передаються механізму зберігання SQL Server. Проте дії, пов'язані з контекстного пошуку, передаються OLE DB-провайдеру служби повнотекстового пошуку. Ця служба здійснює пошук за своїми каталогами і які мають них повнотекстових індексів і повертає набір покажчиків на записи, які відповідають умовам пошуку. Процесор запитів комбінує його з наборами, отриманими від інших провайдерів, зокрема, механізму зберігання і будує остаточне безліч результатів, яке повертається клієнтського додатку. Каталоги та індекси, що знаходяться під управлінням служби повнотекстового пошуку, не зберігаються в базі даних SQL Server, отже, їх не охоплюють операції резервного копіювання і відновлення. Детальніше про архітектуру і синтаксичних конструкціях повнотекстового пошуку можна дізнатися, звернувшись до документації.


Служба повнотекстового пошуку, що входить до складу SQL Server 7.0 забезпечує пошук за строковим і текстовим полям (у тому числі Unicode). Контекстний пошук за документами файлової системи або опублікованими на Web-сервері здійснюється за допомогою індексних механізмів Microsoft Index Server або Microsoft Site Server і розглянутим нами технології гетерогенних запитів (наприклад, через прілінкованние сервера). Для доступу до цих індексах використовуються OLE DB-провайдери (відповідно, для Index Server або Site Server), так що описана вище схема повнотекстового пошуку зберігається з точністю до провайдера. Базові синтаксичні розширення повнотекстового пошуку в Transact-SQL однакові і підтримуються кожним із трьох згаданих провайдерів.


Список літератури



1. Byrne, Jeffry L. "Microsoft SQL Server: What Database Administrators Need To Know", Prentice Hall, 1997, ISBN 0-13-495409-2. (Джеффрі Л. Бірн. "Microsoft SQL Server 6.5. Керівництво адміністратора". Лорі, 1997)


2. Debetta, P. "Microsoft SQL Server 6.5 Programming Unleashed". SAMS Publishing, 1998, ISBN 0-67231-244-1


3. England, Ken. "The SQL Server 6.5 Performance Optimization and Tuning Handbook". Digital Press, ISBN 1-5558-180-3


4. Fushimi, Sh., Kitsuregawa, M., Tanaka, H. "An Overview of The System Software of A Parallel Relational Database Machine GRACE". VLDB Conf. 1986: 209-219


5. Graefe, G., Bunker, R., Cooper S. "Hash joins and hash teams in Microsoft SQL Server". VLDB Conf., 1998


6. Graefe G. "Query Evaluation Techniques for Large Databases". ACM Computing Surveys 25 (2): 73-170 (1993).


7. "Microsoft OLE DB 1.1 Programmer" s Reference and Software Development Kit ". Microsoft Press, 1997, ISBN 1-57231-612-8. (" Довідник з Microsoft OLE DB 1.1 ". Російська Редакція, 1997)


8. Rankins, R.; Solomon, D. "Microsoft SQL Server 6.5 Unleashed". SAMS Publishing, 1998, ISBN 0-672-31190-9. (Д. Соломон та ін "Microsoft SQL Server 6.5. Енциклопедія користувача". Діасофт, 1998)


9. Schneider, Robert D. "Microsoft SQL Server: Planning and Building a High Performance Database". Prentice Hall, 1997, ISBN 0-13-266222-1. (Роберт Д. Шнайдер. "Microsoft SQL Server. Проектування високопродуктивних баз даних ". Лорі, 1997)


10. Soukup, Ron. "Inside Microsoft SQL Server 6.5". Microsoft Press, 1997, ISBN 1-57231-331-5.


11. Spenik, M., Sledge, O. "Microsoft SQL Server 6.5 DBA Survival Guide". SAMS Publishing, 1996, ISBN 0-672-30959-9


12. Vaughn, William R.. "Hitchhiker" s Guide to Visual Basic and SQL Server ". Microsoft Press, 1998, ISBN 1-57231-848-1


13. Zeller, H., Gray J. "An Adaptive Hash Join Algorithm for Multiuser Environments". VLDB Conf. 1990: 186-197


14. Горєв А., Макашаріпов С., Владимиров Ю. "Microsoft SQL Server 6.5 для професіоналів". Вид-во "Питер", 1997, ISBN 5-88782-427-1


15. Макашаріпов С. "Програмування баз даних на Visual Basic 5 у прикладах". Вид-во "Питер", 1997, ISBN 5-88782-315-1


Олексій Шуленін, Microsoft, системний інженер, тел. 967-85-85

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*