Таблиця 1.1 – Відомості про оплати

Прізвище | Ім’я | Адреса | Назва фонду | Сума | Дата

Петренко | Петро | вул. Зелена, 6 | Благодійний фонд "Пальма де Майорке" | 2,00 | 02.12.2003

Дрозд | Ольга | пл. Героїв, 23 | Фонд взаємодопомоги "Гаваї" | 3,00 | 01.01.2004

Дрозд | Ольга | пл. Героїв, 23 | Кредитна спілка "Канарські острови" | 3,00 | 31.01.2004

Сіренко | Степан | пер. Лісний, 2 | Благодійний фонд "Пальма де Майорке" | 4,00 | 12.02.2004

Петренко | Петро | вул. Зелена, 6 | Благодійний фонд "Пальма де Майорке" | -1,00 | 31.03.2004

Дрозд | Ольга | пл. Героїв, 23 | Фонд взаємодопомоги "Гаваї" | -2,00 | 06.04.2004

Дрозд | Ольга | пл. Героїв, 23 | Благодійний фонд "Пальма де Майорке" | 2,00 | 21.04.2004

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

Таблиця 1.1 може служити в якості бази даних, але дублювання інформації в ній приводить до таких недоліків:

витрачається зайва пам’ять як магнітна, так оперативна, що стає особливо відчутним в умовах виробництва, де кількість стовпців таблиці сягає сотень, а рядків – тисяч;

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

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

зростають затрати праці під час внесення свіжих даних у таблицю. Наприклад, під час обслуговування платника доцільно було б використовувати дані про нього, які вже є в таблиці (вибрати зі списку), а не вводити заново;

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

швидкість обслуговування клієнтів і продуктивність праці оператора будуть порівняно невисокими.

Враховуючи ці недоліки, наша БД повинна мати три окремі таблиці про:

платників (таблиця 1.2),

фонди (таблиця 1.3)

оплати (таблиця 1.4).

Таблиця 1.2 – Перелік прізвищ, імен та адрес платників

Код платника | Прізвище платника | Ім’я платника | Адреса

1 | Петренко | Петро | вул. Зелена, 6

2 | Дрозд | Ольга | пл. Героїв, 23

3 | Сіренко | Степан | пер. Лісний, 2

Таблиця 1.3 – Перелік назв фондів

Код фонду | Назва фонду

1 | Благодійний фонд "Пальма де Майорке"

2 | Фонд взаємодопомоги "Гаваї"

3 | Кредитна спілка "Канарські острови"

Таблиця 1.4 – Перелік оплат

Код платника | Код фонду | Сума оплати | Дата оплати

1 | 1 | 2,00 | 02.12.2003

2 | 2 | 3,00 | 01.01.2004

2 | 3 | 3,00 | 31.01.2004

3 | 1 | 4,00 | 12.02.2004

1 | 1 | -1,00 | 31.03.2004

2 | 2 | -2,00 | 06.04.2004

2 | 1 | 2,00 | 21.04.2004

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

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

В теорії БД основною вимогою до таблиць є їх нормалізація. Розглянена вище відсутність дублювання інфорамції є однією з властивостей нормалізованої таблиці.

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

Таблиця 1.5 – Назви місяців і їхніх кодів

Код місяця | Назва місяця

1 | січня

2 | лютого

3 | березня

4 | квітня

5