Mikä on relaatioskeema? Miten luodaan tehokas tietokanta?
Ei ole olemassa mitään yksittäistä tietokantarakennetta, joka olisi aina tehokkaampi kuin mikään muu. Tämä johtuu siitä, että tallennetun tiedon tyyppi ja määrä muuttavat tietokannan optimaalista rakennetta.
On kuitenkin suuri ero suorituskyvyn kannalta optimoidun tietokannan rakentamisen ja tietomäärän kannalta optimoidun tietokannan rakentamisen välillä.
Myös MySQL:n relaatiokaaviota käyttämällä voit luoda tietokannan, joka on optimoitu tietomäärän kannalta. Tämä on ihanteellista tilanteissa, joissa tallennus-, käsittely- ja muistikustannukset ovat kohtuuttoman kalliita.
Vaikka tämä ei enää koske vakioelektroniikkaa, on edelleen paljon tilanteita, joissa ohjelmoijat ja kehittäjät haluaisivat käyttää relaatiokaaviota. Vaikka tallennustila, prosessointiteho ja muisti ovat edullisia tavanomaisten tietokoneiden käyttäjille, nämä asiat ovat massiivisen kalliita kvanttilaskennan maailmassa.
Myös relaatiokaavio on tärkeä MySQL-tietokannoissa, jotka luottavat suhteisiin merkityksen luomisessa. Esimerkiksi työntekijä- ja opintorekisterit voidaan helposti ajatella suhteiden verkostoina, jotka on helpompi kuvata relaatiokaavion avulla kuin esimerkiksi avainarvo- tai graafitietokantojen avulla.
Relaatiokaavio on relaatiotietokannan ensisijainen elementti. Näitä tietokantoja hallitaan käyttämällä kieltä ja rakennetta, joka on johdonmukainen ensimmäisen järjestyksen logiikan kanssa. Tämä mahdollistaa tietokantojen hallinnan entiteettisuhteisiin perustuen, jolloin niitä on helppo järjestää volyymin mukaan.
Relaatiokaavio tarkoittaa metatietoa, joka kuvaa tietojen rakennetta tietyllä toimialueella. Se on tietokannan pohjapiirros, jossa hahmotellaan, miten sen rakenne järjestää tiedot taulukoihin.
Jos tietokantasi sisältää esimerkiksi suuren yrityksen työntekijätietueita, sinulla saattaa olla entiteettisuhteita, jotka kuvaavat jokaisen työntekijän vahvana entiteettinä esimerkiksi näin:
- Työntekijän nimi
- ID-numero
- osoite
- Työntekijän ammattitaito
- Palkkauksen päivämäärä
- Palvelusvuodet
Tässä esimerkissä sinulla olisi kaksi relaationaalisen skeematiedon attribuuttia. Ensinnäkin sinulla olisi Employee-attribuutti, joka on taulukon ensisijainen avain (koska kaikki liittyy työntekijään), ja Address-attribuutti, joka on eri elementeistä koostuva yhdistelmäattribuutti.
Atressi-attribuutti koostuisi seuraavista arvoista:
- Kaupunki
- Katu
- Adressinumero
- Suuntanumero
- Suuntanumero
Tämän tiedostaessasi olet valmis kartoittamaan entiteettisuhdekaavion relationaarista relaatiokaaviota. Sen pitäisi näyttää tältä:
- Työntekijä (Nimi, ID-numero, Osoitenumero, Katu, Kaupunki, Postinumero, Palkkaamispäivämäärä)
- Työntekijän ammattitaito (ID-numero, Ammattitaito)
Huomaa, että palvelusvuodet on jätetty pois tästä luettelosta. Tämä johtuu siitä, että se on johdettu ominaisuus, joka voidaan laskea vähentämällä palkkaamispäivä nykyisestä päivämäärästä. Syy siihen, että Employee Skillset on oma skeemansa, on se, että se on moniarvoinen attribuutti.
Relaatioskeemassa jokaisesta oliotyypistä tulee oma taulukkonsa, ja jokainen yksiarvoinen attribuutti on sarake kyseisessä taulukossa. Johdetut attribuutit voidaan huoletta jättää huomiotta, kun taas moniarvoisista attribuuteista tulee erillisiä taulukoita.
Menetelmä heikkojen entiteettityyppien muuntamiseksi relaatiokaavioon on samankaltainen kuin edellä kuvattu prosessi, paitsi että heikoista entiteettityypeistä tulee omia taulukoitaan, ja vahvan entiteetin ensiöavain toimii vieraana avaimena kyseisessä taulukossa.
Tämähän tarkoittaa sitä, että vahvalle entiteetille Työntekijä (Employee) loisit yhdistetyn ensiöavaimen, joka koostuisi vieraasta avaimesta Riippuvainen (Dependent) ja heikon entiteetin avaimesta. Tällöin skeema näyttäisi seuraavalta:
- Työntekijä (Nimi, ID-numero, Osoitenumero, Katu, Kaupunki, Postinumero, Palkkaamispäivä)
- Riippuvainen (Työntekijä, Riippuvainen ID, Nimi, Osoite)
Tässä korrelaatio on Employee-taulussa olevan ID-numeron ja riippuvainen-taulussa olevan Työntekijä-alkioelementin välissä.”
Tämän työn tehtyäsi olet valmis aloittamaan suhteiden muuntamisen. Tämä edellyttää kunkin suhteen kardinaalisuuden ja asteen ymmärtämistä.
- On kolme mahdollista kardinaalisuutta – 1:1, 1:M, 1:N
- On kolme mahdollista astetta – yksikäsitteinen, kaksikäsitteinen ja kolmikäsitteinen.
Eläsiteltyä esimerkkiä jatkamalla Employee-taulukon ja uuden Department-taulukon välille voitaisiin muodostaa kaksikäsitteinen 1:1-suhde. Jos työntekijä johtaa tiettyä osastoa, häntä voidaan kuvata osittaisena osallistujana, kun taas osastoa kuvattaisiin kokonaisosallistujana.
Relaatiokaavio näyttäisi seuraavalta:
- Työntekijä (Nimi, ID-numero, Osoitenumero, Katu, Kaupunki, Postinumero, Palvelukseenottopäivämäärä)
- Osasto (Johtajan ID-numero, Osaston ID-numero, Nimi, Osoite)
Tässä tapauksessa osittaisen osallistujan ensisijaisesta avaimesta tulee kokonaisosallistujan vierasavain. Johtajan ID-numero korreloi sopivan työntekijän ID-numeron kanssa.
Tässä esitellään tärkeä osa relaatiokaavion luomista. Binäärisen 1:1-suhteen jommankumman osallistujan ensisijaisesta avaimesta voi tulla toisen osallistujan vieras avain. Toinen tapa kuvata yllä olevaa suhdetta olisi käyttää vieraana avaimena Employee-kohdassa Manages, joka korreloi ensisijaisen avaimen Department ID kanssa Department-kohdassa Department.
Esimerkki binäärisestä 1:N-suhteesta olisi opettajan, joka opettaa oppiainetta, välinen suhde. Tietyssä luokkahuoneessa opettajat voivat opettaa useampaa kuin yhtä oppiainetta erilaisille oppilaille, mutta kaikilla oppiaineilla on kuitenkin sama suhde opettajaan.
Yllä olevassa binäärisessä 1:1-suhteessa jokaisella osastolla oli yksilöllinen johtaja. Tässä binäärisessä 1:N-suhteessa vaihteleva määrä opiskelijoita voi jakaa saman opettajan. Opettajan ensisijainen avain olisi opettajan tunnus, joka korreloisi opettajan alla olevan oppiaineen vieraan avaimen kanssa.
Kuvaamaan binääristä M:N-suhdetta kuvitellaan, että opiskelija ilmoittautuu kurssille. Luo uusi taulukko, joka kuvaa Opiskelijaa, ja toinen, joka kuvaa Kurssia. Molemmat taulut liittyvät toisiinsa ilmoittautumisen kautta, ja molemmilla on vierasavaimet.
- Opiskelijan vierasavain on Opiskelijan tunnus.
- Kurssin vierasavain on Kurssin tunnus.
Uuden taulun ensisijainen avain on kummankin entiteetin vierasavaimien yhdistelmä. Kuvaisit sen seuraavasti: (Opiskelijan tunnus, kurssin tunnus). Tämä on yksilöllinen binäärinen M:N-relaatiokaavio, joka yhdistää yksittäiset opiskelijat kursseihin.
Tämä toimii, koska tunnukset luodaan luonteensa vuoksi vierasavaimiksi relaatiotietokannoissa.
Voit käyttää relaatiokaaviota kuvaamaan itseensä viittaavia suhteita. Esimerkiksi kahdella työntekijällä, jotka ovat naimisissa keskenään, voisi olla vierasavain Spouse. Molempien näiden työntekijöiden vierasavaimissa viitataan toisen työntekijän työntekijätunnukseen, joka on kunkin työntekijän vastaavan taulun ensisijainen avain.
Tämä toimii myös relaatioskeemassa, jonka kardinaliteetti on 1:N. Primääriavain-kentästä itsestään tulisi tässä tapauksessa saman taulun vierasavain. Tämä on sama kuin unaarinen 1:1-suhdeskeema.
Esimerkiksi työntekijällä, joka on alaisensa esimies, voi olla vieraana avaimena esimies. Tässä tapauksessa Työntekijän tunnus olisi saman taulukon ensisijainen avain.
M:N-suhteen itseviittaus vaatii kaksi taulukkoa. Toisen on edustettava kyseistä entiteettiä ja toisen on edustettava M:N-suhdetta.
Kuvittele työntekijä, joka on vastuussa tietyn tuotteen tai palvelun laadun takaamisesta. Tähän suhteeseen olisi sisällytettävä sekä takaaja että edunsaaja vieraina avaimina, jotka yhdistyvät korreloimaan työntekijä-taulun työntekijätunnuksen kanssa. Sekä Guarantor että Beneficiary toimisivat primääri- ja vierasavaimina äskettäin luodussa relaatiokaavio-taulussa.
Vaikka binääriset ja unaariset suhteet on helppo kuvata käyttämällä relaatiokaaviota, jossa on yksi tai kaksi taulua. Ternaariset taulukot vaativat kolmannen, uuden taulukon.
Tämän uuden taulukon ensisijainen avain koostuu jokaisen osallistuvan entiteetin vieraasta avaimesta, jotka on laskettu yhteen. Tämä tarkoittaa, että uudessa taulussa on oltava kolme vierasta avainta, joihin korreloida.
Esimerkiksi lääkärin ja hänen potilaansa välinen suhde koostuu itse asiassa kolmesta entiteetistä: Lääkäri, potilas ja lääke. Jotta tätä suhdetta voidaan kuvata oikein relaatioskeemana, jokaiselle näistä entiteeteistä on määritettävä vierasavain ja korreloitava ne uuteen tauluun nimeltä Lääkemääräys.
Tämä on yksinkertainen tapa havainnollistaa ternäärisen taulukon toimintatapa. Äskettäin luodun Prescription-taulun ensisijainen avain on (Lääkärin tunnus, Potilaan tunnus, Lääkkeen tunnus). Kaikista skeemoista, jotka eivät sisällä näitä kolmea tärkeää tietoa, puuttuu tärkeä osa palapelistä.
Tämän lähestymistavan avulla tietokannan ylläpitäjä voisi luoda järjestäytyneen arkiston lääkemääräyksistä, jossa otetaan huomioon tietyt lääketyypit, jotka korreloivat välittömästi niitä käyttävien potilaiden nimiin ja tarjoavat lääkkeet määränneiden lääkäreiden nimet.
Täydellisyyden vuoksi voit halutessasi lisätä lääketiedostotaulukkoon viimeisen voimassaolopäivämäärän (expiration date), niin, että tämä tieto on saatavissa pääruudussa. Voit lisätä Lääkemääräys-taulukkoon seuraavan tapaamisen tai täydennyspäivämäärän päivämäärän. Potilas-tauluun haluaisit loogisesti lisätä syntymäpäivän, osoitteen ja muita tärkeitä relaatiotietoja.
Kaikki nämä työkalut yhdessä mahdollistavat suhdekeskeisten tietokantojen luomisen MySQL:ssä. Voit harjoitella omien MySQL-tietokantojen tekemistä verkossa millä tahansa selaimella SQLDBM:n avulla.