102104 (590526), страница 6

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 6)

Недостатком постреляционной модели является сложность решения проблемы обеспечения целостности и непротиворечивости хранимых данных.

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

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

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

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

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

• Отчет «Клиенты»

• Отчёт «Объекты»

• Отчет «Количество объектов, сданных за период»

• Отчёт «Срок экспозиции объекта»

В отчет «Клиенты» должна быть включена информация:

• Наименование клиента

• Дата подачи заявки

• Категория желаемого объекта

• Тип взаиморасчетов

• Цена услуг

• Ответственный сотрудник

В отчёт «Объекты» должна быть включена информация:

• Наименование

• Дата постановки в базу

• Категория объекта

• Цена

• Отметка о статусе (сдан/не сдан/резерв/оформление)

• Ответственный сотрудник

В отчёт «Объекты, сданные за период» должна быть включена информация:

• Количество сданных объектов по категориям

• Тип взаиморасчётов (нал/безнал)

• Общий приход денежных средств по объектам за период

• Дебиторская задолженность

В отчёт «Сроки экспозиции объектов» должна быть включена информация:

• Наименование объекта

• Категория объекта

• Дата постановки объекта в базу

• Период присутствия в базе

• Цена

• Ответственный сотрудник.

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

2.3 Выбор средств, архитектуры для АСУ. Требования к аппаратному обеспечению

Для разработки АСУ выбрана архитектура «клиент-сервер» - современная архитектура построения информационных систем, обеспечивающая эффективность их функционирования. Достоинством организации информационной системы по архитектуре «клиент-сервер» является возможность централизованного хранения, обслуживания и коллективного доступа к общей корпоративной информации, а также обеспечение высокой производительности и надёжности системы.

Использование архитектуры клиент-сервер:

1. резко уменьшает сетевой трафик;

2. понижает сложность приложений-клиентов (поскольку тем уже нет необходимости обеспечивать целостность и безопасность БД и следить за параметрами многопользовательской работы с БД);

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

4. повышает надежность БД, ее целостность, безопасность и секретность.

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

• распространенность реляционной модели;

• практически любой специалист в области информационных технологий знаком с теорией и практикой реляционных БД;

• поддержка реляционной модели большинством СУБД.

В качестве среды разработки для клиентской части АСУ используется среда разработки C++ Builder 6, разработка компании Borland. С++ Builder относится к системам визуального проектирования, называемым также системами RAD. Разработка приложения в C++ Builder два взаимосвязанных этапа:²¹

• создание пользовательского интерфейса приложения;

• определение функциональности приложения.

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

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

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

При разработке АСУ документооборотом использовались следующие основные факторы выбора средств реализации:

• возможность описания предметной области средствами реляционной модели данных;

• удобный графический интерфейс;

• надежность и возможность работы в сетевом режиме;

• невысокая стоимость приложения по отношению к другим специализированным и глобальным пакетам программ;

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

• открытость – настройка на входные документы, логистику расчетов, отчетных документов;

• не высокое требование к аппаратным ресурсам при разработке программного обеспечения.

В качестве СУБД для проектируемой АСУ выбрана система MS SQL Server. Эта СУБД, создана компанией Microsoft и является в настоящее время одной из самых распространённых, кроме этого предлагаемая СУБД фактически в настоящее время является стандартом в области хранения данных²². Отличительные качества:

• Высокая производительность и надёжность при минимальных требованиях к техническим средствам;

• Высокая масштабируемость;

Структура сети представлена в приложении 4.

Требования к аппаратному обеспечению определяются требованиями к используемым операционным системам и серверным продуктам (Windows XP Professional, Windows 2003 Server, SQL Server 2005)²³:

Требования к серверу

1. Процессор, совместимый с Pentium III или выше;

2. Жесткий диск – 2 ГБ свободного места при установке полного пакета

3. Память – 512 МБ.

Требования к рабочей станции:

1. Процессор Pentium с частотой 233 МГц или более быстрый (рекомендуется не менее 300 МГц)

2. Не менее 64 МБ оперативной памяти (рекомендуется не менее 128 МБ)

3. Не менее 1,5 ГБ свободного места на жестком диске

4. Необходимо наличие дисковода CD–ROM для инсталляции Системы.

Локальная вычислительная сеть

Для локальной вычислительной сети отметим необходимость использования подсоединения рабочих станций при помощи витых пар с пропускной способностью не менее 10Мбит с протоколом TCP/IP.

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

Глава 3. Разработка технического задания

3.1 Разработка базы данных

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

• Реляционная модель данных - удобный способ представления данных предметной области.

• Язык SQL - универсальный способ манипулирования такими данными.

Очевидно, что для одной и той же предметной области реляционные отношения можно спроектировать множеством различных способов. Далее определим критерии качественности базы данных²⁴:

• Адекватность базы данных предметной области;

• Легкость разработки и сопровождения базы данных;

• Скорость выполнения операций обновления данных (вставка, обновление, удаление кортежей);

• Скорость выполнения операций выборки данных.

База данных должна адекватно отражать предметную область. Это означает, что должны выполняться следующие условия²⁵:

1. Состояние базы данных в каждый момент времени должно соответствовать состоянию предметной области.

2. Изменение состояния предметной области должно приводить к соответствующему изменению состояния базы данных

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

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

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

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

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

База данных проектируемой Автоматизированной Системы Управления документооборотом Департамента Аренды (далее и везде АСУ Департамента Аренды) содержит 3 основных таблицы (Clients, Objects, Operations) на основании которых можно получить полную информацию по требуемым отчётам.

Таблица «Clients» является хранилищем информации о клиентах, обратившихся с заявками в Департамент Аренды, структура таблицы «Clients» приведена ниже.

2. Структура таблицы «clients»

Внесем необходимые пояснения по описанию:

• Идентификатор клиента это уникальный индивидуальный номер клиента, под которым он внесен в базу данных;

• Наименование клиента по юридическому статусу (ООО либо ОАО/ЗАО в случае если клиент корпоративный), либо имя клиента, в том случае если клиент – частное лицо;

• Требуемая категория объекта и цена: в данном случае указывается, какой именно категории объект и по какой цене интересует клиента;

• Дата заявки – фактический день обращения клиента в Департамент Аренды;

• Отметка описывает процесс работы с клиентом (заявка в работе – клиенту предложены объекты из категории, идет практический выбор объекта; заявка в оформлении – клиент определил объект, идет оформление сопроводительной документации; заявка выполнена – сопроводительные документы оформлены, счет за услуги оплачен/оплачивается);

• Ответственный сотрудник – фамилия ответственного сотрудника Департамента Аренды, назначенного к данному клиенту руководителем клиентского отдела.

«Objects» – таблица служит хранилищем информации об объектах недвижимости, которые имеются в каталоге Департамента Аренды, структура таблицы «Objects» приведена ниже.

1. Структура таблицы «obects»

Внесем необходимые пояснения по описанию:

• Идентификатор объекта это уникальный индивидуальный номер объекта, под которым он внесен в базу данных;

• Наименование объекта – фактическое название объекта;

• Категория объекта вносится в соответствие с принятой градацией объектов недвижимости (категория А – объекты, стоимость аренды которых составляет от 1 млн. руб.; категория В – объекты, стоимость аренды которых составляет от 500 тыс. руб. до 1 млн. руб.; категория С – объекты, стоимость аренды которых составляет до 500 тыс. руб.);

• Дата постановки объекта в базу – фактический день внесения объекта в базу;

• Цена – фактическая стоимость аренды объекта, определенная Департаментом Эксплуатации;

• Отметка описывает процесс работы с объектом аналогично отметке по клиенту;

• Ответственный сотрудник – фамилия ответственного сотрудника Департамента Аренды, за которым закреплен конкретный объект руководителем клиентского отдела.

«Operations» - таблица содержит информацию обо всех сделках с объектами недвижимости и клиентами за определенный период.

Внесем необходимые пояснения по описанию:

• Идентификатор объекта или клиента – уникальный номер, присваиваемый объекту или клиенту при внесении в базу;

• Дата совершения операции – фактический день заключения договора аренды с клиентом;

• Отметка расчета по операции ставится исходя из фактических расчетов уже произведенных клиентом (наличные денежные средства либо безналичные), в том случае если клиент не оплатил выставленный счет, ставится отметка «не определен»;

1. Структура таблицы «Operations»

Приход денежных средств отражает фактическую суммы оплаты счета клиентом;

• Дебиторская задолженность возникает в том случае, если клиент не оплатил счет, фактически показывает, какой размер дебиторской задолженности числится за данным клиентом и/или объектом;

• Ответственный сотрудник – фамилия ответственного сотрудника Департамента Аренды, за которым закреплен конкретный объект или клиент руководителем клиентского отдела.

Связь таблиц 8, 9 и 10 осуществляется по ключевому полю docid*, slitset таблица срезов, которые указывают на один аналитический счет в таблице account (ключ id). Программный код файла data.cpp, который отвечает за выполнение операций исполнения документов и функционирование АСУ Департамента Аренды в целом приведен в приложении А.

Характеристики

Список файлов ВКР