Tärkeimmät DBMS-toiminnot

2024 Kirjoittaja: Howard Calhoun | [email protected]. Viimeksi muokattu: 2023-12-17 10:26

Nykyaikaisia tietokannanhallintajärjestelmiä käytetään monilla sivustoilla, mutta kaikki eivät tiedä, mitä ne ovat ja kuinka voit käyttää DBMS:n toimintoja. Tällaisilla työkaluilla on v altava määrä mahdollisuuksia, joten jotta voit käyttää niitä täysimääräisesti, sinun tulee ymmärtää, mitä ne voivat tehdä ja kuinka hyödyllisiä ne ovat käyttäjälle.

Tietojenhallinta

Ensinnäkin DBMS:n toimintoihin kuuluu tietojen käsittely ulkoisessa muistissa, ja tämä tehtävä on tarjota VI:n perusrakenteet, joita tarvitaan paitsi suoraan tietokantaan sisältyvän tiedon tallentamiseen, myös suorittaa erilaisia palvelutehtäviä, kuten saada nopeutettua pääsyä tiedostoihin eri tapauksissa. Tietyissä muutoksissa eri tiedostojärjestelmien ominaisuuksia käytetään aktiivisesti, kun taas toiset tarjoavat työtä jopa ulkoisten muistilaitteiden tasolla. Mutta tässä tapauksessa on syytä huomata, että pitkälle kehittyneen DBMS:n toiminnassa käyttäjälle ei missään tapauksessa ilmoiteta, käytetäänkö jotain järjestelmää, ja jos on, kuinka tiedostot on järjestetty. Erityisesti järjestelmä ylläpitää omaa nimeämisjärjestystä tietokantaan sisältyville objekteille.

RAM-puskurinhallinta

V altaosassa tapauksia on tapana käyttää DBMS-toimintoja melko suurissa tietokannoissa, ja tämä koko on ainakin usein paljon suurempi kuin käytettävissä oleva RAM. Tietenkin, jos jokaiseen tietoelementtiin pääsyn yhteydessä suoritetaan vaihto ulkoisen muistin kanssa, jälkimmäisen nopeus vastaa itse järjestelmän nopeutta, joten käytännössä ainoa vaihtoehto sen tosiasialliseen kasvattamiseen on puskurointi. tiedot RAM-muistissa. Lisäksi vaikka käyttöjärjestelmä suorittaa järjestelmän laajuisen puskuroinnin, esimerkiksi UNIXin kanssa, tämä ei riitä antamaan DBMS:lle tarkoitusta ja perustoimintoja, koska sillä on paljon suurempi määrä tietoa puskuroinnin hyödyllisistä ominaisuuksista jokaiselle. tietyn osan käytetystä tietokannasta. Tästä johtuen edistyneillä järjestelmillä on oma puskurisarjansa sekä ainutlaatuinen kurinalaisuus niiden korvaamiseksi.

On syytä huomata, että ohjausjärjestelmillä on erillinen suunta, joka keskittyy koko tietokannan jatkuvaan läsnäoloon RAM-muistissa. Tämä suunta perustuu olettamukseen, että lähitulevaisuudessa tietokoneiden RAM-muistin määrä voi kasvaa niin paljon, että niissä ei enää tarvitse huolehtia puskuroinnista, ja tämän tyyppisten DBMS-järjestelmien perustoiminnot tulevat tarpeeseen. Tällä hetkellä kaikki nämä työt ovat testausvaiheessa.

Tapahtumien hallinta

Tapahtuma on toimintosarja käytetyn tietokannan kanssa, jota hallintajärjestelmä pitääyksi kokonaisuus. Jos tapahtuma on suoritettu täysin onnistuneesti, järjestelmä korjaa ulkoiseen muistiin tekemänsä muutokset tai mikään näistä muutoksista ei vaikuta tietokannan tilaan. Tämä toiminto on tarpeen käytetyn tietokannan loogisen eheyden ylläpitämiseksi. On syytä huomata, että tapahtumamekanismin oikean suunnan ylläpitäminen on edellytys myös käytettäessä yhden käyttäjän DBMS-järjestelmää, jonka tarkoitus ja toiminnot eroavat merkittävästi muun tyyppisistä järjestelmistä.

Ominaisuus, että mikä tahansa tapahtuma alkaa vain, kun tietokanta on johdonmukaisessa tilassa ja jättää sen samaan tilaan toimenpiteen päätyttyä, tekee siitä erittäin kätevän käyttää tietokannan toimintayksikkönä. Kun valvontajärjestelmä hallitsee asianmukaisesti samanaikaisesti suoritettavia tapahtumia, jokainen yksittäinen käyttäjä voi periaatteessa tuntea olevansa osa kokonaisuutta. Tämä on kuitenkin jossain määrin idealisoitu esitys, koska monissa tilanteissa, joissa työskentelevät ihmiset silti tuntevat kollegoidensa läsnäolon, jos he käyttävät usean käyttäjän järjestelmää, mutta itse asiassa tämä on mahdollista myös DBMS:n käsitteessä.. Usean käyttäjän tyyppisen DBMS:n ominaisuudet liittyvät myös tapahtumien hallintaan käsitteet, kuten sarjasuoritussuunnitelma ja serialisointi.

Mitä ne tarkoittavat?

Samanaikaisesti suoritettavien liiketoimien sarjoittaminen edellyttää erityissuunnitelman rakentamista heidän työlleen, jossasaavutetun seoksen kokonaisvaikutus on yhtä suuri kuin tulos, joka saadaan niiden peräkkäisestä toteutuksesta.

Sarjallinen suoritussuunnitelma on erityinen toimintojen rakenne, joka johtaa sarjoitukseen. Tietenkin, jos järjestelmä onnistuu tarjoamaan todella sarjasuorituksen useista tapahtumista, niin kaikille tapahtuman aloittaville käyttäjille muiden läsnäolo on täysin huomaamaton, paitsi että se toimii hieman hitaammin kuin yhden käyttäjän. tila.

On olemassa useita perussarjoitusalgoritmeja. Keskitetyissä järjestelmissä suosituimmat algoritmit nykyään perustuvat erilaisten tietokantaobjektien synkronointikaappauksiin. Käytettäessä mitä tahansa sarjoitusalgoritmeja, on olemassa mahdollisuus ristiriitaan kahden tai useamman tapahtuman välillä pääsyssä tiettyihin tietokantaobjekteihin. Tällaisessa tilanteessa tämän toimenpiteen tukemiseksi on tarpeen suorittaa palautus eli poistaa kaikki yhden tai useamman prosessin kautta tietokantaan tehdyt muutokset. Tämä on vain yksi niistä tilanteista, joissa henkilö tuntee muiden läsnäolon monikäyttäjäjärjestelmässä.

Journaling

Yksi nykyaikaisten järjestelmien päävaatimuksista on varmistaa tietojen tallennuksen luotettavuus ulkoiseen muistiin. Tämä edellyttää erityisesti, että DBMS:n päätoimintoihin kuuluu kyky palauttaa viimeksi sovittutietokannan tila ohjelmisto- tai laitteistovian jälkeen. Suurimmassa osassa tapauksista on tapana harkita kahta vaihtoehtoa laitteistovikojen var alta:

• pehmeä, joka voidaan tulkita tietokoneen odottamattomaksi sammumiseksi (yleisin tapaus on hätävirtakatkos);
• kovat, joille on ominaista ulkoiselle tallennusvälineelle tallennettujen tietojen osittainen tai täydellinen häviäminen.

Esimerkkejä ohjelmistovioista ovat järjestelmän kaatuminen yritettäessä käyttää jotakin ominaisuutta, joka ei ole osa DBMS:n päätoimintoja, tai jonkin käyttäjäapuohjelman kaatuminen, jonka seurauksena tiettyä tapahtumaa ei suoritettu loppuun. Ensin mainittua tilannetta voidaan pitää erityisenä pehmeänä epäonnistumisena, kun taas jälkimmäinen vaatii yhden tapahtuman palautuksen.

Tietenkin joka tapauksessa, jotta tietokanta voidaan palauttaa normaalisti, sinulla on oltava tietty määrä lisätietoja. Toisin sanoen tietokannan tietojen tallennuksen luotettavuuden normaalin ylläpitämisen kann alta on tarpeen varmistaa tiedon tallennuksen redundanssi ja erityisen tarkasti vartioi palautuksen aikana käytettävää osaa tiedosta. Yleisin tapa ylläpitää näitä redundantteja tietoja on muutosloki.

Mikä se on ja miten sitä käytetään?

Loki on tietokannan erityinen osa, pääsyjoka ei sisälly DBMS-toimintojen määrään, ja sitä tuetaan erittäin huolellisesti. Joissakin tilanteissa se jopa tukee kahta lokin kopiota samanaikaisesti, jotka sijaitsevat eri fyysisillä tietovälineillä. Nämä arkistot saavat tietoa tietokannan pääosassa tapahtuvista muutoksista ja eri hallintajärjestelmissä muutoksia voidaan kirjata eri tasoilla. Joissakin tilanteissa lokimerkintä vastaa täysin tiettyä loogista päivitystoimintoa, toisissa - ulkoisen muistisivun päivittämiseen liittyvää minimaalista sisäistä toimintoa, kun taas jotkin DBMS-järjestelmät tarjoavat näiden kahden lähestymistavan yhdistelmän.

Joka tapauksessa käytetään niin kutsuttua "kirjoita eteenpäin" -lokistrategiaa. Kun sitä käytetään, tietue, joka ilmaisee muutoksen kaikissa tietokantaobjekteissa, tulee ulkoiseen lokimuistiin ennen objektin muuttamista. Tiedetään, että jos Access DBMS:n toiminnot mahdollistavat tämän protokollan normaalin toteutuksen, lokin käyttö ratkaisee kaikki tietokannan palauttamiseen liittyvät ongelmat mahdollisten virheiden sattuessa.

Palautus

Yksinkertaisin palautustilanne on yksittäisen tapahtuman peruuttaminen. Tätä toimenpidettä varten sinun ei tarvitse käyttää järjestelmän laajuista muutoslokia, ja riittää, että käytät paikallista muokkauslokia kullekin tapahtumalle ja peruutat sitten tapahtumat suorittamalla käänteiset toiminnot kunkin tapahtuman lopusta alkaen. tietueita. DBMS-funktion rakenne tarjoaa useinjuuri tällaisen rakenteen käyttöä, mutta useimmissa tapauksissa paikallisia lokeja ei silti tueta, ja yksittäisille tapahtumille suoritetaan yksittäinen palautus järjestelmän laajuisen mukaan, ja tätä varten yhdistetään kaikki kunkin tapahtuman tietueet. käänteisessä luettelossa.

Pehmeän vian aikana tietokannan ulkoinen muisti voi sisältää erilaisia objekteja, joita on muokannut tapahtumat, joita ei saatu päätökseen vian tapahtuessa, ja niistä voi myös puuttua useita objekteja, jotka on päivitetty onnistuneesti suoritetuilla. ennen vikaa RAM-puskureiden avulla, joiden sisältö katoaa kokonaan tällaisten ongelmien ilmetessä. Jos paikallisten lokien käytön protokollaa noudatetaan, ulkoisessa muistissa on varmasti merkintöjä, jotka liittyvät tällaisten objektien muokkaamiseen.

Pehmeiden vikojen esiintymisen jälkeisen palautusmenettelyn päätavoite on sellainen päätietokannan ulkoisen muistin tila, joka tapahtuisi, jos VI:ssä tehtäisiin muutoksia valmiisiin tapahtumiin, eikä se sisältäisi jälkiä keskeneräisistä menettelyistä. Tämän vaikutuksen saavuttamiseksi DBMS:n päätoiminnot ovat tässä tapauksessa keskeneräisten tapahtumien palautus ja niiden toimintojen uudelleentoisto, joiden tuloksia ei lopulta näytetä ulkoisessa muistissa. Tämä prosessi sisältää melko suuren määrän hienouksia, jotka liittyvät pääasiassa lokin ja puskurin hallinnan organisointiin.

Vaikeita epäonnistumisia

Kun tietokanta on palautettava vakavan vian jälkeen, ei käytetä vain lokia, vaan myös tietokannan varmuuskopiota. Jälkimmäinen on täydellinen kopio tietokannasta, kun lokin täyttö aloitettiin. Tietenkin normaaliin palautusmenettelyyn vaaditaan päiväkirjan säilyttäminen, joten, kuten aiemmin mainittiin, sen säilyttämiselle ulkoisessa muistissa asetetaan erittäin vakavat vaatimukset. Tässä tapauksessa tietokannan palautus koostuu siitä, että arkistokopion perusteella loki toistaa kaikki tapahtumat, jotka on suoritettu vian ilmetessä. Tarvittaessa se voi jopa toistaa vireillä olevat tapahtumat ja jatkaa normaalia toimintaansa palautusprosessin päätyttyä, mutta useimmissa todellisissa järjestelmissä tätä toimenpidettä ei suoriteta, koska itse kovan vian korjaaminen on melko pitkä prosessi.

Kielituki

Nykyaikaiset tietokannat käyttävät useita kieliä, ja varhaiset tietokantajärjestelmät, joiden tarkoitus, toiminnot ja muut ominaisuudet erosivat merkittävästi nykyaikaisista järjestelmistä, tarjosivat tukea useille pitkälle erikoistuneille kielille. Pohjimmiltaan nämä olivat SDL ja DML, jotka on suunniteltu määrittämään tietokantaskeema ja käsittelemään tietoja.

SDL:ää käytettiin tietokannan loogisen rakenteen määrittämiseen eli tietokannan tietyn rakenteen tunnistamiseen.käyttäjiä. DML puolestaan sisälsi koko joukon tiedonkäsittelyoperaattoreita, joiden avulla voit syöttää tietoja tietokantaan sekä poistaa, muokata tai käyttää olemassa olevia tietoja.

DBMS-toiminnot sisältävät erityyppisiä tukia yhdelle integroidulle kielelle, joka mahdollistaa kaikkien normaaliin tietokantojen työskentelyyn tarvittavien välineiden olemassaolon, alkaen sen alkuperäisestä luomisesta ja tarjoaa standardinmukaisen käyttöliittymän. SQL:ää käytetään vakiokielenä, joka tarjoaa nykypäivän yleisimpien relaatiojärjestelmien DBMS:n perustoiminnot.

Mikä se on?

Ensinnäkin tämä kieli yhdistää DML:n ja SDL:n päätoiminnot, eli se tarjoaa mahdollisuuden määrittää relaatiotietokannan erityiset semantiikkaa ja käsitellä tarvittavia tietoja. Samanaikaisesti eri tietokantaobjektien nimeämistä tuetaan suoraan kielitasolla siinä mielessä, että kääntäjä muuntaa objektien nimet niiden sisäisiksi tunnisteiksi erityisesti ylläpidettyjen palveluluettelotaulukoiden perusteella. Ohjausjärjestelmien ydin ei periaatteessa ole vuorovaikutuksessa taulukoiden tai niiden yksittäisten sarakkeiden kanssa millään tavalla.

SQL-kieli sisältää koko luettelon erikoistyökaluja, joiden avulla voit määrittää tietokannan eheyden rajoitukset. Jälleen kaikki tällaiset rajoitukset sisältyvät erityisiin luettelotaulukoihin, ja eheyden valvonta suoritetaan suoraan kielitasolla, eliLukiessaan yksittäisiä tietokannan muutoskäskyjä kääntäjä luo vastaavan ohjelmakoodin tietokannan eheysrajoitusten perusteella.