4. Первинні ключі

Ключі - це фундамент і цемент реляційної моделі. Первинний ключ унікальним образом ідентифікує кожний запис у таблиці. Наприклад, адреса електронної пошти - це первинний ключ, що унікальним образом ідентифікує кожного покупця; номер замовлення - це первинний ключ, що унікальним образом ідентифікує кожне замовлення. В ідеалі первинний ключ складається тільки з одного поля. Однак іноді для формування первинного ключа потрібно кілька полів. Наприклад, для вказівки місця розташування потрібні одночасно довгота й широта. В ER-діаграмі первинні ключі підкреслені й виділені жирним шрифтом.

Первинні ключі необхідно вибирати обережно. Кожний первинний ключ повинен задовольняти наступним вимогам:

• унікальність: значення первинного ключа унікальним образом ідентифікує кожний запис у таблиці. У США номер соціального страхування унікальним образом ідентифікує кожну людину. Автомобільні номери унікальним образом ідентифікують кожну машину;

• мінімальний розмір: якщо номер соціального страхування унікальний, то немає необхідності формувати первинний ключ із номера соціального страхування й дати народження. Аналогічно, марка й модель машини не потрібні для ідентифікації машини, якщо вже відомий її номер. Однак можливі обставини, коли для формування первинного ключа буде необхідно більш одного поля;

• ненульове значення, оскільки первинний ключ - це унікальний ідентифікатор, його значення не може залишатися порожнім. Кожний запис у таблиці повинна мати непустий первинний ключ;

• необновляємістъ: унікальний ідентифікатор повинен бути постійним увесь час. Номер соціального страхування не має терміну дії. Номера машини існують, поки існує машина. Однак телефонні номери міняються, якщо люди переїжджають. Тому телефонні номери не можуть бути ідеальним первинним ключем. Проте, у багатьох ситуаціях у бізнесі для зручності клієнтів необхідно використовувати обновлюваний первинний ключ. Наприклад, більшість сайтів електронних магазинів використовують як первинний ключ адреса електронної пошти, незважаючи на той факт, що особиста адреса електронної пошти може змінитися, коли людина міняє роботу або інтернет-провайдеру.

Існує неясність щодо унікальності й розміру первинного ключа. Чим більше полів включено в первинний ключ, тим більше шансів, що ключ буде унікальним. Однак розроблювач повинен знайти таке найменше число полів, які б формували унікальний ключ. На рис. 2.7 зображено кілька варіантів первинних ключів, які унікальні, але не мінімальні. На рис. 2.8 показаний правильний варіант первинного ключа, що і унікальний, і мінімальний.

На практиці пошук первинного ключа, що задовольняє всім перерахованим вище вимогам, може виявитися нелегкою справою. Ми розглянемо чотири розповсюджених сценарії вибору первинного ключа: використання існуючих полів, використання комп'ютера для генерування поля, створення зв'язаної таблиці й створення асоціативної таблиці.

Рис. 2.8 Адреса електронної пошти - це унікальний і мінімальний первинний ключ

Первинні ключі найчастіше формуються з одного або більш існуючих у таблиці полів. Приміром, номер соціального страхування може стати гарним первинним ключем для співробітників, номер машини може бути відмінним первинним ключем для автомобілів. Первинні ключі, що складаються з одного поля, більш кращі через свою простоту. Однак буває, що для формування первинного ключа потрібно більш одного поля, наприклад, широта й довгота спільно формують первинний ключ у топографії. До первинного ключа, сформованого з більш ніж одного поля, однаково звертаються як до окремого елемента. Первинний ключ, сформований з існуючих полів, зображений на мал. 2.9.

Рис. 2.9. Первинний ключ, сформований з існуючих полів

Рис. 2.10 Первинний

ключ, сгенероваий

комп'ютером

Створення зв'язків: зовнішні ключі

Батьківська таблиця відтворює свій первинний ключ у кожній дочірній таблиці, до якої вона підключена. Оскільки ці відтворені значення були створені поза дочірньою таблицею, вони називаються зовнішніми ключами. Зовнішні ключі зв'язують родинні записи між батьківською й дочірньою таблицею. Зовнішній ключ розміщається в дочірній таблиці (за «вороньєй лапкою»). Зовнішні ключі виділені на діаграмі жирним і позначаються в такий спосіб: ІМ'Я_БАТЬКІВСЬКОЇ_ТАБЛИЦІ$ім'я_батьківського_поля. (Флеминг і Ван Хол, 1988). Приміром, Клієнт$email - це зовнішній ключ, що вказує на поле електронної пошти email у таблиці Клієнт. Важливість зовнішнього ключа не можна недооцінювати. Зовнішні ключі - це лише спосіб подання зв'язків у реляційної базі даних. Система бази даних бачить тільки зовнішні ключі, а не сполучні лінії. Первинний і зовнішній ключі зображені на мал. 2.11.

Рис. 2.11 Зовнішні ключі відповідають за створення зв'язків

Залежна таблиця (також називана слабкою сутністю) - це дочірня таблиця, якій для ідентифікації необхідна батьківська таблиця. Приміром, на футболці гравця написаний як його номер, так і назва команди, наприклад 19 гравець команди Динамо. Номери унікальні тільки усередині команди, оскільки кожна команда використовує ті самі числа. На рис. 2.12 показані таблиці команди (Команда) і гравця (Гравець). Таблиця Команда є батьківською, а таблиця Гравець - дочірньої. Таблиця Гравець також є залежної, оскільки гравець повинен ідентифікуватися й за назвою команди. Залежні таблиці не можуть існувати в базі даних без батьківських. Наявний зв'язок створений шляхом включення поля Команда$Назва як частина первинного ключа таблиці Гравець. Як і в цьому прикладі, залежні таблиці часто включають первинний ключ батьківської таблиці як фрагмент власного первинного ключа.

Рис.2.12. Слабка сутність

Асоціативна таблиця - це дочірня таблиця двох таблиць, які перебувають у відносинах «багато-до-багатьох». Наприклад, у замовленні може бути кілька товарів. Однак певний продукт також може бути присутнім у декількох замовленнях. Тому між замовленням і продуктом існує відношення «багато-до-багатьох», представлене у вигляді асоціативної таблиці LINEITEM. Асоціативна таблиця використовує зовнішні ключі обох батьківських таблиць для складання власного первинного ключа. Щоб скласти свій первинний ключ, таблиця LINEITEM використовує як поле ORDER$id, так і поле PRODUCT$id, як показано на мал. 2.13.

Рис. 2.13. Первинний ключ асоціативної таблиці