7. ЕСЛИ (Расстояние близкое) и (Комфортабельность высокая) ТОГДА (Категория «Четыре звезды»)

8. ЕСЛИ (Цена низкая) и (Питание высокое) и (Комфортабельность высокая) ТОГДА (Категория «Четыре звезды»)

9. ЕСЛИ (Цена высокая) и (Расстояние близкое) ТОГДА (Категория «Три звезды»)

10. ЕСЛИ (Расстояние среднее) и (Комфортабельность низкая) ТОГДА (Категория «Две звезды»)

11. ЕСЛИ (Цена низкая) ТОГДА (Категория «Одна звезда»)

12. ЕСЛИ (Цена средняя) ТОГДА (Категория «Две звезды»)

13. ЕСЛИ (Цена высокая) ТОГДА (Категория «Три звезды»)

14. ЕСЛИ (Цена высокая) и (Комфортабельность высокая) ТОГДА (Категория «Четыре звезды»)

15. ЕСЛИ (Питание высокое) ТОГДА (Категория «Четыре звезды»)

16. ЕСЛИ (Питание высокое) и (Расстояние близкое) и (Комфортабельность хорошая) ТОГДА (Категория «Три звезды»)

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

Введем оценку входных переменных для частного случая: Цена = 8,047, Качество питания = 7,9, Расстояние = 3,22, Комфортабельность = 6,754. Категория гостиницы = 3,02. Полученный коэффициент больше 3, поэтому категория гостиницы «Четыре звезды».

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

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

2.6 Модернизированная функциональная модель бизнес процессов оператора

«Новая» функциональная модель представлена на рисунке 2.9.

Рис. 2.9 Функциональная модель

На рисунке 2.9 t_1…t₁₀- время выполнения функций. Где:

t₁ = 20 (сек)

t₂ = 45 (сек)

t₃ = 10 (сек)

t₄ = 45 (сек)

t₅ = 20 (сек)

t₆ = 75 (сек)

t₇ = 15 (сек)

t₈ = 60 (сек)

t₉ = 5 (сек)

t₁₀ = 10 (сек)

Следовательно, суммарное время, которое тратится на обслуживание одного клиента:

Т = t₁+t₂+t₃+t₄+t₅+t₆+t₇+t₈+t₉+t₁₀= 305 (сек) = 4,87 (мин)

2.7 Формализация модернизированной функциональной модели с помощью аппарата систем массового обслуживания

Для формализации модели также используем СМО для определения времени обслуживания.

Поток клиентов, обратившихся в службу имеет, интенсивность л=5 (5 клиентов в час). Процесс определения категории продолжается в среднем 4,87 минуты = 0,08 часа. Так как каждая заявка рано или поздно будет обслужена, то вероятность отказа Р_отк= 0

Рассчитаем характеристики СМО и сведем их в таблицу 2.4.

Таблица 2.4

Расчетные характеристики СМО

Обозначение	Физический смысл	Формула для вычисления	Результат	Размерность
л	Интенсивность поступления потока клиентов	Исходные данные	5	клиентов/час
м	Интенсивность обслуживания	м =	12,5	клиентов /час
tобс	Время обслуживания одной заявки	Исходные данные	0,08	часы
Ротк	Вероятность отказа обслуживания клиента	Исходные данные	0
с	Количество обслуженных заявок в единицу времени	с =	0,4	клиентов
q	Относительная пропускная способность	q = 1 - Pотк	1	клиентов
А	Абсолютная пропускная способность - среднее число заявок, которое может обслужить система в единицу времени	A = л*q	5	клиентов
r	Среднее число заявок в очереди	r = с2/(1 - с), при с<1 и r = с2/(с - 1), при с>1	0,26	клиентов
k	Среднее число заявок в системе	k = r + с	0,67	клиентов
tож	Среднее время ожидания в очереди	tож = с/м*(с - 1) = с2/л*(с - 1)	0,005	часы
tсмо	Среднее время пребывания заявки в СМО	tсмо = tож+ tобс	0,085	часы

Произведем сравнительный анализ формализованных моделей с помощью СМО «до» и «после» реинжиниринга и представим его в таблице 2.5.

Таблица 2.5

Сравнительный анализ формализованных моделей

Обозначение	Физический смысл	Результат «ДО»	Результат «ПОСЛЕ»
л	Интенсивность поступления ЛПГ	5	5
tобс	Время обслуживания одной заявки	0,156	0,08
r	Среднее число заявок в очереди	1,86	0,26
k	Среднее число заявок в системе	2,581	0,67
tож	Среднее время ожидания в очереди	0,232	0,005
tсмо	Среднее время пребывания заявки в СМО	0,323	0,085

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

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

Выводы по разделу:

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

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

информационный справочный гостиница домбай



3. Проектирование информационно-справочной системы

3.1 Выбор средств проектирования

Для решения задачи по выбору средства проектирования применим так же метод анализа иерархий (далее МАИ).

Первым этапом структурирование проблемы выбора в виде иерархии

1. Case.Аналитик

2. Erwin\BPwin

3. Rational Rose

Далее устанавливим приоритеты критериев и оценим каждую из альтернатив по критериям. Так как в МАИ элементы задачи сравниваются попарно по отношению к их воздействию на общую для них характеристику. Элементом матрицы a(i,j) является интенсивность проявления элемента иерархии i относительно элемента иерархии j, оцениваемая по шкале интенсивности от 1 до 9, предложенной автором метода, где оценки имеют следующий смысл:

Таблица 3.1

1 - равная важность
3 - умеренное превосходство одного над другим
5 - существенное превосходство одного над другим
7 - значительное превосходство одного над другим
9 - очень сильное превосходство одного над другим
2, 4, 6, 8 - соответствующие промежуточные значения

Критерии

Числовые оценки матрицы попарных сравнений.

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



Таблица 3.2

	Функции, свойства	Case.Аналитик	ERwin/ BPwin	RationalRose
1	Моделирование организационных функций и процессов	+	+	+
2	Разработка технического задания	+/-	+	+/-
3	Функционально-стоимостной анализ	+	+	+/-
4	Оптимизация бизнес процессов	+	+	+
5	Групповая работа над проектом	+	+	+
6	Ценовые различия	$25040	$23 685	$40 520
«+» - да«+/-» - частичная реализация, требующая доработки иными инструментальными средствами«-» - не

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

Итак, в список критериев, по которым мы будем сравнивать системы моделирования, попали:

· Моделирование организационных функций и процессов

· Групповая работа над проектом.

· Стоимость

· Производительность

· Надежность

Следующим шагом будет оценка критериев.

Начнем с построения матрицы попарных сравнений для критериев, т.е. со второго уровня иерархии (на первом уровне наша цель - средства моделирования, на третьем - альтернативы). Для этого строим матрицу размерностью 5х5.

Таблица 3.3

						Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета
Моделирование организационных функций и процессов	1	3	1/5	1/6	1/8	0,41628	0,05194
Групповая работа над проектом	1/3	1	1/6	1/8	1/9	0,23849	0,02976
Стоимость	5	6	1	1/3	1/5	1,14870	0,14331
Производительноcть	6	8	3	1	1/3	2,16894	0,27060
Надежность	8	9	5	3	1	4,04282	0,50439
	Сумма:	8,01524

Cначала определяем оценки компонент собственного вектора. Так для критерия "Стоимость" это будет:

(5 x 6 x 1 x 1/3 x 1/5)^1/5 = 1,14870

Получив сумму оценок собственных векторов (= 8,01524), вычисляем нормализованные оценки вектора приоритета для каждого критерия, разделив значение оценки собственного вектора на эту сумму. Для того же критерия "Стоимость" имеем:

1,14870 / 8,01524 = 0,14331

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

Таблица 3.4

Моделирование организационных функций и процессов	0,05194
Групповая работа над проектом	0,02976
Стоимость	0,14331
Производительность	0,27060
Надежность	0,50439

Рассчитаем индекс согласованности для этой матрицы.

OC = 7,72% < 10%, т.е. пересматривать свои суждения нет нужды.

Объем

Числовые оценки матрицы попарных сравнений

Для оценки размера предоставляемого дискового пространства никакие дополнительные расчеты или исследования не понадобятся. Эта информация однозначно определена выбранным тарифным планом.

Таблица 3.5

инструменты организационного проектирования	Моделирование организационных функций и процессов
Case.Аналитик	Да
ERwin\BPwin	Да
Rational Rose	Да

Таблица 3.6

						Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета
Case.Аналитик	1	1	1	1	1/9	0,644394	0,076923
ERwin\BPwin	1	1	1	1	1/9	0,644394	0,076923
Rational Rose	1	1	1	1	1/9	0,644394	0,076923

Относительная согласованность матрицы - 0,00%, т.е. <10%.

Групповая работа над проектом

Числовые оценки матрицы попарных сравнений

Таблица 3.7

инструменты организационного проектирования	Групповая работа над проектом
Case.Аналитик	да
ERwin\BPwin	да
Rational Rose	да

Таблица 3.8

						Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета
Case.Аналитик	1	1/2	1/5	1/3	1/9	0,326383	0,038950
ERwin\BPwin	2	1	1/6	1/2	1/9	0,450320	0,053741
Rational Rose	5	6	1	2	1/5	1,643752	0,196163

Относительная согласованность матрицы - 6,54%, т.е. <10%.



Стоимость

Таблица 3.9

	Всего ($)
Case.Аналитик	31740
ERwin\BPwin	23685
Rational Rose	40520

Таблица 3.10

						Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета
Case.Аналитик	1	1	3	2	1/7	0,969640	0,121237
ERwin\BPwin	1	1	3	2	1/7	0,969640	0,121237
Rational Rose	1/3	1/3	1	1/2	1/9	0,361491	0,045198

Относительная согласованность матрицы - 3,17%, т.е. <10%.

Результат выбора

Таблица 3.11

Альтернативы	Численное значение вектора приоритета	Глобальные приоритеты
Case.Аналитик	0,076923	0,038950	0,121237	0,244138	0,158835	0,168709
Rational Rose	0,076923	0,053741	0,121237	0,087614	0,363760	0,230155
ERwin\BPwin	0,692308	0,615348	0,640516	0,406878	0,363760	0,439640

Выбранной альтернативой считается альтернатива с максимальным значением глобального приоритета.

Таблица 3.12

Case.Аналитик	0,168709
Rational Rose	0,230155
ERwin\BPwin	0,439640



Вследствие проведенного анализа мы делаем вывод, что наилучшим средством моделирования является Erwin\Bpwin.

3.2 Выбор архитектуры

По способу организации ИС имеют следующие виды;

· архитектура файл-сервер;

· архитектура клиент-сервер;

· многоуровневая система;

· на основе интернет/интранет-технологий.

Рассмотрим более подробно особенности архитектуры построения информационных приложений.

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

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

Архитектура клиент-сервер предназначена для разрешения проблем файл-серверной архитектуры путем разделения компонентов приложения и размещения их там, где они будут функционировать наиболее эффективно. Особенностью файл-серверной архитектуры является использование выделенных серверов баз данных, понимающих запросы на языке структурированных запросов SQL (Structured Query Language) и выполняющих поиск, сортировку и агрегирование информации. Большинство конфигураций клиент-сервер использует двухуровневую модель, в которой клиент обращается к услугам сервера. Предполагается, что диалоговые компоненты размещаются на клиенте, что позволяет обеспечить графический интерфейс. Компоненты управления данными размещаются на сервере, а диалог логики, обработка логики - на клиенте. Двух уровневая архитектура клиент-сервер использует именно этот вариант: приложение работает на клиенте, СУБД - на сервере.

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

Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в классической форме состоит из трех уровней;

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

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

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

Подобную концепцию обработки данных пропагандируют, в частности, фирмы Oracle,Sun, Borland и др. [4]

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

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

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

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

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

Таблица 3.13

Сравнительная характеристика архитектуры ИС

Параметры сравнения	Файл-сервер	Клиент-сервер	Многоуровневая система	Интернет/интранет технологии
Установка СУБД	На клиентском компьютере	Отдельный сервер	Несколько отдельных серверов	Несколько отдельных серверов
Объемы передаваемых данных	Малые	Большие	Очень большие	Очень большие
Применяемые на предприятии	Нет	Да	Нет	Нет
Знакомство обслуживающего персонала с представленными архитектурами	Да	Да	Нет	Нет

Проведем расчет выбора архитектуры ИС по выбранным параметрам на основании технико-экономической эффективности.

Оценим их по каждому i-ому показателю качества по 5-ти бальной шкале. Определим каждому критерию весовой коэффициент k_j, причем

k_j= 1.

Таблица 3.14

Шкала оценок

Параметр	Баллы	Оценка
	4	Отлично
	3	Хорошо
	2	Удовлетворительно
	1	Предельно допустимо
	0	Неприемлемо

Результаты сравнения сведем результаты сравнения в таблицу 3.15.

Таблица 3.15

Оценка технико-экономической эффективности

Параметры сравнения/оценка	Весовой коэфф.	Файл-сервер	Клиент-сервер	Многоуровневая система	Интернет/интранет технологии
		Ajf	kj•Ajf	Ajk	kj•Ajk	Ajm	kj•Ajm	Aji	kj•Aji
Установка СУБД	0,15	1	0,15	4	0,6	3	0,45	3	0,45
Объемы передаваемых данных	0,25	1	0,25	3	0,75	4	1	4	1
Применяемые на предприятии	0,35	0	0	4	1,4	0	0	0	0
Знакомство обслуживающего персонала с представленными архитектурами	0,25	2	0,5	3	0,75	1	0,25	1	0,25
Интегральный технико-экономический показатель, Q		Qf = 0,9	Qk = 3,5	Qm = 1,7	Qi = 1,7

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

для файл-сервера Q_f:

для клиент-сервер Q_k:

для многоуровневой системы Q_m:

для интернет/интранет технологии Q_i:

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

Q = Q_k/ Q_f = 3,5/0,9 = 3,89



т.к. технико-экономический показатель больше 1 выбор в сторону клиент-серверной архитектуры.

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

Q = Q_k/ Q_m = 3,5/1,7 = 2,06

т.к. технико-экономический показатель больше 1 выбор в сторону клиент-серверной архитектуры.

Интегральный технико-экономический показатель между клиент-серверной архитектурой и интернет/интранет технологии равен:

Q = Q_k/ Q_m = 1,7/3,5 = 0,605

т.к. технико-экономический показатель меньше 1 выбор в сторону интернет/интранет технологий.

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

3.3 Разработка логической и физической структуры БД

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

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

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

Из приведенной модели видно, что проектируемая база данных для информационной системы содержит 5 сущностей: категории отелей, данные о заказчике, заказы, отели, прайс-лист. Данный набор сущностей, как показал раздел моделирования необходим и достаточен для функционирования информационной системы в данной предметной области.

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

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

Рис. 3.1 Логическая модель данных

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



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

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

Рис. 3.2 Физическая структура базы данных



4. Реализация выбранного варианта решения

4.1 Обоснование выбора СУБД

Требования, предъявляемые к СУБД должны соответствовать условиям и требованиям заказчика, одним из требований является экономическая составляющая, т.е. относительная дешевизна продукта.

Рассмотрим некоторые из представленных на рынке СУБД, сведённых в таблицу 4.1.

Таблица 4.1

Сравнение СУБД

Название критерия выбора	SQL Server 2000	ORACLE 10g	MySQL
Стоимость сервера (лицензия на процессор и на сам сервер)	5448$	4995$	Общедоступная
Стоимость клиента	146$	149$	Общедоступная
Максимальное число пользователей	Зависит от лицензии	Зависит от лицензии	Зависит от лицензии
Технические требования к серверу	166 Мгц 64 Мб ОЗУ 140-500 Мб на HDD	300 Мгц 128 Мб ОЗУ 1,5 Гб на HDD	100 Мгц 64 Мб ОЗУ 100 Мб на HDD
Поддерживаемые серверные ОС	Windows 2000 Server, Windows 2000 Advanced Server, Windows 2000 Datacenter Server, Windows NT Server 4.0, Windows NT Server 4.0 Enterprise Edition	Windows 2000 Server, Windows 2000 Advanced Server, Windows 2000 Datacenter Server, Windows NT Server 4.0, Windows NT Server 4.0 Enterprise Edition, UNIX-подобныесистемы.	Windows 2000 (SP2), Windows Server 2003, Windows NT® 4.0 (SP6a иливыше), Windows XP Red Hat Enterprise Linux, SUSE Enterprise Linux Server 9 Solaris 7, 8, 9
Степень защищенности хранения данных	Средняя	Высокая	Средняя

На основании выбранных критериев проведем расчет технико-экономической эффективности MySQL, SQL Server 2000, ORACLE 10g.

Оценим их по каждому i-ому показателю качества по 5-ти бальной шкале.

Таблица 4.2

Шкала оценок

Параметр	Баллы	Оценка
	4	Отлично
	3	Хорошо
	2	Удовлетворительно
	1	Предельно допустимо
	0	Неприемлемо

Определим каждому критерию весовой коэффициент k_j, причем k_j= 1.

Результаты сравнения сведем результаты сравнения в таблицу 4.3

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

Для SQL Server 2000Q_s:

,

Для ORACLE 10gQ_d:

И для MySQL:



Таблица 4.3

Оценка технико-экономической эффективности

Параметры сравнения/оценка	Весовой коэффициент	MySQL	SQL Server 2000	ORACLE 10g
Стоимость сервера	0,15	4	0,6	1	0,1	1	0,2
Стоимость клиента	0,10	4	0,40	3	0,30	3	0,3
Максимальное число пользователей	0,10	3	0,3	3	0,3	3	0,3
Технические требования к серверу	0,15	3	0,45	2	0,3	1	0,15
Поддерживаемые серверные ОС	0,05	3	0,15	4	0,2	3	0,15
Степень защищенности хранения данных	0,20	4	0,8	2	0,4	1	0,2
Интегральный технико-экономический показатель, Q	=1		Qa= 3,7		Qs = 2,1		Qo = 1,8

Интегральный технико-экономический показатель между MySQL и SQL Server 2000, равен:

Q = Q_a/ Q_s = 3,7/2,1 = 1,76

Между MySQL и ORACLE 10g,равен:

Q = Q_a/ Q_o = 3,7/1,8 = 2,06

На основании проведенных расчетов можно сделать следующий вывод: интегральный технико-экономический показатель больше 1, что говорит в пользу MySQL и о целесообразности выбора данной СУБД.

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

4.2 Обоснование выбора средства реализации

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

Вначале хотелось бы объяснить свой выбор: HTML и ASP

ASP (Active Server Pages) является фирменным «языком» сценариев Microsoft. Вообще говоря, ASP - это не язык, а расширение Visual Basic для создания сценариев. По этой причине всякому, кто знаком с Visual Basic, относительно легко освоить ASP.

Каковы недостатки? Во-первых, ASP обычно работает медленнее, чем HTML. Фундамент ASP образует архитектура, основанная на СОМ. Поэтому когда программа ASP обращается к базе данных или осуществляет вывод данных для клиента, это происходит при посредстве СОМ-объектов других сервисов NT или уровней операционной системы. Эти связанные с СОМ накладные расходы могут накапливаться и приводить к тому, что во всех случаях, кроме выдачи простых страниц при среднем трафике, производительность оказывается невысокой. Во-вторых, ASP не вполне годится для переноса на другие платформы и интеграции со средствами GNU, а также средами и серверами open source.

Будучи фирменной системой Microsoft, ASP в основном применяется с ее же Internet Information Server (IIS), из-за чего ASP обычно выбирают ограниченно - для 32-разрядных систем Windows, поскольку для большинства серверов эта технология служит бесплатным приложением. Существуют версии ASP для UNIX (например, Chilli Soft ASP) и ряд интерпретаторов ASP для других систем и веб-серверов, однако для них стоимость системы с учетом ее производительности может оказаться неоправданно высокой.

Однако технология ASP.NET весьма отличается. В будущем ASP может существенно поднять свою производительность и возможность масштабирования. Это будет достигнуто дальнейшим усилением архитектуры .NET/COM и управляющей среды. Однако реальных преимуществ можно достичь лишь при условии значительных затрат на различные сопутствующие серверы.

HTML и Cold Fusion

HTML работает практически на всех платформах, а версии Cold Fusion есть только для Win32, Solaris, Linux и HP/UX. HTML требует больших начальных навыков программирования, в отличие от ColdFusion с совершенной интегрированной средой разработки (IDE) и более простыми языковыми конструкциями HTML менее требователен к ресурсам.

HTML и Perl

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

Хотя Perl в ходу достаточно долго (он был разработан в конце 1980-х) и широко поддерживается, он превратился в сложную конструкцию из дополнений и расширений и часто просто избыточен. Формат HTML легче для восприятия при сохранении гибкости.

HTML и Java

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

Кроме того, Java часто обходится дороже, поскольку в большинстве компаний, в конечном счете, устанавливают отдельную машину для Java Enterprise и используют Oracle или другое дорогостоящее ПО. При всем этом HTML требует дальнейшего развития, поскольку не обладает такой же переносимостью и некоторыми удобными возможностями, такими как пул объектов или отображение баз данных, которые есть в Java.

Так же хотелось бы рассказать об истории HTML:

Язык HTML был разработан британским учёным Тимом Бернерсом-Ли приблизительно в 1991--1992 годах в стенах Европейского совета по ядерным исследованиям в Женеве (Швейцария). HTML создавался как язык для обмена научной и технической документацией, пригодный для использования людьми, не являющимися специалистами в области вёрстки. HTML успешно справлялся с проблемой сложности SGML путём определения небольшого набора структурных и семантических элементов (размечаемых «тегами»), служащих для создания относительно простых, но красиво оформленных документов. Помимо упрощения структуры документа, в HTML внесена поддержка гипертекста. Мультимедийные возможности были добавлены позже. Изначально язык HTML был задуман и создан как средство структурирования и форматирования документов без их привязки к средствам воспроизведения (отображения). В идеале, текст с разметкой HTML должен был без стилистических и структурных искажений воспроизводиться на оборудовании с различной технической оснащённостью (цветной экран современного компьютера, монохромный экран органайзера, ограниченный по размерам экран мобильного телефона или устройства и программы голосового воспроизведения текстов). Однако современное применение HTML очень далеко от его изначальной задачи. Например, тег <TABLE>, несколько раз использованный для форматирования страницы, которую вы сейчас читаете, предназначен для создания в документах самых обычных таблиц, но, как можно убедиться, здесь нет ни одной таблицы. С течением времени, основная идея платформо-независимости языка HTML была отдана в своеобразную жертву современным потребностям в мультимедийном и графическом оформлении.



5. Социальная значимость проекта

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

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

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

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

6. Технико-экономическое обосновани...