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

Засоби автоматизованого проектування концептуальної моделі привертають до себе в даний час великий інтерес і використовуються в процесі створення структури бази даних і інтерфейсу користувача для доступу до даних.

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

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

• проектування бази даних, в процесі якого створюються робочі прототипи;

• кодування – створення структур баз даних і закінченого інтерфейсу користувача і

• супровід готової бази даних.

Основна ідея застосування засобів автоматизованого проектування баз даних полягає в тому, що процес ручного кодування починається лише після закінчення процесу проектування. На стадії проектування схема бази даних і інтерфейс користувача для доступу до бази даних створюються автоматично, виходячи з опису концептуальної моделі, за допомогою так званих CASE-засобів (Computer Aided Software/System Engineering). Звичайно, створений таким чином інтерфейс не є закінченим програмним продуктом, проте він дозволяє замовникові оцінити можливості кінцевого продукту і внести свої корективи. Лише після схвалення замовником робочого прототипу розробники приступають до ручного кодування – створення закінченого додатку.

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

На практиці частіше за все CASE-засоби використовуються для створення схеми бази даних у вигляді ER-діаграм і генерації структур баз даних для конкретної СУБД. Після отримання від замовника змін розробники вносять відповідні виправлення до діаграми "сутність – зв'язок" і заново генерують структури баз даних. Засоби автоматичної генерації інтерфейсів використовуються рідше.

В наш час практично кожен виробник СУБД пропонує власний програмний продукт автоматизованого проектування. Це Oracle Designer (Oracle), Power Desinger (Sybase) та інші.

26. Використання формального апарату для оптимізації схем відношень. Проблема вибору раціональних схем відношень

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

Розглянемо для прикладу конкретну схему відношень і проаналізуємо її недоліки. Припустимо, що дані про студентів, факультети, спеціальності, включені в таблицю з наступною схемою відношення: СТУДЕНТ (Код студента, Прізвище, Назва факультету, Назва спеціальності).

Ця схема відношень обумовлює такі недоліки відповідної бази даних:

• Дублювання інформації (надлишковість). У студентів, що навчаються на одному факультеті, повторюватиметься назва факультету. Для різних факультетів повторюватимуться спеціальності.

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

• Потенційна можливість втрати відомостей (аномалії вилучення). При видаленні інформації про всіх студентів, що поступають на певну спеціальність, ми втрачаємо всі відомості про цю спеціальність.

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

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