Система и способ оптимизированного поиска снизу вверх

Система и способ оптимизированного поиска снизу вверх

Иллюстрации

Показать все

Реферат

УРОВЕНЬ ТЕХНИКИ

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

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

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

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

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

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

Одиночная ячейка доступности получается из четко определенной продолжительности остановки (LOS) в поисковом запросе. LOS получается из начальной даты и конечной даты в поисковом запросе. Для множественных возможных совокупностей, которые могут быть получены из LOS в поисковом запросе, отсутствует видимость. Например, если запросчик желает также оценить различные опции в отношении LOS, он будет требовать несколько отдельных запросов поиска для каждой опции LOS. Известный уровень техники не обеспечивает гибкость альтернативных дат или единиц товара. Стоимость и время, требуемые для создания ответа с полной гибкостью, не экономичны в настоящее время. Например, если клиент желает проверить доступность для первой недели мая, потребуются 49 отдельных ячеек доступности. Семь ячеек доступности на каждый день недели (т.е. 7 дней X 7 значений LOS в день). Эта транзакция будет увеличивать стоимость в 48 раз (т.е. разницу между 1 запросом и 49 запросами), и будет приводить к очень большому времени ответа клиенту (т.е. плохой ориентированности на пользователя).

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

Фиг.1А изображает схему системы бронирования гостиницы.

Фиг.1B изображает архитектуру базовых конструктивных блоков настоящего изобретения в одном варианте выполнения.

Фиг.2 изображает архитектуру настоящего изобретения в уже другом варианте выполнения.

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

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

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

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

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

ПОДРОБНОЕ ОПИСАНИЕ

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

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

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

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

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

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

Настоящее изобретение обеспечивает улучшенную систему транзакции доступности комнат гостиницы. Фиг.1А изображает архитектуру системы бронирования гостиницы известного уровня техники; а именно системы HOLEDEX (HDX), предлагаемая Six Continents Hotels, Inc. для ее мировой сети гостиниц. Настоящее изобретение может быть использовано в сочетании с этой системой или любой другой пригодной системой бронирования гостиницы, доступной на рынке.

В системе бронирования на фиг.1А сервер HDX 101 хранит текущую доступность по датам, тарифам, а также другой подробной информации, касающейся комнат гостиницы. Различные клиенты 102а, 102b, 102c и 102d могут подавать запросы серверу HDX 101. Например, клиенты 102а могут содержать веб-сайты путешествий, связанные с сервером HDX 101 с помощью промежуточного центра 103 данных, использующего, например, протокол OTA или XML, чтобы связываться с сервером HDX 101. Клиенты 102b могут содержать глобальные системы распределения (GDS), например, Sabre, Galileo, WorldSpan, Amadeus или TravelWeb, использующие, например, протокол Pegasus, чтобы связываться с сервером HDX 101. Корпоративные собственники брендов гостиниц могут связываться с помощью клиентов 102c с сервером HDX посредством, например, протоколов 3270 или XML. Наконец, индивидуальные гостиницы 102d могут связываться с сервером HDX 101, используя, например, протокол XML и/или HMI.

Запросы поиска доступности, поданные клиентом (102а, 102b, 102c и/или 102d) в сервер HDX 101, могут включать как минимум код гостиницы, дату прибытия и дату отбытия. Так как поиск множественных гостиниц, множественных диапазонов данных и т.д., может обычно приводить к необходимости множественных поисков на сервере HDX 101, настоящее изобретение обеспечивает улучшенный путь выполнения поисков, как описано дополнительно ниже. Наибольшая трудность в сегодняшних средах (т.е. аппаратном обеспечении и сети) в каждом главном центре данных представляет собой огромный рост 60% трафика доступности каждый год. Наиболее эффективный процесс поиска представляет собой неустойчивый баланс между предварительно вычисленными данными и готовыми данными. Когда миллионы запросов поиска попадают в систему бронирования каждый день, накопление имеющейся части уже вычисленных данных доступности переводится в мощную систему транзакции доступности. Для определения того, как наиболее эффективно выполнять поиски на сервере HDX 101, процесс определения доступности размечается с возможностью распределения по категориям каждого этапа, основываясь на различных критериях. Тогда как распределение по категориям может принимать многие формы, в одном варианте выполнения может быть использованы следующие критерии из Таблицы А:

Таблица А
Критерий	Метка
Процесс нахождения	Каждый элемент доступности классифицируется (низкий-высокий), основываясь на количестве ячеек базы данных и логике, требуемой для нахождения товарной единицы, для запроса. Например, в одном варианте выполнения, классифицирование может быть следующим:Гостиница = низкийКатегория тарифа = низкийТорговая единица = высокий
Циклы обработки	Каждый компонент бизнес-логики может быть классифицирован (низкий-высокий), основываясь на величине необходимого времени обработки. Например, в одном варианте выполнения классифицирование может быть следующим:Закрыть для прибытия = низкийОстановиться на несколько дней = среднийЧистый доход = высокий
Уровень доступности	Каждый компонент бизнес-логики может быть связан с элементом доступности, который выполняет специальную бизнес-логику. Например, в одном варианте выполнения:Чистый доход = товарная единицаОстановиться на несколько дней = категория тарифа

Как изображено на фиг.1B, настоящее изобретение включает PreCompute Availability Database 151 (База данных предварительно вычисленной доступности), а также Availability Rule Calculator Engine 152 (Механизм вычисления правил доступности). В одном варианте выполнения PreCompute Availability Database 151 может содержать относительную базу данных, которая имеет 2 главные характеристики:

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

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

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

• Физическую продолжительность остановки (LOS). Это строковое значение представляет битовую маску для каждой ночи вплоть до остановки, например, на 14 дней (любая другая максимальная LOS может быть также выбрана). Физическая доступность типа комнаты может использовать представления о планировке, полном количестве комнат и пролете типа комнат дома. Эти правила могут применяться повторно для каждой ночи маски LOS.

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

• Доход LOS. Это строковое значение может представлять битовую маску для каждой ночи вплоть до остановки, например, на 14 дней (или любую другую максимальную LOS). Компонент управления доходом может использовать вычисление чистого дохода, основываясь на LOS. Положительный доход может быть представлен открытым (1), а отрицательный доход может быть представлен закрытым (0). Может быть несколько опций дохода, которые могут указывать на использование другого значения, основываясь на другом тарифе или коррекциях. Эти правила могут применяться повторно для каждой ночи маски LOS.

• Код тарифа. Концепция паритета может использовать код тарифа для поддержания уровней отношения между всеми кодами тарифа.

Структура этой относительной базы данных создает очень быстрый путь получения единиц товара. Возможно соединять PreCompute Availability Database 151 с таблицами атрибутов для того, чтобы обеспечивать фильтры на этом начальном этапе. Некоторые из атрибутов, наподобие типа кровати, количества кроватей и/или максимальной вместимости могут в одном варианте выполнения помогать предварительно выбирать товарные единицы. Это отличается от известного уровня техники, который применяет фильтры в конце процесса определения доступности, что приводит к лишним циклам обработки на несоответствующих товарных единицах.

Значения, которые управляются с помощью LOS, могут использовать представление битовой маски. Каждый бит представляет ночь, и значения могут быть открытыми (1) или закрытыми (0). Здесь нет ограничений того, как долго LOS может представлять. Подходящее значение может соответствовать подходящей аудитории или бренду гостиницы. Например, в одном варианте выполнения бренды c продленным сроком пребывания могут иметь вплоть до 28 дней или больше предварительно вычисленных LOS.

Как показано на фиг.2, в одном варианте выполнения Availability Rule Calculator Engine 152 и PreCompute Availability Database 151 могут содержать предварительно вычисленную структуру, содержащую приложение J2EE 201, которое использует сообщения из Web Sphere MQ 202 и обрабатывает эти сообщения и обновляет базу данных Oracle 203 требуемыми данными. Эта структура может содержать приложение J2EE 201, которое может включать приложение Core Java 204. Фиг.2 изображает всю структуру с главными компонентами в каждом из приложений, согласно одному варианту выполнения настоящего изобретения. Другие пригодные структуры могут быть также использованы.

Фиг.3 представляет собой схему последовательности высокого уровня, которая изображает в общем ход обработки сообщений в PreCompute Engine на Фиг.1B и 2. Эта схема последовательности показывает сценарий, когда сообщения поступают в последовательность и сразу же обрабатываются. Фиг.4 представляет собой блок схему архитектуры структуры, которая изображает полную схему настоящего изобретения в одном варианте выполнения.

Компоненты структуры на Фиг.2-4 будут определены дополнительно подробно ниже.

• PreComputeMDBean 211 - PreComputeMDBean 211 представляет собой управляемый сообщениями компонент, который ожидает в очереди 411 последовательностей MQ 202, которая принимает сообщения из HOLEDEX 101. Он вызывает MessageManager 214, причем сообщение XML принимается из HOLIDEX 101.

• Stateless Session Beans 212: Могут быть использованы следующие компоненты 212 сеанса без запоминания состояния:

• BootStrapBean: используемый для запуска приложения. Log4j и другие ориентированные на Timer Task компоненты инициализируются здесь, когда приложение запускается.

• MessageManagerBean: Этот EJB используется для обработки сообщений для всех источников и клиентов. В основном, он может вызывать MessageManager 214 или продолжать его. Также этот компонент может вызываться с помощью MDB 211.

• Timer Beans 231 - Этот EJB использует Timer Service. Этот EJB используется для обработки сообщений, которые откладываются в таблице отложенных сообщений. Этот EJB работает в заданное время и вызывает MessageManager, блокирует любую гостиницу, которая имеет отложенные сообщения и обрабатывает сообщение. Важно обрабатывать результаты из Holidex последовательно. Выполнение кластерной среды (т.е. различные узлы могут получать обновления для одной и той же гостиницы в одно и то же время) требует выполнения этого способа обработки обновлений.

• Metric Manager 232 - Этот не сохраняющий данные компонент используется для сбора измерений в заданное время, используя Timer Service (сообщение каждый час). Он выполняет TimedObject. Этот EJB будет инициализироваться с помощью BootStrapBean при этом будет создаваться таймер.

• Data Clients 233 - компонент DataClients представляет собой одиночный компонент, который находится внутри PreCompute engine. Его роль является двойной. Во-первых, он обеспечивает специальную информацию, касающуюся того, как товарные единицы должны быть основаны на интересах Push-клиентов. И, во-вторых, он обеспечивает средство оповещения этих Push-клиентов об изменениях, как только они происходят.

Logging 234 - Log4J будут использоваться в качестве механизма регистрации данных для приложения. Зарегистрированные сообщения будут направляться в файл на сервер, на котором работает сервер приложения. Конфигурация для Log4j должна быть загружена, используя Bootstrap EJB или используя класс запуска в сервере приложения. Имеются различные уровни регистрации: отладка, информирование, предупреждение и ошибка.

MessageManager 214 - MessageManager 214 главным образом может выполнять две операции. Первая, он преобразует XML сообщение в объект Java, и далее, он может вызывать особый PreCompute Manager 216, основываясь на типе сообщения. Он также регулирует обработку последовательности сообщений, основываясь на коде гостиницы и последовательном номере сообщения. Если сообщения не находятся в последовательности, сообщение будут храниться в отдельной таблице для его обработки.

ManagerFactory 218 - класс Manager Factory 218 динамически создает PreComputeManagers 216, основываясь на типе сообщения. Как только он создает Manager, он может запоминать его для более позднего использования.

Классы XMLSchema Java - Эти классы XMLSchema Java могут быть частью Message Manager 214, и создаются, основываясь на XML сообщениях, принятых из HOLTDEX 101. Эти классы содержат значение XML элементов и атрибутов в их способе. Эти классы XML компонентов используются в качестве носителей данных, таким образом, исключая объект отдельного переноса данных для каждого сообщения.

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

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

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

• Validation Classes 222 (Классы проверки достоверности) - В одном варианте выполнения имеются отдельные классы проверки для каждого сообщения. Эти классы проверки проверяют сообщения и, если они находят ошибки, они запускают PreComputeException.

• Data Access Objects (DAOs) 226 - Data Access Objects 226 отделяют операции связи и CRUD, относящихся к базе данных Oracle 203. PreCompute Manager 216 вызывает подходящий DAO 226 для обновления таблицы. DAO 226 может быть основан на одиночной таблице или основан на связанных таблицах. В основном этот DAO 226 достигает соединения с базой данных из класса 228 DBConnector, подготавливает заявки SQL в базу данных и выполняет операции CRUD. Как только эти операции выполняются, он разъединяет соединение с базой данных 203.

• DBConnector 228 - DBConnector 228 представляет собой класс Java, который выделяет механизм соединения для базы данных 203. В одном варианте выполнения он будет получать соединение с базой данных 203 вызовом объекта источника данных. Это класс будет иметь различные способы, такие как, разъединение соединения, откат транзакции и т.д.

• PreCompute Utility Components - Общая для всех функция, необходимая для приложения, может быть разработана в качестве вспомогательных классов, таких как, проверка даты или преобразование специальных данных, которые необходимы приложению. Могут иметься определенные вспомогательные классы, характерные для типов сообщений.

Availability Rule Calculator Engine 152 может включать логику, сгруппированную в две категории:

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

• Бизнес-логику, которая была незначительно разделена во время обработки (основываясь на критерии, описанном ранее относительно Таблицы А), при этом она была связана с четко определенным элементом доступности.

Целевая задача заключается в разработке хорошего баланса между логиками PreCompute Availability Database 151 и Availability Rule Calculator Engine 152. Этот баланс может динамически регулироваться для поддержания высоких характеристик работоспособности. В случае, когда новая логика добавляется в модель доступности, это может преобразовывать подсчет в части элементов доступности, которые будут создавать новый баланс (т.е. золотую середину) между логиками PreCompute Availability Database 151 и Availability Rule Calculator Engine 152.

Availability Rule Calculator 152 управляет "активной" логикой процесса определения доступности. Бизнес-правила могут быть разделены на различные компоненты (т.е. калькуляторы доступности), таким образом, они могут быть выполнены независимо. Могут иметься определенные границы и ограничения, которые могут быть применены в реальном времени с каждым запросом. Например, они могут представлять атрибуты, которые гостиницы могут устанавливать для управления доступностью; например: предварительное приобретение, остановка на ночь, минимальная/максимальная остановка, специальные требования. Другие границы и ограничения могут обнаруживаться только на уровне гостиницы, уровне категории тарифа и уровне кода тарифа. Порядок того, как бизнес-правила применяются, может иметь непосредственное влияние во время цикла обработки.

Availability Rule Calculator engine 152 может иметь два главных компонента:

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

• Калькуляторы правил доступности. Каждый калькулятор (описанный дополнительно ниже относительно Фиг.5) осуществляет интерфейс MaskCalculator 507 и должен обеспечивать способ getMask(), который будет вызывать сборщик. Возвращенная маска логически умножается вместе с другими масками на текущую маску Productltems LOS, чтобы применять правило. Они также должны подавать код причины выполнением getReasonCode().

В одном варианте выполнения Availability Rule Calculator engine 152 может создаваться и работать, как описано дополнительно подробно ниже.

Модель классов

С внутренней стороны сборщик 502 совместно работает с несколькими компонентами "калькулятора" (507 и 601-606 на Фиг.6, описанными дополнительно ниже), причем каждому назначается особый класс правила продолжительностью остановки (LOS). В общем, каждый калькулятор возвращает битовую маску, которая логически умножается вместе с масками Productltem LOS, чтобы получить полную маску LOS.

Контекст сборки

Объект 503 CollectionContext используется для сохранения глобального состояния относительно цикла сборки. Когда посетитель взывает collect() на сборщике 502 (с помощью интерфейса 504 ProductltemCollector), сборщик 502 будет создавать объект 503 CollectionContext. CollectionContext 503 может иметь следующие характеристики:

• Код гостиницы

• Коды категорий тарифа

• Даты

• Объект базы данных

• Опции сборки

• Запомненные факты

CollectionContext 503 переводят в конструктор для каждого калькулятора. Конструктор задает среду каждого калькулятора, и представляет собой компонент программного обеспечения этого класса. Калькуляторы используют CollectionContext 503, чтобы получать базу данных 203 для выполнения запроса таблиц CRS. Они также используют его, чтобы делиться фактами друг с другом посредством объекта контекста. Например, Если гостиница обнаружена гостиницей HIRO, тогда этот факт может быть важным для более, чем одного калькулятора.

Калькуляторы

Калькуляторы (601-606) являются ключевыми компонентами бизнес-логики для PACE engine (механизма РАСЕ). CollectionStrategy 505 определяет, какие калькуляторы использовать, основываясь на том, что было установлено в опциях сборки 506. Каждый калькулятор осуществляет инерфейс MaskCalculator 507 и должен обеспечивать способ getMask(), который будет вызывать сборщика 502. Возвращенная маска логически умножается вместе с другими масками на текущую маску Productltems LOS, чтобы применять правило. Код причины также может быть предоставлен выполнением, например, getReasonCode().

Образцовый интерфейс для MaskCalculator 507 может быть:

Может иметься любое количество MaskCalculator 507. Фиг.6 изображает пример для текущей установки. В одном варианте выполнения калькуляторы могут содержать очень специфичные правила границ или ограничений модели доступности IHG, такие как:

• Arrival Calculator 601 - Он использует день прибытия запроса проверки, установлена ли в гостинице недоступная дата или закрытая для прибытия, или уровня категории тарифа.

• MinMax Calculator 602 - Он использует дату прибытия и дату отбытия для получения LOS. Значение LOS должно удовлетворять минимальному и максимальному количеству дней ограничения остановки, если оно существует.

• Revenue Calculator 603 - Он проверяет, что LOS для специальной величины тарифа создает положительный доход.

• RoomSS Calculator 604 - Он проверяет, что специальный тип комнаты связан со стратегией продажи комнат гостиницы. Стратегия продаж комнат гостиницы указывает типы комнат, которые видны для продажи.

• StayoverDays Calculator 605 - Он использует дату прибытия и дату отбытия для получения LOS. Значение LOS должно удовлетворять дням недели, на которые требуется остаться на ночь.

• Active Days Calculator 606 - Он использует дату прибытия и дату отбытия для получения LOS. Значение LOS должно удовлетворять дням недели, которые помечены активными.

Запас правил гостиницы

Предпочтительно иметь PACE engine, являющийся максимальной эффективным. На фиг.5 и 6 большая часть этого может ложиться на выполнение нескольких MaskCalculator 507, так как они включают правила гостиницы, зашифрованные в базе данных CRS. Каждый раз PACE engine создает новый MaskCalculator 507, причем Calculator 507 может оптимизировать себя предварительно выбирая данные, которые ему необходимы только один раз, из базы данных 203, и далее используя их повторно для каждого применения способа getMask(). Тем не менее, наличие запроса базы данных всеми калькуляторами для правил, которые редко изменяются, значительно влияет на работоспособность, и должно быть исключено.

Чтобы предусмотреть это, объект 503 CollectionContext (фиг.5) может включать возможность обеспечения запоминания правил для нескольких MaskCalculator 507. Как только MaskCalculator 507 создаст свои правила из базы данных 203, он может запоминать их на CollectionContext 503. Это, в свою очередь, означает, что все MaskCalculator 507 могут сначала выяснять, присутствуют ли еще необходимые правила до достижения базы данных 203 и создания правил заново. Эта модель будет способствовать увеличению работоспособности, и в связи с этим, может быть использована во всех возможных случаях.

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

После того, как MaskCalculator 507 запоминает правила, правила могут оставаться в памяти до тех пор, пока не возникнет один из следующих случаев:

• изменение правил гостиницы в базе данных 203

• память LRU стирает правила гостиницы для управления ресурсами

• приложение перезапускается

В одном варианте выполнения каждый из нескольких MaskCalculator 507 может делать попытки использовать способы запоминания и проверять их надежность. Если пригодное решение для управления запоминанием-изменением не доступно, тогда PACE engine может обеспечивать, что запоминание не активируется. Все же, несколько MaskCalculator 507 могут выполнять активацию запоминания в любое время.

Стратегии сборки

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

Чтобы предусмотреть это, PACE engine может использовать интерфейс CollectionStrategy 505, чтобы представлять, как действительно выполняется сборка. Это в основном представляет собой выполнение шаблона разработки Abstract Algorithm, известного специалистам в области техники. Выбор стратегии может быть основан на установках в CollectionOptions 506.

Образцовый интерфейс для CollectionStrategy 505 обеспечен ниже:

В одном варианте выполнения поддержанные CollectionStrategie 505 могут включать:

Класс		Описание
Основная стратегия		Абстрактный класс с основным шаблонным способом вычисления
Стратегия по умолчанию		Продолжает основную стратегию с критерием SQL для кодов категорий тарифов
Стратегия ID торговых единиц		Продолжает основную стратегию с критерием SQL для id торговых единиц

Запросы

Когда PACE engine вызывается, d конечном итоге, он может считывать товарные единицы из таблицы товарных единиц и применять MaskCalculator 507, чтобы получать конечную LOS. Запрос, используемый для выбора товарных единиц? может учитывать нескольких факторов. Они включают:

• Критерий выбора

• Историю LOS

• Исключения прямых продаж

Секции ниже описывают эти аспекты для запроса более подробно.

• Базовый запрос

• История LOS

• Исключения прямых продаж

(1) Базовый запрос

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

Критерий для базового запроса включает следующее:

• Код гостиницы

• Диапазон дат

• Коды категорий тарифа

• Действующий статус

• Принятое изменение (дополнительно)

• Исключенные коды комнат (дополнительно)

• ID товарных единиц (дополнительно)

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

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

Порядок, при котором товарные единицы подаются в ProductltemConsumer важен по двум причинам. Первая, он позволяет нескольким Calculator 507 (Калькуляторам) эффективно вести себя в контекстном переключении. Вторая, он позволяет нескольким ProductltemConsumer просто получать результаты их создания.

В связи с этим, результаты могут быть упорядочены следующим образом:

• Дата

• Код категории тарифа

• Код комнаты

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

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

• принимают запрос для, по меньшей мере, одной гостиницы на диапазоне дат, причем диапазон дат имеет начальную дату и конечную дату (этап 702);

• вычисляют доступность для каждого дня в пределах диапазона дат на множестве продолжительности остановок применением бизнес-требований согласно запросу (этап 703);

• создают конечную доступность для каждого дня в пределах диапазона дат на множестве продолжительности остановок объединением доступности из предварительно вычисленной базы данных и атрибутов запроса (этап 704); и

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

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

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

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