bald56rus, на схеме у вас таблиц несколько больше, чем в водном сообщении. Не совсем прозрачно их назначение.
Отмечу первые два момента, бросившиеся в глаза.
1. не совсем понятно, с чего в Equipments участвует поле UnitId
Связь подразделение - конкретный девайс у вас вроде как реализована через заявки. Если Equipments - конкретный девайс - мое мнение, он должен быть "отвязан" от подразделения. В противном случае может сложиться ситуация, когда в Equipments указано какое-либо подразделение, а соотв. заявки на это нет - несогласованность данных.

2. Что такое "StatesEquipment" . Если статус оборудования, который может меняться опять же путем заявки, то не логичнее ли привязать статус к конкретной заявке, дабы понимать почему данный статус изменился.

3. Ну и в догонку - всегда одна заявка - "одно оборудование"? Нельзя в рамках одной заявки "переместить" два-три -десять девайсов?

bald56rusтут имеется ввиду подразделение за которым закреплено оборудование;
Оборудование закрепляется по заявке? Или эта система отслеживает только заявки на ремонт?
Оборудование может быть перемещено между подразделениями? Необходимо ли учитывать "историю" движения оборудования по подразделениям?

bald56rusесть некий парк оборудования который обслуживается(выполняется ремонт) т.е. при поломке оборудования заводится заявка, оборудование переводится в нерабочее состояние, при закрытии заявки указывается текущее состояние оборудования.
Логично тогда статус привязать к заявке или к истории заявки. Дабы потом можно было восстановить картину - почему и когда статус изменился.

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

bald56rusданная система первоначально задумывалась как система учета и дальнейшего анализа технического состояния оборудования.
На мой взгляд, в таком случае странно "смешивать" в одной таблицы статические и динамические параметры сущности.
Можно внедрить понятие "последнее значение параметра" (к примеру, последнее подразделение, в котором числиться данное оборудование) = если предполагается интенсивная работа с базой/многократные чтения и т.п.

Но тут необходимо знать вашу специфику и предполагаемую нагрузку на приложение.

bald56rusParameters это справочник возможных параметров(состояние, подразделение ну и т.п.) в ValueParameters фактические значения параметров со ссылкой на оборудование.
Mikle83 можешь подсказать насколько это правильно
Вполне жизнеспособный подход. Только почему связь ValueParameters -E Equipments ? По идее, наоборот: один девайс - много параметров.

Я бы подумал в сторону сущности "Список параметров" ( ListOfParameters ), который в итоге прикручивался бы к конкретному оборудованию (типу оборудования?).

Т.е. связь примерно такая:
Parameters (Id) -E ListOfParameters (Id, Param_Id, Mandatory, DefaultValue).
В TypeEquipments добавляется поле типа ListOfParameters_Id .

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

Так же вопрос- надо ли вам отслеживать историю изменения параметров? Если да - нужна таблица типа History для значений.
В основной таблице значений - появляется поле UpdatedTime.


bald56rus насчет нагрузки до 10000 заявок в год(исходя из предыдущего года) пользователей которые это будут делать не так много регистрация и сопровождение в системе не больше 20(думаю это будет максимум) не планируется.на основании этих данных формирование различных отчетов(типа время простоя, наличие одинаковых заявок по одному оборудование в период ну и т.п.)
Не вижу ничего критичного в таком объеме заявок для выбранной модели
как ранее было сказано 1 заявка = 1 девайс. При этом явно количество девайсов будет меньше 10000.
Пусть будет 5000 (т.е. один девайс в среднем два раза в год попадает в "заявку") => у вас 5000 записей в таблице Equipment, пусть у каждого девайса 20 параметров (сильно сомневаюсь, но пусть) => 100 000 записей в таблице значений параметров. Ни о чем для СУБД.
При этом эта часть БД будет в большей степени статична, т.к. насколько я понимаю - большинство параметров статичны или редко изменяются.

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

Исходя из 10000 заявок в год, пусть на каждую по 5 статусов заводится - смысла в оптимизации структуры за счет введения поля "текущий статус" для заявки - я лично не вижу.

По таблицам вопрос - что такое StateRequest и StageRequest ? В чем разница?

В Request - поле Author - как будет заполняться? Это, видимо, какой-то определенный сотрудник? Инфа о нем есть в базе? Если да, то стоит добавить ИД сотрудника, если заполнять предполагается в ручную => про полезность поля можно забыть. Никакого анализа по "авторам" построить не удастся.
Так же не понятно, что делает поле телефон в таблице запросов? Почему его не подтягивать из отдела?

И поле Closed так же странно выглядит - если ввели отдельную сущность "статусы обращений", то Closed - это один из статусов.
В противном случае может быть несогласованность данных = заявка в статусе "закрыта", а в истории статусов с ней никто ничего не делал.

bald56rusпо поводу же заявок:
StateRequest - это состояние заявки (Открыта/В работе/Закрыта);
StageRequest - это этап выполнения(Диагностика/Поиск и закуп запчастей)
поясню как я это представляю ....
Так и не понял, что мешает заявке последовательно пройти
"Открыта -> В работе -> Диагностика -> Поиск и закупка -> Закрыта"?
и зачем два справочника. Что будет, если State = Закрыта, а Stage = Диагностика?

bald56rusClosed это ничто иное как дата закрытия заявки(точнее так дата которую может указать диспетчер
В смысле - планируемая дата закрытия заявки?

bald56rusесли вдруг фактическое закрытие по какой то причине не сделали своевременно(по заявкам ведется статистика по времени выполнения разница между полем Registered и Closed)
Хм. Некоторая избыточность есть.
У вас есть статусы заявки. Логично вычислять именно по разнице в датах присвоения статусов "Открыта"/"Закрыта".
Так же можно выводить среднее время, которое требовалось на диагностику/поиск закупку и т.п. = простор для аналитиков :)

bald56rusт.е. закрытие может произойти в момент когда диспетчера фактически нет, он отработал и ушел а оборудование починили спустя 2 часа.
Мне кажется это два отдельных статуса. Что-то типа принципа "4 глаза".
После завершения ремонта заявка переходит в статус "ремонт завершен"/"оборудование передано заказчику и т.п.". А диспетчер уже утром закрывает окончательно заявку, тем самым подтверждая этот статус, к примеру, предварительно позвонив заказчику и убедившись что "все хорошо". Или наоборот - отправляет заявку "на доработку"/заводит новую заявку если есть нарекания со стороны заказчика.

А закрывать "задним числом" - не советую. Быстро поймут как надо "правильно" закрывать заявки, тем более, если на время выполнения будет завязана премия или зарплата.

P.S.: я надеюсь у вас один часовой пояс? :)