ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Чем плоха связь "многие ко многим"...?
25 сообщений из 66, страница 2 из 3
  2  все
Чем плоха связь "многие ко многим"...?
    #33292208
Sergey M
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergey M
Участник
Templar Дедушка Добрый день.
В умных книгах советуют... если обнаруживается связь "многие ко многим" между таблицами вводить дополнительную табл. связки и связывать через неё по "один ко многим". Подскажите что при этом мы выигрываем...?
Спасибо.
Попробуйте сначала найти как минимум еще одно решение, а потом уже определять, что выигрываем/проигрывеам.

а вложенные таблицы Оракловские это что не то что ли ?
...
Рейтинг: 0 / 0
28.09.2005, 07:38
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33294732
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
Sergey M Templar Дедушка Добрый день.
В умных книгах советуют... если обнаруживается связь "многие ко многим" между таблицами вводить дополнительную табл. связки и связывать через неё по "один ко многим". Подскажите что при этом мы выигрываем...?
Спасибо.
Попробуйте сначала найти как минимум еще одно решение, а потом уже определять, что выигрываем/проигрывеам.

а вложенные таблицы Оракловские это что не то что ли ?Не то. Это связь один ко многим, если проект правильный. То есть одной записи в мастер-таблице соответствует много записей во вложенной таблице. Если же вложенными таблицами пытаться сделать M:N, то хотя бы задумайтесь о проблемах согласованного обновления.
...
Рейтинг: 0 / 0
29.09.2005, 08:39
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33298281
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
mir Sergey Mа вложенные таблицы Оракловские это что не то что ли ?Не то. Это связь один ко многим, если проект правильный.
Хм. Запомним.

mir То есть одной записи в мастер-таблице соответствует много записей во вложенной таблице.
Мастер - это насколько я понимаю, ведущая таблица, та, в которой есть поле типа nested table.

В таком случае я бы хотел увидеть пример "неправильного" проекта, в котором процитированное здесь утверждение не выполняется. Ну или понять, к чему было сказано про правильное/неправильное.
...
Рейтинг: 0 / 0
30.09.2005, 13:16
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33300619
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
softwarer mir Sergey Mа вложенные таблицы Оракловские это что не то что ли ?Не то. Это связь один ко многим, если проект правильный.
Хм. Запомним.

mir То есть одной записи в мастер-таблице соответствует много записей во вложенной таблице.
Мастер - это насколько я понимаю, ведущая таблица, та, в которой есть поле типа nested table.

В таком случае я бы хотел увидеть пример "неправильного" проекта, в котором процитированное здесь утверждение не выполняется. Ну или понять, к чему было сказано про правильное/неправильное.Ну, скажем, храним данные о проектах и разработчиках. В проекте много разработчиков, разработчик участвует в нескольких проектах.
Правильно: таблица "Разработчики", таблица "Проекты", таблица связности "Разработчики в проектах".
Неправильно: таблица "Разработчики" с полем типа nested table "Проекты разработчика". Или же таблица "Проекты" с полем типа nested table "Разработчики проекта". Надо ли объяснять, почему?
...
Рейтинг: 0 / 0
03.10.2005, 10:09
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33301137
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Во-первых, попрошу таки ответить на заданный вопрос. Напомню его:

softwarer mir То есть одной записи в мастер-таблице соответствует много записей во вложенной таблице.
В таком случае я бы хотел увидеть пример "неправильного" проекта, в котором процитированное здесь утверждение не выполняется. Ну или понять, к чему было сказано про правильное/неправильное.

Надо ли объяснять, почему?
Было бы интересно услышать, чем неправильна таблица "Проекты" с полем "Разработчики проекта" И таблица "Разработчики" с полем "Проекты разработчика".
...
Рейтинг: 0 / 0
03.10.2005, 12:54
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33301311
Templar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Templar
Участник
softwarerБыло бы интересно услышать, чем неправильна таблица "Проекты" с полем "Разработчики проекта" И таблица "Разработчики" с полем "Проекты разработчика".
Нарушением 1-й нормальной формы.
...
Рейтинг: 0 / 0
03.10.2005, 13:47
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33301366
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
TemplarНарушением 1-й нормальной формы.
Затрудняюсь предположить, как именно Вас учили, поэтому попрошу уточнить, что с Вашей точки зрения нарушается.
...
Рейтинг: 0 / 0
03.10.2005, 14:05
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33301684
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
softwarerВо-первых, попрошу таки ответить на заданный вопрос. Напомню его:

softwarer mir То есть одной записи в мастер-таблице соответствует много записей во вложенной таблице.
В таком случае я бы хотел увидеть пример "неправильного" проекта, в котором процитированное здесь утверждение не выполняется. Ну или понять, к чему было сказано про правильное/неправильное.

Надо ли объяснять, почему?
Было бы интересно услышать, чем неправильна таблица "Проекты" с полем "Разработчики проекта" И таблица "Разработчики" с полем "Проекты разработчика".Да хотя бы тем, что пока не заведем хоть один проект, в котором участвует разработчик X, данные о нем просто некуда записать. Это в теории называется аномалией добавления. Вот вам аномалия удаления: если удалим запись о проекте, единственном пока для разработчика X, данные о нем тоже исчезнут.
А вот аномалия обновления. Если разработчик X участвует в нескольких проектах, то для каждого такого проекта он войдет в одну из записей поля-таблицы (со всеми своими атрибутами). Теперь задача: изменить адрес разработчика X. Это придется сделать во всех копиях этой записи. Если где-то не обновить, то будет рассогласование данных.
...
Рейтинг: 0 / 0
03.10.2005, 16:12
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33301840
aZm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aZm
Участник
softwarer TemplarНарушением 1-й нормальной формы.
Затрудняюсь предположить, как именно Вас учили, поэтому попрошу уточнить, что с Вашей точки зрения нарушается.

ну рискну, пожалуй, влезть в дискуссию :) 1я нф - атомарность атрибутов.
но... можно предусмотреть извращенную ситуацию, что вопрос, а какие проекты вел разработчик имярек1 никогда не возникнет, а список разработчиков применяется только вместе... хотя за такую модель надо вешать аналитика :) ибо, как показывает практика, таки возникнет :)
...
Рейтинг: 0 / 0
03.10.2005, 17:00
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33302249
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
mirДа хотя бы тем, что пока не заведем хоть один проект, в котором участвует разработчик X, данные о нем просто некуда записать.
Ошибаетесь. Эта аномалия относится как раз к реализации таблицы вида ПроектыРазработчиков - там разработчик может быть добавлен только вместе с проектом.

В данном случае все просто - добавляем запись в таблицу "Разработчики", поле "Проекты разработчика" оставляем пустым. Добавление проекта без разработчиков - аналогично.

mirЭто в теории называется аномалией добавления. Вот вам аномалия удаления: если удалим запись о проекте, единственном пока для разработчика X, данные о нем тоже исчезнут.
Боюсь, не очень интересно разговаривать с человеком, который цитирует книгу, не пытаясь соотнести цитируемое предмету обсуждения.
...
Рейтинг: 0 / 0
03.10.2005, 18:53
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33302269
Naug
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Naug
Участник
авторЭта аномалия относится как раз к реализации таблицы вида ПроектыРазработчиков - там разработчик может быть добавлен только вместе с проектом.
o.O вдумавшись пришёл к выводу что вы имеете ввиду что уже существующего разработчика нельзя внести в таблицу ПроектыРазработчиков пока он не включён в какой-либо проект. Я правильно понял? Если да, то "ну и что?"
...
Рейтинг: 0 / 0
03.10.2005, 19:00
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33302317
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
aZmну рискну, пожалуй, влезть в дискуссию :) 1я нф - атомарность атрибутов.
Согласен. А что есть атомарность атрибутов? Грубо говоря, означает, что тип атрибута адекватен требуемым по смыслу задачи и имеющимся в распоряжении операциям; нам не нужно писать substr (field, 2, 4) чтобы взять часть композитного значения и тому подобных действий.

В данном случае - проблем нет:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
Connected to Oracle Database 10g Enterprise Edition Release  10 . 1 . 0 . 4 . 0  
Connected as test

SQL> create type TData as object ( j integer ) ;

Type created

SQL> create type TDataTable as table of TData ;

Type created

SQL> create table NT ( i integer, subdata TDataTable ) nested table subdata store as NT_subdata ;

Table created

SQL> insert into NT values (  1 , TDataTable ( TData (  1  ), TData (  2  ), TData (  3  ))) ;

 1  row inserted

SQL> insert into NT values (  2 , TDataTable ( TData (  3  ), TData (  4  ), TData (  5  ))) ;

 1  row inserted

SQL> insert into NT values (  3 , TDataTable ( TData (  5  ), TData (  6  ), TData (  1  ))) ;

 1  row inserted

SQL> column i format a10 ;
SQL> select i from NT
   2   where exists ( select  1  from table ( cast ( subdata as TDataTable )) where j =  3  ) ;

         I
----------
          1 
          2

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

aZmно... можно предусмотреть извращенную ситуацию, что вопрос, а какие проекты вел разработчик имярек1 никогда не возникнет,
Собственно, select выше - называет номера проектов, в которых участвовал разработчик номер 3 :)
...
Рейтинг: 0 / 0
03.10.2005, 19:22
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33302327
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Naugo.O вдумавшись пришёл к выводу что вы имеете ввиду что уже существующего разработчика нельзя внести в таблицу ПроектыРазработчиков пока он не включён в какой-либо проект. Я правильно понял? Если да, то "ну и что?"
То, что такой таблицей будет трудно отразить некоторые реалии нашего мира. Скажем, отдел HR не сможет внести в БД принятого на работу сотрудника, пока начальник не распределит его на тот или иной проект.

Реально, конечно, можно с дополнительными усилиями работать и так, но такая структура БД требует изрядной и нетривиальной обвязки из ХП для нормальной работы, причем на пустом месте - это один из классических примеров по нормализации.

Я не понимаю другого - мой оппонент приводит аргумент, относящийся к работе с одной таблицей, к схеме, в которой их ЧЕТЫРЕ. Собственно, три - то, что mir назвал изначально - это простой случай, целиком соответствующий обычной практике с таблицей-развязкой. Целиком - в смысле, физически генерируется именно такая структура данных. Поэтому я попросил прокомментировать более яркий пример, с денормализацией, чтобы недостатки были ярче видны.
...
Рейтинг: 0 / 0
03.10.2005, 19:30
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33302333
Naug
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Naug
Участник
автор
То, что такой таблицей будет трудно отразить некоторые реалии нашего мира. Скажем, отдел HR не сможет внести в БД принятого на работу сотрудника, пока начальник не распределит его на тот или иной проект.
Какая одна таблица?
mirПравильно: таблица "Разработчики", таблица "Проекты", таблица связности "Разработчики в проектах".

обычная псевдо м:м развязка. И разработчиков можно сколько угодно добавлять без проектов и ссылаться на них в других отношениях (РазработчикПродукт).
...
Рейтинг: 0 / 0
03.10.2005, 19:36
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33302913
aZm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aZm
Участник
2 softwarer
давайте не путать теплое и мягкое :)? вложенная таблица это очень частный случай, применимый только (?) в оракл. а в общем случае, получаем тильда/комма/дот/etc сепаратед валуес, в виде строчки, которые в общем случае при помощи sql не обработать :)

---
Vae victis!
...
Рейтинг: 0 / 0
04.10.2005, 10:13
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33303051
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
aZm2 softwarer
давайте не путать теплое и мягкое :)?
Согласен.

aZm вложенная таблица это очень частный случай, применимый только (?) в оракл.
И? Если посмотрите выше - там был задан примерно следующий вопрос: "а не являются ли оракловые вложенные таблицы альтернативой?". Вроде как начали объяснять, что не являются. Согласитесь, "общий случай" тут совершенно не при чем, и не надо путать теплое и мягкое :)
...
Рейтинг: 0 / 0
04.10.2005, 10:49
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33303081
aZm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aZm
Участник
softwarerИ? Если посмотрите выше - там был задан примерно следующий вопрос: "а не являются ли оракловые вложенные таблицы альтернативой?". Вроде как начали объяснять, что не являются. Согласитесь, "общий случай" тут совершенно не при чем, и не надо путать теплое и мягкое :)

полностью согласен, в теме было много букв, прочел не все . в таком контексте - вы полностью правы. кроме того, по вложенным неплохо отписался mir, добавить, право, нечего.

mir
...
Не то. Это связь один ко многим, если проект правильный. То есть одной записи в мастер-таблице соответствует много записей во вложенной таблице. Если же вложенными таблицами пытаться сделать M:N, то хотя бы задумайтесь о проблемах согласованного обновления.

однако... в классической теории вроде бы про nested tables не говорится? (хотя возможно я и ошибаюсь) следовательно, формально , это нарушение 1й нф
...
Рейтинг: 0 / 0
04.10.2005, 10:59
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33303084
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
aZmа в общем случае, получаем тильда/комма/дот/etc сепаратед валуес, в виде строчки, которые в общем случае при помощи sql не обработать
Хотя, сугубо вредности ради:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
Connected to Oracle Database 10g Enterprise Edition Release  10 . 1 . 0 . 4 . 0  
Connected as test

SQL> create type TStringTable as table of varchar2( 4000 ) ;

Type created

SQL> create function Parse_Comma ( Str varchar2 ) return TStringTable pipelined as
   2     p integer ;
   3     s varchar2( 4000 ) ;
   4   begin
   5     s := Str ;
   6     while s is not null loop
   7       p := InStr ( s || ',', ',' ) ;
   8       pipe row ( Trim ( SubStr ( s,  1 , p -  1  ))) ;
   9       s := Trim ( SubStr ( s, p +  1  )) ;
  10     end loop ;
  11     return ;
  12   end ;
  13   /

Function created

SQL> create table ST as
   2     select  1  i#, '1,2,3,4,5' data from dual union
   3     select  2 , '3,4,5,6,7' from dual union
   4     select  3 , '5,6,7,8,9' from dual ;

Table created

SQL> select i# from ST
   2   where exists ( 
   3     select * from table ( cast ( Parse_Comma ( data ) as TStringTable )) 
   4     where column_value =  3  ) ;

        I#
----------
          1 
          2

К чему я это все: не надо относиться к подобным вещам как к заповедям. Надо понимать, откуда они идут и следовать не букве, но духу.
...
Рейтинг: 0 / 0
04.10.2005, 11:00
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33303101
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
aZmкроме того, по вложенным неплохо отписался mir, добавить, право, нечего.
Боюсь, неплохости этой отписки я абсолютно не понял. Такое впечатление, что mir понимает под вложенными таблицами что-то совершенно другое, нежели то, чем они в действительности являются.

aZmоднако... в классической теории вроде бы про nested tables не говорится? (хотя возможно я и ошибаюсь) следовательно, формально , это нарушение 1й нф
Следование неверно. Прежде чем показать почему - комментарий к такому методу доказательства вообще: я абсолютно уверен, что в классической теории нормализации ничего не говорится про blob поля. Значит ли это, что таблицы с такими полями заведомо не нормализованы?

А "почему" - видите ли, nested table - это на самом деле обычная детальная таблица. Если мы рассмотрим варианты: "классический" (то есть создаются таблицы А, Б и развязочная таблица А_Б) и "вложенный" (создаются таблицы А, Б и в таблице Б есть поле типа "вложенная таблица с foreign key на таблицу А") - на самом деле в БД будут созданы абсолютно эквивалентные структуры данных. Глядя на ER-ку, вообще говоря, нельзя определить, какой именно из вариантов физической реализации имеется в виду. Разница в данном случае только в синтаксисе, в том, как мы логически рассматриваем эту таблицу и как предпочитаем с ней работать.
...
Рейтинг: 0 / 0
04.10.2005, 11:08
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33303545
_hike_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_hike_
Участник
Позволю себе вставить свои 5 копеек.
ИМХО все эти NESTED TABLES, магические числа в полях и т.п. есть ничто иное как отход от теории заради практической выгоды.
Ибо реляционная БД много в чем не удовлетворяет разработчиков, но все равно используется так как наиболее провереная временем. И они (разработчики) по всякому извращаются над ней (а кто сказал что это плохо) дабы подогнать под свои нужды. Иногда им в этом помагают даже производители РБД (NESTED TABLES тому пример).
автор... Прежде чем показать почему - комментарий к такому методу доказательства вообще: я абсолютно уверен, что в классической теории нормализации ничего не говорится про blob поля. Значит ли это, что таблицы с такими полями заведомо не нормализованы?
а это смотря что хранить в BLOB полях
...
Рейтинг: 0 / 0
04.10.2005, 13:12
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33304033
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
_hike_Позволю себе вставить свои 5 копеек.
ИМХО все эти NESTED TABLES, магические числа в полях и т.п. есть ничто иное как отход от теории заради практической выгоды.
Давайте не путать божий дар с яичницей. Магические числа в полях теорией никак не покрываются (за исключением разве что некоторых случаев), а говоря об отходе в случае nested table - будьте уж добры пояснить, в чем именно, причем так, чтобы из пояснения было понятно, что Вы хотя бы приблизительно знаете, что это такое.

Практически - это примерно такой же отход от теории, как и любые доработки SQL, например появившееся относительно недавно предложение WITH.

а это смотря что хранить в BLOB полях
Вот именно что. Причем не только "что хранить", но и "как с этим работать". Как и в случае nested tables - само по себе их применение не говорит в пользу того либо другого варианта; надо смотреть, как они применены.
...
Рейтинг: 0 / 0
04.10.2005, 15:25
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33304068
_hike_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_hike_
Участник
автор....надо смотреть, как они применены
абсолютно согласен но беда в том что многие (может это только я таких встречал ????) пытаются использовать NESTED TABLE абсолютно неоправдано нарушая 1 н.ф. Может все дело в названии ? Может надаром в 10ке вместо него ввели XMLType ?
...
Рейтинг: 0 / 0
04.10.2005, 15:36
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33304076
_hike_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_hike_
Участник
или там от него вообще отказались ?
...
Рейтинг: 0 / 0
04.10.2005, 15:38
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33304098
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
softwarer mirДа хотя бы тем, что пока не заведем хоть один проект, в котором участвует разработчик X, данные о нем просто некуда записать.
Ошибаетесь. Эта аномалия относится как раз к реализации таблицы вида ПроектыРазработчиков - там разработчик может быть добавлен только вместе с проектом. С чего это? Добавляю все данные о разработчике в таблицу «Разработчики». Вы считаете, что это невозможно? Почему это отсутствие проектов помешает мне это сделать? Признайтесь, что тут вы просто ошиблись. Как раз классическая схема из 3 таблиц позволяет вводить данные по обеим сущностям полностью независимо, а затем, по необходимости, добавлять данные об их связях.

softwarerВ данном случае все просто - добавляем запись в таблицу "Разработчики", поле "Проекты разработчика" оставляем пустым. Добавление проекта без разработчиков - аналогично. Айн момент. Рассмотрим такой вариант проекта БД: таблица «Проекты» с полем «Разработчики проекта» типа nested table. Если у меня есть на бумажке данные о разработчике X, но в таблице «Проекты» пока нет записей о проектах, в которых он участвует, то куда в БД поместить данные о разработчике X? Ответ: некуда. Никакими тут пустыми полями не поможешь. Аномалия добавления налицо, а значит и парная аномалия удаления (см. мой пред. пост).

softwarer mirЭто в теории называется аномалией добавления. Вот вам аномалия удаления: если удалим запись о проекте, единственном пока для разработчика X, данные о нем тоже исчезнут.
Боюсь, не очень интересно разговаривать с человеком, который цитирует книгу, не пытаясь соотнести цитируемое предмету обсуждения.Вы можете со мной не разговаривать, но способны ли вы возразить по сути вопроса? В частности, вы ничего не сказали по поводу моего пример аномалии обновления.
Итак, рассмотрим тот же вариант проекта БД: таблица «Проекты» с полем «Разработчики проекта» типа nested table. Пусть разработчик X участвует в проектах Y и Z. Это значит, что данные о нем продублированы: одна копия в записи (таблица «Проекты») по проекту Y, другая копия в записи (таблица «Проекты») по проекту Z. Возникает возможность некорректного обновления: в одной копии данные изменили, в другой нет.

А по поводу цитирования книги... Я не держал перед глазами книгу, если вы об этом. Подобные сведения об аномалиях денормализации у каждого, по моему, в памяти, как 2*2=4. У вас разве нет?
...
Рейтинг: 0 / 0
04.10.2005, 15:43
| Ответить | Цитировать | Написать  
Чем плоха связь "многие ко многим"...?
    #33304103
_hike_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_hike_
Участник
автор... вместо него ввели XMLType ?
причем тут XMLType - это вообще отдельный тип.
...
Рейтинг: 0 / 0
04.10.2005, 15:45
| Ответить | Цитировать | Написать  
25 сообщений из 66, страница 2 из 3
  2  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Чем плоха связь "многие ко многим"...?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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