CC BY
35
УДК 004.09;
ПРОЕКТИРОВАНИЕ ДАННЫХ ДЛЯ КОМПЬЮТЕРНОЙ ОБРАБОТКИ
В ФИСКАЛЬНЫХ СИСТЕМАХ
Алексей Владимирович Буравцев, зам. директора Института информационный технологий и автоматизированного проектирования E-mail: buravcev@mirea.ru Алексей Николаевич Щенников, директор Института информационных технологий
и автоматизированного проектирования E-mail: anschennikov@mirea.ru Московский технологический университет (МИРЭА) https://www.mirea.ru/
В статье рассмотрены методы организации структур данных для сложных организационно-технических фискальных систем. Предлагается организация данных в виде системы данных, обладающей системными свойствами. Система данных организована в виде иерархической структуры как совокупность ориентированных ациклических графов. Раскрывается содержание сложной организационно технической фискальной системы. Показано, что ядром фискальной системы является адресный реестр. Основу адресного реестра составляет база данных. Показано, что качество информационной системы определяется качеством обработки и качеством организации данных. Предлагаемый метод организации данных решает задачи не только хранения данных, но и задачи обработки информации.
Ключевые слова: фискальная система, сложная организационно-техническая фискальная система, качество системы, организация данных, ориентированные ациклические графы, SQL
Введение. Для любых информационных систем и сложных организационных систем важным фактором является оценка качества такой системы. Основой оценки качества программного обеспечения и информационных систем в настоящее время являются отечественный стандарт ГОСТ Р ИСО/МЭК 25010-2015 «Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов» и зарубежный стандарт ISO/IEC 25010:2011 «Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программного обеспечения» [1]. Это отражает современную концепцию развития программного обеспечения на основе системной и программной инженерии [2]. Такой интегрированный подход требует проводить разработку информационных систем и программного обеспечения к ним с позиций качества. В соответствии со стандартом ГОСТ Р ИСО/МЭК 25010-2015 в системах выделяют три модели качества: модель самого алгоритма и модель применения алгоритма, модель качества данных. Поэтому разработка любой системы связана с разработкой программного обеспечения и с разработкой качественной модели данных. В силу этого тематика данной статьи соответствует требованиям стандартов качества ГОСТ Р ИСО/МЭК 25010-2015, ISO/IEC 25010:2011 и является необходимым при исследовании и создании любых сложных систем, включающих компьютерную обработку.
Системная и программная инженерия как основа компьютерной обработки и проектирования. Системная и программная инженерия прошли несколько этапов
развития, в процессе которых были сформулированы фундаментальные принципы и методы разработки. Они стали основой для проектирования, реализации и сопровождения крупных технических и программных систем. Развитие современных многоаспектных систем часто требует вклада различных технических дисциплин. Благодаря системному мышлению системная инженерия помогает формировать в единый междисциплинарный комплекс всех технических участников проекта, структурированный процесс разработки проекта и ресурсы проекта. Системная инженерия осуществляет, переход от концепции к производству в эксплуатацию. Системная инженерия как учебная дисциплина представляет собой интегративную дисциплину, которая изучает системное проектирование, элементы системного анализа, компромиссы между расходами и балансами, поддерживая приемлемый уровень риска, охватывающий весь жизненный цикл изделия.
В основу деятельности системного инженера должно быть положено понимание того, что целью всего процесса системной инженерии является оптимальное проведение функциональных границ между человеческими интересами, системой и ее окружением. В самом же окружении выделяются три главные составные части: физическое и техническое окружение; деловое и экономическое окружение; социальное окружение.
Системная инженерия уделяет первостепенное внимание исследованию потребностей, в основе которого должно лежать использование передовых экономических теорий, учет потребностей рынка и возможность изменения этих потребностей как сейчас, так и в будущем. Программная инженерия направлена на исследование, проектирование, разработку и тестирование программного обеспечения на разных уровнях создания и эксплуатации. Оно используется для реализации программного обеспечения для медицинских, промышленных, военных, коммуникационных, аэрокосмических, деловых, научных и общих вычислительных приложений. Базовой основой является свод знаний по системной инженерии ^ЕВоК) [3] и свода знаний по программной инженерии (SWEBOK) [4], наиболее полно раскрывающих содержание предметной области.
Особенности СОТФС. При разработке любой информационной или организационной системы необходимо учитывать ее особенности. Сложная организационно техническая фискальная система (СОТС) является интеграцией информационно-вычислительных систем, сложных организационно-технических систем [5, 6] и фискальных кадастровых систем [7, 8].
Фискальными называются системы, основной прикладной функцией которых является сбор налогов. Как вычислительные системы СОТФС в качестве основы имеют обширную базу данных (на всю страну), ядром которой является адресный реестр [9], представляющий собой также самостоятельную информационную систему, решающую задачи систематизации, учета и обновления адресных объектов Российской Федерации. Масштабность и значимость такой системы ставит важную задачу обработки адресной информации [10]. Методологическая поддержка, разработка эффективных алгоритмов и информационных систем контроля и обработки адресной информации является важным направлением в совершенствовании информационных систем кадастра. Адресный реестр, являясь составным элементом СОТФС, влияет на реализацию всего набора стратегических целей и задач государства, от создания эффективного рыночного оборота недвижимости для формирования доходной налоговой базы, до социальной защиты населения и планирования миграционной политики [10].
Построение и поддержка в актуальном, полном, достоверном, целостном и непротиворечивом состоянии адресного реестра СОТФС - процесс, требующий активного применения методов создания и применения качественного программного обеспечения и структуризации данных. Наличие развитых средств представления и оперирования структурами данных, которые можно представить в виде ориентированного графа, особенно необходимо при конструировании сложных организационно-технических фискальных систем (СОТФС), в которых данные представлены в иерархическом виде. Су-
ществуют различные подходы в организации хранения иерархических структур в реляционных БД. Осуществление их потенциала требует объединения многих факторов из различных сфер деятельности. Являясь разновидностью сложных систем, подобного рода сложные организационно-технические фискальные системы в настоящее время нуждаются в развитии. Для анализа и развития таких систем необходимо применение системного анализа.
СОТФС как сложная система. Под сложной системой понимают множество элементов, которые находятся в связях и отношениях друг с другом [11-13]. Данные элементы в системе образуют единство, целостность и обладают свойством эмер-джентности [14]. Состав элементов системы меняется в зависимости от целей и контекста ее использования.
Необходимо отличать понятие «система», как технический объект, понятие система как информационная система и понятие «система» как формальный объект. Для «системы-объекта» характерно наличие: технических требований; технической и рабочей документации; ресурсного обеспечения, организационного обеспечения, технического обеспечения. Для информационной системы характерно наличие: информационного, процедурного и программного обеспечения. Разбиение СОТФС на элементы осуществляется в зависимости от критерия делимости системы. Элементы могут объединяться в компоненты системы или в подсистемы.
Формально опишем СОТФС (COTFS) как модель, которую можно представить в следующем виде:
COTFS = <Ps, Pr, Str, E, C, R, G, int, out, AT, Cog> (1)
где Ps - совокупность подсистем системы; Pr - совокупность частей системы; Str - структура системы; E - множество элементов системы; C - множество связей в системе; R - множество отношений между элементами, частями и подсистемами, int - множество входов, out - множество выходов системы, AT - интервал жизненного цикла системы, Cog - когнитивный фактор.
Данное определение показывает, что система представляет из себя некую структуру, состоящую из разнородных частей.
Для обеспечения качества обработки информации в сложной системе важно наличие информационного соответствия [15] между алгоритмами обработки и организацией данных. В случае СОТФС структуру данных можно представить в иерархическом виде, а именно в виде ориентированного ациклического графа.
Ориентированные графы. Во многих областях науки и техники важную роль играет понятие иерархии, иерархической структуры. Для таких областей как теория систем, теория управления, типичным является представление объекта исследования (системы) в виде структуры подчиненности одних элементов системы другим.
Ориентированные ациклические графы являются топологической моделью иерархических структур.
Ориентированный граф (сокращённо орграф) G - это упорядоченная пара
G = <V, A>,
где Vэто множество вершин или узлов, A = {(vi, v2) : vi , v2 £ V} - это множество упорядоченных пар различных вершин, называемых дугами или ориентированными рёбрами.
Присутствие во множестве A вектора (vi, v2) соответствует наличию связи (дуги) между вершинами vi и V2 графа. Если в орграфе нет циклов - последовательностей дуг вида (vi, v2), ... , (vn, vi) , то он называется ациклическим.
Направленный ациклический граф (ориентированный ациклический граф, DAG от англ. directed acyclic graph) — орграф, в котором отсутствуют направленные циклы, но могут быть «параллельные» пути, выходящие из одного узла и разными путями приходящие в конечный узел (рис.1). Направленный ациклический граф является обобщением дерева (точнее, их объединения — леса). Направленные ациклические графы широ-
ко используются в приложениях: в компиляторах, в искусственном интеллекте для представления искусственных нейронных сетей без обратной связи, в статистике и машинном обучении [16].
Важным частным случаем ориентированного ациклического графа является дерево
Деревом называется орграф для которого выполняются следующие условия:
- существует узел, в которой не входит ни одной дуги - этот узел называется корнем;
- в каждую вершину, кроме корня, входит одна дуга.
Если рассматривать структуру такого кадастрового реестра как государственный адресный реестр, который является фундаментальной частью СОТФС ФИАС, то можно заметить, что она представлена в виде ориентированного ациклического графа.
Ориентированные ациклические графы в реляционных базах данных. Организация данных в БД преследует цели не только хранения, но и обработки. Организация данных в виде ациклических графов позволяет использовать ациклические алгоритмы. Ациклические алгоритмы не имеют циклов, не зависают и обладают большей надежностью. В итоге, организация данных в виде ациклических графов повышает надежность обработки и надежность СОТФС в целом.
Хранение иерархических данных в реляционных структурах задача, требующая особых подходов, т.к. реляционные базы данных не приспособлены к хранению иерархических структур (как, например, форматы XML или JSON), т.к. структура реляционных таблиц представляет из себя обычные списки. Иерархические данные имеют синтагматическую связь «parent-child» («предок-наследники»), которая не реализована в явном виде в реляционной структуре.
Именно поэтому задача хранения и обработки ориентированных графов в реляционной базе представляет актуальность в отношении СОТФС, чьи данные моделируется в иерархическом виде. Ниже мы подробно рассмотрим некоторые подходы в организации хранения иерархических структур в реляционных БД.
Пусть существуют данные, которые можно представить в виде ориентированного графа. Рассмотрим основные операции, которые необходимы для оперирования над этими данными на языке SQL: вставка и удаление узла, получение предков, потомков и другие операции. Существует четыре основных подхода при проектировании баз данных для хранения и обработки данных в виде иерархической структуры:
• вложенные множества (nested sets)
• список смежности (adjacency list)
• таблица связей или таблица замыканий (closure table)
• материализованный путь (materialized path или path enumeration)
В этой статье мы остановимся на первых трех подходах.
Вложенные множества (Nested sets). Подход «Вложенные множества» подразумевает присвоение каждому узлу в дереве двух дополнительных ключей: left key и right key. Назовем эти два числа L и R, соответственно левым и правым. Эти атрибуты кодируют порядок следования узлов в иерархии, для упрощения некоторых запросов в данной структуре. Вот правила, которые регулируют их использование [17, 18]:
- L и R имеют общую область упорядоченных значений целого типа. Присваиваемое значение из этой области может использоваться только один раз, либо как значение L, либо значение R. Для каждого узла значение L должно быть строго меньше значения R;
- L и R хотя и уникальны, но не должны использоваться для внешней идентификации какого-либо объекта, т.к. они могут быть произвольно переназначены для лучшего облегчения эффективного поиска;
- Любые два узла удовлетворяют соотношению между предками и потомками точно, когда значение L (или R) потомков находится между значениями L и R предка:
(Li < Lj < Ri) О i ancestor of j (Li < Rj < Ri) О i ancestor of j где L - левое значение, R - правое значение, О - обозначение логической операции эквивалентности, «ancestor of» - переводится как «является предком».
Для заполнения этих ключей нам придется полностью обойти всё дерево дважды посещая каждый из узлов. В результате выборка из дерева будет происходить довольно быстро. С другой стороны, изменение структуры требует пересчета всех ключей в узлах, следующих за изменяемым узлом.
Плюсы данного подхода хорошо рассматривать в сравнении с моделью родитель-ребенок, в которой каждый узел имеет свой собственный уникальный идентификатор и идентификатор своего родителя. Сами идентификаторы не имеют никакого отношения к данным, они все лишь служат уникальными определителями узла. Корень дерева должен иметь специальное значение идентификатора родительского узла (например, NULL), так как у корня родителей нет. К сожалению, возникают проблемы при использовании такой модели, если нужно получить все дочерние элементы одного узла. Дело в том, что количество необходимых запросов нашем случае придется выполнить на один запрос больше, чем высота дерева данных. Попытка получения всех дочерних элементов одного узла приведет к множеству запросов к базе данных при использовании большого количества данных.
Подход вложенных множеств поможет решить эту проблему. Вместо идентификатора родителя необходимо хранить значения левого и правого значения узла. Рассмотрим схему (рис. 2) и таблицу 1 на примере адресных данных.
Для определения значений left и right нужно начать с верхнего узла и счетчика равного нулю, соответственно начав перемещение по левой стороне дерева. При прохождении узла счетчик увеличивается на единицу и записывается в узел. Если текущее положение слева от узла, то значение счетчика представляет собой значение left, а если справа, то right. Данные на рис. 1 можно представить в виде таблицы 1.
Таблица 1
Данные, представленные по принципу «вложенные множества»
id left right name
0 0 13 Москва
1 1 8 Зеленоград
2 9 12 Троицк
3 2 5 Кутузово
4 6 7 Малино
5 3 4 Кутузова
6 10 11 Десна
Значение left и right хранят ссылки на дочерние узлы. В свою очередь дочерние узлы тоже имеют такие переменные, отсюда и взялось определение вложенных множеств. Получим все дочерние элементы узла «Зеленоград» (id = 1) с помощью следующего запроса:
SELECT * FROM ao_set WHERE [left] > 1 AND [right] < 8
пропорционально высоте дерева. В
Рис.2. Древовидная структура, организованная по принципу «вложенные множества»
В результате получим узлы «Кутузово», «Малино» и «Кутузова». Отметим, что мы обошлись без рекурсии, обойдясь одним запросом. Получим всех предков узла, включая данные самого узла:
SELECT * FROM ao_set child JOIN ao_set ancestor ON child.[left] BETWEEN ancestor.[left] AND ancestor.[right] WHERE child.id = 5
В результате получим узлы «Москва», «Зеленоград», «Кутузово» и «Кутузова». Опять видим, что можно обойтись без рекурсивных запросов. Получим поддерево для узла «Зеленоград», включая сам узел:
SELECT * FROM ao_set parent JOIN ao_set descendant ON descendant.[left] BETWEEN parent.[left] AND parent.[right] WHERE parent.id = 1
В результате получим узлы «Зеленоград», «Кутузово», «Малино» и «Кутузова». Вставим новый дочерний объект (лист) в дерево:
UPDATE ao_set SET [right] = [right]+2 WHERE [right] >= 9; INSERT INTO ao_set ([id], [left], [right], [name]) VALUES (7, 11, 12, 'Иваново')
В зависимости от позиции вставляемого узла, вид запроса и количество изменяемых «левых» и «правых» значений узлов меняется. Удаление конечного узла (у которого нет потомков) и удаление узла с потомками также потребует пересчета «левых» и «правых» узлов в цепочке, а также непосредственно удаление самого узла. Особым случаем является удаление корневого узла, в результате которого, можно получить несколько деревьев. Если у корня было несколько потомков, то в итоге они станут корневыми узлами.
Преимуществом вложенных множеств является простота чтения прямых потомков узла, а также целого поддерева. Также чтение всех листов может быть реализовано с использованием единственного запроса. Размер строки постоянен (добавляются только два отдельных значения), даже если орграф очень велик. Получение родителя или всех предков узла быстры, и можно получить глубину узла в иерархии, используя операторы COUNT и GROUP BY. Но есть один большой недостаток: добавление или удаление узлов требует пересчета левого и правого значений множества узлов в дереве, поэтому невозможно использовать это решение в больших орграфах. Альтернативным вложенным наборам вариантом является подход вложенных интервалов, но он не дает лучшей производительности при обновлении орграфов. Более подробная информация о данном решении в [19, 20].
Список смежности (Adjacency List). Есть несколько вариаций представления графа списком смежности, отличающихся особенностями ассоциации вершин и коллекций соседей, реализацией коллекций, включаются ли рёбра и вершины в коллекции соседей или только вершины, способами представления рёбер и вершин:
- реализация с использованием хэш-таблицы для ассоциации каждой вершины со списком смежных вершин. Нет явного представления рёбер в этой структуре [21, 22];
- реализация, в которой вершины представлены числовым индексом в массиве, в котором каждая ячейка массива ссылается на однонаправленный связанный список соседних вершин [23];
- объектно-ориентированный список смежности, содержит специальные классы вершин и рёбер. Каждый объект вершины содержит ссылку на коллекцию рёбер. Каждый объект ребра содержит ссылки на исходящую и входящую вершины [24].
Таблица 2
Сравнение оценок сложности операций для списка смежности с матрицей смежности [25]
Операция Список смежности Матрица смежности
Проверка на наличие ребра (х,у) O(|V| + |E|) O(1)
Определение степени вершины O(1) O(|V|)
Использование памяти для разреженных графов O(|V| + |E|) O(|V|2)
Вставка/удаление грани O(1) O(d)
Обход графа O(|V| + |E|) O(|V|2)
Как правило, такая структура данных предполагает хранение информации о смежных вершинах нашего дерева. Рассмотрим простейший граф с тремя вершинами
(1,2,3) (рис.3).
Этот цикличный ненаправленный граф может быть описан тремя списками, в которых хранится информация о связи каждого элемента данного графа с другими элементами, т.е. 1 связан с 2 и 3, 2 связан с 1 и 3, 3 связан с 1 и 2. Фактически, для построения дерева такой граф избыточен, т.к. для привычной ветвистой структуры нам нужно хранить только связь «родитель-наследник», т.е. 2-1 и 3-1. Тогда мы получим дерево с одним корневым элементом (1) и двумя ветками (2,3). Тот и другой графы можно, при желании, отобразить в базе данных с помощью списка смежных вершин, но, поскольку нас интересуют именно деревья, остановимся на них.
На первый взгляд управление деревом Adjacency List довольно простое. Но эта простота приводит к определенным проблемам, так очень просто, можно назначить подчинение первого узла второму, а второго первому, что может привести к бесконечному зацикливанию при выборе дерева, можно назначить родителем узла несуществующий ID и тогда ветка полностью исключится из дерева. Соответственно отсюда определим правила:
- узел может подчиняться только существующему узлу;
- узел не может подчиняться потомку.
Итак, чтобы хранить в базе данных иерархическую структуру методом списка смежных вершин (Adjacency List), нам необходимо хранить информацию о связях «наследник-родитель» в таблицах с данными. Давайте рассмотрим реальный пример дерева на основе адресных данных (рис. 4).
На рисунке квадратами обозначены узлы деревьев. У каждого узла есть имя (верхний Рис.4. Древовидная структура, организованная по
прямоугольник внутри квадрата), принципу «т^ьге вершины»
идентификатор (левый нижний квадрат) и ссылка на идентификатор родителя (правый нижний квадрат). Как видно из рис. 3, каждый наследник в такой структуре ссылается на своего предка. В табличном виде данные, изображенные на рис. 3, можно представить в виде таблицы 3.
Таблица 3.
Данные в таблице, организованные по принципу «смежные вершины»
id parent id name
1 NULL Москва
2 1 Зеленоград
3 2 Кутузово
Рис. 3. Граф с тремя вершинами
Зеленоград
2 1 1
Значение
ID РШ
Москва
null
Кутузово
3 2
Малнно
4 2
Троицк
5 1
Десна Пыхчево
6 5 7 5
О уровень
1 уровень
2 уровень
4 2 Малино
5 1 Троицк
6 5 Десна
7 5 Пыхчево
Операция вставки новых узлов довольно тривиальна. Например, добавим узлу «Троицк» подчиненный объект «Новое»:
INSERT INTO ao_list (id, parent_id, name) VALUES (8, 5, 'Новое');
Изменения родителя узла тоже выполняется простейшей операцией обновления. Например, у объекта «Новое» изменим родителя на «Зеленоград»:
UPDATE ao_list SET parent_id=2 WHERE id=8
При этом, если бы у объекта «Новое» были какие-либо подчиненные объекты, то изменять их в нашем случае не нужно было бы.
Запрос на получение в табличном всех родительских и дочерних объектов:
SELECT parent.*, child.* FROM ao_list parent LEFT JOIN ao_list child ON (child.parent_id = parent.id);
Запрос на получение родительских узлов для всех дочерних узлов:
SELECT child.*, parent.* FROM ao_list child JOIN ao_list parent ON (child.parent_id = parent.id);
Если нам нужно выяснить уровень вложенности объектов, то придется использовать рекурсивный запрос с помощью оператора WITH:
WITH DepthTree (id, parent_id, name, depth) AS ( SELECT *, 0 AS depth FROM ao_list WHERE parent_id IS NULL UNION ALL
SELECT c.*, dt.depth+1 AS depth FROM DepthTree dt JOIN ao_list c ON (dt.id = c.parent_id)) SELECT * FROM DepthTree;
Можно сделать вывод, что данный подход хорошо применим в случае, если приходится оперировать небольшими древовидными структурами, которые сравнительно часто изменяются.
Самым большим преимуществом этого подхода является простое добавление или удаление узлов, которое выполняется за постоянное время.
Также, этот подход довольно уверенно себя чувствует и с большими деревьями, если считывать их порциями вида «знаю предка - прочитать всех наследников». Хороший пример такого случая - динамически подгружаемые деревья. В данном случае алгоритм оптимизирован для такого поведения.
Тем не менее, он плохо применим, когда нужно считывать какие-либо иные части дерева, находить пути, предыдущие и следующие узлы при обходе и считывать ветки дерева целиком (на всю глубину).
Таблица связей (Closure Table или таблица замыканий). Выше упоминалось, что получение поддерева с использованием стандартного списка смежности является трудной задачей, и нужно использовать рекурсию. Но есть еще одно решение, требующее некоторой избыточности в базе данных. Цель этого метода заключается в создании транзитивного замыкания графа отношения.
Рассмотрим орграф G = <V E>, где V - множество вершин или узлов, E - это множество упорядоченных пар различных вершин, называемых дугами или ориентированными рёбрами. Под бинарным отношением на множестве V будем понимать произвольное подмножество
E £Vx V (множество дуг графа G = <V, E>), где £ - знак операции «является подмножеством либо равно».
Бинарное отношение E можно однозначно представить графом
G = <V, E>.
Бинарное отношение на графе G = <V, E> является транзитивным при выполнении условия:
если <x, y> Е E и <y, z> E E, то <x, z> E E для произвольных вершин
x, y, z E V,
где E - знак операции принадлежности к множеству.
Суть применения шаблона Closure Table в базе данных заключается в том, что связи между сущностями хранятся в отдельной таблице - таблице замыканий, тогда как основная таблица содержит только данные самих сущностей. Closure Table - это таблица, получаемая методом транзитивного замыкания.
Таблица связей должна содержать как минимум два поля:
- ссылку на родительский элемент (ancestor),
- ссылку на дочерний элемент (descendant).
Возьмем для примера структуру адресных данных, изображенных на рис. 3.
У нас в данном случае получилось бы две таблицы, первая таблица (таб. 3) хранит адресные данные, а вторая таблица - данные полученные методом транзитивного замыкания (таблица 4).
Таблица 4
Таблица с данными, полученные методом транзитивного замыкания
ancestor 1 1 1 1 1 1 1 2 2 2 3 4 5 5 5 6 7
descendant 1 2 3 4 5 6 7 2 3 4 3 4 5 6 7 6 7
Рассмотрим запрос получения потомков для узла «Троицк»:
SELECT ao.* FROM ao JOIN TreePath t ON (ao.id = t.descendant) WHERE t.ancestor = 5;
Полученный результат представлен в таблице 5.
Таблица 5
Результат выполнения запроса получения потомков для узла «Троицк»
id name
5 Троицк
6 Десна
7 Пыхчево
Рассмотрим запрос получения предков для узла «Десна»:
SELECT ao* FROM ao JOIN TreePath t ON (ao.id = t.ancestor) WHERE t.descendant = 6;
Полученный результат представлен в таблице 6.
Таблица 6
Результат выполнения запроса получения предков узла «Десна»
id name
1 Москва
5 Троицк
6 Десна
Удалим все поддерево для узла «Троицк»:
DELETE FROM TreePath WHERE descendant IN (SELECT descendant FROM TreePath WHERE ancestor = 5);
Добавим в узел «Троицк» новый узел «Новое»:
INSERT INTO ao VALUES (8, 'Новое'); INSERT INTO TreePath (ancestor, descendant) SELECT ancestor, 8 FROM TreePath WHERE descendant = 5 UNION ALL SELECT 8, 8;
Можно расширить таблицу замыканий, добавив в нее поле length, хранящее значение глубины вложенности. Это позволит проще находить непосредственного потомка или родителя, например, запрос:
SELECT ao.* FROM ao JOIN TreePath t ON (ao.id = t.descendant) WHERE t.ancestor = 2 AND t.length = 2;
вернет непосредственные потомки узла «Зеленоград» (таблица 7).
Таблица 7
Результат выполнения запроса поиска непосредственных потомков узла «Зеленоград»
id name
3 Кутузово
4 Малино
Отметим недостатки «Closure Table». Шаблон «Closure Table» часто критикуют за то, что необходимо хранить в базе данных связи каждого элемента дерева со всеми его предками, а также ссылку каждого элемента на самого себя. Чем глубже в иерархии располагается элемент, тем больше записей в таблице необходимо сделать. Очевидно, что добавление новых элементов в конец глубокой древовидной иерархии будет менее эффективным, чем вставка элементов вблизи корня дерева. Кроме этого, стоит отметить, что для хранения деревьев метод Closure Table требует больше места в базе данных, чем любой другой метод.
Для того чтобы объективно оценить значимость этих замечаний, их следует рассматривать в контексте специфики реального проекта. Например, снижение производительности при добавлении нового элемента на сотый или тысячный уровень может быть незначительным или некритичным для работы приложения, или же, что ещё более вероятно, такая ситуация вовсе никогда не произойдёт. На практике редко возникает необходимость хранения данных в иерархических структурах большой вложенности. В большинстве случаев, принципиальным параметром является скорость чтения данных, а не записи. Сравнение подходов по степени сложности приведено в таблице 8.
Таблица 8
Сводная таблица сравнения подходов отображения иерархической структуры в
реляционной базе данных [26]
Adjacency List Path Enumeration Nested Sets Closure Table
Минимальное количество таблиц 1 1 1 2
Получение одного потомка Просто Сложно Сложно Просто
Получение иерархии поддерева Сложно Просто Просто Просто
Удаление одного элемента Просто Просто Сложно Просто
Добавление элемента Просто Просто Сложно Просто
Перемещение поддерева Просто Просто Сложно Просто
Обеспечение ссылочной целостности Да Нет Нет Да
Комбинированные подходы. Существуют также комбинированные подходы, которые в данной статье не описываются, но представляют интерес для анализа. Это
специфические решения СУБД MySQL, MSSQL, PostgreSQL и Oracle. Oracle предлагает использовать оператор CONNECT BY. Этот оператор используется для графов, которые являются деревьями. PostgreSQL, MySQL, Microsoft SQL Server предлагают использовать оператор WITH в составе так называемых обобщенных табличных выражений (Common Table Expression - CTE). Данный оператор также может использоваться для построения рекурсивных запросов. Также, начиная с версии SQL Server 2017, появилась возможность хранить графы в специализированных таблицах.
Заключение. Современные фискальные системы являются разновидностью в первую очередь сложных систем [27]. Как прикладные системы [28] они относятся к кадастровым системам. Современные фискальные системы как базы данных по существу являются адресными системами и системами каталогизации. В больших масштабах фискальные информационные системы используются в системах налогообложения. Результат эволюции фискальных систем привел к необходимости использования для реализации фискальной системы сложной организационной технической системы (СОТС). Применительно к решению задач налогообложения эта система трансформировалась в сложную организационно техническую фискальную систему (СОТФС). Разработка эффективных методов контроля и обработки адресной информации является важным направлением в совершенствовании фискальных систем Адресный реестр является основным составным элементом, формирующим СОТФС. Он влияет на реализацию не только налогообложения, но и всего спектра стратегических задач государства, от создания рыночного оборота недвижимости до формирования доходной налоговой базы. Для таких областей как адресный реестр типичным является представление системы в виде структуры подчиненности одних элементов системы другим. Математической моделью иерархических структур данных являются ориентированные графы. Частным случаем ориентированных ациклических графов являются деревья. Существует несколько подходов для хранения и оперирования данными представленными в виде ориентированных ациклических графов или деревьев в реляционных СУБД. Каждый подход имеет свои преимущества и недостатки, и должен выбираться в зависимости от контекста решаемых задач. В тех случаях, когда возможностей одного подхода недостаточно для решения поставленных задач, используют комбинированные подходы. Правильно выбранный подход или подходы при проектировании и реализации адресного реестра СОТФС позволит решить задачи эффективного хранения и оперирования иерархическими данными. Это повышает качество. Организация данных в виде структур ациклических графов повышает быстродействие вычислений и надежность СОТФС.
Литература
1. ISO/IEC 25010:2011 «Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models» https://www.iso.org/standard/35733.html. Дата просмотра 12.12. 2017.
2. Дешко И.П., Кряженков К.Г., Цветков В.Я. Системная и программная инженерия: Учебное пособие. - М.: МАКС Пресс, 2018. 80 с.
3. Guide to the Systems Engineering Body of Knowledge (SEBoK) http://www.sebokwiki.org/wiki/Guide_to_the_Systems_Engineering_Body_of_K^owledge_(SEBoK). Дата просмотра 12.12. 2017.
4. Guide to the Software Engineering Body of Knowledge (SWEBOK Guide) https://www.computer.org/web/swebok. Дата просмотра 12.12. 2017.
5. Буравцев А. В. Функционирование сложной организационно-технической системы в транспортной сфере // Наука и технологии железных дорог. 2017. № 3 (3). С. 48-58.
6. Тихонов А.Н., Иванников А.Д., Соловьёв И.В., Цветков В.Я. Основы управления сложной организационно-технической системой. Информационный аспект. - М.: МаксПресс, 2010. 228 с.
7. Буравцев А.В., Цвектов .В.Я. Эволюция фискальных систем // Государственный советник. 2017. № 2. С. 19-24.
8. БуравцевА.В. Фискальная кадастровая подсистема // Науки о Земле. 2017. № 3. С. 74-85.
9. Федеральная информационная адресная система: [сайт]. URL: http://fias.nalog.ru/
10. Маставичене Т.В. Совершенствование технологии ведения адресного реестра для повы-
шения эффективности информационной системы кадастра недвижимости: дис. ... канд. техн. наук: 25.00.26 - Землеустройство, кадастр и мониторинг земель М. : МИИГАиК, 2016. 124 с.
11. Буравцев А.В. Стратифицированный метод построения сложной системы // Образовательные ресурсы и технологии. 2017. № 3 (20). С. 23-32.
12. Цветков В.Я. Решение проблем с использованием системного анализа // Перспективы науки и образования. 2015. № 1. С. 50-55.
13. Кудж С.А. Системный подход // Славянский форум. 2014. № 1 (5). С. 252-257.
14. Цветков В.Я. Эмерджентизм // Международный журнал прикладных и фундаментальных исследований. 2017. № 2-1. С. 137-138.
15. Ожерельева Т.А. Информационное соответствие и информационный морфизм в информационном поле // Информационные технологии в науке, образовании и управлении. 2017. № 4. С. 86-92.
16. Gao C., Cortés J., Bullo F. Notes on averaging over acyclic digraphs and discrete coverage control // Automatica. 2008. V. 44. №. 8. С. 2120-2127.
17. Kamfonas M.J. Recursive hierarchies: the relational taboo // The Relational Journal. 1992. Т. 27. №. 10. р. 4.
18. Zhu L.L. et al. Unsupervised structure learning: Hierarchical recursive composition, suspicious coincidence and competitive exclusion //European Conference on Computer Vision. - Springer, Berlin, Heidelberg, 2008. p. 759-773.
19. Tropashko V. Trees in SQL: Nested Sets and Materialized Path //URL: www. dbazine. com/tropashko4. shtml. 2002. Дата просмотра 12.12. 2017.
20. Tropashko V. Nested intervals tree encoding in SQL // ACM SIGMOD Record. 2005. V. 34. № 2. p. 47-52.
21. van Rossum G. Python patterns-implementing graphs // Python essays, Python Software Foundation. 1998. Т. 2003.
22. Smedt T.D., Daelemans W. Pattern for python //Journal of Machine Learning Research. 2012. Т. 13. №. Jun. С. 2063-2067.
23. Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, Clifford Stein. Introduction to Algorithms, Second Edition. - MIT Press and McGraw-Hill, 2001. - P. 527-529
24. Goodrich M. T., Tamassia R. Algorithm design: foundation, analysis and internet examples. - John Wiley & Sons, 2006.
25. Skiena S.S. The algorithm design manual: Text. - Springer Science & Business Media, 1998.
26. Karwin B. SQL antipatterns: avoiding the pitfalls of database programming. - Pragmatic Bookshelf, 2010.
27. Кудж С.А. Многоаспектность рассмотрения сложных систем // Перспективы науки и образования. 2014. № 1. С. 38-43/
28. Цветков В.Я. Прикладные системы // Известия высших учебных заведений. Геодезия и аэрофотосъемка. 2005. № 3. С. 78-85
Designing Data for Computer Processing in Fiscal Systems Buravtsev Alexey Vladimirovich.
Deputy Director of the Institute of Information Technologies and Computer-Aided Design Shchennikov Alexey Nikolaevich
Director of the Institute of Information Technologies and Computer-Aided Design Moscow Techno-logical University (MIREA). 119454, Vernadsky Prospekt, 78, Moscow, Russia.
The article suggests methods of organizing data structures for complex organizational and technical fiscal systems. The basis of data organization is a data system with the properties of a complex system. The data system is organized in the ^ form of a hierarchical structure as a set of oriented acyclic graphs. The article reveals the content of a complex organizational and technical _ fiscal system. The article proves that the core of the _ fiscal system is the address register. The basis of the address register is the database. It is shown that the quality of the information system is determined by the quality ofprocessing and the quality of the data organization. The proposed method of organizing data solves the problem of not storing data and data processing tasks.
Keywords: fiscal system, complex organizational and technical fiscal system, system quality, data organization, oriented acyclic graphs, SQL
