Додати в закладки
Переклад
Translate
 Вхід в УЧАН Анонімний форум з обміну зображеннями і жартами. |
|
|
Скачати одним файлом. Книга: Моделювання та інформаційні системи в економіці: Міжвід. М.Г. Твердохліб
СУМІСНЕ ВИКОРИСТАННЯ КОНЦЕПЦІЙ СТРУКТУРНОГО МОДЕЛЮВАННЯ ТА БАГАТОВИМІРНИХ БАЗ ДАНИХ ЯК ІНСТРУМЕНТ СТВОРЕННЯ ЕФЕКТИВНОЇ СППР
Створення або реорганізація людиною будь-якої системи завжди має певну мету, досягнення чи недосягнення якої можна оцінити за допомогою тих чи інших критеріїв ефективності. У випадку, коли значення критеріїв ефективності досягають прийнятного рівня або перевищують його, можна стверджувати, що діяльність і зусилля людей були доцільними та принесли користь. Разом із тим, як показує практика, у ході реалізації багатьох проектів, у тому числі й таких серйозних, як побудова АЕС, водо сховищ та ін., часто припускаються помилок, які можуть призвести не тільки до того, що не досягаються заплановані показники, а й до цілої низки побічних ефектів. Ці ефекти мають непередбачувані руйнівні наслідки (значні економічні збитки, екологічні катастрофи і навіть понівечені людські долі). Виходячи з цього, а також із того, що на сьогоднішній день людство має у своєму розпорядженні надзвичайно потужні технології, неправильне використання яких може призвести до справді фатальних наслідків, ми можемо стверджувати, що ніхто просто не має права створювати більш-менш серйозну потужну систему без попереднього ретельного її проектування та імітаційного моделювання всіх можливих процесів у ній [2]. Одним із шляхів розв’язання цієї проблеми є використання систем підтримки прийняття рішень (СППР), які б допомогли відповідальним за ті чи інші процеси особам приймати вірні рішення в найрізноманітніших ситуаціях.
Основними компонентами СППР, що визначають її якість та ефективність, є система управління базою моделей (СУБМ) та система управління базою даних (СУБД) [1]. На сьогоднішній день існує чимала кількість різноманітних потужних засобів, за допомогою яких можна реалізовувати процеси управління моделюванням та даними. Одним із найважливіших завдань особи, що створює систему підтримки прийняття рішень, є найліпший вибір СУБМ та СУБД. Разом із тим, на мою думку, найліпший вибір полягає не в тому, щоб обрати найпотужніші та найвідоміші СУБМ та СУБД і спробувати щось створити на їхній основі, а в тому, щоб знайти дві системи, які б органічно доповнювали одна одну і які б взаємно підсилювали свої найкращі сторони, нівелюючи при цьому можливі огріхи.
Дуже цікавим та ефективним варіантом для побудови СППР є спільне використання концепції структурного моделювання, що є основою підсистеми керування моделями, та концепції багатовимірних баз даних як основи для підсистеми управління даними. Розглянемо можливості побудови СППР на основі структурного моделювання та багатовимірних баз даних докладніше.
Будь-який об’єкт чи категорія об’єктів, для управління якими створюється система підтримки прийняття рішень, відображаються в ній за допомогою моделей. Тож перш ніж перейти безпосередньо до розгляду методів управління даними та до моделювання, визначимо поняття моделі та її складових, що необхідні для подальшого просування.
Модель — це комплексне математичне й алгоритмічне відображення об’єкта, що досліджується.
Модель має максимально повно відобразити всі компоненти досліджуваної системи, і, зокрема, її інфраструктуру , її процеси , характеристики процесів і станів, притаманних системі. Покажемо більш докладно, що саме вкладається в поняття «інфраструктура», процеси та характеристики процесів і станів системи.
Інфраструктура системи — це сукупність усіх матеріальних об’єктів, що входять до складу системи, та осіб, що підтримують функціонування цих об’єктів, користуються їхньою роботою або певним чином взаємодіють із об’єктами або іншими особами, причетними до системи, подаючи таким чином певні керівні імпульси іншим складовим системи, що впливають на протікання всіх процесів системи й реалізацію нею своїх функцій.
Щоб краще зрозуміти дане поняття, звернемося до прикладу. У якості системи, що досліджується, розглянемо систему обслуговування банківських платіжних карток. Для того, щоб така си- стема була здатна виконувати свої функції, вона має включати:
— технічну складову у вигляді банкоматів, РОS-терміналів, імпринтерів, серверів тощо;
— користувачів системи в особі банківських клієнтів, які отримують кошти через мережу банкоматів, розраховуються за товари в крамницях через термінали, надають банку розпорядження стосовно управління їхніми картковими рахунками;
— персонал в особі банківських працівників та продавців магазинів, що підтримують життєдіяльність системи, виконують розпорядження клієнтів тощо.
У даному випадку саме технічна складова, клієнти та персонал утворюють те, що в даній статті називається інфраструктурою. Зокрема, технічна складова — це перелік матеріальних об’єктів системи, а клієнти та персонал являють собою осіб, взаємодія яких між собою та з технічною інфраструктурою системи надає їй керівного впливу та ініціює різного роду процеси, що приводять до реалізації системою своїх функцій.
Процес системи — це будь-яка подія, яка відбувається в си- стемі внаслідок взаємодії елементів інфраструктури системи.
За такого визначення процесу, прикладом його в системі обслуговування банківських платіжних карток може бути отримання клієнтом готівки через банкомат, купівля товару в магазині через термінал, унесення коштів на картковий рахунок тощо.
Кожен із наведених у прикладі процесів можна охарактеризувати за допомогою якихось числових значень. Так, процес отримання клієнтом коштів через банкомат характеризується сумою замовленої готівки. Аналогічно можна охарактеризувати й процес купівлі товару за допомогою банківської картки. У даному разі суми виданих банкоматом коштів та сума покупки в магазині є характеристиками процесів . Слід однак зазначити, що не лише процеси, котрі виникають унаслідок взаємодії елементів інфраструктури, можуть характерізуватися певними значеннями. Статичні стани системи також можуть потребувати певних характеристик, що мають суттєве значення для аналізу системи. Наприклад, сума коштів на картковому рахунку клієнта станом на певну дату або залишок коштів у банкоматі також є суттєвими характеристиками системи, які не стосуються напряму якихось динамічних процесів, але визначають важливі стани об’єктів системи. Ці та подібні до них показники є характеристиками станів системи.
Отже, ми визначилися з тим, що таке модель, і розглянули з певної точки зору загальну структуру будь-якої системи, яка відображається за допомогою моделей. Розглянемо тепер, яким чином систему можна змоделювати, використовуючи підходи концепції структурного моделювання.
Розгляд загальних засад структурного моделювання не є предметом даної статті. А з інформацією щодо концептуальних засад структурного моделювання можна ознайомитися в інших джерелах [5]. Зараз же покажемо, як за допомогою базових елементів структурного моделювання можна чітко й органічно відобразити певну систему.
Отже, структурна модель системи являє собою спрямований граф, побудований на основі елементів таких п’яти типів: первинні об’єкти, складені об’єкти, атрибути, функції, тести. Розглянемо докладніше зміст кожного типу елементів.
1. Первинний об’єкт (Primary entity — PE). Відображає сутність певної системи. Не має асоційованих значень.
2. Складений об’єкт (Compound entity — CE). Відображає певну сутність системи, визначення якої спирається на один чи кілька вже визначених об’єктів. Об’єкти, на які спираються складені об’єкти, можуть бути первинними або складеними. Складені об’єкти також не мають асоційованих значень.
3. Атрибути (Attributes — ATTR). Ці елементи визначаються у зв’язку з первинним чи складеним об’єктом або їх групою і відображають значення деякої властивості, що характеризує той чи інший об’єкт.
4. Функція (Function — FUNC). Правило, яке асоціюється з більш ніж одним об’єктом, що підтримує роботу зі значеннями.
5. Тест (Test — TEST). Цей елемент є цілком ідентичним до елементу «функція», із тією лише різницею, що тестовий елемент може набувати двох значень: «Істина» та «Хибність».
Наведені вище елементи структурного моделювання майже ідеально підходять для відображення за їхньою допомогою будь-якої системи, що підлягає моделюванню. Зокрема, усі елементи інфраструктури системи чітко відображаються за допомогою первинних об’єктів структурного моделювання. Наприклад, перелік банкоматів або список клієнтів — це предмети відображення первинними об’єктами структурного моделювання.
Усі явища, які виникають унаслідок взаємодії об’єктів інфраструктури системи, або в термінах структурного моделювання внаслідок взаємодії первинних об’єктів, є процесами системи. Це означає, що комбінація первинних об’єктів структурної моделі визначає процес системи. Разом із тим комбінація первинних об’єктів моделі визначає складені об’єкти моделі, і звідси випливає, що складений об’єкт структурного моделювання ідентифікує процес системи.
Перебіг процесу системи описується за допомогою характеристик процесу. Разом із тим кожен складений об’єкт структурної моделі характеризується атрибутами структурної моделі. Отже, ми можемо стверджувати, що будь-яка характеристика системи в термінах структурного моделювання відображається за допомогою атрибутів структурної моделі.
Ми бачимо, що всі складові будь-якої системи, яка моделюється, чітко відображаються за допомогою перших трьох типів елементів, покладених в основу структурного моделювання. Разом із тим структурне моделювання не зупиняється на тому, що за його допомогою можна чітко описати всі компоненти системи. За рахунок наступних двох елементів структурного моделювання — функцій та тестів — модель системи стає значно глибшою.
Функції структурного моделювання дозволяють агрегувати характеристики процесів системи завдяки використанню атрибутів структурного моделювання й розраховувати необхідні для аналізу системи показники.
Тестові елементи структурного моделювання є чудовим прототипом оцінки значень критеріїв ефективності моделі. За своєю суттю тест — це функція, яка порівнює значення певного критерію ефективності структурної моделі, розрахованого за допомо гою елемента-функції, із запланованим значенням критерію ефективності, і сигналізує про відповідність цього значення запла нованим значенням критерію.
Отже, очевидним є те, що структурне моделювання є чудовим засобом для чіткого відображення та глибокого аналізу дослідної системи.
Наступним важливим компонентом системи підтримки прийняття рішень є система управління даними. В основі будь-якої системи управління даними сучасної СППР лежить концепція сховища даних, яке формується шляхом імпорту в нього спеціальним чином відформатованих даних із різного роду транзактних баз даних, які містять у собі інформацію про функціонування окремих підсистем об’єкта дослідження.
Формування сховища даних розглянемо на прикладі банку. Будь-який сучасний потужний банк має, як правило, щонайменше декілька транзактних баз даних, які відображають у собі реалізацію функцій ОДБ банку, карткових систем банку тощо. Крім того, кожна окрема філія банку, як правило, має свої окремі бази даних, які, до того ж, часто знаходяться під управлінням різних СУБД. Під час формування сховища даних, яке ведеться в головному офісі банку, дані з кожної бази даних спочатку очищаються від непотрібної для аналізу технологічної інформації (тобто підвищується їхня якість), потім їх зводять до відповідних уніфікованих форматів, які підтримуються сховищем даних, а вже потім імпортуються в це сховище.
Утім, ключовим питанням під час формування сховища даних є логічна архітектура, яка лежить у його основі. У даному дослідженні розглянемо концепцію багатовимірної бази даних як основи сховища даних, котра не тільки дозволяє ефективно зберігати дані про діяльність системи, а й органічно поєднується з моделями системи, які побудовано засобами структурного моделювання.
Багатомірна база даних будується на основі таблиць даних двох типів [6]:
— таблиці фактів;
— таблиці вимірів.
Таблиця фактів — це таблиця, що містить у собі необхідну інформацію про всі події, процеси чи стани, які певним чином характеризують систему.
Таблиця вимірів — це таблиця, що містить у собі довідкові дані, котрі характеризують компоненти системи та на основі котрих функціонує система й відбуваються всі її процеси.
Розглянемо більш докладно таблиці кожного типу. Розпочнемо з таблиць вимірів. Для прикладу візьмемо таблицю вимірів, яка характеризує територіальну належність об’єкта на рівнях ієрархії «місто», «район», «вулиця». Дана таблиця вимірів складатиметься з таких полів:
СоmpoundId — складений ключ, який однозначно ідентифікує об’єкт на найнижчому рівні ієрархії;
CityId — ключ на рівні ієрархії «місто»;
City — назва міста;
DistrictId — ключ на рівні ієрархії «район»;
District — назва району;
StreetId — ключ на рівні ієрархії «вулиця»;
Street — назва вулиці.
Структуру таблиці виміру територіальної належності об’єкта показано на рис. 1.
| CompoundId | CityId | City | DistrictId | District | StreetId | Street | ….. | ….. | ….. | ….. | ….. | ….. | ….. |
На перший погляд, наведена таблиця може здатися жахливою (особливо якщо дивитися на неї з точки зору реляційної теорії баз даних), оскільки вона є ненормалізованою та характеризується надзвичайною збитковістю даних, яку легко усунути засобами проектування реляційних баз даних [3]. Це справді вада, яка, утім, не є суттєвою за врахування тих двох обставин, що, по-перше, вона притаманна лише таблицям вимірів багатовимірної бази даних (складають усього 3—5 % загального обсягу сховища даних [4]), і, по-друге, сучасний рівень розвитку технологій відсуває проблему вартості додаткової пам’яті на другий план відносно можливості забезпечення чіткої та прозорої логіки автоматизованої системи, яка б гарантувала її гнучкість і легку модифікацію.
Разом із тим, за такого підходу до проектування даних ми отримуємо іншу надзвичайно важливу перевагу під час побудови СППР у цілому, оскільки в одній таблиці сховища даних цілісно відображається вся необхідна інформація про відповідний інфраструктурний елемент дослідної системи, яка відповідає певному первинному об’єкту структурної моделі системи. Крім того, запропонована структура таблиці вимірів полегшує доступ до будь-якого елемента інфраструктури системи на будь-якому рівні ієрархії, що є дуже важливою перевагою під час реалізації відповідної моделі СППР.
Розглянемо тепер, який вигляд мають таблиці фактів багатовимірної бази даних, у яких відображається все, що відбувається в системі. Структуру таблиці фактів багатомірної бази даних наведено на рис. 2.
| MainId | CompoundId1 | ….. | CompoundIdN | Value1 | ….. | ValueN | ….. | ….. | ….. | ….. | ….. | ….. | ….. |
У наведеній структурі поля CompoundId1 та CompoundIdN відповідають первинним ключам таблиць вимірів і слугують для зв’язку таблиці фактів із цими таблицями. По суті, кожен запис поля CompoundId1 у таблиці фактів однозначно ідентифікує елемент інфраструктури системи (а отже, і відповідний елемент первинного об’єкта структурної моделі), що брав участь у події, яку охарактеризовано відповідним рядком у таблиці фактів багатовимірної бази даних.
Поле MainId однозначно ідентифікує подію, стан чи процес системи, які відбувалися за участі інфраструктурних елементів, ідентифікованих полями CompoundId1 . У термінах структурного моделювання поля CompoundId1 , які визначають поле MainId , відповідають первинним об’єктам, а отже, MainId репрезентує певний складений об’єкт структурної моделі системи.
Поле Value1 містить у собі значення, що характеризує певний процес, стан чи подію системи, котрі відбулися за участі відповідних інфраструктурних елементів системи. У термінах структур ного моделювання значення поля Value1 відповідає значенню певного атрибуту, що характеризує складений об’єкт структурної моделі системи.
Таким чином, розглянувши основи проектування багатовимірної бази даних, ми пересвідчилися в тому, що вона може бути побудованою так, щоб в ній було чітко і структуровано відображено дослідну систему будь-якого рівня складності з охопленням усіх елементів найнижчого необхідного рівня деталізації, і що кожне її поле буде слугувати відображенням певного об’єкта структурної моделі системи.
Отже, у даній роботі ми розглянули можливості спільного використання засобів структурного моделювання й багатовимірних баз даних як основи створення СППР і дійшли висновку, що подібне поєднання є вельми ефективним і здатним забезпечити надійний базис для створення потужної, структурованої, прозорої, гнучкої конкурентоспроможної системи підтримки прийняття рішень.
СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ
1. Ситник В. Ф. Системи підтримки прийняття рішень. — К.: Техніка, 1995. — 162 с.
2. Ситник В. Ф., Орленко Н. С. Імітаційне моделювання. — К.: КНЕУ, 1998. — 234 с.
3. Єрьоміна Н. В. Проектування баз даних. — К.: КНЕУ, 1998. — 208 с.
4. Спирли Е. Корпоративные хранилища данных. Планирование, разработка, реализация. — М.: Вильямс, 2001. — 400 с.
5. Geoffrion A. Structured modeling: Survey and future research directions. — ITORMS, 1999.
6. www.olap.ru/OLAP2.htm.
А. І. СЕМЕНЧЕНКО , канд. техн. наук,
Національний інститут стратегічних досліджень при Адміністрації Президента України
Книга: Моделювання та інформаційні системи в економіці: Міжвід. М.Г. Твердохліб
ЗМІСТ
На попередню
|
|
