1.7. Общий алгоритм работы системы

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

1.8. Выбор платформы проектирования и его обоснование

В качестве операционной системы для реализации программного обеспечения должна быть выбрана среда Windows’9х\NT. Можно выделить следующие причины, обосновывающие этот выбор:

1. Распространенность этих операционных систем;

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

3. возможность работы с большими массивами данных, реализация чего в среде Windows 3.1 или в среде MS-DOS представляет нетривиальную и трудновыполнимую задачу;

4. 32-разрядность систем Windows’95 и Windows NT увеличивает скорость выполнения вычислительных задач.

В качестве среды программирования была выбрана среда Delphi фирмы Borland, сочетающая в себе следующие преимущества:

1. простота и надежность создания и отладки программы;

2. использование всех преимуществ операционных систем Windows’98 и Windows NT, включая 32-разрядность, многозадачность, удобный интерфейс и прочее;

3. использование обработки исключений (exceptions), что позволяет повысить надежность работы программного продукта;

4. наличие и доступность большого количества компонент, реализующих многие стандартные функции;

5. наличие мощных, удобных утилит для отладки и тестирования программного обеспечения;

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

1.9. Проектирование бд системы

1.9.1. Создание инфологической модели

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

Все работы, проводимые на фирме “Эксперт” можно условно разделить на работы с потенциальными клиентами и постоянными. Одним из требований технического задания было – систематизация данных о клиентах. С этой целью мне потребовалось с проектировать базы для хранения информации о потенциальных клиентах и постоянных клиентах. В них содержится информация об организации, ее реквизиты и отрасль деятельности. Для последующей оценки эффективности менеджмента было добавлено поле для хранения информации о том, откуда поступила начальная информация об организации. Для поддержания контакта с фирмой используются данные о контактном лице.

Таблица 1.1

Структура баз потоянных и потенциальных клиентов.

Идентификатор компании

Название компании Вид собственности Телефон Факс Email Юр. Адрес Отрасль Контактное лицо Должность контактного лица Менеджмент Комментарии

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

Таблица 1.2

Структура базы рассылок

Идентификатор письма

Описание письма Файл шаблона Дата отправки

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

Рис. 1.4. Связь базы “Потенциалтьный клиент” и базы “Письма”.

Рис. 1.5. Связь базы “Постоянный клиент” и базы “Письма”.

Для реализации связи многие ко многим между базами клиентов и базами рассылок потребовалось ввести дополнительную базу “Рассылка”.

Таблица 1.3

Структура базы “Рассылка”

Идентификатор организации Идентификатор письма

Рис. 1.5. Связь базы “Клиент” и базы “Рассылка”.

Рис. 1.6. Связь базы “Письма” и базы “Рассылка”.

Основное назначение системы “Эксперт” – контроль за прохождением работ по определенным темам. Поэтому потребовалось создать базу для хранения информации о темах работ, а также отдельную базу для хранения списков работ для каждой из тем. Для автоматизации заполнения контрольных дат во второй базе предусмотрено поле “к-во дней от предыдущей работы”. А для соблюдения хронодогии работ и возможности изменять последовательность их выполнения – поле “хронологический номер”.

Таблица 1.4

Структура базы “Темы”

Идентификатор темы

Название темы

Таблица 1.5

Структура базы “Списки работ по теме”

Идентификатор работы

Название работы Хронологический номер К-во дней от предыдущей работы Идентификатор темы

База с темами должна быть связана с базой о работах по этим темам. В данном случае связь 1:N, так как одной теме может соответсвовать много работ.

Рис. 1.7. Связь базы “Тема” и базы “Работы”.

Контроль за прохождениями работ должен начинаться с момента появления организации в списке потенциальных клиентов. В этот момент должны быть назначены работы с потенциальным клиентом согласно характеру его возможной в будущем заявке (выбирается определенная тема и назначаются соответсвующая ей работы). Именно с этой целью потребовалось создать базу “Предварительная заявка”. В ней содержится указание на потенциального клиента, описание объекта переговоров, информация о папке с документами. Для однозначной идентификации возможной заявки используется номенклатура, присваемая сотрудником “Эксперта” данному делу.

Таблица 1.6

Структура базы с информацией о возможной заявки потенциального клиента

Номенклатура

Идентификатор компании Дата начала работы Объект возможной заявки Номер папки с документами Комментарии

Эта база должна быть связана с базой “Потенциальные клиенты”. Надо также было учесть, что с одной организацией могут идти переговоры по разным темам, поэтому в данном случае одной организации может соответствовать несколько “предварительных заявок”.

Рис. 1.8. Связь базы “Потенциальный клиент” и базы “Предварительная заявка”.

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

Таблица 1.7

Структура базы “Работы по завке”

Код работы

Идентификатор работы в базt “Списки работ” Номенклатура Дата начала работы Планируемая дата окончания Фактическая дата окончания

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

Рис. 1.9. Связь базы “ Предварительная заявка” и “Работы”.

Для постоянных же клиентов необходимо было систематизировать информацию о сделанных завках, но и информацию о договорах, заключенных с ними. Поэтому для хранения этой информации потребовалось создать базу “Договора с постоянными клиентами”. В этой базе хранится информация необходиаю бухгалтеру патентного бюро и секретарю для быстрого поиска данных о договоре (табл. 1.8).

Таблица 1.8

Структура базы “Договора с постоянными клиентами”

Номенклатура

Идентификатор компании Дата начала работы Объект заявки Номер папки с документами Название файла с текстом договора Акт Счета и даты счетов Комментарии

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

Рис. 1.10. Связь базы “Постоянный клиент” и “Договор”.

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

Рис. 1.11. Связь базы “Договор” и “Работы”.

Структура базы “Работы” совпадает с базой “Работы по заявке” для потенциальных клиентов (см. табл. 1.7).

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

Таблица 1.9

Структура базы “Заявка”

Номер заявки

Номенклатура Цвет Классы Процедура прохождения Дата подачи Дата приоритета Дата выдачи свидетельства Эксперт 1 Эксперт 2 Эксперт 3 Телефон эксперта 1 Телефон эксперта 2 Телефон эксперта 3 Номер свидетельства Адрес для переписки Уступка Бюллютень

Каждому договору соответсвует определенная заявка. Проиллюстрирую эту связь баз.

Рис. 1.12. Связь базы “Договор” и “Заявка”.

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

Таблица 1.10

Структура базы “Сотрудники”.

Идентификатор исполнителя

ФИО Адрес Телефон Должность

Каждому сотруднику назначаются работы, за выполнение которых в срок он несет отвественность. Эти работы связаны с договором, но могут отличаться от стандартных: название работы и контрольная дата исполненния могут быть изменены. Именно для создания этой гибкой системы потребовалось введение дополнительной базы “Сотрудник –договор”. Она имеет вид:

Таблица 1.11

Структура базы “Сотрудник-договор”

Идентификатор сотрудника Номенклатура

Описание работы Контрольная дата

Как я уже отметил, необходимо, что бы эта база была связана как с информацией о договорах, так и с базой испонителей, причем по одному договору может работать несколько сотрудников “Эксперт”:

Рис. 1.13. Связь базы “Договор” и “Работа”.

Рис. 1.14. Связь базы “Сотрудник” и “Заявка”.

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

Таблица 1.12

Структура таблицы “Базы”

Идентификатор базы

Название базы Название файла Тип файла

Согласно требований технического задания, необходимом было предусмотреть систему ускоряющих оповещений. Результаттом решения этой задачи стала база “Будильник”. В ней хранится необходимая информация для оповещения о завершении важного этапа работы. Причем учитывается дата начала оповещения о приблежении контрольного срока.

Таблица 1.13

Структура базы “Будильник”

Порядковый номер

Номенклатура Название организации Идентификатор исполнителя Описание работы Дата контроля Дата начала оповещения

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

Таблица 1.14

Структура базы “Регистрация изменений”

Порядковый номер

Номенклатура Название организации Идентификатор исполнителя Описание работы Дата контроля

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

Рис. 1.15. Результат построения инфологической модели баз данных для “постоянных клиентов”.

Рис. 1.16. Результат построения инфологической модели баз данных для “потенциальных клиентов”.

Рис. 1.17. Результат построения инфологической модели служебных баз.

1.9.2. Создание даталогической модели

Даталогическая модель – это описание структуры баз, сделанное на языке выбранной СУБД. Мною была выбрана СУБД Paradox. Требования, предъявляемые к ситеме, полностью можно было реализовать с помощью данной СУБД. Она обеспечивает достаточно большое быстродействие на отдельном компьютере и в пределах небольшой локальной сети.

Рис. 1.19. Результат построения даталогической модели баз данных для “потенциальных клиентов”

Рис. 1.20. Результат построения даталогической модели баз данных “Тема”,“Работы по темам”

Постоянные клиенты и дополнительные базы

Рис. 1.21. Результат построения даталогической модели баз данных для “постоянных клиентов”

Рис. 1.22. Результат построения даталогической модели служебных баз

1.9.3. Ограничения целостности

Ограничения целостности полностью определяются типами данных, выбранными при проектировании даталогической модели. Они обеспечиваются автоматически системой после создания базы и при внесении изменений в нее.