Введение
Автоматизированные системы управления радиочастотным спектром (АИС РЧС) являются базовым инструментом национальных регуляторов в области электросвязи. Рекомендация ITU-R SM.1370-2 задаёт основные требования к таким системам: состав данных, поддерживаемые функции и возможность выборки по диапазону частот, географической области, идентификатору записи и статусу лицензии [1; 2]. Документы МСЭ также рекомендуют использовать компьютеризированные методы управления спектром и соответствующие модели данных [3; 4]. Иными словами, современная АИС РЧС должна не только хранить сведения о лицензиатах, объектах размещения радиоэлектронных средств и параметрах частотных присвоений, но и обеспечивать удобную работу с этими данными [4].
Практика эксплуатации государственного реестра РЧС Киргизской Республики показывает, что значительная часть новых частотных присвоений оформляется для объектов, технические параметры которых либо совпадают с уже зарегистрированными, либо отличаются несущественно. В литературе по цифровизации государственных услуг повторный ввод данных и недостаточная стандартизация процедур рассматриваются как факторы, способные увеличивать административную нагрузку и снижать удобство работы с цифровыми сервисами [5–7]. Для систем государственного управления, ориентированных на интеграцию электронных услуг, отдельное значение имеют согласованная работа информационных контуров и межведомственное взаимодействие [8]. Принципы повторного использования уже имеющихся сведений и однократного предоставления данных рассматриваются как важные направления ограничения избыточного ввода и дублирования сведений [9; 10]. В настоящей статье указанные источники используются как общий контекст постановки задачи, а не как прямое доказательство эффективности каскадного копирования в радиочастотном реестре.
Несмотря на наличие международных руководств, в доступных рецензируемых публикациях по автоматизированному контролю назначения радиочастот и управлению ресурсами радиосистем ограниченно представлены прикладные сценарии ведения национального радиочастотного реестра, в которых поиск прототипа, создание записи на основе копии и анализ производительности рассматриваются совместно [11; 12]. В настоящей статье количественно оцениваются производительность поиска и эффект индексирования, а каскадное копирование рассматривается на уровне структуры создаваемых записей и числа потенциально заполняемых полей. Механизмы экспорта и печати описываются как элементы рабочего контура, но их производительность отдельно не измеряется. В этой связи статья вносит следующий вклад: 1) экспериментально измеряет производительность многокритериального поиска; 2) с помощью EXPLAIN ANALYZE диагностирует причину деградации режима byOne; 3) показывает эффект индексирования – ускорение в 6,2 раза при 95%-ном доверительном интервале 5,69–7,16 раза; 4) формулирует условия, при которых аналогичный эффект может ожидаться в системах сходной архитектуры, без утверждения его универсальной воспроизводимости.
Цель исследования – формализовать механизм поиска прототипа и каскадного копирования при автоматизированном ведении радиочастотного реестра, экспериментально оценить производительность поиска и эффект индексирования, а также оценить каскадное копирование на уровне числа потенциально заполняемых оператором полей. Количественная оценка времени работы операторов, частоты ошибок ввода, а также производительности экспорта и подготовки печатных форм в задачи настоящего исследования не входила. Ниже приведены материалы исследования и использованные методы.
Материалы и методы исследования
Материал исследования включает три компонента: а) агрегированные данные действующего радиочастотного реестра объёмом 667 193 записи (MySQL 8.0.45; без учёта записей, помеченных через поле addflag); б) архивные данные операционного журнала предшествующей системы за период с июня 2000 г. по октябрь 2014 г.; в) программную реализацию механизмов АИС управления РЧС КР. Свидетельство о регистрации программы [13] используется только для идентификации программного решения как объекта исследования и не рассматривается как доказательство научной эффективности предложенных механизмов.
С точки зрения предметной области трёхуровневая организация сведений о лицензиате, объекте размещения радиоэлектронных средств и частотном присвоении согласуется с общей логикой данных автоматизированных систем управления радиочастотным спектром [1–3]. В исследуемой реализации реестр построен на реляционной базе данных и включает три связанные таблицы. Таблица Owner описывает лицензиата и содержит около 20 атрибутов; поле area включает 9 целочисленных кодов (7 областей КР, а также Бишкек и Ош как города республиканского значения), а поле state хранит коды статуса лицензии. Таблица Site описывает объект размещения РЭС и содержит около 20 технических атрибутов; в ней 271 453 строки. Таблица Freq фиксирует частотное присвоение, содержит около 10 атрибутов, а номинал частоты хранится в кГц. Полное пространство поиска задаётся как
F = Owner ⨝ Site ⨝ Freq, |F| = 667 193,
где ⨝ обозначает соединение таблиц, то есть формирование набора строк с совпадающими значениями в связанных полях. Указанные значения являются агрегированными внутренними данными действующего реестра.
Метод 1. Экспериментальные замеры (n=5, тёплый кеш). SQL-запрос выполнялся пять раз подряд в одной сессии, после чего фиксировалось чистое время его выполнения (execution time). Затем вычислялись среднее значение t̄, стандартное отклонение s и 95%-ный доверительный интервал: ±2,776·s/√5. Замеры проводились при тёплом кеше (warm cache), то есть в ситуации, когда рабочие данные уже находятся в оперативном буфере СУБД после предшествующих обращений. Такой режим соответствует типичной непрерывной работе оператора. Для полного реестра (сценарий 0) приведён одиночный ориентировочный замер (†), поэтому доверительный интервал для него не рассчитывался.
Метод 2. Анализ плана запроса (EXPLAIN ANALYZE). Этот метод использовался для получения фактического плана выполнения запроса с реальными значениями rows – числа строк, обработанных на каждом шаге, и loops – числа повторных запусков соответствующего шага – до и после оптимизации.
Метод 3. Оценка доверительного интервала для коэффициента ускорения методом бутстрэпа. Бутстрэп – непараметрический метод статистического оценивания, при котором из исходных данных многократно формируются псевдовыборки путём случайного выбора с возвращением. Распределение интересующей статистики по этим итерациям используется для вычисления доверительного интервала. Серия «до» была получена при nominal=f_test, серия «после» – при nominal=f_oper, то есть при операционном номинале с ненулевым числом присвоений в регионе. Конкретные значения номиналов не раскрываются, поскольку для цели данного эксперимента существенны не предметные свойства частоты, а фактическая вычислительная нагрузка запроса. Эти два номинала не рассматриваются как полностью эквивалентные по предметному содержанию. Их сопоставление используется только для оценки изменения плана выполнения после создания индекса, поскольку EXPLAIN ANALYZE в обоих случаях показывает одинаковые ключевые параметры: соединение Owner ⨝ Site даёт 13 105 строк, а зависимый подзапрос выполняется 25 422 раза. Для оценки коэффициента ускорения было выполнено B=100 000 псевдовыборок с возвращением по двум наборам замеров: до оптимизации {4172; 3137; 3134; 3113; 3038} мс и после оптимизации {557; 526; 510; 556; 490} мс. Для каждой итерации рассчитывалось отношение средних значений t̄до / t̄после; 95%-ный ДИ определялся по 2,5-му и 97,5-му перцентилям и составил 5,69–7,16 раза, медиана – 6,22 раза.
Метод 4. Подсчёт атрибутов схемы базы данных. Для приближённой структурной оценки подсчитывалось число атрибутов (DESCRIBE Owner/Site/Freq), которые оператор потенциально заполняет при ручном создании записи и при использовании операции Copy. Этот метод оценивает только сокращение числа полей ввода и не является хронометражем работы оператора или измерением частоты ошибок ввода. Ниже последовательно описаны механизмы АИС управления РЧС КР, ставшие объектом экспериментальной оценки.
Механизм многокритериального поиска
Механизм поиска построен на принципе последовательного сужения выборки: каждый новый критерий применяется не ко всему реестру заново, а к уже отфильтрованному множеству записей. Формально это можно описать так: пусть P = {p₁, ..., pₙ} – полное множество доступных критериев, а A ⊆ P – подмножество критериев, активированных оператором. Тогда условие выборки W(A)=∧{pᵢ|pᵢ∈A} представляет собой логическое И всех активных условий, а результирующее множество Fʹ(A) не возрастает при расширении A. Практически это означает, что каждый новый критерий либо сокращает число кандидатов, либо оставляет его прежним, но не расширяет. Используемые критерии охватывают административные, пространственные, технические и регистрационные параметры трёх уровней (табл. 1) [1; 4].
Таблица 1
Критерии поиска в реестре РЧС КР
|
Ур. |
Критерий |
Поле БД |
Тип сравнения |
|
1 |
Идентификатор владельца |
owner.ID |
Точное = |
|
1 |
Наименование организации |
owner.Name |
Подстрочный LIKE |
|
1 |
Регион КР (9 кодов) |
owner.area (int) |
По перечислению |
|
1 |
Статус лицензии |
owner.state (int) |
По перечислению |
|
1 |
Номер счёта / лицензии |
owner.schet / LICNUMnum |
Точное = |
|
2 |
Наименование объекта |
site.SiteName |
Подстрочный LIKE |
|
2 |
Широта / долгота (°, ʹ, ʺ) |
site.latitude/longtitude 0/1/2 |
Точное = по компонентам |
|
3 |
Номинал частоты (МГц → кГц) |
freq.nominal (double) |
Точное =, конверсия единиц |
|
3 |
Полоса частот |
freq.band |
Точное = |
Примечание: составлено авторами. Поле area: 9 кодов = 7 областей КР + Бишкек + Ош; поле state – целочисленные коды; номинал – в кГц.
Режим быстрого обзора byOne («по одной записи на объект») предназначен для компактного просмотра реестра: вместо вывода всех частотных присвоений система показывает только первое найденное присвоение для каждого объекта. Технически режим реализован через подзапрос SELECT f2.ID FROM Freq f2 WHERE f2.IDsite=s.ID LIMIT 1. В нормальной работе byOne используется без привязки к конкретной частоте; нагрузочные замеры с фильтром по номиналу проводились только для анализа плана выполнения. При активном фильтре по номиналу запрос может возвращать 0 строк, поскольку первое найденное присвоение не всегда совпадает с заданным значением. Однако число запусков подзапроса определяется количеством объектов в регионе, а не числом строк в итоговой выборке, поэтому данный режим использовался для анализа вычислительной нагрузки, а не пользовательской скорости просмотра.
Механизм каскадного копирования типовой записи
Механизм поиска прототипа служит отправной точкой для операции каскадного копирования. Операция работает с тремя уровнями данных: лицензиат, объект размещения радиоэлектронных средств и частотное присвоение, что соответствует общей логике хранения и выборки сведений в автоматизированных системах управления радиочастотным спектром [1]. Формально операция Copy(ow_id) порождает дерево owʹ→{sʹᵢ}→{f ʹᵢⱼ}: новый Owner наследует технические поля прототипа, каждый Site воспроизводится с новым IDowner, а каждая Freq – с новыми IDsite и IDowner. После создания каждой записи Freq вызывается integrityService.logInsertById(), который вычисляет HMAC-SHA-256 для канонического представления данных записи и сохраняет результат в журнале целостности. В данной статье журналирование рассматривается как механизм фиксации создаваемых записей и контроля последующей целостности, но не как доказательство полной атомарности операции Copy при сбоях. Технически операция реализована как каскад JDBC-вставок; перевод всей процедуры Owner→Site→Freq в явную ACID-транзакцию рассматривается как задача следующей версии. Следовательно, безопасность Copy при частичных сбоях не заявляется как достигнутый результат настоящего исследования.
Механизмы экспорта и подготовки печатных форм
Отобранные и скопированные записи могут передаваться во внешние форматы с помощью механизмов экспорта и подготовки печатных форм. Экспорт реализован как выгрузка фильтрованной выборки Fʹ в формат XLSX без повторного ввода параметров запроса. Подсистема печати формирует PDF-документ после проверки целостности выбранных записей; при выявлении несоответствия операция блокируется. Для сформированного документа дополнительно вычисляется контрольная метка на основе SHA-256. В настоящей статье эти функции описываются только как элементы рабочего контура системы. Их влияние на производительность работы оператора количественно не измерялось, поэтому далее основное внимание уделено поиску, плану выполнения запроса и эффекту индексирования.
Результаты исследования и их обсуждение
Производительность механизма поиска представлена в таблице 2. Последовательное добавление предикатов монотонно сокращает выборку. Нулевое число записей в сценариях 4–5 не является ошибкой: оно показывает, что для данной комбинации условий в реестре просто нет совпадений. В этом смысле нулевой результат тоже является содержательно значимым, поскольку демонстрирует предельную избирательность механизма поиска.
Диагностика режима byOne и эксперимент по оптимизации. До оптимизации среднее время выполнения составляло t̄=3 318,8 мс (95%-ный ДИ: ±594,2 мс). Сокращённый план EXPLAIN ANALYZE до оптимизации показал три ключевых признака: полное сканирование таблицы Site (271 453 строки), формирование соединения Owner ⨝ Site объёмом 13 105 строк и 25 422 итерации зависимого подзапроса.
Причина задержки связана с порядком доступа к данным. Из-за отсутствия индекса на Owner.area MySQL начинает выполнение с полного сканирования Site (271 453 строки), затем для каждой строки Site обращается к Owner и проверяет условие area=2; в результате соединение Owner ⨝ Site даёт 13 105 строк. Зависимый подзапрос запускается 25 422 раза, что зафиксировано в поле loops плана EXPLAIN ANALYZE. В литературе по коррелированным подзапросам отмечается, что такая стратегия может приводить к повторному выполнению подзапроса для кортежей родительского запроса [14], а исследования сложных запросов показывают зависимость времени выполнения от структуры запроса, индексирования и оптимизации [15]. В настоящей работе конкретный эффект индекса Owner.area определяется фактическим планом EXPLAIN ANALYZE и собственными замерами.
Репрезентативность замеров и эксперимент после оптимизации. После создания индекса (CREATE INDEX idx_owner_area ON Owner(area)) режим byOne был протестирован на сценарии с nominal=f_oper – операционным номиналом, для которого в Чуйском регионе зарегистрировано O(10²) объектов. Это подтверждено запросом COUNT(DISTINCT Site.ID); конкретное значение f_oper не публикуется. Нулевое число строк в результате byOne объясняется тем, что первая запись Freq по LIMIT 1 для конкретного объекта может не совпасть с запрошенным номиналом. Однако EXPLAIN ANALYZE показывает, что соединение Owner ⨝ Site по-прежнему даёт 13 105 строк, а подзапрос выполняется 25 422 раза. Следовательно, измерение отражает объём вычислительной работы данного плана запроса. При этом nominal=f_test и nominal=f_oper не трактуются как полностью сопоставимые по предметному содержанию; их сопоставимость ограничена совпадением ключевых характеристик фактического плана выполнения.
Таблица 2
Производительность механизма поиска (MySQL 8.0.45, n=5, тёплый кеш)
|
Сценарий (активные предикаты) |
Замеры t, мс |
t̄, мс |
s, мс |
95% ДИ |
Записей |
|
Полный реестр (ориент.†) |
2 584† |
- |
- |
- |
667 193 |
|
area=Чуйская (код 2) |
53; 53; 52; 70; 52 |
56,0 |
7,8 |
±9,7 |
24 564 |
|
area + state=Действующее (код 2) |
34; 40; 28; 33; 51 |
37,2 |
8,8 |
±10,9 |
15 047 |
|
area + nominal=f_test |
17; 11; 11; 17; 10 |
13,2 |
3,5 |
±4,3 |
0 |
|
area + state + nominal=f_test |
18; 10; 10; 9; 16 |
12,6 |
4,1 |
±5,1 |
0 |
|
byOne (до оптимизации, nom=f_test) |
4 172; 3 137; 3 134; 3 113; 3 038 |
3 318,8 |
478,6 |
±594,2 |
0 |
|
byOne (после INDEX, nom=f_oper) |
557; 526; 510; 556; 490 |
527,8 |
29,1 |
±36,2 |
0* |
Примечание: составлено авторами. (†) – одиночный ориентировочный замер, ДИ не вычислялся. (*) – 0 строк в результате: режим byOne выбирает первую запись Freq по LIMIT 1, которая может не совпадать с запрошенным номиналом; это не патологический случай – EXPLAIN ANALYZE подтверждает одинаковое число итераций независимо от результата (см. текст). Число объектов с nominal=f_oper в регионе: O(10²); конкретные значения f_test и f_oper не публикуются, поскольку в данном сравнении существенны не предметные свойства частот, а совпадение ключевых характеристик фактического плана выполнения запроса. 95% ДИ = ±2,776·s/√5.
Таблица 3
Планы EXPLAIN ANALYZE для режима byOne до и после оптимизации
|
Характеристика плана |
До CREATE INDEX |
После CREATE INDEX idx_owner_area |
|
Точка входа |
Full scan: Site (271 453 стр.) |
Index lookup: Owner.idx_owner_area (4 654 стр.) |
|
Строк соединения Owner ⨝ Site (actual) |
13 105 |
13 105 (без изменений) |
|
Итераций подзапроса (loops, EXPLAIN ANALYZE) |
25 422 |
25 422 (без изменений) |
|
Сценарий замеров |
nominal=f_test |
nominal=f_oper (O(10²) объектов) |
|
t̄, мс (95% ДИ) |
3 318,8 (±594,2) |
527,8 (±36,2) |
|
Ускорение (95%-й ДИ, бутстрэп) |
- |
в 6,2 раза [5,69–7,16 раза] |
Источник: расчёты авторов по фактическим значениям EXPLAIN ANALYZE (actual rows, loops) и замерам времени выполнения запроса; бутстрэп: B=100 000 псевдовыборок, исходные замеры (табл. 2). Данные отражают внутренний агрегированный набор действующего реестра; подтверждающие неперсонализированные материалы могут быть предоставлены редакции по запросу.
После оптимизации среднее время выполнения составило t̄=527,8 мс (s=29,1 мс, 95%-ный ДИ: ±36,2 мс). Для коэффициента ускорения, рассчитанного методом бутстрэпа, 95%-ный доверительный интервал составил 5,69–7,16 раза. EXPLAIN ANALYZE показал изменение точки входа в запрос: вместо полного сканирования Site (271 453 строки) использован индексный поиск по Owner.idx_owner_area (4 654 строки). При этом число итераций зависимого подзапроса (25 422) и число строк соединения Owner ⨝ Site (13 105) не меняются, то есть сам подзапрос оптимизацией не затронут. Следовательно, ускорение достигается именно за счёт устранения полного сканирования промежуточной таблицы. Сводное сопоставление планов до и после оптимизации приведено в таблице 3.
Обобщаемость выявленной закономерности. Полученный результат не следует трактовать как доказательство универсального ускорения во всех реестровых системах. Он описывает конкретную закономерность плана выполнения запроса, выявленную в исследованном реестре. Исследования производительности сложных запросов показывают, что эффективность выполнения зависит от структуры запроса, сложности связей между данными, индексирования и оптимизации [15]. Поэтому аналогичный эффект может ожидаться только при одновременном выполнении трёх условий: (а) на верхнем уровне есть категориальный атрибут с низкой кардинальностью, используемый как основной фильтр; (б) запрос к нижнему уровню реализован как зависимый подзапрос; (в) индекс на этом атрибуте отсутствует. В такой ситуации добавление индекса может изменить точку входа в план запроса и устранить полное сканирование промежуточной таблицы. Смежные публикации по индексированию и оптимизации выполнения SQL-запросов подтверждают, что выбранная стратегия доступа к данным и способ исполнения запроса могут существенно влиять на план и время выполнения [16; 17]; при этом конкретная величина ускорения в 6,2 раза относится только к исследованному набору данных и измеренному запросу.
Оценка числа потенциально заполняемых полей. Подсчёт атрибутов показывает, что при ручном создании записи оператор потенциально заполняет около 50 полей (Owner + Site + Freq), тогда как операция Copy оставляет для заполнения около 15 административных полей Owner. Таким образом, структурное сокращение числа потенциально заполняемых полей составляет примерно 70%. Этот показатель не следует интерпретировать как равное снижение времени работы оператора или как доказанное снижение числа ошибок ввода, поскольку хронометраж действий пользователей и анализ ошибок в настоящем исследовании не проводились. Архивные данные журнала предшествующей системы показывают, что в 2008–2012 гг. функция копирования использовалась в среднем 2 061 раз в год; эти данные подтверждают практическую востребованность сценария копирования, но не являются прямым измерением его текущего временного эффекта.
Интегрированный рабочий контур
Полученные результаты позволяют описать поиск и каскадное копирование как связанные элементы рабочего контура. Сначала оператор выполняет поиск: в измеренных сценариях типовые запросы занимали 7–56 мс и постепенно сужали выборку от 667 193 записей до нуля. Затем может выполняться копирование: система воспроизводит дерево Owner→Site→Freq, а число потенциально заполняемых оператором полей сокращается примерно с 50 до 15. Такая логика повторного использования уже имеющихся сведений концептуально согласуется с принципом однократного предоставления данных [9; 10], однако в данной статье проверяется не общий административный эффект, а конкретные технические показатели поиска, индексирования и структурного сокращения числа полей ввода. Далее возможны экспорт выборки Fʹ в XLSX и формирование PDF после проверки целостности выбранных записей и вычисления контрольной метки документа. Экспорт и печать в настоящей статье описываются только функционально: их влияние на производительность рабочего процесса количественно не оценивалось.
Ограничения исследования
При интерпретации результатов важно учитывать несколько ограничений. Во-первых, замеры проводились при n=5 и тёплом кеше, поэтому при холодном кеше численные значения могут отличаться. Во-вторых, подсчёт атрибутов схемы даёт только структурную оценку сокращения числа потенциально заполняемых полей и не доказывает пропорциональное снижение времени работы оператора. В-третьих, в исследовании не проводился хронометраж действий пользователей и не измерялась частота ошибок ввода до и после применения Copy. В-четвёртых, данные об интенсивности операций копирования (2 061 в год) относятся к предшествующей системе и не обязательно полностью отражают текущую практику. В-пятых, сравнение nominal=f_test и nominal=f_oper ограничено совпадением ключевых характеристик фактического плана выполнения запроса и не означает полной предметной эквивалентности этих частотных номиналов. В-шестых, сопоставление с близкими по тематике публикациями [11; 12] опирается на ограниченный массив открыто доступных работ и не претендует на исчерпывающий обзор всех специализированных систем управления спектром. В-седьмых, количественная оценка производительности фаз экспорта и подготовки печатных форм в данной статье не проводилась. Наконец, операция Copy в текущей реализации описана как каскад JDBC-вставок; её оформление как явной ACID-транзакции относится к дальнейшей доработке.
Выводы
С учётом полученных результатов, их обсуждения и обозначенных ограничений можно сформулировать основные выводы. В статье описаны и экспериментально оценены механизмы поиска прототипа и каскадного копирования в государственном радиочастотном реестре. Ключевые результаты таковы.
1. Типовые запросы поиска выполняются за 7–56 мс; последовательное добавление предикатов сокращает пространство кандидатов от 667 193 до 0 записей.
2. Посредством EXPLAIN ANALYZE диагностирована закономерность: отсутствие индекса на Owner.area (9 значений) → полный скан Site (271 453 строки) → t̄=3 318,8 мс. Создание INDEX(area) даёт t̄=527,8 мс (ускорение в 6,2 раза; 95%-ный ДИ, бутстрэп: 5,69–7,16 раза), что подтверждено на операционном сценарии с ненулевым числом объектов для nominal=f_oper. Сопоставление сценариев основано на совпадении ключевых характеристик фактического плана выполнения запроса, а не на полной предметной эквивалентности nominal=f_test и nominal=f_oper. За пределами исследованного реестра результат следует рассматривать как архитектурно обусловленное ожидание, применимое только при наличии сходного сочетания условий: категориального фильтра верхнего уровня, зависимого подзапроса и отсутствующего индекса по полю фильтрации.
3. Подсчёт атрибутов показывает снижение числа потенциально заполняемых оператором полей с около 50 до около 15, то есть примерно на 70%. Этот результат характеризует структурное сокращение объёма ввода, но не является прямым измерением времени работы оператора или частоты ошибок ввода.
К направлениям дальнейших исследований относятся хронометражное исследование с участием операторов, измерение частоты ошибок ввода до и после применения Copy, оформление операции Copy как явной ACID-транзакции, количественная оценка экспорта и печати, а также расширение эксперимента (n≥30, холодный кеш).
Конфликт интересов
Финансирование
Библиографическая ссылка
Аданбаев А. М., Сагымбаев А. А. ПОИСК ПРОТОТИПА И КАСКАДНОЕ КОПИРОВАНИЕ В РАДИОЧАСТОТНОМ РЕЕСТРЕ: ПРОИЗВОДИТЕЛЬНОСТЬ И ОПТИМИЗАЦИЯ ЗАПРОСОВ // Международный журнал прикладных и фундаментальных исследований. 2026. № 2. С. 32-39;URL: https://applied-research.ru/ru/article/view?id=13788 (дата обращения: 21.05.2026).
DOI: https://doi.org/10.17513/mjpfi.13788