Дерево изделий с контролем узлов и деталей

[sergey-911]

Доброго времени суток уважаемые.
Формирую дерево изделий для отображения конструкторской спецификации. В дереве отображаются КОИ (конструкторские обозначения изделий) в виде сборок, подсборок, деталей. Дерево вывести не проблема. Для этого формирую в MS SQL 2005 таблицу Koi с полями:
ID_Koi (int) - первичный ключ;
ID_Parent (int) – внешний ключ;
Koi – наименование КОИ.
Заполним таблицу начальными данными:
-----------------------------------------------------------------
ID_Koi | ID_Parent | Koi
-----------------------------------------------------------------
1 | NULL | КОИ1
-----------------------------------------------------------------
2 | 1 | КОИ2
-----------------------------------------------------------------
3 | 2 | КОИ3
-----------------------------------------------------------------
4 | 3 | КОИ4
-----------------------------------------------------------------
5 | 3 | КОИ5
-----------------------------------------------------------------
6 | NULL | КОИ6
-----------------------------------------------------------------
7 | 6 | КОИ7
-----------------------------------------------------------------
Формируем дерево в TreeView приложения
+--КОИ1
+--КОИ2
+КОИ3
--КОИ4
--КОИ5
+--КОИ6
--КОИ7

Весь гемор возникает при отслеживании добавления (редактирования, удаления) изделий, подсборок. Так, например, при добавлении в изделие КОИ7 подсборки КОИ2, изделие КОИ7 само становится подсборкой, которое включает не только КОИ2, но и КОИ3, КОИ4 и КОИ5, т.к. КОИ2 – это подсборка, которая включает подсборку КОИ3 и изделия КОИ4 и КОИ5. Этого требует логика поставленной задачи (каждое изделие, подсборка и сборка в дереве изделий меняется один раз, в одном месте, в остальных – должно меняться самостоятельно).

В данном случае в таблицу должны добавиться записи:
-----------------------------------------------------------------
ID_Koi | ID_Parent | Koi
-----------------------------------------------------------------
8 | 6 | КОИ2
-----------------------------------------------------------------
9 | 8 | КОИ3
-----------------------------------------------------------------
10 | 9 | КОИ4
-----------------------------------------------------------------
11 | 9 | КОИ5
-----------------------------------------------------------------
вместо:
-----------------------------------------------------------------
ID_Koi | ID_Parent | Koi
-----------------------------------------------------------------
8 | 6 | КОИ2
-----------------------------------------------------------------
Получим новое дерево в TreeView приложения
+--КОИ1
+--КОИ2
+КОИ3
--КОИ4
--КОИ5
+--КОИ6
+--КОИ7
+--КОИ2
+КОИ3
--КОИ4
--КОИ5

Так же обстоит дело с редактированием подсборок и деталей. Например, при изменении названия КОИ 2 на КОИ8, должны измениться уже 2-е записи (одна в подсборке КОИ1, другая в подсборке КОИ7).
Тоже должно происходить и с удалением – удаляем изделие(сборку, подсборку) в одном месте дерева, а изделие (сборка, подсборка) должна удалиться во всех местах дерева.

Как реализовать такую логику в дереве изделий?

[Debugger]

Не совсем понятен вопрос. Отслеживание редактирование листвьюшника? Или обновление базы после редактирования приложения?
Кстати, дерево у тебя какое-то неправильное.

+--КОИ1
+--КОИ2
+КОИ3
--КОИ4
--КОИ5
+--КОИ6
--КОИ7

1 | NULL | КОИ1
2 | 1 | КОИ2
3 | 2 | КОИ3
4 | 3 | КОИ4
5 | 3 | КОИ5
6 | NULL | КОИ6
7 | 6 | КОИ7

КОИ1
-КОИ2
--КОИ3
---КОИ4
---КОИ5
КОИ6
-КОИ7

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

Эмм... Судя по базе ты иммешь дело с деревом. У каждого элемента дерева (в твоем случае) максимум 1 предок. Такое дерево можно представить в листвьюшнике так, чтобы каждый элемент повторялся один раз. И при его удалении ничего дополнительного удалять не надо было.

[sergey-911]

Не совсем понятен вопрос. Отслеживание редактирование листвьюшника? Или обновление базы после редактирования приложения?

Спасибо Debugger.
Почему вопрос не понятен? Приложение клиент-серверное. Следовательно, все, что изменяется в приложении, должно меняться и в БД, и наоборот. Редактировать пользователи будут в специальной форме, а не в TreeView. После этого будет происходить обновление БД и дерева изделий. На мой взгляд – все логично.
Хочу узнать, какая структура должна быть у БД, чтобы реализовать вышесказанное? И как реализовать такое обновление (запросы, процедуры...)?

Кстати, дерево у тебя какое-то неправильное.

Почему неправильное?

Эмм... Судя по базе ты иммешь дело с деревом. У каждого элемента дерева (в твоем случае) максимум 1 предок.

Логично Debugger, согласен. Но, этот предок может входить и в другие узлы дерева.

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

Можно поподробнее? Если представить в виде таблицы - то не совсем то, что нужно. Нужно в виде дерева (TreeView).

[FireFenix]

Я работал с базой изделей и сборок, если тебе нужны связи, сделай 3 таблицы (как минмум для связей)

1) Таблица object с полями id, name
2) Таблица links с полями id, id_link, id_item
3) Таблица items с полями id, name

суть в том что в links храняться ссылки на items [id_item], и привязка осуществляется по id_link, при желании можно дабвить разнообразие привязки к большему количеству таблиц, прикрутив 2 столбца типа ссылок

при заполнении тривиева начинается с object запросом SELECT * FROM object в цикле делаешь TreeView.Nodes.Add(Key,Text).
Потом внутри цикла рекурсивно считываешь все связи типа SELECT * FROM links LEFT JOIN items ON itens.id=links.id_item WHER id_link='ссылка на родителя связи", передавая Node = TreeView.Node(i) можно спокойно делать хоть до бесконечности ветвей и добавляя их в тривиев Node.Nodes.Add(Key, Text)

Для отслеживания сборка или деталь это, возможно либо модифицировать ключ элемента, либо задавать картинками

P.S. запросы типа для MySQL, для других бд могут быть другие

[Debugger]

1) Таблица object с полями id, name
...
3) Таблица items с полями id, name

Гхм. Не сосем понятно.
Вообще автор правильно указал структуру в начале топика.
1) Загружаешь все (или почти все...) из базы.
2) Запускаешь рекурсию (надеюсь, разберешься?) для добавления всех нодов с ID_Parent = NULL. На псевдокоде (чудо-код, но, думаю, разберешься):

Код: Выделить всё

Call Recurs("Null",ListView.AddNode("База"))
...
Sub Recurs(s,ParentNode)
--For c=0 to Base.CountRecords
----If Base.ID_Parent(c)=s then
-------Recurs(c, ParentNode.AddSubNode(Base.Koi(c)))
----End If
--Next
End Sub

[sergey-911]

Я работал с базой изделей и сборок, если тебе нужны связи, сделай 3 таблицы (как минмум для связей)

1) Таблица object с полями id, name
2) Таблица links с полями id, id_link, id_item
3) Таблица items с полями id, name

суть в том что в links храняться ссылки на items [id_item], и привязка осуществляется по id_link, при желании можно дабвить разнообразие привязки к большему количеству таблиц, прикрутив 2 столбца типа ссылок

Спасибо FireFenix, но я ничего не понял.
Объясни популярно, зачем 3 таблицы в БД? Назночение каждой из них я не догнал. Как это может помочь контролировать узлы дерева? Я так понимаю, в таблице Object ты хранишь родителей самого верхнего уровня (в моем случае - это те изделия, у которых Id_Parent = NULL). Что в остальных двух (более детально, если можно).


Все дерево я заполняю следующей процедурой:

Код: Выделить всё

    Private Sub LoadTreeViewAll()
        'Отображение всех вервей из таблицы TREE
        Dim Query As String
        Query = "SELECT ID_KOI, ID_PARENT, KOI"
        Query = Query & " FROM KOI"
        'Выполнение запроса
        Using Command As System.Data.Common.DbCommand = Provider.CreateCommand()
            Connection.Close()
            Connection.Open()
            Command.Connection = Connection
            Command.CommandText = Query
            Using Reader As System.Data.Common.DbDataReader = _
            Command.ExecuteReader()
                'Вывод результатов
                TreeView1.Nodes.Clear()
                Dim FindedNodes(0) As TreeNode
                'Настройка TreeView
                TreeView1.ShowPlusMinus = True
                'Заполнение TreeView
                Dim ID As String = ""
                Dim ParentID As String = ""
                Dim KOI As String = ""
                Do
                    While Reader.Read()
                        ID = Reader.Item(0).ToString
                        ParentID = Reader.Item(1).ToString
                        KOI = Reader.Item(2).ToString
                        'Добавление в дерево
                        If ParentID Is String.Empty Then
                            'Parent
                            TreeView1.Nodes.Add(ID, KOI).Tag = ID
                        Else
                            'Children
                            FindedNodes = TreeView1.Nodes.Find(ParentID, True)
                            FindedNodes(0).Nodes.Add(ID, KOI).Tag = ID
                        End If
                    End While
                Loop While Reader.NextResult()
                TreeView1.EndUpdate()
                TreeView1.ExpandAll()
            End Using
        End Using
    End Sub


На подключение не обращайте внимания, реализованно фабрикой подключений.
Отдельные ветки заполняю путем рекурсивных запросов (Взял отсюда, слегка доработал).

[sergey-911]

1) Загружаешь все (или почти все...) из базы.
2) Запускаешь рекурсию (надеюсь, разберешься?) для добавления всех нодов с ID_Parent = NULL. На псевдокоде (чудо-код, но, думаю, разберешься):
[code]Call Recurs("Null",ListView.AddNode("База"))
...
Sub Recurs(s,ParentNode)
--For c=0 to Base.CountRecords
----If Base.ID_Parent(c)=s then
-------Recurs(c, ParentNode.AddSubNode(Base.Koi(c)))
----End If
--Next
End Sub

Спасибо Debugger. Я так понимаю, процедура Recurs должна вывести всех родителей, у которых Id_Parent = NULL. Что это даст? Возможно ошибаюсь, поясни плиз.

[FireFenix]

1) Таблица object с полями id, name
...
3) Таблица items с полями id, name

Гхм. Не сосем понятно.
Вообще автор правильно указал структуру в начале топика.

ну я описал как я делал, ибо как правило база данных изделий, сборок и деталий не ограничивается хранением наименований

Спасибо FireFenix, но я ничего не понял.
Объясни популярно, зачем 3 таблицы в БД? Назночение каждой из них я не догнал. Как это может помочь контролировать узлы дерева? Я так понимаю, в таблице Object ты хранишь родителей самого верхнего уровня (в моем случае - это те изделия, у которых Id_Parent = NULL). Что в остальных двух (более детально, если можно). ops

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

Если тебе ненужны большие связи, то можно оставить 1 таблицу

тогда берёшь тривиев и создаёшь рекурсию для обработки связей элементов, предположим, что id_parent = 0 это знеачит что нет связи с другими обьектами, начинаем заносить в цикле

id_parent = 0
Рекурсия (Id_parent as integer, node as treenode)

Код: Выделить всё

запрос "SELECT * FROM table WHER id_parent=" & id_parent //получаем данные id_koi, id_parent, id_type, koi

Цикл получения данных типа Data.Read

if node is nothing then
добавление treeview.nodes.add(данные koi из запроса)
node = treeview.nodes(teeview.nodes.count - 1)
else
добавление node.nodes.add(данные koi из запроса)
node = nodes.lastnode
end if

Конец цикла

вызываем рекусрию (данные id_parent из запроса, node.lastnode)
Конец рекурсии

или как описал Debugger

[sergey-911]

Извини FireFenix. Не могу уловить смысла. Дай плиз пример, или опиши подробней. Чего мы добьемся, применив 3-и таблицы, каковы будут их поля...

На данный момент у меня засада в следующем:
1) Пользователь к изделию Изделие1 добавляет другое Изделие2 (формируя ветвь). Если добавляется изделие-сборка, то в Изделие1 должна войти именно сборка Изделие2, а не только это конкретное изделие.
2) Мало того, во всех местах БД, где встречается Изделие1, должна появиться данная сборка Изделие2.
3) При отображении пользователем сборки Изделие1, должна отобразиться одна ветвь, а не столько, сколько их встречаются в БД.

Короче, в конструкторской спецификации КОИ в данном случае это изделие или деталь. К примеру, Изделие2 - это электрический Двигатель1, который можно отобразить в виде различных винтиков, шпунтиков, ротора и т.п. Соответственно, это Изделие2 можно отобразить в виде ветви дерева, состоящие из других входящих деталей (винтиков, шпунтиков, ротора и т.п.). Допустим, мы заводим новое изделие - вентилятор (Изделие3), содержащий этот двигатель. В этом случае, пользователь заводит Изделие3 в него добавляет Изделие2, и у него сразу (т.к. этот электрический двигатель уже есть в БД) в Изделии3 отображается ветвь Изделие2, отрожающая все винтики, шпунтики, ротор и т.п., все, из чего состоит этот двигатель (Изделие2). Если конструктор решит внести изменения в этот двигатель, то он отображает Изделие2 в виде дерева, меняет в нем что-либо, при этом, изменения сразу должны произойти и в Изделии3 - вентиляторе. Везде, где встречается Изделие2.

[Alec]

К примеру, Изделие2 - это электрический Двигатель1, который можно отобразить в виде различных винтиков, шпунтиков, ротора и т.п. Соответственно, это Изделие2 можно отобразить в виде ветви дерева, состоящие из других входящих деталей (винтиков, шпунтиков, ротора и т.п.). Допустим, мы заводим новое изделие - вентилятор (Изделие3), содержащий этот двигатель. В этом случае, пользователь заводит Изделие3 в него добавляет Изделие2, и у него сразу (т.к. этот электрический двигатель уже есть в БД) в Изделии3 отображается ветвь Изделие2, отрожающая все винтики, шпунтики, ротор и т.п., все, из чего состоит этот двигатель (Изделие2). Если конструктор решит внести изменения в этот двигатель, то он отображает Изделие2 в виде дерева, меняет в нем что-либо, при этом, изменения сразу должны произойти и в Изделии3 - вентиляторе. Везде, где встречается Изделие2.

Я правильно понял, что еще есть Изделие4? Например...(блин, а где еще можно воткнуть вентилятор-то )...пусть это будет "суперкулер".
Тогда:

Код: Выделить всё

Изделие3 'вентилятор
  Изделие2 ' двигатель
    ИзделиеN1' корпус
    ИзделиеN2' винтик
    ...
    ИзделиеNN' шпунтик
Изделие4 'суперкулер
  Изделие2 ' двигатель
    ИзделиеN1' корпус
    ИзделиеN2' винтик
    ...
    ИзделиеNN' шпунтик


и при изменении "винтика" на "болтик" в Изделии2 должно быть:

Код: Выделить всё

Изделие3 'вентилятор
  Изделие2 ' двигатель(модифицированный)
    ИзделиеN1' корпус
    ИзделиеN2.1' болтик
    ...
    ИзделиеNN' шпунтик
Изделие4 'суперкулер
  Изделие2 ' двигатель(модифицированный)
    ИзделиеN1' корпус
    ИзделиеN2.1' болтик
    ...
    ИзделиеNN' шпунтик


Так?

PS. To moders: .Net?

[sergey-911]

Я правильно понял, что еще есть Изделие4? Например...(блин, а где еще можно воткнуть вентилятор-то )...пусть это будет "суперкулер".
Тогда:

Код: Выделить всё

Изделие3 'вентилятор
  Изделие2 ' двигатель
    ИзделиеN1' корпус
    ИзделиеN2' винтик
    ...
    ИзделиеNN' шпунтик
Изделие4 'суперкулер
  Изделие2 ' двигатель
    ИзделиеN1' корпус
    ИзделиеN2' винтик
    ...
    ИзделиеNN' шпунтик


и при изменении "винтика" на "болтик" в Изделии2 должно быть:

Код: Выделить всё

Изделие3 'вентилятор
  Изделие2 ' двигатель(модифицированный)
    ИзделиеN1' корпус
    ИзделиеN2.1' болтик
    ...
    ИзделиеNN' шпунтик
Изделие4 'суперкулер
  Изделие2 ' двигатель(модифицированный)
    ИзделиеN1' корпус
    ИзделиеN2.1' болтик
    ...
    ИзделиеNN' шпунтик


Так?

Так то оно так Alec, вот только, как такое реализовать?

[Debugger]

В таком случае тебе нужна другая структура. В примере у "болтика" больше, чем 1 родитель.

[Alec]

...вот только, как такое реализовать?

По-любому, как минимум две таблицы.
В одной хранится описание деталей и узлов, в другой - связи, в которой и указывается из каких деталей и узлов состоят узлы.
Покажу на "своем" примере (я к нему уже привык )
Таблица №1

Код: Выделить всё

ID   Name           Comment      ...
1   "Корпус"      "ИзделиеN1"
2   "Винтик"      "ИзделиеN2"
3   "Шпунтик"     "ИзделиеNN"
4   "Двигатель"   "Изделие2"
5   "Вентилятор"  "Изделие3"
6   "Суперкулер"  "Изделие4"
7   "Болтик"      "ИзделиеN2.1"


Таблица №2

Код: Выделить всё

ID_Parent  ID_Child  ‘Комментарии
   4          1      'Засунули в двигатель корпус
   4          2      'Засунули в двигатель винтик
   4          3      'Засунули в двигатель шпунтик
   5          4      'Засунули в вентилятор двигатель
   6          4      'Засунули в суперкулер двигатель


И, чтобы в двигателе винтик на болтик, при этом во всех изделиях с этим двигателем, нужно всего-навсего во второй строке второй таблице поменять ID_Child с 2 (винтик) на 7 (болтик).
Как то так, если на пальцах.

[Debugger]

А как потом строить... Тривиальный вопрос. Так же, как и описывали. Рекурсией перебираешь все узлы, начиная с ID_Parent=Null. Только вот будет страшно, если вдруг появятся циклы.
А при изменении узла дерева... Сложно. Но если подумать, достаточно (при перетаскивании узлов дерева)
1) Узнать, какие именно узлы затронуло это изменение (Узел-родитель-старый и узел-родитель-новый).
2) Поменять связи.
3) Перестроить таблицу
Если у тебя все написано аккуратно, то все будет работать.
Сразу говорю - делал нечно подобное. Обрати внимание на перетаскивание узла к своим же детям.

[iGrok]

Прочитал первый пост. Построил себе схемку. Подумал. Понял, как и что нужно сделать. Начал писать пост, и увидел пост от Alec.
Собственно, этот вариант - действительно то, что нужно.

Только вот будет страшно, если вдруг появятся циклы.

А чтобы они не появились и нужно при перетаскивании проверять, чтобы не попасть в "себя же". Т.е. в другую копию себя, или в любого из своих потомков. И при удалении сносить из таблицы связей все записи с ID_Child = ElementId. Ну и плюс сделать процедурку, проверяющую целостность ссылок, а при построении дерева при добавлении потомка проверять путь к корню (fullpath) на предмет существования этого потомка в кач-ве родителя.

[FireFenix]

1) Нужно определиться что вы в конечном счёте хотите.... ибо чем больше составных элементов - тем сложнее логика
2) Все будущие элементы нужно разбить по таблицам или присвоить типы для работы как с БД так и с деревом
3) Если некоторые элементы входят в другие элементы - правильнее создать ещё таблицу связей
4) И только исходя из наличия полной информации и сформированной в БД - можно начинать программировать

[iGrok]

2FireFenix:
Ты, кажется, всё-таки не в теме. Элементов может быть любое кол-во. С любым уровнем вложенности. И нужно всего две таблицы. И кода для реализации такой логики там минимум.

[FireFenix]

2FireFenix:
Ты, кажется, всё-таки не в теме. Элементов может быть любое кол-во. С любым уровнем вложенности. И нужно всего две таблицы. И кода для реализации такой логики там минимум.

Вначале была просто связь и вывод в Тривиев, теперь вложенность элементов.....
Если появятся ещё требования равно и возрастёт колчиство таблиц и связей между ними, поэтому вначале нада определиться, может вложенность это тока часть проблемы, которая отражается на связей элементов

[iGrok]

Вначале была просто связь и вывод в Тривиев, теперь вложенность элементов.....

Совет, как всегда, один. ВНИМАТЕЛЬНО перечитай первый пост.

А в остальном, конечно, согласен. Желательно для проектировки видеть всю картину сразу. Чтобы потом не переделывать код по 200 раз.

[sergey-911]

Кажется разобрался. Вы были как всегда правы, уважаемые форумчане. Действительно было нужно создать 2-е таблицы.
Вдруг кому пригодится, поэтому выкладываю решение проблемы.
1) Строим таблицу 1 (Nomenkl) - номенклатурный справочник с 2-я полями: иденификатором номенклатуры и названиями КОИ. Получаем:
---------------------------------
ID_Nomenkl | Koi
---------------------------------
1 | КОИ1
2 | КОИ2
3 | КОИ3
4 | КОИ4
5 | КОИ5
6 | КОИ6
7 | КОИ7
8 | КОИ8
9 | КОИ9
10 | КОИ10

2) Строим таблицу 2 (Specific) - таблица спецификаций, также содержащая 2-и поля: идентификатор номенклатуры (ID_Nomenkl) и идентификатор родителя (ID_Parent). Получаем:
---------------------------------
ID_Nomtnkl | ID_Parent
---------------------------------
1 | NULL
2 | 1
3 | 2
4 | 3
5 | 3
6 | 2
8 | NULL
9 | 8
2 | 9
10 | NULL
3 | 10
6 | 10

Результирующий запрос

Код: Выделить всё

WITH SP_CTE(ID_Nomenkl, ID_Parent, Koi) AS (SELECT     dbo.Specific.ID_Nomenkl, dbo.Specific.ID_Parent, dbo.Nomenkl.Koi
                                                                                                       FROM         dbo.Nomenkl INNER JOIN
                                                                                                                             dbo.Specific ON dbo.Nomenkl.ID_Nomenkl = dbo.Specific.ID_Nomenkl
                                                                                                       WHERE     (dbo.Specific.ID_Parent IS NULL)
                                                                                                       UNION ALL
                                                                                                       SELECT     Specific_1.ID_Nomenkl, Specific_1.ID_Parent, Nomenkl_1.Koi
                                                                                                       FROM         dbo.Nomenkl AS Nomenkl_1 INNER JOIN
                                                                                                                             dbo.Specific AS Specific_1 ON Nomenkl_1.ID_Nomenkl = Specific_1.ID_Nomenkl INNER JOIN
                                                                                                                             SP_CTE AS SP_CTE_2 ON SP_CTE_2.ID_Nomenkl = Specific_1.ID_Parent)
    SELECT     ID_Nomenkl, ID_Parent, Koi
     FROM         SP_CTE AS SP_CTE_1


позволит получить все необходимые данные (табл.3)

------------------------------------------------
ID_Nomenkl | ID_Parent | Koi
------------------------------------------------
1 | NULL | КОИ1
8 | NULL | КОИ8
10 | NULL | КОИ10
3 | 10 | КОИ3
6 | 10 | КОИ6
4 | 3 | КОИ4
5 | 3 | КОИ5
9 | 8 | КОИ9
2 | 9 | КОИ2
3 | 2 | КОИ3
6 | 2 | КОИ6
4 | 3 | КОИ4
5 | 3 | КОИ5
2 | 1 | КОИ2
3 | 2 | КОИ3
6 | 2 | КОИ6
4 | 3 | КОИ4
5 | 3 | КОИ5

для построения следующего дерева изделий:

+КОИ1
+-КОИ2
+--КОИ3
---КОИ4
---КОИ5
--КОИ6
+КОИ8
+-КОИ9
+--КОИ2
+---КОИ3
-----КОИ4
-----КОИ5
---КОИ6
+КОИ10
+-КОИ3
---КОИ4
---КОИ5
--Кои6

Из данного дерева видно, что результирующий запрос дополнил КОИ9 и КОИ10 данными, взятыми из КОИ1, что позволит избежать дублирования информации в таблицах номенклатура и спецификации!