Расширение ответов на обращения к базе данных, используя данные из внешних источников данных

Расширение ответов на обращения к базе данных, используя данные из внешних источников данных

Иллюстрации

Показать все

Реферат

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

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

[0001] Функционирование программного приложения зависит от рационального использования вычислительных ресурсов.

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

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

[0003] В дополнение к внутренним данным, пользователи иногда хотят осуществлять доступ к данным из внешнего источника или источников данных, с тем чтобы просматривать такие данные наряду с полученными данными внутренней базы данных. Для того чтобы это делать, необходимо разработать приложение (поставщик источников данных), которое понимает, как обмениваться информацией с каждым внешним источником, например, понимает его модель аутентификации, протоколы связи (строки подключения) и/или любую другую информацию, такую как требования по биллингу. Разработка такого приложения лежит за пределами квалификации и/или она слишком трудоемкая для типичного автора обращений, который, вообще говоря, хочет всего лишь анализировать данные.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

[0004] Этот раздел «Сущность Изобретения» предоставляется для того, чтобы представить подборку показательных концепций в упрощенном виде, которые дополнительно описываются ниже в разделе «Подробное Описание». Этот раздел «Сущность Изобретения» не предназначается для того, чтобы идентифицировать ключевые признаки или существенные признаки заявляемого изобретения, а также не предназначается он и для его использования каким-либо образом, ограничивающим объем заявляемого изобретения.

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

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

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

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

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

[0009] Фиг.1 представляет блок-схему, иллюстрирующую иллюстративную систему для расширения ответов на обращения к базе данных, используя данные из внешних источников данных.

[0010] Фиг.2 представляет схему последовательности операций, иллюстрирующую этапы для расширения ответов на обращения к базе данных, используя данные из внешних источников данных, в соответствии с одним иллюстративным вариантом осуществлений.

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

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

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

[0014] Фиг.6 представляет собой схему последовательности операций, иллюстрирующую этапы для задания соответствия компонент логического объекта внешним источникам данных, согласно одному иллюстративному варианту осуществления.

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

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

ПОДРОБНОЕ ОПИСАНИЕ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЙ

[0017] Разнообразные аспекты технологии, описанной в настоящем документе, предназначаются, вообще говоря, для того, чтобы дополнять ответы на обращения к базе данных, используя данные, которые извлекаются из внешних источников данных. Обращение к базе данных включает в себя один или больше параметров, задающих один или больше критериев для отбора данных из внешних источников данных. Один иллюстративный параметр включает в себя идентификатор логического объекта (например, наименование) для группы типов данных. Каждый тип данных может включать в себя один или больше других типов данных. Другие иллюстративные параметры включают в себя один или больше показателей для одного или больше типов данных из группы типов данных. Некоторые другие иллюстративные параметры могут представлять собой контекстуальные параметры, которые ограничивают показатели, возвращаемые внешним источником данных, по отношению к конкретному времени и/или местоположению, например. Поскольку расширенные ответы на обращение к базе данных включают в себя табличные данные, группа типов данных определяет один или больше столбцов, в то время как упомянутые одно или больше показателей определяют одну или больше строк. В одном иллюстративном варианте осуществлений, данные столбца внутри каждой строки табличных данных соответствуют этим одному или больше показателям.

[0018] В одном иллюстративном варианте осуществлений, обращение к базе данных имеет отношение к расширению данных компании разнообразной информацией, иллюстрируемой как в качестве примера финансовая информация, такая как стоимости ценных бумаг, статистические данные персонала, отчеты о прибыли, показатели рыночной капитализации ("market caps"), недавние цены биржевых котировок и/или тому подобное. Один или больше внешних источников данных, таких как финансовые средства массовой информации, фондовые рынки, поисковые системы и/или тому подобное, предоставляют различную финансовую информацию для одного или больше наименований компаний, в ответ на вызовы собственных функций или обращения ("запросы"), запрашивающие такие данные. Типы данных, которые определяют части разнообразной финансовой информации, составляют логический объект. Следовательно, обращение к базе данных включает в себя наименование логического объекта и одно или больше наименований компаний в качестве параметров.

[0019] Иллюстративный логический объект включает в себя некоторое количество компонент (то есть типов данных), включая компоненты, представляющие численность персонала, рыночную капитализацию (market cap) и стоимость ценных бумаг. Многие другие компоненты могут быть включены в состав логического объекта, например, руководство компании, валовой оборот, штат, где была произведена регистрация, годы существования и т.д. Для доступа к таким данным из внешнего источника, механизм преобразований предоставляет один или больше иллюстративных параметров, включающих в себя любую из компонент логического объекта (например, идентифицированных в пользовательском запросе), и дает команду программным средствам обеспечения связи, работающим на подходящем внешнем источнике данных, исполнять собственную функцию. Следовательно, программные средства обеспечения связи возвращают показатели для численности персонала, показатель рыночной капитализации и/или стоимости ценных бумаг, например, если таковые конкретизируются.

[0020] В качестве примера, рассмотрим предприятие с таблицей "companies" под названием (name) C, содержащей строки наименований компаний со столбцом данных о почтовых индексах (zipcode) (среди, вероятно, многих других столбцов) для разнообразных строк компаний. Рассмотрим случай, когда внутренняя база данных не включает в себя данные биржевых котировок (stock ticker) или численность персонала (num_employees) для каждой компании, но когда такая информация является доступной из внешних источников. Чтобы просматривать данные, отформатированные как name, zipcode, ticker и num_employees, в предшествующие времена нужно было иметь прикладное приложение (поставщик), для слияния результатов внутренних обращений с данными из внешних источников. С помощью расширений данных, пользователю нужно всего лишь задать заранее определенный логический объект (например, "CompanyFinancial"), который включает в себя подходящие компоненты, такие как ticker, num_employees, market_cap и т.д., и подать подходящее обращение:

SELECT name, zipcode, ticker, num_employees

FROM Companies с

ENRICH on CompanyFinancial (c.name).

[0021] Первая строка задает столбцы данных для получения, из которых name и zipcode являются доступными из внутренней базы данных предприятия, в то время как ticker и num_employees являются доступными из внешнего источника (или источников). Вторая строка обозначает таблицу, которую обогащают. Третья строка представляет собой расширение данных, в которой задается заранее определенный логический объект "CompanyFinancial", который включает в себя компоненты для внешних данных, где параметр c.name задает для каких компаний возвращать внешние данные, а именно, для тех, которые находятся в таблице "Companies c". Отметим, что пользователь может просматривать логический объект "CompanyFinancial", чтобы определять, что требуемые столбцы данных (ticker и num_employees в этом примере) будут удовлетворены посредством задания этого логического объекта.

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

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

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

[0025] Как уже упоминалось выше, некоторые из иллюстративных параметров могут включать в себя контекстуальные параметры, которые определяют местоположение и/или показатель времени. Механизм преобразований использует контекстуальные параметры для того, чтобы идентифицировать данные, которые соответствуют показателям местоположения и/или времени, из внешнего источника данных. Например, механизм преобразований использует специфические дату/время в качестве параметра вызова собственной функции для того, чтобы отбирать стоимость ценных бумаг в конкретные дату/время. В качестве другого примера, механизм преобразований инициирует вызов другой собственной функции для вычисления средней стоимости ценных бумаг за временной интервал (например, за некоторое количество дней).

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

[0027] Фиг.1 представляет блок-схему, иллюстрирующую иллюстративную систему для расширения ответов на обращения к базе данных, используя данные из внешних источников данных. Иллюстративная система (например, реализованная в одном сервере среди многих серверов) может обеспечивать действие разнообразных служб баз данных. Иллюстративная система включает в себя различные иллюстративные компоненты, такие как обработчик 102 SQL, сервер 104 расширений и механизм 106 преобразований, как это описывается в настоящем документе. Сервер 104 расширений может представлять собой один или больше серверов, содержащих службу расширений.

[0028] Обработчик 102 SQL принимает обращения к базе данных, включающие в себя разнообразные параметры (то есть иногда называемые параметрами расширений), такие как идентификатор логического объекта. Сервер 104 расширений может осуществлять доступ к данным логического объекта 108 и проверять, что каждая компонента в обращении является доступной из внутренних данных 109 или же посредством логического объекта, который согласуется с идентификатором логического объекта. Что касается внешних компонент логического объекта, сервер 104 расширений использует механизм 106 преобразований для доступа к данным на одном или больше внешних источников 110_l-110_n данных и отбирает показатели для разнообразных компонент логического объекта. Эти показатели могут сохраняться в виде табличных данных внутри расширенного ответа на обращение к базе данных, который передается на обработчик 102 SQL посредством сервера 104 расширений. В одном варианте осуществлений, обработчик 102 SQL сконфигурирован заполнять части (например, один или больше столбцов табличных данных) внутренней базы 109 данных расширенным ответом на обращение к базе данных.

[0029] Для того, чтобы знать, как обмениваться информацией с каждым внешним источником, механизм преобразований осуществлеяет доступ к каталогу 112 с информацией, сохраняемой для каждого источника данных, который соответствует компоненте логического объекта. Например, в каталоге 112 имеются записи для каждого внешнего источника данных 110_l-110_n, причем каждая запись определяет протокол для обмена информацией с внешним источником данных, включая вызовы собственных функций, форматы данных, биллинговые процедуры, учетные данные безопасности и/или тому подобное. Каждый может легко оценить, что вместо каталога, или в дополнение к нему, может использоваться любой пригодный механизм для определения такой информации, включая обслуживание протокола и/или связанных с ним данных, в другом хранилище данных, жесткое программирование протокола и/или связанных с ним данных, в механизма преобразований и т.д.

[0030] Сервер 104 расширений и механизм 106 преобразований могут сохраняться и эксплуатироваться на локальном компьютере и/или в сети, чтобы управлять доступом к локальным и/или сетевым базе данных. Альтернативно, сервер 104 расширений и/или механизм 106 преобразований могут быть включены в состав приложений облачных вычислений (cloud computing), где локальный компьютер, в основном, эксплуатируется в качестве интерфейса для совместного использования вычислительных ресурсов в центре обработки данных удаленного сервера. В течение того времени, когда приложения облачных вычислений сохраняют табличные данные в некоторой внутренней базе данных, эта внутренняя база данных не сохраняется на локальном компьютере, например.

[0031] В соответствии с одним иллюстративным вариантом осуществлений, сервер 104 расширений может использовать политику 114, чтобы задавать соответствие каждой из разнообразных компонент логического объекта на подходящему внешнему источнику данных среди множества источников 110_l-110_n данных. Например, стратегия 114 может включать в себя предпочтения, ассоциированные с отбором подходящего внешнего источника данных. В качестве более конкретного примера, политика 114 может обозначать предпочтение бесплатным информационным службам перед коммерческими/платными информационными службами, в соответствии с которым сервер 104 расширений отбирает коммерческую/платную информационную службу только в том случае, если бесплатной возможности выбора не существует; кроме того, в политике может быть определено и ограничение на цену. В качестве другого примера, политика 114 может назначать высокий приоритет конкретному источнику данных. В случае, когда показатель для компоненты логического объекта не может быть получен или вычислен, сервер 104 расширений использует этот конкретный источник данных для доступа к данным для расширения ответа на обращение к базе данных.

[0032] В соответствии с одним иллюстративным вариантом осуществлений, множество внешних источников 110_l-110_n данных включает в себя любой тип удаленной или Интернет - службы данных (например, информационные web-каналы, сообщения, коммерческие или бесплатные базы данных, поисковые системы и/или тому подобное), из которой извлекаются табличные данные, и они затем используются, чтобы сгенерировать расширенный ответ на обращение к базе данных. Каждый из внешних источников данных 110₁–110_n реализует конкретный протокол, который позволяет другим компьютерным системам осуществлять доступ к табличным данным. Конкретный протокол может включать в себя интерфейс прикладного программирования, в котором вызов некоторых функций приводит к извлечению части табличных данных. Поскольку некоторые функции являются собственными для этого конкретного протокола, они могут быть названы как собственные функции.

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

[0034] Фиг.2 представляет собой схему последовательности операций, иллюстрирующую этапы для расширения ответов на обращения к базе данных, используя данные из внешних источников данных, в соответствии с одним иллюстративным вариантом осуществлений. Этапы, изображенные на Фиг.2, начинаются на этапе 202 и переходят к этапу 204, когда обращения к базе данных обрабатываются обработчиком 102 SQL. Этап 204 представляет собой распознавание параметров расширений внутри обращения к базе данных и передачу обращения к базе данных на сервер 104 расширений.

[0035] Этап 206 иллюстрирует извлечение параметров расширений из обращения к базе данных, которые включают в себя идентификатор логического объекта, и один или больше показателей для одной или больше компонент логического объекта. Как это описывается в настоящем документе, эти компоненты логического объекта включают в себя типы данных, ассоциированные с расширением обращения к базе данных. Результаты из внешних источников данных соответствуют одному или больше показателям, как это также описывается в настоящем документе. Этап 208 представляет собой задания соответствия компонент логического объекта внешним источникам данных. Один иллюстративный вариант осуществлений этапа 208 иллюстрируется на Фиг.6, в котором политика определяет, какой внешний источник данных использовать для получения данных для конкретной компоненты логического объекта.

[0036] Этап 210 реализует механизм 106 преобразований, который производит и передает собственные запросы разнообразных данных на внешние источники данных. Собственные запросы конфигурируются, в соответствии с протоколом для соединения с внешними источниками данных, для исполнения совместимых команд и получения результатов. В одном примере, собственные запросы включают в себя вызовы собственных функций, которые реализуются внешними источниками данных. На Фиг.3 показан иллюстративный вариант осуществлений этапа 210, в котором используется каталог для преобразования обращения к базе данных в форму таких вызовов собственных функций, запрашивающих данные для компонент логического объекта.

[0037] Этап 212 предназначается для обработки данных, принятых от внешних источников данных, в качестве ответа на собственные запросы. В одном иллюстративном варианте осуществлений, механизм 106 преобразований конвертирует данные, предоставленные внешним источником данных, в табличные данные, которые используются, чтобы сгенерировать расширенный ответ на обращение к базе данных. Сервер 204 расширений передает расширенный ответ на обращение к базе данных в обработчик 102 SQL, который возвращает представление расширенного табличного ответа и/или внедряет табличные данные во внутреннюю таблицу внутренней базы данных, например, в соответствии со схемой. Внутренняя таблица может обновляться автоматически на запланированной основе и тому подобное, например, посредством автоматического генерирования нового обращения на предмет внешних данных и использования этих данных в расширенном ответе данных, чтобы внедрять обновленные данные.

[0038] В необязательном порядке, сервер 204 расширений собирает статистические данные, касающиеся связанных с биллингом действий, диагностики источников данных и/или тому подобное. Эти статистические данные могут использоваться в разнообразных целях, таких как контроль расходов на биллинг, анализ источников данных и обновление политики. Например, политики может включать в себя ограничение использования для конкретного источника данных. Если статистические данные показывают, что ограничение использования было достигнуто, другой источник данных может быть отобран исходя из политики. Этап 214 представляет собой завершение расширений ответов на обращения к базе данных.

[0039] Фиг.3 представляет собой схему последовательности операций, иллюстрирующую этапы для использования каталога для передачи запросов разнообразной информации во внешний источник данных, в соответствии с одним иллюстративным вариантом осуществлений. Эти запросы конфигурируются так, чтобы представлять собой собственную команду для внешнего источника данных. Сервер 104 расширений использует механизм преобразований для создания этих запросов на основе обращения к базе данных, которое передается от обработчика 102 SQL. Этапы, изображенные на Фиг.3, начинаются на этапе 302 и переходят к этапу 304, где сервер 104 расширений осуществляет доступ к каталогу, реализуя механизм 106 преобразований.

[0040] Этап 306 представляет собой исследование записи в каталоге, ассоциированной с внешним источником данных. Этап 308 относится к идентификации протокола для обмена информацией с внешним источником данных. Каталожная запись определяет протокол для обмена информацией с внешним источником данных, включая вызовы собственных функций, форматы данных, биллинговые процедуры, учетные данные безопасности и/или тому подобное. Следовательно, такой протокол используется механизмом 106 преобразований для инициирования одного или больше вызовов собственных функций к внешнему источнику данных.

[0041] Этап 310 предназначается для установления соединения с внешним источником данных. Протокол каталожной записи также включает в себя местоположение, такое как IP-адрес, а так же любые процедуры аутентификации для внешнего источника данных. Например, имя пользователя учетной записи и пароль могут быть востребованы при доступе к внешнему источнику данных. После установления сеанса (например, сеанса HTTP или HTTPS), механизм 106 преобразований отбирает одну или больше конкретных баз данных или таблиц и инициирует вызовы, запрашивающие разнообразную информацию, как это иллюстрируется посредством этапа 312. Эти вызовы включают в себя вызовы собственных функций, ассоциированных с API внешнего источника данных. Этап 314 относится к завершению использования каталога, чтобы передавать запросы разнообразной информации во внешний источник данных.

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

[0043] Этап 406 предназначается для изучения формата, ассоциированного с данными, принятыми от внешних источников данных (хотя формат может быть известным заранее, например, из информации в каталоге). В одном иллюстративном варианте осуществлений, конкретный внешний источник данных возвращает показатели в особенном формате, таком как формат обозначений объектов JavaScript (JSON). Механизм 106 преобразований конвертирует эти показатели в табличные данные и подготавливает расширенный ответ на обращение к базе данных, как это представлено на этапе 408. Механизм 106 преобразований может выполнять дополнительную обработку в отношении этих показателей, такую как агрегирование стоимостей ценных бумаг за некоторый период времени и вычисление усредненной или медианной стоимости ценных бумаг.

[0044] Этап 410 предназначается для возвращения представления расширенной таблицы и/или заполнения внутренней базы данных, используя расширенный ответ на обращение к базе данных. С помощью сервера 104 расширений, табличные данные, созданные из показателей, которые были возвращены конкретным внешним источником данных, могут быть внедрены в некоторую таблицу или в один или больше столбцов внутри внутренней базы данных, в соответствии с одним иллюстративным вариантом осуществлений. В одном примере, табличные данные совместно используют подобную схему с помощью некоторой таблицы, что переводит функционирование по внедрению в ряд операций по копированию данных. Альтернативно, упомянутая некоторая таблица представляет собой незаполненную или временную таблицу вне пределов реляционной парадигмы, ассоциированной с внутренней базой данных. Этап 412 означает завершение расширенного ответа на обращение к базе данных.

[0045] Фиг.5 представляет собой схему последовательности операций, иллюстрирующую этапы для создания каталога, чтобы преобразовывать обращения к базе данных в собственные запросы к внешнему источнику данных, в соответствии с одним иллюстративным вариантом осуществлений. Каталог образует часть механизма 106 преобразований. Этапы, изображенные на Фиг.5, начинаются на этапе 502 и переходят к этапу 504, когда механизм 106 преобразований генерирует незаполненную запись в каталоге.

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

[0047] Этап 506 предназначается для соединения с внешним источником данных. Например, механизм 106 преобразований создает сеанс, использующий IP-адрес, с помощью интерфейса к внешнему источнику данных, такого как интерфейс прикладного программирования (API). Механизм 106 преобразований приступает к обмену информацией с внешним источником данных через этот интерфейс, что представляется этапом 508. В некоторых вариантах осуществлений, механизм 106 преобразований использует интерфейс для перечисления каждой имеющейся в наличии базы данных, и отбирает подходящую базу данных в ответ на политику, как это описывается в настоящем документе.

[0048] Этап 510 относится к определению требований для использования протокола, ассоциированного с внешним источником данных. В одном иллюстративном варианте осуществлений, механизм 106 преобразований идентифицирует функции, которые исполняются интерфейсом и сконфигурированы для возвращения разнообразной информации. Эти функции являются собственными для внешнего источника данных, и они предоставляют возможность доступа к одной или больше баз данных, имеющихся в наличии. Механизм 106 преобразований также определяет, какие учетные данные необходимы для поиска по одной или больше базе данных, имеющимся в наличии, в соответствии с одним примером. В альтернативном примере, механизм преобразований также определяет, используется ли уникальный формат или запатентованный формат для обмена данными с внешней базой данных. Любая информация, касающаяся требований касаемо использования протокола, сохраняется в незаполненной записи в каталоге, как это представляется этапом 512. Будучи заполненной, упомянутая запись в каталоге используется, чтобы обновлять каталог, что показывается этапом 514.

[0049] Этап 516 представляет собой принятие решения относительно того, обновлять ли дополнительно каталог другой записью для следующего внешнего источника данных. Если имеются еще внешние источники данных для изучения, этапы 504-514 повторяются. Если, с другой стороны, нет больше внешних источников данных для изучения, выполняется этап 516, во время которого завершается создание каталога. Каталог может быть перестроен и/или обновлен в любое подходящее время, например, всякий раз, как только добавляется новый источник данных или он изменяет свой протокол.

[0050] Фиг.6 представляет собой схему последовательности операций, иллюстрирующую этапы для задания соответствия компонент логического объекта внешним источникам данных, согласно одному иллюстративному варианту осуществлений. Каждая компонента логического объекта включает в себя тип данных, показатель или показатели которого расширяют ответ на обращение к базе данных. Как уже упоминалось в настоящем раскрытии, обращение к базе данных задает логический объект, который представляет собой компоновку типов данных. Этапы, изображенные на Фиг.6, начинаются на этапе 602 и переходят к этапу 604, когда механизм 106 преобразований изучает компоненту логического объекта.

[0051] Этап 606 относится к идентификации согласующихся внешних источников данных для компоненты логического объекта. Согласующиеся внешние источники данных конфигурируются таким образом, чтобы предоставлять информацию, которая соответствует компоненте логического объекта. Например, согласующиеся внешние источники данных предоставляют данные, имеющие тот же тип данных, что и компонента логического объекта. Данные, предоставляемые согласующимися внешними источниками данных, могут потребовать дополнительной обработки. В качестве примера, такие данные включают в себя показатели, которые алгоритм использует в качестве входных параметров для вычисления другого показателя, который сохраняется в компоненте логического объекта.

[0052] После идентификации согласующихся внешних источников данных, этап 608 предназначается для доступа к политике, чтобы отобрать подходящий источник для запрашивания разнообразной информации, что представляется как этап 610. В одном иллюстративном варианте осуществлений, политика включает в себя предпочтения для конкретных внешних источников данных, основанные на различных факторах, таких как требования по биллингу, характеристики работы и/или тому подобное. В одном примере, политика указывает предпочтение для бесплатных источников данных. В таком случае, только бесплатные источники из согласующихся внешних источников данных считаются пригодными для выбора. Если больше чем один согласующийся внешний источник данных является бесплатным, то любой из них может быть отобран.

[0053] Этап 612 представляет принятие решения относительно того, следует ли задавать соответствие другой компоненты логического объекта подходящему внешнему источнику данных. Если еще остались компоненты логического объекта, сервер расширений, посредством механизма 106 преобразований, возвращается к Этапу 604 и повторяет каждый этап вплоть до 610 для следующей компоненты логического объекта. Если, с другой ст