Мимо пробегал...kamenjahr...А вот слова television нет;-))

Все же это Вам аккуратнее надо быть (а не нам и ко). Там это слово на первой развороте в дереве, и потом в описании иерархии, и все строки с TV по category_ID относятся именно к TELEVISIONS. Что, тем не менее, к контексту отношения не имеет. :)
БИНГО!!! Т.е если бы слова television (s) НЕ было, то TV не значило бы телевизор?

Arhat109kamenjahrУважаемый Arhat109, введите пожалуйста чо есть "строка текста" и ее атомарность, опираясь на научную литературу по теории реляционных баз данных. Спасибо

:) :) :) ... в школу, плиз. :)

Ни к чему такие дешевые спрыги:-) Так бы и написали, что сие : "строка текста" и ее атомарность ни к селу ни к городу касаемо нормализации реляционных баз данных.

БредятинаkamenjahrУважаемый Arhat109, введите пожалуйста чо есть "строка текста" и ее атомарность, опираясь на научную литературу по теории реляционных баз данных. Спасибо
Это нет и не может быть в теории реляционных баз данных.
1) Вам уже приводили, в несколько неудачном контексте, пример: "Семнадцать мгновений весны". Очевидно, что смысл не изменится, если написать "Весны семнадцать мгновений". Или разбить на два атрибута, чтобы иметь возможность указывать сколько мгновений и какого времени года:
Семнадцать мгновений; Весны
Три мгновения; Зимы
Тем не менее, как название фильма, это значение, вероятно, является атомарным (вероятно, и названия товаров в Вашем примере являлись атомарными, чтобы там в них не было написано).
2) Теперь представим отношение с одним атрибутом:
Фильм {Наименование}
Ничто не мешает пользователю ввести значение очередного кортежа:
"Семнадцать мгновений весны (неплохой, кстати, сериал)"
Это безусловно атомарное значение, с "точки зрения" СУБД и установленных типов и ограничений целостности.
3) Вы же посчитали его не атомарным и добавили еще один атрибут
Фильм {Наименование; Примечание}
и что-то пояснили пользователям, чтобы они вводили:
"Семнадцать мгновений весны; Неплохой, кстати, сериал"
а они ввели
"Семнадцать мгновений весны (был черно-белый, потом раскрасили); Неплохой, кстати, сериал"
И т.д. "Семнадцать мгновений весны (актриса, сыгравшая радистку, была женой Миронова)", Семнадцать мгновений весны (полезно почитать воспоминания Куравлева о съемках в этом фильме)", "Семнадцать мгновений весны (И. Кобзон)", ... и все это атомарные значения, конечно же. Но Вы, проявив настойчивость, нормализуете до конца. Я уверен))
Но, еще раз советую:
14002578


""Семнадцать мгновений весны (неплохой, кстати, сериал)"
Это безусловно атомарное значение, с "точки зрения" СУБД и установленных типов и ограничений целостности." обозначение
"Семнадцать мгновений весны (неплохой, кстати, сериал)" как атомарным является ложным поскольку в "Семнадцать мгновений весны (неплохой, кстати, сериал)"

содержится как само название фильма "Семнадцать мгновений весны" так и его вид сериал так и оценочная характеристика (неплохой, кстати, сериал) .

Для понимания, почему, зачтите воот эту страничку с парой последующих вот из этой книги жизни ;-)

Бредятинаkamenjahr"Семнадцать мгновений весны (неплохой, кстати, сериал)" как атомарным является ложным поскольку в "Семнадцать мгновений весны (неплохой, кстати, сериал)"
содержится как само название фильма "Семнадцать мгновений весны" так и его вид сериал так и оценочная характеристика (неплохой, кстати, сериал) .
Для понимания, почему, зачтите воот эту страничку с парой последующих вот из этой книги жизни ;-)
Этот стиль - игнорирования сообщений - хотя и является общепринятым на sql.ru - Вам не поможет. Не знаю, умышленно ли Вы меня с кем-то путаете, но, оптимистично предположу, что не умышленно. И повторю свое сообщение, в котором нет лишних слов, поэтому не нужно комментировать только одно предложение, если Вы еще не поняли смысл этого текста:

Этого нет и не может быть в теории реляционных баз данных.
1) Вам уже приводили, в несколько неудачном контексте, пример: "Семнадцать мгновений весны". Очевидно, что смысл не изменится, если написать "Весны семнадцать мгновений". Или разбить на два атрибута, чтобы иметь возможность указывать сколько мгновений и какого времени года:
Семнадцать мгновений; Весны
Три мгновения; Зимы
Тем не менее, как название фильма, это значение, вероятно, является атомарным (вероятно, и названия товаров в Вашем примере являлись атомарными, чтобы там в них не было написано).
2) Теперь представим отношение с одним атрибутом:
Фильм {Наименование}
Ничто не мешает пользователю ввести значение очередного кортежа:
"Семнадцать мгновений весны (неплохой, кстати, сериал)"
Это безусловно атомарное значение, с "точки зрения" СУБД и установленных типов и ограничений целостности.
3) Вы же посчитали его не атомарным и добавили еще один атрибут
Фильм {Наименование; Примечание}
и что-то пояснили пользователям, чтобы они вводили:
"Семнадцать мгновений весны; Неплохой, кстати, сериал"
а они ввели
"Семнадцать мгновений весны (был черно-белый, потом раскрасили); Неплохой, кстати, сериал"
И т.д. "Семнадцать мгновений весны (актриса, сыгравшая радистку, была женой Миронова)", Семнадцать мгновений весны (полезно почитать воспоминания Куравлева о съемках в этом фильме)", "Семнадцать мгновений весны (И. Кобзон)", ... и все это атомарные значения, конечно же. Но Вы, проявив настойчивость, нормализуете до конца. Я уверен))
Но, еще раз советую:
14002578

Теперь о Вашей ошибочной, во всех отношениях, ссылке. Глава 11 в книге Дейта, на которую Вы попытались сослаться, называется "Функциональные зависимости". Чтобы лучше понять, как опасно ссылаться на старые издания, вот цитата Дейта (изд. 8 Часть II, глава 6, стр. 214):

"... Иными словами, атрибуты могут иметь значения в виде отношений, а это означает, что в отношениях могут применяться атрибуты, значениями которых, в свою очередь, являются отношения. ... И ниже в этом шестом издании мы находим следующее утверждение:
Домены (т.е. типы) содержат только атомарные значения... [Поэтому] отношения не должны включать повторяющиеся группы...
Но эти замечания были не правильными (по меньшей мере, не совсем правильными). ... автор считает своим долгом принести извинения всем, кого он ввел в заблуждение."

Вы не разобрались в затрагиваемых проблемах проектирования БД, чтобы чувствовать себя уверенно, и поэтому немного нервничаете.

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

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

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

БредятинаДобавлю, что ни на одной из страниц Главы 12 "Дальнейшая нормализация..." нет, и даже теоретически не может быть, ни одного слова, относящегося к проблеме "Семнадцати мгновений весны"))
Это если читать с закрытыми глазами или вообще не читать, абыстробыстро листатьлистатьлистатьлистатьлистать

Щопэнkamenjahr,

Почему вы позволяете себе писать неатомарные комментарии?! Они же сохраняются в базе данных!холодное с мягким путаете. ввод данных и дизайн бд разные вещикро ме того каменты вообще ни при делах речл об ином поле,

Arhat109kamenjahr,

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

... а ежели НЕ можете, то НЕ НАДО ссылаться на произвольный текст "вокруг вопроса"... там, между прочим речь совсем о другом идет.вы вначале бы вели бы научные источникио которых я вас спрашивал на предмет строка текста и ее атомарность что же касается кавычки так я уж поясннил раза три.почему именно в контексте статьи с примером товаров электроники она однозачно кавычково указываеть на размерность в дюймах,,

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

Спустя 9 страниц до Штирлица дошло, что нормализация может касаться только структуры, а не значений атрибутов (независимо от того, есть ли в этих значениях двойные кавычки или нет).

Кот Матроскинkamenjahr,

правда, только что Вы утверждали обратное :)
ввод данных и дизайн бд разные вещи

Давайте Вы определитесь - на основании "ввода данных" можно, по-Вашему, делать выводы о нормализованности структуры или нет?

Ввод данных - это интерактивный процесс - на основании сего процесса выводов о нормализованности не делают.

Когда данные введены, тогда да - на основании введенных данных возможно делать выводы.

Приведу пример: если в книжечке написано, что есть таблица АБЦ со столбцами {ИД, имя, тип}, то только на основании сией инфо невозможно сделать вывод о том, нормализированна табличечка али нет.
А вот если видишь вот такое
{ИД, имя, тип}, 1й кортеж {1, ВасилийАлибабаевичГодРОждения1941холост, осужденНа4ЛетЗаразбавлениеБензинаНаАвтозаправке} - то сразу жеж видно состояние ненормализованности

Arhat109kamenjahr,

Вы сначала научитесь ОТВЕЧАТЬ на вопросы, прежде чем их задавать... я просил "ткнуть пальцем" в номер строки и позицию в ней... ожидались цифирьки, а не отмазки. Аналогично по предыдущим, заданным вам вопросам, также ожидались цифирьки (целые, атомарные значения, а не текст в виде комментов). :)
На вопросы я то ответил, иное дело, что Вы очки себе еще неприкупили. А вот Вы лично Вы ИЗНАЧАЛьНО даже не потрудились ввести научные источники, где бы были бы "строка текста" и "атомарность".

Arhat109kamenjahr,

Вы не ответили ни на один мой вопрос. В качестве ответа должны быть указаны ЦИФИРЬКИ номера строки из цитированного ВАМИ тексту... его не я привел, а вы. И НЕ МОЖЕТЕ в нем же найти доказательств своим перлам... как найдете - свистните, плиз. Цифирьками.
я давным давно ответил на Ваш вопрос. Не надо валинком прикидыватся
Ответы были даны в частности в этих сообщениях:
13995929
14010699

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

Кот МатроскинkamenjahrПриведу пример: если в книжечке написано, что есть таблица АБЦ со столбцами {ИД, имя, тип}, то только на основании сией инфо невозможно сделать вывод о том, нормализированна табличечка али нет.
А вот если видишь вот такое
{ИД, имя, тип}, 1й кортеж {1, ВасилийАлибабаевичГодРОждения1941холост, осужденНа4ЛетЗаразбавлениеБензинаНаАвтозаправке} - то сразу жеж видно состояние ненормализованности

Т.е., По Вашему, свойство "нормализованость" относится не к структуре БД, а только к самой БД вместе с данными? Вчера БД и ее структура были нормализованными, а сегодня тетя Маша ввела в поле name
ВасилийАлибабаевичГодРОждения1941холост
и все, база сразу стала ненормализованной?

Не много не так: Если база данных изначально не предусматривала столбцов, Ф.И.О , Год рождения , Семейное Положение , а было только поле name , в которой хранились строки вида:
ВасилийАлибабаевичГодРОждения1941холост
то такая БД была не нормализованной и тетя Маша своими вводами никак на нормализацию повлиять не могла. НО!! Если мы имеем отдельные столбцы Ф.И.О , Год рождения , Семейное Положение , и есть ГУИ-фронтэнд, где есть ГУИполя в которые тетя Маша может РАЗДЕЛьНО набрать данные про Ф.И.О, год рождения и семейное положения, НО эта тетя Маша лепит в поле "Фамилия" еще и имя с отчеством да еще и руками текст набирает "холост, родился в 1953 в Кисловодске", то да тетя Маша вносит лепту в процесс денормализации таблицы и задача разработчиков программного обеспечения предотвратить подобные поползновения, вводя ряд проверок, не пройдя которые, запись не будет помещена в таблицу БД.