Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: ←Ctrl назад 1 2 [3] 4 5 вперед Ctrl→ все |
Изерлонер Member Откуда: СФО Сообщений: 1269 |
Эту оплошность, как вы видите, далее я исправил.
Не без этого. Только трудно порой не переступить грань и заняться самоедством.
Почему дико? Три нормальные формы вроде соблюдаются. Исключение - таблица элементов с полем взаимозаменяемости (будь она не ладна), но это именно исключение. Ну не нашел лучшего выхода, выход с таблицами суперизделий (две отдельные таблицы, связь с таблицей элементов много ко многим) была явно худшим вариантом... ну по крайней мере в моей реализации
Жизнь заставила.
Наоборот, прекрасно понимаю! Это скорее ответ на ваши слова что, мол вы с огромным опытом и знаниями все сами прекрасно видите и понимаете.
|
|||||||||||||
5 дек 13, 17:24 [15248182] Ответить | Цитировать Сообщить модератору |
Изерлонер Member Откуда: СФО Сообщений: 1269 |
|
|
5 дек 13, 17:38 [15248306] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
Вот наброски модели:
DECLARE @iElementID_Root Int = 6000 -- Продукт как тип или конкретный продукт с идентификационным номером? , @iElementID Int = 1 -- Расходная деталь (конкретная модель, определённой серии) , @iContractorID Int = 4 -- Потребитель
1. Норма расходов (в тубриках) для конкретного продукта 2. ??? Последний показатель говорит что или моя предположительная модель неверна (не угадал на койфейной гуще) или тут полный ахтунг. В модели есть таблицы, которые не используются - но типа нужны для процесса (допустимые компоновки). Там есть модель продукта и сами продукты. Модель продукта, как вы видите, не используется в конечном запросе. Если вам не понятно что означает таблица-понятие спрашивайте. Как только разберётесь - скажете, на сколько не соответствует реальной модели. |
||||||
5 дек 13, 19:35 [15248949] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
![]() ![]()
Хотя вы можете просто почитать то что я вам привёл. Книжечки и темки. Хотя врядли вы это сможете.
У интровертов/иррационалов это обычно развивается самостоятельно, самоанализ, рефлексия - неотъемлемая часть мышления.
CREATE TABLE [dbo].[tblNodeElement] ( [iNodeElementID] Int CONSTRAINT [PK_tblNodeElement] PRIMARY KEY , [iElementID] Int NULL , [iElementID_Parent] Int NULL -- CONSTRAINT [FK_tblNodeElement_Parent] REFERENCES [dbo].[tblNodeElement] ([iElementID]) -- Офигенски спроектированная таблица --, [iEdizmID] Int NULL -- Не по теме , [decNodeElementCnt] Money NULL )
А главное - при изучении нормализации, описывается алгоритмы приведения. Специально для тех кто не умеет формализовывать модели.
Это просто придуманное с потолка объяснение. Соционика говорит что это в большей степени врождённо, а далее воспитание/жизненный опыт. Судя по всему вами сказанном - это скорее врождённо, психотип.
А вот если не будете спешить, то в итоге сдадите сразу без проблем, а то уже сколько мусолите, и что не тронь - находите ошибки. Так модель я вам показал, думайте - описывайте. Приводите нормальные данные для тестов и формулы расчёта. Опишите на той модели - быстрее получите запрос на текущей. |
||||||||||||||||
5 дек 13, 21:01 [15249282] Ответить | Цитировать Сообщить модератору |
Изерлонер Member Откуда: СФО Сообщений: 1269 |
С какой стати??? tblNodeElement привязана к tblElement, а никак не к себе самой! А как еще реализовать иерархическую структуру куда можно загнать сколь угодно сборок/подсборор/узлов и т.п? Изделие состоит из агрегатов и деталей. Агрегаты состоят из сборочных единиц и деталей. Сборочные единицы состоят из сборочных единиц следующего уровня и деталей .... и т.д. Так же при ремонте на каждом уровне применяются какие либо материалы (это что касается выделения материалов в отдельную таблицу. Я даже себе представить не могу как можно с выделенной отдельной таблицей материалов распихать их применение по каждому уровню). Вы ломаете всю схему базы данных. Я не знаю может быть схема (в моей реализации) и плоха, но у меня нет другой рабочей схемы. ![]() |
||
7 дек 13, 18:42 [15258545] Ответить | Цитировать Сообщить модератору |
Изерлонер Member Откуда: СФО Сообщений: 1269 |
К сообщению приложен файл. Размер - 146Kb |
7 дек 13, 18:56 [15258585] Ответить | Цитировать Сообщить модератору |
Изерлонер Member Откуда: СФО Сообщений: 1269 |
лять! Как же мне "нравится" возможность корректировки/удаления своего сообщения! Вот обновленная (самая свежая) схема данных. Выкладываю не для того что бы ее разбирать, а что бы видно было хотя бы что откуда взялось. Для улучшения взаимопонимания. Красным вычеркнул мусор (старые поля которые более не нужны, но пока сохраняю их в базе, вдруг забыл чего из них в новые таблицы перенести) либо то что сейчас не существенно: К сообщению приложен файл. Размер - 148Kb |
7 дек 13, 19:44 [15258676] Ответить | Цитировать Сообщить модератору |
Изерлонер Member Откуда: СФО Сообщений: 1269 |
Пока разбираюсь, выглядит любопытно. Вопрос по ходу - Составные ключи, насколько вообще допустимо их использовать? У меня по ходу общения на форуме сформировалось впечатление что составные ключи - зло. Лучше задать суррогатный, и поставить индексы/ограничения на соответствующие поля. Это не верно?
Ахтунг. SumZeh - норма расхода данной детали (номенклатура, тип) на данном изделии (тип изделия) в данном цехе (конкретный цех). не только для деталей, но и для материалов. SumIzd - норма расхода данной детали на данном изделии (на все цеха предприятия в целом). Т.е. Сколько деталей (материалов) данной номенклатуры идет на ремонт всего изделия в целом. Есть и еще один аналогичный показатель (только для деталей, ну может еще для узлов) Суммарное количество деталей данной номенклатуры могущих быть на данном типе изделия. Т.е. если выше были нормы, здесь ВСЕ детали (в отдельных случаях норма = суммарному количеству деталей (детали обязательной замены), но как правило это не так).
Пока разбираюсь. |
|||||||||||
7 дек 13, 20:22 [15258762] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
Обычно у сущности есть просто суррогатный ключ, но всё равно приходится вводить представительский, банально на название, лучше иметь код (серия). Но иногда есть не понятие, а связка. Связка часто не имеет "потомков", оно просто связывает, типа пользователь-роль (тут один ключ), и может иметь свойства (типа Hidden, Modified), но иногда нет - оно также является понятием, и если у него есть под-элементы и выступает самостоятельной единицей тогда стоит ввести и суррогатный. В данном случае оно того не стоит. Можно ввести, но больше нагромождает. Более того, модель нестабильна, не определена (это главная причина). Тем более что можно в принципе убить таблицу dbo.Assembly, и её роль возмёт на себя сама dbo.DetailConsumptionRate. Т.е. вверху суррогат необходим, а внизу можно и подыграть. Надо помнить главное - схема базы строится под задачи. Такая структура с составным ключём увеличивает производительность за счёт уменьшения количества таблиц в запросах (сразу есть нужная колонка). Только в текущих версия это стало менее обязательно. Т.к. можно создавать индекс сразу на несколько таблиц (межтабличные индексы). Разве что лишние индексы занимают память и IO.
Поправлю запрос на моей модели: SELECT A.Product , C.Detail , Sum(C.[Count] * R.Rate) FROM dbo.Consist C JOIN dbo.Article A ON A.ID = C.Article JOIN dbo.DetailConsumptionRate R ON R.[User] = A.[User] AND R.Node = C.Node AND R.Detail = C.Detail GROUP BY A.Product ,C.Detail
Тогда вопрос. Если это тип изделия. То причём тут заменяемость деталей? Комплектация деталями может быть разнообразно. Для каждой комбинации рассчитывать? Но их количество растёт пропорционально факториалу заменяемости деталей. Что есть decNodeElementCnt? Что есть decZehNorm? Это нормы расходов для деталей? Что это? Как я понимаю есть два подхода в расчёте нормы расхода: графоаналитический и расчетный. Какой у вас используется? Судя по тому что у вас описана структура продукта, то расчётный. Для графоаналитического модель не нужна, и можно снести соответствующие таблицы описывающие модель. Для расчётного нужно убрать таблицы с конкретными показателями, оставив только модель. Тогда сразу вопрос, причём тут цех? Норма расхода, заложенная в модели не зависит от производства. Там просто издержки расходов материалов из-за изношености станков или их особенностей. Тогда получается у вас графоаналитический подход рассчёта нормы рассхода. Вы уже определитесь какой у вас. Если оба, то они независимы, хоть и ссылаются на общие таблы. При графаналитическом в таблице dbo.DetailConsumptionRate можно убить колонку [Node] (вот и пригодился составной ключ), ибо тупо считает до кучи, сколько потрачено в целом.
Мы говорим о расходе материалов на производство изделия? Или расхода запасных частей станков для их производства? Всё ещё непонятно про заменяемость деталей. Есть заложенная схема продукта из конкретных материалов и конкретных деталей в конкретных узлах. Т.е. конкретные нормы расходов. И вот допустим можно некоторые детали заменять. Тогда вводится понятие комплектация. Тут есть такие стратегии. Каждая комплектация это независимая модель (хоть они практически идентичны). Или вводится супермодель из абстрактных деталей, а далее каждая комплектация просто описывает связку конкретного типа детали с конкретной абстрактым-узлом-деталью (заменяемость). У последней есть недостаток - супермодель слишком "неповоротлива", ибо можно заменить целый агрегат (не предусматривавшийся для супермодели). Есть ещё эволюционный вариант - где описывается базовая модель-комплектация, а далее каждая последующая комплектация есть "мутирование" (удаление-добавление-замена) от предка. Скажу что запросы делать в ней бывает просто муторно. И такая полезная в таких задачах вещь как HierarchyID пролетает как фанера над парижем. У каждого подхода есть свои недостатки. Выбор зависит от задачи. Так что пока, понятие заменяемости деталей, точнее как вы это описали - хрень собчачья. И норму расхода рассчитывается на конкретную комплектацию (расчётным методом). Или хоть на весь завод (графаналитически), хотя назвать. И почему это называется "нормой" не пойму - простая сумма расходов. Хотя понятно - эти бухгалтера, часто обычные На данный момент моя модель, судя по всему, не подходит (надо упрощать, корректировать). Но какая правильная - зависит от ответов на выше перечисленные вопросы. Позже поразбираюсь в ваших таблах. |
||||||||||||||
8 дек 13, 03:39 [15259845] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
|
||
8 дек 13, 03:49 [15259848] Ответить | Цитировать Сообщить модератору |
Изерлонер Member Откуда: СФО Сообщений: 1269 |
Для любого агрегата (по крайней мере из тех что могут ремонтироваться на предприятии). Имея нормы расхода на каждый агрегат изделия - автоматически получаем нормы расхода на все изделие (просто сумма всех норм). Но с небольшими оговорками. Например для агрегатов приходящих в ремонт отдельно (не в составе изделия) закладываются материалы на консервацию и упаковку. Если агрегат в составе изделия этих материалов нет. Ну и еще отдельные подобные случаи, но основная часть норм без изменений.
Меня сбивает слово "тип" в отношении детали. Номенклатура здесь более подходит. Норма расхода детали данной номенклатуры.
Во-во. Головняк это большой. Я бы тут еще разделил взаимозаменяемость деталей и взаимозаменяемость узлов. Каждый тип изделий он же не фиксирован, идет время - какие-то агрегаты (входящие в состав изделия) модифицируются производителем, появляются новые серии и т.д. И это все один и тот же тип. Был автомобиль ВАЗ 2101, в каком нибудь 1972 году ему модифицировали трансмиссию. Была трансмиссия А, стала Б. Суть ни чем не помянялась, поменялась номенклатура и количество деталей. И таких модификаций на любом агрегате до черта. Я тут к одному нашему спецу подошел (реальный спец, технарь, но в прямую с изделиями не работает) спрашиваю как быть? Что в нормах учитывать? Он говорит - если ты попытаешься учитывать все модификации - то в конец запутаешься и сдохнешь на работе. Учитывай только последнюю модификацию. Я бы и рад, мне же головняка меньше. Разговариваю с технологами - а что может вообще в ремонт прийти и в каком виде мы это выпускаем? В ремонт может прийти все что угодно в том числе изделия с агрегатами старых модификаций. И мы их ремонтируем и выпускаем с теми же модификациями (доработки могут быть, но могут и не быть - все по согласованию с заказчиком). Вот отсюда пошли попытки хоть как-то все это учесть, попытался совместить ежа с ужом. Есть базовая комплектация (сам назначаю) в нее входят все агрегаты самой последнее модификации и для этой фиксированной комплектации и расчитываются все нормы (тут все четко, просматривается количество деталей каждой номенклатуры, нормы...). Но! Так как в ремонт могут прийти изделия с агрегатами ранних модификаций их тоже как то надо учитывать и показывать в нормативах. Я их и показываю. В примечании ставлю - "взаимозаменяема с..." а расчет суммарных показателей (норм и количеств) проводится так как если бы все изделие было в базовой комплектации, за исключением данного конкретного агрегата. Ну а с взаимозаменяемостью отдельных деталей (и материалов) несколько проще если не заморачиваться (а то и там случаев таких наскрести можно что голова кругом, но это все же редко, да и нахрен никому не нужны эти тонкости... может быть кроме меня) Есть взаимозаменяемые детали например подшипник А и Б. В нормативах показываем и тот подшипник и другой с их количествами и нормами, примечание - "взаимозаменяемы", но при анализе фактического использования в ремонте - условие. Если установлен подшипник А (и выбрана вся норма/количество), то подшипник Б ставить нельзя. И наоборот.
decNodeElementCnt - количество деталей (или узлов... материалы здесь точно не указываются) в узле. decZehNorm - норма расхода детали/узла (материала) на ремонт данного узла.
Никакой. Все жесточайшим образом регламентированно, под каждую цифру должна быть бумажка, проверяющий в расчетах разбираться не будет - ему бумажку подавай где прописано... Слава Богу что проверяющие до меня пока не добрались, так как по моей части идет полный ахтунг. Меня на это место и посадили что бы порядок навел (собрал все данные из всех источников во едино, а это несколько сот томов), а даже скорее не для этого, а что бы был человек на которого в случае чего и ответственность спихнуть (но это имеем в уме за скобками). В отдельных спорных случаях может быть прямой замер (понятно касается это в основном только материалов) Технолог топает на рабочее место и проводит контрольный замер что и как используется. Потом составляется бумажка "Акт комиссии.." которая уже может служить основанием и может быть включена в норматив. На самом деле это происходит довольно редко и этих актов по пальцам пересчитать. Для запчастей основной источник руководство по ремонту - там тоже полный ахтунг -но там все (или почти все) прописано. Нормы там прописаны на изделие (агрегат), без всяких цехов. Разбивку по цехам и по узлам провожу самостоятельно, главное что бы в сумме получалось то что прописано в руководстве по ремонту. Там где норм нету сам использовал расчетный метод. Но это "к делу не пришьешь" (тем более выборка для расчета очень подвержена совершенно посторонним факторам - например на ремонт может быть выписано что либо не потому что необходимо для ремонта, а что бы набрать затраты на ремонт. Все ведь с ног на голову сегодня поставлено, экономика рулит ![]()
Ни при чем. Нормы в руководствах задаются на изделие (агрегат), на цеха распределяю я сам (в соответствии со специализацией цехов и тем что написано о процессе ремонта в тех же руководствах. А издержки расходов на станки и т.п. вообще не учитываются. (это все накладные расходы, которые меня никак не интересуют) Главное то что идет непосредственно на сам ремонт.
[quot Mnior]Стоп, мы ещё чётко не расписали что к чему. Суммарное количество типов деталей? Мы говорим о расходе материалов на производство изделия? Или расхода запасных частей станков для их производства?С Если Вы под суммарным количеством типов имеете ввиду сколько разнообразных типов в изделии имеется вообще, то нет. Суммарное количество детали данного типа (ну не катит здесь тип, номенклатура ближе) на изделие. Стоят у вас свечи в двигателе автомобиля. Суммарное количество на агрегат (двигатель) - 4 шт. На изделие (автомобиль) - 4 шт. Если бы в автомобиле стояло 2 двигателя - было бы 4 и 8 соответственно. Но это суммарное количество тех что стоят вообще. По норме при ремонте могут заменяться не все свечи, а например 2шт на двигатель. Тогда в последнем случае получим цифры 2, 4 соответственно.
У нас вполне себе симпатишные женщины ![]() А почему не норма? Если для изделия в целом то норма и есть. По ней затем далее другими отделами расчитываются свои плановые показатели. Сколько изделий будем ремонтировать в следующем году, да сколько материалов/деталей необходимо закупить для ремонта. Что из этого срочно (уже сейчас) надо заказывать. Планирование сроков, закупок и т.п. |
||||||||||||||||||||
8 дек 13, 07:27 [15259900] Ответить | Цитировать Сообщить модератору |
Изерлонер Member Откуда: СФО Сообщений: 1269 |
decZehNorm - норма расхода детали/узла (материала) на ремонт данного узла в данном цехе. |
||
8 дек 13, 07:33 [15259905] Ответить | Цитировать Сообщить модератору |
Изерлонер Member Откуда: СФО Сообщений: 1269 |
По поводу норм такую "крамолу" еще напишу. В ремонтном производстве на нормы в принципе наплевать. Норму подвинуть можно. Начнет орать начальник какого-нибудь цеха что ему на ремонт изделия ... спирту не хватает. Соберут комиссию, и если его доводы признают убедительными "Мамой клянусь!" - подпишут не взирая на наличие/отстутвие норм расхода. Не так все просто конечно, все ж проверок боятся, но тем не менее, найдут основание это сделать. Поэтому для меня конкретно, как для нормировщика есть следующие правила: Для проверки расхода материалов ориентируюсь на нормы +/- какой-то допуск (особо жесткий допуск для ГСМ в "+" практически ничего). В случае значительного превышения этого допуска требую от начальника цеха бумажку мне на стол за подписью главного инженера - "Куда? Зачем? Основание?". Есть бумажка? Нет проблем, пропускаю. Нет бумажки - че хотите делайте - больше нормы не дам. Для проверки расхода запасных частей самым жестким критерием является количество на изделии decNodeElementCnt. Ну не может быть на изделие выписано четыре подшипника типа А если их на всем изделии стоит две штуки. Физически не может быть. По нормам критерий примерно такой же как и для материалов. На каждое превышение нормы - бумажка. (на деле 50/50 где-то есть бумага, где-то нет пока проверяющие не докапывались (вообще до меня пока не добирались, хотя близко были, да. У меня волосы дыбом на башке торчали), но в идеале при превышении нормы должна быть бумага, что бы прикрыть свою |
8 дек 13, 08:06 [15259909] Ответить | Цитировать Сообщить модератору |
Изерлонер Member Откуда: СФО Сообщений: 1269 |
Смысл суммарных показателей (норма на изделие по цеху, норма на изделие, количество деталей на изделие): 1. КОНТРОЛЬ материальных затрат на ремонт реального изделия проходящего ремонт. Это главная цель, ради неё и все танцы с бубном. Затраты списываются во внешней базе данных на изделие (в случае полноценного изделия) или на наряд-заказ в случае списания на отдельные агрегаты (а вот это конкретный такой ахтунг, с которым я очень долго боролся настаивая ОДИН агрегат – ОДИН наряд–заказ! Но добился лишь что на один наряд заказ могут быть несколько однотипных агрегатов. Проследить на какой конкретно агрегат была списана деталь пользуясь только базой данных не возможно. Но так всё равно лучше, чем когда на один наряд– заказ была масса разнотипных агрегатов — контролировать вообще ничего не реально. Ну и соответственно суммируется расход по внешней (учетной) базе данных и сравнивается с суммарными показателями моей. Сравнивается, выдается заключение – в норме (пропустить «требование»), недобор, перебор. 2. Выдача плановых показателей на будущие периоды, выдача заданий ОМТС. Расчет цены ремонта (в части касающейся материальных затрат) для заказчиков с подробным обоснованием |
8 дек 13, 10:42 [15260009] Ответить | Цитировать Сообщить модератору |
Изерлонер Member Откуда: СФО Сообщений: 1269 |
В вашей модели у узлов не может быть норм расхода? В реальности это не так. Узлы тоже могут меняться, просто это происходит реже. Ну настолько все плохо например что проще заменить весь узел, чем его ремонтировать. Прикладываю скрипт с тестовыми данными (для исходной базы данных) упакованные, иначе по ограничениям форума не проходят. Два изделия. Одно проработано достаточно подробно, с несколькими узлами, уровня три вложенности. Имеются так же узлы "взаимозаменяемые" ... хотя конечно вы правы, называть их "взаимозаменяемыми" в данном случае не корректно. просто две версии, узлы новые, узлы старые. показывать их не стал, поле iIndex которое это показывало снес. Тестовые запросы по ней и по поводу взаимозаменяемых ... наверное завтра. К сообщению приложен файл (Тестовые данные.zip - 11Kb) cкачать ![]() |
||
8 дек 13, 17:14 [15260667] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
Т.е. смешанный. Кое-где простая сумма по структукре изделия, кое где акт проверки на станке - вписываются цифры явно, без описания структуры. Но как я понимаю только для агрегата, а не "7 квадратов стали X на весь ВАЗ 2101"
Ваши ответы я не понял: -: 2 + 2 = 4? -: Нет! Нет! И Нет! Ни в коем случае! 2 + 2 = 4! -: Так четыре? -: Нет! Панимаете, я сегодня вышел на улицу и была плохая погода. А 2 + 2 будет Четыре! Я не могу так разговаривать, для меня очень важно чтобы все части всех предложений всего топика сходились (со всеми правками). Очень тяжело читать отрывки мыслей людей у себя на уме. Если вы говорите "нет", то не надо давать объяснения в отрыве от вопроса. К примеру: - 1 + 2 + 3 + 4 = 10? - Нет! 4 + 3 будет 7. 7 + 2 = 9, и 9 + 1 будет 10. Потому ответ 10. Так нельзя говорить. Надо так и сказать - "Я не очень могу так считать, могу ват так". Но не пишите нет, которые может означать - "не понял", "не знаю", "ХЗ" и т.п. "Не приём" - для меня означает, что мы вырезаем любое упоминание этого термина и эту переменную из задачи в любом виде. Договорились?
Давайте убирём слово "норма расхода" вообще. А просто напишем количество (для деталей - для данного узла нужно 3 подшипника типа A), состав, или затрачивается (на деталь X тратится N килограмм чугуния) Притом неважно, для узла или для всего продукта - это тупо "количество материала". Нет никаких справочников аля tbZehNorm. Количество прописывает или в структурной таблице, или в упрощённой - не важно. В итоге мы получаем константную сводную таблицу: ([Продукт],[Деталь/материал],[Количество/Затраты]). Эта таблица автоматически изменяется только в момент ввода структуры продукта/агрегата/узла (при расчётном подходе) или при акте замеров (при графаналитическом). Расчётный метод это не только расчёт объёма материала на основании заливки, стругания болванок, сверления и т.п. А даже просто: тупое суммирование деталей. Вы должны всегда огораживать нас от вашей кухни которая никоем образом не касается задачи. К примеру: "Мы составляем 100500 актов затрат материалов, а потом суммируем на бумажка, а в систему вводится итоговая сумма". Вы должны так и сказать "Вводится итоговая сумма на основании реальных замеров". Мусор словоблудия не нужно. Ок? Это раздражает.
Есть объект (конкретная машина в которая сейчас стоит на стоянке), а есть тип объекта (ВАЗ 2101 как модель автомобиля). Объектов тип А - много. Типов А - адын, и так даже нельзя говорить. Далее, если у вас есть тип "ВАЗ 2101 А" и "ВАЗ 2101 Б", то это два разных типа, и тогда "ВАЗ 2101" - не тип, а группа типов. Вы можете назвать место слова "тип" - "модель", можете "номенклатура", но если но вы должны выбрать и придерживаться только одного названия и не употреблять другие. "номенклатура" - это сленг в данном случае, а сленг посылаем на хрен - тут форум не данной тематически. В вашем случае вы можете сделать группы моделей, но никак нашей задачи это не должно касаться вообще. Это ваша проблема, оставьте это за кадром.
Это не понятия никак не пересекаются. Это разные задачи. И значения по ним разное: 1. Для производства автомобилей модели А - необходимо затратить 3 тонны чугуния. 2. Для ремонта автомобиля модели А, серия и номер XXXX....XXXXX, от такого-то числа было затрачено 3 килограмма чугуния. 3. Для ремонта автомобилей модели А, за этот месяц на этом ремонтном гараже, в среднем по больнице требовалось 3.14 килограмм чугуния. "Норма" (понятие которое мы далее не будет употреблять) имеет место быть для производства, не для ремонта. Может быть там у вас и употребляются одинаковые слова - но это не значит что это одно и тоже или как-то связано. "Расчётный износ детали" - это другая опера. Это тесты, это замеры и состав автомобиля тут не причём совершенно. Это просто абстрактные константы в вакууме.
Для производства детали А станок потребляет 314 грамм чугуния. За месяц сгорает 15 свечек у автомобиля модели А. Это разные вещи. Обусловленные разными процессами. Одно дело состав агрегата и как он делается, и какой станок, а другое дело, мастерство и степень экплуатации автомобиля в текущих условиях. И вы так и не сказали область что мы рассчитываем - ремонт или производство. Пошли в абстракции. Вместо того чтобы определять чётко конкретику и идти дальше.
Другое контролировать процесс. Контролировать можно 100500 способами, включая контроль предельных допустимых значений. У вас походу целый комплекс задач. И бардак в голове.
2. Контроль заключается не в расчёте "средней по больнице". А учёте самого процесса ремонта.
Да, нужно ставить ограничения, для контроля, но тут явно видно что всё хотите свести к одной строке в табле, и вход и выход. Из описанного могу сказать: Вас специально подобрали на ваше место - как лучшую кандидатуру чтобы можно было сохранить бардак на предприятии, чтобы спокойно воровать дальше. А если что - вами и прикроются. ИМХО.
Как опишите постановку задачи так и будет считаться. Нет постановки нет модели. Из вас тяжело добиться вразумительного ответа, чтобы расписать модель. А вас ещё поставили как разработчика. Нет слов. С таким подходам вам только в форум работа. И сдерут с вас нехило. |
||||||||||||||||||||||||||||||||||||||||||
9 дек 13, 21:57 [15267418] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
Вам нужно просто завести в нужную древовидную структуру данных (в общем смысле, а не Parent - ID). Вводить показания реальных потреблений и через OLAP смотреть по нужным разрезам. Сейчас там есть и предсказания и среднее по больнице и нормы и всё такое. Для контроля нужны описания структуры изделий. Можно аж вводимые данные проверять на крайние условия, или отдельно учитывать поломка деталей во время ремонта. Т.е. просто отражать весь процесс в цифре. Учитывать материалы на выкидывание (заменённые детали). Замеры выборочного контроля. Учёт пользователей. Ну и всё такое. |
9 дек 13, 22:46 [15267632] Ответить | Цитировать Сообщить модератору |
Изерлонер Member Откуда: СФО Сообщений: 1269 |
|
|
10 дек 13, 08:06 [15268356] Ответить | Цитировать Сообщить модератору |
Изерлонер Member Откуда: СФО Сообщений: 1269 |
Если можно так сказать - "административный". Те примеры что я привел - скорее исключение. Нормы расхода (все же нормы, они так в руководствах ремонта и называются, и называли их не бухгалтера, а технари) на ремонт просто есть в различных руководящих источниках и от меня требуют их соблюдения. Соответственно первая задача - собрать все эти нормы в единую базу. Вторая - отслеживать реальное соответствие этим нормам.
Норма расхода она и есть норма. Это плановый показатель. Убрать можно, но Вы потом в количествах не запутаетесь? Количество материалов/деталей затрачиваемых на ремонт план/факт. Количество деталей установленных на агрегате. ...
Пусть будет тип.
Расскажите это издателям ремонтной документации.
Это и ежику понятно. Но при регламентированном ремонте меняются детали в независимости от их состояния. В том смысле что деталь может быть в сколь угодно хорошем состоянии - идет под замену, если это прописано. Правда надо разделять детали обязательной замены, и детали заменяемые по дефектации. По вторым в сущности вы правы. И когда-то раньше нормы расчитывали, статистическими методами, графоаналитическими методами. Прошло то время. Сейчас их тупо назначают. ![]()
Ремонт.
Не я это придумал... но мне это надо каким-то образом реализовывать.
При чем здесь заскоки. Как проконтролировать на какое изделие была установлена деталь если она выписана на группу деталей? ... и я не программист.
Совершенно верное мнение. Только масштабов вы не учитываете. Не я один такой, и даже не все предприятие. Вся отрасль так работает. И воровство идет по крупному на очень высоких уровнях. На моем уровне воровства минимум ... просто знаю. Соответственно и маразматические противоречащие друг другу требования - как бы все так учитывать что бы никто (из рабочих, ИТР и прочего персонала) не воровал (чего и так нет, все за работу держатся, потому что знают что на улице ловить нечего), но что бы для проверяющих органов все было по максимуму не прозрачно.
Не ставили меня разработчиком. Нужно было заткнуть кем-нибудь дырку, под руку я попался. ...и мне вдруг эта работа оказалсь сильно интереснее предыдущей. То что у большинства работников вызывает сильное желание уснуть ... я обрабатываю с интересом. ...Хотя даже этого интереса бывает мало что бы сдержаться и не положить заявление об увольнении начальнику на стол... Разработка - это моя личная инициатива. [/quot] |
||||||||||||||||||||
10 дек 13, 09:03 [15268545] Ответить | Цитировать Сообщить модератору |
Изерлонер Member Откуда: СФО Сообщений: 1269 |
Опечатался. Расчётными методами, графоаналитическими методами. Короче, расчёт непосредственно самих норм (для каждой детали в изделии) это не моя задача. Моя задача использовать то что уже есть в "бумажном" варианте. Надеюсь с этим задача упрощается? |
||
10 дек 13, 11:30 [15269556] Ответить | Цитировать Сообщить модератору |
Изерлонер Member Откуда: СФО Сообщений: 1269 |
блин, точно спать надо. На группу изделий конечно. |
||
10 дек 13, 11:39 [15269631] Ответить | Цитировать Сообщить модератору |
Изерлонер Member Откуда: СФО Сообщений: 1269 |
Я не понимаю смысла таблицы Article в вашей схеме. Я вижу что в ней определяется взаимосвязь цеха и изделия, но зачем (или почему именно так) не понятно. И давайте действительно определяться с понятиями. Могу попытаться более менее корректно описать требования, что есть и что нужно. Насколько подробно надо описывать? |
10 дек 13, 18:22 [15273325] Ответить | Цитировать Сообщить модератору |
Изерлонер Member Откуда: СФО Сообщений: 1269 |
Mnior, если вы решите уйти из темы, прошу просто скажите об этом, не молчите. |
10 дек 13, 18:27 [15273338] Ответить | Цитировать Сообщить модератору |
Изерлонер Member Откуда: СФО Сообщений: 1269 |
Mnior, если вас смущает понятие норма в отношении ремонта, предлагаю замену - плановый расход материалов/запчастей на ремонт, в противовес фактическому расходу. |
10 дек 13, 18:39 [15273398] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
Не думаю что будет какой либо результат от разговора.
Править её не получается из-за непонятности целей и отсутствия внятного ТЗ, и уже совсем не интересно заниматься откровенно бредовой задачей, вешедшей за рамки рациональности. Article изначально было как "реальное изделие"
Бредовость задачи не имеет смысла, если бы мне предложили разработать, я бы загнул цены раз в 5ть. Пустая трата времени. Поэтому и предложил вам идти на форум "работа".
Каково наказание за не выполнение этой нормы среднестатистического жителя Африки? Это симулякр.
Ваше "решение" не решает задачу. На какой узел была установлена деталь - не узнать. Теперь вы понимаете что гранулярность может быть разная (общий процесс, группа изделий, изделие, узел, посадочное место, деталь). Для контроля общего процесса (сохранения массы), не нужна такая мелкая гранулярность, особенно когда это препятствует технологическому процессу (сдача группой). И эту ошибку понимания я и назвал "программистким заскоком". А то что деталь попала на на то изделие, а на другое, так оно может попасть и в другой узел, или не на то место в узле. Стоит ли это контролировать? Ну так наверно это заложено в сам процесс ремонта. А если есть нарушение - то какая разница было при этом одно изделие или два - главное оно выявлено, а далее разбор полётов.
Вот освойте OLAP, как раз его ограничения заставят вас правильно описать задачу. В нужном русле. Я могу написать схему, но я делать этого не буду. Могу периодически послеживать и поправлять ваши самостоятельные умозаключения и формалюзацю. Сперва распишите в 3-7 предложений (без воды и чётко) суть задачи, так чтоб это понял любой реальный технарь, не читавший этого бреда. Типа: "Система учёта расхода деталей/материалов для ремонтных цехов и контроля допустимых их значений на основе структуры ремонтируемых изделий ...", раскрывая суть "учёта расхода". Вот вам цель, вот достигните её, с уклоном на качество (а не лишь бы накалякать). Остальные этапы скажу позже, если это преодолеете. |
||||||||||||||||||||||||
11 дек 13, 00:47 [15274391] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: ←Ctrl назад 1 2 [3] 4 5 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |