Публикация БД в Интернет

Автор работы: Пользователь скрыл имя, 05 Февраля 2014 в 19:13, дипломная работа

Краткое описание

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

Прикрепленные файлы: 9 файлов

~WRL3594.tmp

— 112.00 Кб (Скачать документ)

диплом.doc

— 3.38 Мб (Скачать документ)

Примерами сервером могут  служить:

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

Сервер локальной сети предоставляет ресурсы (услуги) рабочим  станциям и/или другим серверам.

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

      1. Системная архитектура "клиент-сервер"

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

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

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

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

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

Общим решением проблемы мобильности систем, основанных на архитектуре "клиент-сервер" является опора на программные пакеты, реализующие протоколы удаленного вызова процедур (RPC - Remote Procedure Call). При использовании таких средств обращение к сервису в удаленном узле выглядит как обычный вызов процедуры. Средства RPC, в которых, естественно, содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов, переводит вызов в последовательность сетевых взаимодействий. Тем самым, специфика сетевой среды и протоколов скрыта от прикладного программиста.

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

Если система реализована  на основе стандартного пакета RPC, она  может быть легко перенесена в  любую открытую среду.

1.2.3 Серверы баз данных

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

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

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

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

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

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

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

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

1.2.5 Типичное  разделение функций между клиентами  и серверами

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

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

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

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

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

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

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

Трехуровневая архитектура  функционирует в Интранет и Интернет сетях. Клиентская часть («тонкий клиент»), взаимодействующая с пользователем, представляет из себя  HTML-страницу в Web-браузере, либо Windows-приложение, взаимодействующим с Web-сервисами.  Вся программная логика вынесена на сервер приложений, который обеспечивает формирование запросов  к  базе  данных,  передаваемых  на  выполнение  серверу  баз  данных.

Сервер приложений находится  на сервере и может быть Web-сервером или  специализированной  программой  (например,  Oracle  Forms  Server)  (см.  рис. 1.3).

 

Рисунок 1.3. Схема работы с БД в трехуровневой архитектуре

 

 

1.3 Инструментальные средства организации  доступа

В Интернете вся информация размещается на Web-страницах, на языке HTML (в этом случае имеем HTML-страницы) или его расширениях, таких как DHTML (Dynamic HTML — динамический НTML) и XML (extensible Markup Language — расширяемый язык разметки). В содержимое Web-страницы может входить текстовая информация, ссылки на другие Web-страницы, графические изображения, аудио-, видеоинформация и другие данные. Эти страницы хранятся на Web-сервере.

Для доступа к Web-страницам используются специальные клиентские программы - обозреватели Web (программы просмотра, или броузеры — от англ. browser), находящиеся на компьютерах пользователей Интернета. Обозреватель формирует запрос на получение требуемой страницы или другого ресурса с помощью специального адреса URL (Universal Resource Locator — универсальный указатель ресурса). Этот адрес определяет тип протокола для передачи этого ресурса, имя домена, используемое для доступа к требуемому Web-узлу, номер порта (порт — логический канал связи, номера определяются стандартами Интернета), локальный путь к файлу и дополнительные аргументы.

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

Для расширения возможностей клиентской части (обозревателя) и серверной части создаются программы расширения обозревателя и сервера. Схема взаимодействия обозревателя и сервера с использованием программ расширения приведена на рис. 1.4

 

Рисунок 1.4. Схема взаимодействия обозревателя и сервера

 

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

  • сценарии, подготовленные на различных языках сценариев (JavaScript, JScript и VBScript) и вставленные в обычный Wеb-документ;
  • апплеты и сервлеты Java;
  • элементы управления ActiveX;
  • консольные ехе-программы, реализованные с использованием интерфейса CGI;
  • ехе-программы, реализованные с использованием интерфейса WinCGI;
  • динамические библиотеки, реализованные с использованием интерфейса ISAPI;
  • динамические страницы IDC/HTX;
  • активные серверные страницы ASP;
  • персональные домашние страницы РНР [3].

1.3.1 Сценарии JavaScript, JScript и VBScript

Сценарии, написанные на языках JavaScript, JScript или VBScript, используют для динамического управления интерфейсными объектами (компонентами) Web-документа. Эти языки являются языками интерпретируемого типа (код выполняется в процессе интерпретации). Интерпретация и выполнение сценариев осуществляется обозревателем или сервером. Сценарии являются расширением языка HTML и могут включаться в тело Web-документа.

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

JavaScript представляет собой объектно-ориентированный язык с С-подобным синтаксисом. Сценарии на языке JavaScript используются в обозревателе Netscape Navigator, а сценарии на языке JScript используются в обозревателе Internet Explorer. Лексика и синтаксис этих языков практически идентичны, отличия заключаются в используемых объектных моделях обозревателей (совокупностях элементов, их атрибутов и событий Web-документа). В обозревателе Internet Explorer дополнительно поддерживается язык сценариев VBScript, по возможностям функционально эквивалентный языку J Script, но более простой в освоении. Этот язык наиболее часто используется программистами, имеющими опыт работы с Microsoft Visual Basic.

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

ОтзывАстанаева.doc

— 34.50 Кб (Просмотреть файл, Скачать документ)

ПРИЛОЖЕНИЕ Б1.doc

— 123.00 Кб (Просмотреть файл, Скачать документ)

Приложение Б2.doc

— 98.00 Кб (Просмотреть файл, Скачать документ)

ПРИЛОЖЕНИЕ Б4.doc

— 308.00 Кб (Просмотреть файл, Скачать документ)

ПРИЛОЖЕНИЕ Б5 .doc

— 672.50 Кб (Просмотреть файл, Скачать документ)

ПРИЛОЖЕНИЕБ3 .doc

— 265.50 Кб (Просмотреть файл, Скачать документ)

Информация о работе Публикация БД в Интернет