Databas -
Database

Från Wikipedia, den fria encyklopedin
En SQL select -sats och dess resultat

Inom databehandling är en databas en organiserad samling av data som lagras och nås elektroniskt från ett datasystem . Där databaser är mer komplexa utvecklas de ofta med formell design och modelleringsteknik .

Det databashanteringssystem ( DBMS ) är programvara som interagerar med slutanvändarna , program och själva databasen för att fånga och analysera data. DBMS -programvaran omfattar dessutom de kärnanläggningar som tillhandahålls för att administrera databasen. Summan av databasen, DBMS och tillhörande applikationer kan kallas ett "databassystem". Ofta används termen "databas" också löst för att hänvisa till någon av DBMS, databassystemet eller en applikation som är associerad med databasen.

Datavetare kan klassificera databashanteringssystem enligt databasmodellerna som de stöder. Relationsdatabaser blev dominerande på 1980 -talet. Dessa modelldata som rader och kolumner i en serie tabeller , och de allra flesta använder SQL för att skriva och söka efter data. På 2000-talet blev icke-relationsdatabaser populära, kallade NoSQL eftersom de använder olika frågespråk .

Terminologi och översikt

Formellt hänvisar en "databas" till en uppsättning relaterade data och hur den är organiserad. Åtkomst till denna data tillhandahålls vanligtvis av ett "databashanteringssystem" (DBMS) som består av en integrerad uppsättning dataprogramvara som tillåter användare att interagera med en eller flera databaser och ger åtkomst till all data i databasen (även om begränsningar kan finnas som begränsar åtkomsten till viss data). DBMS tillhandahåller olika funktioner som möjliggör inmatning, lagring och hämtning av stora mängder information och ger sätt att hantera hur informationen är organiserad.

På grund av det nära förhållandet mellan dem används termen "databas" ofta avslappnat för att hänvisa till både en databas och DBMS som används för att manipulera den.

Utanför världen av professionell informationsteknologi används termen databas ofta för att hänvisa till all samling av relaterade data (t.ex. ett kalkylblad eller ett kortindex) eftersom storlek och användningskrav vanligtvis kräver användning av ett databashanteringssystem.

Befintliga DBMS tillhandahåller olika funktioner som tillåter hantering av en databas och dess data som kan klassificeras i fyra huvudsakliga funktionella grupper:

  • Datadefinition - Skapande, modifiering och borttagning av definitioner som definierar organisation av data.
  • Uppdatering - Infogning, ändring och radering av faktiska data.
  • Hämtning - Tillhandahållande av information i en form som är direkt användbar eller för vidare behandling av andra applikationer. Den hämtade informationen kan göras tillgänglig i en form i princip samma som den lagras i databasen eller i en ny form erhållen genom att ändra eller kombinera befintlig data från databasen.
  • Administration - Registrering och övervakning av användare, upprätthållande av datasäkerhet, övervakning av prestanda, upprätthållande av dataintegritet, hantering av samtidighetskontroll och återställning av information som har skadats av en händelse, till exempel ett oväntat systemfel.

Både en databas och dess DBMS överensstämmer med principerna för en viss databasmodell . "Databassystem" refererar kollektivt till databasmodellen, databashanteringssystemet och databasen.

Fysiskt databasservrar är engagerade datorer som håller de faktiska databaser och köra bara DBMS och tillhörande programvara. Databasservrar är vanligtvis multiprocessordatorer , med generöst minne och RAID -diskar som används för stabil lagring. Maskinvarudatabasacceleratorer, anslutna till en eller flera servrar via en höghastighetskanal, används också i transaktionsbehandlingsmiljöer med stora volymer. DBMS finns i hjärtat av de flesta databasapplikationer . DBMS kan byggas kring en anpassad multitasking- kärna med inbyggt nätverksstöd , men moderna DBMS-enheter är vanligtvis beroende av ett standardoperativsystem för att tillhandahålla dessa funktioner.

Eftersom DBMS utgör en betydande marknad tar dator- och lagringsleverantörer ofta hänsyn till DBMS -kraven i sina egna utvecklingsplaner.

Databaser och DBMS kan kategoriseras enligt databasmodellerna som de stöder (t.ex. relationell eller XML), datortyp (er) som de körs på (från ett serverkluster till en mobiltelefon), frågespråket ( s) används för att komma åt databasen (t.ex. SQL eller XQuery ) och deras interna konstruktion, vilket påverkar prestanda, skalbarhet , motståndskraft och säkerhet.

Historia

Storleken, kapaciteten och prestandan för databaser och deras respektive DBMS har ökat i storleksordningar. Dessa prestandahöjningar möjliggjordes av teknikens framsteg inom processorer , datorminne , datorminne och datornätverk . Konceptet med en databas möjliggjordes genom uppkomsten av lagringsmedier med direktåtkomst, till exempel magnetiska diskar, som blev allmänt tillgängliga i mitten av 1960 -talet; tidigare system förlitade sig på sekventiell lagring av data på magnetband. Den efterföljande utvecklingen av databasteknik kan delas in i tre epoker baserade på datamodell eller struktur: navigering , SQL/ relationell och postrelationell.

De två huvudsakliga modellerna för tidig navigering var den hierarkiska modellen och CODASYL -modellen ( nätverksmodell ). Dessa kännetecknades av användning av pekare (ofta fysiska hårddiskadresser) för att följa relationer från en post till en annan.

Den relationsmodellen , först föreslogs 1970 av Edgar F. Codd , avvikit från denna tradition genom att insistera att ansökningar ska söka efter information genom innehåll, snarare än genom att följa länkar. Relationsmodellen använder uppsättningar tabeller i huvudbokstil, var och en som används för en annan typ av enhet. Först i mitten av 1980-talet blev datormaskinvaran tillräckligt kraftfull för att möjliggöra bred distribution av relationssystem (DBMS plus applikationer). I början av 1990-talet dominerade dock relationssystemen i alla storskaliga databehandlingsapplikationer , och från och med 2018 är de fortfarande dominerande: IBM DB2 , Oracle , MySQL och Microsoft SQL Server är det mest sökta DBMS . Det dominerande databasspråket, standardiserad SQL för relationsmodellen, har påverkat databasspråk för andra datamodeller.

Objektdatabaser utvecklades på 1980-talet för att övervinna besväret med objektivrelationell impedansmatchning , vilket ledde till att begreppet "post-relationellt" myntades och även utvecklingen av hybridobjekt -relationsdatabaser .

Nästa generation av post-relationsdatabaser i slutet av 2000-talet blev känd som NoSQL- databaser och introducerade snabba nyckelvärdesbutiker och dokumentorienterade databaser . En konkurrerande "nästa generation", känd som NewSQL -databaser, försökte till nya implementeringar som behöll den relationella/SQL -modellen samtidigt som de syftade till att matcha NoSQL: s höga prestanda jämfört med kommersiellt tillgängliga relations -DBMS.

1960 -talet, navigations -DBMS

Grundstruktur för navigations -CODASYL -databasmodell

Införandet av termen databas sammanföll med tillgången till lagring med direktåtkomst (diskar och trummor) från mitten av 1960-talet och framåt. Termen representerade en kontrast med de tidigare bandbaserade systemen, vilket möjliggjorde delad interaktiv användning snarare än daglig batchbehandling . Den Oxford English Dictionary citerar en 1962 rapport från System Development Corporation of California som den första att använda termen "databas" i en viss teknisk mening.

När datorer växte i hastighet och kapacitet, uppstod ett antal generella databassystem; i mitten av 1960-talet hade ett antal sådana system kommit i kommersiell användning. Intresset för en standard började växa och Charles Bachman , författare till en sådan produkt, Integrated Data Store (IDS), grundade Database Task Group inom CODASYL , gruppen som ansvarar för skapandet och standardiseringen av COBOL . År 1971 levererade Database Task Group sin standard, som i allmänhet blev känd som CODASYL -metoden , och snart kom ett antal kommersiella produkter baserade på detta tillvägagångssätt på marknaden.

CODASYL -metoden gav applikationer möjlighet att navigera runt en länkad datamängd som formades till ett stort nätverk. Applikationer kan hitta poster med en av tre metoder:

  1. Användning av en primär nyckel (känd som en CALC -nyckel, vanligtvis implementerad genom hashing )
  2. Navigera relationer (kallade uppsättningar ) från en post till en annan
  3. Skannar alla poster i en ordningsföljd

Senare system lade till B-träd för att tillhandahålla alternativa åtkomstvägar. Många CODASYL -databaser har också lagt till ett deklarativt frågespråk för slutanvändare (skiljer sig från navigations -API: et). CODASYL -databaser var dock komplexa och krävde betydande utbildning och ansträngning för att producera användbara applikationer.

IBM hade också sitt eget DBMS 1966, känt som Information Management System (IMS). IMS var en utveckling av programvara skriven för Apollo -programmetSystem/360 . IMS liknade generellt CODASYL i begreppet, men använde en strikt hierarki för sin modell av datanavigering istället för CODASYLs nätverksmodell. Båda begreppen blev senare kända som navigationsdatabaser på grund av sättet att komma åt data: termen populariserades av Bachmans 1973 Turing Award -presentation The Programmer as Navigator . IMS klassificeras av IBM som en hierarkisk databas . IDMS och Cincom Systems " TOTAL databas klassificeras som nätverksdatabaser. IMS används fortfarande från och med 2014.

1970 -talet, relationell DBMS

Edgar F. Codd arbetade på IBM i San Jose, Kalifornien , i ett av deras offshoot -kontor som främst deltog i utvecklingen av hårddisksystem . Han var missnöjd med navigationsmodellen för CODASYL -tillvägagångssättet, särskilt avsaknaden av en "sök" -funktion. År 1970 skrev han ett antal papper som beskrev ett nytt tillvägagångssätt för konstruktion av databaser som så småningom kulminerade i den banbrytande A Relational Model of Data för stora delade databanker .

I detta dokument beskriver han ett nytt system för lagring och arbete med stora databaser. I stället för att poster lagras i någon form av länkad lista över fria formposter som i CODASYL, var Codds idé att organisera data som ett antal " tabeller ", där varje tabell används för en annan typ av enhet. Varje tabell skulle innehålla ett fast antal kolumner som innehåller enhetens attribut. En eller flera kolumner i varje tabell betecknades som en primär nyckel genom vilken raderna i tabellen kunde identifieras unikt; korsreferenser mellan tabeller använde alltid dessa primära nycklar, snarare än diskadresser, och frågor skulle sammanfoga tabeller baserade på dessa nyckelrelationer, med hjälp av en uppsättning operationer baserade på det matematiska systemet för relationsberäkning (från vilken modellen har fått sitt namn). Uppdelning av data i en uppsättning normaliserade tabeller (eller relationer ) som syftar till att säkerställa att varje "faktum" bara lagrades en gång, vilket förenklar uppdateringsoperationer. Virtuella tabeller som kallas vyer kan presentera data på olika sätt för olika användare, men vyer kunde inte uppdateras direkt.

Codd använde matematiska termer för att definiera modellen: relationer, tupler och domäner snarare än tabeller, rader och kolumner. Den terminologi som nu är bekant kom från tidiga implementeringar. Codd skulle senare kritisera tendensen för praktiska implementeringar att avvika från de matematiska grunderna som modellen baserades på.

I relationsmodellen "länkas" poster med hjälp av virtuella nycklar som inte lagras i databasen men definieras efter behov mellan data som finns i posterna.

Användningen av primära nycklar (användarorienterade identifierare) för att representera relationer över bord, snarare än diskadresser, hade två primära motiv. Ur ett teknikperspektiv möjliggjorde det att flytta och ändra storlek på tabeller utan dyr databasreorganisering. Men Codd var mer intresserad av skillnaden i semantik: användningen av uttryckliga identifierare gjorde det lättare att definiera uppdateringsoperationer med rena matematiska definitioner, och det möjliggjorde också att definiera frågefunktioner i termer av den etablerade disciplinen första ordningens predikatberäkning ; eftersom dessa operationer har rena matematiska egenskaper blir det möjligt att skriva om frågor på bevisligen korrekta sätt, vilket är grunden för frågeoptimering. Det går ingen förlust av uttrycksfullhet jämfört med hierarkiska eller nätverksmodeller, även om kopplingarna mellan tabeller inte längre är så tydliga.

I hierarkiska och nätverksmodeller fick poster ha en komplex intern struktur. Till exempel kan en anställds lönehistorik representeras som en "upprepande grupp" i medarbetarregistret. I relationsmodellen ledde normaliseringsprocessen till att sådana interna strukturer ersattes av data som finns i flera tabeller, endast anslutna med logiska nycklar.

Till exempel är en vanlig användning av ett databassystem att spåra information om användare, deras namn, inloggningsinformation, olika adresser och telefonnummer. I navigationsmetoden skulle all denna data placeras i en enda post med variabel längd. I det relationella tillvägagångssättet skulle data normaliseras till en användartabell, en adresstabell och ett telefonnumertabell (till exempel). Registreringar skulle skapas i dessa valfria tabeller endast om adressen eller telefonnumren faktiskt angavs.

Förutom att identifiera rader/poster med hjälp av logiska identifierare snarare än diskadresser, ändrade Codd hur applikationer samlade data från flera poster. I stället för att kräva att program samlar in data en post i taget genom att navigera i länkarna, skulle de använda ett deklarativt frågespråk som uttryckte vilken data som krävdes, snarare än den åtkomstväg som den skulle hitta. Att hitta en effektiv åtkomstväg till data blev ansvaret för databashanteringssystemet, snarare än applikationsprogrammeraren. Denna process, kallad frågeoptimering, berodde på att frågor uttrycktes i matematisk logik.

Codds papper hämtades av två personer i Berkeley, Eugene Wong och Michael Stonebraker . De startade ett projekt som kallas INGRES med hjälp av finansiering som redan hade tilldelats ett geografiskt databasprojekt och studentprogrammerare för att ta fram kod. Från och med 1973 levererade INGRES sina första testprodukter som i allmänhet var redo för utbredd användning 1979. INGRES liknade System R på ett antal sätt, inklusive användning av ett "språk" för datatillgång , kallat QUEL . Med tiden flyttade INGRES till den nya SQL -standarden.

IBM själv gjorde ett testimplementering av relationsmodellen, PRTV , och en produktionsmodell, Business System 12 , båda nu avbrutna. Honeywell skrev MRDS för Multics , och nu finns det två nya implementeringar: Alphora Dataphor och Rel . De flesta andra DBMS -implementeringar som vanligtvis kallas relationella är faktiskt SQL DBMS.

År 1970 började University of Michigan utvecklingen av MICRO Information Management System baserat på DL Childs set-teoretiska datamodell. MICRO användes för att hantera mycket stora datamängder av US Department of Labor , US Environmental Protection Agency och forskare från University of Alberta , University of Michigan och Wayne State University . Den kördes på IBM -stordatorer med Michigan Terminal System . Systemet förblev i produktion fram till 1998.

Integrerad strategi

Under 1970- och 1980 -talen försökte man bygga databassystem med integrerad hårdvara och programvara. Den bakomliggande filosofin var att en sådan integration skulle ge högre prestanda till en lägre kostnad. Exempel var IBM System/38 , det tidiga erbjudandet av Teradata , och Britton Lee, Inc. databasmaskin.

Ett annat tillvägagångssätt för hårdvarusupport för databashantering var ICL : s CAFS -accelerator , en hårddiskskontroller med programmerbara sökfunktioner. På lång sikt misslyckades dessa insatser i allmänhet eftersom specialiserade databasmaskiner inte kunde hålla jämna steg med den snabba utvecklingen och utvecklingen av datorer för allmänt bruk. Således är de flesta databassystem numera mjukvarusystem som körs på hårdvara för allmänna ändamål, som använder datalagring för allmänt ändamål. Denna idé drivs dock fortfarande för vissa applikationer av vissa företag som Netezza och Oracle ( Exadata ).

Sent 1970 -tal, SQL DBMS

IBM började arbeta med ett prototypsystem löst baserat på Codds koncept som System R i början av 1970 -talet. Den första versionen var klar 1974/5 och arbetet påbörjades sedan med flerbordssystem där data kunde delas upp så att alla data för en post (varav några är valfria) inte behövde lagras i en enda stor "bit". Efterföljande fleranvändarversioner testades av kunderna 1978 och 1979, då hade ett standardiserat frågespråk- SQL-lagts till. Codds idéer etablerade sig som både fungerande och överlägsna CODASYL, vilket tvingade IBM att utveckla en äkta produktionsversion av System R, känd som SQL/DS , och senare Database 2 ( DB2 ).

Larry Ellisons Oracle Database (eller helt enkelt Oracle ) startade från en annan kedja, baserat på IBMs papper om System R. Även om Oracle V1 -implementeringarna slutfördes 1978, var det inte förrän Oracle Version 2 när Ellison slog IBM på marknaden 1979.

Stonebraker använde lektionerna från INGRES för att utveckla en ny databas, Postgres, som nu kallas PostgreSQL . PostgreSQL används ofta för globala missionskritiska applikationer (.org- och .info-domännamnsregistren använder det som sin primära datalagring , liksom många stora företag och finansinstitut).

I Sverige lästes också Codds tidning och Mimer SQL utvecklades från mitten av 1970-talet vid Uppsala universitet . År 1984 konsoliderades detta projekt till ett oberoende företag.

En annan datamodell, entitetsrelationsmodellen , växte fram 1976 och blev populär för databasdesign eftersom den betonade en mer bekant beskrivning än den tidigare relationsmodellen. Senare eftermonterades entitet -relationskonstruktioner som en datamodellkonstruktion för relationsmodellen, och skillnaden mellan de två har blivit irrelevant.

1980 -talet, på skrivbordet

1980 -talet inledde en ålder av stationära datorer . De nya datorerna gav sina användare möjlighet till kalkylblad som Lotus 1-2-3 och databasprogram som dBASE . Produkten dBASE var lätt och lätt att förstå för alla datoranvändare. C. Wayne Ratliff , skaparen av dBASE, sade: "dBASE skilde sig från program som BASIC, C, FORTRAN och COBOL genom att mycket av det smutsiga arbetet redan hade utförts. Datamanipulationen utförs av dBASE istället för av användaren, så att användaren kan koncentrera sig på vad han gör, snarare än att behöva bråka med de smutsiga detaljerna om att öppna, läsa och stänga filer och hantera utrymmetilldelning. " dBASE var en av de mest sålda programvarutitlarna på 1980 -talet och början av 1990 -talet.

1990-tal, objektorienterad

1990-talet, tillsammans med en ökning av objektorienterad programmering , såg en tillväxt i hur data i olika databaser hanterades. Programmerare och designers började behandla data i sina databaser som objekt . Det vill säga att om en persons data fanns i en databas, ansågs den personens attribut, såsom deras adress, telefonnummer och ålder, tillhöra den personen istället för att vara främmande data. Detta gör att relationer mellan data kan vara relationer till objekt och deras attribut och inte till enskilda fält. Termen " objekt -relationell impedansmatchning " beskrev besväret med att översätta mellan programmerade objekt och databastabeller. Objektdatabaser och objektrelationsdatabaser försöker lösa detta problem genom att tillhandahålla ett objektorienterat språk (ibland som tillägg till SQL) som programmerare kan använda som alternativ till rent relationell SQL. På programmeringssidan försöker bibliotek som kallas objektrelationella mappningar (ORM) lösa samma problem.

2000 -talet, NoSQL och NewSQL

XML-databaser är en typ av strukturerad dokumentorienterad databas som tillåter förfrågningar baserade på XML- dokumentattribut. XML -databaser används mestadels i applikationer där data bekvämt ses som en samling av dokument, med en struktur som kan variera från mycket flexibel till mycket stel: exempel inkluderar vetenskapliga artiklar, patent, skatteavgifter och personaljournaler.

NoSQL -databaser är ofta väldigt snabba, kräver inte fasta tabellscheman, undviker sammankoppling genom att lagra denormaliserade data och är utformade för att skala horisontellt .

Under de senaste åren har det varit en stark efterfrågan på massivt distribuerade databaser med hög partitionstolerans, men enligt CAP -satsen är det omöjligt för ett distribuerat system att samtidigt tillhandahålla konsekvens , tillgänglighet och partitionstoleransgarantier. Ett distribuerat system kan uppfylla två av dessa garantier samtidigt, men inte alla tre. Av den anledningen använder många NoSQL -databaser vad som kallas eventuell konsistens för att ge både tillgänglighet och partitionstoleransgarantier med minskad datakonsistens.

NewSQL är en klass av moderna relationsdatabaser som syftar till att ge samma skalbara prestanda för NoSQL-system för onlinetransaktionsbearbetning (läs-skriv) arbetsbelastningar samtidigt som man använder SQL och bibehåller ACID- garantierna för ett traditionellt databassystem.

Användningsfall

Databaser används för att stödja interna verksamheter i organisationer och för att stödja online -interaktioner med kunder och leverantörer (se Enterprise -programvara ).

som samlingar av webbsidor i en databas.

Klassificering

Ett sätt att klassificera databaser innefattar typen av innehåll, till exempel: bibliografiska , dokument-text, statistiska eller multimediaobjekt. Ett annat sätt är genom deras tillämpningsområde, till exempel: bokföring, musikkompositioner, filmer, bank, tillverkning eller försäkring. Ett tredje sätt är av någon teknisk aspekt, till exempel databasstrukturen eller gränssnittstypen. Detta avsnitt listar några av de adjektiv som används för att karakterisera olika typer av databaser.

  • En in-memory-databas är en databas som främst finns i huvudminnet , men som vanligtvis säkerhetskopieras av icke-flyktig datalagring. Huvudminnesdatabaser är snabbare än diskdatabaser och används därför ofta där responstiden är kritisk, till exempel i utrustning för telekommunikationsnät.
  • En aktiv databas innehåller en händelsedriven arkitektur som kan svara på förhållanden både i och utanför databasen. Möjliga användningsområden inkluderar säkerhetsövervakning, varning, statistikinsamling och auktorisering. Många databaser tillhandahåller aktiva databasfunktioner i form av databasutlösare .
  • En molndatabas bygger på molnteknik . Både databasen och de flesta av dess DBMS finns på distans, "i molnet", medan dess applikationer både utvecklas av programmerare och senare underhålls och används av slutanvändare via en webbläsare och öppna API: er .
  • Datalager arkiverar data från operativa databaser och ofta från externa källor som marknadsundersökningsföretag. Lagret blir den centrala datakällan för chefer och andra slutanvändare som kanske inte har tillgång till operativ data. Till exempel kan försäljningsdata aggregeras till veckototaler och konverteras från interna produktkoder för att använda UPC: er så att de kan jämföras med ACNielsen -data . Några grundläggande och väsentliga komponenter i datalagring inkluderar att extrahera, analysera och bryta data, transformera, ladda och hantera data för att göra dem tillgängliga för vidare användning.
  • En deduktiv databas kombinerar logisk programmering med en relationsdatabas.
  • En distribuerad databas är en där både data och DBMS spänner över flera datorer.
  • En dokumentorienterad databas är utformad för att lagra, hämta och hantera dokumentorienterad eller halvstrukturerad information. Dokumentorienterade databaser är en av huvudkategorierna i NoSQL-databaser.
  • Ett inbäddat databassystem är ett DBMS som är tätt integrerat med en programvara som kräver åtkomst till lagrad data på ett sådant sätt att DBMS är dolt för applikationens slutanvändare och kräver lite eller inget pågående underhåll.
  • Slutanvändardatabaser består av data som utvecklats av enskilda slutanvändare. Exempel på dessa är samlingar av dokument, kalkylblad, presentationer, multimedia och andra filer. Flera produkter finns för att stödja sådana databaser. Några av dem är mycket enklare än fullvärdiga DBMS, med mer elementär DBMS-funktionalitet.
  • Ett federerat databassystem består av flera olika databaser, var och en med sitt eget DBMS. Den hanteras som en enda databas av ett federerat databashanteringssystem (FDBMS), som transparent integrerar flera autonoma DBMS, möjligen av olika typer (i så fall skulle det också vara ett heterogent databassystem ), och ger dem en integrerad konceptuell vy .
  • Ibland används termen multidatabas som en synonym till en federerad databas, även om den kan referera till en mindre integrerad (t.ex. utan ett FDBMS och ett hanterat integrerat schema) en grupp databaser som samarbetar i en enda applikation. I det här fallet används vanligtvis middleware för distribution, som vanligtvis inkluderar ett atomic commit-protokoll (ACP), t.ex. tvåfas-commit-protokollet , för att tillåta distribuerade (globala) transaktioner över de deltagande databaserna.
  • En grafdatabas är en slags NoSQL -databas som använder grafstrukturer med noder, kanter och egenskaper för att representera och lagra information. Allmänna grafdatabaser som kan lagra vilken graf som helst skiljer sig från specialiserade grafdatabaser som triplestorer och nätverksdatabaser .
  • En array-DBMS är ett slags NoSQL DBMS som tillåter modellering, lagring och hämtning av (vanligtvis stora) flerdimensionella matriser som satellitbilder och klimatsimuleringsutdata.
  • I en hypertext- eller hypermediedatabas kan varje ord eller en text som representerar ett objekt, t.ex. en annan text, en artikel, en bild eller en film, länkas till det objektet. Hypertextdatabaser är särskilt användbara för att organisera stora mängder olika information. Till exempel är de användbara för att organisera online -uppslagsverk , där användare enkelt kan hoppa runt i texten. Den World Wide Web är alltså en stor distribuerad hyper databas.
  • En kunskapsbas (förkortad KB , kb eller Δ) är en speciell typ av databas för kunskapshantering som tillhandahåller medel för datoriserad insamling, organisation och hämtning av kunskap . Också en samling data som representerar problem med deras lösningar och relaterade erfarenheter.
  • En mobil databas kan föras vidare eller synkroniseras från en mobil datoranordning.
  • Operativa databaser lagrar detaljerad information om hur en organisation fungerar. De behandlar vanligtvis relativt stora volymer uppdateringar med hjälp av transaktioner . Exempel inkluderar kunddatabaser som registrerar kontakt-, kredit- och demografisk information om ett företags kunder, personaldatabaser som innehåller information som lön, förmåner, kompetensdata om anställda, företagsresursplaneringssystem som registrerar detaljer om produktkomponenter, reservdelar och ekonomi databaser som håller reda på organisationens pengar, bokföring och ekonomiska affärer.
  • En parallell databas försöker förbättra prestanda genom parallellisering för uppgifter som att ladda data, bygga index och utvärdera frågor.
De stora parallella DBMS -arkitekturerna som induceras av den underliggande maskinvaruarkitekturen är:
  • Delad minnesarkitektur , där flera processorer delar huvudminnesutrymmet, liksom annan datalagring.
  • Delad diskarkitektur , där varje processorenhet (vanligtvis består av flera processorer) har sitt eget huvudminne, men alla enheter delar den andra lagringen.
  • Arkitektur med ingenting , där varje processorenhet har sitt eget huvudminne och annan lagring.
  • Probabilistiska databaser använder suddig logik för att dra slutsatser från oprecisa data.
  • Realtidsdatabaser bearbetar transaktioner tillräckligt snabbt för att resultatet ska kunna komma tillbaka och ageras direkt.
  • En rumslig databas kan lagra data med flerdimensionella funktioner. Frågorna om sådan information inkluderar platsbaserade frågor, till exempel "Var är det närmaste hotellet i mitt område?".
  • En tidsdatabas har inbyggda tidsaspekter, till exempel en tidsmässig datamodell och en tidsversion av SQL . Mer specifikt inkluderar de tidsmässiga aspekterna vanligtvis giltig tid och transaktionstid.
  • En terminologi-orienterad databas bygger på en objektorienterad databas , ofta anpassad för ett specifikt fält.
  • En ostrukturerad databas är avsedd att på ett hanterbart och skyddat sätt lagra olika objekt som inte passar naturligt och bekvämt i vanliga databaser. Det kan innehålla e -postmeddelanden, dokument, tidskrifter, multimediaobjekt etc. Namnet kan vara vilseledande eftersom vissa objekt kan vara mycket strukturerade. Hela den möjliga objektsamlingen passar dock inte in i ett fördefinierat strukturerat ramverk. De flesta etablerade DBMS stöder nu ostrukturerad data på olika sätt och nya dedikerade DBMS växer fram.

Databashanteringssystem

Connolly och Begg definierar databashanteringssystem (DBMS) som ett "mjukvarusystem som gör det möjligt för användare att definiera, skapa, underhålla och kontrollera åtkomst till databasen". Exempel på DBMS inkluderar MySQL , PostgreSQL , Microsoft SQL Server , Oracle Database och Microsoft Access .

. Andra tillägg kan indikera någon annan egenskap, till exempel DDBMS för ett distribuerat databashanteringssystem.

Funktionen som tillhandahålls av ett DBMS kan variera enormt. Kärnfunktionen är lagring, hämtning och uppdatering av data. Codd föreslog följande funktioner och tjänster som ett fullvärdigt allmänt DBMS bör tillhandahålla:

  • Datalagring, hämtning och uppdatering
  • Användartillgänglig katalog eller datalogg som beskriver metadata
  • Support för transaktioner och samtidighet
  • Faciliteter för att återställa databasen om den skulle skadas
  • Stöd för auktorisering av åtkomst och uppdatering av data
  • Få åtkomst till support från avlägsna platser
  • Att tvinga fram begränsningar för att säkerställa att data i databasen följer vissa regler

Det är också allmänt att förvänta sig att DBMS kommer att tillhandahålla en uppsättning verktyg för sådana ändamål som kan vara nödvändiga för att administrera databasen effektivt, inklusive import, export, övervakning, defragmentering och analysverktyg. Kärnan i DBMS som interagerar mellan databasen och applikationsgränssnittet kallas ibland databasmotorn .

Ofta kommer DBMS att ha konfigurationsparametrar som kan justeras statiskt och dynamiskt, till exempel den maximala mängden huvudminne på en server som databasen kan använda. Trenden är att minimera mängden manuell konfiguration, och för fall som inbäddade databaser är behovet av att rikta nolladministration av största vikt.

De stora stora företags DBMS har tenderat att öka i storlek och funktionalitet och kan ha involverat tusentals mänskliga år av utvecklingsinsatser under sin livstid.

Tidigare fleranvändar-DBMS tillät vanligtvis bara att applikationen kan ligga på samma dator med åtkomst via terminaler eller terminalemuleringsprogramvara. Den klient-server-arkitektur var en utveckling där ansökan var bosatt på en klient skrivbord och databasen på en server så att behandlingen ska fördelas. Detta utvecklades till en multitier -arkitektur som innehåller applikationsservrar och webbservrar med slutanvändargränssnittet via en webbläsare där databasen bara är direkt ansluten till den intilliggande nivån.

Ett DBMS för allmänna ändamål kommer att tillhandahålla offentliga programgränssnitt (API) och eventuellt en processor för databasspråk som SQL så att applikationer kan skrivas för att interagera med databasen. Ett speciellt DBMS kan använda ett privat API och vara specifikt anpassat och länkat till en enda applikation. Till exempel kan ett e- postsystem som utför många av funktionerna i ett DBMS för allmänna ändamål, till exempel infogning av meddelanden, radering av meddelanden, hantering av bilagor, sökning av blocklista, koppla meddelanden till en e-postadress och så vidare, men dessa funktioner är begränsade till vad som krävs för att hantera e-post.

Ansökan

Extern interaktion med databasen kommer att ske via ett applikationsprogram som har gränssnitt för DBMS. Detta kan sträcka sig från ett databasverktyg som tillåter användare att utföra SQL -frågor textmässigt eller grafiskt, till en webbplats som råkar använda en databas för att lagra och söka information.

Gränssnitt för applikationsprogram

En programmerare kommer att koda interaktioner till databasen (ibland kallad en datakälla ) via ett applikationsprogramgränssnitt (API) eller via ett databasspråk . Det specifika API eller det valda språket måste stödjas av DBMS, möjligt indirekt via en förbehandlare eller ett överbryggande API. Vissa API: s syftar till att vara databasoberoende, ODBC är ett allmänt känt exempel. Andra vanliga API: er inkluderar JDBC och ADO.NET .

Databas språk

Databasspråk är specialspråk, som tillåter en eller flera av följande uppgifter, som ibland skiljer sig som sublanguages :

Databasspråk är specifika för en viss datamodell. Anmärkningsvärda exempel inkluderar:

  • SQL kombinerar rollerna för datadefinition, datamanipulering och fråga på ett enda språk. Det var ett av de första kommersiella språken för relationsmodellen, även om den i vissa avseenden avviker från relationsmodellen som beskrivs av Codd (till exempel kan raderna och kolumnerna i en tabell beställas). SQL blev en standard för American National Standards Institute (ANSI) 1986 och av International Organization for Standardization (ISO) 1987. Standarderna har förbättrats regelbundet sedan och stöds (med varierande grad av överensstämmelse) av alla vanliga kommersiella relationella DBMS.
  • OQL är en språkstandard för objektmodeller (från Object Data Management Group ). Det har påverkat utformningen av några av de nyare frågespråken som JDOQL och EJB QL .
  • XQuery är ett standard XML-frågespråk som implementeras av XML-databassystem som MarkLogic och eXist , av relationsdatabaser med XML-kapacitet som Oracle och DB2, och även av XML-processorer i minnet som Saxon .
  • SQL/XML kombinerar XQuery med SQL.

Ett databasspråk kan också innehålla funktioner som:

  • DBMS-specifik konfiguration och lagringsmotorhantering
  • Beräkningar för att ändra sökresultat, som att räkna, summera, medelvärde, sortera, gruppera och korsreferera
  • Begränsningshantering (t.ex. i en fordonsdatabas, tillåter endast en motortyp per bil)
  • Applikationsprogrammeringsgränssnittsversion av frågespråket, för programmerarens bekvämlighet

Lagring

som mellanprodukter för lagringslayout), är lagringsegenskaper och konfigurationsinställningar oerhört viktiga för effektiv drift av DBMS och underhålls därför noga av databasadministratörer. Ett DBMS, medan det är i drift, har alltid sin databas i flera typer av lagring (t.ex. minne och extern lagring). Databasdata och ytterligare information som behövs, möjligen i mycket stora mängder, kodas till bitar. Data finns vanligtvis i lagringen i strukturer som ser helt annorlunda ut än hur data ser ut på konceptuella och externa nivåer, men på sätt som försöker optimera (bästa möjliga) rekonstruktion av dessa nivåer när det behövs av användare och program, liksom som för beräkning av ytterligare typer av nödvändig information från data (t.ex. när du frågar databasen).

Vissa DBMS stöder att specificera vilken teckenkodning som användes för att lagra data, så flera kodningar kan användas i samma databas.

Olika databaslagringsstrukturer på låg nivå används av lagringsmotorn för att serialisera datamodellen så att den kan skrivas till det valda mediet. Tekniker som indexering kan användas för att förbättra prestanda. Konventionell lagring är radorienterad, men det finns också kolumnorienterade och korrelationsdatabaser .

Materialiserade vyer

Ofta används lagringsredundans för att öka prestanda. Ett vanligt exempel är att lagra materialiserade vyer , som består av ofta nödvändiga externa vyer eller sökresultat. Att lagra sådana vyer sparar den dyra beräkningen av dem varje gång de behövs. Nackdelarna med materialiserade vyer är de omkostnader som uppstår när de uppdateras för att hålla dem synkroniserade med deras ursprungliga uppdaterade databasdata och kostnaden för lagringsredundans.

Replikering

Ibland använder en databas lagringsredundans genom replikering av databasobjekt (med en eller flera kopior) för att öka datatillgängligheten (både för att förbättra prestanda för samtidiga åtkomst till flera slutanvändare till samma databasobjekt och för att ge motståndskraft i fall av partiellt misslyckande av en distribuerad databas). Uppdateringar av ett replikerat objekt måste synkroniseras mellan objektkopiorna. I många fall replikeras hela databasen.

säkerhet

Databasesäkerhet behandlar alla olika aspekter av att skydda databasinnehållet, dess ägare och dess användare. Det sträcker sig från skydd från avsiktliga obehöriga databasanvändningar till oavsiktlig databasåtkomst av obehöriga enheter (t.ex. en person eller ett datorprogram).

Databasåtkomstkontroll handlar om att kontrollera vem (en person eller ett visst datorprogram) får tillgång till vilken information i databasen. Informationen kan innefatta specifika databasobjekt (t.ex. posttyper, specifika poster, datastrukturer), vissa beräkningar över vissa objekt (t.ex. frågetyper eller specifika frågor) eller använda specifika åtkomstvägar till de förstnämnda (t.ex. med hjälp av specifika index) eller andra datastrukturer för att komma åt information). Databasåtkomstkontroller ställs in av särskild auktoriserad (av databasägaren) personal som använder dedikerade skyddade DBMS -gränssnitt.

Detta kan hanteras direkt på individuell basis, eller genom tilldelning av individer och privilegier till grupper, eller (i de mest utarbetade modellerna) genom tilldelning av individer och grupper till roller som sedan beviljas rättigheter. Datasäkerhet förhindrar att obehöriga användare kan se eller uppdatera databasen. Med hjälp av lösenord får användare åtkomst till hela databasen eller delmängder av den som kallas "subscheman". Till exempel kan en medarbetardatabas innehålla all data om en enskild anställd, men en grupp användare kan ha behörighet att endast se lönedata, medan andra endast får tillgång till arbetshistorik och medicinsk data. Om DBMS tillhandahåller ett sätt att interaktivt komma in och uppdatera databasen, samt förhöra den, möjliggör denna kapacitet hantering av personliga databaser.

Datasäkerhet handlar i allmänhet om att skydda specifika bitar av data, både fysiskt (dvs. från korruption, förstörelse eller borttagning, t.ex. se fysisk säkerhet ), eller tolkningen av dem eller delar av dem till meningsfull information (t.ex. genom tittar på strängarna av bitar som de innehåller, avslutar specifika giltiga kreditkortsnummer, t.ex. se datakryptering ).

Ändra och få åtkomst till loggposter vem som fick tillgång till vilka attribut, vad som ändrades och när det ändrades. Loggningstjänster möjliggör en rättsmedicinsk databasrevision senare genom att föra register över åtkomsthändelser och ändringar. Ibland används kod på applikationsnivå för att registrera ändringar snarare än att lämna detta till databasen. Övervakning kan ställas in för att försöka upptäcka säkerhetsöverträdelser.

Transaktioner och samtidighet

Datatransaktioner kan användas för att införa en viss nivå av feltolerans och dataintegritet efter återställning från en krasch . En databastransaktion är en arbetsenhet, som vanligtvis inkapslar ett antal operationer över en databas (t.ex. läsning av ett databasobjekt, skrivning, förvärv av lås etc.), en abstraktion som stöds i databasen och även andra system. Varje transaktion har väl definierade gränser i termer av vilka program/kodkörningar som ingår i transaktionen (bestäms av transaktionens programmerare via speciella transaktionskommandon).

Akronymen ACID beskriver några ideala egenskaper för en databastransaktion: atomicitet , konsistens , isolering och hållbarhet .

Migration

En databas som är byggd med ett DBMS är inte portabel till ett annat DBMS (dvs. det andra DBMS kan inte köra det). I vissa situationer är det dock önskvärt att migrera en databas från ett DBMS till ett annat. Orsakerna är främst ekonomiska (olika DBMS kan ha olika totala ägandekostnader eller TCO), funktionella och operativa (olika DBMS kan ha olika kapacitet). Migreringen innebär att databasen omvandlas från en DBMS -typ till en annan. Transformationen bör (om möjligt) behålla den databasrelaterade applikationen (dvs. alla relaterade applikationsprogram) intakt. Således bör databasens konceptuella och externa arkitektoniska nivåer bibehållas i transformationen. Det kan vara önskvärt att även vissa aspekter av arkitekturens interna nivå bibehålls. En komplex eller stor databasmigrering kan vara ett komplicerat och kostsamt (engångs) projekt i sig, som bör beaktas i beslutet att migrera. Detta trots att det kan finnas verktyg för att hjälpa migreringen mellan specifika DBMS. Vanligtvis tillhandahåller en DBMS -leverantör verktyg för att importera databaser från andra populära DBMS.

Bygga, underhålla och justera

Efter att ha utformat en databas för en applikation, är nästa steg att bygga databasen. Vanligtvis kan ett lämpligt allmänt DBMS väljas för att användas för detta ändamål. Ett DBMS tillhandahåller de användargränssnitt som behövs för databasadministratörer för att definiera den nödvändiga programmets datastrukturer inom DBMS: s respektive datamodell. Andra användargränssnitt används för att välja nödvändiga DBMS -parametrar (som säkerhetsrelaterade parametrar, lagringsallokeringsparametrar, etc.).

När databasen är klar (alla dess datastrukturer och andra nödvändiga komponenter är definierade) fylls den vanligtvis med initiala applikationsdata (databasinitialisering, som vanligtvis är ett distinkt projekt; i många fall med hjälp av specialiserade DBMS -gränssnitt som stöder massinsättning) innan gör det operativt. I vissa fall blir databasen operativ medan den är tom för applikationsdata och data ackumuleras under driften.

Efter att databasen har skapats, initialiserats och fyllts i måste den underhållas. Olika databasparametrar kan behöva ändras och databasen kan behöva ställas in ( tuning ) för bättre prestanda; programmets datastrukturer kan ändras eller läggas till, nya relaterade applikationsprogram kan skrivas för att lägga till applikationens funktionalitet etc.

Säkerhetskopiering och återställning

Ibland är det önskvärt att föra tillbaka en databas till ett tidigare tillstånd (av många skäl, t.ex. när databasen hittas skadad på grund av ett programvarufel, eller om den har uppdaterats med felaktiga data). För att uppnå detta görs en säkerhetskopiering ibland eller kontinuerligt, där varje önskat databasläge (dvs. värdena för dess data och deras inbäddning i databasens datastrukturer) lagras i dedikerade säkerhetskopieringsfiler (många tekniker finns för att göra detta effektivt). När en databasadministratör beslutar att föra databasen tillbaka till detta tillstånd (t.ex. genom att ange detta tillstånd vid en önskad tidpunkt då databasen var i detta tillstånd), används dessa filer för att återställa det tillståndet.

Statisk analys

Statisk analysteknik för programvaruverifiering kan också tillämpas i scenariot med frågespråk. I synnerhet har ramverket * Abstrakt tolkning utvidgats till området för frågespråk för relationsdatabaser som ett sätt att stödja sunda approximationstekniker. Semantiken för frågespråk kan ställas in efter lämpliga abstraktioner av den konkreta datadomänen. Abstraktionen av relationsdatabassystemet har många intressanta applikationer, särskilt för säkerhetsändamål, såsom finkornig åtkomstkontroll, vattenstämpel etc.

Diverse funktioner

Andra DBMS -funktioner kan inkludera:

  • Databasloggar - Detta hjälper till att hålla en historik över de utförda funktionerna.
  • Grafikkomponent för att producera grafer och diagram, särskilt i ett datalagringssystem.
  • Frågeoptimerare - Utför frågeoptimering för varje fråga för att välja en effektiv frågeplan (en delordning (träd) av operationer) som ska utföras för att beräkna frågeresultatet. Kan vara specifik för en viss lagringsmotor.
  • Verktyg eller krokar för databasdesign, applikationsprogrammering, applikationsprogramunderhåll, analys av databasprestanda och övervakning, övervakning av databaskonfiguration, DBMS -maskinvarukonfiguration (en DBMS och relaterad databas kan spänna över datorer, nätverk och lagringsenheter) och relaterad databasmappning (särskilt för en distribuerad DBMS), lagringstilldelning och övervakning av databaslayout, lagringsmigrering etc.

I ökande utsträckning efterfrågas ett enda system som innehåller alla dessa kärnfunktioner i samma ram för bygg, test och distribution för databashantering och källkontroll. Lån från andra utvecklingar inom mjukvaruindustrin, marknadsför vissa erbjudanden som " DevOps för databas".

Design och modellering

Process av databasdesign v2.png

Den första uppgiften för en databasdesigner är att ta fram en konceptuell datamodell som speglar strukturen för den information som ska finnas i databasen. Ett vanligt tillvägagångssätt för detta är att utveckla en entitetsrelationsmodell , ofta med hjälp av ritverktyg. En annan populär metod är Unified Modelling Language . En framgångsrik datamodell återspeglar noggrant det möjliga tillståndet i den yttre världen som modelleras: till exempel om människor kan ha mer än ett telefonnummer, kommer den att tillåta att denna information fångas. Att utforma en bra konceptuell datamodell kräver en god förståelse för applikationsdomänen; det handlar vanligtvis om att ställa djupa frågor om saker som är intressanta för en organisation, till exempel "kan en kund också vara leverantör?", eller "om en produkt säljs med två olika förpackningsformer, är det samma produkt eller olika produkter? ", eller" om ett flygplan flyger från New York till Dubai via Frankfurt, är det en eller två flygningar (eller kanske till och med tre)? ". Svaren på dessa frågor fastställer definitioner av den terminologi som används för enheter (kunder, produkter, flyg, flygsegment) och deras relationer och attribut.

Att ta fram den konceptuella datamodellen innebär ibland input från affärsprocesser eller analys av arbetsflöde i organisationen. Detta kan hjälpa till att fastställa vilken information som behövs i databasen och vad som kan utelämnas. Det kan till exempel hjälpa till när du beslutar om databasen behöver ha både historiska och aktuella data.

Efter att ha tagit fram en konceptuell datamodell som användarna är nöjda med är nästa steg att översätta detta till ett schema som implementerar relevanta datastrukturer i databasen. Denna process kallas ofta logisk databasdesign, och utmatningen är en logisk datamodell uttryckt i form av ett schema. Medan den konceptuella datamodellen (åtminstone i teorin) är oberoende av valet av databasteknik, kommer den logiska datamodellen att uttryckas i termer av en viss databasmodell som stöds av det valda DBMS. (Termerna datamodell och databasmodell används ofta omväxlande, men i den här artikeln använder vi datamodell för utformning av en specifik databas och databasmodell för modelleringsnotationen som används för att uttrycka den designen).

Den mest populära databasmodellen för generella databaser är relationsmodellen, eller närmare bestämt, den relationsmodell som representeras av SQL-språket. Processen att skapa en logisk databasdesign med denna modell använder ett metodiskt tillvägagångssätt som kallas normalisering . Målet med normalisering är att se till att varje elementärt "faktum" bara registreras på ett ställe, så att infogningar, uppdateringar och raderingar automatiskt bibehåller konsistensen.

Det sista steget i databasdesign är att fatta de beslut som påverkar prestanda, skalbarhet, återställning, säkerhet och liknande, som är beroende av den specifika DBMS. Detta kallas ofta fysisk databasdesign , och utmatningen är den fysiska datamodellen . Ett viktigt mål under detta skede är dataoberoende , vilket innebär att de beslut som fattas för prestandaoptimeringsändamål bör vara osynliga för slutanvändare och applikationer. Det finns två typer av dataoberoende: Fysisk dataoberoende och logisk dataoberoende. Fysisk design drivs huvudsakligen av prestationskrav och kräver goda kunskaper om den förväntade arbetsbelastningen och åtkomstmönstren och en djup förståelse för de funktioner som erbjuds av det valda DBMS.

En annan aspekt av fysisk databasdesign är säkerhet. Det innebär både att definiera åtkomstkontroll till databasobjekt samt att definiera säkerhetsnivåer och metoder för själva datan.

Modeller

Collage av fem typer av databasmodeller

En databasmodell är en typ av datamodell som bestämmer en databas logiska struktur och i grunden bestämmer på vilket sätt data kan lagras, organiseras och manipuleras. Det mest populära exemplet på en databasmodell är relationsmodellen (eller SQL-approximationen av relationella), som använder ett tabellbaserat format.

Vanliga logiska datamodeller för databaser inkluderar:

En objekt -relationsdatabas kombinerar de två relaterade strukturerna.

Fysiska datamodeller inkluderar:

Andra modeller inkluderar:

Specialiserade modeller är optimerade för vissa typer av data:

Externa, konceptuella och interna åsikter

Traditionell syn på data

Ett databashanteringssystem ger tre vyer av databasdatan:

  • Den externa nivån definierar hur varje grupp slutanvändare ser organisationen av data i databasen. En enda databas kan ha valfritt antal visningar på extern nivå.
  • Den konceptuella nivån förenar de olika yttre vyerna till en kompatibel global syn. Det ger syntesen av alla yttre åsikter. Det är utanför tillämpningsområdet för de olika databasens slutanvändare och är snarare av intresse för databasapplikationsutvecklare och databasadministratörer.
  • Den interna nivån (eller den fysiska nivån ) är den interna organisationen av data i ett DBMS. Det handlar om kostnad, prestanda, skalbarhet och andra operativa frågor. Den behandlar lagringslayout för data, med hjälp av lagringsstrukturer som index för att förbättra prestanda. Ibland lagrar den data från enskilda vyer ( materialiserade vyer ), beräknade från generiska data, om prestandarättfärdiggörelse finns för sådan redundans. Det balanserar alla externa vyers prestationskrav, eventuellt motstridiga, i ett försök att optimera det övergripande resultatet för alla aktiviteter.

Även om det vanligtvis bara finns en konceptuell (eller logisk) och fysisk (eller intern) vy av data, kan det finnas valfritt antal olika externa vyer. Detta gör att användarna kan se databasinformation på ett mer affärsrelaterat sätt snarare än från en teknisk, bearbetningssynpunkt. Till exempel behöver en finansavdelning i ett företag betalningsuppgifterna för alla anställda som en del av företagets utgifter, men behöver inte detaljer om anställda som är av personalavdelningens intresse . Därför behöver olika avdelningar olika syn på företagets databas.

Databasearkitekturen på tre nivåer relaterar till konceptet med dataoberoende som var en av de stora initiala drivkrafterna för relationsmodellen. Tanken är att förändringar som görs på en viss nivå inte påverkar utsikten på en högre nivå. Till exempel påverkar förändringar på den interna nivån inte applikationsprogram skrivna med konceptuella nivågränssnitt, vilket minskar effekten av att göra fysiska förändringar för att förbättra prestanda.

Den konceptuella synen ger en indirekt nivå mellan internt och externt. Å ena sidan ger den en gemensam bild av databasen, oberoende av olika externa vystrukturer, och å andra sidan abstraherar den bort detaljer om hur data lagras eller hanteras (intern nivå). I princip kan varje nivå, och till och med varje extern vy, presenteras av en annan datamodell. I praktiken använder vanligtvis en given DBMS samma datamodell för både den externa och den konceptuella nivån (t.ex. relationsmodell). Den interna nivån, som är dold inuti DBMS och beror på dess implementering, kräver en annan detaljnivå och använder sina egna typer av datastrukturtyper.

Att skilja de externa , konceptuella och interna nivåerna var ett viktigt inslag i de relationsdatabasmodellimplementeringar som dominerar 2000 -talets databaser.

Forskning

Databasteknik har varit ett aktivt forskningsämne sedan 1960 -talet, både inom akademin och i forsknings- och utvecklingsgrupperna (t.ex. IBM Research ). Forskningsaktivitet inkluderar teori och utveckling av prototyper . Anmärkningsvärda forskningsämnen har inkluderat modeller , atomtransaktionskonceptet och relaterade samtidighetskontrolltekniker , frågespråk och frågeoptimeringsmetoder , RAID och mer.

Databasforskningsområdet har flera dedikerade akademiska tidskrifter (till exempel ACM Transactions on Database Systems -TODS, Data and Knowledge Engineering -DKE) och årliga konferenser (t.ex. ACM SIGMOD , ACM PODS , VLDB , IEEE ICDE).

Se även

Anteckningar

Referenser

Källor

Vidare läsning