ДЕЯКІ ОСОБЛИВОСТІ ТЕХНОЛОГІЇ ПІДТРИМКИ ПРИЙНЯТТЯ РІШЕНЬ

Бази даних підтримки прийняття рішень володіють особливими характеристиками, і головна з них полягає в тому, що такі бази даних в основному (хоча і не завжди) призначені тільки для читання Модифікація вмісту бази даних зазвичай огранивать періодичними операціями завантаження або оновлення До того ж серед цих операцій переважає операція INSERT, операція DELETE виконується вкрай рідко, а операція UPDATE не виконується майже ніколи

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

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

фізичні

■ Стовпці найчастіше використовуються в поєднаннях

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

■ Ключі часто містять тимчасової компонент (безумовно, підтримка хронологічний скі впорядкованих даних була б надзвичайно корисною, як описано в главі 23, але надається рідко)

■ Бази даних зазвичай мають великий обсяг, особливо в тому випадку (як це найчастіше буває), коли дані ділових транзакцій1 накопичуються протягом доста точно тривалого часу

■ У базі даних, як правило, широко застосовується індексація

■ База даних часто відрізняється різного роду контрольованої надмірністю

Запити підтримки прийняття рішень також мають характерні особливості і, зокрема, зазвичай вони є досить складними Нижче вказано, в чому саме полягає складність який складають запитів

■&nbsp Складність логічних виразів Запити підтримки прийняття рішень часто включають складні вирази в конструкції WHERE ЦІ вираження нелегко формулювати, в них непросто розбиратися, а в системі виникають складності при їх ефективної реалізації Широко поширена проблема повязана з тим, що в запитах часто потрібно враховувати дані про час (як приклад можна вказати запити на отримання рядків з максимальним значенням тимчасової оцінки в заданий період часу) Якщо в запитах використовуються які-небудь зєднання, то вони дуже швидко стають надзвичайно складними, особливо з тієї причини, що відповідна хронологічна підтримка найчастіше не передбачена І цілком природно, що в кінцевому підсумку у всіх цих випадках спостерігається низька продуктивність

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

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

Автор цієї глави (Макговерен), що працював над однією з перших версій системи підтримки рішень у 1981 році, зауважив, що для зєднання трьох таблиць навіть середніх розмірів цілком може знадобитися багато годин, а зєднання від чотирьох до шести таблиць взагалі стає занадто дорогим Але при використанні сучасних компютерів зєднання від шести до десяти дуже великих таблиць – звичайне справа, і подібна можливість, як правило, передбачена також технологією баз даних Проте все ще не можна виключити ймовірність такої ситуації, що буде сформований запит, при виконанні якого буде потрібно зєднати таку велику кількість таблиць, яке не зовсім успішно підтримується технологією (і зазначені ситуації зустрічаються досить часто) Спроба виконати запит на зєднання більше дванадцяти таблиць може привести до непередбачуваного результату, але необхідність виконання подібних запитів зустрічається досить часто Примітка Опис можливих рішень цієї проблеми наведено в додатку А

зєднання певних таблиць Однак, як уже зазначалося у розділі 13, цей підхід рідко приводить до успіху, оскільки проектувальники в таких випадках стикаються з багатьма проблемами, які потрібно вирішувати завчасно І крім того, спроби уникнути явного використання зєднань на етапі прогону можуть призвести до неефективного застосування реляційних операцій, оскільки при цьому відбувається вибірка великих обсягів даних, які, по суті, не потрібні, а обробка зєднань здійснюється в додатку, а не в СУБД

■&nbsp&nbsp&nbsp&nbsp Складність функцій У запитах систем підтримки прийняття рішень часто ис користуються статистичні та інші математичні функції Але до останнього часу їх підтримували лише деякі програмні продукти (проте ситуа ція в цій області трохи покращилася) Тому часто виникає необхідність в розбитті запиту на послідовність менших запитів, які потім ви полняются, чергуючись з одними процедурами, в яких обчислюються необхідні функції Але, на жаль, при використанні такого підходу може знадобитися витяг великих обсягів даних, не кажучи вже про те, що сам запит стає значно складніше як для написання, так і для розуміння

■&nbsp&nbsp&nbsp&nbsp Аналітична складність Ділові запити рідко можна сформулювати у вигляді одного простого запиту Надмірно складні запити представляють значитель ні труднощі не тільки для користувачів Обмеження, властиві кон кретной реалізації мови SQL, можуть не дозволити системі успішно виконувати обробку подібних запитів Одним із шляхів спрощення таких запитів являють ся їх розбиття на ряд менших запитів із збереженням результатів під вспомога тільних таблицях

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

продуктивності процесів пакетного додавання даних і довільного вилучення даних Але з точки зору автора (яка детально викладається в наступному розділі), такий стан справ має враховуватися на етапі не логічного, а фізичного проектування На жаль, як уже зазначалося в розділі 221, розробники і користувачі систем підтримки прийняття рішень часто допускають помилки, не розрізняючи логічні та фізичні аспекти проектірованія3, а фактично вони часто зовсім відмовляються від створення логічного проекту системи Внаслідок цього, зіткнувшись з перерахованими вище складнощами, вони виявляються непідготовленими до них, і це найчастіше призводить до непереборним труднощам при спробах досягти компромісу між правильністю, зручністю супроводу, продуктивністю, можливістю розширення, ефективністю і практичністю

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

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*