RU105770U1 - Архитектура для хранения и представления данных в эмуляторе - Google Patents

Abstract

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

Description

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

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

Уровень техники

Одной из основных проблем эмуляции сложных структур, таких как файловая система или реестр операционных систем Microsoft Windows, является недостаточное быстродействие при расширении эмулируемой структуры, а также недостаточная универсальность. В настоящий момент не существует систем, которые позволили бы быстро восстанавливать данные при многократном изменении фрагмента базы данных. Есть различные реляционные базы данных, такие как описанные в патентах GB 2459354, US 7051039, WO 03030032, CN 11369291, но основной их недостаток в том, что они имеют низкую скорость работы и не могут работать с большим количеством информации. Существующие нереляционные базы данных сложны для реализации, в связи с чем возникла задача в создании нереляционной и одновременно не сложной в реализации базы данных.

Присутствует необходимость хранения разнородных объектов в базе данных, что описано в патенте US 7627563 или заявке US 20050222964, но без возможности использования перекрестных ссылок для доступа к разным полям объектов, как описано в патентах WO 05079405 или US 6529913. Таким образом, требуется создать базу данных, способную хранить объекты различных типов с возможностью создания перекрестных ссылок между их полями для более быстрого доступа.

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

Сущность полезной модели

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

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

В частном варианте реализации системными ресурсами являются: файловая система; реестр.

Краткое описание прилагаемых чертежей

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

На чертежах:

Фиг.1 показывает структурную блок-схему архитектуры хранения данных.

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

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

Фиг.4 показывает блок-схему алгоритма использования архитектуры данных в эмуляторе.

Фиг.5а и 5б показывают пример прозрачного чтения/записи данных.

Фиг.6 показывает структурную блок-схему ассоциативных таблиц иерархической базы данных.

На Фиг.7 изображена структурная блок-схема примера компьютерной системы, которая используется для реализации полезной модели.

На фиг.8 представлена схема реализации настоящей полезной модели.

Подробное описание предпочтительных вариантов реализации

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

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

Использование предложенной архитектуры хранения данных для работы эмулятора является необходимым для восстановления фрагмента базы данных при многократном его изменении.

Одно из направлений полезной модели - это использование новой архитектуры хранения данных для работы эмулятора. В соответствии с примером реализации представлена универсальная архитектура хранения иерархической информации и пример ее использования.

В общем варианте реализации создается иерархическая база данных. База данных состоит из объектов, поля которых могут быть различного типа: строка, булево выражение, число, ссылка, список и т.д. Для объектов в базе создаются разные пользовательские типы. Например, если база данных содержит информацию о растениях, то для всех объектов базы будут использованы следующие типы: Taxon для определения рода растений, Specie для вида семейства растений, SubSpecie для подвида, Book для книги о растении, Image для изображения растения. Synonym для ссылки на синонимичные растения (аналоги). Каждый тип характеризуется сортированным определенным образом набором полей. Например, для типа Taxon будет следующий набор полей: имя Name, автор Author, список дочерних объектов SubTaxon. Некоторые типы могут иметь один и тот же набор полей, при этом наборы полей разных типов могут частично совпадать. Для типа Specie будет набор полей, совпадающий с типом Taxon. То есть тип Specie наследуется от типа Taxon. Для типа SubSpecie поля также будут совпадать с типом Taxon. Таким образом, реализовано логическое разделение типов, имеющих схожий набор полей. Количество типов в базе данных может быть не ограничено.

Объекты в базе могут быть как полностью, так и частично заполненными. Каждый объект в базе уникально характеризуется родительским объектом, типом, а также индексными полями. Индексные поля - это уникальные для объекта поля. Индексных полей может быть как одно, так и несколько. Например, для объекта типа Taxon индексными будут поля Name и Author. Они являются ключевыми для объекта, и через них осуществляется доступ к нему. Для доступа к объекту типа Taxon необходимо знать его тип (Taxon), имя (Name), автора (Author). Для объекта не обязательно заполнение всех индексных полей. Например, два разных объекта могут иметь одно одинаковое индексное поле, но отличаться по другим индексным полям.

Полями объекта могут быть индексные поля, списки, неиндексные поля, ссылки.

1. Индексное поле - это поле, через которое осуществляется доступ к объекту. Для одного объекта может быть несколько индексных полей. Доступ к объекту можно получить, зная его индексные поля и тип. Индексные поля не обязательны для заполнения. Но сочетание заполненных индексных полей для объекта должно быть уникальным для каждого типа для того, чтобы различать объекты внутри типа. Например, может существовать два объекта Taxon с одинаковым именем Name, но с разными авторами Author.

2. Неиндексное поле - это информационное поле, которое может быть строкой, числом, булевым выражением и т.д.

3. Список - это коллекция дочерних объектов любого типа, упорядоченная по типам объектов.

4. Ссылка - это поле, ссылающееся на любой объект в базе независимо от местоположения объекта, то есть как на дочерние, так и на родительские объекты. Ссылка не может указывать на корневой объект. Такие ссылки являются перекрестными.

Родительский (parent) объект единственный и обязательно существует для любого объекта. Родительский объект есть у каждого объекта базы данных. Корневой объект (root) единственный для базы данных. Структура корневого объекта отличается от обычной структуры объекта наличием следующих ограничений: поля корневого объекта - это списки с уникальными именами (уникальные в рамках корневого объекта). Полный путь к объекту - ветка прохождения от корня до него.

Основные особенности представленной архитектуры - это иерархическая структура, разнородность объектов и перекрестные ссылки.

На Фиг.1 изображена структурная блок-схема архитектуры хранения данных в соответствии с примером реализации. В представленной базе данных обязательным является наличие корневого объекта 110. Корневой объект всегда является списком полей, указывающих на объекты следующего уровня иерархии. Остальные объекты, начиная со второго уровня иерархии не имеют ограничений для набора полей. Все списки дочерних объектов собраны по типам. Например, для объекта 110 все дочерние собраны следующим образом. Сначала идут объекты 120 и 130 типа Type 11, затем идет объект 140 типа Туре 12 и т.д.

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

Таким образом, можно утверждать, что предложенная архитектура универсальна.

На Фиг.2 изображен частный вариант реализации файловой системы в виде иерархической структуры файлов, папок и ярлыков. Для реализации файловой системы на структуру типов объектов наложены ограничения. В файловой системе есть три типа объектов: файл, список объектов («папка» в привычном понимании), ссылка («ярлык» в привычном понимании). Все типы файловой системы состоят из двух полей: имя («Name» на Фиг.2) и содержание («Content» на Фиг.2). Имя объекта - индексное строковое поле, а содержание - это неиндексное поле, зависящее от типа объекта. Если типом объекта является файл, то содержание - текстовое поле, если папка, то это список на дочерние объекты, если ссылка, то указатель на любой объект базы кроме корневого. Объекты 220, 260, 280 соответствуют папкам файловой системы, и всегда являются списком других объектов. Список может быть и пустым. Объекты 230, 240, 270, 285 являются файлами и не могут иметь дочерних объектов. Объекты 250, 290 соответствуют ярлыкам файловой системы. Ярлык 250 ссылается на объект 270, а ярлык 290 ссылается на объект 240. Иерархия файлов и папок идет от корневого элемента 210 файловой системы.

Объект файловой системы уникально идентифицируется по типу объекта, индексным полям и родительскому объекту. Полный путь к объекту описывается через список объектов иерархии разного уровня от корневого до конечного объекта. Например, путь к файлу 285, изображенному на Фиг.2, будет следующим: \Root\Folder, Name1\Folder, Name5\File, Name8\.

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

В другом частном варианте возможна также реализация системного реестра аналогично вышеуказанному примеру с файловой системой.

На Фиг.3 изображен пример реализации использования иерархической базы данных. Для работы в эмуляторе не обязательно загружать всю базу 310 в память, достаточно указать путь только к тем объектам, которые необходимо загрузить. В памяти восстанавливается часть базы от корневого объекта до запрошенных, включая все объекты, через которые проходит путь к запрошенным объектам. Если объекты из указанного пути не найдены в базе данных, то по мере его прохождения автоматически создаются недостающие объекты. Для данной ветви иерархической базы данных, изображенной на Фиг.1, выделяется определенный блок оперативной памяти 320, так называемой предварительно распределенной области данных. Затем для области памяти 320 создается точная резервная копия 330 с сохранением всех ссылок. Таким образом, осуществлена подготовка части базы данных, распределенной в области 320, для многократной работы в эмуляторе. Во время работы над базой данных в ней происходят изменения. При этом может не хватить предварительно выделенной области данных 320, и тогда возможно использование дополнительной памяти 340. После того, как с эмулированной базой были проделаны изменения и на их основе получены результаты, то нужно будет восстановить базу данных в исходное состояние. Для этого точная резервная копия 330 копируется в область 320, и очищается память 340. Целостность ссылок при этом не рушится.

На Фиг.4 изображена блок-схема алгоритма работы эмулятора при использовании иерархической базы данных, изображенной на Фиг.1. На шаге 410 из базы данных загружаются данные в предварительно распределенную область данных. На шаге 420 создается резервная копия загруженных данных. Эта копия может располагаться как в оперативной памяти, так и на жестком диске. Расположение копии в оперативной памяти значительно ускорит работу эмулятора. Затем начинается работа с загруженной частью базы данных на шаге 425. Если выделенной изначально области памяти не хватило при работе с базой, то потребуется выделить дополнительный блок памяти на шаге 430. После завершения работы с базой данных будет восстановлена резервная копия данных в предварительно распределенной области данных, а дополнительная память будет очищена на шаге 440.

На Фиг.5а изображена структурная блок-схема «прозрачного» чтения и записи. При чтении файл 510 считывается с части 520, расположенной на диске. Однако, если до этого были произведены операции записи, которые должны были изменить часть 530, то для этого используется механизм "прозрачной" записи. Для этого на диске создается новая запись 540, не изменяя запись 520а исходного файла. Затем, при чтении файла 510 часть 530 будет считываться не с записи 520, а с записи 540. Таким образом можно эмулировать работу с файловой системой, не изменяя реальных файлов на диске.

На Фиг.5б изображена структурная блок-схема чтения файла из разных частей дискового пространства. Файл состоит из частей 550 и 560, которые лежат не по порядку в записи 570 на диске. Тем не менее, при чтении файл представляется единым целым. Таким образом, можно реализовать способ «прозрачного» чтения и записи файла с диска.

Структура иерархической базы данных, изображенной на Фиг.1, представлена в ассоциативных таблицах. На Фиг.6 изображены ассоциативные таблицы объектов и их типов, а также определения типов полей. База данных состоит из трех таблиц: таблица полей (называемая «Field Definition» 610 на Фиг.6), таблица типов (называемая «Type Definition» 620 на Фиг.6), таблица объектов (называемая «Object» 630 на Фиг.6).

Таблица полей 610 содержит описания всех полей, присутствующих во всех объектах иерархической базы данных, изображенной на Фиг.1. Поля отсортированы таким образом, что они идут в таком же порядке, как они отсортированы в типах. При описании поля в таблице указываются следующие параметры: имя поля, тип поля, флаг индексного поля. Значения имени поля хранятся в колонке «Name» 640. Имя поля не обязательно может быть уникальным. Для связи таблиц используется местоположение поля в таблице. Тип поля хранится в колонке «Type» 645 и может быть строковым, численным, ссылочным, списковым и т.д. Признак индексного поля хранится в колонке 650.

При добавлении нового поля к типу во время использования базы оно будет доступно при перезагрузке базы, и автоматически будет располагаться в таблице рядом с полями своего типа.

Таблица типов 620 содержит описание всех типов базы данных, изображенной на Фиг.1. Каждый тип ссылается на диапазон полей из таблицы полей 610. При описании типа в таблице указываются следующие параметры: имя типа, диапазон полей. Имя типа хранится в колонке «Name» 655, диапазон полей хранится в колонке 660. Некоторые типы могут ссылаться на один и тот же диапазон полей или на верхнюю часть диапазона полей. Поля типов отсортированы так, что индексные поля всегда идут сначала, а затем уже неиндексные поля, списки, ссылки. Поэтому тип, построенный на основе другого типа, не может ссылаться на часть диапазона полей, не содержащую индексных полей.

На Фиг.6 изображен случай совпадения полей 10-14 таблицы 610 у типов 7 и 8 таблицы 620. В этом случае можно сказать, что тип 8 наследован от типа 7 таблицы 620. Также изображен случай частичного совпадения полей 10-11 таблицы 610 у типов 7 и 9 таблицы 620. Но в последнем случае у типа 9 таблицы 620 не может быть диапазон полей 9-11 таблицы 610, так как индексные поля всегда идут в начале диапазона.

На фиг.8 представлена схема реализации настоящей полезной модели. Средство эмуляции 810 делает запрос для эмуляции определенной части системных ресурсов (например, файловая система или реестр) и отправляет этот запрос на средство поддержки иерархической базы данных 820. Само средство поддержки иерархической базы данных 820 использует уже упоминавшиеся таблицы полей 850, типов 860, объектов 870 для описания системных ресурсов и затем запрашивает средство создания копии ресурсов системы 830 для реализации "прозрачного" метода доступа к ресурсам как показано на фиг.5а и 5б. Если средство создания копии ресурсов системы 830 сообщает о нехватке системной памяти для помещения всех необходимых данных, то средство поддержки иерархической базы данных 820 обращается к средству работы с памятью 840 для увеличения объема памяти, используемой для эмуляции системных ресурсов. Стоит отметить, что таблица полей 850 отсортирована по использованию этих полей в типах объектов 870, таблица типов 860 зависит от диапазона полей 850, таблица объектов 870 указывает на типы 860.

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

На Фиг.7 изображена структурная блок-схема примера компьютерной системы, которая используется для реализации полезной модели. Система включает в себя компьютер общего назначения (персональный компьютер или сервер 20), состоящий из следующих элементов: процессор 21, системная память 22 и системная шина 23, соединенная с различными системными компонентами в том числе и с памятью 22, и с процессором 21. Системная шина 23 может быть любого типа, включающая шину памяти или контроллер памяти, периферийную шину и локальную шину, построенная на любой из шинных архитектур. Системная память состоит из постоянного запоминающего устройства (ПЗУ) 24 и оперативного запоминающего устройства (ОЗУ) 25. Базовая система ввода/вывода 26 (BIOS) содержит базовые процедуры для передачи информации между компонентами персонального компьютера 20 и хранится в ПЗУ 24.

Также компьютер 20 может включать привод жесткого диска 27 для чтения и записи на жесткий диск, привод магнитного диска 28 для чтения и записи на съемный магнитный диск и привод оптического диска 30 для чтения и записи на съемный оптический диск, такой как компакт-диск, DVD-диск или другие оптические носители. Приводы жесткого диска 27, магнитного диска 28 и оптического диска 30 соединяются с системной шиной 23 через интерфейсы жесткого дискового устройства 32, магнитного дискового устройства 33, оптического дискового устройства 34 соответственно. Дисководы и соответствующие им машиночитаемые носители обеспечивают энергонезависимое хранение машинных инструкций, структур данных, программных модулей и других данных компьютера 20.

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

Несколько программных модулей, включая операционную систему, могут храниться на жестком диске, магнитном диске 29, оптическом диске 31, ПЗУ 24 или ОЗУ 25. Компьютер 20 содержит файловую систему 36, которая используется операционной системой 35, одним или несколькими приложениями 37, другими программными модулями 38 и данными программ 39. Пользователь может вводить команды или информацию в компьютер 20 с помощью устройств ввода/вывода, таких как клавиатура 40 и мышь 42. Другими устройствами ввода/вывода, не отображенными на схеме, могут быть микрофон, джойстик, игровой планшет, спутниковая антенна, сканер и другие.

Эти и другие устройства ввода/вывода зачастую взаимодействуют с процессором с помощью интерфейса порта последовательного ввода/вывода 46, который соединяется с системной шиной, но также может быть соединен и с другими интерфейсами, такими как порт параллельного ввода/вывода, игровой порт или универсальная последовательная шина. Монитор 47 или другое устройство отображения информации также соединены с системой шиной 23 через интерфейс, например, видеоадаптер 48. В дополнение к монитору 47 обычно персональные компьютеры подключены к другим периферийным устройствам вывода информации, которые не изображены на схеме, такие как колонки и принтер.

Компьютер 20 может работать с удаленными компьютерами 49 с помощью сетевого оборудования, используя логические соединения. Удаленным компьютером (или компьютерами) 49 могут быть другие компьютеры, сервер, роутер, сетевой персональный компьютер, одноранговое или другое сетевое устройство; обычно используются большинство вышеперечисленных устройств одновременно, хотя на схеме изображено только запоминающее устройство 50. Логическое соединение - это локальная сеть 51 и глобальная сеть 52. Такие соединения обычно используются в офисах, компьютерных сетях предприятий, интранетах и Интернете.

В локальной сети компьютер 20 соединен с сетью 51 с помощью сетевого интерфейса или адаптера 53. В глобальной сети компьютер 20 обычно использует модем 54 или другие устройства установки соединения с глобальной сетью 52, такой как Интернет. Модем 54, который может быть внутренним или внешним, соединен с системной шиной 23 через порт последовательного ввода/вывода 46. В сетевом окружении программные модули или их части, изображенные относящимися к персональному компьютеру 22, могут храниться на удаленных запоминающих устройствах. Предполагается, что показанные сетевые соединения являются примером. Могут использоваться и другие виды установления соединения между компьютерами.

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

Claims (2)

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

2. Система по п.1, в которой системными ресурсами являются: (а) файловая система; (б) реестр.