Objektovo orientovaný model. Objektovo orientovaný dátový model

Základné pojmy

Definícia 1.

Objektovo orientovaný modelprezentácie údajov umožňuje identifikovať jednotlivé záznamy databázy.

Databázové záznamy a spracovanie funkcie súvisia s mechanizmami podobnými vhodným prostriedkom, ktoré sú implementované v objektovo orientovaných programovacích jazykoch.

Definícia 2.

Grafické znázornenie Štruktúry objektovo orientovanej databázy je strom, ktorého uzly predstavujú objekty.

Štandardný typ (napríklad reťazec - reťazec) Alebo typ vytvorený užívateľom ( trieda), opisuje vlastnosti objektov.

Na obr. 1 je objekt knižnice materský pre adresár triedy inštancie, účastník a vydávanie. Rôzne objekty, ako napríklad kniha, môžu byť jeden alebo rôzni rodičia. V objektoch, ako je kniha, ktorá má rovnaký rodič, musí byť aspoň rôzne čísla zásob (jedinečné pre každú kópiu knihy), ale rovnaké hodnoty Vlastnosť autor, názov, udc a iSBN..

Logické štruktúry objektovo orientovanej a hierarchickej databázy sú podobné. Líšia sa v hlavných metód manipulačných údajov.

Pri vykonávaní akcie na dáta v objektovom modeli sa používajú logické operácie, ktoré sú zvýšené zapuzdrením, dedičstvom a polymorfizmom. S niektorými obmedzeniami môžete aplikovať operácie, ktoré sú podobné príkazom SQL (napríklad pri vytváraní databázy).

Pri vytváraní a modifikácii databázy sa vykonáva automatická formácia a následné nastavenie indexov (indexové tabuľky), ktoré obsahujú informácie na rýchlu vyhľadávanie údajov.

Definícia 3.

účel zapuzdrenie - Obmedzenie rozsahu názvu nehnuteľnosti hranice objektu, v ktorom je definovaný.

Napríklad, ak je majetok pridaný k objektu, ktorý nastaví telefón autora a má meno telefónVlastnosti rovnakého mena budú mať katalógové a účastnícke objekty. Význam nehnuteľnosti je určený objektom, v ktorom je zapuzdrený.

Definícia 4.

Dedičstvo, späť zapuzdrenie, je zodpovedný za distribúciu oblasti viditeľnosti majetku v porovnaní so všetkými potomkami objektu.

Napríklad všetky objekty knihy, ktoré sú potomkovi adresára objektu, možno pripísať vlastnostiam rodičovského objektu: autor, názov, udc a iSBN..

Ak je potrebné rozšíriť pôsobenie mechanizmu dedičstva pre objekty, ktoré nie sú priame príbuzné (napríklad dvaja potomkovia jedného rodiča) v ich celkovom predkovi určujú abstraktnú vlastnosť typu abs.

Vlastnosti číslo a lístok V objekte knižnice sú zdedené všetkými dcérskymi spoločnosťami, ktoré vydávajú, kniha a účastník. Preto sú hodnoty tejto vlastnosti tried účastníka a vydávania rovnaké - 00015 (obrázok 1).

Definícia 5.

Polymorfizmus Umožňuje rovnaký programový kód pracovať s viacsmernými údajmi.

Inými slovami, pripúšťa sa v objektoch odlišné typy Majú metódy (funkcie alebo postupy) s rovnakými menami.

Vyhľadávanie Objektová databáza je určiť podobnosť medzi objektom, ktorý používateľ určuje a objekty, ktoré sú uložené v databáze.

Výhody a nevýhody objektovo orientovaného modelu

Základný výhoda Objektovo orientovaný dátový model, na rozdiel od relačného modelu, je možnosť zobrazenia informácií o komplexných vzťahoch objektov. Model dátového modelu vám umožní určiť samostatný záznam databázy a funkcie spracovania.

Na nevýhody Objektovo orientovaný model patrí k vysokej koncepčnej ťažkosti, nepohodlné spracovanie údajov a nízkych dotazov.

K dnešnému dňu sú takéto systémy pomerne rozšírené. Patrí medzi ne DBMS:

Postgres,
Osi
Iris
ODBJUPITET,
Univerzálny
Objektivita / db,
Objekt
Stav
Drahokam
G-Base.

Objektovo orientovaná databáza (Obs) - databáza, v ktorej sú údaje modelované vo forme objektov, ich atribútov, metód a tried.

Objektovo orientované databázy sa zvyčajne odporúčajú pre prípady, keď sa vyžaduje vysoko výkonné spracovanie dát s komplexnou štruktúrou.

V Manifeste sa osi ponúka povinné vlastnosti, ku ktorým musí byť zodpovedný akýkoľvek OBD. Ich výber je založený na 2 kritériách: Systém musí byť orientovaný na objekt a predstavuje databázu.

Povinné charakteristiky

1. Podpora komplexných objektov. Systém by mal zabezpečiť možnosť vytvorenia kompozitných objektov aplikovaním dizajnérskych predmetov. Je potrebné, aby návrhári objektov boli ortogonálne, to znamená, že každý dizajnér by mohol byť aplikovaný na akýkoľvek predmet.

2. Podpora jednotlivých objektov. Všetky objekty musia mať jedinečný identifikátor, ktorý nezávisí od hodnôt ich atribútov.

3. Podpora zapuzdrenia. Správna enkapsulácia sa dosiahne z dôvodu, že programátori majú právo na prístup len na metódy metód, a údaje a implementácia metód sú ukryté vo vnútri objektov.

4. Typy a triedy podpory. Vyžaduje sa, že aspoň jeden koncepčný rozdiel medzi typmi a triedami je udržiavaný v OBD. (Termín "typ" viac zodpovedá koncepcii abstraktného typu údajov. V programovacích jazykoch je premenná deklarovaná s jeho typom. Kompilátor môže použiť tieto informácie na kontrolu operácií vykonaných z variabilnej kompatibility s jeho typom, ktorý vám umožní Zaručiť správnosť softvér. Na druhej strane, trieda je druh šablóny pre vytváranie objektov a poskytuje metódy, ktoré môžu byť aplikované na tieto objekty. Koncepcia "triedy" sa teda vo väčšej miere vzťahuje na čas vykonania ako časom kompilácie.)

5. Podpora dedičstva typov a tried od svojich predkov. Podtyp alebo podtrieda, musí zdediť atribúty a metódy zo svojej supertype alebo superclass, resp.

6. Preťaženie v kombinácii s úplnou väzbou. Metódy by sa mali aplikovať na objekty rôznych typov. Implementácia metódy by mala závisieť od typu objektov, na ktoré sa táto metóda aplikuje. Aby sa zabezpečila táto funkcia, väzba metód metód v systéme by sa nemali vykonávať až do času vykonávania programu.

7. Výpočtová plnosť. Jazyk manipulácie s údajmi musí byť programovací jazyk všeobecný účel.

8. Musí byť rozšíriteľný súbor typov údajov. Užívateľ musí mať prostriedky na vytvorenie nových typov údajov na základe sady preddefinovaných typov systému. Okrem toho by nemali existovať žiadne rozdiely medzi metódami používania typov systémových a užívateľských dát.

Oo dbms

Objektovo orientované databázy - Databázy, v ktorých sú informácie prezentované ako objekty ako v objektovo orientovaných programovacích jazykoch.

Aplikujte alebo nepoužijte objektovo orientované databázové systémy (OOSUBD) v reálnych projektoch? V akich prípadoch ich uplatňovanie a v čom nie?

Tu výhody Použitie USUBD:

· Neexistuje žiadny problém nekonzistentnosti dátového modelu v aplikácii a BD (nesúlad impedancie). Všetky údaje sú uložené v databáze v rovnakej forme ako v aplikačnom modeli.

· Nie je potrebné samostatne podporovať dátový model na strane DBMS.

· Všetky objekty na úrovni zdroja údajov sú prísne napísané. Neexistujú žiadne mená stĺpcov! Refaktoring objektovo orientovaná databáza a kód, ktorý pracuje s ním, je teraz automatizovaný, a nie monotónny a nudný proces.

Štandardné ODMG.

Prvý prejavformálne, bol len článok prezentovaný Konferencia o objektovo orientovaných a deduktívnych databázachskupiny jednotlivcov. Ako ste mohli vidieť v predchádzajúcom pododdiele, požiadavky zjavca boli skôr emocionálne ako jasne špecifikované. V roku 1991 bola vytvorená konzorcia ODMG (potom bola táto skratka odhalená ako Skupina databázy objektovAle následne získal širšiu interpretáciu - Skupina pre správu objektov). Konzorcium ODMG úzko súvisí s oveľa početnejším konzorciom OMG ( Objekt Management Group.), ktorý bol vytvorený o dva roky skôr. Hlavným zdrojovým cieľom ODMG bol rozvoj priemyselnej normy objektovo orientovaných databáz (všeobecný model). Ako základ bol prijatý základným modelom objektu OMG COM ( Jadrový objektový model). Viac ako desaťročie existencie ODMG zverejnila tri základné verzie Štandard, z ktorých posledný sa nazýva ODMG 3.0. šestnásť

Je to zábavné, že aj keď ODMG (podľa autora) vyšiel z OMG, v posledných rokoch niektoré OMG štandardy sú založené na modeli objektu ODMG. Špecifikácia jazyka OCL je založená na modeli ODMG ( Obmedzovací jazyk objektu.), ktorá je súčasťou celkovej špecifikácie jazyka UML 1.4 (a UML 2.0). V tomto článku nemáme cieľ vykonať podrobné porovnanie OMG a ODMG prístupov a zaslať zainteresovaných čitateľov Encyklopédia Kogalovsky a materiály týchto stránok konzorcií. Sme obmedzení na krátku prezentáciu hlavných myšlienok obsiahnutých v štandarde ODMG -3.

Architektúra ODMG.

Navrhovaná architektúra ODMG je znázornená na obr. 2.1. Táto architektúra definuje metódu ukladania dát a rôzne typy užívateľského prístupu k tomuto "dátovému skladu" 17. Jediný dátový sklad je k dispozícii v jazyku definovania údajov, jazyka dotazu a mnohých jazykov manipulácie s údajmi. 18 na obr. 2.1 ODL znamená Jazyk definície objektu (jazyk definície objektu), OQL - Jazyk objektov jazyka (jazyk jazykového dotazu)a OML - Jazyk manipulácie s objektmi (jazyk manipulácie s objektom).

Obr. 2.1. Architektúra ODMG.

Centrálna architektúra je dátový modelpredstavuje organizačnú štruktúru, v ktorej všetky údaje spravované Oosubd zostávajú. Jazyk definície objektu, jazyk dotazu a manipulačné jazyky sú navrhnuté takým spôsobom, že všetky ich schopnosti sú založené na údajovom modeli. Architektúra robí existenciu rôznych implementačných štruktúr na ukladanie simulovaných údajov, ale dôležitou požiadavkou je, že všetky knižnice softvéru a všetky podporné nástroje sú uvedené v objektovo orientovanom rámci a mali by sa udržiavať v koordinácii s údajmi.

Hlavnými zložkami architektúry sú nasledujúce.

Objektový model údajov.Všetky údaje pretrvávali Oosubd sú štruktúrované z hľadiska vzorov dátového modelu. V dátovom modeli sa určuje presná sémantika všetkých konceptov (pozri nižšie).

Jazyk definície údajov (ODL).Databázové obvody sú opísané v zmysle jazyka ODL, v ktorom sú vzory dátového modelu špecifikovaný vo forme definície jazyka. ODL vám umožňuje opísať schému ako sadu rozhraní typu objektu, ktorý zahŕňa opis vlastností typov a vzájomných vzťahov medzi nimi, ako aj mená operácií a ich parametrov. ODL nie je kompletným programovacím jazykom; Typy musia byť implementované v jednom z jazykov kategórie OML. Okrem toho, ODL je virtuálnyjazyk v tom zmysle, že norma ODMG nevyžaduje jej implementáciu v softvérových produktoch Oosubd, ktoré sa považujú za relevantné pre štandard. Podpora týchto produktov ekvivalentných definícií jazykov, vrátane všetkých schopností ODL, ale prispôsobené špecifickým funkciám systému. Avšak, prítomnosť špecifikácie jazyka ODL v norme ODMG je dôležitá, pretože vlastnosti modelu údajov sú uvedené v jazyku.

Jazyk požiadaviek objektov (ODL). Jazyk má syntax podobnú syntaxe jazyk SQLAle spolieha sa na sémantiku modelu objektu ODMG. Štandard umožňuje priame používanie OQL a zapustenie ju do jedného z jazykov kategórie OML.

Model relačného dát

Takmer všetky moderné systémy založené na relačný(Relačné) modely správy databáz. názov relačnýje to spôsobené tým, že každý záznam v takejto databáze obsahuje informácie týkajúce sa len na jeden konkrétny objekt.

V relačnýDBMS Všetky spracované údaje sú reprezentované ako ploché stoly. Informácie o objektoch špecifickej formy je prezentované v tabuľkovej forme: Rôzne atribúty objektov sú koncentrované v stĺpcoch tabuľky a struny sú navrhnuté tak, aby zahŕňali popisy všetkých atribútov na jednotlivé inštancie objektov.

Model vytvorený vo fáze infografického modelovania je väčšinou uspokojujúci princípy relačného. Aby sa však tento model na relalilačil, musí vykonať postup normalizácia.

Teória normalizácie pracuje s piatimi normálne formy. Tieto formy sú navrhnuté tak, aby znížili redundanciu informácií, preto každá nasledujúca normálna forma musí spĺňať požiadavky predchádzajúcich a niektorých ďalších podmienok. S praktickým dizajnom databáz sa zvyčajne nepoužívajú štvrtá a piata forma. Obmedzili sme sa na zváženie prvých štyroch normálnych formulárov.

Predstavujeme pojmy potrebné na pochopenie procesu privádzania modelu na relačnú schému.

Postoj- Abstrakcia opísaného objektu ako celkovosti jej vlastností. Vedenie infografického štádia dizajnu, hovorili sme o abstrakcii objektov a pripisovali im niektoré vlastnosti. Teraz, ktorý vykonáva koncepčný dizajn, prejdeme sa na ďalšiu úroveň abstrakcie. V tomto štádiu objektov ako taký už neexistuje. Pôsobíme s množstvom vlastností, ktoré definujú objekt.

Inštancia vzťahu- súbor hodnôt vlastností konkrétneho objektu.

Primárny kľúč- identifikácia množiny atribútov, t.j. Hodnota týchto atribútov je v tomto ohľade jedinečná. Neexistujú žiadne dve inštancie vzťahu obsahujúce rovnaké hodnoty v primárnom kľúči.

Jednoduchý atribút- Atribút, ktorých významy sú nedeliteľné.

Komplexný atribút- Atribút, ktorých hodnota je súbor hodnôt niekoľkých rôznych objektov vlastností alebo niekoľkých hodnôt jedného majetku.

Koncept Essence.

Doména

Koncepcia domény je konkrétnejšia pre databázy, hoci v niektorých programovacích jazykoch má niektoré analógie s podtypmi. V najobecnejšej forme je doména určená úlohou určitého základného typu údajov, na ktoré sa prvky domény a ľubovoľný logický výraz aplikovaný na položku typu údajov. Ak výpočet tohto logického výrazu dáva výsledok "pravdy", dátový prvok je prvokom domény.

Najčastejšou intuitívnou interpretáciou koncepcie domény je pochopenie domény ako prípustného potenciálneho súboru hodnôt tento typ. Napríklad doména "mená" v našom príklade je definovaný na základnom type reťazcov znakov, ale počet hodnôt môže obsahovať iba tie čiary, ktoré môžu zobrazovať názov (najmä, takéto riadky nemôžu začať mäkkou znamenia).

Treba tiež poznamenať sémantické bremeno koncepcie domény: údaje sa považujú za porovnateľné len vtedy, keď sa týkajú jednej domény. V našom príklade sa domény domény "prejdú čísla" a "skupinové číslo" odkazujú na typ celých čísel, ale nie sú porovnateľné. Všimnite si, že vo väčšine relačných DBMS sa koncepcia domény nepoužíva, hoci je už podporovaný v Oracle V.7.

Základom databázových technológií na základe vyššie uvedeného MD leží koncept statického ukladania informácií sa sústreďuje na modelovanie údajov. Nové oblasti uplatňovania technológií s komplexnými, vzájomne prepojenými BD objektov, ako napríklad:

Automatizovaný dizajn;

Automatizovaná výroba;

Automatizovaný vývoj softvér;

Informačné systémy úradu;

Multimediálny systém;

Geografické informačné systémy;

Vydavateľské systémy a iné, - preukázali obmedzené možnosti statického konceptu, pokiaľ ide o modelovanie objektov skutočného sveta.

Pre nové typy komplexných špecializovaných databázových aplikácií je dynamický koncept ukladania informácií účinný, čo vám umožňuje simulovať údaje a procesy platné paralelne s týmito údajmi. To vám umožní vziať do úvahy sémantiku predmetnej oblasti, a preto tieto aplikácie najviac opisujú. Takýto koncept je založený na objektovo orientovaným prístupom, ktoré sa široko používa pri vytváraní softvéru. MD, implementácia tejto koncepcie a založená na objektovo orientovanej paradigm (OOP), dostal názov objektovo orientovaného dátového modelu (oud).

Výstavba OCD pokračuje z predpokladu, že oblasť predmetu môže byť opísaná súborom objektov. Každý objekt je jedinečná identifikovateľná entita, ktorá obsahuje atribúty, ktoré opisujú stav reálnych objektov sveta a súvisiace akcie. Súčasný stav objektu je opísaný jedným alebo viacerými atribútmi, ktoré môžu byť jednoduché alebo zložité. Jednoduchý atribút môže mať primitívny typ (napríklad celé číslo, reťazec atď.) A prijmite doslovný význam. Kompozitný atribút môže obsahovať zbierky a / alebo odkazy. Referenčný atribút je odkazom medzi objektmi.

Kľúčovou vlastnosťou objektu je jedinečnosť jeho identifikácie. Každý objekt v objektovom systéme musí mať svoj vlastný identifikátor.

ID objektu (OID - Identifikátor objektu) je interný spôsob označovania jednotlivých objektov pre databázu. Užívatelia pracujúci s dialógovým programom žiadostí o požiadavky alebo informácie o zobrazení, spravidla nevidia tieto identifikátory. Sú priradené a použité samotné DBMS. Sémantika identifikátora v každom DBMS je ich vlastná. Môže to byť náhodná hodnota a obsahovať informácie potrebné na vyhľadávanie objektu v databázovom súbore, napríklad číslo stránky v súbore a objekt ofset od jeho štartu. Je to identifikátor, ktorý by sa mal použiť na usporiadanie odkazov na objekt.

Všetky objekty sú enkapsulované, t.j. prezentácia alebo vnútorná štruktúra objektu zostáva skrytá od užívateľa. Namiesto toho užívateľ vie len tento objekt môže vykonávať niektoré funkcie. Takže, pre zariadenie, sklad môže použiť takéto metódy na prijatie_dovar, na vydanie_tobap atď. Výhodou enkapsulácie je, že vám umožní zmeniť interné zobrazenie objektov bez prepracovania aplikácií, v ktorých sa tieto objekty používajú. Inými slovami, enkapsulácia znamená nezávislosť údajov.

Objekt zapuzdruje údaje a funkcie (metódy podľa OOP). Metódy určujú správanie objektu. Môžu byť použité na zmenu stavu objektu zmenou hodnôt jeho atribútov alebo vytvárať dotazy k hodnotám obľúbených atribútov. Napríklad, môžu existovať metódy na pridanie informácií o novom objekte nehnuteľností na prenájom, aktualizovať informácie o platovej mzde zamestnanca alebo na tlač informácií o konkrétnom produkte.

Objekty, ktoré majú rovnaký súbor atribútov a reagujú na rovnaké správy, môžu byť zoskupené trieda (V literatúre sa výraz "trieda" a "typ" často používajú ako synonymá). Každá taká trieda má svoj vlastný zástupca - objekt, ktorý je dátovým prvkom. Objekty niektorých tried sa nazývajú kópie.

V niektorých objektovo orientovaných systémoch je trieda tiež objekt a má svoje vlastné atribúty a metódy atribúty a metódy triedy.

Dôležité koncepcie OOP slúžia hierarchia tried a hierarchie kontajnerov.

Triedy hierarchie To znamená možnosť mať prítomnosť každej triedy, v tomto prípade, superclass, jeho podtrieda. Ako príklad, môžete priniesť nasledujúci reťazec: Všetci programátori akéhokoľvek podniku sú jeho zamestnanci, preto každý programátor, ktorý v rámci OCD je trieda programátorov, je to aj zamestnanec, ktorý je zase objektom zamestnancov triedy. Takto programátori budú podtrieda, zamestnanci - nadtrieda. Programátori však môžu tiež zdieľať na systém a aplikovať. Z toho vyplýva, že programátori budú nadtrieda na podokliny SIS_PROGRAMS a GLOBAL_PROGRAMERS. Pokračovať tento reťazec ďalej, dostaneme hierarchiu tried, v ktorej každá podtrieda objektívna zdedí kópie premenných a metód príslušnej superclass.

Existuje niekoľko typov dedičstva - jeden, viacnásobný a selektívny. Jednotné dedičstvo je prípad, keď podtriedy zdedia nič viac ako jednu superclass. Viacnásobné dedičstvo - dedičstvo viac ako jednu superclass. Selektívne dedičstvo umožňuje podtriedenie zdediť obmedzený počet vlastností jeho supertriezy.

Volanie sa nazýva dedičnosť kópií premenných Štrukturálne dedičstvoMetódy dedičstva - behaviorálne dedičstvoa schopnosť používať rovnakú metódu pre rôzne triedy alebo skôr platiť rôzne metódy S rovnakým názvom pre rôzne triedy sa nazýva polymorfizmus.

Objektovo orientovaná architektúra má tiež iný typ hierarchie - hierarchia kontajnery. Je to, že niektoré objekty môžu byť konštruktívne v iných. Objekt triedy by teda mal obsahovať verejne dostupnú premennú, ktorá je odkazom na zamestnancov triedy, čo zodpovedá vedúcemu oddelenia, a musí obsahovať aj odkaz na súbor odkazov na objekty, ktoré sú vhodné pre zamestnancov v tomto oddelení .

V niektorých objektovo orientovaných systémoch je trieda tiež objekt a má svoje vlastné atribúty a metódy. Všeobecné charakteristiky Trieda je opísaná svojimi atribútmi. Metódy objektov triedy sú druh analógu vlastností reálnych objektov sveta. Každý objekt týkajúci sa akejkoľvek konkrétnej triedy má tieto vlastnosti. V dôsledku toho, že pri vytváraní objektu je potrebné deklarovať triedu, na ktorú sa vzťahuje na to, aby v nej určili vlastnosti.

Používateľ a objekt komunikujú prostredníctvom správ. V reakcii na každú správu systém vykonáva príslušnú metódu.

Všetky komunikácie v modeli objektu sa vykonáva pomocou referenčných atribútov, ktoré sa zvyčajne implementujú ako identifikátory OID.

Komunikácia v relačných databázach predstavujú porovnanie primárnych a externých kľúčov. V samotnej databáze nie sú žiadne štruktúry pre tvorbu asociácií medzi tabuľkami, komunikácia sa používa podľa potreby pri pripájaní tabuliek. Naopak, komunikácia tvorí základ objektovo orientovanej databázy, pretože identifikátory objektov, s ktorými je spojená s každým objektom.

V OUMD sa môže implementovať nielen tradičné väzby, ale aj z dôvodu dedičstva.

Komunikačný typ Jedno-to-One (1: 1)medzi objektmi A a B je implementované pridaním referenčného atribútu k objektu v objekte A a (na udržanie referenčnej integrity) referenčného atribútu k objektu A v objekte V.

Komunikácia typu Jedno-to-mnoho (1: m) Medzi objektmi A a B sa implementuje pridaním referenčného atribútu na objekt A a atribút obsahujúci sadu odkazov na objekt A, na objekt (napríklad referenčný atribút B (OID2, OID3 ...) Pridané a v prípadoch objektu v OID2, OID3, ... sa pridá referenčný atribút A: OID1.

Komunikácia ako mnoho-spolu- veľa (M: N) Medzi objektmi A a B sa implementuje pridaním atribútu každému objektu obsahujúcemu súbor odkazov.

V OUD môžete použiť pripojenie "Integer" zobrazenie opisujúce, že objekt tej istej triedy obsahuje objekty iných tried ako jeho časti. V prípade výrobnej databázy medzi triedou, výrobkom a triedami by časť a zhromaždenie existovali "celé číslo". Toto oznámenie - Toto je možnosť komunikácie "Mnoho Ko-Mnoho", ktorá má špeciálnu sémantiku. Komunikácia "Integer" sa implementuje ako akákoľvek iná komunikácia "Mnohí-to-mnoho" s použitím rôznych identifikátorov súvisiacich objektov. Avšak, na rozdiel od zvyčajnej komunikácie "Mnohé-Ko-Mnohé", má iný zmysluplný význam.

Vzhľadom k tomu, že objektovo orientovaná paradigma podporuje dedičstvo, potom v oud, je možné použiť typ "je" a pripojenie "expanduje". Komunikácia "je", ktorá sa tiež nazýva vzťah všeobecného špecializácie, vytvára hierarchiu dedičstva, v ktorej sú podtriedy poskytnuté osobitnými prípadmi nadtriedy. To umožňuje opísať re-dedičné funkcie. Pri použití komunikácie "Rozšírky" podtrieda rozvíja funkčnosť nadrady a nie je obmedzená na jeho súkromný prípad.

Zvážte, ako sa takéto komponenty vykonávajú v oud ako obmedzujúce integritu a dátové operácie.

Vlastnosti týchto zložiek sú určené špecifikámi modelu. Táto špecifickosť v OMD je určená predovšetkým svojimi vnútornými koncepciami ako zapuzdrenie objektov, t.j. Bezpečnosť vnútornej štruktúry, prístup k údajom len prostredníctvom určitých vopred metódy, hierarchie tried a hierarchie kontajnerov.

Špecifikácie OCOM sú diktované špecifikámi objektu. To sa prejavuje v potrebe skupinových objektov v triedach. Každý objekt je zahrnutý v konkrétnej triede v závislosti od úlohy, s jedným objektom môže patriť naraz do niekoľkých tried (napríklad rodina programátorov a vysoká splatná). Ďalším špecifickým cieľom je, že to môže "ísť" z jednej triedy (podtriedy) do druhého. Takže systémový programátor sa môže aplikovať s časom. Hierarchia tried nie je teda analógom hierarchického modelu, pretože by sa to mohlo zdať skôr, ale vyžaduje si systém schopnosti zmeniť umiestnenie každého objektu v tried hierarchie, napríklad na navigáciu "hore" alebo "dole "V tejto hierarchii. Je však možné komplexnejší proces - systém by mal poskytnúť predmet objektu, ktorý sa má pripojiť (odpojený) na ľubovoľný vertex hierarchie kedykoľvek.

Dôležitú úlohu v OUD hrá obmedzenia týkajúce sa integrity vzťahov. Aby sa komunikácia v objektovo orientovaných na prácu na prácu, identifikátory objektov na oboch stranách komunikácie musia spĺňať navzájom. Napríklad, ak existuje prepojenie medzi zamestnancami a ich deťmi, potom musí existovať nejaký druh záruky, že pri vkladaní objektu opisujúceho dieťaťu do objektu, ktorý zobrazuje zamestnanca, druhý identifikátor sa pridá k príslušnému objektu. Tento typ integrity pripojenia, v niečom podobnej referenčnej integrite v modeli relačného dát, sa nastaví pomocou inverzné väzby. Aby ste zaručili integritu odkazov, dizajnér je vybavený špeciálnym dizajnom syntaxe potrebného na určenie umiestnenia spätného identifikátora objektu. Povinnosť stanoviť obmedzenia týkajúce sa integrity vzťahov (ako aj referenčná integrita v relačnej databáze) leží na dizajnér.

V OMD a popise údajov a manipulovať s nimi sa vyskytujú s rovnakým predmetom orientovaným procesným jazykom.

Riadenie databázy objektov GROUP (Objekt Database Management Grow). Vyvinula model objektu (verzia ODMG 2.0 bola prijatá v septembri 1997), ktorá definuje štandardný model pre sémantiku BD objektov. Tento model má veľký význam, pretože určuje vstavanú sémantiku, ktorá je tiež chápaná a môže implementovať objektovo orientované DBMS (OOSUBD). Štruktúra knižníc a aplikácií pomocou tejto sémantiky sa musí preniesť na rôzne oosubds, ktoré podporujú tento objekt MD. Hlavnými komponentmi architektúry ODMG sú: objektový model (om), jazyk definície objektu (ODL), jazyk objektového dotazu (OQL), a C ++, Java a SlmAction Winding Schopnosť.

Objektový model údajov v súlade s normou ODMG 2.0 sa vyznačuje nasledujúcimi vlastnosťami:

Základné konštrukčné prvky sú objekty a literály. Každý objekt má jedinečný identifikátor. Literál nemá svoj vlastný identifikátor a nemôže existovať samostatne ako objekt. Literály sú vždy zabudované do objektov a nemôžu byť označované individuálne;

Objekty a literály sa líšia typu. Každý typ má svoju vlastnú doménu oddelené všetkými objektmi a literálmi tohto typu. Typy môžu mať tiež správanie. Ak má typ nejaké správanie, potom všetky objekty tohto typu majú rovnaké správanie. V praxi môže byť typ triedy, z ktorej je vytvorený objekt, rozhranie alebo jednoduchý typ dát (napríklad celé číslo). Objekt môže byť reprezentovaný ako inštancia typu;

Stav objektu je určený súborom aktuálnych hodnôt implementovaných rôznymi vlastnosťami. Tieto vlastnosti môžu byť atribúty objektu alebo komunikácie medzi objektom a jedným alebo viacerými inými predmetmi;

Správanie objektu je určené súborom operácií, ktoré možno vykonať nad objektom alebo samotným objektom. Operácie môžu mať zoznam vstupných a výstupných parametrov, z ktorých každý z nich striktne definovaný typ. Každá operácia môže tiež vrátiť zadaný výsledok;

Definícia databázy je uložená v schéme zaznamenanej v jazyku definovania objektov (ODL). Databáza ukladá objekty, čo im umožňuje zdieľať ich na zdieľanie rôznych používateľov a aplikácií.

DBMS založené na oud sa nazývajú objektovo orientované DBMS (OOSUBD). Tieto DBMS odkazujú na DBMS tretej generácie * (* História rozvoja skladovacích modelov je často rozdelená do troch etapov (generácie): prvá generácia (koniec roku 1960 je začiatkom 70. rokov) - hierarchické a sieťové modely; druhá generácia (približne 1970-1980) - relačného modelu; tretia generácia (1980 - - začiatkom 2000s) - objektovo orientované modely.).

Dnes sa objektovo orientované databázy aplikujú v rôznych organizáciách na riešenie Široký kruh Úloh. Analýza a zovšeobecnenie nahromadených skúseností v oblasti údajov informačných technológií umožnilo identifikovať aplikácie, v ktorých je používanie objektovo orientovaných databáz oprávnené:

Aplikácia sa skladá z veľké množstvo interakcie časti. Každý z nich má svoje správanie, ktoré závisí od správania druhých;

Systém by mal spracovať veľké objemy neštruktúrovanej alebo majú komplexnú dátovú štruktúru;

Aplikácia bude vykonávať predvídateľný prístup k údajom, takže navigačná povaha objektovo orientovanej databázy nebude významnou nevýhodou;

Potreba neplánovaných požiadaviek je obmedzená;

Štruktúra uložených údajov má hierarchickú alebo podobnú povahu.

V v súčasnosti Na softvérovom trhu je mnoho objektovo orientovaných DBMS. V Tab. 10.6 Niektoré komerčné systémy tejto triedy sú prezentované.

Tabuľka 10.6.

Moderné komerčné Oosubd,

svojich výrobcov a rozsah

Jedným zo základných rozdielov databáz objektov z relational je schopnosť vytvárať a používať nové typy údajov. Dôležitým rysom OOSUBD je, že vytvorenie nového typu nevyžaduje modifikáciu databázy a je založená na princípoch objektovo orientovaného programovania.

Jadro Oosubd je optimalizované pre operácie s objektmi. Prírodné operácie pre IT sú ukladacie objekty, vedenie verzií objektov, oddelenie prístupových práv na konkrétne objekty. Oosubd má vyššiu rýchlosť na operáciách, ktoré vyžadujú prístup a prijímanie dát balených v objektoch, v porovnaní s relačným DBMS, pre ktoré je potrebné odberu vzoriek, ktoré sú pripojené údaje vedie k dodatočným vnútorným operáciám.

Značná hodnota pre Oosubd má schopnosť presunúť objekty z jednej základne na druhú.

Pri vytváraní rôznych aplikácií založených na báze OOSUBD je postavená vstavaná štruktúra triedy jednej alebo inej DBMS. Knižnica triedy podporuje zvyčajne nielen všetky štandardné typy údajov, ale aj rozšírenú sadu multimédií a iných komplexných typov údajov, ako je video, zvuk, sekvencia animačných rámov. V niektorých Oosubd sa vytvárajú knižnice triedy, čo umožňuje uskladnenie a úplné vyhľadávanie informácií o dokumentárnych informáciách (napríklad Jasmine, ODB-JUPITE). Príklad základnej štruktúry tried je znázornený na obr. 10.17.

Hlavná pozícia v IT zaberá triedu Todbobject, ktorá obsahuje všetky potrebné vlastnosti a metódy riadenia prístupu k databáze a indexovaniu. Všetky ostatné triedy prepúšťajú svoje metódy pridaním správnosti správnosti typu a konkrétneho indexéra.

Ako je zrejmé z obr. 10.17, V štruktúre existujú rôzne triedy zamerané na spracovanie dokumentárnych informácií - TodbText, Todbdocument, TodbtextDocument, atď Každý dokument je reprezentovaný samostatným objektom. To zabezpečuje prirodzené uskladnenie dokumentov. Jednou z najdôležitejších operácií je vyhľadávanie dokumentov na požiadanie. Pre väčšinu tried sa implementuje schopnosť vyhľadávať objekty podľa hodnoty konkrétneho kľúča. Pre triedu TodbText sa realizuje možnosť tvarovania vyhľadávací dopyt Fráza napísaná v prirodzenom jazyku.

Trieda Todbdocument je špeciálna, schopná ukladať diferenciálne objekty. Pozostáva z polí, z ktorých každá má meno a súvisiace s objektom určitého typu. Prítomnosť tejto triedy dáva užívateľovi možnosť rozšíriť typovú súpravu. Upravte objekt kontajnera (dokument), môžete nastaviť určitú sadu polí a získať nový typ dokumentu.

Na základe ODB-Jupitera vytvorili vývojári Oosubd plnohodnotný zdroj informačného systému ODB-text, ktorý má univerzálna štruktúra Uložené dáta a výkonný mechanizmus vyhľadávania. Systém ODB-Text je kolektívne spracovanie dokumentov a údržbu firemného archívu. Medzi možnými aplikáciami budú zavolať automatizáciu účtovníctva dokumentov o riadení dokladu moderného úradu, referencie na stavebníctvo informačné systémy (Podobne ako známe právne databázy), udržiavanie sieťových databáz, záznamov o personálu, bibliografii atď.

41. Vlastnosti navrhovania aplikovanej IP. Fázy vývoja IP. (Téma 11, s. 100-103).

11.1.3. Vlastnosti aplikovaného systému

Pri budovaní (výber, prispôsobenie) informačného systému môžete použiť dva základné pojmy, dva hlavné prístupy (tretia koncepcia - ich kombinácia):

1. Orientácia na problémy, ktoré je potrebné riešiť pomocou tohto informačného systému, t.j. problém orientovaný na problém (alebo indukčný prístup);

2. Orientácia na technológii, ktorá je k dispozícii (aktualizovaná) v tomto systéme, strednom, t.j. Technologicky orientovaný prístup (alebo deduktívny prístup).

Výber koncepcie závisí od strategických (taktických) a (alebo) dlhodobých (krátkodobých) kritérií, problémov, zdrojov.

Ak sa najprv študujú možnosti existujúcej technológie, a po určovaní skutočné problémyktoré možno riešiť s ich pomocou, potom je potrebné spoliehať sa na technologicky orientovaný prístup.

Ak sú najprv určené aktuálne problémy a potom sa technológia realizuje dostatočné na vyriešenie týchto problémov, je potrebné spoliehať sa na problém orientovaný na problém.

Zároveň, obe koncepcie budovania informačného systému závisia na sebe: zavedenie nových technológií mení problémy s riešením, a zmena problémov vyriešených - vedie k potrebe zaviesť nové technológie; Obaja sú ovplyvnené rozhodnutiami.

Dizajn systému (vývoj) a používanie akéhokoľvek aplikačného (firemného) informačného systému musí prejsť nasledujúcim životným cyklom informačného systému:

- analýza predbežného projektu (skúsenosti pri vytváraní iných podobných systémov, prototypov, rozdielov a vlastností vyvinutého systému atď.), Analýza vonkajších prejavov systému;

- analýza intrasystému, interná analýza (analýza systémových subsystémov);

- systémový (morfologický) popis (prezentácia) systému (opis systému systému, systémové vzťahy a životné prostredie, iné systémy a systémové zdroje - materiál, energia, informačné, organizačné, ľudské, priestorové a dočasné);

- určenie kritérií primeranosti, efektívnosti a udržateľnosti (spoľahlivosť);

- funkčný popis subsystémov systému (popis modelov, funkčných podsystémov algoritmov);

- Maketling (Popis make-up) systému, posúdenie interakcie systémových subsystémov (vývoj usporiadania - implementácia subsystémov so zjednodušenými funkčnými opismi, postupmi a testovaním interakcie týchto rozložení s cieľom splniť systémový cieľ ), je možné použiť "rozloženie" primeranosti, udržateľnosti, efektívnosti;

- "montáž" a testovanie systému - vykonávanie plných funkčných subsystémov a kritérií, posúdenie modelu podľa formulovaných kritérií;

- fungovanie systému;

- definovanie cieľov ďalšieho rozvoja systému a jeho žiadostí;

- Podpora systému - objasnenie, modifikácia, rozširovanie schopností systému vo svojom fungovacom režime (aby sa ho mohli vyvinúť).

Tieto fázy sú základné systémy pre systémy reengineeringu.

Vývoj firemného informačného systému sa spravidla vykonáva pre úplne definovaný podnik. Funkcie predmetnej činnosti podniku určite ovplyvnia štruktúru informačného systému. Zároveň sú však štruktúry rôznych podnikov všeobecne podobné. Každá organizácia, bez ohľadu na jej činnosti, pozostáva z množstva divízií priamo vykonávajúcich jeden alebo iný typ činnosti spoločnosti. A táto situácia platí pre takmer všetky organizácie, bez ohľadu na to, aký druh činnosti robia.

Akákoľvek organizácia sa teda môže považovať za množinu interakčných prvkov (jednotiek), z ktorých každý môže mať svoje vlastné, pomerne komplikované, štruktúru. Vzťah medzi divíziami je tiež dosť zložitý. Vo všeobecnom prípade možno rozlíšiť tri typy odkazov medzi divíziami podnikov:

Funkčné vzťahy - Každá jednotka vykonáva určité druhy práce ako súčasť jednotného obchodného procesu;

Informačné spojenia - informácie o výmene devízov (dokumenty, faxy, písomné a ústne objednávky atď.);

Externá komunikácia, niektoré divízie komunikujú externé systémyOkrem toho ich interakcia môže byť aj informačná a funkčná.

Všeobecná štruktúra rôznych podnikov umožňuje formulovať niektoré jednotné zásady pre stavebné firemné informačné systémy.

Vo všeobecnosti možno proces vypracovania informačného systému zvážiť z dvoch hľadísk: \\ t

V čase, alebo v etapách Životný cyklus Vyvinutý systém. V tomto prípade sa zvažuje dynamická organizácia procesu vývoja opísaného z hľadiska cyklov, etáp, iterácie a etáp.

Informačný systém podniku je vyvinutý ako nejaký projekt. Mnohé znaky projektového riadenia a fázy vývoja projektu (fázy životného cyklu) sú všeobecné, nezávislé nielen z oblasti predmetu, ale aj o povahe projektu (bez ohľadu na to, inžinierstvo je projektom alebo ekonomickým). Preto dáva zmysel na začiatku zvážiť číslo všeobecné otázky Projektový manažment.

Projekt je cieľovo obmedzená zmena v samostatnom systéme s pôvodne presne definovanými cieľmi, ktorých dosiahnutie určuje ukončenie projektu, ako aj stanovené požiadavky Doteraz, výsledky, riziko, rámec pre fondy a zdroje a organizačná štruktúra.

Zvyčajne pre komplexný koncept (ktorý, najmä koncepcia projektu), je ťažké dať jednoznačnú formuláciu, ktorá plne pokrýva všetky známky myšlienky koncepcie. Vyššie uvedená definícia preto nepožiada o jedinečnosť a úplnosť.

Nasledujúce hlavné rozlišovacie znaky projektu ako predmet riadenia možno rozlíšiť:

Variabilita - cielený preklad systému z existujúceho

požadovaný stav opísaný z hľadiska cieľov projektu;

Obmedzený konečný cieľ;

Obmedzené trvanie;

Rozpočtové obmedzenia;

Vyžadované obmedzené zdroje;

Novinka pre podnik, pre ktorý sa projekt realizuje;

Komplexnosť je prítomnosť veľkého počtu faktorov, priamo alebo nepriamo ovplyvniť pokrok a výsledky projektu;

Právne a organizačné zabezpečenie je vytvorenie špecifickej organizačnej štruktúry v čase realizácie projektu.

Účinnosť práce sa dosahuje riadením procesu implementácie projektu, ktorý zabezpečuje rozdelenie zdrojov, koordinovať postupnosť práce a kompenzácie pre vnútorné a vonkajšie rušivé účinky.

Z hľadiska teórie kontrolných systémov je potrebné dodržiavať projekt ako predmet riadenia a zvládnuť, to znamená, že niektoré vlastnosti sú pridelené na neustále monitorovať priebeh projektu (vlastnosť pozornosti). Okrem toho je potrebné, aby sa mechanizmy včasného pôsobenia na pokroku projektu (majetok ovládateľnosti).

Nehnuteľnosť Riadenie je obzvlášť relevantná v oblasti neistoty a variability oblasti predmetu, ktorá často sprevádzajú projekty na rozvoj informačných systémov.

Každý projekt, bez ohľadu na zložitosť a rozsah práce potrebnú na jeho realizáciu, sa koná vo svojom rozvoji určitých štátov: od štátu, keď projekt ešte nie je, "do štátu, keď projekt už nie je. Kombinácia rozvojových krokov od vzniku myšlienky na úplné ukončenie projektu sa vyrába na rozdelenie fáz (etapy, etapy).

Pri určovaní počtu fáz a ich obsahu existujú určité rozdiely, pretože tieto charakteristiky sú vo veľkej miere závislé od podmienok vykonávania konkrétneho projektu a skúseností hlavných účastníkov. Logika a hlavný obsah procesu vývoja informácií v takmer všetkých prípadoch sú však spoločné.

Nasledujúce fázy vývoja informačného systému možno rozlíšiť:

Tvorba koncepcie;

Vývoj technických špecifikácií;

Dizajn;

Výroba;

Zadanie systému do prevádzky.

Podrobnejšie zvážte každý z nich. Druhá a čiastočne tretia fáza sa vyrábajú, aby zavolali fázy dizajnu systému a posledné dve (niekedy zahŕňajú fázu dizajnu) - fázy implementácie.

Koncepčná fáza

Tvorba myšlienok, stanovenie cieľov;

Vytvorenie kľúčového príkazu projektu;

Štúdium motivácie a požiadaviek zákazníka a ostatných účastníkov;

Zhromažďovanie zdrojov a analýzy existujúceho stavu;

Identifikácia základných požiadaviek a obmedzení požadovaných materiálnymi, finančnými a pracovnými zdrojmi;

Porovnávacie hodnotenie alternatív;

Zastúpenie, ich odborné znalosti a schválenie.

Rozvoj technického rozvoja

Vývoj hlavného obsahu projektu, základná štruktúra projektu;

Rozvoj a schvaľovanie technickej úlohy;

Plánovanie, rozklad základného štrukturálneho modelu projektu;

Vypracovanie odhadov a rozpočtu projektu, ktorý určuje potrebu zdrojov;

Vývoj kalendárnych plánov a rozšírených pracovných plánov;

Podpísanie zmluvy so zákazníkom;

Uvedenie do prevádzky pre komunikácie účastníkov projektu a monitorovanie domácej práce.

Dizajn

V tejto fáze sa určia subsystémy, sú zvolené ich vzťahy. efektívne metódy Použitie projektu a zdrojov. Charakteristické diela tejto fázy:

Vykonávanie základných konštrukčných prác;

Rozvoj súkromných technických úloh;

Implementácia koncepčného dizajnu;

Vypracovanie technických špecifikácií a pokynov;

Zastúpenie vývoja projektu, skúšky a schválenia.

Vývoja

V tejto fáze sa vyrábajú koordinácia a prevádzková kontrola práce na projekte, výrobu subsystémov, ich združenie a testovanie. Hlavný obsah:

Vykonávanie pracovných prác softvéru;

Realizácia prípravy na implementáciu systému;

Kontrola a regulácia hlavných ukazovateľov projektu.

Uvedenie do prevádzky

V tejto fáze, testy, pilotné fungovanie systému v reálnych podmienkach, prebiehajú rokovania o výsledkoch projektu a možných nových zmlúv. Hlavné typy diel:

Komplexné testy;

42. Koncepcia životného cyklu IP. (Téma 11, str. 103-105).

Objektovo orientovaný model

V objektovo orientovaným modelom je prezentácia údajov možná identifikovať jednotlivé databázové záznamy. Medzi nahrávaním a funkciami ich spracovania sú stanovené pomocou mechanizmov podobných vhodných prostriedkov v objektovo orientovaných programovacích jazykoch.

Štandardizovaný model orientovaný na objektov je opísaný v štandardných odporúčaniach ODMG-93 (skupina databázy databázy objektov - skupina riadiacich objektovo orientovaných databáz).

Zvážte zjednodušený model objektovo orientovanej databázy. Štruktúra objektovo orientovanej databázy graficky predstavuje vo forme stromu, ktorého uzly sú objekty. Vlastnosti objektov sú opísané nejakým štandardným typom alebo typom, ktorý navrhol užívateľ (definovaný ako trieda). Hodnota vlastnosti triedy je objekt, ktorý je inštanciou zodpovedajúcej triedy. Každá objekt inštancie triedy sa považuje za potomkov predmetu, v ktorom je definovaný ako majetok. Objekt-inštancia objekt patrí do svojej triedy a má jedného rodiča. Generické vzťahy v databáze tvoria koherentnú hierarchiu objektov. Príklad logickej štruktúry objektovo orientovanej knižničnej databázy je znázornená na obr. 2.9. Objekt typu knižnice je tu rodičovský pre objekty inštancie objektu. Účastník, adresár a emisia. Rôzne objekty, ako napríklad kniha, môžu mať jedného alebo odlišných rodičov. Objekty, ako je kniha, ktorá má rovnaký rodič, by sa mali líšiť aspoň číslo inventára (jedinečné pre každú kópiu knihy), ale majú rovnaké IBN, UDC vlastnosti, meno a autor.

Logická štruktúra objektovo orientovanej databázy navonok je podobná štruktúre hierarchickej databázy. Hlavný rozdiel medzi nimi pozostáva z metód manipulácie s údajmi.

Na vykonávanie opatrení na dátach v posudzovaní databázového modelu sa používajú logické operácie, ktoré sú zvýšené objektovo orientovanými mechanizmami zapuzdrenia, dedičstva a polymorfizmu.

Zapuzdrenie obmedzuje rozsah názvu vlastností v objekte, v ktorom je definovaný. Takže, ak typ objektu je objekt katalógu, pýta sa na telefón autora knihy a má telefónny názov, potom dostaneme vlastnosti rovnakého mena od účastníka a katalógu. Význam tejto vlastnosti bude určený objektom, v ktorom je zapuzdrený.

Naopak distribuuje rozsah nehnuteľnosti na všetkých potomkoch predmetu. Takže, všetky objekty, ako napríklad kniha, ktoré sú potomkami objektu typu objektu, možno pripísať vlastnostiam rodičovského objektu: ISBN, UDC, meno a autor. Ak je potrebné rozšíriť účinok mechanizmu dedičstva na predmety, ktoré nie sú priame príbuzní (napríklad medzi dvomi potomkami jedného rodiča), potom sa v ich celkovom predkovi určuje abstraktný typ typu ABS. Takže definícia abstraktných vlastností cestovného lístka a číslo v objekte knižnice vedie k dedičstvu týchto vlastností všetkými predplatiteľmi, účastníkom, knihou a vydávaním. Nie je náhodou, že hodnoty majetku účastníka triedy a emisie znázornené na obr. 2.9, sú rovnaké - 00015.

Polymorfizmus v objektovo orientovaných programovacích jazykoch znamená schopnosť toho istého programového kódu pracovať s viacsmernými údajmi. Inými slovami, to znamená prípustnosť v objektoch rôznych typov, ktoré majú metódy (postupy alebo funkcie) s rovnakými menami. Počas vykonávania objektu programu sa rovnaké metódy prevádzkujú s rôznymi objektmi v závislosti od typu argumentu. Pokiaľ ide o posudzovaný príklad, polymorfizmus znamená, že objekty triedy s rôznymi rodičmi z katalógu triedy môžu mať iný súbor vlastností. V dôsledku toho môžu pracovné programy s objektmi tried obsahovať polymorfný kód.

Vyhľadávanie objektovo orientovanej databázy je určiť podobnosť medzi užívateľom a objekty uloženými v databáze.

Obr. 2.9 Štruktúra databázy knižnice

Hlavnou výhodou objektovo orientovaného dátového modelu v porovnaní s relačným je schopnosť zobrazovať informácie o komplexných vzťahoch objektov. Objekt-orientovaný dátový model umožňuje identifikovať samostatnú databázovú položku a určiť funkcie ich spracovania.

Nevýhodou objektovo orientovaného modelu sú vysoká koncepčná zložitosť, nepríjemnosti spracovania dát a nízkou rýchlosťou dotazov.

Objektovo orientované DBMS zahŕňa básnik, Jasmine, Versant, O2, ODB-JUPITERS, IRIS, ORION, Postgres.

Data Banks, ako celé číslo, sú zvyčajne klasifikované ekonomickými a právnymi dôvodmi.

Podľa podmienok poskytovania služieb sa rozlišujú slobodné a platené banky, ktoré sú zase rozdelené na komerčné a neziskové (vedecké, knižnice alebo sociálne významné).

Vo forme vlastníctva sú BND rozdelené do štátu a neštátneho. Podľa stupňa prístupnosti existujú verejne dostupné a obmedzené rozsahy.

Iné druhy klasifikácie sú spojené so samostatnými zložkami BND.

1. Rozvoj dátových bánk pozostáva zo 4 etáp:

1. etapa. Tvorba a analýza systémových požiadaviek:

Špecifikácia systému je zostavená, ktorá obsahuje zoznam úloh, ktoré musí BND vyriešiť;

Zoznam koncových užívateľov a ich funkcie;

Zoznam požiadaviek na databáz;

Vypracuje sa okruh prietoku dokumentov v organizácii.

Fáza 2. Koncepčný dizajn: Systémový informačný model je vytvorený bez väzby na typ počítača a typu systému systém; Zabuduje sa infologický model databázy, ktorý najviac opisuje oblasť predmetu v podmienkach používateľa.

3 etapa. Implementačný dizajn: Výber výpočtového systému, systém softvér a dbms; Štruktúra dát je navrhnutá a model Datalog databázy (DB Schéma) je postavený, čo je popis logickej štruktúry databázy v jazyku špecifických vybraných DBMS.

4 etapa. Fyzická implementácia, ktorá zahŕňa vytvorenie a sťahovanie dát v databáze, vývoj a ladenie aplikačných programov na prácu s databázou, písanie dokumentácie. V tomto štádiu je vybudovaný fyzikálny model BD, ktorý opisuje použité pamäťové zariadenia, metódy fyzickej organizácie údajov. Popis fyzickej štruktúry databázy sa nazýva schéma skladovania. V súčasnosti existuje tendencia znížiť tento typ práce.

2. Hlavné úlohy vyriešené zamestnancami údajov

Zamestnanci personálu BND zahŕňajú rôznych špecialistov: administrátori BND, systémových analytikov, systémových a aplikačných programátorov, operátori, špecialisti technické prostriedkyMarketing atď.

Uvádzame hlavné funkcie a úlohy vyriešené zamestnancami pri vývoji a prevádzke databázy:

1) Analýza predmetu (určenie potrieb koncových užívateľov, budovanie informačného modelu oblasti predmetu, identifikácia obmedzení integrity);

2) Projektovanie databázovej štruktúry (určenie zloženia a štruktúry databázových súborov, popis jeho schémy v jazyku opisu údajov);

3) Nastavenie obmedzení integrity databázy;

4) Načítavanie a údržba databázy (databáza sa označuje, vymazanie a pridanie položiek); Vývoj technológií sťahovania a údržby; Vývoj foriem zadávania údajov; vstup a kontrola údajov;

5) Ochrana údajov (vymedzenie používateľov, výber a kontrola prostriedkov ochrany, fixáciu pokusov neoprávneného prístupu);

6) Zabezpečenie obnovy databázy;

7) Analýza účinnosti BND a rozvoj systému;

8) Práca s užívateľmi (zber odpovedí, školení);

9) Podpora systémového softvéru (akvizícia, inštalácia a rozvoj);

10) Organizačné a metodické práce (výber metód dizajnu a modernizácie, plánovanie rozvoja BND, vývoj dokumentácie).

3. Používatelia dátových bánk

Podobne ako akýkoľvek program a organizačný a technický komplex, dátová banka existuje v čase av priestore. Má určité fázy vývoja:

Dizajn,

Implementácia,

Podpora,

Aktualizácia a rozvoj,

Úplná reorganizácia.

V každej fáze existencie sú k Data Bank pripojení rôzne kategórie spotrebiteľov.

Koncových užívateľov

Toto je hlavná kategória používateľov, ktorí majú záujmy spojené s Data Bank. V závislosti od funkcií vytvorených údajov sa údaje môžu v podstate líšiť okolo svojich koncových užívateľov. Môžu to byť náhodné spotrebitelia adresované databáze z času na čas do databázy po obdržaní niektorých informácií a môžu byť bežní používatelia. Príležitostní spotrebitelia možno považovať za možné zákazníkov firmy prezeranie katalógu nastavenia alebo služieb so zovšeobecným alebo detailný popis. Zamestnanci pracujúci s programami osobitne určenými pre nich, ktorí poskytujú automatizáciu svojich činností pri výkone funkcií, môžu byť bežní používatelia. Napríklad na administrácii, ktorý plánuje pomocnú jednotku počítačová spoločnosť, Existuje program, ktorý mu pomáha plánovať a umiestniť aktuálne objednávky podľa pokynov, kontrolovať priebeh ich výkonu, zefektívniť v sklade Potrebné príslušenstvo pre nové objednávky. Hlavné, špeciálne znalosti, ktoré od koncových užívateľov by sa nemali vyžadovať v oblasti jazykových a výpočtových technológií.

Administrátori údajov

Ide o skupinu používateľov, ktorí v počiatočnom štádiu vývoja dátových bankovníctva zodpovedá za svoje optimálne zariadenie z hľadiska simultánnej prevádzky súboru koncových užívateľov, na podporu, je štádium zodpovedné za správnu činnosť Tento stav informácií v režime multiplayerov. Vo vývoji a štádiu reorganizácie je táto skupina zodpovedná za možnosť správnej reorganizácie zásobníka bez zmeny alebo vyplnenia svojej súčasnej služby.

Vývojári a administrátori aplikácií

Táto skupina používateľov, ktorá funguje počas dizajnu, tvorby a reorganizácie dátovej banky. Administrátori aplikácií koordinovať vývojárov, aby vytvorili špecifickú aplikáciu alebo skupinu žiadostí zjednotených vo funkčnom subsystéme. Vývojári určitých aplikácií pracujú so súčasťou informácií z databázy, ktorá sa vyžaduje pre konkrétnu aplikáciu.

Nie v každej dátovej banke je možné zvoliť akýkoľvek typ používateľov. Je známe, že vývoj informačných systémov pomocou správcu tabuľky DBMS Data Bank, administrátor aplikácie a vývojár často existovali v jednej osobe. Avšak, pri vytváraní moderných zložitých firemných databáz, ktoré sa používajú na automatizáciu všetkých alebo veľkých častí obchodných procesov vo veľkej spoločnosti alebo spoločnosti, môžu existovať skupiny administrátorov aplikácií a departementov vývojárov. Najťažšie spôsoby práce sú priradené skupine administrátorov databáz.

Podrobnejšie ich zvážiť.

Časť GND admin Group musí byť:

Systém komentátorov;

Vývojári dátových štruktúr a vzhľadu týkajúce sa banky podpory informácií;

Vývojárov procesov spracovania spracovania údajov;

Systému a aplikovaných programátorov;

Existujúce spoločnosti a odborníci v opravárenskom servise.

Problematika obchodnej banky, hrá dôležitú úlohu, predaj odborníkov.

Hlavné funkcie skupiny administrátora DB

1. Štúdia dátovej oblasti: Popis databázy, ktorým sa ustanovujú text integrity obmedzenia, definícia stavu (dostupnosť, dôvernosť) informácie, definícia potrieb spotrebiteľa, definícia "spotrebiteľov údajov", stanovenie charakteristík na spracovanie dát.

2. Vývoj BD štruktúry: Definícia zloženia a štruktúry databázových súborov a komunikácie medziprodukty, výber metód optimalizácie údajov a metódy prístupu na informácie, popisy databáz v jazyku popisu údajov (JaOode).

3. Nastavenie obmedzení integrity v popise štruktúry postupov spracovania databáz a databáz:

Nastavenie deklaratívnych obmedzení integrity, ktoré sú obsiahnuté v oblasti údajov;

Stanovenie dynamických obmedzení integrity obsiahnutých v oblasti údajov počas zmeny informácií uložených v databáze;

Stanovenie obmedzení integrity je spôsobené štruktúrou databázy;

Vývoj postupov na podporu integrity databázy pri zadávaní a úprave údajov;

Určenie obmedzení integrity paralelnej prevádzky spotrebiteľov v režime Multiplayer.

4. Začatie prevzatia a manuálnej databázy

Vývoj techniky nakladania DB, ktorá sa bude líšiť od postupu pre zmenu a pridanie databázy s údajmi s pravidelným používaním;

Vývoj techník na overenie zadané údaje, skutočný stav databázy. Skutočné objekty databázových modelov niektorých dátových a stredných korelácií a v čase začiatku aktuálne opravy Tento model sa musí zhodovať so stavom objektov dátovej oblasti teraz;

Podľa rozvinutého technika iniciovania dizajnu systému vstupu údajov môže byť potrebné.

5. Ochrana údajov

Stanovenie hesla systému, princípy streľby spotrebiteľov, vytvorenie skupín spotrebiteľov, ktorí majú identické práva na prístup k údajom;

Rozvoj zásad prevencie určitých objektov údajov a rozvoj; Rozvoj špecializovaných metód kódovania informácií počas svojho obehu v miestnych a globálnych informačných sieťach;

Vývoj prostriedkov na stanovenie prístupu k údajom a pokusom o porušenie systému ochrany;

Systém ochrany testovania;

Štúdium prípadov porušenia systému ochrany a rozvíjať dynamické metódy na zabránenie informácií v databáze.

6. Podpora obnovy databázy

Rozvoj organizačných prostriedkov Archivácia a zásady obnovy databázy;

Vývoj ďalších zrelých a technologických procesov obnovy databázy po zlyhaniach.

7. Štúdium databázy zákazníkov databázy: súbor štatistiky na symbol žiadostí, čas zahrnutia ich výkonu v súlade s požadovanými výstupnými dokumentmi

8. Štúdium účinnosti fungovania BND:

Štúdium funkčných indexov BND

Reštrukturalizácia plánovania štruktúry (štrukturálna zmena) databázy a reorganizácie BND.

9. Práca s koncovými užívateľmi:

Zber informácií o zmene oblasti údajov;

Zber informácií o hodnotení prác BND;

Spotrebiteľov, konzultanti spotrebiteľov;

Vývoj potrebnej systematickej a vzdelávacej dokumentácie týkajúcej sa práce koncových používateľov.

10. Vybavenie systému varenia a podpory:

Štúdium dozrievania existujúcich na trhu a výskumných schopností a potreba ich používať v rámci BND;

Vývoj požadovaného organizačného a technického programu pohybu pre rozvoj BND;

Kontrola výkonu vykúpených zrelých pred ich spojením s BND;

Kontrola pripojenia nových zrelých do BND.

11. Organizačná a systematická práca pri vývoji BND:

Výber alebo vytvorenie metódy vývoja databázy;

Určenie cieľov a smerovania vývoja systému ako celku;

Plánovanie etáp vývoja BND;

Vývoj referenčných kníh všeobecných slovníkov projektu BND a koncepčný model;

Inštalácia externých modelov vyvinutých aplikácií;

Kontrola pripojenia novej aplikácie na operáciu BND;

Možnosť integrovaného súboru riešenia problémov aplikácií, ktoré interagujú z jednej databázy.

V modeli orientovanej na objektov (OU), keď sú údaje predložené, je možné identifikovať jednotlivé základné položky. Medzi databázovými záznamami a funkciami ich spracovania stanovujú vzťahy s použitím mechanizmov podobných vhodných prostriedkov v objektovo orientovaných programovacích jazykoch.

Štandardné ou Opísané v štandardných odporúčaniach ODMG-93 (skupina databázy objektov - skupina pre správu objektovo orientovaných databáz). Odporúčanie ODMG-93 ešte nie je možné. Na ilustráciu kľúčových nápadov zvážte mierne zjednodušený model objektovo orientovanej databázy.

Štruktúra OO DB graficky predstavuje vo forme stromu, ktorého uzly sú objekty. Vlastnosti objektu sú opísané nejakým štandardným typom (napr. String - reťazec) alebo typ vytvoreným užívateľom (definovaným ako trieda).

Hodnoty typu reťazca je reťazec znakov. Hodnota vlastnosti triedy je objekt, ktorý je inštanciou zodpovedajúcej triedy. Každá objekt inštancie triedy sa považuje za potomkov predmetu, v ktorom je definovaný ako majetok. Objekt-inštancia objekt patrí do svojej triedy a má jedného rodiča. Generické vzťahy v databáze tvoria viazanú hierarchiu objektov.

Príklad logickej štruktúry puzdra OO DB je znázornený na obr. 3.14. Objekt typu knižnice je tu rodičovský pre objekty inštancie objektu. Účastník, adresár a emisia. Rôzne objekty, ako napríklad kniha, ktorá má ten istý rodič, by sa mali líšiť aspoň v najmenej inventárne číslo (jedinečné pre každú kópiu knihy), ale majú rovnaké hodnoty vlastností iSBN, UDC, NÁZOVa autor.

Obr.3.14.Logická konštrukčná dáta starostlivosť

Logická štruktúra DB OO je externe podobná štruktúre hierarchickej databázy. Hlavný rozdiel medzi nimi pozostáva z metód manipulácie s údajmi. Na vykonávanie akcií o údajoch v databáze sa používajú logické operácie, posilnené objektovo orientovanými mechanizmami zapuzdrenia, dedičstva a polymorfizmu. Operácie, ako sú príkazy SQL, môžu byť obmedzené (napríklad na vytvorenie databázy).

Vytvorenie a úprava databázy je sprevádzaná automatickou formáciou a následným nastavením indexu (indexové tabuľky) obsahujúce informácie na rýchle vyhľadávanie údajov.

Krátko zvážte koncepciu zapuzdrenia, dedičstva a polymorfizmu vo vzťahu k databáze.

Zapuzdrenieobmedzuje rozsah názvu majetku v rámci objektu, v ktorom je definovaný. Takže, ak je objektom katalóg objekt Pridať majetok sa pýta telefónneho zoznamu autora a mať meno telefón,potom dostaneme vlastnosti rovnakého mena od účastníka a katalógu. Význam tejto vlastnosti bude určený objektom, v ktorom je zapuzdrený.

Dedičstvo, Naopak, rozdeľuje oblasť viditeľnosti nehnuteľnosti na všetkých potomkoch predmetu. Takže, všetky objekty, ako je kniha, ktoré sú potomkami objektu typu katalógu, možno pripísať vlastnostiam rodičovského objektu: iSBN, UDC, NÁZOVa autor.Ak je potrebné rozšíriť účinok mechanizmu dedičstva na predmety, ktoré nie sú priame príbuzní (napríklad medzi dvomi potomkami jedného rodiča), potom sa v ich celkovom predkovi určuje abstraktný typ typu ABS. Takže definícia abstraktných vlastností lístok a číslov objekte, knižnica vedie k dedičstvu týchto vlastností všetkými predplatiteľmi, účastníkom, knihou a vydávaním. Nie náhodou preto hodnoty majetku lístoktriedy Účastník a emisia zobrazená na obrázku budú rovnaké - 00015.

Polymorfizmusv programovacích jazykoch orientovaných na objektov znamená schopnosť toho istého programu programu pracovať s viacsmernými údajmi. Inými slovami, to znamená prípustnosť v objektoch rôznych typov, ktoré majú metódy (postupy alebo funkcie) s rovnakými menami. Počas vykonávania objektu programu sa rovnaké metódy prevádzkujú s rôznymi objektmi v závislosti od typu argumentu. Pokiaľ ide o našu databázu OO, polymorfizmus znamená, že kniha triedy objekty, ktorá má rôznymi rodičmi z adresára triedy, môže mať inú množinu vlastností. V dôsledku toho môžu pracovné programy s objektmi tried obsahovať polymorfný kód.

Vyhľadávanie v OO BD je zistiť podobnosť medzi objektom určeným užívateľom a objekty uložené v databáze. Objekt definovaný užívateľom, nazývaný objekt-účel (vlastnosť objektu je typ typu), vo všeobecnom prípade môže byť podmnožinou celej hierarchie objektov v databáze. Objekt objektu, ako aj výsledok vykonania dotazu je možné uložiť v samotnej databáze. Príklad žiadosti o čítanie vstupeniek a účastníckych názvov, ktoré dostali aspoň jednu knihu knižnicou, je znázornená na obr. 3.15.

Základný dôstojnosťTieto údaje v porovnaní s reláciou je schopnosť zobrazovať informácie o komplexných prepojeniach objektov. To vám umožní identifikovať samostatnú databázovú položku a určiť funkcie ich spracovania.

NevýhodaOY sú vysoká koncepčná zložitosť, nepríjemnosti spracovania údajov a nízku rýchlosť dotazov.

Obr.3.15.Fragment databázy s objektovým účelom

Re-obrátiť sa na úlohu objednávok predstavovaných ako model relačného dát na obr. 3.8 a zvážte ho z hľadiska objektovo orientovanej databázy. Celkovo v príklade troch tried: " Zákazníci», « Rozkazy"A" Produkty" Trieda " Zákazníci»Sú betónových klientov; Vlastnosti triedy - Číslo zákazníka, Mesto zákazníka Mesto, Stav, atď. Metódy triedy - " Vytvoriť objednávku», « Zaplatiť účet" atď. Metóda je určitá prevádzka, ktorá môže byť aplikovaná na predmet; Metóda je to, čo by mal objekt urobiť. Trieda zodpovedajúca tabuľke " Informacie o objednavke", nevyžaduje sa. Tabuľkové údaje môžu byť súčasťou triedy " Rozkazy" Dostupnosť v triede " Zákazníci»Metóda" Vytvoriť objednávku"Vedie k interakcii s triedami tried" Rozkazy"A" Produkty" Zároveň užívateľ nemusí vedieť o tejto interakcii objektov. Užívateľ sa osloví na objekt " Rozkazy"A používa metódu" Vytvoriť objednávku" Skutočnosť expozície iným databázam môže byť skrytá od užívateľa. Ak je metóda " Vytvoriť objednávku"Na druhej strane odkazuje na metódu" Skontrolujte úveru klienta"Táto skutočnosť môže byť tiež skrytá od užívateľa. V relačné základne Údaje na vykonanie rovnakých funkcií, musíte napísať postupy v jazyku Visual Basic for Application (VBA).

V 90. rokoch experimentálne prototypy systémov správy databáz OO existovali. V súčasnosti boli takéto systémy rozšírené. Najmä zahŕňajú najmä nasledujúce DBMS: básnik (básnik softvér), Jasmine (Computer Associates), Versant (Versant Technologies), O2 (Ardent Software), ODB-JUPITET (Inteltek Plus Vedecké a výrobné centrum), ako aj IRIS, A postgres.