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
Гражданская
оборона 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) и просто
означает разделение
таблицы на
несколько
меньших таблиц
без потери
информации.
Нормализация
наиболее полезна
для проверки
созданной вами
структуры.
Можно проанализировать
свои решения
о том, какие
столбцы должны
быть включены
в ту или иную
таблицу с точки
зрения правил
нормализации,
убедившись
при этом, что
не сделали
каких-то фатальных
ошибок. Понимание
основ процесса
нормализации
также может
помочь в процессе
проектирования
базы данных,
но оно не является
универсальным
рецептом при
построении
базы с нуля.
Итак, как определить,
какие столбцы
должны располагаться
в начале таблицы.
Общего правила
на этот счет
не существует.
Однако здесь
вам может оказать
существенную
помощь моделирование
зависимостей
— анализ сущности
данных (в терминах
объектов или
вещей) и зависимостей
между ними
(один-к-одному,
один-ко-многим,
многие-ко-многим).
На практике
проектирование
базы данных
требует хорошего
понимания
моделируемой
предметной
области, а также
знаний в области
моделирования
зависимостей
и нормализации.
Проектирование
базы данных
обычно является
итеративным
процессом, в
ходе которого
шаг за шагом
достигается
требуемый
результат, а
иногда и пересматривается
несколько
шагов, переделывая
предыдущую
работу с учетом
появившихся
новых потребностей.
Вот примерная
последовательность
шагов выполняемая
в процессе
проектирования
базы данных.
Исследования
информационной
среды для
моделирования.
Откуда
поступает
информация
и в каком виде?
Как
она будет вводиться
в систему и
кто этим будет
заниматься?
Как
часто она
изменяется?
Какие
параметры
системы будут
наиболее
критическими
с точки зрения
времени реакции
на запрос и
надежности?
Изучение
всех бумажных
материалов,
а также информационных
файлов и форм,
которые используются
в организации
для хранения
и обработки
данных.
Уточнение,
в каком виде
информация
должна извлекаться
из базы данных
— в форме отчетов,
заказов, статистической
информации.
Кому
она будет
предназначаться.
2.
Создание списка
объектов (вещей,
которые будут
предметом базы
данных) вместе
с их свойствами
и атрибутами.
Объекты, скорее
всего, должны
быть собраны
в таблицы (каждая
строка таблицы
будет описывать
один объект,
например организацию,
счет или платежное
поручение),
свойства объектов
будут представлены
столбцами
таблицы (например,
адрес компании,
стоимость
дистрибутива).
3.
В ходе работы
обязательно
должен создаваться
макет таблиц
и связей между
ними, называемый
структурой
данных (data
structure),
или диаграммой
зависимостей
между объектами
(E-R
diagram).
4.
Предварительно
разобравшись
с объектами
и их атрибутами,
надо
убедится,
что каждый
объект имеет
атрибут (или
группу атрибутов),
по которому
однозначно
можно идентифицировать
любую строку
в будущей таблице.
Этот идентификатор
обычно называется
первичным
ключом. Если
такового нет,
то для получения
искусственного
ключа следует
создать дополнительный
столбец.
Затем
должны быть
рассмотрены
зависимости
между объектами.
Имеются
ли зависимости
типа один-ко-многим
(один заказчик
может иметь
множество
выписанных
счетов, но каждый
счет может
быть выписан
только на одного
заказчика) или
многие-ко-многим?
Есть
ли возможности
для объединения
связанных
таблиц? Для
этого служат
внешние ключи
(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г.
Боуман
Джудит, Эмерсон
Сандра, Дарновски
Марси. «Практическое
руководство
по SQL. 3-е издание».
Пер с англ. –
Киев, Диалектика.
1997.
Дейт,
К.
«Введение в
системы баз
данных».-М.:Наука,
Диалектика.
1980.
Мартин,
Дж. «Организация
баз данных в
вычислительных
системах».-М.:Наука,
Диалектика.
1980.
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.
Кодд,
Е.Ф. «Реляционная
модель данных».
Пер с англ. –
Киев, Диалектика.
1996.
Ипстейн,
Роберт. «Реляционная
производительность:
Понимание
производительности
реляционных
баз данных».
Пер с англ. –
Киев, Диалектика.
1996.
Ross,
Ronald
G. «Entity
Modeling: Techniques and Application».
Boston: Database Research Group, Inc. 1995.
Гайн,
Крисс. «Введение
в SQL»
.-М.:Наука, Диалектика.
1980.
Праг,
Керри Н. и др.
«Секреты Access
97» Пер
с англ. – Киев,
Диалектика.
1997.
Кент,
Вилиам. «Введение
в пять нормальных
форм в теории
реляционных
баз данных».
Пер с англ. –
Киев, Диалектика.
1996.
Ларcон,
Брюс. «Руководство
по экспертным
базам данных».
Пер с англ. –
Киев, Диалектика.
1996.
Date C.J.
«An
Introduction to Database Systems»
Volume 1, Reading, Mass.: Addison-Wesley Publishing Company, 1989.
Date C.J.
«An
Introduction to Database Systems»
Volume 2, 2-th edition. Reading, Mass.: Addison-Wesley Publishing
Company, 1989.
Перкинсон,
Р.С. «Анализ
данных: Ключ
к проектированию
баз данных».
Пер с англ. –
Киев, Диалектика.
1996.
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)
18 Iо.к.з. >
кIн
,
0,71
< 2
0,91 zн <
2zф
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п.з.
+ R0)
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с. Датчиком
входного сигнала,
получаемого
фильтрами
небаланса
фазовых токов,
в схеме является
ТНП, сигнал от
которого усиливается
транзисторным
усилителем.
В качестве
достоинств
данной схемы
можно назвать
простоту,
стабильность
устновки,
чуствительность,
а также селективность.
Основной недостаток
– отсутствие
самоконтроля,
что допускает
ее применение
только совместно
с заземлением
(занулением).
Меры по
обеспечению
электробезопасности.
Для обеспечения
электробезопасности
при работе с
вычислительной
техникой необходимо
проведение
организационных
мер электробезопасности.
К ним относится
учеба, инструктаж,
экзамен по
технике безопасности,
правильная
организации
рабочего места
и режима труда,
применение
защитных средств,
предупредительных
плакатов и
сигнализации,
подбор кадров
с учетом профессиональных
особенностей
и т.д.
При эксплуатации
электрооборудования
должны соблюдаться
следующие меры:
К работе на
электроустановках
допускаются
люди, прошедшие
инструктаж
и сдавшие зачет
или экзамен
по технике
безопасности,
причисленные
к III группе по
технике безопасности,
с применением
в случае необходимости
в соответствии
с видом работ
индивидуальных
защитных средств.
Допуск к работе
осуществляет
лицо из оперативного
персонала,
ответственное
за электробезопасность
в данном отделе,
имеющее квалификационную
группу не ниже
IV по распоряжению.
Ограждение
токоведущих
частей электрооборудования.
Для предупреждения
возможности
прикосновения
голые и изолированные
токоведущие
части закрываются
постоянными
или временными
ограждениями.
В лаборатории
(отделе) допускается
установка
электроприборов
только в закрытом
исполнении.
Электропроводка,
используемая
для канализации
электроэнергии,
должна выполняться
с соблюдением
правил ПУЭ.
При монтаже
электропроводок
надо уделить
особое внимание
надежности
соединений.
При наладке
электрооборудования
необходимо
иметь инструменты
только с изолированными
ручками.
Необходимо
выполнять
контроль изоляции
электропроводки
не реже 1 раза
в 6 месяцев.
Контроль изоляции
сводится к
измерению
сопротивлений
изоляции. Оно
не должно превышать
допустимых
значений. (таблица
1.8.39 [6]).
Электрооборудование,
вводимое в
эксплуатацию,
должно быть
подвергнуто
приемо-сдаточным
испытаниям
в соответствии
с главой 1.8. Заключение
о пригодности
оборудования
к эксплуатации
дается на основании
рассмотрения
результатов
всех испытаний.
(1.8.4)
Заключение.
Целью данного
дипломного
проекта является
создание программы
для ПЭВМ. Как
уже отмечалось,
одним из наиболее
опасным фактором
в работе с ПЭВМ
является повышенный
уровень напряжения
в электрической
сети. Поэтому
в данном разделе
«Охрана труда
и экология»
были рассмотрены
требования
электробезопасности
на рабочем
месте программиста.
В работе производился
расчет защитного
зануления
электрооборудования
как защитной
меры, рассмотрен
пример схемы
прибора защитного
отключения,
подходящего
для данной
сети, перечислены
основные
организационные
меры электробезопасности
и требования
предъявляемые
к персоналу.
В результате
проектирования
зануления был
определен ток
однофазного
короткого
замыкания,
напряжение
прикосновения.
В качестве
аппарата защиты
был выбран
предохранитель
ПР-2 с характеристиками,
обеспечивающими
необходимое
время срабатывания
защиты.
Список
литературы.
Долин П.А.
«Основы техники
безопасности
в электроустановках.»,
М., Энергоатомиздат,
1984г.
Белорусов
Н.И., Саакян А.Е.
и др. Справочник
«Электрические
кабели, провода
и шнуры», М.,
Энергоатомиздат,
1987г.
Князевский
Б.А., Либкин Б.С.
«Электроснабжение
промышленных
предприятий»,
М., Энергия, 1976г.
Мотузко Ф.Я.
«Защитные
устройства
в электроустановках»,
М., Энергия, 1973г.
Ревякин А.И.,
Кашолкин Б.И.,
«Электробезопасность
и противопожарная
защита в
электроустановках»,
М., Энергия, 1980г.
«Правила
устройства
электроустановок»,
М., Энергоатомиздат,
1990г.
«Правила
эксплуатации
электроустановок
потребителей»,
М., Энергоатомиздат,
1992г.
Кузнецов
Б.В., «Электробезопасность
при эксплуатации
электроустановок»,
Минск, «Беларусь»,
1987г.
Мотузко Ф.Я.
«Охрана труда»,
М., Высшая школа,
1975г.
Система
стандартов
безопасности
труда. Госкомитет
по стандартам.
ГОСТ 12.1.038-82 «Предельно
допустимые
значения напряжения
прикосновения
и токов.», М.,
1983г.
Долин П.А.
Справочник
по электробезопасности.
М., Энергоатомиздат,
1984г.
Методические
указания по
выполнению
раздела «Охрана
труда и экологии»
в дипломных
проектах. Вопросы
электробезопасности.
Москва, МИРЭА,
1987г.