Приветствую всех и каждого!

Перейду сразу к делу.

Цель: создать приложение (сервер-клиенты) для организованной работы коллектива посредством заявок.

Задача: составить грамотную БД, а именно
-Удобство размещения данных;
-Быстродействие;
-Независимость от СУБД (хотя создавать буду все в MySQL) и/или инструмента программирования;
-Простота работы с БД.

Данные:
Итак, в организации много отделов и сотрудников. Имеется хоть и не большая, но все же текучка кадров. От многочисленной (объемной, количественно большой) суетливой работы многие не успевают или забывают сделать то, что им необходимо сделать. Пытаются записывать на листочках, запоминать, вносить в текстовый файлик на компьютере - но все это все равно примитивно и неэффективно.
Задачи, стоящие перед сотрудниками, разная: от заправки катриджа принтера до исправления нарядов на производстве. Время на исполнение той или иной задачи (заявки) тоже разное (переменной, постоянное), от времени (ну и конечно других параметров) зависит состояние заявки (не начата, в процессе выполнения, завершенная, отложеннная, ожидание другого пользователя). Заявка в своб очередь имеет целый жизненный цикл: публикация (заявитель размещает заявку), регистрация (секретарь, диспетчер или другое уполномоченное лицо фиксирует публикацию заявки, определяет категорию заявки, исполнителя, примерный срок выполнения и др.), исполнение (исполнитель выполняет назначенную ему информацию. К тому же, исполнение может происходить по следующим сценариям: сразу выполняется и завершается; исполнитель просит пояснений, после чего ожидает пояснения и по получению разъяснений от заявителя начинает выполнять) и администрирование (администратор, наверное буду я , выполняет некоторые действия: отчеты по заявкам, проверка исполнений, исправление ошибок регистратора и др.).
К тому же, заявка обладает рядом параметров: id, название, описание, дата публикации, дата регистрации, срок выполнения, дата завершения, комментарии исполнителя, важность, категория, заявитель, исполнитель, регистратор и др.
База данных также должна учитывать и некоторую информацию о сотрудниках: id, ФИО, дата рождения, дата регистрации, дата приема на работу, отдел, должность, роль в приложении (администратор, исполнитель, регистратор, публикатор) и др.

Вкратце попытался донести смысл, надеюсь получилось 

Идей пока две:
1) плохая, отвратительная, неправильная, убогая - все в одну таблицу свести;
2) вроде логичная:
Под списки значений выделяется отдельная таблица (роль в приложении, отдел и др.) + промежуточная таблица (связывает некоторые параметры, к примеру, таблица сотрудников с данными по ним) + общая бд, хранит всю информацию по заявкам.

Прилагаю файл БД Access 2003, где накидал приблизительную БД.

Прошу помочь и поставить на путь истинный в плане организации БД.

Заранее всем спасибо!

Присоединённый файл ( Кол-во скачиваний: 6 )
 bd.rar 31,86 Kb

Самой лучшей идеей, является приведение базы данных в третью нормальную форму.

Ещё хочу дать следующий совет. Нежелательно, чтобы первичный ключ был текстовым, поскольку в данном случае не обеспечивается быстродействие . В этом случае лучше ввести дополнительное поле id и связывать таблицы именно по нему. А для вывода текстовой информации использовать представление.

Первую идею отметаем сразу же, поскольку это 1 нормальная форма.
Вторая - уже ближе к истине. Однако возникает вопрос, возможно ли, что у заявки будет несколько исполнителей, заявителей регистраторов. Также при просмотре Вашей БД заметил, что таблица отдел не связана не с какой другой таблицей, а должна быть связана с таблицей Пользователи (по полю id, которое у Вас я думаю появится). Поля Кому, От кого таблицы Заявки тоже должны быть связаны с таблицей Пользователи. Абсолютно не понял назначение таблицы Доступ к программе, вместо неё просто в поле записываем логическое значение и всё.


То ли плохо искал, то ли этих полей в Вашей БД не обнаружил.
В общем доработать ещё есть что. Но пока Вы на правильном пути.

Спасибо за совет, world!

Добавил небольшую нормализацию. Прикрепляю скрин схемы связей

Это сообщение отредактировал(а) ProESM - 28.8.2010, 15:46

Присоединённый файл ( Кол-во скачиваний: 9 )
 _____.png 52,13 Kb

Не могу понять, что делает индекс должности в таблице отдел.
Ведь тогда получается, что в одном отделе может быть ТОЛЬКО одна должность,
Если Вы хотите, соотнести, что в отделе могут быть только некоторые должности необходимо сделать следующую структуру, как можно увидеть в прикреплённом файле.

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

Присоединённый файл ( Кол-во скачиваний: 5 )
 1.JPG 26,32 Kb

Т.е. получается что-то типа этого (в прикрепленном файле)?

Насчет дублирования инфы я не понял, где она там у меня дублироваться будет?



Присоединённый файл ( Кол-во скачиваний: 6 )
 Schema.png 53,41 Kb

Что касается дублирования инфы, то "Индекс должности" храниться в 2 СВЯЗАННЫХ между собой таблицах Пользователи и Отдел и соответственно может быть получен с помощью запроса.

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



и



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

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

Это сообщение отредактировал(а) world - 28.8.2010, 20:44

Присоединённый файл ( Кол-во скачиваний: 9 )
 1.PNG 53,41 Kb

Спасибо, все понял, отлично получилось!!! Результат труда потом выложу на обозрение. Покритикуете ))

сотрудник может работать на полставки? а совмещать две разные должности в разных отделах?

Я не понимаю - а зачем изобретать велосипед, когда существует масса готовых программных комплексов с описанным функционалом?

По разработанной соместно с world схеме базы данных создал SQL запрос. Все работает шикарно, единственный вопрос, что индексировать, какие поля каких таблиц (для ускорения работы). Жду советов. Заранее спасибо!

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