Требуется ли нормализация в этой таблице?

Я создаю таблицу, и у меня есть постоянное имя C, которое будет заполняться следующим образом: (CA, CB, CC ...)

Все столбцы должны быть заполнены пользователем (кроме идентификатора, который автоматически нумеруется):

ID | NUMBER | NIT | CA | CB | CC | ... | CZ

Как вы могли заметить, к "C" можно применить нормализацию, например:

ID | NUMBER | NIT | C
-  | -      |  -  | A
-  | -      |  -  | B
-  | -      |  -  | C
-  | -      |  -  | ...
-  | -      |  -  | Z

Нужна ли здесь нормализация? Предпочтительнее обрабатывать строки C вместо столбцов, как думала первая таблица?

Я хотел бы прочитать рекомендации или передовой опыт для решения этой проблемы.

Привет. «теоретически, теперь пользователю придется писать« имена »C» & «ограничивает меня, потому что эта таблица [связана] с другой» неясны. Кроме того, кавычки вокруг слова дают или проясняют нестандартное значение или конкретный случай, который у вас в голове. PS Нормализация (до «1НФ») не имеет одного значения, и многие «значения» неясны или бессмысленны.

philipxy 10.09.2018 01:10

Вам необходимо предоставить: желаемый уровень нормализации и полный список определяющих факторов для схемы, которую вы опубликовали. Нет такой вещи, как просто «нормализованное» отношение. Есть уровни нормализации, и вам нужно выбрать тот, который вам нужен.

nicomp 10.09.2018 01:46

@nicomp "Нормализованный" имеет два общих значения. Первый - «нормализован к 1NF» (это первое значение) и «нормализован к более высоким NF» (поскольку были определены «1NF» и выше). См. Ссылку в моем предыдущем комментарии.

philipxy 10.09.2018 02:11

Сейчас это более неясно. Как вводный пример связан с реальным дизайном? Вы переходите от множества похожих столбцов к одному столбцу с (каким-то образом) большим количеством значений. PS Части, которые были непонятны, до сих пор неясны. PS Пожалуйста, используйте текст, а не изображения / ссылки для текста (включая код, таблицы и ERD). Используйте изображение только для удобства, чтобы дополнить текст и / или для того, что нельзя передать в тексте. И никогда не давайте диаграмму без легенды / ключа. Используйте функции редактирования для встраивания, а не ссылки, если у вас есть представитель - сделайте свой пост самодостаточным.

philipxy 10.09.2018 02:27

Я так понимаю, я кое-что проверю, этот пост со временем будет удален

dirojas 10.09.2018 02:52
ReactJs | Supabase | Добавление данных в базу данных
ReactJs | Supabase | Добавление данных в базу данных
Это и есть ваш редактор таблиц в supabase.👇
2
5
98
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Ответ принят как подходящий

"Требуется" нормализация?

Нормализация никогда не будет требуется, если вы не делаете проект для класса базы данных. Часто это хорошая идея. Он может упростить некоторые типы общих запросов и гарантирует, что данный элемент данных сохраняется один раз, что упрощает обновление. В вашем случае это также гарантирует, что добавление нового столбца «C» будет простым - просто еще одной строкой в ​​таблице, а не изменением таблицы.

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

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

nicomp 10.09.2018 02:00

Если [CA, CB ... CZ] являются отдельными атрибутами объекта, описанного в вашей таблице, то схема, похоже, удовлетворяет Первая нормальная форма.

Поскольку ваше описание абстрактное, трудно сказать, подойдет ли более сложная нормализация.

Другие вопросы по теме