Кластеризація українських регіонів за допомогою карти Кохонена та алгоритму k-means в бізнес-аналітичної платформі "Deductor"
Застосування бізнес-аналітичної платформи "Deductor" для оцінки степені екологічної безпеки регіонів України. Дослідження кластеризації українських регіонів за соціально-економічними показниками з використанням карти Кохонена та алгоритму k-means.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | украинский |
| Дата добавления | 26.11.2014 |
| Размер файла | 1,6 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
КУРСОВА РОБОТА
Кластеризація українських регіонів за допомогою карти Кохонена та алгоритму k-means в бізнес-аналітичної платформі "Deductor"
Зміст
- Введення
- Розділ 1. Системи аналітичної обробки даних OLAP
- 1.1 Оперативна OLTP та аналітична OLAP обробка даних
- 1.2 Властивості інформаційних сховищ
- Розділ 2. Deductor Studio. Загальні відомості та його особливості і версії
- 2.1 Deductor Studio
- 2.2 Версії та задачі Deductor Studio
- Розділ 3. Deductor Studio як інструмент кластеризації українських регіонів
- 3.1 Постановка проблеми у загальному вигляді, її зв'язок з актуальними теоретичними та практичними завданнями
- Висновки та пропозиції
- Список використаної літератури
Введення
В останні роки бізнес-аналітична платформа Deductor почала застосовуватися для оцінки степені екологічної безпеки регіонів України, для дослідження типології депресивних територій України, для аналізу економічних показників регіонів Приволжського федерального округу Росії, для кластеризації регіонів Росії по рівню соціально-економічного розвитку, для кластеризації країн Європи на основі субіндексів глобалізації та інших дослідженнях.
Метою даної роботи було дослідити кластеризацію українських регіонів за соціально-економічними показниками 2013 та 2014 років на два або більше "умовних" кластерів в контексті поділу України на "Схід Захід", "Північ-Південь" та інше. Кластеризація проводилася за допомогою карти Кохонена та алгоритму k-means в бізнес-аналітичній платформі Deductor.
Розділ 1. Системи аналітичної обробки даних OLAP
1.1 Оперативна OLTP та аналітична OLAP обробка даних
В області інформаційних технологій завжди існувало два взаємодоповнюючих напрямки:
· оперативна (транзакційна, поопераційна) обробка даних (Online Transaction Processing (OLTP));
· підтримка прийняття рішень через аналіз даних (Online Analytical Processing (OLAP)).
Оперативна аналітична обробка та інтелектуальний аналіз даних - дві складові частини процесу підтримки прийняття рішень.
Основним джерелом інформації, що надходить в оперативну БД є діяльність корпорації. Для проведення аналізу даних потрібне залучення зовнішніх джерел інформації (наприклад, статистичних звітів). Сховище даних має включати як внутрішні корпоративні дані, так і зовнішні дані.
Для оперативної обробки потрібні свіжі дані за кілька останніх місяців, для проведення достовірних аналізу і прогнозування в сховищі даних потрібно мати інформацію про діяльність корпорації і стан ринку протягом декількох років. Обсяг аналітичних БД як мінімум на порядок більше обсягу оперативних.
У багатьох великих корпораціях одночасно існують кілька оперативних ІС з власними БД (з історичних причин). Оперативні БД можуть містити семантично еквівалентну інформацію, представлену в різних форматах, з різним зазначенням часу її надходження, іноді навіть суперечливу. Сховище даних повинне містити одноманітно представлену і узгоджену інформацію, максимально відповідну змісту оперативних БД. Необхідна компонента для вилучення і "очищення" інформації з різних джерел.
Оперативні ІС створюються в розрахунку на вирішення конкретних завдань. Інформація з БД вибирається часто і невеликими порціями. Зазвичай набір запитів до оперативної БД відомий вже при проектуванні. Набір запитів до аналітичної бази даних передбачити неможливо. Сховища даних існують, щоб відповідати на нерегламентовані (ad hoc) запити аналітиків. Можна розраховувати лише на те, що запити будуть надходити не надто часто і зачіпати невеликі обсяги інформації. Розміри аналітичної БД стимулюють використання запитів з агрегатами (сума, мінімальне, максимальне, середнє значення тощо).
Оперативні БД за своєю природою є сильно мінливими, що враховується у використовуваних СКБД (нормалізована структура БД, рядки зберігаються невпорядковано, B-дерева для індексації, транзакції). При малій мінливості аналітичних БД (тільки при завантаженні даних) виявляються розумними впорядкованість масивів, більш швидкі методи індексації при масовій вибірці, зберігання заздалегідь агрегованих даних.
Для оперативних ІС зазвичай вистачає захисту інформації на рівні таблиць. Інформація аналітичних БД настільки критична для корпорації, що потрібні велика грануляція захисту (індивідуальні права доступу до певних рядках і/або стовпцях таблиці).
З точки зору бізнес - аналізу кожен аналізований факт зручно розглядати як функцію від його характеристик. Ці параметри носять назву виміри. Природна структура бази даних для подібного подання - це багатовимірний куб, ребра якого відповідають мірам, а внутрішній об'єм - мірами. Виконуючи перетин куба двовимірної площиною в тому чи іншому напрямку, легко отримати взаємозалежність будь-якої пари величин щодо вибраної міри.
В основі концепції OLAP лежить принцип багатовимірного подання даних. У 1993 році в статті Е. Кодд розглянув недоліки реляційної моделі, в першу чергу, вказавши на неможливість "об'єднувати, переглядати й аналізувати дані з точки зору множинності вимірів, тобто самим зрозумілим для корпоративних аналітиків способом", і визначив загальні вимоги до систем OLAP, що розширює функціональність реляційних СКБД і включає багатовимірний аналіз як одну зі своїх характеристик.
У великому числі публікацій абревіатурою OLAP позначається не тільки багатовимірний погляд на дані, а й зберігання самих даних багатовимірної БД. Це невірно, оскільки сам Кодд відзначає, що реляційні БД були, є і будуть найбільш придатною технологією для зберігання корпоративних даних. Необхідність існує не в новій технології БД, а, швидше, в засобах аналізу, що доповнюють функції існуючих СКБД і досить гнучких, щоб передбачити й автоматизувати різні види інтелектуального аналізу, властиві OLAP.
Навіщо будувати сховища даних - адже вони містять завідомо надлишкову інформацію, яка і так вже знаходиться в базах або файлах оперативних систем? Тому що аналізувати дані оперативних систем безпосередньо вельми скрутно. Це пояснюється різними причинами, у тому числі розрізненістю даних, зберіганням їх у форматах різних СКБД і в різних вузлах корпоративної мережі. Але навіть якщо на підприємстві всі дані зберігаються на центральному сервері БД (що буває досить рідко), аналітик (тобто фахівець, що займається завданнями аналізу і вироблення нових шляхів розвитку фірми) майже напевно не розбереться в їх складних, часом заплутаних структурах. Є досить великий досвід невдалих спроб "нагодувати" аналітиків "сирими" даними з оперативних систем.
Таким чином, завдання сховища - надати "сировину" для аналізу в одному місці та в простій, зрозумілій структурі. Ральф Кімбалл в передмові до своєї книги "The Data Warehouse Toolkit" пише, що якщо після прочитання всієї книги читач зрозуміє тільки одну річ, а саме: структура сховища повинна бути простою, - автор буде вважати своє завдання виконаним.
Є і ще одна причина, що виправдує появу окремого сховища - складні аналітичні запити до оперативної інформації гальмують поточну роботу компанії, надовго блокуючи таблиці та захоплюючи ресурси сервера.
deductor карта кохонен кластеризація регіон
Під сховищем можна розуміти не обов'язково гігантське скупчення даних - головне, щоб воно було зручно для аналізу. Взагалі кажучи, для маленьких сховищ призначається окремий термін - Data Marts (кіоски даних), але в нашій практиці його не часто вживають.
За Коддом, багатовимірне концептуальне уявлення (multi-dimensional conceptual view) являє собою множинну перспективу, що складається з декількох незалежних вимірів, уздовж яких можуть бути проаналізовані певні сукупності даних. Одночасний аналіз по декількох вимірах визначається як багатовимірний аналіз. Кожен вимір включає напрямки консолідації даних, які складаються із серії послідовних рівнів узагальнення, де кожен вищестоящий рівень відповідає більшому ступеню агрегації даних по відповідному вимірюванню. Операція спуску (drilling down) відповідає руху від вищих щаблів консолідації до нижчих; навпаки, операція підйому (rolling up) означає рух від нижчих рівнів до вищих (рис.1.1).
Вимірювання та напрямки консолідації даних
Рис.1.1 Вимірювання та напрямки консолідації даних
Кодд визначив 12 правил, яким повинен задовольняти програмний продукт класу OLAP (табл.1.2).
Таблиця 25.1 Правила оцінки програмних продуктів класу OLAP
|
№ |
Правило |
Розшифрування |
|
|
1 |
Багатовимірне концептуальне уявлення даних (багатовимірні Концептуальні View) |
Концептуальне уявлення моделі даних в продукті OLAP має бути багатовимірним за своєю природою, тобто дозволяти аналітикам виконувати інтуїтивні операції "аналізу вздовж і впоперек" ("slice and dice"), обертання (rotate) і розміщення (pivot) напрямків консолідації |
|
|
2 |
Прозорість (Transparency) |
Користувач не повинен знати про те, які конкретні засоби використовуються для зберігання та обробки даних, як дані організовані та звідки беруться |
|
|
3 |
Доступність (Accessibility) |
Аналітик повинен мати можливість виконувати аналіз в рамках загальної концептуальної схеми, але при цьому дані можуть знаходитись під керуванням спадщини, яка залишилась від старої СКБД, будучи при цьому прив'язаними до загальної аналітичної моделі. Тобто інструментарій OLAP повинен накладати свою логічну схему на фізичні масиви даних, виконуючи всі перетворення, що вимагаються для забезпечення єдиного, узгодженого і цілісного погляду користувача на інформацію |
|
|
4 |
Стійка продуктивність (Consistent Reporting Performance) |
Зі збільшенням числа вимірювань і розмірів БД аналітики не повинні зіткнутися з яким би то не було зменшенням продуктивності. Стійка продуктивність необхідна для підтримки простоти використання і свободи від ускладнень, що вимагаються для доведення OLAP до кінцевого користувача |
|
|
5 |
Клієнт - серверна архітектура (Client-Server Architecture) |
Серверний компонент інструмента OLAP повинен бути достатньо інтелектуальним і мати здатність будувати загальну концептуальну схему на основі узагальнення і консолідації різних логічних і фізичних схем корпоративних баз даних для забезпечення ефекту прозорості |
|
|
6 |
Рівноправність вимірювань (Generic Dimensionality) |
Всі вимірювання даних повинні бути рівноправні. Додаткові характеристики можуть бути надані окремим вимірам, але оскільки всі вони симетричні, дана додаткова функціональність може бути надана будь-якому вимірюванню. Базова структура даних, формули і формати звітів не повинні спиратися на якийсь один вимір |
|
|
7 |
Динамічна обробка розріджених матриць (Dynamic Sparse Matrix Handling) |
Інструмент OLAP повинен забезпечувати оптимальну обробку розріджених матриць. Швидкість доступу повинна зберігатися незалежно від розташування осередків даних і бути постійною величиною для моделей, що мають різне число вимірювань і різну розрідженість даних |
|
|
8 |
Підтримка багатокористувацького режиму (Multi-User Support) |
Найчастіше кілька аналітиків мають необхідність працювати одночасно з однією аналітичною моделлю або створювати різні моделі на основі одних корпоративних даних. Інструмент OLAP повинен надавати їм конкурентний доступ, забезпечувати цілісність та захист даних |
|
|
9 |
Необмежена підтримка кросмірних операцій (Unrestricted Cross-dimensional Operations) |
Обчислення і маніпуляція даними щодо будь-якого числа вимірів не повинні забороняти або обмежувати будь-які відношення між комірками даних. Перетворення, що вимагають довільного визначення, повинні задаватися функціонально повною формульному мовою |
|
|
10 |
Інтуїтивне маніпулювання даними (Intuitive Data Manipulation) |
Переорієнтація напрямків консолідації, деталізація даних в колонках і рядках, агрегація та інші маніпуляції, властиві структурі ієрархії напрямків консолідації, повинні виконуватися в максимально зручному, природному і комфортному інтерфейсі |
|
|
11 |
Гнучкий механізм генерації звітів (Flexible Reporting) |
Повинні підтримуватися різні способи візуалізації даних, тобто звіти повинні подаватися в будь-якій можливій орієнтації |
|
|
12 |
Необмежена кількість вимірювань і рівнів агрегації (Unlimited Dimensions and Aggregation Levels) |
Настійно рекомендується допущення в кожному серйозному OLAP інструменті як мінімум п'ятнадцяти, а краще двадцяти, вимірювань в аналітичній моделі. Більше того, кожне з цих вимірювань повинно допускати практично необмежену кількість певних користувачем рівнів агрегації по будь-якому напряму консолідації |
Настійно рекомендується допущення в кожному серйозному OLAP інструменті як мінімум п'ятнадцяти, а краще двадцяти, вимірювань в аналітичній моделі. Більше того, кожне з цих вимірювань повинно допускати практично необмежену кількість певних користувачем рівнів агрегації по будь-якому напряму консолідації
Тест FASMI
Пізніше дванадцять правил Кодда було перероблено в так званий тест FASMI, що вимагає, аби OLAP-додаток надавав можливості швидкого аналізу багатовимірної інформації, яка розділяється:
fast (швидкий) - аналіз повинен проводитися однаково швидко з усіх аспектів інформації. Прийнятний час відгуку - менше 5-ти секунд;
analysis (аналіз) - повинна бути можливість здійснювати основні типи числового та статистичного аналізу, зумовленого розробником програми або довільно визначеного користувачем;
shared (розділяють) - множина користувачів повинна мати доступ до даних, при цьому необхідно контролювати доступ до конфіденційної інформації;
multidimensional (багатовимірність) - це основна, найбільш істотна характеристика OLAP;
information (інформація) - додаток повинен мати можливість звертатися до будь-якої потрібної інформації, незалежно від її обсягу та місця зберігання.
В даний час на ринку присутня велика кількість продуктів, які в тій чи іншій мірі забезпечують функціональність OLAP. Забезпечуючи багатомірне концептуальне уявлення з боку користувача інтерфейсу до вихідної бази даних, всі продукти OLAP діляться на три класи за типом вихідної БД:
MOLAP (Multidimensional OLAP) - і детальні дані, і агрегати зберігаються в багатовимірній БД. В цьому випадку виходить найбільша надмірність, так як багатовимірні дані повністю містять реляційні;
ROLAP (Relational OLAP) - детальні дані залишаються там, де вони "жили" спочатку - в реляційній БД; агрегати зберігаються в тій же БД в спеціально створених службових таблицях;
HOLAP (Hybrid OLAP) - детальні дані залишаються на місці (в реляційній БД), а агрегати зберігаються в багатовимірній БД.
Крім перерахованих засобів існує ще один клас - інструменти генерації запитів і звітів для настільних ПК, які доповнені функціями OLAP або інтегровані з зовнішніми засобами, що виконують такі функції. Ці добре розвинуті системи здійснюють вибірку даних з вихідних джерел, перетворюють їх і поміщають в динамічну багатовимірну БД, що функціонує на клієнтській станції кінцевого користувача.
Архітектура системи багатовимірного інтелектуального аналізу даних представлена на рис.1.3.
Багатомірний OLAP (MOLAP)
Найперші системи оперативної аналітичної обробки (наприклад, Essbase компанії Arbor Software, Oracle Express Server компанії Oracle) відносились до класу MOLAP, тобто могли працювати тільки зі своїми власними багатовимірними базами даних. Вони ґрунтуються на патентованих технологіях для багатовимірних СКБД і є найбільш дорогими. Ці системи забезпечують повний цикл OLAP-обробки. Вони або включають в себе, крім серверного компонента, власний інтегрований клієнтський інтерфейс, або використовують для зв'язку з користувачем зовнішні програми, які працюють з електронними таблицями. Для обслуговування таких систем потрібен спеціальний штат співробітників, які займаються установкою, супроводженням системи, формуванням уявлень даних для кінцевих користувачів.
У спеціалізованих СКБД, заснованих на багатовимірному поданні даних, дані організовані не у формі реляційних таблиць, а у вигляді впорядкованих багатовимірних масивів:
· гіперкубів (всі збережені в БД комірки повинні мати однакову мірність, тобто знаходитися в максимально повному базисі вимірювань);
· полікубів (кожна змінна зберігається з власним набором вимірів, і всі пов'язані з цим складнощі обробки перекладаються на внутрішні механізми системи).
Використання багатовимірних БД в системах оперативної аналітичної обробки має наступні переваги:
· у разі використання багатовимірних СКБД пошук і вибірка даних здійснюється значно швидше, ніж при багатомірному концептуальному погляді на реляційну базу даних, тому що багатовимірна база даних денормалізована, містить заздалегідь агреговані показники і забезпечує оптимізований доступ до запитуваних комірок;
· багатовимірні СКБД легко справляються з завданнями включення в інформаційну модель різноманітних вбудованих функцій, тоді як об'єктивно існуючі обмеження мови SQL роблять виконання цих завдань на основі реляційних СКБД досить складним, а іноді й неможливим.
З іншого боку, є істотні обмеження:
багатовимірні СКБД не дозволяють працювати з великими БД. До того ж за рахунок денормалізації і попередньо виконаної агрегації обсяг даних багатовимірної бази, як правило, відповідає (по оцінці Кодда) 2,5-100 разів більшому обсягу вихідних деталізованих даних;
багатовимірні СКБД в порівнянні з реляційними дуже неефективно використовують зовнішню пам'ять. У переважній більшості випадків інформаційний гіперкуб є сильно розрідженим, а оскільки дані зберігаються в упорядкованому вигляді, невизначені значення вдається видалити тільки за рахунок вибору оптимального порядку сортування, що дозволяє організувати дані в максимально великі безперервні групи. Але навіть в цьому випадку проблема вирішується тільки частково. Крім того, оптимальний з точки зору зберігання розріджених даних порядок сортування швидше за все не буде збігатися з порядком, який найчастіше використовується у запитах. Тому в реальних системах доводиться шукати компроміс між швидкодією і надмірністю дискового простору, зайнятого базою даних.
Отже, використання багатовимірних СКБД виправдано тільки при наступних умовах:
· обсяг вихідних даних для аналізу не занадто великий (не більше декількох гігабайт), тобто рівень агрегації даних досить високий;
· набір інформаційних вимірів стабільний (оскільки будь-яка зміна в їх структурі майже завжди вимагає повної перебудови гіперкуба);
· час відповіді системи на нерегламентовані запити є найбільш критичним параметром;
· потрібно широке використання складних вбудованих функцій для виконання кросвимірних обчислень над комірками гіперкуба, в тому числі можливість написання користувацьких функцій.
Реляційний OLAP (ROLAP)
Системи оперативної аналітичної обробки реляційних даних (ROLAP) дозволяють представляти дані, що зберігаються в реляційній базі, в багатовимірній формі, забезпечуючи перетворення інформації в багатовимірну модель через проміжний шар метаданих. До цього класу належать DSS Suite компанії MicroStrategy, MetaCube компанії Informix, DecisionSuite компанії Information Advantage тощо. Подібно системам MOLAP, вони вимагають значних витрат на обслуговування фахівцями з інформаційних технологій і передбачають багатокористувацький режим роботи.
Безпосереднє використання реляційних БД в системах оперативної аналітичної обробки має наступні переваги:
· у більшості випадків корпоративні сховища даних реалізуються засобами реляційних СКБД, та інструменти ROLAP дозволяють виконувати аналіз безпосередньо над ними. При цьому розмір сховища не є таким критичним параметром, як у випадку MOLAP;
· у разі змінної розмірності задачі, коли зміни в структуру вимірювань доводиться вносити досить часто, ROLAP системи з динамічним поданням розмірності є оптимальним рішенням, так як в них такі модифікації не вимагають фізичної реорганізації БД;
· реляційні СКБД забезпечують значно вищий рівень захисту даних і хороші можливості розмежування прав доступу.
Головний недолік ROLAP в порівнянні з багатовимірними СКБД - менша продуктивність. Для забезпечення продуктивності, порівнянної з MOLAP, реляційні системи вимагають ретельного опрацювання схеми бази даних і налаштування індексів, тобто великих зусиль з боку адміністраторів БД. Тільки при використанні зіркоподібних схем продуктивність добре налаштованих реляційних систем може бути наближена до продуктивності систем на основі багатовимірних баз даних.
Ідея зіркоподібних схем полягає в тому, що є таблиці для кожного виміру, а всі факти поміщаються в одну таблицю, яка індексована множинним ключем, складеним із ключів окремих вимірів. Кожен промінь схеми зірки задає, в термінології Кодда, напрям консолідації даних за відповідним вимірюванням.
Таким чином, при великому числі незалежних вимірювань необхідно підтримувати множину таблиць фактів, відповідних кожному можливому поєднанню вибраних у запиті вимірів, що також призводить до неекономного використання зовнішньої пам'яті, збільшення часу завантаження даних в БД схеми зірки із зовнішніх джерел і складнощів адміністрування. Механізм пошуку компромісу між надмірністю та швидкодією полягає у створенні таблиць фактів не для всіх можливих поєднань вимірювань, а тільки для тих, значення комірок яких не можуть бути отримані за допомогою наступної агрегації більш повних таблиць фактів.
Таблиці фактів містять чисельні значення комірок гіперкуба, а інші таблиці визначають багатовимірний базис вимірювань, які їх містить. Частину інформації можна отримувати за допомогою динамічної агрегації даних, розподілених по не зіркоподібним нормалізованим структурам, хоча запити, що включають агрегацію, при високонормалізованій структурі БД можуть виконуватися досить повільно.
Орієнтація на уявлення багатовимірної інформації за допомогою зіркоподібних реляційних моделей дозволяє позбутися проблеми оптимізації зберігання розріджених матриць, що гостро стоїть перед багатовимірними СКБД (де проблема розрідженості вирішується спеціальним вибором схеми). Хоча для зберігання кожної комірки використовується цілий запис, який крім самих значень включає вторинні ключі - посилання на таблиці вимірювань, неіснуючі значення просто не включаються в таблицю фактів.
Гібридні OLAP (HOLAP)
Гібридні системи (Hybrid OLAP, HOLAP) розроблені з метою поєднання переваг і мінімізації недоліків, притаманних попереднім класам. До цього класу відноситься Media/MR компанії Speedware. За твердженням розробників, він об'єднує аналітичну гнучкість і швидкість відповіді MOLAP з постійним доступом до реальних даних, властивим ROLAP.
1.2 Властивості інформаційних сховищ
Розробники виділяють наступні властивості:
1. предметна орієнтація;
2. інтегрованість даних;
3. інваріантність у часі;
4. непорушність - стабільність інформації;
5. мінімізація надмірності інформації.
6. Предметна орієнтація
На відміну від БД в традиційних OLTP-системах, де дані підібрані у відповідності з конкретними додатками, інформація в OLAP орієнтована на задачі підтримки прийняття рішень. Для системи підтримки прийняття рішень потрібні "історичні" дані - факти продажів за певні проміжки часу. Добре спроектовані структури даних OLAP відображають розвиток всіх напрямків бізнесу компанії в часі.
Оскільки в OLAP-технології об'єкти даних виходять на перший план, то особливі вимоги пред'являються до структур БД, які використовуються для створення інформаційних сховищ. Принципово відрізняються і структури баз даних для OLTP-й OLAP-систем. У другому випадку в них міститься тільки та інформація, яка може бути корисною для роботи систем підтримки прийняття рішень (DSS).
Інтегрованість даних
Дані в інформаційне сховище надходять з різних джерел, де вони можуть мати різні імена, атрибути, одиниці виміру і способи кодування. Після завантаження в OLAP дані очищаються від індивідуальних ознак, тобто як би приводяться до спільного знаменника. З цього моменту вони представляються користувачу у вигляді єдиного інформаційного простору.
Наприклад, якщо в чотирьох різних додатках стать клієнта кодувалася чотирма різними способами, то в інформаційному сховищі буде використана єдина для всіх даних схема кодування (ч або ж).
Інваріантність у часі
У OLTP-системах істинність даних гарантована тільки в момент читання, оскільки вже в наступну мить вони можуть змінитися в результаті чергової транзакції. Важливою відмінністю OLAP від OLTP-систем є те, що дані в них зберігають свою істинність в будь-який момент процесу читання.
У OLTP-системах інформація часто модифікується як результат виконання яких-небудь транзакцій. Тимчасова інваріантність даних в OLAP досягається за рахунок введення полів з атрибутом "час" (день, тиждень, місяць) в ключі таблиць. В результаті записи в таблицях OLAP ніколи не змінюються, являючи собою знімки даних, зроблені в певні відрізки часу. В OLAP містяться як би моментальні знімки даних. Кожен елемент у своєму ключі явно або опосередковано зберігає часовий параметр, наприклад день, місяць або рік.
Непорушність - стабільність інформації
У OLTP-системах записи можуть регулярно додаватися, вилучатися і редагуватися. В OLAP-системах, як випливає з вимоги тимчасової інваріантності, одного разу завантажені дані теоретично ніколи не змінюються. По відношенню до них можливі тільки дві операції: початкове завантаження і читання (доступ). Це і визначає специфіку проектування структури бази даних для OLAP. Якщо при створенні OLTP-систем розробники повинні враховувати такі моменти, як відкати транзакцій після збою сервера, боротьба з взаємними блокуваннями процесів (deadlocks), збереження цілісності даних, то для OLAP дані проблеми не настільки актуальні - перед розробниками стоять інші завдання, пов'язані, наприклад, із забезпеченням високої швидкості доступу до даних.
Мінімізація надмірності інформації
Оскільки інформація в OLAP завантажується з OLTP-систем, виникає питання, чи не веде це до надмірної надмірності даних? Насправді надмірність мінімальна (близько 1%!), Що пояснюється наступними причинами:
· при завантаженні інформації з OLTP-cистем в OLAP дані фільтруються. Багато з них взагалі не потрапляють в OLAP, оскільки позбавлені сенсу з точки зору використання в системах підтримки прийняття рішень;
· інформація в OLTP-системах носить, як правило, оперативний характер, і дані, втративши актуальність, видаляються. В OLAP, навпаки, зберігається історична інформація, і з цієї точки зору перекриття вмісту OLAP даними OLTP-систем виявляється досить незначним;
· в OLAP зберігається якась підсумкова інформація, яка в базах даних OLTP-систем взагалі відсутня;
· під час завантаження в OLAP записи сортуються, очищаються від непотрібної інформації та призводять до єдиного формату. Після такої обробки це вже зовсім інші дані.
Централізація і зручне структурування - це далеко не все, що потрібно аналітику. Адже йому ще потрібен інструмент для перегляду та візуалізації інформації. Традиційні звіти, навіть побудовані на основі єдиного сховища, позбавлені одного - гнучкості. Їх не можна "покрутити", "розвернути" або "згорнути", щоб отримати бажане представлення даних. Звичайно, можна викликати програміста, і він зробить новий звіт досить швидко - скажімо, протягом дня. Виходить, що аналітик може перевірити за день не більше однієї-двох ідей. А йому (якщо він хороший аналітик) таких ідей може приходити в голову по декілька на годину. І чим більше "зрізів" і "розрізів" даних аналітик бачить, тим більше у нього ідей, які, в свою чергу, для перевірки вимагають все нових і нових "зрізів". Йому потрібен такий інструмент, який дозволив би розгортати та згортати дані просто і зручно. В якості такого інструменту і виступає OLAP. Хоча OLAP і не являє собою необхідний атрибут сховища даних, він все частіше і частіше застосовується для аналізу накопичених в цьому сховищі відомостей. Компоненти, що входять в типове сховище, представлені на рис.25.3.
Структура сховища даних
Рис.1.3 Структура сховища даних
Оперативні дані збираються з різних джерел, очищаються від непотрібного, інтегруються і складаються в реляційне сховище. При цьому вони вже доступні для аналізу за допомогою різних засобів побудови звітів. Потім дані (повністю або частково) готуються для OLAP-аналізу. Вони можуть бути завантажені в спеціальну БД OLAP або залишені в реляційному сховищі. Найважливішим його елементом є метадані, тобто інформація про структуру, розміщення і трансформацію даних. Завдяки ним забезпечується ефективна взаємодія різних компонентів сховища.
Таким чином, можна визначити OLAP як сукупність засобів багатовимірного аналізу даних, накопичених у сховищі. Теоретично засоби OLAP можна застосовувати і безпосередньо до оперативних даних або їх точним копіям (щоб не заважати оперативним користувачам). Але як вже зазначалося вище оперативні дані безпосередньо для аналізу малопридатні.
Сховище даних складається з наступних компонентів:
· ПЗ проміжного шару;
· транзакційні БД і зовнішні джерела інформації;
· рівень доступу до даних;
· завантаження та попередня обробка;
· інформаційне сховище;
· метадані;
· рівень інформаційного доступу;
· рівень керування (адміністрування).
· ПЗ проміжного шару
Забезпечує мережевий доступ і доступ до баз даних. Сюди відносяться мережні та комунікаційні протоколи, драйвери, системи обміну повідомленнями тощо.
Транзакційні БД і зовнішні джерела інформації
Бази даних OLTP-систем історично призначалися для ефективної обробки структур даних у відносно невеликому числі чітко визначених транзакцій. Через обмеження цільової спрямованості "облікових" систем застосовувані в них структури даних погано підходять для систем підтримки прийняття рішень. Крім того, вік багатьох встановлених OLTP-систем досягає 10 - 15 років.
Рівень доступу до даних
ПЗ, яке відноситься до цього рівня, забезпечує спілкування кінцевих користувачів з інформаційним сховищем і завантаження потрібних даних з транзакційних систем. В даний час універсальною мовою спілкування служить мова структурованих запитів (SQL).
Завантаження та попередня обробка
Цей рівень включає в себе набір засобів для завантаження даних з OLTP-систем та зовнішніх джерел. Виконується, як правило, у поєднанні з додатковою обробкою: перевіркою даних на чистоту, консолідацією, форматуванням, фільтрацією тощо.
Інформаційне сховище
Являє собою ядро всієї системи - один або декілька серверів БД.
Метадані
Метадані (репозиторій, "дані про дані"). Відіграють роль довідника, що містить відомості про джерела первинних даних, алгоритми обробки, яким вихідні дані були піддані тощо.
Рівень інформаційного доступу
Забезпечує безпосереднє спілкування користувача з даними OLAP допомогою стандартних систем маніпулювання, аналізу і надання даних типу MS Excel, MS Access, Lotus 1-2-3 тощо.
Рівень керування (адміністрування)
Відслідковує виконання процедур, необхідних для поновлення інформаційного сховища чи підтримання його стану. Тут програмуються процедури підкачки даних, перебудови індексів, виконання підсумкових (підсумовуючих) розрахунків, реплікації даних, побудови звітів, формування повідомлень користувачам, контролю цілісності тощо.
OLAP надає зручні швидкодіючі засоби доступу, перегляду та аналізу ділової інформації, тому OLAP = багатовимірне представлення = гіперкуб. Користувач отримує природну, інтуїтивно зрозумілу модель даних, організовуючи їх у вигляді багатовимірних кубів (Cubes). Осями багатовимірної системи координат служать основні атрибути аналізованого бізнес-процесу. Наприклад, для продажу це можуть бути товар, регіон, тип покупця. В якості одного з вимірів використовується час. На перетинах осей - вимірювань (Dimensions) - знаходяться дані, що кількісно характеризують процес - значення (Measures). Це можуть бути обсяги продажів у штуках або в грошовому вираженні, залишки на складі, витрати тощо. Користувач, який аналізує інформацію, може "розрізати" куб за різними напрямками, отримувати зведені (наприклад, по роках) або, навпаки, детальні (по тижнях) відомості та здійснювати інші маніпуляції, які йому прийдуть в голову в процесі аналізу.
В якості значень в тривимірному кубі, зображеному на рис.1.4., використані суми продажів, а в якості вимірювань - час, товар і магазин. Вимірювання представлені на певних рівнях угруповання: товари групуються за категоріями, магазини - по країнах, а дані про час здійснення операцій - по місяцях. Трохи пізніше ми розглянемо рівні групування (ієрархії) докладніше.
Рис.1.4 Приклад куба
"Розрізання" куба
Навіть тривимірний куб складно відобразити на екрані комп'ютера так, щоб було видно значення вимірів, які нас цікавлять. Для візуалізації даних, що зберігаються в кубі, застосовуються, як правило, звичайні двовимірні, тобто табличні, уявлення, які мають складні ієрархічні заголовки рядків і стовпців.
Двовимірне представлення куба можна отримати, "розрізавши" його поперек однієї або декількох осей (вимірів): ми фіксуємо значення всіх вимірювань, крім двох, - і отримуємо звичайну двовимірну таблицю. У горизонтальній осі таблиці (заголовки стовпців) представлено один вимір, у вертикальній (заголовки рядків) - інший, а в комірках таблиці - значення продажів. При цьому набір мір фактично розглядається як одне з вимірювань - ми або вибираємо для показу одну міру (і тоді можемо розмістити в заголовках рядків і стовпців два виміри), або показуємо кілька мір (і тоді одну з осей таблиці займуть назви заходів, а іншу - значення єдиного "нерозрізаного" вимірювання).
На рис.1.5 зображений двовимірний зріз куба для одного значення - Unit Sales (продано штук) і двох "нерозрізаних" вимірів - Store (Магазин) і Час (Time).
Рис.1.5 Двовимірний зріз куба для однієї міри
На рис.1.6. представлено лише один "нерозрізаний" вимір - Store, але зате тут відображаються значення декількох мір - Unit Sales (продано штук), Store Sales (сума продажу) та Store Cost (витрати магазину).
Рис.1.6. Двовимірний зріз куба для декількох мір
Двовимірне представлення куба можливо і тоді, коли "нерозрізаними" залишаються і більше двох вимірів. При цьому на осях зрізу (рядках і стовпцях) будуть розміщені два або більше вимірів куба, що розрізається (рис.25.7.).
Рис.1.7 Двовимірний зріз куба з декількома вимірами на одній осі
Мітки
Значення, "відкладені" уздовж вимірювань, називаються членами або мітками (members). Мітки використовуються як для "розрізання" куба, так і для обмеження (фільтрації) вибираних даних - коли у вимірі, що залишається "нерозрізаним", нас цікавлять не всі значення, а їх підмножина, наприклад три міста з декількох десятків. Значення міток відображаються в двовимірному поданні куба як заголовки рядків і стовпців.
Ієрархії та рівні
Мітки можуть об'єднуватися в ієрархії, що складаються з одного або декількох рівнів (levels). Наприклад, мітки виміру "Магазин" (Store) природно об'єднуються в ієрархію з рівнями: All (Світ), Country (Країна), State (Штат), City (Місто), Store (Магазин). У відповідності до рівнів ієрархії обчислюються агрегатні значення, наприклад обсяг продажів для США (рівень "Country") або для штату Каліфорнія (рівень "State"). В одному вимірі можна реалізувати більше однієї ієрархії - скажімо, для часу: {Рік, Квартал, Місяць, День} і {Рік, Тиждень, День}.
Варіанти реалізації сховищ даних:
· віртуальне сховище даних;
· вітрини даних;
· глобальне сховище даних;
· багаторівнева архітектура сховища даних.
· Віртуальне сховище даних
В його основі - репозиторій метаданих, які описують джерела інформації (БД транзакційних систем, зовнішні файли тощо), SQL-запити для їх зчитування та процедури обробки та надання інформації. Безпосередній доступ до останніх забезпечує ПЗ проміжного шару. У цьому випадку надмірність даних нульова. Кінцеві користувачі фактично працюють з транзакційними системами безпосередньо зі всіма плюсами (доступ до "живих" даних в реальному часі) і мінусами (інтенсивний мережевий трафік, зниження продуктивності OLTP-систем та реальна загроза їх працездатності внаслідок невдалих дій користувачів-аналітиків).
Вітрина даних
Вітрина даних (Data Mart) за своїм визначенням - це набір тематично пов'язаних баз даних, які містять інформацію, що відноситься до окремих аспектів діяльності корпорації. По суті справи, вітрина даних - це полегшений варіант сховища даних, що містить лише тематично об'єднані дані. Цільова база даних максимально наближена до кінцевого користувача і може містити тематично орієнтовані агрегатні дані. Вітрина даних, природно, істотно менші за обсягом, ніж корпоративне сховище даних.
Глобальне сховище даних
Останнім часом все більш популярною стає ідея поєднати концепції сховища і вітрини даних в одній реалізації та використовувати сховище даних в якості єдиного джерела інтегрованих даних для всіх вітрин даних. Тоді природною стає така трирівнева архітектура системи:
На першому рівні реалізується корпоративне сховище даних на основі однієї з розвинених сучасних реляційних СКБД. Це сховище інтегрованих в основному деталізованих даних. Реляційні СКБД забезпечують ефективне збереження та управління даними дуже великого обсягу, але не дуже добре відповідають потребам OLAP-систем, зокрема, у зв'язку з вимогою багатовимірного представлення даних.
На другому рівні підтримуються вітрини даних на основі багатовимірної системи управління базами даних (прикладом такої системи є Oracle Express Server). Такі СКБД майже ідеально підходять для цілей розробки OLAP-систем, але поки що не дозволяють зберігати надвеликі обсяги даних (граничний розмір багатовимірної бази даних становить 10-40 ГБайт). В даному випадку це і не потрібно, оскільки мова йде про вітрини даних. Зауважимо, що вітрина даних не обов'язково повинна бути повністю сформована. Вона може містити посилання на сховище даних і добирати звідти інформацію по мірі надходження запитів. Звичайно, це дещо збільшує час відгуку, але зате знімає проблему обмеженого обсягу багатовимірної бази даних.
Нарешті, на третьому рівні знаходяться клієнтські робочі місця кінцевих користувачів, на яких встановлюються засоби оперативного аналізу даних.
Розділ 2. Deductor Studio. Загальні відомості та його особливості і версії
2.1 Deductor Studio
Deductor - аналітична платформа, яка дозволяє в короткі терміни створити ефективну систему підтримки прийняття бізнес-рішень. Deductor є повнофункціональною платформою для вирішення завдань Knowledge Discovery in Databases, що дозволяє провести всі нижчеописані кроки. Підготовка початкового набору даних. До складу системи входить Deductor Warehouse - багатовимірне сховище даних, що орієнтоване на рішення задач консолідації інформації з різнорідних джерел і швидкого видобутку потрібного набору даних. Deductor Warehouse підтримує потужний семантичний прошарок, що дозволяє кінцевому користувачеві оперувати бізнес термінами для отримання потрібних даних. Окрім власного сховища Deductor підтримує роботу і з іншими джерелами: Oracle, DB2, MS SQL, Informix, Sybase, Interbase, DBase, FoxPro, Paradox, MS Access, CSV (текстові файли з роздільниками), ODBC, ADO. Для забезпечення максимальної швидкодії Deductor підтримує прямий (direct) доступ до більшості найпопулярніших баз даних. Передобробка. Deductor містить великий набір механізмів передобробки і очищення даних: заповнення пропусків, редагування аномалій, очищення від шумів, згладжування, фільтрація і багато чого іншого з можливістю комбінування методів передобробки. Трансформація, нормалізація даних. Deductor містить великий набір механізмів трансформації даних, що дозволяють провести всю підготовчу роботу для подальшого аналізу. Окрім цього, система містить широкий спектр механізмів нормалізації для всіх типів даних: числових, рядкових, дата/час і логічних. Data Mining. У складі пакету містяться алгоритми, що реалізують популярні та ефективні методи Data Mining: нейронні мережі, дерева рішень, самоорганізовані карти Кохонена, асоціативні правила тощо. Постобробка даних. Результати будь-якої обробки можуть бути відображені за допомогою великого набору механізмів візуалізації: OLAP, таблиці, діаграми, дерева тощо. Для деяких механізмів передбачені спеціалізовані візуалізатори, які забезпечують легкість інтерпретації результатів. Результати можна експортувати для подальшої обробки за допомогою інших додатків. Це дає можливість ефективно використовувати отримані знання або моделі на інших даних. Deductor задовольняє всі вимоги для успішної взаємодії з експертом (аналітиком):
· єдина платформа, в якій можна пройти всі етапи Knowledge Discovery in Databases;
· всі операції проводяться за допомогою майстрів, завдяки яким знижуються вимоги до знання експертом математичного апарату;
· можливість довільного комбінування будь-яких методів обробки;
· великий набір методів візуалізації отриманих результатів;
· пакетне виконання всій дій по обробці даних.
2.2 Версії та задачі Deductor Studio
Склад системи Deductor:
· Studio - программа, яка реалізує функції імпорту, обробки, візуалізації и експорту даних;
· Viewer - робоче місце кінцевого користувача. Дозволяє відділити процес побудови сценаріїв від користування уже готовими моделями;
· Warehouse - багатомірне сховище даних, яке акумулює всю необхідну для аналізу предметної області інформацію;
· Server - служба, яка забезпечує віддалену аналітичну обробку даних;
· Client - клієнт доступу до Deductor Server. Він забезпечує доступ до сервера із сторонніх додатків і управління його роботою.
Версії Deductor:
· Enterprise - призначена для корпоративного використання. В ній реалізовані всі функції, що і у версії Professional. Крім того, в поставку даної версії входять Deductor Server і Deductor Client для віддаленої роботи з системою, підтримка сховищ даних на платформах Oracle і MS SQL, підтримка концепції віртуального сховища даних, реалізація OLE-сервера і інші механізми, які необхідні для корпоративного використання аналітичної платформи.
· Professional - призначена для невеликих компаній і однокористувацької роботи. В цій версії відсутні обмеження на кількість оброблювальних записів, підтримується робота з великою кількістю джерел, сховищем даних на базі бесплатної СУБД Firebird, пакетне виконання сценаріїв, всі механізми обробки і візуалізації даних.
· Academic - бесплатна версія, яка призначена тільки для навчальних цілей. Використання цієї версії у комерційних цілях заборонено. В ній обмежені можливості інтеграції і автоматичної обробки. Підтримується лише 2 джерела і приймача даних: Deductor Warehouse и текстові файли с роздільниками.
Задачі, що вирішує Deductor:
· прогнозування;
· стимулювання попиту;
· сегментація клієнтів;
· оптимізація цінової політики;
· аналітична звітність;
· управління ризиками при кредитуванні фізичних и юридичних осіб;
· оцінка кредитоспроможності;
· визначення профіля клієнтів і особливостей їх поведінки;
· виявлення випадків махінацій.
Розділ 3. Deductor Studio як інструмент кластеризації українських регіонів
3.1 Постановка проблеми у загальному вигляді, її зв'язок з актуальними теоретичними та практичними завданнями
Аналіз інформації є невід'ємною частиною ведення бізнесу і одним з важливих чинників підвищення його конкурентоспроможності. При цьому в переважній більшості випадків усе зводиться до застосування одних і тих же базових механізмів аналізу. Вони є універсальними і застосовні до будь-якої предметної області, завдяки цьому є можливість створення уніфікованої програмної платформи, в якій реалізовані основні механізми аналізу. Data Mining - це не один, а сукупність великого числа різних методів виявлення знань. Всі задачі, вирішувані методами Data Mining, можна умовно розбити на п'ять класів:
· класифікація,
· кластеризація,
· регресія,
· асоціація,
· послідовні шаблони.
Кластеризація - це угрупування об'єктів (спостережень, подій) на основі даних (властивостей), що описують суть об'єктів.
Для вирішення вищеперелічених задач використовуються різні методи і алгоритми Data Mining. З огляду на те, що Data Mining розвивався і розвивається на стику таких дисциплін, як математика, статистика, теорія інформації, машинне навчання, теорія баз даних, цілком закономірно, що більшість алгоритмів і методів Data Mining були розроблені на основі різних методів з цих дисциплін. На сьогодні найбільше розповсюдження отримали самонавчальні методи і машинне навчання. Deductor - це аналітична платформа, основа для створення закінчених прикладних рішень в області аналізу даних. Архітектура системи побудована таким чином, що вся робота по аналізу даних в Deductor Studio базується на виконанні наступних дій:
· імпорт даних,
· обробка даних,
· візуалізація,
· експорт даних.
Процес побудови моделей в Deductor ґрунтується на наступних трьох принципах:
· використання обробників,
· використання візуалізаторів,
· створення сценаріїв.
Оскільки візуалізація допомагає інтерпретувати побудовані моделі, в Deductor Warehouse передбачено велику кількість способів візуалізації даних.
Аналіз останніх досліджень і публікацій. В останні роки бізнес-аналітична платформа Deductor почала застосовуватися для оцінки степені екологічної безпеки регіонів України.
Кластеризація проводилася за допомогою карти Кохонена та алгоритму k-means вбізнес-аналітичній платформі Deductor за даними, які приведені в таблицях 1 та 2.
Таблиця 1. Соціально-економічні показники регіонів в 2012 році
Таблиця 2
Соціально-економічні показники українських регіонів в 2013 році
Розподіл вихідного набору даних із таблиць 1 та 2 на кластери проводився за допомогою бізнес-аналітичної платформи Deductor та обробників карта Кохонена і кластеризація алгоритмом k-means. Серед візуалізаторів бізнес-аналітичної платформи Deductor, які застосовуються для відображення процесу кластеризації найбільш інформативні кубічна модель (OLAP-куб багатовимірне представлення даних. Будь-які дані, що використовуються в програмі, можна подивитися у вигляді крос-таблиці і крос-діаграми), карти Кохонена (відображення карт, побудованих за допомогою відповідного алгоритму) та профілі кластерів.
Для проведення дослідження, таблиці 1 та 2 були збережені у форматі *. txt і імпортовані в бізнес-аналітичну платформу Deductor. Призначення стовпчиків таблиці для аналізу було таким:
Україна - інформаційне поле,
решту - вхідні поля.
Кількість кластерів вибиралась вручну, рівною 2, 3 та 4 тому, що при автоматичному виборі числа кластерів були отримані результати з числом кластерів, які були рівними 27 і навіть більшими.
При кластеризації українських регіонів по соціально-економічних показниках 2013 року на 2 кластери отримані такі результати:
карта Кохонена в 0 кластер потрапили такі регіони - АР Крим, Київська, Одеська, Київ, Севастополь, решту областей потрапили у 1 кластер;
алгоритм k-means в 0 кластер потрапили такі області та міста: Київська, Київ, Севастополь, решту регіонів потрапили у 1 кластер.
Порівняння результатів отриманих за різними алгоритмами показує, що карта Кохонена відносить в 0 кластер на відміну від алгоритму k-means - АР Крим та Одеську область.
Результати кластеризації по соціально-економічних показниках 2012 року на 2 кластери:
карти Кохонена в 0 кластер потрапили такі області та міста - Київська, Одеська, Харківська, Київ, Севастополь, решту регіонів потрапили у 1 кластер;
алгоритм k-means в 0 кластер потрапили такі області та міста - Київська, Одеська, Харківська, Київ, Севастополь, решту регіонів потрапили у 1 кластер.
При порівнянні приведених вище результатів видно, що розподіл регіонів у кластерах отриманих різними алгоритмами однаковий.
Порівняння результатів кластеризації на 2 кластери, які отримані за різними алгоритмами по соціально-економічних показниках 2011 та 2012 років показують, що властивості однакових кластерів подібні. Не спостерігається також чіткого розподілу українських регіонів у кластерах на "Схід-Захід", "Північ-Південь".
Аналіз результатів кластеризації за різні роки із застосуванням різних алгоритмів доцільно проводити за допомогою кубічної моделі або профілів кластерів. Кубічна модель даних розподілу українських регіонів на два кластери за допомогою карти Кохонена приведена на рис.3.1 Вона наглядно представляє показники кожної із груп, дозволяє обробляти їх, як по окремих показниках в регіонах, так і по всіх показниках кожного регіону.
Рис.3.1 Кубічна модель даних з результатом розподілу регіонів України на два кластери за допомогою карт Кохонена
Результати кластеризації по соціально-економічних показниках 2013 року на 3 кластери:
карта Кохонена в 0 кластер потрапили такі регіони - АР Крим, Київська, Одеська, Київ, Севастополь, в 1 кластер потрапили такі області - Дніпропетровська, Донецька, Запорізька, Луганська, решту областей потрапили у 2 кластер;
алгоритм k-means в 0 кластер потрапили такі регіони - АР Крим, Київська, Одеська, Київ, Севастополь, в 1 кластер потрапили такі області - Дніпропетровська, Донецька, Запорізька, Луганська, Полтавська, решту областей потрапили у 2 кластер.
Порівняння результатів отриманих за різними алгоритмами показує, що алгоритм k-means відносить в 1 кластер на відміну від карти Кохонена - Полтавську область.
При кластеризації українських регіонів по соціально-екномічних показниках 2012 року на 3 кластери отримані такі результати:
...Подобные документы
Реалізація сегментації позичальників методом карт Кохонена за допомогою пакету Deductor Studio. Послідовність дій, які необхідно провести для аналізу даних у Deductor Studio. Результат сегментації на картах Кохонена та характеристика кожного сегменту.
контрольная работа [1017,1 K], добавлен 29.09.2010Короткі теоретичні відомості про Deductor – аналітичну платформу, призначену для створення логічно завершених прикладних рішень в області аналізу даних. Основи роботи з аналітичною платформою Deductor виробництва російської компанії BaseGroup Labs.
лабораторная работа [1,4 M], добавлен 14.10.2014Описание платформы Deductor, ее назначение. Организационная структура аналитической платформы Deductor, состав модулей. Принципы работы программы, импорт и экспорт данных. Визуализация информации, сценарная последовательность и мастер обработки.
курсовая работа [3,7 M], добавлен 19.04.2014Основні ознаки, що дозволяють здійснювати ідентифікацію складних об’єктів моніторингу на основі нечітких алгоритмів кластерного аналізу. Вибір доцільного алгоритму кластеризації складних об’єктів моніторингу та синтез математичної моделі кластеризації.
курсовая работа [1,2 M], добавлен 12.01.2016Оцифровування карти за допомогою програмного продукту ArcGis. Порівняння методів інтерполяції за допомогою програмних продуктів Surfer та ArcGis. Згладжування отриманих сіткових даних за допомогою сплайнів і фільтрації. Застосування сіткових чисел.
курсовая работа [2,1 M], добавлен 31.01.2014Определение понятия знания, модели его представления – фреймовая, продукционная, семантическая. Разбор аналитической платформы Deductor. Описание демо-примера программы Deductor– прогнозирование с помощью линейной регрессии, использование визуализатора.
курсовая работа [1,1 M], добавлен 07.06.2011Бібліотека Pcap та її реалізація WinPcap під платформу Windows. Аспекти робот з бібліотекою WinPcap. Штучні нейронні мережі. Застосування бібліотеки Winpcap для захоплення мережевого трафіку. Реалізація нейронної мережі Кохонена для аналізу заголовків.
дипломная работа [2,2 M], добавлен 09.06.2012Сутність та значення алгоритму пошуку асоціативних правил, задачі та сфера використання. Приклад розрахунку показників транзакцій в супермаркеті. Особливості видозміни асоціативних правил. Ознайомлення з аналітичною платформою Deductor, її робота.
лабораторная работа [1,3 M], добавлен 19.03.2011Сучасна практика складання бізнес-плану, методики та стандарти його розробки. Програмні засоби бізнес-планування. Характеристика та особливості застосування пакету деяких прикладних програм: COMFAR, Project Expert, Альт-Інвест та Альт-Інвест-Прим.
реферат [22,9 K], добавлен 03.06.2011Сущность, структура, алгоритм функционирования самообучающихся карт. Начальная инициализация и обучение карты. Сущность и задачи кластеризации. Создание нейронной сети со слоем Кохонена при помощи встроенной в среды Matlab. Отличия сети Кохонена от SOM.
лабораторная работа [36,1 K], добавлен 05.10.2010Дослідження сучасної практики складання бізнес-плану діяльності підприємства. Характеристика сучасних методик, стандартів розробки та програмних засобів бізнес-планування: пакет прикладних програм COMFAR, Project Expert, Альт-Інвест та Альт-Інвест-Прим.
реферат [27,6 K], добавлен 08.08.2011Робота з фінансово-аналітичною інформаційною системою Project Expert; основні функції та модулі системи, їхній опис. Використання системи для створення інвестиційних проектів, їх аналізу та формування бізнес-плану. Опис послідовності виконання завдання.
лабораторная работа [20,5 K], добавлен 03.03.2009Розробка програмних модулів базових операцій обробки на підставі розрядно-логарифмічного кодування. Дослідження алгоритму розв'язку системи лінійних алгебраїчних рівнянь. Реалізація алгоритму Гауса. Покращення точності розрахунків за допомогою рл-чисел.
курсовая работа [427,2 K], добавлен 20.11.2013Дослідження етапів розробки програмної реалізації криптографічного алгоритму RC5. Опис об'єкту, що потребує захисту: операційне середовище, тип програмного забезпечення. Блок-схема алгоритму функціонування програми криптозахисту. Листінг тесту програми.
курсовая работа [4,4 M], добавлен 28.10.2010Проектування процесора для виконання (з використанням доповняльного коду без відновлення розрядів остачі) операції ділення в двійково-десятковій системі числення. Розробка алгоритму виконання операції та операційного автомату. Розробка карти прошивки.
курсовая работа [263,3 K], добавлен 14.03.2013Кластеризація як альтернатива побудови симетричних мультипроцесорних систем. Вища продуктивність і "живучість" обчислювальних комплексів як переваги кластеризації. Особливості варіантів структури кластерів. Види комплексів з активним вторинним вузлом.
реферат [25,6 K], добавлен 08.09.2011Розробка програми для моделювання роботи алгоритму Дейкстри мовою C# з використанням об’єктно-орієнтованих принципів програмування. Алгоритм побудови робочого поля. Програмування графічного інтерфейсу користувача. Тестування програмного забезпечення.
курсовая работа [991,4 K], добавлен 06.08.2013Побудова блок-схеми алгоритму проста вставка. Програмна реалізація алгоритму, опис результатів. Особливості обліку ітерації масивів. Відсортування даних за допомогою програми Turbo Pascal. Аналітична оцінка трудомісткості, графічне представлення.
контрольная работа [570,1 K], добавлен 21.05.2014Засвоєння засобів аналізу трудомісткості обчислювальних алгоритмів. Побудова графа алгоритму з отриманої блок-схеми. Мінімізація графа, його подання у вигляді стохастичної матриці. Знаходження кількості звернень до файлів за допомогою Microsoft Excel.
лабораторная работа [681,5 K], добавлен 02.06.2011Поняття черги в програмуванні, основні операції з чергою і їх реалізація. Опис алгоритму й специфікація програми. Розробка додатку з використанням задачі Ларсона по опису зв'язного неорієнтованого графа. Алгоритм розв’язку і результати виконання програми.
курсовая работа [1,1 M], добавлен 14.09.2012
