модВот теперь все понятно и пора делать выводы Это на основании трех моих постов? Ну-ну...

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

Кстати - а куда делись отношения, содержащие данные например только об одном компоненте класса. Или отношения, содержащих связанные данные о нескольких классах, когда один из них ссылается на другой. Я еще раз повторяю: один класс -> много отношений.

Я ленивый человек - я не хочу руками делать CREATE VIEW , в том случае, если это VIEW следует из семантики данных (например вручную создавать VIEW в котором соединяются заголовки и строки накладных). Я не хочу руками делать CREATE VIEW, связывая данные классов, ссылающихся друг недруга. Я не хочу руками делать UNION, объединяя данные классов наследников, для которых поменялась реализация. Все это может делать система - надо просто использовать правильные имена и правильтные комбинации имен, заданных в описании предметной области посредством множества полиморфных наследуемых классов.

модт.е. как раз класс=отношение. Ну - вам виднее Мои обоснованные предположения о Вашем неознакомлении с обсуждаемым предметом не были Вами опровегрнуты. Пытаетесь спорить о вкусе устриц? Попробуйе их сначала.

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

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

модЕсли уж хотите быть точным то переменная отношения, принимающая значения. Я хочу быть точным и поэтому написал именно то, что написал.

мод U-geneКласс - это неясно что...
Абсолютно с вами согласен, именно поэтому этим и нельзя пользоваться. Не понял:).... только что кто то написал "Класс = отношение"...это был другой мод ?

модВ РМД нет, есть в реализациях. Так "все можно сделать оставаясь в рамках РМД" (с) мод или все можно сделать оставаясь в рамках реализаций, явно нарушающих РМД? Вы уж определитеь батенькак что по Вашему можно.

модЭто вообще не понятно... очень хорошо объясняет, почему же... модя не увидел никаких плюшек.

модНаследники/родители - это разные классы Сильная фраза . Например птицы - это не страусы, а страусы - это не птицы.

модМн-во отношений определяется напрямую при построении РМД, зачем еще какие-то левые способы давайте скажем так, как оно есть - "зачем еще какие-то непонятные Вам способы"? Действиельно - непонятно...зачем:).

Впечатление, что Вы не только моих постов не читаете, но и своих не помните.

В общем ИМХО ничего не сделать - пишите руками думая изредка головой и, главное, не доверяйте автоматам. Правильно! Ну их - эти автоматы! :) И зачем их тока кто то выдумал то? Ерунда это какая то....

мод U-gene а если свойство описывается нескалярным значением - кортежем или отношением?
Именно так я написал

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

А как так красиво на розовеньком фоне писать? :))
2 4321

ЕСли не ошибаюсь, Вы про этот пост

tchingiz мод"сущности" реального мира моделируются обьектами ооп, т.е.
реальный самолет в небе моделируются обьектом класса "самолет"

...это так хорошо звучит, пока Вы обсуждаете один класс....

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

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

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

Пояcню. Есть отгрузки и у отгрузок есть св-ва. Возьмем какое-нибуть самое простое (скалярное) - напимер "дата". Обычно пишут "дата отгрузки" тем самым связывая это свойство с той сущностью, которую это свойство характеризуют. Догматики ОО, утвердающие, что все должно моделироваться объектами скажут конечно же, что дата - это объект. Тем самым в системе, содержащей данные о двух отгрузках будет четыре объета - две собственно "отгузки" и две "даты".

Я не спорю, что дата - это значение, и что для ее хранения нужна какая- то перменная. И тот факт, что для двух дат нужны две разные пременные у меня сомения не вызывает. У меня так же не вызывает факт, что система для доступа к этим значения должна как то эти переменные различимо идентифицировать. Но ИМХО эта идентификация имеет исключительно внутренний системгый характер и к идее объектов никакого отношения не имеет. Дата - это такая сущность, которая сама по себе полностью идентифицируется своим собственным значением. Например, если две разные отгрузки имеют одну и ту же дату... ну в общем в этой фразе все уже сказано. А 2+1=3 Нафига же создавать 4-ре идентифицируемых объекта? ИМХО представлять дату как идентифицируемый объект - это значит неправильно (по крайней мере избыточно) описывать ПО.

Следующий пример касается гораздо более сложного cв-ва - список строк. Список строк - это отношение. Отношение - это тоже значение. Например две разные отгрузки могут иметь абсолютно одинаковые позиции - и этим тоже все сказано.

Перейдем теперь к OID. Если мы говорим, "вот эта штука как-то отличется от других" это значит что у неё есть некие свойства, которые позволяют нам это сказать. Другими словами, свойство уникаальности - это суперпозиция многих (всех?) других свойств. Для создаваемой модели эти другие cв-ва сами по себе могут быть абсолютно неактуальны. ИМХО OID есть системное значение выражающее свойство уникальности, безотносительно других свойств, на самом деле говорящих о уникальности. И если система является объетно-ориентированной , то она должна поддерживать идею, что описание любой....штуки :) в терминах этой системы должно включать значение OID(возможно скрытым для пользователя способом). То есть если просто система - то набор значений, если ОО система - то набор значений, описывающих свойства... разных штук :) + OID (которое тоже является значением, описывающим свойсво этой штуки).Здесь идентификация имеет модельный характер.

Это я к тому, что сущности должны делиться на свойства(значения в термимах системы) и собственно сущности (СС или объекты в теримнах системы).

Для того, что бы описать СС,мы сначала должны описать значения и эти значения могут быть весьма сложными (но это не объекты!). Однако говорить о каком-то наследовании для типов значений ИМХО не нужно. Значения либо равны, либо не равны. Если список отгруженного товара имеет атрибуты (артикул, кол-во) а список проданного товара - атрибуты (артикул, кол-во, цена), то это просто разные значения одного и того же типа отношения.
Кроме того ,значения изначально конечны в своей детализации(дата, адрес, список строк отгузки). Кроме того значения изначально конечно в своей детализации (что неразвыво звязано с самоидентифицируемостью..... невозможно сравнить что то бесконечное.).

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

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

Два последних абзаца местами перепутал.

Было http://www.sql.ru/forum/actualthread.aspx?tid=147188&pg=8#2845512]

Наследование для отношений - это создание новых отношений на основе уже сущ. (копирование свойств) + возможность использования программ, написанных для других отношений. Птиц запихнем в одно отношение, а стаусов в другое?

Было - Ответил

Наследование для отношений - это создание новых отношений на основе уже сущ. (копирование свойств) + возможность использования программ, написанных для других отношений. Птиц запихнем в одно отношение, а стаусов в другое?