Integrarea datelor

Termenul de integrare a datelor se referă la procesele care trebuie implementate pe date provenind din diferite surse de informații pentru a oferi utilizatorului o imagine unificată a acestor date. ^[1]

Istorie

Figura 1: Diagrama simplă a unui depozit de date. Procesul ETL extrage informații din bazele de date sursă, le transformă și le încarcă în depozitul de date.

Figura 2: Diagrama simplă a unei soluții de integrare a datelor. Un proiectant de sistem construiește o schemă mediată prin care utilizatorii pot efectua interogări. Baza de date virtuală se interfață cu bazele de date sursă printr-un wrapper, dacă este necesar.

Au existat de ceva timp probleme în combinarea surselor de date eterogene, adesea identificate ca silozuri de informații, într-o singură interfață de interogare .

La începutul anilor optzeci ai secolului al XX-lea, tehnicienii în computere au început să proiecteze sisteme pentru interoperabilitatea bazelor de date eterogene. ^[2] Primul sistem de integrare a datelor bazat pe metadate structurate a fost proiectat la Universitatea din Minnesota în 1991 pentru seria de microdate cu utilizare publică integrată (IPUMS). IPUMS a folosit o abordare în stilul depozitului de date care extrage, transformă și încarcă date din surse eterogene într-o singură vizualizare pentru ca datele să devină compatibile. ^[3] Prin interoperabilitatea a sute de baze de date legate de populație, IPUMS a demonstrat fezabilitatea integrării datelor pe scară largă. Abordarea depozitului de date oferă o arhitectură strâns cuplată, deoarece datele sunt deja reconciliate fizic într-un singur magazin care poate fi căutat, deci de obicei durează puțin timp pentru a rezolva interogările . ^[4]

Abordarea depozitului de date este mai puțin fezabilă pentru seturile de date actualizate frecvent: aceasta necesită rularea continuă a procesului de extragere, transformare, încărcare (ETL) pentru sincronizare. Dificultăți apar și în construcția depozitelor de date atunci când aveți o interfață de interogare numai pe date sintetizate și nu aveți acces la totalitatea lor. Această problemă apare frecvent la integrarea diferitelor servicii de interogare comercială, cum ar fi călătorii sau aplicații web, cu publicitate clasificată.

Din 2009, tendința integrării datelor a fost cuplarea între datele care oferă o interfață unificată pentru accesarea datelor în timp real printr-o schemă intermediară, care permite preluarea informațiilor direct din bazele de date originale. Acest lucru este în concordanță cu abordarea SOA , populară la acea vreme. Această abordare se bazează pe maparea dintre schema intermediară și schemele sursă originale, transformând o interogare în interogări specializate pe schemele specifice surselor originale. Aceste mapări pot fi definite în două moduri: cu o mapare de la entitățile schemei intermediare la entitățile surselor originale (abordarea „Global As View” (GAV)) sau o mapare de la entitățile surselor originale la entități ale schemei intermediare (abordarea „Local As View” (LAV)). A doua abordare necesită inferențe mai sofisticate pentru a rezolva interogările din schema intermediară, dar facilitează adăugarea de noi surse de date la o schemă intermediară (stabilă).

Din 2010, o parte a activității de cercetare privind integrarea datelor se ocupă de problema integrării semantice. Această problemă nu se referă la modul de structurare a arhitecturii de integrare, ci la modul de rezolvare a conflictelor semantice dintre sursele de date eterogene. De exemplu: dacă două companii își îmbină bazele de date, unele concepte și definiții în schemele lor respective, cum ar fi „câștigurile”, au inevitabil semnificații diferite. Într-o bază de date ar putea însemna profituri în euro (exprimate ca număr zecimal), în timp ce în cealaltă ar putea reprezenta numărul de vânzări (exprimat ca număr întreg). O strategie comună pentru rezolvarea unor astfel de probleme implică utilizarea ontologiilor care definesc în mod explicit termenii schemei și, astfel, ajută la rezolvarea conflictelor semantice. Această abordare reprezintă integrarea datelor bazată pe ontologie. Pe de altă parte, problema combinării rezultatelor căutării din diferite depozite de bioinformatică necesită compararea similitudinilor calculate din diferite surse de date pe un singur criteriu, de exemplu valoarea predictivă pozitivă. Acest lucru permite diferitelor surse pentru comparație directă și pot fi integrate chiar și atunci când natura experimentelor este distinctă. ^[5]

Începând din 2011, s-a realizat că metodele actuale de modelare a datelor imprimau izolarea datelor în fiecare arhitectură sub formă de insule de date și silozuri de informații disparate. Această izolare a datelor este un artefact neintenționat al metodologiei de modelare a datelor care are ca rezultat dezvoltarea de modele de date diferite. Modelele de date diferite, atunci când sunt stocate în baze de date, formează baze de date diferite. Au fost dezvoltate modele avansate de date pentru a elimina artefactul și pentru a promova dezvoltarea de modele integrate de date. ^[6] ^[7] O metodă avansată de modelare a datelor remodelează modelele de date prin mărirea acestora cu metadate structurale, sub formă de entități de date standardizate. Ca urmare a rescrierii mai multor modele de date, setul de modele de date reprelucrate împarte una sau mai multe relații de omogenitate care afectează metadatele structurale comune acum acestor modele de date. Relațiile de omogenitate sunt un tip de relație peer-to-peer între entități, care leagă entități de date de modele multiple standardizate. Mai multe modele de date care conțin aceeași entitate de date standard pot participa la aceeași relație de omogenitate. Când modelele de date integrate sunt instanțiate ca baze de date și sunt populate în mod adecvat de un set comun de date master, aceste baze de date sunt integrate.

Din 2011, abordările de cel mai mare interes pentru disciplină s-au orientat mai mult către centrul de date decât către depozitele de date complet structurate (de obicei relaționale). Din 2013, abordările lacului de date au atins nivelul centrelor de date. (Vezi popularitatea celor trei termeni de căutare pe Google Trends. ^[8] Aceste abordări combină date nestructurate sau diferite într-un singur loc, dar nu necesită neapărat o schemă relațională principală , deseori complexe, pentru a structura și defini toate datele conținute.

Descriere

Acest proces este important în multe situații, atât în cea comercială (gândiți-vă la două companii care trebuie să își îmbine bazele de date ), cât și științifică (de exemplu, combinând rezultatele din diferite arhive de bioinformatică ). Integrarea datelor apare cu o frecvență crescândă, în același mod în care explodează volumul și nevoia de a partaja datele existente. ^[9] Această chestiune a devenit punctul central al unei ample lucrări tehnice și numeroase probleme deschise rămân nerezolvate.

Exemplu

Luați în considerare o aplicație web în care un utilizator poate solicita o varietate de informații despre orașe (cum ar fi statistici privind criminalitatea, vreme, hoteluri, date demografice etc.). În mod tradițional, informațiile trebuie stocate într-o singură bază de date cu o singură schemă. Dar oricărei companii ar fi dificil și costisitor să adune informații în această măsură. Chiar dacă resursele există pentru a colecta date, acestea ar reproduce datele în bazele de date criminologice existente, site-urile meteorologice și datele recensământului. O soluție de integrare poate aborda această problemă considerând resursele externe ca vederi materializate pe o schemă virtuală mediată , rezultând „integrarea datelor virtuale”. Aceasta înseamnă că dezvoltatorii de aplicații construiesc o schemă virtuală - schema mediată - pentru a modela mai bine tipul de răspunsuri dorite de utilizatorii lor. Apoi, proiectează ambalaje sau adaptoare pentru fiecare sursă de date, cum ar fi baza de date criminologică și situl meteorologic. Aceste adaptoare transformă pur și simplu rezultatele interogărilor locale (cele returnate de pe site-urile sau bazele de date respective) într-un formular ușor de procesat pentru soluția integrată. Când un utilizator interogă schema mediată, soluția integrată transformă interogarea într-o interogare adecvată pe sursele de date respective. În cele din urmă, baza de date virtuală grupează rezultatele acestor interogări în răspunsul la interogarea utilizatorului.

Această soluție oferă avantajul de a putea adăuga surse noi prin simpla construire a unui adaptor adecvat sau a unui software de contact. Acest lucru este în contrast cu sistemele ETL sau cu o singură soluție de bază de date, care necesită integrarea manuală a întregului set de date nou în sistem. Soluția virtuală ETL influențează schema virtuală mediată pentru a implementa armonizarea datelor, prin care datele sunt copiate de la sursa desemnată ca „principală” la obiectivele definite, câmp cu câmp. Virtualizarea avansată a datelor este, de asemenea, construită pe conceptul de modelare orientată pe obiecte, pentru a construi scheme virtuale mediate sau arhive de metadate virtuale folosind arhitectura hub și spiță .

Fiecare sursă de date este diversă și, ca atare, nu este concepută pentru a susține fuziuni fiabile cu alte surse. Deci, virtualizarea datelor, precum și federarea datelor , depind de omogenitatea fortuită a datelor pentru a sprijini combinația de date și informații din diverse surse de date. Datorită acestei lipse de omogenitate între date, setul rezultat poate fi inexact, incomplet sau imposibil de validat.

O soluție este de a remodela bazele de date eterogene pentru a le integra fără a fi nevoie de ETL. Bazele de date reelaborate acceptă constrângeri de omogenitate în care integritatea referențială poate fi impusă între bazele de date. În plus, aceste baze de date remodelate oferă căi de acces la date proiectate cu omogenitate a valorilor între baze de date.

Teoria integrării datelor

Teoria integrării datelor constituie un subset al teoriei bazelor de date și formalizează conceptele care stau la baza problemei prin logica de ordinul întâi . Aplicând teoriile, oferă o indicație a fezabilității și dificultății integrării. Deși teoriile sale pot părea abstracte, ele se bucură de o generalitate suficientă pentru a se potrivi tuturor sistemelor de integrare, ^[10] inclusiv cele care includ baze de date relaționale sau XML imbricate ^[11] și cele care tratează bazele de date ca programe ^[12] . Conexiunile la anumite DBMS-uri, cum ar fi Oracle sau DB2, sunt furnizate de tehnologii la nivel de implementare, cum ar fi JDBC , și nu sunt studiate la nivel teoretic.

Definiții

Sistemele de integrare a datelor sunt definite formal printr-un triplu $\left\langle G,S,M\right\rangle$ ${\ displaystyle \ left \ langle G, S, M \ right \ rangle}$ ${\ displaystyle \ left \ langle G, S, M \ right \ rangle}$ unde este $G.$ ${\ displaystyle G}$ $G.$ este schema globală, $S.$ ${\ displaystyle S}$ $S.$ este setul eterogen de scheme sursă și $M.$ ${\ displaystyle M}$ $M.$ este maparea care asociază interogările între surse și schema globală. Amândoi $G.$ ${\ displaystyle G}$ $G.$ Și $S.$ ${\ displaystyle S}$ $S.$ sunt exprimate în limbaj pe alfabete compuse din simboluri pentru fiecare dintre relațiile respective. Cartografierea $M.$ ${\ displaystyle M}$ $M.$ constă în afirmații între interogări pe $G.$ ${\ displaystyle G}$ $G.$ și interogare $S.$ ${\ displaystyle S}$ $S.$ . Când utilizatorii pun la îndoială sistemul de integrare a datelor , aceștia pun întrebări despre $G.$ ${\ displaystyle G}$ $G.$ iar maparea acceptă conexiunile dintre elementele din schema globală și din schemele sursă.

O bază de date pe o schemă este definită ca o colecție de seturi, câte una pentru fiecare relație (într-o bază de date relațională). Baza de date corespunzătoare schemei sursă $S.$ ${\ displaystyle S}$ $S.$ ar trebui să cuprindă setul de seturi de tupluri pentru fiecare sursă eterogenă și se numește baza de date sursă . Rețineți că această bază de date sursă unică poate reprezenta de fapt o colecție de baze de date deconectate. Baza de date corespunzătoare schemei virtuale intermediare $G.$ ${\ displaystyle G}$ $G.$ se numește o bază de date globală . Baza de date locală trebuie să satisfacă maparea $M.$ ${\ displaystyle M}$ $M.$ comparativ cu baza de date sursă. Legitimitatea acestei mapări depinde de natura corespondenței dintre $G.$ ${\ displaystyle G}$ $G.$ Și $S.$ ${\ displaystyle S}$ $S.$ . Există două modele populare pentru modelarea acestei corespondențe: Global View sau GAV și Local View sau LAV.

Figura 3: Ilustrația spațiului tuplu în mapările GAV și LAV. ^[13] În GAV, sistemul este legat de setul de tupluri mapate de mediatori în timp ce setul de tupluri exprimabile pe surse ar putea fi mai mare și mai bogat. În LAV, sistemul este legat de setul de tupluri din surse în timp ce setul de tupluri exprimabile în schema globală poate fi mai extins. Prin urmare, sistemele LAV trebuie adesea să facă față răspunsurilor incomplete.

Sistemele GAV modelează baza de date globală ca un set de vizualizări $S.$ ${\ displaystyle S}$ $S.$ . În acest caz $M.$ ${\ displaystyle M}$ $M.$ se asociază cu fiecare element al $G.$ ${\ displaystyle G}$ $G.$ o întrebare despre $S.$ ${\ displaystyle S}$ $S.$ . Procesarea interogărilor devine simplă datorită asocierilor bine definite între $G.$ ${\ displaystyle G}$ $G.$ Și $S.$ ${\ displaystyle S}$ $S.$ . Sarcina complexității revine implementării codului mediatorului pentru a instrui sistemul de integrare a datelor în modul exact de recuperare a articolelor din bazele de date sursă. Dacă se adaugă alte surse la sistem, ar putea fi necesar un efort mare pentru actualizarea mediatorului, astfel încât abordarea GAV pare preferabilă atunci când sursele au o probabilitate redusă de schimbare.

În abordarea GAV a sistemului de integrare a datelor din exemplu, proiectantul ar trebui să dezvolte mai întâi mediatori pentru fiecare sursă de informații pentru cetățeni și apoi să proiecteze schema generală în jurul acestor mediatori. De exemplu, să ne gândim dacă una dintre surse a servit un site web despre vreme. Proiectantul ar adăuga probabil un element corespunzător vremii la schema generală. Apoi, cea mai mare parte a efortului se concentrează pe scrierea codului de mediere adecvat care transformă predicatele despre vreme în interogări ale sitului meteorologic. Acest efort poate deveni complex dacă și o altă sursă are o afinitate pentru vreme, deoarece proiectantul ar putea avea nevoie să scrie codul pentru a combina corect rezultatele din cele două surse.

Cu toate acestea, în LAV, baza de date sursă este modelată ca un set de vizualizări $G.$ ${\ displaystyle G}$ $G.$ . În acest caz $M.$ ${\ displaystyle M}$ $M.$ se asociază cu fiecare element al $S.$ ${\ displaystyle S}$ $S.$ o întrebare despre $G.$ ${\ displaystyle G}$ $G.$ . Aici asociațiile exacte dintre $G.$ ${\ displaystyle G}$ $G.$ Și $S.$ ${\ displaystyle S}$ $S.$ nu mai sunt bine definite. După cum este ilustrat în secțiunea următoare, sarcina alegerii modului de preluare a articolelor din surse revine procesorului de interogare . Avantajul modelării LAV este că se pot adăuga surse noi cu mult mai puțină cheltuială de energie decât un sistem GAV, prin urmare abordarea LAV ar trebui preferată în cazurile în care schema intermediară este mai puțin stabilă sau mai ușor de modificat. Într-o abordare LAV a sistemului de integrare a datelor din exemplul anterior, proiectantul sistemului proiectează schema generală și apoi introduce pur și simplu schemele surselor de informații ale orașelor respective. Să considerăm din nou că una dintre surse servește un site meteorologic: proiectantul ar trebui să adauge elemente corespunzătoare vremii la schema globală numai dacă acestea nu există deja. Apoi, programatorii ar scrie un adaptor sau un wrapper pentru site și ar adăuga o descriere a schemei de rezultate a site-ului la schemele sursă. Complexitatea adăugării de noi surse se schimbă de la proiectant la procesorul de interogare .

Procesarea interogării

Teoria procesării interogărilor într-un sistem de integrare a datelor este exprimată în mod obișnuit folosind interogări conjunctive și Datalog , un limbaj de programare logică pur declarativă. ^[14] Vă puteți gândi liber la o interogare ca la o funcție logică aplicată relațiilor bazei de date, cum ar fi „ $f(A,B)$ ${\ displaystyle f (A, B)}$ $f (A, B)$ unde este $A<B$ ${\ displaystyle A <B}$ ${\ displaystyle A <B}$ “. În cazul în care un tuplu sau un set de tuple este substituit în regulă și satisface ea (adică , face adevărat), atunci considerăm că o parte uplu a setului de răspuns de interogare. În timp ce formale Datalog- stil de limbi exprima aceste întrebări succint și lipsit de ambiguitate., interogările SQL comune sunt, de asemenea, considerate ca interogări conjunctive.

În ceea ce privește integrarea datelor, „conținerea interogărilor ” este o proprietate importantă a interogărilor conjunctive. O interogare $LA$ ${\ displaystyle A}$ $LA$ conține o altă interogare $B.$ ${\ displaystyle B}$ $B.$ (în simboluri $A\supset B$ ${\ displaystyle A \ supset B}$ ${\ displaystyle A \ supset B}$ ) dacă rezultatele $B.$ ${\ displaystyle B}$ $B.$ sunt un subset al rezultatelor $LA$ ${\ displaystyle A}$ $LA$ pentru fiecare bază de date. Se spune că cele două interogări sunt echivalente dacă seturile rezultate sunt aceleași pentru fiecare bază de date. Acest lucru este important deoarece atât în sistemele GAV, cât și în sistemele LAV, un utilizator plasează interogări conjunctive pe o schemă virtuală reprezentată de un set de vizualizări sau interogări conjunctive materializate . Integrarea își propune să rescrie interogările reprezentate de vizualizări pentru a face rezultatele echivalente sau cel mult conținute în solicitarea utilizatorului nostru. Aceasta corespunde problemei răspunsului la interogări folosind vizualizări. ^[15]

În sistemele GAV, un designer scrie codul brokerului pentru a defini rescrierea interogării . Fiecare element din interogarea utilizatorului se potrivește cu o regulă de substituție la fel cum fiecare element din schema globală se potrivește cu o interogare din sursă. Procesarea interogării extinde pur și simplu sub-obiectivele interogării utilizatorului în conformitate cu regulile specificate în mediator, astfel încât interogarea rezultată este probabil să fie echivalentă. În timp ce proiectantul face cea mai mare parte a lucrării în avans, unele sisteme BCD precum Tsimmis implică simplificarea procesului de descriere a mediatorului.

În sistemele LAV, interogările trec printr-un proces de rescriere mai radical, deoarece nu există un mediator care să alinieze interogările utilizatorilor cu o strategie simplă de extindere. Sistemul de integrare trebuie să efectueze o căutare a spațiului de interogare posibil pentru a găsi cea mai bună rescriere. Rescrierea rezultată poate să nu fie o interogare echivalentă, dar conținută maxim, iar tuplurile returnate pot fi incomplete. Din 2009, algoritmul MiniCon ^[15] este algoritmul principal în rescrierea interogărilor pentru sistemele de integrare a datelor LAV.

În general, complexitatea rescrierii interogărilor este complet NP . ^[15] Dacă spațiul de rescriere este relativ mic, aceasta nu este o problemă - chiar și pentru sistemele de integrare cu sute de surse.

Instrumente de integrare a datelor

Alteryx
Canvas Analytics
Platforma Ultrawrap de la Capsenta
Integrare API Cloud Elements
DataWatch
dataWerks
Platforma Denodo
Platformă de integrare elastic.io
HiperFabric ^[16]
Microsoft PowerQuery
Lavastorm
Platformă Informatica ^[17]
Servicii de integrare a datelor Oracle
ParseKit (enigma.io)
Paxata
RapidMinder Studio
Virtualizarea datelor Red Hat JBoss. Proiect comunitar: teiid.
Azure Data Factory (ADF)
Servicii de integrare SQL Server (SSIS)
TMMData ^[18]
WinPure ^[19]

Integrarea datelor în viața științifică

Întrebări științifice la scară largă, precum încălzirea globală, răspândirea dăunătorilor și epuizarea resurselor necesită tot mai mult colectarea de date eterogene pentru meta-analiză. Acest tip de integrare este deosebit de dificil pentru datele de mediu și ecologice, deoarece standardele de metadate nu sunt convenite și există multe tipuri diferite de date produse în aceste domenii. Inițiativele Fundației Naționale a Științei , cum ar fi Datanet, sunt destinate să faciliteze integrarea datelor de către oamenii de știință, oferind infrastructură IT și setări standard. Cele cinci inițiative Datanet finanțate sunt:

DataONE, condus de William Michener la Universitatea din New Mexico ;
Data Conservancy, condus de Sayeed Choudhury de la Universitatea Johns Hopkins ;
SEAD (Sustainable Environment through Actionable Data), condus de Margaret Hedstrom de la Universitatea din Michigan ;
DataNet Federation Consortium, condus de Reagan Moore de la Universitatea din Carolina de Nord ;
Terra Populus, condusă de Steven Ruggles de la Universitatea din Minnesota ;

Data Conservancy a explorat recent crearea de structuri de integrare globală. Proiectul OpenPHACTS, finanțat prin Inițiativa Medicamentelor Inovatoare a Uniunii Europene , a construit o platformă de descoperire a medicamentelor prin conectarea seturilor de date de la furnizori precum Institutul European de Bioinformatică , Societatea Regală de Chimie , UniProt , WikiPathways și DrugBank .

Notă

^ Maurizio Lenzerini , Integrarea datelor: o perspectivă teoretică ( PDF ), în PODS 2002 , 2002, pp. 233–246.
^ John Miles Smith, Multibase: integrarea sistemelor de baze de date distribuite eterogene , în AFIPS '81 Proceedings of the 4-7 May, 1981, national computer conference , 1982, pp. 487-499.
^ Steven Ruggles , J. David Hacker și Matthew Sobek, Order out of Chaos: The Integrated Public Use Microdata Series , în Historical Methods , vol. 28, 1995, pp. 33–39.
^ Jennifer Widom, Probleme de cercetare în stocarea datelor , în CIKM '95 Proceedings of the 4th international conference on information and knowledge management , 1995, pp. 25-30.
^ Shubhra S. Ray, Combinarea informațiilor multi-sursă prin ponderarea funcțională a adnotării funcționale: Predicția funcției genei în drojdie ( PDF ), în IEEE Transactions on Biomedical Engineering , vol. 56, nr. 2, 2009, pp. 229–236, DOI : 10.1109 / TBME.2008.2005955 , PMID 19272921 .
^ Michael Mireku Kwakye, O abordare practică a fuzionării modelelor de date multidimensionale , 2011.
^ Rapid Architectural Consolidation Engine - Soluția întreprinderii pentru modele de date disparate. ( PDF ), pe iri.com , 2011. Adus la 5 decembrie 2016 (arhivat din original la 24 septembrie 2015) .
^ Tendințele căutării Hub Lake și Warehouse , pe google.com .
^ Frederick Lane, IDC: World a creat 161 miliarde de date în 2006 IDC: World a creat 161 miliarde de date în 2006 , 2006.
^ O teorie a modelului pentru gestionarea schemei generice , la link.springer.com .
^ Mappings imbricate: Schema Mapping Reloaded ( PDF ), pe vldb.org .
^ Inițiativa comună pentru specificarea algebrică și dezvoltarea software-ului ( PDF ), la homepages.inf.ed.ac.uk .
^ Christoph Koch, Integrarea datelor împotriva schemelor autonome în evoluție multiplă ( PDF ), 2001 (arhivat din original la 26 septembrie 2007) .
^ Jeffrey D. Ullman , Information Integration Using Logical Views ( ps ), în ICDT 1997 , 1997, pp. 19–40.
^ ^a ^b ^c Alon Y. Halevy , Răspuns la întrebări folosind vizualizări: Un sondaj ( PDF ), în The VLDB Journal , 2001, pp. 270–294.
^ Copie arhivată , pe hiperfabric.com . Adus pe 2 octombrie 2019 (arhivat din original la 20 martie 2018) .
^ (EN) Computing , pe informatica.com.
^ (EN) TMMData , pe tmmdata.com.
^ (EN) WinPure , pe winpure.com.

Elemente conexe

Controlul autorității	GND ( DE ) 4197730-0

Portal IT : accesați intrările Wikipedia care se ocupă cu IT

[refone-1] Maurizio Lenzerini , Integrarea datelor: o perspectivă teoretică ( PDF ), în PODS 2002 , 2002, pp. 233–246.

[2] John Miles Smith, Multibase: integrarea sistemelor de baze de date distribuite eterogene , în AFIPS '81 Proceedings of the 4-7 May, 1981, national computer conference , 1982, pp. 487-499.

[3] Steven Ruggles , J. David Hacker și Matthew Sobek, Order out of Chaos: The Integrated Public Use Microdata Series , în Historical Methods , vol. 28, 1995, pp. 33–39.

[4] Jennifer Widom, Probleme de cercetare în stocarea datelor , în CIKM '95 Proceedings of the 4th international conference on information and knowledge management , 1995, pp. 25-30.

[5] Shubhra S. Ray, Combinarea informațiilor multi-sursă prin ponderarea funcțională a adnotării funcționale: Predicția funcției genei în drojdie ( PDF ), în IEEE Transactions on Biomedical Engineering , vol. 56, nr. 2, 2009, pp. 229–236, DOI : 10.1109 / TBME.2008.2005955 , PMID 19272921 .

[6] Michael Mireku Kwakye, O abordare practică a fuzionării modelelor de date multidimensionale , 2011.

[7] Rapid Architectural Consolidation Engine - Soluția întreprinderii pentru modele de date disparate. ( PDF ), pe iri.com , 2011. Adus la 5 decembrie 2016 (arhivat din original la 24 septembrie 2015) .

[8] Tendințele căutării Hub Lake și Warehouse , pe google.com .

[DataExplode-9] Frederick Lane, IDC: World a creat 161 miliarde de date în 2006 IDC: World a creat 161 miliarde de date în 2006 , 2006.

[10] O teorie a modelului pentru gestionarea schemei generice , la link.springer.com .

[11] Mappings imbricate: Schema Mapping Reloaded ( PDF ), pe vldb.org .

[12] Inițiativa comună pentru specificarea algebrică și dezvoltarea software-ului ( PDF ), la homepages.inf.ed.ac.uk .

[refseven-13] Christoph Koch, Integrarea datelor împotriva schemelor autonome în evoluție multiplă ( PDF ), 2001 (arhivat din original la 26 septembrie 2007) .

[reffive-14] Jeffrey D. Ullman , Information Integration Using Logical Views ( ps ), în ICDT 1997 , 1997, pp. 19–40.

[refsix-15] Alon Y. Halevy , Răspuns la întrebări folosind vizualizări: Un sondaj ( PDF ), în The VLDB Journal , 2001, pp. 270–294.

[16] Copie arhivată , pe hiperfabric.com . Adus pe 2 octombrie 2019 (arhivat din original la 20 martie 2018) .

[17] (EN) Computing , pe informatica.com.

[18] (EN) TMMData , pe tmmdata.com.

[19] (EN) WinPure , pe winpure.com.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]