Сотрудник утверждает, что хранение сериализованной строки данных в базе данных не нарушает 1NF

Question

1NF требует, чтобы поля были атомарными;то есть оно должно представлять только одно значение.

Он говорит, что, поскольку он не ожидает, что данные будут доступны для поиска или чтения, тогда это не будет нарушением нормальной формы, и что значение представляет собой однообъект.

Прав ли он?

Answer 1

Определить «атомарный».

Последние достижения в теории показывают, что понятие «атомарность», на котором основано определение 1NF (как обычно понимается), является расплывчатым и, вероятно, вообще неопределимым.

Например, координата на карте, это "атомное" значение?Обычно такое значение имеет четко видимые компоненты «X» и «Y», и значение этих компонентов может быть «извлечено» из «вашего» атомарного значения.И если что-то может быть «извлечено» из чего-то другого, то есть подозрение, что это «что-то еще» является «атомарным» в обычном смысле этого слова (т.е. не подлежит дальнейшему разложению).

используя значение типа "координата на карте", то в нарушение 1NF, именно по этой причине?Эту позицию трудно поддерживать.

По этим причинам, одна строка, содержащая список CSV, формально не нарушает 1NF.Это не означает, что на самом деле проектирование ваших баз данных на этой основе - очень хорошая идея.В большинстве случаев этого не будет.Но, формально говоря, он не нарушает 1NF (или что-то от него осталось).

Answer 2

Строка - это одно значение. Тот факт, что он может быть разбит на более мелкие строки, не означает, что вы нарушаете 1NF. Если вы кодируете большое количество информации в строки, то, возможно, вы не пользуетесь всеми преимуществами своих функций СУБД (то есть возможностью запрашивать данные и применять к ним ограничения), но это другой вопрос.

Answer 3

Да, ваш коровник прав.

В настоящее время считается, что одно значение может быть сколь угодно сложным.Это может быть даже стол.(В книгах Криса Дейта ищите «относительный атрибут».) Даты и временные метки являются отдельными значениями, но они оба имеют внутреннюю структуру.

Но если тип имеет , имеет внутреннюю структуруdbms либо игнорирует эту внутреннюю структуру (как SQL делает, если вы SELECT CURRENT_TIMESTAMP), либо предоставляет функции, которые работают с этой внутренней структурой (как SQL делает, если вы SELECT EXTRACT(YEAR FROM CURRENT_TIMESTAMP)).

Ключ в том, что пользователю не нужно писать процедурный код для манипулирования содержимым этой внутренней структуры.Либо dbms предоставляет эти функции, либо разработчик базы данных, который создает новые типы, предоставляет эти функции.

Answer 4

Проблема в том, что одно значение часто может быть фактически разложено на отдельные значения в зависимости от контекста (например, varchar может иметь много значений char, а число с плавающей запятой может бытьдва отдельных номера).Если сериализованные данные не относятся к отношению, представляемому таблицей, то их можно считать 1НФ.

Поле Address может содержать название улицы и город в общей таблице ContactInfo, но поле не будет считаться атомарным в таблице Addresses, которая будет иметь отдельные атрибуты для названия улицы, города, почтового индекса и т. Д.