Objektorienterad datamodell

Den objektorienterade datamodellen är en förlängning av bestämmelserna i objektorienterad programmering (medan den relationella modellen uppstod utifrån mängdteorin, just som en datamodell). Standarden ODMG-93 (Object DataBase Management Group) har utvecklats av Object-Oriented Database Management Group. Denna standard har ännu inte implementerats fullt ut.

Strukturen hos en objektorienterad databas representeras grafiskt i form av ett träd, vars noder är objekt. Den synliga strukturen för ett objekt bestäms av egenskaperna för dess klass. Klass inkluderar objekt, medan strukturen och beteendet för objekt av samma klass är desamma. Varje objekt, nämligen en instans av en klass, anses vara en avkomling av objektet där det definieras som en egenskap. Objektegenskaper- antingen en standardtyp, såsom sträng, eller en användarkonstruerad typklass. Objektens beteende ställs in med metoder. MetodÄr en operation som kan tillämpas på ett objekt.

Som ett exempel, betrakta databasen "LIBRARY" (Fig.4.4). För varje objekt definieras egenskaper, deras typer och värden. I DB:n:

"BIBLIOTEK" - förälder (förfader) för "PRENUMERATION", "KATALOG", "ISSUE";

"CATALOG" är föräldern för "BOK".

"BOK" - olika objekt kan ha samma eller olika föräldrar. Om samma förälder (en författare) är inventeringsnumren olika, men isbn, UDC, titel och författare är samma.

Den logiska strukturen för en objektorienterad databas liknar en hierarkisk, den största skillnaden ligger i metoderna för datamanipulation. Ovanför databasen kan du utföra åtgärder som logiska operationer, förstärkta med objektorienterade metoder för inkapsling, arv och polymorfism.

Inkapsling begränsar omfattningen av egenskapsnamnet till gränserna för objektet där det är definierat. Så, om egenskapen läggs till i "KATALOG" telefon bokens författare, erhålls sedan på samma sätt i "PRENUMERATION" och "KATALOG". Innebörden av egendomen kommer att bestämmas av objektet i vilket den är inkapslad.

Arv omvänt, utvidgar omfattningen av egendomen till alla ättlingar till objektet. Således kan alla objekt av typen "BOK" som är ättlingar till "KATALOG" tilldelas egenskaperna för den överordnade isbn, UDC, namn och författare.

Polyformism betyder samma programkods förmåga att arbeta med olika typer av data. Det betyder med andra ord att det är tillåtet i objekt av olika slag att ha metoder - procedurer och funktioner - med samma namn. Under körningen av ett objektprogram fungerar samma metoder på olika objekt beroende på typen av argument. För databasen "LIBRARY" betyder detta att objekt i klassen "BOOK" som har olika föräldrar än klassen "CATALOG" kan ha en annan uppsättning egenskaper, dvs. program för att arbeta med ett objekt av klassen "BOOK" kan innehålla polymorf kod. I en klass har en metod ingen kropp, det vill säga det är inte definierat vilka specifika åtgärder den ska utföra. Varje underklass utför de nödvändiga operationerna. Encapsulation döljer implementeringsdetaljer från alla objekt utanför den givna hierarkin.

Fördelarna med den objektorienterade modellen i jämförelse med den relationella modellen är förmågan att visa information om komplexa relationer mellan objekt, frånvaron av begränsningar i datalagringsstrukturer. En objektorienterad databas kan lagra inte bara strukturen utan även beteendeaspekterna av datan. Med hjälp av det objektorienterade tillvägagångssättet kan databaser också skapas med stora mängder semantisk information, såsom multimedia och specialiserade för specifika ämnesområden (geografi, design, etc.).

Nackdelarna med detta tillvägagångssätt inkluderar hög konceptuell komplexitet, besvär vid databehandling och låg exekveringshastighet för frågor.

På 90-talet skapades prototyper av fungerande objektorienterade databaser. Dessa är POET (POET SoftWare), JASMINE (COMPUTER ASSOCIATES), IRIS, ORION, POSTGRES.

Ämne 5

Relationellt förhållningssätt för att bygga en informationslogisk modell: grundläggande begrepp

Relationsdatamodell. Grundläggande koncept

Som noterats i avsnittet av föregående föreläsning är relationsmodellen för närvarande en av de vanligaste modellerna på databasmarknaden. Denna modell är baserad på en uppsättning sammanlänkade tabeller (relationer).

De huvudsakliga teoretiska idéerna för relationsmodellen presenterades i verken om relationsteori av den amerikanske logikern Charles Souders Peirce (1839-1914) och den tyske logikern Ernst Schroeder (1841-1902), samt den amerikanske matematikern Edgar Codd .

I verk av Peirce och Schroeder bevisades det att uppsättningen av relationer är stängd under några speciella operationer som tillsammans bildar en abstrakt algebra. Denna viktigaste egenskap hos relationer användes i relationsmodellen för att utveckla ett datamanipulationsspråk.

1970 publicerades en artikel av E. Codd om presentationen av data organiserade i tvådimensionella tabeller, kallade relationer. Codd var först med att introducera relationsmodellens grundläggande begrepp och begränsningar som grund för lagring av data, och visade på möjligheten att databearbeta med traditionella operationer på set och speciella introducerade relationsoperationer.

Relationsmodellens grundläggande begrepp ges i tabell. 3.1.

Objekten för relationsmodellen är främst tabeller (relationer). Dataintegritet säkerställs av externa och primära nycklar (se s. "Relationell dataintegritet").

Operatörer i relationsmodellen är en uppsättning instruktioner som hämtar och manipulerar data.

Tabell 5.1. Element i relationsmodellen

Relationell modellterm	Beskrivning
Databas (DB)	En uppsättning tabeller och andra objekt som behövs för att abstrakt representera det valda ämnesområdet
DB-schema	En uppsättning tabellrubriker som är relaterade till varandra
Attityd	Tabell - en uppsättning objekt i den verkliga världen, som kännetecknas av gemensamma egenskaper och egenskaper (tabellfält)
Relationshuvud	Tabellhuvud - namnen på fälten (kolumnerna) i tabellen
Relationsorgan	Tabellkropp - en samling värden för alla objekt i den verkliga världen, som kan representeras som tabellposter (tabellrader)
Relationsdiagram	Rad med tabellkolumnrubriker (tabell "rubrik")
Relationsattribut	Tabellkolumnnamn (tabellfält)
Förhållande tupel	Tabellrad (Record) - En entydig representation av ett objekt i den verkliga världen skapat med hjälp av värdena i tabellfälten
Domän	Många giltiga attributvärden
Attributvärde	Fältvärde i post (tuppel)
Primärnyckel	Ett eller flera (när det gäller en sammansatt nyckel) attribut som unikt definierar värdet på tupeln (värdet på tabellraden)
Extern nyckel	Ett tabellattribut vars värden motsvarar värdena för primärnyckeln i en annan relaterad (förälder, primär) tabell. En främmande nyckel kan bestå av ett eller flera attribut (sammansatt främmande nyckel). Om antalet främmande nyckelattribut är mindre än antalet attribut för motsvarande primärnyckel, kallas det en trunkerad (partiell) främmande nyckel
Relationens grad (aritet).	Antal tabellkolumner
Kraften i relationen	Antal rader (tuplar) i tabellen
Relationsinstans	Uppsättningen av poster (tupler) för en given tabell (relation). Förekomsten kan ändras med tiden. Eftersom en vanlig databas för närvarande bara fungerar med en version av relationen kallas en sådan instans av relationen för den aktuella.
Data typ	Värdetyp av tabellelement
Basförhållande	Relation som innehåller en eller flera kolumner som kännetecknar objektets egenskaper, såväl som primärnyckeln
Härlett förhållande	Det är inte ett grundläggande förhållande, d.v.s. karaktäriserar inte objektegenskaper och används för att tillhandahålla länkar mellan andra tabeller, får inte innehålla en primärnyckel. Om en primärnyckel anges, så består den av främmande nycklar som är associerade med primärnycklarna för den underliggande relationen
Förbindelse	Etablerar en relation mellan matchande värden i nyckelfält - primärnyckeln för en tabell och främmande nyckel för en annan
En-till-en relation (1:1)	När du använder denna typ av relation kan en post i en tabell ha högst en associerad post i en annan tabell. I båda tabellerna måste nyckelfälten vara primära. Används för att dela tabeller med flera fält eller on-demand dataskydd
En-till-många-relation (1:M)	När du använder denna typ av relation kan varje post i en tabell motsvara flera poster i den andra, men varje post i den andra tabellen motsvarar endast en post i den första tabellen. Den primära nyckeln måste anges i den första tabellen och den externa nyckeln i den andra.
Många-till-många-relation (N:M)	Med denna typ av relation kan en post i den första tabellen motsvara flera poster i den andra tabellen, men en post i den andra tabellen kan motsvara flera poster i den första. Det unika hos nycklarna för sådana tabeller krävs inte. I processen att designa ett databasschema omvandlas sådana länkar. För att göra detta måste du införa en hjälprelation som låter dig ersätta många-till-många-relationen med två en-till-många-relationer.

Datastrukturen för relationsmodellen antar representationen av ämnesområdet för det aktuella problemet som en uppsättning inbördes relaterade relationer.

I varje förhållande kan den ena relationen fungera som den huvudsakliga (bas, förälder), och den andra - som en underordnad (avledd, barn). För att upprätthålla dessa länkar måste båda relationerna innehålla en uppsättning attribut som de är relaterade till: i huvudrelationen är detta den primära nyckeln för relationen (identifierar unikt tupeln av huvudrelationen); den underordnade relationen måste ha en uppsättning attribut som motsvarar primärnyckeln för huvudrelationen. Här är denna uppsättning attribut redan en sekundär nyckel eller främmande nyckel, dvs. definierar uppsättningen av tuplar av den härledda relationen associerad med en enda tupel av basrelationen.

Många sammanlänkade tabeller bildas db schema.

Alltså attityden Rär en tvådimensionell tabell som innehåller vissa data.

Matematiskt N-är relation RÄr en uppsättning kartesiska produkter D 1 × D 2 ×... × D n uppsättningar (domäner) D 1, D 2, ..., D n(n≥1), inte nödvändigtvis annorlunda:

R D 1 × D 2 ×... × D n,

var D 1 × D 2 ×... × D n- komplett kartesisk produkt, d.v.s. en uppsättning av alla möjliga kombinationer av n element vardera, där varje element är hämtat från sin egen domän.

Domänär ett semantiskt koncept som kan ses som en delmängd av värdena för någon datatyp som har en specifik betydelse.

Domänegenskaper:

Domänen har ett unikt namn (inom databasen),

Definierat på någon enkel datatyp eller på en annan domän,

Kan ha något booleskt tillstånd för att beskriva en delmängd av data som är tillåtna för denna domän,

Bär en viss semantisk belastning.

Den huvudsakliga innebörden av domäner är att de begränsar jämförelser: du kan inte jämföra värden från olika domäner, även om de har samma datatyp.

Attribut förhållande är ett par av formen

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

Attributnamn är unika inom en relation. Ofta är attributnamnen desamma som motsvarande domännamn.

Ett R, definierat över flera domäner, har två delar: en rubrik och en brödtext.

Relationshuvud- ett fast antal relationsattribut som beskriver den kartesiska produkten av domäner där relationen är specificerad:

(<A 1: D 1>, <A 2: D 2 >, …, <Och n>).

Rubriken är statisk: den ändras inte när man arbetar med databasen Om relationen har ändrat, lagt till eller tagit bort attribut erhålls en annan relation. Även med namnet sparat.

Kropp relation innehåller många relationstuplar.

Varje kortegeär en uppsättning par av formen:

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

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

Sådant att värdet Val i attribut A i tillhör domänen D i.

En relations kropp är en samling av tupler, det vill säga en delmängd av den kartesiska produkten av domäner. Således är kroppen av en relation i sig en relation i ordets matematiska mening. Texten i en relation kan ändras när du arbetar med databasen, eftersom tupler kan ändras, läggas till och tas bort över tiden.

Relationen skrivs vanligtvis som:

R(<A 1: D 1>, <A 2: D 2 >, …, <Och n>),

eller förkortat: R(A 1, A 2, …, Ett) eller R.

Relationsdiagramär en uppsättning relationsrubriker som ingår i databasen, det vill säga en lista med attributnamn för en given relation med en indikation på den domän som de tillhör:

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

Om attribut tar värden från samma domän, kallas de θ-jämförbara, där θ är uppsättningen av giltiga jämförelser som anges för denna domän.

Till exempel, om en domän innehåller numeriska data, är alla jämförelseoperationer giltiga för den: θ == (=,<>,>=,<=,<,>). Men även för domäner som innehåller teckendata kan inte bara jämförelseoperationer för likhet och ojämlikhet specificeras. Om en lexikografisk ordning anges för en given domän, har den också en fullständig uppsättning jämförelseoperationer.

Scheman för de två relationerna kallas likvärdig om de har samma grad, och ordningen av attributnamnen i scheman är möjlig så att jämförbara attribut kommer att finnas på samma ställen, det vill säga attribut som tar värden från samma domän.

Följande villkor är alltså uppfyllda för likvärdiga relationer:

Förekomsten av samma antal attribut;

Förekomsten av attribut med samma namn;

Förekomsten av samma strängar i relationen, givet att ordningen på attributen kan skilja sig åt;

Relationer av det här slaget är olika bilder av samma relation.

Relationsegenskaper följer direkt av ovanstående definition av en relation. Dessa egenskaper är i grunden skillnaden mellan relationsdatamodellrelationer och enkla tabeller:

Det unika med namnet på förhållandet. Namnet på en relation måste skilja sig från namnen på andra relationer.

Det unika med tupler. Det finns inga identiska tuplar i en relation. Faktum är att kroppen av en relation är en uppsättning av tupler och kan, som alla andra, inte innehålla oskiljbara element. Tabeller, till skillnad från relationer, kan innehålla samma rader. Varje cell i ett förhållande innehåller bara ett atomärt (odelbart) värde.

Oordnade tuplar. Tuplar är inte ordnade (uppifrån och ner), eftersom relationskroppen är en uppsättning och uppsättningen inte är ordnad (för jämförelse är raderna i tabellerna ordnade). Samma förhållande kan representeras av olika tabeller, där raderna är i olika ordning.

Störning av attribut. Attributen är inte ordnade (vänster till höger).

Det unika hos attributnamnet i relationen. Varje attribut har ett unikt namn inom relationen, vilket gör att ordningen på attributen inte spelar någon roll (för jämförelse är kolumnerna i tabellen ordnade). Denna egenskap skiljer sig något från den matematiska definitionen av förhållandet. Samma förhållande kan representeras av olika tabeller där kolumnerna är i olika ordning.

Atomicitet hos attributvärden. Alla attributvärden är atomära. Detta följer av det faktum att de underliggande attributen har atomära betydelser, det vill säga att varje triboot är associerad med en rad värden (en separat elementär typ), värdena för attributen är hämtade från samma domän. Relationsscheman och tupler är uppsättningar, inte listor, så ordningen de presenteras i spelar ingen roll. För jämförelse kan olika information placeras i tabellceller: arrayer, strukturer, andra tabeller, etc.

Kommentar:

Av förhållandets egenskaper följer att inte varje tabellen kan vara en relation. För att någon tabell ska definiera en relation är det nödvändigt att tabellen har en enkel struktur (innehåller bara rader och kolumner, och varje rad måste ha samma antal fält), tabellen får inte ha identiska rader, någon kolumn med tabellen måste innehålla data av endast en typ, alla datatyper som används måste vara enkla.

Det bör noteras att relationsmodellen är en databas i form av en uppsättning sammanlänkade relationer, som kallas relationsdatabasschema.

Objektorienterad datamodell

Objektrelationell datamodell

Andra datamodeller

Den ökande komplexiteten hos databasapplikationer och begränsningarna i relationsmodellen ledde till utvecklingen av Codd-modellen, ĸᴏᴛᴏᴩᴏᴇ som först kallades utökad relationsmodell, och fick senare sin utveckling i den objektrelationella datamodellen. Databaser baserade på dessa modeller brukar kallas för generation III.

Objektrelationsdatamodellen (ORMD) implementeras med hjälp av relationstabeller, men inkluderar objekt som liknar konceptet med ett objekt i objektorienterad programmering. ORMD använder objektorienterade komponenter som användardefinierade datatyper, inkapsling, polymorfism, arv, metodöverstyrning och så vidare.

Tyvärr, förrän nu, har utvecklarna inte kommit till enighet om vad ORMD ska tillhandahålla. År 1999 ᴦ. SQL-99-standarden antogs, och 2003 ᴦ. den andra versionen av denna standard släpptes, kallad SQL-3, som definierar ORMD:s huvudegenskaper. Men än så länge skiljer sig de objektrelationella modellerna som stöds av olika DBMS-leverantörer avsevärt från varandra. Utsikterna för denna riktning bevisas av det faktum att ledande DBMS-tillverkare, inklusive Oracle, Informix, INGRES och andra, har utökat kapaciteten hos sina produkter till en objektrelationell DBMS (ORDBMS).

I de flesta implementeringar av ORMD känns objekt som ett aggregat och en tabell (relation), som kan vara en del av en annan tabell. Databehandlingsmetoder representeras som lagrade procedurer och utlösare, som är procedurdatabasobjekt och är associerade med tabeller. På konceptuell nivå representeras all data i en objektrelationell databas som en relation, och ORDBMS stöder SQL-språket.

En annan metod för att bygga en databas är användningen av en objektorienterad datamodell (OOMD). Datamodellering i OOMD bygger på konceptet om ett objekt. ODM används vanligtvis inom komplexa ämnesområden som saknar funktionaliteten hos den relationella modellen för modellering (till exempel för designautomationssystem (CAD), publiceringssystem, etc.).

När man skapar objektorienterad DBMS (OODBMS) används olika metoder, nämligen:

• inbäddning i det objektorienterade språket av medel avsedda för att arbeta med en databas;
• utvidgning av det befintliga språket för att arbeta med databaser med objektorienterade funktioner;
• skapande av objektorienterade bibliotek med funktioner för att arbeta med en databas;
• skapande av ett nytt språk och en ny objektorienterad datamodell

Fördelarna med OOMD inkluderar stora möjligheter att modellera domänen, uttrycksfullt frågespråk och hög prestanda. Varje objekt i OOMD har en unik identifierare (OID - objektidentifierare). OID-hämtning är betydligt snabbare än sökningar i relationstabeller.

Bland nackdelarna med OOMD bör det noteras bristen på en allmänt accepterad modell, bristen på erfarenhet av skapandet och driften av OODB, komplexiteten i användningen och otillräckliga medel för dataskydd.

År 2000 ᴦ. ODMG (Object Database Management Group) arbetsgruppen, bildad av tillverkarna av OODBMS, har släppt nästa standard (ODMG 3.0) för OODBMS, som beskriver objektmodellen, frågedefinitionsspråk, objektfrågespråk och anslutande språk C+ +, Smalltalk och Java. ODMG-standarder är inte officiella. ODMG:s syn på standardisering är i huvudsak att efter antagandet av nästa version av standarden av ODMGs medlemsorganisationer, publiceras en bok som innehåller standardens text.

Låt oss nu titta på hur datamodellstöd implementeras i riktiga databashanteringssystem.

Objektorienterad datamodell - koncept och typer. Klassificering och funktioner i kategorin "Objektorienterad datamodell" 2017, 2018.

Objektorienterad databas(OODB) är en databas där data modelleras i form av objekt, deras attribut, metoder och klasser.

Objektorienterade databaser rekommenderas vanligtvis för de fall där högpresterande bearbetning av data med en komplex struktur krävs.

OODB-manifestet föreslår de erforderliga egenskaperna som varje OODB måste uppfylla. Deras val baseras på 2 kriterier: systemet måste vara objektorienterat och vara en databas.

Obligatoriska egenskaper

1. Stöd för komplexa objekt. Systemet bör tillhandahålla möjligheten att skapa sammansatta objekt genom att använda konstruktörerna av sammansatta objekt. Objektkonstruktörer måste vara ortogonala, det vill säga vilken konstruktor som helst kan appliceras på vilket objekt som helst.

2. Stöd för objektens individualitet. Alla objekt måste ha en unik identifierare som inte beror på värdena för deras attribut.

3. Stöd för inkapsling. Korrekt inkapsling uppnås på grund av det faktum att programmerare har rätt att endast få tillgång till gränssnittsspecifikationen för metoder, och data och implementering av metoder är dolda inuti objekt.

4. Stöd för typer och klasser. OODB krävs för att stödja minst ett koncept för distinktion mellan typer och klasser. (Termen "typ" överensstämmer mer med konceptet med en abstrakt datatyp. I programmeringsspråk deklareras en variabel med en indikation på dess typ. Kompilatorn kan använda denna information för att kontrollera de operationer som utförs på variabeln för kompatibilitet med dess typ, vilket hjälper till att garantera att programvaran är korrekt. Å andra sidan är en klass en sorts mall för att skapa objekt och tillhandahåller metoder som kan tillämpas på dessa objekt. Begreppet "klass" är alltså mer av en körtid snarare än kompileringstid.)

5. Stöd för arv av typer och klasser från deras förfäder. En undertyp, eller underklass, måste ärva attribut och metoder från sin supertyp, respektive superklass.

6. Överbelastning kombinerat med full bindning. Metoder bör tillämpas på objekt av olika typer. Implementeringen av en metod måste bero på vilken typ av objekt som metoden tillämpas på. För att tillhandahålla denna funktionalitet bör bindningen av metodnamn på systemet inte ske förrän programmet körs.

7. Beräkningsmässig fullständighet. Datamanipuleringsspråket bör vara ett allmänt programmeringsspråk.

8. Uppsättningen av datatyper måste kunna utökas. Användaren måste ha möjlighet att skapa nya datatyper baserat på en uppsättning fördefinierade systemtyper. Dessutom bör det inte göras någon skillnad mellan hur system- och användardefinierade datatyper används.

OO DBMS

Objektorienterade databaser- databaser där information presenteras i form av objekt, som i objektorienterade programmeringsspråk.

Att tillämpa eller inte tillämpa objektorienterade databashanteringssystem (OODBMS) i verkliga projekt idag? I vilka fall ska de användas och i vilka fall inte?

Här Fördelar använder OODBMS:

· Det finns inga problem med missmatchning mellan datamodellen i applikationen och databasen (impedansmismatch). All data lagras i databasen i samma form som i applikationsmodellen.

· Det är inte nödvändigt att separat stödja datamodellen på DBMS-sidan.

· Alla objekt på datakällsnivå är starkt skrivna. Inga fler strängkolumnnamn! Att omstrukturera en objektorienterad databas och koden som fungerar med den är nu automatiserad, snarare än en tråkig och tråkig process.

ODMG standard

Första manifestet formellt var bara en artikel som skickades till Konferens om objektorienterade och deduktiva databaser av en grupp individer. Som du kan se i föregående underavsnitt var manifestets krav snarare känslomässiga än uttryckligen specificerade. 1991 bildades ODMG-konsortiet (då avslöjades denna förkortning som Objektdatabashanteringsgrupp, men fick senare en bredare tolkning - Objektdatahanteringsgrupp). ODMG-konsortiet är nära besläktat med det mycket större OMG-konsortiet ( Objekthanteringsgrupp), som bildades två år tidigare. Det ursprungliga målet för ODMG var att utveckla industristandarden för objektorienterade databaser (gemensam modell). Den grundläggande objektmodellen OMG COM ( Kärnobjektsmodell). Under mer än ett decennium har ODMG publicerat tre grundläggande versioner av standarden, varav den senaste heter ODMG 3.0. 16

Ironiskt nog, även om ODMG (enligt författarens åsikt) är utanför OMG, har vissa OMG-standarder på senare år förlitat sig på ODMG-objektmodellen. Speciellt OCL-språkspecifikationen ( Objektbegränsningsspråk), som är en del av den allmänna språkspecifikationen UML 1.4 (och UML 2.0). I den här artikeln har vi inte för avsikt att göra en detaljerad jämförelse av OMG- och ODMG-metoderna och hänvisa intresserade läsare till Kogalovskys uppslagsverk och material från dessa konsortiers webbplatser. Vi kommer att begränsa oss till en kort sammanfattning av huvudidéerna i ODMG-3-standarden.

ODMG arkitektur

Den föreslagna ODMG-arkitekturen visas i fig. 2.1. Denna arkitektur definierar ett sätt att lagra data och olika typer av användaråtkomst till detta "datalager" 17. Ett enda datalager är tillgängligt från ett datadefinitionsspråk, ett frågespråk och ett antal datamanipuleringsspråk. 18 I fig. 2.1 ODL betyder Objektdefinitionsspråk, OQL - Objektfrågespråk och OML - Objektmanipulationsspråk.

Ris. 2.1. ODMG arkitektur

Centralt för arkitekturen är datamodell, som representerar den organisationsstruktur i vilken all data som hanteras av OODBMS lagras. Objektdefinitionsspråk, frågespråk och manipulationsspråk är designade på ett sådant sätt att alla deras möjligheter förlitar sig på datamodellen. Arkitekturen tillåter en mängd olika implementeringsstrukturer för att lagra modellerad data, men ett viktigt krav är att alla programbibliotek och alla stödjande verktyg tillhandahålls i ett objektorienterat ramverk och måste lagras i överensstämmelse med datan.

Huvudkomponenterna i arkitekturen är följande.

• Objektdatamodell. All data som lagras av en OODBMS är strukturerad i termer av datamodellkonstruktioner. Datamodellen definierar den exakta semantiken för alla begrepp (se nedan för mer information).

• Data Definition Language (ODL). Databasscheman beskrivs i termer av ODL-språket, där datamodellkonstruktioner instansieras i form av ett definitionsspråk. ODL låter dig beskriva ett schema som en uppsättning objekttypsgränssnitt, vilket inkluderar beskrivningen av typegenskaper och relationer mellan dem, såväl som namnen på operationer och deras parametrar. ODL är inte ett komplett programmeringsspråk; typerna måste implementeras på ett av språken i OML-kategorin. ODL är också virtuell språk i den meningen att ODMG-standarden inte kräver att den implementeras i OODBMS-programvaruprodukter som anses vara kompatibla med standarden. Det är tillåtet för dessa produkter att stödja motsvarande definitionsspråk som inkluderar alla funktioner för ODL, men anpassade till specifikationerna för ett specifikt system. Förekomsten av ODL-språkspecifikationen i ODMG-standarden är dock viktig eftersom språket specificerar egenskaperna hos datamodellen.

• Object Query Language (ODL). Språket har en syntax som liknar den för SQL, men förlitar sig på semantiken i ODMG-objektmodellen. Standarden tillåter direkt användning av OQL och dess inbäddning i ett av språken i OML-kategorin.

Relationsdatamodell

Nästan alla moderna system bygger på relationella(relationell) databashanteringsmodell. namn relationella hänger samman med att varje post i en sådan databas innehåller information relaterad till endast ett specifikt objekt.

V relationella All bearbetad data i DBMS presenteras i form av platta tabeller. Information om objekt av en viss typ presenteras i tabellform: olika attribut för objekt är koncentrerade i tabellens kolumner, och rader är avsedda att reducera beskrivningar av alla attribut till enskilda instanser av objekt.

Modellen som skapats i det infologiska modelleringsstadiet uppfyller relativitetsprinciperna i största utsträckning. Men för att konvertera denna modell till en relationsmodell måste du utföra en procedur som kallas normalisering.

Normaliseringsteorin arbetar med fem normala former... Dessa formulär är utformade för att minska redundansen av information, så varje efterföljande normalform måste uppfylla kraven i föregående och vissa ytterligare villkor. I praktisk databasdesign används i allmänhet inte den fjärde och femte formen. Vi har begränsat oss till att överväga de fyra första normalformerna.

Låt oss introducera de begrepp som är nödvändiga för att förstå processen att reducera en modell till ett relationsschema.

Attityd- Abstraktion av det beskrivna objektet som en uppsättning av dess egenskaper. Under det infologiska designstadiet pratade vi om abstraktion av föremål och tilldelade dem några egenskaper. Nu, med konceptuell design, går vi till nästa nivå av abstraktion. I detta skede existerar inte objekten som sådana längre. Vi arbetar med en uppsättning egenskaper som definierar objektet.

Relationsinstans- en uppsättning värden för egenskaperna hos ett visst objekt.

Primärnyckel- en identifierande uppsättning attribut, dvs. värdet av dessa attribut är unikt i detta avseende. Det finns inga två instanser av en relation som innehåller samma värde i primärnyckeln.

Enkelt attribut- ett attribut vars värden är odelbara.

Komplext attribut- ett attribut vars värde är en uppsättning värden av flera olika egenskaper hos ett objekt eller flera värden för en egenskap.

Entitetskoncept ..

Domän

Domän är mer specifik för databaser, även om den har vissa analogier med undertyper i vissa programmeringsspråk. I sin mest allmänna form definieras en domän genom att specificera någon grundläggande datatyp till vilken elementen i domänen hör, och ett godtyckligt logiskt uttryck applicerat på elementet i datatypen. Om detta booleska uttryck utvärderas till sant är dataobjektet ett domänobjekt.

Den mest korrekta intuitiva tolkningen av begreppet en domän är förståelsen av en domän som en tillåten potentiell uppsättning värden av en given typ. Till exempel är domännamnen i vårt exempel definierade på bastypen av teckensträngar, men dess värden kan endast inkludera de strängar som kan representera ett namn (särskilt sådana strängar kan inte börja med ett mjukt tecken).

Den semantiska belastningen av domänkonceptet bör också noteras: data anses vara jämförbara endast om de tillhör samma domän. I vårt exempel är värdena för domänerna "Gap Numbers" och "Group Numbers" av heltalstyp, men är inte jämförbara. Observera att de flesta relationella DBMS:er inte använder domänkonceptet, även om Oracle V.7 redan stöder det.

Objektorienterad modell

I den objektorienterade modellen, vid presentation av data, är det möjligt att identifiera individuella databasposter. Relationer etableras mellan poster och deras bearbetningsfunktioner med hjälp av mekanismer som liknar dem i objektorienterade programmeringsspråk.

En standardiserad objektorienterad modell beskrivs i rekommendationerna för standarden ODMG-93 (Object Database Management Group).

Låt oss överväga en förenklad modell av en objektorienterad databas. Strukturen hos en objektorienterad databas representeras grafiskt i form av ett träd, vars noder är objekt. Objektens egenskaper beskrivs av någon standard eller användarkonstruerad typ (definierad som en klass). Värdet av en egenskap av typen klass är ett objekt som är en instans av motsvarande klass. Varje instans av en klass anses vara en avkomling av objektet där den definieras som en egenskap. Ett instansobjekt av en klass tillhör dess klass och har en enda förälder. Generiska relationer i databasen bildar en sammanhängande hierarki av objekt. Ett exempel på den logiska strukturen för en objektorienterad biblioteksdatabas visas i fig. 2.9. Här är ett objekt av typen Bibliotek det överordnade till exempel objekt för klasserna Subscriber, Directory och Issuance. Olika bokobjekt kan ha samma eller olika föräldrar. Objekt av typen Bok som har samma förälder måste skilja sig åt åtminstone med inventeringsnumret (unikt för varje exemplar av boken), men ha samma egenskapsvärden isbn, udc, title och author.

Den logiska strukturen hos en objektorienterad databas liknar utåt strukturen hos en hierarkisk databas. Den största skillnaden mellan de två är metoderna för datamanipulation.

För att utföra åtgärder på data i den övervägda databasmodellen används logiska operationer, stärkta av objektorienterade mekanismer för inkapsling, arv och polymorfism.

Inkapsling begränsar omfattningen av ett egenskapsnamn till utsidan av objektet där det är definierat. Så om vi lägger till en egenskap som anger telefonnumret till bokens författare och har namnet telefon till ett objekt av typen Katalog, så får vi egenskaperna med samma namn för Subscriber- och Catalog-objekten. Innebörden av en sådan egenskap kommer att bestämmas av objektet i vilket den är inkapslad.

Arv utsträcker däremot egendomens omfattning till objektets alla ättlingar. Således kan alla objekt av typen Bok som är avkomlingar till ett objekt av typen Katalog tilldelas egenskaperna för det överordnade objektet: isbn, udk, titel och författare. Om det är nödvändigt att utvidga effekten av arvsmekanismen till objekt som inte är omedelbara släktingar (till exempel mellan två ättlingar till samma förälder), så definieras en abstrakt egenskap av typen abs i deras gemensamma förfader. Så, definitionen av abstrakta egenskaper biljett och nummer i biblioteksobjektet leder till att dessa egenskaper ärvs av alla underordnade objekt Subscriber, Book och Issue. Därför är det ingen slump att värdena för biljettegenskapen för abonnent- och emissionsklasserna som visas i fig. 2,9 är samma - 00015.

Polymorfism i objektorienterade programmeringsspråk betyder att samma programkod kan arbeta med olika typer av data. Med andra ord betyder det att det är möjligt att ha metoder (procedurer eller funktioner) med samma namn i objekt av olika typer. Under körningen av ett objektprogram fungerar samma metoder på olika objekt beroende på typen av argument. I det här exemplet betyder polymorfism att objekt i klassen Bok som har olika föräldrar än klassen Catalog kan ha en annan uppsättning egenskaper. Därför kan program för att arbeta med objekt i klassen Book innehålla polymorf kod.

Att söka i en objektorienterad databas består i att ta reda på likheten mellan objektet, specificerat av användaren, och objekten lagrade i databasen.

Ris. 2.9 Den logiska strukturen för biblioteksdatabasen

Den främsta fördelen med den objektorienterade datamodellen i jämförelse med den relationella är förmågan att visa information om komplexa relationer mellan objekt. Den objektorienterade datamodellen låter dig identifiera en enda databaspost och definiera funktionerna för deras bearbetning.

Nackdelarna med den objektorienterade modellen är hög konceptuell komplexitet, besvär vid databehandling och låg frågehastighet.

Objektorienterade DBMS inkluderar POET, Jasmine, Versant, O2, ODB-Jupiter, Iris, Orion, Postgres.

Databanker som helhet klassificeras vanligtvis efter ekonomiska och juridiska egenskaper.

Enligt villkoren för tillhandahållande av tjänster särskiljs gratis och betalda banker, som i sin tur är uppdelade i kommersiella och ideella (vetenskapliga, bibliotek eller socialt betydelsefulla).

Enligt ägarformen delas BND in i statlig och icke-statlig. Beroende på graden av tillgänglighet skiljer de på offentliga och med ett begränsat antal användare.

Andra typer av klassificering är förknippade med enskilda komponenter i BnD.

1. Utveckling av databanker består av 4 steg:

Steg 1. Utformning och analys av systemkrav:

En systemspecifikation upprättas, inklusive en lista över uppgifter som ska lösas av BND;

Lista över slutanvändare och deras funktioner;

Lista över krav för databasen;

Ett dokumentflödesdiagram i organisationen upprättas.

Steg 2. Konceptuell design: en informationsmodell av systemet skapas utan hänvisning till typen av dator och typen av systemprogramvara; en infologisk databasmodell byggs upp som mest fullständigt beskriver ämnesområdet i termer av användaren.

Steg 3. Implementeringsdesign: ett datorsystem, systemprogramvara och ett DBMS väljs; datastrukturen utformas och en datalogisk databasmodell (databasschema) byggs, vilket är en beskrivning av databasens logiska struktur på språket för ett specifikt valt databashanteringssystem.

Steg 4. Fysisk implementering, vilket inkluderar att skapa och ladda data till en databas, utveckla och felsöka applikationsprogram för att arbeta med en databas, skriva dokumentation. I detta skede byggs en fysisk modell av databasen, som beskriver de lagringsenheter som används, metoder för fysisk organisering av data. Beskrivningen av den fysiska strukturen i en databas kallas ett lagringsschema. För närvarande finns det en tendens att minska denna typ av arbete.

2. Huvuduppgifterna löses av databankens personal

Personalen på BND inkluderar olika specialister: BND-administratörer, systemanalytiker, system- och applikationsprogrammerare, operatörer, specialister på tekniska medel, marknadsföring, etc.

Låt oss lista de viktigaste funktionerna och uppgifterna som lösts av personalen under utvecklingen och driften av databasen:

1) analys av ämnesområdet (bestämma slutanvändarnas behov, bygga en informationsmodell för ämnesområdet, identifiera integritetsbegränsningar);

2) designa strukturen för databasen (bestämma sammansättningen och strukturen av databasfilerna, beskriva dess schema i databeskrivningsspråket);

3) inställning av databasens integritetsbegränsningar;

4) ladda och underhålla databasen (databasunderhåll inkluderar ändring, radering och tillägg av poster); utveckling av lastnings- och underhållsteknik; utveckling av datainmatningsformulär; datainmatning och kontroll;

5) dataskydd (differentiering av användare, val och verifiering av skyddsmedel, registrering av obehöriga åtkomstförsök);

6) säkerställa databasåterställning;

7) analys av BnD-effektivitet och systemutveckling;

8) arbeta med användare (insamling av svar, utbildning);

9) underhåll av systemprogramvara (förvärv, installation och utveckling);

10) organisatoriskt och metodiskt arbete (val av design- och moderniseringsmetoder, planering av utvecklingen av BND, utveckling av dokumentation).

3. Användare av databanker

Som alla mjukvaru-organisationstekniska komplex existerar en databank i tid och rum. Den har specifika utvecklingsstadier:

Design,

Genomförande,

Stöd,

Uppdatering och utveckling,

Fullständig omorganisation.

I varje skede av tillvaron är olika kategorier av konsumenter kopplade till databanken.

Slutanvändare

Detta är huvudkategorin användare vars intressen är relaterade till databanken. Beroende på egenskaperna hos den skapade databanken kan den skilja sig väsentligt i kretsen av dess slutanvändare. Det kan vara slumpmässiga konsumenter som då och då vänder sig till databasen efter att ha fått viss information, och de kan vara vanliga användare. Tillfälliga kunder kan ses som potentiella kunder till företaget, som bläddrar i en katalog över föreställningar eller tjänster med en generaliserad eller detaljerad beskrivning. Anställda som arbetar med program speciellt utformade för dem, som tillhandahåller automatisering av sina handlingar i utförandet av funktioner, kan vara vanliga användare. Till exempel har en administratör som planerar arbetet med en extra avdelning av ett datorföretag ett program som hjälper honom att planera och ordna aktuella beställningar enligt instruktioner, övervaka utvecklingen av deras produktivitet och organisera nödvändiga tillbehör för nya beställningar i lagret. De huvudsakliga, specialkunskaper som inte bör krävas av slutanvändare inom området språk och datateknik.

Databanksadministratörer

Detta är en grupp användare, som i det inledande skedet av utvecklingen av databanken är ansvarig för dess optimala design ur synvinkeln av den samtidiga driften av en uppsättning slutanvändare, till stöd, scenen är ansvarig för korrekt drift av denna hög med information i fleranvändarläge. Under design- och omorganisationsfasen ansvarar denna grupp för möjligheten att korrekt omorganisera stacken utan att ändra eller slutföra dess löpande underhåll.

Applikationsutvecklare och administratörer

Detta är en grupp användare som fungerar under utformningen, skapandet och omorganisationen av databanken. Applikationsadministratörer samordnar utvecklarnas arbete genom att utveckla en specifik applikation eller grupp av applikationer, förenade i ett funktionellt delsystem. Utvecklare för specifika applikationer arbetar med den information från databasen som krävs för en specifik applikation.

Inte varje databank har alla typer av användare vald. Det är känt att i utvecklingen av informationssystem som använder ett tabellformat DBMS, fanns databanksadministratören, applikationsadministratören och utvecklaren ofta i en person. Men när man skapar moderna komplexa företagsdatabaser som används för att automatisera alla eller stora delar av affärsprocesser i ett stort företag eller företag, kan det finnas applikationsadministratörsgrupper och utvecklingsavdelningar. De svåraste driftslägena är tilldelade gruppen av databasadministratörer.

Låt oss överväga dem mer i detalj.

En del av BnD-administratörsgruppen bör vara:

Systemkommentatorer;

Utvecklare av datastrukturer och utseende gällande informationsstöddatabanken;

Utvecklare av tekniska databehandlingsprocesser;

System- och applikationsprogrammerare;

Driftföretag och experter inom reparationstjänsten.

Kommersiell databanksfråga spelar en viktig roll när man säljer experter.

Huvudfunktionerna för gruppen av DB-administratörer

1. Forskning av dataområdet: beskrivning av dataområdet, packning av texten med integritetsbegränsningar, bestämning av informationens tillstånd (tillgänglighet, konfidentialitet), bestämning av konsumenternas behov, bestämning av överensstämmelsen mellan "datakonsumenter", bestämning av den tidsmässiga volym databehandlingsegenskaper.

2. Utveckling av databasens struktur: definitionen av sammansättningen och strukturen av databasfilerna och mellanliggande anslutningar, valet av metoder för att optimera data och åtkomstmetoder för information, beskrivning av databasen i databeskrivningsspråket (DLS) .

3. Ange integritetsbegränsningar i beskrivningen av databasstrukturen och databasbehandlingsprocedurer:

Att sätta deklarativa integritetsbegränsningar som är inneboende i dataområdet;

Bestämning av dynamiska integritetsbegränsningar som är inneboende i dataområdet vid ändring av informationen som lagras i databasen;

Definitionen av integritetsbegränsningar anropas av databasens struktur;

Utveckling av rutiner för att upprätthålla databasens integritet vid inmatning och korrigering av data;

Bestämning av integritetsbegränsningar genom parallell drift av konsumenter i fleranvändarläge.

4. Starta nedladdningen och vägled databasen

Utveckling av en teknik för att initiera databasladdning, som kommer att skilja sig från proceduren för att ändra och lägga till data med regelbunden användning av databasen;

Utveckling av en teknik för att kontrollera inmatade data, dataområdets verkliga tillstånd. De verkliga objekten i databasmodellerna för något dataområde och korrelationen är mellanliggande, och vid tidpunkten för starten av den aktuella reparationen måste denna modell helt motsvara tillståndet för dataområdesobjekten nu för tiden;

Enligt den utvecklade tekniken för att initiera laddning av systemets design, kan initiering av datainmatning vara nödvändig.

5. Dataskydd

Definiera ett lösenordssystem, principer för att rikta in sig på konsumenter, skapa konsumentgrupper med identiska dataåtkomsträttigheter;

Utveckling av principer för skydd av vissa data och utvecklingsobjekt; utveckling av specialiserade metoder för kodning av information under dess cirkulation i lokala och globala informationsnätverk;

Utveckling av sätt att fixa åtkomst till data och försök att kränka säkerhetssystemet;

Testa skyddssystemet;

Utredning av fall av brott mot skyddssystemet och utveckling av dynamiska metoder för att skydda information i databasen.

6. Stöd för databasåterställning

Utveckling av principer för arkivering av organisatoriska medel och databasåterställning;

Utveckling av ytterligare mjukvara och tekniska processer för databasåterställning efter fel.

7. Undersökning av samtal till databaskonsumenter: en uppsättning statistik om symbolen för förfrågningar, tiden för att slå på deras prestanda, i enlighet med de nödvändiga utdatadokumenten

8. Undersökning av effektiviteten av BnD-funktion:

Undersökning av index för BnD-funktion

Planera omstrukturering (strukturell förändring) av databasen och omorganisation av BND.

9. Arbeta med slutanvändare:

Samla in information om att ändra dataområdet;

Insamling av information om bedömning av BnD-arbete;

Konsumentutbildning, konsumentrådgivning;

Utveckling av nödvändig systematisk och pedagogisk dokumentation gällande slutanvändarnas arbete.

10. Förberedelse och underhåll av systemverktyg:

Forskning av programvara som finns på marknaden och forskning av möjligheten och nödvändigheten av att använda dem inom ramen för BND;

Utveckling av det nödvändiga organisatoriska och tekniska programmet för rörelser för utveckling av BND;

Kontrollera prestandan för den inlösta programvaran innan den ansluts till BND;

Kontroll av anslutningen av den nya mjukvaran till BND.

11. Organisatoriskt och systematiskt arbete i utvecklingen av BND:

Val eller skapande av en metod för databasutveckling;

Fastställande av mål och riktning för utvecklingen av systemet som helhet;

Planera stadierna av BnD-utveckling;

Utveckling av referensböcker för allmänna ordböcker för BND-projektet och en konceptuell modell;

Installation av externa modeller av utvecklade applikationer;

Kontroll av anslutningen av den nya applikationen till BND:s arbete;

Möjlighet till komplex felsökning av en uppsättning applikationer som interagerar från en databas.