Hoewel er veel experimentele projecten zijn (en zelfs commerciële systemen), bestaat er geen algemeen aanvaard objectgeoriënteerd datamodel, niet omdat er geen compleet model is ontwikkeld, maar omdat er geen algemene overeenstemming bestaat over de adoptie van welk model dan ook. In feite zijn er meer specifieke problemen verbonden aan het ontwikkelen van declaratieve zoektalen, het uitvoeren en optimaliseren van vragen, het formuleren en onderhouden van integriteitsbeperkingen, het synchroniseren van toegang en het beheren van transacties, enzovoort.

Met het objectgeoriënteerde model (Fig. 3) kunt u informatie in de vorm van objecten creëren, opslaan en gebruiken. Wanneer een object wordt gemaakt, ontvangt het een unieke identificatie die door het systeem wordt gegenereerd en die gedurende zijn hele bestaan ​​aan het object is gekoppeld en niet verandert wanneer de status van het object verandert.

Afb.3. Objectgeoriënteerd datamodel

Elk object heeft een toestand en gedrag. De toestand van een object is een reeks waarden van zijn attributen. Het gedrag van een object is een reeks methoden (programmacode) die inwerken op de toestand van het object. De waarde van een objectattribuut is ook een object of een reeks objecten. De toestand en het gedrag van een object zijn ingekapseld in het object; De interactie van objecten wordt uitgevoerd op basis van het doorgeven van berichten en de uitvoering van overeenkomstige methoden.

Een set objecten met dezelfde set attributen en methoden vormt een objectklasse. Een object mag slechts tot één klasse behoren (waarbij de mogelijkheid van overerving wordt genegeerd). De aanwezigheid van primitieve, vooraf gedefinieerde klassen is toegestaan, waarvan de instance-objecten geen attributen hebben: gehele getallen, strings, enz. Een klasse waarvan de objecten kunnen dienen als waarden voor een attribuut van objecten van een andere klasse heet het domein van dat attribuut.

Het is mogelijk om een ​​nieuwe klasse te genereren op basis van een bestaande klasse: overerving. In dit geval erft de nieuwe klasse, een subklasse van de bestaande klasse (superklasse) genoemd, alle attributen en methoden van de superklasse. Bovendien kunnen aanvullende attributen en methoden in een subklasse worden gedefinieerd. Er zijn gevallen van eenvoudige en meervoudige overerving. In het eerste geval kan een subklasse worden gedefinieerd op basis van slechts één superklasse; in het tweede geval kunnen er meerdere superklassen zijn. Als een taal of systeem overerving van één klasse ondersteunt, vormt de reeks klassen een boomhiërarchie. Bij het ondersteunen van meervoudige overerving worden klassen met elkaar verbonden in een gerichte, gewortelde grafiek, een klassenrooster genoemd. Een object van een subklasse wordt geacht tot elke superklasse van die klasse te behoren.

Objectgeoriënteerde databases worden het meest gebruikt op gebieden als computerondersteund ontwerp/productie (CAD/CAM), computerondersteunde software-engineering (CASE), samengestelde documentbeheersystemen, d.w.z. op gebieden die niet traditioneel zijn voor databases. Voorbeelden van objectgeoriënteerde DBMS's zijn POET, Jasmine, Versant, Iris, Orion.

2.2.4.Relationeel datamodel

In 1970 stelde de Amerikaanse wiskundige Codd E.F. publiceerde een artikel dat revolutionair was qua inhoud, waarin het gebruik van de verzamelingenleer voor gegevensverwerking werd voorgesteld. Hij voerde aan dat gegevens moeten worden gekoppeld op basis van hun logische relaties (bijvoorbeeld unie, kruispunt) in plaats van fysieke verwijzingen. Hij stelde een eenvoudig datamodel voor waarin alle gegevens worden samengevat in tabellen bestaande uit rijen en kolommen met unieke namen. Deze tabellen worden relaties (relatie - relatie) genoemd, en het model is een relationeel gegevensmodel gebouwd op het concept van wiskundige relaties en wordt soms ook het Codd-model genoemd. De voorstellen van Codd waren zo effectief voor databasesystemen dat hij voor zijn model de prestigieuze Turing Award for Theoretical Foundations of Computing ontving.

In relationele databases worden alle gegevens opgeslagen in eenvoudige tabellen, verdeeld in rijen (ze worden records genoemd) en kolommen (ze worden velden genoemd), op het kruispunt waarvan informatie over de gegevens zich bevindt. In grote lijnen kan dit worden weergegeven zoals in figuur 2. 4.

Afb.4. Relationele databasetabel.

Elke kolom heeft zijn eigen naam. In de tabel “Artikelen in magazijn” (Fig. 5) zijn de veldnamen bijvoorbeeld als volgt: Identificatie, Product, Groepsnaam, Groep, Meeteenheid, Aankoopprijs, Verkoopprijs, Beschikbaarheid op voorraad.

Rijst. 5. Tabel “Product in magazijn” »

Alle waarden in dezelfde kolom zijn van hetzelfde type. Velden zijn dus verschillende kenmerken (ook wel attributen genoemd) van een object. Veldwaarden op dezelfde regel verwijzen naar hetzelfde object en verschillende velden hebben verschillende namen.

Elke record onderscheidt zich door een unieke recordsleutel, die in twee typen bestaat: primair en secundair.

Primaire sleutel– Dit zijn een of meer velden die een record uniek identificeren. Als de primaire sleutel uit één veld bestaat, wordt deze een eenvoudige sleutel genoemd; deze bestaat uit meerdere velden en wordt een samengestelde sleutel genoemd.

Secundaire sleutel– dit is een veld waarvan de waarde kan worden herhaald in verschillende records van het bestand, dat wil zeggen dat het niet uniek is.

Buitenlandse sleutel De subtabel is de secundaire sleutel van deze relatie, die tegelijkertijd als primaire sleutel in de hoofdtabel dient. Als één enkel exemplaar van een record kan worden gevonden op basis van de waarde van de primaire sleutel, dan kunnen er meerdere worden gevonden op basis van de waarde van de externe sleutel (Fig. 6).

Afb.6. Voorbeeld van het gebruik van een externe sleutel

In de regel bestaat een relationele database uit meerdere tabellen, omdat Het is niet mogelijk om in één tabel alle informatie te combineren die medewerkers (databasegebruikers) van welke organisatie dan ook nodig hebben om problemen op te lossen.

Een manier om effectief toegang te krijgen tot een bestandsrecord met behulp van een sleutel is indexering. Door te indexeren wordt een extra bestand gemaakt dat, in geordende vorm, alle sleutelwaarden van het gegevensbestand bevat. Voor elke sleutel bevat het indexbestand een verwijzing naar de overeenkomstige gegevensbestandsinvoer. Met behulp van een verwijzing naar een record in een gegevensbestand wordt dat record rechtstreeks benaderd.

Structured Query Language (SQL) wordt momenteel vaak gebruikt om met relationele databases te werken. Het is een taal die wordt gebruikt om gegevens te creëren, wijzigen en manipuleren. SQL is geen algoritmische programmeertaal. Dit is een informatielogische taal, gebaseerd op relationele algebra en verdeeld in drie delen:

· datadefinitieoperatoren;

· operatoren voor gegevensmanipulatie (Invoegen, Selecteren, Bijwerken, Verwijderen);

· operatoren voor definitie van gegevenstoegang.

In 1986 werd SQL aangenomen als de ANSI-standaard (American National Standards Institute) voor relationele databasetalen. Tegenwoordig wordt deze basis beschouwd als een standaard voor moderne informatiesystemen.

De tabel is dus het belangrijkste type gegevensstructuur van het relationele model. De tabelstructuur wordt bepaald door een reeks kolommen. Elke rij van de tabel bevat één waarde in de overeenkomstige kolom. Er kunnen geen twee identieke rijen in een tabel voorkomen; het totale aantal rijen is niet beperkt. Een kolom is een gegevenselement, elke kolom heeft een naam. Een of meer attributen waarvan de waarden op unieke wijze een tabelrij identificeren, zijn de tabelsleutel.

De voordelen van het relationele model zijn:

Eenvoud en begrijpelijkheid voor de eindgebruiker - de enige informatiestructuur is een tabel;

Bij het ontwerpen van een relationele database worden strikte regels toegepast, gebaseerd op wiskundige apparatuur;

Volledige data-onafhankelijkheid. Bij het veranderen van de structuur zijn de wijzigingen die in applicatieprogramma's moeten worden aangebracht minimaal;

Om query's te bouwen en applicatieprogramma's te schrijven, is het niet nodig om de specifieke organisatie van de database in het externe geheugen te kennen.

De nadelen van het relationele model zijn:

Relatief lage toegangssnelheid en grote hoeveelheid extern geheugen;

Moeilijkheid bij het begrijpen van de datastructuur vanwege het verschijnen van een groot aantal tabellen als resultaat van logisch ontwerp;

Het is niet altijd mogelijk om een ​​vakgebied in de vorm van een tabellenset te presenteren.

Relationele databases zijn momenteel het meest verspreid. Netwerk- en hiërarchische modellen worden als verouderd beschouwd; objectgeoriënteerde modellen zijn nog niet gestandaardiseerd en worden niet algemeen gebruikt.

Objectgeoriënteerd model

In een objectgeoriënteerd model is het bij het presenteren van gegevens mogelijk om individuele databaserecords te identificeren. Relaties worden tot stand gebracht tussen databaserecords en hun verwerkingsfuncties met behulp van mechanismen die vergelijkbaar zijn met de overeenkomstige faciliteiten in objectgeoriënteerde programmeertalen.

Het gestandaardiseerde objectgeoriënteerde model wordt beschreven in de aanbevelingen van de ODMG-93-standaard (Object Database Management Group). Het is nog niet mogelijk geweest de aanbevelingen van ODMG-93 volledig uit te voeren. Om de belangrijkste ideeën te illustreren, kunnen we een enigszins vereenvoudigd model van een objectgeoriënteerde database overwegen.

De structuur van een objectgeoriënteerde database (bijvoorbeeld Versant Object Database, Object Store, enz.) wordt grafisch weergegeven als een boom, waarvan de knooppunten objecten zijn. De eigenschappen van objecten worden beschreven door een standaardtype (bijvoorbeeld string) of een door de gebruiker geconstrueerd type (gedefinieerd als klasse).

De waarde van een eigenschap van het type string is een reeks tekens. De waarde van een eigenschap van type class is een object dat een instantie is van de overeenkomstige klasse. Elk object - een instantie van een klasse wordt beschouwd als een afstammeling van het object waarin het als eigenschap is gedefinieerd. Een object is een instantie van een klasse die tot zijn klasse behoort en één ouder heeft. Generieke relaties in de database vormen een samenhangende hiërarchie van objecten.

De logische structuur van een objectgeoriënteerde database komt oppervlakkig overeen met de structuur van een hiërarchische database. Het belangrijkste verschil tussen beide zijn de methoden voor gegevensmanipulatie.

Om acties uit te voeren op gegevens in het databasemodel in kwestie, worden logische bewerkingen gebruikt, versterkt door objectgeoriënteerde mechanismen van inkapseling, overerving en polymorfisme.

Bewerkingen die vergelijkbaar zijn met SQL-opdrachten kunnen in beperkte mate worden gebruikt (bijvoorbeeld om een ​​database aan te maken).

Het aanmaken en wijzigen van een database gaat gepaard met de automatische vorming en daaropvolgende aanpassing van indexen (indextabellen) die informatie bevatten voor het snel ophalen van gegevens.

Laten we kort de concepten van inkapseling, overerving en polymorfisme bekijken in relatie tot het objectgeoriënteerde databasemodel.

Inkapseling beperkt het bereik van een eigenschapsnaam tot de grenzen van het object waarin deze is gedefinieerd.

Overerving daarentegen breidt de reikwijdte van een eigendom uit tot alle nakomelingen van het object.

Polymorfisme in objectgeoriënteerde programmeertalen betekent het vermogen van dezelfde programmacode om met verschillende soorten gegevens te werken. Met andere woorden: het betekent dat het toegestaan ​​is dat objecten van verschillende typen methoden (procedures of functies) met dezelfde naam hebben. Tijdens de uitvoering van een objectprogramma werken dezelfde methoden op verschillende objecten, afhankelijk van het type argument. Zoeken in een objectgeoriënteerde database houdt in dat er overeenkomsten worden gevonden tussen een door de gebruiker opgegeven object en objecten die in de database zijn opgeslagen. Een door de gebruiker gedefinieerd object, een zogenaamde goal-object (de eigenschap van het object is van het type goal), kan doorgaans een subset zijn van de gehele hiërarchie van objecten die in de database zijn opgeslagen. Het doelobject en het resultaat van de zoekopdracht kunnen in de database zelf worden opgeslagen.

Het belangrijkste voordeel van een objectgeoriënteerd datamodel in vergelijking met een relationeel datamodel is de mogelijkheid om informatie weer te geven over complexe relaties tussen objecten. Met een objectgeoriënteerd datamodel kunt u individuele databaserecords identificeren en functies definiëren voor de verwerking ervan.

De nadelen van het objectgeoriënteerde model zijn een hoge conceptuele complexiteit, ongemakkelijke gegevensverwerking en een lage querysnelheid.

Gegevenstypen

Aanvankelijk werden DBMS'en voornamelijk gebruikt om financiële en economische problemen op te lossen. In dit geval werden, ongeacht het presentatiemodel, de volgende hoofdgegevenstypen in databases gebruikt:

• numeriek. Voorbeelden van gegevenswaarden: 0,43; 328; 2E+5;
• symbolisch (alfanumeriek). Voorbeelden van gegevenswaarden: "Vrijdag", "string", "programmeur";
• datums, gespecificeerd met een speciaal datumtype of als gewone tekengegevens. Voorbeelden van gegevenswaarden: 1/12/97, 23/2/1999.

In verschillende DBMS'en kunnen deze typen enigszins van elkaar verschillen wat betreft naam, waardenbereik en type representatie. Vervolgens begonnen gespecialiseerde gegevensverwerkingssystemen te verschijnen in nieuwe toepassingsgebieden, zoals geo-informatiesystemen, videobeeldverwerking, enz. In dit opzicht begonnen ontwikkelaars nieuwe gegevenstypen te introduceren in traditionele DBMS'en. Relatief nieuwe gegevenstypen zijn onder meer:

• tijdelijk en datum-temporeel, ontworpen om informatie over tijd en (of) datum op te slaan. Voorbeelden van gegevenswaarden: 31-01-85 (datum), 9:10:03 (tijd), 6-03-1960 12:00 (datum en tijd);
• tekens met variabele lengte die zijn ontworpen om lange tekstinformatie op te slaan, zoals een document;
• binair, ontworpen voor het opslaan van grafische objecten, audio- en video-informatie, ruimtelijke, chronologische en andere speciale informatie. In MS Access is dit type bijvoorbeeld het gegevenstype “OLE Object Field”, waarmee u grafische gegevens in het BMP-formaat (Bitmap) in de database kunt opslaan en deze automatisch kunt weergeven wanneer u met de database werkt;
• hyperlinks die zijn ontworpen om koppelingen op te slaan naar verschillende bronnen (knooppunten, bestanden, documenten, enz.) die zich buiten de database bevinden, bijvoorbeeld op internet, een bedrijfsintranet of op de harde schijf van een computer.

In moderne DBMS'en met verschillende datamodellen kunnen alle genoemde datatypen worden gebruikt.

Databasetechnologieën gebaseerd op de hierboven beschreven MD zijn gebaseerd op een statisch concept van informatieopslag, gericht op datamodellering. Er zijn echter nieuwe toepassingsgebieden van de technologie met complexe, onderling verbonden databaseobjecten, zoals:

Computerondersteund ontwerp;

Geautomatiseerde productie;

Geautomatiseerde softwareontwikkeling;

Kantoorinformatiesystemen;

Multimediasystemen;

Geografische informatiesystemen;

Uitgeverssystemen en anderen hebben de beperkte mogelijkheden van het statische concept aangetoond in termen van het modelleren van objecten uit de echte wereld.

Voor nieuwe soorten complexe gespecialiseerde databasetoepassingen is een dynamisch concept van informatieopslag effectief, waardoor parallelle modellering van gegevens en de processen die op deze gegevens inwerken mogelijk wordt. Hierdoor kun je rekening houden met de semantiek van het vakgebied en daardoor deze toepassingen het meest adequaat beschrijven. Dit concept is gebaseerd op de objectgeoriënteerde benadering, die veel wordt gebruikt bij het maken van software. MD, dat dit concept implementeert en gebaseerd is op het objectgeoriënteerde paradigma (OOP), wordt het objectgeoriënteerde datamodel (OODM) genoemd.

De constructie van OOMD is gebaseerd op de veronderstelling dat het onderwerpgebied kan worden beschreven door een reeks objecten. Elk object is een uniek identificeerbare entiteit die attributen bevat die de toestand van objecten in de "echte wereld" en de daarmee samenhangende acties beschrijven. De huidige status van een object wordt beschreven door een of meer attributen, die eenvoudig of complex kunnen zijn. Een eenvoudig attribuut kan van een primitief type zijn (bijvoorbeeld geheel getal, string, enz.) en een letterlijke waarde aannemen. Een samengesteld attribuut kan verzamelingen en/of referenties bevatten. Een referentieattribuut vertegenwoordigt een relatie tussen objecten.

De belangrijkste eigenschap van een object is de uniciteit van zijn identificatie. Daarom moet elk object in een objectgeoriënteerd systeem zijn eigen identificatie hebben.

Een Object Identifier (OID) is een database-interne manier om individuele objecten te taggen. Gebruikers die met een dialooggebaseerde query of informatieviewer werken, zien deze ID's doorgaans niet. Ze worden toegewezen en gebruikt door het DBMS zelf. De semantiek van de identifier is in elk DBMS anders. Het kan een willekeurige waarde zijn of informatie bevatten die nodig is om een ​​object in een databasebestand te vinden, bijvoorbeeld het paginanummer in het bestand en de afstand van het object vanaf het begin. Het is de identificatie die moet worden gebruikt om verwijzingen naar het object te organiseren.

Alle objecten zijn ingekapseld, wat betekent dat de weergave of interne structuur van het object voor de gebruiker verborgen blijft. In plaats daarvan weet de gebruiker alleen dat het object bepaalde functies kan uitvoeren. Voor een WAREHOUSE-object kunnen dus methoden als RECEIVE_GOOD, ISSUE_TOBAP, etc. worden gebruikt. Het voordeel van inkapseling is dat u hiermee de interne representatie van objecten kunt wijzigen zonder de toepassingen waarin deze objecten worden gebruikt te herwerken. Met andere woorden: inkapseling impliceert gegevensonafhankelijkheid.

Een object kapselt gegevens en functies in (methoden, volgens OOP). Methoden definiëren het gedrag van een object. Ze kunnen worden gebruikt om de status van een object te wijzigen door de attribuutwaarden ervan te wijzigen of om de waarden van geselecteerde attributen op te vragen. Er kunnen bijvoorbeeld methoden zijn om informatie toe te voegen over een nieuwe huurwoning, om de salarisinformatie van een werknemer bij te werken of om informatie over een specifiek product af te drukken.

Objecten die dezelfde set attributen hebben en op dezelfde berichten reageren, kunnen worden gegroepeerd Klas(in de literatuur worden de termen ‘klasse’ en ‘type’ vaak door elkaar gebruikt). Elke klasse heeft zijn eigen vertegenwoordiger: een object, dat een data-element is. Objecten van een bepaalde klasse worden het genoemd kopieën.

In sommige objectgeoriënteerde systemen is een klasse ook een object en heeft deze zijn eigen attributen en methoden klasseattributen en klassemethoden.

Belangrijke concepten van OOP zijn klassenhiërarchie en containerhiërarchie.

Klassenhiërarchie impliceert de mogelijkheid dat elke klasse, in dit geval een superklasse genoemd, zijn eigen subklasse heeft. Als voorbeeld kunnen we de volgende keten geven: alle programmeurs van elke onderneming zijn werknemers, daarom is elke programmeur die, binnen het raamwerk van OOMD, een object is van de klasse PROGRAMMERS, ook een werknemer, die op zijn beurt is een object van de klasse EMPLOYEES. PROGRAMMERS zullen dus een subklasse zijn, en WERKNEMERS zullen een superklasse zijn. Maar programmeurs zijn ook onder te verdelen in systeem- en applicatieprogrammeurs. Daarom zal PROGRAMMERS een superklasse zijn voor de subklassen SIS_PROGRAMMERS en APPLICATION_PROGRAMERS. Als we deze keten verder voortzetten, krijgen we een klassenhiërarchie waarin elk object van een subklasse instanties van variabelen en methoden van de overeenkomstige superklasse erft.

Er zijn verschillende soorten overerving: enkelvoudig, meervoudig en selectief. Enkelvoudige overerving is een geval waarin subklassen erven van maximaal één superklasse. Meervoudige overerving is overerving van meer dan één superklasse. Door selectieve overerving kan een subklasse een beperkt aantal eigenschappen van zijn superklasse erven.

Overerving van variabele instanties wordt genoemd structurele erfenis, methode overerving - gedragsmatige overerving en de mogelijkheid om dezelfde methode voor verschillende klassen te gebruiken, of beter gezegd om verschillende methoden met dezelfde naam voor verschillende klassen te gebruiken, wordt genoemd polymorfisme.

Objectgeoriënteerde architectuur kent ook een ander type hiërarchie: containerhiërarchie. Het is zo dat sommige objecten conceptueel in andere kunnen worden vervat. Een object van de klasse DEPARTMENT moet dus de publieke variabele HEAD bevatten, wat een link is naar het klasseobject EMPLOYEES dat overeenkomt met het hoofd van de afdeling, en moet ook een link bevatten naar een reeks links naar objecten die corresponderen met de werknemers die aan het werk zijn. op deze afdeling.

In sommige objectgeoriënteerde systemen is een klasse ook een object en heeft deze zijn eigen attributen en methoden. De algemene kenmerken van een klasse worden beschreven door de attributen ervan. Objectklassemethoden zijn een soort analogie van de eigenschappen van objecten uit de echte wereld. Elk object dat tot een bepaalde klasse behoort, heeft deze eigenschappen. Daarom is het bij het maken van een object noodzakelijk om de klasse waartoe het behoort te declareren, om daarmee de inherente eigenschappen ervan te definiëren.

De gebruiker en het object communiceren via berichten. Als reactie op elk bericht voert het systeem de overeenkomstige methode uit.

Alle relaties in het objectmodel worden gemaakt met behulp van referentieattributen, die doorgaans als OID's worden geïmplementeerd.

Relaties in een relationele database worden weergegeven door een vergelijking van primaire en externe sleutels. In de database zelf zijn er geen structuren voor het vormen van associaties tussen tabellen; verbindingen worden indien nodig gebruikt bij het verbinden van tabellen. Relaties vormen daarentegen de basis van een objectgeoriënteerde database, omdat elk object de identificatiegegevens bevat van de objecten waarmee het is geassocieerd.

In OOMD kunnen niet alleen traditionele verbindingen worden geïmplementeerd, maar ook verbindingen door overerving.

Eén-op-één communicatie (1:1) tussen objecten A en B wordt geïmplementeerd door een referentieattribuut toe te voegen aan object B aan object A en (om de referentiële integriteit te behouden) een referentieattribuut aan object A aan object B.

Een-op-veel-relatie (1:M). tussen objecten A en B wordt geïmplementeerd door aan object A een referentieattribuut naar object B toe te voegen en een attribuut met een reeks verwijzingen naar object A naar object B (er wordt bijvoorbeeld een referentieattribuut B(OID2, OID3...) toegevoegd aan object A, en aan instances van object B met OID2, OID3,... wordt het referentieattribuut A toegevoegd: OID1.

Veel-op-veel-relatie (M:N). tussen objecten A en B wordt geïmplementeerd door aan elk object een attribuut toe te voegen dat een reeks links bevat.

In OOMD kunt u een “geheel-deel”-relatie gebruiken, die beschrijft dat een object van één klasse objecten van andere klassen als onderdelen bevat. In het geval van een productiedatabase zou er een geheel-deelrelatie bestaan ​​tussen de PRODUCT-klasse en de PART- en ASSEMBLY-klassen. Deze relatie is een variant van de veel-op-veel-relatie, die een speciale semantiek heeft. Een geheel-deelrelatie wordt geïmplementeerd zoals elke andere veel-op-veel-relatie, met behulp van een reeks gerelateerde object-ID's. In tegenstelling tot de gebruikelijke veel-op-veel-relatie heeft het echter een andere semantische betekenis.

Omdat het objectgeoriënteerde paradigma overerving ondersteunt, kan OOMD relaties van het type “is” en relaties van het type “extends” gebruiken. De ‘is’-relatie, ook wel de generalisatie-specialisatierelatie genoemd, leidt tot een overervingshiërarchie waarin subklassen speciale gevallen van superklassen zijn. Dit maakt het mogelijk om hererfde kenmerken niet te beschrijven. Wanneer de relatie "uitbreiden" wordt gebruikt, breidt de subklasse de functionaliteit van de superklasse uit in plaats van beperkt te zijn tot een speciaal geval ervan.

Laten we eens kijken hoe componenten zoals integriteitsbeperkingen en gegevensbewerkingen worden geïmplementeerd in OOMD.

De kenmerken van deze componenten worden bepaald door de specifieke kenmerken van het model. Deze specificiteit in OOMD wordt voornamelijk bepaald door interne concepten als het inkapselen van objecten, dat wil zeggen een verborgen interne structuur, toegang tot gegevens alleen via vooraf bepaalde methoden, klassenhiërarchie en containerhiërarchie.

De specifieke kenmerken van de OOMD worden bepaald door de specifieke kenmerken van het object. Het manifesteert zich in de noodzaak om objecten in klassen te groeperen. Elk object is opgenomen in een of andere klasse, afhankelijk van de taak, en een object kan tot meerdere klassen tegelijk behoren (bijvoorbeeld de families PROGRAMMERS en HIGHLY PAID). Een ander specifiek kenmerk van een object is dat het van de ene klasse (subklasse) naar de andere kan “verhuizen”. Zo kan een SYSTEMS PROGRAMMER in de loop van de tijd een APPLICATION PROGRAMMER worden. Een klassenhiërarchie is dus niet analoog aan een hiërarchisch model, zoals het voorheen misschien leek, maar vereist dat het systeem de locatie van elk object binnen de klassenhiërarchie kan wijzigen, bijvoorbeeld “omhoog” of “omlaag” binnen de klassenhiërarchie. een bepaalde hiërarchie. Maar een complexer proces is ook mogelijk: het systeem moet de mogelijkheid bieden dat een object op elk moment aan een willekeurige top van de hiërarchie kan worden gekoppeld (losgemaakt).

Beperkingen op de integriteit van verbindingen spelen een belangrijke rol bij OOMD. Om koppelingen in een objectgeoriënteerde MD te laten werken, moeten de object-ID's aan beide zijden van de koppeling met elkaar overeenkomen. Als er bijvoorbeeld een relatie bestaat tussen WERKNEMERS en hun KINDEREN, dan moet er enige garantie zijn dat wanneer een object dat een kind beschrijft, wordt ingevoegd in een object dat de werknemer vertegenwoordigt, de identificatie van laatstgenoemde wordt toegevoegd aan het overeenkomstige object. Dit type relationele integriteit, enigszins analoog aan referentiële integriteit in het relationele datamodel, wordt tot stand gebracht met behulp van feedbacklinks. Om de integriteit van de relaties te garanderen, wordt de ontwerper voorzien van een speciale syntactische constructie die nodig is om de locatie van de omgekeerde object-ID te specificeren. De verantwoordelijkheid om beperkingen te stellen aan de integriteit van relaties (en aan de referentiële integriteit in een relationele database) ligt bij de ontwerper.

Bij OOMD vinden zowel de gegevensbeschrijving als de manipulatie plaats met behulp van dezelfde objectgeoriënteerde proceduretaal.

De ODMG-groep (Object Database Management Group) houdt zich bezig met de problemen van standaardisatie van objectdatabasetechnologie. Het ontwikkelde een objectmodel (ODMG 2.0 werd in september 1997 aangenomen) dat een standaardmodel definieert voor de semantiek van databaseobjecten. Dit model is belangrijk omdat het ingebouwde semantiek definieert die een objectgeoriënteerd DBMS (OODBMS) begrijpt en kan implementeren. De structuur van bibliotheken en applicaties die deze semantiek gebruiken, moet overdraagbaar zijn tussen verschillende OODBMS's die dit object-MD ondersteunen. De belangrijkste componenten van de ODMG-architectuur zijn: het objectmodel (OM), de objectdefinitietaal (ODL), de objectquerytaal (OQL) en de mogelijkheid om te binden aan C++, Java en Smalltalk.

Het objectdatamodel volgens de ODMG 2.0-standaard wordt gekenmerkt door de volgende eigenschappen:

De basisbouwstenen zijn objecten en letterlijke waarden. Elk object heeft een unieke identificatie. Een letterlijke heeft geen eigen identificatie en kan niet afzonderlijk als object bestaan. Letterlijke waarden zijn altijd ingebed in objecten en er kan niet afzonderlijk naar worden verwezen;

Objecten en letterlijke waarden worden onderscheiden naar type. Elk type heeft zijn eigen domein, gedeeld door alle objecten en letterlijke waarden van dat type. Typen kunnen ook gedrag vertonen. Als een type bepaald gedrag vertoont, vertonen alle objecten van dit type hetzelfde gedrag. In de praktijk kan het type de klasse zijn waaruit het object is gemaakt, een interface of een eenvoudig gegevenstype (zoals een geheel getal). Een object kan worden gezien als een instantie van een type;

De toestand van een object wordt bepaald door een reeks huidige waarden die worden gerealiseerd door een reeks eigenschappen. Deze eigenschappen kunnen attributen van een object zijn of relaties tussen een object en een of meer andere objecten;

Het gedrag van een object wordt gedefinieerd door een reeks bewerkingen die op het object of op het object zelf kunnen worden uitgevoerd. Bewerkingen kunnen een lijst met invoer- en uitvoerparameters hebben, elk van een strikt gedefinieerd type. Elke bewerking kan ook een getypt resultaat retourneren;

De databasedefinitie wordt opgeslagen in een schema geschreven in de Object Definition Language (ODL). In de database worden objecten opgeslagen, waardoor deze kunnen worden gedeeld tussen verschillende gebruikers en applicaties.

DBMS's gebaseerd op OODS worden objectgeoriënteerde DBMS's (OODBMS's) genoemd. Deze DBMS'en worden geclassificeerd als DBMS'en van de derde generatie* (* De geschiedenis van de ontwikkeling van modellen voor gegevensopslag wordt vaak verdeeld in drie fasen (generaties): de eerste generatie (eind jaren zestig - begin jaren zeventig) - hiërarchische en netwerkmodellen; tweede generatie (ongeveer 1970-jaren 80) - relationeel model; derde generatie (jaren 80 - begin 2000) - objectgeoriënteerde modellen.).

Tegenwoordig worden objectgeoriënteerde databases in verschillende organisaties gebruikt om een ​​breed scala aan problemen op te lossen. Analyse en generalisatie van de opgebouwde ervaring op het gebied van informatietechnologiegegevens maakten het mogelijk toepassingen te identificeren waarin het gebruik van objectgeoriënteerde databases gerechtvaardigd is:

De applicatie bestaat uit een groot aantal op elkaar inwerkende onderdelen. Elk van hen heeft zijn eigen gedrag, dat afhangt van het gedrag van anderen;

Het systeem moet grote hoeveelheden ongestructureerde of complexe gegevens verwerken;

De applicatie zal voorspelbaar toegang krijgen tot gegevens, dus het navigatiekarakter van objectgeoriënteerde databases zal geen significant nadeel zijn;

De behoefte aan ongeplande verzoeken is beperkt;

De structuur van de opgeslagen gegevens is hiërarchisch of vergelijkbaar van aard.

Momenteel zijn er veel objectgeoriënteerde DBMS'en op de softwaremarkt. In tabel 10.6 presenteert enkele commerciële systemen van deze klasse.

Tabel 10.6

Moderne commerciële OODBMS,

hun fabrikanten en toepassingsgebieden

Een van de fundamentele verschillen tussen objectdatabases en relationele databases is de mogelijkheid om nieuwe gegevenstypen te creëren en te gebruiken. Een belangrijk kenmerk van OODBMS is dat het creëren van een nieuw type geen wijziging van de databasekern vereist en gebaseerd is op de principes van objectgeoriënteerd programmeren.

De OODBMS-kern is geoptimaliseerd voor operaties met objecten. Natuurlijke handelingen hiervoor zijn het cachen van objecten, het onderhouden van versies van objecten en het verdelen van toegangsrechten tot specifieke objecten. OODBMS wordt gekenmerkt door hogere prestaties bij bewerkingen die toegang en het ophalen van gegevens vereisen die in objecten zijn verpakt, vergeleken met relationele DBMS'en, waarvoor de noodzaak om gerelateerde gegevens op te halen leidt tot de prestaties van aanvullende interne bewerkingen.

Van groot belang voor een OODBMS is de mogelijkheid om objecten van de ene database naar de andere te verplaatsen.

Bij het maken van verschillende applicaties op basis van een OODBMS is de ingebouwde klassenstructuur van een bepaald DBMS belangrijk. De klassenbibliotheek ondersteunt in de regel niet alleen alle standaardgegevenstypen, maar ook een uitgebreide reeks multimedia en andere complexe gegevenstypen, zoals video, geluid en een reeks animatieframes. Sommige OODBMS'en hebben klassenbibliotheken gemaakt die het mogelijk maken om documentinformatie op te slaan en in de volledige tekst te doorzoeken (bijvoorbeeld Jasmine, ODB-Jupiter). Een voorbeeld van de basisklassestructuur wordt getoond in Fig. 10.17.

De hoofdpositie daarin wordt ingenomen door de klasse TOdbObject, die alle noodzakelijke eigenschappen en methoden bevat voor het controleren van de toegang tot de database en het uitvoeren van indexering. Alle andere klassen overschrijven de methoden ervan en voegen een typecontrole toe voor de juistheid van het type dat ze implementeren, en een specifieke indexer.

Zoals blijkt uit Fig. 10.17 zijn er in de structuur verschillende klassen gericht op het verwerken van documentaire informatie - TOdbText, TOdbDocument, TODBTextDocument, enz. Elk document wordt vertegenwoordigd door een afzonderlijk object. Dit zorgt voor een natuurlijke opslag van documenten. Eén van de belangrijkste handelingen is het zoeken naar documenten op aanvraag. Voor de meeste klassen is de mogelijkheid geïmplementeerd om naar objecten te zoeken op basis van de waarde van een specifieke sleutel. Voor de klasse TOdbText is de mogelijkheid geïmplementeerd om een ​​zoekopdracht te genereren op basis van een zinsnede die in natuurlijke taal is geschreven.

De klasse TOdbDocument is speciaal en kan verschillende soorten objecten bevatten. Het bestaat uit velden, die elk een naam hebben en zijn gekoppeld aan een object van een specifiek type. De aanwezigheid van deze klasse geeft de gebruiker de mogelijkheid om de set typen uit te breiden. Door een containerobject (document) te wijzigen, kunt u een specifieke set velden instellen en een nieuw documenttype verkrijgen.

Op basis van ODB-Jupiter hebben de ontwikkelaars van OODBMS een volledig functioneel informatie-ophaalsysteem ODB-Text gecreëerd, dat een universele structuur van opgeslagen gegevens en een krachtige zoekmachine heeft. Het ODB-Text-systeem is een hulpmiddel voor de collectieve verwerking van documenten en het onderhouden van een bedrijfsarchief. Mogelijke toepassingen zijn onder meer de automatisering van de documentstroomadministratie in een modern kantoor, de constructie van referentie- en informatiesystemen (vergelijkbaar met de bekende juridische databases), het onderhoud van netwerkdatabases, personeelsdossiers, bibliografie, enz.

41. Kenmerken van toegepast IC-ontwerp. Fasen van IP-ontwikkeling. (Onderwerp 11, pp. 100-103).

11.1.3. Kenmerken van systeemontwerp van toegepaste IC's

Bij het bouwen (selecteren, aanpassen) van een informatiesysteem kun je twee hoofdconcepten gebruiken, twee hoofdbenaderingen (het derde concept is een combinatie daarvan):

1. focus op problemen die met dit informatiesysteem moeten worden opgelost, d.w.z. probleemgerichte aanpak (of inductieve aanpak);

2. oriëntatie op technologie die beschikbaar (geactualiseerd) is in een bepaald systeem of omgeving, d.w.z. technologiegerichte benadering (of deductieve benadering).

De keuze van het concept hangt af van strategische (tactische) en/of lange termijn (korte termijn) criteria, problemen en middelen.

Als eerst de mogelijkheden van bestaande technologie worden bestudeerd en vervolgens de huidige problemen worden geïdentificeerd die met hun hulp kunnen worden opgelost, dan is het noodzakelijk om te vertrouwen op een technologiegerichte aanpak.

Als eerst de huidige problemen worden geïdentificeerd en vervolgens technologie wordt geïntroduceerd die voldoende is om deze problemen op te lossen, dan is het noodzakelijk om te vertrouwen op een probleemgerichte aanpak.

Tegelijkertijd zijn beide concepten van het bouwen van een informatiesysteem van elkaar afhankelijk: de introductie van nieuwe technologieën verandert de problemen die worden opgelost, en het veranderen van de problemen die worden opgelost leidt tot de noodzaak om nieuwe technologieën te introduceren; beide beïnvloeden de genomen beslissingen.

Systeemontwerp (ontwikkeling) en gebruik van elk toegepast (bedrijfs)informatiesysteem moet de volgende levenscyclus van het informatiesysteem doorlopen:

– analyse voorafgaand aan het ontwerp (ervaring met het creëren van andere soortgelijke systemen, prototypen, verschillen en kenmerken van het systeem dat wordt ontwikkeld, enz.), analyse van de externe manifestaties van het systeem;

– intrasysteemanalyse, interne analyse (analyse van systeemsubsystemen);

– systemische (morfologische) beschrijving (representatie) van het systeem (beschrijving van het systeemdoel, systeemrelaties en verbindingen met de omgeving, andere systemen en systeembronnen - materiaal, energie, informatie, organisatorisch, menselijk, ruimtelijk en temporeel);

– vaststelling van criteria voor toereikendheid, efficiëntie en duurzaamheid (betrouwbaarheid);

– functionele beschrijving van de systeemsubsystemen (beschrijving van modellen, algoritmen voor het functioneren van subsystemen);

– prototyping (lay-outbeschrijving) van het systeem, beoordeling van de interactie van systeemsubsystemen (ontwikkeling van een lay-out - implementatie van subsystemen met vereenvoudigde functionele beschrijvingen, procedures en testen van de interactie van deze lay-outs om aan het systeemdoel te voldoen), terwijl het mogelijk is om “lay-outs” van criteria voor geschiktheid, stabiliteit en efficiëntie te gebruiken;

– “assembleren” en testen van het systeem - implementatie van volwaardige functionele subsystemen en criteria, evaluatie van het model volgens de geformuleerde criteria;

– systeembediening;

– bepaling van doelstellingen voor de verdere ontwikkeling van het systeem en zijn toepassingen;

– onderhoud van het systeem - verduidelijking, wijziging, uitbreiding van de mogelijkheden van het systeem in de manier waarop het functioneert (met het oog op zijn evolutie).

Deze fasen zijn de belangrijkste voor het opnieuw ontwerpen van systemen.

De ontwikkeling van een bedrijfsinformatiesysteem wordt in de regel uitgevoerd voor een zeer specifieke onderneming. Kenmerken van de onderwerpactiviteit van de onderneming zullen zeker de structuur van het informatiesysteem beïnvloeden. Maar tegelijkertijd zijn de structuren van verschillende ondernemingen over het algemeen vergelijkbaar met elkaar. Elke organisatie, ongeacht het type activiteit, bestaat uit een aantal divisies die rechtstreeks een of ander type bedrijfsactiviteit uitvoeren. En deze situatie geldt voor bijna alle organisaties, ongeacht het soort activiteit dat ze ondernemen.

Elke organisatie kan dus worden beschouwd als een reeks op elkaar inwerkende elementen (divisies), die elk hun eigen, tamelijk complexe structuur kunnen hebben. Ook de relaties tussen afdelingen zijn behoorlijk complex. Over het algemeen kunnen drie soorten verbindingen tussen afdelingen van een onderneming worden onderscheiden:

Functionele verbindingen - elke afdeling voert bepaalde soorten werk uit binnen één bedrijfsproces;

Informatiecommunicatie - afdelingen wisselen informatie uit (documenten, faxen, schriftelijke en mondelinge opdrachten, enz.);

Externe communicatie - sommige afdelingen hebben interactie met externe systemen, en hun interactie kan zowel informatief als functioneel zijn.

De gemeenschappelijke structuur van verschillende ondernemingen stelt ons in staat enkele gemeenschappelijke principes te formuleren voor het bouwen van bedrijfsinformatiesystemen.

Over het algemeen kan het proces van het ontwikkelen van een informatiesysteem vanuit twee gezichtspunten worden bekeken:

Op basis van de tijd, of op basis van fasen van de levenscyclus van het systeem dat wordt ontwikkeld. In dit geval beschouwen we de dynamische organisatie van het ontwikkelingsproces, beschreven in termen van cycli, fasen, iteraties en fasen.

Als project wordt een bedrijfsinformatiesysteem ontwikkeld. Veel kenmerken van projectmanagement en de projectontwikkelingsfase (levenscyclusfasen) zijn gemeenschappelijk, niet alleen onafhankelijk van het vakgebied, maar ook van de aard van het project (het maakt niet uit of het een technisch of een economisch project is). Daarom is het zinvol om eerst een aantal algemene projectmanagementkwesties te overwegen.

Een project is een in de tijd beperkte, doelbewuste verandering naar een afzonderlijk systeem met aanvankelijk duidelijk gedefinieerde doelen, waarvan de verwezenlijking de voltooiing van het project bepaalt, evenals met vastgestelde vereisten voor timing, resultaten, risico's en een raamwerk voor de besteding van fondsen en middelen en voor de organisatiestructuur.

Meestal is het voor een complex concept (zoals in het bijzonder het concept van een project) moeilijk om een ​​ondubbelzinnige formulering te geven die alle kenmerken van het geïntroduceerde concept volledig dekt. Daarom beweert de gegeven definitie niet uniek en volledig te zijn.

De volgende belangrijkste onderscheidende kenmerken van het project als beheerobject kunnen worden geïdentificeerd:

Variabiliteit is een doelbewuste overdracht van een systeem van een bestaand systeem naar een ander systeem

de gewenste staat, beschreven in termen van projectdoelen;

Beperking van het einddoel;

Beperkte duur;

Budgetbeperkingen;

Beperkte middelen vereist;

Nieuwigheid voor de onderneming waarvoor het project wordt uitgevoerd;

Complexiteit - de aanwezigheid van een groot aantal factoren die direct of indirect van invloed zijn op de voortgang en resultaten van het project;

Juridische en organisatorische ondersteuning - creatie van een specifieke organisatiestructuur voor de duur van het project.

Efficiëntie van het werk wordt bereikt door het beheer van het projectimplementatieproces, dat zorgt voor de toewijzing van middelen, coördinatie van de volgorde van uitgevoerde werkzaamheden en compensatie van interne en externe storende invloeden.

Vanuit het oogpunt van de theorie van controlesystemen moet een project als controleobject waarneembaar en controleerbaar zijn, dat wil zeggen dat bepaalde kenmerken worden geïdentificeerd waarmee de voortgang van het project voortdurend kan worden gevolgd (observabiliteitseigenschap). Daarnaast zijn mechanismen nodig voor het tijdig beïnvloeden van de voortgang van het project (beheersbaarheidseigenschap).

De beheersbaarheidseigenschap is vooral belangrijk in omstandigheden van onzekerheid en variabiliteit van het vakgebied, die vaak gepaard gaan met ontwikkelingsprojecten voor informatiesystemen.

Elk project, ongeacht de complexiteit en de hoeveelheid werk die nodig is voor de implementatie ervan, doorloopt bepaalde stadia in zijn ontwikkeling: van de staat waarin ‘het project nog niet bestaat’ tot de staat waarin ‘het project niet meer bestaat’. De reeks ontwikkelingsfasen, vanaf het ontstaan ​​van een idee tot de volledige voltooiing van een project, wordt meestal verdeeld in fasen (fasen, fasen).

Er zijn enkele verschillen bij het bepalen van het aantal fasen en hun inhoud, aangezien deze kenmerken grotendeels afhangen van de omstandigheden van het specifieke project en de ervaring van de belangrijkste deelnemers. De logica en de basisinhoud van het ontwikkelingsproces van informatiesystemen zijn echter in bijna alle gevallen hetzelfde.

De volgende fasen van de ontwikkeling van informatiesystemen kunnen worden onderscheiden:

Vorming van het concept;

Ontwikkeling van technische specificaties;

Ontwerp;

Productie;

Het in bedrijf stellen van het systeem.

Laten we elk van hen in meer detail bekijken. De tweede en gedeeltelijk derde fase worden gewoonlijk systeemontwerpfasen genoemd, en de laatste twee (soms wordt hier ook de ontwerpfase in opgenomen) zijn implementatiefasen.

Conceptuele fase

Ideeënvorming, doelen stellen;

Vorming van een belangrijk projectteam;

Het bestuderen van de motivatie en wensen van de klant en andere deelnemers;

Verzameling van initiële gegevens en analyse van de bestaande staat;

Bepaling van basisvereisten en beperkingen, vereiste materiële, financiële en arbeidsmiddelen;

Vergelijkende beoordeling van alternatieven;

Indiening van voorstellen, onderzoek en goedkeuring ervan.

Ontwikkeling van een technisch voorstel

Ontwikkeling van de hoofdinhoud van het project, de basisstructuur van het project;

Ontwikkeling en goedkeuring van technische specificaties;

Planning, ontleding van het structurele basismodel van het project;

Het opstellen van ramingen en begroting voor het project, het bepalen van de benodigde middelen;

Ontwikkeling van kalenderplannen en uitgebreide werkroosters;

Het ondertekenen van een contract met de klant;

Het in gebruik nemen van communicatiemiddelen tussen projectdeelnemers en het bewaken van de voortgang van de werkzaamheden.

Ontwerp

In deze fase worden subsystemen en hun relaties bepaald, en worden de meest effectieve manieren geselecteerd om het project te implementeren en middelen te gebruiken. Typische werkzaamheden van deze fase:

Het uitvoeren van basisontwerpwerkzaamheden;

Ontwikkeling van particuliere technische specificaties;

Het uitvoeren van conceptueel ontwerp;

Opstellen van technische specificaties en instructies;

Presentatie van ontwerpontwikkeling, onderzoek en goedkeuring.

Ontwikkeling

In deze fase wordt de coördinatie en operationele controle van projectwerkzaamheden uitgevoerd, worden subsystemen vervaardigd, geïntegreerd en getest. Hoofdinhoud:

Het uitvoeren van software ontwikkelwerkzaamheden;

Voorbereiding op systeemimplementatie;

Monitoring en regulering van belangrijke projectindicatoren.

Inbedrijfstelling van het systeem

In deze fase worden tests uitgevoerd, proefdraaien van het systeem in reële omstandigheden en worden er onderhandelingen gevoerd over de resultaten van het project en over mogelijke nieuwe contracten. Belangrijkste soorten werkzaamheden:

Uitgebreide testen;

42. Het concept van de IE-levenscyclus. (Onderwerp 11, pp. 103-105).

Objectgeoriënteerde database(OODB) - een database waarin gegevens worden gemodelleerd in de vorm van objecten, hun attributen, methoden en klassen.

Objectgeoriënteerde databases worden doorgaans aanbevolen voor gevallen waarin hoogwaardige verwerking van gegevens met een complexe structuur vereist is.

Het OODB-manifest stelt verplichte kenmerken voor waaraan elke OODB moet voldoen. Hun keuze is gebaseerd op 2 criteria: het systeem moet objectgeoriënteerd zijn en een database zijn.

Vereiste kenmerken

1. Ondersteuning voor complexe objecten. Het systeem moet de mogelijkheid bieden om samengestelde objecten te creëren door het gebruik van samengestelde objectconstructors. Het is noodzakelijk dat objectconstructors orthogonaal zijn, dat wil zeggen dat elke constructor op elk object kan worden toegepast.

2. Ondersteuning van de individualiteit van objecten. Alle objecten moeten een unieke identificatie hebben die onafhankelijk is van de waarden van hun attributen.

3. Ondersteuning voor inkapseling. Correcte inkapseling wordt bereikt doordat programmeurs alleen toegang hebben tot de interfacespecificatie van methoden, en de gegevens en implementatie van methoden verborgen zijn in objecten.

4. Ondersteuning voor typen en klassen. Een OODB is vereist om ten minste één concept van onderscheid tussen typen en klassen te ondersteunen. (De term "type" komt meer overeen met het concept van een abstract gegevenstype. In programmeertalen wordt een variabele gedeclareerd met een indicatie van het type. De compiler kan deze informatie gebruiken om te controleren of de bewerkingen die op de variabele worden uitgevoerd compatibel zijn met het type ervan, dat helpt de juistheid van de software te garanderen, is een sjabloon voor het maken van objecten en biedt methoden die op die objecten kunnen worden toegepast. Het concept van een "klasse" is dus meer een run -time dan een compile-time.)

5. Ondersteuning voor het erven van typen en klassen van hun voorouders. Een subtype of subklasse moet attributen en methoden erven van respectievelijk zijn supertype of superklasse.

6. Overbelasting gecombineerd met volledige binding. Methoden moeten worden toegepast op objecten van verschillende typen. De implementatie van een methode moet afhangen van het type objecten waarop de methode wordt toegepast. Om deze functionaliteit te bieden, mag de binding van de methodenaam in het systeem pas plaatsvinden tijdens de runtime van het programma.

7. Computationele volledigheid. De datamanipulatietaal moet een programmeertaal voor algemene doeleinden zijn.

8. De set gegevenstypen moet uitbreidbaar zijn. De gebruiker moet over de middelen beschikken om nieuwe gegevenstypen te creëren op basis van een reeks vooraf gedefinieerde systeemtypen. Bovendien mag er geen verschil zijn tussen de manier waarop systeem- en gebruikersgegevenstypen worden gebruikt.

OO DBMS

Objectgeoriënteerde databases– databases waarin informatie wordt gepresenteerd in de vorm van objecten, zoals in objectgeoriënteerde programmeertalen.

Om objectgeoriënteerde databasebeheersystemen (OODBMS) tegenwoordig wel of niet te gebruiken in echte projecten? In welke gevallen mogen ze wel en in welke gevallen niet worden gebruikt?

Hier voordelen met behulp van OODBMS:

· Er is geen probleem met impedantie-mismatch tussen het datamodel in de applicatie en de database. Alle gegevens worden in dezelfde vorm als in het applicatiemodel in de database opgeslagen.

· Het is niet nodig om het datamodel afzonderlijk te ondersteunen aan de DBMS-kant.

· Alle objecten op gegevensbronniveau zijn strikt getypeerd. Geen string-kolomnamen meer! Het herstructureren van een objectgeoriënteerde database en de code die erop draait, is nu geautomatiseerd, in plaats van een eentonig en saai proces.

ODMG-standaard

Eerste manifest was formeel slechts een artikel gepresenteerd op Conferentie over objectgeoriënteerde en deductieve databases een groep individuen. Zoals je in de vorige paragraaf kunt zien, waren de eisen van het Manifest emotioneler dan expliciet gespecificeerd. In 1991 werd het ODMG-consortium gevormd (toen werd deze afkorting uitgebreid tot Objectdatabasebeheergroep, maar kreeg later een bredere interpretatie - Objectgegevensbeheergroep). Het ODMG-consortium is nauw verbonden met het veel grotere OMG-consortium ( Objectbeheergroep), dat twee jaar eerder werd opgericht. Het belangrijkste oorspronkelijke doel van de ODMG was het ontwikkelen van een industriestandaard voor objectgeoriënteerde databases (een gemeenschappelijk model). Het basisobjectmodel OMG COM ( Kernobjectmodel). In de loop van zijn ruim tienjarig bestaan ​​heeft ODMG drie basisversies van de standaard gepubliceerd, waarvan de nieuwste ODMG 3.0 heet. 16

Het is grappig dat hoewel ODMG (volgens de auteur) voortkwam uit OMG, de afgelopen jaren sommige OMG-standaarden vertrouwden op het ODMG-objectmodel. Met name de OCL-taalspecificatie ( Objectbeperkingstaal), dat deel uitmaakt van de algemene UML 1.4 (en UML 2.0) taalspecificatie. In dit artikel is het niet onze bedoeling om een ​​gedetailleerde vergelijking te maken tussen de OMG- en ODMG-benaderingen, waarnaar we geïnteresseerde lezers verwijzen Encyclopedie Kogalovsky en materiaal van de websites van deze consortia. We zullen ons beperken tot een korte samenvatting van de belangrijkste ideeën uit de ODMG-3-standaard.

ODMG-architectuur

De door ODMG voorgestelde architectuur wordt getoond in Fig. 2.1. Deze architectuur definieert hoe gegevens worden opgeslagen en de verschillende soorten gebruikerstoegang tot deze “gegevensopslag” 17 . Eén enkele dataopslag is toegankelijk vanuit een datadefinitietaal, een querytaal en een aantal datamanipulatietalen. 18 Op afb. 2.1 OAO-middelen Objectdefinitietaal, OQL- Objectquerytaal en OML- Objectmanipulatietaal.

Rijst. 2.1. ODMG-architectuur

Centraal in de architectuur staat datamodel, die de organisatiestructuur vertegenwoordigt waarin alle gegevens die door het OODBMS worden beheerd, worden opgeslagen. De objectdefinitietaal, de querytaal en de manipulatietalen zijn zo ontworpen dat al hun mogelijkheden gebaseerd zijn op het datamodel. De architectuur maakt een verscheidenheid aan implementatiestructuren mogelijk voor het opslaan van gemodelleerde gegevens, maar een belangrijke vereiste is dat alle softwarebibliotheken en alle ondersteunende tools binnen een objectgeoriënteerd raamwerk worden aangeboden en consistent moeten worden gehouden met de gegevens.

De belangrijkste componenten van de architectuur zijn de volgende.

• Objectgegevensmodel. Alle gegevens die door een OODBMS worden opgeslagen, zijn gestructureerd in termen van datamodelconstructies. Het datamodel definieert de exacte semantiek van alle concepten (zie hieronder voor meer details).

• Gegevensdefinitietaal (ODL). Databaseschema's worden beschreven in termen van ODL, waarbij datamodelconstructies worden geïnstantieerd in de vorm van een definitietaal. Met ODL kunt u een schema beschrijven als een reeks interfaces van objecttypen, inclusief een beschrijving van de eigenschappen van de typen en de relaties ertussen, evenals de namen van de bewerkingen en hun parameters. ODL is geen volledige programmeertaal; de type-implementatie moet worden gedaan in een van de talen van de OML-categorie. Bovendien is ODL dat wel virtueel taal in die zin dat de ODMG-standaard geen implementatie ervan vereist in OODBMS-softwareproducten die geacht worden aan de standaard te voldoen. Deze producten mogen gelijkwaardige definitietalen ondersteunen die alle kenmerken van ODL omvatten, maar zijn aangepast aan de kenmerken van een bepaald systeem. Het hebben van een ODL-taalspecificatie in de ODMG-standaard is echter belangrijk omdat de taal de eigenschappen van het datamodel specificeert.

• Objectquerytaal (ODL). De taal heeft een syntaxis die vergelijkbaar is met die van de SQL-taal, maar is afhankelijk van de semantiek van het ODMG-objectmodel. De standaard maakt direct gebruik van OQL en de inbedding ervan in een van de talen van de OML-categorie mogelijk.

Relationeel datamodel

Bijna alle moderne systemen zijn hierop gebaseerd relationeel(relationele) databasebeheermodellen. Naam relationeel Dit komt door het feit dat elk record in zo'n database informatie bevat die betrekking heeft op slechts één specifiek object.

IN relationeel In het DBMS worden alle verwerkte gegevens gepresenteerd in de vorm van platte tabellen. Informatie over objecten van een bepaald type wordt in tabelvorm gepresenteerd: de tabelkolommen bevatten verschillende objectattributen, en de rijen zijn bedoeld om de beschrijvingen van alle attributen terug te brengen tot individuele exemplaren van objecten.

Het model dat in de fase van informatiemodellering is gecreëerd, voldoet het meest aan de principes van relationaliteit. Om dit model echter naar een relationeel model te converteren, is het noodzakelijk een procedure uit te voeren genaamd normalisatie.

De normalisatietheorie werkt met vijf normale vormen. Deze formulieren zijn ontworpen om informatieredundantie te verminderen, dus elk volgend normaalformulier moet voldoen aan de vereisten van het vorige en aan enkele aanvullende voorwaarden. Bij praktisch databaseontwerp worden de vierde en vijfde vorm in de regel niet gebruikt. We beperkten ons tot het beschouwen van de eerste vier normaalvormen.

Laten we de concepten introduceren die nodig zijn om het proces van het reduceren van een model tot een relationeel schema te begrijpen.

Houding- abstractie van het beschreven object als een reeks eigenschappen ervan. Tijdens de infologische ontwerpfase spraken we over de abstractie van objecten en schreven we er enkele eigenschappen aan toe. Nu gaan we met conceptueel ontwerp naar het volgende niveau van abstractie. In dit stadium bestaan ​​objecten als zodanig niet meer. We werken met een reeks eigenschappen die een object definiëren.

Relatie-instantie- een reeks eigenschapswaarden van een specifiek object.

Primaire sleutel- een identificerende set attributen, d.w.z. de betekenis van deze attributen is in een bepaald opzicht uniek. Er zijn geen twee exemplaren van een relatie die dezelfde waarden in de primaire sleutel bevatten.

Eenvoudig attribuut- een attribuut waarvan de waarden ondeelbaar zijn.

Complex attribuut- een attribuut waarvan de waarde een reeks waarden is van verschillende eigenschappen van een object of meerdere waarden van één eigenschap.

Concepten van essentie..

Domein

Het concept van een domein is specifieker voor databases, hoewel het enkele analogieën vertoont met subtypen in sommige programmeertalen. In de meest algemene vorm wordt een domein gedefinieerd door het specificeren van een basisgegevenstype waartoe de elementen van het domein behoren, en een willekeurige logische expressie toegepast op het element van het gegevenstype. Als de evaluatie van deze Booleaanse expressie waar retourneert, is het data-element een domeinelement.

De meest correcte intuïtieve interpretatie van het concept van een domein is om het domein te begrijpen als een toelaatbare potentiële reeks waarden van een bepaald type. Het domein "Namen" in ons voorbeeld is bijvoorbeeld gedefinieerd op basis van het basistype van tekenreeksen, maar de waarden ervan kunnen alleen tekenreeksen bevatten die een naam kunnen vertegenwoordigen (dergelijke tekenreeksen kunnen met name niet beginnen met een zacht teken).

Er moet ook gewezen worden op de semantische lading van het domeinconcept: gegevens worden alleen als vergelijkbaar beschouwd als ze tot hetzelfde domein behoren. In ons voorbeeld zijn de domeinwaarden ‘Gap Numbers’ en ‘Group Numbers’ van het type geheel getal, maar zijn niet vergelijkbaar. Merk op dat de meeste relationele DBMS'en het concept van een domein niet gebruiken, hoewel Oracle V.7 dit al ondersteunt.

Invoering

De opkomst van het vakgebied van objectgeoriënteerde databases (OODB) werd in de eerste plaats bepaald door de behoeften van de praktijk: de noodzaak om complexe informatietoepassingssystemen te ontwikkelen waarvoor de technologie van eerdere databasesystemen niet geheel bevredigend was. Natuurlijk is OODB niet uit het niets ontstaan. De overeenkomstige basis werd zowel geleverd door eerder werk op het gebied van databases als door de zich lang ontwikkelende gebieden van programmeertalen met abstracte gegevenstypen en objectgeoriënteerde programmeertalen.

Wat betreft de verbinding met eerder werk op het gebied van databases, werd de sterkste invloed op het werk op het gebied van OODB uitgeoefend door de ontwikkeling van het DBMS en de chronologisch daaropvolgende familie van databases, die het beheer van complexe objecten ondersteunden. Deze werken vormden de structurele basis voor de organisatie van OODB. In deze samenvatting worden OOMD en OODBMS besproken.

Objectgeoriënteerd datamodel

Laten we eens kijken naar een van de benaderingen voor het bouwen van een database: met behulp van een objectgeoriënteerd datamodel (OOMD). Gegevensmodellering in OOMD is gebaseerd op het concept van een object. OOMD wordt meestal gebruikt in complexe vakgebieden waarvoor de functionaliteit van het relationele model niet voldoende is voor modellering (bijvoorbeeld voor ontwerpautomatiseringssystemen (CAD), publicatiesystemen, enz.).

Het objectgeoriënteerde datamodel ODMG verschilt voornamelijk van andere modellen in één fundamenteel aspect. In het SQL-gegevensmodel en het echte relationele gegevensmodel is een database een verzameling benoemde gegevenscontainers van hetzelfde algemene type: respectievelijk tabellen of relaties. In een objectgeoriënteerd datamodel is een database een verzameling objecten (datacontainers) van een willekeurig type.

Bij het maken van objectgeoriënteerde DBMS (OODBMS) worden verschillende methoden gebruikt, namelijk:

het inbedden van tools die zijn ontworpen voor het werken met databases in een objectgeoriënteerde taal;

uitbreiding van de bestaande taal voor het werken met databases met objectgeoriënteerde functies;

creatie van objectgeoriënteerde bibliotheken met functies voor het werken met databases;

creatie van een nieuwe taal en een nieuw objectgeoriënteerd datamodel.

De voordelen van OOMD zijn onder meer brede domeinmodelleringsmogelijkheden, een expressieve querytaal en hoge prestaties. Elk object in de OOMD heeft een unieke identificatie (OID - objectidentifier). Toegang krijgen via OID is veel sneller dan zoeken in een relationele tabel.

Tot de tekortkomingen van de OODB behoren het ontbreken van een algemeen aanvaard model, het gebrek aan ervaring met het opzetten en exploiteren van de OODB, de complexiteit van het gebruik en de ontoereikende instrumenten voor gegevensbescherming.

Laten we nu eens kijken hoe ondersteuning voor datamodellen wordt geïmplementeerd in echte databasebeheersystemen.

In een objectgeoriënteerd model (OOM) is het bij het presenteren van gegevens mogelijk individuele databaserecords te identificeren. Relaties worden tot stand gebracht tussen databaserecords en hun verwerkingsfuncties met behulp van mechanismen die vergelijkbaar zijn met de overeenkomstige faciliteiten in objectgeoriënteerde programmeertalen.

Standaard OOM wordt beschreven in de aanbevelingen van de ODMG-93-standaard (Object Database Management Group - objectgeoriënteerde databasebeheergroep). Het is nog niet mogelijk geweest de aanbevelingen van ODMG-93 volledig uit te voeren. Om de belangrijkste ideeën te illustreren, kunnen we een enigszins vereenvoudigd model van een objectgeoriënteerde database overwegen.

De structuur van een objectgeoriënteerde database kan grafisch worden weergegeven als een boom, waarvan de knooppunten objecten zijn. De eigenschappen van objecten worden beschreven door een standaardtype (bijvoorbeeld string) of een door de gebruiker geconstrueerd type (gedefinieerd als klasse).

De waarde van een eigenschap van het type string is een reeks tekens. De waarde van een eigenschap van type class is een object dat een instantie is van de overeenkomstige klasse. Elke objectinstantie van een klasse wordt beschouwd als een onderliggend object van het object waarin het als eigenschap is gedefinieerd. Een instanceobject van een klasse behoort tot zijn klasse en heeft één ouder. Generieke relaties in de database vormen een verbonden hiërarchie van objecten.