Один-один

Другий варіант у нашому прикладі не відображений. Тому припустимо, що ми провели дослідження ринку й зібрали багато інформації про своїх клієнтів, яку тепер потрібно ввести в базу даних. Нам знадобиться додати в таблицю „Клієнти”, приміром, наступні стовпці:

P число працівників;

P адреса (місто, село);

P площа торговельних приміщень;

P назва комп’ютерної системи обліку;

P число сертифікованих бухгалтерів.

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

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

Отже, щоб уникнути зниження швидкості обробки замовлень, ми розбиваємо таблицю на дві, залишаючи за першої ім’я „Клієнти”, поле „Код клієнта” і кілька стовпців з інформацією – на зразок адрес клієнтів, – необхідної для оформлення замовлень. Друга таблиця, що ми назвемо „Клієнти Інфо”, буде мати стовпець „Код інфо про клієнта” і кілька стовпців з даними дослідження. Ідентифікатори, записані в стовпець [Клієнти Інфо].[Код інфо про клієнта] зіставляються один до одного ідентифікаторів стовпця Клієнти.[Код клієнта]. Таким чином, другу таблицю можна представити як додаткові п’ять полів у правій частині таблиці першої. Власне, таке об‘єднання й виконує СКБД, зіставляючи один одному записи обох таблиць за значеннями ключових полів.

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

Існує ще кілька типів відношень, які можуть коротко ускладнюватися. Одне з них припускає зіставлення декількох записів з кожної сторони й називається «багато-багато». Ми не будемо тут розглядати цей тип відношень.

Нижче приводиться порівняння відношень «один-один» й «один-багато»:

	Один-один	Один-багато
Призначення	Створення таблиць із меншим числом стовпців, завдяки чому таблиці з даними, звертання до яких відбувається часто, обробляються швидше	Усунення дублювання й пропусків даних
Число записів	Число записів в обох таблицях однакове	Як правило, число записів в одній таблиці (багато) більше, ніж в інший
Дублювання даних у первинному ключі	Кожна таблиця містить первинний ключ із унікальними значеннями	Сторона «один» містить первинний ключ із унікальними значеннями; сторона «багато» містить зовнішній ключ зі значеннями, які можуть дублюватися

4.3 Нормалізація

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

P Дані представлені у формі таблиць, стовпців і записів, що відповідає правилу 1 Нормальних форм. Серед структур, у яких розташовуються дані, немає зовнішніх (недоступних для SQL).

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

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

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

P У таблицях відсутні дубльовані дані – наприклад, номер телефону постачальника не вказується в записах кожного із сортів, що постачаються, (правило 2 Нормальних форм). Правда, це не позбавляє від необхідності зберігати в таблицях дубльовані коди постачальників різних сортів, необхідні для установки відношень.

P Кожен елемент даних являє собою атом – неподільну частку. Іншими словами, в одному стовпці не можна записати, приміром, найменування компанії й номер її телефону (правила 1 й 3 Нормальних форм).

Іноді виникають ситуації, що вимагають денормалізації даних. Представимо, приміром, щовечірнє складання звіту, що вимагає даних із чотирьох різних таблиць. Аналіз показує, що зв’язування цих таблиць відношеннями негативно позначиться на роботі СКБД. У цій ситуації розумним рішенням може бути допущення дублювання деякої частини даних в одній з таблиць, щоб зменшити число пошуків у зв’язаних відношеннями таблицях. Це загальний підхід, що вимагає, проте, надзвичайної обережності й максимального дотримання правил Нормальних форм. Іноді застосовуються процедури тимчасовий денормалізації (створення копій даних) для виконання деякого завдання, з негайною наступною повторною нормалізацією (видаленням копій) після її завершення. Відмова від нормалізації допускається тільки в крайніх випадках; розуміння можливих проблем допомагає тримати під контролем джерела конфліктів.

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