Tietokannan kehittämisen päävaiheet. Tietokannan kehittämisen vaiheet

Tietokannan suunnittelu

Tietokannan suunnitteluvaiheet:

1. Järjestelmäanalyysi ja sanallinen kuvaus aihealueen tietoobjekteista ja niiden välisistä suhteista.

2. Semanttinen toimialueen mallinnus on alueobjektien osittain formalisoitu kuvaus jollakin semanttisella mallilla, esimerkiksi ER-mallilla.

3. Vakiotietokantajärjestelmän valinta.

4. Tietokannan looginen suunnittelu eli tietokannan kuvaus hyväksytyn tietomallin mukaisesti. Tässä vaiheessa määritetään taulukoiden lukumäärä ja rakenne, muodostetaan tietokantakyselyitä, määritetään raportointiasiakirjojen tyypit, kehitetään tietojenkäsittelyalgoritmeja, luodaan lomakkeita tietojen syöttämiseen ja muokkaamiseen jne.

5. Tietokannan fyysinen suunnittelu, eli tietokannan tehokkaan sijoittamisen valinta ulkoisille tietovälineille parhaan mahdollisen suorituskyvyn varmistamiseksi tietojenkäsittelyssä.

4.2 Entiteetti-suhdemalli (ER-malli)

Essence on jokin todellisen maailman esine, joka voi olla olemassa itsenäisesti. entiteetillä on tapauksia, jotka eroavat toisistaan attribuuttiarvoissa ja mahdollistavat yksiselitteisen tunnistamisen. Attribuutti on kokonaisuuden nimetty ominaisuus. Esimerkiksi kokonaisuus Kirja tunnusomaisia määritteitä, kuten tekijä, nimi, kustantaja jne. Konkreettiset kirjat ovat kokonaisuuksia Kirja. Ne eroavat määritettyjen attribuuttien arvoista, ja ne tunnistetaan yksilöllisesti "nimi"-attribuutilla. Kutsutaan attribuutti, joka yksilöi entiteetin esiintymät avain. Avain voi olla komposiitti A, joka edustaa useiden attribuuttien yhdistelmää.

Oletetaan, että tietokanta suunnitellaan aihealueelle PANKKI. Sillä on johtajien johtamia sivuliikkeitä. Asiakkailla on erityyppisiä tilejä: nykyiset, kiireelliset, pyynnöstä jne., jotka käsitellään konttoreissa. Aihealueella voidaan erottaa neljä kokonaisuutta: sivuliike, johtaja, tili, asiakas.

ER-kaaviossa entiteetti on kuvattu suorakulmiona, jossa sen nimi on merkitty, esimerkiksi:

Yhteys edustaa entiteettien välistä vuorovaikutusta. Se on karakterisoitu teho (liitäntäaste), joka näyttää kuinka monta kokonaisuutta suhteeseen liittyy. Kahden entiteetin välistä suhdetta kutsutaan binääri. ER-kaaviossa suhdetta edustaa timantti, esimerkiksi:

PANKKI-aihealueella on 3 linkkiä:

1. Toimialan johtaja

2. Sivukonttorin käsittelylasku

3. Asiakkaalla on tili

Viestinnän tärkeä ominaisuus on yhteystyyppi (monikertaisuus). Harkitse yllä olevien linkkien tyyppejä. Koska yksi johtaja hallinnoi vain yhtä haaraa, ensimmäinen suhde on yksi-yhteen (1:1) -tyyppinen.

Koska yksi haara käsittelee useita tilejä ja jokaista tiliä käsittelee vain yksi haara, toinen suhde on tyyppiä yksi moneen (1:M).

Koska useat asiakkaat voivat jakaa yhden tilin ja yhdellä asiakkaalla voi olla useita tilejä, kolmas suhde on tyyppiä useista moneen (M:N).

Osallistumisaste määrittää, osallistuvatko kaikki vai vain jotkin kokonaisuuden esiintymät suhteeseen. Hän voi olla pakollinen tai valinnainen.

Jos kaikki entiteetin A esiintymät eivät liity mihinkään entiteetin B esiintymään, entiteetin A osallistumisaste on valinnainen. Tämä on kuvattu ER-kaaviossa mustalla ympyrällä, joka on sijoitettu linkkiviivalle kohteen A lähellä.

Jos jokainen entiteetin A esiintymä liittyy mihin tahansa entiteetin B esiintymään, entiteetin A osallistumisaste on pakollinen. Tässä tapauksessa ER-kaaviossa linkkiviivalla oleva musta ympyrä sijoitetaan suorakulmioon entiteetin A viereen. Esimerkiksi linkki Työntekijät rekisteröivät asiakkaita on tyyppi (1:M). Samanaikaisesti kaikki työntekijät eivät rekisteröi asiakkaita (valinnainen osallistuminen), vaan jokainen asiakas rekisteröi työntekijä (pakollinen osallistuminen):

Oletetaan, että tarkasteltavalla aihealueella PANKKI kaikkien neljän kokonaisuuden osallistumisaste on pakollinen. Sitten ER-malli näyttää tältä:

Jokainen neljästä mallientiteetistä voidaan kuvata omilla attribuuttijoukollaan.

ER-malli yhdessä entiteettiattribuuttijoukkojen kanssa voi toimia esimerkkinä semanttisesta (käsitteellisestä) toimialueen mallista tai käsitteellisestä tietokantaskeemasta.

Tietokantaa kehitettäessä voidaan erottaa seuraavat työn vaiheet.

lavastan. Ongelman muotoilu.

Tässä vaiheessa muodostetaan tehtävä tietokannan luomisesta. Siinä kuvataan yksityiskohtaisesti tietokannan koostumus, luomisen tarkoitus ja tarkoitus sekä luetellaan, minkä tyyppisiä töitä tässä tietokannassa on tarkoitus tehdä (valinta, lisäys, tietojen muokkaaminen, raportin tulostaminen tai tulostaminen jne. .).

II vaihe. Objektianalyysi.

Tässä vaiheessa pohditaan, mistä objekteista tietokanta voi koostua, mitkä ovat näiden objektien ominaisuudet. Kun tietokanta on jaettu erillisiin objekteihin, on tarpeen ottaa huomioon kunkin kohteen ominaisuudet, eli toisin sanoen selvittää, mitkä parametrit kuvaavat kutakin objektia. Kaikki nämä tiedot voidaan järjestää erillisiksi tietueiksi ja taulukoiksi. Seuraavaksi sinun on harkittava kunkin yksittäisen tietueyksikön tietotyyppiä. Tiedot tietotyypeistä tulee myös syöttää koottavaan taulukkoon.

III vaihe. Mallin synteesi.

Tässä vaiheessa yllä olevan analyysin mukaan on tarpeen valita tietty tietokantamalli. Lisäksi kunkin mallin edut ja haitat tarkastellaan ja verrataan luodun tietokannan vaatimuksiin ja tehtäviin. Tällaisen analyysin jälkeen valitaan malli, joka voi maksimoida tehtävän toteutuksen. Mallin valinnan jälkeen on tarpeen piirtää sen kaavio, joka osoittaa taulukoiden tai solmujen väliset suhteet.

IV vaihe. Tietojen esittämistapojen ja ohjelmistotyökalujen valinta.

Mallin luomisen jälkeen on valitusta ohjelmistotuotteesta riippuen määritettävä tiedon esitysmuoto.

Useimmissa DBMS-järjestelmissä tiedot voidaan tallentaa kahdessa muodossa:

käyttämällä lomakkeita;

käyttämättä lomakkeita.

Lomake on käyttäjän luoma graafinen käyttöliittymä tietojen syöttämiseksi tietokantaan.

V vaihe. Kohteen tietokonemallin synteesi.

Tietokonemallin luomisprosessissa voidaan erottaa joitain DBMS:lle tyypillisiä vaiheita.

Vaihe 1. DBMS:n käynnistäminen, uuden tietokantatiedoston luominen tai aiemmin luodun tietokannan avaaminen.

Vaihe 2. Alkutaulukon tai -taulukoiden luominen.

Kun luot lähdetaulukkoa, sinun on määritettävä kunkin kentän nimi ja tyyppi. Kenttien nimiä ei saa toistaa samassa taulukossa. Tietokannan kanssa työskentelyn aikana voit täydentää taulukkoa uusilla kentillä. Luotu taulukko on tallennettava antamalla sille luotavassa tietokannassa ainutlaatuinen nimi.

1. Taulukon tietoja ei saa toistaa. Pöytien välillä ei saa olla toistoa. Kun tietyt tiedot on tallennettu vain yhteen taulukkoon, niitä tarvitsee muuttaa vain yhdessä paikassa. Tämä tehostaa työskentelyä ja eliminoi myös tiedon epäyhdenmukaisuuden eri taulukoissa. Esimerkiksi yhdessä taulukossa tulee olla asiakkaiden osoitteet ja puhelinnumerot.
2. Jokaisessa taulukossa tulee olla tietoa vain yhdestä aiheesta. Kunkin aiheen tiedot käsitellään paljon helpommin, jos ne sisältyvät itsenäisiin taulukoihin. Esimerkiksi osoitteet ja asiakastilaukset on parempi tallentaa erillisiin taulukoihin, jotta tilauksen poistamisen jälkeen asiakastiedot jäävät tietokantaan.
3. Jokaisen taulukon tulee sisältää vaaditut kentät. Taulukon jokaisen kentän tulee sisältää erilliset tiedot taulukon aiheesta. Esimerkiksi asiakastietotaulukko voi sisältää kenttiä, joissa on yrityksen nimi, osoite, kaupunki, maa ja puhelinnumero. Kun suunnittelet kunkin taulukon kenttiä, muista, että jokainen kenttä on liitettävä taulukon aiheeseen. Ei ole suositeltavaa sisällyttää taulukkoon tietoja, jotka ovat lausekkeen tulosta. Taulukon tulee sisältää kaikki tarvittavat tiedot. Tiedot tulee jakaa pienimpiin loogisiin yksiköihin (esimerkiksi kentät "Etunimi" ja "Sukunimi", ei yleiskenttä "Etunimi").
4. Tietokannassa on oltava ensisijainen avain. Tämä on tarpeen, jotta DBMS voi linkittää tietoja eri taulukoista, esimerkiksi tietoja asiakkaasta ja hänen tilauksistaan.

Vaihe 3. Näyttömuotojen luominen.

Aluksi sinun on määritettävä taulukko, jonka perusteella lomake luodaan. Se voidaan luoda ohjatun lomakkeen avulla määrittämällä, mikä muoto sillä tulisi olla, tai itsenäisesti. Lomaketta luotaessa et voi määrittää kaikkia taulukon sisältämiä kenttiä, vaan vain osan niistä. Lomakkeen nimi voi olla sama kuin sen taulukon nimi, johon se luotiin. Yhden taulukon perusteella voit luoda useita lomakkeita, jotka voivat poiketa tästä taulukosta käytettävien kenttien tyypistä tai lukumäärästä. Kun lomake on luotu, se on tallennettava. Luotua lomaketta voi muokata muuttamalla kenttien sijaintia, kokoa ja muotoa.

Vaihe 4. Tietokannan täyttö.

Tietokannan täyttöprosessi voidaan suorittaa kahdessa muodossa: taulukon muodossa ja lomakkeen muodossa. Numero- ja tekstikentät voidaan täyttää taulukkona, kun taas MEMO- ja OLE-kentät voidaan täyttää lomakkeena.

VI vaihe. Työskentely luodun tietokannan kanssa.

Työskentely tietokannan kanssa sisältää seuraavat vaiheet:

etsi tarvittavat tiedot;

tietojen lajittelu;

tietojen valinta;

printata;

tietojen muuttaminen ja lisääminen.

Automaattisten tietokantojen nykyaikaisten tietojärjestelmien luominen ja käyttöönotto tuo uusia suunnittelutehtäviä, joita ei voida ratkaista perinteisillä menetelmillä ja menetelmillä. Tietokantojen suunnitteluun tulee kiinnittää paljon huomiota. Tietokannan suunnittelun onnistumisesta riippuu koko järjestelmän toiminnan tehokkuus, elinkelpoisuus sekä laajennus- ja jatkokehitysmahdollisuus. Siksi tietokantasuunnittelukysymys nostetaan esiin erillisenä, itsenäisenä työalueena tietojärjestelmien kehittämisessä.

Tietokannan suunnittelu -- tämä on iteratiivinen, monivaiheinen prosessi, jossa tehdään tietoisia päätöksiä prosessissa, jossa analysoidaan aihealueen tietomallia, sovellusohjelmoijien ja käyttäjien tietovaatimuksia, syntetisoidaan loogisia ja fyysisiä tietorakenteita, analysoidaan ja perustellaan ohjelmiston valintaa ja laitteisto. Tietokannan suunnitteluvaiheet liittyvät tiedon monitasoiseen organisointiin. Ottaen huomioon tietokannan suunnittelun, noudatamme tällaista monitasoista dataesitystä: ulkoinen, infologinen, looginen (dataloginen) ja sisäinen.

Tämä tietokerrosten esitys ei ole ainoa. On muitakin vaihtoehtoja kerrostetun tiedon esittämiseen. Joten American National Standards Instituten ANSI / X3 / SPARC:n tiedonhallintajärjestelmiä käsittelevän tutkimusryhmän sekä CODASYLin (Conference on Data Systems Languages) ehdotusten mukaisesti erotetaan yleensä kolme tiedon esitystasoa. :

· ulkoinen taso (loppukäyttäjän ja sovellusohjelmoijan näkökulmasta),
· käsitteellinen taso (DBMS:n näkökulmasta),
· sisätilat tasolla (järjestelmän ohjelmoijan näkökulmasta).

Tämän konseptin mukaisesti ulkoinen kerros on osa (alajoukko) käsitteellisessä mallissa, joka on välttämätön minkä tahansa pyynnön tai sovellusohjelman toteuttamiseksi. Eli jos käsitteellinen malli toimii tietyn DBMS:n tukemana skeemana, ulkoinen taso on tietty joukko alijärjestelmiä, jotka ovat tarpeen tietyn sovellusohjelman tai käyttäjäpyynnön toteuttamiseksi.

On myös toinen näkökulma, jonka mukaan ulkoisella tasolla ymmärretään yleisempiä käsitteitä, jotka liittyvät aihealueen tietovirtojen ja niiden jäsentämisen tutkimiseen ja analysointiin. Jotkut kirjoittajat ottavat käyttöön aputason (välitason ulkoisen ja datalogisen tason välillä), jota kutsutaan infologiseksi. Se voi toimia itsenäisenä tai kiinteänä osana ulkoista tasoa.

Tällainen käsite on tarkoituksenmukaisempi tietokannan suunnitteluprosessin ymmärtämisen kannalta. Siksi pidämme infologista tasoa itsenäisenä tiedon esittämisen tasona. Ulkoinen taso toimii tässä tapauksessa erillisenä suunnitteluvaiheena, jossa tutkitaan kaikkea ei-koneista tietotukea eli datan dokumentoinnin ja esittämisen muotoja sekä ulkoista ympäristöä, jossa tietopankki tulee toimimaan menetelmin. tietojen korjaamiseen, keräämiseen ja siirtämiseen tietokantaan.

Tietokantaa suunniteltaessa ulkoisella tasolla on tarpeen tutkia sen ohjausobjektin toimintaa, jota varten tietokanta suunnitellaan, kaikki ensisijainen ja lähtödokumentaatio sen määrittämiseksi, millaista tietoa tietokantaan pitää tallentaa. Ulkoinen taso on pääsääntöisesti sanallinen kuvaus tulo- ja lähtöviesteistä sekä tiedoista, jotka on suositeltavaa tallentaa tietokantaan. Ulkoisen tason kuvaus ei sulje pois päällekkäisyyttä, redundanssia ja tietojen epäjohdonmukaisuutta. Siksi näiden poikkeavuuksien ja ristiriitojen poistamiseksi tietojen ulkoisesta kuvauksesta suoritetaan infologinen suunnittelu.

Infologinen malli on keino strukturoida aihealuetta ja ymmärtää datasemantiikan käsite. Infologista mallia voidaan pitää lähinnä keinona dokumentoida ja jäsentää tiedontarpeiden esitysmuotoa, mikä varmistaa johdonmukaisen viestinnän käyttäjien ja järjestelmäkehittäjien välillä.

Kaikki ulkoiset esitykset integroidaan infologisella tasolla, jossa muodostetaan infologinen (kanoninen) tietomalli, joka ei ole pelkkä ulkoisten dataesitysten summa.

Infologinen taso on aihealueen tieto-looginen malli (ILM), josta tiedon redundanssi on poissuljettu ja ohjausobjektin tietoominaisuudet näytetään ottamatta huomioon tietyn DBMS:n ominaisuuksia ja erityispiirteitä. Toisin sanoen tiedon infologinen esittäminen keskittyy pääasiassa henkilöön, joka suunnittelee tai käyttää tietokantaa.

Looginen (käsitteellinen) taso on rakennettu ottaen huomioon tietyn DBMS:n erityispiirteet ja ominaisuudet. Tämän tasoinen tietojen esitys on keskittynyt enemmän tietokonekäsittelyyn ja ohjelmoijiin, jotka ovat mukana sen kehittämisessä. Tällä tasolla muodostuu käsitteellinen tietomalli, eli aihealueen strukturoitu malli erityisellä tavalla, joka täyttää valitun DBMS:n ominaisuudet ja rajoitukset. Tietyn DBMS:n tukemaa loogisen tason mallia kutsutaan myös datalogiseksi.

Infologiset ja datalogiset mallit, jotka näyttävät yhden aihealueen mallin, ovat riippuvaisia toisistaan. Infologinen malli voidaan helposti muuntaa datalogiseksi malliksi.

sisäinen taso liittyvät tietojen fyysiseen sijaintiin tietokoneen muistissa. Tällä tasolla muodostetaan tietokannasta fyysinen malli, joka sisältää rakenteita tietojen tallentamiseksi tietokoneen muistiin, mm. tietuemuotojen kuvaus, niiden looginen tai fyysinen järjestysjärjestys, laitetyypeittäin järjestys sekä tiedon ominaisuudet ja tavat. Fyysisen mallin parametreistä riippuvat seuraavat tietokannan toiminnan ominaisuudet: muistin määrä ja järjestelmän vasteaika. Tietokannan fyysisiä parametreja voidaan muuttaa sen toiminnan aikana järjestelmän tehokkuuden parantamiseksi. Fyysisten parametrien muuttaminen ei edellytä tarvetta muuttaa infologisia ja datalogisia malleja. Tietokannan tietojen esitystasojen keskinäinen suhdekaavio on esitetty kuvassa 1.1. Tietokanta suunnitellaan näiden tasojen mukaisesti. Tietokannan suunnittelu on monimutkainen ja aikaa vievä prosessi, joka vaatii useiden erittäin pätevien asiantuntijoiden osallistumista. Tietojärjestelmän suorituskyky ja käyttäjien ja sovellusohjelmien toiminnallisten tarpeiden täyttäminen riippuvat siitä, kuinka hyvin tietokanta on suunniteltu. Huonosti suunniteltu tietokanta voi monimutkaistaa kehitysprosessia

sovellusohjelmistot, vaativat monimutkaisemman logiikan käyttöä, mikä puolestaan lisää järjestelmän vasteaikaa ja voi tulevaisuudessa johtaa tarpeeseen suunnitella uudelleen loogista tietokantamallia. Tietokannan loogisen mallin uudelleenjärjestely tai muutosten tekeminen on erittäin ei-toivottu prosessi, koska se aiheuttaa tarpeen muokata tai jopa ohjelmoida yksittäisiä tehtäviä. Kaikki kussakin suunnitteluvaiheessa tehtävä työ on integroitava tietosanakirjaan. Jokaista suunnitteluvaihetta pidetään tiettynä iteratiivisena prosessina, jonka tuloksena muodostuu tietty tietokantamalli.

Riisi. 1.1.

Ulkoinen taso on infologisen suunnittelun valmisteluvaihe.

Ulkoisen tason suunnittelun tarkoituksena on kehittää ei-koneellista tiedon tukea, joka sisältää tiettyä aihealuetta kuvaavan syöttö- (ensisijaisen) dokumentaation järjestelmän, teknisen ja taloudellisen tiedon luokittelu- ja koodausjärjestelmän sekä luettelon. asiaankuuluvista lähtöviesteistä, jotka on luotava BnD:n avulla.

On olemassa kaksi lähestymistapaa tietokantojen suunnitteluun ulkoisella tasolla: "aihealueelta" ja "kyselystä". Lähestymistapa "ainealueelta" muodostuu siitä, että ulkoinen tietotuki koko oppiainealueelle muodostetaan ottamatta huomioon käyttäjien ja sovellusohjelmien tarpeita. Joskus tätä lähestymistapaa kutsutaan myös objekti- tai ei-prosessilähestymistapaksi.

"Pyynnöstä" -lähestymistavassa pääasiallinen tietolähde aihealueesta on käyttäjien pyyntöjen ja sovellusohjelmien tarpeiden tutkiminen. Tätä lähestymistapaa kutsutaan myös prosessi- tai toiminnalliseksi lähestymistavaksi. Tällä lähestymistavalla tietokanta on suunniteltu suorittamaan nykyiset hallintatehtävät ottamatta huomioon mahdollisuutta järjestelmän laajentamiseen ja uusien hallintatehtävien syntymiseen. Lähestymistavan "aihealueelta" etuna on sen objektiivisuus, johdonmukaisuus ohjelmistojen näyttämisessä ja tietomallin vakaus, kyky toteuttaa suuri määrä sovellusohjelmia ja kyselyitä, myös tietokannan luomisen yhteydessä suunnittelemattomia. Tämän lähestymistavan haittapuolena on huomattava työmäärä, joka on tehtävä tietokantaan tallennettavien tietojen määrittämiseksi, mikä näin ollen monimutkaistaa ja lisää projektin kehitysaikaa.

Toiminnallinen lähestymistapa keskittyy käyttäjien ja sovellusten tämänhetkisten vaatimusten toteuttamiseen ottamatta huomioon järjestelmän kehitysnäkymiä. Sitä käytettäessä voi olla vaikeaa yhdistää eri käyttäjien ja sovellusten vaatimuksia. Tämä lähestymistapa vähentää kuitenkin merkittävästi suunnittelun monimutkaisuutta, ja siksi on mahdollista luoda järjestelmä, jolla on korkea suorituskyky. Erikseen otettuna mikään näistä menetelmistä ei kuitenkaan voi tarjota tarpeeksi tietoa järkevän tietokantarakenteen suunnittelemiseksi. Siksi tietokantaa suunniteltaessa on suositeltavaa käyttää näitä kahta lähestymistapaa yhdessä. Jos edustamme kaavamaisesti tietokannan suunnitteluprosessia ulkoisella tasolla, niin se koostuu tällaisista töistä.

1. Ainealueen toiminnallisten tehtävien määrittely, jotka ovat automatisoidun ratkaisun alaisia. Koska tietokannan luomisen päätarkoituksena on tarjota tietoa tietojenkäsittelytoimintoja varten, on ensinnäkin tarpeen tutkia kaikki sen aihealueen (ohjausobjektin) toiminnot, jota varten tietokantaa kehitetään, ja analysoida niitä. ominaisuudet. Ohjausobjektin toimintoja ja toiminnallisia ominaisuuksia tulee tutkia läheisessä yhteydessä tietojärjestelmän tulevien käyttäjien tietojen toiminnallisten vaatimusten tutkimiseen. Tutkimukseen ja analysointiin kuuluu tiedontarpeiden tunnistaminen ja tietovirtojen määrittäminen. Nämä työt voidaan suorittaa kartoittamalla aihealue ja kyselemällä sen työntekijöitä. Tällaisen tutkimuksen tuloksena voi olla luettelo toiminnallisista tehtävistä, jotka tulisi ratkaista automatisoidusti tietokannan avulla.
2. Operatiivisten perusasiakirjojen tutkiminen ja analysointi. Tutkittuaan toiminnot ja määritellyt luettelon toiminnallisista tehtävistä, jotka ovat automatisoidun ratkaisun alaisia, he jatkavat kunkin tehtävän tai niiden kompleksin syötteessä käytettävien operatiivisten asiakirjojen tutkimista. Tutkittuaan ja analysoituaan kaikki operatiiviset asiakirjat (sekä ulkoiset että sisäiset), joita käytetään kunkin tehtävän syötössä, he määrittävät, mitkä tiedot näistä asiakirjoista on tallennettava tietokantaan.
3. Sääntely- ja viiteasiakirjojen tutkiminen. Kolmannessa vaiheessa he tutkivat ja analysoivat kaikkia säädöksiä ja viiteasiakirjoja. Tällaista dokumentaatiota ovat erilaiset luokittelijat, arviot, sopimukset, määräykset, veropolitiikkaa koskevat säädökset, suunnitteluasiakirjat jne. Käyttö- ja referenssitiedon jakelu ja erillinen analysointi on teknologisesti ehdollista. Tietokannat eroavat toisistaan tekniikoiden suhteen, joilla luodaan ja ylläpidetään viitedokumentaatioon sijoitettuja puolipysyviä tietoja ja käyttötietotiedostoja.
4. Syöttöviestien muunnosprosessien tutkiminen tulosviesteiksi.

Ensinnäkin kaikki tulostetut viestit, jotka tulostetaan tai näytetään näytöllä, tutkitaan ja tallennetaan tulostusmatriiseina DM:ään. Tämä on tarpeen sen määrittämiseksi, mitkä syöttöviestien attribuutit on tallennettava tietokantaan lähtöviestien vastaanottamiseksi. Lisäksi tässä vaiheessa määritetään ne indikaattorit, jotka saadaan ongelman ratkaisun aikana tiettyjen laskelmien suorittamisen seurauksena. Jokaiselle laskennalliselle indikaattorille on määritettävä sen muodostamisen algoritmi ja varmistettava, että tämä indikaattori voidaan saada toisessa ja kolmannessa vaiheessa määritettyjen toiminta- ja vertailutietojen ominaisuuksien perusteella. Jos tietyt tiedot eivät riitä laskelmien suorittamiseen, on palattava takaisin, suoritettava lisätutkimuksia ja

määrittää, mistä ja miten saada puuttuvat attribuutit. Lisäksi on tarpeen päättää, mitkä lasketuista indikaattoreista on suositeltavaa tallentaa tietokantaan. Laskemalla saatuja indikaattoreita ei pääsääntöisesti tallenneta tietokantaan. Poikkeuksena ovat tapaukset, joissa laskettua tunnuslukua on käytettävä muiden tehtävien ratkaisemiseen tai tähän tehtävään, mutta seuraavina kalenterijaksoina.

Suunnittelutyötä suoritettaessa ulkoisella tasolla on otettava huomioon, että tiettyjen toimintojen suorittamiseksi tietokannassa on tarpeen tallentaa lisätietoja, joita ei näytetä asiakirjoissa (kalenteritiedot, tilastotiedot jne.) . Yleinen kaavio asiakirjojen ja tietojen tutkimisprosessista ulkoisella suunnittelulla on esitetty kuvassa 1.2.

Kuva 1.2.

Tällainen tutkimus on tehtävä jokaiselle toiminnalliselle tehtävälle tai niiden kompleksille, joka ratkaistaan tietokannan avulla.

Ulkoisen tason suunnittelun tuloksena tulee luettelo tietokantaan tallennettavien toiminnallisten ja ehdollisesti pysyvien tietojen attribuuteista (yksityiskohdista), josta käy ilmi niiden vastaanottolähteet ja esitystapa.

Tämä luettelo ei kuitenkaan sulje pois redundanssin, päällekkäisyyden, epäjohdonmukaisuuden ja muiden sen puutteiden mahdollisuutta. Siksi prosessi ei pääty tähän, vaan siirtyminen infologisen suunnittelun vaiheeseen suoritetaan.

Tietokantaa kehitettäessä voidaan erottaa seuraavat työn vaiheet.

lavastan. Ongelman muotoilu.

II vaihe. Objektianalyysi.

III vaihe. Mallin synteesi.

IV vaihe. Tietojen esittämistapojen ja ohjelmistotyökalujen valinta.

Mallin luomisen jälkeen on valitusta ohjelmistotuotteesta riippuen määritettävä tiedon esitysmuoto.

Useimmissa DBMS-järjestelmissä tiedot voidaan tallentaa kahdessa muodossa:

käyttämällä lomakkeita;
käyttämättä lomakkeita.

Lomake on käyttäjän luoma graafinen käyttöliittymä tietojen syöttämiseen tietokantaan.

V vaihe. Kohteen tietokonemallin synteesi.

Tietokonemallin luomisprosessissa voidaan erottaa joitain DBMS:lle tyypillisiä vaiheita.

Vaihe 1 DBMS:n käynnistäminen, uuden tietokantatiedoston luominen tai aiemmin luodun tietokannan avaaminen.

Vaihe 2 Luo lähdetaulukko tai -taulukot.

1. Taulukon tietoja ei saa toistaa. Pöytien välillä ei saa olla toistoa. Kun tietyt tiedot on tallennettu vain yhteen taulukkoon, niitä tarvitsee muuttaa vain yhdessä paikassa. Tämä tehostaa työskentelyä ja eliminoi myös tiedon epäyhdenmukaisuuden eri taulukoissa. Esimerkiksi yhdessä taulukossa tulee olla asiakkaiden osoitteet ja puhelinnumerot.

2. Jokaisessa taulukossa tulee olla tietoa vain yhdestä aiheesta. Kunkin aiheen tiedot käsitellään paljon helpommin, jos ne sisältyvät itsenäisiin taulukoihin. Esimerkiksi osoitteet ja asiakastilaukset on parempi tallentaa erillisiin taulukoihin, jotta tilauksen poistamisen jälkeen asiakastiedot jäävät tietokantaan.

3. Jokaisen taulukon tulee sisältää vaaditut kentät. Taulukon jokaisen kentän tulee sisältää erilliset tiedot taulukon aiheesta. Esimerkiksi asiakastietotaulukko voi sisältää kenttiä, joissa on yrityksen nimi, osoite, kaupunki, maa ja puhelinnumero. Kun suunnittelet kunkin taulukon kenttiä, muista, että jokainen kenttä on liitettävä taulukon aiheeseen. Ei ole suositeltavaa sisällyttää taulukkoon tietoja, jotka ovat lausekkeen tulosta. Taulukon tulee sisältää kaikki tarvittavat tiedot. Tiedot tulee jakaa pienimpiin loogisiin yksiköihin (esimerkiksi kentät "Etunimi" ja "Sukunimi", ei yleiskenttä "Etunimi").

4. Tietokannassa on oltava ensisijainen avain. Tämä on tarpeen, jotta DBMS voi linkittää tietoja eri taulukoista, esimerkiksi tietoja asiakkaasta ja hänen tilauksistaan.

Vaihe 3 Näyttömuotojen luominen.

Vaihe 4 Tietokannan täyttäminen.

VI vaihe. Työskentely luodun tietokannan kanssa.

Työskentely tietokannan kanssa sisältää seuraavat vaiheet:

etsi tarvittavat tiedot;
tietojen lajittelu;
tietojen valinta;
printata;
tietojen muuttaminen ja lisääminen.

Tietokantasuunnittelun (DB) – kuten myös minkä tahansa muun suunnitteluprosessin – ydin on luoda kuvaus uudesta järjestelmästä, jota ei aiemmin ollut tässä muodossa ja joka toteutettuaan pystyy oletettavasti toimimaan asianmukaisissa olosuhteissa. Tästä seuraa, että tietokannan suunnittelun vaiheiden tulee johdonmukaisesti ja loogisesti heijastaa tämän prosessin ydintä.

Tietokannan suunnittelun sisältö ja vaiheet

Suunnitteluidea perustuu johonkin muotoiltuun sosiaaliseen tarpeeseen. Tällä tarpeella on ympäristö sen esiintymiselle ja kuluttajien kohderyhmä, joka käyttää suunnittelun tulosta. Siksi tietokannan suunnitteluprosessi alkaa tarkastelemalla tiettyä tarvetta asiakkaiden ja sen aiotun sijainnin toimintaympäristön näkökulmasta. Eli ensimmäinen vaihe on tiedon kerääminen ja järjestelmän aihealueen mallin määrittely sekä sen tarkastelu kohdeyleisön näkökulmasta. Yleensä järjestelmän vaatimusten määrittämiseksi määritetään toimintojen laajuus sekä tietokantasovellusten rajat.

Lisäksi suunnittelija, jolla on jo tiettyjä ideoita siitä, mitä hänen tarvitsee luoda, selventää sovelluksen oletettavasti ratkaisemia tehtäviä, muodostaa niistä luettelon (varsinkin jos suunnittelukehityksessä on suuri ja monimutkainen tietokanta), selventää ratkaisujen järjestystä. ongelmia ja analysoi tiedot. Tällainen prosessi on myös vaiheittainen suunnittelutyö, mutta yleensä suunnittelurakenteessa nämä vaiheet imeytyvät konseptisuunnitteluvaiheeseen - objektien, attribuuttien, suhteiden valintavaiheeseen.

Konseptuaalisen (tietomallin) luomiseen kuuluu käyttäjien käsitteellisten vaatimusten alustava muotoilu, mukaan lukien vaatimukset sovelluksille, joita ei välttämättä heti toteuteta, mutta joiden huomioiminen parantaa järjestelmän toimivuutta tulevaisuudessa. Käsittelemällä joukon objektiabstrahojen esityksiä (täsmentämättä fyysisen varastoinnin menetelmiä) ja niiden suhteita, käsitteellinen malli vastaa toimialuemallin sisältöä. Siksi kirjallisuudessa tietokannan suunnittelun ensimmäistä vaihetta kutsutaan infologiseksi suunnitteluksi.

Seuraavaksi erillistä vaihetta (tai lisäystä edelliseen) seuraa toimintaympäristön vaatimusten muodostusvaihe, jossa arvioidaan järjestelmän toiminnan mahdollistavien laskentaresurssien vaatimuksia. Vastaavasti, mitä suurempi suunniteltava tietokanta on, mitä suurempi on käyttäjän aktiivisuus ja pyyntöjen intensiteetti, sitä korkeammat resurssit ovat: tietokoneen konfiguraatiolle, käyttöjärjestelmän tyypille ja versiolle. Esimerkiksi tulevan tietokannan monen käyttäjän toiminta edellyttää verkkoyhteyttä, jossa käytetään moniajoon soveltuvaa käyttöjärjestelmää.

Seuraavaksi suunnittelijan on valittava tietokannan hallintajärjestelmä (DBMS) sekä ohjelmistotyökalut. Tämän jälkeen käsitteellinen malli on siirrettävä valitun ohjausjärjestelmän kanssa yhteensopivaan tietomalliin. Mutta usein tämä liittyy käsitteelliseen malliin tehtyjen muutosten ja muutosten tekemiseen, koska käsitteellisen mallin heijastamia objektien suhteita toisiinsa ei aina voida toteuttaa tämän DBMS:n avulla.

Tämä seikka määrää seuraavan vaiheen syntymisen - tietyn DBMS-tuetun käsitteellisen mallin syntymisen. Tämä vaihe vastaa loogisen suunnittelun vaihetta (loogisen mallin luomista).

Lopuksi tietokannan suunnittelun viimeinen vaihe on fyysinen suunnittelu - vaihe, jossa looginen rakenne ja fyysinen tallennusympäristö yhdistetään.

Siten suunnittelun päävaiheet yksityiskohtaisessa muodossa edustavat vaiheet:

infologinen suunnittelu,
toimintaympäristön vaatimusten muodostus
ohjausjärjestelmän ja tietokantaohjelmiston valinta,
looginen suunnittelu,
fyysinen suunnittelu

Keskeisimmistä käsitellään tarkemmin alla.

infologinen suunnittelu

Entiteettien tunnistaminen on infologisen suunnittelun semanttinen perusta. Entiteetti on tässä sellainen objekti (abstrakti tai konkreettinen), josta tietoa kertyy järjestelmään. Aihealueen infologisessa mallissa kuvataan käyttäjäystävällisin termein, jotka eivät riipu tietokannan erityisestä toteutuksesta, aihealueen rakennetta ja dynaamisia ominaisuuksia. Mutta termit otetaan tyypillisessä mittakaavassa. Eli kuvausta ei ilmaista aihealueen yksittäisten kohteiden ja niiden suhteiden kautta, vaan:

kuvaus objektityypeistä,
kuvattuun tyyppiin liittyvät eheysrajoitukset,
prosessit, jotka johtavat aihealueen kehitykseen - sen siirtymiseen toiseen tilaan.

Infologinen malli voidaan luoda useilla menetelmillä ja lähestymistavoilla:

Toiminnallinen lähestymistapa perustuu asetettuihin tehtäviin. Sitä kutsutaan toiminnalliseksi, koska sitä käytetään, jos tunnetaan niiden henkilöiden toiminnot ja tehtävät, jotka suunnitellun tietokannan avulla palvelevat tietotarpeitaan.
Aihelähestymistapa keskittyy tietoihin tietokantaan tulevasta tiedosta huolimatta siitä, että kyselyiden rakennetta ei ehkä voida määrittää. Tässä tapauksessa aihealueen tutkimuksessa heitä ohjaa sen asianmukaisin näyttö tietokannassa oleettujen tietopyyntöjen kokonaisuuden yhteydessä.
Integroitu lähestymistapa, joka perustuu "entiteetti-suhde" -menetelmään, yhdistää kahden edellisen edut. Menetelmä rajoittuu koko aihealueen jakamiseen paikallisiin osiin, jotka mallinnetaan erikseen ja yhdistetään sitten uudelleen yhdeksi alueeksi.

Koska kokonaisuus-relaatiomenetelmän käyttö on tässä vaiheessa yhdistetty suunnittelumenetelmä, siitä tulee muita useammin prioriteetti.

Paikallisissa edustustoissa menetelmällisen erottelun yhteydessä tulee mahdollisuuksien mukaan sisältää tietoa, joka riittäisi ratkaisemaan erillinen ongelma tai täyttämään jonkin potentiaalisen käyttäjäryhmän tarpeet. Jokainen näistä alueista sisältää noin 6-7 entiteettiä ja vastaa mitä tahansa erillistä ulkoista sovellusta.

Entiteettien riippuvuus näkyy niiden jakautumisessa vahvoihin (perus, emo) ja heikkoihin (lapsi). Vahva kokonaisuus (esimerkiksi lukija kirjastossa) voi olla tietokannassa yksinään, kun taas heikko entiteetti (esimerkiksi tämän lukijan tilaus) on "liitetty" vahvaan, eikä sitä ole olemassa erikseen.

On tarpeen erottaa käsitteet "entiteettiinstanssi" (objekti, jolle on ominaista tietyt ominaisuusarvot) ja käsite "entiteettityyppi" - objekti, jolle on ominaista yleinen nimi ja ominaisuusluettelo.

Kullekin yksittäiselle entiteetille valitaan attribuutit (ominaisuusjoukko), jotka voivat kriteerin mukaan olla:

tunnistava (ainutlaatuinen arvo tämän tyyppisille entiteeteille, mikä tekee niistä mahdollisia avaimia) tai kuvaava;
yksiarvoinen tai moniarvoinen (asianmukaisella määrällä arvoja entiteettiinstanssille);
perus (muista attribuuteista riippumaton) tai johdannaiset (laskettu muiden attribuuttien arvojen perusteella);
yksinkertainen (jakamaton yksikomponenttinen) tai komposiitti (yhdistetty useista komponenteista).

Tämän jälkeen suoritetaan attribuutin määrittely, linkkien määrittely paikallisessa edustuksessa (jaettu valinnaisiin ja pakollisiin) ja paikallisedustustojen yhdistäminen, jotka voidaan yhdistää 4-5 paikalliseen alueeseen. askel. Lukumäärän kasvaessa alueiden binäärinen yhdistäminen tapahtuu useissa vaiheissa.

Tämän ja muiden välivaiheiden aikana heijastuu suunnittelun iteratiivisuus, joka ilmenee tässä siinä, että ristiriitojen eliminoimiseksi on palattava paikallisrepresentaatioiden mallintamisen vaiheeseen selkeyttä ja muutosta varten (esim. muuttaa semanttisesti erilaisten objektien samoja nimiä tai sopia samojen attribuuttien eheysattribuuteista eri sovelluksissa).

Ohjausjärjestelmän ja tietokantaohjelmiston valinta

Tietojärjestelmän käytännön toteutus riippuu tietokannan hallintajärjestelmän valinnasta. Valintaprosessin tärkeimmät kriteerit ovat parametrit:

tietomallin tyyppi ja sen vastaavuus aihealueen tarpeisiin,
mahdollisuusmarginaali tietojärjestelmän laajentamisen yhteydessä,
valitun järjestelmän suorituskykyominaisuudet,
DBMS:n toimintavarmuus ja käyttömukavuus,
tietohallintohenkilöstölle suunnattu työkalu,
itse DBMS:n ja lisäohjelmistojen kustannukset.

Virheet DBMS:n valinnassa aiheuttavat lähes varmasti tarpeen muuttaa käsitteellisiä ja loogisia malleja myöhemmin.

Looginen tietokannan suunnittelu

Tietokannan loogisen rakenteen tulee vastata aihealueen loogista mallia ja ottaa huomioon tietomallin suhde tuettuun DBMS-järjestelmään. Siksi vaihe alkaa tietomallin valinnalla, jossa on tärkeää ottaa huomioon sen yksinkertaisuus ja selkeys.

Luonnollinen tietorakenne mieluiten vastaa sitä edustavaa mallia. Joten esimerkiksi jos tiedot esitetään hierarkkisen rakenteen muodossa, on parempi valita hierarkkinen malli. Käytännössä tällaisen valinnan määrää kuitenkin useammin tietokannan hallintajärjestelmä, ei tietomalli. Siksi käsitteellinen malli itse asiassa käännetään tietomalliksi, joka on yhteensopiva valitun tietokannan hallintajärjestelmän kanssa.

Tässäkin heijastuu suunnittelun luonne, joka mahdollistaa mahdollisuuden (tai tarpeen) palata käsitteelliseen malliin sen muuttamiseksi, jos siellä heijastuvia objektien (tai objektien attribuuttien) välisiä suhteita ei voida toteuttaa suunnittelun keinoin. valittu DBMS.

Vaiheen päätyttyä tulee luoda tietokantaskeemat molemmista arkkitehtuurin tasoista (käsitteellinen ja ulkoinen), jotka on luotava valitun DBMS:n tukemalla tiedonmäärityskielellä.

Tietokantaskeemat luodaan käyttämällä yhtä kahdesta erilaisesta lähestymistavasta:

tai käyttämällä alhaalta ylös -lähestymistapaa, kun työskentelet attribuuttien määrittelyn alemmilla tasoilla, ryhmiteltyinä suhteiksi, jotka edustavat objekteja attribuuttien välisten suhteiden perusteella;
tai käyttämällä käänteistä, ylhäältä alas -lähestymistapaa, jota sovelletaan merkittävästi (jopa satoihin ja tuhansiin) attribuuttien määrän kasvuun.

Toinen lähestymistapa sisältää useiden korkean tason entiteettien ja niiden suhteiden määrittelyn, jota seuraa yksityiskohdat halutulle tasolle, mikä heijastaa esimerkiksi "entiteetti-relaatio"-menetelmän pohjalta luotua mallia. Käytännössä molemmat lähestymistavat kuitenkin yleensä yhdistetään.

Fyysisen tietokannan suunnittelu

Tietokannan fyysisen suunnittelun seuraavassa vaiheessa looginen rakenne esitetään tietokannan tallennusrakenteen muodossa, eli se on linkitetty sellaiseen fyysiseen tallennusvälineeseen, johon tiedot sijoitetaan mahdollisimman tehokkaasti. Tässä tietoskeema on kuvattu yksityiskohtaisesti, ja siinä ilmoitetaan kaikki tyypit, kentät, koot ja rajoitukset. Indeksien ja taulukoiden kehittämisen lisäksi määritellään peruskyselyt.

Fyysisen mallin rakentaminen liittyy monessa suhteessa ristiriitaisten ongelmien ratkaisuun:

datan tallennustilan minimointiongelmia,
tavoitteet eheyden, turvallisuuden ja maksimaalisen suorituskyvyn saavuttamiseksi.

Toinen tehtävä on ristiriidassa ensimmäisen kanssa, koska esimerkiksi:

tapahtumien tehokkaan toiminnan varmistamiseksi sinun on varattava levytilaa väliaikaisille kohteille,
lisätäksesi hakunopeutta sinun on luotava indeksit, joiden lukumäärä määräytyy kaikkien mahdollisten hakuun osallistuvien kenttien yhdistelmien lukumäärän mukaan,
tietojen palauttamiseksi tietokanta varmuuskopioidaan ja kaikista muutoksista pidetään lokia.

Kaikki tämä kasvattaa tietokannan kokoa, joten suunnittelija etsii järkevää tasapainoa, jossa tehtävät ratkaistaan optimaalisesti sijoittamalla tiedot asiantuntevasti muistitilaan, mutta ei tietokannan suojauksen kustannuksella, joka sisältää sekä suojauksen luvattomalta käytöltä että suojauksen. epäonnistumisista.

Fyysisen mallin luomisen viimeistelemiseksi arvioidaan sen toiminnalliset ominaisuudet (haun nopeus, kyselyn suorittamisen tehokkuus ja resurssien kulutus, toimintojen oikeellisuus). Joskus tämä vaihe, kuten tietokannan toteutus-, testaus- ja optimointivaiheet sekä ylläpito ja käyttö, jätetään tietokannan suoran suunnittelun ulkopuolelle.