Системы и способы моделирования данных в основанной на предметах платформе хранения

Системы и способы моделирования данных в основанной на предметах платформе хранения

Иллюстрации

Показать все

Реферат

Перекрестная ссылка

Настоящая заявка относится к предмету изобретений, описанному в следующих заявках с передачей права на совместное использование: заявка на патент США № (еще не назначен) (реестр поверенного № MSFT-1748), дата подачи которой одинакова с датой подачи настоящей заявки, озаглавленная «SYSTEMS AND METHODS FOR REPRESENTING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM BUT INDEPENDENT OF PHYSICAL REPRESENTATION» (Системы и способы представления единиц информации, управляемых аппаратной/программной интерфейсной системой, но независимых от физического представления); заявка на патент США № (еще не назначен) (реестр поверенного № MSFT-1749), дата подачи которой одинакова с датой подачи настоящей заявки, озаглавленная «SYSTEMS AND METHODS FOR SEPARATING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM FROM THEIR PHYSICAL ORGANIZATION» (Системы и способы отделения единиц информации, управляемых аппаратной/программной интерфейсной системой, от их физической организации); заявка на патент США № (еще не назначен) (реестр поверенного № MSFT-1750), дата подачи которой одинакова с датой подачи настоящей заявки, озаглавленная «SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A BASE SCHEMA FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM» (Системы и способы реализации базовой схемы для организации единиц информации, управляемых аппаратной/программной интерфейсной системой); заявка на патент США № (еще не назначен) (реестр поверенного № MSFT-1751), дата подачи которой одинакова с датой подачи настоящей заявки, озаглавленная «SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A CORE SCHEMA FOR PROVIDING A TOP-LEVEL STRUCTURE FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM» (Системы и способы реализации основной схемы для обеспечения структуры верхнего уровня для организации единиц информации, управляемых аппаратной/программной интерфейсной системой); заявка на патент США № (еще не назначен) (реестр поверенного № MSFT-1752), дата подачи которой одинакова с датой подачи настоящей заявки, озаглавленная «SYSTEMS AND METHOD FOR REPRESENTING RELATIONSHIPS BETWEEN UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM» (Системы и способы представления связей между единицами информации, управляемыми аппаратной/программной интерфейсной системой); заявка на патент США № (еще не назначен) (реестр поверенного № MSFT-2733), дата подачи которой одинакова с датой подачи настоящей заявки, озаглавленная «SYSTEMS AND METHODS FOR INTERFACING APPLICATION PROGRAMS WITH AN ITEM-BASED STORAGE PLATFORM» (Системы и способы сопряжения программ приложения с основанной на предметах платформой хранения); и заявка на патент США № (еще не назначен) (реестр поверенного № MSFT-2734), дата подачи которой одинакова с датой подачи настоящей заявки, озаглавленная «STORAGE PLATFORM FOR ORGANIZING, SEARCHING, AND SHARING DATA» (Платформа хранения для организации, поиска и совместного использования данных).

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

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

Предшествующий уровень техники

Емкость индивидуального диска увеличивалась примерно на семьдесят процентов (70%) в год в течение последнего десятилетия. Закон Мура точно предсказал огромное увеличение мощности центрального процессора (ЦП; CPU), которое произошло за эти годы. Проводные и беспроводные технологии обеспечили широкие возможности подключения и полосу частот. Предполагается, что данная тенденция будет продолжаться, в течение нескольких лет средний портативный компьютер будет обрабатывать примерно один терабайт (Тбайт) памяти и содержать миллионы файлов, и станут обычным явлением накопители емкостью 500 гигабайт (Гбайт).

Потребители используют свои компьютеры, главным образом, для установления связи и организации персональной информации, является ли она данными традиционного стиля персональной информационной системы (ПИС; PIM) или мультимедиа, такой как цифровая музыка или фотографии. Значительно увеличились количество цифрового содержимого и возможности хранения необработанных байтов; однако отстали способы, доступные для потребителей, для организации и унификации этих данных. Специалисты в области анализа и обработки информации тратят огромное количество времени на управление и совместное использование информации, и некоторые исследования дают оценку, что специалисты в области анализа и обработки информации тратят 15-25% своего времени на непродуктивную деятельность, относящуюся к информации. Другие исследования дают оценку, что типичный специалист в области анализа и обработки информации тратит примерно 2,5 часа в день на поиск информации.

Разработчики и отделы информационных технологий (ИТ; IT) инвестируют значительное количество времени и денег на построение своих собственных хранилищ данных для общих абстракций хранения для представления таких вещей, как люди, места, времена и события. Это не только приводит к дублированию работы, но это также создает области общих данных без механизмов общего поиска или совместного использования этих данных. Только подумайте, сколько адресных книг может существовать сегодня на компьютере, работающем под операционной системой Microsoft Windows. Многие приложения, такие как клиенты электронной почты и программы персональных финансов, сопровождают индивидуальные адресные книги, и существует незначительное совместное использование среди приложений данных адресных книг, которые каждая такая программа индивидуально сопровождает. Следовательно, программа финансов (подобно Microsoft Money) не использует совместно адреса для получателей платежа с адресами, поддерживаемыми в папке контактов электронной почты (подобно папке в Microsoft Outlook). В самом деле, многие пользователи имеют множество устройств и логически должны синхронизировать свои персональные данные между собой и с многочисленными дополнительными источниками, включая от сотовых телефонов до коммерческих служб, таких как служба MSN (Microsoft Support Network) и AOL (America Online); тем не менее, координация совместно используемых документов в значительной степени достигается присоединением документов к сообщениям электронной почты, т.е. вручную и не эффективно.

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

Однако, хотя обеспечивая приемлемое представление информации, постоянно находящейся в физической системе хранения компьютера, файловая система, тем не менее, является абстракцией этой физической системы хранения, и поэтому использование файлов требует некоторого уровня косвенности (интерпретации) между тем, чем манипулирует пользователь (единицы, имеющие контекст, особенности и связи с другими единицами), и тем, что предоставляет операционная система (файлы, папки и каталоги). Следовательно, у пользователя (приложений и/или конечных пользователей) нет выбора, как загружать единицы информации в структуру файловой системы, даже когда это выполнение является неэффективным, несовместимым или иным образом нежелательным. Кроме того, у существующих файловых систем мало сведений о структуре данных, хранимых в индивидуальных файлах, и из-за этого большая часть информации остается заблокированной в файлах, к которым могут обращаться (и они могут быть понятны) только приложения, которые их записали. Следовательно, это отсутствие схематического описания информации и механизмов управления информацией приводит к созданию бункеров данных с малым совместным использованием данных между индивидуальными бункерами. Например, многие пользователи персональных компьютеров (ПК) имеют более пяти отдельных хранилищ, которые содержат информацию о людях, с которыми они взаимодействуют на некотором уровне, например контакты Outlook, получатели онлайновых счетов, адресная книга Windows, получатели платежа Quicken и списки контактных лиц мгновенного обмена сообщениями (МОС; IM), так как организация файлов представляет сложную проблему для этих пользователей ПК. Так как большинство существующих файловых систем используют модельное представление вложенных папок для организации файлов и папок, когда увеличивается количество файлов, объем работ, необходимых для сопровождения схемы организации, которая является гибкой и эффективной, становится совершенно огромным. В таких ситуациях было бы очень полезным иметь множество классификаций одного файла; однако использование жесткого и гибкого связывания в существующих файловых системах является затруднительным и трудным для поддержки.

В прошлом было предпринято несколько неуспешных попыток обращения к недостаткам файловых систем. Некоторые из этих предыдущих попыток включали в себя использование ассоциативной памяти для обеспечения механизма, посредством которого к данным можно было обращаться по содержимому, а не по физическому адресу. Однако эти усилия оказались неуспешными, так как, хотя ассоциативная память оказалась полезной для маломасштабного применения устройствами, такими как кэши и блоки управления памятью, крупномасштабное использование для устройств, таких как физические носители данных, не было все же возможным по многочисленным причинам, и, таким образом, такое решение просто не существует. Были предприняты другие попытки, использующие системы объектно-ориентированных баз данных (ООБД; OODB), но эти попытки, хотя характеризовались определенными характеристиками баз данных и хорошими нефайловыми представлениями, не были эффективными в обработке файловых представлений и не могли повторять быстродействие, эффективность и простоту иерархической структуры, основанной на файлах и папках, на уровне аппаратной/программной интерфейсной системы. Другие усилия, такие как те, которые пытались использовать SmallTalk (и другие модификации), оказались довольно эффективными при оперировании файловыми и нефайловыми представлениями, но в них отсутствовали особенности баз данных, необходимые для эффективной организации и использования связей, которые существуют между различными файлами данных, и, таким образом, была неприемлемой общая эффективность таких систем. Еще другие попытки использования BeOS (и другие исследования таких операционных систем) оказались неподходящими при оперировании нефайловыми представлениями - основное упущение, одинаковое для традиционных файловых систем, несмотря на способность адекватно представлять файлы, в то же время обеспечивать некоторые необходимые особенности баз данных.

Технология баз данных представляет собой другую область техники, в которой существуют подобные сложные проблемы. Например, хотя модель реляционных баз данных имела большой коммерческий успех, в действительности независимые поставщики программного обеспечения (НППО; ISV), в основном, используют малую часть функциональных возможностей, доступных в программных продуктах реляционных баз данных (таких как Microsoft SQL Server). Вместо этого большая часть взаимодействия приложения с таким продуктом происходит в виде простых «gets» и «puts». Хотя существует ряд легко различимых причин для этого, такие как агностические в отношении платформы или базы данных, одной ключевой причиной, которая часто остается незамеченной, является то, что база данных необязательно обеспечивает точную абстракцию, в чем действительно нуждаются главные поставщики бизнес-приложений. Например, хотя реальный мир имеет понятие о «предметах», таких как «потребители» или «заказы» (вместе с внедренными в заказ «предметными позициями» в качестве предметов самих в себе или самих по себе), реляционные базы данных общаются только на языке таблиц и строк. Следовательно, хотя приложению может быть необходимо иметь аспекты совместимости, блокировки, безопасности и/или триггеров на уровне предметов (указав несколько), базы данных, в основном, предоставляют эти особенности только на уровне таблиц/строк. Хотя это может работать хорошо, если каждый предмет отображается на одну строку в некоторой таблице в базе данных, в случае заказа с многочисленными предметными позициями могут быть причины, почему предмет фактически отображается на многочисленные таблицы, и, когда это так, простая система реляционной базы данных совершенно не предоставляет правильных абстракций. Следовательно, приложение должно строить логику поверх базы данных, чтобы обеспечить эти базовые абстракции. Другими словами, базовая реляционная модель не обеспечивает достаточную платформу для хранения данных, на которой легко могут разрабатываться приложения более высокого уровня, так как базовая реляционная модель требует уровня косвенности между приложением и системой хранения, где семантическая структура данных может быть видимой только в приложении в некоторых случаях. Хотя некоторые поставщики баз данных встраивают функциональные возможности более высокого уровня в свои продукты, такие как предоставление объектно-реляционных возможностей, новых организационных моделей и т.п., никто еще не предоставил вид комплексного решения, необходимый там, где действительно комплексное решение представляет собой решение, которое предоставляет обе полезные абстракции модели данных (такие как «Предметы», «Расширения», «Связи» и т.п.) для полезных абстракций доменов (таких как «Личности», «Расположения», «События» и т.д.).

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

Сущность изобретения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

фиг.2А иллюстрирует традиционную иерархическую структуру на основе дерева для файлов, сгруппированных в папки в каталоге в основанной на файлах операционной системе;

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

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

фиг.5А представляет собой блок-схему, иллюстрирующую структуру Предмета;

фиг.5В представляет собой блок-схему, иллюстрирующую составные типы свойств Предмета по фиг.5А;

фиг.5С представляет собой блок-схему, иллюстрирующую Предмет «Location», в котором дополнительно описываются (явно перечисляются) его составные типы;

фиг.6А иллюстрирует Предмет в качестве подтипа Предмета, определяемого в Базовой Схеме;

фиг.6В представляет собой блок-схему, иллюстрирующую подтип Item по фиг.6А, в котором его унаследованные типы явно перечисляются (в дополнение к ее непосредственным свойствам);

фиг.7 представляет собой блок-схему, иллюстрирующую Базовую Схему, включающую в себя ее два типа класса верхнего уровня, Item и PropertyBase, и дополнительные типы Базовой Схемы, выведенные из них;

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

фиг.8В представляет собой блок-схему, иллюстрирующую типы свойств в Основной Схеме;

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

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

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

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

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

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

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

фиг.16 иллюстрирует примерное дерево каталогов;

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

фиг.18 иллюстрирует принцип Папок Включений согласно аспекту настоящего изобретения;

фиг.19 иллюстрирует базовую архитектуру ИПП (API) платформы хранения;

фиг.20 схематически представляет различные компоненты стека ИПП (API) платформы хранения;

фиг.21А и 21В представляют собой графические представления примерной схемы Контактов (Предметы и Элементы);

фиг.22 иллюстрирует интегрированную среду выполнения (runtime framework) ИПП (API) платформы хранения согласно аспекту настоящего изобретения;

фиг.23 иллюстрирует исполнение операции FindAll согласно варианту осуществления настоящего изобретения;

фиг.24 иллюстрирует процесс, посредством которого классы ИПП (API) платформы хранения генерируются из Схемы платформы хранения согласно аспекту настоящего изобретения;

фиг.25 иллюстрирует схему, на которой основан ИПП (API) Файла согласно другому аспекту настоящего изобретения;

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

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

фиг.28 представляет собой схему, иллюстрирующую принцип представления поиска Предмета, согласно варианту осуществления одного аспекта настоящего изобретения; и

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

Подробное описание изобретения

СОДЕРЖАНИЕ

I. ВВЕДЕНИЕ

А. ПРИМЕРНАЯ ВЫЧИСЛИТЕЛЬНАЯ СРЕДА

В. ТРАДИЦИОННОЕ ОСНОВАННОЕ НА ФАЙЛАХ ХРАНЕНИЕ

II. НОВАЯ ПЛАТФОРМА ХРАНЕНИЯ ДЛЯ ОРГАНИЗАЦИИ, ПОИСКА И СОВМЕСТНОГО ИСПОЛЬЗОВАНИЯ ДАННЫХ

А. СЛОВАРЬ

В. ОБЗОР ПЛАТФОРМЫ ХРАНЕНИЯ

С. МОДЕЛЬ ДАННЫХ

1. Предметы

2. Идентификация предметов

а) Ссылки на предмет

(1) ItemIDReference

(2) ItemPathReference

b) Иерархия ссылочного типа

3. Папки и категории предметов

4. Схемы

а) Базовая схема

b) Основная схема

5. Связи

а) Объявление связи

b) Связь прикрепления

с) Связи внедрения

d) Связи ссылки

е) Правила и ограничения

f) Упорядочение связей

6. Расширяемость

а) Расширения предмета

b) Расширения типов NestedElement

D. ПРОЦЕССОР БАЗЫ ДАННЫХ

1. Реализация хранилища данных, используя определяемые пользователем типы (ОПТ; UDT)

2. Отображение предметов

3. Отображение расширений

4. Отображение вложенных элементов

5. Идентификация объектов

6. Именование объектов языка структурированных запросов (ЯСЗ; SQL)

7. Именование столбцов

8. Представления поиска

а) Предмет

(1) Главное представление поиска предметов

(2) Типизированные представления поиска предметов

b) Расширения предметов

(1) Главное представление поиска расширений

(2) Типизированные представления поиска расширений

с) Вложенные элементы

d) Связи

(1) Главное представление поиска связей

(2) Представления поиска экземпляров связи

9. Обновления

10. Отслеживание изменений и объекты-памятники

а) Отслеживание изменений

(1) Отслеживание изменений в «главных» представлениях поиска

(2) Отслеживание изменений в «типизированных» представлениях поиска

b) Объекты-памятники

(1) Объекты-памятники предметов

(2) Объекты-памятники расширений

(3) Объект-памятник связей

(4) Очистка объектов-памятников

11. Вспомогательный ИПП (API) и функции

а) Функция [System.Storage].GetItem

b) Функция [System.Storage].GetExtension

с) Функция [System.Storage].GetRelationship

12. Метаданные

а) Метаданные схемы 75

b) Метаданные экземпляра 75

Е. ЗАЩИТА

1. Обзор

2. Подробное описание модели защиты

а) Структура дескриптора защиты

(1) Формат маски доступа

(2) Обобщенные права доступа

(3) Стандартные права доступа

b) Характерные для предмета права

(1) Характерные для объекта права файла и каталога

(2) WinFSItemRead

(3) WinFSItemReadAttributes 86

(4) WinFSItemWriteAttribute

(5) WinFSItemWrite

(6) WinFSItemAddLink

(7) WinFSItemDeleteLink

(8) Права на удаление предмета

(9) Права на копирование предмета

(10) Права на перемещение предмета

(11) Права на просмотр политики безопасности на предмет

(12) Права на изменение политики безопасности на предмет

(13) Права, которые не имеют прямого эквивалента

3. Реализация

а) Создание нового предмета в контейнере

b) Добавление явного списка управления доступом (СУД; ACL) к предмету

с) Добавление связи прикрепления к предмету

d) Удаление связи прикрепления из предмета

е) Удаление явного СУД (ACL) из предмета

f) Модифицирование СУД (ACL), ассоциированного с предметом

F. УВЕДОМЛЕНИЯ И ОТСЛЕЖИВАНИЕ ИЗМЕНЕНИЙ

1. События изменения хранения

а) События

b) Наблюдатели

2. Механизм отслеживания изменений и генерирования уведомлений

а) Отслеживание изменений

b) Управление временными метками

с) Обнаружение изменения даты - обнаружение событий

G. СИНХРОНИЗАЦИЯ

1. Синхронизация платформы хранения с платформой хранения

а) Приложения управления синхронизацией

b) Аннотирование схем

с) Конфигурация синхронизации

(1) Папка сообщества - отображения

(2) Профили

(3) Расписания

d) Оперирование конфликтами

(1) Обнаружение конфликтов

(а) Основанные на сведениях конфликты

(b) Основанные на ограничениях конфликты

(2) Обработка конфликтов

(а) Автоматическое разрешение конфликтов

(b) Регистрация конфликтов

(с) Инспектирование и разрешение конфликтов

(d) Слияние реплик и распространение разрешений конфликтов

2. Синхронизация с хранилищами данных не платформы хранения

а) Службы синхронизации

(1) Перечисление изменений

(2) Применение изменений

(3) Разрешение конфликтов

b) Реализация адаптера

3. Защита

4. Управляемость

H. ВОЗМОЖНОСТЬ ВЗАИМОДЕЙСТВИЯ С ТРАДИЦИОННЫМИ ФАЙЛОВЫМИ СИСТЕМАМИ

1. Модель для возможности взаимодействия

2. Особенности хранилища данных

а) Не том

b) Структура хранилища

с) Не все файлы мигрируют

d) Доступ пространства имен файловой системы новой технологии (ФСНТ; NTFS) к файлам платформы хранения

е) Ожидаемые буквы пространства имен/накопителя

I. ИПП (API) ПЛАТФОРМЫ ХРАНЕНИЯ

1. Обзор

2. Именование и области действия

3. Компоненты ИПП (API) платформы хранения

4. Классы данных

5. Интегрированная среда выполнения

а) Классы интегрированной среды выполнения

(1) ItemContext

(2) ItemSearcher

(а) Тип цели

(b) Фильтры

(с) Подготовка поисков

(d) Варианты поиска

(3) Поток результатов предметов («FindResult»)

b) Интегрированная среда выполнения в работе

с) Общие шаблоны программирования

(1) Открытие и закрытие объектов ItemContext

(2) Поиск объектов

(а) Варианты поиска

(b) FindOne и FindOnly

(с) Краткие формы поиска по ItemContext

(d) Поиск по идентификатору (ИД; ID)) или пути

(е) Шаблон GetSearcher

(3) Обновление хранилища

6. Защита

7. Поддержка связей

а) Базовые типы связей

(1) Класс Relationship

(2) Класс ItemReference

(3) Класс ItemIdReference

(4) Класс ItemPathReference

(5) Структура RelationshipId

(6) Класс VirtualRelationshipCollection

b) Генерируемые типы связей

(1) Генерируемые типы связей

(2) Класс RelationshipPrototype

(3) Класс RelationshipPrototypeCollection

с) Поддержка связей в классе Item

(1) Класс Item

(2) Класс RelationshipCollection

d) Поддержка связей в выражениях поиска

(1) Прохождение от предметов к связям

(2) Прохождение от связей к предметам

(3) Объединение прохождения связи

е) Примеры использования поддержки связей

(1) Поиск связей

(2) Навигация от связи к предметам источника и цели

(3) Навигация от предметов источника к связям

(4) Создание связей (и предметов)

(5) Удаление связей (и предметов)

8. «Расширение» ИПП (API) платформы хранения

а) Методы поведения домена

b) Дополнительные методы поведения

с) Дополнительные методы поведения в качестве поставщиков служб

9. Интегрированная среда периода проектирования

10. Формализм запроса

а) Основы фильтров

b) Приведение типов

с) Синтаксис фильтра

11. Удаленное взаимодействие

а) Локальная/удаленная прозрачность в ИПП (API)

b) Реализация платформой хранения удаленного взаимодействия

с) Доступ к хранилищам не платформы хранения

d) Связь с распределенной файловой системой (РФС; DFS)

е) Связь с глобальной архитектурой расширяемого языка разметки (ГАР; GXA)/Indigo

12. Ограничения

13. Совместное использование

а) Представление совместно используемого ресурса

b) Управление совместно используемыми ресурсами

с) Доступ к совместно используемым ресурсам

d) Обнаруживаемость

14. Семантика Find

15. ИПП (API) контактов платформы хранения

а) Обзор System.Storage.Contact

b) Методы поведения доменов

16. ИПП (API) файла платформы хранения

а) Введение

(1) Отражение тома ФСНТ (NTFS) в платформе хранения

(2) Создание File и Directory в пространстве имен платформы хранения

b) Схема файла

с) Обзор System.Storage.Files

d) Примеры кода

(1) Открытие файла и запись в него

(2) Использование запросов

е) Методы поведения доменов

J. ЗАКЛЮЧЕНИЕ

I. ВВЕДЕНИЕ

Предмет настоящего изобретения