Разрабатываю программу для учета продукции (стекло и стеклопакеты). Придумал вот такую схему БД в ERwin. Подскажите пожалуйста тут может быть не правильно.
Спасибо!
http://fastpic.ru/][IMG] http://i22.fastpic.ru/big/2011/0627/15/1405417562b999d8d49d77915454fe15.jpg [/IMG]

Никто не подскажет?

miksoftХм, "толщина продукции"... Это что ж такое производите?

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

miksoftДвижения материалов в накладные/документы прихода/расхода не объединяются?

Понял. Переделаю. Может и "Движение средств" тогда туда же добавить - будет просто еще один тип движения?

miksoftДвижения средств с движениями материалов и заказов никак не связаны?

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


miksoftЗачем Длина/Ширина/Толщина в сведениях о заказе, а не в справочнике продукции?
Тип продукции например - стекло прозрачное 4 мм, а в заказе указаны нужные заказчику размеры этого стекла, например длина 1000 ширина 1000 количество 1шт, длина 500 ширина 500 количество 10 шт и т.д. А вот толщину уберу - вы правы.

miksoftПочему Цена продукции не в сведениях о заказе?

Перенесу.

miksoftСрок изготовления един для всего заказа, по разным позициям различаться не может?

Не может.

Спасибо большое вам за помощь!

Может кто-нибудь еще покритикует\поправит схему?

7000 постов за сутки и ни одного в этом разделе... Где же все спецы по проектированию БД?

Vladimir2009,

Спасибо, добавил.

miksoftanch2011Где же все спецы по проектированию БД?Тут нужны не столько спецы пр проектированию БД, сколько спецы по вашему бизнесу. Да и еще которые в курсе планов на будущее вашего руководства.

Спецы не нужны ) Производство очень простое - покупаем стекло и комплектующие, нарезаем стекло в размер и собираем стеклопакеты. Они могут быть 1-о и 2-х камерные, разной толщины так как стекло может быть разной толщины, может использоваться разное стекло (цвет, энергосберегающее) и т.д.
Прошу помощи у форума именно по нюансам проектирования БД для производства, как должна выглядить типовая БД для прозводства?
Если будут какие-нибудь вопросы, пожалуйста задавайте.

Последняя версия схемы
http://fastpic.ru/][IMG] http://i26.fastpic.ru/big/2011/0705/9b/ae21c7afd5bb68e32b3be354d462109b.jpg [/IMG]

Какие еще будут замечания?
Никак не могу разобраться с типом связей. Когда используется идентифицирующая связь?

Ап

softwarer,

Спасибо!

Cane Cat Fisher,
Cane Cat FisherОчень бегло:
Вокруг банков что-то накручено.
Зачем выносить названия банков в справочник? Много банков с одинаковым названием? Или имеются в виду отделения одного и того же банка? Но у отделений тоже есть собственные имена - иначе как же их тогда различать?
Для банка надо хранить код МФО, или как оно там сейчас называется - он необходим для оформления любого документа.
Банковский счет должен ссылаться на банк (ID_Банк). Из Банка поле ID_Банк_счет убрать.

Согласен. Переделал.
Cane Cat FisherК банковским счетам надо бы даты действия, или хотя бы ручные флажки "открыт-закрыт". Например, была ситуация, когда банк заблокировал наш счет - говорит, пока не отдам, он типа слегка депозитный, а у нас кризис - депозиты до срока не выдаем. Мы срочно открыли новый счет в другом банке, потому что большая контора изъявила желание срочно заплатить за проект, и сообщили его номер. И что вы думаете? Бухгалтер большой конторы сослепу ткнула в списке из двух номеров счетов именно в старый, заблокированный, и деньги шуранула туда. Так что галочки, примечания и все эти вещи.

Сделал.
Cane Cat FisherПо адресам. Данный способ вынесения улиц, городов и домов в справочники в общем-то работоспособен, но, чисто из вредности, сформулирую вопрос, на который он не сможет ответить: вывести список улиц заданного города, на которых нет ни одного нашего контрагента? (смысл запроса, например, в форсировании на этих улицах рекламных компаний). Как вариант, можно подумать о иерахическом справочнике, где улица принадлежит городу, дома - улице и т.д.

Я думаю что такие запросы маловероятны.
Cane Cat FisherБригада, ИД_Сотрудник - это Бригадир ? А сам состав бригады, не нужен?

Это именно состав бригады. На самом деле мне не понятно, как сделать чтобы несколько человек были в одной бригаде?
Cane Cat FisherПоступления средств - во-первых, какие-то банковские реквизиты документа нужны. А во-вторых, поступления с заказами, поставками, продажами никак не связаны?

В поступлении буду фиксировать поступления средств, а по контрагентам буду искать продажи и формировать соответсвенно задолженность от которой и буду отнимать поступления, составляя отчет по задолженностям на данный момент.
Cane Cat FisherЧто такое СПЧ_Статус?

Это уже переделал в Статус_заказа (в производстве, отгружен, закрыт и т.д.). Спасибо за помощь!

Помогите пожалуйста, вот еще с каким вопросом. Отчет "Себестоимость заказа"
Никак не пойму как записать формулы. Как раньше было - есть заказ. в нем по позициям размеры и вид продукции, на каждую позицию считаем расход материалов (всех что нужно) по формулам. Затем умножаем на цену и получаем итоговую стоимость. Вот как на рисунке:
[IMG] http://i24.fastpic.ru/big/2011/0707/17/e30ccb7d5d5e6f82ccf441b4c8e25117.jpg [/IMG]

Как теперь быть? Как и где теперь записывать эти формулы?

Cane Cat FisherНу, это несложно.
СправочникБригад(
БригадаИД PK
БригадаНомер (или Название, как их там различают)
СоставБригады
БригадаИД FK --> СправочникБригад
СотрудникИд FK --> СправочникСотрудников
UNIQUE(БригадаИД, СотрудникИд)
Бригадира можно определить двумя способами. Первый - в СправочникБригад добавить СотрудникИд_Бригадир FK --> СправочникСотрудников. Но тогда придется дополнительно (триггерами?) следить, чтобы бригадир входил в Состав своей бригады. И будет интересный момент при создании бригады: в ее состав надо будет сразу сажать бригадира.
Второй - в СоставеБригады сделать логическое поле "Бригадир". Тогда придется следить, чтобы в бригаде был ровно один бригадир.
Кстати, может и не нужно заморачиваться с такими жесткими ограничениями? Ведь может быть такая ситуация, что бригада вообще без бригадира, хотя бы временно?

Да, бригадира делать не буду. Но я никак не пойму что такое UNIQUE - в смысле два уникальных ключа БригадаИД, СотрудникИд?
Вот так надо было сделать?
[IMG] http://i25.fastpic.ru/big/2011/0708/59/5f9411d6fd4e6c6f3ad3849a559cd759.jpg [/IMG]
Если да, то непонятно как это будет работать, ведь в одной строке таблицы "Производство" будет указано только название бригады и фамилия сотрудника... Не понятно.
Cane Cat Fisherто неправильно. Представьте, что по контрагенту принято сразу три заказа по 100 руб. И он оплатил 100 руб. Какой из заказов пускать в производство?
Оплачивается всегда конкретный счет. Даже если непонятно, какой из заказов оплачен, привязку можно сделать вручную, условно к одному из заказов, или поровну между заказами, но привязка должна быть обязательно. Общая сумма задолженности - это не единственная нужная информация. Из нее всегда следует вопрос "а за что конкретно недоплачено?"

Ага. Сделал.
Cane Cat FisherТеперь надо запросом выбирать заказы, детали заказа, увязывать их с единицами продукции, вытаскивать цену каждой единицы продукции, и это и будет полная спецификация со стоимостью в каждой строке, а итог - общая сумма. Тут база данных достаточно хорошо построена.

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

Cane Cat FisherНет, это один уникальный ключ, содержащий два поля. Чтобы уникальной была их комбинация. Чтобы работник не мог войти в одну бригаду дважды. (Кстати, такая конструкция допускает, что работник может входить в несколько бригад - это действительно так?)

Насколько я понял такой ключ создается так
ALTER TABLE [Test].[dbo].[Состав_бригады]
ADD CONSTRAINT ID_UN_Бригада UNIQUE (ID_Сотрудник, ID_Бригада);
Следует ли мне в таблице Состав_бригады, сначала определить ключи ID_Сотрудник и ID_Бригада как PK (как на рисунке в превыд. посте), а затем на их основе создать UNIQUE ключ? Или они существуют в таблице как FK а например ID_UN_Бригада как РК и как UK? Никогда не сталкивался с такими ключами, поэтому так много вопросов.
Далее у меня в таблице Спецификация_продукции также в одной спецификации используется несколько материалов, мне следует поступить также как и случае с сотрудниками входящими в одну бригаду?
И работник не может входить в несколько бригад.
Cane Cat FisherА "Производство" (кстати, что это в реальной жизни? Какой документ?) возлагается на бригаду в целом, или на отдельного сотрудника? Вот соответственно одно из полей надо оставить.

Что-то типа журнала где фиксируется что делали, когда и кто. Возлагается на бригаду в целом. Оплата труда сделочная поэтому потом считает объем заказа и начисляем по расченкам уже каждому сотруднику бригады оплату труда.
Cane Cat FisherНапример, считаем себестоимость указанного заказа (это себестоимость всей продукции по всем деталям):
SELECT SUM(ДеталиЗаказа.ПлановаяСебестоимость) FROM ДеталиЗаказа JOIN Продукция WHERE ID_Заказ =

Т.е. я могу скажем написать так SELECT (Колонка1 * Колонка2 / Колонка3) FROM и т.д.?
Спасибо!