9.3. Заказанные карты 399

9.3.2 Два применения заказанных карт

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

Базы данных полета

Есть несколько веб-сайтов в Интернете, которые позволяют пользователям выполнять вопросы на flight базах данных, чтобы найти flights между различными городами, как правило с намерением покупки билета. Чтобы сделать вопрос, пользователь определяет происхождение и города назначения, дату отбытия, и время отъезда. Чтобы поддержать такие вопросы, мы можем смоделировать flight базу данных как карту, где ключи - объекты Полета, которые содержат области corre-sponding к этим четырем параметрам. Таким образом, ключ - кортеж

k = (происхождение, место назначения, дата, время).

Дополнительная информация о flight, таком как flight число, число мест, все еще доступных в первом (F) и тренер (Y) класс, flight продолжительность, и плата за проезд, может храниться в объекте стоимости.

Нахождение требуемого flight не является просто вопросом нахождения ключа в карте, соответствующей требуемому вопросу, как бы то ни было. Главная трудность состоит в том, что, хотя пользователь, как правило, хочет точно соответствовать происхождению и городам назначения, а также дате отбытия, он или она, вероятно, будет доволен любым временем отъезда, которое является близко к его или ее требуемому времени отъезда. Мы можем обращаться с таким вопросом, конечно, заказывая наши ключи лексикографически. Таким образом, учитывая пользователя подвергают сомнению ключ k, мы могли, например, назвать ceilingEntry (k), чтобы возвратить flight между желаемыми городами в желаемую дату со временем отъезда в желаемое время или после. Подобное использование floorEntry (k) дало бы нам flight со временем отъезда в желаемое время или прежде. Учитывая эти записи, мы могли тогда использовать higherEntry или функции lowerEntry, чтобы найти flights со следующим рядом с исходными временами, которые соответственно выше или ниже, чем желаемое время, k. Поэтому, эффективное внедрение для заказанной карты было бы хорошим способом удовлетворить такие вопросы. Например, звонить ceilingEntry (k) на ключе вопроса k = (ПОРЯДОК, PVD, 05May, 09:30), сопровождаемый соответствующими требованиями к higherEntry, могло бы привести к следующей последовательности записей:

((ПОРЯДОК,

PVD,

05May,

09:53),

(AA

1840, F5, Y15, 02:05, 251$))

((ПОРЯДОК,

PVD,

05May,

13:29),

(AA

600, F2, Y0, 02:16, 713$))

((ПОРЯДОК,

PVD,

05May,

17:39),

(AA

416, F3, Y9, 02:09, 365$))

((ПОРЯДОК,

PVD,

05May,

19:50),

(AA

1828, F9, Y25, 02:13, 186$))

400 Глава 9. Хеш-таблицы, карты и списки пропуска

Наборы максимумов

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

Мы можем смоделировать такую проблему компромисса как это при помощи пары значения ключа, чтобы смоделировать два параметра, между которыми мы балансируем, который в этом случае был бы парой (стоимость, скорость) для каждого автомобиля. Заметьте, что некоторые автомобили строго лучше, чем другие автомобили, используя эту меру. Например, автомобиль с парой скорости стоимости (20000, 100) строго лучше, чем автомобиль с парой скорости стоимости (30000, 90). В то же время есть некоторые автомобили, которые не являются строго во власти другого автомобиля. Например, автомобиль с парой скорости стоимости (20000, 100) может быть лучше или хуже, чем автомобиль со стоимостью - пара скорости (30000, 120), в зависимости от того, сколько денег мы должны потратить. (См. рисунок 9.8.)

Рисунок 9.8: согласование работы стоимости с парами значения ключа, представленными пунктами в самолете. Заметьте, что пункт p строго лучше, чем пункты c, d и e, но может быть лучше или хуже, чем пункты a, b, f, g, и h, в зависимости от цены, которую мы готовы заплатить. Таким образом, если мы должны были добавить p к нашему набору, мы могли бы удалить пункты c, d, и e, но не другие.

Формально, мы говорим, что пара ценовой работы (a, b) доминирует над парой (c, d) если <c и b> d. Пару (a, b) называют максимальной парой, если это не во власти никаких других пар. Мы интересуемся поддержанием набора максимумов коллекции C цены - исполнительные пары. Таким образом, мы хотели бы добавить новые пары к этой коллекции (например, когда новый автомобиль введен), и мы хотели бы подвергнуть сомнению эту коллекцию для данной суммы в долларах, d, найти самый быстрый автомобиль, который стоит не больше, чем d долларов.