Организация работы с распределенной БД через WEB-интерфейс

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

Организация работы с распределённой БД через WEB-интерфейс



Введение

автоматизация программа интерфейс

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

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

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

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

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

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

· Имеется набор логически связанных разделяемых данных.

· Сохраняемые данные разбиты на некоторое количество фрагментов.

· Может быть предусмотрена репликация фрагментов данных.

· Фрагменты и их копии распределяются по разным узлам.

· Узлы связаны между собой сетевыми соединениями.

· Доступ к данным на каждом узле происходит под управлением СУБД.

· СУБД на каждом узле способна поддерживать автономную работу локальных приложений.

· СУБД каждого узла поддерживает хотя бы одно глобальное приложение.

Но нет необходимости в том, чтобы на каждом из узлов системы существовала своя собственная локальная база данных, что и показано на примере топологии распределенной СУБД, представленной на рисунке:

Рис. 1 Топология распределенной СУБД на локальном уровне

Поэтому наиболее удобно располагать БД, с которой ведётся работа на сервере. В данном проекте доступ будет осуществляться через WEB-интерфейс, что позволит работать с информацией удалённо. Ниже представлен рисунок удалённого доступа к БД.

Рис. 2 Топология распределенной СУБД через WEB-интерфейс, как на локальном уровне, так и удалённо

Таблица 1. Преимущества и недостатки распределенных СУБД

Преимущества Недостатки	Преимущества Недостатки
Отображение структуры организации	Повышение сложности
Разделяемость и локальная автономность	Увеличение стоимости
Повышение доступности данных	Проблемы защиты
Повышение надежности	Усложнение контроля над целостностью данных
Повышение производительности	Отсутствие стандартов
Экономические выгоды	Недостаток опыта
Модульность системы	Усложнение процедуры разработки базы данных



1. Проектирование информационной системы

1.1 Анализ технического задания

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

Полное наименование системы:

Наименование системы: «работы с распределённой БД через WEB-интерфейс».

Наименование заказчика (пользователя) системы:

Отдел АСУ Костромского Государственного Технологического Университета

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

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

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

Первое тестирование системы планируется на 25.05.2011.

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

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

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

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

- отчет об исследовании предметной области (до 18 марта 2011 г.);

- структурная, функциональная, информационная модели предметной области (до 8 апреля 2011 г.);

- пояснительная записка (до 5 июня 2011 г.).

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

Назначение системы

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

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

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

Для достижения целей в процессе работы решаются следующие задачи:

· составление структурной, функциональной и информационной моделей предметной области;

· анализ моделей «как есть», составление моделей «как должно быть»;

· выбор методов и технологий проектирования,

· проектирование и реализация программной части;

· расчёт цены программного продукта.

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

Характеристики объектов автоматизации

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

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

Требование к структуре и функционированию системы

Информационная система работы с распределённой БД через WEB-интерфейс представляет собой приложение из двух частей: базы данных, хранящей информацию, и пользовательской оболочки, предназначенной для работы и управления базой данных. Руководителем работы была поставлена задача создания системы на основе архитектуры «клиент - сервер».

· Разрабатываемая система располагается на сервере;

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

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

Обмен данными между БД и приложением осуществляется посредством SQL - запросов.

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

Диагностика системы должна проводиться квалифицированным обслуживающим персоналом (системным администратором).

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

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

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

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

Показатели назначения

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

Требование к надежности

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

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

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

Требования по безопасности, эргономике и технической эстетике

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

ГОСТ Р 50948-96;

ГОСТ Р 50949-96;

ГОСТ Р 50923-96;

СанПиН 2.2.2.542-96.

Требования к защите от влияния внешних воздействий

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

Требования к функциям (задачам), выполняемым системой

Компоненты программного комплекса выполняют следующие функции:

· файл базы данных - хранение информации;

· клиентское приложение (сохраненная WEB-страница или закладка в браузере) - обеспечение доступа к данным и выполнение вычислений.

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

Для ввода системы в эксплуатацию необходимо:

· сохраненная WEB-страница или закладка в браузере (для быстрого доступа к БД);

· установить дополнительное приложение Microsoft SQL Server 2008 R2.

Требования к интерфейсу

В этом разделе проанализируем, какие общие требования предъявляются к интерфейсу программ.

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

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

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

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

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

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

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

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

Дизайн программного интерфейса должен обеспечивать минимизацию усилий пользователя при выполнении работы и приводить:

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

· уменьшению времени навигации и выбора команды,

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

· увеличению длительности устойчивой работы пользователя и др.

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

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

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

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

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

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

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

Порядок контроля и приемки системы

Прием и контроль разработанной ИС производится на основании приемных испытаний комиссией, сформированной из представителей заказчика (отдел АСУ КГТУ).

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

Для ввода системы в действие необходимо:

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

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

· настроить сетевые соединения с интернет;

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

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

1.2 Технико-организационное обоснование

Описание процессов предприятия-заказчика посредством диаграмм IDEF0

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

Рис. 3. Графическое представление процесса

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

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

На основании проведенного обследования деятельности предприятия-заказчика была построена модель предприятия «как есть» рис. 4.

Рис. 4. IDEF0-диаграмма предприятия-заказчика «Как есть»

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

Сформулируем цель моделирования: описать функционирования системы, которое было бы понятно ее пользователю, не вдаваясь в подробности, связанные с реализацией. Модель будем строить с точки зрения пользователей (обычный пользователь - Operator, привилегированный пользователь - Users, и администратор системы - Admin).

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

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

Рис. 5. IDEF0-диаграмма предприятия-заказчика «Как должно быть»



Таким образом, определим контекстную диаграмму системы

Рис. 6. Контекстная диаграмма системы

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

* Определение уровня доступа в систему.

* Выбор подсистемы.

* Обращение к подсистеме.

* Изменение БД (при необходимости). Получим диаграмму, изображенную на рис. 7.

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

Рис. 7. Декомпозиция работы «Обслуживание, пользователя системы»

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

Рис. 8. Декомпозиция работы «Определение уровня доступа в систему»

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

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

* Открытие БД.

* Выполнение запроса.

* Генерация отчетов.

После открытия БД необходимо сообщить системе об установлении соединения с БД, после чего выполнить запрос и сгенерировать отчеты для пользователя (рис. 9.).

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

Рис. 9. Декомпозиция работы «Обработка запроса пользователя»

1.3 Теоретико-методические основы проектирования ИС

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

Выбор PHP

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

· традиционностью;

· простотой;

· эффективностью;

· безопасностью;

· гибкостью.

Существует еще одна «характеристика», которая делает РНР особенно привлекательным: он распространяется бесплатно! Причем, с открытыми исходными кодами (Open Source).

Традиционность

Язык РНР будет казаться знакомым программистам, работающим в разных областях. Многие конструкции языка позаимствованы из Си, Perl.

Код РНР очень похож на тот, который встречается в типичных программах на С или Pascal. Это заметно снижает начальные усилия при изучении РНР. PHP - язык, сочетающий достоинства Perl и Си и специально нацеленный на работу в Интернете, язык с универсальным (правда, за некоторыми оговорками) и ясным синтаксисом.

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

Простота

Сценарий РНР может состоять из 10 000 строк или из одной строки - все зависит от специфики вашей задачи. Вам не придется подгружать библиотеки, указывать специальные параметры компиляции или что-нибудь в этом роде. Механизм РНР просто начинает выполнять код после первой экранирующей последовательности (<?) и продолжает выполнение до того момента, когда он встретит парную экранирующую последовательность (?>). Если код имеет правильный синтаксис, он исполняется в точности так, как указал программист.

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

Большое разнообразие функций PHP избавят вас от написания многострочных пользовательских функций на C или Pascal.

Эффективность

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

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

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

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

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

1. Средства безопасности системного уровня

В РНР реализованы механизмы безопасности, находящиеся под управлением администраторов; при правильной настройке РНР это обеспечивает максимальную свободу действий и безопасность. РНР может работать в так называемом безопасном режиме (safe mode), который ограничивает возможности применения РНР пользователями по ряду важных показателей. Например, можно ограничить максимальное время выполнения и использование памяти (неконтролируемый расход памяти отрицательно влияет на быстродействие сервера). По аналогии с cgi-bin администратор также может устанавливать ограничения на каталоги, в которых пользователь может просматривать и исполнять сценарии РНР, а также использовать сценарии РНР для просмотра конфиденциальной информации на сервере (например, файла passwd).

2. Средства безопасности уровня приложения

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

Гибкость

Поскольку РНР является встраиваемым (embedded) языком, он отличается исключительной гибкостью по отношению к потребностям разработчика. Хотя РНР обычно рекомендуется использовать в сочетании с HTML, он с таким же успехом интегрируется и в JavaScript, WML, XML и другие языки. Кроме того, хорошо структурированные приложения РНР легко расширяются по мере необходимости (впрочем, это относится ко всем основным языкам программирования).

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

Поскольку РНР не содержит кода, ориентированного на конкретный web-сервер, пользователи не ограничиваются определенными серверами (возможно, незнакомыми для них). Apache, Microsoft IIS, Netscape Enterprise Server, Stronghold и Zeus - РНР работает на всех перечисленных серверах. Поскольку эти серверы работают на разных платформах, РНР в целом является платформенно-независимым языком и существует на таких платформах, как UNIX, Solaris, FreeBSD и Windows 95/98/NT/2000/XP/2003.

Наконец, средства РНР позволяют программисту работать с внешними компонентами, такими как Enterprise Java Beans или СОМ-объекты Win32. Благодаря этим новым возможностям РНР занимает достойное место среди современных технологий и обеспечивает масштабирование проектов до необходимых пределов.

Бесплатное распространение

Стратегия Open Source, и распространение исходных текстов программ в массах, оказало несомненно благотворное влияние на многие проекты, в первую очередь - Linux, хотя и успех проекта Apache сильно подкрепил позиции сторонников Open Source. Сказанное относится и к истории создания РНР, поскольку поддержка пользователей со всего мира оказалась очень важным фактором в развитии проекта РНР.

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

Альтернативные реализации

В силу популярности языка PHP и желания увеличить быстродействие основанных на нём WEB-приложений, создано несколько альтернативных компиляторов, близких к PHP языку. Так в феврале 2010 года компания Facebook открыла свой компилятор PHP - HipHop (HPHP, Hyper-PHP) генерирующий код на C++, с последующей компиляцией в машинный код с помощью gcc.

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

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

Таблица 2. Альтернативные реализации PHP.

Название	Лицензия	Результат компиляции
HipHop	PHP License	C++, машинный код
Roadsend PHP	GPL/LGPL	C, машинный код
Phalanger	Ms SS-PL (Shared source)	Microsoft IL
Quercus (в составе веб-сервера Resin)	GPL или коммерческая	JVM
PHC	BSDL	C, машинный код
Pipp	Artistic License и GNU GPL	Parrot

HipHop for PHP (букв. HipHop для языка PHP) - транслятор исходного кода, созданный компанией Facebook. HipHop программно превращает исходный код, написанный на языке PHP, в высоко оптимизированный код на C++, а затем использует компилятор g++ для его компиляции. HipHop включает в себя транслятор кода, альтернативную реализацию среды выполнения PHP, а также множество наиболее распространённых расширений PHP (англ. PHP Extensions), переписанных на C с целью повышения производительности.

HipHop был создан разработчиками социальной сети Facebook для экономии ресурсов их серверов. Код было решено выпустить 2 февраля 2010 года в виде открытого ПО. Однако релиз кода был задержан из-за проблем с очисткой исходного кода от facebook-специфичных расширений. Исходный код проекта стал доступен 20 февраля 2010 года.

Ими же был разработан HPHPi, представляющий собой экспериментальный интерпретатор PHP, предназначенный для отладки и быстрого прототипирования кода. Затем они разработали HHVM - экспериментальную виртуальную машину для исполнения и JIT оптимизации PHP кода.

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

Roadsend Compiler (компилятор) позволяет создавать WEB-приложения, которые будут работать либо в среде FastCGI, либо с использованием встроенного web-сервера «MicroServer». Возможно также создание приложений с графическим интерфейсом при помощи PHP-GTK или других библиотек, и консольных приложений.

Компилятор Roadsend PHP написан на языке Scheme и компилируется с использованием оптимизирующего scheme-транслятора Bigloo.

Phalanger - это компилятор языка PHP для.NET, представляет собой язык и реализацию стандартной библиотеки совместимой с большинством существующих PHP-приложений. Также поддерживает вызов родных PHP4 расширений, что дает возможность использовать большинство PHP-функций и классов. Phalanger, для внутренних нужд, использует ASP.NET фреймворк, но только для реализации управления HTTP запросов и ответов, сессий и куки. Рендеринг страниц все еще такой же как в PHP, что дает программисту полный контроль над генерируемым кодом, а также совместимость с уже существующим кодом. Начиная с версии 2.0, Phalanger поддерживает полную функциональную совместимость с.NET. Это значит, что программист имеет доступ почти ко всем.NET-классам из PHP-приложения. Поддержка совместимости с.NET потребовала расширить язык PHP так, чтобы из него можно было работать с такими особенностями архитектуры.NET как пространство имён, обобщенные типы. Это расширение получило имя PHP/CLR.

Благодаря полной поддержке.NET появилась возможность разрабатывать все виды.NET-приложений на языке PHP в том числе с пользовательским интерфейсом основанным на Windows Forms, библиотеки классов и web-приложения на инфраструктуре ASP.NET.

Существует два режима компиляции: унаследованный (legacy) и чистый (pure). «Унаследованный режим» полностью совместим со стандартным PHP, однако использовать скрипты скомпилированные в этом режиме немного сложнее. Для того, чтобы сделать использование PHP объектов из C# как можно проще, был введен «чистый режим» при котором программист должен следовать нескольким дополнительным правилам (таким как указывать все исходные файлы во время компиляции вместо использования директивы include), что обеспечит способность прямого взаимодействия со средой.NET, то есть позволит использовать классы написанные на PHP прямо из C#.

Quercus представляет новый смешанный подход Java/PHP к веб-приложениям и услугам, где Java и PHP плотно объединяются друг с другом. Приложения PHP могут пользоваться Java библиотеками и технологиями как JMS, EJB, структуры SOA, Hibernate, и Spring. Эта революционная способность сделана возможной, потому что

1) код PHP интерпретируется / собирается в Java, и

2) Quercus и его библиотеки написаны полностью в Java. Эта архитектура позволяет PHP и Java библиотекам говорить непосредственно друг с другом на уровне программы.

PHC является открытым источником компилятора PHP с поддержкой плагинов. Кроме того, он может быть использован для красивой печати или запутать код PHP как структуру для того, чтобы разработать приложения, которые обрабатываются PHP скриптами, или преобразовать PHP в XML и назад, обеспечивая обработку PHP скриптов с использованием XML инструментов.

PHC для программистов PHP:

· оптимизирует веб-приложение;

· поддерживает всю стандартную библиотеку PHP;

· красивая печать PHP кода;

· объединяет много скриптов PHP в единственный файл;

· оптимизация PHP код с помощью классической оптимизации компиляторов

PHC для разработчиков инструментов:

· анализирует, изменяет или переделает скрипты с помощью C + + плагинов.

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

Реляционные базы данных. Архитектура клиент-сервер

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

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

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

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

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

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

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

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

Всего существуют шесть форм нормализации:

· Первая нормальная форма (1НФ)

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

· Вторая нормальная форма (2НФ)

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

· Третья нормальная форма (3НФ)

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

· Нормальная форма Бойса-Кодда (НФБС)

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

Дальнейшая оптимизация таблиц баз данных должна сводится к полной декомпозиции таблиц.

· Четвертая нормальная форма (4НФ)

4НФ является частным случаем 5НФ, когда полная декомпозиция должна быть соединением двух проекций

· Пятая нормальная форма (5НФ)

Таблица находиться в 5НФ, если каждой её полной декомпозиции все проекции содержат возможный ключ. [11]

Архитектура клиент - сервер.

В сетевой архитектуре «клиент - сервер» БД размещается на компьютере-сервере сети (сервере или удалённом сервере) и называется также удалённой БД. Приложения, осуществляющее работу с этой БД, находится на компьютере пользователя. Приложение пользователя является клиентом, его также называют приложением - клиентом.

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

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

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

· В приложении отсутствует код, связанный с управлением БД, поэтому приложение упрощаются.

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

При работе в архитектуре «клиент - сервер» приложение должно:

· Устанавливать соединение с сервером и завершать его;

· Формировать полученные данные;

· Обрабатывать полученные данные. [13]

Обзор современных технологий

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

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

Технологии, применяемые в Web-клиентах

Одним из направлений развития Web-приложений стало размещение некоторой части логики приложения (такой как проверка корректности вводимых данных) в самом Web-клиенте, например в Web-браузере. В частности, современные Web-браузеры способны интерпретировать код на скриптовых языках, выполнять Java-апплеты и элементы управления ActiveX, использовать другие дополнения, такие как Macromedia Flash Player. Рассмотрим все эти возможности браузеров подробнее.

Скриптовые языки

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

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

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

Java-апплеты

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

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

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

Элементы управления ActiveX

Некоторые из современных браузеров (в частности, Microsoft Internet Explorer) могут служить контейнерами для элементов управления ActiveX - специальных COM-серверов, выполняющихся в адресном пространстве браузера и также получаемых в составе Web-страницы.

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

Естественно, Microsoft Internet Explorer обладает средствами ограничения возможностей выполнения элементов управления ActiveX, в том числе управления ими из кода на скриптовых языках. Однако для контроля безопасности их выполнения имеется еще одно средство, называемое электронной цифровой подписью. Цифровая подпись помещается внутрь элемента управления ActiveX, для чего требуется наличие соответствующего электронного сертификата. Электронная подпись, помимо сведений о фирме-производителе, содержит и другую полезную информацию. Так, например, если файл с элементом управления ActiveX после добавления электронной подписи был изменен, то об этом будет немедленно сообщено перед запуском такого элемента управления - при добавлении подписи к элементу управления ActiveX происходит вычисление контрольной суммы соответствующего файла. Отметим, однако, что в России в настоящее время нет авторизованных компаний, которые могли бы выдать электронный сертификат международного образца. Естественно, наличие электронного сертификата не гарантирует отсутствия потенциально опасного содержимого, но, по крайней мере, позволяет клиенту установить его источник.

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

Приложения Macromedia Flash

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

Модель безопасности приложений Flash основана на том, что Macromedia Flash Player, как и виртуальная Java-машина, выполняет приложения в ограниченном адресном пространстве, при этом выполняемые приложения не имеют доступа к файловой системе (кроме одного конкретного каталога, используемого Macromedia Flash Player для служебных целей) и другим ресурсам компьютера пользователя; исключение делается для микрофонов и видеокамер, однако пользователь должен дать разрешение на передачу данных, полученных с этих устройств. Доступ к сетевым ресурсам ограничивается доменом, с которого было получено приложение. Отметим, что приложения Flash также могут управляться с помощью кода JavaScript, присутствующего на той же странице. Сам Macromedia Flash Player для Microsoft Internet Explorer является элементом управления ActiveX и использует возможности элементов управления ActiveX для доступа к свойствам приложений Flash из скриптовых языков.

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

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

Технологии создания серверных частей Web-приложений

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

CGI

Common Gateway Interface (CGI) - это стандартный интерфейс, позволяющий выполнять серверные приложения, вызываемые через URL. Входной информацией для таких приложений служит содержимое HTTP-заголовка либо тело запроса, в зависимости от применяемого протокола. CGI-приложения генерируют HTML-код, который возвращается браузеру. Отметим, что в свое время широко использовался и термин «CGI-скрипт», происхождение которого объясняется тем, что подобные приложения писались на скриптовых языках типа Perl, выполняющихся, тем не менее, не в браузере, а на сервере. CGI-приложения можно создавать с помощью практически любого средства разработки, генерирующего консольные приложения для операционной системы, под управлением которой функционирует Web-сервер.