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

Откуда: Новосибирск
Сообщений: 2402
Блог
Андрей Леонидович
P.S. А Вы задумайтесь все ли с алгеброй-то хорошо ?
Подобно тому, как "ключи" и "сущности" (помните "entity integrity" ?) неизбежно "вмешиваются" в "модель абстрактых данных", "напоминая" об утраченных идентификации, семантики и навигации, с "алгеброй" и "замыканием" тоже не все гладко. Что собой представляет РБД ? Множество отношений, связанных "клеем" (механизм внешних ключей). Что же должен представлять собой "ответ на запрос" ? Да то же самое - множество отношений, связанных "клеем" (механизм внешних ключей). Вот это и есть логическое (и концептуальное, если поднапрячься) "замыкание". А математическое "замыкание" дает другой результат. Получаем некое внешнее представление результата запроса (в виде одного отношения), а не сам результат (в виде множества взаимосвязанных отношений)...
Нифига-то Вы не поняли, любезный Андрей Леонидович...
6 авг 05, 20:52    [1769565]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

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

Я намекаю уже в который раз. Если Вам хочется "продолжать", откройте свой топик и продолжайте там. Дайте ссылки на первоисточники, найдите наконец то Ваши формулы, и в путь!!!..... Но здесь "продолжать" не надо - тем более, что я уже признал свое полное моральное поражение. Не надо здесь флудить - неужели Вы этого до сих пор не поняли? Ай-яй-яй, как это печально....
7 авг 05, 12:08    [1769669]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 ModelR Не нашел Ваших координат (есть личный вопрос). Вы можете со мной связаться (_grg@comail.ru_)?
15 авг 05, 12:11    [1785963]     Ответить | Цитировать Сообщить модератору
 НРМ  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Прочел монументальный труд.

Прав ли я кратко суммировав:

1. Простые таблицы расширяются возможностью хранить массивы и вложенные объекты, коллекции вложенных объектов (далее вложенные объекты)

2. Структура объектов может быть наследована и изменена.

3. Запросы полиморфны, если не указано обратное

4. Пункт 3 распостраняется и на вложенные объекты.

5. Запросы могут обращаться к вложенным объектам через точку типа customer.address[0].city. JOIN используется для связи к другими объектами
15 авг 05, 13:14    [1786235]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

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

1. Простые таблицы расширяются возможностью хранить массивы и вложенные объекты, коллекции вложенных объектов (далее вложенные объекты)

Нет. Нет там ни массивов, ни вложенных объектов, ни тем более вложенных коллекций. Не понимаю о каких таблицах Вы говорите. Если речь идет о R-переменных, то эти переменные отношений определны на множестве скалярных атрибутов - никаких массивов, коллекций и объектов. Семантика сложных стурктур сохраняется только в именах R-переменных и в именах их атрибутах.

Пример
DESCRIBE TUPLE sometuple
{
i INTEGER;
s STRING;
}

CREATE CLASS ot
{
...
c SET OF sometuple
CONSTRAIN... ;
..
}

Каждый объект типа ot содержит комонент с атрибутами i и s.Соответсвенно, мы можем говорить о R-переменной компонента "ot.c" с атрибутами "i" и "s", ои о R-переменной типа "ot" с атрибутами "с.i" и "с.s". Я специально имена переменных и их атрибутов обозначил кавычками. Сами атрибуты скалярные(никаких вложенных коллекций!), но имена у них сложные. В НМР повторяется несколько раз, что РМД не накладывает никаких требований на имена переменных отношений и их атрибутов, за исключением требования уникальности. Соотвественно я могу написать имя атрибута как "с.s" или как "c.ref.comp_of_ref.scalarattr_of_comp_of_ref" - в любом случае за этим сложным именем атрибута, несущего в себе семантику ссылки, стоит некое скалярное значение.

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

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

2. Структура объектов может быть наследована и изменена.
Да.

3. Запросы полиморфны, если не указано обратное
Я бы сказал так - "В запросах используются данные из R-переменных полиморфных классов". Откуда беруться и как получаются эти данные, определяется системой на основании реализации этих классов.

4. Пункт 3 распостраняется и на вложенные объекты.
С точки зрения пользователя, который не задумывается о R-переменных (у него в голове есть структура сосссылками) - Да.

5. Запросы могут обращаться к вложенным объектам через точку типа customer.address[0].city. JOIN используется для связи к другими объектами
Да. Опять - же с точки зрения этого пользователя. Формально, в терминах R-переменных работа со сслылочными структурами есть те же JOIN-ы, но пользоваетель не должен об этом не думать.

ИМХО НРМ предлагает подход, позволяющий освободить пользователя от лишнего явного использования JOIN-ов. Например, вместо того, что бы каждый раз получая данные о продажах, делать " таблица_заголовков JOIN таблица_строк ON ..."? можно использовать просто "продажи". А если нужны данные только, например, по строкам, можно использовать те же "продажи.строки". А если учесть возможность переопределять компопненты, то я даже не берусь навскидку написать то, что в традиционном SQL будет соотвествовать простому обращению к полиморфным "продажам."
15 авг 05, 15:24    [1786847]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Тьфу - не классов, а О-типов. Ну не класс это, не класс.... :)
15 авг 05, 15:26    [1786854]     Ответить | Цитировать Сообщить модератору
 НРМ  [new]
Dimonische
Member

Откуда:
Сообщений: 137
U-gene
Тьфу - не классов, а О-типов. Ну не класс это, не класс.... :)


Фигня прокололся )


Просто неохота заморачиваться на R переменные и пр. когда можно пользоваться имеющейся теминологией и ничего не терять.
15 авг 05, 16:47    [1787196]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Тьфу - не классов, а О-типов. Ну не класс это, не класс.... :)
Это не Вам - это я сам себе сказал.... :) Тоже привык. Опять же, с точки зрения пользователя оно так и есть - он этой разницей заморачиваться не должен.
15 авг 05, 16:52    [1787218]     Ответить | Цитировать Сообщить модератору
 НРМ  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Я даже больше скажу.

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

Хотя есть простейшие термины - таблица, запись, поле записи.

Как сказал кто-то из классиков:

Если вы 6-ти летнему ребенку не можете объяснить чем занимаетесь, значит вы занимаетесь фигней.
15 авг 05, 17:22    [1787375]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
дураг с инецеативой
Guest
Dimonische

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

Хотя есть простейшие термины - таблица, запись, поле записи.

Уточнение:
В РМД - отношение, кортеж, атрибут (эт, конечно, слишком абстрактно и на практике не реализовано).
В SQL - таблица, запись, поле записи (эт, конечно, просто и понятно и используется на практике).
Разница между понятиями есть и довольно существенная.
SQL = извращение РМД РМД
15 авг 05, 17:48    [1787522]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 Dimonische
А я еще и добавлю!...

Про классиков есть разные версии Я тут в сети кое-что нашел

из сети
...Про это еще Эйнштейн сказал, что ученый, который не может объяснить теорию относительности 5-класснику, не ученый, а шарлатан...

...А. Эйнштейн говорил, что ученый, который не может объяснить пятилетнему ребенку теорию относительности - шарлатан…

...Альберт Эйнштейн: "Если вы не можете что-то объяснить шестилетнему ребенку, значит вы сами этого не понимаете"...

...Эйнштейн сказал: если вы не можете объяснить, что вы делаете, то
не стоит этого делать...

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

...Как говорил Эйнштейн, ученый, который не может уборщице объяснить, чем он занимается, зря получает зарплату...
Так что же все таки сказал Эйнштейн? Когда я зашел на сайт www.aphorism.ru я нашел там целую кучу афоризмов,приписывваемых А.Э. Но! среди них не было ничего про объяснение сложных вещей людям без соответсвующего образования.

Вот если бы кто-то смог обяснить 6-ти летнему ребенку, что есть те же ООП, РМД и все, что с этим связано.... А то ведь и взрослые дяди всё норовят "простейшии термины" пользовать, считая, что при этом они ничего не теряют(что же, пользователь - он и есть пользователь). И на здоровье, и это все понятно.... Я помниться, давным-давно с С на С++ переходил, так все думал - и зачем это все? Можно пользоваться простым С и ничего не теряешь... И ведь действительно, пользуя С++ в сравнении с С я практически ничего не потерял. Зато сколько приобрел!...но это я потом понял....

В общем, как говорил все тот же Эйнштейн "Никакую проблему нельзя решить на том же уровне, на котором она возникла." Постейшие термины принадлежат уровню, где проблема возникла. Можно пользоваться ими и дальше - при этом ничего не будет потеряно. И точно остануться проблемы.
16 авг 05, 01:10    [1788325]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Раз уж речь зашла о таблицах.... Вопрос к знатокам SQL. Я понимаю, что есть теория, а есть суровая практика. Я понимаю, что SQL очень развился, и порой возникает ощущение, что там можно сделать уже все. Правда, ИМХО там это все не совсем очевидно..... Но даже не в очевидности дело...

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

Вот выдержки из примера НРМ (незначимые куски я заменил на )

DESCRIBE TUPLE ArtQty
{
  Art Article;
  Quantity INTEGER;
}

CREATE CLASS GoodsMotion
{	
  ...
  MovedItems SET OF ArtQty 
    CONSTRAIN 
    LOCALKEY Art;
}

ALTER CLASS GoodsMotion
REALIZE  ... MovedItems [color=blue]AS STORED[/color];
Итак, мы имеем о-тип GoodsMotion, описывающий отгрузки со склада. Соответственно, мы имеем R-переменную компонента типа "GoodsMotion.MovedItems" и можем с ней как то работать. Например мы можем найти артикулы, которые отгружались в количестве 100 штук, оформив результат в виде глобальной переменной значимого типа

CREATE 100PiecesArticleList SET OF Article 
AS SELECT Art FROM GoodsMotion.MovedItems WHERE Quantity = 100.
Теперь у нас есть глобальная перменная 100PiecesArticleList , которую мы можем использовать в запросах. Это вычисляемая перменная - фактически аналог типа.

До сей поры ничего нового. Данные об отгрузках типа храняться и на их базе сделан вид. В SQL такое как два пальца....

Теперь я наследую и переопределяю о-тип GoodsMotion

DESCRIBE TUPLE SaleQty
{
	Art Article;
	Quantity INTEGER;
	Price FLOAT;
}

CREATE CLASS Sales EXTENDED GoodsMotion
{
  ...
  SaleItems SET OF SaleQty 
    CONSTRAIN 
    LOCALKEY (Art, Price);
  DoSale (DateOfSale) BOOLEAN;
}

ALTER CLASS Sales
	REALIZE SaleItems AS STORED;

ALTER CLASS Sales
	REALIZE MovedItems AS 
	SUMMARIZE SaleItems 
	BY Art ADD Sum(Pieces) AS Pieces;
Отмечу, что я переопределил компонент MovedItems. Теперь R-переменная компонента типа "GoodsMotion.MovedItems" содержит не только хранимые но и вычисляемые данные. При этом нам не пришлось делать каких либо UNION-ов или других операций, сливающих хранимые и вычисляемые данные вместе. Нам вообще не потребовалось менять существующий вид "100PiecesArticleList". Мы просто унаследовали и переопределили тип. Это можно сделать в SQL?

Я это все к тому, что "простейшии термины" "таблица" и "вид" таки не могут заменить R-переменные. Термины "таблица" или "вид" УЖЕ определz.n реализацию - подразумевается, что они сами по себе УЖЕ определяют, храняться эти данные или как-то вычисляются. R-переменная (подобно таблицам и видамв первом приближении) представляет данные в виде отношения, однако (в отличии от них) откуда эти данные беруться, храняться они или вычисляются - все это определяется реализацией класса. Эта реализация может быть 20 раз переопределна, и, соответсвеннол, R-переменная будет содержать данные полученные 20-ю разными способами. Но никаких изменений существующих запросов - просто переопределние типа.
16 авг 05, 10:52    [1788989]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2402
Блог
To U-gene

Мне кажется, Вам надо перечитать Третий манифест. Очень похоже, что то, что Вы предлагаете, там просто содержится. Реализацию Вашего примера на SQL на вскидку действительно придумать сложно, но, поднатужившись, вероятно можно. А вот на Tutorial D такое должно делаться довольно легко... Наверно... Но думать лень.
16 авг 05, 11:18    [1789172]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Павел Воронцов
Реализацию Вашего примера на SQL на вскидку действительно придумать сложно, но, поднатужившись, вероятно можно.
ИМХО это будет как переписывание программы С++ в использую plain C.

Павел Воронцов
А вот на Tutorial D такое должно делаться довольно легко... Наверно... Но думать лень.
Ой как Вас ленивых много развелось ...:)... ИМХО конечно можно, но так же как см. выше про SQL...

Как медитации?
16 авг 05, 11:40    [1789333]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2402
Блог
U-gene
Как медитации?
Плохо. Всё не до них. Недосуг. Руки-ноги не доходят.
16 авг 05, 13:29    [1790138]     Ответить | Цитировать Сообщить модератору
 НРМ  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Мне кажется, основная сила НРМ (если будет стандарт (например SQL 4) на основе HPM):

ВМЕСТО ПОНЯТИЯ "ЗАПИСЬ" можно будет оперировать сложными по структуре КЛАССАМИ С ВЛОЖЕННЫМИ МАССИВАМИ, КЛАССАМИ и ПР.

Это то что мне постоянно не хватает в реляционыых базах. А главное, это будет переносимо, реализованы JDBC, ODBC и пр. драйверы, EJB 4.0 сможет такие базы использовать и я наконец буду в шоколаде.
16 авг 05, 15:46    [1790882]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
дураг с инецеативой
Guest
Dimonische
Мне кажется, основная сила НРМ (если будет стандарт (например SQL 4) на основе HPM):

ВМЕСТО ПОНЯТИЯ "ЗАПИСЬ" можно будет оперировать сложными по структуре КЛАССАМИ С ВЛОЖЕННЫМИ МАССИВАМИ, КЛАССАМИ и ПР.

Это то что мне постоянно не хватает в реляционыых базах.


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

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

Где-то видел я высказывание Дейта, в духе, что можно, например, объект "крыло самолета" представить, хранить и обрабатывать в РБД как значение абстрактного типа данных (домена), но можно и описать множеством значений relvars, но это разные уровни абстракции, и смешивать их нельзя.
16 авг 05, 16:19    [1791119]     Ответить | Цитировать Сообщить модератору
 НРМ  [new]
Dimonische
Member

Откуда:
Сообщений: 137
дураг с инецеативой


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



А я вот знаете-ли очень хочу этим заняться.

Надоело мне, когда простенькую схему

Портфолио->Мембер->SpreadBySecurity->Ratings

надо постоянно выгребать кучей джойнов. А так, получил Портфолио и вуаля - никаких запросов.

На самом деле - возможность выбора - отношение или встроенный объект, очень важна.

Есть масса сложных объектов, для которых в 99% случаев надо получать сразу все уровни. Просто потому что эти уровни его неотемлемые характеристики в рамках данного софта.

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

СВОБОДА епрст
16 авг 05, 16:31    [1791206]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
2 U-gene и др.
По поводу мультимножеств и идентификации, разговор о которых в этой теме шел довольно долго, можно еще почитать статьи и дискуссии Дейта:
DOUBLE TROUBLE, DOUBLE TROUBLE PART 1
DOUBLE TROUBLE, DOUBLE TROUBLE PART 2
ON DUPLICATES
More on Duplicates and Countability
17 авг 05, 09:24    [1792875]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

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

автор
Кроме этого придется еще и думать (ой, звыняюсь, не всем, конечно, многим это больно), когда использовать отношения, а когда вложенные массивы, классы и т.д., как и где задавать ограничения непротиворечивости данных и т.п.
Дык!..думать то не надо:)...Думаем исключительно в терминах сложных структур. Однако можем ипользовать операции РМД, обращаясь к данным про которые мы думаем как о сложных структурах. При этом мы продолжаем думать о данных как о сложнных структурах, что достигается благодоря тому, что в этих оперциях используются сложные имена переменных отношений и сложные же имена их атрибутов (то есть они сложные с нашей точки зрения, а с точки зрения РМД - это просто имена). Однако эти переменные - являются б/п переменными отношений, определённых на множестве скалярных доменов.

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

Где-то видел я высказывание Дейта, в духе, что можно, например, объект "крыло самолета" представить, хранить и обрабатывать в РБД как значение абстрактного типа данных (домена), но можно и описать множеством значений relvars, но это разные уровни абстракции, и смешивать их нельзя.
Ну может Дейт так и думает :). У меня по поводу НРМ есть аналогия. Если вглянуть на бочку сверху - она круг. Если сбоку - она прямоугольник. Однако это одна и та же бочка. НРМ рассматривает данные как эту бочку. Они могут быть представлены как множество объектов и, одновременно, как множество отношений.
НРМ(стр13)
Другими словами, данные, представленные в виде значений компонентов объектов, и данные, представленные в виде значений R-переменных - это одни и те же данные (в дальнейшем мы будем говорить о двояком представлении данных).

Но это одни и те же данные, и это один и тот же уровень абстракции.
17 авг 05, 12:40    [1793988]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Пред. сообщ. было для дурага с инецеативой
Добавлю
Похоже такое развитие приведет не к упрощению, а к усложнению проектирования БД.

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

В первом приближении в таких системах вместо того, что бы проектировать объекты приложения, и, затем, под них проектировать БД, мы должны проектировать объекты предметной области и, уже затем, делать какой то интерфейс Получается типичная КС система (только используется уже не сервер данных а ...ммм... наверное можно сказать, что сервер моделей ПО), где С является соверщенно отдельной и независимой от К системой. Мы можем развивать модель ПО не трогая К, или мы можем делать любые К.

Насколько это сложнее?
17 авг 05, 14:53    [1795022]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
дураг с инецеативой
Guest
U-gene
При описании о-типов имеется очень четкое деление на описание испецификации и описание реализации. Работа работы с объектами этих типов опирается исключительно на спецификацию. Реализация может быть изменена, переопределна и т.п.
...
Думаем исключительно в терминах сложных структур.
...
Просто описываем объектный тип, создаем объекты этого типа, а потом можем выполнить например SELECT использующий сложные (с точки зрения пользователя, котырый, благодоря этому, продолжает думать про сложные структуры) имена.

Т.е. НРМ - просто логический уровень представления данных (объекты, методы, полморфизм etc.), скрывающий свою реализацию, основанную на РМ?

U-gene

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

Но это одни и те же данные, и это один и тот же уровень абстракции.

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

И еще - может, я где-то недосмотрел, но не увидел решения "горячего" для адептов ООП вопроса - получение и сохранение в приложениях "объектов" целиком.

BTW: Разложение хранимых компонентов объектных типов НРМ по рел.отношениям чем-то напоминает мне RM/T [Кодд, 1979]
17 авг 05, 15:09    [1795129]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Т.е. НРМ - просто логический уровень представления данных (объекты, методы, полморфизм etc.), скрывающий свою реализацию, основанную на РМ?
Хочу у Вас уточнить...
НРМ(стр24)
...Слово "реализация" в данном изложении становиться явно перегруженным. Во-первых, мы используем это слово, когда говорим о реализации типов R*O системы. Во-вторых, мы используем его, когда говорим о реализации системы на базе существующих РСУБД. Естественно, это не одно и тоже. Говоря образно, понятие "реализация типов" принадлежит модели данных и, следовательно, относится только к уровню представления данных. Реализация же системы определяет взаимосвязи между уровнем представления и уровнем хранения...
Задавая свой вопрос, Вы слово "реализация" в какой смысле имели в виду? На всякий случай - говоря о четком делении описания типов на реализацию и спецификацию имел в виду конечно первое.

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

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

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

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

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


Сл.вопрос...
И еще - может, я где-то недосмотрел, но не увидел решения "горячего" для адептов ООП вопроса - получение и сохранение в приложениях "объектов" целиком.

Дык...я тут про парадигму(не люблю это слово :) ) уже написал... ИМХО "получение и сохрание объектов" фактически означает зависимость между К и С в КС системах. НРМ предлагает немножко вообще совсем не то.
17 авг 05, 17:05    [1796029]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
serg99
Member

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

Направление мысли по моему правильное.
17 авг 05, 17:24    [1796187]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Кстати! Вчера целый вечер потратил, но с Tutorial D у меня аналог моего примера пакамист не вырисовывается.
17 авг 05, 17:42    [1796364]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9 10 11 .. 14   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить