Еще раз об иерархии

Здравствуйте, Дмитрий!

Меня очень заинтересовала Ваша статья про иерархические структуры в реляционных базах данных. Я занимаюсь разработкой системы, одной из частей которой является электронный вариант каталога деталей и узлов. Иерархическа структура для такого каталога является единственно возможной: изделие состоит из подсистем, подсистема – из агрегатов, агрегат – из узлов, узел – из деталей, деталь может включать в себя более мелкие детали (винты, гайки и т. п.). Я перебрал много вариантов организации такой иерархической структуры в виде реляционной базы данных; был у меня и тот, что рассмотрен в Вашей статье.

Но в моем случае есть некоторые особенности, не позволяющие воспользоватьс приведенной схемой без изменений:

1. Каждая деталь имеет ряд атрибутов, важнейшими из которых являютс наименование и обозначение (чертежный номер). Напр.:

• Соединение поворотное 3.56.1205.1045.00
• Кольцо 5127А-153
• Выбрать для отображения в TTreeView один из этих атрибутов нельзя: ни наименование без обозначения, ни обозначение без наименования не дают достаточной информации человеку, работающему с такой системой. Можно было бы объединить наименование и обозначение в одну строку, но при этом, из-за значительного разброса в длине строк, теряется наглядность.

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

В связи с этими особенностями более предпочтительной мне показалась следующая схема:

• Детали одного уровня отображаются вместе со своими атрибутами в компоненте TDBGrid. Такое представление аналогично Explorer Windows 95, работающему в режиме Таблица.
• При активизации одного из элементов происходит:
  • "проваливание" на более глубокий уровень, если активизируется узел, содержащая много деталей;
  • "распахивание" элемента , если активизируется деталь, содержаща крепеж.

• При повторной активизации "распахнутого" элемента он "запахивается" :-).
• Кстати, этот же принцип представления информации используется в бумажном оригинале каталога.

Подходящей структурой базы данных будет следующая:
Поле OWNER дает нам информацию для отображения деталей одного уровня, а PARENT содержит информацию о отношениях родитель-потомок.

Ситуация похожа на организацию пользовательского интерфейса в Delphi. Для реализации "распахивающихся" элементов можно применить фильтрацию записей на клиентской машине в сочетании с ведением списка распахнутых элементов данного уровня.

С уважением,
Мухачев Евгений.