Базите на клучеви се најлесниот начин да се создаде ефикасна релациона база на податоци
Како што веќе знаете, бази на податоци користат табели за организирање на информации. (Ако немате основно познавање на концептите на базата на податоци, прочитајте Што е база на податоци? ) Секоја табела се состои од неколку редови, од кои секоја одговара на единствена база на податоци. Значи, како базите на податоци ги одржуваат сите овие податоци во ред? Тоа е преку употреба на клучеви.
Примарни клучеви
Првиот тип на клуч за кој ќе разговараме е примарен клуч . Секоја табела на база на податоци треба да има една или повеќе колони назначени како примарен клуч . Вредноста на овој клуч треба да биде единствена за секој запис во базата на податоци.
На пример, претпоставиме дека имаме табела наречена Вработени која содржи информации за персоналот за секој вработен во нашата фирма. Ние би требало да избереме соодветен примарен клуч кој уникатно ќе го идентификува секој вработен. Вашата прва мисла може да биде да го користите името на вработениот. Ова нема да функционира многу добро затоа што е можно да ангажирате двајца вработени со исто име. Подобар избор може да биде да користите уникатен идентификациски број за вработените што го назначувате на секој вработен кога тие се ангажирани. Некои организации избираат да користат броеви за социјално осигурување (или слични владини идентификатори) за оваа задача, бидејќи секој вработен веќе има еден и тие се загарантирани да бидат уникатни. Сепак, употребата на броеви за социјално осигурување за оваа намена е многу контроверзна поради загриженоста за приватноста. (Ако работите за владина организација, користењето на број за социјално осигурување може дури да биде илегално според Законот за приватност од 1974 година.) Поради оваа причина, повеќето организации се префрлиле на користење на единствени идентификатори (идентификатор на вработениот, идентификација на ученикот, итн. .) кои не ги делат овие загрижености за приватноста.
Откако ќе одлучите за примарниот клуч и поставите база на податоци, системот за управување со бази на податоци ќе ја наметне единственоста на клучот.
Ако се обидете да внесете запис во табела со примарен клуч кој дуплира постоечки запис, вметнувањето ќе пропадне.
Повеќето бази на податоци исто така можат да генерираат свои примарни клучеви. На пример, Мајкрософт пристап, може да биде конфигуриран да го користи типот на податок AutoNumber за да додели уникатен проект за секој запис во табелата. Додека е ефикасен, ова е лоша пракса за дизајн, бидејќи ви остава без значење вредност во секој запис во табелата. Зошто да не го искористите тој простор за да зачувате нешто корисно?
Странски клучеви
Друг тип е странскиот клуч , кој се користи за создавање врски помеѓу табелите. Природни односи постојат помеѓу табели во повеќето структури на бази на податоци. Враќајќи се во базата на податоци на вработените, замислете дека сакавме да додадеме табела која содржи одделенски информации во базата на податоци. Оваа нова табела може да се нарече одделенија и би содржи многу информации за одделот како целина. Ние, исто така, би сакале да вклучиме информации за вработените во одделот, но би било излишно да ги има истите информации во две табели (вработени и одделенија). Наместо тоа, можеме да создадеме врска меѓу двете маси.
Да претпоставиме дека табелата Оддели ја користи колоната Име на одделот како примарен клуч. За да создадеме врска помеѓу двете табели, додаваме нова колона во табелата "Вработени" наречена Оддел. Потоа го пополнуваме името на одделот на кој му припаѓа секој вработен. Ние, исто така, го информираме системот за управување со бази на податоци дека колоната на Одделот во табелата "Вработени" е странски клуч кој се однесува на табелата "Оддели".
Базата на податоци потоа ќе спроведе референцијален интегритет, обезбедувајќи дека сите вредности во колоната "Оддели" од табелата "Вработени" имаат соодветни записи во табелата "Оддели".
Забележете дека не постои пречка за единственост за странски клуч. Можеме (и, најверојатно, имаме) повеќе од еден вработен кој припаѓа на еден оддел. Слично на тоа, нема потреба дека записот во табелата "Оддели" има соодветен запис во табелата "Вработени". Можно е да имаме оддел без вработени.
За повеќе информации за оваа тема, прочитајте Креирање странски клучеви .