| Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
| Все форумы / Microsoft Access |
  |
||
| Топик располагается на нескольких страницах: [1] 2 3 вперед Ctrl→ все |
 Архитектура базы
|
|
|
Serg197311 Member Откуда: Жуковский Сообщений: 518 |
Компания выпускает ИЗДЕЛИЯ. ИЗДЕЛИЕ состоит из большого числа компонентов - 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: Архитектура базы
|
|
|
ROI Member Откуда: г. Тюмень Сообщений: 1784 |
Serg197311, Однозначного ответа вы не получите. Ту столько копий сломано на счет (сборок, уровней вложенности, EVA, древовидные структуры, Тенцер) Поиском по всему сайту вы это несомненно найдете. |
| 5 сен 19, 09:55 [21964257] Ответить | Цитировать Сообщить модератору | |
| Re: Архитектура базы
|
|||
|
Serg197311 Member Откуда: Жуковский Сообщений: 518 |
Да его и не существует наверное, однозначного-то... Ну хоть какой-нибудь бы 
|
||
| 5 сен 19, 09:58 [21964262] Ответить | Цитировать Сообщить модератору | |||
| Re: Архитектура базы
|
|
|
Serg197311 Member Откуда: Жуковский Сообщений: 518 |
Пока склоняюсь к доп таблице со структурой сборок..... В модуле технологов вообще ничего менять не придется, а поддерживать уникальность состава сборки так ИМХО проще и надежней.... |
| 5 сен 19, 10:09 [21964273] Ответить | Цитировать Сообщить модератору | |
| Re: Архитектура базы
|
|
|
Joss Member Откуда: г. Минск Сообщений: 4891 |
Давным-давно работал на заводе и занимался этим делом. Работал тогда инженером-конструктором в ОГК. Есть такие вещи, как спецификации. На основе их разрабатываются производственные описи (ПО), ведомость покупных (ВП), ведомость документов (ВД) и ведомость метизов (крепежа) не помню обозначение, материалы 9так же не помню как обозначалась) Помню была таблица наименований - код детали, сборки, метиза, покупного изделия и т.п - название (ну и дополнительные поля были: вес, материал и т.п) Была таблица Состав : код сборки, код входящей детали, количество деталей. Вот на основе этих таблиц Всё и получали. Очень полезная вещь. Шла как в отдел кооперации, так и в отдел комплектации, к технологам, мастерам в цеха, на склады и т.д. Всё это было реализовано ещё на ЕС ЭВМ. Потом был разработана программа ЦКС (центральный комплектовочный склад) уже на СМ ЭВМ, куда загружали данные с ЕС. Всё работало чётко, пока не наступили 90-е. Потом ушёл с завода. |
| 10 сен 19, 14:54 [21967789] Ответить | Цитировать Сообщить модератору | |
| Re: Архитектура базы
|
|||
|
ldfanate Member Откуда: Сообщений: 129 |
Так понимаю, чтото вроде версионирования документов придётся прикручивать - т.е. хранить всю структуру Сборочных единиц (СЕ), а не только дерево разузловки Изделий на всю глубину. Т.к. с Конструкторами наверняка появятся статусные схемы СЕ (рабочая редакция, на согласовании, прошла техсовет, утверждена и проч.). |
||
| 10 сен 19, 15:54 [21967844] Ответить | Цитировать Сообщить модератору | |||
| Re: Архитектура базы
|
|
|
vmag Member Откуда: MP Сообщений: 3235 |
Serg197311, Как то всё сумбурно и не очень понятно, но вырисовывается алгоритм типа такого (низ/верх): 1. Анализируем существующие MAIN на предмет их достаточности для сборки нового проекта. Если не хватает, создаем (возможно и на основе уже существующих) недостающие (новые) MAIN. 2. Ищем в MAIN1 наиболее подходящий старый проект с совпадением по MAIN по максимуму. 3. На его основе создаем новый MAIN1, выбрасываем из него ненужные MAIN и добавляем недостающие MAIN. Если уж новый проект совсем не похож на старые или есть возможность улучшить технологии, его можно собрать с нуля из MAIN, при условии что п.1 уже выполнен. Мдя... какой вопрос, такой и ответ... |
| 11 сен 19, 01:02 [21968177] Ответить | Цитировать Сообщить модератору | |
| Re: Архитектура базы
|
|
|
Лапух Member Откуда: Стойбище № 7 Сообщений: 880 |
Похоже тут главное понять, что ТС подразумевает под словечками - Уровень вложенности 10-12. Хоть бы Это 10-12 табличек для описания изделия, типа: ВидИзделия МаркаИзделия МодельИзделия РазмерИзделия ФасонИзделия ЦветИзделия ... Далее что то не хватает воображения.  или это всего типа 2 таблицы Изделие ПодчинённоеИзделие Хотя довольно прикольно читать, как ТС не может внятно объяснить, а помогальщики не могут внятно подсказать.
|
| 11 сен 19, 06:00 [21968197] Ответить | Цитировать Сообщить модератору | |
| Re: Архитектура базы
|
|||
|
Serg197311 Member Откуда: Жуковский Сообщений: 518 |
Ну кому непонятно..... тот может и не отвечать Вот Jossу, Idfanatу, vmagу точно все понятно и их ответы-советы все по существу )
|
||
| 11 сен 19, 06:35 [21968200] Ответить | Цитировать Сообщить модератору | |||
| Re: Архитектура базы
|
|||
|
Лапух Member Откуда: Стойбище № 7 Сообщений: 880 |
И что же вы поняли существенного по существу? Может я тоже так хочу, типа научиться видеть суть вещей, но чёй та не пойму чего вы поняли и чего вам подсказали существенного.
|
||
| 11 сен 19, 06:57 [21968207] Ответить | Цитировать Сообщить модератору | |||
| Re: Архитектура базы
|
|||
|
ldfanate Member Откуда: Сообщений: 129 |
Так сделайте табличку со внутренней иерархией на любую глубину. Ближайший аналог SAP ТОРО - там любое сложное изделие (ну например турбоагрегат) разузловывается в виде дерева Технических мест и подчинённых им Единиц оборудования на любую глубину. Теоретически можно до последней гайки и шайбы - но такое не всегда нужно в эксплуатации, поэтому бывает разузловывают какраз до блочных заменяемых Изделий. А сбоку join-ом ваши нынешние таблицы. Избыточность только добавит надёжности, раз у вас там настолько сложное производство. |
||
| 11 сен 19, 07:01 [21968210] Ответить | Цитировать Сообщить модератору | |||
| Re: Архитектура базы
|
|
|
Serg197311 Member Откуда: Жуковский Сообщений: 518 |
Слегка сумбурно просто потому, что на данный момент в конторе нет четкой концепции документооборота, на данный момент ее просто никакой нет, и я собственно ее и создаю сейчас. В планах стоит создавать электронную структуру изделий, хранить ее в базе данных и работать в дальнейшем с ней. Чертежи - что бумажные, что файлами .CATDrawing - совсем отдельная история, с кучей своих заморочек, и поэтому сейчас я рассматриваю только 3D модели сборок и самих деталей. Понимаю, что есть хороший выход - купить готовую PLM(PDM) и внедрить ее. На то что бы так не поступать есть множество причин, и они все не относятся к данной теме. И собственно я колеблюсь между 2-мя направлениями 1) Изменения в сборке(единице номенклатуры с уникальным номером) не допускаются, при необходимости внести изменения создается новая сборка со своим номером(номером версии). Естественно присутствует процедура согласования/информирования всех необходимых лиц. После выполнения проекта все не вошедшие в него промежуточные версии сборки ( по желанию конструкторского отдела) выводятся из номенклатуры и файлы удаляются. История внесения изменений хранится в базе в текстовом виде. В этом случае отдельная таблица со структурой сборок не нужна- можно найти структуру выбранной сборки в таблице с реализованными проектами и использовать ее. Еще плюс - на каждую сборку в номенклатуре обязательно есть свой единственный файл .CATProduct, точно ее описывающий, вся архитектура сборки хранится не только в базе, но и в этом файле. Минус - даже если убрать или добавить 1 шайбу - требуется создать новый файл головной сборки. Но это легко реализуется программными методами из базы. 2) Изменения в сборке допускаются, структура основной сборки хранится в отдельной таблице - допустим SBORKI. Каждое изменение оформляется/согласовывается и хранится с указанием его применяемости. Именно так и был организован старый советский документооборот. Но так было сделано ИМХО потому, что основой был бумажный чертеж. Создать компьютерный документ, описывающий структуру сборки (типа файла .CATProduct) тогда просто не было возможности. При этом у нас теряется уникальность файла сборки-нельзя открыть структуру из SBORKI и использовать ее. Надо обязательно поднимать всю историю изменений по всему дереву сборки. Избежать создания нового файла сборки все равно не получается, придется хранить и файл со структурой основной сборки, и файлы с реальной структурой, реализованной в проектах. Рано или поздно, когда изменений будет больше какого-т количества, все равно придется создать новую основную сборку и хранить и ее файл. В общем я пока не определился..... несколько дней назад думалось про создание доп таблицы SBORKI на данный момент склоняюсь к варианту по п1, без нее.... Думаю-соображаю.... |
| 11 сен 19, 07:22 [21968214] Ответить | Цитировать Сообщить модератору | |
| Re: Архитектура базы
|
|||
|
ПЕНСИОНЕРКА Member Откуда: Владимирская обл Сообщений: 4592 |
работала точно с такой же схемой таблиц + материалы по детали + трудоемкость и расценки по детале-операции + мелкие справочники на их основе расчетом получали состав изделия(код изделия, код детали, количество в изделии- деталь может входить в несколько сборок одного изделия) для оперативных расчетов по цеху+участок+изделие+... и конечно поиск по переменному количеству полей по принципу ИЩУ ПО ТОМУ, ЧТО ЗНАЮ например, это могли быть -кусочек гравировки -кусочек названия -цех -изделие -год и/или номер последнего изменения -сборка/деталь/покупное зацепившись за деталь далее видели -что входит в найденное, т.е. это сборка -куда она сама входит в качестве детали или подсборки поиск(фильтрация) работал по всех цехах и большинстве отделов автономно(общей сети тогда еще не было) в отделах конструктора и технолога -по сети отделов |
||
| 11 сен 19, 07:22 [21968216] Ответить | Цитировать Сообщить модератору | |||
| Re: Архитектура базы
|
|||
|
Serg197311 Member Откуда: Жуковский Сообщений: 518 |
Толцытеся.... и отворится вам! |
||
| 11 сен 19, 07:23 [21968217] Ответить | Цитировать Сообщить модератору | |||
| Re: Архитектура базы
|
|||
|
Serg197311 Member Откуда: Жуковский Сообщений: 518 |
Сейчас, в табл MAIN1 как раз и хранится полная разузловка уже выпущенных изделий, до последней шайбы, реализованная по древесной структуре. |
||
| 11 сен 19, 07:26 [21968218] Ответить | Цитировать Сообщить модератору | |||
| Re: Архитектура базы
|
|||
|
ПЕНСИОНЕРКА Member Откуда: Владимирская обл Сообщений: 4592 |
не очень поняла , как вы храните мы хранили только уникальные строки по КУДА(код сборки)+ЧТО+СКОЛЬКО без привязки к изделию остальное получали расчетно, например - изделия+сборки+детали россыпью, т.е. перевод уже собранных единиц в назад детали с подсчетом задействованных деталей - любой узел можно было пересчитать в ранге изделия и выдать по нему итоги по материалам, трудоемкости и расценку - не трогая основное изделие, можно заменить ссылку на некую сборку(деталь) на вариант сборки/детали или подключить вместо собственной сборки покупную, которую не надо раскрывать для цехов(только для конструкторов) это привело к тому, что таблица СОСТАВ была достаточно компактной, особенно учитывая то , что вариантов изделий было достаточно много, например одна из деталей входила в 800 сборок в более чем 200 изделий |
||
| 11 сен 19, 08:45 [21968249] Ответить | Цитировать Сообщить модератору | |||
| Re: Архитектура базы
|
|
|
Serg197311 Member Откуда: Жуковский Сообщений: 518 |
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: Архитектура базы
|
|||
|
Serg197311 Member Откуда: Жуковский Сообщений: 518 |
А вот этого уже не понял я..... |
||
| 11 сен 19, 09:16 [21968264] Ответить | Цитировать Сообщить модератору | |||
| Re: Архитектура базы
|
|||||||||||||||||||||||||||||||||||||
|
ПЕНСИОНЕРКА Member Откуда: Владимирская обл Сообщений: 4592 |
Serg197311, в вашем исполнении я не поняла, что есть количество - количество в текущей сборке - количество в изделии пусть деталь 61 входит в 2 сборки одного изделия, а деталь 62 одна на 3 изделия
|
||||||||||||||||||||||||||||||||||||
| 11 сен 19, 09:22 [21968266] Ответить | Цитировать Сообщить модератору | |||||||||||||||||||||||||||||||||||||
| Re: Архитектура базы
|
|||
|
Serg197311 Member Откуда: Жуковский Сообщений: 518 |
|
||
| 11 сен 19, 09:40 [21968278] Ответить | Цитировать Сообщить модератору | |||
| Re: Архитектура базы
|
|||
|
ldfanate Member Откуда: Сообщений: 129 |
Такой вариант видится наиболее надёжным (и помоему наиболее методологически-близким к традиционному бумажному обороту конструкторской документации). Т.к. новое всегда пойдёт в БД как обособленный бизнес-объект, и не будет ломать логику использования уже ранее утверждённых бизнес-объектов. К тому же, к бабке не ходи, потом начнут появляться связи между разными СЕ. Ну например, новая СЕ оказывается не полным аналогом прежней СЕ, а ограниченно применимом только для узкой номенклатуры Изделий в исполнении УХЛ (потому что гайку хромированную поменяли на гайку ржавую обыкновенную, и для субтропического исполнения оно не применимо, т.к. приржавеет после первого муссона :). |
||
| 11 сен 19, 09:40 [21968279] Ответить | Цитировать Сообщить модератору | |||
| Re: Архитектура базы
|
|||
|
Serg197311 Member Откуда: Жуковский Сообщений: 518 |
Вот и я пока к нему склоняюсь...... |
||
| 11 сен 19, 09:46 [21968285] Ответить | Цитировать Сообщить модератору | |||
| Re: Архитектура базы
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
ПЕНСИОНЕРКА Member Откуда: Владимирская обл Сообщений: 4592 |
Serg197311, мы считали так sernn \код изделия\1
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 11 сен 19, 09:46 [21968286] Ответить | Цитировать Сообщить модератору | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Re: Архитектура базы
|
|
|
Serg197311 Member Откуда: Жуковский Сообщений: 518 |
Я в таблице храню только количества деталей/сборок в вышестоящей сборке. Если надо посчитать винты такие-то в изделии или в сборке такой-то - это делаю функцией на vba. |
| 11 сен 19, 09:50 [21968291] Ответить | Цитировать Сообщить модератору | |
| Re: Архитектура базы
|
|||
|
ПЕНСИОНЕРКА Member Откуда: Владимирская обл Сообщений: 4592 |
вряд ли изделие в тропическом исполнении отличается только гайкой от базового -отличается и весь техпроцесс, а значит это другое изделие и другие составляющие и другой техпроцесс, даже в гравировке деталей добавляются символы |
||
| 11 сен 19, 09:54 [21968295] Ответить | Цитировать Сообщить модератору | |||
| Топик располагается на нескольких страницах: [1] 2 3 вперед Ctrl→ все |
| Все форумы / Microsoft Access | |
|
x