Objekt -relasjonell impedans mismatch - Object–relational impedance mismatch

Den objektrelasjons impedans mismatch er et sett med konseptuelle og tekniske problemer som ofte oppstår når en relasjonsdatabase management system (RDBMS) blir servert av et program (eller flere programmer) skrevet i et objektorientert programmeringsspråk eller stil , spesielt fordi objekter eller klassedefinisjoner må kartlegges til databasetabeller definert av et relasjonelt skjema.

Begrepet objekt -relasjons -impedans -mismatch er avledet fra det elektrotekniske uttrykket impedans -matching .

Uoverensstemmelser

Objekter (forekomster) refererer til hverandre og danner derfor en graf i matematisk forstand (et nettverk som inkluderer sløyfer og sykluser). Relasjonelle skjemaer er derimot tabellformede og basert på relasjonsalgebra , som definerer koblede heterogene tupler (gruppering av datafelt i en "rad" med forskjellige typer for hvert felt).

Objektorienterte konsepter

Innkapsling

Objektorienterte programmer er designet med teknikker som resulterer i innkapslede objekter hvis interne representasjon kan skjules. I et objektorientert rammeverk forventes de underliggende egenskapene til et gitt objekt ikke å bli utsatt for noe grensesnitt utenfor det som er implementert ved siden av objektet. De fleste objekt -relasjonelle kartleggingsmetodene avslører imidlertid det underliggende innholdet i et objekt for å samhandle med et grensesnitt som objektimplementeringen ikke kan spesifisere. Derfor bryter denne objekt -relasjonelle kartleggingen innkapslingen av objektet, siden mange objekt -relasjonelle kartleggere automatisk genererer offentlige felt som tilsvarer databasekolonner. Noen få rammer bruker i stedet metaprogrammeringsteknikker, og unngår dermed brudd på innkapsling.

tilgjengelighet

I relasjonell tenkning er "privat" kontra "offentlig" tilgang relativ til behovet. I den objektorienterte (OO) modellen er det et absolutt kjennetegn på datatilstanden. De relasjonelle og OO -modellene har ofte konflikter om relativitet versus absolutisme av klassifiseringer og egenskaper.

Grensesnitt, klasse, arv og polymorfisme

Under et objektorientert paradigme har objekter grensesnitt som sammen gir den eneste tilgangen til det indre av objektet. Relasjonsmodellen benytter derimot avledede relasjonsvariabler ( visninger ) for å gi varierende perspektiver og begrensninger for å sikre integritet. På samme måte støttes ikke viktige OOP -konsepter for klasser av objekter, arv og polymorfisme , av relasjonsdatabasesystemer.

Kartlegging til relasjonelle begreper

En riktig kartlegging mellom relasjonelle konsepter og objektorienterte konsepter kan gjøres hvis relasjonelle databasetabeller er knyttet til assosiasjoner som finnes i objektorientert analyse .

Datatypeforskjeller

En stor uoverensstemmelse mellom eksisterende relasjons og OO-språk er de -type system forskjeller. Den relasjonsmodellen forbyr strengt henvisningsattributter (eller pekepunkter ), mens OO-språk omfavner og forventer bienferanseatferd. Skalar typer og deres operatør semantikk kan være vesentlig forskjellig mellom modellene, forårsaker problemer i kartlegging.

For eksempel støtter de fleste SQL- systemer strengtyper med varierende samlinger og begrensede maksimale lengder (åpne teksttyper har en tendens til å hindre ytelse), mens de fleste OO-språk bare anser sortering som et argument for å sortere rutiner og strenger er iboende størrelse til tilgjengelig minne. Et mer subtilt, men beslektet eksempel er at SQL -systemer ofte ignorerer etterfølgende hvitt mellomrom i en streng for sammenligningsformål, mens OO -strengbiblioteker ikke gjør det. Det er vanligvis ikke mulig å konstruere nye datatyper for å begrense mulige verdier for andre primitive typer i et OO -språk.

Strukturelle og integritetsforskjeller

En annen mismatch har å gjøre med forskjellene i strukturelle og integritetsaspektene til de kontrasterte modellene. På OO -språk kan objekter være sammensatt av andre objekter - ofte i høy grad - eller spesialisere seg fra en mer generell definisjon. Dette kan gjøre kartlegging til relasjonsskjemaer mindre grei. Dette er fordi relasjonsdata har en tendens til å være representert i et navngitt sett med globale, ubemerkede relasjonsvariabler. Selve relasjoner, som er sett med tupler som alle samsvarer med samme overskrift (se tuple relationell beregning ), har ikke en ideell motpart på OO -språk. Begrensninger på OO -språk deklareres vanligvis ikke som sådan, men manifesteres som unntak som øker beskyttelseslogikken rundt kode som opererer på innkapslede interne data. Relasjonsmodellen krever derimot deklarative begrensninger for skalartyper, attributter, relasjonsvariabler og databasen som helhet.

Manipulative forskjeller

De semantiske forskjellene er imidlertid spesielt tydelige i de manipulative aspektene ved de kontrastmodellene. Den relasjonsmodellen har et iboende, relativt lite og veldefinert sett med primitive operatører for bruk i spørring og manipulering av data, mens OO-språk generelt håndterer forespørsel og manipulasjon gjennom spesialbygde eller lavere nivå, case- og fysisk tilgang -banespesifikke imperative operasjoner. Noen OO språk har støtte for deklarative spørre sublanguages , men fordi OO språk vanligvis håndtere lister og kanskje hash tabeller , manipulerende primitiver er nødvendigvis forskjellig fra settet baserte driften av relasjonsmodellen.

Transaksjonelle forskjeller

Samtids- og transaksjonsaspektene er også vesentlig forskjellige. Spesielt er transaksjoner , den minste arbeidsenheten utført av databaser, mye større i relasjonsdatabaser enn noen operasjoner utført av klasser på OO -språk. Transaksjoner i relasjonsdatabaser er dynamisk begrensede sett med vilkårlige datamanipulasjoner, mens detaljene i transaksjoner i et OO-språk vanligvis er på nivået til individuelle tildelinger til primitive typer. Generelt har OO -språk ingen analog av isolasjon eller holdbarhet, så atomisitet og konsistens er bare sikret når du skriver til felt av de primitive typene.

Løse impedans mismatch

Arbeidet rundt impedans-mismatch-problemet for objektorienterte programmer starter med anerkjennelse av forskjellene i de spesifikke logiske systemene som brukes. Uoverensstemmelsen blir deretter enten minimert eller kompensert for.

Alternative arkitekturer

Objekt -relasjons -impedans -mismatch -problemet er ikke et universelt problem mellom OO og databaser. Som navnet antyder, oppstår dette impedansproblemet bare med relasjonsdatabaser . Den vanligste løsningen på dette problemet er å bruke en alternativ database, for eksempel NoSQL- eller XML -database .

Minimering

Det har vært noen forsøk på å bygge objektorienterte databasesystemer (OODBMS) som ville unngå impedans-feilpasningsproblemet. De har imidlertid vært mindre vellykkede i praksis enn relasjonsdatabaser, delvis på grunn av begrensningene i OO -prinsipper som grunnlag for en datamodell. Det har blitt forsket på å utvide de databaselignende egenskapene til OO-språk gjennom slike forestillinger som transaksjonsminne .

En vanlig løsning på impedans -mismatch -problemet er å lagre domenet og rammelogikken. I denne ordningen brukes OO -språket til å modellere visse relasjonsaspekter ved kjøretid i stedet for å prøve den mer statiske kartleggingen. Rammer som bruker denne metoden vil typisk ha en analog for en tupel, vanligvis som en "rad" i en "datasett" -komponent eller som en generisk "enhetsforekomst" -klasse, samt en analog for en relasjon. Fordelene med denne tilnærmingen kan omfatte:

  • Enkle veier for å bygge rammer og automatisering rundt transport, presentasjon og validering av domenedata.
  • Mindre kodestørrelse; raskere kompilering og lastetid.
  • Evne for skjemaet til å endre seg dynamisk.
  • Unngår problemene mellom navn og mellomrom.
  • Uttrykkskontroll av begrensninger
  • Ingen kompleks kartlegging nødvendig

Ulemper kan omfatte:

  • Mangel på statiske "sikkerhetskontroller" av typen. Typede accessors brukes noen ganger som en måte å dempe dette på.
  • Mulige ytelseskostnader for kjøretidskonstruksjon og tilgang.
  • Manglende evne til å bruke unike OO -aspekter, for eksempel polymorfisme .

Kompensasjon

Blandingen av diskursnivåer i OO -applikasjonskoden gir problemer, men det er noen vanlige mekanismer som brukes for å kompensere. Den største utfordringen er å tilby rammestøtte, automatisering av datamanipulering og presentasjonsmønstre, innenfor diskursnivået der domenedataene blir modellert. For å løse dette brukes refleksjon og/eller kodegenerering . Refleksjon gjør at kode (klasser) kan adresseres som data og dermed gi automatisering av transport, presentasjon, integritet, etc. av dataene. Generasjon løser problemet ved å adressere enhetsstrukturene som datainnganger for kodegenereringsverktøy eller metaprogrammeringsspråk, som produserer klassene og støtter infrastruktur i massevis. Begge disse ordningene kan fortsatt være gjenstand for visse avvik der disse diskursnivåene smelter sammen. For eksempel vil genererte enhetsklasser vanligvis ha egenskaper som tilordnes domenet (f.eks. Navn, adresse), så vel som eiendommer som gir statlig ledelse og annen rammeinfrastruktur (f.eks. IsModified).

Påstand

Det har blitt hevdet av Christopher J. Date og andre at et virkelig relasjonelt DBMS ikke ville utgjøre et slikt problem, ettersom domener og klasser i hovedsak er det samme. En opprinnelig kartlegging mellom klasser og relasjonsskjemaer er en grunnleggende designfeil; og at individuelle tupler i en databasetabell (relasjon) burde ses på som å etablere relasjoner mellom enheter; ikke som representasjoner for komplekse enheter selv. Imidlertid har dette synet en tendens til å redusere innflytelsen og rollen til objektorientert programmering, ved å bruke det som lite mer enn et feltstyringssystem.

Impedans -mismatch er i programmering mellom domenenobjektene og brukergrensesnittet . Sofistikerte brukergrensesnitt, for å tillate operatører, ledere og andre ikke-programmerere å få tilgang til og manipulere postene i databasen, krever ofte intim kunnskap om arten av de forskjellige databaseattributtene (utover navn og type). Spesielt anses det som en god praksis (fra sluttbrukerproduktivitet) å designe brukergrensesnitt slik at brukergrensesnittet forhindrer ulovlige transaksjoner (de som forårsaker brudd på en databasebegrensning ). for å gjøre det krever mye av logikken i relasjonsskjemaene å dupliseres i koden.

Enkelte kodeutviklingsrammer kan utnytte visse former for logikk som er representert i databasens skjema (for eksempel referanseintegritetsbegrensninger), slik at slike problemer håndteres på en generisk og standard måte gjennom biblioteksrutiner i stedet for ad hoc-kode skrevet på en sak -etter sak.

Det har blitt hevdet at SQL på grunn av et svært begrenset sett med domenetyper (og andre påståtte feil) gjør riktig objekt- og domenemodellering vanskelig; og at SQL utgjør et veldig tapt og ineffektivt grensesnitt mellom et DBMS og et applikasjonsprogram (enten det er skrevet i en objektorientert stil eller ikke). Imidlertid er SQL for øyeblikket det eneste allment aksepterte vanlige databasespråket på markedet; bruk av leverandørspesifikke spørrespråk blir sett på som en dårlig praksis når det kan unngås. Andre databasespråk som Business System 12 og opplæring D er blitt foreslått; men ingen av disse har blitt bredt vedtatt av DBMS -leverandører.

I nåværende versjoner av vanlige "objektrelasjonelle" DBMS-er som Oracle og Microsoft SQL Server, kan punktet ovenfor være et problem. Med disse motorene kan funksjonaliteten til en gitt database vilkårlig utvides gjennom lagret kode (funksjoner og prosedyrer) skrevet på et moderne OO -språk (Java for Oracle og et Microsoft .NET -språk for SQL Server), og disse funksjonene kan påberopes i sin tur i SQL-setninger på en transparent måte: det vil si at brukeren verken vet eller bryr seg om at disse funksjonene/prosedyrene ikke opprinnelig var en del av databasemotoren. Moderne programvareutviklingsparadigmer støttes fullt ut: Dermed kan man lage et sett med biblioteksrutiner som kan gjenbrukes på tvers av flere databaseskjemaer.

Disse leverandørene bestemte seg for å støtte OO-språkintegrasjon på DBMS-backend fordi de innså at til tross for forsøkene fra ISO SQL-99-komiteen for å legge til prosessuelle konstruksjoner i SQL, vil SQL aldri ha det rike settet med biblioteker og datastrukturer som dagens applikasjonsprogrammerere tar for gitt, og det er rimelig å utnytte disse så direkte som mulig i stedet for å prøve å utvide kjerne -SQL -språket. Følgelig er forskjellen mellom "applikasjonsprogrammering" og "databaseadministrasjon" nå uklar: Robust implementering av funksjoner som begrensninger og utløsere kan ofte kreve en person med doble DBA/OO-programmeringskunnskaper, eller et partnerskap mellom personer som kombinerer disse ferdighetene . Dette faktum gjelder også spørsmålet om "ansvarsfordeling" nedenfor.

Noen vil imidlertid påpeke at denne påstanden er avgjørende på grunn av det faktum at: (1) RDBMSes aldri var ment å lette objektmodellering, og (2) SQL skulle generelt bare sees på som et "tap" eller "ineffektivt" grensesnitt språk når man prøver å oppnå en løsning som RDBMSes ikke var designet for. SQL er veldig effektivt til å gjøre det den var designet for å gjøre, nemlig å spørre, sortere, filtrere og lagre store datasett. Noen vil i tillegg påpeke at inkluderingen av OO-språkfunksjonalitet i back-end ganske enkelt letter dårlig arkitektonisk praksis, ettersom den innrømmer applikasjonslogikk på høyt nivå i datalaget, antitetisk til RDBMS.

Her ligger den "kanoniske" kopien av staten. Databasemodellen antar generelt at databasesystemet er det eneste autoritative statslageret om virksomheten; alle kopier av en slik tilstand som et applikasjonsprogram har, er nettopp det - midlertidige kopier (som kan være utdaterte hvis den underliggende databasen ble senere endret av en transaksjon). Mange objektorienterte programmerere foretrekker å se representasjonene i objektene i seg selv som kanoniske data, og se databasen som en lagringslager og utholdenhetsmekanisme.

Et annet stridspunkt er riktig ansvarsfordeling mellom applikasjonsprogrammerere og databaseadministratorer (DBA). Det er ofte slik at nødvendige endringer i applikasjonskoden (for å implementere en ønsket ny funksjon eller funksjonalitet) krever tilsvarende endringer i databasedefinisjonen; i de fleste organisasjoner er databasedefinisjonen DBAs ansvar. På grunn av behovet for å opprettholde et produksjonsdatabasesystem 24 timer i døgnet, er mange DBA motvillige til å gjøre endringer i databaseskjemaer som de anser som umulige eller overflødige, og i noen tilfeller nekter å gjøre det. Bruk av utviklingsdatabaser (bortsett fra produksjonssystemer) kan hjelpe noe; men når den nyutviklede applikasjonen "går live", må DBA godkjenne eventuelle endringer. Noen programmerere ser på dette som uforsonlig; DBA holdes imidlertid ofte ansvarlig hvis endringer i databasedefinisjonen medfører tap av service i et produksjonssystem - som et resultat foretrekker mange DBAer å inneholde designendringer i applikasjonskoden, der designfeil er langt mindre sannsynlig å få katastrofale konsekvenser .

I organisasjoner med et ikke-dysfunksjonelt forhold mellom DBAer og utviklere bør imidlertid problemet ovenfor ikke vise seg, ettersom beslutningen om å endre et databaseskjema eller ikke bare ville være drevet av forretningsbehov: et nytt krav for å beholde tilleggsdata eller en ytelsesøkning for en kritisk applikasjon vil for eksempel både utløse en skjemamodifisering.

Filosofiske forskjeller

Viktige filosofiske forskjeller mellom OO og relasjonsmodeller kan oppsummeres som følger:

  • Deklarative kontra imperative grensesnitt  - Relasjonell tenkning har en tendens til å bruke data som grensesnitt, ikke oppførsel som grensesnitt. Den har dermed en deklarativ tilt i designfilosofien i motsetning til OOs atferdsmessige tilt. (Noen relasjonelle talsmenn foreslår at du bruker triggere, lagrede prosedyrer, etc. for å gi kompleks oppførsel, men dette er ikke et vanlig synspunkt.)
  • Skjemabundet  - Objekter trenger ikke å følge et "overordnet skjema" som attributter eller accessors et objekt har, mens tabellrader må følge enhetens skjema. En gitt rad må tilhøre en og bare en enhet. Det nærmeste i OO er arv, men det er generelt treformet og valgfritt. Dynamiske databasesystemer som tillater ad hoc-kolonner, kan slappe av skjemabundet, men slike systemer er enten for øyeblikket sjeldne, eller det er spørsmål om klassifisering som "relasjonelle".
  • Tilgangsregler  - I relasjonsdatabaser får du tilgang til og endrer attributter gjennom forhåndsdefinerte relasjonsoperatorer, mens OO lar hver klasse lage sitt eget grensesnitt og praksis for tilstandsendring. Synspunktet "selvhåndterende substantiv" til OO gir hvert objekt uavhengighet som relasjonsmodellen ikke tillater. Dette er en "standard versus lokal frihet" -debatt. OO har en tendens til å argumentere for at relasjonsstandarder begrenser uttrykksfullhet, mens relasjonelle forkjempere foreslår at regeloverholdelse tillater mer abstrakt matematisk-lignende resonnement, integritet og designkonsistens.
  • Forholdet mellom substantiv og verb  - OO oppmuntrer til en tett sammenheng mellom verb (handlinger) og substantivene (enhetene) operasjonene opererer på. Det resulterende fast bundet enhet som inneholder både substantiver og verb kalles vanligvis en klasse , eller i OO analyse, et konsept . Relasjonsdesign antar generelt ikke at det er noe naturlig eller logisk om slike stramme assosiasjoner (utenfor relasjonsoperatører).
  • Objektidentitet  - Objekter (andre enn uforanderlige) anses generelt å ha en unik identitet; to objekter som tilfeldigvis har samme tilstand på et gitt tidspunkt, anses ikke å være identiske. Relasjoner, derimot, har ingen iboende oppfatning av denne typen identitet. Når det er sagt, er det en vanlig praksis å fremstille "identitet" for poster i en database ved bruk av globalt unike kandidatnøkler ; selv om mange anser dette som en dårlig praksis for enhver databasepost som ikke har en-til-en-korrespondanse med en ekte verden. (Forhold, som objekter, kan bruke domenenøkler hvis de eksisterer i den ytre verden for identifikasjonsformål). Relasjonssystemer strever i praksis etter og støtter "permanente" og inspiserbare identifikasjonsteknikker, mens objektidentifikasjonsteknikker pleier å være forbigående eller situasjonelle.
  • Normalisering  - Relasjonell normaliseringspraksis ignoreres ofte av OO -design. Imidlertid kan dette bare være en dårlig vane i stedet for en opprinnelig funksjon i OO. En alternativ visning er at en samling objekter, sammenkoblet via noen slags pekere , tilsvarer en nettverksdatabase ; som igjen kan sees på som en ekstremt denormalisert relasjonsdatabase .
  • Skjemaarv  - De fleste relasjonsdatabaser støtter ikke skjemaarv. Selv om en slik funksjon kan legges i teorien for å redusere konflikten med OOP, relasjonelle talsmenn er mindre sannsynlig å tro på nytten av hierarkiske taksonomier og sub-typing fordi de har en tendens til å vise set-baserte taksonomier eller klassifiseringssystemer som mer kraftig og fleksibel enn trær. OO-forkjempere påpeker at modeller for arv/undertyping ikke trenger å være begrenset til trær (selv om dette er en begrensning på mange populære OO-språk som Java ), men OO-løsninger som ikke er av tre, blir sett på som vanskeligere å formulere enn settbaserte variasjoner- on-a-theme management teknikker foretrukket av relasjonelle. I det minste skiller de seg fra teknikker som vanligvis brukes i relasjonsalgebra.
  • Struktur vs. oppførsel  -OO fokuserer først og fremst på å sikre at strukturen til programmet er rimelig (vedlikeholdbar, forståelig, utvidbar, gjenbrukbar, trygg), mens relasjonssystemer fokuserer på hva slags oppførsel det resulterende kjøretidssystemet har (effektivitet, tilpasningsevne , feiltoleranse, livskraft, logisk integritet, etc.). Objektorienterte metoder antar generelt at den primære brukeren av den objektorienterte koden og dens grensesnitt er applikasjonsutviklerne. I relasjonssystemer blir sluttbrukernes syn på systemets oppførsel noen ganger ansett for å være viktigere. Imidlertid er relasjonelle spørsmål og "visninger" vanlige teknikker for å presentere informasjon i applikasjons- eller oppgavespesifikke konfigurasjoner. Videre forbyr ikke relasjonelle lokale eller applikasjonsspesifikke strukturer eller tabeller fra å bli opprettet, selv om mange vanlige utviklingsverktøy ikke gir en slik funksjon direkte, forutsatt at objekter vil bli brukt i stedet. Dette gjør det vanskelig å vite om det angitte ikke-utviklerperspektivet om relasjonelt er iboende i relasjonelle, eller bare et produkt av gjeldende antagelser om praksis og verktøyimplementering.
  • Sett vs. grafforhold  - Forholdet mellom forskjellige elementer (objekter eller poster) har en tendens til å bli håndtert annerledes mellom paradigmene. Relasjonsforhold er vanligvis basert på idiomer hentet fra settteori , mens objektrelasjoner lener seg mot idiomer adoptert fra grafteori (inkludert trær ). Selv om hver kan representere den samme informasjonen som den andre, er tilnærmingene de gir for å få tilgang til og administrere informasjon forskjellige.

Som et resultat av objekt -relasjonell impedans -mismatch, argumenteres det ofte av partisaner på begge sider av debatten at den andre teknologien burde forlates eller reduseres i omfang. Noen talsmenn for databaser ser på tradisjonelle "prosessuelle" språk som mer kompatible med et RDBMS enn mange OO -språk; eller foreslå at en mindre OO -stil burde brukes. (Spesielt argumenteres det for at langlivede domeneobjekter i søknadskoden ikke burde eksistere; slike objekter som eksisterer, bør opprettes når en spørring utføres og avhendes når en transaksjon eller oppgave er fullført). Motsatt hevder noen OO-talsmenn at mer OO-vennlige utholdenhetsmekanismer, for eksempel OODBMS , bør utvikles og brukes, og at relasjonell teknologi bør avvikles. Mange (om ikke de fleste) programmerere og DBA -er har ingen av disse synspunktene; og se på objekt -relasjons -impedans -mismatch som et rent faktum i livet som informasjonsteknologi må håndtere.

Det argumenteres også for at O/R -kartleggingen lønner seg i noen situasjoner, men er sannsynligvis oversolgt: den har fordeler i tillegg til ulemper. Skeptikere påpeker at det er verdt å tenke seg godt om før du bruker det, da det i noen tilfeller vil gi liten verdi.

Se også

Referanser

Eksterne linker