Integrace dat - Data integration

Přehrát média

Úvodní video o integraci údajů o exemplářích v botanických sbírkách se sběrateli exemplářů

Integrace dat zahrnuje kombinování dat z různých zdrojů a poskytování jednotného pohledu uživatelům na ně. Tento proces se stává významným v nejrůznějších situacích, které zahrnují jak komerční (například když dvě podobné společnosti potřebují sloučit své databáze ), tak vědecké (například kombinace výsledků výzkumu z různých úložišť bioinformatiky ). Integrace dat se objevuje s rostoucí frekvencí, protože exploduje objem (tj. Velká data ) a potřeba sdílet existující data . Stala se předmětem rozsáhlé teoretické práce a řada otevřených problémů zůstává nevyřešena. Integrace dat podporuje spolupráci mezi interními i externími uživateli. Integrovaná data musí být přijímána z heterogenního databázového systému a transformována do jediného soudržného úložiště dat, které poskytuje synchronní data v síti souborů pro klienty. Běžné použití integrace dat spočívá v dolování dat při analýze a extrakci informací z existujících databází, které mohou být užitečné pro obchodní informace .

Dějiny

Obrázek 1: Jednoduché schéma pro datový sklad. Proces Extrahovat, transformovat, načíst (ETL) extrahuje informace ze zdrojových databází, transformuje je a poté načte do datového skladu.

Obrázek 2: Jednoduché schéma řešení integrace dat. Návrhář systému vytvoří zprostředkované schéma, proti kterému mohou uživatelé spouštět dotazy. Tyto databáze virtuální rozhraní s databází zdrojových přes obálky kódu v případě potřeby.

Po nějakou dobu existovaly problémy s kombinováním heterogenních zdrojů dat, často označovaných jako informační sila , v rámci jediného rozhraní dotazu. Na začátku 80. let začali počítačoví vědci navrhovat systémy pro interoperabilitu heterogenních databází. První systém pro integraci dat poháněný strukturovanými metadaty byl navržen na univerzitě v Minnesotě v roce 1991 pro integrovanou veřejnou mikrodatovou sérii (IPUMS) . IPUMS použil přístup datového skladu , který extrahuje, transformuje a načte data z heterogenních zdrojů do jedinečného schématu zobrazení, aby se data z různých zdrojů stala kompatibilní. Díky interoperabilitě tisíců populačních databází IPUMS prokázal proveditelnost rozsáhlé integrace dat. Přístup datového skladu nabízí úzce propojenou architekturu, protože data jsou již fyzicky sladěna v jednom dotazovatelném úložišti, takže řešení dotazů obvykle trvá jen málo času.

Přístup k datovému skladu je méně proveditelný pro datové sady, které jsou často aktualizovány, což vyžaduje, aby byl proces synchronizace extrahován, transformován a načítán (ETL) nepřetržitě znovu spouštěn. Problémy vznikají také při konstrukci datových skladů, když má člověk pouze rozhraní dotazu na souhrnné zdroje dat a nemá přístup k úplným datům. Tento problém se často objevuje při integraci několika komerčních dotazovacích služeb, jako jsou cestovní nebo klasifikované reklamní webové aplikace.

Od roku 2009 upřednostňoval trend v integraci dat volné spojení dat a poskytování jednotného rozhraní dotazů pro přístup k datům v reálném čase přes zprostředkované schéma (viz obrázek 2), které umožňuje získávání informací přímo z původních databází. To je v souladu s přístupem SOA populárním v té době. Tento přístup se opírá o mapování mezi zprostředkovaným schématem a schématem původních zdrojů a překlad dotazu do rozložených dotazů tak, aby odpovídaly schématu původních databází. Taková mapování lze určit dvěma způsoby: jako mapování z entit ve zprostředkovaném schématu na entity v původních zdrojích (přístup „Global-as-View“ (GAV)), nebo jako mapování z entit v původních zdrojích na zprostředkované schéma (přístup „Local-as-View“ (LAV)). Druhý přístup vyžaduje složitější závěry k vyřešení dotazu na zprostředkovaném schématu, ale usnadňuje přidávání nových zdrojů dat do (stabilního) zprostředkovaného schématu.

Od roku 2010 se část práce ve výzkumu integrace dat týká problému sémantické integrace . Tento problém se nezabývá strukturováním architektury integrace, ale tím, jak řešit sémantické konflikty mezi heterogenními zdroji dat. Například pokud dvě společnosti spojí své databáze, určité pojmy a definice v jejich příslušných schématech, například „výdělky“, mají nevyhnutelně různé významy. V jedné databázi to může znamenat zisky v dolarech (číslo s plovoucí desetinnou čárkou), zatímco v druhé to může představovat počet prodejů (celé číslo). Společná strategie řešení těchto problémů zahrnuje použití ontologií, které explicitně definují pojmy schématu, a tak pomáhají řešit sémantické konflikty. Tento přístup představuje ontologickou integraci dat . Na druhé straně problém kombinování výsledků výzkumu z různých úložišť bioinformatiky vyžaduje srovnávání podobností, počítaných z různých zdrojů dat, na jednom kritériu, jako je pozitivní prediktivní hodnota. To umožňuje, aby zdroje dat byly přímo srovnatelné a lze je integrovat, i když jsou povahy experimentů odlišné.

Od roku 2011 bylo zjištěno, že současné metody modelování dat propůjčují izolaci dat do každé datové architektury ve formě ostrovů různorodých dat a informačních sil. Tato izolace dat je nezamýšleným artefaktem metodiky modelování dat, která vede k vývoji různorodých datových modelů. Odlišné datové modely, jsou-li vytvořeny jako databáze, tvoří různorodé databáze. Byly vyvinuty vylepšené metodiky datových modelů, které eliminují artefakt izolace dat a podporují vývoj integrovaných datových modelů. Jedna vylepšená metoda modelování dat přepracovává datové modely jejich rozšířením o strukturální metadata ve formě standardizovaných datových entit. V důsledku přepracování více datových modelů bude sada přepracovaných datových modelů nyní sdílet jeden nebo více vztahů shodnosti, které souvisejí se strukturálními metadaty, která jsou nyní společná pro tyto datové modely. Vztahy commonality jsou peer-to-peer typy vztahů entit, které souvisejí se standardizovanými datovými entitami více datových modelů. Více datových modelů, které obsahují stejnou standardní datovou entitu, se může účastnit stejného vztahu shodnosti. Pokud jsou integrované datové modely vytvořeny jako databáze a jsou správně vyplněny ze společné sady kmenových dat, jsou tyto databáze integrovány.

Od roku 2011 mají přístupy k datovým uzlům větší zájem než plně strukturované (obvykle relační) podnikové datové sklady. Od roku 2013 se přístupy k datovému jezeru zvýšily na úroveň datových hubů. (Podívejte se na popularitu všech tří hledaných výrazů v Trendech Google.) Tyto přístupy kombinují nestrukturovaná nebo různorodá data do jednoho místa, ale ke struktuře a definování všech dat v Hubu nutně nevyžadují (často složité) hlavní relační schéma.

Integrace dat hraje v podnikání velkou roli, pokud jde o sběr dat používaných ke studiu trhu. Konverze nezpracovaných dat získaných od spotřebitelů na soudržná data je něco, co se podniky snaží udělat, když zvažují, jaké kroky by měly podniknout dále. Organizace častěji používají dolování dat ke shromažďování informací a vzorů ze svých databází a tento proces jim pomáhá vyvíjet nové obchodní strategie, které zvyšují výkonnost podnikání a provádějí efektivnější ekonomické analýzy. Kompilace velkého množství dat, která shromažďují, aby byla uložena do jejich systému, je formou integrace dat přizpůsobené pro Business Intelligence, aby se zvýšila jejich šance na úspěch.

Příklad

Zvažte webovou aplikaci, kde může uživatel vyhledávat nejrůznější informace o městech (například statistiky kriminality, počasí, hotely, demografie atd.). Tradičně musí být informace uloženy v jedné databázi s jediným schématem. Ale pro každý jednotlivý podnik by byly informace o této šíři shledány poněkud obtížně a nákladně. I kdyby zdroje pro shromažďování údajů existovaly, pravděpodobně by duplikovalo data ve stávajících databázích kriminality, webech o počasí a údajích ze sčítání lidu.

Řešení integrace dat může vyřešit tento problém tím, že tyto externí zdroje budou považovat za zhmotněná zobrazení přes virtuální zprostředkované schéma , což povede k „integraci virtuálních dat“. To znamená, že vývojáři aplikací zkonstruují virtuální schéma - zprostředkované schéma -, aby co nejlépe modelovali druhy odpovědí, které jejich uživatelé chtějí. Dále navrhnou „obaly“ nebo adaptéry pro každý zdroj dat, jako je databáze zločinů a web o počasí. Tyto adaptéry jednoduše transformují výsledky místních dotazů (ty, které vracejí příslušné webové stránky nebo databáze) do snadno zpracovatelné formy pro řešení integrace dat (viz obrázek 2). Když uživatel aplikace dotazuje zprostředkované schéma, řešení integrace dat transformuje tento dotaz na příslušné dotazy přes příslušné zdroje dat. Nakonec virtuální databáze kombinuje výsledky těchto dotazů do odpovědi na dotaz uživatele.

Toto řešení nabízí pohodlí přidávání nových zdrojů jednoduchou konstrukcí adaptéru nebo blade aplikačního softwaru pro ně. Kontrastuje se systémy ETL nebo s jediným databázovým řešením, které vyžaduje ruční integraci celé nové datové sady do systému. Virtuální řešení ETL využívají virtuální zprostředkované schéma k implementaci harmonizace dat; přičemž data jsou kopírována z určeného „hlavního“ zdroje do definovaných cílů, pole po poli. Pokročilá virtualizace dat je také postavena na konceptu objektově orientovaného modelování za účelem konstrukce virtuálního zprostředkovaného schématu nebo úložiště virtuálních metadat pomocí architektury hub a paprsků .

Každý zdroj dat je nesourodý a jako takový není navržen tak, aby podporoval spolehlivé spojení mezi zdroji dat. Proto virtualizace dat i federace dat závisí na náhodných shodách dat, které podporují kombinování dat a informací z různorodých datových sad. Z důvodu nedostatku společné hodnoty datové hodnoty napříč zdroji dat může být návratová sada nepřesná, neúplná a nelze ji ověřit.

Jedním z řešení je přepracovat různorodé databáze a integrovat tyto databáze bez nutnosti použití ETL . Přepracované databáze podporují omezení společných rysů, kde lze mezi databázemi vynutit referenční integritu. Přepracované databáze poskytují navržené přístupové cesty k datům se shodou datových hodnot napříč databázemi.

Teorie

Teorie integrace dat tvoří podmnožinu teorie databází a formalizuje základní pojmy problému v logice prvního řádu . Aplikování teorií naznačuje, jak je proveditelné a obtížné integrovat data. I když se jeho definice mohou zdát abstraktní, mají dostatečnou obecnost, aby vyhovovaly všem možným integračním systémům, včetně těch, které obsahují vnořené relační / XML databáze a těch, které s databázemi zacházejí jako s programy. Připojení k určitým databázovým systémům, jako je Oracle nebo DB2, jsou poskytovány technologiemi na úrovni implementace, jako je JDBC, a nejsou studovány na teoretické úrovni.

Definice

Systémy integrace dat jsou formálně definovány jako n-tice, kde je globální (nebo zprostředkované) schéma, je heterogenní sada zdrojových schémat a je mapováním, které mapuje dotazy mezi zdrojem a globálními schématy. Oba a jsou vyjádřeny v jazycích nad abecedou složených ze symbolů pro každý ze svých vztahů . Mapování se skládá z tvrzení mezi dotazů nad a dotazů přes . Když uživatelé kladou dotazy přes systém integrace dat, kladou dotazy znovu a mapování poté potvrzuje spojení mezi prvky v globálním schématu a zdrojovými schématy. ${\ displaystyle \ left \ langle G, S, M \ right \ rangle}$${\ displaystyle G}$${\ displaystyle S}$${\ displaystyle M}$${\ displaystyle G}$${\ displaystyle S}$ ${\ displaystyle M}$${\ displaystyle G}$${\ displaystyle S}$${\ displaystyle G}$

Databáze přes schéma je definována jako sada sad, jedna pro každou relaci (v relační databázi). Databáze odpovídající zdrojovému schématu by obsahovala sadu sad n-tic pro každý z heterogenních zdrojů dat a nazývá se zdrojová databáze . Všimněte si, že tato zdrojová databáze může ve skutečnosti představovat kolekci odpojených databází. Databáze odpovídající virtuálnímu zprostředkovanému schématu se nazývá globální databáze . Globální databáze musí vyhovovat mapování s ohledem na zdrojovou databázi. Zákonnost tohoto mapování závisí na povaze korespondence mezi a . Existují dva populární způsoby modelování této korespondence: globální jako zobrazení nebo GAV a místní jako zobrazení nebo LAV. ${\ displaystyle S}$${\ displaystyle G}$${\ displaystyle M}$${\ displaystyle G}$${\ displaystyle S}$

Obrázek 3: Ilustrace prostoru n-tice mapování GAV a LAV. V GAV je systém omezen na sadu n-tic mapovaných mediátory, zatímco sada n-tic vyjádřených přes zdroje může být mnohem větší a bohatší. V LAV je systém omezen na sadu n-tic ve zdrojích, zatímco sada n-tic vyjádřených přes globální schéma může být mnohem větší. Systémy LAV se proto často musí vypořádat s neúplnými odpověďmi.

Gav systémy modelovat globální databázi jako soubor názorů nad . V tomto případě se přidruží ke každému prvku dotazu . Zpracování dotazů se stává přímočarou operací díky dobře definovaným asociacím mezi a . Břemeno složitosti spočívá na implementaci kódu zprostředkovatele, který dává systému integrace dat pokyn, jak přesně načíst prvky ze zdrojových databází. Pokud se do systému připojí nějaké nové zdroje, bude pravděpodobně nutné vynaložit značné úsilí na aktualizaci mediátora, a proto se přístup GAV jeví jako vhodnější, pokud se zdá, že se zdroje nezmění. ${\ displaystyle S}$${\ displaystyle M}$${\ displaystyle G}$${\ displaystyle S}$${\ displaystyle G}$${\ displaystyle S}$

V GAV přístupu k výše uvedenému příkladu systému integrace dat by návrhář systému nejprve vyvinul mediátory pro každý z městských informačních zdrojů a poté navrhl globální schéma kolem těchto mediátorů. Zvažte například, zda jeden ze zdrojů sloužil webové stránce o počasí. Návrhář by pak pravděpodobně přidal odpovídající prvek pro počasí do globálního schématu. Velká část úsilí se poté soustředí na psaní správného kódu zprostředkovatele, který převede predikáty počasí na dotaz na web o počasí. Toto úsilí může být složité, pokud se nějaký jiný zdroj týká také počasí, protože návrhář možná bude muset napsat kód, aby správně kombinoval výsledky ze dvou zdrojů.

Na druhou stranu, v LAV, zdrojová databáze je modelován jako soubor názorů nad . V tomto případě se přidruží ke každému prvku dotazu . Zde již nejsou přesně definovány přesné asociace mezi a . Jak je znázorněno v další části, zátěž spočívající v určení, jak načíst prvky ze zdrojů, je umístěna na procesor dotazu. Výhodou modelování LAV je, že lze přidat nové zdroje s mnohem méně práce než v systému GAV, proto by měl být přístup LAV upřednostňován v případech, kdy je zprostředkované schéma méně stabilní nebo se pravděpodobně změní. ${\ displaystyle G}$${\ displaystyle M}$${\ displaystyle S}$${\ displaystyle G}$${\ displaystyle G}$${\ displaystyle S}$

V přístupu LAV k výše uvedenému příkladu systému integrace dat návrhář systému nejprve navrhne globální schéma a poté jednoduše zadá schémata příslušných informačních zdrojů města. Zvažte znovu, pokud jeden ze zdrojů slouží webové stránce o počasí. Návrhář by do globálního schématu přidal odpovídající prvky pro počasí, pouze pokud žádné dosud neexistovaly. Poté programátoři napíšou pro web adaptér nebo obálku a do zdrojových schémat přidají popis schématu výsledků webu. Složitost přidání nového zdroje se přesune z návrháře do procesoru dotazu.

Zpracování dotazů

Teorie zpracování dotazů v systémech integrace dat se běžně vyjadřuje pomocí konjunktivních dotazů a Datalog , čistě deklarativního logického programovacího jazyka. Jeden může volně myslet na konjunktivní dotaz jako na logickou funkci aplikovanou na vztahy databáze, jako je „ kde “. Pokud je n-tice nebo sada n-tic nahrazena pravidlem a splňuje ji (činí to pravdivou), pak tuto n-tici považujeme za součást sady odpovědí v dotazu. Zatímco formální jazyky jako Datalog vyjadřují tyto dotazy stručně a bez dvojznačnosti, běžné dotazy SQL se počítají také jako konjunktivní dotazy. ${\ displaystyle f (A, B)}$${\ displaystyle A <B}$

Pokud jde o integraci dat, „zadržování dotazů“ představuje důležitou vlastnost spojovacích dotazů. Dotaz obsahuje další dotaz (označený ), pokud jsou výsledky aplikace podmnožinou výsledků aplikace pro libovolnou databázi. Dva dotazy se považují za ekvivalentní, pokud jsou výsledné sady stejné pro libovolnou databázi. To je důležité, protože v systémech GAV i LAV zadává uživatel konjunktivní dotazy přes virtuální schéma představované množinou pohledů nebo „materializované“ konjunktivní dotazy. Integrace se snaží přepsat dotazy představované pohledy, aby byly jejich výsledky ekvivalentní nebo maximálně obsažené v dotazu našeho uživatele. To odpovídá problému s odpovědí na dotazy pomocí zobrazení ( AQUV ). ${\ displaystyle A}$${\ displaystyle B}$${\ displaystyle A \ supset B}$${\ displaystyle B}$${\ displaystyle A}$

V systémech GAV návrhář systému zapíše kód zprostředkovatele, aby definoval přepis dotazu. Každý prvek v dotazu uživatele odpovídá substitučnímu pravidlu, stejně jako každý prvek v globálním schématu odpovídá dotazu na zdroj. Zpracování dotazů jednoduše rozšiřuje dílčí cíle dotazu uživatele podle pravidla uvedeného v prostředníkovi a výsledný dotaz bude tedy pravděpodobně ekvivalentní. Zatímco designér dělá většinu práce předem, některé systémy GAV, jako je Tsimmis, zahrnují zjednodušení procesu popisu mediátoru.

V systémech LAV procházejí dotazy radikálnějším procesem přepisování, protože neexistuje žádný prostředník, který by sladil dotaz uživatele s jednoduchou strategií rozšiřování. Integrační systém musí prohledat prostor možných dotazů, aby našel nejlepší přepis. Výsledný přepis nemusí být ekvivalentním dotazem, ale maximálně obsažený a výsledné n-tice mohou být neúplné. Od roku 2011 je algoritmus GQR předním algoritmem přepisování dotazů pro systémy integrace dat LAV.

Složitost přepisování dotazů je obecně NP-úplná . Pokud je prostor přepsání relativně malý, nepředstavuje to problém - dokonce ani pro integrační systémy se stovkami zdrojů.

Ve vědách o životě

Rozsáhlé vědecké otázky, jako je globální oteplování , invazivní šíření druhů a vyčerpání zdrojů , stále více vyžadují sběr různorodých datových souborů pro metaanalýzu . Tento typ datové integrace je obzvláště náročný pro ekologická a environmentální data, protože standardy metadat nejsou dohodnuty a v těchto oblastech existuje mnoho různých typů dat. Iniciativy National Science Foundation, jako je Datanet, mají usnadnit vědcům integraci dat poskytnutím kyberinfrastruktury a stanovením standardů. Těmito pěti financovanými iniciativami Datanet jsou DataONE , vedené Williamem Michenerem z University of New Mexico ; Data Conservancy, vedená Sayeedem Choudhurym z Johns Hopkins University ; SEAD: Udržitelné prostředí prostřednictvím akčních dat, vedená Margaret Hedstromovou z University of Michigan ; konsorcium federace DataNet vedené Reaganem Moorem z University of North Carolina ; a Terra Populus vedená Stevenem Rugglesem z University of Minnesota . Research dat Aliance , má více nedávno prozkoumal vytváření globálních rámců integrace dat. OpenPHACTS projekt, financovaný prostřednictvím Evropské unie iniciativy pro inovační lékařství , postavil hledání léků platformu tím, že spojí soubory dat od poskytovatelů, jako je European Bioinformatics Institute , Royal Society of Chemistry , UniProt , WikiPathways a DrugBank .

Viz také

Reference

externí odkazy