Разработка автоматизированной информационной системы БУ Редакция газеты "К новым рубежам"

В настоящее время проблема комплексной или частичной автоматизации стала актуальной для каждого предприятия. Уже не стоит вопрос “надо или не надо автоматизировать”, предприятия столкнулись с проблемой: каким образом это осуществить. Ведь не существует двух одинаковых организаций. Простое тиражирование даже очень известной и хорошей системы управления предприятием никогда не устроит заказчика полностью, поскольку не может учесть его специфики. Более того, в данном случае возникает проблема выбора именно той системы, которая наиболее подходит для конкретного предприятия. А эта проблема осложняется еще и тем, что ключевые слова, характеризующие различные системы, практически одни и те же: единая информационная среда предприятия; режим реального времени; независимость от законодательства; интеграция с другими приложениями (в том числе с уже работающими на предприятии системами); поэтапное внедрение и т.п.

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

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

требуемую пропускную способность системы;

требуемое время реакции системы на запрос;

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

простоту эксплуатации и поддержки системы;

необходимую безопасность.

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

Цель дипломной работы - провести проектирование и разработку автоматизированной информационной система БУ «Редакция газеты «К новым рубежам».

Задачи дипломной работы:

Провести анализ теоретических подходов к разработке АИС;

Провести анализ деятельности предприятия, построить функционально ориентированные модели AS-IS и TO-BE;

Разработать БД и приложение.

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ РАЗРАБОТКИ АВТОМАТИЗИРОВАННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ БУ «РЕДАКЦИЯ ГАЗЕТЫ «К НОВЫМ РУБЕЖАМ»»

БУ «Редакция газеты «К новым рубежам» основана: в 1937 году (первоначальное название - «Ленинская трибуна»). Занимается выпуском и распространением районной газеты. Оказывает полиграфические услуги, фотоуслуги, тиражирование и печать документов, изготовление печатной документации, разработка и размещение рекламы (макетов) и др. услуги.

Компания практикует клиентно-ориентированный подход и дорожит каждым клиентом.

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

Автоматизация работы учреждения производится для решения основных задач:

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

минимизация временных затрат на заказы клиентов, продажи на основе заказов, а так же планирование будущих продаж;

ведение единой клиентской базы, где собраны сведения: контакты; информация клиентах, возможные предложения и т.д.

Целями внедрения АРМ является совершенствование технического управления, повышение уровня информационной обеспеченностью процесса управления, качества принимаемых решений.

БУ «Редакция газеты «К новым рубежам» предоставляет свои услуги как физическим, так и юридическим лицам. В дальнейшем будем называть их клиентами. Основные функции, выполняемые отделом по работе с клиентами:

работа с клиентами, регистрация заказов;

разработка макетов, внесение изменений, всевозможные нововведения и улучшения;

выполнение заказов;

Работа с клиентами, регистрация заказов.

От клиентов поступают различные заказы. Очень часто клиент не представляет как правильно и лучше изготовить макет.

Разработка макетов, внесение изменений, всевозможные нововведения и улучшения;

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

Договор и акт о выполнении работ составляются в двух экземплярах, один из которых остается на предприятии, а второй передается заказчику. Расчеты с клиентами осуществляются, как в безналичной, так и наличной форме.

Документы формируемые в отделе по работе с клиентами:

Договор;

Счет на оплату услуги или товара (Рис. 2);

Акт выполненных работ (Рис. 3);

Счет-фактура (Рис. 4).

Рисунок 2 - Счет на оплату

Рисунок 3 - Акт выполненных работ

Рисунок 4 - Счет - фактура

1.3 Построение функционально-ориентированных моделей as-is «как есть» и to-be «как должно быть»

Построение модели деятельности «как есть» (AS-IS)

В результате обследования деятельности БУ «Редакция газеты «К новым рубежам» построена функциональная модель существующей организации работы "как есть" (AS-IS). Данная модель реализовывалась с помощью такого CASE-средства, как BPwin 4.0. При создании модели была использована возможность построения смешанной модели, которая содержит одновременно диаграммы разных методологий, т.е. IDEF0, IDEF3 и DFD. Каждая из них решает свои специфические задачи.

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

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

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

Создание модели в стандарте IDEF0

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

Функциональная модель предназначена для описания существующих бизнес - процессов на предприятии (так называемая модель AS-IS «как есть») и идеального положения вещей - того, к чему нужно стремиться (модель ТО-ВЕ «как должно быть»).

Модель включает:

структурную функциональную модель деятельности в соответствии со стандартом IDEF0 (иерархия SADT-диаграмм);

функциональную модель в виде иерархии потоков данных (DFD).

Методология IDEF0 предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы.

Построение модели ИС начинается с описания функционирования предприятия (системы) или отдельной ее части (в нашем случае это деятельность БУ «Редакция газеты «К новым рубежам», в частности отдела по работе с клиентами) в целом в виде контекстной диаграммы (Рис. 5).

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

Таблица 1 - Стрелки контекстной диаграммы

Создадим диаграмму декомпозиции функциональной модели деятельности учреждения в стандарте IDEF0 (Рис. 6).

Таблица 2 - Работы диаграммы декомпозиции А0

Декомпозируем работу «Основная деятельность» (Рис. 6) на основе результатов проведения экспертизы. Получена следующая информация:

Отдел по работе с клиентами получает заказы клиентов;

Менеджер данного отдела анализирует заказ и на основе анализа подбирает необходимый вариант;

Составляется договор на заказ;

Таблица 3 - Работы диаграммы декомпозиции А2

Декомпозируем процесс «Основная деятельность» (Рис.7) на:

Запрашиваются сведения о клиенте и заказе;

Сведения оформляются в заявку;

Заключается договор

Таблица 4 - Работы диаграммы декомпозиции А2.1

Диаграмма потоков данных DFD содержит процесс «Прием и обработка заказа», взаимодействующий с внешними сущностями «Клиент», «БД с клиентами» (Рис.7). «Клиент» делает заказ и сообщает о себе информацию, если ее нет. Компания посылает клиенту коммерческое предложение, договор на оказания услуги или продаже продукта, выставляет счет. После оплаты счета компания отдает заказ клиенту и делает товарную накладную и счёт-фактуру.

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

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

Юридический адрес клиента;

Реквизиты клиента (ИНН, КПП, ОГРН, БИК и др.);

Данные о продукте или описание услуги;

Сроки выполнения;

Цена;

Условия поставки;

Форс-мажорные обстоятельства.

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

Рис. 5 - Контекстная диаграмма БУ «Редакция газеты «К новым рубежам»»

Рис. 6 - Декомпозиция функциональной модели деятельности учреждения

Рис. 7 - Основная деятельность

Рис. 8 - Прием заказа у клиента

Рис. 9

Построение модели деятельности «как должно быть» (to-be)

Анализ построенной функциональной модели «как есть» позволил понять, где находятся самые узкие места, в чем будет состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая организация бизнеса. Детализация бизнес-процессов позволила выявить недостатки библиотеки даже там, где функциональность на первый взгляд кажется очевидной. В результате построена модель TO-BE, которая имеет следующие отличия от модели AS-IS. Декомпозировав процесс «Прием заказа у клиента» мы выявили процессы, занимаемые наибольшее количество времени:

сбор сведений о клиенте;

обработка заказа;

заключение договора.

Для увеличения эффективности работы нам необходимо увеличить скорость выполнения процесса.

Для автоматизации процесса «Прием заказа у клиента» мы решили разработать необходимое программное обеспечение для автоматического вывода заявки на основе занесенных данных о клиентах, ценах, готовых заказах и т.д. Разработав программное обеспечение, мы автоматизировали необходимые нам процессы и тем самым уменьшили время. Благодаря автоматизации этих процессов быстрота обслуживания клиентов, предоставление сведений об услугах, новшествах, изменениях, их ценах возросло в несколько раз, тем самым мы увеличили и объем продаж и улучшили сервис обслуживания клиентов в целом (Рис. 10).

Рис. 10

1.4 Техническое задание

Общие сведения

Полное наименование системы: БУ «Редакция газеты «К новым рубежам»

Условное обозначение системы: АИС РГКнр.

Наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты:

Заказчик: БУ «Редакция газеты «К новым рубежам», адрес - Россия, 646400, г. Омск, пгт Саргатское, ул. Коммунальная, 19.

Разработчик: Омский государственный институт сервиса, адрес - Россия, 644050, г. Омск, Певцова, 13.

Основание для создания: Договор о создании Автоматизированной системы управления деятельностью директором БУ «Редакция газеты «К новым рубежам». Утвержден 20.10.2011 г.

Плановые сроки начала и окончания работы по созданию системы:

Начало: 20.10.2011 г.

Окончание: 20.11.2012 г.

Сведения об источниках и порядке финансирования работ:

Источник финансирования: БУ «Редакция газеты «К новым рубежам»

Объем финансирования: 40 000 рублей.

Назначение и цели создания системы

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

Цели создания системы:

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

повышение оперативности управления процессом;

повышение производительности труда;

обеспечение устойчивости функционирования объекта;

повышение комфорта клиента при заказе.

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

Характеристики объекта автоматизации: <отсутствуют>

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

Требования к системе в целом

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

БУ «Редакция газеты «К новым рубежам» Уровень 1.

Подсистема заключения договоров с клиентами

Подсистема организации хранения заказов.

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

Подсистема расчетов с клиентами.

Требования к способам и средствам связи для информационного обмена между компонентами системы.

Данные договора.

Источник - подсистема заключения договоров с клиентами.

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

Приходный ордер.

Источник - подсистема ведения закупок.

Приемник - подсистема организации зазаков.

Акт о выполнении работ.

Источник - подсистема организации выполнения работ по договору.

Приемник - подсистема расчетов с клиентами.

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

Внешняя сущность - клиент.

Принимает информацию от БУ «Редакция газеты «К новым рубежам» через поток Договор.

Направляет информацию к БУ «Редакция газеты «К новым рубежам» через поток Счет на оплату.

Внешняя сущность - Клиент.

Принимает информацию от БУ «Редакция газеты «К новым рубежам»

через поток Коммерческое предложение

через поток Договор через поток Счет клиенту

через поток Акт выполненных работ

через поток Акт передачи прав

через поток Счет-фактура клиенту.

Направляет информацию БУ «Редакция газеты «К новым рубежам»

через поток Заказ через поток Заказ на услуги

через поток Информация о клиенте.

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

Требования к показателям назначения: <отсутствуют>

Требования к надежности: <отсутствуют>

Требования к безопасности: <отсутствуют>

Требования к эргономике и технической эстетике: <отсутствуют>

Требования к транспортабельности для подвижных АИС: <отсутствуют>

Требования к эксплуатации, техническому обслуживанию, ремонту и хранению комплектов системы: <отсутствуют>

Требования к защите информации от несанкционированного доступа: процесс авторизации пользователей.

Требования к сохранности информации: необходимо предусмотреть резервное копирование информации.

Требования к средствам защиты от внешних воздействий: установка источников бесперебойного питания.

Требования к патентной чистоте: <отсутствуют>

Требования к стандартизации и унификации: <отсутствуют>

Дополнительные требования: <отсутствуют>

Требования к функциям.

Подсистема заключения договоров с клиентами. Уровень 2.

Внести данные о клиенте. Имеет функцию - Ведение БД «Клиенты» с алгоритмом: 1) получить данных клиента; 2) внести данные в БД.

Подобрать требующиеся для клиента условия. Имеет функцию - Подбор продукта по заказу с алгоритмом: 1) получить критерии отбора; 2) определить подходящую стоимость; 3) составить список на основании данных от клиента.

Составить договор. Уровень 3.

Составить договор. Имеет функцию - Составление проекта договора с алгоритмом: 1) получить данные Коммерческого предложения; 2) получить данные клиента; 3) получить рекомендуемые условия оплаты; 4) получить форму договора; 5) составить договор; 6) внести данные договора в БД «Договоры».

Анализировать выполнение клиентом обязательств по договору. Имеет функцию - Формировать рекомендации по условиям заключения сделок с алгоритмом: 1) проверить надежность клиента по БД «Клиенты»; 2) формировать запрос по клиенту в БД «Договоры»; 3) получить отчет о выполнении клиентом обязательств по ранее заключенным договорам; 4) формировать рекомендации.

Подсистема организации хранения заказов. Уровень 2.

Вести учет заказов. Имеет функцию - Ведение учета склада заказов с алгоритмом: 1) внести запись о поступившем заказе в БД «Заказы на складе».

Подсистема организации выполнения работ по договору. Уровень 2.

Имеет функцию - Организация выполнения работ по договору с алгоритмом: 1) получить данные договора с клиентом из БД «Договоры»; 2) формировать требование на отпуск со склада заказов; 4) формировать акт о выполнении работ.

Подсистема расчетов с клиентами. Уровень 2.

Сформировать счет клиенту на предоплату. Имеет функцию - Формирование счета клиенту с алгоритмом: 1) получить из договора данные о размере предоплаты; 2) формировать счет клиенту на предоплату.

Выписать счет-фактуру клиенту. Имеет функцию - Подготовка данных для окончательного расчета по договору с алгоритмом: 1) получить банковскую выписку о произведенной клиентом предоплате; 2) получить акт о выполнении работ; 3) формировать счет-фактуру клиенту.

Произвести окончательный расчет по договору. Имеет функцию - Закрытие договора с клиентом с алгоритмом: 1) получить банковскую выписку об окончательном расчете; 2) внести данные о выполнении обязательств по договору в БД «Договоры»; 3) внести отметку о надежности клиента в БД «Клиенты».

Требования к видам обеспечения.

Требования к математическому обеспечению: <отсутствуют>

Требования к информационному обеспечению.

Внешняя сущность - Клиент.

Перечень входных потоков: Коммерческое предложение, Договор, Счет-фактура клиенту, Счет клиенту, Товарная накладная.

Перечень выходных потоков: Заказ, Информация о клиенте, Заказ на ПО.

Требования к лингвистическому обеспечению: <отсутствуют>

Требования к программному обеспечению: операционная система начиная с Windows 98 до Windows 7.

Требования к техническому обеспечению:

Требования к метрологическому обеспечению: <отсутствуют>

Требования к организационному обеспечению: процессор не ниже Pentium 3, оперативная память не меньше 1ГБ, видеокарта допускается интегрированая, принтер, сканер, модем .

Состав и содержание работ по созданию (развитию) системы.

Номер и наименование этапа:

1. Проведение обследования: начало этапа - 20.10.2011 г., конец - 27.10.2011 г.

2. Создание модели АИС - начало этапа: 28.10.2011 г., конец этапа: 20.11.2012 г.

Порядок контроля и приемки системы: <отсутствует>

Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу в действие: <отсутствуют>

Требования к документированию: <отсутствуют>

Источники разработки

Документ: ТЗ-1

Полное наименование: Техническое задание на проектирование АИС от 25.02.2012 г.

Глава 2. разработка АИС БУ «Редакция газеты «К новым рубежам»»

2.1 Описание Базы данных (БД)

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

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

- договора;

- клиенты:

- поставщики;

- товар;

- заказы;

- услуги;

- доставка.

Понятие тип сущности относится к набору однородных личностей, предметов или событий, выступающих как целое (клиент, поставщики и т.д.).

Атрибут - это свойство сущности в предметной области. Его наименование должно быть уникальным для конкретного типа сущности.

Для сущности «Клиент» использованы следующие атрибуты:

- код клиента;

- наименование клиента;

- адрес;

- телефон.

Для сущности «Договора» использованы следующие атрибуты:

- номер договора;

- код клиента;

- тип договора;

- код поставщика;

- код услуги;

- дата заключения, окончание договора;

- сумма договора;

- код товара.

Для сущности «Услуги» использованы следующие атрибуты:

- код услуги;

- наименование услуги;

- срок исполнения;

- стоимость.

Для сущности «Заказ» использованы следующие атрибуты:

- код заказа;

- наименование заказа;

- сумма заказа.

В базе данных, разработанной для программы БУ «Редакция газеты «К новым рубежам»», содержится 7 таблиц. Расскажем о них поподробнее.

В таблице «Клиенты» хранится информация о клиентах предприятия (Табл. 5).

Таблица 5 - Таблица «Клиенты»

В таблице «Договора» хранится информация о заключенных договорах с поставщиками и клиентами (Табл. 6).

Таблица 6 - Таблица «Договора»

В таблице «Услуги» хранится информация о предоставляемых услугах (Табл. 7).

Таблица 7 - Таблица «Услуга»

Таблица «Заказы» хранит информацию о имеющихся заказах (Табл. 8).

Таблица 8 - Таблица «Заказы»

2.2 Разработка приложения

Разработка приложения велась с помощью программ Borland Delphi Enterprise Version 7.0, MS Access.

Методология IDEF3 была создана для сбора и описания процессов в анализируемой системе. Согласно стандарту ISO/CD 15531-1

ПРОЦЕСС - это упорядоченный набор функций, охватывающий различные сущности предприятия и завершающийся глобальной целью. В методологиях IDEF под «процессом» понимается набор операций, которые, взятые вместе, создают результат, имеющий ценность для потребителя.

БИЗНЕСПРОЦЕСС - совокупность взаимосвязанных бизнес-процедур - функций или действий, формирующих результат, имеющий ценность для потребителя, технологических и организационно-деловых процессов, выполняемая целенаправленно в рамках заранее заданной организационной структуры в результате которых производится определенная группа продуктов и услуг. Такое понимание процесса позволило разработать качественно новую концепцию внутрипроизводственного менеджмента - концепцию реинжиниринга.

РЕИНЖИНИРИНГ есть фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения существенных улучшений в таких ключевых для современного бизнеса показателях результативности, как затраты, качество, уровень обслуживания и оперативность.

МЕТОДОЛОГИЯ IDEF3 (workflow diagramming) - это методология графического моделирования, предназначенная для описания и документирования информационных потоков в системе, в которой процессы выполняются в заданной последовательности, взаимоотношений между процессами обработки информации и объектами, являющихся частью этих процессов и участвующие совместно в одном процессе. Основная цель разработчиков методологии IDEF3 - обеспечение специалиста (эксперта) предметной области инструментом структурного анализа, при помощи которого он сможет представлять знания о выполнении операций в системе или организации в целом. Это метод, обеспечивающий аналитикам возможность описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе. Цель описания может состоять как в документальном оформлении и распространении знаний о процессе, так и в идентификации противоречивости или несовместимости выполнения отдельных операций.

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

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

объекты, которые участвуют при выполнении сценария;

роли, которые выполняют эти объекты (например, агент, транспорт и т.д.);

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

состояния и изменения, которым подвергаются объекты;

время выполнения и контрольные точки синхронизации работ;

ресурсы, которые необходимы для выполнения работ.

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

записывать в терминах системного анализа сырые данные, полученные в ходе интервью.

определять влияние информационных ресурсов организации на важнейшие сценарии деятельности, принятые на предприятии.

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

управлять конфигурацией данных и изменять правила контроля.

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

создавать имитационные модели.

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

Рис. 11 - Контекстная диаграмма БУ «Редакция газеты «К новым рубежам»»

На рис. 11 представлена модель IDEF0 общей системы работы БУ.

Рис. 12 отображает более подробное описание выполнение заявки.

Рис. 12

Microsoft Access - это функционально полная реляционная СУБД. В ней предусмотрены все необходимые вам средства для определения и обработки данных, а также для управления ими при работе с большими объемами информации.

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

Предназначение СУБД Access

СУБД Access предназначена для разработки баз данных реляционного типа для локального их использования на персональных компьютерах и для работы с этими базами.

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

Данная СУБД была выбрана по следующим причинам:

- простота средств реализации,

- легкость освоения инструментарием разработчика (VBA),

- наглядность визуализации информации.

Также «Microsoft Access» предоставляет большое количество внутренних средств по оптимизации работы проектируемого приложения. К ним относятся:

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

- оптимизация дерева вызовов;

- использование файлов MDE;

- автоматическая поддержка компилированного состояния;

- использование библиотек Windows API;

- индивидуальная настройка системы;

- эффективное использование индексов;

- встроенный оптимизатор запросов.

Система управления базами данных (СУБД) обычно поддерживает 4 основных типа отношений между таблицами:

- один-к-одному (одной записи в первой таблице соответствует одна запись во второй);

- один-ко-многим (одной записи в первой таблице соответствует много записей во второй);

- много-к-одному (многим записям в первой таблице соответствует одна запись во второй);

- много-ко-многим (одной записи в первой таблице соответствует много записей во второй и одной записи во второй таблице соответствует много записей в первой).

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

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

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

Взаимосвязи таблиц.

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

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

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

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

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

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

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

Delphi - это система визуального объектно-ориентированного программирования, позволяющая решать множество задач, в частности:

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

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

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

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

- Создавать приложения, которые управляют другими приложения, в честности, такими программами Microsoft Office, как Word, Excel и др.

- Создавать кросс-платформенные приложения, которые можно компилировать и эксплуатировать как и в Windows, так и в системе Linux.

- Создавать приложения различных классов для работы в Интернет и в интранет.

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

- И многое другое, включая создания отчетов, справочных систем, библиотек DLL, компонентов ActiveX.

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

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

Описание приложения Автоматизированная информационная система БУ «Редакция газеты «К новым рубежам»можно начать с формы «Вход» (Рис. 13).

Рис. 13 - Главная форта АИС БУ «Редакция газеты «К новым рубежам»

На форме расположены две кнопки «Вход» и «Выход». Нажав кнопку «Вход» появляется форма «Проверка» (Рис. 2.3). На данной форме расположены поля для ввода данных «Имя пользователя» и «Пароль». Если при вводе пароля пользователь ошибается, то возникает форма «Ошибка» которая сообщает о неверном действии.

Рис. 14 - Форма на аунтификация

Введя правильные данные необходимые для обеспечения безопасности системы, переходим на главную форму программы (она же форма «Договора»).

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

Рис. 15 - Форма «Договора»

Главная форма (Договора) - Кнопка «Новый договор», описывается следующим образом:

procedure TForm3.BtnNewClick(Sender: TObject);

begin

Form10.Show;

end;

На (Рис. 16) представлен результат добавления данных.

Рис. 16 - Форма «Договора» - результат добавления данных

Кнопка «Добавить»

После введения в поля «Edit» формы данных нажимаем кнопку «Добавить», описывается следующая процедура:

procedure Button1Click(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form10: TForm10;

implementation

{$R *.dfm}

procedure TForm10.Button1Click(Sender: TObject);

begin

ADOTable1.insert;

ADOTable1.FieldByName('Тип_договора').asstring:=Edit1.Text;

ADOTable1.Post;

ADOTable1.insert;

ADOTable1.FieldByName('Код_поставщика').asstring:=Edit3.Text;

ADOTable1.Post;

ADOTable1.insert;

ADOTable1.FieldByName('Код_услуги').asstring:=Edit4.Text;

ADOTable1.Post;

ADOTable1.insert;

ADOTable1.FieldByName('Дата_заключения').asstring:=Edit5.Text;

ADOTable1.Post;

ADOTable1.insert;

ADOTable1.FieldByName('Дата_окончания').asstring:=Edit6.Text;

ADOTable1.Post;

ADOTable1.insert;

ADOTable1.FieldByName('Сумма_договора').asstring:=Edit7.Text;

ADOTable1.Post;

ADOTable1.insert;

ADOTable1.FieldByName('Код_товара').asstring:=Edit8.Text;

ADOTable1.Post;

end;

Главная форма (Договора) - Кнопка «Удалить договор»

procedure TForm3.BtnDeleteClick(Sender: TObject);

begin

Form12.Show;

end;

Форма «Удаление договора»

procedure TForm10.Button1Click(Sender: TObject);

begin

if Form3.RzPageControl1.TabIndex=0 then

begin

if Form3.ADOTable1.RecordCount>0 then

begin

Form3.ADOTable1.Edit;

Form3.ADOTable1.DeleteRecords(arCurrent);

end;

end;

Главная форма (Договора) - Кнопка «Поиск»

procedure TForm3.BtnPrintPreviewClick(Sender: TObject);

begin

Form15.show;

end;

Форма «Поиск»

procedure TForm15.Button1Click(Sender: TObject);

var s:string;

begin

If ((RzEdit1.Text='') or (RzEdit2.Text='')) then

begin

ShowMessage('Выберите параметры поиска');

end else

If ((RzEdit1.Text<>'') and (RzEdit2.Text<>'')) then

begin

If Form3.RzPageControl1.TabIndex=0 then

begin

s:=RZEdit1.Text;

Form3.ADOTable1.Locate(RzEdit2.Text,s,[loPartialKey]);

If Form3.ADOTable1.Fields[RzEdit2.ItemIndex].Value<>RzEdit1.Text then

begin

ShowMessage('Не найдено');

end;

end else

If Form1.RzPageControl1.TabIndex=1 then

begin

s:=RZEdit1.Text;

Form1.ADOTable2.Locate(RzEdit2.Text,s,[loPartialKey]);

If Form1.ADOTable2.Fields[RzEdit2.ItemIndex].Value<>RzEdit1.Text then

begin

ShowMessage('Не найдено');