Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7 8   вперед  Ctrl      все
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

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

В общем в сухом остатке от Вас остается
1) Непонимание понятия модели данных. В качестве определниий предлагалось несколько формулировок, начиная от "всё, что поможет описать данные" до "воблы на веревочках"
2) Постояннаяя путаница межу инфологическими и даталогическими моделями.
3) Постоянная путаница между даталогическими моделями и системами, реализующими эти модели
4) Постоянная путаница меду записью формальных операций моделей данных и конструкциями используемого языка программирования.
5)Незнание предмета критики (РМД), о чём свидетельствуют
а)навязчивые попытки навязать РМД(модели даталогической) роль инфологической модели
б) незнание базовых операций - попытка обозвать выборку проекцией, попытка смешать соединение и декартово произведение.
в)попытки связать JOINы с ключевыми полями
г)попытка разделить ключи РМД на суррогатные ( это которые "привинченные к РМД сбоку", "нетипизированные", имеющие "сильную поддержку со стороны системы") и несуррогатные("толстые")
д) непонимание роли доменов в РМД
е) и, в конце концов, "РМД - это не отношение!"

При этом Вы постоянно пытаетесь обвинить оппнентов в религиозноcти, ограниченности, придумывании пакостей, пытяетесь представить людей, всего лишь понимающих РМД (и Ваше незнание её), как секту, сслыетесь на фирмы, Ленина, воблу, пользователей, пространства, смысл и т.п. странные вещи.

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

Друг мой. я честно попыталя прочесть Ваше"Formal Introduction into the Concept-Oriented Data Model".... но буквально сразу же я наткнулся на фразу

A two-level concept-oriented model consists of one root element R which physically includes a set of concept elements ... where each concept physically includes a set of item elements ... .(я убрал определние множеств). Друг мой объясните мне , что в Formal Introduction ... делает слово physically? Далее это physically(не иначе как веревочками от воблы) преследовало меня везде и далее... Physical inclusion is supposed to be persistent and cannot be changed during life cycle of elements. Друг мой, what is physical inclusion supported with? Системой что ли? Это что у Вас, такое вот Formal Introduction of модели и системы? и где же тут операции то? Что Вы даете взамен РМД?

И еще я посмотрел Frequently Asked Questions on the Concept-Oriented Data Model
Перлы, котрые сразу же бросаются в глаза
1) Any model has a physical structure which is defined by physical inclusions of its elements into collections. Это что у Вас что, мантра для внушабельных индиотов - типа если по аглицки и с умным видом, то значит так оно и есть и это истина? Друг мой, "но я же не индиот" (с) С.Лем
2)Concept is an analog of table or relation in the relational data model and class in the object-oriented paradigm. Друг мой, по вашему "отношение",это нечто, что является эквивалентом "класса"? Вперед!
3) In the relational model it is analogous to cascade delete operation. Друг мой, Вы так много интересных вещей находите в РМД!
4) What happens if the reference count gets too low? В это о чём? Это тоже Data Model?
5) The system looks after the usage of items by counting how many each item is referenced from its subitems. (The bottom concept is not taken into account since it is a formal element of the model.) Что, и это тоже?

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

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

В любом случае Вам и всем - С Новым Годом :) Удачи :)
31 дек 06, 01:22    [3600941]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

Откуда:
Сообщений: 349
mir:
Взглянул на свой предыдущий пост и не удержался, решил исправиться. Для понимания точность нужна не только в терминологии.
okdoky
Надеюсь вы знаете XML. Иерархические структуры в нем это отображение JOIN которые реляционщики вынуждены применять при переходе от атрибутов одних таблиц к другим. Да, на месте X и Y могут находится как объектные переменные (обозначающие множество объектов), так и то, что называется атрибутом в РМ.
Пример двух отношений R и R1
R(X, Y, A)
  x, y, a
  x, y1,a
R1(Y, Z, B)
   y, 1, b
   y1,2, b
   y2,3, b
Если я правильно догадываюсь, результатом R1 SEMIJOIN R будет таблица R2(Y, Z, B) со значениями Y, одинаковыми в обеих таблицах и полученная из NATURAL JOIN для R и R1.
R2(Y, Z, B)
   y, 1, b
   y1,2, b

Это не совсем то, что я просил изобразить для X/Y из языка XPath. Вы действительно оперируете множествами отношений. В иерархических моделях реализованных на Zigzag и XML-СУБД имена отношений отсутствуют вообще и используются переменные множества объектов. Те же данные из R и R1 можно в XML представить так
<X ID="x">
  <A>
    a
  </A>
  <Y ID="y">
    <Z>
      1
    </Z>
    <B>
      b
    </B>
  </Y>
  <Y ID="y1">
    <Z>
      2
    </Z>
    <B>
      b
    </B>
  </Y>
</X>
Возможно, это менее наглядно чем в табличном виде. Судить не берусь. Но это лучше отражает реальные связи. Идентификаторы ID в XML можно не использовать вообще. То есть ограничится некими внутренними ссылками, известными самой системе. Иногда, когда множество взаимосвязанных таблиц со сложной структурой (записи одной таблицы зависят от записей другой или вложены в нее) XML может даже оказаться удобнее. Особенно конечно при транспортировке данных. Операция X/Y для таких данных даст нам узлы с ID равным y y1. Для реляционной модели это значения атрибута Y в таблице R1.

Настоятельно рекомендую изучить за праздники XPath (и XQuery). Собственно, на месте X и Y в выражении X/Y могут находиться переменные, представляющие множества объектов (значений) сразу из нескольких атрибутов, то есть объединения UNION. Получить все атрибуты Y можно используя что то типа
[FIXED]select * from X/Y [/FIXED]
или
[FIXED]for $y in X/Y
return $y/*[/FIXED]
Хоть я и не дождался от вас выражения на Tutorial D, согласитесь, это значительно проще, чем в РМ. Можно обойтись без операций JOIN, а значит и самой РМД. При выдаче полной информации об Y Вам не придется вспоминать все нормализованные таблицы (отношения) в которых находятся объекты y, y1. Ведь они могут находится не только в R1. Не правда ли?
31 дек 06, 09:58    [3601041]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
4321ё
Guest
Пьяный Лох
А может забанить дурака, а?
зачем же.
надо же наконетц пыньять, чито двигало например лысенкой. А тут такой заметчательный экземпляр для изучения.
Чистосердечный и фанатичный.


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



я вот думаю, шо могу проздреть унутреннюю единздвенно-верноздь учения. А ходь бы и учения АликСавинова. У миня с эттим лихко. Я даже кличу это сематической инвариантостью (теорий ли, моделей ли - не суть важно). Проблема лишь в том, шо я могу прозреть внудреннюю верноздь множества учений. Видимо в отличь от АдекСавинова. А уж исходя из этой точки мне интерездно, что же на самом деле может мне дасть модель, кроме деклакакции своей единтсвенна-верности. А вот с энтим, мне кааца, у АСавинова пока туго. Кликните, как сыщете какой-нито явный бонус
31 дек 06, 21:41    [3601570]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

Откуда:
Сообщений: 349
okdoky
Хоть я и не дождался от вас выражения на Tutorial D, согласитесь, это значительно проще, чем в РМ. Можно обойтись без операций JOIN, а значит и самой РМД. При выдаче полной информации об Y Вам не придется вспоминать все нормализованные таблицы (отношения) в которых находятся объекты y, y1. Ведь они могут находится не только в R1.
Это было сказано в прядке легкого предновогоднего флейма, с целью отвлечь нездоровое внимание от Александра Савинова и его концептно-ориентированной модели. Ту задачу, которую я предлагал, можно решить в рамках РМД. Для этого достаточно использовать имена отношений, совпадающие или схожие с именами атрибутов X, Y, то есть X(IDX, Y, A), Y(IDY, Z, B). Запрос соответствующий
select * from X/Y 
на SQL будет выглядеть
select * from Y where IDY in (select Y from X)
Пока все просто. Сложнее с SQL или Tutorial D будет для более сложных запросов, которые в XPath например могут выглядеть так X/Y/Z[M/N/K>='k'] или X//*[Z=1]. В последнем случае осуществляется переход ко всем атрибутам, как-либо косвенно связанным с X (не только непосредственно, как Y). Мы не обязаны помнить не только имена отношений, но и имена атрибутов.

Собственно изначально-то речь шла об утверждении
mir
Имена переменных отношений -- нужны.
, по сути об единственности и неповторимости РМД. Уже существуют модели данных не менее строго формализованные, чем РМД. Думаю будет интересно, особенно mir, U-gene, ModelR посмотреть на следующую альтернативу. Здесь также используются переменные, но не отношений…
4 янв 07, 13:07    [3606653]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
okdoky
Собственно изначально-то речь шла об утверждении mir
mir
Имена переменных отношений -- нужны.

, по сути об единственности и неповторимости РМД.

?????

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

Не понятно? Тогда пример - okdoky только что написал...
okdoky
Для этого достаточно использовать имена отношений
...и, по сути, сказал, что РМД является достаточной.

okdoky
Уже существуют модели данных не менее строго формализованные, чем РМД…
... Почитал. Написано по англицки и с умным видом . :) Во всяком случае люди ни с чем не борются и какашками бросаться не пытаются. Нашел проекцию и итераторы. Позабавил аппендикс XML Query Data Model содержащий единственную ссылку...... на себя. :) Нельзя не согласится с содержащейся в конце его примечанием редактора: This section needs to be completed.
4 янв 07, 15:40    [3607081]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Александр Савинов
Ликующий народ (хлеба и зрелищ): Gluk (Kazan), 7


Народ безмолствует

P.S. Я буду молчаливой галюцинацией (с)
6 янв 07, 08:28    [3610480]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
mir
Для типовых задач БД пока лучше РМД ничего не предложили. Вот и все.

Предложили. Или по вашему оракл это только РМД ?
9 янв 07, 11:19    [3615162]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

Откуда:
Сообщений: 349
U-gene
РМД является достаточной.
Достаточность, это слабый аргумент. Кто-то, кажется из дискутирующих, заметил, что Ассемблер тоже достаточен.
U-gene
Позабавил аппендикс XML Query Data Model содержащий единственную ссылку...... на себя. :)
Из моего примера можно понять суть XML-модели данных на основе РМД. Есть такая простенькая ссылка http://www.w3.org/XML/Datamodel.html Здесь интересен пример, как на основе иерархической структуры можно представить сеть, используя атрибут href
<p>
<q id="x7">The first q</q>
<q id="x8">The second q</q>
<q href="#x7">The third q</q>
</p>
9 янв 07, 13:58    [3616277]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
okdoky
Есть такая простенькая ссылка
Точнее будет http://www.w3.org/TR/xpath-datamodel/, но увы, уже не такая простенькая.
9 янв 07, 14:43    [3616646]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Все таки интересно, чем люди читают (или думают?). Берем пару слов из контекста и понимаем их как хотим. Например
U-gene написал
Не понятно? Тогда пример - okdoky только что написал... "Для этого достаточно использовать имена отношений" ...и, по сути, сказал, что РМД является достаточной.
okdoky ответил
U-gene
РМД является достаточной.

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

okdoky раньше написал
Уже существуют модели данных не менее строго формализованные, чем РМД. Думаю будет интересно, особенно mir, U-gene, ModelR посмотреть на следующую альтернативу

okdoky пишет теперь
Из моего примера можно понять суть XML-модели данных на основе РМД.
Друг мой, а Вы не находите (ну так, на минутку) что между "альтернатива" и "на основе" есть некая разница, заключающаяся в том, что первое подразумевает отказ, а второе - использование. То есть Вы сами сначала определитесь, чего же вы собсно доказывать хотите, а потом планомерно об этом пишит. И на всякий случАй хочу повторить - я не считаю, что РМД является едиственно возможной модлью данных.
9 янв 07, 16:15    [3617257]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

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

Не буду спорить (пока) с аргументом, что РМД достаточна. Тем более, что он скорее мой, чем ваш (по вашему же предыдущему посланию). Хочу только добавить. Все, что вы изобразите в реляционном виде легко можно представить в XML. А вот обратное может оказаться значительно сложнее. Думаю вам придется покряхтеть даже над таким простым примером:
<операция>
  <елемент id="1">2</елемент>
  <елемент id="2">2</елемент>
  <елемент id="3">2</елемент>
  <сложить>
    <умножить><елемент href="#1"/><елемент href="#2"></умножить>
    <умножить><елемент href="#2"/><елемент href="#3"></умножить>
  </сложить>
</операция>
9 янв 07, 17:51    [3617943]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Ага, легко заходит но туго выходит.
Сравните SQL и XQuery.
Чтобы определить XQuery (все еще Proposed Recommendation ), сначала приходится определить вышеупомянутую модель данных для XML, затем XPath, не забыть еще XML Schema...

А в принципе отображение непосредственно диктуется той же спецификацией http://www.w3.org/TR/xpath-datamodel/, описывющей конечное число сущностей, каждая с конечным числом атрибутов, каждый из которых есть либо элементарный тип либо список сущностей. Но в чем смысл этого упражнения?
9 янв 07, 19:03    [3618250]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Присоединяюсь - в чем же смысл этого упражнения?

Ну изобразили Вы эту штуку
<операция>
<елемент id="1">2</елемент>
<елемент id="2">2</елемент>
<елемент id="3">2</елемент>
<сложить>
<умножить><елемент href="#1"/><елемент href="#2"></умножить>
<умножить><елемент href="#2"/><елемент href="#3"></умножить>
</сложить>
</операция>
Что Вы с ней дальше то делать будете? Какие Вы к ней операции примените? Зачем Вам так нужно изображать банальное выражение? Смысл этого?

Опять же - примерчик то неудачный:) Есть три переменные и мы делаем id1*id2+id2*id3? Так это скаляры - к РМД это вообще никакого отношения не имеет :). А если Вам нужно как это будет выглядет в системе, реализующей РМД....то скорее всего так, как я написал. Но опять же - эта возможность системы не имеет никакго отношения к (т.е ортгональна) РМД и чем больше таких ортогональных возможностей будет, тем лучше будет нам.

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

Простой пример. Существует арифметическая операция сложения х+у . Я ее записал, как она отображается в математике. Но это же не значит, что в языке, реализующем математику я буду пользоваться только простыми целочисленными переменными и что в языке я смогу использовать опреацию сложения только в виде а+b (где a и b простые целочисленные переменные). Я же могу написать object1.ref.a + object2.method_b() и это никоим образом не нарушит арифметику. Почему? Да потому что все эти ссылки, методы, иерархии и т.п. вещи - все это конструкции языка системы, которые ортогональны арифметике. Ведь когда Страуструп создавал С++ , он же не писал, что де арифметика какая то не такая! Ведь для С++ никто не выдумывал каких то новых операций вместо сложения, умножения и т.п.! Потому что object1.ref.a и object2.method_b() это в конечном итоге всего лишь имена переменных, содержащих значения, а как система с этими именами разбирается, что она вытворяет, что бы доступ к этим значениям получить - это её личное дело, которое к арифметике никакого отношения не имеет.

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

               c-d
/
корень a-b-e-f-g
\
h


то система должна выполнить сдедующий запрос

SELECT c.d, SUM(e.f.g)
FROM a.b
WHERE h...

именно потому, что она реализует РМД и рассматривает ссылочную(с точки зрения пользователя) конструкцию "a.b" как имя отношения, а ссылочные (с той же точки зрения) конcтрукции "с.d", "e.f.g", "h" как имена атрибутов этого отношения. Как она с этими конструкциями будет разбираться, как она будет эти отношения сторить - это ее личное дело, которое к РМД никакого отношения не имеет. Всё это ортогонально РМД.
9 янв 07, 21:33    [3618589]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
U-gene
О том то и речь, что для того, что бы иметь в системе сложные структуры (иерархии, сети), что бы пользовать в системе ссылки никакие модели данных вообще не нужны. Всё это ортгонально РМД. То есть Вы можете изображать модель предметной области используя подходящие языковые конструкции системы, а для доступа к данным Вы можете продлжать пользоваться РМД.

Действительно, с помощью РМД можно смоделировать любые сложные структуры. Но это означает, что обработка этих структур перекладывается на приложение, а цель в том, чтобы этим занималась СУБД, а это в свою очередь означает, что СУБД должна поддерживать сложные структуры и ортогональность не катит.
10 янв 07, 10:14    [3619519]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Для тех, кто в танке - переписал последние предложения

...То же самое и РМД. Если в ней мы манипулируем с отношением R имеющим атрибут a, то это вовсе не значит, что в реализующей её СУБД должны существовать только таблицеподобные переменные с колоночками :). Это примитивный подход - типа как первые языки программирования. Язык СУБД, реализующей РМД, может описывать сложные струкутры использовать ссылки, изобажать иерархии и сети. Это значит, что если (например) описано дерево вида


c-d
/
корень a-b-e-f-g
\
h

то СУБД должна выполнить (например) сдедующий запрос

SELECT c.d, SUM(e.f.g)
FROM a.b
WHERE h...

именно потому, что она (эта СУБД) реализует РМД и рассматривает ссылочную(с точки зрения пользователя) конструкцию "a.b" как имя отношения, а ссылочные (с той же точки зрения) конcтрукции "с.d", "e.f.g", "h" как имена атрибутов этого отношения. Как она (СУБД) с этими конструкциями будет разбираться, как она будет эти отношения строить - это ее личное дело, которое к РМД никакого отношения не имеет. Всё это ортогонально РМД.
10 янв 07, 11:27    [3620027]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
U-gene
она (эта СУБД) реализует РМД

РМД как и любая другая МД нужна пользователю, а не СУБД. Если пользователь описывает иерархию, то для него существует иерархическая МД и никакая другая и он хочет чтобы СУБД поддерживала именно эту МД.
10 янв 07, 12:59    [3620772]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

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

Вы, очевидно, ездиете на формуле горения и питаетесь циклом Кребса. Я же предпочитаю машины и колбасу В общем, не знаю, что Вам нужно, но мне, как пользователю, нужна именно система постоянного хранения данных, где я могу описывать эти данные как мне удобно и оперировать ими понятным мне образом.
10 янв 07, 13:57    [3621283]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

Откуда:
Сообщений: 349
ModelR
Ага, легко заходит но туго выходит.
Сравните SQL и XQuery.
Чтобы определить XQuery (все еще Proposed Recommendation ), сначала приходится определить вышеупомянутую модель данных для XML, затем XPath, не забыть еще XML Schema...

А в принципе отображение непосредственно диктуется той же спецификацией http://www.w3.org/TR/xpath-datamodel/, описывющей конечное число сущностей, каждая с конечным числом атрибутов, каждый из которых есть либо элементарный тип либо список сущностей. Но в чем смысл этого упражнения?
Зачем так загонять себя. Чтобы понять особенности XML-данных достаточно той простой ссылки, которую я привел. Если вдаваться в тонкости XPath. Модель данных, которой он может оперировать, во многом зависит от реализации. Можно подключить даже РМ. Но тогда, как я уже демонстрировал ранее, потребуется совпадение имен отношений атрибутам других (внешних) отношений. Либо предварительно использовать NATURAL JOIN всех отношений включающих атрибуты перечисленные в XPath.
10 янв 07, 14:04    [3621345]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

Откуда:
Сообщений: 349
U-gene
...То же самое и РМД. Если в ней мы манипулируем с отношением R имеющим атрибут a, то это вовсе не значит, что в реализующей её СУБД должны существовать только таблицеподобные переменные с колоночками :)…. Как она (СУБД) с этими конструкциями будет разбираться, как она будет эти отношения строить - это ее личное дело, которое к РМД никакого отношения не имеет. Всё это ортогонально РМД.
Вам mod правильно заметил, СУБД (ее физический уровень) должна соответствовать модели данных (логическому уровню) для которой она предназначена. Почему? Подумайте сами. Поэтому и приходится делить СУБД на реляционные, иерархические (XML, MUMPS) и т.п. Или вы говорите о какой-то абстрактной объектно-реляционно-иерархической СУБД? Которая позволяет оперировать ортогональными РМД моделями . Почему-же они обязательно должны быть ортогональными? Вспомните для примера ОРСУБД...
10 янв 07, 14:20    [3621461]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
U-gene
мне, как пользователю, нужна именно система постоянного хранения данных, где я могу описывать эти данные как мне удобно и оперировать ими понятным мне образом.

Ага, это называется DDL и DML. Опишите плиз ваш пример понятным вам образом.
10 янв 07, 15:00    [3621780]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
мод
Опишите плиз ваш пример понятным вам образом.
Уже два года как. Там и пример есть и как оно работает.

okdoky
Или вы говорите о какой-то абстрактной объектно-реляционно-иерархической СУБД? Которая позволяет оперировать ортогональными РМД моделями.

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

И почему абстрактная? Для меня вполне конкретная Обоснование есть, язык по мотивам тоже есть, сейчас транслятор пишется.....в общем это уже вопрос уже не принципиальный, а только времени и денег.

К сообщению приложен файл. Размер - 0Kb
10 янв 07, 15:59    [3622244]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
U-gene
Там и пример есть и как оно работает.

Вы привели схему данных и пример DML к ней, осталось привести DDL для полноты картины, если не трудно.
U-gene
Надо говорить так - "СУБД которая реализует РМД, является объектно-ориентированной и позволяет описывать иерархии".

Если СУБД позволяет описывать иерархии, то она по определению реализует иерархическую МД.
См. IMS, Oracle
U-gene
Иерархии, сети, OO - это конечно очень хорошо и очень нужно, но это все языковые вещи

Ага, это DDL у них такой. А МД какая при этом (уж всяко не РМД)?
11 янв 07, 10:09    [3625024]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
мод
Если СУБД позволяет описывать иерархии, то она по определению реализует иерархическую МД.
См. ... Oracle


Уточните, где именно надо смотреть Oracle ?
тынц, если можно
11 янв 07, 10:37    [3625220]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
мод
Вы привели схему данных и пример DML к ней, осталось привести DDL для полноты картины, если не трудно.


Вы это о чём? О картинке? Так это просто скриншот парсера с небольшим кусочком примера, который полностью рассматривается в статье, где есть и DDL и DML.

мод
Если СУБД позволяет описывать иерархии, то она по определению реализует иерархическую МД. См. IMS, Oracle


И слава Богу.

мод
Ага, это DDL у них такой. А МД какая при этом (уж всяко не РМД)?


Попробуйте понять этот пост. Скажите, если система гаранирует, что она работает именно описанным там образом, и пользователь может быть уверен, что описав приведенную там иерархию, он сразу же сможет работать с данными, представленными в виде приведенного там отношенния - эта система иерархическая или реляционная? Что, в РМД прописано, что данные должны быть представлены в виде отношений явно пользователем, и не могут быть представлены в виде отношения системой на основании какого то другого (иерархического) описания? Существует стереотип: "РМД - это только явнооппределяемые таблицеподобные переменные с колоночками" или "если есть иерарахия, то это всяко не РМД", но ИМХО это только стереотип.
11 янв 07, 11:05    [3625462]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
мод
Если СУБД позволяет описывать иерархии, то она по определению реализует иерархическую МД. См. IMS, Oracle
О, и какой номер у ORA-xxxxx Hierarhy violated ?
11 янв 07, 11:54    [3625959]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить