Objectgeoriënteerd gegevensmodel

Het objectgeoriënteerde datamodel is een uitbreiding van de bepalingen van objectgeoriënteerd programmeren (terwijl het relationele model is ontstaan ​​op basis van de verzamelingenleer, juist als datamodel). De ODMG-93-standaard (Object DataBase Management Group) is ontwikkeld door de Object-Oriented Database Management Group. Deze standaard is nog niet volledig geïmplementeerd.

De structuur van een objectgeoriënteerde database wordt grafisch weergegeven in de vorm van een boom waarvan de knooppunten objecten zijn. De zichtbare structuur van een object wordt bepaald door de eigenschappen van zijn klasse. Klas omvat objecten, terwijl de structuur en het gedrag van objecten van dezelfde klasse hetzelfde zijn. Elk object, namelijk een instantie van een klasse, wordt beschouwd als een afstammeling van het object waarin het is gedefinieerd als een eigenschap. Objecteigenschappen- ofwel een standaardtype, zoals string, of een door de gebruiker geconstrueerde typeklasse. Het gedrag van objecten wordt ingesteld met behulp van methoden. Methode Is een bewerking die op een object kan worden toegepast.

Neem als voorbeeld de database "LIBRARY" (Fig.4.4). Voor elk object worden eigenschappen, hun typen en waarden gedefinieerd. In de DB:

"LIBRARY" - ouder (voorouder) voor "ABONNEMENT", "CATALOGUS", "PROBLEEM";

"CATALOGUS" is de ouder voor "BOEK".

"BOEK" - verschillende objecten kunnen dezelfde of verschillende ouders hebben. Indien dezelfde ouder (één auteur), dan zijn de inventarisnummers verschillend, maar isbn, UDC, titel en auteur hetzelfde.

De logische structuur van een objectgeoriënteerde database is vergelijkbaar met een hiërarchische, het belangrijkste verschil zit in de methoden van gegevensmanipulatie. Boven de database kunt u acties uitvoeren zoals logische bewerkingen, verbeterd door objectgeoriënteerde methoden van inkapseling, overerving en polymorfisme.

inkapseling beperkt het bereik van de eigenschapsnaam tot de limieten van het object waarin het is gedefinieerd. Dus, als de eigenschap wordt toegevoegd aan de "CATALOGUS" telefoon de auteur van het boek, dan verkregen op dezelfde manier in "ABONNEMENT" en "CATALOGUS". De betekenis van het eigendom wordt bepaald door het object waarin het is ingekapseld.

Erfenis omgekeerd, breidt de reikwijdte van de eigenschap uit naar alle nakomelingen van het object. Zo kunnen alle objecten van het type "BOEK" die afstammen van de "CATALOGUS" de eigenschappen van de bovenliggende isbn, UDC, naam en auteur krijgen.

Polyformisme betekent het vermogen van dezelfde programmacode om met verschillende soorten gegevens te werken. Met andere woorden, het betekent dat het in objecten van verschillende typen is toegestaan ​​om methoden - procedures en functies - met dezelfde naam te hebben. Tijdens de uitvoering van een objectprogramma werken dezelfde methoden op verschillende objecten, afhankelijk van het type argument. Voor de database "LIBRARY" betekent dit dat objecten van de klasse "BOOK" die verschillende ouders hebben dan de klasse "CATALOG", een andere set eigenschappen kunnen hebben, d.w.z. programma's voor het werken met een object van de klasse "BOOK" kunnen polymorfe code bevatten. In een klasse heeft een methode geen body, dat wil zeggen, er is niet gedefinieerd welke specifieke acties deze moet uitvoeren. Elke subklasse voert de vereiste bewerkingen uit. Inkapseling verbergt implementatiedetails van alle objecten buiten de gegeven hiërarchie.

De voordelen van het objectgeoriënteerde model in vergelijking met het relationele model zijn de mogelijkheid om informatie weer te geven over complexe relaties van objecten, de afwezigheid van beperkingen in gegevensopslagstructuren. Een objectgeoriënteerde database kan niet alleen de structuur, maar ook de gedragsaspecten van de gegevens opslaan. Met behulp van de objectgeoriënteerde benadering kunnen ook databases worden gemaakt met grote hoeveelheden semantische informatie, zoals multimedia en gespecialiseerd voor specifieke vakgebieden (geografisch, ontwerp, enz.).

De nadelen van deze aanpak zijn onder meer een hoge conceptuele complexiteit, ongemak bij de gegevensverwerking en een lage uitvoeringssnelheid van query's.

In de jaren 90 werden prototypes gemaakt van werkende objectgeoriënteerde databases. Dit zijn POET (POET SoftWare), JASMINE (COMPUTER ASSOCIATES), IRIS, ORION, POSTGRES.

Onderwerp 5

Relationele benadering bij het bouwen van een informatie-logisch model: basisconcepten

Relationeel datamodel. Basisconcepten

Zoals opgemerkt in de paragraaf van de vorige lezing, is het relationele model momenteel een van de meest voorkomende modellen in de databasemarkt. Dit model is gebaseerd op een reeks onderling verbonden tabellen (relaties).

De belangrijkste theoretische ideeën van het relationele model werden gepresenteerd in de werken over de theorie van relaties door de Amerikaanse logicus Charles Souders Peirce (1839-1914) en de Duitse logicus Ernst Schroeder (1841-1902), evenals de Amerikaanse wiskundige Edgar Codd .

In de werken van Peirce en Schroeder werd bewezen dat de reeks relaties wordt gesloten onder een aantal speciale bewerkingen die samen een abstracte algebra vormen. Deze belangrijkste eigenschap van relaties werd in het relationele model gebruikt om een ​​datamanipulatietaal te ontwikkelen.

In 1970 verscheen een artikel van E. Codd over de presentatie van gegevens georganiseerd in tweedimensionale tabellen, relaties genaamd. Codd was de eerste die de basisconcepten en beperkingen van het relationele model introduceerde als basis voor het opslaan van gegevens, en toonde de mogelijkheid van gegevensverwerking met behulp van traditionele bewerkingen op sets en speciaal geïntroduceerde relationele bewerkingen.

De basisconcepten van het relationele model worden gegeven in de tabel. 3.1.

De objecten van het relationele model zijn voornamelijk tabellen (relaties). De gegevensintegriteit wordt gewaarborgd door externe en primaire sleutels (zie p. "Relationele gegevensintegriteit").

Operators in het relationele model zijn een reeks instructies die gegevens ophalen en manipuleren.

Tabel 5.1. Elementen van het relationele model

Relationele modelterm	Beschrijving
Databank (DB)	Een set tabellen en andere objecten die nodig zijn om het geselecteerde onderwerpgebied abstract weer te geven
DB-schema	Een set tabelkoppen die aan elkaar gerelateerd zijn
Houding	Tabel - een reeks objecten van de echte wereld, die worden gekenmerkt door gemeenschappelijke eigenschappen en kenmerken (tabelvelden)
Relatiekoptekst	Tabelkop - de namen van de velden (kolommen) van de tabel
relatie lichaam	Tabellichaam - een verzameling waarden voor alle objecten in de echte wereld, die kunnen worden weergegeven als tabelrecords (tabelrijen)
Relatiediagram	Rij met tabelkolomkoppen (tabel "header")
Relatiekenmerk	Naam tabelkolom (tabelveld)
relatie tupel	Tabelrij (Record) - Een ondubbelzinnige weergave van een object uit de echte wereld gemaakt met behulp van de waarden van de tabelvelden
Domein	Veel geldige kenmerkwaarden
Attribuutwaarde	Veldwaarde in record (tupel)
Hoofdsleutel	Een of meer (in het geval van een samengestelde sleutel) attributen die op unieke wijze de waarde van de tuple definiëren (de waarde van de tabelrij)
Externe sleutel	Een tabelkenmerk waarvan de waarden overeenkomen met de waarden van de primaire sleutel in een andere gerelateerde (bovenliggende, primaire) tabel. Een externe sleutel kan bestaan ​​uit een of meerdere attributen (samengestelde externe sleutel). Als het aantal refererende sleutelattributen kleiner is dan het aantal attributen van de corresponderende primaire sleutel, dan wordt dit een afgekapte (gedeeltelijke) refererende sleutel genoemd
De mate (ariteit) van de relatie	Aantal tabelkolommen
De kracht van de relatie	Aantal rijen (tupels) van de tabel
Relatie-instantie	De reeks records (tupels) voor een bepaalde tabel (relatie). De instantie kan in de loop van de tijd veranderen. Aangezien een gewone database momenteel met slechts één versie van de relatie werkt, wordt zo'n instantie van de relatie de huidige genoemd.
Data type	Waardetype van tabelelementen
basisrelatie	Relatie die een of meer kolommen bevat die de eigenschappen van het object karakteriseren, evenals de primaire sleutel
Afgeleide verhouding	Het is geen basisrelatie, d.w.z. kenmerkt geen objecteigenschappen en wordt gebruikt om koppelingen tussen andere tabellen te maken, mag geen primaire sleutel bevatten. Als een primaire sleutel is opgegeven, dan bestaat deze uit externe sleutels die zijn gekoppeld aan de primaire sleutels van de onderliggende relatie
Verbinding	Brengt een relatie tot stand tussen overeenkomende waarden in sleutelvelden - de primaire sleutel van de ene tabel en de externe sleutel van een andere
Een-op-een relatie (1: 1)	Bij gebruik van dit type relatie kan een record in de ene tabel maximaal één gekoppeld record in een andere tabel hebben. In beide tabellen moeten sleutelvelden primair zijn. Gebruikt voor het splitsen van tabellen met meerdere velden of gegevensbescherming op aanvraag
Een-op-veel-relatie (1: M)	Bij gebruik van dit type relatie kan elk record van één tabel overeenkomen met meerdere records van de tweede, maar elk record van de tweede tabel komt overeen met slechts één record van de eerste tabel. De primaire sleutel moet worden opgegeven in de eerste tabel en de externe sleutel in de tweede.
Veel-op-veel-relatie (N: M)	Met dit type relatie kan één record in de eerste tabel overeenkomen met meerdere records van de tweede tabel, maar één record van de tweede tabel kan overeenkomen met meerdere records van de eerste. De uniciteit van de sleutels voor dergelijke tabellen is niet vereist. Tijdens het ontwerpen van een databaseschema worden dergelijke koppelingen getransformeerd. Om dit te doen, moet u een hulprelatie introduceren waarmee u de veel-op-veel-relatie kunt vervangen door twee een-op-veel-relaties.

De datastructuur van het relationele model gaat uit van de representatie van het onderwerpgebied van het beschouwde probleem als een reeks onderling gerelateerde relaties.

In elke relatie kan de ene relatie fungeren als de belangrijkste (basis, ouder) en de andere - als ondergeschikte (afgeleid, kind). Om deze koppelingen te behouden, moeten beide relaties een set attributen bevatten waarmee ze gerelateerd zijn: in de hoofdrelatie is dit de primaire sleutel van de relatie (identificeert op unieke wijze de tupel van de hoofdrelatie); de ondergeschikte relatie moet een set attributen hebben die overeenkomt met de primaire sleutel van de hoofdrelatie. Hier is deze set attributen al een secundaire sleutel of externe sleutel, d.w.z. definieert de verzameling tupels van de afgeleide relatie, geassocieerd met een enkele tupel van de basisrelatie.

Veel onderling verbonden tabellen vormen db-schema.

Dus de houding R is een tweedimensionale tabel met enkele gegevens.

wiskundig N-aire relatie R Is een set van cartesiaans product D 1 × D 2 ×… × D n sets (domeinen) D 1, D 2, ..., D n(N≥1), niet noodzakelijk anders:

R D 1 × D 2 ×… × D n,

waar D 1 × D 2 ×… × D n- volledig cartesiaans product, d.w.z. een verzameling van alle mogelijke combinaties van elk n elementen, waarbij elk element uit zijn eigen domein wordt gehaald.

Domein is een semantisch concept dat kan worden gezien als een subset van de waarden van een bepaald gegevenstype met een specifieke betekenis.

Domeineigenschappen:

Het domein heeft een unieke naam (binnen de database),

Gedefinieerd op een eenvoudig gegevenstype of op een ander domein,

Kan een booleaanse voorwaarde hebben om een ​​subset van de gegevens te beschrijven die voor dit domein zijn toegestaan,

Draagt ​​een bepaalde semantische lading.

De belangrijkste betekenis van domeinen is dat ze vergelijkingen beperken: je kunt geen waarden van verschillende domeinen vergelijken, ook niet als ze hetzelfde datatype hebben.

Attribuut relatie is een paar van de vorm

<Имя_атрибута: Имя_домена>(of<ADVERTENTIE>).

Attribuutnamen zijn uniek binnen een relatie. Vaak zijn de attribuutnamen hetzelfde als de bijbehorende domeinnamen.

Een R, gedefinieerd over meerdere domeinen, bestaat uit twee delen: een koptekst en een hoofdtekst.

Relatiekoptekst- een vast aantal relatieattributen die het cartesiaanse product beschrijven van domeinen waarop de relatie is gespecificeerd:

(<A 1: D 1>, <A 2: D 2 >, …, <En N>).

De header is statisch: deze verandert niet tijdens het werken met de database.Als de relatie attributen heeft gewijzigd, toegevoegd of verwijderd, dan wordt een andere relatie verkregen. Zelfs met de naam opgeslagen.

Lichaam relatie bevat veel relatie-tupels.

Elk stoet is een set van paren van de vorm:

<Имя_атрибута: Значение атрибута>:

R(<A 1: Val 1>, <A 2: Val 2 >, …, <A n: Val n>).

zodanig dat de waarde Val i attribuut een i behoort tot het domein D i.

Het lichaam van een relatie is een verzameling tupels, dat wil zeggen een subset van het cartesiaanse product van domeinen. Het lichaam van een relatie is dus zelf een relatie in de wiskundige zin van het woord. De hoofdtekst van een relatie kan veranderen tijdens het werken met de database, aangezien tuples in de loop van de tijd kunnen veranderen, worden toegevoegd en verwijderd.

De relatie wordt meestal geschreven als:

R(<A 1: D 1>, <A 2: D 2 >, …, <En N>),

of afgekort: R(een 1, een 2, …, Een) of R.

Relatiediagram is een set relatieheaders die in de database zijn opgenomen, d.w.z. een lijst met attribuutnamen van een bepaalde relatie met een indicatie van het domein waartoe ze behoren:

SR =(een 1, een 2, …, Een), A i D i, l = 1, ..., nee.

Als attributen waarden aannemen uit hetzelfde domein, worden ze θ-vergelijkbaar genoemd, waarbij θ de set geldige vergelijkingen is die voor dit domein is gespecificeerd.

Als een domein bijvoorbeeld numerieke gegevens bevat, zijn alle vergelijkingsbewerkingen daarvoor geldig: θ == (=,<>,>=,<=,<,>). Maar zelfs voor domeinen die karaktergegevens bevatten, kunnen niet alleen vergelijkingsbewerkingen voor gelijkheid en ongelijkheid worden gespecificeerd. Als een lexicografische volgorde is gespecificeerd voor een bepaald domein, dan heeft het ook een volledige set vergelijkingsbewerkingen.

De schema's van de twee relaties worden genoemd equivalent als ze dezelfde graad hebben, en de volgorde van de attribuutnamen in de schema's mogelijk is, zodat vergelijkbare attributen op dezelfde plaatsen zullen staan, d.w.z. attributen die waarden uit hetzelfde domein aannemen.

Voor gelijkwaardige relaties wordt dus aan de volgende voorwaarden voldaan:

De aanwezigheid van hetzelfde aantal attributen;

De aanwezigheid van attributen met dezelfde namen;

De aanwezigheid van dezelfde strings in de relatie, aangezien de volgorde van de attributen kan verschillen;

Dit soort relaties zijn verschillende beelden van dezelfde relatie.

Relatie eigenschappen volgen direct uit de bovenstaande definitie van een relatie. Deze eigenschappen zijn in feite het verschil tussen relationele gegevensmodelrelaties en eenvoudige tabellen:

Het unieke van de naam van de relatie. De naam van de ene relatie moet verschillen van de naam van andere relaties.

Uniciteit van tuples. Er zijn geen identieke tuples in een relatie. Het lichaam van een relatie is inderdaad een verzameling tupels en kan, zoals elke verzameling, geen niet te onderscheiden elementen bevatten. Tabellen kunnen, in tegenstelling tot relaties, dezelfde rijen bevatten. Elke cel van een relatie bevat alleen een atomaire (ondeelbare) waarde.

Ongeordende tuples. Tupels zijn niet geordend (van boven naar beneden), aangezien de hoofdtekst van de relatie een set is en de set niet is geordend (ter vergelijking: de rijen in de tabellen zijn geordend). Dezelfde relatie kan worden weergegeven door verschillende tabellen, waarin de rijen in verschillende volgorde staan.

Stoornis van attributen. De attributen zijn niet geordend (van links naar rechts).

De uniciteit van de attribuutnaam binnen de relatie. Elk attribuut heeft een unieke naam binnen de relatie, waardoor de volgorde van de attributen er niet toe doet (ter vergelijking: de kolommen in de tabel zijn geordend). Deze eigenschap wijkt enigszins af van de wiskundige definitie van de relatie. Dezelfde relatie kan worden weergegeven door verschillende tabellen waarin de kolommen in verschillende volgorde staan.

Atomiciteit van attribuutwaarden. Alle attribuutwaarden zijn atomair. Dit volgt uit het feit dat de onderliggende attributen atomaire betekenissen hebben, dat wil zeggen dat elke triboot wordt geassocieerd met een reeks waarden (een afzonderlijk elementair type), de waarden van de attributen worden uit hetzelfde domein gehaald. Relatieschema's en tupels zijn sets, geen lijsten, dus de volgorde waarin ze worden gepresenteerd doet er niet toe. Ter vergelijking kan verschillende informatie in tabelcellen worden geplaatst: arrays, structuren, andere tabellen, enz.

Opmerking:

Uit de eigenschappen van de relatie volgt dat: niet alle de tabel kan een relatie zijn. Om een ​​bepaalde tabel een relatie te laten definiëren, is het noodzakelijk dat de tabel een eenvoudige structuur heeft (bevat alleen rijen en kolommen, en elke rij moet hetzelfde aantal velden hebben), de tabel mag geen identieke rijen, geen enkele kolom hebben van de tabel moet gegevens van slechts één type bevatten, alle gebruikte gegevenstypen moeten eenvoudig zijn.

Opgemerkt moet worden dat het relationele model een database is in de vorm van een reeks onderling verbonden relaties, die worden genoemd relationeel databaseschema.

Objectgeoriënteerd gegevensmodel

Object-relationeel datamodel

Andere datamodellen

De toenemende complexiteit van databasetoepassingen en de beperkingen van het relationele model leidden tot de ontwikkeling van het Codd-model, ĸᴏᴛᴏᴩᴏᴇ eerst genoemd uitgebreid relationeel model, en kreeg later zijn ontwikkeling in het object-relationele datamodel. Databases die op deze modellen zijn gebaseerd, worden meestal generatie III genoemd.

Het Object Relational Data Model (ORMD) wordt geïmplementeerd met behulp van relationele tabellen, maar bevat objecten die lijken op het concept van een object in objectgeoriënteerd programmeren. ORMD maakt gebruik van objectgeoriënteerde componenten zoals door de gebruiker gedefinieerde gegevenstypen, inkapseling, polymorfisme, overerving, overschrijven van methoden, enzovoort.

Helaas zijn de ontwikkelaars tot nu toe niet tot een consensus gekomen over wat de ORMD zou moeten bieden. In 1999 . de SQL-99-standaard werd aangenomen, en in 2003 werd ᴦ. de tweede release van deze standaard werd uitgebracht, genaamd SQL-3, die de belangrijkste kenmerken van de ORMD definieert. Maar tot nu toe verschillen de object-relationele modellen die door verschillende DBMS-leveranciers worden ondersteund aanzienlijk van elkaar. De vooruitzichten van deze richting blijken uit het feit dat toonaangevende DBMS-fabrikanten, waaronder Oracle, Informix, INGRES en anderen, de mogelijkheden van hun producten hebben uitgebreid tot een object-relationeel DBMS (ORDBMS).

In de meeste implementaties van ORMD worden objecten herkend als een aggregaat en een tabel (relatie), die onderdeel kan zijn van een andere tabel. Gegevensverwerkingsmethoden worden weergegeven als opgeslagen procedures en triggers, die procedurele database-objecten zijn en zijn gekoppeld aan tabellen. Op conceptueel niveau worden alle gegevens in een object-relationele database weergegeven als een relatie en ondersteunt het ORDBMS de SQL-taal.

Een andere benadering voor het bouwen van een database is het gebruik van een objectgeoriënteerd datamodel (OOMD). Gegevensmodellering in OOMD is gebaseerd op het concept van een object. ODM wordt meestal gebruikt in complexe vakgebieden die de functionaliteit van het relationele model voor modellering missen (bijvoorbeeld voor ontwerpautomatiseringssystemen (CAD), publicatiesystemen, enz.).

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

• inbedding in de objectgeoriënteerde taal van middelen die bedoeld zijn om met een database te werken;
• 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 een database;
• creatie van een nieuwe taal en een nieuw objectgeoriënteerd datamodel

De voordelen van OOMD zijn onder meer ruime mogelijkheden voor het modelleren van het domein, expressieve querytaal en hoge prestaties. Elk object in de OOMD heeft een unieke identifier (OID - object identifier). Het ophalen van OID is aanzienlijk sneller dan het opzoeken van relationele tabellen.

Een van de nadelen van OOMD is het ontbreken van een algemeen geaccepteerd model, gebrek aan ervaring met het creëren en exploiteren van OODB, de complexiteit van het gebruik en onvoldoende middelen voor gegevensbescherming.

In 2000 . De werkgroep ODMG (Object Database Management Group), gevormd door de fabrikanten van OODBMS, heeft de volgende standaard (ODMG 3.0) voor OODBMS uitgebracht, die het objectmodel, de querydefinitietaal, de objectquerytaal en de verbindingstalen beschrijft C + +, Smalltalk en Java. ODMG-normen zijn niet officieel. De ODMG-benadering van standaardisatie is in wezen dat na de goedkeuring van de volgende versie van de standaard door de ODMG-lidorganisaties, een boek wordt gepubliceerd dat de tekst van de standaard bevat.

Laten we nu eens kijken hoe de ondersteuning van gegevensmodellen wordt geïmplementeerd in echte databasebeheersystemen.

Objectgeoriënteerd datamodel - concept en typen. Classificatie en kenmerken van de categorie "Objectgeoriënteerd datamodel" 2017, 2018.

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

Objectgeoriënteerde databases worden meestal aanbevolen voor die gevallen waarin een krachtige verwerking van gegevens met een complexe structuur vereist is.

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

Verplichte kenmerken

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

2. Ondersteuning van de eigenheid van objecten. Alle objecten moeten een unieke identifier hebben die niet afhankelijk is van de waarden van hun attributen.

3. Ondersteuning voor inkapseling. Correcte inkapseling wordt bereikt vanwege het feit dat programmeurs het recht hebben om alleen toegang te krijgen tot de interfacespecificatie van methoden, en de gegevens en implementatie van methoden zijn verborgen in objecten.

4. Ondersteuning voor typen en klassen. De OODB moet ten minste één concept van onderscheid tussen typen en klassen ondersteunen. (De term "type" is meer consistent met het concept van een abstract gegevenstype. In programmeertalen wordt een variabele gedeclareerd met een aanduiding van het type. De compiler kan deze informatie gebruiken om de bewerkingen die op de variabele worden uitgevoerd te controleren op compatibiliteit met het type, dat helpt om de correctheid van de software te garanderen. Aan de andere kant is een klasse een soort sjabloon voor het maken van objecten en biedt het methoden die op die objecten kunnen worden toegepast. Het concept van "klasse" is dus meer van een runtime in plaats van compile-time.)

5. Ondersteuning voor overerving 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 het binden van methodenamen op het systeem pas plaatsvinden op het moment dat het programma wordt uitgevoerd.

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

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

OO DBMS

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

Wel of niet toepassen van objectgeoriënteerde databasemanagementsystemen (OODBMS) in echte projecten vandaag de dag? In welke gevallen moeten ze worden gebruikt en in welke gevallen niet?

Hier Voordelen met behulp van OODBMS:

· Er is geen probleem van mismatch tussen het datamodel in de applicatie en de database (impedantiemismatch). Alle gegevens worden in dezelfde vorm als in het applicatiemodel in de database opgeslagen.

· Het is niet nodig om het datamodel apart te ondersteunen aan de DBMS-zijde.

· Alle objecten op gegevensbronniveau zijn sterk getypt. Geen string-kolomnamen meer! Het refactoren van een objectgeoriënteerde database en de code die ermee werkt, is nu geautomatiseerd, in plaats van een vervelend en saai proces.

ODMG-standaard

eerste manifest formeel was slechts een artikel ingediend bij Conferentie over objectgeoriënteerde en deductieve databases door een groep individuen. Zoals je in de vorige paragraaf kunt zien, waren de vereisten van het Manifest eerder emotioneel dan expliciet gespecificeerd. In 1991 werd het ODMG-consortium gevormd (toen werd deze afkorting bekendgemaakt als: Objectdatabasebeheergroep, maar kreeg later een bredere interpretatie - Objectgegevensbeheergroep). Het ODMG-consortium is nauw verwant aan het veel grotere OMG-consortium ( Object Management Groep), die twee jaar eerder werd opgericht. Het belangrijkste oorspronkelijke doel van ODMG was het ontwikkelen van de industriestandaard voor objectgeoriënteerde databases (gemeenschappelijk model). Het basisobjectmodel OMG COM ( Kernobjectmodel). In de loop van meer dan een decennium heeft ODMG drie basisversies van de standaard gepubliceerd, waarvan de laatste ODMG 3.0 heet. 16

Ironisch genoeg, hoewel de ODMG (naar de mening van de auteur) buiten de OMG valt, hebben sommige OMG-normen de afgelopen jaren vertrouwd op het ODMG-objectmodel. Met name de OCL-taalspecificatie ( Objectbeperkingstaal), die deel uitmaakt van de algemene taalspecificatie UML 1.4 (en UML 2.0). In dit artikel zijn we niet van plan een gedetailleerde vergelijking van de OMG- en ODMG-benaderingen uit te voeren en geïnteresseerde lezers door te verwijzen naar: Encyclopedieën van Kogalovsky en materialen van de websites van deze consortia. We zullen ons beperken tot een korte samenvatting van de belangrijkste ideeën in de ODMG-3-standaard.

ODMG-architectuur

De voorgestelde ODMG-architectuur wordt getoond in Fig. 2.1. Deze architectuur definieert een manier om gegevens op te slaan en verschillende soorten gebruikerstoegang tot deze "gegevensopslag" 17. Een enkele gegevensopslag is toegankelijk vanuit een gegevensdefinitietaal, een querytaal en een aantal gegevensmanipulatietalen. 18 Op afb. 2.1 OAO betekent: 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 de OODBMS worden beheerd, zijn opgeslagen. Objectdefinitietaal, querytaal en manipulatietalen zijn zo ontworpen dat al hun mogelijkheden afhankelijk zijn van 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 worden geleverd in een objectgeoriënteerd raamwerk en consistent met de gegevens moeten worden opgeslagen.

De belangrijkste componenten van de architectuur zijn als volgt.

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

• Gegevensdefinitietaal (ODL). Databaseschema's worden beschreven in termen van de OAO-taal, waarin gegevensmodelconstructies worden geïnstantieerd in de vorm van een definitietaal. Met OAO kunt u een schema beschrijven als een set objecttype-interfaces, die de beschrijving van type-eigenschappen en relaties daartussen omvat, evenals de namen van bewerkingen en hun parameters. OAO is geen volledige programmeertaal; de typen moeten worden geïmplementeerd in een van de talen van de OML-categorie. OAO is ook virtueel taal in die zin dat de ODMG-standaard niet vereist dat deze wordt geïmplementeerd in OODBMS-softwareproducten die geacht worden in overeenstemming te zijn met de standaard. Het is toegestaan ​​voor deze producten om equivalente definitietalen te ondersteunen die alle mogelijkheden van OAO bevatten, maar aangepast aan de specifieke kenmerken van een specifiek systeem. De aanwezigheid van de OAO-taalspecificatie in de ODMG-standaard is echter belangrijk omdat de taal de eigenschappen van het datamodel specificeert.

• Object Query Language (ODL). De taal heeft een syntaxis die lijkt op die van SQL, maar is gebaseerd op 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 gegevensmodel

Bijna alle moderne systemen zijn gebaseerd op relationeel(relationeel) databasebeheermodel. Naam relationeel hangt samen met het feit dat elk record in een dergelijke database informatie bevat die betrekking heeft op slechts één specifiek object.

V relationeel Alle verwerkte gegevens in het DBMS worden gepresenteerd in de vorm van platte tabellen. Informatie over objecten van een bepaald type wordt weergegeven in tabelvorm: verschillende attributen van objecten zijn geconcentreerd in de kolommen van de tabel, en rijen zijn bedoeld om beschrijvingen van alle attributen terug te brengen tot individuele exemplaren van objecten.

Het model dat in het stadium van de infologische modellering is gemaakt, voldoet grotendeels aan de relativiteitsprincipes. Om dit model echter om te zetten in een relationeel model, moet u een procedure uitvoeren met de naam normalisatie.

Normalisatietheorie werkt met vijf normale vormen... Deze formulieren zijn ontworpen om de redundantie van informatie te verminderen, zodat elke volgende normale vorm moet voldoen aan de vereisten van de vorige en enkele aanvullende voorwaarden. Bij praktisch databaseontwerp worden de vierde en vijfde vorm over het algemeen niet gebruikt. We hebben ons beperkt 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 verzameling van eigenschappen. Tijdens de infologische ontwerpfase hebben we gesproken over de abstractie van objecten en hebben we er enkele eigenschappen aan toegekend. Nu, met conceptueel ontwerp, gaan we naar het volgende abstractieniveau. In dit stadium bestaan ​​de objecten als zodanig niet meer. We werken met een set eigenschappen die het object definiëren.

Relatie-instantie- een reeks waarden van de eigenschappen van een bepaald object.

Hoofdsleutel- een identificerende set attributen, d.w.z. de waarde van deze attributen is in dit opzicht uniek. Er zijn geen twee instanties van een relatie met dezelfde waarde in de primaire sleutel.

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.

Entiteitsconcepten ..

Domein

Domein is specifieker voor databases, hoewel het enkele analogieën heeft met subtypen in sommige programmeertalen. In zijn meest algemene vorm wordt een domein gedefinieerd door een basisgegevenstype te specificeren waartoe de elementen van het domein behoren, en een willekeurige logische uitdrukking die wordt toegepast op het element van het gegevenstype. Als deze Booleaanse expressie true oplevert, is het gegevensitem een ​​domeinitem.

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

Let ook op de semantische belasting van het domeinconcept: gegevens worden alleen als vergelijkbaar beschouwd als ze tot hetzelfde domein behoren. In ons voorbeeld zijn de waarden voor de domeinen "Gap Numbers" en "Group Numbers" van het type integer, maar zijn niet vergelijkbaar. Merk op dat de meeste relationele DBMS'en het domeinconcept niet gebruiken, hoewel Oracle V.7 dit al ondersteunt.

Objectgericht model

In het objectgeoriënteerde model is het bij het presenteren van gegevens mogelijk om individuele databaserecords te identificeren. Er worden relaties gelegd tussen records en hun verwerkingsfuncties met behulp van mechanismen die vergelijkbaar zijn met die in objectgeoriënteerde programmeertalen.

Een gestandaardiseerd objectgeoriënteerd model wordt beschreven in de aanbevelingen van de ODMG-93 (Object Database Management Group) standaard.

Laten we een vereenvoudigd model van een objectgeoriënteerde database bekijken. De structuur van een objectgeoriënteerde database wordt grafisch weergegeven in de vorm van een boom waarvan de knooppunten objecten zijn. De eigenschappen van objecten worden beschreven door een standaard of door de gebruiker geconstrueerd type (gedefinieerd als een klasse). De waarde van een eigenschap van het type class is een object dat een instantie is van de corresponderende klasse. Elke instantie van een klasse wordt beschouwd als een afstammeling van het object waarin het als een eigenschap is gedefinieerd. Een instantieobject van een klasse behoort tot zijn klasse en heeft een enkele ouder. Generieke relaties in de database vormen een coherente hiërarchie van objecten. Een voorbeeld van de logische structuur van een objectgeoriënteerde bibliotheekdatabase wordt getoond in Fig. 2.9. Hier is een object van het type Bibliotheek de bovenliggende objecten van bijvoorbeeld de klassen Subscriber, Directory en Issuance. Verschillende boekobjecten kunnen dezelfde of verschillende ouders hebben. Objecten van het type Boek die dezelfde ouder hebben, moeten minimaal verschillen met het inventarisnummer (uniek voor elk exemplaar van het boek), maar hebben dezelfde eigenschapswaarden isbn, udc, titel en auteur.

De logische structuur van een objectgeoriënteerde database is uiterlijk vergelijkbaar met de structuur van een hiërarchische database. Het belangrijkste verschil tussen de twee is de methoden voor gegevensmanipulatie.

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

Inkapseling beperkt het bereik van een eigenschapsnaam tot de buitenkant van het object waarin deze is gedefinieerd. Dus als we een eigenschap toevoegen die het telefoonnummer van de auteur van het boek instelt en de naam phone heeft aan een object van het type Catalogus, dan krijgen we de eigenschappen met dezelfde naam voor de objecten Abonnee en Catalogus. De betekenis van zo'n eigenschap wordt bepaald door het object waarin het is ingekapseld.

Overerving daarentegen breidt de reikwijdte van het eigendom uit naar alle nakomelingen van het object. Zo kunnen alle objecten van het type Boek die afstammen van een object van het type Catalogus de eigenschappen van het bovenliggende object krijgen: isbn, udk, titel en auteur. Als het nodig is om het effect van het overervingsmechanisme uit te breiden tot objecten die geen directe verwanten zijn (bijvoorbeeld tussen twee nakomelingen van dezelfde ouder), dan wordt een abstracte eigenschap van het type abs gedefinieerd in hun gemeenschappelijke voorouder. De definitie van abstracte eigenschappen ticket en nummer in het bibliotheekobject leidt dus tot de overerving van deze eigenschappen door alle onderliggende objecten Abonnee, Boek en Uitgifte. Daarom is het geen toeval dat de waarden van de ticketeigenschap van de klassen Abonnee en Uitgifte, weergegeven in Fig. 2.9 zijn hetzelfde - 00015.

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 mogelijk is om methoden (procedures of functies) met dezelfde naam te hebben in objecten van verschillende typen. Tijdens de uitvoering van een objectprogramma werken dezelfde methoden op verschillende objecten, afhankelijk van het type argument. In dit voorbeeld betekent polymorfisme dat objecten van de klasse Boek die verschillende bovenliggende waarden hebben van de klasse Catalogus, een andere set eigenschappen kunnen hebben. Daarom kunnen programma's voor het werken met objecten van de klasse Book polymorfe code bevatten.

Zoeken in een objectgeoriënteerde database bestaat uit het vinden van de overeenkomst tussen het object, gespecificeerd door de gebruiker, en de objecten die in de database zijn opgeslagen.

Rijst. 2.9 De logische structuur van de bibliotheekdatabase

Het belangrijkste voordeel van het objectgeoriënteerde datamodel in vergelijking met het relationele model is de mogelijkheid om informatie weer te geven over complexe relaties tussen objecten. Met het objectgeoriënteerde gegevensmodel kunt u een enkel databaserecord identificeren en de functies van hun verwerking definiëren.

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

Objectgeoriënteerde DBMS'en omvatten POET, Jasmine, Versant, O2, ODB-Jupiter, Iris, Orion, Postgres.

Databanken als geheel worden doorgaans ingedeeld naar economische en juridische kenmerken.

Volgens de voorwaarden van de dienstverlening worden gratis en betaalde banken onderscheiden, die op hun beurt zijn onderverdeeld in commerciële en non-profit (wetenschappelijk, bibliotheek of maatschappelijk significant).

Volgens de eigendomsvorm zijn BND verdeeld in staat en niet-statelijk. Naar mate van toegankelijkheid maken ze onderscheid tussen publiek en met een beperkt aantal gebruikers.

Andere soorten classificatie worden geassocieerd met individuele componenten van BnD.

1. Ontwikkeling van databanken bestaat uit 4 fasen:

Fase 1. Opstelling en analyse van systeemvereisten:

Er wordt een systeemspecificatie opgesteld, inclusief een lijst van door BND op te lossen taken;

Lijst van eindgebruikers en hun functies;

Lijst van eisen aan de database;

Er wordt een documentstroomschema in de organisatie opgesteld.

Stage 2. Conceptueel ontwerp: er wordt een informatiemodel van het systeem gemaakt zonder verwijzing naar het type computer en het type systeemsoftware; er wordt een infologisch databasemodel gebouwd dat het vakgebied het meest volledig beschrijft in termen van de gebruiker.

Fase 3. Implementatie ontwerp: een computersysteem, systeemsoftware en een DBMS worden geselecteerd; de datastructuur wordt ontworpen en er wordt een databasedatalogisch model (databaseschema) gebouwd, dat een beschrijving is van de logische structuur van de database in de taal van een specifiek geselecteerd databasebeheersysteem.

Fase 4. Fysieke implementatie, waaronder het maken en laden van gegevens in een database, het ontwikkelen en debuggen van applicatieprogramma's voor het werken met een database, het schrijven van documentatie. In dit stadium wordt een fysiek model van de database gebouwd, waarin de gebruikte opslagapparaten en methoden voor de fysieke organisatie van gegevens worden beschreven. De beschrijving van de fysieke structuur van een database wordt een opslagschema genoemd. Momenteel is er een tendens om dit soort werk te verminderen.

2. De belangrijkste taken opgelost door het personeel van de databank

Het personeel van BND omvat verschillende specialisten: BND-beheerders, systeemanalisten, systeem- en applicatieprogrammeurs, operators, specialisten in technische middelen, marketing, enz.

Laten we een lijst maken van de belangrijkste functies en taken die door het personeel zijn opgelost tijdens de ontwikkeling en werking van de database:

1) analyse van het vakgebied (bepalen van de behoeften van eindgebruikers, bouwen van een informatiemodel van het vakgebied, identificeren van integriteitsbeperkingen);

2) het ontwerpen van de structuur van de database (bepalen van de samenstelling en structuur van de databasebestanden, het beschrijven van het schema in de databeschrijvingstaal);

3) het instellen van de database-integriteitsbeperkingen;

4) laden en onderhouden van de database (databaseonderhoud omvat het wijzigen, verwijderen en toevoegen van records); ontwikkeling van laad- en onderhoudstechnologie; ontwikkeling van formulieren voor het invoeren van gegevens; gegevensinvoer en controle;

5) gegevensbescherming (differentiatie van gebruikers, selectie en verificatie van beschermingsmiddelen, registratie van ongeautoriseerde toegangspogingen);

6) zorgen voor databaseherstel;

7) analyse van BnD-efficiëntie en systeemontwikkeling;

8) werken met gebruikers (antwoorden verzamelen, training);

9) onderhoud van systeemsoftware (aankoop, installatie en ontwikkeling);

10) organisatorisch en methodologisch werk (selectie van ontwerp- en moderniseringsmethoden, planning van de ontwikkeling van BND, ontwikkeling van documentatie).

3. Gebruikers van databanken

Zoals elk software-organisatorisch-technisch complex, bestaat een databank in tijd en ruimte. Het heeft specifieke ontwikkelingsstadia:

Ontwerp,

Implementatie,

Steun,

Update en ontwikkeling,

Volledige reorganisatie.

In elke bestaansfase zijn verschillende categorieën consumenten aangesloten op de databank.

Eindgebruikers

Dit is de hoofdcategorie van gebruikers wiens interesses gerelateerd zijn aan de databank. Afhankelijk van de kenmerken van de gecreëerde databank, kan deze wezenlijk verschillen in de kring van zijn eindgebruikers. Dit kunnen willekeurige consumenten zijn die de database van tijd tot tijd aanspreken op de database nadat ze wat informatie hebben ontvangen, en het kunnen ook gewone gebruikers zijn. Casual klanten kunnen worden gezien als potentiële klanten van het bedrijf, die door een catalogus van uitvoeringen of diensten bladeren met een algemene of gedetailleerde beschrijving. Werknemers die werken met programma's die speciaal voor hen zijn ontworpen en die zorgen voor automatisering van hun acties bij het uitvoeren van functies, kunnen gewone gebruikers zijn. Een beheerder die bijvoorbeeld het werk plant van een hulpafdeling van een computerbedrijf, heeft een programma dat hem helpt bij het plannen en rangschikken van lopende bestellingen volgens instructies, het bewaken van de voortgang van hun productiviteit en het organiseren van de benodigde accessoires voor nieuwe bestellingen in het magazijn. De belangrijkste, bijzondere kennis die eindgebruikers niet zouden moeten hebben op het gebied van taal en computertechnologie.

Databankbeheerders

Dit is een groep gebruikers, die in de beginfase van de ontwikkeling van de databank verantwoordelijk is voor het optimale ontwerp vanuit het oogpunt van de gelijktijdige werking van een reeks eindgebruikers, ter ondersteuning is het podium verantwoordelijk voor de juiste werking van deze stapel informatie in multi-user modus. Tijdens de ontwerp- en reorganisatiefase is deze groep verantwoordelijk voor het correct kunnen reorganiseren van de stack zonder het lopende onderhoud te wijzigen of af te ronden.

Applicatieontwikkelaars en -beheerders

Dit is een groep gebruikers die functioneert tijdens het ontwerp, de creatie en de reorganisatie van de databank. Applicatiebeheerders coördineren het werk van ontwikkelaars door een specifieke applicatie of groep applicaties te ontwikkelen, verenigd in een functioneel subsysteem. Ontwikkelaars voor specifieke applicaties werken met het stukje informatie uit de database dat nodig is voor een specifieke applicatie.

Niet elke databank heeft elk type gebruiker geselecteerd. Het is bekend dat bij de ontwikkeling van informatiesystemen die gebruikmaken van een DBMS in tabelvorm, de databankbeheerder, applicatiebeheerder en ontwikkelaar vaak in één persoon bestonden. Bij het maken van moderne, complexe bedrijfsdatabases die worden gebruikt om alle of grote delen van bedrijfsprocessen in een groot bedrijf of bedrijf te automatiseren, kunnen er echter groepen applicatiebeheerders en ontwikkelingsafdelingen zijn. De moeilijkste bedrijfsmodi worden toegewezen aan de groep databasebeheerders.

Laten we ze in meer detail bekijken.

Een deel van de BnD-beheerdersgroep zou moeten zijn:

Systeemcommentatoren;

Ontwikkelaars van datastructuren en uiterlijk mbt de informatieondersteunende databank;

Ontwikkelaars van technologische gegevensverwerkingsprocessen;

Systeem- en applicatieprogrammeurs;

Werkmaatschappijen en experts in de reparatieservice.

De vraag naar een commerciële databank speelt een belangrijke rol bij het verkopen van experts.

De belangrijkste functies van de groep DB-beheerders

1. Onderzoek van het gegevensgebied: beschrijving van het gegevensgebied, het verpakken van de tekst van integriteitsbeperkingen, het bepalen van de staat (beschikbaarheid, vertrouwelijkheid) van informatie, het bepalen van de behoeften van consumenten, het bepalen van de correspondentie van "gegevensconsumenten", het bepalen van de temporele hoeveelheid gegevensverwerkingskenmerken.

2. Ontwikkeling van de structuur van de database: de definitie van de samenstelling en de structuur van de databasebestanden en tussenverbindingen, de keuze van methoden voor het optimaliseren van gegevens en toegangsmethoden voor informatie, het beschrijven van de database in de databeschrijvingstaal (DL) .

3. Integriteitsbeperkingen instellen in de beschrijving van de databasestructuur en databaseverwerkingsprocedures:

Het instellen van declaratieve integriteitsbeperkingen die inherent zijn aan het gegevensgebied;

Bepaling van dynamische integriteitsbeperkingen die inherent zijn aan het gegevensgebied tijdens het wijzigen van de informatie die is opgeslagen in de database;

De definitie van integriteitsbeperkingen wordt genoemd door de structuur van de database;

Ontwikkeling van procedures voor het handhaven van de integriteit van de database bij het invoeren en corrigeren van gegevens;

Bepaling van integriteitsbeperkingen door parallelle werking van consumenten in multiuser-modus.

4. Start het downloaden en begeleid de database

Ontwikkeling van een techniek voor het initiëren van het laden van de database, die zal verschillen van de procedure voor het wijzigen en toevoegen van gegevens bij regelmatig gebruik van de database;

Ontwikkeling van een techniek voor het controleren van de ingevoerde gegevens, de werkelijke toestand van het gegevensgebied. De echte objecten van de databasemodellen van een bepaald gegevensgebied en de correlatie is tussenliggend, en op het moment dat de huidige reparatie begint, moet dit model volledig overeenkomen met de staat van de gegevensgebiedobjecten nu tegen de tijd;

Volgens de ontwikkelde techniek voor het initiëren van het laden van het ontwerp van het systeem, kan het initiëren van gegevensinvoer nodig zijn.

5. Gegevensbescherming

Het definiëren van een wachtwoordsysteem, principes voor het targeten van consumenten, het creëren van consumentengroepen met identieke gegevenstoegangsrechten;

Ontwikkeling van principes voor de bescherming van bepaalde gegevens en ontwikkelingsobjecten; ontwikkeling van gespecialiseerde methoden voor het coderen van informatie tijdens de verspreiding ervan in lokale en mondiale informatienetwerken;

Ontwikkeling van middelen om toegang tot gegevens en pogingen om het beveiligingssysteem te schenden, te herstellen;

Testen van het beveiligingssysteem;

Onderzoek naar gevallen van schending van het beveiligingssysteem en de ontwikkeling van dynamische methoden voor het beschermen van informatie in de database.

6. Ondersteuning voor databaseherstel

Ontwikkeling van principes voor het archiveren van organisatiemiddelen en databaseherstel;

Ontwikkeling van aanvullende software en technologische processen voor databaseherstel na storingen.

7. Onderzoek van oproepen naar databaseconsumenten: een reeks statistieken over het symbool van verzoeken, de tijd om hun prestaties in te schakelen, in overeenstemming met de vereiste uitvoerdocumenten

8. Onderzoek naar de efficiëntie van het functioneren van BnD:

Onderzoek naar de indices van BnD-functioneren

Plannen van herstructurering (structurele wijziging) van de database en reorganisatie van de BND.

9. Werken met eindgebruikers:

Het verzamelen van informatie over het wijzigen van het gegevensgebied;

Verzamelen van informatie over de beoordeling van BnD-werk;

Consumententraining; consumentenadvies;

Ontwikkeling van de nodige systematische en educatieve documentatie met betrekking tot het werk van eindgebruikers.

10. Voorbereiding en onderhoud van systeemtools:

Onderzoek van op de markt bestaande software en onderzoek naar de mogelijkheid en noodzaak van het gebruik ervan in het kader van BND;

Ontwikkeling van het benodigde organisatorische en technische bewegingsprogramma voor de ontwikkeling van BND;

De prestaties van de ingewisselde software controleren voordat deze wordt aangesloten op de BND;

Controle van de aansluiting van de nieuwe software op de BND.

11. Organisatorisch en systematisch werk bij de ontwikkeling van BND:

Selectie of creatie van een database-ontwikkelmethode;

Bepaling van doelen en richting van ontwikkeling van het systeem als geheel;

Planning van de stadia van BnD-ontwikkeling;

Ontwikkeling van naslagwerken voor algemene woordenboeken van het BND-project en een conceptueel model;

Installatie van externe modellen van ontwikkelde applicaties;

Controle van de aansluiting van de nieuwe applicatie op het werk van BND;

Mogelijkheid tot complexe probleemoplossing van een reeks toepassingen die samenwerken vanuit één database.