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

Nested tables - типичная иерархия
11 янв 07, 11:59    [3626012]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
U-gene
Вы это о чём?

Ну там где вы дерево рисовали
c-d /корень a-b-e-f-g \ h
U-gene

Что, в РМД прописано, что данные должны быть представлены в виде отношений явно пользователем, и не могут быть представлены в виде отношения системой на основании какого то другого (иерархического) описания?

Именно так и прописано, а как там система это представляет - никого не интересует (физический уровень понимаешь).
Если пользователь мыслит отношениями- это РМД, если иерархиями - никакой РМД нет.
11 янв 07, 12:12    [3626122]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
мод
Gluk (Kazan)
Уточните, где именно надо смотреть Oracle ?
тынц, если можно

Nested tables - типичная иерархия


Мы уже говорили об этом. Я просил дать ссылку на документ, в котором Oracle относится к иерархическим БД. Ваши собственные измыления на эту тему малоинтересны.
11 янв 07, 12:16    [3626179]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
ModelR
и какой номер у ORA-xxxxx Hierarhy violated ?

Извините, не понял. Соственно я просто имелввиду nested tables.
11 янв 07, 12:17    [3626182]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
Gluk (Kazan)
Я просил дать ссылку на документ, в котором Oracle относится к иерархическим БД. Ваши собственные измыления на эту тему малоинтересны.

Вам шашечки или ехать ? Oracle никуда не относится. Oracle это Oracle.
11 янв 07, 12:19    [3626201]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
мод
Gluk (Kazan)
Я просил дать ссылку на документ, в котором Oracle относится к иерархическим БД. Ваши собственные измыления на эту тему малоинтересны.

Вам шашечки или ехать ? Oracle никуда не относится. Oracle это Oracle.


Вы используете собственную терминологию, способную ввести других в заблуждение.
Это ... несколько неудобно

Как работать с иерархиями в Oracle я знаю. И как БЕЗ Oracle тоже.
Способность работать с иерархиями не делает БД иерархической
11 янв 07, 12:36    [3626361]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
Gluk (Kazan)
Вы используете собственную терминологию, способную ввести других в заблуждение.

Почему собственную ?
Есть три МД: иерархическая, сетевая, реляционная и их гибриды.
Конкретная СУБД может реализовывать все или некоторые из них. Как при этом называть эту СУБД - вопрос десятый.
11 янв 07, 13:04    [3626589]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

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

Вы это о чём?
Ну там где вы дерево рисовали
c-d /корень a-b-e-f-g \ h
Эта :) То есть по-Вашему - это дерево - это я пример DML привел? Всё таки у Вас действительно то ли с терминами что-то не так, то ли с их применением. Где Вы в изображениии дерева DML то нашли?

мод
Если пользователь мыслит отношениями- это РМД, если иерархиями - никакой РМД нет.
И что дальше?. Раньше я задал Вам вопрос
Скажите, если система гаранирует, что она работает именно описанным там образом, и пользователь может быть уверен, что описав приведенную там иерархию, он сразу же сможет работать с данными, представленными в виде приведенного там отношенния - эта система иерархическая или реляционная?
Давайте я его перефразирую, что бы понятней было. Что мешает пользователю, определив некое дерево (мысля при этом конечно иерархиями - например a.b.c.d), рассматирать эти же данные как отношения (мысля конечно отношениями - например отношением "a.b" с атрибутом "c.d") при условии , что система такой ход мысли поддерживает. Такая система - она иерархическая или реляционная?
11 янв 07, 13:24    [3626763]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
U-gene
Эта :) То есть по-Вашему - это дерево - это я пример DML привел?

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

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

U-gene

Раньше я задал Вам вопрос: система иерархическая или реляционная? Давайте я его перефразирую, что бы понятней было. Что мешает пользователю, определив некое дерево (мысля при этом конечно иерархиями - например a.b.c.d), рассматирать эти же данные как отношения (мысля конечно отношениями - например отношением "a.b" с атрибутом "c.d") при условии , что система такой ход мысли поддерживает. Такая система - она иерархическая или реляционная?

1. Если СУБД поддерживает таблицы - она реляционная, если иерархии - она иерархическая, если ссылки - она сетевая. Например IMS поддерживает все три.
2. Если пользователь мыслит иерархиями, зачем ему еще рассматирать эти же данные как отношения ? Это не так просто (метапереход). Например a.b.c.d - и сколько здесь отношений ? отношением "a.b" с атрибутом "c.d" - а почему так а не по другому ? А может это 4 отношения a b c d ? Иди одно abcd ?
И самое главное: в иерархии нет ссылок, она самосвязная, а как связывать отношения ?
11 янв 07, 15:12    [3627741]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
мод
ModelR
и какой номер у ORA-xxxxx Hierarhy violated ?

Извините, не понял. Соственно я просто имелввиду nested tables.

А-а, тогда понял. Тут забавная диалектика. Оракл предоставляет реляционный (как к таблице)доступ к данным nested table - колонки , изображающей из себя иерархически построенную память, но на самом деле хранящуюся в таблице.
11 янв 07, 15:26    [3627861]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
ModelR
Тут забавная диалектика. Оракл предоставляет реляционный (как к таблице)доступ к данным nested table - колонки , изображающей из себя иерархически построенную память, но на самом деле хранящуюся в таблице.

Точно - диалектика. Но самое главное - вложенная таблица связана с родительской строкой внутренними ссылками, которые не задаются юзером, т.е это типичная иерархия (правда - пока одноуровневая - не дотягивает оракл до IMS).
11 янв 07, 16:26    [3628355]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
мод
1. Если СУБД поддерживает таблицы - она реляционная, если иерархии - она иерархическая, если ссылки - она сетевая.
Это не ответ на мой вопрос. Или (если это ответ) то я не понял его - можно расшифровать?

мод
Если пользователь мыслит иерархиями, зачем ему еще рассматирать эти же данные как отношения ?
Не думал об абстрактном пользователе, но мне так удобнее. Например мне кажется более естественным описывая накладные представить их как(например)

НАКЛАДНАЯ
(
номер
кому
когда
СТРОКИ
(
артикулНо ...
артикулНо ...
....
)
)
.....

и затем использовать выражение типа
НАКЛАДНАЯ[когда = вчера].строки.артикулNo

(...которое (по большому счету) будет эквивалентно традиционному

SELECT артикул 
FROM накладнаяHEADER JOIN накладнаяLINES
ON накладнаяHEADER.номер = накладнаяLINES.номернакладной
WHERE накладнаяHEADER.когда = вчера
...)
и, при необходимости, выполнить незапланированный запрос,в котором будет присутствовать

...
FROM НАКЛАДНАЯ JOIN .... ON НАКЛАДНАЯ.строки.артикулNo = ....
...

мод
Это не так просто (метапереход)
Всё таки с терминами у Вас как то не так. Что такое метапереход? Какое отношение он имеет к моделям?

мод
Например a.b.c.d - и сколько здесь отношений ? отношением "a.b" с атрибутом "c.d" - а почему так а не по другому ?
Кто сказал, что нельзя по другому? Я не говорил. Я везде говори "например". Правило простое - эти две половинки (имя отношение и имя атрибута), будучи соединенными вместе, должны образовать корректное (определенное в данной системе) путевое(ссылочное) выражение.

мод
как связывать отношения?
Как обычно.
11 янв 07, 16:54    [3628583]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

Откуда:
Сообщений: 349
U-gene
Давайте я его перефразирую, что бы понятней было. Что мешает пользователю, определив некое дерево (мысля при этом конечно иерархиями - например a.b.c.d), рассматирать эти же данные как отношения (мысля конечно отношениями - например отношением "a.b" с атрибутом "c.d") при условии , что система такой ход мысли поддерживает. Такая система - она иерархическая или реляционная?
Вам очень хочется это назвать реляционной? Потому что система поддерживает такой ход мысли (a.b - отношением и c.d - атрибут)? Пожалуй да. Осталось только научить систему поддерживать этот ход мыслей . Не забывайте, что и специалисты по РМ, mir и др., также должны поддерживать (понимать) ваш ход мыслей и вашу нотацию. А если добавить к вашему условию следующее:
Атрибут d строго зависит от c, c от b, b от a. При удалении a удаляются и зависимые от него атрибуты. 
Что тогда? Ведь последнее условие не только поясняет точечную нотацию, но и характеризует другую, уже нереляционную модель данных. Впрочем выход уже найден. Он находится в ДИАЛЕКТИКЕ...
11 янв 07, 17:10    [3628685]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
U-gene

1. Ну вопрос о типе СУБД не так уж и важен - это всего лишь этикетка.
2. В остальном вы полностью повторяете то, что в оракле и называется nested tables. При этом имхо это даже не расширение РМД, а чистая иерархическая модель. При этом SQL продолжает рулить. И при этом нет необходимости связывать в selectе nested table с родительской строкой - СУБД это делает сама.
зы мне кажется вы стучитесь в открытые ворота - ваш пример с накладной в чистом виде так и описывается на оракле и в DDL и в DML.
ззы "метапереход" - преобразование одной модели к другой
11 янв 07, 17:20    [3628764]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
1 проехали
2 Например
-Я тут как то задал вопрос Может вы мне ответите?
-Глубина ссылочных стуктур не ограничена. Вместо артикулНо я мог бы использовать ссылку на объект класса Товар. А в нем бы могли быть еще ссылки... и т.д.
- И вообще зачем нужны таблицы?:) Если мы определили стркутурный тип и подразумеваем, что может существовать множество экземпляпров этого типа, зачем нам это еще в таблицыто впихивать?

PPS
vjl
"метапереход" - преобразование одной модели к другой
Это Вы где прочитали? тынц пожалуйста....
11 янв 07, 18:35    [3629299]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
U-gene
- И вообще зачем нужны таблицы?:) Если мы определили стркутурный тип и подразумеваем, что может существовать множество экземпляпров этого типа, зачем нам это еще в таблицыто впихивать?

Так множество экземпляров этого типа это и есть таблица. На самом деле вы правы: определив тип данных, мы можем строить любые коллекции этого типа, но на ум приходит только две - массив и таблица. Если у таблицы есть номер строки - то это и есть массив, тогда все сходится на таблице. Но даже при опеределении структурного типа его элементы м.б. таблицами и это надо явно указывать при его описании. Кстати, все три модели данных используют таблицы как структурную единицу - различия только в способах связи таблиц.
U-gene

-Я тут как то задал вопрос Может вы мне ответите?

Попробую. Если бы я разрабатывал СУБД, то разрешил бы вычисляемые поля даже в базовых таблицах. В существующих СУБД для этого используются view. view можно переопределять и "наследовать" т.е. создавать view на view. Для юзера view и таблицы не различимы (с оговорками). Т.е. в вашем примере надо написать новое view с выч. полем.
PPS "метапереход" - это Шуклин придумал :). Нужен же какой-то термин для понятия "преобразования моделей".
12 янв 07, 09:54    [3630648]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
мод
вложенная таблица связана с родительской строкой внутренними ссылками, которые не задаются юзером, т.е это типичная иерархия (правда - пока одноуровневая - не дотягивает оракл до IMS).
Ну почему же одноуровневая? прямо из мануала:
CREATE TYPE satellite_t AS OBJECT (
  name        VARCHAR2(20),
  diameter    NUMBER);

CREATE TYPE nt_sat_t AS TABLE OF satellite_t;

CREATE TYPE planet_t AS OBJECT (
  name        VARCHAR2(20),
  mass        NUMBER,
  satellites  nt_sat_t);

CREATE TYPE nt_pl_t AS TABLE OF planet_t;


CREATE TABLE stars (
  name     VARCHAR2(20),
  age      NUMBER,
  planets  nt_pl_t)
NESTED TABLE planets STORE AS planets_tab 
  (NESTED TABLE satellites STORE AS satellites_tab);

Но приципиально да, Оракл блюдет иерархию в том смысле, что никоим образом невозможно
создать satellites иначе чем предварительно создав запись stars, а в ней planets. Прямые операции с STORE AS - таблицами planets_tab и satellites_tab запрещены.
12 янв 07, 11:04    [3631137]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
мод
Guest
ModelR
Ну почему же одноуровневая?

Sorry, не туда глянул (кажется в 8i). Все нормально, многоуровневая иерархия.
ModelR

Но приципиально да, Оракл блюдет иерархию в том смысле, что никоим образом невозможно
создать satellites иначе чем предварительно создав запись stars, а в ней planets. Прямые операции с STORE AS - таблицами planets_tab и satellites_tab запрещены.

Ну так и д.б. и в IMS так же - полная аналогия. satellites и planets не рассматриваются как самостоятельные таблицы. (спасибо за пример).
12 янв 07, 12:25    [3631855]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
laafrb
Member

Откуда:
Сообщений: 31
чего замолчали то?
18 янв 07, 12:07    [3659412]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
gru
Guest
laafrb О чем тут говорить? Посмотрите что с погодой. Все становится непонятным и странным. Вчитайтесь только:
ModelR
мод
Извините, не понял. Соственно я просто имелввиду nested tables.

А-а, тогда понял. Тут забавная диалектика. Оракл предоставляет реляционный (как к таблице)доступ к данным nested table - колонки , изображающей из себя иерархически построенную память, но на самом деле хранящуюся в таблице.
Это противоречит даже первой нормальной форме, не допускающей в частности многозначные поля в таблице. Разваливается мир, реляционная модель, ...всё. И никакая диалектика тут не поможет (((
21 янв 07, 18:28    [3672001]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
okdoky
Member

Откуда:
Сообщений: 349
gru
ModelR
А-а, тогда понял. Тут забавная диалектика. Оракл предоставляет реляционный (как к таблице)доступ к данным nested table - колонки , изображающей из себя иерархически построенную память, но на самом деле хранящуюся в таблице.
Это противоречит даже первой нормальной форме, не допускающей в частности многозначные поля в таблице. Разваливается мир, реляционная модель, ...всё. И никакая диалектика тут не поможет (((
Ну почему вы так грустно? Да, теория отстает от практики. Реляционные штаны, придуманные Коддом, постепенно становятся короче и уже. Дейт их слегка прирастил. Сказал, что значение домена может быть не только скалярным. Если хотите, можете говорить о нормализованных и ненормализованных реляционных моделях. Говорить можно что угодно. Вон, U-gene добавил, что иерархические структуры и зависимости тоже можно пришить к реляционной модели. Почему нет? Будем такую модель уточнять как иерархическая-реляционная модель или реляционная модель вложенных отношений. Другое дело как быть с той алгеброй, математическим аппаратом, пока удобным только для нормализованных отношений ИМХО. Тут может помочь точечная нотация, или как в Zigzag или XPath, что-то типа a[z/y]/b[c[...]].
23 янв 07, 17:25    [3682410]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
okdoky
gru
Разваливается мир, реляционная модель, ...всё. И никакая диалектика тут не поможет (((
Ну почему вы так грустно? Да, теория отстает от практики. Реляционные штаны, придуманные Коддом, постепенно становятся короче и уже. Дейт их слегка прирастил. Сказал, что значение домена может быть не только скалярным. Если хотите, можете говорить о нормализованных и ненормализованных реляционных моделях. Говорить можно что угодно. Вон, U-gene добавил, что иерархические структуры и зависимости тоже можно пришить к реляционной модели. Почему нет? Будем такую модель уточнять как иерархическая-реляционная модель или реляционная модель вложенных отношений. Другое дело как быть с той алгеброй, математическим аппаратом, пока удобным только для нормализованных отношений ИМХО. Тут может помочь точечная нотация, или как в Zigzag или XPath, что-то типа a[z/y]/b[c[...]].
Родные, но не с вашим уровнем познаний можно философски рассуждать о судьбах РМД, снисходительно похлопывая покойничка Кодда и старичка Дейта по плечу. И тем более нести чушь про "нормализованные и ненормализованные реляционные модели".
Если вы помните, то исходная и самая знаменитая статья Кодда, давшая начало реляционной эпохе -- это A Relational Model of Data for Large Shared Data Banks, Communications of the ACM, Vol. 13, No. 6, June 1970, pp. 377-387. И что же мы там читаем?
E.F.Codd, A Relational Model of Data for Large Shared Data Banks
So far, we have discussed examples of relations which are defined on simple domains — domains whose elements are atomic (nondecomposable) values. Nonatomic values can be discussed within the relational framework. Thus, some domains may have relations as elements. These relations may, in turn, be defined on nonsimple domains, and so on. For example, one of the domains on which the relation employee is defined might be salary history. An element of the salary history domain is a binary relation defined on the domain date and the domain salary. The salary history domain is the set of all such binary relations. At any instant of time there are as many instances of the salary history relation in the data bank as there are employees. In contrast, there is only one instance of the employee relation.

Таким образом, Кодд изначально предусматривал в РМД nonsimple domains и nonatomic values.
Тогда вопрос, откуда взялась 1 нормальная форма? Очень просто. Далее в статье Кодд предложил механизм, названный им "нормализацией", позволяющий преобразовывать отношения с вложенными отношениями в набор отношений в "нормальной форме" (т.е. определенных только на simple domains). Но он ясно указал, что это стоит делать только из прагматических соображений, цитата:
E.F.Codd, A Relational Model of Data for Large Shared Data Banks
The simplicity of the array representation which becomes feasible when all relations are cast in normal form is not only an advantage for storage purposes but also for communication of bulk data between systems which use widely different representations of the data. The communication form would be a suitably compressed version of the array representation and would have the following advantages:
1. It would be devoid of pointers (address-valued or displacement-valued). It would avoid all dependence on hash addressing schemes.
2. It would contain no indices or ordering lists.
Таким образом, приведение доменов к "простому" виду он предложил исключительно для облегчения внутренней реализации будущих реляционных систем. Второй его аргумент, следующий сразу за процитированным, был таков:
E.Codd, A Relational Model of Data for Large Shared Data Banks
If the user's relational model is set up in normal form, names of items of data in the data bank can take a simpler form than would otherwise be the case.
И опять никаких теоретических ограничений, просто "система именования попроще будет".
Что там за прошедшие годы навыдумывали всякие идиоты про теоретический запрет на nosimple domains, пусть останется на их совести. Дейт и другие ничего не "приращивали".

Про алгебраическую поддержку тоже не беритесь рассуждать, полный набор операций, включающих работу с вложенными отношениями, давным-давно предложен. Нотация, как элемент синтаксиса, вообще не имеет отношения к алгебре, но это трудно понять человеку, не осилившему определение типа данных как множества значений...
24 янв 07, 15:25    [3688168]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
P.S. Про "идиотов", придумавших "теоретический запрет" на nosimple domains, я погорячился. Тот же Дейт еще в 6 издании ВвСБД не приветствовал вложенные отношения (правдя, очень вяло). Так что лучше сказать, что сейчас теория во многом просто очищается от ряда ненужных ограничений, ранее вызванных в т.ч. проблемами реализации.
24 янв 07, 15:39    [3688301]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
43210
Guest
mir
P.S. Про "идиотов", придумавших "теоретический запрет" на nosimple domains, я погорячился.
Возможно вы просто определили место для Дейта?
24 янв 07, 17:00    [3689072]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных. (продолжение).  [new]
gru
Guest
mir
Про алгебраическую поддержку тоже не беритесь рассуждать, полный набор операций, включающих работу с вложенными отношениями, давным-давно предложен.
Можно манипулировать комплексными значениями? Не выдавать их в качестве результата, а использовать как исходные данные? Разве точечная нотация это плохо?
mir
Про алгебраическую поддержку тоже не беритесь рассуждать, полный набор операций, включающих работу с вложенными отношениями, давным-давно предложен. Нотация, как элемент синтаксиса, вообще не имеет отношения к алгебре, но это трудно понять человеку, не осилившему определение типа данных как множества значений...
Ужасть. Нотация и синтаксис не имеет отношение к алгебре? А вот это. Нет нотации, нет семантики, уважаемый mir
24 янв 07, 21:31    [3690237]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить