ОТОБРАЖЕНИЕ МОДЕЛИ ФАЙЛОВОЙ СИСТЕМЫ В ОБЪЕКТ БАЗЫ ДАННЫХ Российский патент 2011 года по МПК G06F17/30 

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

Представленное изобретение, в целом, относится к базам данных, и в частности к системам и/или методам, способствующим сохранению экземпляра типа данных и/или выполнению запроса данных.

УРОВЕНЬ ТЕХНИКИ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

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

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

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

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

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

Фиг.6 иллюстрирует структурную схему высокоуровневой структуры хранения в рамках модели данных файлового хранилища.

Фиг.7 иллюстрирует структурную схему экземпляра типа со связанными с ним таблицами.

Фиг.8 иллюстрирует структурную схему иерархии типов и соответствующую проекцию представления данных.

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

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

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

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

ОПИСАНИЕ ИЗОБРЕТЕНИЯ

Использующиеся в данном применении термины «компонент», «система», «интерфейс», «схема» и подобные подразумеваются относящимися к компьютерной сфере, включающей аппаратные средства, программное обеспечение (например, выполняющееся) и/или программно-аппаратные средства. Например, компонент может быть процессом, выполняющимся в процессоре процессором, объектом, исполняемым файлом, программой и/или компьютером. Как пример, компонентом может быть как приложение, выполняемое сервером, так и сам сервер. В процессе может содержаться один или более компонентов, и компонент может находиться на одном компьютере и/или быть распределенным между двумя или более компьютерами.

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

Обратимся к фиг.1, иллюстрирующей систему 100, обеспечивающей хранение экземпляра типа, связанного с моделью данных. Модель данных может быть моделью файлового хранилища 102, дающего возможность хранения, поиска и установления взаимосвязи. Например, видом информации может быть, но ограничен только этими случаями, документ, изображение, видеозапись, контакт, сообщение, электронное письмо, звуковой фрагмент и т.д. Виды информации могут рассматриваться как единицы информации, которые могут быть представлены как случаи комплексных типов, которые являются частью системы типов, поддерживающей наследование. Наследование может быть определено как ситуация, при которой определенные характеристики переходят от одного контекста к другому. В случае объектно-ориентированного программирования объекты наследуют атрибуты и/или поведение от других объектов. Очевидно, что наследование может рассматриваться как иерархическая структура и/или формат.

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

1) нахождение в модели данных файлового хранилища 102, по меньшей мере, одного элемента, соответствующего некоторым критериям;

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

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

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

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

На фиг.2 проиллюстрирована система 200, позволяющая хранить экземпляры типов и/или выполнять запросы на поиск элемента документа и контакта, связанных с моделью данных 202. Модель данных 202 может быть модельным представлением файловой системы хранения, использующей иерархические характеристики и/или наследование. Тип может включать в себя документ, изображение, видеозапись, контакт, сообщение, электронное письмо, звуковой фрагмент и т.д. Однако понятно, что тип может быть типовым информационным типом, хранящимся в системе, представляемой моделью данных 202. Система 204 хранения типов может хранить экземпляры типов и обеспечивать выполнение запросов, позволяющих эффективно находить, по меньшей мере, один из следующих объектов: элемент в модели данных 202; документ в модели данных 202 и контакт в модели данных 202. Система 204 хранения типов может принимать данные, которые могут быть критериями запроса, схемой, критериями, определением схемы, моделью данных, типом, …. Система 200 может также использовать интерфейс 206 для обеспечения различных адаптеров, соединителей, каналов, каналов связи и т.д. для интеграции системы 204 хранения типов практически в любую операционную систему и для обеспечения связи.

Система 204 хранения типов может также включать в себя компонент 208 хранения («хранилище 208»), которое может хранить экземпляры типов. Хранилище может быть отображением модели 202 данных, в которой отображение хранилища может описывать объект базы данных, созданный на основе определения схемы и того, каким образом описанные экземпляры классов хранятся или могут быть доступны. Другими словами, хранилище 208 может хранить экземпляры типов и, по меньшей мере, одно правило, связанное с отображением объявления типа в объект базы данных.

Система 204 хранения типов может включать в себя компонент 210 запроса («запрос 210»), который обеспечивает запросы данных. Запрос 210 может получить, по крайней мере, один из следующих объектов:

- элемент в системе, представленной моделью 202 данных;

- документ в системе, представленной моделью 202 данных;

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

Должно быть принято во внимание и понято, что запрос может базироваться на некоторых критериях и/или критериях запроса, полученных через интерфейс 206. К тому же запрос 210 не ограничивается элементом, документом и контактом; может быть использован любой удобный тип информации, хранящейся в системе, представленной моделью данных 202.

Фиг.3 иллюстрирует систему 300, которая позволяет использовать реляционные хранилища и возможности реляционных запросов. Система 304 хранения типов может хранить экземпляры типов и запросы для рационального и эффективного нахождения, по крайней мере, одного из: элементов, документов и/или контактов, причем эти элементы связаны с файловой системой, представленной моделью 302 данных. Должно быть принято во внимание, что файловая система может быть файловой системой хранения, использующей иерархическую структуру и/или характеристики наследования. Система 304 хранения типов может быть в значительной степени похожа на систему 104, 204 хранения типов, которые показаны на фиг.1 и 2 соответственно. Система 304 хранения типов может использовать интерфейс 306 (для предоставления связи и/или приема данных), который в дальнейшем будет использоваться в соответствии с предметом изобретения.

Система 304 хранения типов может включать компонент 308 хранения («хранилище 308») и компонент 310 запроса («запрос 310»). Хранилище 310 может обеспечить любой удобный метод хранения экземпляра типа. Запрос 310 может обеспечить запрос, который может рационально и эффективно достичь, по меньшей мере, следующего:

- по меньшей мере, один элемент в системе, соответствующий критериям;

- по меньшей мере, один документ в системе, удовлетворяющий критериям;

- по меньшей мере, один контакт в системе, соответствующий критериям.

Должно быть принято во внимание и понятно, что хранилище 308 и запрос 310 могут быть в значительной мере похожи на хранилище 208 и запрос 210, которые показаны на фиг.2.

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

Фиг.4 иллюстрирует систему 400, способствующую отображению и/или просмотру данных, связанных с моделью 402 данных. Модель 402 данных может представлять файловую систему хранения, позволяющую осуществлять хранение, нахождение и установление взаимосвязи информации. Обычный информационный тип, который может храниться в системе, может включать в себя документ, изображение, видеозапись, контакт, сообщение и т.д. Информационный тип может быть представлен как экземпляры комплексных типов, являющихся частью системы типов, поддерживающей наследование. Система 404 хранения типов может хранить экземпляры типов и обеспечивать запрос для поиска элементов, документов и контактов, удовлетворяющих некоторым критериям. Система 400 может также использовать интерфейс 406 для установления связи и/или приема данных, которые могут включать в себя критерии, типы, схемы, модели и запросные критерии.

Система 404 хранения типов может также включать в себя компонент 408 отображения для осуществления хранения экземпляров типов. Компонент 408 отображения обеспечивает отображение типов, описанных в схеме, на определенные типы и объекты базы данных. Компонент 408 отображения может являться картой хранилища, описывающей, по меньшей мере, один объект, причем этот объект базы данных может быть создан на основании схемы определения и/или того, как экземпляры типов, описанные в схеме, хранятся и/или могут быть доступны. Другими словами, экземпляры типов могут быть сохранены и могут быть использованы правила для отображения объявления типа в объект данных. Каждый тип в схеме отображается в класс (например, общеязыковая исполняющая среда (CLR)) в хранилище.

Система 404 хранения типов может включать в себя компонент 410 отображения для обеспечения проекции представления. Проекция представления может раскрывать экземпляры просматриваемого типа. Ценно то, что типы могут являться иерархической структурой, использующей, по меньшей мере, наследование. Другими словами, каждый тип является частью иерархии типов. Представление может быть связано с заданным типом и может проецировать (соотносить) поднабор соответствующих типов представления, связанным с его базовым типом. Представление может проецировать экземпляры, связанные с конкретными типами. Например, для типа «сообщение» только экземпляры, для которых сообщение является родительским элементом, могут быть представлены, по меньшей мере, на основе иерархической структуры.

Компонент 410 представления может обеспечить различные типы пользовательских интерфейсов для осуществления взаимодействия между пользователем и любым компонентом, связанным с системой 404 хранения типов. Как показано, компонент 410 представления является отдельным объектом, встроенным в систему 404 хранения типов. Однако должно быть принято во внимание, что компонент 410 представления и/или подобные компоненты представления могут быть отдельными от системы 404 хранения типов компонентами и/или автономными модулями. Компонент 410 представления может предоставлять один или более графических пользовательских интерфейсов (GUI), интерфейсов командной строки и подобных. Например, GUI может быть визуализирован таким образом, чтобы обеспечить пользователя областями или средствами для загрузки, импортирования, чтения (и т.д.) данных, и может включать в себя области для представления результатов этих действий. Эти области могут содержать известные текстовые и/или графические области, содержащие диалоговые окна, статические управляющие элементы, выпадающие меню, окна списков, всплывающие меню, а также управляющие элементы редактирования, комбинированные окна, переключатели, кнопки-флажки, нажимаемые кнопки и графические области. Как дополнение могут быть применены средства для обеспечения представления вертикальных и/или горизонтальных линеек прокрутки для навигации и кнопки панели инструментов для определения того, какая область будет видимой. Например, пользователь может взаимодействовать с одним или более компонентами, связанными с системой 404 хранения типов.

Пользователь также может взаимодействовать с областями для того, чтобы выбрать и подготовить информацию посредством различных устройств, например, таких как мышь, трекбол, консоли, клавиатуры, пера и/или голосового управления. Обычно такой механизм, как нажимаемые кнопки или клавиши ввода на клавиатуре могут быть использованы для последующего ввода информации для инициации поиска. Ценно также то, что изобретение не ограничивается этими применениями. Например, простая активация кнопки-флажка может инициировать передачу информации. Другой пример - возможно использование интерфейса типа командной строки. Например, интерфейс типа командной строки может запросить (например, через текстовое сообщение на дисплее и звуковой сигнал) у пользователя информацию посредством текстового сообщения. Пользователь может предоставить соответствующую информацию, например буквенно-цифровые входные данные, соответствующие опциям, предоставленным в приглашении интерфейса, или ответить на вопрос, поставленный в приглашении интерфейса. Необходимо принять во внимание то, что интерфейс типа командной строки может использоваться совместно с GUI или API. Как дополнение, интерфейс типа командной строки может быть использован совместно с аппаратными средствами (например, видеоадаптеры) и/или дисплеями (например, черно-белыми и EGA) с ограниченными возможностями поддержки графики и/или низкой пропускной способностью каналов связи.

Фиг.5 иллюстрирует систему 500, использующую интеллектуальные средства для осуществления хранения экземпляра типа, связанного с моделью данных 502. Система 500 включает в себя систему 504 хранения типов, интерфейс 506 и модель 502 данных, которые могут быть в значительной мере схожи с компонентами, показанными на предыдущих чертежах. Интерфейс 506 может осуществлять передачу информации, связанной с данными, которые могут включать в себя критерии, тип, схему, модель данных и запросные критерии. Система 500 может обеспечивать хранение типа, запроса и/или предоставлять возможность просмотра. Ценно и понятно, что процессор базы данных может обеспечивать реляционное хранилище и реляционные запросы в системе 500.

Система 500 также включает в себя интеллектуальный компонент 508. Интеллектуальный компонент 508 может использоваться системой хранения 504 для осуществления хранения и/или обслуживания запросов для системы 500. Например, интеллектуальный компонент 510 может использоваться для осуществления определения сохраняемых пользовательских типов. Данные истории (хронологии) совместно с пользовательскими профилями могут позволить интеллектуальному компоненту 508 определять сохраняемый тип и/или осуществлять запрос по некоторым критериям.

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

Классификатор - это функция, которая отображает входной вектор x=(x1, x2, x3, x4, xn) атрибутов в достоверность того, что входные данные принадлежит классу, то есть f(x)=confidence(class). Такая классификация может использовать вероятностный или статистический анализ (например, разложение на утилиты анализа и затраты) для прогнозирования или предположения действия, которое пользователь желает выполнить автоматически. Машины опорных векторов (SVM - support vector machine) являются примером классификатора, который может быть использован. SVM осуществляют определение гиперповерхности в пространстве вероятных входных данных, которое гиперповерхность пытается разделить запускающие критерии от незапускающих критериев. Интуитивно это делает классификацию правильной для тестирующих данных, близких, но не идентичных обучающим данным. Другие управляемые и неуправляемые модели классификационных подходов включают в себя, например, простой Байесовский метод, Байесовские сети, деревья решений, нейронные сети, модели с нечеткой логикой и вероятностные классификационные модели, обеспечивающие возможность применения различных схем независимости. Используемый вид классификации также включает в себя регрессию, используемую при разработке моделей приоритетов.

Более того, интеллектуальный компонент 508 может использовать хранилище 510 данных для хранения профилей и/или исторических (хронологических) данных. Хранилище 510 данных может быть как временной, так и постоянной памятью или может включать в себя и временную, и постоянную память. Только в иллюстративных и не ограничивающих целях, постоянная память может быть памятью только для чтения (ROM), программируемой ROM (PROM), электрически программируемой ROM (EPROM), электрически стираемой программируемой ROM (EEPROM) или флэш-памятью. Временная память может включать в себя оперативное запоминающее устройство (RAM), которое действует как внешняя кэш-память. Как иллюстрация, но не как ограничение, RAM доступна в различных видах, таких как статическая RAM (SRAM), динамическая RAM (DRAM), синхронная DRAM (SDRAM), SDRAM с удвоенной скоростью передачи (DDR SDRAM), расширенная SDRAM (ESDRAM), DRAM с синхронной связью (SLDRAM), RAM Rambus прямого доступа (RDRAM), динамической RAM по технологии Direct Rambus (DRDRAM) и динамической RAM по технологии Rambus (RDRAM). Хранилище 510 данных рассматриваемых системы и методов подразумевает использование без ограничений этих и любых подходящих типов памяти. Дополнительно должно быть понятно, что хранилище 510 данных может быть сервером и/или базой данных.

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

На фиг.7 показан элемент 702. Таблица 704 элемента 702 может содержать все экземпляры элементов в хранилище (не показано). Таблица 704 может содержать экземпляр 706 объекта («Документ») и экземпляр 708 объекта («Контакт»). Понятно, что каждый тип в схеме отображается в CLR класс в хранилище. Экземпляр 706 объекта может включать в себя заголовок, аннотацию, печатное издание, автора и различные другие метаданные, связанные с экземпляром 706 объекта. Подобным образом, экземпляр 708 объекта может включать в себя различные метаданные, такие как имя, адрес, электронная почта и т.д.

На фиг.8 показана иерархия 800 типов и соответствующая проекция 820 представления. Иерархия 800 типа может включать в себя элемент 802, контакт 804, документ 806, сообщение 808, персональные данные 810, организацию 812, электронную почту 814, факс 816 и голосовое сообщение 818. Понятно, что иерархия 800 типов - только пример и любая удобная иерархия и/или типы могут быть использованы в соответствии с предметом изобретения. Как показано, элемент 802 рассматривается как родительский для каждого входящего в него типа. Таким образом, контакт 804 является родительским объектом для персональных данных 810 и организации 812, в то время как сообщение 808 является родительским для электронной почты 814, факса 816 и голосового сообщения 818. Кроме этого соответствующая проекция 820 представления может отражать иерархию 800 типов. Представление, связанное с заданным типом, может проецировать поднабор элементов представления, связанного с его базовым типом. Например, представление элемента проецирует все элементы в хранилище. Представление контактов проецирует только элементы, которые имеют тип «контакт». Представление персональных данных проецирует только контакты, имеющие старший производный тип «персона».

Обратимся к фиг.6; отображение типа может быть осуществлено при использовании алгоритма отображения типа в тип для описания соответствующей структуры хранения в хранилище. Понятно, что отображение может быть связано с любой файловой системой хранения (например, модель данных, основанная на системе, использующей составные экземпляры типов для описания и/или представления единицы информации). Каждый тип, объявленный в схеме, отображается в CLR класс, который поддерживает контракт SQL UDT (UDT - единый стандарт передачи данных). Понятно, что хотя SQL и используется в приведенных ниже примерах, также могут быть использованы любые подходящие системы управления базами данных. Типы принадлежат пространству имен, которые соответствуют пространству имен схемы с добавленным суффиксом «.Store» (хранение). Типы в заданном пространстве имен соединяются в одиночную сборку, используемую как модуль расширения схемы. Имя CLR типа эквивалентно имени, объявленному в схеме. Для каждого объявленного свойства типа к соответствующему CLR типу добавляется следующее:

1) приватное поле с именем, эквивалентным имени, указанном в схеме в виде префикса вида «m_». Полю приписывается специфический атрибут UDT «System.Data.SqlTypes.SqlUdtField»;

2) публичное свойство с именем, эквивалентным имени, указанном в схеме и соответствующее состояниям получить/установить. Свойству приписывается специфический атрибут UDT System.Data.SqlTypes.SqlUdtProperty; и

3) тип поля и свойство являются CLR типами, соответствующими типу, объявленному в схеме. Если тип является одним из скалярных типов, то они отображаются в один из скалярных SQL типов (обсуждается ниже).

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

Таблица 1 Тип файловой системы хранения Обслуживаемый тип SQL Описание Строка (String) SqlString Данные в Unicode переменной длины с максимальной длиной 2³¹ символов. Длина может быть зафиксирована в диапазоне 1-4000 символов или неограниченной при использовании Двоичный (Binary) SqlBinary Двоичные данные переменной длины с максимальной длиной 2³² байт. Длина может быть зафиксирована в диапазоне 1-8000 байт или неограниченной при использовании ключевого слова «max». Булевский (Boolean) SqlBoolean Обнуляемая Булевская величина Байт (Byte) SqlByte Одинарный байт без знака. Целый, 16 бит (Int16) SqlInt16 Целочисленные данные в диапазоне от -2¹⁵ (-32,768) до 2¹⁵ - 1 (32,767). Целый, 32 бит (Int32) SqlInt32 Целочисленные (целое число) данные от -2³¹ (-2,147,483,648) до 2^3I -1 (2,147,483,647). Целый, 64 бит (Int64) SqlInt64 Целочисленные (целое число) данные от -2⁶³ (-9223372036854775808) до 2⁶³-1 (9223372036854775807). Одинарной точности (Single) SqlSingle Числовые данные с плавающей точкой от -3,40E + 38 до 3,40E +38 Двойной точности (Double) SqlDouble Числовые данные с плавающей точкой от -1,79E + 308 до 1,79E +308 С фиксированной точкой (Decimal) SqlDecimal Числовые данные с фиксированной точностью и диапазоном. Для типа Decimal применяются атрибуты «точность» и «диапазон». «Точность» определяет максимальное число десятичных разрядов цифр десятичного значения. Это включает в себя цифры слева и справа от десятичной точки. Значение атрибута «точность» - целое число от 1 до 28. «Диапазон» определяет максимальное число десятичных цифр справа от десятичной точки. Значение атрибута «диапазон» должно быть между 0 и значением атрибута «точность». Примечание для этапа Beta: эти атрибуты не поддерживаются на данном этапе. «Точность» зафиксирована равной 28, и «диапазон» зафиксирован равным 14. Дата/время (DateTime) SqlDateTime Дата и время в диапазоне от 01 января 1753 года до 31 декабря 9999 года с точностью до трех тысячных секунды или до 3,33 миллисекунды. Guid SqlGuid Глобальный уникальный идентификатор (GUID). Xml SqlString Расширяемый язык разметки (XML) в настоящее время сохраняется как строковое поле. Собственная поддержка XML типа будет рассматриваться в версиях после Beta 1. Поток (Stream) TBD Поддержка запланирована в версиях после Beta 1. При поддержке может заменить объявления типов String(max) и Binary(max).

Объект базы данных, созданный в хранилище файловой системы хранения, может быть сохранен под именем в схеме наименований SQL, производном от схемы наименования файловой системы хранения. Суффикс «.Store» добавляется к схеме наименования в файловой системе хранения для формирования имени по схеме SQL. Например, схема system.storage файлового хранилища формирует объекты в SQL схеме "[System.Storage.Store]", например "[System.Storage.Store].Item".

Содержимое в файловой системе хранения может быть доступно через представления. Представления, показанные ниже, предназначены только для чтения, однако предмет изобретения не является столь ограниченным с момента, когда представления могут быть доступны для записи. Каждый тип элемента может быть отображен в типизированное представление. Каждое представление типизированного элемента может быть идентифицировано в файловой системе хранения при использовании условий наименования вида [<Имя схемы>.Store].[<имя типа элемента>]. Представление типа для типа T может возвращать все элементы типа T и все элементы, производные от T. Представление, соответствующее типу System.Storage.Item - [System.Storage.Store].[Item]. Это представление может возвращать все элементы в хранилище файловой системы хранения. Следующая таблица описывает столбцы представления типов элементов.

Таблица 2 Имя столбца Тип Описание ItemId [System.Storage.Store].
ItemId ItemId элемента TypeId [System.Storage.Store].
TypeId Схематизированный идентификатор типа NamespaceName nvarchar(255) Уникальное имя элемента ContainerId [System.Storage.Store].
ItemId Идентификатор контейнера элемента Item Item type Экземпляр элемента типа EntityState [System.Storage.Store].
EntityState Информация о состоянии элемента ObjectSize Bigint Размер элемента объекта (неизменяемый столбец) ChangeInformation [System.Storage.Store].
ChangeInformation Информация для отслеживания изменений ItemSyncMetadata [System.Storage.Store].
ItemSyncMetadata Метаданные синхронизации PathHandle [System.Storage.Store].
BinPathHandle Дескриптор пути к элементу PromotionStatus Int Статус внедрения для элемента

Каждый тип ссылки отображается в типизированное представление. Каждое типизированное представление ссылки идентифицируется в хранилище файловой системы хранения, используя условное наименование [<Имя схемы>.Store].[<имя типа ссылки>]. Представлением, соответствующим типу System.Storage.Link, является [System.Storage.Store].[Link]. Это представление может содержать все ссылки в хранилище файловой системы хранения. Следующая таблица описывает столбцы представления типа «ссылки».

Таблица 3 Название столбца Тип Описание SourceRef [System.Storage.Store].
ItemId ItemId для источника элемента LinkId [System.Storage.Store].
LinkId Идентификатор ссылки TargetRef [System.Storage.Store].
ItemId ItemId для целевого элемента TypeId [System.Storage.Store].
TypeId TypeId старшего производного типа для экземпляра ссылки Link Link type Экземпляр типа «ссылка» EntityState [System.Storage.Store].
EntityState Информация состояния для ссылки ObjectSize Bigint Размер объекта «ссылка» (неизменяемый столбец) ChangeInformation [System.Storage.Store].
ChangeInformation Информация для отслеживания изменений LinkSyncMetadata [System.Storage.Store].
ItemSyncMetadata Метаданные синхронизации PathHandle [System.Storage.Store].
BinPathHandle Дескриптор пути к элементу, являющемуся источником для ссылки.

Все фрагменты элементов могут быть доступны через отдельное представление [System.Storage.Store].[ItemFragment]. Следующая таблица описывает столбцы глобального представления фрагмента элемента.

Таблица 4 Название столбца Тип Описание ItemId [System.Storage.Store],
ItemId ItemId содержащего элемента SetId [System.Storage.Store].
SetId Использование фрагмента элемента FragmentId [System.Storage.Store].
FragmentId Идентификатор экземпляра объекта TypeId [System.Storage.Store].
TypeId TypeId старшего производного типа для экземпляра ItemFragment ItemFragment [System.Storage.Store].
[ItemFragment] Экземпляр типа ItemFragment EntityState [System.Storage.Store].
EntityState Информация состояния для ссылки ChangeInformation [System.Storage.Store].
ChangeInformation Информация для отслеживания изменений PathHandle [System.Storage.Store].
BinPathHandIe Дескриптор пути к элементу, являющемуся источником для ссылки.

Каждое хранилище предоставляет представление глобального расширения, обозначаемое как [System.Storage.Store].[ItemExtension]. Экземпляры всех типов расширений доступны через это представление. Следующая таблица описывает столбцы в представлении глобального расширения.

Таблица 5 Название столбца Тип Описание ItemId [System.Storage.Store].
ItemId ItemId расширения TypeId [System.Storage.Store].
TypeId Схематизированный идентификатор типа ItemExtension [System.Storage.Store].
ItemExtension Экземпляр типа «расширение» EntityState [System.Storage.Store].
EntityState Информация состояния для расширения ObjectSize Bigint Размер объекта «расширение» (неизменяемый столбец) ChangeInformation [System.Storage.Store].
ChangeInformation Информация для отслеживания изменений PathHandle [System.Storage.Store].
BinPathHandle Дескриптор пути к элементу, содержащему расширение

Каждый тип расширения отображается в типизированное представление. Каждое типизированное представление идентифицируется в хранилище файловой системы хранения, используя условное наименование [<Имя схемы>.Store]. [<Имя типа расширения>]. Следующая таблица описывает столбцы представления типа «расширение».

Таблица 6 Имя столбца Тип Описание ItemId [System.Storage.Store].
ItemId ItemId расширения TypeId [System.Storage.Store].
TypeId Схематизированный идентификатор типа ItemExtension Extension type Экземпляр типа «расширение» ObjectSize Bigint Размер объекта «расширение» (неизменяемый столбец) EntityState [System.Storage.Store].
EntityState Информация состояния для типа «расширение» ChangeInformation [System.Storage.Store].
ChangeInformation Информация для отслеживания изменений PathHandle [System.Storage.Store].
BinPathHandle Дескриптор пути к элементу, содержащему расширение

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

Все элементы хранятся в отдельной таблице элементов, называемой [System.Storage.Store].[Table!Item]. Уникальный ключ в следующей таблице - ItemId.

Таблица 7 Имя столбца Тип Описание ItemId [System.Storage.Store].
ItemId ItemId элемента TypeId [System.Storage.Store].
TypeId Схематизированный идентификатор типа NamespaceName Nvarchar(255) Уникальное имя элемента ContainerId [System.Storage.Store].
ItemId Идентификатор содержащего элемента Item Item type Элемент EntityState [System.Storage.Store].
EntityState UDT-атрибут EntityState, содержащий метаинформацию об элементе SDId int Только для внутреннего применения (используется подсистемой безопасности) SDLastUpdateLocalTS Bigint Отметка времени последнего изменения SDId. Используется для отслеживания изменений ChangeInformation [System.Storage.Store].
ChangeInformation Информация для отслеживания изменений ItemSyncMetadata [System.Storage.Store].
ItemSyncMetadata Метаданные синхронизации для глобальных идентификаторов TombstoneStatus Int Состояние неактивности LastUpdateLocalTS Bigint Только для внутреннего применения (используется для индексирования). Этот столбец отображается в ChangeInformation.Last-
UpdateLocalTS. Нам необходимо отображать его для создания для него индекса. MaxOrd int Только для внутреннего применения (используется для вычисления PathHandle для новых элементов, добавляемых в этот контейнер элемента) TypePath Hierarchical_Type_Id Только для внутреннего применения (неизменяемый столбец) ObjectSize Bigint Размер объекта «элемент» (неизменяемый столбец) PathHandle [System.Storage.Store].
BinPathHandle Дескриптор пути к этому элементу PromotionStatus Int Статус внедрения для элемента LastAccessTime DateTime Время последнего доступа к файловому потоку, связанному с элементом StreamSize Bigint Размер потока, связанного с элементом AllocationSize Bigint Выделенный объем памяти для потока, связанного с элементом

Индексы к таблице элементов описаны в следующей таблице.

Таблица 8 Столбцы Уникальный Кластеризован Включаемые
столбцы TypePath, ItemId Да Да   ItemId Да Нет TombstoneStatus, TypePath, SDId PathHandle Да Нет SDId, TombstoneStatus ContainerId, NamespaceName Да Нет SDId, TombstoneStatus LastUpdateLocalTS Нет Нет SDId, TombstoneStatus, PathHandle

Все ссылки сохраняются в таблице ссылок, название которой [System.Storage.Store].[Table!Link]. Уникальные ключи в нижеследующей таблице - ItemId и LinkId.

Таблица 9 Имя столбца Тип Описание SourceRef [System.Storage.Store].
ItemId ItemId исходного элемента LinkId [System.Storage.Store].
LinkId Идентификатор ссылки TargetRef [System.Storage.Store].
ItemId ItemId целевого элемента TypeId [System.Storage.Store].
TypeId Схематизированный идентификатор типа TypePath Hierarchical_Type_Id Только для внутреннего применения (неизменяемый столбец) Link Link type Объект «ссылка» EntityState [System.Storage.Store].
EntityState Информация состояния для ссылки SDId Int Для внутреннего использования TombstoneStatus Int Статус неактивности ObjectSize Bigint Размер объекта «ссылка» (неизменяемый столбец) ChangeInforma-tion [System.Storage.Store].
ChangeInformation Информация для отслеживания изменений LinkSyncMetada-ta [System.Storage.Store].
LinkSyncMetadata Метаданные синхронизации LastUpdateLocalTS Bigint Только для внутреннего применения (используется для индексирования). Этот столбец отображается в ChangeInformation.LastUp-dateLocalTS. Нам необходимо отображать его для создания для него индекса. PathHandle [System.Storage.Store].
BinPathHandle Дескриптор пути к элементу, являющемуся источником для ссылки.

Индексы к таблице ссылок описаны в следующей таблице.

Таблица 10 Столбцы Уникальный Кластери-
зован Включаемые
столбцы SourceRef, LinkId Да Да   TypePath Нет Нет SDId, TombstoneStatus SourceRef, TypePath Нет Нет SDId, TombstoneStatus PathHandle Нет Нет SDId, TombstoneStatus TargetRef Нет Нет SDId, TombstoneStatus LastUpdateLocalTS Нет Нет SDId, TombstoneStatus,
PathHandle

Все EntityExtensions сохраняются в одной таблице, называющейся [System.Storage.Store].[Table!ItemExtension]. Нижеследующая таблица описывает таблицу расширений элементов.

Таблица 11 Имя столбца Тип Описание ItemId [System.Storage.Store].
ItemId ItemId расширения TypeId [System.Storage.Store].
TypeId Схематизированный идентификатор типа TypePath Hierarchical_Type_Id Только для внутреннего применения (неизменяемый столбец) ItemExtension [System.Storage.Store].
ItemExtension Объект ItemExtension EntityState [System.Storage.Store].
EntityState UDT-атрибут EntityState, содержащий метаинформацию EntityExtension. SDId Int Только для внутреннего применения TombstoneStatus Int Статус неактивности ObjectSize Bigint Размер объекта EntityExtension (неизменяемый столбец) ChangeInforma-tion [System.Storage.Store].
ChangeInformation Информация для отслеживания изменений LastUpdateLocalTS Bigint Только для внутреннего применения (используется для индексирования). Этот столбец отображается в ChangeInformation.LastUpdateLo-calTS. Нам необходимо отображать его для создания для него индекса. PathHandle [System.Storage.Store].
BinPathHandle Дескриптор пути к элементу, включающему EntityExtension

Индексы в таблице ItemExtension описаны в следующей таблице.

Таблица 12 Столбцы Уникальный Кластерный Включенные столбцы TypePath, ItemId, TypeId Да Да   ItemId, TypeId Нет Нет SDId, TombstoneStatus, PathHandle PathHandle Да Нет SDId, TombstoneStatus LastUpdateLocalTS Нет Нет SDId, TombstoneStatus, PathHandle

Все экземпляры типа ItemFragment хранятся в одной таблице, обозначаемой [System.Storage.Store].[Table!ItemFragment]. Следующая таблица раскрывает структуру типа ItemFragment.

Таблица 13 Имя столбца Тип Описание ItemId [System.Storage.Store].
ItemId ItemId содержащего элемента SetId [System.Storage.Store].
SetId Использование фрагмента элемента FragmentId [System.Storage.Store].
FragmentId Идентификатор экземпляра фрагмента ItemFragment [System.Storage.Store].
ItemFragment Объект ItemFragment TypeId [System.Storage.Store].
TypeId Схематизированный идентификатор типа TypePath Hierarchical_Type_Id Только для внутреннего применения (неизменяемый столбец) EntityState [System.Storage.Store].
EntityState UDT-атрибут EntityState, содержащий метаинформацию о фрагменте SDId int Только для внутреннего применения TombstoneStatus Int Статус неактивности ObjectSize bigint Размер объекта ItemFragment (неизменяемый столбец) ChangeInformation [System.Storage.Store].
ChangeInformation Информация для отслеживания изменений LastUpdateLocalTS bigint Только для внутреннего применения (используется для индексирования).
Этот столбец отображается в ChangeInformation.
LastUpdateLocalTS. Нам необходимо отображать его
для создания для него индекса. PathHandle [System.Storage.Store].
BinPathHandle Дескриптор пути к элементу-владельцу.

Индексы таблицы ItemFragment описаны в следующей таблице.

Таблица 14 Имя столбца Уникальный Кластерный Включенные столбцы TypePath, ItemId, SetId, FragmentId Да Да   ItemId, SetId, FragmentId Да Нет SDId, TombstoneStatus, PathHandle PathHandle Да Нет SDId, TombstoneStatus LastUpdateLocalTS Нет Нет SDId, TombstoneStatus, PathHandle

Фиг.9-10 иллюстрируют методики в соответствии с предметом изобретения. Для упрощения объяснений методики изображены и описаны как последовательность действий. Понятно и ценно то, что предмет изобретения не ограничивается проиллюстрированными действиями и/или последовательностью действий; например, действия могут производиться в различном порядке и/или одновременно и совместно с другими действиями, не представленными и описанными здесь. Более того, не проиллюстрированные действия могут потребоваться для осуществления методик в соответствии с предметом изобретения. К тому же специалисты в данной области поймут и оценят по достоинству то, что методики могут быть, как вариант, представлены в виде последовательности взаимосвязанных состояний через диаграмму состояния или событий.

Фиг.9 иллюстрирует методику 900, которая позволяет хранить экземпляры типов, которые отображаются в модель данных и/или обеспечивают запрос. Модель данных может быть моделью файловой системы хранения, допускающей хранение, нахождение и установление взаимосвязей информации. Информационный тип может быть (но не ограничивается) документом, изображением, видеозаписью, контактом, сообщением, электронным письмом, звуковым фрагментом и т.д. Эти информационные типы (например, единицы информации) могут быть представлены как экземпляры комплексных типов, являющихся частью системы типов, поддерживающей наследование, которое позволяет объектам наследовать атрибуты и/или поведение от других объектов. Важно то, что наследование может быть рассмотрено как иерархическая структура и/или формат.

На этапе 902 могут быть получены данные, которые включают в себя тип, критерии, схему, запросные критерии, …. Экземпляр типа может быть сохранен для отображения в модель данных (например, в модель файловой системы хранения) на этапе 904. Например, модель может отображать типы, описанные в схеме, в определяемые пользователем типы и объекты базы данных. Отображение хранилища может описывать объекты базы данных, которые созданы на основе схемы определения и того, каким образом экземпляры типов, описанные в схеме, хранятся и/или могут быть доступны. В данном примере структура базы данных может быть создана так, что экземпляры типов и правила отображения объявлений типов в объект базы данных, могут быть обеспечены.

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

1) найти, по меньшей мере, один элемент в модели 102 данных файловой системы, удовлетворяющий некоторому критерию;

2) найти, по меньшей мере, один документ в модели 102 данных файловой системы, удовлетворяющий конкретному критерию;

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

Фиг. 10 иллюстрирует методику 1000, позволяющую сохранять экземпляры типов и/или обеспечивать выполнение запроса. На этапе 1002 данные получают и/или принимают. Данные могут включать в себя тип, критерии, схему, запросные критерии и т.д. На этапе 1004 возможно использование процессора базы данных для обеспечения, по меньшей мере, одного механизма хранения экземпляра типа и/или выполнения запроса. Например, процессор реляционной базы данных может быть использован для обеспечения реляционного хранилища и возможности выполнения реляционного запроса. Процессор реляционной базы данных может использовать собрание элементов данных, организованных как набор формально описанных таблиц. Данные в таблицах могут быть доступны и/или перекомпонованы различными способами без требования реорганизации таблиц базы данных. Более того, реляционная база данных может быть легко расширена, например, путем добавления новых категорий без модификации существующих приложений и/или данных. На этапе 1006 сохраняют экземпляр типа, что является отображением в модель данных, причем модель данных может быть файловой системой хранения. Отображение хранилища описывает объекты базы данных, созданные на основе схемы и того, как экземпляры типов, описанных в схеме, хранятся и/или могут быть доступны. Отображение может принадлежать типу, описанному в схеме, причем такое отображение используется для пользовательских типов и объектов базы данных. На этапе 1008 может быть обеспечено выполнение запроса для нахождения, по крайней мере, одного элемента, документа и контакта. Запрос может быть использован для поиска, на основании, по меньшей мере частично, на критерии. Кроме того, на этапе 1010 представление может быть применено для (предоставления) экземпляра типа. Например, система типов может быть иерархической по структуре, причем представление может быть сформировано для предоставления любого экземпляра конкретного типа. Другими словами, из-за иерархии представление связано с заданным типом, проецирующим поднабор частных типов представления на связанные с его базовым типом.

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

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

Фиг.11 - блок-схема примера вычислительной среды 1100, с которой предмет изобретения может взаимодействовать. Система 1100 включает один или более клиентов 1110. Клиент 1110 может быть аппаратным и/или программным (например, потоки, процессы, вычислительные устройства). Система 1100 также включает один или более серверов 1120. Сервер 1120 может быть аппаратным и/или программным (например, потоки, процессы, вычислительные устройства). Серверы 1120 могут содержать потоки для выполнения преобразований, реализуемых, например, предметом изобретения.

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

На фиг.12 представлен пример среды 1200 для реализации различных аспектов изобретения, включая компьютер 1212. Компьютер 1212 включает в себя центральный процессорный блок 1214, системную память 1216 и системную шину 1218. Системная шина 1218 объединяет системные компоненты, включая (но не ограничивая ими конфигурацию системы) системную память 1216, с процессорным блоком 1214. Процессорный блок 1214 может быть любым из различных доступных процессоров. Двухъядерные микропроцессоры и другие многопроцессорные архитектуры также могут быть использованы в качестве процессорного блока 1214.

Системная шина 1218 может быть любого из нескольких типов шинных структур, включая шину памяти или контроллер памяти, периферийную шину или внешнюю шину и/или локальную шину, используя любое многообразие доступных шинных архитектур, включая (но не ограничиваясь приведенными примерами) архитектуру шины промышленного стандарта (ISA), микроканальную архитектуру (MSA), расширенную шину ISA (EISA), встроенный интерфейс накопителей (IDE), локальную шину VESA (VLB), шину межсоединения периферийных компонентов (PCI), Card Bus, универсальную последовательную шину (USB), ускоренный графический порт (AGP), шину Международной ассоциации производителей карт памяти для персональных компьютеров (PCMCIA), Firewire (IEEE 1394) и интерфейс малых вычислительных систем (SCSI).

Системная память 1216 включает в себя временную память 1220 и постоянную память 1222. Базовая система ввода-вывода (BIOS), содержащая основные подпрограммы для передачи информации между элементами компьютера 1212 (например, во время старта), хранится в постоянной памяти 1222. В иллюстративных целях (но не ограничивая применения) постоянная память 1222 может включать в себя память только для чтения (ROM), программируемую ROM (PROM), электрически программируемую ROM (EPROM), электрически стираемую программируемую ROM (EEPROM) или флэш-память. Временная память 1220 включает память с произвольным доступом (RAM), которая действует как внешняя кэш-память. Как иллюстрация, но не как ограничение, RAM доступна в различных видах, таких как статическая RAM (SRAM), динамическая RAM (DRAM), синхронная DRAM (SDRAM), SDRAM с удвоенной скоростью передачи (DDR SDRAM), расширенная SDRAM (ESDRAM), DRAM с синхронной связью (SLDRAM), RAM по технологии Direct Rambus (RDRAM), динамической RAM по технологии Direct Rambus (DRDRAM) и динамической RAM по технологии Rambus (RDRAM).

Компьютер 1212 также включает в себя съемные/несъемные, энергозависимые/энергонезависимые компьютерные носители информации. Фиг. 12 иллюстрирует для примера дисковое хранилище 1224. Дисковое хранилище 1224 включает в себя (но не ограничивается) такие устройства, как накопитель на магнитном диске, гибкий магнитный диск, ленточный накопитель, накопитель Jaz, накопитель Zip, накопитель LS-120, карты флэш-памяти или карта памяти. Дополнительно дисковое хранилище 1224 может включать в себя носители информации отдельно или в сочетании с другими носителями, включая (но не ограничиваясь приведенными) накопитель на оптических дисках, такой как устройство чтения компакт-дисков (CD-ROM), накопитель на записываемых компакт-дисках (CD-R), накопитель на перезаписываемых компакт-дисках (CD-RW) или универсальный цифровой диск (DVD-ROM). Для обеспечения связи дисковых накопителей 1224 с системной шиной обычно используется съемный или несъемный интерфейс, такой как интерфейс 1226.

Понятно, что фиг.12 описывает программное обеспечение, которое выступает как промежуточное между пользователем и основными компьютерными ресурсами, описанными в соответствующей операционной среде 1200. Такое программное обеспечение включает в себя операционную систему 1228. Операционная система 1228, которая может быть сохранена в дисковом хранилище 1224, действует с целью контроля и распределения ресурсов компьютерной системы 1212. Системные приложения 1230 пользуются преимуществами управления ресурсами операционной системой 1228 посредством программных модулей 1232 и программных данных 1234, хранящихся в системной памяти 1216 или в дисковом хранилище 1224. Понятно, что предмет изобретения может быть реализован в различных операционных системах или сочетаниях операционных систем.

Пользователь вводит команды или информацию в компьютер 1212 через устройство ввода 1236. Устройство ввода 1236 включает в себя (но не ограничивается перечисленными) указательные устройства тип мышь, трекбол, перо, сенсорная панель, клавиатура, микрофон, джойстик, игровой планшет, спутниковая антенна, сканер, плата TV тюнера, цифровой фотоаппарат, цифровая видеокамера, web-камера и т.п. Эти и другие устройства ввода соединяются с процессорным блоком 1214 через системную шину 1218 через интерфейсный порт(-ы) 1238. Интерфейсный порт(-ы) 1238 включает в себя, например, последовательный порт, параллельный порт, игровой порт универсальную последовательную шину (USB). Устройство или устройства 1240 вывода используют некоторые из тех же самых портов, что и устройства 1236 ввода. Например, USB порт может использоваться для обеспечения ввода в компьютер 1212 и для вывода информации из компьютера 1212 в устройство 1240 вывода. Выходной адаптер 1242 предоставлен для иллюстрации того, что существуют некоторые устройства 1240 вывода, такие как мониторы, громкоговорители, принтеры, которые требуют специальных адаптеров. Выходной адаптер 1242 включает в себя (только в иллюстративных целях и не ограничивая применения перечисленным) видео- и аудиокарты, которые предоставляют средства связи между выходным устройством 1240 и системной шиной 1218. Необходимо отметить, что другие устройства и/или системы устройств, например удаленный компьютер (-ы) 1244, обеспечивают возможность и ввода, и вывода.

Компьютер 1212 может работать в сетевом окружении, используя логические соединения с одним или более удаленными компьютерами, такими как удаленный компьютер(-ы) 1244. Удаленный компьютер(-ы) 1244 может являться персональным компьютером, сервером, маршрутизатором, сетевым персональным компьютером, рабочей станцией, устройством на основе микропроцессора, одноранговым устройством или другим общим сетевым узлом или подобным устройством, и обычно включает в себя многие из элементов, описанных в отношении к компьютеру 1212. В целях краткости, только запоминающее устройство 1246 показано для удаленного компьютера (-ов) 1244. Удаленный компьютер (-ы) 1244 имеет логическое соединение с компьютером 1212 через сетевой интерфейс 1248, осуществляющий проводную и/или беспроводную сеть связи, такую как локальная сеть (LAN) и глобальная сеть (WAN). Технологии LAN включают использование распределенного интерфейса передачи данных по волоконно-оптическим каналам (FDDI), распределенного интерфейса проводной передачи данных (CDDI), Ethernet, Token Ring и подобных. Технологии WAN включают (но не ограничиваются перечисленными) соединениями "точка-точка", сети с коммутацией каналов, например цифровая сеть с интегрированными услугами (ISDN) и их вариации, сети с коммутацией пакетов и цифровые абонентские линии (DSL).

Связное соединение(-я) 1250 подразумевает аппаратное/программное обеспечение, используемое для соединения сетевого интерфейса 1248 к шине 1218. В то время как соединение 1250 связи показано для иллюстративной ясности внутри компьютера 1212, оно также может быть внешним по отношению к компьютеру 1212. Аппаратное/программное обеспечение, необходимое для установления соединения с сетевым интерфейсом 1248, включает в себя (только в иллюстративных целях) внутренние и внешние технологии, такие как модемы, включающие модемы для обычных телефонных линий, кабельные модемы, DSL модемы, ISDN модемы и сетевые Ethernet карты.

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

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

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

Изобретение относится к области баз данных. Техническим результатом является облегчение доступа к объектам баз данных. Раскрываются система и/или способ, позволяющие отображать модель базы данных в объект базы данных. Система хранения типов может использовать отображение хранилища модели данных файлового хранилища. Отображение может описывать объект базы данных, созданный, по меньшей мере, частично, на основе схемы и того, каким образом экземпляры типов, описанные в схеме, хранятся и/или могут быть доступны. Более того, может быть выполнен запрос на нахождение, по меньшей мере, одного из следующего: элемент, документ и/или контакт, которые удовлетворяют, по меньшей мере, одному критерию. Система хранения типов может через интерфейс принимать данные для обеспечения их хранения и выполнения запроса, причем данные принадлежат одному из следующих видов: схема, модель данных, запрос, запросные критерии. Дополнительно система хранения типов может генерировать представление, раскрывающее, по крайней мере, один экземпляр типа. 3 н. и 9 з.п. ф-лы, 12 ил., 14 табл.

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

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

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

4. Носитель по п.3, в котором реляционный компонент использует технологии реляционных баз данных, и который представляет собой совокупность элементов данных, организованных в виде набора формально описанных таблиц, в которых данные могут быть по меньшей мере одним из: доступны без реорганизации либо повторно собраны без реорганизации.

5. Носитель по п.1, в котором отображение описывает по меньшей мере один из объектов базы данных, созданный на основе упомянутой схемы и то, как экземпляр типа, описанный в этой схеме, хранится или доступен.

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

7. Носитель по п.1, в котором тип содержит по меньшей мере одно из следующего: иерархию типов и наследование.

8. Носитель по п.6, в котором компонент представления вызывает пользовательский интерфейс для взаимодействия между пользователем и компонентом хранения типа.

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

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

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

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