powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / О типах связей в сетевой модели данных. (продолжение).
25 сообщений из 178, страница 4 из 8
О типах связей в сетевой модели данных. (продолжение).
    #34248135
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)Уточните, где именно надо смотреть Oracle ?
тынц, если можно
Nested tables - типичная иерархия
...
Рейтинг: 0 / 0
О типах связей в сетевой модели данных. (продолжение).
    #34248195
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneВы это о чём?
Ну там где вы дерево рисовали
c-d /корень a-b-e-f-g \ h
U-gene
Что, в РМД прописано, что данные должны быть представлены в виде отношений явно пользователем , и не могут быть представлены в виде отношения системой на основании какого то другого (иерархического) описания?
Именно так и прописано, а как там система это представляет - никого не интересует (физический уровень понимаешь).
Если пользователь мыслит отношениями- это РМД, если иерархиями - никакой РМД нет.
...
Рейтинг: 0 / 0
О типах связей в сетевой модели данных. (продолжение).
    #34248221
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
мод Gluk (Kazan)Уточните, где именно надо смотреть Oracle ?
тынц, если можно
Nested tables - типичная иерархия

Мы уже говорили об этом. Я просил дать ссылку на документ, в котором Oracle относится к иерархическим БД. Ваши собственные измыления на эту тему малоинтересны.
...
Рейтинг: 0 / 0
О типах связей в сетевой модели данных. (продолжение).
    #34248224
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ModelR и какой номер у ORA-xxxxx Hierarhy violated ?
Извините, не понял. Соственно я просто имелввиду nested tables.
...
Рейтинг: 0 / 0
О типах связей в сетевой модели данных. (продолжение).
    #34248233
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)Я просил дать ссылку на документ, в котором Oracle относится к иерархическим БД. Ваши собственные измыления на эту тему малоинтересны.
Вам шашечки или ехать ? Oracle никуда не относится. Oracle это Oracle.
...
Рейтинг: 0 / 0
О типах связей в сетевой модели данных. (продолжение).
    #34248304
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
мод Gluk (Kazan)Я просил дать ссылку на документ, в котором Oracle относится к иерархическим БД. Ваши собственные измыления на эту тему малоинтересны.
Вам шашечки или ехать ? Oracle никуда не относится. Oracle это Oracle.

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

Как работать с иерархиями в Oracle я знаю. И как БЕЗ Oracle тоже.
Способность работать с иерархиями не делает БД иерархической
...
Рейтинг: 0 / 0
О типах связей в сетевой модели данных. (продолжение).
    #34248417
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)Вы используете собственную терминологию, способную ввести других в заблуждение.
Почему собственную ?
Есть три МД: иерархическая, сетевая, реляционная и их гибриды.
Конкретная СУБД может реализовывать все или некоторые из них. Как при этом называть эту СУБД - вопрос десятый.
...
Рейтинг: 0 / 0
О типах связей в сетевой модели данных. (продолжение).
    #34248506
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
мод U-gene мод Вы привели схему данных и пример DML к ней, осталось привести DDL для полноты картины, если не трудно.
Вы это о чём?Ну там где вы дерево рисовали
c-d /корень a-b-e-f-g \ hЭта :) То есть по-Вашему - это дерево - это я пример DML привел? Всё таки у Вас действительно то ли с терминами что-то не так, то ли с их применением. Где Вы в изображениии дерева D M L то нашли?

модЕсли пользователь мыслит отношениями- это РМД, если иерархиями - никакой РМД нет. И что дальше?. Раньше я задал Вам вопрос Скажите, если система гаранирует, что она работает именно описанным там образом, и пользователь может быть уверен, что описав приведенную там иерархию, он сразу же сможет работать с данными, представленными в виде приведенного там отношенния - эта система иерархическая или реляционная? Давайте я его перефразирую, что бы понятней было. Что мешает пользователю, определив некое дерево (мысля при этом конечно иерархиями - например a.b.c.d), рассматирать эти же данные как отношения (мысля конечно отношениями - например отношением "a.b" с атрибутом "c.d") при условии , что система такой ход мысли поддерживает. Такая система - она иерархическая или реляционная?
...
Рейтинг: 0 / 0
О типах связей в сетевой модели данных. (продолжение).
    #34249117
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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 ?
И самое главное: в иерархии нет ссылок, она самосвязная, а как связывать отношения ?
...
Рейтинг: 0 / 0
О типах связей в сетевой модели данных. (продолжение).
    #34249183
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
мод ModelR и какой номер у ORA-xxxxx Hierarhy violated ?
Извините, не понял. Соственно я просто имелввиду nested tables.
А-а, тогда понял. Тут забавная диалектика. Оракл предоставляет реляционный (как к таблице)доступ к данным nested table - колонки , изображающей из себя иерархически построенную память, но на самом деле хранящуюся в таблице.
...
Рейтинг: 0 / 0
О типах связей в сетевой модели данных. (продолжение).
    #34249450
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ModelRТут забавная диалектика. Оракл предоставляет реляционный (как к таблице)доступ к данным nested table - колонки , изображающей из себя иерархически построенную память, но на самом деле хранящуюся в таблице.
Точно - диалектика. Но самое главное - вложенная таблица связана с родительской строкой внутренними ссылками, которые не задаются юзером, т.е это типичная иерархия (правда - пока одноуровневая - не дотягивает оракл до IMS).
...
Рейтинг: 0 / 0
О типах связей в сетевой модели данных. (продолжение).
    #34249580
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
мод1. Если СУБД поддерживает таблицы - она реляционная, если иерархии - она иерархическая, если ссылки - она сетевая. Это не ответ на мой вопрос. Или (если это ответ) то я не понял его - можно расшифровать?

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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
НАКЛАДНАЯ
(
  номер
  кому   
  когда
  СТРОКИ
  (
    артикулНо ...
    артикулНо ...
    ....
  )
)
.....

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

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

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

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

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

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

модкак связывать отношения? Как обычно.
...
Рейтинг: 0 / 0
О типах связей в сетевой модели данных. (продолжение).
    #34249636
okdoky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-geneДавайте я его перефразирую, что бы понятней было. Что мешает пользователю, определив некое дерево (мысля при этом конечно иерархиями - например a.b.c.d), рассматирать эти же данные как отношения (мысля конечно отношениями - например отношением "a.b" с атрибутом "c.d") при условии , что система такой ход мысли поддерживает. Такая система - она иерархическая или реляционная?Вам очень хочется это назвать реляционной? Потому что система поддерживает такой ход мысли (a.b - отношением и c.d - атрибут)? Пожалуй да. Осталось только научить систему поддерживать этот ход мыслей . Не забывайте, что и специалисты по РМ, mir и др., также должны поддерживать (понимать) ваш ход мыслей и вашу нотацию. А если добавить к вашему условию следующее:
Код: plaintext
 Атрибут d строго зависит от c, c от b, b от a. При удалении a удаляются и зависимые от него атрибуты.  
Что тогда? Ведь последнее условие не только поясняет точечную нотацию, но и характеризует другую, уже нереляционную модель данных. Впрочем выход уже найден. Он находится в ДИАЛЕКТИКЕ...
...
Рейтинг: 0 / 0
О типах связей в сетевой модели данных. (продолжение).
    #34249668
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-gene
1. Ну вопрос о типе СУБД не так уж и важен - это всего лишь этикетка.
2. В остальном вы полностью повторяете то, что в оракле и называется nested tables. При этом имхо это даже не расширение РМД, а чистая иерархическая модель. При этом SQL продолжает рулить. И при этом нет необходимости связывать в selectе nested table с родительской строкой - СУБД это делает сама.
зы мне кажется вы стучитесь в открытые ворота - ваш пример с накладной в чистом виде так и описывается на оракле и в DDL и в DML.
ззы "метапереход" - преобразование одной модели к другой
...
Рейтинг: 0 / 0
О типах связей в сетевой модели данных. (продолжение).
    #34249910
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1 проехали
2 Например
-Я тут как то задал вопрос Может вы мне ответите?
-Глубина ссылочных стуктур не ограничена. Вместо артикулНо я мог бы использовать ссылку на объект класса Товар. А в нем бы могли быть еще ссылки... и т.д.
- И вообще зачем нужны таблицы?:) Если мы определили стркутурный тип и подразумеваем, что может существовать множество экземпляпров этого типа, зачем нам это еще в таблицыто впихивать?

PPS vjl"метапереход" - преобразование одной модели к другой Это Вы где прочитали? тынц пожалуйста....
...
Рейтинг: 0 / 0
О типах связей в сетевой модели данных. (продолжение).
    #34250694
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
U-gene- И вообще зачем нужны таблицы?:) Если мы определили стркутурный тип и подразумеваем, что может существовать множество экземпляпров этого типа, зачем нам это еще в таблицыто впихивать?
Так множество экземпляров этого типа это и есть таблица. На самом деле вы правы: определив тип данных, мы можем строить любые коллекции этого типа, но на ум приходит только две - массив и таблица. Если у таблицы есть номер строки - то это и есть массив, тогда все сходится на таблице. Но даже при опеределении структурного типа его элементы м.б. таблицами и это надо явно указывать при его описании. Кстати, все три модели данных используют таблицы как структурную единицу - различия только в способах связи таблиц.
U-gene
-Я тут как то задал вопрос Может вы мне ответите?
Попробую. Если бы я разрабатывал СУБД, то разрешил бы вычисляемые поля даже в базовых таблицах. В существующих СУБД для этого используются view. view можно переопределять и "наследовать" т.е. создавать view на view. Для юзера view и таблицы не различимы (с оговорками). Т.е. в вашем примере надо написать новое view с выч. полем.
PPS "метапереход" - это Шуклин придумал :). Нужен же какой-то термин для понятия "преобразования моделей".
...
Рейтинг: 0 / 0
О типах связей в сетевой модели данных. (продолжение).
    #34250933
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
мод вложенная таблица связана с родительской строкой внутренними ссылками, которые не задаются юзером, т.е это типичная иерархия (правда - пока одноуровневая - не дотягивает оракл до IMS).Ну почему же одноуровневая? прямо из мануала:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
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 запрещены.
...
Рейтинг: 0 / 0
О типах связей в сетевой модели данных. (продолжение).
    #34251268
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ModelRНу почему же одноуровневая?
Sorry, не туда глянул (кажется в 8i). Все нормально, многоуровневая иерархия.
ModelR
Но приципиально да, Оракл блюдет иерархию в том смысле, что никоим образом невозможно
создать satellites иначе чем предварительно создав запись stars, а в ней planets. Прямые операции с STORE AS - таблицами planets_tab и satellites_tab запрещены.
Ну так и д.б. и в IMS так же - полная аналогия. satellites и planets не рассматриваются как самостоятельные таблицы. (спасибо за пример).
...
Рейтинг: 0 / 0
О типах связей в сетевой модели данных. (продолжение).
    #34264292
laafrb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
чего замолчали то?
...
Рейтинг: 0 / 0
О типах связей в сетевой модели данных. (продолжение).
    #34270650
gru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gru
Гость
laafrb О чем тут говорить? Посмотрите что с погодой. Все становится непонятным и странным. Вчитайтесь только: ModelR модИзвините, не понял. Соственно я просто имелввиду nested tables.
А-а, тогда понял. Тут забавная диалектика. Оракл предоставляет реляционный (как к таблице)доступ к данным nested table - колонки , изображающей из себя иерархически построенную память, но на самом деле хранящуюся в таблице.Это противоречит даже первой нормальной форме , не допускающей в частности многозначные поля в таблице. Разваливается мир, реляционная модель, ...всё. И никакая диалектика тут не поможет (((
...
Рейтинг: 0 / 0
О типах связей в сетевой модели данных. (продолжение).
    #34276191
okdoky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gru ModelR А-а, тогда понял. Тут забавная диалектика. Оракл предоставляет реляционный (как к таблице)доступ к данным nested table - колонки , изображающей из себя иерархически построенную память, но на самом деле хранящуюся в таблице.Это противоречит даже первой нормальной форме , не допускающей в частности многозначные поля в таблице. Разваливается мир, реляционная модель, ...всё. И никакая диалектика тут не поможет (((Ну почему вы так грустно? Да, теория отстает от практики. Реляционные штаны, придуманные Коддом, постепенно становятся короче и уже. Дейт их слегка прирастил. Сказал, что значение домена может быть не только скалярным. Если хотите, можете говорить о нормализованных и ненормализованных реляционных моделях. Говорить можно что угодно. Вон, U-gene добавил, что иерархические структуры и зависимости тоже можно пришить к реляционной модели. Почему нет? Будем такую модель уточнять как иерархическая-реляционная модель или реляционная модель вложенных отношений. Другое дело как быть с той алгеброй, математическим аппаратом, пока удобным только для нормализованных отношений ИМХО. Тут может помочь точечная нотация, или как в Zigzag или XPath, что-то типа a[z/y]/b[c[...]].
...
Рейтинг: 0 / 0
О типах связей в сетевой модели данных. (продолжение).
    #34279107
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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 BanksSo 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 BanksThe 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 BanksIf 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, пусть останется на их совести. Дейт и другие ничего не "приращивали".

Про алгебраическую поддержку тоже не беритесь рассуждать, полный набор операций, включающих работу с вложенными отношениями, давным-давно предложен. Нотация, как элемент синтаксиса, вообще не имеет отношения к алгебре, но это трудно понять человеку, не осилившему определение типа данных как множества значений...
...
Рейтинг: 0 / 0
О типах связей в сетевой модели данных. (продолжение).
    #34279185
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
P.S. Про "идиотов", придумавших "теоретический запрет" на nosimple domains, я погорячился. Тот же Дейт еще в 6 издании ВвСБД не приветствовал вложенные отношения (правдя, очень вяло). Так что лучше сказать, что сейчас теория во многом просто очищается от ряда ненужных ограничений, ранее вызванных в т.ч. проблемами реализации.
...
Рейтинг: 0 / 0
О типах связей в сетевой модели данных. (продолжение).
    #34279628
43210
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mirP.S. Про "идиотов", придумавших "теоретический запрет" на nosimple domains, я погорячился. Возможно вы просто определили место для Дейта?
...
Рейтинг: 0 / 0
О типах связей в сетевой модели данных. (продолжение).
    #34280331
gru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gru
Гость
mirПро алгебраическую поддержку тоже не беритесь рассуждать, полный набор операций, включающих работу с вложенными отношениями, давным-давно предложен.Можно манипулировать комплексными значениями? Не выдавать их в качестве результата, а использовать как исходные данные? Разве точечная нотация это плохо?
mirПро алгебраическую поддержку тоже не беритесь рассуждать, полный набор операций, включающих работу с вложенными отношениями, давным-давно предложен. Нотация, как элемент синтаксиса, вообще не имеет отношения к алгебре, но это трудно понять человеку, не осилившему определение типа данных как множества значений...Ужасть. Нотация и синтаксис не имеет отношение к алгебре? А вот это . Нет нотации, нет семантики, уважаемый mir
...
Рейтинг: 0 / 0
25 сообщений из 178, страница 4 из 8
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / О типах связей в сетевой модели данных. (продолжение).
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]