Прошу помощи в проектировании БД (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 - ну пускай будет прайс, только цен там нет и не планируется (уж очень плавающая позиция - некому отслеживать)
спецификация - нет такого чтобы отдельно заказ шел одному, отдельно другому. Все проще. По какому-то объекту строительства перечисляется все оборудование которое нужно заказать и оформляется в виде документа "Спецификация". Посчитать цену это задача отдела смет... ну как бы это совсем другая песня, хоть и можно подумать над дальнейшем расширением функционала.
спецификацияСостав - я думаю это должна быть одна таблица Спецификация. А вот насчет удаленной позиции я и написал - тут надо отслеживать дату редактирования. Причем именно дату - пользователю может и не нада дата редактирования записи, а вот Редактору БД может пригодиться. Например одна и таже запись может редактироваться несколько раз. И нужно знать когда ее редактировали а не то что ее вообще редактировали.

т.е. "Спецификация состав" это некая промежуточная таблица (временная) используемая как буфер? Что-то я запутался совсем

ПЕНСИОНЕРКАуверена, что спецификаций не одна, а много на 1 объект

Ну конечно не одна.
Спецификация постового оборудования изделий и материалов
Спецификация напольного оборудования изделия и материалов
Спецификация кабельной продукции
Спецификация запасного имущества
Еще бывают несколько типов но крайне редко. Но это все по структуре одинаковые спецификации - только штамп разный.

В общем ночь большая сегодня попробую посидеть в SSDT что-то накидать на что мозга хватит - будет картинка - можно будет что-то корректировать.

Вопрос несколько не по теме:
Стоит ли заморачиваться на названиях БД, таблиц, запросов в плане русских букв и пробелов? Программа не планируется для "не русскоговорящих". БД проектирую в SQL Server 2014 Express. Программу в MS Visual Studio 2013

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

Таблицы:

Заводы-изготовители [Manufactures]
Имя столбца Тип Описание ID_Manufacturer int Идентификатор завода-изготовителяName nvarchar(50) Краткое наименование завода-изготовителяDescription nvarchar(MAX) Описание завода-изготовителя (адрес)Logo image Логотип завода-изготовителя
Единицы измерения [Measure Units]
Имя столбца Тип Описание [ID_Measure Unit] int Идентификатор единиц измеренияName nvarchar(10) Сокращение единицы измерения
Строка спецификации [Specification line]
Имя столбца Тип Описание [ID_Specification line] int Идентификатор строки спецификацииID_Equipment int Идентификатор оборудованияCount float Количество заказываемого оборудования[User note] nvarchar(MAX) Примечание
Спецификация [Specification]
Имя столбца Тип Описание ID_Specification int Идентификатор спецификации[ID_Specification line] int Идентификатор строки спецификацииID_User int Идентификатор пользователя[ID_Specification type] int Идентификатор типа спецификации[ID_Specification status] int Идентификатор статуса спецификации[Object number] nvarchar(30) Номер объекта строительства[Construction project] nvarchar(50) Объект строительства (название станции или перегона)[Object name] nvarchar(300) Наименование объекта[Save date] date Дата последнего сохранения
Пользователи [Users]
Имя столбца Тип Описание ID_User int Идентификатор пользователяName nvarchar(100) Фамилия И.О. пользователяPassword varchar(10) ПарольID_Account int Идентификатор учетной записи
Учетные записи [Account]
Имя столбца Тип Описание ID_Account int Идентификатор учетной записи[User account] varchar(20) Наименование учетной записи
Статусы спецификации [Specification statuses]
Имя столбца Тип Описание [ID_Specification status] int Идентификатор статуса спецификацииStatus nvarchar(20) Наименование статуса спецификации
Типы спецификаций [Specification types]
Имя столбца Тип Описание [ID_Specification type] int Идентификатор типа спецификацииType nvarchar(100) Тип спецификации (сокращенно)[Specification name] nvarchar(300) Наименование спецификации (для штампа)

Представления (связи):

Вот так будет представляться строка:

А вот так данные по спецификациям которые сделали пользователи:

Вот так общая структура у меня выглядит:
(сегодня наверно мой мозг взорвется)

Возникает у меня проблема с сохранением записей за конкретным пользователем.
Т.к. приложение теперь многопользовательское и база одна, то разумно предположить, что одновременно несколько человек будут добавлять свои записи в таблицу Specification line. Остается только закрепить конкретные строки за конкретным пользователем+еще кучу полей идентификации конкретной спецификации.

Сначала я думал сделать временный массив для каждого пользователя, который после набора определенного оборудования из таблицы Equipment catalog нажмет сохранить и весь массив скопируется в таблицу Specification line. Тогда в таблице Specification вместо поля ID_Specification line нужно два поля - начало и конец записи конкретной спецификации. Но тут возникает проблема когда другой пользователь запишет в таблицу Specification line свой диапазон записей вслед, а предыдущий решит добавить еще записей. Вобщем идея не катит. Ну не перелопачивать же все записи, двигать там и пр...

Следующая идея хранить в таблице Specification в поле ID_Specification line список записей (ID_Specification line из таблицы Specification line) пользователя. Тогда всё равно где находится запись. Единственное меня смущает, если пользователь удалит запись(и) и в таблице Specification line образуются "дыры". Другому пользователю я не знаю как "сообщить" про "дыру" в таблице, чтоб он туда писал. Со временем "дыр" может стать больше чем записей, т.к. процесс формирования спецификации пользователем дело долгое с постоянными правками.

Возможно несу ерунду, и все можно решить гораздо более практично. Прошу подсказать что делать

Насчет идей хранения... это я ступил, сознаюсь:) Переделал как рекомендовали. Даже понравилась проделанная работа! Красиво и наглядно. Мне уже нравится работать в Managment Studio.

Вот только я не понимаю насчет одинаковых полей. Для примера напишите хотя бы несколько как например можно было бы именовать их.
И насчет проблем с полями типа bit недопонял. У меня все прекрасно работает... Редактор БД будет ставить птичку если оборудование снято с производства. Возможно потом сделаю розовую подсветку строки, если оборудование снято с производства - для большей наглядности.

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

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

Насчёт "Сущность объект строительства":
Мне кажется достаточно описания в таблице Specifications, хотя под один объект (номер объекта, наименование объекта, объект строительства) может быть от 1 до 5 спецификаций. Может и стоит сделать отдельную таблицу под объект...

ПЕНСИОНЕРКА, П-Л,
Спасибо за замечания!

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

Ну вот вроде бы понимаю, что можно каждую запись "пометить" тем пользователем который ее добавил, только не понимаю зачем это надо.
У одной спецификации может быть только один разработчик. Этот разработчик может переложить свою работу на другого пользователя или это может сделать администратор (пользователь заболел например). Т.е. в таблице Specifications просто смениться ID_User.

Имена полей немного поменял (по своему вкусу) с учетом рекомендаций. ID вначале имени мне привычнее. Поля с "неоднозначными" именами (в том числе и повторяющиеся) name, user сменил на более информативные.
Имена таблиц мне кажется должны быть во множественном числе.

Постоянно консультируюсь с будущими пользователями... чую курсовой в диплом перетечет. Сразу столько "хотелок" я не ожидал.
Например в формируемую таблицу нужно будет добавлять поля не из каталога. Причем и нумерацию строк надо будет сделать с учетом этой строки.
А добавлять надо строки:
ОБОРУДОВАНИЕ:
ИЗДЕЛИЯ И МАТЕРИАЛЫ:
<Пользовательская строку>:
Это своего рода разделитель в общем списке
Ну и нумерация соответственно:
1 ОБОРУДОВАНИЕ:
1.1
1.2
1.3
1. ...
2 ИЗДЕЛИЯ И МАТЕРИАЛЫ:
2.1
2.2
....

Сейчас соберу мозги после взрыва :)
Честно говоря не понимаю зачем эта иерархическая структура. Можно поподробнее что Вы имеете ввиду и как это должно выглядеть применительно к моей базе.

Еще вопрос такой. Вот я задал размер некоторых полей 30, 50, 150 и т.д. Вот вроде бы с запасом от 20% до 200%. А вот если случится беда и как выяснится неподрасчитал и нужно потом увеличить? Как я понимаю это довольно большая проблема для клиентского приложения. Если я поля сделаю все MAX или все увеличу до больших размеров так чтобы наверняка, чем это плохо?
Понимаю, что ламерские вопросы, но все же.