PredeclaredLekks1. Да, места нарушений...
Место, само по себе, не может быть местом нарушения...

В общем, согласен, но в данном случае непринципиально, так как территория нарушений локальна и место - описание участка однозначно заданной территории.

PredeclaredLekks2. Номер смены сотрудника...
Каким образом номер смены сотрудника описывает нарушение?
Он описывает лишь часть графика работы сотрудника.

Необходимо для анализа работы каждой смены.

PredeclaredLekks3. Нарушители и сотрудники - это две разные категории....
Они родились нарушителями и сотрудниками?
Нарушитель никогда не сможет стать сотрудником? У него рога и копыта этому мешают?
Сотрудник никогда не сможет стать нарушителем? У него нимб над головой светится?

В данном случае априори предполагается именно так. Роли разделены именно текущим состоянием "людя" и переход из роли в роль не предусмотрен. Плюс у нарушителей и сотрудников немного разное описание.

PredeclaredLekks... кто выявил, кто зарегистрировал и кто будет обрабатывать нарушение...
Это роли людей в описании события "нарушение".
Нужны:
1. Таблица описания людей
2. Таблица описания ролей
3. Таблица описания участников в описании регистрации/обработки правонарушения с их ролями.

К сожалению мой жалкий опыт не позволяет даже представить как все это должно выглядеть в схеме ((( С учетом того, что в разные моменты времени один и тот же сотрудник может выступать в разной роли, причем в любой из трех (((

PredeclaredLekks... Учитывается также результат обработки нарушений (Penalty).

Я вижу три последовательных, разнесенных по времени ивента:
1. Выявление правонарушения
2. Регистрации правонарушения
3. Обработка правонарушения

Мне знакомы ситуации, когда в суде были оспорены п.1 или п.2 или переквалифицированы результаты п.3
Вам надо учитывать эти варианты?

По последовательности событий Вы правы, но их возможную отмену в данной БД учитывать не нужно, в том числе и изменение значения "результат".

По п.4 если только так. Но как это потом свести в отчет (графы отчета почти как в основной таблице) я пока вообще не представляю.

vmagЕму нужно только одно - чтоб без всяких интерфейсов (но с задействованием всех возможных подстановок) можно было открыть одну единственную таблицу Нарушений и увидеть сразу всё...

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

PredeclaredLekks...Роли разделены именно текущим состоянием "людя" и переход из роли в роль не предусмотрен. ...
Возможно.
Но я спрашиваю: почему описание людей раскиданы по разным таблицам?
Lekks...Плюс у нарушителей и сотрудников немного разное описание...
Совершенно верно. Я бы сказал сильно разное.
Но я спрашиваю: почему описание людей раскиданы по разным таблицам?

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

PredeclaredКстати говоря, статистику по работе сотрудников, в разрезе ролей, считать проще в моем варианте.
Не?

Да пожалуй))) Я так то быстро схватываю, мне б только идею))))

Predeclared, то есть как то так:

Predeclared, вот в моем конкретном случае:
1. Организация одна, ее описание не нужно и использоваться не будет.
2. Атрибут "дата рождения" нужен только "нарушителю", "сотруднику" не нужен.Вообще.
3. Атрибут "признак" также нужен только нарушителю, это внутренний атрибут, используемый организацией для "нарушителей"
4. "Сотруднику" нужны два атрибута - должность и звание, которые могут меняться, но редко
5. А вот "Роль" может изменяться у каждого сотрудника очень динамично (буквально - сегодня - регистратор, завтра - обработчик).
6. Количество сотрудников ограничено пожалуй цифрой 100-120 человек, изменение состава сотрудников происходит нечасто.
7. А вот количество нарушителей может быть до 4000-5000 в год (как правило "количество нарушений" минус 10-15%).

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

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

Три разнотипных документа по результатам вчерашних обсуждений уже разнес по разным таблицам ))) Спасибо за предоставленное русло размышлений!

По поводу цвета штанов - Вы правы, именно так я и поступил))) Применение предложенной Вами схемы вполне приемлемо и, вероятно, даже более целесообразно, но в условиях динамического развития БД, о чем я говорил:
Lekks по большому счету Ваша схема унифицирована для любой организации и наверняка я ее применю в запланированной БД по личному составу, требующей большей гибкости.
Данная БД же - переложение письменного журнала регистрации в электронный вид и, по большому счету, достаточно было бы использования Excel, имеющего даже более высокие аналитические возможности по сравнению с Access. Но БД Access, на мой взгляд, за счет интерфейса позволяет достичь практически полного исключения "человеческого фактора" из процесса регистрации нарушений, что и требуется в первую очередь.
По поводу "штанов" еще подумаю )))

Прогер_самоучкаLekksдостаточно было бы использования Excel, имеющего даже более высокие аналитические возможности по сравнению с Accessнеужели?

В объеме имеющихся у меня знаний об Access (мнение об объекте имеет свойство изменяться в зависимости от наличия характеризующей объект информации) :-)

В общем, так:

Файл забыл ))))

Predeclared, хочу выразить благодарность, ибо решил не городить кучу БД, а сформировать на основе планируемой БД еще и журнал учета нарушений, допущенных сотрудниками при несении службы, т.е. создается ситуация, когда людь - сотрудник становится людем - нарушителем))) А при новой схеме данных обработка такой ситуации намного проще ))) Большое спасибо!