
- •Розділ 1. Системи підтримки прийняття рішень
- •Задачі систем підтримки прийняття рішень
- •База даних - основа сппр
- •Неефективність використання oltp-систем для аналізу даних
- •Розділ 2. Сховище даних
- •2.1. Концепція сховища даних
- •2.2. Організація сд
- •2.3. Очищення даних
- •2.4. Концепція сховища даних і аналіз
- •4.1. Видобуток даних - Data Mining
- •4.2. Завдання Data Mining
- •4.2.1. Data Mining Класифікація задач
- •4.2.2. Задача класифікації і регресії
- •4.2.3. Завдання пошуку асоціативних правил
- •4.2.4. Задача кластеризації
- •4.3. Практичне застосування Data Mining
- •4.3.1. Інтернет-технології
- •4.3.2. Торгівля
- •4.3.3. Телекомунікації
- •4.3.4. Промислове виробництво
- •4.3.5. Медицина
- •4.3.6. Банківська справа
- •4.3.7. Страховий бізнес
- •4.3.8. Інші області застосування
- •4.4. Моделі Data Mining
- •4.4.1. Предбачувальні моделі
- •4.5. Методи Data Mining
- •4.5.1. Базові методи
- •4.5.3. Генетичні алгоритми
- •4.5.4. Нейронні мережі
- •4.6. Процес виявлення знань
- •4.6.1. Основні етапи аналізу
- •4.6.2. Підготовка вихідних даних
- •4.7. Засоби Data Mining
Неефективність використання oltp-систем для аналізу даних
Практика використання OLTP-систем показала неефективність їх застосування для повноцінного аналізу інформації. Такі системи достатньо успішно вирішують задачі збору, зберігання та пошуку інформації, але вони не задовольняють вимоги, що висуваються до сучасних СППР. Підходи, повязані з зростанням функціональності OLTP-систем, не дали задовільних результатів. Основною причиною невдач є протиріччя вимог, що висуваються до СППР і OLTP. Розбіжності між цими системами наведені в таблиці. 1.1.
Таблиця 1.1
Характеристика |
Вимоги до OLTP-системи |
Вимоги до системи аналізу |
Степінь деталізації даних, що зберігаються |
Зберігання лише деталізованих даних |
Зберігання як деталізованих, так і узагальнених даних |
Якість даних |
Допускаються неправильні дані за рахунок помилок при введенні |
Не допускається помилки в даних |
Формат зберігання даних |
Може містити дані в різних форматах в залежності від додатків |
Єдиний погоджений формат зберігання даних |
Допущення надлишкових даних |
Повинна забезпечуватись максимальна нормалізація |
Допускається контролююча денормалізація (надлишковість) для ефективного видобування даних |
Управління даними |
Має бути можливість в будь який час додати, видалити чи змінити дані |
Має бути можливість періодично додавати дані |
Кількість даних, що зберігаються |
Мають бути доступні всі оперативні дані, необхідні в даний момент |
Повинні бути доступні всі дані, накопичені протягом тривалого часу |
Характер запитів до даних |
Доступ до даних користувачем здійснюєтьмся по раніше встановлених запитах |
Запити до даних можуть бути довільні і раніше не сформовані |
Час обробки звернень до даних |
Час відгуку системи вимірюється в секундах |
Час відгуку системи може бути декілька хвилин |
Характер обчислювальної нагрузки на систему |
Постійно середнє завантаження процесора |
Завантаження процесора формується лише при виконанні запиту, але на 100% |
Пріорітетність характеристик системи |
Основними пріорітетами є висока продуктивність і доступність |
Пріорітетними є забезпечення гнучкості системи і незалежність роботи користувачів. |
Давайте подивимося на вимоги до OLTP і СППР більш детально
Ступінь деталізації даних, що зберігаються. Типовий запит в OLTP-системі, як правило, вибірково впливає на окремі записи у таблиці, які ефективно видобуваються за допомогою індексів. У системах аналізу, навпаки, необхідно виконувати запити безпосередньо над великою кількістю даних з широким застосуванням групувань і узагальнень (сума, агрегація і т. д.).
Наприклад, у стандартних системах складського обліку найчастіше виконуються операції обчислення поточної кількості певного товару на складі, продажу та оплати товарів покупцями і т. д. В системах аналізу виконуються запити, пов'язані з визначення загальної вартості товарів, що зберігаються на складі, категорії товарів, які користуються найбільшим і найменшим попитом, узагальнення по категоріях і підсумовування по всіх продажах товарів тощо.
Якість даних. OLTP-системи, як правило, зберігають інформацію, яка вводиться безпосередньо користувачами системи (операторами ЕОМ). Наявність "людського фактору" при введенні підвищує шанси на помилкові дані і може створити локальні проблеми в системі. Аналіз помилкових даних може призвести до неправильних висновків і прийняття неправильних стратегічних рішень.
Формат зберігання даних. OLTP-системи, які обслуговують різні напрямки роботи, не пов'язані між собою. Вони часто реалізуються на різних програмно-апаратних платформах. Ті самі дані у різних базах даних можуть бути представлені в різній формі і можуть не співпадати (наприклад, дані про клієнта, який співпрацював з різними відділами компанії, можуть не співпадати в базах даних цих відділів). В процесі аналізу така відмінність форматів значно ускладнює спільний аналіз цих даних. Таким чином, до систем аналізу висувається вимога єдиного формату. Як правило, це необхідно, щоб цей формат був оптимізований для аналізу даних (часто за рахунок їх надлишковості).
Допущення надлишкових даних. Структура бази даних, що обслуговує OLTP-систему, як правило, досить складна. Вона може містити десятки і навіть сотні таблиць, які посилаються одна на одну. Дані в такій БД сильно нормалізовані для оптимізації займаних ресурсів. Аналітичні запити до БД дуже складно формуються і вкрай неефективно виконуються, оскільки містять в собі представлення, що об’єднує велику кількість таблиць. При проектуванні систем аналізу стараються максимально спростити схему БД і зменшити кількість таблиць, що беруть участь у запитах. Для цього часто роблять денормалізацію (надлишковість даних) БД.
Керування даними. Основні вимоги до OLTP-системи — забезпечити виконання операцій модифікації над БД. При цьому передбачається, що вони повинні виконуватись в реальному режимі, і часто дуже інтенсивно. Наприклад, при оформленні роздрібних продаж в систему вводяться відповідні документи. Очевидно, що інтенсивність вводу залежить від інтенсивності покупок і у випадку ажіотажу буде дуже високою, а будь-яка затримка веде до втрати клієнта. На відміну від OLTP-систем дані в системах аналізу рідко змінюється. Потрапивши один раз у систему, дані практично не змінюється. Введення нових даних, як правило, має епізодичний характер і виконується у період низької активності системи (наприклад, один раз на тиждень по вихідних).
Кількість збережених даних. Як правило, системи аналізу призначені для аналізу тимчасових залежностей, тоді як ОЄТР-системі зазвичай мають справу з поточними значеннями яких-небудь параметрів. Наприклад, типовий складський додаток OLTP оперує з поточними залишками товару на складі, тоді як в системі аналізу може потрібно аналіз динаміки продажів товару. З цієї причини в OLTP-системах допускається зберігання даних за невеликий період часу (наприклад, за останній квартал). Для аналізу даних, навпаки необхідні зведення за максимально великий інтервал часу.
Характер запитів до даних. У OLTP-системах із-за нормалізації БД складання запитів є досить складною роботою і вимагає необхідної кваліфікації. Тому для таких систем заздалегідь складається деякий обмежений набір статичних запитів до БД, необхідний для роботи з системою (наприклад, наявність товару на складі, розмір заборгованості покупців і т. п.). Для СППР неможливо заздалегідь визначити необхідні запити, тому до них пред'являється вимога забезпечити формування довільних запитів до БД аналітиками.
Час обробки звернень до даних. OLTP-системі, як правило, працюють в режимі реального часу, тому до них пред'являються жорсткі вимоги по обробці даних. Наприклад, час введення документів продажу товарів (витратних накладних) і перевірки наявності товару, що продається, на складі має бути мінімальне, оскільки від цього залежить час обслуговування клієнта. У системах аналізу, в порівнянні з OLTP, зазвичай висувають значно менш жорсткі вимоги до часу виконання запиту. При аналізі даних аналітик може витратити більше часу для перевірки своїх гіпотез. Його запити можуть виконуватися в діапазоні від декількох хвилин до декількох годин.
Характер обчислювального навантаження на систему. Як вже наголошувалося раніше, робота з OLTP-системами, як правило, виконується в режимі реального часу. У зв'язку з цим такі системи навантажені рівномірно протягом всього інтервалу часу роботи з ними. Документи продажу або приходу товару оформляються в загальному випадку постійно протягом всього робочого дня. Аналітик при роботі з системою аналізу звертається до неї для перевірки деяких своїх гіпотез і отримання звітів, графіків, діаграм і тому подібне. При виконанні запитів міра завантаження системи висока, оскільки обробляється велика кількість даних, виконуються операції підсумовування, групування і тому подібне Таким чином, характер завантаження систем аналізу є піковим. На рис. 1.3 приведені дані фірми Oracle, що відображають завантаження процесора протягом дня, для систем OLTP, на рис. 1.4 — для систем аналізу.
Рис. 1.3. Завантаження процесора для систем OLTP Рис. 1.4. Завантаження процесора для систем
анализу
Пріоритетність характеристик системи. Для ОLТР-систем пріоритетною є висока продуктивність і доступність даних, оскільки робота з ними ведеться в режимі реального часу. Для систем аналізу пріоритетнішими є завдання забезпечення гнучкості системи і незалежності роботи користувачів, тобто те, що необхідне аналітикам для аналізу даних. Суперечність вимог до OLTP-систем і систем, орієнтованих на глибокий аналіз інформації, ускладнює завдання їх інтеграції як підсистем єдиної СППР. В даний час найбільш популярним вирішенням цієї проблеми є підхід, орієнтований на використання концепції сховищ даних. Загальна ідея сховищ даних полягає в розділенні БД для OLTP-систем і БД для виконання аналізу і подальшому їх проектуванні з врахуванням відповідних вимог.
Висновки
З матеріалу, викладеного в даній главі, можна зробити наступні виcновки.
СППР вирішують три основні завдання: збір, зберігання і аналіз інформації, що зберігається. Завдання аналізу в загальному вигляді може включати: інформаційно-пошуковий аналіз, оперативно-аналітичний аналіз і інтелектуальний аналіз.
Підсистеми збору, зберігання інформації і вирішення завдань інформаційно-пошукового аналізу в даний час успішно реалізуються в рамках ІСР засобами СУБД. Для реалізації підсистем, що виконують оперативно-аналітичний аналіз, використовується концепція багатовимірного представлення даних (OLAP). Підсистема інтелектуального аналізу даних реалізує методи і алгоритми Data Mining.
Історично виділяють три основні структури БД: ієрархічну, мережеву і реляційну. Перші дві не знайшли широкого вживання на практиці. В даний час переважна більшість БД реалізують реляційну структуру представлення даних.
Основний недолік реляційних БД полягає в неможливості обробки інформації, яку не можна представити в табличному вигляді. У зв'язку з цим пропонується використовувати реляційні для поста моделі, наприклад об'єктно-орієнтовані.
Для спрощення розробки прикладних програм, що використовують БД, створюються системи управління базами даних (СУБД) — програмне забезпечення для управління даними, їх зберігання і безпеки даних.
В СУБД розвинений механізм управління транзакціями, що зробило їх основним засобом створення систем оперативної обробки транзакцій (OLTP -систем). До таких систем відносяться перші СППР, вирішальні завдання інформаційно-пошукового аналізу, — ІСР.
OLTP-системі не можуть ефективно використовуватися для вирішення завдань оперативно-аналітичного і інтелектуального аналізу інформації. Основна причина полягає в суперечності вимог до OLTP -системі і до СППР.
В даний час для об'єднання в рамках однієї системи oltp-підсистем і підсистем аналізу використовується концепція сховищ даних. Загальна ідея полягає у виділенні БД для OLTP -підсистем і БД для виконання аналізу.