Сбили меня тут своим классами :)

В НРМ есть, конечно же, объектные типы, и они допускают множественное наследовангие. Вс екомпоененты этих типов можно переопрелелять при наследовании. То есть и компоненты и, следовательно, сами эти типы являются полиморфными.

Хороший вопрос.

Насчет спецификаций - это ИМХО связано с тем же отображением (объекты <=> R-переменные). Если у о-типа А есть много наследников, и от них от всех мы потом множественно наследуем о-тип B, то в спецификации этого типа все равно будет только по одному компопненту из спецификации типа А.

Можно объяснит так. Спецификации компонентов можно рассматривать как элементы некого множества. Спецификация типа - это множество. Множественное наследование (применительно к спецификации о-типа) - это, фактически, объединение нескольких множеств. Естественно, объединение нескольких, содержащих одинаковые элементы множеств в точности повторяет любое из исходных множеств - элементы (т.е. спецификации компонентов) дублироваться не могут. Я не уверен, но насколько я помню , это называется виртуальным множественным наследованием. Или я не тот термин употребляю?

Конечно же будет конфликт реализаций. Но ИМХО данные момент не является принципиальным. Этот конфликт в любом случае можно как-то можно разрешить. Аутоматично (например, брать реализацию из первого типа в списке базовых типов ... ГЫ-ГЫ) или руками (например, в случае конфликто явно указывать, какая реализация нужна - вплоть до требования явного преопределения). Т.е. это дело не НРМ, а конкретной системы, реализующей НМР. В НРМ это могло бы прозвучать как "В системе должен существовать механизм разрешения возможных в случае множественного наследования конфликтов реализаций компонентов"

2 ModelR Второй раз счасибо. :)

Уважаемый Андрей Леонидович.

Во первых, я не понимаю Ваших терминов. У Вас в голове какая то своя, сложная система (нам, гагарам, сие недоступно). Я же во вступлении не пишу, что целью НРМ является реализация сложной системы, существующей в голве у Андрея Леонидовича. Цель гораздо более простая - совмещение манипуляционных возможностей РСУБД с выразительными возможностями, присущими ОО-языкам. Всего то.

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

И наверное в отношений связей Вы правы. ;) Вот взять вес в килограммах! Вроде бы казалось, чистой воды "атрибут" "объекта". Ан нет - приглядишся, и оказывается, что это очень абстрактное представление "связи" между этим объектом, эталонной гирей в Париже и земным шаром. А там глядь! ...кругом то одни связи!! а от объектов вообще ничего не осталось!!! Что делать, что делать??? Караул.....

Еще раз прошу - не надо раздувать здесь флейм. Если приспичит (сорри, но понравилось мне это слово:) ) зовите меня в топик называемый "Вопрос". Ведь все равно никто уже и не помнит, что это был за вопрос....

2 Андей Леонидович
Ах да! Я забыл - Вы же просили показать, " чтобы от товара можно было бы получить операции его отгрузки". Посколку в примере я использую внешний ключ, то эта выборка будет выглядеть до обидного просто Это вернет групповую ссылку на множество обектов, содержащих данные об отгружаемом товаре.

Кстати, если бы я использовал ссылку - то есть вместо поля ArtNo, явно содержащее строку-товарный артикул (внешний ключ), было бы поле ArtRef, ссылающееся на объект о-типа Goods - это выглядело бы так

Хотя... может Быть вам нужно отгужаемое количество?


Или Вам нужны даты, когда товар был отгужен?


В общем не стесняйтесь - спрашивайте, чтоВам из схемы в примере нужно достать. Только не надо срашивать как это или почему это так - находите объяснение в тексте сами.

Эта... Андрей Леонидович... тогда я вообще ничего не понял. Я описал отгузки и товары. В моей "концептуальной" схеме отгрузка характеризуется отгужаемыми в ней товарами, что успешно могу представить в схеме "логической" как с помощью ключа, так и с помощью ссылки. Далее Вы просите показать дословно " чтобы от товара можно было бы получить операции его отгрузки". Я показываю как это можно сделать. Оказывается - это не то! А что тогда? Вы подробно объясните!!!

Только давайте Вы будете использовать мою "концептуальную" и мою абсолютно соотвествующуу ей "логическую" схему. Или, по крайней мере, поставте себя на мето кладовщика или логиста, представте себе какие данные им нужны (это ИМХО не зависит от всяких схем) и попробуте сформулировать вопрос так, как задали бы его они. Ну а если ничто из предложенног Вам не подходит, то я опять таки посыпаю голову пеплом и умываю руки. "Концептуализировать" по Вашему я не буду.

Ув Андрей Леонидович!

Я в прошлый раз забыл спростиь - а что такое "оптимизатор"? Откуда Вы его взыли? Опять из головы? У меня нет оптимизатора. У меня есть операции рел алгебры. Откуда в Вашей голове ВДРУГ появился оптимизатор??? Его нет, аллё, расслабтесь!!!

Давайте не будем махать факториалами, выдавая это за элементы теории баз данных. Я, нагло ссылаясь на собственный текст, не пытаюсь выдать это за элементы теории, Если Вы пишите "элементы теории" дайте ссылку. Я таких "элементов теории" явно нигде не видел. Но даже не в этом дело. Я просто не нахожу глобальной разницы, между тем, что говорю я и тем что говорите Вы.

Андрей Леонидович. На протяжении 3 разворотов сего топика я пытался донести простую идею - для того, что бы работать с переменными отношений необязательно их явно определять. Некоторые не поняли и ушли. Надеюсь, что некоторый процент людей это понял. Теперь, специально для Вас :) я попытаюсь донести такую же простую мысль - для того, что бы работать с той информацией, которую Вы пытаетеся представить в виде связи. её так же не обязательно явно (как связь) описывать.

Итак, когда я говорю про ссылки, я имею в виде конечно ссылки, которые определны в спецификации типа. То есть это НРМ(стр4) ... декларативный перечень внешних свойств (атрибутов и методов), который можно рассматривать как интерфейс, по которому можно организовывать взаимодействия с объектом. Из того, что он декларативный, следует то, что он доступен для чтения всеми пользователями системы. Естественно мы можен определить все типы, на которые ссылается данный тип (это определно в спецификации этого типа), однако я так же хорошо представляю себе операцию, которая возвраoftn нам все компопнеты всех классов, содеражащие ссылки на данный тип. Эта операция не описана в НМР, но ей богу это будет всего лишь простая выборка по каталогу значимых типов. То есть информацию о том, что ссылки существуют(мета данные) можно получить в любом случае - и том случае ссылки из объекта наружу, и в случае ссылки снаружи на объект.

Далее автор...Операция раскрытия ссылки позволяет организовывать ассоциативный доступ к данным объектов любого типа, связанного с объектами данного типа по ссылке. При этом доступ к данным возможен как по ссылке, так и в противоположном направлении (конечно, на самом деле используемое при этом отношение, являющееся результатом операции EXPAND, не подразумевает каких-либо направлений, поскольку поля, содержащие OID объектов, ссылочные поля, содержащие OID связанных объектов, и поля данных в них абсолютно равнозначны ). Это я специально для Вас выделил. Понимаете ли в R-переменные - они так и построены. Схема R-переменной может содержать любое число равнозначных атрибутов-ссылок среди любого числа других атрибутов. Конечно , среди этого любого числа атрибутов-ссылок один (OID) будет обязательнным: в каждом кортеже эта ссылка на объект, данные о котором в этом кортеже представлены. Но эта "обязательность" - единственная черта, которая отличает его от всех остальных ссылок.

То есть если в о-типе специфицирован компопнет, содержащий ссылку ..., refOID, ... . то в соотвествующей R-переменной мы получаем пору ссылок авторOID, ... , refOID, ... , что в точности представляет вашу связь (все это в НМР прописано). Может быть оно по другому называется, может быть эти чвязи и не и не заданы явно , но в принципе это абсолютно тоже самое.

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

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

Или Вы думаете, что пользователь, проанализирует какой-нить там план исполнения этого простого запроса, и увидев, что использовался пресловутый "оптимизатор" (ГЫ-ГЫ), в сердцах выбростит результат вне зависимотсти от его правильнсоти? Думаю вряд ли. Он "же не индиот" (с)Лем

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

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

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

Андрей ЛеонидовичИнформацию Вы ДОСТАЛИ. РЕЗУЛЬТАТ ДОСТИГНУТ ! Но не от товара Вы получили операции его отгрузки, а от операций отгрузок. Как и "полагается" в реляционной системе... Нам гагарам этот Ваш дзэн - "результат ничто, путь все" - не ясен. "РЕЗУЛЬТАТ ДОСТИГНУТ!"(с) Андрей Леонидович

shuklin ...Однако практика показала, что распространение получают эффективные а не формальные реализации...

ИМХО не надо вот так прямо противопоставлять эффектифность и обоснование. То есть Системы баз данных третьего поколения: Манифест...Предложение 2.4: Показатели производительности не имеют почти ничего общего с моделями данных и не должны в них проявляться... Это не я придумал. Так написано в "Манифесте БД третьего поколения" - в манифесте, так или иначе реализуемым СУБД, которые называют себя объектно-реляционными. Тем же Oracle.

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

Например, SQL не реализует в чистом виде то, что написал Кодд. Однако основные то идеи в нем как то(хорошо или плохо) выражены. Но если бы не было статьи Кодда, то сегоднящнего SQL не было бы вообще.

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

Да не то что бы на будущее. У меня уже были некоторые мысли по этому поводу . Наверное, их стоит переписать используя термины НРМ и пример из него.

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