Objektumorientált modell. Objektumorientált adatmodell

Alapvető fogalmak

Meghatározás 1.

Objektumorientált modellaz adatok bemutatása lehetővé teszi az egyes adatbázis-bejegyzések azonosítását.

Az adatbázis-nyilvántartások és feldolgozási funkciók az objektumorientált programozási nyelveken végrehajtott megfelelő eszközökhöz hasonló mechanizmusokhoz kapcsolódnak.

2. meghatározás.

Grafikai ábrázolás Az objektumorientált adatbázis struktúrái olyan fa, amelynek csomópontjai objektumokat képviselnek.

Standard típus (például string - húr) vagy a felhasználó által létrehozott típus ( osztály), körülír az objektumok tulajdonságai.

Az 1. ábrán a könyvtári objektum egy szülő az osztály példányi objektumkönyvtár, az előfizető és a kibocsátás. Különböző tárgyak, például egy könyv lehet egy vagy különböző szülő. Olyan tárgyaknál, mint egy olyan könyv, amely ugyanazzal a szülővel rendelkezik, legalább különböző készletszámmal kell rendelkeznie (egyedülálló a könyv minden egyes példányához), de azonos értékek Tulajdonságok szerző, név, uDC és iSBN..

Az objektumorientált és hierarchikus adatbázis logikai szerkezete hasonló. Ezek különböznek a manipulációs adatok főbb módszereiben.

Az objektumorientált modellben történő adatokat, a logikai műveleteket használják, amelyeket a kapszulázás, az öröklés és a polimorfizmus fokozódik. Bizonyos korlátozás esetén az SQL parancsokhoz hasonló műveleteket alkalmazhat (például egy adatbázis létrehozásakor).

Amikor létrehozására és módosítására az adatbázis, automatikus képzését, majd kiigazítása indexek (index táblák) végzik, amelyek információkat tartalmaznak gyors kereséséhez adatokat.

3. meghatározás.

célja egységbezárás - az objektum határainak tulajdonságainak hatályának korlátozása.

Például, ha az ingatlan hozzáadódik az objektumhoz, amely meghatározza a szerző telefonját, és van egy neve telefonAz azonos név tulajdonságai a katalógus és az előfizetői objektumok. Az ingatlan jelentését az objektum határozza meg, amelyben kapszulázott.

Meghatározás 4.

Öröklés, Vissza kapszulázás, felelős az ingatlan láthatóságának terjesztéséért az objektum minden leszármazottaihoz képest.

Például minden objektumkönyv, amely az objektumkönyvtár leszármazottai, a szülő objektum tulajdonságai tulajdonítható: szerző, név, uDC és iSBN..

Ha szükséges, hogy bővíteni kell az öröklési mechanizmus cselekvését olyan tárgyakhoz, amelyek nem közvetlen rokonok (például két leszármazottak egy szülő) az általános őseikben meghatározzák a típus absztrakt tulajdonát aBS.

Így a tulajdonságok szám és jegy A könyvtár tárgyában minden leányvállalat, könyv és előfizető. Ezért az Osztályok és a kibocsátás ezen tulajdonságai azonosak - 00015 (1. ábra).

5. meghatározás.

Polimorfizmus Lehetővé teszi ugyanazt a programkódot, hogy többutas adatokkal dolgozzon.

Más szóval, elismeri az objektumokat különböző típusok Módszerekkel (funkciók vagy eljárások) azonos nevekkel rendelkeznek.

Keresés Az objektum-orientált adatbázis az, hogy meghatározza a felhasználó által megadott objektum közötti hasonlóságot, és az adatbázisban tárolt objektumokat.

Az objektumorientált modell előnyei és hátrányai

Alapvető előny Az objektumorientált adatmodell, a relációs modellrel ellentétben az objektumok összetett kapcsolataival kapcsolatos információk megjelenítésének lehetősége. A vizsgált adatmodell lehetővé teszi az adatbázis külön bejegyzését és a feldolgozás funkcióit.

NAK NEK hátrányok Az objektumorientált modell a magas fogalmi nehézséghez, kényelmetlen adatfeldolgozáshoz és alacsony lekérdezésekhez tartozik.

A mai napig az ilyen rendszerek meglehetősen elterjedtek. Ezek közé tartozik a DBMS:

• Posztgres,
• Orion
• Írisz
• Odbjupiter,
• Versely
• Objectivity / DB,
• Tárgystár
• Statice
• Drágakő
• G-bázis.

Objektumorientált adatbázis (Obs) - olyan adatbázis, amelyben az adatok objektumok formájában, attribútumainak, módszereinek és osztályai formájában szerepelnek.

Az objektumorientált adatbázisok általában olyan esetekben ajánlottak, ha nagy teljesítményű adatfeldolgozásra van szükség, amely komplex szerkezetű.

A Manifestben az OBS kötelező jellemzőket kínál, amelyeknek az OBD felelősnek kell lennie. A választás 2 kritériumon alapul: a rendszernek objektumorientáltnak kell lennie, és egy adatbázist képvisel.

Kötelező jellemzők

1. A komplex objektumok támogatása. A rendszernek biztosítania kell az összetett objektumok létrehozásának lehetőségét a tervezői objektumok alkalmazásával. Szükséges, hogy az objektumtervező ortogonális, vagyis bármely tervező bármely objektumra alkalmazható.

2. Az egyes objektumok támogatása. Minden objektumnak egyedi azonosítóval kell rendelkeznie, amely nem függ attribútumuk értékétől.

3. A kapszulázás támogatása. Helyes kapszulázás érhető el annak a ténynek köszönhetően, hogy a programozóknak joguk van hozzáférni csak a módszerek módszereinek, és a módszerek adatai és végrehajtása az objektumok belsejében rejtőzik.

4. Támogató típusok és osztályok. Szükséges, hogy a típusok és osztályok között legalább egy koncepciókülönbözetet tartják fenn. (A "Típus" kifejezés egyre inkább megfelel az absztrakt adattípus fogalmának. A programozási nyelveknél a változó a típusával van bejelentve. A fordító használhatja ezt az információt, hogy ellenőrizze a változó kompatibilitásból végrehajtott műveleteket, amely lehetővé teszi az Ön típusát A helyesség garantálása szoftver. Másrészt az osztály egyfajta sablon az objektumok létrehozásához, és olyan módszereket biztosít, amelyek alkalmazhatók ezekre az objektumokra. Így a "osztály" koncepciója nagyobb mértékben a végrehajtás időpontjára utal, mint a fordítási idő.)

5. Támogatja az őseik típusának és osztályának örökségét. Altípus vagy alosztály, meg kell adnia az attribútumokat és a módszereket a szupertípusból, vagy a Superclass-ból.

6. Túlterhelés kombinációban teljes kötéssel. A különböző típusú tárgyakra kell alkalmazni. A módszer végrehajtása a tárgyak típusától függ, amelyre ezt a módszert alkalmazzák. Ennek a funknakcionalitásnak a biztosítása érdekében a rendszerben lévő eljárási módszerek kötődését nem szabad elvégezni a program végrehajtási idejéig.

7. Számítástechnikai teljesség. Az adatkezelési nyelvnek programozási nyelvnek kell lennie Általános rendeltetésű.

8. Az adattípusok készletének bővíthetőnek kell lennie. A felhasználónak olyan eszközökkel kell rendelkeznie, amely új adattípusokat hozhat létre előre meghatározott rendszertípusok alapján. Ezenkívül nem lehet különbség a rendszer és a felhasználói adattípusok használata módszerei között.

Oo dbms

Objektumorientált adatbázisok - Adatbázisok, amelyekben az információkat objektumokként mutatják be objektumorientált programozási nyelveken.

Alkalmazza vagy ne alkalmazza az objektumorientált adatbázis-kezelő rendszereket (Oosubd) alkalmazása valós projektekben ma? Milyen esetekben alkalmazzák őket, és mit nem?

Itt előnyök Usubd használat:

· Nincs probléma az alkalmazás modelljének ellentmondása az alkalmazásban és a BD (impedancia eltérés). Minden adat az adatbázisban ugyanabban az űrlapon tárolódik, mint az alkalmazásmodellben.

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

· Az adatforrás szintjén lévő összes objektum szigorúan beírható. Nincsenek oszlopnevek! A refactoring objektumorientált adatbázis és a kódoló kód automatizált, és nem egy monoton és unalmas folyamat.

Standard ODMG.

Első manifesztformálisan csak egy cikk volt Konferencia tárgyorientált és deduktív adatbázisokkalegyének csoportja. Amint azt az előző alfejezetben látta, a manifeszt követelményei meglehetősen érzelmi, mint egyértelműen meghatározottak. 1991-ben az ODMG konzorcium alakult ki (ez a rövidítés kiderült, mint Objektum adatbázis-kezelőcsoportDe később szélesebb értelmezést szerzett - Objektumadatkezelő csoport). Az ODMG konzorcium szorosan kapcsolódik egy sokkal számos OMG konzorciumhoz ( Objektumkezelő csoport.), amelyet két évvel korábban alakítottak ki. Az ODMG fő forráscélja az objektumorientált adatbázisok ipari színvonalának fejlesztése (általános modell). Alapul az alapvető objektummodell omg com ( Core objektummodell). Az ODMG több mint egy évtizede megjelent alapváltozatok Standard, az utolsó, amelynek neve ODMG 3.0. tizenhat

Vicces, hogy bár az ODMG (a szerző szerint) az OMG-ből származott, az elmúlt években néhány OMG szabvány az ODMG objektummodellen alapul. Az OCL nyelvi specifikáció különösen az ODMG modellen alapul ( Objektum korlátozó nyelv.), amely része az UML 1.4 nyelv (és az UML 2.0) általános specifikációjának. Ebben a cikkben nem teszünk célt az OMG és ODMG megközelítések részletes összehasonlítása és az érdeklődő olvasók küldése Encyclopedia Kogalovsky és a konzorciumok anyagai. Az ODMG -3 szabványban szereplő főbb ötletek rövid bemutatására korlátozódunk.

Építészet ODMG.

A javasolt ODMG architektúrát az 1. ábrán mutatjuk be. 2.1. Ez az architektúra meghatározza az adattárolási módszert és a különböző típusú felhasználói hozzáférést ehhez a "Data Warehouse" 17. Egyetlen adatraktár áll rendelkezésre az adatmeghatározás nyelvéről, lekérdezési nyelvéről és számos adatkezelési nyelvéről. 18. ábra. 2.1 ODL eszközök Objektummeghatározás nyelv (objektummeghatározás nyelv), OQL - Objektum lekérdezési nyelv (nyelvi lekérdezés nyelv)és OML - Objektum manipulációs nyelv (objektum manipulációs nyelv).

Ábra. 2.1. Építészet ODMG.

Az építészet központi szerepe van adatmodella szervezeti struktúra, amelyben az Oosubd által kezelt összes adat marad. Az objektummeghatározás nyelvét, lekérdezési nyelvét és manipulációs nyelvét úgy tervezték meg, hogy minden képessége az adatmodellen alapuljon. Az architektúra számos végrehajtási struktúrát létesít a szimulált adatok tárolására, de fontos követelmény az, hogy az összes szoftverkönyvtárat és az összes támogató eszközt objektumorientált keretrendszerben biztosítják, és az adatokkal való koordinációban kell fenntartani.

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

• Az adatok objektummodellje.Az OOSUBD által fennálló összes adat az adatmodelltervek tekintetében strukturálódik. Az adatmodellben meghatározzák az összes fogalom pontos szemantikáját (lásd alább).

• Adatmeghatározás nyelv (ODL).Az adatbázis-áramköröket az ODL nyelv alapján írják le, amelyben az adatmodelltervek definíciós nyelv formájában vannak megadva. Az ODL lehetővé teszi, hogy az sémát objektumtípus-interfészekként leírja, amely magában foglalja azokat a típusok és kölcsönhatások tulajdonságainak leírását, valamint a műveletek és paraméterek nevét. Az ODL nem teljes programozási nyelv; A típusokat az OML kategória egyik nyelvén kell végrehajtani. Ezenkívül az ODL az virtuálisa nyelv abban az értelemben, hogy az ODMG szabvány nem igényli végrehajtását az Oosubd szoftvertermékeiben, amelyek a szabvány szempontjából relevánsak. E megfelelő definíciós nyelvű termékek támogatása, beleértve az összes ODL-képességet, de az adott rendszer jellemzőihez igazítva. Azonban az ODMG szabványban az ODL nyelvi specifikáció jelenléte azonban fontos, mivel az adatmodell tulajdonságait a nyelv tartalmazza.

• Az objektumkérések nyelve (ODL). A nyelv a szintaxishoz hasonló szintaktikával rendelkezik sQL nyelvDe az ODMG objektummodell szemantikájára támaszkodik. A szabvány lehetővé teszi az OQL közvetlen használatát és beágyazódhat az OML kategória egyik nyelvébe.

Relációs adatmodell

Szinte minden modern rendszerek alapján relációs(Relációs) adatbáziskezelési modellek. Név relációsez annak köszönhető, hogy az ilyen adatbázisban lévő minden egyes bejegyzés csak egy adott objektumra vonatkozó információkat tartalmaz.

BAN BEN relációsDBMS Minden feldolgozott adat lapos táblákként jelenik meg. A konkrét forma tárgyairól szóló információkat táblázatos formában mutatjuk be: különböző objektum-attribútumokat koncentrálunk a táblázat oszlopaiban, és a húrokat úgy tervezték, hogy az összes attribútum leírását tartalmazza az egyes objektumok egyedi példányaihoz.

Az infografikus modellezés színpadán létrehozott modell többnyire kielégíti a relációs elveit. Azonban, hogy ezt a modellt a relációhoz a hívott eljárás végezze el normalizálás.

A normalizációs elmélet öt normál formák. Ezeket az űrlapokat úgy tervezték, hogy csökkentse az információ redundanciáját, ezért minden későbbi normál formanyomtatványnak meg kell felelnie az előző és néhány további feltétel követelményeinek. Az adatbázisok gyakorlati kialakításával a negyedik és az ötödik formákat általában nem használják. Az első négy normál forma megfontolására korlátozódunk.

Bemutatjuk a szükséges fogalmakat annak megértéséhez, hogy megértsük a modellt a relációs rendszerhez.

Hozzáállás- A leírt objektum absztrakciója a tulajdonságok összessége. A tervezés infografikus szakaszának lebonyolítása, beszéltünk az objektumok absztrakciójáról, és bizonyos tulajdonságokkal rendelkeztek nekik. Most, fogalmi tervezés, az absztrakció következő szintjére költözünk. Az objektumok ebben a szakaszában, mint ilyen, már nem létezik. Olyan tulajdonságokkal működünk, amely egy objektumot határoz meg.

A kapcsolat példánya- egy adott objektum tulajdonságainak értéke.

Elsődleges kulcs- Az attribútumok meghatározása, azaz azaz E attribútumok értéke egyedülálló ebben a tekintetben. Az elsődleges kulcsban ugyanazokat az értékeket tartalmazó kapcsolat két példánya van.

Egyszerű attribútum- attribútum, amelynek jelentései oszthatatlanok.

Összetett attribútum- attribútum, amelynek értéke számos különböző objektum tulajdonsága vagy számos ingatlan értéke.

A lényeg fogalma ..

Tartomány

A domain koncepciója pontosabb adatbázisok, bár néhány programozási nyelvű altípusokkal rendelkezik. A legáltalánosabb formában a domaint egy bizonyos alapvető típusú adatok feladata, amelyhez a tartomány elemei és az adattípus-elemhez tartozó önkényes logikai kifejezés. Ha a logikai kifejezés kiszámítása az "igazság" eredményét adja meg, az adatelem a tartomány eleme.

A tartomány fogalmának legmegfelelőbb intuitív értelmezése a domain megértése megengedett potenciális értékrendként ez a típus. Például a domain „nevek” a mi példánkban meghatározása az alapvető típusa karakterfűzérek, de ez a szám értékek csak azokat a sorokat, amelyek ábrázolják a nevet (különösen az ilyen vonalak nem kezdődhet egy puha jel).

Azt is meg kell jegyezni, hogy a tartomány fogalmának szemantikai terhei: Az adatok csak akkor tekinthetők, ha egy tartományra vonatkoznak. Példánkban a domainok "Pass Numbers" és "Csoportszám" domainjei az egész számok típusára vonatkoznak, de nem hasonlíthatók össze. Ne feledje, hogy a legtöbb relációs DBMS-ben a tartomány fogalmát nem használják, bár már támogatott az Oracle V.7.

A fent leírt MD alapuló adatbázis-technológiák alapja, a statikus információ tárolási koncepciója az adatmodellezésre koncentrálódik. Azonban a technológia alkalmazása komplex, egymással összefüggő BD tárgyak, például:

Automatizált tervezés;

Automatizált termelés;

Automatizált fejlesztés szoftver;

Irodai információs rendszerek;

Multimédia rendszer;

Földrajzi információs rendszerek;

Publishing Systems és mások, - a statikus koncepció korlátozott képességeit mutatják a valós világi tárgyak modellezésében.

Az új típusú komplex specializált adatbázis-alkalmazások esetében az információ tárolásának dinamikus koncepciója hatékony, amely lehetővé teszi az adatok és folyamatok szimulációját ezekkel az adatokkal párhuzamosan. Ez lehetővé teszi számodra, hogy vegye figyelembe a téma szemantikáját, és ezért a legmegfelelőbb leírja ezeket az alkalmazásokat. Az ilyen koncepció egy objektumorientált megközelítésen alapul, amelyet széles körben használnak szoftver létrehozásakor. MD, végrehajtási ezt a koncepciót, és amely az objektum-orientált paradigma (OOP), kapta a nevét egy objektum-orientált adatmodell (OUD).

Az OCD építése olyan feltételezésből származik, hogy a tárgyterületet az objektumkészletek írják le. Minden objektum egy olyan egyedi azonosítható entitás, amely olyan attribútumokat tartalmaz, amelyek leírják a valós tárgyak állapotát és a kapcsolódó műveleteket. Az objektum jelenlegi állapotát egy vagy több attribútum írja le, amely egyszerű vagy összetett lehet. Lehet, hogy egy egyszerű attribútum lehet primitív típus (Például egy egész szám, string stb.) És elfogadja a szó szerinti jelentést. A kompozit attribútum tartalmazhat gyűjteményeket és / vagy linkeket. A referencia-attribútum az objektumok közötti kapcsolat.

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

Az objektumazonosító (OID - objektumazonosító) belső módszer az egyes objektumok megjelölésére az adatbázishoz. Felhasználók, akik egy párbeszédpályával foglalkoznak a kérés iránti kérelmek iránti kérelmek iránti kérelmekről, vagy általában nem látják ezeket az azonosítókat. Ezek hozzárendelik és használják a DBMS-t. Az egyes DBMS-ben lévő azonosító szemantikája saját. Mindketten véletlenszerű érték lehet, és tartalmazhat olyan információkat, amelyek szükségesek ahhoz, hogy egy objektumot keressenek az adatbázis-fájlban, például a fájlban lévő oldalszám és az objektum eltolását. Ez az azonosító, amelyet a hivatkozások rendezésére kell használni az objektumra.

Minden objektum kapszulázott, azaz az objektum bemutatója vagy belső szerkezete továbbra is rejtve van a felhasználóból. Ehelyett a felhasználó csak ezt tudja ez az objektum Néhány funkciót elvégezhet. Tehát a létesítmény számára a raktár ilyen módszereket használhat az Accept_DOVAR-hoz, a kiállításhoz stb. A kapszulázás előnye, hogy lehetővé teszi, hogy az objektumok belső ábrázolását megváltoztathatja anélkül, hogy újrahasznosított alkalmazások, amelyekben ezeket az objektumokat használják. Más szavakkal, a kapszulázás az adatfüggetlenséget jelenti.

Az objektum adatokat és funkciókat kap (OOP szerint). A módszerek meghatározzák az objektum viselkedését. Használhatók az objektum állapotának megváltoztatására az attribútumok értékeinek megváltoztatásával, vagy lekérdezések létrehozása a kedvenc attribútumok értékeihez. Például, lehet, hogy módszereket adunk információt egy új ingatlan objektum bérlet, frissítse az információkat a munkavállaló fizetésének vagy nyomtatására információt egy adott terméket.

Olyan objektumok, amelyek azonos tulajdonságokkal rendelkeznek, és ugyanazok az üzenetekre válaszolhatnak osztály (A szakirodalomban az "osztály" és "típus" kifejezés gyakran szinonimaként használatos). Minden ilyen osztálynak saját képviselője - egy olyan tárgy, amely adatelem. Néhány osztály tárgyát nevezik másolatok.

Egyes objektumorientált rendszerekben az osztály is tárgy, és saját tulajdonságai és módszerei vannak osztály attribútumok és osztály módszerek.

Az OOP kiszolgálásának fontos fogalma az osztályok és a konténerek hierarchiájának hierarchiája.

Hierarchia osztályok Ez magában foglalja az egyes osztályok jelenlétét, ebben az esetben a szuperklasszát, alosztályát. Például a következő láncot hozhatjuk meg: minden vállalkozás minden programozója az alkalmazottai, ezért minden olyan programozó, aki az OCD keretén belül a programozók osztálya, szintén olyan alkalmazott, aki viszont egy objektum az osztály alkalmazottai. Így a programozók alosztályok, alkalmazottak - egy szuperklasszávak. De a programozók is megoszthatják a rendszert és alkalmazzák. Következésképpen a programozók szuperklasszák lesznek a SIS_Programs és a global_programok alosztályaihoz. Továbbra is tovább folytatjuk ezt a láncot, az osztályok hierarchiáját kapjuk, amelyben minden alosztály objektum örökli a megfelelő Superclass változók másolatát és módszereit.

Számos örökség van - egyetlen, többszörös és szelektív. Az egyedülálló öröklés olyan eset, amikor az alosztályok nem egynél több szuperklasszát örökölnek. Többszörös öröklés - örökség több mint egy szuperklasszát. A szelektív öröklés lehetővé teszi az alosztály számára, hogy a szuperklasszának korlátozott számú tulajdonságait örökölje.

A változók másolatának örökségét hívják strukturális öröklés, Öröklési módszerek - viselkedési öröklés, és ugyanazt a módszert használni különböző osztályok vagy inkább alkalmazni egyéb módszerek ugyanazzal a névvel hívják a különböző osztályokat polimorfizmus.

Az objektumorientált architektúra egy másik típusú hierarchia is van - hierarchia konténerek. Ez az, hogy néhány tárgy konstruktív lehet másokon belül. Így az osztály objektumnak tartalmaznia kell egy nyilvánosan elérhető változóat, amely hivatkozik az osztályvezetőnek, amely megfelel az osztály vezetőjének, és tartalmaznia kell egy kapcsolatot a hivatkozások halmazára olyan tárgyakra, amelyek alkalmasak a munkavállalók számára ebben az osztályban .

Bizonyos objektumorientált rendszerekben az osztály is tárgy, és saját tulajdonságai és módszerei vannak. Általános jellemzők Az osztályt attribútumai jellemzik. Az objektumosztály módszerei a valós világi tárgyak tulajdonságainak egyfajta analógja. Minden egyes osztályhoz kapcsolódó objektumoknak ezek a tulajdonságok vannak. Következésképpen, egy objektum létrehozásakor meg kell állapítani az osztályt, amelyre utal, hogy meghatározza az abban rejlő tulajdonságokat.

A felhasználó és az objektum az üzenetek segítségével kölcsönhatásba lép. Minden üzenetre válaszul a rendszer elvégzi a megfelelő módszert.

Az objektummodell összes kommunikációját olyan referencia-attribútumokkal végzik, amelyeket általában OID-azonosítóként hajtanak végre.

A relációs adatbázisokban való kommunikáció az elsődleges és a külső kulcsok összehasonlításával történik. Az adatbázisban önmagában nincsenek olyan struktúrák, amelyek a táblázatok közötti társulások kialakulásához vannak szükség, a táblák összekapcsolásakor szükség esetén a kommunikációt használják. Éppen ellenkezőleg, a kommunikáció alkotja az objektumorientált adatbázis alapját, mivel az objektumok azonosításai, amelyekkel az egyes objektumokhoz kapcsolódik.

Nem csak a hagyományos kapcsolatok megvalósíthatók az OUMD-ben, hanem az öröklés miatt is.

Kommunikációs típus egy-egy (1: 1)az A és B objektumok között a hivatkozási attribútum egy objektumhoz való hozzáadásával egy objektumhoz és (a referencia-integritás fenntartásához) az A objektumban lévő objektumhoz tartozó objektumhoz való.

Kommunikáció típusa egy-sok (1: M) Az A és B objektumok között egy olyan objektumhoz való hivatkozási attribútum hozzáadásával valósul meg, és egy olyan attribútumot tartalmaz, amely egy objektumra vonatkozó hivatkozásokat tartalmaz, egy objektumhoz (például egy B referencia-attribútum B (OID2, OID3 ...) Hozzáadva, és az OID2, OID3, ... egy OID3, ... A Referencia attribútum: OID1 hozzáadódik.

Kommunikáció, mint sok-társ sok (M: N) Az A és B objektumok között az attribútum hozzáadásával valósítható meg, amely egy linket tartalmazó objektumhoz van.

A ud, használhatja az "egész" nézet csatlakoztatását, amely leírja, hogy az azonos osztály tárgya más osztályok objektumait alkatrészként tartalmazza. Az osztály, a termék és az osztályok közötti termelési adatbázis esetében a rész és a szerelés létezett volna az "egész szám". Ez a közlemény - Ez a lehetőség a "sok Ko-Sok" kommunikáció, amely különleges szemantikával rendelkezik. A "The Integer" kommunikáció bármely más "sok-sok-sok" kommunikációként valósul meg a kapcsolódó objektumok különböző azonosítójával. Azonban, ellentétben a "sok-ko-sok" szokásos kommunikációval ellentétben, más értelmes jelentése.

Mivel az objektum-orientált paradigma támogatja az örökséget, majd az OGN-ben, lehetséges, hogy az "IS" típus és a "kibővítés" kapcsolatát használhatja. A "IS" kommunikáció, amelyet az általánosítás-specializációnak is neveznek, az öröklés hierarchiáját generálja, amelyben az alosztályokat speciális szuperklasszák esetei nyújtják. Ez lehetővé teszi, hogy ne írja le újra örökölt funkciókat. A "kibővít" kommunikáció használatakor az alosztály a SuperClass funkcionalitását fejleszti, és nem kizárólag a magánügye.

Fontolja meg, hogy az ilyen összetevőket végre Oud korlátozásaként integritás és az adatok műveleteket.

Az összetevők jellemzőit a modell sajátosságai határozzák meg. Az OMD-ben szereplő specifitás elsősorban a belső koncepciói, mint az objektumok kapszulázása, azaz a belső struktúra biztonsága, az adat-hozzáférés csak bizonyos előzetes módszerekkel, az osztályok és a tartály hierarchiájának hierarchiájával.

Az OCOM sajátosságait az objektum sajátosságai diktálják. Ez nyilvánul meg az osztályok csoportjainak csoportosításához. Minden objektumot egy adott osztályba foglalja a feladattól függően, egy objektum egyszerre több osztályba (például a programozók családja és a nagy fizetendő). Egy másik konkrét objektum az, hogy "ki tud lépni" egy osztályból (alosztály) a másikra. Tehát a rendszer programozó idővel alkalmazható. Így az osztályok hierarchiája nem a hierarchikus modell analógja, hiszen korábban úgy tűnhet, de megköveteli, hogy képes legyen megváltoztatni az egyes objektumok helyét az osztályok hierarchiáján belül, például a "fel" vagy "lefelé történő navigáláshoz "Ebben a hierarchiában. De egy összetettebb folyamat lehetséges - a rendszernek bármikor meg kell adnia a hierarchia tetszőleges csúcsát a hierarchia tetszőleges csúcsára.

Fontos szerepet játszik a kapcsolatok integritásának korlátozásaiban. Annak érdekében, hogy az objektum-orientált MD-nek dolgozzon, a kommunikáció mindkét oldalán lévő objektumazonosítóknak meg kell felelniük egymásnak. Ha például a munkavállalók és gyermekeik közötti kapcsolat van, akkor valamilyen jótállásnak kell lennie, hogy egy objektum behelyezése, amely leírja a gyereket egy olyan objektumba, amely megjeleníti a munkavállalót, az utóbbi azonosító hozzáadódik a megfelelő objektumhoz. Ez a fajta kapcsolat integritás, valami hasonló referencia integritás a relációs adatmodellben van beállítva fordított kötések. A linkek integritásának garantálása érdekében a tervező speciális szintaxis kialakítással van ellátva, amely szükséges az objektum fordított azonosítójának helyének meghatározásához. A kapcsolatok integritásának korlátozására vonatkozó kötelezettség (valamint a relációs adatbázisban szereplő referencia-integritás) a tervezőben fekszik.

Az OMD-ben és az adatleírásban, és manipulálják őket ugyanazzal az objektumorientált eljárási nyelvvel.

Objektum adatbáziskezelés roncsoló (objektum adatbázis-kezelő rács). Kidolgozta az objektummodellt (az ODMG 2.0 verziója 1997 szeptemberében), amely meghatározza a BD objektumok szemantikájának szabványos modelljét. Ez a modell nagy jelentőséggel bír, mivel meghatározza a beépített szemantikát, amelyet szintén értünk, és megvalósíthatják az objektumorientált DBMS-t (Oosubd). A könyvtárak és alkalmazások szerkezetét a szemantikával át kell adni a különböző OOSOBDS-re, amelyek támogatják ezt az objektumot MD. Az ODMG architektúra fő összetevői: objektummodell (OM), objektum definíciós nyelv (ODL), objektum lekérdezési nyelv (OQL) és C ++, Java és a Smallalk kötési képesség.

Az adatok objektummodellét az ODMG 2.0 szabványnak megfelelően az alábbi tulajdonságok jellemzik:

Az alapvető szerkezeti elemek tárgyak és literálok. Minden objektumnak egyedi azonosítója van. A literal nem rendelkezik saját azonosítóval, és nem létezhet külön, mint objektumként. A literálok mindig tárgyakba vannak építve, és nem hivatkozhatnak egyedileg;

Az objektumok és a literálok különböző típusúak. Minden típusnak saját domainje van elválasztva az ilyen típusú objektumok és literálok. A típusok viselkedhetnek is. Ha a típusnak van valamilyen viselkedése, akkor az ilyen típusú objektum ugyanaz a viselkedés. A gyakorlatban a típus lehet olyan osztály, amelyből objektum, interfész vagy egyszerű adat (például egész szám) létrejön. Az objektumot a típus példányaként lehet ábrázolni;

Az objektum állapotát a különböző tulajdonságok által végrehajtott aktuális értékek határozzák meg. Ezek a tulajdonságok lehetnek egy objektum vagy egy objektum és egy vagy több másik objektum közötti tárgy jellemzői;

Az objektum viselkedését olyan műveletek halmaza határozza meg, amelyeket az objektum vagy az objektum felett lehet elvégezni. A műveletek a bemeneti és kimeneti paraméterek listáját tartalmazhatják, mindegyik szigorúan meghatározott típusú. Minden egyes művelet is beírható eredményt is visszaadhat;

Az adatbázis definíciója az objektum definíciós nyelvén (ODL) objektum definíció nyelvén rögzített sémában tárolódik. Az adatbázis objektumokat tárol, amelyek lehetővé teszik számukra, hogy megoszthassák őket különböző felhasználók és alkalmazások megosztásához.

Az OGD-n alapuló DBMS-t objektumorientált DBMS (Oosubd) nevezik. Ezek a DBMS a harmadik generáció DBM-jére vonatkozik * (* A tárolási modellek fejlődésének története gyakran három szakaszba kerül (generáció): az első generáció (1960 vége a 70-es évek eleje) - hierarchikus és hálózati modellek; második generáció (kb. 1970-1980) - relációs modell; harmadik generáció (1980-as évek - 2000-es évek elején) - objektumorientált modellek.).

Ma az objektumorientált adatbázisokat különböző szervezetekben alkalmazzák széles kör Feladatok. A felhalmozott tapasztalatok elemzése és általánosítása az információs technológiai adatok területén lehetővé tette azokat az alkalmazások azonosítását, amelyekben az objektumorientált adatbázisok használata indokolt:

Az alkalmazás áll nagy szám kölcsönhatásban lévő részek. Mindegyiküknek van viselkedése, amely mások viselkedésétől függ;

A rendszernek nagymértékben befolyásolnia kell a strukturálatlan vagy összetett adatstruktúrát;

Az alkalmazás kiszámítható adat-hozzáférést végez, így az objektumorientált adatbázis navigációs jellege nem lesz jelentős hátránya;

A nem tervezett kérelmek szükségessége korlátozott;

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

BAN BEN jelenleg Sok objektumorientált DBMS van a szoftverpiacon. A lapon. 10.6 Az osztály kereskedelmi rendszerei közül néhányat bemutatunk.

10.6. Táblázat.

Modern kereskedelmi Oosubd,

gyártók és hatókörük

A relációs objektum-adatbázisok egyik alapvető különbsége az új adattípusok létrehozásának és használatának képessége. Az Oosubd fontos jellemzője, hogy az új típus létrehozása nem igényel adatbázis alapmódosítását, és az objektumorientált programozás elvein alapul.

Az Oosubd magja objektumokkal végzett műveletekre optimalizált. Természetes műveletek az objektumok gyorsítótárazása, tárgyak elvégzése, a hozzáférési jogok szétválasztása az egyes objektumokhoz. Az Oosubd nagyobb sebességgel rendelkezik olyan műveletekre, amelyek a relációs DBMS-ekkel összehasonlítva hozzáférést és adatokat igényelnek, amelyekhez a kapcsolódó adatok mintavételének szükségessége további belső műveletekhez vezet.

Az Oosubd számára jelentős érték képes objektumokat mozgatni egy bázisról a másikra.

Az Oosubd alapú alkalmazások létrehozásakor az egyik vagy egy másik DBMS osztályú beépített szerkezete épül. Az osztálykönyvtár általában nem csak az összes standard adattípust támogatja, hanem egy kiterjesztett multimédiás és egyéb összetett adattípusokat, például videót, hangot, az animációs keretek sorrendjét. Néhány Oosubd-ban az osztálykönyvtárak létrehozása, lehetővé téve a tárolási és teljes szöveges keresést dokumentumfilmek (például Jasmine, Odb-Jupiter). Az osztályok alapszerkezetének példája az 1. ábrán látható. 10.17.

A fő pozíciója a Todbobject osztályban foglalja el, amely tartalmazza az összes szükséges tulajdonságot és módszert az adatbázishoz és az indexeléshez való hozzáférés ellenőrzéséhez. Minden más osztály felülírja a módszereit úgy, hogy hozzáadja az általuk végrehajtott típus helyességének helyességét és a konkrét indexert.

Amint az az 1. ábrán látható. 10.17, A szerkezetben különböző osztályok vannak a dokumentációs információk feldolgozására - TodbyText, Todbdocument, TodbtextDocument stb. Ez biztosítja a dokumentumok természetes tárolását. Az egyik legfontosabb művelet, hogy kérésre dokumentumokat keressen. A legtöbb osztály esetében az objektumok keresésére történő megkeresése egy adott kulcs értékével történik. A TodbyText osztályhoz a kialakítás lehetősége megvalósul keresési lekérdezés A természetes nyelven írt kifejezés.

A Todbdocument osztály egy különleges, képes a differenciálobozok befogadására. Ez mezőkből áll, amelyek mindegyike egy bizonyos típusú objektummal rendelkezik. Ennek az osztálynak a jelenléte megadja a felhasználót, hogy bővítse a típuskészletet. A konténerobjektum (dokumentum) módosítása (dokumentum) beállíthat egy bizonyos mezőt, és új dokumentumtípust kaphat.

Az ODB-Jupiter alapján az Oosubd fejlesztői létrehozták a teljes funkcionalitású ODB-szöveges információforrás-rendszert, amely birtokában van univerzális szerkezet tárolt adatok és erőteljes keresési mechanizmus. Az ODB-szöveges rendszer a dokumentumok kollektív feldolgozása és a vállalati archívum fenntartása. A lehetséges alkalmazások között a modern iroda dokumentumkezelésének elszámolásának automatizálását fogja hívni információs rendszerek (hasonlóan a jól ismert jogi adatbázisokhoz), a hálózati adatbázisok fenntartása, a személyzet nyilvántartása, a bibliográfia stb.

41. Az alkalmazott IP tervezése. IP fejlesztési fázisok. (11. téma, 100-103.

11.1.3. Az alkalmazott rendszertervezés jellemzői

Az információs rendszer épületének (kiválasztása, adaptációja) két alapvető koncepciót használhat, két fő megközelítés (harmadik koncepció - kombinációja):

1. Az információs rendszer segítségével megoldandó problémákra való irányítás, azaz azaz Problémaorientált megközelítés (vagy induktív megközelítés);

2. A rendszerben rendelkezésre álló (frissítve) tájékozódása ebben a rendszerben, a közegben, azaz azaz. Technikailag orientált megközelítés (vagy deduktív megközelítés).

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

Ha a meglévő technológia lehetőségeit először tanulmányozzák, és az utána meghatározzák tényleges problémákamely segít a segítségükkel, akkor szükség van egy technikailag orientált megközelítésre.

Ha először a jelenlegi problémákat határozzák meg, akkor a technológia elegendő ahhoz, hogy megoldja ezeket a problémákat, szükség van egy problémaorientált megközelítésre.

Ugyanakkor mindkét fogalmának az információs rendszer kiépítésének koncepciója függ egymástól: Az új technológiák bevezetése megváltoztatja a megoldható problémákat, és megváltoztatja a megoldott problémákat - az új technológiák bevezetésének szükségességét eredményezi; Mindkettőt a döntések befolyásolják.

A rendszertervezés (fejlesztés) és bármely alkalmazás (vállalati) információs rendszerének használata az információs rendszer következő életciklusát kell adnia:

- Project elemzés (tapasztalat más hasonló rendszerek, prototípusok, különbségek és jellemzők létrehozásában, stb.), A rendszer külső megnyilvánulásainak elemzése;

- intrasztisztémaelemzés, belső elemzés (a rendszer alrendszerek elemzése);

- szisztémás (morfológiai) leírás (prezentáció) a rendszer (leírás a rendszer cél, kapcsolatrendszerek és a környezeti viszonyok, más rendszerek és rendszer erőforrásait - anyag, energia, információ, szervezési, humán, térbeli és ideiglenes);

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

- a rendszer alrendszereinek funkcionális leírása (modellek leírása, működőképes algoritmusok alrendszerek);

- Maketling (smink leírása) a rendszer értékelése a kölcsönhatás a rendszer alrendszerei (Fejlesztés az elrendezés - végrehajtásának alrendszerek egyszerűsített funkcionális leírások, eljárások, és a tesztelés a kölcsönhatás ezen elrendezések teljesítése érdekében a rendszer célja ), Lehetőség van a megfelelőség, a fenntarthatóság, a hatékonyság "elrendezések" használatára;

- "Közgyűlés" és a rendszer tesztelése - a teljes funkcionális alrendszerek és kritériumok végrehajtása, a modell értékelése a megfogalmazott kritériumok szerint;

- Rendszer működése;

- a rendszer további fejlesztésének céljainak meghatározása és alkalmazásai;

- A rendszer támogatása - pontosítás, módosítás, a rendszer lehetőségeinek bővítése működési módjában (annak kialakítása érdekében).

Ezek a szakaszok az információs reengineering rendszerek alapvető rendszerei.

A vállalati információs rendszer fejlesztése általában egy teljesen meghatározott vállalkozás számára történik. A vállalat tárgyaktivitásának jellemzői minden bizonnyal befolyásolják az információs rendszer szerkezetét. De ugyanakkor a különböző vállalkozások struktúrái általában hasonlóak egymáshoz. Minden szervezet tevékenységétől függetlenül számos olyan részből áll, amelyek közvetlenül a vállalat egyik vagy más típusú tevékenységét végzik. És ez a helyzet szinte minden szervezetre érvényes, függetlenül attól, hogy milyen tevékenységet folytat.

Így bármely szervezetnek tekinthető kölcsönhatásba lépő elemek (egységek), amelyek mindegyike saját, meglehetősen bonyolult, struktúrával rendelkezik. A divíziók közötti kapcsolat is meglehetősen összetett. Az általános esetben háromféle linket lehet megkülönböztetni a vállalati divíziók között:

Funkcionális kapcsolatok - Minden egység bizonyos típusú munkát végez egyetlen üzleti folyamat részeként;

Információs kapcsolatok - Divisions Exchange információ (dokumentumok, faxok, írásbeli és szóbeli megrendelések stb.);

Külső kommunikáció, egyes részlegek kölcsönhatásba lépnek külső rendszerekRáadásul az interakció az információs és funkcionális is lehet.

A különböző vállalkozások általános szerkezete lehetővé teszi a vállalati információs rendszerek építéséhez szükséges egységes elveket.

Általában az információs rendszer kidolgozásának folyamata két szempontból tekinthető meg:

Időben, vagy szakaszokban Életciklus Fejlett rendszer. Ebben az esetben figyelembe veszik a ciklusok, szakaszok, iterációk és szakaszok tekintetében leírt fejlesztési folyamat dinamikus szervezését.

A vállalkozás információs rendszerét egyes projektként fejlesztették ki. A projektmenedzsment és a projektfejlesztés (életciklus fázisai) számos jellemzője általános, nemcsak a téma területétől független, hanem a projekt jellegére is (nem számít, a mérnöki projekt vagy gazdasági). Ezért értelme van az elején, hogy fontolja meg a számot Általános kérdések Projektmenedzsment.

A projekt az eredetileg jól meghatározott célkitűzésekkel rendelkező különálló rendszer cél-korlátozott változás, amelynek eredménye meghatározza a projekt befejezését, valamint megállapított követelmények A mai napig, az eredmények, a kockázat, a pénzeszközök és az erőforrások és a szervezeti struktúra.

Általában egy komplex koncepció (amely különösen a projekt fogalmát) nehéz nehéz adni egy egyértelmű megfogalmazás, amely teljes mértékben lefedi a koncepció ötletének összes jelét. Ezért a fenti definíció nem igényel egyediségét és teljességét.

A projekt következő fő megkülönböztető jellemzői, mint a menedzsment tárgyaként megkülönböztethetők:

A rendszer változékonysága - a rendszer célzott fordítása néhány

a projekt céljainak tekintetében leírt kívánt állapot;

Korlátozott végső cél;

Korlátozott időtartam;

Költségvetési korlátozások;

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

Újdonság a vállalkozás számára, amelyre a projektet végrehajtják;

A komplexitás számos tényező jelenléte, közvetlenül vagy közvetve befolyásolja a projekt előrehaladását és eredményeit;

A jogi és szervezeti ellátás egy konkrét szervezeti struktúra létrehozása a projekt végrehajtásának időpontjában.

A munka hatékonyságát a projekt végrehajtási folyamatának kezelésével érik el, amely biztosítja az erőforrások forgalmazását, koordinálja a munka sorrendjét és a belső és külső zavaró hatások kompenzációját.

A szempontból az elmélet ellenőrző rendszerek, a projekt, mint egy tárgy irányítási be kell tartani és kezelhető, azaz néhány jellemzőjét osztottak folyamatosan figyelemmel kíséri a projekt előrehaladásáról (megfigyelhetőségi tulajdonság). Ezenkívül szükség van a projekt előrehaladásáról szóló, a projekt előrehaladásáról szóló mechanizmusok (kezelhetőség tulajdonsága).

A kezelhetőségi tulajdonság különösen fontos a téma bizonytalanságának és változékonyságának ellenére, amely gyakran az információs rendszerek kidolgozására irányuló projekteket kísér.

Mindegyik projekt, függetlenül attól, hogy a végrehajtáshoz szükséges összetettségét és hatókörétől függetlenül bizonyos államok fejlődésében: az államtól, amikor a projekt még nem, "az államnak, amikor a projekt már nem. A fejlesztési lépések kombinációja az ötlet kialakulásából a projekt teljes befejezéséhez a fázisok (szakaszok, szakaszok) megosztására szolgál.

A fázisok számának és tartalmának meghatározásakor vannak különbségek, mivel ezek a jellemzők nagymértékben függnek a konkrét projekt végrehajtásának feltételeitől és a fő résztvevők tapasztalatától. Mindazonáltal az információs rendszer fejlesztési folyamatának logikája és fő tartalma szinte minden esetben közös.

Az információs rendszerfejlesztés következő fázisai megkülönböztethetők:

A koncepció kialakítása;

Műszaki előírások kidolgozása;

Tervezés;

Gyártás;

A rendszer üzembe helyezése.

Tekintsük mindegyiket részletesebben. A második és részben harmadik fázisok a rendszertervezési fázisok és az utolsó kettő (néha tartalmazzák a tervezési fázist) - végrehajtási fázisokat.

Fogalmi fázis

Ötletek kialakítása, célok meghatározása;

A kulcsprojekt parancs kialakítása;

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

A forrásadatok gyűjtése és egy meglévő állam elemzése;

Az anyagi, pénzügyi és munkaerő-erőforrások által előírt alapvető követelmények és korlátozások azonosítása;

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

Képviselet, szakértelmüket és jóváhagyását.

Műszaki fejlesztésfejlesztés

A projekt fő tartalmának fejlesztése, a projekt alapszerkezete;

A technikai feladat fejlesztése és jóváhagyása;

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

A projekt becsléseinek és költségvetésének elkészítése, az erőforrások szükségességének meghatározása;

Naptár tervek kidolgozása és a kibővített munkarendek;

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

Üzembe helyezési eszközök a projekt résztvevői és az otthoni munka nyomon követése érdekében.

Tervezés

Ebben a fázisban meghatározzák az alrendszereket, kapcsolatukat választják. hatékony módszerek Projekt és erőforrás-felhasználás. A fázis jellemző munkája:

Alapvető tervezési munka elvégzése;

Magán technikai feladatok kidolgozása;

Fogalmi tervezés végrehajtása;

Műszaki előírások és utasítások kidolgozása;

A projektfejlesztés, a vizsgálat és a jóváhagyás képviselete.

Fejlődés

Ebben a fázisban a projekt munkájának koordinációját és működtetését gyártják, gyártási alrendszerek, egyesületük és tesztelésük. Központi téma:

A szoftverfejlesztési munkák végrehajtása;

A rendszer végrehajtására szolgáló előkészítés végrehajtása;

A projekt fő mutatói ellenőrzése és szabályozása.

Üzembe helyezés

Ebben a fázisban a rendszer valós körülmények között végzett vizsgálatok, kísérleti műveletek folyamatban vannak a projekt eredményeiről és az esetleges új szerződésekről. Főbb munkatípusok:

Komplex tesztek;

42. IP életciklus koncepció. (11. téma, 103-105.

Objektumorientált modell

Objektumorientált modellben az adatok bemutatása az egyes adatbázis-nyilvántartások azonosítása lehetséges. A feldolgozás felvétele és funkciói között létrejött mechanizmusok segítségével az objektumorientált programozási nyelvek megfelelő eszközeihez hasonló mechanizmusok segítségével.

A szabványosított objektum-orientált modell leírása a ODMG-93 szabvány ajánlásai (Object Database Management Group - a csoport ügyvezető objektumorientált adatbázisok).

Tekintsünk egy objektumorientált adatbázis egyszerűsített modelljét. Az objektumorientált adatbázis struktúrája grafikusan ábrázolja egy olyan fa formájában, amelynek csomópontjai objektumok. Az objektumok tulajdonságait a felhasználó által tervezett szabványtípus vagy típus írja le (osztályként meghatározott). Az osztálytípusú tulajdonság értéke olyan objektum, amely a megfelelő osztály példánya. Minden egyes osztály példány objektum olyan objektum leszármazottja, amelyben ingatlanként van meghatározva. Az objektum-példány objektum az osztályához tartozik, és van egy szülője. Az adatbázisban lévő általános kapcsolatok koherens hierarchiát alkotnak. Az objektum-orientált könyvtár adatbázis logikai szerkezetének példáját mutatja az 1. ábrán. 2.9. Itt a könyvtár típusú objektum egy szülői az objektum példány objektumok számára. Előfizető, könyvtár és kibocsátás. Különböző tárgyak, mint például egy könyv lehet egy vagy különböző szülő. Olyan objektumok, mint például egy olyan könyv, amely ugyanazzal a szülővel rendelkezik, legalább a leltárszámmal (egyedülálló a könyv minden egyes példányához), de ugyanaz az ISBN, UDC tulajdonságok, név és szerző.

Az objektum-orientált adatbázis logikai szerkezete Külsőleg hasonló a hierarchikus adatbázis szerkezetéhez. A legfontosabb különbség az adatkezelési módszerekből áll.

A művelet végrehajtásához adatok az adatbázisban modell megfontolás alatt, logikai műveletek használják, növeli az objektum-orientált mechanizmusokat tokozás, az öröklés és a polimorfizmus.

A kapszulázás korlátozza a tulajdonságok nevét az objektumon belül, amelyben meghatározták. Tehát, ha egy objektumtípus katalógus objektum, kéri a szerző szerzőjét a könyv, és telefonneve, akkor megkapjuk az azonos nevű tulajdonságait az előfizető és a katalógus. Ennek a tulajdonságnak a jelentését az objektum határozza meg, amelyben kapszulázott.

Az öröklés, éppen ellenkezőleg, az ingatlan hatókörét az objektum minden leszármazottain terjeszti. Tehát minden olyan tárgy, mint a könyv, amely az objektumtípus-objektum leszármazottai, a szülői objektum tulajdonságai tulajdoníthatók: ISBN, UDC, név és szerző. Ha szükség van, hogy bővítse a hatását a mechanizmus öröklési tárgyak, amelyek nem közvetlen rokonok (például két leszármazottai az egyik szülő), majd az általános őse az absztrakt típusú ABS típusú határozzuk meg. Tehát a jegy absztrakt tulajdonságainak meghatározása és a könyvtár objektumának számának meghatározása az összes előfizető, az Előfizető, a Könyv és a kibocsátás ezen ingatlanok örökségéhez vezet. Nem véletlen, hogy az osztályjegy-előfizető tulajdonának és az 1. ábrán bemutatott kibocsátás értékei. 2.9 ugyanaz - 00015.

A polimorfizmus az objektumorientált programozási nyelvekben ugyanazon programkód azon képességét jelenti, hogy többutas adatokkal dolgozzon. Más szóval, ez azt jelenti, hogy a különböző típusú objektumok megengedhetősége, hogy módszerei (eljárások vagy funkciók) azonos nevekkel rendelkezzenek. Az objektum program végrehajtása során ugyanazokat a módszereket működtetik különböző objektumokkal az argumentum típusától függően. A vizsgált példa tekintetében a polimorfizmus azt jelenti, hogy az osztálykatalógus különböző szülőkkel rendelkező osztályú objektumok eltérő tulajdonságokkal rendelkezhetnek. Következésképpen az osztály tárgyakkal rendelkező munkaprogramok polimorf kódot tartalmazhatnak.

Az objektum-orientált adatbázis keresése a felhasználó közötti hasonlóság meghatározása, valamint az adatbázisban tárolt objektumok.

Ábra. 2.9 Logikai könyvtári adatbázis-struktúra

Az objektum-orientált adatmodell fő előnye a relációs rendszerhez képest az objektumok összetett kapcsolataival kapcsolatos információk megjelenítése. Az objektum-orientált adatmodell lehetővé teszi egy külön adatbázis-bejegyzés azonosítását, és meghatározza a feldolgozásuk funkcióit.

Az objektumorientált modell hátrányai a magas koncepcionális komplexitás, az adatfeldolgozás kényelmetlensége és a lekérdezések alacsony fordulatszáma.

Az objektumorientált DBMS magában foglalja a költőt, a jázmin, a Versant, az O2, az Odb-Jupiter, az Iris, Orion, Postgres.

Az adatbankokat egész számként, általában gazdasági és jogi alapok minősítik.

A szolgáltatásnyújtás feltételei szerint a szabad és fizetett bankok megkülönböztetik, ami viszont kereskedelmi és nonprofit (tudományos, könyvtár vagy társadalmilag jelentős).

A tulajdonjog formájában a Bnds állami és nem állami. A hozzáférhetőség mértéke szerint nyilvánosan elérhető és korlátozott tartományok vannak.

Más típusú besorolási típusok kapcsolódnak külön BND alkatrészekkel.

1. Az adatbankok fejlesztése 4 szakaszból áll:

1. szakasz. Rendszerkövetelmények kialakítása és elemzése:

A rendszerleírás összeállítja, amely magában foglalja a BND-nek megfelelő feladatok listáját;

A végfelhasználók listája és funkciói;

Az adatbázis-követelmények listája;

Dokumentumáramkör-áramkör a szervezetben készül.

2. szakasz. Koncepcionális tervezés: A rendszerinformációs modell a számítógép típusához és a rendszer szoftver típusához való kötődés nélkül hozható létre; Az adatbázis infológiai modellje épül, amely a leginkább leírja a téma területét a felhasználó feltételeiben.

3 szakasz. Végrehajtás tervezése: A számítástechnikai rendszer van kiválasztva, rendszer szoftver és DBMS; Az adatok szerkezete úgy van kialakítva, és a adatnaplója modell az adatbázis (DB séma) épül, amely egy leírás a logikai felépítése az adatbázist a nyelv az adott kiválasztott DBMS.

4 szakasz. A fizikai megvalósítás, amely magában foglalja az adatbázisban az adatbázisban való munkavégzési programok fejlesztését és letöltését az adatbázisban, írásban. Ebben a szakaszban a BD fizikai modellje épül, amely leírja a használt tárolóeszközöket, az adatok fizikai szervezésének módszereit. Az adatbázis fizikai struktúrájának leírását tárolási rendszernek nevezik. Jelenleg hajlamos csökkenteni az ilyen típusú munkát.

2. Az adatbank személyzet által megoldott fő feladatok

A BND személyzetének személyzete különböző szakembereket tartalmaz: Rendszergazdák BND, rendszerelemzők, rendszer- és alkalmazási programozók, operátorok, szakemberek technikai eszközök, Marketing, stb

A személyzet által megoldott főbb funkciókat és feladatokat soroljuk fel, amikor az adatbázis fejlesztése és kezelése során:

1) A téma területének elemzése (a végfelhasználók igényeinek meghatározása, a téma területének információs modellje, az integritási korlátozások azonosítása);

2) Adatbázis-szerkezet kialakítása (az adatbázis-fájlok összetételének és szerkezetének meghatározása, az adatleírás nyelvének leírása);

3) az adatbázis integritásának korlátozásainak meghatározása;

4) Az adatbázis betöltése és karbantartása (az adatbázist a bejegyzések törlése, törlése és hozzáadása); A letöltési és karbantartási technológia fejlesztése; adatbeviteli formák kidolgozása; az adatok bevitele és ellenőrzése;

5) adatvédelem (a felhasználók elhatárolása, védelmi eszközök kiválasztása és ellenőrzése, jogosulatlan hozzáférés kísérleteinek rögzítése);

6) az adatbázis helyreállításának biztosítása;

7) A BND hatékonyságának és a rendszer fejlődésének elemzése;

8) munka a felhasználókkal (válaszok gyűjteménye, képzés);

9) a rendszer szoftverének támogatása (beszerzés, telepítés és fejlesztés);

10) Szervezeti és módszertani munka (a tervezés és korszerűsítés módszereinek megválasztása, a BND fejlesztésének tervezése, dokumentáció fejlesztése).

3. Adatbankok felhasználói

Mint bármely program, szervezeti és technikai komplexum, az adatbank időben és térben létezik. A fejlesztés bizonyos szakaszai vannak:

Tervezés,

Végrehajtás,

Támogatás,

Frissítés és fejlesztés,

Teljes átszervezés.

A létezés minden szakaszában a fogyasztók különböző kategóriái vannak az adatbankhoz.

Végfelhasználó

Ez az a legfontosabb kategória a felhasználóknak, akiknek érdeke van az adatbankhoz. A létrehozott adatok jellemzőitől függően az adatok lényegében eltérhetnek a végfelhasználók köré. Ezek lehetnek véletlenszerű fogyasztók, amelyek időről időre szólnak az adatbázisba az adatbázisba, miután néhány információt kaptak, és rendes felhasználók lehetnek. Az alkalmi fogyasztók a lehető legbiztonságosabb ügyfelek számára tekinthetők meg, amelyek az általánosított vagy általánosított szolgáltatások katalógusát tekintik részletes leírás. A kifejezetten tervezett programokkal dolgozó alkalmazottak, akik az akció automatizálása a funkciók elvégzésében rendes felhasználók lehetnek. Például az adminisztrátoron, aki leányvállalatot tervez számítástechnikai cég, Van olyan program, amely segít neki megtervezni és megtervezni az aktuális megrendeléseket az utasítások szerint, irányíthatja teljesítményük során, az új megrendelésekhez szükséges tartozékok egyszerűsítését. A végfelhasználókból származó fő, különleges tudás nem szükséges a nyelvi és számítástechnikai eszközök területén.

Adatkivitelezők

Ez egy olyan felhasználók csoportja, akik az adatbankfejlesztés kezdeti szakaszában felelősek az optimális eszközért a végfelhasználók egyidejű működésének szempontjából, a támogatást illetően a színpad felelős a megfelelő működésért Ez az információ információcsomagja többjátékos módban. Az átszervezés fejlesztésében és szakaszában ez a csoport felelős a köteg helyes átszervezésének lehetőségéért a jelenlegi szolgáltatás megváltoztatása vagy befejezése nélkül.

Fejlesztők és alkalmazási rendszergazdák

Ez a felhasználói csoport, amely az adatbank kialakítása, létrehozása és átszervezése során működik. Alkalmazási rendszergazdák koordinálják a fejlesztőket, hogy dolgozzanak ki konkrét alkalmazást vagy alkalmazási csoportot a funkcionális alrendszerben. Az egyes alkalmazások fejlesztői az adatbázisból származó információk részét képezik, amely egy adott alkalmazáshoz szükséges.

Nem minden adatbankban, bármilyen típusú felhasználó kiválasztható. Ismeretes, hogy az információs rendszerek fejlesztése az Adatbank DBMS adminisztrátora, az alkalmazáskezelő és a fejlesztő gyakran létezett egy személyben. Azonban, amikor modern, nehéz vállalati adatbázisokat hoz létre, amelyeket egy nagyvállalati vagy vállalati üzleti folyamatok összes vagy nagy részének automatizálására használnak, alkalmazási rendszergazdák és fejlesztők részlegei lehetnek. A legnehezebb munkamódszerek adatbázis-adminisztrátorok csoportjához vannak rendelve.

Részletesebben fontolja meg őket.

A GND adminisztrátorcsoport része:

Rendszer kommentátorok;

Az adatstruktúrák és megjelenés fejlesztői az információs támogató bank tekintetében;

Az adatfeldolgozási folyamatok feldolgozásának fejlesztői;

Rendszer és alkalmazott programozók;

Meglévő vállalatok és szakértők a javítási szolgáltatásban.

A kereskedelmi adatbank kérdése fontos szerepet játszik, értékesíti a szakértőket.

A DB Admin Group fő funkciói

1. Adatterület-tanulmány: Az adatterület leírása, az integritás korlátozásainak szövege, a státusz meghatározása (elérhetőség, titoktartás) Információ, a fogyasztói igények meghatározása, az "adat fogyasztók" meghatározása, az időbeli adatfeldolgozási jellemzők meghatározása.

2. A BD struktúra fejlesztése: az adatbázis-fájlok összetételének és szerkezetének meghatározása, az adatoptimalizálási módszerek és az információk hozzáférési módszereinek kiválasztása, adatbázis leírása az adatleírás nyelvén (Jaode).

3. Az integritás korlátozásainak beállítása az adatbázis és az adatbázis-feldolgozási eljárások szerkezetének leírásában:

Az adatterületen rejlő deklaratív integritás-korlátozások beállítása;

Az adatterületen rejlő integritás dinamikus korlátai meghatározása az adatbázisban tárolt információk változása során;

Az integritási korlátozások meghatározását az adatbázis szerkezete okozza;

Az adatbázis integritásának támogatására vonatkozó eljárások kidolgozása az adatok beírásakor és kiigazításakor;

Meghatározza a fogyasztók párhuzamos működésének integritásának korlátozását a multiplayer módban.

4. A letöltési és kézi adatbázis megkezdése

A DB betöltési technika fejlesztése, amely eltér az adatbázis módosítására és hozzáadására vonatkozó eljárásra az adatok rendszeres használatával;

Az ellenőrzéshez szükséges technikák fejlesztése Adatok, az adatterület igazi állapota. Valódi objektumok adatbázis-modellek egyes adatterületek és a közbenső korreláció, valamint a kezdet időpontjában jelenlegi javítások Ez a modellnek most meg kell egyeznie az adatterületi objektumok állapotának időben;

Az adatbeviteli rendszer kialakításának kezdeményezésének fejlett technikája szerint szükség lehet.

5. Adatvédelem

A jelszó-rendszer meghatározása, a fogyasztók felvételének elvei, a fogyasztói csoportok létrehozása, akik azonos adathozzáférési jogokkal rendelkeznek;

Egyes adatok és fejlesztési objektumok megelőzésére vonatkozó elvek kidolgozása; A helyi és globális információs hálózatok forgalomba hozatala során az információ kódolásának speciális módszereinek kidolgozása;

Az adatokhoz való hozzáférés és a védelmi rendszer megsértésének megsértésének módja;

Vizsgálati védelmi rendszer;

A védelmi rendszer megsértésének esete és dinamikus módszerek kidolgozása az adatbázisban szereplő információk megelőzésére.

6. Támogatás az adatbázis helyreállításához

A szervezeti eszközök fejlesztése archiválása és elvei az adatbázis helyreállításához;

Az adatbázis helyreállításának további érettségének és technológiai folyamatainak fejlesztése a hibák után.

7. Ügyfélhívások tanulmányozása Adatbázis: A kérelmek szimbólumainak statisztikája, a teljesítményük felvételének ideje, a szükséges kimeneti dokumentumoknak megfelelően

8. A BND működés hatékonyságának tanulmányozása:

A BND működési indexek tanulmányozása

Az adatbázis struktúrájának (strukturális változása) tervezési átalakítása és a BND átszervezése.

9. Munka a végfelhasználókkal:

Információk gyűjtése az adatterület megváltoztatásáról;

Információgyűjtés a BND munkáinak értékeléséről;

Fogyasztói képzés, konzultáció a fogyasztók;

A végfelhasználók munkájával kapcsolatos szükséges szisztematikus és oktatási dokumentáció kidolgozása.

10. Főzés és támogató rendszer berendezések:

A piaci és kutatási képességekkel meglévő érések és a BND keretén belüli használatának szükségessége;

A BND fejlesztéséhez szükséges szervezeti és műszaki program fejlesztése;

A megváltott érettség teljesítményének ellenőrzése a BND-vel való kapcsolatuk előtt;

Az új érlelések csatlakoztatása a BND-hez.

11. Szervezeti és szisztematikus munka a BND fejlesztésekor:

Adatbázisfejlesztési módszer kiválasztása vagy létrehozása;

A rendszer fejlődésének céljainak meghatározása és iránya;

A BND fejlesztésének szakaszai tervezése;

A BND projekt és a fogalmi modell általános szótárai referenciakönyvek kidolgozása;

A kifejlesztett alkalmazások külső modelljeinek telepítése;

Az új alkalmazás kapcsolatának ellenőrzése a BND-művelethez;

Az integrált hibaelhárítási beállítások lehetősége, amelyek kölcsönhatásba lépnek az egyik adatbázisból.

Egy objektumorientált modellben (OU), amikor az adatok benyújtásakor az egyes alapbejegyzések azonosítása lehetséges. Között az adatbázis bejegyzéseivel és a funkciók feldolgozása kapcsolatok kiépítésére mechanizmusok felhasználásával hasonló a megfelelő eszközöket az objektum-orientált programozási nyelvek.

Standard ou Az ODMG-93 szabványos ajánlások (objektum-adatbázis-kezelőcsoport - objektumorientált adatbázisok csoportja). Teljesen az ODMG-93 ajánlás még nem lehetséges. A kulcsfontosságú ötletek illusztrálásához vegye figyelembe az objektumorientált adatbázis kissé egyszerűsített modelljét.

Az OO DB szerkezete grafikusan ábrázolja egy olyan fa formájában, amelynek csomópontjai objektumok. Az objektum tulajdonságait néhány standard típus (például string - string) vagy egy típus írja le, amelyet a felhasználó által létrehozott (osztályként definiált).

A karakterlánc típusának értékei karakterlánc. Az osztálytípusú tulajdonság értéke olyan objektum, amely a megfelelő osztály példánya. Minden egyes osztály példány objektum olyan objektum leszármazottja, amelyben ingatlanként van meghatározva. Az objektum-példány objektum az osztályához tartozik, és van egy szülője. Az adatbázisban lévő általános kapcsolatok az objektumok hierarchiáját képezik.

Az OO DB könyvtári tok logikai szerkezetének példáját az 1. ábrán mutatjuk be. 3.14. Itt a könyvtár típusú objektum egy szülői az objektum példány objektumok számára. Előfizető, könyvtár és kibocsátás. Különböző objektumok, mint például egy olyan könyv, amely ugyanazzal a szülővel rendelkezik, legalább egy leltárszámmal (egyedülálló a könyv minden egyes példányához), de ugyanazok a tulajdonságok értékei vannak iSBN, UDC, névés szerző.

3.14.Logikai strukturális adatok gondozása

Az OO DB logikai szerkezete külső szinten hasonlít a hierarchikus adatbázis szerkezetéhez. A legfontosabb különbség az adatkezelési módszerekből áll. Ahhoz, hogy műveleteket végeznek a adatok az adatbázisban, logikai műveletek használják, megerősítve az objektum-orientált mechanizmusokat tokozás, az öröklés és a polimorfizmus. A műveletek, mint például az SQL parancsok korlátozhatók (például egy adatbázis létrehozásához).

Az adatbázis létrehozását és módosítását az automatikus képződés és az azt követő indexbeállítás (index táblák) kíséri, amely információkat tartalmaz az adatok gyors kereséséhez.

Figyelembe vesszük röviden a kapszulázás, az örökség és a polimorfizmus fogalmát az adatbázishoz képest.

Egységbezáráskorlátozza az ingatlan nevét az objektumban, amelyben meghatározták. Tehát, ha egy objektum egy katalógus objektum Add Ingatlan Ajánlja a szerző telefonkönyvét és nevét telefon,ezután megkapjuk az azonos nevű tulajdonságokat az előfizetőből és a katalógusból. Ennek a tulajdonságnak a jelentését az objektum határozza meg, amelyben kapszulázott.

Öröklés, Éppen ellenkezőleg, terjeszti az ingatlan láthatóságának területét az objektum minden leszármazottain. Tehát minden olyan tárgyat, mint egy könyv, amely a leszármazottai az objektum típusa a katalógus, tudható, hogy az ingatlan a szülő objektum: iSBN, UDC, névés szerző.Ha szükség van, hogy bővítse a hatását a mechanizmus öröklési tárgyak, amelyek nem közvetlen rokonok (például két leszármazottai az egyik szülő), majd az általános őse az absztrakt típusú ABS típusú határozzuk meg. Tehát az absztrakt tulajdonságok meghatározása jegy és számaz objektumban a könyvtár e tulajdonságok örökségét az előfizetők, az Előfizető, a Könyv és a kibocsátás biztosítja. Nem véletlenül, ezért az ingatlan értékei jegyosztályok Az előfizető és az ábrán bemutatott kibocsátás ugyanaz lesz - 00015.

Polimorfizmusaz objektumorientált programozási nyelveken ugyanazon programkód képes dolgozni a többutas adatokkal. Más szóval, ez azt jelenti, hogy a különböző típusú objektumok megengedhetősége, hogy módszerei (eljárások vagy funkciók) azonos nevekkel rendelkezzenek. Az objektum program végrehajtása során ugyanazokat a módszereket működtetik különböző objektumokkal az argumentum típusától függően. Az OO adatbázisunkat illetően a polimorfizmus azt jelenti, hogy az osztálykönyvtár különböző szülőkkel rendelkező osztályú objektumkönyv különböző tulajdonságokkal rendelkezhet. Következésképpen az osztály tárgyakkal rendelkező munkaprogramok polimorf kódot tartalmazhatnak.

Az OO BD keresése az, hogy megtudja a felhasználó által megadott objektum és az adatbázisban tárolt objektumok közötti hasonlóságot. A felhasználó által definiált objektum, az úgynevezett objektum célú (az ingatlan az objektum típus GOAL) általános esetben egy részét a teljes objektumok hierarchiáját az adatbázisban. Az objektumobjektum, valamint a lekérdezés végrehajtásának eredménye az adatbázisban tárolható. Példa az olvasó jegyekre és előfizetői nevekre, amelyek legalább egy könyvet kaptak a könyvtárban, az 1. ábrán látható. 3.15.

Alapvető méltóságEzeket az adatokat a relációs rendszerhez képest az objektumok komplex összekapcsolására vonatkozó információk megjelenítése. Ez lehetővé teszi egy külön adatbázis-bejegyzés azonosítását, és meghatározza a feldolgozásuk funkcióit.

HátrányAz OY magas koncepcionális komplexitás, az adatfeldolgozás kényelmetlensége és a lekérdezések alacsony sebessége.

3.15.Az adatbázis fragmense objektummal

Az 1. ábra szerinti relációs adatmodellként ábrázolt megrendelések feladata. 3.8, és fontolja meg az objektumorientált adatbázis szempontjából. Összesen, a három osztály példájában: " Ügyfelek», « Megrendelések"És" Termékek" Osztály " Ügyfelek»A konkrét ügyfelek; Osztály tulajdonságai - Ügyfélszám, ügyfél neve város, állapot stb. Osztály módszerek - " Hozzon létre egy megrendelést», « Számlát fizet"stb." A módszer olyan művelet, amely az objektumra alkalmazható; A módszer az, amit az objektumnak meg kell tennie. Az asztalnak megfelelő osztály " Rendelési információ", nem szükséges. A táblázatadatok lehetnek az osztály része " Megrendelések" Elérhetőség az osztályban " Ügyfelek"Módszer" Hozzon létre egy megrendelést"Az osztályok osztályaival való kölcsönhatáshoz vezet" Megrendelések"És" Termékek" Ugyanakkor a felhasználónak nem kell tudnia az objektumok interakciójáról. A felhasználó csak az objektumra szólít fel " Megrendelések"És használja a módszert" Hozzon létre egy megrendelést" Az egyéb adatbázisok kitettségének ténye elrejthető a felhasználóból. Ha a módszer " Hozzon létre egy megrendelést"Viszont a módszerre utal" Ellenőrizze az ügyfél hitelképességét"Ez a tény a felhasználóból is el van rejtve. BAN BEN relációs alapok Az adatok teljesítéséhez szükséges adatok, meg kell írni az alkalmazásokat az alkalmazáshoz (VBA).

A 90-es években az OO adatbázis-kezelő rendszerek kísérleti prototípusai léteztek. Jelenleg az ilyen rendszerek széles körben elterjedtek. Különösen, hogy az alábbi DBMS: KÖLTÖ (Poet Software), Jasmine (Computer Associates), Versant (Versant Technologies), O2 (Ardent Software), ODB-Jupiter (Inteltek Plus Tudományos és Termelési Központ), valamint IRIS, Orion és posztgres.