NULL, логіка і невизначеність в SQL

NULL в систе́мах керува́ння ба́зами да́них (СКБД) — спеціальне значення (псевдозначеня), яке може бути записано в полі таблиці бази даних (БД). NULL відповідає поняттю «порожнє поле», тобто «поле, яке не містить ніякого значення». Введено для того, щоб розрізняти в полях БД порожні (візуально не відображаються) значення (наприклад, рядок нульової довжини) і відсутні значення (коли в полі не записано взагалі ніякого значення, навіть порожнього).

Введення

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

Критика Дейта

У найбільш відомих критичних зауваженнях Дейта використовується проста таблична база даних. Вона складається з двох таблиць. У таблиці Suppliers (S, «постачальники») є два стовпці: номер постачальника (SNO, первинний ключ) і місто, в якому розташовується постачальник (CITY). У таблиці Parts (P, «деталі») також є два стовпці: номер деталі (PNO, первинний ключ) і місто, в якому розташовується дана деталь (CITY). У прикладі кожна з таблиць містить по одному запису. Постачальник S1 розташовується в Лондоні, а місто, в якому розташовується деталь, невідомий P1.

Невизначені значення часто вносять плутанину, коли невідомі причини відсутності інформації в базі даних. До найбільш поширених причин неповноти даних є (тимчасова) невідомість значення деякого атрибута і непридатність даного атрибута до представленої в базі даних сутності. З обговорення Дейта бази даних очевидно випливає, що NULL в таблиці P означає (тимчасову) невідомість міста, асоційованого з деталлю P1. У заключному розділі даної замітки обговорюються додаткові складності, що випливають з неоднозначності сенсу невизначених значень.

Критика критики

Але Дейт помиляється. Проблема полягає не в тому, чи узгоджуються з реальністю результати SQL, а в тому, що Дейт невдало формулює свій вихідний запит «Видати пари SNO-PNO, для яких або постачальник і деталь розташовуються в різних містах, або місто, в якому розташовується деталь, не є Парижем (або виконуються обидва ці умови) ». Формулювання на SQL насправді не відповідає цьому запиту. Насправді, запит Дейта не може бути правильно трансльований на SQL, оскільки він передбачає наявність традиційної двозначної логіки, а SQL оперує тризначною логікою.

У традиційній логіці висловлювання бувають істинними або помилковими. Тобто деталь P1 розташовується в Парижі або не мають. У тризначній логіці, використовуваної в SQL, висловлювання бувають істинними, хибними або невідомими (unknown). Після появи можливості невідомих висловлювань деталь P1 не зобов'язана розташовуватися або не була у Парижі. Тепер ми можемо знати, що деталь P1 розташовується в Парижі, що деталь P1 не була у Парижі, а можемо не знати, де розташовується деталь P1.

Запити необхідно формулювати відповідно до вимог використовуваної в мові запитів логічної системи. У традиційній двухзначной логічній системі повинна існувати можливість класифікації тверджень на «справжні» і «неправдиві». При використанні тризначною логічної системи повинні також допускатися «невідомі» твердження. У вихідному запиті Дейта мається на увазі двозначна логіка. Розглянемо першу частину запиту: «Видати пари SNO-PNO, для яких ... постачальник і деталь розташовуються в різних містах». У цьому запиті мається на увазі, що міста, в яких розташовується постачальник і деталь, або різні, або збігаються. Але в тризначною логічній системі SQL міста постачальника і деталі можуть збігатися, можуть не збігатися, а може бути просто невідомо, різні вони або збігаються. Аналогічно іде справа з другою частиною запиту: «« Видати пари SNO-PNO, для яких ... місто, в якому розташовується деталь, не є Парижем ». І в цьому запиті мається на увазі, що місто, в якому розташовується деталь, або є, або не є Парижем. Однак в контексті SQL це місто може бути Парижем, може не бути Парижем, а може бути просто невідомий. І в дійсності невизначене значення в базі даних показує, що ми не знаємо, з яким містом асоційована деталь P1.

Дейт стверджує, що «в реальному світі» місто, в якому розташовується деталь P1, або є, або не є Парижем. Звичайно, це вірно. Але також вірно і те, що «в реальному світі» ми можемо не знати, яке місто асоційований з деталлю P1. Це два різних висловлювання. Міста, яким відповідають деталі, являють собою безліч фактів, яке існує незалежно від того, чи знаємо ми, які міста відповідає якими фактами. У SQL запити завжди мають на увазі знання подібного взаємозв'язку, а не просто її існування. Тому вихідний запит Дейта можна переформулювати наступним чином: «Видати пари SNO-PNO, для яких відомо, що або постачальник і деталь розташовуються в різних містах, або місто, в якому розташовується деталь, не є Парижем (або виконуються обидва ці умови)». Тепер результати SQL-запиту мають сенс. Повертається порожній результат, оскільки, хоча деталі P1 «в реальному світі в дійсності відповідає деяке місто» ( невідомо, якому місту правдива ця деталь.)

Обговорення

Використання в SQL тризначною логіки і маркера невизначених значень призводить до вимоги обліку при формулюванні запитів можливості того, що зв'язки між сутностями є невідомими. Якщо це зробити не вдається, виникає ризик формулювання не ту питання, який передбачався. Потрібно пам'ятати, що логіка SQL не є інтуїтивної. Рідко вдається прямо відобразити в SQL питання, використовувані людьми при звичайному спілкуванні. Не можна просто запитати про «пари SNO-PNO, для яких міста постачальника і деталі не збігаються», а потрібно задавати питання щодо «пари SNO-PNO, для яких відомо, що міста постачальника і деталі не збігаються». Ще більш важливим є те, що потрібно розуміти, в чому полягає відмінність цих формулювань.

Проблема посилюється тим фактом, що інформація може бути відсутнім в базі даних по ряду різних причин. В Дейт вказує сім поширених причин неповноти даних: значення не застосовується, значення невідомо, значення не існує, значення не визначене, значення не достовірно, значення не надано і значенням є порожня множина. Якщо значення може бути відсутнім, наприклад, через непридатність деякого атрибута, запити повинні формулюватися і інтерпретуватися з урахуванням потенційного обставини. Якщо маркери невизначених значень навантажуються різним змістом, побудова запитів швидко стає дуже складним завданням: «видати пари SNO-PNO, для яких атрибут міста деталі є застосовним, і для яких відомо, що постачальник і деталь розташовуються в різних містах, або містом деталі не є Париж »(або виконуються всі три умови). Для вирішення цієї проблеми деякі практики виступають на користь описових істиннісних значень. Ці рішення, які ґрунтуються на реальних значеннях, а не на маркери невизначених значень, дозволяють проектувати бази даних без невизначених значень, запити до яких можуть ґрунтуватися на традиційній двозначної логіки.

Корисно також зауважити, що будь-який запит, що спирається на тризначну логіку, можна декомпозировать в два пов'язаних запиту, що спираються на двозначну логіку. Наприклад, як обговорювалося вище, запит «видати пари SNO-PNO, для яких відомо, що містом деталі не є Париж» передбачає використання тризначної логіки, оскільки місто, в якому розташовується деталь, може бути Парижем, може бути не Парижем, а може бути ніхто не знає. Цей запит може бути декомпозирован в складовою запит «видати пари SNO-PNO, для яких відомий місто, в якому розташовується деталь, і видати з результуючого безлічі пари SNO-PNO, для яких містом деталі не є Париж». Виконання такої декомпозиції часто виявляється корисним, особливо при побудові складних запитів.

В кінцевому рахунку, автор замітки згоден з Дейтом в тому, що тризначна логіка не поєднується з системами управління базами даних. Хоча він не переконаний в тому, що тризначна логіка порушує реляційну модель по суті, він згоден з Макговераном в тому, що перехід до використання багатозначної логіки змушує проектувальників, розробників і користувачів баз даних освоювати зовсім новий спосіб мислення. Важко оцінити практично необхідні витрати, але, звичайно, потреба в них суперечить цілям, для досягнення яких існують SQL-орієнтовані СУБД.

Те, що сам Дейт неправильно розуміє сенс своїх SQL-запитів, підкреслює серйозність цієї проблеми.

Висновок

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

Використання в SQL невизначених значень - це не найважливіша проблема, з якою доводиться стикатися при наявності бази даних. Швидше проблема звучить так: «Де ж ця чортова деталь P1?». Якщо деталь P1 везуть до Парижа, цю інформацію потрібно зберегти в базі даних. Якщо деталь P1 загубиться, потрібно вміти відобразити в базі даних і цю інформацію. Зокрема, включення такої інформації в базу даних підвищує цінність бази даних і сприяє підтримці її цілісності за рахунок наявності можливості видаляти з неї проблематичних записів.

Застосування належних методів проектування дозволяє природним чином мінімізувати число невизначених значень в базі даних. Схема бази даних - це модель конкретної предметної області та її можна точно побудувати тільки на основі повного обстеження цієї предметної області - опису її кордонів, визначення входять до неї компонентів, з'ясування їх взаємозв'язків. Звичайно, метою проектування бази даних є досягнення уявлення не ідеального предметної області, а лише тих її аспектів, які найбільш істотні для конкретної проблеми. Якщо деталь P1 знаходиться в вантажівці, що рухається в бік Парижа, то очікуваний час його прибуття, ймовірно, є істотним, а то, що водій вантажівки недавно посварився з дружиною, швидше за все, не суттєво. Невизначені значення дозволяють спрощувати моделі за рахунок приведення до загальної форми всіх аномалій, що породжують відсутні дані та невідомі зв'язку. Але ціною цього спрощеного уявлення є тризначна логіка і відповідне збільшення складності запитів.

Рідко вдається гарантувати повну відсутність невизначених значень в базі даних. Навіть якби вдалося переконати компанії-виробники СУБД виступити проти невизначених значень і тризначної логіки, ми залишилися б обтяжені цією спадщиною в доступному для огляду майбутньому. І оскільки присутність єдиного невизначеного значення впливає на всю базу даних, в загальному випадку потрібно мати на увазі наявність тризначною логіки. Тому потрібно ретельно перевіряти запити, щоб бути впевненими, що вони означають в точності те, що передбачалося.

Джерела

• C. J. Date. Ні - це не "ні"! (примітки щодо тризначної логіки та суміжних питань). У реляційних базах даних, 1985–1989. Аддісон Уеслі, 1990.
• C. J. Date. Реляційні бази даних, 1994–1997. Аддісон Уеслі Лонгман, 1998.
• C. J. Date. Вступ до систем баз даних. Аддісон Уеслі Лонгман, Редінг, М., сьоме видання, 2000.
• C.J. Date. База даних в глибині: теорія відносин для практиків. O'Reilly, Sebastopol, CA, 2005.
• Г. Г. Гессерт. Обробка відсутніх даних за допомогою збережених значень істини. SIGMOD Record, 20 (3): 30–42, літо 1991.
• Девід МакГован. Нічого з нічого (частина 2 з 4) класичної логіки: Ніщо не порівнює 2 u. У реляційних базах даних, 1994–1997 [2], глава 6, стор. 347–365.
• Девід МакГоверан. Ніщо з нічого (частина 4 з 4): Це так, як ви його використовуєте у реляційних написах баз даних, 1994–1997 рр. [2], глава 8, стор. 377–394.