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

ІсторіяРедагувати

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

На початку 1980-х років, комп'ютерні вчені почали працювати над створенням систем для взаємодії гетерогенних бази даних.

Перша система інтеграції відсутня рухомий структурованих метаданих був розроблений в університеті Міннесоти в 1991 році, для вбудованих мікроданних загального користування Series (IPUMS). IPUMS використовував сховища даних підхід, який витягує, перетворення і завантаження даних з різнорідних джерел в єдине уявлення схеми, так що дані з різних джерел, стають сумісними. Роблячи тисячі баз даних населення що забезпечує можливість взаємодії, IPUMS продемонстрували можливість великомасштабних інтеграції даних. Сховище даних підхід пропонує тісно пов'язані архітектуру, оскільки дані вже фізично узгоджені в єдиному сховищі Queryable, тому зазвичай це займає мало часу, щоб дозволити запити.

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

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

Це узгоджується з підходом SOA популярної в ту епоху. Цей підхід заснований на відображень між опосередкованої схеми і схеми оригінальних джерел, і перетворити запит на спеціалізовані запити, щоб відповідати схемі вихідних баз даних. Такі відображення можуть бути задані 2-ма способами: 
  • відображення об'єктів в опосередкованому схеми до осіб в первинних джерел ( Підхід "Global as View" GAV),
  • відображення з сутностей в першоджерелах до опосередкованої схема (Підхід "Local as View" LAV).

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

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

Станом на 2011 рік було встановлено, що методи моделювання в даний час дані додання ізоляції даних в кожну архітектуру цих у вигляді острівців розрізнених даних та інформаційних бункерах. Ця ізоляція даних є ненавмисним артефактом методології моделювання даних, що призводить до розвитку несумірних моделей даних. Розрізнені моделі даних, коли екземпляр у вигляді баз даних, утворюють розрізнені бази даних. методології моделі Розширені дані були розроблені для усунення ізоляції даних артефакт і сприяти розробці комплексних моделей даних. Один вдосконалений метод моделювання даних переробляє моделі даних шляхом розширення їх структурних метаданих у вигляді стандартизованих об'єктів даних , В результаті переробки декількох моделей даних, безліч моделей переглянутому даних тепер буде ділитися один або більше спільністю відносини, які стосуються структурних метаданих в даний час спільні для цих моделей даних. Спільність відносини типу рівний-рівному відносин сутностей, які відносяться стандартизовані об'єкти цих кількох моделей даних. багатофакторні моделі даних, які містять один і той самий стандартний об'єкт даних може брати участь в такому ж відношенні спільності. Коли інтегровані моделі даних інстанціруются як бази даних і правильно заповнюються із загального набору основних даних, то ці бази даних інтегровані.

З 2011 року підходи маточин дані були більший інтерес, ніж повністю структурованої (зазвичай реляційної) Enterprise Data складів. З 2013 року підходи озеро даних піднялися до рівня концентратори даних. (Переглянути всі три пошуку терміни популярність на Google Trends). Ці підходи поєднують неструктурованих або різні дані в одному місці, але не обов'язково вимагає (часто складного) майстер-схему реляційної структури і визначити всі дані в Hub.

Приклади ситуацій для використанняРедагувати

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

Рішення інтеграції даних може вирішити цю проблему, розглядаючи ці зовнішні ресурси як матеріалізовані уявлення над віртуальною опосередкованої схемою, що призводить до "інтеграції віртуальних даних". Це означає, що додаток-розробники побудувати віртуальну схему - опосередковане схеми - до кращої моделі види відповідей їх користувачі хочуть. Потім вони розробляють "обгорток" або адаптери для кожного джерела даних, такі як бази даних злочинності та веб-сайт про погоду. Ці адаптери просто перетворити локальні результати запиту (повертаються відповідних веб-сайтах або базах даних) в легко переробленому вигляді для інтеграції даних рішення (дивись малюнок 2). Коли додаток-користувач запитує опосередковану схему, рішення інтеграції даних перетворює цей запит в відповідні запити за відповідними джерелами даних. І, нарешті, віртуальна база даних об'єднує результати цих запитів у відповідь на запит користувача.

Це рішення забезпечує зручність додавання нових джерел шляхом простого побудови адаптера або лезо прикладного програмного забезпечення для них. Це контрастує з системами ETL або за допомогою єдиного рішення бази даних, які вимагають ручної інтеграції всього нового набору даних в систему. Віртуальний ETL рішення важелів віртуальної опосередкованої схеми для здійснення гармонізації даних; в результаті чого дані копіюються з призначеного "головного" джерела до певної мети, поле за полем. віртуалізації Advanced Data також побудована на концепції об'єктно-орієнтованого моделювання для побудови віртуальної опосередкованого схеми або віртуального сховища метаданих, використовуючи концентратор і говорив архітектуру.

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

Одним з рішень є переробка розрізнених баз даних для інтеграції цих баз даних без необхідності ETL. Бази даних переробці підтримують обмеження спільності, де посилальної цілісності може застосовуватися між базами даних. Бази даних переробці забезпечують розроблені шляхи доступу до даних із значенням даних спільністю між базами даних.

Інтеграція даних в сучасній науціРедагувати

Масштабні питання в області науки, такі як глобальне потепління, інвазивних видів, поширення і виснаження ресурсів, все частіше вимагають збору розрізнених наборів даних для мета-аналізу. Цей тип інтеграції даних є особливо складним завданням для екологічних і екологічних даних, оскільки стандарти метаданих не узгоджені і існує безліч різних типів даних, отриманих y цих областях. Ініціативи Національного наукового фонду, такі як DATANET покликані зробити інтеграцію даних простіше для вчених шляхом надання кіберінфраструктури і встановлення стандартів. П'ять фінансуються ініціатив DATANET є Dataone, на чолі з Вільямом Мішнером в Університеті штату Нью-Мексико; Даних Охорона природи, під керівництвом Саїда Чоудхурі з Університету Джона Хопкінса; ЮВАО: Сталий розвиток довкілля через здійсненні даних, на чолі з Маргарет Хедстром з Університету штату Мічиган; Консорціум DATANET Федерація, на чолі з Рейганом Мур з Університету Північної Кароліни; і Terra Populus, під керівництвом Стівена Ruggles з Університету Міннесоти. Research Alliance Data, недавно досліджував створення глобальних рамок інтеграції даних. Проект OpenPHACTS, який фінансується через Ініціативу по інноваційним лікарським Європейського союзу, створили платформу виявлення наркотиків, пов'язуючи набори даних від постачальників, таких як Європейський інститут біоінформатики, Королівського хімічного товариства, UniProt, WikiPathways і DrugBank.

Теорія інтеграції данихРедагувати

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

ВизначенняРедагувати

Теорія обробки запитів в системах інтеграції даних зазвичай виражається за допомогою кон'юнктівние запитів і DATALOG, чисто декларативний мову логічного програмування. [14] Можна вільно думати про кон'юнктивний запит як логічну функцію, застосовану до відносин бази даних, таких як " {\ displaystyle F (A, B)}, де {\ displaystyle A <B} ". Якщо кортеж або множина кортежів у правилі і задовольняє його (робить це правда), то ми вважаємо, що кортеж як частина набору відповідей в запиті. У той час як офіційні мови, як Datalog висловити ці питання коротко і без неоднозначності, загальних запитів SQL вважаються кон'юнктивні запитів, а також.

З точки зору інтеграції даних, "стримування запиту" являє собою важливу властивість кон'юнктивні запитів. Запит {\ displaystyle A} містить інший запит {\ displaystyle B} (позначається {\ displaystyle A \ supset B}), якщо результати застосування {\ displaystyle B} є підмножиною результатів застосування {\ displaystyle A} для будь-яка база даних. Ці два запити називаються еквівалентними, якщо отримані набори однакові для будь-якої бази даних. Це важливо, тому що в обох ВДС і LAV системах користувач створює кон'юнктівние запитів по віртуальній схемі, представленої сукупністю поглядів, або "матеріалізувався" кон'юнктівние запитів. Інтеграція прагне переписати запити, представлені думки, щоб зробити їх результати еквівалентні або максимально містяться запиту наших користувачів. Це відповідає завданню відповідей на запити з використанням уявлень (AQUV). [15]

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

У LAV системах запити піддаються більш радикальний процес переписування, тому що не існує посередник для вирівнювання запит користувача за допомогою простої стратегії розширення. Система інтеграції повинна виконати пошук по простору можливих запитів, щоб знайти кращий переписують. Отриманий в результаті переписування не може бути еквівалентом запиту, але максимально містив, і отримані в результаті кортежі можуть бути неповними. Станом на 2009 алгоритм Minicon є провідним запит переписування алгоритм для систем інтеграції даних LAV.

В цілому, складність переписування запиту є NP-повною. Якщо простір переписує відносно невелике, це не викликає особливих проблем. - Навіть для інтеграції систем з сотнями джерел.

Обробка запитівРедагувати

Системи інтеграції даних формально визначається як трійка {\ displaystyle \ вліво \ Лангле G, S, M \ право \ ському}, де {\ displaystyle G} є глобальним (або опосередковане) схеми, {\ displaystyle S} є гетерогенний набір вихідних схем, і {\ displaystyle M} є відображення, яке відображає запити між джерелом і глобальних схем. Обидва {\ displaystyle G} і {\ displaystyle S} виражаються в мовах над алфавітів, що складаються з символів для кожної з них відповідних відносин. Відображення {\ displaystyle M} складається з тверджень між запитами над {\ displaystyle G} і запитів над {\ displaystyle S}. Коли користувачі створюють запити через систему інтеграції даних, вони створюють запити над {\ displaystyle G} і відображення потім стверджує, зв'язку між елементами в глобальній схемою і схем джерел.

База даних по схемі визначається як сукупність множин, по одному для кожного співвідношення (в реляційної базі даних). У базі даних, відповідної вихідної схеми {\ displaystyle S} включатиме в себе безліч наборів кортежі для кожного з різнорідних джерел даних і називається вихідної бази даних. Зверніть увагу, що ця єдина вихідна база даних може насправді представляють собою набір розрізнених баз даних. База даних, відповідна віртуальної опосередкованої схемою {\ displaystyle G} називається глобальної бази даних. Глобальна база даних повинна задовольняти відображення {\ displaystyle M} по відношенню до вихідної базі даних. Законність цього відображення залежить від характеру відповідності між {\ displaystyle G} і {\ displaystyle S}. Два популярних способу моделі це відповідність є глобальна View або GAV і місцеві, як View або LAV.


Кортех простору GAV і LAV відображень У GAV, система обмежена на безлічі кортежів, відображених за допомогою посередників в той час як безліч кортежів виразність над джерелами можуть бути значно більше і багатше. У LAV, система обмежена на безлічі кортежів в джерелах в той час як безліч кортежів виразність над глобальною схемою може бути значно більше. Тому LAV системи часто доводиться мати справу з неповними відповідями. GAV системи модель глобальної бази даних, як набір уявлень над {\ displaystyle S}. В цьому випадку {\ displaystyle M} зіставляє кожному елементу {\ displaystyle G} запит над {\ displaystyle S}. Процедура розгляду заяв про стає простий роботи через чітко визначених асоціацій між {\ displaystyle G} і {\ displaystyle S}. Тягар складності доводиться на реалізацію коду медіаторів інструктування системи інтеграції даних в точності, як витягувати елементи з вихідних баз даних. Якщо будь-які нові джерела приєднатися до системи, значні зусилля можуть бути необхідні для поновлення медіатора, таким чином, підхід ВДС представляється кращим, коли джерела, здається навряд чи зміниться.

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

З іншого боку, в LAV, база даних джерела моделюється як набір уявлень над {\ displaystyle G}. В цьому випадку {\ displaystyle M} зіставляє кожному елементу {\ displaystyle S} запит над {\ displaystyle G}. При цьому точні асоціації між {\ displaystyle G} і {\ displaystyle S} перестають бути чітко визначені. Як показано в наступному розділі, тягар визначення, як витягати елементи з джерел розміщується на процесорі запитів. Перевага моделювання з LAV є те, що нові джерела можуть бути додані з набагато меншою кількістю роботи, ніж в системі, тим самим Г.А.В. ЛАВ підхід слід віддавати перевагу в тих випадках, коли опосередковані схеми менш стабільна, або може змінитися.

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

Рівні інтеграції данихРедагувати

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

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

Види архитектури систем інтеграції даннихРедагувати

КонсолідаціяРедагувати

У разі консолідації дані витягуються з джерел, і поміщаються в сховище даних. Процес заповнення Сховища складається з трьох фаз - витяг, перетворення, завантаження (Extract, Transformation, Loading - ETL). У багатьох випадках саме ETL розуміють під терміном «інтеграція даних». Ще одна поширена технологія консолідації даних - управління змістом корпорації (Для управління корпоративним контентом, скор ECM). Більшість рішень ECM спрямовані на консолідацію і управління неструктурованими даними, такими як документи, звіти і веб-сторінки. Консолідація - односпрямований процес, тобто дані з декількох джерел зливаються в Сховище, але не поширюються з нього назад в розподілену систему. Часто консолідовані дані є основою для додатків бізнес-аналітики (Business Intelligence, BI), OLAP-додатків. При використанні цього методу зазвичай існує деяка затримка між моментом оновлення інформації в первинних системах і часом, коли ці зміни з'являються в кінцеве місце зберігання. Кінцеві місця зберігання даних, що містять дані з великими часом відставання (наприклад, більше одного дня), створюються за допомогою пакетних додатків інтеграції даних, які витягають дані з первинних систем з певними, заздалегідь заданими інтервалами. Кінцеві місця зберігання даних з невеликим відставанням оновлюються за допомогою оперативних додатків інтеграції даних, які постійно відстежують і передають зміни даних з первинних систем в кінцеві місця зберігання.

ФедералізаціяРедагувати

У федеративних БД фізичного переміщення даних не відбувається: дані залишаються у власників, доступ до них здійснюється при необхідності (при виконанні запиту). Спочатку федеративні БД припускали створення в кожному з п вузлів п-1 фрагментів коду, що дозволяє звертатися до будь-якого іншого вузла. При цьому федеративні БД відокремлювали від медіаторів. При використанні медіатора створюється загальне уявлення (модель) даних. Медіатор - посередник, що підтримує єдиний користувальницький інтерфейс на основі глобального представлення даних, що містяться в джерелах, а також підтримку відображення між глобальним і локальним уявленнями даних. Користувальницький запит, сформульований в термінах єдиного інтерфейсу, декомпозіруется на безліч підзапитів, адресованих до потрібних локальних джерел даних. На основі результатів їх обробки синтезується повну відповідь на запит. Використовуються два різновиди архітектури з посередником - глобальна видом і, як Local View. Відображення даних з джерела в загальну модель виконується при кожному запиті спеціальною оболонкою (обгортка). Для цього необхідна інтерпретація запиту до окремих джерел і подальше відображення отриманих даних в єдину модель. Зараз цей спосіб також відносять до федеративним БД. Інтеграція корпоративної інформації (інформаційна інтеграція підприємств, скор ЕІІ.) - Це приклад технології, яка підтримує федеративний підхід до інтеграції даних. Вивчення і профілювання первинних даних, необхідні для федералізації, несильно відрізняються від аналогічних процедур, необхідних для консолідації.

Поширення ДанихРедагувати

Додатки поширення даних здійснюють копіювання даних з одного місця в інше. Ці програми зазвичай працюють в оперативному режимі і виробляють переміщення даних до місць призначення, тобто залежать від певних подій. Оновлення в первинній системі можуть передаватися в кінцеву систему синхронно або асинхронно. Синхронна передача вимагає, щоб поновлення в обох системах відбувалися під час однієї і тієї ж фізичної транзакції. Незалежно від використовуваного типу синхронізації, метод поширення гарантує доставку даних в систему призначення. Така гарантія - це ключовий відмітна ознака поширення даних. Більшість технологій синхронного поширення даних підтримують двосторонній обмін даними між первинними і кінцевими системами. Прикладами технологій, що підтримують поширення даних, є інтеграція корпоративних додатків (Enterprise інтеграції додатків, скор. EAI) і тиражування корпоративних даних (реплікація даних Еnterprise, скор. EDR). Від федеративних БД цей спосіб відрізняє двостороннє поширення даних. [1]

Сервісний підхідРедагувати

Сервісно-орієнтована архітектура SOA (Service Oriented Architecture), успішно застосовується при інтеграції додатків, може бути застосована і при інтеграції даних. Дані також залишаються у власників і навіть місцезнаходження даних невідомо. При запиті відбувається звернення до певних сервісів, які пов'язані з джерелами, де знаходиться інформація і її конкретну адресу. Інтеграція даних об'єднує інформацію з кількох джерел таким чином, щоб її можна було показати клієнту у вигляді сервісу. Сервіс - це не запит в традиційному сенсі звернення до даних, скоріше, це витяг деякої бізнес-сутності (або сутностей), яке може бути виконане сервісом інтеграції через серію запитів і інших сервісів. SOA Підхід концентрується, в першу чергу, на визначенні та спільному використанні в формі сервісів щодо обмеженої кількості найважливіших бізнес-функцій в корпорації. Отже, сервіс-орієнтовані інтерфейси в досить великій мірі будуються на обмеженій кількості запитів на необхідну інформацію, яку потрібно представити споживачеві. Маючи відповідні облікові дані системи безпеки, споживач може здійснити вибірку будь-яких даних з джерела через майже необмежену кількість різних запитів SQL. Але для цього споживач повинен мати уявлення про модель джерела даних і способі створення результату з використанням цієї базової моделі. Чим складніше модель джерела даних, тим складнішою може виявитися ця задача.

Інструменти інтеграції даннихРедагувати

  • Alteryx
  • Analytics Canvas
  • dataWerks
  • DataWatch
  • Denodo Platform
  • HiperFabric
  • Lavastorm
  • ParseKit (enigma.io)
  • Paxata
  • RapidMiner Studio
  • http://www.jboss.org/products/datavirt/overview/[недоступне посилання з червень 2019]. Community project: teiid.
  • Azure Data Factory (ADF)
  • SQL Server Integration Services (SSIS)

ДодаткиРедагувати

ПосиланняРедагувати

  1. Інтеграція даних. http://moodle.onaft.edu.ua/pluginfile.php/1165/mod_resource/content/1/Лекція1%20мадо.pdf[недоступне посилання з червень 2019]