ключы базы дадзеных з'яўляюцца самым простым спосабам, каб стварыць эфектыўную рэляцыйную базу дадзеных
Як вы ўжо ведаеце, базы дадзеных выкарыстаюць табліцы для арганізацыі інфармацыі. (Калі вы не маеце базавую знаёмства з асноўнымі паняццямі баз дадзеных, прачытаць Што такое база дадзеных? ) Кожная табліца складаецца з некалькіх радкоў, кожная з якіх адпавядае адной запісы базы дадзеных. Такім чынам, як базы дадзеных захаваць усе гэтыя запісы прама? Гэта за кошт выкарыстання ключоў.
першасныя ключы
Першы тып ключа мы абмяркуем гэта першасны ключ . Кожная табліца базы дадзеных павінна мець адзін або некалькі слупкоў , прызначаныя ў якасці першаснага ключа . Значэнне гэтай клавішы трумы павінна быць унікальным для кожнага запісу ў базе дадзеных.
Напрыклад, выкажам здагадку, што ў нас ёсць табліца пад назвай Супрацоўнікі, якая ўтрымлівае інфармацыю персаналу для кожнага супрацоўніка нашай фірмы. Нам бы трэба выбраць адпаведны першасны ключ, які б адназначна ідэнтыфікаваць кожны супрацоўнік. Ваша першая думка можа быць выкарыстоўваць імя супрацоўніка. Гэта не будзе працаваць вельмі добра, таму што гэта магчыма, што вы б наняць двух супрацоўнікаў з тым жа імем. Лепшы выбар можа быць выкарыстоўваць унікальны работнік ідэнтыфікацыйнага нумара, прысвойваныя кожнаму супрацоўніку, калі яны нанялі. Некаторыя арганізацыі аддаюць перавагу выкарыстоўваць нумары сацыяльнага забеспячэння (або аналагічныя дзяржаўныя ідэнтыфікатары) для выканання гэтай задачы, паколькі кожны супрацоўнік ужо мае адзін, і яны гарантавана быць унікальнымі. Аднак, выкарыстанне нумара сацыяльнага забеспячэння для гэтай мэты з'яўляецца вельмі спрэчным з-за меркаванні прыватнасці. (Калі вы працуеце ў дзяржаўнай арганізацыі, выкарыстанне нумара сацыяльнага страхавання можа быць нават незаконнымі ў адпаведнасці з Законам аб канфiдэнцыяльнасцi 1974 г.) Па гэтай прычыне, большасць арганізацый перайшлі на выкарыстанне унікальных ідэнтыфікатараў (ID супрацоўніка, студэнцкі білет і г.д. .), якія не падзяляюць гэтыя пытанні прыватнасці.
Пасля таго, як вы вырашыцеся на першасны ключ і наладзіць базу дадзеных, сістэма кіравання базамі дадзеных будзе забяспечваць унікальнасць ключа.
Пры спробе ўставіць запіс у табліцу з першасным ключом, які дублюе існуючую запіс, устаўка пацерпіць няўдачу.
Большасць баз дадзеных таксама здольныя генерыраваць свае ўласныя першасныя ключы. Microsoft Access, напрыклад, можа быць выканана з магчымасцю выкарыстоўваць тып дадзеных AutoNumber надаць унікальны ідэнтыфікатар для кожнага запісу ў табліцы. Эфектыўны, хоць гэта дрэнная практыка дызайну, таму што яна пакідае вас з бессэнсоўным значэннем у кожнай запісу ў табліцы. Чаму б не выкарыстоўваць гэта прастора для захоўвання нешта карыснае?
знешнія ключы
Іншы тып з'яўляецца знешніх ключом , які выкарыстоўваецца для стварэння сувязяў паміж табліцамі. Прыродныя адносіны існуюць паміж табліцамі ў большасці структур баз дадзеных. Вяртаючыся да нашай базе дадзеных супрацоўнікаў, уявіце сабе, што мы хацелі дадаць табліцу, якая змяшчае ведамасную інфармацыю ў базу дадзеных. Гэтая новая табліца можа называцца Факультэты і будзе ўтрымліваць вялікая колькасць інфармацыі аб кафедры ў цэлым. Мы таксама хочам, каб уключыць інфармацыю пра супрацоўнікаў у аддзеле, але гэта было б залішнім мець тую ж інфармацыю ў двух табліцах (супрацоўнікі і падраздзялення). Замест гэтага мы можам стварыць сувязь паміж двума табліцамі.
Выкажам здагадку, што табліца Аддзелы выкарыстоўваецца слупок Імя аддзела ў якасці першаснага ключа. Для таго, каб стварыць сувязь паміж двума табліцамі, мы дадамо новы слупок ў табліцу супрацоўнікаў пад назвай Дэпартамент. Затым увядзіце імя аддзела, якому належыць кожнаму супрацоўніку. Мы таксама інфармаваць сістэму кіравання базамі дадзеных , што калонка Дэпартамент ў табліцы супрацоўнікаў з'яўляецца знешніх ключом , які спасылаецца на табліцу аддзелаў.
База дадзеных будзе забяспечваць спасылачныя цэласнасць , гарантуючы , што ўсе значэння ў слупку Аддзелы табліцы Супрацоўнікі маюць адпаведныя запісы ў табліцы аддзелаў.
Звярніце ўвагу , што не існуе абмежаванне унікальнасці для вонкавага ключа. Мы можам (і найбольш верагодна) маюць больш аднаго супрацоўніка, які належыць да аднаго аддзела. Аналагічным чынам, няма ніякіх патрабаванняў аб тым, што запіс у табліцы аддзелаў мае любую адпаведную запіс у табліцы супрацоўнікаў. Цалкам магчыма, што мы б аддзел без якіх-небудзь супрацоўнікаў.
Больш падрабязная інфармацыя па гэтай тэме, прачытайце Стварэнне знешніх ключоў .