Проектування баз даних

Лекція №4.

Проектування баз даних

Зміст лекції

Предметна область        3

Нормалізація баз даних.        5

Приклад 1. База даних "Розподіл учбового навантаження"        5

Приклад 2. База даних "Аеропорт"        6

Загальні відомості з проектування баз даних

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

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

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

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

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

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