Сховища даних та бази знань Основні проблеми, пов’язані з аналізом інформації, як правило
Основні проблеми, пов'язані з аналізом інформації, як правило, обумовлені розрізненістю даних у першоджерелах, їх якістю та рівнем готовності (відсутністю агрегатів, обчислюваних показників) для вирішення аналітичних завдань.
Основними ідеями, що лежать в основі концепції сховища даних, є:
• інтеграція роз'єднаних деталізованих даних, що описують деякі конкретні факти, властивості, події тощо, в єдиному сховищі;
• поділ наборів даних та додатків на використовувані для оперативної обробки та застосовувані для вирішення завдань аналізу.
На початку вісімдесятих років минулого століття в період бурхливого розвитку реєструючих ІС виникло розуміння обмеженості можливості застосування БД для цілей аналізу даних та побудови на їх основі систем підтримки та прийняття рішень. Реєструючі системи створювалися для автоматизації рутинних операцій із ведення бізнесу — виписка рахунків, оформлення договорів, перевірка стану складу тощо. Користувачами таких систем був переважно лінійний персонал. Основні вимоги, які пред'являлися до реєструючих систем, - забезпечення транзакційності змін, що вносяться, і максимізація швидкості їх виконання. Саме ці вимоги визначили вибір реляційних СУБД та відповідної моделі подання даних як основні використовувані технічні рішення при побудові реєструючих систем.
Для менеджерів та аналітиків були потрібні системи, які б дозволяли:
• аналізувати інформацію у часовому аспекті;
• формувати довільні запити до системи;
• обробляти великі обсяги даних;
• інтегрувати дані з різних систем, що реєструють.
Очевидно, щореєструючі системи не задовольняли жодного
одному з вищезазначених вимог. B реєструючій системі інформація актуальна тільки на момент звернення до бази даних, в наступний момент часу за тим самим запитом можна отримати зовсім інший результат. Інтерфейс реєструючих систем розрахований на проведення жорстко визначених операцій та можливості отримання результатів на нерегламентований запит дуже обмежені. Можливість обробки великих масивів даних також мала через налаштування СУБД виконання коротких транзакцій і неминучого уповільнення роботи інших користувачів.
Відповіддю на потребу стала поява нової технології організації баз даних — технології сховищ даних.
Сховище даних (ХД) - це система, що містить несуперечливу інтегровану предметно-орієнтовану сукупність історичних даних великої корпорації або іншої організації з метою підтримки прийняття стратегічних рішень [31].
Інформаційні ресурси ХД формуються шляхом отримання моментальних знімків БД операційної ІС організації та різних зовнішніх джерел. ХД збирає, очищує, завантажує, агрегує, зберігає дані та надає до них швидкий доступ.
При ефективному використанні ХД може бути одним із основних джерел достовірної інформації для керівників та фахівців усіх підрозділів організації. Це забезпечить узгодженість, своєчасність та обґрунтованість прийняття управлінських рішень, полегшить вивірку обов'язкової звітності, випуск управлінської звітності.
O сховище даних можна говорити як про сукупність джерела даних (структура пов'язаних таблиць - це і є сховище), де збирається інформація для подальшої обробки, і процедур вилучення, перетворення та завантаження даних(ETL - extraction, transformation, loading).
Фізично сховище даних є реляційною базою даних. Однак, на відміну від БД корпоративних інформаційних систем (КІС), сховище має принципово іншу структуру. Наприклад, сховище містить агреговані дані, показники, що обчислюються, зберігає історичні накопичені дані по конкретних об'єктах (період зберігання інформації - тривалий). На відміну від ХД бази даних КІС містять деталізовані дані, період їх зберігання відносно короткий.
Класична архітектура ХД складається з наступних елементів: реляційна, багатовимірна або гібридна БД, засоби вилучення, очищення та завантаження даних, засоби візуалізації даних та генерації звітів (OLAP-клієнти). Реляційна БД будується з архітектури «зірка», у якій із однією таблицею фактів пов'язані кілька таблиць вимірів (довідників), чи «сніжинка», що відрізняється наявністю ієрархічних довідників. Це робиться для оптимізації швидкості виконання об'ємних запитів (останнім часом з'явилося багато статей, які критикують цей підхід за його спрощеність та неможливість вирішення виключно в рамках «зірки» всього різноманіття завдань ХД). У багатовимірній БД будуються «куби» — специфічні структури, аналогічні за змістом реляційним «сніжинкам», але обчислені агрегати, що зберігають, на всіх перетинах вимірювань.
Концептуально модель сховища даних можна подати у вигляді схеми, показаної на рис. 3.20.
Дані з різних джерел містяться в ХД, а опис цих даних в репозиторії метаданих. Кінцевий користувач, використовуючи різні інструменти (засоби візуалізації, побудови звітів, статистичної обробки тощо) та вміст репозиторію, аналізує дані у сховищі. Результатом його діяльності єінформація у вигляді готових звітів, знайдених прихованих закономірностей, будь-яких прогнозів. Так, як засоби роботи кінцевого користувача зі сховищем даних можуть бути найрізноманітнішими, теоретично їх вибір не повинен впливати на його структуру та функції його підтримки в актуальному стані.
Мал. 3.20. Концептуальна модель сховища даних
Особливості сховища даних пов'язані з особливостями завдань, на вирішення яких воно орієнтоване: аналітичну оперативну обробку інформації та, як наслідок, складні для оперативних баз даних SQL-запити.
На основі ХД створюються підмножини даних - OLAP-куби, багатовимірні ієрархічні структури даних, що містять безліч ознак:
• дата/час (період часу, до якого належать дані);
• сфера діяльності (бізнес-сфера, результат), до якої належать дані;
• суб'єкт управління (особа, яка приймає рішення – ЛПР);
• вид ресурсу та ін.
Ці ознаки дозволяють агрегувати дані шляхом довільного поєднання ознак та обчислення статистичних оцінок. В результаті аналізу інформації створюється нове знання, корисне для управління.
Дані до сховища потрапляють з оперативних систем (OL ГР-систем), призначених для автоматизації бізнес-процесів. Крім того, сховище може поповнюватися за рахунок зовнішніх джерел, наприклад, статистичних звітів.
На питання «Навіщо будувати сховища даних - адже вони містять свідомо надмірну інформацію, яка і так присутня в БД або файлах оперативних систем?», можна відповісти, що аналізувати дані оперативних систем безпосередньо неможливо або дуже складно. Це пояснюється різними причинами, у тому числі розрізненістю даних, зберіганням їх у різних форматахСУБД та у різних «куточках» корпоративної мережі.
OLAP (On-line Analytical Processing) не є необхідним атрибутом сховища даних, але він все частіше і частіше застосовується для аналізу накопичених у цьому сховищі відомостей.
Компоненти, що входять до типового сховища, представлені на рис. 3.21.
Мал. 3.21. Структура сховища даних
Оперативні дані збираються з різних джерел, очищаються, інтегруються та складаються у реляційне сховище. При цьому вони вже доступні для аналізу за допомогою різних засобів побудови звітів. Далі (повністю або частково) готуються для OLAP-аналізу. Вони можуть бути завантажені у спеціальну БД OLAP або залишені у реляційному сховищі. Найважливішим його елементом є метадані, тобто. інформація про структуру, розміщення та трансформацію даних.
Завдяки їм забезпечується ефективна взаємодія різних компонентів сховища.
Таким чином, завдання сховища — надати «сировину» для аналізу в одному місці та у простій, зрозумілій структурі.
Є ще одна причина, що виправдовує появу окремого сховища. Складні аналітичні запити до оперативної інформації гальмують поточну роботу компанії, блокуючи надовго таблиці і захоплюючи ресурси сервера.
Основними причинами, які спонукають організації впроваджувати сховища даних, є:
• необхідність виконання аналітичних запитів та генерації звітів на не задіяних основними ІС обчислювальних ресурсах;
• необхідність використання моделей даних та технологій, які прискорюють процес виконання запитів та підготовки звітності, але не призначені для обробки транзакцій;
• створення середовища, в якому навіть щодо невеликих знань основ СУБД достатньо длястворення запитів та підготовки звітів, що означає скорочення часу, який вимагається від персоналу ІТ-відділу для супроводу системи;
• створення джерела із попередньо очищеною інформацією;
• спрощення процесу підготовки звітів на основі інформації з кількох трансакційних систем та/або зовнішніх джерел даних та/або даних, що використовуються виключно для генерації звітів;
• створення виділеного джерела в тих випадках, коли можливості операційної системи не відповідають необхідному бізнесу терміну зберігання даних та/або необхідно мати можливість підготовки звітів на певні моменти часу в минулому;
• захист кінцевих користувачів від необхідності будь-якої міри вникати в структуру і логіку роботи БД реєструючої системи.
Перехід від даних до знань - логічний наслідок розвитку та ускладнення інформаційно-логічних структур, що обробляються за допомогою комп'ютера. Активно сферою використання сучасних комп'ютерів, що розвивається, є створення баз знань (БЗ) та їх застосування в різних галузях науки і техніки.
Знання - це закономірності предметної галузі (принципи, зв'язки, закони), отримані в результаті практичної діяльності та професійного досвіду, що дозволяють фахівцям ставити та вирішувати завдання у цій галузі.
Знання можна як стратегічну інформацію, необхідну формування мети і побудови кінематичної траєкторії, а інформацію — як оперативні знання, використовувані системою в динамічному процесі.
Під базою знань (БЗ) розуміють сукупність знань, накопичених людиною у певній предметній галузі, виражену за допомогою певної мови уявлення знань.
Для створення БЗ розробляються відповідніпрограмні засоби. Вони дозволяють забезпечувати завантаження, актуалізацію, підтримку у достовірному стані, розширення БЗ, формування, обробку та включення нових знань, що відповідають поточній ситуації. Основи знань становлять основу експертних систем під час підготовки управлінських рішень.
Експертні системи (ЕС) — прикладні системи штучного інтелекту, в яких база знань є формалізованими емпіричними знаннями висококваліфікованих фахівців (експертів) у будь-якій вузькій предметній галузі, а також може містити результатну інформацію, отриману при вирішенні економічних завдань.
Структура експертної системи та її компоненти представлені на рис. 3.22. [1]
Мал. 3.22. Структура експертної системи
ними. На основі відносин, що задаються в правилах, виконується логічний висновок. В умовах та висновках правил присутні посилання на фрейми та їх слоти.
• База даних призначена для тимчасового зберігання фактів або гіпотез, які є проміжними рішеннями або результатом спілкування системи із зовнішнім середовищем, якою зазвичай виступає людина, яка веде діалог з експертною системою.
• Машина логічного висновку — механізм міркувань, що оперує знаннями та даними з метою отримання нових даних із знань та інших даних, що є у робочій пам'яті. Для цього зазвичай використовується програмно реалізований механізм дедуктивного логічного висновку (якийсь його різновид) або механізм пошуку рішення в мережі кадрів або семантичної мережі. Машина логічного висновку може реалізовувати міркування у вигляді дедуктивного висновку (прямого, зворотного, змішаного), нечіткого висновку, ймовірнісного висновку, пошуку рішення з розбиттям на послідовність підзавдань, пошуку рішення звикористанням стратегії розбиття простору, пошуку з урахуванням рівнів абстрагування рішення або понять, з ними пов'язаних, монотонного або немонотонного міркування, міркувань з використанням механізму аргументації, асоціативного пошуку з використанням нейронних мереж та ін.
• Підсистема спілкування служить для ведення діалогу з користувачем, в ході якого ЕС запитує у користувача необхідні факти для процесу міркування, а також дає можливість користувачеві якоюсь мірою контролювати та коригувати перебіг міркувань експертної системи.
• Підсистема пояснень необхідна для того, щоб дати можливість користувачеві контролювати перебіг міркувань і, можливо, вчитися в ЕС. Якщо немає цієї підсистеми, ЕС виглядає для користувача як «річ у собі», рішенням якої можна або вірити, або ні. Користувач вибирає останнє і така ЕС не має перспектив для застосування.
Серед спеціалізованих систем, заснованих на знаннях, найбільш значущими є експертні системи реального часу, або динамічні експертні системи. На їхню частку припадає 70% цього ринку.
Класи завдань, які розв'язують експертні системи реального часу, такі: моніторинг у реальному масштабі часу, системи управління верхнього рівня, системи виявлення несправностей, діагностика, складання розкладів, планування, оптимізація, системи — порадники оператора, системи проектування.