Отображение модели файловой системы в объект базы данных

Отображение модели файловой системы в объект базы данных

Иллюстрации

Показать все

Реферат

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

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

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

Достижения в компьютерных технологиях (например, быстродействие микропроцессоров, объем памяти, скорость передачи данных, функциональность программного обеспечения и т.п.) внесли значительный вклад в расширение применения компьютерной техники в различных отраслях. Еще более мощные серверные системы, которые часто представляют массив серверов, обычно обслуживают запросы, исходящие от внешних источников, например, таких как 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 переменной длины с максимальной длиной 231 символов. Длина может быть зафиксирована в диапазоне 1-4000 символов или неограниченной при использовании
Двоичный (Binary)	SqlBinary	Двоичные данные переменной длины с максимальной длиной 232 байт. Длина может быть зафиксирована в диапазоне 1-8000 байт или неограниченной при использовании ключевого слова «max».
Булевский (Boolean)	SqlBoolean	Обнуляемая Булевская величина
Байт (Byte)	SqlByte	Одинарный байт без знака.
Целый, 16 бит (Int16)	SqlInt16	Целочисленные данные в диапазоне от -215 (-32,768) до 215 - 1 (32,767).
Целый, 32 бит (Int32)	SqlInt32	Целочисленные (целое число) данные от -231 (-2,147,483,648) до 23I -1 (2,147,483,647).
Целый, 64 бит (Int64)	SqlInt64	Целочисленные (целое число) данные от -263 (-9223372036854775808) до 263-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, и «диапазон» зафикс