Дипломная работа.
Тема: "Перенос базы данных на WEB-сервер"
Сдавался: СПбГЭТУ(бывший ЛЭТИ), кафедра МО ЭВМ, 15.02.2000
Оценка: "отлично"
Выбор
темы для дипломного
проектирования.
Выбор темы
для дипломного
проектирования,
на мой взгляд,
достаточно
сложная вещь.
В дипломной
работе требуется
проявить
самостоятельность
с одной стороны
и уровень знаний
с другой. Но
помимо этого
хотелось осветить
проблему достаточно
интересную
и новую, поэтому
я выбрал тему
диплома связанную
с технологиями
Internet.
Internet
развивается
довольно
стремительно.
Быстро растет
количество
изданий, посвященных
Сети, что предвещает
широкое ее
распространение
даже в далеких
от техники
областях. Internet
превращается
из большой
игрушки для
интеллектуалов
в полноценный
источник
всевозможной
полезной информации
для всех. Процессы
развития глобальных
информационно-коммуникационных
технологий
очень динамичны
в настоящее
время, а их
возможности
для общества
и экономики
еще только
начинают масштабно
использоваться.
Еще два-три
года назад
Internet
рассматривался
преимущественно
как гигантская
библиотека
и главной его
задачей считалась
помощь в поиске
нужной информации
и организация
доступа к ней.
В настоящий
"коммуникационный"
этап своего
развития главной
задачей сети
Internet
является помощь
в поиске желательных
партнеров и
предоставление
средств для
организации
с ними нужного
вида коммуникаций
с необходимой
интенсивностью.
Результаты
последних
исследований
показали, что
использование
Internet-технологий
может принести
реальную экономию
и прибыль. Ожидается
существенный
рост увеличения
объемов Internet-коммерции,
особенно в
таких областях,
как путешествия,
розничная
торговля, финансы,
тематическая
реклама, а также
в компьютерном
секторе. В мире
накоплено
огромное количество
информации
по различным
вопросам. Чаще
всего эта информация
хранится в
базах данных
(БД). Чтобы опубликовать
её в Сети приходилось
экспортировать
БД в HTML-документы,
что требовало
больших затрат
и усложняло
поиск информации.
Сегодня имеется
большой опыт
подобных работ.
Практически
любой пользователь
Сети не раз
сталкивался
с подобными
БД. Например,
главное в работе
популярного
поискового
сервера Yahoo
(адрес- http::\\www.yahoo.com)
- это запросы
к базе данных
WWW-сервера
по ключевым
словам. Ответ
сервера - список
гипертекстовых
ссылок на найденные
в Сети страницы,
содержащие
нужную информацию.
Именно сегодня
проблема
Web-интерфейса
к БД как никогда
актуальна.
Разработка
технического
задания на
дипломное
проектирование.
Работая
в фирме «Телефонная
Коммерческая
Служба Санкт-Петербурга
008» передо мною,
было поставлена
задача:
Перенести
базу данных
по клиентам
фирмы с сервера
в локальной
сети телефонной
справочной
службы фирмы
на её WEB-сервер.
Выбрать
способ реализации.
Сделать
выбор между
доступными
на сегодняшний
день серверами
баз данных,
для дальнейшей
реализации,
на его основе,
базы данных
«Телефонной
Коммерческой
Службы Санкт-Петербурга
008».
Сделать
выбор между
способами
доступа к базе
данных.
Осуществить
разработку
доступа к базе
данных фирмы
с помощью
Internet-браузера.
Выбор
методов и средств
решения.
Выбор
сервера баз
данных.
В
данном разделе
требуется
определить
с помощью каких
методов и средств
решения можно
осуществить
реализацию
проекта. Сразу
надо сказать,
что средств
решения этой
задачи на сегодняшний
день достаточно
много, но практически
всегда всё
зависит от
количества
ресурсов
предоставляемых
для решения
– типом и характеристиками
сервера, операционной
системой и т.д.
Сразу надо
сказать, что
компьютер,
выделенный
под WEB-сервер
достаточно
мощный (Pentium
II
- 300Мг, 128Мб. оперативной
памяти, SCSI
– диск). На нём
установлена
операционная
система Microsoft
Windows
NT
4.0, так же установлен
WEB-сервер
Internet
Information
Server.
Доступная
потребителю
информация
о самих системах,
операционных
системах, программном
обеспечении
инфраструктуры
(СУБД и мониторы
обработки
транзакций)
как правило,
носит очень
общий характер.
Структура
аппаратных
средств, на
базе которых
работают программные
системы, стала
настолько
сложной, что
эксперты в
одной области
редко являются
таковыми в
другой.
Информация
о реальном
использовании
систем редко
является точной.
Более того,
пользователи
всегда находят
новые способы
использования
вычислительных
систем как
только становятся
доступными
новые возможности.
При стольких
неопределенностях
просто удивительно,
что многие
конфигурации
систем работают
достаточно
хорошо. Оценка
конфигурации
все еще остается
некоторым видом
искусства, но
к ней можно
подойти с научных
позиций. Намного
проще решить,
что определенная
конфигурация
не сможет
обрабатывать
определенные
виды нагрузки,
чем определить
с уверенностью,
что нагрузка
может обрабатываться
внутри определенных
ограничений
производительности.
Более того,
реальное
использование
систем показывает,
что имеет место
тенденция
заполнения
всех доступных
ресурсов. Как
следствие,
системы, даже
имеющие некоторые
избыточные
ресурсы, со
временем не
будут воспринимать
дополнительную
нагрузку.
Следует
отметить, что
выбор той или
иной аппаратной
платформы и
конфигурации
определяется
и рядом общих
требований,
которые предъявляются
к характеристикам
современных
вычислительных
систем.
К ним
относятся:
отношение
стоимость/производительность;
надежность
и отказоустойчивость;
масштабируемость;
совместимость
и мобильность
программного
обеспечения.
Уже
довольно давно
развитые коммерческие
СУБД основываются
на архитектуре
"клиент-сервер".
При этой организации
наиболее трудоемкие
операции над
базами данных
выполняются
на выделенном
компьютере-сервере,
который должен
быть достаточно
мощным и обладать
соответствующим
набором ресурсов
основной и
внешней памяти.
До поры серверная
часть СУБД
обладала простой
организацией:
запросы, поступающие
из клиентских
частей системы,
обрабатывались
последовательно
с небольшой
оптимизацией
для совмещения
процессорной
работы с работой
устройств
внешней памяти.
Однако с появлением
на рынке мультипроцессорных
симметричных
аппаратных
архитектур,
производители
СУБД были вынуждены
пересмотреть
организацию
своих серверов,
допустив в них
внутреннюю
параллельность.
Internet
действительно
неожиданно
бурно ворвался
в устоявшуюся
жизнь разработчиков
клиент-серверных
приложений.
Однако первоначальный
шок довольно
быстро прошел,
как только
наступило
осознание
нехитрого в
общем-то факта,
что структура
Internet/Intranet
приложений
имеет много
общего с традиционной
платформой
"клиент-сервер".
Правильнее
говоря, World Wide Web (WWW)
также основывается
на клиент-серверной
архитектуре.
В самом деле,
Web-браузер является
типичным клиентским
front-end'ом, основное
отличие которого
от клиентских
мест, построенных
с помощью Visual C++,
Visual Basic, Visual FoxPro и других
средств разработки,
состоит в более
гибко настраиваемой
функциональности,
которая может
определяться
даже во время
выполнения
программы. При
этом не требуется
ни перекомпиляции,
ни переустановки
модулей, что
уже само по
себе является
нетривиальной
задачей в больших
и сложных
клиент-серверных
системах масштаба
корпорации.
Правда, первоначально
браузеры
использовались
только как
средства
форматирования
статического
текста. Однако
активно развивающийся
в Internet бизнес вскоре
перестал
довольствоваться
простой публикацией
рекламы предприятия
и справочной
информации
о его деятельности.
Например, клиент
имел полное
право хотеть
выбрать из
рекламного
проспекта фирмы
понравившиеся
ему образцы
и совершить
покупку. Подобно
типичному
интерфейсу
клиентского
приложения
на VB, VFP и т.д., сценарий
работы предполагал
заполнение
клиентом некоторой
формы, населенной,
вообще говоря,
различными
элементами
управления,
отправку
соответствующего
запроса на
сервер и прием
результатов
обработки.
Таким образом,
требования
бизнеса выдвинули
на первый план
принципы
динамического
взаимодействия
браузера и
Web-сервера внутри
сессии, что
заставило
задуматься
как об активной
роли браузера,
так и о расширении
функциональности
сервера по
сравнению с
простым хранением
и пересылкой
HTML-документов.
Многие
фирмы-производители
программных
продуктов
выпускают или
разрабатывают
средства публикации
баз данных в
Internet-сетях.
Основные функции
таких программных
продуктов
данного вида
таковы:
обеспечить
отображение
интерфейса
пользователя
в формате HTML
для отображения
программой
просмотра
клиента, в частности
Internet-броузерами.
обеспечить
формирование
запросов к
базе данных
наиболее простыми
для неподготовленного
пользователя
средствами.
обеспечить
аутентификацию
пользователя
(для разграничения
доступа).
обеспечить
обработку
запроса и возврат
результата
в HTML
формате для
отображения
программой
просмотра
пользователя.
При
этом необходимо
помнить о защите
передаваемой
по Сети информации
и о привлекательности
и понятности
интерфейса.
Для
серийно выпускаемых
программных
продуктов
данного типа
характерны
высокая стоимость
самого программного
обеспечения
(ПО), аппаратной
платформы,
самой СУБД
(насколько мне
известно, ПО
для связи с WWW
пока не включается
в поставку
СУБД). К достоинствам
можно отнести
хорошую
документированность,
наличие технической
поддержки,
низкую стоимость
дальнейших
обновлений
программного
обеспечения.
Хотя в последнее
время начинают
появляться
программы
такого типа
для «настольных»
СУБД типа Visual
FoxPro,
Paradox
и т.д. Но здесь
другая проблема
- при низкой
стоимости
(некоторое ПО
можно получить
по Сети бесплатно
- нужно лишь
иметь СУБД)
отсутствует
мощность и
гибкость. Такое
ПО годится
разве что для
публикации
небольших по
объёму и несложных
баз данных.
Можно
упомянуть
следующие СУБД:
SQL-server
фирмы Microsoft
(требует мощного
сервера баз
данных под
управлением
ОС Microsoft
Windows
NT
server).
Sybase
System
фирмы Sybase
(требует мощного
UNIX-
сервера).
Informix
фирмы Informix
Software
(также требует
мощного UNIX-
сервера).
Progress
фирмы Progress
Software
(работает на
той же аппаратной
платформе, что
и два предыдущих).
InterBase
фирмы Borland
(есть вариант
для Windows
NT
и для UNIX).
Кроме
вышеперечисленных
достоинств
можно также
отметить хорошую
масштабирумость
(наращиваемость),
устойчивость
в работе, защиту
от несанкционированного
доступа и мощность
этих программных
продуктов. Всё
это ПО, как мне
кажется, очень
хорошо подходит
для работы с
крупными проектами
в области баз
данных.
Например,
в последнее
время, всё чаще
упоминают
Intranet
(«внутренняя»
Сеть). Это крупные
корпоративные
вычислительные
сети, основанные
на технологиях
Internet,
использующие
те же протоколы,
форматы данных
и т.д. имеющие
или не имеющие
выход глобальную
сеть Internet.
Достоинства
Intranet
в том, что не
надо переучивать
персонал при
переходе на
новое ПО (можно,
в принципе,
оставить старые
интерфейсы),
так как научив
один раз человека
пользоваться
Internet’
ом, можно легко
обучить его
работе с ПО
предприятия
- для отображения
информации
можно воспользоваться
теми же браузерами.
К общим чертам
вышеперечисленных
программных
продуктов можно
отнести поддержку
стандартного
языка запросов
к базам данных
SQL,
что облегчает
в случае надобности
переход от
одной СУБД к
другой, практическое
отсутствие
ограничений
на размеры
файлов баз
данных.
Оригинальная
версия SQL
– это интерпретируемый
язык, предназначенный
для выполнения
операций над
базами данных.
Язык SQL
был создан в
начале 70 х как
интерфейс для
взаимодействия
с базами данных,
основанными
на новой для
того времени
реляционной
теории. Реальные
приложения
обычно написаны
на других языках,
генерирующих
код на языке
SQL
и передающих
их в СУБД в виде
текста в формате
ASCII.
Нужно отметить
также, что
практически
все реальные
реляционные
(и не только
реляционные)
системы помимо
реализации
стандарта ANSI
SQL,
известного
сейчас в последней
редакции под
именем SQL2
(или SQL-92),
включают в себя
дополнительные
расширения,
например, поддержка
архитектуры
клиент-сервер
или средства
разработки
приложений.
Как говорилось
выше, выбор
реализации
того или иного
решения поставленной
задачи сопряжен,
прежде всего,
с техническими
показателями
компьютера-сервера,
а так же с операционной
системой,
установленной
на нём.
Microsoft SQL Server 7.0 входит
в состав семейства
Microsoft BackOffice, объединяющего
пять серверных
приложений,
разработанных
для совместного
функционирования
в качестве
интегрированной
системы. Она
позволяет
пользователям
повысить
производительность
процесса принятия
решений средствами
систем, базирующихся
на архитектуре
клиент-сервер.
Кроме того,
Microsoft SQL Server 7.0 завершает
линию средств
разработки,
включающих
Microsoft Access, Visual FoxPro®, Visual Basic и Visual
C++™.
Расширенные
возможности
масштабирования
и высокая
производительность.
Особое
внимание, которое
было уделено
повышению
производительности
СУБД, позволило
повысить скорость
выполнения
некоторых
операций почти
на 400% на многопроцессорных
компьютерах.
Это достигается
активным
использованием
многопроцеcсорной
архитектуры
компьютера
и многопоточной
архитектуры
операционной
системы. Среди
операций,
выполняющихся
параллельно,
можно назвать
сканирование
таблиц, загрузку,
создание/восстановление
страховочной
копии. Все это
позволяет
обеспечить
высокопроизводительную
работу с большими
и очень большими
базами данных.
Поддержка
очень больших
баз данных и
съемных носителей.
Для версии
4.21а очень большой
считалась база
данных размером
10-15 Гб (хотя некоторые
организации,
например, Sprint,
работали с
базами данных
размером 60 Гб
и более). Высокоскоростная
параллельная
обработка
делает возможной
поддержку
работы с базами
данных размером
100 Гб и более на
соответствующим
образом конфигурированных
системах. Не
только процесс
создания страховочных
копий выполняется
быстрее, но и
такие операции,
как проверка
целостности
базы данных
(выполняется
командой DBCC),
сильно выигрывают
от использования
параллельного
сканирования
и увеличенных
блоков ввода/вывода.
Возможность
сохранения
в страховочной
копии (восстановления
из копии) индивидуальных
таблиц позволяет
сократить
время, необходимое
на сохранение
(восстановление)
отдельных
таблиц базы
данных. Поддержка
распространения
баз данных на
съемных носителях
(таких как CD-ROM)
позволяет
выпускать
различного
рода справочники
или информационные
материалы.
Интересно
отметить, что
гибкость SQL Server
проявляется
и при работе
с очень маленькими
объемами информации.
Так, для того
чтобы базу
данных можно
было сохранить
на дискете, ее
минимальный
размер снижен
до 1 Мб.
Расширение
возможностей
языка и программного
доступа.
Существующая
версия SQL Server снабжена
мощным языком
программирования
-Transact-SQL, позволяющим
создавать
сложную логику
триггеров и
хранимых процедур.
В новой версии
язык значительно
расширен, теперь
он соответствует
стандарту
ANSI-92, и программисты
получили новые
возможности
(такие как новые,
соответствующие
ANSI-стандарту,
типы данных
и соответствующая
стандарту ANSI
поддержка
декларативной
целостности
данных). Помимо
перечисленных
возможностей,
программист
может воспользоваться
генератором,
автоматически
создающим
уникальные
значения для
ключевых полей
таблицы, возможностью
передавать
идентификаторы
и данные типа
TEXT и IMAGE как параметры
хранимым процедурам
и многое другое.
Использование
хранимых процедур,
которые запускаются
автоматически
при каждом
старте SQL Server, позволяет
создавать
системы, способные
выполнять
различного
рода задания
без участия
администратора.
Наиболее же
интересным
нововведением
являются
скроллируемые,
двунаправленные
курсоры. Курсоры
SQL Server поддерживают
все режимы,
определенные
расширенными
требованиями
ANSI, а также и ODBC
семантику; они
совместимы
с существующими
курсорами,
поддерживаемыми
API в DB-Library.
Производительность
и масштабируемость.
Microsoft SQL Server 7.0 имеет
параллельную
архитектуру,
интенсивно
использующую
много поточность
операционной
системы для
обеспечения
высокой производительности
и масштабируемости
на многопроцессорных
системах. Все
управление
задачами SQL Server
организовано
вытесняющим
для повышения
надежности
и изолирования
возможных
сбоев. За счет
динамического
распределения
нагрузки на
процессоры
SQL Server достигает
автоматической
балансировки
загрузки всех
ЦП компьютера.
Microsoft называет
это "симметричной
архитектурой
сервера".
Преимущества
симметричной
архитектуры.
Симметричная
архитектура
Microsoft SQL Server предоставляет
следующие
преимущества:
- снижает
сложность
системы.
SQL Server не дублирует
службы операционной
системы (такие
как диспетчирование,
распределение
памяти, управление
очередями), что
делает архитектуру
системы более
эффективной
и стабильной;
- повышает
производительность
.
SQL Server способен
обеспечить
высокую скорость
выполнения
транзакций
и обладает
высокой пропускной
способностью
на микропроцессорных
системах, даже
при одновременной
работе сотен
пользователей;
- адаптируется
к росту нагрузки.
Нагрузка
на SQL Server динамически
распределяется
по нескольким
ЦП, что повышает
масштабируемость
на симметричных
многопроцессорных
системах.
повышает
надежность
Задачи
пользователя
исполняются
в самостоятельных
потоках, и при
необходимости
одна задача
принудительно
завершается,
не оказывая
влияния на
выполнение
остальных.
Например, SQL Server
способен прервать
"спящий" процесс
без того, чтобы
это оказало
влияние на
работу всей
системы. Ни
одна задача
не может "выйти
из-под контроля".
Усовершенствования,
связанные с
параллельной
обработкой
данных в SQL Server 7.0 .
У SQL Server 7.0 Microsoft еще
более расширила
возможности
параллельной
обработки
симметричной
архитектуры
сервера. За
счет параллельного
выполнения
широкого диапазона
внутренних
функций СУБД
с использованием
множественных
потоков операционной
системы при
работе на много
процессорных
системах резко
возрастает
производительность
и масштабируемость
многих операций
(таких как
определенные
типы запросов,
сканирование
таблиц, создание
индексов,
создание/восстановление
страховочных
копий, проверка
целостности
базы данных
и т.д.).
Параллельное
сканирование
и асинхронное
опережающее
чтение.
Параллельное
сканирование
и асинхронное
опережающее
чтение повышает
на 40 - 400% скорость
выполнения
некоторых типов
запросов и
других операций
над базой данных
в многопроцессорных
системах. Повышение
производительности
достигается
за счет использования
SQL Server 7.0 множественных
потоков операционной
системы и алгоритмов
определения
следующего
блока данных,
необходимых
для вывода в
кэш. Эта операция
типична для
длительного
запроса с
вычислениями
или операции
создания отчета.
Подобная технология
обеспечивает
резкое повышение
производительности
для любой операции,
требующей
просмотра
таблиц, например,
SELECT, UPDATE и DELETE с необходимостью
поиска, CREATE INDEX, DBCC,
DUMP/LOAD и т.п.
Параллельная
загрузка.
При работе
с новой версией
SQL Server можно запускать
несколько
параллельно
работающих
копий BCP или SQL
Enterprise Manager и выполнять
параллельные
перекрывающиеся
операции загрузки
данных в SQL Server.
Подобные возможности
оказываются
особенно полезными
при необходимости
массивного
копирования
данных в ограниченные
сроки.
И
конечно же
безопасность:
Улучшенная
интеграция
с безопасностью
NT ;
Аутентификация
средствами
NT (как текущий
пользователь
- без пароля,
как другой -
login+pwd) ;
Mixed (возможна
аутентификация
средствами
SQL Srv) ;
Полная
поддержка
пользователей,
групп и ролей
;
Роли могут
быть приписаны
пользователям
и группам NT, а
также пользователям
Sphinx ;
Роли могут
быть вложены
;
Прикладные
роли для 3-уровневых
систем ;
Позволяют
назначать
права при доступе
через приложение,
а не isql ;
Гибкая
гранулярность
прав и системных
ролей ;
Предопределенные
роли
ServerAdmin, SecurityOfficer, ... ;
Поддержка
делегирования
в NT 4.0 ;
На 2-м сервере
не как удаленный
пользователь,
а под тем же
именем ;
Простое
и мощное
администрирование.
Потому
было принято
решение установить
сервером базы
данных – Microsoft
SQL
Server
7.0.
Выбор
методов доступа
к базе данных.
Далее
необходимо
сравнить способы
реализации
доступа к базе
данных. Схематически
можно представить
взаимодействие
базы данных
и WEB-сервера
так:
3.2.1 CGI – Common Gateway
Interface.
Первым
способом стали
приложения
Common Gateway Interface (CGI), поскольку
спецификация
CGI позволяет
браузеру вызвать
тот или иной
исполняемый
модуль или
скрипт на
Web-сервере, который
мог обратиться
с запросом к
базе данных,
построить в
HTML-кодах страницу
результатов
и передать ее
обратно Web-серверу,
который же, в
свою очередь,
отсылал результаты
браузеру.
CGI-приложения
могут содержать
вызовы других
программных
(написанных,
например, на
С++) или командных
(.bat, .cmd) файлов. С
помощью CGI-cкриптов,
а точнее на
языке PERL (Practical Extraction and
Reporting Language), построено
немало интерактивных
Web-приложений.
К сожалению,
каждый такой
скрипт исполняется
как иной, нежели
Web-сервер, процесс,
что быстро
"съедает" ресурсы
даже достаточно
"навороченной"
по сегодняшним
меркам машины,
особенно при
большом количестве
заходов на
сервер.
3.2.2 PHP - Personal Home Page Tools.
Модуль
PHP начал жизнь
как простая
небольшая CGI
оболочка, написанная
на Perl. Чтобы избавиться
от значительных
непроизводительных
затрат из-за
необходимости
запуска Perl при
каждом обращении
к серверу в
стандартном
обращении CGI.
Первоначально
использовался
для маленьких
Internet-страниц.
Позднее был
встроен инструмент
для включения
SQL
в WEB-страницы.
Это была CGI-оболочка,
которая анализирует
запросы SQL и
облегчает
создание форм
и таблиц, основанных
на этих запросах.
PHP/FI
версии 2.0 - полная
перезапись
из этих двух
пакетов, объединенных
в одиночную
программу. Это
теперь развилось
по сути в простой
язык программирования,
внедренный
внутрь HTML файлов.
PHP/FI сегодня используется
больше для
создания целых
WEB
серверов, чем
для малых домашних
страниц. Модуль
устраняет
потребность
в многочисленных
малых cgi программах
на Perl, позволяя
поместить
простые скрипт-программы
непосредственно
в ваши HTML файлы.
Пакет также
упрощает управление
большими WEB
серверами,
помещая все
компоненты
WEB
страницы в
одиночном файле
HTML.
Встроенная
поддержка
различных баз
данных делает
тривиальной
разработку
WEB
страниц с доступом
к базам данных.
Многие находят,
что иметь дело
с внедренным
в html-документы
языком намного
проще, чем создавать
отдельные HTML
и CGI файлы.
3.2.3
ISAPI
– приложения.
3.2.3.1
dBWeb.
Помимо
исполнения
CGI-скриптов,
Microsoft Internet Information Server (MS IIS) предоставляет
разработчикам
возможность
создания с
помощью соответствующего
API (ISAPI) приложений
в виде dll, запуск
которых происходит
в ответ на команду
или выбор линка
на Web-странице.
Каждое такое
приложение
выполняется
в адресном
пространстве
Web-сервера, что,
естественно,
повышает скорость
работы и существенно
экономит машинные
ресурсы. В
зависимости
от сложности
сайта и приложений,
dll могут быть
предзагружены
одновременно
с запуском
сервера, либо
подгружаться/выгружаться
из памяти по
мере необходимости.
К наиболее
известным
средствам
разработки
приложений
на основе ISAPI
относятся
входящий в
состав MS IIS Internet Database
Connector (IDC), а также свободно
распространяемый
dbWeb.
Microsoft dbWeb представляет
собой шлюз
между 32-битными
ODBC-ресурсами,
в качестве
которых могут
выступать,
например, Microsoft
SQL Server, Microsoft Access, Microsoft Visual FoxPro, Oracle и
т.д., и MS IIS. dbWeb предусматривает
создание схемы,
содержащей
описание данных
и связанных
с ними Web-страниц.
Он поддерживает
исполнение
запросов в
реальном режиме
времени на
основе "pull"-модели
публикации,
позволяя тем
самым создавать
активные
Web-страницы.
Рис.
1 Структура
dbWeb.
Microsoft dbWeb структурно
состоит из двух
основных компонент:
dbWeb Service и dbWeb Administrator. dbWeb Service является
типичным
ISAPI-приложением,
которое обрабатывает
пользовательские
запросы, направляемые
посетителем
страницы через
браузер, и управляет
соединениями
между браузером,
ODBC-ресурсом и
IIS. К функциям
dbWeb Administrator относится
создание
HTML-страниц, содержащих
результаты
выполнения
запросов на
основе уже
упоминавшихся
схем, с помощью
которых осуществляется
управление
публикуемыми
данными. Схемы
определяют
сам запрос и
структуру
страниц. При
этом не требуется
знания HTML или
ISAPI, так как в состав
dbWeb Administrator входит
интерактивный
мастер-построитель
схем (Schema Wizard), который
в традиционной
для любой
программы-мастера
манере позволяет
задать поля
поиска по методу
Query-by-Example (QBE), выбрать
поля для отображения
в таблице страницы
результатов
и определить
переходы из
списка записей
в отдельные
страницы, содержащие
развернутую
информацию
по текущей
записи. Настройкой
соответствующих
свойств можно
разрешать или
запрещать
операции вставки,
удаления и
редактирования.
Для проверки
прав пользователя
используется
система безопасности
той СУБД, к которой
происходит
доступ. dbWeb имеет
в своем составе
широкий спектр
шаблонов страниц,
которые при
необходимости
могут быть
легко откорректированы
и настроены
разработчиком
для более полного
соответствия
его задачам.
Таким образом,
dbWeb не является
конечным
пользовательским
приложением.
Скорее его
можно охарактеризовать
как достаточно
легкий в использовании
инструментарий
разработки,
который, как
всякий мастер,
не поддерживает
языка программирования.
Тем не менее,
эта программа
успешно справляется
с автоматизацией
большинства
рутинных операций
по организации
соединений
и публикации
данных из БД
и покрывает,
по разным оценкам,
порядка 40-60% потребностей
бизнеса
среднестатистической
фирмы при организации
доступа к своим
источникам
данных через
Internet.
3.2.3.2
IDC.
IDC является
другим примером
достаточно
давно и успешно
используемого
ISAPI-приложения.
Он входит в
состав MS IIS. С помощью
вызовов функций
ODBC API IDC обеспечивает
прямую связь
между полями
HTML-формы и соответствующим
ODBC-достижимым
источником
данных, например,
базой данных
MS SQL Server, без необходимости
написания
замысловатых
CGI-скриптов. Схема
работы IDC:
Рис.2
Схема работы
IDC.
Для доступа
к данным и публикации
на Web IDC использует
файлы двух
типов - .idc и .htx. Файл
с расширением
idc содержит всю
необходимую
информацию
о соединении
с источником
данных, текст
запроса, а также
ссылку на
соответствующий
htx-файл. Файл с
расширением
htx служит шаблоном
страницы, на
которой будут
опубликованы
данные из базы,
а также элементы
оформления
в виде статического
текста, графики,
видео и т.п. MS IIS
распознает
расширение
.idc как вызов
httpodbc.dll, которая
считывает
http-заголовки
из управляющего
блока ISAPI для
определения
параметров
запроса. Httpodbc.dll
читает и разбирает
idc-файл, указанный
в URL. Имя источника,
имя пользователя,
пароль и пр.
используются
для подключения
к соответствующему
ресурсу ODBC, после
чего httpodbc передает
на выполнение
SQL-запрос и получает
результаты.
Результаты
используются
для наполнения
заготовки в
виде htx-файла,
после чего
полученный
HTML-документ MS IIS
передает браузеру.
3.2.3.3
ADO – Active Data Objects.
Active
Data Objects. Когда
речь заходит
о компонентах
ActiveX, как правило,
неявно подразумевается
клиентская
часть приложения.
Microsoft Active Server Pages (ASP) - активные
серверные
страницы-
представляют
собой инструмент
для эффективной
разработки
серверных
Web-приложений,
интегрирующих
в своем составе
HTML-код, VBScript и компоненты
ActiveX. Это означает,
что в уже существующие
наработки легко
могут быть
встроены фрагменты
кода на VBScript или
JavaScript, а также вызовы
соответствующих
объектов ActiveX.
Как, наверное,
известно, VBScript -
это сужение
хорошо знакомого
языка программирования
Visual Basic на область
создания Web-страниц.
Основным идейным
отличием VBScript от
VB, на мой субъективный
взгляд, служит
то, что VBScript не
содержит операторов
файлового
ввода-вывода
и вообще средств
прямого доступа
к операционной
системе (напрашиваются
параллели, если
Java сопоставить
с С/С++, не правда
ли). Кроме этого,
в VBScript существует
только один
тип переменных
- variant, отсутствуют
декларативные
константы и
т.п. Наличие
привычного
синтаксиса
языка высокого
уровня существенно
упрощает создание
HTML-страниц. Кроме
этого, в состав
среды активных
серверных
страниц (ASP Framework)
входят следующие
5 основных встроенных
объектов.
Application (приложение)
- для разделения
информации
между всеми
пользователями
данного приложения.
Request (запрос)
- для получения
тех значений,
которые броузер
клиента передает
на сервер по
HTTP-запросу, т.е.,
грубо говоря,
для получения
информации
о пользователе
или от пользователя
Response (ответ)
- для передачи
информации
клиенту.
Server (сервер)
- предоставляет
возможность
обращения к
методам и свойствам
сервера для
управления
средой исполнения
ASP.
Session (сеанс)
- для хранения
информации,
относящейся
к данной пользовательской
сессии.
Помимо
базовых объектов,
ASP поддерживают
многочисленные
компоненты
ActiveX, которые упрощают
создание и
значительно
повышают
функциональность
активных Web-страниц.
К ним относятся
различные
элементы управления,
компоненты,
создающие
содержание
приложения,
компоненты
ввода/вывода
в файл и многие
другие. Но нас
в первую очередь
будут интересовать
компоненты,
позволяющие
организовать
доступ к базам
данных, или
Active Data Objects (ADO). В отличие
от хорошо известных
Data Access Objects (DAO) или Remote Data Objects
(RDO) ADO имеют менее
иерархически
строгую структуру
и потому более
удобны при
работе с базами
данных.
Рис.3
Структура DAO
и ADO.
ADO являются
универсальным
инструментом
доступа к данным.
Вы можете без
изменений
использовать
интерфейс ADO
из данного
примера при
работе с базами
данных на VB, Visual
FoxPro и т.д. Наконец,
с помощью ADO, в
свою очередь,
могут быть
построены
пользовательские
компоненты,
для обращения
к серверу баз
данных как со
стороны "толстого"
(Win32), так и со стороны
тонкого (Internet Browser)
клиента. Функции
обеспечения
целостности
транзакций,
сервисы безопасности
и согласованной
работы компонент
в распределенном
приложении
может взять
на себя Microsoft Transaction
Server.
ASP
(Active
Server
Page)
– Активные
серверные
страницы.
Особое
положение среди
средств разработки
занимают активные
серверные
страницы (Active
Server Pages или ASP). Они
предназначены
для организации
доступа к
WEB-серверу,
клиентов,
располагающих
только броузером.
ASP представляют
собой набор
интерпретируемых
сервером MS
IIS (Microsoft Internet
Information
Server)
сценариев,
содержащих
разметку HTML и
программный
код на языках
VBScript и Javascript, который
по желанию
разработчика,
может исполняться
либо на сервере,
либо на клиенте.
Это позволяет
в одном ASP-файле
сочетать серверную
и клиентскую
логику. Та часть
кода, которая
исполняется
на сервере,
может использовать
"родные" интерфейсы
для общения
с сервером и
реализации
как базовых,
так и расширенных
функций MAPI. При
этом общение
клиентской
и серверной
частей ASP-приложения
происходит
исключительно
средствами
протокола HTTP.
За поддержание
сессии между
клиентской
и серверной
частями отвечает
Internet Information Server.
Active
Server Pages являются
обычным ISAPI-фильтром,
работающим
в контексте
процесса MS Internet
Information Server, начиная
с версии 3.0. (Технология
ASP доступна и
для других
серверов. Фирмой
Chili!Soft выпускается
пакет Chili!ASP, после
установки
которого сервера
других производителей
начинают "понимать"
ASP – страницы.)
Отличие ASP от
препроцессора
заключается
в возможности
работы с COM-объектами
(в контексте
ASP их называют
Installable components).
Проект
под названием
Denali почти идеально
вписывается
в технологию
"клиент-сервер",
теперь уже не
настолько
популярную.
Хотя, что может
лучше подходить
для Сети, чем
технология
создания приложений
"логически
централизованных
- физически
децентрализованных".
Говоря простым
языком, логически
централизованные
- это распределенные
вычислительные
системы, доступные
и управляемые
из любой точки,
а физическая
децентрализация
- это возможность
расширения,
масштабирования,
повышения
надежности.
В первую
очередь, ASP имеет
достаточно
развитый командный
язык. И даже не
один, а как минимум
два: VBScript и JScript. "Как
минимум", потому
что объектная
модель OLE для
«скриптовых»
машин позволяет
легко встраивать
в среду другие
языки. Поэтому
разработчикам
на Perl или REXX можно
не переучиваться,
а использовать
свой накопленный
опыт. И все же
языком "по
умолчанию"
для ASP является
VBScript, фактически
подмножество
Visual Basic, и в этом, конечно
же, нет ничего
удивительного
- продукт Microsoft
Corporation. JScript, с другой
стороны, - подмножество
Java и так же похож
на С++. И у той, и
другой скрипт-машины
есть как свои
преимущества,
так и недостатки.
Если вкратце,
то JScript все-таки
кажется помощнее
и почти дотягивает
по возможностям
до нескриптовых
языков. Это
далеко не ассемблер,
практически
невозможно
поковыряться
в потрохах у
системы, но, по
всей видимости,
разработчики
ASP посчитали
это дополнительной
защитой от
вторжения
извне.
Само
кодирование
не требует
никаких дополнительных
затрат в виде
специальных
сред разработки.
Поскольку
ASP-файлы имеют
текстовый
формат, они
легко могут
быть модифицированы
для придания
клиентской
и серверной
частям необходимой
функциональности.
Microsoft рекомендует
использовать
MS InterDev, но почти во
всех современных
версиях HTML-редакторов
(например, Allaire
HomeSite) есть поддержка
тегов ASP. Код
"вставляется"
прямо в HTML-текст
в окружении
специального
тега <% ASP-код %>,
после этого
файлу нужно
дать с расширением
.asp, чтобы он был
передан на вход
ASP-фильтра для
переработки
в обычный HTML и
выдачи IIS-серверу,
который уже
и отдаст результат
браузеру. Причем
любому, не имеет
значения, MS IE это,
Netscape Navigator или браузер
"третьего мира".
Главное, чтобы
он понимал
HTML, а это ведь
вообще-то
первостепенная
задача браузера.
Чем не универсальная
платформа, к
которой долго
и упорно стремятся
все? Конечно,
все же есть
отличия в браузерах,
то есть в их
интерпретации
стандартного
HTML. Всем это знакомо:
одни и те же
странички,
написанные
на самом что
ни на есть
стандартнейшем
HTML, смотрятся
иногда совершенно
по-разному в
IE и NN. А вообще ASP
имеет возможность
справиться
и с этой "проблемой".
Просто определяется
тип браузера,
с которым пришли,
и навигация
идет по страницам,
написанным
для этого типа.
Происхождение
одной из труднейших
проблем при
создании
Интернет-приложений
в самой природе
Сети. Это отсутствие
гарантированной
постоянной
связи, и, отсюда,
невозможность
создания непрерывного
канала для
отслеживания
действий конкретного
клиента. Единственный
выход из этой
ситуации - если
клиент при
каждом обращении
будет "представляться".
Именно это и
сделано при
помощи "cookie".
Немало копий
было поломано
по поводу
безопасности,
но на данный
момент, вроде
бы, решили, что
они достаточно
безвредны, если
не считать
нескольких
десятков байт,
съедаемых на
диске. Зато
пользы от них,
как можно увидеть,
гораздо больше.
После старта
сервер выдает
каждому пришедшему
клиенту уникальный
идентификатор
(SessionID) в виде "cookie"
и в течение
сессии может
понимать "кто
- где". ID уникальны
только в период
непрерывной
работы сервера.
Если остановить
и снова перезапустить
сервер, то можно
получить значения
такие же, как
до перезапуска.
Поэтому применять
SessionID в приложениях
в виде уникального
идентификатора
не рекомендуется
- лучше формировать
свои.
Для настройки
сессии можно
использовать
два объекта:
Application и Session, каждый
из которых
имеет по два
обрабатываемых
события OnStart и
OnEnd. Первый клиент,
пришедший на
сервер, вызывает
создание объектов
Application и Session и отработку
для них своих
процедур OnStart.
Каждый последующий
вызывает создание
объекта Session для
себя и отработку
OnStart для своего
объекта. После
ухода клиента
для соответствующего
объекта Session
отрабатывается
процедура
OnEnd, и объект
уничтожается.
С уходом последнего,
кроме того,
вызывается
процедура OnEnd
для объекта
Application, и уничтожается
объект Application. Уход
клиента происходит
либо по тайм-ауту,
период которого
задается в
минутах свойством
Timeout объекта Session (по
умолчанию 30
минут), либо
силовым методом
Abandon того же самого
объекта. Фактически,
объект Session нужен
для персонализации,
то есть хранения
переменных
среды конкретного
клиента, а
Application - для хранения
глобальной
информации
всего приложения.
Процедуры для
обработки
событий OnStart и
OnEnd описываются
в файле Global.asa, который
должен лежать
в корне виртуального
каталога.
Механизм
приема-передачи
данных в ASP реализован
с помощью двух
встроенных
объектов: Request и
Response. Используя
свойства и
методы этих
объектов, можно
добиться настоящей
интерактивности,
единственным
неудобством
остается
необходимость
закачки новой
страницы каждый
раз при исполнении
какого-нибудь
действия. Но
тут не стоит
забывать, что
ASP - это именно
серверная часть
в клиент-серверной
модели, а для
клиентской
части существуют
другие решения.
Как уже
было сказано
выше, COM-объекты
играют важную
роль в жизни
ASP. И самым значимым
среди них является
Database Access. Он обеспечивает
доступ к данным,
используя
ActiveX Data Objects (ADO). Все, что
для этого нужно,
это создать
объект Database Access, указать
ему Data Source Name (DSN) и соединиться
с источником
данных. Так как
используется
ODBC, источник данных
может быть
любым: сегодня
драйверы ODBC
написаны для
всевозможных
вариантов и
не ограничиваются
системами
управления
базами данных.
Более того, с
выходом объектной
файловой системы
(Object File System), которую
Microsoft обещает
продемонстрировать
в NT 5.0, ADO будут способны
управлять
файловой системой
в стиле баз
данных. Как
прямой потомок
Data Access Objects (DAO) и Remote Data Objects (RDO), модель
ADO очень похожа
на своих предшественников,
вплоть до того,
что программист,
имеющий опыт
работы с DAO или
RDO, способен
практически
сразу использовать
все возможности
ADO. Разработчики
утверждают,
что внешне
единственное
отличие от
старых моделей
- это только
ускорение,
упрощение и
увеличение
надежности
работы приложений,
и представляют
ADO как ядро новой
технологии
универсального
доступа к данным
(Universal Data Access).
Одним из
перспективных
направлений
будет Windows Scripting Host, который
появится в NT
5.0 и Win98. Это одна
из стратегий,
направленных
на снижение
усилий по
администрированию
(ZAW). Действительно,
администраторы
могут удаленно
(из любой точки
Сети) переконфигурировать
системы или
использовать
скрипты для
их автоматической
настройки в
зависимости
от условий.
Microsoft
технологию
ASP продвигает
достаточно
активно. Об
этом говорит
хотя бы то, что
в MS Internet Information Server 4.0 она уже
входит составной
частью, в отличие
от IIS 3.0, где ASP представляли
собой продукт,
который было
нужно инсталлировать
отдельно. Кроме
того, MS Site Server и MS Site Server
Commerce Edition, позиционируемые
как универсальные
инструменты
для строительства
активных WEB-сайтов,
являются теми
же самыми ASP с
огромным набором
специализированных
компонентов.
Выбор
из многих решений
показал, что
наиболее оптимальным
является
использование
ASP.
Это связано
прежде всего
с самой технологией
ASP
модулей. По
сути своей ASP
– это использование
API
Windows
, используется
единое адресное
пространство
для каждого
процесса в
отличии от CGI,
а потому и более
производительно.
Так же не стоит
забывать о том,
что WEB-сервер
компании работает
под управлением
Windows
NT
Server,
а в поставке
Microsoft
IIS
4.0 уже есть встроенный
обработчик
ASP.
Разработка
проекта:
4.1
Перенос базы
данных на Microsoft
SQL
Server.
Перенос
базы данных
компании «ТКС
008» осуществлялся
с локального
сервера в телефонной
службе на WEB-сервер
компании.
Механизм
передачи информации
выглядит следующим
образом:
с сервера
телефонной
службы, с помощью
специально
написанной
программы,
информации
из базы данных
собиралась
в текстовый
файл, причём
для каждой
таблицы существует
отдельный
файл.
далее
эти файлы
доставляются
физически на
компьютер,
установленный,
как WEB-сервер
компании.
Следующим
этапом текстовые
файлы считываются,
программой
написанной
опять же специально,
считывается
каждое поле,
и на основании
этого заноситься
информация
в базу данных
SQL.
Теперь
остановимся
подробнее на
всём механизме
передачи информации.
Первоначально
база данных
клиентов компании
«Телефонная
Коммерческая
Служба 008» была
реализована
на СУБД Btrieve 6.0 , она
работает под
управлением
операционной
системы NetWare
компании Novell.
Для выгрузки
из неё необходимой
информации
о клиентах,
необходимо
было написать
программу для
механического
копирования
содержимого
полей некоторых
таблиц, информация
из которых
требовалась
для переноса
на WEB-сервер.
Такая программа
была написана
на языке Borland Pascal
7.0. Она выгружает
только данные
из таблиц, причем
не все а только
свежие ориентируясь
на даты обновления
записей присутствующие
в базе данных.
Данная программа
механически
записывает
в текстовый
файл поля некоторой
таблицы из базы
данных клиентов,
разделённые
маркером, так
как не все поля
базы данных
являются
фиксированной
длинны. На каждую
таблицу приходиться
свой текстовый
файл с содержимым
её полей. Далее
происходит
доставка этих
файлов на компьютер,
являющийся
WEB-сервером
компании. Они
помещаются
в специально
отведённую
для них директорию,
и программа
обновления
SQL
базы данных,
так же специально
написанная
для этой. Приходящие
несколько
файлов, каждый
из которых
содержит обновления
для одной из
таблиц базы
данных. Программа
открывает эти
файлы в нужной
последовательности.
Читает оттуда
запись за записью.
Ищет соответствующую
запись в БД на
SQL, каждая запись
однозначно
идентифицируется
последовательностью
ключевых полей
- это программа
узнает из первичного
индекса к загружаемой
таблице. Если
запись уже
присутствует
в базе данных
SQL, то она обновляется.
В противном
случае добавляется.
Сама программа
напрямую с
базой «общаться»
не может, поэтому
«общение»
происходит
через альтернативу
ODBC
– BDE
(Borland
Database
Engine).
Информационные
системы, созданные
на основе
классической
архитектуры
клиент/сервер,
называемые
двухзвенными
системами или
системами с
"толстым"
клиентом, состоят
из сервера баз
данных, содержащего
сгенерированные
тем или иным
способом таблицы,
индексы, триггеры
и другие объекты,
реализующие
бизнес-правила
данной информационной
системы, и одного
или нескольких
клиентских
приложений,
предоставляющих
интерфейс
пользователя
и производящих
проверку допустимости
и обработку
данных согласно
содержащимся
в них алгоритмам.
Если говорить
о клиентских
приложениях,
созданных с
помощью Delphi, для
доступа к источникам
данных они
используют
вызовы функций
прикладных
программных
интерфейсов
клиентских
частей соответствующих
серверных СУБД.
Эти вызовы
осуществляются
посредством
использования
библиотеки
Borland Database Engine (BDE). Соответственно
подобное клиентское
приложение
требует наличия
на компьютере
конечного
пользователя
клиентской
части используемой
серверной СУБД
и присутствия
в оперативной
памяти набора
динамически
загружаемых
библиотек как
из клиентской
части, так и из
BDE , таких, как
драйверы баз
данных, библиотеки,
содержащие
функции API клиентских
частей.
Используя
BDE,
можно создать
приложения,
работающие
как с однопользовательскими
базами данных
(БД), так и с серверными
СУБД, такими
как Oracle, Sybase, Informix, Interbase, MS SQL
Server, DB2, а также с
ODBC-источниками.
BDE обеспечивает
для созданных
приложений:
непосредственный
доступ к локальным
базам данных
(dBase, Paradox, текстовые
файлы);
доступ
к SQL-серверам
(Oracle, Sybase, MS SQL Server, InterBase, Informix, DB2) с
помощью драйверов
Borland SQL Links ;
доступ
к любым источникам
данных, имеющим
драйвер ODBC (Open
DataBase Connectivity), например,
к файлам электронных
таблиц (Excel, Lotus 1-2-3),
серверам баз
данных, не имеющим
драйверов SQL
Links (например,
Gupta/Centura);
создание
приложений
клиент-сервер,
использующих
разнородные
данные;
высокую
производительность
при работе с
плоскими таблицами;
использование
SQL (Structured Query Language - язык
запросов к
серверным
СУБД), в том числе
при работе с
локальными
данными;
изоляцию
приложения
от средств
языковой поддержки;
изоляцию
приложения
от конфигурации
системы и сети.
Рис.
4 Связь
приложений
с источниками
данных с помощью
BDE.
BDE
«общается»
с SQL
сервером через
драйверы ODBC.
Следует
обратить внимание
на то, что перед
описанием
ODBC-источника
в файле конфигурации
BDE обязательно
нужно установить
соответствующий
ODBC-драйвер и
описать соответствующий
источник данных
в панели управления
Windows NT, используя
соответствующий
ODBC-администратор.
При этом следует
обратить внимание
на некоторую
терминологическую
неувязку. Дело
в том, что ODBC-драйвер
с точки зрения
BDE, создаваемый
при нажатии
кнопки New ODBC Driver на
странице Drivers
утилиты конфигурации
BDE, на самом деле
представляет
собой указание
не на реальный
ODBC-драйвер, установленный
в панели управления
Windows, а на конкретный
источник данных,
доступ к которому
осуществляется
с помощью реального
ODBC-драйвера (с
точки зрения
панели управления).
А потому рекомендуется
такой порядок
установки при
осуществлении
доступа к
ODBC-источникам
:
Установить
нужный ODBC-драйвер
(и, возможно,
соответствующий
ODBC-администратор
для панели
управления
Windows).
Описать
с помощью
ODBC-администратора
необходимый
источник данных
в панели управления.
Запустить
утилиту конфигурации
BDE и нажать кнопку
New ODBC Driver на странице
Drivers.
Придумать
и ввести имя
так называемого
ODBC-драйвера с
точки зрения
BDE.
Выбрать
"настоящий"
ODBC-драйвер из
установленных
в операционной
системе.
Выбрать
имя источника
данных.
Нажать
OK. В списке драйверов
появится новый
так называемый
ODBC-драйвер (с
точки зрения
BDE).
Перейти
на страницу
Aliases и создать
псевдоним,
связанный со
вновь созданным
драйвером с
точки зрения
BDE.
При работе
с ODBC-источниками
требуется
настройка
следующих
параметров:
Параметр
|
Описание
|
Значение
по умолчанию
|
VERSION
|
Внутренний
параметр BDE
|
1.0
|
TYPE
|
Идентификатор
ODBC-источника
|
FILE
|
DLL
|
Имя
16-разрядной
динамической
библиотеки,
содержащей
драйвер
|
IDODBC16.DLL
|
DLL32
|
Имя
32-разрядной
динамической
библиотеки,
содержащей
драйвер
|
IDODBC32.DLL
|
ODBC
DRIVER
|
ODBC-драйвер
для соединения
с сервером
|
|
DRIVER
FLAGS
|
Внутренний
параметр BDE
|
|
USER
NAME
|
Имя
пользователя
в диалоге ввода
пароля
|
|
ODBS
DSN
|
Имя
источника
данных, описанного
в администраторе
ODBC
|
|
OPEN
MODE
|
Параметр,
определяющий,
в каком режиме
открываются
таблицы - READ/WRITE or
READ ONLY
|
READ/WRITE
|
LANGDRIVER
|
Языковый
драйвер, определяющий
набор символов
и порядок
алфавитной
сортировки
|
'ascii'ANSI
|
SCHEMA
CASHE SIZE
|
Число
таблиц, чья
структура
кэшируется.
Возможные
значения - от
0 до 32
|
8
|
SQLQRYMODE
|
Метод
выполнения
запросов.
Возможные
значения: LOCAL -
запрос обрабатывается
только клиентским
приложением,
SERVER - запрос выполняется
только сервером,
NULL (пустая строка)
- запрос передается
клиенту, если
сервер не может
его обработать.
|
NULL
|
SQLPASSTHRU
MODE
|
Определяет
режим совместного
использования
одного и того
же псевдонима
направляемыми
на сервер и
локальными
запросами:
NOT SHARED - совместное
использование
запрещено,
SHARED AUTOCOMMIT - совместное
использованием
разрешено с
автоматическим
завершением
транзакций,
SHARED NOAUTOCOMMIT - совместное
использованием
разрешено с
завершением
транзакций
по правилам
сервера.
|
SHARED
AUTOCOMMIT
|
TRACE
MODE
|
Численное
значение,
определяющее
уровень вывода
отладочной
информации.
|
|
SCHEMA
CACHE TIME
|
Время
нахождения
информации
о структуре
таблиц в кэше
в секундах
от 1 до 2147483647. Другие
значения: -1 - до
закрытия БД,
0 - информация
не кэшируется
|
-1
|
BATCH
COUNT
|
Число
записей, помещаемых
в пакет до
завершения
транзакции
|
Число
записей, умещающихся
в 32 К.
|
MAX
ROWS
|
Максимальное
число записей,
которые драйвер
может доставить
на рабочую
станцию при
выполнении
одиночного
SQL-запроса
|
-1
(нет ограничений)
|
ROWSET
SIZE
|
Число
записей, доставляемых
в одном блоке
данных (поддерживается
не всеми ODBC-
драйверами).
|
20
|
4.2 Реализация
запросов к базе
данных.
В
данном разделе
описывается
построение
запросов к базе
данных, то есть
написание самих
файлов ASP
с помощью которых
пользователем
осуществляется
ввод информации
для поиска
необходимой
ему информации,
а так же программ-скриптов,
находящиеся
непосредственно
на сервере и
обрабатывающие
запросы.
Специальных
оболочек для
написания
данных программ-скриптов
не использовалось,
хотя компания
Microsoft
рекомендует
для разработки
свою программу
Visual
InterDev.
Начальная
программа-скрипт
(Db008.asp),
запускается
у пользователя-клиента,
осуществляет
вывод полей
для ввода уточняющей
информации
по запросу. Эта
же программа
осуществляет
вызов следующего
ASP
файла и передачу
ему необходимой
информации
по конкретному
запросу.
Существует
два метода для
передачи параметров
из форм: метод
GET
и метод POST.
Метод
GET служит для
получения любой
информации,
идентифицированной
URI-Запроса. Если
URI - Запроса ссылается
на процесс,
выдающий данные,
в качестве
ответа будут
выступать
данные, сгенерированные
данным процессом,
а не код самого
процесса (если
только это не
является выходными
данными процесса).
Использование
метода условный
GET направлено
на разгрузку
сети, так как
он позволяет
не передавать
по сети избыточную
информацию.
Метод
POST используется
для запроса
сервера, чтобы
тот принял
информацию,
включенную
в запрос, как
субординантную
для ресурса,
указанного
в Строке Статус
в поле URI-Запроса.
Метод POST был
разработан,
чтобы была
возможность
использовать
один общий
метод для следующих
функций:
Аннотация
существующих
ресурсов
Добавление
сообщений в
группы новостей,
почтовые списки
или подобные
группы статей
Доставка
блоков данных
процессам,
обрабатывающим
данные
Расширение
баз данных
через операцию
добавления
Реальная
функция, выполняемая
методом POST, определяется
сервером и
обычно зависит
от URI- Запроса.
Добавляемая
информация
рассматривается
как субординатная
указанному
URI в том же смысле,
как файл субординатен
каталогу, в
котором он
находится,
новая статья
субординатна
группе новостей,
в которую она
добавляется,
запись субординатна
базе данных.
Клиент
может предложить
URI для идентификации
нового ресурса,
включив в запрос
заголовок
"URI". Тем не менее,
сервер должен
рассматривать
этот URI только
как совет и
может сохранить
тело запроса
под другим URI
или вообще без
него.
Для
передачи параметров
запроса используется
метод POST,
так как объем
передаваемых
параметром
большой.
Далее
происходит
вызов других
ASP
файлов, в зависимости
от введённой
информации
по конкретному
запросу или
активизации
определённой
ссылки, а так
же передача
параметров
самого запроса.
Вызванный
файл - обработчик
запроса. Он
формирует
конкретный
запрос к базе
данных и возвращает
полученную
информацию
пользователю.
Список
выполняемых
функций конкретного
файла:
Srch_Org.asp
– осуществляет
запрос на выборку
информации
по организациям;
Org_Info.asp
- осуществляет
запрос на выборку
подробной
информации
об организациях;
Srch_Glb.asp
- осуществляет
запрос по конкретной
информации;
Stat_TY1.asp
- осуществляет
запрос на выборку
статистической
информации
по категории
товаров;
Stat_TY2.asp
- осуществляет
запрос на выборку
статистической
информации
по категории
услуги.
Схема
взаимосвязей
между файлами
запросов:
SearchFr.asp
Srch_Org.asp
Org_Info.asp
Srch_TY1.asp
Stat_TY1.asp
Appendix.asp
Srch_Glb.asp
Stat_TY2.asp
Рис.5 Схема
взаимосвязей
между файлами
запросами.
Начальный
файл базы Db008.asp
- содержит форму
для ввода параметров
поиска. Здесь
пользователь
может выбрать
интересующий
его раздел или
просто задать
слово для
контекстного
поиска, так же
выбрав разделы
где искать.
Рис.6
Db008.asp
Далее
происходит
следующее:
Когда
пользователь
нажимает кнопку
типа "Submit" в форме
Web-браузер запрашивает
определённый
ASP-файл
с необходимым
запросом по
выборке необходимой
информации,
а так же передаёт
необходимые
параметры
запроса.
Далее
уже непосредственно
ASP-программа
осуществляет
запрос к базе
данных SQL
через драйвер
ODBC с полученными
параметрами.
Затем
полученные
результаты
поиска передаются
WEB-браузеру
пользователя.
Термин
ODBC означает "open
database connectivity" - технологию,
основанную
на стандарте
ANSI/ISO, которая позволяет
приложениям
осуществлять
доступ к нескольким
базам данных
сторонних
поставщиков.
В ODBC применяется
интерфейс
общего назначения
CLI (call level interface), в котором
SQL используется
как стандарт
для доступа
к данным. Нашей
целью является
обеспечение
устойчивых
серверных
сессий для
клиентских
систем, поддерживающих
ODBC. Сессии могут
переживать
системный крах
без потребности
того, чтобы
клиентские
приложения
не беспокоились
об остановке
работы, разве
только из соображений
времени выполнения.
Когда
клиентское
приложение
запрашивает
информацию
из базы данных,
запрос поступает
драйверу ODBC,
который является
специфической
программой
для системы
баз данных,
реально производящей
доступ к базе
данных. Драйвер
ODBC транслирует
запрос таким
образом, чтобы
сервер баз
данных мог
понять его и
ответить. Сервер
передает запрошенные
данные драйверу
ODBC, который преобразует
данные в форму,
которую может
понять клиентское
приложение
ODBC.
Все запросы
на получение
практически
любого количества
данных из одной
или нескольких
таблиц выполняются
с помощью
единственного
предложения
SELECT. В общем случае
результатом
реализации
предложения
SELECT является
другая таблица.
К этой новой
(рабочей) таблице
может быть
снова применена
операция SELECT и
т.д., т.е. такие
операции могут
быть вложены
друг в друга.
Представляет
исторический
интерес тот
факт, что именно
возможность
включения
одного предложения
SELECT внутрь другого
послужила
мотивировкой
использования
прилагательного
"структуризированный"
в названии
языка SQL.
Предложение
SELECT может использоваться
как:
самостоятельная
команда на
получение и
вывод строк
таблицы, сформированной
из столбцов
и строк одной
или нескольких
таблиц (представлений);
элемент
WHERE- или HAVING-условия
(сокращенный
вариант предложения,
называемый
"вложенный
запрос");
фраза
выбора в командах
CREAT VIEW, DECLARE CURSOR или INSERT;
средство
присвоения
глобальным
переменным
значений из
строк сформированной
таблицы (INTO-фраза).
Здесь в
синтаксических
конструкциях
используются
следующие
обозначения:
звездочка
(*) для обозначения
"все" - употребляется
в обычном
для
программирования
смысле, т.е. "все
случаи, удовлетворяющие
определению";
квадратные
скобки ([]) – означают,
что конструкции,
заключенные
в эти скобки,
являются
необязательными
(т.е. могут быть
опущены);
фигурные
скобки ({}) – означают,
что конструкции,
заключенные
в эти скобки,
должны рассматриваться
как целые
синтаксические
единицы, т.е.
они позволяют
уточнить порядок
разбора синтаксических
конструкций,
заменяя обычные
скобки, используемые
в синтаксисе
SQL;
многоточие
(...) – указывает
на то, что непосредственно
предшествующая
ему синтаксическая
единица факультативно
может повторяться
один или более
раз;
прямая
черта (|) – означает
наличие выбора
из двух или
более возможностей.
Например обозначение
ASC|DESC указывает,
можно выбрать
один из терминов
ASC или DESC; когда
же один из элементов
выбора заключен
в квадратные
скобки, то это
означает, что
он выбирается
по умолчанию
(так, [ASC]|DESC означает,
что отсутствие
всей этой
конструкции
будет восприниматься
как выбор ASC);
точка с
запятой (;) –
завершающий
элемент предложений
SQL;
запятая
(,) – используется
для разделения
элементов
списков;
пробелы
( ) – могут вводиться
для повышения
наглядности
между любыми
синтаксическими
конструкциями
предложений
SQL;
прописные
жирные латинские
буквы и символы
– используются
для написания
конструкций
языка SQL и должны
(если это специально
не оговорено)
записываться
в точности
так, как показано;
строчные
буквы – используются
для написания
конструкций,
которые должны
заменяться
конкретными
значениями,
выбранными
пользователем,
причем для
определенности
отдельные
слова этих
конструкций
связываются
между собой
символом
подчеркивания
(_);
термины
таблица, столбец,
... – заменяют
(с целью сокращения
текста синтаксических
конструкций)
термины имя_таблицы,
имя_столбца,
..., соответственно;
термин
таблица –
используется
для обобщения
таких видов
таблиц, как
базовая_таблица,
представление
или псевдоним;
здесь псевдоним
служит для
временного
(на момент
выполнения
запроса) переименования
и (или) создания
рабочей копии
базовой_таблицы
(представления).
Предложение
SELECT (выбрать) имеет
следующий
формат:
подзапрос
[UNION [ALL] подзапрос]
...
[ORDER
BY {[таблица.]столбец
| номер_элемента_SELECT}
[[ASC] | DESC]
[,{[таблица.]столбец
| номер_элемента_SELECT}
[[ASC] | DESC]] ...;
и позволяет
объединить
(UNION) а затем упорядочить
(ORDER BY) результаты
выбора данных,
полученных
с помощью нескольких
"подзапросов".
При этом упорядочение
можно производить
в порядке возрастания
- ASC (ASCending) или убывания
DESC (DESCending), а по умолчанию
принимается
ASC.
В этом
предложении
подзапрос
позволяет
указать условия
для выбора
нужных данных
и (если требуется)
их обработки
SELECT
(выбрать)
данные из указанных
столбцов и
(если необходимо)
выполнить перед
выводом их
преобразование
в соответствии
с указанными
выражениями
и (или) функциями
FROM
(из) перечисленных
таблиц, в которых
расположены
эти столбцы
WHERE
(где) строки
из указанных
таблиц должны
удовлетворять
указанному
перечню условий
отбора строк
GROUP BY
(группируя
по) указанному
перечню столбцов
с тем, чтобы
получить для
каждой группы
единственное
агрегированное
значение, используя
во фразе SELECT SQL-функции
SUM (сумма), COUNT (количество),
MIN (минимальное
значение), MAX
(максимальное
значение) или
AVG (среднее значение)
HAVING
(имея) в
результате
лишь те группы,
которые удовлетворяют
указанному
перечню условий
отбора групп
и имеет
формат
SELECT [[ALL]
| DISTINCT]{ * | элемент_SELECT
[,элемент_SELECT] ...}
FROM {базовая_таблица
| представление}
[псевдоним]
[,{базовая_таблица
| представление}
[псевдоним]]
...
[WHERE фраза]
[GROUP
BY фраза
[HAVING фраза]];
Элемент_SELECT
- это одна из
следующих
конструкций:
[таблица.]*
| значение |
SQL_функция |
системная_переменная
где значение
– это:
[таблица.]столбец
| (выражение) |
константа |
переменная
Синтаксис
выражений имеет
вид
(
{[ [+] | - ] {значение
| функция_СУБД}
[ + | - | * | ** ]}... )
а синтаксис
SQL_функций – одна
из следующих
конструкций:
{SUM|AVG|MIN|MAX|COUNT}
( [[ALL]|DISTINCT][таблица.]столбец
)
{SUM|AVG|MIN|MAX|COUNT}
( [ALL] выражение
)
COUNT(*)
Фраза
WHERE включает набор
условий для
отбора строк:
WHERE
[NOT] WHERE_условие
[[AND|OR][NOT] WHERE_условие]...
где WHERE_условие
– одна из следующих
конструкций:
значение
{ = | <> | < | <= | > | >= } { значение
| ( подзапрос )
}
значение_1
[NOT] BETWEEN значение_2
AND значение_3
значение
[NOT] IN { ( константа
[,константа]...
) | ( подзапрос
) }
значение
IS [NOT] NULL
[таблица.]столбец
[NOT] LIKE 'строка_символов'
[ESCAPE 'символ']
EXISTS
( подзапрос )
Кроме
традиционных
операторов
сравнения (= |
<> | < | <= | > | >=) в WHERE фразе
используются
условия BETWEEN (между),
LIKE (похоже на), IN
(принадлежит),
IS NULL (не определено)
и EXISTS (существует),
которые могут
предваряться
оператором
NOT (не). Критерий
отбора строк
формируется
из одного или
нескольких
условий, соединенных
логическими
операторами:
AND
- когда
должны удовлетворяться
оба разделяемых
с помощью AND
условия;
OR
-
когда должно
удовлетворяться
одно из разделяемых
с помощью OR
условий;
AND
NOT
- когда
должно удовлетворяться
первое условие
и не должно
второе;
OR
NOT
- когда
или должно
удовлетворяться
первое условие
или не должно
удовлетворяться
второе,причем
существует
приоритет AND
над OR (сначала
выполняются
все операции
AND и только после
этого операции
OR). Для получения
желаемого
результата
WHERE условия должны
быть введены
в правильном
порядке, который
можно организовать
введением
скобок.
При обработке
условия числа
сравниваются
алгебраически
- отрицательные
числа считаются
меньшими, чем
положительные,
независимо
от их абсолютной
величины. Строки
символов сравниваются
в соответствии
с их представлением
в коде, используемом
в конкретной
СУБД, например,
в коде ASCII. Если
сравниваются
две строки
символов, имеющих
разные длины,
более короткая
строка дополняется
справа пробелами
для того, чтобы
они имели одинаковую
длину перед
осуществлением
сравнения.
Наконец,
синтаксис фразы
GROUP BY имеет вид
GROUP
BY [таблица.]столбец
[,[таблица.]столбец]
... [HAVING фраза]
GROUP BY инициирует
перекомпоновку
формируемой
таблицы по
группам, каждая
из которых
имеет одинаковое
значение в
столб-цах, включенных
в перечень
GROUP BY. Далее к этим
группам применяются
агрегирующие
функции, указанные
во фразе SELECT, что
приводит к
замене всех
значений группы
на единственное
значение (сумма,
количество
и т.п.).
С помощью
фразы HAVING (синтаксис
которой почти
не отличается
от синтаксиса
фразы WHERE)
HAVING
[NOT] HAVING_условие
[[AND|OR][NOT] HAVING_условие]...
можно
исключить из
результата
группы, не
удовлетворяющие
заданным условиям:
значение
{ = | <> | < | <= | > | >= } { значение
| ( подзапрос )
|
SQL_функция }
{значение_1
| SQL_функция_1}
[NOT]
BETWEEN
{значение_2
| SQL_функция_2} AND
{значение_3 |
SQL_функция_3}
{значение
| SQL_функция} [NOT] IN { (
константа
[,константа]...
)
|
( подзапрос ) }
{значение
| SQL_функция}
IS
[NOT]
NULL
[таблица.]столбец
[NOT] LIKE 'строка_символов'
[ESCAPE 'символ']
EXISTS
( подзапрос )
Все
выборки информации
из базы данных
SQL
осуществляются
с помощью команды
SELECT.
Пример
запроса на
выборку информации
по фирмам (фрагмент
файла Srch_org.asp):
.......
SQL = "SELECT
OrgID, ShortName, Address, Tel1 FROM Org WHERE Visible = 1 ORDER BY
ShortName".
.......
Запрос
на выдачу подробной
информации
о фирмах: (фрагмент
файла Srch_org.asp):
Header
= Header & " " & Encode( "Результат
расширенного
поиска:"
) & ""
Name = SEARCH.Item(
"TXT" )
Name_Prec =
SEARCH.Item( "TXT_PREC" )
Address = SEARCH.Item(
"ADDRESS" )
Address_Prec = SEARCH.Item( "ADDRESS_PREC"
)
TypeOrg = SEARCH.Item(
"TYPE" )
Phone = SEARCH.Item(
"PHONE" )
Phone_Prec =
SEARCH.Item( "PHONE_PREC" )
Fax = SEARCH.Item(
"FAX" )
Fax_Prec =
SEARCH.Item( "FAX_PREC" )
FaxRek = SEARCH.Item(
"APPENDIX" )
FaxRek_Prec =
SEARCH.Item( "APPENDIX_PREC" )
SQL = "SELECT
OrgID, ShortName, Address, Tel1 FROM Org WHERE Visible = 1"
If Name <> ""
Then
Header
= Header & " " &
Encode( "Наименование
" ) & ""
If Name_Prec = 1
Then
Header = Header & Encode( "содержит
" )
Else
Header = Header & Encode( "начинается
с " )
End If
Header
= Header & """"
& Name & """"
If Name_Prec = 1
Then
Name
= "%" & Name & "%"
Else
Name
= Name & "%"
End If
SQL = SQL & "
AND ( ( ShortName Like '" & Name & "' ) OR (
FullName Like '" & Name & "' ) )"
End If
If Address <> ""
Then
Header
= Header & " " &
Encode( "Адрес
" ) & ""
If Address_Prec = 1
Then
Header = Header & Encode( "содержит
" )
Else
Header = Header & Encode( "начинается
с " )
End If
Header
= Header & """"
& Address & """"
If Address_Prec = 1
Then
Address = "%"
& Address & "%"
Else
Address = Address
& "%"
End If
SQL = SQL & "
AND ( Address Like '" & Address & "' )"
End If
В
результате
поиска на экране
пользователя
появляется
следующая
информация:
Рис.7 Информация
по выборке -
организации.
Распечатка
листингов
запросов к базе
данных приведена
в приложении.
Тестирование
и отладка.
В
ходе тестирования,
были выявлены
некоторые
ошибки работы
программы
обработки. Все
они устранены.
Результатом
разработки
явилась полностью
работоспособная
база данных
компании "Телефонная
Коммерческая
Служба 008".
Помимо
работ, связанных
с отладкой
программ, проводилось
так же тестирование
базы данных
на предмет
быстродействия.
Быстродействие
зависит от
многих составляющих
системы. Сюда
можно отнести:
быстродействие
самого компьютера-сервера
баз данных;
быстродействие
операционной
системы и
WEB-сервера
(MS
IIS
в данном случае);
быстродействие
выбранного
сервера баз
данных;
объём
базы данных;
конечно
же скорость
соединения
с Internet.
Для
объективного
оценивания
быстродействия
первые два
пункта не
рассматривались.
По
оценкам экспертов
из уважаемого
издания «СУБД»,
сервер баз
данных Microsoft
SQL
Server
7.0 на сегодняшний
день является
одним из самых
мощных и производительных
решений на
сегодняшний
день на платформе
Windows
NT.
Собственно
тестирование
производилось
по критерию
объёма.
Как показали
испытания, даже
большой объём
базы (более
3000 записей) не
увеличивал
сильно время
выдачи результата.
Когда как реализация
этого же проекта
средствами
Microsoft
Access
приводила к
большому времени
ожидания выдачи
результата.
Выигрыш в скорости
выдачи выборки
даже визуально
был велик. Хотя
и так известно,
что Access
не предназначен
для больших
баз данных.
По
результатам
тестирования,
можно сказать,
что переход
на более производительную
СУБД MSSQL
7.0 оправдался.
Заключение.
Оглавление.
Выбор
темы для дипломного
проектирования…………………………………....4
Разработка
технического
задания на
дипломное
проектирование…………...5
Выбор
методов и средств
решения…………………………………………………5
Выбор
сервера баз
данных……………………………………………………………………...5
Выбор
методов доступа
к базе данных………………………………………………………13
3.2.1
CGI – Common Gateway Interface………………………………………………………………14 3.2.2
PHP - Personal Home Page Tools………………………………………………………………14 3.2.3 ISAPI
– приложения………………………………………………………………………………15 3.2.3.1
dBWeb…………………………………………………………………………………………..15 3.2.3.2
IDC……………………………………………………………………………………………….17 3.2.3.3
ADO – Active Data Objects……………………………………………………………………18 3.3
ASP
(Active
Server
Page)
– Активные
серверные
страницы……………………………...19
Разработка
проекта…………………………………………………………………...23
Перенос
базы данных
на Microsoft
SQL
Server…………………………………………….....23
Реализация
запросов к
базе данных………………………………………………………...….28
Тестирование
и отладка.………………………………..…………………………………...……39
ЭКОНОМИЧЕСКОЕ
ОБОСНОВАНИЕ
ПРОЕКТА………………………………….41 5.1
Концепция……..…….…….…….…….…….…….…….…….…….…….…….…….…….……….41 5.2
Краткое техническое
описание системы.
…….…….…….…….…….…….…….…….………41 5.3
Рынок и план
маркетинга…….…….…….…….…….…….…….…….…….…….…….………..42 5.4
Организационный
план работы
по реализации
проекта и
определение
стоимости его
разработки.
…….…….…….…….…….…….…….…….…….…….…….…….…….…….…….…….43 5.5
Расчет себестоимости
разработки
проекта.
…….…….…….…….…….…….…….…….…...44 5.6
Прогноз финансовых
показателей.
…….…….…….…….…….…….…….…….…….…….….46 5.6.1
Установление
исходных
предложений.
…….…….…….…….…….…….…….…….………46 5.6.2
Определение
потребности
в начальном
капитале.
…….…….…….…….…….…….…….47 5.6.3
Производство
и реализация.
…….…….…….…….…….…….…….…….…….…….……….49 5.6.4
Определение
производственно-сбытовых
издержек.
…….…….…….…….…….…….…..50 5.6.5
Оценка ликвидационной
стоимости
основных средств..
…….…….…….…….…….……..52 5.6.6
Определение
порога безубыточности
прогнозируемого
производства..…….…….…….52 5.6.7
Определение
текущих расходов
и доходов по
проекту..…….…….…….…….…….……..53 5.6.8
Прогноз движения
денежной
наличности..…….…….…….…….…….…….…….…….……54 5.6.9
Оценка экономической
эффективности
проекта..…….…….…….…….…….…….……….56 5.7
Выводы..…….…….…….…….…….…….
…….…….…….…….…….…….…….…….…….…...56
Раздел безопасность
жизнедеятельности
в дипломном
проекте.
…….………...57 6.1
Общие
положения.…….…….…….…….…….
…….…….…….…….…….…….…….…….……57 6.2
Характер
выполняемой
работы.
…….…….…….…….…….…….…….…….…….…….……...57 6.2.1
Работа
пользователя.
…….…….…….…….…….…….…….…….…….…….…….…….……57 6.2.2
Работа
программиста.
…….…….…….…….…….…….…….…….…….…….…….…….……58 6.2.3
Рекомендации
по организации
труда и отдыха.
…….…….…….…….…….…….…….…...59 6.3
Монитор.
…….…….…….…….…….…….…….…….…….…….…….…….…….…….…….…….60 6.3.1
Требования
к монитору на
РМ пользователя.
…….…….…….…….…….…….…….……...60 6.3.2
Требования
к монитору на
РМ программиста.
…….…….…….…….…….…….…….……..60 6.3.3
Прочие
требования
к монитору.
…….…….…….…….…….…….…….…….…….…….…….61 6.4
Организация
освещения…….…….…….…….…….…….…….…….…….…….…….…….…….62 6.5
Рабочее
место.
…….…….…….…….…….…….…….…….…….…….…….…….…….…….…..63 6.6
Электро
и пожаро безопасность.
…….…….…….…….…….…….…….…….…….…….……..64 6.7
Шумы.
…….…….…….…….…….…….…….…….…….…….…….…….…….…….…….……….64
6.8
Температура,
давление, влажность.
…….…….…….…….…….…….…….…….…….……….64 6.9
Работа
в чрезвычайных
ситуациях.
…….…….…….…….…….…….…….…….…….…….….65 6.10
Интегральная
оценка тяжести
труда. …….…….…….…….…….…….…….…….…….…….65 7. Заключение.
…….…….…….…….…….…….…….…….…….…….…….…….…….…….………68
Список
литературы….…….…….…….…….…….…….…….…….………..…….….…….……..69
Приложение…….…….…….…….…….…….…….…….…….…….…….…….…….…….…….....70
6. Раздел
безопасность
жизнедеятельности
в дипломном
проекте.
Общие положения.
В
дипломном
проекте разрабатывается
программа-модуль
для доступа
к базе данных
через Internet.
Все работы
выполняются
при помощи ЭВМ,
поэтому в этом
разделе описаны
требования
к рабочим местам,
пользователей
ЭВМ: разработчика
программы
(программиста)
и рядового
пользователя
который в дальнейшем
будет работать
с программой-модулем.
Характер
выполняемой
работы.
Работа
пользователя.
Работа
пользователя
на ЭВМ связана,
прежде всего,
с использованием
операционной
системы Windows,
а так же с работой
в Internet-броузере
(Microsoft
Explorer
или Netscape
Navigator).
При этом всё
управление
сводиться на
перемещение
курсора с помощью
манипулятора
«мышь» и ввода
ключевых фраз
для поиска в
базе данных
с помощью клавиатуры.
При
работе с базой
данных от
пользователя
требуется
довольно большое
зрительное
напряжение,
что связанно
с большими
объёмами данных,
выдающимися
на запросы,
кроме того,
следует учитывать
психологическую
нагрузку, вызванную
тем, что ошибка,
допущенная
при вводе ключевых
слов для поиска,
может привести
к неправильному
результату
или вообще к
отсутствию
результата
запроса, а так
как скорость
работы Internet’а
у большинства
пользователей
достаточно
низкая, то это
ведёт к ненужным
задержкам в
работе и психологического
дискомфорта.
Устранение
ошибки потребует
дополнительного
времени.
А потому
труд пользователя
следует считать
тяжёлым из-за
психологических
нагрузок.
Работа
программиста.
В работе
программиста
на ЭВМ можно
выделить два
этапа: написание
программы и
её отладка.
Написание
связано с вводом
текста программы
в память ЭВМ
при помощи
клавиатуры.
Для этого необходим
текстовый
редактор или
специфическая
программа,
позволяющая
визуальными
средствами
создавать из
шаблонов готовую
программу
(хотя, как правило,
приходиться
самому корректировать
исходный текст
программы).
Хотя многие
текстовые
редакторы
позволяют
управлять своей
работой при
помощи «мыши»,
всё-таки она
второстепенна
именно для
небольших
текстовых
редакторов
и, как правило,
для управления
применяется
клавиатура,
но в визуальных
средах редактирования
и создания
программ –
«мышь» активно
используется.
Процесс
ввода текста
программы в
память нельзя
назвать напряжённым,
поскольку
ошибка, допущенная
на этом этапе
это, скорее
всего синтаксическая
ошибка, о которой
будет оповещено
компилятором
или она будет
обнаружена
при отладке
программы.
Однако она
связана с набором
иногда большого
по своему объёму
текста, то есть
с интенсивным
использованием
клавиатуры,
что может стать
причиной развития
«запястного
синдрома». Боль
в плечах, руках
и кистях, связанная
с монотонно
повторяющимися
движениями
рук при работе
с клавиатурой
или с манипулятором
типа «мышь».
«Запястный
синдром» - это
болезненное
поражение
срединного
нерва запястья.
Усилия, необходимые
для того, чтобы
руки постоянно
находились
параллельно
клавиатуре,
вызывают перегрузки
мышц и сухожилии.
Каждое нажатие
на клавишу
сопряжено с
сокращением
мышц, сухожилия
скользят вдоль
костей и соприкасаются
с тканями. В
нижней стороне
запястья около
ладони проходит
пучок из 9 сухожилий,
каждое из которых
покрыто оболочкой
со смазочной
жидкостью, и
срединный нерв.
При распухании
хотя бы одной
из оболочек,
может быть
затронут нерв,
что вызывает
боль.
Наиболее
напряжён труд
программиста
в процессе
тестирования
и отладки набранной
программы,
например при
помощи специализированной
программы,
отладчика. Эта
работа требует
большого зрительного
и умственного
напряжения
т.к. необходимо
всё время отслеживать
состояние
внутренних
регистров
процессора,
переменных,
анализировать
текущую выполняемую
инструкцию
и т.д., таким
образом, работа
программиста
на разных стадиях
сопряжена с
разными факторами
делающих труд
тяжёлым. В начале
это необходимость
набора большого
количества
символов на
клавиатуре,
а затем зрительные
и умственные
напряжения
во время тестирования
и отладки. Поэтому
труд программиста
также тяжёл.
Рекомендации
по организации
труда и отдыха.
Согласно
предыдущим
разделам труд
специалистов
занятых при
создании программы
и её использовании,
может быть
отнесён к разряду
тяжёлых.
Работа
за компьютером
связана со
зрительными
нагрузками,
нагрузками
на спину, плечи,
поясницу, область
шеи, в результате
чего могут
развиться
различные виды
недомоганий:
головная
боль;
резь
в глазах, быстрая
утомляемость;
боль
в спине, плечах,
в области шеи
и т.д.
Потому
должен соблюдаться
режим работы
с обязательными
перерывами.
Наиболее
предпочтителен
такой режим:
45 минут работы,
15 минут перерыв.
При этом в течение
восьми часового
рабочего дня
общее время
пребывания
за компьютером
не должно превышать
5-6 часов. Во время
перерывов
оператор может
выполнять
работу не связанную
с напряжением
зрения.
Для
уменьшения
зрительной
нагрузки
рекомендуется:
принудительное
частое моргание;
отвлечение
внимания через
определённые
промежутки
времени на
другой объект;
сокращение
длительности
зрительной
работы за счёт
изготовления
твёрдых копий
документов
и работы уже
с ними.
Монитор.
Исходя
из особенностей
зрительной
информации,
с которой работают
пользователь
и программист
при использовании
ЭВМ, определим
требования
к монитору.
Требования
к монитору
на РМ пользователя.
Как
говорилось,
работа пользователя
это работа с
графическим
интерфейсом
Windows
и Internet-броузером.
Для качественного
изображения
на экране, т.е.
изображения
с хорошо различимыми
цветами, плавностью
линий, необходим
монитор поддерживающий
разрешение
не менее 800600
точек размером
не менее 14 дюймов,
лучше 15, 17. Это
обеспечить
пользователю
возможность
видеть достаточно
большой участок
«поля» при этом
размеры элементов
изображения
могут быть
достаточно
велики.
Для
того чтобы
зрение оператора
при этом не
утомлялось,
изображение
на экране не
должно мерцать,
поэтому монитор
в этом режиме
должен иметь
частоту кадровой
(вертикальной)
синхронизации
не менее 75 Гц
без прореживания.
Монитор естественно
должен быть
цветным. Соответственно
этим требованиям
должен быть
подобран видеоадаптер
компьютера.
Причём от объёма
памяти видеоадаптера
в основном и
зависит количество
одновременно
отображаемых
на экране цветов.
Поэтому объём
видеопамяти
должен быть
не менее 1Мб,
для одновременного
отображения
65536 цветов.
Требования
к монитору
на РМ программиста.
Требования
к монитору для
рабочего места
программиста
несколько выше,
чем для пользователя.
Это связано
с тем, что программы
визуальной
разработки
приложений
выводят большое
количество
информации.
Однако выводимая
информация
должна максимально
просто быть
воспринята,
т.е. без напряжения
зрения. Для
удовлетворения
этому требованию
существует
два пути.
Первый
состоит в
использовании
программных
средств, которые
позволяют
изменять масштаб
изображения
на экране, изменять
его цвет, располагать
выводимую
информацию,
так как это
удобно пользователю.
В этом случае,
физические
размеры экрана
не важны, хотя
если этот экран
большой, например
17 дюймов, то это
может только
положительно
сказаться на
восприятии.
В общем случае
вполне достаточно
15 дюймов.
Однако
не всё программное
обеспечение
позволяет
указанные
действия по
изменения
параметров
изображения,
особенно это,
касается систем
ориентированных
на работу в
текстовом
режиме. В этом
случае решение
проблемы - это
только использование
большого 17-дюймового
монитора.
Требования
к количеству
цветов отображаемых
ЭВМ для программиста
не так важно
и вполне может
быть не больше
256 (стандартная
палитра для
Windows-приложений).
Способность
к поддержке
высоких разрешений
так же не столь
важна. Главное
чтобы частота
кадровой
синхронизации
в используемом
режиме была
также не меньше
75 Гц.
Прочие
требования
к монитору.
Монитор
источник
ультрафиолетового,
рентгеновского,
инфракрасного,
ультрафиолетового,
электромагнитного
и электрического
полей. При этом
опасный уровень
могут иметь
лишь два последних.
Уровни всех
этих излучений
нормируются
стандартами
многих стран.
Требования
российских
стандартов
охраны труда
в этой области
ниже. Например,
нормы шведского
стандарта MPR
II
в 20 раз жёстче
российских
норм, а TCO’95 в 50 раз.
Поэтому наиболее
правильно
руководствоваться
более высокими
требованиями.
В настоящее
время производители
мониторов по
собственной
инициативе
проводят тестирование
своих изделий
на соответствие
этим нормам,
поэтому наиболее
правильно
использование
мониторов
соответствующих
стандарту MPR
II,
а ещё лучше
TCO’95.
Если
монитор не
проходил
тестирование,
то его использование
возможно лишь
при условии,
что его параметры
соответствуют
стандарту MPR
II,
т.е.:
потенциал
электростатического
поля по абсолютной
величине меньше
500 В;
напряжённость
переменного
электрического
поля частотой
5-5000 Гц на расстоянии
50см от монитора
25В/м;
напряжённость
переменного
магнитного
поля частотой
5-5000 Гц на расстоянии
50см от монитора
250 нТл;
напряжённость
переменного
электрического
поля частотой
5-400 кГц на расстоянии
50см от монитора
- 2,5 В/м;
напряжённость
переменного
магнитного
поля частотой
5-400 кГц на расстоянии
50см от монитора
25 нТл;
Однако
в настоящее
время существует
множество
стандартов,
нормирующих
допустимы
уровень излучений,
поэтому проще
всего обеспечить
безопасный
режим работы
оператора ЭВМ,
это использовать
монитор, соответствующий
стандартам
в этой области.
Наиболее правильно
это использовать
монитор, соответствующий
стандарту
TCO’95 шведской
конфедерации
профсоюзов.
Кроме
перечисленных
требований
монитор должен
иметь возможность
регулировки
яркости, контрастности
размеров изображения.
Желательно
наличие антибликового
покрытия.
Организация
освещения.
Экран
монитора - источник
света. Поэтому
необходимо
организовать
освещение и
расположить
его так чтобы
в поле зрения
оператора не
было других
более ярких
источников
света, а также
освещённость
экрана не увеличилась
за счет какого-то
постороннего
источника
света, например
лампы на потолке
или солнечного
света.
Более
яркий источник
света в поле
зрения оператора
будет слепить
его. Для прочтения
информации
с экрана необходимо
больше напрягать
зрение. Повышенная
освещённость
экрана размывает
изображение
оригинала на
сетчатке глаз.
Для
избежания всего
этого необходимо:
Располагать
монитор экраном
перпендикулярно
к окну.
Помещение
должно иметь
шторы способные
задержать
прямой солнечный
свет.
При
невозможности
исключить
блики на экране
монитора его
перестановкой
необходимо
применение
защитных фильтров,
позволяющих
исключить
отражение
света и, кроме
того, увеличить
контрастность
изображения.
Уровень
освещённости
помещения
должен лежать
в диапазоне
210 -540 лк, освещённость
на рабочем
месте оператора
400 лк.
Яркость
монитора должна
быть примерно
в 5 раз выше яркости
окружающих
его поверхностей,
могущих попадать
в поле зрение
оператора.
При
наличии в помещении
других рабочих
мест, не использующих
ЭВМ, необходимо
использовать
комбинированное
освещение
этого помещения.
Рабочее
место.
Под
рабочим местом
понимается
положение тела
при работе
расположение
экрана монитора
относительно
глаз, клавиатуры,
поза оператора.
Неправильное,
неудобное
положение тела
во время длительной
работы может
стать причиной
длительного
статического
напряжения
мышц спины, шеи
рук и ног, что
в свою очередь
приводит к
быстрому утомлению,
затеканию и
одеревенению
мышц, снижению
работоспособности.
Идеального
положение тела
за экраном
компьютера
нет. Рабочее
место должно
быть таким,
чтобы в течение
рабочего дня
оператор мог
изменить своё
положение. В
общем случае,
рабочее место
должно обеспечивать
возможность
занять следующие
два крайних
положения.
Первое
с выпрямленной
спиной, экран
монитора находится
ниже уровня
глаз под углом
порядка 20
при расстояние
от экрана до
глаз 50см. Второе
положение,
откинувшись,
при котором
центр экрана
находится чуть
ниже уровня
глаз. В обоих
положениях
клавиатура
и мышь должны
быть расположены
так, чтобы за
ними не нужно
было тянуться
или высоко
держать руки
при работе.
Угол между
кистями и плечом
при этом порядка
80 - 100.
Этим
требованиям
можно удовлетворить
использованием
кресла с откидывающейся
спинкой, повторяющей
форму спины
оператора и
с регулируемой
высотой. Высота
стола, на котором
расположен
монитор, также
должна меняться
хотя бы за счет
подкладывания
под его ножки
предметов.
Электро и
пожаро безопасность.
Электробезопасность
достигается
применением
защитных кожухов
делающих невозможным
касание токоведущих
частей. При
этом недопустимо
включение
питания и работа
при снятом
кожухе.
Основная
причин пожара,
перегрев частей
ЭВМ: монитора,
устройств
внутри системного
блока, из-за
ограничения
притока к ним
охлаждающего
воздуха. Во
избежание этого
недопустимо
класть какие-либо
предметы на
монитор, располагать
его и системный
блок вблизи
стенок или
предметов,
затрудняющих
приток к ним
воздуха.
Шумы.
При
закрытом кожухе
системного
блока источник
шума на рабочем
месте оператора
ЭВМ это работающий
принтер. Уровень
шумности зависит
от типа принтера
и для матричного
принтера составляет
порядка 35-40 дБА
(в зависимости
от модели принтера),
что превышает
предельно
допустимы
уровень, значение
которого 40дБА.
Однако, как
правило, в работе
пользователя
и программиста
необходимость
печати возникает
не часто, поэтому
вполне допустимо
применение
принтера подобного
типа, однако
лучше применять
более поздние
лазерные или
струйные принтеры,
шумность которых
значительно
ниже.
Температура,
давление,
влажность.
Комфортными
условиями при
работе на ЭВМ
считаются
условия, при
которых:
температура
воздуха в тёплое
время года
23-25C,
а в холодное
22-24C;
влажность
40-60%;
скорость
ветра не превышает
0,1 м/с;
атмосферное
давление 730-780 мм
р.ст.
Работа в
чрезвычайных
ситуациях.
Чрезвычайной
ситуацией для
оператора ЭВМ,
которая реально
может существовать
на рабочем
месте, следует
считать падение
напряжение
питания в сети,
при котором
данные в оперативной
памяти компьютера
будут потеряны.
Такая ситуация
может быть
причиной
дополнительного
нервного напряжения.
Например,
пользователь
осуществляет
запрос на выборку
каких-либо
результатов,
эта выборка
может осуществляться
в течение десятка
минут и в момент
выборки происходит
отключение
питания. Скорее
всего, все результаты
работы программы
к этому моменту
времени будут
потеряны.
Для
избежания
подобной ситуации
не рабочих
местах следует
использовать
источники
бесперебойного
питания (UPS). Они
поддерживают
напряжения
питания на
необходимом
уровне, после
аварийного
падения напряжения
в основной сети
в течение 10-60 минут
и, кроме того,
сглаживают
пульсации
питающего
напряжения.
Они снабжены
звуковой и
световой
сигнализацией
включаемой
устройством
при отсутствии
напряжения
в основной
электрической
сети. Получив
такой сигнал,
оператор ЭВМ
имеет достаточно
времени для
сохранения
данных в энергонезависимой
памяти.
Интегральная
оценка тяжести
труда.
Оценим
интегральную
тяжесть труда
на РМ пользователя
и РМ программиста
при укомплектовании
их в соответствии
с выше перечисленными
требованиями.
Примем, что
основной источник
шума это матричный
принтер, причём
печать на нём
ведётся не
более 30 минут
в рабочий день.
Помещение, где
проводятся
работы, отапливается
в холодное
время. То есть
основные
неблагоприятные
факторы это
напряжённый
труд и шум
печатающего
принтера. Исходя
из этих исходных
данных оценим
баллы факторов
рабочих среды.
Таблица
1
Расчёт
условий труда
на рабочих
местах
Фактор
|
Значение
|
Длительность,
%
|
Балл
|
|
|
|
|
Температура
воздуха в
помещении в
тёплый период,
C
|
23-25
|
100
|
1
|
Температура
воздуха в
помещении в
холодный период,
C
|
22-24
|
100
|
1
|
Атмосферное
давление, мм
р.ст.
|
730-780
|
100
|
1
|
Промышленный
шум, дБА
|
35-40
|
5
|
0,05
|
Сменность
|
Утренняя
|
100
|
1
|
Длительность
сосредоточенного
наблюдения,
в процентах
рабочего времени
|
50-75
|
100%
|
3
|
Характер
выполняемой
работы
|
Простые
действия по
индивидуально-му
плану
|
100%
|
1
|
СУММА:
|
-
|
-
|
8,05
|
ВСЕГО
ФАКТОРОВ:
|
-
|
-
|
7
|
МАКСИМАЛЬНОЕ
ЗНАЧЕНИЕ:
|
-
|
-
|
3
|
ИНТЕГРАЛНАЯ
ТЯЖЕСТЬ ТРУДА:
|
-
|
-
|
36,7
|
КАТЕГОРИЯ
ТЯЖЕСТИ:
|
-
|
-
|
3
|
УСТАЛОСТЬ:
|
-
|
-
|
33,0
|
РАБОТОСПОСОБНОСТЬ:
|
-
|
-
|
67,0
|
При
работе за компьютером
в течение 5 - 6 часов
получаем недопустимо
высокую категорию
тяжести труда.
Снизим время
работы на ЭВМ
и программиста,
и пользователя
до 4 - 5 часов, тогда
длительность
сосредоточенного
наблюдения
можно оценить
в 2 балла.
Тогда:
интегральная
тяжесть труда
составит 28,9;
категория
тяжести будет
вторая;
усталость:
20,8
работоспособность:
79,2
прирост
работоспособности
составит: 3,6%.
То есть
снижение длительности
сосредоточенного
наблюдения
за экраном
монитора, возможное
благодаря
общему уменьшению
времени работы
за компьютером
приводит к
комфортным
условиям труда
на рабочем
месте.
Министерство
общего и профессионального
образования
РФ
Санкт-Петербургский
государственный
электротехнический
университет
им. В.И. Ульянова
(Ленина) “ЛЭТИ”
Факультет
компьютерных
технологий
и информатики
Кафедра
математического
обеспечения
и применения
ЭВМ
К защите
допустить –
Зав.кафедрой
МОЭВМ
д.т.н.,
проф. Лисс А.Р.
Пояснительная
записка
К
ДИПЛОМНОМУ
ПРОЕКТУ
на
тему: “База
данных Телефонной
Коммерческой
Службы Санкт-Петербурга
“008”
с доступом
через Internet.”
Дипломант:
Гришкевич
М.Т.
Руководитель:
Носков В.
А.
Консультант
по экономическому
обоснованию:
Васильев
А.В.
Консультант
по охране
безопасности
жизнедеятельности:
Товбин Г.М.
Санкт
– Петербург
2000 г.
5.
ЭКОНОМИЧЕСКОЕ
ОБОСНОВАНИЕ
ПРОЕКТА.
5.1 Концепция.
Не
секрет, что в
деловую жизнь
бизнесмена
всё чаще входит
слово Internet.
Это связано,
прежде всего,
с бурным развитием
технологий
связи и электронной
коммерции. Если
раньше с помощью
Internet
было доступно
лишь обмениваться
письмами и
документами,
то сейчас с
развитием
технологий
пользователь
может покупать
товар или услугу,
не выходя из
дома. Так же
возросла роль
выдачи не просто
пассивной
информации
о фирме, но и
например информации
на, вводимый
пользователем,
запрос или
выводе некоторой
информации
из баз данных
фирм непосредственно
, минуя помощь
самой фирмы.
Целью
разработки
базы данных
"Телефонной
Коммерческой
Службы Санкт-Петербурга
008" является
перенос основной
базы данных
данной фирмы
для использования
её посредством
Internet-доступа.
Данная разработка
предназначена
для использования
в составе
Internet-броузеров
Microsoft
Internet
Explorer
или Netscape
Navigator.
Данные Internet-броузеры
существую на
рынке давно
и распространяются
бесплатно.
Поскольку
разрабатываемая
система является
частью продукта,
уже зарекомендовавшего
себя конкурента-
способным, а
доработка
комплекса
производиться
для укрепления
его конкурентоспособных
позиций, уровень
конкурентоспособности
не рассчитывается.
5.2 Краткое
техническое
описание системы.
Разработанный
проект является
одним из модулей
для Internet-броузеров
Microsoft
Internet
Explorer
либо Netscape
Navigator.
Для работы с
ним от пользователя
не требуется
никаких дополнительных
знаний, достаточно
знать основные
навыки обращения
с Internet-броузером
и средствами
навигации в
Internet.
Для работы с
разработанным
проектом пользователю
более полезно
знать практические
вопросы использования
полученного
результата,
чем теоретические
выкладки по
поводу способов
достижения
решения. При
работе от
пользователя
требуется
выбрать необходимую
категорию либо
некоторое
ключевое слово
для поиска
необходимой
информации.
Вывод результата
происходит
в течении некоторого
времени, обусловленного
скоростью
выборки необходимой
информации
из базы данных,
а так же скоростью
Internet-соединения.
5.3 Рынок
и план маркетинга.
В
настоящее время
рынок программного
обеспечения
для Inernet-приложений
в достаточной
степени насыщен.
В связи со спецификой
предмета
Internet-приложений,
влияние на
который оказывает
динамически
изменяющаяся
в настоящее
время законодательная
база, а также
стремительный
рост технического
прогресса,
период жизни
данного типа
продукции
является относительно
кратким.
Рынок
потенциальных
потребителей
такого рода
продукции,
возможно
сегментировать
следующим
образом:
Крупные
организации
и предприятия,
корпоративные
структуры,
имеющие в своем
составе достаточно
большой штат
работников,
территориально
расположенных
далеко от основных
вычислительных
мощностей
компании, для
которых требуется
получить
незамедлительно
достаточно
большой объём
информации.
Небольшие
частные фирмы,
малые предприятия,
частные предприниматели,
желающие разместить
информацию
со своих баз
данных с сети
Internet.
В первом
из перечисленных
сегментов
определяющими
критериями
являются качество
продукта, надежность
эксплуатации,
уровень послепродажного
обслуживания,
надежность
защиты информации
от несанкционированного
доступа.
Для второго
сегмента
потенциальных
покупателей
определяющими
факторами
будут: соотношение
цены и полезного
эффекта от
использования
продукции,
надежность
в эксплуатации,
простота
использования,
цена продукта.
В настоящее
время система
более конкурентоспособна
во втором из
выделенных
сегментов. При
выборе ценовой
политики следует
учитывать
специфику
данного сегмента
рынка. Цена
продукта не
должна быть
чрезмерно
завышена.
Для
продвижения
товара на рынке
используется
реклама в газетах,
для заинтересовавшихся
лиц проводятся
демонстрации.
5.4 Организационный
план работы
по реализации
проекта и определение
стоимости его
разработки.
Для
определения
трудоемкости
выполнения
данной работы
необходимо
составить
перечень всех
этапов, определить
трудоёмкость
на каждом этапе
работы (человеко-дни).
Трудоемкость
выполнения
всей работы
складывается
из трудоемкости
отдельных
этапов работы.
Таблица
1
Трудоемкость
работ по разработке
проекта
|
Наименование
работ
|
Трудоемкость,
чел./дни
|
Главный
специалист
|
Инженер
|
Разработка
технического
задания
|
2
|
3
|
Разработка
методов решения
задачи. Выбор
языка программирования.
|
– |
6
|
Изучение
литературы
|
– |
45
|
Разработка
структуры
решения задачи
|
– |
24
|
Создание
интерфейса
программы
|
1
|
2
|
Разработка
основных модулей
программы
|
– |
20
|
Тестирование
и отладка основных
модулей программы
|
1
|
6
|
Тестирование
и отладка всей
программы в
целом
|
1
|
3
|
Составление
технической
документации
|
1
|
30
|
Сдача
проекта
|
1
|
1
|
ИТОГО:
|
7
|
140
|
На
основе трудоемкости
выполнения
работ по разработке
системы рассчитываются
издержки на
оплату труда
ее исполнителей,
являющиеся
одной из основных
статей калькуляции
себестоимости
разработки.
5.5 Расчет
себестоимости
разработки
проекта.
Себестоимость
определяется
по фактическим
затратам,
произведенным
за счет собственных
финансовых
средств предприятия.
В основе определения
лежит перечень
выполненных
работ и трудоемкость
их выполнения.
Калькуляция
себестоимости
системы осуществляется
по следующим
статьям: материалы
с учетом
транспортно-заготовительных
расходов, основная
и дополнительная
заработная
плата основных
исполнителей
работы; отчисления
на социальные
нужды; расходы
на служебные
командировки;
оплата услуг
сторонних
организаций,
привлекаемых
для выполнения
данной разработки;
прочие прямые
затраты; накладные
расходы.
Стоимость
основных и
вспомогательных
расходных
материалов,
необходимых
для выполнения
разработки,
определяется,
исходя из величины
их расхода,
действующих
цен и транспортно-заготовительных
расходов. Величина
транспортно-заготовительных
расходов принимается
равной 10% стоимости
материалов,
полуфабрикатов
и комплектующих
изделий.
Калькуляция
расходов по
статье "Материалы"
приведены в
таблице
2.
Таблица
2
Калькуляция
расходов по
статье "Материалы"
|
Материалы
|
Единица
измерения
|
Количество
|
Цена,
руб.
|
Сумма,
руб.
|
Бумага
писчая
|
пачка
|
2
|
100
|
200
|
Картридж
для принтера
|
шт.
|
1
|
1200
|
700
|
Дискеты
|
шт.
|
1
|
10
|
10
|
ИТОГО:
|
|
|
|
910
|
Транспортно-заготовительные
расходы, 10%
|
91
|
ВСЕГО:
|
|
1001
|
В качестве
расходов на
оплату услуг
сторонних
организаций
при выполнении
данной разработки
выступает
арендная плата
за использование
машинного
времени.
Величина
арендной платы
рассчитывается
по формуле:
САР
= tАР
* РАР
где
САР
- сумма арендной
платы, р.;
tАР
- время аренды
ПЭВМ = 600 ч.;
РАР
- часовая ставка
арендной платы
- 2,8 р/час.
Величина
часовой ставки
арендной платы
определяется
по договору
между арендатором
и арендодателем.
САР
= 600 * 2,8 = 1680 р.
Основная
и дополнительная
заработная
плата непосредственный
исполнителей
рассчитывается
на основании
следующих
данных:
трудоемкость
выполнения
работ ТСП
и
ТИНЖ
(по таблице
1);
дневная
ставка главного
специалиста
ДСП
= 40 р;
дневная
ставка инженера
ДИНЖ
= 20 р;
процент
дополнительной
заработной
платы - 12%;
процент
отчисления
на социальные
нужды - 39 %;
процент
накладных
расходов (по
данным предприятия)
- 33%.
Основная
заработная
плата исполнителей
(СЗО)
рассчитывается
по формуле:
СЗО
= ТСП
* ДСП
+ ТИНЖ
* ДИНЖ
где
ТСП
и
ТИНЖ
- соответственно,
трудоемкость
выполнения
работ по реализации
данной разработки
главным специалистом
и инженером,
чел/дн.
СЗО
= 7 * 40 + 140 * 20 = 3080 р.
Дополнительная
заработная
плата рассчитывается
по формуле:
СЗД
= 3080 * 0,12 = 369,6 р.
Отчисления
на социальные
нужды:
ССН
= (3080 + 369,6) * 0,39 = 1345,3 р.
Расходов
на служебные
командировки
нет. Накладные
расходы рассчитываются
по формуле:
СНР
= (3080 + 369,6) * 0,33 = 1138,4 р.
На основании
вышеприведенных
данных составлена
калькуляция
себестоимости
разработки
и сведена в
таблицу.
Таблица
3
Калькуляция
себестоимости
разработки
|
Затраты
|
Сумма,
руб.
|
Материалы
|
1001
|
Основная
заработная
плата
|
3080
|
Дополнительная
заработная
плата
|
369,6
|
Отчисления
на социальные
нужды
|
1345,3
|
Аренда
машинного
времени
|
1680
|
Накладные
расходы
|
1138,4
|
ИТОГО
себестоимость:
|
8614,3
|
5.6 Прогноз
финансовых
показателей.
5.6.1 Установление
исходных предложений.
Оптимистический
вариант прогноза
предполагает,
что проект был
быстро и хорошо
воспринят на
рынке. Сегмент
рынка, описанный
выше, был завоеван,
объем продаж
вырос. Появилась
возможность
снизить затраты
на рекламу. По
результатам
маркетингового
исследования
установлено
ожидаемое
увеличение
объема продаж.
Пессимистический
вариант прогноза
предполагает,
что на рынке
появились
конкурентные
продукты, также
ориентированные
на данный сегмент,
и, благодаря
лучшей рекламе,
ценовой политике,
или предоставлению
дополнительных
возможностей
заняли более
выгодное положение,
чем разработанный
проект. Для
укрепления
позиций разработанного
продукта на
рынке должны
быть увеличены
расходы на
рекламу, в результате
чего предполагается
увеличение
объема продаж.
Реалистический
прогноз. Проект
занял устойчивую
конкурентную
позицию в новом
сегменте рынка,
объем продаж
возрос.
Ожидаемые
значения изменения
объемов продаж
по интервалам
инвестиционного
периода на
основе пессимистического,
оптимистического
и реалистического
прогнозов,
произведенных
в ходе маркетинговых
исследований,
приведены в
таблице
4.
Длительность
инвестиционного
периода в связи
с непредсказуемостью
изменений
законодательства
предсказать
достаточно
сложно, однако,
на основании
произведенных
исследований
и проследив
статистику
можно предположить,
что длительность
инвестиционного
периода для
данного проекта
будет 2 года.
Интервалы
инвестиционного
периода 3 месяца.
Таблица
4
Ожидаемые
объемы продаж
по прогнозным
оценкам
Пока-затель
|
Вариант
прогноза
|
Значение
показателя
по интервалам
инвестиционного
периода
|
0
|
1
|
2
|
3
|
4
|
5
|
Цена
(р.)
|
-
|
-
|
-
|
600
|
600
|
600
|
600
|
Ожида-емый
объем продаж
(шт.)
|
Опитими-стический
|
-
|
-
|
20
|
30
|
30
|
30
|
Ожида-емый
объем продаж
(шт.)
|
Пессими-стический
|
-
|
-
|
15
|
20
|
16
|
16
|
Ожида-емый
объем продаж
(шт.)
|
Реалисти-ческий
|
-
|
-
|
16
|
18
|
20
|
20
|
5.6.2 Определение
потребности
в начальном
капитале.
На основании
прогнозных
оценок объемов
продаж определяется
потребность
в начальном
капитале, необходимом
для реализации
проекта.
Специфика
данного производственного
процесса требует
использования
ПЭВМ, принтера,
множительного
аппарата и
помещения для
проведения
этих работ.
Для
копирования,
размножения
и изменения,
при необходимости,
конфигурации
разработанного
проекта с целью
реализации
необходимы
также начальный
запас расходных
материалов
и реклама.
Потребность
в основном
капитале формируется
за счет средств,
израсходованных
на разработку
проекта - 8614,3 р.,
а также дополнительных
средств, необходимых
на приобретение
ПЭВМ и принтера.
Так как ПЭВМ
и принтер могут
быть использованы
не только для
копирования
файлов, печати
сопроводительной
документации
и модернизации,
целесообразным
представляется
отнести на
данный проект
часть стоимости
этих основных
средств, пропорционально
времени их
использования
в рамках реализации
данного проекта.
При
стоимости
компьютера
класса Pentium
166 с монитором
14" - 8000 р, сроке службы
- 5 лет, времени
использования
на 1 экземпляр
продаваемого
продукта, равном
в среднем 0,5 часа,
потребность
в ПЭВМ для реализации
проекта в пределах
данного инвестиционного
периода при
оптимистическом
объеме продаж
составит КПЭВМ.
В данном
случае потребность
в начальном
капитале на
ПЭВМ для реализации
проекта составит
для оптимистического
варианта прогноза:
КПЭВМ
= (8000 / (5 * 1995)) * 0,5 * (20 + 3 *30) = 44,1 р.
Для
пессимистического
варианта прогноза:
КПЭВМ
= (8000 / (5 * 1995)) * 0,5 * (15 + 20 + 2 * 16) = 26,9 р.
Для
реалистического
варианта прогноза:
КПЭВМ
= (8000 / (5 * 1995)) * 0,5 * (16 + 18 + 2 * 20) = 29,7 р.
Аналогично
определяется
потребность
в начальном
капитале на
принтер стоимостью
2500 р при использовании
его для распечатки
документации
по одному экземпляру
в течение 0,5 ч.
Потребность
в начальном
капитале КПРИНТЕР
для реализации
проекта составит
для оптимистического
варианта прогноза:
КПРИНТЕР
= (2500 / (5 * 1995)) * 0,5 * (20 + 3 * 30) = 13,8 р.
Для
пессимистического
варианта прогноза:
КПРИНТЕР
= (2500 / (5 * 1995)) * 0,5 * (15 + 20 + 2 * 16) = 8,4 р.
Для
реалистического
варианта прогноза:
КПРИНТЕР
= (2500 / (5 * 1995)) * 0,5 * (16 + 18 + 2* 20) = 9,3 р.
Потребность
в начальном
оборотном
капитале:
оптимистический
- 400 р;
пессимистический
- 500 р;
реалистический
- 450р.
Сведения
о потребности
в начальном
капитале для
данного проекта
сведены в таблицу.
Таблица
5
Потребность
в начальном
капитале
|
Статьи
|
Варианты
прогноза
|
Оптимистический
|
Пессимистический
|
Реалистический
|
ОСНОВНОЙ
КАПИТАЛ
|
Разработка
системы, р
|
8614,3
|
8614,3
|
8614,3
|
ПЭВМ,
р
|
44,1
|
26,9
|
29,7
|
Принтер,
р
|
13,8
|
8,4
|
9,3
|
ИТОГО:
|
8672,2
|
8649,6
|
8653,3
|
ОБОРОТНЫЙ
КАПИТАЛ
|
Материалы,
р
|
200
|
200
|
200
|
Реклама,
р
|
400
|
500
|
450
|
ВСЕГО:
|
9272,2
|
9349,6
|
9303,3
|
Затраты
на разработку
системы, а также
на первоначальный
запас материалов
и рекламу
предполагается
покрыть за счет
собственных
средств предприятия.
5.6.3 Производство
и реализация.
Продукт
поставляется
на дистрибутивной
дискете с приложением
технической
документации.
Таким образом,
процесс производства
сводится к
созданию
дистрибутивной
дискеты и распечатке
комплекта
документации.
Реализация
продукта происходит
непосредственно
после переноса
файла на дискету
и копирования
документации.
5.6.4 Определение
производственно-сбытовых
издержек.
Производственно-сбытовые
издержки определяются
на основе
пессимистического
варианта прогноза
реализации
комплекса, как
сумма переменных
и постоянных
издержек.
Производственно-сбытовой
процесс связан
с необходимостью
осуществлять
как переменные,
так и постоянные
издержки.
Переменные
издержки
рассчитываются
на единицу
продаваемой
продукции,
постоянные
- на прогнозируемые
объемы продаж
в соответствующих
интервалах
инвестиционного
периода.
В состав
переменных
издержек входят:
затраты
на дискету, на
которую переписывается
программа - 10
р.;
затраты
на бумагу для
распечатки
и ксерокопирования
технической
документации
3 р.
основная
и дополнительная
заработная
плата инженера-программиста,
производящего
перенос программы
на дискету и
размножение
документации.
Эти затраты
рассчитываются,
исходя из
трудозатрат
на выполнение
указанных
работ и часовой
ставки инженера-программиста
по формуле:
СЗО
= (t1
+ t2)
* ЧС * (1 + НД
/ 100)
где
t1
и t2
- трудоемкости
переноса файла
на дискету и
копирования
документации,
чел/ч; ЧС - часовая
ставка оплаты
труда инженера-программиста,
р; НД
- норматив
дополнительной
заработной
платы, доли
единицы (0,12).
СЗО
= (1 + 0,5) * 2,5 * (1 + 0,12) = 4,2 р.
ССН
= СЗО
* НСН
/ 100 =4,2 * 0,39 = 1,64 р.
Постоянные
издержки, связанные
с производством
и сбытом комплекса,
включает в
себя:
арендную
плату за занимаемое
помещение в
сумме 80,0 р в месяц,
что дает в пересчете
на один интервал
инвестиционного
периода, равный
3 месяцам, 240 р;
амортизацию
оборудования,
которая определяется
по государственным
номам по методу
равномерного
списания. За
один интервал
инвестиционного
периода сумма
амортизации
составит:
САМ
= КОБ
* (НАОБ
/ 100) * (tИНТ
/ 12)
где
КОБ
- балансовая
стоимость
основного
средства, р;
НАОБ
- норма амортизации,
%; tИНТ
- количество
месяцев в одном
интервале, мес.
Таким
образом, сумма
амортизации
составит:
САМ
ПЭВМ
= 26,9 * 20 *3 / (100 * 12) = 1,35 р.
САМ
ПРИНТЕР
= 8,4 * 20 *3 / (100 * 12) = 0,42 р.
административно-хозяйственные
расходы включают
в себя основную
и дополнительную
заработную
плату с начислениями
на социальные
нужды административно-управленческую
персонала;
оплату освещения,
отопления в
занимаемом
помещении,
телефона, телефакса,
канцелярских
расходов и
т.п. и составляют
в расчете на
один интервал
инвестиционного
периода 1500 р.
Все эти
данные приведены
в таблице 6. В
этой таблице
приводятся
результаты
расчетов переменных
и постоянных
производственных
издержек для
пессимистического
варианта прогноза.
Таблица
6
Производственно-сбытовые
издержки для
пессимистического
варианта прогноза
Статьи
|
Величина
по интервалам
инвестиционного
варианта прогноза
|
0
|
1
|
2
|
3
|
4
|
5
|
ПЕРЕМЕННЫЕ
ИЗДЕРЖКИ
|
Материалы,
р
|
-
|
-
|
13
|
13
|
13
|
13
|
Основная
и дополнительная
заработная
плата, р.
|
-
|
-
|
4,2
|
4,2
|
4,2
|
4,2
|
Отчисления
на социальные
нужды, р.
|
-
|
-
|
1,64
|
1,64
|
1,64
|
1,64
|
ИТОГО
(с
учетом ожидаемого
объема продаж):
|
-
|
-
|
282,6
|
376,8
|
301,4
|
301,4
|
ПОСТОЯННЫЕ
ИЗДЕРЖКИ
|
Арендная
плата за помещения,
р.
|
-
|
-
|
240
|
240
|
240
|
240
|
Реклама,
р
|
-
|
-
|
300
|
200
|
160
|
60
|
Амортизация
|
-
|
-
|
1,8
|
1,8
|
1,8
|
1,8
|
Административно-хозяйственные
расходы, р
|
-
|
-
|
1500
|
1500
|
1500
|
1500
|
ИТОГО
|
-
|
-
|
2041,8
|
1941,8
|
1901,8
|
1801,8
|
ВСЕГО,
р:
|
-
|
-
|
2324,4
|
2318,6
|
2203,2
|
2103,2
|
5.6.5 Оценка
ликвидационной
стоимости
основных средств.
На момент
завершения
проекта основные
средства
ликвидироваться
не будут.
5.6.6 Определение
порога безубыточности
прогнозируемого
производства.
Объем
продаж продукта,
обеспечивающий
безубыточное
производство,
определяется
на основании
данных, полученных
для пессимистического
варианта прогноза.
При
этом производственно-сбытовые
издержки составляют,
в соответствии
с данными,
представленными
в таблице
6 -
8949,3 р.
Определяется
величина покрытия
постоянных
издержек по
формуле:
SПОКР
= P
- VC0
где
P
- рыночная цена
продукта, р;
VC0
- переменные
издержки за
единицу продукции,
р.
SПОКР
= 600 - 18,8 = 581,2 р.
Минимальный
объем продаж
продукции,
достаточный
для того, чтобы
покрыть валовые
издержки и
обеспечить
безубыточность
производства,
определяется
по формуле:
QТБ
= FС
/ SПОКР
где
FC
- постоянные
издержки по
пессимистическому
варианту прогноза,
р.
QТБ
= 8949,3 / 581,2 = 15,4
То есть
минимальный
объем количества
проданных
продуктов,
достаточный
для покрытия
валовых издержек
и обеспечивающий
безубыточность
производства
составляет
16 шт.
Таким
образом, можно
сделать предварительный
вывод о том,
что, начиная
с четвертого
интервала,
реализация
продукции на
прогнозируемом
сегменте рынка
даже при прогнозируемом
пессимистическом
варианте объема
продаж обещает
быть безубыточной.
5.6.7 Определение
текущих расходов
и доходов по
проекту.
Текущие
расходы и доходы
по проекту
определяются
также на основании
пессимистических
прогнозных
оценок, исходя
из предположения
о том, что если
даже в этом
случае доходы
будут достаточны
для обеспечения
эффективности
проекта, то
реалистический
вариант и, тем
более, оптимистический
- принесут
дополнительные
доходы.
Таблица
7
Доходы
и расходы от
реализации
проекта - пессимистический
прогноз
Статьи
|
Значение
показателя
по интервалам
инвестиционного
периода
|
0
|
1
|
2
|
3
|
4
|
5
|
Ожидаемые
объемы продаж,
шт.
|
-
|
-
|
15
|
20
|
16
|
16
|
Цена,
р.
|
-
|
-
|
600
|
600
|
600
|
600
|
Выручка
от реализации,
р
|
-
|
-
|
9000
|
12000
|
9600
|
9600
|
-
НДС (20%), р.
|
-
|
-
|
1500
|
2000
|
1600
|
1600
|
Производственно-сбытовые
издержки, р
|
-
|
-
|
2324,4
|
2318,6
|
2203,2
|
2103,2
|
Балансовая
прибыль, р.
|
-
|
-
|
5175,6
|
7681,4
|
5796,8
|
5796,8
|
Налог
на прибыль,
р.
|
-
|
-
|
1811,5
|
2688,5
|
2028,9
|
2028,9
|
Нераспределенная
прибыль, р.
|
-
|
-
|
3364,1
|
4992,9
|
3767,9
|
3767,9
|
Убыток
|
-
|
-
|
-
|
-
|
-
|
-
|
5.6.8 Прогноз
движения денежной
наличности.
Прогноз
движения денежной
наличности
производится
на основании
данных, полученных
ранее в предыдущих
расчетах.
Поступления
денежных средств
от реализации
принимаются
на основании
пессимистического
варианта прогноза.
Выплаты
в виде инвестиций
складываются
в нулевом и
первом интервалах
из средств,
затраченных
на разработку
системы, а также
средств, необходимых
для приобретения
основных средств
и начального
запаса оборотных
средств по
оптимистическому
варианту прогноза
(таблица
5).
Производственно
сбытовые издержки
принимаются
по данным таблицы
6 с уменьшение
на сумму амортизации.
Величина
налоговых
выплат складывается
из НДС и налога
на прибыль
(таблица
7).
Результаты
расчетов по
прогнозу движения
денежной наличности
сведены в таблицу
8.
Таблица
8
Прогноз
движения денежной
наличности
Показатели
|
Значение
показателя
по интервалам
инвестиционного
периода
|
0
|
1
|
2
|
3
|
4
|
5
|
ПОСТУПЛЕНИЯ
ДЕНЕЖНЫХ СРЕДСТВ
|
-
|
-
|
9000
|
12000
|
9600
|
9600
|
В
том числе:
|
|
Выручка
от реализации,
р
|
-
|
-
|
9000
|
12000
|
9600
|
9600
|
Ликвидная
стоимость
основных средств
(инвестируемого
капитала)
|
-
|
-
|
-
|
-
|
-
|
-
|
ВЫПЛАТЫ
ДЕНЕЖНЫХ СРЕДСТВ
|
4636,1
|
4636,1
|
5634,1
|
7005,3
|
5830,3
|
5830,3
|
-
инвестиции
|
4636,1
|
4636,1
|
-
|
-
|
-
|
-
|
-
производственно-сбытовые
издержки (без
учета амортизации)
|
-
|
-
|
2322,6
|
2316,8
|
2201,4
|
2101,4
|
-
налоги
|
-
|
-
|
3311,5
|
4688,5
|
3628,9
|
3628,9
|
ЧИСТЫЙ
ДЕНЕЖНЫЙ ПОТОК
(ЧДП)
|
-4636,1
|
-4636,1
|
3365,9
|
4994,7
|
3769,7
|
3769,7
|
ЧДП
(нарастающим
итогом)
|
-4636,1
|
-9272,2
|
-5906,3
|
-911,6
|
2858,1
|
6627,8
|
5.6.9 Оценка
экономической
эффективности
проекта.
Прогноз
движения денежной
наличности
показывает,
что период
возврата инвестиций
составит 9 месяцев.
Рентабельность
инвестиций
ROI
определяется
по формуле:
ROI
= (1 / 9349,6) * 15892,8 * (1 / 6) = 0,28
28%
Интегральный
экономический
эффект определяется
по формуле:
NPV
= -9349,6 + ((15892,8 + 7,2) / 1,1^6) = 374,5
р.
При
годовой ставке
дисконтирования
0,1 (без учета
инфляции).
5.7
Выводы.
Произведенные
маркетинговые
исследования
и расчеты показали,
что разработанный
продукт будет
иметь определенный
спрос в пределах
определенного
сегмента рынка.
Расчеты
показали, что
при ориентации
на пессимистический
вариант прогноза
производства
и реализации
продукции,
полученные
финансовые
показатели
характеризуют
период возврата
инвестиций
- 9 месяцев при
их рентабельности,
равной 28%.
Интегральный
экономический
эффект может
составить 374,5
р..
При
более благоприятной
ситуации на
рынке и приближении
производства
и реализации
к значениям
реалистических
и оптимистических
оценок можно
ожидать увеличения
чистого денежного
потока и, соответственно,
рентабельности
инвестиций
и интегрального
экономического
эффекта.
Таким
образом, реализация
проекта экономически
целесообразна.
|