Në një model të orientuar nga objekti (OOM), 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 të bazës së të dhënave 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.
OOM standard përshkruar në rekomandimet e standardit ODMG-93 (Object Database Management Group - një grup për menaxhimin e bazave të të dhënave të orientuara nga objekti). Nuk ka qenë ende e mundur të zbatohen plotësisht rekomandimet e ODMG-93. Për ilustrim idetë kryesore Konsideroni një model disi të thjeshtuar të një baze të dhënash të orientuar nga objekti.
Struktura e OO DB 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 të lidhur objektesh.
Një shembull i strukturës logjike të OO DB të bibliotekarisë është paraqitur në fig. 3.14. Këtu, objekti i tipit LIBRARY është objekti prind i instancës së klasave SUBSCRIBER, CATALOG dhe ISSUANCE. Objektet e ndryshme të llojit BOOK që kanë të njëjtin prind duhet të ndryshojnë nga të paktën një numër hyrje (unik për çdo shembull të librit), por kanë vlera të njëjta Vetitë isbn, udk, emër dhe autor.
Fig.3.14. Struktura logjike e bazës së të dhënave të shkencës bibliotekare
Struktura logjike e bazës së të dhënave OO ë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ë bazën e të dhënave OOM, aplikoni operacionet logjike, i përmirësuar 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ë indeksit) që përmbajnë informacion për kërkim i shpejtë të dhëna.
Le të shqyrtojmë shkurtimisht konceptet e kapsulimit, trashëgimisë dhe polimorfizmit në lidhje me OOM të një baze të dhënash.
Kapsulimi kufizon shtrirjen e emrit të pronës në objektin në të cilin është përcaktuar. Pra, nëse i shtoni një pronë një objekti të tipit CATALOG që specifikon numrin e telefonit të autorit të librit dhe ka emrin telefoni, atëherë do të marrim vetitë me të njëjtin emër për objektet SUBSCRIBER 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, emër 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ërkufizimi i vetive abstrakte biletë dhe dhomë në objektin LIBRARY bën që të gjitha objektet fëmijë të ABONIT, LIBRIT dhe HUAZIT t'i trashëgojnë këto veti. Nuk është rastësi që prandaj vlerat e pronës biletë Klasat ABONIN dhe ISSUANCE 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ë pranueshmëri në sende tipe te ndryshme kanë metoda (procedura ose funksione) me të njëjtët emra. 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 OO DB tonë, 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 të ndryshëm vetish. Rrjedhimisht, programet për të punuar me objekte të klasës BOOK mund të përmbajnë kod polimorfik.
Kërkimi në OO DB konsiston në gjetjen e ngjashmërive 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 qëllimi (vetia e objektit të tipit qëllimi) në përgjithësi 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. Në Fig. 3.15.
Kryesor dinjitet Të dhënat OOM në krahasim me relacionale janë aftësia për të shfaqur informacion në lidhje me marrëdhëniet komplekse të objekteve. Të dhënat OOM ju lejojnë të identifikoni një rekord të vetëm të bazës së të dhënave dhe të përcaktoni funksionet e përpunimit të tyre.
disavantazh OOM janë kompleksitet i lartë konceptual, shqetësim i përpunimit të të dhënave dhe shpejtësi të ulët ekzekutimi i kërkesave.
 |
Fig.3.15. Fragmenti i bazës së të dhënave me objektin e synuar
Le t'i kthehemi sërish problemit Orders, i paraqitur në formën e një modeli të dhënash relacionale në fig. 3.8 dhe konsideroni atë në termat e një baze të dhënash të orientuar nga objekti. Gjithsej janë tre klasa: Klientët», « Porositë"dhe" Produktet". Objektet e klasës " Klientët» janë klientë specifikë; vetitë e klasës - numri i klientit, qyteti i emrit të klientit, statusi, etj. Metodat e klasës - " Krijo rend», « Paguaj faturën" etj. Një metodë është një operacion që mund të zbatohet në një objekt; një metodë është ajo që një objekt duhet të bëjë. Klasa që korrespondon me tabelën " Detajet e porosisë", nuk kërkohet. Të dhënat e tabelës mund të jenë pjesë e klasës " Porositë". Prezenca në klasë Klientët» metoda » Krijo rend"çon në ndërveprim me objektet e klasave" Porositë"dhe" Produktet". Në këtë rast, përdoruesi nuk ka nevojë të dijë për këtë ndërveprim të objekteve. Përdoruesi akseson vetëm objektin " Porositë"dhe përdor metodën" Krijo rend". Fakti i ndikimit në bazat e tjera të të dhënave mund të fshihet nga përdoruesi. Nëse metoda Krijo rend", nga ana tjetër, i referohet metodës" Kontrolloni besueshmërinë e klientit”, atëherë ky fakt mund të fshihet edhe nga përdoruesi. Në bazat e të dhënave relacionale, për të kryer të njëjtat funksione, duhet të shkruani procedura në gjuhë Bazë vizuale për Aplikim (VBA).
Në vitet 1990 kishte prototipe eksperimentale të sistemeve të menaxhimit të bazës së të dhënave OO. Aktualisht, sisteme të tilla përdoren gjerësisht. Në veçanti, këto përfshijnë DBMS-të e mëposhtme: POET (Software POET), Jasmine (Computer Associates), Versant (Versant Technologies), O2 (Software Ardent), ODB-Jupiter (Inteltech Plus Research and Production Center) dhe Iris , Orion dhe Postgres.
Teknologjitë e bazës së të dhënave të bazuara në MD të përshkruara më sipër bazohen në konceptin statik të ruajtjes së informacionit, të fokusuar në modelimin e të dhënave. Sidoqoftë, 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;
Prodhimi i automatizuar;
Zhvillim i automatizuar software;
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, e cila zbaton këtë koncept dhe bazuar në paradigmën e orientuar nga objekti (OOP), u quajt 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.
koncepte të rëndësishme Shërbimi OOP 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ë 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ë sasi e kufizuar vetitë e superklasës së saj.
Trashëgimia e instancës së ndryshueshme quhet trashëgimi strukturore, trashëgimia e metodës - trashëgimia e sjelljes, por aftësia për të përdorur të njëjtën metodë për klasa të ndryshme, ose më mirë të zbatohet 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 Një klasë përshkruhet nga atributet e saj. Metodat e një klase objekti janë një lloj analog i vetive të objekteve në botën reale. Çdo objekt lidhet me disa klasë 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 lidhjet në modeli i objektit zbatohen duke përdorur atributet referente, 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 lidhjeështë një variant i marrëdhënies shumë-për-shumë me semantikën e veçantë. Një marrëdhënie e plotë-pjesë zbatohet si çdo marrëdhënie tjetër shumë-me-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 gjithashtu 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 "shtrihet", 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., sekreti i 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 hierarkia e dhënë. 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ë.
Rol i rendesishem Në OOMD, kufizimet në integritetin e lidhjeve luajnë. 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ë lidhje midis PUNONJËSVE dhe FËMIJËVE të tyre, atëherë duhet të ketë një 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-ve 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ë fjalë për fjalë 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ë këtij 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 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 ndërmjet 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 hyrës dhe dalës, 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) - hierarkike dhe modeli i rrjetit; gjenerata e dytë (afërsisht 1970-1980) - modeli relacional; gjenerata e tretë (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:
Aplikacioni përbëhet nga një numër i madh pjesë 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ë aksesojë të dhënat në një mënyrë të parashikueshme, kështu që natyra lundruese e një baze të dhënash të orientuar nga objekti nuk do të jetë 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ë.
AT ky moment 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
Nje nga dallimet themelore bazat e të dhënave të objektit nga relacionale është aftësia për të krijuar dhe përdorur lloje të reja të të dhënave. Karakteristikë e rëndësishme OODBMS është se krijimi i një lloji të ri nuk kërkon modifikim të bazës bazë dhe bazohet në parimet e programimit të orientuar drejt objektit.
Kerneli OODBMS është i optimizuar për operacione me objekte. Veprimet e tij natyrore janë ruajtja e objekteve, versionimi i objekteve, 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.
Gjatë krijimit aplikacione të ndryshme në bazë të OODBMS, struktura e integruar e klasës së një DBMS të veçantë është e rëndësishme. Biblioteka e klasës zakonisht mbështet jo vetëm gjithçka lloje standarde të dhëna, por edhe një grup i zgjeruar i multimedias dhe llojeve të tjera komplekse të të dhënave, si video, zëri, sekuenca e kornizave të animacionit. Në disa OODBMS, janë krijuar biblioteka të klasave që mundësojnë ruajtjen dhe kërkimin e plotë të tekstit 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 pronat e kërkuara dhe metodat për menaxhimin 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. nje nga operacionet kritikeë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, aftësia për të formuar pyetje kërkimi me 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. Në listë aplikimet e mundshme le të emërtojmë automatizimin e kontabilitetit për rrjedhën e punës së një zyre moderne, ndërtimin e sistemeve të referencës dhe informacionit (të ngjashme me bazat e njohura ligjore), mirëmbajtjen e bazave të të dhënave të rrjetit, të dhënat e personelit, bibliografinë 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 themelore, dy qasje kryesore (koncepti i tretë është një kombinim i tyre):
1. Orientimi në problemet që duhen zgjidhur 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ë në dispozicion (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 së pari studiohen aftësitë e teknologjisë ekzistuese 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 sistematike dhe lidhjet me mjedisi, sisteme të tjera dhe burimet e sistemit- materiale, energjitike, informative, 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 i prototipimit) të sistemit, vlerësimi i ndërveprimit të nënsistemeve të sistemit (zhvillimi i faqosjes - zbatimi i nënsistemeve me të thjeshtuar përshkrimet funksionale, procedurat dhe testimi i ndërveprimit të këtyre paraqitjeve për të përmbushur qëllimin e sistemit), ndërkohë që është e mundur të përdoren "planet" e kritereve për përshtatshmërinë, qëndrueshmërinë, efikasitetin;
- "montimi" dhe testimi i sistemit - zbatimi i plotë nënsistemet funksionale dhe kriteret, vlerësimi i modelit sipas kritereve të formuluara;
– funksionimin e sistemit;
– përcaktimin e 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 (për 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 informative - 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:
Me kohë, ose me faza cikli i jetes sistemi në zhvillim. AT këtë rast merr në konsideratë organizimin dinamik të procesit të zhvillimit, të përshkruar në terma të cikleve, fazave, përsëritjeve dhe fazave.
Sistemi informativ i ndërmarrjes është zhvilluar si projekt. Shumë tipare 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 lëndore, 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ë serinë çështje të përgjithshme menaxhimin e projektit.
Një projekt është një ndryshim i kufizuar në 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ë.
Kryesorja e mëposhtme veçoritë projekti si objekt kontrolli:
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ëzgjatja 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;
Ligjore dhe mbështetje organizative- krijimi i një strukture organizative specifike për kohëzgjatjen e projektit.
Efikasiteti i punës arrihet përmes menaxhimit të procesit të 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 dhe analiza e të dhënave bazë gjendjen 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 planet 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 më së shumti nënsistemet, ndërlidhjet e tyre mënyra efektive ekzekutimi i projektit dhe përdorimi i burimeve. Veprat karakteristike të kësaj faze:
Zbatimi i punës bazë të projektimit;
Zhvillimi i privatit Termat e referencës;
Zbatimi i dizajnit konceptual;
Hartimi i specifikimeve teknike dhe udhëzimeve;
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 janë duke u zhvilluar 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).
Me një numër të madh projektesh eksperimentale (dhe madje edhe sisteme komerciale) nuk ka një model të të dhënave të orientuar drejt objektit të pranuar përgjithësisht, dhe jo sepse nuk është zhvilluar një model i vetëm i plotë, por sepse nuk ka marrëveshje të përgjithshme për miratimin e ndonjë modeli. Në fakt, ka çështje më specifike që lidhen me hartimin e gjuhëve të pyetjeve deklarative, ekzekutimin dhe optimizimin e pyetjeve, formulimin dhe ruajtjen e kufizimeve të integritetit, sinkronizimin e aksesit dhe menaxhimin e transaksioneve, etj.
Modeli i orientuar nga objekti (Fig. 3) ju lejon të krijoni, ruani dhe përdorni informacione në formën e objekteve. Çdo objekt pas krijimit të tij merr një identifikues unik të gjeneruar nga sistemi, i cili shoqërohet me objektin gjatë gjithë ekzistencës së tij dhe nuk ndryshon kur ndryshon gjendja e objektit.
Fig.3. Modeli i të dhënave të orientuara nga objekti
Çdo objekt ka një gjendje dhe sjellje. Gjendja e një objekti është një grup vlerash për atributet e tij. Sjellja e një objekti është një grup metodash (kodi programi) që veprojnë në gjendjen e objektit. Vlera e një atributi të një objekti është gjithashtu një objekt ose një grup objektesh. Gjendja dhe sjellja e një objekti janë të kapsuluara në një objekt; ndërveprimi i objekteve bazohet në transmetimin e mesazheve dhe ekzekutimin e metodave përkatëse.
Një grup objektesh me të njëjtin grup atributesh dhe metodash formon një klasë objekti. Një objekt duhet t'i përkasë vetëm një klase (nëse nuk merrni parasysh mundësinë e trashëgimisë). Lejohet të ketë klasa të paracaktuara primitive, objektet e shembullit të të cilave nuk kanë atribute: numra të plotë, vargje, etj. Një klasë, objektet e së cilës mund të shërbejnë si vlera të një atributi të objekteve të një klase tjetër, quhet domeni i atij atributi.
Lejohet të gjenerohet një klasë e re bazuar në një klasë tashmë ekzistuese - trashëgimi. Në këtë rast, klasa e re, e quajtur nënklasë e një klase ekzistuese (superklasë), trashëgon të gjitha atributet dhe metodat e superklasës. Përveç kësaj, atributet dhe metodat shtesë mund të përcaktohen në një nënklasë. Ka raste të trashëgimisë së thjeshtë dhe të shumëfishtë. Në rastin e parë, një nënklasë mund të përcaktohet vetëm në bazë të një superklase, në rastin e dytë, mund të ketë disa superklasa. Nëse një gjuhë ose sistem mbështet trashëgiminë e një klase të vetme, grupi i klasave formon një hierarki peme. Kur mbështesin trashëgiminë e shumëfishtë, klasat lidhen në një grafik të drejtuar me një rrënjë, të quajtur rrjetë klasash. Një objekt i një nënklase konsiderohet se i përket çdo superklase të asaj klase.
Bazat e të dhënave të orientuara nga objekti kanë gjetur aplikimin më të gjerë në fusha të tilla si dizajni / prodhimi me ndihmën e kompjuterit (CAD / CAM), sistemet zhvillim i automatizuar softuer (CASE), sisteme të përbëra të menaxhimit të dokumenteve, d.m.th. në zona jo tradicionale për bazat e të dhënave. Shembuj të DBMS-ve të orientuara nga objekti janë - POET, Jasmine, Versant, Iris, Orion.
2.2.4 Modeli i të dhënave relacionale
Në vitin 1970, matematikani amerikan Codd E.F. botoi një artikull revolucionar në përmbajtjen e tij, duke sugjeruar përdorimin e teorisë së grupeve për përpunimin e të dhënave. Ai argumentoi se të dhënat duhet të lidhen sipas marrëdhënieve të tyre logjike (p.sh. bashkimi, kryqëzimi) dhe jo sipas treguesve fizikë. Ai propozoi një model të thjeshtë të dhënash në të cilin të gjitha të dhënat përmblidhen në tabela të përbëra nga rreshta dhe kolona me emra unikë. Këto tabela quhen marrëdhënie (relacion - relacion), dhe modeli - modeli relacional bazuar në konceptin e marrëdhënieve matematikore dhe nganjëherë quhet edhe modeli Codd. Propozimet e Codd ishin aq efektive për sistemet e bazës së të dhënave sa për këtë model atij iu dha çmimi prestigjioz Turing në Teorinë e Informatikës.
Në bazat e të dhënave relacionale, të gjitha të dhënat ruhen në tabela të thjeshta, të ndara në rreshta (ato quhen regjistrime) dhe kolona (ato quhen fusha), në kryqëzimin e të cilave ndodhet informacioni për të dhënat. AT pamje e përgjithshme kjo mund të paraqitet si në Fig. 4.
Fig.4. Tabela e bazës së të dhënave relacionale.
Çdo kolonë ka emrin e vet. Për shembull, në tabelën "Mallrat në magazinë" (Fig. 5.), emrat e fushave janë si më poshtë: Identifikues, Produkt, Emri i grupit, Grupi, njësi matëse, Çmimi i blerjes, Çmimi i shitjes, Disponueshmëria në magazinë.
Oriz. 5. Tabela “Mallrat në Magazinë »
Të gjitha vlerat në një kolonë janë të të njëjtit lloj. Pra, fushat janë karakteristika të ndryshme(nganjëherë quhen atribute) të një objekti. Vlerat e fushave në të njëjtën linjë i referohen të njëjtit objekt dhe fusha të ndryshme kanë emra të ndryshëm.
Çdo regjistrim dallohet nga një çelës unik regjistrimi, të cilët janë dy llojesh: primar dhe dytësor.
çelesi primarështë një ose më shumë fusha që identifikojnë në mënyrë unike një rekord. Nëse çelësi primar përbëhet nga një fushë, ai quhet çelës i thjeshtë, nëse përbëhet nga disa fusha, quhet çelës i përbërë.
çelësi dytësorështë një fushë, vlera e së cilës mund të përsëritet në disa regjistrime të skedarit, domethënë nuk është unike.
Çelësi i jashtëm tabela e varur është çelësi dytësor i kësaj relacioni, i cili, në të njëjtën kohë, kryen funksionet e çelësit primar në tabelën kryesore. Nëse me vlerën e çelësit primar mund të gjendet një shembull i vetëm i regjistrimit, atëherë sipas vlerës së çelësit të huaj ka disa (Fig. 6).
Fig.6. Një shembull i përdorimit të një çelësi të huaj
Si rregull, një bazë të dhënash relacionale përbëhet nga disa tabela, sepse nuk është e mundur të kombinohen në një tabelë të gjitha informacionet e nevojshme për punonjësit (përdoruesit e bazës së të dhënave) të çdo organizate për të zgjidhur problemet.
Mjeti i aksesit efikas me çelës në një skedar skedari është indeksimi. Indeksimi krijon skedar shtesë A që përmban, me radhë, të gjitha vlerat kryesore të skedarit të të dhënave. Për çdo çelës, skedari i indeksit përmban një tregues për hyrjen përkatëse në skedarin e të dhënave. Një tregues për një hyrje në skedarin e të dhënave siguron qasje të drejtpërdrejtë në atë hyrje.
Për të punuar me bazat e të dhënave relacionale, tani përdoret zakonisht Structured Query Language (SQL). Është një gjuhë që përdoret për të krijuar, modifikuar dhe manipuluar të dhëna. SQL nuk është gjuha algoritmike programimit. Kjo është një gjuhë informative-logjike, ajo bazohet në algjebër relacionale dhe ndahet në tre pjesë:
operatorët e përkufizimit të të dhënave;
operatorët e manipulimit të të dhënave (Insert, Select, Update, Delete);
· Operatorët e përkufizimit të aksesit të të dhënave.
Në vitin 1986, SQL u miratua si standardi ANSI (Instituti Kombëtar Amerikan i Standardeve) për gjuhët e bazës së të dhënave relacionale. Sot bazë e dhënë konsiderohet si një standard për sistemet moderne të informacionit.
Kështu, tabela është lloji kryesor i strukturës së të dhënave të modelit relacional. Struktura e një tabele përcaktohet nga një grup kolonash. Çdo rresht i tabelës përmban një vlerë në kolonën përkatëse. Një tabelë nuk mund të ketë dy rreshta identikë, numri total rreshtat nuk janë të kufizuara. Një kolonë është një element i të dhënave, çdo kolonë ka një emër. Një ose më shumë atribute, vlerat e të cilave identifikojnë në mënyrë unike një rresht tabele janë çelësi i tabelës.
Përparësitë e modelit relacional janë:
Thjeshtësia dhe lehtësia e të kuptuarit përdoruesi përfundimtar- e vetmja strukturë informacioni është një tabelë;
Gjatë projektimit të një baze të dhënash relacionale, zbatohen rregulla strikte, bazuar në aparatin matematik;
Pavarësia e plotë e të dhënave. Kur ndryshoni strukturën, ndryshimet që kërkojnë të bëhen programet e aplikimit ah, minimale;
Për të ndërtuar pyetje dhe për të shkruar programe aplikative, nuk ka nevojë të dihet organizimi specifik i bazës së të dhënave në memorien e jashtme.
Disavantazhet e modelit relacional janë:
Shpejtësia relativisht e ulët e aksesit dhe sasia e madhe e memories së jashtme;
Vështirësi në të kuptuarit e strukturës së të dhënave për shkak të shfaqjes së një numri të madh tabelash si rezultat i dizajnit logjik;
Jo gjithmonë zona e lëndës mund të përfaqësohet si një grup tabelash.
Bazat e të dhënave relacionale janë aktualisht më të përdorurat. Modelet e rrjetit dhe ato hierarkike konsiderohen të vjetëruara, modelet e orientuara nga objekti nuk janë ende të standardizuara dhe nuk përdoren gjerësisht.
Baza e të dhënave e orientuar drejt objekteve(OOBD) - një bazë të dhënash në të cilën të dhënat modelohen në formën e objekteve, atributeve, metodave dhe klasave të tyre.
Bazat e të dhënave të orientuara nga objekti zakonisht rekomandohen për ato raste kur kërkohet përpunim me performancë të lartë të të dhënave me një strukturë komplekse.
Manifesti OODB propozon karakteristika të detyrueshme që çdo OODB duhet të plotësojë. Zgjedhja e tyre bazohet në 2 kritere: sistemi duhet të jetë i orientuar drejt objektit dhe të jetë një bazë të dhënash.
Karakteristikat e detyrueshme
1. Mbështetje për objekte komplekse. Sistemi duhet të sigurojë mundësinë e krijimit të objekteve të përbëra duke përdorur konstruktorë të objekteve të përbëra. Është e nevojshme që konstruktorët e objekteve të jenë ortogonalë, domethënë çdo konstruktor mund të aplikohet në çdo objekt.
2. Mbështetje për individualitetin e objekteve. Të gjithë objektet duhet të kenë një identifikues unik që është i pavarur nga vlerat e atributeve të tyre.
3. Mbështetja e kapsulimit. Enkapsulimi i saktë arrihet nga fakti që programuesit kanë akses vetëm në specifikimin e ndërfaqes së metodës, dhe të dhënat dhe zbatimi i metodave fshihen brenda objekteve.
4. Mbështetje për llojet dhe klasat. Kërkohet që OODB të mbështesë të paktën një koncept të dallimit midis llojeve dhe klasave. (Termi "lloj" është më i përshtatshëm për konceptin e një lloji abstrakt të të dhënave. Në gjuhët e programimit, një variabël deklarohet me llojin e tij. Përpiluesi mund ta përdorë këtë informacion për të kontrolluar se çfarë është ekzekutuar me variabli i operacioneve për pajtueshmërinë me llojin e tij, i cili ju lejon të garantoni korrektësinë e softuerit. Nga ana tjetër, një klasë është një shabllon për krijimin e objekteve dhe ofron metoda që mund të aplikohen në këto objekte. Kështu, koncepti i "klasës" i referohet më shumë kohës së ekzekutimit sesa kohës së përpilimit.)
5. Mbështetje për trashëgiminë e llojeve dhe klasave nga paraardhësit e tyre. Një nëntip, ose nënklasë, duhet të trashëgojë atribute dhe metoda nga supertipi ose superklasa e tij, respektivisht.
6. Mbingarkesa e kombinuar me lidhje të plotë. Metodat duhet të zbatohen për objekte të llojeve të ndryshme. Zbatimi i metodës duhet të varet nga lloji i objekteve në të cilat zbatohet metoda. Për të siguruar këtë funksionalitet, lidhja e emrave të metodave në sistem nuk duhet të bëhet deri në kohën e ekzekutimit të programit.
7. Plotësia llogaritëse. Gjuha e manipulimit të të dhënave duhet të jetë një gjuhë programimi për qëllime të përgjithshme.
8. Grupi i llojeve të të dhënave duhet të jetë i zgjerueshëm. Përdoruesi duhet të ketë mjetet për të krijuar lloje të reja të dhënash bazuar në një grup të paracaktuara llojet e sistemit. Për më tepër, midis mënyrave të përdorimit sistematik dhe llojet me porosi të dhënat nuk duhet të kenë dallime.
OO DBMS
Bazat e të dhënave të orientuara nga objektet- bazat e të dhënave në të cilat informacioni paraqitet në formën e objekteve, si në gjuhët programuese të orientuara nga objekti.
Nëse do të përdoren apo jo sistemet e menaxhimit të bazës së të dhënave të orientuara nga objekti (OODBMS) në projekte reale sot? Kur duhet të përdoren dhe kur jo?
Këtu Përfitimet duke përdorur OODBMS:
· Nuk ka problem mospërputhjeje ndërmjet modelit të të dhënave në aplikacion dhe bazës së të dhënave (mospërputhje e impedancës). Të gjitha të dhënat ruhen në bazën e të dhënave në të njëjtën formë si në modelin e aplikacionit.
· Nuk kërkohet të ruhet veçmas modeli i të dhënave në anën e DBMS.
· Të gjitha objektet në nivelin e burimit të të dhënave janë të shtypura fort. Nuk ka më emra të kolonave të vargjeve! Rifaktorimi i një baze të dhënash të orientuar nga objekti dhe kodi që punon me të tani është i automatizuar, jo një proces monoton dhe i mërzitshëm.
Standardi ODMG
Manifesti i parë zyrtarisht ishte vetëm një artikull i paraqitur në Konferencë mbi bazat e të dhënave të orientuara nga objekti dhe deduktive një grup individësh. Siç mund ta shihni në nënseksionin e mëparshëm, kërkesat e Manifestit ishin më tepër emocionale sesa të specifikuara në mënyrë eksplicite. Në vitin 1991, u formua konsorciumi ODMG (atëherë kjo shkurtim u zbulua si Grupi i menaxhimit të bazës së të dhënave të objekteve, por më vonë fitoi një interpretim më të gjerë - Grupi i menaxhimit të të dhënave të objekteve). Konsorciumi ODMG është i lidhur ngushtë me konsorciumin shumë më të madh OMG ( Grupi i Menaxhimit të Objekteve), e cila u formua dy vjet më parë. Qëllimi kryesor fillestar i ODMG ishte të zhvillonte një standard të industrisë për bazat e të dhënave të orientuara nga objekti ( model i përgjithshëm). Modeli bazë i objektit OMG COM u miratua si bazë ( Modeli i objektit kryesor). Gjatë më shumë se dhjetë viteve të ekzistencës së saj, ODMG ka botuar tre versionet bazë standard, më i fundit i të cilit quhet ODMG 3.0. gjashtëmbëdhjetë
Është qesharake që megjithëse ODMG (sipas autorit) u largua nga OMG, në vitet e fundit disa standarde OMG mbështeten në modelin e objektit ODMG. Në veçanti, specifikimi OCL bazohet në modelin ODMG ( Gjuha e kufizimit të objektit), e cila është pjesë e specifikimit të përgjithshëm të gjuhës UML 1.4 (dhe UML 2.0). Në këtë artikull, ne nuk synojmë të bëjmë një krahasim të detajuar të qasjeve OMG dhe ODMG dhe t'i referojmë lexuesit e interesuar në Enciklopedia Kogalovsky dhe materiale nga faqet e internetit të këtyre konsorciumeve. Ne kufizohemi përmbledhje idetë kryesore të përfshira në standardin ODMG-3.
Arkitektura ODMG
Arkitektura e propozuar ODMG është paraqitur në Fig. 2.1. Kjo arkitekturë përcakton mënyrën se si ruhen të dhënat dhe llojet e ndryshme të aksesit të përdoruesve në këtë "magazinë të të dhënave" 17 . Magazinimi i unifikuar i të dhënave është i aksesueshëm nga gjuha e përkufizimit të të dhënave, gjuha e pyetjeve dhe një numër i gjuhëve të manipulimit të të dhënave. 18 Në fig. 2.1 ODL do të thotë Gjuha e përkufizimit të objektit (gjuha e përkufizimit të objektit), OQL - Gjuha e pyetjes së objektit (gjuha e pyetjes së objektit) dhe OML- Gjuha e manipulimit të objekteve (gjuha e manipulimit të objekteve).
Oriz. 2.1. Arkitektura ODMG
Në qendër të arkitekturës është modeli i të dhënave A që përfaqëson strukturën organizative në të cilën ruhen të gjitha të dhënat e menaxhuara nga OODBMS. Gjuha e përkufizimit të objektit, gjuha e pyetjes dhe gjuhët e manipulimit janë krijuar në atë mënyrë që të gjitha aftësitë e tyre të bazohen në modelin e të dhënave. Arkitektura lejon ekzistencën e një sërë strukturash implementuese për ruajtjen e të dhënave të modeluara, por një kërkesë e rëndësishme është që të gjitha bibliotekat e softuerit dhe të gjitha mjetet mbështetëse ofrohen në një kornizë të orientuar nga objekti dhe duhet të mbahen në përputhje me të dhënat.
Komponentët kryesorë të arkitekturës janë si më poshtë.
- Modeli i të dhënave të objektit. Të gjitha të dhënat e ruajtura nga një OODBMS janë të strukturuara në terma të modeleve të të dhënave. Semantika e saktë e të gjitha koncepteve është përcaktuar në modelin e të dhënave (shih më poshtë për më shumë detaje).
- Gjuha e përkufizimit të të dhënave (ODL). Skemat e bazës së të dhënave përshkruhen në termat e gjuhës ODL, në të cilën konstruktet e modelit të të dhënave instantohen në formën e një gjuhe përkufizimi. ODL ju lejon të përshkruani një skemë si një grup ndërfaqesh të llojit të objektit, i cili përfshin një përshkrim të vetive të tipit dhe marrëdhënieve ndërmjet tyre, si dhe emrat e operacioneve dhe parametrat e tyre. ODL nuk është një gjuhë programimi e plotë; zbatimi i llojeve duhet të bëhet në një nga gjuhët e kategorisë OML. Përveç kësaj, ODL është Virtual gjuhë në kuptimin që standardi ODMG nuk kërkon zbatimin e tij në produkte softuerike OODBMS që konsiderohen konform standardit. Është e pranueshme që këto produkte të mbështesin gjuhë me definicion ekuivalent që përfshijnë të gjitha tiparet e ODL, por që janë përshtatur me specifikat e një sistemi të caktuar. Megjithatë, prania e një specifikimi të gjuhës ODL në standardin ODMG është e rëndësishme sepse gjuha specifikon vetitë e modelit të të dhënave.
- Gjuha e pyetjes së objektit (ODL). Gjuha ka një sintaksë të ngjashme me Gjuha SQL, por mbështetet në semantikën e modelit të objektit ODMG. Standardi lejon përdorimin e drejtpërdrejtë të OQL dhe futjen e tij në një nga gjuhët e kategorisë OML.
Modeli i të dhënave relacionale
Pothuajse te gjitha sistemet moderne bazuar në relacionale Modelet e menaxhimit të bazës së të dhënave (relacionale). Emri relacionale për faktin se çdo rekord në një bazë të tillë të dhënash përmban informacion që lidhet vetëm me një objekt specifik.
AT relacionale DBMS të gjitha të dhënat e përpunuara janë paraqitur në formën e tabelave të sheshta. Informacioni për objektet e një lloji të caktuar paraqitet në formë tabelare: kolonat e tabelës përmbajnë atribute të ndryshme të objekteve, dhe rreshtat kanë për qëllim të reduktojnë përshkrimet e të gjitha atributeve në raste individuale të objekteve.
Modeli i krijuar në fazën e modelimit infologjik, në shumica plotëson parimet e relacionalitetit. Megjithatë, për ta sjellë këtë model në marrëdhënie, është e nevojshme të kryhet një procedurë e quajtur normalizimi.
Teoria e normalizimit funksionon me pesë forma normale. Këto formularë janë krijuar për të reduktuar tepricën e informacionit, kështu që çdo formë normale pasuese duhet të plotësojë kërkesat e një të mëparshmi dhe disa kushte shtesë. Në hartimin praktik të bazës së të dhënave, forma e katërt dhe e pestë zakonisht nuk përdoren. Jemi kufizuar në katër format e para normale.
Le të prezantojmë konceptet e nevojshme për të kuptuar procesin e sjelljes së një modeli në një skemë relacionale.
Qëndrimi- abstragimi i objektit të përshkruar si një grup i vetive të tij. Gjatë fazës infologjike të projektimit, folëm për abstraksionin e objekteve dhe u caktuam disa veti. Tani, me dizajnin konceptual, kalojmë në nivelin tjetër të abstraksionit. Në këtë fazë, objektet, si të tilla, nuk ekzistojnë më. Ne operojmë me një grup vetish që përcaktojnë një objekt.
Shembulli i marrëdhënies- një grup vlerash të vetive të një objekti të veçantë.
çelesi primar- grup identifikimi i atributeve, d.m.th. vlera e këtyre atributeve është unike në këtë respekt. Asnjë rast i një relacioni nuk përmban të njëjtat vlera në çelësin primar.
atribut i thjeshtë- një atribut, vlerat e të cilit janë të pandashme.
Atribut kompleks- një atribut vlera e të cilit është një grup vlerash prej disa prona të ndryshme objekt ose vlera të shumta të së njëjtës pronë.
Konceptet e esencës.
Domeni
Koncepti i një domeni është më specifik për bazat e të dhënave, megjithëse ka disa analogji me nëntipet në disa gjuhë programimi. Në formën më të përgjithshme, një domen përcaktohet duke specifikuar disa lloj të dhënash bazë të cilave i përkasin elementet e domenit, dhe një arbitrar shprehje boolean Aplikohet në elementin e llojit të të dhënave. Nëse kjo shprehje boolean vlerësohet si e vërtetë, atëherë elementi i të dhënave është një element domeni.
Interpretimi më i saktë intuitiv i konceptit të një domeni është të kuptuarit e një domeni si një grup potencial i vlefshëm vlerash të një lloji të caktuar. Për shembull, domeni "Emrat" në shembullin tonë është përcaktuar në lloji i bazës vargjet e karaktereve, por vetëm ato vargje që mund të përfaqësojnë një emër mund të përfshihen në vlerën e tij (në veçanti, vargjet e tilla nuk mund të fillojnë me një karakter të butë).
Duhet të theksohet gjithashtu kuptimi semantik i konceptit të domenit: të dhënat konsiderohen të krahasueshme vetëm nëse i përkasin të njëjtit domen. Në shembullin tonë, vlerat e domeneve "Numrat e kalimit" dhe "Numrat e grupit" janë të llojit të plotë, por nuk janë të krahasueshme. Vini re se shumica e DBMS-ve relacionale nuk përdorin konceptin e një domeni, megjithëse ai tashmë mbështetet në Oracle V.7.
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. Është marrë parasysh grupi i vlerave të fushave me shumë vlera tabelë e pavarur të ngulitura 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 për përfaqësimin e të dhënave u shfaq pothuajse njëkohësisht me qasjen relacionale, por interesi për DBMS shumëdimensionale filloi të fitonte karakter masiv që nga mesi i viteve '90. Shtysa ishte në 1993 një artikull nga E. Codd. Ai formuloi 12 kërkesa bazë për sistemet 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-të 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. AT 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ë (vlera, si qelizat e formulës spreadsheets, llogariten sipas formulave të paracaktuara).
Oriz. 2.7. Relacionale dhe paraqitje shumëdimensionale të dhëna
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 shumëdimensionale ekzistuese 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 faqe. Një shembull i një sistemi që mbështet një version polikubik të bazës së të dhënave është serveri Oracle. Serveri 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ë bazës së të dhënave 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, që kanë të njëjtin prind, duhet të ndryshojnë nga të paktën një numër hyrje (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 konsideruar 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ë 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ë 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 pronës 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ë orientuara 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.
