2024 Forfatter: Howard Calhoun | [email protected]. Sist endret: 2023-12-17 10:37
Moderne databasestyringssystemer brukes på mange nettsteder, men ikke alle vet hva de er og hvordan du kan bruke funksjonene til DBMS. Slike verktøy har et stort antall muligheter, så for å bruke dem fullt ut, bør du forstå hva de kan gjøre og hvor nyttige de er for brukeren.
Databehandling
Først av alt inkluderer funksjonene til DBMS behandling av informasjon i eksternt minne, og denne funksjonen er å gi de grunnleggende strukturene til VI, som ikke bare er nødvendig for å lagre informasjon direkte inkludert i databasen, men også å utføre ulike tjenesteoppgaver, for eksempel å få akselerert tilgang til filer i ulike tilfeller. I visse modifikasjoner brukes funksjonene til forskjellige filsystemer aktivt, mens andre sørger for arbeid selv på nivå med eksterne minneenheter. Men i dette tilfellet er det verdt å merke seg at i funksjonen til et høyt utviklet DBMS, blir brukeren uansett ikke informert om noe system brukes, og i så fall hvordan filene er organisert. Spesielt opprettholder systemet sin egen navnefølge for objekter som er inkludert i databasen.
RAM buffer management
I de aller fleste tilfeller er det vanlig å bruke DBMS-funksjoner i ganske store databaser, og denne størrelsen er i hvert fall ofte mye større enn tilgjengelig RAM. Selvfølgelig, hvis det utføres en utveksling med eksternt minne i tilfelle av tilgang til hvert dataelement, vil hastigheten til sistnevnte tilsvare hastigheten til selve systemet, derfor er praktisk t alt det eneste alternativet for å faktisk øke det å buffere informasjon i RAM. Dessuten, selv om operativsystemet utfører systemomfattende bufring, for eksempel med UNIX, vil dette ikke være nok til å gi DBMS formålet og grunnleggende funksjoner, siden det har en mye større mengde data om de fordelaktige egenskapene til bufring for hver spesifikk del av databasen som brukes. På grunn av dette opprettholder avanserte systemer sitt eget sett med buffere, samt en unik disiplin for utskifting.
Det er verdt å merke seg at det er en egen retning for kontrollsystemer, fokusert på kontinuerlig tilstedeværelse av hele databasen i RAM. Denne retningen er basert på antakelsen om at i nær fremtid vil mengden RAM i datamaskiner kunne utvide seg så mye at de ikke lenger vil bekymre seg for noen buffering, og de grunnleggende funksjonene til denne typen DBMS vil komme godt med her. For øyeblikket gjenstår alle disse arbeidene på teststadiet.
Transaksjonsadministrasjon
En transaksjon er en sekvens av operasjoner med databasen som brukes, som styringssystemet anser somen enkelt helhet. Hvis transaksjonen er fullført vellykket, fikser systemet endringene det har gjort i eksternt minne, eller ingen av disse endringene vil påvirke tilstanden til databasen. Denne operasjonen er nødvendig for å opprettholde den logiske integriteten til den brukte databasen. Det er verdt å merke seg at det er en forutsetning å opprettholde riktig forløp for transaksjonsmekanismen selv ved bruk av enkeltbruker-DBMS, hvis formål og funksjoner skiller seg vesentlig fra andre typer systemer.
Egenskapen at enhver transaksjon starter bare når databasen er i en konsistent tilstand og etterlater den i samme tilstand etter slutten av prosedyren, gjør den ekstremt praktisk å bruke som en aktivitetsenhet angående databasen. Med riktig styring av samtidig utførende transaksjoner av kontrollsystemet, kan hver enkelt bruker i prinsippet føle seg som en del av helheten. Dette er imidlertid til en viss grad en idealisert representasjon, siden i mange situasjoner når arbeidsfolk fortsatt vil føle tilstedeværelsen til sine kolleger hvis de bruker et flerbrukersystem, men dette er faktisk også gitt av selve konseptet med et DBMS. Funksjonene til flerbrukertypen DBMS relaterer også konsepter som seriell utførelsesplan og serialisering til transaksjonsadministrasjon.
Hva betyr de?
Serialisering av transaksjoner som utføres samtidig, sørger for konstruksjon av en spesiell plan for deres arbeid, derden totale effekten av blandingen som er oppnådd tilsvarer resultatet oppnådd på grunn av deres sekvensielle utførelse.
En seriell utførelsesplan er en spesifikk struktur av handlinger som fører til serialisering. Selvfølgelig, hvis systemet klarer å gi en virkelig seriell utførelse av en blanding av transaksjoner, vil for enhver bruker som starter en transaksjon, tilstedeværelsen av andre være helt umerkelig, bortsett fra at det vil fungere litt tregere sammenlignet med en enkeltbruker modus.
Det finnes flere grunnleggende serialiseringsalgoritmer. I sentraliserte systemer er de mest populære algoritmene i dag basert på synkroniseringsfangst av ulike databaseobjekter. Ved bruk av serialiseringsalgoritmer er muligheten for konflikter mellom to eller flere transaksjoner ved tilgang til visse databaseobjekter gitt. I en slik situasjon, for å støtte denne prosedyren, er det nødvendig å utføre en tilbakerulling, det vil si å eliminere eventuelle endringer i databasen gjennom en eller flere prosesser. Dette er bare en av situasjonene der en person føler andres tilstedeværelse i et flerbrukersystem.
Journaling
Et av hovedkravene til moderne systemer er å sikre påliteligheten til informasjonslagring i eksternt minne. Spesielt gir dette at hovedfunksjonene til DBMS inkluderer muligheten til å gjenopprette den sist avt altetilstanden til databasen etter at det har oppstått programvare- eller maskinvarefeil. I de aller fleste tilfeller er det vanlig å vurdere to alternativer for maskinvarefeil:
- myk, som kan tolkes som en uventet nedstenging av datamaskinen (det vanligste tilfellet er et nødstrømbrudd);
- hard, som er preget av delvis eller fullstendig tap av data lagret på eksterne medier.
Eksempler på programvarefeil inkluderer å krasje systemet når du prøver å bruke en funksjon som ikke er en del av hovedfunksjonene til DBMS, eller krasj et brukerverktøy, som et resultat av at en bestemt transaksjon ikke ble fullført. Den førstnevnte situasjonen kan betraktes som en spesiell type myk feil, mens sistnevnte krever en enkelt transaksjonsgjenoppretting.
Selvfølgelig, i alle fall, for å gjenopprette databasen norm alt, må du ha en viss mengde tilleggsinformasjon. Med andre ord, for normal vedlikehold av påliteligheten til datalagring i databasen, er det nødvendig å sikre redundansen av informasjonslagring, og delen av dataene som brukes under gjenoppretting må voktes spesielt nøye. Den vanligste metoden for å vedlikeholde disse redundante dataene er endringslogging.
Hva er det og hvordan brukes det?
Loggen er en spesiell del av databasen, tilgangsom ikke er inkludert i antall DBMS-funksjoner, og den støttes veldig nøye. I noen situasjoner gir den til og med støtte for to kopier av loggen samtidig, plassert på forskjellige fysiske medier. Disse depotene mottar informasjon om eventuelle endringer som skjer i hoveddelen av databasen, og i ulike styringssystemer kan endringer logges på ulike nivåer. I noen situasjoner tilsvarer en loggoppføring fullt ut en spesifikk logisk oppdateringsoperasjon, i andre - en minimal intern operasjon knyttet til oppdatering av en ekstern minneside, mens noen DBMS sørger for en kombinasjon av de to tilnærmingene.
I alle fall brukes den såk alte «write ahead»-loggingsstrategien. Når den brukes, kommer en post som indikerer en endring i alle databaseobjekter inn i det eksterne loggminnet før objektet endres. Det er kjent at hvis funksjonene til Access DBMS sørger for normal implementering av denne protokollen, vil bruk av loggen løse eventuelle problemer knyttet til gjenoppretting av databasen i tilfelle feil.
Rullback
Den enkleste gjenopprettingssituasjonen er en individuell tilbakeføring av transaksjoner. For denne prosedyren trenger du ikke å bruke en systemomfattende endringslogg, og det er ganske tilstrekkelig å bruke en lokal modifikasjonsoperasjonslogg for hver transaksjon, og deretter rulle tilbake transaksjoner ved å utføre omvendte operasjoner, fra slutten av hver av postene. Strukturen til en DBMS-funksjon gir oftebruken av nettopp en slik struktur, men i de fleste tilfeller støttes fortsatt ikke lokale logger, og en individuell tilbakerulling selv for individuelle transaksjoner utføres i henhold til den systemomfattende, og for dette er alle poster for hver av transaksjonene kombinert i en omvendt liste.
Under en myk feil, kan databasens eksterne minne inkludere ulike objekter som er blitt modifisert av transaksjoner som ikke ble fullført på tidspunktet for feilen, og kan også mangle ulike objekter som er oppgradert av de som har fullført. før feilen ved bruk av buffere av RAM, hvis innhold forsvinner helt når slike problemer oppstår. Hvis protokollen for å bruke lokale logger følges, er det garantert oppføringer i eksternt minne som gjelder modifikasjon av slike objekter.
Hovedmålet med gjenopprettingsprosedyren etter forekomsten av myke feil er en slik tilstand av det eksterne minnet til hoveddatabasen, som ville oppstå hvis endringer i noen fullførte transaksjoner ble utført i VI og ikke ville inneholde spor av uferdige prosedyrer. For å oppnå denne effekten er hovedfunksjonene til DBMS i dette tilfellet tilbakeføring av ufullstendige transaksjoner og avspilling av de operasjonene hvis resultater til slutt ikke ble vist i eksternt minne. Denne prosessen involverer et ganske stort antall finesser, som hovedsakelig er knyttet til organisering av logg- og bufferhåndtering.
Harde feil
Når en database må gjenopprettes etter en hard feil, brukes ikke bare loggen, men også en sikkerhetskopi av databasen. Sistnevnte er en fullstendig kopi av databasen da fyllingen av loggen begynte. Selvfølgelig, for en normal gjenopprettingsprosedyre, kreves bevaring av journalen, derfor stilles det, som nevnt tidligere, ekstremt alvorlige krav til bevaring i eksternt minne. I dette tilfellet består gjenopprettingen av databasen i det faktum at loggen, basert på arkivkopien, reproduserer alle transaksjonene som er fullført på det tidspunktet feilen oppstod. Om nødvendig kan den til og med spille av ventende transaksjoner og fortsette sin normale drift etter slutten av gjenopprettingsprosedyren, men i de fleste virkelige systemer utføres ikke denne prosedyren av den grunn at hard feilgjenoppretting i seg selv er en ganske langvarig prosedyre.
Språkstøtte
Moderne databaser bruker en rekke språk, og tidlige DBMS-er, hvis formål, funksjoner og andre funksjoner skilte seg vesentlig fra moderne systemer, ga støtte for flere høyt spesialiserte språk. I utgangspunktet var disse SDL og DML, designet for å definere henholdsvis databaseskjemaet og manipulere data.
SDL ble brukt til å bestemme den logiske strukturen til databasen, det vil si å gjenkjenne den spesifikke strukturen til databasen, som er representertbrukere. DML, på den annen side, inkluderte et helt kompleks av informasjonsmanipulasjonsoperatører som tillot deg å legge inn informasjon i databasen, samt slette, endre eller bruke eksisterende data.
DBMS-funksjonene inkluderer ulike typer støtte for et enkelt integrert språk, som sørger for tilstedeværelsen av alle midler som er nødvendige for norm alt arbeid med databaser, fra den første opprettelsen, og gir et standard brukergrensesnitt. SQL brukes som standardspråket som gir de grunnleggende funksjonene til DBMS i dagens vanligste relasjonssystemer.
Hva er det?
For det første kombinerer dette språket hovedfunksjonene til DML og SDL, det vil si at det gir muligheten til å bestemme den spesifikke semantikken til en relasjonsdatabase og manipulere nødvendig informasjon. Samtidig støttes navngivning av ulike databaseobjekter direkte på språknivå i den forstand at kompilatoren konverterer objektnavn til sine interne identifikatorer, basert på spesielt vedlikeholdte tjenestekatalogtabeller. Kjernen i kontrollsystemer samhandler i prinsippet ikke med tabeller eller deres individuelle kolonner på noen måte.
SQL-språket inkluderer en hel liste over spesialverktøy som lar deg bestemme begrensningene for databasens integritet. Igjen er slike restriksjoner inkludert i spesielle katalogtabeller, og integritetskontroll utføres direkte på språknivå, dvs.i prosessen med å lese individuelle databasemodifikasjonssetninger, genererer kompilatoren, basert på integritetsbegrensningene i databasen, den tilsvarende programkoden.
