I objektorienterte databaser (OODBs) kan brukere sette operasjoner på en bestemt database, som er bygd opp av objekter som kan være av en lang rekke typer og som operasjoner er satt for. De kan effektivt håndtere binær informasjon som multimedieobjekter. En annen ekstra fordel med OODB er at den kan programmeres med små prosedyreforskjeller uten å påvirke hele systemet.
Forutsetninger for å lage standarden
Historien til objektorienterte OODB-databaser begynner på slutten av forrige århundre. De ble opprettet for å møte behovene til nye applikasjoner. Antakelsen var at objektorienterte databaser ville revolusjonere programvaresystemer i løpet av 1990-tallet. Det er nå klart at dette ikke er tilfelle. Gjenopplivingen av dette konseptet gjennom fri programvaresamfunn og identifisering av passende applikasjoner for det motiverer imidlertid en gjennomgang av egenskapeneOODB, som er et alternativ til de allestedsnærværende relasjonsdatabasene.
Objektorientert gir fleksibiliteten til å håndtere noen eller alle kravene og er ikke begrenset til datatypene og spørringsspråkene i tradisjonelle databaser. Et nøkkeltrekk ved OODB-er er muligheten de gir utvikleren, slik at han kan spesifisere både strukturen til komplekse objekter og applikasjonsoperasjonene. En annen grunn til å lage OODB-er er den økende bruken av språk for programvareutvikling.
Databaser har blitt grunnlaget for mange informasjonssystemer, men tradisjonelle databaser er vanskelige å bruke når applikasjonene som får tilgang til dem er skrevet i C++, Smalltalk eller Java. For eksempel ble 1C objektorienterte databaser designet på en slik måte at de kan integreres direkte med applikasjoner som bruker objektorienterte språk ved å ta i bruk konseptene deres: Visual Studio. Net, C ++, C, Microsoft SQL Server og andre.
Den største fordelen med OODB er fullstendig eliminering av behovet for RMs1 (impedans) med påfølgende ytelsesforbedringer.
Flaws:
- Veldig primitive konsultasjonsmekanismer, ingen akseptert plattform med selvstandard.
- Kan ikke lagre prosedyrer fordi objekter kun kan nås i klienten.
- Umodenhet i markedet.
- Ingen fysisk gruppering av objekter.
Objektparadigme
Objektorienterte databaser er programmerbare databaser som lagrer komplekse data og deres relasjoner direkte uten å tildele rader og kolonner, noe som gjør dem mer egnet for applikasjoner som fungerer med store batcher. Objekter har mange-til-mange relasjoner og er tilgjengelige ved bruk av pekere som er knyttet til dem for å etablere relasjoner. Som alle programmerbare, tilbyr OODB et applikasjonsutviklingsmiljø og et vedvarende depot som er klart for utnyttelse. Den lagrer og manipulerer informasjon som kan digitaliseres i form av objekter, gir rask tilgang og gir gode behandlingsmuligheter.
Grunnleggende konsepter brukt i en objektorientert database:
- objektidentitet;
- konstruktørtype;
- språkkompatibilitet;
- type hierarkier og arv;
- behandling av komplekse objekter;
- polymorfisme og operatøroverbelastning;
- oppretter versjoner.
For å fullt ut vurdere alle aspektene som karakteriserer en objektorientert database, er det viktig å merke seg alle de viktige objektparadigmene:
- Encapsulation er en egenskap som lar deg skjule informasjon for andre objekter, og dermed forhindre feiltilgang eller konflikter.
- Arv er en egenskap som objekter arver atferd med i et klassehierarki.
- Polymorfisme er en egenskap ved en operasjon som den kan brukes påforskjellige typer objekter.
- Grensesnittet eller signaturen til en operasjon inkluderer navnet og datatypene for argumentene eller parameterne.
- Implementeringen eller metoden for en operasjon er spesifisert separat og kan endres uten å påvirke grensesnittet. Brukerapplikasjoner kan arbeide med data ved å kalle opp spesifiserte operasjoner gjennom navn og argumenter, uavhengig av hvordan de ble implementert.
Klasser og funksjonalitet
Når man vurderer konseptet med klasser i OODB, er det nødvendig å skille mellom begrepene "klasse" og "type". En type brukes til å beskrive et sett med objekter med lignende oppførsel. I denne forstand avhenger det av hvilke operasjoner som kan kalles på objektet. En klasse er en samling av objekter som deler den samme interne strukturen, så den definerer en implementering, mens en type beskriver hvordan den skal brukes.
Begrepet instansiering refererer til det faktum at instansiering av en klasse kan brukes til å produsere et sett med objekter som har samme struktur og oppførsel som satt av klassen.
En funksjon som er svært viktig for utviklingen av objekter er at den kan endre klassen, inkludert attributter og operasjoner, samtidig som den opprettholder identiteten. Dette vil kreve en mekanisme for å håndtere den resulterende semantiske integriteten.
Når du arver en organisasjons objektorienterte database, kan en klasse defineres som en underklasse av en allerede eksisterende superklasse. Den vil arve alle attributter og metoder fra sistnevnte og kan eventuelt definereegen. Dette konseptet er en viktig mekanisme for å støtte gjenbruk. De samme delene av strukturen til to forskjellige klasser kan bare defineres én gang i en felles superklasse, og dermed vil mindre kode bli skrevet. Det er noen systemer som lar en klasse være en underklasse av mer enn én superklasse. Denne funksjonen kalles multippel arv i motsetning til enkeltarv.
Eksempel på en objektorientert database
Det er ofte nyttig å bruke samme navn for forskjellige, men lignende metoder for mediesuperklassen fra bilde- og videoklassene. Mange filer kan vises av forskjellige seere. De trenger ofte å se alle bilder og videoer ved å bruke «view»-metoden, og det aktuelle programmet må startes. Når funksjonen kalles opp og en lenke til videoen sendes, startes mediespilleren. For å implementere denne funksjonen, først av alt, er det nødvendig å definere "presentasjon" -operasjonen i den vanlige media-superklassen fra bilde- og videoklassene. Hver av underklassene omdefinerer oppslagsoperasjonen for deres spesifikke behov. Dette resulterer i forskjellige metoder som har samme operasjonsnavn. I dette tilfellet har bruk av denne funksjonen en viktig fordel.
OODB-struktur
Det objektorienterte paradigmet er basert på innkapsling av data og kode relatert til hvert objekt i en enkelt modul. Konseptuelt utføres alle interaksjoner mellom det og resten av systemet ved hjelp av meldinger. Derav grensesnittetmellom dem bestemmes av det tillatte settet.
Generelt er hvert objekt assosiert med et sett:
- Variabler som inneholder objektdata og samsvarer med ER-modellattributter.
- Meldinger han svarer på. Hver kan ha eller ikke ha parametere, én eller flere.
- Metoder, som hver er en kode som implementerer meldinger og returnerer en verdi som svar på den.
Meldinger i et OO-miljø innebærer ikke bruk av fysisk SMS i datanettverk. Tvert imot refererer det til utveksling av forespørsler mellom objekter, uavhengig av de riktige detaljene i implementeringen. Noen ganger kaller et uttrykk en metode for å utløse det faktum at en melding har blitt sendt til et objekt, og bruker utførelsen av den tilsvarende metoden.
Objektidentitet
Det objektorienterte databasesystemet gir en unik identifikasjon for hvert uavhengig objekt som er lagret i databasen. Det implementeres vanligvis ved hjelp av en systemgenerert unik objektidentifikator eller OID. OID-verdien er usynlig for den eksterne brukeren, men systemet bruker den internt for å administrere koblinger mellom objekter.
Hovedegenskapen til en OID er å være uforanderlig. OID-verdien for et bestemt objekt skal aldri endres. Dette bevarer identiteten til den virkelige verden som er representert. Det er også foretrukket at hver OID bare brukes én gang, selv om den er fjernet fra databasen, bør dens OID ikke tildeles en annen. Det anses også ofte som upassende å basere det på en fysiskadressen til objektet som er lagret, siden omorganisering av dem i databasen kan endre OID. Noen systemer bruker imidlertid den fysiske adressen som OID for å øke effektiviteten ved å hente objekter. Et objektorientert rammeverk pålegger automatisk relasjonsbegrensninger, vanligvis mer anvendelige: domene, nøkkel, objektintegritet og referanseintegritet.
Tre hovedkonstruktører
I OODB kan verdier eller tilstander til komplekse objekter opprettes fra andre ved å bruke konstruktører av visse typer. En måte å representere dem på er å tenke på hver enkelt som en triplett (i, c, v), der i er objektets unike identifikator (OID), c er konstruktøren, det vil si en peker til hvordan verdien av objektet er opprettet, og v er verdien eller tilstanden til objektet. Det kan være flere konstruktører avhengig av datamodellen og OO-systemet.
Tre grunnleggende objektorienterte databasekonstruktører:
- atoms;
- tupler;
- sett.
Andre mer vanlige bruksområder er lister og diagrammer. Det er også D-domenet, som inneholder alle de grunnleggende atomverdiene direkte tilgjengelig på systemet. De inkluderer vanligvis heltall, reelle tall, tegnstrenger, datoer og andre typer data som systemet håndterer direkte. Både strukturen til objekter og operasjoner er inkludert i klassedefinisjoner.
Kompatibilitet med programmeringsspråk
Kjernekonseptene til objektorienterte databaser brukes isom designverktøy og kodifisert for å fungere med databasen.
Det er flere mulige språk der disse konseptene kan integreres:
- Utvide et språk for databehandling som SQL ved å legge til komplekse typer og OOP. Systemer gir objektorienterte utvidelser til relasjonssystemer, k alt objektorienterte relasjonssystemer.
- Bruke et eksisterende objektorientert programmeringsspråk og utvide det til å fungere med databaser. De kalles vedvarende programmeringsspråk og lar utviklere jobbe direkte med data uten å måtte gå gjennom et databehandlingsspråk som SQL. De kalles vedvarende fordi dataene fortsetter å eksistere etter slutten av programmet som opprettet dem.
Når du bestemmer deg for hvilket alternativ du skal bruke, husk at vedvarende språk har en tendens til å være kraftige, og det er relativt enkelt å gjøre programmeringsfeil som skader databasen. Kompleksiteten til språk gjør automatiske optimaliseringer på høyt nivå, som å redusere disk I/O, vanskelig. I mange applikasjoner er evnen til å lage deklarative søk viktig, men vedvarende språk tillater for øyeblikket ikke slike søk uten problemer.
Hierarki av arvetyper
Objektorienterte databaseskjemaer krever vanligvis et stort antall klasser. Imidlertid er flere klasser like hverandre. For å tillate en direkte representasjon av likhetene mellom dem, må du settedem inn i et hierarki av spesialiseringer. Dette konseptet ligner på ER-modeller. Klassespesialiseringer kalles underklasser, som definerer tilleggsattributter og metoder for en eksisterende klasse. Objekter opprettet med underklasser arver alt fra overordnet. Noen av disse nedarvede egenskapene kan i seg selv ha blitt lånt fra de høyere opp i hierarkiet.
Objekter anses som komplekse fordi de krever en stor mengde lagringsplass og ikke er en del av standard datatyper som Object Oriented Database Management (OODBS) vanligvis tilbyr. Fordi størrelsen på objekter er betydelig, kan SOOBMS motta en del av et objekt og levere det til et program før det anskaffes hele objektet. Den kan også bruke buffer- og hurtigbuffermetoder for å hente deler av et objekt på forhånd før en applikasjon får tilgang til dem.
OODB lar brukere lage nye typer som inkluderer både struktur og operasjoner, i dette tilfellet det utvidbare typesystemet. Du kan opprette biblioteker av nye typer ved å definere deres struktur og operasjoner. Mange av dem kan lagre og motta et stort strukturert objekt i form av strenger og tegn eller biter, som sendes "som de er" til applikasjonsprogrammet for tolkning.
Metoden kan få direkte tilgang til målobjektets attributter ved navn, inkludert eventuelle arvet fra overordnede klasser, men må få tilgang til attributter til andre objekter med sekundære signaler. Konseptet lar deg knytte det samme operatørnavnet eller symbolet tilto eller flere forskjellige implementeringer av den, avhengig av typen objekter den gjelder.
Byggeapper
Mange databaseapplikasjoner som bruker OO-systemer krever flere versjoner av samme objekt. Vanligvis blir vedlikeholdsaktiviteter brukt på et programvaresystem etter hvert som kravene deres endres, og innebærer å endre noen av utviklings- og implementeringsmodulene. Hvis systemet allerede kjører og hvis en eller flere moduler må endres, må utvikleren lage en ny versjon av hver av dem ved å gjøre endringer.
Merk at det kan være mer enn to versjoner av et objekt, i tilfelle det kreves to i tillegg til den originale modulen. Egne versjoner av samme programvaremodul kan oppdateres samtidig. Dette kalles parallell objektorientert databasedesign. Det kommer imidlertid alltid et punkt hvor de må slås sammen for at hybrid OODB skal inkludere endringene som er gjort slik at de er kompatible.
Objektorienterte forhold
Alle datasystemer må ha egenskaper til sin arkitektur for å bli vurdert. For eksempel må et system ha tabeller for å regnes som relasjonelle. OODB er intet unntak og inneholder noen grunnleggende egenskaper for objektarkitekturen. Men i den virkelige verden diskuteres mange av disse egenskapene, og noen, for eksempel multippel arv, anses som forbedringer av den objektorienterte databasemodellen i stedet forsom en del av grunnlinjen. For eksempel, i det objektorienterte språket Smalltalk, støttes ikke multippel arv, selv om det anses som en del av objektarkitekturen.
Metoder for en klasse definerer et sett med operasjoner som kan utføres på et objekt. For eksempel, når det brukes på et objekt, returnerer det enten en verdi eller utfører en operasjon for å oppdatere verdiene. Noen ganger returnerer ikke metoder det. Hvis metoden var utformet for å oppdatere antall passasjerer for et kjøretøy, ville ingen verdi blitt returnert, men dataelementet i målet ville endret det.
Objekter er et grunnleggende konsept i OODB. I hovedsak er objekter en abstrakt representasjon av de virkelige tingene som er lagret i den. Et objekt er en forekomst av en klasse i den forstand at det er ekskludert fra definisjonen.
Du kan tenke på et objekt som en selvstendig pakke som har tre deler:
- Egen personlig informasjon, dataverdier.
- Private prosedyrer som vil manipulere verdier gjennom klassedefinisjonen.
- Åpne grensesnittet slik at dette objektet kan kommunisere med andre.
OODB-eksempler
Å bruke OODB forenkler konseptualiseringen fordi det er mer naturlig å representere informasjonen som skal lagres. For å modellere strukturen eller logikken til en database, lar bruken av klassediagrammer deg introdusere klasser med deres strukturelle relasjoner og arv. For å modellere en del av dynamikken, samhandling ogoppførsel mellom objekter, vil et sekvensdiagram brukes til å representere interaksjonen mellom objekter som befinner seg i et midlertidig forhold, og beskriver mulige tilstander slik at de kan bli funnet gitt den endrede tilstanden etter at hendelsen inntreffer.
Et eksempel på en objektorientert database er vist nedenfor.
De har et navn og en levetid, som kan være midlertidig eller permanent. OODB-nøkkelen er muligheten de gir utvikleren til å spesifisere hvor mange strukturer og operasjoner som skal brukes på dem. Det er fleksibilitet og støtte for håndtering av komplekse datatyper. Du kan lage klasser og underklasser, for eksempel kan klientbasen ha en underklasse av denne klientens lenke, og den vil arve alle attributtene og egenskapene til den opprinnelige klassen, denne tilnærmingen lar deg raskt og fleksibelt behandle komplekse data.
