Статті Ключ або відмичка
Будь-які міркування щодо переваг чи недоліків тих чи інших ключів повинні спиратися на вимоги предметної області та ті обмеження, які вона накладає. Порівняння ключів повинні в першу чергу відбуватися в площині повної/неповної відповідності схеми бази даних предметної області, простоти або складності досягнення цієї відповідності, вимоги запровадження додаткових механізмів, що забезпечують дану відповідність. Якщо дві схеми бази даних мають різний ступінь відповідності предметної області, то порівняння будь-яких інших характеристик не буде коректним.
Схема бази даних створюється з урахуванням інфологічної моделі – формального описи предметної області. Як і будь-яка інша модель, інфологічна модель відкидає ті атрибути сутностей, які відіграють у ній значної ролі. Наприклад, при прийомі на роботу нового службовця нас може не цікавити його зростання або колір волосся, і ці атрибути можуть бути відкинуті, тоді як рівень освіти або професійні навички можуть бути важливими. Може так вийти, що серед несуттєвих атрибутів виявляться й атрибути, які однозначно ідентифікують екземпляри цієї сутності. В результаті сутність, в рамках інфологічної моделі, може не мати атрибутів для формування ключа-кандидата. Однак реляційна модель вимагає, щоб кожен кортежбудь-якого відношення мав унікальний ідентифікатор.
На реалізації схеми бази даних можуть позначитися обмеження, властиві тій чи іншій реляційній СУБД. Наприклад, СУБД може накладати обмеження на розмір та/або кількість атрибутів, що входять у відношення або індекс; різні СУБД можуть підтримувати різні набори типів атрибутів тощо. Безсумнівно, ці особливості СУБД позначаться і схемою бази даних. Важливо й те, що різні реляційні СУБД по-своєму реалізують або не реалізують ті чи інші механізми, наприклад, підтримку перевірок, каскадні модифікації, тригера, збережені процедури і т.п. Через війну реалізація логіки взаємодії з даними, для конкретної предметної області, може значно різнитися в різних СУБД. Може навіть виявитися, що дотримуватися однієї стратегії вибору первинного ключа неможливо через складність механізмів підтримки логіки даних на конкретній СУБД. І, незважаючи на те, що сучасні реляційні СУБД мають досить розвинені механізми підтримки логіки даних, проте цих механізмів може виявитися недостатньо або їх реалізація та підтримка буде надто складною та дорогою.
Проектування реляційних баз даних включає стадію визначення функціональних залежностей між атрибутами кожної сутності. На цій стадії, зокрема, визначаються ключі-кандидати – такі набори атрибутів, які можуть бути унікальним ідентифікатором кожного екземпляра цієї сутності (кортежу відношення). Наприклад, серія та номер паспорта є унікальним ідентифікатором документа або, кажучи іншими словами, наведені атрибути визначають усі інші атрибути цього документа, такі як прізвище, ім'я, по батькові власника паспорта, місце та дату видачі документа тощо.
Знання функціональнихзалежностей необхідно для подальшого виконання процесу нормалізації, який є декомпозицією вихідних сутностей на підставі певних правил. Оскільки функціональні залежності існують об'єктивно, незалежно від наших знань предметної області, їх дослідження також об'єктивно необхідне побудови найбільш адекватної моделі предметної області як схеми бази даних.
Неадекватність відображення предметної області у вигляді схеми бази даних призводить до того, що інформація, що зберігається в базі даних, може бути неузгоджена з інформацією в реальному світі. Можна розглянути найпростіший приклад. Припустимо, що для ідентифікації відносини «Службовці» вибрано ключові атрибути паспорта: серію та номер. Тоді нам потрібно буде відповісти на запитання про те, що станеться, якщо службовець змінить паспорт або пред'явить інший документ, який допускається в цій ситуації законом? Якщо зміна паспорта вимагатиме зміни ключових атрибутів, то чи правильно були спочатку визначені сутності предметної області, їх атрибути та функціональні залежності? Припустимо, що раніше у платіжних документах зазначалася інформація, що відповідає атрибутам старого паспорта. Якщо ми змінимо значення атрибутів (серія та номер паспорта) на нові у всіх сутностях (таблицях бази даних), то очевидно, що документи, видані до зміни паспорта, будуть спотворені.
Спотворення пов'язані з тим, що інформація в документах, що зберігаються в базі даних, зміниться, дотримуючись вимог посилальної цілісності. Проте інформація у реальних документах збережеться у первісному вигляді. Тепер інформація в базі даних не буде відповідати реальній інформації. Не змінювати інформацію у пов'язаних сутностях теж неможливо, оскільки в цьому випадку відбудеться порушення посилальноїцілісності. Раніше видані документи посилатимуться на службовця, якого вже немає у базі даних.
Виходить замкнене коло: не можна змінити атрибути, оскільки вони раніше були використані в платіжних документах, а ці документи змінювати не можна, але, проте, змінити атрибути все ж таки треба, бо реальна зміна паспорта відбулася. У чому полягає помилка? У тому, що паспорт був ототожнений з його власником, а, як з'ясувалося, в одного службовця може бути більше одного паспорта. Таким чином, на етапі проектування не було враховано, що службовці та паспорти являють собою дві різні сутності, пов'язані ставленням одним-багатьом.
Наведений приклад показує, що інформаційна неповнота схеми бази даних, її відповідність предметної області може спричинити багато проблем, що виникають під час експлуатації. З повнотою схеми бази даних пов'язана проблема вибору ключів. Дискусія про переваги тих чи інших видів ключів ведеться вже не одне десятиліття, і вона втягнула на свою орбіту найвидатніших дослідників реляційної моделі.