Database - Database

En SQL select -sætning og dens resultat

I computing er en database en organiseret samling af data, der gemmes og tilgås elektronisk fra et computersystem . Hvor databaser er mere komplekse, udvikles de ofte ved hjælp af formel design og modelleringsteknik .

Den database management system ( DBMS ) er den software , der interagerer med slutbrugerne , programmer og selve databasen at indfange og analysere dataene. DBMS -softwaren omfatter desuden de kernefaciliteter, der er til rådighed til administration af databasen. Summen af ​​databasen, DBMS og de tilhørende applikationer kan betegnes som et "databasesystem". Ofte bruges udtrykket "database" også løst til at referere til nogen af ​​DBMS'erne, databasesystemet eller et program, der er knyttet til databasen.

Computerforskere kan klassificere databasesystemer i henhold til de databasemodeller , de understøtter. Relationsdatabaser blev dominerende i 1980'erne. Disse modeldata som rækker og kolonner i en række tabeller , og langt de fleste bruger SQL til at skrive og forespørge data. I 2000'erne blev ikke-relationelle databaser populære, kaldet NoSQL, fordi de bruger forskellige forespørgselssprog .

Terminologi og oversigt

Formelt refererer en "database" til et sæt relaterede data og den måde, de er organiseret på. Adgang til disse data leveres normalt af et "database management system" (DBMS) bestående af et integreret sæt computersoftware, der giver brugerne mulighed for at interagere med en eller flere databaser og giver adgang til alle data i databasen (selvom der er begrænsninger kan eksistere, der begrænser adgangen til bestemte data). DBMS har forskellige funktioner, der tillader indtastning, lagring og hentning af store mængder information og giver måder at styre, hvordan disse oplysninger er organiseret.

På grund af det tætte forhold mellem dem bruges udtrykket "database" ofte tilfældigt til at referere til både en database og DBMS, der bruges til at manipulere den.

Uden for verden af ​​professionel informationsteknologi bruges udtrykket database ofte til at henvise til enhver samling af relaterede data (f.eks. Et regneark eller et kortindeks), da størrelse og brugskrav typisk nødvendiggør brug af et databasesystem.

Eksisterende DBMS'er har forskellige funktioner, der tillader administration af en database og dens data, som kan klassificeres i fire hovedfunktionelle grupper:

  • Datadefinition - Oprettelse, ændring og fjernelse af definitioner, der definerer organisation af data.
  • Opdatering - Indsættelse, ændring og sletning af de faktiske data.
  • Hentning - Tilvejebringelse af oplysninger i en form, der er direkte anvendelig eller til videre behandling af andre applikationer. De hentede data kan gøres tilgængelige i en form, der stort set er den samme, som den er gemt i databasen eller i en ny form, der er opnået ved at ændre eller kombinere eksisterende data fra databasen.
  • Administration - Registrering og overvågning af brugere, håndhævelse af datasikkerhed, overvågning af ydeevne, opretholdelse af dataintegritet, håndtering af samtidighedskontrol og gendannelse af oplysninger, der er blevet ødelagt af en eller anden hændelse, såsom en uventet systemfejl.

Både en database og dens DBMS overholder principperne for en bestemt databasemodel . "Databasesystem" refererer samlet til databasemodellen, databasesystemet og databasen.

Fysisk, database -servere er dedikerede computere, der holder den faktiske databaser og kører kun DBMS og tilhørende software. Databaseservere er normalt multiprocessorcomputere med generøs hukommelse og RAID -diskarrays, der bruges til stabil lagring. Hardware-databaseacceleratorer, der er forbundet til en eller flere servere via en højhastighedskanal, bruges også i transaktionsbehandlingsmiljøer med store mængder. DBMS'er findes i hjertet af de fleste databaseapplikationer . DBMS'er kan være bygget op omkring en brugerdefineret multitasking- kerne med indbygget netværksunderstøttelse , men moderne DBMS'er er typisk afhængige af et standardoperativsystem for at levere disse funktioner.

Da DBMS'er udgør et betydeligt marked , tager computer- og lagringsleverandører ofte hensyn til DBMS -krav i deres egne udviklingsplaner.

Databaser og DBMS'er kan kategoriseres efter de eller de databasemodeller, de understøtter (f.eks. Relationel eller XML), den eller de computertyper, de kører på (fra en serverklynge til en mobiltelefon), forespørgselssproget ( s) bruges til at få adgang til databasen (f.eks. SQL eller XQuery ) og deres interne teknik, som påvirker ydeevne, skalerbarhed , modstandsdygtighed og sikkerhed.

Historie

Størrelser, kapaciteter og ydeevne for databaser og deres respektive DBMS'er er vokset i størrelsesordener. Disse ydelsesforøgelser blev muliggjort af teknologiske fremskridt inden for processorer , computerhukommelse , computerlagring og computernetværk . Konceptet med en database blev muliggjort ved fremkomsten af ​​lagringsmedier med direkte adgang, såsom magnetiske diske, som blev bredt tilgængelige i midten af ​​1960'erne; tidligere systemer baserede sig på sekventiel lagring af data på magnetbånd. Den efterfølgende udvikling af databaseteknologi kan opdeles i tre æraer baseret på datamodel eller struktur: navigation , SQL/ relationel og post-relationel.

De to vigtigste tidlige navigationsdatamodeller var den hierarkiske model og CODASYL -modellen ( netværksmodel ). Disse var kendetegnet ved brug af pointers (ofte fysiske diskadresser) til at følge relationer fra en post til en anden.

Den relationelle model , der først blev foreslået i 1970 af Edgar F. Codd , afveg fra denne tradition ved at insistere på, at applikationer skulle søge efter data efter indhold, snarere end ved at følge links. Den relationelle model anvender sæt tabeller i hovedbogstil, der hver bruges til en anden type enhed. Først i midten af ​​1980'erne blev computerhardware stærk nok til at muliggøre en bred implementering af relationelle systemer (DBMS'er plus applikationer). I begyndelsen af ​​1990'erne dominerede relationelle systemer imidlertid i alle store databehandlingsapplikationer , og fra 2018 er de fortsat dominerende: IBM DB2 , Oracle , MySQL og Microsoft SQL Server er det mest søgte DBMS . Det dominerende databasesprog, standardiseret SQL til relationsmodellen, har påvirket databasesprog for andre datamodeller.

Objektdatabaser blev udviklet i 1980'erne for at overvinde ulejligheden ved objekt-relationel impedans-mismatch , hvilket førte til udformningen af ​​udtrykket "post-relationel" og også udviklingen af ​​hybrid objekt-relationelle databaser .

Den næste generation af post-relationelle databaser i slutningen af ​​2000'erne blev kendt som NoSQL- databaser, der introducerede hurtige nøgleværdibutikker og dokumentorienterede databaser . En konkurrerende "næste generation" kendt som NewSQL -databaser forsøgte på nye implementeringer, der bevarede den relationelle/SQL -model, mens de havde til formål at matche NoSQL's høje ydeevne i forhold til kommercielt tilgængelige relationelle DBMS'er.

1960'erne, navigations -DBMS

Grundlæggende struktur for navigations -CODASYL -databasemodel

Indførelsen af ​​begrebet database faldt sammen med tilgængeligheden af ​​direkte adgang til lagring (diske og trommer) fra midten af ​​1960'erne og fremefter. Udtrykket repræsenterede en kontrast til tidligere tiders tape-baserede systemer, hvilket tillod delt interaktiv brug frem for daglig batchbehandling . Den Oxford English Dictionary citerer en 1962 rapport fra System Development Corporation of California som det første til at bruge udtrykket "data-base" i en specifik teknisk forstand.

Efterhånden som computere voksede i hastighed og kapacitet, opstod en række generelle databasesystemer; i midten af ​​1960'erne var en række sådanne systemer kommet i kommerciel brug. Interessen for en standard begyndte at vokse, og Charles Bachman , forfatter til et sådant produkt, Integrated Data Store (IDS), grundlagde Database Task Group inden for CODASYL , gruppen ansvarlig for oprettelse og standardisering af COBOL . I 1971 leverede Database Task Group deres standard, der generelt blev kendt som CODASYL -tilgangen , og snart kom en række kommercielle produkter baseret på denne tilgang på markedet.

CODASYL -metoden gav applikationer mulighed for at navigere rundt i et sammenkædet datasæt, der blev dannet til et stort netværk. Applikationer kunne finde poster på en af ​​tre metoder:

  1. Brug af en primær nøgle (kendt som en CALC -nøgle, typisk implementeret ved hashing )
  2. Navigering af relationer (kaldet sæt ) fra en post til en anden
  3. Scanning af alle poster i en rækkefølge

Senere systemer tilføjede B-træer for at give alternative adgangsstier. Mange CODASYL -databaser tilføjede også et deklarativt forespørgselssprog til slutbrugere (adskilt fra navigations -API). CODASYL -databaser var imidlertid komplekse og krævede betydelig uddannelse og indsats for at producere nyttige applikationer.

IBM havde også deres eget DBMS i 1966, kendt som Information Management System (IMS). IMS var en udvikling af software skrevet til Apollo -programmetSystem/360 . IMS lignede generelt i konceptet CODASYL, men brugte et strengt hierarki for sin model af datavavigation i stedet for CODASYLs netværksmodel. Begge begreber blev senere kendt som navigationsdatabaser på grund af den måde, hvorpå data blev tilgået: udtrykket blev populært af Bachmans Turing Award -præsentation fra 1973 The Programmer as Navigator . IMS klassificeres af IBM som en hierarkisk database . IDMS og Cincom Systems ' TOTAL database er klassificeret som netværksdatabaser. IMS forbliver i brug fra 2014.

1970'erne, relationel DBMS

Edgar F. Codd arbejdede hos IBM i San Jose, Californien , i et af deres offshoot -kontorer, der primært var involveret i udviklingen af harddisksystemer . Han var utilfreds med navigationsmodellen for CODASYL -tilgangen, især manglen på en "søgefunktion". I 1970 skrev han en række papirer, der skitserede en ny tilgang til databasekonstruktion, der til sidst kulminerede i den banebrydende A Relational Model of Data for Large Shared Data Banks .

I dette papir beskrev han et nyt system til lagring og arbejde med store databaser. I stedet for at optegnelser lagres i en slags sammenkædet liste over friformsposter som i CODASYL, var Codds idé at organisere dataene som et antal " tabeller ", hvor hver tabel blev brugt til en anden type enhed. Hver tabel ville indeholde et fast antal kolonner, der indeholder enhedens attributter. En eller flere kolonner i hver tabel blev betegnet som en primær nøgle, ved hvilken rækker i tabellen kunne identificeres entydigt; krydsreferencer mellem tabeller brugte altid disse primære nøgler i stedet for diskadresser, og forespørgsler ville forbinde tabeller baseret på disse nøglerelationer, ved hjælp af et sæt operationer baseret på det matematiske system for relationel beregning (hvorfra modellen har sit navn). Opdelingen af ​​dataene i et sæt normaliserede tabeller (eller relationer ) med det formål at sikre, at hver "kendsgerning" kun blev gemt én gang, hvilket forenkler opdateringsoperationer. Virtuelle tabeller kaldet visninger kunne præsentere dataene på forskellige måder for forskellige brugere, men visninger kunne ikke opdateres direkte.

Codd brugte matematiske udtryk til at definere modellen: relationer, tupler og domæner frem for tabeller, rækker og kolonner. Den terminologi, der nu er kendt, stammer fra tidlige implementeringer. Codd ville senere kritisere tendensen til praktiske implementeringer til at afvige fra det matematiske fundament, som modellen var baseret på.

I relationsmodellen "linkes" poster ved hjælp af virtuelle nøgler, der ikke er gemt i databasen, men defineres efter behov mellem dataene i posterne.

Brugen af ​​primære nøgler (brugerorienterede identifikatorer) til at repræsentere tværgående tabeller, frem for diskadresser, havde to primære motiver. Fra et ingeniørperspektiv muliggjorde det, at tabeller kunne flyttes og ændres i størrelse uden dyre databaseomlægninger. Men Codd var mere interesseret i forskellen i semantik: brugen af ​​eksplicitte identifikatorer gjorde det lettere at definere opdateringsoperationer med rene matematiske definitioner, og det gjorde det også muligt at definere forespørgselsoperationer med hensyn til den etablerede disciplin for første ordens predikatregning ; fordi disse operationer har rene matematiske egenskaber, bliver det muligt at omskrive forespørgsler på beviseligt korrekte måder, hvilket er grundlaget for forespørgselsoptimering. Der er ikke noget tab af udtryksfuldhed sammenlignet med de hierarkiske eller netværksmodeller, selvom forbindelserne mellem tabeller ikke længere er så eksplicitte.

I hierarkiske og netværksmodeller fik poster lov til at have en kompleks intern struktur. For eksempel kan en medarbejders lønhistorik repræsenteres som en "gentagende gruppe" i medarbejderrekorden. I relationsmodellen førte normaliseringsprocessen til, at sådanne interne strukturer blev erstattet af data i flere tabeller, der kun var forbundet med logiske nøgler.

For eksempel er en almindelig brug af et databasesystem at spore oplysninger om brugere, deres navn, loginoplysninger, forskellige adresser og telefonnumre. I navigationsmetoden vil alle disse data blive placeret i en enkelt registrering med variabel længde. I relationel tilgang ville dataene blive normaliseret til en brugertabel, en adressetabel og et telefonnummertabel (f.eks.). Optegnelser ville kun blive oprettet i disse valgfrie tabeller, hvis adressen eller telefonnumrene faktisk blev angivet.

Ud over at identificere rækker/poster ved hjælp af logiske identifikatorer frem for diskadresser, ændrede Codd måden, hvorpå applikationer samlede data fra flere poster. I stedet for at kræve, at applikationer indsamler data én post ad gangen ved at navigere i linkene, ville de bruge et deklarativt forespørgselssprog, der udtrykte, hvilke data der var påkrævet, frem for den adgangssti, som de skulle findes efter. At finde en effektiv adgangsvej til dataene blev ansvaret for databasesystemet i stedet for applikationsprogrammereren. Denne proces, kaldet forespørgselsoptimering, var afhængig af, at forespørgsler blev udtrykt i form af matematisk logik.

Codd's papir blev afhentet af to personer i Berkeley, Eugene Wong og Michael Stonebraker . De startede et projekt kendt som INGRES ved hjælp af midler, der allerede var afsat til et geografisk databaseprojekt og studerende programmører til at producere kode. Fra 1973 leverede INGRES sine første testprodukter, der generelt var klar til udbredt brug i 1979. INGRES lignede System R på en række måder, herunder brugen af ​​et "sprog" til dataadgang , kendt som QUEL . Over tid flyttede INGRES til den nye SQL -standard.

IBM selv foretog en testimplementering af relationsmodellen, PRTV , og en produktionsmodel, Business System 12 , der nu begge blev afbrudt. Honeywell skrev MRDS for Multics , og nu er der to nye implementeringer: Alphora Dataphor og Rel . De fleste andre DBMS -implementeringer, der normalt kaldes relationelle, er faktisk SQL DBMS'er.

I 1970 begyndte University of Michigan udviklingen af MICRO Information Management System baseret på DL Childs 'Set-Theoretic Data model. MICRO blev brugt til at styre meget store datasæt af US Department of Labor , US Environmental Protection Agency og forskere fra University of Alberta , University of Michigan og Wayne State University . Det kørte på IBM -mainframe -computere ved hjælp af Michigan Terminal System . Systemet forblev i produktion indtil 1998.

Integreret tilgang

I 1970'erne og 1980'erne blev der forsøgt at bygge databasesystemer med integreret hardware og software. Den bagvedliggende filosofi var, at en sådan integration ville give højere ydelse til en lavere pris. Eksempler var IBM System/38 , det tidlige tilbud af Teradata og databasen Machine Britton Lee, Inc.

En anden tilgang til hardwaresupport til databasestyring var ICL 's CAFS -accelerator, en harddiskdiskcontroller med programmerbare søgefunktioner. På lang sigt var disse bestræbelser generelt uden succes, fordi specialiserede databasemaskiner ikke kunne følge med i den hurtige udvikling og fremgang i computere til generelle formål. Således er de fleste databasesystemer i dag softwaresystemer, der kører på hardware til generelle formål, og som anvender generel computerdatalagring. Denne idé forfølges dog stadig for visse applikationer af nogle virksomheder som Netezza og Oracle ( Exadata ).

Slutningen af ​​1970'erne, SQL DBMS

IBM begyndte at arbejde på et prototypesystem løst baseret på Codds koncepter som System R i begyndelsen af ​​1970'erne. Den første version var klar i 1974/5, og derefter startede arbejdet med multi-table-systemer, hvor dataene kunne opdeles, så alle data til en post (hvoraf nogle er valgfri) ikke behøvede at blive gemt i en enkelt stor "klump". Efterfølgende flerbrugerversioner blev testet af kunderne i 1978 og 1979, og på det tidspunkt var et standardiseret forespørgselssprog -SQL-blevet tilføjet. Codds ideer blev ved at etablere sig som både brugbare og bedre end CODASYL, og skubbede IBM til at udvikle en ægte produktionsversion af System R, kendt som SQL/DS , og senere Database 2 ( DB2 ).

Larry Ellisons Oracle Database (eller mere enkelt, Oracle ) startede fra en anden kæde, baseret på IBMs papirer om System R. Selvom Oracle V1 -implementeringer blev afsluttet i 1978, var det først Oracle Version 2, da Ellison slog IBM på markedet i 1979.

Stonebraker fortsatte med at anvende lektionerne fra INGRES til at udvikle en ny database, Postgres, som nu er kendt som PostgreSQL . PostgreSQL bruges ofte til globale missionskritiske applikationer (.org og .info domænenavnsregistre bruger det som deres primære datalagring , ligesom mange store virksomheder og finansielle institutioner).

I Sverige blev Codds papir også læst, og Mimer SQL blev udviklet fra midten af ​​1970'erne ved Uppsala University . I 1984 blev dette projekt konsolideret til en selvstændig virksomhed.

En anden datamodel, entitetsrelationsmodellen , opstod i 1976 og blev populær for databasedesign, da den understregede en mere velkendt beskrivelse end den tidligere relationsmodel. Senere blev entitet -relationskonstruktioner eftermonteret som en datamodelleringskonstruktion for den relationelle model, og forskellen mellem de to er blevet irrelevant.

1980'erne, på skrivebordet

1980'erne indledte en alder af desktop computing . De nye computere gav deres brugere mulighed for regneark som Lotus 1-2-3 og databasesoftware som dBASE . DBASE -produktet var let og let for enhver computerbruger at forstå ud af boksen. C. Wayne Ratliff , skaberen af ​​dBASE, udtalte: "dBASE var forskellig fra programmer som BASIC, C, FORTRAN og COBOL i og med at meget af det beskidte arbejde allerede var blevet udført. Datamanipulationen udføres af dBASE i stedet for af brugeren, så brugeren kan koncentrere sig om det, han laver, frem for at skulle rode med de beskidte detaljer om åbning, læsning og lukning af filer og håndtering af pladsallokering. " dBASE var en af ​​de bedst sælgende softwaretitler i 1980'erne og begyndelsen af ​​1990'erne.

1990'erne, objektorienteret

1990'erne, sammen med en stigning i objektorienteret programmering , oplevede en vækst i, hvordan data i forskellige databaser blev håndteret. Programmerere og designere begyndte at behandle dataene i deres databaser som objekter . Det vil sige, at hvis en persons data var i en database, blev denne persons attributter, f.eks. Deres adresse, telefonnummer og alder, nu anset for at tilhøre den pågældende person i stedet for at være fremmede data. Dette gør det muligt for relationer mellem data at være relationer til objekter og deres attributter og ikke til individuelle felter. Udtrykket " objekt -relationel impedansfejl " beskrev besværet med at oversætte mellem programmerede objekter og databasetabeller. Objektdatabaser og objektrelationsdatabaser forsøger at løse dette problem ved at tilvejebringe et objektorienteret sprog (nogle gange som udvidelser til SQL), som programmører kan bruge som alternativ til rent relationel SQL. På programmeringssiden forsøger biblioteker kendt som objekt -relationelle mappings (ORM'er) at løse det samme problem.

2000'erne, NoSQL og NewSQL

XML-databaser er en type struktureret dokumentorienteret database, der tillader forespørgsel baseret på XML- dokumentattributter. XML -databaser bruges for det meste i applikationer, hvor data bekvemt ses som en samling af dokumenter, med en struktur, der kan variere fra det meget fleksible til det meget stive: eksempler omfatter videnskabelige artikler, patenter, skatteansøgninger og personaleregistre.

NoSQL -databaser er ofte meget hurtige, kræver ikke faste bordskemaer, undgår joinoperationer ved at lagre deormaliserede data og er designet til at skalere vandret .

I de senere år har der været en stærk efterspørgsel efter massivt distribuerede databaser med høj partitionstolerance, men ifølge CAP -sætningen er det umuligt for et distribueret system at samtidig levere konsistens , tilgængelighed og partitionstolerancegarantier. Et distribueret system kan opfylde to af disse garantier på samme tid, men ikke alle tre. Af denne grund bruger mange NoSQL -databaser det, der kaldes eventuel konsistens, til at levere både garantier for tilgængelighed og partitionstolerance med et reduceret datakonsistensniveau.

NewSQL er en klasse af moderne relationsdatabaser, der har til formål at levere den samme skalerbare ydelse af NoSQL-systemer til onlinetransaktionsbehandling (læs-skriv) arbejdsbyrder, mens de stadig bruger SQL og opretholder ACID- garantierne for et traditionelt databasesystem.

Brug cases

Databaser bruges til at understøtte interne operationer i organisationer og til at understøtte online interaktioner med kunder og leverandører (se Enterprise -software ).

Databaser bruges til at opbevare administrative oplysninger og mere specialiserede data, såsom ingeniørdata eller økonomiske modeller. Eksempler omfatter edb -bibliotekssystemer , flyreservationssystemer , edb -reservedelslagersystemer og mange indholdsstyringssystemer, der gemmer websteder som samlinger af websider i en database.

Klassifikation

En måde at klassificere databaser på omfatter typen af ​​deres indhold, for eksempel: bibliografiske , dokumenttekst, statistiske eller multimedieobjekter. En anden måde er ved deres anvendelsesområde, for eksempel: regnskab, kompositioner, film, bank, fremstilling eller forsikring. En tredje måde er et eller andet teknisk aspekt, f.eks. Databasestrukturen eller interfacetypen. Dette afsnit viser et par af de adjektiver, der bruges til at karakterisere forskellige slags databaser.

  • En in-memory-database er en database, der primært findes i hovedhukommelsen , men som typisk sikkerhedskopieres af ikke-flygtig computerdatalagring. Hovedhukommelsesdatabaser er hurtigere end diskdatabaser og bruges derfor ofte, hvor svartiden er kritisk, f.eks. I telekommunikationsnetværksudstyr.
  • En aktiv database indeholder en hændelsesdrevet arkitektur, som kan reagere på forhold både i og uden for databasen. Mulige anvendelser omfatter sikkerhedsovervågning, alarm, indsamling af statistik og autorisation. Mange databaser indeholder aktive databasefunktioner i form af databasetriggere .
  • En sky -database er afhængig af cloud -teknologi . Både databasen og de fleste af dens DBMS ligger eksternt "i skyen", mens dens applikationer både udvikles af programmører og senere vedligeholdes og bruges af slutbrugere via en webbrowser og åbne API'er .
  • Datalagre arkiverer data fra operationelle databaser og ofte fra eksterne kilder som f.eks. Markedsundersøgelsesfirmaer. Lageret bliver den centrale datakilde til brug for ledere og andre slutbrugere, der muligvis ikke har adgang til driftsdata. Eksempelvis kan salgsdata aggregeres til ugentlige totaler og konverteres fra interne produktkoder til brug af UPC'er, så de kan sammenlignes med ACNielsen -data. Nogle grundlæggende og væsentlige komponenter i datalagring omfatter udtrækning, analyse og minedata , transformering, indlæsning og håndtering af data for at gøre dem tilgængelige til videre brug.
  • En deduktiv database kombinerer logisk programmering med en relationsdatabase.
  • En distribueret database er en, hvor både data og DBMS spænder over flere computere.
  • En dokumentorienteret database er designet til at lagre, hente og administrere dokumentorienteret eller semi-struktureret information. Dokumentorienterede databaser er en af ​​hovedkategorierne i NoSQL-databaser.
  • Et integreret databasesystem er et DBMS, der er tæt integreret med en applikationssoftware, der kræver adgang til lagrede data på en sådan måde, at DBMS er skjult for applikationens slutbrugere og kræver lidt eller ingen løbende vedligeholdelse.
  • Slutbrugerdatabaser består af data udviklet af individuelle slutbrugere. Eksempler på disse er samlinger af dokumenter, regneark, præsentationer, multimedier og andre filer. Der findes flere produkter til understøttelse af sådanne databaser. Nogle af dem er meget enklere end fuldgyldige DBMS'er med mere elementær DBMS-funktionalitet.
  • Et sammensat databasesystem består af flere forskellige databaser, hver med sit eget DBMS. Det håndteres som en enkelt database af et fødereret databasesystem (FDBMS), som transparent integrerer flere autonome DBMS'er, muligvis af forskellige typer (i så fald ville det også være et heterogent databasesystem ), og giver dem et integreret konceptuelt overblik .
  • Nogle gange udtrykket multi-databasen bliver brugt som et synonym for fødereret database, selvom det kan henvise til en mindre integreret (fx uden en FDBMS og en styret integreret skema) gruppe af databaser, der samarbejder i en enkelt ansøgning. I dette tilfælde bruges typisk middleware til distribution, som typisk inkluderer en atomic commit-protokol (ACP), f.eks. Tofaset commit-protokollen , for at tillade distribuerede (globale) transaktioner på tværs af de deltagende databaser.
  • En grafdatabase er en slags NoSQL -database, der bruger grafstrukturer med noder, kanter og egenskaber til at repræsentere og gemme oplysninger. Generelle grafdatabaser, der kan gemme enhver graf, adskiller sig fra specialiserede grafdatabaser såsom triplestores og netværksdatabaser .
  • En array DBMS er en slags NoSQL DBMS, der tillader modellering, lagring og hentning af (normalt store) flerdimensionale arrays såsom satellitbilleder og klimasimuleringsoutput.
  • I en hypertekst- eller hypermediedatabase kan ethvert ord eller et stykke tekst, der repræsenterer et objekt, f.eks. Et andet stykke tekst, en artikel, et billede eller en film, hyperlinkes til det objekt. Hypertekstdatabaser er særligt nyttige til at organisere store mængder forskellig information. For eksempel er de nyttige til at organisere online encyklopædier , hvor brugerne bekvemt kan springe rundt i teksten. Den World Wide Web er således en stor distribueret hypertekst database.
  • En vidensbase (forkortet KB , kb eller Δ) er en særlig form for database til vidensstyring , der giver midler til computeriseret indsamling, organisering og hentning af viden . Også en samling af data, der repræsenterer problemer med deres løsninger og relaterede oplevelser.
  • En mobil database kan videreføres eller synkroniseres fra en mobil computerenhed.
  • Operationelle databaser gemme detaljerede data om driften af en organisation. De behandler typisk relativt store mængder opdateringer ved hjælp af transaktioner . Eksempler omfatter kundedatabaser, der registrerer kontakt-, kredit- og demografiske oplysninger om en virksomheds kunder, personaledatabaser, der indeholder oplysninger såsom løn, fordele, færdighedsdata om medarbejdere, virksomhedens ressourceplanlægningssystemer , der registrerer detaljer om produktkomponenter, reservedele og finansielle databaser, der holder styr på organisationens penge, regnskab og økonomiske handler.
  • En parallel database søger at forbedre ydeevnen gennem parallelisering til opgaver såsom indlæsning af data, opbygning af indekser og evaluering af forespørgsler.
De store parallelle DBMS -arkitekturer, der fremkaldes af den underliggende hardware -arkitektur, er:
  • Delt hukommelsesarkitektur , hvor flere processorer deler hovedhukommelsesrummet samt anden datalagring.
  • Delt diskarkitektur , hvor hver behandlingsenhed (typisk bestående af flere processorer) har sin egen hovedhukommelse, men alle enheder deler den anden lagring.
  • Delt-intet arkitektur , hvor hver behandlingsenhed har sin egen hovedhukommelse og anden lagring.
  • Probabilistiske databaser anvender fuzzy logik til at drage slutninger fra upræcise data.
  • Realtidsdatabaser behandler transaktioner hurtigt nok til, at resultatet kan komme tilbage og blive handlet med det samme.
  • En rumlig database kan gemme dataene med multidimensionelle funktioner. Forespørgslerne om sådanne data inkluderer placeringsbaserede forespørgsler, f.eks. "Hvor er det nærmeste hotel i mit område?".
  • En tidsmæssig database har indbyggede tidsaspekter , f.eks. En tidsmæssig datamodel og en tidsmæssig version af SQL . Mere specifikt omfatter de tidsmæssige aspekter normalt gyldig tid og transaktionstid.
  • En terminologi-orienteret database bygger på en objektorienteret database , ofte tilpasset til et specifikt felt.
  • En ustruktureret datadatabase er beregnet til på en håndterbar og beskyttet måde at lagre forskellige objekter, der ikke passer naturligt og bekvemt i fælles databaser. Det kan omfatte e -mail -meddelelser, dokumenter, tidsskrifter, multimedieobjekter osv. Navnet kan være vildledende, da nogle objekter kan være meget strukturerede. Hele den mulige objektsamling passer imidlertid ikke ind i en foruddefineret struktureret ramme. De fleste etablerede DBMS'er understøtter nu ustrukturerede data på forskellige måder, og nye dedikerede DBMS'er dukker op.

Databasestyringssystem

Connolly og Begg definerer database management system (DBMS) som et "softwaresystem, der gør det muligt for brugere at definere, oprette, vedligeholde og kontrollere adgang til databasen". Eksempler på DBMS'er inkluderer MySQL , PostgreSQL , Microsoft SQL Server , Oracle Database og Microsoft Access .

DBMS -akronymet er undertiden udvidet til at angive den underliggende databasemodel med RDBMS for relationel , OODBMS for objektet (orienteret) og ORDBMS for objekt -relationel model . Andre udvidelser kan indikere en anden egenskab, f.eks. DDBMS for et distribueret databasesystem.

Funktionaliteten fra et DBMS kan variere enormt. Kernefunktionen er lagring, hentning og opdatering af data. Codd foreslog følgende funktioner og tjenester, som et fuldt udbygget DBMS bør levere:

  • Datalagring, hentning og opdatering
  • Bruger tilgængeligt katalog eller dataliste, der beskriver metadata
  • Support til transaktioner og samtidighed
  • Faciliteter til gendannelse af databasen, hvis den skulle blive beskadiget
  • Support til godkendelse af adgang og opdatering af data
  • Adgang til support fra fjerntliggende steder
  • Håndhævelse af begrænsninger for at sikre, at data i databasen overholder visse regler

Det må også generelt forventes, at DBMS vil levere et sæt hjælpeprogrammer til de formål, der kan være nødvendige for effektivt at administrere databasen, herunder import, eksport, overvågning, defragmentering og analyseværktøjer. Kernedelen af ​​DBMS, der interagerer mellem databasen og applikationsgrænsefladen, kaldes undertiden databasemotoren .

Ofte vil DBMS'er have konfigurationsparametre, der kan justeres statisk og dynamisk, f.eks. Den maksimale mængde hovedhukommelse på en server, databasen kan bruge. Tendensen er at minimere mængden af ​​manuel konfiguration, og i tilfælde som integrerede databaser er behovet for at målrette nul-administration altafgørende.

De store større virksomheds DBMS'er har haft en tendens til at stige i størrelse og funktionalitet og kan have involveret tusinder af menneskelige års udviklingsindsats gennem deres levetid.

Tidlig flerbruger-DBMS tillod typisk kun, at applikationen var bosat på den samme computer med adgang via terminaler eller terminalemuleringssoftware. Den klient-server-arkitektur var en udvikling, hvor ansøgningen bosat på en klient skrivebordet og databasen på en server tillader behandlingen skal fordeles. Dette udviklede sig til en multitier -arkitektur, der indeholder applikationsservere og webservere med slutbrugergrænsefladen via en webbrowser, hvor databasen kun er direkte forbundet til det tilstødende niveau.

Et DBMS til generelle formål vil levere offentlige applikationsprogrammeringsgrænseflader (API) og eventuelt en processor til databasesprog som f.eks. SQL, så programmer kan skrives til at interagere med databasen. Et DBMS til særlige formål kan bruge en privat API og være specifikt tilpasset og knyttet til en enkelt applikation. For eksempel kan et e-mail- system, der udfører mange af funktionerne i et generelt DBMS, f.eks. Indsættelse af beskeder, sletning af beskeder, håndtering af vedhæftede filer, opslagning af bloklister, tilknytning af meddelelser til en e-mail-adresse og så videre, men disse funktioner er begrænset til det, der kræves for at håndtere e -mail.

Ansøgning

Ekstern interaktion med databasen sker via et applikationsprogram, der har grænseflader til DBMS. Dette kan variere fra et databaseværktøj, der giver brugerne mulighed for at udføre SQL -forespørgsler tekstmæssigt eller grafisk, til et websted, der tilfældigvis bruger en database til at gemme og søge efter oplysninger.

Applikationsprogram interface

En programmør vil kode interaktioner til databasen (undertiden omtalt som en datakilde ) via en applikationsprogramgrænseflade (API) eller via et databasesprog . Den bestemte API eller det valgte sprog skal understøttes af DBMS, muligvis indirekte via en præprocessor eller en bro -API. Nogle API'er sigter mod at være databaseuafhængige, idet ODBC er et almindeligt kendt eksempel. Andre almindelige API'er inkluderer JDBC og ADO.NET .

Databasesprog

Databasesprog er specialsprog, der tillader en eller flere af følgende opgaver, som undertiden adskilles som sublanguages :

Databasesprog er specifikke for en bestemt datamodel. Bemærkelsesværdige eksempler omfatter:

Et databasesprog kan også indeholde funktioner som:

  • DBMS-specifik konfiguration og lagermotorstyring
  • Beregninger til ændring af forespørgselsresultater, som tælling, summering, gennemsnit, sortering, gruppering og krydshenvisning
  • Begrænsningshåndhævelse (f.eks. I en bildatabase, der tillader kun én motortype pr. Bil)
  • Applikationsprogrammeringsgrænsefladeversion af forespørgselssproget, for programmerings bekvemmelighed

Opbevaring

Databaselagring er beholderen til den fysiske materialisering af en database. Det omfatter det interne (fysiske) niveau i databasearkitekturen. Den indeholder også alle de nødvendige oplysninger (f.eks. Metadata , "data om dataene" og interne datastrukturer ) for at rekonstruere det konceptuelle niveau og det eksterne niveau fra det interne niveau, når det er nødvendigt. At sætte data på permanent lagring er generelt databasemotorens ansvar , også kaldet "lagermotor". Selvom et DBMS typisk får adgang til det underliggende operativsystem (og ofte bruger operativsystemernes filsystemer som mellemprodukter til lagringslayout), er lagringsegenskaber og konfigurationsindstillinger ekstremt vigtige for effektiv drift af DBMS og vedligeholdes derfor tæt af databaseadministratorer. Et DBMS, mens det er i drift, har altid sin database i flere typer lagring (f.eks. Hukommelse og ekstern lagring). Databasedataene og den yderligere nødvendige information, muligvis i meget store mængder, kodes i bits. Data findes typisk i opbevaringen i strukturer, der ser helt anderledes ud, end dataene ser ud på det konceptuelle og eksterne niveau, men på måder, der forsøger at optimere (bedst muligt) disse niveaueres rekonstruktion, når det er nødvendigt af brugere og programmer, så godt hvad angår beregning af yderligere typer nødvendige oplysninger fra dataene (f.eks. ved forespørgsel i databasen).

Nogle DBMS'er understøtter angivelse af, hvilken tegnkodning der blev brugt til at gemme data, så flere kodninger kan bruges i den samme database.

Forskellige databaselagringsstrukturer på lavt niveau bruges af lagermotoren til at serialisere datamodellen, så den kan skrives til det valgte medium. Teknikker såsom indeksering kan bruges til at forbedre ydeevnen. Konventionel opbevaring er rækkeorienteret, men der er også søjleorienterede og korrelationsdatabaser .

Materialiserede visninger

Ofte bruges redundans til opbevaring for at øge ydeevnen. Et almindeligt eksempel er lagring af materialiserede visninger , som består af ofte nødvendige eksterne visninger eller forespørgselsresultater. Lagring af sådanne visninger sparer den dyre beregning af dem, hver gang de er nødvendige. Ulemperne ved materialiserede visninger er omkostningerne, der opstår, når de opdateres for at holde dem synkroniseret med deres originale opdaterede databasedata og omkostningerne ved lagringsredundans.

Replikation

Af og til anvender en database lagringsredundans ved replikering af databaseobjekter (med en eller flere kopier) for at øge datatilgængeligheden (både for at forbedre ydeevnen for samtidige flere slutbrugeradgange til det samme databaseobjekt og for at give modstandsdygtighed i tilfælde af delvis fejl i en distribueret database). Opdateringer af et replikeret objekt skal synkroniseres på tværs af objektkopierne. I mange tilfælde replikeres hele databasen.

Sikkerhed

Databasesikkerhed omhandler alle forskellige aspekter af beskyttelse af databaseindholdet, dets ejere og dets brugere. Det spænder fra beskyttelse fra forsætlige uautoriserede databaseanvendelser til utilsigtede databaseadgange fra uautoriserede enheder (f.eks. En person eller et computerprogram).

Databaseadgangskontrol handler om at kontrollere, hvem (en person eller et bestemt computerprogram) har adgang til hvilke oplysninger i databasen. Informationen kan omfatte specifikke databaseobjekter (f.eks. Posttyper, specifikke poster, datastrukturer), bestemte beregninger over bestemte objekter (f.eks. Forespørgselstyper eller specifikke forespørgsler) eller brug af specifikke adgangsstier til førstnævnte (f.eks. Ved hjælp af bestemte indekser eller andre datastrukturer for at få adgang til oplysninger). Databaseadgangskontroller indstilles af specielt autoriseret (af databaseejeren) personale, der anvender dedikerede beskyttede DBMS -grænseflader.

Dette kan styres direkte på individuelt grundlag eller ved tildeling af enkeltpersoner og privilegier til grupper eller (i de mest udførlige modeller) gennem tildeling af enkeltpersoner og grupper til roller, som derefter tildeles rettigheder. Datasikkerhed forhindrer uautoriserede brugere i at se eller opdatere databasen. Ved hjælp af adgangskoder får brugerne adgang til hele databasen eller delsæt af den kaldet "underskemaer". For eksempel kan en medarbejderdatabase indeholde alle data om en individuel medarbejder, men en gruppe brugere kan have tilladelse til kun at se løndata, mens andre kun har adgang til arbejdshistorik og medicinske data. Hvis DBMS giver en måde til interaktivt at indtaste og opdatere databasen samt forhøre den, giver denne kapacitet mulighed for at administrere personlige databaser.

Datasikkerhed handler generelt om at beskytte specifikke dele af data, både fysisk (dvs. mod korruption eller ødelæggelse eller fjernelse, f.eks. Se fysisk sikkerhed ) eller fortolkningen af ​​dem eller dele af dem til meningsfulde oplysninger (f.eks. ser på strengene af bits, de omfatter, og konkluderer specifikke gyldige kreditkortnumre, f.eks. se datakryptering ).

Skift og få adgang til logføringsposter, hvem der fik adgang til hvilke attributter, hvad der blev ændret, og hvornår det blev ændret. Logningstjenester giver mulighed for en retsmedicinsk databaseovervågning senere ved at registrere adgangshændelser og ændringer. Nogle gange bruges kode på applikationsniveau til at registrere ændringer frem for at overlade dette til databasen. Overvågning kan konfigureres for at forsøge at opdage sikkerhedsbrud.

Transaktioner og samtidighed

Databasetransaktioner kan bruges til at indføre et vist niveau af fejltolerance og dataintegritet efter gendannelse fra et nedbrud . En databasetransaktion er en arbejdsenhed, der typisk indkapsler et antal operationer over en database (f.eks. Læsning af et databaseobjekt, skrivning, erhvervelse af lås osv.), En abstraktion understøttet i database og også andre systemer. Hver transaktion har veldefinerede grænser med hensyn til hvilke program-/kodeudførelser der er inkluderet i denne transaktion (bestemt af transaktionens programmør via særlige transaktionskommandoer).

Akronymet ACID beskriver nogle ideelle egenskaber ved en databasetransaktion: atomicitet , konsistens , isolation og holdbarhed .

Migration

En database bygget med et DBMS er ikke bærbar til en anden DBMS (dvs. den anden DBMS kan ikke køre den). I nogle situationer er det imidlertid ønskeligt at migrere en database fra et DBMS til et andet. Årsagerne er primært økonomiske (forskellige DBMS'er kan have forskellige samlede ejeromkostninger eller TCO'er), funktionelle og operationelle (forskellige DBMS'er kan have forskellige muligheder). Migreringen involverer databasens transformation fra en DBMS -type til en anden. Transformationen skal (om muligt) opretholde den database -relaterede applikation (dvs. alle relaterede applikationsprogrammer) intakt. Således bør databasens konceptuelle og eksterne arkitektoniske niveauer fastholdes i transformationen. Det kan være ønskeligt, at også nogle aspekter af arkitekturens interne niveau opretholdes. En kompleks eller stor databaseoverførsel kan være et kompliceret og dyrt (engangs) projekt i sig selv, som bør indgå i beslutningen om at migrere. Dette på trods af det faktum, at der kan findes værktøjer til at hjælpe migrering mellem specifikke DBMS'er. Typisk giver en DBMS -leverandør værktøjer til at hjælpe med at importere databaser fra andre populære DBMS'er.

Bygger, vedligeholder og tuner

Efter at have designet en database til en applikation, er det næste trin at opbygge databasen. Typisk kan der vælges en passende generel DBMS til brug til dette formål. Et DBMS giver de nødvendige brugergrænseflader, der skal bruges af databaseadministratorer til at definere den nødvendige applikations datastrukturer inden for DBMS's respektive datamodel. Andre brugergrænseflader bruges til at vælge nødvendige DBMS -parametre (f.eks. Sikkerhedsrelaterede parametre, lagertildelingsparametre osv.).

Når databasen er klar (alle dens datastrukturer og andre nødvendige komponenter er defineret), udfyldes den typisk med første applikations data (databaseinitialisering, som typisk er et særskilt projekt; i mange tilfælde ved hjælp af specialiserede DBMS -grænseflader, der understøtter masseindsættelse) før gør den operationel. I nogle tilfælde bliver databasen operationel, mens den er tom for applikationsdata, og data akkumuleres under driften.

Når databasen er oprettet, initialiseret og udfyldt, skal den vedligeholdes. Forskellige databaseparametre skal muligvis ændres, og databasen skal muligvis indstilles ( tuning ) for bedre ydeevne; applikations datastrukturer kan ændres eller tilføjes, nye relaterede applikationsprogrammer kan skrives for at tilføje til applikationens funktionalitet osv.

Backup og genskab

Nogle gange er det ønskeligt at bringe en database tilbage til en tidligere tilstand (af mange årsager, f.eks. Tilfælde, hvor databasen er fundet ødelagt på grund af en softwarefejl, eller hvis den er blevet opdateret med fejlagtige data). For at opnå dette udføres en backupoperation lejlighedsvis eller kontinuerligt, hvor hver ønsket databasetilstand (dvs. værdierne for dens data og deres indlejring i databasens datastrukturer) opbevares i dedikerede backupfiler (mange teknikker findes for at gøre dette effektivt). Når det er besluttet af en databaseadministrator at bringe databasen tilbage til denne tilstand (f.eks. Ved at angive denne tilstand ved et ønsket tidspunkt, da databasen var i denne tilstand), bruges disse filer til at gendanne denne tilstand.

Statisk analyse

Statiske analyseteknikker til softwareverifikation kan også anvendes i scenariet med forespørgselssprog. Især * Abstrakt tolkningsrammen er blevet udvidet til at omfatte forespørgselssprog til relationelle databaser som en måde at understøtte lydtilnærmelsesteknikker på. Semantikken i forespørgselssprog kan indstilles efter passende abstraktioner af det konkrete datadomæne. Abstraktionen af ​​det relationelle databasesystem har mange interessante applikationer, især af sikkerhedsmæssige årsager, såsom finkornet adgangskontrol, vandmærkning osv.

Diverse funktioner

Andre DBMS -funktioner kan omfatte:

  • Databaselogfiler - Dette hjælper med at føre en historik over de udførte funktioner.
  • Grafisk komponent til fremstilling af grafer og diagrammer, især i et datalagringssystem.
  • Forespørgselsoptimering - Udfører forespørgselsoptimering for hver forespørgsel for at vælge en effektiv forespørgselsplan (en delvis rækkefølge (træ) af operationer), der skal udføres for at beregne forespørgselsresultatet. Kan være specifik for en bestemt lagermotor.
  • Værktøjer eller kroge til databasedesign, applikationsprogrammering, vedligeholdelse af applikationsprogram, analyse af databasens ydeevne og overvågning, overvågning af databasekonfiguration, DBMS -hardwarekonfiguration (en DBMS og tilhørende database kan omfatte computere, netværk og lagerenheder) og tilhørende databasekortlægning (især for en distribueret DBMS), lagertildeling og overvågning af database layout, lagringsmigrering osv.

I stigende grad er der opfordringer til et enkelt system, der inkorporerer alle disse kernefunktioner i den samme opbygnings-, test- og implementeringsramme til databasestyring og kildekontrol. Nogle låner fra andre udviklinger i softwareindustrien og markedsfører sådanne tilbud som " DevOps til database".

Design og modellering

Proces med database design v2.png

Den første opgave for en databasedesigner er at producere en konceptuel datamodel, der afspejler strukturen af ​​de oplysninger, der skal opbevares i databasen. En fælles tilgang til dette er at udvikle en entitetsrelationsmodel , ofte ved hjælp af tegneværktøjer. En anden populær tilgang er Unified Modeling Language . En vellykket datamodel vil nøjagtigt afspejle den mulige tilstand i den ydre verden, der modelleres: for eksempel, hvis folk kan have mere end ét telefonnummer, tillader det, at disse oplysninger fanges. Design af en god konceptuel datamodel kræver en god forståelse af applikationsdomænet; det indebærer typisk at stille dybe spørgsmål om de ting, der er interessante for en organisation, som "kan en kunde også være leverandør?", eller "hvis et produkt sælges med to forskellige former for emballage, er det samme produkt eller forskellige produkter? ", eller" hvis et fly flyver fra New York til Dubai via Frankfurt, er det en eller to flyvninger (eller måske endda tre)? ". Svarene på disse spørgsmål fastlægger definitioner af den terminologi, der bruges til enheder (kunder, produkter, flyrejser, flyvesegmenter) og deres relationer og attributter.

At producere den konceptuelle datamodel indebærer undertiden input fra forretningsprocesser eller analyse af arbejdsgangen i organisationen. Dette kan hjælpe med at fastslå, hvilke oplysninger der er nødvendige i databasen, og hvad der kan udelades. For eksempel kan det hjælpe, når det afgøres, om databasen skal indeholde historiske data såvel som aktuelle data.

Efter at have produceret en konceptuel datamodel, som brugerne er tilfredse med, er næste trin at oversætte dette til et skema, der implementerer de relevante datastrukturer i databasen. Denne proces kaldes ofte logisk databasedesign, og output er en logisk datamodel udtrykt i form af et skema. Mens den konceptuelle datamodel (i det mindste i teorien) er uafhængig af valget af databaseteknologi, vil den logiske datamodel blive udtrykt i form af en bestemt databasemodel understøttet af det valgte DBMS. (Betegnelserne datamodel og databasemodel bruges ofte i flæng, men i denne artikel bruger vi datamodel til design af en specifik database og databasemodel til modelleringsnotation, der bruges til at udtrykke dette design).

Den mest populære databasemodel for generelle databaser er den relationelle model, eller mere præcist, den relationsmodel, der er repræsenteret af SQL-sproget. Processen med at oprette et logisk databasedesign ved hjælp af denne model anvender en metodisk tilgang kendt som normalisering . Målet med normalisering er at sikre, at hver elementær "kendsgerning" kun registreres ét sted, så indsættelser, opdateringer og sletninger automatisk opretholder konsistens.

Den sidste fase af databasedesign er at træffe de beslutninger, der påvirker ydeevne, skalerbarhed, gendannelse, sikkerhed og lignende, som afhænger af det særlige DBMS. Dette kaldes ofte fysisk database design , og output er den fysiske datamodel . Et centralt mål i denne fase er datauafhængighed , hvilket betyder, at de beslutninger, der træffes med henblik på effektivitetsoptimering, skal være usynlige for slutbrugere og applikationer. Der er to typer datauafhængighed: Fysisk datauafhængighed og logisk datauafhængighed. Fysisk design er hovedsageligt drevet af krav til ydeevne og kræver et godt kendskab til den forventede arbejdsbyrde og adgangsmønstre og en dyb forståelse af de funktioner, der tilbydes af det valgte DBMS.

Et andet aspekt af fysisk databasedesign er sikkerhed. Det indebærer både at definere adgangskontrol til databaseobjekter samt at definere sikkerhedsniveauer og metoder til selve dataene.

Modeller

Collage af fem typer databasemodeller

En databasemodel er en type datamodel, der bestemmer den logiske struktur i en database og grundlæggende bestemmer på hvilken måde data kan lagres, organiseres og manipuleres. Det mest populære eksempel på en databasemodel er relationsmodellen (eller SQL-tilnærmelsen til relationel), der bruger et tabelbaseret format.

Almindelige logiske datamodeller for databaser omfatter:

En objekt -relationel database kombinerer de to relaterede strukturer.

Fysiske datamodeller omfatter:

Andre modeller omfatter:

Specialiserede modeller er optimeret til bestemte datatyper:

Eksterne, konceptuelle og interne synspunkter

Traditionel visning af data

Et databasesystem giver tre visninger af databasedataene:

  • Det eksterne niveau definerer, hvordan hver gruppe af slutbrugere ser organisering af data i databasen. En enkelt database kan have et vilkårligt antal visninger på eksternt niveau.
  • Det konceptuelle niveau forener de forskellige ydre opfattelser til et kompatibelt globalt syn. Det giver syntesen af ​​alle de eksterne synspunkter. Det er uden for anvendelsesområdet for de forskellige database-slutbrugere og er snarere af interesse for databaseapplikationsudviklere og databaseadministratorer.
  • Det interne niveau (eller det fysiske niveau ) er den interne organisering af data inde i et DBMS. Det vedrører omkostninger, ydeevne, skalerbarhed og andre operationelle spørgsmål. Det omhandler lagringslayout af dataene ved hjælp af lagringsstrukturer såsom indekser for at forbedre ydeevnen. Lejlighedsvis gemmer den data for individuelle visninger ( materialiserede visninger ), beregnet ud fra generiske data, hvis der findes en begrundelse for en sådan redundans. Det afbalancerer alle de eksterne visningers krav til ydeevne, muligvis modstridende, i et forsøg på at optimere den samlede ydelse på tværs af alle aktiviteter.

Selvom der typisk kun er én konceptuel (eller logisk) og fysisk (eller intern) visning af dataene, kan der være et vilkårligt antal forskellige eksterne visninger. Dette giver brugerne mulighed for at se databaseoplysninger på en mere forretningsrelateret måde snarere end fra et teknisk, behandlingsmæssigt synspunkt. For eksempel kan en finansiel afdeling af en virksomhed har brug for oplysninger om betaling for alle ansatte som en del af virksomhedens udgifter, men behøver ikke detaljer om medarbejdere, der er af interesse for menneskelige ressourcer afdeling. Derfor har forskellige afdelinger brug for forskellige visninger af virksomhedens database.

Databasearkitekturen på tre niveauer vedrører begrebet datauafhængighed, som var en af ​​de store indledende drivkræfter i relationel model. Tanken er, at ændringer foretaget på et bestemt niveau ikke påvirker udsigten på et højere niveau. F.eks. Påvirker ændringer på det interne niveau ikke applikationsprogrammer, der er skrevet ved hjælp af konceptuelle grænseflader, hvilket reducerer virkningen af ​​at foretage fysiske ændringer for at forbedre ydeevnen.

Den konceptuelle opfattelse giver et niveau af indirekte mellem indre og eksterne. På den ene side giver den en fælles opfattelse af databasen, uafhængig af forskellige eksterne visningsstrukturer, og på den anden side abstraherer den detaljer om, hvordan data gemmes eller administreres (internt niveau). I princippet kan hvert niveau og endda alle eksterne visninger præsenteres ved en anden datamodel. I praksis bruger en given DBMS normalt den samme datamodel til både det eksterne og det konceptuelle niveau (f.eks. Relationel model). Det interne niveau, som er skjult inde i DBMS og afhænger af dets implementering, kræver et andet detaljeringsniveau og bruger sine egne typer datastrukturtyper.

Adskillelse af det eksterne , konceptuelle og interne niveau var et vigtigt element i de relationelle databasemodelimplementeringer, der dominerer det 21. århundredes databaser.

Forskning

Databaseteknologi har været et aktivt forskningstema siden 1960'erne, både i den akademiske verden og i forsknings- og udviklingsgrupperne for virksomheder (f.eks. IBM Research ). Forskningsaktivitet omfatter teori og udvikling af prototyper . Bemærkelsesværdige forskningsemner har inkluderet modeller , atomtransaktionskonceptet og relaterede samtidighedskontrolteknikker , forespørgselssprog og metoder til forespørgselsoptimering , RAID og mere.

Database -forskningsområdet har flere dedikerede akademiske tidsskrifter (f.eks. ACM Transactions on Database Systems -TODS, Data and Knowledge Engineering -DKE) og årlige konferencer (f.eks. ACM SIGMOD , ACM PODS , VLDB , IEEE ICDE).

Se også

Noter

Referencer

Kilder

Yderligere læsning

eksterne links