Ключовете за база данни са най-лесният начин за създаване на ефективна релационна база данни
Както може би вече знаете, базите данни използват таблици за организиране на информация. (Ако нямате основно познаване на понятията за бази данни, прочетете Какво представлява база данни? ) Всяка таблица се състои от няколко реда, всеки от които съответства на един запис на база данни. И така, как базите данни държат всички тези документи прави? Това е чрез използването на ключове.
Основни клавиши
Първият тип ключ, който ще обсъдим, е първичният ключ . Всяка таблица на база данни трябва да има една или повече колони, определени като първичен ключ . Стойността, която този ключ съдържа, трябва да бъде уникална за всеки запис в базата данни.
Да приемем например, че имаме таблица, наречена "Служители", която съдържа информация за всеки служител в нашата фирма. Трябва да изберем подходящ първичен ключ, който да идентифицира уникално всеки служител. Първата ви мисъл може да е да използвате името на служителя. Това не би било добре, защото е възможно да наемете двама служители със същото име. По-добър избор е да използвате уникален идентификационен номер на служител, който сте назначавали на всеки служител, когато са наети. Някои организации избират да използват номера за социална сигурност (или подобни идентификатори на правителството) за тази задача, тъй като всеки служител вече има такъв и те са гарантирани, че са уникални. Използването на номера за социална сигурност за тази цел обаче е много противоречиво поради опасения, свързани с поверителността. (Ако работите за правителствена организация, използването на номер за социална осигуровка може дори да е незаконно съгласно Закона за защита на личните данни от 1974 г.). Поради тази причина повечето организации са се преместили към използването на уникални идентификатори (идентификационен номер на служител, идентификационен номер на студент и т.н. .), които не споделят тези притеснения за поверителността.
След като вземете решение за основния ключ и настроите базата данни, системата за управление на базата данни ще утвърди уникалността на ключа.
Ако се опитате да вмъкнете запис в таблица с първичен ключ, който дублира съществуващ запис, вмъкването ще се провали.
Повечето бази данни също могат да генерират собствени първични ключове. Microsoft Access например може да бъде конфигуриран да използва типа данни AutoNumber, за да присвои уникален идентификатор за всеки запис в таблицата. Макар и ефективна, това е лоша практика, защото ви дава безсмислена стойност във всеки запис в таблицата. Защо да не използваме това пространство, за да съхраним нещо полезно?
Чужди ключове
Другият тип е чужд ключ , който се използва за създаване на връзки между таблици. Естествените взаимоотношения съществуват между таблиците в повечето структури на бази данни. Връщайки се към базата данни на служителите си, си представете, че искаме да добавим към базата данни таблица, съдържаща информация за отдела. Тази нова таблица може да бъде наречена "Отделения" и да съдържа голямо количество информация за отдела като цяло. Също така бихме искали да включим информация за служителите в отдела, но би било излишно да има една и съща информация в две таблици (Служители и отдели). Вместо това можем да създадем връзка между двете таблици.
Да приемем, че таблицата "Департаменти" използва колоната "Име на отдел" като първичен ключ. За да създадем връзка между двете таблици, добавяме нова колона към таблицата "Служители", наречена "Отдел". След това попълваме името на отдела, към който принадлежи всеки служител. Ние също така информираме системата за управление на базата данни, че колоната на Отдел в таблицата "Служители" е чужд ключ, който препраща към таблицата "Департаменти".
Тогава базата данни ще наложи референтна цялост, като се увери, че всички стойности в колоната "Департаменти" на таблицата "Служители" имат съответните записи в таблицата "Департаменти".
Обърнете внимание, че няма ограничения за уникалност за чужд ключ. Можем (и най-вероятно имаме) да имаме повече от един служител, който принадлежи към отделен отдел. По същия начин няма изискване записът в таблицата "Департаменти" да има съответстващо вписване в таблицата "Служители". Възможно е да имаме отделение без служители.
За повече информация по тази тема прочетете Създаване на чужди ключове .