Бази даних в Семантичної павутині

1. Наповнюючи Семантичну павутину
2. моделювання
3. Погляд у майбутнє

Уже два десятиліття тому було ясно, що експоненціальне зростання обсягу даних, що зберігаються в WWW, призведе
до неможливості їх обробки традиційними методами за участю людини. Згодом це стимулювало інтерес до ідеї Semantic Web, яка запропонувала ряд форматів для зберігання інформації і перш за все RDF (Resource Description Framework). Використання RDF зараз заохочують пошукові гіганти: слідом за Yahoo! і компанія Google недавно оголосила про підтримку структурованих даних (RDF і мікроформати) для підвищення інформативності результатів пошуку.

На сьогоднішній день створення інформаційних систем не обов'язково починається з нуля: розробники звільнені від виконання завдання зберігання і швидкого конкурентного доступу до великих наборів даних і можуть скористатися наявною СУБД, створивши в ній необхідні сутності та структури, зосередивши основні зусилля на реалізації сервісів, що надаються новою системою.

Більшість нинішніх СУБД засновані на реляційній моделі даних, а формат RDF, по суті, також є визначенням моделі даних, але зручною для автоматичної машинної обробки і націленої насамперед на використання в WWW. У RDF інформація представлена ​​не в таблицях, а в наборах трійок «суб'єкт-властивість-об'єкт». Кожен з елементів трійки є ресурсом, яким присвоєно ідентифікатор Uniform Resource Identifier, об'єкт також може бути літералом в форматі Unicode. Використовуючи URI, окремі трійки можуть зливатися в єдині RDF-графи, що спрощує інтеграцію розподілених джерел інформації. RDF-графи можуть включати не тільки явно записані, але і логічно виведені трійки. Цю можливість забезпечують розширення RDF - RDF Schema і OWL (Web Ontology Language). Доступ до RDF виконується за допомогою мови запитів SPARQL (SPARQL Protocol and RDF Query Language), деякі аспекти якого схожі з SQL.

Чи означає поширення RDF відмова від звичних баз даних? Позитивна відповідь міг би розцінюватися як найбільша перешкода на шляху Semantic Web, але, на щастя, впровадження RDF не тільки не відкидає прийняті сьогодні бази даних, але і може отримати від них вигоду. Теоретично при створенні нової інформаційної системи можна кожного разу вирішувати, як зберігати RDF-дані, проте одним з переваг RDF є наявність різних засобів зберігання даних, як в основній пам'яті, так і на дисках, а також програмних інтерфейсів, що спрощують створення таких сховищ.

На зорі Semantic Web завдання обробки великих наборів RDF-даних не стояла так гостро, як проблема їх публікації, і не дивно, що перші з'явилися програмні засоби були націлені на роботу з RDF-даними, цілком поміщається в основну пам'ять. Розробників більше залучали питання організації логічного висновку інформації для виразів мови OWL, засновані на методах, традиційних в дескриптивних логіках. У числі таких інструментів можна, наприклад, назвати комерційний RacerPro, пропонований компанією Franz, і відкритий Pellet. Також з'явилося середовище Jena, що надає програмний інтерфейс, що спрощує створення семантичних додатків. Цих коштів було достатньо для швидкого створення невеликих інформаційних додатків, однак залишалося невирішеним питання масштабування, викликаний передчуттям появи у Всесвітній павутині великих обсягів RDF-даних. Як наслідок, з'явилися комерційні та відкриті RDF-сховища.

У середовищі Jena починаючи з версії 1.3 підтримується довготривале зберігання моделей в реляційних базах даних, ця ж можливість є і у відкритому середовищі Sesame . У названих засобах передбачається, що обробка даних і логічний висновок виконуються в основній пам'яті, що означає слабку зв'язаність з базою даних, але краща ефективність і масштабованість виконання запитів досягаються при використанні коштів, що спираються на можливості СУБД для логічного висновку нових фактів. Наприклад, в набір засобів і сховищ HAWK (swat.cse.lehigh.edu/projects/index.html#hawk) включені різні моделі зберігання в пам'яті або в базі даних, з логічним висновком або без нього. У їх число входить використовує бази даних і виконує висновок на основі дескриптивних логік модель DLDB (Description Logic Data Base), що дозволяє зберігати RDF-дані в Microsoft Access, PostgreSQL або MySQL, покриваючи частину конструкцій OWL. Іншим прикладом делегування завдання логічного висновку СУБД є система Owlgres, що використовує PostgreSQL. Прискорення запитів досягається за рахунок декількох факторів, включаючи скорочення передач даних між базою даних і додатком, а також мінімізацію використання погано придатних для відповіді на запити традиційних алгоритмів дескриптивних логік.

Ще більшої ефективності можна добитися, виключивши взаємодію між зовнішнім програмним засобом і СУБД. Підтримка операцій вибірки і зміни RDF-даних в СУБД робить їх доступними для користувача бази даних. Тим самим стає можливим одночасний доступ до звичайних таблиць і завантажених RDF-графам. Подібна функціональність реалізована, наприклад, в СУБД Oracle.

Варто, однак, розуміти, що розробникам RDF-сховищ доводиться знаходити компроміс між виразністю підтримуваних діалектів OWL і ефективністю, масштабованість зберігання і доступу до RDF-даних. Зазвичай кошти, слабо пов'язані з базою даних, підтримують більше конструкцій OWL, але для більш обмежених наборів даних, ніж тісніше пов'язані або інтегровані рішення. Вибір сховища може проводитися на основі потреб конкретного завдання і наявної СУБД. Допомогти у виборі може порівняння засобів на основі контрольних завдань, таких як LUBM ( Lehigh University Benchmark ) Або SP2Bench ( SPARQL Performance Benchmark ).

Наповнюючи Семантичну павутину

На ранніх етапах розвитку Semantic Web найважливішим завданням була публікація RDF-даних, і завдяки суворій структурі реляційні бази даних розглядалися як відмінне джерело RDF. Крім того, до реляційних даних, представлених в RDF, застосовні різні семантичні технології, зокрема вирішується завдання інтеграції різнорідних баз даних, що розглядається в Oracle в якості варіанту використання Semantic Web на рівні підприємства. Також може бути вирішена проблема пошукової доступності інформації з Deep Web - контенту, доступного тільки динамічно через Web-форми і Неіндексований пошуковими движками.

Актуальність публікації RDF-даних з реляційних таблиць підкреслює створення в рамках W3C спеціальної групи RDB2RDF (Relational Database to RDF Mapping), в завдання якої входить дослідження, класифікація і стандартизація методів відображень. Група на початку 2009 року представила детальний огляд існуючих методів.

У більшості методів таблиці відображаються в класи OWL, властивості яких визначаються стовпцями таблиці. Деякі таблиці також можуть представлятися у вигляді властивостей, а не класів, якщо вони задають відносини між рядками інших таблиць. Елементи класів і значення властивостей можуть генеруватися один раз при відображенні (такий метод називають RDF-дампом) або на вимогу, тобто при виконанні запиту. В останньому випадку результатом відображення є не фізичний, а віртуальний RDF-граф. Кожен з методів має і достоїнствами, і недоліками:

• RDF-дампи можуть використовуватися в подальшому незалежно від СУБД або ж служити в якості резервної копії бази даних;

• виконання запитів до RDF-дампи здійснюється швидше, ніж до віртуальних графам, але зате важче відстежувати їх відповідність поточного вмісту бази даних при її змінах.

Існують і інші характеристики, за якими розрізняються методи. Наприклад, в тому, як класи ставляться у відповідність таблицями: створюються нові класи або беруться з деякою OWL-онтології. Відображення джерел в існуючу глобальну онтологію складніше, ніж створення локальних онтологій, але корисно при інтеграції різнорідних джерел інформації. Між локальними і глобальної онтологіями також може бути встановлено відповідність для забезпечення інтеграції інформації.

Наведемо кілька прикладів. декларативний мову D2RQ використовується в сервері D2R Server (Database to RDF) для доступу до віртуальних RDF-графам. У сервері Virtuoso компанії OpenLink Software реалізована функціональність автоматизованої публікації RDF по базі даних. В SPASQL , Назва якого утворено злиттям абревіатур SPARQL і SQL, робилася спроба реалізації запитів SPARQL над базами даних MySQL. Існуючі методи відображень в основному є науковими розробками, однак їх кількість, а також інтерес до даного питання з боку W3C дають надію на те, що методи будуть розвиватися. У число питань, які повинні вирішуватися при цьому, входять наступні: як забезпечувати права доступу до RDF-даних, отриманих з таблиць; як враховувати при відображенні обмеження цілісності? Обмеження можуть бути корисні в різних випадках, включаючи семантичну оптимізацію запитів SPARQL і створення резервних копій баз даних. Однак їх створення пов'язано з труднощами, які проявляються при моделюванні.

моделювання

Мова OWL був спроектований спеціально для опису довільної предметної області, проте різні галузі знань часто пред'являють суперечать один одному вимоги до формального мови свого подання. Зокрема, такий конфлікт виник між припущеннями, прийнятими у Всесвітній павутині, для якої призначений OWL, і в базах даних. У Semantic Web не робиться використовується в базах даних припущення про закритість світу, згідно з яким будь-яка не включена в базу інформація вважається неправильною. Воно застосовується для Всесвітньої павутини, в якій документи можуть бути тимчасово недоступні або не знайдені, що зовсім не означає їх помилковості. Також в базах даних часто передбачається унікальність імен об'єктів, але заборона ідентифікації однакових ресурсів різними URI зробив би практично неможливою децентралізовану розподілену публікацію інформації та інтеграцію різних її джерел.

Цей конфлікт не позначається, коли потрібно представити в RDF тільки дані з таблиць, але впливає при використанні в відображеннях інформації, що містяться в обмеженнях баз даних, або при використанні OWL для моделювання баз даних. На перший погляд здається, що досить уявити таблиці як класи OWL, їх стовпці - як властивості, а для специфікації типів значень стовпців використовувати типи даних XML Schema. Навіть те, що стандарт OWL і більшість реалізують його систем підтримують тільки два обов'язкових типу даних - строковий і цілочисельний, не є серйозною проблемою, так як в OWL 2 їх список планується розширити.

Розглянемо, як позначається конфлікт при моделюванні. Нехай, наприклад, проектується база даних системи резервування авіаквитків, в якій визначено дві таблиці, Замовлення і Клієнт. Нехай діє обмеження, що будь-яке замовлення зроблений одним клієнтом. Дане обмеження потім може бути реалізовано як зовнішній ключ між таблицями, а в UML воно визначається створенням асоціації між класами і зазначенням для неї кратності відповідної ролі, що дорівнює одиниці. В OWL також є можливість визначення так званих обмежень властивостей, в тому числі обмежень кардинальності. Зокрема, в класі Замовлення може бути визначено властивість заброньовано, відповідне аксіомі:

SubClassOf (Замовлення intersectionOf (restriction (заброньовано cardinality (1)) restriction (заброньовано allValuesFrom (Клієнт)))

Дана аксіома задає умову, за якою всі елементи класу Замовлення мають рівно одне значення властивості заброньовано, яке в свою чергу належить класу Клієнт. Аксіома, здавалося б, моделює бажане обмеження, але тут приховані підводні камені. Нехай бронь123 - елемент класу Замовлення, що має два значення властивості заброньовано - Михайло і Майкл. Проектувальник баз даних, який записав вищевказану аксіому, може очікувати, що така ситуація є неприпустимою. Однак, оскільки в OWL не робиться припущення про унікальність імен, замість виявлення помилки буде зроблено висновок, що Михайло і Майкл ідентифікують одного і того ж клієнта. Більш того, аксіома не перешкоджає і наявності об'єктів класу Замовлення, для яких невідомо значення властивості заброньовано; в даному випадку виходячи з відкритості світу передбачатиметься, що існують безіменні об'єкти класу Клієнт, які є такими значеннями.

Виключити таке несподіване поведінку можна тільки зміною парадигми OWL або архітектури Semantic Web, але подібні зміни будуть суперечити природі Всесвітньої павутини і тому мають мало шансів на успіх. Однак проблема з моделюванням може вирішуватися на більш високому рівні архітектури, на рівні Правил або за допомогою мови запитів SPARQL. Зокрема, можна сформулювати запит на пошук всіх замовлень, заброньованих більш ніж одним клієнтом або незаброньовані зовсім. Наявність таких замовлень означає неузгодженість бази даних.

Погляд у майбутнє

Використання технологій Semantic Web не означає відмови від звичних реляційних баз даних, однак розробка семантичних технологій не має обмежуватися тільки технологіями традиційних СУБД, тим більше що звичні таблиці, що зберігають інформацію по рядках, не завжди є кращим вибором для Web. Зокрема, для електронної комерції або новинних порталів краще може підходити вертикальна схема зберігання даних у вигляді таблиці з трьома стовпцями, відповідними ідентифікатору об'єкту, імені та значенням його атрибута.

Майкл Стоунбрейкер заявляє , Що з часів появи System R, від якої беруть початок сучасні СУБД, відбулися істотні зміни в апаратурі, цільових ринках і інтерфейси доступу, але архітектура СУБД з тих пір не переглядалася. Традиційна модель даних вже перестає бути вирішенням усіх проблем, і настає час для активних досліджень нових моделей даних, призначених не для загальних цілей, а для використання в окремих сегментах ринку. Не можна виключати, що в майбутньому на зміну RDF-сховищ, заснованим на традиційних СУБД, прийдуть спеціалізовані RDF-СУБД, звані в числі необхідних інструментів реалізації інтелектуальних агентів в Semantic Web.

Перехід на RDF-СУБД обіцяє бути безболісним для користувачів і розробників, і основна проблема тут - забезпечення працездатності додатків, створених для доступу до SQL-орієнтованим СУБД, при взаємодії з новими RDF-сховищами. Стандартною мовою доступу до RDF є SPARQL, тому вирішення цієї проблеми може полягати в створенні надбудови над RDF-СУБД, перетворюючої SQL-запити в SPARQL, а одержувані відповіді - назад в таблиці. Ця ідея реалізується в системі R2D . Використання надбудов, подібних R2D, дозволить користувачам виконувати доступ до RDF-даних як за допомогою нової мови SPARQL, так і за допомогою звичного SQL.

* * *

Застосування семантичних технологій не вимагає відмови від існуючих, добре знайомих і широко використовуваних. Більш того, бар'єр на шляху впровадження Semantic Web допомагає подолати опора на такі технологи, як реляційні бази даних, SQL. Коли немає ніяких засобів зберігання RDF-даних, логічним видається використовувати методи і технології, які зарекомендували себе як ефективний і масштабується, цієї проблеми в різних областях. У свою чергу, семантичні технології допоможуть збільшити доступність і функціональність традиційних баз даних і Web-форм. Це не означає, що семантичні формати повинні використовуватися на всіх етапах життєвого циклу бази даних: наприклад, UML краще підходить для їх проектування, ніж OWL в нинішньому його стані. Хоча в семантичних додатках використовуються існуючі бази даних, не варто виключати, що поширення Semantic Web призведе до появи і популярності спеціалізованих RDF-сховищ, які будуть сумісні з додатками, створеними для традиційних СУБД. n

Дмитро Левшин ( [email protected] ) - співробітник ВАТ НІЦЕВТ, аспірант МДУ ім. М.В. Ломоносова (Москва).

Web, частина третя

Слідом за World Wide Web з'являється Web 2.0, а зараз вже Web 3.0 обіцяє широкому загалу семантичну революцію. Але що реально стоїть за новою технологією?