Прошу помощи в проектировании БД (MS SQL).

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

Вся сложность которая меня ставит в тупик это то, что у меня в БД нет, в принципе, (многократно) повторяющихся значений в записях, кроме завода изготовителя. Поэтому пока я представляю БД только двумя таблицами.
таблица [Main]
поля:
[ID]
[Name]
[Type]
[code]
[Key_Manufacturer]
[ed_izm]
[Weight]
[Dimension]
[Description]
[Date]
[Note]
[Image]

таблица [Manufacturer]
поля:
[Key_Manufacturer]
[Name]

Еще будет повторяться [ed_izm] (единицы измерения) - кг, тонн, литры, метры, километры и т.д. Но мне кажется проще вбивать руками текст и хранить текстом... хотя не знаю. Ну пусть будет 3 таблицы.

В главной таблице [Main] у меня получится не более 1.000.000 записей. В таблице [Manufacturer] не более 50 записей.

Стоит ли делать БД из 2-3 таблиц? Или проще все в одной сделать и не париться?

Дополнительно могу сказать про особенности записей:
Разные заводы могут делать одинаковое оборудование.
Почти все значения в таблице [Main] могут повторяться но не более 100 на 1M.

Отдельно хочется сказать про запись в файл (думаю xml). Выбранные записи в БД нужно будет формировать в спецификацию (в том же приложении где и будет выводиться БД. Я думаю, что проще это будет сделать по позиции [ID]. И хранить в файле просто этот [ID] + количество заказанного оборудования (отдельное поле).

Прошу помочь дельными советами в проектировании БД!

Я и есть зеленый новичок - не скрываю.

Measure Unit - принял!

Тогда делать надо 3 таблицы:
таблица [Main]
поля:
[ID]
[Name]
[Type]
[code]
[Key_Manufacturer]
[Key_Measure_Unit]
[Weight]
[Dimension]
[Description]
[Date]
[Note]
[Image]

таблица [Manufacturer]
поля:
[Key_Manufacturer]
[Name]

таблица [Measure_Unit]
поля:
[Key_Measure_Unit]
[Measure]

Данная работа это мой курсовой проект. Кому нравится и кому будет приятно - можно шутить, глумиться, показывать свое ЧСВ. Я не обидчивый.

Моя цель прежде всего научиться делать БД. Не для корочки в ВУЗе. Заказывать у спецов не буду однозначно. Программа будет реально работать на производстве.

Спасибо за понимание.

П-ЛСНАЧАЛА изложите коротко назначение, функциональные требования - что ваша база должна мочь.
Я думал первого поста будет достаточно... Возможно что-то не учел...

Задумка такая:
Пользователь ищет по части наименования [Name] нужное оборудование. В таблице должны вывестись варианты (может делают несколько заводов, или есть разные исполнения). Далее пользователь выбирает нужную запись и добавляет ее в свою таблицу (спецификация), где потом только указывает количество. После того как спецификация сформирована - делает экспорт в Word.

П-ЛНу и схему бд лучше выкладывать графическую. Еслиб я умел. Но я готов учиться, так-что не подумайте, что я спрыгиваю :)

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

Сейчас я после всех "рекомендаций" несколько растерялся и не знаю с какой стороны подступиться.

Пока я в Visual Studio уже слепил некое подобие вьвера БД (C#). Там же сделал в SSDT БД и две таблицы. Но они не связаны (не умею пока). Готов все нафик удалить и начать заново.

Давайте по порядку. Что сделать первое? Я выполню - покажу результат. Понятное дело, что вот прям все сразу все Ваши рекомендации я не выполню. Хочется последовательности.

Спасибо за понимание и терпение!

Хоть примерно понял, что Вы от меня хотите добиться:) В любом случае вся эта текстовка/описание пойдет для курсовой в пояснительную записку.

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

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

Требования к системе
Система должна обеспечивать:
-поиск необходимого оборудования в БД по всем полям
-вывод результатов поиска в виде таблицы со всеми характеристиками оборудования
-многоуровневый доступ: "Администратор", "Редактор БД", "Пользователь"
-редактирование БД средствами системы
-создание таблицы спецификации
-добавление выбранного оборудования в спецификацию
-сохранение и последующее открытие сформированной спецификации
-многодокументный режим с возможностью копирования записей из одной спецификации в другую
-экспорт спецификации в Word

Оборудование в системе должно быть представлено для пользователя следующими полями:
-Наименование оборудования - текстовое поле до 200 знаков
-Тип, марка, обозначение - текстовое поле до 50 знаков
-Код оборудования - - текстовое поле до 50 знаков
-Завод изготовитель - - список (отдельная таблица) не более 50 записей
-Единицы измерения - - список (отдельная таблица) не более 20 записей
-Масса (кг) - - float поле до 10 знаков
-Габаритные размеры - текстовое поле до 30 знаков
-Снято с производства - bool checkbox птичка установлена - снято с производства. Как отображать под вопросом еще.

-Изображение Будет отображаться не в таблице (на форме в углу)

Спецификация должна соответствовать ГОСТ (потом поищу какой - там все поля строго именованы и расположены)
В таблице "Спецификация" поле "Количество" должно редактироваться пользователем.

Редактирование каталога оборудования (БД) осуществляет пользователь "Редактор БД". Система должна обеспечивать контроль добавляемого оборудования на полный повтор записи.


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

авторИз приведенных данных видно, что оборудования довольно много. Удобно с ним работать в виде плоского списка ? - Да удобно. Пользователь например ищет оборудование "светофор" по полю "Наименование"- ему должно вывестись в той же таблице все записи содержащие данное слово. Модификаций может быть около 100. Затем он фильтрует то что найдено задавая критерии поиска в других полях. Например Завод-изготовитель. Одно и то же оборудование может делать несколько заводов. (очень врядли будут искать оборудование по другим полям). Может быть в очень редких случаях пользователь будет искать оборудование по коду изделия.
авторНаименование, технические характеристики почему склеены вместе ? - Так и должно быть. В таком виде спецификация передается заказчику (типа стандарт). Разбивать нет смысла.
авторНужна классификация/каталогизация ? - Думаю нет. Я хорошо думал над этим :) не получится, да и не нужно.
авторЧто такое код оборудования ? - просто текстовое поле. Оно и из цифр и из букв и из точек с прочерками и возможно даже с национальными символами. Пользователь может по нему искать оборудование. Может повторяться.
авторНужно вести учет оборудования в количественном исчислении ? Может оборудование пакетироваться (одна упаковка в общей таре - 12 шт. единиц) ? Нет. В БД не нужно. Количество указывается уже в спецификации.

авторСобранные спецификации имеют какой-то жизненный цикл (новая, черновик, готова, обработана, исполнена) ? Надо хранить историю обработки спецификаций ?
Ну как бы нет... Черновик - это то что сохранили файл. Готово это то что экспортировали в Word. Специальных статусов нет. Вернее они есть но это задача системы документооборота - это она определяет статус файла/объекта .

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

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

ПЕНСИОНЕРКАтогда можно предположить, что
ваша mainэто огромный прайсспецификация заказ с полями кому/дата/наименование/составитель .....спецификацияСоставвыбранные из прайса позиции, причем если из прайса удалили, то добавлять в комментарий сообщение об этом ,периодически выдавать отчет строк, которых нет в прайс
main - ну пускай будет прайс, только цен там нет и не планируется (уж очень плавающая позиция - некому отслеживать)
спецификация - нет такого чтобы отдельно заказ шел одному, отдельно другому. Все проще. По какому-то объекту строительства перечисляется все оборудование которое нужно заказать и оформляется в виде документа "Спецификация". Посчитать цену это задача отдела смет... ну как бы это совсем другая песня, хоть и можно подумать над дальнейшем расширением функционала.
спецификацияСостав - я думаю это должна быть одна таблица Спецификация. А вот насчет удаленной позиции я и написал - тут надо отслеживать дату редактирования. Причем именно дату - пользователю может и не нада дата редактирования записи, а вот Редактору БД может пригодиться. Например одна и таже запись может редактироваться несколько раз. И нужно знать когда ее редактировали а не то что ее вообще редактировали.