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 ее опубликовал в материалах математической конференции. Сейчас я лишь развил модель, введя принципы построения новых метауровней.
Как повышать метауровни я объясню в последующих тезисах статьи, когда будет посвободней со временем.

xuser,

Схема для примера, она толкьо напоминает схему Невода.
<xml version="1.0" encoding="UTF-8">
<xs:schema xmlns:xs=" http://www.w3.org/2001/XMLSchema">
<xs:element name="NEVOD_CINEMA_LIB" type="NEVOD_CINEMA_LIB_type" >
<xs:annotation> <xs:documentation>
Пример схемы для построения модели по метамодели структурная семантика
</xs:documentation></xs:annotation>
</xs:element>
<xs:complexType name="NEVOD_CINEMA_LIB_type">
<xs:sequence>
<xs:element name="UID" type="Integer_type" minOccurs="0" />
<xs:element name=" Наименование_библиотеки" type=" String1000_type " minOccurs="0"/ >
<xs:element name=" Фильмы" type="Фильмы_type" minOccurs="0"/>
<xs:element name="Дата_создания_библиотеки" type="Date_type" minOccurs="0"/ >
<xs:element name="Комментарий" type="String1000_type" minOccurs="0"/ >
</xs:sequence>
</xs:complexType>
<xs:complexType name="Фильмы_type" >
<xs:sequence>
<xs:element name="UID" type="Integer_type" minOccurs="0"/>
<xs:element name="Наименование" type="String1000_type" minOccurs="0"/ >
<xs:element name="Сюжет" type="String4000_type" minOccurs="0"/>
<xs:element name="Жанр" type="Жанр_type" minOccurs="0"/>
<xs:element name="Режиссеры" type=" Режиссер_type" minOccurs="0"/>
<xs:element name="Актеры" type=" Актер_type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="Жанр_type" >
<xs:sequence>
<xs:element name="UID" type="Integer_type" minOccurs="0"/>
<xs:element name="Дата_начала_съемок" type="Date_type" minOccurs="0"/>
<xs:element name="Дата_окончания_съемок" type=" Date_type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="Режиссер_type" >
<xs:sequence>
<xs:element name="UID" type="Integer_type" minOccurs="0"/>
<xs:element name="Форма участия" type="String_type" minOccurs="0"/>
<xs:element name="ФИО" type="Физ_лицо_type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="Актер_type" >
<xs:sequence>
<xs:element name="UID" type="Integer_type" minOccurs="0"/>
<xs:element name="Роль" type="String_type" minOccurs="0"/>
<xs:element name="ФИО" type="Физ_лицо_type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="Физ_лицо_type" >
<xs:sequence>
<xs:element name="UID" type="Integer_type" minOccurs="0"/>
<xs:element name="Фамилия" type="String_type" minOccurs="0"/>
<xs:element name="Имя" type="String_type" minOccurs="0"/>
<xs:element name="Отчество" type="String_type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="Integer_type">
<xs:restriction base="xs:integer"/>
</xs:simpleType>
<xs:simpleType name="Date_type">
<xs:restriction base="xs:date"/>
</xs:simpleType>

<xs:simpleType name="String_type">
<xs:restriction base="xs:string">
<xs:maxLength value="250"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="String1000_type">
<xs:restriction base="xs:string">
<xs:maxLength value="1000"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="String4000_type">
<xs:restriction base="xs:string">
<xs:maxLength value="4000"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>

xuser,

Внес поправку...

<xml version="1.0" encoding="UTF-8">
<xs:schema xmlns:xs=" http://www.w3.org/2001/XMLSchema">
<xs:element name="NEVOD_CINEMA_LIB" type="NEVOD_CINEMA_LIB_type" >
<xs:annotation> <xs:documentation>
Пример схемы для построения модели по метамодели структурная семантика
</xs:documentation></xs:annotation>
</xs:element>
<xs:complexType name="NEVOD_CINEMA_LIB_type">
<xs:sequence>
<xs:element name="UID" type="Integer_type" minOccurs="0" />
<xs:element name=" Наименование_библиотеки" type=" String1000_type " minOccurs="0"/ >
<xs:element name=" Фильмы" type="Фильмы_type" minOccurs="0"/>
<xs:element name="Дата_создания_библиотеки" type="Date_type" minOccurs="0"/ >
<xs:element name="Комментарий" type="String1000_type" minOccurs="0"/ >
</xs:sequence>
</xs:complexType>
<xs:complexType name="Фильмы_type" >
<xs:sequence>
<xs:element name="UID" type="Integer_type" minOccurs="0"/>
<xs:element name="Наименование" type="String1000_type" minOccurs="0"/ >
<xs:element name="Сюжет" type="String4000_type" minOccurs="0"/>
<xs:element name="Жанр" type="String_type" minOccurs="0"/>
<xs:element name="Режиссеры" type=" Режиссер_type" minOccurs="0"/>
<xs:element name="Актеры" type=" Актер_type" minOccurs="0"/>
<xs:element name="Дата_начала_съемок" type="Date_type" minOccurs="0"/>
<xs:element name="Дата_окончания_съемок" type=" Date_type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:complexType>
<xs:complexType name="Режиссер_type" >
<xs:sequence>
<xs:element name="UID" type="Integer_type" minOccurs="0"/>
<xs:element name="Форма участия" type="String_type" minOccurs="0"/>
<xs:element name="ФИО" type="Физ_лицо_type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="Актер_type" >
<xs:sequence>
<xs:element name="UID" type="Integer_type" minOccurs="0"/>
<xs:element name="Роль" type="String_type" minOccurs="0"/>
<xs:element name="ФИО" type="Физ_лицо_type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="Физ_лицо_type" >
<xs:sequence>
<xs:element name="UID" type="Integer_type" minOccurs="0"/>
<xs:element name="Фамилия" type="String_type" minOccurs="0"/>
<xs:element name="Имя" type="String_type" minOccurs="0"/>
<xs:element name="Отчество" type="String_type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="Integer_type">
<xs:restriction base="xs:integer"/>
</xs:simpleType>
<xs:simpleType name="Date_type">
<xs:restriction base="xs:date"/>
</xs:simpleType>
<xs:simpleType name="String_type">
<xs:restriction base="xs:string">
<xs:maxLength value="250"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="String1000_type">
<xs:restriction base="xs:string">
<xs:maxLength value="1000"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="String4000_type">
<xs:restriction base="xs:string">
<xs:maxLength value="4000"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>

xuser,

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

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

Таблицы хранения значений атрибутов.
Примером такой таблицы может стать структура <xs:complexType name="Физ_лицо_type" >.
Пусть создан объект "Физическое лицо" с UID=11, номера 9 и 10 зарезервируем для служебных целей.
Таблица хранения экземпляров (объектов) ФЛ будет названа TS_001_00011.
Для объектов репозитария зарезервируем несколько номеров и начнем нумерацию атрибутов пользовательских объектов с 51.
Запрос для
<xs:complexType name="Физ_лицо_type" >
<xs:sequence>
<xs:element name="UID" type="Integer_type" minOccurs="0"/>
<xs:element name="Фамилия" type="String_type" minOccurs="0"/>
<xs:element name="Имя" type="String_type" minOccurs="0"/>
<xs:element name="Отчество" type="String_type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
будет иметь вид:
Create Table TS_001_00011 (
UID INTEGER ,
ATR000051 CHAR(250) ,
ATR000052 CHAR(250) ,
ATR000053 CHAR(250) );

Кстати, построение последовательностей для генерации UID может быть любой, от скозной на все объекты, до построения UID для каждой таблицы отдельно. В примере будем использовать последний вариант. Пусть UID будут целые числа от 1 до 99999999. Этого для примера вполне хватит.

ViPRos ,
данная тема была бы новой лет 20 назад.
Тупить не надо, я ему про метамодели n-уровня, он мне тему ERP-PLM парит. Разницу пойми и встревай.
А не понимаешь - отвали.

Будет время - продолжу.

ViPRos,

Ладно, согласен, есть метамодель, Это же классическая объектная модель.
Так что, ее можно встроить в реляционную СУБД?
На основе классической объектной модели построено множество ООБД.
А здесь я развиваю тему построения структур на основе реляционной СУБД.
А современные проекты я делаю не на Линтере, а на платформе XDB Oracle.
Выбор сделан в сторону XDB именно потому, что ORM встроена в ядро СУБД.
Мне странно видеть, что в Релексе народ не понимает, что КОМ не строишь в ядро
реояционной СУБД, а вот ORM встроишь, что Oracle и подтверждает.

Xuser,
Есть
<xs:complexType name="Физ_лицо_type" >
<xs:sequence>
<xs:element name="UID" type="Integer_type" minOccurs="0"/>
<xs:element name="Фамилия" type="String_type" minOccurs="0"/>
<xs:element name="Имя" type="String_type" minOccurs="0"/>
<xs:element name="Отчество" type="String_type" minOccurs="0"/>
</xs:sequence>
</xs:complexType>

Это соответствует запросу вида:
create type "Физ_лицо_type"
("Фамилия" char(250),
"Имя" char(250),
"Отчество" char(250)
)
;

Таблицу хранения генерируем автоматически.
Запрос на построение объекта хранения будет иметь вид.
будет иметь вид:
Create Table TS_001_00011 (
UID INTEGER ,
ATR000051 CHAR(250) ,
ATR000052 CHAR(250) ,
ATR000053 CHAR(250) );

Но можно построить и именованную структуру объекта хранения.

Create table store "Мой набор ФЛ" as type "Физ_лицо_type";
Мы создаем объекты по ранее созданной структуре, которая может иметь собственное семантическое значение.
Более того мы можем распознавать состав структур, выделять стандартные структуры типа агрегат, иерархия и цепочка, а также распознавать на их основе более сложные структуры.
Представив функции обработки в виде схем БП, мы можем также расопзнавать и их.

А вот как управлять полем UID объектов - дело вкуса.
Можно отлать все на откуп системе и вообще его не упоминать, либо отдать все для управления пользователям.
Скорее всего, разумнее было бы найти "золотую середину"...

ТАК ДЛЯ ЧЕГО ЖЕ НУЖНО РАСПОЗНАВАТЬ СТРУКТУРЫ ТИПОВ ОБЪЕКТОВ?
Вот мы и подошли к самому интересному - множественным атрибутам.
Это и есть знаменитые Nested Table - таблицы управления экземплярами.
Таблицы организуют внутренние связи 1 к n, то есть одному экземляру объекта (объекту) соответствует n наборов атрибутов (связанных объектов). Все остальное тривиально.
Объекты описываются в репозитарии, и генерируются объекты хранения.
Все это реализовано в Oracle. Синтаксис запросов можно взять у него же или поискать в стандарте SQL-2003.