к.т.н. Шаховська Н. Б., Угрин Д.І.

Національний університет “Львівська політехніка”, Україна

Буковинський університет, Україна

Організація формування просторів даних туризму

Сьогодні найбільш гострі проблеми керування інформацією виростають у організацій туристичного бізнесу (наприклад, туристичних підприємств, туристичних агентств, туристичних операторів і ін.), що покладаються на велике число різнотипних, взаємозалежних джерел даних, але не спроможних управляти цими об’ємами даних зручним, інтегрованим і обґрунтованим способом. У даній статті як нова програма робіт в області керування даними пропонуються простори даних і підтримуючі їхні системи. Ця система охоплює більшу частину робіт, виконуваних у цій області сьогодні, а також включає додаткові теми досліджень.

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

Ці проблеми є глобальними – вони виникають у організаціях (великих і малих): усередині туристичних агентств і між ними, у великих туристичних спільнотах, у туристичних бібліотеках (електронних і звичайних) тощо. Однак у кожному із цих сценаріїв є деякі, що пізнають і контрольовані границі між даними й базовими системами. Отже, можна визначити простір даних, що при забезпеченні належного керування дасть організації істотні переваги.

Як ключова програма робіт в області керування данными ми пропонуємо проектування й розробку платформ підтримки просторів даних ПППД (DataSpace Support Platforms).У просторі даних повинна використовуватися вся інформація, що потрібна для конкретної туристичної організації, незважаючи на формат і місце розташування цієї інформації, а також повинен моделюватися розвинутий набір зв'язків між репозитаріями даних. Тому на логічному рівні простір даних представляється як набір учасників і зв'язків.

Простори даних можуть вкладатися один в одного, і вони можуть перекриватися. Тому в просторі даних потрібно дотримуватися правила розмежування доступу. У деяких випадках нестандартності туристичної сфери границі між просторами даних можуть бути плаваючими, але в більшості випадків ці границі будуть визначатися природно.

Разом з неоднорідністю вмісту простору даних виникає потреба в підтримці декількох стилів доступу до даних. Як видно, ПППД будуть допускати багато різних режимів взаємодії, і потрібна гранична спільність, щоб допустити застосування різних служб до різних типів вмісту.

Архітектуру простору даних розділимо за рівнями (рис. 2).

Рис. 2. Рівні реалізації простору даних.

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

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

ПППД також повинні підтримувати й відновлювати дані. Очевидно, що ефекти відновлень будуть визначатися рівнем мінливості відповідних джерел даних. Однієї з основних дослідницьких проблем просторів даних є розробка й забезпечення гарантованої семантики відновлень у різнорідному середовищі з високим рівнем автономності компонентів.

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

Відповідно до перерахованих служб, виділяються наступні архітектурні компоненти ПППД.

Рис.2. Архітектурна схема простору даних.

ПППД з повним набором служб повинні містити всі ці компоненти, багато хто з них могли б використовуватися незалежно для досягнення деякого компромісу між витратами й одержуваними перевагами. Одне важливо, що ПППД допускає інкрементне інвестування, а не являє собою тільки монолітне рішення.

1. M. Franklin, A. Halevy and D. Maier: From Databases to Dataspaces: A New Abstraction for Information Management. ACM SIGMOD Record 34, No. 4 (December 2006), http://www.sigmod.org/sigmod/record/issues/0512/p27-article-franklin.pdf. [2] Serge Abiteboul, Rakesh Agrawal, Phil Bernstein, Mike Carey, Stefano Ceri, Bruce Croft, David DeWitt, Mike Franklin, Hector Garcia Molina, Dieter Gawlick, Jim Gray, Laura Haas, Alon Halevy, Joe Hellerstein, Yannis Ioannidis, Martin Kersten, Michael Pazzani, Mike Lesk, David Maier, Jeff Naughton, Hans Schek, Timos Sellis, Avi Silberschatz, Mike Stonebraker, Rick Snodgrass, Jeff Ullman, Gerhard Weikum, Jennifer Widom, and Stan Zdonik. The Lowell Database Research Self-Assessment. Commun. ACM, 48(5):111-118, 2005. [3] Alon Halevy. Why Your Data Won't Mix. ACM Queue, 3, No. 8 (October 2005), http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=336