Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 16 17 18 19 20 [21] 22 23 24 25 .. 31   вперед  Ctrl
 Re: О типах связей в сетевой модели данных.  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Александр Савинов
Теоретически, циклы можно допустить, если будет предоставлен механизм их "раскрутки"
Если допустить циклы, то таблицы будет невозможно однозначно упорядочить. А значит ваша идея, основанная на иерархии таблиц, рухнет.
Александр Савинов
именно поэтому СУБД должна знать как их интерпретировать
И должна знать, и знает. Схемы РБД с взаимными, циклическими и рефлексивными связями между таблицами (по FK->PK, разумеется) успешно проектируются и используются. Традиционные операции на таких структурах без проблем применяются. Более того, специальные операции для «раскрутки» циклов тоже предложены, от транзитивного замыкания TCLOSE до рекурсивных Common Table Expressions. Уж простите за ликбез, но в вашем случае он неизбежен.
Александр Савинов
Мы запрещаем циклы не для себя, а для СУБД.
Вы их запрещаете проектировщикам. Во имя неизвестной и неясной никому, кроме вас, цели.
Александр Савинов
mir
Зачем он тогда нужен, если не позволяет проектировать БД хотя бы с тем же уровнем гибкости и возможностей. как в РМД?

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

Во-вторых, даже если эту вашу мысль на минутку принять на веру, остается простая логика: каждая селедка -- рыба, но не каждая рыба -- селедка. То есть из того, что более продвинутые теории должны (якобы) привносить новые ограничения, не следует, что теория с большим количеством ограничений автоматически является более продвинутой. Так что ваше замечание совершенно к сути разговора не относится. Наличие в вашем подходе существенных ограничений таким философствованием "оправдать" не выходит.
Александр Савинов
Также как в более развитом государстве всегда меньше свободы (в отличие от общепринятого мнения).
Видимо, наиболее развитым государством была нацистская Германия (как одна из самых несвободных). Так, что ли?

Александр Савинов
Побить РМД в гибкости (т.е. в свободе действий и выразительности вряд ли кому удастся. Для примера, ассемблер бьет все другие языки, а также РМД, в гибкости и выразительности. Но нужно ли нам это?
Во-первых, РМД не язык программирования. Во-вторых, выразительность языка ассемблера минимальна. Почитайте что-нибудь про выразительность. А то ваша, уж простите, малограмотность мешает нам нормально дискутировать.
15 дек 06, 11:05    [3540458]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Александр Савинов
В процессе было затронуто несколько конкретных проблем, которые не связаны с какой-либо теорией. Например:
1 Отличия между доступом и поиском
2 Как удобнее организовать связи между сущностями:
3 Как удобнее организовать доступ:
4 Роль циклов в структуре БД
Как верно было подмечено, это вовсе не постановка проблем. В крайнем случае, это тянет на темы для исследований, причем с сомнительной актуальностью.
Александр Савинов
Но тут сразу налетели блюдители нравов и начали клеймить врагов народа за саму постановку вопроса, которая ставит под сомнение устои общества.
Неправда. От вас очень долго и безуспешно пытались получить определения используемых вами терминов и как раз четкую постановку вопросов. Вы не дали ни того, ни другого.
Александр Савинов
Мол, такие вопросы могут только избранные задавать (и отвечать). Смешно.
И опять неправда. Никто здесь даже в подобном духе не высказывался. Или готовы привести цитаты?
Александр Савинов
Я по всем этим вопросам высказался достаточно конструктивно
Определение доступа как "магической процедуры" как-то не выглядит конструктивно. Запрет циклов вы никак вообще не аргументировали, кроме подспудного "я так считаю". Это тоже не выглядит конструктивно. Так что ситуация скорее выглядит противоположным образом.
Александр Савинов
а вот от оппонентов кроме грязной ругани ничего нет.
Это очень сильно. Можно примеры грязной ругани в ваш адрес? Поскольку я один из ваших оппонентов, я настаиваю на доказательстве этого заявления.
Александр Савинов
А то mir уже в порыве досье на меня начал составлять. Гляди еще какую-то пакость придумает.
Постойте, неужели я переврал цитаты или присочинил что-то от себя? Я привел все цитаты правильно, дал ссылку (любой может сам проверить), так чем вы недовольны?

Кстати, уточните, пожалуйста, вы называете "пакостью" цитирование ваших слов или сами эти слова?
15 дек 06, 11:41    [3540848]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
vadiminfo
Александр Савинов
Любая теория проходит от начального творческого периода к времени, когда она превращается в догму и религию. И сейчас мы это наблюдаем на примере РМД.

А разве мы не видим, что других реальных теорий нет?

Такого масштаба действительно ничего нет и в ближайшее время не предвидится.

vadiminfo
ООМД - не является теоретически обоснованной. Это просто перенесение ООП в МД. Результат, несмотря на все казалось бы достоинства ООП (более естественное моделирование) - РМД устаяло, а ООМД пошло на спад.

Согласен. Я бы сказал, что ООМД не на спад пошло, а практически умерло. В частности, действительно, потому, что там нет собственно теории данных.

vadiminfo
А ООП стали пытаться внедрять в РМД(ОРМД - расширение). Вот это уж точно мы видим.

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

vadiminfo
А теории могут не только превращаться в догмы, но и переживать спады. Однако, это не значит, что им на смену должно прийти что попало, на основании лишь того, что это что попало еще не успело стать догмой или стереотипом. Хотя не очевидно, что ООП не имеет черт догм. Точнее оно имеет уже соответствующего типа сторонников.

Догма это не свойство теории. Это свойство людей, которые ее поддерживают. Если начинают убивать все новое именем теории, говорить от имени теории, то это признак догматического отношения к ней (со стороны людей). И сейчас, как мне кажется такое наблюдается в плане РМД, когда находится много людей, которые ее пытаются приватизировать и карать от ее имени. Я просто сравнил этот период в истории РМД от начального, когда ее саму все пинали кому не лень от имени тогдашних теорий.
15 дек 06, 11:46    [3540898]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
mir
Александр Савинов
Теоретически, циклы можно допустить, если будет предоставлен механизм их "раскрутки"
Если допустить циклы, то таблицы будет невозможно однозначно упорядочить. А значит ваша идея, основанная на иерархии таблиц, рухнет.
Она не рухнет, а просто (пока) не описывает этот случай. Но если и рухнет, то тогда РМД тоже рухнет, если данные не представляются отношениями. Почему на начальной стадии у РМД было столько проблем? Потому что никто не мог понять, как же так, дорогая редакция, в жизни данные иерархические (скажем), а в РМД все в плоских таблицах. И никто не мог этим гениям объяснить, что моделировать данные можно по разному. Главное результат. Так и Ваш аргумент. Мол я привык делать циклы и хочу их иметь, а потому теория, где их нет плохая. А Вы не задумывались над тем, какова семантика циклов, какова их роль при моделировании и, собственно, нужны ли они? Это весьма глубокий вопрос.

mir
Александр Савинов
Мы запрещаем циклы не для себя, а для СУБД.
Вы их запрещаете проектировщикам. Во имя неизвестной и неясной никому, кроме вас, цели.

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

mir
Александр Савинов
Побить РМД в гибкости (т.е. в свободе действий и выразительности вряд ли кому удастся. Для примера, ассемблер бьет все другие языки, а также РМД, в гибкости и выразительности. Но нужно ли нам это?
Во-первых, РМД не язык программирования. Во-вторых, выразительность языка ассемблера минимальна. Почитайте что-нибудь про выразительность. А то ваша, уж простите, малограмотность мешает нам нормально дискутировать.

Дочитав до конца, я был готов удивиться, что нет ничего личного. Анн-нет! Ваши инстинкты взяли свое. Не удержались. Так что я думаю, нам что-то другое мешает дискутировать. А именно, постоянные обвинения с Вашей стороны и непризнание того, что у каждого м.б. свое мнение, отличное от Вашего.

РМД конечно не язык программирования, но любая модель должна предоставить средства работы с данными, обычно какой-то язык. И в большой степени именно средства этого языка определяют ее качества. SQL, в частности, это обычный язык и сравнение с ассемблером для данных вполне уместно.
15 дек 06, 12:12    [3541112]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ggv
Member

Откуда:
Сообщений: 1810
не плохой, в принципе, форум, погибает из-за псевдоученых ....... собачек.
Помните? - "я не ученый, учеными бывают собачки, я - научный работник".
Что-то критики РМД слабо похожи на нацчных работников....
Более всего к ним подходит "звиздеть - не мешки ворочать".
Здесь требуется определение "звиздеть" и чем это отличается от "аргументировать".
15 дек 06, 12:19    [3541163]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
ЙОМОЙО
Но набирать хотим
Select t1.t1f2 where t1.t4f3='Нифигасебефамилия'
--ну или (если имена столбцов неуникальны)
Select t1.t1f2 where t1.(t4.t4f3='Нифигасебефамилия')

А остальное пущай ложиться на могучие плечи СУБД

Это так, но это все лишь одна компонента в подходе. Эта операция назывется проекция (из t4 в t1). Но почему проекция, и нужно ли нам это? А вот это уже ближе к сути. Мы предполагаем, что структура связей это не просто ссылки - что хочу то и делаю (произвольный граф с циклами). Это, в частности, иерархия "более общий - менее общий". Объект, который ссылается на другой, автоматически понимается как менее общий (более специфичный). В данном примере t4 наиболее специфичная таблица, а t1 наиболее общая. Таким образом, изначально в модели данных мы мыслим в терминах пространства (с размерностями), "общий-специфичный", "первичный-вторичный". СУБД при этом становится отсетственной за поддержание такой структуры, т.е. она знает о такой интерпретации. Например, что происходит с объектами в пространстве, если это пространство удалить, или удалить одну размерность пространства? Вот именно в таких терминах думает СУБД в этом случае.

Кстати, раз уж был приведен такой пример, то может кто-то из экспертов в SQL может мне помочь. Пусть есть последовательность таблиц t1, t2, ..., tN, где каждая следующая ссылается на предыдущую с помощью ключа (сложного).

Проблема 1 (проекция). Как найти записи из t1, на которые ссылаются через промежуточные таблицы выбранные записи из tN?

Проблема 2 (де-проекция). Как найти записи из tN, которые ссылаются через промежуточные таблицы на выбранные записи из t1

Я вижу только использование вложенных SELECT. Где самый внутренний находит записи в первой таблице и передает их во внешний следующий SELECT, который делает то же самое. Но есть вопрос, насколько это будет эффективно работать и есть ли ограничения на глубину вложенности (у подозреваю, что есть)? А может есть какие-то другие реализации?
15 дек 06, 12:33    [3541276]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
4321
Member [заблокирован]

Откуда:
Сообщений: 3573
Александр Савинов
ModelR
Что мешает явно указывать связь?

Каждый СОТРУДНИК может РАБОТАЕТ_В один ОТДЕЛ
Каждый ОТДЕЛ должен ИМЕЕТ_НАЧАЛЬНИКА один СОТРУДНИК
Каждый ОТДЕЛ может ИМЕЕТ_КУРАТОРА один СОТРУДНИК


Потому что нельзя ссылаться на то, что еще не существует. ОТДЕЛ может существовать без СОТРУДНИКа, поскольку это контейнер для них. Мы создаем отдел. Какие сотрдуники? Какие кураторы? Они еще не родились. А если бы они родились раньше, то, соответственно, не могли бы ссылаться на отделы.

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

Запрет на циклы это не цель, а средство, т.е. мы делаем это вынужденно, чтобы достигнуть чего-то большего.

Александр, ну неужели вы не видите, что сами, когда пытаетесь, разрешаете "проблему" цикличности ссылок рамножением сущностей. Ну так доведите эту мысль до конца.


Или давайте я расскажу вам как снять "проблему" цикличности (в ваше стиле) "вообще".

1. Вместо того, чтобы сразу писать нечто в виде

CREATE TABLE отдел
(id serial PRIMARY KEY
, начальник сотрудник^
, духовник сотрудник^
, название text
--, ....
;
CREATE TABLE сотрудник
(id serial PRIMARY KEY
работает_в отдел^
, курирует отдел^
, фамилия text
, имя text
--, ...
;
пишем в 2 фазы
--1. описываем все сущности "сами по себе"  -т.е. их идентификаторы
--как вещи в себе
CREATE ENTITY отдел^;
CREATE ENTITY сотрудник^;
CREATE ENTITY ... ;
-- описываем все сущности в их свойствах - т.е. собственно определяем их структуры
-- как "вещи для нас"
CREATE TABLE отдел отдел^ 
--допустимо не более 1 таблицы на ENTITY
(--id serial PRIMARY KEY не объявляется и не доступно - вместо него 
--отдел отдел^ вынесено в объявление таблицы
начальник сотрудник^
, духовник сотрудник^
, название text
--, ....
;
CREATE TABLE сотрудник сотрудник^
(--id serial PRIMARY KEY  не объявляется и не доступно....
работает_в отдел^
, курирует отдел^
, фамилия text
, имя text
...
;
-- тут все ENTITY уже определены, и "старше" TABLE-оф,
-- ENTITY в свою очередь - попросту идентификаторы сущностей, не имеют структуры,
-- т.ч. ни на что не ссылаются => никаких ссылочных цыклов в вашем понимании нет.
-- (таблицы ссылаются не на таблицы, а на ENTITY
--, а ENTITY не ссылаются ни на что - они базовые неопределяемые (а сл-но бесструктурные))

-- Пользуем
SELECT  с.работает_в.начальник
, с.работает_в.название AS отдел
, с.фамилия || ' ' || с.имя ... AS ФИО
...
;
если вы присмотритесь к своим построениям, то вы увидите, что делаете то же самое, но только принуждены вводить дублирующие "сущности" до определения их структур не как перечень используемых в модели сущностей, а как кастрированные таблицы (см ваш пример с "брак"-ом, не содержащим ничего, кроме собственного ПК). т.ч. не стоит ли вашу боязнь циклов в ссылках разрешить радикально. Введением новой разновидности объектов - явных объявлений идентификаторов - т.е. того, чего вам столь не хватает :0).


а на самом деле все это не так, чтобы интересно - т.к. попросту другая форма записи SQL.
Но, думается мне, интересна (независимо от формы записи) реализация примерно следующих вещей
CREATE INDEX idx_отдел_начальникотдел 
ON отдел 
(название , начальник.отдел.название);

поскольку пользователь БД ищет данные в ней не по указателям, а по значениям свойств (и их наборов), т.ч. интересны именно механизмы быстрого ПОИСКА (с последующим "доступом" - т.к. механизмы поиска обычно ищут указатели), а не доступа, как такового. В т.ч. быстрого доступа по наборам, включающим как значения атрибутов собственно текущей сущности, так и значения атрибутов атрибутов (объектных полей)
15 дек 06, 12:36    [3541299]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
4321
Александр Савинов
ModelR
Что мешает явно указывать связь?

Каждый СОТРУДНИК может РАБОТАЕТ_В один ОТДЕЛ
Каждый ОТДЕЛ должен ИМЕЕТ_НАЧАЛЬНИКА один СОТРУДНИК
Каждый ОТДЕЛ может ИМЕЕТ_КУРАТОРА один СОТРУДНИК


Потому что нельзя ссылаться на то, что еще не существует. ОТДЕЛ может существовать без СОТРУДНИКа, поскольку это контейнер для них. Мы создаем отдел. Какие сотрдуники? Какие кураторы? Они еще не родились. А если бы они родились раньше, то, соответственно, не могли бы ссылаться на отделы.

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

Запрет на циклы это не цель, а средство, т.е. мы делаем это вынужденно, чтобы достигнуть чего-то большего.

Александр, ну неужели вы не видите, что сами, когда пытаетесь, разрешаете "проблему" цикличности ссылок рамножением сущностей. Ну так доведите эту мысль до конца.

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

Вот скажите, каково Ваше мнение: циклы это зло или без разницы?
Если они Вам не мешают, то и проблемы нет. Ничего личного.

4321
Или давайте я расскажу вам как снять "проблему" цикличности (в ваше стиле) "вообще".

Насколько я понял, это решение скрывает циклы, но по сути цикл ведь остается. Правильно? Кроме того, он предполагает введение нового элемента ENTITY, который играет роль ширмы для таблицы, чтобы скрыть циклы (насколько я понял).

Но в целом, как я уже отметил, вопрос является концептуальным, а не техническим, т.е. средства "борьбы" или "обхождения" циклов не самое главное. Я предполагаю, что потребоность в них просто не должна возникнуть, так же как потребность в GOTO.
15 дек 06, 13:58    [3542076]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
Вот пример, который показывает, в чем собственно проблема.

У нас есть таблица категорий товаров, содержащая, скажем, "дома", "машины" и т.п. Она дается нам заранее, например, с таможни. На эту таблицу ссылаются (используют) многие другие таблицы, например, Продажи.

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

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

На самом деле это не худший сценарий. Далее мы приходим к ситуации, когда все ссылаются на всех, т.е. получаем полный хаос, примерно как с GOTO. Надо - значит сделаем. Кто первый, кто последний - невозможно определить. Что же тогда делать? Одно решение состоит в том, чтобы следовать дисциплине, когда "старые" не могут ссылаться на "новые", поскольку это ссылка в будущее, которое нельзя предсказать. Категории это одна из исходных таблиц, которая ничего не должна знать о других сущностях в системе.
15 дек 06, 14:18    [3542257]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Александр Савинов
...Далее, в процесс эволюции БД...

странная какая-то эволюция
обычно так не работают
15 дек 06, 14:28    [3542345]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
4321
Member [заблокирован]

Откуда:
Сообщений: 3573
Александр Савинов
Я бы не стал формулировать вопрос циклов, как "проблему" с которой надо бороться или обходить какими-то изощренными техническими средствами.

заметьте, не я это предложил. (с)
Александр Савинов
Есть два стиля: традиционный основан не произвольной структуре ссылок (с т.ч. с циклами), а другой основан не безцикловом графе.
тема графа не раскрыта (сараментальный фопрос "на хрена" натыкается на "Я бы не стал формулировать" и т.п.) Таки хотелось бы понять, чем же он таки "основан" на этой самой бесцикличности, этот ваш подход.
Александр Савинов
При моделировании без циклов никаких проблем не возникает, поскольку они не нужны для моделирования данных,
ну да. вы попросту (довольно произвольно) рассекаете сущность на 2. хотя основным принципом (на деле) является именно выделение ПК (ну и возможно всех безсылочных атрибутов) в "1-ю" (под)сущнсоть, и отсылка всех ссылочных - во 2-ю.


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

Александр Савинов
Но в целом, как я уже отметил, вопрос является концептуальным, а не техническим, т.е. средства "борьбы" или "обхождения" циклов не самое главное.
так вам и предложено концептуальное решение, вычлененное из ваших же (технических) ужимок с рассечением сущностей.
Сухой остаток, т.сказать ];0)
ничего личного.
15 дек 06, 14:31    [3542373]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
U-gene
Вы тут пишите много красивых примеров....:)....однако утверждаете, что де для реализации этих примеров нужно отказаться от РМД. Так нет же. Я (подобно многим тут позволю себе немного просамопиарится) и посоветую Вам сходить по этой ссылке. В принципе мне очень близки Ваши идеи насчет "удобства"...
account.owner.address.street
..точечных нотаций, однако дело в том, что все эти и многие другие "удобные" вещи можно рассматривать всего лишь как иную форму записи операций РМД + некоторые реализуемые системой закономерности по переименованию отношений и их атрибутов в процессе выполнения этих операций.

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

- Ключи в РМД это вовсе не ссылки. Это набор идентифицирующих свойств. А ссылка это отделяемое свойство.

- При доступе к данным в РМД в явном виде должны присутствовать имена ключей, а в точечной нотации они скрыты. Средства наподобие natural join или key join это иногда очень удобные, но все же приспособы с ограниченным использованием.

U-gene
Другими словами Ваши желания не требуют отказа от РМД и более того - выражаются в терминах РМД.

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

U-gene
Конечно, можно сетовать на то, что что РМД неудобна. Вы еще посетуйте на то, что арифметика неудобна - хотя бы потому что в ней нет операции нахождения корней квадратного тречлена или определения среднеквадратичного отклонения (а ведь кое кому эти возможности крайне важны!). В общем "Вы не любите РМД? - Вы просто не умеете её готовить".

Попробуйте убедить знатока ассемблера, что есть способ программироваь лучше. Он Вам ответит то же самое :-) А про неудобства это не я жалуюсь, а те, кто разрабатывает новые средства, чтобы прикрыть ее более удобным уровнем. Так что все претензии к ИБМ или Микрософт. Я тут не при чем.
15 дек 06, 14:35    [3542400]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
4321
Александр Савинов
Насколько я понял, это решение скрывает циклы, но по сути цикл ведь остается. Правильно? Кроме того, он предполагает введение нового элемента ENTITY, который играет роль ширмы для таблицы, чтобы скрыть циклы (насколько я понял).
вы неправильно поняли.
Оно не "скрывает цыклы", а раскрывает сущность ваших же приемов по "снятию цыклов". В оголенном виде. При этом умудряется обойтись без деления таблиц пополам, т.е. без удвоения числа сущностей.

Да, но Вы делите пополам TABLE, разделяя ее на ENITITY и собственно TABLE, так что тоже без усложнения не обойтись. Кроме того, когда Вы говорите о делении таблиц и ненужном усложнении, то кто Вам сказал, что оно ненужно? Это отражает предметную область. А так можно вообще все в одну таблицу закинуть и сказать, что это самый простой дизайн.

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

Вообще-то, сейчас мы говорим не о доступе и идентификаторах, а о циклах. А такое выделение ENTITY это хорошо, и более того, так и надо делать.

Поскольку для каждой ENTITY существует одна TABLE, то фактически ENTITY это ширма, поскольку они существуют парами. Когда мы объявляем ссылку на какую-то ENTITY, то на самом деле видны и поля соответствующей TABLE. Вот если бы могло быть много разных TABLE существовать для одной ENTITY, тогда другое дело.
15 дек 06, 14:53    [3542525]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Александр Савинов
Здесь просто сложился такой стиль диалога, когда вместо аргументов говорят: "ах ты, гад, родину (РМД) не любишь".


Когда же вы поймете, что он сложился исключительно у Вас в голове.
Присоединяюсь к mir

Ссылки на гонения/претеснения/репресси/религиозный фанатизм в студию
за[censored] вы уже всех своим инфантилизмом
15 дек 06, 15:06    [3542620]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
SergSuper
Александр Савинов
...Далее, в процесс эволюции БД...

странная какая-то эволюция
обычно так не работают

Работают по-разному, в т.ч. и таким образом. Но дело не в этом, это ведь пример.

Проблема в том, что есть первичные и более простые вещи, и есть вторичные, более сложные. Например, есть тип Integer, который уже должен заранее существовать перед тем как его можно использовать. Есть класс Figure, который должен быть определен до того, как мы можем определить расширение Rectangle. Это общий принцип. Для нового элемента нужен контекст.

Что касается ссылочной структуры, то здесь его тоже можно применить. В программировании, однако, это не полезно, поскольку слишком сложные связи, а поддержки семантики данных нет. В модели данных же это может быть важным, если мы хотим свалить часть работы на СУБД.
15 дек 06, 15:08    [3542640]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
Александр Савинов
- При доступе к данным в РМД в явном виде должны присутствовать имена ключей, а в точечной нотации они скрыты.

Ваша "точечная нотация" неоднозначна, поэтому лучше про нее совсем забыть. Придумайте что-нибудь получше - например SQL :)
15 дек 06, 15:12    [3542666]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
Gluk (Kazan)
Александр Савинов
Здесь просто сложился такой стиль диалога, когда вместо аргументов говорят: "ах ты, гад, родину (РМД) не любишь".


Когда же вы поймете, что он сложился исключительно у Вас в голове.

Точно так же, как иллюзии, что на РМД кто-то покушается и ее надо защищать.

Gluk (Kazan)
Присоединяюсь к mir

А свое мнение слабо иметь? Или из толпы, да еще иконой прикрывшись, оно как-то надежнее, да? Привычка присоединяться к чему-то или кому-то. Одобрямс.
15 дек 06, 15:13    [3542673]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
мод
Александр Савинов
- При доступе к данным в РМД в явном виде должны присутствовать имена ключей, а в точечной нотации они скрыты.

Ваша "точечная нотация" неоднозначна, поэтому лучше про нее совсем забыть. Придумайте что-нибудь получше - например SQL :)

Это не моя, это античная вещь. Я думаю, каждый ее использует и не жалуется.
15 дек 06, 15:15    [3542689]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Александр Савинов
А свое мнение слабо иметь? Или из толпы, да еще иконой прикрывшись, оно как-то надежнее, да? Привычка присоединяться к чему-то или кому-то. Одобрямс.


сцылки [censored] в студию, [censored]
Сразу после этого, можешь начинать учить меня жить, [censored]
15 дек 06, 15:23    [3542767]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
Gluk (Kazan)
Александр Савинов
А свое мнение слабо иметь? Или из толпы, да еще иконой прикрывшись, оно как-то надежнее, да? Привычка присоединяться к чему-то или кому-то. Одобрямс.


сцылки [censored] в студию, [censored]
Сразу после этого, можешь начинать учить меня жить, [censored]

Ну, вот, я так и думал. Обиделись. Опять материться начали. Но хотя от себя, от души. И то прогресс.
15 дек 06, 15:25    [3542788]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Какой альфонсизм. Публикуют каие-то научные работы, пудрят мозк заказчиком (в результате чего те вместо нормально работающей системы пытаются внедрять какую-то [censored]). На форуме их видите-ли репрессируют, ортодоксы зажимают передовую науку, лять. Начинаешь копать - нет никакой науки. Внутри неонка и кусок провода. Уроды
15 дек 06, 15:35    [3542872]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Александр Савинов
mir
Если допустить циклы, то таблицы будет невозможно однозначно упорядочить. А значит ваша идея, основанная на иерархии таблиц, рухнет.
Она не рухнет, а просто (пока) не описывает этот случай.
Вы постоянно упоминали на comp.databases.theory, что отсутствие циклических связей между таблицами (то есть возможность ввести иерархию таблиц) есть иммантное свойство (и обязательное требование) вашей «концептно-ориентированной модели данных», не так ли? Это вовсе не то же самое, что она «просто пока не описывает этот случай».
Александр Савинов
Но если и рухнет, то тогда РМД тоже рухнет, если данные не представляются отношениями.
Однозначно. Поэтому никто и не говорит, что в РМД можно допустить представление данных не в виде отношений. А вы-то сказали, что «циклы можно допустить». Вот это и показалось мне странным.
Александр Савинов
Почему на начальной стадии у РМД было столько проблем? Потому что никто не мог понять, как же так, дорогая редакция, в жизни данные иерархические (скажем), а в РМД все в плоских таблицах.
Источник такой интересной исторической информации можно? Лично я помню из литературы, что на начальной стадии у РСУБД были проблемы из-за низкой производительности. Это во-первых. Во-вторых, в жизни чистые иерархии встречаются довольно редко. Поэтому удивиться по этому поводу никто не мог бы. В-третьих, никаких плоских таблиц в РМД нет. В РМД отношения, а они никакие не плоские (прошу прощения за очередной ликбез).
Александр Савинов
Мол я привык делать циклы и хочу их иметь, а потому теория, где их нет плохая.
Дело не в том, что я привык делать циклы, а в том, что сложная структура связей между данными есть в реальном мире. Поэтому желание представить их и в базе данных вполне естественно. Причем с минимальными накладными расходами. Разумеется, любая модель данных накладывает свои ограничения и неудобства. Поэтому все упирается в баланс между неудобствами в одном и преимуществами в другом. Вот вы предлагаете дополнительные неудобства. А вот об агромадных выгодах что-то молчок.
Александр Савинов
А Вы не задумывались над тем, какова семантика циклов, какова их роль при моделировании и, собственно, нужны ли они?
Да. А вот у вас я вижу непонимание разницы между циклами связей между записями и циклами связей между отношениями. Вы по смыслу говорите о вреде циклических связей между записями, но предлагаете устранить связи между отношениями. Это как лечить головную боль усекновением головы.
Александр Савинов
В частности, мы получаем понятие размерности БД, например, одна БД может быть 4-мерной, а другая 40-мерной.
То, что мы получаем понятие размерности БД (что бы это ни значило), это не хорошо и не плохо. Это ничего не значит само по себе. Бессмысленный набор слов.
Александр Савинов
Т.е. данные живут в пространстве из 4 или 40 измерений как точки.
В РБД данные и так «живут» в пространстве как точки. Это изначальное свойство РБД. Кортеж отношения из N атрибутов есть вектор с N компонентами, то есть точка N-мерного пространства. Вопрос трактовки, не более того. Вы этого не знали?
Александр Савинов
С другой стороны, это пространство иерархично, т.е. одна размерность может иметь несколько уровней детализации.
Размерность на имеет детализации. Если под ней не понимать что совсем другое. Вот вам пример: куб. Фигура имеет 3 измерения. Придумайте уровни детализации каждой размерности. Бессмыслица какая-то.
Александр Савинов
Далее, на этом основано несколько важных механизмов: проекции и де-проекции, агрегирования, логического вывода.
В РМД проекция, агрегирование, логический вывод и без того существуют и успешно применяются без необходимости вводить предложенные вами ограничения.
Александр Савинов
Наличие цикла означает бесконечную размерность
Размерность чего? Понятие размерности отношения известно, понятие размерности БД не определено (да и надо ли?). Поэтому данная фраза пока ничего для меня не означает.
Александр Савинов
поскольку по нему можно пройти сколько угодно, что запутает СУБД, поскольку она отвечает за вышеперечисленные операции.
У вас СУБД представляется какой-то глупой истеричкой. Вы ее персонализируете. Прям-таки как только мы определили такие связи, СУБД возьмет и запутается. Может, еще она и мышей боится? СУБД реализует операции в соответствии со спецификациями. Рекурсивные операции вроде транзитивного замыкания или RCTE определены так, что бесконечной рекурсии быть не может. Больше читайте, меньше фантазируйте.
Александр Савинов
Поскольку лично я считаю, что циклы это зло, то просто не хочу развивать и вводить механизм их поддержки для общего случая (но это возможно).
Да-да, аргументы «я так считаю» и «я не хочу» являются сугубо технологическими и очень конструктивными.
Александр Савинов
mir
Во-первых, РМД не язык программирования. Во-вторых, выразительность языка ассемблера минимальна. Почитайте что-нибудь про выразительность. А то ваша, уж простите, малограмотность мешает нам нормально дискутировать.
Дочитав до конца, я был готов удивиться, что нет ничего личного. Анн-нет! Ваши инстинкты взяли свое. Не удержались. Так что я думаю, нам что-то другое мешает дискутировать. А именно, постоянные обвинения с Вашей стороны и непризнание того, что у каждого м.б. свое мнение, отличное от Вашего.
А по существу возражения есть? Вы сказали, что язык ассемблера непревзойден по выразительности. Это безграмотно (читайте определение выразительности языка). Я всего лишь констатировал данный факт. Или вы настаиваете на своем утверждении? Если нет, то не вижу причин обвинять меня в предвзятости.
15 дек 06, 15:36    [3542881]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
Gluk (Kazan)
Какой альфонсизм. Публикуют каие-то научные работы, пудрят мозк заказчиком (в результате чего те вместо нормально работающей системы пытаются внедрять какую-то [censored]). На форуме их видите-ли репрессируют, ортодоксы зажимают передовую науку, лять. Начинаешь копать - нет никакой науки. Внутри неонка и кусок провода. Уроды

Ну вот молодцом. Это действительно ясно выраженная позиция. Уважаю (серьзно, без шуток). Это довольно распространенное мнение, которое имеет свои серьезные основания. Я сам по некоторым вопросам придерживаюсь подобных взглядов.
15 дек 06, 15:42    [3542932]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
Александр Савинов
Это не моя, это античная вещь. Я думаю, каждый ее использует и не жалуется.

античная неоднозначность (уходите от ответа)
15 дек 06, 15:43    [3542945]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Александр Савинов
Кстати, раз уж был приведен такой пример, то может кто-то из экспертов в SQL может мне помочь. Пусть есть последовательность таблиц t1, t2, ..., tN, где каждая следующая ссылается на предыдущую с помощью ключа (сложного).

Проблема 1 (проекция). Как найти записи из t1, на которые ссылаются через промежуточные таблицы выбранные записи из tN?

Проблема 2 (де-проекция). Как найти записи из tN, которые ссылаются через промежуточные таблицы на выбранные записи из t1

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

1. Вы не понимаете смысла термина «проекция». Срочно читать любую книжку по геометрии или по РМД! Есть точки (в геометрии) и кортежи (в РМД). И то и другое математически — векторы из N компонентов (имеем N-мерное пространство). Операция проекции удаляет из пространства некоторые измерения, то есть снижает его размерность. И в случае точки и в случае кортежа это трактуется однозначно как удаление из вектора компонентов, которые относились к удаленным измерениям.

2. То, что вы почему-то называете проекцией, фактически есть вариант операции выборки (фильтрации, ограничения).

3. Обе ваши мега-задачи решаются, просто и одинаково, соединением (JOIN) указанных таблиц с последующей проекцией по атрибутам первой таблицы (для задачи 1) или последней таблицы (для задачи 2). И никаких тебе, понимаешь, вложенных SELECT, никаких ограничений. Эффективность определяется внутренней реализацией СУБД. Как делаются соединения, рассказать?

4. (Для любознательных) Для повышенного удобства написания подобных запросов давно предложена операция полусоединения (SEMIJOIN), читать у того же Дейта. Полусоединение R1 SEMIJOIN R2 определяется как проекция соединения R1 JOIN R2 по всем атрибутам R1. Трактуется, понятно, так: "выбрать из R1 все кортежи, имеющие связь с кортежами из R2".
15 дек 06, 16:08    [3543171]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 16 17 18 19 20 [21] 22 23 24 25 .. 31   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить