|
|
|
Критерий правильности проектирования нормализованой реляционной БД
|
|||
|---|---|---|---|
|
#18+
Я про нормальные формы слышал Но мне кажется, что должна быть универсальная формулировка, а не пошаговое определение соответствия 1..5 форме. Старшно я сейчас далек от математики и не могу подтвердить свои слова теоретическими выкладками. Однако, на практике утверждение: Любая комбинация полей в одной строке результата запроса должна получаться одним единственым способом меня ни разу не подводило. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2005, 14:28 |
|
||
|
Критерий правильности проектирования нормализованой реляционной БД
|
|||
|---|---|---|---|
|
#18+
Совсем упустил из виду то, что для меня кажется очевидным Любая комбинация полей, имеющих смысл для потребителя, в одной строке результата запроса должна получаться одним единственым способом То есть суррогатные ключевые поля выводятся за рамки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2005, 14:39 |
|
||
|
Критерий правильности проектирования нормализованой реляционной БД
|
|||
|---|---|---|---|
|
#18+
Cat2Совсем упустил из виду то, что для меня кажется очевидным Любая комбинация полей, имеющих смысл для потребителя, в одной строке результата запроса должна получаться одним единственым способом То есть суррогатные ключевые поля выводятся за рамки. Насчет суррогатных ключей "за рамки". Действительно, за рамки, если генерить их не взирая на наличие/отсутствие естественного PK или AK. Если же исходить из принципа "Суррогатный ключ подменяет существующий естественный, т.е. обязательно наличие PK или AK", то он останется как раз "в рамках". В остальном - согласен, если варианты операций (например OUTER JOIN-> UNION) считать одним и тем же способом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2005, 15:04 |
|
||
|
Критерий правильности проектирования нормализованой реляционной БД
|
|||
|---|---|---|---|
|
#18+
5 НФ поглощает 2, 3НФ (НФБК) и 4НФ. Поэтому определение 5НФ - универсальная формулировка, не ссылающаяся на них. На самом деле шагов до 5НФ два: 1НФ - таблица плоская, 5НФ - не стану переписывать, см. Дейта например. Что означает "получаться одним единственым способом" ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2005, 15:35 |
|
||
|
Критерий правильности проектирования нормализованой реляционной БД
|
|||
|---|---|---|---|
|
#18+
ModelRЧто означает "получаться одним единственым способом" ?Кажется у Дейта есть формулировка - "один факт в одном месте" :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2005, 15:54 |
|
||
|
Критерий правильности проектирования нормализованой реляционной БД
|
|||
|---|---|---|---|
|
#18+
Jimmy. Насчет АК - запутаная история. Их быть вроде не должно. Так как они предполагают однозначный доступ к данным ДРУГИМ способом. Вот индексы - могут быть. Однако в своей формулировке я делаю упор на извлечение одной строки. outer JOIN и тем более UNION в общем случае направлены на получение набора строк. А в частном - получение одной строки вроде попадают под мое определение. И про UNION. В теории ничего не говорится о запрете иметь однотипные таблицы. Вроде они все попадают под правила Кодда. По крайней мере их наличие в базе не противоречит правилу, что любые данные должны быть получены по имени таблицы, имени столбца и PK. Однако вряд ли кто-то, кроме любителей Fox, скажет, что это правильно и полезно. Название таблицы у них неявно является частью PK. Что противоречит принципу хранения всех данных в едином каталоге,я читаю это как "единообразно" Другое дело UNION нескольких Select. Нормальный механизм. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2005, 16:07 |
|
||
|
Критерий правильности проектирования нормализованой реляционной БД
|
|||
|---|---|---|---|
|
#18+
ModelR . Не все базы имеют необходимость в нормализацции выше третьей формы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2005, 16:08 |
|
||
|
Критерий правильности проектирования нормализованой реляционной БД
|
|||
|---|---|---|---|
|
#18+
ChA ModelRЧто означает "получаться одним единственым способом" ?Кажется у Дейта есть формулировка - "один факт в одном месте" :)Но добраться до него в БД можно многими путями. авторНасчет АК - запутаная история. Их быть вроде не должно. Так как они предполагают однозначный доступ к данным ДРУГИМ способом. Вот индексы - могут быть.Т.е.предлагается запретить альтернативные ключи? Но, во-первых, если они присущи данной таблице, и данные в ней корректные, то запрос по этим полям все равно вернет одну запись объявлены они или нет. Во-вторых, наличие двух и более ключей никак не противоречит нормализации - не создает аномалий обновления. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 10:22 |
|
||
|
Критерий правильности проектирования нормализованой реляционной БД
|
|||
|---|---|---|---|
|
#18+
Процесс нормализации нужен для того, чтобы уяснить для себя, что это такое – нормализованная база. Опытный разработчик практически никогда не проходит все шаги, а сразу "инстинктивно" создает базу в нормальной форме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 16:54 |
|
||
|
Критерий правильности проектирования нормализованой реляционной БД
|
|||
|---|---|---|---|
|
#18+
> Процесс нормализации нужен для того, чтобы уяснить для себя, что это такое – > нормализованная база. Опытный разработчик практически никогда не проходит > все шаги, а сразу "инстинктивно" создает базу в нормальной форме. Определенно, сегодня везет на неологизмы. Вот Вы, уважаемый, считаете себя опытным разработчиком? Изложите, пожалуйста, Ваш "инстинктивно" нормализованный вариант структуры данных для описания... хм.... ну, чтобы было совсем просто, - internet-based ресурсов. А потом мы обсудим предложенный Вами вариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 18:23 |
|
||
|
Критерий правильности проектирования нормализованой реляционной БД
|
|||
|---|---|---|---|
|
#18+
ModelR 5 НФ поглощает 2, 3НФ (НФБК) и 4НФ. Поэтому определение 5НФ - универсальная формулировка, не ссылающаяся на них. На самом деле шагов до 5НФ два: 1НФ - таблица плоская, 5НФ - НФБК - имеет проблемы с навязыванием F-зависимостей схеме с помощью выделения ключей, в отличии от 3НФ. Поэтому проектировщик стоит перед выбором ограничения целостности декларативным способом или подавление избытка с помощью НФБК. Проверка свойств НФБК для заданной схемы является NP - полной задачей. В литре иногда упоминается, что и в 5НФ могут быть скрытые аномалии. И приводится упоминание Доменно-ключевой нормальной формы ДКНФ (Фагин, 1981) R.Fagin "A Normal Form for Relation Databases That Is Based On Domain and Keys" ACM Transactions on Database System, сентябрь 1981, с.387-415 Это форма лишена всех аномалий, но не известен ни один алгоритм приводящий к ДКНФ. На практике, скорее всего, во многих задачах схема в 3НФ, скорее всего удовлетворяет и остальным формам. Зато если схема не находится в 3НФ - это достаточно заметно. Так или иначе, часто от СУБД рекомендуется тока нормализация до 3НФ. И это вроде ответ на какой-то экзаменационный вопрос от MS. По моему по Аксцессу, но возможно и по Скулю. А ведь есть еще денормализации. Скорее всего критериев самой оптимальной схемы не найдено. И все зависит от искусства проектировщика. И в общем случае он может без знания теории и нормальных форм налабать схему, такую же по оптимальности, как другой с помощью теории. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 22:19 |
|
||
|
Критерий правильности проектирования нормализованой реляционной БД
|
|||
|---|---|---|---|
|
#18+
Cat2Jimmy. Насчет АК - запутаная история. Их быть вроде не должно. Так как они предполагают однозначный доступ к данным ДРУГИМ способом. Вот индексы - могут быть. Ну, если есть суррогатные ключи, то альтернативные должны быть по определению. Пусть даже таковые будут состоять из комбинации всех остальных атрибутов. Cat2В теории ничего не говорится о запрете иметь однотипные таблицы. Вроде они все попадают под правила Кодда. По крайней мере их наличие в базе не противоречит правилу, что любые данные должны быть получены по имени таблицы, имени столбца и PK. Однако вряд ли кто-то, кроме любителей Fox, скажет, что это правильно и полезно. Название таблицы у них неявно является частью PK. Что противоречит принципу хранения всех данных в едином каталоге,я читаю это как "единообразно" Другое дело UNION нескольких Select. Нормальный механизм. Fox здесь ни при чем, собственно. ;-) И уж если у кого-то из фоксовиков название таблицы неявно является частью PK, то этот выпендрежник рискует огрести проблем и в фоксе, и очень неожиданно, кстати. Но что Фокс такие вольности позволяет, это конечно. Фокс, кстати, реляционная БД примерно настолько же, насколько и Oracle. Захочет разработчик - будет его система реляционной, не хочет - будет возиться с таблицами совсем без PK. Это я к тому, что обе не удовлетворяют всем 12 правилам РБД, а не ради сравнения, упаси Господи ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 23:09 |
|
||
|
Критерий правильности проектирования нормализованой реляционной БД
|
|||
|---|---|---|---|
|
#18+
> И в общем случае он может без знания теории и нормальных форм налабать > схему, такую же по оптимальности, как другой с помощью теории. О, еще один боец. Присоединяйтесь. Задача та же: структура данных для описания internet-based ресурсов. Критерий правильности выполнения: в рамках приведенной структуры предложу описать десяток простеньких ресурсов. Вопросы по задаче есть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 23:24 |
|
||
|
Критерий правильности проектирования нормализованой реляционной БД
|
|||
|---|---|---|---|
|
#18+
[quot guest_20040621О, еще один боец. Присоединяйтесь. Задача та же: структура данных для описания internet-based ресурсов. Критерий правильности выполнения: в рамках приведенной структуры предложу описать десяток простеньких ресурсов. Вопросы по задаче есть?[/quot] Нет уж, надо сформулировать задачу яснее: где полный набор атрибутов, желаемых для имения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 23:31 |
|
||
|
Критерий правильности проектирования нормализованой реляционной БД
|
|||
|---|---|---|---|
|
#18+
> Нет уж, надо сформулировать задачу яснее: где полный набор атрибутов, желаемых для имения? Описывайте те, которые считаете нужными. Или еще проще: разверните перечень атрибутов по вертикали, - так устроит? Оглянитесь. Вокруг - Сеть. Все, что я собираюсь описывать, Вы имеете возможность рассмотреть точно так же, как и я. Любой элемент Сети. ;) Hint № 1: Вы задали несущественный для реализации вопрос. Альтернативный подход: возьмите любой похожий сервис (такой, который описывает элементы Сети) и проанализируйте его полноту, сильные и слабые стороны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2005, 00:22 |
|
||
|
Критерий правильности проектирования нормализованой реляционной БД
|
|||
|---|---|---|---|
|
#18+
guest_20040621Hint № 1: Вы задали несущественный для реализации вопрос.;-))))))))))))) Лично мне будет достаточно списка ресурсов в двух колонках в Excel-е (адрес и описание). Вот, пожалте, система об одной табличке: адрес - PK. Достаточно ли нормализована? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2005, 00:37 |
|
||
|
Критерий правильности проектирования нормализованой реляционной БД
|
|||
|---|---|---|---|
|
#18+
> Лично мне будет достаточно списка ресурсов в двух колонках в Excel-е (адрес и описание). > Вот, пожалте, система об одной табличке: адрес - PK. Достаточно ли нормализована? Главное, чтобы Вас этот вариант устраивал. Устраивает? Вот и чудненько. Пожалуйста, опишите в Вашей структуре данных vpn. Упс. Минус боец. Еще желающие поделиться инстинктивно созданными структурами данных? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2005, 00:53 |
|
||
|
Критерий правильности проектирования нормализованой реляционной БД
|
|||
|---|---|---|---|
|
#18+
Вот и я увидел такую же кривую ухмылку на собеседовании при ответе о нормализации. Тогда я попросил набор сущностей, атрибутов и связей между сущностями. После того как я нарисовал все это сразу в нормализовано виде, ухмылка исчезла… Но учтите, нормализовывать вашу базу на халяву я вам не буду :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2005, 17:43 |
|
||
|
Критерий правильности проектирования нормализованой реляционной БД
|
|||
|---|---|---|---|
|
#18+
> Но учтите, нормализовывать вашу базу на халяву я вам не буду Чего вдруг Вы решили, что кто-то нуждается в Ваших услугах? Вас вежливо просят не писать х#%ни, вот и все. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2005, 09:03 |
|
||
|
Критерий правильности проектирования нормализованой реляционной БД
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Но учтите, нормализовывать вашу базу на халяву я вам не буду Чего вдруг Вы решили, что кто-то нуждается в Ваших услугах? Вас вежливо просят не писать х#%ни, вот и все. ох не смог удержаться и не ответить заносчивому товарищу :) так вот, утверждение о том, что "опытный проектировщик создаёт сразу нормализованную базу" абсолютно верно. это не значит что она сразу будет ИДЕАЛЬНО нормализована. есс-но, будет и дальнейшая работа, и возможно денормализация. вы видно не совсем понимаете, что такое "нормализация", и не знаете, что есть ДКНФ :) стоит почитать литературку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2006, 15:28 |
|
||
|
Критерий правильности проектирования нормализованой реляционной БД
|
|||
|---|---|---|---|
|
#18+
Что-то вспоминается по лит-ре в школе когда-то проходили, на тему Герцена и декабристов, что дескать страшно далеки они от народа... От точно то же можно сказать и о всей теории нормалицации - страшно далека она от практики... Знать может ее и полезно (правда ни разу в жизни мне она не помогла кроме собеседований) но толку от этого о-о-о-чень мало... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2006, 15:48 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=33200544&tid=1545451]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
406ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
| others: | 209ms |
| total: | 710ms |

| 0 / 0 |
