7 multidimensionelle og objektorienterede datamodeller. Objektorienteret databasemodel

Objektorienteret model

I en objektorienteret model er det ved præsentation af data muligt at identificere individuelle databaseposter. Relationer etableres mellem poster og deres behandlingsfunktioner ved hjælp af mekanismer svarende til de tilsvarende værktøjer i objektorienterede programmeringssprog.

Den standardiserede objektorienterede model er beskrevet i anbefalingerne fra ODMG-93 (Object Database Management Group) standarden.

Lad os overveje en forenklet model af en objektorienteret database. Strukturen af en objektorienteret database er grafisk repræsenteret som et træ, hvis noder er objekter. Egenskaberne for objekter er beskrevet af en standardtype eller en brugerkonstrueret type (defineret som en klasse). Værdien af en egenskab af typen klasse er et objekt, der er en instans af den tilsvarende klasse. Hvert instansobjekt i en klasse betragtes som et underordnet objekt af det objekt, hvor det er defineret som en egenskab. Et instansobjekt af en klasse tilhører dens klasse og har én forælder. Generiske relationer i databasen danner et sammenhængende hierarki af objekter. Et eksempel på den logiske struktur af en objektorienteret biblioteksvidenskabelig database er vist i fig. 2.9. Her er et objekt af typen Bibliotek forælderen til instansobjekter i klasserne Subscriber, Directory og Issue. Forskellige bogobjekter kan have samme eller forskellige forældre. Objekter af bogtypen, der har samme forælder, skal mindst afvige i adgangsnummeret (unik for hver bogforekomst), men have de samme værdier for egenskaberne isbn, udc, titel og forfatter.

Den logiske struktur i en objektorienteret database ligner overfladisk strukturen af en hierarkisk database. Den største forskel mellem dem er datamanipulationsmetoderne.

For at udføre handlinger på data i den pågældende databasemodel, bruges logiske operationer, forstærket af objektorienterede mekanismer for indkapsling, arv og polymorfi.

Indkapsling begrænser omfanget af et egenskabsnavn til grænserne for det objekt, hvori det er defineret. Så hvis vi tilføjer en egenskab til et objekt af Katalog-typen, der angiver telefonnummeret på forfatteren af bogen og kaldes telefon, så får vi egenskaber med samme navn for Subscriber- og Catalog-objekterne. Betydningen af en sådan egenskab vil blive bestemt af det objekt, hvori den er indkapslet.

Arv udvider tværtimod omfanget af en ejendom til alle efterkommere af objektet. Således kan alle objekter af Bog-typen, der er efterkommere af et objekt af Katalog-typen, tildeles egenskaberne for det overordnede objekt: isbn, udc, titel og forfatter. Hvis det er nødvendigt at udvide arvemekanismen til objekter, der ikke er umiddelbare slægtninge (for eksempel mellem to børn af samme forælder), er en abstrakt egenskab af typen abs defineret i deres fælles forfader. Definition af de abstrakte egenskaber billet og nummer i biblioteksobjektet fører således til, at disse egenskaber arves af alle underordnede objekter Subscriber, Book og Issue. Det er ikke tilfældigt, at værdierne af billetejendommen for abonnent- og udstedelsesklasserne vist i fig. 2,9 er de samme - 00015.

Polymorfi i objektorienterede programmeringssprog betyder den samme programkodes evne til at arbejde med forskellige typer data. Med andre ord betyder det, at det er tilladt for objekter af forskellige typer at have metoder (procedurer eller funktioner) med samme navne. Under udførelse af et objektprogram fungerer de samme metoder på forskellige objekter afhængigt af argumentets type. I forhold til det undersøgte eksempel betyder polymorfi, at objekter i bogklassen, der har forskellige forældre end Katalog-klassen, kan have et andet sæt egenskaber. Som følge heraf kan programmer til at arbejde med objekter i bogklassen indeholde polymorf kode.

At søge i en objektorienteret database involverer at finde ligheder mellem et objekt specificeret af brugeren og objekter gemt i databasen.

Ris. 2.9 Logisk struktur af den biblioteksvidenskabelige database

Den største fordel ved en objektorienteret datamodel i sammenligning med en relationel er evnen til at vise information om komplekse relationer mellem objekter. En objektorienteret datamodel giver dig mulighed for at identificere individuelle databaseposter og definere funktioner til behandling af dem.

Ulemperne ved den objektorienterede model er høj konceptuel kompleksitet, ubekvem databehandling og lav forespørgselshastighed.

Objektorienterede DBMS'er inkluderer POET, Jasmine, Versant, O2, ODB-Jupiter, Iris, Orion, Postgres.

Databanker som helhed klassificeres normalt efter økonomiske og juridiske karakteristika.

Ifølge vilkårene for serviceydelser er der gratis og betalte banker, som igen er opdelt i kommercielle og almennyttige (videnskabelige, biblioteksmæssige eller samfundsmæssigt betydningsfulde).

Baseret på deres ejerform opdeles BnD'er i statslige og ikke-statslige. Alt efter graden af tilgængelighed skelner de mellem dem, der er offentligt tilgængelige, og dem med et begrænset antal brugere.

Andre typer klassifikation er forbundet med individuelle komponenter i BnD.

1. Udvikling af databanker består af 4 faser:

Scene 1. Dannelse og analyse af systemkrav:

Der udarbejdes en systemspecifikation, herunder en liste over opgaver, som BnD skal løse;

Liste over slutbrugere og deres funktioner;

Liste over databasekrav;

Der udarbejdes et dokumentflowdiagram i organisationen.

Etape 2. Konceptuelt design: en informationsmodel af systemet oprettes uden reference til typen af computer og typen af systemsoftware; Der bygges en infologisk databasemodel, der bedst beskriver fagområdet i brugertermer.

Etape 3. Implementeringsdesign: et computersystem, systemsoftware og DBMS vælges; datastrukturen designes og der bygges en datalogisk model af databasen (DB-skema), som er en beskrivelse af databasens logiske struktur på sproget i det specifikke valgte DBMS.

Etape 4. Fysisk implementering, som omfatter oprettelse og indlæsning af data i databasen, udvikling og fejlretning af applikationsprogrammer til at arbejde med databasen og skrivning af dokumentation. På dette stadium bygges en fysisk model af databasen, som beskriver de anvendte lagringsenheder og metoder til fysisk organisering af data. Beskrivelsen af en databases fysiske struktur kaldes et lagerskema. I øjeblikket er der en tendens til at reducere denne type arbejde.

2. Hovedopgaver løst af databankpersonalet

BnD-staben omfatter forskellige specialister: BnD-administratorer, systemanalytikere, system- og applikationsprogrammører, operatører, teknisk udstyrsspecialister, marketingspecialister mv.

Vi lister de vigtigste funktioner og opgaver udført af personale under udvikling og drift af databasen:

1) analyse af emneområdet (bestemmelse af slutbrugeres behov, opbygning af en informationsmodel for emneområdet, identifikation af integritetsbegrænsninger);

2) design af databasestrukturen (bestemmelse af sammensætning og struktur af databasefiler, beskrivelse af dets skema i et databeskrivelsessprog);

3) indstilling af databaseintegritetsbegrænsninger;

4) indlæsning og vedligeholdelse af databasen (databasevedligeholdelse omfatter ændring, sletning og tilføjelse af poster); udvikling af last- og vedligeholdelsesteknologi; udvikling af dataindtastningsformularer; dataindtastning og kontrol;

5) databeskyttelse (adskillelse af brugere, valg og verifikation af sikkerhedsforanstaltninger, registrering af uautoriserede adgangsforsøg);

6) sikring af databasegendannelse;

7) analyse af effektiviteten af BnD og udvikling af systemet;

8) arbejde med brugere (indsamling af feedback, træning);

9) support af systemsoftware (køb, installation og udvikling);

10) organisatorisk og metodisk arbejde (valg af design- og moderniseringsmetoder, planlægning for udvikling af BnD, udvikling af dokumentation).

3. Databankbrugere

Som enhver software, organisatorisk og teknisk kompleks, eksisterer en databank i tid og rum. Det har visse udviklingsstadier:

Design,

Implementering,

Support,

Opdatering og udvikling,

Fuldstændig omorganisering.

På hvert eksistensstadium er forskellige kategorier af forbrugere forbundet til databanken.

Slutbrugere

Dette er hovedkategorien af brugere, hvis interesser er relateret til databanken. Afhængigt af karakteristikaene for den databank, der oprettes, kan rækkevidden af dens slutbrugere være væsentligt forskellig. Disse kan være tilfældige forbrugere, der fra tid til anden får adgang til databasen efter at have modtaget nogle oplysninger, og der kan være almindelige brugere. Casual forbrugere kan betragtes som mulige kunder i virksomheden, der ser et katalog over produktion eller tjenester med en generaliseret eller detaljeret beskrivelse. Medarbejdere, der arbejder med programmer, der er specielt designet til dem, og som giver automatisering af deres handlinger i produktivitetsfunktioner, kan være almindelige brugere. For eksempel har en administrator, der planlægger arbejdet i en hjælpeafdeling af et computerfirma, et program, der hjælper ham med at planlægge og arrangere aktuelle ordrer i henhold til instruktionerne, overvåge fremskridtene i deres produktivitet og organisere det nødvendige tilbehør på lageret til nye ordrer. Grundlæggende, specialiseret viden, der ikke bør kræves af slutbrugere inden for områderne sprog og computerteknologi.

Databankadministratorer

Dette er en gruppe af brugere, der i den indledende fase af udviklingen af en databank er ansvarlige for dens optimale design ud fra synspunktet om den samtidige drift af et sæt slutbrugere; til støtte er scenen ansvarlig for den korrekte betjening af denne stak information i flerbrugertilstand. Under udviklings- og omorganiseringsfasen er denne gruppe ansvarlig for at sikre, at stakken kan reorganiseres korrekt uden at ændre eller afslutte dens rutinemæssige vedligeholdelse.

Applikationsudviklere og administratorer

Dette er en brugergruppe, der fungerer under design, oprettelse og reorganisering af en databank. Applikationsadministratorer koordinerer udviklernes arbejde med at udvikle en specifik applikation eller en gruppe applikationer kombineret i et funktionelt undersystem. Udviklere af specifikke applikationer arbejder med den del af informationen fra databasen, der kræves til en specifik applikation.

Ikke alle databanker kan vælge enhver type bruger. Det er kendt, at databankadministratoren, applikationsadministratoren og udvikleren ofte eksisterede i én person under udviklingen af informationssystemer ved hjælp af et tabelformet DBMS. Men når man opretter nutidens komplekse virksomhedsdatabaser, som bruges til at automatisere alle eller store dele af forretningsprocesser i en stor virksomhed eller virksomhed, kan der være grupper af applikationsadministratorer og udviklingsafdelinger. De sværeste driftstilstande er tildelt databaseadministratorgruppen.

Lad os se på dem mere detaljeret.

En del af BnD-administratorgruppen bør være:

Systemkommentatorer;

Udviklere af datastrukturer og udseende vedrørende informationsstøttedatabanken;

Udviklere af teknologiske databehandlingsprocesser;

System- og applikationsprogrammører;

Driftsselskaber og eksperter i reparationsservice.

Spørgsmålet om kommerciel databank spiller en vigtig rolle ved salg af eksperter.

Grundlæggende funktioner i databaseadministratorgruppen

1. Undersøgelse af dataområdet: beskrivelse af dataområdet, udformning af teksten til integritetsrestriktioner, fastlæggelse af tilstanden (tilgængelighed, fortrolighed) af oplysninger, bestemmelse af forbrugernes behov, bestemmelse af korrespondancen af "dataforbrugere", fastsættelse af tidsmæssige volumen af databehandlingskarakteristika.

2. Udvikling af databasestrukturen: definition af sammensætning og struktur af databasefiler og mellemforbindelser, valg af dataoptimeringsmetoder og adgangsmetoder til information, beskrivelse af databasen i et databeskrivelsessprog (DDL).

3. Indstilling af integritetsbegrænsninger i beskrivelsen af databasestrukturen og databasebehandlingsprocedurer:

Indstilling af deklarative integritetsbegrænsninger, der er specifikke for dataområdet;

Bestemmelse af dynamiske integritetsbegrænsninger, der er iboende i et dataområde under ændringer i information, der er lagret i databasen;

Definitionen af integritetsbegrænsninger er forårsaget af databasens struktur;

Udvikling af procedurer til vedligeholdelse af databaseintegritet ved indtastning og korrektion af data;

Bestemmelse af integritetsbegrænsninger for parallel drift af forbrugere i flerbrugertilstand.

4. Start af indlæsning og databasestyring

Udvikling af en teknik til at starte databaseindlæsning, som vil adskille sig fra proceduren for ændring og tilføjelse af data ved regelmæssig brug af databasen;

Udvikling af en teknik til at kontrollere de indtastede data i forhold til dataområdets reelle tilstand. Reelle objekter af databasemodeller for et bestemt dataområde og korrelationer er mellemliggende, og i det øjeblik den aktuelle vedligeholdelse begynder, skal denne model svare fuldstændigt til tilstanden af objekterne i dataområdet nu til tider;

Ifølge den udviklede indlæsningsinitieringsteknik kan det være nødvendigt at designe etm.

5. Databeskyttelse

Definering af et adgangskodesystem, principper for målretning mod forbrugere, oprettelse af grupper af forbrugere med identiske adgangsrettigheder til data;

Udvikling af principper til beskyttelse af visse data og udviklingsobjekter; udvikling af specialiserede metoder til kodning af information, som den cirkulerer i lokale og globale informationsnetværk;

Udvikling af midler til registrering af adgang til data og forsøg på at krænke sikkerhedssystemet;

Test af sikkerhedssystemer;

Undersøgelse af tilfælde af krænkelse af sikkerhedssystemet og udvikling af dynamiske metoder til beskyttelse af information i databasen.

6. Databasegendannelsesstøtte

Udvikling af principper for organisatorisk arkivering og databasegendannelse;

Udvikling af yderligere software og teknologiske processer til databasegendannelse efter fejl.

7. Undersøgelse af opkald til databaseforbrugere: et sæt statistikker om anmodningssymbolet, tændingstiden for deres ydeevne i overensstemmelse med de krævede outputdokumenter

8. Undersøgelse af effektiviteten af BnD'ens funktion:

Undersøgelse af BnD-funktionsindekser

Planlægning af omstrukturering af strukturen (strukturændring) af databasen og reorganisering af BnD.

9. Arbejde med slutbrugere:

Indsamling af information om ændringer i dataområdet;

Indsamling af oplysninger om vurdering af B&D-arbejde;

Forbrugeruddannelse; forbrugerhøring;

Udvikling af den nødvendige systematiske og pædagogiske dokumentation vedrørende slutbrugernes arbejde.

10. Forberedelse og support af systemværktøjer:

Undersøgelse af eksisterende software på markedet og undersøgelse af muligheden og nødvendigheden af deres anvendelse inden for rammerne af BnD;

Udvikling af de organisatoriske og tekniske bevægelser, der kræves af programmet til udvikling af BnD;

Kontrol af funktionaliteten af den købte software før tilslutning til BnD;

Overvågning af tilslutning af ny software til BnD.

11. Organisatorisk og systematisk arbejde i udviklingen af BnD:

Valg eller oprettelse af en databaseudviklingsmetode;

Definition af mål og retning for udvikling af systemet som helhed;

Planlægningsstadier af udvikling af BnD;

Udvikling af opslagsbøger til generelle ordbøger for BnD-projektet og en konceptuel model;

Installation af eksterne modeller af udviklede applikationer;

Overvågning af forbindelsen af en ny applikation til BnD's arbejde;

Evnen til omfattende fejlfinding af et sæt applikationer, der interagerer fra én database.

Den første formaliserede og generelt accepterede datamodel var Codd relationsmodel. I denne model, som i alt det følgende, blev der skelnet mellem tre aspekter - strukturelle, holistiske og manipulerende. Datastrukturer i relationsmodellen er baseret på flade normaliserede relationer, integritetsbegrænsninger udtrykkes ved hjælp af førsteordenslogik, og endelig udføres datamanipulation på basis af relationel algebra eller dens ækvivalente relationelregning. Som mange forskere bemærker, skyldes den relationelle datamodel i høj grad sin succes, at den var baseret på det strenge matematiske apparat af mængdeteori, relationer og førsteordenslogik. Udviklerne af et bestemt relationssystem anså det for deres pligt at demonstrere overensstemmelsen af deres specifikke datamodel med den generelle relationelle model, der fungerede som et mål for systemets "relationalitet".

De største vanskeligheder ved objektorienteret datamodellering stammer fra det faktum, at et sådant udviklet matematisk apparat, som en generel objektorienteret datamodel kunne baseres på, ikke eksisterer. Det er i høj grad grunden til, at der stadig ikke er nogen grundlæggende objektorienteret model. På den anden side hævder nogle forfattere, at en generel objektorienteret datamodel i klassisk forstand ikke kan defineres, fordi det klassiske koncept for en datamodel er uegnet til det objektorienterede paradigme.

En af de mest kendte teoretikere inden for datamodeller, Beeri, foreslår i generelle vendinger en formel ramme for OODB, som langt fra er komplet og ikke er en datamodel i traditionel forstand, men tillader forskere og udviklere af OODB-systemer at i det mindste taler det samme sprog (hvis, selvfølgelig, forslagene Bears vil blive udviklet og støttet). Uanset den videre skæbne for disse forslag, anser vi det for nyttigt kort at gengive dem.

For det første foreslås det, efter mange OODB'ers praksis, at skelne mellem to niveauer af objektmodellering: nedre (strukturel) og øvre (adfærdsmæssig). På det strukturelle niveau understøttes komplekse objekter, deres identifikation og typer af "isa"-relationer. En database er en samling af dataelementer relateret til forholdet "er medlem af en klasse" eller "er en attribut". Således kan databasen betragtes som en rettet graf. En vigtig pointe er at fastholde værdibegrebet sammen med begrebet et objekt (senere vil vi se, hvor meget der bygges på dette i en af de succesrige objektorienterede DBMS'er O2).

Et vigtigt aspekt er den klare adskillelse af databaseskemaet og selve databasen. De primære koncepter for OODB-kredsløbsniveauet er typer og klasser. Det bemærkes, at i alle systemer, der kun bruger ét koncept (enten en type eller en klasse), er dette koncept uundgåeligt overbelastet: en type antager tilstedeværelsen af et bestemt sæt værdier, bestemt af datastrukturen af denne type; en klasse antager også tilstedeværelsen af mange objekter, men dette sæt er defineret af brugeren. Typer og klasser spiller således forskellige roller, og stringens og entydighed kræver samtidig støtte til begge begreber.

Beeri præsenterer ikke en komplet formel model for det strukturelle niveau af OODB, men udtrykker tillid til, at det nuværende forståelsesniveau er tilstrækkeligt til at formalisere en sådan model. Hvad angår adfærdsniveauet, foreslås kun en generel tilgang til det logiske apparat, der kræves til dette (logikken på det første niveau er ikke nok).

Beeris vigtige, men ikke velbegrundede, antagelse er, at de to traditionelle niveauer - skema og data - ikke er nok for OODB. For nøjagtigt at definere en OODB kræves der et metaskemaniveau, hvis indhold skal definere de typer objekter og relationer, der er tilladt på databaseskemaniveauet. Metaskemaet bør spille den samme rolle for OODB, som den strukturelle del af relationsdatamodellen spiller for relationelle databaseskemaer.

Der er mange andre publikationer relateret til emnet objektorienterede datamodeller, men de berører enten ret specifikke problemstillinger eller bruger matematiske apparater, der er for seriøse til denne gennemgang (for eksempel definerer nogle forfattere en objektorienteret datamodel baseret på kategoriteori).

For at illustrere den aktuelle situation vil vi kort overveje funktionerne i en specifik datamodel, der anvendes i det objektorienterede O2 DBMS (dette er naturligvis heller ikke en datamodel i klassisk forstand).

O2 understøtter objekter og værdier. Et objekt er et par (identifikator, værdi), og objekterne er indkapslet, dvs. deres værdier er kun tilgængelige gennem metoder - procedurer bundet til objekter. Værdier kan være atomare eller strukturelle. Strukturelle værdier er konstrueret ud fra værdier eller objekter repræsenteret af deres identifikatorer ved hjælp af sæt-, tupel- og listekonstruktører. Strukturelle værdielementer tilgås ved hjælp af foruddefinerede operationer (primitiver).

Der er to mulige typer af dataorganisation: klasser, hvis forekomster er objekter, der indkapsler data og adfærd, og typer, hvis forekomster er værdier. Hver klasse er knyttet til en type, der beskriver strukturen af forekomster af klassen. Typer defineres rekursivt baseret på atomtyper og tidligere definerede typer og klasser ved hjælp af konstruktører. Den adfærdsmæssige side af en klasse bestemmes af et sæt metoder.

Objekter og værdier kan navngives. Navngivningen af et objekt eller en værdi er forbundet med holdbarheden af dets opbevaring (vedholdenhed): alle navngivne objekter eller værdier er holdbare; enhver genstand eller værdi, der er en del af et andet navngivet objekt eller værdi, er holdbart.

Ved at bruge en speciel instruktion specificeret, når du definerer en klasse, kan du opnå langtidslagring af ethvert objekt i denne klasse. I dette tilfælde genererer systemet automatisk en indstillet værdi, hvis navn stemmer overens med navnet på klassen. Dette sæt er garanteret at indeholde alle objekter i en given klasse.

En metode er en programkode, der er bundet til en specifik klasse og kan anvendes på objekter i denne klasse. At definere en metode i O2 sker i to trin. Først erklæres metodesignaturen, dvs. dens navn, klasse, argumenttyper eller klasser og resultattype eller klasse. Metoder kan være offentlige (tilgængelige fra objekter fra andre klasser) eller private (kun tilgængelige inden for en given klasse). På anden fase bestemmes implementeringen af klassen i et af O2-programmeringssprogene (sprogene diskuteres mere detaljeret i næste afsnit af vores anmeldelse).

O2-modellen understøtter multiple klasse-arv baseret på supertype/subtype-forholdet. En underklasse tillader tilføjelse og/eller tilsidesættelse af attributter og metoder. Mulige uklarheder i multipel arv (i navngivningen af attributter og metoder) løses enten ved at omdøbe eller ved eksplicit at angive arvekilden. Et underklasseobjekt er et objekt af hver superklasse, hvorfra underklassen er afledt.

En foruddefineret klasse "Objekt" er understøttet, som er roden af klassegitteret; enhver anden klasse er en implicit efterfølger af "Objekt"-klassen og arver foruddefinerede metoder ("er_samme", "er_værdi_lig" osv.).

Et specifikt træk ved O2-modellen er evnen til at erklære yderligere "eksklusive" attributter og metoder for navngivne objekter. Dette betyder, at et bestemt navngivet objekt, der er repræsentativt for en klasse, kan have en type, der er en undertype af klassetypen. Naturligvis fungerer standardklassemetoder ikke med sådanne attributter, men yderligere (eller standard) metoder, for hvilke yderligere attributter allerede er tilgængelige, kan defineres specifikt for et navngivet objekt. Det understreges, at yderligere attributter og metoder ikke er knyttet til et specifikt objekt, men til et navn, som generelt kan efterfølges af forskellige objekter på forskellige tidspunkter. Implementering af eksklusive attributter og metoder kræver udvikling af sene bindingsteknikker.

I næste afsnit vil vi blandt andet se på funktionerne i programmeringssprogene og forespørgslerne i O2-systemet, som selvfølgelig er tæt forbundet med datamodellens detaljer.

I en objektorienteret model (OOM) er det ved præsentation af data muligt at identificere individuelle databaseposter. Relationer etableres mellem databaseposter og deres behandlingsfunktioner ved hjælp af mekanismer svarende til de tilsvarende faciliteter i objektorienterede programmeringssprog.

Standard OOM er beskrevet i anbefalingerne fra ODMG-93 standarden (Object Database Management Group - objektorienteret databasestyringsgruppe). Det har endnu ikke været muligt fuldt ud at implementere anbefalingerne fra ODMG-93. For at illustrere de vigtigste ideer, overvej en noget forenklet model af en objektorienteret database.

Strukturen af en objektorienteret database kan være grafisk repræsenteret som et træ, hvis noder er objekter. Egenskaberne for objekter er beskrevet af en standardtype (f.eks. streng) eller en brugerkonstrueret type (defineret som klasse).

Værdien af en egenskab af typen streng er en streng af tegn. Værdien af en egenskab af typen klasse er et objekt, der er en instans af den tilsvarende klasse. Hvert instansobjekt i en klasse betragtes som et underordnet objekt af det objekt, hvor det er defineret som en egenskab. Et instansobjekt af en klasse tilhører dens klasse og har én forælder. Generiske relationer i databasen danner et forbundet hierarki af objekter.

Et eksempel på den logiske struktur af en bibliotekarisk OO-database er vist i fig. 3.14. Her er et objekt af typen LIBRARY overordnet for instansobjekter i klasserne SUBSCRIBER, DIRECTORY og ISSUE. Forskellige objekter af typen BOG, der har den samme forælder, skal mindst adskille sig i adgangsnummeret (unik for hver forekomst af bogen), men have de samme egenskabsværdier isbn, udk, titel Og forfatter.

Fig.3.14. Logisk struktur af en biblioteksvidenskabelig database

Den logiske struktur i en objektorienteret database ligner overfladisk strukturen af en hierarkisk database. Den største forskel mellem dem er metoderne til datamanipulation. For at udføre handlinger på data i en OOM-database bruges logiske operationer, forstærket af objektorienterede mekanismer for indkapsling, arv og polymorfi. Operationer, der ligner SQL-kommandoer, kan bruges i begrænset omfang (for eksempel til at oprette en database).

Oprettelse og ændring af en database er ledsaget af automatisk dannelse og efterfølgende justering af indekser (indekstabeller), der indeholder information til hurtig datahentning.

Lad os kort overveje begreberne indkapsling, arv og polymorfi i forhold til OOM-databaser.

Indkapsling begrænser omfanget af et egenskabsnavn til grænserne for det objekt, hvori det er defineret. Så hvis du tilføjer en egenskab til et objekt af typen DIRECTORY, der angiver telefonnummeret på forfatteren af bogen og har navnet telefon, så får vi egenskaber af samme navn for SUBSCRIBER- og DIRECTORY-objekterne. Betydningen af en sådan egenskab vil blive bestemt af det objekt, hvori den er indkapslet.

Arv, tværtimod udvider den ejendommens omfang til alle efterkommere af genstanden. Således kan alle objekter af typen BOG, der er efterkommere af et objekt af typen DIRECTORY, tildeles egenskaberne for det overordnede objekt: isbn, udk, titel Og forfatter. Hvis det er nødvendigt at udvide arvemekanismen til objekter, der ikke er umiddelbare slægtninge (for eksempel mellem to børn af samme forælder), er en abstrakt egenskab af typen abs defineret i deres fælles forfader. Således definitionen af abstrakte egenskaber billet Og nummer i LIBRARY-objektet får disse egenskaber til at blive nedarvet af alle underordnede objekter SUBSCRIBER, BOOK og ISSUE. Det er ikke tilfældigt, at ejendommen værdier billet klasserne SUBSCRIBER og ISSUING vist i figuren vil være de samme - 00015.

Polymorfi i objektorienterede programmeringssprog betyder den samme programkodes evne til at arbejde med forskellige typer data. Med andre ord betyder det, at det er tilladt for objekter af forskellige typer at have metoder (procedurer eller funktioner) med samme navne. Under udførelse af et objektprogram fungerer de samme metoder på forskellige objekter afhængigt af argumentets type. I forhold til vores objektorienterede database betyder polymorfi, at objekter i BOOK-klassen, der har forskellige forældre end DIRECTORY-klassen, kan have et andet sæt egenskaber. Derfor kan programmer til at arbejde med objekter i BOOK-klassen indeholde polymorf kode.

Søgning i en objektorienteret database består i at finde ud af lighederne mellem et objekt specificeret af brugeren og objekter gemt i databasen. Et brugerdefineret objekt, kaldet et målobjekt (objektets egenskab er af typen goal), kan generelt være en delmængde af hele hierarkiet af objekter gemt i databasen. Målobjektet, såvel som resultatet af forespørgslen, kan gemmes i selve databasen. Et eksempel på en anmodning om lånerkortnumre og navne på abonnenter, der har modtaget mindst én bog fra biblioteket, er vist i fig. 3.15.

Hoved værdighed OOM af data i sammenligning med relationelle er evnen til at vise information om komplekse relationer mellem objekter. OOM af data giver dig mulighed for at identificere en individuel databasepost og bestemme funktionerne til behandling af dem.

Ulempe OOM'er er karakteriseret ved høj konceptuel kompleksitet, besvær med databehandling og lav hastighed for udførelse af forespørgsler.

Fig.3.15. Databasefragment med målobjekt

Lad os igen vende tilbage til ordreopgaven, præsenteret i form af en relationel datamodel i fig. 3.8, og betragte det som en objektorienteret database. Der er tre klasser i eksemplet: " Kunder», « Ordre:% s"og" Gods" Klassens objekter " Kunder» er specifikke kunder; klasseejendomme - klientnummer, klientnavn By, Status mv. Klassemetoder - " Opret en ordre», « Betal regningen" og så videre. En metode er en operation, der kan anvendes på et objekt; en metode er, hvad et objekt skal gøre. Klasse svarende til tabel " Ordre detaljer", ikke påkrævet. Tabeldata kan være en del af klassen " Ordre:% s" Tilgængelighed i klassen" Kunder» metode « Opret en ordre"fører til interaktion med klasseobjekter" Ordre:% s"og" Gods" I dette tilfælde behøver brugeren ikke at vide om denne interaktion mellem objekter. Brugeren får kun adgang til objektet " Ordre:% s"og bruger metoden" Opret en ordre" Indvirkningen på andre databaser kan være skjult for brugeren. Hvis metoden " Opret en ordre"kalder til gengæld metoden" Tjek kundens kreditværdighed", så kan dette faktum også skjules for brugeren. Relationelle databaser kræver, at procedurer skrives i Visual Basic for Application (VBA) for at udføre de samme funktioner.

I 90'erne var der eksperimentelle prototyper af OO-databasestyringssystemer. I øjeblikket er sådanne systemer udbredt. Disse omfatter især følgende DBMS: POET (POET Software), Jasmine (Computer Associates), Versant (Versant Technologies), O2 (Ardent Software), ODB-Jupiter (Inteltek Plus Research and Production Center), samt Iris , Orion og Postgres.

Introduktion

Fremkomsten af retningen af objektorienterede databaser (OODB) blev først og fremmest bestemt af behovene i praksis: behovet for at udvikle komplekse, for hvilke teknologien i tidligere databasesystemer ikke var helt tilfredsstillende. Selvfølgelig opstod OODB ikke ud af ingenting. Det tilsvarende grundlag blev leveret både af tidligere arbejde inden for databaser og af de længe udviklende områder af programmeringssprog med abstrakte datatyper og objektorienterede programmeringssprog.

Hvad angår forbindelsen med tidligere arbejde inden for databaser, blev den stærkeste indflydelse på arbejdet inden for OODB udøvet af udviklingen af DBMS og den kronologisk efterfølgende familie af databaser, som understøttede håndteringen af komplekse objekter. Disse arbejder udgjorde det strukturelle grundlag for organisationen af OODB. Dette abstrakt vil diskutere OOMD og OODBMS.

Objektorienteret datamodel

Lad os overveje en af tilgangene til at bygge en database - ved hjælp af en objektorienteret datamodel (OOMD). Datamodellering i OOMD er baseret på konceptet om et objekt. OOMD bruges normalt inden for komplekse fagområder, hvor funktionaliteten af den relationelle model ikke er nok til modellering (f.eks. til designautomationssystemer (CAD), publiceringssystemer osv.).

Den objektorienterede datamodel ODMG adskiller sig fra andre modeller primært i ét grundlæggende aspekt. I SQL-datamodellen og den ægte relationelle datamodel er en database en samling af navngivne databeholdere af samme generiske type: henholdsvis tabeller eller relationer. I en objektorienteret datamodel er en database et sæt objekter (databeholdere) af en vilkårlig type.

Ved oprettelse af objektorienteret DBMS (OODBMS) bruges forskellige metoder, nemlig:

indlejringsværktøjer designet til at arbejde med databaser i et objektorienteret sprog;

udvidelse af det eksisterende sprog til at arbejde med databaser med objektorienterede funktioner;

oprettelse af objektorienterede biblioteker af funktioner til arbejde med databaser;

skabelse af et nyt sprog og en ny objektorienteret datamodel.

Fordelene ved OOMD inkluderer brede domænemodelleringsmuligheder, et udtryksfuldt forespørgselssprog og høj ydeevne. Hvert objekt i OOMD'en har en unik identifikator (OID - object identifier). Adgang via OID er meget hurtigere end at søge i en relationstabel.

Blandt ulemperne ved OODB skal det bemærkes manglen på en generelt accepteret model, manglende erfaring med at skabe og drive OODB, kompleksiteten i brugen og utilstrækkelige databeskyttelsesværktøjer.

Lad os nu se på, hvordan datamodelunderstøttelse implementeres i rigtige databasestyringssystemer.

Objektorienteret model

I en objektorienteret model er det ved præsentation af data muligt at identificere individuelle databaseposter. Relationer etableres mellem databaseposter og deres behandlingsfunktioner ved hjælp af mekanismer svarende til de tilsvarende faciliteter i objektorienterede programmeringssprog.

Den standardiserede objektorienterede model er beskrevet i anbefalingerne fra ODMG-93 (Object Database Management Group) standarden. Det har endnu ikke været muligt fuldt ud at implementere anbefalingerne fra ODMG-93. For at illustrere de vigtigste ideer, overvej en lidt forenklet model af en objektorienteret database.

Strukturen af en objektorienteret database (for eksempel Versant Object Database, Object Store osv.) er grafisk repræsenteret som et træ, hvis noder er objekter. Egenskaberne for objekter er beskrevet af en standardtype (f.eks. streng) eller en brugerkonstrueret type (defineret som klasse).

Værdien af en egenskab af typen streng er en streng af tegn. Værdien af en egenskab af typen klasse er et objekt, der er en instans af den tilsvarende klasse. Hvert objekt - en forekomst af en klasse betragtes som en efterkommer af det objekt, hvori det er defineret som en egenskab. Et objekt er en forekomst af en klasse, der tilhører dens klasse og har én forælder. Generiske relationer i databasen danner et sammenhængende hierarki af objekter.

Den logiske struktur i en objektorienteret database ligner overfladisk strukturen af en hierarkisk database. Den største forskel mellem dem er metoderne til datamanipulation.

For at udføre handlinger på data i den pågældende databasemodel, bruges logiske operationer, forstærket af objektorienterede mekanismer for indkapsling, arv og polymorfi.

Operationer, der ligner SQL-kommandoer, kan bruges i begrænset omfang (for eksempel til at oprette en database).

Oprettelse og ændring af en database er ledsaget af automatisk dannelse og efterfølgende justering af indekser (indekstabeller), der indeholder information til hurtig datahentning.

Lad os kort overveje begreberne indkapsling, arv og polymorfi i forhold til den objektorienterede databasemodel.

Indkapsling begrænser omfanget af et egenskabsnavn til grænserne for det objekt, hvori det er defineret.

Arv udvider tværtimod omfanget af en ejendom til alle efterkommere af objektet.

Polymorfi i objektorienterede programmeringssprog betyder den samme programkodes evne til at arbejde med forskellige typer data. Med andre ord betyder det, at det er tilladt for objekter af forskellige typer at have metoder (procedurer eller funktioner) med samme navne. Under udførelse af et objektprogram fungerer de samme metoder på forskellige objekter afhængigt af argumentets type. At søge i en objektorienteret database involverer at finde ligheder mellem et objekt specificeret af brugeren og objekter gemt i databasen. Et brugerdefineret objekt, kaldet et målobjekt (objektets egenskab er af typen goal), kan generelt være en delmængde af hele hierarkiet af objekter gemt i databasen. Målobjektet, såvel som resultatet af forespørgslen, kan gemmes i selve databasen.

Ulemperne ved den objektorienterede model er høj konceptuel kompleksitet, ubekvem databehandling og lav forespørgselshastighed.

Datatyper

Oprindeligt blev DBMS'er primært brugt til at løse finansielle og økonomiske problemer. I dette tilfælde, uanset præsentationsmodellen, blev følgende hoveddatatyper brugt i databaser:

numerisk. Eksempler på dataværdier: 0,43; 328; 2E+5;
symbolsk (alfanumerisk). Eksempler på dataværdier: "fredag", "streng", "programmør";
datoer, angivet ved hjælp af den specielle datotype eller som almindelige tegndata. Eksempler på dataværdier: 12/1/97, 23/2/1999.

I forskellige DBMS'er kan disse typer afvige lidt fra hinanden i navn, værdiområde og repræsentationstype. Efterfølgende begyndte specialiserede databehandlingssystemer at dukke op inden for nye anvendelsesområder, såsom geoinformationssystemer, videobilledbehandling mv. I denne forbindelse begyndte udviklere at introducere nye datatyper i traditionelle DBMS'er. Relativt nye datatyper omfatter følgende:

midlertidig og dato-temporal, designet til at gemme information om tid og (eller) dato. Eksempler på dataværdier: 01/31/85 (dato), 9:10:03 (tid), 03/6/1960 12:00 (dato og tid);
tegn med variabel længde, der er designet til at gemme lang tekstinformation, såsom et dokument;
binær, designet til lagring af grafiske objekter, lyd- og videoinformation, rumlig, kronologisk og anden speciel information. I MS Access er denne type f.eks. datatypen "OLE Object Field", som giver dig mulighed for at gemme grafiske data i BMP-formatet (Bitmap) i databasen og automatisk vise dem, når du arbejder med databasen;
hyperlinks designet til at gemme links til forskellige ressourcer (knudepunkter, filer, dokumenter osv.), der er placeret uden for databasen, for eksempel på internettet, et virksomheds intranet eller på en computers harddisk.

I moderne DBMS'er med forskellige datamodeller kan alle de anførte datatyper bruges.