всех приветствую, для начала )

есть задача:
вести учет програмного обеспечения установленного у пользователей в организации ( чтоб там не поднимать в конце каждого месяца бумажки, не искать на какой отдел затраты списывать, чтоб оперативно можно было сказать сколько пользователей того или иного ПО, не нужно ли закупать новые лицензии и тд )
уже имеются следующие таблицы:
USERS (id_user,lastname,firstname,initials,department,otdel,dolzhnost)
DEPARTMENT (id_department,department)
OTDEL (id_otdel,otdel)
DOLZHNOST (id_dolzhnost,dolzhnost)

отталкиваясь от следующей таблицы
| Ф | И | О | деп. | отдел | должн. | уст. ПО | ( можно еще - | разраб. | краткое опис. |)

создадим еще таблицы: ПО (id, nazvanie) , Разраб (id, razrab)
проблема в том, что все связи 1-ко-многим, а вот между таблицами USERS и ПО связи многие-ко-многим , тут ничего не поделаешь и придется связывать их так
фио1 | по1
фио1 | по3
фио2 | по2
фио2 | по3
фио3 | по1

или все таки есть варианты?

есть еще вариант завязать ПО с позьзователями через таблицу Департамент, т.к ПО для разных департаментов специфично, и в итоге мы будем иметь в связующей таблице не (фио*по) строк а (департамент*по) строк, но тут возникают проблемы в том случае если какойто програмный продук не установлен у сотрудника департамента (а у всех стоит), или есть то, чего у других нет, и еще если завязывать в кучу к ПО информационные ресурсы предприятия (типа эл.документооборот, правовые системы, инет) то здесь уже играют роль не департаменты а группы доступа, и как бы не пришлось создавать одтельные таблицы ПО и Инф.Ресурсы, и еще по таблице для связки их с таблицей пользователей.

задайте пожалуйста направление мыслям!

заранее спасибо

BrigadeFuhrer
1. Должность не отдельна сама по себе она четко привязана к отделу.

это конечно должно быть так, но как быть если одна должность может быть в разных отделах?
еще связующая таблица?
BrigadeFuhrer
2. Отдел не отделен от департамента а входит в него (вообще можно слить отделы и департаменты в иерархию)

верное замечание, нужно будет поправить
BrigadeFuhrer
3. завязать ПО c должностью конкретного отдела.

очень интересная идея, нужно обдумать

ну а связи многие-ко-многим можно разрулить только через связующие таблицы если нельзя представить в виде нескольких связей 1-ко-многим ?

заранее спасибо

забыл что еще бывают составные ключи, надо учиться ими пользоваться, однако..

автор(вообще можно слить отделы и департаменты в иерархию)

уважаемый BrigadeFuhrer , что подразумеваете под этой фразой? то же что и в случае должность в отделе?

заранее спасибо

Новый вопрос: хороший способ так хранить штатное расписание?

Департаменты
ID_dep | name_dep |(описание)

Отделы
ID_otdel | ID_dep | name_otdel |(описание)

Должности
ID_dolzhn | ID_otdel | name_dolzhn |(описание)

в принципе можно точно сказать какие отделы и должности есть в департаменте, при создании нового отдела или введении новой должности точно можно соотнести с тем или иным департаментом.

тогда возможно таблица сотрудников может выглядеть не так
Сотрудники
id_user | lastname | firstname | initials | department | otdel | dolzhnost | (доп.инф типа мейл,тел.)

а вместо | department | otdel | dolzhnost |
хранить ID_dolzhn и точно можно сказать где сотрудник работает, т.е таблица пользователей будет выглядеть так:

Сотрудники
id_user | lastname | firstname | initials | ID_dolzhn | (доп.инф типа мейл,тел.)

??

еще вопрос как лучше решить проблему когда у людей совпадают и фамилии, имена и отчества?