Для комфортной работы необходим процессор уровня Intel Pentium 500, 64 Мб ОЗУ, совместимая звуковая карта, видеокарта 8 Мб памяти, объем жесткого диска составит:
- Windows 700 Мб;
- файл подкачки 200 Мб;
- файлы разрабатываемой базы данных 2,5 Мб (программа и библиотеки);
- сам файл базы будет увеличиваться примерно на 2 Мб в год;
- сервисное ПО 100 Мб;
- MS Office 300 Мб.
Затрат на приобретение необходимого дополнительного оборудования не потребуется, так как в КП "Алчевское строительное управление" имеется все самое современное оборудование и необходимое программное обеспечение.
Программное обеспечение должно повышать качество управления КП «Алчевское строительное управление», обеспечивать специалистов необходимой информацией для текущей работы и для принятия управленческих решений. Разрабатываемое программное обеспечение должно обладать следующими характеристиками:
- единая система сбора и накопления информации – все части системы должны быть согласованы, информация не должна быть противоречивой или содержать повторения;
- возможность редактирования данных в удобной пользователю форме – программное обеспечение должно содержать простой интерфейс, обеспечивающий простой для пользователя ввод-вывод, изменение и удаление информации;
- возможность анализа деятельности для дальнейшего принятии решений – возможность создания отчетов для руководства.
На уровне базы данных в проектируемой системе необходимо предусмотреть следующие возможности:
- обеспечивать получение отчетов текущих и по итогам работы;
- обеспечивать получение информации без существенных задержек;
- надежность хранения информации — база данных не должна допускать случайной потери данных;
- достоверность хранимой информации — хранимые данные не должны искажаться при вводе либо обработке;
- безопасность хранимой информации - разграничение прав доступа к базе данных, а также необходимость процедуры регистрации пользователей. Необходимо создать парольную защиту, поскольку хранимая в базе информация конфиденциальна.
Информационная система оперативного уровня является связующим звеном между фирмой и внешней средой. В базе данных системы будет храниться важная информация для работы отдела: данные о заявках, договорах, информационных системах, затратах и др. Разрабатываемая система должна отвечать повышенным требованиям к надежности. Если система работает плохо, то организация либо не получает информации извне, либо не выдает информацию. Кроме того, эта система - это поставщик информации для остальных типов информационных систем в организации, так как содержит и оперативную, и архивную информацию.
Отключение этой информационной системы привело бы к необратимым или трудно устранимым негативным последствиям.
Для обеспечения достаточной надежности необходимо применять высококачественное оборудование, применять резервное копирование данных, контролировать входную и выходную информацию.
Проектируемая информационная система работает на основе модели распределенных вычислений клиент-сервер. Для ее реализации необходимо, чтобы все бюро отдела имели современное компьютерное оборудование и компьютеры внутри отдела должны быть соединены локальной сетью. Необходимо установить сервер базы данных, на котором будет храниться вся информация, необходимая для работы. Это даст возможность удобно коммутировать применяемое в системе оборудование, а так же уменьшить риск потери данных и повысить общую надежность и функциональность системы. На сервере предполагается разместить и прикладное программное обеспечение. На сервере информация обрабатывается и хранится, на клиентских сетевых машинах производится ввод-вывод, обработка информации, хранение информации, необходимой для работы конкретного пользователя.
Концептуальная модель базы данных - это высокоуровневая объектно-ориентированная модель предметной области, представляющая объектную область в виде набора объектов, обладающих определенными свойствами и находящимися в некоторых отношениях. Основная цель разработки высокоуровневой модели данных заключается в создании модели пользовательского восприятия данных и согласовании большого количества технических аспектов, связанных с проектированием базы данных. Концептуальная модель данных не привязана к конкретной физической реализации баз данных и не зависит от конкретной СУБД. Концептуальная модель создается на основе представлений о предметной области каждого типа пользователей, представляющих собой набор данных, необходимых пользователю для решения своих задач. Основные концепции модели включают такие понятия как сущность (объект), отношение (связь), типы сущностей, типы связей и атрибуты. Проанализировав предметную область, можно выделить следующие 5 основных сущностей:
- «Объекты»;
- «Строительно-монтажные работы»;
- «Сметы»;
- «Акты»;
- «Реестры»;
После определения основных сущностей необходимо определить атрибуты каждой сущности.
Сущность «Объекты» характеризуется следующими атрибутами:
- «Код объекта»;
- «Наименование объекта»;
Сущность «Строительно-монтажные работы» характеризуется следующими атрибутами:
- «Код работ»;
- «Наименование работ»;
Сущность «Сметы» характеризуется следующими атрибутами:
- «Номер сметы»;
- «Наименование строительно-монтажных работ».
Сущность «Акты» характеризуется следующими атрибутами:
- «Код акта»;
- «Номер акта»;
- «Месяц»;
- «Год»;
- «Наименование объекта».
Сущность «Реестры» характеризуется следующими атрибутами:
- «Номер реестра»;
- «Номер акта»;
- «Номер сметы»;
- «Базисная сметная стоимость»;
- «Договорная цена»;
- «В т.ч. материалы заказчика»;
- «К оплате»;
- «Материалы подрядчика без ГСМ»;
- «Оборудование»;
- «М/лом».
После определения сущностей и их атрибутов необходимо определить связи.
Объекты — Акты на выполненные работы. Связь типа 1: М, т. к. на 1 объекте производятся разные работы в разный период времени и заполняются акты по выполненным работам.
Строительно-монтажные работы – Сметы. Тип связи 1:М, т. к. каждый вид работ может выполняться на разных объектах. На каждый тип работы составляется смета.
Сметы – Реестры. Тип связи 1:М, т. к. 1 тип сметы может вноситься в разные реестры.
Акты — Реестры. Тип связи 1:М, т. к. 1 номер акта может вноситься в разные реестры.
После определения связей пришла очередь определить ключи. На этом этапе для каждого объекта (сущности) устанавливается потенциальный ключ (или ключи), после чего осуществляется выбор первичного ключа. При выборе первичного ключа среди потенциальных следует руководствоваться правилами:
- нужно использовать потенциальный ключ с минимальным набором атрибутов;
- использовать следует тот ключ, вероятность изменения значений которого минимальна;
- выбирать следует тот потенциальный ключ, который имеет минимальную вероятность потери уникальности значений в будущем;
- значения ключа должны иметь минимальную длину;
- с выбранным ключом пользователю будет проще работать.
В данной курсовой работе я выбираю ключевыми поля кодирования информации. На предприятии существует система кодирования информации (каждому документу присваивается его уникальный код). Эти коды очень редко меняются, занимают небольшой объем памяти, не повторяются. То есть содержат все признаки первичного ключа. В каждой сущности разрабатываемой базы данных есть поле для кода. Эти поля являются первичными ключами, и в концептуальной диаграмме будут подчеркнуты.
Полученная концептуальная модель базы данных представлена в приложении А.
Логическое проектирование – создание информационной модели предприятия на основе отдельных моделей данных пользователей, которая независима от особенностей используемой СУБД и других физических условий.
Преобразование локальной концептуальной модели данных в локальную логическую модель заключается в удалении из концептуальных моделей нежелательных элементов и преобразование полученных моделей в локальные логические модели. К нежелательным элементам относятся:
- связи типа «многие – ко - многим»;
- рекурсивные связи;
- связи с атрибутами;
- множественные атрибуты;
- избыточные связи.
Разрыв связей «многое-ко-многому» осуществляется путем введения некоторой дополнительной сущности, которая конкретизирует понятия и изменяет связь «многое-ко-многому» на связь типа 1:М или М:1. Обязательными реквизитами новой сущности должны быть ключи сущностей, имеющих связь типа М:N.