En stor fördel med att använda ett RDBMS är ”referentiell integritet”. Referentiell integritet avser datans noggrannhet och konsistens. Denna dataintegritet uppnås genom att använda dessa primära och utländska nycklar.
Referentiell integritet bevarar dataintegriteten genom ”begränsningar”. Restriktioner är de regler som upprätthåller uppgifternas riktighet genom att förhindra att en relaterad post raderas utan att först radera den primära posten i huvudtabellen. Om ett förhållande mellan primär och främmande nyckel har lagts till på rätt sätt blockeras transaktionen tills de relaterade posterna har tagits bort om man försöker ta bort en primär post utan att först ta bort relaterade poster från andra tabeller. Detta förhindrar så kallade ”föräldralösa poster”, dvs. refererade poster i en tabell som inte längre har en primär post i huvudtabellen.
De tre regler som referentiell integritet upprätthåller är:
1. En främmande nyckel måste ha en motsvarande primärnyckel. (Regeln ”Inga föräldralösa”.)
2. När en post i en primär tabell tas bort måste alla relaterade poster som hänvisar till primärnyckeln också tas bort, vilket vanligtvis åstadkoms med hjälp av cascade delete.
3. Om primärnyckeln för en post ändras måste alla motsvarande poster i andra tabeller som använder primärnyckeln som en främmande nyckel också ändras. Detta kan åstadkommas med hjälp av en kaskaduppdatering.
För att söka data i ett relationellt databashanteringssystem används Structured Querying Language (SQL), som är ett robust språk som är utformat för att hantera data som finns i en relationsdatabas.
SQL har kapacitet för att skapa, hämta, uppdatera och radera poster och förlitar sig i hög grad på detta förhållande mellan primär- och utländsk nyckel för att identifiera relaterade data i flera tabeller. Funktionerna hos SQL gör det relationella databassystemet till förstahandsvalet för alla tillämpningar som kräver stark transaktionsfunktionalitet, datautvinning och komplex rapportering.
Detta SQL-statement visar hur man hämtar en resultatuppsättning av hur alla försäljningsposter för en enskild anställd vars EmployeeId = 1 skulle hämtas.
SELECT * FROM Employees
JOIN Sales ON Employees.EmployeeId = SALES.EmployeeId
WHERE EmployeeId = 1
Detta nästa SQL-utdrag är ett exempel på en fråga som implementerar joins på flera tabeller. I det här fallet hämtar SQL-frågan all information om anställda, försäljning och kunder från tabellen Customers.
SELECT * FROM Employees
JOIN Sales ON Employees.EmployeeId = SALES.EmployeeId
JOIN Customers ON Customers.CustomerId = SALES.CustomerId
WHERE EmployeeId = 1
Relationella databaser har också en funktionalitet som kallas ”indexering”. Ett databasindex är en datastruktur som förbättrar hastigheten för datahämtning. Index läggs vanligen till i datafält som rutinmässigt används för att söka efter och sammanföra tabeller. I ovanstående SQL-utsagor skulle EmployeeId och CompanyId vara kandidater för den här typen av optimering.
Non-relationella databaser
Den icke-relationella databasen, eller NoSQL-databasen, lagrar data. Till skillnad från den relationella databasen finns det dock inga tabeller, rader, primärnycklar eller främmande nycklar. I stället använder den icke-relationella databasen en lagringsmodell som är optimerad för specifika krav för den typ av data som lagras.
Några av de mer populära NoSQL-databaserna är MongoDB, Apache Cassandra, Redis, Couchbase och Apache HBase.
Det finns fyra populära icke-relationella typer: dokumentdatalagret, den kolumnorienterade databasen, nyckelvärdeslagret och grafdatabasen. Ofta används kombinationer av dessa typer för en enda applikation.
Dokumentdatalagret
Ett dokumentdatalagret hanterar en uppsättning namngivna strängfält och objektdatavärden i en enhet som kallas ”dokument” och som vanligtvis lagras i form av JSON-dokument, som kan kodas på en mängd olika sätt, bland annat XML, YAML, JSON, BSON eller som vanlig text. Fälten i dokumenten är exponerade, vilket gör det möjligt för ett program att söka efter och filtrera data med hjälp av fältvärden.
Dokumentlagren kräver inte att alla dokument ska ha identiska datastrukturer, vilket ger en stor flexibilitet. Det är då lätt att se hur denna flexibilitet kan utnyttjas när organisationens krav förändras.
Columnar (eller kolumnorienterade) datalager
Ett kolumnorienterat datalagret organiserar data i kolumner, vilket begreppsmässigt liknar den relationella databasen. Den verkliga fördelen med en kolonnorienterad databas ligger i dess denormaliserade tillvägagångssätt för att strukturera glesa data, vilket kommer från dess kolumnorienterade tillvägagångssätt för att lagra data.
Nyckelvärdeslagren
Det här är den minst komplicerade av NoSQL-databaserna och som namnet antyder är nyckelvärdeslagret helt enkelt en samling av nyckelvärdespar som finns i ett objekt.
Dokumentarkiv
Dokumentarkiv är lite mer komplicerade än nyckelvärdearkiv. De utgår inte från en viss dokumentstruktur som specificeras med ett schema. Dokumentlagret är utformat för att lagra vardagliga dokument som de är, och de tillåter komplicerade sökningar.
MongoDB och CouchDB är båda exempel på dokumentlager.
Grafdatabaser
Sist är den mest komplexa icke-relationella databastypen. Den är utformad för att effektivt lagra relationer mellan enheter. När data är starkt sammankopplade, till exempel inköps- och tillverkningssystem eller referenskataloger, är grafdatabaser en bra lösning.
Möjligheterna för graf NoSQL-databaser är oändliga, och i och med att de data vi samlar in blir alltmer sammankopplade kommer grafdatabaser att fortsätta att vinna i popularitet, inklusive den fortfarande dominerande relationsdatabasen.
Istället för Structure Query Language (SQL) som används av relationsdatabaser använder NoSQL-databaser Object-relational-mapping (ORM). Begreppet ORM innebär att man kan skriva frågor med hjälp av det programmeringsspråk man föredrar. Några av de mer populära ORM:erna är Java, Javascript, .NET och PHP.
I sammanfattning
Vad du behöver veta om relationsdatabaser:
-
De arbetar med strukturerade data.
-
Relationer i systemet har begränsningar, vilket främjar en hög dataintegritet.
-
Det finns obegränsade indexeringsmöjligheter, vilket resulterar i snabbare svarstider på förfrågningar.
-
De är utmärkta på att hålla datatransaktioner säkra.
-
De ger möjlighet att skriva komplexa SQL-förfrågningar för dataanalys och rapportering.
-
Dess modeller kan säkerställa och genomdriva affärsregler på dataskiktet vilket ger en nivå av dataintegritet som inte finns i en icke-relationell databas.
-
De är tabell- och radorienterade.
-
De använder SQL (strukturerat frågespråk) för att forma och manipulera data, vilket är mycket kraftfullt.
-
SQL-databas exempel: MySql, Oracle, Sqlite, Postgres och MS-SQL. NoSQL-databas exempel: MongoDB, BigTable, Redis, RavenDb, Cassandra, Hbase, Neo4j och CouchDb.
-
SQL-databaser lämpar sig bäst för tunga transaktioner.
Non-relationella/NoSQL-databaser:
-
De har förmågan att lagra stora datamängder med liten struktur.
-
De ger skalbarhet och flexibilitet för att möta föränderliga verksamhetskrav.
-
De tillhandahåller alternativ för schemafri eller schema-on-read.
-
De har förmågan att fånga in alla typer av data ”Big Data” inklusive ostrukturerade data.
-
De är dokumentorienterade.
-
NoSQL- eller icke-relationella databaser exempel: MongoDB, Apache Cassandra, Redis, Couchbase och Apache HBase.
-
De är bäst för snabb applikationsutveckling. NoSQL är det bästa valet för flexibel datalagring med få eller inga strukturbegränsningar.
-
De ger en flexibel datamodell med möjlighet att enkelt lagra och kombinera data av vilken struktur som helst utan att behöva ändra ett schema.
Så, vilken ska du välja för ditt projekt? För svaret på denna fråga kan vi cirkla tillbaka till början av denna artikel. Dessa två mycket olika typer av databaser är lika användbara i sin egen rätt men av kontrasterande skäl och användningsområden. Den ena är inte nödvändigtvis bättre än den andra och både relationella och icke-relationella databaser har sin plats.
Kort sagt finns det inget enda rätt svar. Det bästa sättet att avgöra vilken databastyp som är bäst för ditt projekt är att analysera organisationens behov och den applikationsfunktionalitet du behöver uppnå.