leshqow,
leshqowВ PowerDesigner тип данных "Directory" не нашел, создал сам Other -> Directory.
Не понял, о чем это.
leshqowНу тогда и подразделения тоже можно сделать справочником ?
Нет, это не справочник. Если хотите, можете добавить справочник названий подразделений. Что бы при вводе не было ошибок. Но, для вашей задачи это избыточно, и лишние вопросы.
По остальному:
Есть подразделение (отделы), в котором могут работать люди, а могут и не работать (нет пока их там, подразделение новое).
Но, у подразделения есть руководитель и реквизиты (как минимум, телефон) и штатное расписание, т.е. перечень должностей и количество единиц по каждой должности (3 бухгалтера, 2 экономиста и т.д.).
Сами должности - это справочные данные (
ОКПДТР 2018 ).
Значит, создав отдел, мы можем наполнить его штатными единицами на основании справочника должностей.
С подразделением всё.
Сотрудник:
Идентификатором любого сотрудника является его табельный номер, как правило, это целое число, это первичный ключ. Сюда же включаются все необходимы данные, которые могут быть только в единственном числе (ФИО, адрес прописки, например) и, по необходимости и не обязательным – фактическое место проживания и прочее.
Сведения об образовании – это важно.
Уровень образования – это отдельное поле (высшее, церковно-приходское и прочее), по этому атрибуту вполне вероятно будут фильтроваться запросы.
Описание самого образования (где, когда, направление и прочее), можно оставить в таблице «Сотрудники» - это для первичного образования (первичным считается то, которое дает последний самый высокий уровень, т.е. для инженера это будет ВУЗ, а не школа или техникум если такой имеется). Дополнительное образование (в том числе и предыдущее, если есть необходимость его учитывать) храним в отдельной сущности, с указанием: табельный номер, даты, тип обучения и прочее.
Дата приёма, должность (из справочника ОКПДТР), испытательный срок и прочее.
Аналогично и с остальными атрибутами (адреса, телефоны и прочее, например, родственники и т.д.) – первичное в таблице «Сотрудник» остальное в отдельных сущностях, конечно родственников в «Сотрудники» не храним, это отдельная сущность.
С человеком разобрались.
Эти две сущности, «Сотрудники» и «Отделы» пока никак не связаны, но по сути, уже готовы полноценно работать – это уже базы данных.
Теперь, привяжем «Сотрудники» к «Подразделения» = «Персонал»
Человек, который начал работать где-то, уже является персоналом.
Тут просто привязываем табельный номер и идентификатор штатного расписания.
Таким образом, у нас может человек и совмещать должности.
А контроль за соответствием количества вакансий и набранных на эти вакансии сотрудников осуществляется программно, т.к. это уже выходит за рамки нормализации.
Далее, если надо учитывать рабочее время, то учет ведется уже для персонала.
Специально описал повествовательно, что бы был понятен подход.
Очень важно строить модель по тому что хорошо понятно, фантазировать тут не стоит.
Нормализация – не самоцель, но, по сути, она решает вопросы избыточности, целостности и не противоречивости, просто описана математически.
Я думаю, из того что наговорил, у вас уже с лихвой перекроит требования преподавателя :)
Лучше сделать меньше – но качественно, чем много и ни о чем, прежде всего для вас, если Вам это интересно.
А коль проект учебный, то конечно что-то можно упростить, где-то нафанатазировать. Но не придумывать сказки, а из идеального мира.
Выше я дал возможный вариант, дополнить его атрибутами не сложно. Варианты могут быть разные, в зависимости от целевой задачи.
