Az objektum-orientált modellben (OOM) az adatok bemutatásakor lehetőség nyílik az egyes adatbázisrekordok azonosítására. Az adatbázis-rekordok és feldolgozási funkcióik között az objektum-orientált programozási nyelvekhez hasonló mechanizmusok segítségével hoznak létre kapcsolatokat.

A szabványos OOM leírása az ODMG-93 (Object Database Management Group) szabvány ajánlásaiban található. Az ODMG-93 ajánlásait még nem hajtották végre teljes mértékben. A kulcsfontosságú ötletek szemléltetéséhez vegyünk egy kissé leegyszerűsített objektumorientált adatbázis modellt.

Az OO adatbázis szerkezetét grafikusan egy fa formájában ábrázoljuk, melynek csomópontjai objektumok. Az objektumok tulajdonságait valamilyen szabványos típus (például egy karakterlánc típus) vagy egy felhasználó által szerkesztett típus (osztályként definiálva) írja le.

A string típusú tulajdonság értéke egy karakterlánc. A class típusú tulajdonság értéke egy olyan objektum, amely a megfelelő osztály példánya. Egy osztály minden példányát annak az objektumnak a leszármazottjának tekintik, amelyben tulajdonságként definiálták. Egy osztály példányobjektuma az osztályához tartozik, és egyetlen szülője van. Az adatbázisban lévő általános kapcsolatok az objektumok kapcsolódó hierarchiáját alkotják.

ábrán látható egy példa a könyvtári OO DB logikai felépítésére. 3.14. Itt egy LIBRARY típusú objektum a szülő az SUBSCRIBER, DIRECTORY és OUTPUT osztályok példányobjektumainak. Az azonos szülővel rendelkező KÖNYV típusú különböző objektumok legalább a leltári számban különböznek (egyediek a könyv minden példányánál), de ugyanazokkal a tulajdonságértékekkel kell rendelkezniük. isbn, udk, névés szerző.

3.14. ábra. A könyvtári adatbázis logikai felépítése

Az OO adatbázis logikai felépítése külsőleg hasonló egy hierarchikus adatbázis szerkezetéhez. A fő különbség köztük az adatkezelés módszereiben rejlik. Az OOM adatbázisban lévő adatokkal kapcsolatos műveletek végrehajtásához logikai műveleteket használnak, amelyeket a beágyazás, az öröklődés és a polimorfizmus objektumorientált mechanizmusai erősítenek meg. Az SQL parancsokhoz hasonló műveletek korlátozottan használhatók (például adatbázis létrehozására).

Az adatbázis létrehozása és módosítása a gyors adatlekérést biztosító információkat tartalmazó indexek (indextáblázatok) automatikus kialakításával és utólagos javításával jár együtt.

Tekintsük röviden a beágyazás, az öröklődés és a polimorfizmus fogalmait az OOM adatbázisokkal kapcsolatban.

Egységbezárás a tulajdonságnév hatókörét annak az objektumnak a korlátaira korlátozza, amelyben meghatározásra került. Tehát, ha hozzáad egy tulajdonságot egy KÖNYVTÁR típusú objektumhoz, amely beállítja a könyv szerzőjének telefonszámát és a nevét telefon, akkor az SUBSCRIBER és DIRECTORY objektumokhoz azonos nevű tulajdonságokat kapunk. Egy ilyen tulajdonság jelentését az a tárgy határozza meg, amelybe be van zárva.

Öröklés, ellenkezőleg, kiterjeszti a tulajdon körét a tárgy valamennyi leszármazottjára. Tehát minden KÖNYV típusú objektum, amely egy KÖNYVTÁR típusú objektum leszármazottja, hozzárendelhető a szülőobjektum tulajdonságaihoz: isbn, udk, névés szerző. Ha ki kell terjeszteni az öröklődési mechanizmus hatását olyan objektumokra, amelyek nem közvetlen rokonok (például ugyanazon szülő két leszármazottja között), akkor abs típusú absztrakt tulajdonságot határoznak meg a közös ősükben. Tehát az absztrakt tulajdonságok meghatározása jegyés szoba egy LIBRARY objektumban azt eredményezi, hogy ezeket a tulajdonságokat az összes gyermek SUBSCRIBER, BOOK és REFERENCE objektum örökli. Nem véletlen, hogy az ingatlan értékei jegyábrán látható ELŐFIZETÉS és KIADÁS osztályok közül ugyanaz lesz - 00015.

Polimorfizmus objektum-orientált programozási nyelvekben ugyanazon programkód azon képességét jelenti, hogy különböző típusú adatokkal dolgozzon. Más szóval, ez azt jelenti, hogy különböző típusú objektumokban lehetnek azonos nevű metódusok (eljárások vagy függvények). Egy objektumprogram végrehajtása során ugyanazok a metódusok különböző objektumokon működnek az argumentum típusától függően. Az OO DB-nkre vonatkozóan a polimorfizmus azt jelenti, hogy a BOOK osztály objektumai, amelyek a DIRECTORY osztálytól eltérő szülővel rendelkeznek, eltérő tulajdonságokkal rendelkezhetnek. Következésképpen a BOOK osztályba tartozó objektumokkal dolgozó programok polimorf kódot tartalmazhatnak.

A keresés az OO adatbázisban abból áll, hogy megtalálja a hasonlóságot a felhasználó által megadott objektum és az adatbázisban tárolt objektumok között. Egy felhasználó által definiált objektum, amelyet célobjektumnak neveznek (az objektumtulajdonság cél típusú), általános esetben az adatbázisban tárolt objektumok teljes hierarchiájának egy részhalmazát képviselheti. A célobjektum, valamint a lekérdezés végrehajtásának eredménye magában az adatbázisban tárolható. Az ábrán látható egy példa a könyvtári igazolványok számának kérésére és azon előfizetők nevére, akik legalább egy könyvet kaptak a könyvtárban. 3.15.

A fő méltóság Az OOM versus relációs adatok az összetett objektumkapcsolatokról szóló információk megjelenítésének képessége. Az OOM adatok lehetővé teszik egyetlen adatbázis-rekord azonosítását és feldolgozásuk funkcióinak meghatározását.

Hátrány Az OOM fogalmi összetettsége, kényelmetlensége az adatfeldolgozás során és alacsony lekérdezési sebesség.

3.15. ábra. Az adatbázis töredéke a célobjektummal

Térjünk vissza a Rendelések feladatra, amelyet relációs adatmodell formájában mutatunk be az ábrán. 3.8 és tekintsük egy objektum-orientált adatbázis szempontjából. Összesen három osztály van: " Ügyfelek», « Megrendelések"és" Áruk". Az osztály tárgyai " Ügyfelek»Konkrét ügyfelek; osztályú ingatlanok - Ügyfélszám, Ügyfél neve Város, Státusz stb. Osztálymódszerek - " Rendelés létrehozása», « Fizetni számlát" stb. A metódus valamilyen művelet, amely egy objektumra alkalmazható; a metódus az, amit egy objektumnak tennie kell. táblázatnak megfelelő osztály Megrendelés részletei", nem szükséges. A táblázat adatai az osztály részét képezhetik Megrendelések". Jelenlét az osztályban" Ügyfelek"Módszer" Rendelés létrehozása"Interakcióhoz vezet az osztályok objektumaival" Megrendelések"és" Áruk". Ebben az esetben a felhasználónak nem kell tudnia az objektumok ezen interakciójáról. A felhasználó csak az objektumra hivatkozik Megrendelések"És használja a módszert" Rendelés létrehozása". A többi adatbázisra gyakorolt ​​hatás elrejthető a felhasználó elől. Ha a módszer " Rendelés létrehozása", viszont a módszerre utal" Ellenőrizze az ügyfél hitelképességét”, Ezt a tényt a felhasználó elől is el lehet rejteni. Relációs adatbázisokban ugyanazon funkciók végrehajtásához írási eljárások szükségesek a Visual Basic for Application (VBA) programban.

A 90-es években léteztek az OO adatbázis-kezelő rendszerek kísérleti prototípusai. Jelenleg az ilyen rendszerek széles körben elterjedtek. Ide tartoznak különösen a következő DBMS-ek: POET (POET Software), Jasmine (Computer Associates), Versant (Versant Technologies), O2 (Ardent Software), ODB-Jupiter (Inteltek Plus Kutatási és Termelési Központ), valamint Iris , Orion és Postgres.

Objektum orientált adatbázis(OODB) egy adatbázis, amelyben az adatokat objektumok, attribútumok, metódusok és osztályok formájában modellezzük.

Az objektum-orientált adatbázisok általában olyan esetekre javasoltak, ahol összetett szerkezetű adatok nagy teljesítményű feldolgozására van szükség.

Az OODB-jegyzék javaslatokat tesz a szükséges jellemzőkre, amelyeknek minden OODB-nek meg kell felelnie. Választásuk 2 szemponton alapul: a rendszernek objektumorientáltnak és adatbázisnak kell lennie.

Kötelező jellemzők

1. Összetett objektumok támogatása. A rendszernek lehetőséget kell biztosítania összetett objektumok létrehozására az összetett objektumok konstruktorainak használatával. Az objektumkonstruktoroknak ortogonálisnak kell lenniük, azaz bármely konstruktor bármely objektumra alkalmazható.

2. A tárgyak egyéniségének támogatása. Minden objektumnak egyedi azonosítóval kell rendelkeznie, amely nem függ attribútumainak értékétől.

3. Támogatás a tokozáshoz. A helyes beágyazás annak köszönhető, hogy a programozóknak csak a metódusok interfész specifikációjához van joguk hozzáférni, és a metódusok adatai és megvalósítása az objektumok belsejében rejtőzik.

4. Típusok és osztályok támogatása. Az OODB-nek támogatnia kell a típusok és osztályok közötti megkülönböztetés legalább egy fogalmát. (A "típus" kifejezés jobban összeegyeztethető az absztrakt adattípus fogalmával. A programozási nyelvekben a változót a típusának megjelölésével deklarálják. A fordító ezt az információt felhasználhatja a változóval végzett műveletek kompatibilitási ellenőrzésére. típusát, ami segít garantálni a szoftver helyességét Másrészt az osztály egyfajta sablon objektumok létrehozásához, és olyan metódusokat ad, amelyek alkalmazhatók azokra az objektumokra. Így az „osztály" fogalma inkább az futási idő helyett fordítási idő.)

5. Típusok és osztályok őseiktől való öröklésének támogatása. Egy altípusnak vagy alosztálynak örökölnie kell az attribútumokat és metódusokat a szupertípusától, illetve szuperosztályától.

6. Túlterhelés teljes kötéssel kombinálva. A módszereket különböző típusú objektumokra kell alkalmazni. A metódus megvalósításának az objektumok típusától kell függnie, amelyekre a metódust alkalmazzák. Ennek a funkciónak a biztosításához a metódusnevek összerendelése a rendszeren nem történhet meg a program végrehajtási idejéig.

7. Számítási teljesség. Az adatkezelési nyelvnek általános célú programozási nyelvnek kell lennie.

8. Az adattípusok halmazának bővíthetőnek kell lennie. A felhasználónak rendelkeznie kell azokkal az eszközökkel, amelyekkel új adattípusokat hozhat létre előre meghatározott rendszertípusok alapján. Ezenkívül nem szabad különbséget tenni a rendszer és a felhasználó által meghatározott adattípusok felhasználása között.

OO DBMS

Objektum orientált adatbázisok- adatbázisok, amelyekben az információkat objektumok formájában jelenítik meg, mint az objektum-orientált programozási nyelvekben.

Alkalmazni vagy nem alkalmazni objektum-orientált adatbázis-kezelő rendszereket (OODBMS) ma valós projektekben? Milyen esetekben szabad ezeket használni, és milyen esetekben nem?

Itt Előnyök OODBMS használatával:

· Nincs probléma az alkalmazásban lévő adatmodell és az adatbázis között (impedancia eltérés). Az adatbázisban minden adat ugyanolyan formában tárolódik, mint az alkalmazásmodellben.

· Nem szükséges külön támogatni az adatmodellt DBMS oldalon.

· Az adatforrás szintjén lévő összes objektum erősen be van írva. Nincs több karakterlánc-oszlopnév! Az objektum-orientált adatbázis és a vele működő kód átalakítása ma már automatizált, nem pedig unalmas és unalmas folyamat.

ODMG szabvány

Első manifeszt formálisan csak egy cikk volt benyújtva Konferencia az objektum-orientált és deduktív adatbázisokról egyének egy csoportja által. Amint az előző alfejezetben látható, a Kiáltvány követelményei érzelmi jellegűek voltak, semmint kifejezetten meghatározottak. 1991-ben megalakult az ODMG konzorcium (akkor ezt a rövidítést úgy hozták nyilvánosságra Objektum adatbázis-kezelő csoport, de később tágabb értelmezésre tett szert - Objektum adatkezelési csoport). Az ODMG konzorcium szorosan összefügg a sokkal nagyobb OMG konzorciummal ( Objektumkezelő Csoport), amely két évvel korábban alakult. Az ODMG fő eredeti célja az objektum-orientált adatbázisok iparági szabványának kidolgozása volt (közös modell). Az alap objektummodell OMG COM ( Alapobjektum-modell). Az ODMG több mint egy évtized alatt a szabvány három alapváltozatát tette közzé, amelyek közül a legújabb az ODMG 3.0. 16

Ironikus módon, bár az ODMG (a szerző véleménye szerint) kívül esik az OMG-n, az elmúlt években néhány OMG szabvány az ODMG objektummodellre támaszkodott. Különösen az OCL nyelvi specifikáció ( Objektumkényszer nyelv), amely az UML 1.4 (és az UML 2.0) általános nyelvi specifikáció része. Ebben a cikkben nem áll szándékunkban az OMG és az ODMG megközelítések részletes összehasonlítása, és az érdeklődő olvasók figyelmébe ajánljuk. Kogalovszkij enciklopédiáiés e konzorciumok webhelyeiről származó anyagokat. Az ODMG-3 szabványban foglalt főbb gondolatok rövid összefoglalására szorítkozunk.

ODMG architektúra

A javasolt ODMG architektúra az ábrán látható. 2.1. Ez az architektúra meghatározza az adatok tárolásának módját és az ehhez az „adattárhoz” 17 különböző felhasználói hozzáférési típusokat. Egyetlen adattár elérhető egy adatdefiníciós nyelvből, egy lekérdezési nyelvből és számos adatkezelési nyelvből. 18 Az ábrán. 2.1 ODL azt jelenti Objektumdefiníciós nyelv, OQL - Objektumlekérdezési nyelvés OML - Objektummanipulációs nyelv.

Rizs. 2.1. ODMG architektúra

Az építészet központi eleme adatmodell, amely azt a szervezeti struktúrát képviseli, amelyben az OODBMS által kezelt összes adatot tárolják. Az objektumdefiníciós nyelv, a lekérdezési nyelv és a manipulációs nyelvek úgy vannak kialakítva, hogy minden képességük az adatmodelltől függ. Az architektúra sokféle megvalósítási struktúrát tesz lehetővé a modellezett adatok tárolására, de fontos követelmény, hogy minden szoftverkönyvtár és minden támogató eszköz objektum-orientált keretrendszerben legyen biztosítva, és az adatokkal összhangban kell tárolni.

Az architektúra fő összetevői a következők.

• Objektum adatmodell. Az OODBMS által tárolt összes adat adatmodell-konstrukciók szerint van strukturálva. Az adatmodell meghatározza az összes fogalom pontos szemantikáját (további részletekért lásd alább).

• Adatdefiníciós nyelv (ODL). Az adatbázissémákat az ODL nyelven írják le, amelyben az adatmodell-konstrukciók egy definíciós nyelv formájában példányosodnak. Az ODL lehetővé teszi a sémák leírását objektum típusú interfészek halmazaként, amely tartalmazza a típustulajdonságok és a köztük lévő kapcsolatok leírását, valamint a műveletek nevét és paramétereit. Az ODL nem egy teljes programozási nyelv; a típusokat az OML kategória valamelyik nyelvén kell implementálni. Emellett az ODL is virtuális nyelv abban az értelemben, hogy az ODMG szabvány nem követeli meg annak megvalósítását a szabványnak megfelelőnek tekintett OODBMS szoftvertermékekben. Ezek a termékek támogathatják az egyenértékű definíciós nyelveket, amelyek tartalmazzák az ODL összes képességét, de igazodnak egy adott rendszer sajátosságaihoz. Azonban az ODL nyelvi specifikáció jelenléte az ODMG szabványban fontos, mert a nyelv határozza meg az adatmodell tulajdonságait.

• Object Query Language (ODL). A nyelv szintaxisa hasonló az SQL-hez, de az ODMG objektummodell szemantikájára támaszkodik. A szabvány lehetővé teszi az OQL közvetlen használatát és beágyazását az OML kategória egyik nyelvébe.

Relációs adatmodell

Szinte minden modern rendszer ezen alapul relációs(relációs) adatbázis-kezelési modell. Név relációsösszefügg azzal a ténnyel, hogy egy ilyen adatbázisban minden rekord csak egy konkrét objektumra vonatkozó információt tartalmaz.

V relációs A DBMS-ben minden feldolgozott adat lapos táblázatok formájában jelenik meg. Az adott típusú objektumokkal kapcsolatos információk táblázatos formában jelennek meg: az objektumok különféle attribútumai koncentrálódnak a táblázat oszlopaiban, és a sorok célja az összes attribútum leírásának csökkentése az objektumok egyedi példányaira.

Az infológiai modellezés szakaszában megalkotott modell felel meg a legnagyobb mértékben a relativitás elveinek. Ennek a modellnek a relációs modellé való átalakításához azonban végre kell hajtania a nevezett eljárást normalizálás.

A normalizációs elmélet öttel működik normál formák... Ezek az űrlapok az információk redundanciájának csökkentésére szolgálnak, ezért minden további normál űrlapnak meg kell felelnie az előző és néhány további feltétel követelményeinek. A gyakorlati adatbázis-tervezésben általában nem használják a negyedik és ötödik formát. Az első négy normálforma figyelembevételére szorítkoztunk.

Mutassuk be a modell relációs sémává való redukálásának folyamatának megértéséhez szükséges fogalmakat.

Hozzáállás- a leírt objektum absztrakciója tulajdonságainak halmazaként. Az infológiai tervezés szakaszában az objektumok absztrakciójáról beszéltünk, és hozzájuk rendeltünk néhány tulajdonságot. Most a koncepcionális tervezéssel az absztrakció következő szintjére lépünk. Ebben a szakaszban a tárgyak, mint olyanok, már nem léteznek. Az objektumot meghatározó tulajdonságokkal dolgozunk.

Kapcsolati példány- egy adott objektum tulajdonságainak értékkészlete.

Elsődleges kulcs- attribútumok azonosító halmaza, pl. ezen attribútumok értéke ebből a szempontból egyedülálló. Nincs két olyan kapcsolat, amely az elsődleges kulcsban ugyanazt az értéket tartalmazza.

Egyszerű tulajdonság- olyan attribútum, amelynek értékei oszthatatlanok.

Összetett attribútum- attribútum, amelynek értéke egy objektum több különböző tulajdonságának értékkészlete vagy egy tulajdonság több értékének halmaza.

Entitás fogalmak ..

Tartomány

A tartomány inkább az adatbázisokra vonatkozik, bár van némi analógiája egyes programozási nyelvek altípusaival. A tartományt legáltalánosabb formájában úgy határozzuk meg, hogy megadunk valamilyen alapvető adattípust, amelyhez a tartomány elemei tartoznak, és egy tetszőleges logikai kifejezést alkalmazunk az adattípus elemére. Ha ez a logikai kifejezés igaz, akkor az adatelem egy tartományelem.

A tartomány fogalmának leghelyesebb intuitív értelmezése az, ha egy tartományt egy adott típusú megengedett potenciális értékkészletként értelmezzük. Például a Domain "Nevek" a példánkban a karakterláncok alaptípusán van definiálva, de értékei csak azokat a karakterláncokat tartalmazhatják, amelyek egy nevet képviselhetnek (különösen az ilyen karakterláncok nem kezdődhetnek lágy előjellel).

Figyelembe kell venni a tartományfogalom szemantikai terhelését is: az adatokat csak akkor tekintjük összehasonlíthatónak, ha ugyanahhoz a tartományhoz tartoznak. Példánkban a "Gap Numbers" és a "Group Numbers" tartományok értékei egész típusúak, de nem összehasonlíthatók. Vegye figyelembe, hogy a legtöbb relációs DBMS nem használja a tartomány fogalmát, bár az Oracle V.7 már támogatja azt.

A fenti MD-ken alapuló adatbázis-technológiák az információtárolás statikus koncepcióján alapulnak, amely az adatmodellezésre összpontosít. Azonban a technológia alkalmazásának új területei összetett, összekapcsolt adatbázis-objektumokkal, mint például:

Számítógéppel segített tervezés;

Automatizált gyártás;

Automatizált szoftverfejlesztés;

Irodai információs rendszerek;

Multimédiás rendszerek;

Földrajzi információs rendszerek;

Kiadói rendszerek és mások – bebizonyították a statikus koncepció korlátozott képességeit az objektumok valós világban való modellezésére vonatkozóan.

Az új típusú komplex speciális adatbázis-alkalmazások esetében hatékony az információtárolás dinamikus koncepciója, amely lehetővé teszi az adatok és az adatokon ható folyamatok párhuzamos szimulálását. Ez lehetővé teszi, hogy figyelembe vegye a tartomány szemantikáját, és így a legmegfelelőbben leírja ezeket az alkalmazásokat. Ez a koncepció a szoftverfejlesztésben széles körben használt objektum-orientált megközelítésen alapul. Az MD, amely ezt a koncepciót valósítja meg, és az objektum-orientált paradigmán (OOP) alapul, az objektum-orientált adatmodellnek (OOMD) nevezik.

Az OOMD felépítése abból a feltételezésből indul ki, hogy a tárgyterület objektumok halmazával leírható. Minden objektum egy egyedileg azonosítható entitás, amely attribútumokat tartalmaz, amelyek leírják a "valós világ" objektumok állapotát és a hozzájuk kapcsolódó műveleteket. Egy objektum aktuális állapotát egy vagy több attribútum írja le, amelyek lehetnek egyszerűek vagy összetettek. Egy egyszerű attribútum lehet primitív típusú (például egész szám, karakterlánc stb.), és felvehet literális értéket. Az összetett attribútumok gyűjteményeket és/vagy hivatkozásokat tartalmazhatnak. A referenciaattribútum az objektumok közötti kapcsolatot jelöli.

Az objektum legfontosabb tulajdonsága az azonosításának egyedisége. Ezért egy objektumorientált rendszerben minden objektumnak saját azonosítóval kell rendelkeznie.

Az Object Identifier (OID) az egyedi objektumok címkézésének adatbázison belüli módja. Azok a felhasználók, akik a lekérdezések beállítására vagy információk megtekintésére szolgáló párbeszédablakkal dolgoznak, általában nem látják ezeket az azonosítókat. Ezeket maga a DBMS rendeli hozzá és használja. Az azonosító szemantikája az egyes DBMS-ekben eltérő. Ez lehet véletlenszerű érték, vagy tartalmazhat információkat, amelyek szükségesek egy objektum megtalálásához az adatbázisfájlban, például a fájl oldalszámát és az objektum eltolását az elejétől. Ez az az azonosító, amelyet az objektumra való hivatkozások rendezéséhez kell használni.

Minden objektum be van zárva, vagyis az objektum reprezentációja vagy belső szerkezete rejtve marad a felhasználó elől. Ehelyett a felhasználó csak azt tudja, hogy ez az objektum bizonyos funkciókat elláthat. Például a WAREHOUSE objektumhoz olyan metódusok használhatók, mint az ACCEPT_PRODUCT, EXIT_TOBAP stb.. A beágyazás előnye, hogy lehetővé teszi az objektumok belső reprezentációjának megváltoztatását anélkül, hogy átdolgoznánk az ezeket az objektumokat használó alkalmazásokat. Más szavakkal, a tokozás az adatok függetlenségét jelenti.

Egy objektum adatokat és funkciókat foglal magában (metódusok az OOP szerint). A metódusok határozzák meg egy objektum viselkedését. Használhatók egy objektum állapotának megváltoztatására az attribútumok értékeinek megváltoztatásával, vagy a kiválasztott attribútumok értékeinek lekérdezésére. Például létezhetnek módszerek egy új bérleményre vonatkozó információk hozzáadására, egy alkalmazott fizetési információinak frissítésére vagy egy adott tételre vonatkozó információk nyomtatására.

Az azonos attribútumkészlettel rendelkező és ugyanazokra az üzenetekre válaszoló objektumok csoportosíthatók Osztály(a szakirodalomban az "osztály" és a "típus" kifejezéseket gyakran felcserélhetően használják). Minden ilyen osztálynak megvan a maga képviselője - egy objektum, amely adatelem. Egy bizonyos osztályba tartozó objektumokat úgy hívják másolatok.

Egyes objektumorientált rendszerekben az osztály egyben objektum is, és saját attribútumokkal és metódusokkal rendelkezik, amelyeket hívnak osztály attribútumai és osztálymetódusai.

Fontos OOP fogalmak osztályhierarchia és konténerhierarchia.

Osztályhierarchia magában foglalja annak lehetőségét, hogy minden osztálynak, amelyet ebben az esetben szuperosztálynak nevezünk, megvan a maga alosztálya. Példaként felhozható a következő lánc: egy vállalat minden programozója annak alkalmazottja, ezért minden programozó, aki az OOMD-n belül a PROGRAMOZÓK osztály objektuma, egyben alkalmazott is, aki viszont az EMPLOYEES objektuma. osztály. Így a PROGRAMOZÓK alosztály, a MUNKAVÁLLALÓK szuperosztály lesz. De a programozókat rendszerre és alkalmazásra is fel lehet osztani. Ezért a PROGRAMMERS a SIS_PROGRAMMERS és az APPLICATION_PROGRAMMERS alosztályok szuperosztálya lesz. Ezt a láncot tovább folytatva egy osztályhierarchiát kapunk, amelyben az alosztály minden objektuma örökli a megfelelő szuperosztály változóinak és metódusainak példányait.

Az öröklődésnek többféle típusa van - egyszeri, többszörös és szelektív. Az egyszeri öröklődés olyan eset, amikor az alosztályok legfeljebb egy szuperosztályból öröklődnek. Többszörös öröklődés – egynél több szuperosztályból származó öröklődés. A szelektív öröklődés lehetővé teszi egy alosztály számára, hogy korlátozott számú tulajdonságot örököljön a szuperosztályából.

Változópéldány öröklődést hívunk szerkezeti öröklődés, módszer öröklődése - viselkedési öröklődés, és azt a képességet, hogy különböző osztályokhoz ugyanazt a metódust használjuk, vagy inkább különböző osztályokhoz ugyanazon névvel különböző metódusokat alkalmazzunk, az ún. polimorfizmus.

Az objektum-orientált architektúrának van egy másik típusú hierarchiája is - konténer hierarchia... Abból áll, hogy egyes objektumok fogalmilag másokba foglalhatók. Így a DEPARTMENT osztály objektumának tartalmaznia kell a HEAD nyilvános változót, amely hivatkozás a tanszékvezetőnek megfelelő EMPLOYEES osztály objektumára, és tartalmaznia kell egy hivatkozást is egy hivatkozási halmazra a megfelelő objektumokra. az osztályon dolgozó alkalmazottak.

Egyes objektumorientált rendszerekben az osztály egyben objektum is, és saját attribútumai és metódusai vannak. Egy osztály általános jellemzőit attribútumai írják le. Az objektumosztály metódusai analógiák a valós világban lévő objektumok tulajdonságaival. Minden objektum, amely egy adott osztályhoz tartozik, rendelkezik ezekkel a tulajdonságokkal. Ezért egy objektum létrehozásakor deklarálnia kell az osztályt, amelyhez tartozik, hogy így definiálhassa az inherens tulajdonságait.

A felhasználó és az objektum üzeneteken keresztül lép kapcsolatba egymással. Minden egyes üzenetre válaszul a rendszer végrehajtja a megfelelő metódust.

Az objektummodell minden hivatkozása referenciaattribútumok használatával történik, amelyeket általában OID-ként valósítanak meg.

A relációs adatbázisban lévő kapcsolatokat az elsődleges és az idegen kulcsok leképezése ábrázolja. Magában az alapban nincsenek struktúrák a táblák közötti asszociációk kialakítására, a hivatkozásokat szükség szerint használjuk a táblák összekapcsolásakor. Ezzel szemben a kapcsolatok alkotják az objektumorientált adatbázis gerincét, mivel minden objektum tartalmazza azoknak az objektumoknak az azonosítóit, amelyekhez társítva vannak.

Az OOMD-ben nemcsak a hagyományos linkek valósíthatók meg, hanem az öröklődés által kondicionált hivatkozások is.

Személyes kommunikáció (1:1) Az A és B objektumok között úgy valósítható meg, hogy egy referenciaattribútumot adnak hozzá a B objektumhoz az A objektumhoz, és (a hivatkozási integritás fenntartásához) egy referenciaattribútumot az A objektumhoz a B objektumhoz.

Egy a többhez kapcsolat (1: M) Az A és B objektumok között úgy valósul meg, hogy az A objektumhoz egy referenciaattribútumot adnak hozzá a B objektumhoz, és egy attribútumot, amely hivatkozásokat tartalmaz az A objektumhoz a B objektumhoz (például egy B referenciaattribútumot (OID2, OID3 ...) adunk hozzá az A objektumhoz és a B objektumpéldányokhoz OID2, OID3, ... A hivatkozási attribútum: OID1 kerül hozzáadásra.

Sok-sok kapcsolat (M: N) Az A és B objektumok között úgy valósul meg, hogy minden objektumhoz adunk egy hivatkozáskészletet tartalmazó attribútumot.

Az OOMD-ben használhat egy egész-rész kapcsolatot, amely leírja, hogy egy osztály objektuma részeként más osztályok objektumait tartalmazza. Gyártási adatbázis esetén a TERMÉK osztály és az ALKATRÉSZ és ÖSSZESZERELÉS osztályok között egész-alkatrész kapcsolat lenne. Ez a kapcsolat a sok a sokhoz kapcsolat egy speciális szemantikával rendelkező változata. A teljes-rész kapcsolatokat a többi sok-sok kapcsolathoz hasonlóan valósítják meg, kapcsolódó objektumazonosítók készletével. Ennek azonban a szokásos sok-sok kapcsolattal ellentétben más szemantikai jelentése van.

Mivel az objektum-orientált paradigma támogatja az öröklődést, az OOMD-ben lehetőség van az "is" típusú és az "extends" típusú kapcsolat használatára. Az is kapcsolat, amelyet általánosítás-specializáció kapcsolatnak is neveznek, egy öröklődési hierarchiát generál, amelyben az alosztályok a szuperosztályok speciális esetei. Ezzel elkerülhető az újraöröklött jellemzők leírása. Az "extends" kapcsolat használatakor az alosztály a szuperosztály funkcionalitását fejleszti, nem pedig az adott esetre korlátozza.

Fontolja meg, hogy az olyan összetevők, mint az integritási megszorítások és az adatokkal kapcsolatos műveletek hogyan valósulnak meg az OOMD-ben.

Ezen alkatrészek jellemzőit a modell sajátosságai határozzák meg. Ezt a sajátosságot az OOMD-ben elsősorban az olyan belső fogalmak diktálják, mint az objektumok tokozása, vagyis a belső struktúra titkossága, az adatokhoz csak előre definiált metódusokon keresztül történő hozzáférés, az osztályhierarchia és a konténerhierarchia.

Az OOMD sajátosságait az objektum sajátossága is meghatározza. Ez abban nyilvánul meg, hogy az objektumokat osztályokba kell csoportosítani. Minden objektum a feladattól függően egy vagy másik osztályba kerül, és egy objektum egyszerre több osztályba is tartozhat (például PROGRAMOZÓK és HIGHLY PAID családok). Egy objektum másik sajátossága, hogy „átfuthat” egyik osztályból (alosztályból) a másikba. Így a RENDSZERPROGRAMOZÓ idővel ALKALMAZHATÓ lehet. Így az osztályhierarchia nem analóg a hierarchikus modellel, ahogyan korábban tűnhetett, hanem megköveteli, hogy a rendszer képes legyen az egyes objektumok helyét megváltoztatni az osztályhierarchián belül, például „felfelé” vagy „lefelé” mozogni. ezt a hierarchiát. De bonyolultabb folyamat is lehetséges - a rendszernek biztosítania kell, hogy egy objektum bármikor a hierarchia tetszőleges csúcsához kapcsolódjon (lekapcsolható).

Az integritási megszorítások fontos szerepet játszanak az OOMD-ben. Ahhoz, hogy az objektumorientált MD-ben lévő hivatkozások működjenek, a hivatkozás mindkét oldalán meg kell egyeznie az objektumazonosítóknak. Például, ha kapcsolat áll fenn a MUNKAVÁLLALÓK és GYERMEKEIK között, akkor bizonyos fokú biztosítéknak kell lennie arra, hogy amikor egy gyermeket leíró objektumot beillesztenek egy alkalmazottat ábrázoló objektumba, akkor az utóbbi azonosítója hozzáadódik a megfelelő objektumhoz. Ezt a fajta kapcsolatintegritást, amely némileg analóg a relációs adatmodell referenciális integritásával, visszacsatolások segítségével hozzuk létre. A hivatkozások integritásának biztosítása érdekében a tervezőt egy speciális szintaxissal látják el, amely az inverz objektumazonosító helyének meghatározásához szükséges. A hivatkozások integritására (valamint a relációs adatbázisban a hivatkozási integritásra) vonatkozó korlátozások beállításának felelőssége a tervezőt terheli.

Az OOMD-ben az adatok leírása és manipulálása is ugyanazt az objektum-orientált eljárási nyelvet használja.

Az ODMG (Object Database Management Groop) csoport az objektum adatbázis technológia szabványosítási problémáival foglalkozik. Kifejlesztett egy objektummodellt (az ODMG 2.0-s verzióját 1997 szeptemberében fogadták el), amely szabványos modellt határoz meg az adatbázis-objektumok szemantikájához. Ez a modell azért fontos, mert olyan beépített szemantikát határoz meg, amelyet egy objektumorientált DBMS (OODBMS) megért és megvalósíthat. Az ezt a szemantikát használó könyvtárak és alkalmazások szerkezetének hordozhatónak kell lennie az adott objektum-MD-t támogató különféle OODBMS-ek között. Az ODMG architektúra fő összetevői az objektummodell (OM), az objektumdefiníciós nyelv (ODL), az objektumlekérdezési nyelv (OQL), valamint a C ++-hoz, a Java-hoz és a Smalltalkhoz való kapcsolódás képessége.

Az ODMG 2.0 szabvány szerinti objektum adatmodellt a következő tulajdonságok jellemzik:

Az alapvető építőelemek az objektumok és a literálok. Minden objektum egyedi azonosítóval rendelkezik. A literálnak nincs saját azonosítója, és nem létezhet külön objektumként. A literálok mindig objektumokba vannak ágyazva, és nem lehet rájuk külön-külön hivatkozni;

Az objektumok és a literálok típusban különböznek. Minden típusnak megvan a saját tartománya, amelyet az adott típusú objektumok és literálok osztanak meg. A típusoknak viselkedésük is lehet. Ha egy típusnak van valamilyen viselkedése, akkor az adott típusú objektumok mindegyike ugyanazzal a viselkedéssel rendelkezik. A gyakorlatban egy típus lehet az az osztály, amelyből az objektum létrejön, egy interfész vagy egy egyszerű adattípus (például egy egész szám). Egy objektum felfogható egy típus példányának;

Az objektum állapotát a tulajdonságok által megvalósított aktuális értékek halmaza határozza meg. Ezek a tulajdonságok lehetnek egy objektum attribútumai vagy egy objektum és egy vagy több objektum közötti kapcsolat;

Egy objektum viselkedését egy objektumon vagy magán az objektumon végrehajtható műveletek halmaza határozza meg. A műveleteknek lehet egy listája bemeneti és kimeneti paraméterekből, amelyek mindegyike szigorúan meghatározott típusú. Minden művelet visszaadhat egy gépelt eredményt is;

Az adatbázis-definíciókat az Object Definition Language (ODL) nyelven írt séma tárolja. Az adatbázis tárolja az objektumokat, így azokat a különböző felhasználók és alkalmazások megoszthatják.

Az OOMD-n alapuló DBMS-eket objektumorientált DBMS-eknek (OODBMS) nevezik. Ezeket a DBMS-eket harmadik generációs DBMS-eknek nevezik * (* Az adattárolási modellek fejlődésének története gyakran három szakaszra (generációra) oszlik: az első generáció (1960-as évek vége - 70-es évek eleje) - a hierarchikus és hálózati modellek; a második generáció (kb. 1970-1980-as évek) - az relációs modell; harmadik generáció (1980-as évek - 2000-es évek eleje) - Objektumorientált modellek.).

Napjainkban az objektum-orientált adatbázisokat különféle szervezetekben használják sokféle feladat megoldására. Az informatikai adatok területén felhalmozott tapasztalat elemzése és általánosítása lehetővé tette olyan alkalmazások azonosítását, amelyekben az objektum-orientált adatbázisok használata indokolt:

Az alkalmazás nagyszámú, egymással kölcsönhatásban álló részből áll. Mindegyiküknek megvan a maga viselkedése, amely mások viselkedésétől függ;

A rendszernek nagy mennyiségű strukturálatlan vagy összetett adatot kell kezelnie;

Az alkalmazás kiszámítható hozzáférést biztosít majd az adatokhoz, így az objektumorientált adatbázisok navigációs jellege nem jelent jelentős hátrányt;

Az ad hoc kérelmek szükségessége korlátozott;

A tárolt adatok szerkezete hierarchikus vagy hasonló jellegű.

Jelenleg számos objektum-orientált DBMS létezik a szoftverpiacon. asztal A 10.6 bemutatja az osztály néhány kereskedelmi rendszerét.

10.6. táblázat

Modern kereskedelmi OODBMS,

gyártó cégeiket és alkalmazási területeiket

Az egyik alapvető különbség az objektum-adatbázisok és a relációs adatbázisok között az új adattípusok létrehozásának és használatának képessége. Az OODBMS fontos jellemzője, hogy egy új típus létrehozása nem igényli az alapmag módosítását, és az objektum-orientált programozás elvein alapul.

Az OODBMS magja objektumkezelésre van optimalizálva. Természetes műveletei az objektumok gyorsítótárazása, az objektum verziószámozása, az egyes objektumok hozzáférési jogainak szétválasztása. Az OODBMS-eket nagyobb teljesítmény jellemzi az objektumokba csomagolt adatok hozzáférését és visszakeresését igénylő műveleteknél, mint a relációs DBMS-eknél, amelyeknél az összekapcsolt adatok lekérésének szükségessége további belső műveletekhez vezet.

Az OODBMS számára nagyon fontos az objektumok egyik adatbázisból a másikba való áthelyezése.

Az OODBMS-en alapuló különféle alkalmazások létrehozásakor fontos az adott DBMS osztályainak beépített szerkezete. Az osztálykönyvtár általában nem csak az összes szabványos adattípust támogatja, hanem a multimédiás és egyéb összetett adattípusok kiterjesztett halmazát is, például videót, hangot, animációs képkockák sorozatát. Néhány OODBMS osztályban olyan könyvtárakat hoztak létre, amelyek lehetővé teszik a dokumentuminformációk tárolását és teljes szöveges keresését (például Jasmine, ODB-Jupiter). ábrán látható egy példa egy alapvető osztályszerkezetre. 10.17.

A fő pozíciót a TOdbObject osztály foglalja el, amely tartalmazza az adatbázishoz való hozzáférés szabályozásához és az indexelés végrehajtásához szükséges összes tulajdonságot és módszert. Az összes többi osztály felülírja a metódusait az általa megvalósított típus érvényesítési ellenőrzésével és egy adott indexelővel.

ábrából látható. 10.17, a struktúrában különböző osztályok vannak, amelyek a dokumentuminformációk feldolgozására összpontosítanak - TOdbText, TOdbDocument, TODBTextDocument stb. Minden dokumentumot külön objektum képvisel. Így a dokumentumok természetes tárolása biztosított. Az egyik legfontosabb művelet a dokumentumok kérésre történő keresése. A legtöbb osztálynál lehetőség van objektumok keresésére egy adott kulcs értéke alapján. A TOdbText osztály esetében lehetőség van keresési lekérdezés létrehozására természetes nyelven írt kifejezésekre.

A TOdbDocument osztály speciális, különböző típusú objektumok tárolására képes. Mezőkből áll, amelyek mindegyikének van neve, és egy bizonyos típusú objektumhoz van társítva. Ennek az osztálynak a jelenléte lehetővé teszi a felhasználó számára, hogy bővítse a típuskészletet. A konténerobjektum (dokumentum) módosításával beállíthat egy bizonyos mezőkészletet, és így új típusú dokumentumot kaphat.

Az ODB-Jupiter alapján az OODBMS fejlesztői létrehoztak egy teljes értékű ODB-Text információ-visszakereső rendszert, amely a tárolt adatok univerzális struktúrájával és egy hatékony keresőmotorral rendelkezik. Az ODB-Text rendszer a dokumentumok kollektív feldolgozására és a vállalati archívum karbantartására szolgáló eszköz. A lehetséges alkalmazások között megnevezzük a modern iroda dokumentumkezelésének automatizálását, referencia információs rendszerek (hasonlóan a jól ismert Jogi adatbázisokhoz) kiépítését, hálózati adatbázisok karbantartását, személyi nyilvántartásokat, bibliográfiát stb.

41. Az alkalmazott IS tervezésének jellemzői. Az IP fejlesztés fázisai. (11. téma, 100-103. o.).

11.1.3. Az alkalmazott IC rendszerek tervezésének jellemzői

Az információs rendszer felépítése (kiválasztása, adaptálása) során két fő koncepciót, két fő megközelítést alkalmazhat (a harmadik fogalom ezek kombinációja):

1. eligazodás a megoldandó problémákhoz ezen információs rendszer segítségével, azaz. probléma-orientált megközelítés (vagy induktív megközelítés);

2. orientáció az adott rendszerben, környezetben elérhető (frissített) technológia felé, azaz. technológia-orientált megközelítés (vagy deduktív megközelítés).

A koncepció megválasztása stratégiai (taktikai) és (vagy) hosszú távú (rövid távú) kritériumoktól, problémáktól, erőforrásoktól függ.

Ha először a rendelkezésre álló technológia lehetőségeit tanulmányozzuk, majd a segítségükkel megoldható tényleges problémákat határozzuk meg, akkor technológia-orientált megközelítésre kell támaszkodni.

Ha először a tényleges problémákat azonosítják, majd egy olyan technológiát vezetnek be, amely elegendő a problémák megoldására, akkor a probléma-orientált megközelítésre kell támaszkodni.

Ugyanakkor az információs rendszer felépítésének mindkét koncepciója függ egymástól: az új technológiák bevezetése megváltoztatja a megoldandó problémákat, a megoldandó problémák változása pedig új technológiák bevezetésének szükségességét vonja maga után; mindkettő befolyásolja a meghozott döntéseket.

Bármely alkalmazott (vállalati) információs rendszer rendszertervezésének (fejlesztésének) és használatának az információs rendszer alábbi életciklusán kell keresztülmennie:

- tervezés előtti elemzés (más hasonló rendszerek, prototípusok létrehozásában szerzett tapasztalat, a fejlesztés alatt álló rendszer különbségei, jellemzői stb.), a rendszer külső megjelenési formáinak elemzése;

- rendszeren belüli elemzés, belső elemzés (rendszer alrendszerek elemzése);

- a rendszer rendszerszerű (morfológiai) leírása (bemutatása) (a rendszercél leírása, a rendszerrel kapcsolatos kapcsolatok és kapcsolatok a környezettel, más rendszerekkel és rendszerforrásokkal - anyagi, energia, információs, szervezeti, emberi, térbeli és időbeli);

- a megfelelőség, a hatékonyság és a stabilitás (megbízhatóság) kritériumainak meghatározása;

- a rendszer alrendszereinek funkcionális leírása (modellek leírása, alrendszerek működésére szolgáló algoritmusok);

- a rendszer prototípus készítése (elrendezési leírás), a rendszer alrendszerei interakciójának felmérése (elrendezés kidolgozása - alrendszerek megvalósítása egyszerűsített funkcionális leírásokkal, eljárásokkal, és ezen elrendezések interakciójának jóváhagyása a rendszer kielégítése érdekében cél), míg lehetséges a megfelelőségi, stabilitási, hatékonysági kritériumok "elrendezései";

- a rendszer "összeállítása", tesztelése - teljes értékű funkcionális alrendszerek és kritériumok megvalósítása, a modell értékelése a megfogalmazott szempontok szerint;

- a rendszer működése;

- célok meghatározása a rendszer és alkalmazásai továbbfejlesztéséhez;

- rendszerkarbantartás - a rendszer képességeinek pontosítása, módosítása, bővítése a működés módjában (a fejlesztése céljából).

Ezek a szakaszok alapvetőek az információs rendszerek újratervezéséhez.

A vállalati információs rendszer fejlesztése általában egy nagyon specifikus vállalkozás számára történik. A vállalkozás tárgyi tevékenységének sajátosságai kétségtelenül befolyásolják az információs rendszer felépítését. Ugyanakkor a különböző vállalkozások struktúrái általában hasonlóak egymáshoz. Minden szervezet, tevékenységi típusától függetlenül, számos részlegből áll, amelyek közvetlenül végeznek egyik vagy másik típusú vállalati tevékenységet. És ez a helyzet szinte minden szervezetre igaz, függetlenül attól, hogy milyen típusú tevékenységet folytatnak.

Így bármely szervezet kölcsönható elemek (divíziók) halmazának tekinthető, amelyek mindegyikének megvan a maga meglehetősen összetett szerkezete. Az osztályok közötti kapcsolatok is meglehetősen összetettek. Általánosságban elmondható, hogy a vállalkozás részlegei között háromféle kapcsolat létezik:

Funkcionális kapcsolatok – minden részleg bizonyos típusú munkát végez egyetlen üzleti folyamaton belül;

Információs kommunikáció - az osztályok információt cserélnek (dokumentumok, faxok, írásbeli és szóbeli megrendelések stb.);

Külső kapcsolatok - egyes egységek kölcsönhatásba lépnek a külső rendszerekkel, és interakciójuk információs és funkcionális is lehet.

A különböző vállalkozások szerkezetének általánossága lehetővé teszi, hogy megfogalmazzuk a vállalati információs rendszerek felépítésének néhány közös alapelvét.

Általánosságban elmondható, hogy az információs rendszer fejlesztésének folyamata két szempontból vizsgálható:

Idő vagy a fejlesztés alatt álló rendszer életciklusának szakaszai szerint. Ebben az esetben a fejlesztési folyamat dinamikus szerveződését veszik figyelembe, ciklusok, szakaszok, iterációk és szakaszok szerint leírva.

Egyfajta projektként egy vállalati információs rendszert fejlesztenek ki. A projektmenedzsment és a projektfejlesztési fázisok (életciklus-fázisok) sok jellemzője általános, nem csak a témakörtől, hanem a projekt jellegétől is függ (nem számít, hogy mérnöki vagy gazdasági projektről van szó) . Ezért érdemes először megvizsgálni néhány általános projektmenedzsment kérdést.

A projekt egy külön rendszer időben korlátozott, célirányos változtatása kezdetben egyértelműen meghatározott célokkal, amelynek elérése meghatározza a projekt megvalósulását, valamint meghatározott határidőkkel, eredményekkel, kockázattal, a források elköltésének mértékével, ill. erőforrások és a szervezeti struktúra tekintetében.

Általában egy összetett fogalom esetében (amely különösen egy projekt fogalma) nehéz olyan egyértelmű megfogalmazást adni, amely teljes mértékben lefedi a bevezetett koncepció összes jellemzőjét. Ezért az adott meghatározás nem állítja magát egyedinek és teljesnek.

A projektnek, mint menedzsmentobjektumnak a következő főbb megkülönböztető jegyei különböztethetők meg:

A variabilitás egy rendszer célirányos átvitele egy meglévőből egy bizonyosba

a kívánt állapot, a projekt céljaival összefüggésben;

A végső cél korlátozottsága;

Korlátozott időtartam;

Korlátozott költségvetés;

Korlátozott erőforrások szükségesek;

Újdonság a vállalkozás számára, amely számára a projektet megvalósítják;

Komplexitás - számos olyan tényező jelenléte, amelyek közvetlenül vagy közvetve befolyásolják a projekt előrehaladását és eredményeit;

Jogi és szervezeti támogatás - meghatározott szervezeti struktúra kialakítása a projekt időtartamára.

A munka hatékonyságát a projekt megvalósítási folyamatának irányításával érik el, amely biztosítja az erőforrások allokációját, a munkafolyamatok összehangolását és a belső és külső zavaró hatások kompenzálását.

Az irányítási rendszerek elmélete szempontjából a projektnek, mint vezérlési objektumnak megfigyelhetőnek és ellenőrizhetőnek kell lennie, azaz megkülönböztethető néhány jellemző, amellyel folyamatosan nyomon lehet követni a projekt előrehaladását (a megfigyelhetőség tulajdonsága) . Ezen túlmenően szükség van a projekt végrehajtásának menetét időben befolyásoló mechanizmusokra (az irányíthatóság tulajdonsága).

Az irányíthatóság tulajdonsága különösen fontos a témakör bizonytalansága és változékonysága esetén, amely gyakran kíséri az információs rendszerek fejlesztésére irányuló projekteket.

Minden projekt, függetlenül a megvalósításához szükséges munka bonyolultságától és mennyiségétől, bizonyos állapotokon megy keresztül a fejlődése során: attól az állapottól, amikor "a projekt még nincs", egy olyan állapotig, amikor "a projekt már nincs meg". Az ötlet felmerülésétől a projekt teljes befejezéséig tartó fejlesztési szakaszok halmazát általában fázisokra (szakaszokra, szakaszokra) osztják.

A fázisok számának és tartalmának meghatározásában van némi különbség, mivel ezek a jellemzők nagymértékben függenek az adott projekt megvalósításának feltételeitől és a fő résztvevők tapasztalataitól. Ennek ellenére az információs rendszer fejlesztési folyamatának logikája és fő tartalma szinte minden esetben megegyezik.

Az információs rendszer fejlesztésének a következő fázisai különböztethetők meg:

Fogalomalkotás;

Műszaki specifikációk kidolgozása;

Tervezés;

Gyártás;

A rendszer üzembe helyezése.

Tekintsük mindegyiket részletesebben. A második és részben a harmadik fázist rendszerint a rendszertervezés fázisának, az utolsó kettőt (ez néha a tervezési fázist is magában foglalja) pedig a megvalósítás fázisainak nevezik.

Fogalmi fázis

Ötletalkotás, célkitőzés;

Kulcsfontosságú projektcsapat kialakítása;

Az ügyfél és a többi résztvevő motivációjának és követelményeinek tanulmányozása;

Alapadatok gyűjtése és a meglévő állapot elemzése;

Az alapvető követelmények és korlátozások, a szükséges anyagi, pénzügyi és munkaerő-források meghatározása;

Alternatívák összehasonlító értékelése;

Javaslatok benyújtása, megvizsgálása és jóváhagyása.

Műszaki javaslat kidolgozása

A projekt fő tartalmának, a projekt alapstruktúrájának kialakítása;

Műszaki előírások kidolgozása és jóváhagyása;

A projekt alapvető szerkezeti modelljének tervezése, lebontása;

A projekt becslése és költségvetése, forrásigény meghatározása;

Beosztások és bővített munkarendek kialakítása;

Szerződés aláírása az ügyféllel;

A projektben résztvevők kommunikációs eszközeinek üzembe helyezése és a munka előrehaladásának ellenőrzése.

Tervezés

Ebben a fázisban meghatározzák az alrendszereket, azok összefüggéseit, kiválasztják a projektvégrehajtás és az erőforrás-felhasználás leghatékonyabb módjait. Ennek a szakasznak a tipikus alkotásai:

Alapvető tervezési munka;

Privát műszaki specifikációk kidolgozása;

Koncepcionális tervezés;

Műszaki előírások és utasítások elkészítése;

Terv benyújtása, szakvélemény és jóváhagyás.

Fejlesztése

Ebben a fázisban történik a projektmunka koordinációja és operatív ellenőrzése, az alrendszerek gyártása, kombinálása és tesztelése. Központi téma:

Szoftverfejlesztési munka végrehajtása;

Felkészülés a rendszer bevezetésére;

A projekt főbb mutatóinak ellenőrzése, szabályozása.

Rendszer üzembe helyezés

Ebben a fázisban zajlanak a tesztek, a rendszer valós körülmények közötti próbaüzeme, tárgyalások folynak a projekt eredményeiről és az esetleges új szerződésekről. Főbb munkatípusok:

Összetett tesztek;

42. Az IP életciklusának fogalma. (11. téma, 103-105. o.).

Bevezetés

Az objektum-orientált adatbázisok (OODB) irányvonalának kialakulását elsősorban a gyakorlati igények határozták meg: olyan komplex információalkalmazási rendszerek kialakításának igénye, amelyekre a korábbi adatbázisrendszerek technológiája nem volt teljesen kielégítő. Természetesen az OODB nem a semmiből jelent meg. Ennek megfelelő alapot adták mind az adatbázisokkal kapcsolatos korábbi munkák, mind a programozási nyelvek régóta fejlődő területei az absztrakt adattípusokkal és az objektum-orientált programozási nyelvekkel.

Az adatbázisok területén végzett korábbi munkákkal való kapcsolat tekintetében az OODB területén végzett munkára a legnagyobb hatást a DBMS és a következő kronológiai adatbáziscsalád fejlesztése gyakorolta, amelyben az összetett objektumok kezelését támogatták. . Ezek a tevékenységek adták az OOBD szervezet strukturális alapját. Ebben az absztraktban az OOMD-t és az OODBMS-t fogjuk figyelembe venni.

Objektumorientált adatmodell

Fontolja meg az adatbázis felépítésének egyik megközelítését – objektumorientált adatmodell (OOMD) használatával. Az OOMD adatmodellezése az objektum fogalmán alapul. Az ODM-et általában olyan összetett tématerületeken használják, amelyekben hiányzik a relációs modell funkcionalitása a modellezéshez (például tervezési automatizálási rendszerek (CAD), publikációs rendszerek stb.) esetében.

Az ODMG objektumorientált adatmodell mindenekelőtt egy alapvető szempontban különbözik a többi modelltől. Az SQL adatmodellben és a valódi relációs adatmodellben az adatbázis azonos általános típusú elnevezett adattárolók gyűjteménye: táblák vagy relációk. Az objektumorientált adatmodellben az adatbázis tetszőleges típusú objektumok (adattárolók) gyűjteménye.

Objektumorientált DBMS (OODBMS) létrehozásakor különböző módszereket használnak, nevezetesen:

az adatbázisokkal való munkavégzésre szánt eszközök objektum-orientált nyelvbe ágyazása;

a meglévő nyelv kiterjesztése objektum-orientált funkciókkal rendelkező adatbázisokkal való munkavégzéshez;

objektum-orientált függvénykönyvtárak létrehozása adatbázisokkal való munkavégzéshez;

új nyelv és új objektumorientált adatmodell létrehozása.

Az OOMD előnyei közé tartozik a tartomány modellezésének bőséges lehetősége, a kifejező lekérdezési nyelv és a nagy teljesítmény. Az OOMD-ben minden objektum egyedi azonosítóval (OID - objektumazonosító) rendelkezik. Az OID lekérése lényegesen gyorsabb, mint a relációs tábla keresése.

Az OOMD hátrányai között meg kell említeni az általánosan elfogadott modell hiányát, az OODB létrehozásában és működtetésében szerzett tapasztalatok hiányát, a használat bonyolultságát és az adatvédelmi eszközök elégtelenségét.

Most nézzük meg, hogyan valósítják meg az adatmodell-támogatást a valós adatbázis-kezelő rendszerekben.

Az objektum-orientált modellben (OOM) az adatok bemutatásakor lehetőség nyílik az egyes adatbázisrekordok azonosítására. Az adatbázis-rekordok és feldolgozási funkcióik között az objektum-orientált programozási nyelvekhez hasonló mechanizmusok segítségével hoznak létre kapcsolatokat.

A szabványos OOM leírása az ODMG-93 (Object Database Management Group) szabvány ajánlásaiban található. Az ODMG-93 ajánlásait még nem hajtották végre teljes mértékben. A kulcsfontosságú ötletek szemléltetéséhez vegyünk egy kissé leegyszerűsített objektumorientált adatbázis modellt.

Az OO adatbázis szerkezetét grafikusan egy fa formájában ábrázoljuk, melynek csomópontjai objektumok. Az objektumok tulajdonságait valamilyen szabványos típus (például egy karakterlánc típus) vagy egy felhasználó által szerkesztett típus (osztályként definiálva) írja le.

A string típusú tulajdonság értéke egy karakterlánc. A class típusú tulajdonság értéke egy olyan objektum, amely a megfelelő osztály példánya. Egy osztály minden példányát annak az objektumnak a leszármazottjának tekintik, amelyben tulajdonságként definiálták. Egy osztály példányobjektuma az osztályához tartozik, és egyetlen szülője van. Az adatbázisban lévő általános kapcsolatok az objektumok kapcsolódó hierarchiáját alkotják.

Az első formalizált és általánosan elfogadott adatmodell a Codd-féle relációs modell volt. Ebben a modellben, akárcsak a következőkben, három szempontot különítettek el: strukturális, holisztikus és manipulatív. A relációs modell adatstruktúrái lapos normalizált kapcsolatokon alapulnak, az integritási megszorításokat elsőrendű logikával fejezik ki, végül az adatmanipuláció relációs algebrán vagy azzal egyenértékű relációs számításon alapul. Amint azt sok kutató megjegyzi, a relációs adatmodell nagyrészt annak köszönheti sikerét, hogy a halmazelmélet, a relációk és az elsőrendű logika szigorú matematikai apparátusára támaszkodott. Bármely konkrét relációs rendszer tervezői kötelességüknek tekintették, hogy megmutassák, hogy adott adatmodelljük megfelel az általános relációs modellnek, amely a rendszer "relációjának" mértékeként működött.

Az objektum-orientált adatmodellezés fő nehézségei abból fakadnak, hogy nincs olyan fejlett matematikai apparátus, amelyre egy általános objektum-orientált adatmodell támaszkodhatna. Ezért nagyrészt még mindig nincs alapvető objektum-orientált modell. Másrészt egyes szerzők azzal érvelnek, hogy a klasszikus értelemben vett általános objektum-orientált adatmodell nem definiálható, mivel az adatmodell klasszikus koncepciója nem illik az objektum-orientált paradigmához.

Az egyik leghíresebb adatmodell-teoretikus, Beeri felvázolja az OODB formális keretrendszerét, amely korántsem teljes, és nem a hagyományos értelemben vett adatmodell, de lehetővé teszi az OODB rendszerek kutatói és fejlesztői számára, hogy legalább egy nyelv (kivéve persze, ha a Beeri mondatokat fejlesztik és támogatják). E javaslatok további sorsától függetlenül hasznosnak tartjuk ezek rövid összefoglalását.

Először is, sok OODB gyakorlatát követve, az objektummodellezés két szintjének megkülönböztetése javasolt: alsó (strukturális) és felső (viselkedési). Szerkezeti szinten az összetett objektumok, azok azonosítása és az "isa" kommunikáció típusai támogatottak. Az adatbázis az „osztályban van” vagy „attribútum” kapcsolattal összekapcsolt adatelemek gyűjteménye. Így a DB irányított gráfnak tekinthető. Fontos szempont, hogy az objektum fogalmával együtt a jelentés fogalmát is karbantartsuk (később látni fogjuk, hogy az egyik sikeres objektum-orientált DBMS O2-ben mennyit építenek erre).

Fontos szempont az adatbázisséma és magának az adatbázisnak a világos elkülönítése. Az OODB sémaszint elsődleges fogalmai a típusok és az osztályok. Meg kell jegyezni, hogy minden rendszerben, amely csak egy fogalmat (akár egy típust, akár egy osztályt) használ, ez a fogalom elkerülhetetlenül túlterhelt: a típus feltételezi egy bizonyos értékkészlet jelenlétét, amelyet az ilyen típusú adatstruktúra határoz meg; egy osztály objektumok halmazát is feltételezi, de ez a halmaz felhasználó által meghatározott. Így a típusok és az osztályok különböző szerepet töltenek be, és a szigorúság és az egyértelműség érdekében mindkét koncepciót egyszerre kell támogatni.

Beeri nem mutat be teljes formális modellt az OODB strukturális szintjéről, de kifejezi meggyőződését, hogy a jelenlegi megértés szintje elegendő egy ilyen modell formalizálásához. Ami a viselkedési szintet illeti, csak az ehhez szükséges logikai apparátus általános megközelítését javasoljuk (az első szint logikája nem elegendő).

Beeri fontos, bár nem kellően alátámasztott feltételezése, hogy a két hagyományos réteg - a séma és az adat - nem elegendő az OODB-hez. Az OODB pontos meghatározásához metaséma szintre van szükség, amelynek tartalmának meg kell határoznia az adatbázisséma szintjén engedélyezett objektumok és kapcsolatok típusait. A metaséma ugyanazt a szerepet kell betöltse az OODB-k esetében, mint a relációs adatmodell szerkezeti része a relációs adatbázissémák esetében.

Az objektum-orientált adatmodellek témájához sok más publikáció is kapcsolódik, de ezek vagy meglehetősen konkrét kérdéseket érintenek, vagy túl komoly matematikai apparátust használnak ehhez az áttekintéshez (például egyes szerzők objektum-orientált adatmodellt definiálnak). kategóriaelmélet alapján).

A dolgok jelenlegi állapotának szemléltetésére röviden áttekintjük az O2 objektum-orientált DBMS-ben használt konkrét adatmodell jellemzőit (ez természetesen szintén nem a klasszikus értelemben vett adatmodell).

Az O2 objektumokat és értékeket támogat. Egy objektum egy pár (azonosító, érték), és az objektumok be vannak zárva, azaz. értékeik csak metódusokon – objektumokhoz kötött eljárásokon keresztül érhetők el. Az értékek lehetnek atomi vagy szerkezetiek. A strukturális értékeket az azonosítóik által képviselt értékekből vagy objektumokból építik fel halmaz-, sor- és listakonstruktorok segítségével. A strukturális értéktagok előre meghatározott műveletek (primitívek) segítségével érhetők el.

Az adatok rendezésének két módja van: osztályok, amelyeket adatokat és viselkedést magában foglaló objektumok példányosítanak, és típusok, amelyek példányai értékek. Minden osztályhoz egy típus tartozik, amely leírja az osztály példányainak szerkezetét. A típusokat rekurzívan definiáljuk az atomi típusokból és a korábban meghatározott típusokból és osztályokból konstruktorok segítségével. Egy osztály viselkedési oldalát metódusok halmaza határozza meg.

Az objektumok és értékek elnevezhetők. Egy objektum vagy érték elnevezése annak perzisztenciájához kapcsolódik: minden elnevezett objektum vagy érték perzisztens; minden objektum vagy érték, amely egy másik elnevezett objektum vagy érték része, tartós.

Az osztály meghatározásakor adott speciális utasítás segítségével az osztály bármely objektumának hosszú távú tárolását elérheti. Ebben az esetben a rendszer automatikusan generál egy beállított értéket, amelynek neve megegyezik az osztály nevével. Ez a készlet garantáltan tartalmazza ennek az osztálynak az összes objektumát.

Módszer - egy adott osztályhoz társított programkód, amely az osztály objektumaira alkalmazható. A módszer O2-ban történő meghatározása két lépésben történik. Először is deklarálják a metódus aláírását, azaz. annak neve, osztálya, argumentumtípusai vagy osztályai és eredménytípusa vagy osztálya. A metódusok lehetnek nyilvánosak (más osztályok objektumaiból elérhetők) vagy privátak (csak ezen az osztályon belül érhetők el). A második szakaszban meghatározzák az osztály megvalósítását az egyik O2 programozási nyelven (a nyelveket részletesebben áttekintésünk következő szakaszában tárgyaljuk).

Az O2 modell támogatja a több osztályú öröklődést a szupertípus/altípus kapcsolat alapján. Az alosztály jogosult attribútumokat és metódusokat hozzáadni és/vagy felülírni. A többszörös öröklődés esetén (az attribútumok és metódusok elnevezésében) előforduló kétértelműségeket vagy átnevezéssel, vagy az öröklődés forrásának kifejezett megadásával oldják meg. Az alosztály objektum minden olyan szuperosztály objektuma, amelyből az alosztály származik.

Az előre meghatározott "Object" osztály támogatott, amely az osztályrács gyökere; minden más osztály az "Object" osztály implicit örököse, és örökli az előre meghatározott metódusokat ("is_same", "is_value_equal" stb.).

Az O2 modell sajátossága, hogy képes további "exkluzív" attribútumokat és metódusokat deklarálni elnevezett objektumokhoz. Ez azt jelenti, hogy egy osztály adott megnevezett reprezentatív objektumának típusa lehet, amely az osztály típusának altípusa. Természetesen a szabványos osztálymetódusok ilyen attribútumokkal nem működnek, de speciálisan egy elnevezett objektumhoz további (vagy szabványos) metódusok definiálhatók, amelyekhez már rendelkezésre állnak további attribútumok. Hangsúlyozzuk, hogy nem egy konkrét objektumhoz, hanem egy névhez kapcsolódnak további attribútumok, metódusok, amelyek mögött általánosságban elmondható, hogy különböző időpontokban különböző objektumok állhatnak. Az exkluzív attribútumok és módszerek megvalósításához késői kötési technikák fejlesztése szükséges.

A következő részben többek között megvizsgáljuk az O2 rendszer programozási nyelveinek és lekérdezéseinek jellemzőit, amelyek természetesen szorosan kapcsolódnak az adatmodell sajátosságaihoz.