Здравствуйте.

Помогите пожалуйста определиться со структурой базы данных. Давным давно еще в универе занимался базами данных, что-то простенькое делал, но сейчас вообще ничего не могу вспомнить. И разобраться что от чего зависит, и какие таблицы нужны не получается. Мозги не так устроены. :( А очень надо, зашиваюсь на работе ... без базы данных видимо никуда.
Задача следующая:
Необходимо разработать базу данных ремонтного предприятия по ремонту … ну допустим автотехники. В базе данных должны быть реализованы следующие функции:
Регистрация поступившей в ремонт техники автомобиль/агрегат автомобиля, тип автомобиля, модель автомобиля, заводской номер автомобиля/агрегата, дата изготовления, поступает в ремонт в(о) … раз, дата начала ремонта, дата окончания ремонта, тип ремонта (капитальный, средний, техобслуживание) ну и прочее.
Регистрация материальных ресурсов (материалы, ГСМ, запчасти) фактически затраченных на рем онт, их стоимость, обоснование стоимости (счета-фактуры, договора на поставку, пр). Должна быть предусмотрена возможность выбора цены материальных ресурсов из списка цен обоснованных какими-либо документами, или же просто возможность прослеживать динамику изменения цен, т.е. все данные по ценам сохраняются.
Сравнение с нормативными (плановыми затратами) с выделением каким-либо образом затрат превысивших норму (например цветом). Соответственно возможность вносить изменения в планируемое количество материальных ресурсов на ремонт.
Выдача отчетов:
Подробный отчет о расходе материальных ресурсов на ремонт автомобиля/агрегата с разбивкой по типам материалов ( ГСМ, текстильные материалы, стали, пр), типам и принадлежности запчастей (например менялась запчасть в двигателе, другая в трансмиссии третья еще где либо), а так же по ремонтным бригадам – какая бригада конкретно устанавливала запчасть.
Выдача планируемых затрат ... норм расхода на ремонт того или иного автомобиля/ агрегата.
...С остальным пока не определился, но если бы сделать структуру хотя бы для того что уже описал - это решило бы большую часть проблем.

Еще буду очень признателен если порекомендуете хорошую литературу по базам данных. Конкретно интересует не столько среда (вообще собираюсь работать в MS Access 2007) сколько сам процесс проектирования, с упражнениями от простого к сложному. Так что бы прочно, на практике усвоить принципы проектирования баз данных. Пока даже понять толком какие поля являются принадлежностью сущности, а какие должны быть выведены в отдельные таблицы не получается.

это полувоенное предприятие, никто никаких денег на подобные системы не выделяет. Вообще всем по барабану как и чего я там считаю, но результа дай. А не дашь по башке настучат быстро. :( В экселе замучился считать и двадцать раз одно и то же пересчитывать - не катит. Плюс хочется автоматизировать многие моменты (ну как с выделеним нужных данных цветом например - автоматически, сверки фактических показателей с плановыми - дабы не лазить по всем имеющимся таблицам экселя сверяя сколько болтов деревянных должно уходить на ремонт двигателя, и сколько использовано по факту, при том учитывая массу факторов как например тип римонтируемой техники, военная она или гражданская, агрегат это или целый автомобиль). Да и просто что бы была более менее четкая и понятная структура, а не отдельными табличками там сям. Хочу сделать базу данных не для какого-то полноценного бизнеса, а для облегчения своей работы. Так что никаких особых изысков не надо.

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

в компах не совсем чайник. Когда то программировал, делал программы в Делфи, на ассемблере тоже проги делал. Access тоже пытался освоить, несколько раз, но терпежу не хватило - проблемы всегда были с тем что бы четко и конкретно спланировать и поставить задачу. Просто мог писать примерно представляя чего хочу, последовательность процедур, функций и их выполнение. Объектно-ориентированное программирование не освоил. Базы данных чем то по идеологии похожи - тоже не освоил. Потом бросил все это дело. Сейчас вижу что зря, в моей работе не однократно уже базы данных пригодились бы, так что планирую таки освоить.

П-ЛТем не менее, ваша постановка ТЗ тянет на полноценную учетную систему. Таблиц должно быть несколько десятков. У вас впереди долгий путь, его можно пройти, но напрягаться придется сильно.

Подпись: Инженер-конструктор.

До полноценного ТЗ не хватает, сам толком еще понять не могу во всех подробностях чего хочу. Это скорее генеральная линия. И да так и есть, уже из того что ручкой на бумажке начеркал - таблиц более десятка вылезает. Потом начинается путаница со связями и вообще с пониманием что должно входить в ту или иную таблицу.

через долгие мучения с тем куда запихать цену (то ли в материалы, то ли в счет фактуры) пришел например к этому:
таблица материальные ресурсы с полями:
ИД_ресурса
код ресурса //принадлежность к группам - материалы, гсм, запчасти
наименование
обозначение
ед. измерения

таблица обоснований цены
ИД_обоснования
наименование документа
номер документа
дата докум
принадлежность к военн
примечание

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

Пробовал отработать в Access только эту часть базы данных ерунда какая-то получается. Данные вводятся только в две из таблиц и нет возможности выбора из таблицы материальных ресурсов сразу нужной счет фактуры только цены не понятно к чему относящиеся. Впрочем я и не делал полноценной программы и форм. Просто таблицы и связи. Пока задачи создания форм еще не стоит. С правильной структурой бы определится, а там уже другие задачи решать буду.
Может порекомендуете какие-то примеры из близкой области - с ремонтом, с обоснованиями цен счет фактурами (или другими документами).

П-ЛВам не потребуется будет хранить информацию о составе изделий (автомобилей) по агрегатам и деталям и агрегатов по суб-агрегатам и деталями ? Если да, то вы попадаете на деревья и их обработку.


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

П-Л Берясь за новый проект я бы сразу выбрал чуть другой вариант - аксес adp + Ms SQL сервер. С джетом (mdb) не стал бы связываться из-за дикого неудобства программирования запросов и отсутсвия серверных процедурю
Чем хорош MS SQL сервер? ... Мне как чайнику освоить бы пока само проектирование и создание базы данных, и реализация ее в acces. Базу данных не планируется делать сетевой. Все будет на одном компьютере. ... Ну хотелось бы конечно и сетевую, да боюсь харя от напряжения треснет... :) Не все сразу, это скорее как отдаленная цель максимум.

П-ЛТ.е. мельчайшая единица - агрегат. Из агрегатов состоят изделия. 1 Агрегаты не могут включать другие агрегаты ?

2 Нормы материалов на ремонт агрегатов есть ?
3 Какое отношение имеют материалы к агрегатам ?
4 Материалы могут быть использованы на ремонт всего изделия в целом, без указания агрегата ?

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

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

Порекомендуйте какую-нибудь хорошую литературу по базам данных пожалуйста.
Сейчас изучаю "Проектирование баз данных. Просто как 2х2" Шпак Ю.А.
http://books.iqbuy.ru/categories_offer/9785699241323/proektirovanie-baz-dannyh-prosto-kak-dvazhdy-dva-shpak
Мне кажется этого маловато. То есть там есть хорошие примеры, но для поставленной цели описанного мало мне кажется. А в магазинах лежат талмуды с подробным описанием какую кнопочку нажать мышкой, при том совершенно не уделяя внимания проектированию как таковому. Не люблю такие талмуды. Лучше бы что-то с массой практических примеров и разборов.

П-ЛПодумайте и решайте насчет версии аксесс и связки с sql сервером.
Трудно решать когда еще очень смутно представляешь себе о чем речь. Это как кота в мешке покупать. Видимо придется прежде еще литературку по MS SQL сервер приобрести, пролистать.
Вопрос чисто для информации - сколько будет стоить разработка подобной базы данных если ее заказать кому-нибудь на сторону? Я правда довольно смутно себе представляю как это все может происходить. Все же лучше быть самому разработчиком, потому как знаешь, что и где и почему нужно и всегда можешь поправить если что не так, а какие то идеи могут и в процессе разработки возникнуть. Уж не говоря о том что навык проектирования баз данных наверняка не раз еще пригодится.

vill_ager,

Вы будете смеяться, но именно такая задача мне руководством и поставлена. Веду параллельный учет - со своими дополнительными данными. В расчетной группе ведется полноценный учет с использованием нормальной базы данных. (правда интерфейс как под дос). А я парюсь табличками ексель. И план/факт проверять чуть не основная моя задача. Почему и возникла идея о своей БД. Ту что в расчетной группе стоит я вряд ли смогу использовать, да и не все там данные что мне нужно. Как пример нет принадлежности деталей к тем или иным агрегатам, нет разбиения по группам материалов. Тем не менее данные из их базы данных я планирую использовать, через промежуточный файл ексель импортировать в свою. Например данные по приходу - материалы, счет фактуры и пр.

ARTURV,

Быстрее меня уволят чем еще кого-то возьмут. Это военные. При чем не просто военные "элита" можно сказать. Кто с такими работал - поймет. Надо быть кроликом из рекламы энергджайзер - только без батареек. Жалеть меня не надо (лучше помогите ;) тут все так впахивают. До меня несколько человек нормы эти считали. Тупо вручную, даже с калькулятором. Не выдержали. Моих знаний хватает что бы делать больше и быстрее. Но у меня и помимо того задач хватает. Хочу максимально упростить себе эту работу. Кроме того мне просто интересно, так как необходимость в своей БД ощущалась не раз и на других работах.