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

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

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

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

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

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

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

Часть 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 ручками, а ООП был только в зародыше и нами вообще не использовался. Множественный тип атриутов существует.