Снова к вам за помощью, уважаемые гуру.
Было бы неплохо получить замечания и советы относительно схемы одной базы, которую пытаюсь спроектировать наиболее удобным для последующего использования образом. В детали углубляться не буду, дабы не усложнять описание. Если возникнут уточняющие вопросы - постараюсь отвечать оперативно.

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

Теперь, собственно, о схеме базы. Взгляните и начните критиковать, а я сразу добавлю пару-тройку комментариев. :)

О табельщиках: у каждого подразделения два табельщика - основной и дополнительный. Ну вот просто такие требования в нашей организации.
О трекинге: вынесен в отдельную таблицу, поскольку надо отслеживать статус подразделения не разово, а в отчетные месяцы.
О статусах: два булевых поля "завершено" и "утверждено" обеспечивают необходимый набор. завершено=0 и утверждено=0 - заполнение табелей, завершено=1 и утвеждено=0 - ввод завершен, завершено=1 и утверждено=1 - табель утвержден, еще одно состояние недопустимо, что отслеживается соответствующим ограничением.
О выборке сотрудников: сотрудники могут приниматься на работу, а также увольняться, поэтому список сотрудников подразделения всегда ограничивается выбранным отчетным месяцем (если у сотрудника есть табель за отчетный месяц - он появится в списке "доступных" сотрудников).

Андрей, где-то мы с Вами одинаково мыслим. У меня такие же ощущения были насчет ключевых объектов бизнес-логики и второстепенных ролях для сущностей "подразделения" и "сотрудники". Не могли бы Вы поделиться своими наработками в этом направлении? Не схемы и код, конечно, а описание концепций для построения правильных, на Ваш взгляд, структур данных. Желательно привязавшись к текущей задаче, если не сложно. Заодно сравню свои предположения с Вашими.

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

штатное расписание описал бы отдельно (возможно, так и есть?);
В каком смысле "отдельно"?

процесс утверждения описал бы явно (для того, чтобы иметь возможность смотреть, сколько раз табель исправлялся);
Снова не понял Вашу мысль. Можно чуть подробнее? Какие описания имеются ввиду? Каким образом изменится схема хранения данных?

ввел бы блокировки для табеля (возможно, они уже есть?).
Если я правильно понял, о каких блокировках идет речь, то они будут реализованы на уровне процедур доступа к данным.

P.S. Какое тут странное форматирование для цитат... неудобно смотреть.

> На схеме Вы пишете: таблица Сотрудники, поле Должность.
> Я бы добавил таблицу штатного расписания. Вполне может быть,
> что один Сотрудник занимает не одну Должность. И вместо указания
> должности в таблице Сотрудники завел бы промежуточную таблицу
> для связи Сотрудников и единиц штатного расписания.
О, нет. Об этом уже думали. Такая глубина детализации не требуется для этого проекта. Как выяснилось, приемлема некоторая избыточность хранимых данных о сотрудниках.

> Схема хранения данных никак не изменится. Просто вместо логических
> полей (или в дополнение к ним) появятся бизнес-процедуры. Таблица
> бизнес-процедур, таблица маршрутов (бизнес-процедура считается
> законченной, когда документ прошел весь маршрут), таблица движения
> документов (таблица состояний).
А вот про это можно подробнее? Раньше не приходилось создавать workflow с нуля. Есть опыт построения подобных систем на основе готовых "движков" вроде Microsoft Exchange Workflow Engine и Microsoft WSS Workflow, так что примерно понял, о чем Вы говорите, но хотелось бы услышать краткое описание, чтобы не перелопачивать массу документации.

> Как будет выглядеть ситуация, когда работник в течении месяца
> сменит подразделение?
А вот тут и вступит в силу избыточность хранения. С позиции системы будет существовать два сотрудника, у одного из которых табель заполнен до смены подразделения, а у другого - после. Сама ситуация редкая, но мне уже не нравится. Может быть, склонюсь-таки к созданию дополнительных таблиц для отслеживания подобных ситуаций. Неохотно иду на подобные усложнения структуры хранения, поскольку они отдаляют от основной цели приложения.

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

> А если человек работает по совместительству в двух подразделениях?
См. последний абзац предыдущего сообщения.

Андрей, Сергей, Вадим, давайте тогда вот как поступим: я попытаюсь изобразить другую схему базы, а вы будете вносить свои поправки. Ну, или совсем поставите крест и подскажете, на что на самом деле она должна быть похожа. Я понимаю, что у вас мало времени на то, чтобы детально описывать, какие сущности должны быть в схеме, как они связаны и т.д. Кроме того, согласен потратить больше времени на проектирование под вашим руководством, хоть и поджимают сроки. Все-таки не каждый день удается получать хорошие советы от знающих людей.

Dik76, благодарю за хорошую ссылку - она точно понадобится. Уже записал в рекомендации для следующей версии.

Что ж, новая схема, в которой попытался (не судите строго) учесть советы Андрея, Сергея и Вадима. На всякий случай, поясню некоторые обозначения и моменты.
1. Таблицы: TimeKeepers - табельщики; DeptTabs - табели подразделений; Tabs - табели сотрудников.
2. Поля: RptMonth - отчетный месяц; Company - код организации, решил не выносить организации в отдельный словарь, поскольку их у нас всего 5 и подразделений - около 80.
3. Табельщики закрепляются не за подразделениями, а за табелями конкретных отчетных месяцев. Пока не определил, даст ли эта дополнительная гибкость какие-то преимущества.
4. В таблицах табелей первичные ключи - искусственные. Так, в DeptTabs можно выделить составной ключ DeptID + RptMonth, а в Tabs - составной ключ DTID + EmpID. Тоже пока окончательно не решил, как поступить лучше. Сейчас кажется, что так будет проще построить уровень доступа к данным на стороне сервера.

> Мне что-то тоже не нравится эти два флага в таблице заголовков табелей.
> Некрасиво. Даже если новые статусы и не планируется вводить, я б сделал
> лучше справочник статусов и таблицу смен статусов (первичный ключ,
> ссылка на присвоенный статус, ссылка на заголовок табеля, дата).
Предпочитаю создавать решения adhoc на первом витке реализации. Тем более, что бизнес-процесс еще долго меняться не будет. Писать свой движок workflow, пусть даже и упрощенный, в этой ситуации не вижу необходимости именно из-за дополнительной сложности выборки и обработки. "Не усложняйте без надобности". (с) Гради Буч

> Потом название компании в таблице подразделений глаз режет. А если
> название компании поменяется, по всем подразделениям лазить
> и исправлять? По мне так лучше внешним ключом туда ее определить -
> ссылка на справочник компаний.
1. Организаций всего 5, и это еще очень долго не изменится. Справочник не нужен, как мне кажется.
2. Хранится не название, а некоторый код компании. Скажем, в char(6).
3. Ваш довод не выглядит убедитиельно даже в том случае, если хранятся полные названия организаций. Смена названия организации - ровно один запрос UPDATE, а не "лазить и исправлять".

> А вообще, мне больше интересно, какая будет структура для самого
> табеля, а не эта возня с документами и подразделениями. То есть как
> будут организованны данные по конкретной строчке табеля?
> Сдается мне, что просто полями Данные1, данные2 ... тут не обойдешься.
Те первичные табельные данные, которые собираются в наших организациях, не представляют собой сложные структуры, так что обходимся набором полей.

P.S. Нерюх, прошу извинить меня за то, что ответ получился таким... резким и каким-то... в поучительном тоне, что ли. Лишь пытался отвечать кратко и строго по темам, ничего личного.

Андрей, Вадим, Сергей, Дик76, Нерюх, большое спасибо за поддержку в разработке даже такой простой схемы базы. Ваши последние замечания также учел, убедили вы меня. :)
Да, Андрей, задачу обещали не менять, но как-то слабо я им верю. Благо, что заказчики внутренние, а потому поле для компромиссов чуть шире. Это придает некоторую дополнительную уверенность (мнимую, наверное). ;)