Неефективність використання OLTP-систем для аналізу даних
Розділ 1. Системи підтримки прийняття рішень
Задачі систем підтримки прийняття рішень
З появою перших ЕОМ почалась інформатизація різних сторін людської діяльності. Якщо раніше люди основну увагу приділяли речовині, а потім енергії (рис. 1.1), то сьогодні можна без перебільшення припустити, що настав етапі реалізації процесів, пов'язаних з інформацією. Обчислювальна техніка створювалась насамперед для обробки даних. В наш час сучасні обчислювальні системи та комп'ютерні мережі дозволяють накопичувати великі масиви даних для розвязку задач обробки та аналізу. На жаль, сама по собі машинна форма представлення даних містить інформацію, необхідну для людини, в прихованому виді, і для її отримання необхідно використовувати спеціальні методи аналізу даних.
Великий обсяг інформації, з одного боку, дозволяє отримати більш точні обчислення та аналіз, з іншого боку – перетворює пошук розв’язку у важку задачу. Не дивно, що первинний аналіз даних був перекладений на комп'ютері. В результаті з’явився цілий клас програмних систем, які спрямовані на полегшення роботи людей, що проводять аналіз (аналітиків). Такі системи називаються системами підтримки прийняття рішень СППР (DSS, Decision Support System).
Для виконання аналізу СППР повинна накопичувати інформацію, маючи засоби її вводу та зберігання. Існують три основні задачі, що розвязуються в СППР:
· введення даних;
|
|
|
· зберігання даних;
· аналіз даних.
Рис. 1.1. Рівень використання людиною різних об’єктів матеріального світу
Таким чином, СППР — це системи, що володіють засобами вводу, збереження і аналізу даних, які відносяться до конкретної предметної області, з метою пошуку рішень.
Введення даних у СППР реальізується або автоматично від датчиків, що характеризують стан навколишнього середовища чи процес, або людиною-оператором. У першому випадку дані накопичуються шляхом циклічного опитування чи по сигналу готовності, що виникає при появі інформації. У другому випадку СППР повинні надати користувачам зручні засоби вводу даних, які контролюватимуть коректність вводу даних і виконуватимуть пов'язані з ними розрахунки. Якщо введення здійснюється одночасно кількома операторами, то система повинна розв’язати проблему паралельного доступу і модифікації тих самих даних.
Постійне накопичення даних призводить до постійного збільшення їх обсягу. У зв’язку з цим задачею СППР є забезпечення надійного зберігання великого обсягу даних. На СППР також можуть бути покладені задачі запобігання несанкціонованого доступу, резервного зберігання, архівування і т.д.
Основною задачею СППР є надання аналітикам інструменту для виконання аналізу даних. Слід зазначити, що для ефективного використання СППР її користувач-аналітик повинен мати відповідну кваліфікацію. Система не генерує правильне рішення, а лише представляє аналітику дані у відповідному вигляді (звіти, таблиці, діаграми, тощо.) для вивчення і аналізу, саме тому такі системи забезпечують виконання функції підтримки прийняття рішень. Очевидно, що, з одного боку, якість прийнятих рішень залежить від кваліфікації аналітика. З іншого боку, зростання обсягів даних, що аналізуються, висока швидкість обробки та аналізу, а також складність використання машинного представлення даних стимулює дослідження і розробку інтелектуальних СППР. Для таких СППР храктерна наявність функцій, що реалізують окремі розмовні можливості людини.
|
|
|
За ступенем "інтелектуальності" обробки даних при аналізі виділяють три класи задач аналізу:
· інформаційно-пошуковий — СППР реалізує пошук потрібних даних. Характерною рисою такого аналізу є виконання заздалегідь визначених запитів;
· оперативно-аналітичний — СППР робить групування та узагальнення даних в будь-якій формі, необхідній аналітику. На відміну від інформаційно-пошукового аналізу в даному випадку неможливо передбачити запити, необхідні аналітику;
|
|
|
· інтелектуальний — СППР реалізує пошук функціональних і логічних закономірностей в накопичених даних, побудову моделей і правил, які пояснюють знайдені закономірності та/або прогнозують розвиток деяких процесів (з певною ймовірністю).
Таким чином, загальна архітектура СППР може бути представлена наступним чином (рис. 1.2).
Рис. 1.2. Узагальнена архітектура системи підтримки прийняття рішень
Розглянемо окремі підсистеми більш детально.
· Підсистема введення даних. В таких підсистемах, відомих як OLTP (On-line transaction processing), виконуються операційна (транзакційна) обробка даних. Для реалізації цих підсистем використовують звичайні системи керування базами даних (СКБД).
· Підсистема зберігання. Для реалізації цієї підсистеми використовують сучасні СКБД і концепцію сховищ даних.
· Підсистеми аналізу. Ця підсистема може бути побудована на основі:
підсистеми інформаційно-пошукового аналізу на основі реляційних СКБД і статичних запитів з використанням мови структурованих запитів SQL (Structured Query Language);
підсистеми оперативного аналізу. Для реалізації таких підсистеми застосовуються технології оперативної аналітичної обробки даних OLAP (On-line analytical processing), що використовує концепцію багатовимірного представлення даних:
|
|
|
підсистеми інтелектуального аналізу. Ця підсистема реалізує методи і алгоритми Data Mining («видобуток даних»).
База даних - основа СППР
Раніше було відзначено, що для розвязку задач аналізу даних і пошуку рішень необхідно накопичення та збереження великого обсягу даних. Для цих цілей служать бази даних (БД).
Увага! База даних є моделлю деякої предметної області, яка складається з пов'язаних між собою даних про об'єкти, їх властивості і характеристики.
Інструменти для роботи з базами даних представляють СКБД. Не розв’язуючи безпосередньо ніяких прикладних задач, СКБД є інструментом для розробки прикладних програм, що використовуються БД.
Для зберігання даних, відповідно до моделі предметної області, структура БД повинна максимально відповідати цій моделі. Першою такою стуртурою, використовуваною в СКБД, була ієрархічна структура, яка появилась на початку 60-х років минулого століття.
Ієрархічна структура передбачала зберігання даних у вигляді дерева. Це значно спрощувало створення і підтримку такої БД. Але неможливість представлення багатьох об’єктів реального світу у виггляді ієрархії призвела до використання таких баз даних у вузькоспеціалізованих сферах. Типовим представником (найбільш відомих і поширеним) ієрархічної СКБД є Information Management System (ІMS) фірми IBM. Перша версія цього продукту з'явився в 1968 році.
Спробою покращити ієрархічну структуру була мережева структура БД, яка передбачає представлення даних у вигляді мережі. Вона заснована на пропозиціях групи Data Base Task Group (DBTG) Комітету по мовах програмування Conference on Data System Languages (CODASYL). Звіт DBTG був опублікований в 1971 році.
Робота з мережевими БД представляє більш складний процес, ніж робота з ієрархічною БД, тому ця структура не знайшла широкого застосування на практиці. Типовим представником мережевих СКБД є Integrated Database Management System (IDMS) компанії Cullinel Software, Inc.
Найбільш поширеними в наш час є реляційні бази даних. Термін "реляційний" походить від латинського слова "relatio" - відношення. Така структура зберігання даних побудована на взаємовідношенні складових її частин. Реляційний підхід став широко відомий завдяки роботам Е.Кодда, які вперше були опубліковані в 1970 році.В них Кодд сформулював наступні 12 правил для реляційної бази даних:
1. Дані представляються у вигляді таблиці. БД представляють собою набір таблиць. Таблиці зберігають дані, згруповані у вигляді рядків та стовпців. Ряд це набір значень, які відносяться лише до одного об'єкту, що зберігається в таблиці, і називається записом. Стовпець представляє собою одну характеристику для всіх об'єктів, які зберігаються в таблиці, і називається полем. Комірка на перетині рядка і стовпця — це значення характеристики відповідного стовпця для обєкта відповідного рядка.
2. Дані доступні логічно. Реляційна модель не дозволяє звертатись до даних фізично, адресуючи комірки по номерах стовпця і рядка (нема можливості отримати значення в комірці (стовпець 2, рядок 3)). Доступ до даних можливий лише через ідентифікатори таблиці, стовпця і рядка. Ідентифікаторами таблиці і стовпця є їх імена. Вони повинні бути унікальними в межах, відповідно, БД і таблиці. Ідентифікатором рядка є первинний ключ — це значення одого чи кілька стовпців, які однозначно ідентифікують рядки. Кожне значення первинного ключа в межах таблиці повинно бути унікальними. Якщо ідентифікація рядка проводиться на основі значень декількох стовпців, то ключ називається складеним.
3. NULL розглядається як невідоме значення. Якщо в комірку таблиці значення не введено, то записується значення NULL. Це не потрібно плутати з порожньою стрічкою чи зі значення 0.
4. БД повинна включати в себе метадані. База даних зберігає два типи таблиць: користувацькі та системні. У таблицях користувача зберігаються дані, введенні користувачем. В системних таблицях зберігаються метадані: опис таблиці (назва, типи і розміри стовпців), індекси, збережені процедури та інше. Системні таблиці також доступні, тобто користувач може отримати інформацію про метадані бази даних.
5. Повинна використовуватись єдина мова для взаємодії з СКБД.Для керування реляційними базами даних потрібно використовувати спільну мову. В даний час таким інструментом стала мова SQL.
6. СКБД повинна забузпечувати альтернативний вигляд даних. СКБД не має обмежувати користувача лише відображенням таблиць, які існують. Користувач повинен мати можливість побудувати віртуальні таблиці - перегляди (View). Представлення - це динамічне групування декількох таблиць. Зміни даних у представленні повинні автоматично переноситись на вихідні таблиці (за винятком полів, які не редагуються, наприклад, обчислюваних полів).
7. Повинні підтримуватись операції реляційної алгебри. Записи реляційної бази даних розглядатимуться як елементи множини, в якій визначені операції реляційнійної алгебри. СКБД повинна забезбечити виконання цих операцій. В даний час виконання цього правила забезпечує мова SQL.
8. Повинна забезпечуватись незалежність від фізичної організації даних. Додатки, які працюють з даними реляційних БД, не повинні залежати від фізичного сховища даних (від способу зберігання, формату зберігання, тощо).
9. Повинна забезпечуватись незалежність від логічної організації даних. Додатки, які працюють з даними реляційних БД, не повинні залежати від організації звязків між таблицями (логічної організації). При зміні зв'язків між таблицями, самі таблиці, а також запити до них, мінятись не повинні.
10. За цілісність даних відповідає СКБД. Під цілісністю даних в загальному випадку розуміється готовність БД до роботи.
Існують такі типи цілісності:
• фізична цілісність — збереження інформації на носіях і коректність формату зберігання даних;
• логічна цілісність — несуперечність та актуальність даних, що зберігаються в базі даних.
Втрата цілісності бази даних може відбутися через збій апаратури ЕОМ, наявність помилок в програмному забезпеченні, неправильність технологій введення та корекції даних, низька достовірність даних і так далі.
За збереження цілісності даних повинна відповідати СКБД, а не додатки, що оперують ними. Є два шляхи забезпечення цілісності: декларативний та процедурний. При декларативному способі цілісність досягають шляхом накладання обмежень на таблиці, при процедурному – цілісність забезпечують за допомогою процедур, збережених в базі даних.
11. Цілісність даних не може бути порушена. СКБД повинна забезпечувати цілісність даних при будь яких маніпуляціях, що відбуваються з ними.
12.Повинні підтримуватись розподілені операції. Реляційна БД може бути розміщена як на одному комп'ютері, так і на декількох — розподілено. Користувач повинен мати можливість зв'язати дані, розташовані в різних таблицях і на різних вузлах компютерної мережі. Цілісність БД повинна забезпечуватись незалежно від місця збереження даних.
На практиці, крім перерахованих правил існує також вимога мінімізації пам'яті, що використовується для бази даних. Це досягається шляхом створення структури бази даних, при якій повторювання (надлишковість) інформація буде зведено до мінімуму. Щоб задовільнити цю вимогу була розроблена теорія нормалізації. Вона включає в себе кілька рівнів нормалізація баз даних, кожен з яких базується на попередньому. Кожному рівню нормалізації відповідає певна нормальна форма (НФ). Залежно від умов, які задовольняє БД, можна сказати, що вона має відповідну нормальну форму. Наприклад:
· БД має першу НФ, якщо кожне значення, що зберігається в ній, нероздільне до більш примітивного (нероздільність значень);
· БД має другу НФ, якщо вона має першу НФ, і при цьому кожне значення цілком і повністю залежить від ключа (функціонально незалежні значення);
· БД має третю НФ, якщо вона має другу НФ, і при цьому жодне значення не надає будь-яку інформацію про інші значення (взаємно незалежні значення), тощо.
На завершення опису реляційної моделі, важливо зазначити, що вона має суттєвий недолік. Справа в тому, що не кожен тип даних може бути представлений у вигляді таблиці, наприклад, зображення, музика, тощо. Однак, в даний час для зберігання такої інформації у реляційних СКБД була спроба використовувати спеціальні типи полів - BLOB (Binary Large OBjects). В них зберігається посилання на відповідну інформацію, яка не включається в БД. Проте, такий підхід не дозволяє оперувати інформацією, яка не розміщена в базі даних, що обмежує можливості по її використанню.
Для збереження такого роду інформації пропонується використовувати постреляційніі моделі у вигляді об'єктно-орієнтованих структур зберігання даних. Загальний підхід поялягає у зберігання будь-якої інформації у вигляді об’єктів. При цьому самі об'єкти можуть бути організовані в рамках ієрархічної моделі. На жаль, такий підхід, на відміну від реляційної структури, яка базується на реляційній алгебрі, є недостатньо формалізований, і це не дозволяє широко використовувати його на практиці.
Відповідно до правил Кодда СКБД повинна забезпечувати виконання операцій над БД, забезпечуючи при цьому можливість одночасної роботи кількома користувачами (з кількох комп'ютерів) і гарантуючи цілісність даних. Для дотримання цих правил в СКБД використовується механізм керування транзакціями.
Увага!
Транзакція – це послідовність операцій, які виконуються над БД, що розглядаються СКБД як єдине ціле. Транзакціz переводить БД з одного цілісного стану в інший.
Зазвичай, транзакція складається з операцій, що маніпулюють даними, які належать до різних таблиць і логічно пов'язані один з одним. Якщо під час проведення транзакції будуть виконані операції, які змінюють лише частину даних,а інші дані не буде змінена, то цілісність буде порушено. Таким чином, або усі операції транзакції повинні виконуватися, або не виконується жодна. Процес скасування виконання транзакції називається відкатом транзакції (ROLLBACK). Збереження змін, внесених в результаті здійснення операції транзакції, називається фіксацією транзакції (COMMIT).
Властивість транзакцію переводити БД з одного цілісного стану в інший дозволяє використовувати поняття транзакції як одиницю діяльності користувача. У разі одночасного звернення користувачів до БД транзакції, що ініціюються різними користувачами, виконуються не паралельно (що неможливо для однієї БД), а у відповідності до певного плану ставляться в чергу і виконуються послідовно. Таким чином, для користувача, за ініціативою якого сформована транзакція, присутність транзакцій інших користувачів буде незамітною, якщо не зважати на деякі сповільнення роботи в порівнянні з однокористувацьким режимом.
Є кілька базових алгоритмів планування черги транзакцій. У централізованих СКБД найпоширенішим є алгоритм на основі синхронізованих захватів об'єктів БД. При використанні будь якого алгоритму можливі конфлікти між двома чи більше транзакціями з доступу до БД. В такому випадку для підтримки плану необхідно виконуати відкат однієї чи більше транзакцій. Це одним з випадків, коли користувач багатокористувацької СКБД може дійсно відчути присутність в системі транзакцій інших користувачів.
Історія розвитку СКБД тісно пов'язана з удосконаленням підходів до розв’язку задач збереження даних і управління транзакціями. Розвинутий механізм управління транзакціями в сучасних СКБД зробив їх основним засобом побудови систем OLTP, основним завданням яких є забезпечення виконання операцій з базами даних.
OLTP-системи оперативної обробки транзакцій характеризуються великою кількістю змін, одночасним зверненням багатьох користувачів до одних і тих же даних для виконання різноманітних операцій — читання, запису, видалення чи модифікації даних. Для нормальної роботи великої кількості користувачів застосовуються блокування та транзакції. Ефективна обробка транзакцій і підтримка блокувань входять в число найбільш важливих вимог до систем оперативної обробки транзакцій.
До цього класу систем відносяться і перші СППР — інформаційні системи управління (ІСУ, Executive Information System). Такі системи, як правило, засновані на реляційних СКБД, включають в себе підсистеми збору, зберігання та інформаційно-пошукового аналізу інформації, а також містить в собі наперед визначений набір запитів для повсякденної роботи. Кожен новий запит, непередбачений при проектуванні такої системи, повинен спочатку бути формально описаний, закодований програмістом, і лише тоді виконаний. Час очікування в такому випадку може складатись з кількох годин або днів, що неприйнятно для оперативного прийняття рішень.
Неефективність використання 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 -підсистем і БД для виконання аналізу.
Розділ 2. Сховище даних
Концепція сховища даних
Прагнення об'єднати в одній архітектурі СППР можливості oltp-систем і систем аналізу, вимоги до яких багато в чому, як випливає з таблиці 1.1, суперечливі, привело до появи концепції сховища даних (СД).
Концепція СД так чи інакше обговорювалася фахівцями в області інформаційних систем досить давно. Перші статті, присвячені саме СД, з'явилися в 1988 р., їх авторами були Б. Девлін і П. Мерфі. У 1992 р. У.Інмон детально описав дану концепцію в своїй монографії "Побудова сховищ даних" ("Building the Data Warehouse", second edition — QED Publishing Group, 1996).
У основі концепції СД лежить ідея розділення даних, що використовуються для оперативної обробки і для вирішення завдань аналізу. Це дозволяє застосовувати структури даних, які задовольняють вимогам їх зберігання з врахуванням використання в OLTP-системах і системах аналізу. Такий поділ дозволяє оптимізувати як структури даних оперативного зберігання (оперативні БД, файли, електронні таблиці і т. д.) для виконання операцій введення, модифікації, видалення і пошуку, так і структури даних, які використовуються для аналізу (для виконання аналітичних запитів). У СППР ці два типи даних називаються відповідно оперативними джерелами даних (ОДД) і сховищем даних.
У своїй роботі Інмон дав наступне визначення СД. Увага!
Сховище даних — предметно-орієнтований, інтегрований, немінливий, підтримуючий хронологію набір даних, організований для цілей підтримки ухвалення рішень.
Розглянемо властивості СД детальніше.
· Предметна орієнтація. Це фундаментальна відмінність СД від ОДД. Різні ОДД можуть містити дані, що описують одну і ту ж предметну область з різних точок зору (наприклад, з точки зору бухгалтерського обліку, складського обліку, планового відділу і т. д.). Рішення, прийняте на основі лише однієї точки зору, може бути неефективним або навіть невірним. СД дозволяють інтегрувати інформацію, що відображає різні точки зору на одну предметну область.
Предметна орієнтація дозволяє також зберігати в СД лише ті дані, які потрібні для їх аналізу (наприклад, для аналізу немає сенсу зберігати інформацію про номери документів купівлі-продажу, тоді як їх вміст — кількість, ціна проданого товару — необхідно). Це істотно скорочує витрати на носії інформації і підвищує безпеку доступу до даних.
· Інтеграція. ОДД, як правило, розробляються в різний час декількома колективами з власним інструментарієм. Це приводить до того, що дані, що відображають той самий об'єкт реального світу в різних системах, описують його по-різному. Обов'язкова інтеграція даних в СД дозволяє вирішити цю проблему, зводячи дані до єдиного формату.
· Підтримка хронології. Дані в ОДД необхідні для виконання над ними операцій у даний момент часу. Тому вони можуть не мати прив'язки до часу. Для аналізу даних часто буває важливо мати можливість відстежувати хронологію змін показників предметної області. Тому всі дані, що зберігаються в СД, повинні відповідати послідовним інтервалам часу.
· Незмінність. Вимоги до ОДД накладають обмеження на час зберігання в них даних. Ті дані, які не потрібні для оперативної обробки, як правило, видаляються з ОДД для зменшення займаних ресурсів. Для аналізу, навпаки, потрібні дані за максимально великий період часу. Тому, на відміну від ОДД, дані в СД після завантаження лише читаються. Це дозволяє істотно підвищити швидкість доступу до даних, як за рахунок можливої надмірності інформації, що зберігається, так і за рахунок виключення операцій модифікації.
При реалізації в СППР концепції СД дані з різних ОДД копіюються в єдине сховище. Зібрані дані зводяться до єдиного формату, узгоджуються і узагальнюються. Аналітичні запити адресуються до СД (рис. 2.1).
Така модель неминуче приводить до дублювання інформації в ОДД і в СД. Проте Інмон в своїй роботі стверджує, що надмірність даних, що зберігаються в СППР, не перевищує 1 %! Це можна пояснити наступними причинами. При завантаженні інформації з ОДД в СД дані фільтруються. Багато з них не потрапляє в СД, оскільки позбавлені сенсу з точки зору використання в процедурах аналізу.
Інформація в ОДД носить, як правило, оперативний характер, і дані, втративши актуальність, видаляються. У СД, навпаки, зберігається історична інформація. З цієї точки зору дублювання вмісту СД даними ОДД є вельми незначним. У СД зберігається узагальнена інформація, яка в ОДД відсутня.
Під час завантаження в СД дані очищаються (видаляється непотрібна інформація), і після такої обробки вони займають набагато менший об'єм.
Рис. 2.1. Структура СППР з фізичним СД
Надмірність інформації можна звести до нуля, використовуючи віртуальне СД. В даному випадку на відміну від класичного (фізичного) СД дані з ОДД не копіюються в єдине сховище. Вони витягуються, перетворюються і інтегруються безпосередньо при виконанні аналітичних запитів в оперативній пам'яті комп'ютера. Фактично такі запити безпосередньо адресуються до ОДД (рис. 2.2). Основними перевагами віртуального СД є:
· Мінімізація об'єму пам'яті, займаної на носієві інформацією;
· Робота з поточними, деталізованими даними.
Рис. 2.2 Структура СППР з віртуальним СД
Проте такий підхід має багато недоліків.
Час обробки запитів до віртуального СД значно перевищує відповідні показники для фізичного сховища. Крім того, структури оперативних БД, розраховані на інтенсивне оновлення одиночних записів, вищою мірою нормалізовані. Для виконання аналітичного запиту потрібне об'єднання великого числа таблиць, що також призводить до зниження швидкодії.
Інтегрований погляд на віртуальне сховище можливий лише при виконанні умови постійної доступності всіх ОДД. Таким чином, тимчасова недоступність хоч би одного з джерел може призвести або до невиконання аналітичного запиту, або до невірних результатів. Виконання складних аналітичних запитів над ОДД вимагає значних ресурсів комп'ютерів. Це призводить до зниження швидкодії ОLTP-систем, що недопустимо, оскільки час виконання операцій в таких системах часто вельми критичний.
Різні ОДД можуть підтримувати різні формати і кодування даних. Часто на одне і те ж питання може бути отримане декілька варіантів відповіді. Це може бути пов'язано з несинхронним оновленням даних в різних ОДД, відмінностями в описі однакових об'єктів і подій предметної області, помилками при введенні, втратою фрагментів архівів і так далі. В такому випадку мета — формування єдиного несуперечливого погляду на об'єкт управління — може бути не досягнута.
Головним же недоліком віртуального сховища слід визнати практичну неможливість отримання даних за довгий період часу. За відсутності фізичного сховища доступні лише ті дані, які на момент запиту є в ОДД. Основне призначення ОLТР-систем — оперативна обробка поточних даних, тому вони не орієнтовані на зберігання даних за тривалий період часу. У міру застарівання дані вивантажуються в архів і видаляються з оперативної БД.
Не дивлячись на переваги фізичного СД перед віртуальним, необхідно визнати, що його реалізація є досить трудомістким процесом. Зупинимося на основних проблемах створення СД:
· необхідність інтеграції даних з неоднорідних джерел в розподіленому середовищі;
· потреба в ефективному зберіганні і обробці дуже великих об'ємів інформації;
· необхідність наявності багаторівневих довідників метаданих;
· підвищені вимоги до безпеки даних.
Розглянемо ці проблеми детальніше.
Необхідність інтеграції даних з неоднорідних джерел в розподіленому середовищі. СД створюються для інтеграції даних, які можуть поступати з різнорідних ОДД, що фізично розміщуються на різних комп'ютерах: БД, електронних архівів, публічних і комерційних електронних каталогів, довідників, статистичних збірок. При створенні СД доводиться вирішувати задачу побудови системи, що погоджено функціонує з неоднорідними програмними засобами і рішеннями. При вибиранні засобів реалізації СД доводиться враховувати безліч чинників, що включають рівень сумісності різних програмних компонентів, легкість їх освоєння і використання, ефективність функціонування і т. д.
Потреба в ефективному зберіганні і обробці дуже великих об'ємів інформації. Властивість незмінності СД передбачає накопичення в ньому інформації за довгий період часу, що повинне підтримуватися постійним зростанням об'ємів дискової пам'яті.
Орієнтація на виконання аналітичних запитів і пов'язана з цим денормалізація даних приводять до нелінійного зростання об'ємів пам'яті, займаною СД при зростанні об'єму даних. Дослідження, проведені на основі тестового набору ТРС-С, показали, що для баз даних об'ємом в 100 Гбайт потрібна пам'ять, в 4,87 разу більша об'ємом, ніж потрібно для зберігання корисних даних.
Необхідність багаторівневих довідників метаданих. Для систем аналізу наявність розвинених метаданих (даних про дані) і засобів їх надання кінцевим користувачам є одним з основних умов успішної реалізації СД. Метадані необхідні користувачам СППР для розуміння структури інформації, на підставі якої приймається рішення. Наприклад, перш ніж менеджер корпорації поставить системі своє питання, він повинен зрозуміти, яка інформація є, наскільки вона актуальна, чи можна їй довіряти, скільки часу може зайняти формування відповіді і так далі. При створенні СД необхідно вирішувати завдання зберігання і зручного представлення метаданих користувачам.
Підвищення вимог до безпеки даних. Зібрана разом і погоджена інформація про історію розвитку корпорації, її успіхи і невдачі, про взаємини з постачальниками і замовниками, про історію і стан ринку дає можливість аналізу минулої і поточної діяльності корпорації і побудови прогнозів для майбутнього. Очевидно, що подібна інформація є конфіденційною і доступ до неї обмежений в межах самої компанії, не кажучи вже про інші компанії. Для забезпечення безпеки даних доводиться вирішувати питання аутентифікації користувачів, захисту даних при їх переміщенні в сховищі даних з оперативних баз даних і зовнішніх джерел, захисту даних при їх передачі по мережі і тому подібне Зниження витрат на створення СД можна добитися, створюючи його спрощений варіант — вітрину даних (Data Mart).
Увага!
Вітрина даних (ВД) — це спрощений варіант СД, що містить лише тематично об'єднані дані.
ВД максимально наближена до кінцевого користувача і містить дані, тематично орієнтовані на нього (наприклад, ВД для працівників відділу маркетингу може містити дані, необхідні для маркетингового аналізу). ВД істотно менше за об'ємом, ніж СД, і для її реалізації не вимагається великих витрат. Вони можуть бути реалізовані як самостійно, так і разом з СД.
Самостійні ВД (рис. 2.3) часто з'являються в організації історично і зустрічаються у великих організаціях з великою кількістю незалежних підрозділів, які розв’язують власні аналітичні завдання. Перевагами такого підходу є:
· проектування ВД для відповідей на певне коло питань;
· швидке впровадження автономних ВД і отримання віддачі;
· спрощення процедур заповнення ВД і підвищення їх продуктивності за рахунок обліку потреб визначеного кола користувачів.
Рис. 2.3. Структура СППР з самостійними ВД
Недоліками автономних ВД є:
· багатократне зберігання даних в різних ВД, що призводить до збільшення витрат на їх зберігання і потенційних проблем, пов'язаних з необхідністю підтримки несуперечності даних;
· відсутність консолідованості даних на рівні предметної області, а отже — відсутність єдиної картини.
Останнім часом усе більш популярною стає ідея поєднати СД і ВД в одній системі. В цьому випадку СД використовується як єдине джерело інтегрованих даних для всіх ВД (Рис. 2.4).
СД є єдиним централізованим джерелом інформації для всієї предметної області, а ВД є підмножинами даних зі сховища, організованими для представлення інформації по тематичних розділах даної області. Кінцеві користувачі мають можливість доступу до детальних даних сховища, якщо даних у вітрині недостатньо, а також для отримання повнішої інформаційної картини.
Перевагами такого підходу є:
· простота створення і наповнення ВД, оскільки наповнення походить з єдиного стандартизованого надійного джерела очищених даних — із СД;
· простота розширення СППР за рахунок додавання нових ВД;
· зниження навантаження на основне СД.
Рис. 2.4. Структура СППР з СД і ВД
До недоліків відносяться:
· надмірність (дані зберігаються як в СД, так і у ВД);
· додаткові витрати на розробку СППР з СД і ВД.
Підводячи підсумок аналізу шляхів реалізації СППР з використанням концепції СД, можна виділити наступну архітектуру таких систем:
СППР з фізичним (класичним) СД (див. рис. 2.1);
СППР з віртуальним СД (див. рис. 2.2);
СППР з ВД (див. рис. 2.3);
СППР з фізичним СД і з ВД (рис. 2.4).
В разі архітектури з фізичним СД і/чи ВД необхідно приділити увагу питанням організації (архітектури) СД і перенесенню даних з ОДД в СД.
Організація СД
Всі дані в СД діляться на три основні категорії (рис. 2.5):
· детальні дані;
· агреговані дані;
· метадані.
Рис. 2.5. Архітектура СД
Детальними є дані, що переносяться безпосередньо з ОДД. Вони відповідають елементарним подіям, що фіксуються ОLТР-системами (наприклад, продажі, експерименти і ін.). Прийнято розділяти всі дані на виміри і факти. Вимірами називаються набори даних, необхідні для опису подій (наприклад, міста, товари, люди і т. п.). Фактами називаються дані, що відображають суть події (наприклад, кількість проданого товару, результати експериментів і т. п.). Фактичні дані можуть бути представлені у вигляді числових або категоріальних значень.
В процесі експлуатації СД необхідність у ряді детальних даних може знизитися. Непотрібні детальні дані можуть зберігатися в архівах в стислому вигляді на більш ємких накопичувачах з повільнішим доступом (наприклад, на магнітних стрічках). Дані в архіві залишаються доступними для обробки і аналізу. Регулярно використовувані для аналізу дані повинні зберігатися на накопичувачах з швидким доступом (наприклад, на жорстких дисках).
На підставі детальних даних можуть бути отримані агреговані (узагальнені) дані. Агрегація відбувається шляхом підсумовування числових фактичних даних по певних вимірах. Залежно від можливості агрегувати дані вони поділяються на наступні типи:
· аддитивні — числові фактичні дані, які можуть бути підсумовані по всіх вимірах;
· напіваддитивні — числові фактичні дані, які можуть бути підсумовані лише по певних вимірах;
· неаддитивні — фактичні дані, які не можуть бути підсумовані по жодному виміру.
Більшість користувачів СППР працюють не з детальними, а з агрегованими даними. Архітектура СД повинна надавати швидкий і зручний спосіб отримувати інформацію, що цікавить користувача. Для цього необхідно частину агрегованих даних зберігати в СД а не обчислювати їх при виконанні аналітичних запитів. Очевидно, що це веде до надмірності інформації і збільшенню розмірів СД. Тому при проектуванні таких систем поважно добитися оптимального співвідношення між обчислюваними агрегованими даними, що зберігаються. Ті дані, до яких рідко звертаються користувачі, можуть обчислюватися в процесі виконання аналітичних запитів. Дані, які потрібні частіше, повинні зберігатися в СД.
Для зручності роботи з СД необхідна інформація про дані, що містяться в ньому. Така інформація називається метаданими (дані про дані). Згідно концепції Дж.Захмана, метадані повинні відповідати на наступні питання — що, хто, де, як, коли і чому:
· що (опис об'єктів) — метадані описують об'єкти предметної області, інформація про які зберігається в СД. Такий опис включає: атрибути об'єктів, їх можливі значення, відповідні поля в інформаційних структурах СД, джерела інформації про об'єкти і т. д.;
· хто (опис користувачів) — метадані описують категорії користувачів, що використовують дані. Вони описують права доступу до даних, а також включають відомості про користувачів, що виконували над даними різні операції (введення, редагування, завантаження, витягування і т.д.);
· де (опис місця зберігання) — метадані описують місце розташування серверів, робочих станцій, ОДД, розміщені на них програмні засоби і розподіл між ними даних;
· як (опис дій) — метадані описують дії, що виконуються над даними. Описувані дії могли виконуватися як в процесі перенесення з ОДД (наприклад, виправлення помилок, розділення полів і т. д.), так і в процесі їх експлуатації в СД;
· коли (опис часу) — метадані описують час виконання різних операцій над даними (наприклад, завантаження, агрегація, архівація, витягування і т. д.);
· чому (опис причин) — метадані описують причини, що викликають виконання над даними тих або інших операцій. Такими причинами можуть бути вимоги користувачів, статистика звернень до даних і тому подібне
Оскільки метадані грають важливу роль в процесі роботи з СД, то до них має бути забезпечений зручний доступ. Для цього вони зберігаються в репозиторії метаданих із зручним для користувача інтерфейсом. Дані, що поступають з ОДД в СД, і переміщаються всередині СД і потрапляють з СД до аналітиків, утворюють наступні інформаційні потоки (див. рис. 2.5):
· вхідний потік (Inflow)-— утворюється даними, копійованими з ОДД в СД;
· потік узагальнення (Upflow) — утворюється агрегацією детальних даних і їх збереження в СД.
· архівний потік (Downflow) — утворюється переміщенням детальних даних, кількість звернень до яких знизилася;
· потік метаданих (Metaflow) — утворюється перенесенням інформації про дані в репозиторій даних;
· вихідний потік (Outflow) — утворюється даними, що витягуються користувачами;
· зворотний потік (Feedback Flow) — утворюється очищеними даними, які записуються назад в ОДД.
Найпотужніший з інформаційних потоків — вхідний — пов'язаний з перенесенням даних з ОДД. Зазвичай інформація не просто копіюється в СД, а піддається обробці: дані очищаються і збагачуються за рахунок додавання нових атрибутів. Вихідні дані з ОДД об'єднуються з інформацією із зовнішніх джерел — текстових файлів, повідомлень електронної пошти, електронних таблиць і ін. При розробці СД не менше 60 % всіх витрат пов'язано з перенесенням даних.
Процес перенесення, що включає етапи витягування, перетворення і завантаження, називають etl-процесом (Е — extraction, Т — transformation, L — loading: витягування, перетворення і завантаження, відповідно). Програмні засоби, що забезпечують його виконання, називаються etl-системами. Традиційно etl-системи використовувалися для перенесення інформації із застарілих версій інформаційних систем в нові. В даний час etl-процес знаходить все більше вживання для перенесення даних з ОДД в СД і ВД.
Розглянемо детальніше етапи etl-процесу (рис. 2.6). Витягання даних. Щоб почати etl-процес, необхідно витягувати дані з одного або декількох джерел і підготувати їх до етапу перетворення. Можна виділити два способи витягання даних:
1. Витягання даних допоміжними програмними засобами безпосередньо із структур зберігання інформації (файлів, електронних таблиць, БД і т. д. Перевагами такого способу витягання даних є:
• відсутність необхідності розширювати ОLТР-систему (це особливо важливо, якщо її структура закрита);
• дані можуть витягуватися з врахуванням потреб процесу перенесення.
2. Вивантаження даних засобами ОLТР-систем в проміжні структури. Перевагами такого підходу є:
• можливість використовувати засоби ОLТР-систем, адаптовані до структур даних;
• засоби вивантаження змінюються разом із змінами ОLТР-систем і ОДД;
• можливість виконання першого кроку перетворення даних за рахунок певного формату проміжної структури зберігання даних.
Рис. 2.6. etl-процес
Перетворення даних. Після того, як збір даних завершений, необхідно перетворити їх для розміщення на новому місці. На цьому етапі виконуються наступні процедури:
· узагальнення даних (aggregation) — перед завантаженням дані узагальнюються. Процедура узагальнення замінює багаточисельні детальні дані відносно невеликим числом агрегованих даних. Наприклад, передбачимо, що дані про продажі за рік займають в нормалізованій базі даних декілька тисяч записів. Після узагальнення дані перетворяться в менше число коротких записів, які будуть перенесені в СД;
· перетворення значень (value translation) — в ОДД дані часто зберігаються в закодованому вигляді для того, щоб скоротити надмірність даних і пам'ять для їх зберігання. Наприклад, назви товарів, міст, спеціальностей і тому подібне можуть зберігатися в скороченому вигляді. Оскільки СД містять узагальнену інформацію і розраховані на просте використання, закодовані дані зазвичай замінюють на зрозуміліші описи.
· створення полів (field derivation) — при створенні полів для кінцевих користувачів створюється і нова інформація. Наприклад, ОДД містить одне поле для вказування кількості проданих товарів, а друге — для вказування ціни одного екземпляра. Для виключення операції обчислення вартості всіх товарів можна створити спеціальне поле для її зберігання під час перетворення даних;
· очищення даних (cleaning) — направлена на виявлення і видалення помилок і невідповідностей в даних з метою поліпшення їх якості. Проблеми з якістю зустрічаються в окремих ОДД, наприклад, у файлах і БД можуть бути помилки при введенні, окрема інформація може бути втрачена, можуть бути присутніми "забруднення" даних і ін. Очищення також застосовується для узгодження атрибутів полів так, щоб вони відповідали атрибутам бази даних призначення.
Завантаження даних. Після того, як дані перетворені для розміщення в СД, здійснюється етап їх завантаження. При завантаженні виконується запис перетворених детальних і агрегованих даних. Крім того, при записі нових детальних даних частина старих даних може переноситися в архів.
Очищення даних
Одним з важливих завдань, що вирішується при перенесенні даних в СД, є їх очищення. З одного боку, дані завантажуються постійно з різних джерел, тому вірогідність попадання "брудних даних" вельми висока. З іншого боку, СД використовуються для ухвалення рішень, і "брудні дані" можуть стати причиною ухвалення невірних рішень. Таким чином, процедура очищення є обов'язковою при перенесенні даних з ОДД в СД. Зважаючи на великий спектр можливих невідповідностей в даних їх очищення вважається однією з найкрупніших проблем в технології СД. Основні проблеми очищення даних можна класифікувати по наступних рівнях:
· рівень елементу таблиці;
· рівень запису;
· рівень таблиці БД;
· рівень одиночної БД;
· рівень множини БД.
Розглянемо перераховані рівні і відповідні до них проблеми детальніше.
Рівень елементу таблиці. На даному рівні завдання очищення полягає в аналізі і виправленні помилок в даних, що зберігаються у вічках таблиць БД. До таких помилок можна віднести наступні.
1. Орфографічні помилки (друкарські помилки) — виникають при введенні інформації. Вони можуть призвести до неправильного розуміння, а також до спотворення реальних даних. Наприклад, при продажі товару замість кількості 1000 було введено 10 ТОВ або замість назви товару "Горілка" було введено назву "Вода".
2. Відсутність даних — такі помилки відбуваються через відсутність в оператора відповідних даних при введенні інформації. Головним завданням oltp-систем є забезпечення щоденних операцій з даними, тому оператор може пропустити введення невідомих йому даних, а не витрачати час на їх з'ясування. Як наслідок, в БД можуть залишатися незаповнені вічка (що містять значення NULL).
3. Фіктивні значення — це значення, введені оператором, але що не мають сенсу. Найчастіше така проблема зустрічається в полях, обов'язкових для заповнення, але за відсутності в оператора реальних даних він вимушений вводити безглузді дані, наприклад: номер соціального страхування 999-99-9999, або вік клієнта 999, або поштовий індекс 99999. Проблема посилюється, якщо існує вірогідність появи реальних даних, які можуть бути прийняті за фіктивні, наприклад, номер соціального страхування 888-88-8888 для вказівки на статус клієнта-іноземця "нерезидент" або місячний дохід у розмірі $99 999,99 для вказівки на те, що клієнт має роботу.
4. Логічно невірні значення — значення, не відповідні логічному сенсу, що вкладається в дане поле таблиці. Наприклад, в полі "Місто" знаходиться значення "Росія", або в полі "температура хворого" значення 10.
5. Закодовані значення — скорочений запис або кодування реальних даних, використовуване для зменшення займаного місця.
6. Складені значення — значення, що містять декілька логічних даних в одному елементі таблиці. Така ситуація можлива в полях довільного формату (наприклад, рядкових або текстових). Проблема посилюється, якщо відсутній строгий формат запису інформації в такі поля. Рівень запису. На даному рівні виникає проблема суперечності значень в різних полях запису, що описує один і той же об'єкт наочної області наприклад, коли вік людини не відповідає його року народження: age = 22, bdate = 12.02.50. Рівень таблиці БД. На даному рівні виникають проблеми, пов'язані з невідповідністю інформації, що зберігається в таблиці і відноситься до різних об'єктів. На цьому рівні найчастіше зустрічаються наступні проблеми.
· Порушення унікальності. Значення, відповідні унікальним атрибутам різних об'єктів предметної області, є однаковими.
· Відсутність стандартів. Через відсутність стандартів на формат запису значень можуть виникати проблеми, пов'язані з дублюванням даних або з їх протиріччям:
· записи, що дублюються (одна і та ж людина записана в таблицю двічі, хоча значення полів унікальні):
empl=(name="john Smith" ...);
emp2=(name="j.Smith", ...);
• суперечливі записи (про одну людину в різних випадках введена різна інформація про дату народження, хоча значення полів унікальні):
empl=(name="John Smith", bdate=12.02.70);
emp2=(name="J.Smith", bdate=12.12.70);
Рівень одиночної БД. На даному рівні, як правило, виникають проблеми, пов'язані з порушенням цілісності даних.
Рівень множини БД. На цьому рівні виникають проблеми, пов'язані з неоднорідністю як структур БД, так і інформації, що зберігається в них. Можна виділити наступні основні проблеми цього рівня:
· відмінність структур БД (відмінність найменувань полів, типів, розмірів і ін.);
· в різних БД існують однакові найменування різних атрибутів;
· в різних БД однакові дані представлені по-різному;
· в різних БД класифікація елементів різна;
· в різних БД тимчасова градація різна;
· в різних БД ключові значення, що ідентифікують один і той же об'єкт предметної області, різні і тому подібне
При вирішенні завдання очищення даних, перш за все, необхідно усвідомлювати те, що не всі проблеми можуть бути усунені. Можливі ситуації, коли дані не існують і не можуть бути відновлені, незалежно від кількості докладених зусиль. Зустрічаються ситуації, коли значення настільки заплутані або знайдені в стількох непорівнянних місцях з такими на вигляд різними і протилежними значеннями одного і того ж факту, що будь-яка спроба розшифрувати ці дані може породити ще більш невірні результати, і, можливо, кращим рішенням буде відмовитися від їх обробки. Насправді не всі дані потрібно очищати. Як вже наголошувалося, процес очищення вимагає великих затрат, тому ті дані, достовірність яких не впливає на процес ухвалення рішень, можуть залишатися неочищеними. В цілому, очищення даних включає декілька етапів:
· виявлення проблем в даних;
· визначення правил очищення даних;
· тестування правил очищення даних;
· безпосереднє очищення даних.
Виявлення проблем в даних. Для виявлення тих, що підлягають видаленню видів помилок і невідповідностей необхідний детальний аналіз даних. Поряд з ручною перевіркою слід використовувати аналітичні програми. Існує два взаємозв'язані методи аналізу: профайлінг даних і Data Mining.
Профайлінг даних орієнтований на грубий аналіз окремих атрибутів даних. При цьому відбувається отримання, наприклад, такої інформації, як тип, довжина, спектр значень, дискретні значення даних і їх частота, зміна, унікальність, наявність невизначених значень, типових строкових моделей (наприклад, для номерів телефонів) і ін.. що дозволяє забезпечити точне представлення різних аспектів якості атрибуту.
Data Mining допомагає знайти специфічні моделі у великих наборах даних, наприклад стосунки між декількома атрибутами. Саме на це направлені так звані описові моделі Data Mining, включаючи угрупування, узагальнення, пошук асоціацій і послідовностей. При цьому можуть бути отримані обмеження цілісності в атрибутах, наприклад, функціональні залежності або характерні для конкретних застосувань бізнес-правила, які можна використовувати для заповнення втрачених і виправлення недопустимих значень, а також для виявлення дублікатів записів в джерелах даних. Наприклад, правило об'єднання з високою вірогідністю може передбачити проблеми з якістю даних в елементах даних, що порушують це правило. Таким чином, 99% а вірогідність правила "разом = кількість х одиницю" демонструє невідповідність і потреба в детальнішому дослідженні для того, що залишився 1 % записів.
Визначення правил очищення даних. Залежно від числа джерел даних, ступінь їх неоднорідності і забрудненості, вони можуть вимагати досить обширного перетворення і очищення. Перші кроки по очищенню даних можуть скоректувати проблеми окремих джерел даних і підготувати дані для інтеграції. Подальші кроки мають бути направлені на інтеграцію даних і усунення проблем множинних джерел.
На цьому етапі необхідно виробити загальні правила перетворення, частина з яких має бути представлена у вигляді програмних засобів очищення.
Тестування правил очищення даних. Коректність і ефективність правил очищення даних повинні тестуватися і оцінюватися, наприклад, на копіях даних джерела. Це необхідно для з'ясування доцільності коректування правил з метою їх поліпшення або виправлення помилок.
Етапи визначення правил і їх тестування можуть виконуватися ітераційно кілька разів, наприклад, через те, що деякі помилки стають помітні лише після певних перетворень. Безпосереднє очищення даних. На цьому етапі виконуються перетворення відповідно до визначених раніше правил. Очищення виконується в два прийоми. Спочатку усуваються проблеми, пов'язані з окремими джерелами даних, а потім — проблеми безлічі БД.
Над окремими ОДД виконуються наступні процедури.
· Розщеплювання атрибутів. Дана процедура витягує значення з атрибутів вільного формату для підвищення точності вистави і підтримки подальших етапів очищення, таких як зіставлення елементів даних і виключення дублікатів. Необхідні на цьому етапі перетворення перерозподіляють значення в полі для отримання можливості переміщення слів і витягують значення для розщеплених атрибутів.
· Перевірка допустимості і виправлення. Ця процедура досліджує кожен елемент даних джерела на наявність помилок. Виявлені помилки автоматично виправляються (якщо це можливо). Перевірка на наявність орфографічних помилок виконується на основі перегляду словника. Словники географічних найменувань і поштових індексів допомагають коректувати адресні дані. Атрибутивні залежності (дата народження — вік, загальна вартість — ціна за шт., місто — регіональний телефонний код і т. д.) можуть використовуватися для виявлення проблем і заміни втрачених або виправлення невірних значень.
· Стандартизація. Ця процедура перетворить дані в погоджений і уніфікований формат, що необхідне для їх подальшого узгодження і інтеграції. Наприклад, записи про дату і час мають бути оформлені в спеціальному форматі, імена і інші символьні дані повинні конвертуватися або в прописні, або в рядкові букви і так далі Текстові дані можуть бути стислі і уніфіковані за допомогою виявлення основи (шаблону), видалення префіксів, суфіксів і ввідних слів. Більш того, абревіатури і зашифровані схеми підлягають погодженій розшифровці за допомогою спеціального словника синонімів або вживання зумовлених правил конверсії.
Після того, як помилки окремих джерел видалені, очищені дані повинні замінити забруднені дані у вихідних ОДД. Це необхідно для підвищення якості даних в ОДД і виключеннях витрат на очищення при повторному використанні. Після завершення перетворень над даними з окремих джерел можна приступати до їх інтеграції. При цьому виконуються наступні процедури.
· Зіставлення даних, що відносяться до одного елементу. Ця процедура усуває суперечність і дублювання даних з різних джерел, що відносяться до одного об'єкту наочної області. Для зіставлення записів з різних джерел використовуються ідентифікаційні атрибути або комбінація атрибутів. Такими атрибутами можуть виступати загальні первинні ключі або інші загальні унікальні атрибути. На жаль, без таких атрибутів процес зіставлення даних скрутний.
· Злиття записів. Дана процедура об'єднує інтегровані записи, що відносяться до одного об'єкту. Об'єднання виконується, якщо інформація з різних записів доповнює або коректує одна іншу.
· Виключення дублікатів. Дана процедура видаляє дублюючі записи. Вона виконується або над двома очищеними джерелами одночасно, або над окремим, вже інтегрованим набором даних. Виключення дублікатів вимагає, в першу чергу, виявлення (зіставлення) схожих записів, що відносяться до одного і тому ж об'єкту реального оточення.
Очищені дані зберігаються в СД і можуть використовуватися для аналізу і прийняття на їх основі рішень. За формування аналітичних запитів до даних і представлення результатів їх виконання в СППР відповідають підсистеми аналізу. Від вигляду аналізу також залежить і безпосередня реалізація структур зберігання даних в СД.
2.4. Концепція сховища даних і аналіз
Концепція СД не є закінченим архітектурним вирішенням СППР і тим більше не є готовим програмним продуктом. Мета концепції СД — визначити вимоги до даних, що поміщаються в СД, загальні принципи і етапи побудови СД, основні джерела даних, дати рекомендації по вирішенню потенційних проблем, що виникають при вивантаженні, очищенні, узгодженні, транспортуванні і завантаженні даних. Необхідно розуміти, що концепція СД:
· це не концепція аналізу даних, швидше, це концепція підготовки даних для аналізу;
· не зумовлює архітектуру цільової аналітичної системи. Концепція СД вказує на те, які процеси повинні виконуватися в системі, але не де конкретно і як вони виконуватимуться.
Таким чином, концепція СД визначає лише найзагальніші принципи побудови аналітичної системи і в першу чергу сконцентрована на властивостях і вимогах до даних, але не на способах організації і представлення даних в цільовій БД і режимах їх використання. Концепція СД описує побудову аналітичної системи, але не визначає характер її використання. Вона не вирішує жодну з наступних проблем:
· вибір найбільш ефективного для аналізу способу організації даних;
· організація доступу до даних;
· використання технології аналізу.
Проблеми використання зібраних даних вирішують підсистеми аналізу. Як наголошувалося в Розділі 1, такі підсистеми використовують наступні технології:
· регламентовані запити;
· оперативний аналіз даних;
· інтелектуальний аналіз даних.
Якщо регламентовані запити успішно застосовувалися ще задовго до появи концепції СД, то оперативний і інтелектуальний аналізи останнім часом все більше пов'язують з СД.
Висновки
З матеріалу, викладеного в даному розділі, можна зробити наступні висновки.
· Концепція СД передбачає розділення структур зберігання даних для оперативної обробки і виконання аналітичних запитів. Це дозволяє в рамках однієї СППР об'єднати дві підсистеми, що задовольняють суперечливим вимогам.
· Відповідно до визначення Інмона, СД— це предметно-орієнтований, інтегрований, немінливий, підтримуючий хронологію набір даних, організований для цілей підтримки ухвалення рішень.
· Розрізняють два види СД: віртуальне і фізичне. У системах, що реалізовують концепцію віртуального СД, аналітичні запити адресуються безпосередньо до ОДД, а отримані результати інтегруються в оперативній пам'яті комп'ютера. В разі фізичного СД дані переносяться з різних ОДД в єдине сховище, до якого адресуються аналітичні запити.
· Полегшеним варіантом СД є ВД, яка містить лише тематично об'єднані дані. ВД істотно менше за об'ємом, ніж СД, і для її реалізації не вимагається великих витрат. ВД може бути реалізована або самостійно, або в комбінації з СД.
· СД включає: метадані, детальні, агреговані і архівні дані. Що переміщаються в СД дані утворюють інформаційні потоки: вхідний, узагальнюючий, зворотний, вихідний і потік метаданих.
· Детальні дані розділяють на два класи: виміри і факти. Вимірами називаються набори даних, необхідні для опису подій. Фактами називаються дані, що відображають суть події.
· Агреговані дані виходять з детальних даних шляхом їх підсумовування по вимірах. Для швидкого доступу до найчастіше запрошуваних агрегованих даних вони повинні зберігатися в СД, а не обчислюватися при виконанні запитів.
· Метадані необхідні для здобуття користувачем інформації про дані, що зберігаються в СД. Згідно з принципами Захмана, метадані повинні описувати об'єкти наочної області, представлені в СД, користувачів, що працюють з даними, місця зберігання даних, дії над даними, час обробки даних і причини модифікацій даних.
· Найбільш потужним інформаційним потоком в СД є вхідний — потік перенесення даних з ОІД в СД. Процес перенесення, що включає етапи збору, перетворення і завантаження, називають ЕТL-процесом.
· Найбільш важливим завданням при перенесенні даних є їх очищення. Основні проблеми очищення даних можна класифікувати по наступних рівнях: рівень елементу таблиці, рівень запису, рівень таблиці БД, рівень одиночної БД, рівень множини БД.
· Очищення даних включає наступні етапи: виявлення проблем в даних, визначення правил очищення, тестування правил очищення, безпосереднє очищення даних. Після виправлення помилок окремих джерел очищені дані повинні замінити забруднені дані у вихідних ОДД.
· Очищені дані зберігаються в СД і можуть використовуватися для аналізу і прийняття на їх основі рішень. За формування аналітичних запитів до даних і представлення результатів їх виконання в СППР відповідають підсистеми аналізу. Від вигляду аналізу також залежить і безпосередня реалізація структур зберігання даних в СД.
Дата добавления: 2018-05-09; просмотров: 564; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!