I objektorienterede databaser (OODB'er) kan brugere indstille operationer på en bestemt database, som består af objekter, der kan være af en lang række forskellige typer, og for hvilke operationer er indstillet. De kan effektivt håndtere binær information såsom multimedieobjekter. En anden ekstra fordel ved OODB er, at den kan programmeres med små proceduremæssige forskelle uden at påvirke hele systemet.
Forudsætninger for oprettelse af standarden
Historien om objektorienterede OODB-databaser begynder i slutningen af forrige århundrede. De blev skabt for at imødekomme behovene for nye applikationer. Antagelsen var, at objektorienterede databaser ville revolutionere softwaresystemer i løbet af 1990'erne. Det står nu klart, at det ikke er tilfældet. Genoplivningen af dette koncept gennem de frie software-fællesskaber og identifikation af passende applikationer til det motiverer dog en gennemgang af egenskaberneOODB, som er et alternativ til de allestedsnærværende relationsdatabaser.
Objektorienteret giver fleksibiliteten til at håndtere nogle eller alle kravene og er ikke begrænset til datatyperne og forespørgselssprogene i traditionelle databaser. Et nøgletræk ved OODB'er er den evne, de giver udvikleren, hvilket giver ham mulighed for at specificere både strukturen af komplekse objekter og applikationsoperationerne. En anden grund til at oprette OODB'er er den voksende brug af sprog til softwareudvikling.
Databaser er blevet grundlaget for mange informationssystemer, men traditionelle databaser er svære at bruge, når de programmer, der får adgang til dem, er skrevet i C++, Smalltalk eller Java. For eksempel blev 1C objektorienterede databaser designet på en sådan måde, at de kan integreres direkte med applikationer, der bruger objektorienterede sprog ved at adoptere deres koncepter: Visual Studio. Net, C ++, C, Microsoft SQL Server og andre.
Den største fordel ved OODB er den fuldstændige eliminering af behovet for RMs1 (impedans) med efterfølgende forbedringer af ydeevnen.
Flaws:
- Meget primitive høringsmekanismer, ingen selvstandard accepteret platform.
- Kan ikke gemme procedurer, fordi objekter kun kan tilgås i klienten.
- Umodenhed på markedet.
- Ingen fysisk gruppering af objekter.
Objektparadigme
Objektorienterede databaser er programmerbare databaser, der gemmer komplekse data og deres relationer direkte uden at tildele rækker og kolonner, hvilket gør dem mere velegnede til applikationer, der arbejder med store batches. Objekter har mange-til-mange relationer og er tilgængelige ved brug af pointere, der er knyttet til dem, for at etablere relationer. Som enhver programmerbar leverer OODB et applikationsudviklingsmiljø og et vedvarende lager klar til udnyttelse. Den gemmer og manipulerer information, der kan digitaliseres i form af objekter, giver hurtig adgang og giver fantastiske behandlingsmuligheder.
Grundlæggende begreber brugt i en objektorienteret database:
- objektidentitet;
- konstruktørtype;
- sprogkompatibilitet;
- type hierarkier og arv;
- behandling af komplekse objekter;
- polymorfi og operatøroverbelastning;
- opretter versioner.
For fuldt ud at overveje alle de aspekter, der karakteriserer en objektorienteret database, er det vigtigt at bemærke alle de vigtige objektparadigmer:
- Encapsulation er en egenskab, der giver dig mulighed for at skjule oplysninger for andre objekter og derved forhindre forkert adgang eller konflikter.
- Inheritance er en egenskab, hvormed objekter nedarver adfærd i et klassehierarki.
- Polymorfi er en egenskab ved en operation, som den kan anvendes påforskellige typer objekter.
- Grænsefladen eller signaturen for en operation inkluderer navnet og datatyperne for dens argumenter eller parametre.
- Implementeringen eller metoden for en operation er specificeret separat og kan ændres uden at påvirke grænsefladen. Brugerapplikationer kan arbejde med data ved at kalde specificerede operationer gennem deres navne og argumenter, uanset hvordan de blev implementeret.
Klasser og funktionalitet
Når man overvejer begrebet klasser i OODB, er det nødvendigt at skelne mellem udtrykkene "klasse" og "type". En type bruges til at beskrive et sæt objekter med lignende adfærd. I denne forstand afhænger det af, hvilke operationer der kan kaldes på objektet. En klasse er en samling af objekter, der deler den samme interne struktur, så den definerer en implementering, mens en type beskriver, hvordan den bruges.
Udtrykket instansiering refererer til det faktum, at instansiering af en klasse kan bruges til at producere et sæt objekter, der har samme struktur og adfærd som angivet af klassen.
En funktion, der er meget vigtig for udviklingen af objekter, er, at den kan ændre sin klasse, inklusive attributter og operationer, og samtidig bevare identiteten. Dette ville kræve en mekanisme til at håndtere den resulterende semantiske integritet.
Når du arver en organisations objektorienterede database, kan en klasse defineres som en underklasse af en allerede eksisterende superklasse. Det vil arve alle attributter og metoder fra sidstnævnte og kan eventuelt definereegen. Dette koncept er en vigtig mekanisme til at understøtte genbrug. De samme dele af strukturen af to forskellige klasser kan kun defineres én gang i en fælles superklasse, så der vil blive skrevet mindre kode. Der er nogle systemer, der tillader en klasse at være en underklasse af mere end én superklasse. Denne funktion kaldes multipel arv i modsætning til enkelt arv.
Eksempel på en objektorienteret database
Det er ofte nyttigt at bruge det samme navn til forskellige, men lignende metoder i mediesuperklassen fra billed- og videoklasserne. Mange filer kan ses af forskellige fremvisere. De har ofte brug for at se alle billeder og videoer ved hjælp af "view"-metoden, og det relevante program skal startes. Når funktionen kaldes og et link til videoen sendes, startes medieafspilleren. For at implementere denne funktion er det først og fremmest nødvendigt at definere "præsentations"-operationen i den almindelige medie-superklasse fra billed- og videoklasserne. Hver af underklasserne omdefinerer opslagsoperationen til deres specifikke behov. Dette resulterer i forskellige metoder, der har samme operationsnavn. I dette tilfælde har brugen af denne funktion en vigtig fordel.
OODB-struktur
Det objektorienterede paradigme er baseret på indkapsling af data og kode relateret til hvert objekt i et enkelt modul. Konceptuelt udføres alle interaktioner mellem det og resten af systemet ved hjælp af beskeder. Derfor interfacetmellem dem bestemmes af det tilladte sæt.
Generelt er hvert objekt forbundet med et sæt:
- Variabler, der indeholder objektdata og svarer til ER-modelattributter.
- Beskeder han svarer på. Hver kan have eller ikke have parametre, en eller flere.
- Metoder, som hver især er en kode, der implementerer meddelelser og returnerer en værdi som svar på den.
Beskeder i et OO-miljø indebærer ikke brug af fysisk SMS i computernetværk. Tværtimod henviser det til udveksling af anmodninger mellem objekter, uanset de korrekte detaljer om deres implementering. Nogle gange kalder et udtryk en metode til at udløse det faktum, at en besked er blevet sendt til et objekt, og bruger udførelsen af den tilsvarende metode.
Objektidentitet
Det objektorienterede databasesystem giver en unik identifikation for hvert uafhængigt objekt, der er gemt i databasen. Det implementeres norm alt ved hjælp af en systemgenereret unik objektidentifikator eller OID. OID-værdien er usynlig for den eksterne bruger, men systemet bruger den internt til at styre links mellem objekter.
Hovedegenskaben ved en OID er at være uforanderlig. OID-værdien for et bestemt objekt bør aldrig ændres. Dette bevarer identiteten af den virkelige verden, der repræsenteres. Det foretrækkes også, at hvert OID kun bruges én gang, selvom det fjernes fra databasen, bør dets OID ikke tildeles til et andet. Det anses også ofte for upassende at basere det på en fysiskadressen på det lagrede objekt, da reorganisering af dem i databasen kan ændre OID. Nogle systemer bruger dog den fysiske adresse som OID for at øge effektiviteten af at hente objekter. En objektorienteret ramme pålægger automatisk relationelle begrænsninger, norm alt mere anvendelige: domæne, nøgle, objektintegritet og referenceintegritet.
Tre hovedkonstruktører
I OODB kan værdier eller tilstande for komplekse objekter oprettes fra andre ved hjælp af konstruktører af visse typer. En måde at repræsentere dem på er at tænke på hver enkelt som en triplet (i, c, v), hvor i er objektets unikke identifikator (OID), c er konstruktøren, det vil sige en peger på, hvordan værdien af objektet er oprettet, og v er værdien eller tilstanden af objektet. Der kan være flere konstruktører afhængigt af datamodellen og OO-systemet.
Tre grundlæggende objektorienterede databasekonstruktører:
- atomer;
- tupler;
- sæt.
Andre mere almindelige anvendelser er lister og diagrammer. Der er også D-domænet, som indeholder alle de grundlæggende atomværdier, der er direkte tilgængelige på systemet. De omfatter typisk heltal, reelle tal, tegnstrenge, datoer og enhver anden type data, som systemet håndterer direkte. Både strukturen af objekter og operationer er inkluderet i klassedefinitioner.
Kompatibilitet med programmeringssprog
Kernebegreberne i objektorienterede databaser bruges isom designværktøjer og kodificeret til at arbejde med databasen.
Der er flere mulige sprog, hvor disse begreber kan integreres:
- Udvidelse af et sprog til databehandling som SQL ved at tilføje komplekse typer og OOP. Systemer giver objektorienterede udvidelser til relationelle systemer, kaldet objektorienterede relationelle systemer.
- Brug af et eksisterende objektorienteret programmeringssprog og udvidelse af det til at arbejde med databaser. De kaldes persistente programmeringssprog og giver udviklere mulighed for at arbejde direkte med data uden at skulle gennemgå et databehandlingssprog som SQL. De kaldes persistente, fordi dataene fortsætter med at eksistere efter afslutningen af det program, der oprettede dem.
Når du beslutter dig for, hvilken mulighed du skal bruge, skal du huske på, at vedvarende sprog har tendens til at være kraftfulde, og det er relativt nemt at lave programmeringsfejl, der skader databasen. Sprogens kompleksitet gør automatiske optimeringer på højt niveau, såsom reduktion af disk I/O, vanskelig. I mange applikationer er evnen til at lave deklarative forespørgsler vigtig, men vedvarende sprog tillader i øjeblikket ikke sådanne forespørgsler uden problemer.
Hierarki af arvetyper
Objektorienterede databaseskemaer kræver typisk et stort antal klasser. Men flere klasser ligner hinanden. For at tillade en direkte repræsentation af lighederne mellem dem, skal du sættedem ind i et hierarki af specialiseringer. Dette koncept ligner ER-modeller. Klassespecialiseringer kaldes underklasser, som definerer yderligere attributter og metoder for en eksisterende klasse. Objekter oprettet med underklasser arver alt fra forælderen. Nogle af disse nedarvede egenskaber kan selv være lånt fra dem højere oppe i hierarkiet.
Objekter betragtes som komplekse, fordi de kræver en stor mængde lagerplads og ikke er en del af de standarddatatyper, som Object Oriented Database Management (OODBS) norm alt tilbyder. Fordi størrelsen af objekter er betydelig, kan SOOBMS modtage en del af et objekt og levere det til en applikation, før det erhverver hele objektet. Det kan også bruge buffer- og cache-metoder til at hente dele af et objekt før tid, før et program kan få adgang til dem.
OODB giver brugerne mulighed for at oprette nye typer, der inkluderer både struktur og operationer, i dette tilfælde det udvidelige typesystem. Du kan oprette biblioteker af nye typer ved at definere deres struktur og operationer. Mange af dem kan gemme og modtage et stort struktureret objekt i form af strenge og tegn eller bits, som sendes "som de er" til applikationsprogrammet til fortolkning.
Metoden kan få direkte adgang til målobjektets attributter efter navn, inklusive eventuelle nedarvet fra overordnede klasser, men skal tilgå attributter for andre objekter med sekundære signaler. Konceptet giver dig mulighed for at knytte det samme operatørnavn eller symbol tilto eller flere forskellige implementeringer af det, afhængigt af typen af objekter, det gælder for.
Building Apps
Mange databaseapplikationer, der bruger OO-systemer, kræver flere versioner af det samme objekt. Typisk anvendes vedligeholdelsesaktiviteter på et softwaresystem, efterhånden som deres krav ændres, og involverer ændring af nogle af udviklings- og implementeringsmodulerne. Hvis systemet allerede kører, og hvis et eller flere moduler skal ændres, skal udvikleren oprette en ny version af hver af dem ved at foretage ændringer.
Bemærk, at der kan være mere end to versioner af et objekt, hvis der kræves to ud over det originale modul. Egne versioner af det samme softwaremodul kan opdateres på samme tid. Dette kaldes parallelt objektorienteret databasedesign. Der kommer dog altid et punkt, hvor de skal fusioneres, for at hybrid OODB kan inkorporere de ændringer, der er foretaget, så de er kompatible.
Objektorienterede forhold
Alle computersystemer skal have egenskaber i deres arkitektur for at blive taget i betragtning. For eksempel skal et system have tabeller for at blive betragtet som relationelle. OODB er ingen undtagelse og indeholder nogle grundlæggende egenskaber for objektarkitekturen. Men i den virkelige verden diskuteres mange af disse egenskaber, og nogle, såsom multipel arv, betragtes som forbedringer af den objektorienterede databasemodel snarere endsom en del af basislinjen. I det objektorienterede sprog Smalltalk understøttes f.eks. multipel nedarvning ikke, selvom det betragtes som en del af objektarkitekturen.
Metoder for en klasse definerer et sæt operationer, der kan udføres på et objekt. For eksempel, når det anvendes på et objekt, returnerer det enten en værdi eller udfører en operation for at opdatere værdierne. Nogle gange returnerer metoder det ikke. Hvis metoden var designet til at opdatere antallet af passagerer for et køretøj, ville der ikke blive returneret nogen værdi, men dataelementet i målet ville ændre det.
Objekter er et grundlæggende begreb i OODB. I det væsentlige er objekter en abstrakt repræsentation af de virkelige ting, der er gemt i den. Et objekt er en forekomst af en klasse i den forstand, at det er udelukket fra dens definition.
Du kan tænke på et objekt som en selvstændig pakke, der har tre dele:
- Egne personlige oplysninger, dataværdier.
- Private procedurer, der vil manipulere værdier gennem klassedefinitionen.
- Åben grænseflade, så dette objekt kan kommunikere med andre.
OODB-eksempler
At bruge OODB forenkler konceptualiseringen, fordi det er mere naturligt at repræsentere den information, der skal lagres. For at modellere strukturen eller logikken i en database giver brugen af klassediagrammer dig mulighed for at introducere klasser med deres strukturelle relationer og arv. For at modellere en del af dynamikken, interaktion ogadfærd mellem objekter, vil et sekvensdiagram blive brugt til at repræsentere interaktionen mellem objekter placeret i et midlertidigt forhold, der beskriver de mulige tilstande, så de kan findes givet den ændrede tilstand efter begivenheden indtræffer.
Et eksempel på en objektorienteret database er vist nedenfor.
De har et navn og en levetid, som kan være midlertidig eller permanent. OODB-nøglen er den mulighed, de giver udvikleren til at specificere, hvor mange strukturer og operationer, der vil blive anvendt på dem. Der er fleksibilitet og support til at håndtere komplekse datatyper. Du kan oprette klasser og underklasser, for eksempel kan klientbasen have en underklasse af denne klients link, og den vil arve alle attributter og karakteristika fra den oprindelige klasse, denne tilgang giver dig mulighed for hurtigt og fleksibelt at behandle komplekse data.
