Системы и способы расширений и наследования для блоков информации, управляемых системой аппаратно-программного интерфейса

Системы и способы расширений и наследования для блоков информации, управляемых системой аппаратно-программного интерфейса

Иллюстрации

Показать все

Реферат

Перекрестные ссылки на родственные заявки

Данная заявка испрашивает приоритет патентной заявки США № 10/693,574 (реестр поверенного № MSFT-2847), поданной 24 октября 2003 г., на «СИСТЕМЫ И СПОСОБЫ РАСШИРЕНИЙ И НАСЛЕДОВАНИЯ ДЛЯ БЛОКОВ ИНФОРМАЦИИ, УПРАВЛЯЕМЫХ СИСТЕМОЙ АППАРАТНО-ПРОГРАММНОГО ИНТЕРФЕЙСА»; патентной заявки США № 10/646,580 (реестр поверенного № MSFT-2735), поданной 21 августа 2003 г., на «СИСТЕМЫ И СПОСОБЫ ДЛЯ МОДЕЛИРОВАНИЯ ДАННЫХ В ПЛАТФОРМЕ ХРАНЕНИЯ НА ОСНОВЕ ЭЛЕМЕНТОВ ДАННЫХ»; и Международной патентной заявки № PCT/US 03/26144 (реестр поверенного № MSFT-2779), поданной 21 августа 2003 г., на «СИСТЕМЫ И СПОСОБЫ ДЛЯ МОДЕЛИРОВАНИЯ ДАННЫХ В ПЛАТФОРМЕ ХРАНЕНИЯ НА ОСНОВЕ ЭЛЕМЕНТОВ ДАННЫХ»; содержание которых включено в данное описание изобретения посредством ссылки.

Заявка относится к сущности изобретений, раскрытых в следующих совместно переуступленных заявках, содержание которых включено посредством ссылки в настоящую заявку во всей полноте (и частично суммировано здесь для удобства): патентная заявка США № 10/647,058 (реестр поверенного № MSFT-1748), поданная 21 августа 2003 г., на «СИСТЕМЫ И СПОСОБЫ ДЛЯ ПРЕДСТАВЛЕНИЯ БЛОКОВ ИНФОРМАЦИИ ПОД УПРАВЛЕНИЕМ СИСТЕМЫ АППАРАТНО/ПРОГРАММНОГО ИНТЕРФЕЙСА, НО НЕЗАВИСИМО ОТ ФИЗИЧЕСКОГО ПРЕДСТАВЛЕНИЯ»; патентная заявка США № 10/646,941 (реестр поверенного № MSFT-1749), поданная 21 августа 2003 г., на «СИСТЕМЫ И СПОСОБЫ ДЛЯ ОТДЕЛЕНИЯ БЛОКОВ ИНФОРМАЦИИ, УПРАВЛЯЕМЫХ СИСТЕМОЙ АППАРАТНО/ПРОГРАММНОГО ИНТЕРФЕЙСА, ОТ ИХ ФИЗИЧЕСКОЙ ОРГАНИЗАЦИИ»; патентная заявка США № 10/646,940 (реестр поверенного № MSFT-1750), поданная 21 августа 2003 г., на «СИСТЕМЫ И СПОСОБЫ ДЛЯ РЕАЛИЗАЦИИ БАЗОВОЙ СХЕМЫ ДЛЯ ОРГАНИЗАЦИИ БЛОКОВ ИНФОРМАЦИИ, УПРАВЛЯЕМЫХ СИСТЕМОЙ АППАРАТНО/ПРОГРАММНОГО ИНТЕРФЕЙСА»; патентная заявка США № 10/646,632 (реестр поверенного № MSFT-1751), поданная 21 августа 2003 г., на «СИСТЕМЫ И СПОСОБЫ ДЛЯ РЕАЛИЗАЦИИ СХЕМЫ ЯДРА ДЛЯ ОБЕСПЕЧЕНИЯ СТРУКТУРЫ ВЕРХНЕГО УРОВНЯ ДЛЯ ОРГАНИЗАЦИИ БЛОКОВ ИНФОРМАЦИИ, УПРАВЛЯЕМЫХ СИСТЕМОЙ АППАРАТНО/ПРОГРАММНОГО ИНТЕРФЕЙСА»; патентная заявка США № 10/646,645 (реестр поверенного № MSFT-1752), поданная 21 августа 2003 г., на «СИСТЕМЫ И СПОСОБ ДЛЯ ПРЕДСТАВЛЕНИЯ ОТНОШЕНИЙ МЕЖДУ БЛОКАМИ ИНФОРМАЦИИ, УПРАВЛЯЕМЫМИ СИСТЕМОЙ АППАРАТНО/ПРОГРАММНОГО ИНТЕРФЕЙСА»; патентная заявка США № 10/646,575 (реестр поверенного № MSFT-2733), поданная 21 августа 2003 г., на «СИСТЕМЫ И СПОСОБЫ ДЛЯ ВЗАИМОДЕЙСТВИЯ ПРИКЛАДНЫХ ПРОГРАММ С ПЛАТФОРМОЙ ХРАНЕНИЯ НА ОСНОВЕ ЭЛЕМЕНТОВ ДАННЫХ»; патентная заявка США № 10/646,646 (реестр поверенного № MSFT-2734), поданная 21 августа 2003 г., на «ПЛАТФОРМУ ХРАНЕНИЯ ДЛЯ ОРГАНИЗАЦИИ, ПОИСКА И СОВМЕСТНОГО ИСПОЛЬЗОВАНИЯ ДАННЫХ»; патентная заявка США № 10/692,779 (реестр поверенного № MSFT-2829), поданная 24 октября 2003 г., на «СИСТЕМЫ И СПОСОБЫ ДЛЯ РЕАЛИЗАЦИИ СХЕМЫ ЦИФРОВЫХ ИЗОБРАЖЕНИЙ ДЛЯ ОРГАНИЗАЦИИ БЛОКОВ ИНФОРМАЦИИ, УПРАВЛЯЕМЫХ СИСТЕМОЙ АППАРАТНО/ПРОГРАММНОГО ИНТЕРФЕЙСА»; патентная заявка США № 10/692,515 (реестр поверенного № MSFT-2844), поданная 24 октября 2003 г., на «СИСТЕМЫ И СПОСОБЫ ДЛЯ ОБЕСПЕЧЕНИЯ УСЛУГ СИНХРОНИЗАЦИИ ДЛЯ БЛОКОВ ИНФОРМАЦИИ, УПРАВЛЯЕМЫХ СИСТЕМОЙ АППАРАТНО/ПРОГРАММНОГО ИНТЕРФЕЙСА»); патентная заявка США № 10/692,508 (реестр поверенного № MSFT-2845), поданная одновременно с данной на «СИСТЕМЫ И СПОСОБЫ ДЛЯ ОБЕСПЕЧЕНИЯ РЕЛЯЦИОННЫХ И ИЕРАРХИЧЕСКИХ УСЛУГ СИНХРОНИЗАЦИИ ДЛЯ БЛОКОВ ИНФОРМАЦИИ, УПРАВЛЯЕМЫХ СИСТЕМОЙ АППАРАТНО/ПРОГРАММНОГО ИНТЕРФЕЙСА»; и патентная заявка США № 10/693,362 (реестр поверенного № MSFT-2846), поданная 24 октября 2003 г., на «СИСТЕМЫ И СПОСОБЫ ДЛЯ РЕАЛИЗАЦИИ СХЕМ СИНХРОНИЗАЦИИ ДЛЯ БЛОКОВ ИНФОРМАЦИИ, УПРАВЛЯЕМЫХ СИСТЕМОЙ АППАРАТНО/ПРОГРАММНОГО ИНТЕРФЕЙСА».

Область техники

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На чертежах

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

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

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

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

фиг.4 - иллюстрирует структурное отношение между Статьями, Папками статей и Категориями;

фиг.5А - блок-схема, иллюстрирующая структуру Статьи;

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

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

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

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

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

фиг.8А - блок-схема, иллюстрирующая Статьи в Схеме ядра;

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

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

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

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

фиг.12 - схема, иллюстрирующая классификацию отношений;

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

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

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

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

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

фиг.18 - иллюстрирует концепцию папок Включения;

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

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

фиг.21А - графическое представление иллюстративной схемы Статьи «Контакты»;

фиг.21В - графическое представление Элементов для иллюстративной схемы Статьи «Контакты», показанной на фиг.21А;

фиг.22 - иллюстрирует конструкцию среды выполнения API платформы хранения;

фиг.23 - иллюстрирует выполнение операции «найти все»;

фиг.24 - иллюстрирует процесс, посредством которого классы API платформы хранения генерируются из схемы платформы хранения;

фиг.25 - иллюстрирует схему, на которой основан API «Файл»;

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

фиг.27 - (части a, b, и c) обозначают новую идентично защищенную область безопасности, вырезанную из существующей области безопасности;

фиг.28 - схема, иллюстрирующая концепцию поискового вида Статьи;

фиг.29 - схема, иллюстрирующая иллюстративную иерархию Статьи;

фиг.30А - иллюстрирует интерфейс Интерфейс1 как канал связи между первым и вторым сегментами кода;

фиг.30В - иллюстрирует интерфейс как содержащий объекты интерфейса I1 и I2, которые обеспечивают связь между первым и вторым сегментами кода системы через среду М;

фиг.31А - иллюстрирует, как функцию, обеспеченную интерфейсом Интерфейс1, можно разделить для преобразования связей интерфейса на множество интерфейсов Интерфейс1A, Интерфейс 1B, Интерфейс 1C;

фиг.31В - иллюстрирует, как функцию, обеспеченную интерфейсом I1, можно разделить на множество интерфейсов I1a, I1b, I1c;

фиг.32А - иллюстрирует сценарий, где точность несущественного параметра можно игнорировать или заменить произвольным параметром;

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

фиг.33А - иллюстрирует сценарий, где 1-й и 2-й Сегменты кода объединяются в модуль, содержащий их обоих;

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

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

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

фиг.35А - иллюстрирует как компилятор своевременной активизации (JIT) может преобразовывать передачи от одного сегмента кода к другому сегменту кода;

фиг.35В - иллюстрирует как JIT-метод динамического переписывания одного или нескольких интерфейсов можно применять для динамической факторизации или иного изменения интерфейса;

фиг.36 - иллюстрирует ряд взаимосвязанных Статей и подмножества их Отношений;

фиг.37А - иллюстрирует недостатки стандартного выделения подтипов Статей в целях конкретного приложения;

фиг.37В - иллюстрирует частичное решение проблем стандартного выделения подтипов; и

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

Подробное описание

Оглавление
I. Введение
А. Иллюстративная вычислительная среда
В. Традиционное хранение на основе файлов
II.Платформа хранения WINFS для организации, поискаи совместного использования данных
С. Глоссарий
D. Обзор платформы хранения
Е. Модель данных
1. Статьи
2. Идентификация Статьи
3. Папки статей и Категории
4. Схемы
а) Базовая схема
b) Схема ядра
5. Отношения
а) Объявление отношения
b) Отношение поддержания
с) Отношения внедрения
d) Отношения ссылки
е) Правила и ограничения
f) Упорядочение отношений
6. Расширяемость
а) Расширение статьи
b) Расширение типов Вложенного элемента
F. Машина базы данных
1. Реализация хранилища данных с использованием ТОП
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. Метаданные
а) Метаданные схемы
b) Метаданные экземпляра
G. Безопасность
Н. Уведомления и отслеживание изменений
I. Синхронизация
1. Синхронизация между платформами хранения
а) Приложения, управляющие синхронизацией
b) Аннотация схемы
с) Конфигурация синхронизации
(1) Отображения папки сообщества
(2) Профили
(3) Расписания
d) Обработка конфликтов
(1) Обнаружение конфликта
(а) Конфликты на основе знания
(b) Конфликты на основе ограничения
(2) Обработка конфликта
(а) Автоматическое разрешение конфликтов
(b) Регистрация конфликтов
(с) Инспектирование и разрешение конфликтов
(d) Сходимость дубликатов и распространениеразрешений конфликтов
2. Синхронизация с хранилищами данных платформыбез хранения
а) Услуги синхронизации
(1) Перечисление изменений
(2) Применение изменений
(3) Разрешение конфликтов
b) Реализация адаптера
3. Безопасность
4. Управляемость
J. Возможность взаимодействия (с традиционной файловойСистемой)
К. API платформы хранения
III. Расширения и наследование
А. Система типов
В. Семейства типов
1. Типы вложенного элемента
2. Типы статьи
3. Типы отношения
а) Семантика отношения
b) Правила и ограничения для отношений
4. Типы расширения
С. Расширенные функциональные возможности
1. Наследование
2. Расширения
IV. Заключение

I. Введение

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

А. Иллюстративная вычислительная среда

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