Инновационные технологии продвижения бизнеса в интернете

pg_shadow.

Имя атрибута Имя колонки Имя домена Тип данных Признак обязатель-ности Ключи Правило удаления Код пользователя usesysid Цифровой код integer Not null PK Имя пользователя usename Имя name Not null AK1 Тип пользователя usesuper Логический boolean Not null Пароль пользователя Passwd Пароль text Not null

Таблица 2.

12. Атрибут «Пользователь».

Контрагент / E4.

client.

Имя атрибута Имя колонки Имя домена Тип данных Признак обязатель-ности Ключи Правило удаления Код контрагента Id Цифровой код integer Not null PK ИНН контрагента Inn Цифровой код integer Not null AK1 Наименован. контрагента Name Наименование контрагента character varying (256) Not null AK2.1 Адрес контрагента Address Длинное наименование character varying (128) Not null AK2.2 Телефон контрагента Phone Телефон character varying (64) Null E-mail контрагента Email Короткое наименование character varying (32) Null Тип контрагента Kind Контрагент character varying (8) Not null

Таблица 2.

13. Сущность «Контрагент».

Вид цены / E5.

price_kind.

Имя атрибута Имя колонки Имя домена Тип данных Признак обязатель-ности Ключи Правило удаления Код вида цены Id Цифровой код integer Not null PK Наименован. вида цены Name Короткое наименование character varying (32) Not null AK1

Таблица 2.

14. Сущность «Вид цены».

Валюта / E6.

currency.

Имя атрибута Имя колонки Имя домена Тип данных Признак обязатель-ности Ключи Правило удаления Код валюты Id Цифровой код integer Not null PK Наименова-ние валюты Name Короткое наименование character varying (32) Not null AK1

Таблица 2.

15. Сущность «Валюта».

Остаток на дату / E7.

stock.

Имя атрибута Имя колонки Имя домена Тип данных Признак обязатель-ности Ключи Правило удаления Рабочая дата Workday Дата date Not null PK Код товара Ware Буквенно-цифровой код character varying (8) Not null PK; FK1 ware; restrict Значение остатка Value Количество integer Not null

Таблица 2.

16. Сущность «Остаток на дату».

Цена / E8.

price.

Имя атрибута Имя колонки Имя домена Тип данных Признак обязатель-ности Ключи Правило удаления Код товара Ware Буквенно-цифровой код character varying (8) Not null PK; FK1 ware; restrict Код вида цены price_kind Цифровой код integer Not null PK; FK2 price_kind; restrict Код валюты Currency Цифровой код integer Not null PK; FK3 currency; restrict Значение цены Value Деньги numeric (12, 2) Not null

Таблица 2.

17. Сущность «Цена».

Запись о расходе / E9.

expensis_record.

Имя атрибута Имя колонки Имя домена Тип данных Признак обязатель-ности Ключи Правило удаления Номер расходного документа Expenses Цифровой код integer Not null PK; FK1 expenses; restrict Код товара Ware Буквенно-цифровой код character varying (8) Not null PK; FK2 ware; restrict Количество Quantity Количество integer Not null Цена Price Деньги numeric (12, 2) Not null

Таблица 2.

18. Сущность «Запись о расходе».

Запись о приходе / E10.

receipts_record.

Имя атрибута Имя колонки Имя домена Тип данных Признак обязатель-ности Ключи Правило удаления Номер приходного документа Receipts Цифровой код integer Not null PK; FK1 receipts; restrict Код товара Ware Буквенно-цифровой код character varying (8) Not null PK; FK2 ware; restrict Количество Quantity Количество integer Not null Цена Price Деньги numeric (12, 2) Not null

Таблица 2.

19. Сущность «Запись о приходе».

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

Расходный документ / E11.

expenses.

Имя атрибута Имя колонки Имя домена Тип данных Признак обязатель-ности Ключи Правило удаления Номер Id Цифровой код integer Not null PK Контрагент Client Цифровой код integer Not null FK1 client; restrict Пользователь employee Цифровой код integer Not null Дата workday Дата date Not null Не оплачено Paid Логический boolean Not null

Таблица 2.

20. Сущность «Расходный документ».

Приходный документ / E12.

receipts.

Имя атрибута Имя колонки Имя домена Тип данных Признак обязатель-ности Ключи Правило удаления Номер Id Цифровой код Integer Not null PK Контрагент Client Цифровой код Integer Not null FK1 client; restrict Пользователь employee Цифровой код Integer Not null Дата workday Дата Date Not null

Таблица 2.

21. Сущность «Приходный документ».

В общем виде схема спроектированной типовой базы данных представлена на рисунке 2.

4.

Рисунок 2.

4. Общая схема базы данных.

3. Создание административного Web-приложения.

3.

1. Алгоритм работы приложения.

Основной алгоритм работы приложения (алгоритм верхнего уровня) представлен на рисунке 3.

1. В начале работы пользователь должен ввести имя и пароль. Эта информация передается на сервер, где производится обычный набор действий для подключения к базе данных посредством JDBC. На этапе загрузки драйвера сервер загружает JDBC-драйвер для СУБД PostgreSQL. На этапе установки соединения сервер подключается к конкретной базе данных (в данном случае — mydb), используя для идентификации и аутентификации пользователя введенные ранее имя пароль и пароль. На этапе создания объекта состояния сервер передает клиентской программе (браузеру) файл cookie (если файлы cookie отключены в настройках браузера, то используется метод перезаписи URL), который позволит пользователю оставаться аутентифицированным в течение всего сеанса работы с базой данных.

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

public class connectMyDB extends HttpServlet.

{.

public void doPost (HttpServletRequest request,.

HttpServletResponse response) throws ServletException, IOException.

{.

response.setContentType («text/html;charset=KOI8-R»);

String username = request. getParameter («username»);

String password = request. getParameter («password»);

PrintWriter out=response.getWriter ();

HttpSession session = request. getSession (true);

session.setAttribute («username», username);

session.setAttribute («password», password);

String docType="<!DOCTYPE HTML PUBLIC «.

-//W3C//DTD HTML 4.0 Transnational//EN" >" ;

out.println (docType + «<HTML><HEAD><META http-equiv="Content-Type» content="text/html;charset=koi8-r" ></HEAD><BODY>");

try.

{.

Class.forName («org.postgresql.Driver»);

out.println («<H1>Загрузка драйвера базы данных: OK</H1>»);

}.

catch (ClassNotFoundException cnfe).

{.

out.println («<H1>Не удалось загрузить драйвер базы данных</H1>»);

}.

Connection c = null;

try.

{.

Properties props = new Properties ();

props.setProperty («user», username);

props.setProperty («password», password);

props.setProperty («charSet», «KOI8-R»);

c = DriverManager. getConnection («jdbc:postgresql://localhost/mydb», props);

out.println («<H1>Установка соединения: OK</H1>»);

Рисунок 3.

1. Алгоритм работы программы.

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

2.

Рисунок 3.

2. Обобщенный алгоритм работы приложения.

Ниже приводит список решаемых задач и соответствующих им пунктов меню:

— вывести список таблиц базы данных (пункт «Список таблиц»);

— показать список полей конкретной таблицы, включая признак ключа, тип поля, в том числе размер и количество десятичных знаков, там, где это имеет смысл (пункт «Поля таблицы»);

— завести новую таблицу, указав имя таблицы и количество полей, задав имена всем и тип каждому полю и отметить ключевые поля (пункт «Новая таблица»);

— удалить указанную таблицу (пункт «Удалить таблицу»);

— добавить новое поле к уже существующей таблице (пункт «Новое поле»);

— задать значение по умолчанию для уже существующего поля (пункт «Установить значение по умолчанию»);

— отменить значение по умолчанию для тех полей, для которых данное значение задано (пункт «Отменить значение по умолчанию»);

— переименовывать таблицу (пункт «Переименовать таблицу»);

— переименовывать одно из полей существующей таблицы (пункт «Переименовать поле»);

— установить связь между полями таблиц (пункт «Установить связь»);

— ввести ограничения целостности и ограничения, связанные с бизнес-правилами (пункт «Установить проверку условия»);

— сменить владельца существующей таблицы (пункт «Сменить владельца»);

— выполнить произвольный запрос к базе данных (пункт «Произвольный SQL-запрос»);

— вывести список всех пользователей базы данных (пункт «Список пользователей»);

— создать нового непривилегированного пользователя без административных привилегий (пункт «Новый пользователь»);

— удалить из списка пользователей СУБД указанного пользователя (пункт «Удалить пользователя»);

— сменить пароль существующего пользователя (пункт «Сменить пароль»);

— установить срок действия пароля существующего пользователя (пункт «Установить срок действия пароля»);

— назначить права доступа конкретного пользователя к конкретному существующему объекту (пункт «Назначить права»);

— удалить права доступа конкретного пользователя по отношению к конкретному существующему объекту (пункт «Удалить права»);

— назначить права администратора конкретному существующему пользователю (пункт «Предоставить административные права»);

— отобрать права администратора у конкретного пользователя, обладающего административными правами (пункт «Удалить административные права»);

— вывести список существующих групп с их пользователями (пункт «Список групп»);

— создать новую группу пользователей СУБД (пункт «Новая группа»);

— удалить указанную существующую группу пользователей СУБД; при этом пользователи удаляться не должны (пункт «Удалить группу»);

— добавить указанного существующего пользователя СУБД в существующую группу (пункт «Добавить в группу»);

— удалить указанного пользователя, входящего в указанную группу из данной группы (пункт «Удалить из группы»);

— назначить права доступа конкретной группы к конкретному существующему объекту (пункт «Назначить права»);

— удалить права доступа конкретной группы по отношению к конкретному существующему объекту пункт («Удалить права»).

Алгоритмы работы каждого класса, соответствующего конкретным пунктам меню, сводятся к трем видам:

— классы, выполняющие запрос к базе данных и выводящие его результат (в качестве примера на рисунку 3.3 приведен алгоритм работы класса viewTables, выводящий список таблиц);

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

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

Рисунок 3.

3. Алгоритм работы класса viewTables. Выполняется не требующий никаких данных от пользователя SQL-запрос:

SELECT relname, relacl FROM pg_classes WHERE relkind = ‘r' AND relname !~ ‘^pg_' ORDER BY relname.

Рисунок 3.

4. Алгоритм работы класса newUser. Выполняется SQL-запрос, использующий введенное администратором имя нового пользователя. Текст запроса:

CREATE USER <имя_пользователя>

Рисунок 3.

5. Алгоритм работы класса newForeignKey. Выполняемы запросы:

SELECT attname FROM pg_attribute WHERE attnum > 0 AND attrelid =.

(«SELECT relfilenode FROM pg_class WHERE relname = <имя_таблицы>).

и.

ALTER TABLE <имя_таблицы₁> ADD FOREIGN KEY (<имя_поля₁>).

REFERENCES <имя_таблицы₂> (<имя_поля₂>).

3.

2. Обеспечение безопасности.

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

Протокол HTTP является протоколом «без состояний»: каждый раз, когда клиент находит Web-страницу, он открывает отдельное соединение с Web-сервером, и сервер не поддерживает автоматически контекстную информацию о клиенте. Даже если серверы поддерживают сохраняемые (keep-alive) HTTP-соединения, они держат сокет открытым для нескольких запросов клиента, поступающих друг за другом, в течение короткого времени. В протоколе не существует встроенной поддержки для сопровождения контекстной информации. Отсутствие контекста создает ряд трудностей. Например, когда клиенты находятся в онлайновом магазине и добавляют в свою корзину очередную покупку, каким образом сервер знает, что там уже находится? Аналогично, когда клиенты решают продолжить выбор покупок, каким образом сервер может определить, какая из ранее созданных корзин принадлежит каждому из них?

Для решения этой проблемы существует три типичных подхода: cookies, перезапись адреса URL (URL-Rewriting) и скрытые поля формы.

Для хранения информации о сеансе покупок можно использовать HTTP-cookies, и каждое последующее соединение будет просматривать текущий сеанс, а затем извлекать информацию об этом сеансе из некоторого места на сервере.

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

— выделение из множества переданных в HTTP-запросе cookies именно того cookie, который хранит идентификатор сеанса;

— задание соответствующего срока действия cookie (вероятно, сеансы, которые остаются неактивными в течение 24 часов, должны быть сброшены);

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

— генерация уникальный идентификаторов сеанса.

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

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

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

В данной работе для отслеживания сеанса используется предоставляемое сервлетами Java выдающееся техническое решение: интерфейс API класса HttpSession. Этот высокоуровневый интерфейс построен на cookies или перезаписи URL. В действительности, большинство серверов использует cookies, если их поддерживает браузер, но автоматически переходят на перезапись URL, если cookies не поддерживаются или явно отключены. Но разработчик сервлета не должен беспокоится об этих деталях, не должен манипулировать cookies или добавлением информации к адресам URL; ему автоматически выделяется удобное место для хранения произвольных объектов, связанных с каждым сеансом.

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

Просмотр объекта класса HttpSession производится вызовом метода getSession класса HttpServletRequest. Система извлекает из cookie или данных, прикрепленных к URL, идентификатор пользователя, затем использует его в качестве ключа в таблице ранее созданных объектов класса HttpSession. Программист при этом должен только вызвать метод getSession. Если метод getSession возвращает пустое значение, это означает, что пользователь еще не участвует в сеансе, поэтому можно создать новый сеанс. Создание нового сеанса в подобных ситуациях выполняется настолько часто, что существует параметр для автоматического создания нового сеанса, если он еще не существует. Для этого в метод getSession следует передать значение true. Если требуется узнать, существовал ли сеанс ранее или он только что создан, используется метод isNew.

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

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

Сеансы автоматически становятся неактивными, если время между обращениями к ним клиента превышает интервал, заданный методом getMaxInactiveInterval. Когда это происходит, то все объекты, связанные с объектом класса HttpSession, автоматически от него отсоединяются. При этом они автоматически уведомляются об этом (если реализуется интерфейс HttpSessionBindingListener). Сеанс можно сделать неактивным явным образом, используя метод сеанса invalidate.

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

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

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

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

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

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

Настройка клиентского доступа в PostgreSQL заключается в редактировании специального системного файла pg_hba.conf. Данный файл позволяет задать следующие типы подключения:

— host; используется для удаленных компьютеров, при этом служба PostgreSQL должна быть запущена с поддержкой TCP/IP.;

— local; используется для подключения с компьютера, на котором работает сервер PostgreSQL;

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

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

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

— reject; доступ к базе данных для пользователя, регистрирующегося с данного удаленного компьютера однозначно отклоняется;

— password; для получения доступа пользователь должен ввести пароль;

— crypt; аналогичен методу password, но здесь пароль пересылается с использованием простой схемы шифрования;

— krb4, krb5; используется система аутентификации Kerberos версии 4 или 5; использование данного протокола выходит за рамки этой работы, но все возможности для его использования с данным решением открыты;

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

Шифрование сеанса при обмене данными стало вполне обыденным явлением. На всех более или менее серьезных коммерческих сайтах пересылка конфиденциальных данных защищается при помощи протокола SSL (Secure Sockets Layer).

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

4. Тестирование и отладка.

4.

1. Общее описание тестирования и отладки.

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

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

Рисунок 4.

1. Меню интерфейса администратора.

Для тестирования на базе данного решения было создано простое предприятие книжной торговли. В таблицу «Товар» (ware) были добавлены поля «Автор» (author), «Издательство» (publisher), «Номер ISBN» (isbn), «Тип обложки» (back), «Год издания» (year). Были добавлены две таблицы — «Авторы» и «Издатели» — имеющие одинаковый набор полей: «Идентификатор» (id) и «Имя» (name). Были установлены связи между полями «Автор» и «Издательство» таблицы «Товар» и полями «Идентификатор» соответствующих новых таблиц. Для поля «Тип обложки» таблицы «Товар» была установлена проверка условия (‘h' или ‘b', соответственно, для твердого или мягкого переплета.

Далее были заведены два пользователя, одному из которых были предоставлены административные права. Второму пользователю было предоставлено право чтения информации из таблицы «Товар» и право на добавление в таблицу «Цена». Права были проверены выполнением соответствующих SQL-запросов. Затем был создан еще один пользователь. Была создана группа, куда были включены оба новых пользователя — не администратора. Группе было предоставлено право на чтение таблицы «Контрагенты», что было проверено выполнением соответствующего запроса.

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

4.

2. Работа с объектами базы данных.

На рисунке 4.2 приводится скриншот формы для создания нового поля для уже существующей таблицы. После нажатия на клавишу «ОК» был выполнен соответствующий запрос ALTER TABLE. Рисунок 4.

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

Рисунок 4.

2. Создание нового поля в существующей таблице Рисунок 4.

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

После выполнения пяти соответствующих запросов к таблице «Товар» были добавлены пять новых полей. Результат выполнения этих запросов был просмотрен с помощью пункта меню «Показать поля таблицы» (рисунок 4.4).

Рисунок 4.

4. Новые поля в таблице в таблице «Товар».

Для создания двух новых таблиц («Авторы» и «Издатели») использовалась форма, вызываемая выбором пункта меню «Новая таблица». Заполненная форма для создания таблицы «Авторы» представлена на рисунке 4.

5.

Рисунок 4.

5. Создание новой таблицы.

На рисунке 4.6 показано сообщение, которое было выведено на экран браузера после успешного создания таблицы «Авторы».

Рисунок 4.

6. Создана таблица author.

С помощью пункта меню «Список таблиц» был выведен список всех пользовательских таблиц базы данных, где уже отображены только что созданные таблицы «Авторы» (author) «Издательства» (publisher). Скриншот приведен на рисунке 4.

7.

Рисунок 4.

7. Список таблиц базы данных после добавления новых таблиц.

Для создания связей между таблицей «Товары» и таблицами «Авторы» и «Издательства» использовался пункт меню программы «Установить связь». Форма HTML для установки связи между полем author таблицы «Товар» и полем id таблицы «Авторы» показана на рисунке 4.

8.

Рисунок 4.

8. Установка связи между таблицами ware и author.

В результате успешного выполнения команды SQL ALTER TABLE были созданы связи «один ко многим» для атрибутов author и publisher таблицы «Товар». Подтверждение успешно выполненного запроса для поля author было выведено на экран браузера, как показано ниже на рисунке 4.

9.

Рисунок 4.

9. Подтверждение установки связи.

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

10.

Рисунок 4.

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

Для проверки функционирования пункта меню «Установить проверку условия» было установлено ограничение на множество значений атрибута «Тип обложки» (back) таблицы «Товар». Данный атрибут может принимать только два значения: ‘h' для изданий в твердом переплете и ‘b' - для изданий в мягкой обложке. Форма задания данного условия приводится на рисунке 4.

11.

Рисунок 4.

11. Условие для поля back таблицы ware.

На рисунке 4.12 представлено выведенное на экран браузера подтверждение об успешном выполнении SQL-запрос ALTER TABLE для установки проверки условия диапазона значений атрибута.

Рисунок 4.

12. Подтверждение установки ограничения целостности.

4.

3. Работа с пользователями.

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

13.

Рисунок 4.

13. Форма для создания нового пользователя.

На рисунке 4.14 показан внешний вид экрана браузера после успешного создания пользователя user1.

Рисунок 4.

14. Подтверждение создания нового пользователя.

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

Рисунок 4.

15. Отказ в создании новой пользовательской учетной записи для пользователя — не администратора.

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

Рисунок 4.

16. Предоставление административных полномочий пользователю user1.

Пользователю user2 с помощью вызова пункта меню «Назначить права» было предоставлено право чтения таблицы «Товар» и право на добавление записей в таблицу «Цена». Форма, использовавшаяся при назначении прав для таблицы «Товар» представлена ни рисунке 4.

17.

Рисунок 4.

17. Предоставление пользователю user2 прав на чтение таблицы «Товар».

В результате успешного выполнения административного SQL-запроса GRANT на экран браузера было выведено сообщение, представленное на рисунке 4.

18.

Рисунок 4.

18. Подтверждение установки полномочий на чтение таблицы «Товар» для пользователя user2.

Для проверки действительности административных полномочий пользователя user1 с помощью пункта меню «Произвольный SQL-запрос» был выполнен запрос на имена всех пользователей из системной таблицы pg_shadow. Получать данные из этой таблицы могут лишь пользователи, являющиеся суперпользователями системы PostgreSQL. Результат выполнения запроса представлен на рисунке 4.

19.

Рисунок 4.

19. Результат выполнения пользователем user1 запроса к доступной только для администраторов таблице pg_shadow.

От имени пользователя user2 был выполнен запрос на чтение всех полей таблицы товар. Тестовые данные о товаре были внесены в базу данных заранее посредством выполнения запросов INSERT INTO. При этом использовалось данное решение, конкретно, — пункт меню «Произвольный SQL-запрос» интерфе1са администратора. Выведенный на экран браузера результат запроса пользователя user2 к таблице «Товар» представлен на рисунке 4.

20.

Рисунок 4.

20. Результат выполнения пользователем user2 запроса к таблице «Товар».

Для проверки установки полномочий на добавления данных в таблицу «Цена» для пользователя user1 был выполнен соответствующий SQL-запрос. В результате на экран браузера было выведено подтверждающее сообщение, показанное на рисунке 4.

21.

Рисунок 4.

21. Проверка прав на запись информации в таблицу price для пользователя user2.

4.

4. Работа с группами.

После создания новой группы newgroup и добавления в нее пользователя user2 и специально созданного пользователя user3 с помощью пунктов меню «Новая группа» и «Добавить пользователя в группу» был выполнен запрос с помощью пункта меню «Список групп». Результат его выполнения представлен на рисунке 4.

22.

Рисунок 4.

22. Список групп после создания группы newgroup и добавления в нее пользователей user2 и user3.

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

23.

Рисунок 4.

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

С помощью пункта меню «Назначить права» подгруппы для работы с группами пользователей для членов группы newgroup было установлено право на чтение таблицы «Контрагенты». После этого от имени пользователя user3 был сделан запрос на чтение всех данных из таблицы «Контрагенты». Результат выполнения этого запроса представлен на рисунке 4.

24.

Рисунок 4.

24. Результат выполнения запроса к таблице «Контрагенты» пользователем user3 после наделения его группы соответствующими правами.

После этого пользователь user3 был удален из группы newgroup, и был повторен предыдущий SQL-запрос. В результате попытки неправомочного доступа пользователь user3 получил сообщение, показанное на рисунке 4.

25.

Рисунок 4.

25. Реакция на неправильные действия пользователя.

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

ГЛАВА 3. ОБОСНОВАНИЕ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ.

3.

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

— производительность труда.

— трудоемкость производства Пт=В/Тз;

Те=Тз/В;

где В — объем производства за плановый период (квартал, год);

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

— материалоотдача.

— материалоемкость производства Мо=В/М;

Ме=М/В;

где М — общие материальные затраты на производство продукции;

— фондоотдача.

— фондоемкость Фо=В/Ф;

Фе=Ф/В;

где Ф — среднегодовая стоимость основных производственных фондов предприятия;

— капиталоотдача.

— капиталоемкость Ко=ΔВ/К;

Ке=К/ΔВ;

Где ΔВ — прирост выпуска продукции за плановый период, вызванный капитальными вложениями на предприятии за данный период;

К — объем указанных капитальных вложений;

— рентабельность капиталовложений.

— срок окупаемости капиталовложений Рк=(Ц-С)/Ксм;

Ток=Ксм/(Ц-С);

Где ΔП — прирост прибыли, обусловленный капитальными вложениями К.

Интегральные показатели экономической эффективности следующие:

— затраты на 1000 руб. товарной продукции З=Ссм/ТП;

где Ссм — себестоимость произведенной за плановый период продукции;

ТП — объем (стоимость) произведенной продукции;

— рентабельность производства.

— рентабельность продукции Рпр=[Ппр/(Ф+ОС)]*100%ж Рм=(П/С)*100%;

Где Ппр — валовая прибыль по предприятию;

ОС — нормируемые оборотные средства предприятия;

П — прибыль от реализации продукции.

— сравнительный срок окупаемости.

— коэффициент сравнительной эффективности дополнительных капиталовложений Ток=(К2-К1)/(С1-С2)<Тн;

Е=(С1-С2)/(К2-К1)>Eн;

Где К1 и К2 — капитальные вложения в первом и втором случае;

С1 и С2 — годовая себестоимость продукции по сравниваемым вариантам;

Тн — нормативный срок окупаемости капиталовложений, который определяет минимально возможную (допустимую) эффективность вложений;

Ен — аналогично, нормативный коэффициент сравнительной эффективности капиталовложений.

3.

2. Расчет экономической эффективности разработки и внедрения ИС библиотеки.

1. 3.2 Анализ затрат на ресурсное обеспечение.

К прямым материальным затратам относятся затраты на материалы и комплектующие, необходимые для выполнения работ по разработке информационной системе. Учитываются все затраты на материалы и комплектующие, целевым назначением идущие на разработку (таблица 16) [27].

Таблица 16 — Расчет материалов и комплектующих.

№ Элемент затрат Количество Цена за шт. (руб.) Общая стоимость (руб.) 1 Дырокол 1 250 250 2 Бумага А4, пачек 2 300 600 3 Ручки, карандаши, канцелярские товары 15 15 225 4 Картридж для принтера 1 450 900 ИТОГО, рублей 1975 В таблице 17 представлен расчет стоимости комплекса технических средств.

Таблица 17 — Расчет стоимости КТС.

№ Наименование Kол-во Цена за шт. Сумма руб. 1 Персональный компьютер Моноблок Dell XPS One 2720 1 74 000 74 000 2 ИБП APC by Schneider Electric Power Saving Back-UPS Pro 1500 1 14 000 14 000 3 HP LaserJet Pro M1132 MFP.

1 5500 5500 ИТОГО 93 520.

Расходы на содержание и эксплуатацию КТС определяют, как произведение стоимости часа работы КТС на количество часов машинного времени, затраченного на разработку [30].

В стоимость часа работы КТС включают следующие затраты [27]:

Амортизационные отчисления, приходящиеся на 1 час работы КТС:

Ач = Фперв*, (1).

где Фперв — первоначальная стоимость КТС или отдельных его элементов;

а — норма амортизации (0.25);

Fд- фонд времени работы КТС за год (2 000−3 000 часов).

В таблице 18 представлен расчет амортизационных отчислений.

Таблица 18 — Расчет амортизационных отчислений.

№ п/п Элемент КТС Фперв Fд Ач Количество часов работы Общая стоимость (руб.) 1. Персональный компьютер Моноблок Dell XPS One 2720 74 000 3000 6,17 675 4162,5 2 ИБП APC by Schneider Electric Power Saving Back-UPS Pro 1500 14 000 3000 1,17 675 787,5 3 HP LaserJet Pro M1132 MFP.

5500 3000 0,46 675 309,375 ИТОГО 5259.

Затраты на силовую энергию, приходящиеся на 1 час работы КТС; определяют, как произведение установленной мощности КТС в кВт на стоимость 1 кВт в час. Уровень тарифов на электроэнергию в настоящее время составляет 3.58 руб. за кВт/ч (таблица 19).

Таблица 19 — Расчет затрат на силовую энергию.

№ п/п Элемент КТС Установленная мощность, кВт Стоимость 1кВт в час (руб.) Количество часов работы Общая стоимость (руб.) 1 Персональный компьютер Моноблок Dell XPS One 2720 0,66 3,58 675 1594,89 2 ИБП APC by Schneider Electric Power Saving Back-UPS Pro 1500 1 3,58 675 2416,5 3 HP LaserJet Pro M1132 MFP.

0,2 3,58 675 483,3 ИТОГО 4494,69.

Затраты на текущий ремонт и профилактику, приходящиеся на 1 час работы КТС; определяют аналогично амортизационным отчислениям, но вместо нормы амортизации используют процент указанных затрат (5−10%) [27] (таблица 20).

Bч = Фперв*, (2).

где b = 0,05.

Таблица 20 — Расчет затрат на текущий ремонт и профилактику.

№ п/п Элемент КТС Фперв Fд Bч Количество часов работы Общая стоимость (руб.) 1. Персональный компьютер Моноблок Dell XPS One 2720 74 000 3000 1,23 675 832,5 2 ИБП APC by Schneider Electric Power Saving Back-UPS Pro 1500 14 000 3000 0,23 675 157,5 3 HP LaserJet Pro M1132 MFP.

5500 3000 0,09 675 61,875 ИТОГО 1051,875.

Таким образом, расходы на содержание и эксплуатацию комплекса технических средств составляют: 5259+4494+1051=10 804 (руб.).

3.3 Анализ качественных и количественных факторов воздействия проекта на бизнес-архитектуру организации.

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

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

увеличить качество и достоверность хранимой информации;

автоматизировать процесс ведения учета поступления и продажи товаров;

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

обеспечить автоматическое формирование отчетной информации;

обеспечить оперативный поиск информации;

обеспечить защиту информации.

3.4 Расчет экономической эффективности инвестиций в проект.

Коэффициент рентабельности инвестиций ROI (Return On Investment) — финансовый показатель, характеризующий доходность инвестиционных вложений.

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

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

Здесь предполагается, что загруженность специалистов с внедрением ИС с 70-и часов в месяц уменьшится до 50.

Таблица 21 — Сравнение временных и денежных затрат существующего и проектного вариантов Затраты Базовый вариант Проектный вариант 1 2 3 Проведение ежемесячной инвентаризации склада (сотрудники склада) 12 раз в год.

8 ч.*12 = 96 ч.

Средний оклад = 20 000 р.

9600 р/год.

5 сотрудников.

48 000 р. 2 раза в год.

2*8=16 ч.

Средний оклад = 20 000 р.

1600 р/год.

5 сотрудников.

8000 р. Продолжение таблицы 21.

1 2 3 Учет работы с поставщиками (сотрудники отдела закупок) 1 раз в месяц.

8 ч*1 = 8 ч.

Средний оклад = 25 000 р.

11 700 р/год.

2 сотрудника.

23 520 р. 1 раз в месяц.

2 ч*1 = 2 ч.

Средний оклад = 25 000 р.

2285 р/год.

2 сотрудника.

5770 р. Учет заказов клиентов (сотрудники отдела работы с клиентами) 26 раз в месяц.

8 ч*1 = 8 ч.

Средний оклад = 25 000 р.

212 160 р/год.

2 сотрудника.

424 320 р. 26 раз в месяц.

4 ч*1 = 4 ч.

Средний оклад = 25 000 р.

106 080 р/год.

2 сотрудника.

212 160 р. Учет сведений об оплате заказов клиентов и оплате договоров с поставщиками (сотрудники бухгалтерии) 26 раз в месяц.

3 ч*1 = 3 ч.

Средний оклад = 20 000 р.

89 856 р/год.

1 сотрудник.

89 856 р 26 раз в месяц.

1 ч*1 = 2 ч.

Средний оклад = 20 000 р.

29 952 р/год.

1 сотрудник.

29 952 р. Оформление сопроводительной документации для отгрузки заказа клиенту (сотрудники отдела логистики) 26 раз в месяц.

4 ч*1 = 8 ч.

Средний оклад = 25 000 р.

106 080 р/год.

2 сотрудника.

212 160 р. 26 раз в месяц.

2 ч*1 = 4 ч.

Средний оклад = 25 000 р.

53 040 р/год.

2 сотрудника.

106 080 р.

Теперь следует подсчитать все вышеприведенные виды выгод по годам на период жизненного цикла системы. Их структура представлена в таблице 22.

Таблица 22 — Общие выгоды после внедрения ИС Статья выгоды За 1-й год, руб. За 2-й год, руб. За 3-й год, руб. Итого, руб. Сотрудники склада 40 000 40 000 40 000 120 000 Сотрудники отдела ИТ 17 750 17 750 17 750 53 250 Сотрудники отдела полиграфии 212 160 212 160 212 160 636 480 Сотрудники бухгалтерии 59 904 59 904 59 904 179 712 Сотрудники отдела логистики 106 080 106 080 106 080 318 240 ИТОГО 1 307 682.

Теперь, перед тем как получить значение показателя ROI, следует учесть дисконтирование в сумме будущих денежных потоков. Дисконтирование — это определение стоимости денежного потока путём приведения стоимости всех выплат к определённому моменту времени. Простыми словами, дисконтирование используется, когда требуется узнать сегодняшнюю стоимость будущей суммы денег, которые надо будет потратить или получить [30].

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

где, i — норма дисконта,.

n — номер периода.

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

С помощью экспертной оценки была определена норма дисконта данного проекта, равная 20%. Теперь, с помощью MS Excel, можно посчитать коэффициент дисконтирования по формуле (4) (число десятичных знаков равно трем):

За 1-й год: kd=0,833.

За 2-й год: kd=0,694.

За 3-й год: kd=0,578.

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

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

Таблица 23 — Подсчет затрат и выгод внедрения ИС с учетом дисконтирования Значение 1-й год, руб. 2-й год, руб. 3-й год, руб. Итого, руб. Затраты Затраты * kd 196 529 196 529 Выгоды Выгоды * kd 363 100 302 510 251 946 917 556 Выгоды * kd — Затраты * kd 721 027.

Теперь, по формуле (3), можно определить ROI=721 027 /196 529=212%.

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

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

Период разработки АИС составляет 1,5 месяца, в одну смену продолжительностью 8 часов.

После ее внедрения снизятся затраты по материальным расходам на 2%. В результате чего будет достигнуто снижение условной общей себестоимости работ отдела, что позволяет окупить создание и внедрение ИС. Проект окупится в течении 3 месяцев.

Заключение

.

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

1. Типовая база данных для предприятия электронной торговли.

2. Административное Web-приложение для работы с объектами базы данных (таблицами), пользователями и группами.

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

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

Web-приложение было разработано на основе технологии сервлет Java. Разработка производилась в среде операционной системы ASP Linux 7.

3. Для компиляции Java-классов использовался распространяемый бесплатно инструментарий разработчика компании Sun Microsystems Java Software Development Kit Standard Edition.

В процессе разработки и отладки использовались бесплатный Web-сервер Apache c подключенным модулем стороннего производителя mod_jk и распространяемый на основе открытой лицензии сервер приложений Tomcat.

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

При тестировании программы в качестве клиентских рабочих мест использовались:

— персональный компьютер IBM Net Vista с операционной системой Microsoft Windows 98 и Web-браузерами Internet Explorer 6, Netscape Navigator 7 и Opera 7;

— персональный компьютер на базе процессора Pentium-4 (2,53 ГГц, ОЗУ 256 МБ) с операционной системой Microsoft Windows XP Professional и Web-браузером Internet Explorer 6;

— блокнотный персональный компьютер (ноутбук) Toshiba Satellite с операционной системой ASP Linux 7.3 и Web-браузером Mozilla 1.

0.

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

При работе с коммерческими серверами приложений Borland AppServer 4.5 и IBM WebSphere 3.5 не пришлось перекомпилировать ни одного класса, за исключением класса otherQuery, выполняющего произвольный SQL-запрос, что было связано с особенностями восприятия кириллической кодировки со стороны клиента сервером Tomcat.

Ниже приведен список конкретных инструментальных средств, использовавшихся при разработке и отладке данного решения:

— операционная система ASP Linux 7.3;

— система управления базами данных PostgreSQL 7.

2.1−5;

— сервер приложений Tomcat 3.

2.1;

— компилятор байт-кодов Sun Java SDK 1.

1.4−02.

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

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

Список литературы

iBusiness. New solutions for the new economy. 2003, vol. 4.

Холл М. Сервлеты и Java Server Pages. Пер с англ. СПб. Питер, 2001 г.

Вебер Дж. Технология Java в подлиннике. Пер. с англ. СПб. BHV — Санкт-Петербург, 1997 г.

Гери Д. Java server Pages для профессионалов. Пер. с англ. М. Вильямс, 2002 г.

Шарф Д. HTML 3.2 Справочное руководство. Пер. с англ. СПб. Питер, 1998 г.

Хокинс С. Администрирование Web-сервера Apache. Пер. с англ. М. Вильямс, 2001 г.

Установка и конфигурирование Linux. Фолькердинг П. и др. Пер. с англ. СПб. Питер, 2000 г.

Администрирование Microsoft SQL Server 7.

0. Учебный курс. Официальное пособие для самостоятельной подготовки. Пер. с англ. М. Русская редакция, 2000 г.

Гарольд Э., Минс С. XML. Справочник. Пер. с англ. СПб. Символ-Плюс, 2002 г.

Грейвз М. Проектирование баз данных на основе XML. М. Вильямс, 2002 г.

Уорсли Дж., Дрейк Дж. PostgreSQL. Для профессионалов. Пер. с англ. СПб. Питер, 2002 г.

Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Пер. с англ. М. Вильямс, 2001 г.

Керниган Б., Пайк Р. Практика программирования. Пер. с англ. СПб. Невский диалект, 2001 г.

(Экономический анализ отрасли информационных технологий: мировой опыт и реальность России Текст научной статьи по специальности «Экономика и экономические науки» Кибер

Ленинка:

https://cyberleninka.ru/article/n/ekonomicheskiy-analiz-otrasli-informatsionnyh-tehnologiy-mirovoy-opyt-i-realnost-rossii).

И.В. Успенский. Интернет — маркетинг. Маркетинг взаимодействия.

Данные актуальны на 1 ноября 2017 года.

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

Крестиком обозначен уход клиента.

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

Основные функции Логика представ-лений.

ASP, JSP, Сервлеты.

Бизнес-логика.

COM+.

CORBA.

EJB.

Интерфейсы связи.

ADO.

JDBC.

ODBC.

Web-сервер

База данных.

Клиентский Web-браузер

HTTP.

Начало.

Да.

Нет.

Успешная аутентификация.

Загрузка драйвера БД.

Установка соединения.

Создание объекта состояния.

Закрытие соединения.

Да.

Нет.

Не выходить из программы.

Выполнение пользовательского запроса.

Выбор действия пользователем.

Ввод имени и пароля пользователя.

Конец.

Начало.

Выбор функции Работа с группами.

Работа с пользователями.

Работа с объектами БД.

Создание и удаление групп, назначение и изменение прав, включение и исключение пользователей Создание и удаление пользователей, назначение и изменение прав, смена пролей и т. д.

Создание, удаление и модификация таблиц базы данных и полей таблиц и т. д.

Да.

Нет.

Завершение работы.

Конец.

Начало.

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

Выполнить SQL-запрос.

Вывести результат запроса.

Конец.

Начало.

Ввести имя вновь создаваемого пользователя.

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

Выполнить SQL-запрос.

Вывести подтверждение или сообщение об ошибке.

Конец.

Начало.

Выполнить второй SQL-запрос.

Ввести имена полей с помощью списков.

Вывести списки полей таблиц.

Ввести имена связываемых таблиц.

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

Выполнить первый SQL-запрос.

Да.

Нет.

Запрос выполнен успешно.

Вывести сообщение об ошибке.

Вывести подтверждение или сообщение об ошибке.

Конец.