wordДумаю указать это в форме заявки, т.е сделать отметку о осмотре техники мастером и вынесении им вердикта о необходимости того или иного ремонта..
Я бы определил сначала несколько справочников:

"Сотрудники" :
1. ID сотрудника
2. ... должность, необходимые реквизиты, фамилия, телефон, ЗП, почасовая ставка

"Клиенты"
1. ID клиента
2. ... ФИО, телефон, прочее

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

"Объект ремонта" (в отличие от справочника модели, здесь сидит все, что касается конкретного объекта)
1. ID объекта
2. ID модели - внешний ключ на "Модели объектов"
3. ID клиента - внешний ключ на "Клиенты"
4. дата продажи либо начала гарантийного срока
5. серийный номер

далее нужно ввести журнал действий с объектом:

"Журнал действий"
1. ID операции
2. дата и время операции
3. ID объекта - внешний ключ на "Объект ремонта"
4. ID сотрудника - внешний ключ на "Сотрудники"
5. Тип операции - преднастроенный список видов операций (приемка, первичный осмотр, заказ запчастей, приход запчастей, ремонт, выдача)
6. Потраченное время
7. Описание операции - претензии клиента, выявленные проблемы, диагноз, особенности ремонта


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

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

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

Спасибо большое за помощь)
Вот что получилось(в прикрепленном файле)...Правильно ли я сделал что id-шники внес в эту ненормализованную таблицу? или их нужно было вводить уже вовремя нормализации, т.е выделяем,например, отношение сотрудники и определяем его id ключом..
Ну а если все так, то теперь необходимо доказать теорией, справедливость именно такого разделения таблиц, т.е выявить ключи и зависимости...Вот в этом ненормализованном отношении первичным ключом будет Id_операции? И тогда данное отношение находится во 2НФ, т.е каждый неключевой атрибут полностью зависит от первичного ключа...Или я неправильно рассуждаю? И как тогда быть с 3НФ...

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

Вот как-то так, своими словами, умных слов чего-то уже не помню. Надеюсь, я вам помог.

Пролистал тут немного теории, кое-что вспомнил вроде. В ненормализованной таблице у нас есть в наличие транзитивные зависимости A → B и B → C, где A — набор ключевых атрибутов (ключ), B и С — различные множества неключевых атрибутов. То есть id-операции определяет id-клиента (в качестве которого может быть номер паспорта, если он его конечно даст записать), а уже id-клиента определяет такие атрибуты как ФИО, тел, адрес. Выводя эти транзитивные зависимости в отдельные таблицы, мы приводим базу к 3NF. В 2NF транзитивные зависимости возможны, там есть лишь ограничение на зависимость неключевых атрибутов от части составного ключа. Так как у нас в "ненормализованной" таблице ключ не составной, и она находится в 1NF, то и 2NF у нее тоже есть.

И пусть меня поправят теоретики, если я не так въехал в эти определения. :))

wordБлагодарю за помощь) Это получается id сотрудников, клиентов и тд, все-таки нужно вносить в ненормализованную таблицу?
Изначально в ненормализованной таблице они нам не нужны, ибо сами по себе в ней они не несут никакой информации. Однако когда мы задумываемся о нормализации и начинаем выявлять зависимости между полями, нам необходимо определиться, как мы будем идентифицировать выделяемые сущности. Мы можем ввести суррогатные ключи либо воспользоваться теми полями, которые у нас уже есть. Например клиентов и сотрудников определить через номер паспорта, использовать его в качестве ID сотрудника или ID клиента. Для определения объекта ремонта ID модели + "Серийный номер". Однако при этом нужно понимать, что естественные ключи подразумевают некоторые ограничения: если у клиента нет с собой паспорта или он состоит в секте и не хочет его сообщать или клиент - юр. лицо, тут возникают некоторые проблемы. Или сотрудник у нас джамшут-нелегал беспаспортный. Или номера моделей у разных производителей совпадают. Кроме того, такие данные могут изменяться по независящим от нас обстоятельствам и придется записи переименовывать.

То есть, Id-шники мы вносим в процессе нормализации, не раньше. Либо используем естественные ключи. Впрочем как правильно трактовать такие тонкости, зависит больше от ваших местных преподов, лучче у научрука уточнить. Или они у вас отсутствуют?