Нормализация: что означает "повторяющиеся группы"?

Я читал разные учебники и видел разные примеры нормализации, особенно понятие "повторяющихся групп" в первой нормальной форме. Из них я собрал, что повторяющиеся группы являются "своеобразными" многозначными атрибутами (например, здесь и здесь).

Но мы уже делаем отдельные таблицы для каждого многозначного атрибута, включая внешние ключи из родительской таблицы в процессе сопоставления ERM (модели отношений сущностей) с RDM (модель реляционных данных)? Ссылка: this

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

В этом примере значение English повторяется снова и снова. Является ли это повторяющейся группой? Если я удалю его, чтобы сделать еще одну таблицу SUBJECT с именем Subject и Module_ID (Foreign key), это то, что я получаю. Конечно, он избавляется от повторяющейся ценности, но я не уверен, что это правильно. Это правильно?

Ответ 1

Термин "повторяющаяся группа" первоначально означал концепцию на языках CODASYL и COBOL, где одно поле могло содержать массив повторяющихся значений. Когда Э.Ф.Кодд описал свою первую нормальную форму, что он имел в виду под повторяющейся группой. Концепция не существует в любой современной реляционной или SQL-базе данных.

Термин "повторяющаяся группа" также используется неофициально и неточно разработчиками баз данных для обозначения повторяющегося набора столбцов, то есть набора столбцов, содержащих похожие значения в таблице. Это отличается от первоначального значения по отношению к 1NF. Например, в случае таблицы под названием "Семьи" с столбцами с именами Parent1, Parent2, Child1, Child2, Child3 и т.д. Коллекция столбцов Child N иногда упоминается как повторяющаяся группа и считается нарушенной 1NF даже хотя это не повторяющаяся группа в том смысле, в каком это предполагал Кодд.

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

Это неофициальное использование терминологии является немного неудачным, потому что оно может быть немного произвольным и запутанным (когда набор столбцов действительно представляет собой повторение?), а также потому, что это отвлечение от более фундаментальной проблемы, а именно: проблема Null, Все нормальные формы связаны с отношениями, которые не допускают возможности нулей. Если таблица допускает нуль в любом столбце, то она не отвечает требованиям схемы отношений, удовлетворяющей 1NF. В случае таблицы наших семейств, если столбцы Child разрешают null (для представления семейств, у которых меньше N детей), таблица Families не удовлетворяет 1NF. Возможность нулей часто забывается или игнорируется в упражнениях по нормализации, но исключение ненужных столбцов с нулевым значением является одной из серьезных причин избежать повторения наборов столбцов, независимо от того, называете ли вы их "повторяющимися группами".

См. также в этой статье.

Ответ 2

значение English повторяется снова и снова. Является ли это повторяющимся группа?

Нет. Многократные появления английского языка в SUBJECT_MODULE не являются повторяющейся группой или даже одной из двух вещей, которые люди ошибочно называют повторяющейся группой. Они также не свидетельствуют об избыточности или отсутствии нормализации. Такие множественные появления могут быть связаны с избыточным или нормализацией, но они появляются все время, когда нет избыточности и различных уровней нормализации.

Если SUBJECT_MODULE - это строки, в которых "[SUBJECT_NAME] имеет [MODULE_NAME], идентифицированный [MODULE_ID]", и у субъекта может быть более одного модуля, тогда где-то вы должны иметь несколько упоминаний об этом предмете (возможно, через его имя) с упоминаниями разные модули (возможно, по имени или id). Это не будет включать избыточность.

Student Age Subject

Adam    15  Biology
Adam    15  Maths
Alex    14  Maths
Stuart  17  Maths

Избыточность в этом примере из вашего второго вопроса this "не означает, что Адам появляется в двух строках или что Адам появляется с 15 в два ряда. Это то, что если таблица представляет собой строки, где" [Студент] [Возраст] лет и принимает [Тема] ", то Студент (например, Адам) может появляться в нескольких строках, но всегда появляется с тем же Возрастом (например, 15). Но если в таблице были строки, где" [Ученик] имеет друга [Возраст] лет в [Тема]", тогда таблица может быть полностью нормализована уже.

Конечно, он избавляется от повторяющегося значения, но я не уверен, что это правильная вещь.

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

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

Предоставив возможное разложение, вы сказали, что это также строки, где "... [Subject_Name]... [Module_ID]..." AND "... [Module_Name]... [Module_ID]... И вы дали некоторые примеры данных разложения. Но мы знаем только, что это может быть так разложено, потому что вы добавили разложение. И декомпозиции плюс данные по-прежнему недостаточно для того, чтобы мы знали, нужно ли это разложить.

Я читал разные учебники и видел разные примеры нормализация, особенно понятие "повторяющихся групп" в первом нормальная форма.

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

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

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

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

См. этот ответ re "atomicity" .