CC BY
47
УДК 004.652.4+004.827
Н.Б. ШАХОВСЬКА, Д.1. УГРИН
ВИР1ШЕННЯ ПРОБЛЕМ КОМПЛЕКСНОГО АНАЛ1ЗУ В ПРОСТОРАХ ДАНИХ ТУРИЗМУ
Аналiзуються проблеми, що виникають шд час роботи з розрiзненими джерелами з використанням сховищ та баз даних у галузi туризму. Вводиться модель простору даних як засобу штеграци та опрацювання даних з розрiзнених джерел.
Вступ
Туризм е однieю iз провiдних i найбiльш динамiчних галузей економши й за швидкiстю темпу розвитку вш визнаний економiчним феноменом столотя.
У багатьох кра!нах туризм вщграе значну роль у формуванш валового внутрiшнього продукту, активiзацi! зовшшньоторговельного балансу, створеннi додаткових робочих мюць i забезпеченнi зайнятостi населення. Туризм впливае на таю ключовi галузi економiки, як транспорт i зв'язок, будiвництво, сiльське господарство, виробництво товарiв народного споживання й iншi, тобто виступае своерiдним стабiлiзатором соцiально-економiчного розвитку. У свою чергу, на розвиток туризму впливають рiзнi фактори: демографiчнi, природ-но-географiчнi, соцiально-економiчнi, юторичш, релiгiйнi й полiтико-правовi. На основi вико-ристання величезно! кiлькостi даних та шформаци, а також з появою виникнення проблеми впорядкування та використання дано! шформаци логiчним е також i те, що усе бшьше значущу роль у туристичному бiзнесi вiдiграють бази даних, !х сховища та простори.
Як бази даних, так i сховища даних, будуються з допомогою систем управлшня базами даних (СУБД). Саме вони забезпечують загальш умови для збер^ання i запиту структуро-ваних даних. СУБД шдтримуе набiр взаемозв'язаних послуг i гарантуе розробникам мож-ливють зосереджуватися на специфiчних проблемах !х додаткiв, а не на завданнях, що повторюються, якi виникають при потребi в узгодженому i ефективному управлiннi великими об'емами даних.
На жаль, в сучасних сценарiях управлiння даними рiдкiснi випадки, коли вш данi можуть знаходитися шд управлiнням традицшно! реляцшно! СУБД або яко!-небудь шшо! моделi даних чи системи. Натомють розробники часто стикаються з набором слабозв'язаних джерел даних i тому доводиться кожного разу виршувати низькорiвневi завдання управлш-ня даними, що повторюються, в рiзнорiдних колекцiях. У число цих завдань входять забезпечення можливостей пошуку i запиту даних; дотримання правил, обмежень цшсносп, угод про iменування i т.д.; вiдстежування походження даних; забезпечення доступности вiдновлення i контролю доступу; керований розвиток даних i метаданих.
Проблеми такого роду виникають на вшх ланках туристичного бiзнесу - на туристичних об'еднаннях (туристичних операторiв i туристичних компанiй): всерединi адмшютративних туристичних агентств i мiж ними, у великих туристичних готелях (електронних i звичайних) i навiть у великих мережевих компанiях. Проте в кожному з цих сценарив е деяю пiзнаванi i контрольованi межi мiж даними i базовими системами. Тому для управлшня даними туристично! сфери необидно використовувати простори даних.
1. Актуальшсть роботи
Мета роботи - моделювання простору даних туристично! сфери.
Зазначимо особливосп туристично! сфери, яю не дозволяють для опрацювання !хшх даних використовувати сховища даних.
Оскшьки прогнозувати розвиток шформацшних технологiй у туризмi неможливо без розумшня й прогнозування тенденцiй розвитку самого туристичного ринку, то розвиток шде по шляху глобалiзацi!. Важливими факторами в туристичному бiзнесi е швидюсть i якiсть доведення до ктента (агентства або туриста) шформаци про турпродукт, хто швидше й зручшше обслужить клiента. Тому сьогодш вже недостатньо автоматизацi! окремих аспектов дiяльностi компанi!. Наприклад, якщо в туроператора автоматизована бухгалтерiя,
але облш ктента ведеться окремо, а сайт е незалежне iнформацiйне сховище, то вш постiйно буде мати проблеми, пов'язаш з iнформацiйним обмшом мiж всiма пiдроздiлами компани. Так само й в агентствах. Якщо пошук турiв ведеться в однш (або декiлькох) системi, а облш туристiв - в iншiй незалежнш програмi, то витрати на перенесення даних в одне iнформацiйне сховище й усунення з шшого неминуче призводить до накладок, якi будуть зводити нашвець переваги, що дае автоматизащя.
2. Постановка задачi та аналiз лiтературних джерел
На сьогодшшнш день туристичний ринок вимагае комплексно! автоматизаци всiх бiзнес-процесiв у рамках одше! компани або навт всього ринку. А це насамперед проспр iнформацiйних даних туризму з декшькома „вшнами" (iнтерфейсами).
Через одне „вшно" (сайт) дивляться клieнти, через шше (внутрiшню програму) -менед-жери. Трете й четверте вшна - для бухгалтерп й адмшютраци. Зрозумшо, що забезпечити единий iнформацiйний проспр в рамках усього туристичного ринку нереально. Занадто багато гравщв, занадто багато протирiч. Тому прогнозуючи та автоматизуючи iнформацiйнi данi можна говорити лише про единий шформащйний проспр.
Для повноцшно! роботи простору даних туристичного бiзнесу потрiбна пiдтримка декшь-кох моделей туристичних даних, оскшьки проблеми в цьому напрямку знаходяться тшьки в станi вивчення та дослщжень. Щоправда iнформацiя по опрацюванню рiзних джерел даних та використанш цих даних в eдинiй предметнш областi з'явилася у 2006 р. Роботи розгляда-ли проблеми, як привели до необхiдностi введення тако! абстракци даних, як простiр даних туризму. Серед них:
1. 1нтегращя тексту, даних, коду i потоюв (частково вирiшена завдяки введенню Код-дом 12-ти правил побудов сховищ даних та !х подальшо! модифшаци).
2. Забезпечення можливостi багатоконтрольностi даних (у концепцп сховищ даних виршувалася через процедури витягання, перетворення та завантаження даних (extract, transform and load - ETL) [1], а у випадку 1нтернет iз тисячами джерел шформаци, подано! у рiзних форматах, ETL не придатна для використання).
3. Створення простих способiв аналiзу, узагальнення, пошуку i огляду електронних пiдбiрок мультимедiйно! iнформацi!, включаючи розробку стандартiв опису метаданих (на даний момент нема единих стандарта опису та опрацювання мультимедшно! шформаци).
4. Пщтримка неточних та невчасних (тих, що поступають iз зашзненням або в неочшу-ваному порядку) даних та реалiзацiя неточних запита. Останнiми роками достатньо штен-сивно дослщжуеться окремий випадок цie! проблеми, так зваш top-K-запити та неточш запити. Знову ж таки, розроблеш моделi та технологi! працюють лише iз визначеними моделями даних (зокрема реляцшною - Fquery, Fuzzy Grouping та Fuzzy Lookup [2]). Стосовно невчасних даних взагалi вщсутш методи, яю б дозволяли не тшьки фшсувати факт запiзнення даних, але й на основi цих тимчасово вщсутшх даних приймати рiшення (ведуться роботи в обласп машин для обробки подш, проте на даний момент задеклароваш лише проблеми, яю призводять до задачi манiпулювання потоками. Роботи, що були проведет у середиш 90-х роюв в обласп активних баз даних (Active DBMS, ADBMS), залишилися невикористаними через великий час вщклику запитiв та неврахування тимчасово! вщсутноси даних).
5. Проблема штеграцп даних, у тому чи^ надоперативних (частково вирiшена опера-тивними сховищами даних - дат збираються та оперативно опрацьовуються, але залежать вiд зовнiшньо! структури) та частково структурованих (частково вирiшено засобами пошуку неструктурованих даних [2]).
6. Використання природних мов запиив до баз даних (так зваш системи з природномов-ним штерфейсом) - передбачають формування запитiв до системи у виглядi запитальних речень природно! мови.
7. Пiдтримка систем обробки потокових даних (наприклад, система Postgres Майкла Стоунбрейкера, високорiвнева мова «STREAMSQL» з вбудованими орieнтованими на потоки примггивами i операщями).
8. Повинна бути можливiсть ефективного збер^ання, доступу i модифiкацi! шформаци про стан, а також !! комбшування з реальними потоковими даними.
9. Для штегращ! в системi повинна використовуватися однорщна мова для роботи з ушма рiзновидами даних.
3. Основний матерiал
В туристичнiй сферi наперед не можна визначити, яю саме моделi даних використовува-тимуться. Тому виключно за допомогою баз даних та сховищ даних не можна оргашзувати ефективно! взаемоди мiж усiма об'ектами ще! предметно! область Розробники часто зуст-рiчаються з набором слабозв'язаних джерел даних i тому повинш кожного разу виршувати низькорiвневi завдання управлiння даними. У число цих завдань входять забезпечення можливостей пошуку i запиту даних; дотримання правил, обмежень цiлiсностi, угод про iменування i т.д.; вщстежування походження даних; забезпечення доступностi, вщновлення i контролю доступу; керований розвиток даних i !х мета.
Щоб вирiшити цi задачi, необхiдно надавати запити конкретним засобам, задавати потрiбнi питання в потрiбний час, а поим застосовувати отримаш вiдповiдi для досягнення переваг у конкурентнiй боротьбi в галузi туристичного бiзнесу. Розглянемо схему концепци самостiйного аналiзу туристичних даних (рис. 1).
1нформац1я
Замовлення
Турист
X X
та Ч
и о о. с
Пошук шформацп
Пов1домлення-в1дпов1дь
И ] )_1
Каталог
Рис. 1. Схема анатзу туристичних даних Як видно зi схеми, шформащя, що повинна надатися туристичному клieнту, повинна бути знайдена в просторi даних, яка в свою чергу через менеджера та туристичного оператора буде вобрана вщносно вподобань та вимог замовника.
В [1] зазначено, що проспр даних DS - це множина даних, поданих у рiзних моделях (баз даних DB, сховищ даних DW, статичних веб-сторiнок Wb, неструктурованих даних Nd, графiчних та мультимедшних даних Gr), локальних сховищ та iндексiв ODW, а також засобiв iнтеграцi! Int, пошуку Se та опрацювання iнформацi! Wo, об'еднаних середовищем управлiння моделями ЕМ:
DS=<DB, DW, ODW, Wb, Nd, Gr, Int, Se, Wo, ЕМ>. Оскшьки основним джерелом витягування iнформацi! з простору даних вважасться каталог CG, який в свою чергу е реестром ресурсiв даних, що мютять найбiльш базову iнформацiю про кожний з них: джерело, iм'я, мюцеположення в джерелi, розмiр, дата створення i власник i т.д., то вш е iнфраструктурою для бшьшост iнших сервiсiв простору даних, але каталог також може шдтримувати базовий, призначений для користувача iнтер-фейс переглядання простору даних:
DB, DW, Wb, Nd, Gr ^ CG. Вiн не тiльки мютить описову iнформацiю (тобто виконуе роль метаданих), але й зберiгае для кожного учасника схему джерела, статистичш данi, швидкiсть змiни, точнiсть, можли-востi вiдповiдей на запити, шформащю про власника i данi, про полгтику доступу i пiдтримку конфщенцшносп. Оскiльки джерела простору даних фiзично не переносять у нього шформащю та можуть обмiнюватись мiж собою iнформацiею, то у каталозi необидно зберiгати данi i про зв'язки мiж джерелами [1].
Поверх каталога розмщене середовище управлiння моделями, яке дозволяе створювати HOBi зв'язки i манiпулювати iснуючими зв'язками (наприклад, об'еднувати або iнвертувати вiдображення, зливати схеми i створювати един подання декiлькох джерел).
Для iдентифiкацiï та роботи з неоднорщними колекцiями в просторi даних можна викори-стовувати глобальну схему iмен (Uniform Resource Identifiers - URI ) як механзм посилань на глобальн константи, щодо яких е деяка угода мiж декiлькома постачальника-ми даних.
Важливою компонентою простору даних е компонента збер^ання й шдексування (ODW) для досягнення таких цiлей:
- для створення асоцiацiй мiж об'ектами даних вщ рiзних учасникiв;
- для вдосконалення доступу до джерел з обмеженими власними засобами доступу;
- для забезпечення можливосп виконання деяких запита без доступу до реального джерела даних;
- для шдтримки високого рiвня доступност та вiдновлення.
Отже, зв'язок мiж каталогом CG, середовищем управлiння моделями EM, локальним сховищем та iндексами ODW можна подати як функщю EM(CG) ^ ODW.
Чим бшьше моделей здатне «розрiзнити» середовище управлшня, тим точнiша буде iнформацiя в ODW i тим ефектившше можна буде проводити процедури iнтеграцiï, пошуку та опрацювання даних у просторi даних DS.
Оскiльки одним iз ключових питань простору даних е питання iнтеграцiï, то розглянемо задачi 1'х виникнення:
- неоднорiднiсть програмного середовища,
- розподiлений характер оргашзаци,
- пiдвищенi вимоги до безпеки даних,
- необхщшсть наявностi багаторiвневих довiдникiв метаданих,
- потреба в ефективному збер^анш та обробцi дуже великих об'емiв iнформацiï.
Iнтеграцiя шформацшних систем на основi веб-служб Int пов'язана з використанням
чотирьох ключових стандарта:
Extensible Markup Language (XML) - розширена мова розмггки шформацп. Описуе iнформацiю, що пересилаеться по 1нтернету. Запит на одержання яких-небудь даних чи виконання певних дш iншим застосуванням вимагае наявностi способiв передачi параметрiв i одержання назад певних результата. При використанш веб-служб ця iнформацiя описуеть-ся за допомогою мови XML, що е мiжнародним загальноприйнятим стандартом для опису довшьних даних, якими у свою чергу можуть обмшюватися iнформацiйнi системи.
Simple Object Access Protocol (SOAP) - простий протокол доступу до об'екта. Цей стандарт описуе протокол виклику веб-служби (вщдалений процес доступу до послуг шформацп деякоï прикладноï системи), тобто переданi параметри описуються за допомогою мови WSDL, а сам процес виклику описуеться за допомогою SOAP. У типовш ситуацп взаемодiï система однiеï оргашзаци може викликати систему шшо1" оргашзаци, використову-ючи протокол SOAP. Запит, що зазвичай мiстить ту чи шшу форму бiзнес-документа, посилаеться шщатором до запитувано1' системи. Остання приймае запит, i вхщний документ, який мютиться в запитi, обробляеться. У результатi запитана система генеруе вщповщь, що повертаеться iнiцiатору взаемоди. Iнiцiатор також iнформуеться про статус (устх або iнше) запиту.
Web Services Description Language (WSDL) - мова опису веб-служб. Це мова, яка базуеться на стандарт XML, що визначае спошб доступу до веб-служб. Вона описуе функцюнальш можливосп веб-служб i групуе операци взаемоди у певш штерфейси, що задають способи виконання операцiй i ri параметри, якi повиннi бути на входi i виходi.
Universal Description, Discovery, and Integration (UDDI) - ушверсальний метод опису, виявлення та штеграци. Технолопя UDDI надае засоби, за допомогою яких можна зробити так, щоб будь-яю застосування чи послуги, описаш в термшах веб-служб, можуть бути розшзнаш iншими застосуваннями та органiзацiями. Отже, це стандарт створення репстра, використовуючи який, можна описати оргашзаци i послуги, яю вони надають, у вигляд^ доступному для динамiчного виявлення i взаемоди.
!нтегращя на основi веб-сервiсiв мае декшька рiвнiв. Розглянемо ïï схему (рис. 2).
На piBHi даних програмш застосування можуть обмшюватись iнформацieю. Цей piBeHb передбачае iнтеграцiю даних i е найпростшим. Наступний piBeHb — об'ектна взаeмодiя. Тут мова йде про те, що програмне застосування, розташоване на одному cepBepi, може запускати програмш процеси на шшому. Тpeтiй piвeнь штеграци — iнтeгpацiя на piвнi стандартно! семантики. На цьому piвнi cepвicи можуть «спшкуватися cпiльною мовою», обходячи тeхнологiчнi pозбiжноcтi. Один сервю може звертатись до iншого i3 «запитом на виконання покупки», «запитом на виконання пошуку», «запитом на отримання статистики» та iн. На цьому piвнi iнтeгpацi! cepвicи будуть потребувати лише стандартизаци семантики, тобто шд словами «покупка», «пошук» i «статистика» вони повиннi pозумiти одне й те ж саме. Якщо семантичних pозбiжноcтeй мiж ними немае, штегращя не мае особливих тpуднощiв, тобто використовуючи cпeцифiкацiю WSDL, програмне застосування може «говорити» системно-незалежною мовою. З одного боку, системна незалежшсть застосу-вань постае з використання мови XML при створенш WSDL-опишв, а з iншого — специфша-цiя SOAP дозволяе взаемодiяти серверному та ^ентському застосуванням. Потpiбно лише надати вх1дш данi, а турботи про те, яким чином доставити !х застосуванню на обробку та повернути !! результати назад, протокол SOAP повшстю бере на себе [1].
-т——
Програмне Програмне Програмне
застосування застосування застосування
1 2 n
1нформац1я
Рис. 2. Схема iнтеграцii на основ1 Be6-cepBiciB
В той самий час слщ сказати й про деяю недолiки технологи Be6-cepBiciB. В [2] зазначено основш нeдолiки: нeоднозначнiсть спeцифiкацii SOAP, недостатня безпека та недостатня швидюсть роботи веб-сервгав.
Проте простори даних не е пiдходом до штеграци даних; швидше це пiдхiд спiвiснування даних. Мета шдтримки простору даних полягае в забезпеченш базового набору функцш мiж всiма джерелами даних, а не в ix штеграци. Наприклад, DSSP може забезпечити мiж вшма сво1'ми джерелами даних пошук за ключовими словами, аналогiчно тому, що забезпечують iснуючi пошуковi системи в десктопах. При потpeбi в складшших опepацiяx, таких як запити в реляцшному стилi, аналiз даних (data mining) або мошторинг яких-небудь джерел, можна докласти додатковi зусилля до тiснiшоi iнтeгpацii цих джерел в шкрементнш манepi «оплати поточних рахунюв» («pay-as-you-go»).
DSSP повиннi працювати з даними i застосуваннями в piзноманiтниx форматах, доступ-них вiд багатьох систем через piзнi iнтepфeйси. Вщ DSSP потpiбна пiдтpимка всix даних простору даних, без яких-небудь виключень (як це бувае при використанш СУБД). Тому одною iз ключових задач побудови простору даних е визначення виpазноi потужностi запитiв iз Se.
Хоча DSSP забезпечуе засоби штегрованого пошуку, запиту, оновлення i адмшструван-ня пpостоpiв даних, т ж самi данi часто можуть бути доступш для читання i оновлення через власний iнтepфeйс системи, що безпосередньо управляе даними. Тому, на вщмшу вiд СУБД, DSSP не мае повного контролю над сво1'ми даними.
Засоби опрацювання даних Wo повиннi шдтримувати:
- видобування даних (Data mining) - асощативш правила, дерева ршень, генетичнi алгоритми тощо,
- засоби аналiзу даних (Online Analytical Processing - OLAP) - реляцшний OLAP (Relational OLAP - ROLAP), багатовимiрний OLAP (Multidimensional OLAP - MOLAP), пбридний OLAP (Hybrid OLAP - HOLAP), динамiчний OLAP (Dynamic OLAP - DOLAp),
- засоби природно-мовного пошуку - побудова нечiтких запита, запита у виглядi природних питань, запита до метаданих,
- засоби шдбору контенту на основi аналiзу характеристик користувача,
- засоби миттевого аналiзу даних (наприклад, визначення причин отруення або епiдемiч-ного захворювання туристiв на певнiй територiï та пропонування методiв усунення проблем).
Щдхщ сховищ (DataWarehouse) i вирин (data mart) даних на основi витягання операцш-них даних, ï^ трансформацiï до единоï схеми i завантаження даних в сховищi (процедура ETL - extraction, transformation, loading) придатний для використання для сфери з декшькома десятками операцiйних баз даних, що знаходяться пiд единим контролем. У Internet парадигма ETL не прийнятна.
Зв'язок мiж елементами сховища даних поданий на рис. 3.
ffffll
KÎH^BÎ KopMCTyBa4Ï
Рис. 3. Схема зв'язку елеменпв простору даних
Особливостi просторiв даних [5] :
- простори даних складаються з широкоï рiзноманiтностi форматiв та iнтерфейсiв i уш, без виключення формати даних повинш пiдтримуватися;
- данi у просторi даних не знаходяться у повному контроле
- iнтеграцiя тексту, даних, коду i потоюв;
- шдтримка структурованих, текстових, просторових, темпоральних, мультимедшних, процедурних даних; тригерiв; потокiв i черг даних як рiвноправних компонента;
- простори даних повинш забезпечувати вбудовану шдтримку неточних даних. Мусить бути можливють задання неточних запита, i процесор запитiв повинен вщноситися до цього як до додаткового джерела неповноти i неточности
- вщповщ на запити повиннi залежати вщ профiлю користувача. Вiдповiдь на запит експерта мусить вiдрiзнятися вщ вiдповiдi на запит новачка. Релевантнють вiдповiдi теж повинна залежати вщ користувача i вiд контексту. Тому виникае необхщнють середовища для накопичення i використання вiдповiдних метаданих;
- система повинна знати точш взаемозв'язки мiж елементами, що використовуються у кожиш схемi;
- DSSP пропонуе рiвнi обслуговування та методи отримання приблизних вiдповiдей;
- DSSP повинен запропонувати iнструменти i шляхи створення щшьшшо! штеграцп даних в просторi в мiру необхiдностi.
Можуть забезпечуватися рiзнi рiвнi послуг з обробки запита до DSSP, i в деяких випадках вони можуть повертати якнайкращi з можливих приблизнi вщповщь Наприклад, якщо деякi джерела даних стають недоступними, DSSP може забезпечити найкращий з можливих результат на основi даних, доступних пiд час виконання запиту.
Для кращого розумшня принципiв побудови та функцiонування просторiв даних розгляне-мо простiр даних туристично! сфери. Об'екти простору даних та його задачi поданi на рис. 4.
Опишемо об'екти простору даних в галузi туризму. Для простору даних необхщна iнтергацiя шформацп про таю об'екти:
- мiсцевi органи управлiння - надають шформащю про вiдпочинковi, рекреацiйнi та оздоровчi ресурси, а також правила !х експлуатацп; лшп сполучення, особливостi мюцевосп тощо;
- туристичнi агентства - надають шформащю про себе, про послуги, що вони надають.
- адмшютративш одинищ - описуються через шформащю мюцевих органiв управлiння, а також через вщклики попереднiх вiдвiдувачiв;
- особа (вщпочиваючий) - надае шформащю про себе, про умови, яю вш хоче отримати, цiни тощо.
Рис. 4. Об'екти простору даних та його задач1 на приклащ туристично1 сфери Залежно вщ типу об'екта шформащя може збертатися у р1зних моделях та надходити з р1зних джерел:
туристичне агентство - база даних, динам1чний веб-сайт з базою даних, розмщеною на веб-сервер^
адмшютративна одиниця - сховище даних, особа - веб-сайт, база даних, текстов! даш тощо, вщпочинковий ресурс - база даних, веб-сайт.
Оскшьки специфшою галуз1 туризму е подання шформацп в 1нтернет у вигляд1 реклами, замовлень тощо, то на найвищому р1вн1 1ерархй' моделей даних знаходяться колекцп 1мено-ваних ресуршв з базовими властивостями - розм1р, дата створення i тип (наприклад, зображення JPEG, база даних MYSQL).
Галузь туризму накопичить мiльйони даних протягом всього лише декiлькох роюв. Через велику кiлькiсть розрiзнених ресуршв жодна людина не зможе знати ш все сховище повнiстю, ш те, що означае кожен файл. Людям, що звертаються до цих даних, особливо
тим, яю не входять до сховища дано! групи, знадобиться зведений реестр основних атрибута файлiв, таких як перюд часу, до якого вщноситься даний файл, гeогpафiчний район тощо. Коли вpeштi-peшт iнфоpмацiя знайдена, постае питання !! узгодження та штерпре-тацл.
Незабаром таким групам потpiбно буде об'еднуватися з шшими групами для створення туристичних пpоcтоpiв даних peгiонального або нацiонального масштабу. 1м потpiбно буде якомога простше iмпоpтувати сво! данi в стандартних форматах i з глибиною дeталiзацi! (частина файлу або дeкiлька файтв). Коpиcтувачi федеральних пpоcтоpiв даних можуть захотiти побачити колекци даних, що належать piзним групам федераци, наприклад, вci описи та вiдгуки вщпочиваючих щодо опису певного природного ресурсу. Для швидкого пошуку в таких колекщях можуть знадобитися локальнi копи або додатковi iндeкcи.
Висновки
Подано формальну модель простору даних та наведено концептуальну модель простору даних в галузi туризму, що забезпечуе взаемодда мiж джерелами iфоpмацi!, подано! за допомогою piзних моделей даних, з piзними методами подання та опрацювання.
Наукова новизна. Новизна полягае в уведенш формального опису простору даних та окресленш його основних задач.
Практична цгнтсть полягае у побудовi простору даних в галузi туризму, видшенш основних об'ектiв та учасниюв.
Подальше до^дження стосуватимуться форматзаци мeтодiв iнтeгpацi! даних та пошуку неструктурованих, напiвcтpуктуpованих та строго структурованих даних.
Список лiтератури: 1. Шаховська Н.Б. Простори даних: поняття та призначення //Матер1али конфе-ренци CSIT-2007. Льв1в. 2007. С.269-277. 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. Donald Kossmann, Jens-Peter Dittrich. Personal Data Spaces. http:// www.inf.ethz.ch/news/focus/res_focus/feb_2006/index_DE. 5. Garretts Summary of Principles of Dataspace Systems, http://aravaipa.eas.asu.edu/wiki/index.php/Garretts_Summary_of_Principles_of_Dataspace_ Systems#Overview.
Надшшла до редколегИ 19.09.2007 Шаховська Натал1я Богдашвна, канд. техн. наук, доцент кафедри шформацшних систем та мереж НУ «Льв1вська полтгехшка». Науков1 штереси: сховища даних, простори даних, методи штеграцп та опрацювання даних.
Угрин Дмитро Iллiч, астрант НУ «Льв1вська полгтехшка». Науков1 штереси: простори даних у сфер1 туризму, методи опрацювання даних.
