Если Вы уверены, что возможно
iscrafm
Я тут за переводчика с нормального языка на книжный. Да, возможно:

То нормализовано - нет ФЗ: Name->ParentID.

Однко я не уверен, что про одну и ту же схему.



Имеет отношение к табле
В частности не вижу где здесь может быть ParentID. Но вроде должен содержать тип ID.

Я просил ответить именно про ту таблу, про которую был вопрос. А не про какие-то новые схемы, не известно откуда взявшиеся.
Или теперь новую схему нужно оптимизировать? А с первой то разобрались?

iscrafm
Да я просто нарисовал в квадратах те данные, которые Zoria написала текстом, какие еще новые схемы? Нет, Вы явно не читаете то, на что отвечаете.

На мои вопросы ответа не получил. Квадраты не нужны.
Она задала вопрос про то - находится ли конкретная табла в 3НФ. Я на этот вопрос и отвечаю. Там было только три атрибута. Вот нужно на те два последних вопроса (заданных в не "книжной" форме) ответить именно про эту таблу.

Вы говорили, что именно она не нормализована "если просто посмотреть на таблицу с точки зрения теории нормализации" (с) (да это новое в теории, так как на примере такого состояния ничего нельзя сказать находится она в 3НФ во всех возможных состояниях или нет). И откуда-то привистовали новые атрибуты. Нормализация не предполагает выявления новых свойств объектов, которые должны хранить в БД.

iscrafm
2 vadiminfo. Это надеюсь и на Ваш вопрос ответ тоже.


Если это

iscrafm
1 форум null
2 статьи null
3 sql 1
4 c# 1
5 sql 2
6 mysql 2

допустимое состояние, то таблица находится в 3НФ.

А Ваше утверждение
автор
не нормализованная таблица


Не верно. Потому что для id 3 и 5 значение поля Name = sql, а ParentID разные - 1 и 2: ФЗ Name->ParentID. Нет. Аналогично благодаря записям с id 3 и 4 нет ФЗ ParentID->Name. Стало быть о транзитивных зависямостях вообще не может быть речи, потому что есть зависмости только от одного атрибута ID.

Если Zoria подтвердит, что такие состояния допустимы, но ответ - таблица находится в 3НФ и остальные рассуждения iscrafm в его ответе не имеют смысла по отношению к 3НФ.

iscrafm
Ну вот и славненько. Когда столкнетесь с необходимостью заменить sql на ms sql расскажите как это у Вас получится в такой нормальной форме :)

А что мне рассказывать? Отношение находится в 3НФ. Избытка в нем нет - нельзя по значению одного атрибута вычислить значение другого в кортеже, зная что содержится в других. Т.е. если бы зная что раз в кортеже 3 для sql родитель = 1, то и 5 для sql родитель обязательно равен 1. То да избыточность информации на лицо.
Если Вы добавите справочник имен, с сурогратом, который в силу его суррогатности (иначе и его может пришлось бы менять) менять не надо - это не нормализация. Это вообще не вопрос теории РБД. Вместо имен можно сразу было поставить значения суррогатов. И тем ни менее, до того как Вы привели то состояние, вопрос о том находится ли отношение в 3НФ или нет оставался открытым. А как только привели - сразу ясно, что оно в 3НФ.
Примеры приводил.

iscrafm
Вы на одном условии остановились, по фз я и так вижу. А как же аномалии, в расчет не беруться? Именно к ним я и пытаюсь Вас подтолкнуть

Вопрос был про что? Про нормализацию по 3НФ? 3НФ строится на ФЗ.
Все остальные "аномалии" к нормализации отношения не имеют. Например, можно вообще создать таблу с одним полем Name и организовать каскадное обновление. Менять в этой табле sql на ms sql, в исходной все везде заменится. Я так делал на Аксцессе.
Можно суррогаты в справочнике - так на Оракле. Это уже вопросы работы приложения в целом влияют на логичесую схему БД. А та табла принципе останется той же. Все с тем же в принципе тремя полями.

iscrafm
Вообще-то вопросы возникновения аномалий (в данном примере обновления) и нормализации всегда рассматриватся в одном контексте.

Аномалии разные бывают. Нормальные формы, действительно, связанны со стремлением избавиться от аномалий. Но они имеют свои определения.
И в связи с 3Нф рассматривают аномалии обновления более тяжелые, которые могут привести, например, к нарушеню ФЗ. И в общем случае уже никакими справочниками помоч нельзя.


iscrafm
Да, Вы можете назвать это 3НФ, но только для того, чтобы себя потешить.
Не я придумывал нормальные формы, не мне называть ими что вздумается. По моему, это максимум 4 курс. Или что 3НФ не на ФЗ строится? Вы же признали про ФЗ.

iscrafm
А если для работы, то нужно делать декомпозицию на две проекции, исключать аномалии обновления и потом уже называть это нормальной формой.
Для работы не нужно делать декомпозицию в общем случае. Я писал выше. Добавление еще одной таблы - не есть декмпозиция.
А что нужно называть нормальной формой не нам с Вами решать. Как-то без нас решили.

vadiminfo
Да не останется она такой же, как только Вам потребуется добавить помимо заголовка меню еще хотя бы один атрибут, например цвет. Будете искать несогласованности и переделывать структуру каждый раз? А старина Кодд об этом упоминал. Вы сделали моментальный снимок структуры и на этом остановились. Это мертвая структура.

Мне не потребуется. В вопросе было про нормализацию той таблы. Мертвая она или нет - это вопрос из другой серии. Надо было спрашивать про не мертвую. Я не собирался исследовать всю задачу. Куда она том может развиваться. Када появится нарушение ФЗ тока тада и надо будет проводить декомпозицию. А цвет попадет в ту дополнительную справочную таблу. А эта так и останется.

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

И что с того? Если Вы придумаете свою нормальную форму в теории, устраняющую те или иные аномалии и ее признают стоящей, тогда про нее можно говорить. 3НФ к Вашей аномалии не имеет отношение. Имеет к другим, более тяжелым, которых в силу того, что таблица в 3НФ, возникнуть не может.
Надо же прежде чем вперед смотреть еще и с настоящим разобраться.

iscrafm
Я тоже.

Вы писали что надо. Либо Вы не совсем в курсах в каком смысле употребляется этот термин: Вынос имен в отдельную таблицу - не декомпозиция, а добавление новой таблы и изменение структуры исходной. Вы добавили новое поле суррогоат. Это что угодно, но только не декомпозиция нормализации 3НФ. Еще раз напомню, что можно, например, добавить таблу из одного поля и объявить ограничение ссылочной с каскадным обновлением. Т.е. без добавления новых атрибутов в схему для устранения той Вашей аномалии.
К нормализации это не имеет никакого отношения.
Зато я писал пример именно с нарушением 3НФ. И Ваш метод никак не устраняет ту аномалию.

iscrafm
Я обычно просто заранее такие варианты прорабатываю, чтобы потом не выполнять конветацию данных. На живых системах это не есть хорошо.

В общем случае для того чтобы нормализовать нужно исследовать ПО и выявлять зависмости между атрибутами. Однако ПО может быть динамичным. И в общем случае заранее все будующие атрибуты и зависмости выявить нельзя. Но нормальные формы типа 3НФ - не динамичны. Они описаны в литературе, нас им учили профессора, мы сдавали экзамены. И нет никаго смысла называть ими что придет в голову. Иначе те кто получали двойки потребуют пересмотра результатов экзаменов.

Тем более что Вашу аномалию, Ваша "нормализация" и не устраняет на все 100%
Вы исходите из того, что устранили ее введением атрибута, который менять не понадобится, по крайней мере, в нескольких местах первой таблы. А так ли это? Возможно понадобится. И придется менять в нескольких местах заменять 20 на 30. Тада вернулись к тому что было? Конечно, вероятность кажется меньше. Что бум в нормализации вероятности считать?
Каскадное обновление? Ну так оно декларативно даже не любой СУБД поддерживается. Т.е. прогу писать по массовой замене? Так я и запросом могу сразу это сделать. Да и где поддерживается декларативно - ну там тоже прога, тока производителем написанная по массовому обновлению при такой аномалии. Тогда как нормальные формы при устраненнии, например, аномалии обновления стремятся исключить необходимость просмотра записей в принципе: хоть программно, хоть "в ручную".

Тем более и ссылочная целостность не избавит в общем случае от просмотра всех записей в первой табле в общем случае.

vadiminfo
А что менять придется, если в таблице FK. А наименование меняйте хоть сто раз. Таблицу отношений пунктов меню при этом трогать не нужно. Зачем какие-то проги и каскадное обновление?

Сам суррогат. Например, во второй табле

1 sql
2 ms sql

в первой сотни 1 и 2 уже насобиралося. Решили что это не правильно. Нужно оставить только
2 ms sql
Что теперь? Просматирвать не придется в первой табле чтобы заменить 1 на 2?
Каскадное не поможет - во второй табле суррогат первичный ключь - не позволит заменить 2 на 1. Впрочем это детали. Программно я могу и запрос написать.

Опечатка не нозволит заменить 2 на 1.

Блин 1 на 2