Требования к серверу
I. Процессор, совместимый с Pentium III или выше;
II. Жесткий диск – 2 ГБ свободного места при установке полного пакета
III. Память – 512 МБ.
Требования к рабочей станции:
I. Процессор Pentium с частотой 233 МГц или более быстрый (рекомендуется не менее 300 МГц)
II. Не менее 64 МБ оперативной памяти (рекомендуется не менее 128 МБ)
III. Не менее 1,5 ГБ свободного места на жестком диске
IV. Необходимо наличие дисковода CD–ROM для инсталляции Системы.
Локальная вычислительная сеть
Для локальной вычислительной сети отметим необходимость использования подсоединения рабочих станций при помощи витых пар с пропускной способностью не менее 10Мбит с протоколом TCP/IP.
Общая конфигурация локальной вычислительной сети должна быть построена так, чтобы на участках обмена данными между сервером и рабочими станциями, используемыми Системой, не возникало перегрузок, вызванных передачей значительного количества данных другими программными средствами (например, интенсивный файловый обмен).
Глава 3. Разработка технического задания
Целью разработки любой базы данных является хранение и использование информации о какой-либо предметной области. Для реализации этой цели имеются следующие инструменты:
- Реляционная модель данных - удобный способ представления данных предметной области.
- Язык SQL - универсальный способ манипулирования такими данными.
Очевидно, что для одной и той же предметной области реляционные отношения можно спроектировать множеством различных способов. Далее определим критерии качественности базы данных[24]:
- Адекватность базы данных предметной области;
- Легкость разработки и сопровождения базы данных;
- Скорость выполнения операций обновления данных (вставка, обновление, удаление кортежей);
- Скорость выполнения операций выборки данных.
База данных должна адекватно отражать предметную область. Это означает, что должны выполняться следующие условия[25]:
1. Состояние базы данных в каждый момент времени должно соответствовать состоянию предметной области.
2. Изменение состояния предметной области должно приводить к соответствующему изменению состояния базы данных
3. Ограничения предметной области, отраженные в модели предметной области, должны некоторым образом отражаться и учитываться базе данных.
Практически любая база данных, за исключением совершенно элементарных, содержит некоторое количество программного кода в виде триггеров и хранимых процедур. Очевидно, что чем больше программного кода в виде триггеров и хранимых процедур содержит база данных, тем сложнее ее разработка и дальнейшее сопровождение.
Основными операциями, изменяющими состояние базы данных, являются операции вставки, обновления и удаления записей. В базах данных, требующих постоянных изменений производительность определяется скоростью выполнения большого количества небольших операций вставки, обновления и удаления. Одно из назначений базы данных - предоставление информации пользователям.
Удачная разработка базы данных обеспечивает простоту ее поддержки. Данные следует сохранять в таблицах, причем каждая таблица должна содержать информацию одного типа. Тогда достаточно будет обновить конкретные данные только в одном месте, чтобы обновленная информация отображалась во всей базе данных.
Правильно спроектированная база данных обычно содержит разнообразные запросы, позволяющие отображать нужную информацию. В запросах может выводиться подмножество данных или комбинированные данные из нескольких таблиц, например сведения о заказах совместно со сведениями о заказчиках.
База данных проектируемой Автоматизированной Системы Управления документооборотом Департамента Аренды (далее и везде АСУ Департамента Аренды) содержит 3 основных таблицы (Clients, Objects, Operations) на основании которых можно получить полную информацию по требуемым отчётам.
Таблица «Clients» является хранилищем информации о клиентах, обратившихся с заявками в Департамент Аренды, структура таблицы «Clients» приведена ниже.
Таблица 7 Структура таблицы «clients»
Название поля |
Тип |
Описание поля |
docid |
integer |
Номер документа |
clientid |
integer |
Идентификатор клиента |
clientname |
varchar (150) |
Наименование клиента |
objectkat |
char |
Требуемая категория объекта (А, Б, В) |
clientinput |
datetime |
Дата заявки |
clientprice |
integer |
Цена |
clientstatus |
char |
Отметка: заявка в работе/заявка на оформлении/заявка выполнена |
clientmanager |
varchar(40) |
Ответственный сотрудник (исполнитель операции) |
Внесем необходимые пояснения по описанию:
- Идентификатор клиента это уникальный индивидуальный номер клиента, под которым он внесен в базу данных;
- Наименование клиента по юридическому статусу (ООО либо ОАО/ЗАО в случае если клиент корпоративный), либо имя клиента, в том случае если клиент – частное лицо;
- Требуемая категория объекта и цена: в данном случае указывается, какой именно категории объект и по какой цене интересует клиента;
- Дата заявки – фактический день обращения клиента в Департамент Аренды;
- Отметка описывает процесс работы с клиентом (заявка в работе – клиенту предложены объекты из категории, идет практический выбор объекта; заявка в оформлении – клиент определил объект, идет оформление сопроводительной документации; заявка выполнена – сопроводительные документы оформлены, счет за услуги оплачен/оплачивается);
- Ответственный сотрудник – фамилия ответственного сотрудника Департамента Аренды, назначенного к данному клиенту руководителем клиентского отдела.
«Objects» – таблица служит хранилищем информации об объектах недвижимости, которые имеются в каталоге Департамента Аренды, структура таблицы «Objects» приведена ниже.
Таблица 8 Структура таблицы «obects»
Название поля |
Тип |
Описание поля |
docid |
integer |
Номер документа |
objectid |
integer |
Идентификатор объекта |
objectname |
varchar (150) |
Наименование объекта |
objectkat |
char |
Категория объекта (А, Б, В) |
objectinput |
datetime |
Дата постановки объекта в базу |
objectprice |
integer |
Цена |
objectstatus |
char |
Отметка: сдан/не сдан/резерв/оформляется |
objectmanager |
varchar(40) |
Ответственный сотрудник (исполнитель операции) |