Всем Наилучшего Времени ДНЯ!

Долго собирался и вот решился обратиться к коллективному РАЗУМУ!

Дело в том, что имеющаяся база предназначена для обработки данных (документов) изготовления Изделий. Причём Изделия имеют разную структуру и сложность , более того Изделия изготавливаеются разными технологическими методами (Металлоизделия и Швейные).

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

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

Так вот в чем вопрос:
Можно ли создать, естественно на VBA, расчет в котором будет происходить выборка интересующих данных с указанием уровня входимости, но до признака отсутствия данных, например в таблице Состав Сборки в поле ДетальСборки – ‘.’, то же самое в поле ПодСборка – ‘.’, и при налиции еще одного показателя в количестве – 0.

с уважением Alex999kon

конечно, просто готовил наглядное изображение

еще пример структуры запроса

alvkalex999kon,

Я не понимаю почему нельзя выбирать все вхождения, пусть пустые поля где надо выдаёт?

конечно можно, но дело в том что сейчас в работе Изделия с уровнем сложности 58, т.е. мне необходимо построить как минимум 59 запросов на последовательную выборку интересующих данных, при этом, подобных выборок надо еще как минимум еще 5 раз по 59. А что делать если завтра уровень сложности будет 70, а через месяц 100, а потом....

так это я из создания запросов не вылезу.
Хотелось бы получить расчет, как я понимаю наверное цикл, где счетчик I - определяется как показатель сложности (кол-во уровней использованных в Изделии, или в группе Изделий, подлежащих обработке в данном расчет).
При этом при проведении расчетов сейчас расчет идет до максимально и известного уровня сложности, но например нужно выполнить расчет изделия с 5-м уровнем сложности, а вот расчеты пройдут аж до 59 уровня, потому что заранее определить сложность до расчета и рассчитывать только до нужного уровня проблематично, да через макросы только получилось сделать.

alvkalex999kon,

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

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

alvk,

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

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

NickBellalex999kon,

У вас действительно столько одинаковых по структуре таблиц? Разве удобно работать с ними так?

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

попробуйте сами у себя, и все увидите

Программист-Любитель,

попробую по порядку:
1.Сборочные изделия, собственно как и детали могут применяться в разных уровнях разных изделий, впрочем как и в одном но на разных уровнях, СБ могут быть как составляющими другого изготавливаемого изделия или его части, так и быть самостоятельными.
2. насчет ключей и индексов - очень прошу несколько попозже обсудим, сейчас для меня важнее - попробовать создать самостоятельный расчет (а не много-много запросов по уровням), прошу ключи и индексы отложим на потом, обязательно обсудим, но позже.
3. насчет индексирования самой информации в таблицах, если я правильно понял, уже отвечал, си. выше
4. а насчет "Про деревья готовых наработок на скл много. Если бы вы сдели на МС СКЛ + АДП было бы вааще все шоколадно." - позвольте ведь бинарное дерево сруктур изделия - уже заложено и уверен в другом варианте получится то же самое. Просто структура (схема) данных определена входной инфрмацией (ЕСКД, ЕСТД, ЕСПП) а не моими пожеланиями, тем более что переделывать бумажную документацию (см. выше) - этого никто делать не будет да и нельзя.

Ukraina,

как писал выше уровней сейчас 58, а будет и поболее.
поэтому 1-7 не актуально, важнее проработать вопрос о принципах и методах выборки данных, а не о структуре речь.
кстати заложенная структура - не нами разработанная вещь, а только вложенная в базу, если не веришь милости просим: ГОСТ 2.101, 2.711, и все-все учебники по машиностроению.
ранее пробовал как минимум 8 вариантов схемы базы, но с появлением нового уровня сложности, просто некуда было "ложить" данные и соответственно все переставало работать. Взял "умную" структуру из гостов и учебников и не поверишь все получилось и к вопросу о структуре базы уже не возвращаюсь боле 10 лет, и при этом любое Изделие вместе со всеми его наворотами и отличиями прекрасно ложаться в существующую структуру.

Ukraina,

"Не нужно дублировать одни и теже структуры. И далее с запросами легче будет, т.е. не бегать по циклу от 1 до 7, а простыой фильтрацией"

никакого дублирования информации нет и не может быть, можно вносить только уникальные данные в любой из разделов (Требования ГОСТ)

Ukraina,

"Не правильно сказал... Тогда объясни пожалуйста... Если Сборка 1...7 на схеме данных это одно и таже таблица, то с какой целью они так между собой связаны? Длинная цепочка одной таблицы... Можно посмотреть "реальные" данные как выглядят, хотябы в формате Эксель (в ковычки заключил, что истинные данные не нужны, хотел увидеть как можно представить данные в одной таблице с такими связями, для понимания сути). Чувствую, что много проще..."

к сожалению Ты не прав. Например посмотри на применение Детали "Винм М4х12" или "Шайба ф3" в любом автомобиле или в чем то похожем, он там очень на разных уровнях, а информация только в одном месте и один раз, а вот его использование да где угодно и как угодно. ио же самое и со сборочными единицами, затрудняюсь привести пример.

Программист-Любительalex999kon1.Сборочные изделия, собственно как и детали могут применяться в разных уровнях разных изделий, впрочем как и в одном но на разных уровнях, СБ могут быть как составляющими другого изготавливаемого изделия или его части, так и быть самостоятельными.
Да разумеется! Мне не нравится, что у вас таблицы НаименованиеИзделия и НаименованиеСборки дублируют друг друга. По сути, как я наисал - это одно и то же нечто, что можно разобать. Как только вы разнесли один и тот же "лес деревьев" на разные таблицы - получите геморрой по собиранию их обратно для однобразной обработки.

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

alex999kon4. а насчет "Про деревья готовых наработок на скл много. Если бы вы сдели на МС СКЛ + АДП было бы вааще все шоколадно." - позвольте ведь бинарное дерево сруктур изделия - уже заложено и уверен в другом варианте получится то же самое. Просто структура (схема) данных определена входной инфрмацией (ЕСКД, ЕСТД, ЕСПП) а не моими пожеланиями, тем более что переделывать бумажную документацию (см. выше) - этого никто делать не будет да и нельзя.
Не смешивайте горькое с холодным. Процедуры обработки, в том чисте иерархичеких данных, писать на t-sql удобнее не порядок. В конечной итоге - форма на экране или бумажный отчет - будет то же самое. Но на связке МС СКЛ + АДП у вас уйдет в разы меньше меньше времени, код серверной части легко поддерживать, во многих случаях вообще не трогая клиента.

здесь абсолютно с Вами не согласен, никокого дублирования между Изделиями и Сборками нет. Это не может быть одно и тоже, по определению (ГОСТ 2.101).
кстати а чем по Вашему отличается например деталь "Винт М4х16" от Изделия "Винт М4х16", ответь пожалуйста.

Программист-Любитель,

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

Программист-Любитель,

насчет связки СКЛ+АДП не спорю, но структура то данных останется той же. А вот метод выборки их структуры (КУБА) данных никак не связан с использованными средствами, например ORACLE тому подтверждение.