Предположим, что простая база данных Stockinfo содержит
информацию о разных биржах. База данных содержит информацию о
ценах закрытия каждой биржи для каждого торгового дня. Каждая
строка таблицы соответствует отдельной бирже, и информация о
ценах закрытия P1, P2, ..., Pm содержится в одном столбце
Clprice как временная серия - новый тип данных. Запрос,
направленный на поиск привлекательных для инвестиций бирж, мог бы
иметь следующую форму: "Найти все биржи из списка OTC с текущей
ценой закрытия, меньшей $30, с отношением цена/доход, меньшим 15,
с бета (мерой устойчивости) за последний год, меньшей или равной
единице, и такие, у которых цена возрастала более чем на 10
процентов в течение последних двух месяцев".
SELECT FROM Stockinfo Candidate AS
Symbol, Industry, #PRICE (Clprice), Earnings,
#BETA (Clprice, 240), #%CHANGE (Clprice, 40)
WHERE Exchange = NASDAQ AND #PRICE (Clprice) < 30 AND
#BETA (Clprice, 240) 10%
Здесь #BETA (S,n), #PRICE (S) и #%CHANGE (S,n) - новые методы,
применимые к временным рядам S и вычисляемые для последних n
элементов; для PRICE (S) n=1.
Поскольку база данных бирж очень велика, требуется выполнить этот
запрос наиболее эффективным способом. В идеале, все вычисления
нужно было бы выполнить параллельно для каждой строки. Однако на
практике степень параллельности будет ограничена числом доступных
процессоров и возможностями программного обеспечения.
Заметим, что столбец Clprice меняется в каждый торговый день и
содержит гораздо больше данных, чем другие столбцы (Symbol, Name,
Address, Exchange, Industry и т.д.). Поэтому может оказаться
разумным хранить элементы столбца Clprice отдельно от строк, в
которые они входят; стратегии буферизации данных в реляционных
СУБД не работают с большими элементами столбцов так же хорошо,
как с малыми, и обычно их плохо удается обрабатывать единообразно
совместно. В разделе WHERE содержится смесь стандартных и
нестандартных операторов SQL. Если это является обычной ситуацией