Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9 10 .. 14   вперед  Ctrl
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Уважаемый vadiminfo
Я больше Вам отвечать не буду. Вы кажетесь мне большим мастером раздувать флейм, не потрудившись даже ознакомится с предложенной работой. Если Вы не пытаетесь понять как это работает, нафига Вы это обсуждаете?

Я уверен в том что НРМ является достаточно читабельным и понятным документом(конечно, если поднапрячься). Я делал его около двух лет и это уже третья крупная редакция(не говоря о постоянных мелких правках). Все это рецензировалось известным спецом в области БД (ИМХО ведущим в России) и, судя по его отзыву, он считает это полезным подходом и не может припомнить аналоги. Я и сам абсолютно уверен в простоте(по сравнению с тем же SQL3) и работоспособности предлагаемого подхода и, поэтому, меня просто убивают фразы типа...
vadiminfo
...хорошее дело, как манипулировать не зная имя таблы?....Ведь у Вас ее по любому нет?
Думаю, Вы слишком расточительны
Это все описано - R-переменными и их именование являются буквально основными вопросами НРМ.

Уважаемый vadininfo
Если Вы не пытаетесь это понять, если Вы не удосужились это прочитать, то зачем я буду засорять это топик бисером для Вас? Зачем мне пересказывать то, что я уже подробно описал? Вы делаете многогозначительные(как Вам кажется) но на самом деле абсолютно неверные и идиотские выводы только из поверхностного просмотра моих топиков, и на их основании отпускаете замечания, которые выглядят для меня абсолютно дебильными (типа "лощадью ходи"). Пожалуста, перестаньте мусорить в этом топике. Я таки надеюсь прочитать здесь что-либо умное :).
19 июл 05, 21:15    [1718104]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Андрей Леонидович
Guest
Ну Вы уж так сильно-то не кипятитесь, U-gene. Я, например, стараюсь, прочитал текст два раза - действительно не легко понять суть, чтобы уловить новизну. Вот сейчас буду читать в третий раз... То, что связи на объектном уровне представляются с помощью ключей (как в РМД) - это настораживает (в классической объектной модели связи между сущностями поддерживаются с помощью связей между идентификаторами, и там совсем другой смысл "ссылочной целостности")... Попытаюсь разобраться на "сквозном примере", хотя в целостном виде "сквозного примера", по моему, нет...
19 июл 05, 23:11    [1718280]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
U-gene

Я больше Вам отвечать не буду.

Да я и не предполагаю ответ от конкретного лица, када пишу. Это же форум, а не личная переписка.
Мож кто другой ответит, на интересующий вопрос.
Вопрос Дейта о том с чем в РМД соотносится объект мне представляется достаточно интересным. Тока и всего.

U-gene

Если Вы не пытаетесь понять как это работает, нафига Вы это обсуждаете?

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

U-gene

Это все описано

Это был ответ на текст Ваш текст
Нафига нам это множество еще раз явно организовать?

U-gene

деле абсолютно неверные и идиотские выводы
...
Я таки надеюсь прочитать здесь что-либо умное :).

Неужели Вы верите, что Ваши выводы непременно заставляют тока восхищаться правильностью, и отсутствием в них даже намека на идиотизм? Кто бы мог подумать? Впрочем, Вам виднее.
19 июл 05, 23:28    [1718296]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 vadiminfo
автор
...я само это и не обсуждаю, а тока некоторые тезисы, упомянутые в топике, представляющие для меня интерес...


Эти некоторые тезисы(правильные они или неправильные и идиотские) имеют смысл только в контексте предложенной статьи. Обсуждение их без ее прочтения ни имеет никакого смысла. Что я до Вас попытался в очередной раз донести.
20 июл 05, 09:48    [1718858]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
U-gene

имеют смысл только в контексте предложенной статьи.

Кто знает. Они могут оказать важней самой предложенной статьи. Ведь Дейт поднял вопрос. И эти подходы реально использутся в ОРСУБД. Статья, к примеру, может кануть в лету, а этот вопрос остаться.
Кроме того, он может перечеркнуть, либо нет значение данной статьи. Так как она так или иначе пытается соотносить объекты со структурами РМД.
20 июл 05, 11:41    [1719512]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 Андрей Леонидович

Андрей Леонидович
То, что связи на объектном уровне представляются с помощью ключей (как в РМД) - это настораживает


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

Однако заметьте, что НРМ позволяет определять и использовать самые натуральные ссылки. Ссылки - это тоже механизм. Но ИМХО они гораздо ближе вашим любимым:) "связям". К тому же они позволяют организовывать групповой доступ к данным как по ссылке, так и навстречу ей.

2 vadiminfo
Тьфу на Вас :). Когда же Вы перестанете мусорить здесь прописными истинами? Я же Вас об этом просил четыре раза! Это же такое занудство..
20 июл 05, 13:04    [1720008]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
U-gene

Когда же Вы перестанете мусорить здесь прописными истинами?

Хорошо. Вот Вам последняя прописная истина - переименуйте НРМ в дореляционную ОМД, выкиньте на радость коллеге ЧАЛу ключи - все равно они уже не помогут исправить положение дел.
20 июл 05, 14:56    [1720794]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 vadiminfo
Посколку статью Вы не читали, я даже не буду спрашивать, как хорошо Вас понимаете то, что говорите.
20 июл 05, 15:36    [1721118]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
U-gene
2 ModelR

Вы напрасно пытаетесь сравнить R-переменные с таблицыми SQL3. Если уж вам так приспичило сравнивать ,
Приспичило. Сравнение - метод познания, а также описания изобретений, а не отрицание.
U-gene
то это не таблица а, скорее, вид причем то, как этот вид вычисляется, определяется реализацией компонентов о-типа.
Согласен, вычисляемость присуща в SQL3 только полям VIEW, а не базовых таблиц. Методы пользовательских типов также не являются прямой аналогией.
U-gene
Например, если в процессе наследования о-типа реализация компонента была изменена, то значение R-переменной будет вычислятся по новому. Однако весь ранее определнный функционал, который так или иначе манипулировал с этой R-переменной, изменений не потребует(что подразумевает позднее связывание).
Правила наследования очень важны. Например, базовый тип определяет компоненту как хранимую, а порожденный - как вычисляемую, что тогда? А если обратно?
U-gene
ИМХО это средствами SQL3 никак не сделать. Посмотрите еще раз пример в первой части от начала до конца. Там есть все - от описания типов, до наследования с переопрелделением компонентов. Побробуйте сделайте то же на SQL3 - это было бы очень интересно, но мне кажется у Вас это не получится (это будет как преобразование С++ программы на язык С).).
Ну, я верю в программистов, особенно если за пиво...:)
U-gene


Насчет CREATE CLASS? Есть какая то устоявшаяся терминология, а поскольку пользователь, объявив и описав объектный тип, сразу же может манипулирвать его R-переменными, то для него это выглядит в точности как класс. Поэтому я оставил CREATE CLASS.
С термином понятно. Замечу только, что разделение определения типа и декларации переменных просто позволяет один тип использовать многократно. И в SQL и в НРМ это решено не использовать для CREATE TABLE / CREATE CLASS (хотя в SQL можно извернуться - CREATE TABLE AS SELECT...)
U-gene


автор
Далее, "запихнуть в одну таблицу" - нет, ORACLE nested table физически размещается в отдельной таблице
Физически то да, но нафига это логически впихивать в одну таблицу? Нафига это таблица вообще нужна? Можно без нее - ИМХО даже нужно.
На логическом уровне мне в общем то все равно, впихивает или нет. Важно, что есть некоторый агрегат с полезными свойствами.

Вы очень облегчили бы понимание вашего труда если бы провели предлагаемое сравнение, а также может сравнение с какой-то ОБД.

Насчет простоты DML - не уверен что все так просто. Например, какова семантика присвоения вычисляемым полям, или это должно отрезаться на уровне синтаксиса?
20 июл 05, 15:57    [1721294]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 ModelR
Ну раз приспичило, значит интересно :)
Я буду цитировать исходный текст - ИМХО там все ответы есть.

ModelR
Например, какова семантика присвоения вычисляемым полям, или это должно отрезаться на уровне синтаксиса?

Я не знаю, насколько я этим отвечу на этот Ваш воррос, но вот следующая цитата ..точнее связка цитат (только учтите, что это все же манифест, который некоторые вещи просто требует:) )
НРМ(стр5,9)
...Мы рассматриваем и атрибуты, и методы объектных типов как компоненты, содержащие или возвращающие значения - т.е. имеющие значимый тип. Спецификация метода может рассматриваться как спецификация компонента, имя которого совпадает с именем метода, а тип - с типом значения, возвращаемого методом (спецификация метода включает также описание параметров значимых типов).

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

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



Еще вопрос.
2 ModelR
U-gene
Например, если в процессе наследования о-типа реализация компонента была изменена, то значение R-переменной будет вычислятся по новому. Однако весь ранее определнный функционал, который так или иначе манипулировал с этой R-переменной, изменений не потребует(что подразумевает позднее связывание).
Правила наследования очень важны. Например, базовый тип определяет компоненту как хранимую, а порожденный - как вычисляемую, что тогда? А если обратно?


Ответ.
НРМ(стр14-15)
....Как указывалось ранее, в спецификации объектного типа не определяется, являются ли значения его компонентов хранимыми или вычисляемыми. Компонент, реализованный в родительском типе как хранимый, может быть переопределен в классе-наследнике как вычисляемый (и наоборот). Соответственно, когда речь идет о полиморфном наследуемом объектном типе, любая из R-переменных его компонентов может содержать одновременно как хранимые, так и вычисляемые разными способами значения.

Говоря строго, значение R-переменной компонента, конечно же, вычисляется и представляет собой объединение UNION нескольких значений, одни из которых могут быть реализованы как хранимые, а другие являются вычисляемыми (прим для modelR - это и есть тот самый вид, о котором я говорю). Для R-переменных типов картина еще более сложна. Поскольку значение R-переменной типа определяется как декартово произведения значений компонентов, возможен случай, когда в некоторых кортежах только несколько атрибутов являются хранимыми. А из-за того, что в процессе наследования типа реализация компонентов, содержащих эти атрибуты, может измениться, в других кортежах указанные атрибуты могут вычисляться (т.е. R-переменная типа, говоря образно, хранится мозаично). Но в любом случае вычисления значений любых R-переменных должны выполняется системой неявно для пользователя (на основании информации о наследовании типов и реализации компонентов этих типов). Для использования R-переменных необходима только спецификация типа.

Можно провести следующую аналогию. Полиморфные OO-языки программирования делают ненужными использование громоздких и чувствительных к изменениям программы селекторных конструкций, необходимых для выполнения близких по смыслу действий для структур, хранящих близкие по смыслу данные, например
if s.f=1 then function1(s)
elseif s.f =2 then function2(s), заменяя их вызовом полиморфного метода s.function()..

Точно так же полиморфные компоненты делают ненужным явное использование оператора UNION для получения значения отношения, объединяющего близкие по смыслу данные в том случае, когда эти данные хранятся и/или вычисляются разными способами. При этом подразумевается, что объектный тип является наследуемым и что полиморфный компонент может менять свою реализацию. Таким образом, если имеется объектный тип t, в котором определён компонент a, и соответствующие этому типу R-переменные используются в запросах и методах, то создание типа t*, наследующего тип t и переопределяющего реализацию компонента a, не ведет к необходимости менять эти запросы и методы. ....
....Далее идет часть общего примера, демонстрирующего эту мысль
20 июл 05, 16:28    [1721456]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 ModelR
ModelR
Замечу только, что разделение определения типа и декларации переменных просто позволяет один тип использовать многократно.

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

автор
Вы очень облегчили бы понимание вашего труда если бы провели предлагаемое сравнение, а также может сравнение с какой-то ОБД.


С ОСУБД сравнивать не хочу. Все, что я видел - это не столько СУБД, сколько системы, позволяющие хранить объекты программы постоянно - то есть это даже и не СУБД. Настоящих ОСУБД я как то даже и не припомню. То, что предлагает НРМ ближе скорей SQL3....
НРМ (стр34)
Предлагаемый НРМ подход может служить основой для создания системы, которая позволяет создать адекватную, активную и долговременно существующую модель предметной области, управляемую пользователем и предоставляющую пользователю данные о своем состоянии.
20 июл 05, 16:58    [1721641]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
автор
Я не знаю, насколько я этим отвечу на этот Ваш воррос, но вот следующая цитата ..точнее связка цитат (только учтите, что это все же манифест, который некоторые вещи просто требует:) )

В этом все дело. Изложенные требования весьма сильные, одна возможность присвоения значений вычисляемым переменным компонент чего стоит. Кстати причем тут триггеры? Вопрос не как программировать, а что это присвоение должно значить. Например, в вашем примере остатки товара на складе определены как вычисляемые, теперь я присваиваю им некоторое значение, например пустое.
Что это значит? Отныне они перестают вычисляться?

Из приведенной цитаты про наследование (мозаичное представление одного атрибута), а также из рассуждений о единстве спецификации объектного типа и объявления переменной соответствующего типа возникает подозрение, что наследование включает в себя и копирование значения родительской переменной в наследующую переменную. Так ли это?
20 июл 05, 17:18    [1721754]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
U-gene
2 ModelR
[quot ModelR]Замечу только, что разделение определения типа и декларации переменных просто позволяет один тип использовать многократно.

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

Если мне нужно две переменные идентичного типа, удобнее написать
CREATE CLASS Warehouse ... ;
W1 Warehouse;
W2 Warehouse;
ALTER CLASS Warehouse ... ;
больше ничего.
20 июл 05, 17:26    [1721802]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 ModelR
Давайте разбираться.

ModelR
Например, в вашем примере остатки товара на складе определены как вычисляемые, теперь я присваиваю им некоторое значение, например пустое.
Что это значит? Отныне они перестают вычисляться?


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

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

Замечу, НРМ оговаривается, что...
НРМ(стр8)
Мы не рассматриваем иные характерные для языков программирования возможности спецификации объектных типов (например, модификаторы видимости private и public, модификаторы обновляемости readonly, и т.д.), однако допускаем, что такие возможности могут существовать и быть полезными.

Другими словами, если нужно явно запретить такое присваивание, то может быть стоит специфицировать такой компонент как readonly?
20 июл 05, 18:02    [1721937]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 ModelR

ModelR
Если мне нужно две переменные идентичного типа, удобнее написать
CREATE CLASS Warehouse ... ;
W1 Warehouse;
W2 Warehouse;
ALTER CLASS Warehouse ... ;

больше ничего.


Тогда я не понял.
W1 - это отдельно взятая переменная? то есть это объект? Так у меня можно создать сколько угодно объектов одного класса. Или я где то вопрос не догоняю?
20 июл 05, 18:07    [1721951]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
ModelR
Member

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

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

автор
W1 - это отдельно взятая переменная? то есть это объект? Так у меня можно создать сколько угодно объектов одного класса. Или я где то вопрос не догоняю?
Именно - в смысле сколько угодно.

А что про наследование/копирование?
20 июл 05, 18:29    [1722000]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
ModelR
Из приведенной цитаты про наследование (мозаичное представление одного атрибута), а также из рассуждений о единстве спецификации объектного типа и объявления переменной соответствующего типа возникает подозрение, что наследование включает в себя и копирование значения родительской переменной в наследующую переменную. Так ли это?

Давайте таки отделять мух от котлет. Есть объекты (то, что создается командой new имя_о_типа) и есть R-переменные. Я пока не понял, о каких перменных речь.

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

Попробуйте читать внимательней. Мозаичное представление - это про R-переменную класса, а не компонента.

И я хочу донести, что все эти рассуждения про R-переменные есть не более чем обоснование. Пользователь может этого не знать, точно так же как пользователь SQL систем может не знать РМД. Смотрите пример. Он представляет собой достаточно полную модель оговоренной предметной области, которой можно пользоваться - создавать объекты, делать запросы и т.д. Рассматривая пример попробуйте абстрагироваться от обоснования: тогда Вы увидите, что это достаточно просто использовать - описали классы, задали их реализацию и после этого сразу же можно создавать объекты и делать запросы.
20 июл 05, 18:56    [1722072]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 ModelR

Про наследование и R-переменные по другому. Объекты класса наследника, естественно, принадлежат и базовому классу. Спецификация класса наследника включает спецификацию базового класса. Поэтому класс наследнимк наследуют R-переменные базового класса. Никакие значение никуда не копируются(точнее нет даже обснований для того, что бы подозревать это).

ModelR
Именно - в смысле сколько угодно.
Ну так сколько угодно и создавайте.

ModelR
Предлагаю не вводить в модель данных такое понятие как триггер
Хорошо. Вместо фразы
U-gene
Если конечно иное не оговорено в реализации этого компонета специально (например, тем же триггером).
Следует читать: "Если конечно иное не оговорено в реализации этого компонета специально.".
20 июл 05, 19:07    [1722104]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Андрей Леонидович
Guest
Может быть, в научной статье не стоит "опускаться" до "сквозного примера", который начинался бы с КОНЦЕПТУАЛЬНОЙ схемы. Но, надеюсь, в рамках обсуждения мы могли бы это сделать...
Раз уж Вам лень было рисовать, мне - тем более. Поэтому пишу...

Список объектов (в терминах ОМД - это объекты, в ER-терминах - сущности, в OO-терминах - классы, в НРМ-терминах - точнее скажете Вы)
--------------------------------------------------------------

Товар
Торговая марка
Склад
Документ: накладная на перемещение
Документ: товарная накладная
Документ: приходный ордер
Операция перемещения
Операция отгрузки
Операция разгрузки

Список связей
---------------

Товар <-*- Хранится на/Хранит ---> Склад

Товар <--- Имеет/Принадлежит --- Торговая марка

Документ: накладная на перемещение --- Состоит из/Входит в ---> Операция перемещения

Документ: накладная на перемещение <--- Имеет в качестве источника/Источник для --- Склад

Документ: накладная на перемещение <--- Имеет в качестве получателя/Получатель для --- Склад

Операция перемещения <--- Для/Имеет --- Товар

Документ: товарная накладная --- Состоит из/Входит в ---> Операция отгрузки

Документ: товарная накладная <--- Для отгрузки со/На котором оформлена --- Склад

Операция отгрузки <--- Для/Имеет --- Товар

Документ: приходный ордер --- Состоит из/Входит в ---> Операция разгрузки

Документ: приходный ордер <--- Для разгрузки на/На котором оформлена --- Склад

Операция разгрузки <--- Для/Имеет --- Товар

------------------------------------------------

здесь:

<--- ---> многие-ко-многим
--------> один-ко-многим
<-*- ---> наличие характеристик связи (у связи товара и склада есть характеристика связи - количество товара на складе)

------------------------------------------------

Пока 2 замечания:

1) Эта концептуальная схема в ОСУБД представляется на ЛОГИЧЕСКОМ уровне точно в таком же виде, и, следовательно, точно в таком же виде поддерживается объектным навигатором (который должен быть в любой ОБЪЕКТНОЙ системе).

2) Поэтому, во-первых, связь многие-ко-многим поддерживается и отражается в навигаторе явно, и, во-вторых, мы можем просто (в навигаторе) получить, например, перемещения (или отгрузки, или разгрузки) ДАННОГО товара.
В НРМ (точнее в Вашем "варианте" примера) ни того, ни другого нет ни в "объектном", ни в "реляционном" "слоях".

Видимо с многие-ко-многим проблема не преодолима ?
А вот по второму вопросу Вы можете сказать, что концептуальная схема может быть представлена и так (не встраивая операции "внутрь" документа).
Но ! Зачем их вообще представлять не так (встраивать) ?

То есть я Вас "критикую" по двум разным направлениям:

1) с одной стороны, поддерживая "объектный подход", Вы игнорируете возможность явного представления связей многие-ко-многим;

2) а с другой стороны, Вы допускаете (непонятно зачем) денормализацию (встраивание объектов), противоречащую "реляционному духу" (но, впрочем, не Манифесту Дейта), и осложняющую (мягко говоря) прямой доступ к встроенным объектам (в данном случае - к операциям).

Пока у меня складывается впечатление, что НРМ остается "реляционным" даже в объектном "слое". В этой связи было бы интересно услышать, в концентрированном виде, отличительные черты НРМ в сравнении с Манифестом Дейта, например, ...
20 июл 05, 22:38    [1722321]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
U-gene
2 ModelR

Про наследование и R-переменные по другому. Объекты класса наследника, естественно, принадлежат и базовому классу. Спецификация класса наследника включает спецификацию базового класса. Поэтому класс наследнимк наследуют R-переменные базового класса. Никакие значение никуда не копируются(точнее нет даже обснований для того, что бы подозревать это).

ModelR
Именно - в смысле сколько угодно.
Ну так сколько угодно и создавайте.

ok, про объекты понятно. Я пытался спросить про коллекции объектов. Если мне нужно две переменные-коллекции идентичного типа, удобнее написать CREATE CLASS Warehouse ... ;
W1 Collection of Warehouse ;
W2 Collection of Warehouse;
ALTER CLASS Warehouse ... ;

Вообще по-моему трактовка множеств объектов (коллекций) - одно из принципиальных отличий РМД и ООБД. Что по этому поводу говорит НРМ?
21 июл 05, 10:51    [1723020]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 Андрей Леонидович

Какой такой навигатор? Язык и только язык. И никаких рисованных схем. То есть я не против такого рода интерфейса в реальных системах, но в манифесте языка вполне достаточно.

Андрей Леонидович
1) Эта концептуальная схема в ОСУБД представляется на ЛОГИЧЕСКОМ уровне точно в таком же виде, и, следовательно, точно в таком же виде поддерживается объектным навигатором (который должен быть в любой ОБЪЕКТНОЙ системе).


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

Понимете, когда я говорю, что было отгружено 20 штук артикула "а" и было отгружено 20 штук артикула "а" (это сознательное повторение), как Вы определите - это я два раза про один и тот же факт я сказал или про разные? Никак! Сами по себе эти значения (факты) абсолютно одинаковы! Отличить их можно только в контексте объектов, которые этими фактами описываются. Уникальность этих значений(фактов) определяется не в них самим, но только в содеражащих их объектах. Поэтому не надо изо всего делать объекты. Есть просто значения(факты), которые объектами не являются и НМР отражает это.

И какой-такой навигатор?

Андрей Леонидович
2) а с другой стороны, Вы допускаете (непонятно зачем) денормализацию (встраивание объектов), противоречащую "реляционному духу" (но, впрочем, не Манифесту Дейта), и осложняющую (мягко говоря) прямой доступ к встроенным объектам (в данном случае - к операциям).


Что значит - непонятно зачем? Вы же сами забодали тут всех ребят :)утверждением, что ключи - это дескать плохо, и я подумал - раз Андрею Леонидовичу это не нравится, надо изобазить что-то подобное ссылкам в ОО-языках (может так понравиться?). :)

А насчет ненормализованности это самый интересный вопрос. Да, объекты ненормализованы. Однако...
НРМ(стр13)
Предполагается, что данные, хранящиеся в R-переменных, всегда актуальны – любое изменение состояний объектов приводит к изменению значений соответствующих R-переменных. Другими словами, данные, представленные в виде значений компонентов объектов, и данные, представленные в виде значений R-переменных - это одни и те же данные (в дальнейшем мы будем говорить о двояком представлении данных).
Любому объектному типу с ненормализованнйо структурой соответсвует несколько R-переменных, структура которых однозначно нормализована. При этом система организована таким образом, что пользователю не приходится даже задумываться, с каким именно представлением он работает. Прочитайте еще раз внимательн раздел "R-переменные" - там все это описано

Я еще раз говорю - В НРМ нормализованные переменные отношений явно не описыаются. Однако это не значит, что их нет вообще. Их существование, их имена, имена их атрибутов - все это задается описанием значимых и объектных типов (структура последних ненормализована).

Например для о-типа "документ" будет существовать аж три R-переменные
1)R-переменная собственного компонента (что это такое - см. НМР) содержашая данные из заголовка документа
2)R-переменная компопнента описывающего отгрузки поэлементно
3)общая R-переменная типа
Все эти пременные являются нормализованными переменными отношений: первые две навскидку в >=3НФ, третья в 1НФ.
(Замечу, что фактически тоже самое получилось бы и в традиционных SQL системах две таблицы для хранения заголовков и строк, + постоянное использования JOINа, связывающего их вместе(R-перменаая типа и есть этот JOIN). По сути в НРМ то же самое, просто описано и представлено абсолютно по-другому)

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

Абсолютно никакой проблемы - делаете(я использую термины SQL) SELECT...WHERE.... . И что это за слои? Все, с чем работает пользователь, существует....мммм....в одном и том же месте. Никаких слоев. И потом...:)... Какой-такой навигатор?

Еще раз указыаю на ошибочность фразы
Андрей Леонидович
Вы допускаете (непонятно зачем) денормализацию (встраивание объектов)


Я не допускаю встаиания объектов. Где Вы это нашли?На всякий случай связка цитат.
НРМ стр3,10

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


Далее вопрос
Андрей Леонидович
Видимо с многие-ко-многим проблема не преодолима ?


Как не преодолима? Например. Определяем кортежный значимый тип, содержащий ссылку на объектный тип А. Создаем объектный тип В, содержащй компнент ref_comp, представляющий множество кортежей указанного значимого типа. При этом в ключ этого компонента ссылочное поле не входит.
CREATE CLASS A {}

DECRIBE TUPLE t {a A; ...}

CREATE CLASS B
{ ...;
   ref_comp OF t...;
}

Создаем объектный тип B, содержащй компнент ref_c, представляющий множество кортежей указанного значимого типа. Теперь каждый объект класса В может ссылаться на многие объекты класса А, и на каждый объект класса А могут ссылаться многие объекты класса В. Это разве не связь многие ко многим. При этом учтите - ссылки в НРМ допускают доступ к данным в обе стороны.

А если учесть, что
НРМ(стр10)
В системе могут существовать переменные, представляющие собой группу ссылок на объекты заданного типа (групповые ссылки). Значение, хранящееся в такой переменной можно рассматривать как значение отношения с одним единственным атрибутом OID, определенным на одном из ссылочных типов. Отметим, что такая переменная не требует явного определения ключа – подразумевается, что ключом однозначно является единственный атрибут. Одиночную ссылку (т.е. ссылку на один-единственный объект) можно рассматривать как частный случай групповой ссылки.


То такая связь может быть задане еще более просто.
CREATE CLASS A {}

CREATE CLASS B
{ ...;
  ref_comp SET OF A;
}
в данном случае компонент ref_comp прямо определяется как групповая ссылка.

Андрей Леонидович
Пока у меня складывается впечатление, что НРМ остается "реляционным" даже в объектном "слое".


Какие-такие слои? :)
Да он остается реляционным - я этого и добивался Однако описание данных - объектное, и я этого тоже добивался.
21 июл 05, 11:46    [1723286]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 ModelR
ModelR
Вообще по-моему трактовка множеств объектов (коллекций) - одно из принципиальных отличий РМД и ООБД. Что по этому поводу говорит НРМ?


Определив о-тип мы (благодаря его R-переменным) сразу же можем работать с множеством, содержащим все существующие в системе объекты этого типа.

Например

CREATE CLASS A{};

SELECT ... FROM A ...;

Опять же
НРМ(стр10)
В системе могут существовать переменные, представляющие собой группу ссылок на объекты заданного типа (групповые ссылки).


Таким образом мы можем явно задать некое подмножество существующих в системе объектов. Далее, в разделе "R-переменные и ссылки." показано, что...
НРМ(стр19)
...Таким образом, имя ссылки, подобно имени объектного типа, является многозначным именем, которое должно интерпретироваться в зависимости от операции, в которой это имя используется (конечно, в групповых операциях оно интерпретируется как имя R-переменной). По большому счету единственное отличие между R-переменной t и R-переменной reft заключается в том, что первая определена глобально, а вторая – только там, где определена соответствующая ссылочная переменная (т.е. в типе или в методе типа).

То есть мы может работать с подмножеством, определяемым групповой ссылкой, точно так же, как и с множеством, определяемым о-типом

Единственный вопрос может быть в том, что такого рода подмножества не определены глобально, что не позволяет обращаться к ним используя непроцедурные команды управления системой. Да, наверное это было бы полезно. Спасибо, буду думать.
21 июл 05, 12:06    [1723395]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Многие-ко-многим демонстрирует GoodsMotion, проекция его на (FromWarehouse,ToWarehouse) задает все пары складов поставщик-получатель чего-либо. Не вижу проблем.
21 июл 05, 12:18    [1723460]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Привет!

А как в НРМ обстоят дела с
- множественным наследованием классов
- множественным наследованием интерфейсов
- полиморфизмом

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

Дмитрий.
21 июл 05, 16:12    [1724824]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
2 shuklin
Guest
2 shuklin

Интерфейсов нет как понятия (интерфейсы - изобретение, которое я впервые увидел в Java - появляется только потому, что язык не допускает множественное наследование классов. Это мое ИМХО которое даже обсуждения не стоит. Онпять же ИМХО можно обойтись одними классами).

Классы мноджественное наследованиеидопускают. За исключением одного места...
НРМ(стр20)
В команде, создающей новый объектный тип (и соответствующий ссылочный тип), необходимо указывать имя этого типа, перечислить базовые типы (прим - во множественном числе), спецификацию компонентов и определить ключи.
...НРМ это специальным образом не оговоаривает. Однако надо понимать, что для двойственного представления данных (объекты <=> R-перменные) число предков у класса в общем-то не имеет значения. В предыдущих редакциях это, кстати, рассматривалось подробно.

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

В каких это случаях?
И потом, я же иду не от алгоритмов а от ...ммм... некой идей, а там, наоборот, пролетает как раз случай объекта без OID.
21 июл 05, 16:38    [1724989]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9 10 .. 14   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить