Должен ли SQL VIEW всегда быть в 1NF?

Question

SQL VIEW - это глобальная логическая таблица, которая может сохраняться или не сохраняться. Но это все еще стол. Следовательно, должен ли VIEW всегда придерживаться первой нормальной формы (1NF)? т.е. нет дублирующихся строк, только скалярные типы, нет упорядочения сверху вниз или слева направо и т. д. Как насчет высших нормальных форм?

Для меня мои приложения «потребляют» результаты сохраненных процедур, мои VIEW «потребляются» запросами SQL, и эти два использования являются взаимоисключающими (т.е. я не запрашиваю наборы результатов хранимых процедур с использованием SQL и моего приложения не содержат код SQL). Я видел, как другие использовали VIEW, чтобы «объединить» несколько значений в столбце в одну строку, обычно в формате с разделителями-запятыми. Для написания предикатов в SQL-запросе для такого столбца требуется ключ, подобный следующему:

',' + concat_col + ',' LIKE '%' + ',' + search_value + ',' + '%'

Так что мне кажется разумным ожидать, что все таблицы, которые можно запрашивать, состоят только из скалярных типов. Думаю ли я, что я слишком «пурист»?

Answer 1

Нет - я создаю представления, соответствующие выводу, который требуется моей программе.

Answer 2

Суть реляционных систем в том, что вы сохраняете данные в нормализованных отношениях для эффективности и / или управляемости, а затем используете реляционные операторы для преобразования их в нужные вам отношения.

Нематериализованное представление не сохраняется, это запрос.

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

См. этот ответ для более подробной информации.

Answer 3

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

Э. Ф. Кодд не обязательно соглашался, хотя. В своей книге RM версии 2 он предлагает разрешить просмотр без ключей - я думаю, что это большая ошибка. Представления Кодда на самом деле не допускают дубликатов, но они позволяют обнулять каждый столбец и, следовательно, не имеют ключей и не находятся в 1NF.

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

Answer 4

Согласно Крису Дейту, представления должны быть полностью нормализованы:

Выбор относительно того, какие отношения вы делаете базовыми и какие взгляды, является произвольным. В качестве тривиального примера у вас могут быть сотрудники, и у вас может быть базовое отношение, содержащее всех сотрудников, и у вас могут быть сотрудники Восточного побережья и сотрудники Западного побережья как два представления. Или вы можете иметь сотрудников Восточного побережья и Западного побережья в качестве двух базовых отношений и получить объединение всех их в качестве представления. Это совершенно произвольно.

Интервью СУБД с Крисом Дата - октябрь 1994

Answer 5

Я не думаю, что это правило, но если оно было ... Ни одно из правил не должно всегда выполняться.

Answer 6

Нет - правила нормализации применяются к постоянству данных, а не к их представлению. Например, любые повторяющиеся строки в представлении нарушат 1NF, что явно чрезмерно ограничительно.

Для получения дополнительной информации см. Первая нормальная форма .

Answer 7

представление (если оно не материализовано / не проиндексировано) - это не что иное, как хранимый запрос Представления могут содержать более одной таблицы, могут иметь самостоятельные объединения в одну и ту же таблицу и т. Д.