Разработка автоматизированной системы учета готовой продукции на предприятии (на примере ОАО 'Каравай')
Введение
Потоки информации, циркулирующие в мире, который нас окружает, огромны.
Во времени они имеют тенденцию к увеличению. Поэтому в любой организации, как
большой, так и маленькой, возникает проблема такой организации управления
данными, которая обеспечила бы наиболее эффективную работу. Некоторые
организации используют для этого шкафы с папками, но большинство предпочитают
компьютеризированные способы - базы данных, позволяющие эффективно хранить,
структурировать и систематизировать большие объемы данных. И уже сегодня без
баз данных невозможно представить работу большинства финансовых, промышленных,
торговых и прочих организаций. Не будь баз данных, они бы просто захлебнулись в
информационной лавине.
Существует много веских причин перевода существующей информации на
компьютерную основу. Сейчас стоимость хранения информации в файлах ЭВМ дешевле,
чем на бумаге. Базы данных позволяют хранить, структурировать информацию и
извлекать оптимальным для пользователя образом. Использование клиент/серверных
технологий позволяют сберечь значительные средства, а главное и время для
получения необходимой информации, а также упрощают доступ и ведение, поскольку
они основываются на комплексной обработке данных и централизации их хранения.
Кроме того ЭВМ позволяет хранить любые форматы данных, текст, чертежи, данные в
рукописной форме, фотографии, записи голоса и т.д.
Если учитывать всё вышеописанное, то можно понять что актуальность
создания информационной системы для производственного предприятия очень высока
на сегодняшний день.
Цель работы является разработка автоматизированной системы учета готовой
продукции на предприятии по материалам ОАО «Каравай», г. Краснодар, в целях
предоставления оперативной информации для руководства, а так же для подготовки
информации для дальнейшего анализа и снижения объёма бумажного
документооборота.
Для достижения поставленной цели необходимо решить следующие задачи:
Проанализировать деятельность малых производственных предприятий.
Создать базу данных, необходимую для создания информационной системы.
Разработать информационную систему
Посчитать экономическую выгоду от внедрения.
Данная автоматизированная информационная система должна работать с
оперативными данными, накопление этих данных позволит проводить анализ
деятельности предприятия за любой период времени. Это является одной из задач
внедрения системы, и для успешного достижения её, в систему встроен модуль
оптимизации хранения информации. Благодаря его использованию, существенно
сокращается время, затрачиваемое на подготовку информации для использования в
других подсистемах. Это достигается путем выбора наиболее оптимального способа
хранения данных в зависимости от типа. При таком подходе, время, затрачиваемое
на получение этих данных другими подсистемами также сокращается.
1 Аналитический обзор
.1 Общие сведения о предприятии
Исследуемое мной предприятие ОАО «Каравай», г. Краснодар.
Род занятий данного предприятия производство продукции пищевой
промышленности. ОАО «Каравай» имеет следующие организационные документы:
устав предприятия, с проставленным штампом регистрируемого;
свидетельство о постановке на учет в налоговом органе юридического лица,
образованного в соответствии с законодательством Российской Федерации.
свидетельство о внесении записи в единый государственный реестр юридических
лиц о юридическом лице.
перечень номенклатуры изделий аккредитованных Госстандартом Российской
Федерации.
Предприятие образовано 14 апреля 2000г. целевая направленность данного
предприятия ориентирована на занятие своей ниши на рынке товаров производственного
назначения в г Краснодаре.
ОАО «Каравай» обеспечило рабочими местами более 30 человек. Оно
располагается на территории одного здания, концентрированно объединив,
производственные цеха, отделы ИТР администрации и склады, в организованный, гибко
управляемый и имеющий относительно низкие затраты механизм производства. К
этому также следует добавить то, что транспортная развязка г. Краснодара
является наиболее благоприятной для межобластной транспортной связи плюс то,
что образовательные учреждения г. Краснодара подготавливают достаточное
количество специалистов по специальностям связанным с данным производством.
1.2 Организационная структура
Несмотря на свои компактные размеры ОАО «Каравай» в соответствии с
основными принципами формальной организации имеет как горизонтальное, и
вертикальное разделение работ, так и развитую систему коммуникаций, построенную
в соответствии с общепринятыми нормами качественного менеджмента.
На практике применяются множество механизмов обеспечивающих эффективную
работу предприятия, начиная от обратной связи, как инструмента функции контроля
и заканчивая управлением настроений групп и коллектива в целом как процесса
функции мотивации. Организационная структура представляет собой совокупность
частей одного целого, некоторые из которых можно выделить четко, например отдел
технолога, производственный цех, пекарня; другие же имеют слабые разграничения
своих функций и не выделяются как часть, к примеру, часто задачи бухгалтера
объединяются с задачами менеджера в комплексе работ по учету и анализу
хозяйственной деятельности.
Можно выделить пять основных частей разного рода занятий приведенных
ниже.
Рисунок 1.1 - Организационная структура
1.3 Должностные обязанности
Отдел инженера включает в себя должности главного инженера и механика.
Главный инженер несет ответственность за качество и выполнение
возложенных на него обязанностей. Осуществляя повседневное руководство всеми
техническими службами предприятия, главный инженер обеспечивает безотказное
производство, и выпуск конкурентоспособной продукции. Занимаясь техногенной
стороной производства он тесно взаимодействует с администрацией и отделом
хозяйственного учета в решении вопросов стратегического и тактического
планирования затрат на покупку, содержание, обновление и нагрузку
производственных фондов.
Особое внимание он уделяет мероприятиям по охране труда, технике
безопасности, промышленной санитарии, эргономичности труда.
Отдельным полем деятельности является его участие в проведении конструкторских
работ содействие изобретательству и рационализаторству.
В непосредственном подчинении у главного инженера находится механик, его
задачей является поддержание действующего парка оборудования предприятия в
исправном состоянии, путем своевременного качественного ремонтного и
технического обслуживания.
Посредником во взаимоотношениях между управленческим звеном и объектом
управления служит должность начальника производства. Эта должность на
предприятии ОАО «Каравай» появилась относительно недавно. Ее появление
объясняется требованием к качеству производственного процесса. Целями
начальника производства является:
организация оперативного контроля за ходом производства, за обеспечением
производства технической документации, инструментом оснасткой, материалами,
комплектующими изделиями.
Координация работы подразделений предприятия, принятие мер по обеспечению
ритмичности выполнения календарных планов производства, урегулирование взаимных
требований и претензий подразделений предприятия.
Обеспечение оперативного ежедневного учета хода производственных заданий,
выполнению суточных норм выпуска готовой продукции по количеству и номенклатуре
изделия.
В подчинении начальника производства находится экспериментальный цех, в
котором осуществляется подготовка исходных данных для расчета норм расхода
материалов на изделие, норм труда на разработку технологических процессов. В
свою очередь эти данные служат первичной информацией для отдела хозяйственного
учета при учете и анализе финансово хозяйственной деятельности.
Правой рукой начальника производства является технолог.
В функции технолога входит разработка и внедрение в производство наиболее
прогрессивных, ресурсосберегающих технологических процессов, с установлением
режимов обработки и машинного времени на вновь вводимые и модернизированные
объекты производства, а также на детали и узлы разовых заказов с учетом
новейших методов обработки. Систематическое изучение причин брака и дефектов в
производстве и участие в их ликвидации. Контроль за соблюдением технологической
дисциплины и принятию своевременных мер по устранению нарушений технологической
дисциплины.
Отдел хозяйственного учета пропускает через себя все потоки, по которым
движется первичная отчетная и финансовая документация.
Перед описанием функций отдела следует сказать то, что предприятие ОАО
«Каравай» в соответствии со ст. 18 Налогового кодекса Российской Федерации и
установленным федеральным законом от 24 июля 2002г № 104-Ф3 “О внесении
изменений и дополнений в часть вторую налогового кодекса Российской Федерации”
применяет упрощенную форму бухгалтерского учета.
А ст. 4 Федерального закона от 21 ноября 1996 г. №129-Ф3 гласит:
“Организации перешедшие на упрощенную систему налогообложения
освобождаются от обязанности ведения бухгалтерского учета если иное не
предусмотрено настоящим пунктом”.
Во главе отдела утверждена должность, заведующая вопросами бухгалтера,
юриста и экономиста. В круг обязанностей этой должности входят вопросы
осуществление организации бухгалтерского учета хозяйственно финансовой деятельности
и формирование учетной политики, исходя из структуры и особенности деятельности
предприятия со всеми вытекающими отсюда задачами.
Юридической стороной этой должности является разработка или принятие
участия в разработке документов правового характера.
Проведение экономического анализа, основываясь на данных бухгалтерского
баланса и производственных показателей, и отчетов инспектора по кадрам, также
входит в обязанности главы отдела хозяйственного учета.
Инспектор по кадрам подчиняется главе отдела хозяйственного учета
Осуществляет прием, увольнение, перевод на другую должность работников
предприятия на основании приказов директора. Заносит данные в личные карточки,
ведет учет стажа и рабочего времени работников, рассчитывает и отчитывается
перед налоговой инспекцией, пенсионным фондом и органами социального
страхования, предоставляя этим инстанциям информацию по доходам каждого
работника предприятия. Организовывает расчет количества отпускных дней разного
вида отпусков и предоставляет данные бухгалтеру.
Директор ОАО «Каравай» проверяет выполнение всех задач перечисленных
отделов, принимая решения по наиболее важным вопросам.
Кроме этого на его ложиться самый большой груз взаимоотношений с внешней
средой организации. Маркетинговые исследования, задачи снабжения, поиск
покупателя, взаимоотношения с государством являются наиболее актуальными
задачами лица занимающего эту должность.
Когда говорят, что труд обыкновенного рабочего заканчивается с последним
звонком конца рабочего дня, то труд управленца не заканчивается даже ночью.
.4 Анализ деятельности малых производственных предприятий
Рассмотрим структуру АИС малого производственного предприятия и ее
взаимосвязи с другими системами.
Рисунок 1.2 - Группы АИС
При рассмотрении АИС будем использовать восемь групп АИС рисунок 1.1, в
соответствии со структурой предприятия.
Взаимосвязи АИС "Основное производство и контроль качества":
Основное производство и контроль качества - одна из важнейших подсистем
АСУ промышленного предприятия. В этой подсистеме ведутся все первичные
документы по основной производственной деятельности и создается отчётная
информация, с которой работают другие подсистемы. Подсистема выполняет сразу
несколько функций: Планирование производства, Учёт производства, Контроль
качества производства и Анализ. П/с "Основное производство и контроль
качества" обменивается информацией со многими подразделениями предприятия.
Взаимосвязи внутри АИС "Основное производство и контроль
качества" представлены на рисунке 1.3
Рис. 1.2. Взаимосвязи внутри АИС "Основное производство и
Рисунок 1.3 - Основное производство и контроль качества
Поток данных в подсистеме "Бухгалтерский учёт" представляет
собой информацию о плановой себестоимости продукции, плановых затратах на
производство, договорных обязательствах, о ценах на продукцию и собственно план
производства. По мере выполнения плана производства, этот поток наполняется
информацией о фактическом производстве, фактической себестоимости и фактических
затратах.
Обмен информацией с подсистемой "Финансовый учёт" идет по
налогам (план и факт выплат), договорным обязательствам, затратам, планируемому
и фактическому производству.
При расчёте себестоимости продукции и учёте производства, используется
информация о затратах на вспомогательные ресурсы, поступающая из подсистемы
"Учёт вспомогательного производства". Это сметы затрат, планы
ремонтов, планы строительства.
При расчёте выполнения плана производства, учитывается информация о
движении ресурсов, поступающая из этой же подсистеме.
Планирование и учёт поступления ресурсов в производство, строится на
основе обмена с подсистемой "Учёт снабжения" информацией о поставках,
договорных обязательствах, ценах на ресурсы. В "Учёт снабжения"
уходит информация о качестве поставляемого сырья.
Подсистема "Учет сбыта и реализации" получает из подсистемы
"Основное производство и контроль качества" сведения о фактическом
производстве и качестве товарной продукции. Выполнение плана производства в
части отгрузки готовой продукции формируется на основе отчетности по
реализации, поступающей из соответствующей подсистемы. Отчетность создается за
различные периоды времени.
Подсистема "Учет персонала" передает в подсистему
"Основное производство и контроль качества" информацию о сотрудниках
и данные по плановому ФЗП. Эти данные участвуют в расчете себестоимости
продукции.
Вся отчётность подсистемы "Основное производство и контроль
качества" передается в подсистему "Управление и анализ" для
проведения дальнейшего анализа и планирования, в т.ч. стратегического.
Внутри подсистемы "Основное производство и контроль качества",
существует интенсивный обмен информацией между подсистемами различных служб
производства и контроля качества.
Подсистема "Учет деятельности производственных цехов"' связана
со всеми остальными службами. В различные подразделения передается отчетность
по производству, описывающая наличие и движение сырья, полуфабрикатов,
продукции и вспомогательных материалов в производстве, как оперативная, так и
периодическая.
Подсистема "Учёт деятельности производственных цехов" состоит
из подсистем отображённых на рисунке 1.4.
Рисунок 1.4 - Подсистема "Учёт деятельности производственных
цехов"
Из подсистемы "Планирование и учет ТЭП" поступает план
производства, из подсистемы "Материальный учет сырья" - план поставок
сырья, из подсистемы "Технологический контроль производства"
передаются нормы расхода, регламент производства. Подсистема "Служба
сертификации" передает в подсистему "Контроль качества" -
информацию о качестве сырья, продукции, полуфабрикатов.
Подсистема "Планирование и учет ТЭП" связана большей частью с
подсистемы "Технологический контроль производства". Из подсистемы
"Технологический контроль производства" передаются ТЭП, нормы расхода
ресурсов по производству, потребности в ресурсах, план и факт потерь в
производстве. Из подсистемы "Учет деятельности производственных
цехов" передается отчетность по производству (ежесуточная, ежемесячная). В
подсистему "Материальный учёт сырья" передается информация о плане
производства. С подсистемы "Контроль качества" происходит обмен
данными по смете содержания.
Подсистема "Материальный учет сырья" передает плановую и
фактическую информацию о поставках сырья и отгрузке продукции
организациям-поставщикам.
Подсистема "Технологический контроль производства" передает в
подсистему "Планирование и учёт ТЭП" технические показатели, нормы
расхода ресурсов по производству, потребности в ресурсах, план и факт потерь в
производстве, а в подсистеме "Учет деятельности производственных цехов"
- нормы расхода ресурсов и потерь, регламенты производства. Из п/с
"Контроль качества" в подсистему "Технический контроль
производства" поступает отчетность о качестве, из подсистемы
"Статистический учет качества" - результаты статистического анализа
качества, из подсистемы "Учет деятельности производственных цехов" -
отчетность по фактическому производству.
Подсистема "Оперативный контроль за деятельностью предприятия"
получает из подсистемы "Учет деятельности производственных цехов"
оперативную информацию по производству, а из подсистемы "Контроль
качества" - оперативную информацию о качестве.
Подсистема "Служба сертификации" передает в различные
подразделения информацию по ГОСТам, ТУ, СтП, а также руководства и формы
паспортов качества в подсистему "Контроль качества". Из подсистемы
"Контроль качества" приходит отчетность по качеству, а из подсистемы
"Статистический учет качества" - результаты статистического анализа
качества.
Подсистема "Контроль качества" получает заказы на анализы от
подсистемы "Оперативный контроль за деятельностью предприятия" и
подсистемы "Учет деятельности производственных цехов". Сюда поступает
информация о наличии сырья, полуфабрикатов, продукции из подсистемы "Учет
деятельности производственных цехов", ГОСТы, ТУ, СтП, руководства и формы
паспортов качества из подсистемы "Службы сертификации",
статистическая отчетность из подсистемы "Статистический учёт
качества". подсистема "Контроль качества" передает оперативную
информацию о качестве, паспорта качества в подсистему "Учет деятельности
производственных цехов" и в подсистему "Оперативный контроль за
деятельностью предприятия", а отчеты - в подсистему "Технологический
контроль производства" и подсистему "Служба сертификации". С
подсистемой "Планирование и учет ТЭП" происходит обмен данными по
смете содержания.
Подсистема "Статистический учет качества" получает из
подсистемы "Контроль качества" накопленную информацию о качестве
продукции, а из Подсистемы "Службы сертификации" - нормативные
документы, и передает результаты статистического анализа в различные подсистемы:
"Контроль качества", "Служба сертификации",
"Технологический контроль производства".
.5 Функциональная схема подсистемы «Учет деятельности малых
производственных цехов»
Подсистема "Учет деятельности производственных цехов" делится
на следующие функциональные модули рисунок 1.4:
Учет движения сырья, полуфабрикатов, продукции.
Позволяет работать с оперативными данными о наличии и движении сырья,
полуфабрикатов и продукции внутри производственного цикла.
Первичный материальный учет поставки сырья, производства и отгрузки
продукции.
Позволяет работать с информацией о фактической поставке сырья,
производстве продукции и отгрузке, и на ее основе, а также, используя
информацию о движении технологических компонентов, план производства,
информацию о качестве и нормативные документы, автоматически составлять
оперативные и периодические отчеты по фактическому производству продукции,
расходах и потерях. Эта отчетность передается в другие подсистемы.
По проекту реконструкции была принята автоматизированная система
управления заводом, состоящая из АСУ технологическими установками, АСУ
объектами общезаводского хозяйства и автоматизированной системы управления
операциями приёма, хранения, отгрузки готовой продукции и сырья.
Рисунок 1.5 - Функциональная схема подсистема "Учет деятельности
производственных цехов"
Интегрированная
автоматизированная система управления заводом строится на базе компьютерной
сети, средств микропроцессорной техники и электроники. Каждая из указанных АСУ
является иерархической и состоит из следующих подсистем:
- подсистемы автоматизированного контроля и управления технологическим
процессом;
подсистемы автоматической противоаварийной защиты (ПАЗ) технологического
процесса и оборудования.
Первая подсистема выполняется на микропроцессорном
программно-технологическом комплексе (ПТК) с сетевой структурой.
Подсистема автоматической противоаварийной защиты (ПАЗ) выполняется на
высоконадёжном микропроцессорном программно-логическом контроллере (ПЛК) с
горячим резервом входов/выходов, процессора, блока памяти.
В ПТК осуществляются информационные и управляющие функции АСУ, и
отображение информации о действиях ПЛК, регистрация срабатывания и контроля за
работоспособным состоянием средств ПАЗ, постоянный контроль состояния воздушной
среды в пределах объекта, постоянный анализ изменения параметров в сторону
критических значений и прогнозирование возможной аварии, проведение операций
безаварийного пуска и остановки технологического объекта.
АИС "Учет деятельности производственных цехов" представляет
собой законченный комплекс программных модулей для внесения, хранения и
обработки всей оперативной информации по основной производственной деятельности
предприятия. Оперативность обрабатываемой информации ни чем не ограничивается,
при этом, накопление ежесуточной информации позволяет осуществлять дальнейший
анализ в разрезе любых временных периодов.
Вся информация о деятельности предприятия разделяется на несколько типов.
Выделяются следующие данные:
• об объемах поступления сырья на установки
• об объемах переработки на установках
• об объемах сжега на установке (для некоторых установок)
• об объемах цеховой отгрузки
• о расходе топлива по установкам
• о расходе топлива на нужды ТЭЦ
• о потерях по установкам
• о выработках газа (для некоторых установок)
• об остатках продукции в цехах
Вся эта информация имеется в распоряжении экономистов производственных
цехов, которые и будут осуществлять оперативный ввод данных. Данные по суточной
деятельности должны быть введены в систему утром следующего дня. В случае
какой-либо ошибки в учете, позднее могут быть внесены изменения, без ущерба для
целостности данных. Вместе с тем, возможно реализовать ведения журнала
изменений, в котором будут отражаться все действия персонала по внесению корректировок
в оперативные данные. Наличие такого журнала позволит не только проводить
анализ качества учета деятельности (выявляя множество ошибок в ведении
посуточного учета), но и следить за тем, как персонал работает с АРМом.
АИС "Учет деятельности малых производственных предприятий"
должна обеспечивать обработку первичной информации по деятельности основного
производства, ее внедрение будет означать появление оперативных данных в
Общезаводской Системе. При чем данные эти должны отражать реальную картину производства
и без каких-либо задержек по времени. На основе этих данных автоматически будут
создаваться различные сводки и отчеты, пригодные для анализа производственной
деятельности на сколь угодно большом временном периоде.
Данные, предоставляемые рассматриваемой АИС, позволят контролировать
дисциплину персонала. Достаточно легко в АРМ Руководство могут быть встроены
отчеты оценивающие интенсивность работы и качество предоставляемой информации.
Такого рода анализ, основываясь на рассчитываемом проценте ошибок конкретных
исполнителей при учете производства, позволит, используя данные за большой
временной период, оценивать качество работы персонала. Собранные статистические
данные позволят более корректно и решительно подходить к вопросу оценки работы
персонала. Все эти обстоятельства послужили причиной в выборе темы для
дипломного проекта.
Создание АИС "Учет деятельности малых производственных
предприятий" открывает большие возможности перед пользователями и
руководством.
Во-первых - это централизованное управление информационными ресурсами,
во-вторых - быстрый и удобный для пользователя просмотр БД, удобная форма ее
заполнения, корректировка, в-третьих - это возможность осуществления поиска по
разным критериям и вывод полученной информации как на экран в режиме
предварительного просмотра, так и на принтер.
.6 Техническое задание
Организационно-экономическая сущность задачи
В соответствии со своими функциями в процессе работы менеджеру по учету
готовой продукции предстоит решать следующие задачи:
приемка готовой продукции на склад предприятия
занесение соответствующих записей в карточки складского учета
выдача продукции со склада по требованиям руководителей и заказчиков с
выпиской счетов
учет остатков готовой продукции
контроль за исполнением обязательств перед клиентом
участие в разрешении конфликтов связанных с браком товаров
предоставление обобщенной информации о продажах того или иного вида
товаров за определенный период времени.
предоставление отчетов по всей номенклатуре ассортимента и его реализации
с указанием доли каждого товара в общем, объеме продаж за квартал.
участие при составлении плана производства
Цели и задачи учета.
Стратегическая цель:
Федеральный закон "О бухгалтерском учете" № 129-ФЗ от 21.11.96
г. указывает на три стоящие перед учетом задачи (пункт 3 статьи 1):
формирование полной и достоверной информации о деятельности организации и
ее имущественном положении, необходимой внутренним пользователям отчетности -
руководителям, учредителям, участникам и собственникам имущества организации, а
также внешним - инвесторам, кредиторам и другим пользователям отчетности;
обеспечение информацией, необходимой внутренним и внешним пользователям
отчетности для контроля за соблюдением законодательства Российской Федерации,
при осуществлении организацией хозяйственных операций и их целесообразностью,
наличием и движением имущества и обязательств, использованием материальных,
трудовых и финансовых ресурсов в соответствии с утвержденными нормами,
нормативами и сметами;
предотвращение отрицательных результатов хозяйственной деятельности
организации и выявление внутрихозяйственных резервов обеспечения ее финансовой
устойчивости .
Постановка задач учета:
Все задачи учета по причинам, обусловившим их возникновение, возможно
подразделить на несколько групп.
) Технологические - зависят от технологических аспектов учета.
Традиционный учет ориентирован на обработку информации на бумажных носителях.
Сделки во всех областях хозяйственной деятельности заключаются, как правило, в
письменной форме - на бумаге. Отсюда задачами специалиста по учету, а в лице и
самого учета, становятся:
во-первых, регистрация информации, т.е. ее ввод с бумажных носителей,
созданных на другом предприятии, в собственную систему учета;
во-вторых, перевод информации из собственной системы учета на бумажный
носитель - для того, чтобы совершенную сделку могло зарегистрировать в своей
системе другое предприятие.
Если бы технология совершения сделок была иной - к примеру, сделки сразу
регистрировались бы в электронной форме, - подобных задач перед специалистом по
учету не было.
Законодательство требует предоставлять информацию на бумажных носителях,
что делает необходимым для работников предприятия перевод ее на бумагу. Как
только законодательство разрешает предоставлять информацию в электронном виде, соответствующим
образом меняются и задачи специалиста по учету: если бы система самостоятельно
пересылала информацию по месту требования, задача специалиста по учету
ограничилась бы формированием такой информации; если бы система еще и
самостоятельно вычисляла информацию, круг технологических задач, стоящих перед
бухгалтером, еще более сузился бы и сводился бы к регистрации информации.
) Алгоритмические - зависят от используемых в учете алгоритмов.
Под алгоритмом понимаются правила исчисления какой-либо величины,
получения результата. Информация предоставляется заинтересованным лицам в виде
отдельных порций, исчисляемых последовательно и по определенным правилам. Кроме
того без получения промежуточных итогов обычно невозможно получить искомого
результата.
Обязанностью специалиста по учету при достижении стратегической цели
оказывается исчисление каждого промежуточного итога, наличие которого
определяется применяемым в каждом случае алгоритмом. Например, для определения
финансового результата (прибыли или убытка) необходимо предварительно вычислить
все доходы и все расходы, которые, в свою очередь, состоят из различных,
неоднородных величин и требуют своего исчисления на более низком уровне.
Организация учета.
Налаживание учета только недавно стало рассматриваться в качестве одной
из приоритетных составляющих процесса производства продукции и услуг, так как
провалы многих инвестиционных проектов обусловлены отсутствием или
некорректностью управленческой информации.
Системы управленческого учета существенно отличаются от бухгалтерских
систем как по охвату, так и, самое главное, по целям и принципам своего
функционирования. Если бухгалтерский (финансовый) учет предназначен для оценки
результатов работы предприятия внешними институтами -акционерами, кредиторами,
госструктурами, то управленческий учет связывает процесс управления и
бизнес-процессы на самом предприятии. Он обеспечивает управленцев предприятия
информацией по всем вопросам хозяйственной деятельности, необходимой для
принятия ими управленческих решений. Главным принципом учета является
целесообразность и полезность генерируемой информации для внутреннего
управления.
С переходом к рыночным отношениям на передний план управления
предприятием выдвинулись принципиально новые задачи, для решения которых
традиционные системы не приспособлены. Это определение действительно
рентабельных видов продукции для оперативного изменения номенклатуры выпуска;
определение эффективности работы отдельных подразделений предприятия;
определение реальной выгодности для предприятия того или иного покупателя и
дифференциация на основе этого сбытовой политики; определение оптимального
уровня контроля над каналами сбыта и т.д.
Такие вопросы можно решать только на базе специально организованного
учета. Причем значимость его настолько велика, что многие компании пошли по
пути организационного выделения работников, занятых учетом.
Рассматривая практические аспекты построения учета на предприятиях,
необходимо четко различать методологическую базу и процедурно-техническую
сторону организации учетной функции. Если в первом случае речь идет о выборе
той или иной методологии или концепции учета, то во втором - о том, как
процедурно построен этот учет и какими техническими средствами он
осуществляется (вручную или с помощью компьютерной системы). При этом обе
стороны имеют самостоятельное значение и могут весьма существенно влиять друг
на друга. Так даже использование самых мощных компьютерных систем не обеспечит
адекватную управленческую информацию, если методология учета затрат,
применяемая на предприятии, является устаревшей. Вместе с тем попытки внедрения
самой современной и точной методологии учета в бумажном варианте могут
оказаться совершенно неоправданными из-за своей колоссальной трудоемкости и
соответствующих издержек.
Методологические аспекты учета. В концептуальном плане учет может быть
построен на основе различных методик, но в любом случае система должна
предоставлять аналитическую информацию в разрезе ее различных видов.
К традиционным объектам, по которым определяются затраты, могут относится
как отдельные подразделения, участки, переделы, так и отдельные заказы, партии,
виды выпускаемой продукции и предоставляемых услуг.
Ключевым вопросом для методологического построения системы учета является
выбор методики распределения накладных расходов. В этом плане обычно выделяют:
метод полного распределения затрат. При этом традиционно используется
метод общих накладных расходов по подразделениям, метод исчисления накладных
расходов по центрам ответственности;
метод исчисления себестоимости по прямым затратам (директ-костинг - direct-costing);
маржинальный подход.
Практически всегда в систему учета входит блок, основанный на
нормативно-сметном методе (стандарт-костинг - standart-costing). Этот блок является основой для планирования затрат,
бюджетирования и управления затратами по отклонениям.
Компьютерные информационные системы учета.
Развитие компьютерных информационных систем поставило учет на качественно
новую техническую основу и тем самым придало мощный импульс процессам его
реорганизации на предприятии. Внедрение таких систем вполне можно отнести к
разряду технической революции в области учета, и ее последствия выходит далеко
за чисто технические рамки.
Главное, что внесли компьютерные системы в сферу учета, это принципиально
возросшая оперативность и математическая точность обработки огромных массивов
управленческой информации и связанные с этим новые возможности аналитики
(включая многомерный анализ).
Сегодня на рынке представлены системы двух больших классов
-финансово-учетные и промышленного учета, которые в свою очередь, делятся еще
на подклассы.
Финансово-учетные системы разработаны для одной (бухгалтерии) или
нескольких областей учета (финансы, логистика, маркетинг, персонал и т.д.). Они
являются довольно гибкими в применении и нередко вполне функционально
достаточными для предприятий, не стремящихся идти дальше автоматизации
финансово-учетных функций. В этом классе некоторые популярные отечественные
системы (например: 1C, БЭСТ, Монолит, Галактика, Эталон) довольно активно
конкурируют на нашем рынке с такими известными западными пакетами, как SunSystems, Scala, Platinum, Concorde XAL.
Промышленные системы учета изначально создавались для управления и
планирования производственного процесса, а другие области учета (также весьма
серьезно проработанные) как бы вырастали из этой сердцевинной функции и
интегрировались с ней. Такие системы, гораздо более дорогие и сложные во
внедрении, в своих самых современных версиях практически универсальны, но
зачастую настроены на одну или несколько отраслей или типов производства.
Входная информация
Первичные документы в ходе товарной деятельности предприятия тщательно
оформляются, обязательно содержат подписи ответственных лиц.
Документальное оформление отправки готового изделия на склад
При поступлении готовой продукции на склад делаются записи в журнале
приема готовой продукции. Т.е. визуально подсчитываются экземпляры и
проверяются на соответствие с данными маршрутного листа.
Далее из журнала приема готовой продукции информация разносится по
карточкам складского учета.
Документальное
оформление составления заказа
Для того, чтобы оформить заказ необходимо удостовериться в наличии товара
на складе для этого просматриваются карточки складского учета. Если товар
имеется на складе, то в данной карточке в графе расход делается запись о
количестве заказанного товара, указывается, кому отпущено, а в графе остаток
подсчитывается остаток. Далее заполняется фактура в двух экземплярах один
остается в отделе хозяйственного учета, другой предоставляется клиенту. Если товара
в достаточном количестве нет на складе , то составляется заявка, на ее
основании составляется план производства и начинается процесс изготовления
продукции. Документ передается менеджеру по учету готовой продукции, для
последующего сопоставления экземпляра реквизитов заявки с реальным результатом.
Процесс изготовления продукции заканчивается сдачей продукции на склад с
заполнением соответствующих статей в журнале учета ТМЦ.
Выходная информация
Результатом обработки входной информации являются:
каталог товаров.
сведения о товарах с группировкой по типам и первой букве названия
товара.
оперативный отчёт о ходе исполнения заказа. Периодичность: по мере
необходимости.
отчёт по товарной продукции, с указанием планового и фактического
выполнения заказа.
Описание реквизитов
Таблица 1.1 - Описание реквизитов информации
|
Наименование реквизитов
выходных документов
|
Характеристика реквизитов
|
|
Тип
|
Максимальная длинна
|
Десят. знаков
|
|
1
|
2
|
3
|
|
|
Наименование
|
Симв.
|
50
|
|
|
Характеристика ткани
|
Симв.
|
50
|
|
|
Единица измерения
|
Симв
|
10
|
|
|
Продолжение таблицы 1.1 -
Описание реквизитов информации
|
|
Цена
|
Денеж.
|
7
|
2
|
|
На складе
|
Числов
|
6
|
|
|
Ожидается
|
Числов
|
6
|
|
|
Размер
|
Текстов
|
6
|
|
|
Поставки прекращены
|
Логичес
|
|
|
|
Категория
|
Текстов
|
30
|
|
|
Название (клиента)
|
Текстов
|
40
|
|
|
Должность
|
Текстов
|
30
|
|
|
Адрес
|
Текстов
|
60
|
|
|
Город
|
Текстов
|
10
|
|
|
Область
|
Текстов
|
15
|
|
|
Индекс
|
Текстов
|
10
|
|
|
Страна
|
Текстов
|
20
|
|
|
Телефон
|
Текстов
|
24
|
|
|
Факс
|
Текстов
|
24
|
|
|
Дата/размещения
|
Дата
|
dd-mm-yy
|
|
|
Дата/исполнения
|
Дата
|
dd-mm-yy
|
|
|
Дата/назначения
|
Дата
|
dd-mm-yy
|
|
|
Цена
|
Денеж
|
7
|
2
|
|
Количество
|
Числ
|
4
|
|
Основание для разработки программы и ее назначение
Разработка данного программного продукта проводится с использованием
сведений, полученных в ОАО «Каравай», г. Краснодар.
Основанием для разработки служит документ "Задание по дипломному проектированию".
Полное наименование разработки: «Автоматизированная система учета готовой
продукции на предприятии» (по материалам ОАО «Каравай», г. Краснодар)
Программа предназначена для ежедневной работы по учету товаров и заказов,
а также для предоставления отчетности и аналитической информации менеджерам
предприятия.
В программе должна быть предусмотрена возможность хранения, изменения,
добавления и извлечения информации о товарах, имеющихся товарах, и заказах с
распечаткой сведений о реализации.
Программа предназначена для эксплуатации на персональных компьютерах под
управлением любой операционной системы семейства Windows. Полный перечень требований к программному и
аппаратному обеспечению, предъявляемый программой описывается ниже.
Требования к программе
Основные требования. Необходимо создать автоматизированную систему учета
готовой продукции.
Программа должна предусматривать возможность обновления хранимых данных и
возможность корректировки выходных данных. Для программы допускается
использование ее на других предприятиях с похожей деятельностью. Интерфейс
программы должен быть стандартным, принятым в среде Windows.
Требования к составу выполняемых функций.
Учетные входящие.
Производить ввод и редактирование товаров поступающих на склад;
показывать товары по категориям;
Вводить и изменять заказы товаров, вычислять промежуточные итоги,
отображаемые в главной форме, показывать остаток товара на складе;
Добавлять и изменять сведения о товарах.
Добавлять и изменять типы товаров
Учетные исходящие
Отображать имя и местоположение клиента, выводить все его заказы для
выбранной компании, и дата - хронологические записи для выбранного заказа.
Печатать каталог товаров. (двухстраничный заголовок отчета; фотографии
для каждого типа; начало каждого типа на новой странице; группировка всех
записей типа на одной странице; печать формы заказа на отдельной странице в
примечании отчета).
Печатать сведения о товарах с группировкой по первой букве названия
товара.
Печатать сведения о товарах по типам. (в три столбца, каждый тип начинать
в новом столбце).
Аналитические
Отображать квартальные обороты заказов каждого товара и полный итог за
исследуемый год с условием отбора по клиенту;
Печатать сведения об объемах продаж в убывающем порядке с целью
определения наиболее крупных заказов;
Печатать квартальные итоги по сумме продаж в отчете; с возможностью
просмотра информации о записи. (предусмотреть форму для запроса периода
отчета);
Выводить отчет продаж за исследуемый период по типам. (в подчиненном
отчете выводить цифры, а в главном диаграмму);
Предоставить таблицу и график в виде гистограммы о продажах товаров в
каждом квартале отчетного года;
Условия эксплуатации.
Программа предназначена для эксплуатации на персональных компьютерах,
точные требования, к конфигурации которых приводятся ниже.
Для использования программы пользователю необходимо обладать знаниями и
навыками работы в операционной системе Windows.
Условия окружающей среды
Для функционирования программного продукта должны быть приемлемыми для
безотказной работы аппаратного обеспечения, на котором эксплуатируется
программа. Для нормальной работы в этом плане учитываются только эргономические
требования, которые связаны не столько с устранением сбоев работы программы,
сколько удобства работы пользователя с приложением программы с компьютером.
Требования надежности к приложению.
Программный продукт должен устойчиво функционировать в программной среде Windows XP/Vista/7, не
вызывать сбоев в своей работе и в работе операционной системы.
Сбой в работе аппаратного обеспечения и операционной системы может
приводить к аварийному завершению программы, однако после этого она должна
оставаться полностью функциональной, при условии, что сбой не вызвал
повреждения данных или кода программы.
Программа должна обеспечивать ссылочную целостность данных. При
редактировании данных пользователем должна сохраняться целостность всех данных.
Удаление записей таблиц, на которые имеются ссылки в других таблицах, должно
вызывать появления предупреждения о каскадном удалении соответствующих записях.
Наличие в таблицах ссылок на несуществующие записи в других таблицах не
допускаются.
Формы ввода программы должны контролировать целостность, корректность и
непротиворечивость данных вводимым пользователем.
Программа не должна вызывать приостановления работы операционной системы
и других программ в процессе своей работы. Она должна работать в многозадачном
режиме и передавать свободные кванты времени операционной системе.
Требования к составу и параметрам технических средств.
Как уже отмечалось выше, данный продукт должен устойчиво функционировать
в следующих средах: MS Windows XP/Vista/7, поэтому
большая часть минимальных требований накладывается операционной системой, а не
программой. Минимальное аппаратное обеспечение, необходимое для устойчивого
функционирования программы достаточно среднего офисного компьютера и зависит не
столько от самой автоматизированной системы, сколько от программы, на которой
она написана. Необходимый объем жесткого диска зависит от прочих программных
средств, установленных на данном компьютере.
Требования к информационной и программной совместимости.
Требования на языки программирования и иные средства реализации
следующие: необходимо, чтобы средство программирования смогло обеспечить все
для того, чтобы автоматизированная система смогла работать исправно.
Допускается изменение формата выходных данных в новых версиях, однако
желательно, чтобы формат выходных данных оставался неизменным - а именно,
структура баз данных, имена атрибутов, расположение и формат файлов
конфигурации.
Требования к программной документации.
Документация по данному программному продукту должна включать:
описание структуры хранимых данных;
описание алгоритма расчетов;
руководство пользователя;
инструкцию по установки программы.
Цели автоматизации. Процесс анализа и учета довольно долгий и
однообразный. Анализ заключается в однообразной обработке большого числа
информации, часто используя простые методы. Для такой работы очень удобно
использовать компьютер. Таким образом, можно выделить следующие преимущества применения
автоматизированной системы для решения данной задачи:
ускорение обработки;
уменьшение числа ошибок, которые обычно свойственны людям;
удешевление процесса анализа (путем уменьшения времени работы эксперта);
наглядность и простота обработки;
возможность проведения анализа пользователями, не имеющими
специализированных навыков по работе с автоматизированной системой.
Проектная часть
.1
Требования, которым должна удовлетворять организация базы данных
Изучением этого вопроса долгое время занимались различные группы людей в
учреждениях, использующих ЭВМ, в правительственных комиссиях, на вычислительных
центрах коллективного пользования. Комитет CODASYL опубликовал отчеты на эту
тему (CODASYL-организация, разработавшая язык КОБОЛ). Организации пользователей
IBM SHARE и GUIDE в своем отчете сформулировали требования к системе управления
базами данных. Организация ACiM (Association for Computing Machinery) также
занималась изучением этого вопроса.
Ниже перечислены основные требования к организации базы данных, которые
учтены в данной работе.
.1.1
Установление многосторонних связей
Различным программистам требуются различные логические файлы. Эти файлы
получаются из одной и той же совокупности данных. Между элементами запоминаемых
данных могут существовать различные связи. Некоторые базы данных будут
содержать сложные переплетения взаимосвязей. Метод организации данных должен
быть таким, чтобы обеспечивалась возможность удобного представления этих
взаимосвязей и быстрого согласования вносимых в них изменений. Система
управления базами данных должна обеспечивать возможность получения требуемых
логических файлов из имеющихся данных и существующих между ними связей.
Необходимо, чтобы существовало хотя бы небольшое сходство между представлением
логического файла в прикладной программе и способом физического хранения
данных.[7, 10, 11].
2.1.2
Производительность
Базы данных, специально разработанные для использования их оператором
терминала, обеспечивают время ответа, удовлетворительное для диалога человек -
терминал. Кроме того, система баз данных должна обеспечивать соответствующую
пропускную способность. В системах, рассчитанных на небольшой поток запросов,
пропускная способность накладывает незначительные ограничения на структуру базы
данных. В системах с большим потоком запросов, например в системах
резервирования авиабилетов, пропускная способность оказывает решающее влияние
на выбор организации физического хранения данных.
В системах, предназначенных только для пакетной обработки, который будет
использоваться в нашей работе, время ответа не так важно и метод физической
организации может выбираться из условий обеспечения эффективной пакетной
обработки.[7, 10, 11].
2.1.3
Минимальные затраты
Для уменьшения затрат на создание и эксплуатацию базы данных выбираются
такие методы организации, которые минимизируют требования к внешней памяти. При
использовании этих методов физическое представление данных в памяти может
сильно отличаться от того представления, которое использует прикладной
программист. Преобразование одного представления в другое осуществляет
программное обеспечение либо, если возможно, аппаратные или микропрограммные
средства. В таких случаях приходится выбирать между затратами на алгоритм
преобразования и экономией памяти.[7, 10, 11].
.1.4
Минимальная избыточность
В системах обработки, существовавших до использования систем управления
базами данных, информационные фонды обладали очень высоким уровнем
избыточности. Большинство ленточных библиотек содержало большое количество
избыточных данных. Даже при использовании баз данных по мере возрастания
информации, объединяемой в интегрированные базы данных, потенциальная
возможность появления избыточных данных постепенно увеличивается. Избыточные
данные дороги в том смысле, что они занимают больше памяти, чем это необходимо,
и требуют более одной операции обновления. Целью организации базы данных должно
быть уничтожение избыточных данных там, где это выгодно, и контроль за теми
противоречиями, которые вызываются наличием избыточных данных.[7, 10, 11].,
2.1.5
Возможности поиска
Пользователь базы данных может обращаться к ней с самыми различными
вопросами по поводу хранимых данных. В большинстве современных коммерческих
приложений типы запросов предопределены, и физическая организация данных
разрабатывается для их обработки с требуемой скоростью. Возросшие требования к
системам заключаются в обеспечении обработки таких запросов или формирования
таких ответов, которые заранее не запланированы. [7, 10, 11].
.1.6
Целостность
Если база данных содержит данные, используемые многими пользователями,
очень важно, чтобы элементы данных и связи между ними не разрушались.
Необходимо учитывать возможность возникновения ошибок и различного рода
случайных сбоев. Хранение данных, их обновление, процедуры включения данных
должны быть такими, чтобы система в случае возникновения сбоев могла
восстанавливать данные без потерь. Необходимо, чтобы вычислительная система
гарантировала целостность хранимых в ней данных.[7, 10, 11].
2.1.7
Безопасность и секретность
Данные в системах баз данных должны храниться в тайне и сохранности.
Запоминаемая информация иногда очень важна для использующего ее учреждения. Она
не должна быть утеряна или похищена. Для увеличения жизнестойкости информации в
базе данных важно защищать ее от аппаратных или программных сбоев, от
катастрофических и криминальных ситуаций, от некомпетентного или злонамеренного
использования лицами, которые могут ее неправильно употребить.
Под безопасностью данных понимают защиту данных от случайного или
преднамеренного доступа к ним лиц, не имеющих на это право, от неавторизованной
модификации данных или их уничтожения.
Секретность определяют как право отдельных лиц или организаций
определять, когда, как и какое количество соответствующей информации может быть
передано другим лицам или организациям.[7, 10, 11].
.1.8 Связь с
прошлым
Организации, которые в течение какого-то времени эксплуатируют системы
обработки данных, затрачивают значительные средства на написание программ,
процедур и организацию хранения данных. В том случае, когда фирма начинает
использовать на вычислительной установке новое программное обеспечение
управления базами данных, очень важно, чтобы при этом она могла работать с уже
существующими на этой установке программами, обрабатываемые данные можно было
бы соответствующим образом преобразовывать. Такое условие требует наличия
программной и информационной совместимости, и ее отсутствие может стать
основным сдерживающим фактором при переходе к новым системам управления базами
данных. Важно, однако, чтобы проблема связи с прошлым не сдерживала развитие
средств управления базами данных. [7, 10, 11].
2.1.9 Связь с
будущим
Особенно важной представляется связь с будущим. В будущем данные и среда
их хранения изменятся по многим направлениям. Любая коммерческая организация со
временем претерпевает изменения. Особенно дорогими эти изменения оказываются
для пользователей системами обработки данных. Огромные затраты, которые
требуются для реализации самых простых изменений, сильно тормозят развитие этих
систем. Эти затраты расходуются на преобразование данных, перезапись и отладку
прикладных программ, явившихся результатом внесения изменений. Со временем
число прикладных программ в организации растет, и поэтому перспектива
перезаписи всех этих программ кажется нереальной. Одна из самых важных задач
при разработке баз данных-запланировать базу данных таким образом, чтобы
изменения ее можно было выполнять без модификации прикладных программ.[7, 10,
11].
.1.10
Простота использования
Средства, которые используются для представления общего логического
описания данных, должны быть простыми и изящными.
Интерфейс программного обеспечения должен быть ориентирован на конечного
пользователя и учитывать возможность того, что пользователь не имеет
необходимой базы знаний по теории баз данных. [7, 10, 11].
.2 Язык SQL
является инструментом, предназначенным для обработки и чтения данных,
содержащихся в компьютерной базе данных. SQL - это сокращенное название
структурированного языка запросов (Structured Query Language). Как следует из
названия, SQL является языком программирования, который применяется для
организации взаимодействия пользователя с базой данных. На самом деле SQL
работает только с базами данных реляционного типа. Согласно принятой схеме, в
вычислительной системе имеется база данных, в которой хранится важная
информация. Если вычислительная система относится к сфере бизнеса, то в базе
данных может храниться информация о материальных ценностях, выпускаемой
продукции, объемах продаж и зарплате. В базе данных на персональном компьютере
может храниться информация о выписанных чеках, телефонах и адресах или
информация, извлеченная из более крупной вычислительной системы. Компьютерная
программа, которая управляет базой данных, называется системой управления базой
данных, или СУБД.
Если пользователю необходимо прочитать данные из базы данных, он
запрашивает их у СУБД с помощью SQL. СУБД обрабатывает запрос, находит
требуемые данные и посылает их пользователю. Процесс запрашивания данных и
получения результата называется запросом к базе данных: отсюда и название -
структурированный язык запросов.
Однако это название не совсем соответствует действительности. Во-первых,
сегодня SQL представляет собой нечто гораздо большее, чем простой инструмент
создания запросов, хотя именно для этого он и был первоначально предназначен.
Несмотря на то, что чтение данных по-прежнему остается одной из наиболее важных
функций SQL, сейчас этот язык используется для реализации всех функциональных
возможностей, которые СУБД предоставляет пользователю, а именно:
·
Организация
данных. SQL дает пользователю возможность изменять структуру представления
данных, а также устанавливать отношения между элементами базы данных.
·
Чтение данных.
SQL дает пользователю или приложению возможность читать из базы данных
содержащиеся в ней данные и пользоваться ими.
·
Обработка данных.
SQL дает пользователю или приложению возможность изменять базу данных, т.е.
добавлять в нее новые данные, а также удалять или обновлять уже имеющиеся в ней
данные.
·
Управление
доступом. С помощью SQL можно ограничить возможности пользователя по чтению и
изменению данных и защитить их от несанкционированного доступа.
·
Совместное
использование данных. SQL координирует совместное использование данных
пользователями и работающими параллельно, чтобы они не мешали друг другу.
·
Целостность
данных. SQL позволяет обеспечить целостность базы данных, защищая ее от
разрушения из-за несогласованных изменений или отказа системы.
Таким образом, SQL является достаточно мощным языком для взаимодействия с
СУБД.
Во-вторых, SQL - это не полноценный компьютерный язык типа COBOL, FORTRAN
или С. В SQL нет оператора IF для проверки условий, нет оператора GOTO для
организации переходов и нет операторов DO или FOR для создания циклов. SQL
является подъязыком баз данных, в который входит около тридцати операторов,
предназначенных для управления базами данных. Операторы SQL встраиваются в
базовый язык, например COBOL, FORTRAN или С, и дают возможность получать доступ
к базам данных. Кроме того, из такого языка, как С, операторы SQL можно
посылать СУБД в явном виде, используя интерфейс вызовов функций.
Наконец, SQL - это слабо структурированный язык, особенно по сравнению с
такими сильно структурированными языками, как С или Pascal. Операторы SQL
напоминают английские предложения и содержат "слова-пустышки", не
влияющие на смысл оператора, но облегчающие его чтение. В SQL почти нет
нелогичностей, к тому же имеется ряд специальных правил, предотвращающих
создание операторов SQL, которые выглядят как абсолютно правильные, но не имеют
смысла.
Несмотря на не совсем точное название, SQL на сегодняшний день является
единственным стандартным языком для работы с реляционными базами данных. SQL -
это достаточно мощный и в то же время относительно легкий для изучения
язык.[13, 8].
2.2.1 Достоинства
SQL
SQL - это легкий для понимания язык и в то же время универсальное
программное средство управления данными.
Успех языку SQL принесли следующие его особенности:
• независимость от конкретных СУБД;
• наличие стандартов;
• одобрение компанией IBM (СУБД DB2);
• поддержка со стороны компании Microsoft (протокол ODBC);
• реляционная основа;
• высокоуровневая структура, напоминающая английский язык;
• возможность выполнения специальных интерактивных запросов:
• обеспечение программного доступа к базам данных;
• возможность различного представления данных;
• полноценность как языка, предназначенного для работы с базами данных;
• возможность динамического определения данных;
• поддержка архитектуры клиент/сервер.
Все перечисленные выше факторы явились причиной того, что SQL стал
стандартным инструментом для управления данными на персональных компьютерах,
мини-компьютерах и больших ЭВМ. Ниже эти факторы рассмотрены более
подробно.[13, 8, 17].
.3 Архитектуры баз данных
Для рассмотрения способов организации баз данных нужно определить
несколько понятий.
Ядро БД отвечает за управление данными во внешней памяти, управление
буферами оперативной памяти, управление транзакциями и журнализацию. Соответственно,
можно выделить такие компоненты ядра (по крайней мере, логически, хотя в
некоторых системах эти компоненты выделяются явно), как менеджер данных,
менеджер буферов, менеджер транзакций. Ядро БД обладает собственным
интерфейсом, не доступным пользователям напрямую и используемым в программах.
Ядро БД является основной резидентной частью СУБД. При использовании
архитектуры "клиент-сервер" ядро является основной составляющей
серверной части системы.
Основной функцией компилятора языка БД является компиляция операторов
языка БД в некоторую выполняемую программу.
В отдельные утилиты БД обычно выделяют такие процедуры, которые слишком
накладно выполнять с использованием языка БД, например, загрузка и выгрузка БД,
сбор статистики, глобальная проверка целостности БД и т.д. Утилиты
программируются с использованием интерфейса ядра БД, а иногда даже с
проникновением внутрь ядра.
Общий состав средств, необходимых для работы готового приложения с БД,
показан на рисунке 2.1 Согласно этой общей схеме, мы имеем цепочку
Приложение -> Ядро БД -> базы данных. В структуре приложения
имеется цепочка Невизуальные компоненты -> Визуальные компоненты.
Невизуальные компоненты предоставляют программисту некоторые функции по
управлению ядром базы данных, а также самими данными. С помощью Визуальных
компонент данные отображаются на экране (таблицы, списки, выпадающие списки,
графики и др.). Местоположение ядра БД и самих баз данных в этой цепочке не
отражены.
Местоположение Ядра БД и баз данных зависит от используемой архитектуры.
Имеется три разновидности архитектур баз данных:
• локальные базы данных и архитектура "файл-сервер";
• архитектура "клиент-сервер";
• многозвенная (трехзвенная N-tier или multi-tier) архитектура.
Использование той или иной архитектуры накладывает сильный отпечаток на
общую идеологию работы приложения, на программный код в приложении, на состав
компонентов для работы с БД, используемых в приложении (прежде всего это
касается невизуальных компонентов).[4, 15].
Локальные
базы данных и архитектура "файл-сервер"
При работе с локальными базами данных сами БД расположены на том же
компьютере, что и приложения, осуществляющие доступ к ним. Работа с БД
происходит в однопользовательском режиме. Ядро БД распложено на компьютере
пользователя. Приложение ответственно за поддержание целостности БД и за
выполнение запросов к БД. Общая схема однопользовательской архитектуры показана
на рисунке 2.1
При работе в архитектуре "файл-сервер" БД и приложение
расположены на файловом сервере сети (например, Novell NetWare). Возможна многопользовательская
работа с одной и той же БД, когда каждый пользователь со своего компьютера
запускает приложение, расположенное на сетевом сервере.
Тогда на компьютере пользователя запускается копия приложения. По каждому
запросу к БД из приложения, данные из таблиц БД перегоняются на компьютер
пользователя, независимо от того, сколько реально нужно данных для выполнения
запроса. После этого выполняется запрос.
Каждый пользователь имеет на своем компьютере локальную копию данных,
время от времени обновляемых из реальной БД, расположенной на сетевом сервере.
При этом изменения, которые каждый пользователь вносит в БД, могут быть до
определенного момента неизвестны другим пользователям, что делает актуальной
задачу систематического обновления данных на компьютере пользователя из
реальной БД. Другой актуальной задачей является блокирование записей, которые
изменяются одним из пользователей: это необходимо для того, чтобы в это время
другой пользователь не внес изменений в те же данные. В архитектуре "файл-сервер"
вся тяжесть выполнения запросов к БД, управления целостностью БД ложится на
приложение пользователя. БД на сервере является пассивным источником данных.
Общая схема архитектуры "файл-сервер" показана на рисунке 2.1.
Кардинальных различий с точки зрения архитектуры между
однопользовательской архитектурой и архитектурой "файл-сервер" нет. И
в том и в ином случае в качестве СУБД применяются так называемые
"персональные" (или "локальные") СУБД такие как Paradox,
dBase и пр. Сама база данных в этом случае представляет собой набор таблиц,
индексных файлов, файлов полей комментариев (мемо-полей) и пр., хранящихся в
одном каталоге на диске в виде отдельных файлов.[4].
Удаленные
базы данных и архитектура "клиент-сервер"
Архитектура "файл-сервер" неэффективна, по крайней мере, в двух
отношениях:
1. При выполнении запроса к базе данных,
расположенной на файловом сервере, в действительности происходит запрос к
локальной копии данных на компьютере пользователя. Поэтому перед выполнением
запроса данные в локальной копии обновляются из реальной БД. Данные обновляются
в полном объеме. Так, если таблица БД состоит из 1000 записей, а для выполнения
запроса (например, выдать сумму премий за октябрь в отделе Y) реально нужно 10
записей, все равно перегоняются все 1000 записей. Таким образом, не нужно иметь
слишком много пользователей и запросов от них, чтобы серьезно ''забить"
сеть, что, конечно же, не может не сказаться на ее быстродействии.
2. Обеспечение целостности БД
производится из приложений. Это потенциальный источник ошибок, нарушающих
физическую и логическую целостность БД, поскольку различные приложения могут
производить контроль целостности БД по-разному, взаимоисключающими способами,
или не проводить такого контроля вовсе. Намного эффективнее управлять БД из единого
места и по единым законам, нежели из разных приложений и по потенциально разным
законам (все зависит от того, как написано приложение). Поэтому безопасность
при работе в архитектуре "файл-сервер" невысока и всегда присутствует
элемент неопределенности. Секретность и конфиденциальность при работе с БД в
архитектуре "файл-сервер" обеспечить также тяжело - любой, кто имеет
доступ в каталог сетевого сервера, где хранится БД, может изменять таблицы БД
любым образом, копировать их, заменять и т.д. [4].
Архитектура "клиент-сервер" разделяет функции приложения
пользователя (называемого клиентом) и сервера.
Приложение-клиент формирует запрос к серверу, на котором расположена БД,
на структурном языке запросов SQL. Удаленный сервер принимает запрос и
переадресует его SQL-серверу БД. SQL-сервер - это специальная программа,
управляющая удаленной базой данных. SQL-сервер обеспечивает интерпретацию
запроса, его выполнение в базе данных, формирование результата выполнения
запроса и выдачу его приложению-клиенту. При этом ресурсы клиентского
компьютера не участвуют в физическом выполнении запроса; клиентский компьютер
лишь отсылает запрос к серверной БД и получает результат, после чего
интерпретирует его необходимым образом и представляет пользователю. Так как
клиентскому приложению посылается результат выполнения запроса, по сети
"путешествуют" только те данные, которые необходимы клиенту. В итоге
снижается нагрузка на сеть. Поскольку выполнение запроса происходит там же, где
хранятся данные (на сервере), нет необходимости в пересылке больших пакетов
данных. Кроме того, SQL-сервер, если это возможно, оптимизирует полученный
запрос таким образом, чтобы он был выполнен в минимальное время с наименьшими
накладными расходами.
Все это повышает быстродействие системы и снижает время ожидания
результата запроса.
При выполнении запросов сервером существенно повышается степень
безопасности данных, поскольку правила целостности данных определяются в базе
данных на сервере и являются едиными для всех приложений, использующих эту БД.
Таким образом, исключается возможность определения противоречивых правил
поддержания целостности. Мощный аппарат транзакций, поддерживаемый
SQL-серверами, позволяет исключить одновременное изменение одних и тех же
данных различными пользователями и предоставляет возможность откатов к
первоначальным значениям при внесении в БД изменений, закончившихся аварийно.
Таким образом, функциями приложения-клиента являются:
1. посылка к серверу запросов;
2. интерпретация результатов запросов, полученных от сервера, и
представление их пользователю в требуемой форме;
. реализация интерфейса пользователя.сервер - это программа,
расположенная на компьютере сетевого сервера. SQL-сервер должен быть загружен
на момент принятия запроса от клиента. Функциями сервера БД являются:
1. прием запросов от приложений-клиентов, интерпретация запросов,
выполнение запросов в БД, отправка результата выполнения запроса
приложению-клиенту;
2. управление целостностью БД, обеспечение системы безопасности,
блокировка неверных действий приложений-клиентов;
. хранение бизнес-правил, часто используемых запросов в уже
интерпретированном виде;
. обеспечение одновременно безопасной и отказоустойчивой
многопользовательской работы с одними и теми же данными. В архитектуре
"клиент-сервер" используются так называемые "удаленные"
(или "промышленные") СУБД. Промышленными они называются из-за того.
что именно СУБД этого класса могут обеспечить работу информационных систем
масштаба среднего и крупного предприятия, организации, банка. Локальные СУБД
предназначены для однопользовательской работы или для обеспечения работы
информационных систем, рассчитанных на небольшие группы пользователей.[4, 15,
11].
К разрядку промышленных СУБД принадлежат: Oracle, Gupta, Informix,
Sybase, MS SQL Server, DB2, InterBase и ряд других.
Как правило, SQL-сервер управляется отдельным сотрудником или группой
сотрудников (администраторы SQL-сервера). Они управляют физическими
характеристиками баз данных, производят оптимизацию, настройку и
переопределение различных компонентов БД, создают новые БД, изменяют
существующие и т.д., а также выдают привилегии (разрешения на доступ
определенного уровня к конкретным БД, SQL-серверу) различным пользователям.
Кроме этого, существует отдельная категория сотрудников, называемых
администраторами баз данных. Как правило, это администраторы сервера,
разработчики БД или пользователи, имеющие привилегии на создание, изменение,
настройку оптимальных параметров отдельных серверных БД. Администраторы БД
также отвечают за предоставление прав на разноуровневый доступ к сопровождаемым
ими БД для других пользователей.[4, 15, 11].
Использование архитектуры "клиент-сервер":
1. резко уменьшает сетевой трафик:
2. понижает сложность приложений-клиентов (поскольку тем уже нет
необходимости обеспечивать целостность и безопасность БД и следить за
параметрами многопользовательской работы с БД);
. понижает требования к аппаратным средствам, на которых эти
приложения функционируют (т.е. к компьютерам пользователей-клиентов):
. повышает надежность БД, ее целостность, безопасность и
секретность.
.4 Краткое описание выбранной среды разработки
Поскольку использование баз данных является одним из краеугольных камней,
на которых построено существование различных организаций, пристальное внимание
разработчиков приложений баз данных вызывают инструменты, при помощи которых
такие приложения можно было бы создавать. Выдвигаемые к ним требования в общем
виде можно сформулировать как: "быстрота, простота, эффективность,
надежность".
Среди большого разнообразия продуктов для разработки приложений Delphi
занимает одно из ведущих мест. Delphi отдают предпочтение разработчики с разным
стажем, привычками, профессиональными интересами. С помощью Delphi написано
колоссальное количество приложений, десятки фирм и тысячи программистов-одиночек
разрабатывают для Delphi дополнительные компоненты.[4].
В основе такой общепризнанной популярности лежит тот факт, что Delphi,
как никакая другая система программирования, удовлетворяет изложенным выше
требованиям. Действительно, приложения с помощью Delphi разрабатываются быстро,
причем взаимодействие разработчика с интерактивной средой Delphi не вызывает
внутреннего отторжения, а наоборот, оставляет ощущение комфорта.
Delphi-приложения эффективны, если разработчик соблюдает определенные правила
(и часто - если не соблюдает). Эти приложения надежны и при эксплуатации
обладают предсказуемым поведением.[4, 22].
Пакет Delphi - продолжение линии компиляторов языка Pascal корпорации
Borland. Pascal как язык очень прост, а строгий контроль типов данных способствует
раннему обнаружению ошибок и позволяет быстро создавать надежные и эффективные
программы. Корпорация Borland постоянно обогащала язык. Когда-то в версию 4.0
были включены средства раздельной трансляции, позже, начиная с версии 5.5,
появились объекты, а в состав шестой версии пакета вошла полноценная библиотека
классов Turbo Vision, реализующая оконную систему в текстовом режиме работы
видеоадаптера. Это был один из первых продуктов, содержавших интегрированную
среду разработки программ.
Среда программирования напоминает пакет Visual Basic. В вашем
распоряжении несколько отдельных окон: меню и инструментальные панели, Object
Inspector (в котором можно видеть свойства объекта и связанные с ним события),
окна визуального построителя интерфейсов (Visual User Interface Builder),
Object Browser (позволяющее изучать иерархию классов и просматривать списки их
полей, методов и свойств), окна управления проектом (Project Manager) и
редактор.содержит полноценный текстовый редактор типа Brief, назначения клавиш
в котором соответствуют принятым в Windows стандартам, а глубина иерархии
операций Undo неограниченна. Как это стало уже обязательным, реализовано
цветовое выделение различных лексических элементов программы. Процесс
построения приложения достаточно прост. Нужно выбрать форму (в понятие формы
входят обычные, диалоговые, родительские и дочерние окна MDI), задать ее
свойства и включить в нее необходимые компоненты (видимые и, если понадобится,
неотображаемые): меню, инструментальные панели, строку состояния и т. п.,
задать их свойства и далее написать (с помощью редактора исходного кода)
обработчики событий. Object Browser Окна типа Object Browser стали неотъемлемой
частью систем программирования на объектно-ориентированных языках. Работа с
ними становится возможной сразу после того, как вы скомпилировали приложение.сt
Manager - это отдельное окно, где перечисляются модули и формы, составляющие
проект. При каждом модуле указывается маршрут к каталогу, в котором находится
исходный текст. Жирным шрифтом выделяются измененные, но еще не сохраненные
части проекта. В верхней части окна имеется набор кнопок: добавить, удалить,
показать исходный текст, показать форму, задать опции и синхронизировать
содержимое окна с текстом файла проекта, т. е. с головной программой на языке
Pascal.
Опции, включая режимы компиляции, задаются для всего проекта в целом. В
этом отношении традиционные make-файлы, используемые в компиляторах языка C,
значительно более гибки.Component Library (VCL) Богатство палитры объектов для
построения пользовательского интерфейса - один из ключевых факторов при выборе
инструмента визуального программирования. При этом для пользователя имеет
значение как число элементов, включенных непосредственно в среду, так и
доступность элементов соответствующего формата на рынке. [4, 22].
2.5 Проектирование структуры базы данных
В первую очередь для решения поставленной задачи необходимо выбрать
структуру хранения информации.
Существует два способа организации информационных массивов:
файловая организация и организация базы данных. Файловая организация
предполагает специализацию и хранение информации, ориентируясь на одну
прикладную задачу, и обеспечивается самим программистом. Файловая организация
позволяет достигнуть высокой скорости обработки информации, но узкая специализация
программ и файлов с данными может служить причиной большой избыточности.
В наше время при создании АСУ требуется качественно новый подход к
организации данных. К организации данных в АСУ предъявляют два основных
требования:
Интеграция данных, когда все данные накапливаются и хранятся
централизованно, создавая динамично обновляемую модель предметной области.
Максимальная возможная независимость от прикладных программ.
Выполнение этих требований привело к созданию единой (для всех задач
системы) базы данных БД. Преимущества БД в АСУ состоят в следующем:
а) Централизованное управление всеми ресурсами, синхронная поддержка
данных для всех приложений.
б) Отсутствие проблемы избыточности данных вследствие их интеграции.
в) Однократный ввод и многократное использование данных благодаря
устранению дублирования.
г) Унификация средств организации данных и независимость прикладных
программ от организации данных. Исходя из приведенных доводов, была выбрана
организация базы данных.
2.5.1 Структура БД
При проектировании БД необходимо решить вопрос о наиболее эффективной
структуре данных. Основные цели, которые при этом преследуются:
обеспечить быстрый доступ к данным в таблицах;
исключить ненужное повторение данных, которое может явиться причиной
ошибок при вводе и нерационального использования дискового пространства;
обеспечить целостность данных таким образом, чтобы при изменении одних
объектов автоматически происходило соответствующее изменение связанных с ними
других объектов.
Главная задача данной работы заключается в необходимости автоматизации
производственных цехов, а также возможность предоставления оперативной
информации по установкам, за определенный период или за конкретные дни для hуководства. Для её решения была
разработана АИС, в состав которой входят пока девять таблиц (файлов, имеющих
расширение dbf).
Таблица 2.1 - Структура таблицы "Переработка, выработка"(Per_Vur.dbf)
|
Описание поля
|
Поле
|
Тип
|
Ширина поля
|
|
Дата ввода
|
DATA_V
|
D
|
|
|
Код движения
|
KOD_DV
|
N
|
10
|
|
Код установки
|
KOD_USTN
|
N
|
30
|
|
Код продукции
|
KOD_PROD
|
С
|
10
|
|
Количество
|
KOLVO
|
N
|
153
|
Индекс: P_V.NTX по DTOS (DATA_V) + STR(KOD_USTN,
3)
В данной таблице хранятся данные, переработки и выработки по всем
установкам и видам продукции.
Таблица 2.2 - Структура таблицы "Отгрузка, сжег"(Otg_Sjog.dbf)
|
Описание поля
|
Поле
|
Тип
|
Ширина поля
|
|
Дата ввода
|
DATA_V
|
D
|
|
|
Код расхода
|
KOD_RAS
|
N
|
10
|
|
Код установки
|
KOD_USTN
|
N
|
30
|
|
Код продукции
|
KOD_PROD
|
С
|
10
|
|
Количество
|
KOLVO
|
N
|
153
|
Индекс: O_S.NTX по DTOS (DATA_V) + STR(KOD_USTN,
3)
В этой таблице находятся данные по отгрузке и сжегу продукции для всех
установок.
Таблица 2.3 - Структура таблицы "Расход топлива"(RAS_TOP.dbf)
|
Описание поля
|
Поле
|
Тип
|
Ширина поля
|
|
Дата ввод
|
DATA_V
|
D
|
|
|
Код установки
|
KOD_USTN
|
N
|
30
|
|
Количество пропана
|
KOL_PROPAN
|
N
|
73
|
|
Количество мазута
|
KOL_MAZYT
|
N
|
73
|
|
Количество сухогогаза
|
KOL_CUXGAZ
|
N
|
73
|
|
Количество летучих газов
|
KOL_LETGA
|
N
|
73
|
|
Количество вакуумный
дистиллят
|
KOL_VAKDIS
|
N
|
73
|
Индекс: R_T.NTX по DTOS (DATA_V) + STR(KOD_USTN,
3)
Интерес представляют данные о расходе сырья по каждой установке.
Таблица 2.4 - Структура таблицы "Потери при переработке"(Роt_Per.dbf)
|
Описание поля
|
Поле
|
Тип
|
Ширина поля
|
|
Дата ввода
|
DATA_V
|
D
|
|
|
Код установки
|
KOD_USTN
|
N
|
30
|
|
Код продукции
|
KOD_PROD
|
С
|
10
|
|
Потери фактические
|
POT_PHACT
|
N
|
153
|
Индекс:
P_P.NTX по DTOS (DATA_V) +
STR(KOD_USTN, 3)
Большой интерес представляют данные по фактическим потерям продукции и
полуфабрикатов. Есть возможность вводить эти данные ежесуточно и в дальнейшем
анализировать за любой период, в сравнении с плановыми и нормативными показателями.
Таблица 2.5 - Структура таблицы "Расход реагентов"(RAS_Reag.dbf)
|
Описание поля
|
Поле
|
Тип
|
Ширина поля
|
|
Дата ввода
|
DATA_V
|
D
|
|
|
Код установки
|
KOD_USTN
|
N
|
30
|
|
Код продукции
|
KOD_PROD
|
С
|
10
|
|
Количество
|
KOLVO
|
N
|
153
|
Индекс: R_R.NTX по DTOS (DATA_V) + STR(KOD_USTN,
3)
Так как объёмы фактических расходов реагентов жестко нормированы,
необходим достаточно оперативный контроль над их использованием. Для этого в
системе предусматривается возможность ежесуточного ввода первичной информации
по расходу материалов с разделением по видам продукции.
Таблица 2.6 - Структура таблицы "Тип движения"(DV_RAS.dbf)
|
Описание поля
|
Поле
|
Тип
|
Ширина поля
|
|
Код движения
|
KOD_DV
|
N
|
10
|
|
Тип движения
|
TYPE_DV
|
С
|
10
|
Индекс: Т_D.NTX по KOD_DV
В данной таблице находятся данные по типу движения на всех установках.
Таблица 2.7 - Структура таблицы "Тип расхода"(Typ_R.dbf)
|
Описание поля
|
Поле
|
Тип
|
Ширина поля
|
|
Код расхода
|
KOD_RAS
|
N
|
10
|
|
Тип расхода
|
TYPE_RAS
|
С
|
20
|
Индекс: T_R.NTX по KOD_RAS
В этой таблице находятся данные по типу расхода на всех установках.
Таблица 2.8 - Структура таблицы "Справочник установок"(SРR USTN.dbf)
|
Описание поля
|
Поле
|
Тип
|
Ширина поля
|
|
Код подразделения
|
KOD_PODR
|
N
|
20
|
|
Код установки
|
KOD_USTN
|
N
|
30
|
|
Наименование установки
|
NAME_USTN
|
С
|
30
|
|
Краткое наименование
установки, отделения
|
NCUT_USTN
|
С
|
10
|
|
Начальник установки
|
IDENT
|
N
|
60
|
|
Номер телефона в цеху
начальника установки
|
NOM_TEL
|
С
|
10
|
|
Номер счета
|
NOM_SCHET
|
С
|
6
|
|
Код затрат
|
KOD_ZATR
|
С
|
1
|
|
Мат. Ответственное лицо
|
MAT_OTV
|
N
|
60
|
|
Номер тел. Материал. отв.
лица в цехе
|
MAT_TEL
|
С
|
10
|
|
Признак включения установки
в расчет для ПЭО
|
FOR_PLANO
|
L
|
10
|
|
Признак включения установки
для показа зарплаты
|
FOR_ОTIZ
|
L
|
10
|
|
Ссылка на справочник
департаментов
|
ID_DEP
|
N
|
60
|
Индексы:_UST1.NTX
по KOD_USTN_UST2.NTX по STR(KOD_PODR,2,0)+STR(KOD_USTN,3,0)_UST3.NTX
по NAME_USTN_ UST4.NTX по KOD_ZATR
Данные по установкам находятся в этой таблице.
Таблица 2.9 - Структура таблицы "Справочник марок продукции"(РR M.dbf)
|
Описание поля
|
Поле
|
Тип
|
Ширина поля
|
|
Код вида
|
К_VID
|
С
|
2
|
|
Код семейства
|
К_SEM
|
С
|
3
|
|
Код продукции
|
KOD_PROD
|
С
|
10
|
|
Название продукции
|
NAME_ PROD
|
С
|
30
|
|
Качество, техн. условия
|
ТЕХ_USL
|
С
|
20
|
|
Цена за единицу продукции
|
CENA_T
|
N
|
142
|
|
Единица измерения
|
ED_IZM
|
N
|
20
|
|
Вес продукции
|
STAT_NAG
|
N
|
73
|
|
Прейскурант
|
N_POS_PRE
|
С
|
5
|
|
Индекс потребления энергии
|
IND_BENZ
|
N
|
10
|
|
Плотность материала
|
PLOTN
|
N
|
74
|
|
Номер счета
|
NOM_SCHET
|
С
|
4
|
|
Таможенная пошлина
|
ТАМ
|
52
|
|
Аварийная карта
|
AVKAR
|
С
|
3
|
|
Краткое наименование
|
CUT_PROD
|
С
|
15
|
|
Температура
|
ТЕМ
|
N
|
30
|
|
Тип пломбы
|
PLOMBA
|
С
|
1
|
Индексы:
PR_M1 .NTX по KOD_PRОD
PR_M2.NTX по
NAME_PROD_ M3.NTX по К_VID+K_SEM+KOD_PROD
Данные о свойствах и показателей продукта находятся в этой таблице.
Рисунок 2.3 - Структура взаимосвязи таблиц
3 Реализация разработки
.1 Интерфейс программы
Программа разрабатывалась в среде Borland DELPHI 9.0 компании Inprise Corporation. Выбор данной среды обусловлен
следующими причинами:
. Данная среда является ведущей RAD-системой (средой быстрой разработки
приложений) на рынке благодаря следующим особенностям:
.1. Визуальная среда разработки.
.2. Полное использование возможностей среды WIN32.
.3. Гибкость языка Object Pascal.
. Наибольший опыт разработчика работы именно в этой среде.
. Пожелание заказчика (в перспективе возможна доработка этого приложения
силами других разработчиков).
Интерфейс - это общение между человеком и компьютером. На практическом
уровне, интерфейс - это набор стандартных приемов взаимодействия с техникой.
Ключ для создания эффективного интерфейса заключается в быстром,
насколько это возможно, развитии у операторов простой концептуальной модели
интерфейса. Это осуществляется через согласованность. Концепция согласованности
состоит в том, что при работе с компьютером у пользователя формируется система
ожидания одинаковых реакций на одинаковые действия, что постоянно подкрепляет
пользовательскую модель интерфейса.
Другой составляющей интерфейса является свойство его конкретности и
наглядности. Это осуществляется применением плана панели, использованием цветов
и другой выразительной техники. Идеи и концепции затем обретают физическое
выражение на экране, с которым непосредственно общается пользователь.
Приложение состоит из не визуальных и визуальных компонентов работы с БД,
компонентов для выдачи отчетов (которые представляют собой разновидность визуальных
компонентов), а также модулей данных. Визуальные компоненты служат для
представления данных из не визуальных компонентов, т.е. служат целям
обеспечения интерфейса пользователя при работе с данными.
Модули данных служат для централизованного хранения отдельных экземпляров
не визуальных компонентов с целью придания тем или иным наборам данных
единообразного поведения приложения.
Приложение состоит из одной или нескольких форм.
Каждая форма может:
. Хранить и использовать свои "собственные " не визуальные
компоненты;
. Использовать не визуальные компоненты, хранящиеся в одном или
нескольких модулях данных;
. Использовать не визуальные компоненты, хранящиеся и используемые в
других формах.
Каждая форма может воспользоваться только "собственными "
визуальными компонентами, поскольку визуальные компоненты выполняют
интерфейсные функции и при активизации формы теряют свою видимость на экране.
.2 Экранные формы и модули АИС
Основной визуальной единицей приложения в DELPHI является экранная форма, которая представляет собой
окно, на которое помещаются другие визуальные объекты (списки, кнопки, строки
редактирования и др.).
В данной программе есть несколько экранных форм, список которых с кратким
описанием приведен ниже.
• frMainForm - основная форма программы. Содержит
основное меню. Вызывает другие окна.
• frAddPerVir - форма ввода параметров по
переработке и выработке.
• frAddOtgCjog - форма ввода параметров по
отгрузке.
• frAddRasTop- форма ввода параметров по расходу
топлива.
• frReport - отчёт по переработке и выработке.
Структура взаимодействия окон приведена на рисунок 3.1.
Рисунок 3.1 - Структура приложения
При запуске программы открывается главная форма рисунок 3.2.
Рисунок 3.2 - Основное окно программы.
В ней располагается главное меню приложения содержащее следующие пункты:
• Информация по цехам
. Переработка и выработка по установкам
. Отгрузка, сжег
. Расход энергии
. Потери при переработке
. Расход сырья
• Информация по ТЭЦ
. Расход топлива на ТЭЦ
• Сводки и отчёты
1. Деятельность установок
2. Сводка по расходу топлива
3. Отчёт о расходе материалов
. Справка о выходах н/п
. Расчёт потерь
• О программе
1. Выход
Также в главной форме присутствует таблица с данными (по умолчанию, при
запуске приложения таблица содержит данные о переработке и выработке по
установкам). Необходимые данные отображаются с помощью запросов написанных на SQL в элементе TQuery.
Строки таблицы составлены из полей, заранее известных базе данных. В
большинстве систем нельзя добавлять новые типы данных. Каждая строка в таблице
соответствует одной записи. Положение данной строки может изменяться вместе с
удалением или вставкой новых строк.
Чтобы однозначно определить элемент, ему должны быть сопоставлены поле
или набор полей, гарантирующих уникальность элемента внутри таблицы. Такое поле
или поля называются первичным ключом (primary key) таблицы и
часто являются числами. Если одна таблица содержит первичный ключ другой, это
позволяет организовать связь между элементами разных таблиц. Это поле
называется внешним ключом (foreign key).
Вот пример запроса для отображения данных о переработке и выработке по
установкам:
SELECT Per_vur.DATA_V, Dv_ras.TYPE_DV,
Spr_ustn.NCUT_USTN,_m.NAME_PROD, Per_vur.KOLVO, Per_vur.KOD_DV,
Per_vur.KOD_USTN,
Per_vur.KOD_PROD"..\word\Per_Vur.DBF" Per_vurJOIN
"..\word\Dv_Ras.DBF" Dv_ras
ON (Per_vur.KOD_DV=Dv_ras.KOD_DV)
INNER
JOIN "..\word\Spr_ustn.DBF" Spr_ustn
ON (Per_vur.KOD_USTN = Spr_ustn.KOD_USTN)
INNER
JOIN "..\word\Pr_m.DBF" Pr_m
ON (Per_vur.KOD_PROD = Pr_m.KOD_PROD)
где
SELECT, FROM, WHERE, INNER JOIN - операторы языка SQL;__Vur.DBF,
Dv_Ras.DBF, Spr_ustn.DBF, Pr_m.DBF - название таблиц;ТA_V, TYPE_DV, NCUT_USTN - название полей соответствующих
таблиц.
SELECT
- относится к командам языка манипулирования данными, используется для
формулирования и выполнения запросов пользователей к данным, хранящимся в базе
данных, то есть производит выборку из базы данных затребованной пользователем
информации. В ней указывается список полей таблицы. Порядок, в котором поля
перечислены в списке определяет порядок их выборки.
Предложение FROM, задает имена
таблиц к которым делается запрос.
Для задания условий, которыми должны соответствовать значения столбцов
требуемых строк таблицы используется фраза WHERE. В ней, в виде логических выражений задается критерий
выборки строк из таблиц базы данных. Выбираются только те строки, для которых
значение заданного критерия есть истина.
Еще на главной форме существуют кнопки управления:
Добавить - Для добавления новой записи в соответствующую таблицу
Удалить - Для удаления выбранной записи из таблицы
Фильтр - Для выполнения поиска необходимой записи в соответствующей
таблице
Выход - Закрытие приложения
При нажатии на кнопку "Добавить" открывается следующая форма рисунок
3.3.
Здесь мы можем установить необходимые нам значения для новой записи.
Данные для выпадающих списков формируются из существующих таблиц
(справочников). В данном, конкретном случае из таблицы "Установки",
"Продукция" и "Тип движения".
Рисунок 3.3. Окно ввода новой записи
Вот фрагмент кода отображающий в выпадающем списке записи справочника
"Тип движения":
Table1.
Active :=true;Table1 do
ComboBox1.Items.Clear;;not EOF do
СomboBox1.Items.Add(FieldByName('TYPE_DV').AsString);;;;.Text:=FieldByName('TYPE_DV').AsString;
end;
При нажатии кнопки "Ввод" в таблице создаётся новая
запись. Соответственно "Отмена" - означает не производить изменения в
таблице. При нажатии на кнопку "Удалить", из таблицы удаляется
соответствующая запись.
Рисунок 3.4 - Фильтр
Если у нас в таблице существует много записей то, естественно, возникают
определенные трудности с поиском необходимой нам записи.
Чтобы устранить эти трудности необходимо нажать на кнопку
"Фильтр" рисунок 3.4.
В выпадающем списке выбрать нужное нам значение записи и отметить
галочкой рисунок 3.5.
Рисунок 3.5 - Работа фильтра
После нажатия кнопки "Показать результаты" в нижней таблице
выводится список записей соответствующих заданному критерию. С этой таблицей
можно работать также как и с верхней таблицей, т.е. добавлять и удалять записи.
Выбрав пункт меню "Сводки и отчёты" мы можем создать отчет по
данным соответствующих таблиц.
Отчет создается с помощью элемента QuickReport. Когда приложение запущено и выбран,
к примеру, пункт "Отчёт о деятельности предприятия", отчёт будет
выглядеть так рисунок 3.6.
Рисунок 3.6 - Отчёт
4 Оценка экономической эффективности проекта
.1 Стоимость программного продукта
4.1.1 Затраты на создание программного
продукта
Стоимость выполнения каждой работы создания ПП определяется как сумма
заработной платы работников и накладных (косвенных) расходов по формуле:
Ср = sum ( Зr + Нr )
,4.1
r - R
где Зr - заработная плата и отчисления на социальное страхование при
выполнении r-той работы;
Нr - величина накладных расходов, связанных с выполнением r-той работы;-
множество выполняемых работ.
Величина заработной платы на выполнение r-той работы равна:
Зr = Зоr + Здr + Зсr , 4.2
Зоr = Тr * Счr * ( 1 + Кпr ) ,4.3
Здr = Кд * Зоr ,4.4
Зсr = Кс * ( Зоr + Здr ) ,4.5
где Зоr - основная заработная плата на выполнение r-той работы;
Тr -
трудоемкость работы в нормочасах;
Счr - средняя часовая тарифная ставка выполнения работы;
Кпr - коэффициент премий и доплат;
Здr - дополнительная заработная плата;
Кд -
коэффициент дополнительной заработной платы;
Зсr - отчисления на соц. страхование;
Кс -
коэффициент отчислений на соц. страхование.
Величина накладных расходов связанных с выполнением r-той работы,
определяется по формуле:
Нr = ( Зr*Кнr )/100 ,4.6
где Кнr - процент накладных расходов.
.1.2 Цена программного продукта
Розничная цена программного продукта определяется по формуле:
Цр = Спп*(1+Кр)*(1+Пт/100)/Рпп ,4.7
где Спп - себестоимость создания программного продукта;
Кр - коэффициент рентабельности разработки;
Кт - процент торговой наценке к оптовой цене;
Рпп - количество экземпляров продукта, реализованных в текущем году.
Затраты на создание программного продукта, то есть его себестоимость,
составляют 17 643 руб. Коэффициент рентабельности, определяющий прибыль от
реализации программного продукта, принятом равным 0,2. Ожидается, что в текущем
году будет продано три экземпляра программного продукта с торговой наценкой 70
%.
В этом случае розничная цена программного продукта устанавливается
равной:
Цр = 17643*(1+0,2)*(1+70/100)/3 = 11 997 руб.
4.2 Оценка ожидаемого экономического
эффекта
4.2.1 Выбор метода расчета
Основой для расчета годового экономического эффекта является методика,
которая предусматривает сопоставление приведенных затрат по базовому и
внедряемому вариантам.
Годовой экономический эффект определяется по формуле:
Эг = [( Тб + Ен * Кб ) - ( Тв + Ен * Кв )]*B ,4.8
где Тб,Тв - годовые текущие затраты в базовом и внедряемом вариантах;
Кб,Кв - капитальные вложения в базовом и внедряемом вариантах;
Ен -
нормативный коэффициент эффективности капитальных вложений, равный 0.3;- число единиц ПП, внедрённого в
текущем году.
Срок окупаемости затрат в годах определяется по формуле:
Ток = ( Кв - Кб ) / Эг ,4.9
При определении экономического эффекта, в расчете капитальных и текущих
затрат, учитываются только те статьи затрат, которые имеют различие в базовом и
внедряемом вариантах.
.2.2 Сведения о базовом и внедряемом вариантах
При расчете экономического эффекта в качестве базового варианта принят
ручной метод обработки технической документации. В этом случае работу выполняют
два человека. Для выполнения работы они используют два шкафа и 100 папок, в
которых хранится необходимая документация.
Во внедряемом варианте обработку документации ведет один человек, который
работает на персональном компьютере, используя приобретенный программный
продукт и 50 % машинного времени компьютера.
.2.3 Капитальные затраты
Капитальные затраты представляются как разовые затраты, необходимые для
приобретения программного продукта, оборудования, производственных помещений,
требуемого инвентаря и т.д.
Капитальные затраты в базовом варианте определяются стоимостью 2-х
шкафов, приобретаемых по цене 1200 руб. каждый и 100 папок, предназначенных для
хранения документов, стоимостью по 24 руб. каждая. Суммарная их стоимость
составляет:
Кб = 1200 * 2 + 24 * 100 = 4800 руб.
Капитальные затраты во внедряемом варианте определяются стоимостью
программного продукта, 11 997 руб. и 50% стоимости и установки компьютера,
которые приняты равными 9000 руб.
Кв = 11997 + 9000 = 20 997 руб.
.2.4 Текущие затраты
Текущие расходы складываются из заработной платы работников и других расходов,
связанных с обслуживанием выполнением проводимых работ.
Заработная плата определяется как сумма основной заработной платы и
отчислений на социальное страхование.
Текущие расходы, связанные с затратами на обслуживание выполняемых работ
(организация работ, амортизация и ремонт оборудования, использование
производственных площадей, обеспечение энергией и другие статьи затрат) могут
рассматриваться как конкретные статьи затрат или как накладные расходы,
составляющие определенный процент от заработной платы.
В базовом варианте занято 2 человека с основной зарплатой в 1000 рублей
каждый. Их годовая заработная плата равна:
Зоб = 2 * 1000 * 12 = 24 000 руб.
Зсб = 0.37 * Зоб = 8 880 руб.
Зб = 24000 + 8880 = 32 880 руб.
Накладные расходы приняты равными 70 % заработной платы:
Нб = 32880 * 0.7 = 23 020 руб.
Текущие расходы в базовом варианте составляют:
Тб = 32880 + 23020 = 55 900 руб.
Во внедряемом варианте занят 1 человек с зарплатой в 1600 руб. выполняет
работу с использованием программного продукта за 50 % времени. Его годовая
заработная плата за аналогичную работу равна:
Зов = 1 * 1600 * 12 * 0.5 = 9 600 руб.
Звс = 0.37 * 9600 = 3 550 руб.
Зв = 9600 + 3550 = 13 150 руб.
Накладные расходы приняты равными 180 % заработной платы:
Нв = 13150 * 1.8 = 23 670 руб.
Текущие расходы во внедряемом варианте составляют:
Тв = 13150 + 23670 = 36 820 руб.
4.2.5 Расчет экономического эффекта
Предполагается, что программный продукт будет использован в текущем году
тремя потребителями. В этом случае годовой экономический эффект от его
использования каждым потребителем составит:
Эг =(55900 + 0.3*4800) - (36820 + 0.3*20997) = 14 220 руб.
Срок окупаемости произведенных затрат равен:
Ток = (20997 - 4800)/14220 = 1.1 года
Выводы
1. Планом создания программного продукта предусмотрено проведение 30
работ, последовательность выполнения которых устанавливается сетевым графиком.
Согласно разработанной методике, определена трудоемкость выполнения каждой
работы. Общая трудоемкость выполнения проекта составляет 740 нормо-часов. При
выбранной структуре сетевого графика расчет и оптимизация на ЭВМ его параметров
позволили определить сроки выполнения каждой работы и минимальное потребное
количество ее исполнителей. Установлено, что при заданном сроке выполнения всех
работ, равном 60 дням, средняя потребность в исполнителях составит 1.54.
. Затраты на создание программного продукта, то есть его себестоимость,
составляет 17 643 руб. Розничная цена программного продукта установлена в 11
997 руб. Ожидается, что в текущем году разработанным программным продуктом
воспользуются три потребителя.
. Уменьшение трудоемкости и числа работников дает возможность получить
годовой экономический эффект при использования программного продукта каждым
потребителем 14 220 руб. Срок окупаемости дополнительных капитальных затрат
потребителя равен 1,1 года.
Заключение
В современных условиях поиск оптимального решения проблемы организации
интерфейса взаимодействия приобретает характер комплексной задачи, решение
которой существенно осложняется необходимостью оптимизации функционального
взаимодействия операторов между собой и с техническими средствами АСУ в
условиях изменяющегося характера их профессиональной деятельности.
В этой связи хотелось бы подчеркнуть особую актуальность проблемы
моделирования взаимодействия ЧО (человека-оператора) с техническими средствами
АСУ. Сегодня появилась реальная возможность с помощью моделирования на
современных многофункциональных средствах обработки и отображения информации,
таких как Delphi, конкретизировать тип и
характеристики используемых информационных моделей, выявить основные
особенности будущей деятельности операторов, сформулировать требования к
параметрам аппаратно-программных средств интерфейса взаимодействия и т.д.
В данной работе решены поставленные задачи, направленные на устранение
недостатков в сборе, обработке и хранении экономической информации в основных
бизнес процессах предприятия. Для этого было выполнено, собрана исчерпывающая
информация о внутренней организации процессов, как производственных, так и
организационных. После чего выявлена область для автоматизации, выбрана
информация, которая должна храниться в базах, данных для её лучшей обработки и
анализа. После были разработаны необходимые хранилища информации, программные
модули и интерфейс пользователя. В итоге был проведён анализ экономической
эффективности, который указал срок окупаемости 1,1 год.
Проектирование системы выполнено с использованием методов системного
анализа для изучения предметной области, моделирования для представления
функциональной модели предприятия и для описания логической схемы данных, метод
аналогий и сравнений, которые были использованы на всех этапах проектирования.
В результате разработано прикладное решения для малых предприятий. Оно
включает в себя базу данных, реализованную на основе MySQL, и приложения пользователя разработанного в среде DELPHI 9.
Разработанная система позволяет:
Производить ввод и редактирование товаров поступающих на склад;
показывать товары по категориям;
Вводить и изменять заказы товаров, вычислять промежуточные итоги,
отображаемые в главной форме, показывать остаток товара на складе;
Добавлять и изменять сведения о товарах.
Добавлять и изменять типы товаров
Отображать имя и местоположение клиента, выводить все его заказы для
выбранной компании, и дата - хронологические записи для выбранного заказа.
Печатать каталог товаров. (двухстраничный заголовок отчета; фотографии
для каждого типа; начало каждого типа на новой странице; группировка всех
записей типа на одной странице; печать формы заказа на отдельной странице в
примечании отчета).
Печатать сведения о товарах с группировкой по первой букве названия
товара.
Печатать сведения о товарах по типам. (в три столбца, каждый тип начинать
в новом столбце).
Отображать квартальные обороты заказов каждого товара и полный итог за
исследуемый год с условием отбора по клиенту;
Печатать сведения об объемах продаж в убывающем порядке с целью
определения наиболее крупных заказов;
Печатать квартальные итоги по сумме продаж в отчете; с возможностью
просмотра информации о записи. (предусмотреть форму для запроса периода
отчета);
Выводить отчет продаж за исследуемый период по типам. (в подчиненном
отчете выводить цифры, а в главном диаграмму);
Предоставить таблицу и график в виде гистограммы о продажах товаров в
каждом квартале отчетного года;
автоматизированный учет
готовая продукция delphi
Литература
1.
Дж. Тельман,
"Основы систем баз данных" [Текст] / Дж. Тельман Москва.:Финансы и
статистика, 2003г.-324с.
2.
Дейт К.,
"Введение в системы баз данных" [Текст] / Дейт К Москва.: Hаука, 2000
г.-225с.
3.
Когловский М.Р.,
"Технология баз данных на персональных ЭВМ" [Текст] / Когловский М.Р
Москва.: 'Финансы и статистика', 2002 г.-324с.
4.
Шумаков П. В.,
"Delphi 3.0 и создание баз данных" [Текст] / Шумаков П. В Москва
2007г.-506с
5.
Джон Матчо, Дэвид
Р.Фолкнер. «Delphi» [Текст] / Джон Матчо - пер. с англ. - М.:Бином,
2005г.-461с.
6.
A.M.Епанешников.
Епанешников В.А., "Программирование в среде Delphi 2.0" [Текст] /
A.M.Епанешников ,М.: Диалог-Мифи, 2007г.-235с.
7.
Дж. Мартин.,
"Организация баз данных в вычислительных системах" [Текст] / Дж.
Мартин ,М: Мир 2008г.-364с.
8.
С.М.Диго,
"Проектирование и использования баз данных" [Текст] / С.М.Диго,
Москва: Финансы и статистика 2005.-234с.
9.
Горев А.Б, Ахаян
Р.С, Макашарипов С.Т, "Эффективная работа с СУБД" [Текст] / Горев
А.Б, СПб.:Питер, 2007.- 704 с.,ил.
10.Атре Ш., "Структурный подход к организации баз
данных" [Текст] / Атре Ш - М.: Финансы и статистика, 2003. - 320 с.
11.Бойко В.В., Савинков В.М., "Проектирование баз
данных и информационных систем" [Текст] / - М.: Финансы и статистика,
2009. - 351 с.
12.Джексон Г., "Проектирование реляционных баз
данных для использования с микроЭВМ" [Текст] /. -М.: Мир, 2001. - 252 с.
13.Кириллов В.В., "Структурированный язык запросов
(SQL)" [Текст] / Кириллов В.В. - СПб.: ИТМО, 2004. - 80 с.
14.Мейер М., "Теория реляционных баз данных"
[Текст] / Мейер М - М.: Мир, 2007. - 608 с.
15.Тиори Т., Фрай Дж., "Проектирование структур баз
данных" [Текст] / Тиори Т., В 2 кн., - М.: Мир, 2005. Кн. 1. - 287 с.: Кн.
2. - 320 с.
16.Цикритизис Д., Лоховски Ф., "Модели данных"
[Текст] / Цикритизис Д., - М.: Финансы и статистика, 2005. - 344 с.
17."Paradox for Windows: Практическое
руководство". Под редакцией Оспищева Д. А. Издательство АОЗ
"Алевар", 2003.
18.Брябрин В.М., "Программное обеспечение
персональных ЭВМ" [Текст] / Брябрин В.М., , Москва, 'Hаука', 2009 г.-349с.
19.Шафрин Ю.А., "Основы компьютерной
технологии" [Текст] / Шафрин Ю.А., М., 2008.-256с.
20."Рекоммендации по общепользовательскому
интерфейсу", Microsoft, редакция 2005г.
21.Тейксейра, Стив, Пачеко, Ксавье. Delphi 9. "Руководство
разработчика" [Текст] / Тейксейра, .СПб:Издательский дом 'Вильямс'
2009г.-912с.
22.Ден Оузьер, Стив Гробман, Стив Батсон. DELPHI. "Освой самостоятельно"
[Текст] / Ден Оузьер, Перевод с англ.-М.:Восточная Книжная Компания,
2007г.-624с.
23.Калянов Г.Н., "Консалтинг при автоматизации
предприятий": Научно-практическое издание / Калянов Г.Н., . Серия
"Информатизация России на пороге 21 века" - М.:СИНТЕГ, 2007г.-316с.
24.Питер Колетски и др. ORACLE DESIGNER "Настольная книга
пользователя" [Текст] / Питер Колетски., Второе издание.Издательство
'Лори' 2009г.
25.Касьянова Г.Ю., Колесников С.Н., " Управленческий
учёт по формуле 'три в одном' [Текст] / Касьянова Г.Ю., " М.:Издательство-консультационная
компания 'Статус Кво 09', 2009г.-328с.
Приложение А
СПИСОК СОКРАЩЕНИЙ
АБД - администратор БД;
АИС - автоматизированная информационная система;
АРМ - автоматизированное рабочее место;
АСУ - автоматизированные системы управления;
АСУ П - АСУ предприятия;
АСУ ТП - АСУ технологических процессов;
БД - база данных;
ГОСТ - государственный стандарт;
ПАЗ - противоаварийная защита;
ПТК - программно-технический комплекс;
ПЛК - программно-логический контроллер;
ФЗП - фонд заработной платы;
п/с - подсистема;
п/ф - полуфабрикат;
СтП - стандарт предприятия;
СУБД - система управления базами данных;
ТУ - технические условия;
ТЭП - технико-экономические показатели;
ЯОД - язык описания данных;