- Tietokannanhallinta
- Ominaisuudet ja elementit
- -elementtejä
- monikko
- sarake
- avain
- - Eheyden säännöt
- Avaimen eheys
- Referenssinen eheys
- Kuinka tehdä relaatiomalli?
- -Kerätä dataa
- - Määritä ensisijaiset avaimet
- -Luo suhteita taulukoiden välillä
- Yksi monille
- Suunnittele kaksi pöytää
- Monista monille
- Yksi kerrallaan
- Etu
- Rakenteellinen riippumattomuus
- Käsitteellinen yksinkertaisuus
- Helppo suunnittelu, toteutus, ylläpito ja käyttö
- Ad-hoc-kyselykapasiteetti
- haitat
- Laitteiden kulut
- Suunnittelu helppous voi johtaa huonoon suunnitteluun
- «Tietosaarten» ilmiö
- esimerkki
- Viitteet
Relaatiotietokannan malli on menetelmä jäsentää dataa suhteiden avulla grid kaltaisia rakenteita, jotka koostuvat sarakkeita ja rivejä. Se on relaatiotietokantojen käsitteellinen periaate. Sen ehdotti Edgar F. Codd vuonna 1969.
Siitä on sittemmin tullut hallitseva tietokantamalli liiketoimintasovelluksille verrattuna muihin tietokantamalleihin, kuten hierarkkisiin, verkko- ja objektiominaisuuksiin.

Lähde: pixabay.com
Coddilla ei ollut aavistustakaan siitä, kuinka erittäin elintärkeä ja vaikuttava hänen työ relaatiotietokantojen alustana olisi. Suurin osa ihmisistä tuntee hyvin suhteen fyysisen ilmaisun tietokannassa: taulukon.
Suhteellisuusmalli määritellään tietokannaksi, joka mahdollistaa sen tietoelementtien ryhmittelyn yhteen tai useampaan riippumattomaan taulukkoon, jotka voidaan liittää toisiinsa käyttämällä kutakin liittyvää taulukkoa koskevia yhteisiä kenttiä.
Tietokannanhallinta
Tietokantataulukko on samanlainen kuin laskentataulukko. Taulukoiden välillä luotavat suhteet sallivat relaatiotietokannan kuitenkin tallentaa tehokkaasti suuren määrän dataa, joka voidaan hakea tehokkaasti.
Suhteellisemallin tarkoituksena on tarjota deklaratiivinen menetelmä tietojen ja kyselyiden määrittelemiseksi: käyttäjät ilmoittavat suoraan, mitä tietoja tietokanta sisältää ja mitä tietoja he haluavat siitä.
Toisaalta he jättävät tietokannan hallintajärjestelmän ohjelmiston kuvaamaan varastoitavat tietorakenteet ja hakuprosessin vastaamaan kyselyihin.
Useimmat relaatiotietokannat käyttävät SQL-kieltä tietojen kyselyyn ja määrittelyyn. Tällä hetkellä on olemassa monia relaatiotietokannan hallintajärjestelmiä tai RDBMS (relaatiotietokannan hallintajärjestelmä), kuten Oracle, IBM DB2 ja Microsoft SQL Server.
Ominaisuudet ja elementit
- Kaikki tiedot esitetään käsitteellisesti järjestettynä tietojen järjestelynä riveissä ja sarakkeissa, joita kutsutaan suhteeksi tai taulukkoksi.
- Jokaisessa taulukossa on oltava otsikko ja runko. Otsikko on yksinkertaisesti luettelo sarakkeista. Runko on taulukkoa täyttävä tietojoukko, joka on järjestetty riviin.
- Kaikki arvot ovat skalaareja. Eli missä tahansa taulukon rivin / sarakkeen sijainnissa on vain yksi arvo.
-elementtejä
Seuraava kuva esittää taulukon, jossa on sen peruselementtien nimet, jotka muodostavat kokonaisen rakenteen.

monikko
Jokainen tietorivi on kokonaisuus, joka tunnetaan myös nimellä tietue. Jokainen rivi on n-pari, mutta "n-" yleensä hylätään.
sarake
Jokaista tuplen saraketta kutsutaan määritteeksi tai kentäksi. Sarake edustaa arvojoukkoa, jolla tietyllä määritteellä voi olla.
avain
Jokaisessa rivissä on yksi tai useampi sarake, jota kutsutaan taulukkoavaimeksi. Tämä yhdistetty arvo on ainutlaatuinen kaikille taulukon riveille. Tämän näppäimen avulla jokainen pari tunnistetaan yksilöllisesti. Toisin sanoen avainta ei voida kopioida. Sitä kutsutaan ensisijaiseksi avaimeksi.
Toisaalta, vieras tai toissijainen avain on taulukon kenttä, joka viittaa jonkin muun taulukon ensisijaiseen avaimeen. Sitä käytetään viitaamaan ensisijaiseen taulukkoon.
- Eheyden säännöt
Suunnitellessasi relaatiomallia, määrität joitain ehtoja, joita tietokannassa on täytettävä, joita kutsutaan eheyssääntöiksi.
Avaimen eheys
Ensisijaisen avaimen on oltava yksilöllinen kaikille tupleille, eikä se voi olla tyhjä (NULL). Muuten et pysty tunnistamaan riviä yksilöllisesti.
Monisarakkeisen avaimen tapauksessa mikään näistä sarakkeista ei voi sisältää NULL-arvoa.
Referenssinen eheys
Jokaisen vieraan avaimen arvon on vastattava viitatun tai ensisijaisen taulukon ensisijaisen avaimen arvoa.
Rivi ulkomaisella avaimella voidaan lisätä toissijaiseen taulukkoon vain, jos tämä arvo on ensisijaisessa taulukossa.
Jos avaimen arvo muuttuu ensisijaisessa taulukossa, koska rivi päivitetään tai poistetaan, kaikki tämän vieraan avaimen toissijaisten taulukoiden rivit tulisi päivittää tai poistaa vastaavasti.
Kuinka tehdä relaatiomalli?
-Kerätä dataa
Tietokantaan tallentamista varten on kerättävä tarvittavat tiedot. Nämä tiedot on jaettu eri taulukoihin.
Jokaiselle sarakkeelle on valittava sopiva tietotyyppi. Esimerkiksi: kokonaisluku, liukuluku, teksti, päivämäärä jne.
- Määritä ensisijaiset avaimet
Kullekin taulukolle ensisijaiseksi avaimeksi on valittava sarake (tai muutama sarake), joka yksilöi taulukon jokaisen rivin yksilöllisesti. Ensisijaista avainta käytetään myös viittaamaan muihin taulukoihin.
-Luo suhteita taulukoiden välillä
Itsenäisistä, toisistaan riippumattomista taulukoista koostuva tietokanta palvelee vain vähän tarkoitusta.
Tärkein näkökohta relaatiotietokannan suunnittelussa on taulukoiden välisten suhteiden tunnistaminen. Suhdetyypit ovat:
Yksi monille
"Class Listing" -tietokannassa opettaja voi opettaa nollaa tai enemmän luokkia, kun taas luokan opettaa yksi opettaja. Tämän tyyppisiä suhteita tunnetaan yhdestä moniin.
Tätä suhdetta ei voida esittää yhdessä taulukossa. Tietokannassa «Listaluettelo» voi olla Opettajien-taulukko, joka tallentaa tietoja opettajista.
Tallentaaksesi kunkin opettajan opettamat luokat voit luoda lisäsarakkeita, mutta kohtaat ongelman: kuinka monta saraketta luodaan.
Toisaalta, jos sinulla on luokkien niminen taulukko, joka tallentaa luokan tietoja, voit luoda lisäsarakkeita opettajan tietojen tallentamiseksi.
Koska opettaja voi kuitenkin opettaa monia luokkia, hänen tiedot kopioidaan monilla luokkataulukon riveillä.
Suunnittele kaksi pöytää
Siksi sinun on suunniteltava kaksi taulukkoa: luokkataulukko tietojen tallentamiseksi luokista, ensisijaisena avaimena Class_Id ja opettajat-taulukko opettajien tietojen tallentamiseksi, opettaja_Id: n ensisijaisena avaimena.
Yhden suhde voidaan sitten luoda tallentamalla ensisijainen avain päätaulusta (Master_Id) Luokka-taulukkoon, kuten alla on kuvattu.

Luokat-taulukon Master_Id-sarake tunnetaan vieraana avaimena tai toissijaisena avaimena.
Jokaisella Master-taulukon Master_Id-arvolla Classes-taulukossa voi olla nolla tai enemmän rivejä. Jokaisella Class_Id -arvolla Classes-taulukossa on vain yksi rivi Opettajat-taulukossa.
Monista monille
Tuotemyyntitietokannassa asiakastilaus voi sisältää useita tuotteita ja tuote voi esiintyä useissa tilauksissa. Tämän tyyppisiä suhteita tunnetaan monista monille.
Voit käynnistää "Tuotemyynti" -tietokannan kahdella taulukolla: Tuotteet ja Tilaukset. Tuotteet-taulukko sisältää tietoja tuotteista, ensisijaisena avaimena tuotteen tunnus.
Toisaalta Tilaukset-taulukko sisältää asiakkaan tilaukset, joiden ensisijaisena avaimena on orderID.
Et voi tallentaa tilattuja tuotteita Tilaukset-taulukkoon, koska et tiedä kuinka monta saraketta varata tuotteille. Tilauksia ei myöskään voida tallentaa Tuotteet-taulukkoon samasta syystä.
Tukeaksesi monien välisiä suhteita, sinun on luotava kolmas taulukko, joka tunnetaan liittymistaulukkona (OrderDetails) ja jossa jokainen rivi edustaa kohdetta tietyssä järjestyksessä.
OrderDetails-taulukon ensisijainen avain koostuu kahdesta sarakkeesta: orderID ja productID, jotka yksilöivät kunkin rivin yksilöllisesti.
OrderDetails-taulukon OrderID- ja productID-sarakkeita käytetään viitaamaan tilaukset ja tuotteet -taulukoihin. Siksi ne ovat myös vieraita avaimia OrderDetails-taulukossa.

Yksi kerrallaan
Tuotteiden myynti-tietokannassa tuotteella voi olla valinnaisia tietoja, kuten lisäkuvaus ja sen kuva. Pitämällä sitä Products-taulukon sisällä, syntyy paljon tyhjiä tiloja.
Siksi voidaan luoda toinen taulukko (ProductExtras) valinnaisten tietojen tallentamiseksi. Vain yksi tietue luodaan tuotteille, joissa on valinnainen tieto.
Kahdessa taulukossa, Tuotteet ja ProductExtras, on yksi-yksi-suhde. Jokaisella Tuotetta-taulukon rivillä on korkeintaan yksi rivi ProductExtras-taulukossa. Samaa tuotetunnusta on käytettävä ensisijaisena avaimena molemmille taulukoille.

Etu
Rakenteellinen riippumattomuus
Suhteellisessa tietokantamallissa tietokannan rakenteen muutokset eivät vaikuta tiedon saatavuuteen.
Kun on mahdollista tehdä muutoksia tietokannan rakenteeseen vaikuttamatta DBMS: n kykyyn käyttää tietoja, voidaan sanoa, että rakenteellinen riippumattomuus on saavutettu.
Käsitteellinen yksinkertaisuus
Relaatiotietokantamalli on jopa käsitteellisesti yksinkertaisempi kuin hierarkkinen tai verkkotietokantamalli.
Koska relaatiotietokantamalli vapauttaa suunnittelijan tietojen fyysisen tallentamisen yksityiskohdista, suunnittelijat voivat keskittyä tietokannan loogiseen näkymään.
Helppo suunnittelu, toteutus, ylläpito ja käyttö
Relaatiotietokantamallilla saavutetaan sekä tiedon riippumattomuus että rakenteen riippumattomuus, mikä tekee tietokannan suunnittelusta, ylläpidosta, hallinnasta ja käytöstä paljon helpompaa kuin muut mallit.
Ad-hoc-kyselykapasiteetti
Erittäin voimakkaan, joustavan ja helppokäyttöisen kyselyominaisuuden läsnäolo on yksi tärkeimmistä syistä relaatiotietokantamallin valtavaan suosioon.
Relaatiotietokantamallin kyselykieli, jota kutsutaan rakenteelliseksi kyselykieleksi (SQL), tekee ad-hoc-kyselyistä todellisuuden. SQL on neljännen sukupolven kieli (4GL).
4GL antaa käyttäjän määrittää, mitä pitäisi tehdä, määrittelemättä miten se tulisi tehdä. SQL: n avulla käyttäjät voivat siis määritellä haluamansa tiedot ja jättää yksityiskohdat tietojen saamiseksi tietokantaan.
haitat
Laitteiden kulut
Relaatiotietokantamalli piilottaa sen toteutuksen monimutkaisuudet ja käyttäjätietojen fyysisen tallentamisen yksityiskohdat.
Tätä varten relaatiotietokantajärjestelmät tarvitsevat tietokoneita, joissa on tehokkaammat laitteistot ja tiedontallennuslaitteet.
Siksi RDBMS tarvitsee tehokkaita koneita toimimaan sujuvasti. Koska nykyaikaisten tietokoneiden prosessointiteho kasvaa eksponentiaalisella nopeudella, lisää prosessointitehon tarve nykypäivän tilanteessa ei ole enää kovin suuri ongelma.
Suunnittelu helppous voi johtaa huonoon suunnitteluun
Relaatiotietokanta on helppo suunnitella ja käyttää. Käyttäjien ei tarvitse tietää monimutkaisia tietoja tietojen fyysisestä varastoinnista. Heidän ei tarvitse tietää, kuinka tiedot todella tallennetaan voidakseen käyttää niitä.
Suunnittelun ja käytön helppous voi johtaa huonosti suunniteltujen tietokannan hallintajärjestelmien kehittämiseen ja toteuttamiseen. Koska tietokanta on tehokas, nämä suunnittelun tehottomuudet eivät ilmene, kun tietokanta on suunniteltu ja kun tietoja on vain vähän.
Tietokannan kasvaessa huonosti suunnitellut tietokannat hidastavat järjestelmää ja johtavat suorituskyvyn heikkenemiseen ja tietojen vioittumiseen.
«Tietosaarten» ilmiö
Kuten aiemmin mainittiin, relaatiotietokantajärjestelmät ovat helppo toteuttaa ja käyttää. Tämä luo tilanteen, jossa liian monet ihmiset tai yksiköt luovat omia tietokantojaan ja sovelluksiaan.
Nämä tietosaaret estävät tiedon integroinnin, mikä on välttämätöntä organisaation sujuvalle ja tehokkaalle toiminnalle.
Nämä yksittäiset tietokannat luovat myös ongelmia, kuten tietojen epäjohdonmukaisuus, tietojen päällekkäisyys, tietojen redundanssi jne.
esimerkki
Oletetaan, että Tietokanta koostuu Toimittaja-, osat- ja lähetystaulukoista. Taulukoiden ja joidenkin näyterekisterien rakenne on seuraava:

Jokainen toimittajataulukon rivi tunnistetaan yksilöivällä toimittajan numerolla (SNo), joka yksilöi taulukon jokaisen rivin yksilöllisesti. Samoin jokaisella osalla on yksilöllinen osanumero (PNo).
Lisäksi kuljetuksia koskevassa taulukossa voi olla vain yksi lähetys tietylle toimittaja / osa -yhdistelmälle, koska tämä yhdistelmä on lähetysten ensisijainen avain, joka toimii liitotaulukkona, koska se on monien välinen suhde.
Osa- ja lähetystaulukoiden välinen suhde saadaan siten, että kentällä PNo (osanumero) on yhteinen, ja toimittajien ja lähetysten välinen suhde syntyy, kun SNo-kentällä (toimittajan numero) on yhteinen.
Lähetystaulukkoa analysoitaessa voidaan saada tietoa siitä, että Suneetilta ja Ankitilta toimittajilta lähetetään yhteensä 500 pähkinää, 250 kpl.
Samoin toimitettiin kolmelta eri toimittajalta yhteensä 1 100 pulttia. Suneet-toimittajalta lähetettiin 500 sinistä ruuvia. Punaisia ruuveja ei ole lähetetty.
Viitteet
- Wikipedia, ilmainen tietosanakirja (2019). Suhteellinen malli. Kuvannut: en.wikipedia.org.
- Techopedia (2019). Suhteellinen malli. Kuvannut: roofpedia.com.
- Dinesh Thakur (2019). Suhteellinen malli. Tietokoneen muistiinpanot. Otettu: ecomputernotes.com.
- Geekit Geekeille (2019). Suhteellinen malli. Ostettu: geeksforgeeks.org.
- Nanyangin teknillinen yliopisto (2019). Pikakäynnistysohjelma relaatiotietokannan suunnitteluun. Otettu: ntu.edu.sg.
- Adrienne Watt (2019). Luku 7 relaatiotietojen malli. BC Avaa oppikirjat. Otettu: opentextbc.ca.
- Toppr (2019). Relaatiotietokannat ja kaaviot. Otettu: toppr.com.
