En væsentlig fordel ved at bruge et RDBMS er “referentiel integritet”. Referentiel integritet refererer til nøjagtigheden og konsistensen af data. Denne dataintegritet opnås ved at bruge disse primære og fremmede nøgler.
Referentiel integritet bevarer dataintegriteten gennem “begrænsninger”. Begrænsninger er de regler, der håndhæver dataenes nøjagtighed ved at forhindre, at en relateret post slettes uden først at slette den primære post i hovedtabellen. Hvis en primær-fremmed nøgle-relation er blevet tilføjet korrekt, vil et forsøg på at slette en primær post uden først at fjerne relaterede poster fra andre tabeller blokere transaktionen, indtil de relaterede poster er fjernet. Dette forhindrer det, der kaldes “forældreløse poster”, dvs. refererede poster i en tabel, som ikke længere har en primær post i hovedtabellen.
De tre regler, som referentiel integritet håndhæver, er:
1. En fremmednøgle skal have en tilsvarende primærnøgle. (“Ingen forældreløse” regel.)
2. Når en post i en primær tabel slettes, skal alle relaterede poster, der refererer til primærnøglen, også slettes, hvilket typisk opnås ved hjælp af kaskade-sletning.
3. Hvis primærnøglen for en post ændres, skal alle tilsvarende poster i andre tabeller, der bruger primærnøglen som fremmednøgle, også ændres. Dette kan opnås ved hjælp af en kaskadeopdatering.
Søgning af data i et relationelt databasestyringssystem sker ved hjælp af Structured Querying Language (SQL), som er et robust sprog, der er udviklet til forvaltning af de data, der findes i en relationel database.
SQL har mulighed for at oprette, hente, opdatere og slette poster og er i høj grad afhængig af dette primær/fremmede nøgleforhold til at identificere relaterede data på tværs af flere tabeller. SQL’s muligheder gør det relationelle databasesystem til det første valg til enhver applikation, der kræver stærke transaktionsfunktioner, datamining og kompleks rapportering.
Denne SQL-anvisning demonstrerer hentning af et resultatsæt af, hvordan alle salgsposter for en enkelt medarbejder, hvis EmployeeId = 1, ville blive hentet.
SELECT * FROM Employees
JOIN Sales ON Employees.EmployeeId = SALES.EmployeeId
WHERE EmployeeId = 1
Denne næste SQL-angivelse er et eksempel på en forespørgsel, der implementerer joins på flere tabeller. I dette tilfælde henter SQL-forespørgslen alle medarbejderoplysninger, salgsoplysninger og kundeoplysninger fra tabellen Customers.
SELECT * FROM Employees
JOIN Sales ON Employees.EmployeeId = SALES.EmployeeId
JOIN Customers ON Customers.CustomerId = SALES.CustomerId
WHERE EmployeeId = 1
Relationelle databaser har også en funktion, der kaldes “indeksering”. Et databaseindeks er en datastruktur, som forbedrer hastigheden af datahentning. Indekser tilføjes almindeligvis til datafelter, der rutinemæssigt bruges til at forespørge og sammenføje tabeller. I ovenstående SQL-angivelser ville EmployeeId og CompanyId være kandidater til denne type optimering.
Non-relationelle databaser
Den ikke-relationelle database, eller NoSQL-database, lagrer data. Men i modsætning til den relationelle database er der ingen tabeller, rækker, primærnøgler eller fremmednøgler. I stedet bruger den ikke-relationelle database en lagringsmodel, der er optimeret til specifikke krav til den type data, der lagres.
Nogle af de mere populære NoSQL-databaser er MongoDB, Apache Cassandra, Redis, Couchbase og Apache HBase.
Der findes fire populære ikke-relationelle typer: dokumentdatalager, kolonneorienteret database, nøgleværdilager og grafdatabase. Ofte anvendes kombinationer af disse typer til en enkelt applikation.
Dokumentdatalagre
Et dokumentdatalagre administrerer et sæt navngivne strengfelter og objektdataværdier i en enhed, der betegnes som et “dokument”, der typisk lagres i form af JSON-dokumenter, som kan være kodet på en række forskellige måder, herunder XML, YAML, JSON, BSON eller som almindelig tekst. Felterne i dokumenterne er eksponeret, hvilket gør det muligt for en applikation at forespørge og filtrere data ved hjælp af feltværdier.
Dokumentlagrene kræver ikke, at alle dokumenter skal opretholde identiske datastrukturer, hvilket giver en stor fleksibilitet. Det er så let at se, hvordan denne fleksibilitet kan udnyttes, efterhånden som en organisations krav ændrer sig.
Søjleformede (eller kolonneorienterede) datalagre
Et kolonneformet datalagre organiserer data i kolonner, hvilket konceptuelt set ligner den relationelle database. Den sande fordel ved en kolonnefamiliedatabase ligger i dens denormaliserede tilgang til strukturering af sparsomme data, som kommer fra dens kolonneorienterede tilgang til lagring af data.
Nøgle-værdi-lagre
Dette er den mindst komplicerede af NoSQL-databaserne, og som navnet antyder, er nøgle-værdi-lageret simpelthen en samling af nøgle-værdipar, der er indeholdt i et objekt.
Dokumentlagre
Dokumentlagre er en smule mere komplekse end nøgle-værdilagre. De forudsætter ikke en bestemt dokumentstruktur, der er specificeret med et skema. Dokumentlageret er designet til at gemme hverdagsdokumenter som de er, og de giver mulighed for komplicerede forespørgsler.
MongoDB og CouchDB er begge eksempler på dokumentlagre.
Graph databaser
Den sidste er den mest komplekse ikke-relationelle databasetype. Den er designet til effektivt at lagre relationer mellem enheder. Når data er meget indbyrdes forbundne, f.eks. indkøbs- og produktionssystemer eller referencekataloger, er grafdatabaser en god løsning.
Mulighederne for graf-NoSQL-databaser er uendelige, og i takt med at de data, vi indsamler, bliver mere og mere indbyrdes forbundne, vil grafdatabaser fortsat vinde i popularitet, herunder den stadig dominerende relationelle database.
I stedet for det Structure Query Language (SQL), der anvendes af relationelle databaser, bruger NoSQL-databasen Object-relational-mapping (ORM). Konceptet ORM er muligheden for at skrive forespørgsler ved hjælp af dit foretrukne programmeringssprog. Nogle af de mere populære ORM’er er Java, Javascript, .NET og PHP.
I opsummering
Hvad du skal vide om relationelle databaser:
-
De arbejder med strukturerede data.
-
Relationer i systemet har begrænsninger, hvilket fremmer en høj grad af dataintegritet.
-
Der er ubegrænsede indekseringsmuligheder, hvilket resulterer i hurtigere svartider for forespørgsler.
-
De er fremragende til at holde datatransaktioner sikre.
-
De giver mulighed for at skrive komplekse SQL-forespørgsler til dataanalyse og rapportering.
-
Deres modeller kan sikre og håndhæve forretningsregler i datalaget, hvilket tilføjer et niveau af dataintegritet, som ikke findes i en ikke-relationel database.
-
De er tabel- og rækkeorienterede.
-
De bruger SQL (struktureret forespørgselssprog) til at forme og manipulere data, hvilket er meget kraftfuldt.
-
SQL-databaseeksempler: MySql, Oracle, Sqlite, Postgres og MS-SQL. NoSQL-databaseeksempler: MongoDB, BigTable, Redis, RavenDb, Cassandra, Hbase, Neo4j og CouchDb.
-
SQL-databaser er bedst egnet til tunge applikationer af transaktionstype.
Non-relationelle/NoSQL-databaser:
-
De har evnen til at lagre store datamængder med lidt struktur.
-
De giver skalerbarhed og fleksibilitet til at opfylde skiftende forretningskrav.
-
De giver mulighed for skema-fri eller schema-on-read muligheder.
-
De har evnen til at indfange alle typer data “Big Data”, herunder ustrukturerede data.
-
De er dokumentorienterede.
-
NoSQL- eller ikke-relationelle databaser eksempler: MongoDB, Apache Cassandra, Redis, Couchbase og Apache HBase.
-
De er bedst til hurtig applikationsudvikling. NoSQL er det bedste valg til fleksibel datalagring med få eller ingen strukturbegrænsninger.
-
De giver en fleksibel datamodel med mulighed for nemt at lagre og kombinere data af enhver struktur uden at skulle ændre et skema.
Så, hvad skal du vælge til dit projekt? For at få svar på dette spørgsmål kan vi cirkle tilbage til begyndelsen af denne artikel. Disse to meget forskellige typer databaser er lige nyttige i deres egen ret, men af modsatrettede årsager og i forskellige brugssituationer. Den ene er ikke nødvendigvis bedre end den anden, og både relationelle og ikke-relationelle databaser har deres plads.
Kort sagt er der ikke noget enkelt rigtigt svar. Den bedste måde at afgøre, hvilken databasetype der er bedst til dit projekt, er at analysere organisationens behov og den applikationsfunktionalitet, du skal opnå.