Federerat databassystem

Ett federerat databassystem ( FDBS ) är en typ av metadatabashanteringssystem (DBMS), som transparent mappar flera autonoma databassystem till en enda federerad databas . De ingående databaserna är sammankopplade via ett datornätverk och kan vara geografiskt decentraliserade. Eftersom de ingående databassystemen förblir autonoma är ett federerat databassystem ett kontrastrikt alternativ till den (ibland skrämmande) uppgiften att slå samman flera olika databaser. En förenad databas, eller virtuell databas , är en sammansättning av alla ingående databaser i ett förenat databassystem. Det finns ingen faktisk dataintegration i de ingående olika databaserna som ett resultat av datafederation.

Genom dataabstraktion kan federerade databassystem tillhandahålla ett enhetligt användargränssnitt , vilket gör det möjligt för användare och klienter att lagra och hämta data från flera icke-sammanhängande databaser med en enda fråga - även om de ingående databaserna är heterogena . För detta ändamål måste ett förenat databassystem kunna dekomponera frågan i delfrågor för inlämning till de relevanta ingående DBMS: erna , varefter systemet måste sammansätta resultatuppsättningarna av underfrågorna. Eftersom olika databashanteringssystem använder olika frågespråk , kan federerade databassystem tillämpa omslag på underfrågorna för att översätta dem till lämpliga frågespråk .

Definition

McLeod och Heimbigner var bland de första som definierade ett federerat databassystem i mitten av 1980-talet.

En FDBS är en som "definierar arkitekturen och sammankopplar databaser som minimerar central auktoritet men som ändå stödjer partiell delning och samordning mellan databassystem". Denna beskrivning kanske inte exakt återspeglar McLeod/Heimbigners definition av en federerad databas. Snarare passar denna beskrivning vad McLeod/Heimbigner kallade en sammansatt databas. McLeod/Heimbigners federerade databas är en samling autonoma komponenter som gör deras data tillgänglig för andra medlemmar av federationen genom publicering av ett exportschema och åtkomstoperationer; det finns inget enhetligt, centralt schema som omfattar den information som finns tillgänglig från förbundets medlemmar.

Bland andra undersökningar definierar utövare en federerad databas som en samling samverkande komponentsystem som är autonoma och möjligen heterogena .

De tre viktiga komponenterna i en FDBS är autonomi, heterogenitet och distribution. En annan dimension som också har beaktats är nätverksmiljön datornätverk , t.ex. många DBS:er över ett LAN eller många DBS:er över en WAN -uppdateringsrelaterade funktioner för deltagande DBS:er (t.ex. inga uppdateringar, icke-atomära övergångar, atomära uppdateringar ).

FDBS arkitektur

Ett DBMS kan klassificeras som antingen centraliserat eller distribuerat. Ett centraliserat system hanterar en enda databas medan distribuerat hanterar flera databaser. En komponent -DBS i ett DBMS kan centraliseras eller distribueras. En multipel DBS (MDBS) kan klassificeras i två typer beroende på autonomin hos komponenten DBS som federerad och icke federerad. Ett icke-federerat databassystem är en integration av komponent- DBMS som inte är autonoma. Ett federerat databassystem består av komponent -DBS som är autonoma men ändå deltar i en federation för att tillåta partiell och kontrollerad delning av deras data.

Federerade arkitekturer skiljer sig beroende på nivåer av integration med komponentdatabassystemen och omfattningen av tjänster som erbjuds av federationen. En FDBS kan kategoriseras som löst eller tätt kopplade system.

  • Loosely Coupled kräver komponentdatabaser för att konstruera sitt eget förenade schema . En användare kommer vanligtvis åt andra komponentdatabassystem genom att använda ett multidatabasspråk, men detta tar bort alla nivåer av platstransparens, vilket tvingar användaren att ha direkt kunskap om det förenade schemat. En användare importerar de data de behöver från andra komponentdatabaser och integrerar dem med sina egna för att bilda ett federerat schema.
  • Tätt kopplade system består av komponentsystem som använder oberoende processer för att konstruera och publicera ett integrerat federerat schema.

Flera DBS av vilka FDBS är en specifik typ kan karakteriseras längs tre dimensioner: Distribution, Heterogenitet och Autonomi. En annan karaktärisering kan baseras på dimensionen av nätverk, till exempel enstaka databaser eller flera databaser i ett LAN eller WAN.

Distribution

Distribution av data i en FDBS beror på att det finns en multipel DBS innan en FDBS byggs. Data kan distribueras mellan flera databaser som kan lagras i en enda dator eller flera datorer. Dessa datorer kan vara geografiskt placerade på olika platser men sammankopplade av ett nätverk. Fördelarna med datadistribution bidrar till ökad tillgänglighet och tillförlitlighet samt förbättrade åtkomsttider.

Heterogenitet

Huvudartikel: Heterogent databassystem

Heterogeniteter i databaser uppstår på grund av faktorer som skillnader i strukturer, semantik för data, de begränsningar som stöds eller frågespråk . Skillnader i struktur uppstår när två datamodeller ger olika primitiver såsom objektorienterade (OO) modeller som stödjer specialisering och arv och relationsmodeller som inte gör det. Skillnader på grund av begränsningar uppstår när två modeller stöder två olika begränsningar. Till exempel kan uppsättningstypen i CODASYL- schema delvis modelleras som en referensintegritetsbegränsning i ett relationsschema. CODASYL stöder insättning och kvarhållning som inte fångas enbart av referensintegritet. Frågespråket som stöds av en DBMS kan också bidra till heterogenitet mellan andra DBMS- komponenter . Till exempel kan skillnader i frågespråk med samma datamodeller eller olika versioner av frågespråk bidra till heterogenitet .

Semantiska heterogeniteter uppstår när det råder oenighet om betydelse, tolkning eller avsedd användning av data . På schema- och datanivå inkluderar klassificering av möjliga heterogeniteter:

När man skapar ett federerat schema måste man lösa sådana heterogeniteter innan man integrerar DB-komponentscheman.

Schemamatchning, schemamappning

Att hantera inkompatibla datatyper eller frågesyntax är inte det enda hindret för en konkret implementering av en FDBS. I system som inte är planerade uppifrån och ned ligger ett generiskt problem i att matcha semantiskt ekvivalenta , men olika namngivna delar från olika scheman (=datamodeller) (tabeller, attribut). En parvis mappning mellan n attribut skulle resultera i mappningsregler (givna ekvivalensmappningar) - ett tal som snabbt blir för stort för praktiska ändamål. En vanlig utväg är att tillhandahålla ett globalt schema som omfattar de relevanta delarna av alla medlemsscheman och tillhandahålla mappningar i form av databasvyer . Två huvudsakliga tillvägagångssätt beror på kartläggningens riktning:

  1. Global som vy (GaV): det globala schemat definieras i termer av de underliggande schemana
  2. Local as View (LaV): de lokala schemana definieras i termer av det globala schemat

Båda är exempel på dataintegration , kallat schemamatchningsproblem .

Autonomi

Grundläggande för skillnaden mellan en MDBS och en FDBS är begreppet autonomi. Det är viktigt att förstå aspekterna av autonomi för komponentdatabaser och hur de kan hanteras när en komponent-DBS deltar i en FDBS. Det finns fyra typer av autonomier som behandlas:

  • Design Autonomi som hänvisar till förmågan att välja dess design oavsett data, frågespråk eller konceptualisering, funktionalitet hos systemimplementeringen.

Heterogeniteter i en FDBS beror främst på designautonomi.

  • Kommunikationsautonomi hänvisar till DBMS:s allmänna funktion för att kommunicera med andra DBMS eller inte.
  • Exekveringsautonomi tillåter en komponent DBMS att kontrollera de operationer som begärs av lokala och externa operationer.
  • Associationsautonomi ger en befogenhet till komponent DBS att ta avstånd från en federation vilket innebär att FDBS kan fungera oberoende av en enskild DBS .

ANSI/X3/SPARC Study Group beskrev en databeskrivningsarkitektur på tre nivåer, vars komponenter är det konceptuella schemat, det interna schemat och det externa schemat för databaser. Arkitekturen på tre nivåer är dock otillräcklig för att beskriva arkitekturerna för en FDBS. Den utökades därför för att stödja de tre dimensionerna av FDBS, nämligen distribution, autonomi och heterogenitet. Schemaarkitekturen på fem nivåer förklaras nedan.

Samtidighetskontroll

på heterogenitet och autonomi ställer speciella utmaningar när det gäller samtidighetskontroll i en FDBS, vilket är avgörande för korrekt utförande av dess samtidiga transaktioner (se även Global samtidighetskontroll ) . Att uppnå global serialiserbarhet , det största korrekthetskriteriet, under dessa krav har karakteriserats som mycket svårt och olöst. Commitment ordering , som introducerades 1991, har gett en generell lösning för detta problem (Se Global serialiserbarhet ; Se Commitment ordering även för de arkitektoniska aspekterna av lösningen).

Schemaarkitektur på fem nivåer för FDBS

Schemaarkitekturen på fem nivåer inkluderar följande:

  • Local Schema är i grunden den konceptuella modellen för en komponentdatabas uttryckt i en inbyggd datamodell.
  • Komponentschema är delmängden av det lokala schemat som ägarorganisationen är villig att dela med andra användare av FDBS och det översätts till en gemensam datamodell .
  • Exportschema representerar en delmängd av ett komponentschema som är tillgängligt för en viss federation. Den kan innehålla åtkomstkontrollinformation om dess användning av en specifik federationsanvändare. Exportschemat hjälper till att hantera flödet av kontroll av data.
  • Federated Schema är en integration av flera exportscheman. Den innehåller information om datadistribution som genereras när exportscheman integreras.
  • Externt schema extraheras från ett federerat schema och definieras för användarna/applikationerna i en viss federation.

Även om den på ett korrekt sätt representerar det senaste inom dataintegration, lider femnivåschemaarkitekturen ovan av en stor nackdel, nämligen IT-påtvingat utseende och känsla. Moderna dataanvändare kräver kontroll över hur data presenteras; deras behov är något i konflikt med sådana nedifrån och upp-strategier för dataintegration.

Se även

  1. ^ a b c " Mcleod och Heimbigner (1985). "En federerad arkitektur för informationsledning" . ACM-transaktioner på informationssystem, volym 3, nummer 3. s. 253–278.
  2. ^ a b c " Sheth och Larson (1990). "Federerade databassystem för att hantera distribuerade, heterogena och autonoma databaser" ACM Computing Surveys, Vol. 22, No.3 . s. 183–236.
  3. ^ a b c d e Masood, Nayyer; Eaglestone, Barry (december 2003). "Komponent- och federationskonceptmodeller i ett federerat databassystem" ( PDF) . Malaysian Journal of Computer Science . 16 (2): 47–57. Arkiverad från originalet (PDF) 2016-03-07 . Hämtad 2016-03-03 .

externa länkar

Hämtad från " https://sv.wikipedia.org/w/index.php?title=Federated_database_system&oldid=1082312380 "