Andmebaasi võtmed on lihtsaim viis tõhusa relatsioonandmebaasi loomiseks
Nagu te juba teate, kasutavad andmebaasid teabe salvestamiseks tabeleid. (Kui teil puudub põhiteadmisi andmebaasikontseptsioonide kohta, loe Mis on andmebaas? ) Iga tabel koosneb mitmest ristast, millest igaüks vastab ühe andmebaasi kirjele. Niisiis, kuidas andmebaasid hoiavad kõiki neid andmeid otse? See on võtmete abil.
Esmased võtmed
Esmane võti, mida arutame, on peamine võti . Igal andmebaasiserveril peaks olema üks või mitu veergu, mis on määratud primaarvõtmeks . Väärtus, mille see võti omab, peaks olema iga andmebaasi jaoks salvestatud puhul unikaalne.
Näiteks oletame, et meil on tabel nimega Töötajad, mis sisaldab meie firmas iga töötaja kohta personali teavet. Me peame valima sobiva primaarvõtme, mis oleksid iga töötaja jaoks üheselt identifitseerinud. Teie esimene mõte võib olla töötaja nime kasutamine. See ei tööta väga hästi, sest on mõeldav, et võtaksite tööle kahte sama nimega töötajat. Parem valik võiks olla kasutada unikaalset töötaja ID-numbrit, mille olete määranud iga töötaja kohta, kui nad on tööle võetud. Mõned organisatsioonid otsustavad selle ülesande jaoks kasutada sotsiaalkindlustusnumbreid (või sarnaseid valitsuse tunnuseid), sest igal töötajal on juba olemas ja nad on kindlasti unikaalsed. Siiski on sotsiaalkindlustuse numbrite kasutamine sellel eesmärgil eraelu puutumatuse tõttu väga vastuoluline. (Kui te töötate mõne valitsusorganisatsiooni juures, võib sotsiaalkindlustusnumber olla ka 1974. aasta privaatsuseaduse alusel ebaseaduslik.) Sel põhjusel on enamik organisatsioone kasutusele võtnud unikaalseid tunnuseid (töötaja ID, õpilase ID jne) .), kes ei jaga neid privaatsuse probleeme.
Kui otsustate primaarvõtme kasutamise ja andmebaasi seadistamise, täidab andmebaasi haldussüsteem võti unikaalsust.
Kui proovite sisestada rekord esmase võtmega tabelisse, mis dubleerib olemasoleva rekordi, sisestamine ebaõnnestub.
Enamik andmebaasidest on samuti võimelised genereerima oma esmaseid võtmeid. Näiteks Microsoft Access võib olla konfigureeritud kasutama Andmetüübi AutoNumber, et määrata igale tabelis olevale rekordile unikaalne ID. Ehkki see on tõhus, on see halb disaini tava, sest see jätab sulle igas tabelis oleva rekordi mõttetu väärtuse. Miks mitte kasutada seda ruumi midagi kasulikku salvestamiseks?
Võõrkeeled
Teine tüüp on välisvõti , mida kasutatakse tabelite vaheliste suhete loomiseks. Enamus andmebaasi struktuuridest tabelite vahel on loomulikud suhted. Kui soovite oma töötajate andmebaasi tagasi pöörduda, kujutan ette, et tahtisime lisada andmebaasi andmebaasi sisaldava tabeli. Seda uut tabelit võib nimetada osakondadeks ja see sisaldab ka palju osakonda kui tervikut. Me tahaksime lisada ka teavet osakonna töötajate kohta, kuid oleks kahtlemata sama teavet kahes tabelis (töötajad ja osakonnad). Selle asemel saame luua kahe tabeli vahelise suhte.
Oletame, et departemangu tabel kasutab esmase võtmena veeru osakonna nimi. Kahe tabeli vahelise suhte loomiseks lisame uue tabeli töötajate tabeli nimega Department. Seejärel sisestage selle osakonna nimi, kuhu iga töötaja kuulub. Samuti teavitame andmebaasi haldussüsteemi sellest, et osakonna veerus töötajate tabelis on väliste võti, mis viitab osakondade tabelile.
Seejärel tagab andmebaas viitava terviklikkuse tagamise, tagades, et kõigi töötajate tabeli veeruosakondades olevatel väärtustel on vastavad kirjeid osakondade tabelis.
Pange tähele, et välisvõti pole ainulaadne piirang . Me võime (ja tõenäoliselt seda teha) on rohkem kui üks töötaja, kes kuulub ühte osakonda. Samamoodi ei ole nõue, et osakonna lahtris oleval kirjal oleks vastav kirje töötajate tabelis. On võimalik, et meil oleks töötajaid mitteosalev osakond.
Selle teema kohta lisateabe saamiseks lugege Võtme loomine .