• Начало

• Hare.ru @ дикое место
  • Лирика
  • Политика
  • Хай-тек
  • Синема
  • Лирика 2
• Hare.ru @ коллективный разум
  • Бухгалтерия и прочий учёт
  • Концептуальные работы
  • Полезные технологии
  • Собственные руки TM
• О проекте
• Информация
  • Реклама
  • Телеканал Россия 1 на компьютере

Концептуальные работы

Все статьи раздела

От V7 к V8. Обсуждение концепций структур данных. Иерархия кортежей.

Дмитрий Малюгин (где-то в 2001)

Как органично включить иерархию справочников в платформу? Возможно ли это без нарушения основополагающего принципа, что все агрегатные объекты являются наследниками объекта ТД? Или все же иерархия и таблицы – две вещи несовместные?

Начнем с того, что разумным и несложным в реализации является допущение наличия нескольких иерархий у одного справочника. Например, если пользователь желает иметь возможность поддерживать иерархию товаров с одной стороны по поставщикам, а с другой – по видам товаров, то почему бы не позволить ему сделать это? Естественно, при этом становится очевидным, что хранение элементов-групп справочников должно быть организовано в отдельной таблице – для каждой иерархии своя таблица (отдельный класс – Таблица Поддержки Иерархии) и свои "групповые" реквизиты. Также становится очевидным, что редактирование элемента иерархического справочника удобнее вести в диалоговой форме элемента, а не в списке.

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

Кстати, пригодилась бы и поддержка иерархий (групп) для документов. Для некоторых типов документов возможность их "раскладки по папкам" была бы полезной.

Теперь о том, как проецировать группы кортежей в ТД. Предположим, что имеем ТД, где значениями одной из колонок являются ссылки на кортежи какого-либо типа. В эту ТД необходимо добавить учет определенной иерархии данных кортежей. В V7, как известно, элементы-группы в таблице значений помещаются в той же колонке, что и обычные элементы справочника. Является ли данное решение приемлемым? На наш взгляд, нет.

Таким "группированием" неудобно пользоваться – прежде всего потому, что в одной колонке смешаны значения разных типов. Но отводить под каждый уровень иерархии отдельную колонку тоже неразумно – тем более что количество таких уровней заранее неизвестно. Следовательно, остается единственный вариант: все элементы-группы помещаются в одной, но отдельной от простых элементов колонке. Причем ТД сгруппирована по данной колонке.

Алгоритм формирования такой колонки будет следующим:

• На первом шаге исходная ТД группируется "вверх" по реквизиту элементов "Родитель". Это обычная группировка, при определении которой могут быть указаны также колонки с какими-либо итогами.
• На втором шаге перебираются кортежи получившейся таблицы-владельца, и для каждого элемента-группы в таблицу добавляются кортежи со значениями всех его родителей (значения итоговых колонок копируются).
• На третьем шаге производится свертка кортежей-групп и их упорядочивание обычным последовательным обходом (разворотом) всех ветвей дерева, начиная с верхнего.

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

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

Поясним сказанное на примере. Пусть мы имеем некий набор элементов класса ABCD с определенной иерархией Hier1 и некую ТД с итогами для элементов ABCD:

Сгруппируем последовательно ТД2 по группам Hier1 элементов ABCD с учетом итогов по NUM:

Исходная ТД2 получает идентификатор ТД2.Hier1 (или подобный) и становится подчиненной ТД2. Отметим, что для элементов-групп итоги по суммируемым колонкам подчиненных им таблиц могут не совпадать (быть меньше) с итогами, записанными в таблице-владельце (элемент s в ТД2).

Таким образом, мы кратко обсудили "разумные" подходы к организации поддержки иерархий кортежей в платформе, рассмотрели взаимодействие понятий Иерархия и Группировка ТД. Следующий интересный момент в V7 – это поддержка динамичности кортежей, хранение истории атрибутов справочников, состояния регистров.

Попытаемся нащупать общий подход к проблемам на основе понятия Функциональная зависимость (ФЗ).

Резюме.

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

Партнеры: