3.6. Перехід від баз даних до просторів даних: нова абстракція управління інформацією
На протязі десятиліть технології управління даними (економічною інформацією) концентрувалися на розробці систем управління реляційними базами даних. Сьогодні ж найгостріші проблеми управління інформацією походять від організацій, що використовують велику кількість різнотипних взаємозв’язаних джерел даних, але не мають можливості управляти цими просторами даних зручним, інтегрованим та обґрунтованим способом. Для розв’язання задач такого типу пропонується нова концепція – концепція просторів даних [104].
Система управління базами даних забезпечує спільний репозиторій для зберігання і повернення на запит користувача структурованих даних. СУБД підтримує набір взаємозв’язаних послуг та надає можливість розробникам приділяти основну увагу специфічним проблемам їх програм, а не тратити час на стандартні задачі, що виникають при необхідності узгодженого і ефективного управління великими об’ємами даних.
На жаль, в сучасних сценаріях управління даними не часто виникають задачі, коли усі дані можуть розміщуватися під управлінням традиційної реляційної СУБД чи якоїсь іншої моделі даних. Тому розробники часто зіштовхуються з набором слабко зв’язаних джерел даних і вимушені щоразу розв’язувати однотипні низькорівневі задачі управління даними в різнорідних колекціях. До числа таких задач відносять забезпечення можливостей пошуку та отримання даних; дотримання правил, обмежень цілісності, узгодження найменувань тощо; відслідковування походження даних; забезпечення доступності, відновлення та контролю доступу; керований розвиток даних та метаданих.
Такі проблеми виникають всюди – на підприємствах, у державних органах, наукових центрах, і навіть в персональних комп’ютерах та інших пристроях. Однак в кожному з цих сценаріїв є деякі впізнавані і контрольовані межі між даними та базовими системами. Тому можна визначити простір даних, який при забезпеченні належного управління надасть організації суттєві переваги. Отже, простір даних – це нова абстракція управління даними в описаних вище сценаріях. В якості ключової програми робіт в області управління даними пропонується [Error: Reference source not found] розробка платформ підтримки просторів даних (DataSpace Support Platforms, DSSP). DSSP забезпечує набір взаємозв’язаних послуг та гарантує розробникам можливість концентруватися на специфічних проблемах їх програм, а не на стандартних задачах, що виникають при необхідності узгодженої та ефективної роботи із взаємозв’язаними даними, які управляються роздільно.
Обговорення просторів даних та DSSP почнемо з визначення їх місця в контексті існуючих систем. На рис. 3.2 наведено класифікацію існуючих на даний час рішень управління даними [105]. Вимір “Administrative Proximity” („адміністративна близькість“) показує наскільки близькими є різні джерела даних з точки зору адміністративного управління. “Near” („близько“) означає, що джерела знаходяться під єдиним чи, по крайній мірі, координованим управлінням, а “Far” („далеко“) вказує на більш слабку координацію і, можливо, навіть повну відсутність координації. Чим ближче адміністративне управління групи джерел даних, тим сильнішими є гарантії (узгодженість, стабільність, …), які можуть бути надані системою управління даними.
Рис. 3.2. Простір рішень управління даними
Вимір “Semantic Integration” („семантична інтеграція“) є мірою того, наскільки близько можуть бути співставлені схеми різних джерел даних. Іншими словами, наскільки добре відповідають типи, імена, одиниці виміру, зміст та ін. даних в джерелах. На дальному кінці (“low”) інформація про схеми взагалі відсутня. В проміжку між “high” та “low” розміщуються різні рішення та підходи інтеграції даних, що базуються на напівструктурованих даних та контрольованих словниках. Цей вимір показує рівень, на якому можуть бути забезпечені семантично розвинуті засоби отримання (запитування) даних та маніпулювання даними над групою джерел даних, причому більш високий рівень інтеграції забезпечує більш розвинуті функціональні можливості.
Як слідує з рис. 3.2, традиційні СУБД представляють тільки одну, хоча і надзвичайно важливу, точку (DBMS) в просторі засобів управління даними. СУБД вимагають, щоб усі дані знаходилися під єдиним адміністративним управлінням і відповідали єдиній схемі. У відповідь на задоволення цих обмежень СУБД можуть забезпечити розвинуті засоби маніпулювання даними та обробки запитів зі зрозумілою і строгою семантикою, а також строгі трансакційні гарантії обновлень, паралельного доступу та довготривалого зберігання (так звані властивості “ACID” [Error: Reference source not found]).
Важливою точкою на рис. 3.2 є „Системи інтеграції даних“ (“Data Integration Systems”). Системи інтеграції даних та обміну даними традиційно призначаються для підтримки багатьох інших осмислених служб в системах просторів даних. Особливість полягає в тому, що в системах інтеграції даних вимагається семантична інтеграція до того, як можуть бути забезпечені будь-які інші послуги. Тому, хоча й відсутня єдина схема, якій відповідають усі дані, система повинна знати точні взаємозв’язки між елементами, що використовуються в кожній схемі. В результаті для створення системи інтеграції даних потрібна суттєва попередня робота.
Простори даних не є підходом до інтеграції даних – це швидше підхід співіснування даних. Мета підтримки простору даних полягає в забезпеченні базового набору функцій над усіма джерелами даних, а не в інтеграції цих даних. Наприклад, DSSP може забезпечити над усіма своїми джерелами даних пошук за ключовими словами, аналогічно тому, що забезпечують пошукові системи в звичайних операційних системах. За необхідності в більш складних операціях, таких як запити в реляційному стилі, аналіз даних чи моніторинг джерел даних, потрібно прикласти додаткові зусилля до більш тісної інтеграції цих джерел в інкрементній манері „оплати поточних рахунків“ (“pay-as-you-go”).
Аналогічна гнучкість присутня і у вимірі адміністративної близькості. Якщо є необхідність в адміністративній автономії, то DSSP не може гарантувати узгодженість, стійкість результатів операцій обновлення та ін. Для задоволення потреб в більш строгих гарантіях потрібні додаткові зусилля для досягнення згоди між власниками джерел даних та відкриття деяких інтерфейсів (наприклад, для протоколів фіксації трансакцій).
Розглянемо основні специфічні властивості систем просторів даних [Error: Reference source not found]:
DSSP повинні працювати з даними та програмами в різноманітних форматах, доступними через різні інтерфейси. Від DSSP вимагається підтримка усіх даних простору даних без будь-яких обмежень, як це буває при використанні СУБД.
Хоча DSSP забезпечує засоби роботи з даними, ті ж самі дані часто можуть бути доступними для читання та оновлення через власний інтерфейс системи, що безпосередньо управляє даними. Тому, на відміну від СУБД, DSSP не має повного контролю над своїми даними.
Можуть забезпечуватися різні рівні послуг з обробки запитів до DSSP, і в деяких випадках вони можуть повертати найкращі з можливих приблизні відповіді. Наприклад, якщо деякі джерела даних стають недоступними, DSSP може забезпечити найкращий з можливих результат на основі даних, доступних під час виконання запиту.
DSSP повинні підтримувати засоби для забезпечення більш тісної інтеграції даних простору, якщо це стає необхідним.
Логічні компоненти просторів даних. Простір даних, рис. 3.3, повинен містити усю інформацію, потрібну для конкретної організації, незважаючи на формат і місце розташування цієї інформації, а також моделювати розвинутий набір зв’язків між репозиторіями даних. Значить, простір даних моделюється як набір учасників та зв’язків.
Рис. 3.3. Приклад простору даних та компоненти системи простору даних
Учасниками простору даних є індивідуальні джерела даних: вони можуть бути реляційними базами даних, репозиторіями XML, текстовими базами даних, Web-сервісами та пакетами програмного забезпечення. Вони можуть бути в вигляді статичної інформації, що зберігається на носії чи бути потоками даних.
Деякі учасники простору даних можуть підтримувати мови запитів, а інші – бути не інтелектуальними і підтримувати тільки обмежені інтерфейси для формулювання запитів (наприклад, структуровані файли, Web-сервіси чи інші програмні пакети). Учасники можуть бути сильно структурованими (наприклад, реляційними базами даних), напівструктурованими (XML) чи повністю неструктурованми. Деякі джерела можуть підтримувати традиційні операції обновлення, тоді як інші – допускати тільки додавання (з метою архівації), а треті можуть використовуватися в режимі тільки для читання.
Простір даних повинен уміти моделювати будь-який вигляд зв’язку між двома (чи кількома) учасниками. В більш традиційному варіанті потрібно моделювати ситуації, коли один учасник є представленням чи реплікою іншого учасника, або відображати одна на другу схеми двох учасників. Однак іноді виникає необхідність в моделюванні значно ширшого набору зв’язків, наприклад, джерело А вручну утворюється з джерел В, С, або коли джерела E та F створювалися незалежно, але відображають одну і ту ж систему. Зв’язки можуть бути навіть менш конкретними, наприклад, два набори даних утворені з одного джерела даних в один і той же час.
Простори даних можуть бути вкладеними (наприклад, простір даних факультету вкладається в простір даних інституту), і вони також можуть перекриватися (наприклад простір даних обліково-фінансового факультету може містити кількох учасників факультету підприємництва). Тому простір даних повинен містити правила розмежування доступу.
Сервіси простору даних. Поряд з неоднорідністю вмістимого виникає потреба в підтримці кількох стилів доступу до контенту. Однією з основних служб простору даних є каталогізація елементів даних. Каталог – це реєстр ресурсів даних, що містить найбільш базову інформацію про кожного з них: джерело, ім’я, місце розміщення в джерелі, розмір, дата створення та власник тощо. Каталог є інфраструктурою для більшості інших сервісів просторів даних, але він також може підтримувати базовий користувацький інтерфейс перегляду простору даних.
Двома основними службами DSSP є пошук та отримання даних. Тоді як СУБД відрізняються покращеною підтримкою запитів, пошук є основним механізмом роботи кінцевих користувачів з великими колекціями незнайомих даних. Пошук є менш вимогливим, порівняно з отриманням даних, оскільки він базується на подібності, наданні користувачам ранжованих результатів та підтримці інтерактивного удосконалення, так що користувачі можуть досліджувати отриманий набір даних та інкрементно покращувати свої результати. DSSP повинні дозволяти користувачам задавати пошуковий запит та ітераційно його вдосконалювати, якщо це доцільно, до вигляду запиту в стилі бази даних. Ключовий принцип просторів даних полягає в тому, що пошук повинен бути застосований до всього вмістимого простору даних, незалежно від форматів даних.
Універсальні можливості пошуку та запитів повинні розповсюджуватися не тільки на дані, а й на метадані. Користувачі повинні мати можливість пошуку потрібних джерел даних та отримання інформації про їх складність, коректність та актуальність. DSSP також повинні містити інформацію про прогалини в своєму покритті прикладної області і підтримувати обновлення даних. Очевидно, що ефекти обновлень будуть визначатися рівнем незмінності відповідних джерел даних. Однією з основних дослідницьких проблем просторів даних є розробка та забезпечення гарантованої семантики обновлень в різнорідному середовищі з високим рівнем автономності компонентів.
Інші ключові сервіси DSSP включають моніторинг, виявлення подій та підтримку складних потоків робіт. Наприклад, може виникнути задача провести якісь обчислення при надходженні нової частини даних і розповсюдити результати цих обчислень у відповідний набір джерел даних. Аналогічно в DSSP повинні підтримуватися різні форми аналізу даних.
Не кожен учасник простору даних буде обов’язково забезпечувати інтерфейси, потрібні для підтримки усіх функцій DSSP. Тому виникне необхідність в різних розширеннях джерел даних. Джерело не обов’язково буде зберігати свої власні метадані, тому для таких джерел знадобиться незалежний репозиторій метаданих. Може виникнути необхідність у вміщенні інформації в зовнішню оболонку, створену на основі джерела чи його контексту. Наприклад, для переліку агентств зайнятості з Чернівців може знадобитися додаткова помітка „Чернівці“, для того, щоб цей перелік можна було об’єднати з аналогічними переліками з Івано-Франківська та Тернополя. Або для наукового набору даних може знадобитися накладена схема. Елементи даних в джерелі можуть збагачуватися анотаціями, рейтингами, посиланнями на елементи в інших джерелах. Для джерел, в яких відсутня власна служба нотифікації, може знадобитися підтримка відповідного моніторингу.
Системи просторів даних. Далі ми окреслимо один з можливих наборів компонентів та архітектуру системи просторів даних. Як зображено на рис. 3.3, DSSP забезпечує кілька взаємозв’язаних служб над простором даних, деякі з яких є узагальненням компонентів, що підтримуються в традиційних СУБД. Важливо пам’ятати, що на відміну від СУБД, в DSSP не передбачається наявність повного контролю над даними в просторі даних. Замість цього, DSSP дозволяє управляти даними системам-учасникам, але забезпечує новий набір служб поверх усіх цих систем, зберігаючи їх потребу в автономності. Крім того, може бути кілька DSSP, що обслуговують один і той же простір даних. Розглянемо детальніше елементи архітектури систем просторів даних.
Каталог. Каталог містить інформацію про всіх учасників простору даних та про зв’язки між ними. Каталог повинен мати можливість підтримувати різноманітні джерела та зберігати інформацію про їх структуру і можливості на різних рівнях. Зокрема, для кожного учасника каталог повинен містити схему джерела, статистичні дані, швидкість зміни, точність, можливості відповіді на запити, інформацію про власника а також дані про політику доступу і підтримки конфіденційності. Зв’язки можуть зберігатися у вигляді перетворень запитів, графів залежності, а іноді навіть у вигляді текстових описань.
За наявності такої можливості каталог повинен містити базовий реєстр елементів даних в кожному учаснику: ідентифікатор, тип, дата створення тощо. Тоді в ньому можна підтримувати базову можливість перегляду об’єднаного ресурсу усіх учасників. Хоча інтерфейс перегляду погано масштабується, його можна, як мінімум, використовувати для відповідей на запити користувачів про наявність чи відсутність елементу даних чи визначення того, які учасники зберігають документи даного типу. Можливості цього інтерфейсу можуть бути розширені за допомогою простих скриптів.
Поверх каталогу DSSP повинні підтримувати середовище управління моделями, яке дозволяє створювати нові зв’язки (наприклад, об’єднувати чи інвертувати відображення, зливати схеми та створювати єдині пердставлення кількох джерел.
Пошук та отримання даних. Цей компонент повинен забезпечувати такі можливості:
Отримання довільних даних. Користувачам повинна бути доступна можливість отрмання будь-якого елементу даних незалежно від його формату та моделі даних. Перш за все DSSP повинні підтримувати для кожного учасника запити за ключовими словами. По мірі отримання більш детальної інформації про учасника, система поступово повинна переходити до підтримки більш складних запитів. Система повинна підтримувати плавне переключення між запитами за ключовими словами, переглядом та структурованими запитами. Зокрема, при поверненні відповідей на запит за ключовими словами (чи на структурований запит) повинні пропонуватися додаткові інтерфейси запитів, що дозволяють користувачу удосконалити свій запит.
Структуровані запити. Запити в стилі баз даних повинні підтримуватися на основі спільних інтерфейсів (схем-посередників), що забезпечують доступ до кількох джерел, або ж вони можуть адресуватися до конкретного джерела даних (з використанням його власної схеми) з наміром отримати відповідь і від інших джерел (як в системах управління одноранговими даними – Peer-Data Management System). Запити можуть формулюватися на різноманітних мовах (і на основі різних моделей даних), і вони повинні, за можливості, найкращим чином переформульовуватися на інші моделі даних і схеми, забезпечуючи точні і наближені семантичні відображення.
Запити до метаданих. В системі повинен підтримуватися широкий спектр запитів до метаданих. Повинні забезпечуватися можливості: а) отримання даних про джерело відповіді чи про те, яким чином ця відповідь була отримана чи розрахована; б) забезпечення часових міток на елементах даних, що приймали участь в розрахунку відповіді; в) вказування того, які інші елементи даних в просторі даних можуть залежати від заданого елементу даних, і підтримки гіпотетичних запитів (наприклад, „Що зміниться, якщо видалити елемент даних Х“); г) можливість отримання інформації з джерел рівня недостовірної відповіді. DSSP також повинні підтримувати запити на встановлення місця розташування даних, відповідями на які є джерела даних, а не конкретні елементи даних. Наприклад, система повинна мати можливість відповідати на питання типу „Де я можу знайти дані про IBM?“ або „В яких джерелах даних міститься атрибут “salary”?“. Аналогічно, при наявності XML-документу повинна надаватися можливість запиту до XML-документів з подібною структурою і відповідним XML-перетворенням. Нарешті, при наявності фрагменту схеми чи описання Web-сервісу повинна надаватися можливість знаходження в просторі даних подібних фрагментів.
Моніторинг. Усі перелічені служби пошуку та отримання даних повинні також підтримуватися в інкрементній формі, яку можна застосовувати в реальному часі до потокових чи постійно змінюваних джерел даних. Моніторинг може бути організованим у вигляді процесу без стану, в якому елементи даних розглядаються кожен зокрема, чи у вигляді процесу з станом, в якому аналізується кілька елементів даних. Служба інкрементного моніторингу може забезпечити додаткові функції виявлення складних подій та генерації сигналів.
Локальне зберігання та індексування. DSSP повинен містити компонент зберігання та індексування для досягнення таких цілей: а) для створення асоціацій між об’єктами даних від різних учасників в результатах запиту; б) для удосконалення доступу до джерел з обмеженими власними засобами доступу; в) для забезпечення можливості виконання деяких запитів без доступу до реального джерела даних; г) для підтримки високого рівня доступності та відновлення.
Засоби індексування повинні володіти високим рівнем адаптивності до неоднорідних середовищ. В якості вхідних даних повинно прийматися довільне елементарне значення, що зустрічається в просторі даних, і повинні видаватися координати усіх об’єктів даних, в яких є таке значення, і ролі кожного його входження (наприклад, рядок в текстовому файлі, елемент шляху до файлу, значення в базі даних, елемент схеми чи тег в XML-файлі). Важливими аспектами індексу є те, що, по перше, він визначає інформацію для усіх учасників, коли деякі значення входять в декілька джерел даних (до деякої міри це узагальнює ідею індексів з’єднання). Для цієї цілі для деякої множини значень потрібно створювати спеціальні індекси. По друге, індекс повинен уміти працювати з різноманітними посиланнями на об’єкти реального світу, наприклад з різними способами задання (ідентифікації) підприємства чи людини.
Також може знадобитися кешування деяких фрагментів простору даних (вертикальні чи горизонтальні) для того щоб: а) створювати на їх основі додаткові індекси для підтримки більш ефективного доступу; б) підвищити рівень доступності даних, що зберігаються в ненадійних учасниках та в) зменшити завантаження запитами учасників, які не можуть обробляти непередбачені зовнішні запити.
Компонент розкриття. Призначення цього компоненту полягає у виявленні учасників в просторі даних, створенні зв’язків між ними та наданні допомоги адміністраторам при удосконаленні та посиленні цих зв’язків.
Виявлення учасників може відбуватися в кількох формах, наприклад у формі перегляду довідкової структури, починаючи від кореня, чи у формі пошуку координат усіх баз даних в корпоративній мережі. Компонент повинен виконувати початкову класифікацію учасників на основі їх типів та контенту. Після виявлення учасників система повинна забезпечити середовище для напівавтоматичного створення зв’язків між учасниками та удосконалення і підтримки існуючих зв’язків. Цей процес включає знаходження пар учасників, які, ймовірно, повинні бути зв’язані між собою, і потім в пропонуванні варіантів зв’язків, які пізніше перевіряються і уточнюються людиною. Нарешті, важливим є те, що компонент розкриття здійснює моніторинг змісту простору даних, для того, щоб в майбутньому можна було запропонувати нові зв’язки.
Компонент розширення джерел. У деяких учасників можуть бути відсутніми деякі потрібні функції управління даними. Наприклад, учасник може бути відомчим репозиторієм документів, єдиною службою в якому є періодичне резервне копіювання. Для таких випадків DSSP повинен мати засоби наповнення такого учасника додатковими можливостями, таким як схема, каталог, пошук за ключовими словами та моніторинг обновлень.
Цей компонент також підтримує інформацію з „доданою вартістю“, яка зберігається в DSSP, але відсутня у вихідних учасників. Така інформація може вміщувати „лексичні переходи“ між словниками, таблиці трансляції закодованих значень, класифікатори та рейтинги документів, а також анотації чи посилання, прив’язані до наборів даних чи контенту документів. Також повинна бути можливість розповсюдження такої інформації на кілька учасників. Наприклад, в базі даних настольного комп’ютера значні зусилля витрачаються на побудову зв’язків між елементами різних програм (наприклад, збереження зв’язків між презентаціями, статтями та програмами, що відносяться до одного проекту).
Хоча передбачається, що DSSP з повним набором служб повинні містити всі описані вище компоненти, деякі з них можуть бути реалізовані незалежно для досягнення деякого компромісу між затратами та отримуваними перевагами. Наприклад, можливо, що великий ВНЗ спочатку зможе собі дозволити тільки сервіс каталогу та перегляду для простору даних масштабу факультету, але і це було б значним кроком в порівнянні з використанням простого неструктурованого набору файлів. Далі можна було б додати можливості пошуку за ключовими словами в масштабах факультету чи вибраних просторах даних. Важливим є те, що DSSP допускає інкрементне інвестування, а не представляє собою монолітне рішення. Крім того DSSP повинен містити компонент адміністрування та деякий модуль, що підтримує „м’яке“ відновлення.
Проблеми, що виникають при створенні DSSP. На відміну від СУБД, в ядрі DSSP потрібна підтримка кількох моделей даних для того, щоб була змога природнім чином підтримувати якомога більше типів учасників. Моделі даних, що підтримуються в DSSP, утворюють ієрархію відповідно до їх можливостей. Кожний учасник простору даних підтримує деяку модель даних і деяку мову запитів, що відповідає цій моделі. Наприклад, на найвищому рівні ієрархії (найбільш загальному) розміщуються колекції іменованих ресурсів, можливо, з базовими властивостями – розмір, дата створення та тип (наприклад, зображення JPEG, база даних MySQL). „Запит“ до такої моделі даних відповідає тому, що зазвичай підтримується в файлових системах по відношенню до їх директорій: співставлення імен, пошук у діапазоні дат, сортування за розміром файлу тощо. На наступному рівні DSSP повинні підтримувати модель даних мультимножини слів, з чого слідує, що повинна підтримуватися можливість формулювання запитів за ключовими словами для довільного учасника простору даних.
Нижче рівня моделі мультимножини слів в ієрархії може розміщуватися модель напівструктурованих даних, що базується на помічених графах. Якщо учасник підтримує деяку структуру, повинна бути можливість формулювання простих запитів, а, можливо, і складніших запитів, що базуються на моделі напівструктурованих даних. Задача полягає в тому, що якщо в учасника є спосіб природної інтерпретації запиту, то обробник запитів повинен намагатися слідувати такій інтерпретації.
В ієрархії повинні бути присутніми і інші моделі даних: реляційна модель, XML зі схемою, RDF, WOL (Web Ontology Language). За наявності деякого середовища ключова проблема полягає в знаходженні методів інтерпретації запитів на різних мовах на учасниках, що підтримують деякі моделі. Точніше, проблема полягає в переформулюванні запиту, наданого на складній мові, для джерела, представленого на складній мові, для джерела, що підтримує більш слабку модель даних, і навпаки, переформулювання запиту, представленого на простій мові для джерела, що підтримує більш виразну модель даних та мову запитів (наприклад, запит за ключовими словами до реляційної бази даних).
Для адекватного задоволення потреб сценаріїв програм і користувачів простору даних, в DSSP вимагається підтримка більш широкого підходу до запитів. Завдяки WWW і наступаючій революції в галузі доступу людей до інформації, люди сприймають пошук, як одну з основних активностей. Користувачі комп’ютерів усвідомлюють, що суттєва частина їх роботи може бути розділена на дві частини: пошук релевантної інформації та робота зі знайденою інформацією. Може існувати багато різновидів пошуку, деякі з яких нагадують запити до баз даних (пошук квитків для здійснення подорожі, оперативна перевірка банківського балансу), а інші більш подібні до пошуку за ключовими словами (пошук потрібних документів на підприємстві чи пошук рецептів для виготовлення торта).
Тому ключовою проблемою є забезпечення інтуїтивних засобів пошуку та запиту довільної інформації. Насправді, з точки зору користувача різниця між запитом та пошуком повинна зникнути. Користувачі повинні починати з найпростіших засобів пошуку, а потім, якщо необхідно, направлятися до спеціальних інтерфейсів пошуку та запитів. На основі наявного запиту система повинна забезпечувати для користувача корисні поради відносно інших тем, які можуть бути цікавими для нього та можливостей відповідного пошуку. Потрібно також розробити інтуїтивну візуалізацію результатів, що направляє користувачів в потрібному напрямку.
Важливим компонентом побудови простору даних є розкриття його учасників та зв’язків між ними. Дуже розповсюджена проблема сьогоднішніх крупних підприємств полягає у тому, що вони навіть не знають, які джерела даних є наявними в організації. Кінцевою метою розкриття простору даних є виявлення учасників простору даних, створення зв’язків між ними та підвищення точності існуючих зв’язків між учасниками. Основними компонентами системи розкриття простору даних є: а) виявлення учасників в організації; б) напівавтоматичний засіб для кластеризації та знаходження зв’язків між учасниками; в) засіб для створення більш точних зв’язків між учасниками.
Однією з ключових властивостей просторів даних є те, що семантична інтеграція розвивається в часі і тільки там, де потрібно. Найдефіцитнішим з ресурсів, що використовується для семантичної інтеграції, є людська праця. Тому важливо, щоб DSSP знали, як повторно використовувати роботу, виконану людьми, узагальнювати її результати і використовувати їх повторно для розв’язання інших задач. У співтоваристві управління даними уже розроблено методи повторного використання людської праці при створенні семантичних відображень між джерелами даних, але це тільки перший крок. Інші приклади людської праці, яку можна повторно використовувати, включають анотації (наприклад, в створеній вручну анотації зв’язуються два елементи даних з різних джерел); тимчасові колекції даних, що створюються для розв’язання конкретної задачі (їх називають цифровими робочими середовищами); запити до даних (які дозволяють вивести деякі зв’язки, наявність яких неможливо встановити якимось іншим способом) та операції над даними (наприклад, копіювання даних із одного стовпця електронної таблиці в стовпчик іншої таблиці). Задача полягає в тому, що попередня робота повинна бути запам’ятована в системі, і її результати слід використовувати при спробах створення додаткових зв’язків між учасниками простору даних чи відповідей на запити до цього простору. Очікується, що тут будуть корисними методи машинного навчання (Machine Learning).
Ключові проблеми, що виникають при створенні компоненту DSSP локального зберігання та індексації пов’язані з неоднорідністю індексу. Індекс повинен єдиним чином індексувати усі можливі елементи даних, незалежно від того, чи це слова, що зустрічаються в тексті, значення, що зустрічаються в базі даних, чи елементи схеми одного із джерел. Крім того, в індексі повинна передбачатися можливість наявності кількох способів посилання на один і той же об’єкт реального світу. Складно підтримувати індекс в актуальному стані, особливо для учасників, що не мають механізмів повідомлення про обновлення.
Основною перевагою використання DSSP для доступу до різнорідних джерел даних є можливість робити це з деякою впевненістю в якості відповідей на запити і в стабільності результатів операцій обновлення. За наявності великого розкиду в рівнях адміністративної близькості та семантичної інтеграції джерел даних в просторі даних, традиційні гарантії, що надаються СУБД з приводу відповідей на запити часто будуть просто недосяжними. Проблема полягає в тому, як визначити придатні до реалізації, практичні та осмислені рівні гарантій обслуговування, що можуть бути забезпечені в області просторів даних. Для вирішення цієї проблеми потрібно переосмислити багато з фундаментальних принципів управління даними і ввести нові абстракції. Також знадобляться інструментальні засоби, що допомагають розробникам та користувачам розуміти неусувні компроміси в термінах якості, ефективності та контролю.
Є декілька питань відносно теоретичних обґрунтувань просторів даних. Зрозуміло, що потрібне формальне розуміння різних моделей даних, зв’язків та відповідей на запити в просторі даних. В традиційній теорії баз даних одним із основних питань є виразна потужність мови запитів. В контексті просторів даних аналогічне питання буде відноситися до виразної потужності мови запитів над множиною учасників з використанням певних властивостей зв’язків, специфікованих між ними. Питання полягає в тому, які запити можуть бути виражені над простором даних. Аналогічно, як можна розпізнати семантично еквівалентні, але синтаксично різні способи відповідей на запити?
Перспективи. На завершення коротко розглянемо кілька важливих перспектив просторів даних.
Зв’язок з іншими областями. DSSP використовує існуючі розширення методів управління даними, але важливим є також використання методів з інших областей. Розглянемо деякі з них. Оскільки в просторах даних робиться спроба надати зміст неоднорідним колекціям в просторі даних, дві переваги можна отримати з останніх робіт в області представлення знань та Semantic Web: прості, але корисні формалізми для представлення онтологій та поняття URI (Uniform Resource Identifiers) як механізму посилань на глобальні константи, відносно яких існує деяка угода між кількома постачальниками даних. Аналогічно, як зазначалося раніше, деякі операції над просторами даних по своїй суті приводять до деякої невизначеності даних, їх походження, коректності та повноти. В галузі штучного інтелекту розроблено кілька формалізмів для моделювання невизначеності, але вони володіють занадто великою виразністю. Проблема полягає в знаходженні моделей, які були б корисними, але простими, зрозумілими і здатними до масштабування.
Зрозуміло, що більшу частину даних в просторі даних буде складати неструктурований текст. Тому важливу роль при побудові DSSP будуть відігравати методи інформаційного пошуку (Information Retrieval). Важливим є те, що в складному просторі даних користувачі часто не знають що конкретно вони шукають і як інтерпретувати результати. Тому важливо, щоб вони могли ефективно візуалізувати результати пошуку та запитів для покращення направленості своїх досліджень простору даних. Тут знадобляться сучасні методи з області візуалізації інформації (Information Visualization).
Промислові перспективи. В більшій мірі поняття просторів даних зумовлено проблемами, що зараз стоять перед різними підприємствами. Зараз є багато прикладів, коли підприємства уже зробили кроки в цьому напрямку, але ці кроки є ізольованими, і є очевидна потреба в більш широкому представленні, що приведе до більш зрозумілої абстракції системи і набору методів. Наприклад, починає набирати силу корпоративна інтеграція інформації (Enterprise Information Integration). Компанії, що спеціалізуються в цій галузі, створююь системи для обробки запитів до кількох джерел даних всередині організації. Є кілька прикладів продуктів, які створюють індекси над кількома джерелами даних для досягнення цілей, розглянутих раніше (наприклад, Master Data Management, компонент продукту NetWeaver компанії SAP [106]). Існують проекти, напрямлені на розкриття джерел даних підприємства, але тільки деякі компанії вивчають різні аспекти управління корпоративними метаданими.
Отже, найгостріші проблеми управління інформацією в організаціях зараз випливають з наявності в організаціях багатьох різнотипних, але часто взаємозв’язаних джерел даних. Для розв’язання таких проблем запропонована ідея просторів даних та платформ підтримки просторів даних (DataSpace Support Platforms, DSSP). Призначенням DSSP є звільнення розробників від потреб постійної повторної реалізації основних функцій управління даними при роботі зі складними, різнорідними, взаємозв’язаними джерелами даних, аналогічно тому, як традиційні СУБД забезпечили подібні можливості для роботи із структурованими реляційними базами даних. Однак, на відміну від СУБД, DSSP не передбачає наявність повного контролю над даними в просторі даних. Замість цього, DSSP дозволяє управляти даними системам-учасникам, але забезпечує новий набір служб над усіма системами, задовольняючи їх вимоги автономності.