Хотелось бы понять 6NF с примером

Ответ 1

В двух словах 6NF означает, что каждое отношение состоит из ключа-кандидата плюс не более одного другого (ключевого или неключевого) атрибута. Чтобы взять ваш пример, если "Item" идентифицируется ProductCode, а остальные атрибуты - "Описание и цена", то схема 6NF будет состоять из двух отношений (* обозначает каждый ключ):

ItemDesc {ProductCode*, Description}
ItemPrice {ProductCode*, Price}

Это потенциально очень гибкий подход, поскольку он минимизирует зависимости. Это также является его главным недостатком, особенно в базе данных SQL. SQL затрудняет или затрудняет принудительное использование многих ограничений для нескольких таблиц. Используя приведенную выше схему, в большинстве случаев невозможно обеспечить соблюдение бизнес-правила, что каждый продукт должен всегда иметь описание И цену. Аналогичным образом, вы не сможете применять некоторые составные ключи, которые должны применяться (поскольку их атрибуты могут быть разделены на несколько таблиц).

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

Ответ 2

Я начал собирать ответы вместе, но я столкнулся с осложнениями, потому что вы (вполне понятно) хотите простой пример. Проблема многообразна.

Во-первых, у меня нет хорошего представления о вашем уровне фактической экспертизы реляционных баз данных и 5NF; У меня нет начальной точки для рассмотрения, а затем обсудим особенности 6NF,

Во-вторых, как и любой другой NF, он пестрит. Вы можете просто войти в нее; вы можете реализовать 6NF для таблиц certan; вы можете пройти полный свиньи на каждом столе и т.д. Конечно, есть взрыв таблиц, но тогда вы нормализуете это и убиваете взрыв; что расширенная или зрелая реализация 6NF. Без использования полного или частичного уровней 6NF, когда вы просите простейший, наиболее простой пример.

Я надеюсь, вы понимаете, что некоторые таблицы могут быть "в 5NF", а другие - "в 6NF".

Итак, я собрал это для вас. Но даже это требует объяснений.

Теперь SQL едва поддерживает 5NF, он вообще не поддерживает 6NF (я думаю, что dportas говорит то же самое в разных словах). Теперь я реализую 6NF на глубоком уровне по соображениям производительности, упрощенному повороту (из всех таблиц, любых и всех столбцов, а не глупой функции PIVOT в MS), столбчатому доступу и т.д. Для этого вам нужен полный каталог, который является расширение для каталога SQL, поддержка 6NF, который SQL не поддерживает, и поддерживать целостность данных и бизнес-правила. Таким образом, вы действительно не хотите реализовывать 6NF для удовольствия, вы делаете это только в случае необходимости, потому что вам нужно реализовать каталог. (Это то, чего толпа EAV не делает, поэтому большинство систем EAV имеют проблемы с целостностью данных. Большинство из них не используют декларативный ссылочный и целостность данных, которые SQL имеет.)

Но большинство людей, которые реализуют 6NF, не реализуют более глубокий уровень, с полным каталогом. Они имеют более простые потребности и таким образом реализуют более низкий уровень 6NF. Итак, давайте возьмем это, чтобы предоставить вам простой пример. Давайте начнем с обычной таблицы продуктов, объявленной в 5NF (и не будем спорить о том, что такое 5NF). Компания продает различные виды продуктов, половина столбцов является обязательной, а другая половина необязательна, что означает, что в зависимости от типа продукта определенные столбцы могут быть нулевыми. Хотя они, возможно, хорошо поработали с базой данных, Nulls теперь представляют собой большую проблему: столбцы, которые должны быть Not Null для определенных ProductTypes, являются Null, потому что декларация содержит NULL, а их код приложения только хорош, как у следующего парня.

Таким образом, они решили пойти с 6NF, чтобы исправить эту проблему, потому что подзаголовок 6NF утверждает, что он устраняет проблему Null. Шестая нормальная форма - это неприводимая нормальная форма, после нее больше не будет NF, потому что данные не могут быть нормализованы дальше. Строки были нормированы в максимальной степени. Определение 6NF:

таблица находится в 6NF, когда строка содержит первичный ключ и не более одного атрибута.

Обратите внимание, что по этому определению миллионы таблиц по всей планете уже находятся в 6NF, не имея этого намерения. Например. типичные справочные или поисковые таблицы с помощью только ПК и описания.

Right. Ну, наши друзья смотрят на таблицу продуктов, в которой есть восемь неключевых атрибутов, поэтому, если они производят таблицу продуктов 6NF, у них будет восемь таблиц вспомогательных продуктов. Тогда есть проблема, что некоторые столбцы являются внешними ключами для других таблиц, что приводит к большему количеству осложнений. И они отмечают тот факт, что SQL не поддерживает то, что они делают, и им приходится создавать небольшой каталог. Восемь таблиц правильные, но не разумные. Их целью было избавиться от Nulls, а не писать небольшую подсистему вокруг каждой таблицы.

Простой пример 6NF

Читатели, которые не знакомы со стандартом для моделирования реляционных баз данных, могут найти IDEF1X Notation, чтобы интерпретировать символов в примере.

Как правило, таблица продуктов сохраняет все обязательные столбцы, особенно FK, и каждый необязательный столбец, каждый столбец Nullable, помещается в отдельную таблицу под-продуктов. Это самая простая форма, которую я видел. Пять таблиц вместо восьми. В модели четыре таблицы вспомогательных продуктов: "в 6NF"; основная таблица продуктов - "в 5NF".

Теперь нам действительно не нужен каждый сегмент кода, который SELECTs из Product должен выяснить, какие столбцы он должен построить, на основе ProductType и т.д., поэтому мы предоставляем представление, которое по существу обеспечивает 5NF "вид" Кластер таблицы продуктов.

Следующее, что нам нужно, это основные зачатки расширения каталога SQL, чтобы мы могли гарантировать, что правила (целостность данных) для различных ProductTypes поддерживаются в одном месте, в базе данных и не зависят от код приложения. Самый простой каталог, с которым вы можете избавиться. Это отключено ProductType, поэтому ProductType теперь является частью этих метаданных. Вы можете реализовать эту простую структуру без каталога, но я бы не рекомендовал ее.

Обновление

Важно отметить, что я реализую все бизнес-правила в базе данных. В противном случае это не база данных (понятие реализации правил "в коде приложения" очень забавно, особенно в наши дни, когда у нас есть флористы, работающие как "разработчики" ). Поэтому все правила и т.д. В первую очередь реализуются как декларации SQL, ограничения CHECK, функции и т.д. Это сохраняет всю декларативную ссылочную целостность и декларативную целостность данных. Расширение каталога SQL охватывает область, в которой у SQL нет объявлений, и они затем реализованы как SQL. Будучи хорошим словарем данных, он делает гораздо больше. Например. Я не пишу Views каждый раз, когда я меняю таблицы или добавляю или изменяю столбцы или их характеристики, они создаются непосредственно из каталога + расширение с помощью простого генератора кода.

Еще одно очень важное замечание. Вы не можете реализовать 6NF (или EAV должным образом, если на то пошло), не выполняя полное и точное упражнение по нормализации, до 5NF. Проблема, которую я вижу на каждом сайте, заключается в том, что у них нет подлинного состояния 5NF, у них есть mish-mash частичной нормализации или вообще не нормализация, но они очень привязаны к этому. Создание либо 6NF, либо EAV - это катастрофа. Создание EAV или 6NF из этого без всех бизнес-правил, реализованных в декларативном SQL, - это ядерная катастрофа, сжигающая годами. Вы получаете то, за что платите.

Завершить обновление.

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

Ответ 3

Я раньше скептически относился к 6NF поскольку он был представлен как "просто", прикрепление некоторых столбцов временной метки на таблицы.

Я не совсем уверен, откуда это очевидное заблуждение. Возможно, тот факт, что 6NF был введен для книги "Временные данные и реляционный режим" по дате, Дарвен и Лоренцос? Во всяком случае, я надеюсь, что другие ответы здесь пояснили, что 6NF не ограничивается временными базами данных.

То, что я хотел сделать, - хотя 6NF является "академически респектабельным" и всегда достижимо, может не обязательно привести к оптимальному дизайну в каждом случае (а не только при рассмотрении реализации с использованием SQL). Даже вышеупомянутые первооткрыватели и сторонники 6NF, похоже, согласны, например.

Chris Date: "Для практических целей придерживайтесь 5NF (и 6NF)".

Хью Дарвен: "разложение 6NF вокруг Date [не человек!] будет излишним... оптимальным дизайном для футбольного клуба это... 5-и-бит-NF!"

Хью Дарвен: "мы находимся в 5NF, но не в 6NF, и снова 5NF достаточно" (несколько аналогичных примеров).

И снова я также могу найти доказательства обратного:

Chris Date: "Мы с Дарвеном некоторое время чувствовали, что все базовые рельвары должны быть в 6NF".

С практической точки зрения, я недавно расширил схему SQL одного из наших продуктов, чтобы добавить незначительную функцию. Я принял 6NF, чтобы избежать столбцов с нулевым значением и закончил с шестью новыми таблицами, где большинство (всех?) Моих коллег использовали бы одну таблицу (или, возможно, расширенную существующую таблицу) с нулевыми столбцами. Несмотря на то, что я проверял несколько "вспомогательных" хранимых procs и "denormalized" VIEW с триггерами INSTEAD OF, каждый кодер, которому приходилось работать с этой функцией на уровне SQL, уже не в порядке, чтобы проклинать меня:)

Ответ 4

У этих парней есть это: Anchor Modeling. Отличные научные статьи по этому предмету в сочетании с практическими примерами. Их работы окончательно подтолкнули меня за край, чтобы рассмотреть возможность создания DW в 6nf в предстоящем проекте. Работа POC, которую я сделал, подтвердила (по крайней мере, для меня), что огромные преимущества 6nf не перевешивают затраты.