Modeli i të dhënave të orientuara nga objekti

Modeli i të dhënave të orientuar nga objekti është një zgjerim i dispozitave të programimit të orientuar nga objekti (ndërsa modeli relacional u ngrit në bazë të teorisë së grupeve, përkatësisht si model i të dhënave). Grupi i Menaxhimit të Bazës së të Dhënave të Objekteve zhvilloi standardin ODMG-93 (Object Database Management Group). Ky standard ende nuk është zbatuar plotësisht.

Struktura e një baze të dhënash të orientuar nga objekti paraqitet grafikisht si një pemë, nyjet e së cilës janë objekte. Struktura e dukshme e një objekti përcaktohet nga vetitë e klasës së tij. Klasa përfshin objekte, ndërsa struktura dhe sjellja e objekteve të së njëjtës klasë janë të njëjta. Çdo objekt, përkatësisht një shembull i një klase, konsiderohet si një pasardhës i objektit në të cilin është përcaktuar si një veti. Vetitë e objektit- ose një tip standard, siç është vargu, ose një lloj klase e ndërtuar nga përdoruesi. Sjellja e objekteve vendoset duke përdorur metoda. Metodaështë një operacion që mund të zbatohet në një objekt.

Si shembull, merrni parasysh bazën e të dhënave "LIBRARY" (Fig. 4.4). Vetitë, llojet dhe vlerat e tyre përcaktohen për secilin objekt. Në DB:

"BIBLIOTEKA" - prind (paraardhës) për "ABONIM", "KATALOG", "RELESA";

"CATALOGUE" është prindi për "LIBR".

"LIBR" - objekte të ndryshme mund të kenë prindër të njëjtë ose të ndryshëm. Nëse i njëjti prind (një autor), atëherë numrat e inventarit janë të ndryshëm, por isbn, UDC, titulli dhe autori janë të njëjtë.

Struktura logjike e një baze të dhënash të orientuar nga objekti është e ngjashme me atë hierarkike, ndryshimi kryesor është në metodat e manipulimit të të dhënave. Në bazën e të dhënave, ju mund të kryeni veprime të tilla si operacione logjike, të përmirësuara nga metodat e orientuara nga objekti të kapsulimit, trashëgimisë dhe polimorfizmit.

Kapsulimi kufizon shtrirjen e emrit të pronës në objektin në të cilin është përcaktuar. Pra, nëse prona shtohet në "KATALOG" telefonit autori i librit, më pas ato fitohen në mënyrë të ngjashme në "ABONIM" dhe "KATALOG". Kuptimi i pronës do të përcaktohet nga objekti në të cilin është mbyllur.

Trashëgimia, anasjelltas, shtrin objektin e pasurisë tek të gjithë pasardhësit e objektit. Pra, të gjitha objekteve të tipit "LIBR", që janë pasardhës të "KATALOG", mund t'u caktohen vetitë e prindit isbn, UDC, titulli dhe autori.

Poliformizmi nënkupton aftësinë e të njëjtit kod programi për të punuar me të dhëna heterogjene. Me fjalë të tjera, do të thotë pranueshmëria që në objekte të llojeve të ndryshme të kenë metoda - procedura dhe funksione - me emra të njëjtë. Gjatë ekzekutimit të një programi objekti, të njëjtat metoda funksionojnë në objekte të ndryshme në varësi të llojit të argumentit. Për bazën e të dhënave "LIBRARY", kjo do të thotë se objektet e klasës "BOOK" që kanë prindër të ndryshëm nga klasa "CATALOG" mund të kenë një grup të ndryshëm vetish, d.m.th. programet për të punuar me një objekt të klasës "BOOK" mund të përmbajnë kod polimorfik. Në klasë, metoda nuk ka një trup, domethënë nuk është e përcaktuar se çfarë veprimesh specifike duhet të kryejë. Çdo nënklasë kryen operacionet e nevojshme. Enkapsulimi fsheh detajet e zbatimit nga të gjitha objektet jashtë hierarkisë së dhënë.

Përparësitë e modelit të orientuar nga objekti në krahasim me atë relacional janë aftësia për të shfaqur informacion në lidhje me marrëdhëniet komplekse të objekteve, mungesa e kufizimeve në strukturat e ruajtjes së të dhënave. Një bazë të dhënash e orientuar nga objekti mund të ruajë jo vetëm strukturën, por edhe aspektet e sjelljes së të dhënave. Duke përdorur qasjen e orientuar nga objekti, mund të krijohen gjithashtu baza të dhënash me sasi të mëdha informacioni semantik, si baza të të dhënave multimediale dhe baza të të dhënave të specializuara për fusha specifike lëndore (gjeografike, dizajni, etj.).

Disavantazhet e kësaj qasje përfshijnë kompleksitetin e lartë konceptual, shqetësimin e përpunimit të të dhënave dhe shpejtësinë e ulët të ekzekutimit të pyetjeve.

Në vitet 1990, u krijuan prototipe të bazave të të dhënave ekzistuese të orientuara nga objekti. Këta janë POET (POET Software), JASMINE (COMPUTER ASSOCIATES), IRIS, ORION, POSTGRES.

Tema 5

Qasja relacionale në ndërtimin e një modeli informacioni-logjik: konceptet bazë

Modeli i të dhënave relacionale. Konceptet bazë

Siç u përmend në seksionin e leksionit të mëparshëm, modeli relacional është aktualisht një nga modelet më të zakonshme në tregun e bazës së të dhënave. Baza e këtij modeli është një grup tabelash (relacione) të ndërlidhura.

Idetë kryesore teorike të modelit relacional u përshkruan në veprat mbi teorinë e marrëdhënieve nga logjika amerikan Charles Souders Peirce (1839-1914) dhe logjika gjerman Ernst Schroeder (1841-1902), si dhe matematikani amerikan Edgar Codd.

Në veprat e Pierce dhe Schroeder, u vërtetua se grupi i marrëdhënieve është i mbyllur nën disa operacione speciale që së bashku formojnë një algjebër abstrakte. Kjo veti thelbësore e marrëdhënieve u përdor në modelin relacional për të zhvilluar një gjuhë të manipulimit të të dhënave.

Në vitin 1970, u shfaq një artikull nga E. Codd mbi paraqitjen e të dhënave të organizuara në formën e tabelave dydimensionale, të quajtura marrëdhënie. Codd fillimisht prezantoi konceptet bazë dhe kufizimet e modelit relacional si bazë për ruajtjen e të dhënave dhe tregoi mundësinë e përpunimit të të dhënave duke përdorur operacione tradicionale në grupe dhe operacione të veçanta të futura relacionale.

Konceptet bazë të modelit relacional janë dhënë në tabelë. 3.1.

Objektet e modelit relacional janë kryesisht tabelat (marrëdhëniet). Integriteti i të dhënave sigurohet nga çelësat e huaj dhe kryesorë (shih seksionin "Integriteti i të dhënave relacionale").

Operatorët në modelin relacional janë një grup udhëzimesh që ofrojnë marrjen dhe manipulimin e të dhënave.

Tabela 5.1. Elementet e modelit relacional

Termi i modelit relacional	Përshkrim
Baza e të dhënave (DB)	Një grup tabelash dhe objektesh të tjera të nevojshme për paraqitjen abstrakte të fushës së zgjedhur lëndore
Skema DB	Një grup titujsh tabelash të lidhura me njëri-tjetrin
Qëndrimi	Tabela - një grup objektesh të botës reale që karakterizohen nga vetitë dhe karakteristikat e përbashkëta (fushat e tabelës)
Kreu i marrëdhënies	Kreu i tabelës - emrat e fushave (kolonave) të tabelës
Trupi i marrëdhënies	Trupi i tabelës është një grup vlerash për të gjitha objektet e botës reale, i cili përfaqësohet si hyrje në tabelë (rreshtat e tabelës)
skema e marrëdhënieve	Rreshti i kokës së kolonës së tabelës (titulli i tabelës)
atribut i lidhjes	Emri i kolonës së tabelës (fusha e tabelës)
relacioni tuple	Rreshti i tabelës (rekord) - një paraqitje një-për-një e një objekti të botës reale të krijuar duke përdorur vlerat e fushës së tabelës
Domeni	Grupi i vlerave të vlefshme të atributeve
Vlera e atributit	Vlera e fushës në rekord (dyfish)
çelesi primar	Një ose më shumë (në rastin e një çelësi të përbërë) atribute që përcaktojnë në mënyrë unike vlerën e tuples (vlera e rreshtit të tabelës)
Çelësi i jashtëm	Një atribut i një tabele, vlerat e së cilës korrespondojnë me vlerat e një çelësi primar në një tabelë tjetër të lidhur (prind, primar). Një çelës i huaj mund të përbëhet nga një ose më shumë atribute (çelës i huaj i përbërë). Nëse numri i atributeve të çelësit të huaj është më i vogël se numri i atributeve të çelësit primar përkatës, atëherë ai quhet çelës i huaj i cunguar (i pjesshëm).
Shkalla (ariteti) i marrëdhënies	Numri i kolonave të tabelës
Fuqia e marrëdhënieve	Numri i rreshtave (tupave) të tabelës
Shembulli i marrëdhënies	Një grup rekordesh (tupash) për një tabelë (relacion) të caktuar. Një shembull mund të ndryshojë me kalimin e kohës. Meqenëse një bazë e të dhënave e rregullt në kohën aktuale punon vetëm me një version të relacionit, një shembull i tillë i relacionit quhet ai aktual.
Lloji i të dhënave	Lloji i vlerës së elementit të tabelës
Raporti bazë	Marrëdhënie që përmban një ose më shumë kolona që karakterizojnë vetitë e objektit, si dhe një çelës primar
Lidhja e prejardhur	Nuk është një lidhje bazë, d.m.th. nuk karakterizon vetitë e objektit dhe përdoret për të siguruar lidhje midis tabelave të tjera, mund të mos përmbajë një çelës primar. Nëse specifikohet një çelës primar, atëherë ai përbëhet nga çelësa të huaj që lidhen me çelësat kryesorë të relacionit bazë.
Lidhje	Vendos një marrëdhënie midis vlerave që përputhen në fushat kryesore - çelësi kryesor i një tabele dhe çelësi i huaj i një tjetri
Komunikimi një me një (1:1)	Kur përdorni këtë lloj marrëdhënieje, një hyrje në një tabelë mund të ketë më së shumti një hyrje të lidhur në një tabelë tjetër. Në të dyja tabelat, fushat kryesore duhet të jenë primare. Përdoret për të ndarë tabela me fusha të shumta ose për kërkesat e mbrojtjes së të dhënave
Marrëdhënie një-me-shumë (1:M)	Kur përdorni këtë lloj marrëdhënieje, çdo rekord i një tabele mund të korrespondojë me disa regjistrime të tabelës së dytë, por çdo rekord i tabelës së dytë korrespondon me vetëm një rekord të tabelës së parë. Tabela e parë duhet të ketë një çelës primar, e dyta duhet të ketë një çelës të huaj.
Marrëdhënie shumë me shumë (N:M)	Me këtë lloj marrëdhënieje, një rekord në tabelën e parë mund të korrespondojë me disa regjistrime të tabelës së dytë, por një rekord i tabelës së dytë mund të korrespondojë me disa regjistrime të të parës. Unike e çelësave për tabela të tilla nuk kërkohet. Në procesin e hartimit të një skeme të bazës së të dhënave, lidhje të tilla transformohen. Për ta bërë këtë, ju duhet të prezantoni një marrëdhënie ndihmëse që ju lejon të zëvendësoni marrëdhënien shumë me shumë me dy marrëdhënie një me shumë

Struktura e të dhënave të modelit relacional supozon përfaqësimin e fushës lëndore të problemit në shqyrtim si një grup marrëdhëniesh të ndërlidhura.

Në secilën marrëdhënie, njëra marrëdhënie mund të veprojë si kryesore (bazë, prind), dhe tjetra si vartëse (e rrjedhur, fëmijë). Për të ruajtur këto lidhje, të dyja marrëdhëniet duhet të përmbajnë një grup atributesh me të cilat lidhen: në relacionin kryesor, ky është çelësi kryesor i relacionit (identifikon në mënyrë unike tuplen e relacionit kryesor); marrëdhënia fëmijë duhet të ketë një grup atributesh që korrespondojnë me çelësin primar të relacionit kryesor. Këtu, ky grup atributesh është tashmë një çelës dytësor ose çelës i huaj, d.m.th. përcakton një grup tuplesh të lidhjeve të prejardhura të shoqëruara me një tufë të vetme të relacionit bazë.

Formohet një grup tabelash të ndërlidhura skema e bazës së të dhënave.

Pra, marrëdhënia Rështë një tabelë dydimensionale që përmban disa të dhëna.

Matematikisht N-relacion ary Rështë grupi i produktit kartezian D 1×D 2×…×Dn grupe (domene) D 1 , D 2 ,…,D n(n≥1), opsionalisht të ndryshme:

R D 1×D 2×…×Dn,

ku D 1×D 2×…×Dnështë produkti i plotë kartezian, d.m.th. një grup kombinimesh të mundshme të n elementeve secili, ku secili element merret nga domeni i tij.

Domeniështë një koncept semantik që mund të mendohet si një nëngrup vlerash të disa llojeve të të dhënave që kanë një kuptim specifik.

Karakteristikat e domenit:

Domeni ka një emër unik (brenda bazës së të dhënave),

Përcaktuar në një lloj të thjeshtë të dhënash ose në një domen tjetër,

Mund të ketë disa kushte boolean për të përshkruar nëngrupin e të dhënave të lejuara për atë domen,

Mban një ngarkesë të caktuar semantike.

Vlera kryesore e domeneve është se ato kufizojnë krahasimet: nuk mund të krahasoni vlera nga fusha të ndryshme, edhe nëse ato kanë të njëjtin lloj të dhënash.

atribut marrëdhënia është një çift i formës

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

Emrat e atributeve brenda një relacioni janë unikë. Shpesh emrat e atributeve janë të njëjtë me emrat përkatës të domeneve.

Një relacion R i përcaktuar në një grup domenesh përmban dy pjesë: një kokë dhe një trup.

Kreu i marrëdhënies– një numër fiks i atributeve të relacionit që përshkruajnë produktin kartezian të domeneve në të cilat është specifikuar relacioni:

(<A1:D1>, <A2: D2 >, …, <A n: D n>).

Kreu është statik: nuk ndryshon gjatë punës me bazën e të dhënave.Nëse atributet ndryshohen, shtohen ose fshihen në relacion, atëherë fitohet një relacion tjetër. Edhe me emrin e ruajtur.

Trupi relacioni përmban një grup tuplesh relacionesh.

Secili dyfishtëështë një grup çiftesh të formës:

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

R(<A1: Val1>, <A2: Val2 >, …, <A n: Val n>).

E tillë që vlera Val i atribut A i i takon domenit D i.

Trupi i relacionit është një grup tuplesh, d.m.th., një nëngrup i produktit kartezian të domeneve. Kështu, trupi i relacionit është në të vërtetë një relacion në kuptimin matematikor të fjalës. Trupi i relacionit mund të ndryshojë gjatë punës me bazën e të dhënave, pasi tuplet mund të ndryshojnë, shtohen dhe hiqen me kalimin e kohës.

Marrëdhënia zakonisht shkruhet si:

R(<A1:D1>, <A2: D2 >, …, <A n: D n>),

ose shkurtuar: R(A 1, A2, …, Një n) ose R.

skema e marrëdhënieveështë një grup titujsh relacioni të përfshirë në bazën e të dhënave, d.m.th., një listë me emrat e atributeve të një relacioni të caktuar, duke treguar domenin të cilit i referohen:

S R =(A 1, A2, …, Një n), A dhe D i, i = 1,...,n.

Nëse atributet marrin vlera nga i njëjti domen, atëherë ato quhen θ-krahasueshme, ku θ është grupi i krahasimeve të vlefshme të specifikuara për këtë fushë.

Për shembull, nëse domeni përmban të dhëna numerike, atëherë të gjitha operacionet e krahasimit lejohen për të: θ == (=,<>,>=,<=,<,>). Sidoqoftë, për domenet që përmbajnë të dhëna karakteresh, mund të specifikohen jo vetëm operacionet e krahasimit për barazinë dhe pabarazinë e vlerave. Nëse një domeni të caktuar i jepet një renditje leksikografike, atëherë ai gjithashtu ka një grup të plotë operacionesh krahasimi.

Skemat e dy marrëdhënieve quhen ekuivalente, nëse kanë të njëjtën shkallë dhe është e mundur të renditen emrat e atributeve në skema të tilla që atributet e krahasueshme, d.m.th., atributet që marrin vlera nga i njëjti domen, të jenë në të njëjtat vende.

Kështu, kushtet e mëposhtme plotësohen për marrëdhëniet ekuivalente:

Duke pasur të njëjtin numër atributesh;

Prania e atributeve me emra të njëjtë;

Prania e vargjeve identike në marrëdhënie, duke marrë parasysh faktin se rendi i atributeve mund të ndryshojë;

Marrëdhëniet e këtij lloji janë paraqitje të ndryshme të së njëjtës marrëdhënie.

Vetitë e marrëdhënies ndjekin drejtpërdrejt nga përkufizimi i mësipërm i një relacioni. Këto veti janë ndryshimet kryesore midis marrëdhënieve të modelit të të dhënave relacionale dhe tabelave të thjeshta:

Veçantia e emrit të lidhjes. Emri i një relacioni duhet të jetë i ndryshëm nga emrat e marrëdhënieve të tjera.

Unike e tuples. Nuk ka tupa identike në lidhje. Në të vërtetë, trupi i relacionit është një grup tufash dhe, si çdo grup, nuk mund të përmbajë elementë të padallueshëm. Tabelat, ndryshe nga marrëdhëniet, mund të përmbajnë rreshta identikë. Çdo qelizë relacioni përmban vetëm një vlerë atomike (të pandashme).

Çrregullim i dyfishtë. Tuplet nuk janë të renditur (nga lart poshtë), pasi trupi i relacionit është një grup, dhe grupi nuk është i renditur (për krahasim, rreshtat në tabela janë të renditura). E njëjta marrëdhënie mund të përfaqësohet nga tabela të ndryshme me rreshta në renditje të ndryshme.

Çrregullimi i atributeve. Atributet nuk janë të renditura (nga e majta në të djathtë).

Veçantia e emrit të atributit brenda marrëdhënies. Çdo atribut ka një emër unik brenda relacionit, që do të thotë se rendi i atributeve nuk ka rëndësi (për krahasim, kolonat në tabelë janë të renditura). Kjo veti e dallon disi një relacion nga përkufizimi matematikor i një relacioni. E njëjta lidhje mund të përfaqësohet nga tabela të ndryshme në të cilat kolonat janë në një rend të ndryshëm.

Atomiciteti i vlerave të atributeve. Të gjitha vlerat e atributeve janë atomike. Kjo rrjedh nga fakti se atributet themelore kanë vlera atomike, d.m.th., disa domene vlerash (lloji elementar i veçantë) shoqërohet me secilën tribut, vlerat e atributeve merren nga i njëjti domen. Skema dhe tuplet e relacionit janë bashkësi, jo lista, kështu që radha në të cilën ato paraqiten nuk ka rëndësi. Për krahasim - informacione të ndryshme mund të vendosen në qelizat e tabelës: vargje, struktura, tabela të tjera, etj.

Koment:

Nga vetitë e relacionit rezulton se jo çdo tabela mund të jetë një lidhje. Në mënyrë që një tabelë e caktuar të përcaktojë një marrëdhënie, është e nevojshme që tabela të ketë një strukturë të thjeshtë (të përmbajë vetëm rreshta dhe kolona, ​​dhe çdo rresht duhet të ketë të njëjtin numër fushash), tabela nuk duhet të ketë të njëjtat rreshta, kolona e tabelës duhet të përmbajë të dhëna të vetëm një lloji, të gjitha llojet e të dhënave të përdorura duhet të jenë të thjeshta.

Duhet theksuar se modeli relacional është një bazë të dhënash në formën e një grupi marrëdhëniesh të ndërlidhura, të cilat quhen skema e bazës së të dhënave relacionale.

Konceptet bazë

Përkufizimi 1

Modeli i orientuar nga objekti përfaqësimi i të dhënave bën të mundur identifikimin e të dhënave individuale të bazës së të dhënave.

Regjistrimet e bazës së të dhënave dhe funksionet e tyre të përpunimit janë të lidhura me mekanizma të ngjashëm me mjetet përkatëse që zbatohen në gjuhët e programimit të orientuara nga objekti.

Përkufizimi 2

Paraqitja grafike Struktura e një baze të dhënash të orientuar nga objekti është një pemë, nyjet e së cilës përfaqësojnë objekte.

Lloji standard (për shembull, vargu - varg) ose një lloj i krijuar nga përdoruesi ( klasës), përshkruan vetitë e objektit.

Në figurën 1, objekti LIBRARY është prindi i objekteve të shembullit të klasave CATALOG, SUBSCRIBER dhe ISSUES. Objekte të ndryshme të tipit BOOK mund të kenë një ose prindër të ndryshëm. Objektet e tipit BOOK që kanë të njëjtin prind duhet të kenë të paktën numra të ndryshëm aksesi (unik për çdo shembull të librit) por të njëjtat vlera të vetive autor, titullin, udk dhe isbn.

Strukturat logjike të një baze të dhënash të orientuar drejt objekteve dhe hierarkike janë të ngjashme nga jashtë. Ato ndryshojnë kryesisht në metodat e manipulimit të të dhënave.

Kur kryeni veprime mbi të dhënat në një model të orientuar nga objekti, përdoren operacione logjike, të cilat përmirësohen nga kapsulimi, trashëgimia dhe polimorfizmi. Me disa kufizime, mund të përdorni operacione që janë të ngjashme me komandat SQL (për shembull, kur krijoni një bazë të dhënash).

Gjatë krijimit dhe modifikimit të një baze të dhënash, indekset (tabelat e indeksit) formohen automatikisht dhe korrigjohen më pas, të cilat përmbajnë informacion për rikthim të shpejtë të të dhënave.

Përkufizimi 3

Synimi kapsulimi– kufizimi i shtrirjes së emrit të pronës në kufijtë e objektit në të cilin është përcaktuar.

Për shembull, nëse një pronë i shtohet objektit CATALOG që specifikon numrin e telefonit të autorit dhe ka emrin telefonit, atëherë do të fitohen vetitë me të njëjtin emër për objektet CATALOG dhe SUBSCRIBER. Kuptimi i një vetie përcaktohet nga objekti në të cilin është mbyllur.

Përkufizimi 4

Trashëgimia, ana e kundërt e kapsulimit, është përgjegjëse për shtrirjen e objektit të pronës tek të gjithë pasardhësit e objektit.

Për shembull, të gjithë objekteve BOOK që janë fëmijë të objektit CATALOG mund t'u caktohen vetitë e objektit prind: autor, titullin, udk dhe isbn.

Nëse është e nevojshme të shtrihet veprimi i mekanizmit të trashëgimisë në objekte që nuk janë të afërm të menjëhershëm (për shembull, për dy pasardhës të të njëjtit prind), një pronë e tipit abstrakt përcaktohet në paraardhësin e tyre të përbashkët. abs.

Pra pronat dhomë dhe biletë në objektin LIBRARIA trashëgohen nga të gjithë objektet fëmijë LENDING, LIBR dhe ABONIN. Kjo është arsyeja pse vlerat e kësaj prone të klasave SUBSCRIBER dhe ISSUANCE janë të njëjta - 00015 (Figura 1).

Përkufizimi 5

Polimorfizmi lejon që i njëjti kod programi të punojë me të dhëna heterogjene.

Me fjalë të tjera, ai lejon që objektet e llojeve të ndryshme të kenë metoda (funksione ose procedura) me të njëjtin emër.

Kërko në një bazë të dhënash të orientuar nga objekti është për të përcaktuar ngjashmërinë midis objektit që përdoruesi specifikon dhe objekteve që ruhen në bazën e të dhënave.

Avantazhet dhe disavantazhet e modelit të orientuar nga objekti

Kryesor avantazh Modeli i të dhënave i orientuar nga objekti në ndryshim nga modeli relacional është aftësia për të shfaqur informacione rreth marrëdhënieve komplekse të objekteve. Modeli i konsideruar i të dhënave lejon përcaktimin e një rekord të veçantë të bazës së të dhënave dhe funksionet e tij të përpunimit.

te mangësitë Modeli i orientuar nga objekti përfshin kompleksitetin e lartë konceptual, përpunimin e papërshtatshëm të të dhënave dhe shpejtësinë e ulët të ekzekutimit të pyetjeve.

Deri më sot, sisteme të tilla janë mjaft të përhapura. Këto përfshijnë DBMS:

• postgres,
• orion,
• iris,
• ODBJupiter,
• Shumëllojshëm,
• Objektiviteti/DB,
• dyqan objektesh,
• statike,
• gur i çmuar
• g bazë.

Në OOMD, gjatë paraqitjes së të dhënave, është e mundur të identifikohen të dhënat individuale të bazës së të dhënave. Marrëdhëniet krijohen midis regjistrimeve të bazës së të dhënave dhe funksioneve të tyre të përpunimit duke përdorur mekanizma të ngjashëm me mjetet përkatëse në gjuhët e programimit të orientuara nga objekti.

Një model i standardizuar i orientuar nga objekti përshkruhet në rekomandimet e standardit ODMG-93 (Object Database Management Group - një grup i menaxhimit të bazës së të dhënave të orientuar nga objekti). Nuk ka qenë ende e mundur të zbatohen plotësisht rekomandimet e ODMG-93. Për të ilustruar idetë kryesore, merrni parasysh një model disi të thjeshtuar të një baze të dhënash të orientuar nga objekti.

Struktura e një baze të dhënash të orientuar nga objekti (OODB) paraqitet grafikisht si një pemë, nyjet e së cilës janë objekte. Karakteristikat e objektit përshkruhen nga një lloj standardi (për shembull, varg - varg) ose një lloj i ndërtuar nga përdoruesi (i përcaktuar si një klasë).

Vlera e një vetie të tipit string është një varg karakteresh. Vlera e një vetie të klasës së tipit është një objekt që është një shembull i klasës përkatëse. Çdo objekt i shembullit të klasës konsiderohet një fëmijë i objektit në të cilin është përcaktuar si një veti. Një objekt shembulli i një klase i përket klasës së saj dhe ka një prind. Marrëdhëniet gjenerike në bazën e të dhënave formojnë një hierarki koherente të objekteve.

Një shembull i strukturës logjike të një OODB për bibliotekari është paraqitur në fig. 2.8.

Këtu, objekti i tipit LIBRARRY është objekti prind i instancës së klasave SUBSCRIBER, CATALOG dhe ISSUANCE. Objekte të ndryshme të tipit BOOK mund të kenë prindër të njëjtë ose të ndryshëm. Objektet e tipit BOOK që kanë të njëjtin prind duhet të ndryshojnë nga të paktën një numër aksesi (unik për çdo shembull libri), por të kenë të njëjtat vlera të vetive isbn, udk, emër dhe autor.

Oriz. 2.8. Struktura logjike e bazës së të dhënave të bibliotekarisë

Struktura logjike e OODB është nga jashtë e ngjashme me strukturën e IDB. Dallimi kryesor midis tyre është në metodat e manipulimit të të dhënave.

Për të kryer veprime mbi të dhënat në modelin e marrë në konsideratë të bazës së të dhënave, përdoren operacione logjike, të përmirësuara nga mekanizmat e orientuar drejt objektit të kapsulimit, trashëgimisë dhe polimorfizmit. Operacione të ngjashme me komandat SQL mund të përdoren në një masë të kufizuar (për shembull, për të krijuar një bazë të dhënash).

Krijimi dhe modifikimi i bazës së të dhënave shoqërohet me formimin automatik dhe rregullimin e mëvonshëm të indekseve (tabelave të indekseve) që përmbajnë informacion për marrjen e shpejtë të të dhënave.

Le të shqyrtojmë shkurtimisht konceptet e kapsulimit, trashëgimisë dhe polimorfizmit në lidhje me modelin e bazës së të dhënave të orientuar nga objekti.

Kapsulimi kufizon shtrirjen e emrit të pronës në objektin në të cilin është përcaktuar. Pra, nëse një objekti të tipit CATALOG i shtojmë një veti që specifikon numrin e telefonit të autorit të librit dhe ka emrin telefon, atëherë do të marrim vetitë me të njëjtin emër për objektet ABONIN dhe CATALOG. Kuptimi i një vetie të tillë do të përcaktohet nga objekti në të cilin është i kapsuluar.

Trashëgimia, në vend të kësaj, ajo shtrin objektin e pronës për të gjithë pasardhësit e objektit. Pra, të gjithë objekteve të tipit BOOK, që janë pasardhës të një objekti të tipit CATALOG, mund t'u caktohen vetitë e objektit prind: isbn, udk, titull dhe autor. Nëse është e nevojshme të shtrihet veprimi i mekanizmit të trashëgimisë në objekte që nuk janë të afërm të menjëhershëm (për shembull, midis dy pasardhësve të të njëjtit prind), atëherë një veti abstrakte e tipit abs përcaktohet në paraardhësin e tyre të përbashkët. Kështu, përcaktimi i biletës dhe numrit të pronave abstrakte në objektin LIBRARIA çon në trashëgiminë e këtyre pronave nga të gjithë objektet fëmijë të ABONINIT, LIBRIT dhe EMËSIMIT. Nuk është rastësi që prandaj vlerat e pasurisë biletë Klasat ABONIN dhe LËSHIM të paraqitura në figurë do të jenë të njëjta - 00015.

Polimorfizmi në Gjuhët e programimit të orientuara nga objekti nënkupton aftësinë e të njëjtit kod programi për të punuar me të dhëna heterogjene. Me fjalë të tjera, do të thotë se objektet e llojeve të ndryshme mund të kenë metoda (procedura ose funksione) me të njëjtin emër. Gjatë ekzekutimit të një programi objekti, të njëjtat metoda funksionojnë në objekte të ndryshme në varësi të llojit të argumentit. Në lidhje me bazën tonë të të dhënave të orientuar nga objekti, polimorfizmi do të thotë që objektet e klasës BOOK që kanë prindër të ndryshëm nga klasa CATALOG mund të kenë një grup karakteristikash të ndryshme. Rrjedhimisht, programet për të punuar me objekte të klasës BOOK mund të përmbajnë kod polimorfik.

Kërkimi në OODB konsiston në gjetjen e ngjashmërisë midis objektit të specifikuar nga përdoruesi dhe objekteve të ruajtura në bazën e të dhënave. Një objekt i përcaktuar nga përdoruesi i quajtur një objekt objektiv (një veti e një objekti ka lloji iqëllimi), në rastin e përgjithshëm, mund të jetë një nëngrup i të gjithë hierarkisë së objektit të ruajtur në bazën e të dhënave. Objekti i synuar, si dhe rezultati i ekzekutimit të pyetjes, mund të ruhen në vetë bazën e të dhënave. Një shembull i një pyetjeje në lidhje me numrat e kartave të bibliotekës dhe emrat e pajtimtarëve që kanë marrë të paktën një libër në bibliotekë është paraqitur në Fig. 2.9.

Oriz. 2.9. Fragment i një baze të dhënash me një objekt të synuar

Kryesor dinjitet OOMD në krahasim me relacional është aftësia për të shfaqur informacion në lidhje me marrëdhëniet komplekse të objekteve. OOMD ju lejon të identifikoni një rekord të vetëm të bazës së të dhënave dhe të përcaktoni funksionet e përpunimit të tyre.

Kryesor mangësitë OOMD janë kompleksiteti i lartë konceptual, shqetësimi i përpunimit të të dhënave dhe shpejtësia e ulët e ekzekutimit të pyetjeve.

Në vitet '90, kishte prototipe eksperimentale të OODBMS. Aktualisht, ka më shumë se 300 DBMS të tilla. Disa sisteme janë relativisht të përhapura, si DBMS-të e mëposhtme: Cache (InterSystems), ROET (ROET Software), Jasmine (Computer Associates), Versant (VersantTechnologies), O2 (ArdentSoftware), ODB-Jupiter (Qendra Kërkimore dhe Prodhimi "Inteltech Plus " ), si dhe Iris, Orion dhe Postgres.

Përparësitë e OODB në të ardhmen duhet të çojnë në shpërndarjen e tyre shumë të gjerë. Për ta bërë këtë, së pari duhet të zgjidhni problemet e eliminimit të mangësive të qenësishme të OODB: të rrisni fleksibilitetin e strukturës së bazës së të dhënave, të ndërtoni një gjuhë të qartë programimi, të përpunoni sintaksën për analizimin e pyetjeve, të përcaktoni disa metoda të aksesit të të dhënave, të përpunoni çështjet e aksesit të njëkohshëm, përcaktojnë numërimin kompleks të të dhënave, përpunojnë mbrojtjen dhe rikuperimin e të dhënave. Lista e detyrave që duhet të zgjidhen mund të vazhdohet.

Sidoqoftë, edhe pas zgjidhjes së këtyre problemeve, kalimi në OODB do të jetë gradual dhe jo shumë i shpejtë, pasi do të jetë e vështirë të shkëputeni nga numri i madh i DBMS relacionale ekzistuese për arsye objektive dhe subjektive. Për ta bërë një tranzicion të tillë më pak të dhimbshëm do të lejojë përfshirjen në OODBMS jo vetëm të objektit, por edhe të komponentit relacional. Për më tepër, MMD duhet të futet në OODBMS për të formuar një depo të dhënash sistemet OLAP, të cilat janë gjithnjë e më të kërkuara në praktikë.

Teknologjitë e bazës së të dhënave të bazuara në MD të përshkruar më sipër bazohen në konceptin statik të ruajtjes së informacionit, të fokusuar në modelimin e të dhënave. Megjithatë, fusha të reja të aplikimit të teknologjisë me objekte komplekse, të ndërlidhura të bazës së të dhënave, të tilla si:

Dizajn me ndihmën e kompjuterit;

Prodhim i automatizuar;

Zhvillimi i automatizuar i softuerit;

Sistemet e informacionit të zyrës;

Sisteme multimediale;

Sisteme gjeoinformative;

Sistemet e botimit dhe të tjerët kanë demonstruar kufizimet e konceptit statik në drejtim të modelimit të objekteve të botës reale.

Për llojet e reja të aplikacioneve komplekse të specializuara të bazës së të dhënave, koncepti dinamik i ruajtjes së informacionit është efektiv, duke lejuar modelimin paralel të të dhënave dhe proceseve që veprojnë mbi këto të dhëna. Kjo lejon që dikush të marrë parasysh semantikën e fushës lëndore dhe për këtë arsye të përshkruajë në mënyrë më të përshtatshme këto aplikime. Ky koncept bazohet në qasjen e orientuar drejt objektit të përdorur gjerësisht në zhvillimin e softuerit. MD që zbaton këtë koncept dhe bazohet në paradigmën e orientuar drejt objektit (OOP) quhet modeli i të dhënave të orientuara nga objekti (OODM).

Ndërtimi i OOMD bazohet në supozimin se zona e subjektit mund të përshkruhet nga një grup objektesh. Çdo objekt është një entitet i identifikueshëm në mënyrë unike që përmban atribute që përshkruajnë gjendjen e objekteve të "botës reale" dhe veprimet e tyre të lidhura. Gjendja aktuale e një objekti përshkruhet nga një ose më shumë atribute, të cilat mund të jenë të thjeshta ose komplekse. Një atribut i thjeshtë mund të ketë një tip primitiv (për shembull, numër i plotë, varg, etj.) dhe të marrë një vlerë të mirëfilltë. Një atribut i përbërë mund të përmbajë koleksione dhe/ose lidhje. Një atribut i lidhjes përfaqëson një marrëdhënie midis objekteve.

Vetia kryesore e një objekti është unike e identifikimit të tij. Prandaj, çdo objekt në një sistem të orientuar nga objekti duhet të ketë identifikuesin e tij.

Një identifikues i objektit (OID) është një mënyrë e brendshme e bazës së të dhënave për të shënuar objekte individuale. Përdoruesit që punojnë me një pyetje ose punë dialogu të shikimit zakonisht nuk i shohin këta identifikues. Ato caktohen dhe përdoren nga vetë DBMS. Semantika e identifikuesit në çdo DBMS është e ndryshme. Mund të jetë ose një vlerë e rastësishme ose të përmbajë informacionin e nevojshëm për të gjetur objektin në skedarin e bazës së të dhënave, siç është numri i faqes në skedar dhe zhvendosja e objektit që nga fillimi i tij. Është identifikuesi që duhet të përdoret për të organizuar referencat ndaj objektit.

Të gjitha objektet janë të kapsuluara, domethënë, përfaqësimi ose struktura e brendshme e objektit mbetet e fshehur nga përdoruesi. Në vend të kësaj, përdoruesi e di vetëm se objekti mund të kryejë disa funksione. Për shembull, për një objekt WAREHOUSE mund të aplikohen metoda të tilla si ACCEPT_ITEM, ISSUE_TOBAP, etj. Avantazhi i kapsulimit është se ju lejon të ndryshoni paraqitjen e brendshme të objekteve pa ridizajnuar aplikacionet që përdorin këto objekte. Me fjalë të tjera, kapsulimi nënkupton pavarësinë e të dhënave.

Një objekt përmbledh të dhënat dhe funksionet (metodat, sipas OOP). Metodat përcaktojnë sjelljen e një objekti. Ato mund të përdoren për të ndryshuar gjendjen e një objekti duke ndryshuar vlerat e atributeve të tij, ose për të kërkuar vlerat e atributeve të zgjedhura. Për shembull, mund të ketë metoda për të shtuar informacione për një pronë të re me qira, për të përditësuar informacionin e pagës së një punonjësi ose për të printuar informacione për një produkt të caktuar.

Objektet që kanë të njëjtin grup atributesh dhe u përgjigjen të njëjtave mesazhe mund të grupohen në Klasa(në literaturë, termat "klasë" dhe "lloj" shpesh përdoren në mënyrë të ndërsjellë). Çdo klasë e tillë ka përfaqësuesin e vet - një objekt, i cili është elementi i të dhënave. Quhen objekte të një klase të caktuar kopje.

Në disa sisteme të orientuara nga objekti, një klasë është gjithashtu një objekt dhe ka atributet dhe metodat e veta të quajtura atributet e klasës dhe metodat e klasës.

Konceptet e rëndësishme të OOP janë hierarkia e klasës dhe hierarkia e kontejnerëve.

hierarkia e klasës nënkupton mundësinë që çdo klasë, e quajtur në këtë rast superklasë, të ketë nënklasën e saj. Zinxhiri i mëposhtëm mund të citohet si shembull: të gjithë programuesit e një ndërmarrje janë punonjësit e saj, prandaj, secili programues që, në kuadër të OODM, është një objekt i klasës PROGRAMMER, ai është gjithashtu një punonjës, i cili nga ana tjetër , është një objekt i klasës EMPLOYEES. Kështu, PROGRAMERËT do të ishin një nënklasë, STAFF do të ishte një superklasë. Por programuesit mund të ndahen edhe në programues të sistemit dhe të aplikacioneve. Prandaj, PROGRAMMERS do të jetë një superklasë për nënklasat SIS_PROGRAMMERS dhe APPLIC_PROGRAMMERS. Duke vazhduar më tej këtë zinxhir, marrim një hierarki të klasës, në të cilën çdo objekt nënklasë trashëgon instancat e variablave dhe metodat e superklasës përkatëse.

Ekzistojnë disa lloje të trashëgimisë - të vetme, të shumëfishta dhe selektive. Trashëgimi singulare është kur nënklasat trashëgojnë më së shumti nga një superklasë. Trashëgimia e shumëfishtë - trashëgimi nga më shumë se një superklasë. Trashëgimia selektive lejon një nënklasë të trashëgojë një numër të kufizuar pronash nga superklasa e saj.

Trashëgimia e instancës së ndryshueshme quhet trashëgimi strukturore, trashëgimia e metodës - trashëgimia e sjelljes, dhe aftësia për të përdorur të njëjtën metodë për klasa të ndryshme, ose më mirë për të përdorur metoda të ndryshme me të njëjtin emër për klasa të ndryshme, quhet polimorfizëm.

Arkitektura e orientuar nga objekti ka gjithashtu një lloj tjetër hierarkie - hierarkia e kontejnerëve. Ai konsiston në faktin se disa objekte mund të përmbahen konceptualisht brenda të tjerëve. Kështu, një objekt i klasës DEPARTMENT duhet të përmbajë një ndryshore publike HEAD, e cila është një referencë për objektin e klasës EMPLOYEE që korrespondon me drejtuesin e departamentit, dhe gjithashtu duhet të përmbajë një referencë për një grup referencash për objektet që korrespondojnë me punonjësit që punojnë në këtë departament.

Në disa sisteme të orientuara nga objekti, një klasë është gjithashtu një objekt dhe ka atributet dhe metodat e veta. Karakteristikat e përgjithshme të një klase përshkruhen nga atributet e saj. Metodat e një klase objekti janë një lloj analog i vetive të objekteve në botën reale. Çdo objekt që i përket një klase të caktuar ka këto veti. Prandaj, kur krijohet një objekt, është e nevojshme të deklarohet klasa së cilës i përket në mënyrë që të përcaktohen vetitë e tij të qenësishme.

Përdoruesi dhe objekti ndërveprojnë përmes mesazheve. Në përgjigje të çdo mesazhi, sistemi ekzekuton metodën përkatëse.

Të gjitha marrëdhëniet në modelin e objektit bëhen duke përdorur atributet e referencës, të cilat zakonisht zbatohen si OID.

Marrëdhëniet në një bazë të dhënash relacionale përfaqësohen nga përputhja e çelësave primar dhe të huaj. Nuk ka struktura në vetë bazën e të dhënave për formimin e lidhjeve midis tabelave; lidhjet përdoren sipas nevojës kur lidhin tabelat. Në të kundërt, marrëdhëniet janë shtylla kurrizore e një baze të dhënash të orientuar nga objekti, sepse çdo objekt përfshin ID-të e objekteve me të cilat shoqërohet.

Në OOMD, jo vetëm lidhjet tradicionale, por edhe lidhjet për shkak të trashëgimisë mund të zbatohen.

Marrëdhënie një me një (1:1) ndërmjet objekteve A dhe B zbatohet duke shtuar një atribut referimi në objektin B tek objekti A dhe (për të ruajtur integritetin referencial) një atribut referimi në objektin A tek objekti B.

Marrëdhënie një-me-shumë (1:M) ndërmjet objekteve A dhe B zbatohet duke shtuar një atribut referimi për objektin B në objektin A dhe një atribut që përmban një grup lidhjesh për objektin A me objektin B (për shembull, shtohet një atribut referimi B (OID2, OID3 ...) tek objekti A, dhe instancat e objektit B me OID2, OID3, ... atributi i referencës A shtohet: OID1.

Marrëdhënie shumë me shumë (M:N) ndërmjet objekteve A dhe B zbatohet duke shtuar një atribut që përmban një grup lidhjesh për çdo objekt.

Në OODM, mund të përdorni marrëdhënien "të gjithë pjesë", e cila përshkruan se një objekt i një klase përmban objekte të klasave të tjera si pjesë të tij. Në rastin e një baze të dhënash prodhimi, do të kishte një marrëdhënie "të plotë" midis klasës PRODUCT dhe klasave PJESË dhe ASSEMBLY. Kjo marrëdhënie është një variant i marrëdhënies shumë-për-shumë që ka semantikë të veçantë. Një marrëdhënie e plotë-pjese zbatohet si çdo marrëdhënie tjetër shumë-për-shumë, me një grup identifikuesish objektesh të lidhur. Megjithatë, ajo, ndryshe nga marrëdhënia e zakonshme shumë-për-shumë, ka një kuptim tjetër semantik.

Meqenëse paradigma e orientuar nga objekti mbështet trashëgiminë, është e mundur të përdoret një marrëdhënie "është" dhe një marrëdhënie "shtrihet" në OODM. Marrëdhënia "është", e njohur edhe si marrëdhënia përgjithësim-specializim, krijon një hierarki trashëgimie në të cilën nënklasat janë raste të veçanta të superklasave. Kjo lejon që të mos përshkruhen veçoritë e ritrashëguara. Kur përdorni marrëdhënien "zgjeron", nënklasa zgjeron funksionalitetin e superklasës në vend që të kufizohet në rastin e saj të veçantë.

Le të shqyrtojmë se si komponentë të tillë si kufizimet e integritetit dhe operacionet mbi të dhënat zbatohen në OOMD.

Karakteristikat e këtyre komponentëve përcaktohen nga specifikat e modelit. Kjo specifikë në OOMD diktohet kryesisht nga koncepte të tilla të brendshme si përmbledhja e objektit, d.m.th., fshehtësia e strukturës së brendshme, aksesi në të dhëna vetëm përmes metodave të përcaktuara paraprakisht, hierarkia e klasës dhe hierarkia e kontejnerit.

Specifikat e OOMD-së diktohen edhe nga specifikat e objektit. Ajo manifestohet në nevojën për të grupuar objektet në klasa. Çdo objekt përfshihet në një klasë ose në një tjetër në varësi të detyrës, dhe një objekt mund t'i përkasë disa klasave në të njëjtën kohë (për shembull, PROGRAMERËT dhe familjet me PAGUA TË LARTË). Një veçori tjetër specifike e një objekti është se ai mund të "drejtojë" nga një klasë (nënklasë) në tjetrën. Kështu, një PROGRAMER SISTEMOR mund të bëhet përfundimisht një PROGRAMER I APLIKUAR. Kështu, hierarkia e klasës nuk është analoge me modelin hierarkik, siç mund të duket më parë, por kërkon që sistemi të jetë në gjendje të ndryshojë vendndodhjen e secilit objekt brenda hierarkisë së klasës, për shembull, të lëvizë "lart" ose "poshtë" brenda këtë hierarki. Por një proces më kompleks është gjithashtu i mundur - sistemi duhet të sigurojë aftësinë e një objekti për t'u bashkuar (shkëputur) në një majë arbitrare të hierarkisë në çdo kohë.

Kufizimet e integritetit të lidhjes luajnë një rol të rëndësishëm në OODM. Që lidhjet në një DM të orientuar nga objekti të funksionojnë, identifikuesit e objekteve në të dy anët e lidhjes duhet të përputhen. Për shembull, nëse ka një marrëdhënie midis PUNONJËSVE dhe FËMIJËVE të tyre, atëherë duhet të ketë disa garanci që kur një objekt që përshkruan një fëmijë futet në një objekt që përfaqëson një punonjës, ID e punonjësit i shtohet objektit përkatës. Ky lloj integriteti i lidhjes, disi analog me integritetin referencial në modelin e të dhënave relacionale, krijohet me ndihmën e lidhjeve prapa. Për të siguruar integritetin e lidhjeve, projektuesi pajiset me sintaksën speciale të nevojshme për të specifikuar vendndodhjen e identifikuesit të kundërt të objektit. Është përgjegjësi e projektuesit të vendosë kufizime në integritetin e marrëdhënieve (si dhe integritetin referencial në një bazë të dhënash relacionale).

Në OOMD, si përshkrimi i të dhënave ashtu edhe manipulimi i tyre ndodh duke përdorur të njëjtën gjuhë procedurale të orientuar nga objekti.

ODMG (Object Database Management Group) merret me problemet e standardizimit të teknologjisë së bazave të të dhënave të objekteve. Ajo ka zhvilluar një model objekti (ODMG 2.0 u miratua në shtator 1997) që përcakton një model standard për semantikën e objekteve të bazës së të dhënave. Ky model është i rëndësishëm sepse përcakton semantikën e integruar që një DBMS e orientuar nga objekti (OODBMS) kupton dhe mund të zbatojë. Struktura e bibliotekave dhe aplikacioneve që përdorin këtë semantikë duhet të jetë e lëvizshme midis OODBMS të ndryshme që mbështesin modelin e dhënë të të dhënave të objektit. Komponentët kryesorë të arkitekturës ODMG janë: Modeli i objektit (OM), Gjuha e përkufizimit të objektit (ODL), Gjuha e pyetjes së objektit (OQL) dhe aftësia për t'u lidhur me C++, Java dhe Smalltalk.

Modeli i të dhënave të objektit në përputhje me standardin ODMG 2.0 karakterizohet nga vetitë e mëposhtme:

Blloqet bazë të ndërtimit janë objektet dhe fjalë për fjalë. Çdo objekt ka një identifikues unik. Një literal nuk ka identifikuesin e vet dhe nuk mund të ekzistojë veçmas si objekt. Literalet janë gjithmonë të ngulitura në objekte dhe nuk mund të referohen individualisht;

Objektet dhe fjalë për fjalë ndryshojnë sipas llojit. Çdo lloj ka domenin e vet, të ndarë nga të gjitha objektet dhe fjalë për fjalë të atij lloji. Llojet mund të kenë edhe sjellje. Nëse një lloj ka një sjellje, atëherë të gjitha objektet e atij lloji kanë të njëjtën sjellje. Në praktikë, lloji mund të jetë klasa nga e cila është krijuar objekti, një ndërfaqe ose një lloj i thjeshtë i të dhënave (si p.sh. një numër i plotë). Një objekt mund të mendohet si një shembull i një lloji;

Gjendja e një objekti përcaktohet nga një grup vlerash aktuale të zbatuara nga një grup karakteristikash. Këto veti mund të jenë atribute të një objekti ose marrëdhënie midis një objekti dhe një ose më shumë objekteve të tjera;

Sjellja e një objekti përcaktohet nga një grup veprimesh që mund të kryhen në objekt ose në vetë objektin. Operacionet mund të kenë një listë të parametrave të hyrjes dhe daljes, secila prej të cilave ka një lloj të përcaktuar rreptësisht. Çdo operacion mund të kthejë gjithashtu një rezultat të shtypur;

Përkufizimi i bazës së të dhënave ruhet në një skemë të shkruar në gjuhën e përkufizimit të objektit (ODL). Baza e të dhënave ruan objektet, duke i lejuar ato të ndahen midis përdoruesve dhe aplikacioneve të ndryshme.

DBMS të bazuara në OODM quhen DBMS të orientuara nga objekti (OODBMS). Këto DBMS referohen si DBMS e gjeneratës së tretë* (* Historia e zhvillimit të modeleve të ruajtjes së të dhënave shpesh ndahet në tre faza (gjenerata): gjenerata e parë (fundi i viteve 1960 - fillimi i viteve 70) - modele hierarkike dhe rrjetore; gjenerata e dytë (afërsisht 1970-1980) - modeli relacional; i treti gjeneratë (1980 - fillimi i viteve 2000) - modele të orientuara nga objekti.).

Sot, bazat e të dhënave të orientuara nga objekti përdoren në organizata të ndryshme për të zgjidhur një gamë të gjerë problemesh. Analiza dhe përgjithësimi i përvojës së akumuluar në fushën e të dhënave të teknologjisë së informacionit bëri të mundur identifikimin e aplikacioneve në të cilat justifikohet përdorimi i bazave të të dhënave të orientuara nga objekti:

Një aplikacion përbëhet nga një numër i madh pjesësh ndërvepruese. Secila prej tyre ka sjelljen e vet, e cila varet nga sjellja e të tjerëve;

Sistemi duhet të përpunojë sasi të mëdha të strukturës së të dhënave të pastrukturuara ose komplekse;

Aplikacioni do të kryejë akses të parashikueshëm në të dhëna, kështu që natyra lundruese e bazave të të dhënave të orientuara nga objekti nuk do të jetë një disavantazh i rëndësishëm;

Nevoja për kërkesa të paplanifikuara është e kufizuar;

Struktura e të dhënave të ruajtura është hierarkike ose e ngjashme në natyrë.

Për momentin, ka shumë DBMS të orientuara nga objekti në tregun e softuerit. Në tabelë. 10.6 tregon disa nga sistemet komerciale të kësaj klase.

Tabela 10.6

OODBMS komerciale moderne,

kompanitë e tyre prodhuese dhe fushat e aplikimit

Një nga ndryshimet themelore midis bazave të të dhënave të objekteve dhe bazave të të dhënave relacionale është aftësia për të krijuar dhe përdorur lloje të reja të dhënash. Një tipar i rëndësishëm i OODBMS është se krijimi i një lloji të ri nuk kërkon modifikim të bazës së bazës së të dhënave dhe bazohet në parimet e programimit të orientuar nga objekti.

Kerneli OODBMS është optimizuar për operacione me objekte. Veprimet e tij natyrore janë ruajtja e objekteve, versionimi i objekteve dhe ndarja e të drejtave të aksesit në objekte specifike. OODBMS karakterizohen nga performanca më e lartë në operacionet që kërkojnë akses dhe rikthim të të dhënave të paketuara në objekte, krahasuar me DBMS-të relacionale, për të cilat nevoja për të marrë të dhëna të lidhura çon në operacione shtesë të brendshme.

Me rëndësi të konsiderueshme për OODBMS është aftësia për të lëvizur objektet nga një bazë të dhënash në tjetrën.

Kur krijoni aplikacione të ndryshme të bazuara në OODBMS, struktura e integruar e klasës së një DBMS të veçantë është e rëndësishme. Biblioteka e klasës, si rregull, mbështet jo vetëm të gjitha llojet standarde të të dhënave, por edhe një grup të zgjeruar të multimedias dhe llojeve të tjera komplekse të të dhënave, të tilla si video, tinguj, sekuenca të kornizave të animacionit. Në disa OODBMS, janë krijuar biblioteka të klasave që mundësojnë ruajtjen dhe kërkimin e tekstit të plotë të informacionit dokumentar (për shembull, Jasmine, ODB-Jupiter). Një shembull i strukturës bazë të klasës është paraqitur në fig. 10.17.

Pozicioni kryesor në të është i zënë nga klasa TOdbObject, e cila përmban të gjitha vetitë dhe metodat e nevojshme për kontrollin e aksesit në bazën e të dhënave dhe kryerjen e indeksimit. Të gjitha klasat e tjera anashkalojnë metodat e tij, duke shtuar vërtetimin e llojit që zbatojnë dhe një indeksues specifik.

Siç shihet nga fig. 10.17, në strukturë ka klasa të ndryshme të fokusuara në përpunimin e informacionit dokumentar - TOdbText, TOdbDocument, TODBTextDocument, etj. Çdo dokument përfaqësohet nga një objekt i veçantë. Kështu, sigurohet natyraliteti i ruajtjes së dokumenteve. Një nga operacionet më të rëndësishme është kërkimi i dokumenteve sipas kërkesës. Për shumicën e klasave, zbatohet aftësia për të kërkuar objekte sipas vlerës së një çelësi specifik. Për klasën TOdbText, zbatohet aftësia për të gjeneruar një pyetje kërkimi bazuar në një frazë të shkruar në gjuhë natyrore.

Klasa TOdbDocument është e veçantë, e aftë të përmbajë objekte të llojeve të ndryshme. Ai përbëhet nga fusha, secila prej të cilave ka një emër dhe shoqërohet me një objekt të një lloji të caktuar. Prania e kësaj klase i jep përdoruesit mundësinë për të zgjeruar grupin e llojeve. Duke modifikuar objektin e kontejnerit (dokumentin), mund të vendosni një grup specifik fushash dhe të merrni një lloj të ri Dokumenti.

Mbi bazën e ODB-Jupiter, zhvilluesit e OODBMS kanë krijuar një sistem të plotë të rikthimit të informacionit ODB-Text, i cili ka një strukturë universale të të dhënave të ruajtura dhe një mekanizëm të fuqishëm kërkimi. Sistemi ODB-Text është një mjet për përpunimin kolektiv të dokumenteve dhe mbajtjen e një arkivi të korporatës. Ndër aplikimet e mundshme do të përmendim automatizimin e kontabilitetit për rrjedhën e dokumenteve të një zyre moderne, ndërtimin e sistemeve të referencës dhe informacionit (të ngjashme me bazat e njohura të të dhënave ligjore), mirëmbajtjen e bazave të të dhënave të rrjetit, të dhënat e personelit, bibliografinë, etj. etj.

41. Karakteristikat e projektimit të IS të aplikuar. Fazat e zhvillimit të IS. (Tema 11, fq. 100-103).

11.1.3. Karakteristikat e dizajnit të sistemit të IC të aplikuar

Kur ndërtoni (përzgjedhni, përshtatni) një sistem informacioni, mund të përdorni dy koncepte kryesore, dy qasje kryesore (koncepti i tretë është kombinimi i tyre):

1. Orientimi në problemet që duhet të zgjidhen me ndihmën e këtij sistemi informacioni, d.m.th. qasje e orientuar drejt problemit (ose qasje induktive);

2. fokusimi në teknologjinë që është e disponueshme (përditësuar) në një sistem, mjedis të caktuar, d.m.th. qasje e orientuar nga teknologjia (ose qasje deduktive).

Zgjedhja e konceptit varet nga kriteret strategjike (taktike) dhe (ose) afatgjata (afatshkurtra), problemet, burimet.

Nëse fillimisht studiohen mundësitë e teknologjisë së disponueshme dhe më pas përcaktohen problemet aktuale që mund të zgjidhen me ndihmën e tyre, atëherë është e nevojshme të mbështetemi në një qasje të orientuar nga teknologjia.

Nëse fillimisht identifikohen problemet aktuale dhe më pas futet teknologjia e mjaftueshme për zgjidhjen e këtyre problemeve, atëherë është e nevojshme të mbështetemi në një qasje të bazuar në problem.

Në të njëjtën kohë, të dy konceptet e ndërtimit të një sistemi informacioni varen nga njëri-tjetri: futja e teknologjive të reja ndryshon problemet që zgjidhen dhe ndryshimi i problemeve që zgjidhen çon në nevojën për të futur teknologji të reja; Të dyja këto ndikojnë në vendimet që merren.

Dizajni (zhvillimi) i sistemit dhe përdorimi i çdo sistemi informacioni të aplikuar (korporativ) duhet të kalojë në ciklin e mëposhtëm të jetës së sistemit të informacionit:

- analiza para projektit (përvojë në krijimin e sistemeve të tjera të ngjashme, prototipave, dallimeve dhe veçorive të sistemit që po zhvillohet, etj.), Analiza e manifestimeve të jashtme të sistemit;

– analiza intrasistem, analiza e brendshme (analiza e nënsistemeve të sistemit);

- përshkrimi (përfaqësimi) i sistemit (morfologjik) i sistemit (përshkrimi i qëllimit të sistemit, marrëdhëniet dhe lidhjet e sistemit me mjedisin, sistemet e tjera dhe burimet e sistemit - materiale, energji, informacione, organizative, njerëzore, hapësinore dhe kohore);

– përcaktimi i kritereve për përshtatshmërinë, efikasitetin dhe qëndrueshmërinë (besueshmërinë);

– përshkrimi funksional i nënsistemeve të sistemit (përshkrimi i modeleve, algoritmet për funksionimin e nënsistemeve);

- prototipizimi (përshkrimi bedel) i sistemit, vlerësimi i ndërveprimit të nënsistemeve të sistemit (zhvillimi i një modeli - zbatimi i nënsistemeve me përshkrime të thjeshtuara funksionale, procedura dhe testimi i ndërveprimit të këtyre modeleve në mënyrë që të plotësoni qëllimin e sistemit), ndërkohë që është e mundur të përdoren "mock-up" të kritereve për përshtatshmërinë, stabilitetin, efikasitetin;

- "montimi" dhe testimi i sistemit - zbatimi i nënsistemeve dhe kritereve funksionale të plota, vlerësimi i modelit sipas kritereve të formuluara;

- funksionimi i sistemit;

– përcaktimi i qëllimeve për zhvillimin e mëtejshëm të sistemit dhe aplikimeve të tij;

- mirëmbajtja e sistemit - sqarimi, modifikimi, zgjerimi i aftësive të sistemit në mënyrën e funksionimit të tij (me qëllim të evoluimit të tij).

Këto janë fazat kryesore për riinxhinierimin e sistemeve të informacionit.

Zhvillimi i një sistemi informacioni të korporatës, si rregull, kryhet për një ndërmarrje të mirëpërcaktuar. Karakteristikat e veprimtarisë lëndore të ndërmarrjes, natyrisht, do të ndikojnë në strukturën e sistemit të informacionit. Por në të njëjtën kohë, strukturat e ndërmarrjeve të ndryshme janë përgjithësisht të ngjashme me njëra-tjetrën. Çdo organizatë, pavarësisht nga lloji i veprimtarisë së saj, përbëhet nga një numër divizionesh që kryejnë drejtpërdrejt një ose një lloj tjetër veprimtarie të kompanisë. Dhe kjo situatë është e vërtetë për pothuajse të gjitha organizatat, pavarësisht se në çfarë lloj aktiviteti janë të angazhuara.

Kështu, çdo organizatë mund të konsiderohet si një grup elementesh ndërvepruese (nënndarje), secila prej të cilave mund të ketë strukturën e vet, mjaft komplekse. Marrëdhëniet ndërmjet departamenteve janë gjithashtu mjaft komplekse. Në rastin e përgjithshëm, ekzistojnë tre lloje lidhjesh midis njësive të biznesit:

Lidhjet funksionale - çdo divizion kryen lloje të caktuara të punës brenda një procesi të vetëm biznesi;

Komunikimet e informacionit - njësitë shkëmbejnë informacione (dokumente, fakse, urdhra me shkrim dhe me gojë, etj.);

Komunikimet e jashtme - disa njësi ndërveprojnë me sisteme të jashtme, dhe ndërveprimi i tyre gjithashtu mund të jetë informues dhe funksional.

Përbashkësia e strukturës së ndërmarrjeve të ndryshme na lejon të formulojmë disa parime të përbashkëta për ndërtimin e sistemeve të informacionit të korporatave.

Në përgjithësi, procesi i zhvillimit të një sistemi informacioni mund të konsiderohet nga dy këndvështrime:

Sipas kohës, ose sipas fazave të ciklit jetësor të sistemit që po zhvillohet. Në këtë rast, marrim parasysh organizimin dinamik të procesit të zhvillimit, të përshkruar në terma ciklesh, fazash, përsëritjesh dhe fazash.

Sistemi informativ i ndërmarrjes është zhvilluar si projekt. Shumë veçori të fazave të menaxhimit të projektit dhe zhvillimit të projektit (fazat e ciklit jetësor) janë të zakonshme dhe nuk varen jo vetëm nga fusha e temës, por edhe nga natyra e projektit (nuk ka rëndësi nëse është një projekt inxhinierik apo ekonomik ). Prandaj, ka kuptim që së pari të shqyrtojmë një numër çështjesh të përgjithshme të menaxhimit të projektit.

Një projekt është një ndryshim me kohë, i qëllimshëm në një sistem të veçantë me qëllime fillimisht të përcaktuara qartë, arritja e të cilit përcakton përfundimin e projektit, si dhe me kërkesat e përcaktuara për termat, rezultatet, rrezikun, shpenzimin e fondeve dhe burimeve. dhe struktura organizative.

Zakonisht, për një koncept kompleks (i cili, në veçanti, është koncepti i një projekti), është e vështirë të jepet një formulim i qartë që mbulon plotësisht të gjitha tiparet e konceptit të paraqitur. Prandaj, përkufizimi i mësipërm nuk pretendon të jetë unik dhe i plotë.

Mund të dallohen tiparet kryesore të mëposhtme dalluese të projektit si një objekt menaxhimi:

Ndryshueshmëria - transferimi i qëllimshëm i sistemit nga ekzistues në disa

gjendja e dëshiruar, e përshkruar në kuptim të qëllimeve të projektit;

Kufizimi i qëllimit përfundimtar;

kohëzgjatje e kufizuar;

Buxheti i kufizuar;

Kërkohen burime të kufizuara;

Risi për ndërmarrjen për të cilën po zbatohet projekti;

Kompleksiteti - prania e një numri të madh faktorësh që ndikojnë drejtpërdrejt ose indirekt në ecurinë dhe rezultatet e projektit;

Mbështetje juridike dhe organizative - krijimi i një strukture organizative specifike për kohëzgjatjen e projektit.

Efikasiteti i punës arrihet duke menaxhuar procesin e zbatimit të projektit, i cili siguron shpërndarjen e burimeve, koordinimin e sekuencës së punës që po kryhet dhe kompensimin e shqetësimeve të brendshme dhe të jashtme.

Nga pikëpamja e teorisë së sistemeve të kontrollit, projekti si objekt kontrolli duhet të jetë i vëzhgueshëm dhe i menaxhueshëm, domethënë, dallohen disa karakteristika me të cilat është e mundur të monitorohet vazhdimisht ecuria e projektit (vetia e vëzhgimit). Përveç kësaj, ka nevojë për mekanizma të ndikimit në kohë në rrjedhën e zbatimit të projektit (vetia e kontrollit).

Vetia e kontrollueshmërisë është veçanërisht e rëndësishme në kushtet e pasigurisë dhe ndryshueshmërisë së fushës lëndore, të cilat shpesh shoqërojnë projekte për zhvillimin e sistemeve të informacionit.

Çdo projekt, pavarësisht nga kompleksiteti dhe sasia e punës që kërkohet për zbatimin e tij, kalon nëpër faza të caktuara të zhvillimit të tij: nga gjendja kur "nuk ka ende projekt" në gjendjen kur "projekti nuk është më". Tërësia e fazave të zhvillimit nga shfaqja e një ideje deri në përfundimin e plotë të projektit zakonisht ndahet në faza (faza, faza).

Ekzistojnë disa dallime në përcaktimin e numrit të fazave dhe përmbajtjes së tyre, pasi këto karakteristika varen kryesisht nga kushtet për zbatimin e një projekti të veçantë dhe përvoja e pjesëmarrësve kryesorë. Sidoqoftë, logjika dhe përmbajtja kryesore e procesit të zhvillimit të një sistemi informacioni në pothuajse të gjitha rastet janë të zakonshme.

Fazat e mëposhtme të zhvillimit të sistemit të informacionit mund të dallohen:

Formimi i konceptit;

Zhvillimi i specifikimeve teknike;

Dizajn;

Prodhimtaria;

Vënia e sistemit në funksion.

Le të shqyrtojmë secilën prej tyre në më shumë detaje. Fazat e dyta dhe pjesërisht të treta zakonisht quhen fazat e projektimit të sistemit, dhe dy të fundit (nganjëherë përfshijnë fazën e projektimit) janë fazat e zbatimit.

Faza e konceptit

Formimi i ideve, vendosja e qëllimeve;

Formimi i ekipit kryesor të projektit;

Studimi i motivimit dhe kërkesave të klientit dhe pjesëmarrësve të tjerë;

Mbledhja e të dhënave fillestare dhe analiza e gjendjes ekzistuese;

Përcaktimi i kërkesave dhe kufizimeve bazë, burimeve të nevojshme materiale, financiare dhe të punës;

Vlerësimi krahasues i alternativave;

Paraqitja e propozimeve, shqyrtimi dhe miratimi i tyre.

Zhvillimi i një propozimi teknik

Zhvillimi i përmbajtjes kryesore të projektit, strukturës bazë të projektit;

Zhvillimi dhe miratimi i termave të referencës;

Planifikimi, zbërthimi i modelit bazë strukturor të projektit;

Hartimi i vlerësimeve dhe buxheteve për projektin, përcaktimi i nevojës për burime;

Zhvillimi i planeve kalendarike dhe oraret e zgjeruara të punës;

Nënshkrimi i një kontrate me klientin;

Vënia në funksion e mjeteve të komunikimit të pjesëmarrësve të projektit dhe kontrollit mbi ecurinë e punës.

Dizajn

Në këtë fazë, përcaktohen nënsistemet dhe ndërlidhjet e tyre, zgjidhen mënyrat më efektive të zbatimit të projektit dhe përdorimit të burimeve. Veprat karakteristike të kësaj faze:

Zbatimi i punës bazë të projektimit;

Zhvillimi i specifikimeve teknike private;

Zbatimi i dizajnit konceptual;

Hartimi i specifikimeve dhe udhëzimeve teknike;

Prezantimi i zhvillimit, ekzaminimit dhe miratimit të projektimit.

Zhvillimi

Në këtë fazë, kryhet koordinimi dhe kontrolli operacional i punës në projekt, nënsistemet prodhohen, kombinohen dhe testohen. Përmbajtja kryesore:

Kryerja e punës në zhvillimin e softuerit;

Kryerja e përgatitjeve për zbatimin e sistemit;

Kontrolli dhe rregullimi i treguesve kryesorë të projektit.

Vënia në punë e sistemit

Në këtë fazë kryhen teste, funksionimi provë i sistemit në kushte reale, negociatat për rezultatet e projektit dhe për kontrata të reja të mundshme. Llojet kryesore të punës:

Teste komplekse;

42. Koncepti i ciklit jetësor të IP. (Tema 11, fq. 103-105).

Post-relacionalemodel

Modeli klasik relacional supozon pandashmërinë e të dhënave të ruajtura në fushat e regjistrimeve të tabelës. Modeli post-relativ është një model i zgjeruar relacional që heq kufizimin e pandashmërisë së të dhënave. Modeli lejon fusha me shumë vlera - fusha vlerat e të cilave përbëhen nga nënvlera. Një grup vlerash për fusha me shumë vlera konsiderohet të jetë një tabelë e pavarur e ngulitur në tabelën kryesore.

Në fig. 2.6, duke përdorur shembullin e informacionit mbi faturat dhe mallrat për krahasim, është paraqitur paraqitja e të njëjtave të dhëna duke përdorur modelet relacionale (a) dhe postrelacionale (b). Nga figura mund të shihet se, krahasuar me modelin relacional, modeli post-relacion i ruan të dhënat në mënyrë më efikase dhe gjatë përpunimit nuk do të jetë e nevojshme të kryhet një operacion i bashkimit të të dhënave nga dy tabela.

Faturat

N faturë	Blerësi		N faturë		sasi

Nga lart

N faturë	Blerësi		sasi

Oriz. 2.6. Strukturat e të dhënave të modeleve relacionale dhe postrelacionale

Meqenëse modeli post-relativ lejon ruajtjen e të dhënave jo të normalizuara në tabela, lind problemi i sigurimit të integritetit dhe konsistencës së të dhënave. Ky problem zgjidhet duke përfshirë mekanizmat e duhur në DBMS.

Dinjiteti Modeli post-relacional është aftësia për të përfaqësuar një grup tabelash relacionale të lidhura me një tabelë post-relacionale. Kjo siguron një shikueshmëri të lartë të paraqitjes së informacionit dhe një rritje të efikasitetit të përpunimit të tij.

disavantazh Modeli post-relativ është kompleksiteti i zgjidhjes së problemit të sigurimit të integritetit dhe konsistencës së të dhënave të ruajtura.

Modeli i konsideruar i të dhënave post-relacionale mbështetet nga DBMS uniVers. DBMS të tjera të bazuara në modelin e të dhënave post-relacionale përfshijnë gjithashtu sistemet Bubba dhe Dasdb.

Model shumëdimensional

Qasja shumëdimensionale ndaj përfaqësimit të të dhënave u shfaq pothuajse njëkohësisht me atë relacionale, por interesi për DBMS shumëdimensionale filloi të përhapet nga mesi i viteve 1990. Shtysa ishte në vitin 1993 një artikull nga E. Codd. Ai formuloi 12 kërkesa bazë për sistemet e klasave OLAP (OnLine Analytical Processing), më të rëndësishmet prej të cilave lidhen me aftësitë e përfaqësimit konceptual dhe të përpunimit të të dhënave shumëdimensionale.

Në zhvillimin e koncepteve të sistemeve të informacionit, mund të dallohen dy drejtimet e mëposhtme:

Sistemet operative (transaksionale) të përpunimit;

Sistemet e përpunimit analitik (sistemet e mbështetjes së vendimeve).

DBMS relacionale ishin të destinuara për sistemet e informacionit të përpunimit operacional të informacionit dhe janë shumë efektive në këtë fushë. Në sistemet e përpunimit analitik, ato janë provuar të jenë disi të ngathët dhe jo mjaftueshëm fleksibël. DBMS-të shumëdimensionale janë më efikase këtu.

DBMS shumëdimensionale janë DBMS shumë të specializuara të krijuara për përpunimin analitik interaktiv të informacionit. Konceptet kryesore të përdorura në këto DBMS janë grumbullueshmëria, historikiteti dhe parashikueshmëria.

Përmbledhja të dhëna nënkupton shqyrtimin e informacionit në nivele të ndryshme të përgjithësimit të tij. Në sistemet e informacionit, shkalla e detajeve në paraqitjen e informacionit për përdoruesin varet nga niveli i tij: analist, përdorues, menaxher, menaxher.

Historiciteti të dhënat përfshijnë sigurimin e një niveli të lartë të natyrës statike të vetë të dhënave dhe marrëdhënieve të tyre, si dhe lidhjen e detyrueshme të të dhënave me kohën.

Parashikueshmëria përpunimi i të dhënave përfshin vendosjen e funksioneve të parashikimit dhe zbatimin e tyre në intervale të ndryshme kohore.

Shumëdimensionaliteti i modelit të të dhënave nuk nënkupton shumëdimensionalitetin e vizualizimit të të dhënave dixhitale, por paraqitjen logjike shumëdimensionale të strukturës së informacionit në përshkrim dhe në operacionet e manipulimit të të dhënave.

Krahasuar me modelin relacional, organizimi shumëdimensional i të dhënave ka një dukshmëri dhe përmbajtje informacioni më të lartë. Për ilustrim në fig. Figura 2.7 tregon paraqitjet relacionale (a) dhe shumëdimensionale (b) të të njëjtave të dhëna mbi vëllimet e shitjeve të makinave.

Konceptet bazë të modeleve të të dhënave shumëdimensionale: dimensioni dhe qeliza.

Matjaështë një grup të dhënash të të njëjtit lloj që formojnë një nga faqet e hiperkubit. Në një model shumëdimensional, dimensionet luajnë rolin e indekseve që shërbejnë për të identifikuar vlera specifike në qelizat hiperkube.

Qelizëështë një fushë vlera e së cilës përcaktohet në mënyrë unike nga një grup fiks matjesh. Lloji i fushës më së shpeshti përcaktohet si numerik. Në varësi të mënyrës se si formohen vlerat e një qelize të caktuar, ajo mund të jetë një variabël (vlerat ndryshojnë dhe mund të ngarkohen nga një burim i jashtëm i të dhënave ose të gjenerohen në mënyrë programore) ose një formulë (vlerat, si qelizat e formulave të fletëllogaritjes, llogariten sipas formulave të paracaktuara).

Oriz. 2.7. Paraqitja e të dhënave relacionale dhe shumëdimensionale

Në shembullin në fig. 2,7 b çdo vlerë qelize Vëllimi i shitjeve përcaktohet në mënyrë unike nga kombinimi i dimensionit kohor Muaji i Shitjeve dhe modelet e makinave. Në praktikë, shpesh kërkohen më shumë matje. Një shembull i një modeli të dhënash tredimensionale është paraqitur në fig. 2.8.

Oriz. 2.8. Shembull i modelit 3D

DBMS-të ekzistuese shumëdimensionale përdorin dy skema kryesore të organizimit të të dhënave: hiperkubike dhe polikubike.

AT polikubike Skema supozon se disa hiperkuba me dimensione të ndryshme dhe me dimensione të ndryshme mund të përcaktohen në bazën e të dhënave si fytyra. Një shembull i një sistemi që mbështet një variant polikubik të një baze të dhënash është Serveri Oracle Express.

Kur hiperkubik Skema supozon se të gjitha qelizat përcaktohen nga i njëjti grup matjesh. Kjo do të thotë që nëse ka disa hiperkuba në bazën e të dhënave, të gjithë kanë të njëjtin dimension dhe të njëjtat dimensione.

Kryesor dinjitet Modeli shumëdimensional i të dhënave është komoditeti dhe efikasiteti i përpunimit analitik të sasive të mëdha të të dhënave të lidhura me kohën.

disavantazh modeli shumëdimensional i të dhënave është rëndimi i tij për detyrat më të thjeshta të përpunimit konvencional të informacionit në internet.

Shembuj të sistemeve që mbështesin modele të dhënash shumëdimensionale janë Essbase, Media Multi-matrix, Oracle Express Server, Cache. Ka produkte softuerike, të tilla si Media / MR, që ju lejojnë të punoni njëkohësisht me bazat e të dhënave shumëdimensionale dhe relacionale.

Modeli i orientuar nga objekti

Në një model të orientuar nga objekti, gjatë prezantimit të të dhënave, është e mundur të identifikohen të dhënat individuale të bazës së të dhënave. Marrëdhëniet krijohen ndërmjet regjistrimeve dhe funksioneve të tyre të përpunimit duke përdorur mekanizma të ngjashëm me pajisjet përkatëse në gjuhët e programimit të orientuara nga objekti.

Një model i standardizuar i orientuar nga objekti përshkruhet në rekomandimet e standardit ODMG-93 (Object Database Management Group - një grup i menaxhimit të bazës së të dhënave të orientuar nga objekti).

Konsideroni një model të thjeshtuar të një baze të dhënash të orientuar nga objekti. Struktura e një baze të dhënash të orientuar nga objekti paraqitet grafikisht si një pemë, nyjet e së cilës janë objekte. Vetitë e objekteve përshkruhen nga një lloj standardi ose i ndërtuar nga përdoruesi (i përcaktuar si një klasë). Vlera e një vetie të klasës së tipit është një objekt që është një shembull i klasës përkatëse. Çdo objekt i shembullit të klasës konsiderohet një fëmijë i objektit në të cilin është përcaktuar si një veti. Një objekt shembulli i një klase i përket klasës së saj dhe ka një prind. Marrëdhëniet gjenerike në bazën e të dhënave formojnë një hierarki të lidhur objektesh. Një shembull i strukturës logjike të një baze të dhënash të bibliotekarisë së orientuar nga objekti është paraqitur në fig. 2.9. Këtu një objekt i llojit Librariështë prindi i objekteve të instancës së klasës Abonent, Katalogu dhe ekstradimi. Objekte të llojeve të ndryshme libra dhe mund të kenë prindër të njëjtë ose të ndryshëm. Objektet e tipit Libër, të cilat kanë të njëjtin prind, duhet të ndryshojnë nga të paktën një numër aksesi (unik për çdo shembull libri), por të kenë të njëjtat vlera të vetive isb n udk, emrat e dhe autor.

Struktura logjike e një baze të dhënash të orientuar nga objekti është nga jashtë e ngjashme me strukturën e një baze të dhënash hierarkike. Dallimi kryesor midis tyre është në metodat e manipulimit të të dhënave.

Për të kryer veprime mbi të dhënat në modelin e marrë në konsideratë të bazës së të dhënave, përdoren operacione logjike, të përmirësuara nga mekanizmat e orientuar drejt objektit të kapsulimit, trashëgimisë dhe polimorfizmit.

Kapsulimi kufizon shtrirjen e emrit të pronës në objektin në të cilin është përcaktuar. Pra, nëse në një objekt të tipit Katalogu shtoni një pronë që specifikon numrin e telefonit të autorit të librit dhe ka një titull telefonit, atëherë do të marrim vetitë me të njëjtin emër për objektet Abonent dhe Katalogu. Kuptimi i një vetie të tillë do të përcaktohet nga objekti në të cilin është i kapsuluar.

Trashëgimia, përkundrazi, shtrin objektin e pasurisë tek të gjithë pasardhësit e objektit. Kështu, për të gjitha objektet e tipit Libër, që janë pasardhës të një objekti të llojit Katalogu, mund të caktoni vetitë e objektit prind: isbn, udk, titullin dhe autor. Nëse është e nevojshme të zgjerohet mekanizmi i trashëgimisë në objekte që nuk janë të afërm të menjëhershëm (për shembull, midis dy pasardhësve të të njëjtit prind), atëherë një pronë abstrakte e llojit abs. Kështu, përkufizimi i vetive abstrakte biletë dhe dhomë në objekt Librari bën që këto veti të trashëgohen nga të gjitha objektet fëmijë Abonent, Libër dhe Çështjet a. Nuk është rastësi që prandaj vlerat e pasurisë biletë klasat Abonent dhe ekstradimi treguar në fig. 2.9 janë të njëjta - 00015.

Polimorfizmi në gjuhët e programimit të orientuara nga objekti nënkupton aftësinë e të njëjtit kod programi për të punuar me të dhëna heterogjene. Me fjalë të tjera, do të thotë se objektet e llojeve të ndryshme mund të kenë metoda (procedura ose funksione) me të njëjtin emër. Gjatë ekzekutimit të një programi objekti, të njëjtat metoda funksionojnë në objekte të ndryshme në varësi të llojit të argumentit. Në lidhje me shembullin në shqyrtim, polimorfizëm do të thotë se objektet e një klase Libër duke pasur prindër të ndryshëm nga klasa Katalogu, mund të ketë një grup të ndryshëm vetish. Prandaj, programe për të punuar me objekte të klasës Libër mund të përmbajë kod polimorfik.

Kërkimi në një bazë të dhënash të orientuar nga objekti konsiston në gjetjen e ngjashmërive midis objektit të specifikuar nga përdoruesi dhe objekteve të ruajtura në bazën e të dhënave.

Oriz. 2.9. Struktura logjike e bazës së të dhënave të bibliotekarisë

Kryesor dinjitet Modeli i të dhënave të orientuar drejt objektit në krahasim me atë relacional është aftësia për të shfaqur informacione rreth marrëdhënieve komplekse të objekteve. Modeli i të dhënave të orientuar nga objekti ju lejon të identifikoni një regjistrim të vetëm të bazës së të dhënave dhe të përcaktoni funksionet për përpunimin e tyre.

disavantazhet Modelet e orientuara nga objekti janë kompleksiteti i lartë konceptual, shqetësimi i përpunimit të të dhënave dhe shpejtësia e ulët e ekzekutimit të pyetjeve.

DBMS-të e orientuara nga objekti përfshijnë POET, Jasmine, Versant, O2, ODB-Jupiter, Iris, Orion, Postgres.