Способ и система для унификации данных

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

 

Приоритет настоящей заявки заявлен по дате подачи предварительной заявки на патент США № 60/398841, поданной 26 июля 2002 г.

Область техники, к которой относится изобретение

Настоящее изобретение относится к области управления базами данных. Оно может найти конкретное применение как способ и система для доступа к неоднородным данным во множестве баз данных.

Уровень техники

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

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

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

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

Раскрытие изобретения

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

Согласно другому варианту настоящего изобретения предложена система для управления данными во множестве источников данных. Система содержит UniDimNet и множество UniView. UniDimNet содержит множество UniDim, представляющих аспекты отраслевого бизнес-контекста, и множество UniSourceDim, представляющих аспекты, специфические для каждого источника данных. Каждый UniDim связан по меньшей мере с одним другим UniDim и каждый DataSourceDim связан по меньшей мере с одним UniDim. UniView можно объединять в комплексные запросы. Комплексный запрос может иметь набор входных параметров, которые не содержат идентификации конкретного источника данных.

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

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

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

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

Краткое описание чертежей

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

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

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

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

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

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

фиг.6А-6С изображают примерные схемы взаимосвязей структур данных согласно одному варианту настоящего изобретения,

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

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

фиг.9 изображает примерную схему взаимосвязей UniView согласно одному варианту настоящего изобретения,

фиг.10 изображает примерную схему UniViewInterface согласно одному варианту настоящего изобретения,

фиг.11 изображает примерную схему CompundUniView согласно одному варианту настоящего изобретения,

фиг.12 изображает примерную схему UniBuilder согласно одному варианту настоящего изобретения,

фиг.13 изображает примерную схему UniServer согласно одному варианту настоящего изобретения,

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

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

фиг.16-19 изображают примерные моментальные снимки экрана интерфейса UniViewer согласно одному варианту настоящего изобретения,

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

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

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

Осуществление изобретения

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

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

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

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

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

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

В данном контексте термин "механизм доступа к данным" используется взаимозаменяемо с термином "механизм поиска данных" и в родовом смысле, включая, без ограничения перечисленным, программное приложение или модуль программного приложения, который облегчает доступ к данным или поиск данных в источнике данных. Обычно механизм доступа к данным является специфическим для базы данных и/или программного приложения (или типа базы данных или типа программного приложения), к которому он относится, и приспособлен для доступа к нему в ответ на запрос. Примерные механизмы доступа к данным включают в себя, без ограничения перечисленным, предварительно заготовленные запросы к базам данных, предварительно заготовленные визуальные отображения баз данных и наборы интерфейсов прикладных программ (ИПП).

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

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

Термин "аспект отраслевого бизнес-контекста" используется взаимозаменяемо с понятием "аспект".

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

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

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

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

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

Термин "сеть" в данном контексте используется в родовом смысле и включает в себя, без ограничения перечисленным, Интернет, интранет, глобальные вычислительные сети, локальные вычислительные сети и приемопередающие соединения, такие как модуляторы-демодуляторы (модемы).

Один вариант настоящего изобретения направлен на систему, способ и структуры базы данных для унификации данных из множества неоднородных баз данных, каждая из которых содержит данные, связанные с бизнес-контекстом, и механизм доступа к этим данным. Создается база данных (UniDimNet), которая содержит узел для каждого аспекта отрасли промышленности. Для каждого источника данных, доступ к которому возможен через эту систему, создается набор аспектов, специфических для источника данных, и этот набор отображается в соответствующем аспекте (аспектах) отраслевого бизнес-контекста. Создается набор шаблонов (UniView) для запроса источников данных. Каждый UniView содержит конкретный вопрос для конкретного аспекта, предназначенный для конкретного источника данных. UniView запрашивают базы данных, с которыми они связаны, с помощью механизма доступа к данным соответствующей базы данных. Центральный сервер (UniServer) координирует систему и облегчает использование системы с помощью интерфейса (UniViewer). UniViewer позволяет пользователю запрашивать источники данных путем идентификации аспекта отраслевого бизнес-контекста, представителя аспекта и по меньшей мере одного UniView. Чтобы облегчить комплексные запросы, можно объединять, кэшировать и сохранять множество UniView. Хотя настоящее изобретение будет описано со ссылкой на примерный набор баз данных, относящихся к клиническим испытаниям для фармацевтической промышленности, специалистам будет понятно, что изобретение может найти применение в любом типе системы управления базами данных, в которой используется управление множеством неоднородных баз данных, например, для управления неоднородными базами данных, связанными с приложениями для расчета заработной платы или для корпоративных человеческих ресурсов.

На фиг.1 представлен общий вид системы 100 для унификации данных согласно изобретению. В данном варианте система 100 содержит UniBase 110, UniServer 120 и по меньшей мере один источник 130 данных, и может также содержать любой из следующих элементов: блок 140 извещения, UniBuilder 160 и UniViewr 150, или все эти элементы. Система 100 установлена в любом подходящем компьютере, вычислительной системе или взаимосвязанной группе известных вычислительных систем. В одном варианте UniBase 110 и UniServer 120 установлены на центральном сервере. Блок 140 извещения, UniBuilder 160 и UniViewer 150 также могут быть установлены на центральном сервере. Источники 130 данных факультативно находятся на центральном сервере, или в удаленном компьютере, или в удаленной вычислительной системе (не показано). В одном варианте, в котором любой описанный элемент находится в компьютере или вычислительной системе, удаленной от других элементов системы, устанавливается соответствующее электронное соединение, включая, без ограничения перечисленным, сетевое соединение, между удаленными элементами для облегчения связи между ними. Можно использовать любую подходящую сеть или другой способ связи. Система 100 может быть воплощена в любом подходящем языке программирования или комбинации языков программирования, включая системы управления базами данных и SQL (язык структурированных запросов).

Изображенная на фиг.2 система 100 согласно изобретению содержит UniBase 110. UniBase 110 - это база данных, которая хранит и облегчает доступ к UniDimNet 210 и, факультативно, к таблице 220 UniView и кэшированным результатам 230 UniView. UniBase 110 может быть любой подходящей базой данных для хранения данных, реализованной в любой подходящей программе базы данных, включая, без ограничения перечисленным, программное обеспечение базы данных компании Oracle.

Показанная на фиг.3 UniDimNet 210 является базой данных, которая содержит представление всех аспектов отраслевого бизнес-контекста, релевантных для системы 100, и их взаимосвязей. UniDimNet 210 также содержит представление всех аспектов источника данных для всех источников данных, доступных для системы 100, и их взаимосвязей. UniDimNet 210 также содержит соединения (или связи) между представленными аспектами отраслевого бизнес-контекста и представленными аспектами источника данных.

Каждый аспект отраслевого бизнес-контекста, который используется в системе 100, представлен UniDim, полный набор которых для системы 100 представлен показан позицией 310. UniDim - это запись и описание в базе данных UniDimNet 210, которые представляют и определяют уникальный аспект отраслевого бизнес-контекста в системе 100.

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

На фиг.4 представлен примерный полный набор аспектов для примера фармацевтической промышленности. В этом примере полный набор UniDim 310 содержит множество UniDim 410-470, которые определяют отраслевой бизнес-контекст фармацевтической промышленности. Несмотря на то, что в данном примере представлено всего семь UniDim, понятно, что можно определить любое количество подходящих UniDim, и также понятно, что многие системы согласно изобретению могут содержать значительно большее количество UniDim в зависимости от потребности для определения отраслевого бизнес-контекста. В данном примере UniDim 410 представляет аспект "спонсор", UniDim 420 представляет аспект "исследование", UniDim 430 представляет аспект "место", UniDim 440 представляет аспект "пациент", UniDim 450 представляет аспект "пациент на месте", UniDim 460 представляет аспект "визит" и UniDim 470 представляет аспект "запись симптомов".

Каждый UniDim связан по меньшей мере с одним другим UniDim. Как показано на фиг.4, все UniDim данного фармацевтического примера приблизительно иерархически связаны между собой. UniDim 410 (спонсор) может быть связан с одним или более исследований (представленных UniDim 420 - не показанным множеством UniDim 420), каждое исследование может быть связано с одним или более местами (представленными UniDim 430 - не показанным множеством UniDim 430) и каждое место может быть связано с одним или множеством пациентов (представленных UniDim 450 - не показанным множеством UniDim 450). Каждый UniDim 450 (т.е. каждый пациент на месте) может быть связан с одним или множеством UniDim 440 "пациентов" (представляющих информацию о данном пациенте, такую как рост, вес и т.д.), одним или множеством UniDim 470 "записей симптомов" (представляющих записи симптомов пациента) и одним или множеством UniDim 460 "визитов" (представляющих визиты пациента). Как графически показано на фиг.4, некоторые UniDim считаются "более высокими" в этой иерархии, чем другие UniDim. Например, UniDim 410 "выше" в сети UniDim, чем UniDim 430. В одном варианте каждый UniDim в сети рассматривается как одномерный, а информация, касающаяся иерархических взаимосвязей между узлами, распространяет сеть на второй размер.

Возвратимся к UniDimNet 210 на фиг.3: каждый UniDim 380 в полном наборе UniDim 310 отображается или связывается, по меньшей мере, с одним аспектом 390, специфическим для источника данных, содержащимся в полном наборе аспектов, специфических для источника данных (например, 320, 330 и 340), соответствующих конкретному источнику данных (например, на фиг.1 источники данных 172, 174 и 176), доступному для системы 100. Как показано на фиг.1, система 100 обращается к множеству источников данных 130, например, к источникам данных 172, 174 и 176. Несмотря на то, что показано всего три источника данных, понятно, что система 100 согласно изобретению может обращаться к любому количеству источников данных.

Изображенные на фиг.1 и 3 источники данных 172, 174 и 176 могут быть любым подходящим источником данных, содержащим информацию, релевантную для отрасли, к которой осуществляет и/или может осуществлять доступ система 100. На фиг.3 для каждого источника данных, доступного для системы 100, создается полный набор аспектов, специфических для источника данных (например, полный набор 320 для источника данных 172). Полный набор аспектов, специфических для любого источника данных, можно определить с помощью любого подходящего механизма. В одном варианте анализируются внутренняя структура (структуры) данных источника данных и бизнес-информация, представленная этими данными, чтобы определить логические "группы" или ассоциации данных, которые определяют каждый отдельный аспект, специфический для источника данных. В другом варианте анализируется бизнес-контекст каждого набора информации в источнике данных, чтобы дополнительно определить аспекты, специфические для данного источника данных. В еще одном варианте обращаются к аспектам отраслевого бизнес-контекста, содержащимся в системе 100, чтобы определить, можно ли данные в источнике данных концептуально сгруппировать в соответствии с отраслевым бизнес-контекстом. В еще одном варианте (таком как реляционная база данных, проиллюстрированная ниже) внутренняя структура источника данных определяет каждый аспект, специфический для источника данных.

Примерные источники данных и соответствующие аспекты, специфические для источников данных, проиллюстрированы на фиг.5А, 5В и 5С. В этом примерном варианте источник данных 172 (фиг.5А) содержит такой источник данных, как DATATRAK Central Administration ("DATATRAK CA"), примерную базу данных, предоставляемую компанией DATATRAK International, Inc. В DATATRAK CA исходные данные хранятся в специальной таблице, наборе таблиц или в родовой таблице. Полный набор аспектов, специфических для источника данных, зависит от характера информации, хранящейся в этих таблицах, и от типа информации, доступной из системы 100. В одном варианте, в котором информация для доступа системой 100 содержится в специальных таблицах в DATATRAK CA, заранее определенные классы, относящиеся к этим специальным таблицам, определяют аспекты, специфические для источника данных. Эти классы, как и соответствующие аспекты, специфические для источника данных, могут распространяться на весь набор таблиц, чтобы можно было выбирать данные из каждой из них для облегчения группировки бизнес-контекста, что позволяет отделять исходные данные (и таблицы исходных данных) от бизнес-контекста. В одном варианте, в котором информация, к которой должен быть обеспечен доступ для системы 100, содержится в родовых таблицах в DATATRAK CA, аспекты, специфические для источника данных, извлекаются из содержимого специальных полей в исходных данных. Специальные поля группируются на основании бизнес-контекста этих полей. После определения полного набора аспектов, специфических для источника данных 172, и создания его специальных аспектов, специфических для источника данных, полный набор 320 сохраняется в UniDimNet 210.

На фиг.5А примерные аспекты, специфические для примерного источника данных 172 (DATATRAK CA), включают в себя "CA спонсор", "CA исследование" и "CA место". Эти аспекты, специфические для источника данных, относятся к концептуальным группировкам данных в DATATRAK CA, которые относятся, соответственно, к спонсорам в источнике данных, исследованиям в источнике данных и местам в источнике данных. Каждый аспект, специфический для источника данных, который используется в системе 100, представлен в UniDimNet 210 как DataSourceDim, полный набор которых для источника данных 172 представлен позицией 320. DataSourceDim - это запись в базе данных UniDimNet 210, которая представляет уникальный аспект, специфический для источника данных, в системе 100. Аспект "CA спонсор", специфический для источника данных, представлен DataSourceDim 510, аспект "CA исследование", специфический для источника данных, представлен DataSourceDim 512 и аспект "CA место", специфический для источника данных, представлен DataSourceDim 514. Дополнительный DataSourceDim - "Центральный админ" 516 - определен для DATATRAK CA как специальный DataSourceDim, который ссылается на сам источник данных (DATATRAK CA). Каждый DataSourceDim в полном наборе для конкретного источника данных связан со специальным DataSourceDim для этого источника данных.

Также в этом примерном варианте источник данных 174 представляет собой источник данных, который организован для облегчения родовых запросов данных SQL. В такой базе данных SQL (обычно релятивной базе данных) исходные данные базы данных хранятся в таблицах, которые прямо представляют конкретную группировку бизнес-контекстов. При этом аспекты, специфические для источника данных, в такой базе данных можно извлекать прямо из таблиц, в которых хранятся эти данные. Например, база данных может содержать таблицу для "пациента", которая содержит информацию о пациенте. Такая таблица может соответствовать аспекту "пациент", специфическому для источника данных. Альтернативно, можно определить аспекты, специфические для источника данных, которые распространяются на множество таблиц, если данные, выбранные из каждой таблицы, связаны в бизнес-контексте. После определения полного набора аспектов, специфических для источника данных 174, и создания его специальных аспектов, специфических для источника данных, полный набор 330 сохраняется в UniDimNet 210 как репрезентативные DataSourceDim. На фиг.5В примерные DataSourceDim 520, 522 и 524 представляют аспекты, специфические для источника данных: "PD пациент", "PD пациент на месте" и "PD запись симптомов", соответственно. Как и для полного набора 310, для источника данных 172, здесь создается специальный DataSourceDim 526, ссылающийся на источник данных 174, в полном наборе 330 для источника данных 174.

Также в этом примерном варианте источник данных 176 является полностью родовым источником данных, который не рассчитан на включение каких либо специальных таблиц для любых специальных концепций, например, как база данных DATATRAK EDC (DATATRAK EDC), предоставляемая компанией DATATRAK International, Inc. Доступ к такой базе данных осуществляется через интерфейс ИПП (такой как DATATRAK QUESTIONVIEW ®), и она не имеет какой-либо внутренней структуры, которая бы помогла в создании аспектов, специфических для источника данных. В этом случае аспекты, специфические для источника данных, создаются с помощью любого подходящего механизма. В одном варианте аспекты, специфические для источника данных, создаются для такой базы данных путем доступа к метаданным, касающимся данных, хранящихся в этой базе данных, и путем анализа данных, содержащихся в базе данных, в свете отраслевого бизнес-контекста. После определения полного набора аспектов, специфических для источника данных 176, и его специальных аспектов, специфических для источника данных, полный набор 340 сохраняется в UniDimNet 210 в виде репрезентативных DataSourceDim. На фиг.5С примерные DataSourceDim 530, 532 и 534 представляют следующие аспекты, специфические для источника данных: "EDC место", "EDC пациент на месте" и "EDC визит", соответственно. Как и для полного набора 310 для источника данных 172, создается специальный DataSourceDim 536, относящийся к источнику данных 176, в полном наборе 340 для источника данных 176.

Вернемся к фиг.3: после создания полных наборов DataSourceDim (показанных примерными полными наборами 320, 330 и 340) и сохранения их в UniDimNet 210, каждый DataSourceDim отображается или связывается с соответствующим UniDim в полном наборе 310 UniDim. На фиг.6А проиллюстрировано отображение полного набора 350 DataSourceDim в части полного набора 310 UniDim. DataSourceDim 510, который относится к аспекту "CA спонсор", специфическому для источника данных, который сам связан с информацией "CA спонсор", содержащейся в источнике данных DATATRAK CA, связан с UniDim 410 "спонсор", который связан с аспектом "спонсор" отраслевого бизнес-контекста. В этом отношении каждый DataSourceDim, за исключением специального DataSourceDim, относящегося к источнику данных, связан с соответствующим UniDim. UniDim является "соответствующим", если он связан с таким же или подобным аспектом, как аспект, специфический для источника данных. Аналогично DataSourceDim 512 "СА исследование" связан с UniDim 420 "исследование", и DataSourceDim 514 "CA место" связан с UniDim 430 "место".

На фиг.6В и 6С подобное отображение происходит между полными наборами 360 и 370 DataSourceDim и полным набором 310 UniDim, при этом каждый DataSourceDim связан с соответствующим UniDim. На фиг.7 объединены отображенные взаимосвязи, проиллюстрированные на фиг.6А, 6В и 6С. Как видно на чертеже, некоторые UniDim (например, пациент на участке 450) отображены более, чем одним DataSourceDim. Эта ситуация имеет место, когда более одного источника данных содержит информацию, относящуюся к конкретному аспекту отраслевого бизнес-контекста (представленному UniDim).

В одном варианте DataSourceDim является узлом в сети, которая определяет UniDimNet 210, подобно каждому узлу, определенному каждым UniDim. Путем отображения каждого узла DataSourceDim на двухмерной сети UniDimNet, определенной множеством UniDim и их взаимосвязями друг с другом, сеть UniDimNet распространяется на три аспекта. В данном контексте UniDimNet 210 является трехмерной сетью узлов, хранимых как связанные данные в UniBase 110.

В другом варианте UniDimNet 210 представляет собой ряд взаимосвязанных таблиц, причем каждый узел в UniDimNet 210 представлен таблицей. Каждый UniDim и каждый DataSourceDim в UniDimNet 210 представлены таблицей. Каждый представитель аспекта в источнике данных, доступном для системы 100, представлен строкой по меньшей мере в одном UniDim в UniDimNet 210 и по меньшей мере в одном DataSourceDim в UniDimNet 210. Например, на фиг.8 представитель 800 аспекта в источнике данных 176 (DATATRAK EDC) является конкретным местом в исследовании, из которого захватывает данные DATATRAK EDC (т.е. представитель 800 аспекта является представителем аспекта 430 "место" отраслевого бизнес-контекста). Представитель 800 аспекта представлен в таблице 860 для DataSourceDim 530 ("EDC место") строкой 862 и в таблице 850 для UniDim 430 ("место") строкой 852.

Каждая таблица UniDim содержит запись (например, строку в таблице) для каждого представителя аспекта, представленного UniDim, который содержится в источнике данных, доступном для системы 100. Каждая запись (например, строка 852) в таблице UniDim содержит глобально уникальную идентификацию 853, которая уникальным образом идентифицирует представителя аспекта, представленного данной записью. Каждая запись может также содержать метку 854 времени создания и метку 855 времени обновления для каждой записи, которые представляют время, когда данный представитель аспекта был введен в систему 100 и когда он был последний раз обновлен, соответственно. Каждая запись может также содержать дополнительную информацию (например, дополнительные поля записи), касающуюся каждого представителя аспекта в таблице. Можно добавить любую подходящую информацию. Например, можно добавить поле 856, идентифицирующее DataSourceDim, относящийся к представителю аспекта. Понятно, что объем информации, содержащейся в каждой записи UniDim, зависит от времени отклика, желательного для системы 100, и от пространства памяти, предоставленного для UniBase. Обычно, чем больше информации содержится в каждой записи UniDim, чем меньше просмотров источника данных нужно выполнить системе 100 (потому что большой объем информации, касающейся представителя аспекта, будет уже сохранен в записи UniDim), следовательно, это увеличивает быстродействие системы в целом. Однако такая дополнительная информация использует дополнительное пространство памяти, а это может повысить стоимость системы и в зависимости от программного обеспечения, управляющего базой данных, используемого для хранения UniDimNet, может замедлить работу систему, если размер таблиц UniDim станет слишком большим.

Подобно таблицам UniDim, каждая таблица DataSourceDim содержит запись для каждого представителя аспекта, представленного DataSourceDim, который содержится в источнике данных, связанном с DataSourceDim. Каждая запись (например, строка 862) в таблице DataSourceDim содержит ссылку 864 на источник данных, в котором содержится представитель аспекта, ключевую информацию 863 (такую как идентификатор, уникальный для источника данных), необходимую для извлечения представителя аспекта (и связанных с ним данных) из источника данных, и уникальный идентификатор 853 для представителя аспекта, содержащегося в записи UniDim, связанной с данным представителем аспекта. Каждая запись может также содержать метку 854 времени создания и метку 85 времени обновления, подобно связанной с ней записи UniDim. Как и в случае записей UniDim, записи в таблице DataSourceDim могут содержать дополнительную информацию, связанную с конкретным представителем аспекта, и могут также содержать дополнительную информацию, связанную с источником данных и UniDim, с которым связан данный DataSourceDim. Понятно, что те же самые факторы, относящиеся к скорости и размеру, которые диктуют объем информации, содержащейся в записи UniDim, применимы также и к определению объема информации, содержащейся в записи DataSourceDim.

Возвратимся снова к представителю 800 аспекта: запись, связанная с представителем 800 аспекта, содержится в таблице DataSourceDim 860 (запись 862) и таблице UniDim 850 (запись 852). Эти записи связаны друг с другом с помощью любого подходящего механизма. В одном варианте эта связь содержится в DataSourceDim, идентифицирующем поле 856 записи UniDim. В другом варианте эта связь дополнительно определяется каждой записью, содержащей тот же самый идентификатор 853, уникальный для UniDim.

Таблицу UniDim можно связать с более чем одной таблицей DataSourceDim. Как показано также на фиг.8, таблица UniDim 850 также связана с таблицей DataSourceDim 870, представляющей DataSourceDim 514 ("CA место"), которая связана с источником данных 172 (DATATRAK CA). Например, представитель 880 аспекта в источнике данных 172 (DATATRAK CA) является конкретным местом в исследовании, из которого данные сохраняются в DATATRAK CA (т.е. представитель 800 аспекта является представителем аспекта 430 "место" отраслевого бизнес-контекста). Представитель 800 аспекта представлен в таблице 870 для DataSourceDim 514 ("CA место") строкой 872 и в таблице 850 для UniDim 430 ("Место") строкой 858. Понятно, что в этом примере таблица UniDim 850 содержит записи, которые относятся к двум разным таблицам DataSourceDim (и затем к двум разным источникам данных). Таблица UniDim 850 может содержать записи, которые связаны с любым количеством таблиц DataSourceDim, если представитель аспекта (с которым связан DataSourceDim) связан с UniDim (с которым связана таблица UniDim). Кроме того, таблица UniDim может содержать множество записей, которые связаны с множеством записей в одной таблице DataSourceDim (т.е. представляющей множество представителей аспекта в одном источнике данных). В этом случае запись для каждого представителя аспекта будет храниться как в таблицах DataSourceDim, так и в таблицах UniDim, относящихся к данному представителю аспекта.

Также со ссылкой на фиг.8 понятно, что каждая таблица DataSourceDim может также содержать запись (например, 890 для таблицы 860 и 892 для таблицы 870), относящуюся к источнику данных как таковому. Такая запись относится к специальному DataSourceDim (например, на фиг.5 к DataSourceDim 516 ("DATATRAK CA")), который содержит информацию, относящуюся к конкретному источнику данных. Такая запись может содержать информацию, подобную другим записям в базе данных, и факультативно может содержать дополнительную информацию, относящуюся к источнику данных (например, информацию, относящуюся к механизму доступа к источнику данных, или, в общем, информацию о соединении, относящуюся к источнику данных). Каждый источник данных, который связан с DataSourceDim, имеет специальную запись в DataSourceDim, которая связана с ним самим. Таким образом, каждый узел DataSourceDim содержит информацию для всех реальных источников данных соответствующего типа.

В одном варианте каждый представитель аспекта, содержащийся во всех источниках данных, доступных для системы 100, имеет соответствующую запись по меньшей мере в одной таблице UniDim и по меньшей мере в одной таблице DataSourceDim. Таким образом, UniDimNet 210 облегчает запрос аспектов и представителей аспектов, распространяющихся на все источники данных, независимо от физической и логической структуры каждого источника данных. Такие запросы (касающиеся аспектов или представителей аспектов, а не конкретного источника данных или специфических записей в каждом источнике данных) можно осуществлять с помощью шаблонов, или UniView.

UniView представляет собой логику (например, программный компонент, подпрограмму или объект), которая осуществляет действительный запрос данных в источнике данных в системе 100. UniView - это специальный вопрос относительно конкретного аспекта, предназначенного для специального источника данных. На фиг.8 примерный UniView 900 осуществляет связь с механизмом 910 доступа к данным для облегчения доступа и запроса к источнику данных (в данном случае к примерному источнику данных 172). В одном варианте UniView имеет форму вызова функции:

результат=точный_запрос_информации (параметр_представителя),

где "результат" - это запрошенная информация, которая возвращается из источника данных в ответ на запрос; "точный_запрос_информации" - это специфический запрос к источнику данных на специфическую информацию, и "параметр_представителя" - это специфический представитель аспекта, к которому относится данный запрос. Например, UniView, запрашивающий рост пациента Джо Смита, определит "результат" как поле, содержащее значение роста Джо Смита, и может иметь следующую форму:

результат=каков рост пациента (пациент="Джо Смит").

После успешного запроса к соответствующему источнику данных примерный UniView возвратит значение роста Джо Смита, как оно записано в источнике данных.

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

Каждый UniView создается для конкретного источника данных. В одном варианте после внедрения источника данных в систему 100 в ней создается множество UniView для осуществления запросов к этому новому источнику данных. Каждый UniView содержит необходимую информацию и команды для облегчения доступа к источнику данных с помощью механизма доступа к данным для данного конкретного источника данных. Например, доступ к примерным источникам данных DATATRAK EDC и DATATRAK CA возможен через ИПП DATATRAK QUESTIONVIEW API. UniView для любого из этих источников данных будет создан с возможностью доступа и использования DATATRAK QUESTIONVIEW API для осуществления запроса каждой базы данных. Этот UniView будет содержать требуемые параметры, команды и информацию, необходимые для того, чтобы дать указание ИПП запросить базы данных и возвратить определенные результаты (в формате "результатов"). В этом смысле UniDimNet 210 лишена конкретных деталей структуры и физических требований каждого источника данных. UniView принимает запрос, специфический для аспекта, и облегчает доступ к источнику данных для ответа на запрос. Хотя в приведенном выше примере проиллюстрировано использование ИПП как механизма доступа к источнику данных, понятно, что можно использовать любой механизм доступа, который способен осуществлять запрос к источнику данных.

Следует понимать, что количество и величина UniView, которые создаются для каждого конкретного источника данных, зависят от количества и типа представителей аспектов в источнике данных и желания пользователя запрашивать источник данных. В системе 100 можно создавать и использовать любое подходящее количество UniView для конкретного источника данных. Понятно, что многочисленные UniView будут создаваться в зависимости от наличия в источнике данных большого объема данных, представляющих множество представителей. UniView могут храниться в любом подходящем элементе (или базе данных) системы 100, например, в UniBase 110. В одном варианте UniView (или "определения" UniView) хранятся в определении базы данных UniView 220 UniBase 110 (см. фиг.2). В другом варианте множество UniView хранится в дереве UniView Tree 1210 элемента UniBuilder 160 (см. фиг.1 и 12). Дерево UniView Tree 1210 может содержать перечень всех UniView, созданных для системы 100. Этот перечень можно организовать любым подходящим способом для облегчения поиска UniView системы и доступа к ним. В одном варианте UniView в UniView Tree 2010 тематически организованы по аспектам. В другом варианте UniView организованы сначала по источнику данных, а затем по аспектам. В еще одном варианте UniView организованы иерархически. UniBuilder 160 может использовать логику 1220 управления UniView Tree для облегчения управления UniView Tree. Логика 1220 управления UniView Tree содержит любые подходящие операции, способы и/или процессы для облегчения управления деревом UniView Tree 1210, включая, без ограничения перечисленным, логику для добавления UniView к дереву UniView Tree, удаления UniView из дерева, реорганизации дерева, поиска по дереву, структурирования дерева и иного облегчения изменений дерева. Как будет обсуждаться ниже, дерево UniView Tree 1210 может также содержать интерфейсы UniViewInterface и CompoundView. Хотя дерево UniView Tree 1210 было описано как облегчающее организацию UniView системы 100, понятно, что сами UniView можно хранить в дереве UniView Tree 1210, или же альтернативно их можно хранить в другом месте (или базе данных), идентифицировав только ключи, связанные с каждым UniView, организованным в дереве UniView Tree 1210.

Система 100 может содержать дополнительные функции, способствующие управлению, использованию и созданию UniView, включая, без ограничения перечисленным, использование интерфейса UniViewInterface, использование CompoundUniView, кэширование UniView и создание UniView с помощью автоматизированного процесса, например, UniBot. Интерфейсы UniViewInterface проиллюстрированы со ссылкой на фиг.10.

Интерфейс UniViewInterface представляет собой механизм для объединения множества UniView, чтобы облегчить запросы, которые требуют использования множества UniView. UniViewInterface имеет, в основном, такую же форму как UniView (т.е. вызова функции), в которой один интерфейс UniViewinterface вызывает множество UniView. Однако обычно "результат" интерфейса UniViewInterface представляет собой набор результатов, содержание которого является совокупностью (или массивом, или таблицей) найденных данных, которые соответствуют множеству представителей аспектов, найденных множеством UniView, которые вызываются интерфейсом UniViewInterface. Кроме того, "точный_за-прос_информации" в интерфейсе UniViewInterface не является специфическим для источника данных, как в UniView. Вместо этого "точный_запрос_информации" относится только к запрашиваемой информации (например, из аспекта), независимо от источника данных. Также "параметр_представителя" является массивом представителей аспекта, а не одним представителем аспекта. Массив представителей аспекта определяется набором представителей аспекта, которые желательно запросить.

Использование интерфейса UniViewInterface проиллюстрировано со ссылкой на фиг.10. В примере на фиг.10 показано три отдельных источника данных ("Исследование DB" 1040, "EDC исследование I DB" 1042 и "EDC исследование II DB" 1044), каждый из которых имеет различные физические и логические структуры и применяет различные механизмы доступа, и каждый содержит информацию, относящуюся к аспекту "характеристика пациента" (такую как возраст, рост, вес и т.п. участников каждого исследования). UniView можно использовать для отдельного запроса каждой базы данных для одного представителя аспекта. Когда в одном источнике данных имеется множество представителей аспекта, нужно использовать множество UniView для доступа к каждому представителю. Пользователю будет сложно реализовать то количество UniView, которое необходимо для полного запроса ко всем трем источникам данных, так как это будет занимать много времени. Интерфейс UniViewInterface 1010 облегчает запрос с множеством UniView в одном пользовательском запросе.

Интерфейс UniViewInterface 1010 создается с "результатом" в виде совокупности, предназначенной для содержания информации характеристики пациента, для множества пациентов. "Результатом" запроса UniViewInterface 1010 будет совокупность данных характеристик пациентов, в которой каждый пациент является записью в "результате". "Точный_запрос_информации" - это запрос аспекта "пациент" 440 (см. фиг.4) для характеристики пациента (без указания конкретного источника данных). "Параметры представителя" представляют собой массив имен пациентов или других пригодных идентификаторов пациентов. Если пользователь желает получать характеристики пациента 123 1000 (из Исследования), пациента abc 1002 (из EDC I) и пациента xyz 1004 (из EDC II), он передает идентификаторы (например, имена) пациента 123, пациента abc и пациента xyz в UniViewInterface 1010 как значения массива "параметры представителя" (т.е. пациенты-объекты запроса передаются в UniViewInterface). Следует отметить, что пользователь не должен передавать идентификатор источника данных каждого пациента для UniViewInterface. После получения значений в массиве "параметры представителя" UniViewInterface 1010 запрашивает у UniDimNet 210 UniDim, который соответствует аспекту "пациент" (UniViewInterface закодирован для поиска этого аспекта, как UniViewInterface 1010 закодирован для "характеристик пациента"), на основании или для уникальной идентификации каждого представителя аспекта в массиве. Когда UniViewInterface 1010 получает эту информацию для каждого представителя аспекта, UniViewInterface 1010 запрашивает DataSourceDim, связанный с каждым представителем аспекта (следует отметить, что если представитель найден в UniDim, то связь для соответствующего DataSourceDim уже существует), чтобы определить соответствующий источник данных, связанный с каждым представителем аспекта. При наличии этой информации UniViewInterface 1010 вызывает множество UniView. Каждому вызванному UniView передается один "параметр_представителя" как один представитель из массива "параметр_представителя" UniViewInterface 1010, и UniView, которому передается этот один представитель, выбирается по характеру UniViewInterface (т.е. это UniView для "характеристики пациента", также как и UniViewInterface) и идентификатору связанного с ним источника данных. В данном примере UniViewInterface 1010 при этом вызывает UniView 1020, 1022 и 1024, соответственно, для пациента 123, пациента abc и пациента xyz. UniView 1020 осуществляет доступ к источнику данных 1040 через механизм 1030 доступа, UniView 1022 осуществляет доступ к источнику данных 1042 через механизм 1032 доступа (например, DATATRAK QUESTIONVIEW API) и UniView 1024 осуществляет доступ к источнику данных 1044 через механизм 1034 доступа. Полученная совокупность данных характеристики пациентов возвращается пользователю в ответ на запрос UniViewInterface. В одном варианте разработанные UniViewInterface системы 100 сохраняются и/или организуются в дерево UniView Tree 1210. UniViewInterface являются примерами комплексных запросов.

На фиг.11 CompoundUniView является механизмом для сохранения ряда (или комбинации) UniView в целях их дальнейшего использования. Пользователь может пожелать создать комплексный запрос, в котором используется множество UniViews, охватывающих множество аспектов и множество источников данных. Такой комплексный запрос (содержащий множество UniView) после его создания можно сохранить как CompoundUniView и использовать впоследствии с различными введенными параметрами представителя. В примере на фиг.11 пользователь желает сделать запрос о "качестве жизни" по всем источникам данных для конкретного пациента. Пользователь определяет запрос "качество жизни" как включающий в себя "журнал записей состояния желудка пациента" и "журнал записей уровня боли пациента" из журнала записей 1140 пациента в источнике данных, "EDC при приеме лекарств" из источника данных 1142 и "истории лечения пациента" из источника данных 1144. Пользователь объединяет четыре UniView для создания этого комплексного запроса. Пользователь выбирает UniView 1120 и 1122 для использования механизма 1130 доступа для запроса источника данных 1140, UniView 1124 для использования механизма 1132 доступа для запроса источника данных 1142 и UniView 1126 для использования механизма 1134 доступа для запроса источника данных 1144. Этот комплексный запрос сохраняется как CompoundUniView "Качество жизни" 1110. Когда следующий пользователь пожелает сделать запрос у системы 100 о "Качестве жизни" конкретного пациента, ему нужно будет только выбрать CompoundUniView "Качество жизни" 1110 и передать ему желаемое значение параметра_представителя (например, "пациент 123" 1100). Compound UniView 1110 собирает UniView 1120, 1122, 1124 и 1126, передает каждому из них "параметр_представителя", получает "результат" от каждого и возвращает как результат объединенную информацию, возвращенную каждым UniView. В этом смысле единственными входными параметрами, которые должен ввести пользователь (т.е. данные, предоставляемыми пользователем для определения запроса или объема запроса) для CompoundUniView, является идентификатор CompoundUniView (т.е. описание данных, подлежащих запросу, например, "вес пациента") и идентификатор запрашиваемого представителя (представителей) аспекта. Пользователь может также ввести параметр, касающийся желаемого результата (т.е. формата возвращенных данных). В одном варианте разработанные CompoundUniView системы 100 сохраняются и/или организуются в дерево UniView Tree 1210. CompoundUniView являются примерами комплексных запросов.

Кэширование UniView является механизмом ускорения отклика системы 100 за счет кэширования результатов выполненных UniView. При последующих выполнениях таких UniView кэшированные результаты анализируются, чтобы определить, произошло ли обновление соответствующего источника данных после времени кэширования. Обычно, если обновления не произошло, можно возвратить кэшированные результаты для исполнения UniView, сэкономив таким образом время и системные ресурсы, необходимые для доступа к источнику данных, непосредственно в ответ на UniView. Если обновление произошло, то кэш игнорируется, UniView запрашивает источник данных, и ответ на запрос кэшируется сверху старых кэшированных данных.

Для облегчения такого кэширования в одном варианте система 100 создает таблицу кэш-результатов для каждого UniView системы 100. Кэшированные результаты можно сохранять в любом подходящем месте в системе 100. В одном варианте (см. фиг.2) UniBase 110 имеет базу данных 230 для кэшированных результатов UniView. Эта база данных 230 для кэшированных результатов UniView может быть любой подходящей базой данных с любой подходящей организацией для хранения кэшированных результатов из запросов UniView. В одном варианте база данных 230 содержит множество таблиц, каждая из которых связана с конкретным UniView системы 100. Каждая таблица содержит данные "результата" из самого последнего запроса, выполненного UniView, связанным с таблицей. В одном варианте к каждому представителю кэширования в таблице прилагается метка времени, которая указывает дату и время, когда были кэшированы эти данные. Ниже будет описано использование примерной системы кэширования UniView. В одном варианте создание таблиц кэшированных результатов облегчается логикой 1250 таблицы UniView (см. фиг.12) элемента UniBuilder 160 (который будет более подробно описан ниже при обсуждении создания UniView). Логика 1250 таблицы UniView содержит любые подходящие операции, процессы, способы и/или программный код для облегчения создания, доступа и управления таблицами кэшированных результатов.

Создание UniView можно обеспечить с помощью любых подходящих механизмов, включая ручной механизм (т.е. когда один UniView кодируется пользователем). В одном варианте система 100 обеспечивает инструменты для помощи в создании UniView. На фиг.12 UniBuilder 160 содержит логику 1230 класса источника данных и UniBot 1240.

В одном варианте логика 1230 класса источника данных помогает в создании UniView. После того, как система 100 получит доступ, определяется класс источника данных, который содержит необходимую информацию, операции, процессы и механизмы доступа для запроса источника данных этого класса. Класс источника данных содержит информацию, необходимую для UniView, чтобы создать элемент "точный_запрос_информации" UniView, (т.е. специальную информацию, необходимую UniView для облегчения запроса к источнику данных через соответствующий механизм доступа к данным). Эта информация форматируется, чтобы облегчить использование в UniView, направленном на запрос источника данных этого класса. Таким образом, когда желательно создать UniView, который запрашивает источник данных этого класса, автор UniView может "перенести" или "скопировать" сформатированную информацию о классе данных в UniView, сэкономив тем самым время на повторное создание того же самого кода для каждого такого UniView. Чтобы облегчить создание класса источника данных (см. фиг.1), UniBuilder 160 принимает информацию об источнике (источниках) данных из источника данных 130. Логика 1230 класса источника данных включает в себя любые подходящие операции, способы, процессы и/или код для облегчения создания класса источника данных, форматирования класса источника данных, сохранения класса источника данных, доступа к классу источника данных и переноса класса источника данных в UniView. Информацию о классе источника данных можно хранить в любом подходящем месте системы 100.

В одном варианте UniBot 1240 облегчает создание набора "стандартных" UniView для источника данных. UniBot 1240 включает в себя любые подходящие операции, способы, процессы и/или код для облегчения такого создания. UniBot 1240 можно автоматизировать. На основании пользовательского ввода относительно того, что включает в себя "стандартный" набор UniView (т.е. сколько надо UniView для источника данных такого класса, какие аспекты следует запрашивать, какие данные обычно запрашиваются из источника данных такого класса, и т.д.), UniBot 1240 осуществляет доступ к соответствующему источнику (источникам) данных и определяет информацию, необходимую для создания стандартного набора UniView. В одном варианте UniBot 1240 осуществляет доступ к соответствующим источникам данных и определяет информацию, необходимую для создания DataSourceDim для источника данных для внедрения в UniDimNet. В одном варианте UniBot 1240 извлекает такую информацию и создает набор UniView согласно спецификациям, определенным пользователем.

Как показано на фиг.1 координацию между UniBase 110, UniBuilder 160, источниками данных 130 и другими элементами системы 100 (которые будут обсуждаться ниже) осуществляет UniServer 120. На фиг.13 UniServer 120 факультативно содержит логику 1300 управления UniDimNet, логику 1305 управления источником данных, логику 1310 маршрутизации соединений, логику 1320 сложного UniView, логику 1325 управления кадрами экрана и версиями и логику 1330 для облегчения доступа к внешним данным. Понятно, что UniServer 120 может факультативно содержать дополнительные элементы, необходимые для облегчения работы системы 100.

В одном варианте логика 1300 управления UniDimNet облегчает управление UniDimNet. Логика 1300 управления UniDimNet содержит любые операции, процессы, способы и/или программный код для облегчения добавления, обновления и удаления UniDim и DataSourceDim из UniDimNet, распространения структуры UniDimNet на UniBase и другие действия, связанные с UniDimNet, если их не выполняют другие элементы системы 100. В одном варианте логика 1305 управления источником данных облегчает управление источниками данных, доступными для системы 100. Логика 1305 управления источником данных содержит любые операции, процессы, способы или программный код для облегчения управления источниками данных и взаимосвязями (включая взаимодействия) с аспектами. В другом варианте логика 1310 маршрутизации соединений управляет соединениями между элементами системы 100. Логика 1310 маршрутизации соединений содержит любые операции, процессы, способы или/или программный код для облегчения маршрутизации соединений (включая коммуникации) между элементами системы 100, включая, без ограничения перечисленным, UniBase, источники данных и любого пользователя (пользователей).

В еще одном варианте UniServer 120 факультативно содержит логику 1315 запроса UniView для координации действий системы 100 и взаимодействия во время исполнения UniView. Логика 1315 запроса UniView включает в себя любые операции, процессы, способы и/или программный код для облегчения координации ресурсов системы 100 во время исполнения UniView. В одном варианте логика 1315 запроса UniView сконфигурирована с возможностью реализации одной или более из следующих конфигураций выполнения UniView: (1) "Показывать только данные на основе источника". При такой конфигурации (показанной для примера на фиг.14), UniView сначала проверяет связанную с ним таблицу, чтобы определить, есть ли уже кэшированные данные в таблице (этап 1400). Если кэшированных данных нет, то UniView запрашивает соответствующий источник данных и возвращает результат из него (этап 1410). Полученные данные кэшируются (этап 1420) и для этого кэша устанавливается метка времени. Если данные уже были кэшированы, то метка времени кэшированных данных сравнивается с меткой времени соответствующего DataSourceDim (этап 1440). Если метка времени DataSourceDim более поздняя, чем кэшированная метка времени, то этот кэш игнорируется (этап 1450), и UniView запрашивает источник данных (этап 1410). Альтернативно, кэшированные данные извлекаются (этап 1460) и запрос к источнику данных не требуется. (2) "Принимать всегда из источника данных". При такой конфигурации UniView всегда запрашивает результат у источника данных и не проверяет связанную с ним таблицу на наличие кэшированных данных. (3) "Показывать только данные UniBase". Эта конфигурация является противоположной конфигурации "Принимать всегда из источника данных". В ней UniView всегда использует кэшированные данные в таблице, даже если они устарели. При такой конфигурации UniView не запрашивает источник данных. (4) "Показывать нестабильные данные". В такой конфигурации UniView сначала проверяет связанную с ним таблицу на наличие кэшированных данных. Если кэшированные данные существуют, он возвращает их как результат, даже если они устарели. UniView будет продолжать обработку в фоновом режиме, аналогично процессу, описанному для конфигурации "Показывать только данные на основе источника", и будет пересматривать возвращенный результат с данными из источника данных, если кэшированные данные устарели. Если при первичной проверке таблицы в ней не обнаружено кэшированных данных, то UniView будет продолжать свою фоновую обработку (т.е. будет запрашивать источник данных). (5) "Поведение по умолчанию". В этой конфигурации UniView сам содержит код, указывающий, как следует обработать запрос. В этом случае логика 1315 запроса UniView выполняет операции, содержащиеся в UniView. Хотя были описаны некоторые альтернативные конфигурации для логики 1315 запроса UniView, следует понимать, что можно использовать любую подходящую конфигурацию для логики 1315 запроса UniView.

В одном варианте логика 1320 сложного UniView облегчает обработку CompoundUniView. Логика сложного UniView 1320 включает в себя любые операции, процессы, способы и/или программный код для облегчения обработки (выполнения) CompoundUniView. В частности, логика 1320 сложного UniView управляет исполнением CompoundUniView и также действует для него в качестве виртуального источника данных. Для каждого UniView, который вызывается CompoundUniView, логика 1320 сложного UniView выполняет поиск в табличном кэше и (в зависимости от природы кэшированных данных, если таковые имеются) запрос источника данных аналогично операциям, описанным выше для ShowSourceBasedDataOnly. Хотя логика 1320 сложного UniView была описана в связи с конфигурацией "Показывать только данные на основе источника", следует понимать, что логику 1320 сложного UniView можно реализовать для любой пригодной конфигурации.

В одном варианте логика 1325 управления кадрами экрана и версиями обеспечивает сохранение "снимков экрана" результатов запроса UniView и облегчает маркировку таких снимков идентификаторами версии. Логика 1325 управления кадрами экрана и версиями содержит любые операции, процессы, способы и/или программный код для облегчения создания кадров экрана и версий результатов запроса UniView. Когда возвращается результат запроса UniView, он факультативно сохраняется в таблице, соответствующей UniView, в UniBase. В одной факультативной конфигурации UniServer эти кэшированные данные затираются в следующий раз, когда тот же самый UniView возвращает обновленный результат из запроса. Логика 1325 управления кадрами экрана и версиями факультативно позволяет любым кэшированным данным оставаться в таблице. В одном варианте конкретный кэшированный результат сохраняется как запись (например, строка) в кэш-таблице. Логика 1325 управления кадрами экрана и версиями облегчает сохранение последующих возвращенных результатов в виде дополнительной строки (строк) в кэш-таблице. Кроме того, такие кэшированные результаты можно пометить идентификаторами версии для облегчения сравнений версий. В этом отношении множество "снимков экрана" (т.е. возвращенных ранее результатов из предыдущих исполнений UniView) сохраняется в кэш-таблице и могут сравниваться друг с другом (например, для сравнения версий).

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

Представители аспектов в источниках данных редко бывают статичными. Чтобы внести изменения, введенные в представителя аспекта в источнике данных, система 100 факультативно содержит (см. фиг.1) блок 140 извещения, который осуществлять связь с UniServer 120 относительно изменений, которые произошли с представителями аспектов в источниках данных 130. Как видно на фиг.15, блок 140 извещения факультативно содержит книгу 1500 правил и логику 1510 процесса изменения. Книга 1500 правил представляет собой базу данных, которая содержит правила, связанные с каждым источником данных, который доступен для системы 100. Для каждого источника данных соответствующие правила определяют необходимые операции, которые должна выполнить система, чтобы внести изменение в представителя аспекта (например, добавление, удаление или изменение) в системе (например, в UniDimNet). Правило (правила) для любого источника данных являются правилами, подходящими для облегчения интеграции изменения представителя аспекта в системе 100. В одном варианте эти правила определяют минимальную необходимую информацию, которую требуется извлечь из представителя аспекта и передать в систему 100 для интеграции. Обычно такая информация извлекается из источника данных 130 блоком 140 извещения и передается в UniServer 120 для ассимиляции в системе 100. Правила для источника данных могут быть сколь угодно сложными комплексами, начиная от минимальных (например, выбор уникального идентификатора представителя аспекта) до очень сложных (например, использования каскадного набора запросов для автоматического заполнения полной иерархии аспектов для источника данных). Кроме того, эти правила могут указывать, чтобы любые метки времени в системе 100 для представителя аспекта должны обновляться после изменения.

Логика 1510 процесса изменения факультативно облегчает запуск блока 140 извещения и обращение к книгам 1500 правил. Логика 1510 процесса изменения содержит любые операции, процессы, способы и/или программный код для облегчения запуска блока 140 извещения и обращения к книгам 1500 правил. Любое изменение в представителе аспекта можно считать "запускающим событием", которое запускает блок 140 извещения и конкретно логику 1510 процесса изменения. Понятно, что запускающее событие может включать в себя, без ограничения перечисленным, создание представителя аспекта, удаление представителя аспекта или любое изменение свойства представителя аспекта, включая значение любых данных в ней. После возникновения запускающего события запускается логика 1510 процесса изменения. Логика 1510 процесса изменения осуществляет доступ к книгам 1500 правил, чтобы определить, какие технологические операции необходимо реализовать, чтобы ассимилировать измененный представитель аспекта в систему 100. Логика 1510 процесса изменения выполняет и/или облегчает выполнение всех операций, перечисленных в книге правил, чтобы внедрить измененного представителя в систему 100. Хотя логика 1510 процесса изменения была проиллюстрирована как элемент системы 100 вне UniServer 120, понятно, что логику 1510 процесса изменения (и весь блок 140 извещения) можно факультативно включить в состав UniServer 120.

Доступ пользователя к системе 100 и ее использование можно обеспечить с помощью любого подходящего пользовательского интерфейса. В одном варианте, изображенном на фиг.1, система 100 дополнительно содержит UniViewer 150. UniViewer 150 облегчает доступ пользователя к системе 100. В частности, UniViewer 150 позволяет пользователям формулировать запросы к системе 100 путем объединения множества UniView, аспектов и представителей аспектов для формирования простых или комплексных запросов. Обычно UniViewer 150 представляет собой графическую среду, в которой запросы создаются путем перетаскивания компонентов запроса (аспекта (аспектов) и UniView) в область "результата", и результаты отображаются в области результата путем выбора конкретных представителей аспекта.

На фиг.16-19 проиллюстрирован примерный UniViewer 150. После запуска пользователем UniViewer 150, пользователь сначала определяет, работать ли ему с существующим запросом или начать новый запрос. Если выбирается существующий запрос, то этот запрос (и результаты, если таковые имеются) извлекается и отображается графическим пользовательским интерфейсом (ГПИ). Если же требуется новый запрос, то пользователь выбирает по меньшей мере один аспект отраслевого бизнес-контекста, с которого следует начать запрос.

На фиг.16 изображен примерный ГПИ. Отображены выбранный пользователем аспект "место" 1610 и все UniView 1620, имеющиеся в наличии для запроса аспекта "место". В этом примере UniView 1620: "EDC Пространство имен", "Исследование" и "CDF Определение" являются группами UniView (как показано знаком + слева от каждого идентификатора), а остальные идентификаторы относятся к отдельным UniView. После выбора пользователем по меньшей мере одного аспекта в начале этого сеанса UniViewer 150 отображает (1630) каждого представителя аспекта, который содержится в UniDim, относящемся к выбранному аспекту. Можно использовать любой подходящий процесс для поиска таких представителей. В одном варианте UniServer осуществляет доступ к уникальным идентификаторам для каждого представителя, перечисленного в UniDim для выбранного аспекта. После нахождения уникальных идентификаторов UniServer может извлечь представителей аспекта и отобразить их в 1630. Также отображается область 1640 результата (в данный момент свободная).

На фиг.17 пользователь выбирает любое количество UniView, с помощью которых следует запрашивать источник (источники) данных. На фиг.17 пользователь выбрал следующие UniView: "Описание", "AdminID" и "NaSpId", которые он перетащил в область 1640 результатов. После получения каждого UniView область 1640 результатов создает столбец для ожидаемого "результата" данного UniView. На фиг.17 область 1640 результатов отображает столбец 1710 описания для результата UniView "Описание", столбец "AdminID" 1720 для результата UniView "AdminID" и столбец "NaSpID" 1730 для результата UniView "NaSpId". Следует отметить, что перетаскивание множества UniView в область 1640 результатов является примером комплексного запроса.

После того, как пользователь определил запрос путем выбора UniView (см. фиг.18), он может выбрать одного или более представителей 1630 аспекта для передачи запросов в область 1640 результатов (следует отметить, что передача более чем одного представителя аспекта является примером комплексного запроса). На фиг.18 пользователь выбрал представителя "Stadt Klinik Bonn". После выбора этого представителя UniViewer 150 передает его в UniServer. UniServer облегчает исполнение данного запроса. Результат каждого запроса UniView после возврата результатов отображается (1810) в области 1640 результата (т.е. результатом UniView "Описание" является "Krhs", результатом UniView "AdminID" является "11" и результатом UniView "NaSpID" является "S".

Хотя приведенный выше пример был проиллюстрирован с несколькими UniView, которые представляют свойства выбранного аспекта (например, каждый из трех выбранных UniView возвратил свойства выбранного аспекта "место"), понятно, что выбираемые UniView (1610) могут иметь множество путей связи с выбранным аспектом. Например, на фиг.19 выбирается специфический для исследования UniView (по сравнению со специфическим для места UniView). Выбранный специфический для исследования UniView 1920 "Дата визита" объединяется с аспектом, который находится ниже в иерархии UniDimNet, чем "место". Выбранный UniView, как таковой, можно сконфигурировать для извлечения его данных различными способами (потому что в иерархической UniDimNet "более высокий" UniDim "место" может быть связан с одним или множеством "более низких" UniDim "дата визита"). Например, пользователь может выбрать запрос дат конкретного визита (например, "визита 2") или множества визитов, которые показаны в столбцах или строках в области 1640 результатов. В одном варианте такие различные пути пользователь может выбрать щелчком правой кнопки мыши на выбранном UniView и выбором требуемого "пути" из меню возможных "путей".

Как показано на фиг.19, в этом примере пользователь выбрал запрос дат визита для конкретного визита ("визит 2"). Область 1640 результатов расширена, чтобы включить в себя столбец "дата_визита_2" 1910, который содержит результаты, возвращенные UniView, как описывалось выше. Понятно, что можно добавить дополнительные UniView в UniViewer, удалить или изменить, чтобы интерактивно запрашивать источники данных с различными комплексными запросами.

Хотя UniViewer 150 был описан со ссылкой на ГПИ, созданный системой 100, следует понимать, что система 100 может реализовать любые подходящие операции, способы или логику для обеспечения ГПИ UniViewer 150 и результатов любого пользовательского запроса, сделанного с его помощью. В одном варианте, когда система 100 работает, UniDimNet загружается в память (например, ОЗУ). Когда пользователь вначале выбирает контрольный (стартовый) аспект для нового запроса, создается объект "набор результатов" и прикрепляется к выбранному аспекту в UniDimNet. Объект "набор результатов" может быть любым подходящим объектом, включая совокупность, таблицу или массив, и может "обнуляться" (т.е. освобождаться) после создания. После перетаскивания UniView в область результатов можно соответственно изменить объект набора результатов. Например, в зависимости от контекста аспектов UniView объект набора результатов может изменить положение в UniDimNet. В данном примере, если UniView возвращает "информацию о визите" и перетаскивается на аспект "пациент" (выбранный пользователем), то объект набора результатов переместится на "более низкий" уровень (если иерархия UniDimNet определяет UniDim "пациент" как более высокий, чем "визиты", что будет иметь место, если "пациент" определен как имеющий от одного до нескольких "визитов"). Когда UniView перетаскивается в область результатов, к объекту набора результатов добавляются столбцы (например, 1710, 1720 и 1730 на фиг.17) (что является примером сложного запроса). Эти столбцы определяются возвращенным "результатом" от каждого UniView, который перетащили в поле результата. Чтобы поместить информацию, возвращенную из запроса UniView (после того, как представитель аспекта был впоследствии выбран пользователем), в объект набора результатов (и отобразить пользователю с помощью ГПИ), столбцы объекта набора результатов отображаются прямо в столбцах таблицы, которая содержит результаты запроса UniView. Результирующие данные в объекте набора результатов отображаются в области результатов ГПИ.

Во время использования системы 100 может потребоваться добавить дополнительный источник данных или источники данных к системе 100. В этом случае систему 100 модифицируют любым подходящим образом, позволяющим добавить такой новый источник (источники) данных. В одном варианте, показанном на фиг.20А и 20В, проиллюстрирована примерная процедура внедрения дополнительного источника (источников) данных. На этапе 2005 UniServer закрыт. На этапе 2010 выполняется определение, требует ли добавление нового источника (источников) данных добавления любого нового аспекта отраслевого бизнес-контекста к UniDimNet. Если дополнительные аспекты нужны или желательны, то на этапе 2015 UniDimNet расширяется, чтобы включить новый UniDim для каждого нового аспекта и пересмотреть соответственно любые существующие UniDim. После добавления нового (новых) UniDim (или если новые UniDim не добавляются) на этапе 2020 создается DataSourceDim для каждого аспекта источника данных в дополнительном источнике (источниках) данных и все новые DataSourceDim соответственно связываются в UniDimNet. На этапе 2025 факультативно создается новый класс источника данных, особенно если желательна помощь UniBuilder в создании UniView (например, с помощью UniBot). На этапе 2030 создается книга правил и процесса обновления и сохраняется в системе 100. На этапе 2035 факультативно определяется, требует ли новый источник (источники) данных новый класс механизмов доступа к данным. Если ответ положительный, то создается новый класс UniView для инкапсулирования механизмов доступа, необходимых для запроса источника (источников) данных, особенно, если требуется помощь UniBuilder в создании UniView, и класс источника данных, созданный на этапе 2025, изменяется в соответствии с новым классом UniView.

После создания нового класса UniView (или если такой класс не создавался) на этапе 2045 снова запускается UniServer. На этапе 2050 создаются UniView для нового источника (источников) данных с помощью любых подходящих способов, включая ручной способ, или с помощью UniBuilder (особенно UniBot, если были созданы новые классы UniView). На этапе 2055 новые UniView включаются в дерево UniView Tree. На этапе 2060 новые представители источника данных регистрируются в системе 100, включая регистрацию и сохранение всей требуемой информации о каждом представителе в UniDimNet. Блок извещения будет реагировать на новых представителей (не показано), чтобы ассимилировать их в систему 100.

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

На фиг.21 проиллюстрирован вариант способа унификации данных согласно изобретению. В этом варианте на этапе 2110 определяется множество аспектов отраслевого бизнес-контекста. Можно определить любые подходящие аспекты для отрасли, включая без ограничения те, которые были описаны выше. На этапе 2120 определяется множество специфических для источника данных аспектов для каждого источника данных, к которому можно обращать запрос. Можно определить соответствующие аспекты, специфические для источника данных, включая без ограничения те, которые были описаны выше. На этапе 2130 обеспечивается база данных, включающая в себя представления определенных аспектов и аспектов, специфических для источника данных (например, UniDimNet). Может быть обеспечена любая подходящая база данных, включая без ограничения UniDimNet, описанную выше. На этапе 2140 обеспечивается множество запросов, адаптированных для каждого источника данных (например, UniView). Можно предусмотреть любые подходящие запросы, включая, без ограничения перечисленным, описанные выше UniView, интерфейсы UniViewInterface и CompoundUniView. Каждому запросу предоставляется доступ к источнику данных с помощью механизма доступа к данным, который облегчает доступ к источнику данных. На этапе 2150 по меньшей мере один источник данных запрашивается с помощью по меньшей мере одного из представленных запросов. Например, как было описано выше, используется UniView для запроса источника данных, связанного с данным UniView. На этапе 2160 результаты запроса предоставляются пользователю. Можно использовать любые походящие операции для предоставления таких результатов пользователю, включая без ограничения использование ГПИ, предоставленного UniViewer, как было описано выше.

Следует понимать, что описанный выше способ может включать в себя любые дополнительные соответствующие операции и что любой описанный выше этап может содержать дополнительные подэтапы. Например, на фиг.22 этап 2120 факультативно содержит этапы 2210-2250. На этапе 2210 создается объект в базе данных, чтобы представлять каждый аспект отраслевого бизнес-контекста. Можно использовать любой соответствующий объект, включая UniDim в табличном формате, описанный выше. На этапе 2220 каждый объект связывается по меньшей мере с одним другим объектом. Объекты могут связываться любым подходящим образом, включая иерархическую взаимосвязь UniDim, описанную выше. На этапе 2230 создается объект в базе данных, чтобы представлять каждый аспект, специфический для источника данных. Можно использовать любой подходящий объект, включая DataSourceDim в табличном формате, описанный выше. На этапе 2240 каждый объект аспекта, специфического для источника данных, связывается по меньшей мере с одним объектом аспекта отраслевого бизнес-контекста. Объекты аспекта, специфического для источника данных, можно связывать с объектами аспекта отраслевого бизнес-контекста любым походящим способом, включая описанные выше. На этапе 2250 объекты в базе данных заполняются релевантной информацией. Любую релевантную информацию можно сохранять в этих объектах любым подходящим способом. Например, как было описано выше, UniDim и DataSourceDim заполняются уникальными идентификаторами для каждого представителя аспекта.

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

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

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

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

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

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

5. Система по п.4, в которой описание запрашиваемых данных представляет собой точный запрос информации.

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

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

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

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

10. Устройство для унификации множества источников данных,

хранящих данные, относящиеся к отрасли промышленности, причем каждый из множества источников данных является представителем источника данных типа источника данных, при этом устройство содержит:

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

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

i) каждого типа источника данных, представленного во множестве источников данных и

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

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

11. Устройство по п.10, в котором доступ к данным, происходящим из множества источников данных, зависит от определенных для пользователя прав доступа, связанных с, по меньшей мере, одним из типов источников данных, представителей источников данных, аспектов бизнес-контекста и представителей аспекта бизнес-контекста.

12. Устройство по п.10, в котором в базе данных содержится, по меньшей мере, второе множество узлов.

13. Устройство по п.12, в котором каждый узел второго о множества узлов включает таблицу.

14. Устройство по п.13, в котором каждый представитель аспекта бизнес-контекста имеет уникальную идентификацию в таблице соответствующего узла второго множества узлов.

15. Устройство по п.10, в котором множество источников данных включают в себя первого и второго представителей источников данных первого типа источников данных, причем каждый из первого и второго представителей источников данных хранит представителя данных, представляющих первый аспект бизнес-контекста.

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

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

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

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

20. Устройство по п.10, в котором множество источников данных включают в себя первого представителя источника данных из первого типа источников данных и второго представителя источника данных из второго типа источников данных, причем каждый из первого и второго представителей источников данных хранит представителя данных, представляющих первый аспект бизнес-контекста.

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

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

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

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

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

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

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

i) анализа внутренних структур данных одного или нескольких множеств источников данных,

ii) анализа данных, хранящимся в одном или нескольких множествах источников данных,

iii) определения бизнес-контекстов данных, хранящихся в одном или нескольких множествах источников данных, и

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

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

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

30. Устройство для унификации данных, относящихся к отрасли промышленности, включающее в себя:

множество источников данных, хранящих данные, относящиеся к отрасли промышленности, причем каждое множество источников данных, является представителем источника данных типа источника данных;

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

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

i) каждого типа источника данных, представленного во множестве источников данных и

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

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

31. Устройство по п.30, в котором доступ к данным, происходящим из множества источников данных, зависит от определенных для пользователя прав доступа, связанных с, по меньшей мере, одним из типов источников данных, представителей источников данных, аспектов бизнес-контекста и представителей аспекта бизнес-контекста.

32. Устройство по п.30, в котором первый логический элемент, включает в себя: пользовательский интерфейс, выполненный с возможностью разрешения пользователю выполнять, по меньшей мере, одно из выбора, по меньшей мере, одного аспекта бизнес-контекста, выбора требуемой информации и передачи запроса, устройство.

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

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

i) анализе внутренней структуры данных одного или нескольких множеств источников данных,

ii) анализе данных, хранящимся в одном или нескольких множествах источников данных,

iii) определении бизнсе-контекстов данных, хранящихся в одном или нескольких множествах источников данных, и

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

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

a) хранение информации в первом множестве узлов, которое определяет соответствующее множество аспектов отраслевого бизнес-контекста, и соединение первого множества узлов таким образом, что представляет связи между соответствующими аспектами бизнес-контекста;

b) хранение информации во втором множестве узлов, которые указывают данные, хранящиеся в множестве источников данных, соответствующих, по меньшей мере, части множества аспектов бизнес-контекста для, по меньшей мере, одного из: i) каждого типа источника данных, представленного во множестве источников данных и ii) каждого представителя источника данных, представленного во множестве источников данных, и отображение второго множества узлов в первом множестве узлов на основе соответствующих аспектов бизнес-контекста;

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

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

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

36. Способ по п.35, дополнительно включающий в себя: f) передачу запроса каждому идентифицированному представителю источника данных для предоставления требуемой информации.

37. Способ по п.36, дополнительно включающий в себя:

f) хранение, по меньшей мере, одного запроса переданного в f) для использования в последующем запросе для предоставления соответствующей требуемой информации вместо повторения d) и е).

38. Способ по п.36, дополнительно включающий в себя:

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

39. Способ по п.38, дополнительно включающий в себя:

h) хранение, по меньшей мере, одного результата, принятого в d) для использования совместно с последующим запросом для предоставления соответствующей требуемой информации вместо повторения g).

40. Способ по п.38, в котором, по меньшей мере, одно из инициирования в d), идентификации в е), передачи в f) и приема в g) зависит от определенных для пользователя прав доступа, связанных с, по меньшей мере, одним из типов источников данных, представителей источников данных, аспектов бизнес-контекста и представителей аспекта бизнес-контекста совместно с доступом к данным, происходящим из множества источники данных.

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

42. Способ по п.41, дополнительно включающий в себя:

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

43. Способ по п.41, совместно с хранением в b), способ дополнительно включающий в себя:

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

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

44. Способ по п.41, совместно с хранением в b), способ дополнительно включающий в себя:

f) хранение информации в первом узле источника данных второго множества узлов, которое указывает данные, хранящиеся в первом представителе источника данных, соответствующего первому аспекту бизнес-контекста;

g) хранение информации во втором узле источника данных второго множества узлов, которое указывает данные, хранящиеся во втором представителе источника данных, соответствующего первому аспекту бизнес-контекста;

h) хранение информации в первом узле источника данных, который определяет первого представителя аспекта бизнес-контекста; и

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

45. Способ по п.41, дополнительно включающий в себя:

f) совместно с инициацией в d), инициацией первого запроса для предоставления требуемой информации из множества источников данных, основанного, по меньшей мере, частично на выборе первого аспекта бизнес-контекста; и

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

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

47. Способ по п.46, дополнительно включающий в себя:

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

48. Способ по п.46, совместно с хранением в b), способ дополнительно включающий в себя:

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

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

h) хранение информации в первом узле источника данных, который определяет первого представителя аспекта бизнес-контекста; и

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

49. Способ по п.46, совместно с хранением в b), способ дополнительно включающий в себя:

f) хранение информации в первом узле источника данных второго множества узлов, которое указывает данные, хранящиеся в первом представителе источника данных, соответствующем первому аспекту бизнес-контекста;

g) хранение информации во втором узле источника данных второго множества узлов, которое указывает данные, хранящиеся во втором представителе источника данных, соответствующем первому аспекту бизнес-контекста;

h) хранение информации в первом узле источника данных, который определяет первого представителя аспекта бизнес-контекста; и

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

50. Способ по п.46, дополнительно включающий в себя:

f) совместно с инициацией в d), инициация первого запроса для предоставления требуемой информации из множества источников данных, основанного, по меньшей мере, частично на выборе первого аспекта бизнес-контекста; и

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

51. Способ по п.35, в котором инициация в d) также основана, по меньшей мере, частично на выборе, по меньшей мере, одном типе источников данных или, по меньшей мере, одном представителе источника данных для предоставления требуемой информации.

52. Способ по п.35, дополнительно включающий в себя:

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

g) создание первого множества узлов, основанную, по меньшей мере, частично на определенном множестве аспектов бизнес-концепции; и

h) создание второго множества узлов, основанную на, по меньшей мере, частично на одном или нескольких из:

i) анализе внутренних структур данных одного или нескольких множеств источников данных,

ii) анализе данных, хранящихся в одном или нескольких множествах источников данных,

iii) определении бизнес-контекста данных, хранящихся в одном или нескольких множествах источников данных, и

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

53. Способ для унификации данных, относящихся к отрасли промышленности, включающий в себя:

а) идентификацию множества источников данных, хранящих данные, относящиеся к отрасли промышленности, причем каждое множество источников данных является представителем источника данных типа источника данных;

b) хранение информации в первом множестве узлов, которое определяет соответствующее множество аспектов отраслевого бизнес-контекста, и соединение первого множества узлов таким образом, что представляет связи между соответствующими аспектами бизнес-контекста;

c) хранение информации во втором множестве узлов, которые указывают данные, хранящиеся в множестве источников данных, соответствующих, по меньшей мере, части множества аспектов бизнес-контекста для, по меньшей мере, одного из: i) каждого типа источника данных, представленного во множестве источников данных и ii) каждого представителя источника данных, представленного во множестве источников данных, и отображение второго множества узлов в первом множестве узлов на основе соответствующих аспектов бизнес-контекста;

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

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

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

g) передачу запроса каждому идентифицированному представителю источника данных для предоставления требуемой информации;

h) хранение, по меньшей мере, одного запроса, переданного в g) для использования в последующем запросе для предоставления соответствующей требуемой информации вместо повторения е) и f);

i) прием результата из, по меньшей мере, одного представителя источника данных в ответ на запрос;

j) хранение, по меньшей мере, одного результата, принятого в i) для использования совместно с последующим запросом на предоставление соответствующей требуемой информации вместо повторения g).

54. Способ по п.53, в котором, по меньшей мере, одно из инициации в е), идентификации в f), передачи в g) и приема в i) зависит от определенных для пользователя прав доступа, связанных с, по меньшей мере, одним из типов источников данных, представителей источников данных, аспектов бизнес-контекста и представителей аспекта бизнес-контекста совместно с доступом к данным, происходящим из множества источники данных.

55. Способ по п.53, дополнительно включающий в себя:

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

56. Способ по п.53, дополнительно включающий в себя:

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

l) создание первого множества узлов, основанную, по меньшей мере, частично на определенном множестве аспектов бизнес-концепции; и

m) создание второго множества узлов, основанную, по меньшей мере, частично на одном или нескольких из i) анализе внутренних структур данных одного или нескольких множеств источников данных, ii) анализе данных, хранящихся в одном или нескольких множествах источников данных, iii) определении бизнес-контекстов данных, хранящихся в одном или нескольких множествах источников данных, и iv) определении логических группировок данных, хранящихся в одном или нескольких множествах источников данных относительно множества аспектов бизнес-концепции.



 

Похожие патенты:

Изобретение относится к вычислительной технике. .

Изобретение относится к области сетей передачи данных. .

Изобретение относится к системам и способам для идентификации нежелательной информации. .

Изобретение относится к групповому обмену сообщениями. .

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

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

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

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

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

Изобретение относится к средствам осуществления связи между вычислительными устройствами по вычислительным сетям радиосвязи

Изобретение относится к системе и способу применения преобразований к файлам, состоящим из множественных частей

Изобретение относится к области аутентификации, в частности разграничения доступа пользователя к подобласти области сети

Изобретение относится к области сетей передачи данных

Изобретение относится к администрированию сетевой системы и, более конкретно, к среде командной строки, предназначенной для администрирования удаленной сетевой системы
Наверх