ObjectDatabase ++ - ObjectDatabase++

ObjectDatabase ++
Логотип ObjectDatabase ++ (чистый фон) .png
Разработчики)Ekky Software
Стабильный выпуск
3.4 / 1 октября 2012 г. (2012-10-01)[1]
Написано вC ++, C #, VB.NET & TScript
Операционная системаWindows & Linux
ТипБаза данных объектов
ЛицензияПроприетарный[2]
Интернет сайтwww.ekkysoftware.com

ObjectDatabase ++ (ODBPP) является встраиваемым объектно-ориентированная база данных разработан для серверных приложений, требующих минимального внешнего обслуживания. Это написано в C ++ как в реальном времени ISAM уровень базы данных с возможностью автоматического восстановления после сбоев системы при сохранении целостности базы данных. Его уникальный процесс транзакций позволяет поддерживать как индексы, так и таблицы, предотвращая двойное выделение записей индекса, что может препятствовать откату транзакций.

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

История

  • Первоначальная разработка осуществлялась Ekky Software с 2001 по 2003 год.
  • Потребовалось 4 полных переписывания базы данных, прежде чем тестирование подтвердило, что она соответствует спецификациям и функционирует должным образом.
  • За последнее десятилетие многочисленные усовершенствования продуктов позволили значительно расширить поддержку индексов и данных.

Иерархические объекты данных

Показывает традиционный дизайн реляционной базы данных
Показывает дизайн базы данных объектов

ODBPP поддерживает объекты с иерархической структурой,[3][4] похожий на XML, JSON или сериализованный PHP. Именно этот иерархический объект отделяет объектные базы данных от их реляционных собратьев, и именно процесс хранения всего объекта в одной записи, а не распределения его по нескольким таблицам, придает объектным базам данных отличие от реляционной модели.

Традиционный реляционный дизайн

Традиционно базы данных разрабатывались с использованием реляционной модели. Это позволит разделить данные по нескольким таблицам и использовать общий идентификатор, чтобы связать все дочерние записи с их родительскими. Эта модель была основана на каждой строке таблицы, содержащей отдельные фрагменты данных. Базы данных SQL, основанные на этом проекте, создадут присоединяется это восстановило бы все отношения, страдая от ограничений производительности.[5]

Дизайн объектной базы данных

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

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

Контроль многопроцессорных транзакций

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

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

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

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

Поддерживаемые индексы

В отличие от некоторых более ранних моделей объектных баз данных,[6][7] как ISAM Уровень базы данных ODBPP поддерживает большое количество индексов. Во время первоначальной разработки объектной модели основной дизайн заключался в использовании схемы, которая содержала только сериализованный двоичный объект, на который ссылался его идентификатор, и не предоставляла другого доступа к индексу. Это предотвратило базовый поиск по ярлыкам и так далее, и было сделано из-за того, что архитектура подчеркивания все еще была основана на связанной модели. Поскольку ODBPP всегда разрабатывался с использованием объектной модели, он понимает иерархическую природу объектов и способен индексировать содержащиеся в нем данные.

Статический хеш-индекс

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

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

B + древовидные индексы

В B + дерево index - это основная рабочая лошадка всех баз данных, и ODBPP не исключение. Большинство поисков выполняется путем поиска позиции индекса, а не путем повторного вызова следующего по величине значения. ODBPP поддерживает большое количество фильтров в B + Tree, чтобы сделать результаты более удобными. Например, его можно настроить для преобразования всех символов нижнего регистра в верхний регистр или установить для удаления пробелов или не буквенно-цифровых символов, а также предоставить естественный порядок сортировки где «9» стоит перед «10».

Одна из особенностей ODBPP по сравнению со стандартной СУБД заключается в том, что данные, хранящиеся в иерархическом объекте, также могут индексироваться. Тогда это создаст ситуацию, когда есть 0…п значения индекса, созданные для любого объекта.

Пространственные и временные индексы

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

Сопоставление биометрического шаблона

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

Полнотекстовый поиск

ODBPP обеспечивает полнотекстовую индексацию с помощью индексов списка токенов. Эти индексы представляют собой комбинацию дерева B + и переполнения корзины, где текстовая строка разбивается на отдельные токены и индексируется в дереве B +, а поскольку несколько объектов будут иметь одно и то же значение маркера, идентификатор сохраняется в переполнении корзины. (аналогично динамическому хеширование. При таком дизайне полнотекстовый поиск выполняется путем сканирования всех токенов в листьях B + Tree и определения, какие токены соответствуют критериям поиска, и получения соответствующих идентификаторов.

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

Пример реализации

Основы интерфейса

ODBPP был разработан для работы как в процедурном стиле, так и в инкапсулированном объекте. C ++ стиль. Хотя объектный стиль по-прежнему использует процедурный метод для взаимодействия с базой данных на низком уровне, в примере демонстрируется процедурный метод.

Родной пример

учебный класс Фу {общественный:   перечислить { TableID = 1};   беззнаковый int ParentID; // id для ссылки на этот родительский объект   беззнаковый int Флаги[4]; // 0x01 - есть родитель   перечислить {      Имя,// метка, присвоенная объекту Foo      Описание// описание Foo   };} *fooObject;CODBPP база данных;CODBPP::Объект объект;беззнаковый int ошибка;char16_t *fooName = ТЕКСТ("FooName"), *сообщение, буфер[128];если ((ошибка = база данных.OpenDatabase(ТЕКСТ("C:\\Дорожка\\К\\Database.odc "))) == НЕТ ОШИБКИ&& (ошибка = база данных.BeginTransaction()) == НЕТ ОШИБКИ&& (ошибка = база данных.Открытый стол(Фу::TableID)) == НЕТ ОШИБКИ&& (ошибка = база данных.ReadObject(Фу::TableID, CODBPP::РАВНО, &объект, 1, fooName)) == НЕТ ОШИБКИ){    fooObject = (Фу*)объект.фиксированный;    swprintf_s(буфер, __countof(буфер), ТЕКСТ(«Родитель =% d, флаги =% d»), fixedObject->ParentID, fooObject->Флаги[0]);    Окно сообщения(буфер);}если (ошибка && база данных.GetErrorMessage(&сообщение) == НЕТ ОШИБКИ)   Окно сообщения(сообщение);база данных.EndTransaction();

Пример TScript

Эквивалент TScript Пример чтения объекта из базы данных с именем «FooName» выглядит следующим образом. 

#включают «ОДБПП.ц»общественный главный(Переменная параметры = ноль : Структура полученные результаты) {   ODBPP база данных;   ODBPP.Объект objectHandle;   база данных.OpenDatabase(L"c:\\Дорожка\\К\\Database.odc ");   база данных.BeginTransaction();   база данных.Открытый стол(1);   база данных.ReadIndex(1,CODBPP.РАВНО,1,L"FooName": objectHandle);   база данных.FragmentObject(1,objectHandle:полученные результаты);   Система::Окно сообщения(L"Родитель ="+полученные результаты.ParentID+L", Flags ="+полученные результаты.Флаги);}

Пример C #

ObjectDatabase ++ также предоставляется через COM класс-оболочка ODBPPLib.ODBPP. Эквивалентный пример C # чтения объекта из базы данных с именем «FooName» выглядит следующим образом. 

частный пустота button1_Click(объект отправитель, EventArgs е) {    пытаться {        ODBPPLib.ODBPP odbpp = новый ODBPPLib.ODBPP();        odbpp.OpenDatabase(@ "C:  Путь  К  Database.odc");        odbpp.BeginTransaction(odbpp.ОБЩИЙ, 6000);        odbpp.Открытый стол(1);        ODBPPLib.DatabaseObject полученные результаты = odbpp.ReadObject(1, odbpp.РАВНО, 1, "FooName");        если (полученные результаты != ноль)            Окно сообщения.Показать("Родитель =" + полученные результаты.readField("ParentID") + ", Flags =" + полученные результаты.readField(«Флаги»));    }    ловить (Исключение e1) {        Окно сообщения.Показать(e1.Сообщение);    }}

Рекомендации

  1. ^ Ekky Software В архиве 2012-09-29 в Wayback Machine
  2. ^ «Архивная копия». Архивировано из оригинал на 21.08.2013. Получено 2013-08-02.CS1 maint: заархивированная копия как заголовок (связь)
  3. ^ Khoualdi, K, & Alhamdi, T. 2011, «Разработка систем с использованием объектно-ориентированной базы данных. Практическое исследование системы ISO 9001: 2000», Journal of Software Engineering & Applications, 4, 12, pp. 666–671, Computers & Applied Sciences Complete
  4. ^ Насер Т., Алхадж Р. и Ридли М. 2009, «Двустороннее сопоставление между объектно-ориентированными базами данных и XML», Informatica (03505596), 33, 3, стр. 297–308, Computers & Applied Sciences Complete
  5. ^ Сури, П., и Шарма, М. 2011, «СРАВНИТЕЛЬНОЕ ИССЛЕДОВАНИЕ МЕЖДУ ПРОИЗВОДИТЕЛЬНОСТЬЮ ОТНОСИТЕЛЬНОЙ И ОБЪЕКТИВНОЙ БАЗЫ ДАННЫХ В ХРАНЕНИИ ДАННЫХ», Международный журнал систем управления базами данных, 3, 2, стр. 116–127, Компьютеры и прикладные науки Complete
  6. ^ Хардвик, М., Самарас, Г., 1989, «Использование реляционной базы данных в качестве индекса для базы данных распределенных объектов в системах инженерного проектирования», Системы данных и знаний для производства и проектирования, 1989 г., Вторая международная конференция Дата конференции: 16- 18 октября 1989 г.
  7. ^ Zhang, F, Ma, Z, & Yan, L, 2011, «Построение онтологий из объектно-ориентированных моделей баз данных», Integrated Computer-Aided Engineering, 18, 4, стр. 327–347, Computers & Applied Sciences Complete
  8. ^ Ли, К.С.К.; Хонг Ва Леонг; Si, A. 2003, «Приблизительное местоположение объекта для базы данных движущихся объектов», Семинары по распределенным вычислительным системам, 2003. Труды. 23-я Международная конференция, дата проведения: 19–22 мая 2003 г.

внешняя ссылка