Koti-Hyvä tietää-Oliopohjaiset tietokannat: saavutukset ja ongelmat. Objektirelaatiotietomalli

Oliopohjaiset tietokannat: saavutukset ja ongelmat. Objektirelaatiotietomalli

OOMD:ssä dataa esitettäessä on mahdollista tunnistaa tietokannan yksittäiset tietueet. Tietokantatietueiden ja niiden käsittelytoimintojen välille luodaan suhteita vastaavien olioohjelmointikielten työkalujen kaltaisilla mekanismeilla.

Standardoitu oliopohjainen malli on kuvattu ODMG-93-standardin suosituksissa (Object Database Management Group - olio-tietokannan hallintaryhmä). ODMG-93:n suosituksia ei ole vielä voitu toteuttaa täysimääräisesti. Avainideoiden havainnollistamiseksi harkitse hieman yksinkertaistettua mallia oliotietokannasta.

Object-oriented-tietokannan (OODB) rakenne esitetään graafisesti puuna, jonka solmut ovat objekteja. Objektin ominaisuudet kuvataan jollain vakiotyypillä (esimerkiksi merkkijono - merkkijono) tai käyttäjän rakentamalla tyypillä (määritelty luokaksi).

String-tyypin ominaisuuden arvo on merkkijono. Tyypin class ominaisuuden arvo on objekti, joka on vastaavan luokan esiintymä. Jokaisen luokan ilmentymäobjektin katsotaan olevan sen objektin ali, jossa se on määritelty ominaisuudeksi. Luokan ilmentymäobjekti kuuluu luokkaansa ja sillä on yksi vanhempi. Yleiset relaatiot tietokannassa muodostavat yhtenäisen objektihierarkian.

Esimerkki kirjastotyön OODB:n loogisesta rakenteesta on esitetty kuvassa. 2.8.

Tässä LIBRARY-tyypin objekti on SUBSCRIBER-, CATALOG- ja ISSUANCE-luokkien ilmentymäobjektien ylätaso. Erilaisia ​​esineitä tyyppi KIRJA voi olla samat tai eri vanhemmat. KIRJA-tyyppisten objektien, joilla on sama emo, on erotettava vähintään tunnusnumerolla (ainutlaatuinen jokaiselle kirjan kopiolle), mutta niissä on oltava samat arvot ominaisuuksia isbn, udk, nimi ja kirjoittaja.

Riisi. 2.8. Kirjastotyötietokannan looginen rakenne

OODB:n looginen rakenne on ulkoisesti samanlainen kuin IDB:n rakenne. Suurin ero niiden välillä on tietojenkäsittelymenetelmissä.

Jos haluat suorittaa toimintoja tarkasteltavan tietokantamallin tiedoille, käytä loogisia operaatioita, jota tehostavat oliopohjaiset kapselointi-, periytymis- ja polymorfismimekanismit. SQL-komentojen kaltaisia ​​toimintoja voidaan käyttää rajoitetusti (esimerkiksi tietokannan luomiseen).

Tietokannan luomiseen ja muokkaamiseen liittyy automaattista tietoa sisältävien indeksien (indeksitaulukoiden) muodostus ja myöhempi säätäminen. Pikahaku tiedot.

Tarkastellaanpa lyhyesti kapseloinnin, periytymisen ja polymorfismin käsitteitä suhteessa oliotietokantamalliin.

Kapselointi rajoittaa ominaisuuden nimen laajuuden objektiin, jossa se on määritelty. Eli jos lisäämme CATALOG-tyyppiseen objektiin ominaisuuden, joka määrittää kirjan tekijän puhelinnumeron ja jolla on nimipuhelin, niin SUBSCRIBER- ja CATALOG-objekteille saadaan samannimiset ominaisuudet. Tällaisen ominaisuuden merkityksen määrää kohde, johon se on kapseloitu.

perintö, sen sijaan se laajentaa ominaisuuden soveltamisalan kaikkiin kohteen jälkeläisiin. Joten kaikille BOOK-tyypin objekteille, jotka ovat CATALOG-tyypin objektin jälkeläisiä, voidaan määrittää pääobjektin ominaisuudet: isbn, udk, otsikko ja tekijä. Jos periytymismekanismin toiminta on tarpeen laajentaa objekteihin, jotka eivät ole välittömiä sukulaisia ​​(esimerkiksi saman vanhemman kahden jälkeläisen välillä), niiden yhteisessä esi-isässä määritellään abstrakti ominaisuus, jonka tyyppi on abs. Siten abstraktien ominaisuuksien lipun ja numeron määrittely LIBRARY-objektissa johtaa näiden ominaisuuksien perimiseen kaikkien SUBSCRIBER-, BOOK- ja ISSUANCE-alojen aliobjektien toimesta. Ei ole sattumaa, että siksi omaisuuden arvot lippu kuvassa näkyvät luokat SUBSCRIBER ja SSUANCE ovat samat - 00015.

Polymorfismi v olio-ohjelmointikielet tarkoittaa saman ohjelmakoodin kykyä toimia heterogeenisten tietojen kanssa. Toisin sanoen se tarkoittaa, että erityyppisillä objekteilla voi olla menetelmiä (proseduureja tai funktioita) samalla nimellä. Objektiohjelman suorituksen aikana samat menetelmät toimivat eri objekteissa argumentin tyypistä riippuen. Suhteessa oliotietokantaamme polymorfismi tarkoittaa sitä, että BOOK-luokan objekteilla, joilla on eri vanhemmat kuin CATALOG-luokassa, voi olla erilainen ominaisuusjoukko. Tästä johtuen BOOK-luokan objektien kanssa työskentelevät ohjelmat voivat sisältää polymorfista koodia.

Haku OODB:stä koostuu käyttäjän määrittämän objektin ja tietokantaan tallennettujen objektien samankaltaisuuden selvittämisestä. Käyttäjän määrittämä objekti, jota kutsutaan kohdeobjektiksi (objektin ominaisuus on tyyppipäämäärä), v yleinen tapaus voi olla koko tietokantaan tallennetun objektihierarkian osajoukko. Kohdeobjekti, samoin kuin kyselyn suorituksen tulos, voidaan tallentaa itse tietokantaan. Kuvassa on esimerkki kyselystä kirjastokorttien numeroista ja tilaajien nimistä, jotka ovat saaneet vähintään yhden kirjan kirjastosta. 2.9.

Riisi. 2.9. Fragmentti tietokannasta, jossa on kohdeobjekti

Main ihmisarvoa OOMD verrattuna relaatioon on kyky näyttää tietoa objektien monimutkaisista suhteista. OOMD:n avulla voit tunnistaa tietokannan yksittäisen tietueen ja määrittää niiden käsittelyn toiminnot.

Main puutteita OOMD ovat käsitteellistä monimutkaisuutta, tietojenkäsittelyn vaikeutta ja alhainen nopeus pyyntöjen toteuttaminen.

90-luvulla oli OODBMS:n kokeellisia prototyyppejä. Tällä hetkellä tällaisia ​​tietokantajärjestelmiä on yli 300. Jotkut järjestelmät ovat suhteellisen yleisiä, kuten seuraavat DBMS: välimuisti (InterSystems), ROET (ROET Software), Jasmine (Computer Associates), Versant (VersantTechnologies), O2 (ArdentSoftware), ODB-Jupiter (tutkimus- ja tuotantokeskus "Inteltek Plus" "), sekä Iris, Orion ja Postgres.

OODB:n etujen pitäisi tulevaisuudessa johtaa niiden erittäin laajaan levittämiseen. Tätä varten sinun on ensin ratkaistava OODB:n luontaisten puutteiden poistamiseen liittyvät ongelmat: lisättävä tietokantarakenteen joustavuutta, rakennettava selkeä ohjelmointikieli, laadittava kyselyjen jäsennyssyntaksi, määriteltävä useita menetelmiä tietojen saamiseksi, selvitettävä samanaikaiseen käyttöön liittyvät kysymykset, monimutkaisten tietojen luettelointi, tietosuoja ja palautus. Listaa ratkaistavista tehtävistä voidaan jatkaa.

Kuitenkin jopa näiden ongelmien ratkaisemisen jälkeen siirtyminen OODB:hen on asteittaista eikä kovin nopeaa, koska on vaikeaa irtautua valtavasta määrästä olemassa olevia relaatiotietokantajärjestelmiä objektiivisista ja subjektiivisista syistä. Tällaisen siirtymisen helpottaminen sallii objektin lisäksi myös relaatiokomponentin sisällyttämisen OODBMS:ään. Lisäksi MMD tulisi ottaa käyttöön OODBMS:ssä muodostamaan tietovaraston OLAP-järjestelmät, joille on käytännössä yhä enemmän kysyntää.

Peruskonseptit

Määritelmä 1

Olio suuntautunut malli tietojen esitys mahdollistaa yksittäisten tietokantatietueiden tunnistamisen.

Tietokantatietueet ja niiden käsittelytoiminnot yhdistetään vastaavilla olioohjelmointikielillä toteutettujen työkalujen kanssa.

Määritelmä 2

Graafinen esitys Oliopohjaisen tietokannan rakenne on puu, jonka solmut edustavat objekteja.

Vakiotyyppi (esimerkiksi merkkijono - merkkijono) tai käyttäjän luoma tyyppi ( luokkaa), kuvailee kohteen ominaisuuksia.

Kuvassa 1 LIBRARY-objekti on CATALOG-, SUBSCRIBER- ja ISSUES-luokkien ilmentymäobjektien vanhempi. Eri KIRJA-tyypin objekteilla voi olla yksi tai eri vanhemmat. BOOK-tyyppisillä objekteilla, joilla on sama vanhempi, täytyy olla vähintään eri varastonumerot (ainutlaatuiset jokaiselle kirjan kopiolle), mutta samat omaisuusarvot kirjoittaja, otsikko, udk ja isbn.

Olio- ja hierarkkisen tietokannan loogiset rakenteet ovat ulkoisesti samanlaisia. Ne eroavat pääasiassa tietojenkäsittelymenetelmistä.

Suorittaessaan toimenpiteitä datalle oliomallissa käytetään loogisia operaatioita, joita tehostavat kapselointi, periytyminen ja polymorfismi. Tietyin rajoituksin voit käyttää SQL-komentojen kaltaisia ​​toimintoja (esimerkiksi tietokantaa luotaessa).

Tietokantaa luotaessa ja muokattaessa muodostetaan automaattisesti indeksit (indeksitaulukot), jotka myöhemmin korjataan, jotka sisältävät tietoa nopeaa tiedonhakua varten.

Määritelmä 3

Kohde kapselointi– ominaisuuden nimen laajuuden rajoittaminen sen kohteen rajoihin, jossa se on määritelty.

Jos esimerkiksi CATALOG-objektiin lisätään ominaisuus, joka määrittää tekijän puhelinnumeron ja jolla on nimi puhelin, niin CATALOG- ja SUBSCRIBER-objekteille saadaan samannimiset ominaisuudet. Ominaisuuden merkitys määräytyy sen kohteen mukaan, johon se on kapseloitu.

Määritelmä 4

Perintö, kapseloinnin käänteinen, on vastuussa omaisuuden laajuuden laajentamisesta kaikkiin kohteen jälkeläisiin.

Esimerkiksi kaikille KIRJA-objekteille, jotka ovat CATALOG-objektin jälkeläisiä, voidaan määrittää pääobjektin ominaisuudet: kirjoittaja, otsikko, udk ja isbn.

Jos periytymismekanismin toiminta on tarpeen laajentaa esineisiin, jotka eivät ole välittömiä sukulaisia ​​(esimerkiksi saman vanhemman kahdelle jälkeläiselle), niiden yhteisessä esi-isässä määritetään tyyppinen abstrakti ominaisuus. abs.

Ominaisuudet siis huone ja lippu LIBRARY-objektissa olevat aliobjektit LENDING, BOOK ja SUBSCRIBER ovat perineet. Siksi tämän ominaisuuden arvot SUBSCRIBER- ja ISSUANCE-luokissa ovat samat - 00015 (kuva 1).

Määritelmä 5

Polymorfismi mahdollistaa saman ohjelmakoodin työskentelyn heterogeenisten tietojen kanssa.

Toisin sanoen se myöntää esineissä eri tyyppejä on menetelmiä (funktioita tai menettelyjä) kanssa samat nimet.

Hae oliotietokannassa on määrittää samankaltaisuus käyttäjän määrittämän objektin ja tietokantaan tallennettujen objektien välillä.

Oliomallin edut ja haitat

Main etu olio-tietomalli toisin kuin relaatiomalli, on kyky näyttää tietoa objektien monimutkaisista suhteista. Tarkastelun tietomallin avulla voidaan määrittää erillinen sisäänkäynti DB ja sen käsittelyn toiminnot.

TO puutteita oliomalliin kuuluu suuri käsitteellinen monimutkaisuus, hankala tietojenkäsittely ja alhainen kyselyn suoritusnopeus.

Tähän mennessä tällaiset järjestelmät ovat melko yleisiä. Näitä ovat DBMS:

  • postgres,
  • Orion,
  • iiris,
  • ODBJupiter,
  • Versant,
  • Objektiivisuus/DB,
  • esinekauppa,
  • staattinen,
  • jalokivi
  • g pohja.

Objektisuuntautunut tietomalli

Esine- relaatiomalli tiedot

Muut datamallit

Tietokantasovellusten monimutkaistuminen ja relaatiomallin rajoitukset johtivat Codd-mallin kehittämiseen, ĸᴏᴛᴏᴩᴏᴇ ns. laajennettu relaatiomalli, ja kehittyi myöhemmin objekti-relaatiotietomalliksi. Näihin malleihin perustuvat tietokannat luokitellaan yleensä III-sukupolviksi.

Oliorelaatiotietomalli (ORDM) on toteutettu relaatiotaulukoiden avulla, mutta se sisältää objekteja, kuten olio-ohjelmoinnin objektikäsite. ORMD käyttää sellaisia ​​oliokomponentteja kuten käyttäjän määrittämiä tietotyyppejä, kapselointia, polymorfiaa, periytymistä, menetelmän ohittamista jne.

Valitettavasti kehittäjät eivät ole toistaiseksi päässeet yksimielisyyteen siitä, mitä ORMD:n pitäisi tarjota. Vuonna 1999 ᴦ. SQL-99-standardi otettiin käyttöön, ja vuonna 2003 ᴦ. Tämän standardin toinen julkaisu on julkaistu, nimeltään SQL-3, joka määrittelee ORMD:n pääominaisuudet. Mutta toistaiseksi objekti-relaatiomallit ovat tukeneet eri valmistajilta DBMS-järjestelmät eroavat merkittävästi toisistaan. Tämän suunnan näkymistä todistaa se, että johtavat DBMS-valmistajat, mukaan lukien Oracle, Informix, INGRES jne., ovat laajentaneet tuotteidensa ominaisuudet oliorelaatiotietokantajärjestelmään (ORDBMS).

Useimmissa ORMD:n toteutuksissa aggregaatti ja taulukko (relaatio), jotka voivat olla osa toista taulukkoa, tunnistetaan objekteiksi. Tietojenkäsittelymenetelmät esitetään tallennettuina proseduureina ja triggereinä, jotka ovat tietokannan proseduuriobjekteja ja liittyvät taulukoihin. Käsitteellisellä tasolla kaikki objekti-relaatiotietokannan tiedot esitetään suhteina, ja ORDBMS tukee SQL-kieltä.

Toinen tapa rakentaa tietokantaa on käyttää oliopohjaista tietomallia (OODM). Tietomallinnus OOMD:ssä perustuu objektin käsitteeseen. OOMD:tä käytetään yleensä monimutkaisilla aihealueilla mallintamiseen, joissa relaatiomallin toiminnallisuus ei riitä (esim. suunnitteluautomaatiojärjestelmiin (CAD), julkaisujärjestelmiin jne.).

Luotaessa oliopohjaisia ​​tietokantoja (OODBMS) käytetään erilaisia ​​menetelmiä, nimittäin:

  • upottaminen olio-kielityökaluihin, jotka on suunniteltu toimimaan tietokannan kanssa;
  • laajennus olemassa olevaa kieltä työskennellä tietokantojen kanssa oliofunktioiden avulla;
  • oliopohjaisten toimintokirjastojen luominen tietokannan kanssa työskentelemistä varten;
  • uuden kielen ja uuden oliotietomallin luominen

OOM:n etuja ovat mm laajat mahdollisuudet mallinnus aihealue, ilmeikäs kyselykieli ja korkea suorituskyky. Jokaisella OOMD:n objektilla on yksilöllinen tunniste(OID - objektin tunniste). Haku OID:n avulla on huomattavasti nopeampaa kuin relaatiotaulukon haut.

OOMD:n puutteista on syytä mainita puute yleisesti hyväksytty malli, kokemuksen puute OODB:n luomisesta ja käytöstä, käytön monimutkaisuus ja tietosuojatyökalujen riittämättömyys.

Vuonna 2000 ᴦ. työryhmä ODMG (Objekti Tietokannanhallinta OODBMS-valmistajien muodostama Group on julkaissut seuraavan standardin (ODMG 3.0) OODBMS:lle, joka kuvaa objektimallin, kyselynmäärityskielen, objektikyselykielen sekä C ++-, Smalltalk- ja Java-sidoskielet. ODMG-standardit eivät ole virallisia. ODMG:n lähestymistapa standardointiin on olennaisesti se, että sen jälkeen kun ODMG:n jäsenorganisaatiot ovat hyväksyneet standardin seuraavan version, julkaistaan ​​kirja, joka sisältää standardin tekstin.

Mieti nyt, kuinka tietomallien tuki on toteutettu todellisia järjestelmiä tietokannanhallinta.

Oliopohjainen tietomalli - käsite ja tyypit. Luokituksen "Objektiivinen tietomalli" luokittelu ja ominaisuudet 2017, 2018.

Oliomallissa dataa esitettäessä on mahdollista tunnistaa yksittäisiä tietokantatietueita. Tietueiden ja niiden käsittelytoimintojen välille luodaan suhteita vastaavien olioohjelmointikielten toimintojen kaltaisilla mekanismeilla.

Harkitse yksinkertaistettua mallia oliopohjaisesta tietokannasta. Oliopohjaisen tietokannan rakenne esitetään graafisesti puuna, jonka solmut ovat objekteja. Objektien ominaisuudet kuvataan jollain standardilla tai käyttäjän rakentamalla tyypillä (määritelty luokkana). Tyypin class ominaisuuden arvo on objekti, joka on vastaavan luokan esiintymä. Jokaisen luokan ilmentymäobjektin katsotaan olevan sen objektin ali, jossa se on määritelty ominaisuudeksi. Luokan ilmentymäobjekti kuuluu luokkaansa ja sillä on yksi vanhempi. Yleiset relaatiot tietokannassa muodostavat yhtenäisen objektihierarkian. Esimerkki looginen rakenne olio-tietokantakirjasto on esitetty kuvassa. 2.9. Tässä Library-tyypin objekti on luokkien Tilaaja, Katalogi ja Issue ilmentymäobjektien yläobjekti. Eri Kirja-tyyppisillä objekteilla voi olla samat tai eri vanhemmat. Kirja-tyyppisten objektien, joilla on sama emo, on erotettava vähintään varastonumerolla (ainutlaatuinen jokaiselle kirjainstanssille), mutta niillä on samat isb n , udk, title ja author -arvot.

Oliopohjaisen tietokannan looginen rakenne on ulkoisesti samanlainen kuin hierarkkisen tietokannan rakenne. Suurin ero niiden välillä on tietojenkäsittelymenetelmissä.

Tarkastelun tietokantamallin tiedoille tehtävien toimien suorittamiseksi käytetään loogisia operaatioita, joita tehostavat oliopohjaiset kapselointi-, periytymis- ja polymorfismimekanismit.

Kapselointi rajoittaa ominaisuuden nimen laajuuden objektiin, jossa se on määritelty. Perintö päinvastoin laajentaa omaisuuden soveltamisalan kaikkiin kohteen jälkeläisiin.

Polymorfismi olio-ohjelmointikielissä tarkoittaa saman kykyä ohjelmakoodi työskennellä erityyppisten tietojen kanssa. Toisin sanoen se tarkoittaa, että erityyppisillä objekteilla voi olla menetelmiä (proseduureja tai funktioita) samalla nimellä. Haku oliotietokannasta koostuu yhtäläisyyksien selvittämisestä käyttäjän määrittämän kohteen ja tietokantaan tallennettujen kohteiden välillä.

Oliopohjaisen tietomallin tärkein etu relaatiomalliin verrattuna on kyky näyttää tietoa objektien monimutkaisista suhteista. Oliopohjaisen tietomallin avulla voit tunnistaa yksittäisen tietokantatietueen ja määritellä toiminnot niiden käsittelyä varten.

Oliomallin haittoja ovat suuri käsitteellinen monimutkaisuus, tietojenkäsittelyn haitallisuus ja kyselyn suorittamisen alhainen nopeus.

Oliopohjaisia ​​tietokantajärjestelmiä ovat POET, Jasmine, Versant, O2, ODB - Jupiter, Iris, Orion, Postgres.

Yllä kuvatut MD:hen perustuvat tietokantateknologiat perustuvat staattiseen tiedontallennuskonseptiin, joka keskittyy tietojen mallintamiseen. Kuitenkin uusia teknologian sovellusalueita monimutkaisten, toisiinsa liittyvien tietokantaobjektien kanssa, kuten:

Tietokoneavusteinen suunnittelu;

Automatisoitu tuotanto;

Automatisoitu kehitys ohjelmisto;

Toimistotietojärjestelmät;

Multimediajärjestelmät;

Geotietojärjestelmät;

Kustannusjärjestelmät ja muut - osoittivat staattisen konseptin rajalliset mahdollisuudet kohdemallinnuksen kannalta todellista maailmaa.

Uuden tyyppisissä monimutkaisissa erikoistuneissa tietokantasovelluksissa dynaaminen tiedontallennuskonsepti on tehokas, mikä mahdollistaa tietojen ja näihin tietoihin vaikuttavien prosessien rinnakkaismallinnuksen. Näin voidaan ottaa huomioon aihealueen semantiikka ja siten kuvata näitä sovelluksia parhaiten. Tämä konsepti perustuu oliolähtöiseen lähestymistapaan, jota käytetään laajalti ohjelmistokehityksessä. MD, joka toteuttaa tämä käsite ja perustuu olio-paradigmaan (OOP), kutsuttiin olio-tietomalliksi (OODM).

OOMD:n rakenne perustuu olettamukseen, että aihealue voidaan kuvata objektijoukolla. Jokainen objekti on yksilöllisesti tunnistettavissa oleva kokonaisuus, joka sisältää attribuutteja, jotka kuvaavat "todellisen maailman" objektien tilaa ja niihin liittyviä toimintoja. Objektin nykyistä tilaa kuvaa yksi tai useampi attribuutti, joka voi olla yksinkertainen tai monimutkainen. Yksinkertainen attribuutti voi olla primitiivinen tyyppi(esim. kokonaisluku, merkkijono jne.) ja ota kirjaimellinen arvo. Yhdistelmämäärite voi sisältää kokoelmia ja/tai linkkejä. Linkkiattribuutti edustaa objektien välistä suhdetta.

Objektin tärkein ominaisuus on sen tunnistamisen ainutlaatuisuus. Siksi jokaisella oliojärjestelmässä olevalla objektilla on oltava oma tunniste.

Object Identifier (OID) on tietokannan sisäinen tapa merkitä yksittäisiä objekteja. Käyttäjät, jotka työskentelevät kyselyn tai näkymän valintaikkunatyön parissa, eivät yleensä näe näitä tunnisteita. DBMS itse määrittää ne ja käyttää niitä. Jokaisen DBMS:n tunnisteen semantiikka on erilainen. Se voi olla joko satunnainen arvo tai sisältää tietoja, joita tarvitaan kohteen löytämiseen tietokantatiedostosta, kuten tiedoston sivunumero ja objektin siirtymä sen alusta. Se on tunniste, jota tulisi käyttää viittausten järjestämiseen objektiin.

Kaikki objektit ovat kapseloituja, eli objektin esitys tai sisäinen rakenne jää käyttäjältä piiloon. Sen sijaan käyttäjä tietää vain sen annettu esine voi suorittaa joitain toimintoja. Esimerkiksi WAREHOUSE-objektille voidaan soveltaa menetelmiä, kuten ACCEPT_ITEM, ISSUE_TOBAP jne. Kapseloinnin etuna on, että sen avulla voit muuttaa objektien sisäistä esitystapaa suunnittelematta uudelleen näitä objekteja käyttäviä sovelluksia. Toisin sanoen kapselointi merkitsee tietojen riippumattomuutta.

Objekti kapseloi dataa ja toimintoja (menetelmiä, OOP:n mukaan). Menetelmät määrittelevät objektin käyttäytymisen. Niillä voidaan muuttaa kohteen tilaa muuttamalla sen attribuuttiarvoja tai kysellä valittujen attribuuttien arvoja. Voi olla esimerkiksi tapoja lisätä tietoja uudesta vuokrakohteesta, päivittää työntekijän palkkatietoja tai tulostaa tietoja tietystä tuotteesta.

Objektit, joilla on samat attribuutit ja vastaavat samoihin viesteihin, voidaan ryhmitellä Luokka(kirjallisuudessa termejä "luokka" ja "tyyppi" käytetään usein vaihtokelpoisina). Jokaisella tällaisella luokalla on oma edustajansa - objekti, joka on tietoelementti. Tietyn luokan objekteja kutsutaan kopioita.

Joissakin oliojärjestelmissä luokka on myös objekti ja sillä on omat attribuuttinsa ja menetelmänsä nimeltään luokan attribuutit ja luokkamenetelmät.

OOP:n tärkeitä käsitteitä ovat luokkahierarkia ja säilöhierarkia.

luokkahierarkia tarkoittaa mahdollisuutta, että jokaisella luokalla, jota tässä tapauksessa kutsutaan superluokiksi, on oma alaluokkansa. Esimerkkinä voidaan mainita seuraava ketju: yrityksen kaikki ohjelmoijat ovat sen työntekijöitä, joten jokainen ohjelmoija, joka OODM:n puitteissa on OHJELMOIJA-luokan kohde, hän on myös työntekijä, joka puolestaan , on EMPLOYEES-luokan kohde. Siten PROGRAMMERS olisi alaluokka, STAFF olisi superluokka. Mutta ohjelmoijat voidaan jakaa myös järjestelmä- ja sovellusohjelmoijiksi. Siksi PROGRAMMERS on alaluokkien SIS_PROGRAMMERS ja APPLIC_PROGRAMMERS yläluokka. Jatkamalla tätä ketjua edelleen, saadaan luokkahierarkia, jossa jokainen alaluokkaobjekti perii vastaavan superluokan muuttujien ja menetelmien esiintymät.

On olemassa useita perinnön tyyppejä - yksittäinen, moninkertainen ja valikoiva. Singulaarinen periytyminen tarkoittaa sitä, että alaluokat perivät enintään yhdestä superluokasta. Moniperintö- perintö useammasta kuin yhdestä superluokasta. Selektiivinen periytyminen sallii alaluokan periä rajoitetun määrän ominaisuuksia superluokastaan.

Muuttuvan ilmentymän periytymistä kutsutaan rakenteellinen perintö, menetelmän periytyminen - käyttäytymisperinnöstä, ja kyky käyttää samaa menetelmää eri luokat tai pikemminkin kutsutaan eri menetelmien soveltamista samalla nimellä eri luokkiin polymorfismi.

Oliokeskeisellä arkkitehtuurilla on myös toisenlainen hierarkia - säilöhierarkia. Se koostuu siitä tosiasiasta, että jotkut esineet voivat sisällyttää käsitteellisesti toisiin. OSASTO-luokan objektin on siis sisällettävä julkinen muuttuja HEAD, joka on viittaus osastopäällikköä vastaavaan EMPLOYEE-luokan objektiin, ja sen tulee sisältää myös viittaus joukkoon viittauksia yksikössä työskenteleviä työntekijöitä vastaaviin objekteihin. tämä osasto.

Joissakin oliojärjestelmissä luokka on myös objekti ja sillä on omat attribuuttinsa ja menetelmänsä. Yleispiirteet, yleiset piirteet Luokka kuvataan sen attribuuttien avulla. Objektiluokan menetelmät ovat eräänlainen analogi todellisen maailman esineiden ominaisuuksille. Jokaisella tiettyyn luokkaan kuuluvalla esineellä on nämä ominaisuudet. Siksi, kun objekti luodaan, on tarpeen ilmoittaa luokka, johon se kuuluu, jotta voidaan määrittää sen luontaiset ominaisuudet.

Käyttäjä ja kohde ovat vuorovaikutuksessa viestien kautta. Vastauksena jokaiseen viestiin järjestelmä suorittaa vastaavan menetelmän.

Kaikki objektimallin suhteet tehdään referenssiattribuuttien avulla, jotka yleensä toteutetaan OID:inä.

Relaatiotietokannan suhteita edustavat vastaavat ensisijaiset ja vieraat avaimet. Itse tietokannassa ei ole rakenteita taulukoiden välisten assosiaatioiden muodostamiseksi, vaan linkkejä käytetään tarpeen mukaan taulukoiden yhdistämisessä. Sitä vastoin suhteet ovat oliopohjaisen tietokannan selkäranka, koska jokainen objekti sisältää niiden objektien tunnukset, joihin se liittyy.

OOMD:ssä voidaan toteuttaa paitsi perinteisiä linkkejä myös periytyvistä linkeistä.

Kahdenkeskinen suhde (1:1) Objektien A ja B välillä toteutetaan lisäämällä objektiin B viiteattribuutti objektiin A ja (viittauksen eheyden säilyttämiseksi) objektin A viiteattribuutti objektiin B.

Yksi-moneen suhde (1:M) objektien A ja B välillä toteutetaan lisäämällä viittausattribuutti objektiin B objektiin A ja attribuutti, joka sisältää joukon linkkejä objektiin A, objektiin B (esimerkiksi referenssiattribuutti B (OID2, OID3...) objektiin A ja objektin B esiintymiin, joissa on OID2, OID3, ... viittausattribuutti A lisätään: OID1.

Monelta moneen -suhde (M:N) objektien A ja B välillä on toteutettu lisäämällä jokaiseen objektiin linkkijoukon sisältävä attribuutti.

OODM:ssä voidaan käyttää "koko-osa"-suhdetta, joka kuvaa, että yhden luokan objekti sisältää osinaan muiden luokkien objekteja. Tuotantotietokannan tapauksessa PRODUCT-luokan ja PART- ja ASEMBLY-luokkien välillä olisi "koko osa" -suhde. Tämä yhteys on muunnelma monesta moneen -suhteesta erityisellä semantiikkalla. Koko osan suhde toteutetaan kuten mikä tahansa monista moneen -suhde, jossa on joukko siihen liittyviä objektitunnisteita. Sillä on kuitenkin erilainen semanttinen merkitys, toisin kuin tavanomaisella monesta moneen -suhteella.

Koska olio-paradigma tukee periytymistä, on mahdollista käyttää "on"-suhdetta ja "laajentaa"-suhdetta OODM:ssä. "On"-suhde, joka tunnetaan myös nimellä yleistys-erikoistuminen -suhde, luo periytymishierarkian, jossa alaluokat ovat superluokkien erikoistapauksia. Tämä sallii olla kuvaamatta uudelleen perittyjä ominaisuuksia. "Extends"-suhdetta käytettäessä alaluokka laajentaa superluokan toimivuutta sen sijaan, että se rajoittuisi sen erikoistapaukseen.

Tarkastellaanpa, kuinka sellaiset komponentit kuin eheysrajoitukset ja datan operaatiot toteutetaan OOMD:ssä.

Näiden komponenttien ominaisuudet määräytyvät mallin erityispiirteiden mukaan. Tämän OOMD:n spesifisyyden sanelevat ensisijaisesti sellaiset sisäiset käsitteet kuin objektien kapselointi, eli sisäisen rakenteen salaisuus, pääsy dataan vain etukäteen määriteltyjen menetelmien kautta, luokkahierarkia ja konttihierarkia.

OOMD:n erityispiirteet määräytyvät myös kohteen erityispiirteiden mukaan. Se ilmenee tarpeessa ryhmitellä objektit luokkiin. Jokainen objekti sisältyy tehtävästä riippuen johonkin luokkaan ja yksi kohde voi kuulua useaan luokkaan kerralla (esimerkiksi OHJELMOIJAT ja KORKEAN PAKKAAT perheet). Toinen objektin erityispiirre on, että se voi "juoksua" luokasta (alaluokasta) toiseen. Siten JÄRJESTELMÄOHJELMOIJASTA voi lopulta tulla SOVELLETTTU OHJELMOIJA. Siten luokkahierarkia ei ole analoginen hierarkkisen mallin kanssa, kuten se saattaa näyttää aiemmin, vaan edellyttää, että järjestelmä pystyy muuttamaan jokaisen objektin sijaintia luokkahierarkiassa, esimerkiksi siirtymään "ylös" tai "alas" sisällä. annettua hierarkiaa. Mutta monimutkaisempi prosessi on myös mahdollinen - järjestelmän on tarjottava objektille mahdollisuus kiinnittää (irrottaa) mielivaltaiseen hierarkian huipulle milloin tahansa.

Tärkeä rooli OOMD:ssä linkkien eheyden rajoitukset toimivat. Jotta linkit toimisivat oliopohjaisessa DM:ssä, linkin molemmilla puolilla olevien objektitunnisteiden on vastattava toisiaan. Jos esimerkiksi TYÖNTEKIJÖIDEN ja HIEN LAPSIEN välillä on yhteys, täytyy olla jokin takuu siitä, että kun lasta kuvaava objekti lisätään työntekijää edustavaan objektiin, työntekijän tunnus lisätään vastaavaan objektiin. Tällainen linkin eheys, joka on jossain määrin analoginen relaatiotietomallin viiteeheyden kanssa, muodostetaan käyttämällä palautetta. Linkkien eheyden varmistamiseksi suunnittelijalla on erityinen syntaksi, jota tarvitaan objektin käänteisen tunnuksen sijainnin määrittämiseen. Suunnittelijan vastuulla on asettaa rajoituksia suhteiden eheydelle (samoin kuin viiteeheydelle relaatiotietokannassa).

OOMD:ssä sekä tietojen kuvaus että niiden käsittely tapahtuu käyttämällä samaa oliopohjaista proseduurikieltä.

ODMG (Object Database Management Group) käsittelee objektitietokantojen tekniikan standardointiongelmia. Se on kehittänyt objektimallin (ODMG 2.0 otettiin käyttöön syyskuussa 1997), joka määrittelee vakiomallin tietokantaobjektien semantiikkaa varten. Tämä malli on tärkeä, koska se määrittelee sisäänrakennetun semantiikan, jonka oliopohjainen DBMS (OODBMS) ymmärtää ja voi toteuttaa. Tätä semantiikkaa käyttävien kirjastojen ja sovellusten rakenteen on oltava siirrettävissä erilaisten OODBMS:ien kesken, jotka tukevat annettua objektitietomallia. ODMG-arkkitehtuurin pääkomponentit ovat: Object Model (OM), Object Definition Language (ODL), Object Query Language (OQL) ja kyky linkittää C++:aan, Javaan ja Smalltalkiin.

Objekti malli ODMG 2.0 -standardin mukaisille tiedoille on tunnusomaista seuraavat ominaisuudet:

Perusrakennuspalikoita ovat esineet ja literaalit. Jokaisella esineellä on yksilöllinen tunniste. Literaalilla ei ole omaa tunnistetta, eikä se voi olla olemassa erikseen objektina. Literaalit on aina upotettu objekteihin, eikä niihin voi viitata erikseen.

Objektit ja literaalit vaihtelevat tyypeittäin. Jokaisella tyypillä on oma verkkotunnus, jakaa kaikki objektit ja literaalit tämän tyyppistä. Tyypeillä voi myös olla käyttäytymistä. Jos tyypillä on jokin käyttäytyminen, kaikilla tämän tyypin objekteilla on sama käyttäytyminen. Käytännössä tyyppi voi olla luokka, josta objekti luodaan, käyttöliittymä tai yksinkertainen tietotyyppi (kuten kokonaisluku). Objektia voidaan pitää tyypin esiintymänä;

Objektin tila määritellään nykyisten arvojen joukolla, joka on toteutettu ominaisuuksien joukolla. Nämä ominaisuudet voivat olla kohteen attribuutteja tai objektin ja yhden tai useamman muun objektin välisiä suhteita;

Objektin käyttäytyminen määritellään joukolla toimintoja, jotka voidaan suorittaa objektille tai itse objektille. Toiminnoilla voi olla luettelo tulo- ja lähtöparametreista, ja jokainen niistä on tiukka tiettyä tyyppiä. Jokainen operaatio voi myös palauttaa kirjoitetun tuloksen;

Tietokannan määritys tallennetaan määrittelykielellä kirjoitettuun skeemaan Esine Määritelmäkieli (ODL). Tietokanta tallentaa objektit, jolloin ne voidaan jakaa eri käyttäjien ja sovellusten kesken.

OODM:ään perustuvia tietokantajärjestelmiä kutsutaan oliopohjaisiksi DBMS:iksi (OODBMS). Näitä DBMS-järjestelmiä kutsutaan 3. sukupolven DBMS:iksi* (* Tiedontallennusmallien kehityshistoria jakautuu usein kolmeen vaiheeseen (sukupolveen): ensimmäinen sukupolvi (1960-luvun loppu - 70-luvun alku) - hierarkkinen ja verkkomalli; toinen sukupolvi (noin 1970-1980-luvut) - relaatiomalli; kolmas sukupolvi (1980-luku - 2000-luvun alku) - oliomallit.).

Nykyään oliopohjaisia ​​tietokantoja käytetään useissa organisaatioissa monenlaisten ongelmien ratkaisemiseen. Tietotekniikkatiedon alalla kertyneen kokemuksen analysointi ja yleistäminen mahdollisti sovelluksia, joissa oliotietokantojen käyttö on perusteltua:

Sovellus koostuu suuri numero vuorovaikutuksessa olevia osia. Jokaisella heistä on oma käyttäytymisensä, joka riippuu muiden käyttäytymisestä;

Järjestelmän tulee käsitellä suuria määriä strukturoimatonta tai monimutkainen rakenne tiedot;

Sovellus käyttää tietoja ennustettavalla tavalla, joten oliopohjaisen tietokannan navigointi ei ole sitä merkittävä haitta;

Suunnittelemattomien pyyntöjen tarve on rajallinen;

Tallennetun tiedon rakenne on hierarkkinen tai luonteeltaan vastaava.

V tällä hetkellä Ohjelmistomarkkinoilla on monia oliopohjaisia ​​DBMS-järjestelmiä. Taulukossa. 10.6 näyttää osan kaupalliset järjestelmät tästä luokasta.

Taulukko 10.6

Nykyaikainen kaupallinen OODBMS,

niiden valmistusyritykset ja sovellusalueet

Yksi perustavanlaatuisia eroja Objektitietokannat relaatiosta on kyky luoda ja käyttää uusia tietotyyppejä. Tärkeä ominaisuus OODBMS on, että uuden tyypin luominen ei vaadi perusytimen muokkaamista ja perustuu olioohjelmoinnin periaatteisiin.

OODBMS-ydin on optimoitu toimintoihin objektien kanssa. Sen luonnolliset toiminnot ovat objektien välimuisti, objektien versiointi ja tiettyjen objektien käyttöoikeuksien erottaminen. OODBMS:lle on ominaista parempi suorituskyky toiminnoissa, jotka vaativat pääsyä ja hakemista objekteihin pakattuun dataan verrattuna relaatiotietokantajärjestelmä, jolle tarve valita yhdistettyjä tietoja johtaa sisäisiin lisätoimintoihin.

OODBMS:n kannalta erittäin tärkeää on kyky siirtää objekteja tietokannasta toiseen.

Kun luodaan erilaisia ​​OODBMS-pohjaisia ​​sovelluksia, tietyn DBMS:n sisäänrakennettu luokkarakenne on tärkeä. Luokkakirjasto ei yleensä tue vain kaikkea vakiotyypit dataa, mutta myös laajennettu joukko multimediaa ja muita monimutkaisia ​​tietotyyppejä, kuten video, ääni, animaatiokehysten sarja. Joissakin OODBMS:issä on luotu luokkakirjastoja, jotka mahdollistavat dokumenttitiedon tallennuksen ja kokotekstihaun (esim. Jasmine, ODB-Jupiter). Esimerkki perusrakenne luokat on esitetty kuvassa. 10.17.

Pääaseman siinä on TOdbObject-luokka, joka sisältää kaikki tarvittavat ominaisuudet ja menetelmät tietokantaan pääsyn hallitsemiseksi ja indeksoinnin suorittamiseksi. Kaikki muut luokat ohittavat sen menetelmät ja lisäävät toteuttamansa tyypin validoinnin ja tietyn indeksoijan.

Kuten kuvasta näkyy. 10.17, rakenteessa on erilaisia ​​dokumenttitietojen käsittelyyn keskittyviä luokkia - TOdbText, TOdbDocument, TODBTextDocument jne. Jokaista dokumenttia edustaa erillinen objekti. Näin asiakirjojen säilyttämisen luonnollisuus varmistetaan. Yksi tärkeimmistä toiminnoista on asiakirjojen etsiminen pyynnöstä. Useimmissa luokissa kyky etsiä objekteja tietyn avaimen arvon perusteella on toteutettu. TOdbText-luokassa kyky muodostaa hakulauseke luonnollisella kielellä kirjoitetulla lauseella.

TOdbDocument-luokka on erityinen, ja se voi sisältää erityyppisiä objekteja. Se koostuu kentistä, joilla jokaisella on nimi ja joka liittyy tietyntyyppiseen objektiin. Tämän luokan läsnäolo antaa käyttäjälle mahdollisuuden laajentaa tyyppijoukkoa. Muokkaamalla säiliöobjektia (asiakirjaa), voit asettaa tietyn joukon kenttiä ja saada uusi tyyppi Asiakirja.

ODB-Jupiterin pohjalta OODBMS-kehittäjät ovat luoneet monipuolisen tiedonhakujärjestelmän ODB-Text, jossa on universaali tallennettujen tietojen rakenne ja tehokas hakumekanismi. ODB-Text-järjestelmä on työkalu asiakirjojen kollektiiviseen käsittelyyn ja yritysarkiston ylläpitoon. Joukossa mahdollisia sovelluksia mainitaanpa nykyaikaisen toimiston työnkulun kirjanpidon automatisointi, viite- ja tietojärjestelmien rakentaminen (tuotettujen lakitietokantojen tapaan), verkkotietokantojen ylläpito, henkilöstötietueet, bibliografia jne.

41. Sovelletun IS:n suunnitteluominaisuudet. IS-kehityksen vaiheet. (Aihe 11, s. 100-103).

11.1.3. Sovelletun IC:n järjestelmäsuunnittelun ominaisuudet

Rakentaessa (valittaessa, mukautettaessa) tietojärjestelmä voidaan käyttää kahta pääkäsitettä, kahta päälähestymistapaa (kolmas käsite on niiden yhdistelmä):

1. Orientoituminen ongelmiin, jotka on ratkaistava tämän tietojärjestelmän avulla, ts. ongelmalähtöinen lähestymistapa (tai induktiivinen lähestymistapa);

2. keskittyä teknologiaan, joka on saatavilla (päivitetty) tietyssä järjestelmässä, ympäristössä, ts. teknologialähtöinen lähestymistapa (tai deduktiivinen lähestymistapa).

Konseptin valinta riippuu strategisista (taktisista) ja (tai) pitkän aikavälin (lyhyen aikavälin) kriteereistä, ongelmista, resursseista.

Jos ensin tutkitaan olemassa olevan teknologian kykyjä ja sitten selvitetään todelliset ongelmat, jotka niiden avulla voidaan ratkaista, niin on turvauduttava teknologialähtöiseen lähestymistapaan.

Jos todelliset ongelmat tunnistetaan ensin ja sitten otetaan käyttöön ongelmien ratkaisemiseen riittävä tekniikka, on turvauduttava ongelmalähtöiseen lähestymistapaan.

Samanaikaisesti molemmat tietojärjestelmän rakentamisen käsitteet ovat riippuvaisia ​​toisistaan: uusien teknologioiden käyttöönotto muuttaa ratkaistavia ongelmia, ja ratkaistavien ongelmien muuttaminen johtaa tarpeeseen ottaa käyttöön uusia teknologioita; Molemmat vaikuttavat tehtäviin päätöksiin.

Minkä tahansa sovelletun (yrityksen) tietojärjestelmän järjestelmän suunnittelun (kehityksen) ja käytön tulee käydä läpi seuraava tietojärjestelmän elinkaari:

- esiprojektianalyysi (kokemus muiden vastaavien järjestelmien luomisesta, prototyypeistä, kehitettävän järjestelmän eroista ja ominaisuuksista jne.), järjestelmän ulkoisten ilmentymien analysointi;

– järjestelmän sisäinen analyysi, sisäinen analyysi(järjestelmän osajärjestelmien analyysi);

- järjestelmän (morfologinen) kuvaus (esitys) systeemistä (järjestelmän tavoitteen kuvaus, järjestelmäsuhteet ja yhteydet ympäristöön, muut järjestelmät ja järjestelmäresurssit- materiaali-, energia-, informaatio-, organisatorinen, inhimillinen, tilallinen ja ajallinen);

– riittävyyttä, tehokkuutta ja kestävyyttä (luotettavuutta) koskevien kriteerien määrittäminen;

– järjestelmän osajärjestelmien toiminnallinen kuvaus (mallien kuvaus, osajärjestelmien toiminnan algoritmit);

- järjestelmän prototyyppi (prototyyppikuvaus), järjestelmän osajärjestelmien vuorovaikutuksen arviointi (layout-kehitys - alijärjestelmien toteutus yksinkertaistetuilla toiminnalliset kuvaukset, menettelyt ja näiden mallien vuorovaikutuksen testaus järjestelmän tavoitteen saavuttamiseksi), kun taas on mahdollista käyttää riittävyyden, kestävyyden ja tehokkuuden kriteerien "malleja";

- "kokoonpano" ja järjestelmän testaus - täysimittaisen täytäntöönpanon toiminnalliset osajärjestelmät ja kriteerit, mallin arviointi muotoiltujen kriteerien mukaan;

– järjestelmän toiminta;

– tavoitteiden määrittely edelleen kehittäminen järjestelmä ja sen sovellukset;

- järjestelmän ylläpito - järjestelmän kykyjen selkeyttäminen, muuttaminen, laajentaminen sen toimintatavassa (sen evoluutiota varten).

Nämä ovat tietojärjestelmien uudelleensuunnittelun tärkeimmät vaiheet.

Yritystietojärjestelmän kehittäminen tehdään pääsääntöisesti tarkasti määritellylle yritykselle. Yrityksen aihetoiminnan ominaisuudet vaikuttavat tietysti tietojärjestelmän rakenteeseen. Mutta samaan aikaan eri yritysten rakenteet ovat yleensä samankaltaisia. Jokainen organisaatio, riippumatta sen toiminnan tyypistä, koostuu useista osastoista, jotka suorittavat suoraan yrityksen yhden tai toisen tyyppistä toimintaa. Ja tämä tilanne koskee lähes kaikkia organisaatioita riippumatta siitä, minkä tyyppistä toimintaa ne harjoittavat.

Siten mitä tahansa organisaatiota voidaan pitää vuorovaikutteisten elementtien (alaosastojen) sarjana, joista jokaisella voi olla oma, melko monimutkainen rakenne. Myös osastojen väliset suhteet ovat varsin monimutkaiset. Yleisesti ottaen liiketoimintayksiköiden välillä on kolmenlaisia ​​linkkejä:

Toiminnalliset linkit - jokainen divisioona suorittaa tietyntyyppisiä töitä yhdessä liiketoimintaprosessissa;

Tietolinkit- jaostot vaihtavat tietoja (asiakirjat, faksit, kirjalliset ja suulliset määräykset jne.);

Ulkosuhteet - joidenkin yksiköiden kanssa on vuorovaikutusta ulkoiset järjestelmät, ja niiden vuorovaikutus voi myös olla sekä informatiivista että toiminnallista.

Eri yritysten rakenteiden yhtenäisyys mahdollistaa yhteisten periaatteiden muotoilun yritysten tietojärjestelmien rakentamiseen.

Yleisesti ottaen tietojärjestelmän kehittämisprosessia voidaan tarkastella kahdesta näkökulmasta:

Ajan tai vaiheiden mukaan elinkaari kehitteillä olevaa järjestelmää. V Tämä tapaus ottaa huomioon kehitysprosessin dynaamisen organisoinnin, joka kuvataan syklien, vaiheiden, iteraatioiden ja vaiheiden avulla.

Yritystietojärjestelmää kehitetään projektina. Monet projektinhallinnan ja projektin kehitysvaiheiden (elinkaarivaiheiden) piirteet ovat yhteisiä, eivätkä ne riipu pelkästään aihealueesta, vaan myös projektin luonteesta (ei väliä onko kyseessä suunnitteluprojekti vai taloudellinen hanke). ). Siksi on järkevää harkita ensin sarjaa yleisiä kysymyksiä projektinhallinta.

Projekti on ajallisesti rajoitettu määrätietoinen muutos erillinen järjestelmä alun perin selkeästi määritellyillä tavoitteilla, joiden saavuttaminen ratkaisee projektin valmistumisen, sekä vahvistetut vaatimukset aikatauluihin, tuloksiin, riskeihin, kustannusten ja resurssien kohdentamiseen sekä organisaatiorakenteeseen.

Yleensä monimutkaiselle konseptille (joka on erityisesti hankkeen käsite) on vaikea antaa yksiselitteistä muotoilua, joka kattaa täysin kaikki esitellyn konseptin piirteet. Siksi yllä oleva määritelmä ei väitä olevansa ainutlaatuinen ja täydellinen.

Projektin hallintaobjektina voidaan erottaa seuraavat pääpiirteet:

Vaihtuvuus - järjestelmän määrätietoinen siirto olemassa olevasta johonkin

haluttu tila, joka on kuvattu projektin tavoitteiden kannalta;

Lopullisen tavoitteen rajoitus;

rajoitettu kesto;

Rajoitettu budjetti;

Tarvitaan rajalliset resurssit;

Uutuus yritykselle, jota varten hanketta toteutetaan;

Monimutkaisuus - suuren määrän tekijöitä, jotka vaikuttavat suoraan tai epäsuorasti hankkeen edistymiseen ja tuloksiin;

Laillinen ja organisaatiotuki- erityisen organisaatiorakenteen luominen hankkeen ajaksi.

Työn tehokkuus saavutetaan projektin toteutusprosessin ohjauksella, joka varmistaa resurssien allokoinnin, suoritettavan työjärjestyksen koordinoinnin sekä sisäisten ja ulkoisten häiriöiden kompensoinnin.

Ohjausjärjestelmien teorian näkökulmasta projektin ohjausobjektina tulee olla havainnoitavissa ja hallittavissa, eli erotetaan joitain piirteitä, joilla projektin etenemistä voidaan jatkuvasti seurata (havainnointiominaisuus). Lisäksi tarvitaan mekanismeja, jotka vaikuttavat oikea-aikaisesti hankkeen toteuttamisen kulkuun (hallittavuusominaisuus).

Ohjattavuusominaisuus on erityisen tärkeä aihealueen epävarmuuden ja vaihtelevuuden olosuhteissa, jotka usein liittyvät tietojärjestelmien kehittämishankkeisiin.

Jokainen projekti, riippumatta sen toteuttamiseen tarvittavan työn monimutkaisuudesta ja määrästä, käy läpi tietyt kehitysvaiheet: tilasta, jolloin "projektia ei vielä ole" tilaan, jolloin "hanketta ei enää ole". Kehitysvaiheiden joukko idean syntymisestä projektin täydelliseen valmistumiseen jaetaan yleensä vaiheisiin (vaiheet, vaiheet).

Vaiheiden lukumäärän ja niiden sisällön määrittämisessä on joitain eroja, koska nämä ominaisuudet riippuvat suurelta osin tietyn hankkeen toteuttamisen edellytyksistä ja pääosallistujien kokemuksista. Tietojärjestelmän kehittämisprosessin logiikka ja pääsisältö ovat kuitenkin lähes kaikissa tapauksissa yhteisiä.

Tietojärjestelmän kehittämisessä voidaan erottaa seuraavat vaiheet:

käsitteen muodostuminen;

Teknisten eritelmien kehittäminen;

Design;

Valmistus;

Järjestelmän käyttöönotto.

Tarkastellaan jokaista niistä yksityiskohtaisemmin. Toista ja osittain kolmatta vaihetta kutsutaan yleensä järjestelmän suunnitteluvaiheiksi, ja kaksi viimeistä (joskus sisältää suunnitteluvaiheen) ovat toteutusvaiheita.

Konseptivaihe

Ideoiden muodostaminen, tavoitteiden asettaminen;

Keskeisen projektiryhmän muodostaminen;

Asiakkaan ja muiden osallistujien motivaation ja vaatimusten tutkiminen;

Lähtötietojen kerääminen ja nykyisen tilan analysointi;

Perusvaatimusten ja rajoitusten määrittely, tarvittavat aineelliset, taloudelliset ja työvoimaresurssit;

Vaihtoehtojen vertaileva arviointi;

Ehdotusten jättäminen, tarkastelu ja hyväksyminen.

Teknisen ehdotuksen laatiminen

Hankkeen pääsisällön, hankkeen perusrakenteen kehittäminen;

Toimeksiantojen laatiminen ja hyväksyminen;

Suunnittelu, hankkeen perusrakennemallin purkaminen;

Hankkeen arvioiden ja budjettien laatiminen, resurssien tarpeen määrittäminen;

Kehitys kalenterisuunnitelmat ja laajennetut työaikataulut;

Sopimuksen allekirjoittaminen asiakkaan kanssa;

Hankkeen osallistujien viestintävälineiden käyttöönotto ja työn edistymisen valvonta.

Design

Tässä vaiheessa määritetään eniten osajärjestelmät ja niiden väliset liitännät tehokkaita tapoja projektin toteuttaminen ja resurssien käyttö. Tunnusomaisia ​​teoksia tämä vaihe:

Perusasioiden suorittaminen suunnittelutyötä;

Yksityisyyden kehittäminen tehtävänkuvaus;

Konseptisuunnittelun toteuttaminen;

Luonnos tekniset tiedot ja ohjeet;

Suunnittelun esittely, tarkastus ja hyväksyntä.

Kehitys

Tässä vaiheessa toteutetaan projektin työn koordinointi ja toiminnanohjaus, osajärjestelmiä valmistetaan, yhdistetään ja testataan. Pääsisältö:

Ohjelmistokehitystyön suorittaminen;

Valmistelut järjestelmän käyttöönottoa varten;

Hankkeen pääindikaattoreiden valvonta ja säätely.

Järjestelmän käyttöönotto

Tässä vaiheessa suoritetaan testejä, järjestelmän koekäyttöä todellisissa olosuhteissa, käydään neuvotteluja projektin tuloksista ja mahdollisista uusista sopimuksista. Tärkeimmät työtyypit:

Monimutkaiset testit;

42. IP:n elinkaaren käsite. (Aihe 11, s. 103-105).

Aiheeseen liittyvät julkaisut: