А вот чтобы не знать, "где и как данные хранятся" (см. в конце http://proza.ru/2024/10/08/1106), в унифицированной БД (УБД) данные должны бы быть организованы в табличку следующего вида:
1. Ссылка на фактор, характеризующий список параметров, входящих в столбцы данной виртуальной таблицы
2. Ссылка на атрибут требуемого параметра в столбцах этой таблицы
3. Значение строки виртуальной таблицы, отмечающее общность факта занесения в неё значений некоторых из этих параметров.
4. Указание местонахождения значения требуемого параметра (данного).
Плюс ещё несколько таблиц, обеспечивающих формирование виртуальных таблиц и выполнение всех этих ссылок. Важно, чтобы все эти таблицы были бы одинаковы с неизменной структурой при хранении в УБД данных совершенно любого вида, будь то файлы мультимедиа, программ и пр.
Ну а дальше должны бы быть разработаны несколько типовых форм запросов, обеспечивающих формирование виртуальных таблиц, занесение и выборку данных при связи таких таблиц через значения заданных параметров. Так почему же это так и не сделано? Смею предположить потому, что искусство работы с замысловатыми БД как раз "хлеб" ИТ-специалистов.
То, почему авторы этого не сделали, как мне кажется, понятно. Сделав, они просто хорошо решили бы практическую задачу. Кто-то может смог бы потом и лучше. А вот остановившись посередине, они сформулировали положения теории реляционной алгебры, что имело академически непреходящее значение и позволило открыть новые кафедры.
Возвращаясь к УБД, отмечу, что было бы очень хорошо, если бы в УБД предусматривалось наличие описаний всех реквизитов и типов данных в полях каждой таблицы. Такие описания называют "метаданные". Реальная необходимость в этом возникла, когда количество таблиц характеризующих деятельность предприятия стала порядка сотен и тысяч, и метаданные действительно стали включать в БД. Но, опять же, каждый разработчик волен по-своему структурировать и именовать реквизиты уже самих метаданных.
Унифицированная БД (УБД) позволит оперировать электронными документами с такой же лёгкостью, как и бумажными, не привлекая ИТ-специалистов. Это станет возможно потому, что при создании новых документов в УБД не возникает новых сущностных объектов и её структура не изменяется, так как хранимые в ней данные не распределены как попало по таблицам документов, ибо таковых в ней нет.
Унификация позволит также на основе локальных УБД создать иерархически организованную глобальную распределённую УБД. Причём для обмена данными между локальными БД не требуется знать их адреса. Достаточно, чтобы каждая локальная БД имела связь только с единственной БД выше неё по иерархии на одну ступеньку. А уже через неё запрос на выборку будет растиражирован в локальных БД, либо отправлен для тиражирования в БД более высокой иерархии и т.д.
В такой унифицированной БД можно было бы хранить произвольного формата любые сведения из энциклопедий и даже актуальные научные статьи, если человечество со временем всё-таки создаст единый научный язык, в котором отношения сведений между собой типа "кто, кого, как, чем, зачем, когда, где, содержит, зависит от, принадлежит к, было, будет, до, после, сейчас, всегда, от … до …, если … то и т.п." были бы единообразно формализованы в языковых конструкциях или символах отношений, допуская в то же время расширение и описание по мере необходимости спектра учитываемых отношений.
Эта УБД могла бы стать актуальной базой знаний, причём она оперативно отражала бы всё богатство взаимных связей и смысловое содержание хранящихся понятий, фактов и данных.
Кроме того, благодаря УБД типовые алгоритмы управления ресурсами и прикладные задачи станут сразу применимы на любом предприятии и в учреждении, так как не потребуется привязка к конкретным уникальным структурам и форматам хранения данных.
Для каждого типа данного (вида документа) в УБД должны быть приведены его онтологические характеристики, т.е. назначение и сопутствующее текстовое описание, отношения с другими данными и алгоритм получения нового документа этого типа из данных других документов.
Должна быть описана форма представления типа данного в пользовательском интерфейсе и указан нужный инструментарий.
Эти характеристики и средства, называемые метаданными, сами тоже являются обыкновенными данными и, следовательно, должны содержаться в самой базе данных, если не в локальной, то в БД более высокого уровня иерархии. В живой природе аналогом метаданных является, по-видимому, хромосомный набор отвечающий определённому виду организмов.
К метаданным желательно иметь краткое стандартизованное описание в виде метаданных же, называемое классификатор. На каждом уровне иерархии БД классификатор с использованием символов (кодов) отношений позволил бы определить наличие в подведомственных БД затребованных документов и их реквизитов, хотя быть может иначе называемых.
Я надеюсь, что правила его составления будут проще, чем в библиотечном "универсальном десятичном коде" (УДК), описание правил формирования которого на 90% состоит в описании исключений из правил – и именно потому, что не стандартизованы форматы указания взаимоотношений.
В предлагаемой далее унифицированной БД принято кардинальное решение, позволяющее группировать данные в форматах тех или иных документов не меняя структуру и связи таблиц. Некоторые её варианты без всяких нареканий несколько лет эксплуатировались в системе делопроизводства городской мэрии.
Структура УБД показана на рисунке. Характеристики относящиеся к метаданным выделены синим цветом, а относящиеся к данным – красным или розовым. Виртуальные связи объектов показаны зелёным. Поскольку представлена реализация УБД в реляционной базе, то все параметры, характеристики и данные размещены в нескольких реляционных таблицах.
Назначение этих таблиц указано сверху чёрным жирным шрифтом и они выделены окрашенным прямоугольным полем. Поскольку данные различного типа (строки, длинные тексты, дата-время, целые и реальные числа разной разрядности) требуют различных полей в БД, то для каждого их типа предназначена своя таблица. Их массив показан жёлтым.
Для работы с данными, например с файлами мультимедиа, понадобятся конкретные сервисы. Соответствующее ПО тоже может быть автоматически загружено из УБД. Названия ключевых полей таблиц выделены жирным шрифтом.
Сначала показан состав таблицы метаданных, в которой для каждого параметра, как возможного столбца в виртуальной таблице в УБД, описан вид данного, название и его назначение.
Ниже показаны связи метаданных при работе с данными. Описательные части опущены. Стрелками связаны управляющие и управляемые элементы. Конкретные SQL-запросы я здесь не обсуждаю.
Фиолетовая стрелка 1 работает при формировании состава объекта. Сам объект получает описание в метаданных и уникальное значение характеризующего его реквизита.
Фиолетовая стрелка 2 работает при занесении данных в объекты.
Код строки резервируется в начале транзакции занесения данных каждого экземпляра объекта.
При выборке данных объектов работает альтернативная синяя стрелка.
Чтобы объединить несколько таких баз в одну, нет необходимости вникать в структуру распределения данных по таблицам и выполнять импорт данных из каждой. Достаточно просто слить вместе те несколько таблиц, в которых содержится вся УБД.
Конфликтов не будет, если значения группы старших разрядов ключевых полей будут при регистрации БД выдаваться госструктурой, как это делается для автомобильных номеров.
Любой запрос сможет работать и в любой другой УБД, поскольку там можно виртуально создать именно требуемую для него среду используя информацию метаданных.