ОТОБРАЖЕНИЕ МОДЕЛИ ФАЙЛОВОЙ СИСТЕМЫ В ОБЪЕКТ БАЗЫ ДАННЫХ
MAPPING SYSTEM MODEL TO DATABASE OBJECT

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ
Представленное изобретение, в целом, относится к базам данных, и в частности к системам и/или методам, способствующим сохранению экземпляра типа данных и/или выполнению запроса данных.
УРОВЕНЬ ТЕХНИКИ ИЗОБРЕТЕНИЯ
Достижения в компьютерных технологиях (например, быстродействие микропроцессоров, объем памяти, скорость передачи данных, функциональность программного обеспечения и т.п.) внесли значительный вклад в расширение применения компьютерной техники в различных отраслях. Еще более мощные серверные системы, которые часто представляют массив серверов, обычно обслуживают запросы, исходящие от внешних источников, например, таких как 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 может предоставить заключение о и/или предположить состояние системы, среды и/или пользователя, исходя из набора данных наблюдений, которые получены через события и/или данные. Вывод может быть использован для идентификации специфического контекста действия или, например, может выдавать вероятность распределения состояний. Вывод может быть вероятностным, то есть расчет вероятности распределения по интересующим состояниям на основе рассмотрения данных и событий. Вывод также может обращаться к методам, используемым для формирования высокоуровневых событий из набора событий и/или данных. Такие выводы приводят к созданию новых событий или действий из набора наблюдаемых событий и/или сохраненных данных о событии, независимо от того, коррелированны или нет эти события во времени и имеют ли эти события и данные один или несколько источников данных и событий. Различные классификационные (явно или неявно сформированные) схемы и/или системы (например, машины опорных векторов, нейронные сети, экспертные системы, Байесовские сети доверия, нечеткая логика, механизмы слияния данных …) могут быть использованы в связи с проведением автоматических и/или предполагаемых действий, связанных с предметом изобретения.
xn)
confidence(class).
Классификатор - это функция, которая отображает входной вектор x=(x1, x2, x3, x4,  атрибутов в достоверность того, что входные данные принадлежит классу, то есть f(x)= Такая классификация может использовать вероятностный или статистический анализ (например, разложение на утилиты анализа и затраты) для прогнозирования или предположения действия, которое пользователь желает выполнить автоматически. Машины опорных векторов (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<sup>31</sup> символов. Длина может быть зафиксирована в диапазоне 1-4000 символов или неограниченной при использовании
Двоичный (Binary)
SqlBinary
Двоичные данные переменной длины с максимальной длиной 2<sup>32</sup> байт. Длина может быть зафиксирована в диапазоне 1-8000 байт или неограниченной при использовании ключевого слова «max».
Булевский (Boolean)
SqlBoolean
Обнуляемая Булевская величина
Байт (Byte)
SqlByte
Одинарный байт без знака.
Целый, 16 бит (Int16)
SqlInt16
Целочисленные данные в диапазоне от -2<sup>15</sup> (-32,768) до 2<sup>15</sup> - 1 (32,767).
Целый, 32 бит (Int32)
SqlInt32
Целочисленные (целое число) данные от -2<sup>31</sup> (-2,147,483,648) до 2<sup>3I</sup> -1 (2,147,483,647).
Целый, 64 бит (Int64)
SqlInt64
Целочисленные (целое число) данные от -2<sup>63</sup> (-9223372036854775808) до 2<sup>63</sup>-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 карты.
Все это было описано выше вместе с примерами предмета изобретения. Конечно, невозможно описать все вероятные сочетания компонентов и методик при описании предмета изобретения, однако специалисты в данной области могут понять, что многие другие сочетания и перестановки возможны в рамках предмета изобретения. Соответственно предмет изобретения подразумевает охват всех таких изменений, модификаций и вариаций, которые попадают в сферу охвата прилагающихся пунктов патентной формулы.
В частности и принимая во внимание различные функции, выполняемые вышеописанными компонентами, устройствами, схемами, системами и т.п., понятия (включая ссылки на «средства»), используемые при описании этих компонентов подразумеваются одинаковыми, кроме отдельно оговоренных случаев, для любого компонента, выполняющего функцию, проиллюстрированную примерами аспектов изобретения. Принимая это во внимание, также очевидно, что изобретение включает в себя систему, также как и компьютерные носители информации, содержащие исполняемые компьютером инструкции для выполнения действий и/или результатов различных методов изобретения.
В дополнение, так как частные особенности изобретения могут быть раскрыты по отношению только к одному из нескольких реализаций, то эти особенности могут комбинироваться с одной или более особенностями других реализаций как желаемые и выгодные для любого заданного отдельно применения. Более того, для расширения понятий «включать» и «включающий» и их используемых вариантов, как в детальном описании, так и в пунктах патентной формулы, эти понятия подразумевают включение в способ, подобный терминам «содержащий», «включающий в себя», «состоящий из».