ViPRosЕще
Мигрирующие ссылки и Свойства
ну, можн выделить механизм обоспечения расшифровки суррогантных идентификаторов всего перечисленного
Только сало с горчицей.

ViPRosБредятина,
ладно работать надо
скоро все равно придется документировать, год уже футболю :)
Может еще немного пофутболить? Отточить, так сказать, мастерство на тренировках?:)

ViPRosХрактеристика ничуть не информативнее Свойства.

С Вами не соскучаешься:) Я Вам объяснил четыре (!!!) раза почему понятие "свойство" не корректно использовать, а Вы мне объясняете что "информативнее", а что нет. Ну я не против Вас понимать (это Вы категорически не хотите понимать), давайте вводите критерий "информативности":)
ViPRosТип и больше и меньше чем Объект. Больше в смысле Тип как Классификатор Объектов по совпадению типовых свойств.

Итак, пока Ваш "тип" - это то же самое, что и объект в классической объектной модели данных. Который Вы будете старательно мэппировать на отношение (или отношения? - это требует отдельного пояснения) "реляционной" модели данных. Вы понимаете, что объект в классической объектной модели данных не нужно никуда мэппировать? В среде классической объектной СУБД.
ViPRosМеньше в смысле не все Свойства Объекта Тип классифицирует.
Тип как сито, пропускает Объекты через полное совпадение однотипных :) Свойств Типа и Объекта, при этом у Объекта может быть и другие Свойства, которых нет в списке свойств Типа.

Итак, у в Вашей дополнительной модели данных, которую Вы надстраиваете над реляционной моделью данных, объект - это тоже самое, что экземпляр объекта в классической объектной модели данных. Я Вам уже объяснял, что пара "объект-экземпляр" проще и эффективнее, чем пара "класс-объект" (у Вас - "тип-объект"). Но это "мелочи". Главное - у Вас объекты одного типа имеют разные свойства (я стараюсь использовать Вашу терминологию, если явно не указываю терминологию классической объектной модели данных). Это что такое и зачем? Может Вы говорите о супертипах и типах (суперклассах и классах)? О наследовании?
[quot ViPRos]
Ссылка на тип
Это такое сложное Свойство, где Свойством является другой Тип. Через такие Свойства получем доступ к другим Типам полностью или частично.
Это Свойство обеспечивает Связь.
[quot ViPRos]
Ну наконец-то:) Значит никаких связей у Вас, как и в РМД, нет. Замечу, что "Ссылка на тип" у Вас - это не "такое сложное свойство", а просто тип свойства. Это, конечно, не то же самое, что и "внешний ключ" в РМД, но очень кривая конструкция. Я уже много раз объяснял, что если уж идентификаторы объектов не являются значениями свойства типа (я опять использую исключительно Вашу терминологию), то идентификаторы объектов других типов тем более не должны являться значениями свойств типа. Ну а частичный доступ, пока, за пределами понимания. Видимо, Вы будете вводить еще одно понятие для объяснения.
Итак, связи между типами у Вас не поддерживаются, а просто сделана конструкция, которая обеспечивает относительную простоту мэппирования в другую модель, без которой Ваша модель не работает.
ViPRosМакротип.
Для формирования и идентификации более сложных понятий через Связи. Это не Обобщение, а плоская Агрегация. Несколько связанных объектов образуют новое качество. Пальцы, Руки, Ноги, Голова, Глаза, Туловище = Человек.

Давайте по-конкретнее.

У Вас есть Тип "Палец" (типы, классы, объекты, отношения лучше именовать в единственном числе). У него есть свойства:
1 Длина в мм
2 Номер на руке
3 Рука ("ссылка на тип")

Так же у Вас есть Тип "Рука" со свойствами:
1 Длина руки в см
2 Тип руки (правая или левая - не знаю какой тип свойства у Вас для этого используется).
3 Человек ("ссылка на тип")

И, наконец, у Вас есть Тип "Человек" со свойствами:
1 Фамилия
2 ...

Так?

И чем эта "конструкция" отличается от Квартира-Дом-Город? Тем, что Квартира, Дом и Город в Вашем предыдущем примере - это не типы с многичисленными характеристиками (Площадь квартиры, Тип планировки, ...), а просто элементы классификатора (то есть, просто строки). Так?
Я все пытаюсь понять целесообразность "макротипов" и "классификаторов". И опять прихожу к заключению, что классификатор должен быть реализован как тип свойства (в Вашей терминологии).
ViPRosКлассификатор.
Это очень важный семантический инструмент обобщения и специализации.
У меня их несколько - по способу классификации. :) Не буду перечислять.

Задумайтесь над тем, что я Вам уже много раз объяснял. Любой тип свойства - это классификатор. Поэтому не серьезно делать классификатор НЕ ТИПОМ СВОЙСТВА.
ViPRosТип связи.
Ну до "Имеет" рядь ли когда придется опуститься. Тип связи почти полностью можно заменить Классификатором. Но тогда приходится создать связи между Классификаторами, что намного сложнее для понимания.

Поскольку связей у Вас просто нет, "связь" у Вас - тип свойства типа "Ссылка на тип", рассуждения о типе связи теряют какой-либо смысл вообще:)
ViPRosПриведу пример. Все Понятия здесь от модели предметной области.
Технолог назначил на Операцию Металлорежущий станок со скоростью шпинделя 100000 об/с.
Этот объект типизирован как Оборудование.
При планировании операции надо найти конкретный станок с такими характеристиками.
Конкретные станки типизированы в Оборудование в эксплуатации.
НООООО, а откуда это известно? Они могут быть (так и есть на самом деле) типизированы где угодно, и в Основных средствах, и в Оборудовнии к установке и т.д.
Как нам вычислить, что этот долбаный станок надо искать именно в Оборудование в эксплуатации?
Все указанные типы ссылаются на Оборудование, но только связь с Оборудование в эксплуатации типизирована как "Экземплярный класс", остальные по умолчанию "Навигация".
Тип связи "Экземплярный класс" решает все проблемы в данном и в многих других случаях.
А Классификатор "Экземплярный класс" ничего бы не дал в этом случае, так как там нет связи между Оборудование и Оборудование в эксплуатации. Факт что Оборудование в эксплуатации "Экземплярный класс" привел бы к поиску пути от него до Оборудование, чо очень затратно.

Ну вот, а магазин-то уже закрыт:(
Из ЭЛЕМЕНТАРНОЙ ЧАСТИ схемы БД Вы, на ровном месте, выдумали какую-то проблему путем применения Вашей модели (главный ее аспект в Вашем примере - интерфейсная часть) к реляционной модели:)
Технолог, обычно, в технологической карте не указывает конкретный экземпляр станка, а указавает тип станка для выполнения конкретной операции (особенно, если на предприятии много станков такого типа, да еще в разных цехах). У конкретного станка есть тип и есть свойство, которое "говорит" о том, что его в определенный период времени можно использовать (не ремонтируется, например, а именно находится в эксплуатации). Какие еще "экземплярные классы" и "навигации"?

ViPRosРоль типа.
А чем эта семантика задается то?
Живет(Человек, Дом). ЕСли допустить, что семантика определяется Порядком, то да. Но это очень простое предложение. А если порядка не будет? КТО Живет? ГДЕ живет?
КТО Роль которая приписывается Человеку, ГДЕ Дому.
И тут я могу спросить, а дай ко мне Вех КТО во всех Отношениях.
То есть получил дармовой Классификатор КТО и ГДЕ. А для чего Классификатор уже говорил.
Классификатор сложный и затратный механизм. А Тип связи и Роль типа простые.

Я продолжаю тщательно вчитываться в Ваши сообщения, а Вы продолжаете тщательно игнорировать то, что человечество давно прошло и перепахало:)
Смотрите определение связи между объектами в классической объектной модели данных.
ViPRosСобытие типа.
Метод типа.
Это поведенческий аспект из ООП. Нечего говорить особо.

А-а-а, ну нечего, так нечего. Значит к Вашей модели это не имеет отношения?
ViPRosОграничение типа.
Тут ссылочная целостность, определенность значений, уникальность, валидность на уровне объекта, типа, макротипа.
Не так сильно пока как хотелось бы, нет своего языка, а имеющийся куцый и затратный.

Ну, хорошо, раз не так сильно хотелось бы:)
ViPRos+ некоторые вещи для маппинга в РСУБД.

А тут определяющим фактором является место и время, скилзы окружающих, особенно покупателей и заказчиков.
Н уи кроме того СКЛ очень мощный тестомещатель, иногда можно прикрыть задницу если модель не тянет чего-то.
[/quot]
А почему же ВСЕГДА И ВЕЗДЕ ЗАДНИЦУ НЕ ПРИКРЫВАТЬ обязаны спросить у Вас специалисты по "реляционной технологии"!:) Вместо того чтобы городить ЕЩЕ ОДНУ задницу и прикрывать уже две задницы?!

ViPRosа насчет задницу прикрывать
че блин мне теперь сидеть писать ISAM????? Сортирвку????
Не знаю что такое Классическая объектная модель.
Знание по этому поводу какого то Мартина читал в 85 году.
СУБД Классическая объектная модель незнаю.
Сказал бы. ПОсмотрю сразу.
У этого Халпина ниче особенного нет, те же яйца
:) очередной крик души.
С одной стороны, Вы сказали, что никаких запросов не пишите, то есть, это надо понимать так, что у Вас пользователи сами получают все необходимые данные и отчеты (и при этом, что там внутри - SQL или не SQL не имеет совершенно никакого значения). С другой стороны, Вы говорите, что это все-таки не так, и ВАМ САМОМУ приходится писать запросы на SQL.
То есть, вместо того, чтобы повысить мощность своего инструмента, в рамках объективной необходимости (так как очевидно, что он весьма слаб, раз Вам приходится программировать запросы), Вы обреченно постоянно что-то программируете:)
Собственно "Р"СУБД и придуманы для того, чтобы постоянно программировать и бороться, таким образом, с безработицей. Вот у Вас же не получилось написать приложение на SQL, чтобы больше не программировать:) Вы приделали еще одну (намного более сложную) модель к РМД, а Ваше приложение опять не работает (!). Опять нужно что-то программировать.
Что касается SQL, то я уже показал на банальных статистических данных всю бесполезность этого языка для создания приложений.
А что касается Вашего незнания всех аспектов теории и практики баз данных, то тут Вам вряд ли кто-то сможет помочь:)

ViPRosНет, все эти супертипы, наследование и т.д. более конкретные) получается типизацией связей.
Тип - вторичен, основное его применение - классификация объектов по шаблону.
Объект может быть типизирован много раз.
Объекту Тип пофиг, он воще живет в Объектном хранилище. Я уже писал об этом.

Откуда берется объект и как он типизируется?
ViPRosМне очень даже понятно что любое свойство является классификатором, нечего об этом так много говорить. Я ж раньше говорил о классификаци по типу своцстваи по значению свойства.

То есть, Вы подтверждаете, что "классификатор" - это тип свойства типа?
ViPRosО "конструкциях" Палец-Рука-Человек и Квартира-Дом-Город.
Ничем не отличаются, просто я не рисую свойства.

Так а зачем же тогда столько разных понятий в Вашей "неизвестной модели"? Если ничем не отличается? Я то пытался Вам помочь, объяснял, чем, видимо, отличается. А Вы говорите ничем не отличается:)
ViPRosЯ уже много раз говорил что ЛЮБОЕ свойство есть классифкатор. Но, это разбивающий классификатор. Есть еще агрегирующие, обобщающие и т.д.

Да я не против таких типов свойств типов, как "строка", "число", "просто классификатор", "обобщающий классификатор", "агрегирующий классификатор" и т.д.
ViPRosЗначит не смог донести суть проблемы. Отвлекись от технолога и спряь знания о прдметной области.
Нам нужен СЕМАНТИЧЕСКИЙ ПЕРЕХОД от типа ОБОРУДОВАНИЕ к типу ОБОРУДОВАНИЕ В эксплуатации или к любому другому, который является типом-контейнером экземпляров типа-контейнреа классов оборудований.

Ну, это к коллегам по несчатью - программистам, которые пытаются скрестить ООП с РМД:) Я уже совершенно конкретно и неоднократно объяснял суть этой "проблемы".
ViPRosТо бишь мне пофиг КАК эти типы названы и сколько их, я не работаю напрямую с типами практически. Классификаторы, Типы связей, Рои типов, Макротипы. Вот чем я работаю. Т.е. нет функции ОткрытьТип, и т.д. Минимальный уровень макротип.

Классификатор, Тип связи и Роль типа - это лишние понятия, полезность которых Вы так и не смогли объяснить. Что касается Макротипа:
Если ни Палец ни Рука Вас не интересуют, то можно предположить, что найти людей, у которых отсутсвует мизинец на левой руке, Вы сможете только фул сканом по Человеку:)

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

ViPRosмы не придем к взаимопониманию, хотя я тебя отлично понимаю

Оригинальная мысль, если учесть, что я тоже неплохо понимаю:)
ViPRosтут мешает то , что я говорю о реализации, а ты о модельных аспектах
есть у меня связь, она реализована как я говорил
но по твоему ее нет, так как она реализована не как отдельный модельный элемент
но свою роль свзи и у тя и у меня одинакова, а семантику у меня больше за счет дополнительной типизации этой связи

Ну, это не совсем честно:) Очевидно же, что связи нет, ни на уровне модели, ни на уровне реализации, а семантики, конечно, же меньше. Это хорошо видно в предыдущих сообщениях (непонимание, что семантика и мощность поддерживаются в обоих направлениях в классической объектной модели данных; когда говорится "как же быть, если TS(T1,T2)")
И потом, классическая объектная модель данных давно реализована. Какой же смысл говорить, что в одном случае - только модель данных, а в другом - только реализация "неизвестной модели данных":)
ViPRosпальцы и ноги мне без человека без нужды

Ага, а дома и квартиры без улицы тоже без нужды??? А говорили ведь, что "конструкции" Палец-Рука-Человек и Квартира-Дом-Улица - это одно и то же.
ViPRosна модельнем уровне можно сказать, что классификатор тип свойства
а на уровне реализации тип про классификатор ничего не знате (как минимум об агрегирующем его классификаторе)

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

Вот это правильная универсальная реализация чего-угодно:)

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

U-geneМэппинг, по моему сугубому мнению, есть следствие изначально бредовой идеи, что объекты программы нужно хранить в БД.

Здесь есть опасность увести "разговор" в сторону от его сути. Вы подменяете одну вынужденную (из-за использования РСУБД) идею - некой семантической модели, надстраиваемой над реляционной моделью - другой: хранение "объектов программы" в базе данных. Поскольку неизвестно, что Вы понимаете под "объектами программы", относить эту идею к классу бредовых, я думаю, преждевременно.
U-geneПри правильном проектировании моделируемая предметная область будет описываться набором объектов, так или иначе отличных от объектов интерфейса. Можно сделать следующий шаг и засунуть эти объекты в БД - пусть они там существуют независимо от программы. А из БД нам нужны данные о их текущем состоянии, ничего более.

Разумеется. И реляционная и классическая объектная модели данных примерно это и предполагают. Но, при использовании реляционной модели, которая не обеспечивает основные свойства БД - идентификацию, навигацию и семантику, возникает необходимость в разнообразных идеях. Это идеи вынужденные, и их вовсе не обязательно называть бредовыми:)
U-geneЯ уже писал лет пять назад, что проблема неправильно сформулирована и копать нужно гораздо глубже. Есть два принципа оргнизации памяти - адресный и ассоциативный. Компьютеры с адресуемой памятью активно развиваются в течении 60 лет, с ними все понятно. В контексте проблемы я замечу, что когда мы говорим о ОО-языках - по дефолту идет разговор о ОО-трансляторах для компьютеров с адресуемой памятью.

А я думаю, что проблема предельно ясна. Копать нужно только для того, чтобы закопать эту предельную ясность:)
U-geneАссоциативная же память обычно проходит фразой на первой лекции курса "ЭВМ и программирования" (это в лучшем случае, в принципе про нее вообще могут забыть). Однако, если немного подумать, то РМД описывает имеенно ассоциативную память. Имеются значения ассоциированные с переменными отношений (по простому "имена таблиц") и внутри каждой такой переменной мы можем организовать ассоциативный же доступ к кортежам. РМД - модель ассоциативной памяти, ее общий случай. Современные РСУБД - какие-никакие реализации машин с ассоциативной памятью .

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

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

Не показано. Потому что, как только пошли вопросы по существу, показания были тут же свернуты:) Вот и мы здесь со связями пытались разобраться в неизвестной модели, предлагаемой ViPRos.
U-geneЧто касается ограничений современных РСУБД... Ну есть они... но писали же проги под 640 кб памяти... и кстати, какие проги :)
Не понял какая связь этих замечательных прог с ограничениями современных РСУБД. Мне кажется это сказано, чтобы отвлечь внимание от главного - от фундаментальных ограничений реляционной теории, а вовсе не "современных РСУБД".

ViPRosвоще то, у меня нет маппинга в обычном понимании(т.е., внутренние объекты домена трансформируются в объекты БД)

Это, как раз, не вполне обычная интерпретация объектно-реляционного мэппинга:)
ViPRosтут все немного по другому
в промежуточном слое между прогой и БД описывается предметная область, это описание хранится в БД.

Тут все, как раз, "стандартно". Это надстройка в виде неизвестной модели.
ViPRosПо этому описанию генерируются объекты БД

А здесь используется сама "реляционная модель".
ViPRosПрограмма использует это описание для доступа к БД с учетом семантики в описании предметной области

Конечно, ведь в РМД нет семантики, а в надстроенной неизвестной модели - есть (правда, неполноценная - без связей:))
ViPRosи соглашений по генерации объектов БД
вроде почти точно сказал
Вроде:)