FrankieЯ долго размышлял над вопросом: вот есть гонщик - "имя фамилия". Но ведь можно расщепить на имя+фамилия? Что это даст?Вопросо, безусловно, интересный, но подошли вы к ответу неверно. Атомарнось атрибутов - понятие не абсолютное, а относительное. То есть для одной системы ФИО атомарен, для другой нет. Для одной системы понятие "адрес" атомарно, для другой нет. Критерий состоит в том, какие операции предполагается выполнять над данными. Если система заведомо выполняет над атрибутом только операции типа сравнения (= <> < > <= >=), он может быть атомарным. Если хотя бы в потенциале возможны операции над частью атрибута, он не атомарен.

В вашем случае критерий срабатывает четко. Вы заведомо будуте выполнять операции над частью значения атрибута. Значит, вы неверно спроектировали БД. У вас нарушение 1НФ.

Вообще, если в запросах часто встречается LIKE, причем это предопределенные запросы , почти 100% - БД спроектирована неверно.

FrankieЧто такое предопределенные запросы? Те, которые очевидны на этапе проектирования? В общем, да.
FrankieИ почему LIKE это неверно?
Потому, что LIKE почти всегда свидетельствует именно о нарушении 1NF. Бывают исключения, но это обычно ad hoc запросы.
FrankieНе согласен, LIKE - мощная штука, глупо её игнорировать.
Знаете, хорошие фундаментальные знания - еще более мощная штука. Но ведь "мы простых путей не ищем", да?

guest_20040621
MirАтомарность атрибутов - понятие не абсолютное, а относительное.
Поделитесь источником этого умозаключения, pls.
Поделюсь, поделюсь. Хотя вам вполне ясно ответили:
TemplarАтомарность определяется рамками моделируемой предметной области.
Вы дали просто потрясающий ответ:
guest_20040621Понятно. Тогда это просто ошибочная точка зрения. То есть мы вам обязаны что-то обосновывать, а вы нам нет. Типа точку поставили в споре. Такой Большой Папа, мнение которого правильно по определению. Между тем, вам бы с базовыми знаниями определиться. Например:
guest_20040621Среди атрибутов очень много таких, которые на самом деле идентификаторы. ;)) Которые, конечно, абсолютно необязательно ключевые. То есть вы противопоставляете потенциальные ключи (ключевые атрибуты) и атрибуты идентификаторы? Большего бреда я в жизни не видел. К вашему сведению, ключевые атрибуты и атрибуты-идентификаторы — это одно и то же. Если только вы не имели в виду что-то совсем иное (вроде «ключевые» относится только к первичному ключу, но не обязательно к потенциальному ключу). В противном случае хотелось бы выслушать развернутую аргументацию по обоснованию вашего «открытия».
Далее:
guest_20040621Опыт показывает, что такие атрибуты правильнее описывать совершенно определенным образом (версионность, история изменений). И опыт показывает, что атомарность таких атрибутов не зависит (или мало зависит) от предметной области. Т. е. никакой "относительностью" не пахнет. ;))
То есть у вас «опыт», и он что-то там «показывает». Это очень сильный аргумент в споре. Прям наповал. Конечно же, ни у кого больше никакого опыта по определению быть не может (Большой Папа, помним, помним). Однако здесь заметно вот что. И я, и Templar рассуждали об атрибутах вообще, т.е. об общем случае. Вне зависимости от их принадлежности к потенциальным ключам. Вы же рассуждаете только о частных случаях:
*такие* атрибуты, атомарность *таких* атрибутов, *мало* зависит. И что значит «мало» зависит? Если зависит, что ж вы спорите? Если не зависит, при чем здесь «мало»? Это как быть «слегка беременной».

Ну а теперь я все же объясню, почему атомарность атрибутов отношений БД относительна, а не абсолютна.
1. Реальному миру атомарность не присуща. Если бы вы изучали системологию, то знали бы, что одним из главных постулатов теории систем является утверждение о том, что каждый элемент системы в свою очередь является системой. И так до бесконечности. Древние придумали понятие атома, неделимого элемента материи, но его давно уже разложили на элементарные частицы, а те не субчастицы и т.д.

2. Таким образом, идеальная модель реального мира должна обладать бесконечным уровнем детальности.

3. Реальные модели всегда являются «огрублением» моделируемой системы. Они сознательно игнорируют те или иные аспекты оригинала, неважные для цели моделирования. И они всегда рассматривают оригинал на том или ином уровне детальности. Это еще один постулат системологии.

4. Важный аспект моделирования — его цель. Поскольку модель есть артефакт, искусственная конструкция, заведомо упрощающая оригинал в том или ином аспекте, должна быть предопределена цель такого упрощения. Любая модель всегда создается в условиях заведомо известных и заранее выбранных ограничениях, направленных на достижение заданной цели. Если цель будет иной, то и модель той же самой системы-оригинала будет создана иной. Возможно, кардинально иной.

5. База данных в конечном итоге является моделью реального мира. Еще точнее можно сказать, что моделью «части» реального мира, или «одной из моделей», но это неважно.

6. База данных создается как упрощение реального мира, как и любая модель.

7. Создание базы данных всегда преследует определенную цель, задающую соответствующие ограничения, в том числе уровень детальности моделирования.

8. Таким образом атомарность атрибутов БД полностью определяется выбранным уровнем детальности моделирования, который в свою очередь полностью определяется конкретной целью создания БД.

9. Таким образом, атомарность атрибутов БД есть понятие не абсолютное, а относительное.

Почитайте, к примеру, классическую книгу Флейшман Б.С. Основы системологии. — М.: Радио и связь, 1982. — 368 с.

guest_20040621Я свои аргументы привел.Вы, видимо, называете аргументами следующие утверждения: guest_20040621Тогда это просто ошибочная точка зрения guest_20040621Вы делаете распространенную ошибку. guest_20040621 {ваше предложение}Абсолютно неактуально. guest_20040621У-у-у... напрасно Вы так. Этот пример еще хуже. ;)) guest_20040621У-у-у... все плохо. Снова бесполезный пример.

Пусть каждый судит сам, но мне набор подобных заявлений доказательным как-то не показался. На вполне резонный и конкретный пример Templar про ФИО вы ответили:
guest_20040621Я не телепат. Не сталкивался со структурой данных почтовых систем. Что и требовалось доказать.

Остальные ваши аргументы я уже рассмотрел в предыдущем посте. И выглядят они не лучшим образом. Ссылки на «опыт» не пойдут. Лично вас здесь никто не знает, опыт ваш никому из присутствующих не известен, даже регистрироваться на форуме вы почему-то не стали. А верить на слово, что у некой «маски» с ником guest_20040621 уж такой опыт, что всем опытам опыт...
А насчет красивых фраз «придется начинать со стандартов, метаданных, тезауруса» сразу вспоминается «я знаю карате, дзюдо и еще много страшных слов».
Знаете, как-то... хм, нехорошо после этого заявлять оппонентам, что у них «аргументы закончились», что «с ответными аргументами - как-то глуховато». Закончились у меня или Templarа аргументы, или не закончились, — ваши-то еще и не начинались. К сожалению, ваше любимое «У-у-у...» веским аргументом не выглядит.
guest_20040621Пожалуйста, продемонстрируйте, как будут меняться эти атрибуты (атомарность атрибутов) в зависимости от предметной области.
Рассмотрим один пример. Дата/время.
В одних случаях может использоваться как атомарный атрибут, в других желательно разбиение на дату и время, а иногда даже разбиение даты на год, месяц, день. Критерием является наличие/отсутствие необходимости постоянно оперировать частями даты (постоянные выборки по годам, по месяцам и т.д.).
Очевидно, что необходимость постоянно выполнять над датой операцию DATEPART не позволяет использовать индексы и сильно снижает производительность запросов. А если такие запросы составляют львиную долю работы, значит, рассматривать атрибут «дата/время» как атомарный нельзя, лучше разбить его на несколько атрибутов. Разумеется, это требует специальных мер по обеспечению корректности ввода/обновления, но это уже технические детали.
Таким образом, взгляд на «атомарность» даты/времени сильно меняется от задач системы. Пример системы с «атомарностью» — поле «дата рождения» в системе кадрового учета. Типовые операции — атомарное занесение, атомарное чтение, сравнение. Операции над частями даты редки или отсутствуют, над частью «время» — отсутствуют. Это и есть пример «огрубления» в модели. В реальном мире человек рождается в определенный час, минуту. Это время фиксируется в роддоме. А вот для кадрового учета этот аспект неважен — так и долой время рождения. Модель от этого не становится неадекватной, так как цель такой системы полностью достижима.
Пример систем с «неатомарностью» — производственные системы (часто как надстройки над АСУ ТП). Я этим лично занимаюсь. Данные поступают от датчиком и от ручного ввода потоком. Их надо прореживать. Виды отчетности по периодичности самые разные: за каждые два часа (двухчасовки), день, месяц, год, весь период. Операции выборки с условиями над отдельными частями даты и времени не исключение, а скорее правило.
И т.д.
Может, хватит спорить, Ясно же, что вы неправы, признайте честно. Зачем упорствовать?

guest_20040621P.S. Вы отметили, надеюсь, что я тактично проигнорировал Ваши хамские замечания и ответил исключительно по существу.
Дорогой вы мой человек! Не считаете ли вы хамство вот эти слова:
Мистер ВежливостьУ-у-у... дружище, начните, наконец, _изучать_ проектирование баз данных. Купите книжку, что-ли? Или репетитора наймите.
Раз вы первый перешли на такой тон, то и я позволил себе быть с вами... попроще. Впрочем, готов принести искренние извинения за некорректную фразу «Большего бреда я в жизни не видел». Переформулирую так:
Ваша мысль о том, что «есть атрибуты-идентификаторы, которые, конечно, абсолютно необязательно ключевые», мне кажется странной, нелогичной и требующей дополнительных разъяснений.