Databasis sleutels is die maklikste manier om 'n doeltreffende relasionele databasis te skep
Soos u dalk reeds weet, gebruik databasisse tabelle om inligting te organiseer. (As jy nie basiese vertroudheid met databasiskonsepte het nie, lees Wat is 'n databasis? ) Elke tabel bestaan uit 'n aantal rye, wat elk ooreenstem met 'n enkele databasisrekord. So, hoe hou databasisse al hierdie rekords reguit? Dit is deur die gebruik van sleutels.
Primêre sleutels
Die eerste tipe sleutel wat ons sal bespreek, is die primêre sleutel . Elke databasis tabel moet een of meer kolomme hê wat as die primêre sleutel aangewys is . Die waarde wat hierdie sleutel bevat, moet uniek wees vir elke rekord in die databasis.
Stel byvoorbeeld dat ons 'n tafel het, naamlik Werknemers wat personeelinligting bevat vir elke werknemer in ons firma. Ons moet 'n toepaslike primêre sleutel kies wat elke werknemer uniek sal identifiseer. U eerste gedagte kan wees om die werknemer se naam te gebruik. Dit sal nie baie goed uitwerk nie, want dit is denkbaar dat u twee werknemers met dieselfde naam sal huur. 'N Beter keuse kan wees om 'n unieke werknemer ID nommer te gebruik wat u aan elke werknemer toewys wanneer hulle gehuur word. Sommige organisasies kies om sosiale sekerheidnommers (of soortgelyke regeringsidentifikators) vir hierdie taak te gebruik, want elke werknemer het reeds een en hulle is gewaarborg om uniek te wees. Die gebruik van sosiale sekerheidsnommers vir hierdie doel is egter baie omstrede as gevolg van privaatheidskwessies. (As jy vir 'n regeringsorganisasie werk, kan die gebruik van 'n sosiale sekerheidsnommer onwettig wees ingevolge die Wet op Privaatheid van 1974.) Om hierdie rede het die meeste organisasies verskuif na die gebruik van unieke identifiseerders (werknemer ID, student ID, ens. .) wat hierdie privaatheidskwessies nie deel nie.
Sodra jy besluit het oor 'n primêre sleutel en die databasis opstel, sal die databasisbestuurstelsel die uniekheid van die sleutel afdwing.
As u probeer om 'n rekord in 'n tabel in te voeg met 'n primêre sleutel wat 'n bestaande rekord dupliseer, sal die invoeging misluk.
Die meeste databasisse kan ook hul eie primêre sleutels genereer. Microsoft Access kan byvoorbeeld ingestel word om die data tipe AutoNumber te gebruik om 'n unieke ID toe te ken aan elke rekord in die tabel. Alhoewel dit effektief is, is dit 'n slegte ontwerppraktyk, want dit laat jou met 'n betekenislose waarde in elke rekord in die tabel. Hoekom gebruik nie daardie spasie om iets nuttigs te stoor nie?
Buitelandse sleutels
Die ander tipe is die vreemde sleutel wat gebruik word om verhoudings tussen tabelle te skep. Natuurlike verhoudings bestaan tussen tabelle in die meeste databasisstrukture. Terug na ons Werknemers databasis, stel voor dat ons 'n tabel met departementele inligting by die databasis wil byvoeg. Hierdie nuwe tabel kan Departemente genoem word en bevat 'n groot hoeveelheid inligting oor die departement as geheel. Ons wil ook inligting oor die werknemers in die departement insluit, maar dit sal oorbodig wees om dieselfde inligting in twee tabelle (Werknemers en Departemente) te hê. In plaas daarvan kan ons 'n verhouding tussen die twee tafels skep.
Kom ons neem aan dat die Departemente-tabel die Departement Naam-kolom as die primêre sleutel gebruik. Om 'n verhouding tussen die twee tabelle te skep, voeg ons 'n nuwe kolom by die Werknemerstafel genaamd Departement. Ons vul dan die naam van die departement waaraan elke werknemer behoort. Ons lig ook die databasisbestuurstelsel in kennis dat die Departementskolom in die Werknemerstafel 'n vreemde sleutel is wat die Departemente se tabel verwys.
Die databasis sal dan referensiële integriteit afdwing deur te verseker dat al die waardes in die Departemente-kolom van die Werknemers-tabel ooreenstemmende inskrywings in die Departemente-tabel bevat.
Let daarop dat daar geen uniekheidsbeperking vir 'n vreemde sleutel is nie. Ons mag (en heel waarskynlik) meer as een werknemer hê wat aan 'n enkele departement behoort. Net so is daar geen vereiste dat 'n inskrywing in die Departemente-tabel enige ooreenstemmende inskrywing in die Werknemers-tabel het nie. Dit is moontlik dat ons 'n departement sonder werknemers het.
Vir meer oor hierdie onderwerp, lees Creating Foreign Keys .