mcureenabНе путайте связи - понятие ER модели с ограничениями ссылочной целостности БД.

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

В объектных БД связи можно прописать в БД, в виде ссылок на объекты.

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

_модmcureenab
В объектных БД связи можно прописать в БД, в виде ссылок на объекты.
В сетевых и иерархических. В РБД никаких связей нет по определению РМД.

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

mcureenab_модmcureenab
В объектных БД связи можно прописать в БД, в виде ссылок на объекты.
В сетевых и иерархических. В РБД никаких связей нет по определению РМД.

Взаимосвязанные объекты в объектной БД образуют сеть и СУБД о ней знает.

Формально, "Р"СУБД тоже знает о "связях по ключам".

_модmcureenabВзаимосвязанные объекты в объектной БД образуют сеть и СУБД о ней знает.
Можно построить ОБД без прямых связей, аналогично РБД. Наличие прямых связей - это сетевая МД. А элементы сети могут быть любыми.

Возможно, лучше бы было сказать не "прямых", а "явных":)
Кроме того, у связей есть семантика. В некотором смысле, получаем "семантическую сеть". А раз появилось слово сеть, то где-то рядом и слово "сетевая":)
Объектные СУБД, конечно, прямые наследники иерархических и сетевых, то есть объектно-ориентированных, в отличие от записеориентированной "Р"СУБД.

AndrewwО боже ! опять семантика

О боже! Так ничему и не научились:)

_модБредФормально, "Р"СУБД тоже знает о "связях по ключам".
Не, не знает (если явно не указать). А вот ОСУБД обязана знать (здесь согласен), т.к. ссылки на объекты явно типизированы.

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

_модБредНо не благодаря ссылкам (это слабая технология), а благодаря явным связям:)
Это понял. Ссылка может содержать физический адрес объекта, но тогда возникают проблемы с перемещением БД. Либо ссылка содержит ИД объекта доступ через индекс - медленнее, но надежней.
Да, примерно так. Только, поскольку связь (то есть, идентификаторы других объектов) не является атрибутом объекта (так же, как и идентификатор не является атрибутом объекта), то связи - это "отдельная конструкция": каждый экземпляр связи - это пара идентификаторов, а точнее две пары для симметричной навигации.

AndrewwБред, О боже! Так ничему и не научились:)

Сколько времени потратил бы орёл впустую, если бы согласился учиться у вороны. (с) Классик.


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

Естественно, с Вами дискутировать не очем в области баз данных, так как Вы не специалист в этой области. Здесь я с Вами полностью согласен:)

_модБредТолько, поскольку связь (то есть, идентификаторы других объектов) не является атрибутом объекта (так же, как и идентификатор не является атрибутом объекта)
Идентификатор действительно не является атрибутом объекта (его нет в описании стр-ры), а ссылка на другой объект (или сам на себя) - это атрибут объекта и присутсвует в описании структуры этого объекта. И так было всегда, даже в первых сетевых СУБД.

Именно это и было существенным недостатком "первых сетевых СУБД":) Идентификаторов не должно быть среди атрибутов, ни "своих", ни "чужих". Это очень логично. И очень симметрично:)

Заде_мод,

Нет ссылки и есть ссылки.
Надо все же почестнее.
Система (Классификационный механизм)
Объект
Объект - собственные свойства
Объект - ссылочные свойства
Объект - отношение {Объект, Объект1, ..., ОбъектN, свойство отношения1,..., свойство отношенияM}
Частный случай идентифицирующего отношения в системе - {Объект, Система, Идентификатор}

Да, Вы здесь честно описали РМД, как ее видел Кодд в ранних отчетах IBM:)
У Вас здесь принципиально нет связей:)

ЗадеСобственно говоря ссылочные свойства только у объектов-отношений

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

_модБред
Именно это и было существенным недостатком "первых сетевых СУБД":) Идентификаторов не должно быть среди атрибутов, ни "своих", ни "чужих". Это очень логично. И очень симметрично:)
Этот "недостаток" сохранился во всех СУБД. Не вижу ни логики, ни симметрии.

Во всех СУБД с недостатками, а не во всех СУБД.
Своего идентификатора нет среди атрибутов. Лоично? Вроде согласились, что логично:)
Чужих идентификаторов тем более не должно быть. Логично? И "симметрично": ни своих, ни чужих.
Странно, почему не видите:)

А вот в присутствии идентификаторов среди атрибутов, действительно, нет ни логики, ни симметрии.

ЗадеБред,

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

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

Объясню почему.

1) Имя человека, например, присваивается ему в результате определенного события. Зарегистрированного в определенном органе:) Таким образом, оно зафиксировано в информационной системе в рамках объекта типа событие.
2) Рост человека, например, измеряется (физически). И также регистрируется в объекте типа событие (измерение роста или, шире, измерение антропологических характеристик человека).
3) И т.д., и т.п. о каждом атрибуте (свойстве, характеристике) объекта Человек.

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

_модБредЧужих идентификаторов тем более не должно быть.
Св-ва объекта м.б.:
строка
число
дата
классификатор (ссылка)
объект (ссылка)
список
И это все присутствует в описании объекта и доступно для манипулирования. Еснно собственный ИД описывать не надо.

Это и есть принципиальная ошибка:) У Вас здесь принципиально нет связей.
Вы сделали полшага. Вы пишете "Естественно":) Почему-то эти полшага для Вас естественны. А другие полшага "не естественны".

"Классификатор (ссылка)" и "Объект (ссылка)" - это фундаментальные ошибки (я уж не говорю о том, что классификатор - это объект):)

old__man__БредЧужих идентификаторов тем более не должно быть. Логично? И "симметрично": ни своих, ни чужих.

А вот в присутствии идентификаторов среди атрибутов, действительно, нет ни логики, ни симметрии.

Не вполне логично.

Предположим, мы хотим ввести тип "Сумма", который состоит из двух полей -
"Количество" - десятичное и
"Валюта" - ссылка на справочник валют

Если у ссылка может быть атрибутом, то дальше мы можем просто добавить атрибут типа "Сумма"
в договор для полей "Сумма номинальная" и "Сумма с дисконтом".

А если атрибуты отдельно, ссылки отдельно, то как быть?

Как обычно:

Договор - имеет(М:1)/относится к(1:М) - Валюта
Сумм (атрибутов объекта Договор) может быть сколько угодно.

Здесь фундаментальный спор идет, насколько я понимаю:) Вряд ли его стоит решать на уровне проектирования БД для частных задач:)

Задеold__man__,

ну у объекта есть ссылка на объекты Сумма, Сумма с дисконтом...

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

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

В Ваших рассуждениях я бы обратил внимание на частично затронутый принципиальный аспект: Дейт считает, что аналогом класса ООП в РМД является домен, а не отношение:)

Заде_модБредЧужих идентификаторов тем более не должно быть.
Св-ва объекта м.б.:
строка
число
дата
классификатор (ссылка)
объект (ссылка)
список
И это все присутствует в описании объекта и доступно для манипулирования. Еснно собственный ИД описывать не надо.

Если не создавать отношения - {объект, отношение}, {отношение, отношение}, то вышеперечисленное отлично работает и прекрасно визуализируется автоматом. Иначе возникает проблема с лукапом отношений. Приходится либо показывать малоинформативное составное имя, либо пойти на денормализацию :( не смог я этот вопрос красиво решить :(

Вышеперечисленное мало чем отличается от РМД, и работает только для программиста:) А Кодд мечтал, что это будет работать для пользователей. Но не получилось:)

_модЗаде
Если не создавать отношения - {объект, отношение}, {отношение, отношение}, то вышеперечисленное отлично работает и прекрасно визуализируется автоматом.
Об том и речь - все просто и красиво

:)

ЗадеБред
Как раз полная ясность:) Если Вы прислушаетесь к тому о чем я здесь говорю. Несколько лет:)
Идентификатор не является атрибутом (свойством, характеристикой) объекта. Он просто отражает в информационной системе факт существования объекта, не зависимо от значений его атрибутов. Более того, в идеале у объекта вообще не должно быть ни одного атрибута (свойства, характеристики) в тщательно нормализованной БД, в которой отражен весь реальный мир:)


Тут то как раз никто не спорит. Объект существует в системе и только.
Но при тщательном анализе этого факта вырисовываются два подхода.
1. Объект ассоциируется с системным идентификатором(создаем идентификатор и вес жизненный цикл объекта присобачиваем к этому идентификатору). Это для внешних для системы объектов-прищелцев
2. Но есть внутреннние, родные для системы объекты. Допустим два объекта приписанных в системе вошли в отношение и получили свойства отношения. В таком случае этот объект-отношение можно однозначно идентифицировать порядком и идентификаторами вошедших в отношение объектов. Что вносит неоднозначность в систему идентификации. Но, этим самым мы добиваемся запрета создания отношений высшего порядка, а это, кажется, очень важно. (я выше говорил про формальную агрегацию понятий).

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

Этот подход привел к тому, что люди отделены от информации "железобетонной" стеной в виде (SQL)программистов и их кодов:)

На самом деле, результатом любого "запроса" является подсхема схемы БД СО ВСЕЙ ПРИСУЩЕЙ ЕЙ СЕМАНТИКОЙ. Для любителей алгебры не представляет никакого труда реализовать в объектной среде "технологию", подобную SQL для "произвольного связывания объектов" вне определенных связей (то есть, вне идентификаторов). Связывайте на здоровье, якобы для извлечения не познанных закономерностей:) И открытия новых законов природы:)

Вот пункт два меня мучает. Я даю возможность создавать отношения высших порядков Отношение{Отношение1,Отношение2,...}. Но скоко бы не думал, выше третьего порядка ничего осмысленного получить не могу, хотя формально строится пирамида понятий. :(
А если я убираю системный суррогатный идентификатор для отношения, то все семантичски возвращается в норму, но появляются проблема уточнение имен денормализованных свойств и предложения ставноятся все длинее и длинее :

ЗадеБред
В Ваших рассуждениях я бы обратил внимание на частично затронутый принципиальный аспект: Дейт считает, что аналогом класса ООП в РМД является домен, а не отношение:)

Дейт в таком случае противовоставляет домен и отношение. Отношение может быть базовым множеством для домена.
Класс - шалон, трафарет, описание структуры, методов и событий домена.

Дейт ничего не противопоставляет, а объясняет, таким образом, пути "оптимальной интеграции" объектных технологий (в смысле ООП) и РМД.

ЗадеБред
Как раз полная ясность:) Если Вы прислушаетесь к тому о чем я здесь говорю. Несколько лет:)
Идентификатор не является атрибутом (свойством, характеристикой) объекта. Он просто отражает в информационной системе факт существования объекта, не зависимо от значений его атрибутов. Более того, в идеале у объекта вообще не должно быть ни одного атрибута (свойства, характеристики) в тщательно нормализованной БД, в которой отражен весь реальный мир:)


Тут то как раз никто не спорит. Объект существует в системе и только.
Но при тщательном анализе этого факта вырисовываются два подхода.
1. Объект ассоциируется с системным идентификатором(создаем идентификатор и вес жизненный цикл объекта присобачиваем к этому идентификатору). Это для внешних для системы объектов-прищелцев
2. Но есть внутреннние, родные для системы объекты. Допустим два объекта приписанных в системе вошли в отношение и получили свойства отношения. В таком случае этот объект-отношение можно однозначно идентифицировать порядком и идентификаторами вошедших в отношение объектов. Что вносит неоднозначность в систему идентификации. Но, этим самым мы добиваемся запрета создания отношений высшего порядка, а это, кажется, очень важно. (я выше говорил про формальную агрегацию понятий).

Вот пункт два меня мучает. Я даю возможность создавать отношения высших порядков Отношение{Отношение1,Отношение2,...}. Но скоко бы не думал, выше третьего порядка ничего осмысленного получить не могу, хотя формально строится пирамида понятий. :(
А если я убираю системный суррогатный идентификатор для отношения, то все семантичски возвращается в норму, но появляются проблема уточнение имен денормализованных свойств и предложения ставноятся все длинее и длинее :

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

Этот подход привел к тому, что люди отделены от информации "железобетонной" стеной в виде (SQL)программистов и их кодов:)

На самом деле, результатом любого "запроса" является подсхема схемы БД СО ВСЕЙ ПРИСУЩЕЙ ЕЙ СЕМАНТИКОЙ. Для любителей алгебры не представляет никакого труда реализовать в объектной среде "технологию", подобную SQL для "произвольного связывания объектов" вне определенных связей (то есть, вне идентификаторов). Связывайте на здоровье, якобы для извлечения не познанных закономерностей:) И открытия новых законов природы:)

ЗадеБред,

честно гворя мне пофиг кодд, дейт и их рмд, ооп и т.д.
СКЛ сервер я использую токо из за того, что никто не покупает проги для корпоратвного уровня, которые не базируются на скл серверах. Тенденции таковы.
вот и приходится на ск серверах моделировать свои фиговины.
А про то что задавая "семантику"в какой нить хранимой процедуре можно получить что угодно я давно знаю.
select "человек" as оборотень from ишак where "пофиг"="пофиг"

:) мне не пофиг, конечно... и именно поэтому я и работаю над тем, чтобы люди не покупали "проги для корпоративного уровня, которые базируются на скл серверах"... и их уже давно многие не покупают:) Однако см. мое примечание о том, что никто не мешает .... и т.д.

_модБред- из-за отсутствия регистрации упомянутых событий в нашей прикладной системе.
из-за отсутствия необходимости регистрации упомянутых событий в нашей прикладной системе.

Можно и так. Результат тот же:)