Экономические науки/10. Экономика предприятия

 

К.т.н. Холод С.Б.

Дніпропетровський університет імені Альфреда Нобеля, Україна

 

ОБМЕЖЕННЯ РЕАЛІЗАЦІЇ СИСТЕМИ УПРАВЛІННЯ БАЗАМИ ДАНИХ

 

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

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

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

Результат етапу аналізу – створення інформацій­ної моделі. Здавалося б, справа це просте: сутності стають таблицями, а атрибути сутностей – стовпцями таблиць; ключі стають первинними ключами, для можли­вих ключів визначається обмеження unique, зовнішні ключі стають деклараціями посилальної цілісності. Ана­літики, як правило, не заглиблюються в особливості реалізації тієї чи іншої СУБД, тому при проектуванні схеми бази даних проектувальник зіштовхується з конс­трукціями в інформаційній моделі, що не можливо реалізувати або важко реалізувати в обраній СУБД.

Приведемо кілька прикладів обмежень реалізації СУБД:

1.     В інформаційній моделі описані три сутності – А, В, С. Сутності В і С містять зовнішні ключі, що поси­лаються на сутність А. У СУБД підтримується можли­вість визначення зовнішнього ключа тільки для первин­ного ключа, а для можливого ключа визначити декла­ративну посилальну цілісність не можна. У цьому випа­дку відображення ER-моделі на фізичну модель даних неможливо без зміни інформаційної моделі;

2.     В інформаційній моделі описаний зовнішній ключ з каскадним видаленням і модифікацією. У СУБД підтримуються зовнішні ключі тільки для варіанта дії по action (тобто, каскадні зміни в явному вигляді не підтримуються). Реалізація посилальної цілісності за допомогою тригерів обмежена рівнем каскадування тригерів (наприклад, 32 викликами тригера). У цьому випад­ку буде потрібно також зміна інформаційної моделі;

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

4.     В інформаційній моделі описана сутність А, що містить, принаймні, два атрибути BLOB (наприклад, потрібно окремо зберігати і звук і зображення). У СУБД неможливо створити таблицю з двома атрибутами BLOB і в цьому випадку потрібно змінити опис сутності. З від­ношення А виключаються два атрибути BLOB, і дода­ється один атрибут АК типу integer. Додаються дві до­даткові сутності – АІ і АП. Кожна з них буде містити один атрибут BLOB і один ключовий атрибут К типу integer, що стане зовнішнім ключем у кожного з нових відносин і буде посилатися на атрибут АК у відношенні А (тип зовнішнього ключа – on delete cascade, on update cascade);

5.     Життєвий цикл сутності визначений в інформа­ційній моделі відповідною діаграмою. В описанні сут­ності відсутній атрибут, що відображає зміну стану сут­ності. У цій ситуації проектувальники додають атрибут status, для якого визначається обмеження припустимих значень (зі списку припустимих станів), а зміна стану сутності описується тригером, що перевіряє допустимість сполучення нового і старого значення атрибута;

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

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

Виходячи з вищенаведеного, слід констатувати, що однакових СУБД не буває: те, що добре працює в одній, може погано працювати чи взагалі не працювати в іншій, незважа­ючи на запевнення виробників системи управління базами даних у підтримці стан­дартів SQL.