Yksi merkittävä etu RDBMS-tietokannan käytössä on ”viitteellinen eheys”. Viitteellisellä eheydellä tarkoitetaan tietojen tarkkuutta ja johdonmukaisuutta. Tämä tietojen eheys saavutetaan käyttämällä näitä primääri- ja vierasavaimia.
Viitteellinen eheys säilyttää tietojen eheyden ”rajoitteiden” avulla. Rajoitukset ovat sääntöjä, jotka varmistavat tietojen oikeellisuuden estämällä siihen liittyvän tietueen poistamisen poistamatta ensin päätaulun ensisijaista tietuetta. Jos ensisijaisen ja vieraan avaimen suhde on lisätty asianmukaisesti, ensisijaisen tietueen poistoyritys poistamatta ensin toisiin taulukoihin liittyviä tietueita muista taulukoista estää tapahtuman, kunnes toisiinsa liittyvät tietueet on poistettu. Näin estetään niin sanotut ”orvot tietueet”, jotka ovat taulussa olevia viitattuja tietueita, joilla ei enää ole ensisijaista tietuetta päätaulussa.
Kolme sääntöä, joita viitteellinen eheys noudattaa, ovat:
1. Ulkoisella avaimella on oltava vastaava ensisijainen avain. (”Ei orpoja” -sääntö.)
2. Kun ensisijaisen taulun tietue poistetaan, kaikki siihen liittyvät tietueet, jotka viittaavat ensisijaiseen avaimeen, on myös poistettava, mikä toteutetaan tyypillisesti käyttämällä kaskadipoistoa (cascade delete).
3. Jos tietueen ensisijainen avain muuttuu, kaikki vastaavat tietueet muissa taulukoissa, jotka käyttävät ensisijaista avainta vieraana avaimena, on myös muutettava. Tämä voidaan toteuttaa käyttämällä kaskadipäivitystä.
Relaatiotietokannan hallintajärjestelmän tietojen kysely tapahtuu käyttämällä Structured Querying Language (SQL) -kieltä, joka on vankka kieli, joka on suunniteltu relaatiotietokantaan tallennettujen tietojen hallintaan.
SQL:llä on valmiudet tietueiden luomiseen, hakemiseen, päivittämiseen ja poistamiseen, ja se tukeutuu pitkälti primaari- ja vieraisiin avaimiin perustuvaan suhteeseen, jonka avulla voidaan yksilöidä toisiinsa liittyvää dataa useissa eri tauluissa. SQL:n ominaisuudet tekevät relaatiotietokantajärjestelmästä ensisijaisen vaihtoehdon kaikkiin sovelluksiin, jotka vaativat vahvaa transaktiotoimintoa, tiedonlouhintaa ja monimutkaista raportointia.
Tämä SQL-lause havainnollistaa tulosjoukon hakemista siitä, miten haetaan kaikki yhden työntekijän, jonka EmployeeId = 1, myyntitiedot.
SELECT * FROM Employees
JOIN Sales ON Employees.EmployeeId = SALES.EmployeeId
WHERE EmployeeId = 1
Tämä seuraava SQL-lause on esimerkki kyselystä, joka toteuttaa yhdistämisiä useisiin taulukoihin. Tässä tapauksessa SQL-kysely hakee kaikki työntekijätiedot, myyntitiedot ja asiakastiedot Customers-taulusta.
SELECT * FROM Työntekijät
JOIN Myynti ON Työntekijät.TyöntekijäId = MYYNTI.TyöntekijäId
JOIN Asiakkaat ON Asiakkaat.AsiakasId = MYYNTI.AsiakasId
WHERE TyöntekijäId = 1
Relaationaalisissa tietokannoissa on tarjolla myös toiminto, jota kutsutaan nimellä ”indeksoiminen” (indexing). Tietokantaindeksi on tietorakenne, joka parantaa tiedonhaun nopeutta. Indeksejä lisätään yleisesti tietokenttiin, joita käytetään rutiininomaisesti taulukoiden kyselyissä ja yhdistämisessä. Yllä olevissa SQL-lausekkeissa EmployeeId ja CompanyId olisivat ehdokkaita tämäntyyppiselle optimoinnille.
Ei-relationaaliset tietokannat
Ei-relationaalinen tietokanta eli NoSQL-tietokanta tallentaa tietoja. Toisin kuin relaatiotietokannassa, siinä ei kuitenkaan ole tauluja, rivejä, pääavaimia tai vierasavaimia. Sen sijaan ei-relationaalinen tietokanta käyttää tallennusmallia, joka on optimoitu tallennettavan tietotyypin erityisvaatimuksiin.
Joitakin suosituimpia NoSQL-tietokantoja ovat MongoDB, Apache Cassandra, Redis, Couchbase ja Apache HBase.
Suosittuja ei-relationaalisia tietokantatyyppejä on neljä: dokumenttidatan tallennusmuisti (document data store), sarakkeisiin perustuva tietokanta (column-oriented database), avain-arvosäilö (key-value store) ja graafitietokanta (graph database). Usein yhdessä sovelluksessa käytetään näiden tyyppien yhdistelmiä.
Dokumenttitietovarastot
Dokumenttitietovarasto hallinnoi joukkoa nimettyjä merkkijonokenttiä ja objektitietoarvoja kokonaisuudessa, johon viitataan nimellä ”dokumentti” ja joka on tyypillisesti tallennettu JSON-dokumentteina, jotka voidaan koodata monin eri tavoin, kuten XML:llä, YAML:llä, JSON:lla, BSON:lla tai tavallisena tekstinä. Asiakirjojen sisällä olevat kentät ovat avoimia, jolloin sovellus voi kysyä ja suodattaa tietoja kenttien arvojen avulla.
Dokumenttivarastot eivät vaadi kaikilta asiakirjoilta identtisten tietorakenteiden ylläpitämistä, mikä tarjoaa paljon joustavuutta. On siis helppo nähdä, miten tätä joustavuutta voidaan hyödyntää organisaation vaatimusten muuttuessa.
Sarakkeelliset (tai sarakepohjaiset) tietovarastot
Sarakkeellisessa tietovarastossa tiedot järjestetään sarakkeisiin, mikä muistuttaa käsitteellisesti relaatiotietokantaa. Sarakkeisiin perustuvan tietokannan todellinen etu on sen denormalisoitu lähestymistapa harvan datan jäsentämiseen, mikä johtuu sarakkeisiin suuntautuneesta lähestymistavasta datan tallentamiseen.
avain-arvo-tietovarastot
Tämä on NoSQL-tietokannoista vähiten monimutkainen, ja kuten nimestä voi päätellä, avain-arvo-tietovarastossa on kyse yksinkertaisesti kokoelmasta objektiin sisältyviä avain-arvo-pareja.
Dokumenttivarastot
Dokumenttivarastot ovat hieman monimutkaisempia kuin avain-arvovarastot. Ne eivät oleta tiettyä dokumenttirakennetta, joka on määritelty skeeman avulla. Dokumenttivarasto on suunniteltu tallentamaan jokapäiväisiä dokumentteja sellaisenaan, ja ne mahdollistavat monimutkaisen kyselyn.
MongoDB ja CouchDB ovat molemmat esimerkkejä dokumenttivarastoista.
Graafitietokannat
Viimeinen on monimutkaisin ei-relationaalinen tietokantatyyppi. Se on suunniteltu tallentamaan tehokkaasti olioiden välisiä suhteita. Kun tiedot ovat vahvasti yhteydessä toisiinsa, kuten osto- ja valmistusjärjestelmät tai viiteluettelot, graafitietokannat ovat hyvä ratkaisu.
Graafi-NOSSQL-tietokantojen mahdollisuudet ovat rajattomat, ja kun keräämämme tiedot ovat yhä enemmän yhteydessä toisiinsa, graafitietokannat tulevat jatkossakin kasvattamaan suosiotaan, mukaan lukien edelleen vallalla oleva relaatiotietokanta.
Relaatiotietokantojen käyttämän SQL-kyselykielekkeen (SQL, Structure Query Language) sijaan NoSQL-tietokannassa hyödynnetään ORM:iä (ORM, Object-Relational-Mapping). ORM:n käsite on mahdollisuus kirjoittaa kyselyitä haluamallasi ohjelmointikielellä. Joitakin suositumpia ORM-ohjelmia ovat Java, Javascript, .NET ja PHP.
Yhteenvetona
Mitä sinun on tiedettävä relaatiotietokannoista:
-
Ne työskentelevät strukturoitujen tietojen kanssa.
-
Järjestelmässä olevilla suhteilla on rajoituksia, mikä edistää tietojen eheyttä.
-
Neillä on rajattomat indeksointimahdollisuudet, mikä johtaa nopeampiin kyselyiden vasteaikoihin.
-
Neillä on erinomaiset mahdollisuudet pitää tietotapahtumat turvallisina.
-
Ne tarjoavat mahdollisuuden kirjoittaa monimutkaisia SQL-kyselyjä tietojen analysointia ja raportointia varten.
-
Malleilla voidaan varmistaa ja panna täytäntöön liiketoimintasääntöjä tietokerroksessa, mikä lisää tietojen eheyden tason, jota ei löydy ei-relationaalisista tietokannoista.
-
Ne ovat taulukko- ja rivisuuntautuneita.
-
Ne käyttävät SQL:ää (strukturoitua kyselykieltä) tietojen muokkaamiseen ja käsittelyyn, mikä on erittäin tehokasta.
-
SQL-tietokantaesimerkkejä: MySql, Oracle, Sqlite, Postgres ja MS-SQL. NoSQL-tietokantaesimerkkejä: MongoDB, BigTable, Redis, RavenDb, Cassandra, Hbase, Neo4j ja CouchDb.
-
SQL-tietokannat soveltuvat parhaiten raskaisiin transaktiotyyppisiin sovelluksiin.
Ei-relationaaliset/NoSQL-tietokannat:
-
Neillä on kyky tallentaa suuria tietomääriä, joilla on vain vähän rakennetta.
-
Näillä on skaalautuvuutta ja joustavuutta, jotta ne pystyvät vastaamaan muuttuviin liiketoimintavaatimuksiin.
-
Ne tarjoavat skeemattomia tai skeema-on-read -vaihtoehtoja.
-
Ne kykenevät tallentamaan kaikenlaista dataa ”Big Data”, mukaan lukien jäsentymätön data.
-
Ne ovat dokumenttikeskeisiä.
-
NoSQL- eli ei-relationaaliset tietokannat esimerkkejä: MongoDB, Apache Cassandra, Redis, Couchbase ja Apache HBase.
-
Ne soveltuvat parhaiten nopeaan sovelluskehitykseen. NoSQL on paras valinta joustavaan datan tallennukseen, jossa on vain vähän tai ei lainkaan rakenteellisia rajoituksia.
-
Ne tarjoavat joustavan tietomallin, jonka avulla voidaan helposti tallentaa ja yhdistellä minkä tahansa rakenteen omaavaa dataa ilman, että skeemaa tarvitsee muuttaa.
Kumman siis valitsisit projektiisi? Vastauksen tähän kysymykseen saamiseksi voimme palata tämän artikkelin alkuun. Nämä kaksi hyvin erilaista tietokantatyyppiä ovat itsessään yhtä hyödyllisiä, mutta niillä on vastakkaiset syyt ja käyttötarkoitukset. Toinen ei välttämättä ole toista parempi, ja sekä relaatiotietokannoilla että ei-relaatiotietokannoilla on paikkansa.
Lyhyesti sanottuna ei ole olemassa yhtä ainoaa oikeaa vastausta. Paras tapa määrittää, mikä tietokantatyyppi on paras omaan projektiin, on analysoida organisaation tarpeet ja sovelluksen toiminnallisuus, joka halutaan saavuttaa.