§3. Проектування баз даних та інформаційних систем

При проектуванні бази даних замовник, як правило, подає розробнику опис форм, бланків, які існують у паперовому вигляді. При простому перенесенні полів паперових форм у таблиці бази даних неминуче виникає низка проблем. При проектуванні баз даних необхідно дотримуватись таких правил:

• виключити надлишковість збережуваних даних;

• звести кількість таблиць до мінімуму.

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

3.1. Нормалізація та її необхідність

Проілюструємо хід проектування бази даних на прикладі магазину комп’ютерної техніки. Всі дані занесемо в таблицю 1.

Таблиця 1. Магазин „КТ”

Дата	Ім’я продавця	Ім’я покупця	Адреса	Назва товару	Ціна
1.02.05 8.02.05 8.02.05 15.02. 05 22.02. 05	Тепляк Олексій Поштар Андрій Савчук Сергій Кушнір Анатолій Поштар Андрій	Марчук Сергій Данилів Євген Ємчук Микола Мазур Василь Гульчак Іван	Чернівці, вул. Головна Чернівці, вул. Шевченка Кіцмань, вул. Л. Українки Хотин, вул. Хоткевича Чернівці, вул. Лисенка	Комп’ютер Принтер Модем Мишка Монітор Клавіатура Клавіатура Принтер Монітор	450 94 129 7 196

Звичайно, таблицю 1 відношенням назвати не можна, оскільки деякі її стовпці Ім’я продавця, Ім’я покупця, Адреса, Назва товару містять неатомарні значення. Для усунення цього недоліку додамо до таблиці стовпці Прізвище покупця, Прізвище продавця. Стовпець Адреса розіб’ємо на два стовпці: Місто, вулиця. Це дозволить виконати статистичну обробку купівельної здатності міст і їх окремих районів. Крім того, до таблиці доведеться додати кілька рядків, щоб значення стовпця Назва товару також стали атомарними.

Таблиця 2. Магазин „КТ”

Дата	Пріз­ви­ще про­дав­ця	Ім’я про­давця	Пріз­ви­ще по­куп­ця	Ім’я по­куп­­ця	Міс­то	Вулиця	Назва товару	Су­ма
1.02.05	Тепляк	Олек­сій	Мальчук	Сер­гій	Чер­нівці	Головна	Ком­п’ютер	450
8.02.05	Поштар	Андрій	Данилів	Єв­ген	Чер­нівці	Шевченка	Прин­тер	76
8.02.05	Поштар	Андрій	Данилів	Єв­ген	Чер­нівці	Шевченка	Модем	18
8.02.05	Савчук	Сергій	Ємчук	Ми­ко­­ла	Кіц­мань	Л.Україн­ки	Миша	2
8.02.05	Савчук	Сергій	Ємчук	Ми­ко­­ла	Кіц­мань	Л.Україн­ки	Мо­ні­тор	120
8.02.05	Савчук	Сергій	Ємчук	Ми­ко­­ла	Кіц­мань	Л.Україн­ки	Кла­ві­а­тура	7
15.02.05	Кушнір	Анато­лій	Мазур	Ва­силь	Хо­тин	Хотке­ви­ча	Кла­ві­а­тура	7
22.02.05	Поштар	Андрій	Гульчак	Іван	Чер­нівці	Лисенка	Прин­тер	76
22.02.05	Поштар	Андрій	Гульчак	Іван	Чер­нівці	Лисенка	Моні­тор	120

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

Таке подання даних у вигляді таблиці 2 приводить до виникнення великого обсягу надлишкових даних. Ім’я і адресу одного й того ж покупця необхідно заново вносити при введенні нового замовлення. Є інші проблеми: проблема великої кількості помилок при введенні великої кількості інформації, яка повторюється.

Таким чином, при використанні універсальних таблиць виникають такі проблеми:

• Проблема надлишковості даних. Дані практично всіх стовпців багатократно повторюються.

• Проблема оновленя баз даних (або потенційної суперечності даних). Внаслідок надлишковості можна обновити, наприклад, адресу покупця в одному рядку, залишаючи її незмінною в іншому. З’явиться дві адреси, одна з яких вже недійсна.

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

• Проблема вилучення даних. При вилученні даних одного рядка може бути загублена якась потрібна інформація. Для усунення описаних проблем необхідно використати так звану нормалізацію.

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

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

Основою процесу нормалізації є запропонований Е. Коддом процес нормалізації відношень. Процес нормалізації – це послідовна зміна структури таблиць доти, доки вони не будуть задовольняти вимоги останньої форми нормалізації. Існують такі шість форм нормалізації:

• Перша нормальна форма – 1НФ

• Друга нормальна форма – 2НФ

• Третя нормальна форма – 3НФ

• Нормальна форма Бойса-Кодда – НФБК

• Четверта нормальна форма – 4НФ

• П’ята нормальна форма – 5НФ.

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