فصل ۵

بهبودهای برنامه‌پذیری و فراتر از رابطه‌ای

برای تقویت برنامه‌پذیری و الگوی «فراتر از رابطه‌ای» (Beyond-Relational) در Microsoft SQL Server 2012 شمار بسیار زیادی بهبود انجام شده است. برای خوانندگانی که با مفهوم فراتر از رابطه‌ای آشنا نیستند، این اصطلاح به داده‌ها و سرویس‌هایی اشاره می‌کند که از الگوهای سنتی جدول در SQL Server فراتر می‌روند. برخی از بهبودهای فراتر از رابطه‌ای SQL Server 2012 که توانایی ساخت برنامه‌های مدیریت‌کنندهٔ همهٔ انواع داده را بهتر می‌کنند، شامل اصلاح قابلیت‌های موجودی مانند جست‌وجوی تمام‌متن (Full-Text Search)، داده‌های مکانی (Spatial Data) و FILESTREAM هستند. SQL Server 2012 همچنین قابلیت‌های کاملاً جدیدی مانند FileTable و جست‌وجوی معنایی آماری (Statistical Semantic Search) معرفی می‌کند.

پیش از ارائهٔ مرور سطح‌بالای این بهبودها، این فصل ابتدا برخی نقاط درد استفاده از قابلیت‌های فراتر از رابطه‌ای، اهداف SQL Server 2012 در این زمینه، و اکوسیستم داده و سرویس SQL Server 2012 را بررسی می‌کند؛ اکوسیستمی که با عنوان الگوی فراتر از رابطه‌ای در SQL Server نیز شناخته می‌شود.

نقاط درد استفاده از الگوی فراتر از رابطه‌ای

ساخت و نگه‌داری برنامه‌هایی که هم دادهٔ رابطه‌ای و هم دادهٔ غیررابطه‌ای دارند، به دلایل مختلف کاری بسیار پیچیده است. نخست، یکپارچه‌کردن دادهٔ ساخت‌یافته و بدون ساختار دشوار است، زیرا ماهیت این دو نوع داده کاملاً متفاوت است. دوم، دادهٔ ساخت‌یافته معمولاً در پایگاه‌دادهٔ رابطه‌ای قرار می‌گیرد، در حالی که دادهٔ بدون ساختار در پوشه‌ها یا Shareهای فایل روی یک سرور ذخیره می‌شود. در چنین وضعی نقاط یکپارچه‌سازی چندانی برای هم‌بسته‌کردن یا به‌هم‌دوختن داده‌ها وجود ندارد و این موضوع مشکلات مدیریتی ایجاد می‌کند. برای نمونه، مدیر پایگاه‌داده باید دو مجموعه فضای ذخیره‌سازی متفاوت را اداره کند: پایگاه‌دادهٔ رابطه‌ای برای دادهٔ ساخت‌یافته و File Shareها برای دادهٔ بدون ساختار. افزون بر این، هر راهبرد برای دسترس‌پذیری بالا و بازیابی پس از فاجعه روش متفاوتی می‌طلبد، راه ساده‌ای برای همگام‌نگه‌داشتن دادهٔ ساخت‌یافته و بدون ساختار وجود ندارد، و ایجاد یک تجربهٔ جست‌وجوی واحد برای یافتن اطلاعات مرتبط در هر دو قالب دشوار است.

اهداف فراتر از رابطه‌ای SQL Server 2012

نقاط درد بخش پیشین، تیم توسعهٔ SQL Server را به تعریف چند هدف برای بهبود راهبرد و قابلیت‌های فراتر از رابطه‌ای در SQL Server 2012 واداشت. این اهداف عبارت بودند از کاهش هزینهٔ مدیریت داده‌های ناهمگون، ساده‌سازی فرایند توسعهٔ برنامه روی همهٔ انواع داده، فراهم‌کردن سرویس‌های مدیریتی و برنامه‌نویسی برای تمام داده‌ها صرف‌نظر از ساخت‌یافته یا بدون ساختار بودن آن‌ها، و در نهایت ارائهٔ تجربهٔ جست‌وجوی غنی در همهٔ داده‌ها تا سازمان‌ها بتوانند بینش‌های تجاری ارزشمند و روابط معناداری میان داده‌های ذخیره‌شده کشف کنند.

روندهای صنعت نیز دلیل دیگری برای سرمایه‌گذاری روی الگوی فراتر از رابطه‌ای بودند. هشتاد درصد داده‌های سازمان‌ها ساخت‌یافته نیست، در پایگاه‌داده ذخیره نمی‌شود، مدیریت نمی‌شود و قابلیت مقیاس‌پذیری ندارد. SQL Server می‌تواند راهی برای مدیریت دادهٔ بدون ساختار فراهم کند و هم‌زمان تجربهٔ برنامه‌ای غنی و فرصت استخراج بینش ارزشمند از داده را ارائه دهد. این راهکار همچنین می‌تواند تا پشتیبانی از چندصد میلیون سند مقیاس پیدا کند.

پیش از معرفی قابلیت‌های جدید فراتر از رابطه‌ای SQL Server 2012، اکوسیستم داده و سرویس‌های بدون ساختار این محصول را مرور می‌کنیم.

اکوسیستم غنی داده و سرویس‌های بدون ساختار

شکل ۵-۱ نمایی کلی از اکوسیستم داده و سرویس‌های بدون ساختار SQL Server 2012، همراه با بهبودهای انجام‌شده در چند انتشار اخیر SQL Server، ارائه می‌دهد. تمرکز بر قابلیت‌های فراتر از رابطه‌ای با SQL Server 2008 به بلوغ رسید. پیش‌تر برای ذخیرهٔ دادهٔ بدون ساختار در جدول‌های پایگاه‌داده باید از اشیای دودویی بزرگ (Binary Large Object یا BLOB)، مانند ستون‌های varbinary(max) استفاده می‌شد. این رویکرد یکپارچگی را فراهم می‌کرد، اما سرعت Streaming آن به اندازهٔ زمانی نبود که سندها مستقیماً در فایل‌سیستم Windows ذخیره می‌شدند.

برای رفع این نگرانی، FILESTREAM در SQL Server 2008 معرفی شد. FILESTREAM به برنامه‌های مبتنی بر SQL Server اجازه می‌داد داده‌های بدون ساختار مانند سند و تصویر را در فایل‌سیستم نگه دارند. برنامه‌ها می‌توانستند از APIهای غنی Streaming و کارایی فایل‌سیستم استفاده کنند و در عین حال سازگاری تراکنشی میان دادهٔ بدون ساختار و دادهٔ ساخت‌یافتهٔ متناظر حفظ شود. با این حال، برای برخی برنامه‌های Windows که برای کارکردن به سلسله‌مراتب دایرکتوری Win32 نیاز داشتند، هنوز شکافی وجود داشت؛ زیرا فرمان FileOpen به زمینهٔ تراکنشی نیاز داشت که فقط با APIهای FileStream فراهم می‌شد. آن برنامه‌ها همچنان نمی‌توانستند از FILESTREAM استفاده کنند.

قابلیت دیگری که SQL Server 2008 برای دادهٔ بدون ساختار معرفی کرد Remote BLOB Store یا RBS بود. مجموعه API استاندارد RBS اجازه می‌داد یک BLOB مانند سند Office یا ویدئو از طریق API مستقل از فروشنده ذخیره شود. RBS شناسهٔ BLOB سندهای موجود در ذخیره‌سازی راه‌دور را داخل پایگاه‌داده نگه می‌داشت و سازگاری پیوندها را مدیریت می‌کرد. اندازه و محل واقعی فایل‌ها و سندها به‌جای ساختارشان در پایگاه‌داده ذخیره می‌شد. مدیران پایگاه‌داده می‌توانستند دادهٔ رابطه‌ای و دادهٔ RBS را به‌شکل Loose Coupling به هم متصل کنند. RBS با جست‌وجوی تمام‌متن یکپارچه نیست و یکپارچگی تراکنشی کامل میان دو مخزن فراهم نمی‌کند، اما امکان ساخت برنامه‌ها به روشی استاندارد و جابه‌جایی داده میان مخازن را می‌دهد.

در SQL Server 2012 الگوی فراتر از رابطه‌ای با FileTable، FILESTREAM، چند قابلیت جدید جست‌وجوی تمام‌متن و امکان انجام جست‌وجوی معنایی روی دادهٔ بدون ساختار گسترش یافته است.

نمونه‌ای از کاربرد فراتر از رابطه‌ای

Microsoft Outlook همراه Microsoft Exchange نمونهٔ بسیار خوبی از یک پایگاه‌داده و برنامهٔ محبوب فراتر از رابطه‌ای است. این برنامه‌ها هم دادهٔ ساخت‌یافته و هم دادهٔ بدون ساختار ذخیره می‌کنند و با یافتن سندهای مرتبط در همهٔ عناصر برنامه، قابلیت جست‌وجوی سنتی شبیه جست‌وجوی معنایی فراهم می‌سازند. برای نمونه، تاریخ و اولویت هر پیام ایمیل در پایگاه‌دادهٔ ساخت‌یافته ذخیره می‌شود، در حالی که محتوای خود پیام و پیوست‌هایی مانند تصویر و ارائهٔ Microsoft PowerPoint دادهٔ بدون ساختار به‌شمار می‌آیند. ابزار جست‌وجوی Inbox امکان جست‌وجوی هم‌زمان دادهٔ ساخت‌یافته و بدون ساختار را با کلیدواژه‌های مشخص می‌دهد. ابزارهای یافتن پیام‌های مرتبط در یک گفت‌وگو یا پیام‌های مرتبط از یک فرستنده نیز نوعی جست‌وجوی معنایی ارائه می‌کنند. این مثال به‌خوبی استفاده از قابلیت‌های فراتر از رابطه‌ای همراه جست‌وجوی معنایی را نشان می‌دهد.

اکنون برای درک سرمایه‌گذاری‌های Database Engine روی فراتر از رابطه‌ای و جست‌وجوی معنایی، به SQL Server 2012 می‌پردازیم.

بهبودهای FILESTREAM

FILESTREAM به برنامه‌های مبتنی بر SQL Server اجازه می‌دهد دادهٔ بدون ساختار مانند سند و تصویر را در فایل‌سیستم ذخیره کنند. در SQL Server 2008 R2 در هر Filegroup مربوط به FILESTREAM تنها یک Storage Container پشتیبانی می‌شد و این محدودیت، مقیاس‌پذیری ظرفیت ذخیره‌سازی و I/O را محدود می‌کرد.

SQL Server 2012 با پشتیبانی از چند Storage Container، قابلیت Scale-up را به حداکثر می‌رساند. قابلیت‌های جدید مرتبط عبارت‌اند از:

• پشتیبانی از چند Storage Container و Filegroup:
  • تغییرهای زبان تعریف داده (DDL) در دستورهای CREATE DATABASE و ALTER DATABASE.
  • امکان تعیین max_size برای Containerها.
  • پشتیبانی از DBCC SHRINKFILE EMPTYFILE.
• انعطاف‌پذیری مقیاس:
  • افزایش ظرفیت با افزودن درایوهای ذخیره‌سازی.
  • مقیاس‌پذیری I/O با چند دیسک.

آزمایش‌های مشتریان نشان داد استفاده از چند دیسک، مقیاس‌پذیری و کارایی I/O در FILESTREAM را افزایش می‌دهد. شکل ۵-۲ نتیجهٔ مقایسهٔ SQL Server 2012 و SQL Server 2008 R2 را نشان می‌دهد.

در نمودار شکل ۵-۲، خط صعودی بالایی پایداری و Throughput بهتر چند Container را نسبت به یک Container، که با خط تقریباً تخت پایین نمایش داده شده، نشان می‌دهد. چند Container همچنین از راه‌حل پیچیدهٔ سطح برنامه که داده را با دو جدول جداگانه میان دو Container توزیع می‌کند بهتر عمل می‌کند. خط پرنوسان آن راه‌حل چندین افت و اوج دارد؛ افت‌ها ناشی از پیچیدگی کد برنامه و برخی ناهنجاری‌های آزمایش‌اند و می‌توان آن‌ها را نادیده گرفت.

بهبود کارایی هنگام خواندن دادهٔ FILESTREAM با چند Container نیز دیده می‌شود. در چند مورد، هنگام خواندن فایل ۱ مگابایتی، Throughput خواندن پنج برابر بهتر بود.

FileTable

FileTable نوع جدیدی از جدول کاربر است که در پایگاه‌دادهٔ Database Engine ساخته می‌شود. شِمای ثابتی دارد و شامل FILESTREAM و ویژگی‌های فایل است. کاربران می‌توانند Index، Constraint و Trigger تعریف کنند، اما ستون‌ها و Constraintهای تعریف‌شده توسط سیستم قابل تغییر یا حذف نیستند. مدیر پایگاه‌داده می‌تواند برای سناریوهای Bulk Load و اشکال‌زدایی، Constraintها را موقتاً غیرفعال کند. هر ردیف جدول نمایندهٔ یک فایل یا دایرکتوری است و یکپارچگی درخت با Constraintهای سیستمی حفظ می‌شود، زیرا برای کارکرد مطابق انتظار NTFS باید معناشناسی Windows اعمال شود.

FileTable جدولی تخصصی مبتنی بر FILESTREAM است. سازمان می‌تواند فایل‌ها و سندها را در جدول‌های ویژهٔ SQL Server ذخیره کند و برنامه‌های Windows بدون هیچ تغییری آن‌ها را مانند فایل‌های فایل‌سیستم ببینند؛ هم‌زمان نمای Server Message Block یا SMB Share و سازگاری کامل با برنامه‌های Win32 فراهم است. FileTable راهی مؤثر برای رفع موانع ذخیرهٔ داده‌های بدون ساختارِ موجود روی File Serverها در SQL Server است.

پیش‌نیازهای FileTable

برای استفاده از FileTable باید FILESTREAM در سطح نمونهٔ Database Engine فعال باشد، Nontransactional Access در سطح پایگاه‌داده فعال شود و یک Directory برای FileTableهای همان پایگاه‌داده تعیین گردد.

فعال‌کردن FILESTREAM روی نمونهٔ SQL Server

1. Start، سپس All Programs، Microsoft SQL Server 2012 و SQL Server Configuration Manager را انتخاب کنید.
2. در پنل چپ، SQL Server Services را انتخاب کنید.
3. روی نمونهٔ موردنظر راست‌کلیک و Properties را باز کنید.
4. در زبانهٔ FILESTREAM گزینهٔ Enable FILESTREAM For Transact-SQL Access را فعال کنید.
5. Enable FILESTREAM For File I/O Access را فعال کنید تا دادهٔ FILESTREAM از Windows خوانده و نوشته شود؛ سپس نام Share ویندوز را در Windows Share Name وارد کنید.
6. برای دسترسی Remote Clientها به دادهٔ FILESTREAM از Share، گزینهٔ Allow Remote Clients Access To FILESTREAM Data را فعال کنید.
7. Apply و سپس OK را بزنید.

سپس در SQL Server Management Studio:

1. New Query را برای نمایش Query Editor انتخاب کنید.
2. کد زیر را وارد کنید:

EXEC sp_configure filestream_access_level, 2
    RECONFIGURE

3. Execute را انتخاب کنید.
4. سرویس SQL Server را Restart کنید.

فعال‌کردن Directory Name و Nontransactional Access در سطح پایگاه‌داده

1. در Object Explorer به نمونه‌ای متصل شوید که قرار است FileTable در آن ساخته شود.

2. پوشهٔ Databases را باز کنید، روی پایگاه‌دادهٔ موردنظر راست‌کلیک و Properties را انتخاب کنید. پایگاه‌دادهٔ نمونه FileTableExampleDB است.
3. صفحهٔ Options را باز کنید.
4. در FILESTREAM Directory Name نامی مانند FileTableExampleDir وارد کنید.
5. در FILESTREAM Non-Transacted Access گزینهٔ Full یا ReadOnly را انتخاب کنید.
6. OK را بزنید.

راه دیگر، استفاده از Transact-SQL زیر است:

USE [master]
    GO
    ALTER DATABASE [FileTableExampleDB] SET FILESTREAM( NON_TRANSACTED_ACCESS = FULL, DIRECTORY_NAME
     = N'FileTableExampleDir' ) WITH NO_WAIT
    GO

پیکربندی FILESTREAM Filegroup و فایل پایگاه‌داده و تعیین Directory برای FileTable

اگر FILESTREAM Filegroup و فایل پایگاه‌داده قبلاً پیکربندی نشده‌اند، این مرحلهٔ اختیاری را انجام دهید. در مثال زیر نام Filegroup برابر FileTableExampleDBFileStreamFG و نام فایل دادهٔ FILESTREAM برابر FileTableExample_FilestreamFile است و فایل در c:\temp قرار می‌گیرد:

USE [master]
    GO
    ALTER DATABASE [FileTableExampleDB]
    ADD FILEGROUP [FileTableExampleDBFilestreamFG] CONTAINS FILESTREAM
    GO
    ALTER DATABASE [FileTableExampleDB]
    ADD FILE ( NAME = N'FileTableExampleDB_FilestreamFile',
     FILENAME = N'C:\Temp\FileTableExampleDB_FilestreamFile' ) TO FILEGROUP
     [FileTableExampleDBFilestreamFG]
    GO
    USE [FileTableExampleDB]
    GO
    IF NOT EXISTS (SELECT name FROM sys.filegroups WHERE is_default=1
    AND name = N'FileTableExampleDBFilestreamFG')
    ALTER DATABASE [FileTableExampleDB]
    MODIFY FILEGROUP [FileTableExampleDBFilestreamFG] DEFAULT
    GO
    USE [FileTableExampleDB]
    GO
    ALTER DATABASE [FileTableExampleDB] REMOVE FILE [FIleTableExampleDBFilestreamFile]
    GO

ایجاد FileTable

1. در Object Explorer پایگاه‌دادهٔ موردنظر را انتخاب کنید.
2. اشیای آن را باز، روی Tables راست‌کلیک و New FileTable را انتخاب کنید.
3. پنجرهٔ Script جدیدی با Template قابل سفارشی‌سازی باز می‌شود.
4. از گزینهٔ Specify Values For Template Parameters در منوی Query برای سفارشی‌کردن آسان Script استفاده کنید.

یا با دستور زیر FileTableای به نام FileTable01 بسازید:

Use FileTableExampleDB
    GO
    CREATE TABLE FileTable01 AS FILETABLE
    GO

کپی‌کردن سندها و فایل‌ها به FileTable

سندها و فایل‌ها را در Windows Explorer به FileTable جدید کپی کنید. این کار با Cut/Paste سنتی، Drag کردن فایل‌ها یا Transact-SQL ممکن است. در مثال کتاب دو فایل Paint و دو سند Microsoft Word به FileTable کپی شده‌اند.

مشاهدهٔ سندها از طریق FileTable در SSMS

روی FileTable ایجادشده یک Query از نوع SELECT * اجرا کنید. پنجرهٔ نتایج چهار سند کپی‌شده به SMB Share را نمایش می‌دهد.

مدیریت FileTable

مدیریت و ایمن‌سازی FileTable شبیه جدول سنتی در Database Engine است. دادهٔ FileTable از عملیات Backup و Restore و همچنین SQL Server 2012 AlwaysOn Availability Groups برای دسترس‌پذیری بالا و بازیابی پس از فاجعه پشتیبانی می‌کند.

جست‌وجوی تمام‌متن

برای بهبود Full-Text Search در SQL Server 2012 سرمایه‌گذاری زیادی انجام شده است. این قابلیت از نظر کارایی و مقیاس بهتر شده و قابلیت‌های جدیدی از جمله جست‌وجوی شباهت معنایی دارد. Full-Text Search اکنون به بیش از ۱۰۰ میلیون سند مقیاس می‌یابد و بعضی آزمایش‌ها به ۳۵۰ میلیون سند رسیده‌اند. کارایی Query سنتی تمام‌متن تقریباً هفت تا ده برابر نسخه‌های قبلی است. بدترین زمان پاسخ Query در Corpus بزرگی با ۳۵۰ میلیون سند کمتر از سه ثانیه گزارش شده است. پیاده‌سازی داخلی بهتر، Planهای بهتر Query و جلوگیری از مسدودکردن به‌روزرسانی Indexها توسط Queryها از دیگر بهبودهای معماری‌اند.

قابلیت‌های جدید جست‌وجوی تمام‌متن در سه حوزه قرار می‌گیرند:

• Property Search: در نسخه‌های قبلی هنگام جست‌وجو کل سند بررسی می‌شد و جست‌وجوی کلیدواژه فقط در عنوان یا Property خاص ممکن نبود. در SQL Server 2012 با ساخت Full-Text Index می‌توان جست‌وجوی محدود به Property انجام داد.

• Property Search، ادامه: Propertyهایی مانند نام نویسنده یا عنوان اثر با ساخت Search Property List و انتخاب Propertyهای قابل جست‌وجو، قابل جست‌وجو می‌شوند. بعضی Propertyها فقط در انواع سند خاص، مانند ستون دودویی varbinary، varbinary(max) یا image قابل جست‌وجو هستند.
• Customizable Near: عملگر Custom Proximity اجازه می‌دهد فاصلهٔ مجاز میان اصطلاح‌های جست‌وجو و ترتیب آن‌ها تعیین شود. برای نمونه می‌توان سندهایی را یافت که «cognition» و «psychology» حداکثر سه واژه با هم فاصله دارند، یا الزام کرد «Ross» پیش از «Mistry» بیاید.

مثال نخست فاصلهٔ پنج Token را تعیین می‌کند:

select * from FullTextTable
    where contains(*, 'near((test, Space), 5,false)')

اگر جست‌وجوی نخست موفق نبود، پارامتر حداکثر فاصله را مثلاً از ۵ به ۷ تغییر دهید:

select * from FullTextTable
    where contains(*, 'near((test, Space), 7,false)')

در مثال آخر علاوه بر فاصله، ترتیب اصطلاح‌ها نیز اهمیت دارد و پارامتر Match Order از false به true تغییر می‌کند:

select * from FullTextTable
    where contains(*, 'near((test, Space), 5,true)')

• Word Breakerهای جدید: Word Breakerها و Stemmerهای مورد استفادهٔ جست‌وجوی تمام‌متن و معنایی به‌طور کامل به‌روز شده‌اند. پس از Upgrade باید Full-Text Indexهای موجود دوباره Populate شوند تا سازگاری میان محتوای Index و نتایج Query حفظ شود.

جست‌وجوی معنایی آماری

Statistical Semantic Search با ارائهٔ بینش معنایی از محتوای متنی، Full-Text Search را گسترش می‌دهد. جست‌وجوی تمام‌متن واژه‌های مشخص را پیدا می‌کند، اما جست‌وجوی معنایی آماری با استفاده از آمار، عبارت‌های کلیدی مرتبط را استخراج می‌کند تا معنای سندها و شباهت میان آن‌ها را تشخیص دهد. این قابلیت بینش عمیقی از سندهای بدون ساختار فراهم می‌کند.

محتوای بدون ساختار می‌تواند در یک یا چند پایگاه‌دادهٔ Database Engine ذخیره شود و سه تابع Rowset در Transact-SQL نتایج جست‌وجوی معنایی را استخراج می‌کنند.

اکنون می‌توان استخراج خودکار Tag، کشف محتوای مرتبط و ناوبری سلسله‌مراتبی میان محتوای مشابه را به برنامه افزود. برای نمونه، با Query گرفتن از Key Phrase Index می‌توان Taxonomy یک سازمان یا مجموعهٔ سندها را ساخت. همچنین می‌توان Document Similarity Index را برای یافتن رزومه‌های متناسب با شرح شغل Query کرد.

پیش از Index کردن سندها با Semantic Search، سندها باید در پایگاه‌دادهٔ SQL Server ذخیره شوند. قابلیت FileTable و FILESTREAM در Microsoft SQL Server 2012 پیش‌نیاز این کار است.

پیکربندی Semantic Search

مدیر پایگاه‌داده باید مطمئن شود قابلیت Full-Text And Semantic Extractions For Search نصب شده است. برای بررسی نصب از دستور زیر استفاده کنید:

Select SERVERPROPERTY(‘IsFullTextInstalled’);
    GO

خروجی ۱ نشان می‌دهد قابلیت نصب است و خروجی ۰ یعنی نصب نشده است. در صورت نبود قابلیت، Setup را اجرا و آن را به نمونهٔ موجود اضافه کنید. در صفحهٔ Feature Selection گزینهٔ Full-Text And Semantic Extractions For Search را انتخاب کنید.

گام بعد نصب Semantic Language Statistics Database است؛ وابستگی خارجی‌ای که هنگام نصب قابلیت Full-Text And Semantic Extractions For Search خودکار پیکربندی نمی‌شود. برای بررسی وجود آن از دستور زیر استفاده کنید:

SELECT * FROM sys.fulltext_semantic_language_statistics_database;
    GO

مراحل نصب:

1. رسانهٔ SQL Server 2012 را وارد و فایل SemanticLanguageDatabase.msi را پیدا کنید. بسته به نسخهٔ SQL Server، نسخهٔ ۳۲ یا ۶۴ بیتی را انتخاب کنید.
2. روی فایل MSI دوبار کلیک کنید.
3. در License Agreement شرایط را بخوانید و بپذیرید و Next را بزنید.
4. در Feature Selection مسیر نصب را تنظیم و Next را بزنید.
5. Install را انتخاب کنید.
6. پس از پایان نصب Finish را بزنید.
7. فایل‌های Data و Log پایگاه‌دادهٔ Semantic Language را به نمونهٔ SQL Serverی Attach کنید که قابلیت Full-Text And Semantic Extractions For Search روی آن نصب است. پایگاه‌داده با نام semeticsdb در پوشهٔ تعیین‌شده در مرحلهٔ ۴ قرار دارد؛ مسیر پیش‌فرض c:\Program Files\Microsoft Semantic Language Database است.
8. پایگاه‌دادهٔ آمار زبان معنایی را با Stored Procedure زیر Register کنید و نام پایگاه‌دادهٔ Attachشده را بدهید:

EXEC sp_fulltext_semantic_register_language_statistics_db @dbname = N’semanticsdb’;
    GO

9. اکنون قابلیت Statistical Semantic Search آمادهٔ استفاده است.

نمونه‌های Semantic Search

سناریوهای معمول شامل یافتن عبارت‌های کلیدی یک سند، یافتن سندهای مشابه یا مرتبط و یافتن عبارت‌هایی است که دو سند را به هم مشابه می‌کنند.

یافتن عبارت‌های کلیدی یک سند

تابع SEMANTICKEYPHRASETABLE عبارت‌های کلیدی سند نمونه را بازیابی می‌کند. بر اساس اهمیت آماری به هر عبارت امتیاز داده می‌شود و همان امتیاز ترتیب گزارش را تعیین می‌کند.

SET @Title = 'Sample Document.docx'
    SELECT @DocID = DocumentID
        FROM Documents
        WHERE DocumentTitle = @Title
    SELECT @Title AS Title, keyphrase, score
        FROM SEMANTICKEYPHRASETABLE(Documents, *, @DocID)
        ORDER BY score DESC

یافتن سندهای مشابه یا مرتبط

تابع SEMANTICSIMILARITYTABLE سندهای مشابه یا مرتبط با سند نمونه را می‌یابد. نتیجه بر پایهٔ میزان شباهت امتیازدهی و رتبه‌بندی می‌شود.

SET @Title = 'Sample Document.docx'
    SELECT @DocID = DocumentID
        FROM Documents
        WHERE DocumentTitle = @Title
    SELECT @Title AS SourceTitle, DocumentTitle AS MatchedTitle,
            DocumentID, score
        FROM SEMANTICSIMILARITYTABLE(Documents, *, @DocID)
        INNER JOIN Documents ON DocumentID = matched_document_key
        ORDER BY score DESC

یافتن عبارت‌هایی که سندها را مشابه یا مرتبط می‌کنند

Query زیر عبارت‌های کلیدی عامل شباهت دو سند نمونه را می‌گیرد و نتیجه را بر اساس وزن هر عبارت به‌ترتیب نزولی نمایش می‌دهد. این Query تابع SEMANTICSIMILARITYDETAILSTABLE را فراخوانی می‌کند.

SET @SourceTitle = 'first.docx'
    SET @MatchedTitle = 'second.docx'
    SELECT @SourceDocID = DocumentID FROM Documents WHERE DocumentTitle = @SourceTitle
    SELECT @MatchedDocID = DocumentID FROM Documents WHERE DocumentTitle = @MatchedTitle
    SELECT @SourceTitle AS SourceTitle, @MatchedTitle AS MatchedTitle, keyphrase, score
        FROM semanticsimilaritydetailstable(Documents, DocumentContent,
            @SourceDocID, DocumentContent, @MatchedDocID)
        ORDER BY score DESC

بهبودهای دادهٔ مکانی

دادهٔ مکانی معمولاً موقعیت جغرافیایی عارضه‌ها و مرزها نسبت به زمین، از جمله خشکی‌ها، اقیانوس‌ها و عارضه‌های طبیعی یا ساخته‌شده را توصیف می‌کند. این داده به‌صورت مختصات و Topology در قالب Raster یا Vector ذخیره و روی نقشه نمایش داده می‌شود.

SQL Server 2008 نوع‌های دادهٔ geometry و geography را برای ذخیرهٔ دادهٔ برداری مکانی پشتیبانی می‌کرد. Methodها و Propertyهای این نوع‌ها ساخت، مقایسه، تحلیل و بازیابی دادهٔ مکانی را ممکن می‌ساختند. SQL Server 2012 این پشتیبانی را به‌ویژه از نظر نوع‌های مکانی و کارایی بهبود می‌دهد.

سناریوهای دادهٔ مکانی

سناریوهای رایج کسب‌وکار شامل توسعه و تحلیل املاک، مدیریت و توسعهٔ پایگاه مشتریان، تحلیل اثرات محیط‌زیستی و برنامه‌ریزی، تحلیل مالی و اقتصادی جوامع، برنامه‌ریزی و تحلیل توسعهٔ دولتی، بخش‌بندی و تحلیل بازار و طراحی و تحلیل پژوهش‌های علمی است.

عارضه‌های مکانی پشتیبانی‌شده در SQL Server

جدول ۵-۱ انواع برداری پشتیبانی‌شده در SQL Server 2008 را نشان می‌دهد. این نوع‌ها با ISO 19125 و Open Geospatial Consortium Simple Features for Open SQL سازگارند.

دادهٔ Raster مانند تصویر ماهواره‌ای و عکس هوایی دیجیتال در SQL Server 2008 به‌عنوان دادهٔ بدون ساختار پشتیبانی و به‌شکل BLOB ذخیره می‌شد، اما معناشناسی را نمی‌توان مستقیماً از این داده استخراج کرد.

بهبودهای نوع مکانی

SQL Server 2012 زیرنوع‌های جدیدی برای geometry و geography معرفی می‌کند که از قطعه‌های قوس دایره‌ای پشتیبانی می‌کنند: Circular String، Compound Curve و Curve Polygon. تمام Methodها از قوس دایره‌ای، از جمله قوس روی Ellipsoid، پشتیبانی می‌کنند.

Circular String

Circular String دست‌کم با سه نقطه تعریف می‌شود. نقطهٔ اول و سوم آغاز و پایان خط‌اند و مختصات دوم قوس خط را تعیین می‌کند. نقطهٔ سوم می‌تواند Circular String دیگری را متصل کند و در این حالت همان نقطه، نخستین نقطهٔ رشتهٔ بعدی می‌شود. Circular Stringهای متصل معمولاً زمانی معتبرند که تعداد نقاط فرد باشد.

DECLARE @g GEOGRAPHY;
    SET @g = GEOGRAPHY::STGeomFromText('
      CIRCULARSTRING(0 -23.43778, 0 0, 0 23.43778)
    ',4326);

DECLARE @g GEOGRAPHY;
    SET @g = GEOGRAPHY::STGeomFromText('
      COMPOUNDCURVE(
        CIRCULARSTRING(0 -23.43778, 0 0, 0 23.43778),
        CIRCULARSTRING(0 23.43778, -45 23.43778, -90 23.43778),
        CIRCULARSTRING(-90 23.43778, -90 0, -90 -23.43778),
        CIRCULARSTRING(-90 -23.43778, -45 -23.43778, 0 -23.43778))
    ',4326);

Compound Curve

Compound Curve مجموعه‌ای از Circular Stringها یا ترکیبی از Circular String و Line String است. نقطهٔ پایانی هر رشته باید نقطهٔ آغاز رشتهٔ بعدی باشد. در نمونهٔ زیر Line Stringها Keyword ندارند:

DECLARE @g GEOGRAPHY;
    SET @g = GEOGRAPHY::STGeomFromText('
      COMPOUNDCURVE(
        (0 -23.43778, 0 23.43778),     --Linear Segment*
        CIRCULARSTRING(0 23.43778, -45 23.43778, -90 23.43778),
        (-90 23.43778, -90 -23.43778), --Linear Segment*

    CIRCULARSTRING(-90 -23.43778, -45 -23.43778, 0 -23.43778))
      ',4326);

Curve Polygon

Curve Polygon دست‌کم از یک Ring نمایندهٔ شکل بسته تشکیل می‌شود و می‌تواند سوراخ‌هایی به‌شکل Ringهای داخلی داشته باشد. برخلاف Polygon عادی، Ring در Curve Polygon می‌تواند Circular String، Compound Curve یا هر دو را داشته باشد. در هر Ring نقطهٔ پایان هر رشته باید نقطهٔ آغاز رشتهٔ بعدی باشد.

DECLARE @g GEOGRAPHY;
    SET @g = GEOGRAPHY::STGeomFromText('
      CURVEPOLYGON(
        COMPOUNDCURVE(
          (0 -23.43778, 0 23.43778),
          CIRCULARSTRING(0 23.43778, -45 23.43778, -90 23.43778),
          (-90 23.43778, -90 -23.43778),
          CIRCULARSTRING(-90 -23.43778, -45 -23.43778, 0 -23.43778)
        )
      )
    ',4326);

بهبودهای مکانی دیگر

این فصل مهم‌ترین بهبودها را در سطح بالا بررسی کرد. Whitepaper سی‌صفحه‌ای «New Spatial Features in SQL Server 2012» جزئیات کامل‌تری دارد. موضوع‌های دیگر عبارت‌اند از:

• Spatial Index: Autogrid Spatial Index، Hint جدید Spatial Index، فشرده‌سازی Spatial Index و زمان بهتر Create Spatial Index برای دادهٔ نقطه‌ای.
• نوع‌های مکانی: قوس‌های دایره‌ای جدید، Methodها و Aggregateهای جدید یا به‌روزشده برای همهٔ نوع‌ها، دقت بهتر و تغییرهای ویژهٔ نوع Geography.

• کارایی: Plan جدید Nearest-Neighbor Query؛ بهینه‌سازی Relationها برای Point Operatorها؛ بهینه‌سازی STBuffer؛ Stored Procedureهای کمکی مکانی جدید؛ بهبودهای عمومی Engine مرتبط با نوع‌های مکانی؛ و تغییرهای کتابخانهٔ Client-Side.

Extended Events

SQL Server Extended Events سامانه‌ای عمومی برای مدیریت رویدادهای سرور است. رویدادهای زیر در SQL Server 2012 برای هم‌بسته‌کردن داده‌های SQL Server و، در شرایطی، داده‌های سیستم‌عامل و برنامه‌های پایگاه‌داده معرفی شده‌اند:

• page_allocated: فیلدهای worker_address، number_pages، page_size، page_location، allocator_type، page_allocator_type و pool_id.
• page_freed: همان مجموعه فیلدها شامل آدرس Worker، تعداد و اندازهٔ صفحه، محل صفحه، نوع Allocator و Pool ID.
• allocation_failure: فیلدهای worker_address، failure_type، allocation_failure_type، resource_size، pool_id و factor.

رویدادهای زیر نیز برای عملکرد بهتر تغییر کرده‌اند:

• resource_monitor_ring_buffer_record: فیلدهای single_pages_kb و multiple_pages_kb حذف و target_kb و pages_kb اضافه شده‌اند.
• memory_node_oom_ring_buffer_recorded: فیلدهای single_pages_kb و multiple_pages_kb حذف و target_kb و pages_kb اضافه شده‌اند.