Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8 9 10 .. 14   вперед  Ctrl
 Re: НРМ  [new]
Андрей Леонидович
Guest
Вот я и стараюсь вас, гагар, информировать об элементах теории баз данных, о которых вы не знаете...
27 июл 05, 01:20    [1738212]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Андрей Леонидович
Guest
В моделях данных (как правило) НЕТ понятия индексов, ModelR. Поэтому я ничего не утверждаю про "схемы индексирования". Пока...
Я утверждаю только вполне очевидные вещи про связи вообще, и про связи многие-ко-многим, в частности...

Полезно напомнить Вам (в связи с Вашими вариантами примера) высказывание Дейта:

"... вся прежняя критика иерархического подхода ... относилась именно к иерархиям вложения... основным доводом такой критики было ОТСУТСТВИЕ СИММЕТРИИ. В частности, иерархии не совсем удобны для представления отношений типа "многие-ко многим". Например, для рассматриваемого ранее отношения поставщиков и деталей может возникнуть вопрос, содержатся ли объекты-поставщики в объектах-деталях или НАОБОРОТ. А может, верно и то и другое ?"

В ОМД никаких мучений и двухсмысленностей нет. Связь многие-ко-многим представляется явно как связь многие-ко-многим, без всяких "вложений" одних объектов в другие...
В НРМ мне было не понятно как представляется связь многие-ко-многим. Теперь понятно - как и в РМД...
27 июл 05, 01:33    [1738220]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Ну да, потому как ссылка в общепринятом понимании позволяет организовать доступ к данным только в одном напрвлении. Например в ОDMG для того, что бы оргизовать двунаправленную связь требуется определить ссылку и обратную ссылку (backref). При этом ИМХО не очень ясно, что делать когда в связи учавтсвует более двух объектов.

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

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

Вернемся к нашему простому примеру. Существует класса А и класс В. Класс А содержит ссылку(ки) на класс В. Случай первый...
CREATE CLASS A {}

CREATE CLASS B
{ ...;
  ref_comp SET OF A;
}
...я уже объснил. Каждый объект класса В может ссылаться на многие объекты класса А, и на каждый объект класса А могут ссылаться многие объекты класса В. Связь многие ко многим.

Случай второй...
CREATE CLASS A {}

CREATE CLASS B
{ ...;
  ref_comp A;
}
..отличается от первого толко тем, что ссылка одиночная (в первом случае она групповая). Каждый объект класса В может ссылаться только на один объект класса А, однако на каждый объект класса А могут ссылаться многие объекты класса В. Связь один ко многим.

Случай третий....
CREATE CLASS A {}

CREATE CLASS B
{ ...;
  ref_comp SET OF A
  CONSTRAIN GLOBAL KEY;
}
]..отличается от первого тем, что групповая ссылка описана как глобальный ключ. Каждый объект класса В может ссылаться на множество объектов класса А, однако на каждый объект класса А может ссылаться только один объект класса В. Связь многие к одному.

Наконец, четвертый случай...
CREATE CLASS A {}

CREATE CLASS B
{ ...;
  ref_comp A
  CONSTRAIN GLOBAL KEY;
}
], является комбинацией второго и третьего. Каждый объект класса В может ссылаться только на один объект класса А, и на каждый объект класса А может ссылаться только один объект класса В. Связь один к одному.

В любом случае R-переменная компонента ref_comp представляет собой двуарное отношение с аатрибутами (OID, refOID), и в любом случае мы можем оперировать обеими атрибутами по отделности или вместе.

Далее. Когда я говорю, что мы можем ходить по ссылке во всех направлениях, я в том числе подразумеваю, что можно определить компоент, содержащий не одну, но любое число ссылок . Это будет множественная связь. И для любого объекта мы можем найти все объекты, состоящие с ним данной связи.

Андрей Леонидович требует, что бы связь была бы определна явно. Что же если приспичит :), то можно создать такой класс, назвав его "LinkBetween...". Но это идет против идей НРМ и мы ничего от этого не выиграем. И дело даже не в этом. Ув. АЛ предлагает для описания предметной области использовать по крайне мере четыре понятиями - "объект", "атрибут объекта", "связь", "атрибут связи". НРМ, не теряя в в функциональности, использует только два - "объект" и "компонент объекта". И как то не получается у Андрея Леонидовича доказать, что его навороты чем то выигрывают у предлагаемого в НРМ крайне простого подхода к описания данных.
27 июл 05, 02:58    [1738260]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Андрей Леонидович. давайте больше к связям не возвращатся. Я даже готов согласен, что НРМ не смог выразить Ваши чаяния. В двадцатые раз повторяю, что такая цель даже не стояла.
27 июл 05, 03:04    [1738261]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
ModelR
Member

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

В НРМ все немного по другому. Ссылки задаюся направленно, но доступ по ним симметричен - то есть во всех направления.
Ну, не совсем симметричен - ведь ссылочная компонента принадлежит только одному из классов.
U-gene

Вернемся к нашему простому примеру. Существует класса А и класс В. Класс А содержит ссылку(ки) на класс В. Случай первый...я уже объснил. Каждый объект класса В может ссылаться на многие объекты класса А, и на каждый объект класса А могут ссылаться многие объекты класса В. Связь многие ко многим.
А как сказать должен? NOT EMPTY SET OF ?
CREATE CLASS A {}

CREATE CLASS B
{ ...;
  ref_comp NOT EMPTY SET OF A  ;
}
Каждый объект класса В должен ссылаться на один или более объектов класса А, и на каждый объект класса А может ссылаться один или более объектов класса В.
Кстати, ассиметрия и в том, что описывая ссылки в B невозможно сказать, что на каждый А должен ссылаться один или более B.
[quot U-gene]

Случай третий....
CREATE CLASS A {}

CREATE CLASS B
{ ...;
  ref_comp SET OF A
  CONSTRAIN GLOBAL KEY;
}
О, интересно. Т.е. уникальность определяется уже на R-переменной, а не на классе.
27 июл 05, 10:28    [1738674]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

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


Ну так я и сказал - заданы направленно, Но доступ возможен в обоих направлениях. Вот связь многие ко многим
CREATE CLASS A {}

CREATE CLASS B
{ ...;
  ref_comp SET OF A;
}

Здесь задана нарправленная ссылка.

Примеры доступ по ссылке
objectB[refComp]
вернет групповую ссылку на объекты о-типа А, на которые ссылается данный объект о-типа B (т.е. objectB ссылка на конкретный объект). Или
B[refComp] WHERE B...условие...
вернет групповую ссылку на объекты о-типа А, на которые ссылается объекты о-типа B, удовлетворяющие заданному условию.

Примеры доступа против ссылки
OBJECT(B WHERE refComp = objectA)
вернет групповую ссылку на объекты о-типа В, которые ссылается на данный объект о-типа А. Или
OBJECT(B EXPAND refComp WHERE refComp ...условие....)
или несколько по другому
OBJECT(B EXPAND refComp<..условие..>)
вернет групповую ссылку на объекты о-типа В, которые ссылается на удовлетворяющие заданному условию объекты о-типа А. Описание всего этого есть в НРМ.

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

Давайте закроем вопрос [о b]явно определяемых, симметричных связях. Таких в НРМ нет. В онце концов речь шла о соединения РМД и ОО-языков, Поскольку ни в одном из исходных компонентов их тоже нет, не стоит ждать их и от НРМ.

автор
А как сказать должен?

Я не знаю как сказать "должен". Речь идет о переменной, которая по определнию может содержать какие-то значения. Как сказать, что она должна это делать - я не знаю. ИМХО - это дело реализации. Поэтому фраза
автор
Кстати, ассиметрия и в том, что описывая ссылки в B невозможно сказать, что на каждый А должен ссылаться один или более B.
мне не понятна.

автор
О, интересно. Т.е. уникальность определяется уже на R-переменной, а не на классе.

В НРМ есть такое ограничение целостности - глобальный ключ. Если поле в о-типе объявлено как глобальный ключ, то его значения уникакльны во всех объектах этого типа. Какой смысл оно может нести - не мое дело. Разный. Самый простой пример использование этого ограничения - поле содержащее номер документа, должно быть объявнего как глобальный ключ. Это гарантирует, что во всех объектах, описывающих документы, значение этого поля не может повторяться и будет гарантировано уникальным. Тот факт, что я использовал этот ключ, что бы объявить связь многие к одному - это всего лишь следствие из смысла это ключа. По сути тоже самое, что и с номерами документов - только здесь определяется уникальность не номеров, а ссылок.
27 июл 05, 12:09    [1739204]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
2 U-gene
ИМХО, вы слишком часто ссылаетесь на реализацию.
Есть простой вопрос: данная реализация правильная или нет? Соответсвует НРМ или нет? Если достаточно, чтобы соблюдался синтаксис, то получается не модель данных а язык с открытой моделью.
Модель данных все-таки должна быть замкнутой и позволять изображать и данные и формулировать результат операции.

Упомянутый Должен... - это ограничение целостности, которое можно выразить в РМД как собственный предикат отношения (но не всегда в SQL DDL). Поэтому естественно этого ожидать и от НРМ.

В целом мне нравится идея, но как именно модель данных по-моему требует более детального описания операций.
27 июл 05, 16:41    [1740811]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
автор
Упомянутый Должен... - это ограничение целостности, которое можно выразить в РМД как собственный предикат отношения (но не всегда в SQL DDL). Поэтому естественно этого ожидать и от НРМ.


ИМХО как собственный предикат отношения в РМД можно описать все , что угодно, а не только должен.

Вспомник, как в примере описывается продажа.
DESCRIBE TUPLE SaleQty
{
	Art Article;
	Quantity INTEGER;
	Price FLOAT;
}

CREATE CLASS Sales EXTENDED GoodsMotion
{
	IsPayed BOOLEAN;
	SalesManager Manager;
	SaleItems SET OF SaleQty 
		CONSTRAIN 
		LOCALKEY (Art, Price);
	DoSale (DateOfSale) BOOLEAN;
}	
Предположим, что у нас есть два типа продаж - продажа товара и "продажа" рекламных материалов. Между ними есть существенная разница: товар продаем за деньги(Price>0) а рекламные материалы отпускаем на халяву (Price = 0). Соответственно этому мы делаем два класса наследника и меняем в них реализацию компопнента SalesItems, введя для него в каждом классе соответсвующие предикаты.

Мы не поменяли схему, мы не изменили ключи - иначе о R-переменной компонента речи идти не могло. Предикат ограничивает значения некоторыми условиями и не влияет на такие важнейшии для определния вещи как схема и ключи. Предикат может быть переопределён.

То есть предикаты - это дело реализации (типа). ИМХО они должны опрелеляться в реализации типа. Более того, система не реализующая поддержку таких условий все равно может быть R*O системой, хотя конечно такие возможности необходимы жизненно(но не формально).
27 июл 05, 17:17    [1740981]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Тьфу!ну почему здесь посты не редактируются? Предпоследний абзац читать так:

Мы не поменяли схему, мы не изменили ключи - иначе о существовании R-переменной компонента речи идти не могло бы. Предикат ограничивает значения некоторыми условиями, однако он не влияет на такие важнейшии для определения R-перменной вещи как схема и ключи Он не может их изменить. Благодоря этому предикат может быть переопределён, из чего следует что предикат - это дело реализации типа.
27 июл 05, 17:23    [1741020]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Опять про ограничения... Если допускаются произвольные ограничения целостности базы, то видимо они не должны быть частью определения класса. Например что-то типа,
CREATE CLASS A {} 

CREATE CLASS B
{ ...;
  ref_comp SET OF A  ;
}
CREATE constrain  xx as ( B[ref_comp] == OBJECT(А) );
должно означать что на каждый А должен ссылаться один или более B ?
== означает сравнение групповых ссылок.
28 июл 05, 12:47    [1743255]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

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

Я повторяю, что такого рода ограничения целостности могут быть необходимы жизненно, но они не являются необходимиыми с формальной точки зрения. Но если вам так хочется...
автор
CREATE constrain  xx as ( B[ref_comp] == OBJECT(А) );
должно означать что на каждый А должен ссылаться один или более B ?
...то я имею пару вопросов.

Говоря про ограничения целолстноти данных, я имею в виду условия на значения лежащие в каких-то переменных. Мы здесь значения какой переменной ограничиваем?

Давайте вернмся к обычным РСУБД. Есть две таблицы и мы хотим, что бы на все записи из первой таблицы, существовал бы FOREIGN KEY из второй таблицы. Мы как это сделаем?
28 июл 05, 14:26    [1744023]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
U-gene
Но если вам так хочется...
автор
CREATE constrain  xx as ( B[ref_comp] == OBJECT(А) );
должно означать что на каждый А должен ссылаться один или более B ?
...то я имею пару вопросов.

Говоря про ограничения целолстноти данных, я имею в виду условия на значения лежащие в каких-то переменных. Мы здесь значения какой переменной ограничиваем?
РМД предусматривает таже ограничения базы данных - согласованное состояние двух или более отношений, причем не только FK. (для примера см. Дейт 7е издание глава 8.5)
U-gene

Давайте вернмся к обычным РСУБД. Есть две таблицы и мы хотим, что бы на все записи из первой таблицы, существовал бы FOREIGN KEY из второй таблицы. Мы как это сделаем?
Обычные РСУБД это ORACLE, ASA и др.? Насколько я знаю, декларативно они этого не умеют. Скорее всего напишем процедурный код, специфический для СУБД. Но причем здесь СУБД? Мы же обсуждаем модель. То что производители СУБД сочли некоторые свойства РМД тяжелыми для реализации или мало полезными не значит, что они должны исчезнуть из РМД. Кстати в стандарте SQL есть Assertion.
28 июл 05, 17:41    [1745108]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
ModelR
РМД предусматривает таже ограничения базы данных - согласованное состояние двух или более отношений, причем не только FK. (для примера см. Дейт 7е издание глава 8.5)


Ну да! состояние(значение) первой переменной отношения мы ограничиваем состоянием(значением) второй переменной, или наоборот (но не одновременно оба случая - см.дальше). В вашем примере мы состояние(значение) какой конкретно переменной ограничиваем? Кстати, как называется глава 8.5 в 7-м издании (у меня 6-е - буду искать)?

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

автор
U-gene
Давайте вернмся к обычным РСУБД. Есть две таблицы и мы хотим, что бы на все записи из первой таблицы, существовал бы FOREIGN KEY из второй таблицы. Мы как это сделаем?
Обычные РСУБД это ORACLE, ASA и др.? Насколько я знаю, декларативно они этого не умеют.

Они этого и не сумеют. Я же этот вопрос недаром задал. Просто если бы такое ограничение существовало, мы бы во вторую таблицу не смогли бы вставить не одной записи. Нет такой операции в РМД - добавить кортеж в одну таблицу и одновременно изменить кортеж другой таблицы - а без такой операции это ваше ограничение не выполнить!!! И то же будет с вашим
автор
CREATE constrain  xx as ( B[ref_comp] == OBJECT(А) );


И здесь самое время вернуться к согласованному состоянию двух переменных отношений. Если первая зависит от второй, и, лодновременно, вторая от первой, то ИМХО возможны варианты, когда их вообще изменить нельзя будет.
28 июл 05, 18:17    [1745337]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Андрей Леонидович
Guest
Про связь "более двух объектов" говорить, пока, не стоит. Это, действительно, интереснейшая проблема, но Дейт и другие сторонники РМД только спекулируют на ней, намекая, что в РМД эта проблема будто-бы решена. Напоминаю, что просто совокупность n внешних ключей НЕ ПРЕДСТАВЛЯЕТ связь между n объектами (более того, сама эта совокупность ВООБЩЕ не нужна для представления связи) !

[Кстати, еще одна интересная фраза Дейта (опять про роль ключей в РМД), касающаяся связей (8-е издание, стр. 1051):

"Термин СВЯЗЬ используется в объектно-ориентированных продуктах и в соответствующей литературе в основном для связей, представленных в реляционной системе внешними ключами."

Вот как !]

... А я "не задолбался", и никогда "не задолбаюсь", повторять, что явно связь должна определяться:

а) вне описания самих объектов (по Вашему - классов);
б) и без создания класса "Link Between" !!!

Это, во-первых. А, во-вторых, Вы опять забыли про собственные характеристики связи (количество товара на складе и т.п.).

Какие навороты !? Не является количество товара на складе ни характеристикой товара, ни характеристикой склада. Это у Вас "завороты" (наверное, из хороших побуждений "минимализма"), а не у меня "навороты"...

P.S. Давайте, давайте "к связям больше не возвращаться". Любопытно посмотреть как это получится...
28 июл 05, 22:55    [1745795]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Вы Андрей Леонидович, видимо, других аргументов окромя несвязной связки "Дейт сказал ..... а я считаю что нужны!" в оправдание необходимости явного определения связей найти не можете.

На ваше "во-вторых" повторяю, что в компонентне моржет быть любое число атрибутов, и среди них - любое число атрибутов ссылочных типов и, соответсвенно любое число атрбутов нессылочных типов. Последние и представляют эти ваши харатеристики связи.

В том же примере из НРМ
DESCRIBE TUPLE SaleQty
{
	Art Article;
	Quantity INTEGER;
	Price FLOAT;
}

CREATE CLASS Sales EXTENDED GoodsMotion
{
	IsPayed BOOLEAN;
	SalesManager Manager;
	SaleItems SET OF SaleQty 
		CONSTRAIN 
		LOCALKEY (Art, Price);
	DoSale (DateOfSale) BOOLEAN;
}
компоненту SaleItems соответсвует R-переменная компонента Sales.SaleItems со схемой {Object(SALES); Art; Quantity; Price}. Таким образом писание о-типа Sales неяно задает связь типа многие-ко-многим между объектами типа Sales и объектами типа Article, причем у этой связи есть атрибуты Quantity и Price. Так что Ваше "во-вторых" вообще не канает.

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

автор
Напоминаю, что просто совокупность n внешних ключей НЕ ПРЕДСТАВЛЯЕТ связь между n объектами (более того, сама эта совокупность ВООБЩЕ не нужна для представления связи) !
А совокупнось n ссылок? И откуда Вы это напоминаете? И, кстати, если три восклицательных знака поставить, то будет куда убедительней!!!

автор
... А я "не задолбался", и никогда "не задолбаюсь", повторять, что явно связь должна определяться:

а) вне описания самих объектов (по Вашему - классов);
б) и без создания класса "Link Between" !!!
Этот факт(чтоВы не задолбаетесь это повторять) я понял давно. Но нам гагарам не понятно другое - а почему? И вот мы гагары, задолбались Вас спрашивать "почему же она должна определяться явно?" А Вы снова "что тут неясного! я не задолбаюсь повторять, что должна!" Однако хочется чего то нового - например аргументов, отличных от лозугов. А то снова получается, что Вы сказочник про белого бычка.
29 июл 05, 02:33    [1745909]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

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

Все таки интерсно, Вы специально мысли выворачиваете или у Вас просто мозг с логикой не дружит?
автор
[Кстати, еще одна интересная фраза Дейта (опять про роль ключей в РМД), касающаяся связей (8-е издание, стр. 1051):

"Термин СВЯЗЬ используется в объектно-ориентированных продуктах и в соответствующей литературе в основном для связей, представленных в реляционной системе внешними ключами."


Здесь нет про роль ключей. Здесь про вариант их использования. Здесь не сказано, что "внешние ключи использутся для представления связей"(тогда бы это было их "роль"). Здесь сказано, "связи представлены с помощью внешних ключей". Чувствуете разницу?

Если не понятно, попробуйте сравнить две фразы "карандаши используются для рисования линий" и "линии нарисованы с помощью карандашей". Если использовать первую трактовку, то единственная "роль" карандашей - это рисование линий (карандаши должны рисовать линии). Если вторую, то ривование линий - всего лишь вариант использования карандашей(карандаши могут рисовать линии, а еще карандашами можно рисовать точки, птиц, писать буквы, ковыряться в носу и тп).
29 июл 05, 03:31    [1745913]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
U-gene
ModelR
РМД предусматривает таже ограничения базы данных - согласованное состояние двух или более отношений, причем не только FK. (для примера см. Дейт 7е издание глава 8.5)


Ну да! состояние(значение) первой переменной отношения мы ограничиваем состоянием(значением) второй переменной, или наоборот (но не одновременно оба случая - см.дальше). В вашем примере мы состояние(значение) какой конкретно переменной ограничиваем? Кстати, как называется глава 8.5 в 7-м издании (у меня 6-е - буду искать)?
"8.Целостность данных","8.5Ограничения баз данных"
U-gene

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

автор
U-gene
Давайте вернмся к обычным РСУБД. Есть две таблицы и мы хотим, что бы на все записи из первой таблицы, существовал бы FOREIGN KEY из второй таблицы. Мы как это сделаем?
Обычные РСУБД это ORACLE, ASA и др.? Насколько я знаю, декларативно они этого не умеют.

Они этого и не сумеют. Я же этот вопрос недаром задал. Просто если бы такое ограничение существовало, мы бы во вторую таблицу не смогли бы вставить не одной записи. Нет такой операции в РМД - добавить кортеж в одну таблицу и одновременно изменить кортеж другой таблицы - а без такой операции это ваше ограничение не выполнить!!! И то же будет с вашим
автор
CREATE constrain  xx as ( B[ref_comp] == OBJECT(А) );


И здесь самое время вернуться к согласованному состоянию двух переменных отношений. Если первая зависит от второй, и, лодновременно, вторая от первой, то ИМХО возможны варианты, когда их вообще изменить нельзя будет.
Так на это и существуют транзакции. Целостность ограничений базы должна естественно проверяться для транзакции, а не отдельной операции.
29 июл 05, 11:11    [1746672]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Андрей Леонидович
Guest
1. Скажите, U-gene, если это не "раздувание флейма": Вы к чему склоняетесь:

- мир "состоит" из не связанных объектов, или - "только из объектов";

ИЛИ

- мио состоит из взаимосвязанных объектов, или - "из объектов и связей между ними"

?

Предположим, что "объекты" ЕСТЬ. Следует ли их явно представлять в базе данных, если ЭТО ПОЛУЧАЕТСЯ ? Или не стоит, даже если получается !? То есть лучше для чего-то исказить представление окружающего мира в базе данных ?

А теперь, если предположить, что связи между объектами тоже ЕСТЬ, зададим себе тот же вопрос. Следует ли их явно представлять в базе данных, если ЭТО ПОЛУЧАЕТСЯ ? Или не стоит, даже если получается !? То есть лучше для чего-то исказить представление окружающего мира в базе данных ?

2. Итак, Ваше предположение, что "количество товара на складе является характеристикой товара" - это не пропаганда, а убеждение ? Своеобразное представление об окружающем мире. Но я, конечно, уважаю любое своеобразное представление...

3. И совокупность n ссылок тоже не представляет ! Жаль, если Вы этого не понимаете...

4. Ведь Ваш мозг с логикой дружит ! Не могли бы Вы перечислить ДРУГИЕ ВАРИАНТЫ использования внешних ключей, у которых, как Вы опять настаиваете, только ОДНА РОЛЬ...
30 июл 05, 20:53    [1749977]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-genу
Guest
2 ModelR
автор
"8.Целостность данных","8.5Ограничения баз данных"
В 6-м издании я это аж в 16-й главе нашел. Последенее издание что ли купить?

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


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

Почему так издание оговариваю? Просто я посмотрел где то тут оглавление нового издания и немножко пришел в ужас. Я конечно понимаю что Дейт - крутой дядька. Однако ИМХО раньше оно как то понятней было. Поясню. Отдельно существует формальная РМД (отношения, операции, ограничения). Отдельно сущетсвуют концепции, которые могут применяться в общем то к любым системам хранения данных - например те же транзакции. Отдельно имеются некие языковые фишки - генераторы типов и .т.п.вещи. Соответсвенно РМД в таком "классическом" виде, например, не требует понимания транзакций.

А у Дейта, судя по оглавлению 8-го издания (сегодня же покупаю), все это свалено в кучу (в отличии от 6-го). Например в 6-м издании транзакции появляются аж на 354-й станице (гораздо позже объяснения РМД) а в 8-м они появляются аж в 3-й главе ("Введение в РБД"). Почему? Потому что без них "ограничения БД" не объяснить? Неужели BEGIN TRANSACTION стало операцией РМД? В общем куплю книжку - буду разбираться.

К чему я так растекся мыслью?
автор
...Так на это и существуют транзакции. Целостность ограничений базы должна естественно проверяться для транзакции, а не отдельной операции.
Вобщем в НРМ я не словом про транзакции не упоминаю (кроме как в одном примере, где они к основному излождения никак не относятся). Соотвественно, я такого рода ограничения вводить не могу. Да и не хочу. Может быть потому, что У НРМ нет цели "дать подробное описание операций, требующееся именно как для модели данных". Цель другая - продемонстрировать возможный подход к объекдинения свойств ОО и рел. систем в рамках единой системы..
1 авг 05, 14:47    [1752379]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
автор
1.......Вы к чему склоняетесь:

- мир "состоит" из не связанных объектов, или - "только из объектов";

ИЛИ

- мио состоит из взаимосвязанных объектов, или - "из объектов и связей между ними"

?

Предположим, что "объекты" ЕСТЬ. Следует ли их явно представлять в базе данных, если ЭТО ПОЛУЧАЕТСЯ ? Или не стоит, даже если получается !? То есть лучше для чего-то исказить представление окружающего мира в базе данных ?

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

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

Все это не предположение, не пропаганда и не убеждение - это способ, которым данная связь может быть в этой системе типов выражена. Когда я увижу Вашу систему типов, тогда можно будет о чем то говорить и что то сравнивать. А иначе Вы можете просто сказать "а хочу что бы ВСЁ! и СРАЗУ! - что у вас не так? ну и дураки вы все". Чем собственно Вы и знимаетесь. Например...
автор
3. И совокупность n ссылок тоже не представляет ! Жаль, если Вы этого не понимаете...
Куда уж нам, гагарам, до таинств полета Вашей мысли (это жжжжж неспроста)... Вы еще не задолбались доказывать свою правоту, путем повторения мантры "я прав и все тут"?

автор
4. Ведь Ваш мозг с логикой дружит ! Не могли бы Вы перечислить ДРУГИЕ ВАРИАНТЫ использования внешних ключей, , у которых, как Вы опять настаиваете, только ОДНА РОЛЬ...
ГЫ-ГЫ. А я их не хочу перечислять. Я рассматриваю ключи как равенство 2+2=4. А Вы пытаетесь мне задать вопрос "Не могли бы Вы перечислить ДРУГИЕ ВАРИАНТЫ использования этого равенства, кроме как для сложения количеств и расстояний?" Дык меня то интересует само равенство, а не то, как Вы будете его "использовать". Используйте как хотите. Какую "РОЛЬ" дадите, ту они и будут "ИГРАТЬ". А изначально нет у ключей "РОЛЕЙ". Ни одной, ни двух, ни десяти. Я на этом настаиваю....

В общем резюмирую - Вы так и не смогли показать, что связь, описанная явно, хоть чем-то лучще, чем связи представленная в том виде, как это предложено в НРМ. Никаких аргументов, окромя "я точно знаю" и "это же очевидно" обществу не представлено. Были "какие-то" формулы но и они сгинули во мгле веков. И эти люди запре...тьфу, приглашают меня на семинар?
1 авг 05, 15:32    [1752612]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Транзакции конечно не часть РМД. Про то, как и когда проверять ограничение типа 1:1 , которое требует одновременного изменения двух таблиц, РМД отвечать не призвана, равно как и про порядок проверки любых других ограничений. Однако если СУБД претендует на соответствие РМД, она должна уметь работать со всеми допускаемыми РМД ограничениями. Т.е. необходимость транзакций в СУБД следует из требования соответствия РМД, хотя и не является частью РМД.
Воля автора как поступить со своим творением :), однако ничего невозможного в ограничении
CREATE constrain  xx as ( B[ref_comp] == OBJECT(А) );
не видно.
1 авг 05, 15:43    [1752665]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Однако если долго долбить, можно что-то выдолбить. Вот здесь я предположил, что было бы неплохо объявлять глобально видимые группоывые ссылки. На самом деле групповая ссылка - всего лишь один из простейших случаев переменной значимого типа. Но раз я сказал "а" имеет смысл сказать и "б"? Может быть имеет смысл в глобальных перменных с более сложной структурой? Например

CREATE CLASS A
{...}

CREATE CLASS B
{...}

DESCRIBE TUPLE A2B
{
	refA A;
	refB B;
	...; //что то еще
}

CREATE varA2B AS SET OF A2B
    CONSTRAIN...;

На выходе получаем глобально определнную переменную типа-отношения varA2B, возможная РОЛЬ которой будет заключаться в явном представлении связи между объектами класса A и класса B. В общем если ув. АЛ это устроит :), то я буду думать, а если не устроит, то буду думать все равно ;).
1 авг 05, 15:49    [1752696]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 ModelR Дык я про то и говорю! У Дейта в 6-м издании ограничение для БД не являлось ограничением РМД! Оно в таком виде появилось только в 8-м!!!А меня пока и 6-е устраивает :).... В конце концов, нельзя же всем на слово верить, хоть это и Дейт - НРМ этот факт буквально во введении отмечает....
1 авг 05, 15:56    [1752722]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Андрей Леонидович
Guest
Какие уж "формулы", если Вы не обращаете внимания даже на самые элементарные текущие высказывания, причем, что очень важно, хорошо известные и без меня. Например, про n! перестановок...

Зря Вы надеетесь, что связь должна быть ВЫРАЖЕНА В СИСТЕМЕ ТИПОВ. Мне "заморачиваться" не нужно. И объекты, и связи между ними существуют независимо от "систем типов". И я "склоняюсь" к отражению этой, по моему очень простой мысли (при чем здесь "дураки вы все" ?), в базе данных...

Меня устроит, на данном этапе:
а) идентификация сущностей идентификаторами, которые не являются одной из характеристик сущности;
б) явное представление связей между сущностями путем "связывания идентификаторов"; раз идентификаторы не интегрируются в объект, в "один ряд с характеристиками", то и связи ТЕМ БОЛЕЕ не следует интегрировать в объекты (в "один ряд с характеристиками объектов")...
1 авг 05, 23:10    [1753827]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 Андрей Леонидович
Да!... Какие уж "формулы"...(с)ув.А.Л. если их попросту нет.

автор
Зря Вы надеетесь, что связь должна быть ВЫРАЖЕНА В СИСТЕМЕ ТИПОВ.
А в чем она должна быть выражена? Словами? Мы тут "Войну и Мир" пишем? Такие весчи, как "тип", "значение" и "переменная" для Вас роли не играют? Мы что, данные будем через "жжжжж" из Вашей головы описывать? И этот человек запрещает мне ковы...тьфу, приглашают меня на семинар?

автор
Меня устроит, на данном этапе:
а) идентификация сущностей идентификаторами, которые не являются одной из характеристик сущности;
б) явное представление связей между сущностями путем "связывания идентификаторов"; раз идентификаторы не интегрируются в объект, в "один ряд с характеристиками", то и связи ТЕМ БОЛЕЕ не следует интегрировать в объекты (в "один ряд с характеристиками объектов")...

Значит НРМ (с учетом некоторых дополнений) Вас должно, как это не печально, устроить... :)
2 авг 05, 09:58    [1754292]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8 9 10 .. 14   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить