Иерархический справочник и Axapta.

[Andrew_Lan]

Цитата:

Сообщение от domandr

Да 50 000 элементов много. А почему не должно? Очень даже может быть.

Число "50000" (если быть точным - 50625) здесь выступает всего лишь как некий абстрактный индикатор, число полученное математическим выражением, и не более того.
Конечно же, я ни коим образом не утверждаю, что справочник (любой) не может содержать более 50 тыс. элементов! Я просто говорю о том, что если справочник не удовлетворяет некоторым, довольно жёстким, правилам или условиям (перечислены в моём сообщении), то применять его в виде ИЕРАРХИЧЕСКОГО - проблема, нужен другой подход.

Удачи

[Andrew_Lan]

Цитата:

Сообщение от mazzy

Позволю себе не согласится только с одним пунктом.
Это rls - record level security.
.
иерархия для ограничения доступа на уровне записей тоже не нужна

Да, пожалуй, что так.

[domandr]

Цитата:

Сообщение от mazzy

Цитата:

Сообщение от domandr

А вот если взять ювелирную продукцию, так там каждое изделие - отдельная строка в накладной (со своим спец.номером). Тут, то как?

Это вовсе не значит, что для каждой строки надо заводить строчку в номенклатурах. Достаточно серийных номеров. Не так ли?

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

[Timofeev]

Цитата:

Сообщение от Andrew_Lan

РЕЗЮМЕ.
- Иерархический справочник должен быть НАСТРАИВАЕМЫЙ. Т.е. для разных пользователей он должен быть свой (см. п.1), и отражать только те данные и значения, с такой группировкой и в такой совокупности, которые позволены данному конкретному пользователю его полномочиями, мерой ответственности и компетентности.

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

[competitor]

Сергей, привожу ссылку на статью по той же теме, может быть будет полезна
http://rsdn.ru/?article/db/Hierarchy.xml

[mazzy]

Спасибо, Lexey.
Отличная ссылка.

[Dzemon]

Цитата:

Сообщение от Lexey

Сергей, привожу ссылку на статью по той же теме, может быть будет полезна
http://rsdn.ru/?article/db/Hierarchy.xml

Прочитал. Очень спорная статья. Особенно непонятно стремление получить уровень вложенности.

[mazzy]

Цитата:

Сообщение от Dzemon

Очень спорная статья.

в этом то и прелесть.

[Anais_imported]

Прочитала. Эх, умно, красиво... НО!
Можно до бесконечности ломать копья на тему "можно-нельзя" и "нужно-не нужно". Какие могут быть ограничения и чем череваты попытки реализовать.
Но проза жизни такова. Приходит к тебе юзер (ну, или консультант), который дальше своего интерфейса (то есть того, что он может увидеть и мышкой пощупать) не видит, и, что характерно, видеть не хочет и говорит:
"ХОЧУ!". Даешь иерахию! Ну надо!!!
Ты ему про реляции и иерархию, а он тебе: "А ты посмотри: вот тут сделали. Нет, ну как же красиво и удобно."
Зачем я все это пишу? А затем, что совсем недавно (точнее - 15 минут назад ) по левую руку от меня птицей феникс восстала из пепла "инновационная" мысль накрутить иерархию на справочник. На справочник аналитики.
То есть "иерархия" у нас была уже давно, сделанная аналогично "иерархии" в плане счетов: под аналитикой с типом "Заголовок", через третью структуру подвешены аналитики с типом "Значение". Но до сих пор эта роскошь использовалась только в нескольких отчетах (по "заголовочным" аналитикам собирались и печатались итоги). И вот, 15 минут назад была предпринята попытка сделать следующий шаг к загибанию Аксапты в бараний рог: в муках родилась ИДЕЯ выводить эут "иерархию" деревом. В lookup'овой форме для аналитики...
Мотивы? Да пожалуйста, целый вагон:
1. У нас (предприятия) много аналитик, юзеры в них путаются, когда не видят родительских уровней.
2. Юзеры заводят не ту аналитику, а потом так и разносят. А сторнирование - не полезно для системы /Ничего не придумываю, цитирую по консультанту по финансам/
3. Открывают модуль "Проекты" и тыкают пальцами: нет ну вот же! Красиво и удобно.

Многоуважаемы Mazzy, возможно, помнит выложенный мною пару месяцев назад на AxForum'е проект, в котором была реализована иерархия на форме Тех.Мест (для модуля ТОРО). Тогда это пропихнули под эгидой "наличие иерархии прописано в ТЗ". Сейчас в ТЗ ничего такого нет. Но ведь "аналитик так много, без иерерхии с ними так сложно...".

И что вот прикажете делать с такими "ситуациями"?!

(ЗЫ
Как-то сразу вспоминается анекдот "Дорогая! Ты не путай ситуацию с б...твом")

[mazzy]

у меня как раз реализовано предложение.
вся проблема в том, что изначально я хотел опубликовать набор проектов xpo, где пошагово разъяснено, как можно сделать иерархию правильно.

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

приношу свои извинения за задержку. просто сейчас страшная запарка...

[Dzemon]

Ох, попытаюсь в выходные вытащить свои деревянные наработки...

[mazzy]

Давай. Будет очень любопытно.

[Alks]

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

Для начала несколько тезисов:

1. Господство реляционных СУБД (СУРБД) в наше время для разработки деловых приложений бесспорно, так же как то, что Аксапта построена на СУРБД.
2. Так же бесспорно что СУРБД не является идеальным решением в технологиях хранения, обработки и анализа больших объемов информации, но забудем про это пока.
3. Из литературных источников о принципах СУРБД и реаляционной алгебры мы знаем что есть ряд задач, которые СУРБД не могут решать эффективно, в ряд этих задач попадает то что мы тут называем "древовидностью". Поэтому реализация древовидности в СУРБД бесспорно является редко когда практичной задачей - с этим я не спорю. Но давайте посмотрим ниже.

(Теперь собственно комментирование статей уважаемого Mazzy

Цитата:

...В свое время были развиты иерархические СУБД. Однако с появлением реляционных баз данных, иерархические СУБД были незаслуженно забыты...
...На просторах СНГ массовое распространение иерархических справочников в учетных системах и в ERP-системах началось с 1С...

Просто замечаение: Самое интересное, что несмотря на то что 1С работает с СУРБД, если внимательно приглядется к её метамодели данных очевидно становится что... модель справочников 1С представляет собой модель иерархической СУБД! Даже принципы построения запросов и навигации по этим справочникам аналогичны, если не ошибаюсь, моделям предложенным для навигации в иерархических СУБД. Кроме того у меня создаётся ощущение что концепция регистров в 1С подозрительно похожа на OLAP-кубы.
Т.о. 1С являет собой продукт, который использует СУРБД немного не так как предполагается для них.

Цитата:

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

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

Давайте привлечем немножко абстракции нам в помощь.
Постановка задачи такова:
1. имеется некоторые сущности, некоторое множество объектов (в нашем случае - строк в таблице), которые нужно подвергнуть категоризации/классификации.
2. Классифируем мы объекты по свойствам. Например - цвет, размер, модель, класс, ассортимент и т.д.
3. Некоторые свойства объектов образуют иерархическое подчинение ВНУТРИ СЕБЯ. Это важный момент. Мы должны понимать что иерархия иерархии рознь - есть иерархия МЕЖКЛАССОВАЯ и есть иерархия ВНУТРИКЛАССОВАЯ. Межклассовая иерархия (у машины есть 4 колеса) превосходно реализуюется в СУРБД связанными таблицами. Внутриклассовая (каталоги в современный файловых системах) - это уже тот вид иерархии вокруг которого разгорелся спор.
И тут уясним для себя важнейший момент:
Внутриклассовая древовидная иерархия существует только в пределах одного свойства объекта! Если вы строите дерево вокруг нескольких свойств объекта, вы поступаете грубо неверно (это верно так же если свойство одно, но недостаточно нормализовано и на самом деле содержит в себе несколько независимых)! В дальнейшем постараюсь прояснить этот момент как можно чётче. Большая часть проблем и неграмотного дизайна древовидных структур связано именно с этим моментом.
Вообще в идеале у справочника объектов должно быть ровно столько НЕЗАВИСИМЫХ древовидных классификаторов, сколько в нём есть полей иерархического свойства.
Рассмотрим тут пример из статьи:

Цитата:

...На первом уровне, как правило, представлены типы товаров, продукции и материалов, на втором уровне производители или бренды, на третьем уровне детализация по группам товаров и продукции, на четвертом уровне детализация по цветам или размерам, на пятом - по техническим характеристикам и т.д....

Нетрудно заметить что в этом примере нарушается тот принцип о котором я сказал - в древовидный классификатор намешана куча совершенно разных свойств объекта! Осюда и все проблемы, которые mazzy ниже совершенно справедливо обозначает. На самом деле это неправильный классификатор. Такие классификации можно выстраивать как дерево в пользовательском интерфейсе (!) но нельзя переносить их на структуру БД!
Остюда на самом деле и вытекает тезис mazzy о том что "иерархическое представление является удобным только для ОДНОГО пользователя". На самом деле это верно только для "неправильных иерархий" - для межклассовых иерархий - т.е. менеджер по закупкам хочет в корне иерархии видеть поле "производитель", но кладовщик хочет видеть в корне иерархии поле "склад". А ведь всё верно! Для них это действительно так, НО ТАКИЕ КЛАССИФИКАТОРЫ ДЕЙСТВИТЕЛЬНО НЕ НУЖНЫ И ЛЕГКО ЗАМЕНЯЮТСЯ ФИЛЬТРАМИ.

Примером правильной классификации является, например, классификация по ассортименту... АССОРТИМЕНТУ И ТОЛЬКО.
Пример из нашего классификатора:
Лакокрасочная продукция / Эмали / Эмали для наружних работ / Пено-фталиевые
В чём тут фокус? Фокус тут в том что уровни правильного классификатора НЕ ПЕРЕСЕКАЮТСЯ. Они не могут быть подменены один другим. Они не могут быть расчлелены на группу полей - внутри подгруппы Эмали не может быть таких же свойств, что в соседних группах.
(*То что я сейчас говорю является своеобразным "правилом нормализации" для древовидных классификаторов. Правило это как правило не может быть соблюдено в полно объеме - *).
Ниже mazzy приводит говорит о различии между иерархией и фильтрацией - ЭТО И ЕСТЬ ТО О ЧЁМ я говорю. Пример с яндексом еще раз подчёркивает это.
На самом деле вокруг нас огромное количество "правильных деревьев" - ассортимент, структурные подразделения чего либо, иерархия в ООП, иерархия оглавления в книгах и т.д. и т.п.

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

P.S.

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

[Alks]

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

"Ненормализованное дерево" - это дерево, которое строится на основе нескольких свойств объекта (либо одного ненормализованного поля, которое на самом деле содержит независимые данные внутри себя), которые находятся в иерархической взаимосвязи. Для таких деревьев как правило действует принцип "каждому нужно свой вид дерева". Такие деревья лучше всего организовывать только на уровне интерфейса пользователя, не ломая саму плоскую таблицу. Вообще если разобраться это не деревья, а просто тот или иной вид ГРУППИРОВКИ таблицы по нескольким её полям. Для таких деревьев характерно то, что их уровни можно менять местами - например Склад/Поставщик/Товар или Поставщик/Товар/Склад - оба варианта группировки возможны и наделены какой либо функциональностью (особенно в отчетах).

"Нормализованное дерево" - это дерево построенное исключительно в рамках одного свойства объекта. Такое свойство представляет собой некую неделимую иерархическую сущность и может выстраивать только один вид иерархии. Например Сырьё/Топливо/Бензин не может быть выстроено по другому - Топливо/Сырьё/Бензин или Бензин/Топливо/Сырьё не имеют смысла. Следовательно для таких иерархий действует правило "всем нужен только один вид дерева" - такие "правильны" деревья невозможно рационально представить как набор нескольких независимых полей и простая фильтрация (даже с масками) по ним затруднена, более того - само по себе такое дерево имеет вполне очерченный смысл НА КАЖДОМ УРОВНЕ СВОЕЙ ИЕРАРХИИ. Под этим я подразумеваю то, что пользователям полезно и имеет смысл работать не только с листями такого дерева (конечными узлами), но и с ветками. Каждый узел такого дерева может быть использован как укрупнение или наоборот - уточнение каких либо действий/запросов/анализа. Например проставление скидки 5% на все горючесмазочные материалы, но 10% на бензин, или перенос папки со всеми её подпапками в другое место на диске, или вывод суммарного оборота по кафельной плитке и т.д. и т.п.
Поэтому ИМХО, имеет смысл реализовать такое поле в виде настоящей древовидной таблицы.

[Alks]

P.S.

Предпоследним параграфом я хотел отметить что "правильное" дерево - это несомненно нечто большее чем просто фильтрация - это способ восприятия информации и способ управления ею.

За сим заканчиваю комментировать первую часть статьи.

[mazzy]

=A=L=X=, прежде всего, спасибо за обстоятельный комментарий.
Согласен, что как правило иерархии понимаются заказчиками и постановщиками неправильно, а следовательно неправильно и используются.

Пока читал, хотел спросить: "какие будут предложения?"
Потому увидел предлагаемый пример "Лакокрасочная продукция / Эмали / Эмали для наружних работ / Пено-фталиевые"

В этой иерархии признак "Для наружных работ" является межвидовым. Этот признак скорее всего будет повторяться в других группах.

Лакокрасочная продукция / Эмали / Эмали для наружних работ
Лакокрасочная продукция / Краски / Краски для наружних работ
Лакокрасочная продукция / Лаки / Лаки для наружних работ

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

Лакокрасочная продукция / Эмали / Эмали для наружних работ / Пено-фталиевые
Лакокрасочная продукция / Краски / Краски для наружних работ
Лакокрасочная продукция / Краски / Маслянные
Лакокрасочная продукция / Краски / Нитрокраски
Лакокрасочная продукция / Краски / Краски для рисования / Гуашь
Лакокрасочная продукция / Краски / Акварельные

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

Какие будут предложения?
Да, прежде всего отделить формат хранения и формат представления.
Что еще?

Да, очень интересный термин "нормальзованное/ненормализованное дерево". Поскольку вы об этом думали больше, то можно я спрошу?

Для нормализованного дерева действует только одно правило "Нормализованное дерево - это дерево построенное исключительно в рамках одного свойства объекта"? Может есть другие правила?

Бывает ли несколько степеней нормализованности деревьев?

[Alks]

Цитата:

Потому увидел предлагаемый пример "Лакокрасочная продукция / Эмали / Эмали для наружних работ / Пено-фталиевые"
В этой иерархии признак "Для наружных работ" является межвидовым. Этот признак скорее всего будет повторяться в других группах.

Поэтому я и написал ниже "(*То что я сейчас говорю является своеобразным "правилом нормализации" для древовидных классификаторов. Правило это как {и любое} правило {,как правило,} не может быть соблюдено в полно объеме - *)". Тут действительно трудно обойтись без обозначенных вами коллизий. Давайте присмотримся к ним повнимательнее:

Цитата:

Лакокрасочная продукция / Эмали / Эмали для наружних работ
Лакокрасочная продукция / Краски / Краски для наружних работ
Лакокрасочная продукция / Лаки / Лаки для наружних работ

Действительно (так и есть) у нас внедренный в классификатор признак "для наружних" работ присущ почти всей ветке "Лакокрасочной продукции". Казалось бы типичная денормализация, но ведь мы ничего (почти) с ней не можем поделать, ибо кроме этой ветки этот признак нигде больше не будет встречаться, следовательно выносить его в отдельное поле таблицы "ForOuterWork" - нерационально и ненужно для 99% остального справочника, следовательно эту ситуацию разрешить разбиением на отдельные поля и фильтрацией по ним - тоже затруднительно. Возможен вариант с выведением таких свойств из классификатора и введением некоторого строкового поля таблицы ExtraDescription, который будет заполнятся совершенно разными значениями в зависимости от того в какой ветке он будет находится. Мне такой вариант не нравится и имхо лучше иметь на 10% "ненормализованное дерево" (термин то состряпан мной еще вчера, так что не судите строго). Вообще в литературе такие ситуации ("ООП таблицы") предлагается делать специальным образом, но он тут неуместен и только безмерно усложнит ситуацию. Хотя.... кто знает... Тут еще имеет смысл посмотреть на всё глазами предполагаемых пользователей - а важен ли вообще этот момент для них? Например у нас есть разбиение групп ванн на подгруппы "чугунные", "стальные", "акриловые" - тоже так и просится сделать вместо этого разбиения у таблицы поле "материал", но опять же - не всем строкам таблицы это поле нужно, не у всех оно совпадает по возможному набору значений, да и по большому счёту пользователям это поле (сейчас) не нужно - это разбиение последнего уровня и дополнено чем то оно не может быть. Да и возьмём абстрактный пример "иерархического оглавления в книге" - хотя в каждом разделе первым подразделом всегда может быть раздел "Введение", это не является денормализацией - пользователю никогда не нужно получать из книги только введения.
На самом деле путешествуя по нашему дереву я нахожу более "страшные" моменты, когда лаки разбиты на "...внешние работы" и "...внутренние работы", а на уровне ниже каждая из этих веток разбита на "Водные" и "Полимерные". Вот это уже серьезный недочет, но согласитесь - хорошего, универасльного решения нет ни в "древовидном", ни в "плоском" подходе нет.

Цитата:

Да, прежде всего отделить формат хранения и формат представления.
Что еще?

Делать дерево. На самом деле я просто обратил внимание что читая вашу статью у читателя может возникнуть ощущение что любое дерево заведомо можно описать другими средствами - расчленяя его на группу несвязанных полей. И не сказано что на самом деле действительно существуют заковыристые внутриклассовые иерархии, которые ну никак нельзя уложить в СУРБД иначе чем древовидным подходом.
Действительно реализовавывать деревья в СУРБД - плохой тон. Действительно в аксапте нет встроенной поддержки древовидности.
Действительно нужно 10 раз подумать прежде чем нагружать SQL-сервер сериями из сотен рекурсивных запросов, НО
Желание клиента слишком часто действительно является законом.
Правильная древовидность может действительно помогать и упрощать решение многих задач.
На самом деле в аксапте и так есть куча мест где постоянно происходит КУЧА рекурсивных и не очень запросов, так что ответ на вопрос о том стоит ли оно того падение производительности не столь очевиден.

Цитата:

Для нормализованного дерева действует только одно правило "Нормализованное дерево - это дерево построенное исключительно в рамках одного свойства объекта"? Может есть другие правила?

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

Цитата:

Бывает ли несколько степеней нормализованности деревьев?

Наверное да. По хорошему над этим должны думать современные создатели СУБД.

[mazzy]

Цитата:

Сообщение от =A=L=X=

Цитата:

Лакокрасочная продукция / Эмали / Эмали для наружних работ
Лакокрасочная продукция / Краски / Краски для наружних работ
Лакокрасочная продукция / Лаки / Лаки для наружних работ

Действительно (так и есть) у нас внедренный в классификатор признак "для наружних" работ присущ почти всей ветке "Лакокрасочной продукции". Казалось бы типичная денормализация, но ведь мы ничего (почти) с ней не можем поделать, ибо кроме этой ветки этот признак нигде больше не будет встречаться, следовательно выносить его в отдельное поле таблицы "ForOuterWork" - нерационально и ненужно для 99% остального справочника

Доски / Горбыль /
Доски / Профильные / Для наружных работ
Доски / Профильные / Для мебели

[mazzy]

Цитата:

Сообщение от =A=L=X=

Цитата:

Да, прежде всего отделить формат хранения и формат представления.
Что еще?

Делать дерево. На самом деле я просто обратил внимание что читая вашу статью у читателя может возникнуть ощущение что любое дерево заведомо можно описать другими средствами - расчленяя его на группу несвязанных полей. И не сказано что на самом деле действительно существуют заковыристые внутриклассовые иерархии, которые ну никак нельзя уложить в СУРБД иначе чем древовидным подходом.

Сказано. Правда во второй части.

Пример - спецификации (BOM).
Узлы состоят из материалов и других узлов.

Спецификации - типичная иерархия.
Причем именно иерархия, а не граф. С циклами в спецификациях в обязательном порядке приходится бороться.

Причем спецификациям изначально присуща рекурсия.
Рекурся содержится в определении.
Причем именно бесконечная рекурсия.

Так что не любую иерархию можно описать несвязанными полями.
Просто в БОЛЬШИНСТВЕ случаев иерархию применяют совершенно неоправдано.

Еще раз спасибо за высказывания.
По большей части - с вами совершенно согласен.

[Alks]

Цитата:

Сообщение от mazzy

Цитата:

Сообщение от =A=L=X=

Цитата:

Лакокрасочная продукция / Эмали / Эмали для наружних работ
Лакокрасочная продукция / Краски / Краски для наружних работ
Лакокрасочная продукция / Лаки / Лаки для наружних работ

Действительно (так и есть) у нас внедренный в классификатор признак "для наружних" работ присущ почти всей ветке "Лакокрасочной продукции". Казалось бы типичная денормализация, но ведь мы ничего (почти) с ней не можем поделать, ибо кроме этой ветки этот признак нигде больше не будет встречаться, следовательно выносить его в отдельное поле таблицы "ForOuterWork" - нерационально и ненужно для 99% остального справочника

Доски / Горбыль /
Доски / Профильные / Для наружных работ
Доски / Профильные / Для мебели

Ну хорошо: ...ненужно для 95% остального справочника...