Я действительно начал собирать ответ, но столкнулся с осложнениями, потому что вы (вполне понятно) хотите простой пример.Проблема разнообразна.
Во-первых, у меня нет четкого представления о вашем уровне фактических знаний о реляционных базах данных и 5NF;У меня нет отправной точки, чтобы заняться и затем обсудить особенности 6NF,
Во-вторых, как и у любой другой NF, она разнообразна.Вы можете просто вступить в это;вы можете реализовать 6NF для некоторых таблиц;Вы можете использовать всю свинью на каждом столе и т. д. Конечно, есть взрыв столов, но затем вы нормализуете это и убьете взрыв;это продвинутая или зрелая реализация 6NF.Бесполезно указывать полный или частичный уровни 6NF, когда вы запрашиваете самый простой и простой пример.
Я надеюсь, вы понимаете, что некоторые таблицы могут быть "в 5NF", а другие - "в 6NF".".
Так что я собрал один для вас.Но даже это требует объяснения.
Теперь SQL едва поддерживает 5NF, он вообще не поддерживает 6NF (я думаю, что dportas говорит одно и то же в разных словах).Теперь я внедряю 6NF на глубоком уровне, по соображениям производительности, упрощенного поворота (целых таблиц; любых и всех столбцов, а не глупой функции PIVOT в MS), доступа к столбцам и т. Д. Для этого вам нужен полный каталог, который являетсярасширение каталога SQL, чтобы поддержать 6NF, который не поддерживается SQL, и поддерживать целостность данных и бизнес-правила.Таким образом, вы действительно не хотите внедрять 6NF для удовольствия, вы делаете это только в том случае, если у вас есть необходимость, потому что вам нужно реализовать каталог.(Это то, чего не делает группа EAV, и именно поэтому большинство систем EAV сталкиваются с проблемами целостности данных. Большинство из них не используют декларативную ссылочную и целостность данных, как у SQL.)
Но большинство людей, которые внедряют 6NF, не реализуют более глубокий уровень с полным каталогом.Они имеют более простые потребности и, следовательно, реализуют более низкий уровень 6NF.Итак, давайте возьмем это, чтобы предоставить простой пример для вас.Давайте начнем с обычной таблицы Product, которая объявлена в 5NF (и не будем спорить о том, что такое 5NF).Компания продает различные виды Продуктов, половина столбцов обязательна, а другая половина является необязательной, что означает, что в зависимости от Типа продукта некоторые столбцы могут иметь значение Null.Несмотря на то, что они, возможно, хорошо поработали с базой данных, пустые значения теперь представляют собой большую проблему: столбцы, которые должны быть не пустыми для определенных типов продуктов, имеют нулевое значение, поскольку в объявлении указывается значение NULL, а код их приложений так же хорош, как и у следующего парня..
Поэтому они решили пойти с 6NF, чтобы решить эту проблему, потому что подзаголовок 6NF гласит, что он устраняет Нулевую проблему .Шестая нормальная форма является неприводимой нормальной формой, после этого больше не будет NF, потому что данные не могут быть нормализованы дальше.Строки были максимально нормализованы.Определение 6NF:
таблица имеет формат 6NF, когда строка содержит первичный ключ и не более одного атрибута.
Обратите внимание, что по этому определению миллионы таблиц по всей планете уже находятся в 6NF, не имея этого намерения.Например.Типичные справочные или справочные таблицы, только с PK и описанием.
Справа.Итак, наши друзья смотрят на свою таблицу Product, которая имеет восемь неключевых атрибутов, поэтому, если они сделают таблицу Product 6NF, у них будет восемь таблиц Sub-Product.Кроме того, существует проблема, заключающаяся в том, что некоторые столбцы являются внешними ключами для других таблиц, что приводит к дополнительным сложностям.И они отмечают тот факт, что SQL не поддерживает то, что они делают, и им приходится создавать небольшой каталог.Восемь таблиц правильны, но не разумны.Их цель состояла в том, чтобы избавиться от Nulls, а не писать маленькие подсистемы вокруг каждой таблицы.
Простой пример 6NF
Читатели, не знакомые со Стандартом моделирования реляционных баз данных, могут найти Обозначение IDEF1X полезным для интерпретации символов в примере.
Так, как правило, в Таблице продуктов сохраняются все обязательные столбцы, особенно FK, и каждый дополнительный столбец, каждый столбец, допускающий значение Nullable, помещается в отдельную таблицу вспомогательных продуктов. Это самая простая форма, которую я видел. Пять столов вместо восьми. В модели четыре таблицы субпродуктов "в 6NF"; основная таблица продуктов "в 5NF".
Теперь нам действительно не нужно, чтобы каждый сегмент кода, который ВЫБИРАЕТ из Продукта, должен был выяснить, какие столбцы он должен построить, основываясь на ProductType и т. Д., Поэтому мы предоставляем представление, которое по существу обеспечивает 5NF-представление Таблица продуктов кластера.
Следующее, что нам нужно, - это базовые элементы расширения каталога SQL, чтобы мы могли гарантировать, что правила (целостность данных) для различных типов продуктов поддерживаются в одном месте, в базе данных, и не зависят от код приложения. Самый простой каталог, с которым вы можете сойти. Это исключено из ProductType, поэтому ProductType теперь является частью этих метаданных. Вы можете реализовать эту простую структуру без каталога, но я бы не рекомендовал ее.
Обновление
Важно отметить, что я внедряю все Бизнес-правила в базе данных. В противном случае это не база данных (понятие реализации правил "в коде приложения" крайне весело, особенно в наши дни, когда у нас есть флористы, работающие как "разработчики"). Поэтому все правила и т. Д. В первую очередь реализуются как декларации SQL, ограничения CHECK, функции и т. Д. Это сохраняет всю декларативную ссылочную целостность и декларативную целостность данных. Расширение каталога SQL охватывает область, для которой в SQL нет объявлений , и они затем реализуются как SQL. Будучи хорошим словарем данных, он делает гораздо больше. Например. Я не пишу Представления каждый раз, когда я изменяю таблицы или добавляю или изменяю столбцы или их характеристики, они создаются непосредственно из каталога + расширение с помощью простого генератора кода.
Еще одно очень важное замечание. Вы не можете реализовать 6NF (или EAV должным образом, в этом отношении), не выполнив полное и верное упражнение нормализации, до 5NF. Проблема, которую я вижу на каждом сайте, состоит в том, что у них нет подлинного состояния 5NF, у них есть смесь частичной нормализации или вообще никакой нормализации, но они очень привязаны к этому. Создание 6NF или EAV из этого - катастрофа. Создание EAV или 6NF из этого без всех бизнес-правил, реализованных в декларативном SQL , - ядерная катастрофа, горящая годами. Вы получаете то, за что платите.
Конец обновления.
Наконец, да, есть как минимум еще четыре уровня нормализации (нормализация - это принцип, а не просто ссылка на нормальную форму), которые можно применять к этому простому кластеру продуктов 6NF, предоставляя больший контроль, меньше таблиц, и т.д. Чем глубже мы пойдем, тем обширнее каталог. И более высокие уровни производительности. Когда вы будете готовы, просто спросите, я уже установил модели и разместил детали в других ответах.