|
|
|
О типах связей в сетевой модели данных.
|
|||
|---|---|---|---|
|
#18+
Александр СавиновСсылку можно понимать как роль, которую играют данные. Т.е. есть парни, которые ввели понятие ссылка - адрес объекта и все. А мы бум брать их понятия, но приписывать им свое содержание. Зачем? Чтобы все запутать окончательно, и мы их не понимали, а они нас? А придумать свое понятие, дать ему имя и подождать када оно станет популярным, слабо? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2006, 12:51 |
|
||
|
О типах связей в сетевой модели данных.
|
|||
|---|---|---|---|
|
#18+
vadiminfo Александр СавиновСсылку можно понимать как роль, которую играют данные. Т.е. есть парни, которые ввели понятие ссылка - адрес объекта и все. А мы бум брать их понятия, но приписывать им свое содержание. Понятие это и есть содержание, т.е. если есть новое содержание, то есть новое понятие. Те парни тоже взяли существующие термины, например, адрес и наполнили его своим содержанием. Ничего свыше не дано. vadiminfoЗачем? За тем же, зачем создавались РМД, ООП и все остальные вещи, которые не были даны нам свыше. vadiminfoЧтобы все запутать окончательно, и мы их не понимали, а они нас? А придумать свое понятие, дать ему имя и подождать када оно станет популярным, слабо?Это не ко мне вопрос. Я не знаю зачем люди создают что-то новое и путают тех, кто привык к старому. Единственное, что я могу посоветовать, не интересоваться ничем новым (переключить канал) и работать в старой системе понятий, и тогда все вопросы отпадут сами собой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2006, 18:30 |
|
||
|
О типах связей в сетевой модели данных.
|
|||
|---|---|---|---|
|
#18+
ModelRПро отделение ссылок от данных. Собственно у меня ощущение что отделить можно любые проиндексированные данные, не только адреса. Посторим индекс по account.balance и на фига его хранить собственно в account?Согласен. Если говорить просто об отделении, то да. Я уже как-то упоминал, что есть весьма интересная концепция "БД как индекс", в которой собственно вся информация хранится в индексах, а таблиц нет. Но в том, что я делаю, нет цели просто вынести информацию из объекта. Цель в другом: разработать систему опосредованного доступа к объектам по ссылкам. В частности, ести такие требования как возможность создавать (моделировать) собственные ссылки с процедурой доступа, иерархичность ссылок, прозрачность доступа и др. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2006, 18:39 |
|
||
|
О типах связей в сетевой модели данных.
|
|||
|---|---|---|---|
|
#18+
ModelRОтделение перекликается с так называемой 6НФ. Если мы проиндексируем каждое поле, а затем прибьем собственно таблицу оставив индексы то получим 6НФ декомпозицию.Тут еще другой момент. Если что-то хранится в таблице, то это доступно всем, т.е. это объект. Если мы переместим эти данные в индекс, то ничего не изменится, поскольку есть один индекс с одним экземпляром этих данных. Любые изменения видны всем. Если же мы поместим поле в ссылку, то существует множество экземпляров ссылки и каждая будет иметь это поле. Ссылки передаются по значению, а объекты передаются ссылки. Если поле balance будет в ссылке и я его изменю, то эти изменения останутся только в данной ссылке и никто другой это не увидит (если я не передам ему эту ссылку). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2006, 18:44 |
|
||
|
О типах связей в сетевой модели данных.
|
|||
|---|---|---|---|
|
#18+
!з.ы. Запутали окончательно.Я тоже не очень понимаю Ваших вопросов, поэтому не могу коротко ответить. Наверное, на этом надо остановиться, поскольку дальше еще больше деталей будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2006, 18:48 |
|
||
|
О типах связей в сетевой модели данных.
|
|||
|---|---|---|---|
|
#18+
Александр Савинов Это не ко мне вопрос. Я не знаю зачем люди создают что-то новое и путают тех, кто привык к старому. Единственное, что я могу посоветовать, не интересоваться ничем новым (переключить канал) и работать в старой системе понятий, и тогда все вопросы отпадут сами собой. Создание чегото нового должно идти в ногу с реализацией и практическим применением этого нового. Наука без практического использования мертва. (С) не помню кто сказал. Александр Савинов !з.ы. Запутали окончательно.Я тоже не очень понимаю Ваших вопросов, поэтому не могу коротко ответить. Наверное, на этом надо остановиться, поскольку дальше еще больше деталей будет. ИМХО Вы ту понастроили воздушных замков, а теперь не понимаете как из этого извлечь практическую пользу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2006, 20:08 |
|
||
|
О типах связей в сетевой модели данных.
|
|||
|---|---|---|---|
|
#18+
ModelR тоже взял на вооружение местный способ обведения в прямоугольнички "нужных предложений" из контекста, и на "не программируются", конечно, внимания не обратил. "Связи" являются элементом модели, "!", как и "объекты". А в РМД оба этих элемента представлены одним элементом - отношением. Кодд старался разделить, но не получилось с алгеброй. Решил, что алгебра важнее идентификации, навигации и семантики данных. А вот "ключи" - их можно назвать "способом реализации" связей между сущностями (многие здесь третий год трепятся про "ОЦ", не удосужившись почитать даже Кодда и Дейта). Для этого они и введены в РМД. Нет, мод. "Договор" не имеет свойства "Поставщик", как и "Поставщик" не имеет свойства "Договор". Ваш "подход" безнадежно устарел. "Коренное различие", 4321, между "ключами" и "сцылками" заключается в том, что "сцылка" - это отдельный тип, и "сцылается" на идентификатор, не являющийся просто одной из характеристик объекта, а "ключ" - это атрибут (с ранее определенным типом), и "сцылается" на один из атрибутов отношения. И то, и другое, тем не менее, плохо, хотя "сцылка" намного мощнее "ключа". Господа, "Вы не понимаете РМД (научно доказанный факт)". Лучше глюка не скажешь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2006, 20:58 |
|
||
|
О типах связей в сетевой модели данных.
|
|||
|---|---|---|---|
|
#18+
Александр Савинов vadiminfo Александр СавиновСсылку можно понимать как роль, которую играют данные. Т.е. есть парни, которые ввели понятие ссылка - адрес объекта и все. А мы бум брать их понятия, но приписывать им свое содержание. Понятие это и есть содержание, т.е. если есть новое содержание, то есть новое понятие. Те парни тоже взяли существующие термины, например, адрес и наполнили его своим содержанием. Ничего свыше не дано. Вот я говорю Вам, что "роль, которую играют данные" - это новое содержание, которые Вы пытаетесь втюхать в старое понятие "ссылка". Типа у Вас якобы новое понятие, а имя старое - "ссылка". Дайте новное имя - "Роль данных", например. Александр СавиновЗа тем же, зачем создавались РМД, ООП и все остальные вещи, которые не были даны нам свыше. Вообще-то там нет подмены старых понятий, новыми, но со старыми именами. Т.е. пример не удачный. Александр СавиновЭто не ко мне вопрос. Я не знаю зачем люди создают что-то новое и путают тех, кто привык к старому. Единственное, что я могу посоветовать, не интересоваться ничем новым (переключить канал) и работать в старой системе понятий, и тогда все вопросы отпадут сами собой. Это именно к Вам. Речь не о старой системе понятий. А подмене понятий. Я же предлагаю Вам дать новые имена Вашему содержанию, вместо того что бы втюхивать его насильно в старую систему. Новое изучать стоит, если оно стоящее. Так Вы претендуете на новое? Я думал Вы в процессе изучения старого, и здесь просто тестируете как усвоили материал. Т.е. это не новое, а старое, но как Вы его себе представляете. ООП, к примеру, уже достаточно старое. Сыллки и Данные еще старше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2006, 16:34 |
|
||
|
О типах связей в сетевой модели данных.
|
|||
|---|---|---|---|
|
#18+
ЙАмД : Yet Another Data Model Теория: все данные могут быть представлены множеством кортежей <X,P,Y>, для предиката "Объект X имеет значение Y свойства P"; X, Y - кортежи вида <тип, oid> Такое множество далее будет именоваться U-множество. определение U-функция - функция, значением которой является U-множество определение U-алгебра: операции объединения, пересечения, разности множеств, фильтрации и раскрытия значений свойства Операция фильтрации R[ a(r) ] = { r | r є R AND a(r) = true }, r - элемент множества Операция раскрытия значений свойства "R->n->T": R->n->T = { t є T | EXISTS r є R : r.p = n AND t.X = r.Y } определение U-база данных задается U-переменной (THE_U), функцией проверки (ASSERT) и функцией коррекции (FIX). определение U-переменная - переменная, значение которой U-множество. определение Для переменной THE_U определен оператор U-присваивания, который изменяет значение на новое через функцию допустимости: THE_U := ENSURE(Un) , где Un - новое значение U-переменной, ENSURE - U-функция допустимости. определение ENSURE - U-функция допустимости - определяется след. образом: ENSURE(Un) = IF ASSERT(Un) THEN Un ELSE ENSURE(FIX(Un)) определение функция проверки ASSERT(Un) - логическая функция над U-множеством определение функция коррекции FIX(Un) - U-функция над U-множеством ----------------------- можно ли вышеизложенное (с некоторыми натяжками) считать моделью данных ? P.S. просьба практичность не обсуждать, за отсутствием таковой, а равно и уточнений не просить (по той же причине) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2006, 03:11 |
|
||
|
О типах связей в сетевой модели данных.
|
|||
|---|---|---|---|
|
#18+
ПсклонModelR тоже взял на вооружение местный способ обведения в прямоугольнички "нужных предложений" из контекста, и Вам весьма советую, а то где и главное зачем искать Псклони на "не программируются", конечно, внимания не обратил. - загадка. И кто ж их будет разгадывать? Псклон"Связи" являются элементом модели, "!", как и "объекты". ., как и индентификаторы. Это понятно давно, только имя модели неплохо бы называть. ПсклонА вот "ключи" - их можно назвать "способом реализации" связей между сущностями (многие здесь третий год трепятся про "ОЦ", не удосужившись почитать даже Кодда и Дейта). Для этого они и введены в РМД.ну, последний раз. Нет, лишь при некоторых условиях (по крайней мере, сущность = отношение) внешние ключи можно рассматривать как реализацию некоей части понятия связь. А именно той части, что в системе должна существовать дополнительная информация про связанный объект. Собственна связь выражается именно отношением или его проекцией. Например кортеж <USD, EUR, 1.34> прекрасно связывет две валюты без относительно того, есть ли в системе справочник валют, а если есть, то кто и как проверяет согласованность данной связи с этим справочником. Система обязана учитывать внешние ключи только при обновлении данных и абсолютно не обязана как-то учитывать ВК в запросах. Запрос волен связать что и с кем угодно. Конечно, никому не возбраняется построить навигатор по ВК, равно как и сумматор, буде это полезно в приложении. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2006, 11:08 |
|
||
|
О типах связей в сетевой модели данных.
|
|||
|---|---|---|---|
|
#18+
Псклон"Коренное различие", 4321, между "ключами" и "сцылками" заключается в том, что "сцылка" - это отдельный тип, и "сцылается" на идентификатор, не являющийся просто одной из характеристик объекта, а "ключ" - это атрибут каво атрибут, зачэм атрибут... Э? дарагой, скажи, какой он отдэльный, эжли он этаго жэ сущноста идэнтификакатор, а? он такой жэ отделный, как и любое поле. кто сказал, что они физицки обязательно в одной записи напиписаны? - говорять какой-то сайбез не позаписно храницца, а по-атрибутно. И ничего эрсубеда-эрсубедой Псклон, и "сцылается" на один из атрибутов отношения. ишто? исчо раз - разница токо в публикуемости (ежли заложена неизменность "значения" сцылки). Ежли не заложена - тады да, есь разница. Но не существенная, а в реализации. ПсклонИ то, и другое, тем не менее, плохо, хотя "сцылка" намного мощнее "ключа".гыгыгы - если мы не публикуем нечто - дык с чего воно мощнее? С того, шо попряталось? а по существу есть мысли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2006, 11:34 |
|
||
|
О типах связей в сетевой модели данных.
|
|||
|---|---|---|---|
|
#18+
Псклон+ ни семантики.про ключи/идентификацию ИМХО тема всех уже достала, идем по кругу, так что ставим точку, пока новых мыслей не появится. А про семантику - плз. В идеале - чем измерить количество семантики? по минимуму - как отличить семантику от не семантики? все контексте СУБД конечно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2006, 10:25 |
|
||
|
О типах связей в сетевой модели данных.
|
|||
|---|---|---|---|
|
#18+
Опа... Пока отвечал, исчез исходный пост Псклон+ . Интересно, это идентификация или семантика виноваты:( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2006, 11:12 |
|
||
|
О типах связей в сетевой модели данных.
|
|||
|---|---|---|---|
|
#18+
ModelRОпа... Пока отвечал, исчез исходный пост Псклон+ . Интересно, это идентификация или семантика виноваты:( Если сюда ЧАЛа пустить очередной топик загажен будет. Причем не столько им самим, сколько отвечающими. Давайте хоть тут чистоту соблюдём. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2006, 15:41 |
|
||
|
О типах связей в сетевой модели данных.
|
|||
|---|---|---|---|
|
#18+
<attr_name>=<attr_value> , <attr_name>=<attr_value> , и так далее --- похоже на 'точечную нотацию' Александра Савинова? Мне кажется, что похоже. Даже более продумано. Например - cn=My Name,ou=people,dc=mycompany,dc=com Тут вам и нафигация, и идентификация, и семантика, и иерархия. Ну и возможность моделировать - как же без этого. Великолепно можно моделировать. Предметную область. Структуру чего угодно, например, организационнро-штатную структуру компании, ее IT ресурсов, ее не-IT ресурсов. Можно смоделировать дерево, можно два, обычно моделируют три - дерево защищаемых ресурсов, дерево ролей, и дерево людей. Классическая ситуация с авторизацией на основе ролей. Да, ссылки!!! Конечно ссылки - как же без них. Все три (или более) дерева нужно связать между собой ссылками. Ну чтобы авторизация работала, и можно было выбрать роли персоны, и ресурсы ролей. Я так подробно для тех, кто не знает ldapv3. Так вот, теперь вывод - все это великолепно строится на RDBMS и великолепно работает у более чем одного производителя. То есть, как уже и было сказано выше, данные моделируются (правильно сказал?) в RDBMS, а объекты моделируются в ldap. И все просто счастливы. Масштабируемость, транзакционность (чего нет в стандарте ldapv3), триггеры (чего опять нет в стандарте ldapv3), производительность, репликации, далее везде. И никто не носится с идеей очередной революции (или с написанием диссертации). Все тихо так, скромненько. Даже скучно. Я к чему. Да фиг с ним с лдапом. Любую предметную область можно так. Пусть не в стандарте лдап, пусть точками. Что мешает? Диссертации не получится? Зато работать будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2006, 11:55 |
|
||
|
О типах связей в сетевой модели данных.
|
|||
|---|---|---|---|
|
#18+
ModelR SergSuperБлин, ну давайте хоть один топик сделаем ЧАЛFree! Неужели вам интересно постоянно размусоливать о невозможности навигации в РСБД? Дык про ключи надоело - никто и не пишет. А семантику еще не мусолили. Вдруг чего умное узнаем:). а тут тогда что? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2006, 12:31 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=34219998&tid=1553406]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
40ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
| others: | 13ms |
| total: | 139ms |

| 0 / 0 |
