Dataintegration

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 20 februari 2016; kontroller kräver 7 redigeringar .

Dataintegration innebär att kombinera data från olika källor och tillhandahålla data till användarna på ett enhetligt sätt. Denna process blir väsentlig både i kommersiella uppgifter (när två liknande företag behöver kombinera sina databaser) och i vetenskapliga sådana (t.ex. genom att kombinera forskningsresultat från olika bioinformatiska förvar). Dataintegrationens roll ökar när volymen och behovet av datadelning ökar. Detta har blivit fokus för ett omfattande teoretiskt arbete, och många problem förblir olösta.[ förtydliga ] .

Nivåer av dataintegration

Dataintegrationssystem kan tillhandahålla dataintegration på fysisk, logisk och semantisk nivå. Ur en teoretisk synvinkel är integreringen av data på fysisk nivå den enklaste uppgiften och handlar om att konvertera data från olika källor till det nödvändiga enhetliga formatet för deras fysiska representation. Dataintegration på den logiska nivån ger möjligheten att komma åt data som finns i olika källor i termer av ett enda globalt schema som beskriver deras gemensamma representation, med hänsyn tagen till de strukturella och eventuellt beteendemässiga (vid användning av objektmodeller) egenskaper hos datan. . Datans semantiska egenskaper beaktas inte. Stöd för en enhetlig datarepresentation, med hänsyn till deras semantiska egenskaper inom ramen för en unified domänontologi , tillhandahålls av dataintegration på semantisk nivå. [ett]

Integrationsprocessen hämmas av datakällornas heterogenitet, beroende på integrationsnivån. Till exempel, vid integration i det fysiska lagret kan olika filformat användas i datakällor. På den logiska integrationsnivån kan det finnas heterogenitet i de datamodeller som används för olika källor, eller olika datascheman, även om samma datamodell används. Vissa källor kan vara webbplatser, andra kan vara objektdatabaser osv. När de integreras på semantisk nivå kan olika ontologier motsvara olika datakällor. Det är till exempel möjligt att var och en av källorna representerar informationsresurser som modellerar något fragment av ämnesområdet, som motsvarar dess eget begreppssystem, och dessa fragment skär varandra.

Nya problem

När man skapar ett integrationssystem uppstår ett antal uppgifter, vars sammansättning beror på kraven på det och det tillvägagångssätt som används. Dessa inkluderar särskilt:

Integrationssystemarkitekturer

Konsolidering

Vid konsolidering extraheras data från källor och placeras i Data Warehouse . Processen att fylla förrådet består av tre faser - extraktion, transformation, lastning (Extract, Transformation, Loading - ETL ). I många fall är det ETL som förstås med termen "dataintegration". En annan vanlig datakonsolideringsteknik är företagsinnehållshantering (enterprise content management, förkortning ECM ). De flesta ECM-lösningar fokuserar på konsolidering och hantering av ostrukturerad data som dokument, rapporter och webbsidor.

Konsolidering är en enkelriktad process, det vill säga data från flera källor slås samman i lagret, men sprids inte från det tillbaka till det distribuerade systemet. Ofta tjänar konsoliderade data som basen för business intelligence-applikationer (Business Intelligence, BI ), OLAP- applikationer.

Med denna metod är det vanligtvis en viss fördröjning mellan det att informationen uppdateras i de primära systemen och det att ändringarna visas på den slutliga lagringsplatsen. Datalagringsdestinationer som innehåller data med stora fördröjningstider (till exempel mer än en dag) skapas med hjälp av applikationer för batchdataintegrering som hämtar data från primära system med specifika, fördefinierade intervall. Lågfördröjda slutpunkter uppdateras med onlinedataintegreringsapplikationer som ständigt övervakar och driver dataändringar från primära system till slutpunkter.

Federalisering

I federerade databaser finns det ingen fysisk rörelse av data: data förblir hos ägarna, åtkomst till dem utförs vid behov (när en fråga exekveras). Inledningsvis antog federerade databaser skapandet av n-1 kodfragment i var och en av de n noderna, vilket gör att du kan komma åt vilken annan nod som helst. Samtidigt separerades federerade databaser från medlare [2] .

När man använder en mediator skapas en generell representation (modell) av datan. En medlare är en mellanhand som tillhandahåller ett enhetligt användargränssnitt baserat på den globala översikten av data som finns i källorna, samt stöd för kartläggning mellan den globala och lokala synen på data. En användarfråga formulerad i termer av ett enda gränssnitt bryts upp i en uppsättning delfrågor adresserade till de nödvändiga lokala datakällorna. Baserat på resultaten av deras bearbetning syntetiseras ett fullständigt svar på begäran. Två typer av förmedlad arkitektur används - Global som vy och Lokal som vy. [ett]

Kartläggningsdata från källan till den allmänna modellen utförs på varje begäran av ett speciellt omslag. Detta kräver tolkningen av begäran till enskilda källor och den efterföljande kartläggningen av mottagna data till en enda modell. Nu kallas denna metod också för en federerad databas. [3]

Företagsinformationsintegration (förkortning EII ) är ett exempel på en teknik som stöder en federerad strategi för dataintegration.

Den primära datautforskning och profilering som krävs för federalisering skiljer sig inte mycket från de som krävs för konsolidering.

Distribution av data

Datadistributionsapplikationer kopierar data från en plats till en annan. Dessa applikationer fungerar vanligtvis online och flyttar data till destinationer, det vill säga de beror på vissa händelser. Uppdateringar i det primära systemet kan överföras till målsystemet synkront eller asynkront. Synkron överföring kräver att uppdateringar till båda systemen sker under samma fysiska transaktion. Oavsett vilken typ av synkronisering som används, säkerställer distributionsmetoden att data levereras till destinationssystemet. Denna garanti är en nyckelfaktor för dataspridning. De flesta teknologier för synkron datadistribution stöder tvåvägskommunikation mellan primära och slutliga system. Exempel på teknologier som stödjer dataspridning är integrering av företagsapplikationer (Enterprise application integration, förkortning EAI ) och företagsdatareplikering (Enterprise datareplikering, förkortning EDR ). Denna metod skiljer sig från federerade databaser genom tvåvägsdatadistribution. [ett]

Servicemetoden

Den Service Oriented Architecture ( SOA ), som har använts framgångsrikt i applikationsintegration, är också tillämplig vid dataintegration. Uppgifterna finns också kvar hos ägarna och till och med var data finns är okänd. På begäran får man tillgång till vissa tjänster som är kopplade till källor, var informationen finns och dess specifika adress.

Dataintegration kombinerar information från flera källor på ett sådant sätt att den kan visas för kunden som en tjänst. En tjänst är inte en fråga i den traditionella betydelsen av att få åtkomst till data, det är snarare hämtning av någon affärsenhet (eller enheter) som kan utföras av en integrationstjänst genom en serie frågor och andra tjänster. SOA-metoden fokuserar främst på att definiera och dela ett relativt begränsat antal av de viktigaste affärsfunktionerna i ett företag som tjänster. Därför byggs tjänsteorienterade gränssnitt i ganska stor utsträckning på ett begränsat antal förfrågningar om att nödvändig information ska presenteras för konsumenten.

Med lämpliga säkerhetsuppgifter kan konsumenten hämta vilken data som helst från källan genom ett nästan obegränsat antal olika SQL-frågor. Men för detta måste konsumenten ha en förståelse för datakällsmodellen och hur man skapar ett resultat med hjälp av denna underliggande modell. Ju mer komplex datakälla modellen är, desto svårare kan denna uppgift vara. [fyra]

Även

Ett exempel på en hybridmetod beskrivs i [1] .

En annan klassificering av metoder ges i [5] .

Problem med informationsintegration

Oavsett vald teknologi och metod för dataintegration, kvarstår frågor relaterade till deras semantiska tolkning och skillnader i presentationen av samma saker. Det är nämligen nödvändigt att lösa inkonsekvensen av datascheman [6] och inkonsekvensen i själva datan.

Dataschemafelmatchningstyper

Strukturella och semantiska konflikter resulterar i följande problem:

  1. Skillnad i datatyper. Vissa domäner i en källa kan representeras av ett tal, i en annan - av en sträng med fast längd, i den tredje - av en sträng med variabel längd.
  2. Skillnaden ligger i måttenheterna. I en databas anges värdet i centimeter, i den andra - i tum. I det här fallet finns det en 1:1-mappning.
  3. Skillnaden ligger i uppsättningen av tillåtna värden. Samma attribut kan definieras av olika uppsättningar konstanter. Till exempel kan utförandet av en uppgift av en källa bedömas på en fyrgradig skala (otillfredsställande, tillfredsställande, bra, utmärkt), av en annan - med en tregradig skala (-, ±, +) och med en tredje - med en hundragradig skala. Displayen är inte 1:1, den kan vara flervärdig, kanske inte ha motsatsen, kan bero på tredjepartsdata (till exempel motsvarar 30 i matematik "tillfredsställande" och på ryska - "otillfredsställande").
  4. Distinktionen "domän-relation". En domän i en databas (t.ex. ett strängvärde) motsvarar en tabell i en annan databas (poster från en uppslagstabell).
  5. Skillnad "domän - grupp av domäner". I en källa är adressen skriven på en rad, i den andra - separata fält för gatan, huset, byggnaden, lägenheten.
  6. Skillnaden mellan data och schema. Data från en databas motsvarar schemat (metadata) för en annan. I den ena databasen är "ingenjör" värdet av "position"-attributet för "anställd"-relationen, i den andra är "ingenjörer" en relation som innehåller vissa anställda, medan "revisorer" innehåller andra.
  7. Saknade värden. En av källorna kan sakna information som finns i de flesta andra.

Lösning av dessa inkonsekvenser görs ofta manuellt. En översikt över automatiska upplösningsmetoder för schemafelmatchning finns i [7] .

Typer av datainkonsekvens

  1. Dataformatskillnad. "st. Bakhrushina, 18-1" eller "Bakhrushina, 18, byggnad 1"; "8(910)234-45-32" eller "8-910-234-45-32"
  2. Skillnaden ligger i representationen av värden. Till exempel kan en viss organisation registreras i separata källor som Novolipetsk Iron and Steel Works, NLMK, OAO NLMK.
  3. Förlust av datarelevans av en av källorna. Till exempel byte av efternamn vid äktenskap: ett nytt efternamn registreras i en databas, ett gammalt efternamn lagras i en annan och de stämmer inte överens.
  4. Förekomst av operatörsinmatningsfel (eller formulärigenkänningsfel) i enskilda datakällor. Detta inkluderar mekaniska stavfel, fel i att lyssna på svåruttalade namn/titlar, avsaknaden av enhetliga standarder för transkription från främmande språk.
  5. Avsiktligt införa snedvridningar för att göra det svårt att identifiera enheter.

Dessa skillnader leder till dubblering av poster när data integreras i en databas. Att lösa dessa problem och eliminera dubbletter manuellt är nästan omöjligt. Det finns många metoder för dess automatiska och halvautomatiska lösning. På ryska har uppgiften inte en väletablerad term (de använder "rekordmatchning", "probabilistisk sammanfogning", "icke-strikt sammanfogning", "icke-strikt matchning"). I utländska verk kallas denna uppgift Identity resolution , eller Record linkage (det finns andra synonymer). En översikt över metoderna finns i [8] .

Källor

  1. 1 2 3 4 Kogalovsky M.R. Metoder för dataintegration i informationssystem (otillgänglig länk) . Arkiverad från originalet den 22 juli 2012.  
  2. Garcia-Molina G., Ulman J. , Widom J. Databassystems. Hela kursen = Databassystem: The Complete Book. - Williams , 2003. - 1088 sid. ISBN 5-8459-0384-X .
  3. Dataintegration och lagring . Hämtad 25 augusti 2011. Arkiverad från originalet 30 mars 2014.
  4. Gunther Saufer, May Selvage, Eoin Lane, Bill Matthews. Informationstjänstmallar (3 augusti 2007). Arkiverad från originalet den 22 juli 2012.
  5. Leonid Chernyak. Dataintegration: Syntax och semantik . Öppna system, nr 10, 2009. Hämtad 25 augusti 2011. Arkiverad från originalet 8 oktober 2012.
  6. William Kent. Lösa problem med domänfel och schemafel med ett objektorienterat databasprogrammeringsspråk . Proceedings of the International Conference on Very Large Databases (1991). Arkiverad från originalet den 22 juli 2012.
  7. Erhard Rahm, Philip A. Bernstein. En undersökning av tillvägagångssätt för automatisk schemamatchning . VLDB JOURNAL (2001). Arkiverad från originalet den 22 juli 2012.
  8. Ahmed K. Elmagarmid, Panagiotis G. Ipeirotis, Vassilios S. Verykios. Identifiering av dubbletter av poster: En undersökning . IEEE TRANSAKTIONER OM KUNSKAP OCH DATATEKNIK, VOL. 19, nr. 1 JANUARI 2007. Arkiverad från originalet den 22 juli 2012.

Se även