|
Зачем нужны связи?
|
|||
---|---|---|---|
#18+
_модБредТолько, поскольку связь (то есть, идентификаторы других объектов) не является атрибутом объекта (так же, как и идентификатор не является атрибутом объекта) Идентификатор действительно не является атрибутом объекта (его нет в описании стр-ры), а ссылка на другой объект (или сам на себя) - это атрибут объекта и присутсвует в описании структуры этого объекта. И так было всегда, даже в первых сетевых СУБД. Именно это и было существенным недостатком "первых сетевых СУБД":) Идентификаторов не должно быть среди атрибутов, ни "своих", ни "чужих". Это очень логично. И очень симметрично:) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2010, 15:26 |
|
Зачем нужны связи?
|
|||
---|---|---|---|
#18+
Заде_мод, Нет ссылки и есть ссылки. Надо все же почестнее. Система (Классификационный механизм) Объект Объект - собственные свойства Объект - ссылочные свойства Объект - отношение {Объект, Объект1, ..., ОбъектN, свойство отношения1,..., свойство отношенияM} Частный случай идентифицирующего отношения в системе - {Объект, Система, Идентификатор} Да, Вы здесь честно описали РМД, как ее видел Кодд в ранних отчетах IBM:) У Вас здесь принципиально нет связей:) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2010, 15:28 |
|
Зачем нужны связи?
|
|||
---|---|---|---|
#18+
ЗадеСобственно говоря ссылочные свойства только у объектов-отношений Путаетесь немного:) Но в целом так: у отношений (РМД) типа "сущность" - только первичный ключ; у отношений типа "связь" - помимо первичного ключа, два или более внешних ключей... Гиблый подход:) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2010, 15:32 |
|
Зачем нужны связи?
|
|||
---|---|---|---|
#18+
ЗадеНадо все же почестнее. Система (Классификационный механизм) Объект Объект - собственные свойства Объект - ссылочные свойства Объект - отношение {Объект, Объект1, ..., ОбъектN, свойство отношения1,..., свойство отношенияM} Частный случай идентифицирующего отношения в системе - {Объект, Система, Идентификатор} ссылочные свойства =собственные свойства пример: число 5 можно считать ссылкой на множество целых чисел Объект - отношение ничем не отличается от любого другого пример: счет-фактура "связывет" поставщиков и товары ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2010, 17:16 |
|
Зачем нужны связи?
|
|||
---|---|---|---|
#18+
Бред Именно это и было существенным недостатком "первых сетевых СУБД":) Идентификаторов не должно быть среди атрибутов, ни "своих", ни "чужих". Это очень логично. И очень симметрично:) Этот "недостаток" сохранился во всех СУБД. Не вижу ни логики, ни симметрии. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2010, 17:19 |
|
Зачем нужны связи?
|
|||
---|---|---|---|
#18+
_модБред Именно это и было существенным недостатком "первых сетевых СУБД":) Идентификаторов не должно быть среди атрибутов, ни "своих", ни "чужих". Это очень логично. И очень симметрично:) Этот "недостаток" сохранился во всех СУБД. Не вижу ни логики, ни симметрии. Во всех СУБД с недостатками, а не во всех СУБД. Своего идентификатора нет среди атрибутов. Лоично? Вроде согласились, что логично:) Чужих идентификаторов тем более не должно быть. Логично? И "симметрично": ни своих, ни чужих. Странно, почему не видите:) А вот в присутствии идентификаторов среди атрибутов, действительно, нет ни логики, ни симметрии. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2010, 19:45 |
|
Зачем нужны связи?
|
|||
---|---|---|---|
#18+
Бред, ну да путано получилось (зато быстро :)) _мод у меня путаница именно в понимании отношений между объектами (тут вроде ничего), отношением и объектом (тут уже похуже), отношением и отношением, отношением отношений и отношением отношений каюк).... конечно понятно что эти отношения тоже объекты, но они какие-то особенные, "несамодостаточные" только в отношениях-объектах появляются ссылочные свойства, а "самодостаточные" ни на кого не ссылаются (если не взять в расчет предопределенные системные базовые множества объектов) в отношении-объекте совокупность объектов получают присущие только совокупности свойства, а сам отношение-объект практически никода не имеет человекоинтерпретируемое свойство "Наименование" они сильно зависимы, их жизненный цикл определяется жизненным циклом любого из объектов входящих в отношение или надо ввести тот же null, setnull, что как то пахнет гнильцой :( а как только начинается отношение отношений и дальше(высшие ступени отношений), так воще человеческая интерпретация начинает хромать не только по части идентификации :( ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2010, 02:42 |
|
Зачем нужны связи?
|
|||
---|---|---|---|
#18+
Бред, Идентификатор тоже особо интересная фиговина вроде бы он часть идентифицирующей системы объект вроде бы может жить и без этой нафиг ему не нужной фигни тут вопрос, а как обратиться к объекту не имеющего идентификатора? вот "_мод" не свойство человека с которым я разговариваю, но без этого идентификатора я бы обратился в пустоту просто наверное затаскали слово "свойство" и "объект", надо так и оставить "системный идентификатор объекта", не "свойство", а "системное свойство объекта", не "ссылочное свойство" , а "объект участвующий в системном отношении", не называть всю фигню объектом... вощем полная фигня :( ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2010, 02:56 |
|
Зачем нужны связи?
|
|||
---|---|---|---|
#18+
Такое ощущение, что знание ограничено сверху и снизу синтез и анализ конечны бесконечность только в плоском мире, ну типа толщина мира ограничено чем то ни пил нифига и не только про свои знания речь :( ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2010, 03:07 |
|
Зачем нужны связи?
|
|||
---|---|---|---|
#18+
БредЧужих идентификаторов тем более не должно быть. Св-ва объекта м.б.: строка число дата классификатор (ссылка) объект (ссылка) список И это все присутствует в описании объекта и доступно для манипулирования. Еснно собственный ИД описывать не надо. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2010, 09:13 |
|
Зачем нужны связи?
|
|||
---|---|---|---|
#18+
Заде конечно понятно что эти отношения тоже объекты, но они какие-то особенные, "несамодостаточные" В DBOMP было два типа таблиц - основные и связующие. Но когда стали очевидными ограничения такой модели, то перешли к однородным графам. На самом деле ничего страшного здесь нет, просто некоторые ограничения чисто организационного характера - ну нельзя ввести договор на не существующего поставщика. Зато гораздо удобнее все считать просто объектами, пусть и зависимыми друг от друга. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2010, 09:20 |
|
Зачем нужны связи?
|
|||
---|---|---|---|
#18+
БредЧужих идентификаторов тем более не должно быть. Логично? И "симметрично": ни своих, ни чужих. А вот в присутствии идентификаторов среди атрибутов, действительно, нет ни логики, ни симметрии. Не вполне логично. Предположим, мы хотим ввести тип "Сумма", который состоит из двух полей - "Количество" - десятичное и "Валюта" - ссылка на справочник валют Если у ссылка может быть атрибутом, то дальше мы можем просто добавить атрибут типа "Сумма" в договор для полей "Сумма номинальная" и "Сумма с дисконтом". А если атрибуты отдельно, ссылки отдельно, то как быть? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2010, 10:15 |
|
Зачем нужны связи?
|
|||
---|---|---|---|
#18+
old__man__, ну у объекта есть ссылка на объекты Сумма, Сумма с дисконтом... плохо то что спокойно можно удалить эту ссылку у объекта и если этот объект является объектом-отношением, то его семантика отношения становится ущербным Вообще тема меры почти не затронута ведь любое свойство даже те , которые мы считаем примитивными, типа цвет, количество, весь... являются измеримыми в каких-то других объектах, т.е. являются классами и иногда сложными взимоотношениями ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2010, 12:50 |
|
Зачем нужны связи?
|
|||
---|---|---|---|
#18+
_модБредЧужих идентификаторов тем более не должно быть. Св-ва объекта м.б.: строка число дата классификатор (ссылка) объект (ссылка) список И это все присутствует в описании объекта и доступно для манипулирования. Еснно собственный ИД описывать не надо. Если не создавать отношения - {объект, отношение}, {отношение, отношение}, то вышеперечисленное отлично работает и прекрасно визуализируется автоматом. Иначе возникает проблема с лукапом отношений. Приходится либо показывать малоинформативное составное имя, либо пойти на денормализацию :( не смог я этот вопрос красиво решить :( ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2010, 12:56 |
|
Зачем нужны связи?
|
|||
---|---|---|---|
#18+
Заде Если не создавать отношения - {объект, отношение}, {отношение, отношение}, то вышеперечисленное отлично работает и прекрасно визуализируется автоматом. Об том и речь - все просто и красиво ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2010, 14:18 |
|
Зачем нужны связи?
|
|||
---|---|---|---|
#18+
_мод, есть большое искушение сотворить типа такой вещи Специалист{Специальность, Квалификация, Компетенция} Работник{...,Специалист} Потом я беру и назначаю Процесс нормативный{Процессор{Специалист}} а при планировании актуализированного Просесса, я по значению объекта Специалист вычисляюю объект Работник. Но если сделать Работник{...,Специальность, Квалификация, Компетенция}, то приходится сделать Процесс нормативный{Процессор{Работник (where Специальность = @1, Квалификация=@2, Компетенция=*)}} т.е. приходится дать ссылку на ТИП и свойства типа, что являются Метаданными, а мне не хотся открывать метаданные платформы в прикладной системе ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2010, 15:01 |
|
Зачем нужны связи?
|
|||
---|---|---|---|
#18+
ЗадеСпециалист{Специальность, Квалификация, Компетенция} Работник{...,Специалист} Потом я беру и назначаю Процесс нормативный{Процессор{Специалист}} а при планировании актуализированного Просесса, я по значению объекта Специалист вычисляюю объект Работник. Так правильно ( вычислится несколько возможных Работников) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2010, 15:58 |
|
Зачем нужны связи?
|
|||
---|---|---|---|
#18+
ЗадеБред, Идентификатор тоже особо интересная фиговина вроде бы он часть идентифицирующей системы объект вроде бы может жить и без этой нафиг ему не нужной фигни тут вопрос, а как обратиться к объекту не имеющего идентификатора? вот "_мод" не свойство человека с которым я разговариваю, но без этого идентификатора я бы обратился в пустоту просто наверное затаскали слово "свойство" и "объект", надо так и оставить "системный идентификатор объекта", не "свойство", а "системное свойство объекта", не "ссылочное свойство" , а "объект участвующий в системном отношении", не называть всю фигню объектом... вощем полная фигня :( Как раз полная ясность:) Если Вы прислушаетесь к тому о чем я здесь говорю. Несколько лет:) Идентификатор не является атрибутом (свойством, характеристикой) объекта. Он просто отражает в информационной системе факт существования объекта, не зависимо от значений его атрибутов. Более того, в идеале у объекта вообще не должно быть ни одного атрибута (свойства, характеристики) в тщательно нормализованной БД, в которой отражен весь реальный мир:) Объясню почему. 1) Имя человека, например, присваивается ему в результате определенного события. Зарегистрированного в определенном органе:) Таким образом, оно зафиксировано в информационной системе в рамках объекта типа событие. 2) Рост человека, например, измеряется (физически). И также регистрируется в объекте типа событие (измерение роста или, шире, измерение антропологических характеристик человека). 3) И т.д., и т.п. о каждом атрибуте (свойстве, характеристике) объекта Человек. Мы, тем не менее, размещаем, обычно эти атрибуты непосредственно в объекте Человек (то есть, осуществляем банальную денормализацию) по двум причинам: - для повышения производительности определенных операций (для чего, обычно, и делается денормализация); - из-за отсутствия регистрации упомянутых событий в нашей прикладной системе. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2010, 17:20 |
|
Зачем нужны связи?
|
|||
---|---|---|---|
#18+
_модБредЧужих идентификаторов тем более не должно быть. Св-ва объекта м.б.: строка число дата классификатор (ссылка) объект (ссылка) список И это все присутствует в описании объекта и доступно для манипулирования. Еснно собственный ИД описывать не надо. Это и есть принципиальная ошибка:) У Вас здесь принципиально нет связей. Вы сделали полшага. Вы пишете "Естественно":) Почему-то эти полшага для Вас естественны. А другие полшага "не естественны". "Классификатор (ссылка)" и "Объект (ссылка)" - это фундаментальные ошибки (я уж не говорю о том, что классификатор - это объект):) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2010, 17:24 |
|
Зачем нужны связи?
|
|||
---|---|---|---|
#18+
old__man__БредЧужих идентификаторов тем более не должно быть. Логично? И "симметрично": ни своих, ни чужих. А вот в присутствии идентификаторов среди атрибутов, действительно, нет ни логики, ни симметрии. Не вполне логично. Предположим, мы хотим ввести тип "Сумма", который состоит из двух полей - "Количество" - десятичное и "Валюта" - ссылка на справочник валют Если у ссылка может быть атрибутом, то дальше мы можем просто добавить атрибут типа "Сумма" в договор для полей "Сумма номинальная" и "Сумма с дисконтом". А если атрибуты отдельно, ссылки отдельно, то как быть? Как обычно: Договор - имеет(М:1)/относится к(1:М) - Валюта Сумм (атрибутов объекта Договор) может быть сколько угодно. Здесь фундаментальный спор идет, насколько я понимаю:) Вряд ли его стоит решать на уровне проектирования БД для частных задач:) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2010, 17:33 |
|
Зачем нужны связи?
|
|||
---|---|---|---|
#18+
Задеold__man__, ну у объекта есть ссылка на объекты Сумма, Сумма с дисконтом... плохо то что спокойно можно удалить эту ссылку у объекта и если этот объект является объектом-отношением, то его семантика отношения становится ущербным Вообще тема меры почти не затронута ведь любое свойство даже те , которые мы считаем примитивными, типа цвет, количество, весь... являются измеримыми в каких-то других объектах, т.е. являются классами и иногда сложными взимоотношениями В Ваших рассуждениях я бы обратил внимание на частично затронутый принципиальный аспект: Дейт считает, что аналогом класса ООП в РМД является домен, а не отношение:) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2010, 17:35 |
|
Зачем нужны связи?
|
|||
---|---|---|---|
#18+
Заде_модБредЧужих идентификаторов тем более не должно быть. Св-ва объекта м.б.: строка число дата классификатор (ссылка) объект (ссылка) список И это все присутствует в описании объекта и доступно для манипулирования. Еснно собственный ИД описывать не надо. Если не создавать отношения - {объект, отношение}, {отношение, отношение}, то вышеперечисленное отлично работает и прекрасно визуализируется автоматом. Иначе возникает проблема с лукапом отношений. Приходится либо показывать малоинформативное составное имя, либо пойти на денормализацию :( не смог я этот вопрос красиво решить :( Вышеперечисленное мало чем отличается от РМД, и работает только для программиста:) А Кодд мечтал, что это будет работать для пользователей. Но не получилось:) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2010, 17:38 |
|
Зачем нужны связи?
|
|||
---|---|---|---|
#18+
_модЗаде Если не создавать отношения - {объект, отношение}, {отношение, отношение}, то вышеперечисленное отлично работает и прекрасно визуализируется автоматом. Об том и речь - все просто и красиво :) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2010, 17:39 |
|
Зачем нужны связи?
|
|||
---|---|---|---|
#18+
Бред Как раз полная ясность:) Если Вы прислушаетесь к тому о чем я здесь говорю. Несколько лет:) Идентификатор не является атрибутом (свойством, характеристикой) объекта. Он просто отражает в информационной системе факт существования объекта, не зависимо от значений его атрибутов. Более того, в идеале у объекта вообще не должно быть ни одного атрибута (свойства, характеристики) в тщательно нормализованной БД, в которой отражен весь реальный мир:) Тут то как раз никто не спорит. Объект существует в системе и только. Но при тщательном анализе этого факта вырисовываются два подхода. 1. Объект ассоциируется с системным идентификатором(создаем идентификатор и вес жизненный цикл объекта присобачиваем к этому идентификатору). Это для внешних для системы объектов-прищелцев 2. Но есть внутреннние, родные для системы объекты. Допустим два объекта приписанных в системе вошли в отношение и получили свойства отношения. В таком случае этот объект-отношение можно однозначно идентифицировать порядком и идентификаторами вошедших в отношение объектов. Что вносит неоднозначность в систему идентификации. Но, этим самым мы добиваемся запрета создания отношений высшего порядка, а это, кажется, очень важно. (я выше говорил про формальную агрегацию понятий). Вот пункт два меня мучает. Я даю возможность создавать отношения высших порядков Отношение{Отношение1,Отношение2,...}. Но скоко бы не думал, выше третьего порядка ничего осмысленного получить не могу, хотя формально строится пирамида понятий. :( А если я убираю системный суррогатный идентификатор для отношения, то все семантичски возвращается в норму, но появляются проблема уточнение имен денормализованных свойств и предложения ставноятся все длинее и длинее : ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2010, 17:56 |
|
Зачем нужны связи?
|
|||
---|---|---|---|
#18+
Бред В Ваших рассуждениях я бы обратил внимание на частично затронутый принципиальный аспект: Дейт считает, что аналогом класса ООП в РМД является домен, а не отношение:) Дейт в таком случае противовоставляет домен и отношение. Отношение может быть базовым множеством для домена. Класс - шалон, трафарет, описание структуры, методов и событий домена. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2010, 18:02 |
|
|
start [/forum/topic.php?fid=32&msg=36529860&tid=1540105]: |
0ms |
get settings: |
7ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
166ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
1ms |
others: | 244ms |
total: | 518ms |
0 / 0 |