«Номер сметы»;

«Наименование строительно-монтажных работ».

Сущность «Акты» характеризуется следующими атрибутами:

«Код акта»;

«Номер акта»;

«Месяц»;

«Год»;

«Наименование объекта».

Сущность «Реестры» характеризуется следующими атрибутами:

«Номер реестра»;

«Номер акта»;

«Номер сметы»;

«Базисная сметная стоимость»;

«Договорная цена»;

«В т.ч. материалы заказчика»;

«К оплате»;

«Материалы подрядчика без ГСМ»;

«Оборудование»;

«М/лом».

После определения сущностей и их атрибутов необходимо определить связи.

Объекты -- Акты на выполненные работы. Связь типа 1: М, т. к. на 1 объекте производятся разные работы в разный период времени и заполняются акты по выполненным работам.

Строительно-монтажные работы - Сметы. Тип связи 1:М, т. к. каждый вид работ может выполняться на разных объектах. На каждый тип работы составляется смета.

Сметы - Реестры. Тип связи 1:М, т. к. 1 тип сметы может вноситься в разные реестры.

Акты -- Реестры. Тип связи 1:М, т. к. 1 номер акта может вноситься в разные реестры.

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

нужно использовать потенциальный ключ с минимальным набором атрибутов;

использовать следует тот ключ, вероятность изменения значений которого минимальна;

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

значения ключа должны иметь минимальную длину;

с выбранным ключом пользователю будет проще работать.

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

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

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

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

связи типа «многие - ко - многим»;

рекурсивные связи;

связи с атрибутами;

множественные атрибуты;

избыточные связи.

Разрыв связей «многое-ко-многому» осуществляется путем введения некоторой дополнительной сущности, которая конкретизирует понятия и изменяет связь «многое-ко-многому» на связь типа 1:М или М:1. Обязательными реквизитами новой сущности должны быть ключи сущностей, имеющих связь типа М:N.

Основными понятиями модели «сущность- связь» являются:

сущность;

связь;

атрибуты.

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

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

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

«Сметы»: ключевой реквизит -- «Код сметы», так как однозначно определяет уникальность записи БД, он компактен и удобен для обработки.

«Акты» ключом будет являться «Код акта».

каждой сущности ставится в соответствие отношение реляционной модели данных;

каждый атрибут сущности становится атрибутом соответствующего отношения;

первичный ключ сущности становится первичным ключом соответствующего отношения. Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство обязательности (NOT NULL). В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов основной сущности, являющейся первичным ключом основной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом.

После преобразования модели «сущность-связь» получим приведенные ниже параметры атрибутов сущностей.

Таблица 3.1 - Атрибуты отношения «Объекты»

Таблица 3.2 - Атрибуты отношения «Строительно-монтажные работы»

Таблица 3.4 - Атрибуты отношения “ Сметы ”

Таблица 3.5 - Атрибуты отношения “ Реестры ”

Таблица 3.6 - Атрибуты отношения “Наименование работ”

создаются таблицы БД;

вводятся необходимые ограничения;

определяются ключевые поля;

формируются связи между таблицами;

обеспечиваются условия целостности данных.

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

Рисунок 3.1 - Таблица «Объекты»

Рисунок 3.2 - Таблица «Строительно-монтажные работы»

Рисунок 3.3 - Таблица «Акты»

Рисунок 3.4 - Таблица «Сметы»

Рисунок 3.5 - Таблица «Реестры»

Рисунок 3.6 - Таблица «Наименование работ»

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

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

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

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

Рисунок 3.7 - Схема данных

Рисунок 3.8 - Построение запроса «Акты по месяцам»

Рисунок 3.9 - Результат запроса «Акты по месяцам»

Рисунок 3.10 - Результат запроса «Акты по объектам»

Рисунок 3.11 - Построение запроса «Виды работ по объектам»

Рисунок 3.12 - Результат запроса «Виды работ по объектам»

Рисунок 3.13 - Построение запроса «Количество выполненных работ за каждый месяц»

Рисунок 3.14 - Результат запроса «Количество выполненных работ за каждый месяц»

Рисунок 3.15 - Построение запроса «Стоимость работ за каждый месяц»

Рисунок 3.16 - Результаты запроса «Стоимость работ за каждый месяц»

Рисунок 3.17 - Главная форма

Рисунок 3.18 - Форма Ввод данных

Данная форма содержит кнопки для открытия дополнительных форм для ввода данных.

Рисунок 3.19 - Форма Объекты

Рисунок 3.20 - Форма Акты

Рисунок 3.21 - Форма Запросы

Каждый запрос открывается в виде отчета.

Рисунок 3.22 - Отчет Сметы по видам работ

Для выхода из Информационной системы создан макрос Выход.

собрана и проанализирована информация;

произведено моделирование БД;

разработана база данных;

разработано управляющая программа;

проведено тестирование СУБД.

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

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

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

Для решения поставленной цели были реализованы следующие этапы:

проанализирован сопутствующий документооборот;

выявлены “слабые” места;

предложены методы автоматизации изучаемого процесса;

разработана модель базы данных;

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

Страницы: 1, 2, 3