Подмодератор_подфорума,

Могу себя предложить

Подмодератор_подфорума,

Довольно забавно самому себе отчевать...

Подмодератор_подфорума,

,Ребята, жду ответа, иначе... Сами напросились...

Подстрекатель,

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

Подстрекатель,

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

Как_бы_ты_уже_достал,

ребята, давайте жить дружно... А не то хуже будет...

Подстрекатель,

или провокатор?

Подстрекатель,

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

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

Часть 1.

Что такое хранилище данных.
Мертворожденный по версии некоторых мыслоедов стандарт ISO 19504 вполне здраво дает описание DW как совокупности трех метамоделей: экземплярной, объектной, орагнизации связей.
Метамодель - правила построения моделей, такой шаблон, по которому строятся модели.
Для построения DW нужно реализовать 3 правила:
- как строить экземпляры объектов,
- как строить объекты,
- как организовывать взаимосвязи между объектами.
Вроде и непонятный стандарт, но за ним стоит вполне понятная технология.

Подстрекатель,

Часть 1 продолжение.

DW - методика логической организации в виде объектов и их описаний постредством метаданных.
Когда я наблюдал, как описываются таблицы в СУБД Линтер, то подумал, а почему бы не описать таким же образом объекты.
Были созданы таблицы для описания структуры объектов. Позже эти таблицы стали называть репозитарием метаданных.
DW, таким образом, состоит условно из 2-х частей: репозитария метаданных и области хранения значений объектов.
Существуют две нотации описания объектной технологии:
Структуру объектов называют по первой нотации типом объекта,
а совокупность значений атрибутов объекта - объектом.
По другой нотации структура объекта - объект, а совокупность значений атрибутов - экземпляр объекта.

Подстрекатель,

Часть 1. Продолжение.

Таблицы репозитария метаданных.
Почему-то современные СУБД посчитали, что метаданные описывают только способ организации объектов.
Но это заблуждение, т.к. метаданные являются основой построение фреймуорка обработки самих объектов.
Поэтому метаданные должны быть доступны пользователю для организации прикладной обработки объектов.
Строим таблицы репозитария:
- таблица справочника типов объектов,
- таблица справочника типов атрибутов,
- таблица спсика типов объектов (объектов),
- таблица списка атрибутов объектов,
- таблица списка бинарных связей,
- таблица списка структур бинарных связей.
- таблица списка репозитариев.
Всего 7 таблиц описывают репозитарий метаданных.

Подстрекатель,

Часть 1. Продолжение.

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

xuser,

Линтер запросы на создание таблиц репозитария.
Create Table DICT_OF_REP (
UID INTEGER ,
NAME CHAR(80) ,
LEVEL_MD INTEGER
) ;


Create Table DICT_OF_OBJECT (
UID INTEGER ,
UID_REP INTEGER ,
NAME CHAR(80) ,
UID_TYPE_OBJ INTEGER
) ;

Create Table DICT_OF_ATTRS (
UID INTEGER ,
NAME CHAR(80) ,
UID_REP INTEGER ,
UID_OBJ INTEGER ,
TYPE_ATR INTEGER ,
LINK_OBJ_UID INTEGER ,
LENGTH INTEGER ,
POZITION INTEGER
);

Create Table DICT_TYPE_OBJECT (
UID INTEGER ,
NAME_TYPE_OBJ CHAR(30) ,
UID_REP INTEGER) ;

Create Table DICT_TYPE_ATTRS (
UID INTEGER ,
NAME_TYPE_ATR CHAR(30) ,
UID_REP INTEGER) ;


Create Table LINKS (
UID INTEGER ,
UID_REP INTEGER ,
UID_REP1 INTEGER ,
UID_OBJ1 INTEGER ,
UID_OBJ1_ATR INTEGER ,
UID_REP2 INTEGER ,
UID_OBJ2 INTEGER ,
UID_OBJ2_ATR INTEGER ,
UID_CHAR_LINK INTEGER
) ;

Create Table LINK_STRUCTURE (
UID INTEGER ,
UID_REP INTEGER ,
UID_LINK INTEGER ,
LINK_NUMBER INTEGER ,
UID_CHAR_LINK INTEGER
) ;

xuser,

Часть 1. Продолжение.

Метамодель DW.

Итак, метамодель - правила построения моделей.
Таблицы моделей содержат атрибуты со значениями.
Таблицы моделей составляют область хранения значений.
Таблицы моделей содержат экземпляры объектов в виде своих строк.
Т.е. строки таблиц моделей являютс экземплярами объектов (объектами).

Строим экземпляры объектов (объекты) по следующим правилам:
- каждая строка таблицы хранения содержит поле UID - идентификатор экземпляра объекта (объекта),
- все бинарные связи модели образуются путем указания пары UID объектов, образующих бинарную связяь.

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

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

Вот и все правила построения моделей.

xuser,

Часть 1. Продолжение.

Соглашение о наименовании таблиц.

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

xuser,

Лирическо-философское отступление.

Что же первично, структура или содержание?
Мы можем описать собственную структуру таблиц репозитария, которая станет вместе с метамоделью основой для построения множества моделей постредством инструмеентального средства. То есть, цель не построить метамодель, а построить инструментальную оболочку. которая, опираясь на метаданные даст возможность генерировать запросы построения таблиц области хранения данных и манипулировать экземплярами объектов (объектами).
Есть идея, она воплощается в структуры и правила, которые воспроизводят новые структуры и правила.
В этом плане интересно построение метамодели на основе объектов области хранения. Зачем строить репозитарий и метамодель на платформе уже готовой метамодели? Ответ совершенно практичный - для того, чтобы использовать весь багаж возможностей манипулирования объектами более низкого уровня метаданных и встроить свое предметное DW для манипулирования объектами на основе метаданных своего репозитария. Пример: есть репозитарий объектов Oracle. При регистрации XSD схемы в режиме object relation store мы заполняем системный репозитарий метаданными, но они доступны только пользователю SYSTEM.
Мы хотим скопировать данные в свой репозитарий и построить мапинг 'элементов зарегистрированных схем на атрибуты объектов собственной метамодели. По сути, мы связываем объекты нижнего уровня метаданных с объектами более высокого уровня метаданных. Это и есть механизм повышения уровня метаданных. Мы можем не связывать объекты, а просто построить свою метамодель. И в этом случае мы повысим уровень метаданных нового авторского репозитария и уровень метаданных метамодели.

xuser,

Часть 1. Продолжение.

Пример создания и заполнения таблиц репозитария по правилам построения.
Пример следует...

xuser,

представляешь, лень - описывать не мысленный полет, а прецеденты реальности восприятия в виде SQL запросов.
Но соберусь и выдам... Завтра.

xuser,

/* Список репозитариев – самый первый объект репозитария
Create Table TR_001_00001 (
UID INTEGER ,
ATR00001 CHAR(80) ,
ATR00002 INTEGER );

/* Создаем 1 запись начального репозитария */
Insert into TR_001_00001 (UID, ATR00001, ATR00002) VALUES
(1, ‘ Репозитарий начального уровня‘, 1);

/* Список типов объектов репозитария */
Create Table TR_001_00002 (
UID INTEGER ,
ATR00003 CHAR(80) ,
ATR00004 INTEGER
) ;

/* Создаем записи типов объектов (объектов) */
Insert into TR_001_00003 (UID, ATR00003, ATR00004) VALUES
(1, ‘Репозитарий’, 1);
Insert into TR_001_00003 (UID, ATR00003, ATR00004) VALUES
(2, ‘Объект’, 1);
Insert into TR_001_00003 (UID, ATR00003, ATR00004) VALUES
(3, ‘Ссылка на объект’, 1);
Insert into TR_001_00003 (UID, ATR00003, ATR00004) VALUES
(4, ‘Бинарная связь’, 1);
Insert into TR_001_00003 (UID, ATR00003, ATR00004) VALUES
(5, ‘Агрегат связей’, 1);
Insert into TR_001_00003 (UID, ATR00003, ATR00004) VALUES
(6, ‘Иерархия связей’, 1);
Insert into TR_001_00003 (UID, ATR00003, ATR00004) VALUES
(7, ‘Цепочка связей’, 1);

/* Репозитарий – агрегат объектов */

/* Список типов атрибутов объектов репозитария */
Create Table TR_001_00003 (
UID INTEGER ,
ATR00005 CHAR(80) ,
ATR00006 INTEGER
) ;

/* Создаем записи типов атрибутов */

Insert into TR_001_00003 (UID, ATR00005, ATR00006) VALUES
(1, ‘Ссылка на объект однозначная’, 1);
Insert into TR_001_00003 (UID, ATR00005, ATR00006) VALUES
(2, ‘Ссылка на объект многозначная’, 1);
Insert into TR_001_00003 (UID, ATR00005, ATR00006) VALUES
(3, ‘ Текстовый однозначный‘, 1);
Insert into TR_001_00003 (UID, ATR00005, ATR00006) VALUES
(4, ‘ Текстовый многозначный‘, 1);
Insert into TR_001_00003 (UID, ATR00005, ATR00006) VALUES
(5.‘ Числовой целый однозначный‘, 1);
Insert into TR_001_00003 (UID, ATR00005, ATR00006) VALUES
(6.‘ Числовой целый многозначный‘, 1);
...
И т.д. по типам данных СУБД, кроме ссылочных.

/* Создаем список объектов*/
Create Table TR_001_00004 (
UID INTEGER ,
ATR00007 INTEGER ,
ATR00008 CHAR(80) ,
ATR00009 INTEGER
) ;

/* Описываем объекты репозитария, их всего 7 */

Insert into TR_001_00004 (UID, ATR00007, ATR00008, ATR00009) VALUES
(1, 1,‘Список репозитариев’, 2);
Insert into TR_001_00004 (UID, ATR00007, ATR00008, ATR00009) VALUES
(2, 1,‘Список типов объектов’, 2);
Insert into TR_001_00004 (UID, ATR00007, ATR00008, ATR00009) VALUES
(3, 1,‘Список типов атрибутов объектов’, 2);
Insert into TR_001_00004 (UID, ATR00007, ATR00008, ATR00009) VALUES
(4, 1,‘Список объектов, 2);
Insert into TR_001_00004 (UID, ATR00007, ATR00008, ATR00009) VALUES
(5, 1,‘Список атрибутов объектов’, 2);
Insert into TR_001_00004 (UID, ATR00007, ATR00008, ATR00009) VALUES
(6, 1,‘Список бинарных связей’, 2);
Insert into TR_001_00004 (UID, ATR00007, ATR00008, ATR00009) VALUES
(7, 1,‘Список структур бинарных связей’, 2);

/* Создаем список атрибутов объетов*/
Create Table TR_001_00005 (
UID INTEGER ,
ATR000010 CHAR(80) ,
ATR000011 INTEGER ,
ATR000012 INTEGER,
ATR000013 INTEGER,
ATR000014 INTEGER,
ATR000015 INTEGER,
ATR000016 INTEGER,
) ;


Create Table DICT_OF_ATTRS (
UID INTEGER ,
NAME CHAR(80) ,
UID_REP INTEGER ,
UID_OBJ INTEGER ,
TYPE_ATR INTEGER ,
LINK_OBJ_UID INTEGER ,
LENGTH INTEGER ,
POZITION INTEGER
);

/* Описываем атрибуты объектов репозитария */
Insert into TR_001_00005 (UID, ATR000010, ATR000011, ATR000012, ATR000013, ATR000014, ATR000015, ATR000016) VALUES
( 1,‘Наименование репозитария’, 1, 1, 3, 0, 80, 1 );
Insert into TR_001_00005 (UID, ATR000010, ATR000011, ATR000012, ATR000013, ATR000014, ATR000015, ATR000016) VALUES
( 2,‘Уровень метаданных’, 1, 1, 5, 0, 2, 2);
Insert into TR_001_00005 (UID, ATR000010, ATR000011, ATR000012, ATR000013, ATR000014, ATR000015, ATR000016) VALUES
( 3,‘Наименование типа объекта’, 1, 2, 3, 0, 80, 1);
Insert into TR_001_00005 (UID, ATR000010, ATR000011, ATR000012, ATR000013, ATR000014, ATR000015, ATR000016) VALUES
( 4,‘Репозитарий’, 1, 2, 1, 1, 3, 2);
Insert into TR_001_00005 (UID, ATR000010, ATR000011, ATR000012, ATR000013, ATR000014, ATR000015, ATR000016) VALUES
( 5,‘Наименование типа атрибута’, 1, 3, 3, 0, 80, 1);
Insert into TR_001_00005 (UID, ATR000010, ATR000011, ATR000012, ATR000013, ATR000014, ATR000015, ATR000016) VALUES
( 6,‘Репозитарий’, 1, 3, 1, 1, 3, 2);
Insert into TR_001_00005 (UID, ATR000010, ATR000011, ATR000012, ATR000013, ATR000014, ATR000015, ATR000016) VALUES
( 7,‘Репозитарий’, 1, 4, 1, 1, 3, 1);
Insert into TR_001_00005 (UID, ATR000010, ATR000011, ATR000012, ATR000013, ATR000014, ATR000015, ATR000016) VALUES
( 6,‘Репозитарий’, 1, 5, 1, 1, 3, 1);
Insert into TR_001_00005 (UID, ATR000010, ATR000011, ATR000012, ATR000013, ATR000014, ATR000015, ATR000016) VALUES
( 8,‘Наименование объекта’, 1, 5, 5, 0, 80, 2);
Insert into TR_001_00005 (UID, ATR000010, ATR000011, ATR000012, ATR000013, ATR000014, ATR000015, ATR000016) VALUES
( 9,‘Тип объекта’, 1, 5, 1, 2, 2, 3);

И т.д.

xuser,

Строка атрибута 6 лишняя, не заметил...

Alexander1111,

Таблица DICT_OF_ATTRS указана для понимания соответствия построения структуры репозитария по правилам построения объектов.

Alexander111,

Правильное наполнение таблицы 5 - списка атрибутов объектов

/* Описываем атрибуты объектов репозитария */
Insert into TR_001_00005 (UID, ATR000010, ATR000011, ATR000012, ATR000013, ATR000014, ATR000015, ATR000016) VALUES
( 1,‘Наименование репозитария’, 1, 1, 3, 0, 80, 1 );
Insert into TR_001_00005 (UID, ATR000010, ATR000011, ATR000012, ATR000013, ATR000014, ATR000015, ATR000016) VALUES
( 2,‘Уровень метаданных’, 1, 1, 5, 0, 2, 2);
Insert into TR_001_00005 (UID, ATR000010, ATR000011, ATR000012, ATR000013, ATR000014, ATR000015, ATR000016) VALUES
( 3,‘Наименование типа объекта’, 1, 2, 3, 0, 80, 1);
Insert into TR_001_00005 (UID, ATR000010, ATR000011, ATR000012, ATR000013, ATR000014, ATR000015, ATR000016) VALUES
( 4,‘Репозитарий’, 1, 2, 1, 1, 3, 2);
Insert into TR_001_00005 (UID, ATR000010, ATR000011, ATR000012, ATR000013, ATR000014, ATR000015, ATR000016) VALUES
( 5,‘Наименование типа атрибута’, 1, 3, 3, 0, 80, 1);
Insert into TR_001_00005 (UID, ATR000010, ATR000011, ATR000012, ATR000013, ATR000014, ATR000015, ATR000016) VALUES
( 6,‘Репозитарий’, 1, 3, 1, 1, 3, 2);
Insert into TR_001_00005 (UID, ATR000010, ATR000011, ATR000012, ATR000013, ATR000014, ATR000015, ATR000016) VALUES
( 7,‘Репозитарий’, 1, 4, 1, 1, 3, 1);
Insert into TR_001_00005 (UID, ATR000010, ATR000011, ATR000012, ATR000013, ATR000014, ATR000015, ATR000016) VALUES
( 8,‘Наименование объекта’, 1, 4, 5, 0, 80, 2);
Insert into TR_001_00005 (UID, ATR000010, ATR000011, ATR000012, ATR000013, ATR000014, ATR000015, ATR000016) VALUES
( 9,‘Тип объекта’, 1, 4, 1, 2, 2, 3);

И т.п.

Надо на свежую голову репозитарий описывать, но обещал...

xuser,

ORM в СУБД это не совсем то, что ООП.
Тот же Oracle притягивает методы к типам, но это искусственно, т.к. методы процедурные, а не генерируемые по XSD схемам метамодели исполняемых объектов.
Вот если бы метод отражал бы структуру сценария обработки объектов, то он стал бы метаданными объекта.
Связка "тип-супер тип" очень проста. Объект "супер тип" содержит атрибут типа "ссылка" на объект-"тип".
Что значит, "какие атрибуты могут иметь объекты данного типа"?
Какие объекты могут иметь в своем составе атрибут типа "ссылка" и ссылаться на объекты-подтипы?
Да любые объекты типа "объект".
Вот заполнение списка связей и структур связей, построение объектов хранения связей и структур связей надо пояснить отдельно.

Увидел ошибку, правильно:
Insert into TR_001_00005 (UID, ATR000010, ATR000011, ATR000012, ATR000013, ATR000014, ATR000015, ATR000016) VALUES
(8,‘Наименование объекта’, 1, 4, 3, 0, 80, 2);

xuser,

я построю простую XSD схему, опишу ее структурами репозитария и построю по ней объекты.
Если есть своя схема, то предлагай, мне совершенно безразлично, что описывать, лишь был не очень большой объем.

xuserА зачем вообще может быть нужно ORM, как не для поддержки ООП?
Иначе в принципе и реляционной схемы вполне достаточно.

Посмотри, какие SQL запросы в Неводе генерируются, select на 5-6 KB - влегкую.
Я же сам структуру select iin select придумал использовать.
Ты еще тест, на котором Линтер упал, моей фамилией назвал.
Все бы ничего, запросы генерируются по правилам, но появились метаданные.
Невод - Аскрин тем и был хорош, что метаданные для генерации форм, отчетов и запросов активно используются.
Я же это и придумал. Но дело не в этом, метаданные дают возможность использовать структуру в качестве семантического наполнения. Это сплошь и рядом делается в предметных областях.
Для стурктурирования данных в виде объектов используют XSD. XSD и XML - это не ООП, это данные и метаданные.
Вот ООП их активно использует. Да, я тоже в web приложениях использую ООП, но только для нижнем уровне в SOA, т.к.
появилась альтернатива OOП - BPMS. Внизу ООП, а вверху структуры сценариев, а не структурированный по правилам ООП код.
Вот ответ на твой следующий пост.
xuserЧто-то не понял. А какими еще могут быть методы, кроме как процедурными?

Есть нотация описания BPM - BPMD. Могу выслать стандарт, если надо. И все BPMS системы пишут в БД структуры сценариев.
Действия стали данными. Это уже не процедурные методы. Я просто отслеживаю тенденции и считаю, что за этим будующее,
когда данные фактов и действий объединятся на уровне метаданных, повысив их уровень и применимость.

xuserКак найти список всех типов, к которым относится данный объект? Строить цепочки? Кстати, предполагается ли множественное наследование между типами?

Этот вопрос построен на принципах понимания ООП. Вот есть объект, в метаданных есть описание типа, к которому он относится, и список ссылочных атрбутов. Найти все связи объекта является чисто техническим вопросом. Тебе струтктура SQL запроса нужна? Вот наследование - это к методам обработки. Объекты не являются собственностью OOП. Ты прекрасно понимаешь и знаешь, что мы создали объекты, когда все структуры создавались в C/ANSI ручками, а ООП был только в зародыше и нами вообще не использовался. Множественный тип атриутов существует.

xuserКаждый атрибут, насколько я понимаю, имеет имя. Как найти имена всех атрибутов данного типа (включая все его супертипы)?

Каждый атрибут имеет имя и тип. Что значит, супер тип атрибута? Супер тип есть у объекта. Если атрибут является ссылкой в структуре объекта, то можно найти объект, на который он ссылается. Можно найти все ссылки объекта, найти все объекты, на которые данный объект, содержащий данный атрибут ссылается. Можно пройти по всей цепочке ссылок в струтре объекта до самого низа или верха иерахической структуры. Объекты с обной строны агрегаты, а с другой - иерархии связей в структуре объекта.

xuser,

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

xuser,

Часть 1. Продолжение.
Построение БС не в структуре объекта и стрктур связей.
БС в общем случае является агрегатом пары связанных объектов и объекта, содержащего характеристики связи.
Объект (тип объекта) определяет струтктуру связи, а таблица хранения связи содержит экземпляры объектов (объектов). Иногда такую БС называют внешней по отношению к структуре объекта.
Структуры объектов, как и БС, являются объектами модели и строятся по следующим правилам:
- структура состоит более, чем из 1 БС,
- структура может имееть с своем составе в последней позиции БС, которая связывает структуру и объект, характеризующий структуру БС.
- структра может состоять из связей только двух соседних уровней метаданных.
Пока я еще не придумпл, зачем связывать объекты разных уровней метаданных в цепочку, и могут ли быть разрывы уровней?
Все впереди...
Пример, по XSD. .. Надо построить XSD по тестовому примеру Невода с фильмами и актерами. А то XSD построим все объекты.
Продолжение следует.

xuserКаждый атрибут, насколько я понимаю, имеет имя. Как найти имена всех атрибутов данного типа (включая все его супертипы)?

Каждый атрибут имеет имя и относится к одному из типов. У атрибута нет супертипа. Супер типа вообще не сушествует, но есть тип который является родителем для подтипа по связи в структуре объекта "часть - целое". Родительский тип объекта можно назвать супертипом, а к атрибуту это не может относиться.


xuserСупертип B типа A имеет атрибуты, которые по определению супертипа входят в число атрибутов типа A.
Я ожидал, что такой базовый для объектной модели момент должен быть зашит в структуру метаданных, но не вижу этого.

Это для объектной модели по нотации ООП базовый момент, но я же несколько раз подчеркивал, что в СУБД разный подход к данному моменту. Ты воспроизвел принцип наследования, но он относится к методу. Если переменная С имеет тип супертипа В,
по имеет в своем составе все атрибуты типа В. В СУБД нет такой процессуальности, здесь не формируются связи типа структура типа B состоит из структуры типа N и структуры типа D и является супертипом для переменной N и D. Здесь если и есть структура, то она явялется оисанием своего состава. Ведь связь между структурами является агрегатом. Мы же можем описать агрегат, но не процессуально с целью передачи параметров из одной процедуры в другую, как это имеет быть целью в ООП, а для фиксации и обработки факта установления такой связи.

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

Не бессмысленно же связано. Есть опасность наворотить. Так в естественном языке еще большая гибкость, и что, язык стал неээфективным средством описания действительности? Могут быть связаны иерархии и ветки иерархий. Ине просто абы как, а по правилам. Вот в Неводе бинарные связи тоже связываюь любые объекты с любыми. Там я атрибуты не стал связывать, а здесь даю такую возможность. А почему бы не дать? Смысл такие связи имеют.

xuserТот подход, который предлагается, лично мне кажется достаточно ограниченным.

Особенность и перспектива развития современных СУБД заключается в активном использовании метамоделей и метаданных под самым различным углом. Что дает сложная организация данных в СУБД? По моему мнению только одно - возможность манипулировать сложно организованными данными, добавляя и к одним данным другие, связывая все в плотный клубок взаимосвязей. И это не самоцель, а потребность выявить и использовать скрытых закономерностт данных путем усложнения их организации. Я только обозначил возможность построения метамоделей на основе объектов хранения метамодели нижнего уровня.
Осмыслить такой подход не просто, хотя это лишь дело времени. Думаю, говорить об ограничениях при таких возможностях преждевременно. Запад называет 21 век - "Великим путем в метаданные", а мы на метаданные косимся, как на бесполезную вещь.
Представляешь, мы тогда в 1994 разработали такие технологии, которые потом составили основу построения XML, XSL, XSD.
Когда делаешь что либо без сомнений и заминок, то в ороткий срок получается сделать многое. Помнишь, даже тебя и Саню М. заставили кодировать модули Аскрина. Времени сомневаться не было. У нас просто не было ресурсов, да и никто не ставил целей - разработать процессуальные языки. Но метамодель и метаметамодель и метамодель инструментальной оболочки мы разработали. Де факто все современные реляционные СУБД внедряют в свои явра ORM, активно используют метаданные и это не спроста. Именно с метаданными связаны конкурентные преимущества СУБД. Сейчас и процедуры становятся структурированными в формате объектов. Уже не составляет труда "проиграть" объект. А я никого не обязываю поступать по конретному сценарию, жизнь все расставляет по своим местам...Мне, например, очень нравится понимать объектную технолгию Oracle глубже многих.
Просто подошло время, когда оно же и расставило акценты на активном использовании ORM. А я так и не видел статьи об ORM Oracle. Думаю, мой опыт построения ORM будет полезен. Эту модель я разработал в 1996 году, а в 1997 ее опубликовал в материалах математической конференции. Сейчас я лишь развил модель, введя принципы построения новых метауровней.
Как повышать метауровни я объясню в последующих тезисах статьи, когда будет посвободней со временем.