Учитывая все вышесказанное, мы остановимся на СУБД Access для разработки нашего программного продукта.

2.5. Построение датологической модели.

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

Датологическая модель строится в терминах базы данных. Так как в нашем случае используется СУБД ACCESS, то мы строим реляционную модель базы данных в реализации MSACCESS.

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

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

Построенная датологическая модель БД, с учетом особенностей MS ACCESS, выглядит следующим образом:

Таблица 2.2.

Таблица «Карточка клиента»

Имя поля	Тип данных	Описание
КодЗаказа	Счетчик	Идентификатор
ФИОНаименование	Текстовый	Имя заказчика
Телефон	Числовой	Телефон заказчика
Адрес	Текстовый	Адрес заказчика
ДатаОбращения	Дата/время	Дата обращения
Площадь	Поле МЕМО	Площадь помещения
ВысотаСтен	Поле МЕМО	Высота стен
Полы	Текстовый	Окончательная отделка пола
Стены	Текстовый	Окончательная отделка стен
Потолок	Текстовый	Окончательная отделка потолка
Двери	Числовой	Количество дверей
Перегородки	Поле МЕМО	Периметр перегородок

Таблица 2.3.

Таблица «Работы»

Имя поля	Тип данных	Описание
КодРабот	Счетчик	Идентификатор
КодТипа	Числовой	Тип работ
Работа	Текстовый	Наименование работы
ЕдИзм	Текстовый	Единицы измерения
Цена	Денежный	Цена единицы работы

Таблица 2.4.

Таблица «Типы работ»

Имя поля	Тип данных	Описание
КодТипа	Счетчик	Идентификатор
Тип	Текстовый	Тип работ

Таблица 2.5.

Таблица «Единицы измерения»

Имя поля	Тип данных	Описание
КодЕдИзмерения	Счетчик	Идентификатор
ЕдИзмерения	Текстовый	Единицы измерения

Таблица 2.6.

Таблица «Материалы»

Имя поля	Тип данных	Описание
КодМатериала	Счетчик	Идентификатор
Материал	Текстовый	Наименование материала
КодЕдИзмерения	Числовой	Единицы измерения
Цена	Денежный	Цена материала

Таблица 2.7.

Таблица «Нормы расхода»

Имя поля	Тип данных	Описание
КодНормы	Счетчик	Идентификатор
КодРабот	Числовой	Наименование работ
КодМатериала	Числовой	Наименование материала
Единицы	Числовой	Единицы измерения
Количество	Поле МЕМО	Количество

Таблица 2.8.

Таблица «Список работ»

Имя поля	Тип данных	Описание
КодОкончРаботы	Счетчик	Идентификатор
ОкончатРабота	Текстовый	Окончательная работа
КодРабот	Числовой	Наименование работ

Таблица 2.9.

Таблица «ЗакзыРаботы»

Имя поля	Тип данных	Описание
КодЗаказа	Числовой	Код заказа
КодОкончРаботы	Числовой	Окончательная работа

Курсивом в таблицах выделен ключевой столбец.

Связи между таблицами выглядят следующим образом:

Рис. 2.2. Связывание таблиц

На рисунке показана организация связей между таблицами. Связи между таблицами объединены общей тематикой.

Рис.2.3. Общий алгоритм работы программы.

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

Функциональные особенности подпрограмм заключаются в следующем:

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

- Подпрограмма запроса на смету предназначена для произведения расчетов и выдачи готовых результатов, в виде ремонтно-строительных смет, на основании данных содержащихся в карточке клиента.

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

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

Рис. 2.4. Алгоритм работы подпрограммы редактирования таблиц

Глава 3.

Организационно - технологическая часть

Разработал Солнцев М. А.

Руководитель Гагарина Л. Г.

3.1. Общая структура организации работ по проектированию ПП.

3.1.1. Постановка задачи.

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

Задание на разработку программы по форме и характеру должно быть аналогично техническому заданию (ТЗ) на разработку какого-либо технического продукта (см., например, ГОСТ 19.201-78 Единой системы программной документации).

Техническое задание полезно и в том случае, когда заказчик и исполнитель работают в одной и той же комнате или даже являются одним и тем же лицом. Наличие четкой письменной формулировки будет препятствовать подмене или отходу в процессе разработки программы от сформулированных в ТЗ требований в угоду каким-то другим побочным целям. Кроме того, письменно сформулированное задание делает возможным обсуждение, оценку или согласованную с заказчиками (пользователями) корректировку отдельных требований ТЗ в ходе разработки программы. ТЗ препятствует проникновению в программу таких ошибок и противоречий, которые могут быть обнаружены только после разработки большей части программы или уже на стадии анализа полученных результатов счета. Чем более формализованным по характеру будет техническое задание, тем больше шансов, что разрабатываемая программа будет решать именно ту задачу, которую имел ввиду заказчик.