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

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

Понимаете, все движется и развивается. Изначально требования довольно жесткие, т.е. циклы были полностью запрещены. Потом стало ясно, что ссылка на себя ничему не мешает. Я Вам скажу, что в процесе дискуссии я нашел одно весьма интересно решение т.н. проблемы циклов (спасибо ModelR за мотивирующий пример). Завтра еще что-то появится. В любой теории, и РМД не исключение, очень много со временем меняется.

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

Согласен с первым и сожалению о последнем. У нас тут элементарные вопросы бурю эмоций вызывают, а более сложный приведет к краху интернета.

mir
Александр Савинов
А Вы не задумывались над тем, какова семантика циклов, какова их роль при моделировании и, собственно, нужны ли они?
Да. А вот у вас я вижу непонимание разницы между циклами связей между записями и циклами связей между отношениями. Вы по смыслу говорите о вреде циклических связей между записями, но предлагаете устранить связи между отношениями. Это как лечить головную боль усекновением головы.

Ну давайте обсудем эту проблему. Я говорю, что если в структуре таблиц циклов нет, то и между записями их не будет. Согласны?

mir
Александр Савинов
В частности, мы получаем понятие размерности БД, например, одна БД может быть 4-мерной, а другая 40-мерной.
То, что мы получаем понятие размерности БД (что бы это ни значило), это не хорошо и не плохо. Это ничего не значит само по себе. Бессмысленный набор слов.
Александр Савинов
Т.е. данные живут в пространстве из 4 или 40 измерений как точки.
В РБД данные и так «живут» в пространстве как точки. Это изначальное свойство РБД. Кортеж отношения из N атрибутов есть вектор с N компонентами, то есть точка N-мерного пространства. Вопрос трактовки, не более того. Вы этого не знали?

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

mir
Александр Савинов
С другой стороны, это пространство иерархично, т.е. одна размерность может иметь несколько уровней детализации.
Размерность на имеет детализации. Если под ней не понимать что совсем другое. Вот вам пример: куб. Фигура имеет 3 измерения. Придумайте уровни детализации каждой размерности. Бессмыслица какая-то.

Вовсе нет. Если Вы знакомы с OLAP, то у не должно быть отторжения. Это одна из основ (многомерность БД и ее иерархичность). Представьте, что каждая точка на одной из сторон куба на самом деле объект с двумя собственными измерениями.

Был обычный 3-мерный куб:

T
/ | \
X1 X2 X3
\ | /
CUBE

А теперь одно измерение X3 само является двумерным:

T
/ | \ \
| | | \
| | X4 X5
| | \ /
X1 X2 X3
\ | /
CUBE

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

Верно, но только вручную. Если я напишу для этого (правильный) запрос, то все будет работать. А мы вводим базовые свойства и механизмы о которых будет знать сама СУБД. Соответственно, хотим свалить на нее кучу работы. Ну и конечно платим за это свободой. СтОит ли это делать? Не знаю. Мое дело предложить. Я не судья.

mir
Александр Савинов
Наличие цикла означает бесконечную размерность
Размерность чего? Понятие размерности отношения известно, понятие размерности БД не определено (да и надо ли?). Поэтому данная фраза пока ничего для меня не означает.

Упрощенно, размерность это путь по ссылкам. См. диаграммы вверху. Таблица CUBE имеет три собственных размерности. Теперь представьте, что одна из них, например, X3, будет ссылаться на сам CUBE, т.е. папа ссылается на ребенка. Обоим будет плохо. Какова тогда размерность куба я не берусь предсказать.

mir
Александр Савинов
Поскольку лично я считаю, что циклы это зло, то просто не хочу развивать и вводить механизм их поддержки для общего случая (но это возможно).
Да-да, аргументы «я так считаю» и «я не хочу» являются сугубо технологическими и очень конструктивными.

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

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

Давайте не цепляться к словам. Я имел в виду, что на ассемблере Вы всегда запрограмируете то, что сможете на более продвинутом языке и все. Этот язык дает больше свободы действий, т.е. практически ее не ограничивает. Хочешь, делай ошибку, адресуй любую память, вызывай лубой код. Вот и все. А на физическом уровне еще больше свободы, чем на ассемблере.
15 дек 06, 16:27    [3543349]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
4321
Member [заблокирован]

Откуда:
Сообщений: 3573
Александр Савинов
Да, но Вы делите пополам TABLE, разделяя ее на ENITITY и собственно TABLE, так что тоже без усложнения не обойтись.
не я разрываю, а вы (в процессе ухода от цыклов).

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

Александр Савинов
Кроме того, когда Вы говорите о делении таблиц и ненужном усложнении, то кто Вам сказал, что оно ненужно? Это отражает предметную область.
гм. расскажите это на примере выделения ПК сущности "брак" в самостийную таблицу, содержащую единственно суррогатный ПК (т.е. не отражающую ничего кроме _модельного_ понятия - ПК). Если мы найдем в понятии ПК нечто предметное, кроме модельного понятия "указатель" - то я, пожалуй, и соглашусь.

Александр Савинов
А такое выделение ENTITY это хорошо, и более того, так и надо делать.

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

это все не имеет отношения к цикличности ссылок. Т.ч. обсудим эту вариацию _вашего подхода_ факультативно:

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

Просто в случае, когда за ENTITY стоит (в качестве "идентифицируемой") одна и только одна таблица (или же множество, но одного типа (одной структуры)), мы знаем набор полей, в который можно развернуть эту ссылку уже в тот момент, когда определяем поле этого типа в другой таблице. Если же мы с вами озаботимся тем, чтобы снимать [в языке запросов] коллизии при попытке обратиться к несуществующему полю некоторой конкретной сущности (если масса таблиц адресуется одной и той же ENTiTY [возможно напрямую, а возможно через унаследованные от нее ENTiTY], то и нет требований общности структур). Все, видимо, упрется в концепцию наследования ENTiTY и в концепцию разруливания коллизий обращения (добавить _декларативную_ обработку ошибок обращения (поскольку язык то хочется иметь декларативный) или же попросту ввести служебные значения для отсутствия разворачиваемого по ссылке атрибута (а не его значения)).
15 дек 06, 16:31    [3543380]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
мод
Александр Савинов
Это не моя, это античная вещь. Я думаю, каждый ее использует и не жалуется.

античная неоднозначность (уходите от ответа)

Вовсе нет. Просто не увидел там вопроса. Вы предложили заменить "мою точечную нотацию" на что-то лучше, например, SQL. Я понямаю это как призыв назад в будущее. Ну что ж, действительно, есть такое мнение. Но ведь точечная нотация очень широко распространена, а во-вторых SQL тоже не скоро отомрет. Так что единственная конкретная проблема, которую я вижу, это как-то их совместить. Но в чем был вопрос, я все-равно не понял.
15 дек 06, 16:33    [3543415]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
Александр Савинов
Но в чем был вопрос, я все-равно не понял.

Неоднозначность такой нотации !
15 дек 06, 16:42    [3543495]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

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

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

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

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

Вы радуетесь как ребенок, когда он узнал, что взрослые могут что-то не знать или делать ошибки. Я прямо вижу, как у Вас глаза горят. Хочу Вас расстроить. То. что я что-то могу не понимать, меня никак не обижает.

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

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

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

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

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

Это с точки зрения РМД и это показывает различия. На самом деле это есть не что иное как проекция. Дело в том, что РМД не придает никакой семантики связям. А в КОМ ссылка это указатель на пространство, которому мы принадлежим, и на которое нас можно спроецировать.

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

Спасибо, не обязательно (боюсь, слишком много инфы за день получить). Меня интересует больше вопрос, преимущества и недостатки двух способов (через join и вложенный select).
15 дек 06, 16:51    [3543586]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

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

Неоднозначность такой нотации !

Пардон. Теперь ясно. Так я ведь привел 4 (если не ошибаюсь) способа устранения неоднозначности, а также условия их применения. Среди них * есть. Или и Вы о другом? Я просто забыл про ту тему, поэтому не могу быстро переключиться (мы тут уже геометрию обсуждаем по ходу дела, скоро до Эвклида доберемся). Может чего пропустил. А Вы так лаконичны, что я не могу восстановить контекст.
15 дек 06, 16:58    [3543639]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

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

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

Далее, в процесс эволюции БД, приходит чел и говорит, ....
Действительно бардак, но иллюстрирующий какую-ту другую проблему, типа рост алкоголизма как следствие кривого проектирования:).
А вот еще реальный пример :

Город--входит в-->Регион
Регион--имеет административный центр-->Город

Структурно в точности то же что и Сотрудники/отделы.

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

Проблема 2 (де-проекция). Как найти записи из tN, которые ссылаются через промежуточные таблицы на выбранные записи из t1
Эхх, были бы все проблемы этого типа ...
15 дек 06, 17:04    [3543695]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Александр Савинов
Это принципиально другой способ доступа, чем предлагает РМД.
Ну вот - опять. РМД не предлагает способов доступа! Способ доступа предлагает система! Вы путаете определяемую в РМД формальную операцию JOIN и оператор "JOIN" языка программирования SQL-систем.

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

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

Во-вторых.... ну почему Вы всё время связываете ключи и JOIN? JOIN может быть выполнен по любым полям - лишь бы они были из одного доменеа, или даже из разных , но сравнимаемых доменов. Ключ - это ограничение целостности, JOIN - это операция. Всё. Вы же (подозреваю, что по опыту эксплуатации SQL-систем ) вложили в эти простые понятия какой-то свой смысл и теперь яросно со своими же впечатлениями боретесь.

Александр Савинов
При доступе к данным в РМД в явном виде должны присутствовать имена ключей....
Алёй! Вы сами то вдумайтенсь, что Вы сказали!
1) повтор - в РМД нет доступа к данным
2) при чем здесь ключи? Для того, что бы выполнить JOIN, поля, по которым происходит этот самый JOIN, вовсе не дложны быть ключевами.Может Вы все же имели в виду имена полей?

Александр Савинов
...а в точечной нотации они скрыты. Средства наподобие natural join или key join это иногда очень удобные, но все же приспособы с ограниченным использованием.
Друг мой! Вы опять путаете операции модели данных и языковые операторы системы. Ведь ничто не мешает для обозначения формальной операции JOIN использовать в языке управления БД какие угодно символы - хоть ту же точечную нотацию. Она же от этого хуже не станет? :) Но тогда это означает, что точечная нотация - это равноценная приспособа с ограниченным использованием.

Еще раз вчитался Повторяю. "Средства наподобие natural join или key join это иногда очень удобные, но все же приспособы с ограниченным использованием". В целом это, извините, бред. Правда. Вот если я скажу, что "средства наподобии операции умножения двух и более чисел это иногда очень удобно, но все же это приспособы с ограниченным использованием" ведь надо мной же люди смеятся будут. А ведь JOIN - это математическая операция.

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

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

Согласен, отказа от РМД вовсе не нужно.
ИМХО Вы не поняли. Зачем делать какие то домыслы, нести околесицу и искать пробелы и неудобства в теории, если все это можно сделать, используя именно эту теорию?

Александр Савинов
РМД была и будет и ничего с ней не случится, тем более из-за меня.
Спасибо конечно, что Вы дали РМД право на жизнь :) но на самом деле это не у неё беда, а у Вас. Во всяком случае в Ваших красивых примерах я не нашел ничего, что не могло бы быть записано с помощью операций РМД. Другими словами все Ваши рассуждения о том, что JOIN это ограниченная приспособа - это только от незнания.

Александр Савинов
Попробуйте убедить знатока ассемблера, что есть способ программироваь лучше
Ну если в моих доводах я покажу незнание основ программирования, то видимо знаток будет прав.

Александр Савинов
А про неудобства это не я жалуюсь, а те, кто разрабатывает новые средства, чтобы прикрыть ее более удобным уровнем.
Но те то жалуются, что система неудобная. А Вы тут почему то на модедь ( т.е. на голую математику) волну гоните. С теми я соглашусь на 200%, а с Вами - никогда.
15 дек 06, 18:20    [3544262]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
U-gene
Однако ничето не помешает описать в терминах реляционной модели данных, эти самые данные обо всем - о ссылках, связах, указателях, иерархиях равно как о отгрузках, клиентах, обедах, бизнес-транзакциях и тп.


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

Откуда:
Сообщений: 173
U-gene
Александр Савинов
Ключи в РМД это вовсе не ссылки. Это набор идентифицирующих свойств.

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

Ну и что. Это что, индульгенция? Если в ней нет ссылок, значит и доступа по ссылкам нем. Это свойство модели. А другой модели они есть. Третья модель может быть основана на иерархии. И что теперь надо говорить, что там есть только иерархии, а потому претензии не принимаются, поскольку дерево это математическая конструкция и там все всегда верно.

U-gene
Александр Савинов
При доступе к данным в РМД в явном виде должны присутствовать имена ключей....
Алёй! Вы сами то вдумайтенсь, что Вы сказали!
1) повтор - в РМД нет доступа к данным


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

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

U-gene
Александр Савинов
...а в точечной нотации они скрыты. Средства наподобие natural join или key join это иногда очень удобные, но все же приспособы с ограниченным использованием.
Друг мой! Вы опять путаете операции модели данных и языковые операторы системы. Ведь ничто не мешает для обозначения формальной операции JOIN использовать в языке управления БД какие угодно символы - хоть ту же точечную нотацию. Она же от этого хуже не станет? :) Но тогда это означает, что точечная нотация - это равноценная приспособа с ограниченным использованием.

Отсюда следует, что все в мире есть РМД, поскольку все или почти все можно транслировать с помощью соответствующих средств в язык представления и доступа РМД. Другой пример. Поклонник программирования на ассемблере скажет, что программа это последовательность символов, а потому Си++ все равно транслируется в ассемблер. Значит они эквивалентны.

А вообще, я уже отметил принципиальную разницу между т.н. точечной нотацией и средствами РМД. А также указал, почему представляется весьма затруднительным ввести ее в SQL. Так что, я могу только повторить, дело не в символах, а в сути той или иной модели.

U-gene
Еще раз вчитался Повторяю. "Средства наподобие natural join или key join это иногда очень удобные, но все же приспособы с ограниченным использованием". В целом это, извините, бред. Правда. Вот если я скажу, что "средства наподобии операции умножения двух и более чисел это иногда очень удобно, но все же это приспособы с ограниченным использованием" ведь надо мной же люди смеятся будут. А ведь JOIN - это математическая операция.

Нет. JOIN это базовая вещь. А вот natural join или key join это средства для сокращения записи. Если мы их выкинем, то ничего не поменяется по сути. Так что к умножению это не имеет отношения.

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

Согласен, отказа от РМД вовсе не нужно.
ИМХО Вы не поняли. Зачем делать какие то домыслы, нести околесицу и искать пробелы и неудобства в теории, если все это можно сделать, используя именно эту теорию?

Чтобы повысить уровень описания. Зачем нужна модель данных и соответствующая СУБД, если можно все на Си реализовать?

U-gene
Александр Савинов
РМД была и будет и ничего с ней не случится, тем более из-за меня.
Спасибо конечно, что Вы дали РМД право на жизнь :) но на самом деле это не у неё беда, а у Вас. Во всяком случае в Ваших красивых примерах я не нашел ничего, что не могло бы быть записано с помощью операций РМД. Другими словами все Ваши рассуждения о том, что JOIN это ограниченная приспособа - это только от незнания.

Т.е. если Вы не поняли, то у меня беда. Ну да ладно.
Но Вы опять используете следующее правило:

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

Вы понимаете порочность такого правила? Если нет, то я поясню. Дело в том, что нет проблемы представить данные или манипулировать данными (и никогда не было). Просто берете голое железо, читаете и пишете блоки в памяти, потом обрабатываете. Это будет работать, а значит, по Вашему, РМД не нужна. Я же считаю иначе. Дело не в том, можно или нельзя. А дело в адекватности средства, удобности, эффективности и уровне абстракции.

U-gene
Александр Савинов
А про неудобства это не я жалуюсь, а те, кто разрабатывает новые средства, чтобы прикрыть ее более удобным уровнем.
Но те то жалуются, что система неудобная. А Вы тут почему то на модедь ( т.е. на голую математику) волну гоните. С теми я соглашусь на 200%, а с Вами - никогда.

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

У Вас есть представление о модели как о голой математике. Это на самом деле не так. Математика это средство. Можно словами выразить, а можно формулами. Но чаще аппелируют к математике как к крыше для прикрытия. Ну мол, если здесь математика, значит это непогрешимо и критиковать нельзя. Это уже политика, борьба за власть. Я занимаюсь экономикой (технологией), и мне без разницы как это называется - главное, чтобы это эффективно работало. Если это работает плохо, то я так и скажу. А если плохо, то никакие тонны формул этот подход не спасут.
15 дек 06, 20:22    [3544633]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
8)))
Guest
Александр Савинов
Это кстати, официальная точка зрения, или Ваше личное предположение, что РМД не предоставляет доступа к данным. Я в том смысле, я могу это говорить другим людям, что все модели доступ к данным предоставляют, а вот РМД нет. Свойство у нее такое.

Яндекс рулит

К сообщению приложен файл. Размер - 0Kb
15 дек 06, 22:18    [3544884]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Александр Савинов
mir
Александр Савинов
А Вы не задумывались над тем, какова семантика циклов, какова их роль при моделировании и, собственно, нужны ли они?
Да. А вот у вас я вижу непонимание разницы между циклами связей между записями и циклами связей между отношениями. Вы по смыслу говорите о вреде циклических связей между записями, но предлагаете устранить связи между отношениями. Это как лечить головную боль усекновением головы.

Ну давайте обсудем эту проблему. Я говорю, что если в структуре таблиц циклов нет, то и между записями их не будет. Согласны?
Да, ровно в той же мере, как и усекновение головы приведет к исчезновению головной боли.

Александр Савинов
mir
В РБД данные и так «живут» в пространстве как точки. Это изначальное свойство РБД. Кортеж отношения из N атрибутов есть вектор с N компонентами, то есть точка N-мерного пространства. Вопрос трактовки, не более того. Вы этого не знали?
Знал. Но Вы говорите об одном отношении, а я говорю о всей БД. Возьмите любую конкретную БД из 100 таблиц и скажите сколько в ней размерностей (степеней свободы)? В РМД нельзя (ну в смысле, вопрос такой не стоит, а значит и ответа нет). А в КОМ не только можно, но это и была одна из главных целей. Чтобы вся БД рассматривалась как одно большое пространство, где живут данные.
Это не цель, достойная хоть 5 минут внимания, это всего лишь желание выдумать что-нибудь эдакое. Я таких «целей» — без ясно видимой теоретической и практической пользы — напридумываю хоть сто. А смысл?
Александр Савинов
mir
Размерность на имеет детализации. Если под ней не понимать что совсем другое. Вот вам пример: куб. Фигура имеет 3 измерения. Придумайте уровни детализации каждой размерности. Бессмыслица какая-то.
Вовсе нет. Если Вы знакомы с OLAP, то у не должно быть отторжения. Это одна из основ (многомерность БД и ее иерархичность).
Я-то с OLAP знаком, но вы неверно трактуете «иерархичность» измерений. Там это всего лишь смена единиц измерения, не боле того. Скажем, ось времени в единицах «день» можно заменить той же осью с единицей «неделя». Еще раз: ось логически та же, только единицы меняются. Это совсем не то же самое.
Александр Савинов
Представьте, что каждая точка на одной из сторон куба на самом деле объект с двумя собственными измерениями.
Не могу. Дайте пример из жизни. Потому что мой пример из жизни — куб как геометрическая фигура — не может вместо точек иметь таинственные объекты с таинственными собственными измерениями.

Александр Савинов
mir
В РМД проекция, агрегирование, логический вывод и без того существуют и успешно применяются без необходимости вводить предложенные вами ограничения.
Верно, но только вручную. Если я напишу для этого (правильный) запрос, то все будет работать.
Речь шла не об этом. Напомню, что вы сказали, что ваш подход позволит ввести «несколько важных механизмов» (см. список). Я говорю, что логически неверное утверждение, ибо эти механизмы уже есть.
Если вы хотели сказать что-то другое, выражайтесь строже и яснее. Или опять нужно «включить интуицию»?
И далее. Что значит «вручную»? Ваш подход не предполагает написания запросов? И они будут написаны не вручную?
Александр Савинов
А мы вводим базовые свойства и механизмы о которых будет знать сама СУБД.
До сих пор неясно, что же такое «не знает» РСУБД, что будет «знать» ваша СУБД.
Александр Савинов
mir
Александр Савинов
Наличие цикла означает бесконечную размерность
Размерность чего? Понятие размерности отношения известно, понятие размерности БД не определено (да и надо ли?). Поэтому данная фраза пока ничего для меня не означает.
Упрощенно, размерность это путь по ссылкам.
Ах вот оно что, вы используете общеизвестный термин с понятной всем семантикой, но приписываете ему совершенно новое, никому не понятное значение, никак не связанное с традиционным. Этак можно далеко зайти. Впрочем, при беглом просмотре вашей статьи на сайте, я заметил, что это ваш «конек». Полностью, причудливо и неожиданно, переопределены понятия «домен», «синтаксис», «семантика», «размерность».
Больше всего это напоминает программу на С++, в которой переопределены привычные операторы, скажем, «+» означает деление, а «*» означает вычитание. Читать ее невозможно.
Вы это специально делаете?
В любом случае, разговор с вами становится мало осмысленным, ибо нет уверенности в том, что вы имеете в виду под общепринятыми терминами. И конечно, ваша «размерность» никакой размерностью не является.

Александр Савинов
mir
Да-да, аргументы «я так считаю» и «я не хочу» являются сугубо технологическими и очень конструктивными.
Обычно для общих принципов доказательств не бывает. Кроме того, всегда есть личные предпочтения. Вы тоже свое мнение не подкрепляете сильно, ну и что.
Тогда совет: перемещайтесь на философские сайты, где личное мнение является аргументов в разговоре. Здесь у нас сайт технический, а с таким подходом к дискуссии среди технарей делать особо нечего.

Александр Савинов
mir
А по существу возражения есть? Вы сказали, что язык ассемблера непревзойден по выразительности. Это безграмотно (читайте определение выразительности языка). Я всего лишь констатировал данный факт. Или вы настаиваете на своем утверждении? Если нет, то не вижу причин обвинять меня в предвзятости.

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

Кстати, все еще жду доказательств того, что вас тут оппоненты грязно обругали. Я настаиваю.
16 дек 06, 12:02    [3545518]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Александр Савинов
U-gene
1) повтор - в РМД нет доступа к данным
А как же я их получаю? У меня название категории товара "дома". Я хочу найти какие-то связанные данные, скажем, кто эти товары покупал.
Ну Вы же прекрасно знаете как - пишете на реляционном языке запрос, отправляете СУБД, она строит план запроса. И далее обеспечивает уже действительно доступ к данным и выдачу их не как абстрактного реляционного отношения, но как вполне осязаемого резалтсета.
Содержание же резалтсета тем не менее есть в точности содержание реляционного отношения - результата преписанных операций.
Александр Савинов

Это кстати, официальная точка зрения, или Ваше личное предположение, что РМД не предоставляет доступа к данным. Я в том смысле, я могу это говорить другим людям, что все модели доступ к данным предоставляют, а вот РМД нет. Свойство у нее такое.
Официальная точка зрения ... А где искать официальную точку зрения на закон Ома? Тем не менее можно сослаться на Дейта, "Введение в с.б.д." , 7-е издание, гл. 3.2.
Александр Савинов
РМД это ассемблер в мире описания и манипулирования данными.
И да и нет.
Нет, потому что сама мысль о манипуляции данными путем абстрактного языка могла стать полезной лишь когда СУБД уже вооружены мощными средствами доступа к данным, индексами, алгоритмами сортировки/слияния, и проч. и проч.
Да, потому что РМД определяет конечно же лишь базовые абстрактные операции.
То есть это ассемблер достаточно таки продвинутого процессора:)
16 дек 06, 13:08    [3545581]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
шшшшшшшшш
Guest
mir
Александр Савинов
mir
Александр Савинов
А Вы не задумывались над тем, какова семантика циклов, какова их роль при моделировании и, собственно, нужны ли они?
Да. А вот у вас я вижу непонимание разницы между циклами связей между записями и циклами связей между отношениями. Вы по смыслу говорите о вреде циклических связей между записями, но предлагаете устранить связи между отношениями. Это как лечить головную боль усекновением головы.

Ну давайте обсудем эту проблему. Я говорю, что если в структуре таблиц циклов нет, то и между записями их не будет. Согласны?
Да, ровно в той же мере, как и усекновение головы приведет к исчезновению головной боли.

гм. Вернитесь к "решению" А.С. задачи о Генеалогическом дереве. Циклы в связях меж таблицами он "снял" (вынеся ПК), но вот циклы в генеалогии (между записями) - нет :0). Т.ч. одно - совершенно не связано со вторым. И вы рано соглашаетесь.

Лучше еще раз сформулируйте для себя - что такое циклы ссылок между записями. И что такое циклы ссылок между таблицами. И почему в некоторых головах наличиствует фобия циклических ссылок по записям. (тут еще вопрос- а всегда ли нужно с ними бороться -если например я моделирую некий объект с тавтологиями - то самоссылки вероятно не самое вредное. другой вопрос, что для механизмов поддержания ссылочной целостности РМД циклические ссылки по ключам представляют проблему (или могут ее представлять - смотря по тому, когда происходит проверка целостности внутри транзакции, определены ли ключи как ON DELETE RESTRICT). Т.е. проблема циклических ссылок в этом случае - проблема реализации механизма отслеживания целостности. Не более того. А нужна ли такая циклическая ссылка на деле - т.е. в моделируемом объекте, не нужна - это нас уже не интересует. Задрав штаны улепетываем от проблем инструмента (или собственных страхов) во все лопатки. Т.е. решение А.С. с размножением ПК для "снятия цыкла" решает возможно проблему инструмента (позволяет к примеру отработать удаление "закольцованной" ссылки (персона(сторона_пары)-брак-персона(ребенок)) вводя разрыв между таблицей-идентификатором и таблицей - сущностью, в силу чего можно удалить содержательную сущность, не трогая идентификатор, затем удалить сущности других таблиц, на которые ссылалась содержательная сущность, а затем, если потребуется, удалить и идентификатор, не указывающий ни на что содержательное) но не проблему моделируемого объекта. Не проще ли ввести пару деклараций модифицирующих поведение механизма проверки целостности или попросту позволяющих работать именно с такими случаями (удаление содержательной сущности поропсту означает ON DELETE SET NULL в определении вторичного ключа, если вы этого не поняли - т.к. "реферирующая сущность" - таблица ПК - не представлена значением в области "содержательных сущностей").
16 дек 06, 15:27    [3545808]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
ModelR
Александр Савинов

Это кстати, официальная точка зрения, или Ваше личное предположение, что РМД не предоставляет доступа к данным. Я в том смысле, я могу это говорить другим людям, что все модели доступ к данным предоставляют, а вот РМД нет. Свойство у нее такое.
Официальная точка зрения ... А где искать официальную точку зрения на закон Ома?

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

ModelR
Тем не менее можно сослаться на Дейта, "Введение в с.б.д." , 7-е издание, гл. 3.2.

Спасибо.
ModelR
Александр Савинов
РМД это ассемблер в мире описания и манипулирования данными.
И да и нет.
Нет, потому что сама мысль о манипуляции данными путем абстрактного языка могла стать полезной лишь когда СУБД уже вооружены мощными средствами доступа к данным, индексами, алгоритмами сортировки/слияния, и проч. и проч.
Да, потому что РМД определяет конечно же лишь базовые абстрактные операции.
То есть это ассемблер достаточно таки продвинутого процессора:)

Мне кажется что я понимаю. РМД не дает средств доступа, поскольку под таковыми понимаются низкоуровневые средства типа индексов, сортировки и т.п. Ну при такой трактовке этого термина все правильно, я согласен. Просто такое определение мне кажется не очень удачным (на сегодня конечно). Я считаю, что главными целями любой модели данных являются:
- средства представления данных
- средства доступа к данным
- средства манипулирования данными
(Может быть еще что-то - это неформально.) Например, если приходит документ, то мы ему присваиваем номер и кладем куда-то в ящик (средства представления). Если нам нужен документ, то применяем средства доступа. А если надо чего-то изменить, то применяем средства манипулирования (операции). Без средств доступа модель это черный ящик на самом деле. (Помните правило: нет доступа - нет данных.) В этом смысле средства доступа в РМД конечно есть, но они вырождены, т.е. этот вопрос не был главным при построении модели (в те времена это не было актуально). А вот средства манипулирования данными действительно очень мощные, я бы даже сказал, что слишком мощные для сейчас. Впрочем, я не спорю с определениями. Хозяин барин. Если авторы РМД выводят доступ за рамки модели, то это их право (потому я спросил откуда ветер дует). Мне легче, поскольку я как раз работаю над подходом, где доступ и представление это главные моменты, так что могу теперь обоснованно написать, что в РМД этого нет, а у меня есть.
16 дек 06, 15:31    [3545816]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
mir

Александр Савинов
mir
Размерность на имеет детализации. Если под ней не понимать что совсем другое. Вот вам пример: куб. Фигура имеет 3 измерения. Придумайте уровни детализации каждой размерности. Бессмыслица какая-то.
Вовсе нет. Если Вы знакомы с OLAP, то у не должно быть отторжения. Это одна из основ (многомерность БД и ее иерархичность).
Я-то с OLAP знаком, но вы неверно трактуете «иерархичность» измерений. Там это всего лишь смена единиц измерения, не боле того. Скажем, ось времени в единицах «день» можно заменить той же осью с единицей «неделя». Еще раз: ось логически та же, только единицы меняются. Это совсем не то же самое.
Александр Савинов
Представьте, что каждая точка на одной из сторон куба на самом деле объект с двумя собственными измерениями.
Не могу. Дайте пример из жизни. Потому что мой пример из жизни — куб как геометрическая фигура — не может вместо точек иметь таинственные объекты с таинственными собственными измерениями.

Я же привел совершенно конкретную схему. Подставить вместо куба таблицу Товары, а вместо третьего измерения таблицу Заказы. Товары ссылаются на Заказы (т.е. заказы состоят из нескольких товаров). Но сам заказ имеет свои собственные измерения. Здесь есть две проблемы:
1 неформальная. Это способность мыслить в терминах многомерных пространств.
2 формальная. Способность описать это точными средствами.
Вы пока на первом уровне, где я ничем не могу помочь. Это все равно, что пытаться объяснить, почему и как представлять данные отношениями.

mir

Александр Савинов
mir
Александр Савинов
Наличие цикла означает бесконечную размерность
Размерность чего? Понятие размерности отношения известно, понятие размерности БД не определено (да и надо ли?). Поэтому данная фраза пока ничего для меня не означает.
Упрощенно, размерность это путь по ссылкам.
Ах вот оно что, вы используете общеизвестный термин с понятной всем семантикой, но приписываете ему совершенно новое, никому не понятное значение, никак не связанное с традиционным.

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

mir

Александр Савинов
mir
Да-да, аргументы «я так считаю» и «я не хочу» являются сугубо технологическими и очень конструктивными.
Обычно для общих принципов доказательств не бывает. Кроме того, всегда есть личные предпочтения. Вы тоже свое мнение не подкрепляете сильно, ну и что.
Тогда совет: перемещайтесь на философские сайты, где личное мнение является аргументов в разговоре. Здесь у нас сайт технический, а с таким подходом к дискуссии среди технарей делать особо нечего.

Пока от Вас я не услышал ничего конструктивного: ни вопросов, ни ответов. Сформулируйте проблему: что Вас беспокоит. А потом продолжим.

mir

Кстати, все еще жду доказательств того, что вас тут оппоненты грязно обругали. Я настаиваю.

Перестаньте постоянно стучать ложкой по столу и чего-то от кого-то требовать. Вам никто ничего не должен. Если есть проблемы с пониманием, то попросите и Вам обязательно кто-то на форуме доступно все объяснит.

Итак, Ваша проблема состоит в том, что...
16 дек 06, 15:50    [3545842]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
клон ЧАЛА из Пскова
Guest
Еще раз подчеркиваю, okdoky, что Вы не до конца понимаете общую теорию баз данных, то есть основы идентификации (навигации, семантики). Еще раз обращаю внимание на простую и фундаментальную "часть" классической ОМД (shuklin не является ее сторонником, как Вы выразились, так как он не знаком с технологией баз данных в которой обычно реализуюется ОМД):
^obj(id)=ex
И опять Вы повторяете ошибку: даже "на уровне реализации" в ОМД используются идентификаторы, а не "указатели", а в РМД ничего, кроме "ключей" (при всех их "разновидностях") использовать нельзя (что значит "проще использовать" ?).

Про "фокусы" не стоит говорить, мод. В отношении не может быть дубликатов кортежей без всяких "псевдостолбцов".

И снова фундаментально заблуждается mir про роль "ключей" в РМД. И это после чтения Дейта (см. второй абзац на стр. 539 и п.9 на стр. 362 в 8-м издании "Введение в системы баз данных").
Опять про "ограничения целостности" без учета семантики (без обеспечения связей между сущностями). "Стеснительность", с которой mir и другие "специалисты" по РМД выдают объективную потребность представления связей между сущностями за "ограничения целостности", меня умиляет. А для того, чтобы "связать сущности", их нужно идентифицировать, и т.д. и т.п. (типа неохота связывать сущности "целыми кортежами", которые, напомню, уникальны без всяких "ключей").

Да, Александр Савинов, обычная инженерия. Хорошо реализуемая в MUMPS.
^obj(id)=ex
и, при желании, можно "типизировать" (я приводил пример объекта День, для которого идентификатор экземпляров может представлять собой восьмизначное целое число, и другие примеры). И про имена правильно. В ОМД идентификаторы есть не только у экземпляров объектов, но и у самих объектов и их характеристик (так что можно сколько угодно "менять имена классов", okdoky, то есть объектов, так как в классической ОМД нет никаких "классов").

Нет, U-gene, ни одна из моих "претензий к РМД" не может "отпасть", так как все они тщательно аргументированы, потому что я не "воинствующий противник РМД", а человек, изучивший РМД. Что касается "реализаций", как я уже говорил, после MS SQL 6.5 и Oracle 8i я больше не интересуюсь "Р"СУБД, так как ничего от РМД там уже никогда не появится.

Откуда у ModelR такие "сомнения" о "статистике запросов"? В системах класса ERP, например, "запросы" на поиск конкретного экземпляра или экземпляров другого объекта, связанных с данным экземпляром (типа "записи документа") "идут" постоянно, и сотавляют не менее 90% всех "запросов". И в ОСУБД эти "запросы" не программируются, как и подавляющее большинство из оставшихся 10%.

P.S.
Давайте, ребята, "блокируйте" еще и Псков. И обсуждайте "ключи" исключительно в удобном (можете даже назвать его ключевым) для вас ключе. Мифических "ограничений" бессмысленной "целостности". Миру с глюком, наверное, просто не дано разобраться в теории баз данных, как, впрочем, и в "реляционной теории". Но можно еще попробовать поотвечать себе даже не на вопрос
"Может ли данный объект существовать не зависимо от другого конкретного объекта?"
а на более "простой" вопрос
"Может ли сущность не существовать?".
17 дек 06, 12:28    [3546992]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
Александр Савинов
Пусть есть последовательность таблиц t1, t2, ..., tN, где каждая следующая ссылается на предыдущую с помощью ключа (сложного).
Проблема 1 (проекция). Как найти записи из t1, на которые ссылаются через промежуточные таблицы выбранные записи из tN?
Проблема 2 (де-проекция). Как найти записи из tN, которые ссылаются через промежуточные таблицы на выбранные записи из t1

t1->t2->t3 (id - PK, tn_id - FK)
1:
select t1.* from t1 where t2_id in
  (select id from t2 where t3_id in
    (select id from t3 where ...))

t1(t2_id=t2(t3_id=t3(...).id).id).*

2:
select t3.* from t3 where id in
  (select t3_id from t2 where id in
    (select t2_id from t1 where ...))

t3(t2(t1(...).t2_id).t3_id).*
Видно, что точечная запись эквивалентна SQL (но SQL в общем случае нагляднее - структурированней - это ведь Sql !)
18 дек 06, 11:50    [3549064]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

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

t1->t2->t3 (id - PK, tn_id - FK)
1:
select t1.* from t1 where t2_id in
  (select id from t2 where t3_id in
    (select id from t3 where ...))

t1(t2_id=t2(t3_id=t3(...).id).id).*

2:
select t3.* from t3 where id in
  (select t3_id from t2 where id in
    (select t2_id from t1 where ...))

t3(t2(t1(...).t2_id).t3_id).*
Видно, что точечная запись эквивалентна SQL (но SQL в общем случае нагляднее - структурированней - это ведь Sql !)

Я все-таки придерживаюсь мнения, что точечная запись и SQL это разные вещи, а потому они не конкуретны и при определенных усилиях их можно было даже совместить. Но в данном случае SQL действительно весьма нагляден. Но это из-за того, что используются простые идентификаторы. Я не уверен, будет ли запись столь же проста и понятна в общем случае ключа из двух и более колонок. Похоже, что вложенный IN SELECT вообще в этом случае не работает? В основе же точечной записи лежит предположение, что структура ссылок эффективно скрывается, т.е. связь между таблицами это забота СУБД, а не наша.
18 дек 06, 12:29    [3549349]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
Александр Савинов
В основе же точечной записи лежит предположение, что структура ссылок эффективно скрывается, т.е. связь между таблицами это забота СУБД, а не наша.

Этот пример показывает что:
1 связывать сущности в РСУБД надо простыми ссылками
2 SQL нагляднее любой другой нотации (к сожалению !)
3 все ссылки надо указывать явно, а не перекладывать их на СУБД (из-за неоднозначности)
18 дек 06, 14:30    [3550302]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
мод
Александр Савинов
В основе же точечной записи лежит предположение, что структура ссылок эффективно скрывается, т.е. связь между таблицами это забота СУБД, а не наша.

Этот пример показывает что:
1 связывать сущности в РСУБД надо простыми ссылками
2 SQL нагляднее любой другой нотации (к сожалению !)

Почему к сожалению?

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

мод
3 все ссылки надо указывать явно, а не перекладывать их на СУБД (из-за неоднозначности)

Мне пришло в голову очень простое решение для случаая сложный ключей (из нескольких полей):

1. Проекция. Здесь поля ключей пишутся в квадратных скобках, а стрелка это собственно переход:
t3->[k1,k2,...]->[k1,k2,...]->t1.[f1,f2]

2. Де-проекция. То же самое, только инвертируем стрелки:
t1<-[k1,k2,...]<-[k1,k2,...]<-t3.[f1,f2] 

В общем случае можем их комбинировать:
t1<-[k1,k2,...]<-[k1,k2,...]<-t3->[k1,k2,...]->[k1,k2,...]->t6.[f1,f2] 
Здесь в таблице t3 происходит смена направления.
18 дек 06, 15:41    [3550813]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Александр Савинов
SQL это как Бейсик, который как питон


Который как Perl, который как Java ...
Пристрастие к "красивостям" в технической дискуссии вас погубит
18 дек 06, 16:01    [3550972]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
antimod
Guest
мод
Александр Савинов
Пусть есть последовательность таблиц t1, t2, ..., tN, где каждая следующая ссылается на предыдущую с помощью ключа (сложного).
Проблема 1 (проекция). Как найти записи из t1, на которые ссылаются через промежуточные таблицы выбранные записи из tN?
Проблема 2 (де-проекция). Как найти записи из tN, которые ссылаются через промежуточные таблицы на выбранные записи из t1

t1->t2->t3 (id - PK, tn_id - FK)
1:
select t1.* from t1 where t2_id in
  (select id from t2 where t3_id in
    (select id from t3 where ...))

t1(t2_id=t2(t3_id=t3(...).id).id).*

2:
select t3.* from t3 where id in
  (select t3_id from t2 where id in
    (select t2_id from t1 where ...))

t3(t2(t1(...).t2_id).t3_id).*
Видно, что точечная запись эквивалентна SQL (но SQL в общем случае нагляднее - структурированней - это ведь Sql !)

А если так
1:
t1.t2.t3
2:
t1(t2(t3))
18 дек 06, 16:11    [3551064]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
antimod
А если так
1:
t1.t2.t3
2:
t1(t2(t3))

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

А вообще, если говорить о логической навигации, то есть два средства:
- с помощью таблиц (имен узлов графа)
- с помощью связей (имен ребер, в случае РМД это ключи)
Но в точках разворота (между 1 и 2) надо оба имени указывать.
Какой способ лучше зависит от многих факторов, главным образом от области применеия.
18 дек 06, 16:38    [3551296]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
клон ЧАЛА из Пскова
В системах класса ERP, например, "запросы" на поиск конкретного экземпляра или экземпляров другого объекта, связанных с данным экземпляром (типа "записи документа") "идут" постоянно, и сотавляют не менее 90% всех "запросов".
Дык о чем это говорит?
1)что программирование в стиле перебора экземпляров генерит тучу запросов на ровном месте.
2)что запрос, действительно делающий серьезную работу не требуется выполнять ежесекудно.
клон ЧАЛА из Пскова

Но можно еще попробовать поотвечать себе даже не на вопрос
"Может ли данный объект существовать не зависимо от другого конкретного объекта?"
а на более "простой" вопрос
"Может ли сущность не существовать?".
А также, если мы не знаем, что есть сферический конь в вакууме, помешает ли это нам присвоить идентификаторы его экземплярам ? а если не мешает, то выражают ли сами по себе идентификаторы хоть что-то, связанное с объектом? - ну хотя бы факт существования?
18 дек 06, 17:24    [3551639]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 17 18 19 20 21 [22] 23 24 25 26 .. 31   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить