Database - Database

I databehandling er en database en organisert samling av data som er lagret og tilgjengelig elektronisk fra et datasystem . Der databaser er mer komplekse, utvikles de ofte ved hjelp av formell design og modelleringsteknikk .

Den databasesystem ( DBMS ) er den programvare som samvirker med sluttbrukere , programmer og selve databasen for å registrere og analysere data. DBMS -programvaren omfatter i tillegg kjernefasilitetene som tilbys for å administrere databasen. Summen av databasen, DBMS og de tilhørende programmene kan omtales som et "databasesystem". Ofte brukes begrepet "database" også løst for å referere til noen av DBMS, databasesystemet eller et program som er knyttet til databasen.

Datavitenskapere kan klassifisere databasesystemer i henhold til databasemodellene de støtter. Relasjonsdatabaser ble dominerende på 1980 -tallet. Disse modelldataene som rader og kolonner i en tabellserie , og de aller fleste bruker SQL for å skrive og spørre data. På 2000-tallet ble ikke-relasjonsdatabaser populære, referert til som NoSQL fordi de bruker forskjellige spørrespråk .

Terminologi og oversikt

Formelt refererer en "database" til et sett med relaterte data og måten den er organisert på. Tilgang til disse dataene er vanligvis gitt av et "database management system" (DBMS) som består av et integrert sett med dataprogramvare som lar brukerne samhandle med en eller flere databaser og gir tilgang til alle dataene i databasen (selv om begrensninger kan eksistere som begrenser tilgangen til bestemte data). DBMS tilbyr forskjellige funksjoner som tillater registrering, lagring og gjenfinning av store mengder informasjon og gir måter å administrere hvordan informasjonen er organisert på.

På grunn av det nære forholdet mellom dem, brukes begrepet "database" ofte tilfeldig for å referere til både en database og DBMS som brukes til å manipulere den.

Utenfor verden av profesjonell informasjonsteknologi brukes begrepet database ofte for å referere til enhver samling av relaterte data (for eksempel et regneark eller en kortindeks) ettersom krav til størrelse og bruk vanligvis krever bruk av et databasesystem.

Eksisterende DBMS tilbyr forskjellige funksjoner som tillater administrasjon av en database og dens data som kan klassifiseres i fire hovedfunksjonelle grupper:

• Datadefinisjon - Opprettelse, modifikasjon og fjerning av definisjoner som definerer organiseringen av dataene.
• Oppdatering - Innsetting, endring og sletting av faktiske data.
• Hentning - Tilbyr informasjon i et skjema som er direkte brukbart eller for videre behandling av andre applikasjoner. De hentede dataene kan gjøres tilgjengelige i en form som i utgangspunktet er den samme som den er lagret i databasen eller i en ny form som er oppnådd ved å endre eller kombinere eksisterende data fra databasen.
• Administrasjon - Registrering og overvåking av brukere, håndheving av datasikkerhet, overvåking av ytelse, opprettholdelse av dataintegritet, håndtering av samtidighetskontroll og gjenoppretting av informasjon som har blitt ødelagt av en hendelse, for eksempel en uventet systemfeil.

Både en database og dens DBMS samsvarer med prinsippene for en bestemt databasemodell . "Databasesystem" refererer samlet til databasemodellen, databasesystemet og databasen.

Fysisk, databaseservere er dedikerte datamaskiner som holder den faktiske databaser og kjøre bare DBMS og tilhørende programvare. Databaseservere er vanligvis multiprosessormaskiner , med sjenerøst minne og RAID -diskoppsett som brukes til stabil lagring. Maskinvaredatabase-akseleratorer, koblet til en eller flere servere via en høyhastighetskanal, brukes også i transaksjonsbehandlingsmiljøer med store volumer. DBMS er kjernen i de fleste databaseapplikasjoner . DBMSer kan bygges rundt en tilpasset multitasking kjerne med innebygd nettverksstøtte, men moderne DBMSer vanligvis stole på en standard operativsystem for å gi disse funksjonene.

Siden DBMS består av et betydelig marked , tar datamaskin- og lagringsleverandører ofte hensyn til DBMS -kravene i sine egne utviklingsplaner.

Databaser og DBMS kan kategoriseres i henhold til databasemodellene som de støtter (for eksempel relasjonelle eller XML), datamaskinen (e) de kjører på (fra en serverklynge til en mobiltelefon), spørrespråket ( s) brukes til å få tilgang til databasen (for eksempel SQL eller XQuery ), og deres interne prosjektering, som påvirker ytelse, skalerbarhet , motstandskraft og sikkerhet.

Historie

Størrelsene, evnene og ytelsen til databaser og deres respektive DBMS har vokst i størrelsesorden. Disse ytelsesøkningene ble muliggjort av teknologiske fremskritt innen prosessorer , dataminne , datalagring og datanettverk . Konseptet med en database ble muliggjort av fremveksten av lagringsmedier med direkte tilgang, for eksempel magnetiske disker, som ble allment tilgjengelig på midten av 1960 -tallet; tidligere systemer stolte på sekvensiell lagring av data på magnetbånd. Den påfølgende utviklingen av databaseteknologi kan deles inn i tre epoker basert på datamodell eller struktur: navigasjon , SQL/ relasjonell og post-relasjonell.

De to viktigste modellene for tidlig navigasjonsdata var den hierarkiske modellen og CODASYL -modellen ( nettverksmodell ). Disse ble preget av bruk av pekere (ofte fysiske diskadresser) for å følge relasjoner fra en post til en annen.

Den relasjonsmodellen , som først ble foreslått i 1970 av Edgar F. Codd , avvek fra denne tradisjonen ved å insistere på at applikasjoner skulle søke etter data etter innhold, snarere enn ved å følge lenker. Den relasjonsmodellen bruker sett med tabeller i hovedbokstil, som hver brukes for en annen type enhet. Bare på midten av 1980-tallet ble databehandlingsmaskinvaren kraftig nok til å tillate bred distribusjon av relasjonssystemer (DBMS pluss applikasjoner). På begynnelsen av 1990-tallet dominerte imidlertid relasjonssystemer i alle store databehandlingsapplikasjoner , og fra 2018 forblir de dominerende: IBM DB2 , Oracle , MySQL og Microsoft SQL Server er det mest søkte DBMS . Det dominerende databasespråket, standardisert SQL for relasjonsmodellen, har påvirket databasespråk for andre datamodeller.

Objektdatabaser ble utviklet på 1980-tallet for å overvinne ulempen med objekt-relasjonell impedans-mismatch , noe som førte til mynting av begrepet "post-relasjonell" og også utviklingen av hybrid objekt-relasjonsdatabaser .

Neste generasjon post-relasjonsdatabaser på slutten av 2000-tallet ble kjent som NoSQL- databaser, og introduserte raske nøkkelverdilagre og dokumentorienterte databaser . En konkurrerende "neste generasjon" kjent som NewSQL -databaser forsøkte nye implementeringer som beholdt relasjons-/SQL -modellen mens de hadde som mål å matche den høye ytelsen til NoSQL sammenlignet med kommersielt tilgjengelige relasjons -DBMS.

1960 -tallet, navigasjons -DBMS

Innføringen av begrepet database falt sammen med tilgjengeligheten av lagring med direkte tilgang (disker og trommer) fra midten av 1960-tallet og fremover. Begrepet representerte en kontrast med de tape-baserte systemene fra fortiden, noe som tillot delt interaktiv bruk i stedet for daglig batchbehandling . The Oxford English Dictionary siterer en 1962 rapport fra System Development Corporation of California som den første til å bruke begrepet "data-base" i en spesifikk teknisk forstand.

Etter hvert som datamaskiner vokste i hastighet og kapasitet, dukket det opp en rekke generelle databasesystemer; på midten av 1960-tallet hadde en rekke slike systemer kommet i kommersiell bruk. Interessen for en standard begynte å vokse, og Charles Bachman , forfatter av et slikt produkt, Integrated Data Store (IDS), grunnla Database Task Group innen CODASYL , gruppen som er ansvarlig for opprettelse og standardisering av COBOL . I 1971 leverte Database Task Group sin standard, som generelt ble kjent som CODASYL -tilnærmingen , og snart kom en rekke kommersielle produkter basert på denne tilnærmingen på markedet.

CODASYL -tilnærmingen ga applikasjoner muligheten til å navigere rundt et koblet datasett som ble dannet til et stort nettverk. Søknader kan finne poster på en av tre metoder:

1. Bruk av en primærnøkkel (kjent som en CALC -nøkkel, vanligvis implementert ved hashing )
2. Navigere i relasjoner (kalt sett ) fra en post til en annen
3. Skanner alle postene i rekkefølge

Senere systemer la til B-trær for å gi alternative tilgangsstier. Mange CODASYL -databaser la også til et deklarativt spørrespråk for sluttbrukere (forskjellig fra navigasjons -API). CODASYL -databaser var imidlertid komplekse og krevde betydelig opplæring og innsats for å produsere nyttige applikasjoner.

IBM hadde også sitt eget DBMS i 1966, kjent som Information Management System (IMS). IMS var en utvikling av programvare skrevet for Apollo -programmet på System/360 . IMS var generelt lik konseptet til CODASYL, men brukte et strengt hierarki for modellen for datanavigasjon i stedet for CODASYLs nettverksmodell. Begge konseptene ble senere kjent som navigasjonsdatabaser på grunn av måten data ble tilgjengelig på: begrepet ble populært av Bachmans Turing Award -presentasjon fra 1973 The Programmer as Navigator . IMS er klassifisert av IBM som en hierarkisk database . IDM-og CINCOM Systems " TOTAL database er klassifisert som nettdatabaser. IMS forblir i bruk fra 2014.

1970 -tallet, relasjonell DBMS

Edgar F. Codd jobbet på IBM i San Jose, California , i et av deres offshoot -kontorer som hovedsakelig var involvert i utviklingen av harddisksystemer . Han var misfornøyd med navigasjonsmodellen for CODASYL -tilnærmingen, særlig mangelen på et "søk" -anlegg. I 1970 skrev han en rekke artikler som skisserte en ny tilnærming til databasekonstruksjon som til slutt kulminerte i den banebrytende A Relational Model of Data for Large Shared Data Banks .

I denne artikkelen beskrev han et nytt system for lagring og arbeid med store databaser. I stedet for at poster ble lagret i en slags lenket liste over frie formoppføringer som i CODASYL, var Codds idé å organisere dataene som et antall " tabeller ", hvor hver tabell ble brukt for en annen type enhet. Hver tabell inneholder et fast antall kolonner som inneholder attributtene til enheten. En eller flere kolonner i hver tabell ble utpekt som en primærnøkkel som rader i tabellen kunne identifiseres på en unik måte; kryssreferanser mellom tabeller brukte alltid disse primære nøklene, i stedet for diskadresser, og spørringer ville bli med i tabeller basert på disse nøkkelrelasjonene, ved hjelp av et sett med operasjoner basert på det matematiske systemet for relasjonsberegning (som modellen har fått navnet sitt fra). Å dele dataene inn i et sett med normaliserte tabeller (eller relasjoner ) med sikte på å sikre at hvert "faktum" bare ble lagret en gang, og dermed forenkle oppdateringsoperasjoner. Virtuelle tabeller kalt visninger kan presentere dataene på forskjellige måter for forskjellige brukere, men visninger kan ikke oppdateres direkte.

Codd brukte matematiske termer for å definere modellen: relasjoner, tupler og domener i stedet for tabeller, rader og kolonner. Terminologien som nå er kjent, kom fra tidlige implementeringer. Codd ville senere kritisere tendensen til at praktiske implementeringer går fra det matematiske grunnlaget som modellen var basert på.

Bruken av primære nøkler (brukerorienterte identifikatorer) for å representere relasjoner på tvers av bord, i stedet for diskadresser, hadde to hovedmotiveringer. Fra et ingeniørperspektiv muliggjorde det flytting og endring av tabeller uten kostbar omorganisering av databasen. Men Codd var mer interessert i forskjellen i semantikk: bruk av eksplisitte identifikatorer gjorde det lettere å definere oppdateringsoperasjoner med rene matematiske definisjoner, og det gjorde det også mulig å definere spørreoperasjoner når det gjelder den etablerte disiplinen for første ordens predikatberegning ; fordi disse operasjonene har rene matematiske egenskaper, blir det mulig å skrive om spørringer på beviselig riktige måter, som er grunnlaget for spørringsoptimalisering. Det er ingen tap av uttrykksfullhet sammenlignet med hierarkiske eller nettverksmodeller, selv om forbindelsene mellom tabellene ikke lenger er så eksplisitte.

I hierarkiske og nettverksmodeller fikk poster lov til å ha en kompleks intern struktur. For eksempel kan lønnshistorikken til en ansatt være representert som en "gjentakende gruppe" i medarbeiderjournalen. I relasjonsmodellen førte normaliseringsprosessen til at slike interne strukturer ble erstattet av data i flere tabeller, bare forbundet med logiske nøkler.

For eksempel er en vanlig bruk av et databasesystem å spore informasjon om brukere, navn, påloggingsinformasjon, forskjellige adresser og telefonnumre. I navigasjonsmetoden vil alle disse dataene bli plassert i en enkelt rekord med variabel lengde. I den relasjonelle tilnærmingen ville dataene blitt normalisert til en brukertabell, en adressetabell og et telefonnummerbord (for eksempel). Det ville bare blitt opprettet poster i disse valgfrie tabellene hvis adressen eller telefonnumrene faktisk ble oppgitt.

I tillegg til å identifisere rader/poster ved hjelp av logiske identifikatorer i stedet for diskadresser, endret Codd måten applikasjoner samlet data fra flere poster på. I stedet for å kreve at applikasjoner samler data én post om gangen ved å navigere i koblingene, ville de bruke et deklarativt spørrespråk som ga uttrykk for hvilke data som kreves, i stedet for tilgangsbanen de skulle finne. Å finne en effektiv tilgangsbane til dataene ble ansvaret for databasesystemet, i stedet for applikasjonsprogrammereren. Denne prosessen, kalt spørringsoptimalisering, var avhengig av at spørsmål ble uttrykt i form av matematisk logikk.

Codds papir ble hentet av to personer på Berkeley, Eugene Wong og Michael Stonebraker . De startet et prosjekt kjent som INGRES ved å bruke midler som allerede var tildelt for et geografisk databaseprosjekt og studentprogrammerere for å produsere kode. Fra 1973 leverte INGRES sine første testprodukter som generelt var klare for utbredt bruk i 1979. INGRES var lik System R på en rekke måter, inkludert bruk av et "språk" for datatilgang , kjent som QUEL . Over tid flyttet INGRES til den nye SQL -standarden.

IBM selv utførte en testimplementering av relasjonsmodellen, PRTV , og en produksjonsmodell, Business System 12 , som begge ble avviklet. Honeywell skrev MRDS for Multics , og nå er det to nye implementeringer: Alphora Dataphor og Rel . De fleste andre DBMS -implementeringer som vanligvis kalles relasjonelle, er faktisk SQL DBMS.

I 1970 begynte University of Michigan utviklingen av MICRO Information Management System basert på DL Childs 'sett-teoretiske datamodell. MICRO ble brukt til å administrere svært store datasett av US Department of Labor , US Environmental Protection Agency og forskere fra University of Alberta , University of Michigan og Wayne State University . Den kjørte på IBM mainframe -datamaskiner ved bruk av Michigan Terminal System . Systemet forble i produksjon til 1998.

Integrert tilnærming

På 1970- og 1980 -tallet ble det forsøkt å bygge databasesystemer med integrert maskinvare og programvare. Den underliggende filosofien var at slik integrasjon ville gi høyere ytelse til en lavere kostnad. Eksempler var IBM System/38 , det tidlige tilbudet av Teradata , og Britton Lee, Inc. databasemaskin.

En annen tilnærming til maskinvarestøtte for database management var ICL 's kafeer akselerator, en disk controller hardware med programmerbare søkemuligheter. På lang sikt var denne innsatsen generelt mislykket fordi spesialiserte databasemaskiner ikke kunne holde tritt med den raske utviklingen og utviklingen av datamaskiner for generelle formål. Således er de fleste databasesystemer i dag programvaresystemer som kjører på maskinvare for generell bruk, og bruker datalagring for generelle formål. Imidlertid forfølges denne ideen fortsatt for visse applikasjoner av noen selskaper som Netezza og Oracle ( Exadata ).

Sent på 1970 -tallet, SQL DBMS

IBM begynte å jobbe med et prototypesystem løst basert på Codds konsepter som System R på begynnelsen av 1970 -tallet. Den første versjonen var klar i 1974/5, og arbeidet startet deretter med flertabelsystemer der dataene kunne deles slik at alle dataene for en post (hvorav noen er valgfrie) ikke måtte lagres i en enkelt stor "klump". Senere versjoner av flere brukere ble testet av kundene i 1978 og 1979, da hadde et standardisert spørrespråk -SQL-blitt lagt til. Codds ideer etablerte seg som både brukbare og overlegne CODASYL, og presset IBM til å utvikle en ekte produksjonsversjon av System R, kjent som SQL/DS , og senere Database 2 ( DB2 ).

Larry Ellisons Oracle Database (eller rett og slett Oracle ) startet fra en annen kjede, basert på IBMs artikler om System R. Selv om Oracle V1 -implementeringer ble fullført i 1978, var det ikke før Oracle versjon 2 da Ellison slo IBM på markedet i 1979.

Stonebraker brukte videre leksjonene fra INGRES for å utvikle en ny database, Postgres, som nå er kjent som PostgreSQL . PostgreSQL brukes ofte for globale virksomhetskritiske applikasjoner (.org- og .info-domenenavnregistrene bruker det som deres primære datalagring , i likhet med mange store selskaper og finansinstitusjoner).

I Sverige ble Codds papir også lest og Mimer SQL ble utviklet fra midten av 1970-tallet ved Uppsala universitet . I 1984 ble dette prosjektet konsolidert til et uavhengig foretak.

En annen datamodell, entitetsforholdsmodellen , dukket opp i 1976 og ble populær for databasedesign da den la vekt på en mer kjent beskrivelse enn den tidligere relasjonsmodellen. Senere ble entitet -relasjonskonstruksjoner ettermontert som en datamodellkonstruksjon for den relasjonelle modellen, og forskjellen mellom de to har blitt irrelevant.

1980 -tallet, på skrivebordet

1980 -tallet innledet en alder av stasjonær databehandling . De nye datamaskinene ga brukerne sine muligheter med regneark som Lotus 1-2-3 og databaseprogramvare som dBASE . DBASE -produktet var lett og lett for enhver datamaskinbruker å forstå ut av esken. C. Wayne Ratliff , skaperen av dBASE, uttalte: "dBASE var forskjellig fra programmer som BASIC, C, FORTRAN og COBOL ved at mye av det skitne arbeidet allerede var utført. Datamanipulasjonen utføres av dBASE i stedet for av brukeren, slik at brukeren kan konsentrere seg om det han gjør, i stedet for å måtte rote med de skitne detaljene om å åpne, lese og lukke filer og administrere plassallokering. " dBASE var en av de mest solgte programvaretitlene på 1980- og begynnelsen av 1990 -tallet.

1990-tallet, objektorientert

1990-tallet, sammen med en økning i objektorientert programmering , så en vekst i hvordan data i forskjellige databaser ble håndtert. Programmerere og designere begynte å behandle dataene i databasene som objekter . Det vil si at hvis en persons data var i en database, ble personens attributter, for eksempel adresse, telefonnummer og alder, nå ansett å tilhøre den personen i stedet for å være fremmede data. Dette gjør at relasjoner mellom data kan være relasjoner til objekter og deres attributter og ikke til individuelle felt. Begrepet " objekt -relasjons -impedans -mismatch " beskrev ulempen med å oversette mellom programmerte objekter og databasetabeller. Objektdatabaser og objektrelasjonsdatabaser prøver å løse dette problemet ved å tilby et objektorientert språk (noen ganger som utvidelser til SQL) som programmerere kan bruke som alternativ til rent relasjonelt SQL. På programmeringssiden prøver biblioteker kjent som objektrelasjonelle tilordninger (ORM) å løse det samme problemet.

2000 -tallet, NoSQL og NewSQL

XML-databaser er en type strukturert dokumentorientert database som tillater spørring basert på XML- dokumentattributter. XML -databaser brukes for det meste i applikasjoner der dataene på en praktisk måte blir sett på som en samling dokumenter, med en struktur som kan variere fra det meget fleksible til det svært stive: eksempler inkluderer vitenskapelige artikler, patenter, skattemeldinger og personalregistre.

NoSQL -databaser er ofte veldig raske, krever ikke faste tabellskjemaer, unngår koblingsoperasjoner ved å lagre deormaliserte data, og er designet for å skalere horisontalt .

De siste årene har det vært en sterk etterspørsel etter massivt distribuerte databaser med høy partisjonstoleranse, men ifølge CAP -teoremet er det umulig for et distribuert system å samtidig gi konsistens , tilgjengelighet og partisjonstoleransegarantier. Et distribuert system kan tilfredsstille to av disse garantiene samtidig, men ikke alle tre. Av den grunn bruker mange NoSQL -databaser det som kalles eventuell konsistens for å gi både tilgjengelighet og partisjonstoleransegarantier med redusert datakonsistens.

NewSQL er en klasse med moderne relasjonsdatabaser som tar sikte på å gi den samme skalerbare ytelsen til NoSQL-systemer for arbeidsbelastninger på nett for transaksjoner (les-skriv) mens de fortsatt bruker SQL og opprettholder ACID- garantier for et tradisjonelt databasesystem.

Bruk saker

Databaser brukes til å støtte interne operasjoner i organisasjoner og til å underbygge online interaksjoner med kunder og leverandører (se Enterprise -programvare ).

Databaser brukes til å holde administrativ informasjon og mer spesialiserte data, for eksempel ingeniørdata eller økonomiske modeller. Eksempler inkluderer datastyrte biblioteksystemer , flyreservasjonssystemer , datastyrte systembeholdningssystemer og mange innholdshåndteringssystemer som lagrer nettsteder som samlinger av websider i en database.

Klassifisering

En måte å klassifisere databaser på er innholdstypen, for eksempel bibliografiske , dokumenttekst, statistiske eller multimediaobjekter. En annen måte er ved deres applikasjonsområde, for eksempel: regnskap, musikkomposisjoner, filmer, bankvirksomhet, produksjon eller forsikring. En tredje måte er av et teknisk aspekt, for eksempel databasestrukturen eller grensesnitttypen. Denne delen viser noen av adjektivene som brukes til å karakterisere forskjellige typer databaser.

• En in-memory database er en database som hovedsakelig ligger i hovedminnet , men som vanligvis er sikkerhetskopiert av ikke-flyktig datalagring. Hovedminnedatabaser er raskere enn diskdatabaser, og brukes ofte der responstid er kritisk, for eksempel i utstyr for telekommunikasjonsnettverk.
• En aktiv database inkluderer en hendelsesdrevet arkitektur som kan reagere på forhold både i og utenfor databasen. Mulige bruksområder inkluderer sikkerhetsovervåking, varsling, innsamling av statistikk og autorisasjon. Mange databaser gir aktive databasefunksjoner i form av databasetriggere .
• En skydatabase er avhengig av skyteknologi . Både databasen og de fleste av DBMS ligger eksternt, "i skyen", mens applikasjonene er både utviklet av programmerere og senere vedlikeholdt og brukt av sluttbrukere via en nettleser og åpne APIer .
• Datalagre arkiverer data fra operasjonelle databaser og ofte fra eksterne kilder som markedsundersøkelsesfirmaer. Lageret blir den sentrale datakilden for bruk av ledere og andre sluttbrukere som kanskje ikke har tilgang til operasjonelle data. For eksempel kan salgsdata aggregeres til ukentlige summer og konverteres fra interne produktkoder til bruk av UPC -er slik at de kan sammenlignes med ACNielsen -data. Noen grunnleggende og viktige komponenter i datalagring inkluderer ekstraksjon, analyse og gruvedata , transformering, lasting og administrering av data for å gjøre dem tilgjengelige for videre bruk.
• En deduktiv database kombinerer logisk programmering med en relasjonsdatabase.
• En distribuert database er en der både dataene og DBMS spenner over flere datamaskiner.
• En dokumentorientert database er designet for å lagre, hente og administrere dokumentorientert eller semi-strukturert informasjon. Dokumentorienterte databaser er en av hovedkategoriene i NoSQL-databaser.
• Et innebygd databasesystem er et DBMS som er tett integrert med en applikasjonsprogramvare som krever tilgang til lagrede data på en slik måte at DBMS er skjult for applikasjonens sluttbrukere og krever lite eller ingen pågående vedlikehold.
• Sluttbrukerdatabaser består av data utviklet av individuelle sluttbrukere. Eksempler på disse er samlinger av dokumenter, regneark, presentasjoner, multimedia og andre filer. Det finnes flere produkter som støtter slike databaser. Noen av dem er mye enklere enn fullverdige DBMS-er, med mer elementær DBMS-funksjonalitet.
• Et forent databasesystem består av flere forskjellige databaser, hver med sitt eget DBMS. Den håndteres som en enkelt database av et føderert databasesystem (FDBMS), som transparent integrerer flere autonome DBMS -er, muligens av forskjellige typer (i så fall ville det også være et heterogent databasesystem ), og gir dem et integrert konseptuelt syn .
• Noen ganger begrepet multi-database blir brukt som et synonym for å forent database, skjønt det kan referere til en mindre integrert (for eksempel uten en FDBMS og en styrt integrert skjema) gruppe av databaser som samarbeider i en enkelt påføring. I dette tilfellet brukes vanligvis mellomvare for distribusjon, som vanligvis inkluderer en atomic commit-protokoll (ACP), f.eks. Tofaset commit-protokollen , for å tillate distribuerte (globale) transaksjoner på tvers av de deltakende databasene.
• En grafdatabase er en slags NoSQL -database som bruker grafstrukturer med noder, kanter og egenskaper for å representere og lagre informasjon. Generelle grafdatabaser som kan lagre hvilken som helst graf, er forskjellige fra spesialiserte grafdatabaser som triplestores og nettverksdatabaser .
• En array DBMS er en slags NoSQL DBMS som tillater modellering, lagring og gjenfinning av (vanligvis store) flerdimensjonale matriser som satellittbilder og klimasimuleringsutgang.
• I en hypertekst eller hypermedia database, et ord eller en del av teksten representerer et objekt, for eksempel et stykke tekst, en artikkel, et bilde eller en film, kan hyperkoblet til dette objektet. Hypertekstdatabaser er spesielt nyttige for å organisere store mengder forskjellig informasjon. For eksempel er de nyttige for å organisere online leksikon , der brukerne enkelt kan hoppe rundt teksten. The World Wide Web er dermed et stort distribuert hypertekst database.
• En kunnskapsbase (forkortet KB , kb eller Δ) er en spesiell type database for kunnskapshåndtering , som gir midler for datastyrt innsamling, organisering og gjenfinning av kunnskap . Også en samling data som representerer problemer med løsningene og relaterte erfaringer.

• En mobil database kan videreføres eller synkroniseres fra en mobil dataenhet.
• Operasjonelle databaser lagrer detaljerte data om driften av en organisasjon. De behandler vanligvis relativt store mengder oppdateringer ved hjelp av transaksjoner . Eksempler inkluderer kundedatabaser som registrerer kontakt-, kreditt- og demografisk informasjon om en virksomhets kunder, personaldatabaser som inneholder informasjon som lønn, fordeler, ferdighetsdata om ansatte, virksomhetsressursplanleggingssystemer som registrerer detaljer om produktkomponenter, delelager og økonomisk databaser som holder orden på organisasjonens penger, regnskap og økonomiske forhold.
• En parallell database søker å forbedre ytelsen gjennom parallellisering for oppgaver som å laste inn data, bygge indekser og evaluere spørringer.

De viktigste parallelle DBMS -arkitekturer som er indusert av den underliggende maskinvarearkitekturen er:

• Delt minnearkitektur , der flere prosessorer deler hovedminneplassen, samt annen datalagring.
• Delt diskarkitektur , hvor hver prosessorenhet (vanligvis bestående av flere prosessorer) har sitt eget hovedminne, men alle enhetene deler den andre lagringen.
• Delt-ingenting-arkitektur , hvor hver prosessorenhet har sitt eget hovedminne og annen lagring.

• Probabilistiske databaser bruker fuzzy logikk for å trekke slutninger fra upresise data.
• Sanntidsdatabaser behandler transaksjoner raskt nok til at resultatet kan komme tilbake og bli handlet med en gang.
• En romlig database kan lagre dataene med flerdimensjonale funksjoner. Spørringene om slike data inkluderer stedsbaserte spørsmål, for eksempel "Hvor er det nærmeste hotellet i mitt område?".
• En tidsbasert database har innebygde tidsaspekter, for eksempel en tidsmessig datamodell og en tidsmessig versjon av SQL . Nærmere bestemt inkluderer de tidsmessige aspektene vanligvis gyldig tid og transaksjonstid.
• En terminologi-orientert database bygger på en objektorientert database , ofte tilpasset et bestemt felt.
• En ustrukturert database er ment å lagre på en håndterlig og beskyttet måte forskjellige objekter som ikke passer naturlig og praktisk i vanlige databaser. Det kan inneholde e -postmeldinger, dokumenter, tidsskrifter, multimediaobjekter, etc. Navnet kan være misvisende siden noen objekter kan være svært strukturerte. Hele mulig objektsamling passer imidlertid ikke inn i et forhåndsdefinert strukturert rammeverk. De fleste etablerte DBMS støtter nå ustrukturerte data på forskjellige måter, og nye dedikerte DBMS -er dukker opp.

Databasestyringssystem

Connolly og Begg definerer databasesystem (DBMS) som et "programvaresystem som lar brukerne definere, opprette, vedlikeholde og kontrollere tilgang til databasen". Eksempler på DBMS inkluderer MySQL , PostgreSQL , Microsoft SQL Server , Oracle Database og Microsoft Access .

DBMS -forkortelsen utvides noen ganger for å indikere den underliggende databasemodellen , med RDBMS for relasjonen , OODBMS for objektet (orientert) og ORDBMS for objekt -relasjonsmodellen . Andre utvidelser kan indikere andre egenskaper, for eksempel DDBMS for distribuerte databasesystemer.

Funksjonaliteten som tilbys av et DBMS kan variere enormt. Kjernefunksjonaliteten er lagring, henting og oppdatering av data. Codd foreslo følgende funksjoner og tjenester som et fullverdig DBMS bør tilby:

• Datalagring, henting og oppdatering
• Brukertilgjengelig katalog eller dataliste som beskriver metadataene
• Støtte for transaksjoner og samtidighet
• Fasiliteter for å gjenopprette databasen hvis den skulle bli skadet
• Støtte for autorisasjon av tilgang og oppdatering av data
• Få tilgang til støtte fra eksterne steder
• Å håndheve begrensninger for å sikre at data i databasen overholder visse regler

Det er også generelt forventet at DBMS vil tilby et sett med verktøy for slike formål som kan være nødvendige for å administrere databasen effektivt, inkludert import, eksport, overvåking, defragmentering og analyseverktøy. Kjernedelen av DBMS som samhandler mellom databasen og applikasjonsgrensesnittet, noen ganger referert til som databasemotoren .

Ofte vil DBMS ha konfigurasjonsparametere som kan justeres statisk og dynamisk, for eksempel maksimal mengde hovedminne på en server databasen kan bruke. Trenden er å minimere mengden manuell konfigurasjon, og for tilfeller som innebygde databaser er behovet for å målrette null-administrasjon av største betydning.

DBMS -er for store virksomheter har en tendens til å øke i størrelse og funksjonalitet og kan ha involvert tusenvis av menneskelige års utviklingsarbeid gjennom livet.

Tidlig flerbruker-DBMS tillot vanligvis bare at applikasjonen kunne ligge på samme datamaskin med tilgang via terminaler eller programvare for terminalemulering. Den klient-server-arkitektur var en utvikling hvor programmet bodde på en klient stasjonær og databasen på serveren slik at behandlingen som skal fordeles. Dette utviklet seg til en multitier -arkitektur som inneholder applikasjonsservere og webservere med sluttbrukergrensesnittet via en nettleser med databasen bare direkte koblet til det tilstøtende nivået.

En generell DBMS vil tilby offentlige applikasjonsprogrammeringsgrensesnitt (API) og eventuelt en prosessor for databasespråk som SQL, slik at programmer kan skrives for å samhandle med databasen. Et DBMS for spesielle formål kan bruke et privat API og være spesielt tilpasset og knyttet til en enkelt applikasjon. For eksempel kan et e- postsystem som utfører mange av funksjonene i et DBMS for generelle formål, for eksempel innsetting av meldinger, sletting av meldinger, håndtering av vedlegg, oppslag av blokkeringslister, tilknytning av meldinger til en e-postadresse og så videre, men disse funksjonene er begrenset til det som kreves for å håndtere e -post.

applikasjon

Ekstern interaksjon med databasen vil være via et applikasjonsprogram som grensesnitt med DBMS. Dette kan variere fra et databaseverktøy som lar brukerne utføre SQL -spørsmål tekstmessig eller grafisk, til et nettsted som tilfeldigvis bruker en database til å lagre og søke etter informasjon.

Applikasjonsprogramgrensesnitt

En programmerer vil kode interaksjoner til databasen (noen ganger referert til som en datakilde ) via et applikasjonsprogramgrensesnitt (API) eller via et databasespråk . Det bestemte API -et eller språket som er valgt, må støttes av DBMS, mulig indirekte via en preprosessor eller et bro -API. Noen APIer har som mål å være databaseuavhengige, og ODBC er et kjent eksempel. Andre vanlige API -er inkluderer JDBC og ADO.NET .

Databasespråk

Databasespråk er språk for spesielle formål, som tillater en eller flere av følgende oppgaver, noen ganger utpekt som sublanguages :

• Datakontrollspråk (DCL) - kontrollerer tilgang til data;
• Data definition language (DDL) - definerer datatyper som å lage, endre eller slippe tabeller og forholdet mellom dem;
• Datamanipulasjon språk (DML) - utfører oppgaver som å sette inn, oppdatering eller sletting av dataforekomster;
• Data query language (DQL) - lar deg søke etter informasjon og beregne avledet informasjon.

Databasespråk er spesifikke for en bestemt datamodell. Viktige eksempler inkluderer:

• SQL kombinerer rollene til datadefinisjon, datamanipulering og spørring på et enkelt språk. Det var et av de første kommersielle språkene for relasjonsmodellen, selv om den på noen måter avviker fra relasjonsmodellen som beskrevet av Codd (for eksempel kan radene og kolonnene i en tabell bestilles). SQL ble en standard for American National Standards Institute (ANSI) i 1986, og av International Organization for Standardization (ISO) i 1987. Standardene har blitt forbedret jevnlig siden og støttes (med varierende grad av samsvar) av alle vanlige kommersielle relasjonelle DBMS.
• OQL er en språkstandard for objektmodeller (fra Object Data Management Group ). Det har påvirket utformingen av noen av de nyere spørrespråkene som JDOQL og EJB QL .
• XQuery er et standard XML-spørrespråk som er implementert av XML-databasesystemer som MarkLogic og eXist , av relasjonsdatabaser med XML-funksjoner som Oracle og DB2, og også av XML-prosessorer i minnet som Saxon .
• SQL/XML kombinerer XQuery med SQL.

Et databasespråk kan også inneholde funksjoner som:

• DBMS-spesifikk konfigurasjon og lagringsmotorstyring
• Beregninger for å endre søkeresultater, for eksempel telling, summering, gjennomsnitt, sortering, gruppering og kryssreferanser
• Begrensningshåndhevelse (f.eks. I en bildatabase, tillater bare én motortype per bil)
• Applikasjonsprogrammeringsgrensesnittversjon av spørrespråket, for bekvemmelighet for programmerere

Oppbevaring

Databaselagring er beholderen for den fysiske materialiseringen av en database. Den omfatter det interne (fysiske) nivået i databasearkitekturen. Den inneholder også all informasjon som trengs (f.eks. Metadata , "data om dataene" og interne datastrukturer ) for å rekonstruere det konseptuelle nivået og det eksterne nivået fra det interne nivået når det er nødvendig. Å sette data på permanent lagring er generelt databasemotorens ansvar, også kalt "lagermotor". Selv om det vanligvis er tilgjengelig for et DBMS gjennom det underliggende operativsystemet (og ofte bruker operativsystemets filsystemer som mellomprodukter for lagringsoppsett), er lagringsegenskaper og konfigurasjonsinnstillinger ekstremt viktige for effektiv drift av DBMS, og blir derfor nøye vedlikeholdt av databaseadministratorer. Et DBMS, mens det er i drift, har alltid sin database i flere typer lagring (f.eks. Minne og ekstern lagring). Databasedataene og ytterligere nødvendig informasjon, muligens i veldig store mengder, er kodet i biter. Data ligger vanligvis i lagringen i strukturer som ser helt annerledes ut enn dataene ser ut på det konseptuelle og eksterne nivået, men på måter som prøver å optimalisere (best mulig) rekonstruksjon av disse nivåene når det er nødvendig av brukere og programmer, også som for beregning av ytterligere typer nødvendig informasjon fra dataene (f.eks. når du spør databasen).

Noen DBMS støtter å spesifisere hvilken tegnkoding som ble brukt til å lagre data, så flere kodinger kan brukes i den samme databasen.

Ulike databaselagringsstrukturer på lavt nivå brukes av lagringsmotoren til å serialisere datamodellen, slik at den kan skrives til mediet du ønsker. Teknikker som indeksering kan brukes for å forbedre ytelsen. Konvensjonell lagring er radorientert, men det finnes også kolonneorienterte og korrelasjonsdatabaser .

Materialiserte visninger

Ofte brukes redundans for lagring for å øke ytelsen. Et vanlig eksempel er lagring av materialiserte visninger , som består av ofte nødvendige eksterne visninger eller spørringsresultater. Lagring av slike visninger sparer den dyre databehandlingen hver gang de trengs. Ulempene med materialiserte visninger er omkostningene som påløper når de oppdateres for å holde dem synkronisert med de opprinnelige oppdaterte databasedataene, og kostnadene for lagringsredundans.

Replikering

Noen ganger benytter en database lagringsredundans ved replikering av databaseobjekter (med en eller flere kopier) for å øke datatilgjengeligheten (både for å forbedre ytelsen til samtidige flere sluttbrukeradganger til det samme databaseobjektet, og for å gi spenst i tilfelle av delvis svikt i en distribuert database). Oppdateringer av et replikert objekt må synkroniseres mellom objektkopiene. I mange tilfeller replikeres hele databasen.

Sikkerhet

Databasesikkerhet omhandler alle ulike aspekter ved beskyttelse av databaseinnholdet, dets eiere og brukere. Det spenner fra beskyttelse fra forsettlig uautorisert bruk av databaser til utilsiktet databasetilgang fra uautoriserte enheter (f.eks. En person eller et dataprogram).

Datatilgangskontroll omhandler kontroll av hvem (en person eller et bestemt dataprogram) har tilgang til hvilken informasjon i databasen. Informasjonen kan omfatte spesifikke databaseobjekter (f.eks. Posttyper, spesifikke poster, datastrukturer), visse beregninger over bestemte objekter (f.eks. Spørringstyper eller spesifikke spørringer), eller bruk av spesifikke tilgangsveier til førstnevnte (f.eks. Ved bruk av spesifikke indekser eller andre datastrukturer for å få tilgang til informasjon). Tilgangskontroller for databaser angis av spesialautorisert (av databaseeieren) personell som bruker dedikerte beskyttede DBMS -grensesnitt.

Dette kan administreres direkte på individuell basis, eller ved tildeling av enkeltpersoner og privilegier til grupper, eller (i de mest utførlige modellene) gjennom tildeling av enkeltpersoner og grupper til roller som deretter får rettigheter. Datasikkerhet forhindrer uautoriserte brukere i å se eller oppdatere databasen. Ved å bruke passord får brukerne tilgang til hele databasen eller delsettene til den som kalles "undersjemaer". For eksempel kan en ansattedatabase inneholde alle dataene om en enkelt ansatt, men en gruppe brukere kan ha autorisasjon til å se bare lønnsdata, mens andre får tilgang til bare arbeidshistorikk og medisinske data. Hvis DBMS gir en måte å interaktivt gå inn og oppdatere databasen på, så vel som å avhøre den, tillater denne muligheten å administrere personlige databaser.

Datasikkerhet generelt handler om å beskytte spesifikke biter av data, både fysisk (dvs. mot korrupsjon, ødeleggelse eller fjerning, f.eks. Se fysisk sikkerhet ), eller tolkningen av dem eller deler av dem til meningsfull informasjon (f.eks. ser på strengene av biter de består av, konkluderer med spesifikke gyldige kredittkortnumre, f.eks. se datakryptering ).

Endre og få tilgang til loggposter som har tilgang til hvilke attributter, hva som ble endret og når de ble endret. Loggingstjenester åpner for en rettsmedisinsk databaseovervåking senere ved å føre oversikt over tilgangshendelser og endringer. Noen ganger brukes kode på applikasjonsnivå for å registrere endringer i stedet for å overlate dette til databasen. Overvåking kan settes opp for å prøve å oppdage sikkerhetsbrudd.

Transaksjoner og samtidighet

Databasetransaksjoner kan brukes til å introdusere et visst nivå av feiltoleranse og dataintegritet etter gjenoppretting etter et krasj . En databasetransaksjon er en arbeidsenhet, som vanligvis innkapsler et antall operasjoner over en database (f.eks. Å lese et databaseobjekt, skrive, skaffe lås , etc.), en abstraksjon som støttes i databasen og også andre systemer. Hver transaksjon har veldefinerte grenser når det gjelder hvilke program-/kodeutførelser som er inkludert i denne transaksjonen (bestemt av transaksjonens programmerer via spesielle transaksjonskommandoer).

Akronymet ACID beskriver noen ideelle egenskaper ved en databasetransaksjon: atomisitet , konsistens , isolasjon og holdbarhet .

Migrasjon

En database bygget med ett DBMS er ikke bærbar til et annet DBMS (dvs. den andre DBMS kan ikke kjøre den). I noen situasjoner er det imidlertid ønskelig å migrere en database fra ett DBMS til et annet. Årsakene er hovedsakelig økonomiske (forskjellige DBMS -er kan ha forskjellige totale eierkostnader eller TCO), funksjonelle og operasjonelle (forskjellige DBMS -er kan ha forskjellige evner). Migrasjonen innebærer databasens transformasjon fra en DBMS -type til en annen. Transformasjonen bør opprettholde (hvis mulig) det databaserelaterte programmet (dvs. alle relaterte applikasjonsprogrammer) intakt. Dermed bør databasens konseptuelle og eksterne arkitektoniske nivå opprettholdes i transformasjonen. Det kan være ønskelig at også noen aspekter ved arkitekturenes interne nivå opprettholdes. En kompleks eller stor databasemigrasjon kan være et komplisert og kostbart (engangs) prosjekt i seg selv, som bør tas med i beslutningen om å migrere. Dette til tross for at det kan finnes verktøy for å hjelpe migrering mellom spesifikke DBMS -er. Vanligvis tilbyr en DBMS -leverandør verktøy for å importere databaser fra andre populære DBMS -er.

Bygge, vedlikeholde og justere

Etter å ha designet en database for et program, er neste trinn å bygge databasen. Vanligvis kan en passende generell DBMS velges som skal brukes til dette formålet. Et DBMS gir de nødvendige brukergrensesnittene som skal brukes av databaseadministratorer for å definere den nødvendige applikasjonens datastrukturer i DBMSs respektive datamodell. Andre brukergrensesnitt brukes til å velge nødvendige DBMS -parametere (som sikkerhetsrelaterte parametere, lagringsallokeringsparametere, etc.).

Når databasen er klar (alle datastrukturer og andre nødvendige komponenter er definert), fylles den vanligvis med første applikasjons data (databaseinitialisering, som vanligvis er et tydelig prosjekt; i mange tilfeller ved bruk av spesialiserte DBMS -grensesnitt som støtter innsetting av masse) før gjør det operativt. I noen tilfeller blir databasen operativ mens den er tom for applikasjonsdata, og data akkumuleres under driften.

Etter at databasen er opprettet, initialisert og fylt ut, må den vedlikeholdes. Ulike databaseparametere må kanskje endres, og databasen må kanskje justeres ( tuning ) for bedre ytelse; applikasjons datastrukturer kan endres eller legges til, nye relaterte applikasjonsprogrammer kan skrives for å legge til applikasjonens funksjonalitet, etc.

Sikkerhetskopiering og gjenoppretting

Noen ganger er det ønskelig å bringe en database tilbake til en tidligere tilstand (av mange årsaker, for eksempel tilfeller der databasen blir funnet ødelagt på grunn av en programvarefeil, eller hvis den er oppdatert med feilaktige data). For å oppnå dette, utføres en sikkerhetskopieringsoperasjon av og til eller kontinuerlig, hvor hver ønsket databasetilstand (dvs. verdiene til dataene og deres innebygd i databasens datastrukturer) holdes innenfor dedikerte sikkerhetskopifiler (mange teknikker finnes for å gjøre dette effektivt). Når det er bestemt av en databaseadministrator å bringe databasen tilbake til denne tilstanden (f.eks. Ved å spesifisere denne tilstanden ved et ønsket tidspunkt når databasen var i denne tilstanden), brukes disse filene til å gjenopprette denne tilstanden.

Statisk analyse

Statisk analyseteknikk for programvareverifisering kan også brukes i scenariet med spørrespråk. Spesielt har rammeverket * Abstrakt tolkning blitt utvidet til feltet spørrespråk for relasjonsdatabaser som en måte å støtte lydtilnærmingsteknikker på. Semantikken i spørrespråk kan justeres i henhold til passende abstraksjoner av det konkrete domenedataet. Abstraksjonen av det relasjonelle databasesystemet har mange interessante applikasjoner, spesielt for sikkerhetsformål, for eksempel finkornet tilgangskontroll, vannmerker, etc.

Diverse funksjoner

Andre DBMS -funksjoner kan omfatte:

• Databaselogger - Dette hjelper deg med å holde en oversikt over de utførte funksjonene.
• Grafikkomponent for å produsere grafer og diagrammer, spesielt i et datalagringssystem.
• Query optimizer - Utfører spørringsoptimalisering for hver spørring for å velge en effektiv spørringsplan (en delrekkefølge (tre) av operasjoner) som skal utføres for å beregne spørringsresultatet. Kan være spesifikk for en bestemt lagringsmotor.
• Verktøy eller kroker for databasedesign, applikasjonsprogrammering, vedlikehold av applikasjonsprogram, analyse av databasens ytelse og overvåking, overvåkning av databasekonfigurasjon, DBMS -maskinvarekonfigurasjon (en DBMS og tilhørende database kan omfatte datamaskiner, nettverk og lagringsenheter) og tilhørende databasekartlegging (spesielt for en distribuert DBMS), lagertildeling og overvåkning av databaseoppsett, migrering av lagring, etc.

I økende grad blir det krav om et enkelt system som inkorporerer alle disse kjernefunksjonalitetene i det samme rammeverket for bygge, test og distribusjon for databaseadministrasjon og kildekontroll. Noen låner fra andre utviklinger i programvareindustrien og markedsfører slike tilbud som " DevOps for database".

Design og modellering

Den første oppgaven til en databasedesigner er å produsere en konseptuell datamodell som gjenspeiler strukturen til informasjonen som skal lagres i databasen. En vanlig tilnærming til dette er å utvikle en enhet -relasjonsmodell , ofte ved hjelp av tegneverktøy. En annen populær tilnærming er Unified Modeling Language . En vellykket datamodell vil nøyaktig gjenspeile den mulige tilstanden til den eksterne verdenen som modelleres: for eksempel hvis folk kan ha mer enn ett telefonnummer, vil den tillate denne informasjonen å bli fanget opp. Å designe en god konseptuell datamodell krever god forståelse av applikasjonsdomenet; det innebærer vanligvis å stille dype spørsmål om tingene som er interessante for en organisasjon, for eksempel "kan en kunde også være leverandør?", eller "hvis et produkt selges med to forskjellige former for emballasje, er det det samme produktet eller forskjellige produkter? ", eller" hvis et fly flyr fra New York til Dubai via Frankfurt, er det en eller to flyreiser (eller kanskje til og med tre)? ". Svarene på disse spørsmålene etablerer definisjoner av terminologien som brukes for enheter (kunder, produkter, flyreiser, flysegmenter) og deres relasjoner og attributter.

Å produsere den konseptuelle datamodellen innebærer noen ganger input fra forretningsprosesser , eller analyse av arbeidsflyt i organisasjonen. Dette kan bidra til å fastslå hvilken informasjon som trengs i databasen, og hva som kan utelates. Det kan for eksempel hjelpe når du skal avgjøre om databasen må inneholde historiske data så vel som nåværende data.

Etter å ha produsert en konseptuell datamodell som brukerne er fornøyd med, er neste trinn å oversette dette til et skjema som implementerer de relevante datastrukturer i databasen. Denne prosessen kalles ofte logisk databasedesign, og utgangen er en logisk datamodell uttrykt i form av et skjema. Mens den konseptuelle datamodellen (i det minste i teorien) er uavhengig av valget av databaseteknologi, vil den logiske datamodellen bli uttrykt i form av en bestemt databasemodell som støttes av det valgte DBMS. (Begrepene datamodell og databasemodell brukes ofte om hverandre, men i denne artikkelen bruker vi datamodell for utforming av en bestemt database og databasemodell for modelleringsnotasjonen som brukes for å uttrykke det designet).

Den mest populære databasemodellen for generelle databaser er relasjonsmodellen, eller mer presist, den relasjonsmodellen som er representert av SQL-språket. Prosessen med å lage et logisk databasedesign ved hjelp av denne modellen bruker en metodisk tilnærming kjent som normalisering . Målet med normalisering er å sikre at hvert elementære "faktum" bare registreres på ett sted, slik at innsetting, oppdatering og sletting automatisk opprettholder konsistens.

Den siste fasen av databasedesign er å ta avgjørelser som påvirker ytelse, skalerbarhet, gjenoppretting, sikkerhet og lignende, som er avhengige av det spesifikke DBMS. Dette kalles ofte fysisk databasedesign , og utdata er den fysiske datamodellen . Et sentralt mål i denne fasen er datauavhengighet , noe som betyr at beslutninger som tas for ytelsesoptimaliseringsformål bør være usynlige for sluttbrukere og applikasjoner. Det er to typer datauavhengighet: Fysisk datauavhengighet og logisk datauavhengighet. Fysisk design er hovedsakelig drevet av ytelseskrav, og krever god kunnskap om forventet arbeidsmengde og tilgangsmønstre, og en dyp forståelse av funksjonene som tilbys av det valgte DBMS.

Et annet aspekt ved fysisk databasedesign er sikkerhet. Det innebærer både å definere tilgangskontroll til databaseobjekter, så vel som å definere sikkerhetsnivåer og metoder for selve dataene.

Modeller

En databasemodell er en type datamodell som bestemmer den logiske strukturen til en database og grunnleggende bestemmer på hvilken måte data kan lagres, organiseres og manipuleres. Det mest populære eksemplet på en databasemodell er relasjonsmodellen (eller SQL-tilnærmingen til relasjonell), som bruker et tabellbasert format.

Vanlige logiske datamodeller for databaser inkluderer:

• Navigasjonsdatabaser
  • Hierarkisk databasemodell
  • Nettverksmodell
  • Grafisk database
• Forholdsmodell
• Entity -relation modell
  • Forbedret enhet -relasjonsmodell
• Objektmodell
• Dokumentmodell
• Enhet -attributt -verdimodell
• Stjerneskjema

En objekt -relasjonsdatabase kombinerer de to relaterte strukturene.

Fysiske datamodeller inkluderer:

• Omvendt indeks
• Flat fil

Andre modeller inkluderer:

• Flerdimensjonal modell
• Array modell
• Modell med flere verdier

Spesialiserte modeller er optimalisert for bestemte typer data:

• XML -database
• Semantisk modell
• Innholdsbutikk
• Arrangementsbutikk
• Tidsseriemodell

Eksternt, konseptuelt og internt

Et databasesystem gir tre visninger av databasedataene:

• Det eksterne nivået definerer hvordan hver gruppe sluttbrukere ser organisering av data i databasen. En enkelt database kan ha et hvilket som helst antall visninger på eksternt nivå.
• Det konseptuelle nivået forener de forskjellige ytre synspunktene til et kompatibelt globalt syn. Det gir syntese av alle de eksterne visningene. Det er utenfor omfanget av de forskjellige sluttbrukerne av databasen, og er heller interessant for utviklere av databaseapplikasjoner og databaseadministratorer.
• Det interne nivået (eller det fysiske nivået ) er den interne organisasjonen av data inne i et DBMS. Det er opptatt av kostnad, ytelse, skalerbarhet og andre operative forhold. Den omhandler lagringsoppsett for dataene, ved å bruke lagringsstrukturer som indekser for å forbedre ytelsen. Noen ganger lagrer den data for individuelle visninger ( materialiserte visninger ), beregnet ut fra generiske data, hvis det finnes ytelsesbegrunnelse for slik redundans. Den balanserer alle ytelseskravene til de eksterne visningene, muligens motstridende, i et forsøk på å optimalisere den generelle ytelsen på tvers av alle aktivitetene.

Selv om det vanligvis bare er én konseptuell (eller logisk) og fysisk (eller intern) visning av dataene, kan det være mange forskjellige eksterne visninger. Dette lar brukerne se databasinformasjon på en mer forretningsrelatert måte i stedet for fra et teknisk, behandlingsmessig synspunkt. For eksempel, en økonomisk avdeling av et selskap trenger betalings opplysninger om alle ansatte som en del av selskapets utgifter, men trenger ikke detaljer om ansatte som er av interesse for menneskelige ressurser avdelingen. Dermed trenger forskjellige avdelinger forskjellige visninger av selskapets database.

Databasearkitekturen på tre nivåer knytter seg til begrepet datauavhengighet som var en av de viktigste innledende drivkreftene til relasjonsmodellen. Tanken er at endringer gjort på et visst nivå ikke påvirker utsikten på et høyere nivå. For eksempel påvirker endringer på det interne nivået ikke applikasjonsprogrammer skrevet med konseptuelle nivågrensesnitt, noe som reduserer virkningen av å gjøre fysiske endringer for å forbedre ytelsen.

Det konseptuelle synet gir et nivå av indireksjon mellom indre og eksterne. På den ene siden gir den et felles syn på databasen, uavhengig av forskjellige eksterne visningsstrukturer, og på den andre siden abstraherer den bort detaljer om hvordan dataene lagres eller administreres (internt nivå). I prinsippet kan hvert nivå, og til og med alle eksterne visninger, presenteres av en annen datamodell. I praksis bruker vanligvis en gitt DBMS samme datamodell for både det eksterne og det konseptuelle nivået (f.eks. Relasjonsmodell). Det interne nivået, som er skjult inne i DBMS og er avhengig av implementeringen, krever et annet detaljnivå og bruker sine egne typer datastrukturtyper.

Å skille det eksterne , konseptuelle og interne nivået var et hovedtrekk ved implementeringen av den relasjonsbaserte databasemodellen som dominerer databaser fra det 21. århundre.

Forskning

Databaseteknologi har vært et aktivt forskningstema siden 1960 -tallet, både i akademia og i forsknings- og utviklingsgruppene til selskaper (for eksempel IBM Research ). Forskningsaktivitet inkluderer teori og utvikling av prototyper . Kjente forskningstema har inkludert modeller , atom transaksjonen konseptet, og relaterte samtidighet kontrollteknikker, spørrespråk og spørring optimalisering metoder, RAID , og mer.

Databaseforskningsområdet har flere dedikerte akademiske tidsskrifter (for eksempel ACM Transactions on Database Systems -TODS, Data and Knowledge Engineering -DKE) og årlige konferanser (f.eks. ACM SIGMOD , ACM PODS , VLDB , IEEE ICDE).

Se også

Merknader

Referanser

Kilder

Videre lesning

• Ling Liu og Tamer M. Özsu (red.) (2009). " Encyclopedia of Database Systems , 4100 s. 60 illus. ISBN  978-0-387-49616-0 .
• Gray, J. og Reuter, A. Transaction Processing: Concepts and Techniques , 1. utgave, Morgan Kaufmann Publishers, 1992.
• Kroenke, David M. og David J. Auer. Databasekonsepter. 3. utg. New York: Prentice, 2007.
• Raghu Ramakrishnan og Johannes Gehrke , Database Management Systems
• Abraham Silberschatz , Henry F. Korth, S. Sudarshan, Database System Concepts
• Lightstone, S .; Teorey, T .; Nadeau, T. (2007). Fysisk databasedesign: databaseprofesjonens guide til å utnytte indekser, visninger, lagring og mer . Morgan Kaufmann Press. ISBN 978-0-12-369389-1.
• Teorey, T .; Lightstone, S. og Nadeau, T. Database Modeling & Design: Logical Design , 4. utgave, Morgan Kaufmann Press, 2005. ISBN  0-12-685352-5

Eksterne linker

• DB Filutvidelse  - informasjon om filer med DB -utvidelsen