Gegevenspresentatiemodellen: een objectgeoriënteerd model.

Het eerste geformaliseerde en algemeen aanvaarde datamodel was het relationele model van Codd. In dit model werden, zoals in al het volgende, drie aspecten onderscheiden: structureel, holistisch en manipulatief. Datastructuren in het relationele model zijn gebaseerd op vlakke genormaliseerde relaties, integriteitsbeperkingen worden uitgedrukt met behulp van eerste-orde logica, en ten slotte wordt datamanipulatie uitgevoerd op basis van relationele algebra of de equivalente relationele calculus. Zoals veel onderzoekers opmerken, heeft het relationele gegevensmodel veel van zijn succes te danken aan het feit dat het vertrouwde op het rigoureuze wiskundige apparaat van verzamelingenleer, relaties en eerste-orde logica. De ontwerpers van een bepaald relationeel systeem voelden het als hun plicht om aan te tonen dat hun specifieke datamodel overeenkwam met het algemene relationele model, dat fungeerde als een maatstaf voor de 'relationaliteit' van het systeem.

De belangrijkste moeilijkheden van objectgeoriënteerde datamodellering vloeien voort uit het feit dat er niet zo'n ontwikkeld wiskundig apparaat is waarop een algemeen objectgeoriënteerd datamodel zou kunnen vertrouwen. Daarom is er in grote mate nog geen objectgericht basismodel. Aan de andere kant stellen sommige auteurs dat het algemene objectgeoriënteerde datamodel in klassieke zin niet kan worden gedefinieerd vanwege de ongeschiktheid van het klassieke concept van het datamodel voor het objectoriëntatieparadigma.

Een van de beroemdste datamodeltheoretici, Beeri, biedt een schets van een formeel raamwerk voor OODB, dat verre van compleet is en geen datamodel in de traditionele zin is, maar onderzoekers en ontwikkelaars van OODB-systemen in staat stelt om ten minste één taal te spreken (als, natuurlijk, zinnen Beeri zal worden ontwikkeld en ondersteund). Ongeacht het verdere lot van deze voorstellen, achten wij het nuttig ze kort samen te vatten.

Ten eerste wordt, in navolging van de praktijk van veel OODB's, voorgesteld om twee niveaus van objectmodellering te onderscheiden: lager (structureel) en hoger (gedragsmatig). Op structureel niveau worden complexe objecten, hun identificatie en "isa" communicatievarianten ondersteund. Een database is een verzameling gegevenselementen die zijn verbonden door de relatie "zit in een klasse" of "is een attribuut". De DB kan dus worden beschouwd als een gerichte grafiek. Een belangrijk punt is om, samen met het concept van een object, het concept van waarde te behouden (later zullen we zien hoeveel hieraan wordt gebouwd in een van de succesvolle O2 objectgeoriënteerde DBMS).

Een belangrijk aspect is een duidelijke scheiding tussen het databaseschema en de database zelf. De primaire concepten van het OODB-schemaniveau zijn typen en klassen. Opgemerkt wordt dat in alle systemen die slechts één concept gebruiken (ofwel een type of een klasse), dit concept onvermijdelijk overbelast raakt: een type veronderstelt de aanwezigheid van een bepaalde reeks waarden bepaald door de datastructuur van dit type; een klasse gaat ook uit van een set objecten, maar deze set is door de gebruiker gedefinieerd. Typen en klassen spelen dus verschillende rollen, en voor nauwkeurigheid en ondubbelzinnigheid moeten beide concepten tegelijkertijd worden ondersteund.

Beeri presenteert geen volledig formeel model van het structurele OODB-niveau, maar spreekt het vertrouwen uit dat het huidige niveau van begrip voldoende is om een \u200b\u200bdergelijk model te formaliseren. Wat het gedragsniveau betreft, wordt alleen een algemene benadering van het hiervoor benodigde logische apparaat voorgesteld (de logica van het eerste niveau is niet voldoende).

Een belangrijke, zij het onvoldoende onderbouwde, aanname van Beeri is dat de twee traditionele lagen - schema en data - niet voldoende zijn voor OODB. Om een \u200b\u200bOODB nauwkeurig te definiëren, is een metaschema-niveau vereist, waarvan de inhoud de soorten objecten en relaties moet definiëren die zijn toegestaan \u200b\u200bop het databaseschema-niveau. Het metaschema zou voor OODB's dezelfde rol moeten spelen als het structurele deel van het relationele gegevensmodel voor relationele databaseschema's.

Er zijn veel andere publicaties die betrekking hebben op het onderwerp objectgeoriënteerde datamodellen, maar ze raken ofwel vrij specifieke kwesties aan, of gebruiken een wiskundig apparaat dat te serieus is voor deze review (sommige auteurs definiëren bijvoorbeeld een objectgeoriënteerd datamodel op basis van categorietheorie).

Om de huidige stand van zaken te illustreren, zullen we kort ingaan op de kenmerken van een specifiek datamodel dat wordt gebruikt in het O2 objectgeoriënteerde DBMS (dit is natuurlijk ook geen datamodel in klassieke zin).

O2 ondersteunt objecten en waarden. Een object is een paar (identifier, waarde), en de objecten zijn ingekapseld, d.w.z. hun waarden zijn alleen toegankelijk via methoden - procedures die aan objecten zijn gebonden. Waarden kunnen atomair of structureel zijn. Structurele waarden worden opgebouwd uit waarden of objecten die worden voorgesteld door hun ID's met behulp van set-, tuple- en lijstconstructors. Structurele waardeleden worden benaderd met behulp van vooraf gedefinieerde bewerkingen (primitieven).

Er zijn twee soorten gegevensorganisatie: klassen, die worden geïnstantieerd door objecten die gegevens en gedrag inkapselen, en typen, waarvan de instanties waarden zijn. Elke klasse is gekoppeld aan een type dat de structuur van instanties van de klasse beschrijft. Typen worden recursief gedefinieerd op basis van atomaire typen en eerder gedefinieerde typen en klassen met behulp van constructors. De gedragszijde van een klasse wordt bepaald door een reeks methoden.

Objecten en waarden kunnen een naam krijgen. De naamgeving van een object of waarde hangt samen met zijn persistentie: alle benoemde objecten of waarden zijn persistent; elk object of elke waarde die deel uitmaakt van een ander genoemd object of waarde is duurzaam.

Met behulp van een speciale instructie die wordt gegeven bij het definiëren van een klasse, kunt u elk object van deze klasse langdurig opslaan. In dit geval genereert het systeem automatisch een ingestelde waarde waarvan de naam hetzelfde is als de klassenaam. Deze set bevat gegarandeerd alle objecten van deze klasse.

Methode - programmacode geassocieerd met een specifieke klasse en toepasbaar op objecten van deze klasse. De bepaling van de methode in O2 gebeurt in twee fasen. Eerst wordt de handtekening van de methode gedeclareerd, d.w.z. zijn naam, klasse, argumenttypen of klassen, en resultaattype of klasse. Methoden kunnen openbaar zijn (toegankelijk vanuit objecten van andere klassen) of privé (alleen toegankelijk binnen deze klasse). In de tweede fase wordt de implementatie van de klas in een van de O2-programmeertalen bepaald (talen worden in meer detail besproken in de volgende sectie van onze recensie).

Het O2-model ondersteunt overerving van meerdere klassen op basis van de supertype / subtype-relatie. De subklasse mag attributen en methoden toevoegen en / of overschrijven. De onduidelijkheden die mogelijk zijn met meervoudige overerving (in de naamgeving van attributen en methoden) worden opgelost door ofwel een nieuwe naam te geven, ofwel door de bron van overerving expliciet te specificeren. Een subklasseobject is het object van elke superklasse waarvan de subklasse is afgeleid.

De voorgedefinieerde klasse "Object" wordt ondersteund, wat de wortel is van het klassenrooster; elke andere klasse is een impliciete erfgenaam van de "Object" -klasse en erft vooraf gedefinieerde methoden ("is_same", "is_value_equal", enz.).

Een specifiek kenmerk van het O2-model is de mogelijkheid om aanvullende "exclusieve" attributen en methoden voor benoemde objecten te declareren. Dit betekent dat een bepaald genoemd representatief object van een klasse een type kan hebben dat een subtype is van het klassetype. Natuurlijk werken standaardklassemethoden niet met dergelijke attributen, maar aanvullende (of standaard) methoden kunnen specifiek voor een benoemd object worden gedefinieerd, waarvoor al aanvullende attributen beschikbaar zijn. Benadrukt wordt dat aanvullende attributen en methoden niet aan een specifiek object zijn gekoppeld, maar aan een naam, waarachter op verschillende tijdstippen, in het algemeen gesproken, verschillende objecten kunnen staan. De implementatie van exclusieve attributen en methoden vereist de ontwikkeling van late bindingstechnieken.

In de volgende sectie zullen we onder meer de kenmerken van de programmeertalen en queries van het O2-systeem bespreken, die natuurlijk nauw verband houden met de specifieke kenmerken van het datamodel.

Objectgeoriënteerd model

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

Het gestandaardiseerde objectgeoriënteerde model wordt beschreven in de aanbevelingen van de ODMG-93-standaard (Object Database Management Group - Objectgeoriënteerde databasebeheergroep). De aanbevelingen van ODMG-93 zijn nog niet volledig geïmplementeerd. Beschouw, om de belangrijkste ideeën te illustreren, een enigszins vereenvoudigd model van een objectgeoriënteerde database.

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

De waarde van een eigenschap van het type string is een tekenreeks. De waarde van een eigenschap van het 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. Object - een instantie van een klasse behoort tot zijn eigen klasse en heeft één ouder. Generieke relaties in de database vormen een samenhangende hiërarchie van objecten.

De logische structuur van een objectgeoriënteerde database lijkt uiterlijk op de structuur van een hiërarchische database. Het belangrijkste verschil tussen hen zit in de methoden van gegevensmanipulatie.

Om acties uit te voeren op gegevens in het beschouwde databasemodel, worden logische operaties 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 \u200b\u200bdatabase te maken).

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

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

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

Overerving daarentegen breidt de reikwijdte van het 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 is toegestaan \u200b\u200bom methoden (procedures of functies) met dezelfde namen te hebben in objecten van verschillende typen. Tijdens de uitvoering van een objectprogramma werken dezelfde methoden op verschillende objecten, afhankelijk van het type argument. Zoeken in een objectgeoriënteerde database bestaat uit het achterhalen van de overeenkomsten tussen het door de gebruiker opgegeven object en de objecten die in de database zijn opgeslagen. Een door de gebruiker gedefinieerd object, een doelobject genoemd (de objecteigenschap is van het type doel), kan in het algemeen een subset vertegenwoordigen van de volledige hiërarchie van objecten die in de database zijn opgeslagen. Het doelobject en het resultaat van de uitvoering van de query kunnen in de database zelf worden opgeslagen.

Het belangrijkste voordeel van het objectgeoriënteerde gegevensmodel 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 de hoge conceptuele complexiteit, het ongemak bij de gegevensverwerking en de lage zoeksnelheid.

Gegevenstypen

Aanvankelijk werden DBMS'en vooral gebruikt voor het oplossen van financiële en economische problemen. Tegelijkertijd werden, ongeacht het presentatiemodel, de volgende basisgegevenstypen in databases gebruikt:

numeriek. Voorbeelden van datawaarden: 0,43; 328; 2E + 5;
teken (alfanumeriek). Voorbeelden van datawaarden: "vrijdag", "string", "programmeur";
datums, gespecificeerd met behulp van het speciale datumtype of als normale tekengegevens. Voorbeelden van datawaarden: 1.12.97, 23/2/1999.

In verschillende DBMS'en kunnen deze typen onbeduidend van elkaar verschillen in naam, waardenbereik en type presentatie. Vervolgens begonnen gespecialiseerde gegevensverwerkingssystemen te verschijnen in nieuwe toepassingsgebieden, bijvoorbeeld geografische informatie, videobeeldverwerking, enz. In dit opzicht begonnen ontwikkelaars nieuwe gegevenstypen in traditionele DBMS te introduceren. De volgende zijn relatief nieuwe gegevenstypen:

tijd en datum-tijd, bedoeld voor het opslaan van informatie over tijd en (of) datum. Voorbeelden van datawaarden: 31/01/85 (datum), 9:10:03 (tijd), 6/03/1960 12:00 (datum en tijd);
tekenvariabelen van variabele lengte ontworpen om lange tekstinformatie op te slaan, zoals een document;
binair, bedoeld 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 de BMP-indeling (Bitmap) in de database kunt opslaan en automatisch kunt weergeven wanneer u met de database werkt;
hyperlinks die zijn ontworpen om links op te slaan naar verschillende bronnen (sites, bestanden, documenten enz.) die zich buiten de database bevinden, bijvoorbeeld op internet, bedrijfsintranet of op de harde schijf van een computer.

In moderne DBMS met verschillende datamodellen kunnen alle genoemde datatypes worden gebruikt.

Post-relationeelmodel-

Het klassieke relationele model gaat uit van de ondeelbaarheid van gegevens die zijn opgeslagen in de velden van tabelrecords. Het post-relationele model is een uitgebreid relationeel model dat de beperking op de ondeelbaarheid van gegevens wegneemt. Het model staat velden met meerdere waarden toe - velden waarvan de waarden bestaan \u200b\u200buit subwaarden. De set waarden voor velden met meerdere waarden wordt beschouwd als een onafhankelijke tabel, ingebed in de hoofdtabel.

In afb. 2.6 over het voorbeeld van informatie over facturen en goederen ter vergelijking wordt de presentatie van dezelfde gegevens met behulp van relationele (a) en post-relationele (b) modellen getoond. Uit de figuur blijkt dat, in vergelijking met het relationele model, het post-relationele model gegevens efficiënter opslaat en dat het tijdens de verwerking niet nodig is om gegevens uit twee tabellen samen te voegen.

Overhead Overhead-goederen

N factuur	Klant	N factuur	bedrag

Boven het hoofd

N factuur	Klant	bedrag

Figuur: 2.6. Relationele en post-relationele modelgegevensstructuren

Aangezien het post-relationele model het opslaan van niet-genormaliseerde gegevens in tabellen mogelijk maakt, is er een probleem met het waarborgen van de gegevensintegriteit en -consistentie. Dit probleem wordt opgelost door de juiste mechanismen in het DBMS op te nemen.

Waardigheidpost-relationeel model is het vermogen om een \u200b\u200breeks gerelateerde relationele tabellen weer te geven door één post-relationele tabel. Dit zorgt voor een hoge zichtbaarheid van de presentatie van informatie en een verhoging van de efficiëntie van de verwerking ervan.

Nadeelpost-relationeel model is de complexiteit van het oplossen van het probleem van het waarborgen van de integriteit en consistentie van opgeslagen gegevens.

Het beschouwde post-relationele datamodel wordt ondersteund door het uniVers DBMS. Andere DBMS'en gebaseerd op het post-relationele datamodel zijn ook Bubba en Dasdb.

Multidimensionaal model

De multidimensionale benadering van datapresentatie verscheen bijna gelijktijdig met de relationele benadering, maar de interesse in multidimensionale DBMS begon een enorm karakter te krijgen sinds het midden van de jaren 90. De aanzet in 1993 was een artikel van E. Codd. Het formuleerde 12 basisvereisten voor systemen van de OLAP-klasse (OnLine Analytical Processing - online analytische verwerking), waarvan de belangrijkste verband houden met de mogelijkheden van conceptuele weergave en verwerking van multidimensionale gegevens.

Bij de ontwikkeling van concepten van informatiesystemen kunnen de volgende twee richtingen worden onderscheiden:

Online (transactionele) verwerkingssystemen;

Analytische verwerkingssystemen (beslissingsondersteunende systemen).

Relationele DBMS'en zijn bedoeld voor informatiesystemen voor operationele informatieverwerking en zijn op dit gebied zeer effectief. In analytische verwerkingssystemen bleken ze wat onhandig en niet flexibel genoeg te zijn. Multidimensionale DBMS'en zijn hier efficiënter.

Multidimensionale DBMS zijn zeer gespecialiseerde DBMS die zijn ontworpen voor interactieve analytische verwerking van informatie. De belangrijkste concepten die in deze DBMS'en worden gebruikt, zijn: aggregeerbaarheid, historiciteit en voorspelbaarheid.

Aggregeerbaarheiddata betekent het bekijken van informatie op verschillende niveaus van generalisatie. In informatiesystemen hangt de mate van detail in de presentatie van informatie voor de gebruiker af van zijn niveau: analist, gebruiker, manager, manager.

Historiciteitdata impliceert het waarborgen van een hoog niveau van statische data zelf en hun relaties, evenals de verplichting om data aan de tijd te binden.

Voorspelbaarheiddata impliceert het instellen van prognosefuncties en deze toepassen op verschillende tijdsintervallen.

De multidimensionaliteit van het datamodel betekent niet de multidimensionaliteit van visualisatie van digitale data, maar de multidimensionale logische weergave van de structuur van informatie in de beschrijving en in de bewerkingen van datamanipulatie.

In vergelijking met het relationele model heeft de multidimensionale gegevensorganisatie een hogere zichtbaarheid en informatieve inhoud. Ter illustratie, Fig. 2.7 toont de relationele (a) en multidimensionale (b) representaties van dezelfde gegevens over het aantal autoverkopen.

De basisconcepten van multidimensionale datamodellen zijn dimensie en cel.

MetingIs een set gegevens van hetzelfde type dat een van de vlakken van de hyperkubus vormt. In een multidimensionaal model spelen dimensies de rol van indices om specifieke waarden in de cellen van een hyperkubus te identificeren.

CelIs een veld waarvan de waarde uniek wordt bepaald door een vaste set dimensies. Het veldtype wordt meestal gedefinieerd als numeriek. Afhankelijk van hoe de waarden van een bepaalde cel worden gevormd, kan het een variabele zijn (waarden veranderen en kunnen worden geladen vanuit een externe gegevensbron of programmatisch worden gegenereerd) of een formule (waarden, zoals formulecellen in spreadsheets, worden berekend met behulp van vooraf gedefinieerde formules).

Figuur: 2.7. Relationele en multidimensionale gegevensweergave

In het voorbeeld in Fig. 2,7 b elke celwaarde Verkoopvolumeuniek bepaald door de combinatie van tijdsdimensie Verkoop maanden automodel. In de praktijk zijn vaak meer metingen nodig. Een voorbeeld van een 3D-gegevensmodel wordt getoond in Fig. 2.8.

Figuur: 2.8. 3D-modelvoorbeeld

In bestaande multidimensionale DBMS'en worden twee hoofdschema's voor gegevensorganisatie gebruikt: hypercubisch en polycubisch.

IN polycubischhet schema gaat ervan uit dat meerdere hyperkubussen met verschillende afmetingen en met verschillende afmetingen als gezichten kunnen worden gedefinieerd in de database. Een voorbeeld van een systeem dat een polycubische versie van een database ondersteunt, is de Oracle Express Server.

Wanneer hyperkubischhet schema gaat ervan uit dat alle cellen worden gedefinieerd door dezelfde reeks metingen. Dit betekent dat als er meerdere hyperkubussen in de database zijn, ze allemaal dezelfde afmeting hebben en samenvallen.

De belangrijkste waardigheidmultidimensionaal datamodel is het gemak en de efficiëntie van analytische verwerking van grote hoeveelheden gegevens gerelateerd aan tijd.

Nadeelmultidimensionaal datamodel is de omslachtigheid ervan voor de eenvoudigste taken van conventionele operationele informatieverwerking.

Voorbeelden van systemen die multidimensionale datamodellen ondersteunen zijn Essbase, Media Multi - matrix, Oracle Express Server, Cache. Er zijn softwareproducten, zoals Media / MR, waarmee u tegelijkertijd met multidimensionale en relationele databases kunt werken.

Objectgeoriënteerd 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.

Het gestandaardiseerde objectgeoriënteerde model wordt beschreven in de aanbevelingen van de ODMG -93-standaard (Object Database Management Group).

Overweeg een vereenvoudigd objectgeoriënteerd databasemodel. De structuur van een objectgeoriënteerde database wordt grafisch weergegeven als 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 overeenkomstige klasse. Elke instantie van een klasse wordt beschouwd als een afstammeling van het object waarin deze is gedefinieerd als een eigenschap. Een instantieobject van een klasse behoort tot zijn klasse en heeft één ouder. Generieke relaties in de database vormen een samenhangende 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 type Bibliotheekis de ouder van klasse-instantieobjecten Abonnee, Catalogusen Kwestie... Diverse soorten objecten Boekenmaar ze kunnen een of verschillende ouders hebben. Objecten van type Boekdie dezelfde ouder hebben, moeten minstens verschillen in het inventarisnummer (uniek voor elk exemplaar van het boek), maar dezelfde eigenschapswaarden hebben is Bn, udk, namene en auteur.

De logische structuur van een objectgeoriënteerde database lijkt uiterlijk op de structuur van een hiërarchische database. Het belangrijkste verschil tussen de twee zijn de methoden voor gegevensmanipulatie.

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

Inkapselingbeperkt het bereik van de eigenschapsnaam tot de limieten van het object waarin het is gedefinieerd. Dus als een object van het type Catalogusvoeg een eigenschap toe die het telefoonnummer van de auteur van het boek instelt en een naam heeft telefoon, dan krijgen we eigenschappen met dezelfde naam voor objecten Abonneeen Catalogus... De betekenis van zo'n eigenschap wordt bepaald door het object waarin het is ingekapseld.

Erfenisomgekeerd breidt het de reikwijdte van het onroerend goed uit naar alle nakomelingen van het object. Dus alle objecten van het type Boekdie afstammelingen zijn van een object van het type Catalogus, kunt u eigenschappen toewijzen aan het bovenliggende object: isbn, udk, naamen auteur... Als het nodig is om de werking van het overervingsmechanisme uit te breiden tot objecten die geen directe verwanten zijn (bijvoorbeeld tussen twee afstammelingen van dezelfde ouder), dan wordt een abstracte eigenschap van het type gedefinieerd in hun gemeenschappelijke voorouder buikspieren... Dus de definitie van abstracte eigenschappen ticketen aantalin de faciliteit Bibliotheekzorgt ervoor dat deze eigenschappen worden overgeërfd door alle onderliggende objecten Abonnee, Boeken Uitgifteen. Het is geen toeval dat de waarden van ticketklassen Abonneeen Kwestiegetoond in Fig. 2.9 zijn hetzelfde - 00015.

Polymorfismein 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 namen te hebben in objecten van verschillende typen. Tijdens de uitvoering van een objectprogramma werken dezelfde methoden op verschillende objecten, afhankelijk van het type argument. Met betrekking tot dit voorbeeld betekent polymorfisme dat objecten van de klasse Boekmet verschillende ouders uit de klas Catalogus, kan een andere set eigenschappen hebben. Daarom programma's voor het werken met objecten van de klasse Boekkan polymorfe code bevatten.

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

Figuur: 2.9. De logische structuur van de bibliotheekdatabase

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

Nadelenhet objectgeoriënteerde model wordt gekenmerkt door een hoge conceptuele complexiteit, ongemak bij de gegevensverwerking en een lage zoeksnelheid.

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

Invoering

De opkomst van de richting van objectgeoriënteerde databases (OODB) werd allereerst bepaald door de behoeften van de praktijk: de noodzaak om complexe informatie-applicatiesystemen te ontwikkelen, waarvoor de technologie van eerdere databasesystemen niet geheel bevredigend was. OODB is natuurlijk niet helemaal opnieuw ontstaan. De overeenkomstige basis werd gelegd door zowel eerder werk op het gebied van databases als door de zich al lang ontwikkelde gebieden van programmeertalen met abstracte gegevenstypen en objectgeoriënteerde programmeertalen.

Wat betreft de relatie met het eerdere werk op het gebied van databases, was de meest krachtige invloed op het werk op het gebied van OODB de ontwikkeling van het DBMS en de daaropvolgende chronologisch volgende databasefamilie, waarin het beheer van complexe objecten werd ondersteund. Deze activiteiten vormden de structurele basis voor de OOBD-organisatie. In deze samenvatting komen OOMD en OODBMS aan bod.

Objectgeoriënteerd datamodel

Overweeg een van de benaderingen voor het bouwen van een database - met behulp van een objectgeoriënteerd datamodel (OOMD). Datamodellering 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.).

Objectgeoriënteerd datamodel ODMG, verschilt van andere modellen, voornamelijk in één fundamenteel aspect. In het SQL Data Model en het True Relational Data Model is een database een verzameling benoemde datacontainers van hetzelfde generieke type: respectievelijk tabellen of relaties. In het objectgeoriënteerde 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 in de objectgeoriënteerde taal van tools die zijn ontworpen om met de database te werken;

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

het creëren 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 zoektaal 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.

Onder de nadelen van OOMD moet worden gewezen op het ontbreken van een algemeen aanvaard model, gebrek aan ervaring met de oprichting en werking van OODB, de complexiteit van het gebruik en onvoldoende middelen voor gegevensbescherming.

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

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

De standaard OOM is beschreven in de aanbevelingen van de ODMG-93-standaard (Object Database Management Group - objectgeoriënteerde databasebeheergroep). De ODMG-93 aanbevelingen zijn nog niet volledig geïmplementeerd. Beschouw, om de belangrijkste ideeën te illustreren, een enigszins vereenvoudigd model van een objectgeoriënteerde database.

De structuur van de OO-database wordt grafisch weergegeven in de vorm van een boom, waarvan de knooppunten objecten zijn. De eigenschappen van objecten worden beschreven door een standaardtype (bijvoorbeeld een stringtype) of een door de gebruiker geconstrueerd type (gedefinieerd als een klasse).

De waarde van een eigenschap van het type string is een tekenreeks. De waarde van een eigenschap van het type class is een object dat een instantie is van de overeenkomstige klasse. Elke instantie van een klasse wordt beschouwd als een afstammeling van het object waarin deze is gedefinieerd als een eigenschap. Een instantieobject van een klasse behoort tot zijn klasse en heeft één ouder. Generieke relaties in de database vormen een gerelateerde hiërarchie van objecten.

Objectgeoriënteerd model

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

Laten we eens kijken naar een vereenvoudigd model van een objectgeoriënteerde database. De structuur van een objectgeoriënteerde database wordt grafisch weergegeven als 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 overeenkomstige klasse. Elke instantie van een klasse wordt beschouwd als een afstammeling van het object waarin deze als eigenschap is gedefinieerd. Een instantieobject van een klasse behoort tot zijn klasse en heeft één ouder. Generieke relaties in de database vormen een samenhangende 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 Library de ouder, bijvoorbeeld objecten van de klassen Subscriber, Directory en Issuance. Verschillende boekobjecten kunnen dezelfde of verschillende ouders hebben. Objecten van het type Boek die dezelfde ouder hebben, moeten ten minste verschillen door het inventarisnummer (uniek voor elk exemplaar van het boek), maar hebben dezelfde eigenschapswaarden isbn, udc, titel en auteur.

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

Inkapseling beperkt het bereik van een eigenschapsnaam tot het bereik van het object waarin deze is gedefinieerd. Dus als we een eigenschap toevoegen die het telefoonnummer van de auteur van het boek specificeert 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.

Omgekeerd breidt overerving de reikwijdte van de eigenschap uit tot alle nakomelingen van het object. Alle objecten van het type Boek die afstammen van een object van het type Catalogus kunnen dus 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 kinderen van dezelfde ouder), dan wordt een abstracte eigenschap van het type abs gedefinieerd in hun gemeenschappelijke voorouder. Dus de definitie van abstracte eigenschappen ticket en nummer in het Library-object leidt tot de overerving van deze eigenschappen door alle onderliggende objecten Abonnee, Boek en Uitgifte. Daarom is het geen toeval dat de waarden van de ticket-eigenschap van de abonnee- en uitgifteklassen getoond 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 namen 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 Book die andere ouders hebben dan de klasse Catalog, een andere set eigenschappen kunnen hebben. Bijgevolg kunnen programma's voor het werken met objecten van de klasse Book polymorfe code bevatten.

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

Figuur: 2.9 De logische structuur van de bibliotheekdatabase

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

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 onderverdeeld in staat en niet-staat. Naargelang de mate van toegankelijkheid maken ze onderscheid tussen publiek en met een beperkte kring van gebruikers.

Andere soorten classificatie worden geassocieerd met individuele BnD-componenten.

1. Ontwikkeling van databanken bestaat uit 4 fasen:

Fase 1. Opstellen en analyseren van systeemvereisten:

Er wordt een systeemspecificatie opgesteld, inclusief een lijst met taken die BND moet oplossen;

Lijst met eindgebruikers en hun functies;

Lijst met vereisten voor 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 best beschrijft in termen van de gebruiker.

Stap 3. Implementatieontwerp: 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 databank in de taal van een specifiek geselecteerd DBMS.

Stap 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, dat de gebruikte opslagapparaten beschrijft, methoden voor fysieke organisatie van gegevens. 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 bestaat uit 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 domein (bepalen van de behoeften van eindgebruikers, bouwen van een informatiemodel van het domein, identificeren van integriteitsbeperkingen);

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

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 onderhoudstechniek; ontwikkeling van formulieren voor gegevensinvoer; gegevensinvoer en controle;

5) gegevensbescherming (afbakening van gebruikers, selectie en verificatie van beveiligingsmaatregelen, registratie van ongeautoriseerde toegangspogingen);

6) zorgen voor databaseherstel;

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

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

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

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

3. Gebruikers van databanken

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

Ontwerp,

Implementatie,

Ondersteuning,

Update en ontwikkeling,

Volledige reorganisatie.

In elke fase van het bestaan \u200b\u200bzijn verschillende categorieën consumenten verbonden met de databank.

Eindgebruikers

Dit is de hoofdcategorie gebruikers wiens belangen 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 naar de database richten nadat ze wat informatie hebben ontvangen, en het kunnen regelmatige gebruikers zijn. Incidentele consumenten kunnen worden gezien als potentiële klanten van het bedrijf, die door een catalogus met prestaties of diensten bladeren met een algemene of gedetailleerde beschrijving. Werknemers die met speciaal voor hen ontworpen programma's werken en die zorgen voor automatisering van hun acties bij het uitvoeren van functies, kunnen gewone gebruikers zijn. Een beheerder die het werk van een hulpafdeling van een computerbedrijf plant, heeft bijvoorbeeld 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 nodige accessoires voor nieuwe bestellingen in het magazijn. De belangrijkste, bijzondere kennis die van eindgebruikers niet vereist mag worden op het gebied van taal en computertechnologie.

Databank beheerders

Dit is een groep gebruikers, die in de beginfase van de ontwikkeling van de databank verantwoordelijk is voor het optimale ontwerp ervan vanuit het oogpunt van de gelijktijdige werking van een set eindgebruikers, ter ondersteuning is de fase verantwoordelijk voor de juiste werking van deze informatiestapel in multi-user modus. Tijdens de ontwerp- en reorganisatiefase is deze groep ervoor verantwoordelijk dat de stapel correct kan worden gereorganiseerd 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 een groep applicaties te ontwikkelen, verenigd in een functioneel subsysteem. Ontwikkelaars voor specifieke applicaties werken met zoveel informatie uit de database als nodig is voor een specifieke applicatie.

Niet elke databank kan elk type gebruiker hebben geselecteerd. Het is bekend dat bij het ontwikkelen van informatiesystemen met behulp van een tabelvormig DBMS 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 grote onderneming te automatiseren, kunnen er echter ook applicatiebeheerteams en ontwikkelingsafdelingen zijn. De moeilijkste bedrijfsmodi zijn toegewezen aan de DBA-groep.

Laten we ze in meer detail bekijken.

Een deel van de BnD-beheerdersgroep zou moeten zijn:

Systeemcommentatoren;

Ontwikkelaars van datastructuren en uiterlijk met betrekking tot de informatie ondersteunende databank

Ontwikkelaars van technologische gegevensverwerkingsprocessen;

Systeem- en applicatieprogrammeurs;

Werkmaatschappijen en experts in de reparatieservice.

Commerciële databankkwestie speelt een belangrijke rol bij de verkoop van experts.

Hoofdfuncties van de groep DB Administrators

1. Onderzoek van het datagebied: beschrijving van het datagebied, 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 "datagebruikers", het bepalen van het tijdelijke volume van gegevensverwerkingskenmerken.

2. Ontwikkeling van de structuur van de database: de definitie van de samenstelling en de structuur van de databasebestanden en tussenliggende verbindingen, de keuze van optimalisatiemethoden voor data en toegangsmethoden voor informatie, de beschrijving van de database in de data description language (DL).

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

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

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

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

Ontwikkeling van procedures om de integriteit van de database te behouden bij het invoeren en bijwerken van gegevens;

Bepaling van integriteitsbeperkingen door parallelle werking van consumenten in multi-user modus.

4. Start het downloaden en begeleid de database

Ontwikkeling van een techniek voor het starten van het laden van de database, die zal verschillen van de procedure voor het wijzigen en toevoegen van gegevens tijdens regelmatig gebruik van de database;

Ontwikkeling van een techniek voor het controleren van de ingevoerde data, de werkelijke toestand van het datagebied. De werkelijke objecten van de databasemodellen van een gegevensgebied en de correlatie zijn tussenliggend, en op het moment van de start van de huidige reparatie moet dit model volledig overeenkomen met de toestand van de gegevensgebiedobjecten nu in de tijd;

Volgens de ontwikkelde techniek om het laden van het ontwerp van het systeem te starten, kan het starten van gegevensinvoer noodzakelijk zijn.

5. Gegevensbescherming

Het definiëren van een wachtwoordsysteem, de principes van het zich richten op consumenten, het creëren van groepen consumenten met identieke gegevenstoegangsrechten;

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

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

Testen van het beveiligingssysteem;

Onderzoek naar gevallen van schending van het beschermingssysteem en de ontwikkeling van dynamische methoden om informatie in de database te beschermen.

6. Ondersteuning voor databaseherstel

Ontwikkeling van principes voor archivering en herstel van databases;

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

7. Onderzoek van oproepen aan databasegebruikers: 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 de BnD:

Onderzoek naar de indices van het functioneren van de BnD

Planning herstructurering (structurele wijziging) van de database en reorganisatie van de database.

9. Werken met eindgebruikers:

Informatie verzamelen over het wijzigen van het gegevensgebied;

Verzamelen van informatie over de beoordeling van BnD-werk;

Consumententraining, consumentenraadpleging;

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

10. Voorbereiding en onderhoud van systeemtools:

Onderzoek van de 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 u deze op de BND aansluit;

Controle van de aansluiting van nieuwe software op BnD.

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

Een methode voor databaseontwikkeling kiezen of maken;

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

Planning van ontwikkelingsstadia van de BnD;

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.