|
|
|
Иерархические структуры в реляционной БД & нормализация
|
|||
|---|---|---|---|
|
#18+
Мимо пробегал...Модели BMW обозначаются трехзначным индексом - 318, 760 и тп, где первая цифра - кузов а вторая и третья - объем мотора. Тоже разнородная информация и вроде повод для нагородить табличек. А ведь BMW - это не просто слово, а аббревиатура от Bayerische Motoren Werke (Баварские моторные заводы). Здесь можно и функциональную зависимость между буквами углядеть. А вспомнить ВАЗ, МАЗ, БелАЗ... Непаханое поле для энтузиастов-нормализаторов!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2013, 14:04 |
|
||
|
Иерархические структуры в реляционной БД & нормализация
|
|||
|---|---|---|---|
|
#18+
> кто такое может и реализовал с васейвгалстуке надо гнать из профессии Вы предложили абсолютно аналогичный вариант. > правильный вариант он оди вообщетг Вообще-то не один, конечно. Но среди приведенных примеров нет ни одного, решающего задачу приемлемым образом. Однако, можно придумать частные случаи, для которых будут работать все приведенные примеры. Аналогия понятна? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2013, 14:52 |
|
||
|
Иерархические структуры в реляционной БД & нормализация
|
|||
|---|---|---|---|
|
#18+
guest_20040621> кто такое может и реализовал с васейвгалстуке надо гнать из профессии Вы предложили абсолютно аналогичный вариант. > правильный вариант он оди вообщетг Вообще-то не один, конечно. Но среди приведенных примеров нет ни одного, решающего задачу приемлемым образом. Однако, можно придумать частные случаи, для которых будут работать все приведенные примеры. Аналогия понятна? я предложил стандартный рассматриваемый в дцати учебниках вариант вообще-то. А в ответ только лузлы с расчленением телефонных номеров и абревиатур. Атомарность всегда однозначна. Иное дело, что совокупность атомарных объектов объединяют с целью, например быстродействие увеличить, шоб до дцати таблицам не бегать и не джойнить. Теперь зададимся вопросом, а атомарен ли аттрибут name в котором есть наименование+размерность (например 'Ultra-Plasma 62" ') Введу цитато-определение http://www.basegroup.ru/glossary/definitions/atomic_data/ В теории баз данных это атрибуты, которые хранят единственное значение и не являются ни списком, ни множеством значений. Иными словами, это такие данные, разделение которых на составляющие приводит к потере их смысла с точки зрения решаемой задачи. Например, если атрибут «Цена» содержит значение 15, то попытка разделить его на 1 и 5 приведет к полной бессмыслице. Данные, не являющиеся атомарными, называются составными. Например, в базе, содержащей сведения о сотрудниках организации, скорее всего, имеется поле «Адрес», которое может быть представлено в виде «почтовый индекс, город, улица, дом [/, корпус], [квартира]». С точки зрения кадрового учета это атомарный атрибут, поскольку маловероятно, что потребуется отдельное использование его частей, например, сортировка сотрудников по номеру квартиры. Поэтому его разбиение на несколько полей бессмысленно и только усложняет структуру базы данных. В то же время, если производится анализ издательского рынка, где требуется определить число подписчиков на определенные издания в тех или иных городах и регионах, то атрибуты «Почтовый индекс» и «Город» могут иметь самостоятельную ценность. Тогда адрес перестает быть атомарным атрибутом. Следовательно одни и те же данные в зависимости от ситуации могут рассматриваться и как атомарные, и как составные. Знание, являются ли атрибуты в базе данных атомарными с точки зрения решения конкретной задачи, очень важно при организации их хранения, поскольку при нормализации реляционной СУБД все отношения должны быть приведены в 1-ю нормальную форму, которая может содержать только атомарные атрибуты. Если последовать стебу "адавайнабуквыразделим" - 'Ultra-Plasma 62" смысл будет потерян (напомню если че, статья http://mikehillyer.com/articles/managing-hierarchical-data-in-mysql/ посвещена НЕ лингвистическим аспектам, подсчету каких-то буквостатистик а организации базы данных. ) Если же разделить размерность и наименование - смысл потерян не будет . Следовательно данные в атрибуте не атомарны. Следовательно таблица не нормализована. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2013, 16:18 |
|
||
|
Иерархические структуры в реляционной БД & нормализация
|
|||
|---|---|---|---|
|
#18+
Cane Cat FisherМимо пробегал...Модели BMW обозначаются трехзначным индексом - 318, 760 и тп, где первая цифра - кузов а вторая и третья - объем мотора. Тоже разнородная информация и вроде повод для нагородить табличек. А ведь BMW - это не просто слово, а аббревиатура от Bayerische Motoren Werke (Баварские моторные заводы). Здесь можно и функциональную зависимость между буквами углядеть. А вспомнить ВАЗ, МАЗ, БелАЗ... Непаханое поле для энтузиастов-нормализаторов!!! А нафига вообще столбцы в таблице, ерудна какая. Двух стобцов вполне достаточо: айдишник и строка Зафигарить все аттрибуты в строку и дело с концом А всякихтам Коддов -фтопку P.S http://ord.com.ru/files/book2/p251.html] 2.5.1. Первая нормальная форма Все рассматриваемые отношения в реляционном подходе должны находиться в первой нормальной форме (1НФ), которая предполагает, что элементы доменов отношений не являются множествами (т.е. являются атомарными) и не ограничивает наличие функциональных зависимостей между атрибутами в схеме отношения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2013, 16:25 |
|
||
|
Иерархические структуры в реляционной БД & нормализация
|
|||
|---|---|---|---|
|
#18+
kamenjahrАтомарность всегда однозначна. Введу цитато-определение Ты бы его помыл прочитал что ли перед вводом... Знание, являются ли атрибуты в базе данных атомарными с точки зрения решения конкретной задачи , очень важно при организации их хранения Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2013, 16:28 |
|
||
|
Иерархические структуры в реляционной БД & нормализация
|
|||
|---|---|---|---|
|
#18+
kamenjahrАтомарность всегда однозначна. Нет. В Вашей же цитате приводится пример данных, которые атомарны для одной задачи и неатомарны для другой. P.S. Давно уже говорю, что фетиш "специалиста по БД нужно оценивать по нормализации" - вреден. Народ заучивает определения форм, не задумываясь над ними, и в результате получается вот такое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2013, 16:36 |
|
||
|
Иерархические структуры в реляционной БД & нормализация
|
|||
|---|---|---|---|
|
#18+
> стандартный рассматриваемый в дцати учебниках вариант вообще-то Хороший повод выбросить эти учебники. > Теперь зададимся вопросом, а атомарен ли аттрибут name Перефразировать его можно так: я назвал какую-то хрень какой-то хренью, правильно ли я сделал? Конечно, правильно: предполагается, что вы - свободный человек и живете в свободном государстве, т. е. можете делать все, что не запрещено законодательством. Но на самом деле вопрос следует задать по-другому: решает ли предложенный вариант поставленную задачу? Нет, не решает. > Введу цитато-определение Не читайте то, что пишут на заборах. > Следовательно таблица не нормализована. Это неправильный вывод, вам уже сказали. Упираться рогом в стену - плохой метод ведения дискуссий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2013, 17:06 |
|
||
|
Иерархические структуры в реляционной БД & нормализация
|
|||
|---|---|---|---|
|
#18+
kamenjahrЕсли же разделить размерность и наименование - смысл потерян не будет . Потерян будет. Хотя бы потому, что поиск телевизора по названию становится невозможным. Один телевизор может называться Ultra-Plasma 62'', другой Ultra-Thin 2.5'', третий Ultra-Light-0.5 (кг), а четвертый Ultra-2012. и что, везде ради нормализации уберете диагональ, толщину, вес и год? Тогда уж и названия Windows-95, Windows-98, Windows Millenuim и Windows 7 надо разделять. Мораль: Включение в атрибут "название" некоторых других, рыночно-звучных атрибутов не приводит к нарушению 1НФ "названия" в целом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2013, 17:12 |
|
||
|
Иерархические структуры в реляционной БД & нормализация
|
|||
|---|---|---|---|
|
#18+
Что-то я не понимаю, о чем спор идет. Все равно же информация о размерности, весе, технологии будет рядом в отдельной таблице лежать. Ибо в названии "Ultra TV Deluxe", скажем, никакой информации о размерности нет. Ее отдельно хранить надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2013, 17:24 |
|
||
|
Иерархические структуры в реляционной БД & нормализация
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинkamenjahrАтомарность всегда однозначна. Нет. В Вашей же цитате приводится пример данных, которые атомарны для одной задачи и неатомарны для другой. P.S. Давно уже говорю, что фетиш "специалиста по БД нужно оценивать по нормализации" - вреден. Народ заучивает определения форм, не задумываясь над ними, и в результате получается вот такое. В моей цитате приводятся примеры отдела кадров, где "Адрес" атомарен и издательского рынка, где "Адрес" не атомарен. Но атомарность тем не менее всегда однозначна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2013, 17:38 |
|
||
|
Иерархические структуры в реляционной БД & нормализация
|
|||
|---|---|---|---|
|
#18+
guest_20040621> стандартный рассматриваемый в дцати учебниках вариант вообще-то Хороший повод выбросить эти учебники. > Теперь зададимся вопросом, а атомарен ли аттрибут name Перефразировать его можно так: я назвал какую-то хрень какой-то хренью, правильно ли я сделал? Конечно, правильно: предполагается, что вы - свободный человек и живете в свободном государстве, т. е. можете делать все, что не запрещено законодательством. Но на самом деле вопрос следует задать по-другому: решает ли предложенный вариант поставленную задачу? Нет, не решает. > Введу цитато-определение Не читайте то, что пишут на заборах. > Следовательно таблица не нормализована. Это неправильный вывод, вам уже сказали. Упираться рогом в стену - плохой метод ведения дискуссий. А нуда, если теория неудобная и противоречит первому-правилу буравчика кулибиных -фтопку эту теорию с учебниками Что есть правильный и не правильный вывод я поверяю сообразно определениям. Касаемо метода ведения дискуссий: я в юбилейный дцатый раз повторяю: мне безразлично мнение участников сикв.ру по поводу вопросов, которые я изначально не задавал . А на сформулированный мной вопрос участники кстати ответа не дали вообще.то. Такие дела. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2013, 17:44 |
|
||
|
Иерархические структуры в реляционной БД & нормализация
|
|||
|---|---|---|---|
|
#18+
Cane Cat FisherkamenjahrЕсли же разделить размерность и наименование - смысл потерян не будет . Потерян будет. Хотя бы потому, что поиск телевизора по названию становится невозможным. Один телевизор может называться Ultra-Plasma 62'', другой Ultra-Thin 2.5'', третий Ultra-Light-0.5 (кг), а четвертый Ultra-2012. и что, везде ради нормализации уберете диагональ, толщину, вес и год? Тогда уж и названия Windows-95, Windows-98, Windows Millenuim и Windows 7 надо разделять. Мораль: Включение в атрибут "название" некоторых других, рыночно-звучных атрибутов не приводит к нарушению 1НФ "названия" в целом. Холодное с мягким сравниваете, резину на глобус тянете: Из того, что существует название операционной системы с цифирью, не следует, что что всё рыночное теперь в названии цифири иметь будет. Кроме того, поиск по названию будет возможен, потому что само название никуда не делось:-)) До сих пор название не содержало (не) функциональные параметры в виде веса, размера и цвета:-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2013, 17:51 |
|
||
|
Иерархические структуры в реляционной БД & нормализация
|
|||
|---|---|---|---|
|
#18+
kamenjahrВ моей цитате приводятся примеры отдела кадров, где "Адрес" атомарен и издательского рынка, где "Адрес" не атомарен. Но атомарность тем не менее всегда однозначна. Строка адреса " Ул. Никитская, д.4, стр. 1" - для отдела кадров атомарна, а для издательсткого рынка нет. Для одной задачи ее нужно разбивать на поля, для другой - нет. И в чем однозначность? Вы собирались делать выводы про атомарность/неатомарность только по данным , не интересуясь задачей. Вам все говорили, что это неадекватно, в отрыве от задачи нельзя сказать, атомарно или нет значение " Ул. Никитская, д.4, стр. 1" или " TV Philips 24''". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2013, 17:54 |
|
||
|
Иерархические структуры в реляционной БД & нормализация
|
|||
|---|---|---|---|
|
#18+
InkelyadЧто-то я не понимаю, о чем спор идет. Все равно же информация о размерности, весе, технологии будет рядом в отдельной таблице лежать. Ибо в названии "Ultra TV Deluxe", скажем, никакой информации о размерности нет. Ее отдельно хранить надо. "Ибо в названии "Ultra TV Deluxe", скажем, никакой информации о размерности нет." - угу! Но вот в этой статье , которую мне предложили, таблица выглядит вот так Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Обратите внимание вооот на это Super-LCD 42" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2013, 17:56 |
|
||
|
Иерархические структуры в реляционной БД & нормализация
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2013, 18:01 |
|
||
|
Иерархические структуры в реляционной БД & нормализация
|
|||
|---|---|---|---|
|
#18+
Arhat109kamenjahr, ув. аффтар! Это: "Если в реляционной БД отображают иерархические структуры данных (Tree leaf pattern), то что, нормализация данных "поламает" сию иерархическую структуру?" и это: 13982058 и это (там же): "кроме того, телевизиры смешаны с мп3 плеэрами, т.е таблица не нормализована" взаимоНЕсвязанные вопросы . Если это НЕ понятно, то ещё раз, с конца: 1. Строка наименования товара (теловизуры там или МПР3-плюеры - и пофиг на дюймовость) - это всего лишь строка символов в заданной кодировке... и НЕ может быть "нормализована", в силу своей атомарности. Банально - некуда... если, использование строки происходит "целиком" как строки текста. 2. Набор строк в том посту - может быть сложной структуры и требовать нормализации... только (и только) если их использование требует выделения параметров строки (в том примере дюймовости телевизоров) и обработки отдельных праметров как сущностей с которыми работает конечное ПО. Тогда такой набор строк, возможно(!) требует нормализации в виде разделения строки на наименование товара и его набор параметров (в отдельную таблицу, и возможно даже не одну). 3. Хранение в БД иерархии объектов - никак НЕ связано с процессом нормализации строк означенного примера. Соответственно "поломать" там нечего. Задача хранения иерархии - показать взаимозависимость записей(кортежей), задача нормализации - уменьшения избыточности хранимых данных... это "попердикулярные" задачи ваще-то. Как улучшение бензобака автомобиля (нормализация данных) может поломать задачу "перевозить груз" (необходимость иметь кузов) :) По поводу п.1 и п.2 я уже предложил. нах все нормализации и всякие-там-столбцы-немеряно: два столбца айди и СТРОКА - достаточно!!! По поводу п.3 - спасибо. В ходе "Нормализационной дискуссии" я уж это понял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2013, 18:08 |
|
||
|
Иерархические структуры в реляционной БД & нормализация
|
|||
|---|---|---|---|
|
#18+
kamenjahrОбратите внимание вооот на это Super-LCD 42" Что вполне может означать здоровенный уличный телевизор толщиной 42''. Те внятной информации о размерности тут нет. Исключительно названия. Которые могут интерпретироваться как содержащие это информацию применением контекста. Но тогда этот контекст надо тоже куда-то в базу положить (в таблицу правил парсинга названий, скажем). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2013, 18:15 |
|
||
|
Иерархические структуры в реляционной БД & нормализация
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинkamenjahrВ моей цитате приводятся примеры отдела кадров, где "Адрес" атомарен и издательского рынка, где "Адрес" не атомарен. Но атомарность тем не менее всегда однозначна. Строка адреса " Ул. Никитская, д.4, стр. 1" - для отдела кадров атомарна, а для издательсткого рынка нет. Для одной задачи ее нужно разбивать на поля, для другой - нет. И в чем однозначность? Вы собирались делать выводы про атомарность/неатомарность только по данным , не интересуясь задачей. Вам все говорили, что это неадекватно, в отрыве от задачи нельзя сказать, атомарно или нет значение " Ул. Никитская, д.4, стр. 1" или " TV Philips 24''". Конечно, марсианину или еще-кому с планеты З, будет тяжеловато разобраться в Земных реалиях, но мы же с вами имеем же контекст - вполне конкретную статью, которая хотя и не содержит ТЗ, но все же по тексту следует же, что аффтар статьи не собирается лингвистиками заниматься или номера в корень возводить. Просто, при преведении примера он ежика-с-ужом смешал. А в жизни, в реальной жизни (а ее виртуальном представлении на сиквл.ру) покупатель интересуется маркой, габаритами, весом тем же, технологией. И продавцу мало поможет инфо, представленное в_одной-строке в одном столбце, в одном атрибуте. Он не может отсортировать по тому же размеру (а сортировка по размеру, это типовая задача вообще-то в "Магазинном" деле) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2013, 18:16 |
|
||
|
Иерархические структуры в реляционной БД & нормализация
|
|||
|---|---|---|---|
|
#18+
InkelyadkamenjahrОбратите внимание вооот на это Super-LCD 42" Что вполне может означать здоровенный уличный телевизор толщиной 42''. Те внятной информации о размерности тут нет. Исключительно названия. Которые могут интерпретироваться как содержащие это информацию применением контекста. Но тогда этот контекст надо тоже куда-то в базу положить (в таблицу правил парсинга названий, скажем). Могло бы , если бы не было иных данных "вышее" в том же столбце в той же таблице. А также если бы текста статьи не было бы . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2013, 18:22 |
|
||
|
Иерархические структуры в реляционной БД & нормализация
|
|||
|---|---|---|---|
|
#18+
kamenjahrМогло бы , если бы не было иных данных "вышее" в том же столбце в той же таблице. А также если бы текста статьи не было бы . Про что и говорю. Знания/данные о том, что это именно нужная нам размерность появляются с применением контекста. До тех пор, пока этого контекста в базе (или в программах, ее использующих) нет - в базе нет и этих данных. В случае статьи нормализация, выходит, не нарушается до тех пор, пока мы никуда в программу не добавили способность понимать, что строка ' 42" ' в названии - это нужный нам размер. Как только добавим - появится дублирование информации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2013, 18:33 |
|
||
|
Иерархические структуры в реляционной БД & нормализация
|
|||
|---|---|---|---|
|
#18+
> если теория неудобная Теория удобная. Но очень много баранов, которые вместо изложения теории занимаются ее интерпретацией. И даже пишут учебники. Вместо таких учебников и статей про паттерны читать следует Дейта. > я поверяю сообразно определениям Боюсь, вы и определения правильно интерпретировать не в состоянии. > я изначально не задавал Вам очень тактично пытаются объяснить, что заданный вами вопрос "мягкое - оно теплое или сладкое?" некорректен. На него объективно не существует ответа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2013, 18:42 |
|
||
|
Иерархические структуры в реляционной БД & нормализация
|
|||
|---|---|---|---|
|
#18+
InkelyadЧто-то я не понимаю, о чем спор идет. У меня окрепло ощущение, что кое-кто удачно троллит оставшихся. Inkelyad Все равно же информация о размерности, весе, технологии будет рядом в отдельной таблице лежать. Может быть будет. Может - не будет. А весьма вероятно - для телевизора Ultra LCD 42" рядом в отдельной таблице будет лежать диагональ 41.2 дюйма, причём в сантиметрах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2013, 19:23 |
|
||
|
Иерархические структуры в реляционной БД & нормализация
|
|||
|---|---|---|---|
|
#18+
InkelyadkamenjahrМогло бы , если бы не было иных данных "вышее" в том же столбце в той же таблице. А также если бы текста статьи не было бы . Про что и говорю. Знания/данные о том, что это именно нужная нам размерность появляются с применением контекста. До тех пор, пока этого контекста в базе (или в программах, ее использующих) нет - в базе нет и этих данных. В случае статьи нормализация, выходит, не нарушается до тех пор, пока мы никуда в программу не добавили способность понимать, что строка ' 42" ' в названии - это нужный нам размер. Как только добавим - появится дублирование информации. простите покорно ,о если вы уже на стадии программы начали редизайн базы данных,а не на концептуальном этапе,то это уж поздно слишком. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2013, 19:32 |
|
||
|
Иерархические структуры в реляционной БД & нормализация
|
|||
|---|---|---|---|
|
#18+
kamenjahrОбратите внимание вооот на это Super-LCD 42" А Вы обратите внимание на "CD To go!" и скажите где у него размер. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2013, 20:58 |
|
||
|
Иерархические структуры в реляционной БД & нормализация
|
|||
|---|---|---|---|
|
#18+
kamenjahr, я предложил стандартный рассматриваемый в дцати учебниках вариант вообще-то. А в ответ только лузлы с расчленением телефонных номеров и абревиатур. Учебники тоже бывают хорошие и плохие. атомарность всегда однозначна. Иное дело, что совокупность атомарных объектов объединяют с целью, например быстродействие увеличить, шоб до дцати таблицам не бегать и не джойнить. Нет, увы, атомарность неоднозначна, н так просто все, пример с телефонами я уже привел. Все зависит от постановки задачи и операций над доменами полей, они определяют атомарность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2013, 22:59 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=38168474&tid=1541328]: |
0ms |
get settings: |
7ms |
get forum list: |
21ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
28ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
94ms |
get tp. blocked users: |
2ms |
| others: | 216ms |
| total: | 393ms |

| 0 / 0 |
