Формирование многомерных данных в информационной финансово-экономической системе на предприятии госкорпорации «Роскосмос»

Одним из основных требований, предъявляемых к финансово-экономическим системам, является возможность оперативного получения актуальной аналитической информации, необходимой для принятия оперативных управленческих решений и генерации всеохватывающей детализированной отчетности. Особенно актуальной эта задача является для предприятий госкорпорации «Роскосмос», работающих в условиях гособоронзаказа и обязанных вести в своей хозяйственной деятельности раздельный учет затрат по различным проектам. Информационная поддержка бухгалтерского и управленческого учета построена на правилах хранения и обработки данных документов-первоисточников, регистрируемых в системах учета, их связях и процессах формирования новых информационных объектов учета. Данные на разных участках учета есть не что иное, как производные от первичных документов или множества первичной информации. В процессе передела и потребления данных на определенных участках учета ин- формационные связи между различными производными от одного основания могут теряться. Информационные объекты начинают «жить своей жизнью» и порождать новые производные. При информационных разрывах теряется возможность дифференцирования текущей производной до первоисточника данных (основания) и анализа связанных с ним данных в рамках технологических и экономических процессов. Математическое решение подобных задач, приводящее к логически выстроенной цепочке операций и возможности автоматизации учета, является предметом исследований многих ученых и практиков, работающих над созданием систем информационной поддержки финансово-экономических задач в управлении предприятиями.

Анализ исследований

Ведущее место в решении данного класса задач занимают OLAP-технологии [1] (OLAP – online analytical processing, оперативная аналитическая обработка). Системы, реализующие OLAP, должны отвечать так называемым принципам FASMI [2]: Fast (быстрый отклик системы), Analysis (полнофункциональный анализ), Shared (многопользовательский доступ к данным), Multidimensional (многомерное концептуальное представление данных), Information (получение информации в нужном объеме там, где она необходима). Как видно, исходя из данных принципов, требования к системе построения отчетности, которую действительно можно назвать OLAP-системой, весьма жесткие. За секунды отчеты должны строиться по миллионам записей, столь же быстро раскрываться по интересующим пользователя аналитикам, фильтроваться и перегруппировываться [3].

Наиболее распространенным подходом в реализации OLAP-систем является разделение данных между двумя базами: транзакционной (OLTP – online transaction processing) и аналитической (OLAP). При этом OLTP-база оптимизируется под быстрое внесение данных, а OLAP – под быстрое построение сложной отчетности. Фактически OLAP-база обычно строится по специальной архитектуре и содержит предварительно просчитанные агрегатные данные, что и обеспечивает высокую скорость выполнения запросов. Платой за это становится необходимость синхронизировать OLTP и OLAP. Так как подобный процесс, как правило, периодичен, то между появлением данных в оперативной базе и аналитическими данными имеется запаздывание. Данный подход реализован практически во всех современных BI-системах (business intelligence – сбор и анализ бизнес-информации): Microsoft Analysis Services, Oracle OLAP, IBM Informix, Arbor Essbase и др.

Другим подходом в решении задач оперативной аналитической обработки данных является встраивание OLAP-инструментария непосредственно в OLTP-хранилище. Это достигается как использованием специальных элементов данных (например, регистры оперативного учета в платформе «1С: Предприятие» [4]), так и оптимальной (с точки зрения оптимизации выполнения OLAP-запросов) структуризацией схемы данных. Данный подход лег в основу разработанной на предприятии системы управления финансово-экономическими задачами (АСУ ФЭЗ) [5] как эффективная альтернатива сложным и дорогостоящим BI-системам.

Описание подхода

Структуры и алгоритмы, лежащие в основе АСУ ФЭЗ, позволяют эффективно сочетать гибкость и быстродействие транзакционной базы данных (БД), с одной стороны, и возможности построения сложной отчетности за приемлемое время – с другой. Далее в статье приведен обзор технической реализации хранилища данных на примере подсистемы «Покупки», отвечающей за учет товаров, работ и услуг, которые предприятие приобретает для создания собственных объектов продажи.

Ядро модуля «Покупки» составляет 5 таблиц, построенных в соответствии с правилами нормальных форм [6; 7], и представлено на рис. 1:

• –    POK_PRIH – документы прихода товарно-материальных ценностей, работ, услуг;

• –    POK_OSN – документы-основания для учета НДС (входящие счета-фактуры);

• –    PO_SOGL – документы-основания для платежа (акцепт-согласие ответственных сотрудников на оплату товарно-материальных ценностей, работ, услуг);

• –    POK_OPL – платежные документы;

• –    POK_SW – таблица связей, содержит ссылки в виде внешних ключей на первичные ключи записей из перечисленных выше таблиц (ID_PR – на таблицу POK_PRIH, ID_OSN – на таблицу POK_OSN, ID_TS – на таблицу POK_SOGL, ID_OPL – на таблицу POK_OPL).

POK_PRIH
PK	ID PRIM	NUMERIC(10;2)
	WID_DOC	CHAR(IO)
	NUM_DOC	CHAR(30)
	DATE_DOC	DATETIME
	REG NUM DOC	INTEGER
	REG DATE DOC	DATETIME
	COD PRED	INTEGER
	COD VAL	INTEGER
	SUM_DOC	NUMERIC(10;2)
	DOC COD PRED	INTEGER
	DOC COD VAL	INTEGER
	DOC SUM DOC	NUMERIC(10;2)
	DOC PROC NDS	NUMERIC(10;2)
	DOC SUM NDS	NUMERIC(10;2)
	RUB SUM DOC	NUMERIC(10;2)
	RU B SUM NDS	NUMERIC(10;2)
	COR NUM DOC	CHAR(30)
	COR DATE DOC	DATETIME
	PATCH NUM DOC	CHAR(30)
	PATCH DATE DOC	DATETIME
	BUH_PERIOD	INTEGER
	IN_BOOK	INTEGER
	DATE_OTGR	DATETIME
	USR	CHAR(IO)
	DTR	DATETIME

POK_SOGL
PK	ID SOGL	NUMERIC(10;2)
	WID_DOC	CHAR(IO)
	NUM_DOC	CHAR(30)
	DATE_DOC	DATETIME
	REG NUM DOC	INTEGER
	REG DATE DOC	DATETIME
	COD_PRED	INTEGER
	COD VAL	INTEGER
	SUM_DOC	NUMERIC(10;2)
	DOC COD PRED	INTEGER
	DOC COD VAL	INTEGER
	DOC SUM DOC	NUMERIC(10;2)
	DOC PROC NDS	NUMERIC(10;2)
	DOC SUM NDS	NUMERIC(10;2)
	RUB SUM DOC	NUMERIC(10;2)
	RU B SUM NDS	NUMERIC(10;2)
	CO R NUM DOC	CHAR(30)
	COR DATE DOC	DATETIME
	PATCH NUM DOC	CHAR(30)
	PATCH DATE DOC	DATETIME
	BUH_PERIOD	INTEGER
	IN_BOOK	INTEGER
	DATE OTGR	DATETIME
	USR	CHAR(IO)
	DTR	DATETIME

POK_SW
PK	ID SW	INTEGER
FK1	ID_PR	NUMERIC(10;2)
FK2	ID_OSN	NUMERIC(10;2)
FK4	ID_TS	NUMERIC(10;2)
FK3	ID_OPL	NUMERIC(10;2)
	SUM_DOC	NUMERIC(10;2)
	COD VAL	INTEGER
	REFI	NUMERIC(10;2)
	REFO	NUMERIC(10;2)
	REF_STORNO	NUMERIC(10;2)
	COD_PRED	INTEGER
	ID_DOG	INTEGER
	ID_ZATR	INTEGER
	NUM1	INTEGER
	NUM2	INTEGER
	NUM3	INTEGER
	NUM4	INTEGER
	ID1_PR	NUMERIC(10;2)
	ID1_OSN	NUMERIC(10;2)
	ID1_TS	NUMERIC(10;2)
	ID1_OPL	NUMERIC(10;2)
	PR_BUH	NUMERIC(10;2)
	USR	CHAR(30)
	DTR	DATETIME

POK_OSN
PK	ID OSN	NUMERIC(10;2)
	WID_DOC	CHAR(IO)
	NUM_DOC	CHAR(30)
	DATE_DOC	DATETIME
	REG NUM DOC	INTEGER
	REG DATE DOC	DATETIME
	COD PRED	INTEGER
	COD VAL	INTEGER
	SUM_DOC	NUMERIC(10;2)
	DOC COD PRED	INTEGER
	DOC COD VAL	INTEGER
	DOC SUM DOC	NUMERIC(10;2)
	DOC PROC NDS	NUMERIC(10;2)
	DOC SUM NDS	NUMERIC(10;2)
	RUB SUM DOC	NUMERIC(10;2)
	RUB SUM NDS	NUMERIC(10;2)
	COR NUM DOC	CHAR(30)
	COR DATE DOC	DATETIME
	PATCH NUM DOC	CHAR(30)
	PATCH DATE DOC	DATETIME
	BUH_PERIOD	INTEGER
	IN_BOOK	INTEGER
	DATE_OTGR	DATETIME
	USR	CHAR(IO)
	DTR	DATETIME

POK_OPL
PK	ID PPL	NUMERIC(10;2)
	WID_DOC	CHAR(IO)
	NUM_DOC	CHAR(30)
	DATE_DOC	DATETIME
	REG NUM DOC	INTEGER
	REG DATE DOC	DATETIME
	COD_PRED	INTEGER
	COD VAL	INTEGER
	SUM_DOC	NUMERIC(10;2)
	DOC COD PRED	INTEGER
	DOC COD VAL	INTEGER
	DOC SUM DOC	NUMERIC(10;2)
	DOC PROC NDS	NUMERIC(10;2)
	DOC SUM NDS	NUMERIC(10;2)
	RUB SUM DOC	NUMERIC(10;2)
	RU B SUM NDS	NUMERIC(10;2)
	CO R NUM DOC	CHAR(30)
	COR DATE DOC	DATETIME
	PATCH NUM DOC	CHAR(30)
	PATCH DATE DOC	DATETIME
	BUH_PERIOD	INTEGER
	IN_BOOK	INTEGER
	DATE OTGR	DATETIME
	USR	CHAR(IO)
	DTR	DATETIME

Рис. 1. Схема данных модуля «Покупки»

Fig. 1. Module “Purchase” data schema

Предлагаемый подход к структурированию данных позволяет выполнять широкий спектр задач аналитической обработки без предварительной подготовки данных или использования промежуточных представлений. Для наглядного описания проведем их формализацию [8], затем рассмотрим несколько реальных примеров таких задач, решаемых в рамках подсистемы «Покупки». Итак, пусть задана схема базы данных ℜ = { R 1 , R 2 , ..., R k }, полученная в результате нормализации отношений [6; 7]. Отношения R i определены на множестве атрибутов U = { A 1 , A 2 , ..., A n }. Пусть [ R i ] – схема отношения, множество атрибутов, на которых определено отношение R_i . Предположим, что схема ℜ является редуцированной [7], т. е. не существует двух отношений таких, что [ R i ] ⊆ [ R j ], при i ≠ j . Кортеж t [ X ] – совокупность значений атрибутов A j ∈ X ⊆ [ R i ], заданных в кортеже t ∈ R i . Неопределенное значение NULL атрибута A j в кортеже t : t [ A j ] = NULL не равно любому другому значению, в том числе другому неопределенному значению.

Многомерное представление будем задавать в виде совокупности размерностей { D 1 , D 2 , …, D d }, где D l – множество расширенных имен атрибутов: R i A j , A ϕ ∈ [ R i ]; M – множество мер, также заданных в виде расширенных имен атрибутов. Значения D l являются значениями координат гиперкуба, значения M будут располагаться в рабочей области гиперкуба. Для каждой размерности задается ограничение в виде логической формулы F l .

Пример 1. Необходимо найти данные оплат (любых перечислений денежных средств) предприятию с кодом 12345 по проекту 111 и договорам поставки 222, 223, где были уплачены денежные средства с 01.01.2021 по 28.02.2021 по статьям бюджетного планирования (СБП) 333, 334 и получены товар/работы/услуги в период с 01.01.2021 по 31.01.2021.

С целью упрощения постановки и реализации, в этом и последующих примерах не используемые в выборке атрибуты опускаются. Таким образом, в рамках описанной схемы БД имеем следующее подмножество атрибутов: A₁ – идентификатор связи, A₂ – идентификатор записи о поступлении товара/работ/услуг, A 3 – идентификатор записи платежа, A 4 – код предприятия, A 5 – идентификатор проекта, A 6 – идентификатор договора поставки, A 7 – СБП, A 8 – дата приходной накладной, A 9 – дата платежа, A 10 – сумма платежа. Здесь существуют следующие функциональные зависимости: DEP = { A 1 → A 2 A 3 A 4 A 5 A 6 A 7 , A 2 → A 8 , A 3 → A 9 A 10 }. На основании данного подмножества получаем упрощенную схему отношений: Связи документов = R₁ ( A₁ , A₂ , A₃ , A 4 , A 5 , A 6 , A 7 ), Поступления товаров/работ/услуг = R 2 ( A 2 , A 8 ), Платежные документы = R 3 ( A 3 , A 9 , A 10 ), где жирным выделены ключевые атрибуты отношений. Одно из возможных представлений гиперкуба приведено в табл. 1.

Таблица 1

Данные оплат

Код предприятия	12345
Проект	111
Договор поставки	222		223
СБП	333	334	333	334
Дата	Сумма	Сумма	Сумма	Сумма
21.01.2021	75000	250000	357500	65500
26.01.2021	31000	310000	785000	96000
28.01.2021	70000	870080	6500	55000

Атрибуты измерений представлены жирным шрифтом, атрибуты фактов – курсивом, значения атрибутов – обычным шрифтом. Схема гиперкуба в табл. 1 может быть представлена в следующем виде:

{R3.A9} × {R1.A4{R1.A5{R1.A6{R1.A7(R3.A10)}}}}, где D1 = {R3.A9} и D2 = {R1.A4, R1.A5, R1.A6, R1.A7} – измерения, M = {R3.A10} – факты. Логическое ограничение: F = (R1.A2 ≠ NULL ∧ R1.A3 ≠ NULL ∧ R1.A4 = 12345 ∧ R1.A5 = 111 ∧ (R1.A6 = 222 ∨ R1.A6 = 223) ∧ (R1.A7 = 333 ∨ R1.A7 = 334) ∧ R3.A11 >= 01.01.2021 ∧ R3.A11 <= 28.02.2021 ∧ R2.A8 >= 01.01.2020 ∧ R8.A8 <= 31.01.2020).

Соответствующий SQL запрос приведен на рис. 2.

SELECT pok.cod_pred AS pok_cod_pred, -- предприятие pok.id_zatr AS pok_id_zatr, -- проект pok.id_dog AS pok_id_dog, -- договор pok.num4 AS pok_num4, -- статья бюджетного плана opl.date_doc AS opl_date_doc, -- дата платежного документа opl.sum_doc AS opl_sum_doc -- сумма платежного документа FROM pok_sw pok

LEFT JOIN pok_opl opl ON pok.id_opl = opl.id_opl

LEFT JOIN pok_prih pr ON pok.id_pr = pr.id_prih

WHERE pok.id_opl IS NOT NULL -- были уплачены деньги

AND pok.id_pr IS NOT NULL -- были получены товар/работы/услуги

AND pok.cod_pred = 12345 -- данные по предприятию с кодом 12345

AND pok.id_zatr = 111 -- по проекту с кодом 111

AND pok.id_dog = 222 -- по договору с кодом 222

AND pok.num4 = 333 -- платеж был по СБП с кодом 333

Рис. 2. SQL запрос данных оплат предприятию с указанной аналитикой

• Fig. 2.    SQL query of payments data to the enterprise with the specified analytics

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

Пример 2. Необходимо найти дебиторскую задолженность (сумму долга) предприятию с кодом 12345 за поставленные товары/работы/услуги по проектам 111 и 112.

Задано минимальное подмножество атрибутов: A 1 – идентификатор связи, A 2 – идентификатор записи о поступлении товара/работ/услуг, A 3 – идентификатор записи платежа, A 4 – код предприятия, A 5 – идентификатор проекта, A 6 – идентификатор договора поставки, A 7 – номер документа прихода, A 8 – сумма документа прихода, A 9 – отчетный период. На данном множестве атрибутов существуют следующие функциональные зависимости: DEP = { A 1 → A 2 A 3 A 4 A 5 A 6 , A 2 → A 7 A 8 A 9 }. Получаем схему отношений: Связи документов = R 1 ( A 1 , A 2 , A 3 , A 4 , A 5 , A 6 ), Поступления товаров/работ/услуг = R 2 ( A 2 , A 7 , A 8 , A 9 ). Одно из возможных представлений гиперкуба приведено в табл. 2.

Схема гиперкуба в табл. 2 может быть представлена в следующем виде:

{R2.A7} × {R1.A4{R1.A5{R1.A6{R2.A9(R2.A8)}}}}, где D1 = {R2.A7} и D2 = {R1.A4, R1.A5, R1.A6, R2.A9} – измерения, M = {R2.A8} – факты. Логическое ограничение: F = (R1.A2 ≠ NULL ∧ R1.A3 = NULL ∧ R1.A4 = 12345).

Таблица 2

Код предприятия	12345
Проект	111				112
Договор поставки	222		223		224		225
Отчетный период	333		334		333		334
№ док.	I/2020	II/2020	III/2020	IV/2020	I/2020	II/2020	III/2020	IV/2020
11	75000	21500	250000	784200	357500	650800	65500	48000
12	31000	79200	310000	58100	785000	130000	96000	51700
13	70000	623300	870080	3700	6500	210000	55000	3580

Дебиторская задолженность

Пример соответствующего SQL запроса приведен на рис. 3.

SELECT pok.cod_pred AS pok_cod_pred, -- предприятие pok.id_zatr AS pok_id_zatr, -- проект pok.id_dog AS pok_id_dog, -- договор prih.num_doc AS prih_num_doc, -- номер документа прихода prih.sum_doc AS prih_sum_doc, -- сумма документа прихода prih.cod_val AS prih_cod_val, -- код валюты документа прихода prih.buh_period AS prih_buh_period -- отчетный период

FROM pok_sw pok

LEFT JOIN pok_prih prih ON pok.id_pr = prih.id_prih

WHERE pok.id_pr IS NOT NULL -- был приход товара (наличие документа прихода)

AND pok.id_opl IS NULL -- не было оплаты

AND pok.cod_pred = 12345 -- данные по предприятию с кодом 12345

Рис. 3. SQL запрос данных о дебиторской задолженности указанному предприятию

• Fig. 3.    SQL query of data on accounts receivable for the specified company

Результатом будут все строки по исследуемому предприятию, где зарегистрированы первичные приходные документы, по всем проектам, договорам поставки с возможными оплатами в любой валюте. Здесь можно анализировать, за какую поставку чем оплачивалось, какие были согласованы акцепты, авансы или платежи, по каким договорам, для кого, какие счета-фактуры для налогового учета и когда они должны попасть в книги покупок и продаж и т. д. Пример подсчета суммы платежей предприятию представлен на рис. 4.

SELECT SUM(DECODE(NVL(pok.id_opl, 0), 0, 0, pok.sum_doc)) AS sum_opl, pok.cod_val FROM pok_sw pok

WHERE pok.id_pr IS NOT NULL -- был приход товара (наличие приходного ордера)

AND pok.cod_pred = 12345 -- данные по предприятию с кодом 12345 GROUP BY pok.cod_val

Рис. 4. SQL запрос суммы долга указанному предприятию

• Fig. 4.    SQL query for the amount owed to the specified company

Пример 3. Получить информацию о том, какие товары/работы/услуги были оплачены данным документом и на основании какого документа согласования (акцепта) это было сделано.

Задано минимальное подмножество атрибутов: A 1 – идентификатор связи, A 2 – идентификатор записи о поступлении товара/работ/услуг, A 3 – идентификатор записи документа согласования (акцепта), A 4 – идентификатор записи платежа, A 5 – код предприятия, A 6 – идентификатор проекта, A 7 – идентификатор договора поставки, A 8 – вид документа прихода, A 9 – номер документа прихода, A 10 – сумма прихода, A 11 – номер акцепта, A 12 – номер документа оплаты, A 13 – дата документа оплаты. Имеются следующие зависимости: DEP = { A 1 → A 2 A 3 A 4 A 5 A 6 A 7 , A 2 → A 8 A 9 ( A 10 ), A 3 → A 11 , A 4 → A 12 A 13 } (три функциональных и одна многозначная).

В данном примере предлагается отказаться от необходимости выполнения функциональной зависимости [9–13]

D1D2…Dd → M, которая означает, что любому составному вектору значений размерностей D1D2…Dd соответствует не более одного вектора значений мер M.

Отказ от данной зависимости позволит использовать содержательные (не ключевые) атрибуты в размерностях и иметь в одной ячейке гиперкуба несколько значений (список) атрибута R i A j ∈ M . Списки значений используются в анализе данных, когда значения параметров не надо соотносить с объектами.

Получаем следующую схему отношений: Связи документов = R 1 ( A 1 , A 2 , A 3 , A 4 , A 5 , A 6 , A 7 ), Поступления товаров/работ/услуг = R 2 ( A 2 , A 8 , A 9 , A 10 ), Документы согласования платежей = R 3 ( A 3 , A 11 ), Платежные документы = R 4 ( A 4 , A 12 , A 13 ). Одно из возможных представлений гиперкуба приведено в табл. 3.

Таблица 3

Данные платежного документа

Код предприятия	12345
Проект	111
Договор поставки	222				223
Вид документа прихода	Приходная накладная		Приходный ордер		Акт выполненных работ		Приходная накладная
№ акцепта	Сумма	№ док. прихода	Сумма	№ док. прихода	Сумма	№ док. прихода	Сумма	№ док. прихода
11	75000	21	357500	24	250000	27	65500	30
12	31000	22	785000	25	310000	28	96000	31
13	70000	23	6500	26	870080	29	55000	32

Схема гиперкуба в табл. 3 может быть представлена в следующем виде:

{R3.A11} × {R1.A5{R1.A6{R1.A7{R2.A8(R2.A9)}(R2.A10)}}}, где D1 = {R3.A11} и D2 = {R1.A5, R1.A6, R1.A7, R2.A8} – измерения, M = {R3.A9, R3.A10} – факты. Логическое ограничение: F = (R4.A12 = 987 ∧ R4.A13 = 21.01.2021).

Пример соответствующего SQL запроса приведен на рис. 5.

Аналогичным образом реализован модуль АСУ ФЭЗ «Продажи» и другие вспомогательные модули. В совокупности эти модули составляют ядро системы.

Схема базы данных изначально спроектирована в соответствии с правилами нормальных форм [6; 7] и обладает свойством соединения без потерь информации (СБПИ) в соответствии с теоремой 5.8 [6]:

Пусть σ – декомпозиция отношения R, образованная схемами отношений в третьей нормальной форме, и пусть также X – ключ R. Тогда τ = σ ∪ {X} – декомпозиция R, такая, что все составляющие ее схемы отношений находятся в третьей нормальной форме. Эта декомпозиция сохраняет зависимости и сохраняет свойство соединения без потерь.

SELECT pok.cod_pred AS pok_cod_pred, -- предприятие pok.id_zatr AS pok_id_zatr, -- проект pok.id_dog AS pok_id_dog, -- договор prih.wid_doc AS prih_wid_doc, -- вид документа прихода prih.num_doc AS prih_num_doc, -- номер документа прихода prih.sum_doc AS prih_num_doc, -- сумма прихода sogl.num_doc AS osn_num_doc -- номер акцепта

FROM pok_sw pok

LEFT JOIN pok_prih prih ON pok.id_pr = prih.id_prih

LEFT JOIN pok_sogl sogl ON pok.id_osn = sogl.id_osn

LEFT JOIN pok_opl opl ON pok.id_opl = opl.id_opl

Рис. 5. SQL запрос данных платежа

• Fig. 5.    SQL query for payment data

Полученные в результате кубы данных соответствуют формальным правилам, рассмотренным в работе [14], в соответствии с моделью данных «композиционная таблица», которая, в свою очередь, является обобщением модели «семантическая трансформация» [12], на случай списка значений в одной ячейке. Данный алгоритм формирует иерархии в измерениях гиперкуба, используя функциональные, многозначные зависимости исходной базы данных и иерархии атрибутов, заданные пользователем.

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

Заключение

Предложенный вариант формирования и хранения данных первичных документов о хозяйственной деятельности предприятия обеспечивает детализированный раздельный учет финансово-хозяйственных операций покупок и продаж, и позволяет эффективно решать проблемы построения бухгалтерского, налогового и управленческого учетов. Применение вышеописанных схем, логики хранения и обработки данных для работы с различными их производными дает возможность дифференцировать элементы цепочки событий (состояний) в учете до первоисточников, увязанных в таблице связей в соответствии с логикой хозяйственных операций, что позволяет анализировать данные по любому интересующему набору аналитики. Таким образом, на любом этапе и участке учета всегда имеются целостные информационные связи. При этом обеспечивается возможность построения сложных OLAP структур данных в сочетании с быстродействием транзакционной СУБД. Эффективность работы АСУ ФЭЗ и лежащих в ее основе алгоритмов подтверждается опытом многолетней промышленной эксплуатации на одном из ведущих предприятий госкорпорации «Роскосмос» АО «ИСС» без привлечения внешних коммерческих решений.