Et databasestyringssystem eller DBMS (fra engelsk : Data Base Management System eller DBMS) er programvare som lar deg administrere en database . Dette betyr at du gjennom dette programmet kan bruke, konfigurere og trekke ut lagret informasjon [ 1 ] . Brukere kan få tilgang til informasjonen ved å bruke spesifikke søke- og rapportgenereringsverktøy, eller gjennom applikasjoner for det formålet.
Disse systemene gir også metoder for å opprettholde dataintegritet, for å administrere brukertilgang til data og for å gjenopprette informasjon hvis systemet blir ødelagt. De gjør at informasjonen i databasen kan presenteres i ulike formater. De fleste inkluderer en rapportgenerator. De kan også inkludere en grafisk modul som gjør det mulig å presentere informasjonen med grafer og tabeller.
Data er vanligvis tilgjengelig gjennom spørringsspråk, høynivåspråk som forenkler oppgaven med å bygge applikasjoner. De forenkler også spørsmål og presentasjon av informasjon. Et DBMS lar deg kontrollere tilgangen til data, sikre integriteten, administrere samtidig tilgang til dem, gjenopprette data etter en systemfeil og lage sikkerhetskopier. Databaser og deres styringssystemer er avgjørende for ethvert forretningsområde, og må administreres nøye.
Databaser kjører vanligvis på datamaskiner dedikert utelukkende til dette feltet. På grunn av de nødvendige funksjonene kjører de vanligvis på multiprosessordatamaskiner med mye minne .
For datalagring kan du ha dine egne disksystemer eller direkte tilkoblet lagring ( DAS ), du kan koble til et lagringsnettverk ( SAN ) eller koble til et nettverkslagringssystem ( NAS ).
Det er maskinvareakseleratorer som brukes i systemer for behandling av store transaksjoner. DBMS er kjernen i enhver applikasjon som håndterer data. DBMS er basert på standard operativsystemer for å utføre disse funksjonene.
Databaser har vært i bruk siden de tidlige dagene av elektroniske datamaskiner. I motsetning til moderne systemer, som kan brukes på svært forskjellige data og behov, var de fleste av de originale systemene fokusert på spesifikke databaser og designet for å få fart på bekostning av å miste fleksibilitet. Den originale DBMS var bare tilgjengelig for store organisasjoner som hadde råd til de komplekse datamaskinene som trengs.
Etter hvert som datamaskiner fikk fart og kapasitet, dukket det opp generelle databasesystemer; på midten av 1960-tallet var noen systemer allerede i bruk. Interessen for en standard oppsto, og Charles Bachman – forfatter av et av de første produktene, Integrated Data Store (IDS) – grunnla Database Task Group i CODASYL , gruppen som var ansvarlig for opprettelsen og standardiseringen av COBOL. I 1971 publiserte de standarden deres, som ble kjent som "CODASYL-tilnærmingen", og snart dukket det opp noen produkter basert på denne linjen.
CODASYLs strategi var basert på manuell navigering gjennom et nettverksbasert datasett. Da databasen ble startet, returnerte programmet en lenke til den første posten i databasen, som igjen inneholdt pekere til andre data. For å finne en spesifikk post, måtte programmereren følge pekere til den søkte posten.
For å svare på enkle spørsmål som «finn alle mennesker i Japan», måtte programmet gå gjennom alle dataene for å velge de riktige postene. Det fantes ikke noe som het 'søk' eller 'finn', noe som ville vært uakseptabelt i dag, men i tiden da data ble lagret på bånd var det ikke mulig å gjennomføre.
Det ble funnet løsninger på mange av disse problemene. Produsenten Prime opprettet et DBMS justert til CODASYL basert på binære trær som forkortet navigasjonen fra post til post ved å tilby alternative tilgangsstier. Det ga også et veldig tydelig spørrespråk. Faktisk er det ingen grunn til at normaliseringskonsepter ikke kunne brukes på CODASYL-databaser, men CODASYL var til slutt veldig kompleks og krevde mye innsats og øvelse for å produsere en nyttig applikasjon.
IBM hadde også sin egen DBMS i 1968, kjent som IMS . Det var en programvare utviklet for Apollo-programmet på System/360. IMS hadde lignende konsepter som CODASYL, men brukte et strengt databestillingshierarki, i motsetning til CODASYLs nettverksstruktur. Begge konseptene ble senere inkludert i konseptet med navigasjonsdatabaser på grunn av modusen for tilgang til data, faktisk mottok Bachman Turing-prisen i 1973 for sin artikkel The programmer as a browser . [ 2 ]
Edgar Codd jobbet i IBM, i et av de perifere kontorene som hovedsakelig var dedikert til utvikling av harddisker. Jeg var misfornøyd med CODASYL-navigasjonsmodellen, hovedsakelig mangelen på en søkeoperasjon. I 1970 skrev han noen artikler som skisserte en ny tilnærming som kulminerte i dokumentet "A Relational Model of Data for Large Shared Data Banks". [ 3 ]
I denne artikkelen oppdaget du et nytt system for lagring og arbeid med store databaser. I stedet for å lagre poster av vilkårlig type i en lenket liste som i CODASYL, var Codds idé å bruke en "tabell" av poster med fast størrelse. En lenket liste har svært dårlig effektivitet ved lagring av sparsomme data der noen av dataene i en post kan stå tomme. Relasjonsmodellen løser dette ved å dele dataene inn i en serie med normaliserte tabeller – eller relasjoner – der valgfrie elementer er trukket ut fra hovedtabellen slik at de kun tar opp plass etter behov. I denne relasjonsmodellen er relaterte poster knyttet til en "nøkkel".
En vanlig bruk av databaser kan være å opprettholde en katalog over brukere, deres navn, tilgangsinformasjon, adresse og telefonnummer. I navigasjonsløsningen vil alle disse dataene være plassert i en enkelt post, og ubrukte funksjoner vil ganske enkelt ikke være i databasen. I den relasjonelle løsningen vil dataene bli normalisert i en brukertabell, en telefon og en adressetabell, der poster vil bli lagt til dersom vi måtte inkorporere telefon og adresse.
Å avstemme all informasjon er nøkkelen til dette systemet. I relasjonsmodellen brukes en del av informasjonen som en nøkkel, som biunivocally identifiserer en spesifikk post. Når informasjon om en bruker samles inn, får du tilgang til informasjonen i de valgfrie tabellene ved å søke med den nøkkelen. For eksempel, hvis brukernavnet er unikt, vil denne brukerens adresse og telefonnummer bli lagret med brukernavnet som passord. Samlingen av denne informasjonen i en enkelt post er noe tradisjonelle språk ikke er ment for.
Akkurat som navigasjonstilnærmingen krever programmer som går i loop for å samle poster, vil den relasjonelle tilnærmingen også kreve dem. Codds løsning for de nødvendige loopene er basert på et sett-orientert språk, et forslag som senere skulle utkrystallisere seg til den allestedsnærværende SQL. Han foreslo bruk av en gren av algebra kalt tuppelregning, og viste at med den kunne alle de typiske operasjonene på en database utføres, i tillegg til å trekke ut datasett på en enkel måte.
Codds artikkel falt i hendene på to personer i Berkeley, Eugene Wong og Michael Stonebraker. De startet et prosjekt kalt INGRES med midler tildelt et studentprogrammert geografisk databaseprosjekt. Fra 1973 produserte INGRES sine første testversjoner som var klare for generell bruk i 1979. INGRES var veldig lik IBMs System R i flere henseender, inkludert et datatilgangsspråk kjent som QUEL. Over tid tok INGRES i bruk SQL-standarden.
IBM foretok en testimplementering av relasjonsmodellen —PRTV— og en produksjonsmodell —Business System 12— begge avviklet. Honeywell skrev MRDS for Multics, og to nye implementeringer dukker også opp: Alphora Dataphor og Rel . De fleste andre såkalte relasjonelle DBMS-implementeringer er faktisk SQL DBMS.
På 1970 -tallet begynte University of Michigan utviklingen av MICRO Information Management System basert på DL Childs' teoretiske datamodell. Micro ble brukt til å administrere store mengder data i Arbeidsdepartementet til den amerikanske regjeringen. Den kjørte på stormaskinen ved å bruke Michigan Terminal System . Den var i produksjon til 1998 .
IBM begynte tidlig på 1970-tallet med en prototype løst basert på Codds konsepter, og kalte den System R. Den første versjonen var klar i 1974 eller 1975, og begynte dermed arbeidet med flerbordssystemer, der data kunne deles opp tilfeldig. slik at all informasjonen i en post (hvorav noen er valgfri) ikke trenger å lagres i en eneste stor del. Følgende flerbrukerversjoner ble testet av brukere i 1978 og 1979, da et SQL-språk var blitt standardisert. Codds ideer viste seg operative og overlegne CODASYLs, og lanserte IBM i utviklingen av en ekte produksjonsversjon av System R, kjent som SQL/DS, og senere som Database 2 (DB2).
Mange av INGRES-teknikerne var sikre på den kommersielle suksessen til systemet, og dannet egne selskaper for å kommersialisere utviklingen, men med et SQL-grensesnitt. Sybase , Informix , NonStop SQL og selve INGRES ble solgt som derivater av den originale INGRES på 1980-tallet. Selv Microsofts SQL Server er basert på Sybase, og derfor INGRES. Bare Larry Ellison – grunnleggeren av Oracle – startet en ny vei basert på IBMs artikkel om System R, og han overgikk IBM ved å bringe sin første versjon på markedet i 1978.
Stonebraker brukte leksjonene fra INGRES til utviklingen av en ny database – Postgres – nå kjent som PostgreSQL. PostgreSQL brukes til mange kritiske applikasjoner (det brukes av .org- og .info-domeneregistre for deres primære lagring, så vel som av store selskaper og finansinstitusjoner).
I Sverige genererte Codds artikkel Mimer SQL-databasen [ 4 ] ved Uppsala universitet . I 1984 ble dette prosjektet konsolidert til et uavhengig selskap. På begynnelsen av 1980-tallet introduserte Mimer transaksjonsstyring for å gjøre applikasjoner robuste, en idé som ble plukket opp i mange andre DBMS-er.
I løpet av 1980-tallet påvirket fremveksten av objektorientert programmering måten informasjon ble håndtert i databaser. Programmerere og designere begynte å behandle data i databaser som objekter. Dette betyr at dersom en persons data ligger i databasen, anses personens attributter som adresse, telefon og alder å tilhøre personen, det er ikke utenlandske data. Dette gjør det mulig å etablere relasjoner mellom objekter og attributter, i stedet for mellom individuelle felt.
Et annet viktig fokus i løpet av tiåret var økningen i hastighet og pålitelighet av tilgang. I 1989 publiserte to professorer fra University of Wisconsin en artikkel på en ACM-konferanse som skisserte deres metoder for å forbedre databaseytelsen. Tanken var å replikere viktig – og mest etterspurt – informasjon i en liten midlertidig database med lenker til hoveddatabasen. Dette gjorde at den lille databasen kunne søkes mye raskere enn den store. Den forbedrede ytelsen førte til introduksjonen av indeksering, integrert i alle DBMS-er.
Det 21. århundre brakte en ny trend innen databaser: NoSQL. Denne trenden introduserte en ikke-relasjonell linje som er vesentlig forskjellig fra de klassiske. De krever vanligvis ikke faste skjemaer, de unngår joinoperasjoner ved å lagre denormaliserte data, og de er designet for å skalere horisontalt. De fleste av dem kan klassifiseres som nøkkelverdilagre eller dokumentorienterte databaser .
Den siste tiden har det vært stor etterspørsel etter partisjonstolerante distribuerte databaser, men ifølge CAP-teoremet er det ikke mulig å oppnå et distribuert system som samtidig gir konsistens, tilgjengelighet og partisjonstoleranse. Et distribuert system kan tilfredsstille bare to av de tre begrensningene om gangen. Av denne grunn bruker mange NoSQL-databaser den såkalte eventuelle konsistensen for å gi tilgjengelighet og partisjoneringstoleranse, med et maksimalt nivå av datakonsistens.
Populære applikasjoner inkluderer MongoDB , MemcacheDB , Redis , CouchDB , Hazelcast , Apache Cassandra og HBase , som alle er åpen kildekode.
XML-databaser utgjør et undersett av NoSQL-databaser. De bruker alle XML-lagringsformatet, som er åpent, menneske- og maskinlesbart, og mye brukt for interoperabilitet.
I denne kategorien finner vi: BaseX, eXist, MarkLogic Server, MonetDB/XQuery, Sedna.
Hver database som støttes av en DBMS må ha riktig modellerte skjemaer. Sammenfallende med den historiske utviklingen av databaser har de brukt forskjellige modeller. DBMS forventer at en bestemt modell skal kunne få tilgang til databasen på en enkel måte. Disse modellene er:
Inverterte lister er også brukt.
Den hierarkiske strukturen ble brukt i DBMS for de første stormaskinene . Forholdet mellom poster danner en trestruktur. Denne strukturen er enkel, men lite fleksibel siden relasjoner er begrenset til 1:n-typen. IBMs IMS-system og Raimas RDM Mobile [ 5 ] er eksempler på databaser med flere hierarkier på samme datasett. RDM Mobile er en ny innebygd databasedesign for et mobilt datanettverk. Den hierarkiske strukturen brukes i dag til hovedsakelig å lagre geografisk informasjon.
Den hierarkiske databasemodellen har et skjema der dataene er organisert i en trestruktur. Denne strukturen gjør at foreldre/barn-relasjoner kan representeres: hver forelder kan ha flere barn, men hvert barn må komme fra bare én forelder (kjent som 1:N-relasjoner). Alle attributter til en bestemt post er knyttet til en enhetstype. Denne modellen ble laget av IBM i 1960.
I en database er en enhetstype den generelle betegnelsen for en tabell. Hver enkelt post er representert som en rad, og hvert attributt som en kolonne. Typeentitetene er relatert til hverandre ved å bruke 1:N-korrespondanser.
For tiden er de mest brukte hierarkiske databasene IBMs IMS og Microsofts Windows-register .
Denne strukturen inneholder mer komplekse relasjoner enn hierarkiske. Den innrømmer relasjoner for hver post med flere som kan følges av forskjellige veier. Modellen åpner med andre ord for N:N-relasjoner.
Nettverksmodellen er tenkt som en fleksibel måte å representere objekter og deres relasjoner. Dens særegne kvalitet er at ordningen — sett på som et sett med noder forbundet med buer — ikke har noen begrensninger.
Oppfinneren av denne modellen var Charles Bachman, og standarden ble publisert i 1969 av CODASYL.
Den relasjonelle strukturen er den mest utbredte i dag. Den brukes i stormaskiner , mellomstore datamaskiner og mikrodatamaskiner. Lagre data i rader (tupler) og kolonner (attributter). Disse tabellene kan kobles til hverandre med fellesnøkler. Mens han jobbet hos IBM i 1972, unnfanget EF Codd denne strukturen. Modellen er ikke lett for brukeren å konsultere siden den kan kreve en kompleks kombinasjon av tabeller.
Den flerdimensjonale strukturen har likheter med relasjonsmodellen, men i stedet for de to rad-kolonne dimensjonene har den N dimensjoner. Denne strukturen gir utseendet til et regneark. Det er enkelt å vedlikeholde og forstå ettersom loggene lagres på samme måte som de vises. Den høye ytelsen har gjort den til den mest populære databasen for online transaksjonsanalytisk behandling (OLAP).
Den objektorienterte strukturen er designet etter paradigmet til objektorienterte språk. På denne måten støtter den grafikk-, bilde-, tale- og tekstdatatyper på en naturlig måte. Denne strukturen er mye brukt i webapplikasjoner for multimediaapplikasjoner.
Før implementeringen av DBMS med en objektorientert struktur, var lagringen av multimediedata basert på filsystemet for å organisere, lagre og behandle dataene. Filbehandling er tungvint, dyrt og lite fleksibelt. Dataredundans er en ulempe med filbehandling siden uavhengige filer produserer dupliserte filer med deres implikasjoner på nødvendig plass. En annen ulempe er mangelen på integrering, og vanskeligheten med vedlikehold. Dette ble løst ved å bruke objektorientering på dataene.
Databasespørring og rapporteringsspråk lar deg spørre databasen, analysere dataene og oppdatere dem basert på hver brukers privilegier. Den kontrollerer også databasesikkerhet for å hindre uautorisert tilgang fra å vise, slette eller endre data. Gjennom bruk av nøkler tillates tilgang til hele databasen eller deler av den. Som et eksempel kan en ansattdatabase inneholde alle ansattes data, men bare én gruppe brukere kan være autorisert til å se lønn mens andre kan være autorisert til kun å se arbeidshistorier og medisinske data, eller forespørsler.
Hvis DBMS gir en måte å få tilgang til og oppdatere databasen, samt å konsultere den, vil det gjøre det mulig å opprette personlige databaser. Den ville imidlertid mangle evnen til å spore de nødvendige handlingene eller kontrollene som trengs av en stor organisasjons database. Disse kontrollene er bare tilgjengelige når et sett med hjelpeprogrammer overvåker datatilganger og oppdateringer.
Arkitekturen til en DBMS spesifiserer dens komponenter (inkludert deres funksjonelle beskrivelse) og deres grensesnitt. Den omhandler andre konsepter enn databasearkitektur. Hovedkomponentene i en DBMS er: