Helaas vond ik niet genoeg interessante artikelen over objectgeoriënteerde databases (OODB) op Habré. Ik wil dit onderwerp graag aankaarten, omdat... V De laatste tijd meer en meer er wordt gepraat over OOBD. Het is echter onmogelijk om alle informatie in één artikel te plaatsen, dus ik zal het eerst geven Korte beoordeling en mijn gedachten over dit onderwerp. In dit artikel zal ik geen specifieke oplossingen overwegen op basis van elke technologie, maar alleen proberen de technologieën zelf te vergelijken.

Achtergrond

Ik ontwerp en ontwikkel al ongeveer 6 jaar databases. Gedurende deze tijd ontwikkelde ik mijn eigen visie over hoe je ontwerp het beste kunt benaderen, hoe je een systeemarchitectuur kiest, welke functies er bestaan ​​bij het normaliseren en denormaliseren van relationele databases, hoe je bepaalde ontwerpen en queries kunt optimaliseren. In het eerste jaar dat ik werkte, kwam ik tot de conclusie dat ik me niet wilde bezighouden met de routine van het schrijven van dezelfde verzoeken. Als resultaat schreef ik mijn eigen opgeslagen proceduregenerator, die, gebaseerd op de structuur van de database, de meeste routinequery's genereerde (als het interessant is, kan ik een artikel over dit onderwerp schrijven). Vervolgens evolueerde deze generator van jaar tot jaar, en uiteindelijk kwam ik tot de noodzaak om objecten op te slaan zoals ze zijn, om niet de moeite te hoeven nemen om het objectmodel te vertalen naar relationele structuur. Die. Sterker nog, ik kwam om een ​​soort ORM-add-on te genereren. Je kunt natuurlijk zeggen dat er al voldoende hoogwaardige ORM-add-ons en object-relationele databases zijn gemaakt die met succes kunnen worden gebruikt (en ik ben het met je eens, maar met enig voorbehoud). Maar dat paste ook niet bij mij. En ik besloot verder te gaan.

Impact van ORM

In mijn bescheiden mening het gebruik van ORM-add-ons vertraagt ​​alleen de ontwikkeling van OODB. Ik zal proberen deze nogal controversiële verklaring te verduidelijken. Ik denk niet dat ORM slecht is, maar het is ook niet absoluut goed. ORM-technologie speelde ongetwijfeld (en speelt nog steeds) belangrijke rol bij de ontwikkeling van ontwikkelingstools bleek dat de programmeur zich misschien niet echt bekommert om de logica van gegevensopslag. Maar net als overal zijn er ook hier ‘MAAR’s’.

Het gebruik van ORM versnelt ongetwijfeld de productontwikkeling, verlaagt de arbeidskosten en bla bla bla. Elke ORM is echter een soort laag die altijd langzamer zal werken dan direct werk (ik pleit er geenszins voor om alles te verplaatsen SQL-aanroepen verzoeken aan de applicatie - er zou overal moeten zijn gouden gemiddelde). Door de aanwezigheid van een ORM hoeven ontwikkelaars niet te veel na te denken over de werking van het DBMS (en de meeste doen dat niet), wat, op zijn zachtst gezegd, een niet geheel optimale werking van de applicatie onder belasting met zich meebrengt. Om te optimaliseren moet je de diepte ingaan en queries configureren zodat ze sneller werken; je moet de database ingaan en indexen en tabellen opnieuw configureren. Dus voor Optimale werking bijlagen moeten worden bijgevoegd meer werk dan wanneer er geen ORM is. Als gevolg hiervan verlagen we de ontwikkelingskosten en versnellen we de release van de eerste versie van het product, maar compliceren we het optimalisatieproces.

Niemand denkt echter aan optimalisatie op het moment dat de eerste (en vaak de tweede en derde) versie van het product wordt geschreven. Voor de meeste bedrijven is de belangrijkste factor nu niet de kwaliteit, maar de snelheid van ontwikkeling. Dit is begrijpelijk: in eerste instantie wil de klant het product zo snel mogelijk ontvangen en zo min mogelijk geld uitgeven. En pas na enige tijd, wanneer de database gevuld is met echte gegevens, zijn er een paar maanden verstreken, de klant (en ook de ontwikkelaar) is verrast om te ontdekken dat de bemonsteringstijd bijna is verdubbeld, wanneer 10-20 gebruikers tegelijkertijd werken, het DBMS probeert zelfmoord te plegen, enz. . enzovoort. De ontwikkelaar laat zich vaak leiden door oosterse wijsheid: En dan zal óf de ezel sterven, óf de sultan, óf Khoja zelf. Maar als er niemand stierf, dan begint de ontwikkelaar hier naar knelpunten te zoeken, haalt hij automatisch gegenereerde queries uit de ORM, herschrijft ze met de hand, herbouwt de indexen in de databasetabellen en besteedt hier veel tijd en moeite aan. en soortgelijke optimalisatie.

Iets bracht mij opzij. Ik hoop dat ik mijn standpunt ten aanzien van ORM duidelijk genoeg heb gemaakt. Laten we teruggaan naar de vergelijking (of, als iemand dat liever heeft, de oppositie) van relationele en objectgeoriënteerde databases.

Relationele databases versus OODB

Ondanks de enorme populariteit van het OOP-paradigma in programmeren, is dit paradigma nog niet bijzonder populair in de. En daar zijn zowel objectieve als subjectieve redenen voor.

• Populariteit. Onder relationele databases Er zijn veel geweldige producten die moeten worden ondersteund en ontwikkeld. Er is al veel geld geïnvesteerd in deze producten en klanten zijn bereid meer geld te investeren in de ontwikkeling ervan. Integendeel, er zijn relatief weinig serieuze commerciële producten ontwikkeld met behulp van OODB’s, en er bestaan ​​maar weinig krachtige OODBMS’en.
• Querytaal en de standaardisatie ervan. In 1986 werd de eerste standaard SQL-86 aangenomen, die het hele lot van relationele databases bepaalde. Nadat de standaard was aangenomen, moesten alle relationele DBMS-ontwikkelaars deze volgen. Er bestaat nog geen standaard zoektaal voor objectgeoriënteerde databases. Er bestaat momenteel geen consensus onder ontwikkelaars over wat deze querytaal zou moeten doen, laat staan ​​hoe hij dat zou moeten doen.
• Wiskundige apparatuur. Voor relationele databases legde Edgar Codd in zijn tijd de basis voor een wiskundig apparaat relationele algebra. Deze maat. het apparaat legt uit hoe basisbewerkingen op relaties in de database moeten worden uitgevoerd, bewijst hun optimaliteit (of laat zien waar het nodig is om te optimaliseren). Aan de andere kant bestaat een dergelijk apparaat niet voor OOBD, ook al wordt er al sinds de jaren 80 op dit gebied gewerkt. Er zijn dus nog geen strikte termen in OODB, zoals Cartesisch product, relatie, enz.
• Het probleem van het opslaan van gegevens en methoden. Relationele databases slaan alleen ruwe gegevens op. Wat de applicatie ermee gaat doen, hangt af van de applicatie. In OODB moeten objecten daarentegen worden opgeslagen en is een object een verzameling van zijn eigenschappen (objectparameters) en methoden (objectinterface). Er bestaat hier ook geen consensus over hoe een OODB objecten moet opslaan en hoe een ontwikkelaar deze objecten moet ontwikkelen en ontwerpen. Hier doet zich het probleem voor van het opslaan van een hiërarchie van objecten, het opslaan van abstracte klassen, enz..

Conclusies en vooruitzichten

In het licht van de huidige situatie in de ontwikkelingswereld lijkt het vooruitzicht van de opkomst van serieuze en populaire oplossingen met behulp van OODB zeer twijfelachtig (maar niet minder wenselijk) totdat de fundamentele kwesties (wiskundig apparaat en standaard voor de querytaal) zijn opgelost. Als ontwikkelaar word ik hier enigszins verdrietig van, omdat ik tot de conclusie kwam dat de aanwezigheid van een krachtige en handige OODB simpelweg noodzakelijk is voor de verdere hoogwaardige ontwikkeling van database-ontwikkeltools.

Wat de vooruitzichten voor relationele databases betreft, denk ik dat ze nog een hele tijd zullen meegaan. OODB zal relationele databases nog steeds niet volledig kunnen vervangen. Bij sommige problemen uit het echte leven is het nog steeds handiger en correcter om gegevens niet in objecten, maar in tabellen op te slaan.

Ik geloof dus dat OODB in de loop van de tijd een stuk van de markt voor commerciële systemen zal winnen van relationele databases, maar dat ze niet zo'n groot voordeel kunnen behalen als relationele databases momenteel hebben.

DBMS is veel meer hoog niveau moeilijkheden. Het probeert de programmeur ervan te weerhouden iets te doen routinematige operaties over gegevensbeheer, zo kenmerkend voor hiërarchische en netwerkmodellen.

IN relationeel model database is een gecentraliseerde tabelopslag die beveiliging biedt gelijktijdige toegang op informatie van veel gebruikers. In tabelrijen bevatten sommige velden gegevens die rechtstreeks verband houden met de record, en andere bevatten koppelingen naar records van andere tabellen. Relaties tussen records zijn dus een inherente eigenschap van het relationele model.

Elk tabelitem heeft dezelfde structuur. In een tabel met beschrijvingen van auto's hebben alle records bijvoorbeeld dezelfde set velden: fabrikant, model, bouwjaar, kilometerstand, enz. Dergelijke tabellen zijn gemakkelijk weer te geven grafische vorm.

In het relationele model wordt informatieve en structurele onafhankelijkheid bereikt. De records zijn niet zo met elkaar verbonden dat het veranderen van één ervan gevolgen heeft voor de andere, en het veranderen van de databasestructuur leidt niet noodzakelijkerwijs tot een hercompilatie van de applicaties die ermee werken.

Relationele DBMS'en gebruiken de SQL-taal, waarmee u willekeurige, niet-gereguleerde zoekopdrachten kunt formuleren. Dit is de taal vierde generatie, zodat elke gebruiker snel kan leren hoe hij query's moet schrijven. Daarnaast zijn er veel applicaties waarmee je kunt bouwen logica verzoeken in grafische vorm. Dit alles gebeurt als gevolg van strengere eisen aan computerprestaties. Gelukkig modern computer kracht meer dan voldoende.

Relationele databases kampen met verschillen in de uitvoering SQL-taal, hoewel dit geen probleem is met het relationele model. Elk relationeel DBMS implementeert een subset van de SQL-standaard plus een reeks unieke opdrachten, wat de taak van programmeurs die proberen van het ene DBMS naar het andere te gaan, bemoeilijkt. ik moet doen moeilijke keuze tussen maximale tolerantie en maximale prestatie. In het eerste geval moet u zich houden aan de minimale gemeenschappelijke set opdrachten die in elk DBMS wordt ondersteund. In het tweede geval concentreert de programmeur zich eenvoudigweg op het werken in dit specifieke DBMS, waarbij hij profiteert van de unieke opdrachten en functies ervan.

MySQL is een relationeel DBMS en een echte opleiding cursus is gewijd aan de studie van het relationele model. Maar de databasetheorie staat niet stil. Er ontstaan ​​nieuwe technologieën die het relationele model uitbreiden.

Objectgeoriënteerde databases

Met een objectgeoriënteerde database (OODB) kunnen programmeurs die met talen van de derde generatie werken, al hun talen interpreteren informatie-entiteiten zoals voorwerpen die erin zijn opgeslagen werkgeheugen. Een extra front-end abstractielaag zorgt voor het onderscheppen van verzoeken die toegang krijgen tot delen van de database die permanent op schijf zijn opgeslagen. Wijzigingen aan objecten worden optimaal van het geheugen naar de schijf overgebracht.

Het voordeel van OODB is de vereenvoudigde code. Applicaties kunnen gegevens interpreteren in de context van de programmeertaal waarin ze zijn geschreven. Een relationele database retourneert de waarden van alle velden erin tekstvorm, en vervolgens worden ze teruggebracht tot lokale soorten gegevens. Bij OOBD is deze fase geëlimineerd. Technieken voor datamanipulatie blijven altijd hetzelfde, ongeacht of de data op schijf of in het geheugen staan.

Gegevens in een OODB kunnen de vorm aannemen van elke structuur die kan worden uitgedrukt in de gebruikte programmeertaal. Relaties tussen entiteiten kunnen ook willekeurig complex zijn. De OODB beheert de objectcachebuffer door objecten tussen de buffer en schijf opslag indien nodig.

Met behulp van OODB worden twee problemen opgelost. In de eerste plaats complex informatiestructuren worden daarin beter tot uitdrukking gebracht dan in relationele databases, en ten tweede wordt de noodzaak geëlimineerd om gegevens te vertalen vanuit het formaat dat door het DBMS wordt ondersteund. Bijvoorbeeld, binnen relationele DBMS De dimensie van gehele getallen kan 11 cijfers zijn, maar in de gebruikte programmeertaal is dit 16. De programmeur zal met deze situatie rekening moeten houden.

Objectgeoriënteerde DBMS'en vervullen veel extra functies. Dit loont de moeite als de relaties tussen de gegevens erg complex zijn. In dit geval zijn de prestaties van OODB hoger dan die van relationele DBMS. Als de gegevens minder complex zijn, extra functies blijken overbodig. Het dataobjectmodel ondersteunt ad-hocquery's, maar de querytaal is niet noodzakelijkerwijs SQL. Logische weergave gegevens voldoen mogelijk niet aan het relationele model, dus het gebruik van SQL wordt zinloos. Het is vaak handiger om objecten in het geheugen te verwerken door de juiste typen zoekopdrachten uit te voeren.

Het grote nadeel van objectgeoriënteerde databases is hun nauwe samenhang met de gebruikte programmeertaal. Gegevens die zijn opgeslagen in een relationeel DBMS zijn toegankelijk voor elke toepassing, terwijl een Java-object dat in een OODB is geplaatst bijvoorbeeld alleen van belang is voor toepassingen die in Java zijn geschreven.

Object-relationele databases

Object-relationele DBMS'en combineren de kenmerken van relationele en objectmodellen. Hun voorkomen wordt verklaard door het feit dat relationele databases werken goed met ingebouwde gegevenstypen en veel slechter met aangepaste, niet-standaard gegevenstypen. Wanneer er een nieuwe verschijnt belangrijk soort gegevens, moet u de ondersteuning ervan in het DBMS opnemen, of de programmeur dwingen de gegevens in de applicatie zelfstandig te beheren.

Niet alle informatie is zinvol om te worden geïnterpreteerd in de vorm van reeksen symbolen of cijfers. Laten we ons een muziekdatabase voorstellen. Een als audiobestand gecodeerd nummer kan in een tekstvak worden geplaatst grote maat, maar hoe zal het zoeken naar tekst in dit geval worden uitgevoerd?

Het opnieuw opbouwen van een DBMS om ondersteuning voor een nieuw gegevenstype op te nemen is dat niet de beste uitweg uit positie. In plaats daarvan kunt u met een object-relationeel DBMS code laden die is ontworpen om ‘atypische’ gegevens te verwerken. De database behoudt dus zijn tabelstructuur, maar de manier waarop sommige tabelvelden worden verwerkt, wordt extern bepaald, d.w.z. programmeur.

Momenteel domineren relationele DBMS'en onder datamanagementsystemen. De voordelen van de objectgeoriënteerde aanpak voor het creëren van complexe gespecialiseerde applicaties enerzijds, en de wens van ontwikkelaars van databasebeheersystemen anderzijds om het toepassingsgebied van de overeenkomstige DBMS'en uit te breiden opname van objectgeoriënteerde componenten (door de gebruiker uitbreidbaar typesysteem, inkapseling, overerving, polymorfisme, enz.) in het datamodel van een relationeel DBMS. Overeenkomstig DBMS, object-relationeel genoemd , op zichzelf combineren beste kwaliteiten relationele en objectgeoriënteerde databases. Merk op dat verschillende DBMS'en worden geïmplementeerd ander setje van de genoemde objectgeoriënteerde componenten. Er bestaat dus geen universeel geaccepteerd object-relationeel model, maar eerder meerdere van dergelijke modellen die een specifieke reeks objectgeoriënteerde componenten ondersteunen. Al dergelijke modellen zijn echter gebaseerd op relationele tabellen, gebruiken een zoektaal, bevatten het concept van een object en sommige implementeren bovendien de mogelijkheid om methoden in een database op te slaan.

Overeenkomstige veranderingen in het relationele model maakten de uitbreiding van de taalstandaard noodzakelijk SQL-query's. De eerste versie van deze standaard heette SQL3. Het werk aan de standaard gaat tot op de dag van vandaag door.

Als voorbeeld van een maximaal objectgeoriënteerd DBMS kunnen we wijzen op het onderzoek DBMS Postgres(3).

Laten we de elementen van het DBMS noteren die als objectextensies worden beschouwd Microsoft-server 2008.

· Aangepaste extensies. Gebruikers hebben de mogelijkheid om zich te bemoeien met de tools die aanvankelijk door het DBMS werden geboden, en met name nieuwe te creëren aangepaste typen gegevens.

· Opslag van grote hoeveelheden gegevens. Samen met de gegevens die traditioneel in de database werden opgeslagen, Microsoft SQL Met Server 2008 kunt u gegevens in tabelkolommen opslaan grote maten(overeenkomstige gegevenstypen worden ondersteund).

· Nieuwe, klassespecifieke gegevenstypen. Het systeem definieert nieuwe gegevenstypen (geometrie, geografie), kenmerkend voor die gebieden waarin de objectgeoriënteerde benadering zeer effectief is en vaak wordt gebruikt (cartografie en aanverwante toepassingen, geometrische weergave van objecten van heel andere aard).

· Opgeslagen procedures . In zekere zin zijn opgeslagen procedures ook een objectextensie, waarbij de noodzakelijke gebruikersacties op de gegevens worden uitgevoerd (een standaard procedurele benadering voor OOP).

2. Gedistribueerde databases

Een database is een geïntegreerde verzameling gegevens waar veel gebruikers mee werken. De presentatie van alle voorgaande secties is aangenomen enkele basis gegevens op één computer. Laten we ons de basisprincipes herinneren die ten grondslag liggen aan de databasetheorie:

· gecentraliseerde gegevensopslag;

· gecentraliseerd gegevensonderhoud (invoer, correctie, uitlezen, integriteitscontrole).

Merk op dat databases verschenen tijdens de periode van dominantie van mainframecomputers. De database werd op één computer bijgehouden, alle gebruikers werkten op de computer ( mogelijke modi werken worden beschreven in hoorcollege 3). Andere gebruiken computer technologie op dat moment bestond het simpelweg niet. Als je het werk van gebruikers met gegevens in bedrijven, organisaties en ondernemingen in de ‘pre-computer’-tijd analyseert, is het gemakkelijk op te merken dat aparte ruimtes gebruikers werkten met “hun” gegevens (verzamelden bepaalde gegevens, bewaarden deze, verwerkten deze, brachten de verwerkte gegevens over naar andere gebieden of managementniveaus).

Deze technologie had aanzienlijke tekortkomingen die al in eerdere paragrafen zijn opgemerkt: duplicatie van sommige gegevens, gebrek aan mogelijkheden vergelijkende analyse gegevens uit alle gebieden. Deze technologie had echter ook aanzienlijke voordelen: gegevens werden ingevoerd en opgeslagen op de plaatsen waar ze werden gegenereerd; een gebruiker die een expert was op het gebied van deze specifieke gegevens, werkte met deze gegevens, waardoor hij de juistheid van de gegevens in alle stadia van de verwerking effectief kon controleren; de gegevens bevonden zich rechtstreeks bij de gebruiker, waardoor dit mogelijk was operationele verwerking. Centralisatie van gegevens op één computer biedt ongetwijfeld uitkomst effectieve mogelijkheden gegevensopslag en -verwerking lieten niet toe dat bovengenoemde voordelen werden gerealiseerd.

Ontwikkeling van computers computer netwerken heeft geleid tot nieuwe mogelijkheden bij het organiseren en onderhouden van databases, waardoor elke gebruiker zijn eigen gegevens op zijn computer kan hebben en ermee kan werken, en tegelijkertijd alle gebruikers in staat stelt om met de volledige set gegevens te werken als één enkele gecentraliseerde database. De overeenkomstige verzameling gegevens wordt een gedistribueerde database genoemd.

De voorwaarde " gedistribueerde database' komt vrij vaak voor in de literatuur. Echter, binnen verschillende bronnen Deze term betekent totaal verschillende dingen. Sommige auteurs begrijpen dat er sprake is van een gedistribueerde database externe server, waarop de gegevens zich bevinden, evenals clientcomputers, geografisch gelegen op een andere plaats. Deze interpretatie lijkt ons onjuist. Echt gedistribueerde database bevindt zich op meerdere computers. In dit geval bevinden sommige bestanden zich op de ene computer, andere op een andere, enz. Bovendien is het mogelijk en komt het zelfs vaak voor dat informatie op deze computers overlapt en wordt gedupliceerd.

Een gedistribueerde database is een verzameling logisch met elkaar verbonden gedeelde gegevens (en beschrijvingen van hun structuren) die fysiek zijn gedistribueerd in een computernetwerk.

Objectgeoriënteerd datamodel

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

De structuur van een objectgeoriënteerde database wordt grafisch weergegeven als 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 als eigenschap is gedefinieerd. Objecteigenschappen- of standaard soort, bijvoorbeeld string of een door de gebruiker geconstrueerde typeklasse. Het gedrag van objecten wordt gespecificeerd met behulp van methoden. Methode is een bepaalde bewerking die op een object kan worden toegepast.

Beschouw als voorbeeld de database “LIBRARY” (Fig. 4.4). Voor elk object worden eigenschappen, hun typen en waarden gedefinieerd. In de databank:

“BIBLIOTHEEK” – ouder (voorouder) voor “ABONNEMENT”, “CATALOGUS”, “ISSUE”;

"CATALOGUS" is de ouder van "BOEK".

“BOEK” – verschillende objecten kunnen dezelfde of verschillende ouders hebben. Als het dezelfde ouder is (dezelfde auteur), dan zijn de accessienummers verschillend, maar zijn de isbn, UDC, titel en auteur hetzelfde.

Logische structuur Een objectgeoriënteerde database lijkt op een hiërarchische database, het belangrijkste verschil zit in de methoden voor gegevensmanipulatie. U kunt de volgende acties uitvoeren op de database: logische operaties, versterkt door objectgeoriënteerde technieken van inkapseling, overerving en polymorfisme.

Inkapseling beperkt het bereik van een eigenschapsnaam tot de grenzen van het object waarin deze is gedefinieerd. Dus als de woning wordt toegevoegd aan de “CATALOGUS” telefoon auteur van het boek, dan worden ze op dezelfde manier verkregen in “ABONNEMENT” en “CATALOGUS”. De betekenis van een eigenschap wordt bepaald door het object waarin deze is ingekapseld.

Erfenis Omgekeerd breidt het de reikwijdte van de eigenschap uit naar alle onderliggende objecten van het object. Zo kunnen alle objecten van het type “BOEK” die afstammen van “DIRECTORY” de eigenschappen van de bovenliggende isbn, UDC, titel en auteur krijgen.

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

De voordelen van een objectgeoriënteerd model in vergelijking met een relationeel model zijn de mogelijkheid om informatie weer te geven over complexe relaties tussen objecten en de afwezigheid van beperkingen in de gegevensopslagstructuren. Een objectgeoriënteerde database kan niet alleen de structuur, maar ook de gedragsaspecten van de gegevens opslaan. Met behulp van een objectgeoriënteerde aanpak kunnen databases met grote volumes semantische informatie, zoals multimedia en gespecialiseerd voor specifieke vakgebieden (geografisch, ontwerp, etc.).

De nadelen van deze aanpak zijn onder meer een hoge conceptuele complexiteit, ongemak bij gegevensverwerking en lage snelheid het vervullen van verzoeken.

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

Onderwerp 5

Relationele benadering voor het bouwen van een informatielogisch model: basisconcepten

Relationeel datamodel. Basisconcepten

Zoals opgemerkt in het gedeelte van de vorige lezing, is het relationele model momenteel een van de meest voorkomende modellen op de databasemarkt. De basis van dit model is een reeks onderling verbonden tabellen (relaties).

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

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

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

De basisconcepten van het relationele model worden gegeven in Tabel. 3.1.

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

Operators in het relationele model zijn een reeks instructies die de selectie en manipulatie van gegevens mogelijk maken.

Tabel 5.1. Elementen van het relationele model

Relationele modelterm	Beschrijving
Database (DB)	Een reeks tabellen en andere objecten die nodig zijn voor een abstracte weergave van het geselecteerde gebied
DB-schema	Een set tabelkoppen die met elkaar verbonden zijn
Houding	Tafel – een verzameling objecten echte wereld, die worden gekenmerkt algemene eigenschappen en kenmerken (tabelvelden)
Relatiekop	Tabeltitel – namen van velden (kolommen) van de tabel
Lichaamsrelatie	Het lichaam van de tabel is een reeks waarden voor alle objecten in de echte wereld, die kunnen worden weergegeven in de vorm van tabelrecords (tabelrijen)
Relatiediagram	Tabelkolomkoprij (tabelkop)
Relatie attribuut	Naam tabelkolom (tabelveld)
Relatie tupel	Tabelrij (record) – een ondubbelzinnige weergave van een object uit de echte wereld, gemaakt met behulp van tabelveldwaarden
Domein	Een stelletje aanvaardbare waarden attribuut
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 tupel definiëren (tabelrijwaarde)
Externe sleutel	Een tabelattribuut waarvan de waarden overeenkomen met de primaire sleutelwaarden in een andere gerelateerde (bovenliggende, primaire) tabel. Een externe sleutel kan uit één of meer attributen bestaan ​​(samengestelde externe sleutel). Als het aantal attributen van een externe sleutel kleiner is dan het aantal attributen van de corresponderende primaire sleutel, wordt deze afgekapt (gedeeltelijk) genoemd. vreemde sleutel
Mate (ariteit) van de relatie	Aantal tabelkolommen
Vermogensverhouding	Aantal rijen (tupels) van de tabel
Relatie-instantie	Een set records (tupels) voor een bepaalde tabel (relatie). De instantie kan in de loop van de tijd veranderen. Sinds een reguliere database in dit moment time werkt met slechts één versie van de relatie, dan wordt zo'n instantie van de relatie actueel genoemd
Data type	Waardetype tabelelement
Basishouding	Een relatie die een of meer kolommen bevat die de eigenschappen van een object karakteriseren, evenals een primaire sleutel
Afgeleide relatie	Is geen basisrelatie, d.w.z. karakteriseert de eigenschappen van een object niet en wordt gebruikt om relaties tussen andere tabellen aan te geven; het mag geen primaire sleutel bevatten. Als er een primaire sleutel is opgegeven, bestaat deze uit de 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
Eén-op-één communicatie (1:1)	Bij gebruik van dit type relatie kan een record in de ene tabel maximaal één gerelateerd record in een andere tabel hebben. In beide tabellen moeten sleutelvelden primair zijn. Wordt gebruikt om tabellen met talrijke velden van elkaar te scheiden of zoals vereist door gegevensbescherming
Eén-op-veel (1:M) communicatie	Bij gebruik van dit type relatie kan elk record van de ene 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 eerste tabel moet een primaire sleutel hebben, de tweede een externe sleutel.
Veel-op-veel-relatie (N:M).	Bij dit type Eén record in de eerste tabel kan overeenkomen met meerdere records uit de tweede tabel, maar één record uit de tweede tabel kan overeenkomen met meerdere records uit de eerste. Uniciteit van sleutels voor dergelijke tabellen is niet vereist. Tijdens het ontwerpen van een databaseschema worden dergelijke verbindingen getransformeerd. Om dit te doen is het noodzakelijk om een ​​hulprelatie te introduceren waarmee u de veel-op-veel-relatie kunt vervangen door twee één-op-veel-relaties.

De datastructuur van het relationele model houdt in dat het onderwerpgebied van het beschouwde probleem wordt weergegeven als een reeks onderling verbonden relaties.

In elke verbinding kan de ene relatie als hoofdrelatie fungeren (basis, ouder) en de andere als ondergeschikte (afgeleide, onderliggende relatie). Om deze relaties te behouden, moeten beide relaties een reeks attributen bevatten waarmee ze verband houden: in de hoofdrelatie is dit de primaire sleutel van de relatie (identificeert op unieke wijze de tuple van de hoofdrelatie); de ondergeschikte relatie moet een reeks attributen bevatten die overeenkomen met hoofdsleutel fundamentele relatie. Hier is deze set attributen al een secundaire sleutel of externe sleutel, d.w.z. definieert een set tupels van een afgeleide relatie geassocieerd met een enkele tupel van de hoofdrelatie.

Er vormen zich veel onderling verbonden tabellen databaseschema.

De houding dus R is een tweedimensionale tabel die enkele gegevens bevat.

Wiskundig N-aire relatie R is de cartesiaanse productset D 1 ×D 2 ×…×D n sets (domeinen) D 1 , D 2 ,…,D n(N≥1), niet noodzakelijk verschillend:

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

Waar D 1 ×D 2 ×…×D n– compleet 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 vertegenwoordigt semantisch concept, die kan worden gezien als een subset van waarden van een bepaald gegevenstype die een specifieke betekenis hebben.

Domeineigenschappen:

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

Bij sommige gedefinieerd eenvoudig soort gegevens of op een ander domein,

Er kan een logische voorwaarde zijn waarmee u een subset van gegevens kunt beschrijven die geldig zijn voor dit domein.

Draagt ​​een bepaalde semantische lading.

De belangrijkste betekenis van domeinen is dat ze vergelijkingen beperken: je kunt geen waarden vergelijken verschillende domeinen, zelfs als ze hetzelfde gegevenstype 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 relatie R die op een reeks domeinen is gedefinieerd, bestaat uit twee delen: een koptekst en een hoofdtekst.

Relatiekop– een vast aantal relatieattributen, die het cartesiaanse product beschrijven van domeinen waarop de relatie is gespecificeerd:

(<A1: D1>, <A2: D2 >, …, <En N>).

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

Lichaam relatie bevat een set relatie-tupels.

Elk colonne vertegenwoordigt een reeks paren van de vorm:

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

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

Zodanig dat de waarde Vali attribuut Een ik behoort tot het domein D ik.

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 feitelijk een relatie in de wiskundige zin van het woord. De hoofdtekst van de relatie kan veranderen tijdens het werken met de database, omdat tupels in de loop van de tijd kunnen veranderen, worden toegevoegd en verwijderd.

De relatie wordt meestal geschreven als:

R(<A1: D1>, <A2: D2 >, …, <En N>),

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

Relatiediagram is een set relatiekoppen die in de database zijn opgenomen, dat wil zeggen een lijst met attribuutnamen van een bepaalde relatie die het domein aangeeft waartoe ze behoren:

S R =(Een 1, Een 2, …, Een), A ik D ik, i = 1,..., n.

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

Als een domein bijvoorbeeld numerieke gegevens bevat, zijn alle vergelijkingsbewerkingen daarvoor geldig: θ == (=,<>,>=,<=,<,>). Voor domeinen die karaktergegevens bevatten, kunnen echter niet alleen vergelijkingsbewerkingen voor gelijkheid en ongelijkheid van waarden worden gespecificeerd. Als een bepaald domein een lexicografische ordening heeft, beschikt het ook over een volledige reeks vergelijkingsbewerkingen.

Schema's van twee relaties worden genoemd equivalent, als ze dezelfde graad hebben, en het mogelijk is om de attribuutnamen in de schema's zo te ordenen dat vergelijkbare attributen, dat wil zeggen attributen die waarden uit hetzelfde domein aannemen, zich op dezelfde plaatsen zullen bevinden.

Voor gelijkwaardige relaties is dus aan de volgende voorwaarden voldaan:

Hetzelfde aantal attributen hebben;

De aanwezigheid van attributen met dezelfde namen;

De aanwezigheid van identieke rijen in relaties, rekening houdend met het feit dat de volgorde van attributen kan variëren;

Dit soort relaties zijn verschillende beelden van dezelfde relatie.

Eigenschappen van relaties volgt rechtstreeks uit de eerder gegeven definitie van relatie. Deze eigenschappen zijn de belangrijkste verschillen tussen relationele gegevensmodelrelaties en eenvoudige tabellen:

Uniciteit van de relatienaam. De naam van één relatie moet anders zijn dan de namen van andere relaties.

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

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

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

Het unieke karakter van de attribuutnaam binnen de relatie. Elk attribuut heeft binnen de relatie een unieke naam, wat betekent dat de volgorde van de attributen er niet toe doet (ter vergelijking: de kolommen in de tabel zijn geordend). Deze eigenschap onderscheidt een relatie enigszins van de wiskundige definitie van een 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 waarden hebben, dat wil zeggen dat aan elk attribuut een waardedomein (een afzonderlijk elementair type) is gekoppeld, en dat de attribuutwaarden uit hetzelfde domein zijn gehaald. Het schema en de tupels van een relatie zijn sets en geen lijsten, dus de volgorde waarin ze worden gepresenteerd doet er niet toe. Ter vergelijking kunt u verschillende informatie in tabelcellen plaatsen: arrays, structuren, andere tabellen, enz.

Opmerking:

Uit de eigenschappen van de relatie volgt dat niet iedereen een tabel kan een relatie zijn. Om ervoor te zorgen dat een tabel een relatie definieert, moet de tabel een eenvoudige structuur hebben (bevat alleen rijen en kolommen, en elke rij moet hetzelfde aantal velden hebben), de tabel mag geen identieke rijen hebben, elke kolom in de tabel moet bevatten slechts één type gegevens, alle gebruikte gegevenstypen moeten eenvoudig zijn.

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

Object-georiënteerd

Post-relationeel model

Voor- en nadelen van het relationele datamodel

Voornaamst waardigheid relationeel datamodel - het is gemakkelijk te begrijpen, visueel en heeft een strikte wiskundige rechtvaardiging.

Gebreken het volgende:

· het relationele datamodel staat de representatie van objecten met een complexe structuur niet toe, omdat het binnen zijn raamwerk mogelijk is om alleen te modelleren met behulp van tweedimensionale tabellen;

· Gegevens over objecten zijn doorgaans in veel tabellen opgenomen. Dienovereenkomstig vereist het ophalen van informatie over elk dergelijk object het uitvoeren van veel samenvoegingsbewerkingen met behulp van primaire en externe sleutels, wat de gegevensverwerking aanzienlijk vertraagt.

Onlangs zijn modellen zoals postrelationeel, objectgeoriënteerd, objectrelationeel en multidimensionaal modellen.

Post-relationeel Het datamodel is in het algemeen een uitgebreid relationeel model dat de beperking van ondeelbare veldwaarden opheft.

Dat wil zeggen dat velden met meerdere waarden zijn toegestaan, waarvan de waarden uit subwaarden bestaan. Een voorbeeld van een post-relationeel model is een tabel die een verzameling gegevens is uit de gerelateerde relationele tabellen CLIENTS en ORDERS.

Voordelen post-relationeel datamodel:

· de mogelijkheid om gerelateerde relationele tabellen weer te geven met één relationele tabel. Dit zorgt voor een hoge helderheid van de gegevenspresentatie en verhoogt de efficiëntie van de verwerking ervan;

· geen beperkingen op de lengte van velden en hun aantal in tabelrecords.

Gebrek post-relationeel model – problemen bij het waarborgen van de gegevensintegriteit.

Objectgeoriënteerde en object-relationele modellen worden gebruikt om de beperkte mogelijkheden van het relationele model voor het opslaan en verwerken van complexe objecten, zoals documenten, geluid, video, afbeeldingen, enz., te overwinnen.

Objectgeoriënteerd model vertegenwoordigt een structuur die grafisch kan worden weergegeven als een boom waarvan de knooppunten objecten zijn.

Elk object wordt gekenmerkt door een uniek karakter ID, staat en gedrag. Staat een object wordt bepaald door de reeks waarden van zijn attributen. Gedrag beschrijf het voorwerp methoden, procedures genoemd. Dat wil zeggen dat een integraal onderdeel van de beschrijving van een object procedures zijn die acties kunnen uitvoeren op de attributen van het object in het geval van bepaalde gebeurtenissen. .

Objecten kunnen worden gecombineerd tot klassen . Instanties van dezelfde klasse verschillen alleen in de waarden van hun eigenschappen, maar niet in hun methoden. Methoden worden ingesteld wanneer de klasse wordt gedefinieerd.

Om acties op objecten uit te voeren, worden objectgeoriënteerde mechanismen gebruikt - overerving, inkapseling, polymorfisme.

De essentie erfenis is dat je op basis van een bestaande klasse een nieuwe klasse objecten kunt maken die de eigenschappen van de bovenliggende klasse overneemt.

Toegang tot gegevens wordt alleen uitgevoerd in overeenstemming met de regels van objectgedrag beschreven door methoden ( inkapseling ).

Polymorfisme – het vermogen van objecten om anders te reageren op dezelfde gebeurtenis in de omringende wereld. Polymorfisme wordt gebruikt om de verwerking van heterogene objecten te verenigen. De methode Print Result kan bijvoorbeeld voor veel objectklassen worden gedefinieerd, maar zal anders werken afhankelijk van de klasse waarop deze wordt toegepast.

Voornaamst waardigheid OOMD is het vermogen om informatie over complexe objecten weer te geven met een uitgebreide beschrijving van de relaties ertussen en hun dynamisch gedrag. Dit model wordt meestal gebruikt voor complexe vakgebieden, waarvan de modellering de functionaliteit van een relationeel model mist (bijvoorbeeld ontwerp automatiseringssystemen, publicatiesystemen, enz.). P.).

Gebrek OOMD is de complexiteit van het conceptuele apparaat, wat de toepassing ervan bemoeilijkt en een negatieve invloed heeft op de accumulatie van ervaring bij het creëren en exploiteren van objectgeoriënteerde databases.

Object-relationeel datamodel is een hybride model dat de mogelijkheden van het relationele model combineert met objectgegevenseigenschappen.

1. Objecten die zichtbaar zijn op de externe interface worden toegewezen aan tabellen in de ondersteunende relationele database. Omgekeerd worden objecten gereproduceerd vanuit hun representatie in een tabellarische opslagomgeving wanneer ze worden opgevraagd door gebruikers of applicaties (hybride aanpak).

Deze aanpak was eind jaren tachtig populair. en werd belichaamd in softwareproducten voor programmeerautomatisering (CASE), voor ontwerpautomatisering (CAD), in repositories (databases die zijn ontworpen om geen gebruikersgegevens, maar systeemgegevens op te slaan).

2. De interne relationele mechanismen van het datamanagement-DBMS zijn uitgebreid met objectgeoriënteerde mogelijkheden ( uitgebreide relationele benadering).

Deze aanpak is technologisch geavanceerder en heeft momenteel de voorkeur van de meeste relationele DBMS-ontwikkelaars. Hij incarneerde in 1996-1997. in een aantal object-relationele databaseservers.

Kenmerkend voor het object-relationele model van OOMD is dat het gebaseerd is op de strategie van het relationele model. Het opnemen van objecten in het relationele model kan in dit stadium alleen worden besproken als een algemene richting in de ontwikkeling van databases.