Статьи по экономическим темам

Редич О. В. Начальник відділу Академії державної податкової служби України

Перехід підрозділів податкової служби на функціональну організаційну структуру приведе до зміни традиційних технологій і процедур податкових адміністрацій (модифікація і розробка одних, скасування інших). Перелік процедур та їх зміст, в першу чергу, визначить структуру інформаційного, апаратного та програмного забезпечення корпоративної автоматизованої інформаційної системи (КАІС).

Модернізація КАІС державної податкової служби України (ДПСУ) повинна базуватись на використанні концепції сховищ даних (СД, Data Warehouse (DW)). Інформаційні системи (ІС) побудовані на базі СД призначені для збору, інтеграції та аналітичної обробки даних, впровадження на їх основі систем підтримки прийняття рішень (СППР). СД в даному контексті розглядається як засіб інтеграції даних різних систем управління базами даних (СУБД), що можуть бути розподілені територіально (наприклад бази даних обласних ДПА можуть стати елементами розподіленого сховища даних ДПСУ). Важливу роль при впровадженні СД грають метадані що вміщують знання про структуру існуючих баз даних (БД), тип та формат інформації що зберігається в БД, зв’язки між інформаційними об’єктами, семантику інформаційних об’єктів та їх атрибути. Відомо, що всі вказані знання, можна отримати використовуючи методологію реінжинірингу (Business Process Reengineering (BPR)), або бізнес-аналізу.

За програмою Integrated Computer-Aided Manufacturing в США розроблена цілісна сукупність методик концептуального проектування та реінжинірингу складних, неструктурованих систем IDEF (Integrated Definition) [1]. В даній сукупності є методики функціонального, інформаційного та імітаційного проектування (табл.1).

Найвідомішою методикою функціонального моделювання складних систем є методика SADT (Structured Analysis and Design Technique), що була запропонована в 1973 р. Д. Россом і в подальшому стала основою стандарту IDEF0. Цю методику можна рекомендувати для початкових стадій проектування інформаційної системи ДПСУ на основі сховищ даних.

Таблиця 1.

Назва методики

Призначення

IDEF0

Функціональне моделювання (Function Modeling Method)

IDEF1 IDEF1Х

Інформаційне моделювання (Infomation and Data Modelling Methods)

IDEF2

Імітаційне моделювання (Simulation Modeling method)

IDEF3

Моделювання процесів (Process Flow and Object State Description Capture Method)

IDEF4

Об'єктно-орієнтоване проектування (Object-Oriented Design Method)

IDEF5

Систематизація об'єктів застосування (Ontology Description Capture Method)

IDEF6

Використання раціонального досвіду проектування (Design Rationale Capture Method)

IDEF8

Взаємодія людини і системи (Human-System Interaction Design)

IDEF9

Врахування умов і обмежень (Business Constraint Discovery)

IDEF14

Моделювання обчислювальних мереж (Network Design)

Якщо методика IDEF0 пов'язана з функціональними аспектами і дозволяє відповісти на питання "Що робить система", то в IDEF3 деталізуються та конкретизуються IDEF0-функції, IDEF3-модель відповідає на питання "Як система це робить". В IDEF3 входять два типи описань:

1. процесно-орієнтовані у виді послідовності операцій;

2. об'єкт-орієнтовані, що представляються в виді діаграм переходів стану об'єкту.

Системи інформаційного моделювання реалізують методики інфологічного проектування баз даних IDEF1, IDEF1X що мають графічний інтерфейс опису діаграм “сутність–зв’язок” (Entity-Relationship Diagram (ERD)). Всі програмні пакети підтримують один із варіантів ERD. При виборі CASE засобів для бізнес аналізу, інформаційного, функціонального моделювання та реінжинірингу необхідно проаналізувати їх можливість структурного аналізу, функцій BPR, ERD, підтримки автоматичної перевірки на повноту моделі, автоматичної генерації проектної документації.

Методика IDEF4 реалізує об'єктно-орієнтоване проектування великих систем. Вона надає користувачу графічну мову для відображення класів, діаграм наслідувань, таксономії методів.

Методика IDEF5 направлена на представлення онтологічної інформації застосування в зручному для користувача виді. Для цього використовуються символічні позначення (дескриптори) об'єктів, їх асоціацій, ситуацій та мова опису відношень класифікації "частина - ціле".

Розвиток BPR методик продовжується в США за програмою IICE (Information Integration for Concurrent Engineering). Розроблені методики IDEF6-IDEF14 (див. Табл.1).

На ринку програмних продуктів існує значна частина CASE - систем для концептуального проектування. Найчастіше в них підтримується саме методологія IDEF. В Україні та СНД широко відомі такі продукти BPWin, ERWin, OOWin фірми Logic Worcks, Design/IDEF фірми Meta Software, CASE - Аналітик фірми Ейтекс, Silverrun фірми CSA та ін.

Основною задачею першого етапу модернізації інформаційної системи ДПСУ повинно бути визначення функцій податкових інспекцій та адміністрацій і переліку процедур, що забезпечують реалізацію кожної функції. Такий підхід дозволить більш чітко описати функціональну систему підрозділів податкової служби і запропонувати проекти їх організаційної структури.

Необхідно розробити наступні документи:

· "Опис процедур районної державної податкової інспекції (ДПІ)";

· "Опис процедур обласної державної податкової адміністрації (ДПА)".

Наведені документи в комплексі мають визначати зміст проекту модернізації податкової служби України та її інформаційної системи зокрема.

Вибір моделі даних сховища є одним із основних етапів проектування системи, на якому основна увага приділяється вибору методології оперативного аналізу даних сховища. Практика показала що більше користувачів працює із узагальненими даними і меньше – з детальними. Це спостереження лягло в основу підходу до пошуку та вибору даних названого Оперативною Алітичною Обробкою (On-Line Analitical Processing, (OLAP)). Дванадцять визначальних принципів OLAP сформульовано Е. Коддом у 1993 році. Пізніше його визначення було реформоване в так званий тест FASMI, що вимагає від OLAP - застосувань по можливості найшвидшого аналізу розподіляємої багатовимірної інформації (див. http://www. olapreport. com/fasmi. htm).

В основі OLAP лежить поняття гіперкуба або багатовимірного куба даних, в комірках якого зберігаються аналізуємі дані, або вимірювання даних. Вимірювання являють собою сукупність значень інших даних, наприклад видів діяльності, типів власності, дати, видів платежів, тощо. В залежності від відповіді на питання, існує гіперкуб як окрема структура чи як віртуальна модель даних, розрізняють:

· багатовимірні OLAP (Multidimentional OLAP, (MOLAP));

· реляційні OLAP (Relational OLAP, (ROLAP));

· гібридні OLAP (Hybrid OLAP, HOLAP).

В першому випадку гіперкуб реалізується як окрема база даних спеціальної нереляційної структури, що забезпечує максимальний ефект за швидкістю доступу до даних, але вимагає додаткових ресурсів пам’яті. Для ROLAP гіперкуб це лише користувацький інтерфейс, що емулюється на звичайній реляційній СУБД. В цій структурі можна зберігати надзвичайно великі масиви даних, але недоліком її є недостатня ефективність OLAP операцій.

У випадку HOLAP - детальні дані остаються на місці ( в реляційній БД), а агрегати зберігаються в багатовимірній БД.

Зважуючи на специфіку функціонування регіональних підрозділів ДПСУ, де велике значення має оперативна звітність, для регіональних центрів обробки інформації можна рекомендувати багатовимірну модель СД за структурою HOLAP у вигляді вітрин даних (ВД, (Data Marts)). В якості бази для такої вітрини даних може використовуватись прототип звітного файлу для АІС "Галузь", що вміщує інформацію по нарахуванням, пені, штрафам тощо.

Для багатовимірного аналізу, як правило, рекомендують два типи моделей: модель типу "зірка" і багатовимірна модель. Модель "зірка" - це денормалізована реляційна модель, в якій дані зберігаються в таблицях двох типів: таблицях фактів та таблицях вимірювань. Таблиці фактів мають комбінований ключ і є найбільшими таблицями схеми (за об'ємом даних). В кожній таблиці вимірювання є один стовпець, що використовується в якості первинного ключа, і один або декілька дескрипторних текстових стовців (Рис.1.)

Таблиці вимірювань Таблиця фактів Таблиці вимірювань

Модель вітрини даних за схемою "зірка"

Рис.1. Модель вітрини даних за схемою "зірка".

Приклад багатовимірного куба  на основі звітної таблиці ДПІ, побудованого за  допомоогою програмного продукту SPSS.

Виначимо деякі основні поняття багатомірного представлення даних. На логічному рівні структура даних представляє собою складний гіперкуб, що характеризується наступними елементами [2]:

· Вимірювання (dimension) це підмножина однотипних даних, що утворюють одну із граней гіперкуба. В багатовимірній моделі даних вимірювання грають роль індексів, що використовуються для ідентифікації конкретних значень (показників) в ячейках гіперкуба;

· Показники (measure) - це поле, значення якого однозначно визначаються фіксованим набором вимірювань.

Приклад багатовимірного куба, побудованого за допомогою SPSS на основі звітної таблиці районної ДПІ показаний на рис.2.

Існує два варіанти організації даних; Полікубічна модель та Гіперкубічна модель. Полікубічна модель передбачає, що в багатовимірній структурі даних може бути визначено декілька гіперкубів з різною розмірністю і різними вимірюваннями в якості їх граней. У випадку Гіперкубічної моделі передбачається, що всі показники повинні визначатись одним і тим же набором вимірювань.

Таким чином, традиційна реляційна СУБД дозволяє проглядати дані в двох вимірюваннях, наприклад: сума пені та штрафів, нарахована конкретним платникам. Багатовимірна база даних дозволяє проглядати дані в багатьох вимірюваннях, наприклад: податки, сплачені платниками по регіонам, видам діяльності за різні проміжки часу. Для цього за допомогою багатовимірних масивів дані організуються в вимірювання та показники [3].

Вивчення багатовимірних моделей може бути формалізовано за допомогою наведеної нижче лінгвістичної структури. Модель визначається символами, що позначають реальні об'єкти. Введемо наступні позначення:

M: модель бази даних,

m: засоби моделювання (основні концепції, методи). Допустимі значення <реляційна модель, багатовимірна, сутність-зв'язок, ієрархічна, мережева, об'єктна …>,

R: моделюєма предметна область (реальні об'єкти). Допустимі значення : <платник, інспектор, податок, період, район…>,

Модель визначається як M = f (m, R).

Приклади:

M rel, R, =(relational, R) - це модель, що описує реальні об'єкти предметної області R за допомогою реляційних понять, представлень та методів;

M md, R = (multidimensional, R) -це модель що описує реальні об'єкти R за допомогою багатомірних понять, представлень та методів;

M rel, rel = (relational, relational) - це модель, що описує поняття реляційної моделі на мові реляційної моделі, тобто за допомогою реляційних понять, представлень та методів. Така модель є реляційною метамоделлю для реляційної моделі. Designer/2000 поставляється разом із вбудованою реляційною метамоделлю;

M rel, md = (relational, multidimensional) - це модель, що описує багатовимірні поняття та представлення з допомогою реляційних понять, представлень та методів. Вона складає основу для реляційної метамоделі багатовимірної моделі.

За допомогою M md, R вивчаються та моделюються реальні об'єкти, а за допомогою M rel, md поняття багатовимірної моделі.

Можна запропонувати наступний формалізований опис багатовимірної організації даних гіперкубічної моделі:

Гіперкуб - модель логічного представлення даних, що характеризується двома наборами параметрів: вимірюваннями та показниками;

Введемо символьне зображення гіперкуба, де g1, g2,...,g - показники гіперкуба;

- вимірювання гіперкуба;

2. Вимірювання гіперкуба - дискретна множина однотипних даних, що утворюють одну із граней гіперкуба.

де  - кількість значень по вімірюванню - по ,…, - по .

3. Кількість елементів вимірювання визначає потужність вимірювання.

4. Добуток потужностей вимірювань гіперкуба визначає розмірність гіперкуба.

5. Зріз гіперкуба це підмножина значень гіперкуба, що отримується в результаті фіксації одного або декількох значень одного із вимірювань.

6. Елементарна ячейка гіперкуба формується в результаті фіксації одного і тільки одного значення кожного вимірювання.

7. Показники гіперкуба - незмінний набір функцій, що характеризує кожну елементарну ячейку гіперкуба.

8. Зріз будемо називати виродженим, якщо значення цього показника у всіх елементарних ячейках зрізу дорівнює нулю.

9. Вагою гіперкуба будемо називати розмірність гіперкуба, помножену на кількість визначених для нього показників:

10. Розкладанням гіперкуба будемо називати його представлення в виді суми декількох гіперкубів меньших розмірностей без втрати ненульових значень показників.

Модель будемо вважати оптимізаційною, якщо гіперкуб допускає таке розкладання, що сумарна вага W отриманих гіперкубів меньше ваги вихідного куба. На основі такого ствердження можна проводити оптимізацію багатовимірних баз даних.

При виборі способу організації бази даних необхідно враховувати, що в будь-якому сховищі даних поряд з детальними даними повинні знаходитись сумарні показники (агрегати), такі як, наприклад, суми нарахувань податків по областям, містам, районам, нарахування по виду діяльності, підпорядкування, формі власності платників тощо. Агрегати зберігаються в явному виді з однією метою - прискорити виконання запитів. Але за швидкість обробки запитів до сумарних даних потрібно платити значним збільшенням об"ємів даних і часу на їх завантаження. В одному із опублікованих стандартних тестів повний підрахунок для 10 Мб початкових даних показав необхідність збільшення об"єму бази даних до 2.4 Гб, тобто дані повинні збільшитись в 240 раз.[4].

Для створення експертно-аналітичних систем в структурі інформаційних систем підрозділів податкової служби обласного рівня, регіональних центрів обробки інформації можна запропонувати структурну модель сховища даних представлену на рис. 3.

Структурна модель сховища даних ДПА

Надпись:

 

Базою моделей СППР у процесах адміністрування податків повинен бути набір економіко-математичних моделей, використовуючи які з допомогою OLAP технології може проводитись добування знань із баз даних (Data Mining). На етапі проектування експертно-аналітичних систем ДПСУ важливе значення має саме побудова і дослідження таких моделей, використання яких дасть змогу ефективно проводити податковий менеджмент, адміністрування податків, проводити відбір платників для комплексних перевірок тощо. Побудова та дослідження моделей може проводитись на основі наведених в даній статті формалізованих описів та визначень основних понять багатовимірного аналізу даних.

Використана література:

1. И. П.Норенков, Подходы к проектированию автоматизированных систем. // Информационные технологии.-1998. -№2, - С.2-9.

2. О. Заратуйченко. Современные подходы и методы построения аналитических информационных систем. Тезисы выступления на семинаре НТЦ АРБ " Практические вопросы информационно-аналиттической работы в коммерческом банке", -1998.

3. Гибб К. Быстрые нерегламентированные запросы, многомерный анализ и реляционные системы. //Русское издание ORACLE MAGAZINE. -1997.-№4.

4. Альперович А. ВВедение в OLAP и многомерные базы данных.// PC Week. -1999.- №28.

В статье приведена классификация методов построения экспертно-аналитических информационных систем, формализация понятий многомерного анализа данных, возможные подходы к построению хранилищ данных подразделений налоговой службы Украины.

Добавить комментарий


Защитный код
Обновить