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

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

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

Додаткові міркування на користь приведеної тези про уповільнення виконання операцій оновлення даних (вплив журналізації, довжини рядків таблиць) приведені в роботі А.Прохорова [27].

Швидкість операцій вибірки даних

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

Основний приклад

Розглянемо як предметна область деяку організацію, що виконує деякі проекти. Модель предметної області опишемо наступним неформальним текстом:

Співробітники організації виконують проекти.

Проекти складаються з декількох завдань.

Кожний співробітник може брати участь в одному або декількох проектах, або тимчасово не брати участь ні в яких проектах.

Над кожним проектом може працювати декілька співробітників, або тимчасово проект може бути припинений, тоді над ним не працює жоден співробітник.

Над кожним завданням в проекті працює рівно один співробітник.

Кожний співробітник числиться в одному відділі.

Кожний співробітник має телефон, що знаходиться у відділі співробітника.

У ході додаткового уточнення того, які дані необхідно враховувати, з'ясувалося наступне:

Про кожного співробітника необхідно зберігати табельний номер і прізвище. Табельний номер є унікальним для кожного співробітника.

Кожний відділ має унікальний номер.

Кожний проект має номер і найменування. Номер проекту є унікальним.

Кожна робота з проекту має номер, унікальний в межах проекту. Роботи в різних проектах можуть мати однакові номери.

1НФ (Перша Нормальна Форма)

Поняття першої нормальної форми вже обговорювалося на чолі 2. Перша нормальна форма (1НФ) - це звичне відношення. Згідно нашому визначенню відносин, будь-яке відношення автоматично вже знаходиться в 1НФ. Нагадаємо стисло властивості відносин (це і будуть властивості 1НФ):

У відношенні немає однакових кортежів.

Кортежі не впорядковані.

Атрибути не впорядковані і розрізняються по найменуванню.

Всі значення атрибутів атомарні.

У ході логічного моделювання на першому кроці запропоновано берегти дані в одному відношенні, що має наступні атрибути:

СПІВРОБІТНИКИ_ВІДДІЛИ_ПРОЕКТИ (Н_СПІВ, ПРІЗВ, №_ВІДД, ТЕЛ, №_ПРО, ПРОЕКТ, Н_ЗАВД)

де

Н_СПІВ - табельний номер співробітника

ПРІЗВ - прізвище співробітника

Н_ВІД - номер відділу, в якому числиться співробітник

ТЕЛ - телефон співробітника

Н_ПРО - номер проекту, над яким працює співробітник

ПРОЕКТ - найменування проекту, над яким працює співробітник

Н_ЗАВД - номер завдання, над яким працює співробітник

Оскільки кожний співробітник в кожному проекті виконує рівно одне завдання, то як потенційний ключ відношення необхідно узяти пару атрибутів {Н_СПІВ, Н_ПРО}.

У нинішній момент полягання предметної області відображається наступними фактами:

Співробітник Іванов, що працює в 1 відділі, виконує в першому проекті "Космос" завдання 1 і в другому проекті "Клімат" завдання 1.

Співробітник Петров, що працює в 1 відділі, виконує в першому проекті "Космос" завдання 2.

Співробітник Сидоров, що працює в 2 відділі, виконує в першому проекті "Космос" завдання 3 і в другому проекті "Клімат" завдання 2.

Це полягання відображається в таблиці (курсивом виділені ключові атрибути):

Н_СПІВР | ПРІЗВ | Н_ВІД | ТЕЛ | Н_ПРО | ПРОЕКТ | Н_ЗАВД

1 | Іванов | 1 | 11-22-33 | 1 | Космос | 1

1 | Іванов | 1 | 11-22-33 | 2 | Климат | 1

2 | Петров | 1 | 11-22-33 | 1 | Космос | 2

3 | Сидоров | 2 | 33-22-11 |