Null-значення

Основне призначення баз даних полягає в тому, щоб зберігати і надавати інформацію про реальний світ. Для представлення цієї інформації в базі даних використовуються звичні для програмістів типи даних – Рядкові, чисельні, логічні і т.п. Однак у реальному світі часто зустрічається ситуація, коли дані невідомі або не повні. Наприклад, місце проживання або дата народження людини можуть бути невідомі (База даних розшукуваних злочинців). Якщо замість невідомої адреси доречно було б вводити порожній рядок, то що вводити замість невідомої дати? Відповідь – порожню дату – не цілком задовільний, тому що найпростіший запит " видати список людей у порядку зростання дат народження" дасть явно неправильних відповідь.

Для того щоб обійти проблему неповних або невідомих даних, в базах даних можуть використовуватися типи даних, поповнені так званим null-значенням. Null-значення – це, власне, не значення, а якийсь маркер, який показує, що значення невідоме.

Таким чином, у ситуації, коли можлива поява невідомих або неповних даних, розробник має на вибір два варіанти.

Перший варіант полягає в тому, щоб обмежитися використанням звичайних типів даних і не використовувати null-значення, а замість невідомих даних вводити або нульові значення, або значення спеціального виду – наприклад, домовитися, що рядок " Адреса невідома" і є ті дані, які потрібно вводити замість невідомої адреси. У будь-якому випадку на користувача (або на розробника) лягає відповідальність на правильне трактування таких даних. Зокрема, може знадобитися написання спеціального програмного коду, що у потрібних випадках " виловлював" би такі дані. Проблеми, що виникають при цьому очевидні – Не всі дані стають рівноправні, потрібен додатковий програмний код, " відслідковує" цю нерівноправність, в результаті чого ускладнюється розробка і супровід додатків.

Другий варіант полягає у використанні null-значень замість невідомих даних. За здавалося б природністю такого підходу ховаються менш очевидні і більш глибокі проблеми. Найбільш кидається в очі проблемою є необхідність використання тризначної логіки при оперуванні з даними, які можуть містити null-значення. У цьому випадку при неакуратному формулюванні запитів, навіть самі природні запити можуть давати неправильні відповіді. Є більш фундаментальні проблеми, пов'язані з теоретичним обгрунтуванням коректності введення null-значень, наприклад, незрозуміло взагалі, чи входять null-значення в домени чи ні.

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

Практично всі реалізації сучасних реляційних СУБД дозволяють використовувати null-значення, незважаючи на їх недостатню теоретичну обгрунтованість. Таку ситуацію можна порівняти з ситуацією, що склалася на початку століття з теорією множин. Майже відразу після створення Кантором теорії множин, в ній були виявлені внутрішні суперечності (антиномії). Були розроблені більш суворі теорії, що дозволяють уникнути цих протиріч (конструктивна теорія множин). Однак у реальній роботі більшість математиків користується класичною теорією множин, тому що більш суворі теорії більш обмежені і негнучкий в застосуванні саме в силу своєї більшої строгості.

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

Тризначна логіка (3VL)

Оскільки null-значення позначає насправді той факт, що значення невідоме, то будь-які алгебраїчні операції (додавання, множення, конкатенація рядків і т.д.) повинні давати також невідоме значення, тобто null. Дійсно, якщо, наприклад, вага деталі невідома, то невідомо також, скільки важать 10 таких деталей.

При порівнянні виразів, що містять null-значення, результат також може бути невідомий, наприклад, значення істинності для виразу є null, якщо один або обидва аргументи є null. Таким чином, визначення істинності логічних виразів базується на тризначної логіці (three-valued logic, 3VL), В якій крім значень T – ІСТИНА і F – БРЕХНЯ, введено значення U – НЕВІДОМО. Логічне значення U – це те ж саме, що і null-значення. Тризначна логіка базується на наступних таблицях істинності:

Таблиця 1 Таблиця істинності AND

Таблиця 2 Таблиця істинності OR

Таблиця 3 Таблиця істинності NOT

18.

Потенційний ключ для K для відношення R — це підмножина множини атрибутів R, що характеризується такими двома властивостями:

1. Властивість унікальності.

Немає двох різних кортежів в R з однаковим значенням K.

2. Властивість мінімальності (ненадмірності).

Ніяка з підмножин K не володіє властивістю унікальності.

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

· Або ця комбінація володіє властивістю мінімальності, тобто є потенційним ключем (єдиним).

· Або існує як мінімум одна підмножина цієї комбінації, що явно володіє властивістю унікальності, а також мінімальності.

У відношенні може бути декілька потенційних ключів. Один з них може бути вибраний в якості первинного ключа відношення, тоді інші називають альтернативними ключами.

Зазвичай на практиці первинний ключ обирають виходячи з міркувань ефективності.

Потенційні ключі забезпечують основний механізм адресації на рівні кортежів. Тобто, єдиний гарантований спосіб точно вказати який-небудь кортеж — це вказати значення якогось потенційного ключа. В інструкції SQL це, зазвичай, робиться в частині WHERE.

Таким чином потенційні ключі мають таке саме фундаментальне значення для успішної роботи реляційної системи, як адресація основної пам'яті для успішної роботи машини, на якій ця система встановлена.

Зовнішній ключ — атрибут (набір атрибутів) в деякому відношенні R, який відповідає первинному ключу іншого відношення або того ж таки відношення R.

В реляційних базах даних зовнішній ключ задається обмеженням FOREIGN KEY. Наприклад^[1],

CREATE TABLE fools (

id INTEGER PRIMARY KEY AUTO_INCREMENT,

name CHAR (20),

folly_id INTEGER,

FOREIGN KEY (folly_id)

REFERENCES follies(id) ON DELETE CASCADE);