Содержание

I. Специальная часть.

Введение 3

Глава 1. Основная часть

1.1. Содержание и требования, предъявляемые к информации 3

1.2. Значение внутрифирменной системы информации 4

1.3. Основные принципы, цели, задачи и функции внутрифирменной системы информации 6

1.4. Технические средства, используемые во внутрифирменной системе информации 7

1.5. Система ведения записей 8

1.6. Формы как носители информации 8

Глава 2. Информационные базы данных

2.1. Реляционные базы данных 10

2.1.1. Реляционная модель: одни таблицы 11

2.1.2. Независимость 12

2.1.3. Язык высокого уровня 14

2.1.4. Реляционные операции: проектирование, выбор,

объединение. 14

2.1.5. Альтернативный способ просмотра данных 15

2.1.6. Нули 16

2.1.7. Безопасность 17

2.1.8. Целостность 17

2.2. Проектирование баз данных 18

2.2.1. Подход к проектированию базы данных 19

2.2.2. Несколько слов о структуре базы данных. 21

I) Что такое «хорошая структура»

II) Плохая структура базы данных

2.3. Нормализация. 22

2.3.1. Первая нормальная форма. 23

2.3.2. Вторая нормальная форма 23

2.3.3. Третья нормальная форма 24

2.3.4. Четвертая и пятая нормальные формы 24

Глава 3. Общее описание базы данных

3.1. Задачи, выполняемые приложением «Бухгалтерия». 26

3.2. Технические требования, предъявляемые к базе данных. 27

3.3. Выбор системы проектирования и реализации. 27

3.4. Проектирование структуры данных. 29

3.4.1. Описание структуры данных проекта. 31

3.5. Техническая реализация проекта. 39

3.5.1. Общее описание работы с приложением. 39

3.5.2. Формы отчетности (счетов, актов, счетов-фактур, накладных). 41

3.5.3. Сервисные функции. 42

3.5.4. Описание структуры программы. 42

Заключение. Оценка качества программного обеспечения. 95

Метрики Боэма, Брауна и Лайпоу. 96

Метрики программного обеспечения Джилба. 97

Оценка сложности Маккейба. 98

Понимеемость. 99

Выводы. 99

Список литературы к специальной части. 101

Приложения. 103

II. Организационно-экономическая часть. 122

III. Охрана труда и экология. 128

IV. Гражданская оборона 137

V. Эргономика 144

Введение.

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

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

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

1. Основная часть.

1.1 Содержание и требования, предъявляемые к информации.

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

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

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

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

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

— по объекту и качеству — краткость и четкость формулировок, своевременность поступления;

— по целенаправленности — удовлетворение конкретных потребностей;

— по точности и достоверности — правильный отбор первичных сведений, оптимальность систематизации и непрерывность сбора и обработки сведений.

1.2. Значение внутрифирменной системы информации.

Для современных условий характерно применение высокоэффективной внутрифирменной системы информации, основанной на использовании новейших технических средств автоматизированной обработки цифровой и текстовой информации на базе компьютеров с процессорами Intel Pentium, объединенных в локальную единую внутрифирменную вычислительную сеть

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

Информационная система состоит из компонентов обработки информации, внутренних и внешних каналов передачи.

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

В производственно-хозяйственном подразделении предприятия обеспечивается обобщение информации “снизу вверх”, а также, конкретизация информации “сверху вниз”.

Информационный процесс, направленный на получение научно-технической, плановой, контрольной, учетной и аналитической информации, в информационных системах унифицирован и базируется на электронно-вычислительной технике.

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

Информация, и, особенно, ее автоматизированная обработка, является важным фактором повышения эффективности производства.

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

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

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

1.3. Основные принципы, цели, задачи и функции внутрифирменной системы информации.

Основными принципами и целями внутрифирменных систем информации являются:

1.Определение требований к содержанию информации и ее характеру в зависимости от целенаправленности;

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

3.Определение потребностей в технических средствах (в том числе, в компьютерной технике) на предприятии в целом;

4.Разработка программного обеспечения, создание и использование банков данных;

5.Автоматизированная обработка и выдача текстовой информации;

6.Автоматизация административно-управленческого труда на основе использования компьютерной техники.

Важными задачами внутрифирменной системы управления являются:

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

— определение основных направлений системы сбора, обработки и хранения первичных данных;

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

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

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

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

— в конторском деле — для замены секретарей-машинисток и делопроизводителей;

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

1.4. Технические средства, используемые во внутрифирменной системе информации

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

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

Современные ЭВМ способны одновременно обрабатывать цифровую, текстовую и графическую информацию.

В процессе автоматизации управления мини-ЭВМ используются, преимущественно, для:

— разработки оперативных планов производства и контроля за их выполнением;

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

— расчета заработной платы;

— контроля над поступлением заказов;

— анализа данных о сбыте продукции;

— регистрации поступления платежей;

— ведения учета и отчетности.

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

1.5. Система ведения записей.

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

— данные учета и финансовой отчетности, финансовая документация;

— расчеты заработной платы рабочих и служащих;

— тексты контрактов и сопроводительная документация;

— тексты годовых отчетов и протоколы собраний акционеров;

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

Обычно записи первичных данных делят на две группы:

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

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

1.6. Формы как носители информации.

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

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

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

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

2. Информационные базы данных.

Информационные базы данных включают весь комплекс статистических показателей, характеризующих хозяйственную деятельность предприятия в целом, а также, фактологический материал относительно всех факторов, оказывающих влияние на состояние и тенденции развития предприятия. Обычно, при формировании базы данных, решается вопрос и о системе хранения и обновления данных, а также, обоснованная увязка данных, их взаимная согласованность, возможность проведения сравнений и сопоставления оценок, хранимых в банке данных. Данный вопрос имеет существенное значение при объединении первичных данных в укрупненные группы (файлы) со своими реквизитами. Базы данных непрерывно обновляются на определенной систематической основе с учетом требований менеджеров, бухгалтеров — основных пользователей базой данных.

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

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

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

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

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

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

1. Вычислительный центр для обслуживания фирмы в целом;

2. Центральную службу информации;

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

В случае малого предприятия данный аппарат управления, как правило, состоит из двух отделов:

1. Отдел автоматизации (отдел программирования);

2. Технический отдел (отдел сетевых разработок).

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

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

2.1. Реляционные базы данных

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

С. Дейт дает следующее неформальное определение системе управления реляционными базами данных (СУБД).

• Вся информация в базе данных представлена в виде таблиц.

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

Др. И.Ф. Кодд, автор реляционной модели, разработал целый список критериев, которым должна удовлетворять реляционная модель. Описание этого списка, часто называемого «правилами Кодда», требует введения сложной терминологии и теоретических выкладок, что выходит за рамки данного дипломного проекта. Тем не менее, опишем состоящий из 12 правил тест Кодда для реляционных систем, и будем использовать его совместно с общим определением Дейта.

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

• представлять всю информацию в виде таблиц,

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

• использовать язык высокого уровня для структурирования, выполнения запросов и изменения информации в базах данных (теоретически это может быть любой язык баз данных, практически для этого используется язык SQL),

• поддерживать основные реляционные операции (выбор, проектирование и объединение), а также теоретико-множественные операции, такие как объединение, пересечение и дополнение,

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

• различать в таблицах неизвестные значения (nulls), нулевые значения и пропуски в данных,

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

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

2.1.1. Реляционная модель: одни таблицы

Первое правило Кодда гласит, что вся информация в реляционных базах данных представляется значениями в таблицах (tables). В реляционных системах таблицы состоят из горизонтальных строк (row) и вертикальных столбцов (column). Все данные представляются в табличном формате — другого способа просмотреть информацию в базе данных не существует. Несколько замечаний по терминологии. Поскольку такие понятия как таблица, строка и столбец являются общепринятыми в коммерческих системах управления реляционными базами данных, будем стараться использовать их в этом дипломном проекте. Однако иногда можно встретиться и с такими понятиями, как отношение (relations), кортеж (tuple) и атрибут (attributes). Это соответственно синонимы понятий таблица, строка и столбец, так же, как и файл (file), запись (record) и поле (field). Первые три считаются академическими терминами, последние—взяты из общего лексикона, используемого в области обработки данных. Набор связанных таблиц образует базу данных (database). Таблицы в реляционной базе разделены, но полностью равноправны. Между ними не существует никакой иерархии и, вообще говоря, они не обязательно даже физически связаны друг с другом.

Каждая таблица состоит из строк и столбцов. Каждая строка описывает отдельный объект или сущность (entity) человека, компанию, торговую сделку или что-нибудь другое. Каждый столбец описывает одну характеристику объекта—имя человека или его адрес, телефонный номер компании или ее президента, лоты распродажи или дату. Каждый элемент данных, или значение (value), определяется пересечением строки и столбца таблицы. Чтобы найти требуемый элемент данных, необходимо знать имя содержащей его таблицы, столбец и значение его первичного ключа (primary key), или уникального идентификатора (каждая строка должна единственным образом идентифицироваться по одному из своих значений.)

В реляционных базах данных существует два типа таблиц — пользовательские таблицы (user tables) и системные таблицы (system tables). Пользовательские таблицы содержат информацию, для поддержки которой собственно и создавались системы реляционных баз данных—данные по сделкам, заказам, персоналу и т.д. Системные таблицы, известные также под названием системные каталоги (system catalog), содержат описание базы данных. Системные таблицы обычно поддерживаются самой СУБД, однако доступ к ним можно получить так же, как и к любым другим таблицам. Возможность получения доступа к системным таблицам, по аналогии с любыми другими таблицами, составляет основу другого правила Кодда для реляционных систем.

2.1.2. Независимость

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

Реляционная модель обеспечивает независимость данных на двух уровнях — физическом и логическом. Физическая независимость данных (physical data independents) означает с точки зрения пользователя, что представление данных абсолютно не зависит от способа их физического хранения. Как следствие этого, физическое перемещение данных никоим образом не может повлиять на логическую структуру базы данных и ваше восприятие данных. Такие изменения обычно становятся просто необходимыми, особенно в больших многопользовательских системах. Например, при недостатке места для хранения информации может потребоваться установка дополнительных физических носителей. Когда устройство выходит из строя,—увы, его приходится быстро заменять. Иногда может потребоваться увеличить производительность системы или упростить ее использование, изменив для этого методы доступа к физическим данным. (Эти методы связаны с созданием стратегии доступа (access strategies) и применением индексов (index).)

Другой тип независимости, обеспечиваемый реляционными системами—логическая независимость (logical independents) означает, что изменение взаимосвязей между таблицами, столбцами и строками не влияет на правильное функционирование программных приложений и текущих запросов. Можно разбивать таблицы по строкам или столбцам, а приложения и запросы все равно будут выполняться, как и раньше. Несмотря на изменение логической структуры базы данных, всегда можно воспользоваться старыми запросами. Требование логической и физической независимости данных составляет основу двух других правил Кодда.

2.1.3. Язык высокого уровня

Определение реляционной системы, так же, как и правила Кодда, требует, чтобы весь диалог с базой данных велся на едином языке — иногда его называют общим подъязыком данных (comprehensive data sublanguage). В мире коммерческих систем управления базами данных такой язык получил название SQL. SQL используется для манипуляций с данными (data manipulation) выборки и модификации, определения данных (data definition) и администрирования данных (data administration). Любая операция по выборке, модификации, определению или администрированию выполняется с помощью оператора (statement) или команды (command) SQL.

Имеется две разновидности операций по манипуляции с данными — выборка данных (data retrieval) и модификация данных (data modification). Выборка — это поиск необходимых вам данных, а модификация означает добавление, удаление или изменение данных. Операции по выборке (чаше называемые запросами (query)) осуществляют поиск в базе данных, наиболее эффективно извлекают затребованную вами информацию и отображают ее. Другие команды SQL предназначены для создания и удаления таблиц, индексов и других объектов.

Последняя категория операторов SQL—операторы администрирования, или команды управления данными (data control). Они позволяют вам координировать совместное использование базы данных и поддерживать ее в наиболее эффективном состоянии.

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

2.1.4. Реляционные операции

В определении системы управления реляционными базами данных упоминаются три операции по выборке данных — проектирование, выбор (иногда называемый ограничением (restrictions)) и объединение, которые позволяют строго указать системе, какие данные вы хотите увидеть. Операция проектирования выбирает столбцы, операция выбора — строки, а операция объединения собирает вместе данные из связанных таблиц.

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

Проектирование. Операция проектирования позволяет указать системе, какие

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

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

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

2.1.5. Альтернативный способ просмотра данных

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

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

2.1.6. Нули

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

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

С точки зрения другого эксперта по реляционным системам, Дейта, нули не являются полноценным решением проблемы пропусков информации. Тем не менее, они являются составной частью большинства официальных стандартов SQL и de facto промышленных стандартов.

2.1.7. Безопасность

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

В многопользовательских системах обычно имеется пользователь с правами даже более высокими, чем у владельца базы данных—системный администратор (system administrator), или администратор базы данных (database administrator). Этот пользователь обычно обладает широкими правами на наделение полномочий, а также выполняет целый ряд других задач, связанных с поддержкой и администрированием базы данных.

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

2.1.8. Целостность

Целостность (integrity) - очень сложный и серьезный вопрос при управлении реляционными базами данных. Несогласованность между данными может возникать по целому ряду причин. Несогласованность или противоречивость данных может возникать вследствие сбоя системы—проблемы с аппаратным обеспечением, ошибки в программном обеспечении или логические ошибки в приложениях. Реляционные системы управления базами данных защищают данные от такого типа несогласованности, гарантируя, что команда либо будет исполнена до конца, либо будет полностью отменена. Этот процесс обычно называют управлением транзакциями (transaction management).

Другой тип целостности, называемый объектной целостностью (entity integrity), связан с корректным проектированием базы данных. Объектная целостность требует, чтобы ни один первичный ключ не имел нулевого значения. Третий тип целостности, называемый ссылочной целостностью (referential integrity), означает непротиворечивость между частями информации, повторяющимися в разных таблицах. Например, если вы изменяете неправильно введенный номер расчетного счета покупателя в одной таблице, другие таблицы, содержащие эту же информацию, продолжают ссылаться на старый номер, поэтому вы должны обновить и эти таблицы. Чрезвычайно важно, чтобы при изменении информации в одном месте, она соответственно изменялась и во всех других местах. Правила Кодда гласят, что системы управления реляционными базами данных должны обеспечивать не только объектную и ссылочную целостность, но и позволять «вводить дополнительные ограничения на целостность, отражающие специальные требования». Кроме того, по определению Кодда, ограничения на целостность должны:

• определяться на языке высокого уровня, используемом системой для всех других целей;

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

Первоначально только несколько реализаций реляционных баз данных удовлетворяли критериям Кодда на целостность, но ситуация постепенно изменялась. Стандарт 1992 года (часто называемый «SQL92») поддерживает ограничения, обеспечивающие ссылочную целостность и позволяющие задавать бизнес правила. Эти возможности в том или ином виде реализованы в большинстве систем.

2.2. Проектирование баз данных

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

• таблиц, которые будут входить в базу данных,

• столбцов, принадлежащих каждой таблице,

• взаимосвязей между таблицами и столбцами.

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

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

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

• Гибкость структуры базы данных—конструктивные решения не ограничивают возможности выполнять в будущем самые разнообразные запросы.

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

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

2.2.1. Подход к проектированию базы данных

Часто при обсуждении вопросов проектирования реляционных баз данных почти все внимание уделяется применению правил нормализации. В ходе нормализации обеспечивается защита целостности данных путем устранения дублирования данных. В результате таблица, которая первоначально казалась «имеющей смысл», разбивается на две или более связанных таблиц, которые могут быть «собраны вместе» с помощью операции объединения. Этот процесс называется декомпозицией без потерь (non-loss decomposition) и просто означает разделение таблицы на несколько меньших таблиц без потери информации. Нормализация наиболее полезна для проверки созданной вами структуры. Можно проанализировать свои решения о том, какие столбцы должны быть включены в ту или иную таблицу с точки зрения правил нормализации, убедившись при этом, что не сделали каких-то фатальных ошибок. Понимание основ процесса нормализации также может помочь в процессе проектирования базы данных, но оно не является универсальным рецептом при построении базы с нуля. Итак, как определить, какие столбцы должны располагаться в начале таблицы. Общего правила на этот счет не существует. Однако здесь вам может оказать существенную помощь моделирование зависимостей — анализ сущности данных (в терминах объектов или вещей) и зависимостей между ними (один-к-одному, один-ко-многим, многие-ко-многим).

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

1. Исследования информационной среды для моделирования.

• Откуда поступает информация и в каком виде?

• Как она будет вводиться в систему и кто этим будет заниматься?

• Как часто она изменяется?

• Какие параметры системы будут наиболее критическими с точки зрения времени реакции на запрос и надежности?

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

• Уточнение, в каком виде информация должна извлекаться из базы данных — в форме отчетов, заказов, статистической информации.

• Кому она будет предназначаться.

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

3. В ходе работы обязательно должен создаваться макет таблиц и связей между ними, называемый структурой данных (data structure), или диаграммой зависимостей между объектами (E-R diagram).

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

5. Затем должны быть рассмотрены зависимости между объектами.

• Имеются ли зависимости типа один-ко-многим (один заказчик может иметь множество выписанных счетов, но каждый счет может быть выписан только на одного заказчика) или многие-ко-многим?

• Есть ли возможности для объединения связанных таблиц? Для этого служат внешние ключи (foreign key), столбцы в связанных таблицах с совпадающими значениями первичных ключей.

6. Анализ структуры базы данных с точки зрения правил нормализации для поиска логических ошибок. Исправление всех отклонений от нормальных форм или обоснование решения отказаться от выполнения ряда правил нормализации в интересах простоты освоения или производительности. Документирование причины таких решений.

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

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

2.2.2. Несколько слов о структуре базы данных.

I) Что такое «хорошая структура»

Хорошая структура — это, в первую очередь, «прозрачная» структура. Проще говоря, хорошая структура:

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

• гарантирует непротиворечивость данных;

• «выжимает» максимум производительности из системы.

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

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

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

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

II) Плохая структура базы данных

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

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

• порождает избыточные данные;

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

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

2.3. Нормализация.

Вообще говоря, нормализация — это набор стандартов проектирования данных, называемых нормальным и формами (normal forms). Общепринятыми считаются пять нормальных форм, хотя их было предложено значительно больше. Создание таблиц в соответствии с этими стандартами называется нормализацией. Нормальные формы изменяются в порядке от первой до пятой. Каждая последующая форма удовлетворяет требования предыдущей. Если следовать первому правилу нормализации, то данные будут представлены в первой нормальной форме. Если данные удовлетворяют третьему правилу нормализации, они будут находиться в третьей нормальной форме (а также в первой и второй формах).

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

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

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

2.3.1. Первая нормальная форма.

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

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

2.3.2. Вторая нормальная форма

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

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

2.3.3. Третья нормальная форма

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

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

2.3.4. Четвертая и пятая нормальные формы

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

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

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

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

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

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

3. Общее описание базы данных

3.1. Задачи, выполняемые приложением «Бухгалтерия»

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

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

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

3. Оформление, учет и выписка первичной бухгалтерской документации (счетов) по дополнительным заказам (программное и аппаратное обеспечение, информационные услуги)

4. Оформление, учет и выписка вторичной отчетной документации (акты на установку, накладные, счета-фактуры, акты на информационные услуги), фиксирование информации о приходе денежных средств по счетам, формирование первичного финансового отчета по дополнительным заказам организации (программное и аппаратное обеспечение, информационные услуги)

5. Оформление счетов-фактур на сопровождение по авансовым остаткам с 1996 года

6. Ввод прейскурантов на сопровождение и на системы.

7. Ввод и изменение адресных и банковских реквизитов организаций.

3.2. Технические требования, предъявляемые к базе данных.

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

- система должна нормально функционировать на стандартных персональных компьютерах клона IBM с процессором Intel Pentium - 100 (минимальные требования), подсоединенных к локальной офисной вычислительной сети в режиме невыделенных серверов;

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

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

- система должна обеспечивать защиту информационной базы данных от несанкционированного доступа;

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

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

- система должна иметь возможность наращивания в программной части.

- система должна функционировать под управлением операционных систем Windows 95 и Windows NT.

3.3. Выбор системы проектирования и реализации.

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

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

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

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

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

Базы данных созданные с помощью системы управления базами данных «Microsoft Access» полностью реализую реляционную модель построения данных. База данных «Microsoft Access» представляет собой набор групп объектов, таких как таблицы, запросы, формы, отчеты.

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

• один-к-одному;

• один–ко-многим;

• многие-к-одному;

• многие-ко-многим.

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

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

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

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

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

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

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

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

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

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

Применение пакета «Microsoft ADT» (расширенные средства разработчика) вводит новый уровень визуализации данных, засчет таких элементов, как «Tree View», «Tab Control» и других.

На начальном этапе реализации база данных проектировалась на СУБД «Microsoft Access 2.0».В дальнейшем с появлением новой версии «Microsoft Access 7.0» база данных была переведена на новую версию СУБД, так как в новой версии появились новые инструменты разработчика, улучшенный интерфейс и реальная 32-разрядность. При переходе были отлажены с некоторые проблемы связанные с несовместимостью программного кода различных версий, и так как отладка происходила по мере выявления ошибок, то в дальнейшем возможно возникновение проблем с совместимостью кода.

3.4. Проектирование структуры данных.

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

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

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

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

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

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

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

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

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

• модуль для бухгалтерии (MdlByx.mdb),

• модуль для отдела сопровождения (MdlClnt.mdb),

• модуль данных (Data.mdb).

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

• организовать клиент - серверную модель данных,

• разработку и изменение модулей параллельно с работой ранее сконструированных,

• уменьшает размер резервного файла,

В процессе технической реализации данных задач появились дополнительные задачи:

1. Изменение данных по авансовому отчету (корректировка распределения сумм по месяцам для организаций).

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

3. Обмен сообщениями между пользователями (использование для заказа счетов актов и так далее).

3.4.1. Описание структуры данных проекта.

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

Часть 1. (листинг 2.1)

(
таблицы «Заказчики», «СтатусЗаказчика»,«Курьеры»,«Примечания»,)

1. Связь таблицы «Заказчики» с таблицей «СтатусЗаказчика». Поле: «Код» в обеих таблицах

Тип связи: один ко многим без обеспечения целостности данных.

(один со стороны таблицы «СтатусЗаказчика»)

Связывание: мастер подстановок в таблице «Заказчики»

Примечания: данная связь заменяет повторяющееся текстовые значения типа организации соответствующим кодом из таблицы «СтатусЗаказчика».

2.Связь таблицы «Заказчики» с таблицей «Курьеры».

Поле: «КодКурьера» в обеих таблицах.

Тип связи: один ко многим с обеспечением целостности данных.

(один со стороны таблицы «Курьеры»)

Связывание: мастер подстановок в таблице «Заказчики»

Примечания: предусматривает добавление в структуру данных модуля «Курьеры».

3.Связь таблицы «Заказчики» с таблицей «Примечания».

Поле: «КодЗаказчика» в обеих таблицах.

Тип связи: один ко многим без обеспечением целостности данных.

(один со стороны таблицы «Заказчики»)

(возможно связывание один к одному)

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

Часть 2. (листинг 2.2)

(таблицы «Заказчики», «КредитАванс», «ОсновныеСчета», «Дистрибутивы», «Системы»,

«ФормаОплаты», «ТипСистемы», «Платежки», «СчетаФактуры», «СчетаФактурыОсновные»)

1.Связь таблицы «Заказчики» с таблицей «ОсновныеСчета».

Поле: «КодЗаказчика» в обеих таблицах.

Тип связи: один ко многим с обеспечением целостности данных с каскадным удалением и каскадным обновлением данных.

(один со стороны таблицы «Заказчики»)

Связывание: мастер подстановок в таблице «ОсновныеСчета»

Примечания: у каждого заказчика может быть много счетов.

2.Связь таблицы «Заказчики» с таблицей «КредитАванс».

Поле: «КодЗаказчика» в обеих таблицах.

Тип связи: один ко многим без обеспечения целостности данных.

(один со стороны таблицы «Заказчики»)

(возможно связывание один к одному?)

Связывание: мастер подстановок в таблице «КредитАванс»

3.Связь таблицы «Заказчики» с таблицей «СчетаФактуры».

Поле: «КодЗаказчика» в обеих таблицах.

Тип связи: один ко многим без обеспечения целостности данных.

(один со стороны таблицы «Заказчики»)

Связывание: мастер подстановок в таблице «СчетаФактуры»

Примечания: у каждого заказчика может быть много счетов-фактур.

4. Связь таблицы «ОсновныеСчета» с таблицей «Дистрибутивы».

Поле: «КодСчета» в обеих таблицах.

Тип связи: один ко многим с обеспечением целостности данных с каскадным удалением и каскадным обновлением данных.

(один со стороны таблицы «ОсновныеСчета»)

Связывание: мастер подстановок в таблице «Дистрибутивы»

Примечания: в каждый счет может входить много записей по заказам.

5. Связь таблицы «ОсновныеСчета» с таблицей «Платежки».

Поле: «КодСчета» в обеих таблицах.

Тип связи: один ко многим с обеспечением целостности данных с каскадным удалением и каскадным обновлением данных.

(один со стороны таблицы «ОсновныеСчета»)

Связывание: мастер подстановок в таблице «Дистрибутивы»

Примечания: в каждому счету может относится несколько платежных поручений.

(*Если платежное поручение оплачивает несколько счетов, то при внесении данных к счетам пишется одно и тоже платежное поручение, но суммы вносятся в соответствии с суммой счета)

6. Связь таблицы «ОсновныеСчета» с таблицей «СчетаФактурыОсновные».

Поле: «КодСчета» в обеих таблицах.

Тип связи: один ко многим с обеспечением целостности данных с каскадным удалением и каскадным обновлением данных.

(один со стороны таблицы «ОсновныеСчета»)

Связывание: мастер подстановок в таблице «Дистрибутивы»

Примечания: в каждому счету может относится несколько счетов-фактур на системы.

7. Связь таблицы «Дистрибутивы» с таблицей «Системы».

Поле: «КодСистемы».

Тип связи: один ко многим без обеспечения целостности данных.

(один со стороны таблицы «Системы»)

Связывание: мастер подстановок в таблице «Дистрибутивы»

Примечания: данная связь заменяет повторяющееся текстовые значения названия систем соответствующим кодом из таблицы «Системы».

8. Связь таблицы «Дистрибутивы» с таблицей «ТипСистемы».

Поле: «Код» в обеих таблицах.

Тип связи: один ко многим без обеспечения целостности данных.

(один со стороны таблицы «ТипСистемы»)

Связывание: мастер подстановок в таблице «Дистрибутивы»

Примечания: данная связь заменяет повторяющееся текстовые значения типа систем соответствующим кодом из таблицы «ТипСистемы».

9. Связь таблицы «ОсновныеСчета» с таблицей «ФормаОплаты».

Поле: «Код» в обеих таблицах.

Тип связи: один ко многим без обеспечения целостности данных.

(один со стороны таблицы «ФормаОплаты»)

Связывание: мастер подстановок в таблице «ОсновныеСчета»

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

10. Связь таблицы «Системы» с таблицей «КредитАванс».

Временная связь, возможно в дальнейшем будет удалена.

Часть 3. (листинг 2.3)

(таблицы «Заказчики», «ОсновныеСчета», "АвансПоОстаткамС1996Года», «ДанныеДляАвансОтчета», «Системы», «АвансовыйОтчет».)

1. Связь таблицы «Заказчики» с таблицей «АвансПоОстаткамС1996Года».

Поле: «КодЗаказчика» в таблице «Заказчики» с полем «Заказчик» в таблице «АвансПоОстаткамС1996Года».

Тип связи: один ко многим с обеспечением целостности данных.

(один со стороны таблицы «Заказчики»)

Связывание: в окне схемы данных.

Примечания: к каждому заказчику может относится несколько записей по месяцам по авансовому отчету.

2. Связь таблицы «Заказчики» с таблицей «ДанныеДляАвансОтчета».

Поле: «КодЗаказчика» в обеих таблицах.

Тип связи: один ко многим без обеспечения целостности данных.

(один со стороны таблицы «Заказчики»)

Связывание: мастер подстановок в таблице «ДанныеДляАвансОтчета»

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

3. Связь таблицы «Системы» с таблицей «ДанныеДляАвансОтчета».

Поле: «КодСистемы» в обеих таблицах.

Тип связи: один ко многим без обеспечения целостности данных.

(один со стороны таблицы «Заказчики»)

Связывание: мастер подстановок в таблице «ДанныеДляАвансОтчета»

Примечания: данная связь заменяет повторяющееся текстовые значения названия системы соответствующим кодом из таблицы «Системы».

4. Связь таблицы «ОсновныеСчета» с таблицей «ДанныеДляАвансОтчета».

Поле: «КодСчета» в обеих таблицах.

Тип связи: один ко многим без обеспечения целостности данных.

(один со стороны таблицы «ОсновныеСчета»)

Связывание: мастер подстановок в таблице «ДанныеДляАвансОтчета»

Примечания: к каждому счета может относится несколько записей по авансовому отчету.

5. Связь таблицы «ДанныеДляАвансОтчета» с таблицей «АвансовыйОтчет».

Поле: «Код» в таблице «ДанныеДляАвансОтчета» с полем «ИдентКод» в таблице «АвансовыйОтчет».

Тип связи: один ко многим с обеспечения целостности данных с каскадным удалением и каскадным обновлением данных.

(один со стороны таблицы «ДанныеДляАвансОтчета»)

Связывание: в окне схемы данных.

Часть 4. (листинг 2.4)

(таблицы «Заказчики», «ДругиеСчета», «ДругиеПлатежки», «ДругиеЗаказы», «ДанныеДляАвансОтчетаДр», «АвансовыйОтчетДр».)

1. Связь таблицы «Заказчики» с таблицей «ДругиеСчета».

Поле: «КодЗаказчика» в обеих таблицах.

Тип связи: один ко многим с обеспечения целостности данных с каскадным удалением и каскадным обновлением данных.

(один со стороны таблицы «Заказчики»)

Связывание: в окне схемы данных.

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

2. Связь таблицы «Заказчики» с таблицей «ДанныеДляАвансОтчетаДр».

Поле: «КодЗаказчика» в обеих таблицах.

Тип связи: один ко многим без обеспечения целостности данных.

(один со стороны таблицы «Заказчики»)

Связывание: мастер подстановок в таблице «ДанныеДляАвансОтчетаДр»

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

3. Связь таблицы «ДругиеСчета» с таблицей «ДругиеЗаказы».

Поле: «КодСчета» в обеих таблицах.

Тип связи: один ко многим с обеспечения целостности данных с каскадным удалением и каскадным обновлением данных.

(один со стороны таблицы «ДругиеСчета»)

Связывание: мастер подстановок в таблице «ДругиеЗаказы»

Примечания: к каждому счету может относится несколько записей по дополнительным заказам.

4. Связь таблицы «ДругиеСчета» с таблицей «ДругиеПлатежки».

Поле: «КодСчета» в обеих таблицах.

Тип связи: один ко многим с обеспечения целостности данных с каскадным удалением и каскадным обновлением данных.

(один со стороны таблицы «ДругиеСчета»)

Связывание: в окне схемы данных.

Примечания: каждый счет может быть оплачен несколькими платежными поручениями.

5. Связь таблицы «ДругиеСчета» с таблицей «ДанныеДляАвансОтчетаДр».

Поле: «КодСчета» в обеих таблицах.

Тип связи: один ко многим без обеспечения целостности данных.

(один со стороны таблицы «ДругиеСчета»)

Связывание: мастер подстановок в таблице «ДанныеДляАвансОтчетаДр»

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

6. Связь таблицы «ДанныеДляАвансОтчетаДр» с таблицей «АвансовыйОтчетДр».

Поле: «Код» в таблице «ДанныеДляАвансОтчетаДр» с полем «ИдентКод» в таблице «АвансовыйОтчетДр».

Тип связи: один ко многим с обеспечения целостности данных с каскадным удалением и каскадным обновлением данных.

(один со стороны таблицы «ДанныеДляАвансОтчета»)

Связывание: в окне схемы данных.

Часть 5. (листинг 2.5)

(таблицы «ОсновныеСчета», «Источник», «Подразделение», «Сотрудники»)

1. Связь таблицы «ОсновныеСчета» с таблицей «Источник».

Поле: «КодИсточника» в обеих таблицах.

Тип связи: один ко многим без обеспечения целостности данных.

(один со стороны таблицы «Источник»)

Связывание: мастер подстановок в таблице «ОсновныеСчета»

Примечания: данная связь заменяет повторяющееся текстовые значения названия источника информации об организации соответствующим кодом из таблицы «Источник».

2. Связь таблицы «ОсновныеСчета» с таблицей «Подразделение».

Поле: «КодПодразделения» в обеих таблицах.

Тип связи: один ко многим без обеспечения целостности данных.

(один со стороны таблицы «Подразделение»)

Связывание: мастер подстановок в таблице «ОсновныеСчета»

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

3. Связь таблицы «ОсновныеСчета» с таблицей «Сотрудники».

Поле: «КодСотрудника» в обеих таблицах.

Тип связи: один ко многим без обеспечения целостности данных.

(один со стороны таблицы «Сотрудники»)

Связывание: мастер подстановок в таблице «ОсновныеСчета»

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

Часть 6. (листинг 2.6)

(таблицы «Изменение АвансОтчета», «Системы», «СчетаФактуры», «МесяцыСГодом», «ПоследнииДниМесяцаСГодом»)

1. Связь таблицы «Изменение АвансОтчета» с таблицей «Системы».

Поле: «КодСистемы» в обеих таблицах.

Тип связи: один ко многим без обеспечения целостности данных.

(*Может стоит заменить тип связи на «с обеспечением целостности данных»?)

(один со стороны таблицы «Системы»)

Связывание: мастер подстановок в таблице «Изменение АвансОтчета»

Примечания: данная связь проверяет соответствие на правильность занесения кодов систем.

2. Связь таблицы «СчетаФактуры» с таблицей «МесяцыСГодом».

Поле: «Код» в обеих таблицах.

Тип связи: один ко многим без обеспечения целостности данных.

(один со стороны таблицы «МесяцыСГодом»)

Связывание: мастер подстановок в таблице «Изменение АвансОтчета»

Примечания: данная связь заменяет повторяющееся текстовые значения месяца и года даты счета-фактуры соответствующим кодом из таблицы «МесяцыСГодом».

3. Связь таблицы «СчетаФактуры» с таблицей «ПоследнииДниМесяцаСГодом».

Поле: «КодСчетаФактуры» в таблице «СчетаФактуры» с полем «Код» в таблице «ПоследнииДниМесяцаСГодом».

. Тип связи: один ко многим без обеспечения целостности данных.

(один со стороны таблицы «МесяцыСГодом»)

Связывание: мастер подстановок в таблице «Изменение АвансОтчета»

Примечания: данная связь заменяет повторяющееся текстовые значения месяца и года даты счета-фактуры соответствующим кодом из таблицы «ПоследнииДниМесяцаСГодом».

3.5. Техническая реализация проекта.

3.5.1. Общее описание работы с приложением.

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

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

выписка счетов;

- ввод и распределение денежных средств по платежным поручениям;

- ввод дополнительных данных финансового и справочного характера;

- получение справочной информации различного характера по конкретной организации;

- получение финансовой информации в общем.

Соответственно, для выписки счетов по основному профилю работы предприятия (Системы семейства «Консультант Плюс») пользователю необходимо выбрать в меню «Оформление счетов» пункт «Счета по системам Консультант Плюс» и из раскрывающегося списка выбрать пункт «Оформление». Далее в форме необходимо найти требуемого заказчика, выбором из списка либо по процедуре поиска, или ввести нового и оформить на организацию новый счет. Номер нового счета вносится автоматически, в порядке последовательных номеров. Далее, выбором из раскрывающихся списков требуется выбрать необходимые позиции счета и добавить их, в буфер данных для распечатки.

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

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

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

3.5.2. Формы отчетности (счетов, актов, счетов-фактур, накладных).

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

Для всех типов счетов, по событию форматирование области заголовка отчета, по процедуре обработки события, изменяется свойство «Visible» для подчиненного отчета и в соответствии со значениями глобальной переменной ВалДляСчета, на печать выводятся реквизиты организации для перевода денежных средств на счета в разных банках («Федеральный Банк Инноваций и Развития», «Валютное управление СБ РФ»).

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

3.5.3. Сервисные функции.

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

3.5.4. Описание структуры программы.

Учитывая сформированную иерархическую структуру данных и очередность реализации проекта процесс технической реализации состоял из следующих этапов.

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

Для реализации данного этапа была разработана структура взаимодействия трех форм:

1. «ОсновнаяОформлениеСчетов» - основная

(источник записей таблица «Заказчики»).

2. «ОсновныеСчета:Подчиненая» - подчиненная1 (к основной)

(источник записей таблица «СчетаОсновные»).

3. «Дистрибутивы1» - подчиненная1.1 (к подчиненной1)

(источник записей таблица «Дистрибутивы»).

Форма «ОсновнаяОформлениеСчетов».

а) Поля.

1) «Образец»

Назначение: для ввода текстовой и цифровой информации использующейся для поиска по названию организации в процедуре обработки события кнопки «Кнопка165»(Найти).

Вводимое значение: текстовое или цифровое.

2) «Долг»

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

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

Примечание: при очистке данного поля снимается задолженность с данной организации и очищаются соответствующее связанные поля в таблице «КредитАванс». Это осуществляется по событию «После обновления» в процедуре обработки события (листинг 3.1).

3) «Код» (поле со списком)

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

Заполнение: выбор из списка.

Источник записей: аналогичное поле в исходной таблице.

4) «Организация»

Назначение: для отображения названия текущей организации.

Источник записей: аналогичное поле в исходной таблице.

5) «Прейскурант»

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

Заполнение: выбор из списка.

Источник записей: аналогичное поле в исходной таблице.

Примечания:

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

- на событию «Потеря фокуса» в процедуре обработки события (листинг 3.3), происходит проверка на наличие ввода пустого значения.

6) «ВидСопровождения»

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

Заполнение: выбор из списка (значения списка изменяются в соответствии с типом прейскуранта).

Источник записей: аналогичное поле в исходной таблице.

7) «Список116»(Список)

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

Источник записей: SQL - запрос по таблице «Заказчики».

Примечания: сформирован с помощью мастера.

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

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

Источники записей: аналогичные поля в исходной таблице.

б) Кнопки. (для кнопок процедуры обработки событий вызываются по событию «Нажатие кнопки»)

1) «Кнопка165»(Найти).

Назначение: для поиска и вывода информации по организации по текстовому образцу введенному в поле «Образец». Процедура обработки событий (листинг 3.4).

Примечания: задание флагу flagFind значения True (используется для отлавливания ошибки в «Отсутствие текущей записи», процедуре обработки события по событию «Текущая запись» для формы «Основная»).

2) «Кнопка177»(Настройки счета).

Назначение: для вывода на экран диалогового окна «Настройки счета» (смотри пункт __ ).

Примечания: реализация с помощью мастера.

3) «Кнопка170»(Настройки счета).

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

Примечания: реализация с помощью мастера.

4) «КнопкаЗакрытьФорму» (Настройки счета).

Назначение: для закрытия текущей формы.

Примечания: реализация с помощью мастера.

5) «Кнопка_Новая_Запись» (Новая организация).

Назначение: для перехода в текущей форме на новую запись (ввод новой организации).

Примечания: реализация с помощью мастера, задание флагу flagNew значения True (используется для отлавливания ошибки в «Отсутствие текущей записи», процедуре обработки события по событию «Текущая запись» для формы «Основная»).

6) «Примечания»

Назначение: для вывода диалогового окна записи примечаний к текущей организации

Примечания: реализация с помощью мастера.

в) Переключатели. (для переключателей процедуры обработки событий вызываются по событию «После обновления»)

1) «Группа 168» (Организация-Счет).

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

Примечания: задание свойству «Visible» значения True или False в зависимости от положения переключателя. событию «Текущая запись» для формы «Основная»).

Форма «ОсновныеСчета:Подчиненая».

а) Поля.

1) «НомерСчета».

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

Заполнение: ввод с клавиатуры или по процедуре обработки событий кнопки «КнопкаНоваяЗапись» в данной форме (смотри пункт __).

Источник записей: аналогичное поле в исходной таблице.

Примечание: значение данного поля изменяется в процедуре обработки событий по событию «После обновления» поля со списком «КодОтдела» (смотри пункт 4)).

2) «ДатаСчета».

Назначение: для ввода и отображения даты счета для текущей счета.

Заполнение: ввод с клавиатуры или по умолчанию, в свойстве «Значение по умолчанию», значением текущей даты (функция Now()).

Источник записей: аналогичное поле в исходной таблице.

3) «Код» (Форма оплаты).

Назначение: для отображения и выбора формы оплаты данного счета.

Заполнение: выбор из списка.

Источник записей: аналогичное поле в исходной таблице.

Примечание: *надо убрать ПОС по событию «После обновления».

4) «КодОтдела».

Назначение: для отображения и выбора отдела который выписал данный счет..

Заполнение: выбор из списка.

Источник записей: аналогичное поле в исходной таблице.

Примечание: по процедуре обработки событий по событию «После обновления» изменяется значение поля «НомерСчета» в соответствии с существующей номенклатурой (листинг 3.6).

5) «СрокДействияСчета» (Срок действия счета).

Назначение: для отображения и ввода даты по которую будет действителен текущий счет.

Заполнение: ввод с клавиатуры или по умолчанию, в свойстве «Значение по умолчанию», значением последнего числа текущего месяца (функция EndMonth() - смотри список функций базы данных).

Источник записей: аналогичное поле в исходной таблице.

Примечание: * необходимо переделать функцию EndMonth(), чтобы значение срока действия счета = текущая дата + 20 (15) дней.

6) «ЦенаДистрибутива» - скрытое поле.

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

Заполнение: по процедуре обработки событий для события «После обновления» поля «КодСистемы» в форме Подчиненная1.1 (смотри пункт __ в описании формы Подчиненная1.1).

Примечание: *необходимо сбрасывать значение данного поля в Null при переходе по записям в форме Подчиненная1.1, для избежания ситуации с занесением цены предыдущего или последующего дистрибутива.

7) «ЦенаСпецВыпуска» - скрытое поле.

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

Заполнение: по процедуре обработки событий для события «После обновления» поля «КодСистемы» в форме Подчиненная1.1 (смотри пункт __ в описании формы Подчиненная1.1).

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

8) «Сопровождение» - скрытое поле.

Назначение: свободное поле для хранения цены на сопровождение системы, текущей в форме Подчиненная1, в соответствии с параметрами полей «Прейскурант» и «ВидСопровождения» формы Основная.

Заполнение: по процедуре обработки событий для события «После обновления» поля «КодСистемы» в форме Подчиненная1.1 (смотри пункт __ в описании формы Подчиненная1.1).

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

9) «Месяц» - скрытое поле.

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

Заполнение: по процедуре обработки событий для события «После обновления» поля «КодСистемы» в форме Подчиненная1.1 (смотри пункт __ в описании формы Подчиненная1.1).

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

10) «КодЗаказчика» - скрытое поле.

Назначение: главное связующее поле по для форм Подчиненная1 и Основная.

Заполнение: автоматически .

Источник записей: аналогичное поле в исходной таблице.

Примечание: не удалять.

б) Флажки.

1) «ВыпискаНакладной» и «ВыпискаАктов» ?.

Назначение: отметка о выписке актов и накладных при покупке системы.

Заполнение: по процедуре обработки события для кнопки «Кнопка170» в форме Основная.

Источник записей: аналогичное поле в исходной таблице.

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

в) Кнопки. (для кнопок процедуры обработки событий вызываются по событию «Нажатие кнопки»)

1) «КнопкаНоваяЗапись».

Назначение: для перехода на новую запись для данной форма (новый счет для текущей организации) и заполнения поля «НомерСчета» следующим номером согласно существующей номенклатуре, очистка временных таблиц «НаВыпискуСчета» и «НаВыпискуНакладной». Процедура обработки событий (листинг 3.7).

Примечания: * отладить на возникновение ошибок при нестандартном номере предыдущего счета.

2) «Кнопка333», «Кнопка334», «Кнопка335», «Кнопка336».

Назначение: для перехода по записям для текущей формы (счета для данной организации). Реализация с помощью мастера.

Форма «Дистрибутивы1».

а) Поля.

1) «КодМесяца» (Месяц) - поле со списком.

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

Заполнение: выбор из списка.

Источник записей: аналогичное поле в исходной таблице.

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

2) «КодСистемы» (Система).

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

Заполнение: выбор из списка.

Источник записей: аналогичное поле в исходной таблице.

Примечание: для данного поля, в процедуре обработки событий по событию «После обновления», происходит заполнение поля «ЦенаДистрибутива», «ЦенаСпецВыпуска», «Сопровождение» формы Подчиненая1, соответствии с выбранным значением данного поля и со значениями полей «Прейскурант» и «ВидСопровождения», формы Основная (листинг 3.9).

3) «Код» (Тип системы) - поле со списком.

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

Заполнение: выбор из списка.

Источник записей: аналогичное поле в исходной таблице.

Примечание: для данного поля, в процедуре обработки событий по событию «После обновления», происходит расчет цены системы и сопровождения (поля «Цена»и «Сопровождение») в соответствии с выбранным значением данного поля и со значениями полей «СпецвыпускИлиНет», «Количество», «Скидки», «КоличествоМ», «СкидкиС» текущей формы (листинг 3.10).

4) «СпецвыпускИлиНет» - флажок. (Спецвыпуск).

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

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

Примечание: для данного поля, в процедуре обработки событий по событию «После обновления», происходит расчет цены системы и сопровождения (поля «Цена»и «Сопровождение») в соответствии со значением данного поля и со значениями полей «СпецвыпускИлиНет», «Количество», «Скидки», «КоличествоМ», «СкидкиС» текущей формы (листинг 3.11).

5) «Флажок58» - флажок. (только ИПС).

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

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

Примечание: для данного поля, в процедуре обработки событий по событию «После обновления», происходит расчет цены сопровождения в соответствии со значением данного поля и со значениями полей «СпецвыпускИлиНет», «Количество», «Скидки», «КоличествоМ», «СкидкиС» текущей формы, и присваивается Null значению поле «Цена» (листинг 3.12).

6) «Примечание».

Назначение: для ввода и отображения комментариев к текущему заказу.

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

7) «НомерДистрибутива» - необходимость в данной форме ???.

8) «Количество» (Количество систем). - необходимость в данной форме ???.

Назначение: для ввода и отображения количества систем на которые оформляется данный заказ счета.

Заполнение: постоянное значение, равное 1.

Источник записей: аналогичное поле в исходной таблице.

Примечание: для данного поля, в процедуре обработки событий по событию «После обновления», происходит расчет цен по данному заказу счета в соответствии со значением в данном поле и со значениями полей «СпецвыпускИлиНет», «Скидки», «КоличествоМ», «СкидкиС» текущей формы (листинг 3.13).

9) «Скидки» (Скидки на систему).

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

Заполнение: ввод с клавиатуры, значение для ввода - дробное число (0.15 - 15%).

Источник записей: аналогичное поле в исходной таблице.

Примечание: для данного поля, в процедуре обработки событий по событию «После обновления», происходит расчет цен по данному заказу счета в соответствии со значением скидки в данном поле и со значениями полей «СпецвыпускИлиНет», «Количество», «КоличествоМ», «СкидкиС» текущей формы (листинг 3.14).

10) «КоличествоМ» (Количество месяцев)

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

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

Примечание: для данного поля, в процедуре обработки событий по событию «После обновления», происходит расчет цен по данному заказу счета в соответствии со значением в данном поле и со значениями полей «СпецвыпускИлиНет», «Скидки», «Количество», «СкидкиС» текущей формы (листинг 3.15).

11) «СкидкиС» (Скидки на сопров.).

Назначение: для ввода и отображения величены скидки на сопровождение.

Заполнение: ввод с клавиатуры, значение для ввода - дробное число (0.15 - 15%).

Источник записей: аналогичное поле в исходной таблице.

Примечание: для данного поля, в процедуре обработки событий по событию «После обновления», происходит расчет цен по данному заказу счета в соответствии со значением скидки в данном поле и со значениями полей «СпецвыпускИлиНет», «Количество», «КоличествоМ», текущей формы (листинг 3.16).

12) «Цена» (Поставка).

Назначение: для ввода и отображения цены на систему при покупке.

Заполнение: ввод с клавиатуры или по процедуре обработки событий вышеописанных полей.

Источник записей: аналогичное поле в исходной таблице.

13) «Сопровождение».

Назначение: для ввода и отображения цены на сопровождение.

Заполнение: ввод с клавиатуры или по процедуре обработки событий вышеописанных полей.

Источник записей: аналогичное поле в исходной таблице.

14) «КодСчета» - скрытое поле.

Назначение: главное связующее поле по для форм Подчиненная1 и Подчиненная1.1.

Заполнение: автоматически .

Источник записей: аналогичное поле в исходной таблице.

Примечание: не удалять.

15) «СистемыНаВыписку» - список.

Назначение: свободное поле для отображения перечня заказов входящих в счет.

Заполнение: по SQL - запросу.

Источник строк: SQL - запрос по таблице «НаВыпискуСчета».

(SELECT DISTINCTROW [НаВыпискуСчета].[Код], [НаВыпискуСчета].[Система], [НаВыпискуСчета].[Количество] FROM [НаВыпискуСчета];)

Примечание: так как данное поле имеет источник строк SQL - запрос по временной таблице, то отображение изменений для данного поля происходит после обновления данных в форме (DoCmd Refresh).

б) Кнопки. (для кнопок процедуры обработки событий вызываются по событию «Нажатие кнопки»)

1) «Кнопка63» (Добавить новую >- при выписке в счете нового заказа).

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

Примечания: - .

2) «Кнопка69» (Добавить > - при повторной выписке счета).

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

Примечания: - .

3) «Кнопка71», «Кнопка72», «Кнопка73», «Кнопка75».

Назначение: для перехода по записям для текущей формы (заказы для данной счета). Реализация с помощью мастера.

4) «Кнопка70».

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

Примечания: - .

5) «Кнопка74».

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

Примечания: - .

Комментарии.

Описанная структура имеет следующие особенности работы

1. Для формы Основная по событию «Текущая запись» в процедуре обработки событий происходит расчет по значений задолженности текущей организации (заполняется поле «Долг») и проверяется наличие важных примечаний для данной организации (выделение цветом текста кнопки «Примечания»)

(листинг 3.21).

2. Также для формы Основная при загрузки инициализируются две переменные flagNew и flagFind использующиеся для устранения ошибок в процедуре обработки событий по событию «Текущая запись» для формы Основная (для новой организации не может быть кредиторской или авансовой задолженности). Значения переменных - флагов устанавливаются в процедурах обработки событий для кнопок «Кнопка165» (flagFind) и «Кнопка_Новая_Запись» (flagNew). (листинг 3.22).

3. Для формы Подчиненная1 по событию «Открытие» в процедуре обработки событий происходит очистка временной таблицы «НаВыпискуСчета» и «НаВыпискуНакладной» по функции ClearListBox()

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

Для реализации данного этапа была разработана структура взаимодействия трех форм:

1. «Просмотр» - основная

(источник записей таблица «Заказчики»).

2. «ПросмотрSub» - подчиненная1 (к основной)

(источник записей таблица «СчетаОсновные»).

3. «ПросмотрSubSub» - подчиненная1.1 (к подчиненной1)

(источник записей таблица «Дистрибутивы»).

4. «Платежки» - подчиненная1.2 (к подчиненной1)

(источник записей таблица «Платежки»).

5. «СчетаФактурыОсновные» - подчиненная1.3 (к подчиненной1)

(источник записей таблица «СчетаФактурыОсновные»).

Форма «Просмотр».

а) Поля.

1) «Образец»

Назначение: для ввода текстовой и цифровой информации использующейся для поиска

по названию организации в процедуре обработки события кнопки «Кнопка165»(Найти).

Вводимое значение: текстовое или цифровое.

2) «Код» (поле со списком)

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

Заполнение: выбор из списка.

Источник записей: аналогичное поле в исходной таблице.

3) «Организация»

Назначение: для отображения названия текущей организации.

Источник записей: аналогичное поле в исходной таблице.

4) «Список116»(Список)

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

Источник записей: SQL - запрос по таблице «Заказчики».

Примечания: сформирован с помощью мастера.

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

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

Источники записей: аналогичные поля в исходной таблице.

6) «ПервыйМесяц»

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

Примечания: вводимое значение в кратком формате даты (например 04.03.97) используется только для формирования начальной даты при выписке акты и счета-фактуры на сопровождение для текущей организации.

б) Кнопки. (для кнопок процедуры обработки событий вызываются по событию «Нажатие кнопки»)

1) «Кнопка165»(Найти).

Назначение: для поиска и вывода информации по организации по текстовому образцу введенному в поле «Образец». Процедура обработки событий (листинг 3.23).

Примечания: задание флагу flagFind значения True (используется для отлавливания ошибки в «Отсутствие текущей записи», процедуре обработки события по событию «Текущая запись» для формы «Основная»).

2) «Кнопка139»(Настройки печати).

Назначение: для вывода на экран диалогового окна «Настройки счета» (смотри пункт __).

Примечания: реализация с помощью мастера.

3) «Кнопка174».

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

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

4) «КнопкаЗакрытьФорму» (Настройки счета).

Назначение: для закрытия текущей формы.

Примечания: реализация с помощью мастера.

5) «Кнопка181».

Назначение: для предварительного просмотра образца актов и счетов-фактур на сопровождение по счету для текущей организации (листинг 3.25)

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

Форма «ПросмотрSub».

а) Поля.

1) «НомерСчета».

Назначение: для отображения номера счета для текущей организации.

Источник записей: аналогичное поле в исходной таблице.

2) «Код» (Форма оплаты).

Назначение: для отображения и выбора формы оплаты данного счета.

Заполнение: выбор из списка.

Источник записей: аналогичное поле в исходной таблице.

3) «КодОтдела»(Отделы).

Назначение: для отображения и выбора отдела который выписал данный счет..

Заполнение: выбор из списка.

Источник записей: аналогичное поле в исходной таблице.

4) «НомерНакладной» ((№ Накладной).

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

Заполнение: в ввод с клавиатуры или в процедуре обработки событий по событию «После обновления» группы «Группв337» (смотри пункт __ ).

Источник записей: аналогичное поле в исходной таблице.

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

5) «ВсеПлатежки» - скрытое поле.

Назначение: свободное поле для хранения текстовой информации по платежным поручениям оплачивающим текущий счет (Пример: № 24 от 03.02.97).

Заполнение: в процедуре обработки событий кнопки «Кнопка174» в форме Основная. (смотри пункт __ ).

Примечание: * усовершенствовать заполнение по правилам (Пример: 3 февраля 1997 года).

6) «ПоСчету» (е по счету).

Назначение: свободное поле для отображения общей суммы счета включая НДС для визуальной оценки совпадения суммы по счету и суммы по платежным поручениям.

Заполнение: в процедуре обработки событий кнопки «Кнопка347» (Занести).

7) «ПоПлатежке» (е по платежке).

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

Заполнение: в процедуре обработки событий кнопки «Кнопка347» (Занести)(смотри пункт __ ).

8) «Разница».

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

Заполнение: в процедуре обработки событий кнопки «Кнопка347» (Занести)(смотри пункт __ ).

9) «КодИсточника».

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

Заполнение: выбор из списка .

Источник записей: аналогичное поле в исходной таблице.

10) «КодПодразделения».

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

Заполнение: выбор из списка .

Источник записей: аналогичное поле в исходной таблице.

11) «КодСотрудника».

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

Заполнение: выбор из списка .

Источник записей: аналогичное поле в исходной таблице.

12) «КодАгента».

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

Заполнение: выбор из списка .

Источник записей: аналогичное поле в исходной таблице.

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

13) «Агент_процент_1»(% от реализации).

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

Заполнение: ввод с клавиатуры, тип вводимого значения дробное число с разделителем точка (Пример: 0.1 - 10%).

Источник записей: аналогичное поле в исходной таблице.

Примечание: в процедуре обработки событий по событию «После обновления» для данного поля рассчитывается значение в поле «ВознагрАгента» и «НаРукиАгент» текущей формы (листинг 3.27).

14) «Агент_процент_2»(% от сопровож.).

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

Заполнение: ввод с клавиатуры, тип вводимого значения дробное число с разделителем точка (Пример: 0.1 - 10%).

Источник записей: аналогичное поле в исходной таблице.

Примечание: в процедуре обработки событий по событию «После обновления» для данного поля рассчитывается значение в поле «ВознагрАгента» «НаРукиАгент» текущей формы (листинг 3.28).

15) «ВознагрАгент» (Сумма).

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

Заполнение: в процедуре обработки событий по событию «После обновления» для поля «Агент_процент_1» и поля «Агент_процент_2».

Источник записей: аналогичное поле в исходной таблице.

16) «НаРукиАгент» (На руки).

Назначение: для отображения суммы агентского вознаграждения выдаваемого агенту от суммы данного счета.

Заполнение: в процедуре обработки событий по событию «После обновления» для поля «Агент_процент_1» и поля «Агент_процент_2».

Источник записей: аналогичное поле в исходной таблице.

17) «КурсДоллара» (Курс $).

Назначение: для отображения сегодняшнего курса доллара.

Заполнение: ввод с клавиатуры (пока).

Источник записей: аналогичное поле в исходной таблице.

Поле392

18) «Поле392» (Сумма в $).

Назначение: свободное поле для отображения суммы агентского вознаграждения выдаваемого агенту от суммы данного счета в долларах.

Заполнение: =[ВознагрАгент]/[КурсДоллара].

19) «СуммаСНакоплением».

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

Заполнение: в процедуре обработки событий по событию «После обновления» для поля «КодАгента».

20) «КодЗаказчика» - скрытое поле.

Назначение: главное связующее поле по для форм Подчиненная1 и Основная.

Заполнение: автоматически .

Источник записей: аналогичное поле в исходной таблице.

Примечание: не удалять.

б) Флажки.

1) «ВыпискаНакладной» и «ВыпискаАктов».

Назначение: отметка о выписке актов и накладных при покупке системы.

Заполнение: по процедуре обработки события для кнопки «Кнопка174» в форме Основная.

Источник записей: аналогичное поле в исходной таблице.

2) «ОплатаСчета».

Назначение: отметка об оплате текущего счета.

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

Примечание: в процедуре обработки событий по событию «После обновления» для данного поля свойству Visible формы Подчиненая1.2 присваивается значение True или False в зависимости от факта оплаты счета (листинг 3.29).

3) «ВнесениеВАО»(Внесение в авансовый отчет). - скрытое поле

Назначение: отметка о внесение суммы по текущему счету в авансовый отчет.

Заполнение: по процедуре обработки события для кнопки «Кнопка347» в текущей форме.

Источник записей: аналогичное поле в исходной таблице.

в) Группы.

1) «Группа337».

Назначение: переключение между информацией о счете и информацией о заказах, входящих в счет.

Примечания: * автоматическое вычисление следующего номера накладной (поле «НомерНакладной»в текущей форме) и счета-фактуры (поле «НомерСчетаФактуры» в форме Подчиненая1.3) в процедуре обработки событий по событию «После обновления» для данной группы (листинг 3.30).

г) Кнопки. (для кнопок процедуры обработки событий вызываются по событию «Нажатие кнопки»)

1) «Кнопка322», «Кнопка323», «Кнопка324», «Кнопка325».

Назначение: для перехода по записям для текущей формы (счета для данной организации). Реализация с помощью мастера.

Примечания: * по процедурам обработки событий для данных кнопок происходит очистка содержимого временных таблиц «НаВыпискуСчета» и «НаВыпискуНакладной» (листинг 3.31).

2) «Кнопка347».

Назначение: для занесения данных по текущему счету в авансовый отчет (листинг 3.32).

Примечания: * отладить возникновение ошибок и тестировать, тестировать, тестировать.

3) «Кнопка368».

Назначение: для удаления данных по текущему счету из авансового отчета (листинг 3.33).

Примечания: * пользоваться аккуратно.

Форма «ПросмотрSubSub».

а) Поля.

1) «КодСистемы» (Система).

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

Заполнение: выбор из списка.

Источник записей: аналогичное поле в исходной таблице.

Примечание: *нужно ли позволять выбор и ввод в этом и следующих полях, кроме поля «НомерДистрибутива»

2) «Код» (Тип системы) - поле со списком.

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

Заполнение: выбор из списка.

Источник записей: аналогичное поле в исходной таблице.

3) «СпецвыпускИлиНет» - флажок. (Спецвыпуск).

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

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

4) «НомерДистрибутива».

Назначение: для ввода и отображения, номера дистрибутива выписываемой системы.

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

5) «Скидки» (Скидки на систему). - необходимость в данной форме ???.

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

Заполнение: ввод с клавиатуры, значение для ввода - дробное число (0.15 - 15%).

Источник записей: аналогичное поле в исходной таблице.

6) «КоличествоМ» (Количество месяцев) - необходимость в данной форме ???.

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

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

7) «СкидкиС» (Скидки на сопров.) - необходимость в данной форме ???.

Назначение: для ввода и отображения величены скидки на сопровождение.

Заполнение: ввод с клавиатуры, значение для ввода - дробное число (0.15 - 15%).

Источник записей: аналогичное поле в исходной таблице.

8) «Цена» (Поставка).

Назначение: для ввода и отображения цены на систему при покупке.

Источник записей: аналогичное поле в исходной таблице.

9) «Сопровождение». - необходимость в данной форме ???.

Назначение: для ввода и отображения цены на сопровождение.

Источник записей: аналогичное поле в исходной таблице.

10) «СистемыНаВыписку» - список.

Назначение: свободное поле для отображения перечня заказов входящих в счет.

Заполнение: по SQL - запросу.

Источник строк: SQL - запрос по таблице «НаВыпискуСчета».

(SELECT DISTINCTROW [НаВыпискуСчета].[Код], [НаВыпискуСчета].[Система], [НаВыпискуСчета].[Количество] FROM [НаВыпискуСчета];)

Примечание: так как данное поле имеет источник строк SQL - запрос по временной таблице, то отображение изменений для данного поля происходит после обновления данных в форме (DoCmd Refresh).

11) «КодСчета» - скрытое поле.

Назначение: главное связующее поле по для форм Подчиненная1 и Подчиненная1.1.

Заполнение: автоматически .

Источник записей: аналогичное поле в исходной таблице.

Примечание: не удалять.

12) «КодМесяца» - скрытое поле.

Назначение: для фиксации значения месяца прейскуранта по которому был выписан счет.

Источник записей: аналогичное поле в исходной таблице.

Примечание: используется при выписке актов.

б) Кнопки. (для кнопок процедуры обработки событий вызываются по событию «Нажатие кнопки»)

1) «КнопкаНЗ» (Добавить в накладную >).

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

Примечания: - .

2) «Кнопка49», «Кнопка50», «Кнопка51», «Кнопка52».

Назначение: для перехода по записям для текущей формы (заказы для данной счета). Реализация с помощью мастера.

Форма «Платежки» -ленточная форма.

а) Поля.

1) «НомерПлатежки».

Назначение: для ввода и отображения номера платежного поручения, оплачивающего текущий счет.

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

2) «ДатаПлатежки».

Назначение: для ввода и отображения даты платежного поручения, оплачивающего текущий счет.

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

3) «СуммаПлатежки».

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

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

4) «ДатаВыписки».

Назначение: для ввода и отображения даты выписки платежного поручения, оплачивающего текущий счет.

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

5) «КодСчета» - скрытое поле.

Назначение: главное связующее поле по для форм Подчиненная1 и Подчиненная1.2.

Заполнение: автоматически .

Источник записей: аналогичное поле в исходной таблице.

Примечание: не удалять.

Форма «СчетаФактурыОсновные».

а) Поля.

1) «НомерСчетаФактуры».

Назначение: для ввода и отображения номера счета-фактуры для текущего счета.

Заполнение: ввод с клавиатуры или в процедуре обработки событий по событию «После обновления» для группы «Группа337».

Источник записей: аналогичное поле в исходной таблице.

2) «КодСчета» - скрытое поле.

Назначение: главное связующее поле по для форм Подчиненная1 и Подчиненная1.3.

Заполнение: автоматически .

Источник записей: аналогичное поле в исходной таблице.

Примечание: не удалять.

Комментарии.

Описанная структура имеет следующие особенности работы

1. Для формы Основная и ПросмотрSub по событию «Текущая запись» в процедуре обработки событий происходит проверка значения поля «ОплатаСчета» и в соответствии с этим свойству формы Подчиненная1.2 задается значение True или False.(листинг 3.35).

3. Оформление, учет и выписка первичной бухгалтерской документации (счетов) по дополнительным заказам (программное и аппаратное обеспечение, информационные услуги)

Для реализации данного этапа была разработана структура взаимодействия трех форм:

1. «ДругиеЗаказыОформление» - основная

(источник записей таблица «Заказчики»).

2. «ДругиеСчетаПод» - подчиненная1 (к основной)

(источник записей таблица «ДругиеСчета»).

3. «ДругиеСчетаПодПод» - подчиненная1.1 (к подчиненной1)

(источник записей таблица «Дистрибутивы»).

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

Форма «ДругиеЗаказыОформление».

а) Поля - аналогичны.

б) Группы - аналогичны.

в) Кнопки. (для кнопок процедуры обработки событий вызываются по событию «Нажатие кнопки»)

1) «Кнопка170».

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

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

Форма «ДругиеСчетаПод».

а) Поля - аналогичны, кроме:

1) «Цена», «Сопровождение», «ЦенаСпецВыпуска».

Назначение: для ввода и отображения номера счета-фактуры для текущего счета.

Заполнение: ввод с клавиатуры или в процедуре обработки событий по событию «После обновления» для группы «Группа337».

Источник записей: аналогичное поле в исходной таблице.

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

1) «КнопкаНоваяЗапись».

Назначение: для перехода на новую запись для данной форма (новый счет для текущей организации) и заполнения поля «НомерСчета» следующим номером согласно существующей номенклатуре, очистка временных таблиц «НаВыпискуСчета» и «НаВыпискуНакладной». Процедура обработки событий (листинг 3.37).

Примечания: * отладить на возникновение ошибок при нестандартном номере предыдущего счета.

2) «Кнопка333», «Кнопка334», «Кнопка335», «Кнопка336».

Назначение: для перехода по записям для текущей формы (счета для данной организации). Реализация с помощью мастера.

Форма «ДругиеСчетаПодПод».

а) Поля.

1) «КодСистемы» (Наименование).

Назначение: для ввода и отображения наименования товара в заказе для текущего счета.

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

2) «Примечания».

Назначение: для ввода и отображения примечания к товару в заказе для текущего счета.

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

3) «НомерДистрибутива» (Рег. номер).

Назначение: для ввода и отображения уникального идентификационного номера товара в заказе для текущего счета (если он есть).

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

4) «Количество».

Назначение: для ввода и отображения количества единиц товара в заказе для текущего счета (если он есть).

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

5) «Цена».

Назначение: для ввода и отображения стоимости указанного количества товара (без НДС) в заказе для текущего счета (то есть вводимое значение = цена 1-й ед. товара * кол-во товара).

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

5) «СистемыНаВыписку» - список.
Назначение: свободное поле для отображения перечня заказов входящих в счет.

Заполнение: по SQL - запросу.

Источник строк: SQL - запрос по таблице «НаВыпискуСчета».

(SELECT DISTINCTROW [НаВыпискуСчета].[Код], [НаВыпискуСчета].[Система], [НаВыпискуСчета].[Количество] FROM [НаВыпискуСчета];)

Примечание: так как данное поле имеет источник строк SQL - запрос по временной таблице, то отображение изменений для данного поля происходит после обновления данных в форме (DoCmd Refresh).

5) «КодСчета» - скрытое поле.

Назначение: главное связующее поле для форм Подчиненная1 и Подчиненная1.1.

Заполнение: автоматически .

Источник записей: аналогичное поле в исходной таблице.

Примечание: не удалять.

б) Кнопки. (для кнопок процедуры обработки событий вызываются по событию «Нажатие кнопки»)

1) «Кнопка63» (Добавить новую >- при выписке в счете нового заказа).

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

Примечания: - .

2) «Кнопка69» (Добавить > - при повторной выписке счета).

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

Примечания: - .

3) «Кнопка71», «Кнопка72», «Кнопка73», «Кнопка75».

Назначение: для перехода по записям для текущей формы (заказы для данной счета). Реализация с помощью мастера.

4) «Кнопка70».

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

Примечания: - .

5) «Кнопка74».

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

Примечания: - .

4. Оформление, учет и выписка вторичной отчетной документации (акты на установку, накладные, счета-фактуры, акты на информационные услуги), фиксирование информации о приходе денежных средств по счетам, формирование первичного финансового отчета по дополнительным заказам организации (программное и аппаратное обеспечение, информационные услуги)

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

1. «ПросмотрДрСчетов» - основная

(источник записей таблица «Заказчики»).

2. «ПросмотрДрСчетовSub» - подчиненная1 (к основной)

(источник записей таблица «ДругиеСчета»).

3. «ПросмотрДрСчетовSubSub» - подчиненная1.1 (к подчиненной1)

(источник записей таблица «ДругиеЗаказы»).

3. «ДругиеПлатежки» - подчиненная1.2 (к подчиненной1)

(источник записей таблица «ДругиеПлатежки»).

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

Форма «ПросмотрДрСчетов».

а) Поля - аналогичны.

б) Кнопки. (для кнопок процедуры обработки событий вызываются по событию «Нажатие кнопки») - аналогичны

в) Группы. (для групп процедуры обработки событий вызываются по событию «После обновления»).

1) «Группа 168» (Организация-Счет).

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

Примечания: задание свойству «Visible» значения True или False в зависимости от положения переключателя.

Форма «ПросмотрДрСчетовSub».

а) Поля - аналогичны, кроме.

1) «НомерСчетаФактуры».

Назначение: для ввода или отображения номера счета-фактуры для данного счета.

Заполнение: ввод с клавиатуры(пока).

Источник записей: аналогичное поле в исходной таблице.

Примечание: сделать автоматическое заполнение, продумать автоматическое заполнение в зависимости от формы оплаты (номера счетов-фактур по оплате за наличный и безналичный расчет разные).

2) «НомерНакладной».

Назначение: для ввода или отображения номера накладной для данного счета.

Заполнение: ввод с клавиатуры(пока).

Источник записей: аналогичное поле в исходной таблице.

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

в) Группы.

1) «Группа337».

Назначение: переключение между информацией о счете и информацией о заказах, входящих в счет.

Примечания:

г) Кнопки. (для кнопок процедуры обработки событий вызываются по событию «Нажатие кнопки»)

1) «Кнопка322», «Кнопка323», «Кнопка324», «Кнопка325».

Назначение: для перехода по записям для текущей формы (счета для данной организации). Реализация с помощью мастера.

Примечания: * по процедурам обработки событий для данных кнопок происходит очистка содержимого временных таблиц «НаВыпискуСчета» и «НаВыпискуНакладной» (листинг 3.43).

2) «Кнопка347».

Назначение: для занесения данных по текущему счету в авансовый отчет (листинг 3.44).

Примечания: * отладить возникновение ошибок и тестировать, тестировать, тестировать.

3) «Кнопка368».

Назначение: для удаления данных по текущему счету из авансового отчета (листинг 3.45).

Примечания: * пользоваться аккуратно.

Форма «ПросмотрДрСчетовSubSub».

а) Поля

1) «Наименование».

Назначение: для ввода и отображения наименования товара в заказе для текущего счета.

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

2) «Примечания».

Назначение: для ввода и отображения примечания к товару в заказе для текущего счета.

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

3) «НомерДистрибутива» (Рег. номер). ?

Назначение: для ввода и отображения уникального идентификационного номера товара в заказе для текущего счета (если он есть).

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

4) «Количество».

Назначение: для ввода и отображения количества единиц товара в заказе для текущего счета (если он есть).

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

5) «Цена».

Назначение: для ввода и отображения стоимости указанного количества товара (без НДС) в заказе для текущего счета (то есть вводимое значение = цена 1-й ед. товара * кол-во товара).

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

6) «СистемыНаВыписку» - список.
Назначение: свободное поле для отображения перечня заказов входящих в счет-фактуру.

Заполнение: по SQL - запросу.

Источник строк: SQL - запрос по таблице «НаВыпискуСчета».

(SELECT DISTINCTROW [НаВыпискуСчета].[Код], [НаВыпискуСчета].[Система], [НаВыпискуСчета].[Количество] FROM [НаВыпискуСчета];)

Примечание: так как данное поле имеет источник строк SQL - запрос по временной таблице, то отображение изменений для данного поля происходит после обновления данных в форме (DoCmd Refresh).

7) «Список63» - список.
Назначение: свободное поле для отображения заказов входящих в накладную.

Заполнение: по SQL - запросу.

Источник строк: SQL - запрос по таблице «НаВыпискуНакладной».

(SELECT DISTINCTROW НаВыпискуНакладной.Код, НаВыпискуНакладной.Система, НаВыпискуНакладной.[К-во] FROM НаВыпискуНакладной;)

Примечание: так как данное поле имеет источник строк SQL - запрос по временной таблице, то отображение изменений для данного поля происходит после обновления данных в форме (DoCmd Refresh).

8) «Список69» - список.
Назначение: свободное поле для отображения заказов входящих в акты (на установку, информационные услуги).

Заполнение: по SQL - запросу.

Источник строк: SQL - запрос по таблице «НаВыпискуАктовИПС1».

(SELECT DISTINCTROW НаВыпискуАктовИПС1.Код, НаВыпискуАктовИПС1.Наименование FROM НаВыпискуАктовИПС1;)

Примечание: так как данное поле имеет источник строк SQL - запрос по временной таблице, то отображение изменений для данного поля происходит после обновления данных в форме (DoCmd Refresh).

9) «КодСчета» - скрытое поле.

Назначение: главное связующее поле для форм Подчиненная1 и Подчиненная1.1.

Заполнение: автоматически .

Источник записей: аналогичное поле в исходной таблице.

Примечание: не удалять.

г) Кнопки. (для кнопок процедуры обработки событий вызываются по событию «Нажатие кнопки»)

1) «Кнопка59», «Кнопка60», «Кнопка61», «Кнопка62».

Назначение: для перехода по записям для текущей формы (заказы для данного счета). Реализация с помощью мастера.

Примечания: *

2) «КнопкаНЗ» (Добавить >).

Назначение: занесение информации для данного заказа счета во временную таблицу «НаВыпискуСчета» и «НаВыпискуНакладной» с проверкой на наличие правильности заполнения критических значений полей, обновление содержимого формы, с целью отображения последних изменений (в списке «СистемыНаВыписку» и «Список63») и переход на следующую запись в текущей форме (для ввода в накладную и в счет-фактуру следующего заказа счета). Процедура обработки событий (листинг 3.46).

Примечания: - .

3) «Кнопка68» (Добавить в акт >).

Назначение: занесение информации для данного заказа счета во временную таблицу «НаВыпискуАктов» с проверкой на наличие правильности заполнения критических значений полей, обновление содержимого формы, с целью отображения последних изменений (в списке «Список69») и переход на следующую запись в текущей форме (для ввода в акт следующего заказа счета). Процедура обработки событий (листинг 3.47).

Примечания: - .

4) «Кнопка70».

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

Примечания: - .

5) «Кнопка74».

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

Примечания: - .

6) «Кнопка66».

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

Примечания: - .

7) «Кнопка65».

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

Примечания: - .

6) «Кнопка71».

Назначение: для удаления выделенной записи в списке «Список69» из временной таблицы «НаВыпискуАктовИПС1» с проверкой на наличие выделенной записи, обновление содержимого формы, с целью отображения последних изменений (в списке «Список69»). Процедура обработки событий (листинг 3.52).

Примечания: - .

6) «Кнопка73».

Назначение: для удаления всех записей в списке «Список69» из временной таблицы «НаВыпискуАктовИПС1» с проверкой на наличие выделенной записи, обновление содержимого формы, с целью отображения последних изменений (в списке «Список69»). Процедура обработки событий (листинг 3.53).

Примечания: - .

Форма «ДругиеПлатежки» - ленточная форма.

а) Поля - аналогичны форме «Платежи»

5. Оформление счетов-фактур на сопровождение по авансовым остаткам с 1996 года

Для реализации данного этапа была разработана структура взаимодействия двух форм:

1. «ОформлениеСчетовФактур» - основная

(источник записей таблица «Заказчики»).

2. «ОформСчетовФактурSubSub» - подчиненная1 (к основной)

(источник записей таблица «СчетаФактуры»).

Форма «ОформлениеСчетовФактур».

Данная форма является модификацией формы «ОсновнаяОформлениеСчетов», поэтому в данном разделе описываются расхождения с вышеназванной формой.

а) Поля - аналогичны

б) Группы.

1) «Группа 168» (Организация - Счет-фактура).

Назначение: для перехода между информацией о счете-фактуре и адресными реквизитами для текущей организации. Процедура обработки событий (листинг 3.54)

Примечания: задание свойству «Visible» значения True или False в зависимости от положения переключателя.

в) Кнопки - аналогичны

Форма «ОформлениеСчетовФактур».

а) Поля

1) «КодСистемы».

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

Заполнение: выбор из списка.

Источник записей: список значений.

2) «Код» (Месяц).

Назначение: для выбора и отображения месяца за (по) который оказаны вышеназванные услуги.

Заполнение: выбор из списка.

Источник записей: аналогичное поле в исходной таблице.

3) «КодДатаСчетаФактуры» (Дата счета-фактуры).

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

Заполнение: выбор из списка.

Источник записей: аналогичное поле в исходной таблице.

4) «НомерСчетаФактуры» (№ счета-фактуры).

Назначение: для ввода и отображения номера выписываемого счета-фактуры (согласно существующей номенклатуре).

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

5) «Количество».

Назначение: для ввода и отображения количества месяцев, на которые оформляется счет-фактура.

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

6) «Цена».

Назначение: для ввода и отображения стоимости услуг за вышеуказанное количество месяцев, на которые оформляется счет-фактура.

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

7) «НомерПлатежки».

Назначение: для ввода и отображения номера платежного поручения, по которому оплачены вышеуказанные услуги.

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

8) «ДатаПлатежки».

Назначение: для ввода и отображения даты платежного поручения, по которому оплачены вышеуказанные услуги.

Заполнение: ввод с клавиатуры.

Источник записей: аналогичное поле в исходной таблице.

9) «СистемыНаВыписку» - список.
Назначение: свободное список для отображения перечня заказов входящих в счет-фактуру.

Заполнение: по SQL - запросу.

Источник строк: SQL - запрос по таблице «НаВыпискуСчета».

(SELECT DISTINCTROW [НаВыпискуСчета].[Код], [НаВыпискуСчета].[Система], [НаВыпискуСчета].[Количество] FROM [НаВыпискуСчета];)

Примечание: так как данное поле имеет источник строк SQL - запрос по временной таблице, то отображение изменений для данного поля происходит после обновления данных в форме (DoCmd Refresh).

б) Кнопки. (для кнопок процедуры обработки событий вызываются по событию «Нажатие кнопки»)

1) «Кнопка63» (Добавить новую >- при выписке в счете нового заказа).

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

Примечания: - .

2) «Кнопка69» (Добавить >).

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

Примечания: - .

3) «Кнопка71», «Кнопка72», «Кнопка73», «Кнопка75».

Назначение: для перехода по записям для текущей формы (счета -фактуры для данной организации). Реализация с помощью мастера.

4) «Кнопка70».

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

Примечания: - .

5) «Кнопка74».

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

Примечания: - .

6. Ввод прейскурантов на сопровождение и на системы.

В соответствии со структурой распределения цен на системы по регионам была разработана структура взаимодействия пяти форм:

1. «Прейскурант» - основная. (свободная форма)

2. «ПрейскурантОС» - подчиненная1 (к основной)

(источник записей таблица «ПрейскурантОС»).

3. «ПрейскурантОП» - подчиненная2 (к основной)

(источник записей таблица «ПрейскурантОП»).

4. «Прейскурант_Север» - подчиненная3 (к основной)

(источник записей таблица «Прейскурант_Север»).

5. «Прейскурант_Россия» - подчиненная4 (к основной)

(источник записей таблица «Прейскурант_Россия»).

Форма «Прейскурант».

а) Кнопки

1) «Кнопка119»(Отдел продаж).

Назначение: для вывода на экран формы Подчиненная1 и скрытия форм Подчиненная2,3,4, замена подписи надписи «Регион» и надписи «Регион1» на ’ Отдел продаж ’. Процедура обработки событий (листинг 3.59).

Примечания: - .

2) «Кнопка117»(Отдел сопровождения).

Назначение: для вывода на экран формы Подчиненная2 и скрытия форм Подчиненная1,3,4, замена подписи надписи «Регион» и надписи «Регион1» на ’ Отдел сопровождения’. Процедура обработки событий (листинг 3.60).

Примечания: - .

3) «Кнопка118»(По России).

Назначение: для вывода на экран формы Подчиненная3 и скрытия форм Подчиненная1,2,4, замена подписи надписи «Регион» и надписи «Регион1» на ’ Исключая Москву и Московскую область’. Процедура обработки событий (листинг 3.61).

Примечания: - .

4) «Кнопка120»( и др.).

Назначение: для вывода на экран формы Подчиненная4 и скрытия форм Подчиненная1,2,3, замена подписи надписи «Регион» и надписи «Регион1» на ’ Для отдаленных и северных районов’. Процедура обработки событий (листинг 3.62).

Примечания: - .

5) «КнопкаВыход».

Назначение: закрытие текущей формы.

Примечания: реализация с помощью мастера.

Формы «ПрейскурантОС», «ПрейскурантОП», «Прейскурант_Север», «Прейскурант_Россия» являются однотипными простыми формами для ввода информации о ценах систем для разных регионов. Все поля в формах имеют источниками данных аналогичные поля в исходных таблицах для форм. Во всех формах присутствуют кнопки для навигации по записям (переход на новую, следующую и предыдущую записи)

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

1. «ЦенаСистем» - основная. (свободная форма)

2. «ЦенаСистемМосква» - подчиненная1 (к основной)

(источник записей таблица «ЦенаСистемМосква»).

3. «ЦенаСистемРоссия» - подчиненная2 (к основной)

(источник записей таблица «ЦенаСистемРоссия»).

4. «ЦенаСистемСевер» - подчиненная3 (к основной)

(источник записей таблица «ЦенаСистемСевер»).

Форма «Прейскурант».

а) Кнопки

1) «Москва».

Назначение: для вывода на экран формы Подчиненная1 и скрытия форм Подчиненная2,3, замена подписи надписи «Регион» и надписи «Регион1» на ’ Москва и московская область’. Процедура обработки событий (листинг 3.63).

Примечания: - .

2) «Россия».

Назначение: для вывода на экран формы Подчиненная2 и скрытия форм Подчиненная1,3, замена подписи надписи «Регион» и надписи «Регион1» на ’ Исключая Москву и Московскую область’. Процедура обработки событий (листинг 3.64).

Примечания: - .

3) «ИТД»( и др.).

Назначение: для вывода на экран формы Подчиненная3 и скрытия форм Подчиненная1,2, замена подписи надписи «Регион» и надписи «Регион1» на ’ Для отдаленных и северных районов’. Процедура обработки событий (листинг 3.65).

Примечания: - .

4) «КнопкаВыход».

Назначение: закрытие текущей формы.

Примечания: реализация с помощью мастера.

Формы «ЦенаСистемМосква», «ЦенаСистемРоссия», «ЦенаСистемСевер»

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

7. Ввод и изменение адресных и банковских реквизитов организаций.

Форма «НовыеЗаказчики»

а) Поля

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

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

1) «Образец»

Назначение: свободное поле для ввода текстовой и цифровой информации использующейся для поиска по названию организации в процедуре обработки события кнопки «Кнопка56»(Найти).

Вводимое значение: текстовое или цифровое.

2) «Список57»(Список) - скрытое поле

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

Источник записей: SQL - запрос по таблице «Заказчики».

Примечания: сформирован с помощью мастера.

б) Кнопки

1) «Кнопка50».

Назначение: для вывода на экран диалогового окна «СтатусЗаказчика», для ввода нового типа статуса организации (см пункт __ ).

Примечания: реализация с помощью мастера.

2) «Кнопка43».

Назначение: переход на новую запись для данной формы (ввод новой организации).

Примечания: реализация с помощью мастера.

3) «Кнопка44», «Кнопка45», «Кнопка46», «Кнопка47»

Назначение: переход по записям данной формы (первая, предыдущая, следующая и последняя записи).

Примечания: реализация с помощью мастера.

4) «Кнопка_Закрыть»

Назначение: закрытие данной формы.

Примечания: реализация с помощью мастера.

5) «Кнопка56»(Найти).

Назначение: для поиска и вывода информации по организации по текстовому образцу введенному в поле «Образец». Процедура обработки событий (листинг 3.66).

Примечания: - .

8. Изменение данных по авансовому отчету (корректировка распределения сумм по месяцам для организаций).

Для реализации данного этапа была разработана структура взаимодействия трех форм:

1. «ИзменитьАвансОтчет» - основная

(источник записей таблица «Заказчики»).

2. «SubИзменениеАавнсОтчета» - подчиненная1 (к основной)

(источник записей временная таблица «Изменение АвансОтчета»).

3. «ИзменАавнсОтчТАБЛ» - вспомогательная

(источник записей таблица «АвансовыйОтчет»).

Форма «ИзменитьАвансОтчет»

а) Поля

1) «Образец»

Назначение: свободное поле для ввода текстовой и цифровой информации использующейся для поиска по названию организации в процедуре обработки события кнопки «Кнопка24»(Найти).

Вводимое значение: текстовое или цифровое.

2) «Организация»

Назначение: для отображения названия текущей организации.

Источник записей: аналогичное поле в исходной таблице.

3) «Список13» - список.

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

Источник записей: SQL - запрос по таблице «Заказчики».

Примечания: сформирован с помощью мастера.

б) Кнопки

1) «Кнопка24»(Найти).

Назначение: для поиска и вывода информации по организации по текстовому образцу введенному в поле «Образец». Процедура обработки событий (листинг 3.67).

Примечания:.

2) «КнопкаЗакрытьФорму» (Настройки счета).

Назначение: для закрытия текущей формы.

Примечания: реализация с помощью мастера.

Форма «SubИзменениеАавнсОтчета» - ленточная форма

а) Поля

1) «ПоСчету»

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

Источник записей: аналогичное поле в исходной таблице.

2) «КодСистемы»

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

Источник записей: аналогичное поле в исходной таблице.

3) «ДатаНМС» - скрытое поле

Назначение: для хранения даты начального месяца сопровождения по данному счету.

Источник записей: аналогичное поле в исходной таблице.

4) «Поле2» - скрытое поле

Назначение: для хранения даты последнего месяца сопровождения по данному счету.

Источник записей: аналогичное поле в исходной таблице.

5) «ИдентКод» - скрытое поле

Назначение: для хранения уникального кода записи в авансовом отчете. Значение используется, как значение фильтра при вызове диалогового окна «ИзменАавнсОтчТАБЛ».

Источник записей: аналогичное поле в исходной таблице.

6) «Поле4»

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

Источник записей: =Format([ДатаHMC];"mmmm yyyy").

7) «ДатаПМС»

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

Источник записей: =Format([Поле2];"mmmm yyyy")

б) Кнопки

1) «Кнопка14» (...).

Назначение: для вызова диалогового окна «ИзменАавнсОтчТАБЛ», с применением фильтра по соответствующему значению в поле «ИдентКод» (листинг 3.68).

Примечания: реализация с помощью мастера.

Форма «ИзменАавнсОтчТАБЛ» - ленточная форма

а) Поля

1) «Месяц»

Назначение: для отображения месяца авансового отчета.

Источник записей: аналогичное поле в исходной таблице.

2) «Сумма»

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

Источник записей: аналогичное поле в исходной таблице.

3) «ИдентКод» - скрытое поле

Назначение: для хранения уникального кода записи по авансовому отчету. Значение по которому используется фильтр при вызове диалогового окна «ИзменАавнсОтчТАБЛ».

Источник записей: аналогичное поле в исходной таблице.

б) Кнопки

1) «Кнопка8» (Выход).

Назначение: для закрытия текущей формы.

Примечания: реализация с помощью мастера.

Комментарии.

Описанная структура имеет следующие особенности работы

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

(листинг 3.69).

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

Для реализации данного этапа была разработана структура взаимодействия трех форм:

1. «ИнфПоОрганизациям» - основная

(источник записей таблица «Заказчики»).

2. «ИнфоПоОрганСистемы» - подчиненная1 (к основной)

(источник записей временная таблица «ИнфоПоСистемамЗаказчика»).

3. «ИнфоПоОрганSub» - подчиненная2 (к основной)

(источник записей временная таблица «ИнфоПоСистемамЗаказчика»).

Форма «ИнфПоОрганизациям»

а) Поля

1) «Образец»

Назначение: свободное поле для ввода текстовой и цифровой информации использующейся для поиска по названию организации в процедуре обработки события кнопки «Кнопка24»(Найти).

Вводимое значение: текстовое или цифровое.

2) «Список13» - список.

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

Источник записей: SQL - запрос по таблице «Заказчики».

Примечания: сформирован с помощью мастера.

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

б) Кнопки

1) «Кнопка24»(Найти).

Назначение: для поиска и вывода информации по организации по текстовому образцу введенному в поле «Образец». Процедура обработки событий (листинг 3.70).

Примечания:.

2) «Кнопка57» (Обновить) - необходимость?.

Назначение: для обновления данных для текущей формы. Процедура обработки событий (листинг 3.71).

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

3) «Кнопка26» (Адрес, реквизиты).

Назначение: для вывода на экран адресных и банковских реквизитов организации (листинг 3.72).

Примечания: задание свойству Visible форм Подчиненная1 и Подчиненная2 значения False.

4) «Кнопка28» (Счета).

Назначение: для вывода на экран информации по счетам выписанным для текущей организации. (листинг 3.73).

Примечания: заполнение временной таблицы «ИнфоПоСистемамЗаказчика», задание свойству Visible формы Подчиненная1 значения True и Подчиненная2 значения False.

5) «Кнопка27» (Системы).

Назначение: для вывода на экран информации по системам для текущей организации. (листинг 3.74).

Примечания: заполнение временной таблицы «ИнфоПоСистемамЗаказчика», задание свойству Visible формы Подчиненная1 значения False и Подчиненная2 значения True.

6) «Кнопка25» (Выход).

Назначение: для закрытия текущей формы.

Примечания: реализация с помощью мастера.

Форма «ИнфоПоОрганСистемы» - ленточная форма

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

Форма «ИнфоПоОрганSub» - ленточная форма

а) Поля

1) «Поле4»

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

Источник записей: =Format([Поле20];"mmmm yyyy").

2) «ДатаПМС»

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

Источник записей: =Format([Поле2];"mmmm yyyy").

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

10. Обмен сообщениями между пользователями (в дальнейшем возможно использование для заказа счетов актов и так далее? ).

Форма «Сообщения»

а) Поля

1) «username» (Кому) - поле со списком

Назначение: для выбора имени пользователя, которому должно быть отправлено сообщение.

Источник строк: SQL - запрос.

Заполнение: по SQL - запросу.

(SELECT DISTINCTROW [usersTable].[Код], [usersTable].[user] FROM [usersTable];)

Примечания:

2) «messageText» (Текст сообщения)

Назначение: для ввода текста сообщения.

Заполнение: ввод с клавиатуры.

б) Кнопки

1) «Кнопка8» (Послать сообщение).

Назначение: для отсылки сообщения. Процедура обработки событий (листинг 3.75).

Примечания: заполнение временной таблицы «flagsTable».

2) «Кнопка28» (Выход).

Назначение: для закрытия текущей формы.

Примечания: реализация с помощью мастера.

Форма «HiddenFormForCheck»

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

Комментарии.

Описанная структура имеет следующие особенности работы

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

(листинг 3.76).

11. Инициализация глобальных переменных НдсДляСчета и ВалДляСчета.

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

Форма «ТипСчета» и «ТипСчета1»

а) Группы

1). «Группа0»

Назначение: для задание, по событию «После обновления» в процедуре обработке событий, глобальной переменной НдсДляСчета значения True или False в зависимости от положения переключателей. (листинг 3.77).

2). «Группа11»

Назначение: для задание, по событию «После обновления» в процедуре обработке событий, глобальной переменной ВалДляСчета значения True или False в зависимости от положения переключателей. (листинг 3.78).

Заключение. Оценка качества программного обеспечения.

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

Боэм, Браун и Лайпоу занимались проблемой вычисления единой обобщающей меры качества и пришли к выводу, что это невозможно, так как входит в противоречие с частными характеристиками качества. Руководство должно принять решение об относительной важности следующих характеристик:

1) своевременное выполнение;

2) эффективность использования таких ресурсов, как:

а) процессоры;

б) память;

в) периферийные устройства;

3) аспекты обслуживания программы, такие как:

а) понимаемость;

б) модифицируемость;

в) удобство переноса с ЭВМ на ЭВМ.

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

Метрики Боэма, Брауна и Лайпоу.

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

1. Как хорошо (просто, надежно, эффективно) могу я использовать данный пакет в том виде, как он есть?

2. Насколько просто его обслуживать (разобраться в нем, модифицировать, перепроверить)?

3. Могу ли я пользоваться этим пакетом, если сменю оборудование (удобство переноса)?

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

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

Метрики программного обеспечения Джилба.

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

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

Отношение количества правильных данных ко всем данным приводится Джилбом в качестве меры точности (свободы от ошибок). Так же, как Боэм, Браун и Лайпоу, Джилб считает, что точность необходима для надежности программы. Прецизионность определяется как мера того, насколько часты ошибки, обусловленные одинаковыми причинами. Джилб оценивает ее дробью, в числителе которой стоит число фактических ошибок на входе, а в знаменателе - общее число наблюденных ошибок, причинами которых явились эти ошибки на входе. Так, например, если одна ошибка вызывает в течение определенного периода времени 100 сообщений об ошибках, то прецизионность равна 0.01.

Второй большой категорией, введенной Джилбом, является гибкость, в которую входят:

1) логическая сложность;

2) внутренняя гибкость;

3) открытость (адаптируемость);

4) толерантность (к изменениям входа системы);

5) универсальность;

6) удобство переноса;

7) совместимость.

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

Кроме этих, Джилб приводит еще большое количество иных метрик, но это длинное перечисление скорее будит воображение, чем приносит пользу. Работа Джилба демонстрирует новые возможности, однако реальное применение этих идей на практике дает обескураживающие результаты. Большинство характеристик очень трудно получить; сбивает с толку и то, что оценки сильно связаны, что затрудняет программисту предсказание влияния изменения программы на некоторую группу характеристик.

Оценка сложности Маккейба.

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

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

Согласно его подходу вычисляется и контролируется число путей в программе. В математические предпосылки входит определение цикломатического числа V(G) для графа с n вершинами, e ребрами и p компонентами связности:

V(G) = e - n + p

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

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

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

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

Понимаемость.

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

Авторы работы "Predicting Software Comprehensibility" экспериментировали с 36 профессиональными программистами, предложив им по 25 минут изучать 3 программы, а затем восстановить их за 20 минут. Были использованы 3 класса задач (инженерные, статические и не численные) и 3 типа структурирования (полное, частичное и неструктурированные программы). Было также введено 3 уровня мнемоничности имен переменных.

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

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

Выводы.

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

Список литературы к специальной части.

1. Р.Ахаян и др. «Эффективная работа с СУБД», Санкт-Петербург, «Питер», 1997г.

2. «Проектирование и разработка систем автоматизации предприятий».

3. «Database Unleashed», Indianapolis USA, «SAMS Publishing», 1996г.

4. Боуман Джудит, Эмерсон Сандра, Дарновски Марси. «Практическое руководство по SQL. 3-е издание». Пер с англ. – Киев, Диалектика. 1997.

5. Дейт, К. «Введение в системы баз данных».-М.:Наука, Диалектика. 1980.

6. Мартин, Дж. «Организация баз данных в вычислительных системах».-М.:Наука, Диалектика. 1980.

7. ANSI SQL Standart. The 1992 ISO-ANSI SQL standart is available through ANSI as document X3.135-1992 and through ISO as document ISO/EC 9075:1992.

8. Кодд, Е.Ф. «Реляционная модель данных». Пер с англ. – Киев, Диалектика. 1996.

9. Ипстейн, Роберт. «Реляционная производительность: Понимание производительности реляционных баз данных». Пер с англ. – Киев, Диалектика. 1996.

10. Ross, Ronald G. «Entity Modeling: Techniques and Application». Boston: Database Research Group, Inc. 1995.

11. Гайн, Крисс. «Введение в SQL» .-М.:Наука, Диалектика. 1980.

12. Праг, Керри Н. и др. «Секреты Access 97» Пер с англ. – Киев, Диалектика. 1997.

13. Кент, Вилиам. «Введение в пять нормальных форм в теории реляционных баз данных». Пер с англ. – Киев, Диалектика. 1996.

14. Ларcон, Брюс. «Руководство по экспертным базам данных». Пер с англ. – Киев, Диалектика. 1996.

15. Date C.J. «An Introduction to Database Systems» Volume 1, Reading, Mass.: Addison-Wesley Publishing Company, 1989.

16. Date C.J. «An Introduction to Database Systems» Volume 2, 2-th edition. Reading, Mass.: Addison-Wesley Publishing Company, 1989.

17. Перкинсон, Р.С. «Анализ данных: Ключ к проектированию баз данных». Пер с англ. – Киев, Диалектика. 1996.

18. Microsoft Corporation. «Описание Transact-SQL» .-М.:Наука, Диалектика. 1980.

Приложение А

Листинг программ

1) Преобразование числового денежного номера в строчное выражение

Public Function NewNumber(nnn As Double) As String

Dim numb(21) As String

Dim numb1(11) As String

Dim numb2(11) As String

Dim mil, tus, ed As Long

Dim sot, des, ed1 As Integer

Dim strval, strkop As String

Dim kop As Integer

Dim str1, str2 As String

Dim numstr As Integer

If (nnn > 999999999) Then

MsgBox ("Слишком большое число!")

Exit Function

End If

'

nnn = CDbl(Format(nnn, "Currency"))

If GetStrAfterSign(CStr(nnn) & "0") = "" Then

NewNumber = "00 копеек"

Exit Function

End If

kop = CInt(Left(GetStrAfterSign(CStr(nnn) & "0"), 2))

nnn = kop

numb(0) = " один"

numb(1) = " двe"

numb(2) = " три"

numb(3) = " четыре"

numb(4) = " пять"

numb(5) = " шесть"

numb(6) = " семь"

numb(7) = " восемь"

numb(8) = " девять"

numb(9) = " десять"

numb(10) = " одиннадцать"

numb(11) = " двенадцать"

numb(12) = " тринадцать"

numb(13) = " четырнадцать"

numb(14) = " пятнадцать"

numb(15) = " шестнадцать"

numb(16) = " семнадцать"

numb(17) = " восемнадцать"

numb(18) = " девятнадцать"

numb1(0) = " двадцать"

numb1(1) = " тридцать"

numb1(2) = " сорок"

numb1(3) = " пятьдесят"

numb1(4) = " шестьдесят"

numb1(5) = " семьдесят"

numb1(6) = " восемьдесят"

numb1(7) = " девяносто"

numb2(0) = " сто"

numb2(1) = " двести"

numb2(2) = " триста"

numb2(3) = " четыреста"

numb2(4) = " пятьсот"

numb2(5) = " шестьсот"

numb2(6) = " семьсот"

numb2(7) = " восемьсот"

numb2(8) = " девятьсот"

numb(19) = " одна"

numb(20) = " две"

mil = nnn \ 1000000

tus = (nnn - mil * 1000000) \ 1000

ed = nnn - mil * 1000000 - tus * 1000

If (mil <> 0) Then

sot = mil \ 100

des = (mil - sot * 100) \ 10

ed1 = mil - sot * 100 - des * 10

If (sot > 0) Then

strval = strval & numb2(sot - 1)

End If

If (des > 0) Then

If (des = 1) Then

strval = strval & numb(des * 10 + ed1 - 1) & " миллионов"

GoTo nex

Else

strval = strval & numb1(des - 2)

End If

End If

If (ed1 = 0) Then

strval = strval & " миллионов"

ElseIf (ed1 = 1) Then

strval = strval & " один миллион"

ElseIf (ed1 > 1 And ed1 < 5) Then

strval = strval & numb(ed1 - 1) & " миллиона"

Else

strval = strval & numb(ed1 - 1) & " миллионов"

End If

End If

nex:

If (tus <> 0) Then

sot = tus \ 100

des = (tus - sot * 100) \ 10

ed1 = tus - sot * 100 - des * 10

If (sot > 0) Then

strval = strval & numb2(sot - 1)

End If

If (des > 0) Then

If (des = 1) Then

strval = strval & numb(des * 10 + ed1 - 1) & " тысяч"

GoTo nex1

Else

strval = strval & numb1(des - 2)

End If

End If

If (ed1 = 0) Then

strval = strval & " тысяч"

ElseIf (ed1 = 1) Then

strval = strval & " одна тысяча"

ElseIf (ed1 = 2) Then

strval = strval & " две тысячи"

ElseIf (ed1 > 2 And ed1 < 5) Then

strval = strval & numb(ed1 - 1) & " тысячи"

Else

strval = strval & numb(ed1 - 1) & " тысяч"

End If

End If

nex1:

If (ed <> 0) Then

sot = ed \ 100

des = (ed - sot * 100) \ 10

ed1 = ed - sot * 100 - des * 10

If (sot > 0) Then

strval = strval & numb2(sot - 1)

End If

If (des > 0) Then

If (des = 1) Then

strval = strval & numb(des * 10 + ed1 - 1) & " копеек"

GoTo nex2

Else

strval = strval & numb1(des - 2)

End If

End If

If (ed1 = 0) Then

strval = strval & " копеек"

ElseIf (ed1 = 1) Then

strval = strval & " одна копейка"

ElseIf (ed1 > 1 And ed1 < 5) Then

strval = strval & numb(ed1 - 1) & " копейки"

Else

strval = strval & numb(ed1 - 1) & " копеек"

End If

Else

strval = strval & " копеек"

End If

nex2:

strval = LTrim(strval)

NewNumber = strval

End Function

2) Занесение денежных средств по счету на авансовый остаток.

Sub Кнопка347_Click()

On Error GoTo Err_Кнопка347_Click

Dim dbs As Database

Dim rst, rstПоCчету, rstПоАО As Recordset

Dim rstПоДате As Recordset

Dim strSQL As String

Dim i, j As Integer

Dim Цена, ЦенаП, Сопровождение, Сумма As Double

Dim Дата As Date

Dim ДатаTMP As Date

Dim ДатаПМС As Date

Dim ДатаTMP2 As Date

Dim ДАТАПМП As Date

Dim flagДата As Boolean

Dim flagБольше As Boolean

Dim flagГолоеСопр As Boolean

Dim Разница As Currency

Dim sing As String

'Dim ЦенаП_Р, Сумма_Р As Currency

flagБольше = False

Set dbs = CurrentDb

Me.Refresh

sing = Chr(34)

Set dbs = CurrentDb

strSQL = "SELECT DISTINCTROW ОсновныеСчета.НомерСчета, Дистрибутивы.Цена AS Цена, Дистрибутивы.Сопровождение AS Сопровождение FROM [ОсновныеСчета] INNER JOIN Дистрибутивы ON ОсновныеСчета.КодСчета = Дистрибутивы.КодСчета WHERE (((ОсновныеСчета.НомерСчета)=" & sing & Forms![Просмотр]![ОсновныеСчета].Form![НомерСчета] & sing & "));"

Set rst = dbs.OpenRecordset(strSQL)

If Forms![Просмотр]![ОсновныеСчета].Form![ВнесениеВАО] = True And Разница = 0 Then

Msg = "Суммы по счету уже внесены в авансовый отчет." ' Сообщение.

Style = vbOKCancel + vbQuestion ' Кнопки.

Title = "Сообщение" ' Заголовок.

Response = MsgBox(Msg, Style, Title) ' Выводит сообщение.

If Response = vbOK Then ' Если нажата кнопка "Да" (Yes).

GoTo labelBegin

Else

Exit Sub

End If

End If

labelBegin:

Цена = 0

Сопровождение = 0

rst.MoveLast

j = rst.RecordCount

rst.MoveFirst

For i = 1 To j

Цена = rst![Цена] * 1.2 + Цена

Сопровождение = rst![Сопровождение] * 1.2 + Сопровождение

rst.MoveNext

Next i

Сумма = Цена + Сопровождение

Forms![Просмотр]![ОсновныеСчета].Form![ПоСчету] = Сумма

rst.Close

strSQL = "SELECT DISTINCTROW ОсновныеСчета.НомерСчета, Платежки.СуммаПрихода As Цена, Платежки.ДатаВыписки As Дата FROM [ОсновныеСчета] INNER JOIN Платежки ON ОсновныеСчета.КодСчета = Платежки.КодСчета WHERE (((ОсновныеСчета.НомерСчета)=" & sing & Forms![Просмотр]![ОсновныеСчета].Form![НомерСчета] & sing & "));"

Set rst = dbs.OpenRecordset(strSQL)

rst.MoveLast

Дата = rst![Дата]

j = rst.RecordCount

rst.MoveFirst

For i = 1 To j

ЦенаП = rst![Цена] + ЦенаП

rst.MoveNext

Next i

Forms![Просмотр]![ОсновныеСчета].Form![ПоПлатежке] = ЦенаП

rst.Close

If ЦенаП < Сумма Then

Msg = "Cумма по счету" & Chr(13) & " - " & Сумма & "р." & Chr(13) & "Cуммы по платежкам " & Chr(13) & " - " & ЦенаП & "р." & Chr(13) & "Cуммы по платежкам меньше суммы по счета." ' Сообщение.

'Msg = "Cуммы по платежкам меньше суммы по счетам." & Chr(13) & "Занести в авансовый отчет?" ' Сообщение.

Style = vbCancel + vbCritical ' Кнопки.

Title = "Предупреждение" ' Заголовок.

Response = MsgBox(Msg, Style, Title) ' Выводит сообщение.

Exit Sub

End If

If ЦенаП > Сумма Then

Msg = "Cумма по счету" & Chr(13) & " - " & Сумма & "р." & Chr(13) & "Cуммы по платежкам " & Chr(13) & " - " & ЦенаП & "р." & Chr(13) & "Cуммы по платежкам больше суммы по счета." ' Сообщение.

'Msg = "Cуммы по платежкам больше суммы по счета." & Chr(13) & "Занести в авансовый отчет?" ' Сообщение.

Style = vbOKCancel + vbCritical ' Кнопки.

Title = "Предупреждение" ' Заголовок.

Response = MsgBox(Msg, Style, Title) ' Выводит сообщение.

If Response = vbOK Then ' Если нажата кнопка "Да" (Yes).

flagБольше = True

Разница = ЦенаП - Сумма

GoTo labelOK

Else

Exit Sub

End If

End If

'ЦенаП_Р = ЦенаП

'Сумма_Р = Сумма

Msg = "Cумма по счету" & Chr(13) & " - " & Сумма & "р." & Chr(13) & "Cуммы по платежкам " & Chr(13) & " - " & ЦенаП & "р." & Chr(13) & "Суммы совпадают." & Chr(13) & "Занести в авансовый отчет?" ' Сообщение.

Style = vbOKCancel + vbInformation ' Кнопки.

Title = "Сообщение" ' Заголовок.

Response = MsgBox(Msg, Style, Title) ' Выводит сообщение.

If Response = vbOK Then ' Если нажата кнопка "Да" (Yes).

Forms![Просмотр]![ОсновныеСчета].Form![Разница] = 0

GoTo labelOK

Else

Exit Sub

End If

labelOK:

Set rst = dbs.OpenRecordset("ДанныеДляАвансОтчета")

strSQL = "SELECT DISTINCTROW ОсновныеСчета.НомерСчета, Дистрибутивы.КодСистемы, Дистрибутивы.Цена, Дистрибутивы.ТолькоИПС, Дистрибутивы.Сопровождение, Дистрибутивы.КоличествоМ, Дистрибутивы.Количество FROM [ОсновныеСчета] INNER JOIN Дистрибутивы ON ОсновныеСчета.КодСчета = Дистрибутивы.КодСчета WHERE (((ОсновныеСчета.НомерСчета)=" & sing & Forms![Просмотр]![ОсновныеСчета].Form![НомерСчета] & sing & "));"

'"SELECT DISTINCTROW ОсновныеСчета.НомерСчета, Дистрибутивы.КодСистемы, Дистрибутивы.Цена, Дистрибутивы.Сопровождение, Дистрибутивы.КоличествоМ, Дистрибутивы.Количество FROM [ОсновныеСчета] INNER JOIN Дистрибутивы ON ОсновныеСчета.НомерСчета = Дистрибутивы.НомерСчета WHERE (((ОсновныеСчета.НомерСчета)=" & Forms![Просмотр]![ОсновныеСчета].Form![НомерСчета] & "));"

Set rstПоCчету = dbs.OpenRecordset(strSQL)

Set rstПоАО = dbs.OpenRecordset("АвансовыйОтчет")

rstПоCчету.MoveLast

j = rstПоCчету.RecordCount

ДатаStore = Дата

Select Case Forms![Просмотр]![ОсновныеСчета].Form![Код]

Case 1, 3

Нал = False

Case 2

Нал = True

End Select

rstПоCчету.MoveFirst

'ОСНОВНОЙ ЦИКЛ

flagДата = False

For i = 1 To j

'Проверка для вторичного ИПС

If rstПоCчету![Цена] = 0 Then

If flagДата = False Then

GoTo ДатаОпределение

End If

Дата = ДатаStore

Set dbs = CurrentDb

strSQLTMP = "SELECT DISTINCTROW ДанныеДляАвансОтчета.Код, ДанныеДляАвансОтчета.КодЗаказчика, ДанныеДляАвансОтчета.КодСистемы, ДанныеДляАвансОтчета.КоличествоМС, Max(ДанныеДляАвансОтчета.ДатаПМС) AS ДатаПМС FROM [ДанныеДляАвансОтчета] GROUP BY ДанныеДляАвансОтчета.Код, ДанныеДляАвансОтчета.КодЗаказчика, ДанныеДляАвансОтчета.КодСистемы, ДанныеДляАвансОтчета.КоличествоМС HAVING (((ДанныеДляАвансОтчета.КодЗаказчика)=" & Forms![Просмотр]![КодЗаказчика] & ") AND ((ДанныеДляАвансОтчета.КодСистемы)=" & rstПоCчету![КодСистемы] & ") AND ((ДанныеДляАвансОтчета.КоличествоМС)<>0));"

Set rstTMP2 = dbs.OpenRecordset(strSQLTMP)

If rstTMP2.RecordCount >= 1 Then

GoTo labelЕстьЗаписи

'Else

'MsgBox ("Записей Нет")

Exit Sub

End If

labelЕстьЗаписи:

rstTMP2.MoveLast

rstTMP2.Close

Дата:

ДатаTMP2 = Format(ДатаStore, "m yy")

If flagГолоеСопр = True Then 'Расписать если сопров голое

rst.AddNew

rst![КодЗаказчика] = Forms![Просмотр]![КодЗаказчика]

rst![КодСчета] = Forms![Просмотр]![ОсновныеСчета].Form![КодСчета]

rst![КодСистемы] = rstПоCчету![КодСистемы]

rst![ДатаПМС] = Format(ДатаTMP2, "m yy")

rst![КоличествоМС] = rstПоCчету![КоличествоМ]

rst![Нал] = Нал

Msg = "Заносим сопровождение " & НазваниеСистемы(rstПоCчету![КодСистемы]) & " на " & rstПоCчету![КоличествоМ] & " месяцев"

Style = vbOKCancel + vbInformation ' Кнопки.

Title = "Сообщение" ' Заголовок.

MsgBox Msg, Style, Title

rst.Update

rst.MoveLast

m = rstПоCчету![КоличествоМ]

For k = 1 To m

rstПоАО.AddNew

rstПоАО![ИдентКод] = rst![Код]

ЦенаСоп = rstПоCчету![Сопровождение] / m

rstПоАО![Сумма] = ЦенаСоп * 1.2

rstПоАО![Нал] = Нал

ДатаTMP = Format(ДатаПМС, "m yy")

rstПоАО![Месяц] = ДатаTMP

ДатаTMP = ДатаTMP + 32

ДатаПМС = ДатаTMP

rstПоАО.Update

Next k

GoTo labelnext

End If

'Сравнение с месяцем выписки

ДатаTMP2 = CDate(Format(ДатаStore, "m yy"))

If CDate(ДатаTMP2) <= CDate(ДатаПМС) Or (CDate(Format(ДатаStore, "m yy")) - CDate(Format(ДатаПМС, "m yy"))) / 100 = 1 Then

rst.AddNew

rst![КодЗаказчика] = Forms![Просмотр]![КодЗаказчика]

rst![КодСчета] = Forms![Просмотр]![ОсновныеСчета].Form![КодСчета]

rst![КодСистемы] = rstПоCчету![КодСистемы]

ДАТАПМП = Format(ДатаПМС, "m yy")

ДАТАПМП = ДАТАПМП + 32

rst![ДатаПМС] = Format(ДатаTMP2, "m yy")

rst![КоличествоМС] = rstПоCчету![КоличествоМ]

rst![Нал] = Нал

Msg = "Заносим сопровождение " & НазваниеСистемы(rstПоCчету![КодСистемы]) & " на " & rstПоCчету![КоличествоМ] & " месяцев с " & CurrentMonthWParamWSuf(ДатаTMP2)

Style = vbOKOnly + vbInformation ' Кнопки.

Title = "Сообщение" ' Заголовок.

MsgBox Msg, Style, Title

rst.Update

rst.MoveLast

m = rstПоCчету![КоличествоМ]

For k = 1 To m

rstПоАО.AddNew

rstПоАО![ИдентКод] = rst![Код]

ЦенаСоп = rstПоCчету![Сопровождение] / m

rstПоАО![Сумма] = ЦенаСоп * 1.2

rstПоАО![Нал] = Нал

ДатаTMP = Format(ДАТАПМП, "m yy")

rstПоАО![Месяц] = ДатаTMP

ДатаTMP = ДатаTMP + 32

ДАТАПМП = ДатаTMP

rstПоАО.Update

Next k

Else

РазницаДат = (CDate(Format(ДатаStore, "m yy")) - CDate(Format(ДатаПМС, "m yy"))) / 100

rst.AddNew

rst![КодЗаказчика] = Forms![Просмотр]![КодЗаказчика]

rst![КодСчета] = Forms![Просмотр]![ОсновныеСчета].Form![КодСчета]

rst![КодСистемы] = rstПоCчету![КодСистемы]

rst![ДатаПМС] = ДатаTMP2

rst![КоличествоМС] = rstПоCчету![КоличествоМ]

rst![Нал] = Нал

rst.Update

rst.MoveLast

rstПоАО.AddNew

rstПоАО![ИдентКод] = rst![Код]

ЦенаСоп = rstПоCчету![Сопровождение] / rstПоCчету![КоличествоМ]

rstПоАО![Сумма] = ЦенаСоп * 1.2 * CInt(РазницаДат)

rstПоАО![Нал] = Нал

ДатаTMP = Format(Дата, "m yy")

rstПоАО![Месяц] = ДатаTMP

ДатаTMP = ДатаTMP + 32

Дата = ДатаTMP

rstПоАО.Update

m = rstПоCчету![КоличествоМ]

For k = 1 To m - CInt(РазницаДат)

rstПоАО.AddNew

rstПоАО![ИдентКод] = rst![Код]

ЦенаСоп = rstПоCчету![Сопровождение] / m

rstПоАО![Сумма] = ЦенаСоп * 1.2

rstПоАО![Нал] = Нал

ДатаTMP = Format(Дата, "m yy")

rstПоАО![Месяц] = ДатаTMP

ДатаTMP = ДатаTMP + 32

Дата = ДатаTMP

rstПоАО.Update

Next k

End If

Else

'ДЛЯ ПЕРВИЧНОЙ ПОКУПКИ

Дата = ДатаStore

If rstПоCчету![Цена] <> 0 Then

rst.AddNew

rst![КодЗаказчика] = Forms![Просмотр]![КодЗаказчика]

rst![КодСчета] = Forms![Просмотр]![ОсновныеСчета].Form![КодСчета]

rst![КодСистемы] = rstПоCчету![КодСистемы]

rst![ДатаПМС] = Дата

rst![КоличествоМС] = 0

rst![Нал] = Нал

rst.Update

rst.MoveLast

rstПоАО.AddNew

rstПоАО![ИдентКод] = rst![Код]

rstПоАО![Сумма] = rstПоCчету![Цена] * 1.2

rstПоАО![Месяц] = Дата

rstПоАО![Нал] = Нал

Msg = "Заносим сумму реализации системы " & НазваниеСистемы(rstПоCчету![КодСистемы]) & " на " & CurrentMWParam(Дата)

Style = vbOKOnly + vbInformation ' Кнопки.

Title = "Сообщение" ' Заголовок.

MsgBox Msg, Style, Title

rstПоАО.Update

End If

If rstПоCчету![Сопровождение] <> 0 Then

rst.AddNew

rst![КодЗаказчика] = Forms![Просмотр]![КодЗаказчика]

rst![КодСчета] = Forms![Просмотр]![ОсновныеСчета].Form![КодСчета]

rst![КодСистемы] = rstПоCчету![КодСистемы]

rst![ДатаПМС] = Дата

rst![КоличествоМС] = rstПоCчету![КоличествоМ]

rst![Нал] = Нал

Msg = "Заносим сопровождение " & НазваниеСистемы(rstПоCчету![КодСистемы]) & " на " & rstПоCчету![КоличествоМ] & " месяцев с " & CurrentMonthWParamWSuf(Дата)

Style = vbOKOnly + vbInformation ' Кнопки.

Title = "Сообщение" ' Заголовок.

MsgBox Msg, Style, Title

rst.Update

rst.MoveLast

m = rstПоCчету![КоличествоМ]

For k = 1 To m

rstПоАО.AddNew

rstПоАО![ИдентКод] = rst![Код]

ЦенаСоп = rstПоCчету![Сопровождение] / m

rstПоАО![Сумма] = ЦенаСоп * 1.2

rstПоАО![Нал] = Нал

If Format(Дата, "dd") < 20 Then

ДатаTMP = Format(Дата, "m yy")

rstПоАО![Месяц] = ДатаTMP

ДатаTMP = ДатаTMP + 32

Дата = ДатаTMP

rstПоАО.Update

Else

ДатаTMP = Format(Дата + 12, "m yy")

rstПоАО![Месяц] = ДатаTMP

ДатаTMP = ДатаTMP + 32

Дата = ДатаTMP

rstПоАО.Update

End If

Next k

End If

End If

labelnext:

rstПоCчету.MoveNext

Next i

Код = rst![КодСистемы]

rst.Close

rstПоCчету.Close

rstПоАО.Close

labelEnd:

Forms![Просмотр]![ОсновныеСчета].Form![ВнесениеВАО] = True

If flagБольше = True Then

Set rst = dbs.OpenRecordset("КредитАванс")

rst.AddNew

rst.[КодЗаказчика] = Forms![Просмотр]![КодЗаказчика]

rst![+или-] = Разница

rst![КодСистемы] = Код

rst![Месяц] = Дата

rst.Update

rst.Close

End If

Exit_Кнопка347_Click:

DoCmd.OpenTable "АвансовыйОтчет"

dbs.Close

Exit Sub

Err_Кнопка347_Click:

If Err.Number = 94 Then

MsgBox ("Задайте дату платежки")

Exit Sub

End If

If Err.Number = 3021 Then

DoCmd.OpenForm "Месяц2", , , , , acDialog

ДатаTMP3 = "01." & Forms![Месяц2]![Месяц] & "." & Forms![Месяц2]![Год]

ДатаПМС = Format(ДатаTMP3, "m yy")

flagГолоеСопр = True

'ДатаTMP3 = Forms![Месяц2]![Месяц]

'ДатаПМС = Format(ДатаTMP3, "m yy")

Resume Дата

End If

If Err.Number = 424 Then

Resume labelEnd

End If

If Err.Number = 2113 Then

Resume labelBegin

End If

' Вначале, вычитаем константу, добавленную объектом, чтобы получить

' собственный код ошибки объекта.

MyError = Err.Number - vbObjectError

' Если после вычитания константы vbObjectError число по-прежнему

' попадает в диапазон 0 - 65535, то ошибка определена в объекте.

If MyError > 0 And MyError < 65535 Then

Msg = "Адресуемый объект присвоил ошибке следующий код : " _

& MyError & ". Источником ошибки является: " _

& Err.Source & ". Нажмите клавишу F1 для вывода справки."

' В противном случае ошибке соответствует код ошибки Visual Basic.

Else

Msg = "Эта ошибка (# " & Err.Number & ") имеет код ошибки Visual" & _

" Basic. Для вывода раздела справки Visual Basic нажмите" & _

" кнопку 'Справка' или клавишу F1."

End If

MsgBox Msg, , "Ошибка объекта", Err.HelpFile, Err.HelpContext

Err.Number = 0

Resume Exit_Кнопка347_Click

ДатаОпределение:

strSQLДата = "SELECT DISTINCTROW ДанныеДляАвансОтчета.КодЗаказчика, ДанныеДляАвансОтчета.КодСчета, ДанныеДляАвансОтчета.КодСистемы, ДанныеДляАвансОтчета.КоличествоМС, Max(АвансовыйОтчет.Месяц) AS Max_Месяц FROM [ДанныеДляАвансОтчета] INNER JOIN [АвансовыйОтчет] ON ДанныеДляАвансОтчета.Код = АвансовыйОтчет.ИдентКод GROUP BY ДанныеДляАвансОтчета.КодЗаказчика, ДанныеДляАвансОтчета.КодСчета, ДанныеДляАвансОтчета.КодСистемы, ДанныеДляАвансОтчета.КоличествоМС HAVING (((ДанныеДляАвансОтчета.КодЗаказчика)=" & Forms![Просмотр]![КодЗаказчика] & ") AND ((ДанныеДляАвансОтчета.КодСистемы)=" & rstПоCчету![КодСистемы] & ") AND ((ДанныеДляАвансОтчета.КоличествоМС)<>0));"

Set rstПоДате = dbs.OpenRecordset(strSQLДата)

rstПоДате.MoveLast

ДатаПМС = rstПоДате![Max_Месяц]

flagДата = True

rstПоДате.Close

GoTo Дата

End Sub

3) Просмотр информации по счетам и системам выбранного заказчика.

Private Sub Счет_Click()

Dim rst, rstTMP As Recordset

Dim dbs As Database

Dim i, j As Integer

Dim strSQL As String

Dim Дата As Date

Set dbs = CurrentDb

strSQL = "SELECT DISTINCTROW Заказчики.КодЗаказчика, ОсновныеСчета.НомерСчета, ОсновныеСчета.ОплатаСчета, ОсновныеСчета.ДатаСчета, ОсновныеСчета.СрокДействияСчета, Дистрибутивы.КодСистемы, Дистрибутивы.Код, Дистрибутивы.КоличествоМ, Дистрибутивы.Цена, Дистрибутивы.Сопровождение, Дистрибутивы.Скидки, Дистрибутивы.СкидкиС, Дистрибутивы.СпецвупыскИлиНет FROM ([Заказчики] INNER JOIN [ОсновныеСчета] ON Заказчики.КодЗаказчика = ОсновныеСчета.КодЗаказчика) INNER JOIN Дистрибутивы ON ОсновныеСчета.КодСчета = Дистрибутивы.КодСчета WHERE (((Заказчики.КодЗаказчика)=" & Me![КодЗаказчика] & "));"

Set rst = dbs.OpenRecordset(strSQL)

Set rstTMP = dbs.OpenRecordset("ИнфоПоСистемамЗаказчика")

Do Until rstTMP.EOF

rstTMP.Delete

rstTMP.MoveNext

Loop

If rst.RecordCount = 0 Then

MsgBox ("Нет счетов на данную организацию")

rstTMP.Close

rst.Close

dbs.Close

Me.Refresh

Exit Sub

End If

rst.MoveLast

j = rst.RecordCount

rst.MoveFirst

For i = 1 To j

rstTMP.AddNew

rstTMP![КодСистемы] = НазваниеСистемы(rst![КодСистемы])

rstTMP![ПоСчету] = rst![НомерСчета]

If rst![Код] = 1 Then

rstTMP![Тип] = "Локальная"

Else

rstTMP![Тип] = "Сетевая"

End If

rstTMP![ДатаС] = CurrentDateWParam(rst![ДатаСчета])

rstTMP![Цена] = rst![Цена]

rstTMP![Сопр] = rst![Сопровождение]

rstTMP![Скид] = rst![Скидки]

rstTMP![СкидС] = rst![СкидкиС]

rstTMP![ДейстПо] = rst![СрокДействияСчета]

rstTMP![Спец] = rst![СпецвупыскИлиНет]

rstTMP![Кво] = rst![КоличествоМ]

rstTMP![Оплата] = rst![ОплатаСчета]

rst.MoveNext

rstTMP.Update

Next i

Me![ИнфоПоОрганСистемы].Form.Visible = -1

Me![ИнфоПоОрганизSub].Form.Visible = 0

rstTMP.Close

rst.Close

dbs.Close

Me.Refresh

End Sub

Private Sub Сист_Click()

On Error GoTo Err_Кнопка6_Click

Dim rst, rstTMP, rstTMP2 As Recordset

Dim rstTMP3 As Recordset

Dim rstTMP4 As Recordset

Dim rstTMP5 As Recordset

Dim dbs As Database

Dim i, j As Integer

Dim strSQL, strSQLTMP, strSQLTMP3 As String

Dim strSQLTMP2 As String

Dim Дата As Date

DoCmd.Hourglass True

Set dbs = CurrentDb

strSQL = "SELECT DISTINCTROW ДанныеДляАвансОтчета.КодЗаказчика, ДанныеДляАвансОтчета.КодСистемы FROM [ДанныеДляАвансОтчета] WHERE (((ДанныеДляАвансОтчета.КодЗаказчика)=" & Me![КодЗаказчика] & ") AND ((ДанныеДляАвансОтчета.КоличествоМС)<>0));"

Set rst = dbs.OpenRecordset(strSQL)

Set rstTMP4 = dbs.OpenRecordset("ИнфоПоСистемамЗаказчика")

Do Until rstTMP4.EOF

rstTMP4.Delete

rstTMP4.MoveNext

Loop

If rst.RecordCount = 0 Then

' MsgBox ("Не сопровождается")

rst.Close

Me![ИнфоПоОрганизSub].Form.Visible = -1

Me![ИнфоПоОрганСистемы].Form.Visible = 0

'инфо по 1996 году

strSQLTMP2 = "SELECT DISTINCTROW АвансПоОстаткамС1996Года.Заказчик, АвансПоОстаткамС1996Года.Месяц, АвансПоОстаткамС1996Года.Сумма FROM АвансПоОстаткамС1996Года WHERE (((АвансПоОстаткамС1996Года.Заказчик)=" & Me![КодЗаказчика] & "));"

Set rstTMP5 = dbs.OpenRecordset(strSQLTMP2)

rstTMP4.AddNew

rstTMP5.MoveFirst

rstTMP4![Дата1С1996] = CurrentMWParam(rstTMP5![Месяц])

rstTMP5.MoveLast

rstTMP4![Дата2С1996] = rstTMP5![Месяц]

rstTMP5.Close

rstTMP4.Update

Me.Refresh

rstTMP4.Close

dbs.Close

DoCmd.Hourglass False

Exit Sub

End If

rst.MoveLast

j = rst.RecordCount

rst.MoveFirst

For i = 1 To j

rstTMP4.AddNew

rstTMP4![КодСистемы] = НазваниеСистемы(rst![КодСистемы])

strSQLTMP = "SELECT DISTINCTROW Заказчики.Организация, ДанныеДляАвансОтчета.КодСистемы, АвансовыйОтчет.Месяц, ДанныеДляАвансОтчета.КоличествоМС, Заказчики.КодЗаказчика, ДанныеДляАвансОтчета.КодСчета, ОсновныеСчета.НомерСчета AS НС, АвансовыйОтчет.ИдентКод, Дистрибутивы.СкидкиС, ОсновныеСчета.ДатаСчета"

strSQLTMP = strSQLTMP & " FROM (([ОсновныеСчета] INNER JOIN ([Заказчики] INNER JOIN [ДанныеДляАвансОтчета] ON (Заказчики.КодЗаказчика = ДанныеДляАвансОтчета.КодЗаказчика) AND (Заказчики.КодЗаказчика = ДанныеДляАвансОтчета.КодЗаказчика)) ON (Заказчики.КодЗаказчика = ОсновныеСчета.КодЗаказчика) AND (ОсновныеСчета.КодСчета = ДанныеДляАвансОтчета.КодСчета)) INNER JOIN [АвансовыйОтчет] ON ДанныеДляАвансОтчета.Код = АвансовыйОтчет.ИдентКод) INNER JOIN Дистрибутивы ON ОсновныеСчета.КодСчета = Дистрибутивы.КодСчета"

strSQLTMP = strSQLTMP & " GROUP BY Заказчики.Организация, ДанныеДляАвансОтчета.КодСистемы, АвансовыйОтчет.Месяц, ДанныеДляАвансОтчета.КоличествоМС, Заказчики.КодЗаказчика, ДанныеДляАвансОтчета.КодСчета, ОсновныеСчета.НомерСчета, АвансовыйОтчет.ИдентКод, Дистрибутивы.СкидкиС, ОсновныеСчета.ДатаСчета"

strSQLTMP = strSQLTMP & " HAVING (((ДанныеДляАвансОтчета.КодСистемы)=" & rst![КодСистемы] & ") AND ((ДанныеДляАвансОтчета.КоличествоМС)<>0) AND ((Заказчики.КодЗаказчика)=" & Me![КодЗаказчика] & "));"

Set rstTMP2 = dbs.OpenRecordset(strSQLTMP)

Дата = Format(rstTMP2![Месяц], "m yy")

rstTMP4![ДатаС] = Дата

rstTMP2.MoveLast

Дата = Format(rstTMP2![Месяц], "m yy")

rstTMP4![ДейстПо] = Дата

rstTMP4![ПоСчету] = rstTMP2![НС]

rstTMP4![ДатаСчСопр] = CurrentDateWParam(rstTMP2![ДатаСчета])

rstTMP4![СкидС] = rstTMP2![СкидкиС]

'Запрос по системам

strSQLTMP = "SELECT DISTINCTROW Заказчики.КодЗаказчика, Заказчики.Организация, ОсновныеСчета.НомерСчета, ОсновныеСчета.ДатаСчета, ОсновныеСчета.ДатаУстановки, Дистрибутивы.КодСистемы, Дистрибутивы.Код, Дистрибутивы.СпецвупыскИлиНет, Дистрибутивы.Скидки, Дистрибутивы.Цена, Дистрибутивы.НомерДистрибутива"

strSQLTMP = strSQLTMP & " FROM ([Заказчики] INNER JOIN [ОсновныеСчета] ON Заказчики.КодЗаказчика = ОсновныеСчета.КодЗаказчика) INNER JOIN Дистрибутивы ON ОсновныеСчета.КодСчета = Дистрибутивы.КодСчета"

strSQLTMP = strSQLTMP & " WHERE (((Заказчики.КодЗаказчика)=" & Me![КодЗаказчика] & ") AND ((Дистрибутивы.КодСистемы)=" & rst![КодСистемы] & ") AND ((Дистрибутивы.Цена)<>0));"

Set rstTMP3 = dbs.OpenRecordset(strSQLTMP)

rstTMP4![ПоСчетуПок] = rstTMP3![НомерСчета]

rstTMP4![ДатСчПок] = CurrentDateWParam(rstTMP3![ДатаСчета])

rstTMP4![Рег] = rstTMP3![НомерДистрибутива]

rstTMP4![Скид] = rstTMP3![Скидки]

rstTMP4![Спец] = rstTMP3![СпецвупыскИлиНет]

If rstTMP3![Код] = 1 Then

rstTMP4![Тип] = "Локальная"

Else

rstTMP4![Тип] = "Сетевая"

End If

labelnext:

strSQLTMP2 = "SELECT DISTINCTROW АвансПоОстаткамС1996Года.Заказчик, АвансПоОстаткамС1996Года.Месяц, АвансПоОстаткамС1996Года.Сумма FROM АвансПоОстаткамС1996Года WHERE (((АвансПоОстаткамС1996Года.Заказчик)=" & Me![КодЗаказчика] & "));"

Set rstTMP5 = dbs.OpenRecordset(strSQLTMP2)

If rstTMP5.RecordCount > 0 Then

rstTMP5.MoveFirst

rstTMP4![Дата1С1996] = CurrentMWParam(rstTMP5![Месяц])

rstTMP5.MoveLast

rstTMP4![Дата2С1996] = CurrentMWParam(rstTMP5![Месяц])

rstTMP5.Close

rstTMP4.Update

rst.MoveNext

rstTMP2.Close

rstTMP3.Close

Else

rstTMP5.Close

rstTMP2.Close

rstTMP3.Close

End If

Next i

rstTMP4.Close

rst.Close

dbs.Close

Me.Refresh

Exit_Кнопка6_Click:

Me.Refresh

Me![ИнфоПоОрганизSub].Form.Visible = -1

Me![ИнфоПоОрганСистемы].Form.Visible = 0

DoCmd.Hourglass False

Exit Sub

Err_Кнопка6_Click:

If Err.Number = 3021 Then

'MsgBox ("Нет данных по этой организации")

Resume labelnext:

'Resume Exit_Кнопка6_Click

'MsgBox Err.Description

End If

MsgBox ("Нет данных по этой организации")

Me![ИнфоПоОрганизSub].Form.Visible = 0

Me![ИнфоПоОрганСистемы].Form.Visible = 0

MsgBox Err.Number

Resume Exit_Кнопка6_Click

DoCmd.Hourglass False

End Sub

Задание по организационно – экономической части к дипломному проекту.

Тема: «Технико-экономическое обоснование проекта. Расчет сметы затрат и цены на ПП. Оценка конкурентоспособности разработки»

1. Календарный график.

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

N п/п	Наименование работ	Исполнители	Длительность работы
			Сент.	окт.	ноябрь	Декабрь	Январь
1	Разработка технического задания	Начальник отдела, менеджер	20
2	Подбор литературы	Системный программист, программист	15
3	Рабочее проектирование	Системный программист, программист		25
4	Отладка и тестирование	Системный программист, программист			55
5	Обобщение и оценка результатов	Системный программист, программист, менеджер					30
6	Сдача темы	Начальник отдела, менеджер					5

2. Расчет сметы.

При составлении сметы затрат на НИР учитываются:

- стоимость материалов, покупных полуфабрикатов и изделий,

- основная заработная плата,

- дополнительная заработная плата,

- отчисления на социальные нужды,

- накладные расходы,

- затраты на машинное время.

2.1. Определения затрат на материалы, покупные изделия и полуфабрикаты.

Наименование	Единица измерения	Количество	Цена за единицу, руб.	Стоимость
1. Литература	Шт.	6	60.000	360.000
2. НЖМД (дискеты)	Пачка.	4	40.000	160.000
3. Канцтовары	Шт.			50.000
4. Бумага(А4)	Пачка	3	5.000	15.000
Итого:				585.000

Транспортные расходы учитываются здесь же и состовляют 5% итоговой суммы, т.е. 29.250 р.

Затраты на материалы и покупные изделия равны:

З_м = 585.000 + 29.250 = 614.250 руб.

2.2. Основная заработная плата.

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

Должность	Заработная плата в месяц, руб.	Стоимость одного рабочего дня, руб.
Начальник отдела	2.300.000	115.000
Системный программист	1.200.000	60.000
Программист	1.000.000	50.000
Менеджер	1.900.000	95.000

Таблица расчета основной заработной платы.

N п/п	Наименование этапа НИР	Исполнитель	Трудоем-кость	Зарплата за 1 день, руб.		Сумма, руб.
1	Разработка технического задания	Начальник отдела, менеджер	20	115.000 95.000		2,300,000 1,900,000
2	Подбор литературы	Системный программист, программист	15	60.000 50.000		900,000 750,000
3	Рабочее проектирование	Системный программист, программист	25	60.000 50.000		1,500,000 1,250,000
4	Отладка и тестирование	Системный программист, программист	55	60.000 50.000		3,300,000 2,750,000
5	Обобщенеи и оценка результатов	Системный программист, программист, менеджер	30	60.000 50.000		1,800,000 1,500,000
6	Сдача темы	Начальник отдела, менеджер	5	115.000 95.000		575,000 475,000
7	Итого				19,000,000

2.3. Дополнительная заработная плата.

На эту статью относятся выплаты, предусмотренные законодательством за неотработанное рабочее время. Размер дополнительной заработной платы сотрудников, непосредственно

выполняющий НИР, определяется в процентах от основной. В научных учереждениях она составляет 10-12% от основной заработной платы.

Здоп = Зосн * 0,12 = 2,280,000 руб.

2.4. Отчисления на социальные нужды.

На эту статью относятся отчисления на оплату перерывов в работе по временной нетрудоспособности. Отчисления на социальные нужды составляют 40% от величины основной заработной платы.

В отчисления на социальные нужды входят:

• отчисления на медицинское страхование:

• в городской бюджет – 0,2%

• в федеральный бюджет – 3,4%

• отчисления в фонд занятости – 1,5%;

• отчисления в пенсионный фонд - 29%;

• отчисления на социальное страхование – 5,4%;

• транспортный налог - 1%;

• отчисления на в фонд образования – 1%;

Зсн = Зосн * 0.415 = 7,600,000 руб.

2.5. Накладные расходы.

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

Зн = (Зосн + Здоп) * 1.2 = 25,536,000 руб.

2.6. Стоимость машинного времени.

Для отладки программы, численных расчетов и построения графиков необходимо 50 дней. В среднем программист работает 6 часов в день, себестоимость одного часа машинного времени около 3000 руб.

Змаш = 3000 * 6 * 50 = 900,000 руб.

Итоговая таблица сметы затрат.

N п/п	Наименование статьи расходов	Сумма, руб.
1	Стоимость материалов, покупных полуфабрикатов и изделий.	614,250
2	Основная заработная плата.	19,000,000
3	Дополнительная заработная плата.	2,280,000
4	Отчисления на социальные нужды.	7,600,000
5	Накладные расходы.	25,536,000
6	Стоимость машинного времени.	900,000
	Итого	55,930,250

2.7. Цена программного продукта.

Цена, определяется себестоимостью и прибылью, которая в свою очередь составляет 30% от ФОТ.

Ц = 55.930.250 + 0,3 * 21,280,000 = 62,314,250 руб.

3. Оценка экономической эффективности.

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

	Частота регистраций
	Обьем памяти	Быстродействие	Аппаратная независимость	Дизайн	Сервис
Нащ программный продукт	0,81	0,93	0,85	0,87	0,89
Конкутентный программный продукт	0,62	0,84	0,86	0,78	0,81

Р
ассчитаем коэффициент конкурентоспособности.

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

Задание по охране труда и техника безопасности.

Тема: «Разработать мероприятия по охране труда на рабочем месте пользователя.»

1. Введение.

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

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

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

ром.

2. Анализ условий труда пользователя.

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

- длина помещения: 9 м;

- ширина помещения: 7 м;

- высота помещения: 3.5 м;

- число окон: 3;

- число рабочих мест: 6;

- освещение: искусственное;

- число вычислительной техники: 5.

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

- недостаточное освещение;

- шум от работающих машин;

- облучение от экрана дисплея;

- выделение избытков теплоты.

Кроме того, в помещение могут попадать частички пыли.

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

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

4. Расчет вентиляции.

4.1. Анализ микроклимата.

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

1) температурой воздуха t( C);

2) относительной влажностью (%);

3) скоростью движения воздуха на рабочем месте,V(м/с).

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

Таблица 1. Параметры микроклимата.

Период года	Категория работ	Зона	Тмпера-тура, °C	Относит. влажность, %	Скорость движения, м/с
холдн.	Легкая	оптим.	22-24	40-60	0.1
		доп.	25-18	75	<0.1
теплый	Легкая	оптим.	23-25	40-60	0.1
		доп.	28-22	55	0.1-0.2

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

4.2. Определение потребного воздухообмена.

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

W=n*w (1.)

где n - число людей, n = 6 человек;

w - количество влаги, выделяемое одним человеком, г/ч,

w = 84 г/ч при t = 22С [1].

По формуле (1.) получаем:

W = 6 * 84 = 504 (г/ч)

Теперь можно определить потребный воздухообмен, который определяется по формуле:

(2.)

где W - количество водяного пара, выделяющегося в помещении, г/ч, W = 504 г/ч;

D, d - влагосодержание вытяжного и приточного воздуха, г/кг, определяется по температуре и относительной влажности воздуха;

p - плотность приточного воздуха, р = 1.2 кг/ м;

d = 10 г/кг при температуре рабочей зоны 22 С;

D = 16 г/кг -принимается равным предельно допустимому, т.е. при tр.з.=26 С , =75 %. Таким образом расход воздуха (по формуле (2.)) равен :

Теперь проведем расчет выделений тепла.

Тепловыделения от людей зависят от тяжести работы, температуры и скорости движения окружающего воздуха. Считается, что женщина выделяет 85% тепловыделений взрослого мужчины. В расчетах используется явное тепло, т. е. тепло воздействующее на изменение температуры воздуха в помещении. Тепловыделения от людей :

Qл = n * q , (3.)

где n - количество людей в помещении, 5 мужчин и 1 женщина;

q - удельная теплота , выделяемая человеком (явное тепло при t = 22 С ), Вт ; q = 68 Вт [1];

По формуле (3.) получаем:

Qл = 5 * 68 + 1 * 0.85 * 68 = 397.80 Вт.

Расчет тепла, поступающего в помещение от солнечной радиации Qост производится по формуле:

Qост = Fост * qост * Aост , (4.)

где Fост - площадь поверхности остекления,м ,

Fост= 9 м ;

qост - тепловыделения от солнечной радиации, Вт/м, через 1 м поверхности остекления (с учетом ориентации по сторонам света), qост = 150 Вт/м [4], т.е окна с двойным остеклением с металлическими переплетами;

Aост - коэффициент учета характера остекления, Aост=1.15 (двойное остекление в одной раме).

Подставив все полученные значения в формулу (4.), получим:

Qост = 9 * 150 * 1.15 = 1552,5 Вт.

Расчет тепловыделений от источников искусственного освещения Qосв, Вт, производится по формуле:

Qосв = N * * 1000 , (5.)

где N - суммарная мощность источников освещения, кВт,

N= 2 * 6 * 0.08 = 0.960 кВт где 0.08 кВт - мощность одной лампы, а всего в помещении 6 светильников по 2 лампы в каждом;

- коэффициент тепловых потерь, = 0.55 для люминес-

центных ламп.

По формуле (5.) имеем:

Qосв = 0.96 * 0.55 * 1000 = 528 Вт.

Для расчета тепловыделений от устройств вычислительной техники используется формула (5.) с коэффициентом тепловых потерь равном = 0.5. В помещении стоят 5 компьютеров типа IBM PC AT с мощностью 63.5 Вт источника питания.Тогда :

Qвт = 5 * 0.0635 * 0.5 * 1000 = 158.75 Вт.

Таким образом, в помещении выделяется всего избыточного тепла:

Qизб = Qл + Qост + Qосв + Qвт = 2637.05 Вт.

При открытии дверей и окон естественный расход тепла:

Qрасх = 0.1 * Qизб = 263.705 (Вт). (6.)

По формуле (7.) посчитаем объем вентилируемого воздуха для теплого времени года:

(7.)

где Qизб - теплоизбытки, Qизб = 2637.05 Вт;

Ср - массовая удельная теплоемкость воздуха,

Ср = 1000 Дж/(кг* С);

р - плотность приточного воздуха, р = 1.2 кг/м ;

tуд, tпр - температуры удаляемого и приточного воздуха, С;

Температура удаляемого воздуха определяется по формуле:

tуд = tрз + а * (Н - 2),

где tрз = 22 С;

а - нарастание температуры воздуха на каждый 1 м высоты, С/м, а =0.5 С/м;

Н - высота помещения, Н = 3.5 м.

Следовательно, tуд = 22 + 0.5 * (3.5 - 2) = 23 С.

Температура приточного воздуха tпр при наличии избытков тепла должна быть на 5 С ниже температуры воздуха в рабочей зоне, поэтому tпр = 17 С. Подставив полученные значения в формулу (7.) найдем:

При одновременном выделении тепла и влаги сравниваются соответствующие воздухообмены, потребные для их удаления, и выбирается наибольший. Поскольку Gт= 1318 м /ч,а G = 70 м /ч,то систему вентиляции будем проектировать для воздухообмена Gвент = 1318.5 м /ч.

5. Проектирование системы вентиляции.

Исходными данными для расчета размера воздуховода являются расход воздуха (Gвент = 1318.5 м /ч) и допустимые скорости его движения в помещении (v = 9 м/с). Потребная площадь воздуховода f, м определяется по формуле:

(8.)

Для дальнейших расчетов (при определении сопротивления сети, подборе вентилятора и электродвигателя) площадь воздуховода принимается равной ближайшей большей стандартной величине, т. е. f = 0.0614 м [1]. В промышленных зданиях рекомендуется использовать круглые металлические воздуховоды. Тогда расчет сечения воздуховода заключается в определении диаметра трубы. По справочнику находим, что для площади f = 0.0614 м условный диаметр воздуховода d = 280 мм [1].

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

где R - удельные потери давления на трение на участке сети, R =3.2 Па/м;

l - длина участка воздуховода, м, l = 3 м;

- сумма коэффициентов местных потерь на участке воздуховода, 1.1 - для колена, 1.4 - для прямого участка; v - скорость воздуха на участке воздуховода, 9 м/с;

р - плотность воздуха( принимаем р = 1.2 кг/м ).

Значения R,v, определяются по справочнику (R - по значению диаметра воздуховода на участке d = 280 мм, в зависимости от типа местного сопротивления)[1]. Результаты расчета воздуховода и сопротивления сети приведены в табл. 2.

Таблица 2. Расчет воздуховода и сопротивления сети.

G, (м/ч)	l, (м)	v, (м/с)	d, (мм)	v*p/2 Па	R, Па/м	R*I, Па		Па	P, Па
1318	3	9	280	48.60	3.2	9.6	2.5	121.5	131.1

Требуемое давление, создаваемое вентилятором, с учетом запаса на непредвиденное сопротивление в сети в размере 10 % составит:

Ртр = 1.1 * Рmax = 1.1 * 131.1 = 144.21 (Па) (10.)

В вентиляционных установках применяют вентиляторы низкого давления (до 1 кПа) и среднего давления (от 1 до 3 кПа). В сетях с малым сопротивлением до 200 Па применяют осевые вентиляторы. Вентиляторы подбирают по аэродинамическим характеристикам, т.е. зависимостям между полным давлением (Ртр, Па), создаваемым вентилятором, и произволительностью (Gтр, м /ч).

С учетом возможных дополнительных потерь или подсоса воздуха в воздуховодах потребная производительность вентилятора увеличивается на 10 %, поэтому:

Gтр = 1.1 * Gвент = 1.1 * 1318.3 = 1450.35 (м /ч)(11)

По справочным данным [2] определяем необходимый вентилятор и электродвигатель: вентилятор О6-300 (N4), КПД вентилятора h = 0.65.

Мощность электродвигателя (N, кВт) рассчитывается по формуле:

(12.)

где h - КПД вентилятора и ременной передачи.

Выберем по рассчитанному значению мощности электродвигатель 4АА63В4У2 с мощностью 0.37 кВт.

Задание по гражданской обороне.

Тема: «Оценка устойчивости дисплейного зала к воздействию ионизирующего излучения.»

1. Введение.

Гражданская оборона (ГО) представляет собой общегосударственную систему мероприятий, осуществляющую защиту населения и народного хозяйства государства в чрезвычайных ситуациях мирного и военного времени, обеспечивающих повышение устойчивости работы отраслей экономики, проведение АСИДНР при ликвидации последствий стихийных бедствий, аварий и катастроф.

Руководство осуществляется МЧС. Рабочим органом управления комитета является штаб войск ГО и 9 региональных центров, которые находятся в Москве, Санкт-Петербурге, Ростове на Дону, Самаре, Екатеринбурге, Новороссийске, Красноярске, Чите и Хабаровске.

В целом ГО строится по территориально-производственному принципу, т.е. органы управления ГО создаются исполнительными властями по территориям (края, области) и по линии безопасности управления (министерства, ведомства).

ГО России предназначено для решения трех групп задач:

- защита населения в чрезвычайных ситуациях мирного и военного времени;

- повышение устойчивости работы отраслей экономики в чрезвычайных ситуациях;

- организация и проведение АСИДНР при ликвидации последствий чрезвычайных ситуаций.

ГО Москвы имеет, кроме того, следующие задачи:

- организация первоочередного жизнеобеспечения пострадавшего населения;

- проведение профилактических мероприятий для уменьшения риска возникновения промышленных аварий и катастроф;

- всеобщее обязательное обучение населения основам ГО;

- создания и подготовка органов управления (систем связи, оповещения, пунктов управления и т.п.).

На ГО возлагается:

- осуществление мероприятий по защите рабочих и служащих в чрезвычайных ситуациях;

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

- обеспечение непрерывного управлениями службами и формированиями ГО;

- создание, оснащение, подготовка сил ГО объектов и поддержание их в постоянной готовности;

- всеобщее обязательное обучение рабочих и служащих мерам защиты при чрезвычайных ситуациях;

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

- проведение аварийно - спасательных и других неотложных работ в очагах поражения.

К учреждениям ГО относятся:

- медицинские учреждения (больницы, поликлиники, здравпункты, диспансеры, санатории и т.п.);

- ветеринарные лаборатории и учреждения;

- химические лаборатории;

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

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

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

Распределение энергии между поражающими факторами ядерного взрыва зависит от вида взрыва и условий, в которых он происходит. При взрыве в атмосфере примерно 50% энергии взрыва расходуется на образование ударной волны, 30 - 40% - на световое излучение, до 5% - на проникающую радиацию и электромагнитный импульс и до 15% - на радиоактивное заражение.

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

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

Задача данного этапа дипломного проектирования - оценка устойчивости дисплейного зала к воздействию ионизирующего излучения. Зададимся исходными данными для задачи.

Описание дисплейного класса:

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

- дисплейный класс рассчитан на 20 ЭВМ типа Intel Pentium-100 с мониторами типа Samsung 15GA;

- дисплейный класс дополнительно имеет внутреннее покрытие из дерева рассчитанное на погашение внешних наводок и наводок от электросети.

Для проверки устойчивости дисплейного зала к воздействию ионизирующего излучения зададимся параметрами ядерного взрыва:

- мощность взрыва равна 1000 Кт;

- диапазон оцениваемых расстояний от 500 до 3500 м.

2.1. Оценка поражающих факторов проникающей радиации.

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

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

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

Время действия проникающей радиации не превышает 10-15 секунд с момента взрыва. Основными параметрами, характеризующими проникающую радиацию, является доза и мощность излучения, потоки плотность потока частиц. Ионизирующая способность гамма-излучения характеризуется экспозиционной дозой излучения.

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

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

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

Обратимые изменения в материалах, элементах и аппаратуре в целом могут возникать при мощности экспозиционных доз от 1000 Р/с.

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

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

3.2. Расчет факторов проникающей радиации.

Мощность взрыва принимаем равную 1000 Кт.

1. Мощность поглощенной дозы, [P/c].

, где - мощность взрыва, Кт.

2. Поглощенная доза излучения, [р.].

3. Поток нейтронов, [1/м].

.

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

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

Таблица 1.1.

Факторы	Радиус, м
	500	1000	1500	2000	2500	3000	3500
P, P/с	3.1108	6.7106	2.5105	1.1104	600	34	2
D, P	2.0106	9.8104	8.5103	930	120	17	3
н/м	2.01018	3.91016	1.21015	5.01013	2.31012	1.21011	6.0109

Учитывая, что наименее стойким элементом ЭВМ являются микросхемы, количество которых определяется типом ЭВМ и составляет 30 - 50 единиц, для которых предельные значения равны соответственно:

=10 н/м; D=1000 P; P=1000 P/с, получаем, что на расстоянии более 2500 метров от взрыва проникающая радиация ЯВ не повлияет на работоспособность ЭВМ. Необратимые изменения в микросхемах под воздействием проникающей радиации будут возникать, если ЭВМ будет находиться на расстоянии менее 1500 метров от центра взрыва.

4. Выводы.

В целом защита ЭВМ от воздействия проникающей радиации может быть в первую очередь достигнута за счет размещения в помещении, обеспечивающем снижение дозы проникающей радиации в 500 - 1000 раз, и использования экранов из тяжелых металлов и перекрытий из бетонных плит толщиной 1 - 1,5 м и более.

4.1. Предложения по обеспечению устойчивости дисплейного зала к воздействию ионизирующего излучения

Следовательно, надежность работы ЭВМ в условиях воздействия проникающей радиации ядерного взрыва будет повышена, если будут приняты следующие меры:

- наиболее важные узлы ЭВМ будут укрыты защитным слоем материала и перегородок, не пропускающего радиацию и тепло. Наиболее хорошо поглощают радиацию тяжелые материалы, например металлы (бетон, железные плиты и др.);

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

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

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

5. Список используемой литературы.

1. В.Г.Атаманюк, Л.Г.Ширшев, Н.И.Акимов “Гражданская оборона”, Москва, Высшая школа, 1986 г.

2. Л.Г.Ширшев “Ионизирующее излучение и электроника”, Москва, 1969 г.

3. Радиационная стойкость материалов радиотехнических конструкций, Справочник, Москва, 1976 г.

4. Методические указания к практическим работам по курсу “Гражданская оборона” под редакцией Л.Г.Ширшева, Москва, 1981г.

Задание по эргономике.

Тема: «Применение эргономики при проектировании, разработке и внедрения систем автоматизации деятельности предприятия».

1. Введение.

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

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

• художников-дизайнеров – для оформления интерфейса пользователей

• финансистов-консультантов – для более глубокого исследования бизнес-процессов предприятия

• менеджеров – для организации работы групп разработчиков систем автоматизации

• специалистов по эргономике – для исследования потребительских свойств разрабатываемой системы, а также для проектирования наиболее удобного интерфейса пользователя

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

В данной работе мы рассмотрим требования, предъявляемые специалистами по эргономики при разработке систем автоматизации предприятий.

2. Влияние эргономики при проектировании реляционной базы данных.

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

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

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

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

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

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

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

3. Влияние эргономики при создании интерфейса пользователя.

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

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

Использование графического интерфейса. При создании системы автоматизации необходимо ориентироваться на операционные системы с графическим интерфейсом пользователя (Windows, OS/2, OSMac и т.п.). Системы с текстовым вводом (например MS-DOS) являются устаревшими и не предназначены для разработки интерфейса пользователя.

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

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

Длительное ожидание выполнения каких-либо действий всегда должно сопровождается надписью (например «Идет выполнение операции. Подождите…»). Также необходимо использовать строки загрузки, которые позволяют наглядно представить какой объем информации уже обработан и какой объем еще предстоит обработать. Данные средства позволяют сгладить эффект «длительного ожидания» у пользователя.

При работе необходимо использовать строки повседневного общения. Это позволит снять напряжение от работы, а также развлечет пользователя. Например, при выходе из программы можно использовать сообщение вида «Действительно уходите? До свидания. Надеемся вы к нам еще загляните…».

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

Использование современных элементов управления. Такие элементы управления как «закладки», «деревья», «ползунки» и т.п. – помогут пользователю легко управлять даже самыми сложными данными.

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

4. Внедрение и его влияние на эргономические свойства проекта.

После окончания этапов проектирования и разработки наступает этап внедрения системы автоматизации предприятия. На данном этапе проводятся доработки пользовательского интерфейса и отладка системы. Как правило основные изменения, вносимые на данном этапе в программу касаются прежде всего эргономических свойств проекта. Этап внедрения подобен покупке новой обуви – должно пройти некоторое время для того, что бы «расходить» программу. Часто оказывается, что на этапе разработки интерфейса пользователь и разработчики неправильно поняли друг друга в результате чего на этапе внедрения приходится находить компромис. Важно понимать, что данный компромис должен устраивать пользователя и помогать ему в работе.

5. Заключение.

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

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

Список литературы.

1. Р.Ахаян и др. «Эффективная работа с СУБД», Санкт-Петербург, «Питер», 1997г.

2. «Проектирование и разработка систем автоматизации предприятий».

3. «Database Unleashed», Indianapolis USA, «SAMS Publishing», 1996г.

Содержание.

СПЕЦИАЛЬНАЯ ЧАСТЬ.

Введение.

ГЛАВА 1. «Малые предприятия и проблемы автоматизации»

1. Предприятие как центр обработки информации.

2. Особенности ведения учета и автоматизации бизнес-процессов на малом предприятии.

3. Определение и классификация систем автоматизации предприятия.

4. Складские операции и кадровый учет на малом предприятии.

5. Содержательная постановка задачи автоматизации.

ГЛАВА 2. «СУБД и Клиент-серверная модель вычислений»

2.1. Общие вопросы проектирования баз данных

2.1.1. Основные понятия теории баз данных

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

2.1.3. Основы теории проектирования баз данных

2.2. Клиент-серверная модель вычислений

2.2.1. Эволюция моделей вычисления

2.2.2. Преимущества и недостатки вычислений клиент-сервер

2.3. Сервер в системе клиент-сервер. Microsoft SQL Server

2.3.1. Базы данных и реляционные СУБД

2.3.2. Сервер баз данных Microsoft SQL Server – важнейшие особенности

2.4. Клиент в системе клиент-сервер. Microsoft Access 97

2.4.1. Клиентные приложения – окно доступа к базе данных

2.4.2. Использование СУБД MicrosoftAccess 97 в качестве клиентного приложения

2.5. Взаимодействие Access и SQL Server

2.5.1. Особенности использования Access в разнородной среде.

2.5.2. Особенности использования Microsoft SQL Server в разнородной среде.

ГЛАВА 3. «Модель учета кадров и складских запасов малого предприятия. Реализация. Анализ работы»

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

3.2. Формализованное описание механизмов складского и кадрового учета.

3.3. Особенности реализации проекта.

3.4. Анализ работы базы данных.

Заключение

Список литературы к специальной части

ОРГАНИЗАЦИОННО-ЭКОНОМИЧЕСКАЯ ЧАСТЬ

ОХРАНА ТРУДА И ЭКОЛОГИЯ

ГРАЖДАНСКАЯ ОБОРОНА

ЭРГОНОМИКА

Приложения

1. Техническое описание дипломного проекта.

2. Листинги основных программных модулей проекта.

ВВЕДЕНИЕ.

В книге Джона Нейсбитта “Мегатренды” – бестселлера, в котором рассматриваются тенденции трансформации современного общества – говорится, ”мы движемся от постиндустриального общества к обществу информационному”. Информационный сектор и число людей, связанных с информацией, постоянно возрастают. Точный объем информационного сектора в экономике определить довольно трудно, поскольку многие виды деятельности, особенно в сфере предоставления услуг имеют информационную составляющую. Во всяком случае ясно, что этот сектор растет очень быстро. В 90-х годах 95% новых рабочих мест появилось в областях, связанных со знаниями и предоставлением услуг.

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

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

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

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

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

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

Данная работа является примером применения новейших технологий в области информатизации управления – технологий клиент-сервер. Целью работы является построение системы автоматизации бизнес-процессов малого предприятия.

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

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

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

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

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

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

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

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

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

Далее дается заключение и список литературы к специальной части дипломного проекта.

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

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

ГЛАВА 1.

Предприятие как центр обработки информации.

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

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

• Обеспечивать получение общих или детализированных данных по итогам работы.

• Позволять легко определять тенденции изменения важнейших показателей.

• Обеспечивать получение информации, критической по времени, без существенной задержки.

• Выполнять точный и полный анализ данных.

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

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

Любая организация обрабатывает информацию для выработки двух видов «продукции»: информации (данных, документов, речевой информации) и решений (оперативных и стратегических). Организация получает начальную (входящую) информацию в различных видах: документы, доставляющие информацию в виде слов и цифр; речевая информация по телефону; данные от ЭВМ, часто в электронной форме. Конечная (исходящая) информация вырабатывается в таких же видах. Производственный цикл организации может включать перекомпоновку информации, объединение данной информации с дугой, накопление информации.

Анализ деятельности предприятий позволяет классифицировать задачи, решаемые предприятием.

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

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

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

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

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

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

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

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

Значение малого бизнеса в рыночной экономике, очень велико. Его становление и развитие является одной из основных проблем экономической политики в условиях перехода от административно-командной к рыночной экономике. Малый бизнес в рыночной экономике - ведущий сектор, определяющий темпы экономического роста, структуру и качество валового национального продукта. Во всех развитых странах на долю малого бизнеса приходится 60 - 70 процентов ВНП. Поэтому абсолютное большинство развитых государств всемерно поощряет деятельность малого бизнеса.

В мировой экономике функционирует огромное количество малых фирм, компаний и предприятий. Например, в Индии число малых предприятий превышает 12 млн., а в Японии 9 млн.

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

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

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

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

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

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

Таким образом, на третьем этапе автоматизации бизнес-процессов небольших фирм появляется идея создания малой ЛВС. На Западе под этим термином понимают сети, охватывающие от 2 до 30 компьютеров. В России, возможно, граница, отделяющая сети в малом офисе и частного пользователя (одна или несколько квартир в доме) от сети среднего предприятия, проходит на уровне десяти машин. Примерно на этом уровне происходит разделение сетей компаний, слабо использующих информационные технологии, и тех, для которых компьютеризация имеет большее значение.

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

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

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

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

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

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

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

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

4. Динамика. Следует учитывать различные аспекты фактора времени.

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

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

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

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

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

Критерии выбора информационной системы

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

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

Пять основных критериев.

Система должна быть понятной.

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

Система должна быть удобной.

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

Довольно распространен еще один неверный подход к автоматизации на предприятиях: подбор персонала под систему. Часто можно встретить рекламу типа: "требуется специалист, умеющий работать с программным обеспечением...". А как до приема на работу проверить реальные знания кандидата? Как узнать, будет ли данная система удобна для его работы? При поступлении на должность кандидат скажет что угодно, а дальше начнутся проблемы. Итак, система подбирается под человека и должна быть удобна для него.

Система должна быть надежной.

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

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

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

Система должна быть адекватной.

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

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

Определение и классификация систем автоматизации.

Функционирование систем автоматизации связано с накоплением и обработкой информации. Под информацией понимается совокупность знаний о фактических данных и зависимостях между ними. В ЭВМ понятия информации и данных часто отождествляются. Но если быть точными, то данные – это информация, представленная в форме, необходимой для ввода ее в ЭВМ, хранения, обработки и выдачи потребителям.

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

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

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

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

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

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

Второй признак классификации делит информационные системы на две группы: к первой относятся информационно-справочные системы (ИСС), называемые часто запросно-ответными или просто справочными, которые выполняют поиск и вывод информации без ее обработки. Автоматизированные информационные системы обработки данных (АИСОД, ИСОД), относящиеся ко второй группе, сочетают в себе информационно-справочную систему с системой обработки данных. Обработка найденных данных выполняется комплексом предусмотренных в системе прикладных программ. Большинство систем автоматизации построено по принципу ИСОД.

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

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

Последний из приводимых признаков классификации учитывает рассредоточенность (распределенность) компонентов системы автоматизации: локальная система размещается на одной ЭВМ, в то время как распределенная система функционирует в среде вычислительной сети и распределена по ее узлам (серверам и рабочим станциям).

Складские операции и кадровый учет на малом предприятии.

Содержательная постановка задачи автоматизации.

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

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

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

ГЛАВА 2.

2.1. Общие вопросы проектирования баз данных

Основные понятия теории баз данных.

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

Ядром информационной системы являются хранимые в ней данные. На любом предприятии данные различных отделов, как правило, пересекаются, то есть используются в нескольких подразделениях или вообще являются общими. Например, для целей управления часто нужна информация по всему предприятию. Заказ комплектующих невозможен без наличия информации о запасах. Хранящиеся в информационной системе данные должны быть легко доступны в том виде, в каком они нужны для конкретной производственной деятельности предприятия. При этом не имеет существенного значения способ хранения данных. Сегодня на предприятии мы можем встретить систему обработки данных традиционного типа, в которой служащий вручную помещает данные в скоросшиватель, и рядом с ней – современную систему с применением самой быстродействующей ЭВМ, сложнейшего оборудования и программного обеспечения. Несмотря на поразительную несхожесть, обе эти системы обязаны предоставлять достоверную информацию в определенное время, определенному лицу, в определенном месте и с ограниченными затратами.

Построение информационных систем основывается на понятиях теории баз данных.

Предметная область.

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

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

Необходимо различать полную предметную область (предприятие) и организационную единицу этой предметной области. Организационная единица в свою очередь может представлять свою предметную область (отделы).

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

Объект.

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

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

Класс объектов.

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

Объекты и их свойства являются понятиями реального мира. Для информационного пространства употребляется понятие атрибута объекта.

Атрибут.

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

Взаимосвязь между перечисленными выше понятиями проиллюстрирована схемой:

Таблица.

Таблица – это некоторая регулярная структура, состоящая из конечного набора однотипных записей.

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

Значение данных.

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

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

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

Ключевой элемент данных.

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

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

Первичный ключ.

Первичные ключ – это атрибут (или группа атрибутов), которые единственным образом идентифицируют каждую строку в таблице.

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

Альтернативный ключ.

Альтернативный ключ – это атрибут (или группа атрибутов), несовпадающий с первичным ключом и уникально идентифицирующий экземпляр объекта. Например для объекта «служащий», который имеет атрибуты «ИДЕНТИФИКАТОР», «ФАМИЛИЯ», «ИМЯ», «ОТЧЕСТВО», группа атрибутов «ФАМИЛИЯ», «ИМЯ», «ОТЧЕСТВО» может являться альтернативным ключом по отношению к атрибуту «ИДЕНТИФИКАТОР».

Запись данных.

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

Тип данных.

Тип данных характеризует вид хранящихся данных.

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

Домен.

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

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

ТИПЫ ДАННЫХ

ДОМЕНЫ

Представление.

Представление – это сохраненяемый в базе данных именованный запрос на выборку данных (из одной или нескольких таблиц).

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

Связь.

Связь – это функциональная зависимость между сущностями.

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

Поддержание непротиворечивости функциональных зависимостей между сущностями называется ссылочной целостностью. Поскольку связи содержатся «внутри» реляционной модели, реализация ссылочной целостности может выполняться как приложением, так и самой системой управления базами данных (СУБД) с помощью механизмов декларативной ссылочной целостности и триггеров.

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

• тип связи (идентифицирующая, не идентифицирующая, полная/неполная категория, неспецифическая связь);

• родительская сущность;

• дочерняя (зависимая) сущность;

• мощность связи;

• допустимость пустых значений.

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

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

Мощность связи представляет собой отношение количества экземпляров родительской сущности к соответствующему количеству экземпляров дочерней сущности. Для любой связи, кроме неспецифической, эта связь записывается как 1:n.

Хранимые процедуры.

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

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

Правила.

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

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

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

Триггеры.

Триггеры – это предварительно определенное действие или последовательность действий, автоматически осуществляемых при выполнении операций обновления, добавления или удаления данных.

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

• Ограничения, для реализации которых собственно и создается триггер.

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

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

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

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

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

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

Ссылочная целостность.

Ссылочная целостность – это обеспечение соответствия значения внешнего ключа экземпляра дочерней сущности значениям первичного ключа в родительской сущности.

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

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

• отсутствие проверки;

• проверка допустимости;

• запрет операции;

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

• установка пустого (NULL) значения или заданного значения по умолчанию.

Нормализация отношений.

Нормализация отношений – это процесс построения оптимальной структуры таблиц и связей в реляционной базе данных.

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

Словарь данных.

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

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

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

При ответе на первый вопрос: «Что лежит в основе бизнеса данной фирмы ?», как правило, выявляются наиболее важные для данного бизнеса или производственного процесса компоненты.

Ответы на второй вопрос: «Как это делается ?» позволяют получить список основных бизнес-процессов, происходящих в фирме.

Вопрос: «Где происходият данные процессы ?» больше относится к проблемам телекоммуникаций и организациии совместной работы персонала. Например, в случае большого объема операций, которые выполняются вне территории фирмы торговыми агентами, придется учитывать проблемы синхронизации данных. При наличии филиалов весьма непростой проблемой является оптимальный выбор системы распределения данных. Можно централизовать всю обработку данных и филиалы будут выполнять свои операции, пользуясь возможностями телекоммуникаций. Работа с данными в этом случае упрощается, однако необходимо позаботиться об устойчивой связи филиалов с головным предприятием.

Ответ на вопрос: «Кто выполняет эти процессы ?» даст организационная структура фирмы.

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

Последний вопрос: «Почему эти действия выполняются?» позволяет определить мотивацию производственной деятельности фирмы.

Ответы на шесть перечисленных вопросов позволяют подойти к главному в постановке задачи – построению информационной модели предприятия. Такая модель отображается в виде взаимосвязей между бизнес-компонентами. В практике проектирования информационных систем такие схемы получили название ER-диаграмм (Entity-relationship diagram (ERD) – диаграма «Сущность-связь»). ER-диаграмы хорошо вписываются в методологию структурного анализа и проектирования информационных систем. Такие методологии обеспечивают строгое и наглядное описание проектируемой системы, которое начинается с ее общего обзора и затем уточняется, давая возможность получить различную степень детализации объекта с различным числом уровней.

Максимально формализованное описание задачи состоит из следующих компонентов:

• Наименование задачи.

• Цель работы.

• Функции задачи.

• Бизнес-правила.

• Требования к программе.

• Перечень вводимой информации.

• Перечень печатных отчетов.

• Требования к оснащению офиса фирмы компьютерной техникой.

Основы теории проектирования баз данных.

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

Система автоматизированной обработки данных основывается на использовании определенной модели данных или информационной модели. Модель данных отражает взаимосвязи между объектами.

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

Концептуальная модель.

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

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

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

Логическая модель(внешняя модель).

Логическая модель отражает логические связи между элементами данных вне зависимости от их содержания и среде хранения.

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

Физическая модель(внутренняя модель).

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

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

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

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

Типы моделей данных.

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

Иерархическая модель.

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

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

Сетевая модель.

В сетевой модели данных понятия главного и подчиненного объектов несколько расширены. Любой объект может быть и главным и подчиненным (в сетевой модели главный объект обозначается термином «владелец набора», а подчиненный – термином «член набора»). Один и тот же объект может одновременно выступать и в роли владельца и в роли члена набора. Это означает, что каждый объект может участвовать в любом числе взаимосвязей.

Реляционная модель.

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

Проектирование базы данных.

Все тонкости построения информационной модели преследуют одну-единственную цель – получить хорошую базу данных. Что же такое хорошая база данных?

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

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

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

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

• База данных должна обеспечивать получение требуемых данных за приемлемое время, то есть отвечать заданным требованиям производительности.

• База данных должна удовлетворять выявленным и вновь возникающим требованиям конечных пользователей.

• База данных должна легко расширяться при реорганизации и расширении предметной области.

• База данных должна легко изменяться при изменении программной и аппаратной среды.

• Загруженные в базу данных корректные данные должны оставаться корректными.

• Данные до включения в базу данных должны проверяться на корректность.

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

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

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

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

2.2. Клиент-серверная модель вычислений

Иногда компьютерные технологии делают решительный рывок. Реляционная модель СУБД с ее простыми табличными структурами данных и мощными операциями – одна из таких революций. В 1994 г. отмечалась 25 годовщина с того момента, как доктор И.Ф.Кодд (тогда научный сотрудник компании IBM) предложил реляционную модель. Реляционная модель помогла сориентировать компьютерные науки на исследование проблем управления данными, а системы управления базами данных (реляционные СУБД) внесли заметные улучшения в доступ к данным и разработку приложений. Хотя в последнее время большое внимание уделяется объектно-ориентированным базам данных, в индустрии СУБД главенствует мнение, что ведущие реляционные системы управления базами данных успешно реализуют идеи объектно-ориентированных СУБД как расширение базовой реляционной модели. Существующая реляционная модель управления базами данных с успехом будет продолжать свое существование и в предстоящие годы.

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

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

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

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

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

Вычисления клиент-сервер.

Что такое вычисления клиент-сервер, и как использовать их преимущества? Вычисления клиент-сервер – это относительно новая модель вычислений, представляющая собой ни что иное как распределение обработки в многопользовательской базе данных по нескольким компьютерам (ПК и рабочим станциям). Что же может дать вычисление клиент-сервер по сравнению с традиционной однокомпьютерной средой (с одной большой ЭВМ). При корректной реализации системы клиент-сервер вы получите систему управления информацией с намного лучшим отношением «цена/производительность», которую можно наращивать и легко приспосабливать к меняющимся требованиям. И это лишь некоторые из причин, по которым стоит разобраться в вычислениях клиент-сервер и реализовать их в системе управления информацией.

Эволюция модели вычислений.

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

Централизованная модель.

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

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

Как и все прочее, модель вычислений на хост-машине имеет свои преимущества и недостатки. Плюсом является централизация в большой ЭВМ. Таким образом, системные администраторы могут надежно управлять одной машиной и обеспечивать доступность данных, когда они требуются пользователям, а также для защиты архивировать их. Централизованные системы позволяют совместно использовать периферию, диски, принтеры и модемы. Однако такая модель имеет и многие отрицательные качества. Например, чем большему числу сотрудников необходим доступ к большой ЭВМ, тем большая вычислительная мощность требуется для обслуживания потребностей организации. Сложилось так, что индустрию больших и мини-ЭВМ контролировали лишь несколько компаний. Это означало, что соответствующие ОС, процессоры, приложения и память на диске, необходимые для обслуживания организации, стоили очень дорого. Чем больше вам было нужно, тем больше приходилось платить.

Модель с автономными персональными вычислениями.

В 80-е годы произошло то, что навсегда изменило характер вычислений в организации: появились персональные компьютеры и рабочие станции. С тех пор как IBM создала PC и ОС DOS, Apple – Macintosh, а позднее появились рабочие станции UNIX таких компаний как Hewlett-Packard и Sun Microsystems, независимые друг от друга рабочие станции стали доминировать в организациях, положив конец централизованному контролю над данными компании больших машин.

Такую популярность персональные рабочие станции приобрели благодаря тому, что они имеют над большими ЭВМ несколько преимуществ:

• Персональные рабочие станции – это недорогие и простые в использовании компьютеры, предоставляющие вычислительные возможности и производительность, сопоставимые с дорогими большими машинами.

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

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

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

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

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

Модель вычислений с сетью и файловым сервером.

Проблемы совместного использования данных и периферийных устройств персональных компьютеров и рабочих станций быстро породили модель вычислений с сетью и файловым сервером. Фактически, если сегодня вы используете на работе персональный компьютер или рабочую станцию, то, скорее всего ваш компьютер подключен к локальной вычислительной сети (LAN). Локальная сеть дает преимущества коллективных вычислений, сохраняя простоту использования ПК, но позволяя совместно использовать данные и периферию, как в системах с большой ЭВМ.

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

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

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

Модель вычислений клиент-сервер.

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

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

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

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

• Управление доступом к базе данных и другими требованиями защиты.

• Защита информации в базе данных с помощью средств архивации-восстановления и создания резервных копий.

• Централизованное задание для всех клиентских приложений правил глобальной целостности данных.

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

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

• Управление логикой приложения, например, всплывающими списками в форме ввода данных или столбчатыми диаграммами в графическом представлении данных.

• Выполнение логики приложения, например, вычисление полей в форме ввода данных.

• Проверка допустимости данных.

• Запрос и получение информации о сервере базы данных.

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

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

Преимущества и недостатки вычислений клиент-сервер.

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

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

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

2. Использование систем клиент-сервер для разработки приложений.

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

3. Экономия средств благодаря использованию систем клиент-сервер.

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

4. Недостатки модели.

Вычисления клиент-сервер имеют и присущие им недостатки. Во-первых, ожидаемую экономию затрат реально можно получить не всегда. При проектировании стоимости компьютерной системы следует учитывать множество факторов, а не только затраты на аппаратуру. Например при оценке затрат важными показателями является продуктивность пользователей, включая пользователей приложения, разработчиков и администраторов. Разработчики могут улучшить продуктивность благодаря доступным в системах СУБД клиент-сервер GUI и инструментальным средствам автоматизированной разработки программного обеспечения (CASE). Однако пользователи и администраторы могут фактически столкнуться со снижением производительности. Это может произойти из-за недостаточной надежности системы, так как система клиент-сервер представляет собой сочетание независимо разработанных различными производителями и управляемых аппаратных и программных компонентов, а не однородную и централизованно управляемую большую или мини-ЭВМ. Неработоспособность из-за ненадежности системы снижает продуктивность работы пользователей и администраторов.

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

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

2.3. Сервер в системе клиент-сервер. Microsoft SQL Server

Серверы баз данных.

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

Однако для реальной работы с данными требуется соответствующее программное обеспечение. Таким программным обеспечением является система управления базой данных (СУБД) или сервер базы данных.

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

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

Целостность данных: ограничения целостности. В реляционной модели встает вопрос целостности данных. Если для реляционной базы данных выполнено условие целостности данных, то это означает, что все ее данные являются допустимыми (согласно набору правил). Например, все организации в таблице ОРГАНИЗАЦИИ должны иметь уникальный идентификатор ID (иначе вы не сможете различить две организации с одинаковым названием). Это стандартное правило целостности называется целостностью единицы, и подразумевает, что вы можете уникальным образом идентифицировать каждую строку таблицы.

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

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

Операции с данными: транзакции. Транзакция базы данных – это единица работы, состоящая из одного или нескольких операторов SQL.

Microsoft SQL Server.

Microsoft SQL Server является компонентом Microsoft Back Office для работы с базами данных. Он представляет собой систему управления реляционными базами данных (RDBMS), построенную для более эффективного управления информацией организации, с помощью которого можно создавать мощные приложения обработки данных в многопользовательской сетевой среде.

Характеристики Microsoft SQL Server .

Microsoft SQL Server построен на основе архитектуры клиент-сервер, которая позволяет разбивать процесс обработки информации на два компонента – предварительную обработку данных или клиентский компонент, и окончательную обработку или серверный компонент. SQL Server представляет собой сервер базы данных, обеспечивающий окончательную обработку данных, который может взаимодействовать с несколькими различными клиентскими компонентами, расположенными, как правило в одной сети (LAN). Он обладает встроенной поддержкой репликации данных, мощными инструментальными средствами и открытой архитектурой, которая обеспечивает ему репутацию надежного и эффективного информационного решения для организаций всех размеров. SQL Server представляет собой законченную интегрированную систему управления базами данных, которая удовлетворяет всем современным требованиям построения масштабируемых распределенных информационных систем.

Microsoft SQL Server имеет следующие характеристики:

• Relational database management system (RDBMS). Структура данных SQL Server удовлетворяет реляционной модели базы данных и позволяет проводить с данными операции в соответствии с правилами реляционной алгебры, впервые сформулированными Е.Ф.Коддом в 1970г.

• SQL-based. Администраторы, пользователи и прикладные программисты применяют Structured Query Language (SQL) для работы с SQL Server.

• Масштабируемость. На компьютер с SQL Server можно добавить дополнительные процессоры (имеется в виду, что компьютер, на котором работает SQL Server, представляет такую возможность), и тогда производительность работы программного обеспечения SQL Server также увеличится без какой бы то ни было дополнительной настройки.

• Высокая производительность. Microsoft SQL Server был тщательно протестирован на многих компьютерах в различных условиях работы. Его показатели производительности находятся среди лучших для подобных систем.

В 1988 году фирма Microsoft совместно со своими партнерами Ashton-Tate и Sybase представили свою первую версию SQL Server , построенную под операционную систему OS/2. В дальнейшем фирма Microsoft перенесла SQL Server под Windows NT. Эти изменения потребовали коренных перестроек в ядре SQL Server, но, тем самым, обеспечили продукту SQL Server мощность мультипроцессорной RDBMS в среде Windows NT. В 1992 году фирма Microsoft начала процесс отделения от Sybase и стала сосредотачивать больше внимания на собственной версии SQL Server. В конце концов, Microsoft и Sybase закончили совместную работу, и к Microsoft перешел полный контроль над разработкой SQL Server. Далее в SQL Server были добавлены следующие возможности:

• Поддержка RISC-платформы

• MAPI-интерфейс для разработки приложений, выполняющих запросы в базу данных

• Инструменты переноса данных

• Интеграция с объектами OLE и системой программирования VisualBasic

• Расширен язык работы с системой, добавлена декларированная ссылочная целостность (DRI) и поддержка курсоров

Важнейшие особенности Microsoft SQL Server.

Широкие возможности администрирования. SQL Server 6.0 предоставляет широкие возможности администрирования, осуществляемого системой интегрированных объектов, сервисов и компонентов. Для того чтобы управлять системой, SQL Server использует SQL Enterprise Manager – графический инструмент, который осуществляет управление системой и включает:

• Планирование задач

• Административные изменения

• Встроенный интерфейс управления репликациями

SQL Enterprise Manager также обеспечивает для администратора базы данных (DBA) более простое управление:

• Входом в систему

• Привилегиями доступа

• Группами пользователей

• Устройствами данных и базами данных

• Созданием сценариев

• Резервированием баз данных и журналом транзакций

• Компонентами баз данных (таблицами, представлениями, хранимыми процедурами, индексами, триггерами, правилами, значениями по умолчанию и создаваемыми пользователями типами данных)

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

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

Репликация. Microsoft SQL Server 6.0 включает возможность репликации данных как стандарта RDBMS. При репликации данных пользователь может распространять копии транзакционных данных от одного сервера предприятия на один или несколько удаленных серверов.

Функциональные особенности. SQL Server поддерживает стандарты, принятые Американским Национальным Институтов Стандартов, которые предполагают возможности работы с курсорами, обладающими возможностями прокрутки и абсолютного и относительного позиционирования, а также включает:

• Расширенный контроль целостности базы данных

• Параллельное сканирование данных (асинхронное предварительное чтение) последовательных страниц операций

• Возможность добавления ключей и резервных слов

• Оптимизатор запросов

• Системные хранимые процедуры

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

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

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

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

Основа продукта RDBMS состоит в том, что он осуществляет отделение функций управления данными от функций приложения. Эта концепция хорошо работает в комбинации с моделью клиент-сервер. Работа по управлению данными изолирована в RDBMS, которая в модели клиент-сервер расположена на сервере и в операционной системе Windows NT представлена сервисом. Приложениям сервис RDBMS необходим для обработки запросов к данным. Сервис управления данными включает, как минимум, возможность определять данные и манипулировать ими.

2.4 Клиент в системе клиент-сервер. Microsoft Access 97

2.4.1. Клиентные приложения – окно доступа к базе данных

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

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

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

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

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

• Ввод данных и оперативная обработка транзакций при помощи форм.

• Применение средств генерации запросов и вывода отчетов для поддержки анализа принятия решений.

• Усовершенствование клиентских приложений при помощи инструментальных средств.

2.4.2. Использование СУБД MicrosoftAccess 97 в качестве клиентного приложения

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

СУБД Microsoft Access 97 для работы с данными использует процессор баз данных Microsoft Jet, объекты доступа к данным и средство быстрого построения интерфейса – Конструктор форм. Для получения распечаток используются конструкторы отчетов. Автоматизация рутинных операций может быть выполнена с помощью макрокоманд. В случае недостатка визуальных средств, пользователи могут обратиться к созданию процедур и функций. При этом как в макрокомандах можно использовать вызовы функций, так и из кода процедур и функций можно выполнять макрокоманды.

В Microsoft Access 97 присутствует язык программирования Visual Basic for Application, который позволяет создавать массивы, свои типы данных, вызывать DLL-функции, контролировать работу приложений с помощью OLE Automation. Можно даже полностью создавать базы данных с помощью кодирования, если в этом появляется необходимость.

MS Access имеет один из самых лучших наборов визуальных средств среди аналогичных программных продуктов.

Одно из основных преимуществ MS Access – тесная интеграции с популярным офисным пакетом Microsoft Office.

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

Встроенный язык запросов SQL позволяет максимально гибко работать с данными и значительно ускоряет доступ к внешним данным.

Формы.

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

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

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

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

• Командные кнопки в форме могут выполнять действия, связанные с выводимой в форме текущей записью.

• Форма, выводящая на экран контекстно-зависимые инструкции, позволяет сократить время обучения.

Создание форм в клиентском приложении отнимает больше половины времени. Однако при использовании форм в MS Access предоставляется наибольшее разнообразии средств автоматизации.

При работе с формами доступно большое количество встроенных объектов. Со многими объектами связаны Построители, причем число их разновидностей так велико, что позволяет построить автоматизированно до 90% приложения. Мастера предоставляются для таких объектов как кнопки, группы, списки, комбинированные списки, подчиненные формы.

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

Для форм доступны три режима работы: Конструктор, Форма и Таблица. Режим ввода данных имеет три вида: ленточная форма, простая форма и таблица. При работе с простой формой одновременно Вы можете видеть данные только одной записи, при ленточной – одну и более, в зависимости от того, сколько можно уместить их на экран.

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

При работе с формой загружается своя система меню, в режиме Конструктора – одна, а в режиме формы – другая. Также загружается панель инструментов. В режиме формы можно указать, какое меню и панель инструментов должны загружаться, при этом можно указывать и созданные пользователем.

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

Формы и элементы управления можно модифицировать программно.

Отчеты и запросы.

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

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

Для создания отчетов в MS Access используется Мастер отчетов, который позволяет автоматизировать создание стандартных отчетов, а также содержит средства для создания отчетов с диаграммами и почтовых наклеек.

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

Также как и формы, отчеты можно создавать программно.

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

Система построения запросов в Access не имеет себе равных среди СУБД массового использования. Практически все виды запросов, которые можно построить программно, в Access можно построить визуально. Исключение составляют сквозные запросы (SQL pass-through), запросы на изменение структуры данных (DDL) и запросы объединения.

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

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

Использование сквозных запросов позволяет контролировать работу любого сервера базы даных, находясь в среде разработки MS Access.

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

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

Для создания динамически меняющихся запросов можно создать параметрические запросы. Параметрический запрос позволяет пользователю ввести значения для отбора данных.

Запросы можно составлять программным путем. При этом возможны два варианта. Первый – запуск непосредственно команд SQL. Для этого необходимо создать переменную строкового типа и запустить ее с помощью макрокоманды RunSQL. Второй способ – это использование объектов доступа к данным.

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

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

• Макросы.

• Встроенный язык программирования VisualBasic.

• Встроенные утилиты системы защиты.

Макросы.

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

Система защиты.

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

Язык программирования VisualBasic.

Visual Basic является универсальным языком программирования, однако в СУБД MS Access он используется как язык программирования для обработки баз данных.

Основные возможности Visual Basic, применимые в разработке приложений для обработки информации, могут быть реализованны благодаря наличию в нем объектов для доступа к данным – Data Access Object (DAO), 32-разрядного процессора данных – JET и предназначенных специально для работы с данными элементов управления.

Процессор данных в Visual Basic поддерживает все стандартные операции по созданию, изменению и удалению таблиц, индексов и запросов. Формат БД процессора данных Visual Basic соответствует формату Access. JET также обеспечивает поддержку целостности и проверку вводимых и изменяемых данных на уровне полей и записей. Для изменения данных JET позволяет использовать язык SQL.

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

Уникальным свойством JET является возможность создания копий данных (репликация БД), а также согласования данных в обновляемой и оригинальной БД. Причем эти операции могут выполняться как с файлами формата БД процессора данных (MS Access), так и с БД других форматов, поддерживаемых через механизм ODBC.

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

2.5. Взаимодействие Access и SQL Server

2.5.1 Особенности использования Microsoft Access в разнородной среде.

Поскольку Access является завершенным программным продуктом непосредственного взаимодействия пользователя с базой данных, его невозможно использовать в качестве интерфейсного средства управления дисплеем, подключенного к серверу. Включая Access в разнородную систему, можно построить либо приложение полностью взаимодействующее с файловым сервером, либо сбалансированное приложение клиент/сервер вместе с нормальным сервером базы данных, например Microsoft SQL Server.

Access очень хорошо работает в качестве однопользовательской системы приложения базы данных. Его средства реализации форм можно применять для создания очень полезного клиентского интерфейса, а Visual Basic for Applications (VBA), для формирования кода прикладной задачи. Допустимо внедрять VBA и в механизм базы данных средства для реализации бизнес-правил и правил целостности данных, а также создавать высокоэффективный механизм базы данных, обеспечивающий размещение данных приложения и управление ими.

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

Применение только Access для создания приложения клиент-сервер дает следующие преимущества:

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

• Возможность использования для создания приложения единственного интегрированного продукта.

• Относительную простоту экспертной оценки приложения в силу широкой популярности Access.

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

• Применение средств VisualBasic, используемых в различных продуктах фирмы Microsoft, для кода более сложных приложений.

• Относительную простоту построения приложений умеренной сложности (обеспечивающих работу не более двадцати пользователей).

• Возможность создания приложений клиент-сервер с помощью более дешевой сетевой технологии.

Способ построения приложений только с помощью Access имеет следующие недостатки:

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

• Все бизнес-правила должны быть ужесточены клиентом: опытный пользователь может получить доступ к данным вне приложения клиента в обход правилам.

• Даже при тщательно разработанном доступе к файловому серверу обычно возникает более интенсивный сетевой трафик, чем при использованиии сервера баз данных.

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

• Архитектура файлового сервера Access не способствует управлению большими объемами данных (свыше одного гигабайта) на сервере.

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

2.5.2. Особенности использования Microsoft SQL Server в разнородной среде.

При использовании в архитектуре клиент-сервер развитой системы управлелния базой данных, такой как Microsoft SQL Server, более сбалансированная рабочая загрузка создается автоматически – перемещением большей части работы на сервер. Клиент может не посылать команды доступа к файлам нижнего уровня серверу, а послать по сети более специальные запросы к базе данных.

Применение Access с SQL Server для создания приложения клиент-сервер дает следующие преимущества:

• SQL Server, работающий в Microsoft NT, более устойчив по отношению к сбоям системы.

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

• На сервере базы данных можно создать более эффективную защиту данных.

• Установка правил целостности данных и бизнес-правил на сервере лишает клиента возможности их обойти.

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

• Хорошо спроектированный сервер базы данных способен работать с сотнями пользователей одновременно.

Применение Access с SQL Server для создания приложения клиент-сервер имеет и недостатки:

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

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

• Приложения файлового сервера имеют тенденцию к усложнению.

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

ГЛАВА 3. «Модель учета кадров и складских запасов малого предприятия. Реализация. Анализ работы»

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

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

Таким образом работа фирмы рассматривается через работу с конкретным клиентом.

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

Общие требования к разрабатываемой системе автоматизации:

• Ведение учета в реальном масштабе времени.

• Ведение учета одновременно с нескольких рабочих мест.

• Наличие графического пользовательского интерфейса.

• Наличие системы защиты и разделения прав пользователей.

Особенности бизнес-процессов предприятия-заказчика:

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

• Наличие курьерской службы – внештатных сотрудников, работающих по договору.

• Наличие головного предприятия – разработчика программных средств, информационно-техническое обслуживание которых осуществляет фирма-заказчик по дистрибуторскому договору.

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

Автоматизация складского учета.

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

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

• Получение программных продуктов (товаров) на склад предприятия.

• Выдача программных продуктов покупателям (клиентам).

• Формирование информации по текущему состоянию склада.

• Формирование информации по складу за отчетных период.

Особенности ведения складского учета на предприятии заказчике:

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

• Существует большое количество разновидностей дистрибутивов программ – более 10.

• Существует несколько типов дистрибутивов: локальный, сетевой, однопользовательский-сетевой.

• Существуют специализированные виды дистрибутивов: спецвыпуск, VIP-выпуск.

• Существует возможность перевода дистрибутива между разновидностями, типами, специализированными видами.

• Существует возможность возврата на склад дистрибутива через неограниченный промежуток времени.

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

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

Автоматизация кадрового учета.

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

Общие требования к разработке системы автоматизации кадрового учета:

• Регистрация информации о сотрудниках предприятия.

• Регистрация информации о проводимой работе сотрудников.

• Возможность начисления заработной платы сотрудникам.

• Возможность приема,перемещений и увольнений сотрудников.

• Возможность просмотра начислений предыдущих периодов.

Особенности ведения кадрового учета на предприятии заказчике:

• Регистрация кандидатов желающих занять вакансию на работу в курьерской службе.

• Распределение обслуживаемых организаций по курьерам.

• Просмотр месячных и статистических отчетов по периодам сопровождения.

• Перераспределение организаций между курьерами.

• Учет пополнения организаций.

• Оплата курьеров в зависимости от объема выполненой работы за месяц.

• Динамически изменяющийся период расчета зарплаты.

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

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

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

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

Для решения задачи была выбрана клиент-серверная реализация системы автоматизации, в качестве сервера баз данных использовался Microsoft SQL Server, в качестве клиентской платформы был выбран Microsoft Access. Основные особенности и причины выбора модели, сервера и клиента подробно описаны в ГЛАВЕ 2 данного дипломного проекта.

Для реализации проекта структура базы данных была разделена на три отдельных модуля:

- модуль для отдела сопровождения (MdlClnt.mdb),

- модуль для технического отдела (MdlStore.mdb),

- модуль данных (Data.mdb).

3.2. Формализованное описание механизмов складского и кадрового учета.

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

Модуль «Склад».

• Начало работы.

• Прием дистрибутивов на склад.

• Выдача дистрибутивов со склада клиентам.

• Изменение характеристик дистрибутивов.

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

• Просмотр текущего состояния склада.

• Просмотр отчета по складу за отчетных период.

• Возврат дистрибутива на склад.

• Окончание работы.

Модуль «Кадры».

• Начало работы.

• Ведение перечня кандидатов на должность курьера.

• Перевод кандидата в должность курьера.

• Распределение организаций между курьерами.

• Заполнение характеристик организации и установленных у нее систем.

• Регистрация работы курьера в течение рабочего периода.

• Поиск информации в системе.

• Регистрация расчетного периода.

• Расчет заработной платы курьера.

• Архивирование расчетного периода.

• Увольнение курьера.

• Отключение организации от сопровождения.

• Окончание работы.

Надо отметить, что поведение системы описывается визуальными формами и процедурами, написанными на языке Visual Basic for Application и содержащимися в разделе «Приложения» дипломной работы. Структура составляет функциональные блоки и программы, описывающие существенные события. Рассмотрим на содержательном уровне реакции системы на перечисленные выше события.

Модуль «Склад».

Начало работы.

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

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

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

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

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

При регистрации системы на складе также необходимо указать следующие реквизиты:

• Дата регистрации системы на складе (по умолчанию текущая системная дата).

• Тип системы – локальная, сетевая, сетевая-однопользовательская (по умолчанию локальная).

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

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

Необходимо отметить наличие исключительных ситуаций, предусмотренных программой:

• При регистрации дистрибутива с регистрационным номером больше 60000 он автоматически будет зарегистрирован как «спецвыпуск».

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

Выдача дистрибутивов со склада клиентам.

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

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

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

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

Изменение характеристик дистрибутивов.

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

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

2. Изменение характеристик дистрибутивов выданных со склада. Для этого необходимо воспользоваться пунктом меню «Операции» – «Переход дистрибутивов». В открывшемся диалоге ввода необходимо задать номер искомого дистрибутива и нажать кнопку «Найти». В окне найденных дистрибутивов необходимо выделить искомый, затем нажать кнопку «Изменить свойства». В открывшемся окне существует возможность изменить любые свойства дистрибутива: от даты получения на склад – до типа системы и организации за которой он зарегистрирован.

3. Изменение системы, выданной пользователю. Существует возможность изменения разновидности системы, выписанной клиенту. Данная ситуация возможна, если клиент пожелал получить более или менее мощную систему. Для изменения системы необходимо вызвать диалог изменения свойств дистрибутива (смотри п.2), а затем дважды нажать мышью на интересующий дистрибутив. В открывшемся окне необходимо указать новую разновидность системы, а также можно изменить любые другие реквизиты дистрибутива. Результатом данной операции является генерация нового дистрибутива на складе, при этом в примечании к измененному дистрибутиву указывается, что он был переведен на новую систему, в примечании к новому дистрибутиву указывается, что он является переходом с другой разновидности системы, а также дата перехода.

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

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

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

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

Просмотр текущего состояния склада.

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

Просмотр отчета по складу за отчетных период.

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

Возврат дистрибутива на склад.

В случае отказа клиента от покупки системы существует возможность возвратить дистрибутив на склад. Для этого достаточно выбрать списанный дистрибутив в диалоге «Получение и выдача дистрибутивов» и затем нажать на кнопку «Возвратить». Дистрибутив будет возвращен на склад, при этом в примечании к дистрибутиву будет указана дата возвращения и клиент за которым числился дистрибутив.

Окончание работы.

Для окончания работы с системой необходимо выбрать пункт меню «Выход». При этом система выполнит закрытие открытых объектов,сброс таблиц и разрыв соединения с сервером. После этого модуль «Склад» будет закрыт.

Модуль «Кадры».

Начало работы.

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

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

Ведение перечня кандидатов на должность курьера.

До поступления на работу в курьерскую службу каждый из кандидатов должен пройти собеседование с менеджером отдела сопровождения, а также заполнить анкету. Результаты собеседования и анкетирования фиксируются в графах диалога “Курьеры”. Для заполнения граф необходимо выбрать пункт меню “Операции”-“Курьеры”, затем в окне диалога “Курьеры “ выбрать закладку “Кандидаты”. В графах закладки “Кандидаты” указывается:

• Фамилия, Имя, Отчество кандидата.

• Адрес и домашний телефон кандидата.

• Место постоянной работы, учебы.

После заполнения всех граф необходимо нажать кнопку “Занести” для регистрации информации о кандидате в базе даных.

Перевод кандидата в должность курьера.

Для выполнения данной операции в окне диалога “Курьеры”, в закладке “Кандидаты” необходимо выделить кандидата. Затем нужно нажать кнопку “Перевести в курьеры”, после выполнения данной операции кандидат будет зачислен на работу в должность курьера.

Распределение организаций между курьерами.

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

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

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

Заполнение характеристик организации и установленных у нее систем.

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

• полное название организации;

• ФИО руководителя организации;

• ФИО бухгалтера организации;

• ФИО контактного сотрудника организации;

• контактные телефоны(факс) организации;

• адрес(ближайшая станция метро) организации;

• банковские реквизиты организации;

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

• “сложность” организации – под “сложностью” организации понимается ряд характеристик, затрудняющих сопровождение данной организации (дальность, наличие устаревшей техники, разветвленность организации, важность организации).

Заполнение перечня характеристик организации ведется из диалогового окна “Характеристики организации”, которое вызывается из окна “Курьеры” нажатием кнопки “Параметры организации”.

Регистрация работы курьера в течение рабочего периода.

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

Поиск информации в системе.

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

• Фамилия, имя, отчество курьера, сопровождающего данную организацию.

• Координаты и контактные лица данной организации.

• Периодичность пополнения и хронологию пополнений в текущем отчетном периоде.

• Информацию о системах, установленных в данной организации.

Регистрация расчетного периода.

В текущий момент времени все пользователи системы “Кадры” получают информацию по курьерской службе актуальную на текущий момент расчетного периода. Однако существует возможность перемещения рабочего интервала внутри расчетного периода. Данная возможность позволяет просмотреть информацию прошлых периодов работы. Для изменения текущей недели расчетного периода необходимо воспользоваться пунктом меню “Опции” меню “Сервис”. Затем в диалоге ввода необходимо выбрать месяц и неделю интересующего нас рабочего периода. После нажатия кнопки “Установить” будет установлен необходимый расчетный месяц и неделя и информация будет обновлена.

Расчет заработной платы курьера.

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

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

После окончания расчета появляется сообщение: “Расчет закончен”.

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

Увольнение курьера.

Для выполнения операции увольнения необходимо передать все сопровождаемые организации данного курьера, а затем нажать кнопку “Уволить” окна диалога. После выполнения данной операции информация по курьеру будет перемещена в закладку “Уволенные”.

Отключение организации от сопровождения.

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

Окончание работы.

Для окончания работы с системой необходимо выбрать пункт меню «Выход». При этом система выполнит закрытие открытых объектов, сброс таблиц и разрыв соединения с сервером. После этого модуль «Кадры» будет закрыт.

Дополнительные возможности.

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

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

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

ОРГАНИЗАЦИОННО-ЭКОНОМИЧЕСКАЯ ЧАСТЬ

Тема: «Технико-экономическое обоснование проекта. Расчет сметы затрат и цены на ПП. Оценка целесообразности проведения работы.»

1. Введение.

Данная работа является научно-исследовательской разработкой в области автоматизации деятельности коммерческих предприятий и относится к системам автоматизации бухгалтерского и складского учета.

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

Об автоматизации малых предприятий.

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

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

• Обеспечивать получение общих или детализированных данных по итогам работы.

• Позволять легко определять тенденции изменения важнейших показателей.

• Обеспечивать получение информации, критической по времени, без существенной задержки.

• Выполнять точный и полный анализ данных.

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

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

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

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

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

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

2. Организация работы.

НИР проводилась по заказу Закрытого Акционерного Общества «Информационное Бюро «Воробьевы Горы»», являющемся Региональным Информационным Центром Общероссийской сети распространения правовой информации «Консультант Плюс» в 1997 году. Источником финансирования проекта является заказчик - коммерческое предприятие.

Согласно ГОСТ 15.101-80 «Порядок проведения НИР» можно выделить четыре этапа проектирования. Время проведения работы составляет 3 месяца. Длительность работ по каждому этапу была определена следующим образом:

1. Разработка технического задания – 2 недели.

2. Выбор направления исследования – 3недели.

3. Теоретические и экспериментальные исследования – 4 недели.

4. Обобщение и оценка результатов исследования - 3 недели.

Работы начали проводиться с 01.09.97г. Ниже представлен график проведения НИР.

Для проведения научно-исследовательской разработки была создана группа:

1. Руководитель проекта – ведущий инженер.

2. Исполнители – инженер-программист, инженер.

Приведем календарный план работ НИР в соответствии с этапами работы:

1-ый этап. 01.09.1997 – 14.09.1997

• Разработка основных требований в предметной области к НИР. Оформление технического задания. Исполнитель – ведущий инженер.

• Разработка основных требований к программному обеспечению. Исполнитель – инженер-программист.

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

2-ой этап. 15.09.1997 – 07.10.1997

• Постановка задачи сотрудникам рабочей группы НИР. Оценка конкурирующих разработок. Исполнитель – ведущий инженер.

• Закупка и установка необходимого программного обеспечения. Составление блок-схемы НИР. Исполнитель – инженер-программист.

• Изучение предметной области и необходимого программного обеспечения. Проектирование интерфейса пользователя и общего дизайна программы. Исполнитель – инженер.

3-ий этап. 08.10.1997 – 07.11.1997

• Программирование интерфейса пользователя, системы защиты. Исполнитель – инженер.

• Проектирование модулей предметной области и индивидуальных алгоритмов работы. Сборка модулей. Исполнитель – ведущий инженер.

• Программирование модулей предметной области и индивидуальных алгоритмов работы. Исполнитель – инженер-программист.

4-ый этап. 08.11.1997 – 30.11.1997

• Проверка работы алгоритмов, обучение пользователей, изготовление документации пользователя и отчетных документов по НИР. Исполнетель – ведущий инженер.

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

• Отладка интерфейса пользователя и системы защиты. Распределение прав и паролей между пользователями. Исполнитель – инженер.

3. Расчет сметы затрат и цены научно-технической продукции.

Цена разработки включает в себя следующие статьи затрат:

1. Статья затрат «Затраты на оплату труда работников, непосредственно занятых созданием научно-технической продукции» - 13500 тыс. руб.

Расчет выполнен исходя из трудоемкости, необходимой для выполнения работ, и заработной платы работников (см.табл.1).

2. Статья затрат «Отчисления по налогам » – 5332.5 тыс. руб.

Затраты по данной статье определяются установленным нормативом от расходов на оплату труда работников, непосредственно занятых созданием научно-технической продукции ( в том числе: 1.5% - отчисления в фонд занятости, 28% - отчисления в пенсионный фонд, 5.4% - отчисления в фонд социального страхования, 3.6% - отчисления в фонд медицинского страхования, 1% - транспортный налог).

13500 тыс. руб. * 39.5% = 5332.5 тыс. руб.

3. Статья затрат «Накладные расходы» - 47250 тыс. руб.

Затраты по данной статье составляют 350% от расходов на оплату труда работников, непосредственно занятых созданием научно-технической продукции.

13500 тыс. руб. * 350% = 47250 тыс. руб.

4. Статья затрат «Материалы» – 154тыс. руб. (см.табл.2).

5. Статья затрат «Транспортные расходы» – 15.4 тыс. руб.

Затраты по данной статье составляют 10% от стоимости материалов:

154 тыс. руб. * 10% = 15.4 тыс. руб.

6. Статья «Прибыль» –

Расчетный норматив рентабельности определен 20% от собственных работ.

(13500 + 5332.5 + 47250 + 154 + 15.4) тыс. руб. * 20% = 13250 тыс. руб.

Не учитываются затраты по статьям «Дополнительная заработная плата», «Командировочные расходы», «Расходы на специальное оборудование», «Оплата работ, выполняемых сторонними организациями», т.к. они не используются.

Таблица 1. Расчет основной заработной платы.

Должность	Оклад (руб.)	Продолжительность работы (мес.)	Фонд оплаты труда (руб.)
Ведущий инженер	2 000 000	3	6 000 000
Инженер-программист	1 500 000	3	4 500 000
Инженер	1 000 000	3	3 000 000
Итого:			13 500 000

Таблица 2. Данные по статье затрат «Материалы»

Наименование материала	Единицы измерений	Количество штук	Стоимость (руб.)	Общая стоимость (руб.)
Бумага писчая	Пачка	1	20 000	20 000
Бумага для принтера	Пачка	3	30 000	90 000
Карандаши	Шт.	3	2 000	6 000
Ручки шариковые	Шт.	3	4 000	12 000
Ластики	Шт.	2	500	1 000
Дискеты	Шт.	10	2 500	25 000
Итого:				154 000

Таблица 3. Смета затрат на разарботку.

Статья затрат	Сумма (руб.)
Затраты на оплату труда работников	13 500 000
Отчисление на налоги	5 332 500
Накладные расходы	47 250 000
Материалы	154 000
Транспортные расходы	15 400
Итого:	66 251 900

Таким образом, стоимость проведения данной научно-исследовательской разработки равна:

С = 66 251 900 рублей.

Цена научно-технической продукции определяется суммой:

Ц = С + П, где С – стоимость НИР,

П – прибыль.

Подставляя рассчитанные значения, получим:

Ц = 66 251 900 + 13 250 000 = 79 501 900 руб.

Цена продажи данной работы с учетом НДС составлвяет:

Цпр = 79 501 900 + 15 900 380 = 95 402 280 руб.

4. Оценка конкурентноспособности изделия.

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

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

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

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

Теперь оценим конкурентоспособность научно-технической разработки. Перед тем как была разработана данная программа, фирма-заказчик рассматривала возможность установки программы RS-Balance российского холдинга R-Style. Программа RS-Balance, широко используется на территории РФ для автоматизации деятельности средних и крупных предприятий.

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

Встроенный язык программирования системы RS-Balance не является столь распространенным, как используемый нами Visual Basic – таким образом затраты на обучение персонала были бы значительными.

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

Таким образом суммарная стоимость затрат на приобретение, внедрение и сопровождение программы RS-Balance оказалась выше, чем у разработанной нами программы. Количественная оценка эффективности НИР можно получить, исходя из сравнительной таблицы в которую занесены некоторые эксплуатационные характеристики разработанной системы и программы RS-Balance.

Таблица 4.

Показатели	Собственная разработка	Коэфф.	RS-Balance	Коэфф.
Объем памяти, занимаемый файлами системы	2 Мб	1	10 Мб	5
Среднее время ввода данных	2 Мин	1	6 Мин	3
Стоимость программы	~15 000 $	1	~15 000$	1
Стоимость обучения персонала	~1 000 $	1	~ 10 000$	10
Итого		4		19

Сравнительный коэффициент: 4/19 = 0.21

Таким образом, данная научно-техническая разработка в 4.75 раз эффективнее по сравнению с известной нам подобной системой. Кроме того мы не учитывали возможность получения прибыли от коммерческого распространения НИР. Дать количественную оценку возможности коммерческого распространения довольно трудно, так как возможность продаж системы зависит от многих факторов, например реклама, маркетинг, ценовая политика и спрос и т.д.

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

ЭРГОНОМИКА

Тема: «Эргономические особенности дипломного проекта».

1. Введение.

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

Как ни странно, но первый шаг в этом направлении сделали разработчики программного обеспечения. В 1992 году вышла в свет новая операционная система Microsoft Windows 3.1 которая обладала встроенным графическим интерфейсом и мгновенно получила огромную популярность среди пользователей персональных компьютеров.

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

Сегодня мы переживаем бурный рост развития эргономики в области программного и аппаратного обеспечения компьютеров. Каждый день на рынке появляются все новые решения и разработки предназначенные улучшить работу пользователей на персональном компьютере. Современный дизайн, беспроводные устройства ввода-вывода, технология Plug&Play («включи и работай»), речевой и рукописный ввод, системы искусственного интеллекта, “плоские” дисплеи, TCO95 (стандарт жестко ограничивающий электромагнитное и другие виды излучений компьютера) и т.д. – все это Вы можете встретить в современных компьютерных системах.

2. Эргономика при проектировании систем автоматизации.

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

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

1. Использование модели вычислений клиент-сервер.

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

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

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

После выбора модели вычислений необходимо решить вопрос о выборе средств разработки и использования проектируемой системы автоматизации. Так как более 90% компьютеров в мире используют операционные системы семейства Microsoft Windows, а более 80% пользователей используют офисный пакет приложений Microsoft Office – выбор был сделан именно в пользу данных систем. Таким образом пользователь получает возможность работать в дружественной ему среде, а так же избегает дополнительных финансовых затрат. Необходимо отметить, что данные два программных продукта (Windows 95 и Microsoft Office 97) на сегодняшний день являются образцом эргономических разработок в области компьютерной индустрии. При создании данных программ использовались длительные программы тестирования в которых принимало участие несколько миллионов человек. Цель данных программ – увеличение производительности и достижение комфорта при работе человека за компьютером. Каждая следующая версия программ данного семейства в среднем на 30% повышает уровень работы пользователя. Контекстно-зависимое меню, диалоговые окна, панели инструментов, подсказки, контекстно-зависимая система помощи, гипертекст – вот всего лишь несколько примеров применения в рассмотренных системах разработок в области эргономики.

3. Индивидуальный подход к разработке.

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

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

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

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

4. Использование современных программных разработок в области интерфейса пользователя.

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

• для отображения процесса загрузки программы использовались «строки загрузки»

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

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

5. Разработка дизайна проекта.

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

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

Длительное ожидание выполнения каких-либо действий всегда сопровождается надписью «Идет выполнение операции. Подождите…» совместно с использованием строки загрузки, которая позволяет наглядно представить какой объем информации уже обработан и какой объем еще предстоит обработать. Данное средство позволяет сгладить эффект «длительного ожидания» у пользователя.

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

3. Эргономические особенности сервера баз данных.

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

Для разработки серверной части дипломной работы использовался сервер баз данных Microsoft SQL Server 6.5. На сегодняшний день данный продукт обладает одними из наилучших возможностей управления.

Для управления базой данных служит SQL Enterprise Manager, который обладает графическим пользовательским интерфейсом и позволяет наглядно представить все службы сервера и ветви базы данных. При работе с SQL Enterprise Manager Вы можете либо пользоваться меню, либо кнопками панели инструментов. Для каждой кнопки меню есть своя подсказка (tooltip). Если остановить на некоторое время курсор мыши на кнопке панели инструментов, появится маленькое окошечко с описанием функции этой кнопки. Выбирая определенные опции и вводя информацию в появляющиеся окна, Вы можете проделать множество тех же самых действий, которые выполнялись раньше через команды языка Trasact-SQL и требовали длительного утомительного изучения языка SQL и основ программирования. Так же существует окно легенды с отображением всех обозначений и символов, используемых в SQL Enterprise Manager. Кроме опций меню и кнопок панели инструментов существует возможность использовать правую кнопку мыши и открывать с ее помощью контекстное меню для объектов в окнах SQL Enterprise Manager. Если остановить курсор мыши на каком-либо объекте и нажать правую кнопку мыши, Вы сможете выполнить такие команды как создание объекта, удаление объекта или редактирование его структуры.

Для управления доступом к базе данных служит SQL Security Manager. Обладая встроенным графическим интерфейсом и всеми возможностями по управленю объектами аналогичными SQL Enterprice Manager, SQL Security Manager обладает также одним очень важным и удобным дополнением. Администраторы Windows NT Server – операционной системы под управлением которой работает SQL Server, получают возможность управлять бюджетами (системами безопасности) пользователей напрямую через SQL Security Manager.

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

4. Эргономические особенности клиентского приложения.

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

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

• MS Access имеет один из самых лучших наборов визуальных средств среди аналогичных программных продуктов. Вся работа с базами данных интегрирована в окне базы данных. При разработке программы широко используются такие современные решения, как панели инструментов, технология Drag&Drop (перетащи и брось), панели свойств, гипертекстовые ссылки и др.

• При создании форм, отчетов, запросов существует возможность воспользоваться большим количеством встроенных шаблонов и «помощников», следовательно сокращается процесс написания программы.

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

• Широкие возможности документирования и создания помощи пользователям. Окна подсказок, «ярлыки» подсказок, отличная документация на русском языке и встроеная система помощи – отличительные особенности СУБД Microsoft Access.

• Одно из основных преимуществ MS Access – тесная интеграции с популярным офисным пакетом Microsoft Office. 80% пользователей в мире применяют этот пакет для организации работы в офисе и дома. Следовательно проектируемая нами система может быть легко применена и перенесена между множеством компьютеров.

• MS Access использует самый популярный на сегодняшний день язык программирования Visual Basic. Это позволяет рассчитывать на широкую поддержку со стороны пользователей и сторонних разработчиков.

5. Заключение.

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

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

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

ГРАЖДАНСКАЯ ОБОРОНА

Тема: «Разработка программы для складского учета в на складе ГО г.Москвы».

1. Введение.

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

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

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

В целях заблаговременной подготовки объектов к возможному возникновению ЧС, создания условий, повышающих устойчивость работы предприятий и своевременного проведения аварийно-спасательных и других неотложных работ на объектах, организуется гражданская оборона (ГО). При начальнике ГО объекта создается штаб ГОЧС – орган управления начальника гражданской обороны. Состав штаба зависит от размера и значимости объекта для общества. Штаб ГОЧС осуществляет мероприятия по защите рабочих, служащих и населения и обеспечивает своевременное оповещение их об угрозе ЧС; организует и обеспечивает непрерывное управление ГО; разрабатывает план ГО объекта, периодически корректирует и организует его выполнение; организует и контролирует обучение рабочих и служащих гражданской обороне и подготовку невоенизированных формирований объекта. Надо отметить, что невоенизированные формирования составляют основу сил гражданской обороны.

Основная задача формирований при ликвидации последствий ЧС – спасение людей и материальных ценностей.

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

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

Основу защиты в г. Москве составляет ГУ ГОЧС (Главное Управление Гражданской Обороны и Чрезвычайных Ситуаций) г. Москвы. Так как Москва является одним из крупнейших административных центров и играет главенствующю роль в политической и экономической жизни РФ – ответственность за защиту города в условиях ЧС несет штаб ГУ ГОЧС г.Москвы. Необходимо отметить, что Москва является одним из самых густонаселенных городов, поэтому штабу ГУ ГОЧС города приходится хранить и вести учет большого количества различных материалов и оборудования для защиты города в условиях ЧС. До настоящего времени учет складских запасов производился исключительно в бумажной форме, однако развитие вычислительной техники позволило разработать системы автоматизации для учета складской деятельности штабов ГОЧС.

2. Особенности складского учета на складе ГУ ГОЧС.

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

• Программа должна работать на нескольких компьютерах, объединенных в локальную вычислительную сеть. Таким образом с программой могут одновременно работать несколько человек. Например, сотрудник отдела снабжения склада ГУ ГОЧС может просматривать состояние склада и осуществлять своевременный заказ оборудования, и в то же самое время кладовщик может отпускать оборудование подразделениям ГО для проведения спасательных работ.

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

• Программа должна отражать специфику деятельности склада ГУ ГОЧС. Она должна обладать возможностями группировать оборудование на складе по категориям: медикаменты, автотранспорт, инструменты, спецодежда, средства защиты и.т.п.

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

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

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

• Программа должна легко переноситься с одного компьютера на другой, так как не исключена возможность использования программы в подвижном варианте ( на компьютерах типа notebook) в условиях ЧС.

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

При проектировании учитывалось, что склад ГУ ГОЧС г.Москвы является организацией с разветвленной инфраструктурой. Предполагается использование данной программы в разных отделах склада, разными сотрудниками.

3. Разработка программы «Склад ГО».

Программа «Склад ГО» разрабатывалась с учетом особенностей ведения складского учета на складе ГУ ГОЧС г.Москвы. Программа создавалась и используется в оболочке Системы Управления Базами Данных (СУБД) Microsoft Access 97. Выбор данного программного продукта был сделан после анализа требований, предъявляемых к программе. При выборе учитывались следующие положения:

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

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

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

• Данная СУБД обладает развитым графическим интерфейсом пользователя и функционирует в самой распространенной операционной системе Windows 95. Она обладает встроенным языком программирования Visual Basic for Application, который делает ее еще более гибкой и настраиваемой на нужды пользователей.

Проектирование базы данных «Склад ГО» велось в соответствии с блок-схемой складского учета (Приложение 1). В соответствии с данной блок-схемой можно выделить три этапа работы программы:

1. Ввод начальных данных. На данном этапе формируются начальные данные, необходимые для работы программы. Для этого заносятся группы оборудования, регистрируемого на складе (медикаменты, средства защиты и т.д.), вводятся поставщики оборудования (Штаб ГУ ГОЧС Московского Военного Округа, Росвооружение, ООО «Стройтехника», и т.п.), перечисляются сотрудники склада ГУ ГОЧС г.Москва (Петров, Иванов и т.д.) и регистрируются основные реквизиты склада ГУ ГОЧС (адрес, телефон, индекс…).

2. Работа в программе «Склад ГО». На данном этапе происходит основная работа по ведению складского учета на складе ГУ ГОЧС: регистрируются поступившие товары, производится инвентаризация оборудования, подготавливаются заказы.

3. Формирование отчетности по складу. На данном этапе происходит анализ результатов работы склада за определенный период времени, а так же анализ текущего состояния склада. Существует возможность просмотреть три вида отчетов, которые характеризуют различные аспекты складского учета на складе ГУ ГОЧС.

Описание форм и отчетов.

1. Форма «Сведения об организации». Предназначена для ввода реквизитов склада ГУ ГОЧС г.Москвы. Данные реквизиты в дальнейшем используются при формировании отчетной информации.

Основные поля: «адрес», «индекс», «телефон», «факс», «руководитель».

2. Форма «Группы оборудования». Предназначена для ввода групп оборудования, хранящегося на складе ГУ ГОЧС. На этапе ввода начальных данных в данное поле введены значения: «транспорт», «спасательная техника», «инструменты», «средства защиты», «медикаменты», «средства связи», «спецодежда», «продукты питания». Данная форма позволяет вводить новые, удалять и изменять существующие группы оборудования.

Основные поля: «код группы», «категория».

3. Форма «Поставщики». Данная форма содержит сведения о поставщиках оборудования для склада ГУ ГОЧС г.Москвы. В данную форму на этапе формирования начальных данных введены следующие значения: «Штаб ГУ ГОЧС Московского Военного Округа», «Росвооружение», «АО «Росмедпоставки»», ООО «Стройтехника», Министерство связи РФ. Существует возможность добавления новой или изменения реквизитов существующей организации.

Основные поля: «Название», «Обращаться к», «Должность», «Адрес», «Телефон», «Факс», «Индекс», «Город».

4. Форма «Сотрудники». Форма содержит сведения о сотрудниках склада ГУ ГОЧС г.Москвы. Данные о сотрудниках используются для формирования заказов, а также для распределения прав доступа к базе данных.

Основные поля: «Фамилия», «Имя», «Должность», «Телефон», «Внутренний телефон».

5. Форма «Оборудование». Является одной из основных форм, предназначенных для ведения учетных операций по складу. Содержит информацию о всех видах оборудования хранимого на складе, количестве оборудования данного вида на складе, а также информацию по заказанному оборудованию. Позволяет регистрировать заказ оборудования, отслеживать состояние склада, а также проводить инвентаризацию оборудования.

Основные поля: «Название оборудования», «Описание», «Группа», «Количество на складе», «Количество в заказе», кнопка «Заказать…».

6. Форма «Формирование заказа». Служит для оформления заказа на оборудование. Позволяет производить групповой заказ, связывать заказ с конкретным поставщиком, фиксировать даты размещения и исполнения. Каждый заказ оформляется конкретным сотрудником склада ГУ ГОЧС г.Москва, следовательно существует возможность контроля за заказами со стороны руководства склада. При работе с данной формой существует возможность вывести на экран и распечатать Карточку заказа.

Основные поля: «Номер заказа», «Поставщик», «Сотрудник», «Описание», «Дата размещения», «Дата исполнения», таблица «Заказ оборудования», кнопка «Просмотр карточки оборудования».

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

8. Отчет «Итоговые сведения по складу». Отчет о текущем состоянии склада. Показывает приход, расход, остаток (в количественном и денежном эквиваленте) оборудования , хранящегося на складе.

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

4. Выводы.

Созданная программа «Склад ГО» – является современным решением задачи ведения складского учета средств ГО. Данная программа обладает рядом преимуществ перед аналогичными программами. Основными преимуществами данной программы являются:

• легкость в использовании

• удовлетворение специфических задач склада ГУ ГОЧС

• широкие возможности расширения

• высокая степень защиты

Данная программа разработана для склада ГУ ГОЧС г. Москвы, однако может применяться и на складах ГУ ГОЧС по всей территории РФ. Использование средств вычислительной техники и современного программного обеспечения значительно повышают уровень работы складов ГУ ГОЧС и позволяют своевременно и оперативно работать в условиях чрезвычайных ситуаций.

5. Приложения.

Приложение 1. Блок-схема работы программы.

П

риложение 2. Экранные формы программы.

Список литературы.

1. В.Г.Атаманюк и др. «Гражданская оборона», Москва, «Высшая школа», 1986г.

2. Р.Ахаян и др. «Эффективная работа с СУБД», Санкт-Петербург, «Питер», 1997г.

3. Г.Саливан, Д.Бенаш «Секреты MS Access 97», Санкт-Петербург, «BHV», 1997г.

4. «Гражданская оборона». Под редакцией А.Т.Алтунина, «Военное издательство», 1984г.

5. Список литературы.

1. Р.Ахаян и др. «Эффективная работа с СУБД», Санкт-Петербург, «Питер», 1997г.

2. Г.Саливан, Д.Бенаш «Microsoft BackOffice в подлиннеке», Санкт-Петербург, «BHV», 1997г.

3. Д.Л.Вескес, М.Гандерлоу,М.Чипмен «Access и SQL Server», Москва, «Лори», 1997г.

4. Dwayne Gifford «Access 97 Unleashed», Indianapolis USA, «SAMS Publishing», 1997г.

ОХРАНА ТРУДА И ЭКОЛОГИЯ

Тема: «Обеспечение требований электробезопасности на рабочем месте программиста.»

Введение.

Стандартная конфигурация ПЭВМ включает слудующий набор оборудования: системный блок, монитор, принтер и периферийное оборудование. Наличие данных электроприборов является источником возникновения опасных и вредных производственных факторов.

В помещении, где находится ПЭВМ, действуют следующие неблагоприятные факторы:

• повышенный уровень напряжения электрической цепи, замыкание которой может произойти через тело человека;

• повышенный уровень шума;

• повышенный уровень электромагнитных излучений;

• недостаточная освещенность рабочей зоны;

• неблагоприятные метеорологические условия рабочей зоны;

• пожароопасные факторы;

Среди наиболее опасных факторов в помещении с электрооборудованием является возможность поражения человека электрическим током вследствии нарушения электроизоляции. Человек начинает ощущать протекающий через него ток промыщленной частоты (50 Гц) относительно малого значения: 0.6 – 1.5 мА. Этот ток называется пороговым ощутимым током. Ток 10 – 25 мА вызывает сильные и весьма болезненные судороги мышц, которые человек преодолеть не в состоянии. Такой ток называется пороговым неотпускающим. Ток 80 – 100 мА и выше вызывает существенные повреждения в организме человека.

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

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

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

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

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

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

Задача проектирования зануления – выбрать основные элементы зануления (нулевые защитные проводники, аппараты защиты и повторные заземления) и определить их параметры. В результате расчета проверяется соответствие выбранных элементов критерию эффективности зануления и в случае несоответствия назначаются меры ее повышения.

Проектирование зануления.

1. Исходные данные.

Необходимо спроектировать зануление электрооборудования с номинальным напряжением 220В. Электрооборудование представляет собой компьютерный процессор с монитором. Мощьность процессора составляем 120Вт, монитора – 360Вт. С учетом подключения периферийной аппаратуры ( в нашем случае – принтера) считаем, что мощьность нашего электрооборудования не превышает 1кВт. Следовательно, номинальный ток составляет I_н = P/U = 4,5 A.

Для питания электрооборудования от цеховой силовой сборки используется провод марки АПР, прокладываемый в стальной трубе. Сечение алюминиевого провода S = 2,5 мм². Диаметр водогазопроводной трубы для прокладки проводов d = 19,1 мм. Потребитель подключен к третьему участку питающей магистрали. Длина участка 0,05 км. Первый участок магистрали выполнен четырехжильным кабелем марки АВРЕ с алюминиевыми жилами сечением 3х70, 1х25 мм² в полихлорвиниловой оболочке, длина участка 0,23 км. Участок защищен автоматом типа А3134 с комбинированным расцепителем на номинальный ток I_н = 150 A. Участок магистрали №2 выполнен кабелем АВРГ 3х35, 1х10 мм², длина участка 0,075 км, участок защищен автоматическим выключателем А3134 с тепловым расцепителем на номинальный ток I_н = 80 A. Магистраль питается от масляного трансформатора типа ТМ – 1000 с первичным напряжением 10 кВ и вторичным 400/230 В, со схемой соединения обмоток . Магистраль зануления на первых двух участках выполнена четвертой жилой питающего кабеля, на третьем участке – стальной трубой.

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

Схема питания прибора представлена на рисунке 1:

ТП – трансформаторная подстанция, РП – распределительный пункт, СП – силовая подстанция.

2. Выбор аппарата защиты, сопротивления и места сооружения повторных заземлений.

Применим для защиты предохранитель типа ПР-2.

I_пр = 1,25 I_н, где I_н - номинальный ток электрооборудования.

I_пр = 1,25  4,5 = 5,6А.

Для расчета выбираем номинал предохранителя 6А.

В схеме электроснабжения используется один участок длиной более 200м, поэтому необходимо сооружение повторного заземления на распределительном пункте (РП). Сопротивление повторного заземления регламентируется ГОСТом 12.1.030-81. В ПУЭ регламентируется сопротивление растеканию всех повторных заземлителей, которое в любое время года должно быть не больше 5, 10, 20 Ом соответствено при 380, 220, 127 В источника однофазного тока. Т.о. сопротивление повторного заземления в нашем случае не должно превышать 10 Ом.

3. Расчетная проверка зануления.

3.1. Определяем расчетный ток однофазного короткого замыкания для предохранителя ПР-2. Если среда нормальная

I _о.к.з. > к I_н, где I_н - номинальный ток защитных аппаратов ( в данном случае – предохранителя);

к – коэффициент кратности; для ПР-2 к =3.

I _о.к.з. = 3  6 = 18 А

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

I_з = ,

где z_т -расчетное сопротивление трансформатора, z_п - суммарное полное сопротивление фазного провода и нулевого защитного проводника.

3.2. Определяем расчетное сопротивление трансформатора ( по табл. 6.1 [1]).

z_т = 0,081 Ом; z_т / 3 = 0,027 Ом.

3.3. Полное сопротивление петли “фазный-нулевой провод” определяется по формуле:

z_п = z_ф + z_н; где z_ф = ;

z_н = ;

Определяем активное сопротивление фазного провода для каждого участка и суммарное по формуле:

r = ; где - удельное сопротивление материала ,

l - длина участка, км;

S - сечение провода, мм²

_алюм = 31,4 ;

r_ф1 = 31,4  0,23 / 70 = 0,1032 Ом;

r_ф2 = 31,4  0,075 / 35 = 0,0673 Ом;

r_ф3 = 31,4  0,05 / 2,5 = 0,628 Ом;

r_ф = 0,7985 Ом.

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

r_ф = r_ф  К_т, где К_т = 1 +  (Т-20) - поправочный коэффициент

 - температуреный коэффициент сопротивления.

Для алюминия  = 0,004 град^–1 [12],

К_т = 1 + 0,004 (55 – 20) = 1,14;

r_ф = 1,14  0,7985 = 0,9103 Ом.

3.5. Определяем активное сопротивление нулевого защитного проводника:

r_н1 = 31,4  0,23 / 25 = 0,2889 Ом,

r_н2 = 31,4  0,075 / 10 = 0,2355 Ом,

Для водогазопроводной трубы из стали d = 19,1 мм, погонное сопротивление

r_ =1,8 Ом/км (табл. 25, [11])

r_н3 = r_  l = 1,8  0,05 = 0,09 Ом.

3.6. Определяем расчетное активное сопротивление магистрали зануления с учетом температурной поправки.

r_н1t = 0,2889  1,14 = 0,3293 Ом,

r_н2t = 0,2355  1,14 = 0,2684 Ом,

Кtстали = 1 + 0,05  (55 - 20) =1,175, где  - температурный коэффициент сопротивления для стали.

r_н3t = 0,09  1,175 = 0,1057 Ом

r_н = 0,7036 Ом.

3.7. Определим внешние индуктивные сопротивления фазных проводов и нулевого.

x_ф’ = х_ф.м’ – х_ф.L’; х_н’ = х_н.м’ – х_н.L’

х_ф.м’ = х_н.м’ = 0,145  lg d_ф-н  l; где d – расстояние между фазным и нулевым проводом.

Для 1 и 2 участков магистрали d определяем, исходя из следующих данных справочника [2]:

• толщина оболочки четырехжильного кабеля данных марок 2,1 мм (табл.1.23);

• диаметр внешней оболочки – 39,9 мм для кабеля с жилами 3х70 и 1х25 мм² и 30,4 – для 3х35 и 1х10 мм² (табл. 5.13)

• толщина изоляции жил (табл.5.3)

S, мм²: 70 – 1,6 мм;

25 – 1,4 мм;

35 – 1,4 мм;

10 – 1,2 мм;

Т.о.

d₁ = 39,9 – 4,2 – 1,6 – 1,4 – 9,4 –5,6 = 17,6 мм;

d₂ = 30,4 – 4,2 – 1,4 – 1,2 – 6,7 – 3,6 = 13,4 мм.

Для третьего участка d определяется вычитанием радиуса провода из радиуса водогазопроводной трубы:

d3 = 19,1 / 2 – 0,9 = 8,7 мм.

Тогда

х_ф.м1’ = х_н.м1’ = 0,145  lg 17,6  0,23 = 0,0416 Ом;

х_ф.м2’ = х_н.м2’ = 0,145  lg 13,4  0,075 = 0,0122 Ом;

х_ф.м3’ = х_н.м3’ = 0,145  lg 8,7  0,05 = 0,0068 Ом.

х_ф.м’ = х_н.м’ = 0,0606 Ом.

Внешние индуктивные сопротивления самоиндукции определяются по формуле:

х_ф.L’ = х_L’  l; где - х_L’ погонное индуктивное сопротивление самоиндукции, Ом/м. Значения х_L’ выбираем для каждого участка по таблице 2 (стр.13 [12]).

х_ф.L1’ = 0,09  0,23 = 0,0207 Ом,

х_ф.L2’ = 0,068  0,075 = 0,0051 Ом,

х_ф.L3’ = 0,03  0,05 = 0,0015 Ом,

х_ф.L’ = 0,0273 Ом.

х_н.L1’ = 0,068  0,23 = 0,0156 Ом,

х_н.L2’ = 0,03  0,075 = 0,0023 Ом,

х_н.L3’ = 0,138  0,05 = 0,0069 Ом,

х_н.L’ = 0,0248 Ом.

Суммарные внешние индуктивные сопротивления:

х_ф’ = 0,0606 – 0,0273 = 0,0333 Ом,

х_н’ = 0,0606 – 0,0248 = 0,0358 Ом.

3.8. Определим внутренние индуктивные сопротивления:

х_ф1-2” = х_н1-2” = 0,0157  l₂ = 0,0048 Ом (l₂ = 0,23 + 0,075 = 0,305 км),

х_ф3” = 0,0157l₃ 0,05 = 0,0008 Ом,

х_н3” = 0,6r_н3 = 0,06  0,1057 = 0,0634 Ом,

х_ф” = 0,0056 Ом, х_н” = 0,0682 Ом

3.9. Находим полное сопротивление фазного и нулевого проводов:

z_ф = = 0,9111 Ом,

z_н = = 0,7112 Ом.

3.10. Рассчитаем ток однофазного короткого замыкания:

I_о.к.з. = ; I_о.к.з. = 220/ (0,027 + 0,9111 + 0,7112) = 133,39А.

3.11. Сравниваем расчетные параметры с допустимыми.

133,4 > 18 I_о.к.з. > кI_н ,

0,71 < 2  0,91 z_н < 2z_ф

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

Падение напряжения на участке нулевого провода составит:

U_н = I_о.к.з.  z_н2-3

z_н2-3 =

r_н2-3 = r_н2t + r_н3t = 0,2684 + 0,1057 = 0,3742 Ом,

х_н2-3’ = х_н2’ + х_н3’ = (х_н.м2’ – х_н.L2’) + (х_н.м3’ – х_н.L3’) = 0,0122 – 0,0023) + (0,0068 – 0,0069) = 0,0098 Ом,

х_н2-3” = х_н2” + х_н3” = 0,0157  0,075 + 0,064 = 0,0013 + 0,0634 = 0,0646 Ом

Т.о. х_н2-3 = 0,3815 Ом.

U_н = 133,4 0,3815 = 50,89 В.

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

U_п.з. = R_п.з.  I_о.к.з.  z_н1 / (R_п.з. + R₀)

z_н1 = ;

где r_н1t = 0,3293 Ом,

z_н1 = =0,3307 Ом.

U_п.з. = 10  133,4  0,3307 / (10+4) = 31,51 В,

Учитывая коэффициент прикосновения (табл.1 [12]), получим полное напряжение прикосновения:

U_пр = U_н +   U_п.з. = 51,42 + 0,3  31,91 = 60,99 В.

По таблице 2 п.1.3. ГОСТа [10] определяем, что для такого значения предельно допустимое время воздействия тока 0.9с.

Как видно из характеристики предохранителя ПР-2 с номинальным током 6А [3] время срабатывания защиты 0.9с и меньше обеспечивается при кратности тока к > 7. Это удовлетворяет нашей задаче, т.к. истинная кратность тока, полученная в результате расчета, составляет к = 133,4/6  21.

Защитное отключение.

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

В сетях до 1000В с заземленной нейтралью могут быть использованы устройства защитного отключения (УЗО), реагирующие на несимметрию фазных токов [5].

Примером УЗО для нашей сети может служить однофазная схема магнитного пускателя С-881, реагирующая на небаланс фазных токов [4]:

Назначение прибора: защита от замыканий на корпус и при прикосновении к фазным проводам. Установка срабатывания – ток трогания Iтр = 0,010 А. Время срабатывания 0,03с. Датчиком входного сигнала, получаемого фильтрами небаланса фазовых токов, в схеме является ТНП, сигнал от которого усиливается транзисторным усилителем.

В качестве достоинств данной схемы можно назвать простоту, стабильность устновки, чуствительность, а также селективность. Основной недостаток – отсутствие самоконтроля, что допускает ее применение только совместно с заземлением (занулением).

Меры по обеспечению электробезопасности.

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

При эксплуатации электрооборудования должны соблюдаться следующие меры:

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

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

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

4. Электропроводка, используемая для канализации электроэнергии, должна выполняться с соблюдением правил ПУЭ. При монтаже электропроводок надо уделить особое внимание надежности соединений.

5. При наладке электрооборудования необходимо иметь инструменты только с изолированными ручками.

6. Необходимо выполнять контроль изоляции электропроводки не реже 1 раза в 6 месяцев. Контроль изоляции сводится к измерению сопротивлений изоляции. Оно не должно превышать допустимых значений. (таблица 1.8.39 [6]).

7. Электрооборудование, вводимое в эксплуатацию, должно быть подвергнуто приемо-сдаточным испытаниям в соответствии с главой 1.8. Заключение о пригодности оборудования к эксплуатации дается на основании рассмотрения результатов всех испытаний. (1.8.4)

Заключение.

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

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

Список литературы.

1. Долин П.А. «Основы техники безопасности в электроустановках.», М., Энергоатомиздат, 1984г.

2. Белорусов Н.И., Саакян А.Е. и др. Справочник «Электрические кабели, провода и шнуры», М., Энергоатомиздат, 1987г.

3. Князевский Б.А., Либкин Б.С. «Электроснабжение промышленных предприятий», М., Энергия, 1976г.

4. Мотузко Ф.Я. «Защитные устройства в электроустановках», М., Энергия, 1973г.

5. Ревякин А.И., Кашолкин Б.И., «Электробезопасность и противопожарная защита в электроустановках», М., Энергия, 1980г.

6. «Правила устройства электроустановок», М., Энергоатомиздат, 1990г.

7. «Правила эксплуатации электроустановок потребителей», М., Энергоатомиздат, 1992г.

8. Кузнецов Б.В., «Электробезопасность при эксплуатации электроустановок», Минск, «Беларусь», 1987г.

9. Мотузко Ф.Я. «Охрана труда», М., Высшая школа, 1975г.

10. Система стандартов безопасности труда. Госкомитет по стандартам. ГОСТ 12.1.038-82 «Предельно допустимые значения напряжения прикосновения и токов.», М., 1983г.

11. Долин П.А. Справочник по электробезопасности. М., Энергоатомиздат, 1984г.

12. Методические указания по выполнению раздела «Охрана труда и экологии» в дипломных проектах. Вопросы электробезопасности. Москва, МИРЭА, 1987г.

СодержаниеI. Специальная часть. Введение 3 Глава 1. Основная часть 1.1. Содержание и требования, предъявляемые к информации 3 1.2. Значение внутрифирменной системы информации 4 1.3. Основные принципы, цели, задачи и функции внутрифирменно

 

• 14:21 05 Июля 2016
  Российско-китайский медуниверситет откроет магистерскую программу по TCM
• 01:21 05 Июля 2016
  На форуме МГУ Россия и Китай обсудят научно-образовательное сотрудничество
• 11:00 04 Июля 2016
  Реморенко: "ЕГЭ-туризм" в России сходит на нет
• 10:52 04 Июля 2016
  Летняя российско-австрийская школа откроется в Москве
• 15:31 01 Июля 2016
  В СПбГУ могут воссоздать географический факультет

Заказать уникальную работу