In objekgeoriënteerde databasisse (OODB's) kan gebruikers bewerkings op 'n spesifieke databasis stel, wat bestaan uit voorwerpe wat van 'n wye verskeidenheid tipes kan wees en waarvoor bewerkings ingestel is. Hulle kan binêre inligting doeltreffend verwerk, soos multimedia-objekte. Nog 'n bykomende voordeel van OODB is dat dit met geringe prosedurele verskille geprogrammeer kan word sonder om die hele stelsel te beïnvloed.
Voorvereistes vir die skepping van die standaard
Die geskiedenis van objekgeoriënteerde OODB-databasisse begin aan die einde van die vorige eeu. Hulle is geskep om aan die behoeftes van nuwe toepassings te voldoen. Die aanname was dat objekgeoriënteerde databasisse sagtewarestelsels gedurende die 1990's sou revolusioneer. Dit is nou duidelik dat dit nie die geval is nie. Die herlewing van hierdie konsep deur die vrye sagteware gemeenskappe en die identifisering van geskikte toepassings daarvoor motiveer egter 'n hersiening van die kenmerkeOODB, wat 'n alternatief is vir die alomteenwoordige relasionele databasisse.
Objektgeoriënteerd bied die buigsaamheid om sommige of al die vereistes te hanteer en is nie beperk tot die datatipes en navraagtale van tradisionele databasisse nie. 'n Sleutelkenmerk van OODB's is die vermoë wat hulle aan die ontwikkelaar bied, wat hom in staat stel om beide die struktuur van komplekse voorwerpe en die toepassingsbewerkings te spesifiseer. Nog 'n rede vir die skep van OODB's is die toenemende gebruik van tale vir sagteware-ontwikkeling.
Databasisse het die grondslag van baie inligtingstelsels geword, maar tradisionele databasisse is moeilik om te gebruik wanneer die toepassings wat toegang daartoe verkry, in C++, Smalltalk of Java geskryf is. Byvoorbeeld, 1C objekgeoriënteerde databasisse is so ontwerp dat hulle direk geïntegreer kan word met toepassings wat objekgeoriënteerde tale gebruik deur hul konsepte aan te neem: Visual Studio. Net, C ++, C, Microsoft SQL Server en ander.
Die grootste voordeel van OODB is die volledige uitskakeling van die behoefte aan RMs1 (impedansie) met daaropvolgende prestasieverbeterings.
Flaws:
- Baie primitiewe konsultasiemeganismes, geen selfstandaard-aanvaarde platform nie.
- Kan nie prosedures stoor nie, want voorwerpe kan slegs in die kliënt verkry word.
- Onvolwassenheid in die mark.
- Geen fisiese groepering van voorwerpe nie.
Objectparadigma
Objekgeoriënteerde databasisse is programmeerbare databasisse wat komplekse data en sy verwantskappe direk stoor sonder om rye en kolomme toe te ken, wat hulle meer geskik maak vir toepassings wat met groot bondels werk. Voorwerpe het baie-tot-baie verhoudings en is toeganklik deur die gebruik van aanwysers wat daarmee geassosieer word om verhoudings te vestig. Soos enige programmeerbare, bied OODB 'n toepassingsontwikkelingsomgewing en 'n aanhoudende bewaarplek gereed vir gebruik. Dit stoor en manipuleer inligting wat in die vorm van voorwerpe gedigitaliseer kan word, bied vinnige toegang en bied uitstekende verwerkingsvermoëns.
Basiese konsepte wat in 'n objekgeoriënteerde databasis gebruik word:
- voorwerpidentiteit;
- konstruktortipe;
- taalversoenbaarheid;
- tipe hiërargieë en oorerwing;
- verwerking van komplekse voorwerpe;
- polimorfisme en operateuroorlading;
- skep weergawes.
Om al die aspekte wat 'n objekgeoriënteerde databasis kenmerk ten volle te oorweeg, is dit belangrik om op al die belangrike objekparadigmas te let:
- Encapsulation is 'n eienskap wat jou toelaat om inligting vir ander voorwerpe te versteek en sodoende verkeerde toegang of konflikte te voorkom.
- Erfenis is 'n eienskap waardeur voorwerpe gedrag in 'n klashiërargie erf.
- Polimorfisme is 'n eienskap van 'n bewerking waarmee dit toegepas kan wordverskillende soorte voorwerpe.
- Die koppelvlak of handtekening van 'n bewerking sluit die naam en datatipes van sy argumente of parameters in.
- Die implementering of metode van 'n bewerking word afsonderlik gespesifiseer en kan verander word sonder om die koppelvlak te beïnvloed. Gebruikertoepassings kan op data werk deur gespesifiseerde bewerkings deur hul name en argumente te noem, ongeag hoe dit geïmplementeer is.
Klasse en funksionaliteit
Wanneer die konsep van klasse in OODB oorweeg word, is dit nodig om tussen die terme "klas" en "tipe" te onderskei. 'n Tipe word gebruik om 'n stel voorwerpe met soortgelyke gedrag te beskryf. In hierdie sin hang dit af van watter bewerkings op die voorwerp genoem kan word. 'n Klas is 'n versameling voorwerpe wat dieselfde interne struktuur deel, so dit definieer 'n implementering, terwyl 'n tipe beskryf hoe om dit te gebruik.
Die term instansiasie verwys na die feit dat instansiasie van 'n klas gebruik kan word om 'n stel voorwerpe te produseer wat dieselfde struktuur en gedrag het as wat deur die klas gestel word.
'n Eienskap wat baie belangrik is vir die evolusie van voorwerpe, is dat dit sy klas kan verander, insluitend eienskappe en bewerkings, terwyl identiteit behou word. Dit sal 'n meganisme vereis om die gevolglike semantiese integriteit te hanteer.
Deur 'n organisasie se objekgeoriënteerde databasis te erf, kan 'n klas gedefinieer word as 'n subklas van 'n reeds bestaande superklas. Dit sal alle eienskappe en metodes van laasgenoemde erf en kan opsioneel definieereie. Hierdie konsep is 'n belangrike meganisme om hergebruik te ondersteun. Dieselfde dele van die struktuur van twee verskillende klasse kan slegs een keer in 'n gemeenskaplike superklas gedefinieer word, dus sal minder kode geskryf word. Daar is sommige stelsels wat 'n klas toelaat om 'n subklas van meer as een superklas te wees. Hierdie kenmerk word meervoudige erfenis genoem, in teenstelling met enkeloorerwing.
Voorbeeld van 'n objekgeoriënteerde databasis
Dit is dikwels nuttig om dieselfde naam te gebruik vir verskillende maar soortgelyke metodes van die media-superklas vanaf die prent- en videoklasse. Baie lêers kan deur verskillende kykers bekyk word. Hulle moet dikwels alle foto's en video's met die "bekyk"-metode bekyk, en die toepaslike program moet loop. Wanneer die funksie geroep word en 'n skakel na die video deurgegee word, word die mediaspeler geloods. Om hierdie kenmerk te implementeer, is dit eerstens nodig om die "aanbieding"-operasie in die algemene media-superklas uit die foto- en videoklasse te definieer. Elkeen van die subklasse herdefinieer die soekoperasie vir hul spesifieke behoeftes. Dit lei tot verskillende metodes wat dieselfde bewerkingsnaam het. In hierdie geval het die gebruik van hierdie funksie 'n belangrike voordeel.
OODB-struktuur
Die objekgeoriënteerde paradigma is gebaseer op die inkapseling van data en kode wat verband hou met elke objek in 'n enkele module. Konseptueel word alle interaksies tussen dit en die res van die stelsel uitgevoer met behulp van boodskappe. Vandaar die koppelvlaktussen hulle word bepaal deur die toegelate stel.
In die algemeen word elke voorwerp met 'n stel geassosieer:
- Veranderlikes wat objekdata bevat en ooreenstem met ER-modelkenmerke.
- Boodskappe waarop hy antwoord. Elkeen mag of nie parameters hê nie, een of meer.
- Metodes, wat elkeen 'n kode is wat boodskappe implementeer en 'n waarde in reaksie daarop terugstuur.
Boodskappe in 'n OO-omgewing impliseer nie die gebruik van fisiese SMS in rekenaarnetwerke nie. Inteendeel, dit verwys na die uitruil van versoeke tussen voorwerpe, ongeag die korrekte besonderhede van die implementering daarvan. Soms roep 'n uitdrukking 'n metode om die feit te aktiveer dat 'n boodskap na 'n voorwerp gestuur is, en gebruik die uitvoering van die ooreenstemmende metode.
Voorwerpidentiteit
Die objekgeoriënteerde databasisstelsel verskaf 'n unieke identifikasie vir elke onafhanklike objek wat in die databasis gestoor word. Dit word gewoonlik geïmplementeer met behulp van 'n stelselgegenereerde unieke objekidentifiseerder of OID. Die OID-waarde is onsigbaar vir die eksterne gebruiker, maar die stelsel gebruik dit intern om skakels tussen voorwerpe te bestuur.
Die hoofeienskap van 'n OID is om onveranderlik te wees. Die OID-waarde vir 'n spesifieke voorwerp moet nooit verander nie. Dit behou die identiteit van die werklike wêreld wat verteenwoordig word. Dit word ook verkies dat elke OID slegs een keer gebruik word, al word dit van die databasis verwyder, moet sy OID nie aan 'n ander toegeken word nie. Dit word ook dikwels as onvanpas beskou om dit op 'n fisiese te baseerdie adres van die voorwerp in stoor, aangesien die herorganisering van hulle in die databasis die OID kan verander. Sommige stelsels gebruik egter die fisiese adres as die OID om die doeltreffendheid van die herwinning van voorwerpe te verhoog. 'n Objekgeoriënteerde raamwerk stel outomaties relasionele beperkings, gewoonlik meer toepaslik: domein, sleutel, objekintegriteit en verwysingsintegriteit.
Drie hoofkonstrukteurs
In OODB kan waardes of toestande van komplekse voorwerpe van ander geskep word deur gebruik te maak van konstruktors van sekere tipes. Een manier om hulle voor te stel, is om aan elkeen te dink as 'n drieling (i, c, v), waar i die voorwerp se unieke identifiseerder (OID) is, c die konstruktor is, dit wil sê 'n wyser na hoe die waarde van die voorwerp is geskep, en v is die waarde of toestand van die voorwerp. Daar kan verskeie konstruktors wees, afhangende van die datamodel en die OO-stelsel.
Drie basiese objekgeoriënteerde databasiskonstrukteurs:
- atome;
- tuples;
- stelle.
Ander meer algemene gebruike is lyste en kaarte. Daar is ook die D-domein, wat al die basiese atoomwaardes bevat wat direk op die stelsel beskikbaar is. Dit sluit tipies heelgetalle, reële getalle, karakterstringe, datums en enige ander tipe data in wat die stelsel direk hanteer. Beide die struktuur van voorwerpe en bewerkings is ingesluit in klasdefinisies.
Verenigbaarheid met programmeertale
Die kernbegrippe van objekgeoriënteerde databasisse word gebruik inas ontwerpnutsmiddels en gekodifiseer om met die databasis te werk.
Daar is verskeie moontlike tale waarin hierdie konsepte geïntegreer kan word:
- Uitbreiding van 'n taal vir dataverwerking soos SQL deur komplekse tipes en OOP by te voeg. Stelsels verskaf objekgeoriënteerde uitbreidings aan relasionele stelsels, genoem objekgeoriënteerde relasionele stelsels.
- Gebruik 'n bestaande objekgeoriënteerde programmeertaal en brei dit uit om met databasisse te werk. Dit word aanhoudende programmeertale genoem en laat ontwikkelaars toe om direk met data te werk sonder om deur 'n dataverwerkingstaal soos SQL te gaan. Hulle word aanhoudend genoem omdat die data aanhou bestaan na die einde van die program wat dit geskep het.
Wanneer jy besluit watter opsie om te gebruik, hou in gedagte dat aanhoudende tale geneig is om kragtig te wees, en dit is relatief maklik om programmeringsfoute te maak wat die databasis beskadig. Die kompleksiteit van tale maak hoëvlak outomatiese optimalisering, soos die vermindering van skyf I/O, moeilik. In baie toepassings is die vermoë om verklarende navrae te maak belangrik, maar volgehoue tale laat tans nie sulke navrae sonder probleme toe nie.
Hiërargie van erfenistipes
Objectgeoriënteerde databasisskemas vereis tipies 'n groot aantal klasse. Verskeie klasse is egter soortgelyk aan mekaar. Om 'n direkte voorstelling van die ooreenkomste tussen hulle moontlik te maak, moet jy plaashulle in 'n hiërargie van spesialisasies. Hierdie konsep is soortgelyk aan ER-modelle. Klasspesialisasies word subklasse genoem, wat bykomende eienskappe en metodes vir 'n bestaande klas definieer. Voorwerpe wat met subklasse geskep word, erf alles van die ouer. Sommige van hierdie oorgeërfde eienskappe is dalk self ontleen aan dié hoër op in die hiërargie.
Objekte word as kompleks beskou omdat hulle 'n groot hoeveelheid stoorspasie benodig en nie deel is van die standaard datatipes wat Object Oriented Database Management (OODBS) gewoonlik bied nie. Omdat die grootte van voorwerpe beduidend is, kan SOOBMS 'n gedeelte van 'n voorwerp ontvang en dit aan 'n toepassing verskaf voordat die hele voorwerp verkry word. Dit kan ook buffer- en kasmetodes gebruik om dele van 'n voorwerp voor die tyd te kry, voordat 'n toepassing toegang daartoe kan kry.
OODB laat gebruikers toe om nuwe tipes te skep wat beide struktuur en bedrywighede insluit, in hierdie geval die uitbreidbare tipe stelsel. Jy kan biblioteke van nuwe tipes skep deur hul struktuur en bedrywighede te definieer. Baie van hulle kan 'n groot gestruktureerde voorwerp in die vorm van stringe en karakters of stukkies stoor en ontvang, wat "soos dit is" na die toepassingsprogram deurgegee word vir interpretasie.
Die metode kan direk toegang verkry tot die teikenvoorwerp se kenmerke op naam, insluitend enige wat van ouerklasse geërf is, maar moet toegang verkry tot kenmerke van ander voorwerpe met sekondêre seine. Die konsep laat jou toe om dieselfde operateur se naam of simbool te assosieertwee of meer verskillende implementerings daarvan, afhangende van die tipe voorwerpe waarop dit van toepassing is.
Bouprogramme
Baie databasistoepassings wat OO-stelsels gebruik, vereis veelvuldige weergawes van dieselfde voorwerp. Instandhoudingsaktiwiteite word tipies op 'n sagtewarestelsel toegepas soos hul vereistes verander, en behels die verandering van sommige van die ontwikkelings- en implementeringsmodules. As die stelsel reeds loop en as een of meer modules verander moet word, moet die ontwikkelaar 'n nuwe weergawe van elkeen van hulle skep deur veranderinge aan te bring.
Let daarop dat daar meer as twee weergawes van 'n voorwerp kan wees, ingeval twee bykomend tot die oorspronklike module vereis word. Eie weergawes van dieselfde sagtewaremodule kan terselfdertyd opgedateer word. Dit word die parallelle ontwerp van objekgeoriënteerde databasisse genoem. Daar kom egter altyd 'n punt waar hulle saamgevoeg moet word sodat die hibriede OODB die veranderinge wat aangebring is, kan inkorporeer sodat hulle versoenbaar is.
Objekgeoriënteerde toestande
Alle rekenaarstelsels moet eienskappe van hul argitektuur hê om oorweeg te word. Byvoorbeeld, 'n stelsel moet tabelle hê om as relasioneel beskou te word. OODB is geen uitsondering nie en bevat 'n paar basiese eienskappe van die objek argitektuur. In die werklike wêreld word baie van hierdie eienskappe egter bespreek en sommige, soos meervoudige oorerwing, word beskou as verbeterings aan die objekgeoriënteerde databasismodel eerder asas deel van die basislyn. Byvoorbeeld, in die objekgeoriënteerde taal Smalltalk word meervoudige oorerwing nie ondersteun nie, al word dit as deel van die objek-argitektuur beskou.
Metodes vir 'n klas definieer 'n stel bewerkings wat op 'n voorwerp uitgevoer kan word. Byvoorbeeld, wanneer dit op 'n voorwerp toegepas word, gee dit óf 'n waarde terug óf voer een of ander bewerking uit om die waardes op te dateer. Soms gee metodes dit nie terug nie. As die metode ontwerp is om die aantal passasiers vir 'n voertuig op te dateer, sal geen waarde teruggestuur word nie, maar die data-element in die teiken sal dit verander.
Objekte is 'n fundamentele konsep in OODB. In wese is voorwerpe 'n abstrakte voorstelling van die werklike wêreld dinge wat daarin gestoor word. 'n Voorwerp is 'n geval van 'n klas in die sin dat dit uitgesluit is van sy definisie.
Jy kan aan 'n voorwerp dink as 'n selfstandige pakket wat drie dele het:
- Eie persoonlike inligting, datawaardes.
- Private prosedures wat waardes sal manipuleer deur die klasdefinisie.
- Maak koppelvlak oop sodat hierdie voorwerp met ander kan kommunikeer.
OODB-voorbeelde
Die gebruik van OODB vereenvoudig die konseptualisering omdat dit meer natuurlik is om die inligting voor te stel wat gestoor moet word. Om die struktuur of logika van 'n databasis te modelleer, laat die gebruik van klasdiagramme jou toe om klasse met hul strukturele verwantskappe en oorerwing bekend te stel. Ten einde deel van die dinamika, interaksie engedrag tussen voorwerpe, sal 'n volgordediagram gebruik word om die interaksie tussen voorwerpe wat in 'n tydelike verhouding geleë is voor te stel, wat die moontlike toestande beskryf sodat hulle gevind kan word gegewe die veranderde toestand nadat die gebeurtenis plaasgevind het.
'n Voorbeeld van 'n objekgeoriënteerde databasis word hieronder getoon.
Hulle het 'n naam en 'n leeftyd, wat tydelik of permanent kan wees. Die OODB-sleutel is die vermoë wat hulle aan die ontwikkelaar verskaf om te spesifiseer hoeveel strukture en bedrywighede daarop toegepas sal word. Daar is buigsaamheid en ondersteuning vir die hantering van komplekse datatipes. Jy kan klasse en subklasse skep, byvoorbeeld, die kliëntebasis kan 'n subklas van hierdie kliënt se skakel hê, en dit sal al die eienskappe en kenmerke van die oorspronklike klas erf, hierdie benadering laat jou toe om komplekse data vinnig en buigsaam te verwerk.