Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft Access Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4   вперед  Ctrl      все
 Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 627
Компания выпускает ИЗДЕЛИЯ.
ИЗДЕЛИЕ состоит из большого числа компонентов - 10000-15000
Туда входят сборочные единицы(производства компании) - уровень вложенности до 10-12, детали и покупные изделия
Сборочные единицы 50% разрабатываются заново для каждого изделия, 50% берутся из ранее разработанных.
Сейчас организовано так
Таблица MAIN - сборочные единицы и детали в неструктурированном порядке - типа общий каталог
Таблица MAIN1 - описание конкретных ИЗДЕЛИЙ, где содержится точная информация о составе(дереве) ИЗДЕЛИЯ с его полной структурой.
связь по id компонента
Пока это было только для технологов - это работало норм. Сейчас планируется расширение функций и подключение к базе с таблицами конструкторского отдела. Они будут работать не в Аксе, а через VBA модуль в программе CATIA
ВОПРОС - Как организовать правильное (оптимальное) использование сборочных единиц разработанных ранее в новых проектах.
Примечание 1- уникальность состава сборочной единицы естественно обеспечивается, при изменении состава единицы хоть на 1 винт - это уже новая сборочная единица.
вижу 2 варианта
1) получать данные о структуре сборки из табл MAIN1(брать из какого-то уже выполненного изделия) и при необходимости копировать их в новый проект.
2) создать промежуточную таблицу, связанную с MAIN, и содержащую информацию о составе сборочных единиц
Примечание 2 Хранить точную структуру сборочных единиц в MAIN(общем каталоге) не представляется возможным, так как одна и та же сборочная единица может входить в десятки или сотни вышестоящих сборочных единиц с разным уровнем вложенности.
Вопрос локальный, я полагаю что не стоит идти сильно вглубь и вширь всей базы.....
5 сен 19, 09:43    [21964244]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ROI
Member

Откуда: г. Тюмень
Сообщений: 1793
Serg197311,

Однозначного ответа вы не получите.
Ту столько копий сломано на счет (сборок, уровней вложенности, EVA, древовидные структуры, Тенцер)
Поиском по всему сайту вы это несомненно найдете.
5 сен 19, 09:55    [21964257]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 627
ROI
Однозначного ответа вы не получите.

Да его и не существует наверное, однозначного-то...
Ну хоть какой-нибудь бы
5 сен 19, 09:58    [21964262]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 627
Пока склоняюсь к доп таблице со структурой сборок.....
В модуле технологов вообще ничего менять не придется, а поддерживать уникальность состава сборки так ИМХО проще и надежней....
5 сен 19, 10:09    [21964273]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Joss
Member

Откуда: г. Минск
Сообщений: 4950
Давным-давно работал на заводе и занимался этим делом.
Работал тогда инженером-конструктором в ОГК.
Есть такие вещи, как спецификации. На основе их разрабатываются производственные описи (ПО), ведомость покупных (ВП), ведомость документов (ВД) и ведомость метизов (крепежа) не помню обозначение, материалы 9так же не помню как обозначалась)
Помню была таблица наименований - код детали, сборки, метиза, покупного изделия и т.п - название (ну и дополнительные поля были: вес, материал и т.п)
Была таблица Состав : код сборки, код входящей детали, количество деталей.
Вот на основе этих таблиц Всё и получали. Очень полезная вещь. Шла как в отдел кооперации, так и в отдел комплектации, к технологам, мастерам в цеха, на склады и т.д.
Всё это было реализовано ещё на ЕС ЭВМ. Потом был разработана программа ЦКС (центральный комплектовочный склад) уже на СМ ЭВМ, куда загружали данные с ЕС. Всё работало чётко, пока не наступили 90-е. Потом ушёл с завода.
10 сен 19, 14:54    [21967789]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ldfanate
Member

Откуда:
Сообщений: 145
Serg197311
Компания выпускает ИЗДЕЛИЯ.
ИЗДЕЛИЕ состоит из большого числа компонентов - 10000-15000
Туда входят сборочные единицы(производства компании) - уровень вложенности до 10-12, детали и покупные изделия
Сборочные единицы 50% разрабатываются заново для каждого изделия, 50% берутся из ранее разработанных.
...
Примечание 2 Хранить точную структуру сборочных единиц в MAIN(общем каталоге) не представляется возможным, так как одна и та же сборочная единица может входить в десятки или сотни вышестоящих сборочных единиц с разным уровнем вложенности.
...


Так понимаю, чтото вроде версионирования документов придётся прикручивать - т.е. хранить всю структуру Сборочных единиц (СЕ), а не только дерево разузловки Изделий на всю глубину. Т.к. с Конструкторами наверняка появятся статусные схемы СЕ (рабочая редакция, на согласовании, прошла техсовет, утверждена и проч.).
10 сен 19, 15:54    [21967844]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
vmag
Member

Откуда: MP
Сообщений: 3289
Serg197311,

Как то всё сумбурно и не очень понятно, но вырисовывается алгоритм типа такого (низ/верх):
1. Анализируем существующие MAIN на предмет их достаточности для сборки нового проекта.
Если не хватает, создаем (возможно и на основе уже существующих) недостающие (новые) MAIN.
2. Ищем в MAIN1 наиболее подходящий старый проект с совпадением по MAIN по максимуму.
3. На его основе создаем новый MAIN1, выбрасываем из него ненужные MAIN и добавляем недостающие MAIN.

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

Мдя... какой вопрос, такой и ответ...
11 сен 19, 01:02    [21968177]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Лапух
Member

Откуда: Стойбище № 7
Сообщений: 926
Похоже тут главное понять, что ТС подразумевает под словечками - Уровень вложенности 10-12.
Хоть бы пукнул показал или поподробнее расписал как это выглядит в натуре,
Это 10-12 табличек для описания изделия, типа:
ВидИзделия
МаркаИзделия
МодельИзделия
РазмерИзделия
ФасонИзделия
ЦветИзделия
...
Далее что то не хватает воображения. Картинка с другого сайта.

или это всего типа 2 таблицы
Изделие
ПодчинённоеИзделие

Хотя довольно прикольно читать, как ТС не может внятно объяснить, а помогальщики не могут внятно подсказать.
Картинка с другого сайта.
11 сен 19, 06:00    [21968197]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 627
Лапух
Хотя довольно прикольно читать, как ТС не может внятно объяснить, а помогальщики не могут внятно подсказать.
Картинка с другого сайта.

Ну кому непонятно..... тот может и не отвечать
Вот Jossу, Idfanatу, vmagу точно все понятно и их ответы-советы все по существу)
11 сен 19, 06:35    [21968200]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Лапух
Member

Откуда: Стойбище № 7
Сообщений: 926
Serg197311
...и их ответы-советы все по существу...

И что же вы поняли существенного по существу?
Может я тоже так хочу, типа научиться видеть суть вещей, но чёй та не пойму чего вы поняли и чего вам подсказали существенного. Картинка с другого сайта.
11 сен 19, 06:57    [21968207]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ldfanate
Member

Откуда:
Сообщений: 145
Serg197311
Пока склоняюсь к доп таблице со структурой сборок.....
В модуле технологов вообще ничего менять не придется, а поддерживать уникальность состава сборки так ИМХО проще и надежней....


Так сделайте табличку со внутренней иерархией на любую глубину. Ближайший аналог SAP ТОРО - там любое сложное изделие (ну например турбоагрегат) разузловывается в виде дерева Технических мест и подчинённых им Единиц оборудования на любую глубину. Теоретически можно до последней гайки и шайбы - но такое не всегда нужно в эксплуатации, поэтому бывает разузловывают какраз до блочных заменяемых Изделий. А сбоку join-ом ваши нынешние таблицы. Избыточность только добавит надёжности, раз у вас там настолько сложное производство.
11 сен 19, 07:01    [21968210]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 627
Слегка сумбурно просто потому, что на данный момент в конторе нет четкой концепции документооборота, на данный момент ее просто никакой нет, и я собственно ее и создаю сейчас.
В планах стоит создавать электронную структуру изделий, хранить ее в базе данных и работать в дальнейшем с ней. Чертежи - что бумажные, что файлами .CATDrawing - совсем отдельная история, с кучей своих заморочек, и поэтому сейчас я рассматриваю только 3D модели сборок и самих деталей. Понимаю, что есть хороший выход - купить готовую PLM(PDM) и внедрить ее. На то что бы так не поступать есть множество причин, и они все не относятся к данной теме.
И собственно я колеблюсь между 2-мя направлениями
1) Изменения в сборке(единице номенклатуры с уникальным номером) не допускаются, при необходимости внести изменения создается новая сборка со своим номером(номером версии). Естественно присутствует процедура согласования/информирования всех необходимых лиц. После выполнения проекта все не вошедшие в него промежуточные версии сборки ( по желанию конструкторского отдела) выводятся из номенклатуры и файлы удаляются. История внесения изменений хранится в базе в текстовом виде.
В этом случае отдельная таблица со структурой сборок не нужна- можно найти структуру выбранной сборки в таблице с реализованными проектами и использовать ее. Еще плюс - на каждую сборку в номенклатуре обязательно есть свой единственный файл .CATProduct, точно ее описывающий, вся архитектура сборки хранится не только в базе, но и в этом файле.
Минус - даже если убрать или добавить 1 шайбу - требуется создать новый файл головной сборки. Но это легко реализуется программными методами из базы.
2) Изменения в сборке допускаются, структура основной сборки хранится в отдельной таблице - допустим SBORKI. Каждое изменение оформляется/согласовывается и хранится с указанием его применяемости. Именно так и был организован старый советский документооборот. Но так было сделано ИМХО потому, что основой был бумажный чертеж. Создать компьютерный документ, описывающий структуру сборки (типа файла .CATProduct) тогда просто не было возможности.
При этом у нас теряется уникальность файла сборки-нельзя открыть структуру из SBORKI и использовать ее. Надо обязательно поднимать всю историю изменений по всему дереву сборки. Избежать создания нового файла сборки все равно не получается, придется хранить и файл со структурой основной сборки, и файлы с реальной структурой, реализованной в проектах. Рано или поздно, когда изменений будет больше какого-т количества, все равно придется создать новую основную сборку и хранить и ее файл.
В общем я пока не определился.....
несколько дней назад думалось про создание доп таблицы SBORKI
на данный момент склоняюсь к варианту по п1, без нее....
Думаю-соображаю....
11 сен 19, 07:22    [21968214]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ПЕНСИОНЕРКА
Member

Откуда: Владимирская обл
Сообщений: 4603
Joss
Помню была таблица наименований - код детали/ сборки - название (ну и дополнительные поля были: вес, материал и т.п)
Была таблица Состав : код сборки, код входящей детали, количество деталей в сборке

работала точно с такой же схемой таблиц
+ материалы по детали
+ трудоемкость и расценки по детале-операции
+ мелкие справочники

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

и конечно поиск по переменному количеству полей по принципу ИЩУ ПО ТОМУ, ЧТО ЗНАЮ

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

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

поиск(фильтрация) работал по всех цехах и большинстве отделов автономно(общей сети тогда еще не было)
в отделах конструктора и технолога -по сети отделов
11 сен 19, 07:22    [21968216]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 627
Лапух

Может я тоже так хочу, типа научиться видеть суть вещей, но чёй та не пойму чего вы поняли и чего вам подсказали существенного. Картинка с другого сайта.

Толцытеся.... и отворится вам!
11 сен 19, 07:23    [21968217]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 627
ldfanate
Теоретически можно до последней гайки и шайбы - но такое не всегда нужно в эксплуатации, поэтому бывает разузловывают какраз до блочных заменяемых Изделий. А сбоку join-ом ваши нынешние таблицы. Избыточность только добавит надёжности, раз у вас там настолько сложное производство.

Сейчас, в табл MAIN1 как раз и хранится полная разузловка уже выпущенных изделий, до последней шайбы, реализованная по древесной структуре.
11 сен 19, 07:26    [21968218]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ПЕНСИОНЕРКА
Member

Откуда: Владимирская обл
Сообщений: 4603
Serg197311
Сейчас, в табл MAIN1 как раз и хранится полная разузловка уже выпущенных изделий, до последней шайбы, реализованная по древесной структуре

не очень поняла , как вы храните

мы хранили только уникальные строки по КУДА(код сборки)+ЧТО+СКОЛЬКО без привязки к изделию
остальное получали расчетно, например
- изделия+сборки+детали россыпью, т.е. перевод уже собранных единиц в назад детали с подсчетом задействованных деталей
- любой узел можно было пересчитать в ранге изделия и выдать по нему итоги по материалам, трудоемкости и расценку
- не трогая основное изделие, можно заменить ссылку на некую сборку(деталь) на вариант сборки/детали или подключить вместо собственной сборки покупную, которую не надо раскрывать для цехов(только для конструкторов)

это привело к тому, что таблица СОСТАВ была достаточно компактной, особенно учитывая то , что вариантов изделий было достаточно много, например одна из деталей входила в 800 сборок в более чем 200 изделий
11 сен 19, 08:45    [21968249]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 627
code OWN sernn codever qt
151 145 1 59 1
152 146 1 60 1
153 146 1 61 1

Типа так
Code - код текущей записи в MAIN1
OWN - код вышестоящей записи из MAIN1
sernn - код изделия
codever - код детали(сборки) из основного каталога MAIN
qt - количество
11 сен 19, 09:05    [21968256]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 627
ПЕНСИОНЕРКА
мы хранили только уникальные строки по КУДА(код сборки)+ЧТО+СКОЛЬКО без привязки к изделию
остальное получали расчетно, например

А вот этого уже не понял я.....
11 сен 19, 09:16    [21968264]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ПЕНСИОНЕРКА
Member

Откуда: Владимирская обл
Сообщений: 4603
Serg197311,

в вашем исполнении я не поняла, что есть количество
- количество в текущей сборке
- количество в изделии

пусть деталь 61 входит в 2 сборки одного изделия, а деталь 62 одна на 3 изделия
codeOWNsernncodeverqt
код текущей записи в MAIN1код вышестоящей записи из MAIN1код изделия- код детали(сборки) из основного каталога MAINколичество
1511451591
1521461601
1531461611
1541451611
1541451620,3333
11 сен 19, 09:22    [21968266]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 627
ПЕНСИОНЕРКА
Serg197311,

в вашем исполнении я не поняла, что есть количество
- количество в текущей сборке

11 сен 19, 09:40    [21968278]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ldfanate
Member

Откуда:
Сообщений: 145
автор
1) Изменения в сборке(единице номенклатуры с уникальным номером) не допускаются, при необходимости внести изменения создается новая сборка со своим номером(номером версии). Естественно присутствует процедура согласования/информирования всех необходимых лиц.


Такой вариант видится наиболее надёжным (и помоему наиболее методологически-близким к традиционному бумажному обороту конструкторской документации). Т.к. новое всегда пойдёт в БД как обособленный бизнес-объект, и не будет ломать логику использования уже ранее утверждённых бизнес-объектов.
К тому же, к бабке не ходи, потом начнут появляться связи между разными СЕ. Ну например, новая СЕ оказывается не полным аналогом прежней СЕ, а ограниченно применимом только для узкой номенклатуры Изделий в исполнении УХЛ (потому что гайку хромированную поменяли на гайку ржавую обыкновенную, и для субтропического исполнения оно не применимо, т.к. приржавеет после первого муссона :).
11 сен 19, 09:40    [21968279]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 627
ldfanate

Такой вариант видится наиболее надёжным :).

Вот и я пока к нему склоняюсь......
11 сен 19, 09:46    [21968285]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ПЕНСИОНЕРКА
Member

Откуда: Владимирская обл
Сообщений: 4603
Serg197311,

мы считали так



sernn \код изделия\1

строкаOWNcodeverqt сборкуна изделие
код текущей записи в MAIN1код вышестоящей записи из MAIN1- код детали(сборки) из основного каталога MAINприменяемостьколичество по сборкам
1450054022
146006410,50,5
1511455911*2=2
1521466011*0,5=0,5
1531466111*0,5=0,5
1541456111*2=2
154145620,33330,3333*2=0,6666


детальизделиеколичество всего
4012
4110,5
5911*2=2
6011*0,5=0,5
6111*0,5+1*2=2,5
620,33330,3333*2=0,6666
11 сен 19, 09:46    [21968286]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
Serg197311
Member

Откуда: Жуковский
Сообщений: 627
Я в таблице храню только количества деталей/сборок в вышестоящей сборке. Если надо посчитать винты такие-то в изделии или в сборке такой-то - это делаю функцией на vba.
11 сен 19, 09:50    [21968291]     Ответить | Цитировать Сообщить модератору
 Re: Архитектура базы  [new]
ПЕНСИОНЕРКА
Member

Откуда: Владимирская обл
Сообщений: 4603
ldfanate
например, новая СЕ оказывается не полным аналогом прежней СЕ, а ограниченно применимом только для узкой номенклатуры Изделий в исполнении УХЛ (потому что гайку хромированную поменяли на гайку ржавую обыкновенную, и для субтропического исполнения оно не применимо, т.к. приржавеет после первого муссона :).

вряд ли изделие в тропическом исполнении отличается только гайкой от базового -отличается и весь техпроцесс, а значит это другое изделие и другие составляющие и другой техпроцесс, даже в гравировке деталей добавляются символы
11 сен 19, 09:54    [21968295]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4   вперед  Ctrl      все
Все форумы / Microsoft Access Ответить