Wr,

1. Не очень понятно, зачем вам разделять таблицы Человек и Сотрудник.
2. Как взаимосвязаны отделы и цеха и почему Должность привязывается к цеху, причем по названию?
3. У вас классификатор спецодежды может иметь произвольное количество уровней вложенности? Если нет (а даже если и да), то может оказаться сильно проще сделать две таблицы: Группы_одежды и собственно Одежда с привязкой к группе. В принципе таблицу Группы_одежды можно при желании сделать ссылающейся сама на себя и реальзовать произвольную структуру дерева, но с выделенным типм листа. Преимущества - проще организовать проверку связей, что человеку выдается именно конкретная одежда, а не группа.
4. Соответственно нужны таблицы связей:
4.1 Должность_Одежда, задающая, какая одежда какой должности положена.
4.2 Человек_Одежда, хранящая, что, кому, когда и на сколько было выдано.
Проверка, что у человека есть все, что нужно, осуществляется с помощью связей Человек_Одежда-Человек-Должность-Должность_Одежда.

Wriljy,

1.
Человек может уволиться, а потом прийти заново.
Человек может подрабатывать в другом цеху/на другой должности по совместительству.
Вдруг потребуется в дальнейшем хранить какие-то личные данные, например дата рождения, прописка, паспортные данные -
поэтому думаю правильней будет разделить.
Я не про должность, я про сотрудника. Чем отличается запись в таблице Человек от записи в таблице Сотрудник? Или, скажем, табельный номер у вас приписывается к Сотруднику, и Человек, работающий по совместительству, будет иметь таких номеров несколько? Тогда да, смысл есть.

Wr2.
Вот блин, ребёнок отвлекает.
Опечатка, естественно
Должность [Ключ записи] [Нимаенование должности]

Так, а привязка к цеху-отделу? Или вы предполагаете таблицу Сотрудник привязывать к Должности и Отделу? Тогда может есть смысл назвать ее не Сотрудник, а Штатная_единица например?
Wr3.
Количество уровней вложенности произвольное.
Т.е. лучше переделать таблицу
Тип [Ключ записи] [Наименование типа] [Ключ предка] [Признак типа]
Тогда будут храниться данные:
[1] [Электробезопасность] [Null] [1] - Верхний элемент в группе электробезопасноть
[2] [Перчатки] [1] [1] - Подруппа в типе "Электробезопасность"
[3] [] [2] [0] - Это уже конкретная спец.одежда из группы "Перчатки"

Имхо "Перчатки тип А.3" лучше хранить в одтельной таблице, и привязывать запись к подгруппе "Перчатки".

Wr4.
4.1 Нужно продумать в зависимости не только от должности, но и от отдела.
Например (от болды), инженеру из отдела снабжения положены перчатки хб (чтобы на складе ручки не пачкал, когда инвентаризацию проводит) и каска, вдруг что с верхних стеллажей упадёт :)
А инженеру из цеха электроники положены перчатки диэлектрические и халат х/б.
4.2 Нужно как-то продумать не "Человек_Одежда", а "Сотрудник_Одежда"
Одному человеку, работающему ещё и по совместительству положены два "набора" спец.одежды.

Только что-то не сообразить - как это всё правильно хранить...
Соответственно выданная спецодежда привязывается к Штатной_единице, и для человека можно проверять отдельную комплектацию по этим единицам. Только вы уверены, что надо выдавать несколько одинаковых предметов одежды? Уточните.

WrПоэтому будет ещё одна таблица "Площадка", привязанная к "Штатная_еденица"
? Уверены? Я может чего не понимаю, но по-моему Цех должен быть привязан к площадке, а штатная единица к цеху. Хотя конечно вам виднее, что у вас как

WrКогда человек работает по совместительству, и на обеих должностях положен, например, халат х/б,
то он получит два халата, при этом они, как правило, они имею ещё и разные сроки носки (у инженера год, а у слесаря 6 месяцев)

Как скажете.
WrНемного не понял по поводу хранение "Перчатки тип А.3" в отдельной таблице.
Можете привести пример - какие тогда будут таблицы и с какими полями?
Группы_одежды:
ИдГруппы, ИдРодительскойГруппы (возможно вместо двух полей использовать hierarchyid какой-нибудь), НазваниеГруппы.

Одежда:
ИдОдежды, ИдГруппы, НазваниеОдежды, всякие доп.поля типа инвентарного номера и т.п

Преимущества главным образом в упрощении связности: Должность или Штатная_единица гарантировано привязаны именно к одежде, вам не надо проверять, что при вводе не ошиблись и не указали группу.

Wriljy,

Ну, такой у нас бедлам с привязкой цехов)))
Есть ремонтный цех. На одной площадке это цех№21 со своим старшим и сменными мастерами и со свомими бригадами.
Есть тот же ремонтный цех (делает то же самое, но на другой площадке) и у него уже номер 22, и там свои мастера и бригады.
А есть административный цех, отвечающий за уборку территориии пр. и он один на все плащдки, с одним старшим мастером :)

Сурово А еще наверное могут существовать выездные бригады ремонтников, нет? Да еще и обслуживающие только часть площадок
Продумайте структуру и кратность связей между сущностями Цех, Штатная_единица, Должность и Площадка, тогда схему нарисовать будет просто.
Wr
Вот, для наглядности сделал картинку, но никак не могу понять, как привязать что конкретной должности в конкретном цеху необходим определённый набор одежды. Т.е. набор одежды должен определяться не для Штатной_Еденицы, а, например, для всех техников (должность) химико-технической лаборатории (отдел)
Тут возможны опять же варианты, но нужно понимать, от чего это количество одежды зависит. Если, например, оно зависит от должности и цеха, но не зависит от площадки - создается таблица примерно такого вида:
Одежда_Должность_Цех:
ИдОдежды, ИдДолжности, ИдЦеха, Количество, МаксимальныйСрокСлужбы
Вообще говоря у вас классическая совершенно задача по нормализации: вам надо привести предметную область к форме не ниже 3НФ. Обычно на этом нормализацию можно остановить, но уже смотря по ситуации.

WrОдежду, соответственно, тоже получают с одной площадки. Поэтому таких сразу отбрасываем...
Ок, значит штатная единица привязана к цеху и площадке. Соответственно отдельную таблицу связи Цех_Площадка можете создавать, а можете не создавать. Я бы создал, контроль правильности облегчит.
WrЗависимости норматива от площадки нет, он един и зависит только от отдела и должности.

Ок, значит с таблицей Одежда_Должность_Цех тоже разобрались.

WrКак мне кажется, в плане учёта сотрудников и спец.одежды имеющейся базы хватит.
Т.е. основные задачи:
- Учёт сотрудников (кто в каком отделе и на какой площадке числится)
- Что положено сотруднику

А вот с третьей - определить что сейчас у работника есть и какие сроки носки у выданной одежды.
Чтобы можно было сделать выборку по сотрудникам по цехам/площадке с невыданной или просроченной спец.одежде.
С этим проблемы... что-то мне никак не сообразить :(
А какие собственно? Вам нужна таблица Штатная_единица_Одежда, примерно такая:
ИдШтатнойЕдиницы, ИдОдежды, Дата_Выдачи

У вас есть связь Одежда - Штатная_единица_Одежда - Штатная_единица - Должность+Цех - Одежда_Должность_Цех - Одежда. Соответственно вам надо проверить, что множество справа цепочки и множество слева одинаковы и выполняются условия на срок службы. Делается одним запросом.
WrP.S.: Я не программер, так немного только умею.
Стоило пару раз написать простенькие приложения с 2-4-мя формами и базой на 3-5-ть таблиц.
Теперь "сели на шею" и озадачивают :(
Бывает Ниче, научитесь, глядишь и работу поменяете

WriljyЯ бы создал, контроль правильности облегчит.
Не соображу, какой тут может быть контроль правильности?
Если бы со всеми цехами было как с ремонтным: Первая лощадка цех№21, вторая - цех№22
У половины отделов нет аткого разделения: Охрана труда - один общий отдел с одим начальником на все площадки,
просто сотрудники закреплены за разными площадками. При этом если на удалённой площадке инж. по охр.труда ушёл в отпуск,
то его замещает один из инж. по охр. труда с основной площадки. Причём это происходит по указанию руководителя в устной форме)))
Контроль правильности такой: есть есть такая таблица и в ней есть записи (Цех1,Площадка1),(Цех1,Площадка3), то, при вводе штатной единицы, система не даст для нее указать Цех1,Площадка2. Иначе все на риске клиента.
Wriljy А какие собственно? Вам нужна таблица Штатная_единица_Одежда, примерно такая:
ИдШтатнойЕдиницы, ИдОдежды, Дата_Выдачи
Надо, наверно, ещё добавить поле Срок_носки.
Бывает так, например, что пришёл практикант на должность слесаря, получил халат хб у которого срок носки 6месяцев,
отработал месяц и ушёл, сдав халат на склад. Тогда потом этот халат будет выдан кому-то другому, но уже на оставшиеся 5 месяцев.
Вам виднее. Тогда наверное еще всякие инвентарные номера надо и т.п.
Wriljy У вас есть связь Одежда - Штатная_единица_Одежда - Штатная_единица - Должность+Цех - Одежда_Должность_Цех - Одежда. Соответственно вам надо проверить, что множество справа цепочки и множество слева одинаковы и выполняются условия на срок службы. Делается одним запросом.

А вот с такими сложными запросами как раз у меня проблемы. Пока освоены только на уровне select [тра-та-та] from [парам-пам-пам] where [пурум-пум-пум].

Что-то вроде такого:
Получатся список сотрудников с предметами одежды, которая не выдана либо просрочена. Можно слегка изменить и получать с конкретным указанием - не выдана или просрочена.
WrЧто скажает по поводу получившейся базы(см. рис). Вроде тогда всё можно отследить.
А если постаят потом ещё и задачу учёта СИЗ (что вполне возможно), то может заранее продумать
Например как на рис.
Т.е. в Группах отслеживать дерево: Высотные работы - Когти
в Типах: Тип А, Тип Б и т.д. с укзанием ГОСТ/ТУ, Общего срока носки от производителя и пр. именно для этого типа
Кладовые - тут понятно, на каждой плащадке есть свой склад
Если экземпляр оджеды не выдан и находится на складе, будет соответствующая запись в таблице НаСкладе.
Порядко наверно будет такой - сначала одежда поступает на склад, кладовщик заносит данные и делаем запись в табл. НаСкладе.
А при выдаче удалять эту запись, и делать запись в "ВыданнаяОдежда"

Имхо таблица НаСкладе тут лишняя. Я бы в таблице Одежда сделал 2 связи - на Кладовая и на Выданная одежда, или даже сразу на Штатная_Единица, и навесил CONSTRAINT CHECK (ИдКладовая IS NULL OR ИдШтатнаяЕдиница IS NULL). Соответственно может быть активна только одна связь, и это легко контролируется. А так - может быть прописано две ссылки, на уровне базы это можно контроллировать только триггерами. И ДатуВыдачи сюда же, она же может датой передачи на склад быть.
Тут возникает вопрос - надо учитывать историю одежды или нет? Т.е. кому когда выдавали, когда сдавали на склад? Если надо - придется еще делать таблицу движений.

WriljyБывает Ниче, научитесь, глядишь и работу поменяете
Вполне возможно, а то текущая работа по сборке и настройке ПК, установке ПО уже как-то поднадоела)))
Удачи На форуме часто хорошие книжки рекомендуют, можно поискать.
WrПросьба указать недостатки данной структуры БД, и всё таки как сделать запрос. Если не сложно, то хотелось бы увидеть следующие запросы, остальные хочется попробовать самому по аналогии продумать.
Скорее всего надо будет отображать следующие данные:
- Список всех сотрудников с выделением цветом тех у кого что-то просрочено или не выдано.
Планируется на формк будет dataGridView, и фильтры: Все сотрудники, фильтровка по площадкам/цехам
(скорее всего на форме будут ComboBox'ы с выбором соответствующих площадок/цехов);
- Список только тех сотрудников, у кого что-то просрочено или не выдано (фильтр как и предыдущем пункте);
примерно так:
Фильтр ставьте какой нравится.

Wriljy,

Про Цех-Площадка Вы правы, я об этом не подумал :)
Я так понимаю надо добавить таблицу ОтделыПлощадки,
В табл. ШтатнаяЕденица добавить вторичный ключ из таблицы ОтделыПлощадки и убрать вторичный ключ от табл. Отделы
Тогда, при добавлении сотрудника, надо будет в приложении выбрать сначала Площадку,
а comboBox с отдлами/цехами уже запонять возможными вариантами в соответствии с табл. ОтделыПлощадки и выбранной площадкой?
Ну типа того. Или сначала Цех, потом Площадку, тут уж как хотите.
WrПро CONSTRAINT CHECK (ИдКладовая IS NULL OR ИдШтатнаяЕдиница IS NULL) я правильно понял? (см. рис)
Вроде да. Надо еще поле ДатаВыдачи в таблицу Одежда добавить.

WrПро движение. Не продумать.
Я так понимаю должна быть табл. в которой будут
[Ключ.Записи] [Ключ.Одежды] [Дата] [Движение.Откуда] [Движение.Куда]
Но как тогда высчтывать остаточный срок носки? Например у каски он может быть три года,
и за это время она может поменять несколько хозяев, и несколько раз вернуться на склад :)

По таблице движений это делается. Работа с интервалами - совершенно классическая задача.

WrДа и вопрос, по поводу реализации тогда учёта СИЗ, допустим на склад пришло 20 халатов хб одного размера
и 5 халатов - другого. Кладовщику что, каждый экземпляр заносить отдельно, или делать какую-ниудь
хранимую процедуру с параметром "Количество" и в ней делать цикл вставки с кличеством проходов раным "Количество"?

Это вам виднее. Если надо отслеживать индивидуальный срок носки каждого предмета, то по другому просто не получится. Заносить каждый экземпляр конечно не надо, в интерфейсе указывается количество вновь добавляемых, а система сама создает индивидуальные записи и присваивает инвентарные номера.

WrС запросами вроде в общех чертах понял, большое спасибо. Осталось только разобраться с отличием join от left join :)

http://ru.wikipedia.org/wiki/Join_(SQL)#.D0.92.D0.B8.D0.B4.D1.8B_.D0.BE.D0.BF.D0.B5.D1.80.D0.B0.D1.82.D0.BE.D1.80.D0.B0_JOIN


WrИ, может быть, тогда лучше делать не запрос из приложения, а создать вьюшки.
Например будут :
1. вьюшка которая отображает всех сотрудников со всех цехов и площадок у которых что-то невыдано
2. вьюшка которая отображает всех сотрудников со всех цехов и площадок у которых что-то просрочено
3.....
А в приложении сделать comboBox "Режим отображения": "Показать с невыданой спец.одеждой", с просроченной (и т.д. в зависимости от пожеланий, да и с дальнейшей перспективой, кто его знает что ещё захотят потом)
И уже в зависимости от выбранного режима отображения обращаться к определённой вьюшке с учётом фильтра по площадке/цеху
В принципе мысль хранить запросы в базе, а не на клиенте, правильная. Можно вьюшки, можно таблицные функции или процедуры (в функцию или процедуру можно сразу передать параметры площадки-цеха, ко вьюхе можно генерить запрос с динамическим фильтром).