I objektorienterade databaser (OODBs) kan användare ställa in operationer på en viss databas, som består av objekt som kan vara av en mängd olika typer och för vilka operationer är inställda. De kan effektivt hantera binär information som multimediaobjekt. En annan extra fördel med OODB är att den kan programmeras med små procedurskillnader utan att påverka hela systemet.
Förutsättningar för att skapa standarden
Historien om objektorienterade OODB-databaser börjar i slutet av förra seklet. De skapades för att möta behoven hos nya applikationer. Antagandet var att objektorienterade databaser skulle revolutionera mjukvarusystemen under 1990-talet. Det står nu klart att så inte är fallet. Men återupplivandet av detta koncept genom de fria mjukvarugemenskaperna och identifieringen av lämpliga applikationer för det motiverar en översyn av egenskapernaOODB, som är ett alternativ till de allestädes närvarande relationsdatabaserna.
Objektorienterad ger flexibiliteten att hantera vissa eller alla krav och är inte begränsad till datatyperna och frågespråken i traditionella databaser. En nyckelfunktion hos OODBs är förmågan de ger utvecklaren, vilket gör att han kan specificera både strukturen för komplexa objekt och applikationsoperationerna. En annan anledning till att skapa OODBs är den växande användningen av språk för mjukvaruutveckling.
Databaser har blivit grunden för många informationssystem, men traditionella databaser är svåra att använda när applikationerna som kommer åt dem är skrivna i C++, Smalltalk eller Java. Till exempel designades 1C objektorienterade databaser på ett sådant sätt att de kan integreras direkt med applikationer som använder objektorienterade språk genom att anta deras koncept: Visual Studio. Net, C ++, C, Microsoft SQL Server och andra.
Den största fördelen med OODB är att behovet av RMs1 (impedans) helt elimineras med efterföljande prestandaförbättringar.
Flaws:
- Mycket primitiva samrådsmekanismer, ingen plattform som accepteras av egen standard.
- Kan inte lagra procedurer eftersom objekt endast kan nås i klienten.
- Omognad på marknaden.
- Ingen fysisk gruppering av objekt.
Objektparadigm
Objektorienterade databaser är programmerbara databaser som lagrar komplexa data och dess relationer direkt utan att tilldela rader och kolumner, vilket gör dem mer lämpade för applikationer som fungerar med stora partier. Objekt har många-till-många-relationer och är tillgängliga genom att använda pekare som är associerade med dem för att upprätta relationer. Som alla programmerbara, tillhandahåller OODB en applikationsutvecklingsmiljö och ett beständigt arkiv redo för exploatering. Den lagrar och manipulerar information som kan digitaliseras i form av objekt, ger snabb åtkomst och ger fantastiska bearbetningsmöjligheter.
Grundläggande begrepp som används i en objektorienterad databas:
- objektidentitet;
- konstruktortyp;
- språkkompatibilitet;
- typ hierarkier och arv;
- bearbetar komplexa objekt;
- polymorfism och operatörsöverbelastning;
- skapa versioner.
För att fullt ut överväga alla aspekter som kännetecknar en objektorienterad databas är det viktigt att notera alla viktiga objektparadigm:
- Encapsulation är en egenskap som låter dig dölja information för andra objekt och därigenom förhindra felaktig åtkomst eller konflikter.
- Arv är en egenskap genom vilken objekt ärver beteende i en klasshierarki.
- Polymorfism är en egenskap hos en operation som den kan tillämpas påolika typer av objekt.
- Gränssnittet eller signaturen för en operation inkluderar namnet och datatyperna för dess argument eller parametrar.
- Implementeringen eller metoden för en operation specificeras separat och kan ändras utan att det påverkar gränssnittet. Användarapplikationer kan arbeta med data genom att anropa specificerade operationer genom deras namn och argument, oavsett hur de implementerades.
Klasser och funktionalitet
När man överväger begreppet klasser i OODB, är det nödvändigt att skilja mellan termerna "klass" och "typ". En typ används för att beskriva en uppsättning objekt med liknande beteende. I denna mening beror det på vilka operationer som kan anropas på objektet. En klass är en samling objekt som delar samma interna struktur, så den definierar en implementering, medan en typ beskriver hur den används.
Termen instansiering hänvisar till det faktum att instansiering av en klass kan användas för att producera en uppsättning objekt som har samma struktur och beteende som satts av klassen.
En funktion som är mycket viktig för utvecklingen av objekt är att den kan ändra sin klass, inklusive attribut och operationer, samtidigt som identiteten bibehålls. Detta skulle kräva en mekanism för att hantera den resulterande semantiska integriteten.
Genom att ärva en organisations objektorienterade databas kan en klass definieras som en underklass till en redan existerande superklass. Det kommer att ärva alla attribut och metoder från de senare och kan valfritt definieraegen. Detta koncept är en viktig mekanism för att stödja återanvändning. Samma delar av strukturen för två olika klasser kan bara definieras en gång i en gemensam superklass, så mindre kod kommer att skrivas. Det finns några system som tillåter en klass att vara en underklass av mer än en superklass. Den här funktionen kallas multipelarv i motsats till enkelarv.
Exempel på en objektorienterad databas
Det är ofta användbart att använda samma namn för olika men liknande metoder för mediasuperklassen från bild- och videoklasserna. Många filer kan ses av olika tittare. De behöver ofta se alla foton och videor med "view"-metoden, och lämpligt program måste startas. När funktionen anropas och en länk till videon skickas, startas mediaspelaren. För att implementera denna funktion är det först och främst nödvändigt att definiera "presentation"-operationen i den vanliga mediasuperklassen från bild- och videoklasserna. Var och en av underklasserna omdefinierar uppslagsoperationen för deras specifika behov. Detta resulterar i olika metoder som har samma operationsnamn. I det här fallet har användningen av den här funktionen en viktig fördel.
OODB-struktur
Det objektorienterade paradigmet är baserat på inkapsling av data och kod relaterad till varje objekt i en enda modul. Begreppsmässigt utförs all interaktion mellan det och resten av systemet med hjälp av meddelanden. Därav gränssnittetmellan dem bestäms av den tillåtna uppsättningen.
I allmänhet är varje objekt associerat med en uppsättning:
- Variabler som innehåller objektdata och motsvarar ER-modellattribut.
- Meddelanden han svarar på. Var och en kan ha parametrar eller inte, en eller flera.
- Metoder, som var och en är en kod som implementerar meddelanden och returnerar ett värde som svar på det.
Meddelanden i en OO-miljö innebär inte användning av fysiska SMS i datornätverk. Tvärtom hänvisar det till utbyte av förfrågningar mellan objekt, oavsett de korrekta detaljerna i deras genomförande. Ibland anropar ett uttryck en metod för att utlösa det faktum att ett meddelande har skickats till ett objekt, och använder exekveringen av motsvarande metod.
Objektidentitet
Det objektorienterade databassystemet ger en unik identifiering för varje oberoende objekt som lagras i databasen. Det implementeras vanligtvis med hjälp av en systemgenererad unik objektidentifierare eller OID. OID-värdet är osynligt för den externa användaren, men systemet använder det internt för att hantera länkar mellan objekt.
Den huvudsakliga egenskapen hos en OID är att vara oföränderlig. OID-värdet för ett visst objekt bör aldrig ändras. Detta bevarar identiteten hos den verkliga världen som representeras. Det är också att föredra att varje OID endast används en gång, även om det tas bort från databasen, bör dess OID inte tilldelas en annan. Det anses också ofta vara olämpligt att basera det på en fysiskadressen till objektet som lagras, eftersom omorganisering av dem i databasen kan ändra OID. Vissa system använder dock den fysiska adressen som OID för att öka effektiviteten för att hämta objekt. Ett objektorienterat ramverk lägger automatiskt på relationsrestriktioner, vanligtvis mer tillämpliga: domän, nyckel, objektintegritet och referensintegritet.
Tre huvudkonstruktörer
I OODB kan värden eller tillstånd för komplexa objekt skapas från andra med hjälp av konstruktorer av vissa typer. Ett sätt att representera dem är att tänka på var och en som en triplett (i, c, v), där i är objektets unika identifierare (OID), c är konstruktorn, det vill säga en pekare till hur objektets värde är skapat, och v är värdet eller tillståndet för objektet. Det kan finnas flera konstruktörer beroende på datamodellen och OO-systemet.
Tre grundläggande objektorienterade databaskonstruktörer:
- atoms;
- tupler;
- set.
Andra vanligare användningsområden är listor och diagram. Det finns också D-domänen, som innehåller alla grundläggande atomvärden direkt tillgängliga på systemet. De inkluderar vanligtvis heltal, reella tal, teckensträngar, datum och alla andra typer av data som systemet hanterar direkt. Både strukturen för objekt och operationer ingår i klassdefinitioner.
Kompatibilitet med programmeringsspråk
Kärnkoncepten för objektorienterade databaser används isom designverktyg och kodifierad för att fungera med databasen.
Det finns flera möjliga språk där dessa begrepp kan integreras:
- Utöka ett språk för databehandling som SQL genom att lägga till komplexa typer och OOP. System tillhandahåller objektorienterade tillägg till relationssystem, så kallade objektorienterade relationssystem.
- Använda ett befintligt objektorienterat programmeringsspråk och utöka det till att fungera med databaser. De kallas beständiga programmeringsspråk och låter utvecklare arbeta direkt med data utan att behöva gå igenom ett databehandlingsspråk som SQL. De kallas persistenta eftersom data fortsätter att existera efter slutet av programmet som skapade det.
När du bestämmer dig för vilket alternativ du ska använda, kom ihåg att beständiga språk tenderar att vara kraftfulla och det är relativt lätt att göra programmeringsfel som skadar databasen. Språkens komplexitet gör automatiska optimeringar på hög nivå, som att reducera disk I/O, svårt. I många applikationer är förmågan att göra deklarativa frågor viktig, men beständiga språk tillåter för närvarande inte sådana frågor utan problem.
Hierarki av arvstyper
Objektorienterade databasscheman kräver vanligtvis ett stort antal klasser. Men flera klasser liknar varandra. För att tillåta en direkt representation av likheterna mellan dem måste du sättadem in i en hierarki av specialiseringar. Detta koncept liknar ER-modeller. Klassspecialiseringar kallas underklasser, som definierar ytterligare attribut och metoder för en befintlig klass. Objekt skapade med underklasser ärver allt från föräldern. Vissa av dessa ärvda egenskaper kan ha lånats från de högre upp i hierarkin.
Objekt anses vara komplexa eftersom de kräver en stor mängd lagringsutrymme och inte ingår i de standarddatatyper som Object Oriented Database Management (OODBS) vanligtvis erbjuder. Eftersom storleken på objekt är betydande, kan SOOBMS ta emot en del av ett objekt och tillhandahålla det till en applikation innan det förvärvar hela objektet. Den kan också använda buffert- och cachemetoder för att få delar av ett objekt i förväg innan ett program kan komma åt dem.
OODB tillåter användare att skapa nya typer som inkluderar både struktur och operationer, i det här fallet det utvidgbara typsystemet. Du kan skapa bibliotek av nya typer genom att definiera deras struktur och operationer. Många av dem kan lagra och ta emot ett stort strukturerat objekt i form av strängar och tecken eller bitar, som skickas "som de är" till applikationsprogrammet för tolkning.
Metoden kan direkt komma åt målobjektets attribut efter namn, inklusive eventuella ärvda från överordnade klasser, men måste komma åt attribut för andra objekt med sekundära signaler. Konceptet låter dig associera samma operatörsnamn eller symbol medtvå eller flera olika implementeringar av det, beroende på vilken typ av objekt det gäller.
Byggappar
Många databasapplikationer som använder OO-system kräver flera versioner av samma objekt. Norm alt tillämpas underhållsaktiviteter på ett mjukvarusystem när deras krav förändras, och innebär att vissa av utvecklings- och implementeringsmodulerna ändras. Om systemet redan körs och om en eller flera moduler behöver ändras måste utvecklaren skapa en ny version av var och en av dem genom att göra ändringar.
Observera att det kan finnas fler än två versioner av ett objekt, om två krävs utöver originalmodulen. Egna versioner av samma mjukvarumodul kan uppdateras samtidigt. Detta kallas parallell objektorienterad databasdesign. Men det kommer alltid en punkt där de måste slås samman för att hybrid OODB ska kunna införliva de ändringar som har gjorts så att de är kompatibla.
Objektorienterade förhållanden
Alla datorsystem måste ha egenskaper för sin arkitektur för att kunna beaktas. Ett system måste till exempel ha tabeller för att betraktas som relationella. OODB är inget undantag och innehåller några grundläggande egenskaper för objektarkitekturen. Men i den verkliga världen diskuteras många av dessa egenskaper och vissa, såsom multipelt arv, anses vara förbättringar av den objektorienterade databasmodellen snarare änsom en del av baslinjen. Till exempel, i det objektorienterade språket Smalltalk, stöds inte multipelt arv, även om det anses vara en del av objektarkitekturen.
Metoder för en klass definierar en uppsättning operationer som kan utföras på ett objekt. Till exempel, när det appliceras på ett objekt returnerar det antingen ett värde eller utför någon operation för att uppdatera värdena. Ibland returnerar metoder inte det. Om metoden var utformad för att uppdatera antalet passagerare för ett fordon skulle inget värde returneras, men dataelementet i målet skulle ändra det.
Objekt är ett grundläggande begrepp i OODB. I huvudsak är objekt en abstrakt representation av de verkliga sakerna som finns lagrade i den. Ett objekt är en instans av en klass i den meningen att det är exkluderat från dess definition.
Du kan tänka dig ett objekt som ett fristående paket som har tre delar:
- Egen personlig information, datavärden.
- Privata procedurer som kommer att manipulera värden genom klassdefinitionen.
- Öppna gränssnittet så att det här objektet kan kommunicera med andra.
OODB-exempel
Att använda OODB förenklar konceptualiseringen eftersom det är mer naturligt att representera den information som behöver lagras. För att modellera strukturen eller logiken för en databas, låter användningen av klassdiagram dig introducera klasser med deras strukturella relationer och arv. För att modellera en del av dynamiken, interaktion ochbeteende mellan objekt kommer ett sekvensdiagram att användas för att representera interaktionen mellan objekt som befinner sig i ett temporärt förhållande, och beskriver de möjliga tillstånden så att de kan hittas givet det ändrade tillståndet efter händelsen inträffar.
Ett exempel på en objektorienterad databas visas nedan.
De har ett namn och en livstid, som kan vara tillfälliga eller permanenta. OODB-nyckeln är förmågan de ger utvecklaren att specificera hur många strukturer och operationer som kommer att tillämpas på dem. Det finns flexibilitet och stöd för att hantera komplexa datatyper. Du kan skapa klasser och underklasser, till exempel kan klientbasen ha en underklass av denna klients länk, och den kommer att ärva alla attribut och egenskaper hos den ursprungliga klassen, detta tillvägagångssätt låter dig snabbt och flexibelt bearbeta komplexa data.
