In objectgeoriënteerde databases (OODB's) kunnen gebruikers bewerkingen instellen op een bepaalde database, die bestaat uit objecten die van een grote verscheidenheid aan typen kunnen zijn en waarvoor bewerkingen zijn ingesteld. Ze kunnen efficiënt omgaan met binaire informatie, zoals multimedia-objecten. Een ander bijkomend voordeel van OODB is dat het kan worden geprogrammeerd met kleine procedurele verschillen zonder het hele systeem te beïnvloeden.
Vereisten voor het maken van de standaard
De geschiedenis van objectgeoriënteerde OODB-databases begint aan het einde van de vorige eeuw. Ze zijn gemaakt om te voldoen aan de behoeften van nieuwe toepassingen. De veronderstelling was dat objectgeoriënteerde databases in de jaren negentig een revolutie teweeg zouden brengen in softwaresystemen. Inmiddels is duidelijk dat dit niet het geval is. De heropleving van dit concept door de vrije-softwaregemeenschappen en de identificatie van geschikte toepassingen ervoor motiveert echter een herziening van de kenmerkenOODB, een alternatief voor de alomtegenwoordige relationele databases.
Objectgeoriënteerd biedt de flexibiliteit om aan sommige of alle vereisten te voldoen en is niet beperkt tot de gegevenstypen en querytalen van traditionele databases. Een belangrijk kenmerk van OODB's is de mogelijkheid die ze de ontwikkelaar bieden, waardoor hij zowel de structuur van complexe objecten als de applicatiebewerkingen kan specificeren. Een andere reden voor het maken van OODB's is het toenemende gebruik van talen voor softwareontwikkeling.
Databases zijn de basis geworden van veel informatiesystemen, maar traditionele databases zijn moeilijk te gebruiken wanneer de toepassingen die er toegang toe hebben, zijn geschreven in C++, Smalltalk of Java. Zo zijn 1C objectgeoriënteerde databases zo ontworpen dat ze direct kunnen worden geïntegreerd met applicaties die objectgeoriënteerde talen gebruiken door hun concepten over te nemen: Visual Studio. Net, C++, C, Microsoft SQL Server en anderen.
Het belangrijkste voordeel van OODB is de volledige eliminatie van de noodzaak voor RMs1 (impedantie) met daaropvolgende prestatieverbeteringen.
Flaws:
- Zeer primitieve overlegmechanismen, geen geaccepteerd platform op basis van zelfstandaardisatie.
- Kan procedures niet opslaan omdat objecten alleen toegankelijk zijn in de client.
- Onvolwassenheid op de markt.
- Geen fysieke groepering van objecten.
Objectparadigma
Objectgeoriënteerde databases zijn programmeerbare databases die complexe gegevens en hun relaties rechtstreeks opslaan zonder rijen en kolommen toe te wijzen, waardoor ze meer geschikt zijn voor toepassingen die met grote batches werken. Objecten hebben veel-op-veel-relaties en zijn toegankelijk via het gebruik van aanwijzers die eraan zijn gekoppeld om relaties tot stand te brengen. Zoals elke programmeerbare, biedt OODB een applicatie-ontwikkelomgeving en een permanente repository die klaar is voor gebruik. Het slaat informatie op en manipuleert deze die kan worden gedigitaliseerd in de vorm van objecten, biedt snelle toegang en geweldige verwerkingsmogelijkheden.
Basisconcepten gebruikt in een objectgeoriënteerde database:
- object identiteit;
- constructortype;
- taalcompatibiliteit;
- type hiërarchieën en overerving;
- verwerking van complexe objecten;
- polymorfisme en overbelasting van de operator;
- versies maken.
Om alle aspecten die kenmerkend zijn voor een objectgeoriënteerde database volledig in overweging te nemen, is het belangrijk om alle belangrijke objectparadigma's te noteren:
- Encapsulation is een eigenschap waarmee u informatie voor andere objecten kunt verbergen, waardoor onjuiste toegang of conflicten worden voorkomen.
- Overerving is een eigenschap waarmee objecten gedrag in een klassenhiërarchie erven.
- Polymorfisme is een eigenschap van een bewerking waarmee het kan worden toegepast opverschillende soorten objecten.
- De interface of handtekening van een bewerking omvat de naam en gegevenstypen van de argumenten of parameters.
- De implementatie of methode van een bewerking wordt afzonderlijk gespecificeerd en kan worden gewijzigd zonder de interface te beïnvloeden. Gebruikerstoepassingen kunnen met gegevens werken door gespecificeerde bewerkingen aan te roepen via hun naam en argumenten, ongeacht hoe ze zijn geïmplementeerd.
Klassen en functionaliteit
Bij het overwegen van het concept van klassen in OODB, is het noodzakelijk om onderscheid te maken tussen de termen "klasse" en "type". Een type wordt gebruikt om een set objecten met vergelijkbaar gedrag te beschrijven. In die zin hangt het af van welke bewerkingen op het object kunnen worden aangeroepen. Een klasse is een verzameling objecten die dezelfde interne structuur delen, dus het definieert een implementatie, terwijl een type beschrijft hoe het moet worden gebruikt.
De term instantiatie verwijst naar het feit dat instantiëring van een klasse kan worden gebruikt om een set objecten te produceren die dezelfde structuur en hetzelfde gedrag hebben als ingesteld door de klasse.
Een kenmerk dat erg belangrijk is voor de evolutie van objecten, is dat het zijn klasse kan veranderen, inclusief attributen en bewerkingen, terwijl de identiteit behouden blijft. Dit zou een mechanisme vereisen om de resulterende semantische integriteit te verwerken.
Door de objectgeoriënteerde database van een organisatie over te nemen, kan een klasse worden gedefinieerd als een subklasse van een reeds bestaande superklasse. Het zal alle attributen en methoden van de laatste erven en kan optioneel definiëreneigen. Dit concept is een belangrijk mechanisme om hergebruik te ondersteunen. Dezelfde delen van de structuur van twee verschillende klassen kunnen slechts één keer worden gedefinieerd in een gemeenschappelijke superklasse, waardoor er minder code zal worden geschreven. Er zijn systemen die toestaan dat een klasse een subklasse is van meer dan één superklasse. Deze functie wordt meervoudige overerving genoemd in tegenstelling tot enkele overerving.
Voorbeeld van een objectgeoriënteerde database
Het is vaak handig om dezelfde naam te gebruiken voor verschillende maar vergelijkbare methoden van de media-superklasse uit de foto- en videoklassen. Veel bestanden kunnen door verschillende kijkers worden bekeken. Ze moeten vaak alle foto's en video's bekijken met behulp van de "view"-methode en het juiste programma moet worden gestart. Wanneer de functie wordt aangeroepen en een link naar de video wordt doorgegeven, wordt de mediaspeler gestart. Om deze functie te implementeren, is het allereerst noodzakelijk om de "presentatie" -bewerking in de algemene media-superklasse te definiëren uit de foto- en videoklassen. Elk van de subklassen herdefinieert de opzoekbewerking voor hun specifieke behoeften. Dit resulteert in verschillende methoden die dezelfde bewerkingsnaam hebben. In dit geval heeft het gebruik van deze functie een belangrijk voordeel.
OODB-structuur
Het objectgeoriënteerde paradigma is gebaseerd op het inkapselen van gegevens en code met betrekking tot elk object in een enkele module. Conceptueel worden alle interacties tussen het en de rest van het systeem uitgevoerd met behulp van berichten. Vandaar de interfacetussen hen wordt bepaald door de toegestane set.
Over het algemeen wordt elk object geassocieerd met een set:
- Variabelen die objectgegevens bevatten en overeenkomen met ER-modelkenmerken.
- Berichten waarop hij reageert. Elk kan al dan niet parameters hebben, een of meer.
- Methoden, die elk een code zijn die berichten implementeert en als reactie daarop een waarde retourneert.
Berichten in een OO-omgeving impliceert niet het gebruik van fysieke sms in computernetwerken. Integendeel, het verwijst naar de uitwisseling van verzoeken tussen objecten, ongeacht de juiste details van hun implementatie. Soms roept een expressie een methode aan om het feit te activeren dat een bericht naar een object is verzonden, en gebruikt de expressie de bijbehorende methode.
Identiteit van het object
Het objectgeoriënteerde databasesysteem biedt een unieke identificatie voor elk onafhankelijk object dat in de database is opgeslagen. Het wordt meestal geïmplementeerd met behulp van een door het systeem gegenereerde unieke object-ID of OID. De OID-waarde is onzichtbaar voor de externe gebruiker, maar het systeem gebruikt deze intern om koppelingen tussen objecten te beheren.
De belangrijkste eigenschap van een OID is om onveranderlijk te zijn. De OID-waarde voor een bepaald object mag nooit veranderen. Dit behoudt de identiteit van de echte wereld die wordt weergegeven. Het heeft ook de voorkeur dat elke OID slechts één keer wordt gebruikt, zelfs als deze uit de database wordt verwijderd, mag de OID niet aan een andere worden toegewezen. Het wordt ook vaak als ongepast beschouwd om het te baseren op een fysiekehet adres van het object in de opslag, aangezien het reorganiseren ervan in de database de OID kan veranderen. Sommige systemen gebruiken echter het fysieke adres als de OID om de efficiëntie van het ophalen van objecten te vergroten. Een objectgeoriënteerd raamwerk legt automatisch relationele beperkingen op, die meestal meer van toepassing zijn: domein, sleutel, objectintegriteit en referentiële integriteit.
Drie hoofdconstructeurs
In OODB kunnen waarden of toestanden van complexe objecten van andere worden gemaakt met behulp van constructors van bepaalde typen. Een manier om ze weer te geven, is door elk te beschouwen als een triplet (i, c, v), waarbij i de unieke identifier (OID) van het object is, c de constructor is, dat wil zeggen een verwijzing naar hoe de waarde van het object is gemaakt, en v is de waarde of staat van het object. Er kunnen meerdere constructors zijn, afhankelijk van het datamodel en het OO-systeem.
Drie elementaire objectgeoriënteerde databaseconstructors:
- atomen;
- tupels;
- sets.
Andere, meer gebruikelijke toepassingen zijn lijsten en grafieken. Er is ook het D-domein, dat alle elementaire atoomwaarden bevat die direct op het systeem beschikbaar zijn. Ze bevatten doorgaans gehele getallen, reële getallen, tekenreeksen, datums en elk ander type gegevens dat rechtstreeks door het systeem wordt verwerkt. Zowel de structuur van objecten als bewerkingen zijn opgenomen in klassedefinities.
Compatibiliteit met programmeertalen
De kernconcepten van objectgeoriënteerde databases worden gebruikt inals ontwerptools en gecodeerd om met de database te werken.
Er zijn verschillende mogelijke talen waarin deze concepten kunnen worden geïntegreerd:
- Uitbreiding van een taal voor gegevensverwerking zoals SQL door complexe typen en OOP toe te voegen. Systemen bieden objectgeoriënteerde uitbreidingen van relationele systemen, objectgeoriënteerde relationele systemen genoemd.
- Een bestaande objectgeoriënteerde programmeertaal gebruiken en deze uitbreiden om met databases te werken. Ze worden persistente programmeertalen genoemd en stellen ontwikkelaars in staat om direct met gegevens te werken zonder een gegevensverwerkingstaal zoals SQL te hoeven doorlopen. Ze worden persistent genoemd omdat de gegevens blijven bestaan na het einde van het programma waarmee ze zijn gemaakt.
Houd er rekening mee dat hardnekkige talen vaak krachtig zijn en dat het relatief eenvoudig is om programmeerfouten te maken die de database beschadigen wanneer je beslist welke optie je wilt gebruiken. De complexiteit van talen maakt automatische optimalisaties op hoog niveau, zoals het verminderen van schijf-I/O, moeilijk. In veel toepassingen is de mogelijkheid om declaratieve zoekopdrachten te maken belangrijk, maar persistente talen staan dergelijke zoekopdrachten momenteel niet zonder problemen toe.
Hiërarchie van overervingstypen
Objectgeoriënteerde databaseschema's vereisen doorgaans een groot aantal klassen. Verschillende klassen lijken echter op elkaar. Om een directe weergave van de overeenkomsten tussen hen mogelijk te maken, moet u zettenze in een hiërarchie van specialisaties. Dit concept is vergelijkbaar met ER-modellen. Klassespecialisaties worden subklassen genoemd, die aanvullende attributen en methoden voor een bestaande klasse definiëren. Objecten die met subklassen zijn gemaakt, erven alles van de ouder. Sommige van deze overgeërfde kenmerken zijn mogelijk zelf ontleend aan degenen die hoger in de hiërarchie staan.
Objecten worden als complex beschouwd omdat ze veel opslagruimte nodig hebben en geen deel uitmaken van de standaard gegevenstypen die Object Oriented Database Management (OODBS) gewoonlijk biedt. Omdat de grootte van objecten aanzienlijk is, kan SOOBMS een deel van een object ontvangen en dit aan een toepassing verstrekken voordat het volledige object wordt verkregen. Het kan ook buffer- en cachemethoden gebruiken om delen van een object van tevoren op te halen, voordat een toepassing er toegang toe heeft.
OODB stelt gebruikers in staat om nieuwe typen te creëren die zowel structuur als bewerkingen bevatten, in dit geval het uitbreidbare typesysteem. U kunt bibliotheken van nieuwe typen maken door hun structuur en bewerkingen te definiëren. Velen van hen kunnen een groot gestructureerd object opslaan en ontvangen in de vorm van strings en karakters of bits, die "as is" worden doorgegeven aan het applicatieprogramma voor interpretatie.
De methode heeft rechtstreeks toegang tot de attributen van het doelobject op naam, inclusief alle geërfde van bovenliggende klassen, maar moet toegang hebben tot attributen van andere objecten met secundaire signalen. Het concept stelt u in staat om dezelfde operatornaam of hetzelfde symbool te associëren met:twee of meer verschillende implementaties ervan, afhankelijk van het type objecten waarop het van toepassing is.
Apps bouwen
Veel database-applicaties die OO-systemen gebruiken, vereisen meerdere versies van hetzelfde object. Doorgaans worden onderhoudsactiviteiten toegepast op een softwaresysteem wanneer hun vereisten veranderen, en dit omvat het wijzigen van enkele van de ontwikkelings- en implementatiemodules. Als het systeem al draait en als een of meer modules moeten worden gewijzigd, moet de ontwikkelaar van elk ervan een nieuwe versie maken door wijzigingen aan te brengen.
Merk op dat er meer dan twee versies van een object kunnen zijn, voor het geval er twee nodig zijn naast de originele module. Eigen versies van dezelfde softwaremodule kunnen tegelijkertijd worden geüpdatet. Dit wordt parallel objectgeoriënteerd databaseontwerp genoemd. Er komt echter altijd een punt waarop ze moeten worden samengevoegd zodat de hybride OODB de aangebrachte wijzigingen kan opnemen, zodat ze compatibel zijn.
Object-georiënteerde voorwaarden
Alle computersystemen moeten eigenschappen van hun architectuur hebben om in overweging te worden genomen. Een systeem moet bijvoorbeeld tabellen hebben om als relationeel te worden beschouwd. OODB is geen uitzondering en bevat enkele basiseigenschappen van de objectarchitectuur. In de echte wereld worden echter veel van deze eigenschappen besproken en sommige, zoals meervoudige overerving, worden beschouwd als verbeteringen aan het objectgeoriënteerde databasemodel in plaats vanals onderdeel van de basislijn. In de objectgeoriënteerde taal Smalltalk wordt bijvoorbeeld meervoudige overerving niet ondersteund, ook al wordt dit beschouwd als onderdeel van de objectarchitectuur.
Methoden voor een klasse definiëren een reeks bewerkingen die op een object kunnen worden uitgevoerd. Wanneer het bijvoorbeeld op een object wordt toegepast, retourneert het een waarde of voert het een bewerking uit om de waarden bij te werken. Soms retourneren methoden het niet. Als de methode was ontworpen om het aantal passagiers voor een voertuig bij te werken, zou er geen waarde worden geretourneerd, maar het gegevenselement in het doel zou dit veranderen.
Objecten zijn een fundamenteel concept in OODB. In wezen zijn objecten een abstracte weergave van de dingen uit de echte wereld die erin zijn opgeslagen. Een object is een instantie van een klasse in die zin dat het is uitgesloten van zijn definitie.
Je kunt een object zien als een op zichzelf staand pakket dat uit drie delen bestaat:
- Eigen persoonlijke informatie, gegevenswaarden.
- Privéprocedures die waarden manipuleren via de klassendefinitie.
- Open interface zodat dit object met anderen kan communiceren.
OODB-voorbeelden
Het gebruik van OODB vereenvoudigt de conceptualisering omdat het natuurlijker is om de informatie weer te geven die moet worden opgeslagen. Om de structuur of logica van een database te modelleren, kunt u met behulp van klassendiagrammen klassen introduceren met hun structurele relaties en overerving. Om een deel van de dynamiek, interactie engedrag tussen objecten, zal een sequentiediagram worden gebruikt om de interactie weer te geven tussen objecten die zich in een tijdelijke relatie bevinden, waarbij de mogelijke toestanden worden beschreven, zodat ze kunnen worden gevonden met de gewijzigde toestand nadat de gebeurtenis heeft plaatsgevonden.
Een voorbeeld van een objectgeoriënteerde database wordt hieronder getoond.
Ze hebben een naam en een leven lang, dat tijdelijk of permanent kan zijn. De OODB-sleutel is de mogelijkheid die ze de ontwikkelaar bieden om te specificeren hoeveel structuren en bewerkingen erop worden toegepast. Er is flexibiliteit en ondersteuning voor het omgaan met complexe gegevenstypen. U kunt klassen en subklassen maken, het klantenbestand kan bijvoorbeeld een subklasse van de link van deze klant hebben en het zal alle attributen en kenmerken van de originele klasse erven. Met deze aanpak kunt u snel en flexibel complexe gegevens verwerken.
