Що таке NULL

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

NULL представляє значення, що на даний момент невідомо.

Іноді значення NULL визначають як «непридатне», «невідоме» або «нерозв’язне». Розглянемо ряд ситуацій, до яких можуть бути застосовні наведені визначення.

P Значення NULL відсотка річного приросту. Чи означає це, що потрібно почекати кінця року для визначення значення? Або компанія існує перший рік, тому про приріст не можна вести мову! Нарешті, потрібне значення не можна обчислити, оскільки в недавній пожежі згоріли потрібні папери!

P Значення NULL дати народження. Чи означає це, що людина просто не народилась, і чи не співвідноситься це, деяким чином, з абортом, у відношенні якого можна визначити багато дат, але тільки не народження?

P Значення NULL балансу банківського рахунку. Чи означає це нульовий баланс? Або що рахунок поки не відкритий? Може баланс неможливо порахувати через помилку або якусь невідповідність? Або він існує, але невідомо, що це таке? Або, попросту, не попадає в інтервал значень, визначених для даного стовпця?

P Значення NULL прізвища. Чи означає це, що прізвище даної людини невідоме? Або людина прибула з Індонезії, де більшість населення звикли обходитися без прізвищ?

P NULL значення в стовпці таблиці, що містить ідентифікатор керівника співробітника. Чи означає це, що дана людина незалежна і не має керівника? Або він самий головний і нікому не підкоряється? Або, нарешті, це консультант, запрошений з іншої компанії?

P NULL гарантійного строку. Чи означає він безстрокову гарантію або відсутність такої?

P NULL віку. Чи означає це, що людина приховує вік? Звичайно, у кожної людини є вік, але вік деяких людей невідомий.

Чи можна обійтися без значення NULL?

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

Значення NULL – неминуче зло. Вони займають більше місця в пам’яті, чим звичайні значення, утрудняють індексування й пошук. Втім, всі утруднення – чисто логічні, пов’язані з необхідністю визначати, у кожному конкретному випадку, зміст цього значення. Ситуація ще більше ускладнюється здатністю цих значень розмножуватися. Тобто, у результаті виконання операцій додавання, віднімання, множення або ділення двох чисел, одне з яких дорівнює NULL, одержуємо ще один NULL, У складних обчисленнях імовірність наявності цього значення підвищується – отже, підвищується й імовірність одержання результату, рівного NULL.

Чому дорівнює NULL?

Невизначеність відчувається як незручність, тому багато студентів намагаються представити NULL як деяке конкретне значення. Це неправильно. NULL не має нічого спільного ні з нулем, ні з порожнім текстовим рядком, позначеним парою лапок.

Було знайдено кілька рішень проблем, породжуваних цими значеннями. Всі вони запропоновані постачальниками СКБД і все ґрунтувалися на чистому ANSI-SQL. Перше рішення полягало в тому, що ANSI-SQL пропонував ігнорувати значення NULL в операціях на зразок визначення найбільшого, найменшого або середнього значення на множині даних. Ми продовжимо обговорення цієї теми далі. Другим рішенням була розробка деякими постачальниками функцій, що виконують заміну значення NULL, певним за замовчуванням, іншим залежно від конкретної ситуації. Наприклад, у запиті можна вказати заміну всіх значень NULL, у якому-небудь стовпці, нулями. У таблиці як і раніше будуть залишатися значення NULL, але в повернутому наборі записів замість них будуть стояти нулі. Опис цих функцій можна знайти в документації до СКБД, у яких вони реалізовані. Нарешті, у всіх версіях SQL забезпечена підтримка «трійкової логіки», у якій визначені результати порівняння значення NULL зі значеннями TRUE й FALSE. Трійкова логіка описується в літературі по SQL, призначеної для кваліфікованих SQL-програмістів.

Загальні рекомендації відносно значень NULL

Ми завершимо обговорення значень NULL (яке, думаю, було небезкорисним) декількома порадами по роботі із цими значеннями.

P По можливості, потрібно накладати на стовпець умову NOT NULL, що забезпечує наявність значення в кожному полі стовпця.

P По можливості, встановлюйте використання замість відсутніх значень значення за замовчуванням (звичайно нуль або порожній рядок).

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

P Там, де це можливо й логічно виправдано, встановлюйте додаткові стовпці з інформацією, яку можна використати для уточнення змісту значень NULL. Наприклад, стовпець зі значеннями TRUE /FALSE можна використати для позначення людей, що не вказали свій вік. Пізніше, коли ми навчимося встановлювати складні запити вибірки даних, ці значення можна буде використати при обробці значень NULL.

P Пам’ятаючи про здатності значень NULL розмножуватися, дуже уважно ставитеся до обчислень у стовпцях, у яких можлива поява цих значень.

P Якщо значення NULL, що виникає в даному стовпці, може мати кілька тлумачень, спробуйте використати значення-підстановку для одного або декількох з них. Наприклад, при розходженні тлумачень «невідомо» й «не було», вводьте «НБ» для позначення відсутніх значень.

P Не виконуйте операцій відношення (=, <, >) над значеннями NULL.

P Якщо є можливість уникнути запису в стовпець значень NULL, встановіть відповідне обмеження.

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

P При програмуванні процедур введення даних із клавіатури передбачайте блокування введення значень NULL.

4.5 Де ж у цій теорії місце SQL-операторам?

У стандарті ANSI-SQL визначені, власне кажучи, три підмножини мови SQL:

P Мова визначення даних (Data Definition Language – DDL) призначена для опису структур даних. Більша частина принципів конструювання баз даних, розглянутих у даній темі, реалізовані на основі DDL. Ми розглянемо цю мову в далі.

P Найбільше часто використовувані команди відносяться до мови маніпулювання даними (Data Manipulation Language – DML), що описує операції запису, модифікації й видалення даних. Всі операції зчитування даних також відносяться до DML. Її розгляд – далі.

P Нарешті, мова керування даними (Data Control Language – DCL) використовується для програмування безпеки в багатокористувацьких системах. DCL містить команди створення облікових записів користувачів й установки дозволів доступу.

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

5 Порівняння термінології SQL й інших систем

Як останній крок до розуміння концепції баз даних з підтримкою SQL зрівняємо термінологію цієї мови з термінологією інших систем роботи з інформацією.

5.1 Паперові документи

Якщо дані про клієнтів записувати на паперові картки, то ящик із цими картками буде відповідати таблиці, картка – запису, місця в картці, де записаний номер телефону, місто й т.п., відповідають стовпцям. Що ж стосується SQL-операторів вибірки даних, то їхня роль у картковій системі грають позначки на куточках карток особливо коштовних клієнтів, по яких їх можна відрізнити від інших.

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

5.2 Електронні таблиці

Аналогія з електронними таблицями напрошується сама собою, однак ця аналогія таїть у собі деяку небезпеку. Дійсно, база даних відповідає книзі електронної таблиці, таблиці бази даних – електронним таблицям, записи – рядкам електронних таблиць. Небезпека ж полягає в уявленні, що таблиця бази даних має ту ж гнучкість, що й електронна таблиця. В клітинці електронної таблиці можна розмістити, приміром, формулу, в SQL-таблиці – тільки дані. Обчислення ж (наприклад, цінових знижок) виконуються SQL-операторами перед доставкою результатів користувачеві. Крім цього, в електронних таблицях не фіксується формат клітинок, точніше він може змінюватись. В одному рядку, як й в одному стовпці, можуть співіснувати чисельні й строкові значення, дати й т.п. В SQL-таблиці такі „вольнощі” не допускаються заради підтримки високого рівня ефективності системи.

Бази даних володіють рядом переваг над електронними таблицями. Це, по-перше, можливість установки відношень між таблицями, завдяки чому вдається значно знижувати дублювання й пропуски даних. В електронних таблицях рішення цього завдання набагато складніше. По-друге, у базах даних, на відміну від електронних таблиць, можна зберігати величезні обсяги інформації. По-третє, SQL-оператори дозволяють задавати більше складні умови пошуку й об‘єднування даних. Нарешті, SQL забезпечує могутніші засоби підтримки цілісності даних.

5.3 Настільні системи СКБД (на прикладі Access)

Багато читачів мають досвід роботи з настільними системами баз даних з шкільних уроків інформатики. Ці системи не призначені для обслуговування одночасно більше десятка користувачів. Перехід до роботи з потужними СКБД (з підтримкою SQL) – цілком логічний крок у випадку збільшення числа користувачів або інтегрування бази даних у вузол Web.

Існує деякий різнобій у термінології між різними постачальниками баз даних. Правда, у більшості випадків база даних все-таки складається з таблиць, які в свою чергу мають записи й стовпці. В одній із СКБД таблиця, власне кажучи, представлена файлом. У деяких СКБД стовпці йменуються полями. В SQL запити даних іменуються операторами, у настільних системах вони часто залишаються запитами. Ще одна істотна особливість настільних систем: вся їхня структура й дані зберігаються у файлах, тоді як у СКБД промислового масштабу застосовується інший механізм взаємодії з дисками. Файлова система, на зразок застосовуваної в Access, не може бути застосована в таких СКБД, оскільки концепції власника файлу й блокування неможливі в системах, розрахованих на одночасне підключення тисяч користувачів. Нарешті, у настільних системах зовнішній інтерфейс, з’єднання й прикладна частина зазвичай об‘єднані в одному пакеті. А в мові SQL інтерфейс користувача не передбачений.