Архитектура Opensearch для openmetadata как репозитария метаданных глазами DeepSeek OpenMetadata использует OpenSearch (или Elasticsearch) в качестве основного движка для поиска и обнаружения данных (Data Discovery), в то время как реляционная база данных (PostgreSQL или MySQL) выступает в роли источника истины (Source of Truth) для хранения сущностей и их связей . Ниже представлен развернутый обзор архитектуры этой интеграции. В архитектуре OpenMetadata реализован паттерн "CQRS" (Command Query Responsibility Segregation) в упрощенном виде: Такой подход позволяет быстро выполнять сложные поисковые запросы без создания высокой нагрузки на основную базу данных...
Вселенная метаданных
Oracle XDB (XML Database) как образец ORM DataStore Oracle XDB (XML Database) — это встроенный в СУБД Oracle компонент и гибридная модель данных, предназначенная для нативного хранения, индексирования, запросов и управления документами XML и связанными с ними веб-ресурсами прямо внутри объектно-реляционной структуры базы данных. Архитектура и хранение данных XMLType: Специальный тип данных SQL для переменных, колонок и таблиц, содержащих XML-документы, который создается при регистрации XSD. Модели физического хранения: Object-Relational (ORM DataStore): мапинг объектов XML-документа на объекты объектно-реляционной модели данных. Binary XML: Компактный двоичный формат, оптимизированный для производительности и эффективного использования диска (сжатые бинарные файлы). CLOB: Сохранение исходного текста документа в символьном большом объекте (сжатые символьные файлы). Аннотации XDB: Специальные атрибуты пространств имен xmlns.oracle.com/...b), определяющие отображение элементов XML на типы SQL в описании root объекта. Ключевые возможности XML Tables: Поддержка встроенных языков запросов и навигации по XML-данным прямо из операторов SQL. XML Index: Полнотекстовые и структурированные индексы для мгновенного поиска внутри документов. Репозиторий XDB (XML DB Repository - Stage): Иерархическая файловая система внутри базы данных, отображающая URL/пути на объекты XMLType с поддержкой протоколов доступа (FTP, HTTP/WebDAV) и управлением прав через ACL. Программные интерфейсы: Богатый набор API на PL/SQL (пакеты вроде DBMS_XMLSCHEMA, DBMS_XDB_CONFIG), Java (DOM API в пакете oracle.xdb.dom) и C/C++.
Объектно-реляционная модель хранения (ORM DataStore) СУБД Oracle 8,9 Объектно-реляционная модель хранения Oracle Database версии 8 (1997 г.) была реализована вне ядра СУБД средствами модулей PL/SQL, которые являлись внешним пакетом приложений. Попытка внедрения кода ORM в ядро СУБД Oracle версии 8 была неудачной. СУБД Oracle 8 при использовании ORM кода ядра «падала» похлеще СУБД Линтер версии 3 при попытке создать иерархический словарь. Объектно-реляционная модель хранения (ORM DataStore) Oracle DB (2001г. версия 9.0.1) — модель хранения, которая из классических таблиц создает сложные структуры объектов. Вы можете хранить простые строки и столбцы вместе со сложными типами данных, такими как коллекции и вложенные структуры, сохраняя при этом всю мощь языка SQL. Основные понятия Объектные типы (Object Types): Свои типы данных (объекты), которые объединяют атрибуты и пакеты функции обработки данных (методы). Вложенные таблицы (Nested Tables): Таблицы хранения значений и связей Массивы (VARRAY): Списки многозначных атрибутов Ссылки (REF): Указатели на конкретные объекты в других таблицах (связи). Типы объектов (OBJECT TYPE): Пользовательские типы данных, которые могут содержать как атрибуты (скалярные типы вроде VARCHAR2 или NUMBER), так и методы (функции и процедуры). Объектные таблицы (OBJECT TABLE): Таблицы, где каждая строка представляет собой отдельный объект с уникальным системным идентификатором — OID (Object Identifier). Ссылки (REF): Специальный тип данных для указания на конкретные строки-объекты в объектных таблицах, заменяющий традиционные внешние ключи (Foreign Keys) на прямые указатели. Коллекции (Varrays и Nested Tables): Инструменты для моделирования атрибутов с множественными значениями (например, списка телефонов или строк заказа прямо внутри объекта). Главные плюсы Сложные структуры: Удобно описывать реальные вещи и связи без лишних таблиц соединения. Понятный код: Логику можно хранить прямо внутри типов данных через методы на PL/SQL. Совместимость: Старый добрый SQL и новые объекты работают вместе в одной базе. Повторное использование: Созданный объектный тип можно применять в разных частях базы. Минусы подхода Сложность: Требуется подготовка для проектирования и поддержки БД Скорость: Запросы с объектами и ссылками работают медленнее, чем простые реляционные без использования индексов Nested Tables.
Что изменилось в ОРМ в 2000-х Релекс еще в 1995 году переименовал АСКРИН в НЕВОД как ИАС (информационную аналитическую систему), независимую от предметной области. ИАС Невод 2006 года перестал быть похож на АИС АСКРИН 1995 года. Изменились метаданные приложений и модули их обработки, а базовые принципы ОРМ остались неизменны. Даже наименования атрибутов поменялись незначительно. Базовыми принципами ОРМ были и остались принципы хранения связей и ссылок, а также фиксирование их структуры и описания в виде метаданных. Основные структуры ОРМ хранения и обработки данных, разработанные в 1994 году создаются запросами: Create Table OBJECTS (NAME CHAR(40) , OBJ_ID INTEGER , STATUS INTEGER) ; Create Table ATTRS (NAME CHAR(30) , ATR_ID INTEGER , OBJ_ID INTEGER , ATR_TYPE INTEGER , GR_ID INTEGER , REF_OBJ_ID INTEGER , DICT INTEGER , TYPE INTEGER , LEN INTEGER ,DOM_ID INTEGER , NUM_IN_OBJ INTEGER , ANNO INTEGER) ; Create Table LINKS (LNK_EL_ID INTEGER , OBJ1_EL_ID INTEGER , OBJ2_EL_ID INTEGER , OBJ1_ID INTEGER , OBJ2_ID INTEGER , COLOR CHAR(30)) ; Create Table USERP (USR SMALLINT ,NAME CHAR(40) , SYSNAME CHAR(18) , DOSTUP CHAR(5) , DATE_NPD DATE , DATE_KPD DATE , ANNO CHAR(180) , RIGHTS INTEGER) ; Основные структуры ОРМ хранения и обработки данных, используемые в 2006 году создаются запросами: CREATE TABLE "NEVOD"."DB_OBJECT" CHARACTER SET "DEFAULT" ( "ID" INTEGER , "NAME" NCHAR(40) , "TYPE" SMALLINT , "PARENT" INTEGER , "PROPERTIES" SMALLINT , "REAL_ID" INTEGER , "OWNER" NCHAR(18) , "TABL" NCHAR(18) , "TRIGGER" BLOB , "COL_ID" NCHAR(18) , "DEF" INTEGER ); CREATE TABLE "NEVOD"."DB_ATTRIBUTE" CHARACTER SET "DEFAULT" ( "ID" INTEGER , "NAME" NCHAR(30) , "TYPE" SMALLINT , "LEN" SMALLINT , "NUM_IN_OBJ" SMALLINT , "PARENT" INTEGER , "DOMEN" INTEGER , "REF_OBJ" INTEGER , "REF_GRP" INTEGER , "PROPERTIES" INTEGER , "REAL_ID" INTEGER , "OWNER" NCHAR(18) , "TABL" NCHAR(18) , "COL" NCHAR(18) , "TRIGGER" BLOB , "COL_ID" NCHAR(18) , "COL_PARENT" NCHAR(18) , "DEF" INTEGER ); CREATE TABLE "NEVOD"."LINKS" CHARACTER SET "DEFAULT" ( "DOC_ID" INTEGER , "LNK_EL_ID" INTEGER , "OBJ1_EL_ID" INTEGER , "OBJ2_EL_ID" INTEGER , "OBJ1_ID" INTEGER , "OBJ2_ID" INTEGER , "COLOR" NCHAR(30) , "ID_1" NCHAR(23) , "ID_2" NCHAR(23) , "OWNER" INTEGER ); CREATE TABLE "NEVOD"."USERP" CHARACTER SET "DEFAULT" ( "USR" SMALLINT , "NAME" NCHAR(40) , "SYSNAME" NCHAR(18) , "DOSTUP" NCHAR(5) , "DATE_NPD" DATE , "DATE_KPD" DATE , "ANNO" NCHAR(180) , "RIGHTS" INTEGER , "STARTTIME" NCHAR(4) , "ENDTIME" NCHAR(4) , "FLAGS" SMALLINT , "SUBJAREA" INTEGER , "ROLE_ID" INTEGER DEFAULT 0); Создать ОРМ хранения и обработки данных со множественными значениями не просто. Ее можно дополнять, развивать, но базовые принципы остаются неизменными.
Linter версии 4.1. Разработка АCКРИН и моя разработка API к ОРМ заставила разработчиков ядра СУБД Linter значительно доработать код и устранить множество ошибок и ограничений в коде ядра, в частности в трансляторе SQL запросов. Так к концу1994 года была выпущена версия 4.1 СУБД Linter (Large Intereal). Странно, но LIntereal было бы понятней, чем «лентяй». Кража кода API к ОРМ По мере разработки API к ОРМ Пешков принижал мою разработку и поощрял альтернативную разработку того же продукта. Мою разработку отклонили. Мне было не понятно такое положение дел. Лишь позднее мне удалось узнать, что продажа АСКРИН на CEBIT-95 сопровождалась требованием разработки API. Сперва был выплачен аванс, а затем после передачи кода API был произведен окончательный расчет. Мне нужна была ссуда на покупку жилья, но Бойченко мне отказал. А когда Пешков попросил меня прокомментировать код API, который никто из программистов не мог понять, т. к. модули получения путей были убраны из текста кода, я с большим удовольствием проигнорировал его просьбу и ушел из фирмы в мае 1995 года. В 1995 году было совершенно непонятно, как устанавливать и защищать интеллектуальную собственность, тем более что технологии далеко опередили свое время.

