Home » Blogs » Natalya's blog

Простори даних - нова абстракція керування даними

Submitted by Natalya on Wed, 24/10/2007 - 18:03

І бази даних, і сховища даних дозволяють опрацьовувати деталізовані та інтегровані дані, що побудовані на основі наперед допустимих моделей даних. У випадку роботи у всесвітній мережі з величезною кількістю ресурсів (прикладами таких задач є туристичний бізнес – збирання інформацію про місця відпочинку, її інтеграція та зберігання у внутрішніх базах даних, геоінформаційні системи – на сьогодні ще не розроблено єдних стандартів подання такої інформації, а її збір також проходить із джерел з наперед невідомими моделями даних) неможливо визначити, які саме моделі даних використовуватимуться. Тому виключно за допомогою баз даних та сховищ даних не можна організувати ефективної взаємодії між усіма об'єктами у цих предметних областях. Розробники часто зустрічаються з набором слабо зв'язаних джерел даних і тому повинні кожного разу вирішувати низькорівневі завдання управління даними. У число цих завдань входять забезпечення можливостей пошуку і запиту даних; дотримання правил, обмежень цілісності, угод про іменування і т.д.; відстежування походження даних; забезпечення доступності, відновлення і контролю доступу; керований розвиток даних і метаданих.

Традиційні СКБД представляють тільки одну точку (хоч і дуже важливу) в просторі рішень управління даними. Важливою точкою є "системи інтеграції даних. Насправді, системи інтеграції даних і обміну даними традиційно призначаються для підтримки багатьох інших служб в системах просторів даних. Особливість полягає у тому, що в системах інтеграції даних потрібна семантична інтеграція до того, як можуть бути забезпечені які-небудь інші послуги. Тому, хоч і відсутня єдина схема, якій відповідають всі дані, система повинна знати точні взаємозв'язки між елементами, що використовуються в кожній схемі. В результаті для створення системи інтеграції даних потрібна значна попередня робота.

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

На відміну від СУБД, в ядрі DSSP потрібна підтримка декількох моделей даних, щоб природним чином підтримувалося якомога більше типів учасників.

Простір даних – це множина баз даних, сховищ даних, локальних сховищ та індексів, статичних Web-сторінок, графічних матеріалів, засобів інтеґрації, пошуку та опрацювання інформації [2, 13, 14, 59]. Як ключова задача робіт в області керування даними використовується платформа підтримки просторів даних (DataSpace Support Platforms, DSSP). DSSP забезпечує набір взаємозв'язаних послуг і ґарантує розробникам можливість
концентруватися на специфічних проблемах їх додатків, а не на завданнях, що повторюються, виникають при потребі узгодженої й ефективної роботи з взаємозв'язаними, але роздільно керованими даними.

На відміну від СКБД, в ядрі DSSP необхідна підтримка декількох моделей даних, щоб природним чином підтримувалося якомога більше типів учасників.

Перші статті по опрацюванні різних джерел даних та використанні цих даних в єдиній предметній області з’явилися у 2005 р.Роботи [2, 3] задекларували проблеми, які привели до необхідності введення такої абстракціїх даних, як простір даних. Серед них:

  • Інтеграція тексту, даних, коду і потоків (частково вирішена завдяки введенню Коддом 12-ти правил побудов сховищ даних та їх подальшої модифікації [12]).
  • Забезпечення можливості багатоконтрольності даних (у концепції сховищ даних вирішувалася через процедури витягання, перетворення та завантеження даних (extract, transform and load – ETL)[3], а у випадку Інтернет із тисячами джерел інформації, поданої у різних форматах, ETL не придатна для використання).
  • Створення простих способів аналізу, узагальнення, пошуку і огляду електронних підбірок мультимедійної інформації, включаючи розробку стандартів опису метаданих (на даний момент нема єдиних стандартів опису та опрацювання мультимедійної інформації).
  • Підтримка неточних та невчасних (тих, що поступають із запізненням або в неочікуваному порядку) даних та реалізація неточних запитів. Останніми роками достатньо інтенсивно досліджується окремий випадок цієї проблеми, так звані top-K-запити та неточні запити. Знову ж таки, розроблені моделі та технології працюють лише із визначеними моделями даних (зокрема реляційною –Fquery [12], Fuzzy Grouping та Fuzzy Lookup [13]). Стосовно невчасних даних взагалі відсутні методи, які б дозволяли не тільки фіксувати факт запізнення даних, але й на основі цих тимчасово відсутніх даних приймати рішення (ведуться роботи в області машин для обробки подій, проте на даний момент задекларовані лише проблеми, які призводять до задачі маніпулювання потоками. Роботи, що були проведені у середині 90-х років в області активних баз даних (Active DBMS, ADBMS) залишилися невикористаними через великий час відклику запитів та неврахування тимчасової відсутності даних [14]).
  • Релевантність відповіді повинна залежати від користувача і від контексту. Потрібне середовище для накопичення і використання відповідних метаданих. Є наробки щодо визначення типу користувача на основі записів у журналі доступу до ресурсів [14].
  • Проблема інтеграції даних, у тому числі надоперативних (частково вирішена оперативними сховищами даних – дані збираються та оперативно опрацьовуються, але залежать від зовнішньої структури) та частково структурованих (частково вирішено засобами пошуку неструктурованих даних [10]).
  • Використання природніх мов запитів до баз даних (так звані системи з природномовним інтерфейсом) [9] – передбачають формування запитів до системи у вигляді запитальних речень природної мови.
  • Підтримка систем обробки потокових даних (наприклад, система Postgres Майкла Стоунбрейкера, високорівнева мова “STREAMSQL” з вбудованими орієнтованими
    на потоки примітивами і операціями).
  • Повинна бути можливість ефективного зберігання, доступу і модифікації інформації про стан, а також її комбінування з реальними потоковими даними.
  • Для інтеграції в системі повинна використовуватися однорідна мова для роботи з усіма різновидами даних.

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

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

    Поверх каталога розміщене середовище управління моделями, яке дозволяє створювати нові
    зв'язки і маніпулювати існуючими зв'язками (наприклад, об'єднувати або інвертувати відображення, зливати схеми і створювати єдині представлення декількох джерел).

    Важливою компонентою простору даних є компонента зберігання і індексування для досягнення наступних цілей:

  • для створення асоціацій між об'єктами даних від різних учасників;
  • для вдосконалення доступу до джерел з обмеженими власними засобами доступу;
  • для забезпечення можливості виконання деяких запитів без доступу до реального джерела даних;
  • для підтримки високого рівня доступності і відновлення.

    • Засоби індексування повинні володіти високим рівнем адаптивності до неоднорідних середовищ. Результатом локального зберігання та індексування є запит, що може повернути, наприклад, рядок в текстовому файлі, елемент шляху до файлу, значення в базі даних, елемент схеми або тег в XML-файлі. Важливими аспектами індексу є те, що, по-перше, він визначає інформацію для всіх учасників, коли деякі значення входять в декілька джерел даних (в деякому розумінні, це узагальнює ідею індексів з'єднання). По-друге, індекс повинен справлятися з різноманітністю посилань на об'єкти предметної області, наприклад, з різними способами опису адміністративної одиниці.

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

    Оскільки одним із ключових питань простору даних є питання інтеграції, то розглянемо стандарти інтеграції. Інтеграція інформаційних систем на основі веб-служб пов'язана з використанням чотирьох ключових стандартів: розширена мова розмітки інформації — Extensible Markup Language (XML), простий протокол доступу до об'єкта — Simple Object Access Protocol (SOAP), мова опису веб-служб — Web Services Description Language (WSDL), універсальний метод опису, виявлення та інтеграції — Universal Description, Discovery, and Integration (UDDI).

    Засоби опрацювання даних повинні підтримувати:

  • Видобування даних (Data mining) – асоціативні правила, дерева рішень, генетичні алгоритми тощо,
  • Analytical Processing (OLAP) – реляційний OLAP (Relational OLAP –ROLAP), багатовимірний OLAP (Multidimensional OLAP – MOLAP), гібридний OLAP (Hybrid OLAP – HOLAP), динамічний OLAP (Dynamic OLAP – DOLAP),
  • Засоби природномовного пошуку– побудова нечітких запитів, запитів у вигляді природних питань, запитів до метаданих,
  • Засоби підбору контенту на основі аналізу характеристик користувача,
  • Засоби миттєвого аналізу даних (наприклад, визначення причин підвищення тиску у котлах за значеннями давачів приладів та пропонування методів усунення неполадок).

    • Отже, слід виділити такі особливості просторів даних.

  • Простори даних складаються з широкої різноманітності форматів та інтерфейсів і усі, без виключення формати даних повинні підтримуватися;
  • Дані у просторі даних не знаходяться у повному контролі;
  • Передбачається інтеграція тексту, даних, коду і потоків;
  • Підтримка структурованих, текстових, просторових, темпоральних, мультимедійних, процедурних даних; тригерів; потоків і черг даних як рівноправних компонентів;
  • Простори даних повинні забезпечувати вбудовану підтримку неточних даних. Повинна бути можливість задання неточних запитів, і процесор запитів повинен відноситися до цього як до додаткового джерела неповноти і неточності;
  • Відповіді на запити повинні залежати від профілю користувача. Відповідь на запит експерта повинна відрізнятися від відповіді на запит новачка. Релевантність відповіді теж повинна залежати від користувача і від контексту;
  • Система повинна знати точні взаємозв'язки між елементами, що використовуються у кожній схемі;
  • DSSP пропонує рівні обслуговування та методи отриманні приблизних відповідей;
  • DSSP повинен запропонувати інструменти і шляхи створення щільнішої інтеграції даних в просторі в міру необхідності.
  • Можуть забезпечуватися різні рівні послуг з обробки запитів до DSSP, і в деяких випадках вони можуть повертати найкращі з можливих приблизні відповіді. Наприклад, якщо деякі джерела даних стають недоступними, може забезпечити найкращий з можливих результат на основі даних, доступних під час виконання запиту.

    • 1. Сергей Кузнецов. От баз данных к пространствам данных: новая абстракция управления информацией. – 2006,http://www.citforum.ru/database/articles/from_db_to_ds

    2. Кэтэрин Дрюэк (Katherine Drewek). Хранилища данных: сходство и различия подходов Билла Инмона и Ральфа Кимболла, 2005, http://www.b-eye-network.com/view/743

    3. Dan Linstedt. Data Vaulttm overview the next evolution in data modeling. – 2005,http://www.tdan.com/i021hy01.htm

    4. Огляд технологій інтеграції інформаційних систем, 2006,
    http://www.microsoft.com/Ukraine/Government/Analytics/IntegrationTechnologies/Overview.msp

    5. Сергей Кузнецов. Пространства данных: исследовательский полигон или путь к новому поколению систем управления данными? http://synthesis.ipi.ac.ru/sigmod/seminar/s20060420.

    6. Donald Kossmann, Jens-Peter Dittrich. Personal Data Spaces.http://www.inf.ethz.ch/news/focus/res_focus/feb_2006/index_DE.

    7. Garretts Summary of Principles of Dataspace Systems, http://aravaipa.eas.asu.edu/wiki/index.php/Garretts_Summary_of_Principles_of_Dataspace_Systems#Overview

    8. ETH - Databases and Information Systems – iMeMex, www.dbis.ethz.ch/research/current_projects/iMeMex

    9. Processing of natural language queries to a relational database. Samsonova M, Рisarev A, Blagov M,http://www.cs.dartmouth.edu/~brd/Teaching/AI/Lectures/Summaries/natlang.html

    10. Основные концепции и подходы при создании контекстно-поисковых систем на основе реляционных баз данных.
    http://www.citforum.ru/database/articles/search_sys.shtml    .

    11. Стулов А. Особенности построения хранилищ данных.http://www.citforum.ru/database/articles/20030520/

    12. Kacprzyk J., Ziolkowski A. Database Queries with Fuzzy Linguistic Quantifiers//
    IEEE Transactions on Systems, Man, and Cybernetics. SMC-16, 1996. – P. 512-529.

    13. Fuzzy Grouping в Microsoft SQL Server 2005 http://msdn.microsoft.com/msdnmag/issues/05/09/SQLServer2005/default.aspx.

    14. Пелещишин А.М. Методи та алгоритми моделювання Web-систем. Вісник ДУ Львівська Політехніка, №406.-Львів, 2000. С.199-211

    15. Черняк Л. Машины для обработки событий. - Открытые системы #09/2006

    16. Гіпертекстові Технології, http://moodle.ukma.kiev.ua

    »

    © Інформаційні технології. Аналітика , Рідна Мережа